Thought Leadership
Wenn Unternehmen mit Daten arbeiten, brauchen sie auch eine Möglichkeit, sie zu speichern, zu verwalten und, wenn sie diese nutzen wollen, sie zu visualisieren. Das bedeutet fast immer, dass Data Warehouses, Data Lakes und BI-Tools zum Einsatz der Datenspeicherung kommen. Es scheint noch gar nicht so lange her zu sein, dass Unternehmen ihre Daten noch in einfachen Papierakten gespeichert haben.Im Laufe der Zeit wurden diese Dateien auf Disketten migriert, die dann zu Festplatten in lokalen IT-Umgebungen wurden, und jetzt bewegt sich alles erneut – dieses Mal in die Cloud.
In diesem Zusammenhang tauchen immer wieder die Begriffe Replikation und Sharding auf. Stefan Käser, Solution Architect bei Berliner Data-Spezialisten DoubleCloud, erläutert die Begriffe und deren Bedeutung für eine moderne Speicherumgebung:
„Die Art und Weise, wie Daten gespeichert werden, musste sich schon immer weiterentwickeln, um mit der aktuellen Technologie Schritt zu halten. Die jüngste rasante Entwicklung bei der Datenspeicherung ist jedoch einzig und allein auf die schiere Menge an Daten zurückzuführen, auf die Unternehmen jetzt Zugriff haben. Datenspeicherlösungen mussten effizienter und fortschrittlicher werden, um das Volumen bewältigen zu können.
Ein Beispiel ist, wie Kunden mit Unternehmen interagieren – per mobiler App, über den Desktop-PC, Browser, mit dem Verkaufsteam, mit dem Kundendienst, und das ist nur ein normales Einzelhandelsgeschäft. Andere Branchen haben noch größere Datenmengen und Datenknoten zu speichern, zu verarbeiten, zu verwalten, zu analysieren und zu visualisieren.
Diese Datenmengen sind zwar unendlich nützlich für ein Unternehmen, stellen aber eine enorme Belastung für Datenbank-Cluster dar. Diese müssen immer größere Datenmengen verarbeiten, die Datenmenge wächst exponentiell und die Daten werden dabei immer häufiger in Anspruch genommen. Wie sollen Unternehmen so viele Daten verarbeiten, wenn sie auf ein Cluster treffen, und dennoch verwertbare Geschäftsinformationen daraus ableiten? Hier kommen Replikation und Sharding ins Spiel, insbesondere Sharding.
Was ist Replikation?
In Bezug auf Data Warehousing und Datenbankmanagement bezieht sich die Replikation auf eine Art von Datenbanklösung, bei der Kopien derselben Datenbank auf mehreren, unterschiedlichen Rechnern gehostet werden. Der wichtigste Grund für die Replikation ist die Schaffung zusätzlicher Redundanz. Wenn einer der Rechner, auf dem eine Datenbank gehostet wird, ausfällt, ist die Wiederherstellung exponentiell schneller, da einer der anderen Rechner, auf dem die Datenbank repliziert ist, einspringen kann, um die Last zu übernehmen. Dieser Replikationsprozess minimiert nicht nur die Ausfallzeit, sondern auch den Datenverlust, da immer eine Kopie der aktiven Datenbank vorhanden ist.
Hauptmerkmale der Replikation
Replikationssätze sind Cluster aus verschiedenen Knoten, die alle genau dieselben Kopien des Datensatzes mit verschiedenen Arten von Setups wie Master-Slave oder Master-Master verwalten können. Optimal ist es, wenn jedes Replikat in der Lage ist, Aktualisierungen zu empfangen, wobei die anderen Replikate dann synchronisiert werden. Alle Änderungen an den Daten werden kopiert und in einem asynchronen Prozess auf die sekundären Maschinen übertragen. Das bedeutet, dass alle Sekundärknoten mit dem Primärknoten verbunden sind. Sollte der primäre Server ausfallen, wird einer der sekundären Knoten automatisch zum neuen primären Knoten „befördert“.
Warum eine Datenbank replizieren?
Durch die Replizierung einer Datenbank wird die Datenmenge maximiert, die im Falle eines unvorhergesehenen Ereignisses wiederhergestellt werden kann, und in einigen Fällen wird der Datenverlust auf null begrenzt. Es bedeutet, dass keine Ausfallzeiten für die Wartung erforderlich sind, da immer eine andere Version der Daten zur Verfügung steht, während die Wartungsarbeiten durchgeführt werden. Der andere große Vorteil ist die massive Verbesserung der Leseskalierung, da immer zusätzliche Kopien der Daten zur Verfügung stehen, von denen gelesen werden kann. Kurz gesagt, es bietet hohe Datenredundanz und hohe Verfügbarkeit. Datenbanken werden durch das Vorhalten mehrerer Kopien (oder Replikate) auf isolierten Servern wesentlich langlebiger. Und das ist Replikation in Kurzform.
Was ist Sharding?
Sharding ist ein wenig komplizierter als Replizieren. Sobald die Datenmenge eines Unternehmens eine bestimmte Größe erreicht, wird die Skalierung zu einem großen Leistungsproblem. Eine große Anzahl von Benutzern, die alle auf dieselbe Datenbank zugreifen, kann wirklich Probleme verursachen. Sharding ist eine Lösung, die darauf abzielt, dem entgegenzuwirken, indem die Datenbank in separate Shards aufgeteilt wird, die auf mehrere Rechner verteilt sind. Im Wesentlichen handelt es sich um einen Lastausgleich durch Aufteilung der Datenbank auf verschiedene Datenbankserver.
Im Gegensatz zur Replikation, bei der die gesamte Datenbank repliziert wird, wird beim Sharding nur ein Teil davon repliziert, wobei die Daten auf Anfrage eines Benutzers von den verschiedenen Servern abgerufen werden. Die Kehrseite der Medaille ist jedoch, dass der Leistungsgewinn einen Preis hat. Wann immer Benutzer Daten von mehreren Shards gleichzeitig benötigen, müssen sie diese neu kombinieren, entweder innerhalb des aufrufenden Servers oder in ihrer Anwendung.
Warum ist das Sharding einer Datenbank sinnvoll?
Große, herkömmliche Datenbanken mit riesigen Datensätzen oder vielen Nutzern, die darauf zugreifen – oder beides, erweisen sich oft als problematisch für einen einzelnen Server, da sie dessen CPU-Limit herausfordern. Sharding entlastet diesen Druck, indem die Last auf mehrere Server verteilt wird, ohne dass die gesamte Datenbank repliziert werden muss. Das heißt, statt eines Servers, der als primärer Server fungiert – wie im Falle der Replikation, haben wir nun mehrere Sharding-Server, von denen jeder nur einen Teil der Daten vorhält.
Ein Konfigurationsserver hält die Metadaten vor, was wo sein soll, und konfiguriert einen Routing-Server, um Daten in einen bestimmten Shard zu integrieren. Sharding bedeutet, dass die Server die Last je nach Bedarf automatisch auf die verschiedenen Server verteilen können, während die Gesamtzahl der Operationen, die jeder einzelne Shard zu bewältigen hat, massiv reduziert wird. Durch die Aufteilung Ihrer Daten auf mehrere Instanzen wird auch die Schreibkapazität massiv erhöht.
Was ist der Unterschied zwischen Replikation und Sharding?
Man stelle sich Replikation und Sharding wie eine virtuelle Torte vor. Bei der Replikation werden aus dem ursprünglichen Kuchen zwei Kuchen, was aber zusätzlichen Speicherplatz erfordert, um beide zu speichern. Es steht also ein „Ersatzkuchen“ bereit, falls etwas schiefgehen sollte, was aber auch doppelte Speicherkosten bedeutet. Stattdessen ließe sich der Kuchen in vier, acht oder zwölf Stücke zerteilen, wobei jedes Stück an einem anderen Ort gelagert wird. Es gibt also immer noch einen ganzen Kuchen, aber man muss an verschiedene Orte gehen, um jedes Stück zu bekommen. Das ist Sharding – oder horizontale Skalierung.
Hier beginnt es kompliziert zu werden. Sowohl Replikation als auch Sharding sind nur ein Teil der Lösung. Ein echter Modern Data Stack sollte beides in einem Sharding-Cluster nutzen, in dem jeder Shard repliziert wird, um die Integrität der Daten zu wahren und Speicherkosten zu sparen.
Replikation und Sharding sind also eine Möglichkeit, Datenbanken und vernetzten Anwendungen zu verwalten und Kosten zu senken. Wenn sich das kompliziert anhört, liegt das daran, dass es leider auch so sein kann, um es richtig zu optimieren. Es gibt immer noch die alte Lösung, die Anzahl der Datenbanken zu erhöhen. Wenn dies zu teuer erscheint, ist es vielleicht an der Zeit, einen Managed Service in Betracht zu ziehen.“
