التصنيفات
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 بشكل أفضل مع التطبيقات التي لا تعتمد تمامًا على تكامل البيانات وغالباً الانظمة التي تعتمد على عرض البيانات اكثر من ادخالها.

التصنيفات
infrastructure optimization

Redis ام Memcached


Redis و Memcached كلاهما أنظمة مفتوحة المصدر عالية الأداء لإدارة الذاكرة المؤقتة . كلا النظامين يخزن معظم البيانات الموجودة في الذاكرة المؤقتة الـ Ram ويدير عدة عمليات عليها. لكن الفرق الجوهري بين النظامين تقريبا هو ان Redis يدعم بنى بيانات ( Data structure ) اكثر بكثير , بما في ذلك linked lists والـ hash tables وغيرها.
في هذه المقالة ، سنبحث الفرق بين Redis و Memcached. وبعض المعلومات عن ميزات النظامين

مقارنة الميزات

العمليات على السيرفر ( server side )
يدعم Redis عمليات التخزين وتمثيل البيانات في السيرفر ، ويمتلك عدد اكبر من بنى البيانات ( Data structure ) ويدعم عمليات أكثر من Memcached.
في Memcached ، اذا اردت اجراء بعض التعديلات على البيانات المخزنة مثل اعادة ترتيبها او ازالة التكرار او غيرها تحتاج إلى جلب البيانات من الذاكرة ثم تعديلها ( لربما عبر كود تكتبه في برنامجك او ارسالها لجهة العميل clinet side ) ثم تعييد ارجاع البيانات للسيرفر او الرام ان كنت تخزن البيانات على نفس السيرفر . والنتيجة هي أن هذا يزيد بشكل كبير من عدد العمليات والطلبات على السيرفر و الشبكة وأحجام البيانات. في Redis ، تكون هذه العمليات المعقدة اكثر كفائة وفعالية . لذلك ، إذا كنت بحاجة لدعم بنى بيانات وعمليات أكثر تعقيدًا ، فإن Redis يعد اختيارًا جيدًا.

مقارنة الكفاءة في استخدام الذاكرة
Memcached يعتبر ذو كفائة عاليه في تخزين البيانات على شكل ( key-value ) . بينما يتبنى Rides تمثيل البيانات على شكل ( hash structure ) ، لذلك معدل كفائة الذاكرة أعلى من Memcached بفضل ما يسمى بوضع ضغط البيانات ( combined compression mode )

مقارنة الأداء
يعتمد الـ Redis ال ( single threaded ) بعمليات الادخال والاخراج لذلك فهو يعتمد على نواة واحدة من المعالج ( singel core ) فقط بينما تستخدم Memcached ال ( multithreaded ) بالتالي ممكن ان تستخدم اكثر من نواة في المعالج ( multiple cores ) . لذلك في المتوسط ​​، تفتخر Redis بأداء أعلى من Memcached في تخزين البيانات الصغيرة عند قياسها من ناحية عدد الانوية المستخدمة في معالجة البيانات. بينما يتفوق Memcached Redis لتخزين البيانات من 100K أو أعلى. على الرغم من قيام Redis بإجراء بعض التحسينات لتخزين البيانات الكبيرة ، إلا أنها لا تزال أدنى من Memcached.

دعونا الآن نناقش بعض النقاط لدعم المقارنات المذكورة أعلاه.

أنواع البيانات المختلفة المدعومة

بخلاف Memcached الذي يدعم فقط البيانات ذات بالبنية الأساسية البسيطة ( key-value structure )، يدعم Redis أنواع البيانات أكثر ثراءً وتعقدياً، بما في ذلك String و Hash و List و Set و Set Sorted Set.
بشكل عام يستخدم Redis الـ redisObject لتمثيل كافة المفاتيح والقيم. المعلومات الأساسية لـ redisObject هي كما هو موضح أدناه:

 يمثل المخطط السابق البيانات في ال ( value object ).
يمثل ( encoding ) طريقة التخزين لأنواع البيانات المختلفة في Redis ، مثل type = string يمثل أن القيمة تخزن نص ،
او مثلا int. إذا كان int ، وغيرها
الآن دعونا نناقش بعض أنواع البيانات.

النصوص strings

تستخدم الاوامر التالية: set/get/decr/incr/mget .

تستخدم عادةً : للنصوص ( strings ) فهي نوع البيانات الأكثر شيوعًا بالعادة تخزن على شكل key/value .

