Skalierbarkeit

Unter vertikaler Skalierung versteht man ein Steigern der Leistung durch das Hinzufügen von Ressourcen zu einem Knoten/Rechner des Systems. Beispiele dafür wären das Vergrößern von Speicherplatz, das Hinzufügen einer CPU, oder das Einbauen einer leistungsstärkeren Grafikkarte.

Charakteristisch für diese Art von Skalierung ist, dass ein System unabhängig von der Implementierung der Software schneller gemacht werden kann. Das heißt, es muss keine Zeile Code geändert werden, um eine Leistungssteigerung durch vertikales Skalieren zu erfahren. Der große Nachteil dabei ist jedoch, dass man früher oder später an eine Grenze stößt, bei der man den Rechner nicht weiter aufrüsten kann, wenn man bereits die beste Hardware verwendet, die zu diesem Zeitpunkt am Markt ist.

Im Gegensatz zur vertikalen Skalierung sind der horizontalen Skalierung keine Grenzen (aus Sicht der Hardware) gesetzt. Horizontale Skalierung bedeutet die Steigerung der Leistung eines Systems durch das Hinzufügen zusätzlicher Rechner/Knoten. Die Effizienz dieser Art der Skalierung ist jedoch stark von der Implementierung der Software abhängig, da nicht jede Software gleich gut parallelisierbar ist.

Lastskalierbarkeit steht für ein konstantes Systemverhalten über größere Lastbereiche hinweg. Das bedeutet, dass ein System zum einen sowohl bei geringer, mittlerer, als auch bei hoher Last keine zu große Verzögerung aufweist und die Anfragen rasch abgearbeitet werden können.

Bei einer Garderobe in einem Museum, bei welcher Besucher Jacken abgeben und wieder abholen, gilt das First-Come-First-Served-Prinzip. Dabei gibt es eine beschränkte Anzahl an Kleiderhaken und eine größere Anzahl an Besuchern. Die Garderobe, an der sich die Besucher in einer Reihe anstellen, ist ein Karussell. Um einen freien Haken bzw. seine Jacke zu finden, sucht jeder Besucher linear danach.

Unser Ziel ist es nun, die Zeit, die ein Besucher tatsächlich im Museum verbringen kann, zu maximieren.

Die Performance dieses Systems ist unter hoher Last dramatisch schlecht. Erstens wird das Suchen freier Haken immer aufwändiger, je weniger freie Haken zur Verfügung stehen. Zweitens ist unter hoher Auslastung (z. B. im Winter) ein Deadlock vorprogrammiert. Während am Morgen sämtliche Besucher ihre Jacken abgeben, holen sie sich diese am Abend wieder alle ab. Ein Deadlock wird voraussichtlich mittags und am frühen Nachmittag auftreten, wenn keine freien Kleiderhaken mehr verfügbar sind und weitere Besucher am Ende der Schlange stehen, um ihre Jacke abzuholen.

Personen, die ihre Jacke abholen möchten, könnten diesen Deadlock auflösen, indem sie die anreisenden Besucher bitten, in der Schlange vorgelassen zu werden. Da die Personen, welche ihre Jacke abholen, erst nach einem gewissen Timeout danach fragen werden, ist dieses System höchst inperformant.

Das Erhöhen der Anzahl an Kleiderhaken würde das Problem lediglich hinauszögern, jedoch nicht beheben. Die Lastskalierbarkeit ist folglich sehr schlecht.

Räumliche Skalierbarkeit weist ein System bzw. Anwendung auf, wenn der Speicherbedarf bei einer wachsenden Anzahl an zu verwaltenden Elementen nicht inakzeptabel hoch ansteigt. Nachdem „inakzeptabel“ ein relativer Begriff ist, spricht man in diesem Zusammenhang in der Regel von akzeptabel, wenn der Speicherbedarf höchstens sub-linear ansteigt. Um das zu erreichen, kann z. B. eine dünnbesetzte Matrix (engl. sparse matrix) bzw. Datenkompression angewendet werden. Da Datenkompression eine gewisse Zeit beansprucht, steht diese jedoch häufig in Widerspruch zur Lastskalierbarkeit.

