Hibernate Envers performance MySQL

Question

Сейчас я пытаюсь выбрать наиболее подходящий подход для реализации Audit Trail для моих объектов с базой данных AWS RDS MySQL.

Мне нужно зарегистрировать все изменения сущностей, включая инициатора (пользователя), который инициировал эти изменения. Одним из основных критериев является производительность.

Hibernate Envers выглядит как самое простое и наиболее полное решение и может быть очень быстро интегрировано. Сейчас я беспокоюсь о возможном замедлении производительности после введения Envers. Я видел несколько сообщений, в которых разработчики предпочитают подход к Audit Trail на основе триггеров базы данных.

Основная проблема с триггерами заключается в том, как получить инициатор (пользователь), который инициировал эти изменения.

Основываясь на своем опыте, не могли бы вы предложить подход для Java/Spring/Hibernate/MySQL (AWS), чтобы реализовать Audit Trail для исторических изменений.

Кроме того, есть ли у нас какое-либо решение для аудита в рамках инфраструктуры баз данных AWS RDS MySQL?

Answer 1

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

С простой точки базы данных, поскольку таблица растет до определенного предела, да, ее производительность ухудшится, но, как правило, это в основном влияет на запросы и меньше на вставку/обновление, если таблица правильно проиндексирована и правильно сформированы запросы.

Но многие базы данных поддерживают разделение как средство контроля производительности, особенно на больших таблицах. Обычно это связано с разделением данных таблицы на множество границ, определенных созданной вами схемой разделов. Вы просто определяете, какие наиболее релевантные данные, и вы пытаетесь сохранить этот раздел на своих самых быстрых дисках/хранилище, а менее релевантные, как правило, более старые данные хранятся на ваших более медленных дисках/хранилищах.

Вы также можете выбрать сохранение таблиц базы данных в разных схемах/табличных пространствах, указав свойство envers org.hibernate.envers.default_schema. Если ваша база данных поддерживает размещение схем в разных файлах базы данных в файловой системе, вы можете повысить производительность, позволяя чтение/запись таблицы сущностей не влиять на чтение/запись ваших таблиц аудита.

Я не могу говорить с поддержкой MySQL ни для одной из этих вещей, но я знаю, что MSSQL/Oracle поддерживает разбиение на разделы очень легко, и Oracle, безусловно, позволяет разделять схемы на разные файлы базы данных.