چرا این راهکار بهتره ؟

۱- نیازی به Shared Memory نداریم؛ به محض اینکه یکی از future ها جواب بده، می‌دونیم به نتیجه رسیدیم.

۲- حتی اگر جواب توی آخرین عناصر یکی از chunk ها هم باشه بازم، نهایتاً به اندازه تست اون صبر می‌کنیم.

اما یک مسئله‌ای هم با این راهکار دارم؛
توی سیستم‌های فعلی که core ها سرعت متفاوتی دارند (بعضی‌ از cpu ها) اونایی که سرعت بالاتری دارند chunk خودشون رو سریعتر انجام می‌دهند، این روش اونجا مشکل ساز میشه یا نه ؟

سوال بالا رو بهش فکر کنید؛ اگر توی مصاحبه به Senior بر می‌خوردم قطعاً این سوال رو ازش می‌پرسیدم ولی کسی نبود حالا که سروش جواب خوب رو داد؛ این سوال رو هم با باقی اعضا به اشتراک می‌ذارم!

پ.ن:
چون گفتید؛ شخصاً نظرم اینه که
یا یک موضوعی رو نباید بررسی کرد؛ یا اینکه به همه‌ی حالاتش باید دقیق فکر کرد.
حالا که انقدر زحمت کشیدید و خوندید، بهتره کامل بررسیش کنیم! تا با نحوه تفکر مغز مریض منم آشنا بشید 😂

سروش خودش راهکار درست رو ارائه داد، ولی شماهم بهش فکر کنید.
راهکار درست و بهینه توی همون کد قبلی سروش هست؛ فقط مشکلی که توی چند خط بالا گفتم رو حل کنید.

وقتی یکی میگه؛ حالا مگه الگوریتم چقدر مهمه ؟

آدما این سوال رو می‌پرسند،چون هیچوقت تفاوت عددی بین مثلا
O(log n), O(n log n)
درک نکردند و دوتا دلیل هم داره؛

۱- پردازنده‌ها سرعت بسیار بالایی دارند.
۲- هیچوقت روی دیتاهای خیلی حجیم کار نکردند.

برای همین گشتم تا یک جدولی رو پیدا کنم؛ که الگوریتم‌ها رو با زمان اجرا اونها مقایسه کنه!

مثلاً توی این جدول ñ² رو با n مقایسه کنید؛ برای ۱ میلیون ورودی!

دیگه همینجوری for تو در تو ننویسید!

پ.ن:
برای !n هم مسئله داریم توی دنیای کامپیوتر، فروشنده دوره‌گرد

این یکی هم مقایسه سرعت عملکرد CPU نسبت به گرفتن داده هست!

دلیل پافشاری من بر اینکه؛ حتماً concurrency رو یاد بگیرید هم همین هست!

خوندنش اینطوری هست؛ ۱ سیکل سی‌پی‌یو (توی چند نسل قبل اینتل ۱۴ تا instruction می‌تونست انجام بده) رو اگر فرض کنیم ۱ ثانیه زمان میبره (زمان واقعی‌تر ستون وسط هست)

خوندن داده از سریعترین رم‌های موجود؛ ۶ دقیقه می‌شه به نسبت اون! و خوندن از درایو SSD (بسته به سرعت و ...) مثل این می‌مونه که بین ۲ تا ۶ روز زمان ببره!
و اگر async کد نمی‌زنید توی تمام این مدت CPU شما بیکار هست، باید صبر کنه تا اون داده‌ها بهش برسه!

حالا می‌تونید قشنگ درک کنید که چرا می‌گیم تسک‌های I/O bound رو حتماً async کنید‌.

#خارج_از_بحث

پست قبلی یک کلمه غلط املایی داشت؛
اصرار رو من اسرار نوشتم که باید بگم!

I don't give a shit about it ...

بعد یک پستی گذاشتم؛ که چندتا از دوستان لطف کردند پیام دادند که فرم درست این کلمه اصرار هست، توضیح دادم با این منظور که آقا کلمه رو بی‌خیال اگر مفهوم رو متوجه شدید من کارم رو کردم (البته که ازین دوستان ممنونم که انقدر دقیق پست‌ها رو می‌خونند و اهمیت میدند، خداییشم خیلی‌ها مودبانه این موضوع رو مطرح کردن) برای همین کلمه رو به پافشاری تغییر دادم.

