20180818圖數(shù)據(jù)庫概覽
1.總體趨勢
Knowledge Base of Relational and NoSQL Database Management Systems?db-engines.com
根據(jù)DB-Engines的數(shù)據(jù)庫DB-Engines排名，圖數(shù)據(jù)庫一騎絕塵，
圖數(shù)據(jù)庫2018-8的最新排名如下
Neo4j仍是最流行的圖數(shù)據(jù)庫，圖中JanusGraph的排名并不靠前，但要考慮到他是之前很火已經(jīng)被收購?fù)Ｖ拱l(fā)展的titan的fork分支，所以這點加成還是可以算上的。圖中與OrientDB趨勢基本一致的哪個黑線就是titabDB生前的排名。
CosmosDB/DatastaxStardog/Sqrrl等商業(yè)數(shù)據(jù)庫就不做分析了， 本文只對Neo4j、OrientDB、JanusGraph、Giraph、HugeGraph做下分析，其中HugeGraph并不在上面，這是百度開源的圖數(shù)據(jù)庫，簡單看了下也不錯，列在這。
2.圖數(shù)據(jù)庫組件
一個完善的圖數(shù)據(jù)系統(tǒng)應(yīng)該至少包括圖存儲及圖處理引擎，數(shù)據(jù)導(dǎo)入導(dǎo)出，管理運維，查詢和計算，商業(yè)化產(chǎn)品需要有高可用及容災(zāi)備份。
圖存儲和圖處理：這個是圖數(shù)據(jù)庫的核心，圖存儲負責將關(guān)系型數(shù)據(jù)集非結(jié)構(gòu)化數(shù)據(jù)轉(zhuǎn)成圖結(jié)構(gòu)進行存儲，這里的存儲可以為原生存儲或序列化之后的非原生存儲；圖處理則負責數(shù)據(jù)的更新及運算。
數(shù)據(jù)導(dǎo)入導(dǎo)出：數(shù)據(jù)從外界到圖存儲的導(dǎo)入導(dǎo)出能力，如從外界的json、csv，rdf等數(shù)據(jù)形式導(dǎo)入到圖數(shù)據(jù)庫中，或?qū)D數(shù)據(jù)庫中的數(shù)據(jù)導(dǎo)出來。
管理運維：管理運維則包含系統(tǒng)的監(jiān)控，配置及可視化能力
查詢和計算：主要指提供查詢語言供用戶進行圖的查詢遍歷等操作。
3.圖數(shù)據(jù)庫：
【1】Neo4j
是老牌的圖數(shù)據(jù)代表。其功能強大，性能也不錯，單節(jié)點的服務(wù)器可承載上億級的節(jié)點和關(guān)系，單節(jié)點性能不夠時也可進行分布式集群部署。
Neo4j有自己的后端存儲，不必如同JanusGraph等一樣還要依賴另外的數(shù)據(jù)庫存儲。
Neo4j在每個節(jié)點中存儲了每個邊的指針，因而遍歷時效率相當高。
Neo4j分為社區(qū)版和企業(yè)版，社區(qū)版功能受限，另外其提供可視化的客戶端感覺很不錯。
據(jù)neo4j的中國合作方的社區(qū)中描述，主要區(qū)別如下：
1、容量：社區(qū)版最多支持 320 億個節(jié)點、320 億個關(guān)系和 640 億個屬性，而企業(yè)版沒有這個限制；
2、并發(fā)：社區(qū)版只能部署成單實例，不能做集群。而企業(yè)版可以部署成高可用集群或因果集群，從而可以解決高并發(fā)量的問題；
3、容災(zāi)：由于企業(yè)版支持集群，部分實例出故障不會影響整個系統(tǒng)正常運行；
4、熱備：社區(qū)版只支持冷備份，即需要停止服務(wù)后才能進行備份，而企業(yè)版支持熱備，第一次是全量備份，后續(xù)是增量備份；
5、性能：社區(qū)版最多用到 4 個內(nèi)核，而企業(yè)能用到全部內(nèi)核，且對性能做了精心的優(yōu)化；
6、支持：企業(yè)版客戶能得到 5X10 電話支持（Neo4j 美國電話、郵件，微云數(shù)聚電話、微信、郵件）；
考慮到這些限制，要選開源免費大容量分布式的圖數(shù)據(jù)庫的可以跳過了，研究圖論及小型應(yīng)用或不差錢的項目則選其的支持服務(wù)則另當別論。另外neo4j的協(xié)議為GPLv3，這個也不適合選用。
【2】OrientDB
OrientDB據(jù)描述性能可以達到Neo4j的數(shù)倍，但也有測試表明在遍歷時磁盤空間增加，以空間換時間，遍歷性能不高，但計算最短路徑等性能高。
Neo4J和OrientDB在插入數(shù)據(jù)時候都會默認建立索引，索引的不同也造成了其不同操作的性能差異；
Neo4J：擅長遍歷圖及不存在大量關(guān)系的節(jié)點的圖計算
OrientDB：側(cè)重文檔數(shù)據(jù)庫，主要還是SB樹索引導(dǎo)致，空間浪費比較大；插入節(jié)點與neo4j差不多，但是在插入節(jié)點關(guān)系即邊時無優(yōu)化；在圖論算法上性能高，但遍歷性能低。
OrientDB也有社區(qū)版及企業(yè)版，但是其基于Apache2.0協(xié)議，這個更友好
【3】JanusGraph
Distributed graph database?janusgraph.org
JanusGraph基于Titan發(fā)展而來，包含其所有功能，采用Tikerpop的Gremlin圖查詢語言，
有單獨的后端存儲，支持Cassandra/HBase/BerkeleyDB等做存儲，支持Solr/ES/Lucence等做圖索引
支持Spark GraphX/Giraph等圖分析計算引擎及Hadoop分布式計算框架
原生支持集成了Tinkerpop系列組件：Gremlin查詢語言，Gremlin-Server及Gremlin applications。
采用很友好的Apache2.0協(xié)議，支持對接可視化組件如Cytoscape， plugin for Apache TinkerPop，Graphexp，KeyLines by Cambridge Intelligence，Linkurious
【4】HugeGraph
王二鐵：百度安全開源大規(guī)模圖數(shù)據(jù)庫HugeGraph?zhuanlan.zhihu.com
HugeGraph是支持Apache TinkerPop 3框架和Gremlin圖查詢語言的大型分布式圖數(shù)據(jù)庫，據(jù)其描述其性能是相當強勁，剛開源不久。不過貌似每個都說自己是最好最強的...
HugeGraph是一款面向分析型，支持批量操作的圖數(shù)據(jù)庫系統(tǒng)，它能夠與大數(shù)據(jù)平臺無縫集成，有效解決海量圖數(shù)據(jù)的存儲、查詢和關(guān)聯(lián)分析需求。HugeGraph支持HBase和Cassandra等常見的分布式系統(tǒng)作為其存儲引擎來實現(xiàn)水平擴展。HugeGraph可以與Spark GraphX進行鏈接，借助Spark GraphX圖分析算法（如PageRank、Connected Components、Triangle Count等）對HugeGraph的數(shù)據(jù)進行分析挖掘。
HugeGraph的主要特點包括：
基于TinkerPop 3 API實現(xiàn)，支持Gremlin圖查詢語言；
擁有完善的周邊工具鏈和相關(guān)功能組件，可以滿足圖數(shù)據(jù)庫開發(fā)的基本需求，提供易用高效的使用體驗；
具備獨立的Schema管理模塊，豐富完善的Schema校驗機制，確保圖數(shù)據(jù)庫中的數(shù)據(jù)完整性和一致性；
支持數(shù)據(jù)的備份和還原，可以在不同的后端存儲之間轉(zhuǎn)換；
多種ID生成策略應(yīng)對不同業(yè)務(wù)場景，擁有完善的索引管理機制，支持多種索引查詢操作；
可以實現(xiàn)與Hadoop、Spark、HBase、ES等大數(shù)據(jù)系統(tǒng)集成，支持多種Bulk Load操作，實現(xiàn)海量數(shù)據(jù)快速插入；
除上述特定之外，HugeGraph還針對圖數(shù)據(jù)庫的高頻應(yīng)用（例如：ShortestPath、k-out、k-neighbor等）做了特定性能優(yōu)化，并且為用戶提供更為高效的使用體驗
我的感覺是跟titan/JanusGraph蠻像的
看其致謝果不其然，不過里面還是蠻多創(chuàng)新及擴展的，如果他能持續(xù)的接納Janus和DataStax的新特性并長久發(fā)展的話用這個倒是不錯。
HugeGraph relies on theTinkerPopframework, we refer to the storage structure ofJanusGraphand the schema definition ofDataStax. Thanks to Tinkerpop, thanks to JanusGraph and Titan, thanks to DataStax. Thanks to all other organizations or authors who contributed to the project.
3.圖分析系統(tǒng)
上面簡單介紹了幾個圖數(shù)據(jù)庫，也提到其后端存儲，neo4j等使用自己的原生圖存儲，而JanusGraph/HugeGraph等則用非原生圖存儲。
原生圖存儲一般都是經(jīng)過專門為了存儲和管理圖結(jié)構(gòu)而優(yōu)化的，遍歷查詢性能很高，但掐非遍歷類的查詢則不占優(yōu)勢，且為了全局搜索還會占用大量內(nèi)存。
非原生圖存儲通常將圖結(jié)構(gòu)序列化存儲到RDBMS或其他通用存儲中，如JanusGraph的HBase/Cassandra，HugeGraph甚至增加了對MySQL等的支持。
一個圖分析系統(tǒng)除了圖數(shù)據(jù)庫外還要有圖計算引擎，主要目的是為了進行除遍歷外的圖算法分析。前述的圖數(shù)據(jù)庫相當于OLTP，而圖計算則相當于OLAP。有的圖數(shù)據(jù)庫也繼承了少量的圖計算能力，但真正的大型系統(tǒng)還是需要單獨的計算框架。
基于圖的并行計算框架，有g(shù)oogle的Pregel，基于Spark的GraphX，Apache下的Giraph/HAMA以及GraphLab，其中Giraph是Pregel的開源實現(xiàn)。
