Vol.03 nMeetup | 圖數據庫綜述與 Nebula 在圖數據庫設計的實踐

Nebula Graph：一個開源的分佈式圖數據庫。做爲惟一可以存儲萬億個帶屬性的節點和邊的在線圖數據庫，Nebula Graph 不只可以在高併發場景下知足毫秒級的低時延查詢要求，還可以實現服務高可用且保障數據安全性。

第三期 nMeetup( nMeetup 全稱：Nebula Graph Meetup，爲由開源的分佈式圖數據庫 Nebula Graph 發起的面向圖數據庫愛好者的線下沙龍) 活動於 2019 年 8 月 3 日在上海陸家嘴的匯豐銀行大樓舉辦，我司 CEO -- Sherman 在活動中發表《 Nebula Graph Internals 》主題演講 。本篇文章是根據這次演講所整理出的技術乾貨，全文閱讀須要 30 分鐘，咱們一塊兒打開圖數據庫的知識大門吧~

你們好，很是感謝你們今天可以來咱們這個線下沙龍，天氣很熱，剛又下了暴雨，說明你們對圖數據庫的熱情要比夏天溫度要高。今天咱們準備了幾個 topic，一個就是介紹一下咱們產品——Nebula 的一些設計思路，今天不講介紹性東西，主要講 Nebula 內部的思考——爲何會去作 Nebula，怎麼樣去作，以及爲何會採起這樣的設計思路。

這個就是 Nebula。先從 overview 介紹圖數據庫究竟是個什麼東西，而後講咱們對圖數據庫的一些思考。最後具體介紹兩個模塊， Nebula 的 Query Service 和 Storage Service。後面兩部分會稍微偏技術一些，在這個過程中若是你們遇到什麼問題，歡迎隨時提出。

圖數據庫是什麼

圖領域的 OLAP & OLTP 場景

對於圖計算或者圖數據庫自己咱們是這麼理解的，它跟傳統數據庫很相似，也分爲 OLAP 和 OLTP 兩個方向。

上圖中下面這根軸表示數據對查詢時效性的要求，OLAP 更偏向於作離線分析，OLTP 更偏向於線上處理。咱們認爲圖領域也能夠這麼劃分。

首先在 OLAP 這個領域，咱們稱爲圖計算框架，這些圖計算框架的主要目的，是作分析。基於圖的結構的分析——這裏圖代指一個關係網絡。總體上這個分析比較相似於傳統數據庫的 OLAP。但一個主要特色就是基於圖結構的迭代算法，這個在傳統數據庫上是沒有的。最典型的算法是谷歌 PageRank，經過一些不斷的迭代計算，來算網頁的相關度，還有很是常見的 LPA 算法，使用的也很是多。

若是咱們繼續沿着這個線向右邊延伸,能夠看到一個叫作 Graph Stream 的領域，這個領域至關於圖的基礎計算跟流式計算相結合的產物。你們知道關係網絡並非單單一個靜態結構，而是會在業務中不斷地發生變化：多是圖的結構，或者圖上的屬性發生變化，當圖結構和屬性發生變化時，咱們但願去作一些計算，這裏的計算多是一種觸發的計算或判斷——例如在變化過程中是否是動態地在圖上造成一個閉環，或者動態地判斷圖上是否造成一個隔離子圖等等。Trigger（觸發）的話，通常是經過事件來驅動這類計算。對時效性的響應固然是越高越好，但每每響應時間通常是在秒級左右。

那麼再往軸上右邊這個方向看，是線上的在線響應的系統。你們知道這類系統的特色是對延時要求很是高。能夠想象若是在線上作交易的時候，在這個交易瞬間，須要到圖上去拿一些信息，固然不但願要花費秒級。通常響應時間都是在十幾、二十毫秒這樣一個範圍。能夠看到最右邊的場景和要求跟左邊的是徹底不同的，是一種典型的 OLTP 場景。在這種場景裏面，一般是對子圖的計算或者遍歷——這個和左邊對全圖作計算是徹底不同的：好比說從幾個點出發，獲得周邊三、4度的鄰居構成一個子圖，再基於這個子圖進行計算，根據計算的結果再繼續作一些圖遍歷。因此咱們把這種場景稱爲圖數據庫。咱們如今主要研發內容主要面向OLTP這類場景。因此說今天的一些想法和講的內容，都是跟這塊相關。

