كيف تقرر ما إذا كان MongoDB مناسبًا لك

على مدار العامين الماضيين ، قمت بإنشاء تطبيقات ويب حول MongoDB. في هذه المقالة القصيرة أود أن أجيب على بعض الأسئلة المتكررة أو سوء الفهم لدى معظم المطورين عند تقييمها:

  • ما هو الترخيص؟
  • ماذا يعني أن MongoDB هي قاعدة بيانات NoSQL؟
  • ماذا عن عروض MongoDB؟

الترخيص

نعم ، MongoDB مرخص بموجب GNU AGPL v3.0 لمؤسسة البرمجيات الحرة . من الناحية العملية ، هذا يعني أنه يجب إطلاق التحسينات التي تجريها على MongoDB للمجتمع. يجب أيضًا توزيع الكود المصدري لأي عمل مشتق.

قد تتساءل عما إذا كان التطبيق الخاص بك هو عمل مشتق. يجب أن أعترف أنني لم أجد تعريفًا بسيطًا لمثل هذا المصطلح. ومع ذلك ، في حالة MongoDB الخاصة ، فهم ببساطة يدركون أن التطبيقات التي تستخدم قاعدة البيانات الخاصة بهم هي عمل منفصل. علاوة على ذلك ، يتم إصدار برامج التشغيل المدعومة الخاصة بهم بموجب ترخيص Apache v2.0. هذا هو الترخيص المسموح. لا يتطلب منك نشر كود المصدر الخاص بك ، وعادة ما يتحدث تطبيقك فقط مع MongoDB باستخدام برنامج تشغيل.

نتيجة لذلك ، لا داعي للقلق بشأن ترخيص MongoDB لبناء تطبيقك حوله. حتى أنهم يرسلون رسائل موقعة تؤكد الوعد إلى الإدارات القانونية إذا كانت هناك أسئلة. كما أنها توفر تراخيص تجارية إذا كانت الرسالة الموقعة غير كافية.

ملاحظة: على الرغم من أن قدرًا كبيرًا من الخبرة جعلني أثق في هذا التحليل ، فأنا لست محاميًا. المنظر المعروض هنا هو فهمي الشخصي وليس رسمياً.

NoSQL

نعم ، MongoDB هي قاعدة بيانات NoSQL. يمكن أن تكون هذه الكلمة مربكة للغاية. سأحاول تحليل الأفكار الأكثر شيوعًا مع التركيز على كيفية تطبيق ذلك على MongoDB.

موجه المستند

في قواعد بيانات SQL التقليدية ، يتم ترتيب البيانات في شكل جداول وصفوف. يحتوي كل صف على عدد ثابت من الأعمدة التي يمكنها فقط تخزين البيانات من نوع معين (على سبيل المثال ، عدد صحيح ، نص ، تاريخ ووقت). هذا يحدد مخطط البيانات الخاصة بك.

في MongoDB ، يتم تخزين البيانات في شكل كائنات BSON منظمة في مجموعات. البياناتعادة ما يتم التعامل معها في شكل كائنات JSON. هذا يجعل تعيين الكائنات في قاعدة البيانات مهمة بسيطة ، وعادةً ما يزيل أي شيء مشابه لرسم الخرائط العلائقية للكائنات .

المعاملات

قبل الإصدار 4 ، قدمت MongoDB المعاملات على مستوى المستند فقط. لم يتم تطبيق عمليات الكتابة جزئيًا على مستند مدرج أو محدث. كانت العملية ذرية بمعنى أنها إما فشلت أو تنجح. بالنسبة للوثيقة بأكملها ، قيل إنها ACID على مستوى الوثيقة. نتيجة لذلك ، لم تكن هناك إمكانية للتغييرات الذرية التي تمتد عبر وثائق متعددة. كان عليك محاكاة معاملات قاعدة البيانات المطلوبة (على سبيل المثال ، باستخدام التزام مرحلتين).

منذ الإصدار 4 ، تدعم MongoDB معاملات ACID متعددة المستندات ، مما يجعلها قاعدة البيانات مفتوحة المصدر الوحيدة لدمج نموذج المستند مع ضمانات ACID.

