Nichts bleibt wie es war – das ist nicht nur eine Erkenntnis des rheinischen Grundgesetzes, sondern in der IT auch der Normalzustand. Weil sich immer mehr Dienste ins Digitale verlagern, wachsen die Anforderungen an IT-Installationen kontinuierlich – und die Last, mit der diese es zu tun haben. In den vergangenen Jahren haben deshalb Konzepte für das Skalieren in die Breite kontinuierlich an Relevanz gewonnen. Logisch: Auch mit der potentesten CPU und absurden Mengen RAM stoßen einzelne Server irgendwann an die Grenzen dessen, was sie zu leisten imstande sind. Gut, wenn sich die Last stattdessen auf beliebig viele physische Knoten verteilen lässt. Weil praktisch jedes Setup der Gegenwart Datenbanken nutzt, gilt dieser Grundsatz natürlich auch für PostgreSQL, MariaDB & Co.
Datenbanken skalierbar zu bauen, ist allerdings alles andere als trivial. Die Probleme gleichen jenen von Storage-Lösungen mit eingebauter Replikation wie etwa Ceph: Eine skalierte Datenbank muss einerseits sicherstellen, dass von Clients durchgeführte Writes sauber bei allen teilnehmenden Knoten ankommen, bevor der Client den Write als erfolgreich durchgeführt gemeldet bekommt. Sie muss andererseits resilient sein, damit nicht im Falle eines Hardware-Ausfalls unkontrolliert auf zwei nun disjunkte Partitionen eines einzelnen Clusters geschrieben wird. Das alles darf freilich nicht zulasten der Performance laufen: Ein Multi-Knoten-MariaDB nützt niemanden, wenn es für einzelne Commits eine
...Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.