Рецепты тюнинга схемы

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

Выбор типа таблицы

StarRocks поддерживает четыре типа таблиц: Duplicate Key, Aggregate, Unique Key и Primary Key. Все они упорядочены по KEY.

  • AGGREGATE KEY: когда в StarRocks загружаются записи с одинаковым AGGREGATE KEY, старые и новые записи агрегируются. В настоящее время Aggregate‑таблицы поддерживают функции агрегирования: SUM, MIN, MAX и REPLACE. Aggregate‑таблицы позволяют заранее агрегировать данные, упрощая бизнес‑отчёты и многомерную аналитику.

  • DUPLICATE KEY: для таблицы DUPLICATE KEY нужно указать только sort key. Записи с одинаковым DUPLICATE KEY сосуществуют. Подходит для аналитики без предварительной агрегирования данных.

  • UNIQUE KEY: когда загружаются записи с одинаковым UNIQUE KEY, новая запись перезаписывает старую. Таблица UNIQUE KEY похожа на Aggregate‑таблицу с функцией REPLACE. Обе подходят для сценариев с постоянными обновлениями.

  • PRIMARY KEY: таблицы Primary Key гарантируют уникальность записей и позволяют выполнять обновления в реальном времени.

CREATE TABLE site_visit
(
    siteid      INT,
    city        SMALLINT,
    username    VARCHAR(32),
    pv BIGINT   SUM DEFAULT '0'
)
AGGREGATE KEY(siteid, city, username)
DISTRIBUTED BY HASH(siteid);


CREATE TABLE session_data
(
    visitorid   SMALLINT,
    sessionid   BIGINT,
    visittime   DATETIME,
    city        CHAR(20),
    province    CHAR(20),
    ip          varchar(32),
    browser      CHAR(20),
    url         VARCHAR(1024)
)
DUPLICATE KEY(visitorid, sessionid)
DISTRIBUTED BY HASH(sessionid, visitorid);

CREATE TABLE sales_order
(
    orderid     BIGINT,
    status      TINYINT,
    username    VARCHAR(32),
    amount      BIGINT DEFAULT '0'
)
UNIQUE KEY(orderid)
DISTRIBUTED BY HASH(orderid);

CREATE TABLE sales_order
(
    orderid     BIGINT,
    status      TINYINT,
    username    VARCHAR(32),
    amount      BIGINT DEFAULT '0'
)
PRIMARY KEY(orderid)
DISTRIBUTED BY HASH(orderid);

Colocate Table

Чтобы ускорить запросы, таблицы с одинаковым распределением могут использовать общий столбец бакетирования. В этом случае данные можно соединять локально без передачи по кластеру во время операции join.

CREATE TABLE colocate_table
(
    visitorid   SMALLINT,
    sessionid   BIGINT,
    visittime   DATETIME,
    city        CHAR(20),
    province    CHAR(20),
    ip          varchar(32),
    browser      CHAR(20),
    url         VARCHAR(1024)
)
DUPLICATE KEY(visitorid, sessionid)
DISTRIBUTED BY HASH(sessionid, visitorid)
PROPERTIES(
    "colocate_with" = "group1"
);

Больше о colocate join и управлении репликами: Colocate join

Плоская таблица и star‑схема

StarRocks поддерживает star schema, которая более гибка для моделирования, чем плоские таблицы. Вы можете создать view вместо плоских таблиц на этапе моделирования, а затем выполнять запросы к нескольким таблицам для ускорения.

Недостатки плоских таблиц:

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

  • Высокая стоимость сопровождения, так как плоским таблицам требуются дополнительные разработки, место хранения и операции донаполнения данных.

  • Высокая стоимость загрузки данных: в плоской таблице много полей, а в Aggregate‑таблице ключевых полей может быть ещё больше. Во время загрузки приходится сортировать больше полей, что замедляет ingest.

Если у вас высокие требования к конкуррентности или низкой латентности запросов, вы всё ещё можете использовать плоские таблицы.

Партиция и бакет

