0
- En Mysql (5.7 et versions ultérieures) pour le suivi des modifications d'une table, this approach est très simple à mettre en œuvre.
- Mais il faut que la table des versions soit de MyISAM, ce qui permet le verrouillage au niveau de la table.
- Cette approche fonctionnerait-elle bien pour les systèmes de production où plusieurs insertions/mises à jour se produisent toutes les secondes?
- Est-ce que quelqu'un a une réelle expérience des systèmes de production à propos de cette approche?
Chaque table dans la base de données (InnoDB) a des versions Table (MyISAM) Mon système a la charge suivante.
* Environ 500 lectures/sec sur chaque table en raison de diverses jointures.
* Et 50 écritures/sec à diverses tables qui ont des déclencheurs à la table de versions.
La table des versions (MyISAM) deviendrait-elle un goulot d'étranglement pour les performances?Performances MyISAM
Je n'ai pas d'expérience directe avec ce type de scénario MyISAM très performant, mais ... Je pense que MyISAM ira bien * pourvu * que vous ayez configuré vos tables et votre serveur de manière appropriée. Je parle d'utiliser des champs statiques, des index appropriés, et vous pouvez même utiliser un serveur dédié pour la tâche qui a besoin de cette performance et je pense que MyISAM fonctionnera très bien. Vous pouvez également configurer votre base de données sur un disque SSD plutôt que sur un disque dur. – Dennis
La seule raison de MyISAM ici est d'obtenir l'incrément. Donc ce que vous gagnez, c'est le temps de ne pas chercher une méthode pour le faire avec InnoDB (table d'état/colonne ou simplement en utilisant par exemple un horodatage au lieu d'un incrément). Ce que vous perdez: ça ne marchera plus dans MySQL 8 (plus de MyISAM). Et vous aurez des entrées de version invalides chaque fois qu'une transaction InnoDB est annulée (car elle ne peut pas revenir dans MyISAM). La performance, d'un autre côté, ne devrait pas poser de problème, et si c'est le cas, vous pouvez la partitionner, par ex. mettre des versions pour les id impair/pair dans la table/serveur 1/2. De toute façon, mon point est: MyISAM est mort. Laisse reposer en paix. – Solarflare
MyISAM Storage Engine effectuera un verrouillage de table complet. Lecture et écriture ne peuvent pas être effectuées en même temps dans une table, toutes les autres sessions qui veulent accéder à cette table particulière doivent attendre que la mise à jour soit terminée. InnoDB va certainement résoudre ce problème. Pour le système de production avec beaucoup d'écritures, vous devrez essayer de désactiver query_cache. Une taille de cache de requête trop importante entraîne une dégradation significative des performances. En raison de la surcharge du cache et du verrouillage. Les requêtes Cacheable sortent un verrou exclusif sur le cache de requêtes de MySQL. – xachela