「JanusGraph與HugeGraph」圖形數據庫 - 技術選型-功能對比
Tinkerpop highlevel-arch
- gremlin server: httpserver/websocket server接收標準的gremlin dsl語法，自身相當於一個計算節點，完成圖的遍歷，或者操作DML語言，操作底層OLTP圖庫。
- gremlin traversal language: 圖的查詢遍歷語言及語言解釋實現，類似sqlparser
- provider strategies: vendor可自定義的策略，如對某些遍歷步驟可優化，g.v("filter")可走全文搜索，而非全表scan。
- core api(for OLTP) : 圖庫的curd操作，包括traveral，追求低延時，高吞吐，儘量少的慢查詢。
- graph computer(for OLAP) : 有MR/spark引擎，通過MR分治思想或DAG圖做一些大數據處理，充分利用多機計算能力,這個規範是可選實現。
核心在於提供gremlin查詢語法及引擎，類似sqlparse,把查詢語言轉變成執行計劃。還有core-api 節點，邊的抽象，爲底層OLTP&OLAP引擎可以自由切換成其他廠商實現，當然也內嵌了一套內存圖庫實現，以供vendor參考。
OLTP和OLAP
列表數據存儲在一系列列中，而在行表中，它將表記錄存儲在一系列行中。
oltp vs olap
OLTP(使用行表)
實時，有限數據訪問，隨機數據訪問，順序處理，查詢。 例如：Hbase、TinkerPop
- OLTP查詢：行表用於有效地返回整行，適用於需要頻繁變換表（需要根據某些條件更新/刪除錶行時）的OLTP方案。在這些情況下，行表與列表相比具有明顯的優勢。
- 點查詢：行表也適用於點查詢（例如，基於某些where子句條件僅選擇幾條記錄的查詢）。
- 小維度表：行表也適用於創建小維度表，因爲這些表可以創建爲複製表（在所有數據服務器上覆製表數據）。
- 創建索引：行表還允許在表的某些列上創建索引以提高性能。
OLAP(使用列表)
長時間運行，訪問整個數據集，順序數據訪問，並行處理，批處理。 例如：Spark、Hive、Cassandra
- 分析查詢：列表對於OLAP查詢具有明顯的優勢，因此建議將此類查詢中涉及的大表創建爲列式表。這些表很少發生變異（刪除/更新）。對於列表上的給定查詢，只會讀取所需的列（因爲只需要掃描所需的子集列），從而提供更好的掃描性能。因此，與行表相比，聚合查詢在列表上執行得更快。
- 數據壓縮：列表提供的另一個優點是可以高效地壓縮數據，從而減少大型表的總存儲空間。
列表不適用於OLTP方案。在這種情況下，建議使用行表。
JG和HG的OLTP/OLAP
一個圖分析系統除了圖數據庫外還要有圖計算引擎，主要目的是爲了進行除遍歷外的圖算法分析。
其後端存儲中，neo4j等使用自己的原生圖存儲，而JG/HG等則用非原生圖存儲，通常將圖結構序列化存儲到RDBMS中。
原生圖存儲一般都是經過專門爲了存儲和管理圖結構而優化的，遍歷查詢性能很高，但掐非遍歷類的查詢則不佔優勢，且爲了全局搜索還會佔用大量內存。
前述的圖數據庫相當於OLTP，而圖計算則相當於OLAP。有的圖數據庫也繼承了少量的圖計算能力，但真正的大型系統還是需要單獨的計算框架。
OLTP實現方法
JG和HG集成了各大開源存儲系統，如hbase，Cassandra，BerkeleyDB，以及整合開源搜索引擎，如solr, ElasticSearch. 總體來說實現了一個OLTP圖庫. 兩者架構大體相似。
（1）極簡方案
對於測試或者單應用來說，JG/HG服務可以和後端存儲/索引部署在一臺機器上
（2）快速上手方案對於測試或者單應用來說，JG/HG服務可以和後端存儲/索引部署在一臺機器上。
（下左圖）這種場景是大多數用戶在剛開始使用JG/HG時可能要選擇的場景。它提供了可伸縮性和容錯性所需要的最少服務數量。每個JG/HG服務運行在單獨的存儲後端和可選的索引後端。
（3）建議部署方案
（上右圖）JG/HG服務實例集羣不和存儲後端集羣和索引後端集羣部署在一起，他們被分配到不同的服務器上集羣上。建議不同的組件集羣（JG/HG服務、索引後端、存儲後端）部署到不同的服務器集羣上，這樣能夠方便擴容和管理，相互之間也互不依賴。這爲維護更多的服務器提供了更高的靈活性。
（4）嵌入式方案
基於JVM的應用程序可以直接嵌入一個JG/HG包，而不用連接到JG/HG服務。雖然這樣可以減少管理開銷，這導致不能對JG/HG進行單獨擴容。JG/HG嵌入式部署方案是其他部署方案的變種，JG/HG只是從服務器直接移動到應用程序中，因爲它現在只是用作庫，而不是獨立的服務。
OLAP實現方法
基於圖的並行計算框架，有google的Pregel，基於Spark的GraphX，Apache下的Giraph/HAMA以及GraphLab，其中Giraph是Pregel的開源實現。
OLAP標準在tinkerpop框架裏面是可選的，使用自身的實現爲單機內存實現，分佈式的實現：
- 在janusGraph中可通過使用Spark集羣進行distributed OLAP方面工作（spark僅作爲底層計算層，api還用Gremlin）.
- 在HugeGraph中通過hugegraph-spark工具將圖數據從HG(數據源)抽取到Spark集羣進行distributed OLAP方面工作（獨立使用GraphX api 進行業務邏輯計算）
兩者對比
圖數據庫組件
一個完善的圖數據系統應該至少包括圖存儲及圖處理引擎，數據導入導出，管理運維，查詢和計算，商業化產品需要有高可用及容災備份。
相同點：
|
功能 |
HugeGraph |
JanusGraph |
|
|
|
|
|
索引後端 |
Solr、ES 等，用於加快訪問速度並支持更復雜的查詢語句 |
|
|
分佈式OLTP後端 （圖存儲） |
集成Hbase、Cassandra 等 都是準實時的離線圖計算框架：數據按batch大小計算 |
|
|
圖處理 |
都是使用Tinkerpop3 |
|
|
分佈式OLAP引擎 |
集成Spark |
|
|
Gremlin遍歷 （查詢和計算） |
都是單機計算。複雜如PageRank等才提交給Spark |
|
|
高可用及容災備份 |
底層Hbase有，HG/JG都沒實現 （以後商業版HG會實現） |
|
|
水平擴展 |
支持 |
|
|
不同的後端存儲之間轉換 |
支持 |
|
|
ACID特性和最終一致性 |
支持，使用HBase後端 |
|
|
都沒有實現分佈式 （區別於存儲分佈式） |
從janusGraph-9.9.2章節最新的配置信息可知：
|
|
|
異常處理 |
異常處理很low，經常不知道錯誤的原因 |
|
|
|
|
|
是不是titan/JanusGraph看起來很相似？！（如果在JanusGraph之上做一些封裝，對接janusService和可視化那就更像了）
看其致謝果不其然，不過裏面還是有創新和擴展的，如果他能持續的接納Janus的優點並對其擴展和生態封裝並長久發展的話用這個倒是不錯，可惜就在。。。封裝完就收費了。
HugeGraph relies on the TinkerPopframework, we refer to the storage structure of JanusGraph and 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.
異同點：
|
功能 |
HugeGraph |
JanusGraph |
|
特性 |
把其它組件封裝一下，變成自己的 |
與其他組件的交互(DIY)能力強 |
|
分佈式OLAP |
集成並使用Spark-2.1.1 GranphX API （已轉向收費） |
使用Gremlin API 並將Spark-2.2.x集成爲底層計算引擎 |
|
可視化工具 |
僅使用自帶HugeGraph-Studio |
|
|
OLAP複雜計算 |
Titan比GraphX快，所以：JG > HG（來自知乎） |
|
|
數據導入
|
僅支持本地csv，json文件導入 （更多：看Hugegraph數據導入導出總結章節） |
據說支持本地csv等文件、hdfs導入 （無參考文檔）
批量導入：與HugeGraph一樣需要嚴格的數據格式，但JanusGraph中沒有實現導入數據的方法。
|
|
圖管理 |
無從下手配置與創建多圖 （缺少相關文檔，也不支持指定OLAP引擎） |
方便從配置文件創建不同的圖 1.ConfiguredGraphFactory方式，使用默認配置與後端創建圖：
2.JanusGraphFactory方式，使用自定義配置指定存儲後端與OLAP計算後端（如使用spark集羣）等初始化圖：
|
|
管理運維 管理/優化複雜性 |
難（耦合高） |
較難（集成多） |
|
Schema管理模塊 |
不支持自動創建schema |
支持自動創建schema |
|
高頻圖算法
|
封裝了（ShortestPath、k-out、k-neighbor等），使用更友好
|
通過Gremlin 代碼自行實現 |
|
可插入節點數 |
千萬級，節點id長度超過千萬插入失敗 |
可過億（JG相對於HG更大規模） |
|
節點類型 |
Int/String（必須小於9位數） |
Int（長整形，位數不限） |
|
hbase後端版本 |
Hbase-2 （可能是比Titan快點的原因） |
Hbase-1 （繼承了老Titan，還未做升級） |
|
社區支持 |
百度 |
IBM、google等 |
|
數據量 |
|
1. 假如有 1 billion 的訂單，10 billion 的邊(十億用戶和商品，100以交易記錄，比較符合淘寶的數據量) 分別使用上面的三種辦法所需時間爲：大於10天，2天，8個小時。所需要的資源量：很少(因爲可以一條一條插入)，很多（因爲要join），比較多(需要批量導入)
|
|
邊信息 |
可有無向邊 |
僅支持有向邊 |
|
全文檢索功能 |
不支持 |
通過ES |
|
|
|
|
JanusGraph可視化工具：
Cytoscape：www.cytoscape.org/
Gephi plugin for Apache TinkerPop：tinkerpop.apache.org/docs/current/reference/
Graphexp：github.com/bricaud/graphexp
KeyLines by Cambridge Intelligence：cambridge-intelligence.com/visualizing-janusgraph-new-titandb-fork/
Linkurious：doc.linkurio.us/ogma/latest/tutorials/janusgraph/
問題
- 並沒有實現真正意義上的事務。
- 沒有發揮MPP思想，一個計算節點負責所有的圖遍歷。存儲層hbase分佈式化了，但自身計算節點並沒有分佈式化。janusGraph把hbase當做黑盒，純客戶端，圖遍歷拉取所有數據，沒有深入定製到表格存儲裏面，這也是可預見可修改的地方。
- gremlin-server單機運算處理能力有限，勢必要水平擴展，但core包中使用了有很多cache,有狀態的，集羣模式下要考慮內存狀態一致性問題
hugegraph是高可用的嗎，是否支持動態擴展？--來自社區
高可用可以從多個維度來講，包括
* 圖的服務器引擎高可用，目前HugeGraphServer服務本身並沒有高可用實現，只有一套簡單的服務監控及失效拉起的功能（服務器的高可用在開發計劃中）
* 存儲後端高可用，卡桑德拉或HBase的等本身支持高可用。
× 所以，HG也並沒有實現分佈式
用戶併發性：
如果元數據與數據都在Cassandra數據庫中存儲，理論上我是可以啓動多個HugeGraphServer來對我服務的對嗎??
：HugeGraphServer服務有緩存機制，元數據和圖數據都會緩存，多個HugeGraphServer同時連一個Cassandra後端，可能會出現數據不一致的現象
侷限
- g.V(... ids) 或g.E(... ids) 指向性query，配合hbase使用沒問題，但g.V().has(filter） 可就是全表掃描了，避免該問題要配合全文搜索引擎使用。 g.V()默認實現GraphStep會把vetex信息拉倒當前進程，會dump圖庫所有節點信息，操作重，條目過多很容易就OOM。
- DSL語言設計之初就沒有考慮過MPP體系，計算能力全壓在當前進程，架設成常駐進程很容易出現CPU打滿，QPS不足等問題。
總結：
- HugeGraph基於TinkerPop，很大程度借鑑了Titan和JanusGraph項目，用到了JanusGraph的storage存儲框架和Titan的schema定義框架。
- Hugegraph-studio, hugegraph-tool是JanusGraph沒有的組件，JanusGraph的可視化需要和Gephi這樣的工具結合起來用。
- 不管JanusGraph還是HugeGraph，都只是封裝層中間件，底層存儲都是集成Nosql做存儲引擎，大同小異。
- 數據導入配置都很複雜
還有一些彙報數據，這裏不便放出，總之，跟領導彙報完，我最後選了JanusGraph，並已部署結束開始功能測試了，放出這篇文章的時候我的知識圖譜平臺架構剛寫完，我們的最終目的是做一個個性化的"HugeGraph"平臺產品，甚至從功能的豐富性上超越它。