# Polars 2.0: چرا پیوندها دیگر ترتیب ردیف خود را حفظ نمی‌کنند

Published: 2026-10-08

Polars 2.0 به طور پیش‌فرض، collect را روی یک موتور جریانی اجرا می‌کند. برای join، group\_by و unpivot، این نسخه دیگر ترتیب ردیف ورودی را تضمین نمی‌کند، مگر اینکه شما maintain\_order را تنظیم کنید یا به صراحت مرتب‌سازی کنید. در اجرای ما روی polars 2.0.0، یک inner join با 2,000,000 ردیف به طور پیش‌فرض ردیف‌ها را خارج از ترتیب ورودی بازگرداند و با تنظیم maintain\_order، ترتیب را حفظ کرد. این نسخه همچنین قابلیت out-of-core spilling را فعال می‌کند و ادعاهای بنچمارک را متعلق به خود فروشنده می‌سازد.

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

## این ویدیو چه مواردی را پوشش می‌دهد

- فراخوانی collect() روی یک کوئری lazy اکنون به طور پیش‌فرض از موتور جریانی استفاده می‌کند که ترتیب ردیف را برای join، group\_by و unpivot تضمین نمی‌کند.
- راهنمای مهاجرت می‌گوید که ترتیب دیگر ترتیب قبل از 2.0 نیست و تضمین نمی‌شود؛ اگر به آن تکیه می‌کنید، مرتب‌سازی صریح را توصیه می‌کند.
- در اجرای ما، یک inner join پیش‌فرض، ترتیب ورودی را False بازگرداند؛ maintain\_order="left\_right" روی join، True بازگرداند. یک ماشین، یک اجرا، یک شکل join.
- out-of-core spilling به طور پیش‌فرض روشن است: در حدود 80 درصد از RAM شروع می‌شود، با بودجه پیش‌فرض دیسک 64 گیگابایت. join و group\_by out-of-core در نقشه راه هستند.
- collect\_schema() یک ستون گمشده را قبل از خواندن هر داده‌ای شناسایی می‌کند، اما یک cast که فقط روی یک مقدار شکست می‌خورد، فقط در collect() شکست می‌خورد.
- مقایسه TPC-H و TPC-DS، اجرای خود فروشنده روی داده‌های مشتق شده است و پاورقی آن می‌گوید نتایج با بنچمارک‌های رسمی قابل مقایسه نیستند.

## فصل‌ها

- 0:00 چرا ترتیب پیش‌فرض تغییر کرد؟
- 0:56 راهنمای مهاجرت چه چیزی را وعده می‌دهد؟
- 1:17 آیا بنچمارک یک رقابت عادلانه است؟
- 1:41 وقتی آن را اجرا می‌کنیم چه می‌بینیم؟
- 1:56 آیا سخت‌گیرانه‌تر به معنای زودتر است؟
- 2:07 چگونه ترتیب قدیمی را برگردانم؟
- 2:20 حکم چیست؟

## رونوشت ترجمه شده

ترجمه شده از روایت اصلی انگلیسی. صوت و زیرنویس‌های موجود توسط YouTube کنترل می‌شوند.

### چرا ترتیب پیش‌فرض تغییر کرد؟

0:00 شما فکر می‌کنید یک join ردیف‌های شما را به ترتیبی که نوشته‌اید برمی‌گرداند. Polars 2.0 به طور پیش‌فرض، عمداً، این قول را نداد. در این ویدیو: چرا پیش‌فرض تغییر کرد؟ چه سودی داشت؟ و کدام یک از اسکریپت‌های شما اول خراب می‌شود؟ این The Daily Diff است، در پشت صحنه. Polars یک کتابخانه DataFrame متن‌باز است: یک موتور جدول که از پایتون فراخوانی می‌کنید،

