dbnewz

Monty, un des fondateurs de MySQL, a quitté SUN/MySQL il y a quelques mois et à depuis fondé Monty Program AB la société dernière MariaDB. Il a écrit une très grande partie du code de MySQL. Ce qui m’avait impressionné la première fois ou je l’avais rencontré c’est qu’il connaît le code source presque par coeur. Vous lui dites, « j’ai un problème à cet endroit »… en quelques minutes, il est capable de savoir de quel partie du code cela vient. Impressionant.

Autre chose sur Monty, il a 3 enfants:

• sa fille My – MySQL
• son fils Max – MaxDB
• sa fille Maria – moteur de stockage Maria – MariaDB

des choses comme celles là ne s’inventent pas.

Revenons sur MariaDB, c’est la version communautaire de MySQL 6.0 qui utilise par défaut le moteur de stockage Maria, mais supporte aussi InnoDB, XtraDB, PBXT,…

Maria est une évolution de MyISAM, au départ développé pour palier les problèmes de corruptions de MyISAM. Au final, ce moteur présente bien des avantages au niveau des performances, montée en charge et fiabilité sans compter des nouveaux types d’index pour les requêtes de type SCAN.

MariaDB est quelque chose à surveiller de très prêt.

Si vous êtes un MAC addicted comme moi, vous connaissez l’outil Time Machine d’Apple qui permet de faire des sauvegardes ( idéalement avec la Time Capsule ). L’outil attendu depuis des années pour faire des backup/restoration, surtout des « Point in time recovery » qui permet de revenir exactement à une période dans le temps.

Le concept est simple:

• backup à chaud avec enregistrement des positions des binlogs
• backup des binlogs

La console Web permet de gérer tout cela et de programmer les prises de backup. C’est basé sur l’outil MySQL Backup disponible avec la 6.0.

Les étapes:

• backup sur le server
• backup data copié sur le TM server

Personnellement je trouve l’idée très intéressante maintenant, est ce un vaporware? est ce dispo pour la prod? A voir.

Trop c’est trop. Déjà à l’époque,nous devions choisir entre un nombre incalculable de sessions… En effet sans compter les keynotes, il y avait 8 presentations en parallèle. Nouveauté cette année, en plus des sessions « standard », le MySQL camp et la conférence performance de Percona. Evidemment les horaires ne correspondent pas, et je vais devoir courir d’une salle à l’autre. Ceci sans compter les rendez-vous et les discussions de couloir…

Ce matin, j’ai zappé le keynote MySQL pour aller voir celui de Peter ( Percona ), suivi par une présentation de MariaDB… un café avec Jay Pipes, ancien manager de la communauté US et maintenant développeur pour drizzle…. puis de retour à la conf pour suivre « Build Your Own MySQL Time Machine » et « Using Q4M: A Message Queue Storage Engine for MySQL »… puis direction Percona pour voir « Your Disk Array is Slower Than it Should Be » de Paul Tuckfield / YouTube qui avait donné un excellent keynote l’année dernière…. enfin rendez-vous avec Andy Oram avec qui j’avais travaillé pour High Perfomance MySQL ( Technical Reviewer )…

Je n’ai pas encore décidé la suite de la journée… Je ne veux pas avoir l’air de me plaindre car j’apprécie la chance d’être là, mais c’est loin d’être des vacances si vous voulez tout suivre.

Je connais Paul depuis maintenant quelques années, quand PBXT était seulement un petit projet qu’il avait commencé tout seul en parallele de son activité principale. 3 ans après, PBXT est un moteur de stockage qui concurrence InnoDB. Il va nous présenter l’histoire de PBXT, les challenges qu’il a dû remplir et les prévisions sur l’avenir.

PBXT est disponible pour MySQL, MariaDB et Drizzle.

Les challenges

• CPU – Le nombre de coeurs augmente mais la vitesse reste stable
• Plus de CPU -> plus de contention
  • minimize les mutex
  • segmentation
  • read lock
  • atomic
  • bus contention
• SSD – no seek time
  • le cluster des data n’est plus essentiel

Les Bases – un record avec une taille fixe + un record avec une taille variable
Les performances de la dernière version de PBXT ( 1.0.8 ) sont aussi bonnes que celle d’InnoDB avec 16 threads en parallele. Qu’est qui à changé?
Lire le reste de cet article »

Boris et Dan nous présentent l’architecture de Zimbra composée entre autres d’un server ZCS, de Java Jetty, d’OpenLDAP, de MySQL 5.0, de fichiers de stockage et de Lucene.

Quelques chiffres pour chaque serveur :

• 95k mailboxes
• 11M message
• 530k messages a day
• 464k SOAP request per day
• 6.4M POP requests per day

Le serveur type est un quad core, 32G RAM

• ZCS a sa propre architecture pour gérer les REDO
• backup tout en une fois ( filesystem, database, ldap )
• restore – load le dernier backup and rejoue tous les REDO
• ZCS redo log – incrémental restore

Problèmes et solutions:

• Les tags d’un utilisateur sont stockés sur 1 seul entier ( 64 bits ) – évite les jointures
• trier les messages de la mailbox – ils utilisent les HINTS
• data partitionning – les différents tests
  • 1 table pour tous les users
  • 1 database par users ( limité par le filesystem )
  • 100 databases with X mailboxes in it

Wrap up:

• 40M mailboxes – ( payant )
• problème de perf IMAP
• Migration lente

John travaille pour le site eMapSite et est spécialisé dans la GIS ( Système d’information géographique ). Pour plus de détail sur le concept, je vous laisse lire la définition sur wikipedia. Les SGBDs qui se sont intéréssés à ce genre de données ont été Oracle et Postgres et maintenant MySQL. MySQL a rattrapé son retard dans le domaine.

L’idée est de découper la carte en carrés contenant le plus petit objet possible. Les index R-Tree ont été développés à cette occasion, liant les « carrés » entre eux. Charger des données en base prend généralement beaucoup de temps. John utilise un trick assez sympa. Un trigger après insertion sur une table blackhole qui calcule ensuite les données GIS et les insère dans la table adéquate.

MyISAM est le seul moteur à supporter les index r-tree. Afin d’éviter des problèmes de concurrence, vous pouvez utiliser un master en InnoDB et des slaves en MyISAM.

John nous a présenté les différentes fonctions GIS de MySQL et je dois dire que c’est assez compliqué. Les requètes sont complexes et bon, il serait temps que je révise mes notions de trigonométrie…