MongoDB چیست؟ یک سیستم مدیریت پایگاه داده با مدل سندی است که داده را در سندها و مجموعه‌ها نگهداری می‌کند. برای برنامه‌ای که داده‌های آن ساختار تو‌در‌تو یا ویژگی‌های متغیر دارند، این مدل می‌تواند مناسب باشد. انتخاب آن باید از الگوی خواندن و نوشتن برنامه شروع شود، نه صرفاً محبوبیت نام محصول.
مدل داده در MongoDB چیست؟
سند از فیلد و مقدار تشکیل می‌شود و مقدار می‌تواند آرایه یا سند دیگری باشد. قالب ذخیره‌سازی BSON است؛ نمایش شبیه JSON در ابزارها به معنی ذخیرهٔ سادهٔ فایل متنی JSON نیست. مجموعه یا collection گروهی از سندها را در خود جای می‌دهد.
برای نمونهٔ مفهومیِ اطلاعات یک سرویس میزبانی:
{
"service": "demo-hosting",
"features": ["ssl", "daily-report"],
"limits": {"sites": 3}
}این داده صرفاً نمونهٔ آموزشی است و مشخصات هیچ پلن تجاری را اعلام نمی‌کند. اگر برنامه بیشتر همین اطلاعات را با هم می‌خواند، نگهداری آن‌ها در یک سند قابل بررسی است.
انعطاف ساختار به معنی بی‌نیازی از طراحی نیست
طبق راهنمای مدل‌سازی MongoDB، سندهای یک مجموعه الزاماً فیلدهای یکسان ندارند و می‌توان اعتبارسنجی ساختار تعریف کرد. رابطه‌ها نیز با جاسازی داده یا ارجاع مدل می‌شوند. باید تصمیم بگیرید کدام داده با هم خوانده می‌شود و کدام بخش مستقلاً تغییر می‌کند.
اگر دادهٔ مشترک را در سندهای زیادی تکرار کنید، اصلاح آن به هماهنگی بیشتری نیاز دارد. برعکس، ارجاع دادن همه‌چیز بدون توجه به مسیر دسترسی می‌تواند پرس‌وجو را پیچیده کند. این انتخاب بخشی از طراحی برنامه است و MongoDB آن را خودکار برای شما حل نمی‌کند.
آیا همهٔ داده‌ها در RAM هستند؟
خیر. در استقرار معمولِ خودمدیریت با موتور WiredTiger، فایل داده و journal روی دیسک و حافظهٔ نهان برای کمک به کارایی استفاده می‌شوند. ظرفیت RAM، سرعت ذخیره‌ساز و اندازهٔ مجموعهٔ دادهٔ فعال همگی اهمیت دارند. تصور «حذف کامل دیسک» مبنای درستی برای انتخاب سرور نیست.
تراکنش، تکثیر و شاردینگ
- تراکنش چندسندی برای عملیات مرتبط وجود دارد؛ در استقرارهای replica set و sharded cluster قابل استفاده است و هزینهٔ اجرایی دارد.
- Replica Set نسخه‌هایی از داده را روی چند عضو نگه می‌دارد تا دسترس‌پذیری بهتر شود. این قابلیت جای بکاپ مستقل را نمی‌گیرد.
- Sharding داده را میان چند ماشین تقسیم می‌کند. انتخاب shard key و شکل پرس‌وجو بر نتیجه اثر دارد؛ زیاد کردن تعداد سرور تضمین رفع گلوگاه نیست.
برای یک پروژهٔ کوچک، شروع با زیرساخت پیچیده بدون نیاز اندازه‌گیری‌شده می‌تواند هزینهٔ نگهداری را بالا ببرد. ظرفیت آینده را پیش‌بینی کنید، اما پیچیدگی را بر اساس شواهد اضافه کنید.
MongoDB یا MySQL؟
هیچ‌کدام در همهٔ بارهای کاری سریع‌تر نیستند. مدل داده، ایندکس‌ها، میزان هم‌زمانی، نیاز به join و تراکنش و منابع سرور تعیین‌کننده‌اند. یک نمونهٔ واقعی با حجم نزدیک به تولید بسازید و زمان پاسخ، مصرف حافظه و هزینهٔ نوشتن را مقایسه کنید.
برای سایت وردپرسی معمول، تعویض MySQL یا MariaDB با MongoDB یک تغییر سادهٔ تنظیمات نیست؛ سازگاری برنامه و درایورها شرط اول است. برای برنامهٔ اختصاصی نیز توان تیم در پایش، بازیابی و نگهداری را کنار قابلیت‌های فنی بسنجید.
مجوز و مسئولیت نگهداری
Community Server به‌صورت source-available و تحت مجوز SSPL عرضه می‌شود؛ اصطلاح متن‌باز را بدون توجه به مجوز دقیق به کار نبرید. نسخهٔ مدیریت‌شده و خودمدیریت نیز مسئولیت‌های یکسانی ندارند. پیش از انتخاب، به‌روزرسانی، دسترسی کاربران، حفاظت شبکه، بکاپ و آزمون بازیابی را در طراحی سرویس در نظر بگیرید.
مطالعهٔ مرتبط
بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.
