图数据库比关系数据库更先进么？
传闻中的图数据库
最近老是听到图数据库，说其有很多用处，例如：
智能问答
反欺诈
反洗钱
智能推荐
......
也听到有同事表示，图数据库可以做到关系数据库可以做到的任何事情，但我自身对图数据库的理解仅仅只局限于图的数据模型是
有多个实体
实体之间有关系进行关联
如下,引自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
- 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号（企鹅号）传播渠道之一，根据《腾讯内容开放平台服务协议》转载发布内容。
- 如有侵权，请联系 cloudcommunity@tencent.com 删除。
相关快讯
扫码
添加站长 进交流群
领取专属 10元无门槛券
私享最新 技术干货
腾讯云开发者
