導讀：你想知道百億級圖譜如何實現毫秒級查詢嗎？社區(qū)眾多的圖數據庫中如何才能挑選到一款適合實際應用場景的圖數據庫呢？貝殼找房的行業(yè)圖譜480億量級的三元組究竟是如何存儲的呢？本文將帶你探索上述問題并從中得到解答。本次分享題目為"分布式圖數據庫在貝殼找房的應用實踐"，共分為以下五大塊內容：

• 圖數據庫簡介

• 圖數據庫技術選型

• 圖數據庫平臺建設

• 原理&優(yōu)化&不足

• 未來規(guī)劃

01

圖數據庫簡介

先來看一個問題：貝殼找房最大的圖譜——行業(yè)圖譜，目前量級已經達了480億三元組，如此海量的圖譜數據究竟應該如何存儲，如何查詢，才能滿足高并發(fā)場景下的毫秒級響應，從而支持貝殼業(yè)務的快速發(fā)展呢？我們帶著這個問題開始本次的分享。

1. 為什么需要圖數據庫？

貝殼的行業(yè)圖譜中包含了很多信息，比如房源、客戶、經紀人、開發(fā)商、小區(qū)、地鐵、醫(yī)院、學校、超市、電影院等等；

我們假設這樣一種特殊的查詢場景：找出開發(fā)商是XXX，小區(qū)綠化率大于30%，周邊200米有大型超市，500米有地鐵，1000米有三甲醫(yī)院，2000米有升學率超過60%的高中，房價在800W以內，最近被經紀人帶看次數最多的房子。

這可能是一個客戶想要的房子，但是各位覺得有哪個產品可以支持么？如果說我們用傳統的關系型數據庫，MySQL或者Oracle可以嗎？那是不是我們要關聯房源表、客戶表、經紀人表、開發(fā)商表等等，一次關聯幾十張表才可能得到想要的結果？但明顯這是不現實的；那ES ( Elasticsearch ) 可以嗎？ES在搜索領域非?；?，它可以解決嗎？其實ES也是解決不了的，ES要搜這樣的房源，肯定是需要有一張很寬的房源表，那怎么搜索這套房源周邊200米有大型超市？難道要建距離周邊超市的距離這樣一個字段嗎？顯然也是不現實的；HBase更不用說了。所以顯而易見這種行業(yè)圖譜的數據只能使用圖數據庫，比如Neo4j這樣的存儲引擎才可以支持。

2. 圖數據庫簡介

簡單介紹一下圖數據庫，什么是圖數據庫？

• 不是存儲圖片的數據庫

• 存儲節(jié)點和關系，以圖結構存儲和查詢

應用場景非常廣泛，遠不止我們聊到的行業(yè)圖譜、知識圖譜這些，它包含：

• 社交網絡、計算機網絡、道路網絡、電信網絡

• 關聯查詢，搜索推薦

• 風險預測，風控管理

• 業(yè)務流程，生物流程

• 公司或市場結構

• 事件及其之間的因果關系或其他聯系

還有很多其他領域都可以使用圖數據庫來解決。

這是DB-Engines上的各種類型數據庫的流行度趨勢圖，可以明顯的看出圖數據庫在近兩年來越來越流行，越來越被大眾所關注。

這是圖數據庫領域的各類產品，排名第一的就是大家最熟悉的Neo4j，下面還有很多開源的、閉源的、單機的、分布式的等等各種圖數據庫，產品非常繁多。

02

圖數據庫技術選型

