MongoDB

تُطبّق MongoDB لغة استعلام خاصة بها تُسمى لغة استعلام Mongo (MQL). ^{[ 23 ]} تدعم MongoDB الاستعلامات الميدانية، والاستعلامات النطاقية ، والبحث باستخدام التعابير النمطية . ^{[ 24 ]} يمكن للاستعلامات إرجاع حقول مُحددة من المستندات، كما يُمكن تضمين دوال JavaScript مُعرّفة من قِبل المستخدم . يُمكن أيضًا تهيئة الاستعلامات لإرجاع عينة عشوائية من النتائج بحجم مُحدد.

يمكن فهرسة الحقول في مستند MongoDB باستخدام الفهارس الأساسية والثانوية.

يوفر MongoDB توافرًا عاليًا من خلال مجموعات النسخ المتماثلة. ^{[ 25 ]} تتكون مجموعة النسخ المتماثلة من نسختين أو أكثر من البيانات. يمكن لكل عضو في مجموعة النسخ المتماثلة أن يعمل كنسخة أساسية أو ثانوية في أي وقت. تُجرى جميع عمليات الكتابة والقراءة على النسخة الأساسية افتراضيًا. تحتفظ النسخ الثانوية بنسخة من بيانات النسخة الأساسية باستخدام آلية النسخ المتماثل المدمجة. عند تعطل النسخة الأساسية، تُجري مجموعة النسخ المتماثلة تلقائيًا عملية انتخاب لتحديد النسخة الثانوية التي ستصبح النسخة الأساسية. يمكن للنسخ الثانوية اختياريًا إجراء عمليات القراءة، ولكن بياناتها تكون متسقة في النهاية فقط افتراضيًا.

إذا كان نشر MongoDB المُكرَّر يحتوي على عضو ثانوي واحد فقط، فيجب إضافة برنامج خفي منفصل يُسمى المُحكِّم إلى المجموعة. ويتولى هذا البرنامج مسؤولية حسم عملية اختيار العضو الأساسي الجديد. ^{[ 26 ]} ونتيجةً لذلك، يتطلب نشر MongoDB المُوزَّع المثالي ثلاثة خوادم منفصلة على الأقل، حتى في حالة وجود عضو أساسي واحد وعضو ثانوي واحد فقط. ^{[ 26 ]}

يتوسع MongoDB أفقيًا باستخدام التجزئة . ^{[ 27 ]} يختار المستخدم مفتاح التجزئة، الذي يحدد كيفية توزيع البيانات في المجموعة. تُقسّم البيانات إلى نطاقات (بناءً على مفتاح التجزئة) وتُوزّع عبر أجزاء متعددة، كل منها عبارة عن قاعدة بيانات رئيسية مع نسخة واحدة أو أكثر. بدلاً من ذلك، يمكن تجزئة مفتاح التجزئة لربطه بجزء، مما يتيح توزيعًا متساويًا للبيانات.

يمكن تشغيل MongoDB على عدة خوادم، مع موازنة الحمل أو تكرار البيانات للحفاظ على عمل النظام في حالة حدوث عطل في الأجهزة.

يمكن استخدام MongoDB كنظام ملفات ، يسمى GridFS ، مع ميزات موازنة الأحمال وتكرار البيانات عبر أجهزة متعددة لتخزين الملفات.

تُضمَّن هذه الوظيفة، المسماة نظام ملفات الشبكة ^{[ 28 ]} ، مع برامج تشغيل MongoDB. يوفر MongoDB للمطورين وظائف لمعالجة الملفات ومحتواها. يمكن الوصول إلى GridFS باستخدام أداة mongofiles أو إضافات Nginx ^{[ 29 ]} و lighttpd ^{[ 30 ]} . يقسم GridFS الملف إلى أجزاء، أو كتل، ويخزن كل كتلة منها كمستند منفصل ^{[ 31 ] .}

