知识图谱之图数据库如何选型:知识图谱存储与图数据库总结、主流图数据库对比(JanusGraph、HugeGraph、Neo4j、Dgraph、NebulaGraph、Tugrapg)

本文涉及的产品
检索分析服务 Elasticsearch 版,2核4GB开发者规格 1个月
简介: 知识图谱之图数据库如何选型:知识图谱存储与图数据库总结、主流图数据库对比(JanusGraph、HugeGraph、Neo4j、Dgraph、NebulaGraph、Tugrapg)

知识图谱之图数据库如何选型:知识图谱存储与图数据库总结、主流图数据库对比(JanusGraph、HugeGraph、Neo4j、Dgraph、NebulaGraph、Tugrapg)

图数据库每月排名

1.知识图谱

1.1 KG简单知识点

  • 数据模型

知识图谱的两种主流数据模型(数据的结构、操作和约束):

RDF 图模型和属性图模型

数据模型特性 数据模型特性 RDF 图模型 属性图模型
结构 标准化程度 数学模型 表达力 边属性表达 概念层本体定义 串行化格式 已由 W3C 制定了标准化的语法和语义 3 - 均匀有向标签超图 RDF 图模型强于属性图模型 通过额外方法, 如 “具体化” RDFS、OWL、 XML、JSON、N-Triples、Turtle 等 尚未形成工业标准 有向标签属性图 属性图模型弱于 RDF 图模型 内置支持 不支持 CSV
操作 查询代数 SPARQL 代数
查询语言 SPARQL Cypher、Gremlin、PGQL、G-CORE
约束 约束语言 RDF Shapes 约束语言 (SHACL)
  • 数据库管理系统

知识图谱数据模型的主流数据库管理系统:

RDF三元组库和原生图数据库

  • 查询语言

知识图谱查询语言:

SPARQL、Cypher、Gremlin、PGQL 和 G-CORE

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

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

1.2.知识图谱存储方式

  • 关系型存储

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

  • 原生图存储

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

2.基于关系的知识图谱存储管理

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

2.1 三元组表

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

  • 三元组表存储方案虽然简单明了,但三元组表的行数与知识图谱的边数相等,其最大问题在于将知识图谱查询翻译为 SQL 查询后会产生三元组表的大量自连接操作
  • RDF 数据库系统 3store

2.2水平表

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

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

2.3 属性表

属性表 (property table) 存储方案是对水平表的细分,将同类主语存到一个表中,解决了表中列数目过多的问题。

  • RDF 三元组库 Jena
  • 属性表既克服了三元组表的自连接问题,又解决了水平表中列数目过多的问题。实际上,水平表就是属性表的一种极端情况,即水平表是将所有主语划归为一类,因此属性表中的空值问题得到很大的缓解。
  • 属性表仍存 在如下一些缺点:
    • (1) 对于规模稍大的真实知识图谱数据,主语的类别可能有几千到上万个,需要建立几千到上万个表,这往往超过了关系数据库的限制
    • (2) 即使在同一类型中,不同主语具有的谓语集合也可能差异较大,会造成与水平表中类似的空值问题
    • (3) 水平表中存在的一对多联系或多值属性存储问题在属性表中仍然存在

2.4 垂直划分

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

  • SW-Store
  • 优点:
    • (1) 谓语表仅存储出现在 知识图谱中的三元组, 解决了空值问题;
    • (2) 一个主语的一对多联系或多值属性存储在谓语表的多行中, 解决了 多值问题;
    • (3) 每个谓语表都按主语列的值进行排序, 能够使用归并排序连接 (merge-sort join) 快速执行不同谓 语表的连接查询操作.
  • 缺点:
    • (1) 需要创建的表的数目与知识图谱中不同谓语数目相等,而大规模的真实知识图谱 (如 DBpedia、YAGO、WikiData 等) 中谓语数目可能超过几千个,在关系数据库中维护如此规模的表需要花费很大开销
    • (2) 越是复杂的知识图谱查询操作,需要执行的表连接操作数量越多,而对于未指定谓语的三元组查询,将发生需要连接全部谓语表进行查询的极端情况
    • (3) 谓语表的数量越多,数据更新维护代价越大,对于一个主语的更新将涉及多张表,产生很高的更新时 I/O 开销。

