ArangoDB、Neo4j、OrientDB性能比較
系統信息
圖數據庫版本信息
| 圖數據庫 |
版本 |
備注 |
| Neo4J |
3.2 |
|
| OrientDB |
2.2.x |
|
| ArangoDB、 |
3.1.19 |
|
| Titan |
1.0.0 |
需要集群，暫不分析 |
OS&庫信息
- OS：Ubuntu 16.04
- 虛擬機VM12
- python3驅動
- python-arango
- neo4j-driver
- PyOrient
- 繪圖庫：MatPlotLib+Numpy
- 性能監測庫：psutil
測試信息
- 測試所得四張圖分別為
- 數量時間圖，斜率越小性能越好
- CPU平均占用率圖
- RAM使用圖
- 硬盤剩余空間圖
圖數據庫分類
NoSQL數據庫類別：
- 鍵值(Key-Value)數據庫
- 面向文檔(Document-Oriented)數據庫
- 列存儲(Wide Column Store/Column-Family)數據庫
- 圖(Graph-Oriented)數據庫
單次寫入速率分析
- 圖數據庫引擎全部打開，自動繪圖
一萬節點十萬插入速度
插入一萬頂點V
一萬節點-插入節點性能分析
簡單分析
- 三個圖數據庫所消耗插入節點時間相差無幾，性能高低依次OrientDB>Neo4J>ArangoDB
- ArangoDB的節點hash可能隨節點數量的提高而降低插入節點的性能
- CPU使用情況為Neo4J使用率高於OrentDB，ArangoDB在最后有個提升，且結合第一張圖ArangoDB在最后斜率升高推測ArangoDB可能插入節點斜率隨着節點數的增多而降低。這是因為ArangoDB在存儲節點時候會計算
_key的Hash而產生的性能降低，但是節點插入的速度的Y軸與后面計算的Y軸不在同一數量級上，ArangoDB犧牲插入節點的性能提高后續的性能是很值得。 - 對RAM使用情況，ArangoDB>OrientDB>Neo4J
- 硬盤使用情況，OrientDB>Neo4J>ArangoDB
結論
在插入節點這步驟：
- ArangoDB建立Hash索引，所以插入節點時候的性能會稍微有點低，RAM占用最大，所消耗的存儲空間最小。
- Neo4J進行了CPU的密集計算，對RAM和硬盤的占用率不高。
- OrientDB插入耗時最短，CPU，RAM也占用較低，建立BS樹索引的優勢，但是磁盤消耗大，其以文檔形式直接存儲數據而不進行前期的預處理，結合后面的數據可以看出，OrientDB和ArangoDB雖然都支持文檔數據庫和圖數據，但OrientDB更加偏重於文檔數據的存儲，而不是圖數據的分析。
插入十萬邊E
一萬節點-插入邊性能分析
簡單分析
- 插入邊中，耗時長短依次：OrientDB>ArangoDB>Neo4J，從這可以看出，沒有在節點環節作出合適預處理的OrientDB在插入關系的時候的性能遠遠落后於ArangoDB和Neo4J。
- CPU占用上，Neo4J>OrientDB>ArangoDB
- 磁盤使用情況：Neo4J>OrientDB>ArangoDB
結論
- 在插入邊的情況下，ArangDB性能依舊稍稍落后於Neo4J，但其在CPU、RAM和磁盤占用上都不如ArangoDB
- OrientDB則是性能落后很多，且插入邊時候磁盤的剩余空間波動巨大，可能是其中產生了緩存文件之類。
- OrientDB在插入E時性能差距太大
遍歷鄰節點
- 鄰節點深度為1
- 采用了三個圖數據庫內置的廣度優先算法
一萬節點遍歷
一萬節點-鄰節點查詢性能分析
分析
- ArangoDB在存儲節點時候所消耗的性能在做圖計算時候帶來了巨大的性能優勢，便利和最短路徑都因此受益，便利時間依次：OrientDB>Neo4J>ArangoDB
- Neo4J的圖為折線，這意味着如果沒有相鄰節點Neo4J可以快速發現，而OrientDB和ArangoDB則會逼近直線。
- Neo4J節點存在大量關系其運行時間消耗大，關系越多耗時越久，不適合大關系的圖。
- Neo4J和ArangoDB是圖遍歷中性能較好的兩種，Neo4J依賴於CPU的計算力去遍歷圖，ArangoDB則依賴內存
- Neo4J和ArangoDB皆不會因為遍歷而消耗磁盤空間，OrientDB會。
- OrientDB在遍歷時候消耗的磁盤空間可能就是為了優化后面圖算法所做的准備，這可以在最短路徑的圖算法結論中看出。
- 以磁盤空間來優化算法速度。
- OrientDB遍歷性能太低
最短路徑
- 采用了三個圖數據庫內置的Dijkstra算法
一萬節點相互最短路徑
一萬節點-兩節點最短路徑性能分析
分析
- 在查找兩節點最短路徑時候，所消耗時間：Neo4J>OrientDB>ArangoDB
- Neo4J依舊是折線，綜合兩個圖算法，Neo4J有辦法快速找到沒有關系的孤立節點。因為index-free adjacency的關系。
- OrientDB在做最短路徑時候性能相比Neo4J高很多。
- 對CPU的利用：Neo4J>OrientDB>ArangoDB，且OrientDB很穩定
- 在做最短路徑時候，除了ArangoDB，其他兩個都會消耗磁盤空間。
綜合分析
Neo4J、OrientDB、ArangoDB在插入數據時候都會默認的建立索引，性能的差距有部分就是因為自身索引的選擇導致的，各自理念不同；
- Neo4J：index-free adjacency，擅長遍歷圖，以及計算不存在大量關系的節點的圖
- OrientDB：側重文檔數據庫，主要還是SB樹索引導致，空間浪費比較大；插入節點與另外兩個數據庫相差無幾，但是在插入關系中另外兩個數據庫都做了優化，OrientDB無優化，就掛了；在圖論計算力上性能優異，但是在遍歷中還是優化不夠，被甩開。
- ArangoDB：對於V和E文檔都建立了索引，
_key、_from、_to，保證了內部自身查找文檔數據的快速
簡要闡述
| Name |
ArangoDB |
OrientDB |
Neo4J |
| 數據庫類型 |
multi-model DBMS |
multi-model DBMS |
graph database |
| 數據模型 |
Document store、Graph DBMS、Key-value store |
Document store、Graph DBMS、Key-value store |
Graph DBMS |
| 適合的操作系統 |
Linux、OS X、Raspbian、Solaris、Windows |
All OS with a Java JDK (>= JDK 6) |
Linux、OS X、Solaris、Windows |
| 事物支持 |
ACID |
ACID |
ACID |
| 外鍵 |
No |
Yes |
Yes |
- ArangoDB與OrientDB都是文檔和圖數據庫的綜合體，V和E都是分別存儲在不同的文檔的中，然后通過文檔去構建圖，不同之處：
- ArangoDB以文檔數據庫模式存儲圖，以特殊字段標識（
_from,_to）文檔類型成為V和E文檔，作為圖數據庫基礎。 - OrientDB采用了OOP的繼承的方式去實現了V和E兩個類；
- ArangoDB優化了
_key字段，可以很簡單hash，且本身也被優化了； - Neo4J的存儲方式是分別存儲了V和E作為兩個文件；
ArangoDB
優點：ArangoDB FAQ、
- 存儲空間占用下：采用了元數據模式存儲數據；Wiki元數據
- 可通過內存提速，CPU占用率低
- 支持主從集群
- Multi-collection transactions
- 擴展性好：JavaScript；
- 用JavaScript和ArangoDB構建應用，Foxx微服務運行在DB內部，可快速訪問數據。
- AQL功能很強大，配置編程遠方便與靈活於Neo4J、OrientDB
- Neo4J的Cypher也比較強大，清晰，但是不利於調整，靈活性不夠
- OrientDB，類SQL，查詢繁瑣，調整不便利，內置SQL函數接口也不方便。
缺點：
- 插入性能稍低
索引
- 自動索引
_key屬性，_from和_to屬性；保證V和E的查找的速度。ArangoDB默認索引
Neo4J
優點
- 可集群，使用讀/寫負載平衡器將請求直接到一個集群；Oreilly Graph Databases，Figure 4.9
- 支持事物、鎖、頁面緩存；Oreilly Graph Databases，Figure 6.3
- 遍歷下：建立索引通常成本O(log(n))，但Neo4J的遍歷一個關系的復雜度趨向於O(1)；Oreilly Graph Databases Page：151
- index-free adjacency：提供high-performance traversals, queries, and writes
- Neo4j uses relationships, not indexes, for fast traversals；O(1)
- ArangoDB寫了篇文章：Index Free Adjacency or Hybrid Indexes for Graph Databases，講述了這個技術被自己干掉；
- 存儲節點時使用了”index-free adjacency”，即每個節點都有指向其鄰居節點的指針，可以讓我們在O(1)的時間內找到鄰居節點。
- 圖形關系的最佳存儲模式，嵌入式、高性能、輕量級
- Cypher語法友好
缺點
- Neo4j沒法存儲巨大的一張關系圖 ，因為他不支持分片
- Neo4j 3.1支持因果集群並改進了安全，主寫副讀
- 可集群，使用讀/寫負載平衡器將請求直接到一個集群；Oreilly Graph Databases，Figure 4.9
- 因為index-free adjacency，遍歷快但是計算隨機兩個節點最短路徑性能不佳
分片（sharding）是MongoDB 用來將大型集合分割到不同服務器（或者說一個集群）上所采用的方法。盡管分片起源於關系型數據庫分區，但它（像MongoDB 的大部分方面一樣）完全是另一回事。
文件存儲
- 存儲關系 record 數組數據：
- relationships are stored in the relationship store file,
neostore.relationshipstore.db. - 存儲關系ID：
neostore.relationshipstore.db.id - 存儲關系組數據及其序列Id：
neostore.relationshipgroupstore.db存儲關系 group數組數據neostore.relationshipgroupstore.db.id- 存儲關系類型及其序列Id：
neostore.relationshiptypestore.db存儲關系類型數組數據neostore.relationshiptypestore.db.id- 存儲關系類型的名稱及其序列Id：
neostore.relationshiptypestore.db.names存儲關系類型 token 數組數據neostore.relationshiptypestore.db.names.id
OrientDB
優點
- 安裝簡單，功能豐富
- OrientDB是兼具文擋數據庫的靈活性和圖形數據庫管理鏈接能力的可深層次擴展的文檔-圖形數據庫管理系統(NoSQL數據庫)。
- 可選無模式、全模式或混合模式下。支持許多高級特性，諸如ACID事務、快速索引，原生和SQL查詢功能。
- 可以JSON格式導入、導出文檔。
- 若不執行昂貴的JOIN操作的話，如同關系數據庫可在幾毫秒內可檢索數以百記的鏈接文檔圖。
缺點
存儲原理
OrientDB本地存儲原則：使用包含由固定大小部分（頁面）分割的磁盤數據並寫入日志記錄方法的磁盤緩存（當頁面中的更改首先記錄在所謂的持久存儲器中時），我們可以實現以下特性：OrientDB 2.2.x——PLocal Engine
- Operations on single page are atomic.
- Changes applied to the page can be restored after server crash even if they were not flushed to the disk.
默認索引
SB索引，基於B-樹。SB樹
- 磁盤消耗大不難理解。
- 其節點唯一標志@RID就是SB索引樹的父節點標識吧，推測。
- 插入關系先獲得節點，在SB樹索引與Neo4J和ArangoDB的實現對比下會慢。