Sep/092
Sondage: Storage engine non officiel
Depuis quelques années, beaucoup de storages engines ont vue le jour pour répondre à des besoins que les storages engines fournis avec MySQL ne font pas bien, voir pas du tout. Selon moi, la majorité d’entre eux sont des projets qui risquent mourir dans un proche avenir. Toujours selon moi, pour que les projets gratuits et opensource demeurent longtemps, il faut qu’ils jouissent d’une certaine popularité, ce que la majorité des storages engines ne possèdent pas. De plus, ils doivent être en mesure de prouver qu’ils sont sans faille; on ne peut se permettre de perdre des données à cause d’un engine immature.
Malgré tout, je crois en un storage engine non officiel: Percona-XtraDB. Il est basé sur le populaire engine InnoDB, mais offre de meilleures performances tout en demeurant 100% compatible à ce que InnoDB peut accomplir. On peut donc remplacer aveuglement InnoDB par XtraDB sans craindre quoi que ce soit! On pourrait ainsi dire qu’il s’agit d’un nouveau InnoDB, plus rapide et plus robuste.
Comme son nom l’indique, il est principalement développé par Percona, une entreprise pour laquelle j’ai un très grand respect. Bien qu’il soit encore jeune, j’ai confiance qu’il atteigne une maturité très rapidement. Je suis de très près son évolution et j’ai déjà élaboré quelques tests avec.
J’aimerais connaitre vos opinions sur les storages engines non officiels.
Loading ...Jan/098
MyISAM ou InnoDB ?
Un ami me demandait aujourd’hui si une application qu’il utilise à son travail pourrait être plus performante si les tables étaient Innodb plutôt que MyISAM ? Oui. Non. Peut-être. Il n’y a pas de réponse à cette question; il y beaucoup trop de facteurs à considérer.
Peter Zaitsev a publié hier un article sur le sujet. Comme il indique, il faut d’abord s’interroger pour savoir “pourquoi” les tables sont MyISAM à la base. Le sont-ils pour une raison particulière ou parce qu’elles utilisent le storage engine par défaut de MySQL ?
Les 2 storages engines possèdent des avantages différents qui les rendent aussi performant l’un que l’autre, dépendamment de l’utilisation qu’on en fait. Pour répondre adéquatement à mon ami, il aurait fallu que je connaisse quel genre de requêtes son application fait, à quelle fréquence, combien de connexions simultanées utilisent la base de données, etc.. À défaut de connaître toutes ces informations, voici quelques différences qui peuvent vous faire opter pour InnoDB plutôt que MyISAM.
En fait, il faut savoir que de manière générale, là où MyISAM brille, InnoDB est hors compétition, et vice versa. MyISAM est reconnu pour sa vitesse d’écriture, sa faible consommation de mémoire et d’espace disque, sa rapidité à retourner un count(*) et les fulltext index.
InnoDB lui consomme plus de mémoire et d’espace disque, les requêtes d’écritures sont moins rapides que MyISAM, les count(*) sont excessivement lents et il ne supporte pas les fulltext index. Il requiert de modifier la configuration par défaut pour être performant alors que MyISAM performe bien avec la configuration par défaut. À son avantage, il possède du row-level locking, des transactions (acid compliant), des clustered primary key index et son implémentation permet une meilleure “concurrency” (plusieurs opérations simultanées). Lorsque configuré adéquatement, il devient très performant.
Lorsque la concurrence devient un enjeu, qu’il y a beaucoup de requêtes d’écriture et de lecture, InnoDB est le meilleur choix. Plusieurs personnes affirment qu’il devrait être le storage engine par défaut; il est vrai qu’il offre beaucoup plus d’avantages que MyISAM et qu’il offre de meilleures performances en générale (c’est mon avis). Par contre, il ne faut pas négliger les autres storages engines, car ils peuvent être beaucoup plus efficace dans certains cas. Dans le cours de Performance Tunning, on nous enseigne à savoir où, quand, comment et pourquoi un storage engine sera meilleur qu’un autre.
Jun/085
Stocker des fichiers dans MySQL
Est-il mauvais de stocker des fichiers dans MySQL ? Il n’y a pas de bonne ou mauvaise réponse à cette question. Tout dépend de vos besoins. Personnellement, je préfère stocker les fichiers à l’extérieur de la base de données pour les raisons suivantes:
- Le filesystem va mieux cacher les fichiers
- Le serveur MySQL va avoir plus de facilité à cacher les autres données
- Le débit de donnée du serveur va être moins élevé
- Il est plus facile de réorganiser et maintenir les fichiers
- Le tablespace demeure petit (si vous devez utiliser InnoDB)
Une bonne approche est de stocker un pointeur vers les fichiers sur le filesystem plutôt que le binaire du fichier directement dans la BD. Il y a cependant des avantages à les stocker dans la base de données:
- Toutes les données sont centralisées à une place pour les backups
- C’est plus simple à gérer avec la réplication et/ou du load balancing
- Il est possible de demeurer ACID compliant.
J’ai eu une situation qui aurait pu devenir très problématique dernièrement lorsque je devais faire la maintenance de la base de données de l’application RT. Pour faire une histoire courte, RT stock des attachements d’email dans une table InnoDB et le tablespace d’InnoDB est devenu corrompu lorsqu’il a atteint 40 Go. Lorsqu’on sélectionnait des enregistrements précis de la table Attachements, le serveur plantait et mysql_safe le repartait automatiquement. Heureusement, il s’agissait d’un Slave. Comme nous avions qu’un seul slave, nous avons du le “reconstruire” à partir du Master. 40Go de données, c’est long à backuper et restaurer et le downtime que ça a créé était considérablement long. Un downtime est toujours trop long. Sur les 40Go, environ 30 étaient des fichiers d’attachements. Ça aurait été beaucoup plus simple et rapide si les fichiers n’étaient pas stockés dans MySQL…
May/081
Modifier le innodb_log_file_size
Je me suis déjà fait avoir 2 fois par cette option. Si vous avez des tables InnoDB avec un gros load d’écriture (insert, update), il est généralement recommandé d’avoir un innodb_log_file_size assez élevé. Mais soyez vigilant: plus la grosseur du log file est élévée, plus le temps de recovery est long dans le cas d’un crash.
Mais peu importe. Là ou je veux en venir, c’est sur la manière de modifier cette option. InnoDB est un engine capricieux et innodb_log_file_size est l’un de ses caprices. Les logs jouent un rôle très important dans plusieurs concepts d’InnoDB. Il y stock un tas d’information comme le schema de certains .frm et d’autres metadata. Le problème est qu’on ne peut pas simplement modifier la grosseur du log dans le my.cnf et repartir le serveur. En fait oui, c’est possible et le serveur ne fera pas d’erreur. Mais aucune table InnoDB ne sera utilisable.
La manière de faire est relativement simple.
- On s’assure que la variable innodb_fast_shutdown ne vaut pas 2.
- Si la valeur de innodb_fast_shutdown est 2, il faut la changer pour 1, arrêter le serveur, le repartir, et l’arrêter de nouveau. Ceci permet à InnoDB de fermer correctement.
- On arrêtele serveur
- On modifie la configuration
- On renomme le fichier log lui-même
- On repart le serveur
En renommant le fichier, MySQL va recréer un nouveau log avec la nouvelle grosseur spécifiée dans la configuration au redémarrage. Si tout se déroule bien, on peut supprimer l’ancien log qu’on a renommé. Parcontre, si quelque chose tourne mal, il est possible de remettre l’ancienne valeur de innodb_log_file_size, deleter le nouveau log file et remettre l’ancien qui a été renommé.
InnoDB s’attend à toujours avoir un log de la même grosseur. En modifiant l’option, la grosseur spécifiée dans la configuration et la grosseur réelle du fichier ne concorde plus. C’est pour cette raison que nous devons en recréer un tout neuf, avec la bonne grosseur.
Si comme moi, vous avez oublié de renommer l’ancien log file, MySQL ne vous indiquera pas que c’est le innodb_log_file_size qui est le problème. Vous aurez tout simplement des erreurs lorsque vous tenterez d’accéder ou écrire dans une table InnoDB.
Apr/080
Pourquoi il ne faut pas utiliser le type CHAR avec InnoDB
Utilisez le type de colonne VARCHAR au lieu de CHAR si vous stockez des chaînes de taille variable, ou si une colonne peut contenir plusieurs valeurs NULL. Une colonne CHAR(N) prend toujours N bytes pour stocker les données, même si la chaîne est plus petite, ou que sa valeur est NULL.
Mais encore ! InnoDB est un engine complexe qui ajoute des données supplémentaires à chaque entrée et à certaines colonnes. Parmi ces informations se retrouvent notamment les indexes. Vous devez savoir que le type CHAR est fixe et qu’un coup les données supplémentaires ajoutées, il requiert encore plus d’espace en mémoire et sur le disque dur ! Physiquement, les données sont écrites dans des “pages” de 16KB (généralement) ce qui pousse le système à utiliser une page supplémentaire pour stocker les données supplémentaires si le champ CHAR demande 16KB.
Avec un champ de type VARCHAR, si les données sont plus petites que 16KB il sera peut-être possible de stocker les informations supplémentaires dans la même page. Ceci réduira le nombre de lectures du disque dur.
Comme il est difficile de connaitre le nombre de KB exactement utilisé pour un enregistrement d’InnoDB, il est recommandé de toujours utiliser le type VARCHAR. Même avec des champs entièrement fixes, l’espace utilisé varie avec les indexes.
Si vous voulez plus de renseignements sur le fonctionnement de InnoDB : http://forge.mysql.com/wiki/MySQL_Internals_InnoDB.