2.5六重索引

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

  • RDF-3X , Hexastore
  • 优点:
    • (1) 知识图谱查询中的每种三元组模式查询都可以直接使用相应的索引进行快速 前缀范围查找;
    • (2) 可以通过不同索引表之间的连接操作 直接加速知识图谱上的连接查询.
  • 缺点:
    • (1) 虽然部分缓解了三元组表的单表自连接问题, 但需要花费 6 倍的存 储空间开销、索引维护代价和数据更新时的一致性维护代价, 随着知识图谱规模的增大, 该问题会愈加突出;
    • (2) 当知识图谱查询变得复杂时, 会产生大量的连接索引表查询操作, 依然不可避免索引表的自连接.
  • DB2RDF 是一种面向实体的 RDF 知识图谱存储方案
    • IBM DB2

4.原生知识图谱存储管理

4.1.老牌图数据库

原生知识图谱存储是指专门为知识图谱而设计的底层存储管理方案
目前主要的原生图数据库有 Neo4j、gStore、JanusGraph、OrientDB 和 Cayley。

4.1.1Neo4j

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

4.1.2 gStore

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

4.1.3 分布式图数据库:JanusGraph

JanusGraph 是在原有 Titan 系统基础上继续开发的开源分布式图数据库。JanusGraph 的存储后端与查询引擎是分离的, 可使用分布式 Bigtable 存储库 Cassandra 或 HBase 作为存储后端。JanusGraph 借助第三方分布式索引库 ElasticSearch、Solr 和 Lucene 实现各类型数据的快速检索功能,包括地理信息数据、数值数据和全文搜索。JanusGraph 还具备基于 MapReduce 的图分析引擎,,可将 Gremlin 导航查询转化为 MapReduce 任务。

4.1.4 OrientDB

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

4.1.5 Cayley

Cayley 是由 Google 公司工程师开发的一款轻量级开源图数据库。Cayley 的开发受到了 Freebase 知识图谱和 Google 知识图谱背后的图数据存储的影响。Cayley 使用 Go 语言开发,可以作为 Go 类库使用;对外提供 REST API,具有内置的查询编辑器和可视化界面;支持多种查询语言,包括:基于 Gremlin 的 Gizmo、GraphQL 和 MQL;支持多种存储后端, 包括:键值数据库 Bolt、LevelDB, NoSQL 数据库 MongoDB、CouchDB、PouchDB、ElasticSearch,关系数据库 PostgreSQL、MySQL 等。

4.2 其他原生图数据库

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

4.2.1 图数据库选型准则

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

  • (A) 项目开源,暂不考虑需付费的图数据库

  • (B) 分布式架构设计,具备良好的可扩展性

  • © 毫秒级的多跳查询延迟

  • (D) 支持千亿量级点边存储

  • (E) 具备批量从数仓导入数据的能力

针对主流图数据库,进行选型分析

DB-Engines Ranking of Graph DBMS 剔除不开源的项目,可分为:

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

4.2.2 图数据库对比

(1) NebulaGraph vs. Dgraph vs. HugeGraph

NebulaGraph vs. Dgraph vs. HugeGraph 的对比分析

部署方案

实时数据写入


数据查询

(2) Neo4j vs NebulaGraph vs JanusGraph

Neo4j vs NebulaGraph vs JanusGraph 的对比分析

