التصنيفات
Uncategorized

أساليب المصادقة الأكثر استخداماً في الـ API REST

هناك العديد من أساليب توثيق الاتصال وعمليات المصادقة ( authentication methods ) المستخدمة للحصول على صلاحيات او لتعريف هوية المستخدم عند التعامل مع الواجهات البرمجة ( REST APIs ) .
في هذا المقال سأحاول توضيح أكثر 3 طرق مصادقة استخداماً في عالم REST APIs و microservices world.

المصادقة مقابل الصلاحيات – Authentication vs Authorization

قبل ان نبداء دعونا نحاول التفريق بين المصادقة ( Authentication ) والصلاحيات الممنوحة للمستخدم بعد المصادقة ( Authorization )

بالعادة في الكثير من الانظمة يتم دمج الوظيفتين معاً بحيث انك مجرد ان عرفت عن نفسك ( Authentication ) تأخذ صلاحيات معينة للتعامل مع النظام ( Authorization ) لكن من الاسهل والافضل فصل الوظيفتين

المصادقة ( Authentication ) هي اثبات اوتعريف او تصريح عن شخصية او كيان ما .
وللتوضيح هذا يشبه الحصول على البطاقة الشخصية التي تثبت في الحقيقة انك شخص معين له اسم وينتمي لفئة الدولة او شركة او منظمة معينة .

الصلاحيات ( Authorization ) هو مفهوم مختلف تمامًا وبعبارة بسيطة ، يعبر عن مدى صلاحياتك للوصول والدخول لاماكن معينة او بيانات معينة في النظام .

ملخص:
المصادقة: يشير إلى إثبات الهوية الصحيحة
الصلاحيات: تشير إلى السماح بإجراء معين

الآن وبعد أن عرفنا ماهية المصادقة ، دعنا نرى ما هي طرق المصادقة الأكثر استخدامًا في واجهات برمجة تطبيقات REST APIs.

3 طرق المصادقة الأكثر استخداماً

1 – المصادقة عبر برتوكول HTTP

المصادقة عبر الـ HTTP لها عدة انواع سنتطرق لاثنين منها
١-
المصادقة الأساسية – Basic Authentication
٢-
مصادقة حامل الرمز – Bearer Authentication

المصادقة الأساسية – Basic Authentication

* لا يوصى باستخدام بروتوكول HTTP الأساسي للمصادقة نظرًا لوجود ثغرات أمنية فيه.

هذه هي الطريقة الأكثر سهولة ومباشرة. بهذه الطريقة ، يتم ارسال اسم مستخدم و كلمة المرور في الـ ( request header ).
ويتم تشفير اسم المستخدم وكلمة المرور باستخدام Base64 ، وهو أسلوب تشفير يحول اسم المستخدم وكلمة المرور إلى مجموعة من 64 حرفًا لضمان النقل الآمن.

لا تتطلب هذه الطريقة ملفات تعريف الارتباط ( cookies ) او جلسات ( session ) أو صفحات تسجيل الدخول وغيرها من الحلول المتخصصة ، لأنها تستخدم الـ HTTP header نفسه لارسال البيانات ، فليست هناك حاجة إلى المصافحة مع الخادم ( handshakes ) أو أنظمة الاستجابة المعقدة الأخرى.

مثال على ارسال البيانات عبر الـ HTTP header
Authorization: Basic bG9sOnNlY3VyZQ==

مصادقة حامل الرمز – Bearer Authentication

مصادقة حامل الرمز (تسمى أيضًا مصادقة token ) عبارة عن نظام مصادقة HTTP يتضمن رموز أمان تسمى الرموز المميزة ( security tokens ).
تدور الفكرة الرئيسية حول الحصول على رمز ( token ) يكون هذا الرمز هو اشبة ببطاقة او مفتاح للدخول او التعامل مع النظام.
يولد النظام الرمز ويرسله لك ويكون له فترة صلاحية محددة او مفتوحة يخول حامل الرمز لإرسال او استقبال المعلومات وللوصول لروابط او معلومات في النظام

يجب على العميل إرسال الرمز المميز عبر الـ HTTP header تقديم او ارسال اي طلب للسيرفر:


Authorization: Bearer <token>

على غرار المصادقة الأساسية ، يجب استخدام مصادقة Bearer فقط عبر اتصال مشفر وامن ( SSL )