圖數據庫及其餘數據庫的關注度增加趨勢

這張圖是從 DB-Engines.com 上截下來的，反應了從 2013 年到 2019 年 7 月，全部類型數據庫的趨勢。這個趨勢是怎麼計算出來的？DB-Engines 經過到各大網站上去爬取內容，查看全部用戶，包括開發人員和業務人員的狀況下統計某類數據庫被說起的次數將其轉化爲分數，分數越高，表示這種類型的數據庫的關注度越高。因此說這是一個關注度的趨勢。

最底下這條紅線是關係型數據庫，在關係型數據庫之上有各種數據庫，好比 Key-Value型、文檔型、RDF 等。最上面的綠線就是圖數據庫。

能夠看到在過去六年多的時間裏，圖數據庫的整個趨勢，或者說它的影響力大概增加了十倍。

圖數據存儲計算什麼數據

今天咱們談數據庫確定離不開數據，由於數據庫只是一個載體，一個存儲和計算的載體，它裏面的數據究竟是什麼呢？就是咱們平時說的圖。這裏列出了幾個目前爲止比較常見的多對多的關係數據。

圖數據的常見多對多關係數據庫場景

第一個 Social Network（社交網路），好比說微信或者 Facebook 好友關係等等。這個網絡有幾十億個用戶，幾千億到幾萬億的鏈接關係。第二個 Business Relation，商業的關係，常見的有兩種網絡：

• 金融與資金關係網絡：一種好比說在支付網絡裏面，帳戶和帳戶之間的支付關係或者轉帳關係，這個是比較典型的金融與資金關係網絡；
• 公司關係：在 business 裏面，好比說公司控股關係，法人關係等等，它也是一個很是龐大的網絡。基於工商總局數據，有許多公司耕耘在這一領域。這個網絡的節點規模也有億到十億的級別，大概幾百億條邊，若是算上交易轉帳數據那就很是龐大了。

第三個是知識圖譜，也是最近比較熱的一個領域。在各個垂直領域會有不一樣的知識點，且知識點之間有相關性。部分垂直領域知識的網絡至少有幾百億條關係，好比銀行、公安還有醫學領域。

最後就是這幾年熱門的 IoT（Internet of Things）領域，隨着近年智能設備的增加，預計之後 IoT 設備數量會遠超過人口數量，如今咱們每一個人身邊佩帶的智能設備已不止一個，好比說智能手機、智能手錶，它們之間組成一個龐大的關係網絡，雖然具體應用有待後續開發，但這個領域在將來會有很大的應用空間。

圖數據庫的應用場景

剛纔提到的是常見的關係網絡，這裏是咱們思考的一些應用場景。

第一個應用場景是基於社交關係網絡的社交推薦，好比：拼多多的商品推薦，抖音的視頻推薦，頭條的內容推薦，均可以基於已有的好友關係來推薦。

第二個就是風控領域，風控實際上是銀行保險業的核心話題。傳統的風控是基於規則——基於規則的風控手段，相對已經比較成熟了，通常是拿直接的交易對手來作規則判斷。但如今風控有個新趨勢，就是經過關聯關係作拓展，好比交易對手等相關的周邊帳號，經過這些關係來判斷這筆交易或者轉帳的風險。從規則向基於關聯關係的風控演進，這個趨勢比較明顯。

關於知識圖譜這一塊，和 Google 比較有關，谷歌在 2003，2004 年時候，其實已經在慢慢把它的 search engine，從反向索引轉向轉到了知識圖譜。若是隻有倒排表，好比說要查「特朗普」今年幾歲，這個是很難作到的，由於已有的信息是他的生日是哪年。

