Делать event driven на логах - ну такое:)

Да, логи можно процессить, стриминг там какой-нибудь, решений море. Можно даже пайплайн длинный сделать. Но в подобной ситуации у меня было бы большое удивление от того, что кто-то делает подобное сознательно и с желанием, а не по необходимости.

Это если думать о логах как о файлах. А ты думай как о kafka topics

Это уже не логи, это уже data streams :)

Это все append only логи

Все есть данные, вопрос только в том, для чего они предназначаются. Можно натянуть любую абстракцию, но business value у такого решения будет весьма и весьма сомнительное.

Речь о том, что в append only log хочется писать о всех событиях которые происходят и это частый кейс

Event log, ага. Можно писать. Хоть в кафку, хоть в хадуп, хоть в кликхаус... Даже полезно, для аудита, например. Или для анализа действий пользователей.

У этого есть достаточно четкое предназначение. Другой вопрос - писать к примеру терабайты логов приложения, где куча сервисной и в целом бесполезной инфы про "подключился к базе, обработал запрос, закрыл коннект". Она конечно нужна, но такие вещи опять же лучше в метрики обвязывать, с ними сильно проще работать и они просто на порядки дешевле.

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

И обычно это количество денег ощутимо меньше, чем то, что готовы потратить на тот же анализ поведения пользователей. Потому что у него есть понятная польза, а у "раз в месяц посмотреть что там за 500 ошибки" польза не очень понятна (для бизнеса) и труднообъяснима.

Кто подскажет по редису

Есть сущность, и есть вариации этой сущности
Мы прикрутили фолбек логику, когда ты пытаешься достать вариацию, а ее нет, мы отдаем дефолтную/глобальную сущность
Потом к нам пришли девопсы, и говорят нужно прикрутить кеш, у вас пишутся данные редко, а читаются часто.
Ну мы и сделали кеш на неделю

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

Все что нарыл, это Redis scan + pipeline delete для всех найденых ключей по wildcard, когда мы обновляем дефолтную сущтность

Остановите меня, если я увлекся и есть более изячное решение)

у нас в лог базе данных есть машинлернинг(unsupervised & supervised), но надо запросы писать

может вам это в хешсете тогда держать?

Да, выглядит намного проще
У нас на самом деле записей там не так много нужно

А че я не додумался?)

@spacentropy спасибо

Ток теперь грядет рефакторинг cache layer 😩

Добавьте версии в сущности, вычитали кеш и тут же версию дефолтной сущности, сравнили - обновили кеш если надо

Не надо трекать в таком случае и искать все закешенные вариации

Ну и expire разумный на кеши вариациий