Шардирование базы данных — это процесс её разделения на несколько машин, что способствует масштабируемости приложения. Механизм шардирования предполагает разбиение данных на два или более мелких фрагмента, называемых логическими шардами. Затем логические блоки распределяются по отдельным узлам базы данных, называемым физическими блоками, каждый из которых может содержать несколько логических блоков.
Такой подход позволяет избежать проблем с производительностью, возникающих, когда одна из машин работает в условиях перегрузки, и обеспечивает более экономичное и грамотное масштабирование. По мере увеличения объема данных и трафика все чаще возникает необходимость горизонтального масштабирования путем добавления новых машин, а не вертикального путем модернизации одного большого сервера.
На этом этапе перед компанией встал важный вопрос: что делать — вертикально масштабировать платформу, инвестируя в более мощный и дорогой сервер с увеличенной оперативной памятью, более мощным процессором, дисковым вводом-выводом и емкостью хранилища, или горизонтально масштабировать платформу, распределяя данные по нескольким более доступным серверам. Оба варианта имеют свои плюсы и минусы, и решение в конечном итоге сводится к тому, какой подход будет наиболее экономичным и эффективным с точки зрения масштабирования платформы для удовлетворения растущих потребностей ее пользователей. В такой ситуации разделение базы данных на части может стать высокорентабельным и масштабируемым решением, а компромиссным вариантом является усложнение системы.
Архитектуры для шардирования
После того как принято решение о разделении базы данных, следующий шаг — выяснить, как это сделать. Это включает в себя понимание различных типов шардирования и того, как эти решения используются для распределения данных. В этом разделе мы рассмотрим некоторые из наиболее часто используемых типов шардирования и применяемые в них методы распределения данных.
1 — Вертикальное сегментирование
Один из простых способов сегментировать базу данных вашего приложения — вынести таблицы, связанные с определенными функциями, на собственные серверы. Например, вы можете разместить информацию о профиле пользователя на одном сервере, списки друзей — на другом, а третий — для пользовательского контента, например фотографий.
Такой подход относительно прост в реализации и оказывает минимальное влияние на работу приложения в целом. Однако если сайт будет продолжать расти, может потребоваться дальнейшее разделение баз данных по отдельным функциям на несколько серверов.
2 — Сегментирование на основе диапазонов
Сегментирование на основе диапазонов — это техника, которая предполагает разделение данных на основе диапазонов определенных значений. Например, рассмотрим базу данных каталога розничной компании, в которой хранится информация обо всех товарах. Один из способов разделения этих данных — создать несколько разделов и разделить информацию о товарах в зависимости от их ценового диапазона.
Такой подход позволяет более организованно и эффективно распределять данные, упрощая управление и запросы к базе данных. Однако главная проблема такого подхода заключается в том, что если значение, используемое для разделения, выбрано не очень тщательно, это может привести к неравномерному распределению данных по серверам. Например, если определенный ценовой диапазон содержит большее количество товаров, это может привести к перегрузке одного осколка, в то время как другие будут недоиспользованы.
3 — Сегментирование на основе ключей
Шардирование на основе ключей, также именуемое шардированием на основе хэшей. Оно работает на основе использования уникального значения, например идентификатора пользователя, в качестве входных данных для хэш-функции. Затем хэш-функция вычисляет выходное значение, которое используется для определения сервера, на котором должны храниться данные. Одним из примеров является использование идентификатора пользователя в качестве входного значения и использование операции модуляции идентификатора пользователя с количеством доступных серверов для определения того, на каком сервере хранить информацию пользователя.
Этот подход направлен на обеспечение равномерного распределения данных по серверам. Однако одна из главных проблем этого метода заключается в том, что он ограничивает гибкость при добавлении новых серверов в систему, поскольку для этого потребуется изменить хэш-функцию, а это может быть сложно сделать без простоев.
4 — Сегментирование на основе каталогов
Сегментирование на основе каталогов предполагает наличие таблицы поиска, в которой используется ключ шарда для отслеживания того, в каком шарде хранятся те или иные данные. Этот ключ обычно представляет собой уникальный идентификатор для каждого фрагмента данных, например идентификатор пользователя или идентификатор продукта. Таблица поиска используется для определения того, к какому хранилищу относится конкретный фрагмент данных, что позволяет системе эффективно извлекать и обновлять данные по мере необходимости.
Такой подход позволяет более гибко добавлять или удалять серверы, а также изменять схему сегментирования, не влияя на работу остальной части приложения. Например, если в настоящее время имеется десять серверов, а хэш-функция представляет собой операцию по модулю, добавление еще пяти серверов в пул может быть выполнено без простоев. Можно запустить сценарий для копирования данных с первоначальных десяти серверов на новые пять серверов на основе новой хэш-функции, используя новое количество серверов, равное пятнадцати. После копирования данных таблица поиска может перейти на использование новой хэш-функции.
Преимущества шардирования
1 — Высокая доступность
Если один контейнер выходит из строя, остальные продолжают работать. Разделение базы данных на шарды повышает доступность приложения. В случае сбоя в одном из шардов только определенная часть приложения станет недоступной для пользователей. Однако другие шарды могут продолжать работать без перебоев. С другой стороны, если база данных не разделена на части, то в случае сбоя может стать недоступным все приложение.
2 — Ускоренные запросы
Шардирование базы данных улучшает время отклика на запрос за счет разделения данных на более мелкие группы. Когда запрос отправляется в базу данных без шардирования, может потребоваться просмотреть каждую строку в таблице, прежде чем он найдет нужный набор результатов. В отличие от этого, при использовании разделенной базы данных запрос должен пройти только по меньшему количеству строк, что приводит к ускорению времени ответа на запрос.
3 — Параллельная запись
Распределяя операции записи между несколькими шардами, система может обрабатывать больше одновременных записей, что приводит к повышению эффективности и надежности базы данных.
4 — Больше работы
Шардирование обеспечивает горизонтальное масштабирование, которое также известно как масштабирование наружу. Благодаря параллельному бэкенду система может выполнять больше работы одновременно, что позволяет ей справляться с высокой пользовательской нагрузкой. Параллельные пути через систему также позволяют быстрее выполнять операции записи, поскольку данные распределяются по нескольким шардам. Веб-серверы с балансировкой нагрузки также могут использоваться для доступа к шардам по разным сетевым маршрутам, которые обрабатываются отдельными процессорами и используют отдельные кэши оперативной памяти и пути дискового ввода-вывода. Это уменьшает количество проблемных мест и повышает общую производительность и надежность системы.
Недостатки
1 — Объединения
Шардинг базы данных может создать проблемы при выполнении объединений для нескольких таблиц. До перехода к шардированию такие запросы выполнялись на одном сервере, но после распределения базы данных по нескольким серверам выполнение объединений, охватывающих все шарды базы данных, становится более сложным и трудным. Это связано с тем, что данные приходится компилировать с нескольких серверов, что может привести к значительным накладным расходам и негативно сказаться на производительности.
Однако есть способы смягчить эту проблему. Использование кэширования и быстрых сетей может помочь ускорить процесс и обеспечить быстрое время загрузки страниц. Кроме того, денормализация базы данных путем объединения связанных данных в одну таблицу также может стать эффективным решением, поскольку позволяет выполнять ранее сложные запросы на объединение данных в одной таблице.
2 — Ссылочная целостность
Поддержание целостности данных, например, использование внешних ключей, может оказаться сложной задачей при использовании базы данных с чередованием. Большинство реляционных систем управления базами данных не поддерживают внешние ключи на разных серверах, что затрудняет обеспечение ссылочной целостности. Это означает, что приложениям, которые полагаются на эту функцию, придется реализовать ее в коде и регулярно выполнять задания SQL, чтобы обеспечить согласованность данных. Это может создать дополнительную сложность и усложнить обслуживание приложения.
3 — Сбалансированность данных
При использовании шардированной базы данных важно следить за распределением данных по шардам, поскольку один шард может стать больше других, что называется «горячей точкой». Это может свести на нет все преимущества шардирования и вызвать проблемы с производительностью. Чтобы предотвратить это, может потребоваться повторное шардирование базы данных, чтобы обеспечить равномерное распределение данных по всем шардам. Лучше всего запланировать такую возможность с самого начала, так как при неправильном выполнении перешардирование (решардинг) может привести к простоям.
4 — Ограниченная поддержка баз данных
Не все движки баз данных обеспечивают встроенную поддержку шардирование, а это значит, что такую поддержку может потребоваться реализовать отдельно. При этом могут возникнуть проблемы с поиском документации и решений по устранению неполадок.