這幾年機器學習和 AI 領域發展很是快，你們知道就機器學習或者模型訓練範疇來講，平時用大量數據去訓練模型，其實歸根結底是對大量數據彙總或者說統計性的結果。最近一兩年，你們發現光有統計性結果不夠，數據和數據之間的關係也應體如今模型裏，因此開始將基於圖的數據關係加入到模型訓練，這個就是學術界很是流行的 Graph Embedding，把圖的結構引入到模型訓練裏面。

在健康和醫療領域，患者的過往病史、服藥史、醫生的處方還存在紙質文檔的狀況，一些醫療類公司經過語音和圖像將文檔數字化，再用 NLP 把關鍵信息提取出來。根據關鍵信息，好比：血壓、用藥等等構造一棵大的決策樹或者醫療知識圖譜。這塊也是比較新的應用。

區塊鏈的應用其實比較容易理解，區塊鏈自己雖說是鏈，但有不少分支結構，當分支交織後也就構成一個網絡。舉個簡單例子，A 某想經過比特幣洗錢，經常使用方法是經過多個帳號，幾回轉帳後，資金經過數字貨幣造成一個閉環，而這個方法是能夠經過圖進行洗錢防範。

最後一塊是公共安全領域，好比，某些犯罪是團伙做案，那麼追蹤團伙中某我的的行爲軌跡，好比：交通工具、酒店等等就可標識出整個團伙的特徵。某個攝像頭和某個嫌疑人在某個時間構建起來關聯關係，下一個時刻，另一個攝像頭和另一個嫌疑人也創建了關聯。這個圖不是靜態的，它是時序的。 這些就是一些已經看到的圖的應用領域。

圖數據庫面臨的挑戰

回到圖數據庫，作圖數據庫到底有哪些挑戰。和全部的 OLTP 系統同樣：

第一個挑戰就是低延時。咱們不但願一次查詢，要幾秒鐘甚至幾分鐘才能產生結果。好比說風控場景，在線轉帳的時候，我要判斷這筆交易是否有風險，可能整個時間只有一百毫秒，留給風控判斷的時間只有幾十毫秒。不可能轉帳完才發現對方帳戶已經被標黑了，或者這筆交易實際上是在套null現。

第二個挑戰是高吞吐，如今熱門的 APP，好比抖音或者頭條，平常訪問的併發量是很是高的，峯值可能幾十萬 QPS，DB 要能抗的住。

第三個挑戰是數據量激增，數據量的增長速度快於硬件特別是硬盤的增加速度，這個給 DB 帶來了很大的挑戰。你們可能用過一些單機版的圖數據庫，剛開始用以爲不錯，能知足需求。但一兩年後，發現數據量增長太快，單機版已經徹底知足不了需求，這時總不能把業務流控吧。

咱們遇到過一個圖 case，有超過一千億個節點，一萬億條邊，點和邊上都還有屬性，整個圖的數據量超過上百T。能夠預計下，將來幾年數據量的增加速度會遠遠快於摩爾定理的速度，因此單機版數據庫確定搞不定業務需求，這對圖數據庫開發是一個很大的挑戰。

第四個挑戰是分析的複雜性，固然這裏分析指的是 OLTP 層面的。由於圖數據庫還比較新，你們剛開始使用的時候會比較簡單，例如只作一些 K度拓展。可是隨着使用者的理解愈來愈深，就會提出更多愈來愈複雜的需求。例如在圖遍歷過程當中過濾、統計、排序、循環等等，再根據這些計算結果繼續圖遍歷。因此說業務需求愈來愈複雜。這就要求圖數據庫提供的功能愈來愈多。

最後一個挑戰是關於數據一致性——固然還有不少其餘挑戰，這裏沒有所有羅列。前幾年你們對於圖數據庫的使用方法更像使用二級索引，把較大的數據放在另外的存儲組件，好比 HBase 將關聯關係放在圖數據庫裏，將圖數據庫只做爲圖結構索引來加速。但像剛纔說的，業務愈來愈複雜，對響應時間要求愈來愈高，原先的架構除了不方便，性能上也有很大挑戰。好比，須要對屬性作過濾時，要從 HBase 讀取出太多數據，各類序列化、過濾操做都很慢。這樣就產生了新需求——將這些數據直接存儲在圖數據庫裏，天然 ACID 的需求也都有了。

