پست‌گرس‌کل کند نیست، استوریج شما کند است

در رویداد POSETTE، ارائه با عنوان «پست‌گرس کند نیست، استوریج شما کند است» به بررسی تأثیر عملکرد استوریج بر مقیاس‌پذیری PostgreSQL در مقیاس بزرگ پرداخت. این مقاله نگاهی به بنچمارک‌های انجام شده و معماری پیشنهادی برای اجرای پایتون یا پست‌گرس روی NVMe محلی دارد.

علائم پنج‌گانه مقیاس‌پذیری

هنگامی که حجم داده‌های PostgreSQL به صدها گیگابایت یا ترابایت می‌رسد، معمولاً با پنج مشکل رایج مواجه می‌شویم:

• کندی اینجست: پایپ‌لاین‌های داده با حجم بالای UPDATE و UPSERT با گذشت زمان کندتر می‌شوند.
• تأخیر ناپایدار در خواندن: بیشتر کوئری‌ها سریع هستند، اما برخی کوئری‌ها ناگهان بسیار کند می‌شوند.
• عقب افتادن VACUUM: با افزایش عملیات به‌روزرسانی، فرآیند پاکسازی از حجم داده‌های حجیم عقب می‌افتد.
• چک‌پوینت‌های کند: عملیات چک‌پوینت با بار کاری اصلی برای کسب منابع رقابت می‌کنند.
• تاخیر در ریپیکیشن منطقی: استریم کردن داده‌ها به سیستم‌هایی مثل Kafka با کندی مواجه می‌شود.

بنچمارک: NVMe محلی در برابر EBS

برای درک بهتر، آزمایشی روی یک مجموعه داده ۳.۳ میلیارد رصدی انجام شد. نتایج نشان داد که خوشه‌های مبتنی بر NVMe محلی توانسته‌اند میانگین تراکنش بر ثانیه (TPS) بسیار بالاتری را نسبت به فضای ذخیره‌سازی EBS ثبت کنند. میانگین تأخیر تراکنش‌ها از ۳۶.۹ میلی‌ثانیه به ۴.۰ میلی‌ثانیه کاهش یافت.

بیشتر تأخیر اضافی در EBS ناشی از انتظار برای پاسخگویی استوریج بود، نه درگیر بودن پردازنده. خواندن صفحات و همگام‌سازی WAL زمان زیادی را در EBS تلف می‌کنند.

اجرای PostgreSQL روی NVMe محلی در محیط پروداکشن

استفاده از NVMe محلی چالش دوام داده‌ها را به همراه دارد زیرا با از کار افتادن ماشین، داده‌های محلی نیز از دست می‌روند. معماری پیشنهادی برای حل این مشکل شامل موارد زیر است:

1. دسترسی بالا با دو استندبای: استفاده از ریپیکیشن همگام مبتنی بر کوئرم برای اطمینان از بقای داده‌ها.
2. بکاپ‌های مداوم روی Object Storage: استفاده از ابزارهایی مانند WAL-G برای آرشیو مداوم WAL و پشتیبان‌گیری فیزیکی.

شرکت‌هایی مانند Instacart و Datadog از این الگو برای پایداری و سرعت بالا استفاده می‌کنند.