ArangoDB 3.0集群 - 读/写速度改善为零?

时间:2016-06-28 13:14:17

标签: performance cluster-computing mesos arangodb dcos

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

ArangoDB 3.0 cluster via DC/OS 1.7

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

  • 15GB RAM(每个DB通过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

结果:

Executed in 13.894 seconds

执行计划:

 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}

结果:

Executed in 1.157 seconds

执行计划:

 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

然后我缩小到只有1x协调员和1x服务器 - 从90GB / 48核心减少可用内存,减少到15GB / 8核心。

我希望写和读显示出一些区别。以下是相同查询的结果(在截断集合并重新运行之后):

写:

Executed in 13.763 seconds

读:

Executed in 1.127 seconds

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

问题:

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

  • 我的收藏品配置是否最佳?我根据“DBPrimary平方”选择了16个分片。在docs中推荐(我的原始设置使用了4x服务器,并且看到了相同的性能)

  • 我尝试的查询是否能够有效地进行聚类?远程循环等

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

1 个答案:

答案 0 :(得分:1)

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

3.0及以前的单个AQL查询仅使用一个协调器。因此,部署更多协调器不会加速单个查询,无论是写入还是阅读查询。

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

如果您正在编写查询,我们目前仍然对3.0中涉及的集合进行独占写锁定。因此,更多分片或DBservers无助于扩展AQL写入查询的性能。我们将对3.1的这个限制进行研究,但这也不是特别容易。

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

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

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

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

一旦我们进行了适当的群集范围的交易,我们将能够绕过这个限制,这也是有计划的,但还没有落在3.0中。