dbnewz

Modifier une petite ligne dans le fichier de configuration de son SGBD et obtenir les performances souhaitées, c’est possible… si vous êtes chanceux. La performance globale d’un SGBD repose en effet sur un ensemble de briques, logicielles ou matérielles, qui une fois empilées correctement forment un ensemble cohérent (et performant) : la seule étape du fichier de configuration ne suffit pas.

Dans un de ses récents billets, Matt Yonkovit a déclenché une série de réflexions intéressantes à propos de l’impact des performances des disques durs sur l’ensemble du SGBD.

Selon lui, les problèmes de performance au sein d’un SGBD sont la plupart du temps relatifs aux disques durs et notamment au nombre d’I/O (Entrées/Sorties) qu’ils sont capables de traiter par seconde (IOPS).

Comparés aux processeurs actuels capables de prendre plusieurs milliards de décisions par seconde (Ghz) et aux mémoires vives dont les temps d’accès se mesurent en nanosecondes, le temps d’accès d’un disque dur se compte encore en millisecondes… Difficile de lutter contre des éléments purement électroniques quand on est constitué d’éléments mécaniques en mouvement (têtes de lecture, plateaux…).

Afin d’avoir recours le moins possible aux disques, l’utilisation des index est une première étape qu’on complètera par différents mécanismes de caching afin de limiter encore davantage les accès à ce support et éviter ainsi que le disque ne constitue un goulet d’étranglement (”I/O bound”).

Outre ces mécanismes, la technologie SSD pourrait bien à l’avenir changer la donne.

Les SSD, littéralement Solid-State Drives (ou Disk par abus de langage), ne sont pas des disques mais des unités de stockage constituées de mémoire flash (persistante).

Au vu des benchmarks les concernant, il y’a fort à parier que les SSD seront de plus en plus d’actualité dans les mois qui viennent.
Ces benchmarks sont unanimes sur un point : les SSD obtiennent d’excellentes performances lors des random read, laissant loin derrière les disques “classiques”. Grosse ombre au tableau néanmoins : les tests effectués sur des random write ne sont pas aussi concluants. Pourquoi ?

Sur un disque classique un “random read” entraîne (du plus couteux au moins couteux) :
- le déplacement de la tête de lecture/écriture sur la bonne piste (”seek time”)
- une fois la tête sur la bonne piste, il faut encore repérer sur celle-ci le bloc secteur demandé (”rotational latency”)
- la lecture et la transmission de la donnée vers le système.

Avec un SSD, le même “random read” est beaucoup plus rapide : pas de tête de lecture à déplacer ni d’attente liée à la rotation d’un plateau. Conclusion, comptez environ 5 ms de temps d’accès à un secteur particulier pour un disque performant et environ 0.15 ms pour un SSD.

En revanche, lors d’une écriture, le SSD est par conception beaucoup plus lent qu’en lecture : la “préparation” obligatoire de l’importante zone dédiée à l’écriture (”erase block”) et un ensemble d’écritures spécifique à cette technologie pénalisent les performances.

Face à ce problème connu, des parades logicielles voient le jour et la plupart des constructeurs de SSD proposeront sûrement leur propre solution dans les mois à venir. Actuellement la technologie MFT (Managed Flash Technology) offre déjà de grandes améliorations (cf lien “benchmarks” ci-dessus, 3ème graphique). Les performances obtenues sont sensiblement égales lors des random read par rapport aux SSD classiques mais les résultats sont 30x supérieurs en random write par rapport aux SSD et 15x supérieurs aux disque durs.

Enfin, un autre signe que le SSD est très certainement une technologie d’avenir : un des plus récents moteurs pour MySQL, PBXT, est conçu pour fonctionner avec les SSD (pdf).

Pour résumer, concernant les SSD :

Avantages :
- Très rapide en random read
- Peu sensible à la fragmentation des fichiers : performances constantes.
- Fiabilité supérieure au HD (pas d’éléments mécaniques en mouvement)

Inconvénients des SSD :
- Prix
- Capacités en deça des disques actuels
- Durée de vie plus courte qu’un disque (nombres de cycles d’écriture limités)

