Einführung

Es gibt einen bekannten Satz der Informatik, der von Eric Brewer vorgeschlagen wurde, der besagt, dass man für eine Datenbank mit verteilten Daten nur zwei der folgenden drei Eigenschaften versprechen kann:

• Konsistenz
• Verfügbarkeit
• Partitionstoleranz

Dies ist sehr abstrakt und die Terminologie ist nicht gerade intuitiv, daher werden wir in diesem Artikel unser Bestes tun, um dieses Problem zu lösen theorie von abstrakten zu mehr realen Gesprächen und Beispielen. Dieser Satz kann Sie dazu bringen, über Ihre Datenbankarchitektur nachzudenken, was Ihre Anwendung wirklich benötigt und welche Opfer sie möglicherweise bringen muss, um diese zu erreichen.

Definition der CAP-Terminologie

Lassen Sie uns einige grundlegende Definitionen aus dem Weg räumen, damit wir auf derselben Seite sein können, wenn wir über diesen Satz sprechen.

CAP – Konsistenz, Verfügbarkeit, Partitionstoleranz

• Konsistenz – Alle Ihre Datenserver haben die gleichen Daten, so dass Sie jeden Server im System abfragen und genau die gleichen Daten erhalten können.
• Verfügbarkeit – Jede Anfrage an die Datenserver erhält eine Antwort. Wenn ein Server ausgelastet ist, wird er an einen anderen Server weitergeleitet, der antworten kann.
• Partitionstoleranz – Die Fähigkeit des Systems, weiter zu arbeiten, selbst wenn Netzwerkfehler auftreten und einige der Server nicht kommunizieren können.

Zugrunde liegende Annahme – P ist unmöglich

In einem verteilten Datenbanksystem werden Ihre Daten auf verschiedene Server aufgeteilt, und diese Server kommunizieren über ein Netzwerk miteinander, sodass sie denselben Datensatz verwalten können. Das Problem ist, dass Netzwerke brechen und so gehen wir davon aus, dass es immer kommunizieren wird, dh wir können kein perfektes Netzwerk haben. In Bezug auf diese Theorie bedeutet dies, dass Sie in der realen Welt Partitionstoleranz opfern müssen. Wenn das perfekte unfehlbare Netzwerk existieren würde, hätten wir kein Problem damit, Konsistenz und Verfügbarkeit zu erreichen, aber dies ist die reale Welt, die auf physischen Drähten basiert, die versagen, und wir gehen davon aus, dass sie versagen wird.

Wenn P unmöglich ist, was sind unsere Entscheidungen?

Da wir die Partitionstoleranz aufgegeben haben, sagt der Satz, dass wir jetzt zwischen Konsistenz und Verfügbarkeit wählen müssen.

Sie können wählen, Verfügbarkeit zu haben, wo Ihre Anwendung alle eingehenden Anfragen erfüllen kann, aber es kann nicht garantiert werden, dass die Daten die neuesten sind.

Was braucht Ihre Anwendung?

Wenn Ihre Anwendung eine Social-Media-Site ist und nicht immer über die neuesten Daten verfügen muss, sollten Sie die Verfügbarkeit auswählen. Ist es wichtig, dass Ihre Benutzer einen Beitrag nach einer Verzögerung von 30 Sekunden sehen? Wenn nicht, bevorzugen Sie möglicherweise die Verfügbarkeit, da Sie priorisieren, dass Ihre Benutzer auf Daten zugreifen können, auch wenn es sich nicht um die aktuellsten Daten handelt.

Wenn Ihre Anwendung andererseits erfordert, dass jeder Lesevorgang in die Datenbank die absolut neuesten Daten sind, müssen Sie die Verfügbarkeit opfern und die Konsistenz wählen. Einige Anfragen müssen fehlerhaft sein, da die Informationen nicht garantiert werden können, dass es sich um die absolut neueste handelt.

Die Entscheidungen von relationalen und NoSQL

Datenbanktechnologien wie SQL und andere relationale Datenbanksysteme, die mit ACID entwickelt wurden, priorisieren die Konsistenz. Auf der anderen Seite priorisieren die meisten NoSQL-Datenbanken die Verfügbarkeit.

Fazit

Wir glauben, dass die Prüfung dieses Theorems in Bezug auf Ihre Bewerbung eine hervorragende Übung ist und Ihnen hilft, die Prioritäten Ihrer Bewerbung zu bewerten. Wenn Sie ein verteiltes Datensystem haben, untersuchen Sie Ihre Architektur und verstehen Sie, welches Opfer Sie bringen. MongoDB, CockroachDB und Postgres sind heute großartige Datenbanktechnologien, die unsere Datenbankarchitekturen extrem robust machen, aber wie wir bereits besprochen haben, sind sie nicht perfekt. Wir haben kein perfektes Netzwerk und es gibt immer „Benutzerfehler“. Wenn Sie in eine Produktionsumgebung wechseln und die besten Optionen für Ihre Anwendung besprechen möchten, zögern Sie bitte nicht, uns bei Object Rocket zu kontaktieren.