# Polars 2.0: ඇයි join කිරීමේදී තවදුරටත් එහි පේළි අනුපිළිවෙල නොපවතින්නේ

Published: 2026-10-08

Polars 2.0 පෙරනිමියෙන් streaming එන්ජිමක් මත collect ක්‍රියාත්මක කරයි. join, group\_by සහ unpivot සඳහා, maintain\_order හෝ sort පැහැදිලිව සකසා නොමැති නම්, මෙම නිකුතුව තවදුරටත් ආදාන පේළි අනුපිළිවෙල සහතික නොකරයි. අපගේ polars 2.0.0 ක්‍රියාත්මක කිරීමේදී, පේළි 2,000,000ක inner join එකක් පෙරනිමියෙන් ආදාන අනුපිළිවෙලින් පිටත පේළි ආපසු ලබා දුන් අතර, maintain\_order සකසා ඇති විට අනුපිළිවෙල පවත්වා ගත්තේය. මෙම නිකුතුව out-of-core spilling ද සක්‍රිය කරන අතර benchmark හිමිකම් විකුණුම්කරුගේම ඒවා බවට පත් කරයි.

Canonical: https://thedailydiff.dev/si/video/polars-2-row-order/

## මෙම වීඩියෝවෙන් ආවරණය වන දේ

- lazy query එකක් මත collect() ඇමතීම දැන් පෙරනිමියෙන් streaming එන්ජිම භාවිතා කරයි, එය join, group\_by සහ unpivot සඳහා පේළි අනුපිළිවෙල සහතික නොකරයි.
- සංක්‍රමණ මාර්ගෝපදේශය පවසන්නේ අනුපිළිවෙල තවදුරටත් 2.0 පෙර අනුපිළිවෙල නොවන බවත් එය සහතික නොවන බවත්ය; ඔබ එය මත රඳා පවතින්නේ නම් පැහැදිලි වර්ග කිරීමක් නිර්දේශ කරයි.
- අපගේ ක්‍රියාත්මක කිරීමේදී, පෙරනිමි inner join එකක් ආදාන අනුපිළිවෙල False ලෙස ආපසු ලබා දුන්නේය; join එක මත maintain\_order="left\_right" True ලෙස ආපසු ලබා දුන්නේය. එක් යන්ත්‍රයක්, එක් ක්‍රියාත්මක කිරීමක්, එක් join හැඩයක්.
- Out-of-core spilling පෙරනිමියෙන් සක්‍රියයි: එය RAM වලින් 80 % පමණ ආරම්භ වේ, 64 GB පෙරනිමි තැටි අයවැයක් සමඟින්. Out-of-core join සහ group\_by මාර්ග සිතියමෙහි ඇත.
- collect\_schema() දත්ත කියවීමට පෙර නැතිවූ තීරුවක් හඳුනා ගනී, නමුත් එක් අගයක් මත අසමත් වන cast එකක් අසමත් වන්නේ collect() හිදී පමණි.
- TPC-H සහ TPC-DS සංසන්දනය යනු ලබාගත් දත්ත මත විකුණුම්කරුගේම ක්‍රියාත්මක කිරීමක් වන අතර, එහි පාද සටහන පවසන්නේ ප්‍රතිඵල නිල benchmarks සමඟ සැසඳිය නොහැකි බවයි.

## පරිච්ඡේද

- 0:00 පෙරනිමි අනුපිළිවෙල වෙනස් වූයේ ඇයි?
- 0:56 සංක්‍රමණ මාර්ගෝපදේශය පොරොන්දු වන්නේ කුමක්ද?
- 1:17 benchmark එක සාධාරණ සටනක්ද?
- 1:41 අපි එය ක්‍රියාත්මක කරන විට අපට පෙනෙන්නේ කුමක්ද?
- 1:56 වඩා දැඩි වීම යනු කලින් වීමද?
- 2:07 මට පැරණි අනුපිළිවෙල නැවත ලබා ගත හැක්කේ කෙසේද?
- 2:20 තීන්දුව කුමක්ද?

## පරිවර්තනය කරන ලද පිටපත

මුල් ඉංග්‍රීසි නිරූපණයෙන් පරිවර්තනය කරන ලදී. පවතින ශ්‍රව්‍ය සහ ශීර්ෂ පාඨ YouTube මගින් පාලනය වේ.

### පෙරනිමි අනුපිළිවෙල වෙනස් වූයේ ඇයි?

0:00 ඔබ සිතන්නේ join එකක් ඔබ ලියූ අනුපිළිවෙලට ඔබේ පේළි නැවත ලබා දෙන බවයි. Polars 2.0 පෙරනිමියෙන්, හිතාමතාම, එය පොරොන්දු වීම නැවැත්වීය. මෙම වීඩියෝවේ: පෙරනිමිය වෙනස් වූයේ ඇයි? එයින් ලැබුණේ කුමක්ද? සහ ඔබේ කුමන scripts එකද මුලින්ම බිඳ වැටෙන්නේ? මෙය The Daily Diff, තිරය පිටුපසින්. Polars යනු විවෘත මූලාශ්‍ර DataFrame පුස්තකාලයකි: ඔබ Python වලින් අමතන table engine එකක්,

0:20 එහි හරය Rust වලින් ලියා ඇත. එය MIT බලපත්‍රය යටතේ නොමිලේ වන අතර, ඔබ එය pip install polars සමඟ ස්ථාපනය කරයි. මුලින්ම එක් විස්තරයක්. පැරණි අනුපිළිවෙල නැවත ගෙන එන switch එක join එකටම තර්කයක් වේ. මම අවසානයේ එය වෙත නැවත එන්නම්. 2.0 සිට, collect පෙරනිමියෙන් streaming engine ක්‍රියාත්මක කරයි. Streaming මඟින් query එක සමාන්තරව ක්‍රියාත්මක වන කොටස් වලට බෙදයි, සහ කොටස් ඒවා අවසන් වන විට අවසන් වේ.