圖數據庫模型：原生圖數據庫 vs 多模數據庫

說完技術挑戰，還有個概念我想特別澄清下。你們若是網上搜圖數據庫，可能有 20 個自稱圖數據庫的產品。我認爲這些產品能夠分紅兩類，一種就是原生的，還有一類是多模的。

對於圖原生的產品，在設計時考慮了圖數據的特性，存儲、計算引擎都是基於圖的特色作了特別設計和優化。

而對於多模的產品，就有不少，好比說 ArangoDB 或者 Orientdb，還有一些雲廠商的服務。它們的底層是一個表或文檔型數據庫，在上層增長圖的服務。對於這類多模數據庫，圖服務層所作的操做，好比：遍歷、寫入，最終將被映射到下面的存儲層，成爲一系列表和文檔的操做。因此它最大的問題是整個系統並非爲了圖這種多對多的結構特色設計，一旦數據量或者併發量增大以後，問題就比較明顯。咱們最近碰到一個比較典型的 case，客戶使用多模 DB，在數據量很小時還比較方便，但當數據量大到必定程度，作二跳三跳查詢時 touch 的數據很是多，而多模 DB 底層是關係型數據庫，全部關係最終要映射到關係型數據庫的 join  操做，作三四層的 join ，性能會很是的差。

圖數據庫——Nebula Graph：一個開源的分佈式圖數據庫

上面是咱們對行業的一些思考。這裏是咱們在作的圖數據庫，它是一個開源的分佈式的項目——Nebula Graph。

存儲設計

這裏我想說下咱們在設計 Nebula 時候的一些思考，爲何會這樣設計？

剛剛說到過技術挑戰中數據量迅速膨脹，業務邏輯愈加複雜，像這樣的開發挑戰，Nebula 是如何解決的。

Nebula 在設計存儲時，採用 share-nothing 的分佈式架構，本質上存儲節點間沒有數據共享，也就是整個分佈式結構無中心節點。這樣的好處在於，第一，容易作水平拓展；第二，即便部分機器 Crash，經過數據強一致性—— Raft 協議能保證整個系統的可用性，不會丟失數據。

由於業務會愈加複雜，因此 Nebula 支持多種存儲引擎。有的業務數據量不大但對查詢的實時性要求高，Nebula 支持純內存式的存儲引擎；數據量大且查詢併發量也大的狀況下，Nebula 支持使用內存加 SSD 模式。固然 Nebula 也支持第三方存儲引擎，好比，HBase，考慮到這樣使用存在的主要問題是性能不佳，咱們建議用在一些對性能要求不是很高的場景。

第三個設計就是把存儲和計算這兩層分開了——也就是「存儲計算分離」。這樣的設計有幾個明顯的好處。全部數據庫在計算層一般都是無狀態的，CPU intensive，當 CPU 的計算力不夠的時候，容易彈性擴容、縮容，而對於存儲層而言，涉及到數據的搬遷狀況要複雜些。因此當存儲計算分離後，計算層和存儲層能夠根據各自的狀況彈性調整。

至於數據強一致這個挑戰，有主要分兩個方面，一個是關於數據的強一致，就是多數派協議——Nebula 如今使用的 Raft 協議，經過多副本的方式來實現強一致。另外個是分佈式的事物務 Transaction，它來保證要向多臺機器寫入一批相互依賴數據的正確性，這個和 NewSQL 裏面的概念是很是相似的。

計算設計

剛剛是咱們對存儲引擎的一些思考，這裏是咱們對計算引擎的思考。

