Alexey Kovyazin, 16. Mai 2014

Sie können diesen Artikel im PDF-Format herunterladen.

Kürzlich haben wir bei IBSurgeon eine Reihe von Leistungstests mit Firebird 2.5.2 durchgeführt. Firebird 2.5.2 ist die beliebteste Version der Firebird-Datenbank, und ihre Benutzer haben oft Fragen zur Firebird-Leistung.

Eines der wichtigsten Themen bezüglich der Datenbankleistung ist deren Verschlechterung. Viele Benutzer behaupten, dass ihre Datenbankanwendungen Leistungsprobleme haben, wenn ein bestimmter Schwellenwert erreicht wird: Es kann 3 GB, 5 GB, die Größe des Arbeitsspeichers, 20 GB usw. sein. Die häufigste Behauptung ist: „Die Datenbankgröße ist größer als die RAM-Größe“: Wenn die Firebird-Datenbankgröße die RAM-Größe erreicht, wird berichtet, dass sie sehr langsam wird … Stimmt das?

Wir haben beschlossen, eine Reihe von Tests durchzuführen, um zu prüfen, ob es eine solche Leistungsverschlechterung im Zusammenhang mit dem Datenbankwachstum gibt. Wir haben beschlossen, das Wachstum der Datenbank über die Zeit mit derselben Last auf derselben Hardware zu simulieren. Dazu haben wir 11 Tests mit Datenbanken zwischen 9 GB und 30 GB durchgeführt:

Abbildung 1. Datenbankgrößen für die Tests

Testhardware und Firebird-Konfiguration

Die Testhardware hatte die folgenden Hauptmerkmale:

CPU AMD-FX8350, RAM 16 GB, SATA-Software-RAID1 2x4TB Seagate-Festplatten, Betriebssystem Windows Server 2008R2 (2008R2 ist 64-Bit).

Wie Sie sehen können, handelt es sich um eine Low-End-Hardwarekonfiguration; sie kann derzeit (Mai 2014) für weniger als 1000 USD gekauft werden und kann als typische Low-Level-Konfiguration betrachtet werden - vielleicht mit Ausnahme der großen SATA-Festplatten, aber laut Herstellerbericht ist die Geschwindigkeit von 1-TB- und 4-TB-SATA-Festplatten fast gleich.

Da das Ziel des Tests darin bestand, Leistungsänderungen eines typischen Systems zu messen, haben wir Firebird (64-Bit) mit SuperServer-Architektur verwendet, nicht Classic, um die Situation in einem kleinen Unternehmen vollständig zu simulieren - sie verwenden, was ursprünglich seit Jahren installiert wurde. Wie Sie wissen, verwendet SuperServer nur 1 CPU-Kern, daher könnten Classic oder SuperClassic (die alle CPU-Kerne nutzen können) bessere Ergebnisse in Bezug auf die Leistung zeigen, aber unser Ziel war nicht das Leistungs-Tuning.

Wir haben jedoch firebird.conf mit den offensichtlichen Änderungen angepasst, die wir für alle Firebird-SuperServer-Installationen empfehlen: erhöhte Seitenpuffer auf 10000 und temporärer Speicherplatz für das Sortieren.

Alle Testdatenbanken wurden mit einer Seitengröße von 16384 erstellt, nur aus Konsistenzgründen.

Testen

Laden

Jeder Test bestand aus 2 Schritten: Laden und Simulation von 20 Terminals, die Einfügungen, Aktualisierungen und Löschungen durchführen.

Der Ladeschritt wird von einer Ladeanwendung (load.exe) durchgeführt, die Daten in mehrere Tabellen einfügt. Wie Sie in Abbildung 2 sehen können, werden die Daten mit unterschiedlicher Geschwindigkeit geladen; sie variiert von ~35 MB/s bis 1 MB/s.

Abbildung 2. Datenbank-Ladegeschwindigkeit (roter Graph)

Dies hängt mit dem Design der Ladeanwendung zusammen, nicht mit Firebird: Der Loader fügt schnell 70 % der Datenbank ein und füllt dann langsam den Rest der Daten, und dies wird bei Datenbanken aller Größen wiederholt. Es ist wichtig für uns, dass der Loader dieselben Operationen durchführt, damit wir seine Durchschnittsgeschwindigkeit verwenden können, um die Ladegeschwindigkeit zu messen.

Es ist wichtig zu erwähnen, dass der Loader nur Daten einfügt und Indizes nach Abschluss des Ladens erstellt werden.

Schauen wir uns die Tabelle mit den Ergebnissen für den Ladeschritt für 11 Datenbanken zwischen 9 und 30 GB an:

#	Datenbankgröße, GB	Ladezeit, Sek.	SATA-Ladegeschwindigkeit, MB/s
1	9,04	2535	3,65166075
2	10,80	3197	3,45924304
3	13,00	4057	3,281242297
4	15,50	4698	3,378458919
5	17,30	5455	3,24751604
6	19,90	6037	3,375451383
7	21,60	6473	3,417024564
8	24,20	7539	3,287014193
9	26,00	7779	3,422547885
10	28,60	8851	3,308823862
11	30,30	9266	3,348499892

