У нас много полей, c with получался более лаконичный код, но можно и без него, конечно. Про неправильный код Вы зря, всё таки схема рабочая, а про with и особенность join я упомянул, не захотел писать только чтоб статью сильно не раздувать деталями, хотя может Вы и правы, стоило.
Вы, возможно, не обратили внимание на мою оговорку в статье насчёт тяжёлых join, я этот момент затронул. Выходом для нас стало использование with (хотя можно из без него). То что вы говорите верно, если не учесть этот момент, и мы его учли, за счёт чего join для нас стал приемлемым.
Нагрузочное тестирование проводили. Конечно, если в таблицах будет много записей, порядка 1 млрд., вставка больших пачек, скажем 1 млн., будет занимать минуты. И всё будет зависеть от того, устраивает Вас это или нет. У нас не так много новых записей, в сутки до 10 млн., поэтому join-ы не такие тяжёлые, потому что join будет с таблицей в которое количество записей такое, какую пачку выбрал консюмер из Kafka. К тому же сортировку в таблицах мы подбирали так, чтобы join-ы выполнялись как можно более быстро. Разница в скорости в итоге от первого варианта до итогового была ощутимая, если правильно помню около 1.5 раз. В любом случае как общий подход наше решение советовать не стану, нужно исходить из Ваших конкретных условий. Нагрузка, железо и прочее.
Какую задачу Вы имеете ввиду? Для задачи в целом нет. Если под задачей понимать какую-либо часть обработки в "конвейере", то его можно использовать для уменьшения количества записей. Собственно, мы его аналог используем в таблице metrics_agg.
У нас много полей, c with получался более лаконичный код, но можно и без него, конечно.
Про неправильный код Вы зря, всё таки схема рабочая, а про with и особенность join я упомянул, не захотел писать только чтоб статью сильно не раздувать деталями, хотя может Вы и правы, стоило.
Вы, возможно, не обратили внимание на мою оговорку в статье насчёт тяжёлых join, я этот момент затронул. Выходом для нас стало использование with (хотя можно из без него). То что вы говорите верно, если не учесть этот момент, и мы его учли, за счёт чего join для нас стал приемлемым.
Нагрузочное тестирование проводили. Конечно, если в таблицах будет много записей, порядка 1 млрд., вставка больших пачек, скажем 1 млн., будет занимать минуты. И всё будет зависеть от того, устраивает Вас это или нет. У нас не так много новых записей, в сутки до 10 млн., поэтому join-ы не такие тяжёлые, потому что join будет с таблицей в которое количество записей такое, какую пачку выбрал консюмер из Kafka. К тому же сортировку в таблицах мы подбирали так, чтобы join-ы выполнялись как можно более быстро. Разница в скорости в итоге от первого варианта до итогового была ощутимая, если правильно помню около 1.5 раз.
В любом случае как общий подход наше решение советовать не стану, нужно исходить из Ваших конкретных условий. Нагрузка, железо и прочее.
Какую задачу Вы имеете ввиду? Для задачи в целом нет. Если под задачей понимать какую-либо часть обработки в "конвейере", то его можно использовать для уменьшения количества записей. Собственно, мы его аналог используем в таблице metrics_agg.