Le problème du split brain, c'est un problème qui est partagé par toutes les setups qui se veulent haute-dispo. La solution doit être évidemment pensée pour qu'il n'y en aie pas. Plus facile à dire qu'à faire... surtout qu'on se limite souvent au périmètre du la bdd, alors qu'il faut pouvoir analyser le système dans son ensemble. Ceci-dit, la linéarité maître-esclave fournit des outils en plus pour éviter ce cas (timelines) et en général elle se prête bien au modèle d'intégrité des SGBR.
Si on se limite au périmètre de la sgbr, certes pg n'a pas de solution clef en main comme mongo ou elastic. Et je dirais que c'est pour le mieux, car cela pousse les gens à mieux réfléchir à leur solution (et, espérons le, à sortir du périmètre de la bdd uniquement). Au contraire, mongo et elastic vont te donner beaucoup de misères dans les scénarios où justement ça me fonctionne plus comme il faut... ce qui est en fait contre productif :) (de bonne foie, cet argument peut s'appliquer à toute solution HA)
Sur le point de la réplication, pg a eu un développement exemplaire de sa solution de réplication. Elle a évoluée petit à petit à partir d'une base solide, certes lentement, mais en ne compromettant jamais l'existant: Pg t'offre la garantie qu'une requête au moment transactionnel "t" donnera le même résultat sur tous les réplicas, ou une erreur*. C'est une opinion qui est largement répandue et que je partage. Si on compare à mysql, il y avait plusieurs méthodes de réplication, chacune avec des limitations différentes, et aucune ne garantissant une réplication parfaite. Il est de plus possible (je dirais, indispensable même) de tirer profit de la numérotation des transaction pour mieux coordonner ses différents application clientes de la bdd.
Pour en revenir à la question de quelle solution est supérieure aux autres, et bien je dois dire que c'est celle que l'on comprenne et pour laquelle on est prêt à développer. Faire du mongo ou ES en multi-nodes, pourquoi pas, mais alors jamais il ne faut dépendre de leur intégrité supposée. Avoir une archi maître-maître, c'est aussi utiliser des types de données différents qui sont "fusionnables" afin d'éluder le problème de la résolution de conflits. Pg a aussi certains fork proprios faisant du maître-maître, mais il faut bien comprendre les tenants et aboutissants pour en faire un bon usage, et certainement pas s'attendre à de meilleures performances et encore moins à ne pas devoir modifier ses applications.
*: C'est le talon d'Achille de ce modèle: une requête active sur un replica suspend l'application de certaines transactions qui sont susceptibles d'entrer en conflit (par exemple, un drop table) et donc de toutes celles qui suivent (car les transactions sont appliquées dans le même ordre pour garantir l'exactitude de la réplication). Le risque c'est d'avoir un blocage/lag persistent qui fini par générer des erreurs après que le délais dépasse une valeur arbitraire.
[^] # Re: Scylla/MongoDB
Posté par benja . En réponse au journal Cassandra 4 qui la testent, un qui l'Hécube. Évalué à 5.
disclaimer: fan de Pg, et pas expert pour un sous
Le problème du split brain, c'est un problème qui est partagé par toutes les setups qui se veulent haute-dispo. La solution doit être évidemment pensée pour qu'il n'y en aie pas. Plus facile à dire qu'à faire... surtout qu'on se limite souvent au périmètre du la bdd, alors qu'il faut pouvoir analyser le système dans son ensemble. Ceci-dit, la linéarité maître-esclave fournit des outils en plus pour éviter ce cas (timelines) et en général elle se prête bien au modèle d'intégrité des SGBR.
Si on se limite au périmètre de la sgbr, certes pg n'a pas de solution clef en main comme mongo ou elastic. Et je dirais que c'est pour le mieux, car cela pousse les gens à mieux réfléchir à leur solution (et, espérons le, à sortir du périmètre de la bdd uniquement). Au contraire, mongo et elastic vont te donner beaucoup de misères dans les scénarios où justement ça me fonctionne plus comme il faut... ce qui est en fait contre productif :) (de bonne foie, cet argument peut s'appliquer à toute solution HA)
Sur le point de la réplication, pg a eu un développement exemplaire de sa solution de réplication. Elle a évoluée petit à petit à partir d'une base solide, certes lentement, mais en ne compromettant jamais l'existant: Pg t'offre la garantie qu'une requête au moment transactionnel "t" donnera le même résultat sur tous les réplicas, ou une erreur*. C'est une opinion qui est largement répandue et que je partage. Si on compare à mysql, il y avait plusieurs méthodes de réplication, chacune avec des limitations différentes, et aucune ne garantissant une réplication parfaite. Il est de plus possible (je dirais, indispensable même) de tirer profit de la numérotation des transaction pour mieux coordonner ses différents application clientes de la bdd.
Pour en revenir à la question de quelle solution est supérieure aux autres, et bien je dois dire que c'est celle que l'on comprenne et pour laquelle on est prêt à développer. Faire du mongo ou ES en multi-nodes, pourquoi pas, mais alors jamais il ne faut dépendre de leur intégrité supposée. Avoir une archi maître-maître, c'est aussi utiliser des types de données différents qui sont "fusionnables" afin d'éluder le problème de la résolution de conflits. Pg a aussi certains fork proprios faisant du maître-maître, mais il faut bien comprendre les tenants et aboutissants pour en faire un bon usage, et certainement pas s'attendre à de meilleures performances et encore moins à ne pas devoir modifier ses applications.
*: C'est le talon d'Achille de ce modèle: une requête active sur un replica suspend l'application de certaines transactions qui sont susceptibles d'entrer en conflit (par exemple, un drop table) et donc de toutes celles qui suivent (car les transactions sont appliquées dans le même ordre pour garantir l'exactitude de la réplication). Le risque c'est d'avoir un blocage/lag persistent qui fini par générer des erreurs après que le délais dépasse une valeur arbitraire.