剛才提到圖數據庫的應用場景非常廣：搜索、推薦、關系圖譜、知識圖譜等等。目前貝殼也有各種場景需要使用到圖數據庫，但選型各不相同，有的部門使用JanusGraph，有的使用Neo4j，每個有需要的部門都得從頭搭建一套。所以我們想是不是應該有一個通用的圖數據庫平臺，可以支撐所有需要使用圖數據庫的場景，然后讓做關系圖譜、行業(yè)圖譜的同學可以更關注于上層的算法和策略，而無需關注底層的存儲、分布式、高性能、高可用等等？答案顯然是確定的：我們需要這樣一個統一的圖數據庫平臺。那么目前圖數據庫領域已經有這么多產品，要做圖數據庫平臺的話，到底應該選用哪一個呢？所以我們進入第二個主題，圖數據庫的技術選型。

1. 圖數據庫技術選型

當我們進行圖數據庫技術選型的時候，我們具體需要關注哪些指標？哪些因素會影響我們的決策呢？我們主要關注以下幾個方面：開源、成熟度、可擴展性、文檔豐富度、性能、穩(wěn)定性、運維成本、易用性。其中運維成本是比較容易忽視的，但我們做技術選型時必須考慮清楚，每種選型的運維成本是否是可接受的，投入產出比是否值得。

前面看到圖數據庫雖然有很多種，但實際上開源的、流行的圖數據庫就只有以下幾種：Neo4j、OrientDB、ArangoDB、JanusGraph、Dgraph，Neo4j實際上是用來做對比的，OrientDB和ArangoDB都是老牌的圖數據庫了，發(fā)展比較早，從2012、2013年就開始做了，JanusGraph和Dgraph是比較新的，從2016、2017年才開始做。

2. 主流圖數據庫對比

那它們的主要區(qū)別是什么呢？我們將上述主流的圖數據庫做一下調研，先簡單粗略的對比分析一下：

Neo4j歷史悠久，且長期處于圖數據庫領域的龍頭地位，那為什么不考慮它呢？原因很簡單，因為它開源的社區(qū)版本只支持單機，不支持分布式。

OrientDB和ArangoDB它們起步比較早，最初的時候都是一個單機的圖數據庫，然后隨著用戶數據量的不斷增加，后期增加了分布式模式，支持集群和副本，但是經過調研發(fā)現，可能是由于后加的功能，他們的分布式支持的不是很好。

所以主要注意力放到了JanusGraph和Dgraph上，他們發(fā)展的比較晚，從設計之初就考慮了分布式和擴展性，所以對分布式支持的非常好，也都是完全的開源免費，存儲數據模型也都是專為圖數據而設計。他們有一個比較大的區(qū)別就是，JanusGraph的存儲需要依賴于其他存儲系統，而Dgraph使用自身的存儲系統，這就造成了前面提到的運維成本的問題。例如JanusGraph多數使用HBase作為底層存儲系統，而HBase又依賴于Zookeeper和HDFS，另外JanusGraph的索引又依賴于ES，所以想要搭建一套完整的JanusGraph，需要同時搭建維護好幾套系統，維護成本非常大；而Dgraph這些都是原生支持的，所以相對來說，Dgraph維護成本低很多。

下面我們具體對比一下二者的架構。

3. JanusGraph架構

前文提到，JanusGraph的存儲系統依賴于像Cassandra、HBase、BerkelyDB等等這樣的存儲系統，索引系統依賴于Elasticsearch、Solr、Lucene等等；也基于這些原因，它和大數據生態(tài)結合的非常好，可以很好地和Spark結合做一些大型的圖計算；但缺點就是它的維護成本會非常高，依賴于這么多的外部系統，搭建一套JanusGraph系統的同時需要搭建好幾套依賴系統；另一方面就是穩(wěn)定性，根據經驗來看，系統越復雜，依賴系統越多，整體可控性就越差，穩(wěn)定性風險就越大。

4. Dgraph架構

這是Dgraph的架構，它的架構其實非常簡單，所有功能都是原生支持的，不依賴于任何第三方系統，右圖從下往上看：

• zero：集群大腦，用于控制集群，將服務器分配到一個組，并均衡數據。通過raft選主；相當于hadoop的namenode或者Elasticsearch的master。

