Bei dieser Methode wird eine mathematische Formel (eine Hash-Funktion) auf den Shard-Schlüssel angewendet, um Daten zuzuweisen. Das System kann beispielsweise die Nutzer-ID (mod 4) berechnen, um einen Nutzer einem von vier Servern zuzuweisen.

Hash-Funktionen sorgen zwar für eine konsistente Verteilung der Daten, aber nur dann, wenn der Shard-Schlüssel eine hohe Kardinalität und eine geringe Häufigkeitsschiefe aufweist. Wenn Sie einen Shard-Schlüssel mit einem häufigen Wert auswählen, z. B. „Nachname“, wobei „Smith“ 1.000-mal häufiger vorkommt als „Pyne“, sendet die Hash-Funktion jeden „Smith“-Datensatz an denselben Shard. So entsteht trotz der Verwendung einer mathematischen Formel ein „Hot Shard“.

Auch das Hinzufügen neuer Server ist mit dieser Methode schwierig, da sich die Formel ändert. Oft müssen Sie Ihre Daten neu aufteilen oder in den neuen Servercluster verschieben.

Daten werden anhand von Wertebereichen zugewiesen. Sie könnten beispielsweise die Nutzer-IDs 1–1.000 auf Server A und 1.001–2.000 auf Server B platzieren. Das ist sehr intuitiv und eignet sich hervorragend für Abfragen, bei denen eine Datenfolge gelesen werden muss (Bereichsabfragen). Der Nachteil sind „Hotspots“: Wenn alle neuen Nutzer Server B zugewiesen werden, erledigt dieser Server die ganze Arbeit, während Server A untätig ist.

Bei dieser Strategie wird eine Lookup-Tabelle (ein Verzeichnis) verwendet, in der genau festgehalten wird, welcher Shard welche Daten enthält. Diese Option bietet die größte Flexibilität, da Sie Daten zwischen Shards verschieben können, ohne eine Formel zu ändern. Diese Nachschlagetabelle wird jedoch zum Engpass, da jede Abfrage zuerst das Verzeichnis prüfen muss, was die Latenz erhöht. Wenn das Verzeichnis ausfällt, ist die gesamte Datenbank nicht mehr zugänglich.

Beim Geo-Sharding werden Daten bestimmten Servern zugewiesen, basierend auf dem physischen Standort des Nutzers. So werden beispielsweise Daten von Nutzern in Frankreich auf Servern in der EU gespeichert, während für Nutzer in den USA Server in Nordamerika verwendet werden. Dadurch wird die Latenz (Geschwindigkeit) für Nutzer deutlich reduziert und Unternehmen können Gesetze zur Datenresidenz wie die DSGVO einhalten.

Bei dieser Methode, die auch als funktionale Partitionierung bezeichnet wird, werden Daten nach Merkmalen und nicht nach Zeilen aufgeteilt. Sie könnten zum Beispiel alle Tabellen mit Nutzerprofilen auf Server A und alle Tabellen mit hochgeladenen Fotos auf Server B platzieren. Das organisiert die Daten zwar logisch, ist aber funktional ähnlich wie eine Microservices-Datenarchitektur und löst das Problem nicht, wenn ein bestimmtes Feature (wie Fotos) zu groß für einen einzelnen Server wird.

Fragmentierung ist eine spezielle Art der horizontalen Partitionierung, bei der die Datenstücke auf völlig unterschiedliche Server verteilt werden. So werden sowohl die Hardwarekapazitätsgrenzen (Speicher) als auch die Engpässe beim Schreibdurchsatz gelöst, da verschiedene Server Schreibvorgänge gleichzeitig verarbeiten können.

• Manuelle Fragmentierung: Bei der manuellen Fragmentierung ist der Entwickler oder Datenbankadministrator für die Definition der Shard-Schlüssel, die Erstellung der Infrastruktur für jeden Shard und das Schreiben der Logik für das Routing von Abfragen verantwortlich. So haben Sie die detaillierte Kontrolle darüber, wo sich die Daten befinden. Allerdings ist ein erheblicher Wartungsaufwand erforderlich. Wenn ein Shard zu groß wird, müssen Sie die Daten manuell neu aufteilen. Dabei werden Millionen von Zeilen auf neue Server verschoben, während die Ausfallzeit der Anwendung möglichst gering gehalten werden soll.
• Automatisches Sharding: Das automatische Sharding, das häufig in NoSQL-Datenbanken wie Bigtable oder verteilten SQL-Datenbanken wie Spanner zu finden ist, übernimmt die Verteilung von Daten und Traffic automatisch. Das System überwacht die Datengröße und die Last auf jedem Server. Wenn ein bestimmter Shard zu einem „Hotspot“ wird oder zu groß wird, teilt die Datenbank-Engine den Shard automatisch auf und verschiebt Daten auf einen weniger ausgelasteten Server. Das entlastet Ihr Team und sorgt für eine gleichbleibende Leistung, wenn Ihre Anwendung skaliert wird.

Beim Partitionieren wird eine große Tabelle in kleinere, besser verwaltbare Teile aufgeteilt (z. B. eine Protokolltabelle nach Monaten), die aber auf derselben Serverinstanz verbleiben. So lassen sich Speicherprobleme lösen, da alte Daten einfacher archiviert oder gelöscht werden können, ohne dass der Rest der Tabelle beeinträchtigt wird. Serverprobleme werden dadurch jedoch nicht gelöst. Da sich alle Partitionen weiterhin auf einem einzelnen Computer befinden, teilen sie sich weiterhin dieselbe CPU und denselben RAM. Das bedeutet, dass die Partitionierung nicht hilft, wenn der Server an seine Leistungsgrenzen stößt.

Bei der Replikation wird die gesamte Datenbank auf mehrere Server kopiert. Dies kann eine gute Wahl für die Leseverfügbarkeit sein. Wenn ein Server ausfällt, kann ein anderer übernehmen. Allerdings hilft sie nicht bei der Schreibskalierung, da jedes geschriebene Datenelement in jedes Replikat kopiert werden muss, wodurch die Schreibgeschwindigkeit auf die Kapazität einer einzelnen Maschine beschränkt wird.

Ebenso wichtig ist, dass die meisten Replikationsmodelle nur einen „Writer“ (den primären Knoten) gleichzeitig zulassen. Wenn Sie versuchen, mehreren Servern gleichzeitig das Akzeptieren von Schreibvorgängen zu erlauben, riskieren Sie Schreibkonflikte, bei denen zwei Server versuchen, denselben Datensatz mit unterschiedlichen Informationen zu aktualisieren. Diese Konflikte zu lösen ist technisch schwierig und kann zu Datenverlust oder Inkonsistenzen führen, wenn sie nicht von einem ausgeklügelten verteilten System gehandhabt werden.

Eine verteilte Datenbank wie Cloud Spanner bietet die Vorteile von Sharding ohne den manuellen Aufwand. Diese Systeme sind von Anfang an für einen Cluster von Maschinen ausgelegt. Sie kümmern sich automatisch und transparent um die Datenverteilung, das Rebalancing und die Replikation. Einige dieser Systeme nutzen mehrere Schreibvorgänge und verarbeiten Schreibkonflikte automatisch. So können Sie horizontal skalieren und gleichzeitig die Konsistenz einer herkömmlichen relationalen Datenbank beibehalten.