Hash

تستخدم الاوامر التالية: hget/hset/hgetall وغيرها.

تستخدم عادةً : لتخزين معلومات المستخدم ، بما في ذلك رقم المستخدم واسم المستخدم والعمر وتاريخ الميلاد ؛ ويتم إستعادة اسم المستخدم أو العمر أو عيد الميلاد من خلال معرف المستخدم ID.

السلاسل List

تستخدم الاوامر التالية: lpush/rpush/lpop/rpop/lrange.

تستخدم عادةً : السلاسل ( List ) هي أهم بنية بيانات في Redis. في الواقع ، من الممكن تطبيق قائمة Twitter وقائمة المعجبين باستخدام السلاسل ( List ) في الـ Redis.

Set

تستخدم الاوامر التالية: sadd/spop/smembers/sunion وغيرها.

تستخدم عادةً : الـ Set في الـ Redis مماثلة للـ List . إلا انها يمكنها إزالة التكرارات تلقائيًا. عندما تحتاج إلى تخزين قائمة بيانات دون أي تكرار ، فإن الـ Set تعد خيارًا جيدًا. بالإضافة إلى ذلك ، توفر المجموعة واجهة  اوامر للاستعلام على ما إذا كان العضو ضمن مجموعة ، وهي ميزة لا توفرها ال List.

Sorted Set

تستخدم الاوامر التالية: zadd/zrange/zrem/zcard وغيرها.

تستخدم عادةً : هنالك تشابه كبير بينها وبين ال Set. الفرق هو أنه أن الـ Set لا تقوم تلقائيًا بترتيب البيانات ، فإن الـ Sorted Set يمكنها فرز البيانات من خلال قيمة مرجعية معينة يقدمها المستخدم . والأكثر من ذلك ، أن هذا الأخير تفرز البيانات التي يتم إدخالها تلقائيًا. يمكنك اختيار بنية الـ sorted set عندما تحتاج إلى قائمة منظمة بدون بيانات مكررة ، مثل الـ Time line لتويتر ، والذي يمكن ان يكون وقت النشر كـ ( قيمة مرجعية ) مع الفرز التلقائي للبيانات التي يتم الحصول عليها حسب الوقت.

 الاختلاف في ادارة الذاكرة

في Redis ، لا يتم تخزين البيانات في الذاكرة المؤقتة الـ Ram بل من الممكن ان يقوم Redis بنقل بعض البيانات إلى القرص الصلب ال Hard Disk. وهذا فرق كبير بين Redis و Memcached. فعند امتلاء الذاكرة المؤقتة الـ Ram ، قد يقوم Redis بنقل القيم غير المستخدمة لفترة طويلة إلى القرص الصلب. يقوم Redis بتخزين جميع المفاتيح ( key’s ). إذا اكتشف أن استخدام الذاكرة يتجاوز قيمة معينة ( عادة تكون معرفة مسبقاً ) ، فسيؤدي ذلك إلى تشغيل عملية النقل الـ Swap. يقوم Redis بحساب قيم المفاتيح التي سيتم نقلها إلى القرص استنادًا إلى المعادلة التالية
“قابلية التبديل = عمر البيانات * لوغ ( الحجم في الذاكرة )”.
ثم يقوم بنقل هذه القيم للقرص الصلب الـ Hard Disk ويقوم بمحوها من الذاكرة المؤقته الـ Ram. تتيح هذه الميزة لـ Redis الحفاظ على بيانات بحجم أكبر من سعة ذاكرة الجهاز.

في الوقت نفسه ، عندما يقوم Redis بتبديل البيانات الموجودة في الذاكرة المؤقتة الـ Ram إلى القرص الصلب الـ Hard Disk ، تقوم Thread بتوفير خدمات الاستعلام والادخال ،  ويقوم thread فرعي بعملية نقل البيانات وكلاهما يعملان على نفس المنطقة من الذاكرة. إذا قمت بتحديث البيانات التي تجري عليها عملية النقل ، فسوف يقوم Redis بتجميد كل عمليات التحديق هذه العملية لحين انتهاء عملية النقل ، مما يحول دون تنفيذ هذا التغيير حتى تكمل الthread عملية المبادلة. عندما تقرأ بيانات من Redis ، إذا كانت قيمة مفتاح القراءة غير موجودة في الذاكرة ، فإن Redis يحتاج إلى تحميل البيانات من القرص الصلب ثم يعيدها إليك ،هنا تحدث مشكلة I/O . بشكل افتراضي ، سيواجه Redis الازدحام ، أي أنه لن يستجيب إلا بعد التحميل الناجح لجميع ملفات النقل من القرص الصلب .
هذه الطريقة مناسبة للعمليات عندما يكون هناك عدد صغير من العملاء. ولكن إذا قمت بتطبيق Redis في موقع كبير بعمليات قراءة وكتابة كثير ، فلن يكون قادرًا على تلبية المتطلبات بكفائة. يوجد بعض التوصيات لحل هذه المشكلة ولكن ان اذكرها هنا.

