چگونه Database مناسب را انتخاب کنیم؟
راهنمای انتخاب پایگاهداده بر اساس شکل داده، تراکنش، پرسوجو و عملیات — با ارجاع به مستندات PostgreSQL، MySQL، MongoDB، Redis و راهنمای انتخاب موتور AWS RDS.
بنیانگذار و مهندس محصول
انتخاب Database (پایگاهداده) یکی از تصمیمهای برگشتناپذیرِ نسبتاً گران در سالهای اول محصول است. مهاجرت شِما، بازنویسی پرسوجو، و عادت تیم زمان میبرد. با این حال، انتخاب را نباید به «چه چیزی روی گیتهاب ستاره دارد» واگذار کرد.
موتورهای رایج کار یکسانی نمیکنند. PostgreSQL روی مدل شیء-رابطهای، قیود و تراکنش تأکید دارد؛ MySQL برای بارهای وب تراکنشی ساده و سازگاری ابزار گسترده شناخته میشود؛ MongoDB سندمحور است؛ Redis حافظهای برای دسترسی سریع و ساختارهای ویژه. راهنمای AWS RDS هم صریحاً میگوید MySQL و PostgreSQL را بر اساس نوع کار انتخاب کنید نه برچسب کلی.
این مقاله از مدل داده و Use Case شروع میکند؛ سپس ترکیب لایهها را توضیح میدهد. پیشنیاز مفهومی: مقالات ۰۳۳ تا ۰۳۵.
پاسخ کوتاه
اگر داده رابطهای است، تراکنش و قیود مهماند و پرسوجو پیچیده میشود، از یک پایگاه رابطهای بالغ (اغلب PostgreSQL یا MySQL بر اساس اکوسیستم تیم) شروع کنید. اگر اسناد متغیر و دسترسی سندوار غالب است، موتور سند را برای همان بخش بررسی کنید. Redis را معمولاً کنار منبع حقیقت برای کش، نشست، محدودیت نرخ و ساختارهای لحظهای بگذارید — نه بهعنوان تنها دفترکل سفارشها.
یک محصول میتواند چند موتور داشته باشد؛ شرطش مالکیت روشن و مرز همگامسازی است. چند موتور بدون مرز، فقط چند نقطهٔ شکست است.
اول بپرسید داده چه شکلی است و چه اشتباهی نباید ممکن باشد؛ بعد برند را گوگل کنید.
سؤالهای قبل از نام برند
- موجودیتهای اصلی و روابطشان چیست؟
- کدام تغییرات باید «یا همه یا هیچ» باشند؟
- پرسوجوهای گزارش چگونه به نظر میرسند؟
- شِما چقدر پایدار است و چه کسی آن را تغییر میدهد؟
- حجم رشد سالانه و الگوی خواندن/نوشتن چیست؟
- الزام پشتیبانگیری، نقطهٔ بازگشت و انطباق چیست؟
اگر جوابها را ندارید، جلسهٔ انتخاب موتور زود است؛ جلسهٔ کشف دامنه دیر شده.
جدول تطبیق کار با خانوادهٔ موتور
| نیاز غالب | خانواده | نمونهٔ رسمی برای مطالعه |
|---|---|---|
| روابط، قیود، SQL، تراکنش | رابطهای | PostgreSQL / MySQL docs |
| سند JSON با شِمای متغیر | سندمحور | MongoDB manual |
| تأخیر بسیار کم، کش، شمارنده، pub/sub | حافظهای / ساختار داده | Redis docs |
| جستجوی متنی سنگین | جستجو (جدا یا افزونه) | بسته به پشته؛ با منبع حقیقت قاطی نکنید |
PostgreSQL — وقتی صحت و پرسوجوی غنی مهم است
مستندات PostgreSQL آن را ORDBMS متنباز با پرسوجوی پیچیده، کلید خارجی، تریگر، نمای قابلبهروزرسانی، یکپارچگی تراکنشی و MVCC معرفی میکند و بر توسعهپذیری (نوع، تابع، ایندکس، زبان رویهای) تأکید دارد. برای SaaS با منطق تجاری، گزارشهای چندجدولی، و دادهٔ ترکیبی JSON+رابطهای، نقطهٔ شروع بسیار رایج و منطقی است.
AWS در راهنمای انتخاب موتور RDS میگوید اگر به JSON پیشرفته، پرسوجوی پیچیده یا افزونهها نیاز دارید به PostgreSQL فکر کنید. این توصیهٔ تناسب است نه حکم جهانی.
MySQL — وقتی وب تراکنشی و سازگاری ابزار مهم است
مرجع MySQL موتور را پایگاه رابطهای معرفی میکند و برای کاربردهای وب و عملیات تراکنشی ساده در راهنماهای ابری اغلب کنار Postgres بهعنوان شروع پیشنهادی میآید. AWS میگوید MySQL را وقتی سازگاری گسترده با ابزار/فریمورک یا بار تراکنشی ساده دارید در نظر بگیرید.
اگر تیم و ابزارهای موجود عمیقاً MySQL هستند و کار شما در همان قاب میگنجد، تعویض به Postgres فقط بهخاطر مقالات مقایسهای هزینهٔ بیدلیل است. اگر میدانید GIS، CTEهای پیچیده یا افزونههای خاص مسیر شماست، همان اول Postgres را جدیتر وزن دهید.
MongoDB — وقتی سند طبیعی است
MongoDB را وقتی انتخاب نزدیک است که واحد طبیعی کارتان سند است (پروفایل انعطافپذیر، کاتالوگ با ویژگیهای متغیر، محتوای تو در تو) و joinهای سنگین مرکز دامنه نیستند. اگر مدام حس میکنید باید تراکنش چندسندۀ پیچیده و گزارش رابطهای قوی را به زور داخل سند جا دهید، شاید مدل دامنه رابطهایتر از فرض اولیه است.
اشتباه رایج: انتخاب سندمحور فقط چون «شِماレス راحت است». شِما همیشه هست؛ یا در دیتابیس enforce میشود یا در کد و در سر توسعهدهندگان پخش میشود.
Redis — لایهٔ سریع، نه جایگزین دفترکل
Redis Docs آن را data store حافظهای برای کش، ساختار داده، استریم و پیام معرفی میکند. برای نشست، rate limit، صف سبک، لیدربورد و کش نتیجهٔ گران مناسب است. بهعنوان تنها محل ذخیرهٔ پرداخت و موجودی، مگر با طراحی دوام صریح و پذیرش ریسک، خطرناک است.
الگوی سالم: منبع حقیقت رابطهای یا سند + Redis برای مسیر داغ خواندن/شمارش. باطلسازی کش را از روز اول طراحی کنید.
الگوی تصمیم ۳۰ دقیقهای
- روی کاغذ چهار موجودیت اول و روابطشان را بکشید.
- دو تراکنش حیاتی را به زبان کسبوکار بنویسید.
- سه گزارش مدیریتی را بهصورت سؤال بنویسید.
- اگر روابط و تراکنش غالب بود → رابطهای را پیشفرض بگیرید.
- اگر یک بخش واقعاً سندوار بود → همان بخش را جدا ارزیابی کنید.
- گلوگاه خواندن را بعد از ایندکس درست با کش جواب دهید نه قبلش.
چند موتور یا یکی؟
شروع با یک موتور قوی معمولاً درست است. موتور دوم را وقتی اضافه کنید که Use Case متفاوت و مرز همگامسازی مشخص دارید. همگامسازی دو منبع حقیقت بدون قرارداد، از خود انتخاب موتور خطرناکتر است.
عملیات را در انتخاب بگذارید
- پشتیبانگیری و تمرین Restore.
- مانیتورینگ قفل، Replication lag، و فضای دیسک.
- مسیر مهاجرت شِما بدون downtime طولانی.
- مهارت تیم on-call در موتور انتخابی.
موتوری که کسی نمیتواند شب عیبیابی کند، روی کاغذ مقیاسپذیر و در عمل شکننده است.
جمعبندی
دیتابیس را با شکل داده، نیاز تراکنش، الگوی پرسوجو و توان عملیات انتخاب کنید. PostgreSQL و MySQL برای بسیاری از سیستمهای رابطهای نقطهٔ شروعاند؛ MongoDB وقتی سند طبیعی است؛ Redis کنار منبع حقیقت برای سرعت. «بهترین دیتابیس» بدون معیار وجود ندارد.
منابع و مراجع
- PostgreSQL — What Is PostgreSQL?: https://www.postgresql.org/docs/current/intro-whatis.html
- MySQL 8.4 — What is MySQL?: https://dev.mysql.com/doc/refman/8.4/en/what-is-mysql.html
- MongoDB Manual — Introduction: https://www.mongodb.com/docs/manual/introduction/
- Redis Docs — Get started: https://redis.io/docs/latest/get-started/
- AWS RDS Getting Started — Choosing your database engine: https://docs.aws.amazon.com/AmazonRDS/latest/gettingstartedguide/choosing-engine.html
این هفته مدل دادهٔ مسیر حیاتی را بدون نام برند روی تخته بکشید؛ بعد موتور را نام ببرید.
نویسنده
سهیل ابراهیمپور بنیانگذار FutureForge است. روی طراحی محصول، معماری و استقرار نرمافزار سفارشی کار میکند.
یادداشتهای مرتبط
اگر در انتخاب معماری یا مسیر توسعه مطمئن نیستید، میتوانید درباره پروژه صحبت کنیم.
مسئله و محدودیت را بنویسید. اگر تطابق داشته باشیم، برای گفتگو هماهنگ میکنیم.
