tsx81428 发表于 2024-6-14 22:44:48

最新常见的图数据库对比,选型,架构,性能对比

图数据库排名



[*] 地址:https://db-engines.com/en/ranking/graph+dbmshttps://img-blog.csdnimg.cn/direct/7494d871a43b40d58b473ebd8fe4b129.png
知识图谱查询语言

SPARQL、Cypher、Gremlin、PGQL 和 G-CORE

语法 / 语义 / 特性SPARQLCypherGremlinPGQLG-CORE图模式匹配查询语法CGPCGPCGP(无可选)1CGPCGP语义子图同态、包 2无重复边、包 2子图同态、包 2子图同构 3、包 2子图同态、包 2导航式查询语法RPQ 超集 (增加反向边和属性集上的否定)RPQ 子集 (* 只能作用在单边)RPQ 超集 (增加通过表达式比力属性值)RPQ 超集 (增加比力路径上的极点和边)RPQ 超集 (增加复杂路径表达式)语义恣意路径、集合 4无重复边 5、包 2恣意路径 6、包 2最短路径 7、包 8最短路径 9、包 2分析型查询聚合函数聚合函数聚合函数、PageRank、PeerPressure 聚类聚合函数聚合函数查询可组合性否是是否是数据更新语言 DMLCRUD10CRUD无无CR数据定义语言 DDL无有无无无实现系统Jena、RDF4J、gStore、Virtuoso 等Neo4j、AgensGraph 等TinkerTop 等Oracle PGX无

[*] Gremlin 不显式支持可选 (optional) 操纵, 但可以通过其他语法特性等价模拟.
[*] 可通过 DISTINCT 关键字支持集合语义.
[*] PGQL 默认的图模式匹配查询语义是子图同构, 可利用 ALL 关键字改为子图同态.
[*] SPARQL 中只有当利用 * 运算使得属性路径查询无法等价写为 CGP 时才利用集合语义.
[*] Cypher 可通过 shortestPath 函数支持最短路径语义.
[*] Gremlin 中其他语义可以被模拟出来.
[*] PGQL 路径查询可通过用户定义函数实现其他语义.
[*] PGQL 路径查询返回单条最短路径, 集合和包语义相同.
[*] G-CORE 路径查询可通过 ALL 关键字改为恣意路径语义.
[*] CRUD 分别代表 CREATE 创建、READ 读取、UPDATE 更新和 DELETE 删除
知识图谱存储方式



[*] 关系型存储
存储大规模知识图谱,且便于对知识进行更新,但当知识图谱查询的选择性较大时,查询性能明显降落


[*] 原生图存储
无邻接索引的特性可以或许高效处理复杂的知识图谱查询,但有限的存储容量和不灵活的更新机制使得原生图存储不能很好地应用于大规模知识图谱中
基于关系的知识图谱存储管理

关系数据库目前仍是利用最多的数据库管理系统。基于关系的知识图谱存储方案, 包罗: 三元组表、程度表、属性表、垂直分别、六重索引和 DB2RDF。
三元组表

三元组表 (triple table) 是将知识图谱存储到关系数据库的最简单、最直接的办法, 就是在关系数据库中创建 一张具有 3 列的表, 该表的模式为 triple_table(subject,predicate,object),subject、predicate 和 object 这 3 列分别表示主语、谓语和宾语。


[*] 三元组表存储方案虽然简单明白,但三元组表的行数与知识图谱的边数相等,其最大题目在于将知识图谱查询翻译为 SQL 查询后会产生三元组表的大量自连接操纵
[*] RDF 数据库系统 3storehttps://img-blog.csdnimg.cn/direct/986a2d4bf4b74673912892abd75d56fc.png

程度表

程度表 (horizontal table) 存储方案同样非常简单。程度表的每行记录存储知识图谱中一个主语的全部谓语 和宾语。实际上, 程度表相当于知识图谱的邻接表。程度表的列数是知识图谱中不同谓语的数目, 行数是知识图 谱中不同主语的数目。


[*] RDF 数据库系统 DLDB
[*] 程度表的缺点在于:

[*] (1) 所需列的数目即是知识图谱中不同谓语数目,在真实知识图谱数据会集,不同 谓语数目可能为几千个到上万个,很可能超出关系数据库所允许的表中列数目上限
[*] (2) 对于一行来说,仅在极 少数列上具有值, 表中存在大量空值, 空值过多会影响表的存储、索引和查询性能
[*] (3) 在知识图谱中,同一主语 和谓语可能具有多个不同宾语,即一对多联系或多值属性,而程度表的一行一列上只能存储一个值,无法应对这种情况 (可以将多个值用分隔符连接存储为一个值,但这违反了关系数据库设计的第一范式);
[*] (4) 知识图谱的更新往往会引起谓语的增加、修改或删除,即程度表中列的增加、修改或删除,这是对于表结构的改变,成本很高。

