Dieser Artikel erschien zuerst in InfoWorld . Es wird mit Genehmigung nachgedruckt. © IDG Communications, Inc., 2020. Alle Rechte vorbehalten. Wie MariaDB mit Xpand globale Reichweite erreicht. Xpand ist jetzt in MariaDB SkySQL verfügbar und fügt verteiltes SQL für Skalierbarkeit und Elastizität in der Cloud hinzu.
Da die Informations- und Verarbeitungsanforderungen gewachsen sind, haben Problempunkte wie Leistung und Belastbarkeit neue Lösungen erforderlich gemacht. Datenbanken müssen ACID-Compliance und -Konsistenz aufrechterhalten, hohe Verfügbarkeit und hohe Leistung bieten und massive Workloads bewältigen, ohne Ressourcen zu belasten. Sharding hat eine Lösung angeboten, aber für viele Unternehmen stößt Sharding aufgrund seiner Komplexität und seines Ressourcenbedarfs an seine Grenzen. Eine bessere Lösung ist verteiltes SQL.
Bei einer verteilten SQL-Implementierung wird die Datenbank auf mehrere physische Systeme verteilt, wodurch Transaktionen auf einer global skalierbaren Ebene bereitgestellt werden. MariaDB Platform X5, eine Hauptversion, die Upgrades für jeden Aspekt von MariaDB Platform enthält, bietet verteiltes SQL und massive Skalierbarkeit durch das Hinzufügen einer neuen intelligenten Speicher-Engine namens Xpand. Mit einer Shared-Nothing-Architektur, vollständig verteilten ACID-Transaktionen und starker Konsistenz ermöglicht Ihnen Xpand die Skalierung auf Millionen von Transaktionen pro Sekunde.
Optimierte Pluggable Smart Engines
MariaDB Enterprise Server ist so konzipiert, dass es Plug-in-Storage-Engines (wie Xpand) verwendet, um bestimmte Workloads von einer einzigen Plattform aus zu optimieren. Es sind keine spezialisierten Datenbanken erforderlich, um bestimmte Workloads zu bewältigen. MariaDB Xpand, unsere intelligente Engine für verteiltes SQL, ist die neueste Ergänzung unserer Produktpalette. Xpand erweitert die Optionen unserer anderen Engines um massiv skalierbare verteilte Transaktionsfunktionen. Unsere anderen Plug-in-Engines bieten eine Optimierung für analytische (spaltenweise), leseintensive und schreibintensive Workloads. Sie können replizierte, verteilte und spaltenorientierte Tabellen mischen und abgleichen, um jede Datenbank für Ihre spezifischen Anforderungen zu optimieren.
Das Hinzufügen von MariaDB Xpand ermöglicht es Unternehmenskunden, alle Vorteile von verteiltem SQL – Geschwindigkeit, Verfügbarkeit und Skalierbarkeit – zu nutzen und gleichzeitig die gewohnten Vorteile von MariaDB beizubehalten.
Werfen wir einen allgemeinen Blick darauf, wie MariaDB Xpand verteiltes SQL bereitstellt.
Verteiltes SQL bis zu den Indizes
Xpand bietet verteiltes SQL durch Aufteilen, Replizieren und Verteilen von Daten über Knoten hinweg. Was bedeutet das? Wir verwenden ein sehr einfaches Beispiel mit einer Tabelle und drei Knoten, um die Konzepte zu demonstrieren. In diesem Beispiel wird nicht gezeigt, dass alle Slices repliziert werden.
In Abbildung 1 oben haben wir eine Tabelle mit zwei Indizes. Die Tabelle enthält einige Daten, und wir haben einen Index in Spalte zwei und einen weiteren in Spalte drei und eins. Indizes sind gewissermaßen selbst Tabellen. Sie sind Teilmengen der Tabelle. Der Primärschlüssel ist id , der erste Index in der Tabelle. Das wird verwendet, um die Tabellendaten zu hashen und in der Datenbank zu verteilen.
Jetzt fügen wir den Begriff Slices hinzu . Slices sind im Wesentlichen horizontale Partitionen der Tabelle. Wir haben fünf Zeilen in unserer Tabelle. In Abbildung 2 wurde die Tabelle aufgeteilt und verteilt. Knoten Nr. 1 hat zwei Zeilen. Knoten Nr. 2 hat zwei Zeilen und Knoten Nr. 3 hat eine Zeile. Ziel ist es, die Daten so gleichmäßig wie möglich über die Knoten zu verteilen.
Die Indizes wurden auch geschnitten und verteilt. Dies ist ein wesentlicher Unterschied zwischen Xpand und anderen verteilten Lösungen. Typischerweise haben verteilte Datenbanken lokale Indizes, sodass jeder Knoten einen Index seiner eigenen Daten hat. In Xpand werden Indizes unabhängig von der Tabelle verteilt und gespeichert. Dadurch entfällt die Notwendigkeit, eine Anfrage an alle Knoten zu senden (scatter/gather). Im obigen Beispiel enthält Knoten Nr. 1 die Zeilen 2 und 4 der Tabelle sowie Indizes für die Zeilen 32 und 35 und die Zeilen April und März. Die Tabelle und die Indizes werden unabhängig auf die Knoten aufgeteilt, verteilt und repliziert.
Die Abfrage-Engine verwendet die verteilten Indizes, um zu bestimmen, wo die Daten zu finden sind. Es sucht nur nach den erforderlichen Indexpartitionen und sendet dann Abfragen nur an die Speicherorte, an denen sich die erforderlichen Daten befinden. Abfragen werden alle verteilt. Sie werden gleichzeitig und parallel durchgeführt. Wohin sie gehen, hängt ganz von den Daten ab und davon, was zur Lösung der Abfrage erforderlich ist.
Alle Slices werden mindestens zweimal repliziert. Für jeden Slice gibt es Replikate, die sich auf anderen Knoten befinden. Standardmäßig gibt es drei Kopien dieser Daten – das Slice und zwei Replikate. Jede Kopie befindet sich auf einem anderen Knoten, und wenn Sie in mehreren Verfügbarkeitszonen ausgeführt würden, würden sich diese Kopien auch in verschiedenen Verfügbarkeitszonen befinden.
Lese- und Schreibbehandlung
Nehmen wir ein anderes Beispiel. In Abbildung 3 haben wir fünf Instanzen von MariaDB Enterprise Server mit Xpand (Knoten). Es gibt eine Tabelle zum Speichern von Kundenprofilen. Das Slice mit Shanes Profil befindet sich auf Knoten Nr. 1 mit Kopien auf Knoten Nr. 3 und Knoten Nr. 5. Abfragen können auf jedem Knoten eingehen und werden unterschiedlich verarbeitet, je nachdem, ob es sich um Lese- oder Schreibvorgänge handelt.
Schreibvorgänge werden innerhalb einer verteilten Transaktion synchron auf alle Kopien vorgenommen. Jedes Mal, wenn ich mein „Shane“-Profil aktualisiere, weil ich meine E-Mail-Adresse oder meine Adresse geändert habe, gehen diese Schreibvorgänge innerhalb einer Transaktion gleichzeitig an alle Kopien. Dies sorgt für starke Konsistenz.
In Abbildung 3 ging die UPDATE-Anweisung an Knoten Nr. 2. Es gibt nichts auf Knoten Nr. 2 bezüglich meines Profils, aber Knoten Nr. 2 weiß, wo sich mein Profil befindet, und sendet Aktualisierungen an Knoten Nr. 1, Knoten Nr. 3 und Knoten Nr. 5, führt dann diese Transaktion durch und kehrt zur Anwendung zurück.
Lesevorgänge werden unterschiedlich gehandhabt. Im Diagramm befindet sich das Slice mit meinem Profil auf Knoten Nr. 1 mit Kopien auf Knoten Nr. 3 und Knoten Nr. 5. Dies macht Knoten Nr. 1 zum Ranking-Replikat. Jeder Slice hat eine Ranking-Replik, die man als den Knoten bezeichnen könnte, der die Daten „besitzt“. Standardmäßig geht ein Lesevorgang unabhängig davon, auf welchem Knoten er eingeht, immer an das Ranking-Replikat, sodass jedes SELECT, das zu mir aufgelöst wird, an Knoten Nr. 1 geht.
Elastizität verleihen
Verteilte Datenbanken wie Xpand ändern sich ständig und entwickeln sich abhängig von den Daten in der Anwendung weiter. Der Rebalancer-Prozess ist dafür verantwortlich, die Datenverteilung an die aktuellen Anforderungen anzupassen und die optimale Verteilung der Slices über die Knoten hinweg aufrechtzuerhalten. Es gibt drei allgemeine Szenarien, die eine Umverteilung erfordern:Hinzufügen von Knoten, Entfernen von Knoten und Verhindern ungleichmäßiger Arbeitslasten oder „Hotspots“.
Angenommen, wir arbeiten mit drei Knoten, stellen jedoch fest, dass der Datenverkehr zunimmt und wir skalieren müssen – wir fügen einen vierten Knoten hinzu, um den Datenverkehr zu bewältigen. Knoten Nr. 4 ist leer, wenn wir ihn hinzufügen, wie in Abbildung 4 gezeigt. Der Rebalancer verschiebt automatisch Slices und Replikate, um Knoten Nr. 4 zu verwenden, wie in Abbildung 5 gezeigt.
Sollte Node #4 ausfallen, geht der Rebalancer automatisch wieder an die Arbeit; Diesmal werden Scheiben von ihren Repliken neu erstellt. Es gehen keine Daten verloren. Replikate werden auch neu erstellt, um diejenigen zu ersetzen, die sich auf Knoten Nr. 4 befanden, sodass alle Slices wieder Replikate auf anderen Knoten haben, um eine hohe Verfügbarkeit sicherzustellen.
Abbildung 6. Wenn ein Knoten ausfällt, erstellt der Xpand-Rebalancer die Slices und die Replikate, die sich auf dem ausgefallenen Knoten befanden, aus den Replikatdaten auf den anderen Knoten neu.
Die Arbeitsbelastung ausgleichen
Zusätzlich zu Scale-out und Hochverfügbarkeit mildert der Rebalancer eine ungleiche Workload-Verteilung – entweder Hotspots oder Unterauslastung. Selbst wenn Daten mit einem perfekten Hash-Algorithmus zufällig verteilt werden, können Hotspots auftreten. Es könnte zum Beispiel passieren, dass die 10 Produkte, die diesen Monat zum Verkauf angeboten werden, zufällig auf Node #1 sitzen. Die Daten sind gleichmäßig verteilt, die Arbeitslast jedoch nicht (Abbildung 7). In diesem Szenario verteilt der Rebalancer Slices neu, um die Ressourcennutzung auszugleichen (Abbildung 8).
Abbildung 7. Xpand hat die Daten gleichmäßig verteilt, aber die Arbeitslast ist ungleichmäßig. Knoten 1 hat eine deutlich höhere Arbeitslast als die anderen drei Knoten.
Abbildung 8. Der Xpand-Rebalancer verteilt Datenscheiben neu, um die Arbeitslast zwischen den Knoten auszugleichen.
Skalierbarkeit, Geschwindigkeit, Verfügbarkeit, Ausgewogenheit
Der Informations- und Verarbeitungsbedarf wird weiter wachsen. Das ist eine gegebene. MariaDB Xpand bietet eine konsistente, ACID-konforme Skalierungslösung für Unternehmen mit Anforderungen, die mit anderen Alternativen wie Replikation und Sharding nicht erfüllt werden können.
Verteiltes SQL bietet Skalierbarkeit, und MariaDB Xpand bietet die Flexibilität, zu wählen, wie viel Skalierbarkeit Sie benötigen. Verteilen Sie eine Tabelle oder mehrere Tabellen oder sogar Ihre gesamte Datenbank, Sie haben die Wahl. Im Betrieb lässt sich die Kapazität leicht anpassen, um sich jederzeit ändernden Workload-Anforderungen gerecht zu werden. Sie müssen nie zu viel bereitgestellt werden.
Xpand schützt auch transparent vor ungleichmäßiger Ressourcennutzung, indem Daten dynamisch neu verteilt werden, um die Arbeitslast auf Knoten auszugleichen und Hotspots zu vermeiden. Entwickler müssen sich keine Gedanken über Skalierbarkeit und Leistung machen. Xpand ist elastisch. Xpand bietet außerdem Redundanz und Hochverfügbarkeit. Da Daten aufgeteilt, repliziert und über Knoten verteilt werden, sind die Daten geschützt und die Redundanz wird im Falle eines Hardwareausfalls aufrechterhalten.
Und mit der Architektur von MariaDB werden Ihre verteilten Tabellen – einschließlich Engine-übergreifender JOINs – gut mit Ihren anderen MariaDB-Tabellen zusammenspielen. Erstellen Sie die Datenbanklösung, die Sie benötigen, indem Sie replizierte, verteilte oder spaltenorientierte Tabellen in einer einzigen Datenbank auf MariaDB Platform mischen und abgleichen.
