Retour sur le meetup SkySQL / Le mug

Publié le Mis à jour le

Fin avril Le Mug organisait un meetup à Paris avec SkySQL. L’occasion de se tenir au courant des dernières avancées dans le stockage des données autour d’une bière irlandaise…

Au programme un premier sujet toujours intéressant sur la haute disponibilité et une présentation des différentes architectures possibles, et un sujet plus étonnant sur NoSQL ou l’on pourrait s’attendre à une critique assez basique de ce challenger, mais qui va nous amener bien plus loin…


SkySQL

SkySQL est une société composée à 90% d’anciens de MySQL. Ses misions sont variées : missions de conseil, formation, support & support niveau 3 (bugs) de MariaDB.

SkySQL est très proche de Monty Program société à but non lucratif chargé du développement de MariaDB.

Le MUG


Le MySQL User Group est une association dont le principal but est de promouvoir la base de données MySQL auprès des professionnels et de participer à son développement.

Après une rapide présentation des intervenants, place aux résumé des conférences.

Les architectures hautes disponibilité

Par Joffrey Michaie, consultant MySQL chez SkySQL

Réplication MySQL

La réplication MySQL permet de s’assurer que les données sont sauvegardées dans de bonnes conditions et réutilisables rapidement en cas de problème. Elle permet également de fournir une meilleure qualité de service en production avec un système maître / esclaves. Cette solution offre des possibilités de réplication sur plusieurs niveaux.

Réplication asynchrone locale

La réplication asynchrone propose de nombreux avantages :
– Pas d’impact sur la prod en cas de sauvegarde ;
– Redirection de trafic partielle ou totale sur slave ;
– Réplication entre plusieurs sites géographiques ;
– Natif dans MySQL / Indépendant de la plateforme, de la version ou du moteur de stockage ;
– Réplication Master / Slave, Master / Master, ou Circulaire.

Par contre, elle présente un inconvénient non négligeable. De par sa nature asynchrone, elle ne garantit pas de copie en temps réel, ce qui peut être problématique pour des écritures simultanées. A préférer pour fournir des accès en lecture de façon massive donc.

Réplication semi-synchrone locale (depuis MySQL 5.5)

La réplication semi-synchrone apporte plus de consistance au niveau des données grâce à une vérification systématique de la copie des données sur un serveur esclave, ainsi il n’y a pas de perte de données en cas de crash.

Niveau inconvénients, on notera une perte de performance causée par un aller-retour réseau en plus et un aléa dû à une copie binaire, qui n’assure pas que les esclaves peuvent fournir la donnée en temps réel.

Réplication synchrone via DRDB (Block Device)

Ce mode apporte une réplication certifiée, un switch instantané et garantit la consistance des données pour un coût limité.

En revanche, il propose seulement une configuration Master / Slave, ne fonctionne qu’avec InnoDB (possible avec MyIsam mais très lent) et uniquement sur une architecture Linux.

Il faut également noter que cette solution est très dépendante de la capacité du réseau !

DRDB + MySQL Réplication

La combinaison de DRBD et MySQL Replication permet plus de disponibilité, puisque lors de mises à jour, les esclaves restent disponibles en lecture.

Active/Passive Cluster

Ce système consiste à mettre plusieurs serveurs sur le même disque (NAS) ce qui permet un switch rapide. Cependant, le NAS devient le maillon faible de cette solution.

Virtualisation

La virtualisation permet aussi un switch rapide mais avec la même réserve puisque le stockage reste le maillon faible et oblige à faire des snapshots très régulièrement.

MySQL Cluster

Cette solution est semblable à un moteur InnoDB, mais permet modification des tables à chaud (Ajout de colonnes à chaud…) et garantit une très haute disponibilité.

Avantages :
– Branchement / débranchement de serveur à la volée ;
– Très haute disponibilité ;
– Ajout de processeur ou de mémoire sans couper le service ;
– Mise à jour de version de MySQL sans couper le service ;
– Réplication instantanée ;
– Réplication géographique asynchrone possible.

La solution ultime ? Probablement mais, elle est d’une complexité importante et a un coût humain élevé. On notera aussi qu’elle n’est pas optimisée pour certaines requêtes avec des jointures.

Petit rappel sur les moteurs

Un petit rappel rapide sur les intérêts des principaux moteurs en termes de performances et d’intégrité des données :

MyIsam :
– Données en cache, pas d’assurance qu’elles soient écrites physiquement sur le disque
– Verrou par table

InnoDB :
– Intégrité des données
– Verrou par ligne
– Mécanisme de recouvrement rapide en cas de crash