2 – مفاتيح الواجهة البرمجية – API Keys

تم إنشاء اسلوب المصادقة عبر مفاتيح الواجهة البرمجية (API) كحل لإصلاح مشكلات المصادقة المبكرة لـ HTTP Basic Authentication وأنظمة أخرى مماثلة. في هذه الطريقة ، يتم تعيين قيمة فريدة تم إنشاؤها لكل مستخدم لأول مرة ، مما يدل على أن المستخدم معروف. عندما يحاول المستخدم إعادة الدخول للنظام ، يتم استخدام مفتاحه الفريد لإثبات أنه المستخدم نفسه .

احياناً يتم إرسال العديد من المفاتيح كجزء من الـ URL عند طلب الخدمة ، مما يجعل من السهل اكتشافها بالنسبة لشخص لا ينبغي أن يكون له حق الوصول إليها. لذلك يجب عدم تمرير المفاتيح عبر الرابط ( URL params ) لانها ببساطة قابلة للقراءة من طرف ثالث! الخيار الأفضل هو وضع مفتاح API في الـ ( Authorization header ). على النحو التالي :
Authorization: Apikey 1234567890abcdef.

هناك بالتأكيد بعض الحالات من الجيد فيها استخدام API Keys.
أولاً وقبل كل شيء لانها بسيطة وسهلة الاستخدام . ففي الحالات التي لا تعد فيها الحماية والامان معيار مهم جداً على سبيل المثال ، إذا كانت واجهة برمجة التطبيقات (API) لها وظيفة واحدة وهي القراءة “read” ، يمكن أن يكون مفتاح API حلاً مناسبًا. بشرط ان لا يكون هنالك امكانية التعديل أو الحذف .

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

الرجاء التفكير ملياً في امان النظام قبل استخدام هذه الطريقة

3.  برتوكول التفويض المفتوح ( OAuth 2.0 )

كانت الإصدارات السابقة من هذا البرتوكول ، OAuth 1.0 و 1.0a ، أكثر تعقيدًا من OAuth 2.0. ففي اخر نسخة من هذا البرتوكول تم اسقاط الكثير من المتطلبات منها ان كل طلب كان يحتاج لرقم مشفر ( keyed hash ) وتم استبدالها باحد الخيارات التالية :

  • رمز الوصول ( access token ): يتم إرساله بنفس طريقة مفتاح API ، وهو يتيح للتطبيق الوصول إلى بيانات المستخدم, يمكن اختيارياً تحديد مدة صلاحية معينة للمفتاح.
  • رمز الوصول محدث ( refresh token ): هو جزء اختياري في البرتوكول في حال تم تعيين مدة صلاحية للمفتاح وانتهت يتم انشاء هذا المفتاح .

يعد OAuth 2.0 هو الخيار الأفضل لتحديد هوية المتسخدمين ومنح الأذونات المناسبة لهم للتعامل مع النظام . في هذه الطريقة ، يقوم المستخدم بتسجيل الدخول إلى النظام. سيطلب ذلك النظام المصادقة ويعيد الطلب للمستخدم. ثم يقوم المستخدم بإعادة توجيه هذا الطلب إلى خادم مصادقة مستقل ( authorization server ) ، والذي يرفض هذا المصادقة أو يسمح به ، في حال السماح يتم ارسال رمز المصادقة ( access token ) لمقدم الخدمة فيصبح المستخدم الان مخول للدخول للنظام

يمثل المخطط التالي سير العملية

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

ملخص

في الوقت الحالي ، الفائز الواضح في الطرق الثلاث هو OAuth 2.0 ، وهناك بعض حالات الاستخدام التي قد تكون فيها مفاتيح واجهة برمجة التطبيقات ( Api Key’s ) أو أساليب مصادقة HTTP مناسبة حسب النظام ودرجة الامان المطلوبة .


التصنيفات
Uncategorized

MongoDB مقابل MySQL: دراسة مقارنة على قواعد البيانات


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

لنبداء اولا بتعريف كلا القاعدتين ونأخذ نظرة سريعة عنهما

اولاً الـ MongoDB
MongoDB هي واحدة من قواعد البيانات الأكثر شعبية من نوع قاعدة بيانات NoSQL. تم تطويرها من فكرة في عام 2007 وتم إصدار نسخته الأولى في عام 2010. تم تطويرها وصيانتها بواسطة شركة MongoDB.

