Sharding: Was das ist und wann es für alte Datenbanken sinnvoll wird
Ihre Anwendung läuft seit Jahren zuverlässig. Doch seit einiger Zeit dauern Auswertungen länger. Der Monatsbericht braucht plötzlich zehn Minuten. Nutzer melden, dass Seiten hängen bleiben.
Irgendwann fällt in der Diskussion ein Begriff: Sharding. Deutsch gibt es dafür kein gutes Wort. Gemeint ist das Aufteilen einer Datenbank auf mehrere Server.
Klingt nach der Lösung. Ist es aber selten. Dieser Artikel erklärt, was Sharding wirklich bedeutet, wann es hilft und welche einfacheren Wege es vorher gibt.
Was ist Sharding?
Eine Datenbank ist ein digitales Lager für Ihre Daten. Kunden, Bestellungen, Rechnungen, Protokolle. Normalerweise liegt dieses Lager auf einem einzigen Server.
Sharding bedeutet: Sie zerlegen dieses Lager in mehrere Teile. Jeder Teil heißt Shard, also Scherbe oder Bruchstück. Jeder Shard liegt auf einem eigenen Server.
Ein Beispiel. Ihre Kundentabelle enthält zehn Millionen Einträge. Beim Sharding landen Kunden mit den Anfangsbuchstaben A bis M auf Server eins. N bis Z auf Server zwei. Jeder Server trägt nur noch die halbe Last.
Der Unterschied zur Replikation
Sharding wird oft mit Replikation verwechselt. Der Unterschied ist wichtig.
Bei der Replikation kopieren Sie die komplette Datenbank auf mehrere Server. Jeder Server hat alle Daten. Das hilft, wenn viel gelesen wird.
Beim Sharding hat jeder Server nur einen Ausschnitt. Das hilft, wenn die Datenmenge selbst zum Problem wird. Beide Verfahren lösen unterschiedliche Probleme.
Was Sharding an Komplexität mitbringt
Sobald Daten verteilt liegen, wird jede Abfrage komplizierter. Die Anwendung muss wissen, auf welchem Server ein Datensatz liegt.
Auswertungen über alle Kunden hinweg müssen mehrere Server abfragen. Die Ergebnisse werden anschließend zusammengeführt. Transaktionen über mehrere Shards sind aufwendig und fehleranfällig.
Auch das Backup wird komplexer. Sie sichern nicht mehr eine Datenbank, sondern mehrere. Und zwar zum gleichen Zeitpunkt.
Warum Ihre Datenbank langsam wird
In den meisten Fällen ist die Datenmenge nicht das eigentliche Problem. Das übersehen viele Diskussionen über Sharding.
Die Daten sind über Jahre gewachsen
Eine Anwendung aus 2010 wurde für andere Mengen gebaut. Damals waren es zehntausend Bestellungen im Jahr. Heute sind es zweihunderttausend.
Die Struktur der Datenbank hat sich aber nie geändert. Sie trägt eine Last, für die sie nie ausgelegt war. Das ist einer der Punkte, an denen sich über die Jahre einiges angesammelt hat.
Es fehlen Indizes
Ein Index ist wie das Register in einem Buch. Ohne Register müssen Sie jede Seite durchblättern. Mit Register schlagen Sie direkt nach.
Fehlende oder falsche Indizes sind die häufigste Ursache für langsame Datenbanken. Der Server durchsucht dann Millionen Zeilen für eine einzige Antwort. Mehr über solche Ursachen lesen Sie in unserem Beitrag zur Datenbankoptimierung bei alter Software.
Die Abfragen sind über die Jahre gewachsen
Jede Erweiterung hat eine Bedingung hinzugefügt. Aus einer schlanken Abfrage wurde ein Ungetüm über zwölf Tabellen.
Solche Abfragen bremsen auch auf schneller Hardware. Kein Sharding der Welt repariert das.
Die Datenbankversion ist veraltet
Alte Datenbankversionen arbeiten messbar langsamer als aktuelle. Zwischen MySQL 5.5 und MySQL 8 liegen Welten bei der Abfrageplanung. Was das für Betrieb und Sicherheit bedeutet, zeigt unser Artikel zum End of Life von MySQL 5.
Wann Sharding wirklich sinnvoll ist
Es gibt Situationen, in denen Sharding der richtige Weg ist. Sie sind seltener, als der Begriff vermuten lässt.
Sharding lohnt sich, wenn alle folgenden Punkte zutreffen.
Die Datenmenge sprengt einen einzelnen Server. Sie reden über mehrere Terabyte in einzelnen Tabellen. Nicht über ein paar Gigabyte.
Optimierung ist ausgereizt. Indizes stimmen, Abfragen sind sauber, die Version ist aktuell. Und es reicht trotzdem nicht.
Die Daten lassen sich sauber trennen. Ein klares Kriterium existiert, etwa Mandant, Region oder Kundennummer. Ohne ein solches Kriterium wird Sharding zum Dauerproblem.
Die Anwendung kann angepasst werden. Sie haben Zugriff auf den Quellcode. Und Sie haben ein Team, das ihn versteht.
Fehlt einer dieser Punkte, ist Sharding die falsche Antwort. Bei vielen Legacy-Systemen fehlen gleich mehrere.
Was Sharding bei alter Software kostet
Sharding ist keine Konfigurationsänderung. Es ist ein Eingriff in die Architektur Ihrer Anwendung.
Der Datenzugriff muss überall angepasst werden. Bei einer gewachsenen Anwendung stecken solche Zugriffe an hunderten Stellen. Ohne Tests wird jede Änderung zum Risiko.
Dazu kommt der laufende Betrieb. Sie betreiben ab sofort mehrere Datenbankserver statt einem. Monitoring, Backups und Updates vervielfachen sich.
Rechnen Sie bei einem mittelgroßen Legacy-System mit mehreren Monaten Projektlaufzeit. Und mit dauerhaft höheren Betriebskosten. Warum solche Kosten oft im Verborgenen bleiben, beschreibt unser Text zu Effizienz und Serverkosten alter Software.
Die Alternativen, die meistens zuerst greifen
In unserer Praxis lösen vier Maßnahmen die überwiegende Mehrheit der Performance-Probleme. Alle sind deutlich günstiger als Sharding.
Indizes prüfen und ergänzen
Jede Datenbank kann protokollieren, welche Abfragen lange dauern. Diese Liste zeigt schnell, wo Indizes fehlen.
Der Aufwand liegt oft bei wenigen Tagen. Die Wirkung ist häufig dramatisch. Antwortzeiten von zwanzig Sekunden fallen auf unter eine Sekunde.
Abfragen aufräumen
Die langsamsten zehn Abfragen verursachen meistens den größten Teil der Last. Wer diese zehn überarbeitet, gewinnt am meisten. Konkrete Techniken dazu finden Sie in unserem Beitrag zur Datenbankoptimierung für alte Software.
Alte Daten archivieren
Brauchen Sie Bestellungen aus 2009 im laufenden Betrieb? Meistens nicht.
Verschieben Sie historische Daten in ein Archiv. Die aktive Tabelle schrumpft deutlich. Das wirkt ähnlich wie Sharding, ist aber viel einfacher umzusetzen.
Datenbank und Hardware aktualisieren
Ein Versionssprung bringt oft mehr als erwartet. Moderne Datenbankversionen planen Abfragen besser. Mehr Arbeitsspeicher ist zudem günstiger als ein Sharding-Projekt.
Diese vier Schritte sind der klassische Weg, um technische Schulden an der Datenbank zu tilgen. Erst danach stellt sich die Architekturfrage neu.
So gehen Sie vor
Beginnen Sie mit einer Messung, nicht mit einer Entscheidung. Ohne Zahlen diskutieren alle Beteiligten über Vermutungen.
Lassen Sie erfassen, welche Abfragen wie lange dauern. Prüfen Sie, wie groß die größten Tabellen wirklich sind. Klären Sie, wie stark die Datenmenge pro Jahr wächst.
Erst mit diesen Zahlen lässt sich beurteilen, ob Sharding überhaupt zur Debatte steht. In den meisten Fällen zeigt die Messung etwas anderes. Nämlich eine Handvoll Abfragen, die seit Jahren niemand angefasst hat.
Falls Sie im Haus niemanden haben, der diese Analyse übernimmt, unterstützen wir Sie dabei. Unsere Software-Wartung umfasst genau solche Prüfungen.
Fazit
Sharding ist ein wirksames Werkzeug für sehr große Datenmengen. Für die meisten Legacy-Systeme im Mittelstand ist es überdimensioniert.
Wer eine langsame Datenbank hat, findet die Ursache fast immer woanders. Bei fehlenden Indizes, bei alten Abfragen, bei veralteten Versionen. Diese Ursachen lassen sich mit überschaubarem Aufwand beheben.
Prüfen Sie zuerst das Naheliegende. Die Architekturfrage können Sie danach immer noch stellen.
Ihre Datenbank wird langsamer und niemand weiß genau warum? Sprechen Sie uns an. Wir schauen uns Ihr System an und sagen Ihnen ehrlich, woran es liegt. Das Erstgespräch ist kostenlos.