Améliorations attendues (et en cours) :
- Chute des prix
- Augmentation des performances en écriture
- Augmentation de la capacité
- Meilleure répartition des écritures sur le support (augmentation du nombre de cycles écritures / durée de vie)

Si cette rapide présentation des SSD a aiguisé votre curiosité, voici quelques pistes pour aller plus loin :
- Le blog de Kevin Burton.
- La rubrique SSD sur Wikipédia (notamment les références en bas de page).

Bonjour à tous, premier post sur dbnewz, c’est donc l’occasion de me présenter.
En quelques mots, je suis d’abord un passionné d’internet. J’ai la chance de travailler dans le domaine qui me passionne depuis 2000. D’abord ingénieur développement puis rédacteur/auteur et à nouveau ingénieur développement, c’est dans la peau d’un “ingénieur bases de données” que j’ai assisté à la dernière MySQL Conference. Pour la petite histoire, c’est lors d’un “MySQL Quizz Show” pas avare en soda et pop-corn, que le père de dbnewz aka “pébé” m’a proposé de participer à ce blog. Vous savez tout, ou presque : la rubrique “à propos” a également été mis à jour.

Les présentations étant faites, retour au sujet de ce premier billet : la récente MySQL Conference. Si vous n’avez pas eu la chance d’y assister (elle se tenait du 14 au 18 avril dernier à Santa Clara), surtout ne ratez pas les présentations (pdf, ppt..) des différents conférenciers désormais disponibles sur le web. Certes ces slides ne compenseront pas l’aspect humain qui fait le charme d’une telle conférence (nouveaux contacts, retrouvailles…) mais techniquement au moins, vous serez servis.
Au menu des dizaines de présentations et de retours d’expérience sur l’état de l’art de MySQL. Les thèmes abordés sont nombreux : la réplication, les moteurs de demain (PBXT, Maria), la gestion de la montée en charge, la haute disponibilité, la technologie cluster, le benchmarking mais aussi des “best practices” sur les stratégies de backup, de sécurité…
Certaines présentations sont également disponibles en vidéos ce qui permet de se rapprocher encore davantage de ce qui se passait à Santa Clara, et de donner envie à ceux qui ne l’ont pas encore prévu de s’inscrire pour l’année prochaine ?

Les liens :
Outre le site officiel qui recense les présentations disponibles par ordre alphabétique, rendez-vous également sur le wiki de la conférence pour y trouver un découpage par journées ainsi que certaines vidéos et de nombreuses photos.

La vie est faite de hasard et de rencontres. Cette fois-ci, j’ai eu le plaisir de rencontrer Arnaud à la dernière conférence MySQL UC. Devant son talent et sa motivation, j’ai rapidement eu l’envie de le voir participer encore plus à la vie de la communauté française. C’est avec joie que je vous informe de sa volonté de me rejoindre sur ce blog. Bienvenue Arnaud!

Arnaud: “De l’éléphant Php au dauphin MySQL, je navigue entre deux mondes étroitement liés : le développement web et les bases de données. Actuellement “ingénieur bases de données” chez un opérateur internet / télécom, je manipule particulièrement MySQL (tuning, réplication, cluster…) avec un soupçon de PostgreSQL. Je participe notamment à l’élaboration de solutions à forte audience capables de monter en charge et d’assurer une haute qualité de service.”

Je vous laisse le plaisir d’en découvrir plus dans les semaines à venir sur DBNewz.

En regardant le blog de Colin, je ne peux m’empecher de penser à ces très bons moments passés à Heidelberg…
Voilà la photo:

3 keynotes ce matin:

• State of MySQL MÃ¥rten Mickos (MySQL), Rich Green (Sun Microsystems, Inc)
• Open Source: The Heart of the Network Economy Jonathan Schwartz (Sun Microsystems)
• A Head in the Cloud - The Power of Infrastructure as a Service Werner Vogels (Amazon.com)

C’est la 1er fois que j’assiste à une présentation de Mr Schwartz et je dois dire que j’ai bien apprécié… C’est officiellement parti… les sessions commencent!

ET C’EST PARTI pour l’édition 2008 de la MySQL UC. Quel plaisir de retrouver les membres de la communauté! Le premier jour est consacré aux tutoriaux. J’ai choisi de suivre:

• Building Scalable & High Performance Datamarts with MySQL
• SQL Antipatterns