تعتمد قاعدة البيانات هذه على نظام المفتاح-القيمة (key-value pairs ) لكل قيمة مفتاح اشبه بالمصفوفات الثنائية . يتم تخزين البيانات في وثائق في ملفات BSON والتي هي بالواقع نسخة معدلة قليلاً من ملفات JSON .

لهذا السبب ، يتم استخدامها بكثرة في المشاريع المبنية على Node.js. علاوة على ذلك ، من مميرات هذا النموذج ان الـ JSON تعمل على تسهيل تبادل البيانات بين تطبيقات الويب والخوادم بتنسيق قابل للقراءة من قبل الإنسان.

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

لا تعتمد MongoDB على بنية محددة كما في ال MySql لاجداول ولا بينة محددة مسبقا ولا نوع محدد من البيانات . يسمح هذا النموذج بتمثيل العلاقات الهرمية وتسهل القدرة على ادخال اي شكل من البيانات واي نوع دون قيود محددة مسبقاً.

بالإضافة إلى ذلك ، يسهل هذا النموذج عمليات مشاركة البيانات ونسخها ونقلها وتضمينها بقيود اقل بكثير من الـ MySql وشبيهاتها

ثانياً ما هو الـ MySql
MySQL هو نظام إدارة قواعد بيانات علائقية مفتوح المصدر RDBMS. تم بناؤه في الأصل بواسطة MySQL AB رغم أنه مملوك حاليًا لشركة Oracle.

يستخدم مفهوم تخزين البيانات في صفوف وجداول يتم تصنيفها في قاعدة البيانات. يستخدم لغة استعلام مهيكلة SQL للوصول إلى البيانات والأوامر ونقلها مثل “SELECT” و “UPDATE” و “INSERT” و “DELETE” لإدارتها.

يتم تخزين المعلومات ذات الصلة في جداول مختلفة ولكن مفهوم عمليات JOIN يبسط عملية ربطها وتنفيذ الاستعلامات عبر جداول متعددة وتقليل فرص تكرار البيانات.

مرونة البنية بين MongoDB و MySQL:

MongoDB : احد افضل الامور في ال MongoDB انك غير مقيد باي بنية ( schema design ) او شكل معين لادخال البيانات بامكانك بكل بساطة جمع مجموعة من الوثائق ( الوثيقة يقابلها الجدول في ال MySql ) في مجموعة لتشكل مخطط بيانات ( schema design ) معين حسب حاجة النظام.

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

MySQL: قبل أن تتمكن من تخزين أي شيء في MySQL ، تحتاج إلى تحديد الجداول والأعمدة بوضوح .

ولهذا السبب ، لا توجد مرونة كبيرة في طريقة تخزين البيانات إذا كنت تتبع التطبيع ( normalization ) . ايضا عمليات التعديل والتطوير تعتبر كابوس حقيقي لانك بحاجة لاعادة النظر في المخطط كل مرة ( schema design )

على سبيل المثال ، إذا كنت تدير نظام بنكي ، فيمكن إضافة معلوماته إلى الجدول المسمى “الحساب” على النحو التالي:

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

يقوم MongoDB بتخزين البيانات بطريقة كتابة JSON كما هو موضح أدناه:

يمكن تخزين هذه المستندات في مجموعة أيضًا.

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

لغة الاستعلام في MongoDB و MySQL

MongoDB: تستخدم لغة الاستعلام غير المهيكلة ( un-Structured Query Language ) . لإنشاء استعلام في مستندات JSON ، يلزمك تحديد مستند معين ثم تحدد خصائص ترغب في تطابق النتائج معها.

تسخدم الـ MongoDB جمل شبيهة نوعاً ما بالـ SQL للاستعلام والادخال والتعديل والحذف ولكن الاختلاف يكمن اولا انك يجب ان تحدد الوثيقة المطلوبة ( تكافيء الجدول في ال MySql لكن مع امكانية تكرارها لعدد غير محدود ) ايضا يجب تحدد المعلمة او القيمة التي يتم عبرها اختيار منطقة التعديل عبر ( set$ ) والتي تكافيء ( set ) في ال Mysql

MySQL: يستخدم SQL لغة الاستعلام الهيكلية (Structured Query Language SQL ) للتواصل مع قاعدة البيانات. على الرغم من بساطته ، إلا أنه في الواقع لغة قوية للغاية والتي تتألف بشكل رئيسي من جزأين: لغة تعريف البيانات DDL و لغة معالجة البيانات DML.

