Спасибо, очень ценный комментарий! Более сжато, но в "подводных камнях" подсветил и предложил решение по проблемам 1 и 3: разбивать данные на партии (например, грузить по месяцам или более короткий промежуток, искать баланс производительности).
В целом, как вы правильно сказали — всё зависит от масштаба, характера данных и конкретной задачи. Если аккуратно управлять размерами и понимать компромиссы, можно получить прирост в x2 и более, а также сэкономить память. Но если просто “включить массивы везде” — можно легко сделать только хуже.
В нашем кейсе мы хотим не просто “найти машины, по котором были превышения”, а привязать каждое превышение к конкретной аренде, чтобы определить нарушителя. А для этого уже нужно сопоставить временные интервалы телеметрии и заказов — вот тут и начинаются сложности. Простого джоина по ключу недостаточно, приходится искать пересечения по времени.
Про производительность — в конце статьи есть таблица с замерами. Можно проверить на своих или тестовых данных, что работает лучше :)
SUM(gmv) OVER (PARTITION BY car_id ORDER BY order_created_at DESC RANGE BETWEEN INTERVAL '24' HOUR PRECEDING AND CURRENT ROW) AS NEXT_24_HOURS_GMV_SUM
Было бы интересно замерить разницу в производительности между этими тремя методами) Но а так да, в условиях отсутствия функционала БД пришлось изобретать решение)
Это была проверка на внимательность.) Спасибо!
Спасибо, очень ценный комментарий! Более сжато, но в "подводных камнях" подсветил и предложил решение по проблемам 1 и 3: разбивать данные на партии (например, грузить по месяцам или более короткий промежуток, искать баланс производительности).
В целом, как вы правильно сказали — всё зависит от масштаба, характера данных и конкретной задачи. Если аккуратно управлять размерами и понимать компромиссы, можно получить прирост в x2 и более, а также сэкономить память. Но если просто “включить массивы везде” — можно легко сделать только хуже.
В нашем кейсе мы хотим не просто “найти машины, по котором были превышения”, а привязать каждое превышение к конкретной аренде, чтобы определить нарушителя. А для этого уже нужно сопоставить временные интервалы телеметрии и заказов — вот тут и начинаются сложности. Простого джоина по ключу недостаточно, приходится искать пересечения по времени.
Про производительность — в конце статьи есть таблица с замерами. Можно проверить на своих или тестовых данных, что работает лучше :)
Да, в Exasol, к примеру, задача решалась бы как:
SUM(gmv) OVER (PARTITION BY car_id ORDER BY order_created_at DESC RANGE BETWEEN INTERVAL '24' HOUR PRECEDING AND CURRENT ROW) AS NEXT_24_HOURS_GMV_SUM
Было бы интересно замерить разницу в производительности между этими тремя методами) Но а так да, в условиях отсутствия функционала БД пришлось изобретать решение)