SQL 靠邊站、GQL 來了：已成為 ISO/IEC 國際標準數據庫語言項目

　　作者：Alastair GreenFollow 是 Neo4j 的查詢語言標準和研究負責人。

　　面向屬性圖的標準查詢語言

　　GQL 是官方標準。今年 6 月，隸屬 ISO/IEC 聯合技術委員會1（負責制定 IT 標準）的全球諸多國家性標準機構開始就 GQL 項目提案進行表決。上周初投票結束，該提案獲得了通過，七個國家派出專家開展這個為期四年的項目。

　　GQL 的全稱是“圖形查詢語言”。這種新語言將由監管 SQL 標準的同一個國際工作組開發和維護。GQL 高度依賴現有的語言。　　

　　主要靈感源自 Cypher（現在實現的版本有十多個，包括六款商業產品）、Oracle 的 PGQL 和 SQL 本身，以及用于只讀屬性圖查詢的 SQL 新擴展。Tigergraph 的 GSQL 雖然來自風格上與其他標準機構不一樣的起點，但它是另一個值得注意的貢獻，其開發者已對 GQL 項目表示出了堅定承諾。

　　自 SQL 項目啟動以來已有三十多年，它最初是一項 ANSI 標準：GQL 是 SQL 之后的第一個 ISO/IEC 國際標準數據庫語言項目。十個國家投票支持這個新項目：中國、韓國、瑞典、美國、德國、英國、荷蘭、丹麥、哈薩克斯坦、加拿大和芬蘭。五個國家因缺乏判斷或評論該提案的專長而棄權。

　　只有日本投了反對票。日本給出的評論饒有意思。他們提出了兩個理由：外界的現有語言已經取得所需的結果；具體來說，SQL/屬性圖查詢（PGQ）擴展與 SQL 標準的其余部分一起就能滿足需求。

　　我想談談為什么 GQL 的擁護者提議與 SQL 共存的一種新標準語言是對的。

　　為什么我們需要一種專門針對圖形的查詢語言？

　　我在 2018 年 5 月提出了 GQL 宣言（GQL Manifesto）。該倡議的直接原因是：a）SQL/PGQ 僅限于只讀查詢，b）它無法投射新圖形，c）它只能訪問基于生成 SQL 表的圖形化視圖的圖形。

　　但許多供應商、研究人員和用戶都一致認為，可以使用非關系型“圖形原生”存儲和運行時模型（比如 Neo4j 領先行業的產品或新的 Redis Labs 圖形產品）來開發圖形數據庫。他們絕對需要一種 Cypher 之類的語言可以支持數據的插入和維護，而不僅僅是數據查詢。而 SQL 不太可能成為以圖形為中心的可“基于圖形生成”的語言所需的那種合適的模型。基于圖形生成是指獲取作為查詢輸入的圖形，因而輸出圖形，就像 SQL 可以讀表，并生成實為新表的結果集。

　　GQL 和 SQL 如何協同工作？

　　支持 GQL 項目的許多公司和國家性標準機構并不將 GQL 和 SQL 視為競爭對手，而是視為可以通過共同基礎和互操作性來相輔相成的語言。我這里所說的基礎是指核心數據類型和形成表達式的方法，以及共同的概念（比如目錄中保存的模式對象以及用戶/角色關聯的會話。）

　　不妨進一步了解這兩種語言將如何協同操作。

　　SQL/PGQ 查詢實際上是包裹著一段“proto-GQL”的 SQL 子查詢。我在下面演示的一個示例查詢來自關于 SQL/PGQ 的非常出色的資料（http://wiki.ldbcouncil.org/download/attachments/106233859/ldbc_tuc_2019_sql-pgq.pdf?version=1&modificationDate=1562342465000&api=v2）；今年 SIGMOD 大會接近尾聲時，Oracle 的同仁 Oskar van Rest 為 7 月份在阿姆斯特丹召開的鏈接數據庫基準委員會（LDBC）會議制作了該資料。

　　以關鍵字 MATCH 開頭的紅色部分是模式匹配查詢的一個片段，它與用 Cypher 或 PGQL 編寫的查詢極其類似（這些語言在很多方面非常相似）。你可能注意到，IS 用于引入標簽（如在 Creator IS Person 中），用于引入主機參數或變量。但是你也可以在標簽表達式中使用冒號（如果 SQL 引擎的解析器足夠智能），那樣與之前存在的“輸入”屬性圖查詢語言的相似性會變得更明顯。

