Query Cache

Query Cache — это мощная функция Selena, которая может значительно повысить производительность агрегатных запросов. Сохраняя промежуточные результаты локальных агрегаций в памяти, Query Cache может избежать ненужного доступа к диску и вычислений для новых запросов, которые идентичны или похожи на предыдущие. С помощью Query Cache Selena может предоставлять быстрые и точные результаты для агрегатных запросов, экономя время и ресурсы и обеспечивая лучшую масштабируемость. Query Cache особенно полезен в сценариях с высокой конкурентностью, где многие пользователи выполняют похожие запросы на больших и сложных наборах данных.

Эта функция поддерживается начиная с версии 1.5.0.

В версии 2.5 Query Cache поддерживает только агрегатные запросы к отдельным плоским таблицам. Начиная с версии 1.5.0, Query Cache также поддерживает агрегатные запросы к нескольким таблицам, соединенным в схеме звезды.

Сценарии применения

Мы рекомендуем использовать Query Cache в следующих сценариях:

• Вы часто выполняете агрегатные запросы к отдельным плоским таблицам или к нескольким соединенным таблицам, которые связаны в схеме звезды.
• Большинство ваших агрегатных запросов — это агрегатные запросы без GROUP BY и агрегатные запросы GROUP BY с низкой кардинальностью.
• Ваши данные загружаются в режиме добавления по временным разделам и могут быть категоризированы как горячие данные и холодные данные на основе частоты доступа.

Query Cache поддерживает запросы, которые соответствуют следующим условиям:

• Движок запросов — Pipeline. Чтобы включить движок Pipeline, установите переменную сессии enable_pipeline_engine в true.

  ПРИМЕЧАНИЕ

  Другие движки запросов не поддерживают Query Cache.

• Запросы к нативным OLAP таблицам (с версии 2.5) или облачно-нативным таблицам (с версии 3.0). Query Cache не поддерживает запросы к внешним таблицам. Query Cache также поддерживает запросы, планы которых требуют доступа к синхронным материализованным представлениям. Однако Query Cache не поддерживает запросы, планы которых требуют доступа к асинхронным материализованным представлениям.

• Запросы являются агрегатными запросами к отдельным таблицам или к нескольким соединенным таблицам.

  ПРИМЕЧАНИЕ

  • Query Cache поддерживает Broadcast Join и Bucket Shuffle Join.
  • Query Cache поддерживает две древовидные структуры, содержащие операторы Join: Aggregation-Join и Join-Aggregation. Shuffle joins не поддерживаются в структуре дерева Aggregation-Join, в то время как Hash joins не поддерживаются в структуре дерева Join-Aggregation.

• Запросы не включают недетерминированные функции, такие как rand, random, uuid и sleep.

Query Cache поддерживает запросы к таблицам, которые используют любую из следующих политик разделения: Unpartitioned, Multi-Column Partitioned и Single-Column Partitioned.

Ограничения функции

• Query Cache основан на вычислениях по tablet'ам движка Pipeline. Вычисление по tablet'ам означает, что драйвер pipeline может обрабатывать целые tablet'ы один за другим, а не обрабатывать часть tablet'а или множество tablet'ов вперемешку. Если количество tablet'ов, которые нужно обработать каждым отдельным BE для запроса, больше или равно количеству драйверов pipeline, которые вызываются для выполнения этого запроса, Query Cache работает. Количество вызванных драйверов pipeline представляет фактическую степень параллелизма (DOP). Если количество tablet'ов меньше количества драйверов pipeline, каждый драйвер pipeline обрабатывает только часть конкретного tablet'а. В этой ситуации результаты вычислений по tablet'ам не могут быть получены, и поэтому Query Cache не работает.
• В Selena агрегатный запрос состоит как минимум из четырех этапов. Результаты вычислений по tablet'ам, генерируемые AggregateNode на первом этапе, могут быть кэшированы только тогда, когда OlapScanNode и AggregateNode вычисляют данные из одного и того же фрагмента. Результаты вычислений по tablet'ам, генерируемые AggregateNode на других этапах, не могут быть кэшированы. Для некоторых DISTINCT агрегатных запросов, если переменная сессии cbo_cte_reuse установлена в true, Query Cache не работает, когда OlapScanNode, который производит данные, и AggregateNode первого этапа, который потребляет произведенные данные, вычисляют данные из разных фрагментов и соединены ExchangeNode. Следующие два примера показывают сценарии, в которых выполняются оптимизации CTE и поэтому Query Cache не работает:
  • Выходные столбцы вычисляются с использованием агрегатной функции avg(distinct).
  • Выходные столбцы вычисляются несколькими DISTINCT агрегатными функциями.
• Если ваши данные перемешиваются перед агрегацией, Query Cache не может ускорить запросы к этим данным.
• Если столбцы group-by или столбцы дедупликации таблицы являются столбцами с высокой кардинальностью, для агрегатных запросов к этой таблице будут генерироваться большие результаты. В этих случаях запросы будут обходить Query Cache во время выполнения.
• Query Cache занимает небольшое количество памяти, предоставляемой BE для сохранения результатов вычислений. Размер Query Cache по умолчанию составляет 512 МБ. Поэтому Query Cache не подходит для сохранения элементов данных большого размера. Кроме того, после включения Query Cache производительность запросов снижается, если коэффициент попаданий в кэш низкий. Поэтому, если размер результатов вычислений, генерируемых для tablet'а, превышает порог, указанный параметром query_cache_entry_max_bytes или query_cache_entry_max_rows, Query Cache больше не работает для запроса, и запрос переключается в режим Passthrough.

Как это работает

Когда Query Cache включен, каждый BE разделяет локальную агрегацию запроса на следующие два этапа:

1. Агрегация по tablet'ам

   BE обрабатывает каждый tablet индивидуально. Когда BE начинает обрабатывать tablet, он сначала проверяет Query Cache, чтобы увидеть, находится ли промежуточный результат агрегации по этому tablet'у в Query Cache. Если да (попадание в кэш), BE напрямую извлекает промежуточный результат из Query Cache. Если нет (промах кэша), BE обращается к данным на диске и выполняет локальную агрегацию для вычисления промежуточного результата. Когда BE заканчивает обработку tablet'а, он заполняет Query Cache промежуточным результатом агрегации по этому tablet'у.

