En ce qui concerne "Dynamic" , le format Barracuda non compressé uniquement, très peu de choses ont changé par rapport au format compact, principalement sur la façon dont les blobs (et les champs très dynamiques) sont stockés . Je n'ai jamais eu de problème avec compact vs dynamique, je peux donc recommander en toute sécurité la dynamique de Barracuda. N'oubliez pas que Barracuda prend également en charge les anciens formats de ligne redondants et compacts .
L'article que vous mentionnez est probablement trop ancien (5.1) et, comme Peter Z., PDG de Percona, le mentionne sur les commentaires, il peut être un peu trompeur. Cela ne signifie pas que la compression ne peut pas être un gain énorme en fonction des charges de travail. Cependant, je vous recommanderais de l'essayer sur les versions> = 5.6, car Facebook et Oracle ont fait beaucoup d'améliorations à ce sujet.
En tant que documents de référence plus récents, je vous recommanderais:
En particulier, j'aime les documents Facebook car ils sont tiers (pas besoin d'agenda) et ils ont l'un des plus grands déploiements MySQL au monde. Comme vous pouvez le voir, ils ont eu des configurations très réussies combinant la technologie SSD avec la compression.
Cela vous sera-t-il avantageux? Cela dépendra de votre charge de travail, de votre ensemble de travail et de votre configuration (IOPS, mémoire) . Selon que vous êtes lié aux E / S, lié au CPU ou lié à la mémoire, la compression peut affecter négativement dans certains cas, en ajoutant du CPU supplémentaire, des besoins en mémoire (les pages compressées et non compressées sont stockées sur le pool de mémoire tampon InnoDB) ou en générant trop d'échecs de compression, augmentant la latence. Cela dépend également du type de données: la compression peut être très utile pour les gros objets de texte, mais elle peut être inutile avec des données déjà compressées.
D'après mon expérience, dans la pratique, il y a des gens pour qui la compression était le Saint Graal de la performance et en sont très satisfaits, mais dans d'autres cas, nous avons dû revenir à des données non compressées car aucun gain n'a été obtenu. Bien qu'une charge de travail d'écriture très lourde puisse sembler un mauvais environnement pour la compression, si dans votre cas particulier vous n'êtes pas lié à la CPU et à la mémoire, mais lié à l'iops, cela peut être néanmoins utile.
En général, il est très difficile de prédire les résultats, vous devez généralement configurer un environnement de test pour l'analyse comparative, puis découvrir pourquoi vous obtenez des résultats meilleurs ou pires (et de cette façon, vous pouvez jouer avec différentes tailles de bloc, etc.). Barracuda est complètement sûr. La compression peut ou non vous convenir. Et vous pouvez toujours expérimenter d'autres méthodes de compression comme la compression côté client des objets blob (par exemple, si vous vous retrouvez liée au processeur) ou d'autres moteurs tiers comme RocksDB et TokuDB , dans lesquels la compression est une grande priorité, car elle est concentrée en termes de performances pour des ensembles de données plus volumineux que InnoDB ne peut gérer.
En bref: les principales raisons d'utiliser Barracuda sont la gestion des BLOB, la innodb_large_prefixcompatibilité (grands index) et la compression. Dynamique, sur MySQL 8.0 est désormais le format de fichier par défaut.