للتوضيح اكثر لنلقي نظرة على هذا الجدول الذي يقارن بين الاوامر في كلا القاعدتين

العلاقات في MongoDB و MySQL

MongoDB: لا يوجد في الـ MongoDB عملية دمج النتائج ( Join ) لكن يوجد شيء مكافيء لها عبارة عن عملية تجميع للبيانات ( aggregate ) من خلال الامر ( $lookup )

على سبيل المثال ، اذا كنت تريد قائمة بالأشخاص الذين لديهم حساب التوفير ، حيث يتم تضمين حقل “المعرف – ID” الخاص في ملفات ( وثائق ) متعددة من مجموعة “الحساب” مع ملف مجموعة “قائمة حساب التوفير”.  لأيجاد معلومات مجمعة من الملفين “قائمة حسابات التوفير” و “الحسابات” المرتبطة بها ، يجب عليه جلب مستند “حفظ قائمة الحساب” ثم استخدام المراجع المدمجة لقراءة مستندات متعددة من مجموعة الحسابات كالتالي.

MySQL: واحدة من أفضل الأجزاء في MySQL هي عمليات JOIN. فبجملة استعلام بسيطة ، يسمح JOIN للمستخدم بربط البيانات من جدولين أو أكثر في استعلام واحد بمساعدة الأمر “SELECT” المنفرد.

على سبيل المثال ، يمكننا بسهولة الحصول على البيانات ذات الصلة في جداول متعددة باستخدام عبارة SQL واحدة.


التشاركية في الـ MongoDB و MySQL

التشاركية ( Sharding ) هي طريقة توزيع البيانات على أجهزة متعددة لدعم العمليات على البيانات الكبيرة والاستعلامات الكثيرة.

احيانا من الممكن ان يكون حجم الاستعلامات والادخال ( I/O ) اكبر من قدرة الذاكرة العشوائية او قدرة المعالج في النظام . يتم حل هذه المشكلات عن طريق زيادة الكفائة الافقية والعامودية ( horizontal and vertical scaling ).

تعني زيادة الكفائة العامودية ( vertical scaling ). زيادة سعة نفس الخادم عن طريق إضافة المزيد من الذاكرة العشوائي ( ram ) أو وحدة المعالجة المركزية ( cpu )أو مساحة التخزين ( memory ) .
بينما تعني زيادة الكفائة الافقية ( horizontal scaling ). تقسيم قاعدة البيانات وتحميلها على خوادم إضافية متعددة. بحيث يتوزع الجهد على اجهزة متعددة

MongoDB: لديها القدرة على تقسيم البيانات إلى مجموعات والمجموعات إلى مجموعات فرعية من البيانات لتخزينها عبر اجهزة متعددة. هذا يعطي التطبيق القدرة على النمو والتوسع دور النظر إلى قيود الجهاز او الخادم الواحد.
أيضًا ، يمكنها معالجة توزيع البيانات عبر أي عدد من الخوادم لزيادة استخدام مساحة الذاكرة وعمل توزيع للاستعلامات تلقائي ( load balance queries ).

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

تعتبر Mongo جيدة جدًا في بعض المناطق التي تكون فيها قواعد البيانات العلائقية ( relational databases ) ضعيفة بشكل خاص ، المشاركة التلقائية ، والحفاظ على أوقات استجابة ثابتة حتى في ظروف استئنائية.

MySQL: التشاركية في الـ Mysql مختلفة نوعا ما ، تحتاج إلى توزيع قاعدة بيانات MySQL الخاصة بنا . وسوف نختار النسخ المتماثل ( replication ). من السهل علينا ان نعمل خادم تابع ( slave server ) ليقراء المعلومات ويستنسخها من السيد ( Master ) يمكن انشاء العديد من الخوادم التابعة لتقراء من السيد لكن ماذا عن الكتابة ؟!

على عكس MongoDB ، MySQL لا يوجد الية للتشاركية . يمكن حل هذه المشكلة حلول خاصة بك كما فعلت Facebook و Pinterest.

النسخ المتماثل Replication

mongodb vs mysql

