Партиционирование¶

Быстрая аналитика в StarRocks начинается с схемы таблицы, соответствующей вашим шаблонам запросов. Это руководство конденсирует практический опыт в чёткие правила по партиционированию, помогая вам:

• Сканировать меньше данных благодаря агрессивной обрезке партиций (partition pruning)

• Управлять задачами жизненного цикла (TTL, удаления по требованиям GDPR, перемещение по уровням хранения) с помощью операций, затрагивающих только метаданные

• Масштабироваться плавно при росте числа арендаторов, объёма данных или окон хранения

• Контролировать write amplification — новые данные попадают в «горячую» партицию; компакция выполняется в исторических партициях

Держите это руководство под рукой при моделировании новой таблицы или рефакторинге старой — каждый раздел даёт целевые критерии, эвристики проектирования и операционные «ограждения», чтобы вы избегали дорогостоящего перепартиционирования в дальнейшем.

Партиционирование vs. бакетирование — разные задачи¶

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

• Партиционирование позволяет StarRocks пропускать целые блоки данных во время выполнения запроса с помощью partition pruning и включает операции жизненного цикла, затрагивающие только метаданные, например удаление старых данных или данных конкретного арендатора.

• Бакетирование, напротив, помогает распределять данные по таблетам для параллелизации выполнения запросов и балансировки нагрузки, особенно в сочетании с хеш‑функциями.

Когда партиционировать?¶

Выбор ключа партиционирования¶

1. Сначала время — если 80% запросов включают фильтр по времени, начните с date_trunc('day', dt).

2. Изоляция арендаторов — добавьте tenant_id в ключ, когда нужно управлять данными по арендаторам.

3. Выравнивание с политикой хранения — включите в ключ столбец, по которому планируется очистка.

4. Составные ключи: PARTITION BY tenant_id, date_trunc('day', dt) обеспечивает идеальную обрезку, но создаёт #тенантов × #дней партиций. Держите суммарно <≈ 100 k, иначе память FE и компакция на BE будут страдать.

Выбор гранулярности¶

Гранулярность PARTITION BY date_trunc('day', dt) следует подбирать по сценарию. Можно использовать «hour», «day», «month» и т. д. См. date_trunc

• Эмпирическое правило: держите каждую партицию ≤ 100 GB и ≤ 20 k таблет/партицию с учётом реплик.

• Смешанная гранулярность: начиная с версии 3.4, StarRocks поддерживает смешанную гранулярность путём объединения исторических партиций в более грубые.

Примеры «рецепто⻶

Click‑stream факт (single‑tenant)¶

CREATE TABLE click_stream (
  user_id BIGINT,
  event_time DATETIME,
  url STRING,
  ...
)
DUPLICATE KEY(user_id, event_time)
PARTITION BY date_trunc('day', event_time)
DISTRIBUTED BY HASH(user_id) BUCKETS xxx;

SaaS метрики (multi‑tenant, шаблон A)¶

Рекомендуется для большинства SaaS‑нагрузок. Партиционирование по времени, строки арендатора хранятся совместно.

CREATE TABLE metrics (
  tenant_id INT,
  dt DATETIME,
  metric_name STRING,
  v DOUBLE
)
PRIMARY KEY(tenant_id, dt, metric_name)
PARTITION BY date_trunc('DAY', dt)
DISTRIBUTED BY HASH(tenant_id) BUCKETS xxx;

Композит для «крупных арендаторов» (шаблон B)¶

Когда необходимы DML/DDL по конкретным арендаторам или присутствуют «крупные» арендаторы, будьте внимательны к риску взрыва числа партиций.

CREATE TABLE activity (
  tenant_id INT,
  dt DATETIME,
  id BIGINT,
  ....
)
DUPLICATE KEY(dt, id)
PARTITION BY tenant_id, date_trunc('MONTH', dt)
DISTRIBUTED BY HASH(id) BUCKETS xxx;