Reihe von Artikeln

1. Gründe, auf die Sie achten sollten
2. Wahrscheinliche Probleme
3. Hindernisse für die Adoption
4. Wie der neue Algorithmus helfen kann

Es ist sehr selten, dass letztendlich konsistente Datenbanken besser sind als starke Konsistenzdatenbanken. Darüber hinaus ist es in Multi-Region-Anwendungsszenarien, die erweitert werden müssen, noch zweifelhafter, eine nicht verteilte Datenbank oder eine endgültige konsistente Datenbank auszuw?hlen. Was fordert also Ingenieure auf, stark konsistente verteilte Datenbanken zu ignorieren? Wir haben viele Gründe gesehen, aber die falsche Annahme ist der Fahrer.

"Cap Theorem zeigt, dass dies unm?glich ist"

Wie wir im ersten Teil dieser Serie erkl?ren, wird der CAP -Theorem weithin akzeptiert, aber oft missverstanden. Wenn viele Menschen einen berühmten Theorem falsch verstehen, hinterl?sst es seine Spuren. In diesem Fall glauben viele Ingenieure immer noch, dass die endgültige Konsistenz ein notwendiges übel ist.

"Es ist zu schwierig/unm?glich, eine stark konsistente verteilte Datenbank zu erstellen."

Es wurde allm?hlich erkannt, dass Konsistenz nicht geopfert werden sollte, aber viele Datenbanken setzen immer noch die Konsistenz an zweiter Stelle. Warum ist das? Einige beliebte Datenbanken bieten Optionen für eine h?here Konsistenz, aber auf Kosten einer sehr hohen Latenz. Ihre Verkaufsinformationen k?nnen sogar behaupten, dass die Konsistenz mit geringer Latenz in verteilten Datenbanken mit mehreren Regionen schwierig oder sogar unm?glich ist, w?hrend die Entwicklergemeinschaft eine tiefe Erinnerung an eine sehr schlechte Latenz in nicht konsistenten Datenbanken hat. Die Kombination der beiden zusammenfasst das Missverst?ndnis, dass eine starke Konsistenz in verteilten Datenbanken mit relativ geringer Latenz unm?glich ist.

"Frühgeborene Optimierung ist die Quelle des gesamten B?sen"

Viele Ingenieure bauen auf dem Prinzip auf, dass ?vorzeitige Optimierung die Quelle des gesamten B?sen ist“ (Donald Knuth), aber diese Aussage gilt nur für kleine Ineffizienzen. Das Aufbau Ihres Startups in einer stark konsistenten verteilten skalierbaren Datenbank scheint eine vorzeitige Optimierung zu sein, da Ihre Anwendung zun?chst nicht skaliert werden muss und wahrscheinlich nicht verteilt werden muss. Wir sprechen hier jedoch keine kleine Ineffizienz. Wenn Ihre Bewerbung popul?r wird, k?nnen skalierbare oder verteilte Anforderungen über Nacht erscheinen. Zu diesem Zeitpunkt werden Ihre Benutzer eine schlechte Erfahrung erleben und Sie werden vor einer gro?en Herausforderung stehen, Ihre Infrastruktur und Ihren Code zu ?ndern.

"Es ist schwierig, eine verteilte Datenbank zu programmieren"

Da verteilte Datenbanken neu sind und viele Datenbanken schwerwiegende Einschr?nkungen haben, machte dieser Satz einst sinnvoll. Sie erlauben keine Verbindungen, nur einen Schlüsselwertspeicher oder verlangen, dass Sie Daten basierend auf vordefinierten Shard-Schlüssel abfragen, die Sie sp?ter nicht ?ndern k?nnen. Heute haben wir verteilte Datenbanken mit flexiblen Modellen und der Flexibilit?t, mit der Sie herk?mmliche Datenbanken verwendet werden. Dies h?ngt eng mit dem vorherigen Punkt zusammen, der die Tatsache ignoriert, dass es heute ebenso einfach ist, mit der Programmierung für eine stark konsistente verteilte Datenbank zu beginnen wie herk?mmliche Datenbanken und auf lange Sicht m?glicherweise einfacher. Wenn es gleich einfach ist, warum nicht von Anfang an optimieren?

Die Verwendung einer endgültigen Konsistenzdatenbank ist wie ...

