Performance ArangoDB 3.0群集-读/写速度零改进？

我通过DC/OS 1.7设置了ArangoDB 3.0集群，如下所示：

我尝试了两个关于3x co ord，6x服务器设置的查询。每个节点都有以下规格：

• 15GB RAM（通过DC/OS为每个数据库主设备分配4GB）
• 8芯
• 科雷奥斯

我尝试了两个查询来测试

coins

集合的性能。没有添加任何指数。集合的配置为：

Wait for sync:  false
Type:   document
Status: loaded
Shards: 16
Replication factor: 1
Index buckets:  8

写入：

FOR i IN 1..1000000 INSERT {flip:RAND() > 0.5 ? 'h' : 't'} IN coins

FOR coin IN coins COLLECT flip = coin.flip WITH COUNT INTO total RETURN {flip, total}

结果:

执行计划：

 Id   NodeType            Site          Est.   Comment
  1   SingletonNode       COOR             1   * ROOT
  2   CalculationNode     COOR             1     - LET #2 = 1 .. 1000000   /* range */   /* simple expression */
  3   EnumerateListNode   COOR       1000000     - FOR i IN #2   /* list iteration */
  4   CalculationNode     COOR       1000000       - LET #4 = { "flip" : ((RAND() > 0.5) ? "h" : "t") }   /* v8 expression */
  6   DistributeNode      COOR       1000000       - DISTRIBUTE
  7   RemoteNode          DBS        1000000       - REMOTE
  5   InsertNode          DBS              0       - INSERT #4 IN coins
  8   RemoteNode          COOR             0       - REMOTE
  9   GatherNode          COOR             0       - GATHER

Indexes used:
 none

Optimization rules applied:
 Id   RuleName
  1   remove-data-modification-out-variables
  2   distribute-in-cluster

Write query options:
 Option                   Value
 ignoreErrors             false
 waitForSync              false
 nullMeansRemove          false
 mergeObjects             true
 ignoreDocumentNotFound   false
 readCompleteInput        false

 Id   NodeType                  Site          Est.   Comment
  1   SingletonNode             DBS              1   * ROOT
  2   EnumerateCollectionNode   DBS        1000000     - FOR coin IN coins   /* full collection scan */
  3   CalculationNode           DBS        1000000       - LET #3 = coin.`flip`   /* attribute expression */   /* collections used: coin : coins */
 10   RemoteNode                COOR       1000000       - REMOTE
 11   GatherNode                COOR       1000000       - GATHER
  4   CollectNode               COOR        800000       - COLLECT flip = #3 WITH COUNT INTO total   /* hash*/
  7   SortNode                  COOR        800000       - SORT flip ASC
  5   CalculationNode           COOR        800000       - LET #5 = { "flip" : flip, "total" : total }   /* simple expression */
  6   ReturnNode                COOR        800000       - RETURN #5

Indexes used:
 none

Optimization rules applied:
 Id   RuleName
  1   move-calculations-up
  2   move-calculations-down
  3   scatter-in-cluster
  4   distribute-filtercalc-to-cluster
  5   remove-unnecessary-remote-scatter

阅读：

FOR i IN 1..1000000 INSERT {flip:RAND() > 0.5 ? 'h' : 't'} IN coins

FOR coin IN coins COLLECT flip = coin.flip WITH COUNT INTO total RETURN {flip, total}

结果:

执行计划：

 Id   NodeType            Site          Est.   Comment
  1   SingletonNode       COOR             1   * ROOT
  2   CalculationNode     COOR             1     - LET #2 = 1 .. 1000000   /* range */   /* simple expression */
  3   EnumerateListNode   COOR       1000000     - FOR i IN #2   /* list iteration */
  4   CalculationNode     COOR       1000000       - LET #4 = { "flip" : ((RAND() > 0.5) ? "h" : "t") }   /* v8 expression */
  6   DistributeNode      COOR       1000000       - DISTRIBUTE
  7   RemoteNode          DBS        1000000       - REMOTE
  5   InsertNode          DBS              0       - INSERT #4 IN coins
  8   RemoteNode          COOR             0       - REMOTE
  9   GatherNode          COOR             0       - GATHER

Indexes used:
 none

Optimization rules applied:
 Id   RuleName
  1   remove-data-modification-out-variables
  2   distribute-in-cluster

