چرا Async تو کار با دیتابیس همیشه کار امد نیست؟ 🧵

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

🧠 چرا Async تو دیتابیس تأثیر کمی داره؟

وقتی با دیتابیس کار می‌کنین (مثل PostgreSQL، MySQL یا MongoDB)، عملیات‌ها مثل خوندن (SELECT)، نوشتن (INSERT) یا آپدیت کردن معمولاً CPU-bound هستن، نه I/O-bound. حالا این یعنی چی؟

‏CPU-bound:
یعنی گلوگاه اصلی تو عملیات، پردازش CPUئه. مثلاً وقتی یه کوئری SQL اجرا می‌کنی، دیتابیس باید کارایی مثل پارس کردن کوئری، بهینه‌سازی پلن، پردازش داده‌ها و مرتب‌سازی رو انجام بده. اینا همشون به CPU وابسته‌ان.

‏I/O-bound:
یعنی گلوگاه اصلی منتظر موندن برای ورودی/خروجی (مثل خوندن از دیسک یا شبکه). Async تو این سناریوها خوب عمل میکنه چون می‌تونه CPU رو آزاد کنه تا وقتی منتظر I/O هستیم، کارهای دیگه انجام بده.

دیتابیس‌ها معمولاً تو محیط‌های خودشون بهینه شدن که عملیات CPU-bound رو سریع انجام بدن (مثل استفاده از ایندکس‌ها یا کش). برای همین، وقتی از یه کلاینت (مثل یه برنامه پایتون) به دیتابیس وصل می‌شین، بیشتر زمان صرف پردازش کوئری تو خود دیتابیسه، نه منتظر شبکه یا دیسک. حالا Async (مثل async/await تو پایتون) اینجا کمک زیادی نمی‌کنه، چون CPU داره کار اصلی رو انجام می‌ده و چیزی برای "منتظر موندن" وجود نداره.

مثال ساده:
فرض کنین یه کوئری سنگین مثل این تو PostgreSQL دارین:

SELECT * FROM orders WHERE total > 1000 ORDER BY created_at;

این کوئری CPU دیتابیس رو حسابی درگیر می‌کنه (برای فیلتر کردن و مرتب‌سازی). حالا اگه تو پایتون اینو با یه کلاینت sync (مثل psycopg2) یا async (مثل asyncpg) اجرا کنین، تفاوت سرعت خیلی کمه، چون گلوگاه اصلی تو خود دیتابیسه، نه تو کلاینت.

📚 چرا Async همیشه مفید نیست؟

وقتی از یه کلاینت Async استفاده می‌کنین (مثل asyncpg یا motor برای MongoDB)، انتظار دارین عملیات دیتابیس سریع‌تر بشه چون می‌تونه همزمان کارهای دیگه رو انجام بده. اما چندتا دلیل باعث می‌شه این تأثیر کم باشه:

1⃣ گلوگاه تو دیتابیسه:
همون‌طور که گفتم، بیشتر عملیات دیتابیس CPU-bound هستن. Async فقط می‌تونه I/O شبکه رو مدیریت کنه (مثل زمان ارسال کوئری یا گرفتن نتیجه)، ولی این بخش معمولاً کسری از کل زمانه.

2⃣ ‏Overhead خود Async: استفاده از async/await یه مقدار سربار (overhead) به کد اضافه می‌کنه. اگه عملیات دیتابیستون سریع باشه (مثلاً چند میلی‌ثانیه)، این سربار ممکنه حتی باعث شه Async کندتر بشه.

3⃣ مدیریت اتصالات:
دیتابیس‌ها معمولاً تعداد اتصالات همزمان (connection pool) رو محدود می‌کنن. حتی با Async، اگه تعداد کوئری‌ها زیاد باشه، ممکنه منتظر اتصال بمونین.

🔍 کی Async به کار میاد؟

هرچند Async تو اکثر عملیات دیتابیس تأثیر زیادی نداره، تو یه سری سناریوها می‌تونه خوب عمل کنه:

1⃣ دیتابیس‌های توزیع‌شده:
تو دیتابیس‌های NoSQL مثل MongoDB یا Cassandra که عملیات شبکه‌ای (مثل اتصال به نودهای مختلف) زمان‌بره، Async می‌تونه کمک کنه کلاینت همزمان چند درخواست رو مدیریت کنه.

2⃣ عملیات I/O-heavy:
اگه دیتابیستون روی یه سرور دور باشه یا شبکه کند باشه، Async می‌تونه زمان انتظار برای اتصال و انتقال داده رو بهتر مدیریت کنه.

3⃣ چندین درخواست همزمان:
اگه برنامه‌تون نیاز داره چند کوئری رو به‌صورت موازی اجرا کنه (مثل یه API که باید از چند جدول داده جمع کنه)، Async می‌تونه این درخواست‌ها رو همزمان مدیریت کنه.

4⃣ دیتابیس‌های خاص:
بعضی دیتابیس‌ها مثل CockroachDB یا Redis که برای عملیات سریع و توزیع‌شده طراحی شدن، با کلاینت‌های Async بهتر کار می‌کنن.

✍ جمع‌بندی
اینکه بگیم Async تو کار با دیتابیس معجزه می‌کنه یه کم زیاده‌رویه چون بیشتر عملیات دیتابیس CPU-bound هستن، استفاده از کلاینت‌های Async مثل asyncpg یا motor معمولاً تأثیر چشمگیری روی پرفورمنس نداره. اما تو سناریوهای خاص مثل دیتابیس‌های توزیع‌شده، عملیات شبکه‌محور یا درخواست‌های موازی، Async می‌تونه مفید باشه. پس قبل از اینکه همه‌چیز رو Async کنین، نوع عملیات‌تون رو بررسی کنین و ببینین کجا واقعاً به کارتون میاد.

#️⃣ #web #programming #db

➖➖➖➖➖➖➖➖➖➖ 

🥷🏻 CHANNEL | GROUP