اگه هنوز براتون سواله که MongoDb یا مثلا SqlServer ...

با یه سرچ توی مقالات فارسی میتونین ببینین که متاسفانه هیچ مقاله درست و درمونی پیدا نمیشه که جواب این سوال رو داده باشه، اکثرا مقالاتی مبهم و کلی گویی مواجه میشین که در آخر هم جواب سوال رو نتونسته بده. مابقی هم که الی ماشاالله کپی از همدیگه!

توی این پست میخوام به صورت علمی به قضیه نگاه کنیم و ببینیم که چرا و کجا ها Mongo انتخاب بهتری هست و کجا ها نیست. قبلش اما باید CAP Theorem (تئوری CAP) رو بدونین.

اگه نمیدونین تئوری CAP چیه اول اینجا رو مطالعه کنین

وقتی از نگاه تئوری CAP دیتابیس mongo رو بررسی کنیم

مونگو تو شرایط مختلف trade-off متفاوتی از C و A و P رو فراهم میکنه

?از نگاه Consistency

مثلا وقتی به صورت Distribute ازش استفاده نشه Strong Consistent هست پس Consistency رو داره

ولی وقتی به صورت Distribute ازش استفاده بشه (مثلا دیتا از replica ها خونده بشه) Eventual Consistent هست پس Consistency رو فدا میکنه

?از نگاه Availability

وقتی از مونگو به صورت توزیع شده (Replica-Sets) استفاده بشه، high availability خوبی رو فراهم و در صورت دان شدن Primary Node سریعا یک node دیگه جایگزین میشه ولی در این حالت Consistency فدای Availability میشه

?از نگاه Partition Tolerance

توسط قابلیت Replica-Sets عملا Partition Tolerance فراهم است منتها تا زمانی که "بیش از نیمی" از Node ها به یک دیگر متصل باشند. در این حالت سیستم Primary Node جدید رو انتخاب میکنه

ولی اگر Node های ثانویه به اندازه کافی نباشند همچنان امکان read وجود داره ولی دیگه امکان write وجود نداره. پس دراین حالت Availability برای Consistency فدا میشه

?نتیجه گیری :

• اگر توزیع نشده استفاده بشه : CA
• اگر توزیع شده باشه ولی اکثریت node ها در دسترس باشند : AP
• اگر توزیع شده باشه ولی کمتر از نصف node ها در دسترس باشند : CP

✅ در نهایت ویژگی های خوبی که باعث میشه Mongo انتخاب بهتری نسبت به دیتابیس SQL/Relational باشه ایناس :

1️⃣ شما نیاز به مقیاس پذیری بالا به صورت Horizontal Scaling دارید (توسط قابلیت Replica-Set و Sharding مونگو)

در این حالت معمولا Consistency فدا میشه پس باید دقت داشت که این روش برای دیتا های حساس که به یکپارچگی و ثبات بالا نیاز دارند مناسب نیست، مثل برنامه های حسابداری و بانکی

2️⃣ دیتای شما ساختار (Schema) مشخصی نداره و به انعطاف پذیری بالا نیاز دارید (به خاطر Schema-less بودن مونگو)

در این حالت باید توجه داشت که متفاوت بودن ساختار رکورد (داکیومنت) ها میتونه احتمال خطا توی سیستم رو افزایش بده پس باید در سطح کد نویسی حواسمون بهش باشه

3️⃣ دیتابیس Mongo برای ذخیره سازی و بازیابی دیتا های حجیم و "مرتبط" بسیار مناسبه و پرفرمنس بالایی داره، چون تمام دیتای مرتبط به یک سند داخل خودش ذخیره میشه و نیاز به Join خیلی کمتر احساس میشه

4️⃣ دیتابیس Mongo به خاطر ساختار و سادگی ایی که داره Performance Tuning و Optimization های حرفه ای که نیاز به DBA داشته باشه خیلی کمتر توش احساس میشه پس اگه میخواین خیلی درگیر کار های DBA ایی نشین Mongo گزینه مناسبیه

? کانال دات نت زوم

https://t.me/DotNetZoom