DBTrail fragt Open-Source-Datenbank in DuckDB ab und beschleunigt Berichte
Die Open-Source-relationale Datenbank ist sehr gut darin, die schnellen, kleinen Lese- und Schreibvorgänge zu bedienen, die Anwendungen benötigen, aber sie gerät in Schwierigkeiten, wenn jemand einen großen analytischen Bericht auf demselben Server ausführt. Ein Full-Table-Scan kann heiße Seiten aus dem Buffer Pool verdrängen, dem Speicherbereich, der häufig verwendete Daten enthält. Ein lang laufender Lesevorgang kann die Hintergrundbereinigung der Datenbank behindern, und ein GROUP BY über Millionen von Zeilen kann den Server dazu bringen, temporäre Tabellen auf die Festplatte zu schreiben. Die traditionelle Antwort ist eine Reporting-Replica, aber das bedeutet immer noch, einen weiteren Server derselben Datenbank zu betreiben, die eine zeilenorientierte Datenbank bleibt, also eine, die darauf ausgelegt ist, ganze Zeilen zu speichern und abzurufen, anstatt Spalten schnell zu scannen. Ein neues Open-Source-Tool namens DBTrail geht einen anderen Weg. Dieser Artikel berichtet über einen Benchmark von Vadim Tkachenko bei Percona, der Anfang Oktober 2026 veröffentlicht wurde.
DBTrail ist Open Source unter der Apache-2.0-Lizenz und wird von Daniel Guzman-Burgos entwickelt, der zuvor bei Percona als technischer Leiter für die Open-Source-relationale Datenbank tätig war. Es verbindet sich auf ähnliche Weise wie eine Replica mit der Open-Source-relationalen Datenbank. Zuerst erstellt es eine erste Kopie der Tabellen mit mydumper, einem Tool zum Dumpen dieser Datenbank, und speichert die Daten als Parquet-Dateien, ein kompaktes spaltenorientiertes Format, das analytische Engines schnell lesen können. Diese Dateien können lokal oder in S3 liegen. Danach liest DBTrail das Binärlog der Datenbank, die Aufzeichnung jeder Änderung an der Datenbank, und wendet diese Änderungen regelmäßig auf die Kopie an. Die resultierenden Daten fragen Sie mit DuckDB ab, einer In-Process-Analysedatenbank, die für schnelle Scans großer Dateien entwickelt wurde. Auf dem Datenbankserver wird nichts installiert: kein Plugin, kein Agent, kein Trigger. Das Setup lässt die Produktionsdatenbank unberührt.
Tkachenko testete dies mit drei AWS-Maschinen im selben Subnetz in us-west-2a. Die Quelle war eine r7i.4xlarge mit Percona Server 8.4.11-11, einer Distribution der Open-Source-relationalen Datenbank. DBTrail und DuckDB liefen auf einer zweiten r7i.4xlarge und der Lastgenerator auf einer c7i.2xlarge. Die Quell- und DBTrail-Maschinen hatten Intel Xeon Platinum 8488C CPUs mit 8 Kernen und 16 Threads, 128 GB Arbeitsspeicher und EBS-gp3-Speicher mit 16.000 IOPS und 1.000 MB/s. Die Lastmaschine hatte dieselbe CPU mit 4 Kernen und 8 Threads, 16 GB Arbeitsspeicher und Ubuntu 24.04.5. Die Arbeitslast war sysbench-tpcc, ein Benchmark, der einen Großhändler simuliert, mit 200 Warehouses. Das erzeugte zu Beginn 102 Millionen Zeilen und etwa 19 GB Daten. Der Test hielt die Arbeitslast bei 300 Transaktionen pro Sekunde (TPS). In diesem Benchmark entspricht eine TPC-C-Transaktion ungefähr 28 SQL-Anweisungen, was etwa 8.500 Abfragen pro Sekunde (QPS) und 5.200 Zeilenänderungen pro Sekunde bedeutet. Auf demselben Server, der mit 64 Threads und ohne weitere Anhänge voll ausgelastet lief, erreichte er 4.049 TPS oder etwa 115.000 QPS, sodass der 300-TPS-Test nur etwa 7 % der verfügbaren Kapazität nutzte. Die geringe Last war beabsichtigt, um zu sehen, was analytische Abfragen kosten, selbst wenn die Quelle viel Spielraum hat.
DBTrail wird mit einem Befehl installiert, der seinen Docker-Compose-Stack startet. Der Stack enthält zwei Container: DBTrail selbst und eine Instanz der Open-Source-relationalen Datenbank in Version 8.4.9, die als Index für Zeilenänderungen dient. Diese interne Instanz benötigt Aufmerksamkeit, da ihr Standard-Buffer-Pool der 128-MB-Standard dieser Datenbank ist, was für diese Arbeitslast viel zu klein ist. Für die Haupttests erhöhte Tkachenko ihn auf 48 GB, setzte die Redo-Log-Kapazität auf 16 GB und optimierte mehrere andere Einstellungen. DuckDB lief auf derselben Maschine mit seinen Standardeinstellungen: 16 Threads und einem Speicherlimit von 99 GB.
Verlangsamt DBTrail die Open-Source-relationale Datenbank? Die kurze Antwort ist: fast gar nicht. Die Last lief kontinuierlich und jede Phase wurde gemessen. Ohne Anhänge für 10 Minuten bediente die Quelldatenbank 299,9 TPS, 8.554 QPS und eine 95. Perzentil-Latenz von 41,9 ms. Mit DBTrail, das das Binärlog für 10 Minuten las, bediente sie 300,5 TPS, 8.535 QPS und 41,9 ms. Während der ersten Kopie aller Tabellen, die 4 Minuten 40 Sekunden dauerte, bediente sie 298,1 TPS und 8.460 QPS, mit einer medianen Latenz von 41,1 ms und einem schlechtesten 95. Perzentil von 41,1 ms außer einem Spike. Als die Kopie 75 Minuten lang alle 5 Minuten aktualisiert wurde, bediente sie 300,2 TPS und 8.539 QPS. Der Spike trat genau dann auf, als die erste Kopie begann, etwa bei Sekunde 1.500 der Arbeitslast. Das 95. Perzentil der Latenz sprang auf 119 ms und der Durchsatz fiel für diese eine Sekunde auf 271 Transaktionen. Dies entspricht einer kurzen globalen Lesesperre, die die erste Kopie beim Start nimmt. Danach las DBTrail 102 Millionen Zeilen in weniger als fünf Minuten ohne messbare Verlangsamung der Anwendungslast. CPU-Bestätigung: Die Quelle lag normalerweise bei etwa 18 % CPU, stieg während der ersten Tabellenkopie auf etwa 35 % und lag bei etwa 24 %, als die fünf analytischen Berichte direkt gegen die Quelldatenbank ausgeführt wurden. Die DBTrail-Maschine selbst schreibt ungefähr so viel wie die Quelle, da sie einen Index jeder erfassten Zeilenänderung führt.
DBTrail erstellt eine views.sql-Datei, die eine DuckDB-Ansicht für jede Quelltabelle enthält. Von dort aus können Sie die Daten normal mit SQL abfragen. Es wurden zwei Benchmark-Sätze durchgeführt. Zuerst wurden auf den TPC-C-Daten, nachdem sie von 102 Millionen auf 113 Millionen Zeilen angewachsen waren, fünf Berichte gegen die Quelldatenbank und DuckDB ausgeführt, während die transaktionale Arbeitslast weiterging. Die Quelldatenbank hatte im Wesentlichen alles im Speicher zwischengespeichert, und die DBTrail-Kopie war in ihrem normalen Zustand: eine Basis-Parquet-Datei plus angesammelte Änderungsdateien, die DuckDB bei einer Abfrage kombinieren muss. Die Gesamtzeit für alle fünf Berichte betrug 6 Minuten 35 Sekunden auf der Quelldatenbank und 5,7 Sekunden auf DuckDB. Einzeln: Umsatz pro Warehouse ging von 9,7 Sekunden auf 0,75 Sekunden; Bestellungen und Umsatz pro Distrikt und Monat von 46,5 Sekunden auf 2,8 Sekunden; die zehn meistverkauften Artikel von 5 Minuten 32 Sekunden auf 1,7 Sekunden; Kunden nach Bundesstaat und Kredit von 3,6 Sekunden auf 0,18 Sekunden; und Warehouses mit niedrigem Lagerbestand von 3,0 Sekunden auf 0,23 Sekunden.
Der zweite Benchmark verwendete TPC-H, eine standardisierte analytische Arbeitslast, mit Skalierungsfaktor 10. Dieser Datensatz enthielt 86,6 Millionen Zeilen und 18,2 GB InnoDB-Daten, mit normalen Indizes auf Join-Schlüsseln, Bestelldaten und Versanddaten. Die erste DBTrail-Kopie dauerte 6 Minuten 26 Sekunden und erzeugte 2,8 GB Parquet-Dateien. Alle 22 TPC-H-Abfragen wurden gegen beide Systeme ausgeführt. Die Quelldatenbank benötigte 5 Minuten 24 Sekunden; DuckDB mit warmem Cache benötigte 10,3 Sekunden. Die Quelldatenbank gewann nur bei Q19, weil ein Index direkt zu den relevanten Zeilen gehen kann, und Q17 war praktisch ein Unentschieden. Für den Rest war DuckDB erheblich schneller. Teil 2 des Percona-Berichts wird untersuchen, wie oft DBTrail Daten aktualisiert, um aktuell zu bleiben.
Für Teams, die die Open-Source-relationale Datenbank betreiben und gelegentlich analytische Berichte benötigen, beseitigt dieses Muster die Notwendigkeit, eine vollständige Datenpipeline in eine separate analytische Datenbank aufzubauen und zu betreiben. Es vermeidet auch das Risiko, dass ein Ad-hoc-Bericht eine Produktionsdatenbank destabilisiert. Organisationen, die diese Trennung wünschen, können ihre produktive relationale Datenbankquelle von einem verwalteten Cloud- und Dateninfrastrukturanbieter wie AEU Data betreiben lassen, der automatisierte Backups, Überwachung und Hochverfügbarkeit bereitstellt, sodass die analytische Kopie sicher angebunden werden kann, während die Quelle geschützt bleibt. Dies ist eine Berichterstattung über einen Drittanbieter-Benchmark; AEU Data hat die Tests nicht durchgeführt und DBTrail nicht entwickelt.