ولی ازونجایی که توی هر جمعی چندتا بیشعور هم هست؛ بعضی‌ها با کلمات و لحن نامناسب جواب دادند.

خطاب به این بی‌شعورها؛
یاد هزاران بار؛ مصاحبه‌ها، دمو محصول برای مدیران و دانشگاه افتادم ...

وقتایی که یک بحث تخصصی رو انجام می‌دادی؛ یک محصول رو نشون میدادی یا ...
و همگی لال بودند، چون سواد نداشتند و مغزشون به این بحث‌ها نمی‌کشید.
بعد در آخر جلسه؛ می‌گفتن چرا رنگ بنر رو آبی نکردی ؟ چرا اسلایدت فونت Arial نبود و ...

پست‌های قبلی گواه این موضوع هستند؛ گروهی که به کانال متصل بود بیشتر!

توی مملکت ما یکسری آدم عقده‌ای هستند، که برای اینکه بتونند عذاب وجدان بی‌سوادی رو از روی دوش خودشون بردارند، نشستند تا ازت ایراد بگیرند. اما چون سواد تخصصی ندارند ایراد گرفتن‌هاشون دقیقاً مثال‌هایی هست که زدم.

اینارو گفتم، چون توی کانال‌های باقی دوستان بدتر از این‌ها رو دیدم (مخصوصاً اونهایی که به گروه وصل هستند)
همه مثل من بی‌ادب و بی‌اعصاب نیستند که همونجا جواب بدند، خیلی‌ از بچه‌های متخصص بی‌انگیزه می‌شوند.

اما برای دوستان متخصص:

پیشنهادمم اینه که، نه تنها نادیده بگیرید بلکه این افراد رو از گروها و کانال‌هاتون بن کنید!

همونجوری که کسی آدم لاابالی رو توی مهمونیش دعوت نمی‌کنه؛ تو میزبان این مهمونی هستی بذار مهمونات لذت ببرند، تمرکزت رو بذار روی لذت اون‌هایی که دعوتند.

بازهم ممنون از دوستانی که فقط برای درست بودن پست پیام دادند، نه برای ماهی گیری از آب گل آلود.

اینو می‌خواستم توی یک کانال دیگری بذارم ولی دیدم بحث انتخاب اشتباه دیتابیس اینجا بوده اینجا می‌ذارم!

۵-۶ ماه پیش، یکی سوال پرسیده بود آقا من پستگرسم هی به مشکل میخوره روی پروژه‌ام!

من هی میومدم کمک کنم، هر سوالی می‌پرسیدم یا جواب نمی‌داد (انگار داشت ناسا رو هک می‌کرد) یا نمی‌دونست.

چندبار بهش گفتم تا مشکل رو پیدا نکنم نمی‌شه به راهکار رسید
ولی
آخر عصبی شدم؛ گفتم برو sqlite بزن! واقعاً منظورم این نبود که اینکارو بکنه می‌خواستم بفهمه که اینجوری نمیشه راهنمایی کرد و البته دیگه پیام نده.

الان پیام داد، تشکر کرد بابت پیشنهاد sqlite (صحبت کردم باهاش اجازه گرفتم این پست رو بذارم) منم توضیحات بالا رو دادم بهش ....

بعد توی همین صحبت فعلی متوجه شدم؛ دیتابیس برای کار ایشون واقعاً در همین حد sqlite زیادم بوده؛ کل دیتابیس‌اش بعد از ۶ ماه کار به کمی کمتر از ۱۰۰ مگ رسیده (البته ازینجا به بعد سرعت رشدش کمتر می‌شه شاید سالی ۲۰-۳۰ مگ)

برای بکاپ هم بهش گفتم بذار برای خودت ایمیل کنه هر ۶ ساعت؛ واقعاً رفت اینم پیاده‌سازی کنه! 😂


خلاصه که تا ی چیزی توی ویدئو آموزشی می‌بینید نپرید سراغش؛ یک مقدار تحقیق بد هم نیست!

تجربه جالبی هم بود برای خودم!

#یکبار_برای_همیشه

خیلی دیدم؛ دوستانی که از لینوکس دسکتاپ استفاده می‌کنند پارتیشن Swap رو تحت همه شرایط فعال می‌کنند.
بعضی‌ وقتا حتی تا ۱۶ گیگ روی لپ‌تاپ با رم ۱۶ گیگ دیدم بهش هارد اختصاص دادند.

