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


查询引擎可使用索引来减少执行遍历功能所需的线性查找次数 , 诈骗检测也可采用此方法 。 上文中金融交易便是边缘 , 交易日期或交易金额等属性可以增加选择效率 。
某些情况下 , 以上两种方法都不适用;遍历超节点时 , 性能一定程度上会下降 。 多数情况下 , 还是有办法优化性能 , 但另一个问题是大多数图形数据库尚未解决的 。
两大挑战!是什么阻碍了图形数据库的扩展?文章插图
网络跃点问题假如需要遍历一个高度连接的数据集 , 查询所需的所有数据的记忆都负荷在同一台计算机上 , 查询单个主要记忆大约需要100ns 。
假设数据集已经远远满足单个实例所需 , 或者操作者想要提高群集或是全包的可用性和处理能力 。 在图形案例中 , 分片的意思就是拆除之前所建立的连接 , 因为图形遍历所需的数据当前可能留在不同计算机上 。 这会导致的查询信息时网络延迟 , 网络可能不是开发人员的问题 , 但查询性能就是了 。
即使现代Gbit 网络和服务器位于同一机架 , 网络查找的成本也比内存中在查找贵5000倍左右 。 若在连接群集服务器的网络上添加一点负载 , 后果不可预想 。
两大挑战!是什么阻碍了图形数据库的扩展?文章插图
这种情况下 , 遍历可能从数据库服务器1开始 , 点击具有指向存储在 DB Server 2上的顶点边缘的节点 , 从而通过网络进行查找网络跃点 。 考虑到更多实际中的情况 , 在单个遍历查询中 , 实际上是存在多个跃点的 。
两大挑战!是什么阻碍了图形数据库的扩展?文章插图
在诈骗检测、IT网络管理 , 甚至现代企业识别和访问管理案例中 , 可能会涉及到分配图形数据 , 同时还需要以低于秒的性能执行查询功能 。 而查询执行期间产生的大量网络跃点可能会使之失败 , 付出高昂的缩放代价 。
两大挑战!是什么阻碍了图形数据库的扩展?文章插图
更智能的解决方法大多数情况下 , 如果对数据有一些了解 , 你就可以更智能地来分片图形(客户 ID、区域等) 。 其他时候 , 也可以使用分布式图形分析 , 通过使用社区检测算法(例如ArangoDB的Pregel 套件)生成此域知识 , 从而进行计算 。
例如 , 诈骗检测就需要分析财务交易以确定诈骗套路 。 在过去 , 骗子利用某些国家或地区的银行来洗钱 。 我们可以使用此领域知识作为图形数据集的分片密钥 , 并在 DB 服务器1上分配在此区域执行的所有财务事务 , 并在其他服务器上分配处理其他事务 。
两大挑战!是什么阻碍了图形数据库的扩展?文章插图
而现在 , 使用ArangoDB的SmartGraph功能 , 本地就能阻止洗钱或查询其他图形的请求 , 避免或至少大幅度降低了查询期间所产生的网络跃点 。 这究竟是如何做到的?
ArangoDB中的查询引擎能够记忆遍历所需的数据存储位置 , 并向每个数据库服务器的查询引擎发送请求 , 然后在本地处理请求 。 之后 , 每个数据库服务器上结果的差异会被合并到协调器并发送到客户端 。 对于层次分明的图形 , 还可以利用不相交的智能图来优化查询 。
对于解决数据缩放问题的呼声越来越高 , 而图形技术对于回答此类复杂的问题也愈发重要 。
笔者可以肯定地说 , 图形数据库在垂直方向上扩展是可行的 , 在ArangoDB中 , 水平扩展也能实现 。 当然 , 在有些极端不常见的情况下 , 中心节点索引和SmartGraphs也都无能为力 。
两大挑战!是什么阻碍了图形数据库的扩展?文章插图
留言点赞关注
我们一起分享AI学习与发展的干货
如转载 , 请后台留言 , 遵守转载规范