Grundlegendes zum Datenbank-Sharding

Jede Anwendung oder Website, die ein erhebliches Wachstum verzeichnet, muss möglicherweise skaliert werden, um dem Anstieg des Datenverkehrs Rechnung zu tragen. Bei datengesteuerten Anwendungen und Websites ist es wichtig, dass die Skalierung so erfolgt, dass die Sicherheit und Integrität der Daten gewährleistet ist. Es kann schwierig sein, vorherzusagen, wie beliebt oder wie lange eine Website oder Anwendung sein wird, weshalb einige Unternehmen eine Datenbankarchitektur wählen, mit der sie ihre Datenbanken dynamisch skalieren können.

In diesem konzeptionellen Artikel werden wir eine solche Datenbankarchitektur diskutieren:sharded databases. Sharding hat in den letzten Jahren viel Aufmerksamkeit erhalten, aber viele wissen nicht genau, was es ist oder in welchen Szenarien es sinnvoll sein könnte, eine Datenbank zu sharden. Wir werden uns ansehen, was Scherben sind, welche Vor- und Nachteile sie haben und welche gängigen Scherbenmethoden es gibt.

Sharding ist ein Datenbankarchitekturmuster, das sich aufhorizontal partitioning bezieht - die Praxis, die Zeilen einer Tabelle in mehrere verschiedene Tabellen zu trennen, die als Partitionen bezeichnet werden. Jede Partition hat dasselbe Schema und dieselben Spalten, aber auch völlig unterschiedliche Zeilen. Ebenso sind die Daten in den einzelnen Partitionen eindeutig und unabhängig von den Daten in den anderen Partitionen.

Es kann hilfreich sein, sich die horizontale Partitionierung in Bezug aufvertical partitioning vorzustellen. In einer vertikal partitionierten Tabelle werden ganze Spalten herausgetrennt und in neue, unterschiedliche Tabellen eingefügt. Die Daten in einer vertikalen Partition sind unabhängig von den Daten in allen anderen Partitionen und enthalten jeweils unterschiedliche Zeilen und Spalten. Das folgende Diagramm zeigt, wie eine Tabelle sowohl horizontal als auch vertikal partitioniert werden kann:

Beim Sharding werden die Daten in zwei oder mehr kleinere Blöcke aufgeteilt, die alslogical shards bezeichnet werden. Die logischen Shards werden dann auf separate Datenbankknoten verteilt, die alsphysical shards bezeichnet werden und mehrere logische Shards enthalten können. Trotzdem stellen die in allen Shards enthaltenen Daten zusammen einen gesamten logischen Datensatz dar.

Datenbank-Shards veranschaulichen einshared-nothing architecture. Dies bedeutet, dass die Scherben autonom sind; Sie teilen sich keine Daten oder Rechenressourcen. In einigen Fällen kann es jedoch sinnvoll sein, bestimmte Tabellen in jeden Shard zu replizieren, um als Referenztabellen zu dienen. Angenommen, es gibt eine Datenbank für eine Anwendung, die von festen Umrechnungskursen für Gewichtsmessungen abhängt. Durch das Replizieren einer Tabelle mit den erforderlichen Conversion-Rate-Daten in jeden Shard kann sichergestellt werden, dass alle für Abfragen erforderlichen Daten in jedem Shard gespeichert sind.

Oft wird das Sharding auf Anwendungsebene implementiert, was bedeutet, dass die Anwendung Code enthält, der definiert, auf welchen Shard Lese- und Schreibvorgänge übertragen werden sollen. Einige Datenbankverwaltungssysteme verfügen jedoch über integrierte Sharding-Funktionen, mit denen Sie Sharding direkt auf Datenbankebene implementieren können.

In Anbetracht dieses allgemeinen Überblicks über das Sharding gehen wir einige der mit dieser Datenbankarchitektur verbundenen positiven und negativen Aspekte durch.

Der Hauptanreiz beim Sharding einer Datenbank besteht darin, dass sie dazu beitragen kann,horizontal scaling, auch alsscaling out bezeichnet, zu vereinfachen. Bei der horizontalen Skalierung werden einem vorhandenen Stapel mehr Maschinen hinzugefügt, um die Last zu verteilen und mehr Verkehr und eine schnellere Verarbeitung zu ermöglichen. Dies steht häufig im Gegensatz zuvertical scaling, auch bekannt alsscaling up, bei dem die Hardware eines vorhandenen Servers aktualisiert wird, normalerweise durch Hinzufügen von mehr RAM oder CPU.

