يسلط الضوء:
- من الضروري تصميم المخطط على الرغم من أنه اختياري في MongoDB.
- وبالمثل ، يجب أن تتطابق الفهارس مع مخططك وأنماط الوصول.
- تجنب استخدام الأجسام الكبيرة والمصفوفات الكبيرة.
- كن حذرًا مع إعدادات MongoDB ، خاصة عندما يتعلق الأمر بالأمان والموثوقية.
- لا يحتوي MongoDB على مُحسِّن استعلام ، لذلك يجب توخي الحذر عند إجراء عمليات الاستعلام.
لقد كنت أعمل مع قواعد البيانات لفترة طويلة جدًا ، لكنني اكتشفت مؤخرًا MongoDB. هناك بعض الأشياء التي أود معرفتها قبل البدء بها. عندما يكون لدى الشخص بالفعل خبرة في مجال معين ، يكون لديه أفكار مسبقة حول ماهية قواعد البيانات وماذا يفعل. على أمل تسهيل فهم الآخرين ، إليك قائمة بالأخطاء الشائعة.
إنشاء خادم MongoDB بدون مصادقة
للأسف يتم تثبيت MongoDB بدون المصادقة بشكل افتراضي. من الطبيعي أن يتم الوصول إلى محطة العمل محليًا. ولكن نظرًا لأن MongoDB هو نظام متعدد المستخدمين يحب استخدام كميات كبيرة من الذاكرة ، فمن الأفضل وضعه على خادم به أكبر قدر ممكن من ذاكرة الوصول العشوائي ، حتى لو كنت ستستخدمه فقط للتطوير. قد يكون التثبيت على الخادم عبر المنفذ الافتراضي مشكلة ، خاصة إذا كان من الممكن تنفيذ أي كود جافا سكريبت في الطلب (على سبيل المثال ،
$whereكفكرة للحقن ).
هناك العديد من طرق المصادقة ، ولكن أسهلها هو تعيين معرف المستخدم / كلمة المرور. خذ هذه الفكرة بينما تفكر في مصادقة مبنية على LDAP . فيما يتعلق بالأمن ، يجب أن تظل MongoDB محدثة ويجب دائمًا فحص السجلات للوصول غير المصرح به. على سبيل المثال ، أود اختيار منفذ مختلف كمنفذ افتراضي.
تذكر ربط سطح الهجوم بـ MongoDB
تحتوي قائمة فحص أمان MongoDB على نصائح جيدة لتقليل مخاطر اختراق الشبكة وتسرب البيانات. من السهل رفضها والقول إن خادم التطوير لا يحتاج إلى مستوى عالٍ من الأمان. ومع ذلك ، فإن الأمور ليست بهذه البساطة وهذا ينطبق على جميع خوادم MongoDB. على وجه الخصوص ، ما لم يكن هناك سبب مقنع لاستخدام
mapReduce، groupأو $ حيث ، يجب عليك تعطيل استخدام كود JavaScript التعسفي عن طريق الكتابة في ملف التكوين javascriptEnabled:false. نظرًا لأن ملفات البيانات غير مشفرة في MongoDB القياسي ، فمن المنطقي تشغيل MongoDB مع مستخدم مخصص لديه وصول كامل للملفات ، مع وصول محدود إليه فقط والقدرة على استخدام عناصر التحكم في الوصول إلى الملفات الخاصة بنظام التشغيل.
خطأ في تصميم الدائرة
لا يستخدم MongoDB المخطط. لكن هذا لا يعني أن الدائرة ليست ضرورية. إذا كنت ترغب فقط في تخزين المستندات دون أي تخطيط ثابت ، فيمكن أن يكون الحفظ سريعًا وسهلاً ، ولكن استرجاعها لاحقًا قد يكون صعبًا . تستحق
المقالة الكلاسيكية " 6 قواعد أساسية لتصميم مخطط MongoDB" القراءة ، بينما تستحق ميزات مثل مستكشف المخطط في أداة الطرف الثالث في Studio 3T استخدامها للتحقق المنتظم من صحة المخطط.
لا تنس ترتيب الفرز
يمكن أن يكون نسيان ترتيب الفرز هو الأكثر إحباطًا وإهدارًا لأي خطأ آخر في التكوين. يستخدم MongoBD الفرز الثنائي افتراضيًا . لكن من غير المحتمل أن يكون مفيدًا لأي شخص. كانت الأنواع الثنائية الحساسة لحالة الأحرف ، والحساسة للإجهاد ، تعتبر مفارقات تاريخية مثيرة للفضول إلى جانب الخرز والقفطان والشوارب المجعدة في الثمانينيات من القرن الماضي. الآن استخدامها لا يغتفر. في الحياة الواقعية ، "دراجة نارية" هي نفسها "دراجة نارية". و "بريطانيا" و "بريطانيا" هما نفس المكان. الحرف الصغير هو ببساطة المكافئ الكبير للحرف الكبير. ولا تجعلني أتحدث عن فرز علامات التشكيل. استخدم الترتيب غير المتحسس لحالة الأحرف عند إنشاء قاعدة بيانات في MongoDBالتي تتوافق مع لغة وثقافة مستخدمي النظام . سيؤدي ذلك إلى تبسيط البحث عن بيانات السلسلة بشكل كبير.
إنشاء مجموعات بمستندات كبيرة
يسر MongoDB استضافة مستندات كبيرة يصل حجمها إلى 16 ميجا بايت في مجموعات ، وقد تم تصميم GridFS للمستندات الكبيرة التي يزيد حجمها عن 16 ميجا بايت . ولكن لمجرد أنه يمكن وضع المستندات الكبيرة هناك ، فليس من الجيد الاحتفاظ بها هناك. يعمل MongoDB بشكل أفضل إذا قمت بحفظ المستندات الفردية التي يبلغ حجمها عدة كيلوبايت ، ومعاملتها مثل الصفوف في جدول SQL واسع. ستكون المستندات الكبيرة مصدرًا لمشاكل الأداء .
قم بإنشاء مستندات ذات مصفوفات كبيرة
يمكن أن تحتوي المستندات على صفائف. من الأفضل أن يكون عدد العناصر في المصفوفة بعيدًا عن العدد المكون من أربعة أرقام. إذا تمت إضافة عناصر إلى المصفوفة بشكل متكرر ، فستتجاوز حجم المستند الذي يحتويها ، وسيتعين نقلها ، مما يعني أن الفهارس ستحتاج إلى التحديث أيضًا . عند إعادة فهرسة مستند بمصفوفة كبيرة ، غالبًا ما يتم الكتابة فوق الفهارس ، حيث يوجد لكل عنصر سجل يخزن فهرسه. تحدث إعادة الفهرسة هذه أيضًا عند إدراج مستند أو حذفه.
يحتوي MongoDB على ما يسمى بـ "عامل التعبئة" الذي يوفر مساحة للمستندات لتنمو لتقليل هذه المشكلة.
قد تعتقد أنه يمكنك الاستغناء عن فهرسة المصفوفات. لسوء الحظ ، نظرًا لنقص الفهارس ، قد تواجهك مشكلات أخرى. نظرًا لأن المستندات يتم مسحها ضوئيًا من البداية إلى النهاية ، فسوف يستغرق الأمر وقتًا أطول للعثور على العناصر في نهاية المصفوفة ، وستكون معظم العمليات المرتبطة بمثل هذا المستند بطيئة .
لا تنس ترتيب المراحل في مسائل التجميع
في نظام قاعدة بيانات مع مُحسِّن استعلام ، تعد الاستعلامات التي تكتبها تفسيرات لما تريد الحصول عليه ، وليس كيفية الحصول عليه. تعمل هذه الآلية عن طريق القياس مع الطلب في المطعم: عادةً ما تطلب طبقًا فقط ، ولا تقدم تعليمات مفصلة للطاهي.
في MongoDB ، تقوم بإرشاد الطاهي. على سبيل المثال ، تحتاج إلى التأكد من أن البيانات تمر في
reduceأقرب وقت ممكن في خط الأنابيب باستخدام $matchو $project، ولا يحدث الفرز إلا بعد ذلك reduce، وأن البحث يتم بالترتيب الذي تريده بالضبط. يمكن أن يفسدك وجود مُحسِّن استعلام يلغي العمل غير الضروري ، وينظم المراحل على النحو الأمثل ، ويحدد نوع الاتصال. في MongoDB ، لديك المزيد من التحكم بتكلفة الراحة.
أدوات مثلسوف يجعل Studio 3T من السهل إنشاء استعلامات التجميع في MongoDB . يسمح لك محرر التجميع بتطبيق عبارات خط الأنابيب خطوة واحدة في كل مرة ، بالإضافة إلى التحقق من صحة الإدخال والإخراج في كل خطوة لتبسيط التصحيح.
باستخدام التسجيل السريع
لا تقم أبدًا بتعيين معلمات كتابة MongoDB بسرعة عالية ولكن موثوقية منخفضة. يبدو وضع "الملف والنسيان" هذا سريعًا لأن الأمر يعود قبل إجراء الكتابة. إذا تعطل النظام قبل كتابة البيانات على القرص ، فسيتم فقدها وفي حالة غير متسقة. لحسن الحظ ، تم تمكين التسجيل في MongoDB 64 بت.
تستخدم محركات التخزين MMAPv1 و WiredTiger التسجيل لمنع ذلك ، على الرغم من أن WiredTiger يمكن أن يستعيد آخر نقطة تفتيش مطابقة إذا تم تعطيل التسجيل.
يضمن تسجيل دفتر اليومية أن قاعدة البيانات في حالة متسقة بعد الاسترداد ويحتفظ بجميع البيانات حتى يتم تسجيلها. يتم تكوين تردد الإدخالات باستخدام المعلمة
commitIntervalMs.
للتأكد من السجلات ، تأكد من تمكين التسجيل في ملف التكوين
(storage.journal.enabled)وأن تكرار السجلات مناسب لكمية المعلومات التي يمكنك تحمل فقدها.
الفرز بدون فهرس
عند البحث والتجميع ، غالبًا ما يكون من الضروري فرز البيانات. نأمل أن يتم ذلك في إحدى المراحل النهائية ، بعد تصفية النتيجة لتقليل كمية البيانات التي يتم فرزها. ومع ذلك ، فأنت بحاجة إلى فهرس للفرز . يمكنك استخدام فهرس واحد أو متعدد.
إذا لم يكن هناك فهرس مناسب ، فإن MongoDB ستستغني عنه. هناك حد للذاكرة يبلغ 32 ميجابايت على الحجم الإجمالي لجميع المستندات في عملية الفرز ، وإذا وصل MongoDB إلى هذا الحد ، فسيؤدي إما إلى ظهور خطأ أو إرجاع مجموعة سجلات فارغة .
البحث بدون دعم الفهرس
تؤدي استعلامات البحث وظيفة مشابهة لعملية JOIN في SQL. للحصول على أفضل أداء ، يحتاجون إلى فهرس القيمة الرئيسية المستخدمة كمفتاح خارجي. هذا ليس واضحًا لأن الاستخدام لا ينعكس في ملف
explain(). هذه المؤشرات هي بالإضافة إلى فهرس كتب في explain()، والذي يستخدم بدوره من قبل مشغلي خطوط الأنابيب $matchو $sort، عندما تحدث في بداية الطريق. يمكن أن تغطي الفهارس الآن أي مرحلة من مراحل خط أنابيب التجميع .
الانسحاب من استخدام التحديث المتعدد
تُستخدم الطريقة
db.collection.update()لتغيير جزء من مستند موجود أو مستند بأكمله ، حتى الاستبدال الكامل ، اعتمادًا على المعلمة التي تحددها update. ليس من الواضح أنه لن يقوم بمعالجة جميع المستندات في المجموعة حتى تقوم بتعيين خيار multiتحديث جميع المستندات التي تفي بمعايير الاستعلام.
لا تنس أهمية ترتيب المفاتيح في جدول التجزئة
في JSON ، يتكون الكائن من مجموعة غير مرتبة من صفر أو أكثر من أزواج الاسم / القيمة ، حيث يكون الاسم سلسلة والقيمة عبارة عن سلسلة أو رقم أو منطقي أو صفر أو كائن أو مصفوفة.
للأسف ، تضع BSON أهمية كبيرة على الطلب عند البحث. في MongoDB، من اجل مفاتيح داخل مضمنة كائنات المسائل ، أي
{ firstname: "Phil", surname: "factor" }ليس هو نفسه { { surname: "factor", firstname: "Phil" }. بمعنى أنه يجب عليك الاحتفاظ بترتيب أزواج الاسم / القيمة في المستندات إذا كنت تريد التأكد من العثور عليها.
لا تخلط بين "خالية" و "غير محدد"
لم تكن القيمة "undefined" صالحة أبدًا في JSON وفقًا لمعيار JSON الرسمي (ECMA-404 ، القسم 5) ، على الرغم من استخدامها في JavaScript. علاوة على ذلك ، بالنسبة لـ BSON يتم إهماله وتحويله إلى
$null، وهو ليس دائمًا حلاً جيدًا. تجنب استخدام "غير محدد" في MongoDB .
استخدم $limit()بدون$sort()
في كثير من الأحيان ، عندما تقوم بالتطوير في MongoDB ، من المفيد فقط رؤية عينة من النتيجة التي ستظهر من استعلام أو تجميع. إنه مفيد لهذه المهمة
$limit()، لكن لا يجب أن يكون في الإصدار النهائي من الكود ، ما لم تستخدمه أمامه $sort. هذا الميكانيكي ضروري لأنه بخلاف ذلك لا يمكنك ضمان ترتيب النتيجة ولا يمكنك عرض البيانات بشكل موثوق. في الجزء العلوي من النتيجة ، ستحصل على سجلات مختلفة حسب الفرز. للعمل بشكل موثوق ، يجب أن تكون الاستعلامات والتجميعات حتمية ، أي تنتج نفس النتائج في كل مرة يتم تنفيذها. الكود ، الذي $limit()ليس كذلك $sort، لن يكون حتميًا ويمكن أن يتسبب لاحقًا في أخطاء يصعب تعقبها.
خاتمة
الطريقة الوحيدة للإحباط من MongoDB هي مقارنتها مباشرة بنوع آخر من قواعد البيانات ، مثل DBMS ، أو استخدامها بناءً على بعض التوقعات المحددة. إنها مثل مقارنة برتقالة بالشوكة. أنظمة قواعد البيانات لها أهداف محددة. من الأفضل أن تفهم وتقدير هذه الاختلافات بنفسك. سيكون من العار أن نضغط على مطوري MongoDB بسبب المسار الذي أجبرهم على اتباع مسار DBMS. أريد أن أرى طرقًا جديدة ومثيرة لحل المشكلات القديمة ، مثل ضمان تكامل البيانات وبناء أنظمة بيانات تكون مرنة ضد الفشل والهجوم من قبل المستخدمين الضارين.
يعد تنفيذ MongoDB 4.0 لمعاملات ACID مثالًا جيدًا على كيفية ابتكار التحسينات المهمة. أصبحت المعاملات متعددة المستندات وكشوف الحساب متعددة الذرات الآن. أصبح من الممكن أيضًا تعديل الوقت المستغرق للحصول على أقفال وإكمال المعاملات المعلقة ، وكذلك تغيير مستوى العزل.