Verteilte Datenbanken werden h?ufig von Personen erstellt, die das ultimative Konsistenzproblem erlebt haben. Zum Beispiel wurde Faunadb von einem ehemaligen Twitter -Ingenieur erstellt, nachdem er erlebt hatte, wie schwierig es war, ein skalierbares System auf einer beliebten endgültigen Konsistenzdatenbank wie Cassandra zu erstellen. Diese Probleme treten oft auf, wenn neue Unternehmen zu expandieren beginnen, so viele junge Ingenieure haben sie nie pers?nlich erlebt.

Manchmal k?nnen schmerzhafte Dinge uns Lektionen beibringen, von denen wir nicht glauben, dass wir es wissen müssen.

- Amy Poehler

Die Diskussion der Gefahr der endgültigen Konsistenz führt h?ufig in Ingenieuren, die noch keine Probleme hatten, um das Argument vorzulegen, dass ?dies für mich funktioniert“. Da dies normalerweise Monate (oder Jahre, wenn Sie Glück haben) dauert, schauen wir uns eine Analogie an.

… Fahrrad mit losen R?dern fahren.

Vor nicht allzu langer Zeit verpasste mein bester Freund das Date fast, also habe ich ihm mein Fahrrad geliehen. Ich bin froh, dass ich geholfen habe, er ist froh, alles geht gut. Das Vergnügen wurde schnell zu Schmerzen, als er versuchte, das Fahrrad zum Bürgersteig zu springen. Sie sehen ... Ich habe früher an diesem Tag mit dem Fahrrad herumgespielt und vergessen, die Vorderr?der festzuziehen. Er kehrte mit einem riesigen lila Bluterguss zurück.

Das Beispiel des Fahrrads ist der Verwendung einer nicht starken Konsistenzdatenbank sehr ?hnlich. Alles l?uft gut, bevor Sie versuchen, die R?der des Fahrrads zu heben (oder mit anderen Worten, bis Ihr Unternehmen abhebt und sich ausdehnt).

Wenn Ihre Bewerbung erweitert werden muss, implementieren Sie sie normalerweise durch Kopieren des Dienstes. Sobald die Datenbank zum Engpass wird, replizieren Sie Ihre herk?mmliche Datenbank oder migrieren Sie in eine verteilte Datenbank. Leider kann zu diesem Zeitpunkt, wenn Sie die Datenbank kopieren, die Funktionalit?t in Ihrer Anwendung unterbrochen. Bisher haben Sie diese Probleme nicht bemerkt, weil die Datenbank auf einem Knoten ausgeführt wird. Zu dieser Zeit k?nnten zwei Dinge passieren:

• Fall 1, erstellen/beheben Sie es um es herum: Entwickler erkennen schnell, dass die Datenbank, in der sie "reiten", für die Funktionalit?t, die sie aufgebaut haben oder zu erstellen versuchen, unzuverl?ssig ist. Ihre Auswahl l?uft auf Stornierungsfunktionen, Vereinfachung von Funktionen oder das ?ndern der Datenbank.
• Situation 2, Herbst: Der Entwickler hat keine gute Information vom Verk?ufer (ich bin ein schlechter Fahrradanbieter für meine Freunde) über die Risiken erhalten. Es gibt jetzt einen Mangel an Informationen, um die sehr subtile Bedeutung dessen zu verstehen, was los ist. Dies ist nicht unbedingt auf die mangelnden F?higkeiten der Ingenieure zurückzuführen. Lazy definierte Standards und optimistisches Marketing machen gro?artige Arbeit, um die Konsistenzgarantien verschiedener Datenbanken zu verwechseln.

Entwickler, die im ersten Fall enden, werden h?ufig beim Umgang mit dem endgültigen Konsistenzsystem auftreten. Sie akzeptieren jetzt entweder, dass sie keine bestimmte Funktionalit?t liefern k?nnen, oder sie erstellen eine komplexe und schwer zu macht über die Datenbank schwer zu machende Schicht, um das zu erhalten, was sie ben?tigen. Im Wesentlichen versuchen sie, eine starke Konsistenzdatenbank über der endgültigen Konsistenzdatenbank zu entwickeln. Schade, da andere verteilte Datenbanken von Grund auf neu gestaltet haben, die nicht nur effizienter sind, sondern keine Wartung von Ihrem Entwicklungsteam erfordern!

… Fahrrad mit losen R?dern fahren und unsichtbar.

