Добрый день! Недавно наша компания начала пытаться в кликхаус. И у меня

возник вопрос - а правильно ли мы его используем?
Суть такова:
(упрощённо) У нас есть рейсы по заказам с мунициаплитетом и назначенными на них машинами (municipality_uuid -> order_uuid -> run_uuid -> vehicle_uuid)
vehicle_uuid может меняться.
Мы создали таблицу с сырыми данными по изменениям order_runs_raw с полями municipality_uuid, order_uuid, run_uuid, vehicle_uuid, updated_at
Для этой таблицы матвьюху order_runs с полями municipality_uuid, order_uuid, run_uuid, argMaxState(vehicle_uuid, order_runs_raw.updated_at), maxState(updated_at) ORDER BY municipality_uuid, order_uuid, run_uuid
для того чтобы иметь актуальный vehicle_uuid для каждого рейса в соответствии с последними изменениями

Далее возникла задача выводить изменения по разным часам
матвьюха order_runs_hourly с полями municipality_uuid, order_uuid, run_uuid, toStartOfHour(updated_at) as updated_at_hour, argMaxState(vehicle_uuid, order_runs_raw.updated_at), maxState(updated_at) ORDER BY municipality_uuid, order_uuid, run_uuid, updated_at_hour

Далее необходимо для различных уровней агрегации выводить список используемых в рейсах за час машин (при чём за последний updated_at в часу, а не все машины вместе с заменёнными)
Т.е. нужна матвьюха типа municipality_uuid, order_uuid, updated_at_hour, массивМашин ORDER BY municipality_uuid, order_uuid, updated_at_hour

Не могу понять как реализовать последнюю вьюху да и правильный ли вообще подход

> (упрощённо) У нас есть рейсы по заказам с мунициаплитетом и назначенными на них машинами (municipality_uuid -> order_uuid -> run_uuid -> vehicle_uuid) Вы обеспечиваете рейсами муниципалитеты небольшой галактики?) если вам необходимо использовать 16 байтовый айди? > для того чтобы иметь актуальный vehicle_uuid для каждого рейса в соответствии с последними изменениями Почему не replacingMergeTree И сколько у вас вообще строк в таблице?

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

MV и тд это тоже просто insert trigger и удаляет в фоне https://kb.altinity.com/altinity-kb-schema-design/materialized-views/

выбирайте последние данные всегда, и у вас не будет дубликатов

используйте SELECT ... FINAL дубликаты будут удаляться из результатов выборки

а FINAL сильно влияет на производительность запроса ?

а сколько строк у вас в таблице? может вам clickhouse вообще не нужен?

https://kb.altinity.com/altinity-kb-queries-and-syntax/altinity-kb-final-clause-speed/ https://kb.altinity.com/engines/mergetree-table-engine-family/replacingmergetree/ Зависит от обстоятельств

от нескольких сотен до пара тысяч ордеров в день, в каждом из них по сотне рейсов

у меня около трёх миллиардов, но вопрос не про меня. Я тоже использую MV у которых данные схлопываются. и почему-то FINAL не использую, хотя наверное можно было бы попробовать.

спасибо, проверим на наших кейсах после обновления до свежей lts

я не про MV я про ReplacingMergeTree выборка из этой таблицы если у вас возможны дубликаты в разных вставках, должна быть с FINAL либо всякие там any, argMin , argMax функции использовать

да, я как раз использую argMax.

А чем собственно может помочь ReplacingMergeTree? Из-за того что запрос во вьюхах выполняется только в рамках вставляемых данных - в массив во вьюхе будут попадать все значения, т.к. массив то сам из себя старые значения удалять не будет