برای اینکه بفهمیم مانگو دی‌بی چیه، اول باید ببینیم قبل از اون دنیا چه شکلی بود. سال‌ها، پادشاه بی‌چون‌وچرای دنیای دیتابیس‌ها، سیستم‌های مدیریت دیتابیس رابطه‌ای یا همون RDBMS بودن. اسم‌هایی مثل MySQL رو حتما شنیدید. این دیتابیس‌ها مثل یک جدول اکسل خیلی بزرگ و منظم عمل می‌کنن. همه چیز در قالب جدول‌ها، سطرها و ستون‌های از پیش تعریف شده ذخیره میشه. مثلا اگه یه دیتابیس برای دانشجوها داشته باشید، یه جدول دارید به اسم «دانشجو» با ستون‌های مشخص: شماره دانشجویی، نام، نام خانوادگی و… . این ساختار خیلی منظم و دقیقه و برای خیلی از کارها، مثل سیستم‌های مالی و حسابداری که داده‌ها ساختار کاملا مشخصی دارن، عالیه.
اما دنیای مدرن یه چالش جدید ایجاد کرد. با اومدن اپلیکیشن‌های موبایل، شبکه‌های اجتماعی و اینترنت اشیا (IoT)، ما با حجم عظیمی از داده‌هایی روبرو شدیم که همیشه ساختار مشخص و منظمی نداشتن. به این نوع داده‌ها میگن داده‌های بدون ساختار یا نیمه‌ساختاریافته. مثلا پست‌های یک شبکه اجتماعی رو در نظر بگیرید. یه پست میتونه فقط متن باشه، یکی دیگه عکس و متن داشته باشه، یکی ویدیو و کپشن، و یکی دیگه ترکیبی از همه اینها با کلی تگ و کامنت. جا دادن این همه تنوع توی جدول‌های خشک و بی‌روح SQL خیلی سخت و گاهی غیرممکن بود. توسعه‌دهنده‌ها به ابزاری نیاز داشتن که انعطاف‌پذیر باشه و بتونه با این داده‌های متنوع و نامنظم کار کنه. اینجا بود که دیتابیس‌های NoSQL (که مخفف Not only SQL هست) وارد میدون شدن و مانگو دی‌بی یکی از پرچم‌دارهای این نسل جدیده.
مانگو دی‌بی دقیقا چیه؟ خداحافظی با جدول‌ها
خب، بریم سر اصل مطلب. مانگو دی‌بی یک دیتابیس از نوع NoSQL و سند-گرا (Document-Oriented) هست. این یعنی چی؟ یعنی به جای اینکه داده‌ها رو توی سطر و ستون ذخیره کنه، اونها رو توی ساختارهایی شبیه به اسناد JSON ذخیره می‌کنه. اگه با برنامه‌نویسی جاوا اسکریپت آشنا باشید، حتما با JSON کار کردید. JSON یه فرمت متنی ساده برای نمایش داده‌ها به صورت زوج‌های «کلید-مقدار» هست. مثلا اطلاعات یه کاربر میتونه این شکلی باشه:
{
"نام": "سارا",
"نام_خانوادگی": "رضایی",
"سن": 25,
"علاقمندی‌ها": ["کتاب", "موسیقی", "سفر"]
}مانگو دی‌بی داده‌ها رو در قالبی به اسم BSON ذخیره می‌کنه که مخفف Binary JSON هست. BSON در واقع نسخه باینری یا دودویی JSON هست که کارایی بالاتری داره و از انواع داده‌ای بیشتری مثل تاریخ و داده‌های باینری هم پشتیبانی می‌کنه.
مزیت اصلی این مدل سند-گرا، انعطاف‌پذیری فوق‌العاده اونه. هر سند میتونه ساختار منحصر به فرد خودش رو داشته باشه. مثلا توی همون دیتابیس کاربرها، یه کاربر میتونه فیلد «ایمیل» داشته باشه و یکی دیگه نداشته باشه. یا یه کاربر فیلد «آدرس» داشته باشه که خودش شامل چند فیلد دیگه مثل شهر و خیابون هست. این ویژگی باعث میشه مدل داده‌ای دیتابیس شما خیلی به مدل داده‌ای اپلیکیشن شما نزدیک باشه و کار کردن باهاش برای توسعه‌دهنده‌ها خیلی راحت‌تر و سریع‌تر بشه. دیگه لازم نیست برای هر تغییر کوچیکی، کل ساختار دیتابیس رو عوض کنید.
معماری و اجزای اصلی مانگو دی‌بی
برای اینکه بهتر با کارکرد مانگو دی‌بی آشنا بشیم، بیایید اجزای اصلیش رو بشناسیم و با معادلشون توی دنیای دیتابیس‌های رابطه‌ای (RDBMS) مقایسه کنیم. این مقایسه کمک می‌کنه تصویر واضح‌تری تو ذهنتون شکل بگیره.
| جزء در مانگو دی‌بی | معادل در RDBMS | توضیحات |
|---|---|---|
| دیتابیس (Database) | دیتابیس (Database) | بالاترین سطح ساختار که مجموعه‌ای از کالکشن‌ها رو در خودش نگه میداره. |
| کالکشن (Collection) | جدول (Table) | گروهی از اسناد مرتبط. مثلا کالکشن «کاربران» یا کالکشن «محصولات». |
| سند (Document) | سطر (Row) | واحد اصلی ذخیره‌سازی داده که یک شی BSON با زوج‌های کلید-مقدار هست. |
| فیلد (Field) | ستون (Column) | یک ویژگی یا صفت خاص درون یک سند که داده‌ها رو نگه میداره. |
همونطور که می‌بینید، مفاهیم خیلی شبیه به هم هستن، اما فلسفه پشتشون کاملا متفاوته. توی مانگو دی‌بی، یک کالکشن میتونه اسنادی با ساختارهای کاملا متفاوت رو در خودش جا بده. این یعنی شما یک «شمای پویا» یا Schema-less دارید. لازم نیست از قبل تعریف کنید که هر سند چه فیلدهایی باید داشته باشه.
برای مثال، فرض کنید یک دیتابیس به اسم «GeeksforGeeks» داریم. داخل این دیتابیس دو تا کالکشن داریم و داخل هر کالکشن هم دو تا سند. داده‌های ما داخل این سندها و در قالب فیلدها ذخیره میشن.
ویژگی‌های کلیدی که مانگو دی‌بی رو خاص می‌کنن
حالا که با کلیات مانگو دی‌بی آشنا شدیم، بیایید ببینیم چه ویژگی‌هایی باعث شده این دیتابیس اینقدر محبوب بشه.
۱. انعطاف‌پذیری و مدل سند-گرا
این مهم‌ترین ویژگی مانگو دی‌بی هست که قبلا هم بهش اشاره کردیم. مدل سند-گرا مستقیما به اشیا (objects) در کد شما نگاشت میشه. این یعنی لازم نیست کلی کد بنویسید تا داده‌ها رو از فرمت جدولی به فرمت شی‌گرا تبدیل کنید. این انعطاف‌پذیری به شما اجازه میده داده‌های مرتبط رو توی یک سند واحد جاسازی کنید (embed کنید) که این کار باعث افزایش سرعت و کاهش هزینه‌های محاسباتی میشه.
۲. مقیاس‌پذیری افقی (Horizontal Scaling) با شاردینگ (Sharding)
یکی از بزرگترین چالش‌ها در دنیای داده‌های بزرگ (Big Data) اینه که وقتی حجم داده‌ها خیلی زیاد میشه، چطور سیستم رو مدیریت کنیم. دو راه کلی وجود داره: مقیاس‌پذیری عمودی (Vertical Scaling) و مقیای‌پذیری افقی (Horizontal Scaling).
- مقیاس‌پذیری عمودی: یعنی همون سرور فعلی رو قوی‌تر کنیم. مثلا رم و سی‌پی‌یو بیشتری بهش اضافه کنیم. این کار مثل اینه که ماشینتون رو با یه مدل قوی‌تر عوض کنید. اما این روش محدودیت داره و خیلی گرونه.
- مقیاس‌پذیری افقی: یعنی به جای قوی‌تر کردن یک سرور، تعداد سرورها رو زیاد کنیم و داده‌ها رو بین اونها تقسیم کنیم. این روش خیلی به‌صرفه‌تر و انعطاف‌پذیرتره.
مانگو دی‌بی از پایه برای مقیاس‌پذیری افقی طراحی شده. این کار رو با استفاده از تکنیکی به اسم شاردینگ (Sharding) انجام میده. در شاردینگ، داده‌های یک کالکشن بزرگ بر اساس یک کلید مشخص (shard key) به تکه‌های کوچکتری به اسم «چانک» (chunk) تقسیم میشن و هر تکه روی یک سرور مجزا (که بهش میگن shard) ذخیره میشه. این کار باعث میشه فشار کاری بین چندین ماشین پخش بشه و سیستم بتونه حجم عظیمی از داده و درخواست رو مدیریت کنه. این ویژگی، مانگو دی‌بی رو برای اپلیکیشن‌های بزرگ و با رشد سریع، ایده‌ال می‌کنه.
۳. دسترسی بالا (High Availability) با تکثیر (Replication)
هیچ‌کس دوست نداره سیستمش از کار بیفته. مانگو دی‌بی برای اطمینان از اینکه دیتابیس شما همیشه در دسترسه، از مکانیزمی به اسم تکثیر یا Replication استفاده می‌کنه. این کار از طریق چیزی به اسم مجموعه تکثیر (Replica Set) انجام میشه.
یک Replica Set شامل چند کپی از داده‌های شما روی سرورهای مختلفه. این مجموعه یک سرور اصلی (Primary) و چند سرور ثانویه (Secondary) داره. تمام عملیات نوشتن (write) به صورت پیش‌فرض روی سرور اصلی انجام میشه. سرورهای ثانویه به طور مداوم داده‌ها رو از سرور اصلی کپی می‌کنن و یک نسخه به‌روز از داده‌ها رو نگه می‌دارن.
حالا اگه سرور اصلی به هر دلیلی از کار بیفته (مثلا به خاطر مشکل سخت‌افزاری)، مجموعه تکثیر به طور خودکار یک «انتخابات» برگزار می‌کنه و یکی از سرورهای ثانویه رو به عنوان سرور اصلی جدید انتخاب می‌کنه. این فرآیند که بهش Failover میگن، باعث میشه سیستم شما با کمترین وقفه به کارش ادامه بده. جالبه بدونید که برای جلوگیری از دوپاره شدن مغز (split-brain) در انتخابات، اگه فقط یک سرور ثانویه داشته باشید، باید یک عضو سوم به اسم داور (Arbiter) هم به مجموعه اضافه بشه که فقط در انتخابات رای میده و داده‌ای ذخیره نمی‌کنه.
۴. کوئری‌های قدرتمند و ایندکس‌گذاری
مانگو دی‌بی فقط برای ذخیره داده نیست، بلکه ابزارهای خیلی قدرتمندی برای دسترسی و تحلیل داده‌ها هم فراهم می‌کنه. شما می‌تونید کوئری‌های موردی (Ad hoc queries) بزنید، یعنی بدون نیاز به تعریف قبلی، هر نوع جستجویی رو روی داده‌ها انجام بدید. این کوئری‌ها میتونن بر اساس فیلدهای خاص، محدوده‌های مشخص (range query) و حتی عبارت‌های باقاعده (regular-expression) باشن.
برای اینکه این کوئری‌ها سریع اجرا بشن، مانگو دی‌بی از ایندکس‌گذاری (Indexing) پشتیبانی می‌کنه. درست مثل فهرست آخر یک کتاب که به شما کمک می‌کنه سریع‌تر به یک مطلب برسید، ایندکس‌ها هم به دیتابیس کمک می‌کنن تا اسناد مورد نظر شما رو بدون جستجوی کامل در کل کالکشن پیدا کنه. شما می‌تونید روی هر فیلدی در سند، ایندکس اولیه (primary) یا ثانویه (secondary) بسازید.
۵. تجمیع داده‌ها (Aggregation)
گاهی وقتا شما فقط به داده‌های خام نیاز ندارید، بلکه می‌خواید یک سری پردازش روی اونها انجام بدید و به یک نتیجه خلاصه‌شده برسید. مثلا می‌خواید میانگین فروش محصولات در هر دسته‌بندی رو محاسبه کنید. مانگو دی‌بی برای این کار ابزارهای تجمیع قدرتمندی داره.
- پایپ‌لاین تجمیع (Aggregation Pipeline): این روش اصلی و پرکاربردترین روشه. مثل یک خط مونتاژ کار می‌کنه که داده‌ها از مراحل مختلفی عبور می‌کنن و در هر مرحله یک عملیات خاص روشون انجام میشه (مثلا گروه‌بندی، فیلتر کردن، محاسبه).
- تابع Map-Reduce: این یک روش قدیمی‌تر برای پردازش دسته‌ای داده‌هاست، اما پایپ‌لاین تجمیع معمولا کارایی بهتری داره.
- متدهای تجمیع تک‌منظوره: برای کارهای ساده‌تر مثل شمارش یا پیدا کردن مقادیر متمایز.
۶. ذخیره‌سازی فایل با GridFS
مانگو دی‌بی یک محدودیت داره: هر سند نمی‌تونه بزرگتر از ۱۶ مگابایت باشه. پس اگه بخوایم فایل‌های بزرگ مثل ویدیو یا عکس‌های باکیفیت رو ذخیره کنیم چی؟ برای این کار، مانگو دی‌بی یک راه‌حل داخلی به اسم GridFS داره. GridFS فایل‌های بزرگ رو به تکه‌های کوچکتر (chunks) تقسیم می‌کنه و هر تکه رو به عنوان یک سند مجزا در کالکشن‌های مخصوص ذخیره می‌کنه. اینطوری شما می‌تونید از تمام ویژگی‌های مانگو دی‌بی مثل تکثیر و شاردینگ برای فایل‌های بزرگ هم استفاده کنید.
ابزارهای اصلی برای کار با مانگو دی‌بی
وقتی با مانگو دی‌بی کار می‌کنید، چند تا دستور و ابزار اصلی وجود داره که باید باهاشون آشنا باشید. این دستورها گاهی برای تازه‌کارها گیج‌کننده هستن، پس بیایید یک بار برای همیشه تفاوتشون رو یاد بگیریم. این بخش رو از تجربه یکی از کارمندهای خود شرکت مانگو دی‌بی به اسم Helen Scott براتون میگم که خودش هم اوایل با این دستورها سردرگم بوده.
mongod: این کلمه مخفف MongoDB Daemon هست و در واقع سرور اصلی دیتابیس شماست. مثل موتور ماشین می‌مونه. تا وقتی این سرور رو اجرا نکنید، هیچ دیتابیسی وجود نداره که بهش وصل بشید. این سرور به صورت پیش‌فرض روی پورت 27017 منتظر اتصال کلاینت‌ها می‌مونه.mongoوmongosh: اینها شل (Shell) یا کلاینت شما هستن. یعنی ابزاری که باهاش به سرور (mongod) وصل میشید و دستوراتتون رو اجرا می‌کنید؛ مثل کوئری زدن، اضافه کردن داده یا کارهای مدیریتی.mongoنسخه قدیمی‌تر این شل بود که از نسخه ۵.۰ به بعد مانگو دی‌بی، منسوخ شده. نسخه جدید و بهبودیافته اونmongoshنام داره که ویژگی‌هایی مثل هایلایت کردن دستورات، تاریخچه دستورات و لاگین بهتر رو ارائه میده. پس اگه می‌خواید با دیتابیس تعامل داشته باشید، باید ازmongoshاستفاده کنید.mongos: این یکی کمی پیشرفته‌تره و وقتی کاربرد داره که شما از شاردینگ استفاده می‌کنید.mongosمخفف MongoDB Shard هست و مثل یک پراکسی یا روتر عمل می‌کنه. وقتی شما داده‌هاتون رو روی چندین سرور (shard) پخش کردید، کلاینت شما (مثلاmongosh) نمی‌دونه که داده مورد نظرش روی کدوم سرور قرار داره.mongosاینجا وارد عمل میشه. کلاینت شما بهmongosوصل میشه وmongosوظیفه داره کوئری‌ها و درخواست‌های نوشتن رو به شارد یا شاردهای درست هدایت کنه.
پس به طور خلاصه: شما mongod رو اجرا می‌کنید تا سرور دیتابیس راه بیفته. بعد با mongosh بهش وصل میشید تا با داده‌هاتون کار کنید. و اگه دیتابیس شما خیلی بزرگ و شارد شده باشه، mongos هم به عنوان یک واسط بین شما و شاردها عمل می‌کنه.
مانگو دی‌بی اطلس (MongoDB Atlas): دیتابیس در ابرها
راه انداختن و مدیریت یک دیتابیس، مخصوصا اگه بزرگ و توزیع‌شده باشه، کار ساده‌ای نیست. باید نگران نصب، پیکربندی، پشتیبان‌گیری، امنیت و خیلی چیزهای دیگه باشید. شرکت مانگو دی‌بی برای حل این مشکل، یک سرویس ابری به اسم MongoDB Atlas رو ارائه کرده.
اطلس یک سرویس «دیتابیس به عنوان سرویس» (DBaaS) کاملا مدیریت شده است. یعنی شما دیگه لازم نیست خودتون سرور راه بندازید یا نگران نگهداری اون باشید. فقط با چند کلیک یک کلاستر (مجموعه‌ای از سرورها) مانگو دی‌بی روی پلتفرم‌های ابری معروفی مثل Amazon Web Services (AWS)، Google Cloud Platform و Microsoft Azure ایجاد می‌کنید و شرکت مانگو دی‌بی تمام کارهای مدیریتی رو براتون انجام میده. این سرویس امکاناتی مثل پشتیبان‌گیری خودکار، مانیتورینگ، امنیت پیشرفته و مقیاس‌پذیری راحت رو فراهم می‌کنه و به شما اجازه میده روی توسعه اپلیکیشن خودتون تمرکز کنید. جالبه بدونید که تا سال ۲۰۲۴، ۷۰ درصد درآمد شرکت مانگو دی‌بی از همین سرویس اطلس بوده.
موارد استفاده مانگو دی‌بی: کجا به کار میاد؟
با توجه به ویژگی‌هایی که گفتیم، مانگو دی‌بی برای طیف وسیعی از اپلیکیشن‌های مدرن مناسبه. بیایید چند تا از کاربردهای رایجش رو با هم مرور کنیم:
- سیستم‌های مدیریت محتوا (CMS): به خاطر انعطاف‌پذیری بالا، مانگو دی‌بی برای ذخیره انواع محتوا مثل مقالات، وبلاگ‌ها و سایت‌های خبری که ساختارهای متنوعی دارن، عالیه.
- اپلیکیشن‌های موبایل: مانگو دی‌بی به راحتی میتونه داده‌های سمت بک‌اند اپلیکیشن‌های iOS و اندروید رو ذخیره کنه و به توسعه‌دهنده‌ها اجازه میده اپلیکیشن‌هاشون رو به صورت یکپارچه مقیاس‌پذیر کنن.
- تجارت الکترونیک (E-commerce): فروشگاه‌های آنلاین میتونن از مانگو دی‌بی برای مدیریت کاتالوگ محصولات، پروفایل کاربران، سبدهای خرید و تاریخچه تراکنش‌ها استفاده کنن.
- اینترنت اشیا (IoT): دستگاه‌های IoT حجم عظیمی از داده‌های سنسورها رو تولید می‌کنن. مقیاس‌پذیری و انعطاف‌پذیری مانگو دی‌بی اون رو برای ذخیره و پردازش این داده‌ها ایده‌ال می‌کنه.
- بازی‌های آنلاین: ذخیره پروفایل بازیکنان، امتیازات، دستاوردها و وضعیت بازی که ساختارهای پیچیده‌ای دارن، با مدل سند-گرای مانگو دی‌بی خیلی راحت‌تره.
- تحلیل داده‌های آنی (Real-Time Analytics): توانایی مانگو دی‌بی در پردازش سریع داده‌ها، اون رو برای سیستم‌های مانیتورینگ، تشخیص تقلب و ارائه پیشنهادهای شخصی‌سازی شده مناسب می‌کنه.
- شبکه‌های اجتماعی: مدیریت روابط پیچیده بین کاربران، محتوای تولید شده توسط کاربر و تعاملات زنده، با مانگو دی‌بی به خوبی امکان‌پذیره.
- کاربردهای داده‌های بزرگ (Big Data): مانگو دی‌بی به خوبی با ابزارهای اکوسیستم داده‌های بزرگ مثل Apache Hadoop و Spark ادغام میشه و برای کارهایی مثل مدل‌سازی ریسک و تحلیل‌های پیش‌بینی‌کننده استفاده میشه.
مقایسه مانگو دی‌بی با رقبای سنتی: MySQL
برای اینکه جایگاه مانگو دی‌بی رو بهتر درک کنیم، خوبه که اون رو با MySQL به عنوان نماینده دیتابیس‌های رابطه‌ای مقایسه کنیم.
| ویژگی | مانگو دی‌بی (MongoDB) | مای‌اس‌کیو‌ال (MySQL) |
|---|---|---|
| مدل داده | سند-گرا (Document-Oriented)، بدون شما (Schema-less) | رابطه‌ای (Relational)، با شمای از پیش تعریف شده |
| زبان کوئری | MQL (زبانی شبیه JSON) | SQL (زبان کوئری ساختاریافته) |
| مقیاس‌پذیری | افقی (Horizontal) با شاردینگ داخلی | عمدتا عمودی (Vertical)، مقیاس‌پذیری افقی پیچیده‌تره |
| موارد استفاده | داده‌های بزرگ، اپلیکیشن‌های مدرن، داده‌های نیمه‌ساختاریافته | سیستم‌های تراکنشی، داده‌های با ساختار مشخص، جاهایی که یکپارچگی داده حیاتیه |
| انعطاف‌پذیری | بسیار بالا، تغییر ساختار داده آسان است | کم، تغییر شما نیازمند فرآیندهای پیچیده است |
چه زمانی MySQL بهتره؟ وقتی یکپارچگی داده‌ها و ایزوله‌سازی (isolation) حرف اول رو میزنه، مثل سیستم‌های مدیریت تراکنش‌های مالی، MySQL به خاطر ساختار سفت و سختش انتخاب بهتریه.
چه زمانی مانگو دی‌بی بهتره؟ وقتی سرعت، دسترسی بالا و توانایی کار با داده‌های متنوع و در حال تغییر اولویت داره، انعطاف‌پذیری و عملکرد بالای مانگو دی‌بی اون رو به گزینه بهتری تبدیل می‌کنه.
تاریخچه و لایسنس: یک مسیر پر فراز و نشیب
مانگو دی‌بی توسط شرکتی به اسم 10gen در سال ۲۰۰۷ شروع به توسعه پیدا کرد. این شرکت که بعدها در سال ۲۰۱۳ اسم خودش رو به MongoDB Inc. تغییر داد، در ابتدا قصد داشت یک محصول پلتفرم به عنوان سرویس (PaaS) بسازه که مانگو دی‌بی یکی از اجزای اون بود. اما در سال ۲۰۰۹، اونها مدل توسعه رو به سمت متن‌باز تغییر دادن. مانگو دی‌بی در تاریخ ۲۰ اکتبر ۲۰۱۷ با نماد MDB در بورس NASDAQ عرضه عمومی شد.
یکی از بحث‌برانگیزترین اتفاقات در تاریخ مانگو دی‌بی، تغییر لایسنس اون بود. نسخه‌هایی که قبل از ۱۶ اکتبر ۲۰۱۸ منتشر شدن، تحت لایسنس AGPL بودن که یک لایسنس متن‌باز شناخته شده است. اما بعد از این تاریخ، شرکت مانگو دی‌بی لایسنس نرم‌افزار سرور خودش رو به Server Side Public License (SSPL) تغییر داد.
این لایسنس جدید که توسط خود مانگو دی‌بی نوشته شده، شبیه به لایسنس‌های متن‌باز هست اما یک شرط مهم داره: اگه شما نرم‌افزار مانگو دی‌بی رو به عنوان یک «سرویس» عمومی ارائه بدید، باید کل سورس کد سرویس خودتون رو هم تحت همین لایسنس SSPL منتشر کنید. این تغییر برای جلوگیری از این بود که شرکت‌های بزرگ ارائه‌دهنده خدمات ابری، از مانگو دی‌بی به صورت تجاری استفاده کنن بدون اینکه به جامعه اون کمک کنن.
این تغییر باعث شد که بنیاد نرم‌افزار متن‌باز (OSI) اعلام کنه که SSPL یک لایسنس متن‌باز نیست. در نتیجه، توزیع‌های لینوکسی معروفی مثل Debian، Fedora و Red Hat Enterprise Linux، مانگو دی‌بی رو از مخازن رسمی خودشون حذف کردن.
انتقادات و چالش‌ها: نگاهی بی‌طرفانه
هیچ تکنولوژی‌ای بدون نقطه ضعف نیست و مانگو دی‌بی هم از این قاعده مستثنی نیست. مهمه که با نگاهی بی‌طرفانه، برخی از انتقادات و چالش‌های مطرح شده در مورد اون رو هم بررسی کنیم.
- امنیت: در نسخه‌های قدیمی‌تر، تنظیمات پیش‌فرض امنیتی مانگو دی‌بی ضعیف بود و به هر کسی اجازه دسترسی کامل به دیتابیس رو می‌داد. این موضوع باعث شد که هکرها به ده‌ها هزار دیتابیس حمله کنن، اطلاعات رو سرقت کنن یا برای پس دادن اونها باج بخوان. البته از نسخه ۲.۶ به بعد، این مشکل حل شد و به صورت پیش‌فرض، دیتابیس فقط به اتصالات از خود ماشین (localhost) اجازه دسترسی میده.
- عدم وجود JOINهای پیچیده: در دیتابیس‌های رابطه‌ای، شما می‌تونید با دستور JOIN داده‌ها رو از جدول‌های مختلف به هم وصل کنید. مانگو دی‌بی به صورت ذاتی از JOIN به اون شکل پشتیبانی نمی‌کنه. به جای اون، شما باید از طریق جاسازی اسناد (embedding) یا ارجاع (referencing) روابط رو مدیریت کنید. این موضوع گاهی برای کسانی که از دنیای SQL میان، چالش‌برانگیزه و باعث میشه در اپلیکیشن‌های خیلی پیچیده که روابط زیادی دارن، برخی به سمت SQL برگردن.
- مصرف بالای حافظه: مانگو دی‌بی برای افزایش کارایی، از حافظه رم به مقدار زیادی استفاده می‌کنه که میتونه هزینه‌های سخت‌افزاری رو بالا ببره.
- انتقادات فنی و یکپارچگی داده: در گذشته، گزارش‌هایی مثل گزارش معروف Jepsen (یک شرکت تحقیقاتی در زمینه ایمنی سیستم‌های توزیع‌شده) مشکلاتی رو در مورد یکپارچگی داده‌ها در سناریوهای خاصی از خرابی شبکه در مانگو دی‌بی پیدا کرده بود. این گزارش‌ها نشون می‌داد که در شرایط خاص، ممکنه دیتابیس داده‌های قدیمی (stale reads) برگردونه یا حتی داده‌هایی که تایید شدن رو به عقب برگردونه (rollback). شرکت مانگو دی‌بی در نسخه‌های بعدی (مثل نسخه ۳.۴ و بالاتر) بسیاری از این مشکلات رو برطرف کرد و ادعا کرد که تست‌های Jepsen رو با موفقیت پشت سر گذاشته. اما گزارش‌های جدیدتر Jepsen در مورد نسخه‌های جدیدتر مثل ۴.۲.۶، همچنان به برخی مشکلات و پیچیدگی‌ها در تضمین کامل یکپارچگی داده‌ها در تراکنش‌ها اشاره داشت. البته این مشکلات هم در پچ‌های بعدی مورد توجه قرار گرفتن و در نسخه ۵.۰، پیش‌فرض‌های مربوط به تایید نوشتن داده (write concern) برای افزایش ایمنی، تقویت شدن.
این انتقادات به این معنی نیستن که مانگو دی‌بی ابزار بدیه، بلکه نشون میدن که مثل هر ابزار قدرتمند دیگه‌ای، باید با آگاهی کامل از نقاط قوت و ضعفش از اون استفاده کرد.
پرسش و پاسخ‌های متداول (FAQ)
حالا که یک دید کلی و جامع از مانگو دی‌بی پیدا کردیم، بیایید به چند تا سوال رایج که ممکنه تو ذهن شما شکل گرفته باشه جواب بدیم.
سوال ۱: پس مانگو دی‌بی فقط برای داده‌های «بدون ساختار» خوبه؟
نه لزوما. اصطلاح بهتر «داده‌های نیمه‌ساختاریافته» یا داده‌هایی هست که ساختار ثابتی ندارن. مانگو دی‌بی برای هر اپلیکیشنی که داده‌هاش به راحتی در قالب جدول‌های سفت و سخت جا نمیگیرن یا ساختارشون در طول زمان زیاد تغییر می‌کنه، عالیه. حتی برای داده‌های ساختاریافته هم میشه ازش استفاده کرد، اما انعطاف‌پذیریش در کار با داده‌های متنوع نقطه قوت اصلیشه.
سوال ۲: فرق بین
mongoوmongoshدقیقا چی بود؟هر دو ابزارهایی برای اتصال به سرور مانگو دی‌بی و اجرای دستورات هستن.
mongoنسخه قدیمی‌تره که دیگه توسعه داده نمیشه.mongoshنسخه جدید، مدرن و پیشنهادی هست که امکانات بهتری مثل رنگی بودن دستورات و تاریخچه بهتر رو ارائه میده. همیشه سعی کنید ازmongoshاستفاده کنید.سوال ۳: این «کرسر» (Cursor) که گاهی در موردش صحبت میشه چیه؟
وقتی شما یک کوئری
findدر مانگو دی‌بی اجرا می‌کنید، دیتابیس تمام نتایج رو یک‌جا برای شما ارسال نمی‌کنه، چون ممکنه نتایج خیلی زیاد باشن و حافظه زیادی مصرف کنن. به جای اون، یک کرسر (Cursor) برمی‌گردونه. کرسر مثل یک «اشاره‌گر» به مجموعه‌ی نتایج روی سرور عمل می‌کنه. شما با استفاده از این کرسر می‌تونید نتایج رو یکی یکی یا به صورت دسته‌ای (batch) از سرور بگیرید. متدهایی مثلhasNext()(که چک می‌کنه آیا نتیجه دیگه‌ای وجود داره) وnext()(که نتیجه بعدی رو برمی‌گردونه) روی همین کرسر کار می‌کنن.سوال ۴: اگه اینقدر انعطاف‌پذیر و خوبه، چه زمانی نباید از مانگو دی‌بی استفاده کنم؟
مانگو دی‌بی برای همه کارها بهترین راه‌حل نیست. اگه اپلیکیشن شما داده‌های بسیار رابطه‌ای داره و نیاز به JOINهای پیچیده بین چندین جدول دارید (مثلا یک سیستم بانکی پیچیده)، و یکپارچگی و ثبات داده‌ها (ACID properties) در سطح تراکنش‌های چند جدولی برای شما حیاتی‌تر از هر چیز دیگه‌ای هست، احتمالا یک دیتابیس رابطه‌ای مثل MySQL یا PostgreSQL انتخاب بهتری باشه.
سوال ۵: جریان این لایسنس SSPL چیه؟ یعنی مانگو دی‌بی دیگه متن‌باز نیست؟
از نظر فنی، سورس کد مانگو دی‌بی همچنان در دسترسه (source-available)، اما لایسنس SSPL توسط بنیاد متن‌باز به عنوان یک لایسنس «متن‌باز» واقعی تایید نشده. دلیلش هم محدودیتی هست که برای ارائه‌دهندگان خدمات ابری ایجاد می‌کنه. برای یک توسعه‌دهنده معمولی که از مانگو دی‌بی در اپلیکیشن خودش استفاده می‌کنه، این موضوع معمولا تفاوت خاصی ایجاد نمی‌کنه. اما اگه قصد دارید خود مانگو دی‌بی رو به عنوان یک سرویس تجاری به دیگران بفروشید، باید شرایط این لایسنس رو به دقت بررسی کنید. نسخه Community مانگو دی‌بی همچنان برای استفاده رایگانه.
دیدگاهتان را بنویسید