Заказчик хочет сохранять, причем отключаемо, все данные читаемые или модифицируемые в основной бд в дополнительную.
В качестве дополнительной предполагается использование какой-либо NoSQL базы. Основная — PostgreSQL.
Работа с основной предполагается через EF Core.
Как бы это реализовать?
Очевидные проблемы:
1. Оно не должно тормозить
2. Логирование должно быть в одном месте что бы не забывать его включать/отключать. Соответственно вся работа с бд должна пройти через некую точку и эта точка не должна стать узким местом.
Здравствуйте, BlackEric, Вы писали:
BE>Заказчик хочет сохранять, причем отключаемо, все данные читаемые или модифицируемые в основной бд в дополнительную.
А цель этого какая?
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, BlackEric, Вы писали:
BE>>Заказчик хочет сохранять, причем отключаемо, все данные читаемые или модифицируемые в основной бд в дополнительную. K>А цель этого какая?
Залогировать всЁ. В том числе чтение. Да, там будут терабайты логов. Требование такое.
В Java вся работа с базой идёт через JDBC. Это набор интерфейсов, которые реализует драйвер. Собственно я бы сделал свою реализацию этих интерфейсов, которая просто пробрасывает все вызовы к драйверу, а после успешного завершения операции логгировала бы эту операцию во второй базе. Если в .NET похожая архитектура драйверов базы, можно попробовать примерно так же сделать.
Здравствуйте, BlackEric, Вы писали:
BE>Заказчик хочет сохранять, причем отключаемо, все данные читаемые или модифицируемые в основной бд в дополнительную. BE>В качестве дополнительной предполагается использование какой-либо NoSQL базы. Основная — PostgreSQL. BE>Работа с основной предполагается через EF Core.
Посмотри на GridGain. Там есть средства интеграции с РСУБД, в том числе и с PostgreSQL. Эта интеграция использует GridGain как In-memory кэш для РСУБД. Но GridGain ещё умеет сохранять данные на диск. Возможно, это как раз то, что тебе нужно. Но детальнее подсказать, к сожалению, не смогу т.к. сам знаком с GridGain'ом поверхностно.
Здравствуйте, vsb, Вы писали:
vsb>В Java вся работа с базой идёт через JDBC. Это набор интерфейсов, которые реализует драйвер. Собственно я бы сделал свою реализацию этих интерфейсов, которая просто пробрасывает все вызовы к драйверу, а после успешного завершения операции логгировала бы эту операцию во второй базе. Если в .NET похожая архитектура драйверов базы, можно попробовать примерно так же сделать.
Здравствуйте, BlackEric, Вы писали:
BE>В качестве дополнительной предполагается использование какой-либо NoSQL базы. Основная — PostgreSQL.
Как бы это реализовать? BE>Очевидные проблемы: BE>1. Оно не должно тормозить BE>2. Логирование должно быть в одном месте что бы не забывать его включать/отключать. Соответственно вся работа с бд должна пройти через некую точку и эта точка не должна стать узким местом.
PostgreSQL уже пишет лог, поэтому можно (основываюсь на опыте с другой СУБД) просто постоочно читать лог из системных таблиц с отбором ненужного и асинхронно писать в data lake (чтобы была schema on read и недорого).
Здравствуйте, BlackEric, Вы писали:
BE>Заказчик хочет сохранять, причем отключаемо, все данные читаемые или модифицируемые в основной бд в дополнительную.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, BlackEric, Вы писали:
BE>>Заказчик хочет сохранять, причем отключаемо, все данные читаемые или модифицируемые в основной бд в дополнительную.
S>Не проще репликацию настроить?
Репликацию тоже хотят, но это не заменяет логирования всего и вся.
Здравствуйте, Milena, Вы писали:
M>PostgreSQL уже пишет лог, поэтому можно (основываюсь на опыте с другой СУБД) просто постоочно читать лог из системных таблиц с отбором ненужного и асинхронно писать в data lake (чтобы была schema on read и недорого).
Что-то я не знаю где у постгреса логи такого уровня. Я в нем не спец, правда.
Здравствуйте, BlackEric, Вы писали:
BE>Заказчик хочет сохранять, причем отключаемо, все данные читаемые или модифицируемые в основной бд в дополнительную. BE>В качестве дополнительной предполагается использование какой-либо NoSQL базы. Основная — PostgreSQL. BE>Работа с основной предполагается через EF Core.
BE>Как бы это реализовать? BE>Очевидные проблемы: BE>1. Оно не должно тормозить BE>2. Логирование должно быть в одном месте что бы не забывать его включать/отключать. Соответственно вся работа с бд должна пройти через некую точку и эта точка не должна стать узким местом.
У меня вырисовывается что-то типа класса с двумя дженерик функциями для get и post.
Они будут в себя принимать реквест, его логировать и через медиатор передавать реквест в репозиторный хандлер. Ну и обратно респонс репозитория логировать.
Здравствуйте, BlackEric, Вы писали:
BE>Здравствуйте, Milena, Вы писали:
M>>PostgreSQL уже пишет лог, поэтому можно (основываюсь на опыте с другой СУБД) просто постоочно читать лог из системных таблиц с отбором ненужного и асинхронно писать в data lake (чтобы была schema on read и недорого).
BE>Что-то я не знаю где у постгреса логи такого уровня. Я в нем не спец, правда.
Я имею в виду обычный транзакционный лог базы данных, которую пишет любая СУБД. Я делала подобное в SQL Server, но в целом это доступно в любой БД, так как это основа ее функционирования, просто реализация разная будет.
То, что я описала, можно сделать через write-ahead log stream: https://stackoverflow.com/questions/36291676/query-transaction-log-in-postgresql/36292724
Здравствуйте, Milena, Вы писали:
M>Я имею в виду обычный транзакционный лог базы данных, которую пишет любая СУБД. Я делала подобное в SQL Server, но в целом это доступно в любой БД, так как это основа ее функционирования, просто реализация разная будет. M>То, что я описала, можно сделать через write-ahead log stream: https://stackoverflow.com/questions/36291676/query-transaction-log-in-postgresql/36292724
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, BlackEric, Вы писали:
K>>>А цель этого какая? BE>>Залогировать всЁ. В том числе чтение. Да, там будут терабайты логов. Требование такое.
W>Так цель-то какая? Аудит? Восстановление после сбоя? История изменений?
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, BlackEric, Вы писали:
BE>>1. Оно не должно тормозить
W>Так не бывает, в общем случае.
BE>>вся работа с бд должна пройти через некую точку и эта точка не должна стать узким местом.
W>Ты же понимаешь, что эти требования взаимоисключающие.
Имхо, полноценно реализовать такое через автоматический парсинг логов не реально.
Под "полноценно" я имею в виду что в нормальный аудит должны попадать:
информация о пользователе приложения (не пользователе БД!), окружении (e.g. через какой клиент поступил запрос, с какого IP и т.п.),
запрошенной операции (причем не просто read/write базы, а в бизнес-терминах, e.g. "попытка изменения пароля", "попытка проведения платежа" и т.п.),
значения данных до/после изменения.
Вообще задача хорошо ложится на Event Sourcing парадигму. Тогда лог изменений (поток событий) будет из коробки.
Но и в классической схеме с репозиториями можно попробовать построить pipeline обработки входящих запросов по CQRS схеме.
Т.е. чтобы на каждую бизнес транзакцию был свой IQueryHandler<T>/ICommandHandler<T>.
Тогда поверх можно единожды написать универсальный декоратор, который будет логировать контекст (пользователь, IP и т.п.), входные параметры и результаты выполнения.
