لقد اكتشفت ذلك مؤخرًا تزيل Red Hat دعم MongoDB من القمر الصناعي (على سبيل المثال ، بسبب تغييرات الترخيص). لقد جعلني أفكر في أنني رأيت في السنوات القليلة الماضية مجموعة من المقالات حول مدى فظاعة برنامج MongoDB وأنه لا ينبغي لأحد أن يستخدمه على الإطلاق. ولكن خلال هذا الوقت ، أصبح MongoDB منتجًا أكثر نضجًا. ماذا حدث؟ هل كل الكراهية ناتجة بالفعل عن أخطاء في بداية تسويق نظام DBMS الجديد؟ أم أن الناس يستخدمون MongoDB في المكان الخطأ فقط؟

إذا شعرت فجأة أنني أدافع عن MongoDB ، يرجى القراءة تنصل في نهاية المقال.

اتجاه جديد

لقد عملت في صناعة البرمجيات منذ سنوات أكثر مما يمكن أن نقوله ، لكنني ما زلت جزءًا من الاتجاهات التي ضربت صناعتنا. لقد شاهدت ظهور 4GL و AOP و Agile و SOA و Web 2.0 و AJAX و blockchain ... القائمة لا حصر لها. كل عام هناك اتجاهات جديدة. يتلاشى بعضها سريعًا ، بينما يغير البعض الآخر بشكل أساسي طريقة تطوير البرامج.

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

ولكن من وقت لآخر ، يوجد (أو هناك مجيء ثانٍ ، كما في هذه الحالة) ابتكار جديد ، مدفوعًا بتنفيذ واحد معين له. في حالة NoSQL ، كان الضجيج مدفوعًا بشكل كبير بظهور MongoDB وصعوده. لم تبدأ MongoDB هذا الاتجاه: في الواقع ، بدأت شركات الإنترنت الكبيرة تواجه مشاكل في معالجة كميات كبيرة من البيانات ، مما أدى إلى عودة قواعد البيانات غير العلائقية. بدأت الحركة العامة بمشاريع مثل Bigtable من Google و Cassandra من Facebook ، لكن MongoDB أصبح التطبيق الأكثر شهرة ويمكن الوصول إليه لقاعدة بيانات NoSQL الذي تمكن معظم المطورين من الوصول إليه.

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

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

من المهم أن تتذكر أن MongoDB وقواعد بيانات المستندات بشكل عام ، تحل عددًا من المشكلات مع قواعد البيانات العلائقية التقليدية:

• مخطط صارم: باستخدام قاعدة بيانات علائقية ، إذا كان لديك بيانات تم إنشاؤها ديناميكيًا ، فأنت مجبر إما على إنشاء مجموعة من أعمدة البيانات "المختلفة" العشوائية ، أو دفع نقاط البيانات الكبيرة هناك ، أو استخدام تكوين EAV… كل هذا له عيوب كبيرة.
• صعوبة التحجيم: إذا كان هناك الكثير من البيانات التي لا تتناسب مع خادم واحد ، فإن MongoDB تقدم آليات للسماح لها بالتوسع عبر أجهزة متعددة.
• تعديلات الدوائر المعقدة: لا هجرات! في قاعدة البيانات العلائقية ، يمكن أن يكون تغيير هيكل قاعدة البيانات مشكلة كبيرة (خاصة عندما يكون هناك الكثير من البيانات). تمكنت MongoDB من تبسيط العملية بشكل كبير. وجعل الأمر سهلاً بحيث يمكنك فقط تحديث المخطط أثناء التنقل والمضي قدمًا بسرعة كبيرة.
• كتابة الأداء: كان أداء MongoDB جيدًا ، خاصة عند ضبطه بشكل صحيح. حتى التكوين الجاهز لـ MongoDB ، والذي تم انتقاده في كثير من الأحيان ، أظهر بعض أرقام الأداء المثيرة للإعجاب.

كل المخاطر عليك

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

لكي نكون منصفين ، لا أحد في 10gen / MongoDB Inc. لن أقول أن ما يلي ليس صحيحًا ، فهذه مجرد تنازلات.

