Übersicht über das Sharding von Datenbanken
- So funktioniert das Sharding von Datenbanken
- Vorteile von Sharding
- Nachteile von Sharding
- Arten von Sharding
- Alternativen zum Sharding von Datenbanken
- Wie Couchbase Capella™ beim Sharding von Datenbanken hilft
- Schlussfolgerung
Das Sharding von Datenbanken ist ein leistungsstarkes Werkzeug zur Optimierung der Leistung und Skalierbarkeit einer Datenbank. Es ermöglicht einen schnelleren Zugriff auf Daten und versetzt eine Datenbank in die Lage, größere Arbeitslasten zu bewältigen, indem Daten und Verarbeitungsleistung auf mehrere Server verteilt werden. Da NoSQL-Datenbanken mit Blick auf verteiltes Computing und automatisches Sharding entwickelt wurden, sind sie oft die Datenbanken, die am meisten mit Sharding in Verbindung gebracht werden. Mit genügend Aufwand lässt sich Sharding jedoch mit jeder Datenbanktechnologie realisieren.
Wie funktioniert das Sharding von Datenbanken?
Beim Sharding von Datenbanken wird der gesamte Datenbestand in mehrere Gruppen, so genannte Shards, aufgeteilt. Nach der Aufteilung kann jeder Shard unabhängig gespeichert werden, in der Regel auf mehreren Servern, die oft als Cluster bezeichnet werden. Auf jeden Shard kann unabhängig zugegriffen werden, was bedeutet, dass Sie schneller auf die Daten zugreifen können und Ihnen mehr Ressourcen für die Verarbeitung, die Datenverarbeitung und die Speicherung zur Verfügung stehen.
Wo findet das Sharding statt?
Wenn eine Datenbank über integrierte Sharding-Funktionen verfügt, benötigt das Entwicklungsteam weniger Arbeit, um Sharding zu realisieren. Wenn Sharding eine optionale Funktion ist oder eine Konfiguration erfordert, müssen Sie sorgfältig planen, aber Sharding sollte keine wesentlichen Änderungen oder Ergänzungen der Codebasis erfordern. Wenn die zugrundeliegende Datenbank kein Sharding unterstützt (wie es bei vielen relationalen Datenbanken der Fall ist), müssen Sie möglicherweise größere Änderungen an der Codebasis vornehmen, und die Entwickler müssen Sharding in die Persistenzschicht einer Anwendung integrieren.
Muss ich meine Daten splitten?
Ob Sie Sharding verwenden sollten oder nicht, hängt von vielen Faktoren ab. Zu diesen Faktoren gehören die Größe Ihres Datenbestands, die Anzahl der Systembenutzer, die Anzahl der durchgeführten Operationen und Ihre Infrastrukturbeschränkungen.
Wenn die Leistung Ihrer Anwendung aufgrund von mehr Benutzern oder mehr Vorgängen merklich abnimmt, ist die horizontale Skalierung (bei der häufig Sharding zum Einsatz kommt) eine Möglichkeit, die für Ihre Datenbank verfügbaren Rechenressourcen zu erhöhen. Eine schlechte Leistung kann aber auch auf suboptimalen Code, das Fehlen geeigneter Indizes, die Notwendigkeit von Änderungen an der Datenmodellierung oder andere Probleme hinweisen. Sharding sollte nicht immer die erste Wahl sein, um die Leistung zu verbessern, aber für einige Datenbanktechnologien kann es ein reibungsarmes Mittel sein, um Ihre Leistungsziele zu erreichen.
Vorteile von Sharding
- Schnellere Leistung: Es stehen mehr Server für die Verarbeitung von Ein- und Ausgaben zur Verfügung
- Horizontale Skalierung: Sie können schnell zusätzliche Server zu einem Cluster hinzufügen
- Kosten: Die horizontale Skalierung ist oft kostengünstiger als die vertikale Skalierung (d. h. die Aufrüstung eines Servers auf einen anderen, leistungsfähigeren Server).
- Verteilung/Uptime: Eine horizontal skalierte verteilte Datenbank kann eine bessere Betriebszeit erreichen als ein herkömmlicher einzelner Server
Nachteile von Sharding
- Komplexität: Je nach Datenbanksystem kann die Komplexität des Shardings variieren. Einige Datenbanken sind so konzipiert, dass Verteilung, horizontale Skalierung und Sharding bereits enthalten sind. Andere erfordern einen eher praktischen DIY-Ansatz.
- Neu ausbalancieren: Wenn Sie einem Cluster zusätzliche Rechner hinzufügen, müssen die Shards wahrscheinlich neu ausbalanciert werden, um die Daten gleichmäßig zu verteilen (wenn Sie beispielsweise 1.000 Dokumente haben, die gleichmäßig auf drei Shards verteilt sind, sind das ungefähr 333 Dokumente pro Shard). Wenn Sie einen vierten Shard hinzufügen, würde die gleichmäßige Verteilung 250 Dokumente pro Shard betragen). Wenn eine Datenbank nicht über integrierte Sharding-Funktionen verfügt, ist das Rebalancing garantiert ein komplexer manueller DIY-Prozess.
Arten von Sharding
Für das Sharding gibt es mehrere Ansätze. Einige Datenbanksysteme verfügen über integrierte Sharding-Funktionen, während andere das Sharding nicht direkt unterstützen (und eine Menge benutzerdefinierter Kodierung oder DIY-Prozesse erfordern). Das Ziel jedes Ansatzes ist es, Daten konsistent in Shards aufzuteilen, so dass Daten jedes Mal auf demselben Shard nachgeschlagen oder in diesen geschrieben werden können.
Bereichsbasiertes Sharding
Beim bereichsbasierten Sharding werden Datenwerte ausgewählt und einem Shard zugewiesen, je nachdem, ob sie in einen bestimmten Bereich fallen oder nicht. Wenn Sie beispielsweise Benutzerdaten haben, die das Alter enthalten, könnte ein Shard Benutzer im Alter von 0 bis 10 Jahren speichern, ein anderer Shard Benutzer im Alter von 11 bis 20 Jahren und so weiter.
Dieser Ansatz kann problematisch sein, weil ein Shard am Ende viel mehr Nutzer speichern könnte als der andere. Und Scherben, die eine unverhältnismäßig große Datenmenge speichern, können zu Hotspots werden, die die Leistung beeinträchtigen.
Schlüsselbasiertes Sharding
Das schlüsselbasierte Sharding verfolgt eher einen unabhängigen Ansatz. Ein Wert in den Daten (in der Regel die Dokument-ID in einer NoSQL-Dokumentendatenbank) wird durch einen Hash geleitet, und dieser Hash bestimmt, in welchem Shard die Daten gespeichert werden sollen.
Dieser Ansatz kann problematisch sein, wenn er nicht direkt von der Datenbank unterstützt wird, da jede Anwendung, die auf die Datenbank zugreift, in der Lage sein muss, den Hash zu konstruieren. Außerdem erfordert dieser Ansatz, dass der für den Hash verwendete Datenwert unveränderlich ist. Dies ist in der Regel kein Problem, kann aber in seltenen Ausnahmefällen vorkommen.
Couchbase verwendet automatisches schlüsselbasiertes Sharding um Daten gleichmäßig in einem Cluster zu verteilen, und bietet außerdem einen automatischen Ausgleich und eine automatische Replikation. Diese Automatisierungen können wichtige Prozesse vereinfachen und wertvolle Zeit für Ihr Entwicklungsteam freisetzen.
Verzeichnisbasiertes Sharding
Verzeichnisbasiertes Sharding ist ein Ansatz, bei dem ein bestimmter Wert der Daten auf der Grundlage seines Wertes in einer Nachschlagetabelle oder einer Nachschlagekonfiguration einem bestimmten Shard zugeordnet wird. Dieser Ansatz ähnelt dem Bereichskonzept, kann aber eine einfache Suche beinhalten. Ein Benutzer mit einer Adresse in Ohio würde beispielsweise im Shard “Ohio” gespeichert, ein Benutzer in Kalifornien im Shard “Kalifornien” und so weiter.
Dieser Ansatz kann problematisch sein, da eine Nachschlagetabelle oder eine Konfiguration nicht mehr verfügbar sein, ausfallen oder beschädigt werden kann. In solchen Fällen kann die Anwendung keine Lese- oder Schreibvorgänge mehr durchführen.
Geo-Sharding
Ein Geo-Shard kann mit den anderen Sharding-Optionen kombiniert oder an deren Stelle verwendet werden. Die Idee hinter der geografischen Aufteilung besteht darin, Daten physisch näher an dem Ort zu speichern, an dem am häufigsten auf sie zugegriffen wird. So würde beispielsweise ein Nutzer mit einer Adresse in Ohio auf einem Server in Ohio gespeichert, während ein Nutzer mit einer Adresse in Kalifornien auf einem Server in Kalifornien gespeichert würde.
Dieser Ansatz kann einen schnelleren Zugriff ermöglichen, aber auch zu Hotspots und nicht ausgelasteten Servern führen. Geo-Sharding kann auch nicht den gesetzlichen Anforderungen für bestimmte Anwendungen oder Gerichtsbarkeiten entsprechen.
Zusätzlich zum automatischen Sharding kann Couchbase auch Geo-Sharding unterstützen durch Rechenzentrumsübergreifende Replikation (XDCR).
Entitätsbasiertes Sharding
Entitätsbasiertes Sharding bedeutet, dass getrennte, aber eng miteinander verbundene Daten zusammen auf demselben Shard gespeichert werden. So kann beispielsweise ein Benutzer in der Logik einer Anwendung als Entität betrachtet werden, aber die Einkaufshistorie eines Benutzers kann separat in einem anderen Shard gespeichert werden. Indem Sie die zusammengehörigen Daten im selben Shard speichern, können Sie den Rechenaufwand verringern, der erforderlich ist, um sie gleichzeitig abzurufen.
Der Nachteil dieses Ansatzes ist die Komplexität. Die Konfiguration, welche Daten wohin gehören, kann ein komplexer Prozess sein, insbesondere wenn einige Daten von mehreren Stellen verwendet werden.
Alternativen zum Sharding von Datenbanken
Die horizontale Skalierung wird immer ein gewisses Maß an Sharding beinhalten, aber es gibt viele Optionen für wie zu splitten. Eine Möglichkeit ist das architektonische Sharding, z. B. eine Microservices-Architektur oder ein Sharding auf physischen Festplatten, das für den Benutzer undurchsichtig ist. Sharding kann sogar versteckt und abstrahiert werden hinter einer Cloud-Datenbank.
Wenn man ein Datenbanksystem in Erwägung zieht, ist es wichtig zu wissen, wie das Sharding erreicht werden soll. Es kann vollständig abstrahiert und verborgen sein, es kann automatisch sein, es kann mit potenziell komplexen Konfigurationsoptionen unterstützt werden, oder es kann nicht unterstützt werden und einen DIY-Ansatz erfordern.
Wie Couchbase Capella beim Sharding von Datenbanken hilft
Couchbase Capella ist die Cloud-Datenbankplattform für digitale Unternehmen.
Capella verwendet das gleiche Sharding-System wie Couchbase Server, nämlich ein schlüsselbasiertes automatisches Sharding. Aus der Sicht eines Benutzers oder Entwicklers erfordert das Sharding mit Couchbase keine zusätzliche Konfiguration oder Wartung. Durch die Verwendung eines CRC32-Algorithmus in Verbindung mit vBuckets stellt Capella sicher, dass Ihr System keine Hotspots aufweist.
Capella automatisiert die Replikation. Sie wählen einfach die gewünschte Anzahl von Replikaten aus, und Capella erledigt den Rest.
Capella automatisiert auch das Rebalancing. Wenn Sie Server hinzufügen oder aus einem Cluster entfernen, gleicht Capella diese automatisch aus, ohne Ausfallzeiten zu verursachen.
Schließlich kann Capella über die XDCR-Funktion eine geografische Aufteilung erreichen. XDCR repliziert Daten zwischen Rechenzentren in Echtzeit. XDCR-Replikationen können Daten auf der Grundlage von benutzerdefinierten Filtern ein- oder ausschließen, um die lokale Latenz zu verbessern oder die Anforderungen an den Datenstandort zu erfüllen.
Schlussfolgerung
Sharding ist ein wichtiges Konzept, das Sie verstehen müssen, wenn Sie eine Datenbank skalieren wollen, um mehr Operationen zu verarbeiten. Und NoSQL-Datenbanken sind besonders gut im Sharding, weil sie viele der Einschränkungen, die relationale Datenbanken haben, eliminieren. Dennoch bietet Couchbase Capella einige der besten Features einer relationalen Datenbank (SQL-Syntax und eine vollständige SQL-Implementierung mit JOINs und ACID-Transaktionen) zu einer verteilten Datenbank mit automatischem Sharding.
Um mehr über Sharding in Couchbase zu erfahren, lesen Sie hier:
Weitere wichtige Ressourcen für Überlegungen zur Skalierung einer Datenbank:
