مقارنة بين MySQL و MongoDB

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

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

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

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

نبذة موجزة عن MySQL و MongoDB

تُعرف لغة SQL بأنها لغة استعلام مهيكلة تستخدم لتخزين ومعالجة واسترجاع البيانات الموجودة في قاعدة بيانات علائقية Relational Database وهذه الأخيرة وهي مجموعة من عناصر البيانات التي تترابط مع بعضها بعلاقات محددة على شكل مجموعة من الجداول ذات الأعمدة والأسطر، ويعد التعامل مع هذه اللغة واضحًا لأن قواعد البيانات مهيكلة ومنظمة حتى مع المشاريع الكبيرة.

أما لغة NoSQL فهي لغة استعلام غير مهيكلة تستخدم لتخزين ومعالجة واسترجاع البيانات من قاعدة بيانات غير علائقية Non-Relational Database وهذا النوع من قواعد البيانات لا يستخدمُ المخططات Schema لبناء قواعد بيانات وإنما يستخدم نماذج مرن مثل أزواج الاسم والقيمة للمتطلبات Name-Value أو المستندات وهذا ما يمنح قاعدة البيانات المرونة العالية في التكيف مع البيانات المتغيرة للمشاريع الحديثة، ويعد التعامل مع هذه اللغة صعبًا نسبيًا في المشاريع الكبيرة.

تعد أنظمة إدارة قواعد البيانات DBMS -وهي اختصارا Database Management Systems- أنظمة برمجية تُستخدم لتخزين واسترجاع وتنفيذ الاستعلامات على البيانات المخزنة في قاعدة البيانات، وتعمل هذه الأنظمة كواجهة بين المستخدم النهائي وقاعدة البيانات، مما يسمح للمستخدمين بإنشاء وقراءة وتحديث وحذف البيانات في قاعدة البيانات.

قبل أن ندخل في تفاصيل الحديث عن هذين النظامين لا بدّ أن نوضح بأنه يمكن النظر إلى هذه المقارنة على أنها مقارنة بين نوعي قواعد البيانات SQL و NoSQL ولكن بطريقة غير مباشرة، كما أنه من الجدير بالذكر أن هنالك العديد من الأنظمة التي تدير قواعد البيانات من نوع SQL نذكر منها MySQL و PostgreSQL و Microsoft SQL Server وغيرها، وأيضًا هنالك أنظمة إدارة لقواعد البيانات NoSQL مثل MongoDB و BigTable و Redis و RavenDB و Cassandra و HBase و Neo4j و CouchDB وغيرها.

ما هي MySQL؟

تعريف قواعد بيانات MySQL هو نظام إدارة قواعد بيانات علائقية RDBMS -وهو اختصارا Relational Database Management System- يستخدم لتحديث وإدارة وإنشاء قواعد البيانات العلائقية، صدر عام 1995 وسرعان ما بنى تاريخًا قويًا وسمعة عالية وموثوقية كبيرة بفضل مميزاته من السهولة والأمان ومع إتاحته كنظام مفتوح المصدر الأمر الذي الذي عزز شعبيته ومكّن المبرمجين من التعديل على الشيفرة البرمجية. أما قاعدة البيانات العلائقية Relational Database: فهي مجموعة من عناصر البيانات مرتبطة بعلاقات محددة مسبقًا فيما بينها، وتنظم هذه العناصر كمجموعة من الجداول ذات الأعمدة والصفوف، ويمكن تمييز كل صف في الجدول بمعرف فريد يسمى مفتاح أساسي، ويمكن جعل الصفوف الموجودة بين جداول متعددة مرتبطة باستخدام مفاتيح خارجية.

يتوافق نظام إدارة MySQL مع العديد من الخوادم عبر جميع اللغات والبرامج الوسيطة، كما أن تصميمه متعدد الطبقات مع وحدات مستقلة الأمر الذي يوفر الحماية المطلوبة وهو يدعم الخيوط دعمًا كاملًا من خلال خيوط النواة Kernel Threads، كما يقدم أدوات مدمجة لتحليل الاستعلام وتحليل المساحة، ويمكنه التعامل مع كميات كبيرة من البيانات تصل حتى 50 مليون صف أو أكثر، ويعمل مع العديد من توزيعات يونكس UNIX ولينكس Linux.

ما هو MongoDB؟

تعريف MongoDB هو نظام لإدارة قواعد البيانات غير العلائقية Non-Relational Databases مثل NoSQL و Cassandra، ويمكننا هذا النظام من إدارة المعلومات في قواعد البيانات سواء إضافة أو حذف أو تعديل أو استرداد، كما أن هذا النظام مفتوح المصدر وله أيضًا إصدارات تجارية أيضًا. ظهرت الشركة في البداية في عام 2007 عندما واجه المبرمجون الثلاثة وايت ميريمان وإليوت هورويتز وكيفين رايان مشكلة أثناء عمليات التطوير وقابلية التوسع لتطبيق الويب المشهور DoubleClick إذ كان يتطلب الموقع عرض 400,000 إعلان في الثانية، ولكن الاعتماد على مناهج قواعد البيانات العلائقية التقليدية أدى لبطئ كبير الأمر الذي حفزهم لتأسيس شركة 10Gen ولتطور الشركة بعدئذٍ ويغير اسمها لاحقًا إلى MongoDB Inc في عام 2013 ولتطرح اسهمها للاكتتاب العام في عام 2017.

يدعم النظام أشكالًا مختلفة من البيانات وهذا لأن قواعد البيانات التي من نوع NoSQL بحد ذاتها تدعم هذه الأنواع ولا تتطلب قواعد البيانات أي مخططات مسبقة Database Schema مما يسمح بمرونة عالية في تطوير قواعد البيانات. في الواقع يمكن أن تكون المستندات في نفس المجموعة ومع ذلك لها هياكل مختلفة تمامًا فيما بينها.

يعتمد نظام MongoDB أسلوبًا مختلفًا لتخزين البيانات إذ يمثل المعلومات كسلسلة من المستندات المشابهة لصيغة JSON الموجودة في لغة جافاسكربت (للتوسع في فهم صيغة JSON يمكنك الاطلاع على مقال ما هي JSON؟)، وتسمى الصياغة التي يخزن بها Binary JSON أو BSON. وتعرف BSON بأنها شكل ثنائي لتمثيل هياكل البيانات البسيطة أو المعقدة بما في ذلك المصفوفات الترابطية Associative Arrays (المعروفة أيضًا باسم أزواج الاسم والقيمة Name-Value)، والمصفوفات المفهرسة بالأرقام الصحيحة، ومجموعة من الأنواع العددية الأساسية. تتشابه الحقول الموجودة في هذه المستندات مع الأعمدة الموجودة في قاعدة البيانات العلائقية. وعادة ما يستخدم المتغير BSON لتبادل البيانات، يذكر أن شركة MongoDB طورت هذا المتغير عام 2009.

مقارنة بين MySQL vs MongoDB

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

المجتمع والتطوير

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

وجه المقارنة	قواعد بيانات MySQL	قواعد بيانات MongoDB
الموقع الرسمي	MongoDB	MySQL
تاريخ أول إصدار	1995	2009
رقم الاصدار الحالي (الذي كان وقت كتابة المقال)	8.0.28	5.0.5

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

قابلية التوسع

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

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

يشير التوسع العمودي Vertical Scaling إلى التوسعة من خلال زيادة إمكانيات المكونات المادية للمخدم مثل زيادة قدرة وحدة المعالجة المركزية أو ذاكرة الوصول العشوائي …إلخ، بينما يشير التوسع الأفقي Horizontal Scaling إلى التوسع من خلال إضافة المزيد من الخوادم وتوزيع الحمولة عليها.

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

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

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

مخطط البيانات وتنوع البيانات

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

كما تتطلب MySQL إنشاءً مسبقًا لمخطط قواعد وتنظيم الجداول والأعمدة قبل تخزين أي بيانات، بالإضافة إلى ذلك يتطلب تعديل مخطط البيانات إعادة التفكير بعناية بكيفية تنفيذ التعديل من خلال لغة تعريف البيانات DDL (وهي اختصار Data Definition Language) أو لغة معالجة البيانات DML (وهي اختصار Data Manipulation Language) لأن نظام التعديل الذي تفرضه قواعد بيانات SQL صارم لذلك عندما يتغير مخطط قاعدة البيانات خصوصًا إن كانت التغييرات كبيرة، فنعيد بناء قاعدة البيانات ثم ننقل البيانات عليها من جديد، وفي الواقع هذا الاتساق هو من أكثر نقاط القوة في MySQL لأنه يحافظ على البيانات منظمة ومتسقة.

