Graph Query Language(GQL，圖形查詢語言)是由同時維護SQL標準的國際工作組開發和維護的一種新語言。GQL很大程度上借鑒了現有的語言，主要的靈感來自Cypher(現在實現版本有10多個，包括6個商業產品)、Oracle的PGQL和SQL本身。GQL項目是自SQL之後的第一個ISO/IEC國際標準數據庫語言項目。今年6 月，隸屬ISO/IEC 聯合技術委員會1(負責定制IT 標準)的全球諸多國家性標準機構開始就GQL 項目提案進行表決，有七個國家派出專家參與這項為期四年的項目。在本週投票結束，提案獲得通過。

共有十個國家投出了贊成票，其中包括中國、韓國、瑞典、美國、德國、英國、荷蘭、丹麥、哈薩克斯坦、加拿大和芬蘭。另外有五個國家選擇棄權，其理由是缺乏對該提案作出判斷或發表評論的專門知識。

只有日本投了反對票，它列舉了兩個理由：

• 現有的語言已經能實現這類需求
• 具體來說，SQL/Property Graph Query 擴展以及SQL 標準的其餘部分可以滿足需求

為什麼我們需要一種特定於圖形的查詢語言？

許多供應商、研究人員和用戶一致認為，可以使用非關係型“圖形原生”存儲和運行時模型來開發圖形數據庫。例如Neo4j 的行業領先的圖形數據庫平台和新的Redis Labs 圖形產品。

但是，他們也需要一種類似 Cypher 的語言來支持數據的插入和維護，而不僅僅是數據查詢。對於以圖行為中心的語言來說，SQL 不太可能是一個合適的模型，所需的語言是能夠將圖形作為查詢輸入，然後輸出一個圖，就像SQL 可以讀取表，並生成實為新表的結果集。

GQL 和SQL 如何協同工作？

許多支持GQL 提案的公司和國家標準機構並不認為GQL 和SQL 是競爭對手，而是通過共享的基礎和互操作來相互補充。(其中指的是核心數據類型和表達式的形成方式，以及共享的概念，如目錄中持有的模式對象，以及與用戶/角色相關的會話)。

SQL/PgQ 查詢實際上是一個圍繞著一段“proto-gql”的SQL 子查詢。下面有一個示例查詢，在今年SIGMOD 大會接近尾聲時，Oracle 的Oskarvanrest 為今年7 月在阿姆斯特丹舉行的鏈接數據庫基準理事會(Link Database Benchmark Council，LDBC)會議提出的。

以關鍵字MATCH 開頭的紅色部分是模式匹配查詢的一個片段，該查詢非常類似用Cypher 或PGQL 編寫的查詢。你可能會注意到，它用於引入標籤(如在Creator IS Person 中)，以及用於引入主機參數或變量。但是，你也可以在標籤表達式中使用冒號(如果SQL 引擎的解析器是智能的)，那麼與先前存在的“輸入”屬性圖查詢語言的相似性就會更加明顯。

PgQ 查詢的其他部分(黑色和綠色)將這個Proto-GQL 連接到一個SQL SELECT 語句中。表格結果通過Columns 子句流到常規SQL 查詢中。它們只對與圖形查詢交互的SQL 引擎來說是需要注意的，GQL 本身不會涉及到這種SQL“外部函數接口”。

SQL 生成表，GQL 生成圖

SQL 在一個關鍵方面與Cypher 語言大不相同，Cypher 讓用戶在不知道將返回哪些類型的數據的情況下探索其數據圖的結構。它可以讓你進行真正的圖形查詢，其中值得注意不僅僅是值，還包括數據子集的形狀，與匹配圖模式的元素的值有關。換句話說，圖查詢針對在一個或多個輸入圖上計算的子圖或投射圖。

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

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

更普遍地說，GQL 是一種比SQL 更現代的語言，它具有更結構化的類型系統。

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

目前還無法確定GQL 的第一個可實現版本，但很有可能在2020 年下半年之前製定某個相當完整的草案。

來源：linkedin