两大挑战!是什么阻碍了图形数据库的扩展?

微信扫一扫,分享到朋友圈

两大挑战!是什么阻碍了图形数据库的扩展?

本文转载自公众号“读芯术”(ID:AI_Discovery)。

生活中的许多地方都在运用着数据库技术,例如诈骗检测、知识图谱、资产管理、推荐浏览器、物联网、权限管理等等。数据库技术能够快速分析相关度高的数据点以及其之间的联系,图形数据库便是其中之一。

但由于图形数据本身性质特殊,其在架构方面还面临诸多挑战。那么,图形数据库是否能够扩展呢?本文将全面分析可能阻碍图形数据库扩展的两个挑战,并讨论当前可用的解决方案。

什么是”图形数据库的可扩展性”?

“扩展”,不只是指将更多的数据存入一台计算机或随便存进多台计算机。对于大型数据集或不断增长的数据集,良好的查询性能十分必要。

所以,其中真正的问题在于,当单台计算机上的数据集增长到会影响其他功能时,图形数据库的表现能否令人满意呢?如果你还不能理解为什么这是首要问题,请和我一起快速回顾以下图形数据库。

简单来说,图形数据库用于存储无架构对象(顶点或节点)以及任意数据(属性)和对象(边缘)的关联数据。边通常能够指出对象之间的着力点,顶点和边共同构成图形网络数据集。

离散数学将图形定义为一组顶点和边;而计算机科学则将其定义为一种抽象的数据类型,它能够表示连接或关系。它不同于关系数据库系统中的表格数据结构,后者表达数据关系的能力十分有限。

如上所述,图形由节点(又名顶点[V]) 组成,这些节点由关系(即边[E])连接。

顶点具有任意数量的边和任意深度(路径的长度)的窗体路径。

它也可以针对跨行金融交易进行图形建模,如下图所示。此例中,我们可以将银行帐户定义为节点,银行交易记录与其他关系定义为边缘。

以这种方式存储帐户和交易信息,以遍历创建图形未知或变化的数据深度。在关系数据库中编写和运行此类查询功能往往是一项复杂的工作(使用多模型数据库能够以银行与其分支机构之间的关系来建模)。

图形数据库提供各种算法,以便用户查询所存储的数据及分析其间关系。包括遍历、模式匹配、最短路径或分布式图形处理,如分析社区侦测、连接组件或中心性。大多数算法都有一个共同点,这也是解决超节点和网络跃点问题的本质——算法通过边从一个节点遍历到另一个节点。

快速回顾之后,挑战就要开始啦!

“名人效应”

上文已提到顶点或节点可以具有任意数量的边。超级点的一个经典例子便是网红——超节点是图形数据集中传入或传出边条数过多的节点。帕特里克·斯图尔特爵士的Twitter账户目前就拥有340多万粉丝。

如果现在将帐户和推文数据进行图形建模,遍历其数据即Patrick Stewart的帐户信息,那么算法必须定向分析Steward帐户所有的340万条边。这就会延长查询执行时间,甚至可能突破被授权的权限。类似的问题存在于欺诈检测(帐户进行大量交易、网络管理-大型 IP hub)等案例中。

超级节点是图形的固有问题,也是所有图形数据库面临的问题,以下两种方法能尽量减少超节点的影响。

图源:unsplash

方法一:拆分超节点

更准确来说,可以复制节点”Patrick Stewart”,并按某个属性(如粉丝的国家/地区或其他特定分组)拆分数据边缘。这样就会将超节点遍历数据对性能的影响降至最低,以便查询分类时所用。

方法二:中心节点索引

以顶点为中心的索引同时存储边缘信息和有关节点的信息。还是以帕特里克·斯图尔特的 Twitter 帐户为例,可以这样分组:粉丝的起始关注日期/时间信息、粉丝的国家/地区、粉丝的粉丝数等等,以上所有属性都可以为更高效地使用()提供选择性。

查询引擎可使用索引来减少执行遍历功能所需的线性查找次数,诈骗检测也可采用此方法。上文中金融交易便是边缘,交易日期或交易金额等属性可以增加选择效率。

某些情况下,以上两种方法都不适用;遍历超节点时,性能一定程度上会下降。多数情况下,还是有办法优化性能,但另一个问题是大多数图形数据库尚未解决的。

网络跃点问题

假如需要遍历一个高度连接的数据集,查询所需的所有数据的记忆都负荷在同一台计算机上,查询单个主要记忆大约需要100ns。

假设数据集已经远远满足单个实例所需,或者操作者想要提高群集或是全包的可用性和处理能力。在图形案例中,分片的意思就是拆除之前所建立的连接,因为图形遍历所需的数据当前可能留在不同计算机上。这会导致的查询信息时网络延迟,网络可能不是开发人员的问题,但查询性能就是了。

即使现代Gbit 网络和服务器位于同一机架,网络查找的成本也比内存中在查找贵5000倍左右。若在连接群集服务器的网络上添加一点负载,后果不可预想。

这种情况下,遍历可能从数据库服务器1开始,点击具有指向存储在 DB Server 2上的顶点边缘的节点,从而通过网络进行查找网络跃点。考虑到更多实际中的情况,在单个遍历查询中,实际上是存在多个跃点的。

在诈骗检测、IT网络管理,甚至现代企业识别和访问管理案例中,可能会涉及到分配图形数据,同时还需要以低于秒的性能执行查询功能。而查询执行期间产生的大量网络跃点可能会使之失败,付出高昂的缩放代价。

更智能的解决方法

大多数情况下,如果对数据有一些了解,你就可以更智能地来分片图形(客户 ID、区域等)。其他时候,也可以使用分布式图形分析,通过使用社区检测算法(例如ArangoDB的Pregel 套件)生成此域知识,从而进行计算。

例如,诈骗检测就需要分析财务交易以确定诈骗套路。在过去,骗子利用某些国家或地区的银行来洗钱。我们可以使用此领域知识作为图形数据集的分片密钥,并在 DB 服务器1上分配在此区域执行的所有财务事务,并在其他服务器上分配处理其他事务。

而现在,使用ArangoDB的SmartGraph功能,本地就能阻止洗钱或查询其他图形的请求,避免或至少大幅度降低了查询期间所产生的网络跃点。这究竟是如何做到的?

ArangoDB中的查询引擎能够记忆遍历所需的数据存储位置,并向每个数据库服务器的查询引擎发送请求,然后在本地处理请求。之后,每个数据库服务器上结果的差异会被合并到协调器并发送到客户端。对于层次分明的图形,还可以利用不相交的智能图来优化查询。

对于解决数据缩放问题的呼声越来越高,而图形技术对于回答此类复杂的问题也愈发重要。

笔者可以肯定地说,图形数据库在垂直方向上扩展是可行的,在ArangoDB中,水平扩展也能实现。当然,在有些极端不常见的情况下,中心节点索引和SmartGraphs也都无能为力。

【责任编辑:赵宁宁 TEL:(010)68476606】

微信扫一扫,分享到朋友圈

两大挑战!是什么阻碍了图形数据库的扩展?

O'Reilly 出版社又一经典之作——Python 设计模式

上一篇

陈薇院士率队研发新冠病毒药物:改善肺部纤维化

下一篇

你也可能喜欢

两大挑战!是什么阻碍了图形数据库的扩展?

长按储存图像,分享给朋友