圖數據庫項目DGraph的前世此生

本文由雲+社區發表

做者：ManishRai Jain

做者：ManishRai Jain Dgraph Labs創始人

版權聲明：本文由騰訊雲數據庫產品團隊整理，頁面原始內容來自於db weekly英文官網，若轉載請註明出處。翻譯目的在於傳遞更多全球最新數據庫領域相關信息，並不意味着騰訊雲數據庫產品團隊贊同其觀點或證明其內容的真實性。若是其餘媒體、網站或其餘任何形式的法律實體和我的使用，必須通過著做權人合法書面受權並自負所有法律責任。不得擅自使用騰訊雲數據庫團隊的名義進行轉載，或盜用騰訊雲數據庫團隊名義發佈信息。

---

每當我向別人介紹本身，並解釋咱們在Dgraph Labs所建設的內容時，我常常被人問到是否在Facebook工做過，或者我如今所作的嘗試是否受到FaceBook的啓發。不少人都知道FaceBook爲社交圖數據庫所作的努力，是由於他們發佈了不少關於圖數據庫基礎設施的文章。

來自谷歌的Word僅限於提供知識圖譜，但在這個項目以前，幾乎沒有人認爲內部基礎架構就能夠實現這個服務。Google提供專門的系統來提供知識圖譜服務。事實上，在谷歌工做的時候，我和個人團隊對圖數據庫服務系統下了很大的賭注。遠在2010年，我本身就至少作了兩個比較激進的嘗試去研究新的圖數據庫理論，來看看咱們能夠創造什麼。

Google須要構建一個新的圖數據庫服務系統，不只能夠處理知識圖譜數據中的複雜關係，還能夠處理全部訪問結構化數據的搜索服務（OneBoxes）。該服務系統要具有遍歷全部數據的能力，還要具有足夠高的吞吐量和足夠低的延時，這樣就能夠應用於海量的網絡搜索查詢。當時幾乎沒有可用的系統或者數據庫能同時知足上面三個要求。

如今我已經回答了谷歌爲何要構建圖數據服務系統，剩下的篇幅我會向大家介紹，咱們是如何一步一步，構建一個符合要求的圖數據庫系統來服務知識圖譜和搜索引擎的。

我是怎麼知道這些的？

先容許我快速的自我介紹一下，2006年到2013年，我在谷歌工做。最開始是做爲一個實習生，後面在Web Search Infrastructure組做爲一個軟件工程師工做。2010年，Google收購了Metaweb，個人團隊剛剛推出了Caffeine。我想作一些不同凡響的事情，並開始與Metaweb人合做，穿梭在舊金山和山景之間。我當時的目標是弄清楚如何使用知識圖譜來改進網絡搜索。

在我致力於研發圖數據庫以前，Google有一些項目。值得注意的是，Google在紐約辦公室建立了一個名爲Squared的項目，而且有一些關於知識卡片的討論。這些是我的和小團隊的零星努力。但那時候尚未造成一個既定的決策鏈，這也最終使我離開了谷歌。這個咱們稍後再談。

Metaweb故事

如上所述，谷歌在2010年收購了Metaweb。Metaweb使用多種技術構建了一個高質量的知識圖譜，包括爬取和解析維基百科，以及使用相似維基百科的衆包策略經過Freebase運做。全部這些都是由他們內部構建的圖形數據庫驅動的，這個數據庫名爲Graphd ，一個圖數據庫程序（現已經GitHub上發佈）。

Graphd有一些很是典型的屬性。像守護進程同樣，它在一臺服務器上運行，全部數據都在內存中。整個Freebase網站都用了Graphd。收購完成後，谷歌面臨的挑戰之一就是繼續運行Freebase。

Google構建了SSTable，而後是Bigtable，它們能夠橫向擴展到數百或數千臺機器，共同服務於數PB的數據。並且它們使用Borg（一個集羣管理工具，K8s的前身）分配機器，使用Stubby（gRPC出來）進行通訊，經過Borg名稱服務解析IP地址（BNS，baked into K8s），並將數據存儲在Google文件系統（GFS，相似Hadoop FS）。進程可能會死亡，機器可能會崩潰，但系統仍是會一直保持運行。

