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.

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“.

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.

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.