Всем привет! Появилась такая задача: Имеем postgresql 11 и приложение работающее

с ним и пишущее свои логи в graylog.
Для анализа логов часто нужна информация из БД дополнительно.
Поэтому предложили перенести логи в postgresql чтобы джоинить сразу выборку из логов с нужными таблицами базы.
Для поиска по логам будет использоваться FTS.
Кол-во логов 200 записей в минуту с хранением 1 год.
Кто то сталкивался с таким? Что стоит предусмотреть?
Пока что из идей было сделать таблицы при помощи timescaledb для более быстрого поиска фильтруя по времени.
Так же думал найти какой нибудь fdw для elasticaearch, но не нашел какого то популярного решения.
Или возможно вообще не с той стороны подхожу к этому вопросу? Если кто то имеет подобный опыт или есть идеи, прошу помочь)

timescale тут точно поможет с удалением устаревших логов.

Не знаю насколько хорошо с ним будет работать fts и соответствующие индексы, и не принесет ли он больше бед чем помощи.

Не пробовали, но мне кажется для FTS Timescale не очень подходит. Его сила в другом. Мы для работы с логами пробовали ClickHouse с подтаскиванием в него нужных таблиц из Postgres и Grafana+Loki. Пока ни одно решение нас не устроило.

Если у вас реально 200 з/с то ещё норм, но кто дает гарантию что завтра их не станет 400 а потом тысяча и тогда вы очень быстро упретесь в лимиты постгреса

200з/минуту не в секунду, гарантий нету конечно, это просто анализ из того как они все предыдущее время писались в грейлог насколько понимаю

Доброе утро, я бы не рекомендовал вам использовать postgres для данной задачи Есть например тот же clickhouse, складывайте туда логи и нужные данные из постгреса, например используйте очереди (Kafka, RabbitMQ), чтобы слать в одно место логи и данные, вариантов куча Но очень высока вероятность что вы упретесь в postgres с логами Ищите другое решение, более подходящее для этих задач

данные с которыми надо джойнить логи уже лежат в postgres и их точно не вариант переносить в кликхаус например

их легко может стать 1000-и в секунду

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

Типичная ошыбка — оптимизировать систему под какие-то абстрактные фантазии, а не под свои потребности.

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

А информация из бд статичная или может меняться после записи лога? Может имеет смысл ее в момент записи лога докладывать, либо насыщать лог данными через какой-нибудь воркер, который можно встроить в пайплайн обработки логов

даже если она статична - то кажется дергать лишние 200раз прод таблицу вместо того чтобы потом её условно раз в месяц при инвестигейте каком то дернуть - тоже излишне

Да, но за это придется заплатить зависимостями табличек с данными от табличек с логами и сопутствующие проблемы от раздувания базы, вопросы масштабирования итд итп

Кстати, если хранить логи в рабочей базе при всплеске ошибок может быть "весело". Из личного опыта. Я бы хотя бы разделил базы.

Да, уже думаю выделить под них отдельный инстанс, который по длинк будет в прод за доп данными ходить по необходимости. Вариант с кликхаусом отпал потому что они пишут по одной строчки 200 отдельных инсертов в минуту, что не очень хорошо для клика