據(jù)庫查詢語言三坐標：Cypher、openCypher與GQL的演進與區(qū)別)
最近整理圖數(shù)據(jù)庫的學(xué)習(xí)筆記發(fā)現(xiàn)一個特別容易讓人繞暈的問題Cypher、openCypher、GQL這三個詞經(jīng)常被混著用。有人以為 openCypher 是 Cypher 的新版本也有人以為 GQL 就是 GraphQL 的縮寫。其實三者代表了同一條查詢語言演進路徑上的三個坐標Neo4j 的廠商方言、社區(qū)推動的開放規(guī)范、ISO 發(fā)布的國際標準。這篇簡記想用一條線把三者的來歷、關(guān)系、差異和當前落地情況講清楚給剛接觸圖數(shù)據(jù)庫的開發(fā)者以及正在做圖數(shù)據(jù)庫選型的團隊提供一個可以參考的坐標系。如果你想把這篇文章當快速索引來用先看第 1 節(jié)理解 Cypher 的底層設(shè)計哲學(xué)第 2 節(jié)是語法心法第 3 節(jié)搞清 openCypher 的邊界第 4 節(jié)和第 5 節(jié)用于理解 GQL 帶來的變化以及三個概念的準確區(qū)分最后第 6 節(jié)是我自己踩過的坑和當前的學(xué)習(xí)路線可以直接跳到對應(yīng)小標題看。1. 從一條查詢說起Cypher 為什么讓人上癮1.1 SQL 在圖數(shù)據(jù)面前的無力感在 Cypher 出現(xiàn)以前圖數(shù)據(jù)查詢基本靠 SQL 硬寫或者靠各家的專用 API。問題是圖數(shù)據(jù)天然是節(jié)點 邊的結(jié)構(gòu)化網(wǎng)狀數(shù)據(jù)SQL 是面向二維表的集合操作表達圖遍歷時非常擰巴。舉一個最簡單的場景查Alice 認識的朋友里年齡大于 25 歲的人。在 SQL 里如果 friend 關(guān)系是一個表你需要自連接一次SELECT f.name FROM person p JOIN knows k ON p.id k.person_id JOIN person f ON k.friend_id f.id WHERE p.name Alice AND f.age 25;這還只是查一跳。如果要查Alice 的六度好友SQL 要么寫遞歸 CTE要么在應(yīng)用層反復(fù)循環(huán)查詢。遞歸 CTE 不是不能寫但可讀性、性能、維護性都很糟。圖數(shù)據(jù)最擅長的就是多跳遍歷而 SQL 在這里表現(xiàn)得像穿西裝游泳——不是不行是別扭。1.2 圖案即查詢的設(shè)計哲學(xué)Cypher 的核心創(chuàng)意是把查詢寫成一張圖的樣子。你直接在查詢里畫一個模式pattern告訴數(shù)據(jù)庫在所有數(shù)據(jù)中找出長得像這個模式的所有結(jié)構(gòu)。MATCH (alice:Person {name: Alice})-[:KNOWS]-(friend:Person) RETURN friend.name這一行就是在說找一個 Person它的 name 是 Alice通過 KNOWS 關(guān)系連到另一個 Person把這個人的 name 返回。 圓括號表示節(jié)點方括號表示關(guān)系箭頭表示方向。整個過程像在紙上畫社交關(guān)系圖一樣自然。這也是 Cypher 讓我上癮的根本原因它是聲明式語言你只描述要什么不描述怎么做執(zhí)行計劃由優(yōu)化器決定。對于非數(shù)據(jù)庫專業(yè)出身的人這種思維負擔(dān)小得多。你可以把一個復(fù)雜查詢的需求先畫成草圖再翻譯成 Cypher幾乎就是逐行謄寫。1.3 Cypher 不是唯一答案但它是重要的答案圖查詢語言其實有多個流派。Neo4j 在 2011 年前后開始做 Cypher后來 Oracle 也搞了 PGQL還有 TinkerPop/Gremlin 這種命令式遍歷語言。Gremlin 的寫法強調(diào)怎么走Cypher 強調(diào)要什么這是兩種完全不同的心智模型。Cypher 能流行起來除了 Neo4j 的生態(tài)加持它這種圖案即查詢的直觀性占了很大功勞。很多接觸圖數(shù)據(jù)庫的開發(fā)者第一個會寫的查詢就是順著一條關(guān)系找鄰居Cypher 把這個門檻降到了接近零。2. 模式匹配是心法別只記語法2.1 屬性圖模型的三件套要理解 Cypher先理解它操作的數(shù)據(jù)模型——屬性圖Property Graph。這個模型里只有三個要素節(jié)點Node、關(guān)系Relationship、屬性Property。節(jié)點可以打標簽Label表示類型比如 Person、Movie關(guān)系有且僅有一個類型Type比如 KNOWS、ACTED_IN節(jié)點和關(guān)系都可以掛鍵值對形式的屬性。關(guān)系是圖數(shù)據(jù)庫和關(guān)系型數(shù)據(jù)庫最大的分水嶺。在 SQL 里兩張表的關(guān)系是靠外鍵和 JOIN 臨時算出來的在圖數(shù)據(jù)庫里關(guān)系是存儲層面的一等公民物理上直接連著兩個節(jié)點。所以圖數(shù)據(jù)庫做多跳查詢不需要反復(fù)做昂貴的連接運算這是它擅長深度遍歷的根本原因。2.2 讀懂一行 MATCH拆解最常用的模式語法你可以把 MATCH 語句當成一個模板MATCH (p:Person {name: Alice})-[:KNOWS*1..2]-(f:Person)(p:Person)圓括號是節(jié)點模式。p是變量名后面可以用:Person是標簽過濾{name: Alice}是屬性過濾。-[:KNOWS*1..2]-方括號是關(guān)系模式。:KNOWS是關(guān)系類型*1..2是可變長度路徑表示沿著 KNOWS 走 1 到 2 跳箭頭表示方向。(f:Person)目標節(jié)點模式。整句話的意思從 name 為 Alice 的 Person 出發(fā)沿著 KNOWS 關(guān)系走 1 到 2 跳到達任何 Person 類型的節(jié)點并把這個節(jié)點綁定到變量f上。這里變量名、標簽、屬性條件都可以靈活增減。沒有方向時可以用--表示無向連接這在社交網(wǎng)絡(luò)互為好友的場景很實用。2.3 從業(yè)務(wù)問題到查詢的推演我們來看一個綜合例子。假設(shè)需求是找出 Alice 的好友中共同感興趣的 Topic 超過 3 個、且在最近一年還活躍的人。第一步先畫結(jié)構(gòu)。Alice 和好友們通過 KNOWS 相連好友通過 HAS_INTEREST 連到 Topic。畫出草圖后模式就出來了MATCH (alice:Person {name: Alice})-[:KNOWS]-(p:Person)-[:HAS_INTEREST]-(t:Topic) WITH p, count(t) AS interestCount WHERE interestCount 3 AND p.lastActive date(2024-01-01) RETURN p.name, interestCount ORDER BY interestCount DESC這里有個關(guān)鍵點WHERE不能直接跟在聚合函數(shù)count(t)后面需要先用WITH把聚合結(jié)果傳遞下去再用WHERE過濾。這就是 Cypher 和 SQL 的一個顯著差異——SQL 里聚合后過濾用的是HAVINGCypher 用WITH ... WHERE組合實現(xiàn)同樣的能力。善于用WITH做分段聚合是寫出清晰 Cypher 的前提。2.4 CREATE 與 MERGE創(chuàng)建和更新數(shù)據(jù)的兩種思路查詢語言總得有寫入能力。CREATE簡單粗暴每次執(zhí)行都會創(chuàng)建新的節(jié)點或關(guān)系CREATE (n:Person {name: Bob, age: 30})MERGE則是先查后建的原子操作語義上等價于存在就匹配不存在就創(chuàng)建MERGE (p:Person {email: bobexample.com}) ON CREATE SET p.createdAt datetime() ON MATCH SET p.lastSeen datetime()ON CREATE和ON MATCH是 MERGE 特有的分支分別處理節(jié)點被新建和節(jié)點已存在兩種情況。這個寫法非常適合做數(shù)據(jù)同步場景比如用戶表導(dǎo)入時用 email 作為唯一標識有則更新時間戳無則插入新記錄。但要注意MERGE 默認基于整個模式匹配不是只匹配模式中的某個節(jié)點。如果你只寫了MERGE (p:Person {email: ...})它匹配的是擁有該 email 屬性的 Person 節(jié)點這個完整結(jié)構(gòu)。3. openCypher從廠商方言到社區(qū)規(guī)范的中間態(tài)3.1 為什么 Neo4j 要把 Cypher 開放出來2015 年Neo4j 啟動了 openCypher 項目把 Cypher 的語法和語義規(guī)范、相關(guān)測試工具以 Apache 2.0 許可開源。很多人不理解這步棋數(shù)據(jù)庫廠商的語言專利通常是護城河Neo4j 為什么要自斷后路背后的邏輯其實很現(xiàn)實。圖數(shù)據(jù)庫市場當時開始出現(xiàn)多家競爭者每家都有自己的查詢語言。如果 Cypher 只屬于 Neo4j用戶選型時就會擔(dān)心被綁定如果讓 Cypher 成為多廠商共同支持的開放規(guī)范反而能降低用戶的顧慮而 Neo4j 作為原廠實現(xiàn)和生態(tài)最成熟的數(shù)據(jù)庫依然占據(jù)心智第一的位置。用術(shù)語說這相當于把 Cypher 從專有技術(shù)變成行業(yè)公共品。3.2 openCypher 項目里到底有什么openCypher 不是一門新語言它是 Cypher 語言本身的開放化包裝。項目主要包含三塊東西規(guī)范文檔描述 Cypher 的語法、表達式語義、模式匹配規(guī)則。TCKTechnology Compatibility Kit, 技術(shù)兼容性測試套件用 Gherkin 風(fēng)格的.feature腳本描述大量給定數(shù)據(jù) 執(zhí)行查詢 期望結(jié)果的測試場景數(shù)據(jù)庫實現(xiàn)可以拿這些場景驗證自己的兼容程度。開源的工具鏈包括詞法/語法解析器等方便其他數(shù)據(jù)庫復(fù)用解析層。TCK 的腳本長這樣簡化示意Feature: WHERE Scenario: Filter nodes by property Given an empty graph And having executed: CREATE (:Person {name: Alice, age: 30}) CREATE (:Person {name: Bob, age: 20}) When executing query: MATCH (p:Person) WHERE p.age 25 RETURN p.name Then the result should be: | p.name | | Alice |這套測試的價值在于它把兼容 openCypher從一句口號變成了可驗證的指標。數(shù)據(jù)庫廠商說支持 openCypher你可以拿 TCK 跑一遍通過率一目了然。3.3 誰在用 openCypher目前常見的 openCypher 兼容實現(xiàn)包括 Neo4j、Memgraph、Kuzu、Amazon Neptune 的兼容模式等。Kuzu 是嵌入式列式圖數(shù)據(jù)庫主打單機分析場景能在筆記本上直接跑語法和 Neo4j 非常接近Memgraph 是流式圖數(shù)據(jù)庫核心也接受 openCypher 查詢。它們的共同點是語法上盡量貼近 Cypher但系統(tǒng)層面各有各的存儲引擎、索引策略和事務(wù)模型。這一點必須強調(diào)openCypher 只規(guī)范了查詢語言這一層。它不規(guī)定存儲布局、不規(guī)定索引結(jié)構(gòu)、不規(guī)定事務(wù)隔離級別、不規(guī)定分布式行為。所以同一個查詢在五個數(shù)據(jù)庫里跑結(jié)果可能對但性能和并發(fā)表現(xiàn)可能天差地別。語言是普通話系統(tǒng)是各個方言地區(qū)的民間習(xí)俗兩者不能畫等號。3.4 openCypher 的天花板openCypher 的定位是開放規(guī)范但距離國際標準還有明顯距離。它沒有定義多圖操作、沒有標準化的目錄管理、也沒有嚴格的形式化語義。更重要的是openCypher 項目雖然開放主導(dǎo)權(quán)依然在 Neo4j 手里。對于一個想要嚴肅使用圖數(shù)據(jù)庫的大型組織來說廠商主導(dǎo)的開放規(guī)范并不能完全消除鎖定焦慮大家真正期待的是由 ISO 這樣的國際標準化組織來定義一門正式的圖查詢語言。這個期待最終等來了 GQL。4. GQLISO 國際標準把圖查詢語言送進新階段4.1 七年磨一劍2024 年 4 月ISO/IEC 39075:2024 正式發(fā)布GQLGraph Query Language成為國際標準。從 2017 年項目啟動算起前后經(jīng)歷了大約七年。它并非憑空設(shè)計而是充分吸收了 openCypher 的成熟語法、PGQL 等語言的合理設(shè)計最終由 ISO/IEC JTC 1/SC 32 委員會統(tǒng)一打磨成標準。GQL 的定位非常明確它是與 SQL 并列的、專為屬性圖數(shù)據(jù)模型設(shè)計的標準查詢語言。換句話說關(guān)系型數(shù)據(jù)庫有 SQL 做統(tǒng)一接口圖數(shù)據(jù)庫現(xiàn)在有了自己的官方標準語言。對用戶來說這是封閉生態(tài)走向開放生態(tài)的關(guān)鍵一步。4.2 GQL 和 SQL/PGQ 的關(guān)系很多人不知道SQL 標準族里其實還有一個 SQL/PGQISO/IEC 9075-16:2023Property Graph Queries。它允許在 SQL 語句中嵌入屬性圖模式匹配相當于給關(guān)系型數(shù)據(jù)庫加上了圖查詢擴展。GQL 是獨立完整的圖數(shù)據(jù)庫語言SQL/PGQ 是 SQL 內(nèi)部的一個補充部分兩者共享屬性圖的數(shù)據(jù)模型認知。這個關(guān)系值得多說一句它意味著圖查詢的思想正在反哺傳統(tǒng)數(shù)據(jù)庫。你可以用 SQL 寫圖模式也可以用 GQL 操作純圖數(shù)據(jù)庫未來關(guān)系型和圖數(shù)據(jù)之間的邊界會越來越靈活。這對做數(shù)據(jù)架構(gòu)的人來說是一個重要的趨勢信號。4.3 GQL 從 Cypher 繼承了什么又改了什么打開 GQL 標準你會發(fā)現(xiàn)Cypher 的味道非常濃。節(jié)點圓括號、關(guān)系方括號、MATCH 關(guān)鍵字、變量綁定、模式匹配的思維這些核心設(shè)計被完整保留。GQL 相當于把 Cypher 的骨架接收下來然后按照國際標準的嚴格要求重新定義了一套語義。差異也很明顯最直觀的幾個多圖支持。openCypher 默認在一個圖里操作GQL 用USE GRAPH顯式進入某個圖。屬性操作。openCypher 刪除屬性用REMOVEGQL 標準里用DROP PROPERTY。語句結(jié)束。GQL 語句以分號結(jié)束標準味十足openCypher 對分號沒有強制要求。圖目錄。GQL 標準定義了 CATALOG 和圖目錄操作openCypher 沒有這個概念。寫一個 GQL 風(fēng)格的示意查詢USE GRAPH social; MATCH (p:Person {name: Alice})-[:FRIEND]-(f:Person) WHERE f.age 25 RETURN f.name AS name;看起來和 Cypher 幾乎一樣但多了圖切換和分號。所有 GQL 的細節(jié)我建議以正式標準文本和各數(shù)據(jù)庫最新文檔為準——標準落地初期廠商支持度一定是參差不齊的。4.4 廠商跟進到什么程度了GQL 發(fā)布后Neo4j 官方明確表態(tài) Cypher 會持續(xù)演進以兼容 GQL這等于給現(xiàn)有 Ne4oj 用戶吃了一顆定心丸你的 Cypher 知識不會作廢。新興的 Kuzu、Memgraph 等也一直在跟進標準兼容。但現(xiàn)實地說標準剛發(fā)布兩三年內(nèi)市面上絕大多數(shù)圖數(shù)據(jù)庫還是以兼容 openCypher 為主GQL 更多是作為未來方向存在。做技術(shù)選型時可以優(yōu)先選擇明確表態(tài)向 GQL 演進的實現(xiàn)同時不指望眼下所有語法都對齊標準。4.5 一個常見的混淆GQL 不是 GraphQL這個名字的坑我踩過不止一次。GQL 是圖數(shù)據(jù)庫查詢語言GraphQL 是 Meta 提出的 API 查詢語言跑在 HTTP 層服務(wù)端和客戶端之間用。前者操作數(shù)據(jù)引擎內(nèi)部的數(shù)據(jù)后者操作業(yè)務(wù)接口的資源圖。兩者除了名字縮寫接近技術(shù)棧和應(yīng)用場景幾乎沒有交集。搜索資料時搜 GQL 很容易跳出 GraphQL 的內(nèi)容記得在關(guān)鍵詞里加上 graph database 或 ISO 39075 過濾。5. 一個表看懂三者關(guān)系再細看語法差異5.1 三者定位對比名稱本質(zhì)發(fā)起/管理機構(gòu)狀態(tài)典型實現(xiàn)CypherNeo4j 的圖查詢語言Neo4j隨 Neo4j 版本演進非獨立標準Neo4j DatabaseopenCypherCypher 的開放規(guī)范openCypher 項目Neo4j 主導(dǎo)面向社區(qū)的開放規(guī)范非 ISO 標準Neo4j、Kuzu、Memgraph、Amazon NeptuneGQL圖查詢語言國際標準ISO/IEC JTC 1/SC 32已發(fā)布ISO/IEC 39075:2024各廠商正在實現(xiàn)/演進中演進路徑其實是線性的Cypher 是源頭openCypher 把源頭開放成規(guī)范GQL 把規(guī)范升格為國際標準。三者不是三個平行的選項而是一條時間軸上的三個階段。5.2 語法差異速查表差異點openCypherGQL 標準刪除屬性REMOVE n.propDROP PROPERTY n.prop多圖切換通常固定單圖USE GRAPH graphName語句結(jié)束分號非必需以分號結(jié)束圖目錄無標準概念有 CATALOG 概念標簽表達式有限支持完整支持這些是標準層面的差異。具體到某個數(shù)據(jù)庫廠商會在標準和自己原有方言之間做取舍實際行為的差異可能比表里列的更大。我的建議是不要把 Cypher 當作統(tǒng)一語法去背把它當作一種圖查詢思維去學(xué)落地時再逐庫核對細節(jié)。5.3 遷移和兼容性驗證的實操思路如果你正在做數(shù)據(jù)庫遷移或者計劃用多個圖數(shù)據(jù)庫這幾點可以直接抄把現(xiàn)有查詢清單里的REMOVE、函數(shù)大小寫、正則函數(shù)、CALL 子查詢等逐一核對這些都是方言差異的重災(zāi)區(qū)。有條件時用 openCypher 的 TCK 對目標數(shù)據(jù)庫跑一遍兼容性測試通過率比廠商宣傳頁靠譜得多。寫查詢時盡量使用公共子集MATCH、WHERE、RETURN、CREATE、MERGE、可變長度路徑這些核心語法在絕大多數(shù)兼容實現(xiàn)里行為一致。避免依賴某個數(shù)據(jù)庫特有的高級功能比如某一家的過程調(diào)用語法或存儲過程機制否則遷移時你會被這些甜蜜的鎖卡住。6. 實踐中的幾個體會和避坑建議6.1 先畫出圖再寫模式我見過最多的新手錯誤不是語法寫錯而是模式本身畫錯了。方向?qū)懛础㈥P(guān)系類型拼錯、把本可以在屬性條件里過濾的內(nèi)容放到 WHERE 里這些問題的根源都是沒有先在紙上畫出節(jié)點和關(guān)系。我的習(xí)慣是任何超過兩跳的查詢先花一分鐘畫草圖再照著草圖翻譯成 Cypher。草圖對了代碼基本就對了七成。6.2 避坑變長路徑是性能陷阱-[:KNOWS*1..6]-這種寫法看起來方便但在稠密圖上會帶來指數(shù)級的遍歷開銷。實際使用時一定要給跳數(shù)設(shè)上限并且盡量結(jié)合方向、標簽和屬性條件做剪枝。如果查詢只需要結(jié)果集的一部分再加上 LIMIT避免引擎為了取一條記錄把半個圖都遍歷一遍。圖數(shù)據(jù)庫再快也扛不住失控的路徑爆炸。6.3 避坑MERGE 不是并發(fā)安全萬能藥MERGE在概念上是原子的但它能不能真正防止重復(fù)創(chuàng)建取決于底層是否有一致性約束兜底。兩個并發(fā)事務(wù)同時執(zhí)行相同的 MERGE如果沒有唯一性約束依然可能創(chuàng)建出重復(fù)節(jié)點。所以凡是作為業(yè)務(wù)唯一標識的屬性盡量在數(shù)據(jù)庫層面建立唯一約束比如 Neo4j 的CREATE CONSTRAINT ... FOR (p:Person) REQUIRE p.email IS UNIQUE。語言層面的語義和存儲層面的約束要配套使用。6.4 避坑openCypher 規(guī)范管不到系統(tǒng)行為前面說過openCypher 只規(guī)范語言不系統(tǒng)行為。這意味著兩個都宣稱兼容 openCypher 的數(shù)據(jù)庫在并發(fā)控制、索引選擇、事務(wù)隔離上可以表現(xiàn)得完全不同。用 Kuzu 做嵌入式單機分析時查詢快如閃電換成某個分布式圖數(shù)據(jù)庫同一個查詢可能會因為跨節(jié)點通信和分布式事務(wù)成本慢上幾個數(shù)量級。選型時不能光看語法兼容一定要拿自己的業(yè)務(wù)查詢樣例做基準測試。6.5 我現(xiàn)在的學(xué)習(xí)路線建議如果你也想系統(tǒng)地學(xué)這套東西我建議分三層推進。第一層以 openCypher 為基線把 MATCH / RETURN / WHERE / CREATE / MERGE / WITH 這些核心子句吃透能把業(yè)務(wù)問題翻譯成圖模式。第二層關(guān)注 GQL 標準的公開材料重點看多圖、CATALOG、DROP PROPERTY 這些差異點建立標準視角。第三層用到具體數(shù)據(jù)庫時再精讀它的查詢語言文檔關(guān)注它標注的是兼容 openCypher vX還是支持 GQL 標準子集。最后分享一個我在實際項目里的小習(xí)慣。每次接入新的圖數(shù)據(jù)庫我都會先寫一組語言探針——二十來條針對語法邊界的探測查詢覆蓋 create、match、merge、變長路徑、多跳聚合、屬性過濾這幾個大類直接丟給數(shù)據(jù)庫跑輸出結(jié)果對比一下行為差異。這套探針比任何宣傳文檔都可靠。別指望 Cypher、openCypher、GQL 這三名字會自動變成同一種東西但把它們來龍去脈搞清之后你會發(fā)現(xiàn)紙面上的混亂其實很有條理每一次變化都是圖查詢語言從私有走向公共、從規(guī)范走向標準的一步。 圖數(shù)據(jù)庫查詢語言三坐標：Cypher、openCypher與GQL的演進與區(qū)別
最近整理圖數(shù)據(jù)庫的學(xué)習(xí)筆記發(fā)現(xiàn)一個特別容易讓人繞暈的問題Cypher、openCypher、GQL這三個詞經(jīng)常被混著用。有人以為 openCypher 是 Cypher 的新版本也有人以為 GQL 就是 GraphQL 的縮寫。其實三者代表了同一條查詢語言演進路徑上的三個坐標Neo4j 的廠商方言、社區(qū)推動的開放規(guī)范、ISO 發(fā)布的國際標準。這篇簡記想用一條線把三者的來歷、關(guān)系、差異和當前落地情況講清楚給剛接觸圖數(shù)據(jù)庫的開發(fā)者以及正在做圖數(shù)據(jù)庫選型的團隊提供一個可以參考的坐標系。如果你想把這篇文章當快速索引來用先看第 1 節(jié)理解 Cypher 的底層設(shè)計哲學(xué)第 2 節(jié)是語法心法第 3 節(jié)搞清 openCypher 的邊界第 4 節(jié)和第 5 節(jié)用于理解 GQL 帶來的變化以及三個概念的準確區(qū)分最后第 6 節(jié)是我自己踩過的坑和當前的學(xué)習(xí)路線可以直接跳到對應(yīng)小標題看。1. 從一條查詢說起Cypher 為什么讓人上癮1.1 SQL 在圖數(shù)據(jù)面前的無力感在 Cypher 出現(xiàn)以前圖數(shù)據(jù)查詢基本靠 SQL 硬寫或者靠各家的專用 API。問題是圖數(shù)據(jù)天然是節(jié)點 邊的結(jié)構(gòu)化網(wǎng)狀數(shù)據(jù)SQL 是面向二維表的集合操作表達圖遍歷時非常擰巴。舉一個最簡單的場景查Alice 認識的朋友里年齡大于 25 歲的人。在 SQL 里如果 friend 關(guān)系是一個表你需要自連接一次SELECT f.name FROM person p JOIN knows k ON p.id k.person_id JOIN person f ON k.friend_id f.id WHERE p.name Alice AND f.age 25;這還只是查一跳。如果要查Alice 的六度好友SQL 要么寫遞歸 CTE要么在應(yīng)用層反復(fù)循環(huán)查詢。遞歸 CTE 不是不能寫但可讀性、性能、維護性都很糟。圖數(shù)據(jù)最擅長的就是多跳遍歷而 SQL 在這里表現(xiàn)得像穿西裝游泳——不是不行是別扭。1.2 圖案即查詢的設(shè)計哲學(xué)Cypher 的核心創(chuàng)意是把查詢寫成一張圖的樣子。你直接在查詢里畫一個模式pattern告訴數(shù)據(jù)庫在所有數(shù)據(jù)中找出長得像這個模式的所有結(jié)構(gòu)。MATCH (alice:Person {name: Alice})-[:KNOWS]-(friend:Person) RETURN friend.name這一行就是在說找一個 Person它的 name 是 Alice通過 KNOWS 關(guān)系連到另一個 Person把這個人的 name 返回。 圓括號表示節(jié)點方括號表示關(guān)系箭頭表示方向。整個過程像在紙上畫社交關(guān)系圖一樣自然。這也是 Cypher 讓我上癮的根本原因它是聲明式語言你只描述要什么不描述怎么做執(zhí)行計劃由優(yōu)化器決定。對于非數(shù)據(jù)庫專業(yè)出身的人這種思維負擔(dān)小得多。你可以把一個復(fù)雜查詢的需求先畫成草圖再翻譯成 Cypher幾乎就是逐行謄寫。1.3 Cypher 不是唯一答案但它是重要的答案圖查詢語言其實有多個流派。Neo4j 在 2011 年前后開始做 Cypher后來 Oracle 也搞了 PGQL還有 TinkerPop/Gremlin 這種命令式遍歷語言。Gremlin 的寫法強調(diào)怎么走Cypher 強調(diào)要什么這是兩種完全不同的心智模型。Cypher 能流行起來除了 Neo4j 的生態(tài)加持它這種圖案即查詢的直觀性占了很大功勞。很多接觸圖數(shù)據(jù)庫的開發(fā)者第一個會寫的查詢就是順著一條關(guān)系找鄰居Cypher 把這個門檻降到了接近零。2. 模式匹配是心法別只記語法2.1 屬性圖模型的三件套要理解 Cypher先理解它操作的數(shù)據(jù)模型——屬性圖Property Graph。這個模型里只有三個要素節(jié)點Node、關(guān)系Relationship、屬性Property。節(jié)點可以打標簽Label表示類型比如 Person、Movie關(guān)系有且僅有一個類型Type比如 KNOWS、ACTED_IN節(jié)點和關(guān)系都可以掛鍵值對形式的屬性。關(guān)系是圖數(shù)據(jù)庫和關(guān)系型數(shù)據(jù)庫最大的分水嶺。在 SQL 里兩張表的關(guān)系是靠外鍵和 JOIN 臨時算出來的在圖數(shù)據(jù)庫里關(guān)系是存儲層面的一等公民物理上直接連著兩個節(jié)點。所以圖數(shù)據(jù)庫做多跳查詢不需要反復(fù)做昂貴的連接運算這是它擅長深度遍歷的根本原因。2.2 讀懂一行 MATCH拆解最常用的模式語法你可以把 MATCH 語句當成一個模板MATCH (p:Person {name: Alice})-[:KNOWS*1..2]-(f:Person)(p:Person)圓括號是節(jié)點模式。p是變量名后面可以用:Person是標簽過濾{name: Alice}是屬性過濾。-[:KNOWS*1..2]-方括號是關(guān)系模式。:KNOWS是關(guān)系類型*1..2是可變長度路徑表示沿著 KNOWS 走 1 到 2 跳箭頭表示方向。(f:Person)目標節(jié)點模式。整句話的意思從 name 為 Alice 的 Person 出發(fā)沿著 KNOWS 關(guān)系走 1 到 2 跳到達任何 Person 類型的節(jié)點并把這個節(jié)點綁定到變量f上。這里變量名、標簽、屬性條件都可以靈活增減。沒有方向時可以用--表示無向連接這在社交網(wǎng)絡(luò)互為好友的場景很實用。2.3 從業(yè)務(wù)問題到查詢的推演我們來看一個綜合例子。假設(shè)需求是找出 Alice 的好友中共同感興趣的 Topic 超過 3 個、且在最近一年還活躍的人。第一步先畫結(jié)構(gòu)。Alice 和好友們通過 KNOWS 相連好友通過 HAS_INTEREST 連到 Topic。畫出草圖后模式就出來了MATCH (alice:Person {name: Alice})-[:KNOWS]-(p:Person)-[:HAS_INTEREST]-(t:Topic) WITH p, count(t) AS interestCount WHERE interestCount 3 AND p.lastActive date(2024-01-01) RETURN p.name, interestCount ORDER BY interestCount DESC這里有個關(guān)鍵點WHERE不能直接跟在聚合函數(shù)count(t)后面需要先用WITH把聚合結(jié)果傳遞下去再用WHERE過濾。這就是 Cypher 和 SQL 的一個顯著差異——SQL 里聚合后過濾用的是HAVINGCypher 用WITH ... WHERE組合實現(xiàn)同樣的能力。善于用WITH做分段聚合是寫出清晰 Cypher 的前提。2.4 CREATE 與 MERGE創(chuàng)建和更新數(shù)據(jù)的兩種思路查詢語言總得有寫入能力。CREATE簡單粗暴每次執(zhí)行都會創(chuàng)建新的節(jié)點或關(guān)系CREATE (n:Person {name: Bob, age: 30})MERGE則是先查后建的原子操作語義上等價于存在就匹配不存在就創(chuàng)建MERGE (p:Person {email: bobexample.com}) ON CREATE SET p.createdAt datetime() ON MATCH SET p.lastSeen datetime()ON CREATE和ON MATCH是 MERGE 特有的分支分別處理節(jié)點被新建和節(jié)點已存在兩種情況。這個寫法非常適合做數(shù)據(jù)同步場景比如用戶表導(dǎo)入時用 email 作為唯一標識有則更新時間戳無則插入新記錄。但要注意MERGE 默認基于整個模式匹配不是只匹配模式中的某個節(jié)點。如果你只寫了MERGE (p:Person {email: ...})它匹配的是擁有該 email 屬性的 Person 節(jié)點這個完整結(jié)構(gòu)。3. openCypher從廠商方言到社區(qū)規(guī)范的中間態(tài)3.1 為什么 Neo4j 要把 Cypher 開放出來2015 年Neo4j 啟動了 openCypher 項目把 Cypher 的語法和語義規(guī)范、相關(guān)測試工具以 Apache 2.0 許可開源。很多人不理解這步棋數(shù)據(jù)庫廠商的語言專利通常是護城河Neo4j 為什么要自斷后路背后的邏輯其實很現(xiàn)實。圖數(shù)據(jù)庫市場當時開始出現(xiàn)多家競爭者每家都有自己的查詢語言。如果 Cypher 只屬于 Neo4j用戶選型時就會擔(dān)心被綁定如果讓 Cypher 成為多廠商共同支持的開放規(guī)范反而能降低用戶的顧慮而 Neo4j 作為原廠實現(xiàn)和生態(tài)最成熟的數(shù)據(jù)庫依然占據(jù)心智第一的位置。用術(shù)語說這相當于把 Cypher 從專有技術(shù)變成行業(yè)公共品。3.2 openCypher 項目里到底有什么openCypher 不是一門新語言它是 Cypher 語言本身的開放化包裝。項目主要包含三塊東西規(guī)范文檔描述 Cypher 的語法、表達式語義、模式匹配規(guī)則。TCKTechnology Compatibility Kit, 技術(shù)兼容性測試套件用 Gherkin 風(fēng)格的.feature腳本描述大量給定數(shù)據(jù) 執(zhí)行查詢 期望結(jié)果的測試場景數(shù)據(jù)庫實現(xiàn)可以拿這些場景驗證自己的兼容程度。開源的工具鏈包括詞法/語法解析器等方便其他數(shù)據(jù)庫復(fù)用解析層。TCK 的腳本長這樣簡化示意Feature: WHERE Scenario: Filter nodes by property Given an empty graph And having executed: CREATE (:Person {name: Alice, age: 30}) CREATE (:Person {name: Bob, age: 20}) When executing query: MATCH (p:Person) WHERE p.age 25 RETURN p.name Then the result should be: | p.name | | Alice |這套測試的價值在于它把兼容 openCypher從一句口號變成了可驗證的指標。數(shù)據(jù)庫廠商說支持 openCypher你可以拿 TCK 跑一遍通過率一目了然。3.3 誰在用 openCypher目前常見的 openCypher 兼容實現(xiàn)包括 Neo4j、Memgraph、Kuzu、Amazon Neptune 的兼容模式等。Kuzu 是嵌入式列式圖數(shù)據(jù)庫主打單機分析場景能在筆記本上直接跑語法和 Neo4j 非常接近Memgraph 是流式圖數(shù)據(jù)庫核心也接受 openCypher 查詢。它們的共同點是語法上盡量貼近 Cypher但系統(tǒng)層面各有各的存儲引擎、索引策略和事務(wù)模型。這一點必須強調(diào)openCypher 只規(guī)范了查詢語言這一層。它不規(guī)定存儲布局、不規(guī)定索引結(jié)構(gòu)、不規(guī)定事務(wù)隔離級別、不規(guī)定分布式行為。所以同一個查詢在五個數(shù)據(jù)庫里跑結(jié)果可能對但性能和并發(fā)表現(xiàn)可能天差地別。語言是普通話系統(tǒng)是各個方言地區(qū)的民間習(xí)俗兩者不能畫等號。3.4 openCypher 的天花板openCypher 的定位是開放規(guī)范但距離國際標準還有明顯距離。它沒有定義多圖操作、沒有標準化的目錄管理、也沒有嚴格的形式化語義。更重要的是openCypher 項目雖然開放主導(dǎo)權(quán)依然在 Neo4j 手里。對于一個想要嚴肅使用圖數(shù)據(jù)庫的大型組織來說廠商主導(dǎo)的開放規(guī)范并不能完全消除鎖定焦慮大家真正期待的是由 ISO 這樣的國際標準化組織來定義一門正式的圖查詢語言。這個期待最終等來了 GQL。4. GQLISO 國際標準把圖查詢語言送進新階段4.1 七年磨一劍2024 年 4 月ISO/IEC 39075:2024 正式發(fā)布GQLGraph Query Language成為國際標準。從 2017 年項目啟動算起前后經(jīng)歷了大約七年。它并非憑空設(shè)計而是充分吸收了 openCypher 的成熟語法、PGQL 等語言的合理設(shè)計最終由 ISO/IEC JTC 1/SC 32 委員會統(tǒng)一打磨成標準。GQL 的定位非常明確它是與 SQL 并列的、專為屬性圖數(shù)據(jù)模型設(shè)計的標準查詢語言。換句話說關(guān)系型數(shù)據(jù)庫有 SQL 做統(tǒng)一接口圖數(shù)據(jù)庫現(xiàn)在有了自己的官方標準語言。對用戶來說這是封閉生態(tài)走向開放生態(tài)的關(guān)鍵一步。4.2 GQL 和 SQL/PGQ 的關(guān)系很多人不知道SQL 標準族里其實還有一個 SQL/PGQISO/IEC 9075-16:2023Property Graph Queries。它允許在 SQL 語句中嵌入屬性圖模式匹配相當于給關(guān)系型數(shù)據(jù)庫加上了圖查詢擴展。GQL 是獨立完整的圖數(shù)據(jù)庫語言SQL/PGQ 是 SQL 內(nèi)部的一個補充部分兩者共享屬性圖的數(shù)據(jù)模型認知。這個關(guān)系值得多說一句它意味著圖查詢的思想正在反哺傳統(tǒng)數(shù)據(jù)庫。你可以用 SQL 寫圖模式也可以用 GQL 操作純圖數(shù)據(jù)庫未來關(guān)系型和圖數(shù)據(jù)之間的邊界會越來越靈活。這對做數(shù)據(jù)架構(gòu)的人來說是一個重要的趨勢信號。4.3 GQL 從 Cypher 繼承了什么又改了什么打開 GQL 標準你會發(fā)現(xiàn)Cypher 的味道非常濃。節(jié)點圓括號、關(guān)系方括號、MATCH 關(guān)鍵字、變量綁定、模式匹配的思維這些核心設(shè)計被完整保留。GQL 相當于把 Cypher 的骨架接收下來然后按照國際標準的嚴格要求重新定義了一套語義。差異也很明顯最直觀的幾個多圖支持。openCypher 默認在一個圖里操作GQL 用USE GRAPH顯式進入某個圖。屬性操作。openCypher 刪除屬性用REMOVEGQL 標準里用DROP PROPERTY。語句結(jié)束。GQL 語句以分號結(jié)束標準味十足openCypher 對分號沒有強制要求。圖目錄。GQL 標準定義了 CATALOG 和圖目錄操作openCypher 沒有這個概念。寫一個 GQL 風(fēng)格的示意查詢USE GRAPH social; MATCH (p:Person {name: Alice})-[:FRIEND]-(f:Person) WHERE f.age 25 RETURN f.name AS name;看起來和 Cypher 幾乎一樣但多了圖切換和分號。所有 GQL 的細節(jié)我建議以正式標準文本和各數(shù)據(jù)庫最新文檔為準——標準落地初期廠商支持度一定是參差不齊的。4.4 廠商跟進到什么程度了GQL 發(fā)布后Neo4j 官方明確表態(tài) Cypher 會持續(xù)演進以兼容 GQL這等于給現(xiàn)有 Ne4oj 用戶吃了一顆定心丸你的 Cypher 知識不會作廢。新興的 Kuzu、Memgraph 等也一直在跟進標準兼容。但現(xiàn)實地說標準剛發(fā)布兩三年內(nèi)市面上絕大多數(shù)圖數(shù)據(jù)庫還是以兼容 openCypher 為主GQL 更多是作為未來方向存在。做技術(shù)選型時可以優(yōu)先選擇明確表態(tài)向 GQL 演進的實現(xiàn)同時不指望眼下所有語法都對齊標準。4.5 一個常見的混淆GQL 不是 GraphQL這個名字的坑我踩過不止一次。GQL 是圖數(shù)據(jù)庫查詢語言GraphQL 是 Meta 提出的 API 查詢語言跑在 HTTP 層服務(wù)端和客戶端之間用。前者操作數(shù)據(jù)引擎內(nèi)部的數(shù)據(jù)后者操作業(yè)務(wù)接口的資源圖。兩者除了名字縮寫接近技術(shù)棧和應(yīng)用場景幾乎沒有交集。搜索資料時搜 GQL 很容易跳出 GraphQL 的內(nèi)容記得在關(guān)鍵詞里加上 graph database 或 ISO 39075 過濾。5. 一個表看懂三者關(guān)系再細看語法差異5.1 三者定位對比名稱本質(zhì)發(fā)起/管理機構(gòu)狀態(tài)典型實現(xiàn)CypherNeo4j 的圖查詢語言Neo4j隨 Neo4j 版本演進非獨立標準Neo4j DatabaseopenCypherCypher 的開放規(guī)范openCypher 項目Neo4j 主導(dǎo)面向社區(qū)的開放規(guī)范非 ISO 標準Neo4j、Kuzu、Memgraph、Amazon NeptuneGQL圖查詢語言國際標準ISO/IEC JTC 1/SC 32已發(fā)布ISO/IEC 39075:2024各廠商正在實現(xiàn)/演進中演進路徑其實是線性的Cypher 是源頭openCypher 把源頭開放成規(guī)范GQL 把規(guī)范升格為國際標準。三者不是三個平行的選項而是一條時間軸上的三個階段。5.2 語法差異速查表差異點openCypherGQL 標準刪除屬性REMOVE n.propDROP PROPERTY n.prop多圖切換通常固定單圖USE GRAPH graphName語句結(jié)束分號非必需以分號結(jié)束圖目錄無標準概念有 CATALOG 概念標簽表達式有限支持完整支持這些是標準層面的差異。具體到某個數(shù)據(jù)庫廠商會在標準和自己原有方言之間做取舍實際行為的差異可能比表里列的更大。我的建議是不要把 Cypher 當作統(tǒng)一語法去背把它當作一種圖查詢思維去學(xué)落地時再逐庫核對細節(jié)。5.3 遷移和兼容性驗證的實操思路如果你正在做數(shù)據(jù)庫遷移或者計劃用多個圖數(shù)據(jù)庫這幾點可以直接抄把現(xiàn)有查詢清單里的REMOVE、函數(shù)大小寫、正則函數(shù)、CALL 子查詢等逐一核對這些都是方言差異的重災(zāi)區(qū)。有條件時用 openCypher 的 TCK 對目標數(shù)據(jù)庫跑一遍兼容性測試通過率比廠商宣傳頁靠譜得多。寫查詢時盡量使用公共子集MATCH、WHERE、RETURN、CREATE、MERGE、可變長度路徑這些核心語法在絕大多數(shù)兼容實現(xiàn)里行為一致。避免依賴某個數(shù)據(jù)庫特有的高級功能比如某一家的過程調(diào)用語法或存儲過程機制否則遷移時你會被這些甜蜜的鎖卡住。6. 實踐中的幾個體會和避坑建議6.1 先畫出圖再寫模式我見過最多的新手錯誤不是語法寫錯而是模式本身畫錯了。方向?qū)懛础㈥P(guān)系類型拼錯、把本可以在屬性條件里過濾的內(nèi)容放到 WHERE 里這些問題的根源都是沒有先在紙上畫出節(jié)點和關(guān)系。我的習(xí)慣是任何超過兩跳的查詢先花一分鐘畫草圖再照著草圖翻譯成 Cypher。草圖對了代碼基本就對了七成。6.2 避坑變長路徑是性能陷阱-[:KNOWS*1..6]-這種寫法看起來方便但在稠密圖上會帶來指數(shù)級的遍歷開銷。實際使用時一定要給跳數(shù)設(shè)上限并且盡量結(jié)合方向、標簽和屬性條件做剪枝。如果查詢只需要結(jié)果集的一部分再加上 LIMIT避免引擎為了取一條記錄把半個圖都遍歷一遍。圖數(shù)據(jù)庫再快也扛不住失控的路徑爆炸。6.3 避坑MERGE 不是并發(fā)安全萬能藥MERGE在概念上是原子的但它能不能真正防止重復(fù)創(chuàng)建取決于底層是否有一致性約束兜底。兩個并發(fā)事務(wù)同時執(zhí)行相同的 MERGE如果沒有唯一性約束依然可能創(chuàng)建出重復(fù)節(jié)點。所以凡是作為業(yè)務(wù)唯一標識的屬性盡量在數(shù)據(jù)庫層面建立唯一約束比如 Neo4j 的CREATE CONSTRAINT ... FOR (p:Person) REQUIRE p.email IS UNIQUE。語言層面的語義和存儲層面的約束要配套使用。6.4 避坑openCypher 規(guī)范管不到系統(tǒng)行為前面說過openCypher 只規(guī)范語言不系統(tǒng)行為。這意味著兩個都宣稱兼容 openCypher 的數(shù)據(jù)庫在并發(fā)控制、索引選擇、事務(wù)隔離上可以表現(xiàn)得完全不同。用 Kuzu 做嵌入式單機分析時查詢快如閃電換成某個分布式圖數(shù)據(jù)庫同一個查詢可能會因為跨節(jié)點通信和分布式事務(wù)成本慢上幾個數(shù)量級。選型時不能光看語法兼容一定要拿自己的業(yè)務(wù)查詢樣例做基準測試。6.5 我現(xiàn)在的學(xué)習(xí)路線建議如果你也想系統(tǒng)地學(xué)這套東西我建議分三層推進。第一層以 openCypher 為基線把 MATCH / RETURN / WHERE / CREATE / MERGE / WITH 這些核心子句吃透能把業(yè)務(wù)問題翻譯成圖模式。第二層關(guān)注 GQL 標準的公開材料重點看多圖、CATALOG、DROP PROPERTY 這些差異點建立標準視角。第三層用到具體數(shù)據(jù)庫時再精讀它的查詢語言文檔關(guān)注它標注的是兼容 openCypher vX還是支持 GQL 標準子集。最后分享一個我在實際項目里的小習(xí)慣。每次接入新的圖數(shù)據(jù)庫我都會先寫一組語言探針——二十來條針對語法邊界的探測查詢覆蓋 create、match、merge、變長路徑、多跳聚合、屬性過濾這幾個大類直接丟給數(shù)據(jù)庫跑輸出結(jié)果對比一下行為差異。這套探針比任何宣傳文檔都可靠。別指望 Cypher、openCypher、GQL 這三名字會自動變成同一種東西但把它們來龍去脈搞清之后你會發(fā)現(xiàn)紙面上的混亂其實很有條理每一次變化都是圖查詢語言從私有走向公共、從規(guī)范走向標準的一步。