• خسارة المعاملاتج: المعاملات هي سمة أساسية للعديد من قواعد البيانات العلائقية (ليس كلها ، ولكن معظمها). تعني المعاملة أنه يمكنك إجراء عمليات متعددة بشكل تلقائي وضمان بقاء البيانات متسقة. بالطبع ، مع قاعدة بيانات NoSQL ، يمكن أن تكون المعاملات ضمن مستند واحد ، أو يمكنك استخدام التزامات مرحلتين للحصول على دلالات المعاملات. لكن سيتعين عليك تنفيذ هذه الوظيفة بنفسك ... والتي يمكن أن تكون مهمة صعبة وتستغرق وقتًا طويلاً. غالبًا لا تدرك المشكلة حتى ترى أن البيانات الموجودة في قاعدة البيانات تدخل في حالات غير صالحة لأنه من المستحيل ضمان ذرية العمليات. ملاحظة: لقد أخبرني الكثيرون أن المعاملات قد تم تقديمها في MongoDB 4.0 العام الماضي ، ولكن مع بعض القيود. يبقى الاستنتاج من المقالة كما هو: تقييم كيف تناسب التكنولوجيا احتياجاتك.
• فقدان التكامل العلائقي (المفاتيح الخارجية): إذا كانت لبياناتك علاقات ، فسيتعين عليك تطبيقها في التطبيق. إن امتلاك قاعدة بيانات تحترم هذه العلاقات سيستغرق الكثير من العمل خارج التطبيق وبالتالي على المبرمجين لديك.
• عدم القدرة على تطبيق بنية البيانات: يمكن أن تكون المخططات الصارمة مشكلة كبيرة في بعض الأحيان ، ولكنها أيضًا آلية قوية لهيكلة بيانات جيدة إذا تم استخدامها بحكمة. توفر قواعد بيانات المستندات مثل MongoDB مرونة لا تصدق في المخطط ، ولكن هذه المرونة تقضي على مسؤولية الحفاظ على البيانات نظيفة. إذا لم تهتم بهم ، فسوف ينتهي بك الأمر بكتابة الكثير من التعليمات البرمجية في التطبيق الخاص بك لحساب البيانات التي لم يتم تخزينها بالشكل الذي تتوقعه. كما يقولون كثيرًا في شركتنا Simple Thread ... ستتم إعادة كتابة التطبيق يومًا ما ، لكن البيانات ستعيش إلى الأبد. ملاحظة: يدعم MongoDB التحقق من صحة المخطط ، وهو أمر مفيد ولكنه لا يوفر نفس الضمانات مثل قاعدة البيانات العلائقية. بادئ ذي بدء ، إضافة أو تغيير التحقق من صحة المخطط لا يؤثر على البيانات الموجودة في المجموعة. يجب عليك التأكد من تحديث البيانات وفقًا للمخطط الجديد. قرر بنفسك ما إذا كان هذا كافياً لاحتياجاتك.
• لغة الاستعلام الخاصة / فقدان النظام البيئي للأداة: كان ظهور SQL ثورة مطلقة ، ولم يتغير شيء منذ ذلك الحين. إنها لغة قوية بشكل لا يصدق ، ولكنها أيضًا معقدة للغاية. تعتبر الحاجة إلى إنشاء استعلامات قاعدة بيانات بلغة جديدة ، تتكون من أجزاء JSON ، خطوة كبيرة إلى الوراء من قبل الأشخاص الذين لديهم خبرة في SQL. هناك عالم كامل من الأدوات التي تتفاعل مع قواعد بيانات SQL ، من IDEs إلى أدوات إعداد التقارير. الانتقال إلى قاعدة بيانات لا تدعم SQL يعني أنه لا يمكنك استخدام معظم هذه الأدوات ، أو أنك بحاجة إلى تحويل البيانات إلى SQL من أجل استخدامها ، وهو الأمر الذي قد يكون أصعب مما تعتقد.

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

ما كان يمكن القيام به بشكل مختلف؟

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

كيف تختار التكنولوجيا المناسبة؟ كانت هناك عدة محاولات لإنشاء إطار عمل منهجي لتقييم التكنولوجيا ، مثل "إطار تنفيذ التقنيات في مؤسسات البرمجيات" и "Framefork لتقييم تقنيات البرمجيات"، ولكن يبدو لي أن هذا تعقيد غير ضروري.

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

إذا كنت لا تواجه بعض المشاكل ، فأنت لست بحاجة إلى أداة جديدة. نقطة.

السؤال الأول: ما هي المشاكل التي أحاول حلها؟

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

السؤال الثاني: ما الذي أفتقده؟

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

إذا لم يكن لديك أي منهما ، فمن المنطقي التفكير في الحد الأدنى من الاستثمار المحتمل لتحديد قيمة هذه الأداة. وإذا قمت باستثمار ، ما مدى صعوبة عكس القرار؟

الناس دائما يفسدون كل شيء

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

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

التقييم الموضوعي ليس بالأمر السهل ، لكن فهم التحيزات المعرفية الأساسية سيساعدك على اتخاذ قرارات أكثر عقلانية.

ملخص

عندما يظهر ابتكار ، يجب الإجابة على سؤالين بعناية فائقة:

• هل هذه الأداة تحل مشكلة حقيقية؟
• هل نحن جيدون في فهم المقايضات؟

إذا لم تتمكن من الإجابة على هذين السؤالين بثقة ، فتراجع بضع خطوات للوراء وفكر.

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

تنصل

أريد أن أوضح أنني لا أحب ولا أكره MongoDB. لم يكن لدينا نوع المشاكل التي من الأفضل حل MongoDB. أعلم أن شركة 10gen / MongoDB Inc. تصرفت بجرأة شديدة في البداية ، حيث حددت إعدادات افتراضية غير آمنة وروجت لـ MongoDB في كل مكان (خاصة في الهاكاثون) كحل شامل للعمل مع أي بيانات. ربما كان قرارا سيئا. لكنه يؤكد النهج الموصوف هنا: يمكن اكتشاف هذه المشكلات بسرعة كبيرة حتى مع التقييم السطحي للتكنولوجيا.

المصدر: www.habr.com