Nous allons parler de Datamarts toute la matinée, pour l’instant nous en sommes à la partie technique… j’attends la partie consacrée à MySQL.

Many things in the current IT world are based around hard facts, solid experience and studied techniques. Unfortunately this tends not to be the case when it comes to application developers making database decisions. This is not a criticism of application developers per se, their expertise lies in the app technology, but more a problem with development process and a misunderstanding of the role of the database as the underpinnings of data oriented (as opposed to object oriented) application architecture.The general process of modern agile application development proceeds along fairly set lines of iterative feature based and hopefully test driven development. This approach of getting something working with a suite of tests around it which enable rapid refactoring and rapid development run counter to most Big Design Up Front (BDUF) methodologies, most notably the much maligned waterfall model and the general approach taken to most database driven methods. To truly be an agile database developer in this brave new development world implies a level of clairvoyance beyond most of us, and requires an understanding of future application direction and projected data growth which is beyond that which can be expected of application developers and their product managers. To ignore this difference in requirements of the agile developer and the data modeller/DBA will invariably lead to scalability and performance issues as the project moves forward through its multiple iterations.

We are not saying here that the focus and philosophy of the agile development team and that of the database designer/administrator are incompatible, more that there is a difference in the needs and aims of the two groups and that this difference needs to be recognised as such. This is not always the case in the necessary drive to shift development paradigms. The larger the project, the more apparent this becomes. Changing code is not the same as changing data. A database at the core of a complex multi tier application will usually be supporting many different access paths, from the OLTP requirements of a running user driven application to the reporting requirements of management and maintenance as well as a suite of custom administration interfaces, data feeds in and out as well as the requirements for failover and disaster recovery, and refactoring, recoding and changing requirements is not as simple as that of single parts of the overall codebase.

While there are database methodologies to support agile development, generally the current processes have database design/deployment/administration as worrying separate, and the realms of all the pieces of getting a product from the back of a restaurant napkin to global server deployment need to incorporate the whole iterative development process. We should not be in the position of giving the DBAs the code to deploy when the iterative cycle ends. This is simply unacceptable from an architecture and process point of view. What we have here is a series of failures in using the best people for the job.

As mentioned above, application developers are not generally the best people to be structuring and modelling the data. Data structures, no matter how well abstracted, are fundamentally tied to the underlying technology. Sensible design and architectural decisions can only happen if the data specialists are incorporated into the agile development teams themselves. We can, and need, separate database administration teams, but also, these teams must be part of, or have significant input into the development process, else all roads lead to project misery, to poor use of software/hardware and the continuation of the ignorance loop, as mistakes in data structure and design are rarely fed back up to the original designers. Adding features to code and refactoring as we go works for code, it rarely works in practice for data. It is not so much the new features that is the problem, it the short-termism which the process unconsciously encourages which lies at the heart of the problem. Large data volumes require a degree of foward planning that is often lacking from our short Sprint focused design decisions.

Ignoring data modelling disasters, most projects start off with a fairly well understood and structurally sensible data structure (bear with me here) for the first few iterations of the system. These first set of requirements generally have the data model supporting them happily. The issues only usually really arise as the codebase and feature list grows, along with the growing datasets. Data structures that support smaller volumes of data do not necessarily scale linearly and a lack of understanding of the changing nature of the system will cause problems for the future of the application due to information not flowing back from the DBAs about the current state of the system, as well as the new demands being placed on it from the continuous feature development of the agile processes. Changing requirements are all part of the agile world, and are part of the power of this type of development, and additional features pose less of a problem than feature modifications, but the focus of short iterative steps can easily lead to a loss of focus on the greater need of the ability of the database and the datamodel itself to support the changing application.

In conclusion, for our agile data development processes to succeed, we need to use the skills where they are best suited. Database abstraction layers need to be tested by the database specialists, not in isolation, but within the application context itself, and any fundamental design decisions should be made by the people who understand the systems involved, at all levels.

Voici mon problème du jour : Comment lancer un script (de maintenance par exemple) qui fait appel à mysql, sans stocker en dur le nom de l’utilisateur et le mot de passe (ce qui est mal, très très mal). Le but est que seul un utilisateur privilégié (je n’ai pas forcément dit root ! je pense plutôt à un compte système comme mysql par exemple) puisse lancer ce script.

