Синхронные материализованные представления¶

В этой теме описывается, как создавать, использовать и администрировать синхронные материализованные представления (Rollup).

Для синхронного MV все изменения в базовой таблице одновременно обновляют соответствующие синхронные MV; обновление инициируется автоматически. Обслуживание таких MV существенно дешевле, что делает их подходящими для прозрачного ускорения real‑time агрегирующих запросов по одной таблице.

Синхронные MV в StarRocks создаются только на одной базовой таблице из default catalog и по сути являются специальным индексом для ускорения запросов, а не физической таблицей, как асинхронные MV.

Начиная с v2.4, StarRocks поддерживает асинхронные MV, которые можно создавать над несколькими таблицами и с более широким набором агрегирующих операторов. См. Asynchronous materialized view.

Сравнение ASYNC MV (v2.5/v2.4) и SYNC MV (Rollup):

Базовые понятия¶

• Base table — исходная таблица для MV. Для синхронных MV — это одна «родная» таблица из default catalog. Поддерживаются Duplicate Key и Aggregate таблицы.

• Refresh — синхронный MV обновляется при каждом изменении данных в базовой таблице; ручного запуска не требуется.

• Query rewrite — при выполнении запроса к базовой таблице система определяет, можно ли переиспользовать предвычисленные результаты из MV. Если да, запрос читается напрямую из MV, избегая дорогих вычислений/соединений. Поддержка переписывания ограничена частью агрегирующих операторов (см. Correspondence of aggregate functions).

Подготовка¶

Проверьте, подходит ли ваш DWH под ускорение с помощью синхронных MV (например, есть ли часто переиспользуемые подзапросы).

Пример: таблица sales_records с полями record_id, seller_id, store_id, sale_date, sale_amt.

CREATE TABLE sales_records(
    record_id INT,
    seller_id INT,
    store_id INT,
    sale_date DATE,
    sale_amt BIGINT
) DISTRIBUTED BY HASH(record_id);

INSERT INTO sales_records
VALUES
    (001,01,1,"2022-03-13",8573),
    (002,02,2,"2022-03-14",6948),
    (003,01,1,"2022-03-14",4319),
    (004,03,3,"2022-03-15",8734),
    (005,03,3,"2022-03-16",4212),
    (006,02,2,"2022-03-17",9515);

Частая аналитика сумм по магазинам (запрос с sum()):

SELECT store_id, SUM(sale_amt)
FROM sales_records
GROUP BY store_id;

До создания MV EXPLAIN показывает rollup: sales_records — запрос использует базовую таблицу.

Создание синхронного MV¶

CREATE MATERIALIZED VIEW store_amt AS
SELECT store_id, SUM(sale_amt)
FROM sales_records
GROUP BY store_id;

Внимание

• При использовании агрегатных функций требуется GROUP BY с минимум одним столбцом группировки в SELECT.

• Нельзя использовать одну агрегатную функцию над несколькими столбцами (sum(a+b) не поддерживается).

• Нельзя использовать несколько агрегатных функций над одним столбцом (select sum(a), min(a) ... не поддерживается).

• JOIN не поддерживается при создании синхронного MV.

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

• Слишком много синхронных MV по таблице замедляет ingest, т.к. они обновляются синхронно с базовой таблицей.

• Параллельное создание нескольких синхронных MV не поддерживается.

• MV можно создавать только в default_catalog.

Проверка статуса построения¶

Создание MV — асинхронная операция. Успех CREATE MATERIALIZED VIEW означает, что задача поставлена. Статус смотрите через SHOW ALTER MATERIALIZED VIEW; поле RollupIndexName — имя MV, State — состояние.

Прямой запрос к MV¶

Синхронный MV — индекс, не отдельная таблица. Для прямого чтения используйте hint [_SYNC_MV_]:

SELECT * FROM store_amt [_SYNC_MV_];

Примечание: имена столбцов MV генерируются автоматически, даже если в SELECT заданы алиасы.

Переписывание и ускорение¶

Повторный запуск запроса после построения MV, как правило, сокращает время (например, до 0.01s в примере).

Проверка попадания в MV¶

EXPLAIN покажет rollup: store_amt — запрос использует синхронный MV.

Просмотр синхронных MV¶

DESC <tbl_name> ALL показывает схему базовой таблицы и её синхронных MV.

Удаление синхронного MV¶

Удаляйте MV, если он создан неверно и ещё строится (отмените задачу CANCEL ALTER TABLE ROLLUP ...), если избыточные MV снижают ingest, или если частота запросов низкая и высокая латентность приемлема.

Удаление существующего MV:

DROP MATERIALIZED VIEW store_amt;

Рекомендации¶

Точное count distinct¶

Используйте bitmap_union(to_bitmap(user_id)) для предагрегации:

CREATE MATERIALIZED VIEW advertiser_uv AS
SELECT advertiser, channel, bitmap_union(to_bitmap(user_id))
FROM advertiser_view_record
GROUP BY advertiser, channel;

Запросы count(distinct user_id) будут переписаны в bitmap_union_count(to_bitmap(user_id)) и смогут попасть в MV.

Приблизительный count distinct¶

Используйте hll_union(hll_hash(user_id)):

CREATE MATERIALIZED VIEW advertiser_uv2 AS
SELECT advertiser, channel, hll_union(hll_hash(user_id))
FROM advertiser_view_record
GROUP BY advertiser, channel;

Дополнительные sort‑keys¶

Если базовая таблица tableA(k1,k2,k3) отсортирована по k1,k2, а нужно ускорить WHERE k3 = x, создайте MV с k3 первым столбцом:

CREATE MATERIALIZED VIEW k3_as_key AS
SELECT k3, k2, k1
FROM tableA;

Соответствие агрегатных функций¶