DuckDB ali SQLite: analitika do 50-krat hitrejša

Za aplikacijo, ki pogosto spreminja posamezne zapise, je smiselna izbira SQLite; za obsežne lokalne agregacije in združevanje tabel pa DuckDB. V meritvi Star Schema Benchmark je bil DuckDB pri eni skupini analitičnih poizvedb od 30- do 50-krat hitrejši od SQLite, pri drugi od 3- do 8-krat. To je rezultat konkretne laboratorijske obremenitve, ne napoved hitrosti vsakega poročila.

Če aplikacija potrebuje oboje, lahko zapise še naprej hrani v SQLite, DuckDB pa neposredno priključi njeno datoteko za analizo. Tako izbira analitičnega orodja ne zahteva takojšnje selitve operativnih podatkov. Pri odločitvi sta pomembna pogostost kratkih sprememb in obseg podatkov, ki jih morajo prebrati poročila.

Odločitev po vzorcu branja in pisanja

Najprej ločite delo z eno vrstico od dela z velikim delom tabele. Shranjevanje uporabniške nastavitve, sprememba stanja naročila in iskanje zapisa po ključu so kratke operacije. Izračun prometa po mesecih, združevanje naročil z izdelki in pregled večletnih podatkov zahtevajo drugačen način obdelave. Podobna sintaksa SQL pri obeh zbirkah te razlike ne odpravi.

Prevladujejo kratke transakcije: SQLite naj bo primarna shramba. Če občasno poročilo teče dovolj hitro, dodatna analitična pot še nima jasne koristi.
Prevladujejo obsežna branja: DuckDB je primernejše izhodišče za lokalno analitiko, pri kateri poizvedbe pregledujejo veliko vrstic in računajo skupne vrednosti.
Potrebujete oboje: SQLite lahko sprejema spremembe aplikacije, DuckDB pa bere iste tabele za poročila. Za pogosto ponavljajoče se zahtevne analize je lahko smiselna še ločena analitična kopija.

Pri mešani obremenitvi torej ni treba izbrati enega pogona za vse naloge. Pomembno je tudi, kako sveži morajo biti rezultati: neposredno branje operativne datoteke omogoča poizvedbe nad njenimi podatki, ločena kopija pa potrebuje način osveževanja. Ta razlika lahko pri izbiri arhitekture pomeni več kot najhitrejši rezultat iz laboratorijskega merila.

Zakaj SQLite ustreza zapisom aplikacije

Datoteka SQLite ohrani lokalne zapise aplikacije pri posodobitvi posameznega zapisa.

SQLite je vgrajena zbirka za lokalno shranjevanje brez ločenega podatkovnega strežnika. Smernice SQLite med primernimi rabami navajajo datoteke namiznih aplikacij in lokalno shrambo; pojasnjujejo tudi, da lahko v posamezno datoteko hkrati piše le en zapisovalec. Več bralcev lahko dostopa do nje sočasno, kratke zapisovalne transakcije pa si sledijo.

To ustreza aplikaciji, ki mora zanesljivo ohraniti trenutno stanje in se hitro odzvati na spremembo posameznega zapisa. Omejitev zapisovalcev postane pomembnejša, ko veliko procesov potrebuje hkratno pisanje in čakanje ni sprejemljivo. Takrat je vprašanje širše od izbire med SQLite in DuckDB: zasnova morda potrebuje strežniško zbirko, ki usklajuje številne zapisovalce.

SQLite zna izvajati tudi poročila in analitične poizvedbe. Samo dejstvo, da poročilo vsebuje GROUP BY ali JOIN, zato še ni razlog za drugo zbirko. Če občasna poizvedba prebere malo podatkov in pravočasno vrne rezultat, preprostejša zasnova z eno datoteko ostane uporabna. Analitična pot pridobi pomen, ko obsežna branja postanejo reden in drag del dela.

Kje DuckDB pridobi prednost