https://img-blog.csdnimg.cn/direct/ee6ecf775dce4df79271464be30fb987.png
属性表

属性表 (property table) 存储方案是对程度表的细分,将同类主语存到一个表中,办理了表中列数目过多的题目。


[*] RDF 三元组库 Jena
[*] 属性表既克服了三元组表的自连接题目,又办理了程度表中列数目过多的题目。实际上,程度表就是属性表的一种极端情况,即程度表是将全部主语划归为一类,因此属性表中的空值题目得到很大的缓解。
[*] 属性表仍存 在如下一些缺点:

[*] (1) 对于规模稍大的真实知识图谱数据,主语的种别可能有几千到上万个,必要创建几千到上万个表,这往往高出了关系数据库的限制
[*] (2) 即使在同一范例中,不同主语具有的谓语集合也可能差别较大,会造成与程度表中类似的空值题目
[*] (3) 程度表中存在的一对多联系或多值属性存储题目在属性表中仍旧存在

垂直分别

垂直分别 (vertical partitioning) 存储方案,为每种谓语创建一张两列的表(subject,object), 表中存放知识图谱中由该谓语连接的主语和宾 语, 表的总数目即知识图谱中不同谓语的数目.


[*] SW-Store
[*] 优点:

[*] (1) 谓语表仅存储出现在 知识图谱中的三元组, 办理了空值题目;
[*] (2) 一个主语的一对多联系或多值属性存储在谓语表的多行中, 办理了 多值题目;
[*] (3) 每个谓语表都按主语列的值进行排序, 可以或许利用归并排序连接 (merge-sort join) 快速实行不同谓 语表的连接查询操纵.

[*] 缺点:

[*] (1) 必要创建的表的数目与知识图谱中不同谓语数目相等,而大规模的真实知识图谱 (如 DBpedia、YAGO、WikiData 等) 中谓语数目可能高出几千个,在关系数据库中维护云云规模的表必要花费很大开销
[*] (2) 越是复杂的知识图谱查询操纵,必要实行的表连接操纵数目越多,而对于未指定谓语的三元组查询,将发生必要连接全部谓语表进行查询的极端情况
[*] (3) 谓语表的数目越多,数据更新维护代价越大,对于一个主语的更新将涉及多张表,产生很高的更新时 I/O 开销。

https://img-blog.csdnimg.cn/direct/9eee39cb464f4764beb810699d00fdcd.png
六重索引

六重索引 (sextuple indexing) 存储方案是对三元组表的扩展,是一种典型的 “空间换时间” 策略,其将三元组全部 6 种排列对应地创建为 6 张表,即 spo(主语,谓语,宾语)、pos(谓语,宾语,主语)、osp(宾语,主语,谓语)、sop(主语,宾语,谓语)、pso(谓语,主语,宾语)和 ops(宾语,谓语,主语)。不丢脸出,其中 spo 表就是原来的三元组表。六重索引通过 6 张表的连接操纵不仅缓解了三元组表的单表自连接题目,而且进步了某些典型知识图谱查询的服从。


[*] RDF-3X , Hexastore
[*] 优点:

[*] (1) 知识图谱查询中的每种三元组模式查询都可以直接利用相应的索引进行快速 前缀范围查找;
[*] (2) 可以通过不同索引表之间的连接操纵 直接加快知识图谱上的连接查询.

[*] 缺点:

[*] (1) 虽然部分缓解了三元组表的单表自连接题目, 但必要花费 6 倍的存 储空间开销、索引维护代价和数据更新时的一致性维护代价, 随着知识图谱规模的增大, 该题目会愈加突出;
[*] (2) 当知识图谱查询变得复杂时, 会产生大量的连接索引表查询操纵, 依然不可避免索引表的自连接.

[*] DB2RDF 是一种面向实体的 RDF 知识图谱存储方案

[*] IBM DB2

原生知识图谱存储管理

Neo4j

Neo4j 是目前最流行的属性图数据库,其原生图存储层的最大特点是具有 “无索引邻接(index-free adjacency)” 特性。所谓 “无索引邻接” 是指,每个极点维护着指向其邻接极点的直接引用,相当于每个极点都可看作是其邻接极点的一个 “局部索引”,用其查找邻接极点比利用“全局索引” 节省大量时间。这就意味着图导航操纵代价与图大小无关,仅与图的遍历范围成正比
gStore

