البحث في الموقع

يشرح هذا الفيديو كيفية نشر تطبيق React.js مع واجهة خلفية Node.js تتعامل مع قواعد MongoDB على منصة Heroku، وسيغطي المواضيع التالية: مستلزمات نشر التطبي على منصة Heroku كيفية ربط خادم Node.js بتطبيق React إنشاء قواعد بيانات في MongoDB Atlas كيفية الحصول على رابط قواعد البيانات في MongoDB Atlas إنشاء تطبيق جديد على منصة Heroku نشر التطبيق من مستودع GitHub إضافة متغيرات البيئة إلى منصة Heroku تجد شرحًا كاملًا عن Node.js ومكتبة React في دورة تطوير التطبيقات باستخدام لغة JavaScript والتي ستتعلم فيها بناء تطبيقات ومشاريع عملية، وسيكون هذا الدرس عونًا لك في نشر تلك التطبيقات على أشهر منصة نشر. نرجو لك التوفيق بنشر تطبيقات مفيدة!

منذ زمن سحيق، كانت الذاكرةُ أكثر وظيفة نحتاجها ونعتمد عليها في الحاسوب. ورغم اختلاف التقنيات وأساليب التنفيذ الكامنة وراءها، إلّا أنّ معظم الحواسيب تأتي بالعتاد الضروريّ لمعالجة المعلومات وحفظها بأمان لاستخدامها في المستقبل متى احتجنا لها. لقد صار من المستحيل في عالمنا الحديث تخيل أيّ عمل لا يستفيد من هذه القدرة في الأجهزة، سواء كانت خواديم أو حواسيب شخصية أو كفّيّة. تُعالَج البيانات وتُسجَّل وتُسترجَع مع كل عملية، وفي كل مكان من الألعاب إلى الأدوات المتعلقة بالأعمال، بما فيها المواقع. أنظمة إدارة قواعد البيانات (DataBase Management Systems – DBMS) هي برمجيات عالية المستوى تعمل مع واجهات برمجة تطبيقات (APIs) أدنى منها في المستوى، وتلك الواجهات بدورها تهتم بهذه العمليات. لقد تم تطوير العديد من أنظمة إدارة قواعد البيانات (كقواعد البيانات العلائقيّة relational databases، وnoSQL، وغيرها) لعقود من الزمن للمساعدة على حلّ المشكلات المختلفة، إضافة إلى برامج لها (مثل MySQL ,PostgreSQL ,MongoDB ,Redis، إلخ). سنقوم في هذا المقال بالمرور على أساسيّات قواعد البيانات وأنظمة إدارة قواعد البيانات. وسنتعرف من خلالها على المنطق الذي تعمل به قواعد البيانات المختلفة، وكيفية التفرقة بينها. أنظمة إدارة قواعد البياناتإن مفهوم نظام إدارة قاعدة البيانات مظلّةٌ تندرج تحتها كلّ الأدوات المختلفة أنواعها (كبرامج الحاسوب والمكتبات المضمّنة)، والتي غالبًا تعمل بطرق مختلفة وفريدة جدًّا. تتعامل هذه التطبيقات مع مجموعات من المعلومات، أو تساعد بكثرة في التعامل معها. وحيث أن المعلومات (أو البيانات) يُمكِن إن تأتي بأشكال وأحجام مختلفة، فقد تم تطوير العشرات من أنظمة قواعد البيانات، ومعها أعداد هائلة من تطبيقات قواعد البيانات منذ بداية النصف الثاني من القرن الحادي والعشرين، وذلك من أجل تلبية الاحتياجات الحوسبيّة والبرمجية المختلفة. تُبنى أنظمة إدارة قواعد البيانات على نماذج لقواعد البيانات: وهي بُنى محدّدة للتعامل مع البيانات. وكل تطبيق ونظام إدارة محتوى جديد أنشئ لتطبيق أساليبها يعمل بطريقة مختلفة فيما يتعلق بالتعريفات وعمليات التخزين والاسترجاع للمعلومات المُعطاة. ورغم أنّ هناك عددًا كبيرًا من الحلول التي تُنشئ أنظمة إدارة قواعد بيانات مختلفة، إلّا أنّ كلّ مدة زمنية تضمّنت خيارات محدودة صارت شائعة جدًّا وبقيت قيد الاستخدام لمدة أطول، والغالب أنّ أكثرها هيمنة على هذه الساحة خلال العقدين الأخيرين (وربما أكثر من ذلك) هي أنظمة إدارة قواعد البيانات العلائقيّة (Relational Database Management Systems – RDBMS). أنواع قواعد البياناتيستخدم كلُّ نظام إدارة بياناتٍ نموذجًا لقواعد البيانات لترتيب البيانات التي يديرها منطقيًّا. هذه النماذج (أو الأنواع) هي الخطوة الأولى والمحدّد الأهم لكيفية عمل تطبيق قواعد البيانات وكيفية تعامله مع المعلومات وتصرفه بها. هناك بعض الأنواع المختلفة لنماذج لقواعد البيانات التي تعرض بوضوع ودقّة معنى هيكلة البيانات، والغالب أن أكثر هذه الأنواع شهرةً قواعدُ البيانات العلائقيّة. ورغم أنّ النموذج العلائقيّ وقواعد البيانات العلائقيّة (relational databases) مرنة وقويّة للغاية –عندما يعلم المبرمج كيف يستخدمها–، إلّا أنّ هناك بعض المشكلات التي واجهات عديدين، وبعض المزايا التي لم تقدمها هذه الحلول. لقد بدأت حديثًا مجموعة من التطبيقات والأنظمة المختلفة المدعوّة بقواعد بيانات NoSQL بالاشتهار بسرعة كبيرة، والتي قدمت وعودًا لحل هذه المشكلات وتقديم بعض الوظائف المثيرة للاهتمام بشدّة. بالتخلص من البيانات المهيكلة بطريقة متصلّبة (بإبقاء النمط المعرّف في النموذج العلائقيّ (relational model))، تعمل هذه الأنظمة بتقديم طريقة حرّة أكثر في التعامل مع المعلومات، وبهذا توفّر سهولة ومرونة عاليتين جدًّا؛ رغم أنّها تأتي بمشاكل خاصة بها –والتي تكون بعضها جدّيّة– فيما يتعلق بطبيعة البيانات الهامّة والتي لا غنى عنها. النموذج العلائقيّيقدّم النظام العلائقيّ الذي ظهر في تسعينات القرن الماضي طريقة مناسبة للرياضيات في هيكلة وحفظ واستخدام البيانات. توسّع هذه الطريقة من التصاميم القديمة، كالنموذج المسطّح (flat)، والشبكيّ، وغيرها، وذلك بتقديمها مفهوم "العلاقات". تقدّم العلاقات فوائد تتعلق بتجميع البيانات كمجموعات مقيّدة، تربط فيها جداول البيانات –المحتوية على معلومات بطريقة منظمة (كاسم شخص وعنوانه مثلاً)– كل المدخلات بإعطاء قيم للصفات (كرقم هوية الشخص مثلًا). وبفضل عقود من البحث والتطوير، تعمل أنظمة قواعد البيانات التي تستخدم النموذج العلائقيّ بكفاءة وموثوقيّة عاليتين جدًّا. أضف إلى ذلك الخبرة الطويلة للمبرمجين ومديري قواعد البيانات في التعامل مع هذه الأدوات؛ لقد أدّى هذا إلى أن يصبح استخدام تطبيقات قواعد البيانات العلائقيّة الخيار الأمثل للتطبيقات ذات المهام الحرجة، والتي لا يمكنها احتمال فقدان أيّة بيانات تحت أيّ ظرف، وخاصة كنتيجة لخلل ما أو لطبيعة التطبيق نفسه الذي قد يكون أكثر عرضة للأخطاء. ورغم طبيعتها الصارمة المتعلقة بتشكيل والتعامل مع البيانات، يمكن لقواعد البيانات العلائقيّة أن تكون مرنة للغاية وأن تقدم الكثير، وذلك بتقديم قدر ضئيل من المجهود. التوجّه عديم النموذج (Model-less) أو NoSQLتعتمد طريقة NoSQL في هيكلة البيانات على التخلص من هذه القيود، حيث تحرر أساليب حفظ، واستعلام، واستخدام المعلومات. تسعى قواعد بيانات NoSQL إلى التخلص من العلائقات المعقدة، وتقدم أنواع عديدة من الطرق للحفاظ على البيانات والعمل عليها لحالات استخدام معينة بكفاءة (كتخزين مستندات كاملة النصوص)، وذلك من خلال استخدامها توجّها غير منظم (أو الهيكلة على الطريق / أثناء العمل). أنظمة إدارة قواعد بيانات شائعةهدفنا في هذا المقال هو أن نقدم لك نماذج عن بعض أشهر حلول قواعد البيانات وأكثرها استخدامًا. ورغم صعوبة الوصول إلى نتيجة بخصوص نسبة الاستخدام، يمكننا بوضوح افتراض أنّه بالنسبة لغالب الناس، تقع الاختيارات بين محرّكات قواعد البيانات العلائقيّة، أو محرك NoSQL أحدث. لكن قبل البدء بشرح الفروقات بين التطبيقات المختلفة لكل منهما، دعنا نرى ما يجري خلف الستار. أنظمة إدارة قواعد البيانات العلائقيّةلقد حصلت أنظمة إدارة قواعد البيانات العلائقيّة على اسمها من النموذج الذي تعتمد عليه، وهو النموذج العلائقيّ الذي ناقشناه أعلاه. إنّ هذه الأنظمة –الآن، وستبقى لمدة من الزمن في المستقبل– الخيار المفضّل للحفاظ على البيانات موثوقة وآمنة؛ وهي كذلك كفؤة. تتطلب أنظمة إدارة قواعد البيانات العلائقيّة مخططات معرفة ومحددة جيدًا –ولا يجب أن يختلط الأمر مع تعريف PostgreSQL الخاص بهذه الأنظمة– لقبول هذه البيانات. تشكّل هذه الهيئات التي يحددها المستخدم كيفية حفظ واستخدام البيانات. إنّ هذه المخططات شبيهة جدًّا بالجداول، وفيها أعمدة تمثّل عدد ونوع المعلومات التي تنتمي لكل سجل، والصفوف التي تمثّل المدخلات. من أنظمة إدارة قواعد البيانات الشائعة نذكر: SQLite: نظام إدارة قواعد بيانات علائقيّة مضمّن قويّ جدًّا.MySQL: نظام إدارة قواعد بيانات علائقيّة الأكثر شهرة والشائع استخدامه.PostgreSQL: أكثر نظام إدارة قواعد بيانات علائقيّة كيانيّ (objective-RDBMS) متقدم وهو متوافق مع SQL ومفتوح المصدر.ملاحظة: لمعرفة المزيد عن أنظمة إدارة قواعد بيانات NoSQL، راجع المقالة التالية عن الموضوع: A Comparison Of NoSQL Database Management Systems. أنظمة قواعد بيانات NoSQL (أو NewSQL)لا تأتي أنظمة قواعد بيانات NoSQL بنموذج كالمستخدم في (أو الذي تحتاجه) الحلول العلائقيّة المهيكلة. هناك العديد من التطبيقات، وكلّ منها تعمل بطريقة مختلفة كليًّا، وتخدم احتياجات محدّدة. هذه الحلول عديمة المخططات (schema-less) إمّا تسمح تشكيلات غير محدودة للمدخلات، أو –على العكس– بسيطة جدًّا ولكنها كفؤة للغاية كمخازن قيم معتمد على المفاتيح (key based value stores) مفيدة. على خلاف قواعد البيانات العلائقيّة التقليديّة، يمكن تجميع مجموعات من البينات معًا باستخدام قواعد بيانات NoSQL، كـ MongoDB مثلًا. تُبقي مخازن المستندات هذه كل قطعة من البيانات مع بعضها كمجموعة واحدة (أي كملف) في قاعدة البيانات. يمكن تمثيل هذه المستندات ككيانات بيانات منفردة، مثلها في ذلك كمثل JSON، ومع ذلك تبقى كراسات، وذلك يعتمد على خصائصها. ليس لقواعد بيانات NoSQL طريقة موحدة للاستعلام عن البيانات (مثل SQL لقواعد البيانات العلائقيّة) ويقدم كلّ من الحلول طريقته الخاصّة للاستعلام. ملاحظة: لمعرفة المزيد عن أنظمة إدارة قواعد البيانات العلائقيّة، ألق نظرة على هذه المقالة المتعلقة بالموضوع: A Comparison Of Relational Database Management Systems. مقارنة بين أنظمة إدارة قواعد بيانات SQL و NoSQLمن أجل الوصول إلى نتيجة بسيطة ومفهومة، لنحلّل أولًا الاختلافات بين أنظمة إدارة قواعد البيانات: هيكلية ونوع البيانات المحتفظ بها:تتطلب قواعد البيانات العلائقيّة SQL هيكلة ذات خصائص محدّدة للحفاظ على البيانات، على خلاف قواعد بيانات NoSQL التي تسمح بعمليات انسياب حُرّ (free-flow operations). الاستعلام: وبغضّ النظر عن تراخيصها، تستخدم كلّ قواعد البيانات العلائقيّة معيار SQL إلى حدّ ما، ولهذا يمكن الاستعلام فيها بلغة SQL (أي Structured Query Language). أما قواعد بيانات NoSQL فلا تستخدم طريقة محدّدة للعمل على البيانات التي تديرها. التحجيم: يمكن تحجيم كلي الحلين عموديًّا (أي بزيادة موارد النظام). لكن لكون حلول NoSQL تطبيقات أحدث (وأبسط)، فهذا يجعلها تقدّم وسائل أسهل بكثير لتحجيمها أفقيًّا (أي بإنشاء شبكة عنقودية cluster من أجهزة متعدّدة). المتانة Reliability: عندما يتعلق الأمر بالمتانة والثقة الآمنة بالقَيد المنفّذ، تبقى قواعد بيانات SQL الخيار الأفضل. الدعم: لأنظمة إدارة قواعد البيانات العلائقيّة تاريخ طويل استمر لعقود من الزمن. إنها شائعة جدًّا، ومن السهل إيجاد دعم سواء مجانيّ أو مدفوع. إذا حدثت مشكلة، فمن الأسهل حلّها عليها من قواعد بيانات NoSQL التي شاعت حديثًا، وخاصة إذا كان الحلّ موضع السؤال ذا طبيعة معقّدة (مثل MongoDB). احتياجات حفظ واستعلام البيانات المعقدة: إنّ قواعد البيانات العلائقيّة بطبيعتها الخيار الأمثل لاحتياجات حفظ البيانات والاستعلامات المعقّدة. إنها أكثر كفاءة وتتفوق في هذا المجال. ترجمة -وبتصرّف- للمقال Understanding SQL And NoSQL Databases And Different Database Models لصاحبه O.S. Tezer.