Abbildung 3 Ladezeit und -geschwindigkeit

Oder besser im Diagramm in Abbildung 4 dargestellt:

Abbildung 4. Testergebnisse: Ladegeschwindigkeit.

Wie Sie sehen können, gibt es einen ziemlich stabilen Graphen, und die Durchschnittsgeschwindigkeit für den Ladeprozess variiert um 3,3-3,4 MB/s. Es gibt auch keine Anzeichen für eine abnehmende Ladegeschwindigkeit, wenn die Datenbankgröße größer als die RAM-Größe wird (nach Datenbank #5 mit einer Größe von 17,3 GB).

Leistung

Die Ladezeiten sehen also vielversprechend aus. Was ist mit den tatsächlichen Leistungsergebnissen?

Bevor wir zu den Leistungsergebnissen kommen, lassen Sie uns kurz den Simulationsprozess überprüfen.

Die Simulation führt 20 Threads aus, und jeder führt zufällig mehrere Geschäftsoperationen durch: neue Bestellung erstellen, Zahlung verarbeiten, Produkte auf Lager zählen, Bestelllieferung verarbeiten usw. (Details finden Sie in den SQL-Texten der tatsächlichen gespeicherten Prozeduren). Wie Sie sehen können, ist dies die übliche Reihe von Geschäftsoperationen einer abstrakten Inventar-/Verkaufsanwendung.

Die Testanwendung misst die Anzahl der Geschäftsoperationen pro Sekunde und meldet eine Durchschnittszahl. Natürlich ist diese Zahl ein künstlicher Parameter, aber sie ist gut genug für Vergleiche.

Leistungstestergebnisse:

#	Datenbankgröße, GB	Leistung bei SATA
1	9,04	494,73
2	10,80	491,94
3	13,00	480,36
4	15,50	469,11
5	17,30	446,42
6	19,90	431,61
7	21,60	426,85
8	24,20	424,5
9	26,00	414,04
10	28,60	409,14
11	30,30	407,97

Abbildung 5. Tabelle mit Leistungstestergebnissen.

Oder besser in grafischer Darstellung:

Abbildung 6. Leistungsergebnisdiagramm

Wie Sie sehen können, gibt es eine langsame Leistungsverschlechterung mit dem Wachstum der Datenbankgröße - je größer die Datenbank, desto langsamer arbeitet sie (auf derselben Hardware). Es gibt auch keinen großen Leistungsabfall, wenn die Datenbankgröße größer als der RAM wird. Das Wachstum der Datenbank von 9 GB auf 30 GB führt zu einem ungefähren Leistungsverlust von 20 %.

30-GB-Firebird-Datenbanken sind heutzutage überall, und sie wachsen und wachsen im Laufe der Zeit. Was wird jedoch mit der Datenbankleistierung passieren, wenn sie noch größer wird? Wir meinen - GRÖSSER! Was wird mit der Leistung passieren, wenn die Datenbank WIRKLICH GROSS wird?

Mr.Big

Um diese Frage zu beantworten, haben wir uns entschieden, das äußerste Ende der Testtabelle zu betrachten und einen Test mit einer 1,7-TB-Datenbank (1813 GB) auf derselben Hardware mit denselben Einstellungen durchzuführen.

Laden

Also haben wir eine solche Datenbank erstellt:

Abbildung 7. Datenbankgröße - jetzt mit 1813-GB-Datenbank

Das Laden dauerte 566448 Sekunden - 157 Stunden, 6,55 Tage. Das ist eine lange Zeit, aber die durchschnittliche Ladegeschwindigkeit war … 3,28 MB/s!

#	Datenbankgröße, GB	Ladezeit, Sek.	SATA-Ladegeschwindigkeit, MB/s
12	1813,969025	566448	3,279214122

Abbildung 8. Ladezeit und -geschwindigkeit für die 1,7-TB-Firebird-Datenbank

Im Diagramm sieht es sehr gut aus: der letzte Punkt (#12). Firebird zeigt also sehr gute Ergebnisse seiner Einfügealgorithmen.

Abbildung 9 Ladegeschwindigkeit - Punkt #12 ist für die 1,7-TB-Firebird-Datenbank

Leistung von Mr.Big

Dann haben wir denselben Leistungstest durchgeführt - Zeile 12 ist für die 1,7-TB-Datenbank.

#	Datenbankgröße, GB	Leistung bei SATA
1	9,04	494,73
2	10,80	491,94
3	13,00	480,36
4	15,50	469,11
5	17,30	446,42
6	19,90	431,61
7	21,60	426,85
8	24,20	424,5
9	26,00	414,04
10	28,60	409,14
11	30,30	407,97
12	1813,969025	169,33

Abbildung 10. Leistungstestergebnisse - Zeile 12 ist für die 1,7-TB-Datenbank

Und im Diagramm:


Abbildung 11. Leistung, Punkt #12 ist für die 1,7-TB-Datenbank

Das Ergebnis bestätigt, dass es eine langsame und stabile Leistungsverschlechterung in Firebird gibt - während die Datenbankgröße um das 60-fache gewachsen ist (von 30 GB auf 1813 GB), betrug der Leistungsverlust das 2,4-fache (von 407 auf 169 Punkte).

Es ist keine häufige Situation, dass eine Datenbank (auf derselben Low-End-Hardware) von 30 GB auf 1,7 TB wächst, aber Firebird wird auch in dieser Situation funktionieren.

Große Datenbank im Detail

Um die 1,7-TB-Datenbank besser zu verstehen, haben wir Datenbankstatistiken für die Mr.Big-Datenbank gesammelt und in IBAnalyst analysiert:

Abbildung 12 Tabellen der 1,7-TB-Datenbank in IBAnalyst

Wie Sie sehen können, gibt es 2 große Tabellen - ORDER_LINE (~600 GB) mit 6,3 Milliarden Datensätzen und STOCK (~680 GB) mit 2,1 Milliarden Datensätzen.

Und für diese Tabellen gibt es 2 Indizes mit Tiefe = 4 - das bedeutet, dass jede Anfrage 4 Lesevorgänge von Indexseiten durchführt, bevor die tatsächlichen Daten gelesen werden. Der ORDER_LINE_PK-Index hat eine Größe von 50 GB.

Abbildung 13. Indizes der Firebird-1,7-TB-Datenbank

Trotz der riesigen Anzahl von Datensätzen sieht die Datenbankstatistik gut aus, daher ist es nicht überraschend, dass Firebird auch für große Datenbanken auf Low-End-Hardware ziemlich gute Ergebnisse zeigt.

Testen von Firebird mit SSD-Laufwerk

Nach Abschluss der Reihe von Firebird-Tests auf Low-End-Hardware haben wir beschlossen, zu prüfen, welche Ergebnisse am anderen Ende der Datenspeichertechnologie erzielt werden, und haben ein SSD-Laufwerk auf demselben Server installiert.

Wir haben ein SSD-Laufwerk Plextor PX-256M M5 Pro installiert und dieselbe Testreihe (außer der 1,7-TB-Datenbank) mit denselben Einstellungen durchgeführt. Die Ergebnisse wurden zu den Diagrammen mit SATA-Geräten hinzugefügt, siehe unten.

Laden

Wie Sie sehen können, ist die Ladezeit bei SSD dieselbe wie bei SATA. Dies ist ein erwartetes Ergebnis: Die Geschwindigkeit sequenzieller Schreiboperationen ist bei SATA- und SSD-Laufwerken fast gleich.

Abbildung 14. Laden bei SSD und SATA

Leistung

Siehe Leistungsergebnisse:

Abbildung 15. Leistung bei SSD und SATA

Wie Sie sehen können, zeigt die Leistung bei zufälligen IO-Operationen ~8x bessere Ergebnisse für SSD-Laufwerke. Wir wussten aus unserer Erfahrung mit Kundendatenbanken, dass SSD bei realen Anwendungen 30-50 % schneller ist, aber eine 8-fache Steigerung ist sehr hoch.

Dieser Test ist jedoch künstlich und speziell darauf ausgelegt, hochbelastete OLTP-Operationen mit vielen Aktualisierungen/Löschungen, aber ohne große Abrufe zu simulieren. Eine übliche Datenbankanwendung arbeitet nicht die ganze Zeit in diesem Modus. Das erklärt, warum SSD in diesem speziellen Fall so hohe Ergebnisse zeigt.

Zusammenfassung

Was haben wir also aus diesen Tests gelernt?

Zunächst einmal - die Leistung von Firebird hat keine großen Abfälle im Zusammenhang mit einer Größenbeschränkung. Auf derselben Hardware wird die Leistung mit dem Wachstum der Datenbankgröße langsam abnehmen. Ein solcher Leistungsabfall kann durch die Anpassung der Firebird-Konfiguration oder durch ein intelligentes Hardware-Upgrade kompensiert werden.

Es ist ein guter Ort, um zu erwähnen, dass IBSurgeon einen Firebird-Leistungsoptimierungsdienst anbietet - unter Verwendung experimenteller Daten, die wir aus Tests wie diesen gesammelt haben, können wir die Leistung von Firebird- und InterBase-Datenbanken erheblich steigern.

Dann wussten wir, dass selbst sehr große Firebird-Datenbanken (1,7 Terabyte) auf Low-End-Hardware mit einem signifikanten, aber akzeptablen Leistungsverlust funktionieren.

Und drittens ist SSD wirklich gut für OLTP-Anwendungen. Wahrscheinlich ist es derzeit der günstigste Weg, die Datenbankleistung zu verbessern. Natürlich wird die Verwendung von SSD keine Probleme mit schlechten Abfrageplänen und ineffektiven Indizes beheben, aber sie kann die Leistung im Allgemeinen steigern.

Fortsetzung folgt: Weitere Details zur 1,7 Terabyte Firebird-Datenbank.