Le SQL distribué est attrayant car il offre un accès relationnel sur une infrastructure répliquée. L'erreur consiste à s'attendre à ce qu'il se comporte comme un PostgreSQL ordinaire à nœud unique avec une disponibilité supplémentaire.
Il hérite toujours de la physique du consensus.
Le Modèle Mental Qui Aide
CockroachDB est plus facile à raisonner lorsque vous partez de Raft et du quorum, et non de la syntaxe SQL. Une écriture doit généralement atteindre une majorité de réplicas avant d'être durable. Si les réplicas sont géographiquement éloignés, la latence d'écriture reflète cette distance.
Une image simplifiée est :
- un détenteur de bail reçoit l'écriture
- les suiveurs répliquent l'entrée du journal
- le quorum accuse réception
- l'écriture s'engage
C'est pourquoi la topologie est si importante. La base de données n'est pas "lente sans raison". Elle effectue un travail de coordination.
Pourquoi Cela Apparaît en Production
Une fois que vous comprenez le chemin du consensus, plusieurs comportements deviennent moins surprenants :
- les écritures inter-régionales coûtent plus de latence
- les plages de points chauds peuvent surcharger un détenteur de bail
- la récupération des pannes de nœuds concerne le quorum, et pas seulement le redémarrage du processus
- les décisions de localité de lecture et d'écriture affectent l'expérience utilisateur
Le SQL distribué achète une forte cohérence et une résilience opérationnelle, mais il ne révoque pas le problème de la vitesse de la lumière.
Meilleure Règle
Utilisez CockroachDB lorsque la disponibilité et le modèle de distribution justifient le coût du consensus. Si la charge de travail est principalement à région unique et sensible à la latence, un déploiement PostgreSQL bien géré peut toujours être le meilleur choix d'ingénierie.
Lectures Complémentaires