• alpha：存儲數據并處理查詢，托管謂詞和索引，即datanode。

• group：多個alpha組成一個group，數據分片存儲到不同group，每個group內數據通過raft保證強一致性。

• ratel：可視化界面，用戶可通過界面來執(zhí)行查詢，更新或修改schema。

• 同時Dgraph還支持gRPC或者HTTP來連接alpha進行寫入或查詢。

Dgraph只有一個可執(zhí)行文件，通過指定不同的參數在不同的機器上啟動，就能自動組成集群，無需搭建維護其他任何第三方系統，這是它的優(yōu)勢。那是不是就能通過這樣的架構對比，因Dgraph運維簡單就直接選擇它呢？肯定不行，我們還需要做一些性能壓測來對比，如果說JanusGraph的性能是Dgraph的好幾倍，那維護成本高些也是可以接受的。所以基于這個目的，我們對這兩個圖數據庫做了詳細的性能對比測試。

5. JanusGraph和Dgraph性能對比

在48核、128G內存、SATA硬盤的三臺物理機環(huán)境，4800萬個點、6300萬條邊、4.5億三元組、總計30G的數據集下進行性能對比測試：

• 寫入性能維度來看，分為實時寫入和初始化寫入三元組兩種，在實時寫入對比中，點的寫入性能：JanusGraph達到15000/s，Dgraph達到35000/s；邊的寫入性能：JanusGraph達到9000/s，Dgraph達到10000/s。

• 查詢性能維度來看，相差較大，主要測試圖數據庫典型的幾種場景，比如點的屬性，點的一度、二度、三度關系，包括最短路徑等等。大家可以從表中看到，在簡單查詢的場景下，比如查詢點的屬性、點的一度關系時，二者都是毫秒級別的，沒有太大的性能差別；但是隨著查詢越來越復雜，JanusGraph的查詢越來越慢，最后查到三度的頂點和屬性要消耗700多毫秒，但Dgraph一直保持在幾毫秒之內。

所以可以看出Dgraph相對JanusGraph的查詢性能的優(yōu)勢是非常大的。

6. JanusGraph VS Dgraph

總結一下兩種圖數據庫特性的對比：

• 架構方面：Dgraph是分布式的，而JanusGraph構建于其他分布式數據庫之上。

• 副本方面：Dgraph是強一致性的，JanusGraph需要依賴底層的存儲DB。

• 數據均衡方面：Dgraph支持自動均衡，JanusGraph也是依賴底層的存儲DB。

• 語言方面：JanusGraph使用了比較常用的Gremlin，而Dgraph使用基于GraphQL改進的GraphQL+-。

• 全文檢索、正則表達式、地理位置檢索方面：Dgraph是原生支持的，JanusGraph依賴外部檢索系統。

• 可視化方面：Dgraph有自己的可視化系統，JanusGraph依賴外部系統。

• 維護成本方面：由于不依賴其他系統，Dgraph遠低于JanusGraph。 

• 寫入性能方面：Dgraph稍高一些。

• 查詢性能方面：深度查詢時，Dgraph性能遠高于JanusGraph。

所以基于以上對比，我們最終選擇了使用Dgraph來構建我們的圖數據庫平臺。

03

圖數據庫平臺建設

在圖數據庫選型確定后，就需要真正地把圖數據庫平臺搭建起來。

1. 集群的建設

