Равномерное распределение данных¶

• Если после создания таблицы шаблоны запросов или свойства данных в бизнес‑сценарии изменились, начиная с версии v3.2 StarRocks поддерживает изменение некоторых свойств, связанных с распределением данных, после создания таблицы, чтобы соответствовать актуальным требованиям к производительности.

• Начиная с версии v3.1, вам не нужно указывать бакет‑ключ в предложении DISTRIBUTED BY при создании таблицы или добавлении партиции. StarRocks поддерживает случайное бакетирование (random bucketing), которое равномерно распределяет данные по всем бакетам.

• Начиная с версии v2.5.7, можно не задавать вручную число бакетов при создании таблицы или добавлении партиции: StarRocks может автоматически определять число бакетов (BUCKETS). Однако если производительность вас не устраивает и вы знакомы с механизмом бакетирования, вы можете задать число бакетов вручную.

Введение¶

Общие методы распределения¶

Современные распределённые СУБД обычно используют базовые методы распределения: Round‑Robin, Range, List и Hash.

• Round‑Robin: циклическое распределение данных по узлам.

• Range: распределение по диапазонам значений столбца партиционирования. На схеме диапазоны [1-3] и [4-6] сопоставлены разным узлам.

• List: распределение по дискретным значениям столбцов партиционирования (например, пол, регион). Каждое значение сопоставляется узлу; несколько разных значений могут сопоставляться одному узлу.

• Hash: распределение на основе хеш‑функции.

Для большей гибкости помимо одиночных методов можно комбинировать их — распространённые сочетания: Hash+Hash, Range+Hash, Hash+List.

Методы распределения в StarRocks¶

StarRocks поддерживает как раздельное, так и комбинированное использование методов распределения.

Помимо общих методов, StarRocks поддерживает Random‑распределение для упрощения настройки бакетирования.

StarRocks реализует двухуровневую схему «партиционирование + бакетирование».

• Первый уровень — партиционирование: данные в таблице можно делить на партиции. Поддерживаются expression partitioning, range partitioning и list partitioning. Можно и без партиционирования (вся таблица — одна партиция).

• Второй уровень — бакетирование: данные в партиции дополнительно распределяются по бакетам. Поддерживаются hash и random bucketing.

• Random distribution

  Если при создании таблицы не задать методы партиционирования и бакетирования, используется random distribution по умолчанию. В настоящий момент этот метод доступен только для таблиц Duplicate Key.

  CREATE TABLE site_access1 (
      event_day DATE,
      site_id INT DEFAULT '10', 
      pv BIGINT DEFAULT '0' ,
      city_code VARCHAR(100),
      user_name VARCHAR(32) DEFAULT ''
  )
  DUPLICATE KEY (event_day,site_id,pv);
  -- Because the partitioning and bucketing methods are not configured, random distribution is used by default.
  

• Hash distribution

  CREATE TABLE site_access2 (
      event_day DATE,
      site_id INT DEFAULT '10',
      city_code SMALLINT,
      user_name VARCHAR(32) DEFAULT '',
      pv BIGINT SUM DEFAULT '0'
  )
  AGGREGATE KEY (event_day, site_id, city_code, user_name)
  -- Use hash bucketing as the bucketing method and must specify the bucketing key.
  DISTRIBUTED BY HASH(event_day,site_id); 
  

• Range+Random distribution (в настоящий момент доступно только для Duplicate Key таблиц.)

  CREATE TABLE site_access3 (
      event_day DATE,
      site_id INT DEFAULT '10', 
      pv BIGINT DEFAULT '0' ,
      city_code VARCHAR(100),
      user_name VARCHAR(32) DEFAULT ''
  )
  DUPLICATE KEY(event_day,site_id,pv)
  -- Use expression partitioning as the partitioning method and configure a time function expression.
  -- You can also use range partitioning.
  PARTITION BY date_trunc('day', event_day);
  -- Because the bucketing method is not configured, random bucketing is used by default.
  

• Range+Hash distribution

  CREATE TABLE site_access4 (
      event_day DATE,
      site_id INT DEFAULT '10',
      city_code VARCHAR(100),
      user_name VARCHAR(32) DEFAULT '',
      pv BIGINT SUM DEFAULT '0'
  )
  AGGREGATE KEY(event_day, site_id, city_code, user_name)
  -- Use expression partitioning as the partitioning method and configure a time function expression.
  -- You can also use range partitioning.
  PARTITION BY date_trunc('day', event_day)
  -- Use hash bucketing as the bucketing method and must specify the bucketing key.
  DISTRIBUTED BY HASH(event_day, site_id);
  

