У меня есть кластер ArangoDB 3.0, настроенный через DC/OS 1.7, как показано здесь:
Я попробовал два запроса на этой настройке сервера 3x co-ord, 6x. Каждый узел имеет следующие характеристики:
- 15 ГБ ОЗУ (4 ГБ назначается на основную базу данных через DC/OS)
- 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 сервера, уменьшив доступную оперативную память с 90 ГБ / 48 ядер до 15 ГБ / 8 ядер.
Я ожидал, что запись и чтение покажут некоторую разницу. Вот результаты тех же запросов (после усечения коллекции и повторного запуска):
Написать:
Читать:
Результат – почти одинаковое время выполнения.
Вопросы:
Я пропустил какой-то шаг: явная репликация? (Я попытался «перебалансировать осколки», что привело к тому, что некоторые дополнительные серверы БД были помечены как последователи, но не повлияло на скорость выполнения)
Является ли конфигурация моей коллекции оптимальной? Я выбрал 16 осколков, основываясь на рекомендации «DBPrimary Squared» в документации (в моей исходной настройке использовались 4-кратные серверы и наблюдалась эквивалентная производительность).
Могут ли запросы, которые я пробовал, эффективно кластеризоваться? Диапазонные петли и т. д.
Есть ли образцы запросов, которые я могу попробовать, чтобы проверить, правильно ли настроен кластер, и должны ли они окончательно доказать разницу в производительности чтения/записи между узлами 1x и узлами n?