2. Межтабletная агрегация

   BE собирает промежуточные результаты со всех tablet'ов, участвующих в запросе, и объединяет их в окончательный результат.

   

Когда в будущем выдается похожий запрос, он может повторно использовать кэшированный результат предыдущего запроса. Например, запрос, показанный на следующем рисунке, включает три tablet'а (Tablets 0-2), и промежуточный результат для первого tablet'а (Tablet 0) уже находится в Query Cache. Для этого примера BE может напрямую извлечь результат для Tablet 0 из Query Cache вместо обращения к данным на диске. Если Query Cache полностью прогрет, он может содержать промежуточные результаты для всех трех tablet'ов, и таким образом BE не нужно обращаться к каким-либо данным на диске.

Для освобождения дополнительной памяти Query Cache использует политику вытеснения на основе Least Recently Used (LRU) для управления записями кэша в нем. Согласно этой политике вытеснения, когда объем памяти, занимаемый Query Cache, превышает его предопределенный размер (query_cache_capacity), наименее недавно используемые записи кэша вытесняются из Query Cache.

ПРИМЕЧАНИЕ

В будущем Selena также будет поддерживать политику вытеснения на основе Time to Live (TTL), основанную на которой записи кэша могут быть вытеснены из Query Cache.

FE определяет, нужно ли каждый запрос ускорять с помощью Query Cache, и нормализует запросы для устранения тривиальных литеральных деталей, которые не влияют на семантику запросов.

Чтобы предотвратить снижение производительности, вызванное плохими случаями Query Cache, BE использует адаптивную политику для обхода Query Cache во время выполнения.

Включение Query Cache

В этом разделе описываются параметры и переменные сессии, которые используются для включения и настройки Query Cache.

Переменные сессии FE

Переменная	Значение по умолчанию	Может быть динамически настроена	Описание
enable_query_cache	false	Да	Указывает, включать ли Query Cache. Допустимые значения: true и false. true указывает на включение этой функции, а false указывает на отключение этой функции. Когда Query Cache включен, он работает только для запросов, которые соответствуют условиям, указанным в разделе "Сценарии применения" этой темы.
query_cache_entry_max_bytes	4194304	Да	Указывает порог для запуска режима Passthrough. Допустимые значения: 0 до 9223372036854775807. Когда количество байтов или строк из результатов вычислений конкретного tablet'а, к которому обращается запрос, превышает порог, указанный параметром query_cache_entry_max_bytes или query_cache_entry_max_rows, запрос переключается в режим Passthrough. Если параметр query_cache_entry_max_bytes или query_cache_entry_max_rows установлен в 0, режим Passthrough используется даже тогда, когда из задействованных tablet'ов не генерируются результаты вычислений.
query_cache_entry_max_rows	409600	Да	То же, что и выше.

Параметры BE

Вам нужно настроить следующий параметр в файле конфигурации BE be.conf. После перенастройки этого параметра для BE вы должны перезапустить BE, чтобы новая настройка параметра вступила в силу.

Параметр	Обязательный	Описание
query_cache_capacity	Нет	Указывает размер Query Cache. Единица: байты. Размер по умолчанию составляет 512 МБ. Каждый BE имеет свой собственный локальный Query Cache в памяти, и он заполняет и проверяет только свой собственный Query Cache. Обратите внимание, что размер Query Cache не может быть меньше 4 МБ. Если емкость памяти BE недостаточна для обеспечения ожидаемого размера Query Cache, вы можете увеличить емкость памяти BE.

Разработан для максимального коэффициента попаданий в кэш во всех сценариях

Рассмотрим три сценария, где Query Cache все еще эффективен, даже когда запросы не идентичны буквально. Эти три сценария:

• Семантически эквивалентные запросы
• Запросы с перекрывающимися сканируемыми разделами
• Запросы к данным с изменениями данных только для добавления (без операций UPDATE или DELETE)

Семантически эквивалентные запросы

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

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

  • Q1

    SELECT
        (
            ifnull(sum(murmur_hash3_32(hour)), 0) + ifnull(sum(murmur_hash3_32(k0)), 0) + ifnull(sum(murmur_hash3_32(__c_0)), 0)
        ) AS fingerprint
    FROM
        (
            SELECT
                date_trunc('hour', ts) AS hour,
                k0,
                sum(v1) AS __c_0
            FROM
                t0
            WHERE
                ts between '2022-01-03 00:00:00'
                and '2022-01-03 23:59:59'
            GROUP BY
                date_trunc('hour', ts),
                k0
        ) AS t;

  • Q2

    SELECT
        date_trunc('hour', ts) AS hour,
        k0,
        sum(v1) AS __c_0
    FROM
        t0
    WHERE
        ts between '2022-01-03 00:00:00'
        and '2022-01-03 23:59:59'
    GROUP BY
        date_trunc('hour', ts),
        k0