وأما بالنسبة لتنوع البيانات فإن قاعدة بيانات MongoDB تسمح بتخزين المستندات والتي تختلف في المحتوى والحجم، أما MySQL نظرًا لأن مخطط البيانات أكثر تقييدًا وصرامة، فإن كل صف داخل الجدول يتطلب نفس الأعمدة (أي مثلًا يجب لعمود الاسم في جدول بيانات MySQL أن يأخذ نفس نوع البيانات ونفس الحجم وفي حالتنا كون Varchar(50) أي بحجم 50 محرف فقط‎) والتي يمكن أن تكون صعبة، ولذلك تتفوق قاعدة بيانات MongoDB على قاعدة بيانات MySQL عند التعامل مع كميات متنوعة وكبيرة من البيانات المعقدة.

الأداء والسرعة

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

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

الحماية

تستخدم نظام قواعد البيانات MySQL نموذج أمان قائم على الامتيازات Privileges، والذي يتطلب مصادقة المستخدم أي أن النظام يتطلب عمليات أمان وهي المصادقة Authentication والتفويض Authorization والتحقق Verification، بالإضافة إلى ذلك تستخدم قواعد البيانات MySQL اتصالات مشفرة بين العملاء والخادم وذلك من خلال طبقة مآخذ التوصيل الآمنة SSL بروتوكول أمان.

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

خصائص ACID

تعد خصائص ACID وهي اختصار للكلمات التالية: الذرية Atomicity والاتساق Consistency والعزل Isolation والمتانة Durability من الخصائص المهمة جدًا عند التعامل مع قواعد البيانات، ويعد توافر هذه الشروط أساسيًا للوثوق بتعاملات قاعدة البيانات يذكر أن أول من طرح هذه الشروط هو العالم جيم جراي Jim Gray وذلك في أواخر الستينات القرن العشرين. تتكون تعاملات قواعد البيانات Database Transaction من مجموعة من العمليات المفردة. فمثلًا عند تحويل مبلغ من حساب بنكي إلى آخر، يخصم المبلغ من حساب المصدر ويضاف في الحساب المستقبل. فيكون لدينا عمليتان لكنهما معا تشكلات تعاملًا واحدًا، وعمومًا لنشرح بالضبط أهمية كل خاصية من هذه الخواص:

الذرية Atomicity: وتعني أن تعاملات قاعدة البيانات إما أن تنفذ جميع عملياتها بصورة كاملة أو لا تُنفذ أيًا منها، بمعنى أنه لا يوجد حل وسط، ففي مثال التحويل البنكي إما أن تنفذ عمليتي الخصم والإيداع أو لا تُنفذ أية واحدة منها لأن تنفيذ أحدهما وفشل الآخر سينتجُ عنه خلل في صحة البيانات.
الاتساق Consistency: وتعني أن تظل قاعدة الباينات ملتزمة بقوانين تكامل البيانات كما حددها مصمم قاعدة البيانات بعد تنفيذ التعامل، فمثلًا إذا حُدد الحد الأدنى للرصيد بمبلغ معين يجب أن ترفض قاعدة البيانات أي تعامل ينتج عنه في النهاية إخلال بهذا القانون.
العزل Isolation: وتعني أن تنفذ التعاملات المختلفة بمعزل عن بعضها بعضًا، ويختص هذا الشرط بقواعد البيانات التي تنفذ عدة تعليمات متزامنة، فمثلًا إذا أراد العميل الكشف عن رصيده أثناء أجراء تعامل التحويل مالي يجب أن تمنحه قاعدة البيانات إما البيانات التي سبقت التحويل أو التي نتجت عنه (بفرض أنها نفذت بنجاح).
المتانة Durability: وهي إذا ظهر للمستخدم نتيجة مفادها أن التعامل نُفذّ بنجاح، فإن ذلك يعني أن التعامل لن يُتراجع عنه مهما حدث، حتى في حالة حدوث أي أعطال لاحقة في قاعدة البيانات.

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

طريقة كتابة الاستعلام