Write query options:
 Option                   Value
 ignoreErrors             false
 waitForSync              false
 nullMeansRemove          false
 mergeObjects             true
 ignoreDocumentNotFound   false
 readCompleteInput        false

 Id   NodeType                  Site          Est.   Comment
  1   SingletonNode             DBS              1   * ROOT
  2   EnumerateCollectionNode   DBS        1000000     - FOR coin IN coins   /* full collection scan */
  3   CalculationNode           DBS        1000000       - LET #3 = coin.`flip`   /* attribute expression */   /* collections used: coin : coins */
 10   RemoteNode                COOR       1000000       - REMOTE
 11   GatherNode                COOR       1000000       - GATHER
  4   CollectNode               COOR        800000       - COLLECT flip = #3 WITH COUNT INTO total   /* hash*/
  7   SortNode                  COOR        800000       - SORT flip ASC
  5   CalculationNode           COOR        800000       - LET #5 = { "flip" : flip, "total" : total }   /* simple expression */
  6   ReturnNode                COOR        800000       - RETURN #5

Indexes used:
 none

Optimization rules applied:
 Id   RuleName
  1   move-calculations-up
  2   move-calculations-down
  3   scatter-in-cluster
  4   distribute-filtercalc-to-cluster
  5   remove-unnecessary-remote-scatter

然后我缩小到只有1个协调器和1个服务器，将可用RAM从90GB/48核减少到15GB/8核

我希望写作和阅读能显示出一些不同。以下是相同查询的结果（在截断集合并重新运行后）：

写入：

FOR i IN 1..1000000 INSERT {flip:RAND() > 0.5 ? 'h' : 't'} IN coins

FOR coin IN coins COLLECT flip = coin.flip WITH COUNT INTO total RETURN {flip, total}

阅读：

FOR i IN 1..1000000 INSERT {flip:RAND() > 0.5 ? 'h' : 't'} IN coins

FOR coin IN coins COLLECT flip = coin.flip WITH COUNT INTO total RETURN {flip, total}

结果-几乎相同的执行时间。

问题:

• 我是否错过了某些步骤：显式复制？（我尝试了“重新平衡碎片”——这导致一些额外的DB服务器被标记为追随者，但对执行速度没有影响）

• 我的收藏配置是否最优？我根据文档中的“DBPrimary squared”建议选择了16个碎片（我最初的设置使用了4台服务器，性能相当）

• 我尝试的查询是否能够有效地进行集群？远程循环等

• 我是否可以尝试一些示例查询来测试集群是否正确配置，并最终证明1x节点与n节点之间的读/写性能差异

---

我想我可以解释一下这些问题（作为ArangoDB的核心开发人员之一，负责分布式模式）。以下评论考虑ARANGODB版本3。

3.0及之前版本中的单个AQL查询仅使用单个协调器。因此，部署更多的协调器不会加快单个查询的速度，无论是写入查询还是读取查询

这很难改变，因为AQL在集群中组织了一条数据管道，而且很难让多个协调员参与

如果您编写查询，我们目前仍对3.0中涉及的集合拥有独占写锁。因此，更多的碎片或数据库服务器无助于提高AQL写查询的性能。我们将对3.1进行此限制，但这也不是特别容易

更多的数据库服务器和协调器将加快单个文档读写的吞吐量（不使用AQL时），如中所示。因此，通过将标准文档API与新的批处理扩展一起使用，可以更快地执行写查询

对于阅读AQL查询，如果您使用更多的服务器，如果查询可以跨碎片并行化，或者如果您测量许多此类查询的吞吐量，通常会看到加速

对于具有聚合的特定读取查询，我们缺少AQL查询优化器规则及其附带的基础设施，该基础设施可以将聚合移动到单个碎片，然后合并结果。这是计划好的，但尚未在3.0中实现，因此您在阅读查询中看不到加速。explain输出显示COLLECT及其SORT在协调器上执行，因此所有数据都必须通过单个协调器移动

至于你的第一个问题，复制在这里也没有帮助。如果您设置了同步复制，那么在3.0中，所有读写操作都将通过单个服务器进行。因此，在此阶段，更高的复制系数不会提高读取性能

一旦我们有了适当的集群范围的事务，我们将能够绕过这个限制，这也是计划中的，但还没有在3.0中实现