Шардирование в 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®

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

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

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

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

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

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

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

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

• Идентификаторы шардов в Yandex Cloud отличаются от их идентификаторов в ClickHouse®:

  • В кластере Managed Service for ClickHouse® используются имена шардов.
  • В ClickHouse® используются числовые идентификаторы, которые соответствуют лексикографическому порядку имен шардов в Managed Service for ClickHouse® (например, A-shard, B-shard, shard10, shard100).

  Учитывайте это, если ваше приложение обращается к шардам по их идентификаторам при записи и чтении данных распределенной таблицы.

  Чтобы узнать, как идентификаторы Yandex Cloud и ClickHouse® соответствуют друг другу, используйте запрос:

  SELECT
   substitution AS shard_name,
   shardNum() AS shard_number
  FROM cluster('{cluster}', system.macros)
  WHERE macro = 'shard'
  ORDER BY shard_name
  

  Например, в кластере с шардами shard1, shard2, shard3, shard4, shard100 соответствие будет выглядеть так:

  ┌─shard_name─┬─shard_number─┐
  │ shard1     │            1 │
  └────────────┴──────────────┘
  ┌─shard_name─┬─shard_number─┐
  │ shard100   │            2 │
  └────────────┴──────────────┘
  ┌─shard_name─┬─shard_number─┐
  │ shard2     │            3 │
  └────────────┴──────────────┘
  ┌─shard_name─┬─shard_number─┐
  │ shard3     │            4 │
  └────────────┴──────────────┘
  ┌─shard_name─┬─shard_number─┐
  │ shard4     │            5 │
  └────────────┴──────────────┘
  

ClickHouse® является зарегистрированным товарным знаком ClickHouse, Inc.