Datenbank: Github partitioniert zentralen MySQL-Cluster für halbe Last
"Vor mehr als 10 Jahren begann Github.com wie viele andere Webanwendungen dieser Zeit - basierend auf Ruby on Rails - mit einer einzigen MySQL-Datenbank zum Speichern der meisten Daten" , heißt es in einem aktuellen Blogbeitrag des Engineering-Teams von Github(öffnet im neuen Fenster) . Die zentrale MySQL-Datenbank sorgte dabei mit dem folgenden Wachstum des Code-Hosting-Dienstes jedoch für immer mehr Probleme, so dass sich das Team dazu entschied, den Aufbau grundsätzlich zu ändern.
"So haben wir beispielsweise damit begonnen, Daten für einige Funktionen (wie den Status) in separaten MySQL-Datenbanken zu speichern, wir haben Read-Replicas hinzugefügt, um die Last auf mehrere Rechner zu verteilen, und wir haben begonnen, ProxySQL zu verwenden, um die Anzahl der Verbindungen zu unseren primären MySQL-Instanzen zu reduzieren" .
Der zentrale MySQL-Cluster blieb dabei aber zunächst weiter bestehen. Darin gespeichert wurden etwa die Profile der Nutzer, Repositories, Github-Issues oder auch Pull Requests. Dazu heißt es jedoch: "Wir hatten Mühe, die Größe unserer Datenbanksysteme angemessen zu halten und mussten immer wieder auf neuere und größere Maschinen umsteigen, um sie zu vergrößern."
Die Lösung für Github war hier die Partitionierung der Datenbank. Doch "bevor Datenbanktabellen physisch verschoben werden können, müssen wir sicherstellen, dass sie virtuell im Anwendungslayout getrennt sind" , heißt es in dem Blog. Dazu haben die Beteiligten die Tabelle zunächst gruppiert und die Grenzen mit Hilfe von Lintern durchgesetzt. Die Linter erkennen dabei SQL-Abfragen und auch Transaktionen, die über die Gruppengrenzen hinweggehen und verhindern diese. Durch eine intelligente Wiederverwendung der MySQL-Replikation konnten die Daten letztlich auch physisch getrennt werden.
Das Ergebnis der Arbeit ist für Github von großem Vorteil. So habe das Team zwar ein weiteres Wachstum der Zugriffe auf die Datenbanktabellen inzwischen auf rund 1,2 Millionen Abfragen pro Sekunde verzeichnet. Doch dank der Arbeit an der Partitionierung konnte die durchschnittliche Last auf jedem der Hosts etwa halbiert werden, wie es in dem Blogpost heißt. Zusätzlich zu der Partitionierung setzt das Entwicklungsteam inzwischen auch auf das sogenannte Sharding. Details dazu sollen folgen.