摘要
上文（存儲篇）說到資料庫重要的兩部分為存儲和計算，本篇内容為你解讀圖資料庫 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 為好友回報問題~