Antwortzeit, Durchsatz und horizontale Skalierbarkeit


Größere Hardware ist nicht immer schneller – sie kann aber mehr Last bewältigen. Sie entspricht eher einer breiteren Autobahn als einem schnelleren Auto – man kann (darf) nicht schneller fahren, nur weil drei Spuren frei sind. Das ist der Grund, warum langsame SQL-Abfragen durch größere Hardware nicht automatisch schnell werden.

Wir sind nicht mehr in den 1990ern. Damals wuchsen die CPU-Takt­ra­ten rapide. Langsame Software war auf neuer Hardware automatisch schneller – nur wegen der höheren Taktrate. Es war, als wäre jedes neue Auto doppelt so schnell wie das alte gewesen. In den ersten Jahren des 21. Jahrhunderts sind Taktraten aber an die physikalischen Grenzen gestoßen. Seither gab es kaum noch Verbesserungen in diesem Bereich. Um dennoch leistungsfähigere Prozessoren zu bauen, mussten die Hersteller auf eine Multi-Core-Strategie umsteigen. Obwohl dadurch mehrere Aufgaben gleichzeitig bearbeitet werden können, steigt die Geschwindigkeit nicht, wenn es nur eine Aufgabe gibt. Performance hat eben mehrere Dimensionen.

Horizontale Skalierung, wenn man also mehrere Server verwendet, hat ähnliche Einschränkungen. Obwohl man dadurch mehr Abfragen verar­bei­ten kann, steigt die Geschwindigkeit einzelner Abfragen nicht unbedingt. Um die Antwortzeit einer Suche zu verbessern, benötigt man einen effizienten Suchbaum – sogar in nicht-relationalen Systemen wie CouchDB oder MongoDB.

Wichtig

Sorgfältige Indizierung ist der beste Weg, Suchen zu beschleunigen – sowohl bei relationalen SQL-Datenbanken als auch bei nicht-relatio­nalen Systemen.

Bei sorgfältiger Indizierung strebt man danach, die logarithmische Ska­lie­rung eines B-Tree-Indexes optimal auszunutzen. Oft wird aber nur ober­fläch­lich indiziert. Der Chart aus „Auswirkungen des Datenvolumens“ zeigt den Unterschied zwischen ordentlicher und oberflächlicher Indizierung.

Abbildung 3.5. Antwortzeit über das Datenvolumen


Der Geschwindigkeitsunterschied ist überwältigend. Durch horizontale Skalie­rung kann man die Auswirkungen oberflächlicher Indizierung kaum kompensieren. Selbst wenn man die Antwortzeit durch Hardware so weit verbessern könnte, wäre es doch fraglich, ob zusätzliche Hardware die beste Lösung für solche Probleme ist.

Viele der sogenannten NoSQL-Systeme argumentieren aber gerade damit, dass sie sämtliche Performance-Probleme durch horizontale Skalierung lösen können. Diese Skalierbarkeit beschränkt sich im Wesentlichen auf Schreiboperationen und wird durch Abschläge bei der Datenkonsistenz erreicht („letztendliche Konsistenz“, engl. eventual consistency). SQL-Daten­banken garantieren aber eine strikte Konsistenz. Dadurch wir die Antwortzeit für Schreiboperationen zwar erhöht, der Durchsatz muss sich aber nicht unbedingt reduzieren. Mehr dazu im Kasten „Konsistenz-Modelle und das CAP-Theorem“.

Konsistenz-Modelle und das CAP-Theorem

Um strikte Konsistenz in einem verteilten System zu wahren, müssen sämtliche Schreibzugriffe zwischen den teilnehmenden Knoten synchron koordiniert werden. Daraus resultieren zwei unangenehme Nebenwirkungen: (1) die synchrone Kommunikation erhöht die Ant­wort­zei­ten durch Latenzen; (2) die Verfügbarkeit wird verringert, weil bei jeder Änderung mehrere Systeme gleichzeitig aktiv sein müssen.

Verteilte SQL-Datenbanken werden oft mit Computer-Clustern ver­wech­selt, die auf ein zentrales Speichersystem zugreifen oder eine Master/Slave-Replikation benutzen. Eine verteilte Datenbank entspricht aber eher einem Web-Shop, der mit einem Waren­wirt­schafts­system integriert ist. Häufig sind es völlig unabhängige Systeme verschiedener Hersteller. Dennoch ist die Konsistenz über beide Datenbestände wünschenswert. Um Transaktionen über mehrere Systeme zu koordinieren, wird das Zwei-Phasen-Commit-Protokoll (2PC) verwendet. Damit erhält man das bekannte „Alles-oder-nichts-Verhalten“ über mehrere Datenbanken hinweg. Eine globale Transaktion kann aber nur abgeschlossen werden, wenn alle teilnehmenden Knoten verfügbar sind. Dadurch reduziert sich die Gesamtverfügbarkeit.