DuckDB je usmerjen v poizvedbe, ki obdelajo velik del podatkovne množice. Opis zasnove DuckDB navaja stolpčno in vektorizirano izvajanje: pogon vrednosti obdeluje v paketih, namesto da bi za vsako vrstico posebej ponavljal enako delo. To je uporabno pri izračunih, ki iz velikega števila vrstic potrebujejo le izbrane stolpce.

Pri poročilu o prodaji, ki združuje zneske po obdobjih in kategorijah, mora zbirka prebrati ter povezati precej podatkov. DuckDB je zasnovan prav za takšne agregacije in obsežnejše spremembe v paketih. Podpira tudi transakcije, vendar podatek o hitrosti analitičnih poizvedb sam po sebi ne pove, kako primeren bo za množico drobnih sprememb stanja aplikacije.

Razlika med pogonoma je zato povezana z obliko dela, ne zgolj z velikostjo datoteke. Majhna zbirka lahko vsebuje zapletena poročila, velika pa večinoma kratka iskanja po ključu. Za razvijalca je koristnejše vprašanje, katere poizvedbe porabijo največ časa in kako pogosto tečejo, kakor splošna oznaka, da je podatkov »veliko«.

Kaj meri velika razlika v hitrosti

Star Schema Benchmark predstavlja analitiko podatkovnega skladišča: velika tabela dejstev se povezuje z manjšimi razsežnostnimi tabelami, poizvedbe pa uporabljajo filtre in agregacije. Takšna naloga je bliže poročilu o prodaji kakor shranjevanju posameznega naročila. Razpon rezultatov se razlikuje med skupinami poizvedb, ker se razlikujejo tudi njihovi filtri in povezave.

Meritev primerja pogona pri določeni konfiguraciji in podatkih, shranjenih v njunih zbirkah. Iz nje zato ni mogoče neposredno sklepati, da bo poizvedba v DuckDB enako hitrejša, ko ta bere priključeno datoteko SQLite. V slednjem primeru podatki ostanejo v obliki SQLite; neposredna priključitev odstrani potrebo po predhodnem izvozu, sama pa jih ne spremeni v domačo stolpčno shrambo DuckDB.

Za pogosto ponavljajoče se poročilo sta tako različni možnosti neposredno branje datoteke in priprava ločene kopije za analitiko. Kopija lahko bolje ustreza načinu dela DuckDB, vendar njen nastanek in osveževanje zahtevata čas. Korist je odvisna od tega, kolikokrat se poročilo izvede, koliko podatkov obdeluje in kolikšen zamik podatkov je sprejemljiv.

Skupna datoteka in meja sočasnega dela

DuckDB priključi datoteko SQLite za analizo in lahko podatke izvozi v Parquet.

Razširitev SQLite za DuckDB omogoča neposredno branje in spreminjanje datoteke SQLite ter izvoz njenih podatkov v Parquet. Za pogojno datoteko app.db je ukaz ATTACH 'app.db' AS app (TYPE sqlite);. Priključene tabele so nato dostopne pod imenom zbirke, zato lahko analitična poizvedba bere obstoječe podatke brez predhodne selitve.

Če bi aplikacija imela tabelo narocila, bi pogojni primer poizvedbe bil SELECT status, COUNT(*) FROM app.narocila GROUP BY status;. Ime tabele in njen stolpec sta samo ponazoritev. Aplikacija lahko še naprej zapisuje v SQLite, analitični proces pa uporablja DuckDB za poizvedbe nad priključeno datoteko. Če poročila zahtevajo drugačno postavitev podatkov, se lahko iz istih tabel pripravi ločen izvoz Parquet.

Pri skupni rabi še vedno veljajo pravila zaklepanja SQLite. V načinu WAL lahko bralci delujejo sočasno z zapisovalcem, dolgotrajna bralna transakcija pa lahko zadrži dokončanje prenosa zapisov iz dnevnika v glavno datoteko. Zato sta pri zahtevnih poročilih pomembna tudi njihov čas izvajanja in ritem zapisovanja aplikacije. Kadar analitično branje občutno obremeni operativno datoteko, ločena kopija omogoči, da poročila tečejo neodvisno od nje; cena te ločitve je osveževanje podatkov.

Preberite tudi: