راهنمای خرید سرور اختصاصی برای دیتابیس: چقدر رم، دیسک NVMe و CPU لازم دارید؟

وقتی دیتابیس یک اپلیکیشن از چند صد هزار رکورد فراتر می‌رود، اولین چیزی که کند می‌شود معمولاً CPU نیست؛ دیسک و رم هستند. خیلی از تیم‌ها سراغ خرید سرور اختصاصی برای دیتابیس می‌روند بدون اینکه بدانند دقیقاً چه مقدار رم، چه نوع دیسک و چند هسته واقعاً لازم دارند، و نتیجه یا اورکیل کردن بودجه است یا خرید یک پلن که شش ماه بعد جواب نمی‌دهد.

این راهنما سه پارامتر اصلی را جداگانه بررسی می‌کند: رم، دیسک و CPU، و در پایان یک جدول برای انتخاب پلن بر اساس اندازه‌ی واقعی بار کاری می‌آورد.

چرا سرور اختصاصی و نه VPS یا هاست اشتراکی؟

روی هاست اشتراکی یا VPS‌های ارزان، منابع I/O بین چند مشتری روی یک هایپروایزر مشترک است. برای یک وب‌سایت این مشکل ایجاد نمی‌کند، اما دیتابیس به طور مداوم دیسک را می‌خواند و می‌نویسد و نسبت به نویز همسایه‌ها (noisy neighbor) حساس است.

روی سرور اختصاصی، کل منابع فیزیکی در اختیار خود شماست: نویز همسایه وجود ندارد، IOPS دیسک قابل پیش‌بینی است و می‌توانید RAID و تنظیمات دیسک را دقیقاً متناسب با موتور دیتابیس خودتان (MySQL، PostgreSQL، MongoDB و…) بچینید. اگر هنوز بین این دو گزینه مردد هستید، تفاوت هاست اشتراکی و سرور مجازی (VPS) را هم ببینید.

چقدر رم برای دیتابیس لازم است؟

قانون ساده این است: رم کافی یعنی working set دیتابیس شما در حافظه جا شود، نه کل حجم دیتابیس.

working set یعنی بخشی از داده که واقعاً در کوئری‌های روزمره خوانده و نوشته می‌شود — نه آرشیو قدیمی که یک بار در ماه به آن مراجعه می‌شود. اگر جدول سفارش‌ها ۲۰۰ گیگابایت باشد ولی ۹۰ درصد کوئری‌ها فقط سفارش‌های سه ماه اخیر را می‌خوانند، working set واقعی چیزی نزدیک به حجم همان سه ماه است.

محاسبه‌ی سریع working set

برای شروع می‌توانید این تخمین را به کار ببرید:

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

تنظیمات واقعی در MySQL و PostgreSQL

در MySQL با InnoDB، innodb_buffer_pool_size معمولاً ۷۰ تا ۸۰ درصد کل رم سرور تنظیم می‌شود. اگر working set شما ۳۰ گیگابایت است، سرور با ۴۰ تا ۴۸ گیگابایت رم منطقی‌تر از سروری با ۱۶ گیگابایت است — چون در آن حالت هر کوئری‌ای که خارج از کش می‌افتد باید از دیسک بخواند.

در PostgreSQL همین منطق با shared_buffers و کش سطح سیستم‌عامل برقرار است؛ PostgreSQL علاوه بر بافر داخلی، به کش OS هم برای فایل‌های دیتابیس متکی است، پس رم آزاد سیستم هم نقش دارد، نه فقط عدد shared_buffers. برای دیتابیس‌های حساس به دسترس‌پذیری، راه‌اندازی Replication و Failover خودکار در PostgreSQL روی دو سرور جداگانه هم قدم بعدی طبیعی است.

اگر مطمئن نیستید working set چقدر است، از مانیتورینگ hit ratio بافر کش شروع کنید: اگر پایین‌تر از ۹۵ درصد است، معمولاً رم کم است، نه چیز دیگری.

چرا NVMe و IOPS مهم‌تر از ظرفیت دیسک هستند

خیلی از خریدها بر اساس گیگابایت دیسک تصمیم‌گیری می‌شوند، در حالی که برای دیتابیس متغیر مهم‌تر IOPS و latency است، نه فضای خالی.

یک دیسک SATA SSD معمولی چیزی حدود ۹۰ هزار IOPS تصادفی می‌دهد، در حالی که یک NVMe روی همان کلاس سرور می‌تواند به چند صد هزار تا بیش از یک میلیون IOPS برسد، آن هم با latency به‌مراتب پایین‌تر. برای دیتابیسی که همزمان چند صد کانکشن کوئری می‌زند، این تفاوت مستقیماً روی زمان پاسخ هر تراکنش دیده می‌شود.

نکته‌ی عملی: دیسکی با ۴ ترابایت فضا ولی IOPS پایین، برای یک دیتابیس پرترافیک از یک NVMe ۵۰۰ گیگابایتی با IOPS بالا ضعیف‌تر عمل می‌کند. اول IOPS و latency را مشخص کنید، بعد ببینید همان کلاس دیسک چه ظرفیتی هم به شما می‌دهد.

RAID مناسب برای دیتابیس

برای دیتابیسی که هم خواندن و هم نوشتن زیاد دارد، RAID 10 معمولاً انتخاب مناسبی است: هم افزونگی دیتا در برابر خرابی دیسک را می‌دهد و هم روی نوشتن پنالتی سنگینی نسبت به RAID 5/6 ندارد. RAID 5 برای بار کاری با نوشتن سنگین (که اکثر دیتابیس‌های تراکنشی همین‌طورند) به‌خاطر write penalty گزینه‌ی خوبی نیست. جزئیات پیاده‌سازی را می‌توانید در پیکربندی RAID نرم‌افزاری با mdadm (RAID 1، RAID 5 و RAID 10) ببینید.

انتخاب CPU: تعداد هسته یا فرکانس بالاتر؟

برای اکثر دیتابیس‌های رابطه‌ای، تعداد کانکشن‌های همزمان مهم‌تر از فرکانس تک‌هسته است. اگر اپلیکیشن شما صدها کانکشن همزمان به دیتابیس باز می‌کند، تعداد هسته‌ی بیشتر (مثلاً ۸ تا ۱۶ هسته) معمولاً از یک CPU با فرکانس بالاتر ولی هسته‌ی کمتر بهتر جواب می‌دهد.

از طرف دیگر، کوئری‌های سنگین تحلیلی یا عملیات‌هایی که روی یک ترد اجرا می‌شوند (مثل بعضی نوشتن‌های ترتیبی) از فرکانس بالاتر تک‌هسته سود می‌برند. اگر بار کاری شما ترکیبی از OLTP روزمره و گزارش‌گیری دوره‌ای است، CPU با هسته‌ی نسبتاً زیاد و فرکانس متوسط رو به بالا، تعادل بهتری می‌دهد.

جدول انتخاب پلن بر اساس اندازه‌ی بار کاری

این جدول نقطه‌ی شروع است، نه فرمول قطعی؛ عدد دقیق را با مانیتورینگ بافر کش و latency دیسک روی بار کاری واقعی خودتان تنظیم کنید.

چک‌لیست قبل از خرید

پیش از ثبت سفارش سرور اختصاصی، این موارد را یک‌بار مرور کنید:

• working set واقعی دیتابیس را از روی کوئری‌های پرتکرار، نه حجم کل جدول‌ها، محاسبه کرده‌اید.
• رم انتخابی حداقل به اندازه‌ی working set به‌علاوه‌ی ایندکس‌ها هست.
• دیسک NVMe است، نه SATA SSD، و IOPS تضمین‌شده مشخص است.
• پیکربندی RAID با الگوی خواندن/نوشتن دیتابیس شما (نه یک تنظیم پیش‌فرض) انتخاب شده.
• تعداد هسته با تعداد کانکشن همزمان اپلیکیشن هم‌خوانی دارد.
• امکان ارتقای بعدی رم و دیسک بدون تعویض کل سرور وجود دارد — برای خود دیسک، مدیریت دیسک با LVM این ارتقا را بدون Downtime ممکن می‌کند.

جمع‌بندی

خرید سرور اختصاصی برای دیتابیس با حدس زدن جواب نمی‌دهد. رم باید بر اساس working set واقعی محاسبه شود نه حجم کل دیتابیس، دیسک باید بر اساس IOPS و latency انتخاب شود نه فقط ظرفیت، و CPU باید با تعداد کانکشن‌های همزمان اپلیکیشن هماهنگ باشد.

اگر می‌خواهید بدون حدس‌زدن یک پلن مناسب انتخاب کنید، پلن‌های سرور اختصاصی آریانت را ببینید؛ پیکربندی رم، NVMe و RAID برای هر سه سطح بار کاری بالا از قبل آماده است و در صورت رشد دیتابیس هم قابل ارتقا است. برای بار کاری دیگری که رم و CPU زیاد می‌خواهد، راهنمای خرید سرور برای اجرای هوش مصنوعی و مدل‌های زبانی (LLM) را هم ببینید.