ArangoDB、Neo4j、OrientDB单机性能比较

[TOC]

系统信息

图数据库版本信息

图数据库 版本 备注
Neo4J 3.2
OrientDB 2.2.x
ArangoDB、 3.1.19 有密钥失效问题,导致无法下载成功server端
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

一万节点-插入节点性能分析.jpg

简单分析

  • 三个图数据库所消耗插入节点时间相差无几,性能高低依次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

一万节点-插入边性能分析.png

简单分析

  • 插入边中,耗时长短依次:OrientDB>ArangoDB>Neo4J,从这可以看出,没有在节点环节作出合适预处理的OrientDB在插入关系的时候的性能远远落后于ArangoDB和Neo4J。
  • CPU占用上,Neo4J>OrientDB>ArangoDB
  • 磁盘使用情况:Neo4J>OrientDB>ArangoDB

结论

  • 在插入边的情况下,ArangDB性能依旧稍稍落后于Neo4J,但其在CPU、RAM和磁盘占用上都不如ArangoDB
  • OrientDB则是性能落后很多,且插入边时候磁盘的剩余空间波动巨大,可能是其中产生了缓存文件之类。
  • OrientDB在插入E时性能差距太大

遍历邻节点

  • 邻节点深度为1
  • 采用了三个图数据库内置的广度优先算法

一万节点遍历

一万节点-邻节点查询性能分析.jpg

分析

  • ArangoDB在存储节点时候所消耗的性能在做图计算时候带来了巨大的性能优势,便利和最短路径都因此受益,便利时间依次:OrientDB>Neo4J>ArangoDB
    • Neo4J的图为折线,这意味着如果没有相邻节点Neo4J可以快速发现,而OrientDB和ArangoDB则会逼近直线。
    • Neo4J节点存在大量关系其运行时间消耗大,关系越多耗时越久,不适合大关系的图。
  • Neo4J和ArangoDB是图遍历中性能较好的两种,Neo4J依赖于CPU的计算力去遍历图,ArangoDB则依赖内存
  • Neo4J和ArangoDB皆不会因为遍历而消耗磁盘空间,OrientDB会。
    • OrientDB在遍历时候消耗的磁盘空间可能就是为了优化后面图算法所做的准备,这可以在最短路径的图算法结论中看出。
    • 以磁盘空间来优化算法速度。
  • OrientDB遍历性能太低

最短路径

  • 采用了三个图数据库内置的Dijkstra算法

一万节点相互最短路径

一万节点-两节点最短路径性能分析.jpg

分析

  • 在查找两节点最短路径时候,所消耗时间: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,保证了内部自身查找文档数据的快速

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好之类的。


简要阐述

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企业版存在一个smartGraph的功能,未尝试。

图数据库存储数据类型——复杂度与灵活性关系:

图数据库存储数据类型——复杂度与灵活性关系.png

ArangoDB

优点:ArangoDB FAQ

  • 存储空间占用下:采用了元数据模式存储数据;Wiki元数据
    • 可通过内存提速,CPU占用率低
  • 支持主从集群
  • Multi-collection transactions
  • 扩展性好:JavaScript;
    • 用JavaScript和ArangoDB构建应用,Foxx微服务运行在DB内部,可快速访问数据。
  • AQL功能很强大,配置编程远方便与灵活于Neo4J、OrientDB
    • Neo4J的Cypher也比较强大,清晰,但是不利于调整,灵活性不够
    • OrientDB,类SQL,查询繁琐,调整不便利,内置SQL函数接口也不方便。

缺点:

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

Cassandra :用于储存收件箱等简单格式数据——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

索引

Neo4J

优点

  • 可集群,使用读/写负载平衡器将请求直接到一个集群;[Oreilly Graph Databases](../Neo4J/docs/Oreilly Graph Databases.pdf),Figure 4.9
  • 支持事物、锁、页面缓存;[Oreilly Graph Databases](../Neo4J/docs/Oreilly Graph Databases.pdf),Figure 6.3
  • 遍历下:建立索引通常成本O(log(n)),但Neo4J的遍历一个关系的复杂度趋向于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,讲述了这个技术被自己干掉;
    • 存储节点时使用了”index-free adjacency”,即每个节点都有指向其邻居节点的指针,可以让我们在O(1)的时间内找到邻居节点。
    • 图形关系的最佳存储模式,嵌入式、高性能、轻量级
  • Cypher语法友好

缺点

  • Neo4j没法存储巨大的一张关系图 ,因为他不支持分片
  • 因为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.

保护数据

orientdb-storage.png

默认索引

SB索引,基于B-树。SB树

  • 磁盘消耗大不难理解。
  • 其节点唯一标志@RID就是SB索引树的父节点标识吧,推测。
  • 插入关系先获得节点,在SB树索引与Neo4J和ArangoDB的实现对比下会慢。

参考资料

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,294评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,493评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,790评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,595评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,718评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,906评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,053评论 3 410
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,797评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,250评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,570评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,711评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,388评论 4 332
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,018评论 3 316
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,796评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,023评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,461评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,595评论 2 350

推荐阅读更多精彩内容