دعم استمرارية البيانات
( data persistence )

على الرغم من ان Redis يتعامل مع الذاكرة المؤقتة الـ Ram ، إلا أن Redis يدعم استمرارية بيانات الذاكرة ( memory data persistence ) حيث تستطيع استعادة البيانات في حال حصلت مشكلة او قطع في الطاقة عبر اليتين هما ( RDB snapshot و AOF log ) بينما لم يقدم Memcached اي يدعم عمليات استمرار البيانات الا في النسخة الاخيرة التي تحمل الرقم 1.5.18 عبر الية DAX filesystem mounts.

لقطة RDB


يدعم Redis تخزين لقطة ( snapshot ) عن البيانات الحالية في ملف بيانات للاستعادة في الحالات الطارئة . ولكن كيف يمكننا إنشاء لقطة لقاعدة البيانات الحالية مع عمليات كتابة البيانات المستمرة؟ يقوم Redis عند إنشاء لقطة بالكتابة من خلال انشاء عملية كتابة فرعية . تقوم العملية الحالية بتكوين عملية فرعية تخزن كل البيانات بشكل دوري وتكتبها في ملف RDB. يمكننا تهيئة توقيت إنشاء لقطة RDB من خلال أمر الحفظ لـ Redis. على سبيل المثال ، إذا كنت ترغب في تكوين إنشاء لقطة لمرة واحدة كل 10 دقائق ، يمكنك تكوين إنشاء لقطة بعد كل 1000 عملية كتابة. يمكنك أيضًا تكوين قواعد متعددة للتنفيذ معًا. توجد تعريفات لهذه القواعد في ملفات تهيئة Redis. يمكنك أيضًا تعيين القواعد باستخدام الأمر CONFIG SET من Redis أثناء وقت تشغيل Redis دون إعادة تشغيل Redis.

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

سجل AOF

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

بالنهاية بالنسبة ل Redis
لمتطلبات العمل العامة ، أقترح عليك استخدام RDB لأن RDB اخف على النظام من سجلات AOF. اما ان كانت بياناتك حساسة ولا تحتمل مخاطرة فقد أي للبيانات ، أوصيك باستخدام سجلات AOF.

الخلاصة

استعرضنا في هذه المقالة بعض جوانب القوة لدى النظامين ارجوا تنتبه عزيزي القاريء انني لم اغطي كل الجوانب لدى النظامين لذلك لا تعتبر هذه المقالة تفضيل ل Redis على ال Memcached لكن هذا رأي شخصي بالنهاية وما يحسم الافضلية هو استخدامك للنظام وحجم بياناتك

المراجع

التصنيفات
GIT productivity and teamwork

أنشاء الفروع في الـ GIT ودمجها

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

في أنظمة التحكم في الإصدارات القديمة (مثل CVS) ، بسبب صعوبة العملية أقتصرت عمليات الدمج على المستخدمين الخبراء.
حتى في أنظمة التحكم في الحديثة نسبياُ مقل Subversion ، يجب رفع ال ( commits ) إلى مستودع مركزي ،
لذلك فإن الفروع والدمج يعتبر مميز وسهل في الـ GIT.

العمل المتفرّع ( branching workflow ) هو امر شائع الاستخدام في Git وهو عبارة عن إنشاء فرع جديد لكل ميزة جديدة أو لإصلاح خلل أو التحسين.
كل فرع يتم رفع كل التعديلات والاكواد الجديدة الخاصة بميزة معينة او اصلاح معين وبمجرد اكتمال الميزة الجديدة تكون جاهزة للدمج مرة أخرى في الفرع الرئيسي ( master branch ) .
كما يمكن رفع كل فرع على حدة لمستودع البرمجيات .

يتم استخدام الأمر git branch لإستعراض جميع الفروع الموجودة . ستظهر علامة النجمة بجوار الفرع النشط حاليًا.

