一、圖數(shù)據(jù)庫

優(yōu)點

1、圖數(shù)據(jù)庫可以很高效的插入大量數(shù)據(jù)。圖數(shù)據(jù)庫面向的應(yīng)用領(lǐng)域數(shù)據(jù)量可能都比較大，比如知識圖譜、社交關(guān)系、風(fēng)控關(guān)系等，總數(shù)據(jù)量級別一般在億或十億以上，有的甚至達(dá)到百億邊。mysql不做分表分庫的情況下插入百萬數(shù)據(jù)基本就慢到不行，圖數(shù)據(jù)庫基本能勝任億級以上的數(shù)據(jù)，比如neo4j、titan(janus)、hugegraph等圖數(shù)據(jù)庫，持續(xù)插入十億級的數(shù)據(jù)基本還能保持在一個較高的速度。

2、圖數(shù)據(jù)庫可以很高效的查詢關(guān)聯(lián)數(shù)據(jù)。傳統(tǒng)關(guān)系型數(shù)據(jù)庫不擅長做關(guān)聯(lián)查詢，特別是多層關(guān)聯(lián)（比如查我的好友的好友有哪些人），因為一般來說都需要做表連接，表連接是一個很昂貴的操作，涉及到大量的IO操作及內(nèi)存消耗。圖數(shù)據(jù)庫對關(guān)聯(lián)查詢一般都進(jìn)行針對性的優(yōu)化，比如存儲模型上、數(shù)據(jù)結(jié)構(gòu)、查詢算法等，防止局部數(shù)據(jù)的查詢引發(fā)全部數(shù)據(jù)的讀取。

3、圖數(shù)據(jù)庫提供了針對圖檢索的查詢語言，比如Gremlin、Cypher等圖數(shù)據(jù)庫語言。圖查詢語言大大方便了關(guān)聯(lián)分析業(yè)務(wù)的持續(xù)開發(fā)，傳統(tǒng)方案在需求變更時往往要修改數(shù)據(jù)存儲模型、修改復(fù)雜的查詢腳本，圖數(shù)據(jù)庫已經(jīng)把業(yè)務(wù)表達(dá)抽象好了。

選擇

實際上開源的、流行的圖數(shù)據(jù)庫就只有以下幾種：

Neo4j就不說了，基本是圖數(shù)據(jù)庫這塊的領(lǐng)跑者，但實話實說，費用也不低，因此需要慎重考慮，如果是土豪，當(dāng)我沒說。

OrientDB和ArangoDB都是老牌的圖數(shù)據(jù)庫了，正因為早，所以呢，框架和架構(gòu)有點老，因為是從單機版拓展而來的，對于集群和分布式支持的不是那么舒服。但瑕不掩瑜。

JanusGraph和Dgraph是比較新的，對分布式和集群支持還行，費用也不高。

另外，特別提一下：TigerGraph，是最貼合中國國情的圖數(shù)據(jù)庫系統(tǒng)，目前在國內(nèi)用的還不錯。

延伸閱讀：

二、圖數(shù)據(jù)庫主要特點

存儲計算分離

對于 Nebula Graph 來講，有這么幾個技術(shù)特點：名列前茅個就是采用了存儲計算分離的架構(gòu)。這樣架構(gòu)主要的考慮其實前面幾個 Talk大家都已經(jīng)討論了很多，主要好處就是為了上云或者說 彈性 ， 方便單獨擴容 。上午的 Talk：HBase on Cloud 也有提到，業(yè)務(wù)水位總是很難預(yù)測的，一段時間存儲不夠了，有些時候計算不夠了。在云上或者使用容器技術(shù)，計算存儲分離的架構(gòu)運維起來會比較方便，成本也更好控制。大家使用 HBase 那么久，這方面的感觸肯定很多。

查詢語言 nGQL

Nebula Graph 的第二個技術(shù)特點是它的查詢語言，我們稱為 nGQL，比較接近 SQL。少數(shù)大一點的語法差異就是 不用嵌套 （embedding）。大家都知道嵌套的 SQL，讀起來是非常痛苦的，要從里向外讀。

支持多種后端存儲

第三個特點就是 Nebula Graph 支持多種后端存儲，除了原生的引擎外，也支持 HBase。因為很多用戶，對 HBase 已經(jīng)相當(dāng)熟悉了，并不希望多一套存儲架構(gòu)。從架構(gòu)上來說，Nebula Graph 是完全對等的分布式系統(tǒng)。

計算下推

和 HBase 的 CoProcessor 一樣，Nebula Graph 支持?jǐn)?shù)據(jù)計算下推。數(shù)據(jù)過濾，包括一些簡單的聚合運算，能夠在存儲層就做掉，這樣對于性能來講能提升會非常大。