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 ...Mar/092
Truc rapide pour faire un csv avec MySQL
Je dois régulièrement créer des rapports pour la comptabilité (et d’autres gens moins à l’aise avec des ordinateurs) au boulot. Le moyen facile est de leur envoyer le tout dans un fichier CSV converti en excel par email.
Il y a plusieurs manières de créer un CSV à partir de MySQL. Voici la manière que je qualifie de “standard”:
-
SELECT a,b,a+b INTO OUTFILE '/tmp/result.txt'
-
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
-
LINES TERMINATED BY '\n'
-
FROM test_table;
Une manière un peu plus rapide (trouvé en fouillant sur google):
-
mysql -umyUser-p dbName -B -e "SELECT a,b,a+b FROM test_table;" | sed 's/\t/","/g;s/^/"/;s/$/"/;s/\n//g' > filename.csv
Et maintenant.. (roulement de tambour).. “MA” manière!
-
CREATE TABLE test_table_csv SELECT a,b,a+b FROM test_table; ALTER test_table_csv ENGINE = csv;
Maintenant, si vous allez voir dans /var/lib/mysql/dbName/ vous y trouverez un fichier csv nommé test_table_csv.CSV. MySQL s’est occupé de la syntaxe “compliqué” pour nous! Le seul inconvénient de cette manière est que vous devez avoir les permissions pour lire /var/lib/mysql.
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.
Dec/083
Ça fait quoi un DBA ?!
Parfois, et surtout durant les fêtes, on me demande ce que je fais dans la vie. Je suis DBA, ou Administrateur de Base de Données. 95% des gens à qui je réponds ne savent pas ce que je fais. Alors, j’explique qu’est-ce qu’une base de données et le type d’application propice à en utiliser, et j’opte pour les exemples:
- Je m’assure que la BD est performance
- Je m’assure de l’intégrité des données
- Je m’assure qu’il n’y aura pas de downtime
- Je m’assure des backups
Beaucoup de gens ne comprennent toujours pas ce que je fais, mais bon, tant pis je vais pas leur donner un cours.
Tout ça me fait réfléchir sur ce que font concrètement les gens qui ont un emploi comme moi. Les 4 points que je donne en exemple ne sont souvent pas suffisants pour occuper un employé à temps plein, à 40h par semaine.
Pour ma part, mon background de développeur me permet de participer activement à l’analyse de nouveaux projets qui utiliseront une base de données. De plus, je m’occupe de la performance de notre application, car même avec un serveur MySQL dédié ultra performant, les performances peuvent être décevantes si l’application ne communique pas adéquatement avec la BD.
Au-delà du boulot quotidien, j’essaye de me tenir à jour sur tous les nouveaux features de MySQL et les nouvelles technologies en lien avec les bases de données. J’anticipe l’utilisation des features de 5.1 et 6.0 sans négliger la possibilité d’utiliser autre chose que MySQL, comme Drizzle ou PostgreSQL ou encore utiliser les nouveaux storage engines comme XtraDB de Percona.
Je vous pose donc la question: quelles sont vos tâches quotidiennes en tant qu’expert en technologie de l’information ?
Aug/083
MySQL Performance Tuning à Montréal
Je vous parlais récemment du cours MySQL Performance Tuning, et contrairement à ce que je disais, j’ai pu y assister. J’aurais aimé que le cours parle de la configuration du serveur sur lequel se trouve MySQL, car un OS bien optimisé va évidemment offrir beaucoup de performance à MySQL. Mais étant donné que plus d’une 20aine de plateformes sont supportés, nous pourrions en discuter pendant plusieurs semaines. En fait, le cours focus principalement sur la configuration et l’utilisation qu’on en fait.
Il n’y a pas d’option magique à activer pour que MySQL performe bien. Il n’y a pas non plus d’outil statistique comme ceux d’Oracle qui permet automagiquement de comprendre la charge de travail et s’ajuster en conséquence (Notez cependant que c’est un feature prévu avec Falcon). Le Tuning avec MySQL est une question de feeling. Lorsqu’on connaît comment le serveur est fait, qu’on connaît tous les buffers et logs des différents Storages Engine, il est possible de savoir et prévoir qu’est-ce qui sera performant ou non pour toutes sortes de situations. Il reste ensuite à valider que nos choix sont optimales avec une série de tests (benchmarks).
Le cours dure 4 jours et nous permet de voir derrière le rideau, c’est à dire comment les données sont manipulées à l’interne. Les sujets qui m’ont plus marqué sont:
- Les index (les préfixes, les covering index, les clustered index d’InnoDB, les index sur une table MEMORY, etc…)
- Pourquoi et comment choisir un Storage Engine plutôt qu’un autre
- Les outils de benchmarking
- La normalisation et la dénormalisation des tables
- La mécanique derrière les storage engines (leurs buffers, leurs systèmes de log, leur features spécifiques, etc..)
- Comment tirer avantage des nouveaux features de MySQL 5.0 et 5.1 (View, Stored Procedure, Trigger, Partitionning, etc..)
En conclusion, j’ai bien aimé le cours. Même si certains chapitres ne sont que de la revision, il y a toujours matière à réfléchir et je vais retourner au boulot avec un tas de nouvelles idées.