Nebula 架構剖析系列（二）圖數據庫的查詢引擎設計

摘要

上文（存儲篇）說到數據庫重要的兩部分爲存儲和計算，本篇內容爲你解讀圖數據庫 Nebula 在查詢引擎 Query Engine 方面的設計實踐。

在 Nebula 中，Query Engine 是用來處理 Nebula 查詢語言語句（nGQL）。本篇文章將帶你瞭解 Nebula Query Engine 的架構。

上圖爲查詢引擎的架構圖，若是你對 SQL 的執行引擎比較熟悉，那麼對上圖必定不會陌生。Nebula 的 Query Engine 架構圖和現代 SQL 的執行引擎相似，只是在查詢語言解析器和具體的執行計劃有所區別。

Session Manager

Nebula 權限管理採用基於角色的權限控制（Role Based Access Control）。客戶端第一次鏈接到 Query Engine 時需做認證，當認證成功以後 Query Engine 會建立一個新 session，並將該 session ID 返回給客戶端。全部的 session 統一由 Session Manger 管理。session 會記錄當前 graph space 信息及對該 space 的權限。此外，session 還會記錄一些會話相關的配置信息，並臨時保存同一 session 內的跨多個請求的一些信息。

客戶端鏈接結束以後 session 會關閉，或者若是長時間沒通訊會切爲空閒狀態。這個空閒時長是能夠配置的。
客戶端的每一個請求都必須帶上此 session ID，不然 Query Engine 會拒絕此請求。

Storage Engine 無論理 session，Query Engine 在訪問存儲引擎時，會帶上 session 信息。

Parser

Query Engine 解析來自客戶端的 nGQL 語句，分析器(parser)主要基於著名的 flex / bison 工具集。字典文件（lexicon）和語法規則（grammar）在 Nebula 源代碼的 src/parser  目錄下。設計上，nGQL 的語法很是接近 SQL，目的是下降學習成本。 圖數據庫目前沒有統一的查詢語言國際標準，一旦 ISO/IEC 的圖查詢語言（GQL）委員會發布 GQL 國際標準，nGQL 會盡快去實現兼容。
Parser 構建產出的抽象語法樹（Abstrac Syntax Tree，簡稱 AST）會交給下一模塊：Execution Planner。

Execution Planner

執行計劃器（Execution Planner）負責將抽象樹 AST 解析成一系列執行動做 action（可執行計劃）。action 爲最小可執行單元。例如，典型的 action 能夠是獲取某個節點的全部鄰節點，或者得到某條邊的屬性，或基於特定過濾條件篩選節點或邊。當抽象樹 AST 被轉換成執行計劃時，全部 ID 信息會被抽取出來以便執行計劃的複用。這些 ID 信息會放置在當前請求 context 中，context 也會保存變量和中間結果。

Optimization

經由 Execution Planner 產生的執行計劃會交給執行優化框架 Optimization，優化框架中註冊有多個 Optimizer。Optimizer 會依次被調用對執行計劃進行優化，這樣每一個 Optimizer都有機會修改（優化）執行計劃。最後，優化過的執行計劃可能和原始執行計劃徹底不同，可是優化後的執行結果必須和原始執行計劃的結果同樣的。

Execution

Query Engine 最後一步是去執行優化後的執行計劃，這步是執行框架（Execution Framework）完成的。執行層的每一個執行器一次只處理一個執行計劃，計劃中的 action 會挨個一一執行。執行器也會一些有針對性的局部優化，好比：決定是否併發執行。針對不一樣的 action所需數據和信息，執行器須要經由 meta service 與storage engine的客戶端與他們通訊。

最後，若是你想嘗試編譯一下 Nebula 源代碼可參考以下方式：

有問題請在 GitHub（GitHub 地址：https://github.com/vesoft-inc/nebula） 或者微信公衆號上留言，也能夠添加 Nebula 小助手微信號：NebulaGraphbot 爲好友反饋問題~

推薦閱讀

• Nebula 架構剖析系列（零）圖數據庫的總體架構設計
• Nebula 架構剖析系列（一）圖數據庫的存儲設計