J’ai cherché de quoi stocker des données avec plusieurs serveurs maîtres en réplication, mais je n’ai rien trouvé d’intéressant pour l’instant. Je me suis dis que toi, fidèle lecteur, tu pourrais apporter ta pierre. D’autant qu’il me semble que c’est une problématique courante, au moins pour les américains qui doivent avoir des serveurs sur les deux côtes, synchronisés entre eux.
Fonctionnellement
J’ai des visiteurs qui vont accéder en lecture, en écriture ou en modification à des données. Ces visiteurs peuvent être répartis géographiquement et j’aimerai que dans la mesure du possible, ils puissent accéder à leurs données rapidement. Par rapidement j’entends « sans avoir à payer 100 à 200 ms de latence pour joindre un serveur de base de données sur une autre côte ou sur un autre continent ».
Là où j’ai de la chance, c’est qu’une même données ne sera crée, modifiée ou lue que par un seul utilisateur (ou presque). Cet utilisateur sera donc le plus souvent au même endroit, donc je peux répartir mes données en considérant qu’un seul serveur est maître sur chaque données. Dans mon esprit ça veut dire que ce sera rapide (données proches) 90% du temps et lent (serveur maître loin) les 10% du temps restant si l’utilisateur navigue géographiquement. Par contre il faut que lors de la création d’une donnée, je puisse choisir quel serveur sera le maître pour la donnée en question (pas de répartition automatique par hachage de clef puisque le maître est choisi en fonction de la proximité géographique).
Histoire de compléter : J’ai assez peu de relationnel dans ces données et j’y accède quasiment toujours par leur clef primaire. Je suis prêt à utiliser du SGBDR type MySQL, du clef/valeur type Redis, ou des intermédiaires type MongoDB (bon, j’ai une préférence pour du Redis, qui serait mon choix sans la contrainte multi-maître).
J’ai des volumes qui vont représenter plusieurs Go, entre 5 et 20 on va dire à vue de nez, non volatiles (donc j’exclue tout système qui ne permet pas de sauvegarde ou qui n’a pas de couche écriture disque). La performance est importance lors des accès, mais je ne vais pas avoir un débit d’écriture phénoménal non plus. Je ne pense pas que ce soit le critère de choix principal.
Enfin, je n’ai pas besoin d’écritures synchrones sur plusieurs serveurs. Je suis prêt à avoir une latence d’une ou plusieurs secondes avant de pouvoir accéder à une nouvelle donnée (ou à une modification) depuis un autre serveur que celui de sa création.
Techniquement
Beaucoup de solutions ont un mode maître-maître qui ne semble pas convenir à mon besoin, où les conflits peuvent être légion : Si un utilisateur fait volontairement une opération sur une données à partir de plusieurs emplacements géographique, je risque de ne pas pouvoir tracer ses différentes opérations mais d’avoir au mieux la trace de la dernière. Sauf erreur de ma part, les bidouillages multi-maîtres MySQL et PostgreSQL entrent dans cette catégorie.
J’ai jeté un oeil à Redis-cluster, qui a l’air d’être assez proche de la philosophie que je cherche (chaque donnée a un et un seul maître) mais c’est malheureusement avec une isolation complète, c’est à dire qu’aucun noeud n’a l’ensemble des informations en lecture. J’y viendrai s’il le faut, mais si je veux un fail-over correct ça veut dire qu’il faut que je double chaque noeud (le maître, puis son esclave en cas de défaillance). Je ne suis pas non plus certain de pouvoir choisir le maître à utiliser lors de l’écriture.
Je regarde Riak, CouchDB, RethinkDB, Tyrant, Voldemort, Dynomite et quelques autres mais je manque cruellement de retours d’expérience et d’informations pour faire un choix éclairé, si tant est que l’un de ceux là puisse correspondre.
J’ai aussi en tête de faire quelque chose à la main avec une logique applicative par dessus le connecteur Redis, pour qu’il se connecte au bon serveur en fonction du premier caractère de la clef, mais j’aimerai franchement éviter les bidouilles manuelle pour quelque chose qui doit certainement avoir une solution sur étagère.
Dis, lecteur, as tu des liens, des retours d’expérience, des informations, des commentaires ?
Laisser un commentaire