Масштабирование баз данных — партиционирование, репликация и шардирование

СУБД очень часто становится «узким местом» в производительности веб‑приложений, влияющим на общее быстродействие и устойчивость к высоким нагрузкам. В современных высоконагруженных системах эффективное управление данными невозможно без использования методов масштабирования и обеспечения отказоустойчивости. Репликация, партиционирование и шардирование — ключевые подходы, которые позволяют распределять данные, повышать производительность и гарантировать доступность.

В этой статье разберем каждый из них подробно, если же хотите просто понять суть этих подходов без погружения в детали, то рекомендуем другую нашу статью — «Просто о сложном: что такое репликация, партиционирование и шардирование?».

Масштабирование «железа» и адекватная настройка

Первое, что стоит сделать, если скорость работы базы данных не удовлетворяет требованиям, это проверить адекватность настройки СУБД относительно имеющихся ресурсов, а также убедиться, что при проектировании БД были учтены используемые запросы. Если, например, для СУБД работает с настройками «из коробки», а при обработке запросов не используются индексы, то надо не масштабировать СУБД, достаточно просто откорректировать конфигурацию работы сервера баз данных и обновить схему используемой базы данных под профиль нагрузки. Иногда также проще увеличить выделение ресурсов под сервер баз данных — количество оперативной памяти и скорость работы дисковой подсистемы оказывают существенное воздействие на скорость работы СУБД. Нередко даже небольшое увеличение RAM и переход на SSD увеличивает производительность в разы или даже на порядок.

Масштабирование через партиционирование, репликацию и шардирование (SQL и NoSQL)

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

Описанные ниже схемы масштабирования применимы как для реляционных баз данных, тах и для NoSQL‑хранилищ. Разумеется, что у всех баз данных и хранилищ есть своя специфика, поэтому мы рассмотрим только основные направления, а в детали реализации вдаваться не будем.

Репликация (replication)

Репликация — это синхронное или асинхронное копирование данных между несколькими серверами. Ведущие серверы часто называют мастерами (master), а ведомые серверы — слэйвами (slaves), иногда используются и другие названия — лидер и фолловеры (leader & followers), праймари и реплики (primary & replicas). Один ведущий узел (мастер, лидер, праймари) принимает запросы как на запись, так и на чтение, а ведомые (реплики, слейвы или фолловеры) синхронизируются с ним и обслуживают только запросы на чтение.

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

Репликация бывает синхронной и асинхронной. При синхронной репликации как минимум один слейв должен быть на 100% актуален, а при асинхронной — допустима некоторая задержка в репликации данных от мастера к слейвам. Таким образом, при асинхронной репликации мы получаем высокую скорость работы, но при выходе из строя мастер‑сервера вероятна потеря некоторого количества данных. Синхронная же репликация предусматривает, что транзакции подтверждаются мастером только после записи на заданное количество слейвов — в итоге получается крайне высокая согласованность данных, но низкая производительность. Подробнее про этот выбор между быстродействием и согласованностью — см. PACELC‑теорема.

С практической точки зрения, создание нескольких дополнительных slave‑серверов позволяет снять с основного сервера нагрузку по запросам на чтение и повысить общую производительность системы, а также можно организовать слэйвы под конкретные ресурсоёмкие задачи и таким образом, например, упростить составление серьёзных аналитических отчётов — используемый для этих целей slave может быть нагружен на 100%, но на работу других пользователей приложения это не повлияет. Если нужна максимальная надёжность и сохранность данных при адекватной производительности, то обычно достаточно реализовать синхронную репликацию на 1-2 слэйва при большем их количестве в общем.

Партиционирование (partitioning)

Партиционирование или сегментирование — это разбиение таблиц, содержащих большое количество записей, на логические части по неким выбранным администратором критериям. Партиционирование таблиц делит весь объем операций по обработке данных на несколько независимых и параллельно выполняющихся потоков, что существенно ускоряет работу СУБД. По сути, это разделение таблицы на логические части (партиции) для ускорения запросов и управления большими объемами данных. Партиционировать таблицы можно горизонтально (на уровне строк, например, через разделение на партиции по диапазонам значений) и вертикально (на уровне столбцов, например, через вынесение редко используемых полей в отдельную таблицу). В результате будет ускорение запросов за счет работы с меньшими объемами данных и упрощения управления информацией (в частности, при архивации старых партиций или при разделении данных на «горячие» и «холодные»).

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

Шардинг (sharding)

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

Стратегии шардирования могут отличаться в зависимости от задач. Ключевой шардинг (Key-Based) — данные распределяются по шардам посредством хэш‑функции или через остаток от деления (например, user_id % N). Диапазонный шардинг (Range-Based) — шарды хранят данные из определенных диапазонов (например, пользователи A–M, N–Z). Географический шардинг — данные хранятся ближе к пользователям (шард для РФ, шард для ЕС, шард для США).

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

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

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

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

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

Стоит помнить, что репликация и шардинг (как вместе, так и по отдельности) превращают систему в распределённую, поэтому при разработке надо учитывать ограничения по теореме CAP: нельзя одновременно гарантировать согласованность данных (C — consistency), доступность (A — availability) и устойчивость к фрагментации (P — partition tolerance). В лучшем случае можно получить только два свойства из трёх перечисленных. В финтехе, например, обычный выбор — C+P, а в системах с менее значимой информацией — A+P.

С практической точки зрения, репликация бывает полезна для проектов любого масштаба, где нужна отказоустойчивость и высокая сохранность данных. Наличие реплики позволяет сохранить данные и быстро восстановить работоспособность сервиса даже при полной потере мастера. Масштабирование под нагрузку обычно тоже первоначально производится при помощи репликации БД, реже — через партиционирование. Шардинг же обычно рационально использовать только в достаточно крупных системах с очень большим количеством данных.