Meetup MariaDB du 26 juin 2014

Jeudi 26 juin 2014, je me suis rendu à un événement #mariadb organisé par SkySQL.

http://www.skysql.com/about/news-events/events/mariadb-roadshow-paris

L’occasion de garder contact avec la communauté MariaDB et échanger avec des utilisateurs de MariaDB, TokuDB, Spider, Galera Cluster, ou encore des développeurs de chez Percona.

Au programme de cette rencontre :

• La nouvelle offre MariaDB : MariaDB 10, MaxScale et plus encore
  Serge Frezefond, Cloud Solutions Architect, SkySQL Ab
• Haute disponibilité avec MariaDB Enterprise
  Stéphane Varoqui, Senior Consultant, SkySQL Ab
• Automatisation & Gestion de Cluster de Base de Données avec Severalnines
  Jean-Jerome Schmidt, VP Marketing, Severalnines
• Big Data avec MariaDB10, TokuDB et Spider
  Bernard Garros, Head of Development, Galaxy Semiconductor Solutions
  Stéphane Varoqui, Consultant principal, SkySQL Ab
• Évolutivité avec MariaDB et MaxScale: Atteindre de nouveaux sommets
  Serge Frezefond, Cloud Solutions Architect, SkySQL Ab

Les slides sont disponibles sur :

https://mariadb.com/resources/technical-presentations

Quelques notes complémentaires :

Haute disponibilité avec Galera Cluster
Galera Cluster est une solution de Haute Disponibilité (plusieurs serveurs MariaDB en réplication synchrone, multi-maître). En théorie n’importe quel noeud du cluster peut être accédé en écriture. Cependant, les intervenants mettaient en garde sur une telle utilisation de Galera Cluster : si l’application n’est pas adaptée à ce type d’usage, on s’expose à une augmentation du nombre de deadlocks et des problèmes de performances (réplication synchrone). Dans la plupart des cas, il est plutôt conseillé d’utiliser un seul noeud en serveur maître et basculer sur un autre noeud uniquement en cas de défaillance du premier. On conserve ainsi une solution de Haute Disponibilité, sans les risques liés au côté multi-master.

A noter que dans la v10.1 de MariaDB, Galera Cluster pourrait devenir une simple option de MariaDB (ON/OFF) plutôt qu’un produit séparé. A confirmer.

Automatisation : oui mais…
Stéphane Varoqui mettait en garde contre un excès d’automatisation dans le cadre de la mise en place d’un environnement de Haute Disponibilité. Certaines opérations comme la bascule de serveur maître automatique peuvent provoquer plus de problèmes qu’elles n’en résolvent. On ne peut remplacer l’humain partout.

Big Data avec MariaDB10, TokuDB et Spider
Un retour d’expérience sur une architecture autour de Spider & TokuDB. A la différence de notre projet autour de Spider sur CCM, pas de pre-sharding pour gérer la scalabilité, mais un système qui gère un historique des clefs de répartition des shards. Par exemple les données entre la date d1 et d2 sont réparties par modulo sur les serveurs a, b et c. Les données après la date d2 sont réparties sur 4 serveurs a, b, c et d. Cela est toutefois facilité du fait que les données conservées ne le sont que sur une période déterminée.

TokuDB
=> utile principalement dans le cadre d’insertions massives. Bufferise ses mise à jour d’index. Résultat : beaucoup moins d’IO disque. Sur des techno SSD, cela peut permettre d’augmenter significativement leur durée de vie.
Avec TokuDB, tous les index peuvent être clusterés (augmentation du volume mais compensé par le taux de compression)

FusionIO
Les cartes FusionIO possèdent leur propre algo de compression. Dans ses dernières versions, InnoDB peut déléguer directement la compression à la carte Fusion.

Fractal Tree (tokudb, leveldb) vs BTree (innodb)
BTree : plus rapide en mémoire vs FractalTree
FractalTree : plus rapide sur disque vs Btree
=> si la bdd et ses index tiennent en mémoire => privilégier BTree
=> sur la bdd/index est trop volumineuses => privilégier FractalTree