前面提到的一個技術挑戰是低延時、高併發，Nebula 整個的核心代碼都是 C++ 寫的，這樣保證了執行效率。其次，作了不少並行和異步執行的優化。第三個是計算下推。在分佈式系統裏面，硬件上網絡對總體性能的影響最大，因此數據搬遷是一個很低效的動做。有些開源圖數據庫產品，好比 JanusGraph，它的存儲層在 HBase，上面有個單獨的計算層，當計算層須要數據的時候，會到 HBase 裏面拉回大量的數據，再作過濾和計算。舉個例子，1 萬條數據裏面最終過濾出 100 條，那至關於 99% 的網絡傳輸都浪費了。因此 Nebula 的設計方案是移動計算，而不是數據，計算下推到存儲層，像前面這個例子，直接在存儲層作完過濾再回傳計算層，這樣能夠有 100 倍的加速。

第二，若是你們接觸過圖數據庫領域的一些產品，會發現圖數據庫這領域，相比關係型數據庫有個很大的問題——沒有通用的標準。關係型領域的標準在差很少 30 年前已制定，但圖數據庫這個領域各家產品的語言相差很大。那麼針對這個問題 Nebula 是怎麼解決？第一儘可能貼近 SQL，哪怕你沒有學過 Nebula 語言，你也能猜出語句的做用。所以 Nebula 的查詢語言和 SQL 很像，爲描述性語言，而不是命令式語言。第二個是過去幾年咱們作圖數據庫領域的經驗積累，就是 No-embedding（無嵌套）。SQL 是容許 embedding 的，但嵌套有個問題——當查詢語句過長時，語句難讀，由於 SQL 語句需從內向外讀，語序正好跟人的理解相反，由於人比較習慣從前日後來理解。因此Nebula 把嵌套語句寫成從前日後的方式，做爲替代，提供 Shell 管道這樣的方式，即前面一條命令的輸出做爲後一條命令的輸入。這樣寫出來的語句比較容易理解，寫了一個上百行的 query 你就會發現從前日後讀比從中間開始讀要易於理解。 第三，和傳統數據庫相比，圖的計算不光是 CRUD，更重要是基於圖結構的算法，加上新的圖算法不停地涌現，Nebula 怎麼 keep up？

• 將部分主要算法 build in 到查詢引擎裏；
• 經過支持 UDF（user-defined function，用戶定義函數），用戶可把業務相關邏輯寫成程序或者函數，避免寫重複 query；
• 查詢語言的編程能力：Nebula 的查詢語言 nGQL 是 Programmable。

架構設計

Overview 這一章節的最後內容是 Nebula 的架構。上圖虛線把存儲和計算一分爲二，上面是整個計算層，每一臺機器或者虛擬機是一個節點，它是無狀態的，相互之間沒有任何通信，因此計算層要作擴縮容很是容易。 下面是存儲層，有數據存儲因此是有狀態的。存儲層還能夠細分，第一層是 Storage Service，從計算層傳來的請求帶有圖語義信息，好比：鄰居點、取 property，Storage Service 的做用是把圖語義變成了 key-value 語義交給下層的 KV-store，在 Storage Service 和 KV-store 之間是一層分佈式 Raft 協議。

圖的右邊是 Meta Service，這個模塊有點相似 HDFS 的 NameNode，主要提供兩個功能，一個是各類元信息，好比 schema，還有一個是指揮存儲擴容。你們都知道存儲擴容是個很是複雜的過程，在不影響在線業務地狀況下一步步增長機器，數據也要一點點搬遷，這個時候就須要有個中心指揮。另外 Meta Service 自己也是經過 Raft 來保證高可用的。

圖數據庫 Nebula 的查詢引擎設計

上面就是 Nebula 的整體介紹，下面這個部分介紹查詢引擎的設計細節。

查詢語言——nGQL

先來介紹下 Nebula 的查詢語言 nGQL。nGQL 的子查詢有三種組合方式：管道、分號和變量。 nGQL 支持實時的增刪改、圖遍歷、屬性遍歷，也支持對屬性先作 index 再遍歷。此外，你還能夠對圖上的路徑寫個正則表達式，查找全部知足這個條件的圖路徑。

查詢引擎架構

再來介紹下查詢引擎的架構，從查詢引擎的架構圖上來看，和數據庫相似：從客戶端發起一個請求(statement)，而後 Parser 作詞法分析，以後把分析結果傳給執行計劃（Execution Planner），執行計劃會基於這個語句的特色，交給優化器(Optimizer)進行優化，最後將結果交給執行引擎(Execution Engine)去執行。執行引擎會經過 MetaService 獲取點和邊的 schema，經過存儲引擎層獲取點和邊的數據。

