ここに示すように、DC/OS 1.7 を使用して ArangoDB 3.0 クラスターをセットアップしています。
この 3x co-ord、6x サーバーのセットアップで 2 つのクエリを試しました。各ノードには次の仕様があります。
- 15 GB RAM (DC/OS を介して DB プライマリごとに 4 GB を割り当て)
- 8コア
- CoreOS
coinsコレクションに対するパフォーマンスをテストするために、2 つのクエリを試しました。インデックスは追加されませんでした。コレクションの構成は次のとおりです。
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 コアに減らしました。
書き込みと読み取りが何らかの違いを示すことを期待していました。同じクエリの結果を次に示します (コレクションを切り捨てて再実行した後)。
書く：
読んだ：
結果 - ほぼ同じ実行時間。
質問:
ある種のステップ re: 明示的複製が欠落していますか? (「シャードの再調整」を試みました - これにより、追加の DB サーバーの一部がフォロワーとしてラベル付けされましたが、実行速度に違いはありませんでした)
コレクションの構成は最適ですか? ドキュメントの「DBPrimary squared」の推奨事項に基づいて、16 個のシャードを選択しました (元のセットアップでは 4x サーバーを使用し、同等のパフォーマンスが得られました)。
試したクエリは効果的にクラスター化できますか? 遠距離ループなど
クラスターが正しく構成されているかどうかをテストし、1x ノードと n ノードの読み取り/書き込みパフォーマンスの違いを明確に証明するサンプル クエリはありますか?