Was ist Datenbank-Sharding?<\/h2>\n
Sharding ist eine Optimierungstechnik, bei der Tabellen auf andere Datenbankserver verteilt werden. Es \u00e4hnelt der Partitionierung in dem Sinne, dass beide die Daten in kleinere Teilmengen aufteilen. Der Unterschied ist, dass beim Sharding diese Teilmengen auf verschiedene Server verteilt werden, w\u00e4hrend sie beim Partitioning in einer Datenbank gespeichert werden. Diese Server verwenden dieselbe Datenbank-Engine und denselben Hardware-Typ, um ein \u00e4hnliches Leistungsniveau f\u00fcr alle Shards zu erreichen.<\/p>\n
Sharding zielt darauf ab, eine „share-nothing“-Architektur zu erreichen, die Verarbeitungsengp\u00e4sse und „single points of failure“ ausschlie\u00dft.<\/p>\n Du kannst Sharding auf zwei Arten implementieren – horizontal<\/a> und vertikal. Beim horizontalen Sharding wird die Tabelle anhand der Zeilen unterteilt, beim vertikalen Sharding anhand der Spalten.<\/p>\n In dieser Hinsicht ist das Sharding wie die Partitionierung, bei der gro\u00dfe Tabellen in kleinere unterteilt werden.<\/p>\n Horizontales Sharding eignet sich gut f\u00fcr Datenbanken, bei denen die meisten Abfragen nur eine Teilmenge von Zeilen zur\u00fcckgeben, z. B. eine Kundendatenbank, die Daten (wie Name, Adresse, E-Mail usw.) auf einmal zur\u00fcckgibt.<\/p>\n Vertikales Sharding eignet sich f\u00fcr Datenbanken, deren Abfragen einzelne Spalten zur\u00fcckgeben. Wenn die Kundendatenbank z. B. den Namen oder die E-Mail-Adresse des Kunden separat zur\u00fcckgibt, kannst du den Namen und die E-Mail-Adresse in verschiedene Cluster aufteilen.<\/p>\n Nachfolgend sind einige der Vorteile von Datenbank-Sharding aufgef\u00fchrt.<\/p>\n Du kannst deine Datenbank vertikal oder horizontal skalieren. Vertikale Skalierung bedeutet, dass du dem Server mehr zentrale Recheneinheiten (CPU) und Arbeitsspeicher (RAM) hinzuf\u00fcgst, um die Leistung zu verbessern. Vertikale Skalierung ist eine hilfreiche L\u00f6sung f\u00fcr kleine bis mittlere Datenbanken. Wenn deine Daten jedoch wachsen, ist eine vertikale Skalierung nicht mehr praktikabel. Es gibt nur so viel Leistung, wie du einem einzelnen Server hinzuf\u00fcgen kannst.<\/p>\n Die horizontale Skalierung ist flexibler. Sie erm\u00f6glicht es dir, deine Datenbank nach Bedarf zu skalieren, indem du weitere Server zu deinem System hinzuf\u00fcgst. Jeder dieser Server stellt Ressourcen f\u00fcr verschiedene Shards der Datenbank bereit. Dadurch wird die Arbeitslast verteilt und das System kann mehr Anfragen bearbeiten.<\/p>\n Shards haben nur ein paar Zeilen und Spalten. Deshalb dauert die Bearbeitung von Datenbankabfragen<\/a> weniger lang. Im Gegensatz dazu kann eine Abfrage einer nicht gesharten Datenbank die Suche in Hunderten oder sogar Tausenden von Zeilen erfordern.<\/p>\n Datenbankausf\u00e4lle k\u00f6nnen aus verschiedenen Gr\u00fcnden auftreten, z. B. durch versehentliches L\u00f6schen von Daten, Verbindungsfehler oder Cybersecurity-Angriffe. Sharding minimiert die Auswirkungen von Ausf\u00e4llen. Da jeder Shard autonom ist, ist nur der betroffene Shard von Ausfallzeiten betroffen. Wenn du zum Beispiel vier Shards hast und einer davon ausf\u00e4llt, sind nur 25 Prozent des Betriebs betroffen.<\/p>\n Obwohl Sharding die Zuverl\u00e4ssigkeit und Verf\u00fcgbarkeit einer Datenbank verbessert, ist die Implementierung komplex<\/a>. Eine falsche Sharding-Architektur kann die Leistung beeintr\u00e4chtigen und zu Datenverlusten f\u00fchren.<\/p>\n Achte darauf, eine Sharding-Technik zu w\u00e4hlen, die eine ausgewogene Verteilung der Daten auf alle Shards erm\u00f6glicht. Ohne diese Ausgewogenheit riskierst du die Entstehung von Datenbank-Hotspots, die entstehen, wenn ein Shard den Gro\u00dfteil der Daten speichert, w\u00e4hrend andere Shards praktisch leer bleiben. Dadurch verringert sich der Schreibdurchsatz auf dem einzelnen Shard.<\/p>\n Um dieses Problem zu l\u00f6sen, k\u00f6nntest du den unausgewogenen Shard noch weiter partitionieren, aber das ist ein schwieriger Prozess, der deine Datenbank w\u00e4hrend der Datenmigration lahmlegen kann.<\/p>\n Ein weiterer Nachteil des Sharding ist, dass SQL-Joins mit mehreren Tabellen in verschiedenen Shards zu langsam werden und die Leistung beeintr\u00e4chtigen k\u00f6nnen. Mit der richtigen Architektur kannst du dieses Problem jedoch vermeiden.<\/p>\n Du kannst Sharding mit drei Architekturen umsetzen:<\/p>\n Welche Architektur du w\u00e4hlst, h\u00e4ngt von deinem Anwendungsfall ab.<\/p>\n Bei einer schl\u00fcssel- oder hashed-basierten<\/a> Sharding-Architektur verwendet eine Datenbankanwendung einen Shard-Schl\u00fcssel, um einen Shard zu finden. Eine Hash-Funktion verschl\u00fcsselt den Wert des Sharding-Schl\u00fcssels, und die Ausgabe ordnet die Daten einem bestimmten Shard zu. Eine einfache Hashing-Funktion kann der Modulus des Schl\u00fcssels und die Anzahl der Shards sein.<\/p>\n Die Hash-Funktion kann mehr als einen Sharding-Schl\u00fcssel annehmen. Aus diesem Grund eignet sich das schl\u00fcsselbasierte Sharding f\u00fcr Datens\u00e4tze, die gemeinsame Schl\u00fcssel haben. Durch die algorithmische Verteilung der Daten wird die M\u00f6glichkeit minimiert, dass Datenbank-Hotspots entstehen, in denen ein Shard mehr Daten enth\u00e4lt als der andere.<\/p>\n Da die Verteilung jedoch nur auf der Hashing-Funktion beruht, ist es unm\u00f6glich, Daten logisch zusammenzufassen. Daher k\u00f6nnen Datenbankoperationen, die Daten aus mehreren Shards ben\u00f6tigen, ineffizient sein, da sie das Lesen von Daten aus jedem Shard erfordern.<\/p>\n Beim bereichsbasierten Sharding<\/a> wird eine Datenbank in Abh\u00e4ngigkeit von einem bestimmten Wertebereich gesharded.<\/p>\n Dabei wird ein Sharding-Schl\u00fcssel verwendet, um zu bestimmen, welchem Shard ein Wert zugewiesen werden soll. Die Datenbankanwendung pr\u00fcft den Shard, der dem Sharding-Schl\u00fcssel in einer Nachschlagetabelle entspricht, und speichert die Daten. Aus diesem Grund ist das bereichsbasierte Sharding einfach zu entwerfen und zu implementieren.<\/p>\n Du k\u00f6nntest zum Beispiel den Wert der Benutzer-ID in einer Benutzerdatenbank als Sharding-Schl\u00fcssel verwenden. Du k\u00f6nntest Benutzer mit IDs zwischen 0 und 2.000 in einem Shard speichern, Benutzer mit IDs zwischen 2.000 und 4.000 in einem anderen Shard, und so weiter.<\/p>\n Das bereichsbasierte Sharding kann zu Hotspots in der Datenbank f\u00fchren. Stell dir eine Benutzerdatenbank vor, in der die meisten deiner Benutzer-IDs zwischen 2.001 und 4.000 liegen. Der Prozess ordnet sie einem einzigen Shard zu, wodurch im Laufe der Zeit ein Ungleichgewicht entsteht. Das bereichsbasierte Sharding funktioniert daher am besten bei gleichm\u00e4\u00dfig verteilten Daten.<\/p>\n Beim verzeichnisbasierten Sharding<\/a> werden logisch zusammengeh\u00f6rige Daten im selben Shard zusammengefasst. Dabei wird eine Nachschlagetabelle verwendet, die eine Liste von Zuordnungen f\u00fcr jede Entit\u00e4t in der Datenbank enth\u00e4lt. Jedes Mapping entspricht einem Datenbank-Shard.<\/p>\n Das verzeichnisbasierte Sharding ist flexibler als das bereichs- oder schl\u00fcsselbasierte Sharding, weil du Daten dynamisch zu Shards hinzuf\u00fcgen kannst. Es gibt keine Sharding-Funktion, der du folgen musst, und auch keine Bereichswerte, die du einhalten musst. Diese Flexibilit\u00e4t erh\u00f6ht die Effizienz der Datenbank: Du kannst zusammenh\u00e4ngende Daten in einem Shard speichern, was bedeutet, dass die Ausf\u00fchrung gemeinsamer Abfragen weniger Zeit in Anspruch nimmt.<\/p>\n Wenn du z. B. verzeichnisbasiertes Sharding verwendest und die Benutzer\/innen nach ihrem Standort gruppierst, um die Benutzer\/innen von einem bestimmten Ort abzurufen, fragst du nur einen einzigen Shard ab.<\/p>\n Die meisten modernen Datenbank-Engines bieten Unterst\u00fctzung f\u00fcr Datenbank-Sharding. Eine dieser Datenbank-Engines ist MariaDB, eine kommerziell unterst\u00fctzte Abspaltung von MySQL. Es ist ein hochleistungsf\u00e4higes Open-Source-Datenbanksystem, das von Unternehmen wie IBM, GitHub und Wikimedia eingesetzt wird. Es ist auch Teil des Hochleistungsserver-Stacks bei Kinsta.<\/p>\n MariaDB bietet integrierte Sharding-Funktionen durch die Spider Storage Engine<\/a>. Die Spider Storage Engine ist eine Engine zur Clusterbildung, die Partitionierung und Extended Architecture (XA)-Transaktionen unterst\u00fctzt. Sie erm\u00f6glicht es dir, entfernte Tabellen aus verschiedenen Instanzen so zu behandeln, als bef\u00e4nden sie sich in derselben Instanz. Sobald du eine Tabelle in der Spider Storage Engine erstellst, wird die Tabelle mit einer anderen Tabelle auf dem entfernten MariaDB-Server verkn\u00fcpft. Sobald die Verbindung hergestellt ist, teilt die Storage Engine die Verkn\u00fcpfung mit allen Tabellen, die Teil derselben Transaktion sind.<\/p>\n Das Sharding von Datenbanken ist eine Skalierungstechnik, bei der Tabellen in kleinere Teilmengen aufgeteilt und auf verschiedene Server, die sogenannten Shards, verteilt werden. Du kannst Sharding auf verschiedene Weise implementieren, z. B. durch schl\u00fcsselbasiertes Sharding, bereichsbasiertes Sharding und verzeichnisbasiertes Sharding.<\/p>\n Sharding verbessert zwar die Skalierbarkeit, Zuverl\u00e4ssigkeit und Verf\u00fcgbarkeit einer Datenbank, ist aber sehr komplex in der Umsetzung. Au\u00dferdem ist es nach der Erstellung eines Shards nicht einfach, die Datenbank in den Zustand ohne Sharding zur\u00fcckzuversetzen. Deshalb solltest du Sharding nur dann zur Optimierung einsetzen, wenn du sicher bist, dass andere Skalierungsoptionen nicht funktionieren.<\/p>\n Ganz gleich, ob es sich bei deinem Unternehmen um eine gemeinn\u00fctzige<\/a> Organisation oder ein Gro\u00dfunternehmen<\/a> handelt, mit den Expertenl\u00f6sungen von Kinsta kannst du dich um dein Website-Hosting k\u00fcmmern und dich auf das Wesentliche konzentrieren.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" Die Erstellung einer Website ist der erste Schritt, um im Internet pr\u00e4sent zu sein. Um langfristig erfolgreich zu sein, musst du auch sicherstellen, dass deine Website …<\/p>\n","protected":false},"author":117,"featured_media":55939,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_kinsta_gated_content":false,"_kinsta_gated_content_redirect":"","footnotes":""},"tags":[],"topic":[983],"class_list":["post-55938","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","topic-technische-tipps"],"yoast_head":"\n![\"Eine](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/11\/database-sharding-example.png\")
Vorteile von Datenbank-Sharding<\/h2>\n
Verbesserte horizontale Skalierung<\/h3>\n
Schnellere Abfrage-Antwortzeiten<\/h3>\n
Erh\u00f6hte Verl\u00e4sslichkeit bei Ausf\u00e4llen<\/h3>\n
Nachteile von Sharding<\/h2>\n
Sharding-Architekturen<\/h2>\n
\n
Schl\u00fcsselbasiertes Sharding<\/h3>\n
Bereichsbasiertes Sharding<\/h3>\n
Verzeichnisbasiertes Sharding<\/h3>\n
Datenbank-Sharding mit Kinsta<\/h2>\n
Zusammenfassung<\/h2>\n