ArangoDB图遍历查询如何在群集中执行？

Question

在这里对SmartGraphs的描述中，似乎暗示着图遍历查询实际上沿着机器的边缘，直到查询完成执行为止。 那实际上是这样吗？ 例如，假设您具有以下查询，该查询从ID为12345的人开始检索1-hop，2-hop和3-hop朋友：

FOR p IN Person
  FILTER p._key == 12345
  FOR friend IN 1..3 OUTBOUND p knows
    RETURN friend

有人可以指导我从客户端开始一直到客户端结果结束整个查询过程吗？

Answer 1

与我们网站上的架构相比，实际发生的情况可能有所不同。 我们展示的是一种“最坏的情况”，其中数据无法完美分片（只是为了使其更加有趣）。 但是，让我们先快速退一步来描述ArangoDB集群中的不同角色。 如果您已经了解我们的群集语言/体系结构，请跳过下一段。

顾名思义，您有一个协调器，它协调查询的执行，并且也是建立最终结果集以将其发送回客户端的地方。 协调器是无状态的，承载查询引擎，并且是Foxx服务所在的地方。 实际数据以有状态方式存储在DB服务器上，但是DB服务器还具有分布式查询引擎，该引擎在我们所有的分布式查询处理中都起着至关重要的作用。 集群的大脑是具有至少三个运行RAFT共识协议的代理的代理。

将图形数据集拆分为SmartGraph时，将查询发送给Coordinator时会发生以下情况。 -协调器知道查询所需的数据驻留在哪台计算机上，并将查询相应地分发到各个DB服务器。 -每个数据库服务器都有自己的查询引擎，并在本地处理来自协调器的传入查询，然后将中间结果发送回协调器，最终结果集将合并到该协调器中。 这是并行运行的。 -协调器然后将结果发送回客户端。

如果您有一个完全可分割的图（例如，其分支为分片的层次结构，//用例可以是例如物料清单或网络分析），则可以实现接近单个实例的性能，因为可以将查询发送到正确的DBserver，并且不需要网络跃点。 如果您有一个更“非结构化”的图（例如社交网络），其中可以在任意两个给定的顶点之间发生连接，则分片将成为一个优化问题，并且根据查询的不同，服务器之间的网络跳跃的可能性更大。 后一种情况显示在我们网站的架构中。 在他的案例中，SmartGraph功能可以将所需的网络跃点最小化，但不能完全减少。

希望这能有所帮助。