Stonebraker über das CAP-Theorem und Datenbanken Mike Stonebraker hat gestern einen ausgezeichneten Blog-Beitrag auf der CACM-Seite veröffentlicht: Errors in Database Systems, Eventual Consistency, and the CAP Theorem. In diesem Artikel stellt Mike die Anwendung des CAP-Theorems von Eric Brewer durch die NoSQL-Datenbank-Community in Frage. Viele der Implementierer von hochskalierbaren NoSQL-Systemen haben argumentiert, dass das CAP-Theorem sie zwingt, ein eventual konsistentes Modell zu verwenden. Mike stellt diese Behauptung in Frage und weist darauf hin, dass einige häufige Datenbankfehler durch eventual consistency nicht vermieden werden und CAP in diesen Fällen nicht wirklich anwendbar ist. Wenn Sie einen Anwendungsfehler, einen administrativen Fehler oder einen Datenbankimplementierungsfehler haben, der Datenverluste verursacht, dann sind diese einfach weg, es sei denn, Sie haben eine Offline-Kopie. Das ist übrigens der Grund, warum ich ein großer Fan von Deferred Delete bin. Dies ist eine Technik, bei der gelöschte Elemente als gelöscht markiert, aber erst einige Tage oder vorzugsweise Wochen später per Garbage Collection entfernt werden. Deferred Delete ist kein vollständiger Schutz, aber es hat mir mehr als einmal den Hintern gerettet und ich bin ein Anhänger davon. Siehe On Designing and Deploying Internet-Scale Services für weitere Details. CAP und die Anwendung von eventual consistency schützen uns nicht direkt vor Anwendungs- oder Datenbankimplementierungsfehlern. Und im Falle einer großflächigen Katastrophe, bei der der Cluster vollständig verloren geht, bieten weder eventual consistency noch CAP eine Lösung. Mike merkt auch an, dass Netzwerkpartitionen relativ selten sind. Ich könnte hier ein wenig streiten. Netzwerkpartitionen sho
Discussion
Join the conversation
Be the first to comment