[TOC]

系統(tǒng)信息

圖數(shù)據(jù)庫版本信息

OS&庫信息

• OS：Ubuntu 16.04
• 虛擬機(jī)VM12
• python3驅(qū)動(dòng)
  • python-arango
  • neo4j-driver
  • PyOrient
• 繪圖庫：MatPlotLib+Numpy
• 性能監(jiān)測庫：psutil

測試信息

• 測試所得四張圖分別為
  • 數(shù)量時(shí)間圖，斜率越小性能越好
  • CPU平均占用率圖
  • RAM使用圖
  • 硬盤剩余空間圖

圖數(shù)據(jù)庫分類

NoSQL數(shù)據(jù)庫類別：

• 鍵值(Key-Value)數(shù)據(jù)庫
• 面向文檔(Document-Oriented)數(shù)據(jù)庫
• 列存儲(chǔ)(Wide Column Store/Column-Family)數(shù)據(jù)庫
• 圖(Graph-Oriented)數(shù)據(jù)庫

單次寫入速率分析

• 圖數(shù)據(jù)庫引擎全部打開，自動(dòng)繪圖

一萬節(jié)點(diǎn)十萬插入速度

插入一萬頂點(diǎn)V

一萬節(jié)點(diǎn)-插入節(jié)點(diǎn)性能分析.jpg

簡單分析

• 三個(gè)圖數(shù)據(jù)庫所消耗插入節(jié)點(diǎn)時(shí)間相差無幾，性能高低依次OrientDB>Neo4J>ArangoDB
  • ArangoDB的節(jié)點(diǎn)hash可能隨節(jié)點(diǎn)數(shù)量的提高而降低插入節(jié)點(diǎn)的性能
• CPU使用情況為Neo4J使用率高于OrentDB，ArangoDB在最后有個(gè)提升，且結(jié)合第一張圖ArangoDB在最后斜率升高推測ArangoDB可能插入節(jié)點(diǎn)斜率隨著節(jié)點(diǎn)數(shù)的增多而降低。這是因?yàn)锳rangoDB在存儲(chǔ)節(jié)點(diǎn)時(shí)候會(huì)計(jì)算_key的Hash而產(chǎn)生的性能降低，但是節(jié)點(diǎn)插入的速度的Y軸與后面計(jì)算的Y軸不在同一數(shù)量級上，ArangoDB犧牲插入節(jié)點(diǎn)的性能提高后續(xù)的性能是很值得。
• 對RAM使用情況，ArangoDB>OrientDB>Neo4J
• 硬盤使用情況，OrientDB>Neo4J>ArangoDB

結(jié)論

在插入節(jié)點(diǎn)這步驟：

• ArangoDB建立Hash索引，所以插入節(jié)點(diǎn)時(shí)候的性能會(huì)稍微有點(diǎn)低，RAM占用最大，所消耗的存儲(chǔ)空間最小。
• Neo4J進(jìn)行了CPU的密集計(jì)算，對RAM和硬盤的占用率不高。
• OrientDB插入耗時(shí)最短，CPU，RAM也占用較低，建立BS樹索引的優(yōu)勢，但是磁盤消耗大，其以文檔形式直接存儲(chǔ)數(shù)據(jù)而不進(jìn)行前期的預(yù)處理，結(jié)合后面的數(shù)據(jù)可以看出，OrientDB和ArangoDB雖然都支持文檔數(shù)據(jù)庫和圖數(shù)據(jù)，但OrientDB更加偏重于文檔數(shù)據(jù)的存儲(chǔ)，而不是圖數(shù)據(jù)的分析。

插入十萬邊E

一萬節(jié)點(diǎn)-插入邊性能分析.png

簡單分析

• 插入邊中，耗時(shí)長短依次：OrientDB>ArangoDB>Neo4J，從這可以看出，沒有在節(jié)點(diǎn)環(huán)節(jié)作出合適預(yù)處理的OrientDB在插入關(guān)系的時(shí)候的性能遠(yuǎn)遠(yuǎn)落后于ArangoDB和Neo4J。
• CPU占用上，Neo4J>OrientDB>ArangoDB
• 磁盤使用情況：Neo4J>OrientDB>ArangoDB

結(jié)論

• 在插入邊的情況下，ArangDB性能依舊稍稍落后于Neo4J，但其在CPU、RAM和磁盤占用上都不如ArangoDB
• OrientDB則是性能落后很多，且插入邊時(shí)候磁盤的剩余空間波動(dòng)巨大，可能是其中產(chǎn)生了緩存文件之類。
• OrientDB在插入E時(shí)性能差距太大

遍歷鄰節(jié)點(diǎn)

• 鄰節(jié)點(diǎn)深度為1
• 采用了三個(gè)圖數(shù)據(jù)庫內(nèi)置的廣度優(yōu)先算法

