DBTrail interroga il database open-source in DuckDB e accelera i report
Il database relazionale open-source è molto bravo a servire le letture e scritture piccole e veloci di cui le applicazioni hanno bisogno, ma si mette nei guai quando qualcuno esegue un report analitico di grandi dimensioni sullo stesso server. Una scansione completa della tabella può spingere fuori le pagine calde dal buffer pool, l'area di memoria che contiene i dati usati di frequente. Una lettura di lunga durata può rallentare la pulizia in background del database, e un GROUP BY su milioni di righe può far scrivere al server tabelle temporanee su disco. La risposta tradizionale è una replica di report, ma questo significa comunque eseguire un altro server dello stesso database, che rimane un database orientato alle righe, costruito per memorizzare e recuperare righe intere piuttosto che per scansionare rapidamente le colonne. Un nuovo strumento open-source chiamato DBTrail segue una strada diversa. Questo articolo riporta un benchmark di Vadim Tkachenko di Percona, pubblicato all'inizio di ottobre 2026.
DBTrail è open source sotto licenza Apache 2.0 ed è sviluppato da Daniel Guzman-Burgos, che in precedenza ha lavorato in Percona come technical lead per il database relazionale open-source. Si connette al database relazionale open-source in modo simile a una replica. Prima fa una copia iniziale delle tabelle usando mydumper, uno strumento per il dump di quel database, e memorizza i dati come file Parquet, un formato compatto orientato alle colonne che i motori analitici possono leggere rapidamente. Questi file possono risiedere localmente o in S3. Dopo di che, DBTrail legge il binary log del database, il registro di ogni modifica apportata al database, e periodicamente applica queste modifiche alla copia. Si interrogano i dati risultanti con DuckDB, un database analitico in-process progettato per scansioni veloci di file di grandi dimensioni. Non viene installato nulla all'interno del server del database: nessun plugin, agente o trigger. La configurazione mantiene intatto il database di produzione.
Tkachenko ha testato questo usando tre macchine AWS nella stessa subnet in us-west-2a. La sorgente era una r7i.4xlarge con Percona Server 8.4.11-11, una distribuzione del database relazionale open-source. DBTrail e DuckDB giravano su una seconda r7i.4xlarge, e il generatore di carico su una c7i.2xlarge. Le macchine sorgente e DBTrail avevano CPU Intel Xeon Platinum 8488C con 8 core e 16 thread, 128 GB di memoria e storage EBS gp3 con 16.000 IOPS e 1.000 MB/s. La macchina di carico aveva la stessa CPU con 4 core e 8 thread, 16 GB di memoria e Ubuntu 24.04.5. Il carico di lavoro era sysbench-tpcc, un benchmark che simula un fornitore all'ingrosso, con 200 magazzini. Questo ha prodotto 102 milioni di righe e circa 19 GB di dati all'inizio. Il test ha mantenuto il carico di lavoro a 300 transazioni al secondo (TPS). In questo benchmark, una transazione TPC-C corrisponde a circa 28 istruzioni SQL, il che significa circa 8.500 query al secondo (QPS) e 5.200 modifiche di riga al secondo. Sullo stesso server alla massima potenza con 64 thread e nient'altro collegato, ha raggiunto 4.049 TPS, ovvero circa 115.000 QPS, quindi il test a 300 TPS usava solo circa il 7% della capacità disponibile. Il carico leggero era intenzionale, per vedere quanto costano le query analitiche anche quando la sorgente ha ampio margine.
DBTrail si installa con un comando che avvia il suo stack Docker Compose. Lo stack contiene due container: DBTrail stesso e un'istanza versione 8.4.9 del database relazionale open-source usata come indice delle modifiche alle righe. Quell'istanza interna richiede attenzione perché il suo buffer pool predefinito è quello di 128 MB del database, che è decisamente troppo piccolo per questo carico di lavoro. Per i test principali, Tkachenko lo ha aumentato a 48 GB, ha impostato la capacità del redo log a 16 GB e ha ottimizzato diverse altre impostazioni. DuckDB girava sulla stessa macchina con i suoi valori predefiniti: 16 thread e un limite di memoria di 99 GB.
DBTrail rallenta il database relazionale open-source? La risposta breve è quasi per niente. Il carico è stato eseguito in continuazione e ogni fase è stata misurata. Senza nulla collegato per 10 minuti, il database sorgente ha servito 299,9 TPS, 8.554 QPS e una latenza al 95° percentile di 41,9 ms. Con DBTrail che leggeva il binary log per 10 minuti, ha servito 300,5 TPS, 8.535 QPS e 41,9 ms. Durante la copia iniziale di tutte le tabelle, che ha richiesto 4 minuti e 40 secondi, ha servito 298,1 TPS e 8.460 QPS, con latenza mediana di 41,1 ms e un peggiore 95° percentile di 41,1 ms tranne un picco. Quando la copia veniva aggiornata ogni 5 minuti per 75 minuti, ha servito 300,2 TPS e 8.539 QPS. Il picco si è verificato esattamente quando è iniziata la copia iniziale, intorno al secondo 1.500 del carico di lavoro. La latenza al 95° percentile è saltata a 119 ms e il throughput è sceso a 271 transazioni per quel singolo secondo. Questo corrisponde a un breve blocco di lettura globale che la copia iniziale acquisisce all'avvio. Dopo di che, DBTrail ha letto 102 milioni di righe in meno di cinque minuti senza alcun rallentamento misurabile nel carico di lavoro dell'applicazione. Conferma della CPU: la sorgente normalmente stava intorno al 18% di CPU, aumentava a circa il 35% durante la copia iniziale della tabella e stava intorno al 24% quando i cinque report analitici venivano eseguiti direttamente contro il database sorgente. La macchina DBTrail stessa scrive più o meno quanto la sorgente perché mantiene un indice di ogni modifica di riga catturata.
DBTrail crea un file views.sql contenente una vista DuckDB per ogni tabella sorgente. Da lì si possono interrogare i dati normalmente con SQL. Sono stati eseguiti due set di benchmark. Prima, sui dati TPC-C dopo che erano cresciuti da 102 milioni a 113 milioni di righe, cinque report sono stati eseguiti contro il database sorgente e DuckDB mentre il carico di lavoro transazionale continuava. Il database sorgente aveva essenzialmente tutto in cache in memoria, e la copia DBTrail era nel suo stato normale: un file Parquet di base più file di modifiche accumulati che DuckDB deve combinare quando esegue una query. Il tempo totale per tutti e cinque i report è stato di 6 minuti e 35 secondi sul database sorgente e 5,7 secondi su DuckDB. Individualmente, il fatturato per magazzino è passato da 9,7 secondi a 0,75 secondi; ordini e fatturato per distretto e mese da 46,5 secondi a 2,8 secondi; i dieci articoli più venduti da 5 minuti e 32 secondi a 1,7 secondi; clienti per stato e credito da 3,6 secondi a 0,18 secondi; e magazzini con scorte basse da 3,0 secondi a 0,23 secondi.
Il secondo benchmark ha usato TPC-H, un carico di lavoro analitico standard, a fattore di scala 10. Quel dataset conteneva 86,6 milioni di righe e 18,2 GB di dati InnoDB, con indici normali sulle chiavi di join, le date degli ordini e le date di spedizione. La copia iniziale di DBTrail ha richiesto 6 minuti e 26 secondi e ha prodotto 2,8 GB di file Parquet. Tutte le 22 query TPC-H sono state eseguite su entrambi i sistemi. Il database sorgente ha impiegato 5 minuti e 24 secondi; DuckDB, con cache calda, ha impiegato 10,3 secondi. Il database sorgente ha vinto solo la Q19 perché un indice può andare direttamente alle righe rilevanti, e la Q17 è stata di fatto un pareggio. Per il resto, DuckDB è stato sostanzialmente più veloce. La parte 2 del report di Percona esaminerà quanto spesso DBTrail aggiorna i dati per rimanere aggiornato.
Per i team che eseguono il database relazionale open-source e occasionalmente hanno bisogno di report analitici, questo schema elimina la necessità di costruire e gestire una pipeline di dati completa verso un database analitico separato. Evita anche il rischio che un report ad hoc destabilizzi un database di produzione. Le organizzazioni che desiderano questa separazione possono far eseguire il loro database relazionale di produzione da un provider di cloud e infrastruttura dati gestito come AEU Data, che fornisce backup automatici, monitoraggio e alta disponibilità, in modo che la copia analitica possa essere collegata in sicurezza mentre la sorgente rimane protetta. Questo è un report su un benchmark di terze parti; AEU Data non ha eseguito i test né costruito DBTrail.