Programmation

Depuis de nombreuses années plusieurs concepts progressent concernant les bases de données, on peut cependant remarquer que, premièrement, le modèle relationnel est le plus largement utilisé, et ensuite que nous continuons d’écrire des requêtes SQL dans nos codes sources, mélangeant ainsi deux langages.

Resterons nous perpetuellement bloqué sur le modèle relationnel et ses jointures, ou trouverons nous un jour une façon plus simple d’appréhender un modèle de donnée complexe ?

Seul l’avenir répondra à cette question, mais pas forcément un avenir si proche qu’on le pense, en effet une thèse écrite en 1993 fait déja état des SGBD Orientés Objets et propose un concept de langage persistant, mais pourtant les bases relationnelles ne trouvent toujours pas de sérieux concurents. En attendant, voici quelques remarques et commentaires pratique sur l’utilisation des bases de données.

Modulabilité

Le premier problème posé est que nous utilisons d’un coté un langage (PHP, Java, C++ …) et d’un autre un SGBD (MySQL, PostgresSQL, Oracle…). Le traitement des données est donc doublement dépendant des technologies utilisées, car les requêtes sont spécifiques et diffèrent d’un SGBD à un autre. Les solutions d’interopérabilité sont assez intéréssantes, mais trouvent leurs limites. Il s’agit en général d’utiliser des classes spéciales du langage utilisé qui serviront en grande partie à la communication avec le serveur (intermédiaires).

Cette approche est appellée mapping objet-relationnel, autrement dit l’illusion d’utiliser une base de données orientée objet alors que tout est relationnel. Ces systèmes se nomment « ORM » (Object-relational mapping), on en trouve en PHP comme Propel, Doctrine ou pdoMap. Ainsi il est par exemple possible d’écrire:

$u = new User;
$u->prenom = "Jacques";
$u->age = 32;
$u->insert();

(L’ORM Est une classe abstraite de laquelle hérite User). Et l’ORM s’occupe automatiquement de générer les requêtes SQL correctes. Autre exemple:

$u = new User;
$u->get(35);
$u->age++;
$u->update();

Et pour les requêtes un peu compliquées, les ORM vont jusqu’à créer des langages, comme le JDOQL (Java) ou le DQL (PHP), qui servent à requêter non pas les bases de données mais les classes (ce qui engendre naturellement des requêtes vers la base, mais de manière opaque). Ces requêtes sont généralement plus courtes et plus expressives que le langage SQL.

On remarque ainsi plusieurs avantages:

• La syntaxe du langage peut s’appliquer aux champs de la base (comme le « age++ »), la lisibilité du code ainsi obtenu peut être très bonne
• Les fonctions SQL « CRUD » (Create, Retrieve, Update & Delete) se font très facilement, plus une seule ligne de code SQL à écrire
• La syntaxe est en théorie la plus indépendante du SGBD possible, le concept « utopique » étant que le changement d’SGBD ne nécéssiterait que du bricolage dans l’ORM et non pas dans le code PHP
• Les mêmes ORM sont parfois présents dans plusieurs frameworks, on retrouvera Propel dans Symfony par exemple
• L’ORM peut servir d’intermédiaire pour établir des mécanismes de Cache

Mais aussi des inconvénients:

• La gestion des bases de données complexes (ayant des multiples jointures) est assez peu aisée à manipuler
• La lourdeur d’execution en prendra forcément un coup, ce type de classes faisant souvent appel à des accesseurs magiques ou à des éléments du modèle objet

Ce système permet aussi de profiter d’avoir des classes pour chaque table afin d’écrire des méthodes « custom ». Par exemple:

$u->addFriend($v);

Le découpage « un objet par table » prend généralement un sens assez pertinent.

Performances

Les performances sont aussi très importantes dans la communication avec un SGBD. Des politiques de mise en cache peuvent être adoptées. L’idée est assez simple, chaque requête du style « récupérer un enregistrement par sa clé » fait d’abord appel à une fonction du langage qui vérifie si le cache ne contient pas cet enregistrement.

Avantage immédiat, les enregistrements très récement et très souvent accédés restent « sous le coude ». C’est un peu comme si vous travailliez dans une grande bibliothèque, vous iriez chercher les trois livres dont vous avez besoin et vous les poseriez sur la table à coté de vous.

Ce mécanisme a été implémenté dans PHP par le biais d’APC (Alternative PHP Cache), qui permet de stocker ou de récupérer des éléments par leur index. Il existe aussi memcached, un serveur entièrement dédié à la mise en cache d’informations. Il est notament massivement utilisé par Facebook, le concept étant simple, on lui accorde une certaine quantité de mémoire et il se débrouille pour associer nos clés à nos données.

Autre détails, penser simplement à indexer la base de données sur les champs sur lesquels faire des recherches ou des jointures. Il faut parfois faire preuve d’un peu d’astuce pour parvenir à optimiser la base de manière à éviter les requêtes trop lourdes. Créer un Index « à chaud » peut être une opération très lourde, mais le gain par la suite sera forcément  très intéréssant.

Nouveau problème posé par ces mécanismes: la scalabilité. Imaginez que votre site web fonctionne bien et que vous vouliez supporter un plus gros traffic, le cache ne sera pas forcément très pratique, car il doit être global (d’ou l’interêt de memcache par rapport à APC par exemple)

Scalabilité

Voici une proposition de découpage possible assez arbitraire:

• Un serveur executant le SGBD (prendre une grosse machine, car cette partie n’est pas facile à découper)
• N Frontaux HTTP derrière un Rétro-proxy ou un load balancer
• Eventuellement des frontaux dédiés aux fichiers statiques
• Un ou plusieurs serveurs de cache (machines avec beaucoup de RAM, un processeur raisonable et un disque dur minimaliste)

La plus grande difficulté repose sur la répartition de la machine hébérgeant la base de données. Nous pouvons nous rassurer en nous disant que même des très grosses bases peuvent facilement tenir le coup pour peu qu’elles soient bien indexées, et que le réseau n’est pas un facteur très contraignant quant à la rapidité  (en LAN les performances sont plutôt bonnes entre les frontaux.

Maintenabilité

Un des concepts aussi employé dans les grosses architectures est l’éloignement de la base de données des serveurs applicatifs. Cet éloignement se fait par l’ajout de services, généralement conçus pour marcher via XML, et permet de garder la maitrise de l’ensemble des requêtes effectuées dans la base.

Ainsi les administrateurs de bases de données (DBA) entretiendront leur base et créeront des services associés à chaque type de requête qu’il sera possible de rencontrer. Ainsi les applications ne communiqueront jamais directement avec le SGBD mais avec des interfaces XML.

En conclusion, même si les bases relationelles restent franchement de la partie, un ensemble considérable d’outils et de couches qui viennent se greffer autour de ces derniers change l’environnement dans lequel les développeurs doivent évoluer.