• List+Random distribution (в настоящий момент доступно только для Duplicate Key таблиц.)

  CREATE TABLE t_recharge_detail1 (
      id bigint,
      user_id bigint,
      recharge_money decimal(32,2), 
      city varchar(20) not null,
      dt date not null
  )
  DUPLICATE KEY(id)
  -- Use expression partitioning as the partitioning method and specify the partitioning column.
  -- You can also use list partitioning.
  PARTITION BY (city);
  -- Because the bucketing method is not configured, random bucketing is used by default.
  

• List+Hash distribution

  CREATE TABLE t_recharge_detail2 (
      id bigint,
      user_id bigint,
      recharge_money decimal(32,2), 
      city varchar(20) not null,
      dt date not null
  )
  DUPLICATE KEY(id)
  -- Use expression partitioning as the partitioning method and specify the partitioning column.
  -- You can also use list partitioning.
  PARTITION BY (city)
  -- Use hash bucketing as the bucketing method and must specify the bucketing key.
  DISTRIBUTED BY HASH(city,id); 
  

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

Метод партиционирования делит таблицу на несколько партиций. Он используется прежде всего для разделения таблицы на различные единицы управления на основе партиционирующего ключа. Для каждой партиции можно задать стратегию хранения: число бакетов, стратегию hot/cold, тип носителя и число реплик. StarRocks позволяет использовать разные типы носителей в одном кластере: например, свежие данные хранить на SSD для ускорения запросов, а исторические — на SATA для снижения затрат.

Как выбирать столбцы и гранулярность партиционирования¶

• Ключ партиционирования — один или несколько столбцов. Правильный выбор столбца может значительно сократить объём сканируемых данных. В большинстве систем используют партиционирование по времени для упрощения удаления просроченных данных и управления многоуровневым хранением hot/cold. В этом случае применяйте expression или range partitioning со столбцом времени. Если данные часто запрашиваются и управляются по ENUM‑значениям, используйте expression или list partitioning и выберите соответствующий столбец.

• При выборе гранулярности учитывайте объём данных, шаблоны запросов и требуемую детальность управления.

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

  • Пример 2: если месячный объём велик, а запросы обычно по дням, партиционирование по дням уменьшит объём сканирования.

  • Пример 3: если требуется ежедневное истечение данных, выбирайте дневную гранулярность.

Бакетирование¶

Метод бакетирования делит партицию на несколько бакетов. Данные в бакете называются tablet.

Поддерживаются random bucketing с версии v3.1 и hash bucketing.

• Random bucketing: при создании таблицы или добавлении партиций бакет‑ключ не задаётся. Данные в партиции случайно распределяются по бакетам.

• Hash bucketing: требуется указать бакет‑ключ. Данные в одной партиции делятся на бакеты по значениям ключа; строки с одинаковым значением попадают в один и тот же бакет.

Число бакетов: по умолчанию StarRocks автоматически определяет число бакетов (с v2.5.7). Его можно и задать вручную. Подробнее см. определение числа бакетов.

Создание и управление партициями¶

Создание партиций¶

Expression partitioning (рекомендуется)¶

Режим shared‑data поддерживает time function expression с v3.1.0 и column expression с v3.1.1.

Начиная с v3.0, StarRocks поддерживает expression partitioning (ранее — automatic partitioning), более гибкий и удобный метод. Он подходит для большинства случаев, например запросов и управления по непрерывным диапазонам дат или ENUM‑значениям.

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

С v3.4 expression partitioning дополнительно оптимизирован: унифицирует стратегии партиционирования и поддерживает более сложные решения. Рекомендуется в большинстве случаев и в будущем заменит другие стратегии.

Пример 1: простое time function выражение с DATETIME‑столбцом.

CREATE TABLE site_access(
    event_day DATETIME NOT NULL,
    site_id INT DEFAULT '10',
    city_code VARCHAR(100),
    user_name VARCHAR(32) DEFAULT '',
    pv BIGINT DEFAULT '0'
)
DUPLICATE KEY(event_day, site_id, city_code, user_name)
PARTITION BY time_slice(event_day, INTERVAL 7 day)
DISTRIBUTED BY HASH(event_day, site_id)

Пример 2: column expression с несколькими столбцами.

CREATE TABLE t_recharge_detail1 (
    id bigint,
    user_id bigint,
    recharge_money decimal(32,2), 
    city varchar(20) not null,
    dt varchar(20) not null
)
DUPLICATE KEY(id)
PARTITION BY dt,city
DISTRIBUTED BY HASH(`id`);

