ТЕХНОЛОГИЯ ШАРДИНГА В БАЗАХ ДАННЫХ Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 004.85

Макаров Д.А. студент

факультет «Информатика и системы управления» Московский государственный технический университет имени Н.Э. Баумана Россия, г. Москва ТЕХНОЛОГИЯ ШАРДИНГА В БАЗАХ ДАННЫХ

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

Ключевые слова: sharding, разделение данных, шард, масштабируемость, сервер, база данных, горизонтальный шардинг, вертикальный шардинг, хэширование

Makarov D.A. student

Faculty of Informatics and Management Systems Moscow State Technical University named after N.E.

Bauman Russia, Moscow SHARDING TECHNOLOGY IN DATABASES

Abstract: this article discusses a widely applicable method of data separation - sharding. The spectrum of problems that are solved using this technology is determined. The most common data partitioning schemes are considered. At the end of the article some problems that can be encountered when using sharding are given.

Keywords: sharding, data splitting, shard, scalability, server, database, horizontal sharding, vertical sharding, hashing

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

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

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

данных.

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

шардинга

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Использованные источники:

1. Шардинг и репликация. [Электронный ресурс]. Режим доступа: https://ruhighload.com/шардинг+и+репликация (дата обращения 19.01.2020).

2. Ульман, Дж. Основы систем баз данных. - М.: Финансы и статистика, 2017. - 292 c.

3. Архипенков С., Голубев Д., Максименко О. Хранилища данных. От концепции до внедрения. - М.: Диалог-Мифи, 2002. - 528 c.