которые крупные- много статей на тему выпускают

Добрый день коллеги возникла проблема с написанием запроса в clickhouse.
есть таблица progress_documents вида

session_id uuid  - идентификатор сессии
document_id int -  номер документа в обработке
server_time data_time -  серверное время
state boolean  - статус
server_date date- дата

Записи в неё добавляются каждые 30с.
Необходимо
1. Для всех session_id вычислить время обработки документа (взять разность server_time двух соседних записей и все такие разности просумировать).
в одной сесси могут обрабатываться несколько документов.

Моя идея была в том что бы брать соседние записи с помощью функции neighbor и затем суммировать
select sum(server_time - next_ts) as result from (select server_time, neighbor(server_time, 1, NULL) as next_server_time from progress_documents

Вопрос как сделать это для всех session_id и всех document_id. Буду благодарен за любые подсказки

Проверять session_id и document_id соседней записи и обрабатывать в зависимости изменились или нет

Здравствуйте, товарищи.

Вопрос по выборке и хранению данных в InfluxDB

Есть ли возможность как-то ускорить текущую выборку или оптимизировать структуру хранения данных?

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

https://pastebin.com/0aB2efPT

Обычно в этом помогают индексы

я, честно говоря, не уверен, что я правильно организовал структуру базы. Или правильно использую join. Чудовищно медленно получается по 4 секунды на запрос

Ну, тогда шли структуру, запрос и время выполнения.

Что за ин-флюс я конечно не знаю, но если это реляционная БД, это не важно

это TSDB

структуру сейчас нарисую, запрос в пасте

А, это не запрос, я это не смогу

это запрос на Flux. Выглядит вот так вот чудовищно

SQL-like influxQL они дропнули в последней версии

Индекс есть по
["_start", "_stop", "_time", "guest_session_id", "user_id", "username"]

?

да

это тэги - индексируемые поля

Составной из 6 полей?

нужно уточнить как это работает, возможно, нет

Уточняй, и это у тебя в нескольких таблицах

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