Пример 3: сложное time function выражение с Unix‑timestamp столбцом.

CREATE TABLE orders (
    ts BIGINT NOT NULL,
    id BIGINT NOT NULL,
    city STRING NOT NULL
)
PARTITION BY from_unixtime(ts,'%Y%m%d');

Пример 4: смешанное выражение — time function + column expression.

CREATE TABLE orders (
    ts BIGINT NOT NULL,
    id BIGINT NOT NULL,
    city STRING NOT NULL
)
PARTITION BY from_unixtime(ts,'%Y%m%d'), city;

Range partitioning¶

Range partitioning подходит для простых непрерывных данных — временных рядов или числовых диапазонов.

Ручное создание партиций¶

Определите соответствие каждой партиции диапазону значений столбца партиционирования.

• Столбец партиционирования типа date.

  CREATE TABLE site_access(
      event_day DATE,
      site_id INT,
      city_code VARCHAR(100),
      user_name VARCHAR(32),
      pv BIGINT SUM DEFAULT '0'
  )
  AGGREGATE KEY(event_day, site_id, city_code, user_name)
  PARTITION BY RANGE(event_day)(
      PARTITION p1 VALUES LESS THAN ("2020-01-31"),
      PARTITION p2 VALUES LESS THAN ("2020-02-29"),
      PARTITION p3 VALUES LESS THAN ("2020-03-31")
  )
  DISTRIBUTED BY HASH(site_id);
  

• Столбец партиционирования типа integer.

  CREATE TABLE site_access(
      datekey INT,
      site_id INT,
      city_code SMALLINT,
      user_name VARCHAR(32),
      pv BIGINT SUM DEFAULT '0'
  )
  AGGREGATE KEY(datekey, site_id, city_code, user_name)
  PARTITION BY RANGE (datekey) (
      PARTITION p1 VALUES LESS THAN ("20200131"),
      PARTITION p2 VALUES LESS THAN ("20200229"),
      PARTITION p3 VALUES LESS THAN ("20200331")
  )
  DISTRIBUTED BY HASH(site_id);
  

• Три специальных time‑функции как столбцы партиционирования (с v3.3.0).

  При явном задании соответствия партиций и диапазонов значений столбца можно использовать специальную time‑функцию, чтобы преобразовать значения timestamp или строк в даты и делить партиции по этим датам.

  -- A 10-digit timestamp accurate to the second, for example, 1703832553.
  CREATE TABLE site_access(
      event_time bigint,
      site_id INT,
      city_code SMALLINT,
      user_name VARCHAR(32),
      pv BIGINT SUM DEFAULT '0'
    )
  AGGREGATE KEY(event_time, site_id, city_code, user_name)
  PARTITION BY RANGE(from_unixtime(event_time)) (
      PARTITION p1 VALUES LESS THAN ("2021-01-01"),
      PARTITION p2 VALUES LESS THAN ("2021-01-02"),
      PARTITION p3 VALUES LESS THAN ("2021-01-03")
  )
  DISTRIBUTED BY HASH(site_id)
  ;
  
  -- A 13-digit timestamp accurate to the millisecond, for example, 1703832553219.
  CREATE TABLE site_access(
      event_time bigint,
      site_id INT,
      city_code SMALLINT,
      user_name VARCHAR(32),
      pv BIGINT SUM DEFAULT '0'
    )
  AGGREGATE KEY(event_time, site_id, city_code, user_name)
  PARTITION BY RANGE(from_unixtime_ms(event_time))(
      PARTITION p1 VALUES LESS THAN ("2021-01-01"),
      PARTITION p2 VALUES LESS THAN ("2021-01-02"),
      PARTITION p3 VALUES LESS THAN ("2021-01-03")
  )
  DISTRIBUTED BY HASH(site_id);
  

  CREATE TABLE site_access (
       event_time  varchar(100),
       site_id INT,
       city_code SMALLINT,
       user_name VARCHAR(32),
       pv BIGINT SUM DEFAULT '0'
  )
  AGGREGATE KEY(event_time, site_id, city_code, user_name)
  PARTITION BY RANGE(str2date(event_time, '%Y-%m-%d'))(
      PARTITION p1 VALUES LESS THAN ("2021-01-01"),
      PARTITION p2 VALUES LESS THAN ("2021-01-02"),
      PARTITION p3 VALUES LESS THAN ("2021-01-03")
  )
  DISTRIBUTED BY HASH(site_id);
  

