0

En ce moment j'essaie de choisir l'approche la plus appropriée afin de mettre en œuvre Audit Trail pour mes entités avec base de données MySQL AWS RDS.Hibernate Envers performance MySQL

Je dois enregistrer toutes les modifications d'entité, y compris l'initiateur (utilisateur) qui a initié ces modifications. L'un des principaux critères est la performance.

Hibernate Envers est la solution la plus simple et la plus complète et peut être intégrée très rapidement. En ce moment, je m'inquiète du ralentissement possible de la performance après l'introduction d'Envers. J'ai vu quelques messages où les développeurs préfèrent l'approche pour Audit Trail basée sur des déclencheurs de base de données.

Le principal problème avec les déclencheurs est comment obtenir l'initiateur (utilisateur) qui a initié ces modifications. Sur la base de votre expérience, pourriez-vous suggérer l'approche pour Java/Spring/Hibernate/MySQL (AWS) afin de mettre en œuvre Audit Trail pour les changements historiques.

En outre, avons-nous une solution pour Audit Trail dans l'infrastructure de base de données MySQL d'AWS RDS?

+0

Pouvez-vous élaborer sur les problèmes de performance ou les préoccupations que vous avez? Je ne suis pas au courant de problèmes de performances, mais je vous invite à les décrire ici ou à ouvrir un JIRA pour que je puisse y jeter un coup d'œil. – Naros

+0

en raison de la quantité de demandes que je peux obtenir rapidement de très grandes tables avec des changements historiques. Je crains que cela puisse ralentir mon système – alexanoid

+0

Ce problème n'est pas un problème de performance Envers, c'est simplement un effet secondaire auquel est confrontée toute solution d'audit lorsque vous devez auditer toutes les modifications dans un scénario de système à haut volume. Que vous choisissiez d'utiliser une autre solution ou de recourir à des déclencheurs de base de données, le volume de lignes que vous générez reste constant en fonction des besoins de votre entreprise. – Naros

Répondre

2

Comprendre que la spéculation sur la performance sans preuves concrètes pour soutenir sa théorie est analogue à une optimisation prématurée du code. C'est presque toujours une perte de temps. Du simple point de vue de la base de données, si la table atteint une limite spécifique, oui, ses performances se dégradent, mais cela affecte principalement les requêtes et moins l'insertion/mise à jour si la table est correctement indexée. Mais de nombreuses bases de données prennent en charge le partitionnement comme moyen de contrôler les problèmes de performances, en particulier sur les tables plus grandes. Cela implique généralement la séparation des données d'une table sur un ensemble de limites définies par un schéma de partition que vous créez. Vous définissez simplement quelles sont les données les plus pertinentes et vous essayez de stocker cette partition sur vos disques/stockage les plus rapides et les données les moins pertinentes, généralement plus anciennes, sont stockées sur vos disques/stockage les plus lents.

Vous pouvez également choisir de stocker des tables de base de données dans différents schémas/tablespaces en spécifiant la propriété envers org.hibernate.envers.default_schema. Si votre base de données prend en charge l'insertion de schémas dans différents fichiers de base de données sur le système de fichiers, vous pouvez améliorer les performances en autorisant les lectures/écritures de votre table d'entités sans impact sur les lectures/écritures de vos tables d'audit.

Je ne peux pas parler de la prise en charge par MySQL de ces choses, mais je sais que MSSQL/Oracle supporte très bien le partitionnement et Oracle permet la séparation des schémas entre différents fichiers de bases de données.