1

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

通过 DC/OS 1.7 的 ArangoDB 3.0 集群

我在这个 3x co-ord、6x 服务器设置上尝试了两个查询。每个节点都有以下规格:

  • 15GB RAM(通过 DC/OS 为每个 DB Primary 分配 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

结果:

在 13.894 秒内执行

执行计划:

 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

读:

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

结果:

在 1.157 秒内执行

执行计划:

 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 个内核。

我希望写入和读取会显示出一些差异。以下是相同查询的结果(截断集合并重新运行后):

写:

在 13.763 秒内执行

读:

在 1.127 秒内执行

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

问题:

  • 我是否错过了某种步骤:显式复制?(我尝试了“重新平衡分片”——这导致一些额外的数据库服务器被标记为追随者,但对执行速度没有影响)

  • 我的收藏配置是最优的吗?我根据文档中的“DBPrimary squared”建议选择了 16 个分片(我最初的设置使用了 4 个服务器,并且看到了相同的性能)

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

  • 是否有我可以尝试的示例查询来测试集群是否配置正确,并且应该明确证明 1x 节点与 n 节点之间的读/写性能差异?

4

1 回答 1

1

我想我可以对这些问题有所了解(作为 ArangoDB 的核心开发人员之一,负责分布式模式)。以下评论考虑了 ArangoDB 3.0 版。

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

这很难改变,因为 AQL 跨集群组织数据管道,并且很难涉及多个协调器。

如果您确实编写查询,我们目前在 3.0 中仍然对所涉及的集合具有排他写锁。因此,更多的分片或 DBserver 无助于扩大 AQL 写入查询的性能。我们将为 3.1 解决这个限制,但这也不是特别容易。

更多 DBserver 和协调器将加快单个文档读取和写入的吞吐量(不使用 AQL 时),如本博文所示。因此,通过使用带有新批处理扩展的标准文档 API,您的写入查询可能会执行得更快。

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

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

至于您的第一个问题,复制在这里也无济于事。如果您设置了同步复制,那么在 3.0 中,每个分片的所有读取和写入都通过单个服务器。因此,较高的复制因子在此阶段不会提高您的读取性能。

一旦我们有适当的集群范围的事务,我们将能够绕过这个限制,这也是计划的,但还没有登陆 3.0。

于 2016-06-29T13:11:54.643 回答