• Если оба запроса принадлежат к одному из следующих типов запросов, они могут быть оценены как семантически эквивалентные. Обратите внимание, что запросы, которые включают предложение HAVING, не могут быть оценены как семантически эквивалентные запросам, которые не включают предложение HAVING. Однако включение предложения ORDER BY или LIMIT не влияет на оценку того, являются ли два запроса семантически эквивалентными.

  • GROUP BY агрегации

    SELECT <GroupByItems>, <AggFunctionItems> 
    FROM <Table> 
    WHERE <Predicates> [and <PartitionColumnRangePredicate>]
    GROUP BY <GroupByItems>
    [HAVING <HavingPredicate>] 

    ПРИМЕЧАНИЕ

    В предыдущем примере предложение HAVING является необязательным.

  • GROUP BY DISTINCT агрегации

    SELECT DISTINCT <GroupByItems>, <Items> 
    FROM <Table> 
    WHERE <Predicates> [and <PartitionColumnRangePredicate>]
    GROUP BY <GroupByItems>
    HAVING <HavingPredicate>

    ПРИМЕЧАНИЕ

    В предыдущем примере предложение HAVING является необязательным.

  • Агрегации без GROUP BY

    SELECT <AggFunctionItems> FROM <Table> 
    WHERE <Predicates> [and <PartitionColumnRangePredicate>]

  • DISTINCT агрегации без GROUP BY

    SELECT DISTINCT <Items> FROM <Table> 
    WHERE <Predicates> [and <PartitionColumnRangePredicate>]

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

  • col between v1 and v2: Значения столбца разделения попадают в диапазон [v1, v2], где v1 и v2 — константные выражения.
  • v1 < col and col < v2: Значения столбца разделения попадают в диапазон (v1, v2), где v1 и v2 — константные выражения.
  • v1 < col and col <= v2: Значения столбца разделения попадают в диапазон (v1, v2], где v1 и v2 — константные выражения.
  • v1 <= col and col < v2: Значения столбца разделения попадают в диапазон [v1, v2), где v1 и v2 — константные выражения.
  • v1 <= col and col <= v2: Значения столбца разделения попадают в диапазон [v1, v2], где v1 и v2 — константные выражения.

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

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

• Если оставшиеся предикаты предложений WHERE двух запросов семантически эквивалентны после удаления PartitionColumnRangePredicate, два запроса оцениваются как семантически эквивалентные.

• Если предикаты в предложениях HAVING двух запросов семантически эквивалентны, два запроса оцениваются как семантически эквивалентные.

Используйте следующую таблицу lineorder_flat в качестве примера:

CREATE TABLE `lineorder_flat`
(
    `lo_orderdate` date NOT NULL COMMENT "",
    `lo_orderkey` int(11) NOT NULL COMMENT "",
    `lo_linenumber` tinyint(4) NOT NULL COMMENT "",
    `lo_custkey` int(11) NOT NULL COMMENT "",
    `lo_partkey` int(11) NOT NULL COMMENT "",
    `lo_suppkey` int(11) NOT NULL COMMENT "",
    `lo_orderpriority` varchar(100) NOT NULL COMMENT "",
    `lo_shippriority` tinyint(4) NOT NULL COMMENT "",
    `lo_quantity` tinyint(4) NOT NULL COMMENT "",
    `lo_extendedprice` int(11) NOT NULL COMMENT "",
    `lo_ordtotalprice` int(11) NOT NULL COMMENT "",
    `lo_discount` tinyint(4) NOT NULL COMMENT "",
    `lo_revenue` int(11) NOT NULL COMMENT "",
    `lo_supplycost` int(11) NOT NULL COMMENT "",
    `lo_tax` tinyint(4) NOT NULL COMMENT "",
    `lo_commitdate` date NOT NULL COMMENT "",
    `lo_shipmode` varchar(100) NOT NULL COMMENT "",
    `c_name` varchar(100) NOT NULL COMMENT "",
    `c_address` varchar(100) NOT NULL COMMENT "",
    `c_city` varchar(100) NOT NULL COMMENT "",
    `c_nation` varchar(100) NOT NULL COMMENT "",
    `c_region` varchar(100) NOT NULL COMMENT "",
    `c_phone` varchar(100) NOT NULL COMMENT "",
    `c_mktsegment` varchar(100) NOT NULL COMMENT "",
    `s_name` varchar(100) NOT NULL COMMENT "",
    `s_address` varchar(100) NOT NULL COMMENT "",
    `s_city` varchar(100) NOT NULL COMMENT "",
    `s_nation` varchar(100) NOT NULL COMMENT "",
    `s_region` varchar(100) NOT NULL COMMENT "",
    `s_phone` varchar(100) NOT NULL COMMENT "",
    `p_name` varchar(100) NOT NULL COMMENT "",
    `p_mfgr` varchar(100) NOT NULL COMMENT "",
    `p_category` varchar(100) NOT NULL COMMENT "",
    `p_brand` varchar(100) NOT NULL COMMENT "",
    `p_color` varchar(100) NOT NULL COMMENT "",
    `p_type` varchar(100) NOT NULL COMMENT "",
    `p_size` tinyint(4) NOT NULL COMMENT "",
    `p_container` varchar(100) NOT NULL COMMENT ""
)
ENGINE=OLAP 
DUPLICATE KEY(`lo_orderdate`, `lo_orderkey`)
COMMENT "olap"
PARTITION BY RANGE(`lo_orderdate`)
(PARTITION p1 VALUES [('0000-01-01'), ('1993-01-01')),
PARTITION p2 VALUES [('1993-01-01'), ('1994-01-01')),
PARTITION p3 VALUES [('1994-01-01'), ('1995-01-01')),
PARTITION p4 VALUES [('1995-01-01'), ('1996-01-01')),
PARTITION p5 VALUES [('1996-01-01'), ('1997-01-01')),
PARTITION p6 VALUES [('1997-01-01'), ('1998-01-01')),
PARTITION p7 VALUES [('1998-01-01'), ('1999-01-01')))
DISTRIBUTED BY HASH(`lo_orderkey`)
PROPERTIES 
(
    "replication_num" = "3",
    "colocate_with" = "groupxx1",
    "storage_format" = "DEFAULT",
    "enable_persistent_index" = "false",
    "compression" = "LZ4"
);

Следующие два запроса, Q1 и Q2, к таблице lineorder_flat семантически эквивалентны после их обработки следующим образом:

1. Переставить выходные столбцы оператора SELECT.
2. Переставить выходные столбцы предложения GROUP BY.
3. Удалить выходные столбцы предложения ORDER BY.
4. Переставить предикаты в предложении WHERE.
5. Добавить PartitionColumnRangePredicate.

• Q1

  SELECT sum(lo_revenue), year(lo_orderdate) AS year,p_brand
  FROM lineorder_flat
  WHERE p_category = 'MFGR#12' AND s_region = 'AMERICA'
  GROUP BY year,p_brand
  ORDER BY year,p_brand;