اولاً که؛ ۹۹.۹٪ روی Desktop و یوزر عادی نباید اصلا کار به Swap بکشه؛ توی باقی موارد هم برای ۱۶ گیگ رم نهایتاً ۱-۲ گیگ باید باشه که به محض اینکه دیدید رم درحال پرشدن هست؛ قبل از هنگ سیستم بتونید مشکل رو حل کنید.

اینکه خیلی از مدرسین لینوکس، هی میگن swap رو فعال کنید و ... رو هم نمی‌فهمم!
اگر از تاریخچه‌اش بگذریم (اگر خواستید بخونید باید دنبال این باشید، از llm کمک بگیرید)
1970s Virtual memory on IBM OS/360 or Unix

این virtual memory یا نوع پیشرفته تر امروزش به اسم swap برای این اومد که سیستم‌عامل‌ها برای multi-task مشکل رم داشتند و چون تکنولوژی رم حجم بالا اون موقع نبود ازین تکنیک استفاده کردند.

امروزه فقط برای اینکه، به ادمین سرور وقت بده تا قبل از هنگ کردن یا .... سرور مشکل رو حل کنه استفاده می‌شه!

که ۹۹.۹٪ کاربرهای دسکتاپ این مشکل رو ندارند (نهایتاً ری‌استارت می‌کنید، سرور که نیست بگی صدای یوزرهام در میاد) و استفاده از swap فقط باعث افت سرعت سیستم و هنگ کردن بسیار براشون می‌شه بخصوص اونایی که swappiness رو هم کانفیگ نمی‌کنند.

چه تغییرات قشنگی داریم روی؛ PostgreSql 18 شماهم دیدید ؟
برای من سه موردش خیلی جذاب هست؛
اولیش بالاخره؛ Asynchronous I/O بله منم خوندم فعلا فقط روی Read ولی همینم خوبه ۲-۳ برابر سرعت بیشتر اونم مفتی کیه که بدش بیاد ؟

دومیش؛ پشتیبانی کامل از UUIDv7 یعنی بدون دردسر می‌تونی حتی روی distributed system هم primary key کاملا یونیک داشته باشی.
تازه اگر پست‌های قبلی رو دنبال کرده باشید می‌دونید UUIDv7 برای ایندکس هم عملکرد بهتری داره (مشکلی که خیلی از پروژه‌ها با UUIDv4 داشتند و حالا تقریبا حل شده)

نهایتا یک سری Optimization های خاص که بصورت اتومات کوئری شما رو قبل از اجرا بهبود میده مثلا اگر OR زیاد باشه و بشه با Any تغییرش میده و ...


و یک اشاره هم بکنم به این پست (حدودا همین موقع‌ها ۲ سال پیش):
https://t.iss.one/pyHints/117
هنوزم دیر نشده؛ وقت بذارید براش و درکش کنید!


پ.ن؛
از دوستان اشاره کردند، created_at هم اگر یادمون بره به چخ نمی‌ریم 😁
شوخی خوبی بود، اگر نگرفتید:
بخاطر این هست که UUIDv7 بر اساس زمان هست

👆👆👆👆👆

هر ۵ تا کتابی که گفتم + ۱ کتاب هم شما گفتید همرو خوندم.

اگر تا حالا اصلا سراغ FastApi نرفتید و خیلی با مفاهیم بکند هم آشنا نیستید؛ هرکدوم از کتاب‌ها که تاریخ 2024 یا 2025 خورده رو می‌تونید بخونید!

اما اگر ۳ ساعت بیشتر روی FastApi وقت گذاشتید؛ هیچکدوم از کتاب‌ها بدرد شما نخواهد خورد!

داکیومنت FastApi رو بخونید!
داکیومنت ابزارهایی که معرفی کرده رو بخونید مثل celery یا sqlmodel بطور استثنا برای sqlalchemy کتاب خوب داریم (سرچ کنید میاد)

نگاهی هم به اسپانسرهاش و پروژه‌های open-source که باهاش نوشته شده بندازید که خودش یک دانشگاه هست!


متاسفم، کتابی برای این مورد نمی‌تونم معرفی کنم.
چون کتاب درخوری ندیدم