DBTrail kërkon në bazën e të dhënave me burim të hapur në DuckDB dhe shpejton raportet
Baza e të dhënave relacionale me burim të hapur është shumë e mirë në shërbimin e leximeve dhe shkrimeve të shpejta dhe të vogla që u duhen aplikacioneve, por has telashe kur dikush ekzekuton një raport të madh analitik në të njëjtin server. Një skanim i plotë i tabelës mund të nxjerrë faqet e nxehta nga buffer pool, zona e memories që mban të dhënat e përdorura shpesh. Një lexim i gjatë mund të mbajë prapa pastrimin në sfond të bazës së të dhënave, dhe një GROUP BY mbi miliona rreshta mund ta detyrojë serverin të shkruajë tabela të përkohshme në disk. Përgjigjja tradicionale është një replikë raportimi, por kjo ende ekzekuton një server tjetër të së njëjtës bazë të dhënash, e cila mbetet një bazë e dhënash e orientuar nga rreshtat, e ndërtuar për të ruajtur dhe marrë rreshta të plotë në vend që të skanojë kolonat shpejt. Një mjet i ri me burim të hapur i quajtur DBTrail ndjek një rrugë tjetër. Ky artikull raporton mbi një krahasim nga Vadim Tkachenko në Percona, botuar në fillim të tetorit 2026.
DBTrail është me burim të hapur nën licencën Apache 2.0 dhe po ndërtohet nga Daniel Guzman-Burgos, i cili më parë punoi në Percona si udhëheqës teknik për bazën e të dhënave relacionale me burim të hapur. Ai lidhet me bazën e të dhënave relacionale me burim të hapur në mënyrë të ngjashme me një replikë. Së pari bën një kopje fillestare të tabelave duke përdorur mydumper, një mjet për nxjerrjen e asaj baze të dhënash, dhe i ruan të dhënat si skedarë Parquet, një format kompakt i orientuar nga kolonat që motorët analitikë mund ta lexojnë shpejt. Këta skedarë mund të jenë lokalisht ose në S3. Pas kësaj, DBTrail lexon binary log-un e bazës së të dhënave, regjistrin e çdo ndryshimi të bërë në bazën e të dhënave, dhe periodikisht i zbaton ato ndryshime në kopje. Ju i pyetni të dhënat që rezultojnë me DuckDB, një bazë të dhënash analitike brenda procesit e projektuar për skanime të shpejta të skedarëve të mëdhenj. Asgjë nuk instalohet brenda serverit të bazës së të dhënave: as shtojcë, as agjent, as shkaktar. Konfigurimi e mban bazën e të dhënave të prodhimit të paprekur.
Tkachenko e testoi këtë duke përdorur tre makina AWS në të njëjtin nënrrjet në us-west-2a. Burimi ishte një r7i.4xlarge që ekzekutonte Percona Server 8.4.11-11, një shpërndarje e bazës së të dhënave relacionale me burim të hapur. DBTrail dhe DuckDB ekzekutoheshin në një r7i.4xlarge të dytë, dhe gjeneruesi i ngarkesës në një c7i.2xlarge. Makinat burim dhe DBTrail kishin CPU Intel Xeon Platinum 8488C me 8 bërthama dhe 16 fije, 128 GB memorie, dhe ruajtje EBS gp3 me 16,000 IOPS dhe 1,000 MB/s. Makina e ngarkesës kishte të njëjtin CPU me 4 bërthama dhe 8 fije, 16 GB memorie, dhe Ubuntu 24.04.5. Ngarkesa ishte sysbench-tpcc, një krahasim që simulon një furnizues me shumicë, me 200 depo. Kjo prodhoi 102 milionë rreshta dhe rreth 19 GB të dhëna në fillim. Testi e mbajti ngarkesën në 300 transaksione për sekondë (TPS). Në këtë krahasim, një transaksion TPC-C është afërsisht 28 deklarata SQL, që do të thotë rreth 8,500 pyetje për sekondë (QPS) dhe 5,200 ndryshime rreshtash për sekondë. Në të njëjtin server që punonte me kapacitet të plotë me 64 fije dhe asgjë tjetër të lidhur, ai arriti 4,049 TPS, ose rreth 115,000 QPS, kështu që testi 300 TPS përdori vetëm rreth 7% të kapacitetit të disponueshëm. Ngarkesa e lehtë ishte e qëllimshme, për të parë se çfarë kushtojnë pyetjet analitike edhe kur burimi ka shumë hapësirë.
DBTrail instalohet me një komandë që nis stivën e tij Docker Compose. Stiva përmban dy kontejnerë: vetë DBTrail dhe një instancë të versionit 8.4.9 të bazës së të dhënave relacionale me burim të hapur e përdorur si indeks i ndryshimeve të rreshtave. Ajo instancë e brendshme ka nevojë për vëmendje sepse buffer pool-i i saj i parazgjedhur është 128 MB i asaj baze të dhënash, që është shumë i vogël për këtë ngarkesë. Për testet kryesore, Tkachenko e rriti atë në 48 GB, vendosi kapacitetin e redo log në 16 GB, dhe rregulloi disa cilësime të tjera. DuckDB ekzekutohej në të njëjtën makinë me parazgjedhjet e tij: 16 fije dhe një kufi memorie prej 99 GB.
A e ngadalëson DBTrail bazën e të dhënave relacionale me burim të hapur? Përgjigjja e shkurtër është pothuajse aspak. Ngarkesa vazhdoi pa ndërprerje, dhe çdo fazë u mat. Me asgjë të lidhur për 10 minuta, baza e të dhënave burim shërbeu 299.9 TPS, 8,554 QPS, dhe një latencë të përqindjes së 95-të prej 41.9 ms. Me DBTrail që lexonte binary log-un për 10 minuta, ajo shërbeu 300.5 TPS, 8,535 QPS, dhe 41.9 ms. Gjatë kopjimit fillestar të të gjitha tabelave, që zgjati 4 minuta e 40 sekonda, ajo shërbeu 298.1 TPS dhe 8,460 QPS, me latencë mesatare 41.1 ms dhe një përqindje të 95-të më të keqe prej 41.1 ms përveç një rritjeje të papritur. Kur kopja rifreskohej çdo 5 minuta për 75 minuta, ajo shërbeu 300.2 TPS dhe 8,539 QPS. Rritja e papritur ndodhi pikërisht kur filloi kopjimi fillestar, rreth sekondës 1,500 të ngarkesës. Latenca e përqindjes së 95-të u hodh në 119 ms dhe xhiroja ra në 271 transaksione për atë sekondë. Kjo përputhet me një bllokim të shkurtër global të leximit që kopjimi fillestar e merr kur fillon. Pas kësaj, DBTrail lexoi 102 milionë rreshta në më pak se pesë minuta pa ndonjë ngadalësim të matshëm në ngarkesën e aplikacionit. Konfirmim i CPU-së: burimi normalisht qëndronte rreth 18% CPU, u rrit në rreth 35% gjatë kopjimit fillestar të tabelave, dhe ishte rreth 24% kur pesë raportet analitike u ekzekutuan drejtpërdrejt kundër bazës së të dhënave burim. Vetë makina DBTrail shkruan afërsisht po aq sa burimi sepse mban një indeks të çdo ndryshimi të kapur rreshti.
DBTrail krijon një skedar views.sql që përmban një pamje DuckDB për çdo tabelë burimi. Prej andej ju mund t'i pyetni të dhënat normalisht me SQL. Dy grupe krahasimesh u ekzekutuan. Së pari, mbi të dhënat TPC-C pasi ishin rritur nga 102 milionë në 113 milionë rreshta, pesë raporte u ekzekutuan kundër bazës së të dhënave burim dhe DuckDB ndërsa ngarkesa transaksionale vazhdonte. Baza e të dhënave burim kishte në thelb gjithçka të memorizuar në memorie, dhe kopja DBTrail ishte në gjendjen e saj normale: një skedar bazë Parquet plus skedarë të akumuluar ndryshimesh që DuckDB duhet t'i kombinojë kur ekzekuton një pyetje. Koha totale për të pesë raportet ishte 6 minuta e 35 sekonda në bazën e të dhënave burim dhe 5.7 sekonda në DuckDB. Individualisht, të ardhurat për depo shkuan nga 9.7 sekonda në 0.75 sekonda; porositë dhe të ardhurat për distrikt dhe muaj nga 46.5 sekonda në 2.8 sekonda; dhjetë artikujt më të shitur nga 5 minuta e 32 sekonda në 1.7 sekonda; klientët sipas shtetit dhe kredisë nga 3.6 sekonda në 0.18 sekonda; dhe depot me stoqe të ulëta nga 3.0 sekonda në 0.23 sekonda.
Krahasimi i dytë përdori TPC-H, një ngarkesë standarde analitike, në faktorin e shkallës 10. Ai grup të dhënash përmbante 86.6 milionë rreshta dhe 18.2 GB të dhëna InnoDB, me indekse normale në çelësat e bashkimit, datat e porosive dhe datat e dërgesave. Kopjimi fillestar i DBTrail zgjati 6 minuta e 26 sekonda dhe prodhoi 2.8 GB skedarë Parquet. Të 22 pyetjet TPC-H u ekzekutuan kundër të dy sistemeve. Baza e të dhënave burim mori 5 minuta e 24 sekonda; DuckDB, me një cache të ngrohtë, mori 10.3 sekonda. Baza e të dhënave burim fitoi vetëm Q19 sepse një indeks mund të shkojë drejtpërdrejt te rreshtat përkatës, dhe Q17 ishte në thelb barazim. Për pjesën tjetër, DuckDB ishte dukshëm më i shpejtë. Pjesa 2 e raportit të Percona do të shikojë se sa shpesh DBTrail rifreskon të dhënat për të qëndruar i përditësuar.
Për ekipet që ekzekutojnë bazën e të dhënave relacionale me burim të hapur dhe herë pas here kanë nevojë për raporte analitike, ky model heq nevojën për të ndërtuar dhe operuar një tubacion të plotë të dhënash në një bazë të dhënash analitike të veçantë. Ai gjithashtu shmang rrezikun që një raport ad-hoc të destabilizojë një bazë të dhënash prodhimi. Organizatat që duan këtë ndarje mund ta kenë burimin e tyre të bazës së të dhënave relacionale të prodhimit të ekzekutuar nga një ofrues i menaxhuar i cloud-it dhe infrastrukturës së të dhënave si AEU Data, i cili siguron kopje rezervë të automatizuara, monitorim dhe disponueshmëri të lartë, kështu që kopja analitike mund të lidhet në mënyrë të sigurt ndërsa burimi mbetet i mbrojtur. Ky është raportim mbi një krahasim të palës së tretë; AEU Data nuk i kreu testet ose nuk e ndërtoi DBTrail.