图形数据大小 平台 数据导入 一跳查询 两查询 共享好友查询
1000 万条边 Neo4j 26 秒 6.618 秒 6.644 秒 6.661 秒
HugeGraph 89 秒 16 毫秒 22 毫秒 72 毫秒
NebulaGraph 32.63 秒 1.482 毫秒 3.095 毫秒 0.994 毫秒
1 亿条边 Neo4j 1 分 21 秒 42.921 秒 43.332 秒 44.072 秒
HugeGraph 10 分 19 毫秒 20 毫秒 5 秒
NebulaGraph 3 分 52 秒 1.971 毫秒 4.34 毫秒 4.147 毫秒
10 亿条边 Neo4j 8 分 34 秒 165.397 秒 176.272 秒 168.256 秒
HugeGraph 65 分 19 毫秒 651 毫秒 3.8 秒
NebulaGraph 29 分 35 秒 2.035 秒 22.48 毫秒 1.761 毫秒
80 亿条边缘 Neo4j 1 小时 23 分钟 314.34 秒 393.18 秒 608.27 秒
HugeGraph 16 小时 68 毫秒 24 秒 541 毫秒
NebulaGraph ~30 分钟 小于 1s 小于 5 秒 小于 1s

(3) Dgraph vs. HugeGraph vs. JanusGraph vs. NebulaGraph vs. Neo4j

Dgraph vs. HugeGraph vs. JanusGraph vs. NebulaGraph vs. Neo4j 的对比分析

4.2.3 主要知识图谱数据库对比


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

类型 名称 许可证 数据模型 / 存储方案 查询语言 是否活跃
基于关系 3store 开源 RDF 图 / 三元组表 SPARQL
DLDB 研究原型 RDF 图 / 水平表 SPARQL 早期系统, 水平表存储方案的代表性系统
Jena 开源 RDF 图 / 属性表 SPARQL 主流的语义 Web 工具库、RDF 数据库和 OWL 推理工具
SW-Store 研究原型 RDF 图 / 垂直划分 SPARQL 科研原型系统, 垂直划分存储方案的代表性系统
IBM DB2 商业 RDF 图 / DB2RDF SPARQL/ SQL 支持 RDF 的主流商业数据库
Oracle 18c 商业 RDF 图 / 关系存储 SPARQL/ PGQL 支持 RDF 的主流商业数据库
RDF 三元组库 RDF4J 开源 RDF 图 / SAIL API SPARQL
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 和 Gremlin
StarDog 商业 RDF 图 / 三元组索引 SPARQL 对 OWL2 推理机制具有良好的支持
原生图数据库 Neo4j 商业 / 开源 属性图 / 原生图存储 Cypher
JanusGraph 开源 属性图分布式存储 Gremlin 分布式图数据库, 存储后端与查询引擎分离, 实现了 Gremlin
OrientDB 商业 属性图 / 原生图存储 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 开源 属性图 / 分布式存储 DataFrame Cypher 基于 Spark 框架的 Cypher 引擎

JanusGraph(尚可)、Neo4j(老牌先入为主不一定最佳)、Dgraph(尚可)、NebulaGraph(推荐) 四款图数据库比较。

主流和推荐使用图数据库对比
特性 JanusGraph Neo4j Dgraph NebulaGraph
首次发布 2017 年 2007 年 2016 年 2019 年
开发语言 Java Java Go C++
开源
属性图模型 完整的属性图模型 完整的属性图模型 类 RDF 存储 完整的属性图模型
架构 分布式 单机 分布式 分布式
存储后端 Hbase、Cassandra、
BerkeleyDB
自定义文件格式 键值数据库 BadgerDB 键值数据库
RocksDB
高可用性 支 持 不支持 支持 支持
高可靠性 支 持 不支持 支持 支持
一致性协议 Paxos 等 RAFT RAFT
跨数据中心复制 支 持 不支持 支持 不支持
事务 ACID 或 BASE 完全的 ACID 0mid 修改版 不支持
分区策略 随机分区,支持显式指定分区策略 不支持分区 自动分区 静态分区
大数据平台集成 Spark、Hadoop、Giraph Spark 不支持 Spark、Flink
查询语言 Gremlin Cypher GraphQL nGQL
全文检索 ElasticSearch、Solr、Lucene 内置 内置 ElasticSearch
多个图 支持创建任意多图 一个实例只能有一个图 一个集群只能有一个图 支持创建任意多图
属性图模式 多种约束方法 可选模式约束 无模式 强制模式约束
客户端协议 HTTP、WebSockets HTTP、BOLT HTTP、gRPC 等 HTTP
客户端语言 Java、Python、C#、Go、Ruby
Java、Python、Go 等 Java、Go、Python、等 Python、Java 等