MongoDB: تدعم النسخ المتماثل (  master-slave replication ). وتدعم عمليات متعددة للنسخ في ان واحد ولكن. سيتم تعيين دور أساسي أو ثانوي لكل عضو في مجموعة النسخ المتماثلة في أي نقطة من العملية.

بشكل افتراضي ، تتم القراءة / الكتابة على النسخة المتماثلة الأساسية ثم يتم نسخها نسخاً متماثلاً في النسخ الثانوية.

MySQL: تدعم كلاً من النسخ المتماثل بين السيد والتابع والنسخ بين السيد والسيد ( master-slave replication and master-master replication ). يوفر لك النسخ متعدد المصادر ( Multi-source replication ) القدرة على نسخ البيانات من العديد من من الخوادم السيد ( master server) بشكل متوازي ( parallel ).

MongoDB – MySQL: مقارنة الاداء والسرعة

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

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

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

لنأخذ مثالًا عامًا لفهم سرعة MySQL و MongoDB وفقًا للوظائف المختلفة.

تم إجراء القياسات في الحالات التالية:

  • MySQL 5.7.9
  • MongoDB 3.2.0

وتم إجراء الاختبار على نفس البيئة وجميع الاختبارات للحصول على 1000000 سجل.

اختبار أداء “SELECT” و “UPDATE” و “INSERT”

يتضح من الرسم البياني أعلاه أن MongoDB يأخذ وقتًا أقل من MySQL للأوامر نفسها. وهذا يجب أن يكون أجاب على سؤالك: ما مدى سرعة MongoDB مقارنة MySQL!

متى يجب استخدام MongoDB؟

إذا كانت هذه متطلباتك ، يجب أن تستخدم MongoDB:

  • عندما تحتاج إلى توفير حجم كبير للبيانات من خلال الاسترداد التلقائي والسريع والفوري للبيانات
  • في المستقبل ، إذا كانت قاعدة بيانتك ستتوزع وتحتاج لتوزيعها على عدة سيرفرات نظرًا لأن MongoDB لديه حل تشاركية مضمّن.
  • إذا كان لديك مخطط بينات قابل للتغيير المستمر ( unstable schema ) وتريد تقليل تكلفة اعادة هيلكة قاعدة البيانات لديك.
  • إذا كانت معظم خدماتك قائمة على الحوسبة السحابية ، فإن MongoDB هو الأنسب بالنسبة لك ، حيث أن الية التشاركية فيه تتماشى جيدًا مع انظمة التوسع التلقائي ( auto scaling ) الحوسبة السحابية.

MongoDB: إيجابيات وسلبيات

  • MongoDB : هو الأفضل عندما تريد هيكل مرن لقاعدة البيانات ( flexibil schema ). ايضا يمكنك بسهولة استخدام مجموعات النسخ المتماثلة مع MongoDB ويمكن الاستفادة من قابلية التوسع. خطط التوسع مرنة ويمكن تحقيقها بسهولة عن طريق إضافة المزيد من الآلات وذاكرة الوصول العشوائي إلى النظام. ويشمل أيضا التحقق من صحة الوثائق والأنظمة المتكاملة.
  • تتضمن سلبيات MongoDB استخدام حجم بيانات أعلى من ال MySql .

متى تستخدم MySQL؟

إذا كانت هذه متطلباتك ، يجب أن تستخدم MySQL:

  • إذا بدأت للتو ولم تكن قاعدة بياناتك كبيرة الحجم ، فستساعدك MySQL في إعداد سهل الصيانة ومنخفض الصيانة.
    إذا كنت قد حددت مخططًا ثابتًا لقاعدة البيانات ولن تتغير بنية البيانات على مدار الوقت.
  • إذا كان لديك معدل تنفيذ مرتفع للجمل على سبيل المثال لدى موقع BBC حوالي 30،000 جملة ادخال في دقيقة ، 4000 استعلام في ساعة)
    إذا كان أمان البيانات على رأس أولوياتك ، فإن MySQL هو أكثر أنظمة إدارة قواعد البيانات أمانًا.

MySql: إيجابيات وسلبيات

  • احد اهم الايجابيات المجتمع الضخم خلفها
  • الكثير من تطبيقات الطرف الثالث التي تقوم بعمليات المزامنة والنسخ التلقائي وغيرها
  • الامان العالي جداً