مخطط أقل (حقًا؟)

هذا يعني أنك لست مضطرًا لإخبار قاعدة البيانات بهيكل بياناتك والأنواع الأولية التي يجب استخدامها قبل أن تتمكن من إدارتها. هذا يعني أيضًا أنه يمكنك مزج المستندات التي لها هياكل مختلفة في نفس مجموعة البيانات.

تتمثل إحدى الفوائد العظيمة في أن عمليات ترحيل المخطط أصبحت أسهل (معظم التعديلات على قاعدة البيانات شفافة وتلقائية). من غير المحتمل أن يسبب التراجع مشاكل. ميزة أخرى هي أن التوسع الديناميكي لنماذج البيانات الحالية بسمات مخصصة في وقت التشغيل أمر مباشر .

لكنكل هذا لا يعني أنه ليس لديك أي مخطط على الإطلاق. إذا لم يتم التصريح عنه صراحة ، فإنه يتألق ضمنيًا من منطق التطبيق الخاص بك. قد يتم الإعلان عنها بطرق أخرى للتعامل مع التحقق من صحة النموذج / البيانات. على أي حال ، لا يزال يتعين عليك إخبار قاعدة البيانات صراحةً بكيفية إنشاء الفهارس لضمان الأداء الجيد.

في الواقع ، يعد تصميم المخطط حجر الزاوية في إنشاء قواعد بيانات رائعة ، سواء أكانت SQL أم لا. إذا كنت لا تفهم بياناتك وقيود الأجهزة والبرامج ، فلن تتمكن من تصميم مخطط بشكل فعال.

غير علائقية (حقًا؟)

هذا يعني أنه لا يتعين عليك دائمًا إنشاء علاقة بين مستندين للتعامل مع هياكل البيانات المجمعة.

في الواقع ، في قواعد البيانات العلائقية ، تسمح لك جملة SQL JOIN بدمج صفوف من جدولين أو أكثر باستخدام حقل مشترك بينهما. تم تصميم قواعد البيانات الموجهة للمستندات مثل MongoDB لتخزين البيانات غير المنسقة . من الناحية المثالية ، يجب ألا تكون هناك علاقة بين المجموعات: إذا كانت نفس البيانات مطلوبة في وثيقتين أو أكثر ، فيجب تكرارها. واحدة من الفوائد العظيمة هي أن عملية قراءة واحدة مطلوبة للحصول على جميع البيانات.

ولكن لا يزال بإمكانك إنشاء العلاقات والرجوع إلى مستند آخر إذا كنت ترغب في ذلك أو إذا احتجت:

  • حسب المعرف ، يمكنك بعد ذلك "ملئها" يدويًا باستخدام استعلام ثان أو باستخدام DBRefs
  • بأي مجال آخر ، ثم يمكنك استخدام $lookupعامل التشغيل

هذا يجعل MongoDB مرنًا حقًا ويسمح لك باختيار كيفية التعامل مع العلاقات بين الكائنات الخاصة بك على أساس كل حالة على حدة .

أداء

قراءة و كتابة

نعم ، تم تصميم MongoDB مثل أي قاعدة بيانات "حقيقية" للتعامل مع حجم ضخم من البيانات. باختصار ، لا تعد مئات أو آلاف العناصر شيئًا لقاعدة بيانات ، لذلك لا داعي للقلق إذا كان لديك مثل هذه الأرقام. يمكنك أن تجد الكثير من المعايير حولها. إليك طريقة بسيطة لتعطيك بعض الترتيب التقريبي للحجم. المستندات المخزنة بسيطة حقًا وعادة ما تمثل قياسًا زمنيًا:

{ value: random(0,100), timestamp: date}

نظرًا للطريقة التي يفوض بها MongoDB إدارة الذاكرة لنظام التشغيل ، فإن وجود مستندات أكثر تعقيدًا (تحتوي عادةً على عشرات السمات) لا يؤثر بشكل كبير على النتائج