0:42 join, group by සහ unpivot සඳහා, නිකුතුව අනුපිළිවෙලක් පොරොන්දු නොවේ. මුලින්ම බලපාන්නේ කාටද? ප්‍රතිදානය සුරැකි ගොනුවක් සමඟ, පේළියෙන් පේළියට සංසන්දනය කරන ඕනෑම අයෙකුට. එම පරීක්ෂණය ඔබේ ලැප්ටොප් එකේ සමත් වී වෙනත් යන්ත්‍රයක අසමත් විය හැක. ඊළඟට, සංක්‍රමණ මාර්ගෝපදේශය.

### සංක්‍රමණ මාර්ගෝපදේශය පොරොන්දු වන්නේ කුමක්ද?

0:57 එය පවසන්නේ ඉහත පෙන්වා ඇති නිශ්චිත පේළි අනුපිළිවෙල සහතික නොවන බවයි. එබැවින් ඔබ අනුපිළිවෙල මත රඳා පවතින්නේ නම්, පැහැදිලිව වර්ග කරන්න. Out-of-core ද පෙරනිමියෙන් සක්‍රියයි. එය RAM වලින් අසූවක් පමණ ප්‍රතිශතයකදී තැටියට පිටාර ගැලීම ආරම්භ කරයි, ගිගාබයිට් හැට හතරක අයවැයක් සමඟින්. Sort, window functions සහ බොහෝ ප්‍රකාශන දැන් පිටාර ගැලිය හැක. Joins සහ group-bys පැමිණෙමින් තිබේ.

### benchmark එක සාධාරණ සටනක්ද?

1:17 Polars පවසන්නේ එය TPC-H සහ TPC-DS benchmarks වලදී DataFusion සහ DuckDB පරාජය කරන බවයි. අංක ඔවුන්ගේම ක්‍රියාත්මක කිරීම් වලින්, ලබාගත් දත්ත මත ලබාගෙන ඇති අතර, ඔවුන්ගේ පාද සටහන පවසන්නේ ඒවා නිල ප්‍රතිඵල සමඟ සැසඳිය නොහැකි බවයි. ඔවුන්ගේම සංඛ්‍යා පවසන්නේ Polars TPC-H මත cores දහසය සිට සියයක් අනූ දෙක දක්වා තුනක් අට ගුණයක් පමණ වේගවත් වන බවයි. ඔවුන් තවදුරටත් පවසන්නේ විශාල යන්ත්‍රයේ අමතර threads කුඩා queries මන්දගාමී කරන බවයි. අපි Polars 2.0.0 මත එම join එක දෙවරක් ක්‍රියාත්මක කළා.

### අපි එය ක්‍රියාත්මක කරන විට අපට පෙනෙන්නේ කුමක්ද?

1:41 පෙරනිමි ක්‍රියාත්මක කිරීම පේළි shuffle කරයි. ධජය සමඟින්, ආදාන අනුපිළිවෙල පවතී. පරීක්ෂණයක් පෝෂණය කරන joins සොයන්න. එය පසුපස sort එකක් නොමැති ඕනෑම join එකක් ඔබ කිසිදා නොකළ පේළි අනුපිළිවෙල තීරණයකි. Polars 2.0 types ගැන වඩාත් දැඩියි. schema check එක මඟින් කිසිදු දත්තයක් කියවීමට පෙර නැතිවූ තීරුවක් හඳුනා ගනී.

### වඩා දැඩි වීම යනු කලින් වීමද?

1:58 එය එක් පේළියක් මත අසමත් වන cast එකක් හඳුනා ගත නොහැක, මන්ද එම දෝෂය දත්ත එනතුරු බලා සිටින බැවිනි. දැන් මම විවෘත කළ loop එක. switch එක join එක මත පවතී.

### මට පැරණි අනුපිළිවෙල නැවත ලබා ගත හැක්කේ කෙසේද?

2:08 join එක මත maintain order සකසන්න, නැතහොත් එය පසුපස sort එකක් එක් කරන්න. මාර්ගෝපදේශය sort එක යෝජනා කරයි. join flag එක අපගේ ක්‍රියාත්මක කිරීමේදී අනුපිළිවෙල තබා ගත්තේය, වම් පැත්තේ අනුපිළිවෙල left, right ලෙස තබා ගත්තේය. තිරය ​​පිටුපසින් තීන්දුව: සමාලෝචනය අවශ්‍යයි. උත්ශ්‍රේණි කිරීමට පෙර මම සෑම join එකක්ම සමාලෝචනය කරමි.

### තීන්දුව කුමක්ද?

2:22 මේ ගැන ප්‍රශ්නයක් තිබේද? එය අදහස් දැක්වීම් වලට දමන්න. සහ අද සඳහා වෙනස එයයි. මම Axrisi වෙතින් Niko. වගකීමෙන් යුතුව ඒකාබද්ධ කරන්න. වගකීමෙන් යුතුව ඒකාබද්ධ කරන්න.

## මූලාශ්‍ර

- [Release of Polars 2.0](https://pola.rs/posts/release-polars-2/) — Polars (pola.rs)
- [Polars 2.0 upgrade guide](https://docs.pola.rs/releases/upgrade/2/) — Polars documentation
- [Polars homepage](https://pola.rs/) — Polars (pola.rs)
- [polars-2.0-benchmark repository](https://github.com/pola-rs/polars-2.0-benchmark) — Polars on GitHub
- [Release of Polars 2.0 (Hacker News discussion)](https://news.ycombinator.com/item?id=49977177) — Hacker News