Viens TPC-DS etalona vaicājums uz gigabaita datu PostgreSQL rēķina 81,8 sekundes. Ar spraudni pg_duckdb tas pats vaicājums nobeidzas 52 milisekundēs. Starpība ir aptuveni 1500 reižu, un to nedod ne jaudīgāks serveris, ne papildu indeksi — datus apstrādā cits dzinējs, kas tagad dzīvo pašā PostgreSQL procesā.
Spraudnis pg_duckdb sasniedza 1.0 versiju un ir gatavs ražošanai. To kopīgi izstrādā MotherDuck, Hydra un DuckDB Labs. Ideja ir vienkārša: paņemt DuckDB kolonnu un vektoru dzinēju un ielikt to PostgreSQL kā parastu paplašinājumu, lai analītiskos vaicājumus vairs nevajadzētu vilkt uz atsevišķu datu noliktavu.
Kāpēc PostgreSQL analītikā apstājas
PostgreSQL glabā datus pa rindām. Tas der darījumu slodzei — meklēšanai pēc atslēgas, maziem atjauninājumiem un vaicājumiem, kad indeksi ir sakārtoti. Analītikā aina mainās. Kad vajag noskenēt veselu kolonnu un saskaitīt agregātus pār miljoniem rindu, rindu glabāšana kļūst par bremzi: dzinējs izlasa visu rindu, lai izvilktu vienu lauku, un apstrādā katru rindu pa vienai.
DuckDB strādā pretēji. Tas glabā un apstrādā datus pa kolonnām un rēķina veselu vērtību paku — vektoru — vienā piegājienā. Vienam laukam vairs nav jālasa blakus esošie. Tieši šī atšķirība parādās TPC-DS skaitļos, un jo lielāki dati, jo plaisa platāka: uz 10 gigabaitiem AWS vidē MotherDuck ziņo, ka tīrs PostgreSQL rēķina pāri divām stundām, bet pg_duckdb tiek galā aptuveni 400 milisekundēs.
Kā vaicājums nonāk DuckDB
DuckDB pats ir iegultā OLAP datubāze — līdzīgi SQLite, tikai analītikai. To 2019. gadā radīja pētnieki Nīderlandes CWI institūtā, un tas darbojas viena procesa iekšpusē bez atsevišķa servera. pg_duckdb izmanto tieši šo dzinēju: PostgreSQL paliek saskarne un datu glabātuve, DuckDB pievienojas kā skaitļošanas slānis analītiskajiem vaicājumiem.
Dati paliek parastajās PostgreSQL tabulās. Neko nevajag pārkārtot vai kopēt uz citu formātu. Spraudnis āķojas PostgreSQL vaicājumu plānā un tās daļas, ko DuckDB var izpildīt ātrāk — filtrus, agregātus, savienojumus — nodod savam dzinējam vektorizētai, paralēlai izpildei. Pārējo apstrādā PostgreSQL kā vienmēr.
Kontroli var paņemt arī rokās. Komanda SET duckdb.force_execution = true; liek sesijai vaicājumus dzīt caur DuckDB, tā ka analītiķis izvēlas dzinēju atsevišķām slodzēm, kamēr darījumu daļa turpina strādāt uz PostgreSQL garantijām.
Viss joprojām glabājas tajās pašās PostgreSQL tabulās, ko jau lietojat. — MotherDuck izstrādes komanda
Ne aizstājējs darījumiem
pg_duckdb paātrina lasīšanu un analītiku, ne darījumu rakstīšanu. Ieraksti PostgreSQL tabulās joprojām iet caur PostgreSQL ar tā darījumu garantijām; DuckDB dzinējs pārņem lielos skenēšanas un agregācijas vaicājumus. Tāpēc spraudni var pievienot esošai datubāzei, negaidot lietotnes pārrakstīšanu — OLTP daļa strādā tāpat kā līdz šim.
Datu ezers bez atsevišķa dzinēja
pg_duckdb neaprobežojas ar lokālajām tabulām. Tas lasa Parquet, CSV, JSON, Iceberg un Delta Lake failus tieši no Amazon S3, Google Cloud Storage, Azure un Cloudflare R2. Rezultātu var rakstīt atpakaļ uz S3 vai MotherDuck ar parasto COPY komandu. Praksē tas nozīmē, ka vienā SQL vaicājumā var savienot PostgreSQL tabulu ar Parquet failu objektu krātuvē, neizmantojot atsevišķu ETL rīku.
Kam analītikas apjoms pāraug vienu serveri, spraudnim ir MotherDuck integrācija. Smagos vaicājumus var novirzīt uz MotherDuck bezservera skaitļošanu mākonī, kamēr PostgreSQL turpina apkalpot darījumus. 1.0 versija atļauj vienā datubāzē lietot vairākus lietotājus ar dažādām MotherDuck pilnvarām: atsevišķi lasīšanas un rakstīšanas, atsevišķi tikai lasīšanas.
Kur tas iederas
Tipiskais lietojums ir hibrīda slodze: viena PostgreSQL instance apkalpo gan darījumus, gan atskaites. Produkta komanda tur lietotāju datus PostgreSQL, bet paneļus un agregātus, kas agrāk datubāzi nolika ceļos, tagad rēķina DuckDB dzinējs uz tiem pašiem datiem. Otrs lietojums ir datu ezers: analītiķis vaicā Parquet vai Iceberg failus objektu krātuvē un tos pašā vaicājumā savieno ar dzīvām PostgreSQL tabulām, nepārceļot neko starp sistēmām.
Ko tas maina komandām
Līdz šim ātra analītika virs PostgreSQL parasti nozīmēja datus izvilkt uz atsevišķu sistēmu — Snowflake, ClickHouse vai savu DuckDB kaudzīti — un uzturēt sinhronizāciju. pg_duckdb noņem šo soli tur, kur dati jau atrodas PostgreSQL. The New Stack raksta, ka daudziem vaicājumiem reālistiskais paātrinājums ir ap 10 reizēm; 1500 reizes ir galējais gadījums uz labvēlīga TPC-DS vaicājuma, ne ikdienas norma.
Projekts nesākās tukšā vietā. MotherDuck kopā ar Hydra un DuckDB Labs pg_duckdb beta versiju izlaida jau agrāk, un 1.0 nobeidz to darbu — pēc BigDATAwire ziņotā, beta jau rādīja to pašu vektorizēto dzinēju PostgreSQL iekšpusē, bet bez ražošanai vajadzīgās stabilitātes un datu tipu pārklājuma.
Izmēģināt var ar vienu Docker attēlu:
docker run -d -e POSTGRES_PASSWORD=duckdb pgduckdb/pgduckdb:16-main
Kods ir atvērts un mitināts DuckDB GitHub organizācijā. Spraudni var būvēt arī no pirmkoda un pievienot esošai PostgreSQL instancei kā jebkuru citu paplašinājumu. 1.0 laidiens papildus stabilitātei ienes plašāku datu tipu atbalstu un iespēju instalēt DuckDB kopienas paplašinājumus tieši no datubāzes.
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.