一萬節(jié)點(diǎn)遍歷

一萬節(jié)點(diǎn)-鄰節(jié)點(diǎn)查詢性能分析.jpg

分析

• ArangoDB在存儲(chǔ)節(jié)點(diǎn)時(shí)候所消耗的性能在做圖計(jì)算時(shí)候帶來了巨大的性能優(yōu)勢，便利和最短路徑都因此受益，便利時(shí)間依次：OrientDB>Neo4J>ArangoDB
  • Neo4J的圖為折線，這意味著如果沒有相鄰節(jié)點(diǎn)Neo4J可以快速發(fā)現(xiàn)，而OrientDB和ArangoDB則會(huì)逼近直線。
  • Neo4J節(jié)點(diǎn)存在大量關(guān)系其運(yùn)行時(shí)間消耗大，關(guān)系越多耗時(shí)越久，不適合大關(guān)系的圖。
• Neo4J和ArangoDB是圖遍歷中性能較好的兩種，Neo4J依賴于CPU的計(jì)算力去遍歷圖，ArangoDB則依賴內(nèi)存
• Neo4J和ArangoDB皆不會(huì)因?yàn)楸闅v而消耗磁盤空間，OrientDB會(huì)。
  • OrientDB在遍歷時(shí)候消耗的磁盤空間可能就是為了優(yōu)化后面圖算法所做的準(zhǔn)備，這可以在最短路徑的圖算法結(jié)論中看出。
  • 以磁盤空間來優(yōu)化算法速度。
• OrientDB遍歷性能太低

最短路徑

• 采用了三個(gè)圖數(shù)據(jù)庫內(nèi)置的Dijkstra算法

一萬節(jié)點(diǎn)相互最短路徑

一萬節(jié)點(diǎn)-兩節(jié)點(diǎn)最短路徑性能分析.jpg

分析

• 在查找兩節(jié)點(diǎn)最短路徑時(shí)候，所消耗時(shí)間：Neo4J>OrientDB>ArangoDB
  • Neo4J依舊是折線，綜合兩個(gè)圖算法，Neo4J有辦法快速找到?jīng)]有關(guān)系的孤立節(jié)點(diǎn)。因?yàn)閕ndex-free adjacency的關(guān)系。
  • OrientDB在做最短路徑時(shí)候性能相比Neo4J高很多。
• 對CPU的利用：Neo4J>OrientDB>ArangoDB，且OrientDB很穩(wěn)定
• 在做最短路徑時(shí)候，除了ArangoDB，其他兩個(gè)都會(huì)消耗磁盤空間。

綜合分析

Neo4J、OrientDB、ArangoDB在插入數(shù)據(jù)時(shí)候都會(huì)默認(rèn)的建立索引，性能的差距有部分就是因?yàn)樽陨硭饕倪x擇導(dǎo)致的，各自理念不同；

• Neo4J：index-free adjacency，擅長遍歷圖，以及計(jì)算不存在大量關(guān)系的節(jié)點(diǎn)的圖
• OrientDB：側(cè)重文檔數(shù)據(jù)庫，主要還是SB樹索引導(dǎo)致，空間浪費(fèi)比較大；插入節(jié)點(diǎn)與另外兩個(gè)數(shù)據(jù)庫相差無幾，但是在插入關(guān)系中另外兩個(gè)數(shù)據(jù)庫都做了優(yōu)化，OrientDB無優(yōu)化，就掛了；在圖論計(jì)算力上性能優(yōu)異，但是在遍歷中還是優(yōu)化不夠，被甩開。
• ArangoDB：對于V和E文檔都建立了索引，_key、_from、_to，保證了內(nèi)部自身查找文檔數(shù)據(jù)的快速

What “Graph First” Means for Native Graph Technology

An overview of the graph database space.png

[Oreilly Graph Databases](../Neo4J/docs/Oreilly Graph Databases.pdf) Figure 1.3

There are two main elements that distinguish native graph technology: storage and processing. ——native-vs-non-native-graph-technology

具體就是闡述了Native比Non-Native好之類的。

簡要闡述

• ArangoDB與OrientDB都是文檔和圖數(shù)據(jù)庫的綜合體，V和E都是分別存儲(chǔ)在不同的文檔的中，然后通過文檔去構(gòu)建圖，不同之處：
  • ArangoDB以文檔數(shù)據(jù)庫模式存儲(chǔ)圖，以特殊字段標(biāo)識(shí)（_from,_to）文檔類型成為V和E文檔，作為圖數(shù)據(jù)庫基礎(chǔ)。
  • OrientDB采用了OOP的繼承的方式去實(shí)現(xiàn)了V和E兩個(gè)類；
• ArangoDB優(yōu)化了_key字段，可以很簡單hash，且本身也被優(yōu)化了；
• Neo4J的存儲(chǔ)方式是分別存儲(chǔ)了V和E作為兩個(gè)文件；

ArangoDB企業(yè)版存在一個(gè)smartGraph的功能，未嘗試。

圖數(shù)據(jù)庫存儲(chǔ)數(shù)據(jù)類型——復(fù)雜度與靈活性關(guān)系：

圖數(shù)據(jù)庫存儲(chǔ)數(shù)據(jù)類型——復(fù)雜度與靈活性關(guān)系.png

ArangoDB

優(yōu)點(diǎn)：ArangoDB FAQ、

• 存儲(chǔ)空間占用下：采用了元數(shù)據(jù)模式存儲(chǔ)數(shù)據(jù)；Wiki元數(shù)據(jù)
  • 可通過內(nèi)存提速，CPU占用率低
• 支持主從集群
• Multi-collection transactions
• 擴(kuò)展性好：JavaScript；
  • 用JavaScript和ArangoDB構(gòu)建應(yīng)用，F(xiàn)oxx微服務(wù)運(yùn)行在DB內(nèi)部，可快速訪問數(shù)據(jù)。
• AQL功能很強(qiáng)大，配置編程遠(yuǎn)方便與靈活于Neo4J、OrientDB
  • Neo4J的Cypher也比較強(qiáng)大，清晰，但是不利于調(diào)整，靈活性不夠
  • OrientDB，類SQL，查詢繁瑣，調(diào)整不便利，內(nèi)置SQL函數(shù)接口也不方便。

缺點(diǎn)：

• 插入性能稍低
• ArangoDB doesn’t compete with massively distributed systems like Cassandra with thousands of nodes and many terabytes of data.ArangoDB FAQ

Cassandra :用于儲(chǔ)存收件箱等簡單格式數(shù)據(jù)——Wiki

The Apache Cassandra database is the right choice when you need scalability and high availability without compromising performance. Linear scalability and proven fault-tolerance on commodity hardware or cloud infrastructure make it the perfect platform for mission-critical data.Cassandra's support for replicating across multiple datacenters is best-in-class, providing lower latency for your users and the peace of mind of knowing that you can survive regional outages.

——Apache Cassandra

索引

• 自動(dòng)索引_key屬性，_from和_to屬性；保證V和E的查找的速度。ArangoDB默認(rèn)索引

Neo4J

優(yōu)點(diǎn)

• 可集群，使用讀/寫負(fù)載平衡器將請求直接到一個(gè)集群；[Oreilly Graph Databases](../Neo4J/docs/Oreilly Graph Databases.pdf)，F(xiàn)igure 4.9
• 支持事物、鎖、頁面緩存；[Oreilly Graph Databases](../Neo4J/docs/Oreilly Graph Databases.pdf)，F(xiàn)igure 6.3
• 遍歷下：建立索引通常成本O(log(n))，但Neo4J的遍歷一個(gè)關(guān)系的復(fù)雜度趨向于O(1)；[Oreilly Graph Databases](../Neo4J/docs/Oreilly Graph Databases.pdf) 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，講述了這個(gè)技術(shù)被自己干掉；
  • 存儲(chǔ)節(jié)點(diǎn)時(shí)使用了”index-free adjacency”，即每個(gè)節(jié)點(diǎn)都有指向其鄰居節(jié)點(diǎn)的指針，可以讓我們在O(1)的時(shí)間內(nèi)找到鄰居節(jié)點(diǎn)。
  • 圖形關(guān)系的最佳存儲(chǔ)模式，嵌入式、高性能、輕量級
• Cypher語法友好

缺點(diǎn)

• Neo4j沒法存儲(chǔ)巨大的一張關(guān)系圖 ，因?yàn)樗恢С址制?
  • Neo4j 3.1支持因果集群并改進(jìn)了安全，主寫副讀
  • 可集群，使用讀/寫負(fù)載平衡器將請求直接到一個(gè)集群；[Oreilly Graph Databases](../Neo4J/docs/Oreilly Graph Databases.pdf)，F(xiàn)igure 4.9
• 因?yàn)閕ndex-free adjacency，遍歷快但是計(jì)算隨機(jī)兩個(gè)節(jié)點(diǎn)最短路徑性能不佳

分片（sharding）是MongoDB 用來將大型集合分割到不同服務(wù)器（或者說一個(gè)集群）上所采用的方法。盡管分片起源于關(guān)系型數(shù)據(jù)庫分區(qū)，但它（像MongoDB 的大部分方面一樣）完全是另一回事。

——什么是分片

文件存儲(chǔ)

• 存儲(chǔ)關(guān)系 record 數(shù)組數(shù)據(jù)：
  • relationships are stored in the relationship store file, neostore.relationshipstore.db.
  • 存儲(chǔ)關(guān)系ID：neostore.relationshipstore.db.id
• 存儲(chǔ)關(guān)系組數(shù)據(jù)及其序列Id：
  • neostore.relationshipgroupstore.db 存儲(chǔ)關(guān)系 group數(shù)組數(shù)據(jù)
  • neostore.relationshipgroupstore.db.id
• 存儲(chǔ)關(guān)系類型及其序列Id：
  • neostore.relationshiptypestore.db 存儲(chǔ)關(guān)系類型數(shù)組數(shù)據(jù)
  • neostore.relationshiptypestore.db.id
• 存儲(chǔ)關(guān)系類型的名稱及其序列Id：
  • neostore.relationshiptypestore.db.names 存儲(chǔ)關(guān)系類型 token 數(shù)組數(shù)據(jù)
  • neostore.relationshiptypestore.db.names.id

OrientDB

優(yōu)點(diǎn)

• 安裝簡單，功能豐富
• OrientDB是兼具文擋數(shù)據(jù)庫的靈活性和圖形數(shù)據(jù)庫管理鏈接能力的可深層次擴(kuò)展的文檔-圖形數(shù)據(jù)庫管理系統(tǒng)(NoSQL數(shù)據(jù)庫)。
• 可選無模式、全模式或混合模式下。支持許多高級特性，諸如ACID事務(wù)、快速索引，原生和SQL查詢功能。
• 可以JSON格式導(dǎo)入、導(dǎo)出文檔。
• 若不執(zhí)行昂貴的JOIN操作的話，如同關(guān)系數(shù)據(jù)庫可在幾毫秒內(nèi)可檢索數(shù)以百記的鏈接文檔圖。

缺點(diǎn)

• 坑很多：Tackling a 1 Billion Member Social Network – Fast Search on a Large Graph
• 性能和可擴(kuò)展性不好

存儲(chǔ)原理

OrientDB本地存儲(chǔ)原則：使用包含由固定大小部分（頁面）分割的磁盤數(shù)據(jù)并寫入日志記錄方法的磁盤緩存（當(dāng)頁面中的更改首先記錄在所謂的持久存儲(chǔ)器中時(shí)），我們可以實(shí)現(xiàn)以下特性：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.

保護(hù)數(shù)據(jù)

orientdb-storage.png

默認(rèn)索引

SB索引，基于B-樹。SB樹

• 磁盤消耗大不難理解。
• 其節(jié)點(diǎn)唯一標(biāo)志@RID就是SB索引樹的父節(jié)點(diǎn)標(biāo)識(shí)吧，推測。
• 插入關(guān)系先獲得節(jié)點(diǎn)，在SB樹索引與Neo4J和ArangoDB的實(shí)現(xiàn)對比下會(huì)慢。

參考資料

• Neo4j 底層存儲(chǔ)結(jié)構(gòu)分析
• System Properties Comparison ArangoDB vs. Neo4j vs. OrientDB
• Benchmark: PostgreSQL, MongoDB, Neo4j, OrientDB and ArangoDB，ArangoDB社區(qū)
• 大數(shù)據(jù)分析技術(shù)研究報(bào)告(四)
  • NoSQL數(shù)據(jù)庫的四大家族
• ArangoDB介紹——未知架構(gòu)和底層原理
• ArangoDB FAQ
• bachelor-thesis，原文：https://lucas.dohmen.io/assets/pdfs/bachelor-thesis.pdf
• Neo4j 底層存儲(chǔ)結(jié)構(gòu)分析
• [Oreilly Graph Databases](../Neo4J/docs/Oreilly Graph Databases.pdf)
• ArangoDB_Manual_3.1.19
• Neo4j 3.1支持因果集群并改進(jìn)了安全，Neo4j 3.1 Supports Causal Clustering and Security Enhancements
• native-vs-non-native-graph-technology
• Index Free Adjacency or Hybrid Indexes for Graph Databases，ArangoDB社區(qū)，講述了Neo4J的index-free adjacency技術(shù)怎么被不看好并且被它KO的故事。
  • ArangoDB 3.1 索引技術(shù)
  • OrientDB 2.2x 索引技術(shù)
• Tackling a 1 Billion Member Social Network – Fast Search on a Large Graph；Neo4J是如何干掉OrientDB、Titan的。2016-4-20
• 圖數(shù)據(jù)庫：存儲(chǔ)半結(jié)構(gòu)化大數(shù)據(jù)的解決方案
• 在選擇數(shù)據(jù)庫的路上，我們遇到過哪些坑？（1）
• OrientDB 2.2.x——PLocal Engine