上文提到，搭建Dgraph集群其實非常簡單，我們使用docker+k8s技術對Dgraph進行統一的容器化部署和管理。如圖使用三臺服務器，每臺服務器上啟動四個節(jié)點，其中三個是Alpha節(jié)點，就是存儲數據、索引、執(zhí)行查詢的節(jié)點，一個zero節(jié)點，是Dgraph的控制節(jié)點；需要注意到的一點是，每個Group的3個Alpha用于存儲同一份數據的三個副本，一個Group的不同的Alpha肯定是不能在同一臺機器的，而哪幾個Alpha組成一個Group是zero根據副本數來確定的，比如dgraph zero -- replicas 3這樣啟動時候就指定三個副本數，并且根據Alpha的啟動順序來確定。所以有個啟動技巧就是，先在第一臺服務器上啟動Alpha1，然后切到第二胎服務器上啟動Alpha2，再到第三臺服務器上啟動Alpha3，這三個先啟動的Alpha組成第一個Group；然后輪流順序地啟動其他的Alpha 4、5、6組成第二個Group，7、8、9組成第三個Group，不能直接在第一臺服務器上直接啟動123，這樣組成一個Group是無法保證高可用的，因為當這一臺機器掛掉之后三個副本就全部丟失了。

左側是Dgraph的啟動命令，啟動zero時候指定一下副本數量；啟動alpha的時候，指定一下zero的地址就可以了；這樣就啟動了一個Dgraph集群，由此可見，它的搭建和維護成本確定很低。

2. 數據寫入

集群搭建好了以后，就要考慮數據的寫入了，因為是要做一個通用的圖數據庫平臺，所以要考慮多種的數據寫入模式，比如實時數據流、批量數據流和初始化數據流。

實時數據流模式：有一個Data-Accepter模塊，用戶可以將實時變更的數據用過這個模塊推過來，然后通過Kafka做異步消峰，寫到Kafka隊列里面，后面有Graph-Import模塊從Kafka將數據取出寫到Dgraph集群。

批量數據流模式：比如說要做全量的數據更新，目前貝殼大部分的行業(yè)圖譜數據都是存在Hive或者是HDFS中的，這時候會有一個Hive2Kafka的spark任務，從用戶的Hive表或者HDFS拿到全部的圖譜數據，同樣寫入Kafka，最后通過Graph-Import模塊從Kafka取出數據寫入Dgraph集群。

初始化數據流模式：Dgraph還有一個不同點就是支持數據初始化導入，這個導入是非?？斓?，比如像行業(yè)圖譜這樣的480億數據，第一次全部導入，按照這種數據流的模式一條條去寫一定是要花很多時間的，所以采用Dgraph提供的初始化導入，使用Dgraph的Bulk Loader接口，通過MapReduce的方式預先生成它的數據文件和索引文件，然后再啟動Dgraph的Alpha節(jié)點去加載這些文件，這樣可以實現非常快的初始化導入，后面會詳細說這塊內容。所以我們也支持這種初始化數據流，通過腳本可以一鍵式的完成初始化數據生成，然后調用k8s接口啟動一個Dgraph集群，再加載生成好的數據，最后返回一個查詢API接口給Dgraph的使用方。

3. 數據查詢 

完成數據導入之后，接下來就是數據查詢了，上圖為Dgraph的可視化界面Ratel，左邊輸入一個查詢語句之后，右邊就會出現相應圖的展示；這個例子是要查出名字包含“秀園”，綠化率大于百分之三十的小區(qū)的附近一千米內的所有幼兒園。右邊展示圖的下面可以看到Dgraph的服務端查詢只花了24毫秒，加上來回網絡開銷總計也就91毫秒，非常的快。

4. Graph SQL

最上面就是Dgraph的查詢語句，大家可以感受一下，并不是那么簡單，是需要一定的學習成本的。而我們前面說到建設圖數據庫平臺需要考慮易用性，需要盡量簡化使用方的學習成本，所以需要考慮是否有更簡單的查詢語法。

這種查詢在Gremlin是怎么寫的呢？如圖，使用多個has然后select就可以篩選出來，但同樣不夠簡單明了。

考慮到大部分程序員最熟悉的查詢語言就是SQL，甚至不是程序員，一些數據分析師也會SQL，那是否可以使用SQL對圖數據庫查詢？于是我們設計了一套使用SQL查詢圖數據庫的語言，稱之為Graph SQL。比如上圖最下面的語句：select小區(qū)名字、小區(qū)綠化率、幼兒園名字；from小區(qū)到幼兒園的這么一個關系，此處和SQL有所不同，不是from一個表，而是from一個小區(qū)到幼兒園的關系子圖；然后where小區(qū)名字包含"秀園"，綠化率大于30%，距離幼兒園的距離小于1000米。

