Technologies

Administration NoSQL : un oxymore ?

Publié le : Auteur: Christian CHABOT 3 commentaires
No SQL

La lecture d’un papier de Martin Fowler du 25 février à propos des implications de l’utilisation des solutions NoSQL sur l’administration des données (http://martinfowler.com/bliki/NoDBA.html) nous a ramené à un récent débat chez Antéo dont l’idée directrice était « le rôle de DBA a t-il encore du sens avec NoSQL ? ».

Non content de voir que Martin Fowler partage notre point de vue ;-), on pourrait prolonger ce débat sur la gestion des compétences requises pour la réalisation d’application utilisant ce type de solution mais aussi, et peut-être même surtout, pour leur maintien en condition opérationnelle.

Lors de la réalisation du développement d’application avec des SGBD classiques, la question du dimensionnement et de la disponibilité peut être repoussée aux phases d’intégration et placée sous la responsabilité d’un DBA plutôt que de celle d’un architecte ou d’un développeur.
Pour illustrer cet aspect, prenons par exemple la mise en place d’indexes, à priori par l’analyse des fonctions de recherche (finders) présentes sur les DAOs, ou à posteriori après analyse d’un plan d’exécution sur une requête complexe. Dans ces deux cas l’amélioration des performances quitte le domaine du développement pour intégrer celui de l’exploitation avec une intervention sur le SGBD. On pourra cependant objecter qu’il est possible d’améliorer les performances d’une application en agissant sur son code source ou son paramétrage, comme par exemple le chargement par lot (batch-size) dans le cas de l’utilisation d’un ORM comme Hibernate.

Avec les solutions NoSQL, on observe actuellement une tendance lourde à n’intégrer les problématiques de dimensionnement ou de disponibilité que dans le code applicatif, ou à ne répondre à des problématiques de performances qu’à travers le design applicatif retenu. En l’absence de réflexion sur la possibilité de décorréler ces aspects du code, avec un paramétrage cohérent et exhaustif ou à l’aide d’un composant de gestion spécifique, on s’oriente vers un modèle opérationnel inédit et peu réaliste.

La sollicitation d’une application évolue dans la durée et les schémas de données aussi. De ce point de vue les SGBD traditionnels sont semble t-il mieux armés pour accompagner l’évolution de l’utilisation des données sans impacter la conception applicative (gestion des tablespaces, mise en place de vues …).
La segmentation développement / production à quand même du sens lorsqu’il s’agit de mobiliser des ressources dans le temps sur des problématiques quotidiennes très éloignées. Elle n’implique pas la mobilisation de ressources de développement sur une durée d’exploitation qui est sans rapport avec celle de la phase de développement. On ne peut pas non plus demander aux DBA des compétences de programmation, ni aux développeurs les compétences requises pour l’exploitation des applications.

La réflexion lors de la mise en place de solutions NoSQL doit donc se faire aussi sur un plan systémique : quelle est la durée de vie d’exploitation de mon application ? Quelles ressources vais-je devoir mobilier ?
Voilà donc certainement des questions qu’il faut se poser et auxquelles les solutions NoSQL devront répondre dans leur évolution.

  • La rencontre meetup NoSQL de San Francisco du 11 juin 2009 a été particulièrement importante pour le développement de cette tendance. Plus de 100 développeurs de logiciels ont assisté à des présentations de solutions telles que Project Voldemort , Cassandra Project , Dynomite , HBase , Hypertable , CouchDB et MongoDB . Le concept du NoSQL a cependant une bonne décennie d’ancienneté.

  • je pense qu’avant d’envisager de passer à nosql pour un souci de performance, il faut déjà passer de mysql à postgres, et de postgres à oracle/MS server et seulement en dernier recours abandonner le sql pour NoSQL. C’est par parce que mysql ne tient pas la charge que les autres sgbrs ne le peuvent pas.

  • Emmanuel Lesne

    L’utilité d’un DBA pour les données du NoSQL est un vaste débat.

    Je te citerai un exemple dans une banque française qui a mis en place une équipe complète pour gérer les DataGrid en exploitation. Cette équipe intègre, teste et configure les applications dans des environnements représentatifs. Leurs benchs sont des montées en charge sur plusieurs jours avec des Go injectés. Une 1ère conclusion
    s’impose:
    * les développeurs n’ont pas accès à un environnement représentatif comme cela.
    * les développeurs n’ont pas la spécialisation de l’outil.
    * le client ne veut pas perdre de donnée… et ne fait donc pas confiance aux développeurs !

    Mais ne peut-on pas élargir le problème de la gestion des données. Qui a déjà rencontré un DBA salarié dans une société ? … Quelle société met les moyens pour garantir que ces données sont accessibles et bien gérées ? Quelques grands compte le font, c’est vrai. Mais un nombre important de sociétés « pensent » que cela marche tout seul !

    Il ne faut pas perdre de vue que la donnée est ce qu’il y a de plus précieux. Perdre ses données, c’est la plus grande perte pour une société.
    Alors, à mon avis et celui-ci est proche du tient, une société qui laissera la gestion de ces données aux développeurs (en NoSQL ou autre techno) mettra, à terme, la clé sous la porte 🙂 !