Перейти к основному содержимому
Перейти к основному содержимому

Анализатор

Известные несовместимости​

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

Недействительные запросы больше не оптимизируются​

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

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

Пример 1:

Следующий запрос использует колонку number в списке проекции, когда доступно только toString(number) после агрегации. В старом анализаторе GROUP BY toString(number) был оптимизирован в GROUP BY number, что делало запрос действительным.

Пример 2:

Та же проблема возникает и в этом запросе: колонка number используется после агрегации с другим ключом. Предыдущий анализатор запросов исправил этот запрос, переместив фильтр number > 5 из секции HAVING в секцию WHERE.

Чтобы исправить запрос, вам следует переместить все условия, которые относятся к неагрегированным колонкам, в секцию WHERE, чтобы соответствовать стандартному синтаксису SQL:

CREATE VIEW с недействительным запросом​

Новый анализатор всегда выполняет проверку типов. Ранее было возможно создать VIEW с недействительным SELECT запросом. Он затем терпел неудачу при первом SELECT или INSERT (в случае MATERIALIZED VIEW).

Теперь невозможно создать такие VIEW больше.

Пример:

Известные несовместимости оператора JOIN​

Соединение с использованием колонки из проекции​

Псевдонимы из списка SELECT не могут использоваться в качестве ключа JOIN USING по умолчанию.

Новая настройка, analyzer_compatibility_join_using_top_level_identifier, при включении изменяет поведение JOIN USING, предпочитая разрешать идентификаторы на основе выражений из списка проекции запроса SELECT, а не используя колонки из левой таблицы напрямую.

Пример:

При установленной analyzer_compatibility_join_using_top_level_identifier в значение true, условие соединения интерпретируется как t1.a + 1 = t2.b, соответствуя поведению предыдущих версий. Таким образом, результатом будет 2, 'two'. Когда настройка false, условие соединения по умолчанию становится t1.b = t2.b, и запрос вернет 2, 'one'. Если b отсутствует в t1, запрос завершится с ошибкой.

Изменения в поведении с JOIN USING и ALIAS/MATERIALIZED колонками​

В новом анализаторе использование * в запросе JOIN USING, который включает колонки ALIAS или MATERIALIZED, будет по умолчанию включать эти колонки в результирующий набор.

Пример:

В новом анализаторе результат этого запроса будет включать колонку payload вместе с id из обеих таблиц. В отличие от этого, предыдущий анализатор включал бы эти колонки ALIAS только если были включены определенные настройки (asterisk_include_alias_columns или asterisk_include_materialized_columns), и колонки могли бы появляться в другом порядке.

Чтобы гарантировать согласованные и ожидаемые результаты, особенно при миграции старых запросов на новый анализатор, рекомендуется явно указывать колонки в секции SELECT, а не использовать *.

Обработка модификаторов типов для колонок в секции USING​

В новой версии анализатора правила определения общего супертайпа для колонок, указанных в секции USING, были стандартизированы для того, чтобы генерировать более предсказуемые результаты, особенно при работе с модификаторами типа, такими как LowCardinality и Nullable.

  • LowCardinality(T) и T: Когда колонка типа LowCardinality(T) соединяется с колонкой типа T, результирующий общий супертайп будет T, эффективно отбрасывая модификатор LowCardinality.

  • Nullable(T) и T: Когда колонка типа Nullable(T) соединяется с колонкой типа T, результирующий общий супертайп будет Nullable(T), что гарантирует сохранение свойства nullable.

Пример:

В этом запросе общий супертайп для id определяется как String, отбрасывая модификатор LowCardinality из t1.

Изменения названий колонок проекции​

Во время вычисления названий проекций псевдонимы не заменяются.

Несовместимые типы аргументов функций​

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

Пример:

Следующий запрос завершается неудачей с ошибкой There is no supertype for types Array(UInt8), String because some of them are Array and some of them are not:

Гетерогенные кластеры​

Новый анализатор значительно изменил протокол взаимодействия между серверами в кластере. Таким образом, невозможно выполнять распределенные запросы на серверах с различными значениями настройки enable_analyzer.

Мутации интерпретируются предыдущим анализатором​

Мутации все еще используют старый анализатор. Это означает, что некоторые новые функции SQL ClickHouse не могут использоваться в мутациях. Например, оператор QUALIFY. Статус можно проверить здесь.

Не поддерживаемые функции​

Список функций, которые новый анализатор в настоящее время не поддерживает:

  • Индекс Annoy.
  • Индекс Hypothesis. Работа в процессе здесь.
  • Окно представления не поддерживается. В будущем нет планов на его поддержку.