上圖為目前我們提供的一個完整的基于SQL查圖的語法，增加了一些特定的圖的關鍵字，比如：shortestpath：查詢圖的最短路徑；degree：查詢一度關系、二度關系、三度關系等等；然后也支持查點、查邊、查節(jié)點的屬性等等，后面還有GROUP BY、HAVING、ORDER BY、LIMIT等等，LIMIT支持對點、也支持對邊進行LIMIT；當然目前只支持了一些簡單的語法，后面復雜的查詢還在繼續(xù)完善中。通過支持這種類SQL的查詢語法，就可以極大的降低圖數據庫平臺的接入成本和學習成本。 

這是最終的一個實現效果，可以看到通過發(fā)送一個簡單的HTTP請求，里面包含一個SQL查詢語句，可以很快的返回圖數據庫的查詢結果。

5. 整體架構

匯總前面的集群搭建、數據寫入、數據查詢，再復用統一的服務治理框架，整合起來就是我們當前圖數據庫平臺的整體架構了：

統一的網關，用來做鑒權、分發(fā)、限流、熔斷和降級。

在網關之下有統一的數據流模塊和查詢層模塊：

• 數據流模塊包含數據源、數據接收、增量、全量、Kafka、數據導入。

• 查詢層模塊支持Graph-SQL，如果有Graph-SQL無法支持的查詢，也可以使用原生的GraphQL+-來進行復雜的查詢，然后通過Graph-Client連接到底層的Dgraph集群執(zhí)行并返回結果。

其中：

• Dgraph集群整體是通過Docker+K8s虛擬化技術部署到物理機上的

• 右邊復用了貝殼搜索平臺的整體服務治理能力，所有微服務都通過注冊中心、配置中心、負載均衡、消息總線、熔斷降級、鏈路追蹤、監(jiān)控告警等技術進行統一調度、管理、監(jiān)控等。

04

原理&優(yōu)化&不足

完成了圖數據庫平臺的搭建之后，相當于只是完成了從0到1的工作，只是有了這樣一個圖數據庫平臺可用；下一步就是要完成從1到N 的過程，需要保證平臺的穩(wěn)定性、提升平臺的性能和體驗，這是第二部分的工作。為了完成第二部分的工作，就需要對Dgraph做一些深入的學習、深入的理解、深入的優(yōu)化，需要知道它的優(yōu)勢和不足，知道他的底層的原理實現。

1. Dgraph原理

簡單介紹一下Dgraph的原理：

① 存儲引擎：

Dgraph的存儲引擎是自研的Badger，完全由Go語言開發(fā)。最初Dgraph存儲也是使用RocksDB，但后來上層通過go調用，出現一些內存溢出的問題，于是Dgraph團隊干脆自己用Go實現了一個高效的、持久化的，基于LSM的鍵值數據庫，并且號稱隨機讀比RocksDB快3.5倍

② 存儲結構 ( 因為存儲引擎是KV的，所存儲結構也是KV的 )：

(Predicate, Subject) --> [sorted list of ValueId]，Key是由謂詞和主語組成的，Value是一個有序的數組。

舉個例子：

(friend, me)-->[person1, person2, person3, person4, person5]，Key是friend和me，friend是關系，me是主語，這樣組成的一個Key；Value是有序的，me的所有friend，從person1、person2到person5這些ID組成的一個有序的數組。

基于這樣的底層存儲結構設計，Dgraph同一個謂詞下的所有數據都存儲在同一個數據節(jié)點甚至同一個數據塊中，所以這樣查詢一個謂詞數據時候，只需要一次RPC調用就可以拿到這個謂詞下面全部需要的數據，對于后面的一度、二度、多度的關聯查詢有非常大的性能提升，這是它核心的優(yōu)勢。