正是基於這個環境，Graphd得以發揚光大，服務於在單個服務器上運行整個網站的數據庫的想法與Google（包括我本身）最初的想法千差萬別。Graphd須要64GB或更多內存才能運行。若是你在嘲笑這內存，請注意時間點，這是在2010年。大多數Google服務器的最大容量爲32GB。事實上，Google必須購買具備足夠大RAM的特殊機器來支持Graphd。

GraphD的替代者

關於如何移動和重寫GraphD以分佈式方式工做的想法被提出，可是他們不是存儲鍵值對的數據庫，人們只須要獲取一大塊數據，將其移動到另外一個服務上，當訪問對應的key，就能夠提供服務了。圖數據庫須要保證有效的鏈接和遍歷，這就須要咱們使用特定的方式構建軟件。

在這些想法中，其中一個是使用名爲MindMeld（IIRC）的項目。該項目能夠經過網絡硬件能夠更快地訪問來自另外一臺服務器的內存。據推算，這種訪問方式正常的RPC更快，足以快速複製內存數據庫所需的僞複製直接內存訪問。這個想法並無走得太遠。

另外一個真正被採納的想法是構建一個真正的圖數據庫服務系統。不只能夠取代Graphd for Freebase，還能夠爲未來的全部知識圖譜工做服務。這被命名爲Dgraph，一個分佈式的圖數據庫服務系統，一個升級版的Graphd。

不用感到疑惑，答案是確定的。在Google內部，Dgraph Labs這家公司和開源項目Dgraph，就是這樣被命名的。

對於本博文的大部份內容，當我提到Dgraph時，我指的是Google內部的項目，而不是咱們構建的開源項目。固然開源項目後面也會有更多介紹。

Cerebro的故事：一個知識圖譜引擎

一個無心中造就的圖數據庫服務系統

雖然那時是我已經意識到Dgraph在努力取代Graphd的路上，但我當時的目標是改進網絡搜索的體驗。我在Metaweb找到了一位研發工程師DH，他同時也是Cubed的創始人。

正如我前面提到的，Google紐約的一些工程師已經創建了Google Squared。DH創建了一個相似的項目Cubed。雖然Squared這個項目最終爛尾了，但Cubed很是使人印象深入。我開始考慮如何在Google上構建它。Google提供了一些小特性，幫助我更輕鬆的搞定整個構建過程。

第一個特性是搜索，谷歌提供了一種方法，能夠高度準確地判斷哪些詞是連在一塊兒理解的。例如，當看到像[tom hanks movies]這樣的短語時，它能夠告訴你[tom]和[hanks]應該連起來。一樣，看到[san francisco weather]就知道[san]和[francisco]連在一塊兒表達一個意思。對於人類而言，這些都是顯而易見的事情，然而對於機器來講，作到這一點很難。

第二個特性是理解語法，當一個相似於[books by french authors]的搜索請求產生時，機器能夠理解爲[french authors]寫的[books]（即法國籍做者寫的書）。但這個短語還能夠被理解爲寫[french books]的[authors]，即寫法國書籍的做者。我使用斯坦福的詞性（POS）標記器來更好地理解語法並構建一棵語法樹。

第三個特性是理解實體，[french]一詞能夠表明不少實體。它能夠表明國家（地區），國籍（指法國人），菜餚（指法式食物）或法語。這裏我可使用另外一個項目來獲取單詞或短語能夠對應的實體列表。

第四部分是瞭解實體之間的關係。如今我已經知道如何將單詞鏈接成到短語，短語應該被以什麼樣的形式組織（即語法），以及它們能夠對應的實體，我須要一種方法來找到這些實體之間的關係以建立機器解釋。例如，一個查詢說[books by french authors]，而後POS告訴咱們它表明[french authors]寫的[books]。咱們有[french]的幾個實體，[authors]的幾個實體，接下來算法須要肯定它們的鏈接方式。他們能夠經過出生地聯繫起來，即出生在法國的做者（但多是英文寫做），或者是法國國民的做者，或者說或寫法語（但可能與法國這個國家無關）的做者，或者僅僅是喜歡法國美食的做家。

