Geschwindigkeit aufnehmen mit Vitess (MySQL Sharding)

Im Artikel „Sharding – Das Fruit Ninja der Datenbanken" wurde das Thema Sharding und dessen Nutzen generell vorgestellt. Jetzt soll das Sharding von MySQL-Datenbanken genauer unter die Lupe genommen werden. Dabei wird explizit die Sharding-Lösung Vitess betrachtet. Es soll vor allem die Frage beantwortet werden, wie die horizontale Partitionierung innerhalb eines Vitess-Clusters funktioniert.

YouTube als Startpunkt - die Geschichte von Vitess 

Die Geschichte von Vitess beginnt bei YouTube, wo die Datenbank für Meta-Informationen der Videos aus allen Nähten platzte. Dort wurde bis 2010 mit der MySQL-Replikation gearbeitet, bei der die Schreibprozesse auf einen Master-Knoten koordiniert und die Lesevorgänge auf mehrere Replika Nodes verteilt wurden ("Read-Scale-Out"). Die Schreiblast wurde so groß, dass sie nicht mehr von einer Master-Datenbank bewältigt werden konnte.

Außerdem stieg die Datenmenge der Datenbank exponentiell an. Abhängig von der verwendeten InnoDB Page Size, also der festgelegten Blockgröße, ist die maximale Größe einer Tabelle innerhalb dieser Engine ohnehin auf 16 TB bis 256 TB beschränkt. YouTube betrachtete hier also Daten im Big- Data-Bereich. Als Lösung für das Problem entstand das Clustering System Vitess zum Sharding von MySQL-Datenbanken.

Architektur 

Um ein Verständnis für das Sharding mit Vitess zu schaffen, ist ein kurzer Überblick über die einzelnen Komponenten notwendig. Es werden hier nur die wichtigsten Komponenten vorgestellt.

Diese genügen, um eine grobe Vorstellung vom Aufbau eines Vitess-Clusters zu erhalten.

VTTablet oder auch kurz Tablet

Ein VTTablet (oder auch kurz: Tablet) ist eine Referenz auf eine bestehende MySQL-Instanz. Im Vitess-Cluster ist es ein Prozess, der mit der entsprechenden MySQL-Datenbank verbunden ist und dort weitreichende Zugriffsmöglichkeiten hat. Ein Tablet, also die Referenz zu einer MySQL-Instanz, kann wiederum repliziert werden. Ein Shard kann in diesem Fall aus einem oder mehreren replizierten Tablets bestehen und stellt somit eine Teilmenge der Datenbank dar.

VTGate das Eingangstor

Er ist das Eingangstor des Vitess-Clusters und entspricht einem leichtgewichtigen Proxy. Vom VTGate aus werden alle SQL-Abfragen und SQL-Befehle an die unterliegenden VTTablets weitergeleitet. Der VTGate entscheidet also, an welchen MySQL-Server die Abfragen gesendet werden.

Tropology Service - Kommunikation ist alles

Damit der VTGate weiß, an welche Tablets er die SQL-Befehle routen soll, kommuniziert er mit dem Topology Service. Dieser stellt die Konfiguration der unterschiedlichen Komponenten des Vitess-Clusters bereit, um weitere MySQL-Instanzen in die Umgebung einzubinden oder entfernen zu können.

Funktionsweise des Shardings 

In Vitess entspricht ein Datenbankschema einem Keyspace, also einer Zusammenstellung von einem oder mehreren VTTablets und deren unterliegenden MySQL-Instanzen. Besteht ein Keyspace nur aus einem Shard (initialer Shard 0), betrachtet man diese Datenbank auch als "Unsharded Keyspace". In diesem Fall ist dem Keyspace nur eine MySQL-Primary-Instanz und eventuell mehreren MySQL-Replika-Knoten zugeordnet (aus Gründen der Verfügbarkeit). Die Daten sind nicht auf weiteren Servern verteilt.

Beim Sharding wird ein Keyspace als Sharded Keyspace bezeichnet, wenn ihm mehrere Tablets zugeordnet sind und die Datensätze auf diese horizontal aufgeteilt werden. Die VTTablets werden nun zusätzlich mit einer Shard-Kennung markiert. Bei der Aufnahme von zwei Shards sind dies die Kennungen:

• -80
• 80-

Die Kennung "-80" steht für einem Wertebereich von 0x00 bis 0x80. Kennung "80-" betrachtet einen Bereich von 0x80 bis 0xFF. Die Shards werden also mit Hexadezimalzahlen charakterisiert. Der Wertebereich gibt Auskunft darüber, welche Datensätze ein Shard aufnehmen darf.

In Vitess verfügt jede "geshardete" Tabelle über einen Vindex. Dieser entspricht im Wesentlichen dem Sharding-Key, nach welchem die Daten auf die verschiedenen MySQL-Server verteilt werden. Jeder Vindex-Wert wird auf einer Keyspace-ID abgebildet. Dies geschieht mittels einer Hash-Funktion. Die Keyspace-ID ist vom Datentyp Unsigned Integer 64-Bit und liegt daher immer im Wertebereich von 0x00 bis 0xFF.

Auf Shard -80 landen alle Datensätze dessen Keyspace-ID:

• < 0x8000000000000000

Auf Shard 80- landen alle Datensätze dessen Keyspace-ID:

• >= 0x8000000000000000
• <= 0xFFFFFFFFFFFFFFFF

Abhängig von der verwendeten Hash-Funktion, ergibt sich dadurch eine gleichmäßige Verteilung der Datensätze auf die verschiedenen Shards.

Fazit 

Mit der Sharding-Lösung Vitess lässt sich eine horizontale Partitionierung der Daten einer bestehenden MySQL-Datenbank durchführen. Die Sinnhaftigkeit für den Einsatz von Vitess hängt sehr stark von den Daten und dem Datenmodell der Datenbank selbst ab. Der administrative Aufwand zur Umsetzung eines Vitess-Clusters ist, aufgrund der vielen Komponenten, nicht zu unterschätzen. Je größer die Datenmenge, desto eher handelt es sich beim Sharding um eine Option, die hilft, das bestehende System in eine zukunftssichere Umgebung umzuwandeln.

Seminarempfehlung