③ 數據分片 ( 作為一個分布式系統，要想平滑的擴展，必須要支持數據分片 )：

根據謂詞分片，相同謂詞的數據按序存儲在同一個節(jié)點，減少RPC，提升查詢性能，不同謂詞可能是在不同的節(jié)點

定期數據均衡 ( rebalance_interval )，zero節(jié)點會定期的檢測各個節(jié)點的數據是否均衡，如果某個節(jié)點數據過大或者過小，會導致查詢的性能下降，因此zero節(jié)點會盡量的保證每個節(jié)點的數據均衡。

group根據replicas和alpha啟動順序確定，因為Dgraph的副本一致性是依賴Raft協議的，所以要保證至少有三個節(jié)點，才能保證數據的強一致性。

④ 高可用：

每個group至少3個alpha，互為副本，raft協議保證強一致性；每個group中的alpha的數據保持一致，這樣某個alpha節(jié)點掛了，可以通過其他的alpha進行數據恢復。

write-ahead logs，預寫日志；分布式很常見的WAL機制，為了提升寫入性能，一定是先寫緩存后刷磁盤的，不會直接寫磁盤的，那樣性能會非常低，但先寫內存后寫磁盤會帶來一個問題，一旦機器掛掉了，內存數據沒有刷到磁盤中，那這部分數據就會丟失。因此大部分分布式系統，比如：HBase、Elasticsearch、Dgraph等都是數據寫內存之前，先預寫日志，日志會實時刷到磁盤上，然后再將數據寫內存，一旦內存中數據丟失了，可以通過磁盤上的日志回放這些數據，從而保證高可用性。

2. Bulk Loader優(yōu)化

其實我們對于Dgraph的研究也僅僅只有幾個月而已，所以目前只是做了一些小的優(yōu)化：480億的行業(yè)圖譜如何快速的導入到集群中？

最開始使用Java客戶端寫入，發(fā)現這種方法性能非常低，完全寫完可能需要整整一周的時間；

然后使用Dgraph的Bulk Loader寫入，先生成索引數據，再通過alpha節(jié)點加載，最后啟動集群來提供服務，這種方式需要48小時才能全部寫入完成，時間也有點長，是否還能進一步優(yōu)化提升速度呢？

于是我們研究了一下Bulk Loader的源碼，發(fā)現只是一個簡單的Map Reduce過程，但他是在單機上執(zhí)行的，使用單機執(zhí)行是因為它要分配一個全局唯一的UID，為了保證UID的唯一性和順序性而選擇單機執(zhí)行，使用單機多線程，啟動多個Map和Reduce線程，然后每個線程生成Shard文件，最后通過Dgraph的alpha加載數據。于是基于對源碼的理解，我們發(fā)現是可以優(yōu)化的，Dgraph原本作為分布式系統，各種查詢寫入都是可以做線性擴展的，不能說最初的批量導入只能是一個單機的模塊。

所以我們對源碼進行了一定的優(yōu)化，將原來的單機多線程改為了多機多線程模式，首先通過Partition模塊，為原來的每條數據分配一個UID，這塊還是單機執(zhí)行的，把相同group的數據分到一個數據塊中；然后把這些數據塊分發(fā)到不同機器上，每臺機器上都可以啟動原來的Map進程和Reduce進程，每臺機器都可以生成Dgraph需要的數據文件，再在每臺機器上啟動alpha進程加載這些數據文件，直至整個集群啟動成功為止。這樣把480億三元組的數據初始化導入從48小時提升到了15小時，提升了三倍性能。

3. 性能壓測