يختار كثيرون من مطوري الويب الحديث اليوم استخدام قواعد بيانات NoSQL في مشاريعهم، وعادة ما تكون MongoDB اختيارهم الأول. إنّ إنشاء نسخ احتياطية بشكل دوري أمر مهم إن كنت تستخدم قواعد MongoDB في مشاريع في طور التشغيل وذلك بغرض الحفاظ على البيانات من التلف، ولحسن الحظ، توفّر MongoDB أمرًا بسيطًا ضمن أدواتها لإنشاء واستعادة النسخ الاحتياطية. لفهم كيفية عمل النسخ الاحتياطية دون المساس بقواعد بيانات عملك الخاص، سنبدأ المقال بإنشاء قاعدة بيانات جديدة وإضافة قدر بسيط من البيانات إليها، بعد ذلك سنقوم بإنشاء نسخة احتياطية لهذه القاعدة، ومن ثم حذفها واستعادتها من النسخة الاحتياطية التي قمنا بإنشائها. المتطلبات نظام تشغيل Ubuntu 14.04، مستخدم عادي بدون صلاحيات مدير نظام، لكنّه يملك صلاحية تنفيذ أمر sudo. يمكن مراجعة مقال الإعداد الابتدائي لخادوم أوبنتو 14.04 لمزيد من المعلومات، تثبيت وإعداد MongoDB. الخطوة الأولى: إنشاء قاعدة بيانات تجريبية إنّ إنشاء نسخة احتياطية لقاعدة بيانات فارغة ليس أمرًا مفيدًا، لذا سنقوم في هذه الخطوة بإنشاء قاعدة بيانات تجريبية وإضافة بعض البيانات لها. إنّ أسهل طريقة للتعامل مع MongoDB هي عبر سطر أوامرها الذي يمكن فتحه بتنفيذ الأمر mongo في سطر الأوامر العادي. > mongo بعد ذلك سنقوم بإنشاء قاعدة بيانات جديدة سندعوها myDatabase وذلك باستخدام الأمر المساعد use: $ use myDatabasee سنحصل على الخرج التالي نتيجة لتنفيذ الأمر: switched to db myDatabase ينبغي على جميع البيانات في قاعدة MongoDB أن تتبع لمجموعة collection. وبالرغم من ذلك، فليس هناك حاجة لإنشاء مجموعة بشكل خاص، فعند استخدام التابع insert لإدخال بيانات لمجموعة غير موجودة، سيتم إنشاء المجموعة بشكل تلقائي قبل كتابة البيانات. بإمكانك استخدام الشفرة البرمجية التالية لإضافة 3 سندات documents لمجموعة تدعى myCollection باستخدام التابع insert: db.myCollection.insert([ {'name': 'Alice', 'age': 30}, {'name': 'Bill', 'age': 25}, {'name': 'Bob', 'age': 35} ]); وستظهر الرسالة التالية إن تم تنفيذ الشفرة بنجاح: BulkWriteResult({ "writeErrors" : [ ], "writeConcernErrors" : [ ], "nInserted" : 3, "nUpserted" : 0, "nMatched" : 0, "nModified" : 0, "nRemoved" : 0, "upserted" : [ ] }) الخطوة الثانية: التحقق من حجم قاعدة البيانات الآن وبعد أن حصلنا على قاعدة مع بعض البيانات فيها، سنقوم بأخذ نسخة احتياطية لها. ولكن حجم النسخ الاحتياطية قد يكون كبيرًا إن كانت لديك قاعدة بيانات كبيرة، وبالتالي حتى نتجنب المخاطرة باستهلاك مساحة التخزين المتبقية في القرص، وبالنتيجة إبطاء الخادوم أو منعه من العمل، فيجب أن نتحقق من حجم قاعدة البيانات قبل البدء بالنسخ الاحتياطي. للقيام بذلك بإمكاننا استخدام التابع stats والتحقق من القيمة التي يعيدها المفتاح dataSize لمعرفة حجم القاعدة مقدّرًا بالبايت. $ db.stats().dataSize; وبالنسبة لقاعدة بياناتنا التجريبية فإن الحجم سيكون رقمًا صغيرًا يبلغ 592 بايت. انتبه إلى أن القيمة التي يعطيها dataSize هي قيمة تقريبية لحجم النسخة الاحتياطية. الخطوة الثالثة: إنشاء النسخة الاحتياطية بإمكاننا استخدام الأمر mongodump والذي سيقوم باستدعاء أداة من الأدوات المرفقة مع MongoDb. سيقوم الأمر mongodump بشكل افتراضي بإنشاء نسخة احتياطية لجميع قواعد البيانات المستخدمة. ولإنشاء نسخة احتياطية لقاعدة بيانات معيّنة، يجب إضافة الخيار -d وتحديد اسم القاعدة. إضافة لذلك، يمكن إعلام mongodump بالمكان الذي نرغب بتخزين النسخة الاحتياطية فيه وذلك باستخدام الخيار -o وتحديد المسار. يتم تنفيذ mongodump من سطر الأوامر العادي لذا سنقوم الآن بإنهاء العمل بسطر أوامر mongo والعودة لسطر الأوامر العادي وذلك بالضغط على مفتاحي Ctrl+D. سنقوم بعد ذلك بتنفيذ الأمر mongodump لإنشاء نسخة احتياطية لقاعدتنا myDatabase وتخزين النسخة في المسار backups/first_backup/~: $ mongodump -d myDatabase -o ~/backups/first_backup إن تم تنفيذ الأمر بنجاح فيفترض أن تظهر الرسالة التالية: 2015-11-24T18:11:58.590-0500 writing myDatabase.myCollection to /home/me/backups/first_backup/myDatabase/myCollection.bson 2015-11-24T18:11:58.591-0500 writing myDatabase.myCollection metadata to /home/me/backups/first_backup/myDatabase/myCollection.metadata.json 2015-11-24T18:11:58.592-0500 done dumping myDatabase.myCollection (3 documents) 2015-11-24T18:11:58.592-0500 writing myDatabase.system.indexes to /home/me/backups/first_backup/myDatabase/system.indexes.bson لاحظ بأنّ النسخة الاحتياطية ليست ملفًّا واحدًا بل هو مجلد يملك الهيكل التالي: first_backup └── myDatabase ├── myCollection.bson ├── myCollection.metadata.json └── system.indexes.bson الخطوة الرابعة: حذف قاعدة البيانات لاختبار النسخة الاحتياطية التي قمنا بالحصول عليها، يمكن إما التوجّه لخادوم آخر يملك نسخة MongoDB أخرى أو حذف قاعدة البيانات التجريبية من الخادوم الحالي، وسنختار الخيار الثاني في المقال. لنقم الآن بفتح سطر أوامر mongo ومن ثم الاتصال بقاعدة البيانات: $ mongo myDatabase سنقوم بحذف قاعدة البيانات باستخدام التابع dropDatabase: $ db.dropDatabase(); إن تم حذف القاعدة بنجاح، ستشاهد الرسالة التالية: { "dropped" : "myDatabase", "ok" : 1 } وللتأكد يمكن استخدام التابع find على المجموعة myCollection وسنرى بأن جميع البيانات المدخلة سابقًا قد اختفت. $ db.myCollection.find(); وبطبيعة الحال فلن يكون هناك أي خرج نتيجة لتنفيذ الأمر لعدم وجود بيانات لإظهارها. الخطوة الخامسة: استعادة قاعدة البيانات من النسخة الاحتياطية لاستعادة قاعدة البيانات التي حصلنا على نسخة احتياطية منها باستخدام الأمر mongodump، سنقوم باستخدام أداة أخرى من أدوات Mongo يسمى mongorestore، ولكن قبل استخدامه قم بالعودة لسطر الأوامر العادي بالنقر على مفتاحي Ctrl+D إن كنت ما تزال في سطر أوامر mongo. إن من السهل استخدام أمر mongorestore حيث يكفي تمرير المسار الذي توجد به النسخة الاحتياطية كما في المثال: $ mongorestore ~/backups/first_backup/ وستظهر رسالة تشبه التالية دلالة على نجاح التنفيذ: 2015-11-24T18:27:04.250-0500 building a list of dbs and collections to restore from /home/me/backups/first_backup/ dir 2015-11-24T18:27:04.251-0500 reading metadata file from /home/me/backups/first_backup/myDatabase/myCollection.metadata.json 2015-11-24T18:27:04.252-0500 restoring myDatabase.myCollection from file /home/me/backups/first_backup/myDatabase/myCollection.bson 2015-11-24T18:27:04.309-0500 restoring indexes for collection myDatabase.myCollection from metadata 2015-11-24T18:27:04.310-0500 finished restoring myDatabase.myCollection (3 documents) 2015-11-24T18:27:04.310-0500 done ولاختبار البيانات التي قمنا باستعادتها، سنقوم بفتح سطر أوامر mongo مجددًا والاتصال بقاعدة myDatabase: $ mongo myDatabase ومن ثم نستخدم الأمر find على المجموعة: $ db.myCollection.find(); فإن سار كل شيء على ما يرام، ينبغي الآن أن تظهر لك البيانات المدخلة سابقًا: { "_id" : ObjectId("5654e76f21299039c2ba8720"), "name" : "Alice", "age" : 30 } { "_id" : ObjectId("5654e76f21299039c2ba8721"), "name" : "Bill", "age" : 25 } { "_id" : ObjectId("5654e76f21299039c2ba8722"), "name" : "Bob", "age" : 35 } الخلاصة تعلّمنا كيفية استخدام mongodump و mongorestore لإنشاء نسخة احتياطية واستعادة واحدة تخص قاعدة بيانات MongoDB. تذكر بأن إنشاء نسخة احتياطية هي عملية شرهة لموارد النظام ويمكن لها أن تخفض من أداء محرك MongoDB، لذا ينصح بأن تتم العملية فقط في الساعات التي تكون فيها الطلبات على القاعدة أقل ما يمكن. ترجمة -وبتصرّف- للمقال How to Create and Use MongoDB Backups on Ubuntu 14.04 لصاحبته Hazel Virdó.