基於搜索索引的圖數據庫系統

爲了肯定實體是否須要以及如何鏈接，我須要一個圖數據庫系統。Graphd從未擴展到整個Google級別，而我擅長的是網絡搜索。知識圖譜元數據以三元組格式化，即每一個事實由三個部分表示，主題S（實體），謂詞P（關係）和對象O（另外一個實體）。查詢必須來自[S P]→[O]，來自[P O]→[S]，有時來自[S O]→[P]。

我使用了Google的搜索索引系統，爲每一個三元組分配了一個Id，並構建了三個索引，分別爲S，P和O.另外，索引容許附件，因此我附上了每一個實體的類型信息（即演員，書，人等等）。

我創建了這個圖數據服務系統，但知道它存在鏈接深度問題（以下所述），而且不適合任何複雜的圖數據查詢。事實上，當Metaweb團隊的某我的讓我開放該系統給其餘團隊訪問時，我堅持拒絕了。

爲了肯定實體間的關係，我會遍歷查詢實體間的全部可能性。好比，[french]和[author]之間會產生的全部關係，從中選一部分結果出來，在判斷[book]和這些結果之間產生的任何聯繫，以此類推不斷推演。這會致使同一個短語會產生多個解釋，好比[tom hanks movies]這個短語，它會產生如[湯姆漢克斯執導的電影]、[湯姆漢克斯主演的電影]、[湯姆漢克斯製做的電影]這樣的解釋，並自動過濾像[電影命名湯姆漢克斯]的解釋。

對於每一個可能解釋，圖數據庫系統將生成結果列表，包含圖中的有效實體，而且還將返回其類型（存在於附件中）。使用起來很是強大，由於結果的類型容許過濾，排序或進一步擴展等功能。好比對於電影搜索結果，您能夠按照發行年份，電影的長度（短片，長片），語言，獲獎等等對電影進行分類。

這個項目看起來很常智能，咱們（DH做爲知識圖譜專家也參與了一部分）將它命名爲Cerebro，以後X戰警電影裏出現了同名機器（腦波觸發器）。

Cerebro的運行常常會揭示一我的們最初沒有探索過的很是有趣的事實。當運行像[美國總統]那樣的查詢時，Cerebro會明白總統是人類，而人類有身高。所以，它容許你按身高對總統進行分類，並代表亞伯拉罕林肯是美國最高的總統。它還能夠容許人們按國籍查詢總統，在這種狀況下，它同時顯示了美國和英國總統的名單，由於美國有一位英國國籍總統：喬治華盛頓。 （免責聲明：基於當時KG狀態的結果，不能保證這些結果的正確性。）

超連接 vs 知識圖譜

Cerebro是有機會真正理解用戶查詢的含義的。利用圖數據庫的中的數據庫，咱們能夠生成查詢的機器解釋，生成結果列表並理解結果以支持進一步探索。如前面介紹的，您能夠對結果啓動特定的過濾和排序操做，也能夠進行對鏈接進行遍從來顯示數據的鏈接關係。從[美國總統]到[他們去的學校]，或者[他們所生的孩子]。 DH在另外一個他稱爲Parallax的項目中證實了從一個結果列表跳轉到另外一個結果列表的能力。

Cerebro使人很是印象深入，Metaweb的領導層也支持它。即便是服務於其中的一部分的，Cerebro也具備使人滿意的高性能和功能，我稱之爲知識引擎（從搜索引擎升級）。可是谷歌的領導沒有知識圖譜相關領域的。個人經理對此也並不感興趣，在跟他溝通以後，我得到了將其展現給一位很是高級的搜索部門領導的機會。

然而展現以後的迴應使人沮喪。對於[法國做者的書籍]的演示，該領導向我展現了谷歌查詢的搜索結果，其中顯示了十個相關的超連接，他認爲谷歌能夠作一樣的事情。此外，他們不想從網站上取走大量信息，也許會侵犯搜索者的隱私。

