Mastodon, eine beliebte Social-Media-Plattform mit einer riesigen Nutzerbasis, verwendet PostgreSQL als Datenbank. Viele Entwickler sind davon überzeugt, dass Rails-Anwendungen nicht gut skalieren. Doch diese Annahme ist längst überholt. Moderne Methoden und Tools erlauben es, Rails-Apps auch bei großem Datenverkehr performant zu betreiben. Ein wesentliches Element dabei ist das Sharding der Datenbank – also die horizontale Verteilung von Daten auf mehrere Datenbankinstanzen.
So wird die Last verteilt und die Performance auch bei wachsendem Nutzeraufkommen gewährleistet. Die Herausforderung bei hochgeladenen Rails-Apps wie Mastodon besteht darin, dass man nicht einfach mehrere Container starten und sich auf die vertikale Skalierung verlassen kann. Stattdessen braucht man eine Architektur, die mehrere Datenbanken einbindet. Genau hier setzt PgDog an. PgDog ist ein spezieller Postgres-Proxy, der Abfragen analysiert und automatisch entscheidet, an welchen Knoten die Daten abgefragt oder gespeichert werden sollen.
Dadurch ermöglicht PgDog eine transparente Sharding-Lösung, die ohne größere Codeänderungen der Anwendung auskommt. Der Einstieg in die Implementierung besteht darin, PgDog zwischen die Anwendung und die Postgres-Datenbank zu setzen. Auf einem lokalen System erfolgt dies einfach durch Verschiebung des Verbindungsports in der Konfiguration und das Starten des PgDog-Pools. Somit wird unterscheidbar, dass künftig alle Datenbankanfragen über PgDog laufen. Anfangs werden aber noch keine Abfragen verteilt, sondern alle zum gleichen Datenbankserver geleitet.
Dies bildet die Basis, von der aus nun die eigentliche Sharding-Strategie definiert werden kann. Der Dreh- und Angelpunkt für jede Sharding-Lösung ist die Wahl des richtigen Sharding-Schlüssels. Im Fall von relationalen Datenbanken ist dies eine spezifische Spalte innerhalb einer Tabelle, deren Werte es erlauben, Daten gleichmäßig auf verschiedene Datenbankinstanzen aufzuteilen. Die Aufgabe liegt darin, diese Spalte so zu identifizieren, dass bei Datenabfragen klar ist, ob sie direkt an eine einzige Datenbankinstanz gehen können oder ob ein Abgleich über alle Shards notwendig ist. Eine perfekte Wahl des Sharding-Schlüssels bedeutet, dass die Daten gleichmäßig verteilt und die Datenbanklast auf die einzelnen Knoten ausgeglichen wird.
Somit kann jede Datenbank nur einen Bruchteil der gesamten Anfragen bearbeiten, was die Skalierbarkeit theoretisch auf das Vielfache erhöht. Zudem muss der Sharding-Key idealerweise an vielen Stellen in der Datenbankreferenzen vorhanden sein, um eine nahtlose Nutzung und schnelle Zuordnung der Daten zu ermöglichen. Für Mastodon wurde die Tabelle "accounts" als Basis für den Sharding-Schlüssel gewählt. Grund hierfür ist, dass die Spalte "id" aus dieser Tabelle in etwa 75 der 205 Tabellen als Fremdschlüssel referenziert wird. Dies bedeutete, dass rund 36 Prozent der Datenbanktabellen direkt mit diesem Schlüssel verbunden waren, was bereits ein guter Startpunkt für die Verteilung ist.
Noch realistischer wurde der Anteil durch das Einbeziehen transitativer Beziehungen, also Tabellen, die nicht direkt, sondern über weitere Tabellen referenziert werden. Dieses recursive join-Verfahren führte dazu, dass 60 Prozent aller Tabellen letztlich unter dem Sharding-Schlüssel zusammengefasst werden konnten. Um sicherzugehen, dass der gewählte Sharding-Schlüssel für alle Zugriffe sinnvoll ist und häufig in Abfragen genutzt wird, wurde von PgDog eine sogenannte „Dry Run“-Funktion entwickelt. Diese erlaubt es, alle Anfragen im Proxy zu beobachten, ohne dass diese tatsächlich auf mehrere Datenbanken verteilt werden. Stattdessen wird analysiert, wie PgDog die Abfragen routen würde, und die Ergebnisse werden protokolliert und können somit bewertet werden.
So lässt sich bestimmen, wie viele Abfragen von einem einzigen Shard beantwortet werden könnten und wie viele mehrere Shards gleichzeitig benötigen. Die gesammelten Daten aus dieser Trockenübung zeigten zunächst ernüchternde Ergebnisse. Nur etwa 26 Prozent der Anfragen enthielten bereits den Sharding-Key, sodass ein großer Anteil der Datenbanklast ungerichtet auf allen Shards operierte. Dies verdeutlicht, dass nicht jede Tabelle oder Abfrage ohne weiteres über den Sharding-Schlüssel adressiert werden kann. Vor allem Tabellen, die wenig mit Nutzerdaten zu tun haben und eher Metadaten wie Einstellungen oder Nutzungsbedingungen speichern, konnten nicht eindeutig zugeordnet werden.
Diese Erkenntnis führte zum Konzept der „Omnishards“. Dabei handelt es sich um Tabellen, die nicht sharded werden, sondern in allen Datenbanken identisch vorgehalten werden. Da diese Daten oft selten geändert und aber häufig abgefragt werden, macht es Sinn, sie kopiert in jedem Shard verfügbar zu halten. PgDog verteilt Leseanfragen auf Omnishard-Tabellen anschließend per Round-Robin auf die Shards, sodass die Last ausgeglichen bleibt. Beruflich genutzt, führt diese Technik zu deutlichen Performancegewinnen, da die sogenannten Metadata-Tabellen so keine Cross-Shard-Operationen auslösen.
Nach der Implementierung der Omnishards konnte eine deutliche Steigerung der direkt verteilbaren Abfragen festgestellt werden. Die Zahl der Anfragen, welche nur einen Shard ansteuerten, stieg auf 52 Prozent an. Noch nicht die angestrebten 95 Prozent, dennoch ein wichtiger Meilenstein, der belegt, dass die Sharding-Strategie grundsätzlich funktioniert. Dabei profitierte PgDog von seiner effizienten Query-Caching-Funktion, mit der es meist nur einmal eine Abfrage parsen musste, bevor es sie zuverlässig routen konnte. Dank der Normalisierung mit dem Tool pg_query wurden unterschiedliche Abfragen mit ähnlichem Aufbau zusammengeführt, wodurch Speicherbedarf und Rechenzeit optimiert wurden.
Ein häufiges Problem beim Sharding betrifft Schreibvorgänge im Kontext von Transaktionen. Bei Mastodon zeigte sich, dass einige Insert-Abfragen keine direkte Kennung für den Shard enthalten. Beispielhaft war die Tabelle "conversations", in die zuerst Daten eingefügt wurden, ohne dass im Insert selbst ein Sharding-Key vorlag. Später werden dann in der Tabelle "statuses" Schlüssel zugehörig zum Account mitgeschickt. Das bedeutet, dass eine Routing-Entscheidung für die erste Tabelle getroffen werden müsste, bevor alle Infos vorliegen.
Um dieses Dilemma zu lösen, entwickelte PgDog eine Methode namens „Manuelles Routing“. Hierbei nutzt man den SQL-Befehl SET, um einen temporären Session-Parameter zu definieren, der den Sharding-Key enthält. Innerhalb einer Transaktion wird dieser Wert gesetzt, was PgDog erlaubt, alle nachfolgenden Abfragen der korrekten Datenbankinstanz zuzuordnen. Die Rails-Anwendung musste hierzu lediglich an den Stellen, in denen Daten geschrieben werden, mit einem Sharding-Kontext versehen werden. Zur Erleichterung für Entwickler wurde ein Ruby-Gem namens PgDog entwickelt.
Dieses ermöglicht es, durch eine einfache Methodenumgebung den Sharding-Key zu setzen und gleichzeitig eine Transaktion zu starten. So bleiben die Änderungen minimal und der Code sauber. Die Integration erfolgt ohne große Umbauten der bestehenden Codebasis, was die Adoption erheblich vereinfacht. Das Erreichen von 95 Prozent aller Anfragen, die direkt einem Shard zugeordnet werden können, ist das erklärte Ziel, um eine effiziente horizontale Skalierung sicherzustellen. Neben der Wahl eines passenden Sharding-Schlüssels spielen dabei auch Codemuster, Query-Struktur und Datenbankreferenzen eine wichtige Rolle.
Weitere Herausforderungen sind die Gewährleistung der Datenintegrität über omnisharded Tabellen hinweg sowie der Schutz vor ungültigen Cross-Shard-Schreibevorgängen. Das gesamte Projekt zeigt, dass Sharding in Rails-Anwendungen kein Mythos ist, sondern durch intelligente Tools wie PgDog im Zusammenspiel mit PostgreSQL realisierbar wird. Es bedarf zwar einiger konzeptioneller Vorarbeit, einer guten Kenntnis des Datenbankschemas und einiger pragmatischer Lösungen, doch die potenziellen Skalierungsvorteile sind enorm. Für Mastodon als repräsentatives Beispiel einer großen Webanwendung zeigt sich, dass eine Vielzahl der Abfragen mit vergleichsweise geringem Aufwand auf mehrere Datenbank-Shards verteilbar ist. Die vorgestellten Konzepte wie Dry Run, Omnishards und Manuelles Routing bilden die Grundlage einer sicheren und performanten Multi-Database-Architektur.
Sie erlauben es Entwicklern, die Datenbanklast zu zerteilen und besser auszunutzen, ohne massiv in die App-Logik eingreifen zu müssen. Zudem ist die Kombination mit Monitoring über Prometheus und anderen Werkzeugen essenziell, um den Erfolg der Maßnahmen in Echtzeit zu messen und bei Bedarf nachzusteuern. PgDog entwickelt sich so zum unverzichtbaren Werkzeug für die Skalierbarkeit von Datenbanken in Rails-Umgebungen. Während die vorgestellten Lösungen noch weiter optimiert werden müssen, vermittelt dieses Projekt einen klaren Einblick in die Praxis des verteilten Datenmanagements. Es wird spannend zu beobachten, wie mit zukünftigen Versionen, automatisierten Codeänderungen und Unterstützung für umfassende Transaktionssicherheit die nächste Stufe der Datenbank-Skalierung erreicht wird.
Wer sich tiefer mit dem Thema Datenbank-Sharding beschäftigen will, findet in der Umsetzung bei Mastodon und PgDog wertvolle Anregungen, wie moderne Anwendungen auch unter höchster Last stabil und performant bleiben können. Die richtige Architektur entscheidet über die Nutzererfahrung und den langfristigen Erfolg von Webdiensten – und Sharding ist unverzichtbarer Teil dieses Puzzles.