4.2.4、单个性能强图数据库

(1) TuGraph

TuGraph 由蚂蚁集团与清华大学联合研发,构建了一套包含图存储、图计算、图学习、图研发平台的完善的图技术体系,拥有业界领先规模的图集群,解决了图数据分析面临的大数据量、高吞吐率和低延迟等重大挑战,是蚂蚁集团金融风控能力的重要基础设施,显著提升了欺诈洗钱等金融风险的实时识别能力和审理分析效率,并面向金融、工业、政务服务等行业客户。

性能较强,大容量,但初步开源,问题较多,功能尚不完善。

功能特诊 性能和可扩展性
标签属性图模型 TB 级大容量
支持多图 千万顶点 / 秒的高吞吐率
完善的 ACID 事务处理 高可用性支持(企业版)
内置 25+ 图分析算法 高性能批量导入
基于 web 客户端的图可视化工具 在线 / 离线备份
支持 RESTful API 和 RPC
OpenCypher 图查询语言
基于 C++/Python/Java 的存储过程
适用于高效图算法开发的 Traversal API

(2) NebulaGraph

NebulaGraph 是一个分布式,可扩展且闪电般的图形数据库。它是世界上能够托管具有数百亿个顶点(节点)和数万亿条边(关系)的图形的最佳解决方案,具有毫秒级延迟。

社区版与企业版的差异

整体上来说,社区版比企业版少一些可视化以及图算法

  • 测试硬件环境

  • 性能对比

我们使用不同量级的图从入库时间,一度好友查询,二度好友查询,共同好友查询几个方面进行了对比,结果如下:

可以看到在导入性能上,数据量小的时候 Nebula Graph 的导入效率稍慢于 Neo4j,但在大数据量的时候 Nebula Graph 的导入明显优于其他两款图数据库;在 3 种查询场景下, Nebula Graph 的效率都明显高于 Neo4j,与 HugeGraph 相比也有一定的优势。

  • 查询语言对比

从查询语句的角度出发,Gremlin 比较复杂,nGQL 和 Cypher 比较简练,从可读性角度出发,nGQL 比较类 SQL 化,比较符合大家的使用习惯。

  • 可视化对比

在可视化方面,所有的平台都还只处于可用状态,Nebula Graph 的选择性扩展在团伙挖掘中是一个加分项,但是在二度结果展示流畅度,展示结果自定义展示方面还有优化空间。

在比较了多款业内主要使用的开源数据库后,我们从性能,学习成本和与业务的贴合程度多个角度考虑,最终选择了性能出众,上手简单,能大幅提高业务效率的 Nebula Graph 图数据库。

总结

随着知识图谱规模的日益增长,数据管理愈加重要。随着三元组库和图数据库的相互融合发展,知识图谱的存储和数据管理手段将愈加丰富和强大。本文主要讲述的是知识图谱存储技术、数据库的对比,进而能在进行知识存储中进行选择适合自己研发场景的数据库。

更多优质内容请关注公号:汀丶人工智能;会提供一些相关的资源和优质文章,免费获取阅读。

参考链接

https://blog.csdn.net/wnm23/article/details/130093888

知识图谱的综述、构建、存储与应用
如何高效存储大规模知识图谱数据?基于机器学习的知识图谱存储结构—论文
知识图谱入门:知识图谱存储、融合、可视化、图表示计算与搜索常用工具总结
美团图数据库平台建设及业务实践 - 美团技术团队 (meituan.com)
(8 条消息) Neo4j 和 Nebula Graph 和 HugeGraph 对比选型_会发 paper 的学渣的博客 - CSDN 博客_nebula neo4j
企业版报价 NebulaGraph Database (nebula-graph.com.cn)