Ein System verfügt über eine zeitlich-räumliche Skalierbarkeit, wenn sich das Erhöhen der Anzahl von Objekten, die ein System umfasst, nicht erheblich auf dessen Performance auswirkt. Beispielsweise weist eine Suchmaschine mit linearer Komplexität keine zeitlich-räumliche Skalierbarkeit auf, während eine Suchmaschine mit indizierten, bzw. sortierten Daten, z. B. unter Verwendung einer Hashtabelle oder eines balancierten Baums, sehr wohl eine zeitlich-räumliche Skalierbarkeit vorweisen könnte.

Strukturelle Skalierbarkeit zeichnet ein System aus, dessen Implementierung das Erhöhen der Anzahl von Objekten innerhalb eines selbst definierten Bereichs nicht maßgeblich behindert.

Da ein System natürlich mehrere Arten von Skalierbarkeit aufweisen kann, stellt sich die Frage, wie und ob diese miteinander zusammenhängen. Siehe dazu die Tabelle oben.

Die Lastskalierbarkeit eines Systems wird nicht zwangsläufig durch eine schlechte räumliche oder strukturelle Skalierbarkeit negativ beeinflusst. Systeme mit schlechter räumlicher oder zeitlich-räumlicher Skalierbarkeit haben, aufgrund des Overheads an Speicherverwaltung bzw. des hohen Suchaufwands, möglicherweise auch eine schlechte Lastskalierbarkeit. Systeme mit guter zeitlich-räumlicher Skalierbarkeit haben unter Umständen eine schlechte Lastskalierbarkeit, wenn z. B. nicht ausreichend parallelisiert wurde.

Der Zusammenhang zwischen struktureller Skalierbarkeit und Lastskalierbarkeit sieht folgendermaßen aus: Während letztere keine Auswirkungen auf erstere hat, kann das umgekehrt sehr wohl der Fall sein.

Die verschiedenen Arten von Skalierbarkeit sind also nicht ganz unabhängig voneinander.

Beim Betrachten des Ladens einer Seite in einem beliebigen Browser mit einem Debugging-Tool (z. B. Firebug) fällt auf, dass ähnliche große Elemente unterschiedlich lange Ladezeiten beanspruchen. Bei genauerer Betrachtung erkennt man, dass einige dieser Elemente einen zusätzlichen DNS-Lookup benötigen. Dieser Vorgang der Adressauflösung kann durch DNS-Caching auf unterschiedlichen Ebenen (z. B. Browser, Betriebssystem, Internet-Provider etc.) beschleunigt werden. Um die Anzahl der Lookups zu reduzieren, könnte man nun alle JavaScript- und CSS-Dateien zu jeweils einer zusammenfassen und man könnte alle Bilder auf ein großes zusammenfügen und mittels CSS-Sprites nur den gewünschten Bildausschnitt anzeigen. Allgemein kann man folgende Regel dazu aufstellen: Je weniger DNS-Lookups beim Laden einer Seite erforderlich sind, desto besser ist die Performance. Die folgende Tabelle[5] veranschaulicht, wie teuer der DNS-Lookup und der Verbindungsaufbau verhältnismäßig sind.

Moderne Browser können jedoch mehrere Verbindungen gleichzeitig zu einem Server offen halten, um mehrere Objekte parallel herunterzuladen. Laut HTTP/1.1 RFC 2616[6] sollte das Maximum an gleichzeitigen Verbindungen je Server im Browser auf 2 limitiert werden. Einige Browser ignorieren diese Richtlinie jedoch und verwenden ein Maximum von 6 gleichzeitigen Verbindungen und mehr. Reduziert man auf einer Webseite nun jedoch alle JavaScript- und CSS-Dateien sowie alle Bilder lediglich auf jeweils eine Datei, so entlastet man zwar die anbietenden Server, hebelt jedoch gleichzeitig diesen Mechanismus der parallelen Verbindungen des Browsers aus.

Idealerweise nutzt man diese Parallelisierung im Browser zur Gänze aus und hat gleichzeitig möglichst wenige DNS-Lookups. Um das zu erreichen, verteilt man eine Webseite am besten auf mehrere Subdomains (z. B. ruft man Bilder von einer Subdomain auf, während man Videos von einer anderen lädt). Durch diese Vorgehensweise lässt sich relativ einfach eine beachtliche Performance-Steigerung erzielen. Es gibt jedoch keine allgemeine Antwort darauf, wie viele Subdomains man verwenden sollte, um die bestmögliche Leistung zu erzielen. Einfache Performance-Tests der zu optimierenden Seite sollten darüber jedoch rasch Aufschluss bieten.

