Анализатор

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

В версии 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 Clause

В новой версии анализатора правила определения общего суперттипа для колонок, указанных в клаузе 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.
• Индекс гипотез. Работа в процессе здесь.
• Оконное представление не поддерживается. Нет планов поддерживать его в будущем.