Стоит ли использовать ksqlDB

@fo2rist, этап подбора этот сервис не прошел, поэтому уже именно вопросы поддержки не рассматривали. Похоже, что при небольшой или средней нагрузке жить будет нормально, так как кластер confluent kafka хорошо продуман и содержит сервисы для поддержки и снятия метрик. Мне не удалось, к сожалению, увидеть эту систему на проде, не могу поделиться опытом

@fo2rist, как указал выше, я слабо ориентируюсьт в проблеме. Мне шеф архитекотр показывал, что кафкаконнект в таблице постгреса накармливаемого типы полей проставляет не те, коотрые надо (стринги в основном).

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

Так-то не то, чтобы это было что-то прям страшное - ну пусть за запись в БД отвечает отдельный сервис, который принимает эвенты и делает запись в БД, если хотим реализовать CQRS. Но тут свои минусы и подводные камни могут быть. Вообще, заниматься такими изучениями и экспериментами было бы прям классно, но в условиях недостатка энергии и необходимости решать хуяторские задачи приходится только кукаретничать (:

kafka connect требует много изоленты, т.к. написан довольно хрупко:

• любит молча останавливать перекладывание вообще всех топиков, если ему в одном что-то не понравится
• не имеет нормального мониторинга, приходится следить за оффсетами консюмер-групп вместо нормальных метрик
• непонятно что делать при эволюции схем

Мы пару лет трахались сначала с kafka-elasticsearch-sink, потом с kafka-clickhouse-sink, в итоге сейчас пилим свой велосипед, который будет перекладывать топики в клик.

На ksql мы смотрели, но нам он совсем не подошел, уже не вспомню почему, кажется был сильно ограничен в средствах работы с данными.

@strangeman, ну да, если вам понадобился кликхаус (колоночная бд для аналитики) и эластик (для полнотекстового поиска), то ksqldb тут ваще никак не поможет. Он пока слабенький и прокрывает самые простейшие запросы