gStore 将 RDF 数据图中每个资源的全部属性和属性值映射到一个二进制位串上。具体而言,对于每个属性 或属性值,gStore 都定义一个固定长度的位串并将位串中全部位置为 0。然后利用多少个预先定义的字符串哈希函数将属性或属性值按照标识符映射到多少个小于位串长度的整数值,进而将位串上这些值所对应的位置置为 1。
分布式图数据库:JanusGraph

JanusGraph 是在原有 Titan 系统根本上继续开发的开源分布式图数据库。JanusGraph 的存储后端与查询引擎是分离的, 可利用分布式 Bigtable 存储库 Cassandra 或 HBase 作为存储后端。JanusGraph 借助第三方分布式索引库 ElasticSearch、Solr 和 Lucene 实现各范例数据的快速检索功能,包罗地理信息数据、数值数据和全文搜索。JanusGraph 还具备基于 MapReduce 的图分析引擎,,可将 Gremlin 导航查询转化为 MapReduce 任务。
图计算框架(TinkerPop)
数据存储(Cassandra,HBase,BerkeleyDB)
索引存储(Elasticsearch,Solr,Lucene)
JanusGraph从其框架上来说,是起到一个桥梁的作用。将各种开源的软件连接到一起,形成一个大型图数据库。https://img-blog.csdnimg.cn/direct/18797d79e05544e3bdac54bf6fc11e23.png
OrientDB

OrientDB 最初是由 OrientDB 公司开发的多模子数据库管理系统。OrientDB 虽然支持图、文档、键值、对象、关系等多种数据模子, 但其底层实现主要面向图和文档数据存储管理的需求设计。其存储层中数据记录之间的联系并不是像关系数据库那样通过主外键的引用,而是通过记录之前直接的物理指针。OrientDB 对于数据模式的支持相对灵活,可以管理无模式数据 (schema-less),也可以像关系数据库那样定义完整的模式(schema-full),还可以适应介于两者之间的肴杂模式(schema-mixed) 数据。在查询语言方面,OrientDB 支持扩展的 SQL 和 Gremlin 用于图上的导航式查询;OrientDB 的 MATCH 语句实现了声明式的模式匹配,这类似于 Cypher 语言查询模式。
Cayley

Cayley 是由 Google 公司工程师开发的一款轻量级开源图数据库。Cayley 的开发受到了 Freebase 知识图谱和 Google 知识图谱背后的图数据存储的影响。Cayley 利用 Go 语言开发,可以作为 Go 类库利用;对外提供 REST API,具有内置的查询编辑器和可视化界面;支持多种查询语言,包罗:基于 Gremlin 的 Gizmo、GraphQL 和 MQL;支持多种存储后端, 包罗:键值数据库 Bolt、LevelDB, NoSQL 数据库 MongoDB、CouchDB、PouchDB、ElasticSearch,关系数据库 PostgreSQL、MySQL 等。
NebulaGraph
https://img-blog.csdnimg.cn/direct/978ff6eb0a2f4da3aa957b1b7e22607e.png
NebulaGraph 是一款完全由杭州悦数科技有限公司自主研发的开源分布式图数据库产物,善于处理千亿节点万亿条边的超大规模数据集,同时保持毫秒级查询延时。自 2019 年 5 月开源以来,被多家互联网头部企业竞相接纳,广泛应用于金融风控、及时推荐、知识图谱等业务场景。早期接纳者包罗腾讯、美团、京东、360数科、微众银行、小红书、知乎、快手、BOSS直聘等知名互联网企业,随着图数据库技术的日益普及以及业务场景的不断发掘,越来越多行业加入了 NebulaGraph 社区,包罗中国移动、众安保险、泰康人寿等。
性能高效:高可用,高吞吐低时延

NebulaGraph 的图数据库接纳原生分布式结构,得益于其 shared-nothing 以及存储与计算分离的架构设计,NebulaGraph 具备在线程度扩缩容能力;原生分布式架构,利用 Raft 协议包管数据一致性,确保集群高可用;同时兼容 openCypher,可以或许无缝对接 Neo4j 用户,降低学习及迁移成本。
开源社区:数千名成员,日常互动活跃