Es ist relativ einfach, eine relationale Datenbank auf einem einzelnen Computer auszuführen und sie nach Bedarf zu skalieren, indem die Computerressourcen aktualisiert werden. Letztendlich wird jedoch jede nicht verteilte Datenbank in Bezug auf Speicherplatz und Rechenleistung begrenzt sein, sodass die Möglichkeit der horizontalen Skalierung Ihr Setup wesentlich flexibler macht.

Ein weiterer Grund, warum sich manche für eine Sharded-Datenbankarchitektur entscheiden, ist die schnellere Beantwortung von Anfragen. Wenn Sie eine Abfrage in einer Datenbank senden, die nicht gesharded wurde, muss sie möglicherweise jede Zeile in der Tabelle durchsuchen, die Sie abfragen, bevor die gesuchte Ergebnismenge gefunden werden kann. Bei einer Anwendung mit einer großen, monolithischen Datenbank können Abfragen sehr langsam werden. Durch das Teilen einer Tabelle in mehrere müssen Abfragen jedoch weniger Zeilen umfassen, und ihre Ergebnismengen werden viel schneller zurückgegeben.

Sharding kann auch dazu beitragen, eine Anwendung zuverlässiger zu machen, indem die Auswirkungen von Ausfällen gemindert werden. Wenn Ihre Anwendung oder Website auf einer nicht gesicherten Datenbank basiert, kann ein Ausfall dazu führen, dass die gesamte Anwendung nicht verfügbar ist. Bei einer Sharded-Datenbank wirkt sich ein Ausfall jedoch wahrscheinlich nur auf einen einzigen Shard aus. Auch wenn dies dazu führen kann, dass einige Teile der Anwendung oder Website für einige Benutzer nicht verfügbar sind, ist die Gesamtauswirkung dennoch geringer als bei einem Absturz der gesamten Datenbank.

Das Sharding einer Datenbank kann die Skalierung vereinfachen und die Leistung verbessern, kann jedoch auch bestimmte Einschränkungen mit sich bringen. Hier werden wir einige davon diskutieren und erklären, warum dies Gründe sein könnten, um Scherben zu vermeiden.

Die erste Schwierigkeit, auf die Menschen beim Sharding stoßen, ist die Komplexität der ordnungsgemäßen Implementierung einer Sharded-Datenbankarchitektur. Bei fehlerhafter Ausführung besteht ein erhebliches Risiko, dass der Sharding-Prozess zu Datenverlust oder beschädigten Tabellen führen kann. Selbst wenn dies korrekt durchgeführt wird, hat das Splittern wahrscheinlich einen großen Einfluss auf die Arbeitsabläufe Ihres Teams. Anstatt von einem einzigen Einstiegspunkt aus auf die Daten zuzugreifen und diese zu verwalten, müssen Benutzer Daten über mehrere Shard-Standorte hinweg verwalten, was für einige Teams möglicherweise störend sein kann.

Ein Problem, auf das Benutzer nach dem Löschen einer Datenbank manchmal stoßen, besteht darin, dass die Scherben schließlich aus dem Gleichgewicht geraten. Angenommen, Sie haben eine Datenbank mit zwei separaten Shards, einer für Kunden, deren Nachnamen mit den Buchstaben A bis M beginnen, und einer für Kunden, deren Namen mit den Buchstaben N bis Z beginnen. Ihre Bewerbung dient jedoch einer übermäßigen Anzahl von Personen, deren Nachname mit dem Buchstaben G beginnt. Dementsprechend sammelt der A-M-Shard nach und nach mehr Daten als der N-Z-Shard, sodass die Anwendung langsamer wird und für einen erheblichen Teil Ihrer Benutzer nicht mehr funktioniert. Der A-M-Splitter ist zu einem sogenanntendatabase hotspot geworden. In diesem Fall werden alle Vorteile des Shardings der Datenbank durch die Verlangsamungen und Abstürze aufgehoben. Die Datenbank müsste wahrscheinlich repariert und erneut gesichert werden, um eine gleichmäßigere Datenverteilung zu ermöglichen.

