Учитывая, что набор данных, который можно масштабировать до как 100GB & 1Гб и выполнение тех же запросов на обоих наборов данных, мы можем сказать, что -
Sharding 100GB через 5 Осколки 20GB каждый эквивалентен шардинге 1 Гб через 5 Осколков 200MB каждую
с точкой зрения высокого уровня, то sharded cluster architecture может быть похожи на оба ваши примеры: 5 Осколков, 3 конфигурации серверов, а также некоторое количество mongos процессов. Я бы с сомнением назвал это «эквивалентом» таким же образом, что мопед не эквивалентен мотоциклу, хотя оба эти двухколесных транспортных средства в этой аналогии, поэтому интерпретация зависит от вашей точки зрения.
Однако, конечно, можно начать с 5 кластеров с чередованием, снабженных ресурсами (ОЗУ/ЦП/хранилище), чтобы соответствовать определенной ожидаемой рабочей нагрузке, а затем обновить (или понизить) тот же кластер с ресурсами, чтобы соответствовать изменяющимся требованиям для вашего использование случай.
Будет ли масштабный эффект влиять на то, как осколки выполняются Монго? Если да, где будут наблюдаться изменения?
Основная разница в поведении, основанная на объёме оштукатуренных данных, будет представлять собой активность sharded cluster balancing. Балансировка основана на кусках, которые являются логическими смежными диапазонами значений ключа осколка, которые по умолчанию составляют примерно 64 МБ данных.
Балансировка куски между осколками запускается с использованием migration threshold на основе разницы между осколками с наименьшим и большинство кусков, а также общего количества кусков в sharded коллекции:
| Number of Chunks | Migration Threshold |
|====================|=====================|
| Fewer than 20 | 2 |
| 20-79 | 4 |
| 80 and greater | 8 |
только с 100MB данных на каждый осколок, что будет примерно 2 куска (или ~ 10 в целом).
При наличии 20 Гбайт данных на каждый осколок было бы не менее 312 кусков на каждый осколок (скорее всего, так как куски упреждающе расщепляются, а не всегда заполняются).
Если вы выберете хороший ключ осколка, который эффективно распределяет данные по осколкам, часто требуется повторная балансировка. С другой стороны, у плохого ключа осколка потребуется более частая балансировка, и проблемы будут гораздо более очевидными в масштабе из-за дополнительных затрат ввода-вывода.