Qu'est-ce que le ballonnement des tables dans les bases de données?
Quelqu'un peut-il expliquer ce que ballonnements signifie en termes de base de données? Par exemple, qu'est-ce que cela signifie de dire qu'un indice est gonflé. J'ai essayé de le chercher, mais il n'y a aucune explication de ce que sont les ballonnements, seulement ce qu'ils provoquent ou ce qu'ils provoquent.
En raison de la façon dont PostgreSQL gère les transactions et les accès concurrents, MVCC - Multi-Version Concurrency Control, vous pouvez avoir des ballonnements. Dans PostgreSQL, lorsque vous effectuez un UPDATE ou DELETE, la ligne n'est pas réellement supprimée physiquement. Pour un DELETE, il marque simplement la ligne comme indisponible pour les transactions futures, et pour UPDATE, sous le capot, c'est un INSERT puis DELETE, où la version précédente de la ligne est marquée comme indisponible.
Bien que les données soient marquées comme indisponibles, elles sont toujours là et l'espace ne peut pas être utilisé. Pour marquer ensuite l'espace comme disponible pour une utilisation par la base de données, un processus sous vide doit se produire derrière les opérations et marquer cet espace disponible pour la base de données à utiliser. Cependant, il n'est pas retourné au système d'exploitation. Cela se produit uniquement lorsqu'il n'y a pas de lignes actives dans une page entière, ce qui peut être rare dans certaines charges de travail. Cela peut être une bonne chose pour certaines charges de travail, car vous pouvez simplement mettre à jour l'espace sur les pages individuelles à l'intérieur des fichiers de données, sans avoir besoin d'ajouter des fichiers de données supplémentaires.
Les problèmes surviennent avec le ballonnement lorsqu'il y a un nombre excessivement élevé de tuples morts par rapport aux tuples vivants. Marcher et vérifier tous les indicateurs de visibilité prend du temps, et avoir plus de fichiers de données pour une relation entraîne une charge supplémentaire inutile IO. Le gonflement est particulièrement visible sur les index, qui peuvent également avoir de nombreux tuples morts) , parfois beaucoup plus que le tableau. Bloat peut ralentir les recherches et les analyses d'index, ce qui se traduira par une augmentation lente des temps de requête et une modification des plans de requête.
Vous pouvez restaurer l'espace en utilisant pg_reorg , pg_repack , CLUSTER ou VACUUM FULL. Cela va parcourir et réorganiser les fichiers, déplacer les tuples et réorganiser pour vous assurer qu'il n'y a pas de tuples morts, ce qui éliminera le ballonnement.
Bloat peut également être géré efficacement en ajustant les paramètres VACUUM par table, ce qui marque l'espace mort de Tuple disponible pour une réutilisation par les requêtes suivantes.
Vous pouvez utiliser des requêtes sur le wiki PostgreSQL liées à Show Database Bloat et Index Bloat pour déterminer la quantité de ballonnement dont vous disposez, et à partir de là, faire un peu d'analyse des performances pour voir si vous avez des problèmes avec la quantité de ballonnement que vous avez sur vos tables.
Cela fait probablement référence à des problèmes courants avec les index dans lesquels soit deux colonnes sont ajoutées à l'index, soit des index se chevauchent sur une table. Autrement dit, plusieurs index contenant le même ensemble de colonnes (rendant l'un d'eux inutile). Je passerais en revue tous les index des tables à la recherche de colonnes qui se chevauchent, à la recherche d'index qui ne sont que des sous-ensembles d'autres index et les supprimer SI vous pouvez déterminer qu'ils ne sont pas utilisés.
De plus, à mesure que les données des tableaux sont mises à jour, les index peuvent devenir fragmentés, ce qui les rend plus volumineux que nécessaire. Je ne connais pas les postgres, mais je soupçonne qu'il existe des méthodes pour défragmenter les index (en reconstruisant les index) qui réduiront leur taille sur le disque.