ArangoDB 3.0集群 - 读/写速度的改进是零?
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了ArangoDB 3.0集群 - 读/写速度的改进是零?相关的知识,希望对你有一定的参考价值。
我通过DC / OS 1.7设置了ArangoDB 3.0集群,如下所示:
我在这个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
结果:
执行计划:
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
然后我缩小到1x协调器和1x服务器 - 从90GB / 48核心减少可用内存,降至15GB / 8核心。
我希望写和读显示出一些区别。以下是相同查询的结果(在截断集合并重新运行之后):
写:
读:
结果 - 执行时间几乎相同。
问题:
- 我错过了某种步骤:显式复制? (我尝试'重新平衡分片' - 这导致一些额外的数据库服务器被标记为粉丝,但对执行速度没有影响)
- 我的收藏品配置是否最佳?我根据文档中的“DBPrimary平方”建议选择了16个分片(我的原始设置使用了4x服务器,并且看到了相同的性能)
- 我尝试过的查询是否能够有效地进行聚类?远程循环等
- 是否有我可以尝试的示例查询来测试集群是否配置正确,并且应该明确证明1x节点与n个节点之间的读/写性能差异?
我想我可以对这些问题有所了解(作为ArangoDB的核心开发人员之一,负责分布式模式)。以下注释考虑了ArangoDB版本3.0。
3.0及之前的单个AQL查询仅使用单个协调器。因此,部署更多协调器不会加速单个查询,无论是写入还是读取查询。
这很难改变,因为AQL在整个集群中组织数据管道,并且很难涉及多个协调器。
如果您正在编写查询,我们目前仍然对3.0中涉及的集合进行独占写锁定。因此,更多分片或DBservers无助于扩展AQL写入查询的性能。我们将对3.1的这个限制进行研究,但这也不是特别容易。
更多的DBservers和协调器将加速单个文档读写的吞吐量(当不使用AQL时),如this blog post中所示。因此,通过将标准文档API与新的批处理扩展一起使用,可以更快地执行写入查询。
对于读取AQL查询,如果您使用更多服务器,如果查询可以跨分片并行化,或者您测量许多此类查询的吞吐量,您通常会看到加速。
对于使用聚合的特定读取查询,我们缺少AQL查询优化器规则及其附带的基础结构,可以将聚合移动到各个分片,然后组合结果。这是有计划的,但尚未在3.0中实现,因此您在阅读查询中看不到加速。 explain输出显示带有SORT的COLLECT在协调器上执行,因此所有数据都必须通过单个协调器移动。
至于你的第一个问题,复制也无济于事。如果设置同步复制,则在3.0中,对每个分片,所有读取和写入都通过单个服务器进行。因此,在此阶段更高的复制因子不会提高您的读取性能。
一旦我们有适当的集群范围的交易,我们将能够解决这个限制,这也是计划但未登陆3.0。
以上是关于ArangoDB 3.0集群 - 读/写速度的改进是零?的主要内容,如果未能解决你的问题,请参考以下文章