همانطور که در عکس زیر مشاهده میکنید محبوبیت MONGODB در سال های اخیر به شکل چشم گیری افزایش یافته است. یکی از مهم ترین سرویس هایی که به شکل کامل به آن وابسته شده سرویس های CLOUD است از جمله AMAZON, GOOGLE CLOUD PLATFORM, AZUREکه از آن برای سرویس دهی استفاده میکنند . دلیل این مورد، انعطاف پذیری فوق العاده ای است که MONGODB به دلیل DISTRIBUTED بودن به آن میدهد. در ادامه به توضیح این ویژگی میپردازیم
قبل از شروع مطلب لازم است چند مفهوم زیر را توضیح دهیم:
Atomic transaction
این مفهموم بسیار مهمی برای حفظ CONSISTENCY دیتا میباشد و بدین معناست که در صورتی تعدادی کوئری داشته باشیم یا همه انها به طور کامل اجرا میشوند یا هیچ کدام اجرا نمیشوند(FAIL) بدین ترتیب یکپارچگی دیتا تضمین میشود . یک حساب بانکی را فرض کنید که میخواهد تراکنش انتقال پول را انجام دهد یک سری تراکنش ها باید به ترتیب زیر اجرا شوند :
1. وارد کردن مبلغ
2. چک کردن موجودی حساب
3. انتقال به حساب
4. کسر از حساب
فرض کنید پس از انجام مرحله 3 بقیه کوئری ها اجرا نشوند و انتقال به حساب دیگر انجام شود و کسر مبلغ از کارت اجرا نشود بدین ترتیب اشتباه در دیتا و عدم یکپارچگی اتفاق می افتد. به همین دلیل یک تراکنش ATOMIC برای سیستم هایی که یکپارچگی دیتا برای آنها مهم است بسیار حائز اهمیت میباشد.
Sharding database
زمانی که درخواست های زیادی برروی دیتابیس باشد ، میزان LOAD برروی دیتابیس نیز بالا می رود. در این زمان نیازمند افزایش منابع سرور هستیم، اما در واقعیت اضافه کردن تعداد سرور با کانفیگ معمولی بسیار کم هزینه تر از ارتقا سیستم به منابع بسیار قوی تر میباشد بدین ترتیب تقسیم کردن REQUEST ها بین سرور های مختلف بسیار صرفه تر میباشد. با استفاده از مفهوم SHARDING این عمل در سطح APPLICATION و DATABASE قابل انجام است .
SCHEMA
قبل از ذخیره دیتا در دیتابیس های RELATIONAL باید حتما جداول و ستون ها تعریف شوند حتی نوع مقادیر ذخیره شده نیز باید از قبل مشخص شود به این طراحی که باید از قبل اماده شود SCHEMA گفته میشود.
MOGODB VS MYSQL
Mongodb قابلیت هندل کردن دیتا unstructured را با اختلاف فوق العاده سریع تری دارد. دیتا در MONGODBبه جای جداول در DOCUMENT ذخیره میشود. داکیومنت همان ردیف های جدول هستند با این تفاوت که هیچ محدودیتی در ذخیره دیتا ندارند . در این داکیومنت ها هر نوع دیتا ذخیره میشود و هر ATTRIBUTE میتواند چندین مقدار داشته باشد. هر داکیومنت یک ID منحصر دارد که هنگام ساخت به طور خودکار با ان میشود.
این داکیومنت ها در یک COLLECTION قرار میگیرند که این COLLECTION ها همان جداول دیتابیس معمولی هستند
داکیومنت ها به شکل JSON نوشته میشوند
این داکیومنت ها چه مزایایی دارند؟
1. به زبان انسان نزدیک تر هستند و نوشتن انها خیلی راحتر هست.
2. محدودیت های ورود دیتا به جدول را ندارند .در هر ستون تنها برای هر متغییر یک مقدار میتوان تعریف کرد در حالی که در داکیومنت هرتعداد مقدار با TYPE های مختلف قابل ذخیره سازی است.
3. سرعت را بالا برده و پیچیدگی را کم میکنند. فرض کنید برای جدول مشخصات کاربران بیمارستان جدولی داریم که یکی از فیلد ها ادرس و یکی شماره تلفن میباشد در صورتی که کاربری دو شماره و یا دو ادرس داشته باشد نمیتوان ان را وارد کرد و برای این منظور جدولی جدا وابسته به ان فقط برای ادرس درست میکنیم بدین ترتیب پیچیدگی ارتباط این جداول از یک طرف و خواندن دیتا از هر جای مختلفی از دیسک از سمت دیگر از جمله مشکلاتی است که داکیومنت ها حل کرده اند.
CLUSTERING
Clustering در این دیتابیس با استفاده از replication set ها به فرم master slave انجام میشود و نود های فرعی میتوانند هر سروری در هر دیتاسنتری باشند. این مورد امکان fault tolerance را فراهم میکند بدین ترتیب اگر در یک دیتاسنتر مشکلی به وجود اید دیتاسنتر های دیگر در دسترس قرار دارند. و دیتا از تظر فیزیکی پخش شده و سرعت پاسخ را بالا میبرد.
Mysql نیز امکان clustering دارد اما در عمل هنگام fail شدن کاربردی ندارد. Mongo به صورت built-in میتواند در صورت خارج شدن یک نود در کمتر از 5 ثانبه نود جدید را انتخاب کرده و در شبکه قرار دهد اما این روند در mysql به صورت دستی انجام میگیرد.
INDEXING
هردو از متدهای indexing برای بالابردن سرعت کوئری ها استفاده میکنند. در صورتی که از indexing در دیتابیس اطلاعاتی ندارید ویدئو زیر را مشاهده نمایید
SCHEMA-LESS
mongodb برخلافmysql به صورت schemaless دیتا را ذخیره میکند که علاوه بر راحتی بسیاز زیاد در کار با ان ریسک inconsistency دیتا را نیز به همراه دارد
یکی از مهم ترین محدودیت های mongodb عدم ساپورت join و atomic transaction هاست. لازم به ذکر است در نسخه های جدید ان MongoDB 3.6به بعد از atomic transaction پشتیبانی میشود اما پیچیدگی در پیاده سازی را بسیار بالا میبرد.
HORIZENTAL SHARDING
Horizontal sharding از جمله قوی ترین قابلیت های mongodb در مقایسه با mysql است و هر دو دیتابیس این امکان را دارند. اما به دلیل مشکلاتی مثل عدم بالانس پس از sharding این مورد در عمل با mysql پیاده سازی نمیشود اما mongo دقیقا در بخش هایی که mysql ضعیف عمل میکند مثل application-unaware scaling, auto-sharding بسیار قوی میباشد.
Mpngodb یاmysql
حالا که نقاط ضعف و قوت هر کدام را بررسی کردیم میتوانیم پاسخ به این سوال را بدهیم، کدام دیتابیس مناسب برنامه من است؟ هر دیتابیس در ویژگی هایی ارائه میدهد که میتواند راهکار مشکل در محیط های گوناگون است و در نهایت ادمین این قدرت انتخاب را دارد تا با توجه به نیاز های برنامه خود این انتخاب را انجام دهد
دسته بندی کلی زیر این موارد را به طور کلی جمع بندی میکند
موارد زیر مناسب استفاده از mongodbهستند:
• زمانی که high-avalability برای برنامه شما اهمیت دارد و نباید قطعی در برنامه باشید.
• برنامه شما پتانسیل گسترش بالایی دارد و به scalability بالا نیاز دارید.
• از cloudاستفاده میکنید.
و در این موارد استفاده از mysql راهکار بهینه میباشد:
• زمانی که یکپارچگی و صحت دیتا اهمیت بالایی دارد مثل بانک و برنامه های حسابداری.
• Mysql یکی از امن ترین دیتابیس ها محسوب میشود و با تمام متد هایی که برای حفظ دیتا ارائه میدهد زمانی که امنیت اهمیت دارد بهترین گزینه است.
• زمانی که در ابتدا کار هستید و برنامه شما scale بالایی نیاز ندارد.