相关实践学习
阿里云图数据库GDB入门与应用
图数据库(Graph Database,简称GDB)是一种支持Property Graph图模型、用于处理高度连接数据查询与存储的实时、可靠的在线数据库服务。它支持Apache TinkerPop Gremlin查询语言,可以帮您快速构建基于高度连接的数据集的应用程序。GDB非常适合社交网络、欺诈检测、推荐引擎、实时图谱、网络/IT运营这类高度互连数据集的场景。 GDB由阿里云自主研发,具备如下优势: 标准图查询语言:支持属性图,高度兼容Gremlin图查询语言。 高度优化的自研引擎:高度优化的自研图计算层和存储层,云盘多副本保障数据超高可靠,支持ACID事务。 服务高可用:支持高可用实例,节点故障迅速转移,保障业务连续性。 易运维:提供备份恢复、自动升级、监控告警、故障切换等丰富的运维功能,大幅降低运维成本。 产品主页:https://www.aliyun.com/product/gdb
相关文章
|
24天前
|
Cloud Native OLAP OLTP
在业务处理分析一体化的背景下,开发者如何平衡OLTP和OLAP数据库的技术需求与选型?
在业务处理分析一体化的背景下,开发者如何平衡OLTP和OLAP数据库的技术需求与选型?
122 4
|
29天前
|
关系型数据库 分布式数据库 数据库
数据库流行度排行榜会影响你的数据库选型吗
【2月更文挑战第33天】数据库流行度排行榜会影响你的数据库选型吗
16 2
|
1月前
|
存储 SQL Web App开发
SQL实践篇(一):使用WebSQL在H5中存储一个本地数据库
SQL实践篇(一):使用WebSQL在H5中存储一个本地数据库
44 2
|
4天前
|
存储 关系型数据库 MySQL
如何处理爬取到的数据,例如存储到数据库或文件中?
处理爬取的数据,可存储为txt、csv(适合表格数据)或json(适合结构化数据)文件。若需存储大量数据并执行复杂查询,可选择关系型(如MySQL)或非关系型(如MongoDB)数据库。以MySQL为例,需安装数据库和Python的pymysql库,创建数据库和表,然后编写Python代码进行数据操作。选择存储方式应考虑数据类型、数量及后续处理需求。
12 1
|
11天前
|
存储 SQL Oracle
【Oracle】玩转Oracle数据库(二):体系结构、存储结构与各类参数
【Oracle】玩转Oracle数据库(二):体系结构、存储结构与各类参数
35 7
|
19天前
|
数据库 存储 BI
SAP ABAP CDS View 源代码存储的数据库表揭秘和其他相关数据库表介绍试读版
SAP ABAP CDS View 源代码存储的数据库表揭秘和其他相关数据库表介绍试读版
11 0
SAP ABAP CDS View 源代码存储的数据库表揭秘和其他相关数据库表介绍试读版
|
28天前
|
存储 SQL 数据库
C# 将 Word 转文本存储到数据库并进行管理
C# 将 Word 转文本存储到数据库并进行管理
|
1月前
|
人工智能 自然语言处理 NoSQL
悦数图数据库推出 AI 知识图谱构建器及图语言生成助手
随着人工智能应用在全球范围的普及和风靡,大语言模型技术(Large Language Model,简称 LLM)受到了广泛的关注和应用。而图数据库作为一种处理复杂数据结构的工具,能够为企业构建行业大语言模型提供强大的支持,包括丰富亿万级别的上下文信息,提升模型的应答精度,从而实现企业级的应用效果。同时,Graph+LLM 可以助力快速构建知识图谱,帮助企业更深入地理解和挖掘数据价值。
|
1月前
|
关系型数据库 分布式数据库 数据库
据库流行度排行榜可能会影响他们的数据库选型
【2月更文挑战第12天】据库流行度排行榜可能会影响他们的数据库选型
20 8
|
1月前
|
存储 弹性计算 NoSQL
阿里云突发!上百种云产品大规模降价,云服务器、云数据库、存储价格下调
阿里云突发!上百种云产品大规模降价,云服务器、云数据库、存储价格下调
103 2