Поддерживает ли Galera (или MSSQL) эту схему кластеризации?

Кластерные базы данных можно относительно легко масштабировать.
Однако даже при условии нулевой задержки для запуска нового экземпляра существует значительная задержка до того, как новый добавленный узел будет готов обслуживать запросы.
Во время этой задержки новый экземпляр синхронизируется с кластером, потенциально передавая по сети тысячи ГиБ.
Например, Percona заявляет, что SST Galera работают со скоростью около 100 ГБ / час по сети 1 ГБ.

У меня бывают непродолжительные (2-3 часа) сильные всплески запросов (в 40-100 раз больше обычного) в моем большом наборе данных.
В этом случае автомасштабирование теряет свою эффективность.

Один из способов преодолеть это - разделить таблицы (в конечном итоге небольшие таблицы будут использовать один раздел) и распределить каждый раздел (или набор разделов) по разным наборам узлов (назовите этот набор шардов).

Затем автоматическое масштабирование будет настроено для отслеживания отдельных сегментов и их масштабирования путем добавления к ним дополнительных узлов.
В конце концов, можно использовать глобальный монитор, чтобы проверить, будет ли полезен новый сегмент (т. Е. Если все сегменты одновременно превышают пороговое значение).

Это похоже на архитектуру MongoDB, хотя я не знаю, действительно ли MongoDB работает таким образом.
Это позволит избежать необходимости передавать весь набор данных при добавлении нового узла в кластер, нужно скопировать только раздел шарда (уменьшение задержки).

Также было бы неплохо, если бы внутри каждого шарда любой узел мог бы обрабатывать запросы на запись (в отличие от того, как работают шарды MongoDB, если я прав), эффективно превращая каждый шард в отдельный кластер.
Но поскольку меня интересует СУБД SQL, мне нужна возможность выполнять соединение с участием данных в разных шардах. То, что не сможет сделать набор независимых кластеров.

Поддерживает ли это Galera (или MSSQL, как альтернатива)?