Je mehr Knoten ein verteiltes System hat, desto problematischer wird strikte Konsistenz. Es ist, de facto, unmöglich, strikte Konsistenz über mehr als ein paar Knoten zu wahren. Verzichtet man darauf, löst man sowohl das Verfügbarkeits- als auch das Latenz-Problem. Die Grundidee ist, die globale Konsistenz herzustellen, nachdem die Schreiboperation lokal abgeschlossen wurde. Das Problem ist nur, dass es keine Möglichkeit gibt, Konflikte zu vermeiden, wenn zwei Knoten widersprüchliche Änderungen annehmen. Die Konsistenz wird letztendlich erreicht, indem Konflikte nachträglich aufgelöst werden. In diesem Zusammenhang bedeutet Konsistenz bloß, dass alle Systeme dieselben Daten haben – das müssen nicht unbedingt die letzten oder richtigen Daten sein.

Brewer’s CAP-Theorem beschreibt den allgemeinen Zusammenhang zwischen Konsistenz (Consistency), Verfügbarkeit (Availability) und der Toleranz gegenüber isolierten Partitionen (Partition tolerance).

Meistens verbessert zusätzliche Hardware die Antwortzeiten nicht. Ein System kann dadurch sogar langsamer werden, weil zusätzliche Latenzen anfallen. Wenn die Applikation und die Datenbank auf demselben Server installiert sind, spielen Netzwerk-Latenzen zum Beispiel keine Rolle. Eine derartige Konfiguration ist bei Produktionssystemen aber selten – dort verwendet man dezidierte Hardware für die Applikation und die Daten­bank. Manche Sicherheits­richtlinien erfordern sogar eine Firewall zwischen dem Applikations-Server und der Datenbank. Je komplexer die Infrastruktur wird, desto mehr Latenzen akkumulieren sich, desto langsamer werden die Abfragen. Auch das führt immer wieder zur scheinbar widersprüchlichen Beobachtung, dass die teure Produktionshardware langsamer ist als der Desktop PC, der bei der Entwicklung verwendet wurde.

Bei unseren Schlulungs-, Tuning-, und
Literaturangeboten ist für jeden was dabei

Eine weitere wichtige Latenz sind die Suchzeiten von Festplatten. Rotie­rende Festplattenlaufwerke (HDD) benötigen in der Regel einige Millise­kun­den, um die beweglichen Teile so zu platzieren, dass die gewünschten Daten gelesen werden können. Beim Durchwandern eines Indexbaumes mit vier Schichten tritt diese Latenz dann schon viermal auf – insgesamt etliche Millisekunden. Das ist zwar eine halbe Ewigkeit für einen Computer, aber immer noch weit unter der Wahrnehmungsgrenze eines Menschen – solange man es nur einmal macht. Mit einer einfachen SQL-Abfrage kann man aber auch hunderte oder gar tausende Festplattenzugriffe auslösen. Insbesondere, wenn man mehrere Tabellen mit einer Join-Operation verbindet. Obwohl dieses Problem durch Caching verringert wird und neue Technologien, wie SSD, wesentlich geringere Suchzeiten haben, stehen Join-Operationen nach wie vor im Generalverdacht langsam zu sein. Daher behandelt das nächste Kapitel, wie man Join-Operationen indiziert.

Wenn dir gefällt, wie ich die Dinge erkläre, wirst du meine Kurse lieben.

Solid State Disks (SSD) und Caching

Solid State Disks (SSD) sind eine Massenspeicher-Technologie ohne bewegliche Teile. Die Suchzeit ist bei einer SSD um eine Größen­ord­nung besser als bei Festplatten mit beweglichen Teilen (HDD). SSDs sind seit circa 2010 im Serverumfeld verfügbar, bei Datenbanken aufgrund des hohen Preises und der beschränkten Lebenserwartung aber nicht weit verbreitet.

Datenbanken verwenden aber einen Zwischenspeicher (cache) für häufig benötigte Daten. Das hilft vor allem bei Daten, die bei jedem Indexzugriff benötigt werden – also z. B. der Wurzel­kno­ten. Häufig verwendete Indizes könnten sogar als Ganzes im Hauptspeicher gecached sein, sodass eine Indexsuche keinen einzigen Festplattenzugriff auslöst.

Fakten

  • Performance hat zwei Dimensionen: Antwortzeit und Durchsatz.

  • Mehr Hardware verbessert die Antwortzeit meistens nicht.

  • Sorgfältige Indizierung ist die beste Methode, Antwortzeiten zu verbessern.

Über den Autor

Photo of Markus Winand
Markus Winand stimmt Entwickler auf SQL-Performance ein. Er hat das Buch SQL Performance Explained veröffentlicht und bietet inhouse Schulungen sowie Tuning-Leistungen auf http://winand.at/ an.