【问题标题】:ArangoDB 3.0 cluster - zero improvement on read/write speeds?ArangoDB 3.0 集群 - 读/写速度零提升?
【发布时间】:2016-06-28 13:14:17
【问题描述】:

我有一个通过 DC/OS 1.7 设置的 ArangoDB 3.0 集群,如下所示:

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

  • 15GB RAM(通过 DC/OS 为每个主数据库分配 4GB)
  • 8 核
  • CoreOS

我尝试了两个查询来测试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

结果:

执行计划:

 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}

结果:

执行计划:

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

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

写:

阅读:

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

问题:

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

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

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

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

【问题讨论】:

    标签: performance cluster-computing mesos arangodb dcos


    【解决方案1】:

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

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

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

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

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

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

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

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

    一旦我们有适当的集群范围的交易,我们将能够绕过这个限制,这也是计划中的,但尚未登陆 3.0。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2020-07-21
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-10-23
      • 1970-01-01
      相关资源
      最近更新 更多