кластер кликхауса в котором в рамках шарда стоит партицирование по месяцам.
При этом в одной таблице данные поделены неким признаком (условно клиент) и обращение всегда идет с указанием поля. Кардинальность поля около 100 значений
Ключ сортировки + primary key уже максимально оптимизирован под то чтобы читать как можно меньше за раз и ускорить запросы
Но всё равно в некоторых запросах мы видим что такие большие коммунальные партиции влияют на клиентов с маленьким объемом строк
И подумали, а что если добавить ID клиента в ключ партицирования, чтобы разделить прям файлами данные клиентов
Из плюсов видится что мы сможем гибко управлять данными в рамках клиента (переносить партиции, удалять по TTL) + клиенты не будут упираться в общий размер данных
Из минусов - вставки станут дороже, + 100 партиций в месяц на один хост, насколько помню кликхаусу может стать плохо в какой то момент.
Стоит вообще пытаться в такое? Или сразу готовиться и заводить кластера тяжелым клиентам? Мб что-то еще упустил?
лучше поделить огромный кластер на несколько маленьких (2 level sharding), и хранить меньше клиентов внутри каждого кластера, это ускорит запросы потому что надо меньше ждать нод при дистрибьютид запросах. Вы все равно сможете кверять данные по всем клиентам/всем кластерам и такие запросы немного замедлятся, и то не факт.
имеется в виду поделить кластер на группы шардов, верно?
Обсуждают сегодня