KLIP 53 — Pull-запросы к потокам

Автор: Джон Реслер (@vvcephei) | Целевая версия: 0.23.1; 7.1.0 | Статус: объединён | Обсуждение: ссылка на PR с обсуждением дизайна

Краткое содержание: Пользователи должны иметь возможность выполнять pull-запросы (специальные, самозавершающиеся) к потокам, так же как и к таблицам.

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

ksqlDB позволяет создавать как pull-запросы (которые выполняются по запросу и работают до завершения, как типичные запросы к базе данных), так и push-запросы (долго выполняющиеся подписки, которые возвращают результаты непрерывно по мере поступления новых входных данных).

В ksqlDB также есть двойная модель данных «таблица/поток». Можно выполнять push-запросы для таблиц и потоков, а также pull-запросы для таблиц, но в настоящее время нельзя выполнять pull-запросы для потоков.

Ранее мы считали ненужным реализовывать pull-запросы для потоков, поскольку для потока «текущее состояние» эквивалентно всей истории записей. Другими словами, pull-запрос к потоку вернёт то же самое, что и push-запрос, если он настроен на начало потока и отменён после достижения конца.

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

Что входит в рамки проекта

• Запросы должны поддерживаться для объектов STREAM без «EMIT CHANGES» в конце.
• Pull-запросы должны начинаться с начала потока.
• Pull-запросы должны завершаться. Потоки по определению не имеют «конца», поэтому нам нужно определить момент завершения запроса. Когда вы отправляете запрос, ksqlDB просканирует все данные, которые в данный момент находятся в истории потока, и затем завершится, не дожидаясь дополнительных данных.
• Pull-запросы к потокам будут поддерживать тот же диапазон операций запроса, что и для таблиц. Другими словами, вы сможете фильтровать поток с помощью предложения WHERE.

Что не входит в рамки проекта

• В настоящее время pull-запросы к потокам не будут поддерживать группировку/агрегацию или объединения. Это было бы полезно, но оставлено для будущей работы. Обратите внимание, что ни агрегация, ни объединение в настоящее время не поддерживаются для pull-запросов к таблицам.
• Если старые записи уже были удалены из потока из-за настроек хранения, они не будут включены в результаты.
• Сканирование потока может включать или не включать некоторые новые записи, поступающие во время выполнения запроса. Единственное, что гарантируется, — это то, что запрос будет включать все записи, которые уже находятся в потоке в начале запроса. При желании мы можем сделать конечную точку более строгой в будущем.

Ценность/результат

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

Общедоступные API

Новый синтаксис не добавляется. Единственное изменение заключается в том, что запросы к объектам потока больше не должны заканчиваться на «EMIT CHANGES».

Дизайн

Чтобы поддержать полную выразительность запросов ksqlDB, текущий дизайн состоит в том, чтобы просто рассматривать pull-запросы к потокам как синтаксический сахар. Внутренне мы будем:

1. Создавать типичный push-запрос.
2. Настраивать запрос на запуск с «самого раннего» (начала потока).
3. Определять конечные смещения разделов потока.
4. Запускать push-запрос.
5. Следить за ходом выполнения запроса. После достижения или превышения всех смещений в шаге 3 завершать запрос.

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

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

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

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

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

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

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