Шардирование в Managed Service for ClickHouse

Шардирование — это стратегия горизонтального масштабирования кластера, при которой части одной базы данных ClickHouse размещаются на разных шардах. Шард состоит из одного или нескольких хостов-реплик. Запрос на запись или чтение в шард может быть отправлен на любую его реплику, выделенного мастера нет. При вставке данных они будут скопированы с реплики, на которой был выполнен INSERT-запрос, на другие реплики шарда в асинхронном режиме.

Преимущества шардирования

Шардирование обычно используется в следующих случаях:

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

Шардирование может помочь:

• Преодолеть технические ограничения.

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

• Повысить отказоустойчивость.

  Шардирование позволяет изолировать отказы отдельных хостов или наборов реплик. Без шардирования отказ отдельного хоста или набора реплик могут привести к потере доступа ко всем данным, которые они содержат. А отказ, например, одного шарда из пяти оставляет доступными 80% данных таблицы.

• Повысить скорость выполнения запросов.

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

Использование шардирования

Чтобы распределить данные по шардам, нужно создать распределенную таблицу на движке Distributed, использующую эти шарды. Часть данных в такой таблице будет храниться на одном шарде, часть — на других шардах. Фактически, части данных хранятся в нижележащих таблицах, которые находятся на хостах каждого шарда, распределенная таблица лишь обеспечивает маршрутизацию запросов к этим таблицам.

Чтобы определить, на какой шард поместить данные при выполнении запроса INSERT, ClickHouse использует ключ шардирования — в зависимости от его значения запрос будет направлен к тому или иному шарду. Ключ шардирования схож с ключом партиционирования. Удобство в работе и фактическое улучшение производительности при использовании шардирования сильно зависят от выбора ключа шардирования: ключ должен быть выбран так, чтобы данные были логично распределены по шардам и при этом данные разных шардов не были связаны между собой. В отличие от запросов INSERT, запросы SELECT отправляют подзапросы на все шарды кластера, вне зависимости от того, каким образом данные распределены по шардам.

ClickHouse предлагает два разных подхода для работы с распределенными таблицами, обеспечивая возможность гибкого распределения данных в кластере:

• Можно создать распределенную таблицу, которая использует все шарды кластера (пример).

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

  При этом допустимо:

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

Например, можно настроить следующую конфигурацию шардов в рамках одного кластера ClickHouse, используя эти подходы:

• Группа A из двух шардов с хостами класса s2.small: используется в качестве основы для распределенной таблицы, нагрузка на которую невелика. Данные распределенной таблицы хранятся в этой же группе шардов.
• Группа B из двух шардов с хостами класса s2.medium: используется в качестве основы для распределенной таблицы, нагрузка на которую постоянна и велика. Данные распределенной таблицы хранятся в другой группе C из пяти шардов с высокопроизводительными хостами класса m2.large.

Подробнее о работе с распределенными таблицами см. в документации ClickHouse.

Особенности управления шардированием в Managed Service for ClickHouse

Managed Service for ClickHouse управляет шардами следующим образом:

• При создании кластера в него автоматически добавляется один шард shard1. Этот шард включает все хосты кластера. При создании кластера из нескольких хостов автоматически включается поддержка репликации.

• В существующий кластер можно добавить нужное количество шардов.

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

• В шард можно добавить хосты.

  Шарды из нескольких хостов требуют работающей репликации. Поэтому:

  • В кластерах, где есть шард из нескольких хостов, механизмы репликации ClickHouse Keeper или ZooKeeper уже работают, и можно сразу добавлять хосты в шард.
  • В кластерах с шардами из одного хоста нужно включить отказоустойчивость с помощью ZooKeeper, и только потом добавлять хосты в шард.

  Подробнее о репликации, ClickHouse Keeper и ZooKeeper см. в разделе Репликация.