Ein weiterer großer Nachteil ist, dass es nach dem Sharding einer Datenbank sehr schwierig sein kann, sie wieder in ihre nicht gesicherte Architektur zu versetzen. Alle Backups der Datenbank, die vor dem Löschen erstellt wurden, enthalten keine Daten, die seit der Partitionierung geschrieben wurden. Infolgedessen würde das Wiederherstellen der ursprünglichen, nicht gesicherten Architektur das Zusammenführen der neuen, partitionierten Daten mit den alten Sicherungen oder alternativ das Zurücktransformieren der partitionierten Datenbank in eine einzelne Datenbank erfordern, was kostspielig und zeitaufwendig wäre.

Ein letzter zu berücksichtigender Nachteil ist, dass Sharding nicht von jedem Datenbankmodul nativ unterstützt wird. Beispielsweise enthält PostgreSQL kein automatisches Sharding als Feature, obwohl es möglich ist, eine PostgreSQL-Datenbank manuell zu sharden. Es gibt eine Reihe von Postgres-Gabeln, die automatisches Sharding enthalten, die jedoch häufig hinter der neuesten PostgreSQL-Version zurückbleiben und denen bestimmte andere Funktionen fehlen. Einige spezialisierte Datenbanktechnologien - wie MySQL Cluster oder bestimmte Database-as-a-Service-Produkte wie MongoDB Atlas - enthalten als Feature Auto-Sharding, Vanilla-Versionen dieser Datenbankverwaltungssysteme jedoch nicht. Aus diesem Grund erfordert Sharding oft einen eigenen Ansatz. Dies bedeutet, dass die Dokumentation zum Sharding oder Tipps zur Fehlerbehebung häufig schwer zu finden sind.

Dies sind natürlich nur einige allgemeine Punkte, die vor dem Scherben beachtet werden müssen. Je nach Anwendungsfall kann das Sharding einer Datenbank noch viel mehr Nachteile haben.

Nachdem wir uns nun mit einigen Nachteilen und Vorteilen von Sharding befasst haben, gehen wir auf einige unterschiedliche Architekturen für Sharded-Datenbanken ein.

Sobald Sie sich entschieden haben, Ihre Datenbank zu speichern, müssen Sie als Nächstes herausfinden, wie Sie dies tun werden. Beim Ausführen von Abfragen oder beim Verteilen eingehender Daten an geshardete Tabellen oder Datenbanken ist es entscheidend, dass die richtigen Shards verwendet werden. Andernfalls können Daten verloren gehen oder Abfragen schmerzhaft verlangsamt werden. In diesem Abschnitt werden einige gängige Sharding-Architekturen vorgestellt, bei denen jeweils ein geringfügig anderer Prozess zum Verteilen von Daten über Shards verwendet wird.

Ob man eine Sharded-Datenbankarchitektur implementieren soll oder nicht, ist fast immer umstritten. Einige sehen Sharding als unvermeidliches Ergebnis für Datenbanken, die eine bestimmte Größe erreichen, während andere es als Kopfschmerzen ansehen, die vermieden werden sollten, es sei denn, dies ist aufgrund der durch Sharding verursachten Komplexität unbedingt erforderlich.

Aufgrund dieser zusätzlichen Komplexität wird das Sharding normalerweise nur bei sehr großen Datenmengen durchgeführt. Im Folgenden sind einige häufige Szenarien aufgeführt, in denen das Sharden einer Datenbank von Vorteil sein kann:

Vor dem Sharding sollten Sie alle anderen Optionen zur Optimierung Ihrer Datenbank ausschöpfen. Einige Optimierungen, die Sie in Betracht ziehen könnten, umfassen:

Bedenken Sie, dass keine dieser Strategien ausreicht, wenn Ihre Anwendung oder Website über einen bestimmten Punkt hinaus wächst, um die Leistung selbst zu verbessern. In solchen Fällen ist Sharding in der Tat die beste Option für Sie.

Sharding kann eine großartige Lösung für diejenigen sein, die ihre Datenbank horizontal skalieren möchten. Dies erhöht jedoch auch die Komplexität und schafft mehr potenzielle Fehlerquellen für Ihre Anwendung. Für einige mag Sharding erforderlich sein, aber die Zeit und die Ressourcen, die zum Erstellen und Verwalten einer Sharding-Architektur benötigt werden, können die Vorteile für andere aufwiegen.

Wenn Sie diesen konzeptionellen Artikel lesen, sollten Sie die Vor- und Nachteile des Splitterns besser verstehen. In Zukunft können Sie diese Erkenntnis nutzen, um eine fundiertere Entscheidung darüber zu treffen, ob eine Sharded-Datenbankarchitektur für Ihre Anwendung geeignet ist oder nicht.