يوفر MongoDB ثلاث طرق لإجراء التجميع: مسار التجميع (المفضل )، ووظيفة map-reduce (التي تم إيقاف استخدامها بدءًا من MongoDB 5.0)، وطرق التجميع ذات الغرض الواحد. ^{[ 32 ]}

يمكن استخدام تقنية MapReduce لمعالجة البيانات على دفعات وعمليات التجميع. ومع ذلك، وفقًا لوثائق MongoDB، فإن مسار التجميع يوفر أداءً أفضل لمعظم عمليات التجميع. ^{[ 33 ]}

يُمكّن إطار التجميع المستخدمين من الحصول على نتائج مشابهة لتلك التي تُرجعها الاستعلامات التي تتضمن عبارة SQL GROUP BY. ويمكن ربط عوامل التجميع معًا لتشكيل سلسلة من العمليات، على غرار أنابيب يونكس . ويتضمن إطار التجميع عامل $lookup، الذي يُمكنه ربط المستندات من مجموعات متعددة، بالإضافة إلى عوامل إحصائية مثل الانحراف المعياري.

يدعم MongoDB مجموعات ذات حجم ثابت تسمى المجموعات المحدودة. يحافظ هذا النوع من المجموعات على ترتيب الإدخال، وبمجرد الوصول إلى الحجم المحدد، يتصرف مثل قائمة انتظار دائرية .

يدعم MongoDB معاملات ACID متعددة المستندات منذ الإصدار 4.0 في يونيو 2018. ^{[ 34 ]}

بسبب إعدادات الأمان الافتراضية في MongoDB، التي تتيح لأي مستخدم الوصول الكامل إلى قاعدة البيانات، سُرقت بيانات من عشرات الآلاف من عمليات تثبيت MongoDB. علاوة على ذلك، احتُجزت العديد من خوادم MongoDB مقابل فدية . ^{[ 42 ] [ 43 ]} في سبتمبر 2017، أعلن دافي أوتينهايمر، رئيس قسم أمن المنتجات في MongoDB، عن اتخاذ تدابير للتصدي لهذه المخاطر. ^{[ 44 ]}

في بعض حالات الفشل التي قد يتمكن فيها تطبيق ما من الوصول إلى عمليتين منفصلتين في MongoDB لا يمكنهما الوصول إلى بعضهما البعض، قد يُعيد MongoDB عمليات قراءة قديمة. كما قد يتراجع MongoDB عن عمليات كتابة تم تأكيدها. ^{[ 45 ]} تمت معالجة هذه المشكلة في الإصدار 3.4.0، الذي صدر في نوفمبر 2016، ^{[ 46 ]} وطُبقت على الإصدارات السابقة بدءًا من الإصدار 3.2.12. ^{[ 47 ]}

قبل الإصدار 2.2، كانت عمليات القفل تُنفذ على مستوى كل عملية خادم. مع الإصدار 2.2، أصبحت عمليات القفل تُنفذ على مستوى قاعدة البيانات. ^{[ 48 ]} بدءًا من الإصدار 3.0، ^{[ 49 ]} أصبحت محركات التخزين القابلة للتوصيل متاحة، وقد يُنفذ كل محرك تخزين عمليات القفل بطريقة مختلفة. ^{[ 49 ]} مع MongoDB 3.0، تُنفذ عمليات القفل على مستوى المجموعة لمحرك تخزين MMAPv1، ^{[ 50 ]} بينما يستخدم محرك تخزين WiredTiger بروتوكول تزامن تفاؤلي يوفر قفلًا فعالًا على مستوى المستند. ^{[ 51 ]} حتى مع الإصدارات السابقة للإصدار 3.0، يتمثل أحد أساليب زيادة التزامن في استخدام التجزئة . ^{[ 52 ]} في بعض الحالات، تُحرر عمليات القراءة والكتابة أقفالها. إذا توقع MongoDB أن صفحة ما من غير المرجح أن تكون موجودة في الذاكرة، فستُحرر العمليات قفلها أثناء تحميل الصفحات. توسع استخدام تحرير القفل بشكل كبير في الإصدار 2.2. ^{[ 53 ]}