لإنشاء فرع جديد ، يمكننا استخدام الامر التالي  git branch new-branch. سيؤدي هذا إلى إنشاء فرع جديد وينسخ كل شي موجود على الفرع النشط حاليًا.

في هذه المرحلة ، أنشأنا فرعًا جديدًا ، ولكننا لا نزال موجودين في الفرع الرئيسي ( master branch ) .
لبدء العمل في الفرع الجديد ، نحتاج أولاً إلى تشغيل الأمر
git checkout new-branch. سيؤدي ذلك إلى تغيير الفرع النشط إلى الفرع الجديد.

في هذه المرحلة ، سيتم إضافة الايداعات ( commits ) للفرع الجديد . بمجرد اكتمال التعديلات و الانتهاء من العمل المطلوب ، يمكن دمج الايداعات ( commits ) للفرع الرمز الرئيسي ( master ).

أولاً نتحول للفرع الرئيسي ( master ) من خلال تنفيذ الامر التالي git checkout master. ثم نقوم بتشغيل الأمر
git merge new-branch لدمج الميزة الجديدة في الفرع الرئيسي. لاحظ أن git merge تدمج الفرع المحدد في الفرع النشط حاليًا. لذلك نحن بحاجة إلى أن نكون على الفرع الذي ندمج فيه.

إذا سارت الامور بشكل جيد نكون قد انهينا العمل. تظهر التغييرات والايداعات ( commits ) التي قمنا بها في الفرع new_branch في الفرع master . ومع ذلك ، من المحتمل ألا يتمكن Git من إكمال الدمج بسبب تغيير التعارض في فرع المصدر. هذا يسمى تعارض دمج و ربما سأفرد له مقاله منفصله .

للتلخيص ، فيما يلي الأوامر لإنشاء فرع جديد ، وإجراء بعض الايداعات ( commits ) ، وإعادة دمجها في الفرع الرئيسي:

التصنيفات
servers and security Terminal

البحث عن النصوص باستخدام Terminal على Mac


لتحديد مكان نص داخل ملف او مجلد ، استخدم أداة grep.

تقوم أداة grep بالبحث في الملفات عن السطور التي تحتوي على مطابقة للنص المطلوب .
افتراضيًا ، يطبع grep النصوص المطابقة ومسار الملف في النظام.

للبحث داخل ملف واحد استخدم الامر التالي

grep text fileـname

استبدل text بالنص الذي تريد البحث عنه واستبدل file_name باسم الملف الذي تريد البحث فيه.

للبحث داخل مجلد والمجلدات التي بداخله استخدم الامر التالي

grep -r "text" "folder_name"

استبدل text بالنص الذي تريد البحث عنه واستبدل folder_name باسم المجلد الذي تريد البحث فيه.

التصنيفات
servers and security

ssh-copy-id إضافة مفتاح الاتصال لسيرفرك

إعداد مصادقة المفتاح العمومي

 في ال SSH  هنالك مفتاحان الاول public و private. (المفتاح العمومي والمفتاح الخاص)
الغرض من ssh-copy-id هو جعل إعداد مصادقة المفتاح العام أسهل. هذه العملية هي على النحو التالي.

إنشاء مفتاح SSH

باستخدام OpenSSH ، يتم إنشاء مفتاح SSH باستخدام
ssh-keygen. في أبسط شكل ، فقط قم بتشغيل ssh-keygen والإجابة على الأسئلة. المثال التالي يوضح هذا.

يستغرق إنشاء زوج مفاتيح (المفتاح العمومي والمفتاح الخاص) دقيقة واحدة فقط. عادة ما يتم تخزين الملفات الرئيسية في المجلد ~/.ssh

نسخ المفتاح للسيرفر

بمجرد إنشاء مفتاح SSH ، يمكن استخدام الأمر ssh-copy-id لتثبيته كمفتاح معتمد على السيرفر. بمجرد أن يتم اعتماد المفتاح لـ SSH ، فإنه يمنح الوصول إلى السيرفر دون كلمة مرور.

استخدم الأمر التالي لنسخ مفتاح SSH:

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

يتم نسخ المفتاح العمومي فقط إلى السيرفر. لا ينبغي أبدا نسخ المفتاح الخاص إلى جهاز آخر.

اختبار المفتاح الجديد

بمجرد نسخ المفتاح ، من الأفضل اختباره:

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