執行計劃案例

這裏有個小例子展現了執行計劃，下方就是一條語句。首先 use myspace，這裏的 space 和數據庫裏的 database 是一個概念，每一個 space 是一個物理隔離的空間，可用來區分敏感數據和非敏感數據，或者說作多租戶的支持。分號後面是下一語句—— INSERT VERTEX 插入節點， GO 是網絡拓展， | 爲 Nebula 的管道用法，這條語句的意思是將第一條 Go 的結果傳給第二條 Go，而後再傳給第三條，即往外走三步遍歷，最後把整個結果作求和運算。這是一種常見的寫法，Nebula 還支持其餘寫法。

這樣語句的執行計劃就會變成上圖右邊的語法執行樹。這裏每一個節點，都叫作Executor（語法執行者），語句中的分號對應執行 SequentialExecutor ，Go 對應執行 GoExecutor ，"|"（管道）對應執行 PipeExecutor 。

執行優化

這一頁介紹執行優化。在順序執行過程當中優化器會判斷當前語句是否存在相互依賴關係，在沒有相互依賴時，執行引擎可並行執行從而加速整個執行過程，下降執行延時。流水線優化，跟處理器 CPU 的流水線優化相似。上面「GO … | GO … | GO … 」例子中，表面上第一個 GO 執行完畢後再把結果發給第二個 GO 執行，但實際執行時，第一個 GO 部分結果出來以後，就能夠先傳給下一個GO，不須要等所有結果拿到以後再傳給下一步，這對提高時延效果明顯。固然不是全部狀況都能這樣優化，裏面有不少工做要作。前面已提過計算下沉的優化，即過濾的操做盡可能放在存儲層，節省經過網絡傳輸的數據量。JIT 優化在數據庫裏已經比較流行，把一條 query 變成代碼直接去執行，這樣執行效率會更高。

圖數據庫 Nebula 的存儲引擎設計

剛纔介紹了查詢引擎，下面介紹存儲引擎。

存儲架構

這張圖實際上是前面總體架構圖的下面部分。縱向可理解爲一臺機器，每臺機器最上面是 Storage service，綠色的桶是數據存儲，數據被切分紅不少個分片 partition，3 臺機器上同 id 的 partition 組成一個 group，每一個 group 內用 Raft 協議實現多副本一致性。Partition 的數據最後落在 Store Engine 上，Nebula 默認 Store Engine 是 RocksDB。這裏再提一下，partition 是個邏輯概念，partition 數量多少不會額外增長內存，因此通常把 partition 數量設置成遠大於機器的數量。

Schema

這一頁是 schema，講的是怎麼把圖數據變成 KV 存儲。這裏面的第一個概念是標籤（Tag），「標籤」表示的是點（Vertex）的類型，一個點能夠有多種「標籤」或者說「類型」。另外一個概念是邊類型（Edge Type），一條邊須要用起點 ID，終點 ID，邊類型和 Ranking 來惟一標識。前面幾個字段比較好理解，Ranking 這個字段是留給客戶表示額外信息，好比：轉帳時間。這裏補充下說明下 Nebula 頂點 Vertex、標籤 Tag、邊 Edge、邊類型 Edge Type的關係。

Vertex 是一個頂點，用一個 64 位的 id 來標識，一個 Vertex 能夠被打上多個 Tag（標籤），每一個 Tag 定義了一組屬性，舉個例子，咱們能夠有 Person 和 Developer 這兩個 Tag，Person 這個 Tag 裏定義了姓名、電話、住址等等信息，Developer 這個 Tag 裏可能定義了熟悉的編程語言、工做年限、GitHub 帳號等等信息。一個 Vertex 能夠被打上 Person 這個 Tag，這就表示這個 Vertex 表明了一個 Person，同時也包含了 Person 裏的屬性。另外一個 Vertex 可能被同時打上了 Person 和 Developer 這兩個 Tag，那就表示這個 Vertex 不只是一個 Person，仍是一個 Developer。