NebulaGraph 的开发者社区聚集了几千名社区成员和超百位社区代码贡献者,项目在 GitHub 上积聚了高出 7800 个 star。近期被 CSDN 选为 2021 年的 “年度开源项目”。英国投资公司 OXX.VC 也将 NebulaGraph 评选为 2021 年成长最快的开源公司,与 Airbyte、Supabase 等广受欢迎的开源项目并列。
官网:https://www.nebula-graph.com.cn/
git:https://github.com/vesoft-inc/nebula
性能对比:https://discuss.nebula-graph.com.cn/t/topic/11727
文档:https://docs.nebula-graph.com.cn/3.6.0/1.introduction/1.what-is-nebula-graph/
其他原生图数据库

Amazon 云平台的 Amazon Neptune 多模子图数据库 Arango DB 微软的 Azure CosmosDB DataStax 的 Enterprise Graph Sparsity 的 Sparksee TigerGraph
图数据库选型准则

在图数据库的选型上我们主要考虑了以下 5 点:


[*] (A) 项目开源,暂不考虑需付费的图数据库
[*] (B) 分布式架构设计,具备良好的可扩展性
[*] (C) 毫秒级的多跳查询延迟
[*] (D) 支持千亿量级点边存储
[*] (E) 具备批量从数仓导入数据的能力
针对主流图数据库,进行选型分析
DB-Engines Ranking of Graph DBMS 剔除不开源的项目,可分为:

[*] Neo4j、ArangoDB、Virtuoso、TigerGraph、RedisGraph。 此类图数据库只有单机版本开源可用,性能优秀,但不能应对分布式场景中数据的规模增长,即不满意选型要求(B)、(D)。
[*] JanusGraph、HugeGraph。 此类图数据库在现有存储系统之上新增了通用的图语义解释层,图语义层提供了图遍历的能力,但是受到存储层或者架构限制,不支持完整的计算下推,多跳遍历的性能较差,很难满意 OLTP(on-line transaction processing)场景下对低延时的要求,即不满意选型要求(C)。
[*] DGraph、NebulaGraph。 此类图数据库根据图数据的特点对数据存储模子、点边分布、实行引擎进行了全新设计,对图的多跳遍历进行了深度优化,根本满意我们的选型要求。
图数据库对比

NebulaGraph vs. Dgraph vs. HugeGraph

NebulaGraph vs. Dgraph vs. HugeGraph 的对比分析
部署方案https://img-blog.csdnimg.cn/direct/e26cc4cc24394ba6abeeabc12c94fee5.png
及时数据写入
https://img-blog.csdnimg.cn/direct/f5af5cbd007147c6a71660d1c79ec5db.png
https://img-blog.csdnimg.cn/direct/2b820efd937e4d85ac64fa8fa6174257.png
查询对比
https://img-blog.csdnimg.cn/direct/99d9a36a7d4944d185415740d86f9229.png
Neo4j vs HugeGraph vs NebulaGraph

Neo4j vs HugeGraph vs NebulaGraph 的对比分析

图形数据大小平台数据导入一跳查询两查询共享好友查询1000 万条边Neo4j26 秒6.618 秒6.644 秒6.661 秒HugeGraph89 秒16 毫秒22 毫秒72 毫秒NebulaGraph32.63 秒1.482 毫秒3.095 毫秒0.994 毫秒1 亿条边Neo4j1 分 21 秒42.921 秒43.332 秒44.072 秒HugeGraph10 分19 毫秒20 毫秒5 秒NebulaGraph3 分 52 秒1.971 毫秒4.34 毫秒4.147 毫秒10 亿条边Neo4j8 分 34 秒165.397 秒176.272 秒168.256 秒HugeGraph65 分19 毫秒651 毫秒3.8 秒NebulaGraph29 分 35 秒2.035 秒22.48 毫秒1.761 毫秒80 亿条边缘Neo4j1 小时 23 分钟314.34 秒393.18 秒608.27 秒HugeGraph16 小时68 毫秒24 秒541 毫秒NebulaGraph~30 分钟小于 1s小于 5 秒小于 1s
架构:
https://img-blog.csdnimg.cn/direct/efa178c80e264d0984743104b2dc94ba.png
Dgraph vs. HugeGraph vs. JanusGraph vs. NebulaGraph vs. Neo4j

Dgraph vs. HugeGraph vs. JanusGraph vs. NebulaGraph vs. Neo4j 的对比分析
主要知识图谱数据库对比

https://img-blog.csdnimg.cn/direct/74bdc62877834b978dbeff595d541bb1.png
https://img-blog.csdnimg.cn/direct/8d78ca92aaca447ab7519b10b24de573.png

常见知识图谱数据库管理系统的比力


