Как партиционировать одну таблицу с миллиардами строк?

Question

IT Interview Practice · Accepted Answer

**Разбейте гигантскую таблицу на меньшие физические дочерние таблицы по ключу партиционирования, чтобы каждый запрос касался только нужных партиций (partition pruning) вместо сканирования миллиардов строк.** Таблица с 5 млрд строк заказов всё ещё ведёт себя как одна логическая таблица, но движок пропускает 99% её, когда ваш `WHERE` фильтрует по ключу партиционирования.

## Форма партиционированной таблицы

```text
                 orders (logical parent)
                        │  partition key = created_at
       ┌────────────────┼────────────────┬───────────────┐
       ▼                ▼                ▼               ▼
 orders_2024_q1   orders_2024_q2   orders_2024_q3   orders_2025_q1
  (child table)    (child table)    (child table)    (child, active)
       │                                                  │
   local index                                        local index
   (per child)                                        (per child)
```

## Выбор стратегии партиционирования

- **Range** — по диапазонам дат/id. Лучше для time-series (заказы, логи, события); свежие данные остаются горячими, а старые диапазоны легко дропать.
- **Hash** — равномерное распределение по N партициям через `hash(key) % N`. Используйте, когда нет естественного диапазона и нужна сбалансированная нагрузка (например, `user_id`).
- **List** — явные бакеты (`region IN ('EU','US')`). Хорошо для изоляции по tenant или региону.

```sql
-- Postgres: range partition by month, prune on created_at
CREATE TABLE orders (id bigint, created_at date, amount numeric)
  PARTITION BY RANGE (created_at);

CREATE TABLE orders_2025_01 PARTITION OF orders
  FOR VALUES FROM ('2025-01-01') TO ('2025-02-01');

-- This scans ONLY orders_2025_01, not the whole table
SELECT sum(amount) FROM orders
 WHERE created_at >= '2025-01-01' AND created_at < '2025-02-01';
```

## Pruning, индексы, обслуживание

- **Partition pruning** работает, только если запрос фильтрует по **ключу партиционирования**. Фильтруйте по чему-то другому — и вы сканируете каждую партицию — ошибка №1.
- **Локальный индекс** = один индекс на дочернюю таблицу (по умолчанию в Postgres); дёшево строить и дропать вместе с партицией. **Глобальный индекс** (Oracle) охватывает все партиции — помогает уникальным lookup поперёк партиций, но должен перестраиваться при дропе одной.
- **Обслуживание** становится O(партиция): архивируйте старые данные через `DROP TABLE orders_2019` (мгновенно, без гигантского `DELETE`), и `ATTACH`/`DETACH` для скользящих окон.

## Взгляд с точки зрения интервью

Интервьюер прощупывает, понимаете ли вы, что **партиционирование — это не индексирование**: оно сокращает сканируемые данные, а индекс сокращает просматриваемые строки внутри скана; часто нужны оба. Хороший ответ называет range/hash/list; отличный подчёркивает, что **ключ партиционирования должен совпадать с вашим доминирующим фильтром запроса**, предупреждает, что неверный ключ убивает pruning, и упоминает дешёвое архивирование через `DROP`.

**Компромисс:** кросс-партиционные запросы (без фильтра по ключу или уникальные ограничения поперёк партиций) становятся медленнее, а обеспечение уникальности труднее. Не партиционируйте таблицу на 10 млн строк — вы добавите операционную сложность без выгоды. Партиционируйте, когда таблица огромна **и** запросы естественно ограничены по ключу.

Форма партиционированной таблицы

Выбор стратегии партиционирования

Pruning, индексы, обслуживание

Взгляд с точки зрения интервью

Похожие вопросы