Comments 15
Почему при stream+table когда приходит со стороны table нету тригера? что это за бред?
Например у нас полностью асинхронный сайт:
1) добавляются видео (генерим guid, отправляем в очередь)
2) в UI можно сделать сразу допустим like (отправляем в очередь) (не придирайтесь я для простаты восприятия).
окей для видео TABLE — всё логично.
НО специально делать table для лайков вместо stream, из за того что не можем гарантировать кто первый придет, это бред!
Во-вторых, Kafka Streams API писали не мы, возмущаться тут бессмысленно.
Не нашел примерные нагрузки. Не поделитесь что летает на такой конфигурации ПО и хардваре, приемные цифры потоков?
Точных цифр по памяти сейчас не назову, надо лезть, смотреть и считать.
В целом, вопрос нагрузки интересный, вас что именно интересует? Если смотреть на голые цифры количества событий на вход и на выход, будет не очень много, но это ни о чем не скажет. Внутри происходят сложные вычисления в режиме реального времени с кучей джойнов и агрегатов, что создаёт почти всю нагрузку на кластер.
С проблемой RocksDb на HDD мы тоже столкнулись и в итоге перенесли хранение стора в tmpfs. Подскажите как вы реализуете деплой без потери данных? По сути когда меняешь структуру стрима, то меняется структура хранения в сторе и новая версия приложения с ней уже не совоместима? Или с ksql таких проблем нет?
Почему стриминг на KSQL и Kafka Streams — это непросто