数据集|两大挑战！是什么阻碍了图形数据库的扩展？( 二 ) 数据库|阻碍|节点|挑战|扩展

假设数据集已经远远满足单个实例所需，或者操作者想要提高群集或是全包的可用性和处理能力。在图形案例中，分片的意思就是拆除之前所建立的连接，因为图形遍历所需的数据当前可能留在不同计算机上。这会导致的查询信息时网络延迟，网络可能不是开发人员的问题，但查询性能就是了。
即使现代Gbit 网络和服务器位于同一机架，网络查找的成本也比内存中在查找贵5000倍左右。若在连接群集服务器的网络上添加一点负载，后果不可预想。

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

文章插图
在诈骗检测、IT网络管理，甚至现代企业识别和访问管理案例中，可能会涉及到分配图形数据，同时还需要以低于秒的性能执行查询功能。而查询执行期间产生的大量网络跃点可能会使之失败，付出高昂的缩放代价。
【 数据集|两大挑战！是什么阻碍了图形数据库的扩展？】大多数情况下，如果对数据有一些了解，你就可以更智能地来分片图形（客户 ID、区域等）。其他时候，也可以使用分布式图形分析，通过使用社区检测算法（例如ArangoDB的Pregel 套件）生成此域知识，从而进行计算。
例如，诈骗检测就需要分析财务交易以确定诈骗套路。在过去，骗子利用某些国家或地区的银行来洗钱。我们可以使用此领域知识作为图形数据集的分片密钥，并在 DB 服务器1上分配在此区域执行的所有财务事务，并在其他服务器上分配处理其他事务。

文章插图
而现在，使用ArangoDB的SmartGraph功能，本地就能阻止洗钱或查询其他图形的请求，避免或至少大幅度降低了查询期间所产生的网络跃点。这究竟是如何做到的？
ArangoDB中的查询引擎能够记忆遍历所需的数据存储位置，并向每个数据库服务器的查询引擎发送请求，然后在本地处理请求。之后，每个数据库服务器上结果的差异会被合并到协调器并发送到客户端。对于层次分明的图形，还可以利用不相交的智能图来优化查询。
对于解决数据缩放问题的呼声越来越高，而图形技术对于回答此类复杂的问题也愈发重要。
笔者可以肯定地说，图形数据库在垂直方向上扩展是可行的，在ArangoDB中，水平扩展也能实现。当然，在有些极端不常见的情况下，中心节点索引和SmartGraphs也都无能为力。
留言点赞关注
我们一起分享AI学习与发展的干货
如转载，请后台留言，遵守转载规范