StarRocks поддерживает двухуровневое разбиение: первый уровень — RANGE партиция, второй — HASH бакет.

  • RANGE партиция: используется для деления данных на интервалы (можно понимать как разбиение исходной таблицы на множество подтables). Большинство пользователей выбирают партиционирование по времени, что даёт преимущества:

    • Проще разделять «горячие» и «холодные» данные

    • Можно использовать многоуровневое хранение StarRocks (SSD + SATA)

    • Быстрее удалять данные по партиции

  • HASH бакет: делит данные на бакеты по хеш‑значению.

    • Рекомендуется использовать для бакетирования столбец с высокой различимостью, чтобы избежать перекоса данных.

    • Для упрощения восстановления держите размер сжатых данных в каждом бакете в диапазоне 100 MB — 1 GB. Рекомендуем выбрать подходящее число бакетов при создании таблицы или добавлении партиции.

    • Random бакетирование не рекомендуется. При создании таблицы явно указывайте столбец HASH‑бакетирования.

Разрежённый индекс и bloomfilter индекс

StarRocks хранит данные в упорядоченном виде и строит разрежённые индексы с гранулярностью 1024 строки.

StarRocks выбирает фиксированной длины префикс (сейчас 36 байт) в схеме как разрежённый индекс.

При создании таблицы рекомендуется помещать часто используемые для фильтрации поля в начало объявления схемы. Поля с наибольшей различимостью и частотой в запросах ставьте первыми.

Поле VARCHAR должно располагаться в конце разрежённого индекса, потому что индекс обрезается на поле VARCHAR. Если VARCHAR идёт первым, индекс может оказаться короче 36 байт.

Возьмём таблицу site_visit из примера. В ней четыре столбца: siteid, city, username, pv. Sort key включает три столбца siteid, city, username размером 4, 2 и 32 байта соответственно. Поэтому префикс‑индекс (разрежённый индекс) может составлять первые 30 байт siteid + city + username.

Помимо разрежённых индексов, StarRocks предоставляет bloomfilter‑индексы, эффективные для фильтрации по столбцам с высокой различимостью. Если вам нужно поставить поля VARCHAR перед другими полями, вы можете создать bloomfilter‑индексы.

Inverted Index

StarRocks использует технологию Bitmap Index для поддержки инвертированных индексов, применимых ко всем столбцам таблиц Duplicate Key и к ключевым столбцам таблиц Aggregate и Unique Key. Bitmap Index подходит для столбцов с небольшим диапазоном значений, например gender, city, province. По мере расширения диапазона растёт и bitmap‑индекс.

Materialized view (rollup)

Rollup — это по сути материализованный индекс исходной (базовой) таблицы. При создании rollup можно выбрать только часть столбцов базовой таблицы в схему, и порядок полей в схеме может отличаться от базовой таблицы. Ниже — несколько случаев использования rollup:

  • Низкая степень агрегируемости данных в базовой таблице из‑за полей с высокой различимостью. В этом случае можно выбрать часть столбцов и создать rollup. Возьмём таблицу site_visit из примера:

    site_visit(siteid, city, username, pv)

    Столбец siteid может приводить к плохой агрегируемости. Если часто нужно считать PV по city, можно создать rollup только с city и pv.

    ALTER TABLE site_visit ADD ROLLUP rollup_city(city, pv);

  • Префикс‑индекс в базовой таблице не срабатывает, так как способ построения базовой таблицы не покрывает все паттерны запросов. В этом случае можно создать rollup, чтобы поменять порядок столбцов. На примере session_data:

    session_data(visitorid, sessionid, visittime, city, province, ip, browser, url)

    Если помимо visitorid нужно анализировать посещения по browser и province, можно создать отдельный rollup:

    ALTER TABLE session_data
ADD ROLLUP rollup_browser(browser,province,ip,url)
DUPLICATE KEY(browser,province);

Изменение схемы (Schema change)

В StarRocks есть три способа менять схемы: sorted schema change, direct schema change и linked schema change.

  • Sorted schema change: изменяет порядок сортировки столбца и переупорядочивает данные. Например, удаление столбца в отсортированной схеме приводит к переупорядочиванию данных.

    ALTER TABLE site_visit DROP COLUMN city;

  • Direct schema change: преобразует данные вместо переупорядочивания, например изменяет тип столбца или добавляет столбец в разрежённый индекс.

    ALTER TABLE site_visit MODIFY COLUMN username varchar(64);

  • Linked schema change: выполняет изменения без преобразования данных, например добавление столбцов.

    ALTER TABLE site_visit ADD COLUMN click bigint SUM default '0';

    Рекомендуется сразу выбирать подходящую схему при создании таблиц, чтобы ускорить будущие изменения схемы.