我通过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节点之间的读/写性能差异？
1条答案
按热度按时间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中还没有实现。