DuckDB eða Polars: tengingar vinna hraðann, minnisþakið snýr valinu

Polars er sterkur fyrsti kostur þegar Python-vinnslukeðja inniheldur margar tengingar og vinnugögnin hafa nægt svigrúm í minni. DuckDB hentar betur þegar SQL er aðalvinnumálið eða hópun með mjög mörgum niðurstöðuhópum nálgast minnismörk. Munurinn snýst bæði um hraða og um það hvort fyrirspurnin nær að ljúka.

Þetta val gildir þó ekki endilega um alla keðjuna. Hægt er að láta aðra vélina sjá um afmarkaða SQL-fyrirspurn og hina um áframhaldandi umbreytingar í Python. Birtar mælingar gefa gagnlega vísbendingu um hvar hvor vél hefur forskot, en þær mæla tiltekin gögn, vélbúnað og hvernig niðurstöður voru búnar til.

SQL eða lazy gagnarammi: hvað mótar vinnuna?

DuckDB vinnur með SQL sem megintjáningarmál. Fyrir teymi sem lýsir greiningu með töflum, tengilyklum, síum og hópun er fyrirspurnin sjálf læsileg eining sem má keyra úr Python. Polars fellur betur að vinnslu þar sem forritari raðar dálkatjáningum, síum og umbreytingum saman í gagnaramma. Val á vél getur því snúist um það hvar meginrökfræði verkefnisins á að búa, jafnvel áður en hraði er mældur.

Í leiðbeiningum Polars um lazy API er lýst hvernig aðgerðir mynda fyrirspurnaráætlun sem er bestað áður en hún er keyrð. Síur geta færst nær lestri gagnanna og aðeins nauðsynlegir dálkar verið sóttir. Þetta getur skipt miklu fyrir breið Parquet-gögn þegar niðurstaðan byggist á fáum dálkum: minni lestur minnkar vinnu áður en tenging eða hópun hefst. Ávinningurinn ræðst samt af því hvaða skref áætlunin getur sameinað og hvaða gögn þurfa loks að liggja fyrir.

Lazy vinnulag breytir líka því hvað þarf að bera saman. Ef Polars fær að vinna heila keðju úr inntaki að niðurstöðu, en DuckDB fær aðeins eina staka fyrirspurn á þegar hlaðna töflu, eru tímarnir ekki lýsing á sama verki. Fyrir teymi sem endurnýtir SQL milli greininga vegur skýr framsetning og viðhald fyrirspurna einnig þungt, þótt stakur gagnarammahluti keyri hraðar.

Hvað sýna tímarnir fyrir tengingar og hópun?

Í afkastaprófi Uvik Software á tíu milljónum raða tók samanlagður miðgildistími fimm tenginga 3,16 sekúndur í Polars 2.0.0 og 10,46 í DuckDB 1.5.6; tíu hópunarfyrirspurnir tóku 2,86 sekúndur í Polars og 3,91 í DuckDB. Við fimmtíu milljónir raða og 5,84 GiB minnishámark lauk DuckDB öllum tíu hópunarfyrirspurnunum en Polars níu. Þar fær hraðari tengingavinnsla því annað vægi en geta til að ljúka stórri hópun.

Hraðamunurinn í tengingunum var ekki aðeins afleiðing einnar óvenjulegrar fyrirspurnar: Polars var hraðara í hverri tengingu prófsins. Hópunin var fjölbreyttari. DuckDB var hraðara í fleiri einstökum hópunarfyrirspurnum, þótt samanlagður tími Polars væri lægri. Fjöldi ólíkra tengilykla, stærð niðurstöðu og aðgerðir innan hvers hóps geta breytt röðinni. Sá sem vinnur einkum með síendurteknar tengingar hefur því aðra upphafstilgátu en sá sem vinnur með margs konar samantektir.

Prófið notaði tilbúin gögn með tiltekinni dreifingu lykla. Mældur var keyrslutími þar til fullbúin niðurstaða lá fyrir: Polars safnaði gagnaramma en DuckDB bjó til nýja töflu. Innlestur var mældur sérstaklega. Þegar tenging skilar nær öllum röðum getur efnisgerð stórrar niðurstöðu orðið verulegur hluti tímans. Fyrirspurn sem síar snemma og skilar litlu úrtaki getur því sýnt annað hlutfall, þótt hún noti sama tengilykil.