若是你也認爲這個高管說的有道理，不妨再想想：當Google進行網絡搜索時，它並不能真正理解查詢。它會在正確的相對位置，頁面的等級中查找正確的關鍵字，以及作諸如此類的事。它是一個很是複雜和極其複雜的系統，但它並不能真正理解查詢或結果。用戶須要自行從結果中讀取，解析和提取他們須要的信息，並進一步搜索以將完整的結果列表放在一塊兒。

例如，對於[法國做者的書籍]，首先須要將一個詳盡的列表放在一塊兒，內容多大單個網頁可能都放不下。而後按出版年份對這些書籍進行排序，或者按出版社等進行過濾，全部這些操做都須要大量的連接跟蹤，進一步搜索和人工聚合結果。 Cerebro有能力將全部用戶過濾信息的步驟省除，讓人機交互簡單而完美。

然而，這是當時典型的知識圖譜方法。Google的管理層不肯定知識圖譜的效用，也不肯定搜索引擎應該如何跟知識圖譜結合起來。這個經過向用戶提供網頁連接而得到巨大成功的組織，難以輕易消化這種接近更知識的新方式。

在與Google管理層對峙了一年後，我幾乎喪失了繼續的信心。此時谷歌上海辦公室的一位經理向我伸出手，我於2011年6月將項目交給了他。他組建了一個由15名工程師組成的團隊。我在上海呆了一個星期，將我建造和學到的東西轉移給工程師。 DH也參與其中，他在這裏長期指導團隊。

鏈接深度問題

我爲Cerebro構建的圖數據庫服務系統存在一個鏈接深度問題。當須要查詢的先前部分的結果集來執行其後續部分時，一個鏈接就被創建了。典型的鏈接將涉及一些SELECT操做，即來自通用數據集的某些結果中的過濾器，而後使用這些結果來過濾數據集的另外一部分。我將以一個例子來講明。

好比說，你想知道 [people in SF who eat sushi]（住在舊金山且吃壽司的人）。數據被人們分紅兩類：住在SF的人和吃壽司的人這兩類信息。

以上查詢是單級鏈接。若是數據庫外部的應用程序正在執行此操做，它將執行一個查詢來執行第一步。而後執行多個查詢（每一個結果一個查詢），找出每一個人吃什麼，只挑選吃壽司的人。

第二步是出現扇出問題。若是第一步有一百萬個結果（全部舊金山人口），那麼第二步須要將每一個結果放入查詢中，檢索他們的飲食習慣，而後經過過濾器過濾出符合條件的人。

分佈式系統工程師一般經過廣播來解決這個問題。他們將結果分紅不少批量任務，使用分片功能進行分割，並將查詢任務分配到集羣中的每一個服務器。使用分佈式會完成鏈接，但會致使查詢延遲問題。

分佈式系統中的廣播很糟糕。谷歌的Jeff Dean在他的「Achieving Rapid Response Times in Large Online Services」 演講中最好地解釋了這個問題。查詢的總延遲老是大於最慢的那臺機器的延遲。單個機器上的小問題就會致使延遲，每次查詢涉及到海量的機器就會大大增長延遲的可能性。

考慮一個服務器，其50％延遲爲1ms，但99％延遲爲1s（即百分之99的延遲都小於等於1s）。若是查詢僅僅在一個服務器上處理，則只有1％的請求會佔用一秒鐘以上。但若是查詢觸及其中的100臺服務器，則63％的請求將佔用一秒鐘以上。

所以，執行一個查詢的廣播對於查詢延遲是不利的。如今考慮是否須要進行兩次，三次或更屢次鏈接。對於實時OLTP場景來講，會變得太慢，延時超出人們的接受範圍。

大多數非原生圖數據庫都存在這種高扇出的廣播問題，包括Janus圖，Twitter的FlockDB和Facebook的TAO。

分佈式鏈接是一個難題。現有的單機圖形數據庫經過將通用數據集保持在一個機器（獨立數據庫）內，而且在不觸及其餘服務器的狀況下進行全部鏈接操做，則能夠避免這個問題，好比Neo4j。

進入Dgraph：任意深度鏈接引擎