• Q2

  SELECT year(lo_orderdate) AS year, p_brand, sum(lo_revenue)
  FROM lineorder_flat
  WHERE s_region = 'AMERICA' AND p_category = 'MFGR#12' AND 
     lo_orderdate >= '1993-01-01' AND lo_orderdate <= '1993-12-31'
  GROUP BY p_brand, year(lo_orderdate)

Семантическая эквивалентность оценивается на основе физических планов запросов. Поэтому буквальные различия в запросах не влияют на оценку семантической эквивалентности. Кроме того, константные выражения удаляются из запросов, а выражения cast удаляются во время оптимизации запросов. Поэтому эти выражения не влияют на оценку семантической эквивалентности. В-третьих, псевдонимы столбцов и отношений также не влияют на оценку семантической эквивалентности.

Запросы с перекрывающимися сканируемыми разделами

Query Cache поддерживает разделение запросов на основе предикатов.

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

Используйте следующую таблицу t0 в качестве примера:

CREATE TABLE if not exists t0
(
    ts DATETIME NOT NULL,
    k0 VARCHAR(10) NOT NULL,
    k1 BIGINT NOT NULL,
    v1 DECIMAL64(7, 2) NOT NULL 
)
ENGINE=OLAP
DUPLICATE KEY(`ts`, `k0`, `k1`)
COMMENT "OLAP"
PARTITION BY RANGE(ts)
(
  START ("2022-01-01 00:00:00") END ("2022-02-01 00:00:00") EVERY (INTERVAL 1 day) 
)
DISTRIBUTED BY HASH(`ts`, `k0`, `k1`)
PROPERTIES
(
    "replication_num" = "3", 
    "storage_format" = "default"
);

Таблица t0 разделена по дням, и столбец ts является столбцом разделения таблицы. Среди следующих четырех запросов Q2, Q3 и Q4 могут повторно использовать части результатов вычислений, кэшированных для Q1:

• Q1

  SELECT date_trunc('day', ts) as day, sum(v0)
  FROM t0
  WHERE ts BETWEEN '2022-01-02 12:30:00' AND '2022-01-14 23:59:59'
  GROUP BY day;

  Диапазон значений, указанный предикатом ts between '2022-01-02 12:30:00' and '2022-01-14 23:59:59' запроса Q1, может быть разделен на следующие интервалы:

  1. [2022-01-02 12:30:00, 2022-01-03 00:00:00),
  2. [2022-01-03 00:00:00, 2022-01-04 00:00:00),
  3. [2022-01-04 00:00:00, 2022-01-05 00:00:00),
  ...
  12. [2022-01-13 00:00:00, 2022-01-14 00:00:00),
  13. [2022-01-14 00:00:00, 2022-01-15 00:00:00),

• Q2

  SELECT date_trunc('day', ts) as day, sum(v0)
  FROM t0
  WHERE ts >= '2022-01-02 12:30:00' AND  ts < '2022-01-05 00:00:00'
  GROUP BY day;

  Q2 может повторно использовать результаты вычислений в следующих интервалах Q1:

  1. [2022-01-02 12:30:00, 2022-01-03 00:00:00),
  2. [2022-01-03 00:00:00, 2022-01-04 00:00:00),
  3. [2022-01-04 00:00:00, 2022-01-05 00:00:00),

• Q3

  SELECT date_trunc('day', ts) as day, sum(v0)
  FROM t0
  WHERE ts >= '2022-01-01 12:30:00' AND  ts <= '2022-01-10 12:00:00'
  GROUP BY day;

  Q3 может повторно использовать результаты вычислений в следующих интервалах Q1:

  2. [2022-01-03 00:00:00, 2022-01-04 00:00:00),
  3. [2022-01-04 00:00:00, 2022-01-05 00:00:00),
  ...
  8. [2022-01-09 00:00:00, 2022-01-10 00:00:00),

• Q4

  SELECT date_trunc('day', ts) as day, sum(v0)
  FROM t0
  WHERE ts BETWEEN '2022-01-02 12:30:00' and '2022-01-02 23:59:59'
  GROUP BY day;

  Q4 может повторно использовать результаты вычислений в следующих интервалах Q1:

  1. [2022-01-02 12:30:00, 2022-01-03 00:00:00),

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

Политика разделения	Поддержка повторного использования частичных результатов вычислений
Unpartitioned	Не поддерживается
Multi-Column Partitioned	Не поддерживается ПРИМЕЧАНИЕ Эта функция может быть поддержана в будущем.
Single-Column Partitioned	Поддерживается

Запросы к данным с изменениями данных только для добавления

Query Cache поддерживает многоверсионное кэширование.

По мере загрузки данных генерируются новые версии tablet'ов. Следовательно, кэшированные результаты вычислений, которые генерируются из предыдущих версий tablet'ов, становятся устаревшими и отстают от последних версий tablet'ов. В этой ситуации механизм многоверсионного кэширования пытается объединить устаревшие результаты, сохраненные в Query Cache, и инкрементальные версии tablet'ов, хранящиеся на диске, в окончательные результаты tablet'ов, чтобы новые запросы могли нести последние версии tablet'ов. Многоверсионное кэширование ограничено типами таблиц, типами запросов и типами обновления данных.

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

Тип таблицы	Тип запроса	Поддержка многоверсионного кэширования
Duplicate Key table	Запросы к базовым таблицам Запросы к синхронным материализованным представлениям	Запросы к базовым таблицам: поддерживается во всех ситуациях, кроме случаев, когда инкрементальные версии tablet'ов содержат записи удаления данных. Запросы к синхронным материализованным представлениям: поддерживается во всех ситуациях, кроме случаев, когда предложения GROUP BY, HAVING или WHERE запросов ссылаются на столбцы агрегации.
Aggregate table	Запросы к базовым таблицам или запросы к синхронным материализованным представлениям	Поддерживается во всех ситуациях, кроме следующих: Схемы базовых таблиц содержат агрегатную функцию replace. Предложения GROUP BY, HAVING или WHERE запросов ссылаются на столбцы агрегации. Инкрементальные версии tablet'ов содержат записи удаления данных.
Unique Key table	Н/Д	Не поддерживается. Однако Query Cache поддерживается.
Primary Key table	Н/Д	Не поддерживается. Однако Query Cache поддерживается.