يعد الفرق بين البيانات المهيكلة وغير المهيكلة نقطة انطلاق مفيدة لأن البيانات المنظمة تتبع نموذجًا أو مخططًا محددًا جيدًا. بينما نجد بأن البيانات غير المهيكلة ليست منظمة وفقًا لأي نموذج محدد مسبقًا. ولذلك من المنطقي أن نجد نظام قواعد البيانات MySQL يستخدم لغة الاستعلام المهيكلة SQL عند طلب معلومات من جدول قاعدة بيانات، كما أنه لإنشاء جداول في قاعدة البيانات يتطلب معرفة بلغة تعريف البيانات DDL، ولتعديل البيانات يجب تعلم لغة معالجة البيانات DML وبذلك نستطيع التحكم الكامل بقواعد البيانات.

أما بالنسبة لنظام قواعد البيانات MongoDB فهي تعتمد على لغة استعلام غير مهيكلة وهي MongoDB Query Language، والتي تعتمد بدورها على جافاسكربت وتحديدًا طريقة تبادل البيانات JSON الأمر الذي يجعل MongoDB تدعم لغات متعددة (مثل بايثون وجافا و C#‎ و Perl و PHP وروبي وجافاسكربت) ويمكن كتابة استعلام مركب ومحدد لمختلف الحقول داخل مستندات المجموعة باستخدام عوامل تشغيل الاستعلام.

لنستعرض المثال التالي لفهم كيفية الاختلافات التي تحدث بين الاستعلامات لنفترض أن لدينا قاعدة بيانات تحتوي على جدول به الأعمدة التالية:

الاسم
العنوان
رقم حساب
متوسط كمية الطلب
السعر
عدد مخزون المنتجات

من قراءة سريعة للتسميات يمكننا معرفة أو توقع المدخلات في كل عمود وبالتالي يمكننا الاستعلام عن البيانات وتحليلها بسهولة لأن تدفق البيانات محدد جيدًا. أما بالنسبة للقواعد البيانات غير المهيكلة فإن البيانات بها لا تتناسب بدقة مع الأعمدة. فمثلًا يمكن أن يتضمن جدول بيانات غير مهيكلة ما يلي:

مقاطع فيديو
نشاط الجهاز المحمول
استخدام وسائل التواصل الاجتماعي
مستندات نصية
صور

هل هنالك طريقة لمعرفة ما هو مقطع الفيديو أو الأغنية الشائعة التي أدخلها المستخدم؟ غالبًا لا يمكننا معرفة أو توقع ذلك، ولهذا السبب لا يمكننا استخدام الأدوات التقليدية للاستعلام عنه لأن تغير البيانات ينتج عنه تغير طريقة التعامل معها، وعمومًا الجدول التالي سيمنحنا المعرفة مبدئية للفوارق بين طريقة طريقة الاستعلام في MySQL و MongoDB.

وهذه نظرة سريعة لبعض التعليمات في كل من نظام إدارة قواعد البيانات MySQL و MongoDB.

الاستعلام عن جميع الموظفين:

من خلال MySQL تكون التعليمة:

select * from Employee;‎

من خلال MongoDB تكون التعليمة:

db.Employee.find()‎

الاستعلام في بنية قواعد البيانات المعقدة:

من خلال MySQL تكون التعليمة:

SELECT E.* from Employee E inner join Dept D on E.EMPID=D.EMPID Where D.City=’Irving’

من خلال MongoDB تكون التعليمة:

db.Employee.find( { "Address.City" : "Irving" }).pretty()‎

ادخال مجموعة من البيانات:

من خلال MySQL تكون التعليمة:

Insert into Employee values (‘Brian Lockwood’,45, ‘A’),(‘Charles’,35,’A’)

من خلال MongoDB تكون التعليمة:

document = [ { "Name" : "Brian Lockwood","Age" : "45", status:"A"}, { "Name" : "Charles","Age" : "35", status:"A"}]

طريقة استخدام distinct لتصفية النتائج المكررة من استعلام معين:

من خلال MySQL تكون التعليمة:

Select distinct status from Employee;‎

من خلال MongoDB تكون التعليمة:

db.Employee.distinct( "status");‎

طريقة الاستعلام مشروط:

في MySQL تكون التعليمة:

Select * from Employee where Age>30

في MongoDB تكون التعليمة:

db.Employee.find ( { Age: {$gt : "30"} });‎

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

سهولة التعلم للمبتدئين

يعد نظام قواعد بيانات MySQL سهل نسبيًا وذلك بسبب أنه متسق ومنظم وهيكليته واضحة ولذلك من الطبيعي أن يكون تعلمه سهل وبسيط رغم طول منحنى تعلمه لكثرة المفاهيم فيه (وأحيانًا تعقيدها) بينما في المقابل نجد بأن البنية غير المهيكلة والمرونة العالية يمكن أن تجعل عملية التعلم أصعب نظرًا لكثرة التفاصيل والسيناريوهات رغم أن تعلم بدء استعمالها وتنفيذها سهل وسريع ويكون غالبًا مدمجًا مع اللغة البرمجية نفسها (أي تكتب الاستعلامات بلغة جافاسكربت بدلًا من لغة SQL) لما تخفي عن المستخدم التعقيد الداخلي.

أيهما أفضل MySQL vs MongoDB؟

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

متى نستخدم MySQL و MongoDB؟

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

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

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

يعد موقع Shutterfly مثلًا مميزًا لكيفية الانتقال إلى قواعد البيانات MongoDB، وهو واحدٌ من أشهر مواقع مشاركة للصور عبر الإنترنت، واعتمد في البداية على استخدام قواعد البيانات العلائقية المقدمة من شركة أوراكل لكن قواعد البيانات العلائقية غير مرنة لطبيعة عمل الموقع ومكلفة عند التوسع، كما تسببت في بعض الأحيان باختناقات خصيصًا عند التعامل مع عدد كبير من البيانات، لأن الشركة لديها أكثر من 6 مليارات صورة بالإضافة إلى معدل عمليات يصل إلى 10000 عملية في الثانية، وسرعان ما أدركت الشركة بأن الانتقال إلى قاعدة بيانات غير علائقية تعتمد على المستندات سيُساعدها على زيادة قابلية تطوير الموقع وتحسين أدائه وزيادة إنتاجية وقت البرمجة.

يتيح نموذج مستند MongoDB للمطورين تخزين البيانات بالطريقة التي هي عليها بدلًا من محاولة تحويلها لتناسب نوع قواعد بيانات معين، من خلال عملية Normalization وهي عملية تنظيم البيانات في قاعدة البيانات (لمزيد من المعلومات يمكنك الاطلاع على مقال فهم عملية التوحيد Normalization المستخدمة عند تصميم قاعدة البيانات)، قارنت الشركة بين العديد من أنظمة قواعد البيانات البديلة الأخرى مثل BerkeleyDB أو CouchDB أو Cassandra لتستقر في النهاية على MongoDB لإدارة وتخزين بيناتها وأكدت الشركة أنها مسرورة بقرارها الانتقال من Oracle إلى MongoDB واستطاعت توفير 20% من النفقات المتعلقة بقواعد البيانات بعد هذا الانتقال بحسب تصريح أحد مهندسيها.

إذا أردت الاطلاع على مقارنة شاملة وسريعة حول كل من MongoDB و MySQL، فيمكنك مشاهدة الفيديو الآتي:

الخاتمة

تعرفنا في هذا المقال على أهمية قواعد البيانات في الشركات وأخذنا نظرة سريعة إلى سرعة تطورها مع كثرة الاعتماد عليها وبعدها اطلعنا على نظامي إدارة قواعد البيانات MySQL و MongoDB وتعمقنا في فهم الاختلافات والتشابه بينهما من خلال الاطلاع على المجتمع والشعبية وقابلية التوسع ومن ثم فهمنا بين مخطط البيانات وتنوعها بين كِلا النظامين كما تعرفنا على تشابه سرعة وأداء النظامين ولنتعرف بعدها على طريقة حماية قواعد البيانات وإيفاء كل نظام بخصائص ACID ولندخل بعدها بالعمق أكثر من خلال معرفة كيفية كتابة الاستعلامات بينها ومن ثم سهولة تعلم المبتدئين لهذين النظامين وأجبنا بعدها على السؤال المكرر في الأوساط التقنية وهو أيهما أفضل MySQL vs MongoDB؟ كما اختتمنا المقال من خلال معرفة متى نستخدم كل منهما.

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