　　PGQ 查詢的其他部分（黑色和綠色）將此 proto-GQL 聯合到 SQL SELECT 語句中。表格結果通過 COLUMNS 子句流出到常規 SQL 查詢中。它們僅僅對與圖形查詢交互的 SQL 引擎而言值得關注。GQL 本身不會參與這種 SQL“外來函數接口”。

　　SQL/PGQ：GQL 火箭的第一級

　　模式匹配只讀子語言（上面 Oskar 的示例查詢中標以紅色）注定要成為完整 CRUD GQL 的一個組成部分。它好比是“GQL 火箭的第一級”。這種緊密的連接是 GQL 項目提案文件的一部分。

　　因此，GQL 的其中一項工作是規范諸多方面，比如屬性圖數據模型、標簽的使用以及查詢謂詞（query predicate）的屬性：我們獲得了一種標準的方法來處理已經可以用現有語言來處理的事情。我們希望由多種類似語言變成一種標準語言。

　　但我們還希望將供應商正竭力開發的工業創新成果納入到定義清晰的屬性圖數據庫這個產品類別?6?7。SQL/PGQ 領域有值得關注的新動向，比如常規路徑查詢、嵌套路徑和路徑宏命令，所有這些都增強了流行的模式匹配范式的功能。GQL 會添加還沒有被所有供應商實施，但起碼被至少一家供應商實施的其他創新。

　　這就引出了 SQL/PGQ 無力實現、而且不太可能實現的功能。

　　SQL 生成表，而 GQL 生成圖

　　SQL 這種語言在一個關鍵方面與 Cypher 大不相同。Cypher（和 PGQ 的圖形子語言）讓用戶可以探索其數據圖的結構，無需事先知道將返回哪些類型的數據。它們讓你可以進行真正的圖查詢，這方面值得關注的不僅僅是值，還有數據子集的形狀，在與圖模式匹配的元素值方面予以定義。換句話說，圖查詢描述了針對一個或多個輸入圖計算的子圖或投射圖。

　　然而，SQL/PGQ、Cypher 和 PGQL 只允許你從圖中提取一個表。這是必須保留的重要特性，因為否則就不可能獲取存儲在圖元素上的實際數據值。但是將結果僅限于表意味著你無法輕松創建圖轉換鏈，也無法針對多個輸入圖執行集合操作。你也無法生成和存儲快照圖，無法定義圖投射視圖。

　　GQL 將建立在 openCypher Morpheus 的基礎上（后者將 Cypher 引入到 Apache Spark），并結合來自 LDBC 的G-CORE 的靈感，為用戶提供了一種組合圖查詢語言，支持所有那些功能。這將使 GQL 在概念上等同于 SQL。

　　我認為 SQL 標準社區在這里做出了一個正確的決定：讓 SQL（一種圍繞表構建的語言）可以在 SQL 用戶想要從圖中查找和投射表時可以引用 GQL，但在用戶想要從圖中查找和投射圖時可以使用 GQL。這意味著我們可以生成圖、將圖編入目錄，這些圖不僅僅是基于表的視圖，還有離散的復雜數據對象。

　　這涉及 SQL 并非天然適合的其他圖功能。

　　CRUD 的圖模式

　　插入、更新和刪除圖（以及路徑和元素）的 DML 語句與用于匹配和提取數據的 DQL 密切相關。因此，最好在這兩種操作中使用一套共享的以模式為中心的詞匯表。這意味著 GQL 是適合將“CUD”添加到 PGQ 的“R”的（單一）環境。

　　你可以更新圖視圖下的表以獲得同樣的效果（前提是你使用配備圖的 SQL 引擎），但這使你無法享用圖數據模型的簡單性和強大功能。這就像通過針對所有基本表編寫更新來寫入到 SQL 視圖：有可能做到但弄巧成拙。

　　SQL 引用 GQL

　　由于除了 SQL/PGQ 中完成的工作外，GQL 還添加了數據修改，我們開發了一種“可引用性更強”的 GQL。如果 SQL 用戶想要將數據從表格數據庫推送到存儲在數據庫目錄中的圖對象，那么合乎自然的做法是引用更多的 GQL，在 SQL GRAPH_MODIFY 函數里面執行專門針對圖的那項工作。

　　當我們 Neo4j 早在 2017 年在關于 PGQ 的標準討論中首次提出“SQL 引用 Cypher”供討論時，得到的評論是“Cypher 不是一項可引用的國際標準”。這促使我們直奔 GQL。它將是一種官方的國際標準，可以被 SQL 引用。當然，隨著時間的推移，我們可能希望讓 GQL 可以為表操作引用 SQL！