Влияние типов обновления данных на многоверсионное кэширование следующее:

• Удаления данных

  Многоверсионное кэширование не может работать, если инкрементальные версии tablet'ов содержат операции удаления.

• Вставки данных

  • Если для tablet'а генерируется пустая версия, существующие данные tablet'а в Query Cache остаются действительными и все еще могут быть извлечены.
  • Если для tablet'а генерируется непустая версия, существующие данные tablet'а в Query Cache остаются действительными, но их версия отстает от последней версии tablet'а. В этой ситуации Selena читает инкрементальные данные, сгенерированные от версии существующих данных до последней версии tablet'а, объединяет существующие данные с инкрементальными данными и заполняет объединенные данные в Query Cache.

• Изменения схемы и усечения tablet'ов

  Если схема таблицы изменяется или конкретные tablet'ы таблицы усекаются, для таблицы генерируются новые tablet'ы. В результате существующие данные tablet'ов таблицы в Query Cache становятся недействительными.

Метрики

Профили запросов, для которых работает Query Cache, содержат статистику CacheOperator.

В исходном плане запроса, если pipeline содержит OlapScanOperator, имена OlapScanOperator и агрегатных операторов имеют префикс ML_, чтобы обозначить, что pipeline использует MultilaneOperator для выполнения вычислений по tablet'ам. CacheOperator вставляется перед ML_CONJUGATE_AGGREGATE для обработки логики, которая контролирует, как Query Cache работает в режимах Passthrough, Populate и Probe. Профиль запроса содержит следующие метрики CacheOperator, которые помогают понять использование Query Cache.

Метрика	Описание
CachePassthroughBytes	Количество байтов, сгенерированных в режиме Passthrough.
CachePassthroughChunkNum	Количество chunks, сгенерированных в режиме Passthrough.
CachePassthroughRowNum	Количество строк, сгенерированных в режиме Passthrough.
CachePassthroughTabletNum	Количество tablet'ов, сгенерированных в режиме Passthrough.
CachePassthroughTime:	Количество времени вычислений, затраченного в режиме Passthrough.
CachePopulateBytes	Количество байтов, сгенерированных в режиме Populate.
CachePopulateChunkNum	Количество chunks, сгенерированных в режиме Populate.
CachePopulateRowNum	Количество строк, сгенерированных в режиме Populate.
CachePopulateTabletNum	Количество tablet'ов, сгенерированных в режиме Populate.
CachePopulateTime	Количество времени вычислений, затраченного в режиме Populate.
CacheProbeBytes	Количество байтов, сгенерированных для попаданий в кэш в режиме Probe.
CacheProbeChunkNum	Количество chunks, сгенерированных для попаданий в кэш в режиме Probe.
CacheProbeRowNum	Количество строк, сгенерированных для попаданий в кэш в режиме Probe.
CacheProbeTabletNum	Количество tablet'ов, сгенерированных для попаданий в кэш в режиме Probe.
CacheProbeTime	Количество времени вычислений, затраченного в режиме Probe.

Метрики CachePopulateXXX предоставляют статистику о промахах Query Cache, для которых Query Cache обновляется.

Метрики CachePassthroughXXX предоставляют статистику о промахах Query Cache, для которых Query Cache не обновляется, потому что размер сгенерированных результатов вычислений по tablet'ам большой.

Метрики CacheProbeXXX предоставляют статистику о попаданиях в Query Cache.

В механизме многоверсионного кэширования метрики CachePopulate и метрики CacheProbe могут содержать одинаковую статистику tablet'ов, а метрики CachePassthrough и метрики CacheProbe также могут содержать одинаковую статистику tablet'ов. Например, когда Selena вычисляет данные каждого tablet'а, он попадает в результаты вычислений, сгенерированные на исторической версии tablet'а. В этой ситуации Selena читает инкрементальные данные, сгенерированные от исторической версии до последней версии tablet'а, вычисляет данные и объединяет инкрементальные данные с кэшированными данными. Если размер результатов вычислений, сгенерированных после объединения, не превышает порог, указанный параметром query_cache_entry_max_bytes или query_cache_entry_max_rows, статистика tablet'а собирается в метрики CachePopulate. В противном случае статистика tablet'а собирается в метрики CachePassthrough.

Операции RESTful API

• metrics |grep query_cache

  Эта операция API используется для запроса метрик, связанных с Query Cache.

  curl -s  http://<be_host>:<be_http_port>/metrics |grep query_cache
  
  # TYPE starrocks_be_query_cache_capacity gauge
  starrocks_be_query_cache_capacity 536870912
  # TYPE starrocks_be_query_cache_hit_count gauge
  starrocks_be_query_cache_hit_count 5084393
  # TYPE starrocks_be_query_cache_hit_ratio gauge
  starrocks_be_query_cache_hit_ratio 0.984098
  # TYPE starrocks_be_query_cache_lookup_count gauge
  starrocks_be_query_cache_lookup_count 5166553
  # TYPE starrocks_be_query_cache_usage gauge
  starrocks_be_query_cache_usage 0
  # TYPE starrocks_be_query_cache_usage_ratio gauge
  starrocks_be_query_cache_usage_ratio 0.000000

• api/query_cache/stat

  Эта операция API используется для запроса использования Query Cache.

  curl  http://<be_host>:<be_http_port>/api/query_cache/stat
  {
      "capacity": 536870912,
      "usage": 0,
      "usage_ratio": 0.0,
      "lookup_count": 5025124,
      "hit_count": 4943720,
      "hit_ratio": 0.983800598751394
  }

• api/query_cache/invalidate_all

  Эта операция API используется для очистки Query Cache.

  curl  -XPUT http://<be_host>:<be_http_port>/api/query_cache/invalidate_all
  
  {
      "status": "OK"
  }