Af hverju getur minnisþak snúið valinu?

Stærra prófið snerist um hópun, ekki stórar tengingar. Polars lauk flestum fyrirspurnunum en stöðvaðist í hópun sem myndaði gríðarlega marga ólíka hópa. Þótt inntakið rúmist í minni geta innri gagnaskipanir fyrir hópa og niðurstaðan sjálf stækkað við útreikninginn. Skrárstærð á diski segir því ekki ein og sér hvort verkefnið kemst undir fast minnisþak.

Útgáfulýsing Polars 2.0 segir að lazy fyrirspurnir noti sjálfgefið streymisvél og að ákveðnar aðgerðir geti flutt millivinnu á disk. Þar er líka tekið fram að sá diskastuðningur nái enn ekki til tenginga og hópunar. Streymi getur minnkað minni fyrir hluta vinnslukeðju án þess að leysa minnisþörf sérhverrar aðgerðar í henni. Í sömu útgáfu fékk SQL aukið vægi í Polars, þannig að verkaskiptingin milli vélanna er ekki algjör mörk milli SQL og Python.

Afkastaleiðbeiningar DuckDB lýsa því að vélin geti flutt millivinnu við hópun, tengingar, röðun og gluggaföll á disk þegar minni nægir ekki. Sú geta skýrir hvers vegna hún er áhugaverð nálægt minnismörkum, en diskpláss og lestrarhraði verða þá hluti af raunverulegum kostnaði. Leiðbeiningarnar nefna einnig að samspil margra minnisfrekra aðgerða og sumar söfnunaraðgerðir geti enn valdið minnisvanda. Kosturinn er því meiri möguleiki á að ljúka þessu tiltekna álagi, ekki trygging fyrir öllum stórum fyrirspurnum.

Hvenær borgar sig að nota báðar vélarnar?

Samspil er raunhæft þegar SQL er þægilegast fyrir afmarkaða fyrirspurn en Polars fyrir áframhaldandi Python-umbreytingar. Samvirknileiðbeiningar DuckDB sýna að DuckDB getur lesið Polars-gagnaramma í gegnum Apache Arrow og skilað SQL-niðurstöðu sem Polars-gagnaramma; pyarrow þarf að vera uppsett. Þannig þarf ekki að velja eina vél sem tungumál fyrir alla greininguna.

Stærð þess sem fer milli þrepa ræður þó miklu um ávinninginn. Ef SQL-hlutinn minnkar gagnamassann með síu eða hópun getur síðari Polars-vinnsla fengið viðráðanlega niðurstöðu. Ef tenging skilar nær öllu inntakinu þarf samt minni fyrir þá niðurstöðu og tíma til að búa hana til. Samvirknin gerir verkaskiptingu mögulega; hún afnemur ekki kostnað við milliniðurstöður.

Valið eftir ráðandi takmörkun

• Margar tengingar og gott minnissvigrúm: Polars er eðlilegur upphafskostur, einkum þegar umbreytingarnar eru þegar skrifaðar sem Python-tjáningar.
• SQL sem sameiginlegt vinnumál: DuckDB heldur fyrirspurnum í því formi sem teymið notar og getur tekið við niðurstöðu úr Polars þegar það hentar.
• Hópun með mjög mörgum ólíkum hópum nálægt minnisþaki: DuckDB er sterkari upphafskostur vegna diskavinnslu, með nægu tímabundnu plássi fyrir milliskref.
• Blandað vinnulag: Skiptu verkinu við þann punkt þar sem milliniðurstaðan er nógu lítil til að áframhaldandi vinnsla hafi skýran ávinning.

Lestu einnig:

• Asana eða Basecamp: 28 manna teymi snýr verðdæminu við
• Ragas eða DeepEval: gagnasafnið og CI-prófið mæla ekki sama hlut
• Cursor eða GitHub Copilot: vinnulagið skiptir meira máli en eitt stig