一、圖數(shù)據(jù)庫neo4j和spark下面的graphx有什么區(qū)別

neo4j是native graph database，也就是有自己的數(shù)據(jù)庫存儲(chǔ)。它的長處在于支持交互式查詢，屬于oltp系統(tǒng)，很多人說不支持分片存儲(chǔ)使其無法應(yīng)付海量數(shù)據(jù)，本人覺得恰恰相反，可以說neo4j的存儲(chǔ)方式是教科書式的以空間換時(shí)間，每臺(tái)服務(wù)器配備ssd磁盤陣列雖然貴，但是可以大幅減少分片存儲(chǔ)的帶寬占用和通信時(shí)間開銷，保證oltp的效率。

neo4j很容易上手，特有的cypher查詢語言以畫草圖的方式查詢和建模數(shù)據(jù)，很直觀。適當(dāng)構(gòu)建查詢計(jì)劃的情況下，neo4j的查詢效率很高，能夠迅速從整網(wǎng)中找出符合特定模式的子網(wǎng)，供隨后分析之用。

此外，neo4j實(shí)現(xiàn)了tinkerpop接口，tinkerpop是剛剛畢業(yè)的一個(gè)阿帕奇項(xiàng)目，有望建立圖數(shù)據(jù)庫的一套標(biāo)準(zhǔn)用戶接口。同樣實(shí)現(xiàn)tinkerpop的還有titan，orient等主流圖數(shù)據(jù)庫。

再來看graphX。

graphX是spark的系統(tǒng)組件，存儲(chǔ)是基于spark rdd的，有節(jié)點(diǎn)和邊兩種rdd。熟悉spark的朋友對(duì)rdd該不會(huì)陌生，spark通過緩存rdd的操作節(jié)省了大量計(jì)算和io開支，因此spark特別適合對(duì)海量數(shù)據(jù)進(jìn)行運(yùn)算，此理同樣適用于graphX。因此，graphX自設(shè)計(jì)之初就是奔著圖計(jì)算的目標(biāo)去的，屬于olap系統(tǒng)，而非oltp系統(tǒng)。

graphX有豐富的函數(shù)庫，能完成很多經(jīng)典圖算法，如pagerank、三角計(jì)數(shù)、社群發(fā)現(xiàn)、最短路徑計(jì)算等等。此外，圖存儲(chǔ)和計(jì)算的方式不禁讓人想到神經(jīng)網(wǎng)絡(luò)算法，如果將隱層用節(jié)點(diǎn)rdd表示，隱層之間的邊用邊rdd表示，運(yùn)用graphX的計(jì)算優(yōu)勢(shì)搭建起一套多層神經(jīng)網(wǎng)絡(luò)的想法很美妙，這應(yīng)該就是MLlab相應(yīng)算法模塊的工作原理。

因此跟graphx相關(guān)的概念集中在圖計(jì)算，而非圖存儲(chǔ)和查詢領(lǐng)域。所以經(jīng)常瀏覽db-engines的朋友們不難發(fā)現(xiàn)，圖數(shù)據(jù)庫列表里就沒有g(shù)raphx這一項(xiàng)。在比較圖存儲(chǔ)和圖查詢性能時(shí)，比較集合多是neo4j、orientdb、titan、arangodb等圖數(shù)據(jù)庫系統(tǒng)。而比較圖計(jì)算時(shí)，比較集合多是graphlab、giraph、graphX。

簡言之，圖數(shù)據(jù)庫系統(tǒng)和圖計(jì)算系統(tǒng)不是一回事：前者是為了存儲(chǔ)完整數(shù)據(jù)，并根據(jù)需求從中查詢數(shù)據(jù)子集供分析展示之用；后者的任務(wù)是拿到一個(gè)圖結(jié)構(gòu)的數(shù)據(jù)集，從中計(jì)算一些有用的東西。

如果你有隨時(shí)增長的海量數(shù)據(jù)，希望以圖的方式存儲(chǔ)這些數(shù)據(jù)，從而能在需要時(shí)順利挖出一個(gè)子圖來，那就要借助于圖數(shù)據(jù)庫，此時(shí)如果你有充足的資金，neo4j是不二之選，否則就要從db-engines里面第二名以后的一眾數(shù)據(jù)庫里挑選。進(jìn)一步，如果你的需求不只停留在查詢，還要依據(jù)查詢結(jié)果計(jì)算出一些圖的特征來，那么建議你將圖數(shù)據(jù)庫系統(tǒng)同圖計(jì)算系統(tǒng)聯(lián)合使用。

延伸閱讀：

二、圖數(shù)據(jù)庫優(yōu)點(diǎn)有什么

使用圖（或者網(wǎng)）的方式來表達(dá)現(xiàn)實(shí)世界的關(guān)系很直接、自然，易于建模。比如某人喜歡看某電影，就可以建立一條邊連接這個(gè)人和這部電影，這條邊就叫做“喜歡”邊，同時(shí)這個(gè)人還可以有其它邊，比如“朋友”邊、“同學(xué)”邊等，同樣這個(gè)電影也可以有其它邊，比如“導(dǎo)演”邊、“主演”邊等，這樣就構(gòu)建了自然的關(guān)系網(wǎng)。圖數(shù)據(jù)庫可以很高效的插入大量數(shù)據(jù)。圖數(shù)據(jù)庫面向的應(yīng)用領(lǐng)域數(shù)據(jù)量可能都比較大，比如知識(shí)圖譜、社交關(guān)系、風(fēng)控關(guān)系等，總數(shù)據(jù)量級(jí)別一般在億或十億以上，有的甚至達(dá)到百億邊。mysql不做分表分庫的情況下插入百萬數(shù)據(jù)基本就慢到不行，圖數(shù)據(jù)庫基本能勝任億級(jí)以上的數(shù)據(jù)，比如neo4j、titan(janus)、hugegraph等圖數(shù)據(jù)庫，持續(xù)插入十億級(jí)的數(shù)據(jù)基本還能保持在一個(gè)較高的速度。圖數(shù)據(jù)庫可以很高效的查詢關(guān)聯(lián)數(shù)據(jù)。傳統(tǒng)關(guān)系型數(shù)據(jù)庫不擅長做關(guān)聯(lián)查詢，特別是多層關(guān)聯(lián)（比如查我的好友的好友有哪些人），因?yàn)橐话銇碚f都需要做表連接，表連接是一個(gè)很昂貴的操作，涉及到大量的IO操作及內(nèi)存消耗。圖數(shù)據(jù)庫對(duì)關(guān)聯(lián)查詢一般都進(jìn)行針對(duì)性的優(yōu)化，比如存儲(chǔ)模型上、數(shù)據(jù)結(jié)構(gòu)、查詢算法等，防止局部數(shù)據(jù)的查詢引發(fā)全部數(shù)據(jù)的讀取。