Технология шардинга в базах данных

Шардинг (также известный как разделение данных) – это процесс разделения большого набора данных на множество небольших разделов, которые размещаются на разных машинах. Каждый раздел известен как «шард».

Каждый шард имеет ту же схему базы данных, что и исходная база данных. Большая часть данных распределяется таким образом, что каждая строка отображается ровно в одном фрагменте. Объединенные данные из всех сегментов совпадают с данными из исходной базы данных.

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

Какие проблемы масштабируемости решаются с помощью шардинга

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

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

Каждый шард может быть расположен на одной и той же машине (coresident) или на разных машинах (remote) [1].

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

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

Распространенные схемы разбиения или разделения данных

Существует три распространенных стратегии шардинга [2]:

• 1.    Горизонтальный или дальномерный шардинг

• 2.    Вертикальный шардинг

• 3.    Ключ, основанный на хэшировании

В этом случае данные разделяются на основе диапазонов значений, присущих каждому объекту. Например, если вы сохраняете контактную информацию для своих онлайн-клиентов, вы можете сохранить эту информацию для клиентов, чья фамилия начинается с А-М на одном сегменте, а остальные – на другом.

Недостатком этой схемы является то, что фамилии клиентов могут быть распределены неравномерно. У вас может быть намного больше клиентов, чьи имена попадают в диапазон А-М, чем клиентов, чьи фамилии попадают в диапазон Н-Я. В этом случае ваш первый шард будет испытывать гораздо большую нагрузку, чем второй шард, и может стать «опасным» местом системы.

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

Это хорошо работает для относительных нестатических данных – например, для хранения контактной информации о студентах в колледже.

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

В этом случае у объекта есть значение (например, IP-адрес клиентского приложения), которое можно использовать в качестве входных данных для хэш-функции и генерировать полученное в результате хэш-значение. Это хэш-значение определяет, какой сервер базы данных (шард) использовать [3].

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

Проблемы шардинга

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

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

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

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