图数据库比关系数据库更先进么?

传闻中的图数据库

最近老是听到图数据库,说其有很多用处,例如:

智能问答

反欺诈

反洗钱

智能推荐

......

也听到有同事表示,图数据库可以做到关系数据库可以做到的任何事情,但我自身对图数据库的理解仅仅只局限于图的数据模型是

有多个实体

实体之间有关系进行关联

如下,引自NEO4J网站:

那图数据库究竟是怎样存储这些数据的,为啥它就能适用于上述那些场景,他真的比关系数据库先进么?

这一直成为我挥之不去的谜团,这两天我了解了一下图数据库的基本概念及使用形式,终于对图数据库有了一个大致的认知。

从NEO4J的RDB VS GRAPH DB 文档中学习

NE04J是一个图数据库,对图数据库的入门我是从NEO4J的这篇文章开始的

关系数据库的存储模型

文章开始部分陈述了关系数据库的数据模型,如下图,引自neo4j网站:

正确的说,这仅仅是关系数据库范式指导下设计的数据模型。

在上面的关系数据库表设计示例中,我们可以看到,Employee单独存储,Departments单独存储,员工与部门的关系也单独存储,在获得一个员工从属于哪个部门时需要做表关联,对应到硬盘中,就是需要从硬盘的三大块区域,7个磁盘位置,里找到7行数据后做处理才有结果。

也就是说在这个数据模型下,性能很低。

图数据库的存储模型

然后文章继续介绍了图数据库下的存储模型,如下,引自NEO4J网站:

在图数据中,BELONGS这个关系数据会跟实体数据Alice存储到一起,这样的话,就能大大地提升 “Alice是哪个部门的员工”这个问题的解决速度,因为它减少了磁盘查询的次数,只需要从4个磁盘位置里拿到对应的数据即可。

以上差别是图数据库与传统关系数据库的最核心差别。

图数据库的查询形式

其查询是使用一种叫Cypher的语言进行的,如下:

以上是一个查询语句,跟SQL很像,但对图这种数据结构做了表达上的优化。

对图数据库的初步推断

从其查询的形式上来看,要实现筛查d.name= "IT Department"的人名,那么必须能建索引。

从其存储形式,一个实体要包含所有的各种各样的关系上来看,其必须支持动态的数据结构

因此在我看来图数据库就是拥有以下特性的存储引擎:

对图查询进行了表达形式优化的类SQL查询语言

动态字段存储

KV形式的一级索引(也有可能是BTREE形式)

BTREE形式的二级索引

在数据组织形式和查询读取技术中其应并无更多的黑科技。

在我眼中的 图数据库 VS 关系数据库

在NEO4J的文档里,大力吹嘘图数据库的优势,但完全没有提到其缺点,并且之前就提到了,其有很多独特的应用场景,如一开始就提到的反洗钱、反欺诈、推荐等等场景,那他应该是一个颠覆性的产品,可以完全替代RDBS,为什么现实中RDBS是主流呢?

实际上,这还是一个老生常谈的原因,不同的数据库适用于不同的场景。

在我的眼中,实际图数据库和关系数据库的本质区别是其数据模型的设计理念(如果说数据库范式就是关系数据库设计理念的话)。

传统关系数据库也可以用于存储查询图模式的数据,只要根据范式设计原则反向设计一下就可以了。

对应到上面的员工、部门、从属关系 的例子,在RDB中,可以将从属关系变成一个字段值 “111,119,189”就可以存储到关系数据库的员工行记录里了。经过这种范式反的过程后,关系数据库存储的数据模型形式就跟图数据库存储一样了。

既然如此,图数据库为什么诞生了呢?因为:

关系数据库的行格式是固定的,要做动态字段就要自行代码处理呀

可能数据库里的BTREE的聚簇对于图来说也是不必要的,有额外的性能消耗呀

NODE的物理大小变化范围很大,跟RDS数据库的优化形式可能不匹配会下降性能呀

SQL语言表达能力强,但是写起来繁琐,没有针对图数据模型进行优化呀

因此图数据库为了处理这些不方便,应运而生了。

图数据模式 VS 范式设计模式

这里讨论的是两种设计理念的联系与区别。

我们之前就已经多次提到了,范式在关系数据库的现代应用中,会做反范式化的一些处理以提升性能。

然后我们看图数据模式,以下的内容引用自NEO4J博客最差实践描述,可搜索dark-side-neo4j-worst-practices:

In terms of data modeling, it’s important to find the middle ground between placing all attributes and properties in a single node and separating each attribute into an individual node. Both of the following extremist approaches will cause significant problems for your graph, as you can see below:

Of course, the right way to model that kind of case is in the middle so everything that is a thing on its own should be a node. So a person, of course, and maybe their address should be a node on its own, but then you should make use of properties which describe the attributes of those entities.

意思大概就是,你不能把一个人的所有 关系/属性 都变成关系,或者都变成属性。你要适中选择一个度,例如地址可以成为单独一个实体,用关系与"NODE-人"进行关联,其他的都是人的属性。

那何谓适合的度呢?

假设存在这么一个设计,人物NODE 与 地址NODE产生关联,地址NODE与 省份NODE、市NODE、县NODE产生关联

如果我需要知道 人物NODE所在的省份信息,是不是需要通过地址这个NODE跳转一下(JOIN一下)再查找省份信息呢?这会不会很慢呢?

还是说,我们知道了我们要查省份这个信息,因此,我们就直接把省份这个信息直接关联到人物这个NODE里呢?如果很多间接关系都直接扔到了一个NODE里,会不会NODE变得无穷大,也变得很慢呢?

按照我们最初对图数据库的理解,实体的关系都会直接存储到实体中,但是通过这些情况的分析,我们会发现,是不会这么做的,这要看那些关系是我们关心的,一些多层间接关系我们不关心的话,就直接通过多个间接关系表达就可以了。

现在有没有一点 对于 图模式数据 和 范式化模式数据 的联系区别有点感觉?

对,在我看来,图数据模型以及范式化数据模型是两个极端:

极端的图数据模型从实体出发整合了一个实体的所有关系

极端的范式数据模型从关系出发,整合了所有同类型的关系

而真正高性能的数据模型,取决于业务数据使用形态,在他们之间取得一个适合于业务的平衡。

给出最终结论

最后,图数据库只是一个从图数据模型设计理念出发,有特定适合场景的数据库实现而已,并无神奇的地方。

对于靠近 图数据库模型设计理念的数据模型,其以实体维度组织数据,可以更好地获取一个实体的属性及关系,因此对于识别实体特性的场景更高效,如识别账户是否被卷入欺诈等。

而对于靠近 范式数据库设计理念的数据模型,其以关系维度组织整合同类关系,可以更好地获得一类关系的整体特征,同时由于同一类关系其格式形态固定,因此能获得更好的更新及插入性能。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180816G1DDBP00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券