　　屬性圖模式　　

　　這引出了 SQL 不適合的另一項主要功能。圖的類型是其節點的類型，加上邊緣的類型以及它們可以連接的節點的類型。特定類型的節點和關系存儲數據值：特定類型的標簽和屬性（內容）。

　　SQL 沒有這個進化的概念：按照類型組合和參數化表示復雜類型。而表示圖類型的最自然方式是顯示它編碼的數據關系的模式。使用元素內容（標簽和屬性）的“記錄類型”定義的屬性圖形類型應運而生，模式用于將那些內容類型組合到節點和關系（包括方向）。

　　下圖是一項 Neo4j 提案，尚未得到一直在為 GQL 項目做準備的工作組的同意，但它肯定會讓人想到 ASCII 碼繪圖中簡潔、富有表現力的圖案如何有助于記錄和直觀顯示圖及其類型。

　　順便說一下，GQL 很可能規范無向關系的模式、查詢和修改（PGQL 和 Tigergraph 的 GSQL 中已經存在的一項功能）。更寬泛說，GQL 讓我們有機會獲得比 SQL 更現代化的語言，擁有更結構化的類型系統、干凈地組合作為過程查看的查詢，擁有參數（允許參數化視圖）以及前向（線性）和嵌套過程組合。

　　“全圖”（Omnigraph）

　　我最后闡述 GQL 有別于 SQL 的最值得關注的地方之一。在G-CORE 研究語言中，你可以將兩個圖結合起來，然后添加新元素（節點和關系），構成第三個圖。作者著眼于“在現有圖上構建”。G-CORE（比如 Cypher for Apache Spark）只針對不可變數據進行操作，因此這種方法中的第三個圖實際上是前兩個圖的副本加上任何新數據。

　　但數據庫是可變存儲系統。在 Neo4j 中，我們開始將這種“兩個圖加新數據”設計模式的可變存儲系統稱為全圖（omnigraph）。它是視圖和基本圖的組合，在 SQL 中沒有相對應的，因為 SQL 并不構造擁有任何顯式關系的數據，只有值調控的鏈接（外來鍵）。

　　GQL 視圖如同 SQL 視圖，讓你可以查看源自基本表上函數的數據。該視圖的任何更新都將寫入到基本表。GQL 基本圖（如同 SQL 基表表）讓你可以直接存儲和讀取數據。但是 GQL“全圖”將是這樣一個圖：一些數據通過其他圖（包括其他視圖）的視圖得出的，一些數據是新的、是相應圖所特有的（基本數據）。這就有可能在預先存在的圖中的元素之間添加關系，但是這些關系僅存在于“疊加”全圖中。

　　這種安排好比 SQL 中基本表和派生表的命名組合，由于外來鍵和鏈接表關系形成的內在圖被組合在一起。我們認為，稱之為圖更合乎自然，使用圖形查詢語言來定義和查詢它更自然。

　　WG3 將在坦桑尼亞阿魯沙開會

　　GQL 項目的工作將于本月晚些時候在坦桑尼亞阿魯沙召開的 SQL/GQL 標準委員會 ISO/IEC JTC 1 SC 32/WG3 的下一次會議上全面開始。

　　現階段無法表明第一個可實施版本的 GQL 何時問世，但很有可能在 2020 年下半年之前制定某個相當完整的草案。

　　GQL 社區 10 月 9 日發布更新

　　10 月 9 日周三將舉行 GQL 社區更新互聯網大會，由 LDBC 主席 Peter Boncz 和 WG3 召集人 Keith Hare 共同主持。

　　這次會議將討論不同的主題和工作流程，包括針對屬性圖模式和現有語言分析的兩個 LDBC“特別任務組”安排的社區工作。此前，LDBC 的理事會已決定為支持 GQL 的社區工作充當組織中心，充分發揮 LDBC 與 WG3 的正式聯絡機制。

　　已設想使用正式的指稱語義來協助提高 GQL 規范的質量和準確性，并依托在愛丁堡和華沙開展的類似工作，為 Cypher 的一部分（包括值得關注的 Cypher.PL 可執行語義項目，用 Prolog 編寫）定義正式語義。隨著時間的推移，也很有可能會開始開發用于語法工具和一致性測試的開源軟件，以支持官方規范，就像 openCypher 項目那樣。

　　定義屬性圖數據管理這個類別

　　GQL 有望成為屬性圖的關鍵性標準：在這個世紀，數據管理領域最激動人心、最強大的產品類別之一已在業界扎穩了腳跟。