Параметры в предыдущих операциях API следующие:

• be_host: IP-адрес узла, на котором находится BE.
• be_http_port: номер HTTP-порта узла, на котором находится BE.

Меры предосторожности

• Selena нужно заполнить Query Cache результатами вычислений запросов, которые инициируются в первый раз. В результате производительность запросов может быть немного ниже ожидаемой, а задержка запросов увеличивается.
• Если вы настроите большой размер Query Cache, количество памяти, которое может быть выделено для оценки запросов на BE, уменьшается. Мы рекомендуем, чтобы размер Query Cache не превышал 1/6 емкости памяти, выделенной для оценки запросов.
• Если количество tablet'ов, которые нужно обработать, меньше значения pipeline_dop, Query Cache не работает. Чтобы включить работу Query Cache, вы можете установить pipeline_dop на меньшее значение, такое как 1. Начиная с версии 1.5.0, Selena адаптивно настраивает этот параметр на основе параллелизма запросов.

Примеры

Набор данных

1. Войдите в ваш кластер Selena, перейдите в целевую базу данных и выполните следующую команду для создания таблицы с именем t0:

   CREATE TABLE t0
   (
         `ts` datetime NOT NULL COMMENT "",
         `k0` varchar(10) NOT NULL COMMENT "",
         `k1` char(6) NOT NULL COMMENT "",
         `v0` bigint(20) NOT NULL COMMENT "",
         `v1` decimal64(7, 2) NOT NULL COMMENT ""
   )
   ENGINE=OLAP 
   DUPLICATE KEY(`ts`, `k0`, `k1`)
   COMMENT "OLAP"
   PARTITION BY RANGE(`ts`)
   (
       START ("2022-01-01 00:00:00") END ("2022-02-01 00:00:00") EVERY (INTERVAL 1 DAY)
   )
   DISTRIBUTED BY HASH(`ts`, `k0`, `k1`)
   PROPERTIES
   (
       "replication_num" = "3",
       "storage_format" = "DEFAULT",
       "enable_persistent_index" = "false"
   );

