La question de la consistance (cohérence?) est celle du compromis. Sur une machine, les données entrent et celle ci est la seule à devoir gérer ses accès. En mode distribué, c'est beaucoup plus compliqué.

Mettre à jour de la donnée

Sur un système distribué, par définition, celui ci est constitué de plusieurs instances (on parle de nœuds) formant un réseau. Notez bien que la topologie de ce dernier vous est imposée. Et pour gérer vos données, vous avez deux familles de solutions:

  • peer to peer : tous les nœuds gèrent des ordres de lecture et de mise à jour. Dans ce cas, la complexité réside dans la gestion de la cohérence globale. Deux nœuds diamétralement opposés d'un gros réseau ne seront pas en liaison permanente, et une mise à jour dans l'un ne sera pas impactée immédiatement à l'autre. Ce délai peut aller jusqu'à plusieurs secondes, et c'est ce qu'on appelle la fenêtre d'incohérence. Et pendant ce temps... Pendant ce temps, que faire? Quelle valeur a une variable? Cela pose des problèmes de cohérence en écriture / écriture, écriture / lecture. Si deux nœuds distants sont mis à jour en même temps, quelle valeur retenir pour la réconciliation? Si un nœud est mis à jour, que doit on répondre à l'autre bout du cluster sur la valeur d'une variable?
  • master slave: un nœud en particulier prend la main sur toutes les écritures, et va dupliquer la donnée sur tous les nœuds esclaves. Une demande de lecture peut donc être adressée par n'importe quel nœud (master comme esclave), mais les écritures le seront forcément par le seul nœud master. Inconvénient trivial : un seul nœud ne peut pas toujours porter toutes les écritures.
  • Le master slave avec sharding : le sharding consiste à confier à une machine une sous partie des données. Si par exemple on partitionne les entités par le nom du client, on peut tout à fait avoir un nœud qui gère les noms de A à H, un de I à Q, et le dernier pour R et suivants. Puisque par hypothèse les données sont bien partitionnées, les master n'ont pas besoin de se coordonner avec les autres, en tous cas pour les écritures. En fait, tout traitement de type full scan sera obligé de contacter tous les nœuds, ce qui pose encore d'autres familles de problèmes.

Exemples d'architecture

Citons deux exemples: HDFS et Cassandra.

HDFS a défini un nœud master qui prend à sa charge la gestion de la concurrence. Comme c'est le seul nœud qui est sollicité pour la création d'un fichier, ou de la mise à jour de celui ci, il a à sa connaissance toutes les informations pour régler les accès concurrents. Dans les premiers articles de recherche, la question est résolue de manière assez brutale : le nœud maître est là parce que ça facilite considérablement l'architecture...

Cassandra propose plusieurs niveaux de cohérence pour les lectures ou écritures, et la documentation est ici. Le principe est assez simple: vous choisissez le niveau de propagation de l'information en écriture, et le niveau de validation de la réponse en lecture. C'est une question qui devient à la charge du développeur. A cette personne là de déterminer le niveau de cohérence voulu. Par exemple, si Cassandra est mis à jour une fois par jour par batch, une lecture sur un noeud suffit après la mise à jour, puisque tous ont la même information.

Conclusion

Dans tous les cas, vous comprenez bien que le dilemme est :

  • soit vous avez un seul point qui gère tout seul les mises à jour. Il existe des algorithmes pour les distribuer sur un petit réseau. Cet élément du système est votre goulot d'étranglement, mais vous garantissez une certaine cohérence, au détriment par contre du temps de traitement. En effet, vous allez solliciter le même point d'entrée pour toutes les requêtes
  • soit vous avez une architecture complètement distribuée sans noeud master. Alors, dans ce cas là, il va vous falloir vous poser la question de la cohérence de manière pragmatique (essentiellement, comme Cassandra vous laisse faire).

Evidemment, ce dilemme a été formalisé, avec la notion de cohérence éventuelle (eventual consistency). Elle consiste à dire qu'au bout d'un moment, et sauf partitionnement du réseau, une mise à jour est propagée dans le réseau. Pour le dire autrement: attendez suffisamment sans mettre à jour le système et tous les noeuds qui le composent devraient avoir l'information. C'est un besoin fondamental, mais on n'a pas de borne du temps nécessaire en général.

 

Comments are closed.

Set your Twitter account name in your settings to use the TwitterBar Section.