C’est plutôt facile, et je fournis trois solutions pour la peine :

1. Avoir un fichier de configuration pour le script accessible seulement par l’utilisateur privilégié

   On définit dans le fichier de configuration des variables d’environnement, une pour le user, une autre pour le mot de passe. Dans le script il ne reste qu’à utiliser la commande source pour récuperer ses variables (seul l’utilisateur privilégié pourra lire le fichier). Simple et efficace.

2. Avoir un fichier de configuration pour mysql accessible seulement par l’utilisateur privilégié

   Variante de la précédente : on crée un fichier de configuration spécifique pour mysql (que l’on pourra mettre par exemple dans /etc/mysql mais il n’y a aucune obligation). Et on utilise l’option –defaults-file pour que mysql lise le contenu du fichier (il lit notamment les sections [client] et [mysql]). Exemple de fichier:
   
[client]
host = localhost
user = votre_user
password = votre_mot_de_passe
socket = /var/run/mysqld/mysqld.sock

   Bonus : on peut spécifier d’autres options pour influer sur mysql (en vrac, le nom de serveur, le jeu de caractères…).

3. Pour ceux qui ont plusieurs scripts mais qui ont des options qui diffèrent légèrement

   Vous avez des scripts quasiment identiques mais les options diffèrent légèrement (ou vous voulez centraliser tout en un seul fichier) : c’est possible. C’est une variante du cas précedent : on écrit un fichier de configuration mysql que l’on découpe en plusieurs sections. Ensuite, on fait appel au programme my_print_defaults ! my_print_defaults examine le fichier de configuration (option -c pour spécifier le votre…) et donne en sortie les paramètres à passer à mysql sous forme d’argument. Exemple :
   
$ my_print_defaults -c /etc/mysql/maconf.cnf client
--host=localhost
--user=votre_user
--password=votre_mot_de_passe
--socket=/var/run/mysqld/mysqld.sock

   Il ne reste plus qu’à passer cela à mysql en récuperant la sortie dans une variable (ou en utilisant cette petite merveille de xargs).

Le séjour n’est pas encore fini mais je peux déjà vous livrer quelques sentiments de cette immersion dans le monde des développeurs MySQL. L’ambiance y est excellente, tout le monde est heureux d’être présent. Néanmoins ce ne sont pas des vacances pour autant. Le petit déjeuné est pris en 7:30 et 8:15 et est suivi par de nombreux team meetings. L’après midi se concentre plus sur des sessions université MySQL.. Ces sessions étant vraiment orienté développeur je dois dire que j’ai vu en quelques jours plus de code C++ que je n’en ai vu en des années… Enfin c’est un vrai plaisir de voir les nouveautés présentées par leur auteurs. Cet événement réuni plus d’une centaine de “MySQLers”, principalement développeurs mais aussi quelques formateurs, QA,… et une dizaine d’invités externes…

Les différences avec la conférence utilisateurs:

• pas de sales, ni de marketing, tout y est très technique, nous parlons plus d’optimisation, de modifications de MySQL que d’utilisation de la base
• beaucoup moins de personnes, ce qui permet de rencontrer le maximum de personne et discuter de sujets variés.

En parlant de User Conférence, la prochaine est déjà prévue du 15-18 Avril 2008, toujours à Santa Clara et j’y serai évidement. Je dois trouver ce que je pourrai y présenter avant le 30 octobre…

MySQL AB est une compagnie mondiale. La plupart des employés sont de part le monde et travaillent de chez eux. Les échanges se font le plus souvent par emails, blog, téléphone, IM et IRC. Une fois par an, ils se retrouvent pour un “MySQL Developer Meeting”. Cette année encore, cette rencontre a lieu à Heidelberg en Allemagne et débute aujourd’hui 19 Septembre 2007 pour finir dimanche. Suite au billet de Kaj qui a rendu la nouvelle officielle, nous y avons appris que certaines personnes de la communauté sont invités à y participer. J’y serai à partir de ce soir et essayerai de vous tenir au courant des nouveautés qui ne sont pas confidentielles. En effet j’ai du signer un accord de confidentialité.