Denis Dollfus' Blog

NoSQL : les SGBDR remis en question

L'adoption naissante du Cloud et surtout le buzz qui l'entoure apportent aux développeurs et architectes de nouvelles idées qui secouent certaines habitudes qu'on croyait aller de soi.

Le composant qui souffre le plus est un de ceux qui semble pourtant le mieux installé dans la durée : la base de données relationnelle. 

A peu près tous les fournisseurs de cloud proposent en effet un service de stockage dans lequel le côté "relationnel" a disparu en même temps que le langage de requête SQL. C'est le cas entre autres de SimpleDB d'Amazon, BigTable de Google et Azure Storage de Microsoft (et non le très relationnel MS SQL Data Service), qui ont en commun de booster la disponibilité et la partitionabilité au dépend de la consistance des données, conformément au théorème de CAP (cf. USI-2009/Le Touilleur Express).

Evidement, constater que tous ces grands du Web convergent vers le même type de solution a de quoi faire réfléchir, surtout quand on sait que ce type de stockage, simple d'emploi et capable de monter en puissance sans explosion des coûts ("scalable", à proposer d'urgence à l'Académie Française), est déjà utilisé avec succès en interne par Amazon et Google.

"Faire réfléchir" c'est peu dire. Avec la création récente de NoSQL, le Cloud semble agir comme un catalyseur suceptible de déclencher un tsunami anti-base de données relationnelle. NoSQL rassemble des acteurs désireux de faire connaitre leurs systèmes de stockage open-source non relationnels, parfois très proche d'un simple dictionnaire constitué de paires clé-valeur. On y trouve CouchDB, Voldemort (j'aime bien le nom), Cassandra, Dynomite, HBase, HyperTable, VPork (joli aussi) et MongoDB. 

Si ces systèmes de gestion des données gagnent du terrain, il faudra sans doute oublier ou en tout cas repenser l'approche centrée sur le modèle relationnel qui caractérise la grande majorité des architectures des applications de gestion de données. Certains mots-clés comme "SGBDR", voire "ORM" et "Hibernate" pourraient devenir aussi datés que le WAP (oouuouuh, tremblez).

Tous les liens vers les solutions de persistance NoSQL sont sur le compte-rendu de la première rencontre NoSQL qui a eu lieu le 12 juin 2009 et a rassemblé 150 personnes à San Francisco :

• Compte-rendu de la rencontre NoSQL : NoSQL Debrief
• ComputerWorld : No to SQL? Anti-database movement gains steam

Le Cloud va-t-il réussir là où les bases de données orientées objets ont échoué ?

 

ESENT, le moteur de base de données livré avec Windows

Information délivrée par monsieur Windows SDK : "Je ne sais pas combien de personnes savent que Windows est livré avec une base de données native transactionnelle que les développeurs peuvent exploiter via les SDK de Windows. Le moteur de base de données ESENT peut être utilisée quand une application requiert un système de haute performance et peu couteuse en puissance de calcul pour stocker des données structurées ou semi-structurées."

C'est sûrement un scoop pour beaucoup, même si ESENT est déjà exploité par quelques applications Windows bien connues telles Active Directory et Desktop Search.

Ce qui est nouveau en revanche c'est qu'ESENT dispose maintenant de son interface .Net : ESENT managed interface est open-source et hebergée sur CodePlex.

Via Ayende Rahien, qui l'a mise en oeuvre pendant que vous preniez le café.

Comment accéder aux données dans une application Silverlight 2.0

MSDN Magazine de septembre contient deux articles sur l'accès aux données depuis une application Silverlight. Ils proposent deux voies différentes :

• Via ADO.NET Data Services (Shawn Wildermuth)
• Via WCF (John Papa)

J'aime bien l'approche ADO.NET Data Services (anciennement Astoria), qui consiste à générer une couche d'API REST au dessus de l'accès aux données, plus précisément au-dessus de tout accès aux données qui implémente IQueryable et optionnellement IUpdateable (oui c'est bien IUpdateable, pas IUpdatable).

Ces deux interfaces, aujourd'hui implémentées par Entity Framework, sont le moyen par lequel d'autres systèmes de persistance pourront être exposés à la mode "ADO.NET Data Services" (encore un nom à rallonge qui va finir en acronyme obscur, Astoria c'était quand même plus facilement écrit et retenu). Nhibernate notamment pourrait bien être un des premiers ORM open-source à pouvoir être exposé en REST par ADO.NET Data Services. Shawn Wildermuth y travaille.

Sources :

Service-Driven Apps With Silverlight 2 And WCF

Create Data-Centric Web Applications With Silverlight 2

ORMs : L'Entity Framework de Microsoft aura meilleure réputation que NHibernate

Hibernate et son cousin .Net NHibernate souffrent d’un handicap qui nuit à leur réputation. Dès 2006 Sami Jaber constatait que les premiers retours terrain étaient plutôt désastreux : "[...] des requêtes SQL générées de 70 pages imprimées (véridique), parfois 300 ou 400 requêtes par formulaires et des DBA qui crient au scandale".

Implicit Lazy loading

Le lazy loading implicite (littéralement "chargement paresseux") mis en œuvre par (N)Hibernate est en grande partie responsable de cette notoriété reprochable. Typiquement en lazy loading, un objet (disons  client) dont les propriétés ont été renseignées par NHibernate verra  ses objets associés (disons client.Commandes) initialisés paresseusement par une requête SQL, c'est-à-dire seulement quand nécessaire et si nécessaire.

 

Lazy road crossing. Rien à voir. Désolé.

Jusque là tout va bien, le lazy loading c'est plutôt bien pour éviter que toute la base de données ne se retrouve en mémoire par le biais de plusieurs associations.

Le hic, c'est que toute cette mécanique de requêtage automatique de la base de données se produit implicitement, presque à l'insu du développeur. Par exemple si le développeur doit écrire une itération sur tous les client.Commandes pour calculer le total des commandes, il écrira une boucle foreach (Commande commande in client.Commandes), et NHibernate va silencieusement générer et exécuter autant de requêtes SQL que de commandes associées à cet objet client. 150 commandes ? 150 requêtes envoyées une-à-une à la base de données...

D'un côté c'est génial parce que le développeur peut manipuler des objets C# purs et durs en ignorant qu'une base de données est à l'œuvre derrière le décor, orchestrée par NHibernate. De l'autre, et pour les même raisons, c'est une catastrophe. En ignorant la réalité du SGDB, les performances chutent et les DBA crient au scandale, parce que la façon optimale de charger des données en mémoire dépend, au cas par cas, de l'usage que l'on s'apprête à en faire. NHibernate n'ayant aucune vision de cet usage, l'optimisation des requêtes ne peut être menée que par le développeur grâce aux outils (join fetch par exemple) de NHibernate.

Malheureusement, quelles que soient les possibilités qu'offre NHibernate pour forcer le chargement d'une collection d'objets en un seul aller-retour SQL, le seul fait que le développeur ait la possibilité d'ignorer le moyen par lequel les objets persistent (conformément au principe de Persistence Ignorance –PI– de l'approche Domain Driven Design –DDD) promet quelques utilisateurs énervés par la lenteur de certains traitements, des DBA scandalisés et finalement des clients mécontents. Bref une sale réputation.

Explicit loading

Et c'est donc une décision marketing qui a conduit l'équipe Microsoft responsable d'Entity Framework à choisir le chargement explicite (explicit loading) plutôt qu'implicite. Dans le dernier numéro de MSDN Magazine, l'encart intitulé "Insights: Entity Framework Data Loading" et signé DiegoVega est clair à ce propos : " Following the "no hidden network roundtrips" principle, Entity Framework avoids automatic lazy loading".

Aucun aller-retour avec le SGBD n'aura lieu sans que le développeur ne le sache.

Le principe de l'explicit loading est simple : tant que le développeur n'a pas écrit le nécessaire pour charger une Commande de notre association client.Commandes, l'accès à une de ces commandes déclenche une exception. En explicit loading, les développeurs se soucient du SGBD,  les DBA sont heureux, et l'image de Microsoft est sauve.

A vérifier bien sûr...

Liens :

MSDN Magazine, Mai 2008. Lire en particulier l'encart "Insights: Entity Framework Data Loading" http://msdn.microsoft.com/en-us/magazine/cc507640.aspx

Sami Jaber 2006 : Evitons le vietnam Hibernate  http://www.dotnetguru2.org/sami/index.php?p=333&more=1&c=1&tb=1&pb=1

Ted Newart 2006 : The Vietnam of Computer Science
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

Daniel Simmons, développeur sur l'Entity Framework : "we never make a round trip to the server implicitly". Cf. discussion http://forums.microsoft.com/MSDN/ShowPost.aspx?siteid=1&PostID=644979.

ADO.NET Entity Framework Beta 3 http://www.microsoft.com/downloads/details.aspx?FamilyId=15DB9989-1621-444D-9B18-D1A04A21B519&displaylang=en

Publier une database sur un serveur Web distant partagé

Une mise à jour de Sql Server Database Publishing Toolkit vient de paraître sur CodePlex. Bien utile pour publier sa base de donnée (schéma+data) sur un serveur distant sans passer des heures à scripter dans une petite fenêtre de saisie.
Deux modes sont supportés : la génération de scripts et l'accès au service Web offert par l'hébergeur. Ce service Web fait partie de Sql Server Database Publishing Toolkit.

Schémas de base de données prédéfinis

Autant on parle de réutilisabilité en programmation orientée objets, autant les SGBD ne semblent pas aborder le sujet. Je dis bien "semble" parce que les SGBD n'étant pas ma spécialité, il est plus que possible que j'ignore les bonnes sources d'infos à ce sujet.

Bref, comment faire quand on ne veut pas réinventer la roue côté database sur un projet qu'on sait classique (e-commerce, Help Desk, bug tracking...) ?

Et bien maintenant on peut télécharger des schémas prédéfinis. Et ça peut rudement aider.

Le post original est là, sur le blog de Dan Fernandez. Dédié à SQL Server, mais aisément généralisable.