MySQL Cluster :
– Semblable à InnoDB
– Modification des tables à chaud
– Haute disponibilité

NoSQL

Par Stéphane Varoqui, consultant MySQL senior chez SkySQL

16 des 20 plus gros sites Web utilisent MySQL, qui est donc bien implanté, mais NoSQL se pose en challenger. Il apporte de nouvelles fonctionnalités pour de nouveaux usages, principalement pour du cache.

Caching

À la question : Qui utilise APC ? 10% seulement de la salle lève la main ! À peu près 25% pour l’utilisation de NoSQL.

La question à se poser si l’on hésite entre SQL & NoSQL, est : “A-t-on besoin de consistance ?”

Pour une application Web, les différents niveaux de cache sont :
– Browser cache ;
– CDN ;
– Web server cache ;
– Memory cache ;
– Database server cache ;
– Disk Storage.

Memcached

La présentation se focalise sur l’exemple de Memcached, pour lequel il est important de prévoir plusieurs caches pour les invalider séparément. Il faut également bien penser à utiliser des caches pour des données réutilisables, et ne pas saturer le cache avec des données que l’on ne rappellera pas !

Le versionning des clés de cache, permet également une gestion fine de l’invalidation du cache par zones. Des outils de monitoring existent et permettent de s’assurer du bon fonctionnement des outils.

Les avantages apportés par cet outil sont :
– Non bloquant
– Multi threadé
– Gestion avec telnet possible (port 11211)

Mais en terme de volume de stockage, rien de comparable aux bases de données…

Handler_Socket

C’est un plugin pour MySQL développé par des Japonais. C’est en fait l’implémentation de l’API memcached en front sur MySQL. On attaque directement les moteurs de stockage, en évitant la très coûteuse couche de parsing SQL.

Pour info Handler Socket est disponible sur Github et fonctionne sur le port 9998.

Les avantages par rapport à un accès SQL classiques sont :
– Moins de CPU ;
– Opérations simples et rapides ;
– Jusqu’à 1 000 000 de requêtes/s ;
– Requête en range et gestion des limites (pas possible en NoSQL classique).

Pour éviter des problèmes de latence, il est important de l’utiliser avec des données chargées en mémoire, les performances sont nettement moins bonnes avec un accès aux données du disque dur.

MySQL et NoSQL

Alors que fait MySQL pour gérer l’arrivée de nouveaux challengers sur le domaine du stockage de données ? Et bien c’est la piste de l’intégration de solutions innovantes dans les prochaines versions qui a été choisie ! NoSQL n’aura jamais aussi bien porté son nom, puisque désormais on pourra utiliser conjointement SQL et NoSQL !

MySQL 5.6.2 embarque Memcache dans MySQL[voir sur [http://labs.mysql.com/.]], ce qui permet d’éviter le parsing SQL tout en conservant les avantages d’InnoDB et notamment la consistance qui fait défaut à certains outils NoSQL.

MariaDB 5.2 y ajoute le support des Virtual column, ces colonnes calculées mais non stockées (l’équivalent des vues adaptées aux colonnes). Quant à MariaDB 5.3, qui sortira peut être avant la fin de l’année, ce sont les HANDLER commands qui font leur apparition et permettent d’utiliser une implémentation de Handler_socket de façon native et avec quasiment les mêmes performances !

Exemple :

HANDLER login READ ‘PRIMARY’ = (?);

MariaDB 5.6 ce sera, Hbase Storage Engine for Dynamic Column avec le
passage de « document base » à « hbase » de manière à optimiser le stockage en « colonne » plutôt qu’en « ligne ».

Et pour les plus curieux, on nous conseille de jeter un œil à Drizzle pour stocker le query cache avec memcached et augmenter les performances ! À tester donc !

Conclusion

Merci à SkySQL et à le Mug pour l’excellent accueil. Au final, on retiendra plein de promesses vraiment dignes d’intérêt, et que l’on attend désormais avec impatience. MySQL est une solution qui a de beaux jours devant elle, et le pari d’utiliser conjointement SQL & NoSQL est à mon avis tout à fait pertinent !

Si vous avez des retours sur ces nouvelles solutions, les commentaires sont là pour cela !

En savoir plus…

Les supports des conférences :
– [http://www.lemug.fr/2011/les-supports-de-la-conference-mysql-avec-skysql->http://www.lemug.fr/2011/les-supports-de-la-conference-mysql-avec-skysql]

Les organisateurs de la soirée :
– SkySQL : http://www.skysql.com/fr/index
– Le MUG : http://www.lemug.fr


  • Bases de données

  • Conférence

  • MySQL

  • NoSQL