يُعدّ محرك قواعد بيانات MongoDB أحد أشهر محرّكات قواعد بيانات NoSQL، ويشتهر بمرونته وقابليته للتوسعة وقوّته ومدى اعتماديّته وسهولة استخدامه. سنتحدث في المقال عن كيفية إجراء نسخ احتياطي واستعادة نسخة احتياطية ونقل قاعدة بيانات MongoDB. عند الحديث عن الاستيراد والتصدير في MongoDB فالمقصود التعامل مع البيانات بصيغة مقروءة من قبل البشر، ومتوافقة مع باقي المنتجات البرمجية. بالمقابل، فإن عمليات النسخ الاحتياطي واستعادة النسخ الاحتياطية تُنشئ أو تَستخدم نمط بيانات ثنائية binary خاصّة بـ MongoDB، وتحافظ بالتالي على تناسق وسلامة البيانات إضافة إلى سمات MongoDB الخاصة. بناء على ما سبق، فإنّه من المفضّل استخدام النسخ الاحتياطي عند الحاجة لتهجير migration قاعدة البيانات طالما أن هناك توافقية ما بين النظام المصدر والنظام الهدف. المتطلبات الأولية قبل أن نتابع، يرجى التأكّد من توفر المتطلبات التالية بشكل كامل: نظام تشغيل Ubuntu، مستخدم عادي بدون صلاحيات مدير نظام، لكنّه يملك صلاحية تنفيذ أمر sudo. يمكن مراجعة مقال الإعداد الابتدائي لخادوم أوبنتو 14.04 لمزيد من المعلومات، تثبيت وإعداد MongoDB. وعدا عمّا قد يستثنى بوضوح، فإنّ جميع الأوامر التي تحتاج لصلاحيات مدير نظام root في المقال، يجب أن يتم تنفيذها من قبل مستخدم عادي يملك صلاحيات sudo. نسخة قاعدة بيانات MongoDB تجريبية، ويمكن الحصول على واحدة وتثبيتها وفق التعليمات المذكورة في مقال استيراد وتصدير قاعدة بيانات MongoDB في نظام أوبنتو 14.04. تنبيه: يجب تنفيذ جميع الأوامر المذكورة في المقال بصلاحيات المستخدم العادي من خلال أمر sudo ويستثنى من ذلك ما يذكر صراحة أن يتم تنفيذه وفق صلاحيات مدير النظام root. فهم الأساسيات سنحتاج لفهم بعض الأمور قبل أن نتابع أكثر في المقال، وإن كنت تملك بعض الخبرة مع قواعد البيانات العلائقية relational المشهورة مثل MySQL، فربّما تجد بعض التشابه عند العمل مع MongoDB. إنّ أول ما تحتاج معرفته حول MongoDB هو أنها تستخدم صيغتي json و bson (الصيغة الثنائية binary من json) بغرض تخزين المعلومات. إنّ Json هي صيغة مقروءة من قبل البشر وبالتالي مناسبة جدًا لتصدير واستيراد البيانات في نهاية الأمر، ومن الممكن أيضًا التعديل على البيانات المصدّرة باستخدام أيّ أداة تدعم json، بما في ذلك أي محرر نصوص بسيط. يبدو أحد الأمثلة عن مستند json على الشكل التالي: {"address":[ {"building":"1007", "street":"Park Ave"}, {"building":"1008", "street":"New Ave"}, ]} إنّ Json مناسبة جدًا للعمل معها، لكنها لا تدعم جميع أنماط البيانات المتاحة في bson، وهذا يعني بأنّه سيكون لدينا "فقدان في الدقّة" في البيانات عند استخدام json، ولهذا السبب فإنّه من الأفضل استخدام الصيغة الثنائية bson في حالة النسخ الاحتياطي والاستعادة لأنّها ستساعد في استعادة قاعدة بيانات MongoDB بشكل أدق. ثانيًا، ليس هناك داعٍ للقلق حول إنشاء قاعدة البيانات إن لم تكن موجودة أصلًا عند القيام باستعادة نسخة احتياطية، حيث سيتم إنشاؤها بشكل تلقائي. إضافة لذلك، فإنّ هيكل المجموعات collections (التي تُقابل الجداول) في القاعدة -بخلاف محركات قواعد البيانات الأخرى- سيتم إنشاؤها أيضًا بشكل تلقائي عند إدراج insert أول سطر. ثالثًا، إن قراءة وإدراج كمّية كبيرة من البيانات في MongoDB، قد يستهلك مصادر النظام كقدرة المعالج، الذاكرة ومساحة التخزين بشكل كبير جدًا وهذه نقطة حساسة على اعتبار أن MongoDB تُستخدم عادة مع قواعد البيانات الكبيرة والبيانات الضخمة، والحل الأسهل لهذه المشكلة هو تنفيذ عمليات التصدير والنسخ الاحتياطي ليلًا. رابعًا، فقد يكون هناك مشكلة في تناسق البيانات إن كنت تملك خادوم MongoDB معرّض لضغط العمل باستمرار وبالتالي قد تتغير البيانات أثناء عملية التصدير، حيث لا يوجد حل بسيط لهذه المشكلة ولكن في نهاية المقال سنتحدث حول استنساخ البيانات replication. وعلى الرغم من أنه من الممكن استخدام وظائف الاستيراد والتصدير للحصول على نسخة احتياطية أو استعادتها، تبقى هناك طرق أفضل لتضمن دقة البيانات في قاعدة MongoDB، ومن هذه الطرق استخدام الأمر mongodump للحصول على نسخة احتياطية للبيانات، والأمر mongorestore لاستعادة نسخة احتياطية سابقة. الحصول على نسخة احتياطية لقاعدة بيانات MongoDB لنتحدث أولًا عن الحصول على نسخة احتياطية لقاعدة البيانات. يقوم المُعامل db-- في الأمر mongodump بتحديد اسم قاعدة البيانات التي نرغب بالحصول على نسخة احتياطية لها، فإن لم يتم تحديد اسم قاعدة البيانات، سيقوم الأمر بإنشاء نسخة احتياطية لجميع قواعد البيانات التي يديرها محرّك MongoDB. أما لتحديد مسار المجلّد الذي سيتم تخزين النسخ الاحتياطية فيه فنستخدم المُعامل out--. لنرى المثال التالي للحصول على نسخة احتياطية من قاعدة بيانات اسمها newdb ولتخزين النسخة في مجلد var/backups/mongobackups/. نصيحة: من الأفضل أن يتم تخزين كل نسخة احتياطية في مجلد فرعي يُسمّى بتاريخ اليوم الذي تم إنشاء النسخة الاحتياطية فيه، مثل var/backups/mongobackups/01-20-16/ (العشرون من كانون الثاني 2016). لنقم أولًا بإنشاء المجلد الرئيسي الذي سنقوم فيه بتخزين النسخ الاحتياطية لقواعد MongoDB التي نملكها، ونستخدم لذلك الأمر: $ sudo mkdir /var/backups/mongobackups ثم نقوم بإنشاء نسخة احتياطية بالأمر التالي: $ sudo mongodump --db newdb --out /var/backups/mongobackups/`date +"%m-%d-%y"` فإن تم تنفيذ الأمر بنجاح، سيظهر ما يشبه النتيجة التالية على الشاشة: 2016-01-20T10:11:57.685-0500 writing newdb.restaurants to /var/backups/mongobackups/01-20-16/newdb/restaurants.bson 2016-01-20T10:11:57.907-0500 writing newdb.restaurants metadata to /var/backups/mongobackups/01-20-16/newdb/restaurants.metadata.json 2016-01-20T10:11:57.911-0500 done dumping newdb.restaurants (25359 documents) 2016-01-20T10:11:57.911-0500 writing newdb.system.indexes to /var/backups/mongobackups/01-20-16/newdb/system.indexes.bson لاحظ في الأمر الذي قمنا بتنفيذه أننا أدرجنا الجزء التالي "date +"%m-%d-%y الذي يقوم بالحصول على تاريخ اليوم بشكل تلقائي، وبالتالي نحصل على نسخة احتياطية داخل مجلد فرعي /var/backups/mongobackups/01-20-16/، وهذا مناسب جدًا إن قمنا بجدولة الأمر ليتم تنفيذه بصورة اوتوماتيكية. عند الوصول إلى هذه المرحلة نكون قد حصلنا على نسخة احتياطية لقاعدة البيانات المسمّاة newdb في المسار /var/backups/mongobackups/01-20-16/newdb/، وتملك هذه النسخة جميع المعلومات اللازمة لاستعادة حالة القاعدة newdb في حال حصول مشكلة فيها. وكقاعدة عامة، يجب أن يتم الحصول على نسخ احتياطية بشكل دوري، على أساس نسخة احتياطية يومية مثلًا، ويستحسن أن يتم تنفيذ العملية في الوقت الذي يكون نشاط الخادوم أقل ما يمكن، وللقيام بذلك يمكن جدولة تنفيذ الأمر mongodump باستخدام cron حتى يتم تنفيذه بصورة دورية، مثلاً، الساعة 3:03 صباحًا من كل يوم. لتنفيذ ذلك سنقوم بفتح محرّر cron المسمّى crontab على الشكل التالي: $ sudo crontab -e ملاحظة: عندما يتم تنفيذ الأمر sudo crontab فإننا نقوم بتحرير المهام المجدولة الخاصة بحساب المستخدم مدير النظام root. إن هذا مستحسن لأنه في حال جدولة الأمر mongodump ليتم تنفيذه بصلاحيات مستخدم آخر فقد لا يتم التنفيذ بشكل صحيح وخصوصًا إن كانت إعدادات sudo تتطلب تأكيد الأمر بإدخال كلمة المرور. سنقوم في crontab بإدخال السطر التالي: 3 3 * * * mongodump --out /var/backups/mongobackups/`date +"%m-%d-%y"` لاحظ أننا لم نستخدم المعامل db-- في الأمر السابق لأننا نرغب بالحصول على نسخة احتياطية دورية لجميع القواعد التي نملكها. إن تنفيذ النسخ الاحتياطي الدوري سيؤدي مع الوقت إلى استهلاك مساحة التخزين على القرص الصلب، لذا فمن الأفضل أن يتم حذف النسخ الاحتياطية القديمة بصورة دورية أو خفض المساحة التي تستهلكها عبر ضغطها. لحذف النسخ الاحتياطية التي تم الحصول عليها قبل 7 أيام يمكن أن نستخدم الأمر التالي: $ find /var/backups/mongobackups/ -mtime +7 -exec rm -rf {} \; وكما في الأمر المُجدول السابق فمن الممكن التخلص من النسخ الاحتياطية القديمة بصورة دورية عبر تنفيذ الأمر قبل أمر النسخ الاحتياطي، ولأجل هذا سنقوم بإدراج السطر التالي في cron، والذي سيتم تنفيذه الساعة 3:01 صباحًا من كل يوم: 3 1 * * * find /var/backups/mongobackups/ -mtime +7 -exec rm -rf {} \; وبإتمام الخطوات السابقة نكون قد ضمنّا حلًا مناسبًا للنسخ الاحتياطي لقواعد بيانات MongoDB. استعادة نسخة احتياطية لقاعدة بيانات MongoDB إن استعادة نسخة احتياطية سابقة لقاعدة بيانات MongoDB (كالتي حصلنا عليها من الخطوة السابقة) تتم باستخدام الأمر mongorestore والذي يمكّنك من الحصول على نسخة مطابقة تمامًا لبيانات القاعدة كما كانت في لحظة إنشاء النسخة الاحتياطية، متضمنًا ذلك جميع الفهارس وأنماط البيانات، وهذه مسألة مفيدة جدًا إن رغبت بنقل قاعدة البيانات. ومتابعة من المثال السابق، لنرى كيف من الممكن استعادة نسخة احتياطية سابقة. سنقوم باستخدام المُعامل db-- مع الأمر mongorestore لتحديد القاعدة التي نرغب باستعادة النسخة الاحتياطية إليها، كما سنستخدم المُعامل drop-- كي نضمن أن يتم حذف القاعدة القديمة حتى تتم استعادة النسخة الاحتياطية إلى نسخة جديدة من القاعدة لا تحتوي أي مشاكل، وأخيرًا سنقوم بتحديد مسار النسخة الاحتياطية التي نرغب باستعادتها; سيظهر الأمر كاملًا على النحو التالي (لا تنس استبدال المسار بمسار النسخة الموجودة لديك والتي ترغب باستعادتها): $ sudo mongorestore --db newdb --drop /var/backups/mongobackups/01-20-16/newdb/ وسيظهر ما يشبه الخرج التالي على الشاشة في حال تنفيذ الأمر بالشكل الصحيح: 2016-01-20T10:44:47.876-0500 building a list of collections to restore from /var/backups/mongobackups/01-20-16/newdb/ dir 2016-01-20T10:44:47.908-0500 reading metadata file from /var/backups/mongobackups/01-20-16/newdb/restaurants.metadata.json 2016-01-20T10:44:47.909-0500 restoring newdb.restaurants from file /var/backups/mongobackups/01-20-16/newdb/restaurants.bson 2016-01-20T10:44:48.591-0500 restoring indexes for collection newdb.restaurants from metadata 2016-01-20T10:44:48.592-0500 finished restoring newdb.restaurants (25359 documents) 2016-01-20T10:44:48.592-0500 done وفي هذه الحالة نكون قد أنجزنا استعادة نسخة احتياطية للقاعدة على الخادوم ذاته. أمّا لو رغبنا بنقل البيانات من خادوم لآخر باستخدام نفس الطريقة، فكُل ما نحتاجه هو نسخ مجلد النسخة الاحتياطية /var/backups/mongobackups/01-20-16/newdb/ إلى الخادوم الجديد قبل تنفيذ أمر استعادة النسخة الاحتياطية على الخادوم الجديد. الخلاصة تعرّفنا في المقال على أساسيات إدارة بيانات قاعدة MongoDB فيما يخص النسخ الاحتياطي والاستعادة من نسخة احتياطية سابقة، ونقل قاعدة البيانات من خادوم لآخر. إن آلية النسخ المُتماثل للبيانات ليست مهمّة بغرض قابلية التوسعة فحسب، وإنما مهمّة للموضوع الذي نتحدث عنه الآن، حيث تسمح الآلية باستمرارية تشغيل خدمة MongoDB دون توقّف أو انقطاع من خلال خادوم MongoDB ثانوي بينما يتم استعادة نسخة احتياطية على الخادوم الرئيسي في حال حدوث خلل ما فيه. وتعتبر سجلّات التشغيل (operations log (oplog جزءًا من آلية النسخة المُتماثل، حيث تقوم هذه السجلّات بتخزين جميع العمليات التي قامت بتغيير البيانات، ومن الممكن استخدام هذا السجل -كما يستخدم السجل الثنائي binary log في MySQL- بغرض استعادة البيانات بعد آخر نسخة احتياطية. تذكّر بأن النسخ الاحتياطي عادة يتم في فترة متأخرة من الليل، فإن قررت استعادة نسخة احتياطية ليلًا (قبل أن تبدأ عملية النسخ الاحتياطي) فستفقد جميع البيانات الجديدة التي لم يتم الحصول على نسخة احتياطية لها أولًا. ترجمة -وبتصرّف- للمقال How To Back Up, Restore, and Migrate a MongoDB Database on Ubuntu 14.04 لصاحبه Anatoliy Dimitrov.

يُعدّ MongoDB أحد أشهر محركات قواعد البيانات من نوع NoSQL، فهو شهير بمرونته، فعاليّته، موثوقيته وسهولة استخدامه، وسنستعرض في المقال كيفية استيراد وتصدير قواعد بيانات MongoDB. تجدر الإشارة إلى أنّه عند حديثنا عن الاستيراد والتصدير فالمقصود التعامل مع البيانات بصيغة مقروءة من قبل البشر، ومتوافقة مع باقي المنتجات البرمجية. بالمقابل، فإن عمليات النسخ الاحتياطي واستعادة النسخ الاحتياطية تُنشئ أو تَستخدم نمط بيانات ثنائية binary خاصّة بـ MongoDB، وتحافظ بالتالي على تناسق وسلامة البيانات إضافة إلى سمات MongoDB الخاصة. بناء على ما سبق، فإنّه من المفضّل استخدام النسخ الاحتياطي عند الحاجة لنقل/تهجير migration قاعدة البيانات طالما أن هناك توافقية ما بين النظام المصدر والنظام الهدف، وهذا الموضوع خارج إطار حديثنا. المتطلبات الأولية قبل أن نتابع، يرجى التأكّد من توفر المتطلبات التالية بشكل كامل: نظام تشغيل Ubuntu 14.04، مستخدم عادي بدون صلاحيات مدير نظام، لكنّه يملك صلاحية تنفيذ أمر sudo. يمكن مراجعة الإعداد الابتدائي لخادوم أوبنتو 14.04 لمزيد من المعلومات، تثبيت وإعداد MongoDB. وعدا عمّا قد يستثنى بوضوح، فإنّ جميع الأوامر التي تحتاج لصلاحيات مدير نظام root في المقال، يجب أن يتم تنفيذها من قبل مستخدم عادي يملك صلاحيات sudo. فهم الأساسيات سنحتاج لفهم بعض الأمور قبل أن نتابع المقال، وإن كنت تملك بعض الخبرة مع قواعد البيانات العلائقية relational المشهورة مثل MySQL، فربّما تجد بعض التشابه عند العمل مع MongoDB. إنّ أول ما تحتاج معرفته حول MongoDB هو أنها تستخدم صيغتي json و bson (الصيغة الثنائية binary من json) بغرض تخزين المعلومات. إنّ Json هي صيغة مقروءة من قبل البشر وبالتالي مناسبة جدًا لتصدير واستيراد البيانات في نهاية الأمر، ومن الممكن أيضًا التعديل على البيانات المصدّرة باستخدام أيّ أداة تدعم json، بما في ذلك أي محرر نصوص بسيط. يبدو أحد الأمثلة عن مستند json على الشكل التالي: {"address":[ {"building":"1007", "street":"Park Ave"}, {"building":"1008", "street":"New Ave"}, ]} إنّ Json مناسبة جدًا للعمل معها، لكنها لا تدعم جميع أنماط البيانات المتاحة في bson، وهذا يعني بأنّه سيكون لدينا "فقدان في الدقّة" في البيانات عند استخدام json، ولهذا السبب فإنّه من الأفضل استخدام الصيغة الثنائية bson في حالة النسخ الاحتياطي والاستعادة لأنّها ستساعد في استعادة قاعدة بيانات MongoDB بشكل أدق. ثانيًا، ليس هناك داعٍ للقلق حول إنشاء قاعدة البيانات إن لم تكن موجودة أصلًا عند القيام باستعادة نسخة احتياطية، حيث سيتم إنشاؤها بشكل تلقائي. إضافة لذلك، فإنّ هيكل المجموعات collections (التي تُقابل الجداول) في القاعدة -بخلاف محركات قواعد البيانات الأخرى- سيتم إنشاؤها أيضًا بشكل تلقائي عند إدراج insert أول سطر. ثالثًا، إن قراءة وإدراج كمّية كبيرة من البيانات في MongoDB، قد يستهلك مصادر النظام كقدرة المعالج، الذاكرة ومساحة التخزين بشكل كبير جدًا وهذه نقطة حساسة على اعتبار أن MongoDB تُستخدم عادة مع قواعد البيانات الكبيرة والبيانات الضخمة، والحل الأسهل لهذه المشكلة هو تنفيذ عمليات التصدير والنسخ الاحتياطي ليلًا. رابعًا، فقد يكون هناك مشكلة في تناسق البيانات consistency إن كنت تملك خادوم MongoDB معرّض لضغط العمل باستمرار وبالتالي قد تتغير البيانات أثناء عملية التصدير، حيث لا يوجد حل بسيط لهذه المشكلة ولكن في نهاية المقال سنتحدث حول استنساخ البيانات replication. استيراد المعلومات إلى قاعدة بيانات MongoDB لنتعلّم كيفية استيراد المعلومات إلى قاعدة بيانات MongoDB، سنقوم باستخدام عيّنة قاعدة بيانات معروفة حول المطاعم. إنّ القاعدة بصيغة json ويمكن تحميلها باستخدام الأمر wget بالشكل التالي: $ wget https://raw.githubusercontent.com/mongodb/docs-assets/primer-dataset/primer-dataset.json وحالما ينتهي التحميل ستحصل على ملف حجمه 12 ميغابايت يُدعى primer-dataset.json في المجلّد الذي قمت بتنفيذ الأمر فيه. سنقوم باستيراد البيانات من هذا الملف إلى قاعدة بيانات جديدة سنسمّيها newdb وضمن جدول سنسمّيه restaurants. للقيام بعملية الاستيراد سنستخدم الأمر mongoimport على الشكل التالي: $ sudo mongoimport --db newdb --collection restaurants --file primer-dataset.json ويُفترض أن تكون نتيجة تنفيذ الأمر السابق على الشكل التالي: 2016-01-17T14:27:04.806-0500 connected to: localhost 2016-01-17T14:27:07.315-0500 imported 25359 documents وكما يظهر في الناتج السابق، فقد تم استيراد 25359 مستند، ولأننا لم نكن نملك قاعدة بيانات باسم newdb، فقد قام محرّك MongoDB بإنشائها بشكل تلقائي، وللتأكّد من نجاح عملية الاستيراد سنقوم بالاتصال بقاعدة البيانات newdb على الشكل التالي: $ sudo mongo newdb سنلاحظ عند تنفيذ الأمر بأن شكل مِحرف سطر الأوامر قد تغيّر، مما يشير إلى نجاح الاتصال بقاعدة البيانات، وللتحقق الآن من عدد المستندات التي تم استيرادها، سنقوم بتنفيذ الأمر التالي: > db.restaurants.count() ويفترض أن تكون النتيجة 25359، وهو مطابق تمامًا لعدد المستندات المستوردة. وللتحقق بشكل أفضل من نجاح الاستيراد، سنقوم باختيار المستند الأول من مجموعة المطاعم بتنفيذ الأمر التالي: > db.restaurants.findOne() وينبغي أن تكون النتيجة على الشكل التالي: { "_id" : ObjectId("569beb098106480d3ed99926"), "address" : { "building" : "1007", "coord" : [ -73.856077, 40.848447 ], "street" : "Morris Park Ave", "zipcode" : "10462" }, "borough" : "Bronx", "cuisine" : "Bakery", "grades" : [ { "date" : ISODate("2014-03-03T00:00:00Z"), "grade" : "A", "score" : 2 }, ... ], "name" : "Morris Park Bake Shop", "restaurant_id" : "30075445" } إنّ مثل هذا التحقق قد يظهر أيّ مشاكل في محتوى المستندات أو ترميزها أو ما شابه ذلك، فصيغة json تستخدم ترميز UTF-8 ويجب أن تكون البيانات المصدّرة والمستوردة بهذا الترميز. تذكّر هذا الأمر دومًا عند القيام بتحرير ملفات json بشكل يدوي، وفيما عدا ذلك فإنّ محرك MongoDB سيتولّى الأمر عنك بشكل تلقائي. أخيرًا، للخروج من سطر أوامر MongoDB نقوم بتنفيذ الأمر exit على الشكل: > exit وسيتم الخروج والعودة إلى سطر أوامر النظام كمستخدم عادي. تصدير المعلومات من قاعدة بيانات MongoDB كما ذكرنا سابقًا، فإنّه من الممكن الحصول على بيانات مقروءة ومفهومة عند القيام بتصدير المعلومات من قاعدة MongoDB، وتكون صيغة الملف المصدّر بشكل افتراضي هي json، ولكن من الممكن أيضًا الحصول على البيانات في ملف بصيغة (csv (comma separated value. نستخدم الأمر mongoexport لتصدير البيانات من قاعدة MongoDB، ويسمح أمر التصدير باختيار قاعدة بيانات، مجموعة من المجموعات collection، حقل من الحقول، وحتّى استخدام استعلام من أجل التصدير. وكمثال بسيط على أمر التصدير mongoexport، سنقوم بتصدير مجموعة المطاعم من قاعدة newdb التي قمنا باستيرادها سابقًا، ويبدو الأمر على النحو التالي: $ sudo mongoexport --db newdb -c restaurants --out newdbexport.json حيث قمنا في الأمر السابق باستخدام المُعامل db-- لتحديد القاعدة، والمُعامل c- لتحديد المجموعة، والمُعامل --out لتحديد اسم الملف الذي سيتم تصدير البيانات إليه، وستكون نتيجة تنفيذ الأمر السابق بشكل ناجح على النحو التالي: 2016-01-20T03:39:00.143-0500 connected to: localhost 2016-01-20T03:39:03.145-0500 exported 25359 records ويظهر الأمر السابق أنه قد تم تصدير 25359 مستند، وهو مماثل تمامًا لعدد المستندات التي قمنا باستيرادها سابقًا. قد نحتاج في بعض الأحيان إلى تصدير جزء من مجموعة، وبالأخذ بعين الاعتبار هيكل ومحتوى مستند المطاعم بصيغة json، سنقوم بتصدير معلومات جميع المطاعم التي تحقق الشرط الذي يقول بأنها موجودة في المنطقة الإدارية المسمّاة Bronx والتي تقدّم الطعام الصيني. للحصول على هذه المعلومات بشكل مباشر في حال كنّا متصلين بقاعدة MongoDB من خلال سطر أوامر MongoDB، فسنقوم بالاتصال بقاعدة البيانات مجددًا: $ sudo mongo newdb ومن ثم سنستخدم الاستعلام: > db.restaurants.find( { borough: "Bronx", cuisine: "Chinese" } ) وسيتم عرض النتيجة مباشرة، وللخروج من سطر أوامر MongoDB سننفّذ الأمر exit كما ذكرنا سابقًا. أمّا لتصدير البيانات من سطر أوامر النظام دون أن نكون متصلين بقاعدة البيانات مسبقًا، فسنقوم بتمرير الاستعلام السابق كمُعامل لأمر mongoexport باستخدام المُعامل q- على الشكل التالي: $ sudo mongoexport --db newdb -c restaurants -q "{ borough: 'Bronx', cuisine: 'Chinese' }" --out Bronx_Chinese_retaurants.json لاحظ في الأمر السابق بأنّا قمنا باستخدام علامات الاقتباس الفرديّة ' داخل علامات الاقتباس الزوجيّة " لأنّ هذا شرط من شروط كتابة الاستعلام في سطر الأوامر، ولو احتجنا لاستخدام علامات اقتباس زوجيّة أو إشارة $ فسنحتاج لتخطي المحارف الخاصة باستخدام \ بإدراجها قبل المحرف الخاص في الاستعلام. إن تمت عملية التصدير بنجاح فينبغي أن تكون النتيجة على الشكل التالي: 2016-01-20T04:16:28.381-0500 connected to: localhost 2016-01-20T04:16:28.461-0500 exported 323 records تُظهر النتيجة السابقة بأنّ هناك 323 سجل قد تم تصديره، ويمكن إيجادها ضمن ملف Bronx_Chinese_retaurants.json الذي قمنا بتحديده. الخلاصة تعرفّنا في المقال على أساسيات استيراد وتصدير المعلومات من وإلى قاعدة بيانات MongoDB. إنّ عملية الاستنساخ replication مفيدة في حالة التوسعة، ولكنّها مهمة أيضًا للنواحي التي تحدثنا عنها، حيث تسمح باستمرارية تشغيل خدمات MongoDB دون انقطاع عبر خادوم MongoDB ثانوي بينما نقوم باستعادة نسخة احتياطية إلى الخادوم الرئيسي عند حدوث فشل. إن جزءًا من عملية الاستنساخ هو سجل العمليات (oplog)، الذي يقوم بتسجيل جميع العمليات التي تقوم بتغيير البيانات، ويمكن استخدام هذا السجل كما في MySQL، لاستعادة البيانات بعد أن تكون آخر عملية نسخ احتياطي قد بدأت. تذكّر بأن عمليات النسخ الاحتياطي تحصل في الليل عندما يكون نشاط قاعدة البيانات في حدّه الأدنى، وإن قررت استعادة نسخة احتياطية لقاعدة البيانات في الفترة المسائية (أي قبل أن تبدأ عملية النسخ الاحتياطي الليلية) فإنّك ستفقد بذلك جميع التعديلات التي تمت على القاعدة منذ آخر عملية نسخ احتياطي. ترجمة -وبتصرّف- للمقال How To Import and Export a MongoDB Database on Ubuntu 14.04 لصاحبه Anatoliy Dimitrov.

لم تعد الكثير من التطبيقات التي تعمل على الأجهزة المحمولة، مع تقدم تقنيات مثل التخزين المحلّي Local storage على المتصفحات، تحتاج إلى الاستخدام الكثيف لقواعد البيانات؛ مع بقاء الحاجة للاتصال بخادوم بعيد يخزّن ويحدّث بيانات ضرورية مثل معلومات المستخدم، نتائج مسابقة أو غيرها من البيانات التي لا يمكن تخزينها على العميل. تأتي منصات خدمات النهاية الخلفية للأجهزة المحمولة Mobile Backend as a Service لحل هذا الإشكال: تخزين بيانات على الخادوم لتوفيرها للأجهزة العميلة بأقل تكلفة. Parse التي تمتلكها فيس بوك هي إحدى هذه المنصات. أعلنت فيس بوك في شهر يناير 2016 عن إغلاق المنصة مع فتح مصدر النهاية الخلفية ونشرها باسم Parse server ليستمر تطويرها ويمكن تثبيتها في أي بيئة تشغّل Node.js و MongoDB دون الاعتماد على منصة الشركة؛ على أن تتوقف المنصة التابعة للشركة في شهر يناير 2017. يقدّم هذا الدليل تفاصيل تثبيت Parse server على خادوم أوبنتو 14.04؛ ويتوجّه ليكون مدخلا لتهجير التطبيقات من Parse أو لاستخدام النهاية الخلفية التي يوفرها في تطبيقات جديدة. المتطلبات سنفترض أن لديك خادوم أوبنتو 14.04 وحساب مستخدم بصلاحيات إدارية، غير المستخدم الجذر root. تمكن مراجعة درس الإعداد الابتدائي لخادوم أوبنتو 14.04 لإعدادات نظام التشغيل. يتطلّب الدرس كذلك تثبيت MongoDB. تأكد من إعداد المتطلبات ثم عد لهذا الدليل واتّبع الخطوات التالية. الخطوة الأولى: تثبيت Node.js وأدوات التطوير ابدأ بالانتقال إلى مجلد المستخدم الشخصي: cd ~ سنستخدم مستودع Apt الذي توفره NodeSource عن طريق سكربت تثبيت النسخة المستقرة الأخيرة من Node.js (الإصدار 5.5.0 أثناء كتابة هذا الدليل). نزّل السكربت بالأمر التالي: curl -sL https://deb.nodesource.com/setup_5.x -o nodesource_setup.sh يمكنك، إن أردت، رؤية محتوى السكربت باستخدام nanoأو أي محرّر نصوص آخر: nano ./nodesource_setup.sh نفذ السكربت بصلاحيات إدارية مع استخدام خيار E- لإخبار sudo بالحفاظ على متغيرات النظام Environment variables الخاصّة بالمستخدم: sudo -E bash ./nodesource_setup.sh تُضاف مستودعات NodeSource إلى النظام بعد انتهاء السكربت، ويمكننا بالتالي استخدام apt-get لتثبيت حزمة nodejs. سنثبت حزمة التعريف build-essential التي تتيح مجموعة من أدوات التطوير التي يمكن أن تكون مفيدة لنا في ما بعد، إضافة إلى نظام التحكّم في النسخ Git لنستخدمه في تنزيل المشروعات من GitHub: sudo apt-get install -y nodejs build-essential git الخطوة الثانية: تثبيت تطبيق Parse Server تجريبي صُمّم Parse Server للعمل بالتزامن مع Express، وهو إطار عمل Node.js شائع الاستخدام لتطبيقات الويب، يسمح بتركيب عناصر البرمجيات الوسيطة Middleware المستجيبة لتعريف واجهة تطبيقات برمجية API على مسار محدَّد. يحوي مستودع parse-server-example على GitHub مثالا لتطبيق يتبع هذا النمط في تصميم البرامج. انسخ المستودع باستخدام git على النحو التالي: git clone https://github.com/ParsePlatform/parse-server-example.git ادخل إلى مجلد parse-server-example الذي نسخته للتو: cd ~/parse-server-example ثم استخدم npm لتثبيت الاعتماديات بما فيها parse-server في المجلد الحالي: npm install سيعثُر npm على جميع الوحدات Modules المطلوبة لـ parse-server ثم يخزّنها على المسار parse-server-example/node_modules/~. الخطوة الثالثة: اختبار التطبيق التجريبي استخدم أمر npm لبدء تشغيل الخدمة. يُنفَّذ الأمر المعرَّف في خاصية start من ملف package.json؛ أي في هذه الحالة node index.js: npm start مخرجات الأمر: > parse-server-example@1.0.0 start /home/sammy/parse-server-example > node index.js DATABASE_URI not specified, falling back to localhost. parse-server-example running on port 1337. يمكن إنهاء تشغيل التطبيق في أي وقت بالضغط على الزرين Ctrl وC. يمرّر تطبيق Express المعرَّف في index.js طلبات HTTP إلى وحدة parse-server التي تتواصل مع قاعدة بيانات MongoDB وتطلُب تنفيذ الدوال المعرَّفة في الملف parse-server-example/cloud/main.js/~. نقطة النهاية Endpoint المبدئية لواجهة تطبيقات Parse Server في هذا المثال هي: http://your_server_IP/parse يمكن استخدام أمر curl في سطر أوامر آخر، أثناء عمل التطبيق، لتجربة نقطة النهاية. تأكد أولا من تسجيل دخولك إلى الخادوم إذ أن هذه الأوامر تستدعي المضيف المحلّي localhost بدلا من عنوان IP آخر. أنشئ تسجيلة Record بإرسال طلب POST مع ترويسة X-Parse-Application-Id لتحديد التطبيق، إضافة لبيانات أخرى بصيغة JSON: curl -X POST \ -H "X-Parse-Application-Id: myAppId" \ -H "Content-Type: application/json" \ -d '{"score":1337,"playerName":"Sammy","cheatMode":false}' \ http://localhost:1337/parse/classes/GameScore مخرجات الأمر: {"objectId":"fu7t4oWLuW","createdAt":"2016-02-02T18:43:00.659Z"} تُخزَّن البيانات المرسَلة في قاعدة بيانات MongoDB ويمكن إيجادها بإرسال طلب GET باستخدام curl مرة أخرى: curl -H "X-Parse-Application-Id: myAppId" http://localhost:1337/parse/classes/GameScore مخرجات الأمر: {"results":[{"objectId":"GWuEydYCcd","score":1337,"playerName":"Sammy","cheatMode":false,"updatedAt":"2016-02-02T04:04:29.497Z","createdAt":"2016-02-02T04:04:29.497Z"}]} استدع الدالة hello المعرَّفة في الملف parse-server-example/cloud/main.js/~ باستخدام واجهة التطبيقات البرمجية: curl -X POST \ -H "X-Parse-Application-Id: myAppId" \ -H "Content-Type: application/json" \ -d '{}' \ http://localhost:1337/parse/functions/hello مخرجات الأمر: {"result":"Hi"} الخطوة الرابعة: إعدادات التطبيق التجريبي اضغط على Ctrl وC في نافذة سطر الأوامر الأولى لإيقاف تطبيق Parse Server. يمكن إعداد التطبيق باستخدام ستة متغيرات نظام يبينها الجدول التالي. المتغير الوصف DATABASE_URI مسار الاتصال بقاعدة بيانات MongoDB، مثلاmongodb://localhost:27017/dev CLOUD_CODE_MAIN مسار إلى ملف يحوي الشفرة المصدرية لدوال Cloud Code الخاصّة بـParse APP_ID سلسلة محارف لتعريف التطبيق، مثلا myAppId. MASTER_KEY مفتاح سري رئيس يمكّن من تجاوز جميع آليات الأمان في التطبيق. PARSE_MOUNT المسار الذي توجد عليه واجهة تطبيقات Parse Server PORT المنفذ الذي ينصت عليه التطبيق، مثلا 1337 ننفذ أمر export قبل تشغيل التطبيق لإعداد متغيرات النظام، مثلا: export APP_ID=fooApp يمكننا إنشاء نسخة أسهل من التطبيق لأخذ صورة عن آلية العمل. أنشئ ملف سكربت جديدا: nano my_app.js ثم ألصق الشفرة التالية مع تغيير القيم بما يناسب: var express = require('express'); var ParseServer = require('parse-server').ParseServer; // إعداد واجهة التطبيقات البرمجية var api = new ParseServer({ databaseURI: 'mongodb://localhost:27017/dev', cloud: __dirname + '/cloud/main.js', appId: 'myOtherAppId', masterKey: 'myMasterKey' }); var app = express(); // ضبط مسار التطبيق app.use('/myparseapp', api); // الإنصات للاتصالات القادمة على المنفذ 9999 var port = 9999; app.listen(port, function() { console.log('parse-server-example running on port ' + port + '.'); }); احفظ الملف ثم نفذ الأمر التالي بعد إغلاقه: node my_app.js مخرجات الأمر: parse-server-example running on port 9999. يمكنك في أي وقت إيقاف التطبيق بالضغط على Ctrl وC. يعمل my_app.js بنفس الطريقة التي يعمل بها index.js تقريبا، مع فرق أنه ينصت على المنفذ 9999 مع تركيب Parse Server على المسار myparseapp/ بحيث يصبح مسار نقطة النهاية كما يلي: http://yourserverIP:9999/myparseapp يمكن تجربتها بـاستخدام curl على النحو التالي: curl -H "X-Parse-Application-Id: myOtherAppId" http://localhost:9999/myparseapp/classes/GameScore خاتمة قدّمنا في هذا الدرس أساسيات تشغيل تطبيق Node.js مثل Parse Server على أوبنتو. يتطلّب تهجير تطبيق من Parse حذرا أكبر وربما تعديلات على الشفرة البرمجية ويجب أن يُستعدّ له جيدا من ناحية تهيئة البنية التحتية. ترجمة -وبتصرّف- للمقال How To Run Parse Server on Ubuntu 14.04 لصاحبه Brennen Bearnes.