ArangoDB 3.0 集群 - read/write 速度的改进为零？
ArangoDB 3.0 cluster - zero improvement on read/write speeds?
我有一个 ArangoDB 3.0 集群 set-up 到 DC/OS 1.7，如下所示：
我在这个 3x co-ord、6x 服务器 set-up 上尝试了两个查询。每个节点都有以下规格：
- 15GB RAM（通过 DC/OS 为每个主数据库分配 4GB）
- 8 核
- CoreOS
我尝试了两个查询来测试 coins collection 的性能。没有添加索引。 collection 的配置是：
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 个 co-ordinator 和 1 个服务器 - 将可用 RAM 从 90GB/48 核减少到 15GB/8 核。
我希望写和读会有所不同。以下是相同查询的结果（在截断 collection 和 re-running 之后）：
写入：
阅读：
结果 - 几乎相同的执行时间。
问题：
我是否缺少某种步骤：显式复制？ （我尝试了 'rebalancing shards' - 这导致一些额外的数据库服务器被标记为追随者，但对执行速度没有影响）
我的 collection 配置是否最优？我根据文档中的 'DBPrimary squared' 推荐选择了 16 个分片（我最初的 set-up 使用了 4 台服务器，并获得了相同的性能）
我尝试的查询是否能够有效地聚类？远程循环等
是否有我可以尝试的示例查询来测试集群是否配置正确，并且应该明确证明 read/write 1x 节点与 n 节点之间的性能差异？
我想我可以解释一下这些问题（作为ArangoDB的核心开发人员之一，负责分布式模式）。以下评论考虑 ArangoDB 版本 3.0.
3.0 及之前的单个 AQL 查询仅使用单个协调器。因此，部署更多的协调器不会加快单个查询的速度，无论是写入查询还是读取查询。
这很难改变，因为 AQL 组织了一个跨集群的数据管道，很难涉及多个协调器。
如果你写查询，我们目前在 3.0 中对涉及的集合仍然有独占写锁。因此，更多分片或 DBservers 无助于扩展 AQL 写入查询的性能。我们将在 3.1 中处理此限制，但这也不是特别容易。
更多的数据库服务器和协调器将加快单个文档读写的吞吐量（当不使用 AQL 时），如 this blog post 中所示。因此，通过使用带有新批处理扩展的标准文档 API，您的写入查询可能会执行得更快。
对于读取 AQL 查询，如果您使用更多服务器，如果查询可以跨分片并行化，或者如果您测量许多此类查询的吞吐量，您通常会看到加速。
对于您使用聚合的特定阅读查询，我们缺少 AQL 查询优化器规则及其随附的基础结构，可以将聚合移动到各个分片，然后组合结果。这是计划但尚未在 3.0 中实现的，因此您在阅读查询中看不到加速。解释输出显示 COLLECT 及其 SORT 在协调器上执行，因此所有数据都必须通过单个协调器移动。
关于你的第一个问题，复制在这里也无济于事。如果设置同步复制，那么在 3.0 中，所有读写都通过每个分片的单个服务器。因此，较高的复制因子在此阶段不会提高您的读取性能。
一旦我们有适当的集群范围事务，我们将能够绕过这个限制，这也在计划中，但尚未在 3.0 中实现。
我有一个 ArangoDB 3.0 集群 set-up 到 DC/OS 1.7，如下所示：
我在这个 3x co-ord、6x 服务器 set-up 上尝试了两个查询。每个节点都有以下规格：
- 15GB RAM（通过 DC/OS 为每个主数据库分配 4GB）
- 8 核
- CoreOS
我尝试了两个查询来测试 coins collection 的性能。没有添加索引。 collection 的配置是：
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 个 co-ordinator 和 1 个服务器 - 将可用 RAM 从 90GB/48 核减少到 15GB/8 核。
我希望写和读会有所不同。以下是相同查询的结果（在截断 collection 和 re-running 之后）：
写入：
阅读：
结果 - 几乎相同的执行时间。
问题：
我是否缺少某种步骤：显式复制？ （我尝试了 'rebalancing shards' - 这导致一些额外的数据库服务器被标记为追随者，但对执行速度没有影响）
我的 collection 配置是否最优？我根据文档中的 'DBPrimary squared' 推荐选择了 16 个分片（我最初的 set-up 使用了 4 台服务器，并获得了相同的性能）
我尝试的查询是否能够有效地聚类？远程循环等
是否有我可以尝试的示例查询来测试集群是否配置正确，并且应该明确证明 read/write 1x 节点与 n 节点之间的性能差异？
我想我可以解释一下这些问题（作为ArangoDB的核心开发人员之一，负责分布式模式）。以下评论考虑 ArangoDB 版本 3.0.
3.0 及之前的单个 AQL 查询仅使用单个协调器。因此，部署更多的协调器不会加快单个查询的速度，无论是写入查询还是读取查询。
这很难改变，因为 AQL 组织了一个跨集群的数据管道，很难涉及多个协调器。
如果你写查询，我们目前在 3.0 中对涉及的集合仍然有独占写锁。因此，更多分片或 DBservers 无助于扩展 AQL 写入查询的性能。我们将在 3.1 中处理此限制，但这也不是特别容易。
更多的数据库服务器和协调器将加快单个文档读写的吞吐量（当不使用 AQL 时），如 this blog post 中所示。因此，通过使用带有新批处理扩展的标准文档 API，您的写入查询可能会执行得更快。
对于读取 AQL 查询，如果您使用更多服务器，如果查询可以跨分片并行化，或者如果您测量许多此类查询的吞吐量，您通常会看到加速。
对于您使用聚合的特定阅读查询，我们缺少 AQL 查询优化器规则及其随附的基础结构，可以将聚合移动到各个分片，然后组合结果。这是计划但尚未在 3.0 中实现的，因此您在阅读查询中看不到加速。解释输出显示 COLLECT 及其 SORT 在协调器上执行，因此所有数据都必须通过单个协调器移动。
关于你的第一个问题，复制在这里也无济于事。如果设置同步复制，那么在 3.0 中，所有读写都通过每个分片的单个服务器。因此，较高的复制因子在此阶段不会提高您的读取性能。
一旦我们有适当的集群范围事务，我们将能够绕过这个限制，这也在计划中，但尚未在 3.0 中实现。