استنتاج نهائي
للإجابة على السؤال الرئيسي حول “لماذا يجب علي استخدام X على Y؟” تحتاج إلى أن تأخذ في الاعتبار أهداف مشروعك والعديد من الأشياء الأخرى ذات الصلة.

MySQL منظمة بشكل كبير بسبب مرونتها وأدائها العالي وحماية موثوقة للبيانات وسهولة إدارتها. يمكن أن تعمل فهرسة البيانات المناسبة لحل مشكلتك بالأداء وتسهيل التفاعل وضمان المتانة.

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

نتيجة – ليست بالضرورة بديلاً عن الآخر. تعمل MongoDB و MySQL في ظروف مختلفة وكل منها يشكل حل لمشكلة معينة.

التصنيفات
Uncategorized

InnoDB و MyISAM مقارنة السلبيات والايجابيات


يعتبر هذان المحركان ( InnoDB و MyISAM ) الاكثر استخداماً وشيوعاً في قواعد بيانات MySQL.
في هذه المقارنة سنلخص مجموعة من نقاط القوة والضعف لدى المحركين.

بدايةً دعونا نراجع امور مهمة حول المحركين وتاريخهما

  1. InnoDB احدث من ال MyISAM
  2. InnoDB اكثر تعقيداً من MyISAM
  3. InnoDB يحافظ على سلامة البيانات ( data integrity ) بحيث انه يتحقق من توافق البيانات ونوعها مع الحقل او العامود بينما يتساهل بذلك MyISAM
  4. InnoDB يقوم بعمل قفل على مستوى الصف ( row data locking ) عند ادخال البيانات منعاً للتضارب عند ادخال البيانات بينما يقوم MyISAM بقفل الجدول كاملاً (table data locking ) مما قد يؤخر التعديل والادخال في حالة كانت العمليات متعددة على الجدول.
  5. InnoDB يدعم عمليات الـ transactions والتي من خلالها يمكن تنفيذ سلسلة من الجمل وفي حال فشل احدها يمكن التراجع عن كل الاحداث بينما لا يدعم MyISAM ذلك.
  6. InnoDB يدعم الـ foreign keys والعلاقات بين الجداول بينما لا يدعم MyISAM ذلك
  7. InnoDB لديه امكانية افضل في استعادة البيانات في الحالات المفاجئة ( crash recovery ) بينما الالية اقل جودة وقدرة في ال MyISAM
  8. MyISAM يدعم عمليات البحث من نوع full-text بينما لا يدعم InnoDB ذلك

مع هذه الاختلافات الجوهرية لكل محرك منهما مجموعة من الإيجابيات والسلبيات ولكل منهما افضلية في بعض السيناريوهات والاستخدامات نستعرضها فيما يلي:

إيجابيات محرك InnoDB

  1. محرك InnoDB صارم جداً في صحة المدخلات وتوافقها مع نوع البيانات المعرفة في الجدول ولا يتساهل ابدا في ادخال نوع مختلف للبيانات ولا يقوم بأي عمليات تقريب او تحويل للبيانات لذلك هو مهم عندما تكون البيانات المدخلة دقيقة وحساسة
  2. المحرك اسرع في عمليات الادخال والتعديل لانه يعتمد على اقفال السطر المراد تعديله فقط ( row data locking ) بينما تتم باقي العمليات على الجدول دون اي مشاكل

سلبيات محرك InnoDB

  1. لان المحرك صارم في العلاقات بين الجداول وانواع البيانات المدخلة , لذلك يستهلك وقت اطول من مصممي قواعد البيانات ومدراء الانظمة لتنفيذ مخططات وانشاء قواعد البيانات
  2. يستهل موارد اكثر من النظام مثل الرامات والمعالجات
  3. لا يدعم ارشفة النص الكامل ( full-text indexing )

إيجابيات محرك MyISAM

  1. محرك بسيط لذلك هو اسهل بالتعامل خصوصاً بالانظمة الصغيرة والمبتدئين الذين لا يهتمون كثيراً بالعلاقات بين الجداول
  2. اسرع لانه يمتلك بنبية أبسط
  3. يدعم ارشفة النص الكامل ( full-text indexing )

سلبيات محرك MyISAM

  1. لا يدعم تكامل البيانات ( data integrity )
  2. لا يدعم تسلسل العمليات ( transactions )
  3. ابطاء في عمليات التعديل المتعدد بسبب الاعتماد على قفل الجدول (table data locking )

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