1-TB-Firebird-Datenbank: Vorläufiger Bericht
Dmitry Kuzmenko, letzte Aktualisierung 31-03-2014
Übersetzungen dieses Dokuments: Portugiesisch Russisch Chinesisch
Lesen Sie unseren Artikel über eine noch größere (1,7 Terabyte) Datenbank: Weitere Details zur 1,7 Terabyte Firebird SQL Datenbank.
Warum eine Terabyte-Firebird-Datenbank erstellen?
Viele Unternehmen arbeiten mit großen Firebird-Datenbanken und verlassen sich auf sie, um wichtige Geschäftsabläufe zu unterstützen. Einige Firebird-Datenbanken sind bereits hunderte Gigabyte groß und wachsen weiter (siehe Abschnitt „Wer ist groß?"), und es ist leicht vorherzusagen, wann sie 2, 3 oder 5 Mal größer werden. Daher sind Datenbankadministratoren und Anbieter daran interessiert, das Verhalten von Firebird mit großen Datenbanken zu untersuchen und Empfehlungen zur Verwaltung zu erhalten.
Ein weiterer wichtiger Grund, den wir bei der Erstellung der 1-TB-Firebird-Datenbank im Hinterkopf hatten, war die endgültige Beseitigung der weit verbreiteten Wahrnehmung von Firebird als Datenbank-Engine für „kleine Datenbanken". Dieser Mythos scheint jetzt tot zu sein, aber einige Analysten und Journalisten holen ihn regelmäßig aus dem Grab hervor, und wir hoffen, mit dieser lächerlichen Wahrnehmung endlich Schluss zu machen.
| ## Hardware |
Firebird ist bekannt für seine unglaubliche Skalierbarkeit, und diese Untersuchung hat dies erneut bestätigt. Der ursprüngliche Zweck dieses Experiments war nur die Erstellung einer Firebird-Datenbank mit 1 TB Größe, daher verwendeten wir einen gewöhnlichen Desktop-Computer:
Tabelle 1: Hardware
| Komponente | Parameter |
| CPU | AMDAthlon 64 x2 5200 |
| RAM | 4 GB |
| Motherboard | MSI K9N Platinum |
| HDD1 (Betriebssystem und temporär) | ST3160815AS, 160 GB, SATA II |
| HDD2 (Hilfslaufwerk) | HDT721064SLA360, 640 GB, SATA II |
| HDD2 (Hilfslaufwerk) | HDS728080PLA380, 80 GB, SATA I |
| HDD3 (Datenbank) | ST31500341AS, 1,5 TB, SATA II (Firmware CC1H) |
Im Wesentlichen haben wir die 1,5-TB-Festplatte in einen unserer Büro-Desktops eingebaut, ohne weitere Änderungen. Diese Festplatte wurde mit einer Clustergröße von 16 KB formatiert (derselben wie die Seitengröße der Datenbank, wie Sie unten sehen können).
Software
Da es sich um einen Desktop-Computer handelt, ist das Betriebssystem Windows XP Professional SP3, 32-Bit. Für den eigentlichen Test verwendeten wir den Loader aus dem TPC-basierten Toolkit (Download unter http://ibdeveloper.com/tests/tpc-c/, sowohl Binärdateien als auch Quellen sind verfügbar).
Wir möchten betonen, dass der Loader Daten so einfügt, wie sie in einem realen Szenario eingefügt würden: Datensätze werden eingefügt und in der Datenbank (und an physischen Speicherorten) in mehreren Master-Detail-Subdetail-Tabellen platziert, nicht Tabelle für Tabelle.
Tabelle 2: Software
| Software | Version |
| Betriebssystem | Windows XP Professional SP3, 32-Bit |
| Firebird | 2.1.3 SuperServer (Snapshot) |
| Loader | Benutzerdefinierter Loader aus dem tpc-basierten Test |
Plan
Wir hatten einen sehr einfachen Plan für dieses Experiment:
- Datenbank erstellen und mit 1 TB Daten laden, ohne Indizes
- Primärschlüssel und geeignete Indizes erstellen (die Datenbankgröße ist also tatsächlich größer als 1 TB)
- Datenbankstatistiken sammeln
- Mehrere SQL-Abfragen ausführen und die Datenbankleistung bewerten
Datenbank- und Firebird-Serverkonfiguration
Die Datenbank hat eine Seitengröße von 16384 Bytes, dieselbe wie der HDD-Cluster, um den Festplattendurchsatz zu maximieren (1 Seite pro E/A-Zyklus zu lesen/schreiben).
In der Firebird-Konfiguration haben wir ein zusätzliches Verzeichnis für den temporären Speicher konfiguriert und es auf die Festplatte mit 640 GB gelegt (wo ~300 GB frei waren).
Ladevorgang
Die Daten wurden in mehreren Schritten in diese Datenbank geladen. Der Computer wurde während der Ladevorgänge als normaler Desktop verwendet (wir hatten MS Office, Firefox, IBAnalyst usw. - etwa 8-12 Programme liefen gleichzeitig). Wenn wir die Hardware nur für diese Aufgabe gewidmet hätten, wäre es wahrscheinlich schneller gewesen, also betrachten Sie diese Werte bitte nur als ein Beispiel für die untere Grenze; sie sind definitiv nicht die Spitzenergebnisse.
Tabelle 3: Ladevorgänge
| |
| Beschreibung | Wert |
| Zeit zum Laden | ~70 Stunden |
| Insgesamt eingefügte Datensätze | 6,2 Milliarden |
| Durchschnittliche Einfügegeschwindigkeit | 24500 Datensätze/Sekunde |
| Durchschnittliche Datensatzgröße | 146 Bytes (min 13 Bytes, max - 600 Bytes) |
| Transaktionen | 646489 |
Wir verbrachten ~4 Tage mit dem Laden, und danach hatten wir eine Firebird-Datenbank mit genau 1 TB Größe (d. h. 1 099 900 125 184 Bytes).
Unten sehen Sie das Datenbankwachstum und die Transaktionsdynamik im FBDataGuard Viewer:
Indizes
Wir haben die Indizes nacheinander erstellt und die Erstellungszeit sowie die Größe der für die Sortierung verwendeten temporären Datei gezählt.
Der größte Index wurde für die Tabelle ORDER_LINE erstellt. Ihr Primärschlüssel enthält vier Felder (Smallint, Smallint, Integer und Smallint). Die temporäre Datei für diesen Sortierindex war 182 GB groß, und die endgültige Indexgröße in der Datenbank beträgt 29,3 GB.
Es ist interessant zu sehen, dass selbst der Index für eine Tabelle mit 3,8 Milliarden Datensätzen eine Tiefe von 3 hat, da die Seitengröße 16384 Bytes betrug, sodass bei der Suche nach Daten über den Primärschlüssel für diese Tabelle kein Overhead entsteht.
Statistiken
Danach haben wir die Datenbankstatistiken gesammelt. Es dauerte 7 Stunden 32 Minuten 45 Sekunden.
Wir haben die wichtigsten Statistikinformationen in einer Tabelle zusammengefasst und einige Abfragen und Zeitmessungen eingefügt:
Tabelle 4: Konsolidierte Statistiken für die 1-TB-Datenbank
| Tabellenname | Datensatzanzahl | Größe, GB | Ausführungszeit von select count(*) | Indexerstellungszeit | Tmp-Dateigröße, GB | Indexgröße, GB |
| WAREHOUSE | 1240 | 0,002 | 0s | 0 | 0 | 0,0 |
| ITEM | 100000 | 0,012 | 0,7s | - | - | 0,0 |
| DISTRICT | 124000 | 0,017 | 0,7s | 6 | - | 0,0 |
| NEW_ORDER | 111600000 | 32 | 20m 00s | 23m 00s | 4,56 | 0,8 |
| CUSTOMER | 372000000 | 224 | - | 41m 00s | - | 2,6 |
| customer_last | 1h 52m 32s | 12,4 | 2,3 | |||
| fk_cust_ware | 2h 10m 51s | - | 2,3 | |||
| HISTORY | 372000000 | 32 | - | - | - | - |
| ORDERS | 372000000 | 25 | 32m 00s | 45m 41s | 15,2 | 2,5 |
| STOCK | 1240000000 | 404 | - | 3h 34m 44s | 41,5 | 9,2 |
| ORDER_LINE | 3720051796 | 359 | - | 12h 6m 18s | 182,0 | 29,3 |
Die Datenbankstatistiken können von hier heruntergeladen werden.
Sie können den kostenlosen FBDataGuard Community Edition Viewer verwenden, um Textdaten zu interpretieren und nicht nur Datenbankleistungsmetriken, sondern auch CPU- und Speicherverbrauch zu sehen.
Abfragen
Zunächst haben wir select count(*)-Abfragen auf mehreren Tabellen ausgeführt (siehe 4. Spalte in Tabelle 4 oben). Wie Sie wissen, ist select count(*) für die gesamte Tabelle aufgrund der Multi-Version-Natur von Firebird eine teure Operation für den Server, da sie den Besuch jeder Seite erfordert, und erfahrene Firebird-Entwickler verwenden kein select count(*), aber wir haben es verwendet, um das allgemeine Leistungsverhältnis von Datenbank und Hardware zu demonstrieren.
Nach den select count-Abfragen haben wir Abfragen aus einem realen Szenario ausgeführt, und um ehrlich zu sein, waren wir von so guten Ergebnissen erstaunt. Sehen Sie selbst:
| Abfrage | Statistiken | Beschreibung |
| select w_id, w_name, c_id, c_last from WAREHOUSE, customer where c_w_id = w_id |
PLAN JOIN (WAREHOUSE NATURAL, CUSTOMER INDEX (FK_CUST_WARE)) ------ Leistungsinfo —— Vorbereitungszeit = 15ms Ausführungszeit = 79ms Durchschnittliche Abrufzeit = 6,08 ms Aktueller Speicher = 272 264 476 Max. Speicher = 272 514 048 Speicherpuffer = 16 384 Lesevorgänge von Festplatte in Cache = 82 Schreibvorgänge von Cache auf Festplatte = 0 Abrufe aus Cache = 3 648 |
Einfacher Join von Tabellen mit 12400 und 372000000 Datensätzen, keine WHERE-Bedingungen. „Durchschnittliche Abrufzeit = 6,08 ms" gilt für das Abrufen der ersten Zeile. |
| select w_id, w_name, c_id, c_last from WAREHOUSE, customer where c_w_id = w_id and c_w_id = 10000 |
PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE)) ------ Leistungsinfo —— Vorbereitungszeit = 16ms Ausführungszeit = 78ms Durchschnittliche Abrufzeit = 6,00 ms Aktueller Speicher = 272 266 148 Max. Speicher = 272 514 048 Speicherpuffer = 16 384 Lesevorgänge von Festplatte in Cache = 88 Schreibvorgänge von Cache auf Festplatte = 0 Abrufe aus Cache = 3 656 |
Join derselben Tabellen mit einer Bedingung, die die Auswahl aktueller Datensätze erzwingt. „Durchschnittliche Abrufzeit = 6,00 ms" gilt für das Abrufen der ersten Zeile. |
| select count(*) from WAREHOUSE, customer where c_w_id = w_id and c_w_id = 10000 Ergebnis = 30000 |
PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE)) ------ Leistungsinfo —— Vorbereitungszeit = 0ms Ausführungszeit = 453ms Durchschnittliche Abrufzeit = 453,00 ms Aktueller Speicher = 272 263 844 Max. Speicher = 272 514 048 Speicherpuffer = 16 384 Lesevorgänge von Festplatte in Cache = 1 048 Schreibvorgänge von Cache auf Festplatte = 0 Abrufe aus Cache = 60 024 |
Datensätze für die vorherige Abfrage zählen |
| SELECT * FROM ORDER_LINE WHERE OL_W_ID = 500 |
Plan PLAN (ORDER_LINE INDEX (ORDER_LINE_PK)) ------ Leistungsinfo —— Vorbereitungszeit = 0ms Ausführungszeit = 94ms Durchschnittliche Abrufzeit = 7,23 ms Aktueller Speicher = 136 445 536 Max. Speicher = 136 592 176 Speicherpuffer = 8 192 Lesevorgänge von Festplatte in Cache = 150 Schreibvorgänge von Cache auf Festplatte = 0 Abrufe aus Cache = 2 402 |
Abfrage an die größte Tabelle (3,8 Mrd. Datensätze). „Durchschnittliche Abrufzeit = 7,23 ms" gilt für das Abrufen der ersten Zeile. |
<br>Plan<br><br>PLAN (ORDER_LINE INDEX (ORDER_LINE_PK))<br><br> <br><br>------ Leistungsinfo ------<br><br>Vorbereitungszeit = 0ms<br><br>Ausführungszeit = 3s 438ms<br><br>Durchschnittliche Abrufzeit = 0,01 ms<br><br>Aktueller Speicher = 136 445 496<br><br>Max. Speicher = 136 592 176<br><br>Speicherpuffer = 8 192<br><br>Lesevorgänge von Festplatte in Cache = 1 840<br><br>Schreibvorgänge von Cache auf Festplatte = 0<br><br>Abrufe aus Cache = 598 636<br> |
| SELECT * FROM ORDER_LINE
WHERE OL_W_ID = 500 | Dieselbe Abfrage auf die größte Tabelle (3,8 Mrd. Datensätze), aber diesmal haben wir alle Datensätze abgerufen (299.245 Datensätze abgerufen). |
| | |
| select w_id, w_name, c_id, c_last
from WAREHOUSE, customer
where c_w_id = w_id and (c_w_id > 8000) and (c_w_id < 10000) | Plan
PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE))
------ Leistungsinformationen ——
Vorbereitungszeit = 0ms
Ausführungszeit = 125ms
Durchschnittliche Abrufzeit = 9,62 ms
Aktueller Speicher = 272 270 824
Maximaler Speicher = 272 514 048
Speicherpuffer = 16 384
Lesevorgänge von Festplatte in Cache = 91
Schreibvorgänge von Cache auf Festplatte = 0
Abrufe aus dem Cache = 3 659 | Tabellen mit 1.240 Datensätzen und 372 Mio. Datensätzen verknüpfen. |
| select count(*)
from WAREHOUSE, customer
where c_w_id = w_id and (c_w_id > 8000) and (c_w_id < 10000)
Ergebnis = 59 970 000 | Plan
PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE))
------ Leistungsinformationen ——
Vorbereitungszeit = 0ms
Ausführungszeit = 13m 4s 718ms
Durchschnittliche Abrufzeit = 784 718,00 ms
Aktueller Speicher = 272 268 532
Maximaler Speicher = 272 514 048
Speicherpuffer = 16 384
Lesevorgänge von Festplatte in Cache = 2 332 583
Schreibvorgänge von Cache auf Festplatte = 0
Abrufe aus dem Cache = 119 977 902 | Datensätze für die vorherige Abfrage zählen |
Zusammenfassung
In diesem Experiment zeigt Firebird die folgenden Ergebnisse
-
Zweifellose Fähigkeit, große Datenbanken zu verwalten. Wir sind uns ziemlich sicher, dass es möglich ist, eine 32-TB-Datenbank auf geeigneter Hardware zu erstellen und zu verwenden, und Firebird wird dieselbe hohe Leistung zeigen wie bei kleineren Datenbanken (d. h. 1 TB und darunter).
-
Gute Skalierbarkeit und erstaunlich kleiner Fußabdruck. Die 1-TB-Datenbank wurde auf einem normalen Desktop-Computer erstellt und, was noch wichtiger ist, sie kann für allgemeine Abfragen verwendet werden: Wenn Sie nicht Millionen von Datensätzen abrufen, ist die Abfragegeschwindigkeit dieselbe wie bei Datenbanken mittlerer Größe (10-15 GB).
Dies ist nicht das Ende dieses Experiments: Wir beabsichtigen, einige Abfragen auszuführen, zusätzliche Statistiken zu sammeln und in Kürze einen detaillierteren Bericht zu veröffentlichen. Bitte bleiben Sie dran.
Kontakte
Senden Sie alle Ihre Fragen und Anfragen an [email protected]