Привет! Дано: три ноды, на них два кластера - три реплики

и три шарда, типа такого:


<remote_servers replace="replace">
<cluster_shard>
<shard>
<replica>
<host>node1</host>
</replica>
</shard>
<shard>
<replica>
<host>node2</host>
</replica>
</shard>
<shard>
<replica>
<host>node3</host>
</replica>
</shard>
</cluster_shard>
<cluster_replica>
<shard>
<replica>
<host>node1</host>
</replica>
<replica>
<host>node2</host>
</replica>
<replica>
<host>node3</host>
</replica>
</shard>
</cluster_replica>
</remote_servers>

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

проблема: вместе с количеством пользователей и количеством селектов от них растёт нагрузка, упираемся в пропускную способность дисков - в пиках disk usage на плато 100%, очереди дисков до 60. диски уже самые модные из доступных в облаке ssd, выглядит как нужно скейлиться количеством нод.

навскидку можно
⁃ или мигрировать в совсем новый кластер из скажем 9 нод, по пути равномерно решардируем данные
⁃ или расширить существующий, но не очень понятно как правильно уравновесить данные по нодам

вопрос: имеет ли смысл сделать репликацию шардов? это вдвое увеличит бюджет, очевидно повысит надёжность, но будет ли прирост по пропускной способности, удвоит ли это пропускную способность кластера для селектов? или есть ещё какие хорошие практики для масштабирования?

спасибо!

Имеет. Удвоит. Половина запросов на одной реплике будет выполняться половина на второй. Можно ещё пооптимизировать запросы, добавить памяти. Сколько памяти?

ясно, спасибо. памяти в пиках вроде пока хватает, да и в облаке легко накинуть. оптимизация запросов это скорее вопрос обучения ~40 человек, авось постепенно научатся =)

а когда ещё вырастем через год, как посоветуете масштабироваться дальше? хотим заложиться на будущее, есть ли что-то что нужно учесть сейчас кроме примерной прикидки capacity?

Ну вы сами говорите что диск нагружен в полку, это значит что в кеш память не помещается горячие данные, увеличение ОЗУ самый дешёвый способ это решить.

попробуем, спасибо! swap отключен если что, но очевидно Клик сам пишет на диск свой кэш?

Лучше всего сначала подумать. Банальные ошибки приводят к фулсканам всех пвртиций например. Или например если с умом подойти и построить проджекшины, можно ускорится раз в 100

Кх использует файловый кеш операционной системы.

Добрый день. Подскажите, есть ли какой-то источник где можно подробнее прочитать/посмотреть про построение проджекшинов?

Видео Амоса смотрели? Мне кажется там все очевидно. Или вот мой пример https://kb.altinity.com/altinity-kb-queries-and-syntax/projections-examples/

нет, видео не видел, изучу, спасибо!