Я бы на самом деле занимался этим с двух точек зрения.
Одно из преимуществ, которые вы получаете, используя Envers, заключается в том, что вы можете очень быстро аннотировать свои сущности и точно сказать структуре, как вы хотите отслеживатьизменения для ваших моделей сущностей.Что еще лучше, вы можете сделать так, чтобы Envers автоматически генерировал для вас расширяемые поля.
Давайте возьмем эту базовую сущность:
@Entity
@Audited(withModifiedFlag = true)
public class Person {
@Id
@GeneratedValue
private Integer id;
private String name;
}
Когда вы включите функцию withModifiedFlag
, это информирует Enversдобавить несколько дополнительных столбцов метаданных в таблицу аудита для этой сущности, поэтому в основном таблица аудита этой сущности будет выглядеть следующим образом:
+----+------+----------+-----+---------+
| ID | name | name_MOD | REV | REVTYPE |
+----+------+----------+-----+---------+
Преимущество в том, что если вы используете какой-то процесс для экспорта и потоковой передачиданные непосредственно из таблицы, вам больше не нужно фактически сравнивать текущую строку с предыдущей строкой, чтобы узнать, что изменилось;схема сообщает вам об этом автоматически, просто посмотрев, является ли связанный столбец _MOD
1
(true) или 0
(false).
С этого момента у вас есть пара опций.
Собственный запрос ETL
Вы можете использовать собственные запросы Hibernate для извлечения и преобразования данных в JSON для ES либо через некоторый поток фонового приложения, либо через отдельный фоновый процесс.Поскольку столбец _MOD
предоставляет вам индикатор того, что поле изменилось, вы можете легко прочитать строки и построить необходимые данные без необходимости выполнения операции diff во время извлечения.
Я бы также рекомендовал настроить Envers дляПоместите объекты аудита в отдельный каталог / схему.Это максимизирует способность базы данных улучшать дисковый ввод-вывод для нескольких баз данных одновременно.
Debezium ETL
Проект Debezium - отличный способ справиться с репликацией данных.Одним из его сильных преимуществ является то, что он позволяет пользователям делать это на разнородных платформах, которые точно вписываются в вашу модель.
Большая разница в том, что Debezium не читает базу данных напрямую, чтобы определить изменения, а скорее читаетфайл журнала транзакций базы данных и генерирует серию событий, описывающих операции DML, которые выполнялись с этой базой данных.Короче говоря, вы избегаете операций чтения, которые вас так беспокоят, поскольку Debezium регидратирует состояние непосредственно из журнала транзакций.
Например:
- Hibernate выполняет
INSERT INTO Person (?,?) VALUES (?,?)
. - Hibernate Envers выполняет
INSERT INTO Person_AUD (...) VALUES (....)
- База данных записывает эту операцию в журналы повторов / транзакций.
- Дебезиум замечает, что журнал был записан, читает записи.
- Debezium генерирует событие вставки для
Person_AUD
(таблица подписана). - Любая зарегистрированная заинтересованная сторона этого события получает его и обрабатывает.
Оно находится в (5) где ваш код преобразования / загрузки будет существовать, чтобы получать это событие вставки, генерировать вывод JSON и отправлять его в ES.
Заключение
Используя Debezium, вы сможете эффективно офлайн репликация данных в разнородных средах в чрезвычайно эффективном поместье.Этот проект не только подходит для вашего случая использования, но и чрезвычайно ценен в современном мире архитектуры микросервисов, где обмен данными между службами имеет решающее значение.
Используя Envers, вы можете предоставить онлайн резервное решение для предоставления пользователям аудита исторических данных, когда ваш кластер ES недоступен или перегружен, вместо предоставления пользователям ответа «Служба недоступна, вернитесь позже».
Что бы вы ни решили, производительность не являетсяединственный касающийся фактор.Вы также должны помнить о пользовательском опыте, масштабируемости и надежности;поэтому я считаю, что оптимальным решением является объединение обоих.