Как лучше всего организовать очистку файла журнала в PostgreSQL?
У меня задача реализовать событийную архитектуру при работе с базой данных PostgreSQL.
Было решено реализовать его с помощью JDBC, так как приложение является расширением Java-приложения. Итак, возникли следующие проблемы. Хотя работа с базой данных построена не на базе WebSocker, а на драйвере, никакого пула событий в базе данных нет, поэтому чтение событий было реализовано через стандартное логирование. И возникла проблема — это многопользовательская удаленная работа приложения с одной базой данных. Ситуация с прямым чтением и очисткой файла через Java сразу отпала, так как нет возможности напрямую очистить лог-файл. Я нашел вариант чтения данных из лог-файла средствами самой базы данных, но база данных не предназначена для обработки текстовых данных, поэтому варианта очистки лог-файла через PostgreSQL я не нашел, вот тут-то и возник ступор.
Опытные пользователи, пожалуйста. Можно ли как-то очистить файл журнала с помощью самой базы данных? (Например, через запрос)
Если есть варианты получше, как читать события в базе, буду рад их выслушать.
Ого. На первый взгляд даже не думал о применении Посгри в качестве шины данных событийной архитектуры. На ум сразу приходят Кафка или Стримы Rabbitmq, собственно, спроектированные для работы с потоками событий...
У Посгри конечно есть notify, который можно использовать совместно с триггерами таблиц, но это тоже что-то довольно самобытное.
Можете ли подробнее описать архитектуру решения, быть может я думаю о чем-то другом? Потому что пока никак не могу увязать в голове описанное в вопросе - БД, событийку и файловые логи
Дмитрий Шицков, Ну смотрите, логи бд фиксируют почти всё, что происходит в базе данных, например подключение пользователя базы данных. Когда в файле логов появляется строка о подключении пользователя, автоматически срабатывает прослушивание данного события.
AdaMorgan, стало чуть понятнее. Если у вас используется стандартное логирование БД и требуется решить вопрос масштабирования, предложил бы такой вариант системы:
Postgresql пишет лог в json
Используя filebeat, логи пушить в топик (возможно, в топики в разрезе по пользователям или другим условиям) в Kafka. Ротацию устаревших логов так же можно выполнять с помощью filebeat
Потоки события из Kafka уже анализируются приложением
Если этот вариант не подходит и требуется лишь решить вопрос удаления старых файлов, то не совсем понял почему "Ситуация с прямым чтением и очисткой файла через Java сразу отпала". Она не столь удобна как чтение из Кафки, но возможна. Ваше приложение должно будет управлять ротацией логов. Операция должна будет следующей - выполняется logrotate (или аналогичными библиотеками для Java) для лога, затем необходимо закрыть и открыть снова файл лога в Java. Таким образов вы гарантированно дочитаете старый лог.
При других вариантах очистки или ротации, я опасаюсь, будет шанс потерять часть событий.
1) Как советует Александ Путров, классический путь: интересующие события пишите в таблицу.
2) Если нужны уведомления подписчиков, то ставите Supabase Realtime. Это отдельный сервис который прикидывается репликой постгреса и рассылает уведомления клиентам.
поэтому варианта очистки лог-файла через PostgreSQL я не нашел
Это вредная идея уровня «мне сборщик мусора в JAVA не даёт сразу очистить мусор, я хочу подключаться из другого процесса и делать очистку сам», никогда так не делайте.
