在 SmartGraphs here 的描述中，它似乎暗示图形遍历查询实际上是从机器到机器的边，直到查询完成执行。它实际上是这样工作的吗？例如，假设您有以下查询，从 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
有人可以引导我完成从客户端开始到客户端结果结束的此查询的整个生命周期吗？
【问题讨论】：
标签： arangodb
与我们网站上的架构相比，实际发生的情况可能会有所不同。我们展示的是一种“最坏情况”，即数据无法完美分片（只是为了让它更有趣）。但是，让我们先快速退一步来描述 ArangoDB 集群中的不同角色。如果您已经了解我们的集群术语/架构，请跳过下一段。
您拥有协调器，顾名思义，它协调查询执行，也是构建最终结果集以将其发送回客户端的地方。协调器是无状态的，托管一个查询引擎，是 Foxx 服务所在的地方。实际数据以有状态的方式存储在 DBservers 上，但 DBservers 也有一个分布式查询引擎，它在我们所有的分布式查询处理中起着至关重要的作用。集群的大脑是至少有 3 个代理运行 RAFT 共识协议的代理。
当您将图形数据集分片为 SmartGraph 时，将查询发送到协调器时会发生以下情况。 - 协调器知道查询所需的数据位于哪台机器上 并将查询相应地分发给相应的 DBserver。 - 每个 DBserver 都有自己的查询引擎，并在本地处理来自 Coordinator 的传入查询，然后将中间结果发送回 coordinator，最终结果集在其中组合在一起。这并行运行。 - 协调器将结果发送回客户端。
如果您有一个完全可分片的图（例如，其分支是分片的层次结构//用例可以是例如物料清单或网络分析），那么您可以获得接近单个实例的性能，因为查询可以发送到正确的 DBservers 并且不需要网络跃点。 如果您有一个更加“非结构化”的图，例如社交网络，其中任何两个给定顶点之间都可以发生连接，那么分片就成为一个优化问题，并且根据查询，更有可能发生服务器之间的网络跃点。后一种情况显示在我们网站上的模式中。在他的案例中，SmartGraph 功能可以将所需的网络跳数降至最低，但并非完全。
希望这会有所帮助。
【讨论】：