Le fractionnement de ce fichier en petits morceaux (par exemple 4G) serait-il meilleur ou pire pour les performances?
nachito
Réponses:
13
Quand cela peut être un problème
Si vous exécutez show table statussur une table et que le Data_freechamp représente la grande majorité de ibdata1la taille de votre fichier, vous risquez d'avoir beaucoup d'espace perdu. Beaucoup d'insertions / suppressions en feront un problème. Si tel est le cas et que les insertions et suppressions transitoires constituent la majeure partie de vos données, vous avez un bon cas pour le fichier par table.
Ce n'est pas un "oui" automatique, cependant. Il y a beaucoup de discussions dans le monde sur la fragmentation interne à l'intérieur des fichiers InnoDB, mais les placer dans un système de fichiers en tant que fichier par table déplace simplement votre fragmentation au niveau du système de fichiers au lieu du niveau de la base de données.
Pourquoi ce n'est généralement pas un problème
Considérez votre fichier InnoDB comme un système de fichiers plutôt que comme un fichier. Si vous avez beaucoup de fichiers, vous aurez besoin d'un gros système de fichiers.
Pour la plupart, les systèmes de fichiers réussissent très bien à évoluer pour gérer des téraoctets de données et un nombre incalculable de fichiers. Parfois, ils rencontrent des problèmes d'indexation médiocre (par exemple, des limites au nombre de fichiers dans un répertoire avant un impact sur les performances), mais pour la plupart, le système de fichiers moderne peut basculer bien dans la plage de téraoctets.
InnoDB fonctionne de la même manière. La taille de votre fichier de données peut être énorme ... et comme les grands systèmes de fichiers, cela peut poser des problèmes avec la sauvegarde de vos données. Cependant, tout comme le fractionnement de votre système de fichiers en plusieurs partitions ne résout pas ce problème, ni essayer de manipuler innodb. Bien que vous puissiez utiliser innodb_file_per_table , je le recommande rarement.
Tout comme votre système de fichiers, la meilleure réponse est de connaître les limites en interne et d'y travailler. Comprendre les index et les appliquer correctement. Ne cherchez pas à diviser InnoDB, ce n'est pas fait pour ça.
Je me souviens d'une diapositive marketing MySQL vraiment très ancienne où le client dirigeait un entrepôt de données avec quelques téraoctets. Il y a plusieurs années. InnoDB ou MyISAM, les deux fonctionneraient. C'est standard sur le rack MySQL.
Il semble que je sois un peu moins de 50% utilisé. InnoDB free: 7364608 kB
nachito
@nachito On dirait que ça devrait aller. Si vous sentez que vous avez besoin de l'espace pour le système de fichiers, récupérez-le. Si vous êtes juste préoccupé par les performances, ne le faites pas. De plus, pour les performances, il est préférable de conserver vos fichiers de base de données sur leur propre partition, donc si vous vous concentrez sur les performances, vous ne verrez pas de récupération utilisable de toute façon.
Jeff Ferland
6
Les fichiers ibdata ne rétrécissent pas - si vous avez récemment supprimé des tables ou supprimé beaucoup de lignes - innodb dans votre configuration ne libérera pas l'espace libre dans le système de fichiers. je vous suggère:
sauvegarder toutes vos données, par exemple avec mysqldump
ajouter à la directive my.cnf innodb_file_per_table
redémarrer mysql
supprimer toutes les bases de données à l'aide du moteur innodb
arrêtez mysql
supprimer le fichier ibdata
rm ib_logfile [01]
démarrez mysql, vérifiez syslog si tout va bien
recharger votre vidage
de cette façon, vous pourrez récupérer l'espace chaque fois que vous supprimez une table / base de données innodb - les fichiers idb associés seront supprimés immédiatement.
Je comprends que cela ne rétrécira jamais sans dumping et rechargement des tables. Cependant, si j'ai abandonné les bases de données InnoDB, utilisera-t-il cet espace "libre" avant de recommencer à croître?
Votre réponse est juste une suggestion simple sans obscurcir le problème comme ma réponse semble l'avoir fait. +1 !!!
RolandoMySQLDBA
1
Eh bien, la réponse est une solution pour réduire l'espace utilisé par les fichiers de données, mais ce n'est pas une discussion sur le mérite lié à cela, et c'est la question que je lis. Un fichier ibdata de 15 Go est-il un gros problème?
Réponses:
Quand cela peut être un problème
Si vous exécutez
show table statussur une table et que leData_freechamp représente la grande majorité deibdata1la taille de votre fichier, vous risquez d'avoir beaucoup d'espace perdu. Beaucoup d'insertions / suppressions en feront un problème. Si tel est le cas et que les insertions et suppressions transitoires constituent la majeure partie de vos données, vous avez un bon cas pour le fichier par table.Ce n'est pas un "oui" automatique, cependant. Il y a beaucoup de discussions dans le monde sur la fragmentation interne à l'intérieur des fichiers InnoDB, mais les placer dans un système de fichiers en tant que fichier par table déplace simplement votre fragmentation au niveau du système de fichiers au lieu du niveau de la base de données.
Pourquoi ce n'est généralement pas un problème
Considérez votre fichier InnoDB comme un système de fichiers plutôt que comme un fichier. Si vous avez beaucoup de fichiers, vous aurez besoin d'un gros système de fichiers.
Pour la plupart, les systèmes de fichiers réussissent très bien à évoluer pour gérer des téraoctets de données et un nombre incalculable de fichiers. Parfois, ils rencontrent des problèmes d'indexation médiocre (par exemple, des limites au nombre de fichiers dans un répertoire avant un impact sur les performances), mais pour la plupart, le système de fichiers moderne peut basculer bien dans la plage de téraoctets.
InnoDB fonctionne de la même manière. La taille de votre fichier de données peut être énorme ... et comme les grands systèmes de fichiers, cela peut poser des problèmes avec la sauvegarde de vos données. Cependant, tout comme le fractionnement de votre système de fichiers en plusieurs partitions ne résout pas ce problème, ni essayer de manipuler innodb. Bien que vous puissiez utiliser innodb_file_per_table , je le recommande rarement.
Tout comme votre système de fichiers, la meilleure réponse est de connaître les limites en interne et d'y travailler. Comprendre les index et les appliquer correctement. Ne cherchez pas à diviser InnoDB, ce n'est pas fait pour ça.
Étant donné que je m'efforce de transmettre le concept de manière constructive, voici une lecture rapide qui dit mieux que moi les mots: les téraoctets ne sont pas des données volumineuses, les pétaoctets le sont .
Ne transpirez pas une base de données de 15 Go.
la source
InnoDB free: 7364608 kBLes fichiers ibdata ne rétrécissent pas - si vous avez récemment supprimé des tables ou supprimé beaucoup de lignes - innodb dans votre configuration ne libérera pas l'espace libre dans le système de fichiers. je vous suggère:
de cette façon, vous pourrez récupérer l'espace chaque fois que vous supprimez une table / base de données innodb - les fichiers idb associés seront supprimés immédiatement.
la source