0:20 با هسته آن که در Rust نوشته شده است. تحت مجوز MIT رایگان است و با pip install polars نصب می‌شود. ابتدا یک جزئیات. سوئیچی که ترتیب قدیمی را برمی‌گرداند، یک آرگومان برای خود join است. در انتها به آن برمی‌گردم. از نسخه 2.0، collect به طور پیش‌فرض موتور جریانی را اجرا می‌کند. Streaming کوئری را به تکه‌هایی تقسیم می‌کند که به صورت موازی اجرا می‌شوند، و تکه‌ها وقتی که تمام شوند، تمام می‌شوند.

0:42 برای join، group by و unpivot، این نسخه ترتیبی را وعده نمی‌دهد. چه کسی اول ضربه می‌خورد؟ هر کسی که خروجی را با یک فایل ذخیره شده، ردیف به ردیف مقایسه کند. آن تست می‌تواند روی لپ‌تاپ شما پاس شود و روی یک ماشین دیگر شکست بخورد. بعد، راهنمای مهاجرت.

### راهنمای مهاجرت چه چیزی را وعده می‌دهد؟

0:57 می‌گوید ترتیب دقیق ردیف نشان داده شده در بالا تضمین نمی‌شود. بنابراین اگر به ترتیب تکیه می‌کنید، به صراحت مرتب‌سازی کنید. Out-of-core نیز به طور پیش‌فرض روشن است. در حدود هشتاد درصد RAM شروع به ریختن به دیسک می‌کند، با بودجه شصت و چهار گیگابایتی. Sort، توابع پنجره‌ای و بسیاری از عبارات اکنون می‌توانند spill کنند. Joins و group-bys در راه هستند.

### آیا بنچمارک یک رقابت عادلانه است؟

1:17 Polars می‌گوید در بنچمارک‌های TPC-H و TPC-DS، DataFusion و DuckDB را شکست می‌دهد. اعداد از اجراهای خودشان، روی داده‌های مشتق شده، به دست می‌آیند، و پاورقی آنها می‌گوید که با نتایج رسمی قابل مقایسه نیستند. اعداد خودشان می‌گویند Polars در TPC-H حدود سه و هشت دهم برابر سریع‌تر می‌شود از شانزده هسته به صد و نود و دو هسته. آنها همچنین می‌گویند رشته‌های اضافی ماشین بزرگ، کوئری‌های کوچک را کند می‌کنند.

### وقتی آن را اجرا می‌کنیم چه می‌بینیم؟

1:41 ما همان join را دو بار روی Polars 2.0.0 اجرا کردیم. اجرای پیش‌فرض ردیف‌ها را به هم می‌ریزد. با پرچم، ترتیب ورودی حفظ می‌شود. joinهایی را پیدا کنید که یک تست را تغذیه می‌کنند. هر join بدون مرتب‌سازی بعد از آن، یک تصمیم ترتیب ردیف است که شما هرگز نگرفته‌اید. Polars 2.0 در مورد انواع سخت‌گیرانه‌تر است.

### آیا سخت‌گیرانه‌تر به معنای زودتر است؟

1:58 بررسی طرح‌واره یک ستون گمشده را قبل از خواندن هر داده‌ای شناسایی می‌کند. نمی‌تواند یک cast را که روی یک ردیف شکست می‌خورد، شناسایی کند، زیرا آن خطا منتظر داده‌ها است. اکنون حلقه ای که باز کردم.

### چگونه ترتیب قدیمی را برگردانم؟

2:08 سوئیچ روی join قرار دارد. maintain\_order را روی join تنظیم کنید، یا یک sort بعد از آن اضافه کنید. راهنما مرتب‌سازی را پیشنهاد می‌کند. پرچم join ترتیب را در اجرای ما حفظ کرد، با حفظ ترتیب سمت چپ به عنوان left, right. حکم، در پشت صحنه: نیاز به بازبینی.

### حکم چیست؟

2:22 من قبل از ارتقاء هر join را بازبینی می‌کنم. سؤالی در مورد این دارید؟ آن را در نظرات قرار دهید. و این تفاوت امروز است. من Niko از Axrisi هستم. با مسئولیت‌پذیری ادغام کنید.

## منابع

- [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