图数据库是什么以及在业务场景的应用
【摘要】 图数据库的原始设计动机就是更好地描述实体之间的关系。图数据库与关系型数据库最大的不同就是免索引邻接。图数据模型中的每个节点都会维护与它相邻的节点关系,这就意味着查询时间与图的整体规模无关,只与每个节点的邻点数量有关,这使得图数据库在处理大量复杂关系时也能保持良好的性能。
近些年来,在大数据处理过程中有一种被广泛提及和使用的数据库,那就是图数据库。那么图数据库究竟是什么呢?
图数据库,如果是刚接触的人,可能会被其字面意思所误导。其实,图数据库并不是指存储图片、图像的数据库,而是指存储图这种数据结构的数据库。那么图又是什么呢?
图数据结构,能够很自然地表征现实世界。比如用户、门店、骑手这些实体可以用图中的点来表示,用户到门店的消费行为、骑手给用户的送餐行为可以用图中的边来表示。使用图的方式对场景建模,便于描述复杂关系。在美团,也有比较多的图数据存储及多跳查询需求,概括起来主要包括以下 4 个方面:
- 图谱挖掘: 美团有美食图谱、商品图谱、旅游图谱、用户全景图谱在内的近 10 个领域知识图谱,数据量级大概在千亿级别。在迭代、挖掘数据的过程中,需要一种组件对这些图谱数据进行统一的管理。
- 安全风控: 业务部门有内容风控的需求,希望在商户、用户、评论中通过多跳查询来识别虚假评价;在支付时进行金融风控的验证,实时多跳查询风险点。
- 链路分析: 包括代码分析、服务治理、数据血缘管理,比如公司数据平台上有很多 ETL Job,Job 和 Job 之间存在强弱依赖关系,这些强弱依赖关系形成了一张图,在进行 ETL Job 的优化或者故障处理时,需要对这个图进行实时查询分析。
- 组织架构: 公司组织架构的管理,实线汇报链、虚线汇报链、虚拟组织的管理,以及商家连锁门店的管理。比如,维护一个商家在不同区域都有哪些门店,能够进行多层关系查找或者逆向关系搜索。
什么是图
我们通过下面的例子来认识一下。
东汉末年,孙权、刘备联军曾在赤壁一带以火攻敌船之计大破曹军。
如果我们把各阵营之间的关系抽象一下,以阵营作为点,阵营之间的关系作为边,这样我们就可以用如下的图来形象地表示上述关系:
以上就是这里所谓的图(的可视化展示)。
我们把这种存储实体和实体之间关系的数据结构,称为图,Graph,图由点和边组成,一个点就是一个实体,比如上述实例中的阵营,两个实体之间的关系则用有方向或无方向的边来表示,比如刘备和孙权之间的联盟关系等。这种通用的结构可以对现实中的各种场景进行建模,从交通运输系统到组织架构管理,从工艺流程设计到社交网络。
什么是图数据库
知道了图的概念,你就可以理解什么是图数据库了。简单来说,图数据库就是用来处理图这种数据结构的工具。
不同于传统的使用二维表格存储数据的关系型数据库,图数据库在传统意义上被归类为NoSQL(Not Only SQL)数据库的一种,也就是说图数据库属于非关系型数据库。
一般的图数据库至少包含图存储、图查询、图分析这三种功能。
为什么要用图数据库
那我们为什么要用图数据库呢?我们还是用东汉末年的例子来讲解一下图数据库相对于关系型数据库的优势。
假设某关系型数据库中有三张表,分别是东汉末年人物表、东汉末年战役表和东汉末年人物参战表。
表1 东汉末年人物表
ID | 名字 | 性别 | 籍贯 | … |
---|---|---|---|---|
1 | 曹操 | 男 | 沛国谯县 | ... |
2 | 大乔 | 女 | 庐江郡皖县 | … |
3 | 关羽 | 男 | 河东解良 | … |
… | … | … | … | … |
表2 东汉末年战役表
ID | 战役 | 年份 | 攻方 | 守方 |
---|---|---|---|---|
1 | 赤壁之战 | 208 | 曹操 | 孙权、刘备 |
2 | 汉中之战 | 217-219 | 刘备 | 曹操 |
3 | 樊城之战 | 219 | 刘备 | 曹操、孙权 |
… | … | … | … | … |
表3 东汉末年人物参战表
ID | 战役 | 参战人物ID |
---|---|---|
1 | 赤壁之战 | 1 |
2 | 赤壁之战3 | |
3 | 樊城之战 | 3 |
… | … | … |
当我们想知道“樊城之战的守方是谁”,查询一般会比较快,从表2可以直接得到,但当我们想知道“刘备集团发动了哪些战争”的时候,尽管我们也可以从表2查到答案,但是我们可能需要遍历整个表2,查询效率会瞬间降低。而当我们要查询诸如“关羽出战过刘备集团发动的哪些战争”的时候,我们来看一下执行这条查询时关系型数据库是怎么做的:
- 首先通过东汉末年人物表找到关羽对应的人物ID
- 再使用东汉末年人物参战表找到其参战的战役
- 最后通过东汉末年战役表找到其参战的哪些战役的攻方是刘备集团
我们会发现,这个查询实在是太繁琐了。所以对于这种查询是关系型数据库的劣势
而如果我们将以上表格转化为如下的一张关系图谱,那么谁和谁是什么关系就一目了然了。
这么说也许你还没有真正领略到图数据库的巨大威力,我们再来看一个最经典的社交网络中查询性能对比的数据。
在《Neo4j in Action》这本书中,作者做了一个测试:在一个包含100万人,每个人约有50个朋友的社交网络中找最大深度为5的朋友的朋友,得到的实验结果如下:
测试结果表明,深度为2时两种数据库的性能差别不大,都很迅速;当深度为3时,关系型数据库需要半分钟完成查询,图数据库依旧在1秒内搞定;当深度为4时,关系型数据库耗费了接近半小时返回结果,图数据库不到2秒;而当深度达到5以后,关系型数据库就迟迟无法响应了,图数据库却依旧可以「秒杀」,表现出了非常良好的性能。
图数据库选型
在图数据库的选型上我们主要考虑了以下 5 点:(A) 项目开源,暂不考虑需付费的图数据库;(B) 分布式架构设计,具备良好的可扩展性;(C)毫秒级的多跳查询延迟;(D) 支持千亿量级点边存储;(E) 具备批量从数仓导入数据的能力。
分析 DB-Engines[2] 上排名前 30 的图数据库,剔除不开源的项目,我们将剩余的图数据库分为三类:
- 第一类:Neo4j[3]、ArangoDB[4]、Virtuoso[5]、TigerGraph[6]、RedisGraph[7]。 此类图数据库只有单机版本开源可用,性能优秀,但不能应对分布式场景中数据的规模增长,即不满足选型要求(B)、(D)。
- 第二类:JanusGraph[8]、HugeGraph[9]。 此类图数据库在现有存储系统之上新增了通用的图语义解释层,图语义层提供了图遍历的能力,但是受到存储层或者架构限制,不支持完整的计算下推,多跳遍历的性能较差,很难满足 OLTP 场景下对低延时的要求,即不满足选型要求(C)。
- 第三类:DGraph[10]、NebulaGraph[11]。 此类图数据库根据图数据的特点对数据存储模型、点边分布、执行引擎进行了全新设计,对图的多跳遍历进行了深度优化,基本满足我们的选型要求。
DGraph 是由前 Google 员工 Manish Rai Jain 离职创业后,在 2016 年推出的图数据库产品,底层数据模型是 RDF[12],基于 Go 语言编写,存储引擎基于 BadgerDB[13] 改造,使用 RAFT 保证数据读写的强一致性。
NebulaGraph 是由前 Facebook 员工叶小萌离职创业后,在 2019年 推出的图数据库产品,底层数据模型是属性图,基于 C++ 语言编写,存储引擎基于 RocksDB[14] 改造,使用 RAFT 保证数据读写的强一致性。
为什么要用图数据库:
1. 关系型数据库不擅长处理数据之间的关系,而图数据库在处理数据之间关系方面灵活且高性能
我们不可否认关系型数据库自上世纪80年代以来一直都是数据库领域发展的主力,当前,随着社交、物联网、金融、电商等领域的快速发展,由此产生的数据呈现指数级的增长,而传统的关系型数据库在处理复杂关系的数据上表现很差,这是因为关系型数据库是通过外键的约束来实现多表之间的关系引用的。查询实体之间的关系需要JOIN操作,而JOIN操作通常非常耗时。
而图数据库的原始设计动机就是更好地描述实体之间的关系。图数据库与关系型数据库最大的不同就是免索引邻接。图数据模型中的每个节点都会维护与它相邻的节点关系,这就意味着查询时间与图的整体规模无关,只与每个节点的邻点数量有关,这使得图数据库在处理大量复杂关系时也能保持良好的性能。
另外,图的结构决定了其易于扩展的特性。我们不必在模型设计之初就把所有的细节都考虑到,因为在后续增加新的节点、新的关系、新的属性甚至新的标签都很容易,也不会破坏已有的查询和应用功能。
2. 数据之间的关系越来越重要
当我们在问图数据库为什么如此重要时,其实就是在问,数据之间的关系为何如此重要?正如大家都知道人际关系的价值,其实数据的价值也在于它们之间的关联关系上。
举个例子。最近直播带货非常火,假如某个主播在微博上有几百万的粉丝,这个数据如果不利用起来,价值并不大,但如果他直播带货,把关注他的粉丝和可能来他直播间购物的顾客联系起来时,这些数据立马展现出巨大的商业价值。
3. 使用图的方式表达现实世界中的很多事物更直接,更直观,也更易于理解
自然界中有各种各样的关系,而关系型数据库只能把这些拍扁成表格形态的行列数据,而图数据基于图模型以一种直观的方式去模拟这些关系,因而更形象。
另外,现在大部分的图数据库都提供了可视化的图展示,使得查询和分析变得很直观。
4. 专业的图分析算法为实际场景提供解决方案
图数据库起源于图理论,借助于专业的图分析算法,能够为实际场景提供合适的解决方案。
图数据库平台建设
为了统一管理图数据,减少工程同学在图数据库集群上的运维压力,我们基于开源分布式图数据库 NebulaGraph,搭建了一套一站式图数据库自助管理平台(见图 4),该平台包含以下 4 层:
- 数据应用层。 业务方可以在业务服务中引入图谱 SDK,实时地对图数据进行增删改查。
- 数据存储层。 支持两种图数据库集群的部署。
- 第一种部署方式是 CP 方案,即 Consistency & Partition tolerance。单集群部署,集群中机器数量大于等于副本的数量,副本数量大于等于 3 。只要集群中有大于副本数一半的机器存活,整个集群就可以对外正常提供服务。CP 方案保证了数据读写的强一致性,但这种部署方式下集群可用性不高。
- 第二种部署方式是 AP 方案,即 Availability & Partition tolerance。在一个应用中部署多个图数据库集群,每个集群数据副本数为 1 ,多集群之间进行互备。这种部署方式的好处在于整个应用对外的可用性高,但数据读写的一致性要差些。
- 数据生产层。 图数据主要有两种来源,第一种是业务方把数仓中数据通过 ETL Job 转成点和边的 Hive 表,然后离线导入到图数据库中;第二种是业务线上实时产生的数据、或者通过 Spark/Flink 等流式处理产生的近线数据,调用在线批量写接口实时灌到图数据库中。
- 支撑平台。 提供了 Schema 管理、权限管理、数据质检、数据增删改查、集群扩缩容、图谱画像、图数据导出、监控报警、图可视化、集群包管理等功能。
与业界方案相比,团队主导设计的图数据库平台除了支持存储千亿顶点、万亿边,具备毫秒级别查询能力外,还提供了如下四项能力:应用可用性 SLA 达 99.99%;支持每小时百亿量级数据导入;实时写入数据时保证多集群数据最终一致性;易用的图谱可视化能力。下面将介绍具体的设计思路。
1. 高可用模块设计
首先介绍单应用多集群高可用模块的设计(AP 方案)。为什么有 AP 方案的设计呢?
因为接入图数据库平台的业务方比较在意的指标是集群可用性。在线服务对集群的可用性要求非常高,最基础的要求是集群可用性能达到 4 个 9,即一年里集群的不可用时间要小于一个小时。对于在线服务来说,服务或者集群的可用性是整个业务的生命线,如果这点保证不了,即使集群提供的能力再多再丰富,那么业务方也不会考虑使用,可用性是业务选型的基础。
另外,公司要求中间件要有跨区域容灾能力,即要具备在多个地域部署多集群的能力。我们分析了平台接入方的业务需求,大约 80% 的场景是 T+1 全量导入数据、线上只读。在这种场景下,对图数据的读写强一致性要求并不高,因此我们设计了单应用多集群这种部署方案。
AP 方案部署方式可以参考图 5,一个业务方在图数据库平台上创建了 1 个应用并部署了 4 个集群,其中北京 2 个、上海 2 个,平时这 4 个集群同时对外提供服务。假如现在北京集群 1 挂了,那么北京集群 2 可以提供服务。如果说真那么不巧,北京集群都挂了,或者北京侧对外的网络不可用,那么上海的集群也可以提供服务。
在这种部署方式下,平台会尽可能地通过一些方式来保证整个应用的可用性。然后每个集群内部尽量部署同机房的机器,因为图数据库集群内部 RPC 非常多,如果有跨机房或者跨区域的频繁调用,整个集群对外的性能会比较低。
高可用模块主要包含下面 4 个部分,如上图 6 所示:
第一部分是右侧的图数据库 Agent,它是部署在图数据库集群的一个进程,用来收集机器和图数据库三个核心模块的信息,并上报到图数据库平台。Agent 能够接收图数据库平台的命令并对图数据库进行操作。
第二部分是图数据库平台,它主要是对集群进行管理,并同步图数据库集群的状态到配置中心。
第三部分是图数据库 SDK,主要负责管理连接到图数据库集群的连接。如果业务方发送了某个查询请求,SDK 会进行集群的路由和负载均衡,选择出一条高质量的连接来发送请求。此外,SDK 还会处理图数据库集群中问题机器的自动降级以及恢复,并且支持平滑切换集群的数据版本。
第四部分是配置中心,类似 ZooKeeper,存储集群的当前状态。
2. 每小时百亿量级数据导入模块设计
第二个模块是每小时百亿量级数据导入模块,平台在 2019 年底- 2020 年初全量导入数据的方式是调用 NebulaGraph 对外提供的批量数据导入接口,这种方式的数据写入速率大概是每小时 10 亿级别,导入百亿数据大概要耗费 10 个小时,耗时较长。此外,在以几十万每秒的速度导数据的过程中,会长期占用机器的 CPU、IO 资源,一方面会对机器造成损耗,另一方面数据导入过程中集群对外提供的读性能会变弱。
为了解决上面两个问题,平台进行了如下优化:在 Spark 集群中直接生成图数据库底层文件 SST File,再借助 RocksDB 的 Bulkload 功能直接 ingest 文件到图数据库。
数据导入的核心流程可以参考图 7,当用户执行导数据操作后,图数据库平台会向公司的 Spark 集群提交一个 Spark 任务,在 Spark 任务中会生成图数据库里相关的点、边以及点索引、边索引相关的 SST 文件,并上传到美团的 S3 云存储上。文件生成后,图数据库平台会通知应用中多个集群去下载这些存储文件,之后完成 ingest 跟 compact 操作,最后完成数据版本的切换。
为兼顾各个业务方的不同需求,平台统一了应用导入、集群导入、离线导入、在线导入,以及全量导入、增量导入这些场景,然后细分成下面九个阶段,从流程上保证在导数据过程中应用整体的可用性:SST File 生成 、SST File 下载 、ingest、compact、数据校验、增量回溯、数据版本切换、集群重启、数据预热。
3. 实时写入多集群数据同步模块设计
第三个模块是实时写入多集群数据同步模块,平台约有 15% 的需求场景是在实时读取数据时,还要把新产生的业务数据实时写入集群,并且对数据的读写强一致性要求不高。就是说,业务方写到图数据库里的数据,不需要立马能读到。针对上述场景,业务方在使用单应用多集群这种部署方案时,多集群里的数据需要保证最终一致性。针对这一需求,我们做了以下设计。
第一部分是引入 Kafka 组件,业务方在服务中通过 SDK 对图数据库进行写操作时,SDK 并不直接写图数据库,而是把写操作写到 Kafka 队列里,之后由该应用下的多个集群异步消费这个 Kafka 队列。
第二部分是集群在应用级别可配置消费并发度,来控制数据写入集群的速度。具体流程如下:
- SDK 对用户写操作语句做语法解析,将其中点边的批量操作拆解成单个点边操作,即对写语句做一次改写。
- Agent 消费 Kafka 时确保每个点及其出边相关操作在单个线程里顺序执行(见图 8),保证这点就能保证各个集群执行完写操作后最终的结果是一致的。
- 并发扩展:通过改变 Kafka 分片数、Agent 中消费 Kafka 线程数来调整 Kafka 中操作的消费速度。如果未来图数据库支持事务的话,上面的配置需要调整成单分片单线程消费,有必要对设计方案再做优化调整。
第三部分是在实时写入数据过程中,平台可以同步生成一个全量数据版本,并做平滑切换(见图 9),确保数据的不重、不漏、不延迟。
4. 图可视化模块设计
第四个模块是图可视化模块(见图10),主要是用于解决子图探索问题。当用户在图数据库平台通过可视化组件查看图数据时,能尽量通过恰当的交互设计来避免因为节点过多而引发爆屏。主要包括以下几个功能:
- 通过 ID 或者索引查找顶点。
- 能查看顶点和边的卡片(卡片中展示点边属性和属性值),可以单选、多选、框选以及按类型选择顶点。
- 图探索,当用户点击某个顶点时,系统会展示它的一跳邻居信息,包括该顶点有哪些出边?通过这个边它能关联到几个点?该顶点的入边又是什么情况?通过这种一跳信息的展示,用户在平台上探索子图的时候,可快速了解到周边的邻居信息,更快地进行子图探索。在探索过程中,平台也支持通过属性对边进行过滤。
- 图编辑能力,让平台用户在不熟悉 NebulaGraph 语法的情况下也能增删改点边数据,对线上数据进行临时干预。
图数据库如何存储、查询、分析
图存储
图数据库如何存储图,对查询和分析效率至关重要。图数据库使用图模型来操作图数据。所谓的图模型是指图数据库描述和组织图数据的方式。
目前主流的图数据库选择的图模型是属性图。属性图由点、边、标签和属性组成,我们结合一个具体的属性图实例来看一下。
以上属性图可以帮助我们理解一些相关概念:
- 可以为点设置标签,比如 person, war等,拥有相同标签的点我们认为它们属于一个分组,是一个集合,这样刘备和曹操属于一个分组;
- 同样可以为边设置标签,标签可以为 relation等;
- 节点可以拥有很多属性,比如 style name、year等,这些属性值以键值对的形式表示,例如:刘备的style name是玄德;
- 边也可以拥有属性,比如army等;
- 边允许有方向,例如刘备和汉中之战之间的边的方向是由刘备指向汉中之战的;
- 元数据是用来描述点和边的属性信息的,元数据由若干标签组成,每个标签由若干属性组成。
图查询
如果我们想知道刘备的籍贯在哪,刘备和曹操是什么关系,汉中之战的发动方是谁等等,这些都属于图查询的范畴。
我们知道,SQL是关系型数据库的查询语言,但是图数据库的查询语言并没有复用SQL。这是因为本质上图数据库处理的是高维数据,而SQL所适用的是二维的数据结构,其并不擅长关系的查询和操作。使用专门的图查询语言比SQL更加高效。
目前主流的图查询语言包括Gremlin和Cypher等。
图分析
图分析是指通过各种图算法来挖掘图信息的一门技术。
核心的图算法可以分成三类:路径搜索类、中心性分析类和社区发现类。
路径搜索是探索图中节点通过边建立的直接或间接的联系。例如在下图中,通过路径搜索,我们发现了这样一条路径:孙策-[夫妻]-大乔-[姐妹]-小乔-[夫妻]-周瑜,据此得知孙策和周瑜是连襟的关系。路径搜索类算法广泛用于物流配送、社交关系分析等场景。
中心性分析是指分析特定节点在图中的重要程度及其影响力。例如在上图中,直观来看,孙权是一个重要的人物,因为与他直接相连的边的数量最多。中心性分析类算法一般用于网页排序、意见领袖挖掘、流感传播等场景。
社区发现意在发现图中联系更紧密的群体结构。如果把更多的三国人物和关系加到上图中,利用Louvain等社团挖掘类算法,我们很容易发现这些人物分属三个阵营,如下图所示。
社区发现类算法可用于犯罪团伙挖掘等场景。
图数据库有什么用
介绍完图数据库的主要功能,我们再来看看图数据库都有哪些应用场景。图数据库擅长的应用领域包括:
1.社交领域:Facebook, Twitter用它来进行社交关系管理、好友推荐
我们熟悉的好友推荐。就可以采用推荐好友的好友的方法。
徐庶和司马徽向刘备推荐诸葛亮可以通过下图形象地展示
2. 电商领域:
华为商城用它来实现商品实时推荐
通过分析目标用户和其他用户的喜好商品,找到相似的其他用户,把这些用户购买过的商品推荐给目标用户。
美团:图谱推荐理由
该项目数据来自用户的画像信息、商户的特征信息、用户半年内收藏/购买行为,数据量级是 10 亿级别,T+1 全量更新。现在美团 App 和点评 App 上默认的商户推荐列表是由深度学习模型生成的,但模型并不会给出生成这个列表的理由,缺少可解释性。
而在图谱里用户跟商户之间天然存在多条连通路径,项目考虑选出一条合适路径来生成推荐理由,在 App 界面上展示给用户推荐某家店的原因。该项目基于用户的协同过滤算法来生成推荐理由,在家乡、消费水平、偏好类目、偏好菜系等多个组合维度中找出多条路径,然后给这些路径打分,选出一条分值较高的路径,之后按照特定 Pattern 产出推荐理由。通过上述方式,就可以获得“在北京喜欢北京菜的山东老乡都说这家店很赞”,或者“广州老乡都中意他家的正宗北京炸酱面”这类理由。
3. 金融领域:中国工商银行、摩根大通用它来做风控管理
目前来看,金融领域对图数据库的需求很迫切,以贷款为例,在整个贷款周期中,图数据库都能发挥巨大的作用。
4. 安平领域:公安用它来进行嫌疑关系审查、犯罪团伙挖掘
东汉末年,曹操刺杀董卓,貂蝉挑拨董卓父子关系,吕布斩杀董卓,但是董卓却不知道,这些事件幕后主凶之一都有王允,如下图所示。现实中也可能是这样,幕后真凶可能与目标案件没有直接关系,只有间接的关系
5. 智能助理
该项目数据是基于美团商户数据、用户评论构建的餐饮娱乐知识图谱,覆盖美食、酒店、旅游等领域,包含 13 类实体和 22 类关系。
目前,点边数量大概在百亿级别,数据 T+1 全量更新,主要用于解决搜索或者智能助理里 KBQA(全称:Knowledge Based Question Answer)类问题。核心处理流程是通过 NLP 算法识别关系和实体后构造出 NebulaGraph SQL 语句,再到图数据库获取数据。
典型的应用场景包括商场找店,比如,某个用户想知道望京新荟城这个商场有没有海底捞,系统可以快速查出结果告诉用户;另一个场景是标签找店,用户想知道望京 SOHO 附近有没有适合情侣约会的餐厅,或者可以多加几个场景标签,系统都可以帮忙查找出来。
6. 搜索召回
该项目数据是基于医美商家信息构建的医美知识图谱,包含 9 类实体和 13 类关系,点边数量在百万级别,同样也是 T+1 全量更新,主要用于大搜底层实时召回,返回与 Query 相关的商户、产品或医生信息,解决医美类搜索词少结果、无结果问题。比如,某个用户搜“啤酒肚”这种症状、或者“润百颜”这类品牌,系统可以召回相关的医美门店。
7. 代码依赖分析
该项目把代码库中代码依赖关系写入到图数据库。代码库中存在很多服务代码,这些服务会包括对外提供的接口,这些接口的实现依赖于该服务中某些类的成员函数,这些类的成员函数又依赖了本类的成员变量、成员函数或者其它类的成员函数,那么它们之间的依赖关系就形成了一张图,可以把这个图写到图数据库里做代码依赖分析。
典型应用场景是精准测试:当开发同学完成需求并向公司的代码仓库提交了 PR 后,可以把更改实时地写到图数据库中。这样的话,开发同学就能查到他所写的代码影响了哪些外部接口,并且借助图可视化组件查看调用路径。如果开发同学本来是要改接口 A 的行为,改了很多代码,但是他可能并不知道他改的代码也会影响到对外接口 B、C、D,这时候就可以用代码依赖分析来做个 Check,增加测试的完备性。
什么样的场景适合用图数据库
你可以根据以下几点来判断你的问题是否需要图数据库:
- 如果你的问题中频繁出现多对多的关系,建议首选图数据库;
- 如果你的问题中数据之间的关系非常重要,建议首选图数据库;
- 如果你需要处理大规模数据集之间的关系,建议首选图数据库。
参考来源