KLIP 54 — Оптимизация запросов на извлечение диапазона

Автор: Патрик Штуди (@pstuedi) | Целевая версия: 0.22.0; 7.1.0 | Статус: Объединён | Обсуждение: https://github.com/confluentinc/ksql/pull/7993

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

Мотивация и предпосылки

В настоящее время запросы на диапазон по первичным ключам (например, WHERE colX < T) реализуются с помощью сканирования таблицы с последующей операцией фильтрации, что неэффективно. Недавно в Kafka Streams были добавлены возможности сканирования диапазона (KAFKA-4064). После этой работы мы должны оптимизировать выполнение запросов на диапазон в ksqlDB, напрямую используя специальный интерфейс запроса диапазона для повышения эффективности ввода-вывода и производительности.

Что входит в область действия

• Запросы на извлечение по таблицам с предложением WHERE, включающим выражения «>», «>=», «<», «<=», должны выполняться с использованием интерфейса диапазона в хранилище состояний. Существуют ограничения на то, когда эту оптимизацию можно применять. См. следующий раздел.

Что не входит в область действия

• Запросы с конъюнкциями или дизъюнкциями выражений диапазона не будут оптимизированы с помощью методов, предложенных в этом KLIP, но вместо этого мы будем использовать сканирование таблиц для таких запросов. В будущем мы планируем оптимизировать запросы с несколькими выражениями диапазона путём объединения различных выражений диапазона в меньшее количество выражений, что приведёт к меньшему количеству вызовов диапазона в хранилище состояний.
• Существует возможность нескольких физических оптимизаций плана вокруг запросов диапазона, таких как пропуск избыточной фильтрации в операторах выбора. Такие оптимизации не являются частью этого KLIP.
• В настоящее время область применения этого KLIP ограничена строковыми типами ключей. Причина этого в том, что по умолчанию компаратор в rocksdb является лексикографическим, поэтому порядок двоичных типов ключей, таких как целые числа, семантически не будет правильным. Например, отрицательные целые числа, представленные в формате дополнения до двух, могут оказаться больше некоторых положительных целых чисел. На данный момент мы ограничиваем оптимизацию сканирования диапазона строковыми типами ключей. В будущем мы планируем добавить поддержку двоичных ключей.

Ценность/возврат

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

Публичные API

Новый синтаксис не добавляется.

Дизайн

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

1. Генерировать KeyConstrains для выражений диапазона (вместо NoKeyConstraints).
2. Включить существующий KeyedTableLookupOperator для обработки KeyConstraints типа «<», «<=», «>», «>».
3. Добавить поддержку сканирования диапазона в материализацию ksqlDB.

План тестирования

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

Обновления документации

• Обновлений документации не требуется.

Последствия совместимости

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

Последствия для безопасности

Ожидаемых последствий для безопасности нет.