Quelle est la différence avec un forum? Nous retenons les meilleures questions et nous écrivons un article avec la dite question et sa réponse. Si vous ne voyez pas votre question, c’est que nous n’avons pas encore eu le temp d’y répondre…

A très bientôt!

PS: Cette adresse peut aussi être utilisée si vous constatez un problème sur le site…

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).

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.

Cet outil est sensé me simplifier la vie pour migrer des bases Sybase, Informix et DB2 vers de l’Oracle. (Oracle9i et Oracle10g). Il s’occupe du schéma, des triggers, des procédures stockées. Serait ce l’outil magique? Bon il n’est pas encore capable de modifier votre application client si vous utiliser du SQL spécifique à votre SGDB mais qui sait.

Premier bémol, il ne semble supporter que du DB2 sous Windows. En 8 ans de carrière je n’ai encore jamais joué avec des serveurs DB2 sous Windows, de l’AIX du Linux oui. Pour moi Windows s’arrête avec MSSQL serveur. La suite de cet aventure pour les mois à venir.