Der am schwierigsten zu skalierende Teil eines Systems ist meistens die Datenbank bzw. die Datenhaltungsschicht (s. o.). Der Ursprung dieses Problems kann bis zum Paper A Relational Model of Data for Large Shared Data Banks[7] von Edgar F. Codd zurückverfolgt werden, welches das Konzept eines Relational Database Management System (RDBMS) vorstellt.

Eine Methode, um Datenbanken zu skalieren, ist es, sich zu Nutze zu machen, dass die meisten Anwendungen und Datenbanken wesentlich mehr Lese- als Schreibzugriffe aufweisen. Ein durchaus realistisches Szenario, das in dem Buch von Martin L. Abbott und Michael T. Fisher beschrieben wird, ist eine Buchreservierungsplattform, welche ein Verhältnis zwischen Lese- und Schreibzugriffen von 400:1 aufweist. Systeme dieser Art können relativ einfach skaliert werden, indem mehrere read-only Duplikate dieser Daten angefertigt werden.

Es gibt mehrere Wege, um die Kopien dieser Daten zu verteilen, abhängig davon, wie aktuell die Daten der Duplikate wirklich sein müssen. Grundsätzlich sollte es kein Problem sein, dass diese Daten lediglich alle 3, 30, oder 90 Sekunden synchronisiert werden. Bei dem Szenario der Buchplattform gibt es 1.000.000 Bücher, und 10 % davon werden täglich reserviert. Angenommen, die Reservierungen sind gleichmäßig über den gesamten Tag verteilt, so findet ca. eine Reservierung pro Sekunde (0,86 Sekunden) statt. Die Wahrscheinlichkeit, dass zum Zeitpunkt (innerhalb 90 Sekunden) einer Reservierung ein anderer Kunde das gleiche Buch reservieren möchte, beträgt (90/0,86)/100.000 = 0,104 %. Natürlich kann und wird dieser Fall irgendwann eintreffen, doch diesem Problem kann ganz einfach durch eine abschließende, erneute Überprüfung der Datenbank entgegentreten werden.

Eine Möglichkeit, um diese Methode umzusetzen, ist es, die Daten, z. B. mit einem Key-Value-Store (etwa Redis), zu cachen. Der Cache muss erst nach Ablauf seiner Gültigkeit erneuert werden und entlastet damit die Datenbank enorm. Der einfachste Weg, diesen Cache zu implementieren, ist, ihn in einer bereits bestehenden Schicht (z. B. der Logikschicht) zu installieren. Für eine bessere Performance und Skalierbarkeit verwendet man dafür jedoch eine eigene Schicht, bzw. eigene Server, zwischen der Logikschicht und der Datenhaltungsschicht.

Der nächste Schritt ist nun, die Datenbank zu replizieren. Die meisten bekannten Datenbanksysteme verfügen bereits über eine solche Funktion. MySQL bewerkstelligt dies mit dem master-slave-Prinzip, wobei die master-Datenbank die eigentliche Datenbank mit Schreibrechten ist und die slave-Datenbanken die duplizierten read-only Kopien sind. Die Master-Datenbank zeichnet sämtliche updates, inserts, deletes etc. im sogenannten Binary-Log auf, und die Slaves reproduzieren diese. Diese Slaves steckt man nun hinter einen Load Balancer (s. u.), um die Last entsprechend zu verteilen.

Diese Art von Skalierung lässt die Anzahl der Transaktionen relativ einfach skalieren. Je mehr Duplikate der Datenbank verwendet werden, desto mehr Transaktionen können auch parallel bewältigt werden. In anderen Worten bedeutet das, dass nun beliebig viele User (natürlich abhängig von der Anzahl der Server) gleichzeitig auf unsere Datenbank zugreifen können. Diese Methode hilft uns nicht dabei, auch die Daten an sich zu skalieren. Um nun auch beliebig viele Daten in der Datenbank speichern zu können, ist ein weiterer Schritt nötig. Dieses Problem wird im nächsten Punkt behandelt.

