在图数据库中有三大组件——图计算、图存储以及图查询语言。上一个篇文章,老夫聊到了图存储,重点讲的是它的基础概念以及图存储引擎的架构设计中的一对重要概念——非原生图与原生图,接下来我们就聊聊关于图存储数据结构与构图的那些事儿吧。
我们知道,在实际的应用场景中,SQL类数据库很少用来做2层或以上的查询,这是由它的存储结构和计算模式决定的。
例如,在一个工商图谱中,从某个企业顶点出发,以递归的方式查询它的投资人(上游),找到所有持股比例大于0.1%的股东,穿透5层,并返回全部的持股路径(及完整的子图)。
显然,这个问题如果用SQL来解决会非常复杂,代码量大,而且因“递归穿透”问题而导致代码可读性低。当然,它最大的问题是计算复杂度高,时效性变得很差(性能会指数级地差于基于原生图的图计算系统)。
另外一个方面,SQL非常不善于处理异构的数据,例如持股路径,一条路径上有点、边,而且是不同类型的点(公司和人),从数据组装角度来看,还需要在SQL之外封装如XML、JSON之类的数据结构,才可能支持如此复杂的查询逻辑(业务逻辑)。在一个有1万条持股关系的表中进行5层查询的耗时为38s,SQL代码
订阅专栏 解锁全文
571

被折叠的 条评论
为什么被折叠?



