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功能可以將所需的網絡躍點最小化，但不能完全減少。

希望這能有所幫助。