在結束Cerebro以後，我有了構建圖形服務系統的經驗，參與了Dgraph項目，併成爲該項目的三位技術主管之一。 Dgraph設計中涉及的概念是新穎的，解決了鏈接深度問題。

Dgraph以一種特殊的方式對圖形數據進行分片，其中每一個鏈接均可以徹底由一臺機器執行，回到以前說的概念主題 - 謂詞 - 對象（SPO），Dgraph的每一個實例將保存與該實例中的每一個謂詞相對應的全部主題和對象。多個謂詞將存儲在實例上，每一個謂詞都以總體存儲。

這實際上容許了查詢執行任意深度鏈接，同時避免扇出廣播問題。好比查詢[people in SF who eat sushi]，會致使數據庫內最多進行兩次網絡調用，不管集羣規模大小。第一個調用會找到全部住在舊金山的人。第二個調用會發送這我的名單並與全部吃壽司的人求並集。咱們還能夠添加更多約束或擴展，每一個步驟仍然會涉及最多一個網絡調用。

這引入了位於單個服務器上的很是大的謂詞的問題，可是這個問題能夠經過隨着大小的增加在兩個或更多個實例之間進一步分割謂詞來解決。即便這樣，整個集羣中的單個謂詞拆分也只是在最極端狀況下的最壞行爲，其中全部數據僅對應於一個謂詞。在其餘狀況下，這種經過謂詞對數據進行分片的技術表現都很好，能夠在實際系統中實現更快的查詢延遲。

分片技術並非Dgraph的惟一創新。Dgraph爲全部對象分配了整數ID，並對其進行排序並存儲在發佈列表結構中，以便快速對這些發佈列表求進行交叉計算。這些創新將在鏈接期間加快過濾速度，還能夠用來查找公共引用等。這些想法裏涉及到了Google的Web服務系統。

經過Plasma項目統一全部OneBox

谷歌的Dgraph不是一個數據庫，而是一個服務系統，至關於谷歌的網絡搜索服務系統。使用Dgraph還能夠對實時更新作出反應。做爲實時更新服務系統，它須要一個實時圖形索引系統。我在Caffeine項目中積累了不少實時增量索引系統方面的經驗。

我發起一個項目，經過圖數據索引系統來統一全部Google OneBox，其中包括天氣，航班，事件新聞等。你可能不知道OneBox這個詞，但你確定已經看過了。 OneBox不一樣於其餘搜索結果，是一個單獨的顯示框，在運行某些類型的查詢時顯示，Google能夠在OneBox返回更豐富的信息。想了解一下OneBox，請嘗試搜索[weather in sf]。

在發起這個項目以前，每一個OneBox由獨立後端運行並由不一樣的團隊維護。有一組很複雜的結構化數據，但每一個OneBox之間沒有共享數據。這樣不只在操做上保留了後端的大量的重複工做，並且每一個Box之間缺少知識共享也限制了Google能夠響應的查詢類型。

舉個例子，[events in SF]能夠顯示舊金山的事件新聞，[weather in SF]能夠顯示舊金山的天氣。但若是[events in SF]這個OneBox瞭解到天氣多雨而且知道用戶須要查找的事件是在室內仍是在室外，它就能夠根據天氣過濾（或至少排序）事件（在暴雨中，可能電影或交響樂等室內活動是最好的選擇）。

在Metaweb團隊的幫助下，咱們開始將全部這些數據轉換爲SPO格式並在一個系統下對其進行索引。我將系統命名爲Plasma，一個基於圖數據服務系統Dgraph的實時圖形索引系統。

管理混亂

像Cerebro同樣，Plasma項目資金不足，但仍在繼續。最終，當管理層意識到OneBox團隊即將遷移到這個項目時，他們須要負責知識圖譜的「合適人選」。在那場「權利的遊戲」中，我經歷了三次管理層變化，但每次都沒有對知識圖譜有經驗的人加入。

在這次管理層洗牌期間，支持Spanner的管理層認爲Dgraph過於複雜，Spanner是一個全球分佈式的SQL數據庫，須要GPS時鐘來確保全局一致性。具備諷刺意味的是，這至今仍然使人難以置信。

