Arangodb3.0集群-读/写速度零改进?

des4xlb0  于 2021-06-26  发布在  Mesos
关注(0)|答案(1)|浏览(486)

我通过dc/os 1.7建立了arangodb 3.0集群,如下所示:

我尝试了两个关于3x co ord,6x服务器设置的查询。每个节点都有以下规格:
15gb ram(通过dc/os为每个db主设备分配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

结果:

执行计划:

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核。
我希望写作和阅读能有所不同。以下是相同查询的结果(在截断集合并重新运行之后):
写:

阅读:

结果-几乎相同的执行时间。
问题:
我是否错过了某些步骤:显式复制(我尝试了‘重新平衡碎片’——这导致一些额外的db服务器被标记为追随者,但对执行速度没有影响)
我的收藏配置是否最佳?基于docs中的“dbprimary squared”建议,我选择了16个shard(我最初的设置使用了4个服务器,性能相当)
我尝试的查询是否能够有效地进行聚类?远程循环等。
我是否可以尝试一些示例查询来测试集群是否正确配置,并最终证明1x节点与n节点之间的读/写性能差异?

4bbkushb

4bbkushb1#

我想我可以解释一下这些问题(作为arangodb的核心开发人员之一,负责分布式模式)。以下注解考虑arangodb 3.0版。
3.0及以前版本中的单个aql查询只使用一个协调器。因此,部署更多的协调器并不能加快单个查询的速度,无论是写查询还是读查询。
这是很难改变的,因为aql组织了一个跨集群的数据管道,并且很难涉及到多个协调器。
如果您编写查询,我们目前仍对3.0中涉及的集合拥有独占写锁。因此,更多的shard或dbserver无助于提高aql写查询的性能。我们将在3.1中研究这个限制,但这也不是特别容易。
更多的数据库服务器和协调器将加快单个文档读写的吞吐量(当不使用aql时),如本文所示。因此,通过使用带有新批处理扩展的标准文档api,可以更快地执行写查询。
对于阅读aql查询,如果您使用更多的服务器,如果查询可以在shard之间并行化,或者如果您测量许多这样的查询的吞吐量,通常会看到一个加速。
对于具有聚合的特定读取查询,我们缺少一个aql查询优化器规则及其附带的基础结构,该基础结构可以将聚合移动到各个碎片,然后合并结果。这是计划好的,但还没有在3.0中实现,因此您在阅读查询中看不到加速。explain输出显示collect及其sort在协调器上执行,因此所有数据都必须通过单个协调器移动。
至于你的第一个问题,复制在这里也没有帮助。如果您设置了同步复制,那么在3.0中,所有读写操作都将通过单个服务器进行。因此,在这个阶段,较高的复制因子不会提高读取性能。
一旦我们有了适当的集群范围的事务,我们就能够绕过这个限制,这也是计划中的,但在3.0中还没有实现。

相关问题