Was man hiermit erreichen möchte, ist, eine Datenbank auf mehrere Rechner aufzuteilen und ihre Kapazität beliebig durch weitere Rechner zu erweitern. Dazu muss die Datenbank zu einem gewissen Grad denormalisiert werden. Unter Denormalisierung versteht man die bewusste Rücknahme einer Normalisierung zum Zweck der Verbesserung des Laufzeitverhaltens einer Datenbankanwendung.

Im Zuge der Denormalisierung muss die Datenbank fragmentiert werden.

Man unterscheidet horizontale und vertikale Fragmentierung.

Bei der Horizontalen Fragmentierung (Eng. sharding) wird die Gesamtheit aller Datensätze einer Relation auf mehrere Tabellen aufgeteilt. Wenn diese Tabellen auf demselben Server liegen, dann handelt es sich meistens um Partitionierung. Die einzelnen Tabellen können aber auch auf unterschiedlichen Servern liegen. So können z. B. die Daten für die Geschäfte in den USA auf einem Server in den USA gespeichert werden und die Daten für die Geschäfte mit Europa liegen auf einem Server in Deutschland. Diese Aufteilung wird auch als Regionalisierung bezeichnet.

Horizontale Fragmentierung schafft keine Redundanz der gespeicherten Daten, sondern der Strukturen. Wenn eine Relation geändert werden muss, dann muss nicht nur eine Tabelle geändert werden, sondern es müssen alle Tabellen geändert werden, über die die Daten aus der betreffenden Relation verteilt sind. Hier besteht die Gefahr von Anomalien in den Datenstrukturen.

Bei der Vertikalen Fragmentierung werden die abhängigen Attribute (nicht-Schlüssel-Attribute) einer Tabelle in zwei oder mehrere Gruppen aufgeteilt. Aus jeder Gruppe wird eine eigene Tabelle, die noch um alle Schlüssel-Attribute der Ursprungstabelle ergänzt werden. Das kann dann sinnvoll sein, wenn die Attribute einer Relation Datensätze mit einer sehr großen Satzlänge ergeben. Wenn zusätzlich noch die Zugriffe meistens nur einige wenige Attribute betreffen, dann kann man die wenigen häufig zugegriffenen Attribute in eine Gruppe zusammenfassen und den Rest in eine zweite Gruppe zusammenfassen. Die häufig auszuführenden Zugriffe werden dadurch schneller, weil eine geringere Menge an Daten von der Festplatte gelesen werden muss. Die selten auszuführenden Zugriffe auf die restlichen Attribute werden dadurch nicht schneller, aber auch nicht langsamer.

Ab welcher Satzlänge eine Aufspaltung in mehrere kleinere Tabellen sinnvoll ist, hängt auch von dem Datenbanksystem ab. Viele Datenbanksysteme speichern die Daten in Form von Blöcken mit einer Größe von 4 KiB, 8 KiB oder 16 KiB ab. Wenn die durchschnittliche Satzlänge wenig größer als 50 % eines Datenblocks ist, dann bleibt viel Speicherplatz ungenutzt. Wenn die durchschnittliche Satzlänge größer als die verwendete Blockgröße ist, dann werden die Datenzugriffe aufwändiger. Wenn BLOBs zusammen mit anderen Attributen in einer Relation vorkommen, ist vertikale Fragmentierung fast immer von Vorteil.

Partitionierung ist ein Spezialfall der horizontalen Fragmentierung.

Große Datenbestände lassen sich leichter administrieren, wenn die Daten einer Relation in mehrere kleine Teile (=Partitionen) aufgeteilt und diese separat gespeichert werden. Wenn eine Partition einer Tabelle gerade aktualisiert wird, dann können andere Partitionen der Tabelle zur selben Zeit reorganisiert werden. Wenn in einer Partition ein Fehler entdeckt wird, dann kann diese einzelne Partition aus einer Datensicherung wiederhergestellt werden, während Programme auf die anderen Partitionen weiter zugreifen können. Die meisten etablierten Datenbankhersteller bieten Partitionierung an, siehe z. B. Partitionierung bei DB2 und Partitionierung bei MySQL.

Die meisten Datenbanksysteme bieten die Möglichkeit, entweder einzelne Partitionen anzusprechen oder alle Partitionen unter einem einheitlichen Tabellennamen anzusprechen.

Durch Partitionierung können die Datenzugriffe beschleunigt werden. Der wesentliche Vorteil ist jedoch die leichtere Administrierbarkeit der gesamten Tabelle.