Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

retour

Base de données

Base de données

La grosse base centrale

Nous avons donné des axes de solution vers une extensibilité à peu près sans limite au plan théorique.

 

En matière de base de données, avant d’être aux limites, on peut trouver de très importants facteurs de gain dans l’optimisation des requêtes, des index, des paramètres généraux ou du cache. Une fois la base optimisée, on peut encore trouver un gain important dans la configuration matérielle : disques rapides, processeurs, mémoire.

Au total, il faut retenir qu’une base de données bien conçue et bien « tunée », sur un serveur puissant, peut servir une très grosse plateforme web. A titre d’exemple, le site cadremploi.fr, qui reçoit 3,2 millions de visites par mois, sur des processus de consultation relativement complexes, s’appuie sur une base Oracle unique tournant sur un bi-processeur qui a quelques années déjà, une base qui est loin d’être surchargée. Avec des applications bien conçues pour la performance, une base centrale peut aller très loin.

La réplication SGBD simple

L’un des outils puissants à notre disposition pour étendre la capacité de la gestion de données est la réplication.

Voyons d’abord le cas de la réplication maître-esclave.

Le principe est simple : toutes les écritures appliquées sur la base maître sont propagées et exécutées sur la ou les bases esclaves. Il peut y avoir un grand nombre de bases esclaves. La base maître est la seule qui accepte les écritures, les autres bases sont en lecture seule.

image092

La réplication maître-esclave est offerte par la plupart des SGBD, et facile à mettre en œuvre.

La réplication est transactionnelle, c’est à dire que seules les transactions commitées sur la base maître sont répliquées sur la base esclave, et elles sont alors répliquées totalement.

La réplication est fiable : aucune transaction ne peut être perdue, même en présence d’incidents, que ce soit sur le réseau ou bien sur l’une des bases esclaves. Si la base esclave est indisponible, par exemple arrêtée pour maintenance, alors les transactions s’accumulent en file d’attente, et seront jouées lorsque la base esclave redeviendra disponible. Cette fiabilité théorique est toutefois dépendante de la configuration matérielle dans la pratique : si la file d’attente est sur un disque non secouru qui vient à crasher, les transactions non transmises seront perdues.

La réplication est asynchrone : la base esclave peut être en retard de quelques transactions par rapport à la base maître. Ce retard dépend de la configuration, et peut être réduit à quelques secondes. Mais au plan théorique, il faut compter sur la possibilité d’un décalage plus grand.

Enfin, le couple formé de la base maître et d’une base esclave en lecture ne respecte pas les propriétés ACID, comme vues plus haut.

Comme pour tout dispositif incrémental, fonctionnant par « deltas » c’est à dire ne portant que sur la propagation des changements, la fiabilité est absolument critique. Un taux même très faible de transactions perdues engendrerait une divergence entre les bases qui ne pourrait aller qu’en s’accentuant. Et une fois que les bases ont divergé, les resynchroniser peut être particulièrement délicat.

On peut distinguer deux modes d’utilisation de la réplication :

  • En mode secours seul. La base esclave est une copie, légèrement décalée, de la base maître. En cas de panne de la base maître, on passe l’esclave en maître.
  • En mode partage de charge. Dans ce mode, la base esclave est utilisée en lecture. Les requêtes en lecture peuvent être réparties entre la base maître et la base esclave ou plusieurs bases esclaves. C’est un schéma que nous avons déjà évoqué.

Il faut garder à l’esprit que, dans tous les cas, l’activité en écriture sur la base esclave, ou bien les bases esclaves, est la même que sur la base maître. C’est donc une configuration qui n’apporte rien si la base maître est saturée en écriture.

Réplication « manuelle »

La réplication suppose des modèles de données très proche, sinon identiques. Elle crée donc une forte dépendance entre les sous-systèmes concernés. Lorsqu’il s’agit de sous-systèmes homologues, comme dans le cas d’une répartition de charge, la dépendance ne pose pas de problème : quoi qu’il en soit on souhaite que les bases soient identiques.

Mais on peut aussi mettre en œuvre la réplication entre sous-systèmes distincts, qui doivent échanger des données. Dans ce cas, la dépendance n’est pas bonne, et viole le principe d’encapsulation des données. C’est à dire que la réplication est utilisée à la manière d’un middleware, ce qu’elle n’est pas. Il convient plutôt :

  • Soit d’utiliser un vrai middleware de type MOM, asynchrone et fiable.
  • Soit de mettre en place un dispositif de collecte applicatif, qui pourra passer par l’invocation d’un webservice de collecte.

Réplication croisée, multi-maîtres

La réplication multi-maîtres consiste « simplement » à croiser deux réplications maître-esclave, comme on peut le représenter sur le schéma suivant :

image094

Dans cette configuration, les deux bases sont en lecture-écriture. Elles sont identiques à un délai près, c’est à dire qu’en l’absence d’écriture, elles redeviennent identiques.

