Ich liebe serverlose Technologie. Ich spiele herum und erstelle viele verschiedene serverlose Anwendungen, um mit anderen coolen Technologien herumzuexperimentieren. Innerhalb des riesigen Clusters von Technologien, die ich verwende/mit denen ich experimentiere, war PlanetScale war die Datenbank, die ich hauptsächlich für meine persönlichen Nebenprojekte verwendet habe, da es keine andere "gute" Option gab, die das Prisma ORM unterstützte .
PlanetScale ist eine serverlose MySQL-Plattform, die einfach Vitess verkauft, ein Datenbank-Clustering-System für die horizontale Skalierung von MySQL. Sie haben ihre eigene Datenbank nicht geschrieben - möglicherweise dazu beigetragen, aber sie haben sie nicht geschrieben. Aus der Vitess-Dokumentation:
Vitess wurde 2010 gegründet um die Herausforderungen der MySQL-Skalierbarkeit zu lösen, mit denen das Team bei YouTube konfrontiert war.
In diesem Artikel nähern wir uns dem Verständnis der Struktur dieser nicht-ACID-Legacy-Sharding-Datenbanken, warum sie etwas so Wichtiges wie die referenzielle Integrität nicht unterstützen können und warum wir sie in unseren Anwendungen nicht verwenden sollten. In diesem Artikel geht es mehr um die Technologie von Vitess, obwohl ich PlanetScale in den Titel aufgenommen habe, weil es, wie ich oben erwähnt habe, Vitess (mit einigen Werkzeugen) nur als Service verkauft und sie in den folgenden Monaten als solche an Bedeutung gewonnen haben eine "zuverlässige" serverlose Datenbank.
Hintergrund
Meine anfängliche Frage war, warum es heißt, dass es unmöglich ist, eine PlanetScale-Datenbank mit referenzieller Integrität zu skalieren, da in ihrer Dokumentation Folgendes angegeben ist:
Der Weg FOREIGN KEY Einschränkungen in MySQL (oder besser gesagt in der InnoDB-Speicher-Engine) implementiert sind, stören Online-DDL-Operationen. Erfahren Sie mehr in diesem Vitess-Blogbeitrag.
Beschränkt auf einen einzelnen MySQL-Serverbereich, FOREIGN KEY Einschränkungen sind nicht mehr aufrechtzuerhalten, wenn Ihre Daten wachsen und auf mehrere Datenbankserver verteilt sind. Dies geschieht normalerweise, wenn Sie funktionale Partitionierung/Sharding und/oder horizontales Sharding einführen.
Das brachte mich auf den Gedanken:mach FOREIGN KEY Beschränkungen beeinflussen die Skalierbarkeit im Allgemeinen? und wenn ja, wie?
Ich denke, es ist wichtig zu erkennen, dass SQL-Tabellenverknüpfungen ziemlich kostspielig sind, aber meines Wissens wurde es nicht stark von der referenziellen Integrität beeinflusst? Wenn wir jetzt so etwas wie Datenanalyse machen, brauchen wir offensichtlich keine referenzielle Integrität, da wir unsere Daten einfach in eine einzige Tabelle werfen wollen, aber PlanetScale und Vitess rühmen sich damit, von großen Webanwendungen verwendet zu werden wie YouTube.
Dies führte dazu, dass ich verwirrt war, warum sie den FOREIGN KEY fallen ließen Einschränkung, da Datenbanken wie CockroachDB und Spanner weiterhin die referenzielle Integrität bewahren und skalierbar sind.
Was ist referenzielle Integrität und warum ist sie wichtig?
Beginnen wir mit den Grundlagen, falls Sie neu sind. Ich vermute, dass die meisten Leute, die diesen Beitrag lesen, eine ziemliche Vorstellung davon haben, wovon sie sprechen, aber ich erkläre es als Formalität. In einfachen Worten, ein FOREIGN KEY Constraint ist ein Datenbankschlüssel, mit dem wir Beziehungen zwischen zwei verschiedenen Tabellen herstellen können, indem wir auf eine Spalte oder einen Satz von Spalten verweisen. Referentielle Integrität bezieht sich einfach auf den Zustand der Datenbank, in dem alle Werte aller Schlüssel gültig sind.
Warum ist es wichtig?
Nachdem wir nun eine ungefähre Vorstellung davon haben, was sie sind, springen wir zum zweiten Teil:Warum sind sie wichtig?
Die referenzielle Integrität ist wichtig, da sie Sie davon abhält, neue Fehler in Ihre Datenbank einzuführen. Diese Funktion wird häufig von relationalen Datenbanken bereitgestellt und verhindert, dass Benutzer oder Anwendungen inkonsistente Daten in die Datenbank eingeben. Dies führt zu verbesserter Datenqualität, schnellerer Entwicklung, viel weniger Fehlern und Konsistenz in Ihrer gesamten Anwendung.
Warum hat Vitess es nicht?
Um zu verstehen, warum Vitess die referentielle Integrität nicht unterstützen kann, müssen wir uns also mit der Architektur der Datenbank befassen. Vitess ist eine fragmentierte Nicht-ACID-SQL-Datenbank, keine echte verteilte ACID-SQL-Datenbank.
Jetzt fragen Sie sich sicher, was diese Begriffe sind. Lassen Sie mich sie für Sie aufschlüsseln:ACID ist ein Akronym für Atomicity, Consistency, Isolation und Durability.
Atomarität bezieht sich hier auf eine Aktion, die entweder abgeschlossen wird oder vollständig fehlschlägt - kein teilweiser Abschluss einer Transaktion. Konsistenz bezieht sich darauf, dass die Transaktion die Datenbank in einem gültigen Zustand verlässt. Isolation bedeutet einfach, dass zwei Transaktionen ohne gegenseitige Beeinflussung ausgeführt werden, und Dauerhaftigkeit bedeutet, dass die Änderungen der Transaktion gespeichert werden.
Ein Shard ist eine horizontale Partition von Daten in einer Datenbank, und jeder Shard wird auf einer separaten Datenbankserverinstanz gehalten, um die Last zu verteilen. Wenn wir uns also auf eine geteilte Datenbank beziehen, sprechen wir über so etwas. Wie ich bereits sagte, ist Vitess eine fragmentierte Nicht-ACID-SQL-Datenbank, was im Grunde bedeutet, dass sie die ACID-Eigenschaften von Transaktionen NICHT garantiert.
Warum fallen lassen?
Nun, das Problem beginnt, wenn Sie eine MySQL-Datenbank mit einem wohldefinierten Schema haben und Ihr Dienst mit dem Problem populär wird, dass zu viele Lesevorgänge die Datenbank treffen. Die meisten Leute beginnen hier damit, häufig ausgeführte Abfragen zwischenzuspeichern, aber die Lesevorgänge sind nicht mehr ACIDic.
Neben zu vielen Lesevorgängen ist eine übermäßige Anzahl von Schreibvorgängen in Ihrer Datenbank ein ernstes Problem, mit dem viele konfrontiert sein könnten. Nehmen wir an, wir sind bereit, unsere Taschen in Brand zu stecken – wir können vertikal skalieren, indem wir mehr RAM, einen 16-Kern-Prozessor und jede Menge wirklich schneller Solid-State-Laufwerke hinzufügen.
Wir haben natürlich immer noch das Problem, dass SQL-Tabellen-Joins immer komplexer werden, also beginnen Sie mit der Denormalisierung, um Joins zwischen Tabellen zu vermeiden.
Ich habe vor einiger Zeit einen Vortrag auf dem Prisma Meetup gehalten, in dem ich die Grundlagen des Entwurfs einer relationalen Datenbank erläutert habe. Ein Thema, das ich hier behandelt habe, war die Denormalisierung. Wenn Sie daran interessiert sind, sollten Sie sich das unbedingt ansehen.
Aber die Denormalisierung ist im Grunde der Prozess, bei dem Sie redundante Daten zu Tabellen in Ihrer Datenbank hinzufügen, was die Leistung auf Kosten des Festplattenspeichers verbessert, da Sie keine CPU-Leistung mehr für Verknüpfungen verwenden. Während die Denormalisierung die Lesegeschwindigkeit verbessert, ist es wichtig zu wissen, dass dadurch das Schreiben langsamer wird.
Trotz alledem ist unsere Datenbank immer noch langsam, sodass wir Datenbankberechnungen auf den Client verlagern, zum Beispiel eine UUID generieren oder ein Datum zuweisen.
Selbst nach all dem werden Abfragen immer noch langsam sein - daher halten wir das Ergebnis der am häufigsten abgefragten Daten in einem Prozess bereit, der als Datenbankmaterialisierung bekannt ist. Jetzt sind Lesevorgänge möglicherweise schneller, aber Schreibvorgänge werden von Tag zu Tag langsamer. Die einzig logische Situation ist jetzt, Sekundärindizes zu löschen.
An diesem Punkt hat unsere Datenbank also
- Keine ACID-Eigenschaften wegen Caching
- Kein normalisiertes Schema
- Keine Auslöser
- Keine Datenbankberechnungen
- Keine sekundären Indizes
Dies ebnete den Weg für Vitess- und NoSQL-Datenbanken, da Unternehmen Probleme mit der Skalierung ihrer Datenbank hatten. Die Art und Weise, wie es entworfen wurde, war nicht in der Lage, die Datenkonsistenz, eine ACID-Eigenschaft, aufrechtzuerhalten, wenn Transaktionen mehrere verschiedene Shards umfassten. Bei der referenziellen Integrität dreht sich alles um Konsistenz, wenn sich Daten über mehrere Shards erstrecken, daher ist es sinnvoll, dass sie sie nicht gut unterstützen können.
Wir können ohne FOREIGN KEY tief in die Struktur von NoSQL-Datenbanken einsteigen Beschränkungen und Probleme, mit denen wir konfrontiert werden, wenn wir dieses Modell übernehmen, aber das ist das Thema für einen anderen Beitrag.
Es ist nicht nur Vitess, es ist eine Standardpraxis für Sharding-Datenbanken, um die referenzielle Integrität zu vermeiden, da es einfach keine andere Wahl gibt. In Bezug auf das ACID-Modell heißt es in ihrer Dokumentation, dass sie Atomarität, aber keine Isolation garantieren, und geht sogar so weit zu sagen:
Die Gewährleistung der ACID-Isolation ist sehr umstritten und mit hohen Kosten verbunden. Die Bereitstellung als Standard hätte Vitess für die häufigsten Anwendungsfälle unpraktisch gemacht.
Lassen Sie uns kurz darüber sprechen, was ACID Isolation ist. Es gibt vier Ebenen (gemäß den SQL-92-Standards), einschließlich Serialisierbarkeit, Read Committed, Read Uncommitted und Repeatable Reads. Abgesehen davon gibt es weitere Isolationsstufen, wie z. B. die Snapshot-Isolation, die kein SQL-Standard ist, obwohl sie von mehreren Datenbanken wie Firebase oder MongoDB verwendet wird. Wenn Sie sich weiter dafür interessieren, empfehle ich Ihnen, diesen Beitrag zu lesen. Um es kurz zu halten, ich werde nicht darauf eingehen, was jede Isolationsstufe tut/bedeutet, aber wenn Sie mehr darüber lesen möchten, sehen Sie sich diese Seite aus der MySQL-Dokumentation an.
Die ACID-Isolation bezieht sich darauf, dass die Datenbanktransaktionen ACIDic sind, was wichtig ist, da sie garantieren, dass sich die Operationen so verhalten, wie es die Entwickler erwarten. Ich bin mir nicht sicher, was sie meinen, wenn sie sagen:"Die Gewährleistung der ACID-Isolation ist sehr umstritten und mit hohen Kosten verbunden", aber wenn sie meinen, dass die Gewährleistung der ACID-Isolation hohe Kosten für jedes Produkt verursacht , sie liegen falsch. Mehrere verteilte ACID-konforme Datenbanken haben die höchste Isolationsstufe (serialisierbare Transaktionen) und sind dennoch leistungsfähig mit schnellen Lese-/Schreibgeschwindigkeiten. Im Zusammenhang mit Vitess liegen sie jedoch nicht falsch, da Transaktionen über mehrere Shards hinweg kein Isolationsniveau erreichen können.
Fazit
Bei all dem müssen Sie sich fragen:Warum sollte jemand PlanetScale oder Vitess verwenden wollen? Nun, das frage ich mich auch. Bei vielen Unternehmen und Websites lag der Grund darin, dass sie sich für Vitess entschieden haben, als es keine besseren Optionen gab. Wenn Sie zum Anfang des Artikels gehen, beachten Sie, wie er im Jahr 2010 erstellt wurde. Jetzt, da wir eine ACID-konforme, skalierbare Datenbank mit referenzieller Integrität genießen können, wäre es in unserem besten Interesse, auf diese neuen Datenbanken umzusteigen, und ich hab schon damit angefangen! Die Technologie ändert sich schnell, und es ist eine entscheidende Komponente jeder Anwendung, Ihre Datenbank auf dem neuesten Stand zu halten.
