位置:编程技术网 > 架构设计 > 正文 >

数易轩解读:图数据库是什么?图数据库的发展思路

2020年10月13日 00:40来源:未知手机版

马修·格雷·古柏勒,push push baby,丘倩鸣

>属性图由顶点(圆圈)、边(箭头)、属性(key:value)和标签组成,顶点和边可以有标签,比如顶点的标签是User,边的标签是FOLLOWS。图中标签为User的顶点有name属性,属性值为Johan或Peter或Emil。边表示了他们的关注关系。图中标签为FOLLOWS的边是单向边,如果是相互关注了,那么需要2条边表示。

如果不算上标签,属性图自身的关系可以用下图表示:

>Q:为什么需要图数据库,相比关系型数据库等有什么优势?

A:因为关系型数据库不擅长处理数据之间的关系。

>上图是一个使用关系数据库模型实现的商品交易的例子。如果要做商品推荐相关的查询时,可以发现其中一些查询是低效的(例如,“客户购买了什么产品?”),而有些查询可能是无法完成的(例如,“哪些客户购买了该产品?”)。

Q:能举个更详细的对比例子吗?

A:假设我们要查找某个公司的员工Alice属于哪个部门。

>在关系型数据库中,一般需要建立员工信息表,员工和部门对应关系表(假设一个员工可以属于多个部门),部门信息表。查找时需分为3步:

A,先要通过员工信息表找到Alice对应的工号;

B,再使用工号去关系表中找到其对应的部门ID;

C,最后使用部门ID在部门信息表中找到部门名称等信息。

A需要一次索引查找过程,B也需要一次索引查找,C可能需要3次索引查找。如果是个大型公司,员工数万甚至十多万,那么员工和部门对应关系表的记录会非常多,B的查找效率会远低于A和C。

>但如果在图数据库中,就不需要那么复杂的查询。这正是因为图数据库与关系型数据库的建模方式不同,或者说数据的存储方式不同。在图数据库中,员工和部门都在同一张图中,通过边直接建立关系。在查找时也是分为3步:

a,先通过在员工标签Person上建立的全局索引(可稀疏)来找到Alice对应的节点Na;

b,再通过Na节点保存的标签为BELONGS_TO的边来找到对应的部门;

c,最后读取部门信息。

虽然也可以分为3步,但效率却大不相同。a的效率基本等价于A;b无需进行索引查找,直接可以通过Na节点获取,虽然Na节点可能存在非常多不同标签的边,但跟员工和部门关系表的记录数肯定不是一个数量级的,而且通过Na查找边时还可以走Na节点的局部索引来加速查找;c的效率不同的图数据库会有所不同,对于支持免索引邻接的Neo4J等图数据库,Na直接指向3个部门节点的物理地址,对于其他非原生图存储的数据库,比如JanusGraph,需要查找在部门标签Department上建立的全局索引。

Q:有具体的性能测试数据不?

A:我们举最经典的社交网络中查询的性能作为对比。

>上图为一个社交网络,图中包括了朋友、同事、夫妻和恋人等多种关系。有人曾做过一个测试:在一个包含100w人,每人约有50个朋友的社交网络中找到最大深度为5的朋友的朋友。下图为图数据库Neo4J和关系型数据库在寻找扩展朋友时的性能对比。

>从图中可以发现,深度为2时(即朋友的朋友),两种数据库性能相差不是很明显;深度为3时,很明显,关系型数据库的响应时间30s,已经变得不可接受了;深度到4时,关系数据库需要近半个小时才能返回结果,已经妄称在线数据处理系统了;深度到5时,关系型数据库已经掉入深渊。而对于图数据库Neo4J,深度从3到5,其响应时间均在3秒以内。

本文地址:http://www.reviewcode.cn/jiagousheji/177126.html 转载请注明出处!

今日热点资讯