La réplication multi-maîtres est d’une mise en œuvre délicate, non pas tant au plan technique, mais au plan fonctionnel :

  • Des cas d’incohérences transitoires entre les deux bases doivent être analysés, et parfois traités par des règles de gestion spécifiques.
  • Une même transaction étant exécutée sur une même base, chaque base a un comportement ACID, mais ce n’est pas le cas du couple de bases, ce n’est pas un cluster.

Par ailleurs, comme le cluster, c’est une configuration qui dans la pratique peut aller jusqu’à 3 serveurs, mais guère au delà.

Si les requêtes à la base de données sont réparties unitairement entre les bases, alors le risque est fort de souffrir d’incohérences. Un même internaute pourrait avoir demandé une modification de ses données, traitée sur l’un des serveurs, et immédiatement accéder en lecture sur l’autre serveur et ne pas voir ses changements. On voit que pour assurer qu’un même internaute a une vision cohérente et stable des données, il faut faire en sorte qu’il n’accède qu’à une seule des bases.

Pour cela, on peut envisager :

Soit une répartition statique des frontaux vers les bases de données, associée à une répartition de charge avec affinité de serveurs, ce qui peut se représenter comme suit :

image096
  • Soit une répartition sans affinité à l’étage frontal, mais une mémoire du serveur affecté à une session. Ce qui a le bénéfice d’un load-balancing plus flexible en amont, mais oblige malgré tout à une gestion de données de session, qui bien sûr ne pourra pas ici être en base de données, mais pourrait être conservée dans un cookie par exemple.
image098

Notons qu’ici aussi, comme pour le cluster, si une des bases est indisponible, la capacité globale est divisée par deux

RAIDb et Sequoia

En matière d’extensibilité de la gestion des données, il faut citer aussi le concept relativement récent de RAIDb, « Redundant Array of Inexpensive Databases », inspiré évidemment du RAID pour les disques.

Le concept est issu des laboratoires de l’INRIA, exposé dans un article de 2003, et implémenté d’abord sous la forme d’un middleware initialement nommé C-JDBC, repris ensuite par Continuent et renommé Sequoia.

Comme pour le RAID disque, le principe de Sequoia est l’utilisation de multiples bases de données, de dimension et de niveau de fonctionnalités ordinaires, pour construire un cluster de bases de données, visant à la fois la haute disponibilité de l’ensemble et l’extensibilité en capacité. Sequoia implémente une « base de données virtuelle », appuyée sur des bases de données effectives, qui peuvent être hétérogènes, appelées ici « backend ».

Pour les applications, l’utilisation d’un cluster Sequoia au lieu d’une base de données ordinaire est totalement transparente. Les applications adressent la base de données par le middleware standard JDBC, pour les applications Java, mais des APIs sont maintenant disponibles également pour les applications PHP ou d’autres environnements.

Ily a plusieurs configurations possibles de Sequoia, mais la plus utile est celle qui gère N bases de données identiques, entre lesquelles les requêtes sont distribuées. Les requêtes d’écriture sont adressées en parallèle à toutes les bases, tandis que les requêtes de lecture sont load-balancées. On n’obtient donc un bénéfice réel que s’il y a relativement moins d’écritures que de lectures, ce qui est courant.

image100
image102

Cette configuration apporte des bénéfices semblables à ceux de la réplication, mais avec une différence essentielle : les écritures sont exécutées de manière synchrone sur toutes les bases, de sorte qu’il n’y a plus de problème lié aux incohérences transitoires.

Sequoia traite également de la tolérance aux pannes, puisque les bases de données indisponibles sont automatiquement sorties de la répartition. Bien entendu, le composant middleware lui-même ne doit pas devenir « SPOF », point de fragilité. C’est pourquoi la configuration type met en œuvre deux ou plusieurs contrôleurs Sequoia, et les connecteurs (du côté des applications clientes), gèrent une répartition de charge (random, round-robin, séquentielle), entre les contrôleurs, sachant eux-mêmes éliminer un contrôleur défaillant.

image104

Une même connexion applicative est stable, sur le même contrôleur, mais le contrôleur répartit ensuite les requêtes entre les différentes bases. Il utilise lui-même différents algorithmes : least-pending-requests (la base qui a le moins de requêtes en attente), round-robin (permutation circulaire), weighed-round-robin (idem avec pondération selon la capacité).

Une fonctionnalité importante est la gestion d’une log des transactions au niveau du contrôleur Sequoia lui-même, indépendamment des bases backend. Ainsi Sequoia permet également de désactiver l’une base de données backend pour une opération de maintenance. Dans ce cas, le contrôleur définit un point de contrôle dans sa log, de manière à pouvoir rejouer les transactions manquantes lorsque la base sera réinsérée.

En conclusion, Sequoia et le concept du RAIDb est une voie particulièrement intéressante vers l’extensibilité de la gestion des données, respectant le principe que nous avons posé en introduction, de faire appel à des composants ordinaires et peu coûteux. Son caractère transparent pour l’application le rend en particulier compatible avec des progiciels standards.

On a dit plus haut à quel point la gestion des données était difficilement extensible. A cet égard, Sequoia est l’une des voies les plus intéressantes. Sequoia est une solution open source, qui a déjà suffisamment de références opérationnelles pour avoir démontré sa stabilité.