حتى الإصدار 3.3.11، لم يكن بإمكان MongoDB إجراء الفرز بناءً على الترتيب ، وكان يقتصر على المقارنة على مستوى البايت باستخدام دالة memcmp ، مما لم يوفر ترتيبًا صحيحًا للعديد من اللغات غير الإنجليزية عند استخدامها مع ترميز Unicode . تم إصلاح هذه المشكلة في 23 أغسطس 2016.

قبل إصدار MongoDB 4.0، لم تكن الاستعلامات على الفهرس ذرية. وكان من الممكن تفويت المستندات التي تم تحديثها أثناء تنفيذ الاستعلامات. ^{[ 54 ]} وقد أدى إدخال آلية قراءة اللقطات في MongoDB 4.0 إلى القضاء على هذا الخطر. ^{[ 55 ]}

زعمت MongoDB أن الإصدار 3.6.4 قد اجتاز "أصعب اختبارات سلامة البيانات وصحتها واتساقها في هذا المجال" التي أجرتها شركة Jepsen، وأن "MongoDB تقدم من بين أقوى ضمانات اتساق البيانات وصحتها وسلامتها مقارنةً بأي قاعدة بيانات متاحة اليوم". ^{[ 56 ]} وقد نفت شركة Jepsen، التي تُعرّف نفسها بأنها "شركة أبحاث سلامة الأنظمة الموزعة"، كلا الادعاءين على تويتر ، قائلةً: "في ذلك التقرير، فقدت MongoDB بيانات وانتهكت مبدأ السببية الافتراضية". وفي تقريرها الصادر في مايو 2020 عن الإصدار 4.2.6 من MongoDB، كتبت Jepsen أن MongoDB لم تذكر سوى الاختبارات التي اجتازها الإصدار 3.6.4، وأن الإصدار 4.2.6 قد تسبب في المزيد من المشاكل. ^{[ 57 ]} وجاء في ملخص اختبار Jepsen جزئيًا ما يلي:

قام جيبسن بتقييم إصدار MongoDB 4.2.6، ووجد أنه حتى مع أعلى مستويات ضمان القراءة والكتابة، فشل في الحفاظ على عزل اللقطات. بدلاً من ذلك، لاحظ جيبسن انحرافًا في القراءة، وتدفقًا دوريًا للمعلومات، وكتابات مكررة، وانتهاكات للاتساق الداخلي. تعني الإعدادات الافتراضية الضعيفة أن المعاملات قد تفقد عمليات الكتابة وتسمح بعمليات قراءة غير مكتملة، حتى مع خفض مستويات الأمان المطلوبة على مستوى قاعدة البيانات والمجموعة. علاوة على ذلك، لم يضمن ضمان قراءة اللقطات الحصول على اللقطة إلا إذا اقترن بأغلبية ضمان الكتابة - حتى بالنسبة لمعاملات القراءة فقط. تُعقّد خيارات التصميم هذه الاستخدام الآمن لمعاملات MongoDB. ^{[ 58 ]}

في 26 مايو، قام جيبسن بتحديث التقرير ليقول: "حددت MongoDB خللًا في آلية إعادة محاولة المعاملات، ويعتقدون أنه مسؤول عن الحالات الشاذة الملحوظة في هذا التقرير؛ ومن المقرر إصدار تصحيح لهذا الخلل في الإصدار 4.2.8." ^{[ 58 ]} وقد تم إصلاح المشكلة في ذلك الإصدار، كما "تمت معالجة انتقادات جيبسن بشأن مخاوف الكتابة الافتراضية، حيث تم رفع مستوى مخاوف الكتابة الافتراضية إلى مستوى المخاوف الرئيسية (w:majority) بدءًا من MongoDB 5.0." ^{[ 59 ]}