范例名称许可证数据模子 / 存储方案查询语言是否活跃基于关系3store开源RDF 图 / 三元组表SPARQL否DLDB研究原型RDF 图 / 程度表SPARQL早期系统, 程度表存储方案的代表性系统Jena开源RDF 图 / 属性表SPARQL主流的语义 Web 工具库、RDF 数据库和 OWL 推理工具SW-Store研究原型RDF 图 / 垂直分别SPARQL科研原型系统, 垂直分别存储方案的代表性系统IBM DB2贸易RDF 图 / DB2RDFSPARQL/ SQL支持 RDF 的主流贸易数据库Oracle 18c贸易RDF 图 / 关系存储SPARQL/ PGQL支持 RDF 的主流贸易数据库RDF 三元组库RDF4J开源RDF 图 / SAIL APISPARQL是RDF-3X开源RDF 图 / 六重索引SPARQL科研原型系统, 六重索引存储方案的代表性系统gStore开源研究原型RDF 图 / VS * 树SPARQL科研原型系统, 原生图存储, 利用了基于位串图存储技术Virtuoso贸易 / 开源RDF 图 / 多模子肴杂SPARQL/ SQL语义 Web 项目常用的 RDF 数据库, 基于成熟的 SQL 引擎AllegroGraph贸易RDF 图 / 三元组索引SPARQL对语义推理功能具有较为完善的支持GraphDB贸易RDF 图 / 三元组索引SPARQL支持语义 Web 标准的主流产物, 支持 SAIL 层推理功能BlazeGraph贸易RDF 图 / 三元组索引SPARQL/ Gremlin基于 RDF 三元组库的图数据库, 实现了 SPARQL 和 GremlinStarDog贸易RDF 图 / 三元组索引SPARQL对 OWL2 推理机制具有良好的支持原生图数据库Neo4j贸易 / 开源属性图 / 原生图存储Cypher是JanusGraph开源属性图分布式存储Gremlin分布式图数据库, 存储后端与查询引擎分离, 实现了 GremlinOrientDB贸易属性图 / 原生图存储SQL/ Gremlin支持多模子的原生图数据管理系统, 对数据模式的灵活支持Cayley开源RDF 图 / 外部存储Gremlin/ GraphQL轻量级开源图数据库, 易于扩展对新语言和存储后端的支持分布式系统与框架Sempala开源研究原型RDF 图 / 分布式存储SPARQL否TriAD开源研究原型RDF 图 / 分布式存储六重索引SPARQL基于 MPI 框架的异步通信协议H2RDF+开源研究原型RDF 图 / 分布式存储六重索引SPARQL基于 HBase 构建六重索引S2RDF开源研究原型RDF 图 / 分布式存储垂直分别SPARQL基于 Spark 框架创建大量索引Stylus开源研究原型RDF 图 / 分布式存储属性表优化SPARQL基于分布式内存键值库的 RDF 三元组库Apache Rya开源RDF 图 / 分布式存储三元组索引SPARQL基于列存储 Accumulo 的 RDF 三元组库Cypher for Apache Spark开源属性图 / 分布式存储 DataFrameCypher基于 Spark 框架的 Cypher 引擎
   JanusGraph(尚可)、Neo4j(老牌先入为主不一定最佳)、Dgraph(尚可)、NebulaGraph(推荐) 四款图数据库比力。

特性JanusGraphNeo4jDgraphNebulaGraph初次发布2017 年2007 年2016 年2019 年开发语言JavaJavaGoC++开源是是是是属性图模子完整的属性图模子完整的属性图模子类 RDF 存储完整的属性图模子架构分布式单机分布式分布式存储后端Hbase、Cassandra、
BerkeleyDB自定义文件格式键值数据库 BadgerDB键值数据库
RocksDB高可用性支 持不支持支持支持高可靠性支 持不支持支持支持一致性协议Paxos 等无RAFTRAFT跨数据中心复制支 持不支持支持不支持事件ACID 或 BASE完全的 ACID0mid 修改版不支持分区策略随机分区,支持显式指定分区策略不支持分区主动分区静态分区大数据平台集成Spark、Hadoop、GiraphSpark不支持Spark、Flink查询语言GremlinCypherGraphQLnGQL全文检索ElasticSearch、Solr、Lucene内置内置ElasticSearch多个图支持创建恣意多图一个实例只能有一个图一个集群只能有一个图支持创建恣意多图属性图模式多种束缚方法可选模式束缚无模式逼迫模式束缚客户端协议HTTP、WebSocketsHTTP、BOLTHTTP、gRPC 等HTTP客户端语言Java、Python、C#、Go、Ruby
等Java、Python、Go 等Java、Go、Python、等Python、Java 等


免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
页: [1]
查看完整版本: 最新常见的图数据库对比,选型,架构,性能对比