最終，Dgraph取消了，Plasma倖免於難，但由新的領導和新的團隊來負責繼續運營，並直接彙報給CEO。新團隊對知識圖譜缺少了解，他們決定創建一個基於Google現有搜索索引的服務系統（就像我爲Cerebro所作的那樣）。我建議使用我已經爲Cerebro創建的系統，可是被拒絕了。我將Plasma改造爲一個爬取並能夠擴展知識話題到若干層的系統，這樣Google現有的搜索服務能夠把結果當成Web文檔來處理。他們稱之爲TS（名稱縮寫）。

這種改造也意味着新的服務系統將沒法進行任何深度鏈接。在不少公司，我都看到一個關於知識圖譜的「決策詛咒」，是由於工程師們一般錯誤地認爲「圖數據服務是一個簡單的問題，能夠經過在另外一個已有系統之上構建一個層來解決」。

幾個月以後，2013年5月，我離開谷歌，此時我已經爲Dgraph / Plasma工做了兩年。

後記

• 幾年後，Web搜索基礎設施團隊被重命名爲Web搜索和知識圖形基礎設施團隊，我曾經向其演示Cerebro的領導開始從新領導知識圖譜工做，大談特談他們打算如何用知識圖譜取代超連接，並直接回應儘量多的用戶查詢。
• 當上海的Cerebro研發團隊的即將將項目上線時，該項目從上海直接被拉到了谷歌紐約辦公室。最終，它以Knowledge Strip的形式上線。若是你搜索[tom hanks movies]，你會在搜索結果頂部看到它。自首次發佈以來，它有一些迭代改進，但仍然不支持Cerebro提供的過濾和排序級別。
• 在Dgraph工做的全部三位技術主管（包括我）最終都離開了谷歌。據我所知，其餘兩位領導如今正在微軟和LinkedIn工做。
• 當我做爲高級軟件工程師離開谷歌時，我確實得到了兩次晉升，目前準備迎接第三次。
• 小道消息，當前版本的TS實際上很是接近Cerebro的圖形系統設計，主題，謂詞和對象都有一個索引。所以，它將繼續受到加入鏈接深度問題的困擾。
• 此後，Plasma被重寫並重命名，但仍然繼續充當實時圖形索引系統，支持TS。他們一塊兒繼續託管和提供Google的全部結構化數據，包括知識圖譜。
• 從不少地方均可以看出，Google沒法進行深度鏈接。首先，咱們仍然沒有看到OneBoxes的各類數據反饋的結合：儘管天氣和KG數據隨時可用， [cities by most rain in asia] （亞洲下雨最多的城市）都、沒有生成城市實體列表（相反，結果是來自網頁的引用）; [events in SF]沒法根據天氣進行過濾; [US presidents]的結果不能進一步分類，過濾或擴展到他們的孩子或他們就讀的學校。我懷疑這也是中止使用Freebase的緣由之一。

搜索關注「騰訊雲數據庫TencentDB"官方微信，最新最熱數據庫前沿知識和手把手實戰教程等你來約，更可在移動端一鍵管理數據庫。

Dgraph：鳳凰磐涅

離開谷歌兩年後，我決定創建Dgraph。不在Google的日子裏，我見證了不少與在內部研發圖數據系統時的猶豫不決。圖形空間有不少半生不熟的解決方案，特別是不少自定義解決方案，草率的將系統搭建在關係型或NoSQL數據庫之上，或者做爲多模型數據庫的衆多功能之一。若是存在一個本地單擊解決方案，則會遇到可伸縮性問題。

Dgraph團隊花了三年的時間，不只吸取了我本身以前的經驗，並且還對系統設計進行了大量的原創型研究，創建了市場上無與倫比的圖形數據庫。所以，公司具有了強大，可擴展且高性能的解決方案，用來替代那些半生不熟的解決方案。

此文已由騰訊雲+社區在各渠道發佈

獲取更多新鮮技術乾貨，能夠關注咱們騰訊雲技術社區-雲加社區官方號及知乎機構號