Comments 2
Возможно вопрос более подходит к вашей предыдущий стать. Вот на примере лайков. Flink как вы пишете работает без batch в реальном времени и т д.
Считаем лайки (суммируем по статьям). Внутри flink они инкрементируются обрабатывая сообщение за сообщением. И есть sink в базу например mongo. И как они в базу пишутся ? Также на каждый лайк происходит update в базу данных? Это же создаст туже нагрузку что я просто буду писать напрямую в базу update like++. Посмотрел параметры в настройках sink для mongo , там есть параметры таймаутов, размеров буферов и т д. Но ничего связанного с решением описанной проблемы.
Так вот мне flink не подходит и мне нужно переходить как раз на batch по типу spark?
Или это какие то сложные ручные Processorы надо писать чтобы они делали flush в бд с условиями 'или изменения за 1 минуту или накопили 1000 записей на update'
0
Немного задержался с ответом... Именно с коннектором mongo у меня опыта не было, но общий принцип в том, что у sink должны быть параметры на размера батча и интервала для записи текущего батча (для mongo они есть - https://nightlies.apache.org/flink/flink-docs-master/docs/connectors/datastream/mongodb/#configurations-1). В этом случае нагрузка будет высокая, но уже периодичная. Это конечно не решает вышу проблему.
Если говорить конкретно про операцию инкремента, то я бы вставил window-оператор, в котором суммировал все инкременты в окне например 10минут. Когда окно "закрывается", то в последующий sink-оператор передавать уже инкремент на аггрегированное значение, чтобы выполнился один запрос в бд. В этом случае мы добавляем искусственный батчинг из-за ожидания "закрытия" окна (пока оно не закроется - данные не запишутся), но не добавляем батчинг с точки зрения "задержки обработки сообщений".
Apache Flink: Unit и E2E-тестирование оператора с таймерами в Apache Flink