Verteiltes SQL ist ansprechend, weil es relationalen Zugriff auf einer replizierten Infrastruktur bietet. Der Fehler besteht darin, zu erwarten, dass es sich wie ein gewöhnliches einzelnes Postgres mit zusätzlicher Verfügbarkeit verhält.
Es erbt weiterhin die Physik des Konsenses.
Das mentale Modell, das hilft
CockroachDB ist einfacher zu durchdenken, wenn man von Raft und Quorum ausgeht, nicht von der SQL-Syntax. Ein Write muss in der Regel eine Mehrzahl der Replikate erreichen, bevor es dauerhaft ist. Wenn die Replikate geografisch weit auseinanderliegen, spiegelt die Schreiblatenz diese Entfernung wider.
Ein vereinfachtes Bild ist:
- ein Leaseholder erhält den Write
- Followers replizieren den Log-Eintrag
- Quorum bestätigt
- der Write wird festgeschrieben
Deshalb ist die Topologie so wichtig. Die Datenbank ist nicht „langsam ohne Grund“. Sie leistet Koordinationsarbeit.
Warum sich das in der Produktion zeigt
Sobald man den Konsenspfad versteht, werden mehrere Verhaltensweisen weniger überraschend:
- Kreuzregionale Writes kosten mehr Latenz
- Hotspot-Bereiche können einen Leaseholder überlasten
- Die Wiederherstellung von Knotenfehlern betrifft das Quorum, nicht nur den Neustart des Prozesses
- Entscheidungen über die Lese- und Schreiblokalität beeinflussen das Benutzererlebnis
Verteiltes SQL kauft starke Konsistenz und operationale Resilienz, aber es hebt nicht das Lichtgeschwindigkeitsproblem auf.
Bessere Regel
Verwenden Sie CockroachDB, wenn das Verfügbarkeits- und Verteilungsmodell die Kosten des Konsenses rechtfertigt. Wenn die Arbeitslast größtenteils einzelregional und latenzsensitiv ist, kann ein gut verwaltetes Postgres-Deployment dennoch die bessere Ingenieurlösung sein.
Weiterführende Literatur