Vertex 和 Vertex 之間能夠用 Edge 相連，每一條 Edge 都會有類型，好比：好友關係。每一個 Edge Type 可定義一組屬性。Edge 通常用來表示一種關係，或者一個動做。好比，Peraon A 給 Person B 轉了一筆錢，那 A 和 B 之間就會有一條 Transfer 類型的邊，Transfer 這個邊類型（Edge Type）能夠定義一組屬性，好比轉帳金額，轉帳時間等等。任何兩個 Vertex 之間能夠有多種類型的邊，也能夠有多條同種類型的邊，好比：轉帳，兩個 Person 間可存在多筆轉帳，那每筆轉帳就是一條邊。 上面例子中，點和邊都帶有屬性，即多組<k,v>。Nebula是一個強 schema 系統，屬性的每一個字段名和對應的類型須要在構圖時先定義，和數據庫中的 alter table 相似 Nebula 也支持你在後續操做中進行 Schema 更改。Schema 中還有常見的 TTL（Time To Live），指定特定數據的生命週期，數據時效到後這條數據會被自動清理。

數據分片和 Key 的設計

剛纔有提到過度片（Partition）和鍵（Key）的設計，這裏再詳細解釋一下。

數據分片 Partition 或者有些系統叫 Shard，它的 ID 是怎麼獲得？很是簡單，根據點的 ID 作 Hash，而後取模 partition 數量，就獲得了 PartitionID。

Vertex 的 Key 是由 PartID + VID + TagID 三元組構成的，Value 裏面存放的是屬性（Property），這些屬性是一系列 KV 對的序列化。

Edge 的 Key 是由 PartID + SrcID + EdgeType + Ranking + DstID 五元組構成，但邊和點不一樣：一個點在 Nebula 裏只存儲一個 KV，但在 Nebula 中一條邊會存兩個 KV，一個 Out-edge Key和一個 In-edge Key，Out-edge 爲圖論中的出邊，In-edge 爲圖論中的入邊，雖然兩個 Key 都表示同一條邏輯邊，但存儲兩個 KV 的好處在於遍歷時，方便作出度和入度的遍歷。

舉個例子：要查詢過去 24 小時給我轉過錢的人，即查找全部指向個人帳號，遍歷的時候從「我」這個節點開始，沿着邊反向走能夠看到 Key 的設計是入邊 In-edge 的 DstID 信息在前面。因此作 Key 查詢時，入邊和終點，也就是「我」和「指向個人邊」是存儲在一個分片 Partition 上的，這樣就不涉及跨網絡開銷，最多一次硬盤讀就能夠取到對應數據。

多副本和高可用

最後再談下數據多副本和 Failover 的問題。前面已經提到多副本間是基於 Raft 協議的數據強一致。Nebula 在 Raft 作了些改進，好比，每組 partition 的 leader 都是打散的，這樣才能夠在多臺機器併發操做。此外還增長了 Raft learner 的角色，這個角色不會參與 Raft 協議的投票，只負責從 leader 讀數據。這個主要應用於一個數據中心向另一個數據中心作異步複製場景，也可用於複製到另外第三方存儲引擎，好比：HBase。

容錯機制

Nebula 對於容錯或者說高可用的保證，主要依賴於 Raft 協議。這樣單機 Crash 對服務是沒有影響的，由於用了 3 副本。那要是 Meta Server 掛了，也不會像 HDFS 的 NameNode 掛了影響那麼大，這時只是不能新建 schema，可是數據讀寫沒有影響，這樣作 meta 的遷移或者擴容也比較方便。

最後是 Nebula 的 GitHub 地址，歡迎你們試用，有什麼問題能夠向咱們提 issue。GitHub 地址：https://github.com/vesoft-inc/nebula

Nebula Graph：一個開源的分佈式圖數據庫。

GitHub：https://github.com/vesoft-inc/nebula

知乎：https://www.zhihu.com/org/nebulagraph/posts

微博：https://weibo.com/nebulagraph