一、圖數(shù)據(jù)庫neo4j和spark下面的graphx有什么區(qū)別
neo4j是native graph database,也就是有自己的數(shù)據(jù)庫存儲。它的長處在于支持交互式查詢,屬于oltp系統(tǒng),很多人說不支持分片存儲使其無法應(yīng)付海量數(shù)據(jù),本人覺得恰恰相反,可以說neo4j的存儲方式是教科書式的以空間換時間,每臺服務(wù)器配備ssd磁盤陣列雖然貴,但是可以大幅減少分片存儲的帶寬占用和通信時間開銷,保證oltp的效率。
neo4j很容易上手,特有的cypher查詢語言以畫草圖的方式查詢和建模數(shù)據(jù),很直觀。適當(dāng)構(gòu)建查詢計(jì)劃的情況下,neo4j的查詢效率很高,能夠迅速從整網(wǎng)中找出符合特定模式的子網(wǎng),供隨后分析之用。
此外,neo4j實(shí)現(xiàn)了tinkerpop接口,tinkerpop是剛剛畢業(yè)的一個阿帕奇項(xiàng)目,有望建立圖數(shù)據(jù)庫的一套標(biāo)準(zhǔn)用戶接口。同樣實(shí)現(xiàn)tinkerpop的還有titan,orient等主流圖數(shù)據(jù)庫。
再來看graphX。
graphX是spark的系統(tǒng)組件,存儲是基于spark rdd的,有節(jié)點(diǎn)和邊兩種rdd。熟悉spark的朋友對rdd該不會陌生,spark通過緩存rdd的操作節(jié)省了大量計(jì)算和io開支,因此spark特別適合對海量數(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ì)算等等。此外,圖存儲和計(jì)算的方式不禁讓人想到神經(jīng)網(wǎng)絡(luò)算法,如果將隱層用節(jié)點(diǎn)rdd表示,隱層之間的邊用邊rdd表示,運(yùn)用graphX的計(jì)算優(yōu)勢搭建起一套多層神經(jīng)網(wǎng)絡(luò)的想法很美妙,這應(yīng)該就是MLlab相應(yīng)算法模塊的工作原理。
因此跟graphx相關(guān)的概念集中在圖計(jì)算,而非圖存儲和查詢領(lǐng)域。所以經(jīng)常瀏覽db-engines的朋友們不難發(fā)現(xiàn),圖數(shù)據(jù)庫列表里就沒有g(shù)raphx這一項(xiàng)。在比較圖存儲和圖查詢性能時,比較集合多是neo4j、orientdb、titan、arangodb等圖數(shù)據(jù)庫系統(tǒng)。而比較圖計(jì)算時,比較集合多是graphlab、giraph、graphX。
簡言之,圖數(shù)據(jù)庫系統(tǒng)和圖計(jì)算系統(tǒng)不是一回事:前者是為了存儲完整數(shù)據(jù),并根據(jù)需求從中查詢數(shù)據(jù)子集供分析展示之用;后者的任務(wù)是拿到一個圖結(jié)構(gòu)的數(shù)據(jù)集,從中計(jì)算一些有用的東西。
如果你有隨時增長的海量數(shù)據(jù),希望以圖的方式存儲這些數(shù)據(jù),從而能在需要時順利挖出一個子圖來,那就要借助于圖數(shù)據(jù)庫,此時如果你有充足的資金,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)系很直接、自然,易于建模。比如某人喜歡看某電影,就可以建立一條邊連接這個人和這部電影,這條邊就叫做“喜歡”邊,同時這個人還可以有其它邊,比如“朋友”邊、“同學(xué)”邊等,同樣這個電影也可以有其它邊,比如“導(dǎo)演”邊、“主演”邊等,這樣就構(gòu)建了自然的關(guān)系網(wǎng)。圖數(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ù)基本還能保持在一個較高的速度。圖數(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都需要做表連接,表連接是一個很昂貴的操作,涉及到大量的IO操作及內(nèi)存消耗。圖數(shù)據(jù)庫對關(guān)聯(lián)查詢一般都進(jìn)行針對性的優(yōu)化,比如存儲模型上、數(shù)據(jù)結(jié)構(gòu)、查詢算法等,防止局部數(shù)據(jù)的查詢引發(fā)全部數(shù)據(jù)的讀取。