تم فهرسة كلا السمتين. يقوم MongoDB تلقائيًا بإضافة وفهرسة المعرف الفريد للمستند. اختبرت ثلاثة طلبات:

  • ابحث عن القيمة القصوى للمجموعة باستخدام إطار التجميع
  • أوجد أكبر 100 قيمة أكبر من 99.9
  • الحصول على وثيقة واحدة عن طريق الهوية

لا يستفيد "الحد الأقصى للطلب" من الفهارس بسبب التجميع ، بينما يمكن لطلبات "أكبر من" و "حسب المعرف" استخدامها. سترى مدى أهمية هذا للأداء.

كان تكوين الاختبار MongoDB 3.4.1 64 بت - OS Windows 7 Pro SP1 - CPU Core i7–4712HQ 2.3GHz - 16Go RAM - SSD HD ، وكانت نتائج الاختبار كالتالي:

لذلك ، إذا قمت ببناء الفهارس الصحيحة للاستعلام عن مليار مستند ، فستظل تعمل بشكل كافٍ لمعظم التطبيقات على خادم واحد. إذا لزم الأمر ، يمكنك زيادة الأداء باستخدام التجزئة.

فيما يلي البرامج النصية المستخدمة لإنشاء / الاستعلام عن قاعدة البيانات لهذا الاختبار:

وأوامر التشغيل:

// Launch server./mongod --dbpath "C:\Program Files\MongoDB\Server\3.4\data" --port 27018// Insertion exemple for 10e7./mongo --port 27018 --eval "var arg1=10000000" create_collection.js// Requests./mongo --port 27018 --eval "" query_collection.js

ذاكرة

نعم ، يبدو موقع MongoDB غالبًا أنه يستخدم كل ذاكرة الوصول العشوائي المتاحة. يعتمد في الواقع على محركات تخزين مختلفة. WiredTiger هو البداية الافتراضية في MongoDB 3.2 ، و MMAPv1 هو الافتراضي لإصدارات MongoDB قبل 3.2. ومع ذلك ، فإنهم يعملون بشكل مشابه. عبر ذاكرة التخزين المؤقت لنظام الملفات ، يستخدمون تلقائيًا جميع الذاكرة الخالية التي لا يتم استخدامها بواسطة ذاكرة التخزين المؤقت للمحرك أو بواسطة عمليات أخرى . وهذا متماسك إذا كنت ترغب في الحصول على أقصى أداء.

لذلك غالبًا ما تُظهر شاشات موارد النظام أن MongoDB يستخدم الكثير من الذاكرة ، لكن استخدامه ديناميكي . إذا احتاجت عملية أخرى فجأة إلى نصف ذاكرة الوصول العشوائي للخادم ، فسوف ينتج MongoDB ذاكرة مخزنة مؤقتًا للعملية الأخرى.

نتيجة لذلك ، فإن المعلمة الفردية التي يمكنك ضبطها لتحسين استخدام الذاكرة هي حجم ذاكرة التخزين المؤقت للمحرك. على سبيل المثال ، بشكل افتراضي ، يستخدم محرك WiredTiger 50٪ من ذاكرة الوصول العشوائي مطروحًا منها 1 غيغابايت ، والتي يمكن أن تكون كبيرة جدًا على الخوادم التي تحتوي على ذاكرة كبيرة. يمكن أن يسبب هذا بعض المشاكل إذا كنت تستخدم حاويات ذات ذاكرة محدودة ، لذلك ببساطة اكتشف التوازن الصحيح لحالة الاستخدام الخاصة بك.

استنتاج

آمل أن تكون لديك فكرة أكثر دقة عن الفوائد التي تقدمها MongoDB إذا كانت تناسب احتياجاتك. في الآونة الأخيرة ، بدأت MongoDB قاعدة بيانات كعرض خدمة يسمى MongoDB Atlas والتي قد تكون مفيدة لك لاختبارها.

إذا أعجبك هذا المقال ، فلا تتردد في إلقاء نظرة على حلولنا مفتوحة المصدر ، فريق Kalisio!