2. Вставьте следующие записи данных в t0:

   INSERT INTO t0
   VALUES
       ('2022-01-11 20:42:26', 'n4AGcEqYp', 'hhbawx', '799393174109549', '8029.42'),
       ('2022-01-27 18:17:59', 'i66lt', 'mtrtzf', '100400167', '10000.88'),
       ('2022-01-28 20:10:44', 'z6', 'oqkeun', '-58681382337', '59881.87'),
       ('2022-01-29 14:54:31', 'qQ', 'dzytua', '-19682006834', '43807.02'),
       ('2022-01-31 08:08:11', 'qQ', 'dzytua', '7970665929984223925', '-8947.74'),
       ('2022-01-15 00:40:58', '65', 'hhbawx', '4054945', '156.56'),
       ('2022-01-24 16:17:51', 'onqR3JsK1', 'udtmfp', '-12962', '-72127.53'),
       ('2022-01-01 22:36:24', 'n4AGcEqYp', 'fabnct', '-50999821', '17349.85'),
       ('2022-01-21 08:41:50', 'Nlpz1j3h', 'dzytua', '-60162', '287.06'),
       ('2022-01-30 23:44:55', '', 'slfght', '62891747919627339', '8014.98'),
       ('2022-01-18 19:14:28', 'z6', 'dzytua', '-1113001726', '73258.24'),
       ('2022-01-30 14:54:59', 'z6', 'udtmfp', '111175577438857975', '-15280.41'),
       ('2022-01-08 22:08:26', 'z6', 'ympyls', '3', '2.07'),
       ('2022-01-03 08:17:29', 'Nlpz1j3h', 'udtmfp', '-234492', '217.58'),
       ('2022-01-27 07:28:47', 'Pc', 'cawanm', '-1015', '-20631.50'),
       ('2022-01-17 14:07:47', 'Nlpz1j3h', 'lbsvqu', '2295574006197343179', '93768.75'),
       ('2022-01-31 14:00:12', 'onqR3JsK1', 'umlkpo', '-227', '-66199.05'),
       ('2022-01-05 20:31:26', '65', 'lbsvqu', '684307', '36412.49'),
       ('2022-01-06 00:51:34', 'z6', 'dzytua', '11700309310', '-26064.10'),
       ('2022-01-26 02:59:00', 'n4AGcEqYp', 'slfght', '-15320250288446', '-58003.69'),
       ('2022-01-05 03:26:26', 'z6', 'cawanm', '19841055192960542', '-5634.36'),
       ('2022-01-17 08:51:23', 'Pc', 'ghftus', '35476438804110', '13625.99'),
       ('2022-01-30 18:56:03', 'n4AGcEqYp', 'lbsvqu', '3303892099598', '8.37'),
       ('2022-01-22 14:17:18', 'i66lt', 'umlkpo', '-27653110', '-82306.25'),
       ('2022-01-02 10:25:01', 'qQ', 'ghftus', '-188567166', '71442.87'),
       ('2022-01-30 04:58:14', 'Pc', 'ympyls', '-9983', '-82071.59'),
       ('2022-01-05 00:16:56', '7Bh', 'hhbawx', '43712', '84762.97'),
       ('2022-01-25 03:25:53', '65', 'mtrtzf', '4604107', '-2434.69'),
       ('2022-01-27 21:09:10', '65', 'udtmfp', '476134823953365199', '38736.04'),
       ('2022-01-11 13:35:44', '65', 'qmwhvr', '1', '0.28'),
       ('2022-01-03 19:13:07', '', 'lbsvqu', '11', '-53084.04'),
       ('2022-01-20 02:27:25', 'i66lt', 'umlkpo', '3218824416', '-71393.20'),
       ('2022-01-04 04:52:36', '7Bh', 'ghftus', '-112543071', '-78377.93'),
       ('2022-01-27 18:27:06', 'Pc', 'umlkpo', '477', '-98060.13'),
       ('2022-01-04 19:40:36', '', 'udtmfp', '433677211', '-99829.94'),
       ('2022-01-20 23:19:58', 'Nlpz1j3h', 'udtmfp', '361394977', '-19284.18'),
       ('2022-01-05 02:17:56', 'Pc', 'oqkeun', '-552390906075744662', '-25267.92'),
       ('2022-01-02 16:14:07', '65', 'dzytua', '132', '2393.77'),
       ('2022-01-28 23:17:14', 'z6', 'umlkpo', '61', '-52028.57'),
       ('2022-01-12 08:05:44', 'qQ', 'hhbawx', '-9579605666539132', '-87801.81'),
       ('2022-01-31 19:48:22', 'z6', 'lbsvqu', '9883530877822', '34006.42'),
       ('2022-01-11 20:38:41', '', 'piszhr', '56108215256366', '-74059.80'),
       ('2022-01-01 04:15:17', '65', 'cawanm', '-440061829443010909', '88960.51'),
       ('2022-01-05 07:26:09', 'qQ', 'umlkpo', '-24889917494681901', '-23372.12'),
       ('2022-01-29 18:13:55', 'Nlpz1j3h', 'cawanm', '-233', '-24294.42'),
       ('2022-01-10 00:49:45', 'Nlpz1j3h', 'ympyls', '-2396341', '77723.88'),
       ('2022-01-29 08:02:58', 'n4AGcEqYp', 'slfght', '45212', '93099.78'),
       ('2022-01-28 08:59:21', 'onqR3JsK1', 'oqkeun', '76', '-78641.65'),
       ('2022-01-26 14:29:39', '7Bh', 'umlkpo', '176003552517', '-99999.96'),
       ('2022-01-03 18:53:37', '7Bh', 'piszhr', '3906151622605106', '55723.01'),
       ('2022-01-04 07:08:19', 'i66lt', 'ympyls', '-240097380835621', '-81800.87'),
       ('2022-01-28 14:54:17', 'Nlpz1j3h', 'slfght', '-69018069110121', '90533.64'),
       ('2022-01-22 07:48:53', 'Pc', 'ympyls', '22396835447981344', '-12583.39'),
       ('2022-01-22 07:39:29', 'Pc', 'uqkghp', '10551305', '52163.82'),
       ('2022-01-08 22:39:47', 'Nlpz1j3h', 'cawanm', '67905472699', '87831.30'),
       ('2022-01-05 14:53:34', '7Bh', 'dzytua', '-779598598706906834', '-38780.41'),
       ('2022-01-30 17:34:41', 'onqR3JsK1', 'oqkeun', '346687625005524', '-62475.31'),
       ('2022-01-29 12:14:06', '', 'qmwhvr', '3315', '22076.88'),
       ('2022-01-05 06:47:04', 'Nlpz1j3h', 'udtmfp', '-469', '42747.17'),
       ('2022-01-19 15:20:20', '7Bh', 'lbsvqu', '347317095885', '-76393.49'),
       ('2022-01-08 16:18:22', 'z6', 'fghmcd', '2', '90315.60'),
       ('2022-01-02 00:23:06', 'Pc', 'piszhr', '-3651517384168400', '58220.34'),
       ('2022-01-12 08:23:31', 'onqR3JsK1', 'udtmfp', '5636394870355729225', '33224.25'),
       ('2022-01-28 10:46:44', 'onqR3JsK1', 'oqkeun', '-28102078612755', '6469.53'),
       ('2022-01-23 23:16:11', 'onqR3JsK1', 'ghftus', '-707475035515433949', '63422.66'),
       ('2022-01-03 05:32:31', 'z6', 'hhbawx', '-45', '-49680.52'),
       ('2022-01-27 03:24:33', 'qQ', 'qmwhvr', '375943906057539870', '-66092.96'),
       ('2022-01-25 20:07:22', '7Bh', 'slfght', '1', '72440.21'),
       ('2022-01-04 16:07:24', 'qQ', 'uqkghp', '751213107482249', '16417.31'),
       ('2022-01-23 19:22:00', 'Pc', 'hhbawx', '-740731249600493', '88439.40'),
       ('2022-01-05 09:04:20', '7Bh', 'cawanm', '23602', '302.44');

Примеры запросов

Статистика метрик, связанных с Query Cache, в этом разделе является примерами и предназначена только для справки.

Query Cache работает для локальных агрегаций на этапе 1

Это включает три ситуации:

• Запрос обращается только к одному tablet'у.
• Запрос обращается к нескольким tablet'ам из нескольких разделов таблицы, которая сама составляет colocated group, и данные не нужно перемешивать для агрегаций.
• Запрос обращается к нескольким tablet'ам из одного раздела таблицы, и данные не нужно перемешивать для агрегаций.

Пример запроса:

SELECT
    date_trunc('hour', ts) AS hour,
    k0,
    sum(v1) AS __c_0
FROM
    t0
WHERE
    ts between '2022-01-03 00:00:00'
    and '2022-01-03 23:59:59'
GROUP BY
    date_trunc('hour', ts),
    k0

Следующий рисунок показывает метрики, связанные с Query Cache, в профиле запроса.

Query Cache не работает для удаленных агрегаций на этапе 1

Когда агрегации на нескольких tablet'ах принудительно выполняются на этапе 1, данные сначала перемешиваются, а затем агрегируются.

Пример запроса:

SET new_planner_agg_stage = 1;

SELECT
    date_trunc('hour', ts) AS hour,
    v0 % 2 AS is_odd,
    sum(v1) AS __c_0
FROM
    t0
WHERE
    ts between '2022-01-03 00:00:00'
    and '2022-01-03 23:59:59'
GROUP BY
    date_trunc('hour', ts),
    is_odd

Query Cache работает для локальных агрегаций на этапе 2

Это включает три ситуации:

• Агрегации на этапе 2 запроса компилируются для сравнения одного типа данных. Первая агрегация — это локальная агрегация. После завершения первой агрегации результаты, сгенерированные из первой агрегации, вычисляются для выполнения второй агрегации, которая является глобальной агрегацией.
• Запрос — это запрос SELECT DISTINCT.
• Запрос включает одну из следующих DISTINCT агрегатных функций: sum(distinct), count(distinct) и avg(distinct). В большинстве случаев агрегации выполняются на этапе 3 или 4 для такого запроса. Однако вы можете выполнить set new_planner_agg_stage = 1, чтобы принудительно выполнить агрегации на этапе 2 для запроса. Если запрос содержит avg(distinct) и вы хотите выполнить агрегации на этапе, вам также нужно выполнить set cbo_cte_reuse = false, чтобы отключить оптимизации CTE.

Пример запроса:

SELECT
    date_trunc('hour', ts) AS hour,
    v0 % 2 AS is_odd,
    sum(v1) AS __c_0
FROM
    t0
WHERE
    ts between '2022-01-03 00:00:00'
    and '2022-01-03 23:59:59'
GROUP BY
    date_trunc('hour', ts),
    is_odd

Следующий рисунок показывает метрики, связанные с Query Cache, в профиле запроса.

Query Cache работает для локальных агрегаций на этапе 3

Запрос — это GROUP BY агрегатный запрос, который включает одну DISTINCT агрегатную функцию.

Поддерживаемые DISTINCT агрегатные функции: sum(distinct), count(distinct) и avg(distinct).

УВЕДОМЛЕНИЕ

Если запрос включает avg(distinct), вам также нужно выполнить set cbo_cte_reuse = false, чтобы отключить оптимизации CTE.

Пример запроса:

SELECT
    date_trunc('hour', ts) AS hour,
    v0 % 2 AS is_odd,
    sum(distinct v1) AS __c_0
FROM
    t0
WHERE
    ts between '2022-01-03 00:00:00'
    and '2022-01-03 23:59:59'
GROUP BY
    date_trunc('hour', ts),
    is_odd;

Следующий рисунок показывает метрики, связанные с Query Cache, в профиле запроса.

Query Cache работает для локальных агрегаций на этапе 4

Запрос — это агрегатный запрос без GROUP BY, который включает одну DISTINCT агрегатную функцию. Такие запросы включают классические запросы, которые удаляют дублированные данные.

Пример запроса:

SELECT
    count(distinct v1) AS __c_0
FROM
    t0
WHERE
    ts between '2022-01-03 00:00:00'
    and '2022-01-03 23:59:59'

Следующий рисунок показывает метрики, связанные с Query Cache, в профиле запроса.

Кэшированные результаты повторно используются для двух запросов, чьи первые агрегации семантически эквивалентны

Используйте следующие два запроса, Q1 и Q2, в качестве примера. Q1 и Q2 оба включают несколько агрегаций, но их первые агрегации семантически эквивалентны. Поэтому Q1 и Q2 оцениваются как семантически эквивалентные и могут повторно использовать результаты вычислений друг друга, сохраненные в Query Cache.

• Q1

  SELECT
      (
          ifnull(sum(murmur_hash3_32(hour)), 0) + ifnull(sum(murmur_hash3_32(k0)), 0) + ifnull(sum(murmur_hash3_32(__c_0)), 0)
        ) AS fingerprint
  FROM
      (
          SELECT
              date_trunc('hour', ts) AS hour,
              k0,
              sum(v1) AS __c_0
          FROM
              t0
          WHERE
              ts between '2022-01-03 00:00:00'
              and '2022-01-03 23:59:59'
          GROUP BY
              date_trunc('hour', ts),
              k0
      ) AS t;

• Q2

  SELECT
      date_trunc('hour', ts) AS hour,
      k0,
      sum(v1) AS __c_0
  FROM
      t0
  WHERE
      ts between '2022-01-03 00:00:00'
      and '2022-01-03 23:59:59'
  GROUP BY
      date_trunc('hour', ts),
      k0

Следующий рисунок показывает метрики CachePopulate для Q1.

Следующий рисунок показывает метрики CacheProbe для Q2.

Query Cache не работает для DISTINCT запросов, для которых включены оптимизации CTE

После выполнения set cbo_cte_reuse = true для включения оптимизаций CTE результаты вычислений для конкретных запросов, которые включают DISTINCT агрегатные функции, не могут быть кэшированы. Несколько примеров следующие:

• Запрос содержит одну DISTINCT агрегатную функцию avg(distinct):

  SELECT
      avg(distinct v1) AS __c_0
  FROM
      t0
  WHERE
      ts between '2022-01-03 00:00:00'
      and '2022-01-03 23:59:59';

• Запрос содержит несколько DISTINCT агрегатных функций, которые ссылаются на один и тот же столбец:

  SELECT
      avg(distinct v1) AS __c_0,
      sum(distinct v1) AS __c_1,
      count(distinct v1) AS __c_2
  FROM
      t0
  WHERE
      ts between '2022-01-03 00:00:00'
      and '2022-01-03 23:59:59';

• Запрос содержит несколько DISTINCT агрегатных функций, каждая из которых ссылается на разный столбец:

  SELECT
      sum(distinct v1) AS __c_1,
      count(distinct v0) AS __c_2
  FROM
      t0
  WHERE
      ts between '2022-01-03 00:00:00'
      and '2022-01-03 23:59:59';

Лучшие практики

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

• Выберите один столбец типа DATE в качестве столбца раздела. Если таблица содержит более одного столбца типа DATE, выберите столбец, значения которого продвигаются вперед по мере инкрементального поступления данных и который используется для определения интересующих временных диапазонов ваших запросов.
• Выберите подходящую ширину раздела. Данные, поступившие совсем недавно, могут изменить последние разделы таблицы. Поэтому записи кэша, включающие последние разделы, нестабильны и склонны к аннулированию.
• Укажите количество bucket'ов, которое составляет несколько десятков в описании распределения оператора создания таблицы. Если количество bucket'ов чрезмерно мало, Query Cache не может вступить в силу, когда количество tablet'ов, которые нужно обработать BE, меньше значения pipeline_dop.