把這480億數據導入后，就可以回答我們最初的問題了，它真的可以支持百億級圖譜數據毫秒級查詢嗎？于是我們專門對其進行了性能壓測，如上圖，可以看出Dgraph的性能確實很好，底下橫坐標是我們的并發(fā)線程，左邊縱坐標是響應時間 ( 單位毫秒 )，右邊縱坐標是QPS吞吐率；當我們用1000并發(fā)壓測時，仍然可以保持在50ms的響應延遲，并且QPS可以達到15000/s，性能非常好。

4. Dgraph不足

那Dgraph性能這么好，運維又簡單，是不是就可以說Dgraph是一個完美的圖數據庫呢？是不是所有的場景都可以用Dgraph來支持呢？顯然不是的，沒有最完美的系統，只有最適合你業(yè)務的系統；就像沒有最完美的人，只有最適合你的人一樣。Dgraph也是有它的缺陷和不足的：

① 不支持多重邊

就是說任意一對頂點，相同標簽類型的邊只允許存在一條；在JanusGraph中，兩個頂點確定之后，是允許存在多重邊的。比如：Dgraph中，我和你是同學關系，那只能有一條叫同學關系的邊；但在JanusGraph中，我和你可以同時是小學同學、中學同學、大學同學，有三條同學關系的邊。

② 一個集群只支持一個圖

目前Dgraph一個集群只支持一個圖，支持多圖這個功能官方正在開發(fā)中，后期會支持；目前對貝殼的影響還不大，貝殼的圖譜都是比較大的、隔離的，比如行業(yè)圖譜480億本身就是需要一個單獨的集群的，不會和其他圖譜共用，目前還夠不成太大的問題。后期自然是希望官方可以盡快的支持了。

③ 大數據生態(tài)兼容不夠

不像JanusGraph和大數據生態(tài)兼容的那么好，因為JanusGraph本身就是基于HBase存儲的；Dgraph本身使用Go開發(fā)，使用Spark對它進行大并發(fā)寫的時候，會出現overload的狀態(tài)。

④ 不是很成熟

Dgraph從2016年開始做，總結下來并不是很成熟，有很多小問題，但是更新也比較快，很多問題很快就修復了。

總結一下，就是沒有最完美的系統，只有最合適的系統；我們做技術選型，主要就是看它的優(yōu)勢是不是我們需要的、缺陷是不是我們可以接受的，所以最后我們選擇了Dgraph作為我們的圖數據庫選型，然后基于它搭建我們的圖數據庫平臺，后續(xù)開放給需要的各個業(yè)務方去使用。

05

未來規(guī)劃

最后簡單說一下未來的規(guī)劃，我這邊主要是負責貝殼整體的搜索平臺建設，Dgraph建設只是其中的一部分，在整個搜索的架構之下。目前我們已經有基于Elasticsearch的文本檢索引擎，以及基于Dgraph的圖數據檢索引擎，后續(xù)還會有基于Faiss的向量檢索引擎。

搜索云平臺是一個業(yè)務接入平臺，將與下層的效果平臺、算法平臺、三大引擎、容器平臺全部打通，同時集成統一的服務治理能力，整體構成一個搜索中臺。以后業(yè)務方不用再關心底層的數據存儲、寫入和查詢，由搜索中臺來統一整合相關能力，然后提供統一的入口和出口，同時保障整體性能和穩(wěn)定性，從而快速對業(yè)務賦能，業(yè)務方只需要關注上層的業(yè)務邏輯和策略。

所以對圖數據庫的整體規(guī)劃是：

• 深入學習，性能、穩(wěn)定性優(yōu)化，源碼改進

• 作為搜索中臺基礎引擎，支持各種圖數據庫檢索需求

• 接入搜索云平臺，界面化操作快速配置接入，簡化運維

• 增強搜索功能，提升搜索效果

• 支持行業(yè)圖譜、關系圖譜、知識圖譜、風險管理……

特別推薦一個分享架構+算法的優(yōu)質內容，還沒關注的小伙伴，可以長按關注一下：
長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