لقد اكتشفت مؤخرًا أن
Red Hat تزيل دعم MongoDB من القمر الصناعي (يقولون بسبب تغييرات الترخيص). لقد جعلني أعتقد أنه في السنوات القليلة الماضية ، رأيت مجموعة من المقالات حول مدى روعة MongoDB وأنه لا ينبغي لأحد استخدامها على الإطلاق. ولكن خلال هذا الوقت ، أصبح MongoDB منتجًا أكثر نضجًا. ماذا حدث؟ هل كل الكراهية ناجمة عن أخطاء في بداية تسويق نظام إدارة قواعد البيانات الجديد؟ أو هل يستخدم الناس MongoDB في مكان خاطئ؟
إذا شعرت فجأة بأنني أحمي MongoDB ، يرجى قراءة
إخلاء المسؤولية في نهاية المقال.
الاتجاه الجديد
لقد كنت أعمل في صناعة البرمجيات لأكثر من الوقت الكافي للتحدث بشكل لائق ، لكن على الرغم من ذلك ، فإن جزءًا صغيرًا فقط من الاتجاهات التي ضربت صناعتنا مثلت حسابي. لقد شهدت نمو 4GL ، AOP ، Agile ، الخدمية ، الويب 2.0 ، AJAX ، blockchain ... القائمة لا حصر لها. كل عام تظهر اتجاهات جديدة. بعضها يتلاشى بسرعة ، بينما يغير البعض الآخر بشكل أساسي طريقة تطوير البرمجيات.
في كل اتجاه جديد ، يتم إنشاء إثارة عامة معينة: إما أن يقفز الناس إلى القارب ، أو يرون الضوضاء الناتجة عن الآخرين - ويتبعون الحشد. يتم تدوين هذه العملية بواسطة Gartner في
دورة الضجيج . على الرغم من أنه مثير للجدل ، يصف هذا الرسم البياني تقريبًا ما يحدث للتقنيات قبل أن تصبح قابلة للاستخدام في النهاية.
ولكن من وقت لآخر ، يظهر ابتكار جديد (أو يحدث مجيء ثانٍ ، كما في هذه الحالة) ، مدفوعًا بتطبيق محدد واحد فقط. في حالة NoSQL ، كان الدافع وراء الضجيج القوي هو ظهور MongoDB وارتفاعه السريع. لم تطلق MongoDB هذا الاتجاه: في الواقع ، بدأت شركات الإنترنت الكبيرة تواجه مشاكل في معالجة كميات كبيرة من البيانات ، مما أدى إلى عودة قواعد البيانات غير ذات العلاقة. بدأت الحركة العامة بمشاريع مثل Bigtable من Google و Cassandra من Facebook ، لكن MongoDB أصبح التطبيق الأكثر شهرة وبأسعار معقولة لقاعدة بيانات NoSQL ، التي تمكن معظم المطورين من الوصول إليها.
ملاحظة: قد تعتقد أنني أقوم بخلط قواعد بيانات المستندات مع قواعد بيانات الأعمدة أو مخازن المفاتيح / القيمة أو أي من الأنواع الأخرى العديدة من مخازن البيانات التي تندرج تحت التعريف العام لـ NoSQL. وأنت على حق. ولكن في ذلك الوقت سادت الفوضى. كان الجميع مهووسًا بـ NoSQL ، وكان الجميع في أمس الحاجة إليها ، رغم أن الكثيرين لم يروا الاختلافات في التقنيات المختلفة. بالنسبة للكثيرين ، أصبح MongoDB مرادفًا لـ NoSQL.وهاجمها المطورين. لقد كانت فكرة مغرية إلى حد كبير أن يكون لديك قاعدة بيانات بدون مخطط يقيس بطريقة سحرية لحل أي مشكلة. في حوالي عام 2014 ، بدا أنه في كل مكان تم فيه استخدام قاعدة بيانات علائقية منذ عام ، مثل MySQL أو Postgres أو SQL Server ، بدأت قواعد بيانات MongoDB. على السؤال لماذا ، يمكنك الحصول على إجابة من banal "هذا هو مقياس الويب" إلى أكثر تفكيرًا "بياناتي ضعيفة التنظيم للغاية وتتناسب بشكل جيد مع قاعدة البيانات دون مخطط".
من المهم أن تتذكر أن قواعد بيانات MongoDB وقواعد المستندات تحل عمومًا عددًا من المشكلات في قواعد البيانات العلائقية التقليدية:
- مخطط صارم : مع قاعدة بيانات علائقية ، إذا كنت قد أنشأت بيانات ديناميكية ، فأنت مجبر على إنشاء مجموعة من أعمدة البيانات "المختلفة" العشوائية أو دفع نقاط البيانات هناك أو استخدام تكوين EAV ... كل هذا له عيوب كبيرة.
- صعوبة القياس : إذا كان هناك الكثير من البيانات التي لا تناسبها على خادم واحد ، فقد اقترح MongoDB آليات لتوسيع نطاقها على أجهزة متعددة.
- تعديلات الدوائر المتطورة : لا الهجرات! في قاعدة البيانات العلائقية ، يمكن أن يكون تغيير بنية قاعدة البيانات مشكلة كبيرة (خاصةً عندما يكون هناك الكثير من البيانات). كان MongoDB قادرا على تبسيط العملية إلى حد كبير. وقد جعل الأمر سهلاً للغاية بحيث يمكنك فقط تحديث الدائرة أثناء التنقل والمضي قدمًا بسرعة كبيرة.
- أداء التسجيل : كان أداء MongoDB جيدًا ، خاصة مع الضبط السليم. حتى تكوين MongoDB خارج الصندوق ، والذي كان يتم انتقاده في كثير من الأحيان ، أظهر بعض مقاييس الأداء المثيرة للإعجاب.
جميع المخاطر عليك.
كانت الفوائد المحتملة لـ MongoDB ضخمة ، خاصة بالنسبة لفئات معينة من المشاكل. إذا قرأت القائمة أعلاه دون فهم السياق وليس لديك أي خبرة ، فقد تحصل على انطباع بأن MongoDB هو بالفعل نظام إدارة قواعد بيانات ثوري. كانت المشكلة الوحيدة هي أن المزايا المذكورة أعلاه كانت مصحوبة بعدد من التحفظات ، بعضها مدرج أدناه.
في الإنصاف ، لا أحد في 10gen / MongoDB Inc. لن يقول أن الأمور التالية غير صحيحة ؛ إنها مجرد حل وسط.
- فقدان المعاملات : المعاملات هي سمة رئيسية للعديد من قواعد البيانات العلائقية (وليس كلها ، ولكن معظمها). معاملات تعني أنه يمكنك إجراء العديد من العمليات بشكل آلي ويمكن أن تضمن أن البيانات ستظل متسقة. بالطبع ، مع وجود قاعدة بيانات NoSQL ، يمكن أن تكون المعاملة ضمن نفس المستند ، أو يمكنك استخدام تعهدات ثنائية الطور للحصول على دلالات المعاملات. لكن عليك تنفيذ هذه الوظيفة بنفسك ... والتي يمكن أن تكون مهمة معقدة وتستغرق وقتًا طويلاً. غالبًا ما تكون غير مدرك للمشكلة حتى ترى أن البيانات الموجودة في قاعدة البيانات تقع في حالات غير مقبولة ، لأنه من المستحيل ضمان دقة العمليات. ملاحظة: أخبرني كثيرون أن المعاملات ظهرت في MongoDB 4.0 العام الماضي ، ولكن مع عدد من القيود. يظل الاستنتاج من المقالة كما هو: تقييم كيف تلبي التكنولوجيا احتياجاتك.
- فقدان السلامة الترابطية (المفاتيح الخارجية) : إذا كانت هناك علاقة في بياناتك ، فيجب عليك تطبيقها في التطبيق. سيؤدي امتلاك قاعدة بيانات تتوافق مع هذه العلاقات إلى إزالة جزء كبير من العمل من التطبيق ، وبالتالي من المبرمجين لديك.
- نقص القدرة على تطبيق بنية البيانات : تصبح المخططات الصارمة مشكلة كبيرة في بعض الأحيان ، ولكنها أيضًا آلية قوية لهيكلة البيانات الجيدة ، إذا تم استخدامها بشكل صحيح. توفر قواعد بيانات المستندات مثل MongoDB مرونة مذهلة في المخطط ، ولكن هذه المرونة تزيل مسؤولية الحفاظ على نظافة البيانات. إذا لم تعتني بهم ، فسيتعين عليك في النهاية كتابة الكثير من التعليمات البرمجية في التطبيق لحساب البيانات التي لم يتم تخزينها بالشكل الذي تتوقعه. كما تقول شركتنا غالبًا "مؤشر ترابط بسيط" ... في يوم ما ، سيتم إعادة كتابة التطبيق ، وستبقى البيانات إلى الأبد. ملاحظة: يدعم MongoDB التحقق من صحة المخطط: إنه مفيد ، لكنه لا يوفر نفس الضمانات الموجودة في قاعدة البيانات الترابطية. بادئ ذي بدء ، لا تؤثر إضافة التحقق من المخطط أو تعديله على البيانات الموجودة في المجموعة. يجب أن تتأكد بنفسك من تحديث البيانات وفقًا للنظام الجديد. قرر بنفسك إذا كان هذا يكفي لاحتياجاتك.
- لغة الاستعلام الأصلية / فقد النظام الإيكولوجي للأدوات : أصبح ظهور SQL ثورة مطلقة ، ولم يتغير شيء منذ ذلك الحين. إنها لغة قوية بشكل لا يصدق ، ولكنها أيضًا معقدة للغاية. تعتبر الحاجة إلى تصميم استعلامات قاعدة البيانات بلغة جديدة تتكون من أجزاء JSON خطوة كبيرة إلى الوراء من قبل الأشخاص الذين لديهم خبرة مع SQL. هناك مجموعة كاملة من الأدوات التي تتفاعل مع قواعد بيانات SQL: من IDE إلى أدوات التقارير. يعني الانتقال إلى قاعدة بيانات لا تدعم SQL أنه لا يمكنك استخدام معظم هذه الأدوات أو تحتاج إلى تحويل البيانات إلى SQL لاستخدامها ، وقد يكون ذلك أكثر صعوبة مما تعتقد.
العديد من المطورين الذين تحولوا إلى MongoDB لم يفهموا فعلاً المقايضات ، وكثيراً ما تراجعوا بشكل كبير ، وقاموا بإعدادها كمخزن بيانات أساسي. بعد ذلك ، كان من الصعب جدًا العودة.
ما يمكن القيام به بشكل مختلف؟
ليس الجميع قفز رأسه وضرب القاع. لكن العديد من المشاريع قامت بتثبيت قاعدة MongoDB حيث لم تكن تناسبها - وسيتعين عليها التعايش معها لسنوات عديدة أخرى. إذا أمضت هذه المنظمات بعض الوقت ونظرت بشكل منهجي في اختيار التقنيات ، لكان العديد منها قد اتخذ خيارًا مختلفًا.
كيفية اختيار التكنولوجيا المناسبة؟ كانت هناك عدة محاولات لإنشاء إطار منهجي لتقييم التكنولوجيا ، مثل
"إطار لتنفيذ التكنولوجيا في منظمات البرمجيات" و
"إطار لتقييم تقنيات البرمجيات" ، لكن يبدو لي أن هذا التعقيد غير ضروري.
يمكن تقييم العديد من التقنيات بشكل معقول بطرح سؤالين أساسيين فقط.
تكمن المشكلة في إيجاد الأشخاص الذين يمكنهم الاستجابة لهم بطريقة مسؤولة ، وقضاء الوقت في البحث عن إجابات ودون تحيز.إذا لم تواجه أي مشكلة ، فلن تحتاج إلى أداة جديدة. النقطة.
السؤال 1: ما هي المشاكل التي أحاول حلها؟
إذا لم تواجه أي مشكلة ، فلن تحتاج إلى أداة جديدة. النقطة. لا حاجة للبحث عن حل ثم الخروج بمشكلة. إذا لم تصادف مشكلة أن التكنولوجيا الجديدة لا تحل بشكل أفضل من التكنولوجيا الحالية ، فلا يوجد شيء للمناقشة. إذا كنت تفكر في استخدام هذه التقنية لأنك رأيت كيف يستخدمها الآخرون ، فكر في المشكلات التي يواجهونها واسألهم عما إذا كانت لديك مثل هذه المشاكل. من السهل قبول التكنولوجيا لأن الآخرين يستخدمونها ، تكمن الصعوبة في فهم ما إذا كنت تواجه نفس المشكلات.
السؤال 2: ما الذي أخسره؟
هذا بالتأكيد سؤال أكثر صعوبة ، لأنه يجب عليك أن تفهم التكنولوجيا القديمة والجديدة وتفهمها جيدًا. في بعض الأحيان لا يمكنك فهم شيء جديد حقًا حتى تقوم ببناء شيء ما أو يكون لديك موظف لديه مثل هذه التجربة.
إذا لم يكن لديك واحد أو آخر ، فمن المنطقي أن تفكر في الحد الأدنى للاستثمار الممكن لتحديد قيمة هذه الأداة. وإذا قمت بالاستثمار ، فما مدى صعوبة عكس القرار؟
الناس دائما يفسدون كل شيء
عند محاولة الإجابة على هذه الأسئلة بشكل محايد قدر الإمكان ، تذكر شيئًا واحدًا: عليك أن تكافح مع الطبيعة البشرية. هناك عدد من التحيزات المعرفية التي يجب التغلب عليها من أجل تقييم التكنولوجيا بشكل فعال. هنا مجرد أمثلة قليلة:
- تأثير الانضمام إلى الأغلبية - يعرف الجميع عنها ، لكن لا يزال من الصعب القتال معها. فقط تأكد من أن التكنولوجيا تتناسب مع احتياجاتك الحقيقية.
- تأثير الحداثة - يميل العديد من المطورين إلى التقليل من أهمية التقنيات التي كانوا يعملون معها لفترة طويلة ويقللون من مزايا التكنولوجيا الجديدة. ليس فقط المبرمجين ، كل شخص يخضع لهذا التحيز المعرفي.
- تأثير الخصائص الإيجابية - نحن نميل إلى معرفة ما هو موجود ، ونغفل ما هو مفقود. يمكن أن يؤدي ذلك إلى حدوث فوضى مع تأثير الجدة ، لأنك لا تبالغ في تقدير التكنولوجيا الجديدة فحسب ، بل تتجاهل أيضًا أوجه القصور فيها .
التقييم الموضوعي ليس بالأمر السهل ، لكن فهم التحيزات المعرفية الأساسية سيساعد على اتخاذ قرارات أكثر عقلانية.
ملخص
عند ظهور ابتكار معين ، يجب الإجابة عن سؤالين بعناية شديدة:
- هل هذه الأداة تحل مشكلة حقيقية؟
- هل نفهم الحلول الوسط جيداً؟
إذا لم تستطع الإجابة بثقة عن هذين السؤالين ، فراجع خطوات قليلة للتفكير.
فهل كان MongoDB هو الخيار الصحيح بشكل عام؟ بالطبع نعم كما هو الحال مع معظم التقنيات الهندسية ، وهذا يعتمد على العديد من العوامل. من بين الذين أجابوا على هذين السؤالين ، استفاد الكثيرون من MongoDB واستمروا في الاستفادة منه. من لم يفعل هذا ، آمل أن يكونوا قد تلقوا درسًا قيمًا وليس مؤلمًا جدًا حول الحركة على طول دورة الضجيج.
تنصل
أريد أن أوضح أنني لا أحب ولا كراهية لـ MongoDB. إنه لم نواجه أية مشاكل يكون MongoDB الأنسب لها. أعلم أن 10gen / MongoDB Inc. في البداية ، كانت تتصرف بجرأة شديدة ، حيث وضعت قيمًا افتراضية غير آمنة وتروج لـ MongoDB في كل مكان (وخاصةً على hackathons) كحل عالمي للعمل مع أي بيانات. ربما كان هذا قرارًا سيئًا. لكنه يؤكد النهج الموضح هنا: يمكن اكتشاف هذه المشكلات بسرعة كبيرة حتى مع وجود تقييم سطحي للتكنولوجيا.