Der Entwickler, der in der zweiten Situation landete, fuhr ein teilweise unsichtbares Fahrrad. Sie merkten nicht, dass die R?der locker waren, sie sahen nicht, wie die R?der abfallen, und sobald sie nach dem Sturz aufblicken, sahen sie immer noch ein v?llig intaktes Fahrrad.

Wenn die Dinge schief gehen, ist die Komplexit?t der L?sung dieser Fehler aus den folgenden Gründen hoch:

• Stellen Sie fest, ob es sich um einen endgültigen Konsistenzfehler handelt. Das Problem kann ein Anwendungsfehler oder ein Fehler sein, der durch Missverst?ndnisse der Garantien der zugrunde liegenden Datenbank verursacht wird. Natürlich müssen wir die Anwendungslogik untersuchen, und wenn die Anwendungslogik in einer nicht verteilten Umgebung angemessen ist, müssen die Ingenieure den Instinkt haben, zu bewerten, ob diese Situation aufgrund der endgültigen Konsistenz auftreten kann.
• Der Grund verschwand. Zweitens kann die Wurzel des Problems verschwunden sein (die R?der sind auf magische Weise wieder mit dem Fahrrad verbunden, und alles, was Sie sehen, ist ein perfektes Fahrrad).
• Repariere es! Sobald das Problem identifiziert ist, k?nnen Sie eine L?sung finden, versuchen, eine Ebene über der Datenbank (HI, Latenz und andere potenzielle Fehler) zu erstellen, Funktionen zu l?schen oder die Datenbank zu ?ndern. Die letzte Option wird manchmal als einfach angesehen. Selbst die geringsten Unterschiede zwischen Datenbanken k?nnen diese Arbeit sehr schwierig machen. Wenn Ihre App startet, sind Sie bereits besch?ftigt. Dies ist nicht die Zeit, in der Sie die Datenbank ?ndern m?chten!

… Fahren Sie ein Fahrrad mit einem losen Rad, unsichtbar und einer Gruppe von Menschen, die auf Ihren Schultern stehen.

Das Invisible Bike -Beispiel ist immer noch zu verzeihend. Tats?chlich k?nnen andere von Ihrer Bewerbung abh?ngen. Grunds?tzlich fahren Sie mit einem unsichtbaren Fahrrad, w?hrend andere (Ihre Kunden) auf Ihren Schultern stehen.

Sie werden nicht nur fallen, sie werden auch mit Ihnen fallen und schwer und schmerzhaft auf Sie fallen. Sie k?nnen diesen Herbst nicht einmal überleben; Mit anderen Worten, Ihr Unternehmen kann dem Sturm negativer Feedback der Kunden m?glicherweise nicht standhalten.

Was ist die Moral der Geschichte? Wenn Sie von Anfang an eine starke Konsistenz- (und ultimative Konsistenz-) Datenbank w?hlen, müssen Sie nicht in Betracht ziehen, an einem komplexen und ressourcenintensiven Projekt wie der Migration einer Datenbank zu arbeiten, wenn Ihre Kunden bereits frustriert sind.

abschlie?end

Vor einigen Jahren war es vernünftig, die endgültige Konsistenzdatenbank zu skalieren, da zu diesem Zeitpunkt keine andere Option vorhanden war. Wir haben jetzt jedoch moderne Datenbanken, die effizient skalieren k?nnen, ohne die Datenkonsistenz oder Leistung zu beeintr?chtigen. Darüber hinaus enthalten diese modernen Datenbanken viele andere leistungsstarke Funktionen, die über die Konsistenz hinausgehen, wie z. B. Benutzerfreundlichkeit, serverloses Preismodell, integrierte Authentifizierung, Aktualit?t, natives GraphQL und mehr. Mit modernen Datenbanken k?nnen Sie skalieren, ohne Pandoras Box zu ?ffnen!

Und wenn Sie sich nach dem Lesen dieser Serie immer noch für eine stark konsistente verteilte Datenbank entscheiden, stellen Sie zumindest sicher, dass Sie Ihre R?der festziehen (mit anderen Worten, lesen und verstehen Sie die Konsistenzgarantien verschiedener Datenbanken).

Reihe von Artikeln

1. Gründe, auf die Sie achten sollten
2. Wahrscheinliche Probleme
3. Hindernisse für die Adoption
4. Wie der neue Algorithmus helfen kann

Das obige ist der detaillierte Inhalt vonKonsequente Backends und UX: Was sind die Hindernisse für die Adoption?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!