نکات طراحی دیتابیس در MongoDB

دیتابیس مونگو یک پایگاه داده محبوب است که اجازه می‌دهد بدون اجبار از پیروی schema خاصی، داده‌ها ذخیره شوند.

داده‌ها در قالب JSON ذخیره می‌شوند و می‌توانند شامل ساختارهای مختلفی باشند. به‌عنوان مثال در یک collection می‌توانیم دو document زیر را داشته باشیم:

برای به‌دست آوردن بهترین نتیجه از MongoDB، باید اصول طراحی دیتابیس را بدانیم. قبل از مراجعه به برخی نکات طراحی دیتابیس، باید بدانیم که MongoDB چگونه داده‌ها را ذخیره می‌کند.

چگونه داده ها در MongoDB ذخیره می شوند؟

اگر از دیتابیس‌های RDBMS نظیر SQL Server، PostgreSQL، MySQL به سمت MongoDB آمده‌اید احتمالاً مفاهیم مثل table و row و column را در ذهن دارید. این مفاهیم در MongoDB وجود ندارند و داده‌ها در collections و documents‌ها ذخیره می‌شوند.

تصویر زیر ساختار MongoDB را با RDBMS‌ها مقایسه می‌کند.

نکات و ترفندهای طراحی دیتابیس

تفاوت Normalization با Denormalization:

با توجه به این که MongoDB با document کار می‌کند، درک مفاهیم Normalization و Denormalization بسیار مهم است. این دو روش نحوه ذخیره داده‌های MongoDB را تعریف می‌کنند.

تعریف Normalization – به معنای ذخیره داده‌ها در چندین collection با رفرنس‌دهی بین آن‌ها است. داده‌ها یک بار تعریف می‌شوند و آپدیت را ساده‌تر می‌کنند. وقتی صحبت از خواندن داده‌ها می‌شود، نقطه ضعف normalization به چشم می‌آید. اگر می‌خواهید داده‌ها را از چندین collection دریافت کنید، باید چندین کوئری (Query) بزنید. در نتیجه عملیات خواندن کندتر انجام می‌گیرد.

تعریف Denormalization – تعداد زیادی داده را در یک document به صورت تو در تو ذخیره می‌کند. این مدل عملیات خواندن عملکرد بهتری خواهد داشت اما در اینزرت (Insert) و آپدیت‌ها کندتر خواهد بود. این روش ذخیره داده‌ها فضای بیشتری را برای ذخیره‌سازی اشغال می‌کند.

برای انتخاب یکی از روش‌ها بالا باید به موارد زیر توجه کرد.

• اگر دیتابیسی دارید که نیازی به به‌روزرسانی منظم ندارد، دارای document‌های کوچک است که اندازه آن به آهستگی رشد می‌کند، اجرای سریع بروزرسانی آنچنان مهم نیست، اما برای خواندن به عملکرد خوبی نیاز دارید، پس denormalization ممکن است انتخاب خوبی باشد.
• اگر دیتابیس شما دارای document‌های بزرگی است که دارای به روزرسانی مداوم است و می‌خواهید عملکرد خوبی در نوشتن داشته باشید، پس normalization ممکن است انتخاب خوبی باشد.

روابط یک به چند (One-to-N)

مدل‌سازی روابط “یک به چند” در MongoDB نسبت به RDBMS ظریف‌تر است. کسانی که تازه به سراغ MongoDB آمده‌اند، به سراغ ذخیره آرایه‌ای از داده‌ها در جدول Parent می‌روند و این همیشه بهترین راه حل نیست. همانطور که در اولین نکته مشاهده کردیم، دانستن زمان استفاده از normalization یا denormalization بسیار مهم است. بنابراین قبل از هر چیزی باید بدانیم منظور از چند در عبارت “یک به چند” دقیقاً چه می‌باشد؟ تعداد کم، زیاد یا خیلی زیاد؟ هر رابطه یک روش مدل‌سازی متفاوت خواهد داشت.

برای مثال برای ذخیره‌سازی رابطه “یک به تعداد کمی” بهترین روش ذخیره به صورت تو در تو است. به فیلد addresses در document زیر توجه کنید.

در رابطه “یک به چند” دو collection را در نظر می‌گیریم. collection  محصولات و collection قطعات. هر محصول با استفاده از “ObjectID” به قطعات خود اشاره می‌کند.

دیگر نکات در طراحی دیتابیس

ایندکس گذاری

برای حفظ عملکرد خوب دیتابیس خود، باید یک ایندکس گذاری خوب پیاده سازی کنید که عملکرد نوشتن و خواندن شما را سریع‌تر می‌کند. دانستن مزایا و محدودیت‌های ایندکس گذاری برای MongoDB در انجام این کار بسیار مهم است. به خاطر داشته باشید که MongoDB در نگهداری document‌ها برای یک مرتب سازی، محدودیت ۳۲MB دارد. اگر از ایندکس استفاده نکنید، دیتابیس مجبور می‌شود ضمن مرتب سازی، مقدار زیادی از document‌ها را نگه دارد. اگر MongoDB به این محدودیت برخورد کند، سپس دیتابیس خطا یا یک مجموعه خالی را بر می‌گرداند.

اتمی بودن (Atomicity)

اتمی در دیتابیس به این معنی است که کل عملیات‌ها باید به عنوان یک عملیات واحد به‌طورکلی از بین برود یا موفق شود. اگر تراکنش والدین دارای بسیاری از عملیات‌های فرعی باشد، حتی اگر یک عملیات نیز انجام نشود کل عملیات‌ها شکست می‌خورند. عملیات‌ها در MongoDB در سطح document انجام می‌شوند. هیچ عملیات نوشتنی نمی‌تواند بیش از یک document را تحت تأثیر قرار دهد. این‌ها به عنوان عملیات جداگانه‌ای رفتار می‌کنند. یک عملیات نوشتن تنها می‌تواند داده‌ها را برای یک موجودیت اینزرت یا آپدیت کند. از این رو، این عملیات نوشتن اتمی را تسهیل می‌کند.

با این حال، ساختارهایی که ارائه‌دهنده اتمی بودن در عملیات اینزرت هستند ممکن است برنامه را برای استفاده از داده‌ها محدود کنند. همچنین ممکن است روش‌های تغییر برنامه محدود شود. برای طراحی دیتابیسی انعطاف پذیر باید به نکته اتمی بودن نیز دقت شود.

ایجاد collection با document های بزرگ

مونگو اجازه می‌دهد که document‌های بزرگ تا ۱۶ مگابایت در collection قرار گیرند. اما پشتیبانی از document‌های بزرگ به این معنی نیست که ذخیره این حجم از داده داخل یک document ایده خوبی است. اگر document جداگانه‌ای به اندازه چند کیلوبایت نگه دارید، MongoDB به بهترین وجه کار می‌کند. document بزرگ باعث ایجاد چندین مشکل در عملکرد خواهد شد.

برای درک بهتری از 16 مگابایت این کتاب جنگ جهانی تنها 360 کیلوبایت حجم دارد.

نتیجه گیری

برای درک کامل از MongoDB همراه با داشتن دید کامل از آنچه می‌خواهید با MongoDB پیاده کنید، این دو کمک بسیار زیادی در طراحی مناسب دیتابیس می‌کنند.

منابع:

۱ - MongoDB Design: Tips AND Tricks

۲ - MongoDB Data Modeling with Document Structure

۳ - Things I Wish I’d Known When Starting with MongoDB