Ответ

Распределение больших объёмов данных достигается двумя основными способами:

Партиционирование (partitioning): Логическое деление одной таблицы внутри одной базы данных на сегменты (partition) по какому-то ключу, обычно дате или диапазону значений. Это позволяет быстро выполнять операции над отдельными разделами, ускоряет поиск и облегчает обслуживание.
Шардинг (sharding): Физическое разделение данных на несколько БД/серверов по определённому алгоритму — таблица фактически дублируется на разных кластерах, каждый из которых содержит свой сегмент данных.

Преимущества partitioning — нет необходимости поддерживать отдельную бизнес-логику маршрутизации запросов, всё происходит "прозрачно" для приложения; недостатки — ограничено возможностями одной СУБД.

Шардинг даёт горизонтальное масштабирование (лимит зависит только от числа серверов), но требует сложной синхронизации, маршрутизации и обработки "меж-шардовых" запросов.

Пример (PostgreSQL, range-partitioning):

-- Базовая партиционированная таблица
CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  customer_id INT,
  order_date DATE
) PARTITION BY RANGE (order_date);

CREATE TABLE orders_2023 PARTITION OF orders
  FOR VALUES FROM ('2023-01-01') TO ('2024-01-01');

Вопрос с подвохом

Вопрос: Можно ли "на лету" перемещать строки между партициями без блокирования основной таблицы?

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

Пример:

-- ALTER TABLE ... MOVE PARTITION, как правило, требует экстра-внимания к блокировкам. Лучше делать в малонагруженное время.

Примеры реальных ошибок из-за незнания тонкостей темы

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

История 2: При добавлении шардинга не учли неуникальность идентификатора между шардами. Часто возникали конфликты ключей при межшардовой агрегации.

История 3: Автоматическая архивация "устаревших" партиций удаляла их без повторной проверки внешних связей, что привело к потере связи с другими таблицами и потере части "живых" данных. После этого всю логику удаления партиций переписали с мультитестами на связность.