Динамическое партиционирование¶

Свойства dynamic partitioning задаются при создании таблицы. StarRocks автоматически заблаговременно создаёт новые партиции и удаляет устаревшие, реализуя TTL‑управление для партиций.

В отличие от автоматического создания партиций в expression partitioning, динамическое партиционирование периодически создаёт новые партиции только по заданным свойствам. Если новые данные не попадают в созданные партиции, загрузка завершится ошибкой. Expression partitioning создаёт нужные партиции исходя из поступающих данных.

Пакетное создание нескольких партиций¶

Можно пакетно создавать партиции при и после создания таблицы. Укажите начало и конец диапазона в START() и END() и шаг в EVERY(). Диапазоны партиций лево‑замкнутые и право‑разомкнутые. Правила именования такие же, как у динамического партиционирования.

• Столбец партиционирования типа date.

  При типе date в момент создания таблицы используйте START() и END() для указания даты начала и конца, а EVERY(INTERVAL xxx) — для шага. Поддерживаемая гранулярность интервала: HOUR (с v3.0), DAY, WEEK, MONTH, YEAR.

  В примере ниже партиции создаются с 2021‑01‑01 по 2021‑01‑04 с шагом 1 день:

  CREATE TABLE site_access (
      datekey DATE,
      site_id INT,
      city_code SMALLINT,
      user_name VARCHAR(32),
      pv BIGINT DEFAULT '0'
  )
  DUPLICATE KEY(datekey, site_id, city_code, user_name)
  PARTITION BY RANGE (datekey) (
      START ("2021-01-01") END ("2021-01-04") EVERY (INTERVAL 1 DAY)
  )
  DISTRIBUTED BY HASH(site_id);
  

  Эквивалентно следующему PARTITION BY:

  PARTITION BY RANGE (datekey) (
      PARTITION p20210101 VALUES [('2021-01-01'), ('2021-01-02')),
      PARTITION p20210102 VALUES [('2021-01-02'), ('2021-01-03')),
      PARTITION p20210103 VALUES [('2021-01-03'), ('2021-01-04'))
  )
  

  Можно создавать партии с разными интервалами, указав разные значения в EVERY для каждого блока (диапазоны не должны пересекаться). Например:

  CREATE TABLE site_access (
      datekey DATE,
      site_id INT,
      city_code SMALLINT,
      user_name VARCHAR(32),
      pv BIGINT DEFAULT '0'
  )
  DUPLICATE KEY(datekey, site_id, city_code, user_name)
  PARTITION BY RANGE (datekey) (
      START ("2019-01-01") END ("2021-01-01") EVERY (INTERVAL 1 YEAR),
      START ("2021-01-01") END ("2021-05-01") EVERY (INTERVAL 1 MONTH),
      START ("2021-05-01") END ("2021-05-04") EVERY (INTERVAL 1 DAY)
  )
  DISTRIBUTED BY HASH(site_id);
  

  Эквивалентно:

  PARTITION BY RANGE (datekey) (
      PARTITION p2019 VALUES [('2019-01-01'), ('2020-01-01')),
      PARTITION p2020 VALUES [('2020-01-01'), ('2021-01-01')),
      PARTITION p202101 VALUES [('2021-01-01'), ('2021-02-01')),
      PARTITION p202102 VALUES [('2021-02-01'), ('2021-03-01')),
      PARTITION p202103 VALUES [('2021-03-01'), ('2021-04-01')),
      PARTITION p202104 VALUES [('2021-04-01'), ('2021-05-01')),
      PARTITION p20210501 VALUES [('2021-05-01'), ('2021-05-02')),
      PARTITION p20210502 VALUES [('2021-05-02'), ('2021-05-03')),
      PARTITION p20210503 VALUES [('2021-05-03'), ('2021-05-04'))
  )
  

• Столбец партиционирования типа integer.

  Для INT‑столбца в START и END задаётся диапазон, в EVERY — шаг. Пример:

  Значения в START() и END() должны быть в двойных кавычках, а в EVERY() — без кавычек.

Операция не удаляет данные немедленно. Они помещаются в корзину (Trash) на некоторый срок (по умолчанию сутки). Если партиция удалена ошибочно, используйте команду RECOVER для восстановления партиции и её данных.

• Короткие запросы сканируют небольшой объём и могут выполняться на одном узле.

• Длинные запросы сканируют большие объёмы и выигрывают от параллельного сканирования на нескольких узлах.