Разделить таблицу на части и распределить записи между серверами — разные решения. Объясняем связь терминов, ключ распределения и ограничения на примере архива.
Два вопроса вместо одного
В большом архиве можно завести отдельные папки по месяцам, оставив их в одном помещении. А можно распределить архив между несколькими помещениями и договориться, куда идти за нужным документом. Обе ситуации предполагают деление, но меняют устройство работы по-разному. В системах данных похожая разница встречается между партиционированием таблицы и шардингом.
При обсуждении полезно сразу разделить два вопроса: как организованы части данных и где они обслуживаются. В этой статье партиционированием таблицы будем называть её разделение на управляемые части, а шардингом — распределение разных частей набора между узлами. Так проще сравнить решения, не смешивая их с выбором мощности оборудования.
Части одной логической таблицы
В документации PostgreSQL партиционирование описано как разделение одной логической таблицы на меньшие физические части. Например, записи могут попадать в разные части по диапазонам дат. Для пользователя это по-прежнему может быть одна таблица, хотя её части хранятся и обслуживаются отдельно.
Само появление таких частей не означает, что появились дополнительные серверы. Поэтому фраза «мы уже разделили таблицу» ещё не отвечает на вопрос о распределении нагрузки между машинами. В нашем условном архиве папки за январь и февраль вполне могут оставаться в одном помещении. Это полезная организация, но помещение от этого не превращается в два независимых пункта обслуживания.
Что добавляет шардинг
При шардинге разные записи распределяют между отдельными узлами или группами узлов. Каждый шард обслуживает свою часть. В MongoDB размещение документов определяется ключом шардинга — выбранным полем или сочетанием полей. Этот ключ помогает системе понять, где искать нужные сведения.
Представим условный сервис с клиентами из нескольких регионов. Одни клиентские записи обслуживает первая группа, другие — вторая. Здесь важно не только хранение, но и направление обращения: запрос должен попасть к нужным участникам. Шард при этом не обязательно равен одному компьютеру. В конкретной системе он может иметь собственные копии для поддержания доступности.
Почему в документации встречаются разные названия
Слово «партиционирование» используют и в более широком смысле — для разделения данных между хранилищами. В руководстве Microsoft горизонтальная партиция прямо называется также шардом. Поэтому утверждение «партиция всегда находится на одном сервере» слишком категорично. Значение термина нужно читать в контексте продукта.
Два подхода могут сочетаться. В условном сервисе сведения о разных группах клиентов распределены по шардам, а внутри каждого шарда история разбита на месячные части. Первое правило выбирает место обслуживания клиента, второе организует его историю. Это пример возможной архитектуры, а не готовая рекомендация для любой базы.
Что произойдёт с двумя разными вопросами к данным
Допустим, архив содержит двенадцать месячных частей, а сотруднику нужен один месяц. При подходящих условиях система может исключить ненужные части — такой механизм описан PostgreSQL. Но вопрос о всей истории потребует более широкого чтения. Количество частей само по себе не гарантирует ускорение.
Теперь представим запрос по одному клиенту, размещённому на определённом шарде. Если система может определить его местоположение, обращение получится направленным. Для общего итога по всем клиентам могут понадобиться несколько шардов. Документация MongoDB отдельно различает направленные обращения и обращения ко всем шардам. Сбор общего результата добавляет работу, даже когда данные аккуратно распределены.
Какие сведения собрать перед выбором
Начните с трёх понятных сценариев: поиск одной записи, отчёт за период и общий итог по всему набору. Для каждого опишите, какие части нужны и где они находятся. Затем выясните, что происходит, когда одна группа клиентов становится значительно активнее остальных. Равное количество записей не обязательно означает равную нагрузку.
В обсуждении также нужны правила добавления новых частей, перемещения данных и работы при недоступности одного узла. Это вопросы сопровождения, которые нельзя заменить одним названием технологии. Результатом должен быть понятный ответ: какое правило делит записи, как находится нужное место и кто отвечает за обслуживание каждой части. Только после этого имеет смысл оценивать конкретное решение на типичной нагрузке.
Следующий шаг
На программе «Архитектор данных» можно познакомиться с задачами проектирования систем данных. При выборе подхода полезно учиться связывать устройство хранения с тем, как пользователи ищут, изменяют и объединяют сведения.
