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

منذ زمن سحيق، كانت الذاكرةُ أكثر وظيفة نحتاجها ونعتمد عليها في الحاسوب. ورغم اختلاف التقنيات وأساليب التنفيذ الكامنة وراءها، إلّا أنّ معظم الحواسيب تأتي بالعتاد الضروريّ لمعالجة المعلومات وحفظها بأمان لاستخدامها في المستقبل متى احتجنا لها. لقد صار من المستحيل في عالمنا الحديث تخيل أيّ عمل لا يستفيد من هذه القدرة في الأجهزة، سواء كانت خواديم أو حواسيب شخصية أو كفّيّة. تُعالَج البيانات وتُسجَّل وتُسترجَع مع كل عملية، وفي كل مكان من الألعاب إلى الأدوات المتعلقة بالأعمال، بما فيها المواقع. أنظمة إدارة قواعد البيانات (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.

نشرح طريقة تثبيت وإعداد خادم PostgreSQL على نظام أوبنتو 18.04. مع إعداد كلمة مرور للمستخدم root؛ وإنشاء قاعدة بيانات جديدة ومستخدم جديد لديه الصلاحيات الكاملة عليها. قسم PostgreSQL في أكاديمية حسوب غني بالمقالات المفيدة للتعامل معها: https://academy.hsoub.com/devops/servers/databases/postgresql/ نوفر توثيقًا كاملًا لجميع تعليمات SQL على موسوعة حسوب: https://wiki.hsoub.com/SQL

مقدمة تأتي قواعد بيانات SQL مُثبّتة مع جميع الأوامر التي تحتاجها للإضافة، والتعديل، والحذف والاستعلام عن بياناتك. يوفّر هذا الدليل لنمط الورقة المرجعية cheat sheet مرجعًا سريعًا لبعضٍ من أوامر SQL الأكثر شيوعًا. كيفية استخدام هذا الدليل: هذا الدليل على شكل ورقة مرجعيّة فيها أمثلة منفصلة قابلة للاستخدام فرادى. انتقل إلى أي مقطع ذي صلة بالمهمة التي تحاول إكمالها. عندما ترى نصًّا مميّزًا في أوامر هذا الدليل، فضع بالحسبان أن هذا النص يشير إلى الأعمدة، والجداول، والبيانات في قاعدة البيانات الخاصة بك. ضُمّنت قيم البيانات في هذا الدليل في الأمثلة المُعطاة بعلامة ('). من الضروري في SQL تضمين أي قيم بيانات تحتوي على سلاسل نصية في علامات اقتباس أحادية. هذا التضمين غير مطلوب من أجل البيانات الرقمية، ولكنه لن يتسبب بأيّة مشاكل أيضًا. يرجى ملاحظة أنّه على الرغم من كون SQL معياريّة، إلاّ أنّ معظم برامج قواعد بيانات SQL لها إضافاتها الخاصّة. يستخدم هذا الدليل MySQL كنموذج لنظام إدارة قواعد البيانات العلائقية (RDBMS)، ولكن الأوامر المقدّمة ستعمل مع برامج قواعد البيانات العلائقية الأخرى، بما في ذلك PostgreSQL و MariaDB وSQLite. سنُضمّن الأوامر البديلة عند وجود فروق مهمّة بين أنظمة إدارة قواعد البيانات العلائقية RDBMSs. بدء مِحث أوامر قاعدة البيانات (باستخدام استيثاق Socket/Trust) يمكن لمستخدم MySQL الجذر root الاستيثاق بدون كلمة مرور بشكل افتراضي في نظام التشغيل أبونتو Ubuntu 18.04 باستخدام الأمر التالي: $ sudo mysql استخدم الأمر التالي لفتح مِحث أوامر PostgreSQL. سيُسجلك هذا المثال كمستخدم postgres، والذي يتضمن صلاحيات دور المستخدم المميّز superuser role، ولكن يمكنك استبداله بأي دور مُنشئ مُسبقًا: $ sudo -u postgres psql بدء مِحث أوامر قاعدة البيانات (باستخدام استيثاق كلمة المرور) إذا ُضبط مستخدم MySQL الجذر root للاستيثاق باستخدام كلمة مرور، فبإمكانك استخدام الأمر التالي: $ mysql -u root -p إذا أعددت مُسبقًا حساب مستخدم عادي non-root لقاعدة بياناتك، فيمكنك أيضًا استخدام هذه الطريقة لتسجيل الدخول باسم هذا المستخدم: $ mysql -u user -p سيُقاطعك الأمر السابق بعد تشغيله للمطالبة بكلمة المرور الخاصّة بك. إذا كنت ترغب في جعل كلمة المرور كجزء من الأمر، فأَتبعْ الخيار p- مباشرة بكلمة مرورك، بدون ترك فراغ بينهما: $ mysql -u root -ppassword إنشاء قاعدة بيانات يُنشئ الأمر التالي قاعدة بيانات بإعداداتٍ افتراضيّة: mysql> CREATE DATABASE database_name; يمكنك إذا أردت لقاعدة بياناتك أن تستخدم مجموعة محارف وتصنيف مختلفة عن الإعدادات الافتراضيّة تحديد ذلك باستخدام الصياغة التالية: mysql> CREATE DATABASE database_name CHARACTER SET character_set COLLATE collation; إظهار قائمة قواعد البيانات شغّل الأمر التالي لرؤية قواعد البيانات الموجودة في نظام MySQL أو MariaDB: mysql> SHOW DATABASES; يمكنك في PostgreSQL مشاهدة قواعد البيانات المُنشأة باستخدام الأمر التالي: postgres=# \list حذف قاعدة البيانات شغّل الأمر التالي لحذف قاعدة بيانات بما في ذلك ضمنًا أي جداول وبيانات موجودة فيها: mysql> DROP DATABASE IF EXISTS database; إنشاء مستخدم نفّذ الأمر التالي لإنشاء معرّف مستخدِم لقاعدةِ بياناتك من دون تحديد أيّ امتيازاتٍ له: mysql> CREATE USER username IDENTIFIED BY 'password'; تَستخدم PostgreSQL بنية مشابهة، ولكنها مختلفة قليلاً، إليك الصياغة: postgres=# CREATE USER user WITH PASSWORD 'password'; يمكنك إذا أردتَ إنشاء مستخدم جديد ومنحه امتيازات باستخدام أمر واحد عن طريق إصدار عبارة GRANT. ينشئ الأمر التالي مستخدمًا جديدًا ويمنحه امتيازات كاملة لكامل قاعدة البيانات والجداول في نظام إدارة قواعد البيانات العلائقية RDBMS: mysql> GRANT ALL PRIVILEGES ON *.* TO 'username'@'localhost' IDENTIFIED BY 'password'; لاحظ الكلمة المفتاحيّة PRIVILEGES في تعليمة GRANT السابقة. إن هذه الكلمة اختيارية في معظم أنظمة إدارة قواعد البيانات العلائقية، ويمكن كتابة هذه التعليمة بشكل مكافئ على النحو التالي: mysql> GRANT ALL ON *.* TO 'username'@'localhost' IDENTIFIED BY 'password'; كن منتبهًا مع ذلك، أنّ الكلمة المفتاحيّة PRIVILEGES مطلوبة لمنح امتيازات كهذه عندما يكون وضع Strict SQL مُشغّلًا. حذف مستخدم استخدم الصياغة التالية لحذف اسم مستخدم قاعدة البيانات: mysql> DROP USER IF EXISTS username; لاحظ أن هذا الأمر لا يحذف افتراضيًا أيّة جداول أُنشأت بواسطة المستخدم المحذوف، وقد تؤدي محاولات الوصول إلى جداول كهذه إلى حدوث أخطاء. اختيار قاعدة البيانات يجب أولًا إخبار RDBMS بقاعدة البيانات التي ترغب في إنشائها في MySQL و MariaDB قبل أن تتمكن من إنشاء جدول. استخدم الصياغة التالية للقيام بذلك: mysql> USE database; يجب عليك استخدام الأمر التالي في PostgreSQL لاختيار قاعدة بياناتك المرغوبة: postgres=# \connect database إنشاء جدول تنشئ بنية الأمر التالية جدولًا جديدًا باسم table يحوي عمودين لكل منهما نوع بياناته الخاص: mysql> CREATE TABLE table ( column_1 column_1_data_type, column_2 column_2_data_taype ); حذف جدول نفّذ ما يلي لحذف جدول بالكامل، بما في ذلك جميع البيانات الخاصّة به: mysql> DROP TABLE IF EXISTS table إدخال البيانات في جدول استخدم الصياغة التالية لملء جدول بصف واحد من البيانات (row): mysql> INSERT INTO table ( column_A, column_B, column_C ) VALUES ( 'data_A', 'data_B', 'data_C' ); يمكنك أيضًا ملء جدول بعدة صفوف من البيانات باستخدام أمر واحد، على النحو التالي: mysql> INSERT INTO table ( column_A, column_B, column_C ) VALUES ( 'data_1A', 'data_1B', 'data_1C' ), ( 'data_2A', 'data_2B', 'data_2C' ), ( 'data_3A', 'data_3B', 'data_3C' ); حذف بيانات من جدول استخدم بنية الأوامر التالية لحذف صف من البيانات من جدول. لاحظ أن value يجب أن تكون القيمة الموجودة في العمود المحدد column في الصف الذي تريد حذفه: mysql> DELETE FROM table WHERE column='value'; ملاحظة: إذا لم تُضمّن عبارة WHERE في تعليمة DELETE، كما هو موضّح في المثال التالي، فستُحذف جميع البيانات الموجودة في الجدول، ولكن لن تُحذف الأعمدة أو الجدول نفسه: mysql> DELETE FROM table; تغيير البيانات في جدول استخدم الصياغة التالية لتحديث البيانات الموجودة في الصف المُعطى. لاحظ أنّ عبارة WHERE في نهاية الأمر تُخبر SQL بالصف المطلوب تحديثه. إنّ value هي القيمة الموجودة في column_A المحاذية للصفِ الذي تريد تغييره. ملاحظة: إذا أهملتَ تضمين عبارة WHERE في تعليمة UPDATE، فسيَستبدِل الأمر البيانات الموجودة في كل صف من الجدول. mysql> UPDATE table SET column_1 = value_1, column_2 = value_2 WHERE column_A=value; إضافة عمود ستضيف صياغة الأمر التالية عمودًا جديدًا إلى جدول: mysql> ALTER TABLE table ADD COLUMN column data_type; حذف عمود سيؤدي هذا الأمر إلى حذف عمود من جدول: mysql> ALTER TABLE table DROP COLUMN column; تنفيذ الاستعلامات الأساسيّة استخدم الصياغة التالية لعرض جميع البيانات من عمود واحد من جدول: mysql> SELECT column FROM table; افصلْ بين أسماء الأعمدة بفاصلة للاستعلام عن أعمدة متعددة من نفس الجدول: mysql> SELECT column_1, column_2 FROM table; يمكنك أيضًا الاستعلام عن كل الأعمدة في جدول عن طريق استبدال أسماء الأعمدة بعلامة النجمة (*). تعمل علامات النجمة في SQL كبدائل لتمثيل "الكل": mysql> SELECT * FROM table; استخدام عبارات WHERE يمكنك تضييق نطاق نتائج استعلام عن طريق إلحاق تعليمة SELECT بعبارة WHERE، كما يلي: mysql> SELECT column FROM table WHERE conditions_that_apply; يمكنك على سبيل المثال الاستعلام عن جميع البيانات من صف واحد من خلال صياغة مشابهة لما يلي. لاحظ أن value يجب أن تكون قيمة محفوظة في كل من column المحدّد والصف الذي تريد الاستعلام عنه: mysql> SELECT * FROM table WHERE column = value; العمل مع مُعاملات المقارنة يحدّد مُعامل المقارنة في جملة WHERE كيفيّة مقارنة العمود المحدّد بقيمة ما. فيما يلي بعض معاملات المقارنة الشائعة لـ SQL: = : اختبار المساواة != : اختبار عدم المساواة < : اختبار أقل من > : اختبار أكبر من <= : اختبار أقل من أو يساوي >= : اختبار أكبر من أو يساوي BETWEEN : اختبار فيما إذا كانت القيمة ضمن مجال مُعطى IN : اختبار ما إذا كانت قيمة الصّف مُتضَمّنة في مجموعة من القيم المحدّدة EXISTS : اختبار ما إذا كانت صفوف موجودة، تبعاً للشروط المحدّدة LIKE : اختبار فيما إذا كانت قيمة تتطابق مع سلسلة نصيّة محدّدة IS NULL : اختبار القيم الفارغة IS NOT NULL : اختبار كافّة القيم غير الفارغة "NULL" العمل مع محارف البدل Wildcards يسمح SQL باستخدام محارف البدل wildcard. وهي مفيدة عندما تحاول العثور على مُدخل محدّد في جدول، ولكنك لا تكون متأكدًا تماماً من هذا المُدخل. تعتبر علامات النجمة (*) عناصر بديلة لتمثيل "الكل"، حيث تقوم بالاستعلام كل الأعمدة في جدول: mysql> SELECT * FROM table; تمثل علامات النسبة المئوية (٪) صفراً أو أكثر من محارف غير معروفة. mysql> SELECT * FROM table WHERE column LIKE val%; يُستخدم التسطير السفلي (_) لتمثيل محرف واحد غير معروف: mysql> SELECT * FROM table WHERE column LIKE v_lue; حساب المُدخلات في عمود تُستخدم الدّالة COUNT لإيجاد عدد الإدخالات في عمود محدّد. ستُرجع الصياغة التالية إجمالي عدد القيم الموجودة في column: mysql> SELECT COUNT(column) FROM table; يمكنك تضييق نتائج دالة COUNT من خلال إضافة عبارة WHERE، كما يلي: mysql> SELECT COUNT(column) FROM table WHERE column=value; إيجاد قيمة المعدل في عمود تُستخدم الدّالة AVG لإيجاد المعدل بين القيم الموجودة في عمود محدّد. لاحظ أن دالة AVG ستعمل فقط مع الأعمدة التي تحتوي على قيم رقميّة. وقد تُعيد خطأ أو 0 عند استخدامها على عمود يحمل قيم نصيّة: mysql> SELECT AVG(column) FROM table; إيجاد مجموع القيم في عمود تُستخدم الدّالة SUM لإجمالي مجموع القيم الرقميّة الموجودة في عمود: mysql> SELECT SUM(column) FROM table; كما هو الحال مع دالة AVG، إذا نَفّذتَ الدالة SUM على عمود يحوي قيم نصيّة، فقد تُعيد خطأ أو فقط 0، وذلك اعتمادًا على نظام إدارة قواعد البيانات العلائقية خاصتك. إيجاد القيمة الكبرى في عمود استخدم دالة MAX للعثور على أكبر قيمة رقميّة في عمود أو القيمة الأخيرة أبجديًا : mysql> SELECT MAX(column) FROM table; إيجاد القيمة الصغرى في عمود استخدم الدّالة MIN للعثور على أصغر قيمة رقميّة في عمود أو القيمة الأولى أبجديًا: mysql> SELECT MIN(column) FROM table; فرز النتائج باستخدام عبارات ORDER BY تُستخدم عبارة ORDER BY لفرز نتائج الاستعلام. تُعيد الصياغة التالية للاستعلام القيم من column_1 و column_2 وتُرتّب النتائج حسب القيم الموجودة في column_1 بترتيب تصاعدي، أو بترتيب أبجدي بالنسبة لقيم السلاسل النصيّة: mysql> SELECT column_1, column_2 FROM table ORDER BY column_1; أتبع الاستعلام بـ DESC لتنفيذ نفس الإجراء، ولكن مع ترتيب النتائج بترتيب أبجدي تنازلي: mysql> SELECT column_1, column_2 FROM table ORDER BY column_1 DESC; فرز النتائج باستخدام عبارات GROUP BY تشبه عبارة GROUP BY عبارة ORDER BY، ولكنها تُستخدم لفرز نتائج استعلام يتضمن دالة مُجمِّعة مثل COUNT أو MAX أو MIN أو SUM. ستؤدي الدوال التجميعيّة الموضّحة في القسم السابق بمفردها إلى إرجاع قيمة واحدة فقط. ويمكنك مع ذلك عرض نتائج دالة التجميع المنفّذة على كل قيمة مطابقة في العمود من خلال تضمين عبارة GROUP BY. ستَحسب الصياغة التالية عدد القيم المطابقة في column_2 وتُجمّعها بترتيب تصاعدي أو أبجدي: mysql> SELECT COUNT(column_1), column_2 FROM table GROUP BY column_2; أتبِعْ الاستعلام بـ DESC لتنفيذ نفس الإجراء، ولكن بتجميع النتائج بالترتيب الأبجدي التنازلي: mysql> SELECT COUNT(column_1), column_2 FROM table GROUP BY column_2 DESC; الاستعلام عن جداول متعددة مع عبارات JOIN تستخدم عبارات JOIN لإنشاء مجموعات نتائج تجمع بين صفوف من جدولين أو أكثر. لن تعمل عبارات JOIN إلا إذا كان لكل من الجدولين عمود له اسم ونوع بيانات متطابقان، كما في هذا المثال: mysql> SELECT table_1.column_1, table_2.column_2 FROM table_1 JOIN table_2 ON table_1.common_column=table_2.common_column; هذا مثال على عبارة INNER JOIN. ستقوم INNER JOIN بإرجاع جميع السجلات التي تحتوي على قيم متطابقة في كلا الجدولين، ولكنها لن تعرض أي سجلات لا تحتوي على قيم متطابقة. من الممكن إرجاع كافة السجلات من أحد الجدولين، بما في ذلك القيم التي لا تحتوي على مطابق في الجدول الآخر، وذلك باستخدام عبارة JOIN خارجيّة. تُكتب عبارات JOIN الخارجية إما كـ LEFT JOIN أو RIGHT JOIN. تُرجع عبارة LEFT JOIN كافة السجلات من الجدول "الأيسر" والسجلات المطابقة فقط من الجدول "اليمين". في سياق عبارة JOIN الخارجيّة، يكون الجدول الأيسر هو المشار إليه في جملة FROM، والجدول الأيمن هو أي جدول آخر مشار إليه بعد عبارة JOIN. سيَعرض الاستعلام التالي كل سجل من table_1 وفقط القيم المطابقة من table_2. ستظهر القيم غير المطابقة في table2 كـ NULL في مجموعة النتائج: mysql> SELECT table_1.column_1, table_2.column_2 FROM table_1 LEFT JOIN table_2 ON table_1.common_column=table_2.common_column; إن وظيفة عبارة RIGHT JOIN مماثلة لـ LEFT JOIN، ولكنها تُرجع جميع النتائج من الجدول الأيمن، والقيم المطابقة فقط من الجدول الأيسر: mysql> SELECT table_1.column_1, table_2.column_2 FROM table_1 RIGHT JOIN table_2 ON table_1.common_column=table_2.common_column; دمج تعليمات SELECT متعددة باستخدام عبارات UNION يفيد مُعامل UNION في دمج نتائج تعليمتي SELECT (أو أكثر) في مجموعة نتائج واحدة: mysql> SELECT column_1 FROM table UNION SELECT column_2 FROM table; يمكن بالإضافة إلى ذلك أن تجمع عبارة UNION بين تعليمتي SELECT (أو أكثر) والتي تستعلم عن جداول مختلفة في نفس مجموعة النتائج: mysql> SELECT column FROM table_1 UNION SELECT column FROM table_2; الخلاصة يغطي هذا الدليل بعضًا من الأوامر الأكثر شيوعًا في SQL المُستخدمة لإدارة قواعد البيانات، والمستخدمين، والجداول، والاستعلام عن المحتويات الموجودة في هذه الجداول. ومع ذلك، هناك العديد من تجميعات العبارات والمعاملات والتي تنتج جميعها مجموعات فريدة من النتائج. إذا كنت تبحث عن دليل أكثر شموليّة للعمل مع SQL، فإنّنا نُشجعك على مراجعة Oracle's Database SQL Reference بالإضافة إلى ذلك، إذا كانت هناك أوامر SQL شائعة ترغب في رؤيتها في هذا الدليل، فيرجى طرحها أو تقديم اقتراحات في التعليقات أدناه. ترجمة بتصرّف للمقال How To Manage an SQL Database لصاحبه Mark Drake

في هذا الدرس، ستتعلم كيفية استخدام خُطّافات (Git (Git hooks لأتمتة نشر بيئة الإنتاج لتطبيقات Rails على خادم أوبونتو 14.04 عن بُعد. باستخدام خُطّافات Git ستتمكن من نشر التطبيقات عن طريق دفع التغييرات إلى خادم الإنتاج production server، وبدلًا من أن تقوم بكل شيء يدويًّا (مثل ترحيل قاعدة البيانات) فالاستعانة بأحد أشكال النشر الآلي، مثل خُطّافات Git، سيوفر عليك الكثير من الوقت على المدى الطويل. في هذا الدرس سنستخدم خُطّافGit من نوعpost-receive ، بالإضافة إلىPuma كخادم للتطبيق،Nginx كوكيل عكسي لـ Puma و PostgreSQL كقاعدة بيانات. المتطلبات الأساسية سوف تحتاج صلاحيات مستخدم غير جذري non-root والذي يملك امتيازات مستخدم أساسي superuser على خادم أوبونتو. في هذا المثال، سيكون اسم المستخدم deploy. يمكنك تعلم كيفية فعل ذلك في هذا الدرس: الإعداد الابتدائي لخادوم أوبنتو 14.04. إذا كنت ترغب في النشر دون الحاجة لإدخال كلمة المرور، فتأكد من إعداد مفاتيح SSH. سوف تحتاج إلى تثبيت Ruby على خادمك. إذا لم تكن قد فعلت ذلك سلفًا، يمكنك تثبيته جنبًا إلى جنب مع Rails باستخدام rbenv أو RVM. سوف تحتاج أيضًا إلى تطبيق Rails مُدار في مستودع git على جهازك. إذا لم يكن لديك تطبيق في git، فسوف نقدم لك تطبيقًا بسيطًا كمثال لتعمل عليه. لنبدأ على بركة الله. تثبيت PostgreSQL معظم بيئات Rails تستخدم PostgreSQL كقاعدة بيانات، لذلك عليك تثبيته على خادمك الآن. على خادم الإنتاج، قم بتحديث apt-get: sudo apt-get update ثم قم بتثبيت PostgreSQL بهذه التعليمات: sudo apt-get install postgresql postgresql-contrib libpq-dev إنشاء قاعدة بيانات الإنتاج الخاصة بالمستخدم لإبقاء الأمور بسيطةً، سنسمي قاعدة بيانات الإنتاج الخاصة بالمستخدم بنفس اسم التطبيق خاصتك. على سبيل المثال، إذا كان اسم تطبيقك “appname”، فيجب عليك إنشاء مستخدم PostgreSQL بهذه الطريقة: sudo -u postgres createuser -s appname لتعيين كلمة مرور لقاعدة بيانات المستخدم، ادخُل سطر أوامر PostgreSQL هكذا: sudo -u postgres psql بعد ذلك قم بتعيين كلمة المرور لقاعدة بيانات المستخدم “appname” هكذا: \password appname قم بإدخال كلمة المرور التي تريد ثم قم بتأكيدها. اخرج من سطر أوامر PostgreSQL بهذه التعليمة: \q الآن نحن على استعداد لتزويد تطبيقك بمعلومات الاتصال الخاصة بقاعدة البيانات. إعداد تطبيق Rails على جهاز التطوير خاصتك، ستقوم بإعداد تطبيقك لأجل النشر. اختياري: إنشاء تطبيق Rails إن كان لديك تطبيق Rails جاهز للنشر. فيمكنك تخطي هذا القسم والقيام بالتغييرات المناسبة لاحقًا. أمّا إن لم يكن لديك تطبيق جاهز، فإن الخطوة الأولى هي إنشاء تطبيق Rails جديدة. هذه التعليمات ستنشئ تطبيق Rails جديد تحت اسم “appname” في المجلد الرئيسي. لا تتردد في استبدال “appname” بالاسم الذي تريد: cd ~ rails new appname ثم تحوّل إلى مجلد التطبيق: cd appname لأجل تطبيقنا هذا، سوف نقوم بتوليد سقالة scaffold controller لكي يجد تطبيقنا شيءً ليعرضه: rails generate scaffold Task title:string note:text لنتأكدْ الآن من أن تطبيقنا موجود في مستودعgit . تهيئة Git Repo إن لم يكن تطبيقك موجودًا بالفعل في مستودع git لسبب ما، قم بتهيئته وإجراء إلزام أولي initial commit. قم بالتحوّل إلى مجلد التطبيق. في مثالنا، التطبيق يسمى " appname" وهو موضوع في المجلد الرئيسي home directory: cd ~/appname git init git add -A git commit -m 'initial commit' الآن دعونا نُجهّز تطبيقنا لربط الاتصال بقاعدة بيانات الإنتاج لـ PostgreSQL. تحديث إعدادات قاعدة البيانات تحوّل إلى مجلد تطبيقك إن لم تكن بالفعل هناك. في مثالنا، التطبيق يسمى “appname” وهو موضوع في المجلد الرئيسي home directory: cd ~/appname الآن افتح ملف إعداد قاعدة البيانات في محرر النصوص المفضل لديك: vi config/database.yml اعثر على مقطع الإنتاج production section في إعدادات قاعدة بيانات تطبيقك، وقم باستبداله بمعلومات الاتصال بقاعدة بيانات الإنتاج خاصتك. من المفروض أن يبدو كشيء من هذا القبيل (قم باستبدال القيم عند الاقتضاء): config/database.yml excerpt production: <<: *default host: localhost adapter: postgresql encoding: utf8 database: appname_production pool: 5 username: <%= ENV['APPNAME_DATABASE_USER'] %> password: <%= ENV['APPNAME_DATABASE_PASSWORD'] %> احفظ واخرج. هذا الملف يؤكد على أن بيئة الإنتاج الخاصة بالتطبيق ينبغي أن تستخدم قاعدة بيانات PostgreSQL تحت مُسمّى “appname_production” على المضيف المحلي localhost. لاحظ أنه تم إحالة اسم المستخدم وكلمة مرور قاعدة البيانات إلى متغيرات البيئة environment variables. سنقوم بتحديدها على الخادم في وقت لاحق. تحديث Gemfile إذا لم يكن لدى Gemfile خاصتك المكتبة pg (PostgreSQL adapter gem)، ولم تكن المكتبة Puma مُحددة، فيجب عليك إضافتهما الآن. افتح Gemfile الخاص بتطبيقك في المحرّر المفضل لديك: vi Gemfile أضف الأسطر التالية إلىGemfile : Gemfile excerpt group :production do gem 'pg' gem 'puma' end احفظ واخرج. سيحدد هذا النص البرمجي أن بيئة الإنتاج production environment يجب أن تستخدم المكتبات pgوpuma : إعداد Puma قبل إعداد Puma، يجب عليك أن تتحقق من عدد وحدات المعالجة المركزية التي يملكها خادمك. يمكنك بسهولة فعل ذلك على خادمك بهذه التعليمة: grep -c processor /proc/cpuinfo الآن، على جهاز التطوير خاصتك، قم بإضافة إعدادات Puma إلى الإعداد config/puma.rb . افتح الملف في محرر النصوص: vi config/puma.rb انسخ وألصق هذه الإعدادات في الملف: config/puma.rb # Change to match your CPU core count workers 2 # Min and Max threads per worker threads 1, 6 app_dir = File.expand_path("../..", __FILE__) shared_dir = "#{app_dir}/shared" # Default to production rails_env = ENV['RAILS_ENV'] || "production" environment rails_env # Set up socket location bind "unix://#{shared_dir}/sockets/puma.sock" # Logging stdout_redirect "#{shared_dir}/log/puma.stdout.log", "#{shared_dir}/log/puma.stderr.log", true # Set master PID and state locations pidfile "#{shared_dir}/pids/puma.pid" state_path "#{shared_dir}/pids/puma.state" activate_control_app on_worker_boot do require "active_record" ActiveRecord::Base.connection.disconnect! rescue Ac-tiveRecord::ConnectionNotEstablished Ac-tiveRecord::Base.establish_connection(YAML.load_file("#{app_dir}/config/database.yml")[rails_env]) end قم بتغيير العددworkers إلى عدد وحدات المعالجة المركزية لخادمك. يفترض المثال أن لديك اثنان. احفظ واخرج. الآن تم إعداد Puma بموضعlocation تطبيقك وموضع مقبسه socket والمذكرات logs ومعرّفات العمليات PIDS. لا تتردد في تعديل الملف، أو إضافة الخيارات التي تناسبك. ألزمCommit التغييرات الأخيرة: git add -A git commit -m 'added pg and puma' قبل الاستمرار، قم بتوليد المفتاح السري والذي سيتم استخدامه لبيئة الإنتاج الخاصة بتطبيقك: rake secret rake secret sample output: 29cc5419f6b0ee6b03b717392c28f5869eff0d136d8ae388c68424c6e5dbe52c1afea8fbec305b057f4b071db1646473c1f9a62f803ab8386456ad3b29b14b89 سوف تنسخ المُخرجات وتستخدمها لتحديد القيمة SECRET_KEY_BASE الخاصة بتطبيقك في الخطوة التالية. إنشاء النص البرمجي لإطلاق Puma سنقوم بإنشاء نص برمجي للإطلاق (Upstart init script). حتى نتمكن من تشغيل وإيقاف Puma بسهولة، وللتأكد من أنه سيبدأ عند بدء التشغيل. على خادم الإنتاج خاصتك، حمّل أداة Jungle Upstart من مستودع Puma على GitHub وضعها في المجلد الرئيسي: cd ~ wget https://raw.githubusercontent.com/puma/puma/master/tools/jungle/upstart/puma-manager.conf wget https://raw.githubusercontent.com/puma/puma/master/tools/jungle/upstart/puma.conf الآن افتح الملف puma.conf حتى تتمكن من تحرير إعدادات النشر الخاصة بمستخدمPuma : vi puma.conf ابحث عن السطرين الذين يحددان setuid و setgid، و قم باستبدال “apps” باسم النشر الخاص بالمستخدم أو المجموعة خاصتك. على سبيل المثال، إذا كان اسم مستخدم النشر “deploy”، فينبغي أن تكون الأسطر هكذا: puma.conf excerpt 1 of 2 setuid deploy setgid deploy الآن ابحث عن السطر الذي يحتوي:exec /bin/bash <<'EOT'. أضف الأسطر التالية تحته، وتأكد من استبدال اسم المستخدم وكلمة المرور الخاصة ب PostgreSQL، وأضف كذلك rake secret الذي قمت بإنشائه سابقًا: puma.conf excerpt 2 of 2 export APPNAME_DATABASE_USER='appname' export APPNAME_DATABASE_PASSWORD='appname_password' export SECRET_KEY_BASE='rake_secret_generated_above' احفظ واخرج. الآن انسخ النصوص في مجلد خدمات الإطلاق Upstart services: sudo cp puma.conf puma-manager.conf /etc/init النص البرمجي puma-manager.conf يُحدد /etc/puma.conf كمرجع لمعرفة التطبيقات التي يجب إدارتها. دعونا ننشئ ونحرّر هذا الملف الآن: sudo vi /etc/puma.conf كل أسطر هذا الملف يجب أن تتضمن مسارات التطبيقات التي تريد من Puma أن يُديرها. سنقوم بنشر تطبيقنا في مجلد يُسمى “appname” داخل المجلد الرئيسي. في هذا المثال، سيكون كما يلي (تأكد من تعديل المسار ليتناسب مع المكان الذي يتواجد فيه تطبيقك): /etc/puma.conf /home/deploy/appname احفظ واخرج الآن تمّ إعداد تطبيقك لينطلق عند بدء التشغيل بمساعدة Upstart, وهذا يعني أن تطبيقك سيبدأ حتى بعد إعادة إقلاع خادمك. لا تنسى أننا لم ننشر التطبيق حتى الآن، لذلك لسنا جاهزين لتشغيله بعد. تثبيت وإعداد Nginx لجعل التطبيق متاحًا على شبكة الإنترنت، يجب أن تستخدم Nginx كخادم. قم بتثبيت Nginx باستخدام apt-get: sudo apt-get install nginx الآن افتح كتلة الخادم الافتراضي default server block بمحرر النصوص: sudo vi /etc/nginx/sites-available/default استبدل محتويات الملف بالتعليمات البرمجية التالية. تأكد من استبدال الأجزاء الملوّنة باسم المستخدم واسم التطبيق المناسبين. /etc/nginx/sites-available/default upstream app { # Path to Puma SOCK file, as defined previously server unix:/home/deploy/appname/shared/sockets/puma.sock fail_timeout=0; } server { listen 80; server_name localhost; root /home/deploy/appname/public; try_files $uri/index.html $uri @app; location @app { proxy_pass http://app; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_redirect off; } error_page 500 502 503 504 /500.html; client_max_body_size 4G; keepalive_timeout 10; } احفظ واخرج. سيقوم هذا النص البرمجي بإعداد Nginx كوكيل عكسي، لذلك طلبات HTTP ستُرسل إلى الخادم Puma عبر مقبس يونيكس Unix socket. لا تتردد في إجراء التغييرات التي تراها مناسبةً. لن نقوم بإعادة تشغيل Nginx, فالتطبيق غير موجود بعدُ على الخادم. سنقوم بإعداد التطبيق فيما يلي. إعداد مستودع الإنتاج (git (Prepare Production Git Remote على خادم الإنتاج، قم بتثبيت git بواسطة apt-get: sudo apt-get install git ثم قم بإنشاء مجلد للمستودع البعيد remote repository. سنقوم بإنشاء مجلد git أوّلي في المجلد الرئيسي وسنسميه “appname_production”. يمكنك تسمية المستودع البعيد كما تريد (ولكن لا تضعه في ~/appnameلأنه المكان الذي سننشر فيه التطبيق): mkdir ~/appname_production cd ~/appname_production git init –bare بما أن هذا المستودع أوّلي، فلا يوجد مجلّد عمل بعدُ وجميع الملفات الموجودة في .git موجودة في المجلد الرئيسي نفسه. نحن بحاجة إلى إنشاء خُطّاف git من نوعpost-receive ، والذي هو النص البرمجي الذي سيتم تشغيله عندما يتلقى خادم الإنتاج دفعةً من git(git push). افتح الملف hooks/post-receive في محرر النصوص: vi hooks/post-receive انسخ وألصق النص التالي في الملف post-receive: hooks/post-receive #!/bin/bash GIT_DIR=/home/deploy/appname_production WORK_TREE=/home/deploy/appname export APPNAME_DATABASE_USER='appname' export APPNAME_DATABASE_PASSWORD='appname_password' export RAILS_ENV=production . ~/.bash_profile while read oldrev newrev ref do if [[ $ref =~ .*/master$ ]]; then echo "Master ref received. Deploying master branch to produc-tion..." mkdir -p $WORK_TREE git --work-tree=$WORK_TREE --git-dir=$GIT_DIR checkout -f mkdir -p $WORK_TREE/shared/pids $WORK_TREE/shared/sockets $WORK_TREE/shared/log # start deploy tasks cd $WORK_TREE bundle install rake db:create rake db:migrate rake assets:precompile sudo restart puma-manager sudo service nginx restart # end deploy tasks echo "Git hooks deploy complete" else echo "Ref $ref successfully received. Doing nothing: only the mas-ter branch may be deployed on this server." fi done تأكد من تحديث القيم التالية: GIT_DIR :مجلد المستودع الأولي لـ (git (bare git repository الذي قمت بإنشائه في وقت سابق WORK_TREE : المجلد حيث تريد نشر تطبيقك (يجب أن يتطابق مع الموضع الذي قمت بتحديده في إعدادات Puma) APPNAME_DATABASE_USER :اسم مستخدم PostgreSQL (ضروري لمهام rake ) APPNAME_DATABASE_PASSWORD : كلمة مرور PostgreSQL (ضروري لمهام rake ) بعد ذلك، يجب عليك مراجعة التعليمات الموجودة بين التعليقين # start deploy tasks و # end deploy tasks. هذه هي التعليمات التي سيتم تشغيلها في كل مرة يتم دفع push الشعبة الرئيسية master branch إلى مستودع الإنتاج في(git (appname_production. إذا تركتها كما هي، فسيحاول الخادم القيام بما يلي بالنسبة لبيئة الإنتاج الخاصة بتطبيقك: تشغيل المُحزّم bundler إنشاء قاعدة بيانات ترحيل قاعدة البيانات الترجمة الأوليةPrecompile للأصول assets إعادة تشغيل Puma إعادة تشغيل Nginx إذا كنت ترغب في إجراء أية تغييرات أو أي إضافات للتحقق من الأخطاء، لا تتردد في القيام بذلك. بمجرد الانتهاء من مراجعة النص البرمجي احفظه واخرج. بعد ذلك، اجعل البرنامج النصي قابلًا للتنفيذ: chmod +x hooks/post-receive Sudo بلا كلمة مرور Passwordless Sudo لأن الخُطّاف post-receive يحتاج إلى تشغيل تعليماتsudo ، فسنسمح للمستخدم deploy باستخدام sudo بدون كلمة مرور(استبدل اسم المستخدمdeploy في حال اخترت اسمًا مختلفًا): sudo sh -c 'echo "deploy ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/90-deploy' هذا سيسمح للمستخدم deploy بتشغيل التعليمة sudo دون الحاجة لإعطاء كلمة المرور. ربما تريد أن تُقيّد التعليمات التي يمكن للمستخدمdeploy القيام بها. وكحد أدنى، عليك استخدام مفتاح المصادقة SSH كما عليك تعطيل المصادقة بكلمة المرور password authentication. إضافة Production Git Remote الآن بعد أن أعددنا كل شيء لخادم الإنتاج، دعونا نضيف production git remote لمستودع التطبيق خاصتنا. على جهاز التطوير خاصتك، تأكد من أنك في مجلد التطبيق: cd ~/appname ثم قم بإضافة مستودع git بعيد (git remote) جديد تحت اسم “production” والذي يشير إلى مستودع git الأولي appname_production الذي أنشأته على خادم الإنتاج. استبدل اسم المستخدم (deploy) وعنوان الـ IP الخاص بالخادم واسم المستودع البعيد (appname_production): git remote add production deploy@production_server_public_IP:appname_production لقد صار تطبيقك الآن جاهزًا للنشر بواسطة git push. النشر للإنتاج Deploy to Production بعد كل الإعدادات التي قمنا بها، يمكنك الآن نشر تطبيقك على الخادم خاصتك عن طريق تشغيل تعليمات git التالية: git push production master هذا سيدفع push شعبتك الرئيسية المحلية local master branch إلى مستودع الإنتاج البعيد production remote الذي قمت بإنشائه سابقًا. عندما يتلقى production remote أمر الدفع، فسينفّذ النصَّ البرمجي post-receive الذي أعددناه في وقت سابق. إذا قمت بكل شيء بشكل صحيح، فيجب أن يكون تطبيقك متاحًا الآن على عنوان الـ IP العام لخادم الإنتاج خاصتك. إذا كنت تستخدم التطبيق التعليمي لهذا الدرس، فمن المفروض أن تكون قادرًا على الوصول إلى http://production_server_IP/tasks من أيّ متصفح و من المفروض أن ترى شيئًا من هذا القبيل: الخلاصة في أي وقت تقوم بإجراء تغيير على تطبيقك، يمكنك تشغيل نفس التعليمة git push للنشر على خادم الإنتاج خاصتك. هذا لوحده من المفروض أن يوفر عليك الكثير من الوقت على مدى عمر المشروع. لقد شمل هذا الدرس فقط الخطّافات من نوع “post-receive”، ولكن هناك عدة أنواع أخرى من الخطّافات التي يمكن أن تساعدك على تحسين أتمتة عملية النشر. ترجمة -وبتصرّف- للمقال How To Deploy a Rails App with Git Hooks on Ubuntu 14.04 لصاحبه Mitchell Anicas

چانجو هو إطار عمل مرن يستخدم ﻹنشاء تطبيقات بلغة بايثون، وهذه التطبيقات مُجهزة تلقائيًا لتخزين البيانات في ملف قاعدة بيانات SQLite خفيف ويعمل بشكل جيد في الاستعمالات العادية والصغيرة، لكن استخدام نظام إدارة قواعد بيانات تقليدي سيطوِّر أداء التطبيق تحت ضغط زيادة المستخدمين أو زيادة حجم البيانات. وسنستعرض في هذا الدليل كيفية تثبيت وتهيئة PostgreSQL لاستخدامها مع تطبيقات Django، وسنثبّت الحزم اللازمة وننشئ اعتماديات قاعدة البيانات للتطبيق، ثم نبدأ مشروع Django جديد ونجهّزه ليستخدم هذه اﻹعدادات. المتطلبات خادم يعمل بتوزيعة ديبيان جنو/لينكس إصدار 8 “Jessie” مع مستخدم -غير الجذر- له صلاحية sudo. تثبيت الحزم من مستودعات ديبيان سنثبّت أولًا pip -مدير حزم بايثون- لتثبيت وإدارة حزم بايثون، وسنثبّت أيضًا برنامج قاعدة البيانات والمكتبات اللازمة للتفاعل معهم. يحتاج إصدار بايثون 2 و3 إلى حزم مختلفة قليلًا عن بعضها، لذا اختر الأوامر التي تتوافق مع إصدار بايثون لديك. انسخ الأوامر التالية إن كنت تستخدم بايثون 2: $ sudo apt-get update $ sudo apt-get install python-pip python-dev libpq-dev postgresql postgresql-contrib وهذه إن كنت تستخدم بايثون 3: $ sudo apt-get update $ sudo apt-get install python3-pip python3-dev libpq-dev postgresql postgresql-contrib إنشاء قاعدة البيانات والمستخدم الخاص بها يستخدم Postgres نظام توثيق للاتصالات المحلية اسمه “توثيق النِّدّ Peer Authentication”. وهذا يعني أنه إذا كان اسم المستخدم في نظام التشغيل يطابق اسم Postgres صالح، فإن هذا المستخدم يمكنه الولوج دون الحاجة إلى توثيق. وقد أُنشئ مستخدم للنظام اسمه postgres ليتوافق مع مستخدم postgres المدير لنظام PostgreSQL، وسنحتاج هذا المستخدم لتنفيذ مهام إدارية، ويمكننا أيضًا أن نستخدم sudo وندخل اسم المستخدم من خلال لاحقة u-. سجل الدخول إلى جلسة Postgres تفاعلية عبر كتابة الأمر التالي: $ sudo -u postgres psql وسننشئ أولًا قاعدة بيانات لمشروع Django، ويجب أن يكون لكل مشروع قاعدة البيانات الخاصة به للدواعي الأمنية. وسنسمّي قاعدة البيانات في هذا المقال باسم myproject، لكن من اﻷفضل طبعًا أن تختار اسمًا يصلح لمشروع حقيقي. postgres=# CREATE DATABASE myproject; سيكون الخرج هكذا: CREATE DATABASE أنشئ مستخدمًا لقاعدة البيانات، وسنستعمله للاتصال بقاعدة البيانات والتفاعل معها، وﻻ تنس أن تستبدل myprojectuser باسم قاعدة البيانات الذي اخترته، وتغيّر password بكلمة سر قوية: postgres=# CREATE USER myprojectuser WITH PASSWORD 'password'; سيكون الخرج هكذا: CREATE ROLE واﻵن سنعدّل بعض معاملات الاتصال لهذا المستخدم لتسريع عمليات قاعدة البيانات بما أن القيم الصحيحة لن تضطر إلى أن تمر بعمليات استعلام وضبط في كل مرة يحدث اتصال. فسنضبط الترميز الافتراضي على UTF-8 وهو الترميز الافتراضي الذي يتوقعه Django. وسنضبط القاعدة الافترضية لعزل التعاملات “default transactio isolation scheme” على read committed، والتي تحظر القراءة من التعاملات غير المرسلة “uncommitted transactions”. وأخيرًا، سنضبط المنطقة الزمنية الافتراضية لمشاريع Django على UTC. وهذه الإعدادات يُنصح بها في التوثيق الرسمي لمشروع Django، دعنا نكتب ذلك الآن: postgres=# ALTER ROLE myprojectuser SET client_encoding TO 'utf8'; postgres=# ALTER ROLE myprojectuser SET default_transaction_isolation TO 'read committed'; postgres=# ALTER ROLE myprojectuser SET timezone TO 'UTC'; ويكون الخرج هكذا: ALTER ROLE ALTER ROLE ALTER ROLE وكل ما نحتاجه الآن هو إعطاء مستخدم قاعدة البيانات صلاحيات الوصول لقاعدة البيانات التي أنشأناها للتو: postgres=# GRANT ALL PRIVILEGES ON DATABASE myproject TO myprojectuser; ويكون الخرج هكذا: GRANT اخرج الآن من محث SQL: postgres=# \q يجب أن تعود الطرفية بك الآن إلى جلسة shell السابقة. تثبيت Django في بيئة افتراضية يمكننا تثبيت Django الآن بما أن قاعدة بياناتنا قد صارت جاهزة، وسنثبته وكل اعتمادياته داخل بيئة بايثون افتراضية لتحقيق مرونة أكثر، وستتيح لنا حزمة virtualenv إنشاء هذه البيئات بسهولة. اكتب هذا السطر في الطرفية لتثبيت virtualenv إن كنت تستخدم Python 2: $ sudo pip install virtualenv وهذا إن كنت تستخدم Python 3: $ sudo pip3 install virtualenv أنشئ مجلدًا جديدًا باسم مشروعك (استبدل اسم مشروعك بـ myproject الذي اخترناه هنا لغرض المثال فقط)، ثم انتقل داخله: $ mkdir ~/myproject $ cd ~/myproject اكتب السطر التالي لإنشاء بيئة افتراضية لتخزين متطلبات بايثون لمشروع Django الخاص بنا: $ virtualenv venv وذلك سيثبّت نسخة محلية من بايثون وأمر pip محلي داخل مجلد اسمه venv داخل مجلد مشروعك. نحتاج الآن إلى تفعيل البيئة الافتراضية قبل تثبيت البرامج داخلها، ويمكننا فعل ذلك عبر الأمر التالي: $ source venv/bin/activate سيتغير المحثّ الآن ليشير إلى أنك تعمل الآن داخل بيئة افتراضية وسيبدو شبيهًا بهذا: (venv)user@host:~/myproject$ ويمكننا الآن تثبيت Django باستخدام pip، ثم سنثبت psycopg2 التي ستتيح لنا استخدام قاعدة البيانات التي أعددناها: (venv) $ pip install django psycopg2 يمكننا الآن أن نبدأ مشروع Django داخل مجلد المشروع (myproject في حالتنا)، وسينشئ هذا مجلدًا فرعيًا بنفس اسم مجلد المشروع ليحتوي الشفرة البرمجية، إضافة إلى مخطوطة إدارية “management script” داخل المجلد الحالي: (venv) $ django-admin.py startproject myproject . ملاحظة: تأكد من إضافة النقطة في نهاية الأمر السابق، فنحن ﻻ نحتاج مستوىً فرعيًا آخر في المجلد بما أننا أنشأنا مجلدًا أبًا للمشروع “parent directory” ليحتوي مجلد البيئة الوهمية، وهو ما كان سيحدث لو لم نضع النقطة في نهاية سطر الأوامر السابق. يجب أن تكون هيكلة مجلدك الحالي شبيهة بهذا: . └── ./myproject/ ├── manage.py ├── myproject/ │ ├── __init__.py │ ├── settings.py │ ├── urls.py │ └── wsgi.py └── venv/ └── . . . وكما ترى فإن لدينا مجلدًا أبًا للمشروع يحتوي مخطوطة manage.py، ومجلد داخلي للمشروع، ومجلد البيئة الوهمية venv الذي أنشأناه قبل قليل. ضبط إعدادات قاعدة بيانات Django سنضبط الآن مشروعنا كي نستخدم قاعدة البيانات التي أنشأناها، افتح ملف الإعدادات الرئيسية لمشروع Django الموجود في المجلد الفرعي للمشروع: (ملاحظة: استبدل مشروعك بـmyproject) (venv) $ nano ~/myproject/myproject/settings.py قد تحتاج أيضًا إلى تعديل تعليمة ALLOWED_HOSTS قبل إعداد قاعدة البيانات، وتلك التعليمةتحدد قائمة عناوين أو أسماء نطاقات مسموح باستخدامها للاتصال مع مشروع Django، فأي طلب اتصال بترويسة HOST ليس في هذه القائمة سيتم اعتراضه. ويتطلّب Django أن تعدّل هذه التعليمة كي يمنع فئة معينة من الاختراقات الأمنية. ولتعديل هذه التعليمة، أدخل -بين قوسين مربعيْن- عناوين IP أو أسماء النطاقات المرتبطة بخادم Django الخاص بك ويجب أن يكون كل نطاق أو عنوان IP داخل علامتي تنصيص مفردتيْن، وتفصل بين كل واحد منهم فاصلة “,”. وإن رغبت في الاستجابة لطلبات من نطاق ما إضافة إلى النطاقات الفرعية له فضع نقطة قبله أثناء كتابته. إليك أمثلة تعرض لك الطريقة الصحيحة لصيغة هذه التعليمة، استبدل النطاقات وعناوين الـ IP التي تريدها بالأمثلة الموجودة هنا: . . . # أبسط حالة: اكتب العناوين وأسماء النطاقات لخادم چانجو الخاص بك # ALLOWED_HOSTS = [ 'example.com', '203.0.113.5'] # ابدأ اسم النطاق بنقطة للاستجابة له ولأي نطاق فرعي # ALLOWED_HOSTS = ['.example.com', '203.0.113.5'] ALLOWED_HOSTS = ['your_server_domain_or_IP', 'second_domain_or_IP', . . .] واﻵن ابحث عن قسم DATABASES الذي يبدو كهذا: . . . DATABASES = { 'default': { 'ENGINE': 'django.db.backends.sqlite3', 'NAME': os.path.join(BASE_DIR, 'db.sqlite3'), } } . . . هذا القسم يستخدم SQLite كقاعدة بيانات، ونريد تعديل هذه لكي يستخدم قاعدة بيانات PostgreSQL الخاصة بنا. فأول ما نفعله هو تغيير المحرك كي يستخدم محوّل postgresql_psycopg2 بدلًا من sqlite3، ثم نستخدم اسم قاعدة بياناتنا (myproject في مثالنا) في خانة NAME، ونضيف بعض بيانات تسجيل الدخول مثل اسم المستخدم وكلمة المرور، والمضيف الذي سيتصل به، وسنضيف خانة Port ونتركها فارغة كي يتم اختيار المنفذ الافتراضي: . . . DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql_psycopg2', 'NAME': 'myproject', 'USER': 'myprojectuser', 'PASSWORD': 'password', 'HOST': 'localhost', 'PORT': '', } } . . . واﻵن احفظ الملف وأغلقه. نقل قاعدة البيانات واختبار مشروعك يمكننا الآن نقل هياكل البيانات -بما أننا أنهينا ضبط إعدادات Django- إلى قاعدة بياناتنا واختبار الخادم، سنبدأ بإنشاء هيكل ابتدائي لقاعدة البيانات بما أننا ﻻ نملك أي بيانات حقيقية بعد: (venv) $ cd ~/myproject (venv) $ ./manage.py makemigrations (venv) $ ./manage.py migrate أنشئ حسابًا إداريًا: (venv) $ ./manage.py createsuperuser وسيطلب منك النظام اختيار اسم لمستخدم هذا الحساب وعنوان بريد وكلمة مرور له. ملاحظة: قبل أن تجرب خادم التطوير، تأكد أن تفتح منفذًا في جدارك الناري، وإن كنت تستخدم جدار ufw، فإن فتح المنفذ المناسب يتم عبر كتابة هذا الأمر: (venv) $ sudo ufw allow 8000 أما إن كنت تستخدم جدار iptables، فإن الأمر الذي تحتاجه يعتمد على اﻹعدادات التي تستخدمها، الأمر التالي يصلح ﻷغلب الإعدادات: (venv) $ sudo iptables -I INPUT -p tcp --dport 8000 -j ACCEPT يمكنك الآن اختبار عمل قاعدة بياناتك بشكل صحيح من خلال بدء تشغيل خادم تطوير Django: (venv) $ ./manage.py runserver 0.0.0.0:8000 اذهب إلى عنوان IP الخاص بالخادم أو اسم النطاق الخاص به متبوعًا بـ 8000: للوصول إلى الصفحة الجذر الافتراضية لـDjango: http://server_domain_or_IP:8000 يجب أن ترى صفحة index الافتراضية: ضع admin/ في نهاية الرابط، يجب أن تكون قادرًا على الوصول لشاشة تسجيل الدخول إلى واجهة التحكم: أدخل اسم المستخدم وكلمة المرور اللتان أنشأتهما قبل قليل باستخدام createsuperuser، فتدخل إلى لوحة التحكم: وبدخولنا للوحة التحكم نكون قد تأكدنا أن قاعدة البيانات قد خزّنت معلومات حساب المستخدم الخاص بنا ويمكننا الدخول إليه دون مشاكل. يمكنك الآن إيقاف الخادم حين تنتهي من تحققك بالضغط على ctrl-c داخل شاشة الطرفية. وإن أردت وسيلة أخرى لاختبار قاعدة البيانات يمكنك الاستعلام داخل قاعدة بيانات Postgres نفسها باستخدام psql، فمثلًا يمكنك الاتصال بقاعدة بيانات مشروعك (myproject) عن طريق المستخدم myprojectuser وإظهار كل الجداول المتاحة بكتابة الأمر التالي: (venv) $ psql -W myproject myprojectuser -h 127.0.0.1 -f <(echo '\dt') لتفصيل اﻷمر السابق، فإنه يجب أن نستخدم ﻻحقة h- من أجل الاتصال بالمضيف المحلي localhost عبر الشبكة لتحديد أننا نريد توثيق كلمة المرور بدلًا من توثيق النّدّ. أما W- فستجعل psql يسألك عن كلمة المرور المناسبة، وf- لتمرير الأمر الوصفي “meta-command” في psql لتنفيذه، وdt\ لعرض كل الجداول في قاعدة البيانات. List of relations Schema | Name | Type | Owner --------+----------------------------+-------+--------------- public | auth_group | table | myprojectuser public | auth_group_permissions | table | myprojectuser public | auth_permission | table | myprojectuser public | auth_user | table | myprojectuser public | auth_user_groups | table | myprojectuser public | auth_user_user_permissions | table | myprojectuser public | django_admin_log | table | myprojectuser public | django_content_type | table | myprojectuser public | django_migrations | table | myprojectuser public | django_session | table | myprojectuser (10 rows) وكما ترى فإن Django قد أنشأ بعض الجداول داخل قاعدة البيانات الخاصة بنا، وهذا يؤكد لنا أن إعداداتنا كانت صحيحة. الخلاصة قد عرضنا في هذا الدليل كيفية تثبيت وإعداد PostgreSQL كقاعدة بيانات في النهاية الخلفية لمشروع Django، إذ تستفيد أغلب المشاريع من استخدام نظم إدارة متطورة لقواعد البيانات، رغم أن SQLite تتعامل بشكل جيد أثناء تطوير المشروع وأثناء الاستخدام الخفيف له. ترجمة -بتصرف- لمقال How To Use Postgresql with your Django Application on Debian 8 لصاحبه Justin Ellingwood.

تزيد أحجام قواعد البيانات مع الوقت حتى تتجاوز أحيانًا المساحة اﻷصلية التي خُصِّصت لها، وقد تواجهك مشاكل في المدخلات والمخرجات I/O إن كانت قاعدة البيانات موجودة في نفس القسم “Partition” الموجود به بقية نظام التشغيل. وسنتعلم في هذا الدليل كيفية نقل مجلد البيانات في نظام PostgreSQL لإدارة قواعد البيانات إلى مكان جديد في حالة كنت تريد إضافة مساحة جديدة أو تبحث في طرق لتحسين الأداء، أو الاستفادة من مزايا التخزين الأخرى التي توفرها أنظمة مصفوفات الأقراص المستقلة RAID، أو عُقّدُ التخزين الشبكية “Network Block Storages”، أو غيرها من الأجهزة وأنظمة التخزين. المتطلبات خادم يعمل بتوزيعة أوبنتو 16.04، عليها مستخدم له صلاحية sudo -انتبه، ليس المستخدم الجذر root-. خادم PostgreSQL، يمكنك قراءة كيفية تثبيت واستخدام PostgreSQL على أوبنتو في هذا المقال. وسننقل البيانات إلى وحدة تخزينية “Block Storage Device” لها نقطة الضم التالية /mnt/volume-nyc1-01. فائدة: تكون اﻷقراص أو اﻷجهزة/الوحدات “Devices”بشكل عام في أنظمة لينكس عبارة عن ملفات، وكل جهاز “قسم/partition من القرص الصلب مثلًا” له نقطة ضم “mount point” يكون فيها محتواه. الخطوة الأولى: نقل مجلد بيانات PostgreSQL سنبدأ جلسة PostgreSQL تفاعلية أولًا كي نتحقق من المكان الحالي للمجلد، وسنستخدم أمر psql للدخول إلى شاشة تفاعلية “interactive monitor”، ثم نضيفu postgres- لتخبر sudo أن ينفِّذ أمر psql كمستخدم postgre. $ sudo -u postgres psql وبمجرد دخولك إلى الشاشة، اطلب عرض مجلد البيانات: postgres=# SHOW data_directory; وسيكون الخرج في حالتنا هكذا: data_directory ------------------------------ /var/lib/postgresql/9.5/main (1 row) ويؤكد هذا الخرج أن PostgreSQL مُعدَّ لاستخدام مجلد البيانات الافتراضي main الموجود في المسار ذي اللون الأحمر بالأعلى، إذًا هذا هو المجلد الذي سننقله. اكتب q\ للخروج بمجرد أن تتأكد من وجود المجلد في النظام. سنوقف PostgreSQL لضمان سلامة البيانات، قبل أن نغيّر شيئًا في مجلد main: $ sudo systemctl stop postgresql ثم نستعلم عن حالة PostgreSQL لنتأكد أنها أُوقِفَت، إذ أن systemctl ﻻ يعرض نتائج أوامر إدارة الخدمات في النظام: $ sudo systemctl status postgresql وتتأكد أنها أوقفت إن كان السطر الأخير في الخرج يقول لك إن الخادم قد توقف: . . . Jul 22 16:22:44 ubuntu-512mb-nyc1-01 systemd[1]: Stopped PostgreSQL RDBMS. والآن، سننسخ مجلد البيانات الحالي إلى مكان جديد باستخدام rsync، مع استخدام لاحقة a- للحفاظ على الصلاحيات وبقية خصائص المجلد، وv- لعرض خرج مفصّل كي تتابع ما يحدث. ملاحظة: تأكد من عدم وجود شرطة مائلة بعد اسم المجلد، والتي قد تضاف تلقائيًا إن استخدمت زر tab لإكمال النصوص، إذ أن rsync سيضع محتوى المجلد في نقطة الضم بدلًا من مجلد محتوي لـ PostgreSQL. سنبدأ rsync من مجلد postgresql من أجل محاكاة هيكل المجلد الأصلي في المكان الجديد، وسنتجنب مشاكل الصلاحيات للترقيات المستقبلية عبر إنشاء مجلد postgresql داخل نقطة الضم “mount point” والإبقاء على ملكيته لمستخدم PostgreSQL. ونحن لا نحتاج هنا إلى مجلد الإصدار 9.5 بما أننا حددنا مكان المجلد بوضوح في ملفpostgresql.conf، لكن ﻻ بأس باتباع أسلوب المشروع خاصة إن كانت هناك حاجة في المستقبل لتشغيل عدة إصدارات من PostgreSQL: $ sudo rsync -av /var/lib/postgresql /mnt/volume-nyc1-01 وسنعيد تسمية المجلد الحالي مع امتداد bak. ونبقي عليه حتى نتأكد أن النقل تم بنجاح، ونحن نعيد تسميته من أجل تجنب أي لبس قد يحدث من ملفات موجودة في كلا من المكان القديم والجديد: $ sudo mv /var/lib/postgresql/9.5/main /var/lib/postgresql/9.5/main.bak وبهذا نكون جاهزين لننتقل إلى ضبط إعدادات PostgreSQL. الخطوة الثانية: التوجيه إلى المكان الجديد للبيانات تُضبط القيمة الافتراضية لـ data_directory في إعدادات PostgreSQL على أنه موجود في هذا المسار: /var/lib/postgresql/9.5/main وتوجد هذه الإعدادات في ملف postgresql.conf، وسنغيّر الآن تلك الإعدادات لنضع المكان الجديد لمجلد البيانات: $ sudo nano /etc/postgresql/9.5/main/postgresql.conf ابحث عن السطر الذي يبدأ بكلمة data_directory وغيّر مساره إلى المسار الموجود فيه المجلد الجديد، وفي حالتنا فإن هذا السطر يجب أن يبدو هكذا بعد تغيير المسار: . . . data_directory = '/mnt/volume-nyc1-01/postgresql/9.5/main' . . . الخطوة الثالثة: إعادة تشغيل PostgreSQL نحن الآن جاهزون لتشغيل PostgreSQL، الصق الأمر الأول لتشغيله، والثاني لمعرفة حالته: $ sudo systemctl start postgresql $ sudo systemctl status postgresql افتح شاشة PostgreSQL التفاعلية: $ sudo -u postgres psql اطلب عرض قيمة data_directory لنتأكد أن مجلد البيانات الجديد هو المستخدَم الآن: postgres=# SHOW data_directory; يجب أن يكون الخرج هكذا في حالتنا: data_directory ----------------------------------------- /mnt/volume-nyc1-01/postgresql/9.5/main (1 row) وننتهز هذه الفرصة بما أننا أعدنا تشغيل PostgreSQL وتأكدنا أنه يستخدم المكان الجديد، كي نتأكد أن قاعدة البيانات تعمل بكفاءة. احذف مجلد البيانات الاحتياطي -القديم- بمجرد أن تتأكد من سلامة أي بيانات موجودة مسبقًا: $ sudo rm -Rf /var/lib/postgresql/9.5/main.bak أعد تشغيل PostgreSQL مرة أخيرة للتأكد من أنها تعمل كما يجب: $ sudo systemctl start postgresql $ sudo systemctl status postgresql الخلاصة يجب أن تستخدم قاعدةُ بياناتك الآن المجلدَ الجديد في المكان الذي اخترتَه له، وهذا يعني أنك تستطيع الآن زيادة حجم قاعدة البيانات بما أنك نقلتها من المكان القديم ذي المساحة المحدودة. ترجمة -بتصرف- لمقال How To Move a PostgreSQL Data Directory to a New Location on Ubuntu 16.04 لصاحبته Melissa Anderson

PostgreSQL، هو نظام متطور مفتوح المصدر، كائنيّ الارتباط-Object Relational ﻹدارة قواعد البيانات، وهو نظام قابل للتوسع، بمعنى أنه يستطيع معالجة اﻷحمال المختلفة بدءًا من تطبيقات جهاز واحد إلى خدمات الويب التجارية التي تتعامل مع مستخدمين كثر في نفس الوقت. وهذا النظام Transactional أي يعامل النقل المتسلسل للبيانات -مثل تحديث قاعدة البيانات- كوحدة واحدة لضمان سلامتها، ويحقق خصائص ACID (Atomicity – Consistency – Isolation – Durability). وكذلك يدعم قسمًا كبيرًا من معايير SQL. فائدة: خصائص ACID هي أربعة خصائص يجب توافرها في تعاملات قواعد البيانات، وهي الذرية-Atomicity -أن تُنفَّذ العملية كوحدة واحدة-، والتناسق-Consistency، والعزل-Isolation، والثبات-Durability. ويوفر PostgreSQL العديد من المزايا مثل: الاستعلامات المعقدة-Complex Queries المفاتيح الأجنبية-Foreign Keys المشاهدات القابلة للتحديث-Updatable Views سلامة عمليات نقل البيانات-Transactional Integrity التحكم في التزامن متعدد الإصدارات-Multiversion Concurrency Control وذكرنا قبل قليل أنه قابل للتمدد والتوسع بواسطة مستخدميه عبر إضافة دوال-Functions جديدة، ومشغّلات-operators، وأنواع بيانات، وطرق فهرسة، ولغات إجرائية-Procedural Languages. ويقدّم PostgreSQL طرقًا عديدة لتكرار قاعدة بيانات، وسنتعلم في هذا الدليل كيفية إعداد تكرار من نوع (الرئيسي-Master/الثانوي-Slave)، وهي عملية مزامنة بين قاعدتي بيانات من خلال النسخ من قاعدة بيانات على خادم (الرئيسي) إلى قاعدة بيانات أخرى في خادم آخر (الثانوي)، وسننفذ هذه العملية على خادم يعمل بتوزيعة أوبنتو 16.04. المتطلبات أن يكون PostgreSQL 9.6 مثبتًا على خادم أوبنتو 16.04 إعداد UFW ثبّت جدار الحماية الناري غير المعقّد-Uncomplicated Firewall على خوادم أوبنتو، وهو أداة ﻹدارة جدار الحماية المعتمِد على iptables. استخدم الأمر التالي في الطرفية: # apt-get install -y ufw واﻵن، أضف PostgreSQL وخدمة SSH إلى جدار الحماية، عبر تنفيذ اﻷمر التالي: # ufw allow ssh # ufw allow postgresql فعّل جدار الحماية: # ufw enable إعداد خادم PostgreSQL الرئيسي سيمتلك الخادم الرئيسي صلاحيات القراءة والكتابة لقاعدة البيانات، وسيكون هو القادر على نقل البيانات إلى الخادم الثانوي. • افتح محررًا نصيًا وعدّل إعدادات PostgreSQL الرئيسية كما يلي: (ملاحظة: استبدل EDITOR$ بالمحرر النصي الذي تفضّله) # $EDITOR /etc/postgresql/9.6/main/postgresql.conf أزل التعليق (#) من سطر listen_addresses وأضف عنوان IP للخادم الرئيسي: listen_addresses = 'master_server_IP_address' واﻵن، أزل التعليق من سطر wal_level لتغيير قيمته: wal_level = hot_standby وأزل التعليق من السطر التالي كي تستخدم المزامنة المحلية-Local Syncing لمستوى المزامنة "Synchronization Level" synchronous_commit = local ثم أزل التعليق من السطرين التاليين، وعدلهما كما يلي، بما أننا نستخدم خادمين: max_wal_senders = 2 wal_keep_segments = 10 واﻵن احفظ الملف وأغلقه. عدّل ملف pg_hba.conf من أجل إعدادات التوثيق-Authentication، كما يلي: افتح الملف عبر هذا الأمر: # $EDITOR /etc/postgresql/9.6/main/pg_hba.conf الصق الإعدادات التالية: # Localhost host replication replica 127.0.0.1/32 md5 # PostgreSQL Master IP address host replication replica master_IP_address/32 md5 # PostgreSQL SLave IP address host replication replica slave_IP_address/32 md5 احفظ الملف وأغلقه، ثم أعد تشغيل PostgreSQL باستخدام systemctl # systemctl restart postgresql إنشاء مستخدم من أجل التكرار سننشئ مستخدم PostgreSQL من أجل عملية التكرار، فسجّل الدخول أولًا إلى حساب المستخدم المسمّىpostgres وافتح صدفة PostgreSQL، من خلال الأوامر التالية: # su - postgres $ psql أنشئ مستخدمًا جديدًا: postgres=# CREATE USER replica REPLICATION LOGIN ENCRYPTED PASSWORD 'usr_strong_pwd'; أغلق الصَّدَفة، وهكذا تنتهي إعدادات الخادم الرئيسي. إعداد الخادم الثانوي لن تكون للخادم الثانوي صلاحيات الكتابة في قاعدة البيانات، وستكون وظيفته الوحيدة هي استقبال البيانات من الخادم الرئيسي، أي ستكون له صلاحية القراءة فقط. • سنوقف أولًا خدمة PostgreSQL: # systemctl stop postgresql افتح ملف الإعدادات الرئيسية لـ PostgreSQL: # $EDITOR /etc/postgresql/9.6/main/postgresql.conf أزل التعليق من سطر listen_addresses وغيّر قيمته: listen_addresses = 'slave_IP_address' أزل التعليق من سطر wal_level وغيّره كما يلي: wal_level = hot_standby وأزل التعليق أيضًا من سطر synchronous_commit كما في الخادم الرئيسي للاستفادة من المزامنة المحلية-local syncing: synchronous_commit = local ثم أزل التعليق من السطرين التاليين وغيّر قيمهما كما يلي: max_wal_senders = 2 wal_keep_segments = 10 أزل التعليق من السطر التالي وغيّر قيمته كما يلي من أجل تفعيل hot_standby للخادم الثانوي: hot_standby = on احفظ الملف وأغلقه. نسخ البيانات من الخادم الرئيسي إلى الثانوي لكي نزامن بيانات الخادم الرئيسي مع الثانوي، فيجب أن يحل المجلد الأساسي “main” في الخادم الرئيسي محل المجلد الرئيسي في الخادم الثانوي، ونفعل هذا كما يلي: • سجل الدخول إلى مستخدم postgres: # su – postgres خذ نسخة احتياطية من مجلد البيانات الفعلي: $ cd/var/lib/postgresql/9.6/ $ mv main main_bak أنشئ مجلد أساسيًا جديدًا: $ mkdir main/ غيّر صلاحياته: $ chmod 700 main وهنا، انسخ المجلد الأساسي من الخادم الرئيسي إلى الخادم الثانوي باستخدام pg_basebackup: # pg_basebackup -h master_IP_address -U replica -D /var/lib/postgresql/9.6/main /-P –xlog وحين ينتهي النسخ، أنشئ ملف recovery.conf داخل المجلد الأساسي "main” وانسخ المحتوى التالي فيه: standby_mode = 'on' primary_conninfo = 'host=10.0.15.10 port=5432 user=replica password=usr_strong_pwd' trigger_file = '/tmp/postgresql.trigger.5432' واﻵن، احفظ الملف وأغلقه، ثم غير صلاحياته كما يلي: # chmod 600 recovery.conf شغّل خدمة PostgreSQL: # systemctl start postgresql وهنا تنتهي إعدادات الخادم الثانوي. الخلاصة لقد رأينا في هذا الدليل المبسّط كيفية ضبط تكرار Master/Slave في PostgreSQL عبر استخدام خادمين يعملان بأوبنتو. وهذه الطريقة في التكرار ما هي إﻻ إحدى طرق عديدة يوفرها نظام PostgreSQL لإدارة قواعد البيانات. ترجمة -بتصرف- لمقال PostgreSQL Replication on Ubuntu Tutorial لصاحبه Giuseppe Molica

تستخدِم محركات البحث تقنية بحث النصوص الكاملة (Full-Text Search (FTS للبحث عن نتائج في قاعدة بيانات ما، وهي تقنية مفيدة في تقوية نتائج البحث في مواقع مثل المتاجر الرقمية ومحركات البحث والجرائد وغيرها. ويتلخص ما تفعله FTS في جلب المستندات “documents” وهي وحدات من قواعد البيانات تحتوي بيانات نصية ﻻ تتطابق بشكل كامل مع نصوص البحث، فمثلًا حين يبحث مستخدم ما عن “cats and dogs” فإن التطبيق المزوّد بـتقنية بحث النصوص الكاملة سيُظهر نتائج تحتوي الكلمتين dogs وcats بشكل منفصل، أو بترتيب معكوس “dogs and cats”، أو صور مختلفة من هذه الكلمات (cat أو dog)، وذلك يعطي أفضلية للتطبيقات في تخمين قصد المستخدم وإظهار نتائج بحث مرتبطة بما يريده وبسرعة أكبر. وتسمح أنظمة إدارة قواعد البيانات مثل PostgreSQL بعمليات بحث نصية بشكل جزئي باستخدام بنود LIKE، لكن هذه العمليات تعطي عادةً أداء دون المستوى مع البيانات الكبيرة، كما أنها مقيَّدة بمطابقة مدخلات المستخدم الحرفية، وهذا يعني أن استعلامًا ما أو بحثًا عن بيانات معينة قد ﻻ يعطي أي نتائج، حتى لو كانت هناك مستندات عن معلومات مرتبطة بهذا البحث. أما باستخدام FTS فيمكنك بناء محرك بحث قوي للنصوص دون الحاجة لاعتماديات جديدة على أدوات أكثر تطورًا، وسنستخدم نظام PostgreSQL في هذا المقال لتخزين بيانات تحتوي مقالات لموقع أخبار افتراضي، ثم نتعلم كيف نبحث في قاعدة البيانات باستخدام FTS، واختيار أفضل النتائج فقط. ثم سنقوم ببعض التحسينات في الأداء لعمليات بحث النصوص الكاملة. المتطلبات خادم مثبت عليه أوبنتو 16.04 به مستخدم يملك صلاحيات `sudo`، ﻻ أن يكون هو المستخدم الجذر. خادمPostgreSQL، وسنستخدم نحن قاعدة بيانات ومستخدم باسم `sammy` كمثال. ملاحظة: تأكد أن يكون لديك حزمة postgresql-conrib عبر تنفيذ الأمر التالي في الطرفية: sudo apt-get list postgresql-contrib الخطوة الأولى: إنشاء بيانات وهمية من أجل الشرح سنحتاج إلى بعض البيانات من أجل استخدامها في اختبار إضافة FTS، لكن إن كان لديك جدول به قيم نصية جاهزة فيمكنك أن تنتقل إلى الخطوة التالية مباشرة وتستبدل قيمك بالقيم الموجودة هنا، أما إن لم يكن لديك فاتبع ما يلي: اتصل بقاعدة بيانات PostgreSQL من خلال الخادم الخاص بها، ولن تحتاج كلمة مرور لأنك تتصل من نفس المضيف “host”: sudo -u postgres psql sammy وهذا الأمر سيفتح جلسة PostgreSQL تفاعلية ظاهر بها اسم قاعدة البيانات الذي نعمل عليها -sammy في حالتنا-، فيجب أن ترى =#sammy في محث قاعدة البيانات. أنشئ جدولًا وسمّه news، وسيمثِّل كل مدخل في هذا الجدول مقالًا بعنوان وجزء من المحتوى والكاتب، إضافة إلى معرّف فريد: sammy=# CREATE TABLE news ( sammy=# id SERIAL PRIMARY KEY, sammy=# title TEXT NOT NULL, sammy=# content TEXT NOT NULL, sammy=# author TEXT NOT NULL sammy=# ); إن نظرنا للجدول السابق، فإن id هو معرّف الجدول الأساسي مع النوع الخاص SERIAL المسؤول عن زيادة هذا المعرف بشكل تلقائي للجدول، وذلك معرّف فريد سنتحدث عنه أكثر في الخطوة الثالثة حين ننظر في تحسينات الأداء. واﻵن أضف بعض البيانات للجدول باستخدام أمر INESRT، ستمثل هذه البيانات الوهمية بالأسفل بعض مقالات الأخبار: sammy=# INSERT INTO news (id, title, content, author) VALUES sammy=# (1, 'Pacific Northwest high-speed rail line', 'Currently there are only a few options for traveling the 140 miles between Seattle and Vancouver and none of them are ideal.', 'Greg'), sammy=# (2, 'Hitting the beach was voted the best part of life in the region', 'Exploring tracks and trails was second most popular, followed by visiting the shops and then checking out local parks.', 'Ethan'), sammy=# (3, 'Machine Learning from scratch', 'Bare bones implementations of some of the foundational models and algorithms.', 'Jo'); سنجرب الآن بعض عمليات البحث بما أننا أدخلنا بعض البيانات التي يمكن البحث والاستعلام عنها. الخطوة الثانية: تجهيز المستندات والبحث فيها أول خطوة هنا هي بناء مستند واحد بأعمدة نصوص متعددة من جدول قاعدة البيانات، ثم يمكننا تحويل النتائج بعدها إلى متَّجَه من الكلمات نستخدمه في عمليات البحث. ملاحظة: يستخدم خرج psql في هذا الدليل تهيئة expanded display والتي تعرض كل عمود من الخرج في سطر جديد لتسهيل عرضها على الشاشة. يمكننا تفعيلها كما يلي: sammydb=# \x يجب أن يكون الخرج هكذا: Expanded display is on. سنحتاج أولًا إلى جمع كل الأعمدة معًا باستخدام دالتي التسلسل `||` والتحويل `()to_tsvector` في PostgreSQL: sammy=# SELECT title || '. ' || content as document, to_tsvector(title || '. ' || content) as metadata FROM news WHERE id = 1; سيخرج لنا هذا أول سجلّ كمستند كامل باﻹضافة إلى نسخته التي سنستخدمها في البحث: -[ RECORD 1 ]----------------------------------------------------- document | Pacific Northwest high-speed rail line. Currently there are only a few options for traveling the 140 miles between Seattle and Vancouver and none of them are ideal. metadata | '140':18 'current':8 'high':4 'high-spe':3 'ideal':29 'line':7 'mile':19 'none':25 'northwest':2 'option':14 'pacif':1 'rail':6 'seattl':21 'speed':5 'travel':16 'vancouv':23 ربما تلاحظ أن هناك كلمات أقل في النسخة المحوّلة metadata في الخرج السابق عن النسخة الأصلية document، وبعض الكلمات مختلفة، وكل كلمة لديها فاصلة منقوطة ; ورقم ملحق بها، وذلك ﻷن دالة ()to_tsvector تنسّق كل كلمة كي نستطيع إيجاد صور مختلفة منها، ثم تصنف النتائج أبجديًا، وذلك الرقم هو موضع الكلمة في document، قد تكون هناك مواضع أخرى للكلمة بينها فواصل , إن كانت الكلمة المنسّقة تظهر أكثر من مرة. يمكننا الآن استغلال إمكانيات FTS عبر استخدام هذا المستند المحوّل في البحث عن كلمة “Explorations”: sammy=# SELECT * FROM news WHERE to_tsvector(title || '. ' || content) @@ to_tsquery('Explorations'); وسنقوم الآن بتحليل الدوال والمشغِّلات التي استخدمناها في اﻷمر أعلاه: تترجم دالةُ ()to_tsquery المعاملَ “parameter” -الذي يمكن أن يكون تعديلًا مباشرًا أو طفيفًا في بحث المستخدم- إلى معيار بحث نصي يقلل المدخلات بنفس طريقة ()to_tsvector. وإضافة إلى ذلك فإن الدالة تتيح لك تحديد اللغة التي تريد استخدامها وما إن يجب أن تكون كل الكلمات موجودة في النتائج أو واحدة منهم فقط. ويحدد مشغِّل @@ ما إن كان tsvector مماثلًا لـ tsquery أم لـ tsvector آخر، عبر عرض إحدى نتيجتين (true أو false)، مما يسهّل استخدامه كجزء من معيار WHERE. الخرج: -[ RECORD 1 ]----------------------------------------------------- id | 2 title | Hitting the beach was voted the best part of life in the region content | Exploring tracks and trails was second most popular, followed by visiting the shops and then checking out local parks. author | Ethan أظهرت عمليةُ البحث المستندَ الذي يحتوي كلمة Exploring، رغم أن الكلمة التي بحثنا عنها هي Exploration، أما لو استخدمنا مشغّل LIKE لكنّا حصلنا على نتيجة فارغة. واﻵن بما أننا عرفنا كيفية تجهيز المستندات لها وكيفية هيكلة المستندات، فسننظر في كيفية تحسين أداء FTS. الخطوة الثالثة: تحسين أداء FTS قد يشكّل توليد مستند في كل مرة نستخدم فيها استعلام FTS مشكلة في الأداء إن كنا نستخدم خوادم صغيرة أو بيانات كبيرة. وأحد الحلول الجيدة لهذا الأمر هو توليد المستند المحوّل أثناء إدخال المستند الأصلي وتخزينه مع البيانات الأخرى، وبهذه الطريقة يمكننا استرجاعه باستعلام صغير عوضًا عن توليده في كل مرة. أولًا ننشئ عمودًا إضافيًا اسمه document في جدول news الذي أنشأناه قبل قليل: sammy=# ALTER TABLE news ADD "document" tsvector; سنحتاج الآن أن نستخدم استعلامًا جديدًا ﻹدخال البيانات في الجدول، لكن على عكس الخطوة الثانية، سنحتاج هنا إلى تجهيز المستند المحوّل وإضافته إلى عمود document الجديد: sammy=# INSERT INTO news (id, title, content, author, document) sammy=# VALUES (4, 'Sleep deprivation curing depression', 'Clinicians have long known that there is a strong link between sleep, sunlight and mood.', 'Patel', to_tsvector('Sleep deprivation curing depression' || '. ' || 'Clinicians have long known that there is a strong link between sleep, sunlight and mood.')); تتطلب إضافة عمود جديد إلى الجدول الموجود مسبقًا أن نضيف قيمًا فارغة لعمود document أولًا، وسنحدّثه الآن بالقيم المولَّدة. استخدم أمر UPDATE لإضافة البيانات الناقصة. sammy=# UPDATE news SET document = to_tsvector(title || '. ' || content) WHERE document IS NULL; وهذه الأسطر التي أضفناها إلى جدولنا تحسّن من أداء FTS، لكن قد نواجه مشاكل أخرى في حالة البيانات الكبيرة بسبب أن قاعدة البيانات ﻻ تزال في حاجة إلى فحص الجدول كله ﻹيجاد الأسطر التي توافق مدخلات البحث، وحل هذا أن نستخدم الفهارس “indexes”. فهرس قاعدة البيانات database index هو هيكل بيانات يخزّن البيانات بشكل منفصل من البيانات الأساسية التي تحسّن عمليات استرجاع البيانات، ويتم تحديثها بعد أي تغيّر في محتوى الجدول وﻻ تتكلف إﻻ الكتابة الجديدة ومساحة تخزين صغيرة نسبيًا. وتسمح المساحة الصغيرة وهيكل البيانات المهيّأ جيدًا للفهارس أن تعمل بكفاءة أكبر من استخدام مساحة الجدول لاختيار الاستعلامات. وبشكل عام، فإن الفهارس تسرّع إيجاد قواعد البيانات للصفوف من خلال البحث باستخدام خوارزميات وهياكل بيانات خاصة. ويمتاز نظام PostgreSQL بأن به عدة أنواع من الفهارس التي تناسب أنواعًا محددة من الاستعلامات، وأقرب هذه الأنواع إلى حالتنا هنا هي فهارس GiST وGIN. والفرق البارز بينهما هو السرعة التي يجلب كل منهما البيانات من الجدول، فـGIN أبطأ أثناء إضافة بيانات جديدة لكنه أسرع في الاستعلام، أما GiST فأسرع في بناء البيانات الجديدة لكنه يحتاج إلى قراءات إضافية للبيانات. وسننشئ فهرس GIN هنا ﻷن GiST أبطأ بثلاث مرات في جلب البيانات: sammy=# CREATE INDEX idx_fts_search ON news USING gin(document); وسيصبح استعلام SELECT أبسط باستخدام عمود document المفهرس: sammy=# SELECT title, content FROM news WHERE document @@ to_tsquery('Travel | Cure'); ويجب أن يكون الخرج شيئًا كهذا: -[ RECORD 1 ]----------------------------------------------------- title | Sleep deprivation curing depression content | Clinicians have long known that there is a strong link between sleep, sunlight and mood. -[ RECORD 2 ]----------------------------------------------------- title | Pacific Northwest high-speed rail line content | Currently there are only a few options for traveling the 140 miles between Seattle and Vancouver and none of them are ideal. واﻵن يمكنك الخروج من لوحة التحكم الخاصة بقاعدة البيانات عبر كتابة q\. الخلاصة يغطي هذا الدليل كيفية استخدام تقنية بحث النصوص الكاملة في PostgreSQL، بما في ذلك تجهيز وتخزين مستند البيانات الوصفية metadata واستخدام فهرس لتحسين أداء البحث. وإن أردت مزيدًا من الشرح حول FTS في PostgreSQL فألق نظرة على التوثيق الرسمي لنظام PostgreSQL حول بحث النصوص الكاملة. ترجمة -بتصرف- لمقال How to Use Full-Text Search in PostgreSQL on Ubuntu 16.04 لصاحبه Ilya Kotov

Django هو إطار عمل مرن يستخدم ﻹنشاء تطبيقات بلغة بايثون، وهذه التطبيقات مُجهزة تلقائيًا لتخزين البيانات في ملف قاعدة بيانات SQLite خفيف ويعمل بشكل جيد في الاستعمالات العادية والصغيرة، لكن استخدام نظام إدارة قواعد بيانات تقليدي سيطوِّر أداء التطبيق تحت ضغط زيادة المستخدمين أو زيادة حجم البيانات. وسنستعرض في هذا الدرس كيفية تثبيت وتهيئة PostgreSQL لاستخدامها مع تطبيقات Django، وسنثبّت الحزم اللازمة وننشئ اعتماديات قاعدة البيانات للتطبيق، ثم نبدأ مشروع Django جديد ونجهّزه ليستخدم هذه اﻹعدادات. المتطلبات خادم يعمل بتوزيعة أوبنتو 16.04 مع مستخدم -غير الجذر- له صلاحية sudo. تثبيت الحزم من مستودعات أوبنتو سنثبّت أولًا pip -مدير حزم بايثون- لتثبيت وإدارة حزم بايثون، وسنثبّت أيضًا برنامج قاعدة البيانات والمكتبات اللازمة للتفاعل معهم. يحتاج إصدار بايثون 2 و3 إلى حزم مختلفة قليلًا عن بعضها، لذا اختر الأوامر التي تتوافق مع إصدار بايثون لديك. انسخ الأوامر التالية إن كنت تستخدم بايثون 2: $ sudo apt-get update $ sudo apt-get install python-pip python-dev libpq-dev postgresql postgresql-contrib وهذه إن كنت تستخدم بايثون 3: $ sudo apt-get update $ sudo apt-get install python3-pip python3-dev libpq-dev postgresql postgresql-contrib يمكننا الآن إنشاء قاعدة البيانات بما أننا أنهينا تثبيت هذه الحِزّم. إنشاء قاعدة البيانات والمستخدم الخاص بها يستخدم Postgres نظام توثيق للاتصالات المحلية اسمه "توثيق النِّدّ Peer Authentication”. وهذا يعني أنه إذا كان اسم المستخدم في نظام التشغيل يطابق اسم Postgres صالح، فإن هذا المستخدم يمكنه الولوج دون الحاجة إلى توثيق. وقد أُنشئ مستخدم للنظام اسمه postgres ليتوافق مع مستخدم postgres المدير لنظام PostgreSQL، وسنحتاج هذا المستخدم لتنفيذ مهام إدارية، ويمكننا أيضًا أن نستخدم sudo وندخل اسم المستخدم من خلال لاحقة u-. سجل الدخول إلى جلسة Postgres تفاعلية عبر كتابة الأمر التالي: $ sudo -u postgres psql وسننشئ أولًا قاعدة بيانات لمشروع Django، ويجب أن يكون لكل مشروع قاعدة البيانات الخاصة به للدواعي الأمنية. وسنسمّي قاعدة البيانات في هذا المقال باسم myproject، لكن من اﻷفضل طبعًا أن تختار اسمًا يصلح لمشروع حقيقي. ملاحظة: تذكر أن تنهي كل الأوامر في محث SQL بفاصلة منقوطة ; postgres=# CREATE DATABASE myproject; أنشئ مستخدمًا لقاعدة البيانات، وسنستعمله للاتصال بقاعدة البيانات والتفاعل معها، وﻻ تنسَ أن تستبدل myprojectuser باسم قاعدة البيانات الذي اخترته، وتغيّر password بكلمة سر قوية: postgres=# CREATE USER myprojectuser WITH PASSWORD 'password'; واﻵن سنعدّل بعض معاملات الاتصال لهذا المستخدم لتسريع عمليات قاعدة البيانات بما أن القيم الصحيحة لن تضطر إلى أن تمر بعمليات استعلام وضبط في كل مرة يحدث اتصال. فسنضبط الترميز الافتراضي على UTF-8 وهو الترميز الافتراضي الذي يتوقعه Django. وسنضبط النظام الافتراضي لعزل التعاملات "default transactio isolation scheme” على read committed، وذلك لحظر القراءة من التعاملات غير المرسلة "uncommitted transactions”. وأخيرًا، سنضبط المنطقة الزمنية الافتراضية لمشاريع Django على UTC. وهذه الإعدادات يُنصح بها في التوثيق الرسمي لمشروع Django، دعنا نكتب ذلك الآن: postgres=# ALTER ROLE myprojectuser SET client_encoding TO 'utf8'; postgres=# ALTER ROLE myprojectuser SET default_transaction_isolation TO 'read committed'; postgres=# ALTER ROLE myprojectuser SET timezone TO 'UTC'; وكل ما نحتاجه الآن هو إعطاء مستخدم قاعدة البيانات صلاحيات الوصول لقاعدة البيانات التي أنشأناها للتو: postgres=# GRANT ALL PRIVILEGES ON DATABASE myproject TO myprojectuser; اخرج الآن من محث SQL: postgres=# \q تثبيت Django في بيئة افتراضية يمكننا تثبيت Django الآن بما أن قاعدة بياناتنا قد صارت جاهزة، وسنثبته وكل اعتمادياته داخل بيئة بايثون افتراضية لتحقيق مرونة أكثر، وستتيح لنا حزمة virtualenv إنشاء هذه البيئات بسهولة. اكتب هذا السطر في الطرفية لتثبيت virtualenv إن كنت تستخدم Python 2: $ sudo pip install virtualenv وهذا إن كنت تستخدم Python 3: $ sudo pip3 install virtualenv أنشئ مجلدًا جديدًا باسم مشروعك (استبدل اسم مشروعك بـ myproject الذي اخترناه هنا لغرض المثال فقط)، ثم انتقل داخله: $ mkdir ~/myproject $ cd ~/myproject اكتب السطر التالي لإنشاء بيئة افتراضية لتخزين متطلبات بايثون لمشروع Django الخاص بنا: $ virtualenv myprojectenv وذلك سيثبّت نسخة محلية من بايثون وأمر pip محلي داخل مجلد اسمه myprojectenv داخل مجلد مشروعك. نحتاج الآن إلى تفعيل البيئة الافتراضية قبل تثبيت البرامج داخلها، ويمكننا فعل ذلك عبر الأمر التالي: $ source myprojectenv/bin/activate سيتغير المحثّ الآن ليشير إلى أنك تعمل الآن داخل بيئة افتراضية وسيبدو شبيهًا بهذا: (myprojectenv)user@host:~/myproject$ ويمكننا الآن تثبيت Django باستخدام pip، ثم سنثبت psycopg2 التي ستتيح لنا استخدام قاعدة البيانات التي أعددناها: (ﻻحظ أنه يجب استخدام أمر pip وليس pip3 داخل البيئة الافتراضية بغض النظر عن نسخة بايثون التي لديك) (venv) $ pip install django psycopg2 يمكننا الآن أن نبدأ مشروع Django داخل مجلد المشروع (myproject في حالتنا)، وسينشئ هذا مجلدًا فرعيًا بنفس اسم مجلد المشروع ليحتوي الشفرة البرمجية، إضافة إلى مخطوطة إدارية "management script” داخل المجلد الحالي، ﻻ تنس إضافة النقطة التي في آخر الأمر التالي كي ﻻ يُنشأ مستوى فرعي جديد في المجلد: (venv) $ django-admin.py startproject myproject . سنضبط الآن مشروعنا ليستخدم قاعدة البيانات التي أنشأناها، افتح ملف الإعدادات الرئيسية لمشروع Django الموجود في المجلد الفرعي للمشروع: (ملاحظة: استبدل مشروعك بـmyproject) (myprojectenv) $ nano ~/myproject/myproject/settings.py ستجد قسم DATABASE في نهاية الملف، وسيبدو مشابهًا لهذا: . . . DATABASES = { 'default': { 'ENGINE': 'django.db.backends.sqlite3', 'NAME': os.path.join(BASE_DIR, 'db.sqlite3'), } } . . . هذا القسم يستخدم SQLite كقاعدة بيانات، ونريد تعديل هذه لكي يستخدم قاعدة بيانات PostgreSQL الخاصة بنا. فأول ما نفعله هو تغيير المحرك كي يستخدم محوّل postgresql_psycopg2 بدلًا من sqlite3، ثم نستخدم اسم قاعدة بياناتنا (myproject في مثالنا) في خانة NAME، ونضيف بعض بيانات تسجيل الدخول مثل اسم المستخدم وكلمة المرور، والمضيف الذي سيتصل به، وسنضيف خانة Port ونتركها فارغة كي يتم اختيار المنفذ الافتراضي: . . . DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql_psycopg2', 'NAME': 'myproject', 'USER': 'myprojectuser', 'PASSWORD': 'password', 'HOST': 'localhost', 'PORT': '', } } . . . وبما أننا في الملف، فقد تحتاج إلى تعديل تعليمة ALLOWED_HOSTS التي تحدد قائمة عناوين أو أسماء نطاقات مسموح باستخدامها للاتصال مع مشروع Django، فأي طلب اتصال بترويسة HOST ليس في هذه القائمة سيتم اعتراضه. ويتطلّب Django أن تعدّل هذه التعليمة كي يمنع فئة معينة من الاختراقات الأمنية. ولتعديل هذه التعليمة، أدخل -بين قوسين مربعيْن- عناوين IP أو أسماء النطاقات المرتبطة بخادم Django الخاص بك ويجب أن يكون كل نطاق أو عنوان IP داخل علامتي تنصيص مفردتيْن، وتفصل بين كل واحد منهم فاصلة ",”. وإن رغبت في الاستجابة لطلبات من نطاق ما إضافة إلى النطاقات الفرعية له فضع نقطة قبله أثناء كتابته. إليك أمثلة تعرض لك الطريقة الصحيحة لصيغة هذه التعليمة، استبدل النطاقات وعناوين الـ IP التي تريدها بالأمثلة الموجودة هنا: . . . # أبسط حالة: اكتب العناوين وأسماء النطاقات لخادم چانجو الخاص بك # ALLOWED_HOSTS = [ 'example.com', '203.0.113.5'] # ابدأ اسم النطاق بنقطة للاستجابة له ولأي نطاق فرعي # ALLOWED_HOSTS = ['.example.com', '203.0.113.5'] ALLOWED_HOSTS = ['your_server_domain_or_IP', 'second_domain_or_IP', . . .] واﻵن احفظ الملف وأغلقه. نقل قاعدة البيانات واختبار مشروعك يمكننا الآن نقل هياكل البيانات -بما أننا أنهينا ضبط إعدادات Django- إلى قاعدة بياناتنا واختبار الخادم. سنبدأ بإنشاء هيكل ابتدائي لقاعدة البيانات بما أننا ﻻ نملك أي بيانات حقيقية بعد: (myprojectenv) $ cd ~/myproject (myprojectenv) $ python manage.py makemigrations (myprojectenv) $ python manage.py migrate أنشئ حسابًا إداريًا: (myprojectenv) $ python manage.py createsuperuser وسيطلب منك النظام اختيار اسم لمستخدم هذا الحساب وعنوان بريد وكلمة مرور له. انتبه هنا إلى أنه يجب فتح المنفذ الذي سنستخدمه في الجدار الناري كي نتمكن من الدخول إلى خادم تطوير Django، إن كنت تستخدم UFW فإن فتح المنفذ المناسب يتم بكتابة هذا الأمر: (myprojectenv) $ sudo ufw allow 8000 وبمجرد أن تفتح المنفذ يمكنك اختبار عمل قاعدة البيانات بتشغيل خادم Django: http://server_domain_or_IP:8000 يجب أن ترى صفحة index الافتراضية: ضعadmin/ في نهاية الرابط، يجب أن يدخلك هذا لشاشة تسجيل الدخول إلى واجهة التحكم: أدخل اسم المستخدم وكلمة المرور اللتان أنشأتهما قبل قليل باستخدام createsuperuser، فتدخل إلى لوحة التحكم: وبدخولنا للوحة التحكم نكون قد تأكدنا أن قاعدة البيانات قد خزّنت معلومات حساب المستخدم الخاص بنا ويمكننا الدخول إليه دون مشاكل. يمكنك الآن إيقاف الخادم حين تنتهي من تحققك بالضغط على ctrl-c داخل شاشة الطرفية. الخلاصة قد عرضنا في هذا الدليل كيفية تثبيت وإعداد PostgreSQL كقاعدة بيانات في النهاية الخلفية لمشروع Django، إذ تستفيد أغلب المشاريع من استخدام نظم إدارة متطورة لقواعد البيانات، رغم أن SQLite تتعامل بشكل جيد أثناء تطوير المشروع وأثناء الاستخدام الخفيف له. ترجمة -بتصرف- لمقال How To Use PostgreSQL with your Django Application on Ubuntu 16.04 لصاحبه Justin Ellingwood.

مقدّمة من الممكن أن ننخدع بفكرة أنّ الخوادم لن تُهاجَم ما دام الخادوم جديدا، زواره قلائل أو أنّ المخترقين لن يستفيدوا شيئا من اختراقه. لكنّ العديد من الهجمات تكون مُؤتمتة وتُصمَّمُ خصيصا للبحث عن الأخطاء الشّائعة التي تُرتَكب عند ضبط الخادوم. تقوم هذه البرمجيات بفحص الشبكات لاكتشاف الخوادم فقط، ولا تكثرت بمحتواها. تمكين الاتصالات الخارجيّة من أكثر الحالات الشّائعة التي قد تُؤدي إلى وصول غير مُصرّح إلى قاعدة بيانات PostgreSQL. يُمكن أن يحدث هذا لأنّ الإعدادات تسمح للبرمجيات باستكشاف الخوادم الضعيفة بسهولة. في هذا الدّرس، سنلقي نظرة على كيفيّة تقليل خطر الوصول غير المُصرّح الذي يطرحه تفعيل الاتّصالات البعيدة (remote connections). ورغم أنّ هذه خطوة أولى بغاية الأهميّة، وبما أنّ الخوادم قد تتعرّض للاختراق بطرق أخرى، فإنّنا ننصح باتّخاذ إجراءات إضافيّة لحماية بياناتك، والتي يُمكنك أن تجدها في جزء "إجراءات إضافيّة لمزيد من الحماية” من هذا الدّرس. الوضعيّة لفهم الخطر الذي نحاول تخفيفه، تخيّل الخادوم على أنّه متجر صغير. إن كان المتجر يُنصت (listening) على أي منفذ (port)، فهذا يُكافئ قلب لافتة تُشير إلى أنّ المتجر "مفتوح”. أي أنّ الخادوم يكون مرئيّا على الشّبكة، ما يُمكّن البرمجيات المؤتمتة من إيجاده. يُمكننا أن نتخيّل بأنّ كلّ منفذ عبارة عن طريقة للدّخول إلى المتجر، مثل باب أو نافذة مثلا. يُمكن لهذه المداخل أن تكون مفتوحة، مُغلقة، مُقفلة أو مُعطّلة حسب حالة البرمجيّة التي تقوم بالإنصات، لكنّ الإنصات على واجهة عامّة يعني بأنّ البرمجيات الخبيثة تستطيع مُحاولة الدّخول. فمثلا، يُمكن أن تُحاول البرمجيّة استعمال كلمة مرور افتراضيّة على أمل أنّها لم تتغيّر. يُمكن لها كذلك استغلال ثغرات أمنيّة موجودة في البرنامج الذي يُنصِتُ على أمل أنّها لم تُصلَح بعد. يُمكن مُحاولة العديد من الأساليب، إن تمكّنت البرمجيّة الخبيثة من إيجاد نقطة ضعف وقامت باستغلالها، فهذا يعني بأنّ الوصول إلى الخادوم سيتمّ بنجاح وسيتمكّن الهجوم من تخليف خسائر كبيرة. إن قُمنا بتقييد عفريت (daemon) معيّن مثل postgresql ليُنصت محليّا فقط، فهذا مُشابه لمحو الباب الذي يوصل إلى الخارج. ولن يُمكن مُحاولة أي شيء آخر للوصول إلى Postgres. تحمي الجدران النّاريّة (Firewalls) وشبكات VPN بطريقة مُشابهة. في هذا الدّرس، سنُركّز على حذف الباب العمومي الذي يوصل إلى PostgreSQL. لحماية العفريت أو البيانات أثناء نقلها أو تخزينها، انظر فقرة "إجراءات إضافيّة لمزيد من الحماية” من هذا الدّرس. المُتطلّبات سنستعمل في هذا الدّرس خادومي Ubuntu، الأول لمُضيف قاعدة البيانات والآخر ليعمل كعميل يتّصل بالمُضيف عن بُعد. يجب على كلّ خادوم أن يُجهَّز بمُستخدم sudo وجدار ناري مُفعّل. يُمكنك الاستعانة بدرس الإعداد البدئي لخادوم Ubuntu. مُضيف قاعدة البيانات PostgreSQL (Ubuntu 16.04) إن لم تقم بتنصيب PostgreSQL بعد، يُمكنك القيام بذلك باستخدام الأوامر التّاليّة: sudo apt-get update sudo apt-get install postgresql postgresql-contrib آلة العميل (Ubuntu 16.04) لاختبار تمكين الاتصالات البعيدة، سنستعمل عميل PostgreSQL psql. لتنصيبها، استعمل الأوامر التّاليّة: sudo apt-get update sudo apt-get install postgresql-client عند استيفاء هذه المُتطلبات، ستكون جاهزا لاتّباع هذا الدّرس. فهم الإعداد الافتراضيّ عند تنصيب PostgreSQL من مستودع حزم Ubuntu، فالخيار الافتراضيّ هو الانصات على المُضيف المحليّ (localhost). يُمكن تغيير هذا الخيار الافتراضي عبر تعديل مقطع listen_addresses على ملفّ postgresql.conf، لكنّ هذا الإعداد الافتراضي يمنع الخادوم من الانصات آليّا على واجهة عموميّة (public interface). علاوة على ما سبق، فالملفّ pg_hba.conf لا يسمح سوى لاتّصالات من مقابس أسماء نطاقات Unix/Linux (Unix/Linux domain sockets)، وعنوان الاسترجاع (loopback address) الخاصّ بالخادوم المحلي، ما يعني بأنّ الاتّصالات من مُضيفات خارجيّة لن تُقبَل: # Put your actual configuration here # ---------------------------------- # # If you want to allow non-local connections, you need to add more # "host" records. In that case you will also need to make PostgreSQL # listen on a non-local interface via the listen_addresses # configuration parameter, or via the -i or -h command line switches. # DO NOT DISABLE! # If you change this first entry you will need to make sure that the # database superuser can access the database using some other method. # Noninteractive access to all databases is required during automatic # maintenance (custom daily cronjobs, replication, and similar tasks). # # Database administrative login by Unix domain socket local all postgres peer # TYPE DATABASE USER ADDRESS METHOD # "local" is for Unix domain socket connections only local all all peer # IPv4 local connections: host all all 127.0.0.1/32 md5 # IPv6 local connections: host all all ::1/128 md5 هذه الإعدادات الافتراضيّة تُحقّق هدف منع الانصات على واجهة عموميّة. إن تركناها على حالها وأبقينا الجدار النّاري مُفعّلا، فهذا كلّ ما في الأمر! يُمكننا الآن الانتقال إلى قسم "إجراءات إضافيّة لمزيد من الحماية” للتّعرف على كيفيّة حماية البيانات أثناء نقلها. إن أردت الاتصال من مُضيف بعيد، فسنتطرّق إلى كيفيّة تعديل الإعدادات الافتراضيّة إضافة إلى الخطوات التي يجب اتّخاذها فورا لحماية الخادوم في الفقرة التّاليّة. إعداد الاتّصالات البعيدة (Remote Connections) لإعداد بيئة إنتاج قويّة، وقبل بدء العمل مع بيانات حسّاسة، من المُفضّل تشفير مرور (traffic) PostgreSQL باستخدام SSL، إضافة إلى حماية باستخدام جدار ناري خارجي أو شبكة افتراضيّة خاصّة (VPN). قبل القيام بالأمور السابقة ذكرها، يُمكننا اتّخاذ طريق أقل تعقيدا عبر تفعيل جدار ناريّ على خادوم قاعدة البيانات الخاص بنا وتقييد الوصول لتقبل فقط المُضيفات التي تحتاج إلى الوصول إلى الخادوم. الخطوة الأولى – إضافة مُستخدم وقاعدة بيانات سنبدأ بإضافة مُستخدم وقاعدة بيانات لأغراض تجريبيّة. للقيام بذلك، سنستعمل عميل PostgreSQL psql للاتصال بصفة المُستخدم الإداري postgres. عبر تمرير الخيار -i للأمر sudo سيتمّ تشغيل صدفة تسجيل الدّخول (login shell) الخاصّة بالمُستخدم postgres، ما يضمن بأنّ الخيارات في ملفّ .profile أو في موارد أخرى مُتعلّقة بتسجيل الدّخول ستُحمَّل. يقوم الخيار -u بتحديد المُستخدم postgres: sudo -i -u postgres psql بعدها، سنقوم بإنشاء مُستخدم بكلمة مرور. تأكّد من استعمال كلمة مرور جيّدة عوضا عن المقطع mypassword في المثال أسفله: CREATE USER sammy WITH PASSWORD 'mypassword'; إن تمّ إنشاء المُستخدم بنجاح، فسنستقبل المُخرج التّالي: CREATE ROLE مُلاحظة: منذ الإصدار 8.1 من PostgreSQL، فالأدوار (ROLES) والمُستخدمون (USERS) يشتركون في المعنى.لكنّ هناك اتّفاقا يقول بأنّه إن كان لدور كلمة مرور فإنّنا نُسمّيه مُستخدما، ونُسمّي الدّور عديم كلمة المرور دورا، لذا أحيانا ستحصل على ROLE في المُخرج رغم أنّك تتوقّع أن ترى USER. تاليّاََ، سنُنشئ قاعدة بيانات وسنمنح كامل صلاحيّات الوصول لمُستخدمنا الجديد. تقول أفضل الممارسات بمنح المُستخدمين صلاحيّات الوصول التي يجتاجونها فقط، وعلى الموارد التي يجب أن يحصلوا عليها فقط، لذا فاعتمادا على حالة الاستخدام ( use case)، قد يُفضّل تقييد أحقيّة الوصول للمُستخدم. . CREATE DATABASE sammydb OWNER sammy; عند إنشاء قاعدة البيانات بنجاح، سنستقبل التّأكيد التّالي: CREATE DATABASE بعد إنشاء المُستخدم وقاعدة البيانات، سنقوم بالخروج من سطر أوامر PostgreSQL: \q بعد الضغط على مفتاح ENTER، سنرجع إلى سطر الأوامر وسنكون جاهزين للمُتابعة. الخطورة الثّانيّة – إعداد UFW في درس الإعداد البدئي لخادوم Ubuntu ، قمنا بتفعيل UFW وسمحنا لاتّصالات SSH فقط. قبل بدء الإعداد، لنتحقّق من حالة UFW: sudo ufw status مُلاحظة: إن كان المخرج يدُلّ على أنّ الجدار النّاري غير مُفعّل (inactive)، يُمكننا تفعيله بالأمر التّالي: sudo ufw enable بعد التّفعيل، فإنّ إعادة تنفيذ الأمر sudo ufw status سيستعرض القواعد الحاليّة. فعّل SSH إن كان ذلك مطلوبا: sudo ufw allow OpenSSH في حالة لم تُغيِّر من المُتطلّبات، فمُخرج الأمر sudo ufw status سيُشير إلى أنّ OpenSSH هي الخدمة الوحيدة المُفعّلة: Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) بعد التّحقّق من حالة الجدار النّاري، سنقوم بالسماح بالوصول إلى منفذ PostgreSQL وسنُقيّد الوصول لنسمح فقط للمُضيف أو المُضيفات المرغوبة. سيُضيف الأمر أسفله قاعدة للمنفذ الافتراضيّ لـPostgreSQL، أي المنفذ رقم 5432. إن غيّرت هذا المنفذ، فتأكّد من تعديل الأمر أسفله. تأكّد من استعمال عنوان IP الخاص بالخادوم الذي يحتاج إلى الوصول. أعد تنفيذ الأمر لإضافة كلّ عميل من العملاء الذين ترغب بإعطائهم أحقيّة الوصول إن كان ذلك لازما: sudo ufw allow from client_ip_address to any port 5432 استبدل client_ip_address بعنوان IP الخاصّ بالعميل. للتّحقّق من أنّ القاعدة قد طُبِّقت، يُمكنك تنفيذ الأمر ufw status مُجدّدا: sudo ufw status المُخرج: To Action From -- ------ ---- OpenSSH ALLOW Anywhere 5432 ALLOW client_ip_address OpenSSH (v6) ALLOW Anywhere (v6) مُلاحظة: إن لم تكن لديك دراية مُسبقة بأساسيّات UFW، يُمكنك تعلّم المزيد في درس أساسيات UFW: قواعد وأوامر شائعة للجدار الناري . بعد تجهيز قاعدة الجدار النّاريّ هذه، سنقوم الآن بإعداد PostgreSQL لتُنصت على عنوان IP العمومي. سنقوم بهذا عبر تعديل إعدادَيْن، خانة للمُضيف المُتصل في pg_hba.conf وإعداد listen_addresses في postgresql.conf. الخطوة الثّالثة – إعداد المُضيفات المسموح لها (Allowed Hosts) سنبدأ عبر إضافة خانة المُضيف في ملفّ pg_hba.conf. إن كنت تستعمل نسخة أخرى غيْرَ النُّسخةِ 9.5 من PostgreSQL فتأكّد من تعديل الأمر أسفله قبل تنفيذه: sudo nano /etc/postgresql/9.5/main/pg_hba.conf سنضع أسطر host تحت مقطع التّعليقات الذي يصف كيفيّة السّماح للاتصالات غير المحليّة. سنُضيف سطرا يحمل العنوان العمومي الخاص بخادوم قاعدة البيانات لاختبار ما إذا كان الجدار النّاري مُعدّا بشكل صحيح. استبدل المقطع client_ip_address بعنوان IP الخاص بآلة العميل الخاصّ بك: # If you want to allow non-local connections, you need to add more # "host" records. In that case you will also need to make PostgreSQL # listen on a non-local interface via the listen_addresses # configuration parameter, or via the -i or -h command line switches. host sammydb sammy client_ip_address/32 md5 قبل حفظ التغييرات، لننظر إلى كل قيمة من قيم السّطر الذي أضفناه في حالة كنت ترغب تعديل أي منها: المُضيف، المُعامل host يُحدّد بأنّ اتّصال TCP/IP سيُستَعمَل. قاعدة البيانات، العمود الثّاني، sammydb، يُحدّد أي قاعدة بيانات يُمكن للمُضيف أن يتّصل بها، يُمكنك تعيين أكثر من قاعدة بيانات واحدة عبر تفرقة أسمائها بالفاصلة ,. المُستخدم، sammy، يُحدّد المُستخدم المسموح له بالاتّصال. وكما مع عمود قاعدة البيانات، فتستطيع تحديد أكثر من مستخدم واحد باستعمال علامة الفاصلة. العنوان، يُحدّد عنوان آلة العميل ويُمكن أن يكون عبارة عن اسم مُضيف (hostname)، مجال عناوين IP (IP address range) أو كلمات مفتاحيّة خاصّة. في المثال أعلاه، قمنا بالسماح لعنوان IP الخاصّ بالعميل فقط. طريقة الاستيثاق (auth-method)، في الأخير، يُمكن تحديد طريقة استيثاق، يُشير md5 إلى كلمة مرور مزدوجة التّشفير بـMD5 ( double-MD5-hashed password ) لن تحتاج سوى كلمة المرور التي تم إنشاؤها للمُستخدم الذي سيقوم بالاتّصال. للمزيد من المعلومات وإعدادات إضافيّة راجع التوثيق الرّسمي لـPostgreSQL حول ملفّ pg_hba.conf. بعد الانتهاء من التّعديلات، احفظ وأغلق الملف. الخطوة الرّابعة – إعداد عنوان الإنصات (Listening Address) سنقوم الآن بضبط عنوان الإنصات في ملفّ postgresql.conf (تأكّد من تصحيح رقم النّسخة): sudo nano /etc/postgresql/9.5/main/postgresql.conf أضف عناوين الإنصات تحت سطر listen_addresses، تأكّد من استبدال server_ip_address بعنوان IP أو اسم مُضيف قاعدة البيانات الخاصّة بك وليس عنوان العميل الذي سيقوم بالاتصال: #listen_addresses = 'localhost' # what IP address(es) to listen on; listen_addresses = 'localhost,server_ip_address' احفظ وأغلق الملفّ عند الانتهاء من إجراء التّعديلات. الخطوة الخامسة – إعادة تشغيل PostgreSQL لن تُطبَّق التعديلات حتى نُعيد تشغيل عفريت (daemon) PostgreSQL، لذا سنقوم بهذا قبل أن نبدأ بالتجربة: sudo systemctl restart postgresql وبما أنّ systemctl لا يوفّر تغذيّة راجعة (feedback)، فسنتحقّق من نجاح إعادة تشغيل العفريت: sudo systemctl status postgresql إن احتوى المُخرج على Active: active وانتهى بمقطع مُشابه لما يلي، فهذا يعني بأنّ عفريتPostgreSQL مُفعّل. ... Jan 10 23:02:20 PostgreSQL systemd[1]: Started PostgreSQL RDBMS. بعد إعادة تشغيل العفريت، يُمكننا الآن التّجربة. الخطوة السّادسة – تجربة الاتّصال لنتحقّق من أنّنا نستطيع الاتّصال من جهاز العميل الخاص بنا. للقيام بهذا، سنستعمل الأمر psql مع الخيّار -U لتحديد المُستخدم، الخيار -h لتحديد عنوان IP الخاصّ بالعميل و -d لتحديد قاعدة البيانات، وذلك لأنّنا ضيّقنا الحماية لكي يتمكّن sammy فقط من الاتّصال بقاعدة بيانات واحدة فقط. psql -U sammy -h postgres_host_ip -d sammydb استبدل postgres_host_ip بعنوان IP الخاصّ بمُضيف PostgreSQL. إن تمّ إعداد كل شيء بشكل صحيح، فيجب أن تستقبل المحثَّ (prompt) التّالي: Password for user sammy: أدخل كلمة المرور التّي حدّدتها مسبقا عندما أضفت المُستخدم sammy في مرقاب (monitor) PostgreSQL. إن حصلت على المحثّ التّالي، فهذا يعني بأنّ الاتصال قد تمّ بنجاح: sammydb=> هذا يُؤكّد على أنّنا نستطيع تجاوز الجدار النّاري وأن نتّصل بقاعدة البيانات. سنقوم الآن بالخروج من المحثّ: \q بعد التّحقّق من أنّ الإعدادات قد ضُبِطت بنجاح، سنقوم بتنظيف مُخلّفات التّجربة. الخطوة السّابعة – حذف قاعدة البيانات والمُستخدم التّجريبيّين بعد اختبار الاتّصال، يُمكننا الآن العودة إلى المُضيف واستخدام الأمر التّالي لحذف قاعدة البيانات والمُستخدم. sudo -i -u postgres psql لحذف قاعدة البيانات: DROP DATABASE sammydb; عند نجاح العمليّة، ستستقبل المُخرج التّالي: DROP DATABASE لحذف المُستخدم: DROP USER sammy; المُخرج عند نجاح العمليّة: DROP ROLE سنقوم بإنهاء عمليّة التّنظيف بحذف خانة المُضيف الخاصّة بقاعدة البيانات sammydb من ملفّ pg_hba.conf لأنّنا لم نعد نحتاج إليها: sudo nano /etc/postgresql/9.5/main/pg_hba.conf استبدل 9.5 برقم النّسخة الخاصّة بك. السّطر الذي يجب عليك حذفه: host sammydb sammy client_ip_address/32 md5 ليُطبَّقَ التّعديل، سنقوم بحفظ وإغلاق الملفّ ومن ثمّ نُعيد تشغيل خادوم قاعدة البيانات: sudo systemctl restart postgresl للتحقّق من أنّ إعادة التّشغيل قد تمّت بنجاح، سنطّلع على الحالة: sudo systemctl status postgres إن كان المُخرج يحتوي على Active: active فهذا يعني بأنّ إعادة التّشغيل قد تمّت بنجاح. يُمكنك الآن ضبط التّطبيق أو الخدمة على العميل التي تحتاج إلى إمكانيّة الاتصال عن بعد. خاتمة اتّخذنا في هذا الدّرس الخطوات الأساسيّة لحماية PostgreSQL عبر إعداد الجدار النّاريّ الخاصّ بالخادوم ليسمح فقط للاتصالات من المُضيفات التي تحتاج إلى صلاحيّات الوصول وعبر ضبط PostgreSQL لتقبل الاتصالات من هذه المُضيفات فقط. هذا يُخفّف من خطر بعض من أنواع الهجمات. تعتبر هذه الإجراءات الخطوة الأولى فقط لحماية البيانات، وننصح بمراجعة واتّخاذ الإجراءات الأمنية الإضافيّة المذكورة أعلاه. ترجمة -بتصرّف- للمقال How To Secure PostgreSQL Against Automated Attacks لصاحبته Melissa Anderson.

توفر أوبنتو خادومَيّ قواعد بيانات شهيرَين هما: قواعد بيانات MySQL.قواعد بيانات PostgreSQL.حيث تتوفران في المستودع الرئيسي (main)؛ ويشرح هذا الدرس كيفية تثبيت وضبط خادومَي قواعد البيانات آنفَيّ الذكر. MySQLإن MySQL هو خادوم قواعد بيانات سريع ومتعدد الخيوط (multi-threaded) ومتعدد المستخدمين ومرن جدًا؛ مُطوَّر للأنظمة الإنتاجية المحورية والتي تتحمل حِملًا ثقيلًا، ويمكن أيضًا تضمينه في البرمجيات سريعة النشر (mass-deployed). التثبيتنفذِّ الأمر الآتي في الطرفية لتثبيت MySQL: sudo apt-get install mysql-serverسيُطلب منك إدخال كلمة مرور للمستخدم الجذر لخادوم MySQL أثناء التثبيت. بعد أن ينتهي التثبيت، فيجب أن يبدأ خادوم MySQL تلقائيًا؛ تستطيع تنفيذ الأمر الآتي في الطرفية للتحقق إذا كان خادوم MySQL يعمل أم لا: sudo netstat -tap | grep mysqlيجب أن تشاهد شيئًا شبيهًا بما يلي بعد تنفيذ الأمر السابق: tcp 0 0 localhost:mysql *:* LISTEN 2556/mysqldإذا لم يكن يعمل الخادوم، فتستطيع تشغيله بالأمر: sudo service mysql restartالضبطتستطيع تعديل الملف ‎/etc/mysql/my.cnf لضبط الإعدادات الأساسية، مثل ملف السجل، ورقم المنفذ ...إلخ. فمثلًا لضبط MySQL ليستمع إلى الاتصالات من مضيفي الشبكة، عليك تعديل قيمة التعليمة bind-address إلى عنوان IP للخادوم: bind-address = 192.168.0.5ملاحظة: عدِّل 192.168.0.5 إلى العنوان الملائم. بعد إجراء التعديلات على ملف ‎/etc/mysql/my.cnf؛ فيجب إعادة تشغيل عفريت MySQL: sudo service mysql restartأدخل الأمر الآتي في الطرفية إذا رغبت بتغيير كلمة مرور المستخدم الجذر (root) في MySQL: sudo dpkg-reconfigure mysql-server-5.5سيُوقَف عمل عفريت MySQL، وستُسأل عن كلمة المرور الجديدة. محركات قاعدة البياناتعلى الرغم من أن الضبط الافتراضي لخادوم MySQL الموفر من حزم أوبنتو يعمل عملًا صحيحًا دون مشاكل، لكن هنالك بعض الأمور التي عليك أخذها بعين الاعتبار قبل الإكمال. صُمِّمَت قواعد بيانات MySQL للسماح بتخزين البيانات بطرقٍ مختلفة؛ يُشار لهذه الطرق إما بمحركات قواعد البيانات أو محركات التخزين (Storage engine)؛ هنالك محركان رئيسيان ستكون مهتمًا بهما: InnoDB و MyISAM؛ لا تتغير طريقة التعامل مع محركات التخزين المختلفة بالنسبة للمستخدم النهائي؛ حيث تتعامل MySQL مع الأمور بطريقة مختلفة وراء الستار، أي أنه بغض النظر عن محرك التخزين الذي تستخدمه، فإنك ستتعامل مع قواعد البيانات بنفس الطريقة تمامًا. لكل محرك إيجابياته وسلبياته؛ وبينما من الممكن دمج عدِّة محركات قواعد بيانات على مستوى الجدول، لكن ذلك خطيرٌ، فربما يقلل ذلك من الفعالية والأداء لأنك تُقسِّم الموارد بين محركين بدلًا من تخصيصها لمحرك واحد فقط. المحرك MyISAM هو الأقدم بين المحركين المذكورين؛ يمكن أن يكون أسرع من InnoDB في حالات معيّنة ويفضل الأعمال التي تتطلب القراءة فقط؛ تتمحور بعض تطبيقات الويب حول MyISAM (على الرغم أنها لن تُبطَئ إذا استخدمت InnoDB)؛ يدعم MyISAM أيضًا نوع البيانات FULLTEXT؛ الذي يسمح بالبحث بسرعة كبيرة في كمياتٍ كبيرةٍ من النص؛ لكن MyISAM قادر على قفل الجدول بأكمله فقط عند الكتابة، هذا يعني أن عمليةً واحدةً فقط تستطيع تحديث الجدول في لحظة زمنية معينّة؛ قد يكون هذا إعاقةً لتوسع تطبيق يعتمد على هذا الجدول؛ ولا يحتوي MyISAM على ميزة «journaling»، وهذا يعني أنه من الصعب استرجاع البيانات بعد حدوث انهيار.المحرك InnoDB هو محرك قواعد بيانات أكثر حداثةً، صُمِّم ليكون متوافقًا مع ACID الذي يضمن إجراء العمليات على قواعد البيانات بطريقة عملية؛ قفل الكتابة يحدث على مستوى السجل (row) ضمن الجدول؛ هذا يعني أنه من الممكن إجراء عدِّة تحديثات لسجلات جدولٍ ما في نفس الوقت؛ التخزين الموقت للبيانات يحدث في الذاكرة ضمن محرك قواعد البيانات، مما يسمح بالتخزين على أساس السجل وليس على أساس كتلة الملف (file block)؛ ولكي يتوافق مع ACID، فإن كل العمليات تحدث بطريقة «journaled» مستقلةً عن الجداول الرئيسية؛ وهذا يؤدي إلى استرجاع البيانات استرجاعًا عمليًا.إن InnoDB هو المحرك الافتراضي في MySQL 5.5 ومن المستحسن بشدة استخدامه بدلًا من MyISAM ما لم تكن تريد استخدام مزايا خاصة بذاك المحرك. الضبط المتقدم: إنشاء ملف ضبط my.cnfهنالك عدد من المعاملات التي يمكن تعديلها في ملف ضبط MySQL مما يسمح لك بتحسين أداء الخادوم مع مرور الوقت؛ ربما تجد الأداة «Percona's my.cnf generating tool» مفيدةً للإعداد الابتدائي؛ ستولد هذه الأداة ملف my.cnf ليكون أكثر ملائمةً لإمكانيات ومتطلبات خادومك. لا تستبدل ملف my.cnf المولد من Percona إذا وضعت بيانات في قاعدة بيانات، بعض التغييرات في الملف لن تسبب مشاكل لأنها تُعدِّل طريقة تخزين البيانات على القرص الصلب ولن تتمكن من تشغيل MySQL؛ إذا أردت استخدامه وكانت لديك بيانات موجودة مسبقًا، فعليك أن تجري mysqldump ثم تعيد التحميل: mysqldump --all-databases --all-routines -u root -p > ~/fulldump.sqlستُسأل عن كلمة مرور المستخدم الجذر لقواعد MySQL قبل إنشاء نسخة من البيانات؛ من المستحسن أن تتأكد أنه لا يوجد مستخدمين أو عمليات تستخدم قاعدة البيانات قبل إجراء هذه الخطوة؛ ربما تأخذ عملية النسخ بعض الوقت بناءً على مقدار البيانات الموجودة في قاعدة البيانات لديك؛ لن ترى شيئًا على الشاشة أثناء تنفيذ الأمر السابق. أغلق خادوم MySQL بعد إكمال عملية التفريغ (dump): sudo service mysql stopخذ الآن نسخةً احتياطيةً من my.cnf واستبدله بالملف الجديد: sudo cp /etc/my.cnf /etc/my.cnf.backup sudo cp /path/to/new/my.cnf /etc/my.cnfالآن احذف وأعد تهيئة مجال قواعد البيانات وتأكد أن الملكية صحيحة قبل إعادة تشغيلMySQL: sudo rm -rf /var/lib/mysql/* sudo mysql_install_db sudo chown -R mysql: /var/lib/mysql sudo service start mysqlكل ما تبقى الآن هو إعادة استيراد بياناتك؛ وللحصول على فكرة عن مدى إتمام عملية الاستيراد، فربما تجد الأداة pv‏ (Pipe Viewer) مفيدةً؛ الأمر الآتي يظهر كيفية تثبيت واستخدام pv لهذه الحالة، ربما لا تريد أن تستخدمها وكل ما عليك فعله هو استبدال pv بالأمر cat؛ تجاهل أية أوقات متوقعة للانتهاء (ETA) مولدة من pv؛ لأنها مبنية على الوقت المستغرق لكي يُعالَج كل سجل من الملف، لكن سرعة إدراج البيانات قد تختلف اختلافًا كبيرًا من سجل إلى سجل: sudo apt-get install pv pv ~/fulldump.sql | mysqlملاحظة: هذا ليس ضروريًا لكل تعديلات my.cnf؛ أغلبية المتغيرات التي قد ترغب في تعديلها لتحسين الأداء يمكن أن تُغيَّر حتى وإن كان يعمل الخادوم؛ تأكد من الحصول على نسخة احتياطية من ملفات الضبط والبيانات قبل إجراء التعديلات. MySQL Tunerالأداة «MySQL Tuner» هي أداة مفيدة تستطيع الاتصال إلى خدمة MySQL التي تعمل وتوفر اقتراحات عن كيفية ضبطها بأفضل ضبط لحالتك؛ وكما كان يعمل الخادوم لوقتٍ أطول، كلما كانت «النصيحة» التي سيوفرها mysqltuner أفضل؛ خذ بعين الاعتبار الانتظار لمدة 24 ساعة في بيئة إنتاجية قبل تشغيل هذه الأداة؛ تستطيع تثبيت mysqltuner من مستودعات أوبنتو: sudo apt-get install mysqltunerثم تشغيلها بعد تثبيتها بالأمر: mysqltunerوانتظر التقرير النهائي، سيوفر القسم العلوي معلوماتٍ عن خادوم قاعدة البيانات، ويوفر القسم السفلي اقتراحاتٍ لكي تعدلها في ملف my.cnf؛ يمكن تعديل أغلبية الاقتراحات على الخادوم مباشرةً دون إعادة تشغيله، انظر إلى توثيق MySQL الرسمي للمتغيرات المناسبة لتعديلها في البيئات الإنتاجية؛ ما يلي هو جزء من تقرير من قاعدة بيانات إنتاجية الذي يُظهِر أن هنالك بعض الفائدة من زيادة مقدار ذاكرة تخزين الطلبية: -------- Recommendations ----------------------------------------------------- General recommendations: Run OPTIMIZE TABLE to defragment tables for better performance Increase table_cache gradually to avoid file descriptor limits Variables to adjust: key_buffer_size (> 1.4G) query_cache_size (> 32M) table_cache (> 64) innodb_buffer_pool_size (>= 22G)تعليق أخير عن ضبط قواعد البيانات: بينما نستطيع أن نقول أن بعض الإعدادات هي الأفضل، لكن قد يختلف الأداء من تطبيق لآخر؛ على سبيل المثال، ما يعمل عملًا ممتازًا لووردبريس (Wordpress) قد لا يكون الأفضل لدروبال (Drupal) أو جوملا (Joomla) أو التطبيقات التجارية؛ الأداء متعلقٌ بأنواع الطلبيات واستخدام الفهارس، وإذا ما كان تصميم قاعدة البيانات جيدًا، وهكذا... ربما من الجيد إنفاق بعض الوقت في البحث عن إعدادات ملائمة لقواعد البيانات بناءً على التطبيقات التي تستخدمها؛ لكن بعد أن تتجاوز التعديلات حدًا معيّنًا، فإن أيّة تغييرات تجريها لا تتسبب إلا بتحسين بسيط جدًا في أداء التطبيق، ومن الأفضل لك تحسين التطبيق نفسه، أو التفكير في توسيع خادوم MySQL إما باستخدام عتاد أفضل أو بإضافة خواديم تابعة (slave). مصادرراجع الموقع الرئيسي لقواعد MySQL لمزيدٍ من المعلومات.التوثيق الكامل متوفر بصيغ online و offline من «MySQL Developers portal».لمعلومات عامة حول SQL، انظر إلى كتاب «Using SQL Special Edition».صفحة ويكي أوبنتو «Apache MySQL PHP» فيها بعض المعلومات المفيدة.PostgreSQLPostgreSQL هي قاعدة بيانات علائقية تعتمد على الكائنات وتملك ميزات أنظمة قواعد البيانات التجارية التقليدية مع تحسينات موجودة في الجيل الجديد من أنظمة DBMS. التثبيتأدخل الأمر الآتي في الطرفية لتثبيت PostgreSQL: sudo apt-get install postgresqlبعد انتهاء التثبيت، عليك ضبط خادوم PostgreSQL بناءً على متطلباتك، على الرغم من أن الضبط الافتراضي قابل للاستخدام. الضبطالاتصال عبر TCP/IP معطَّل افتراضيًا؛ تدعم PostgreSQL عدّة طرق للاستيثاق من العميل؛ طريقة الاستيثاق IDENT تُستعمَل للمستخدمين المحليين ولمستخدم postgres ما لم يُضبَط غير ذلك؛ رجاءً راجع «PostgreSQL Administrator's Guide» إذا أردت ضبط بدائل مثل Kerberos. سنفترض في ما يلي أنك ستُفعِّل اتصالات TCP/IP وتستخدم طريقة MD5 للاستيثاق من العميل؛ تُخزَّن ملفات ضبط PostgreSQL في المجلد ‎/etc/postgresql/<version>/main؛ على سبيل المثال، إذا ثبتت خادوم PostgreSQL 9.1، فإن ملفات الضبط ستُخزَّن في المجلد ‎/etc/postgresql/9.1/main. تنويه: لضبط الاستيثاق بطريقة ident، فأضف مدخلات إلى ‎/etc/postgresql/9.1/‎ main/pg_ident.conf؛ هنالك تعليقات تفصيلية في الملف لتساعدك. لتفعيل اتصالات TCP/IP، عليك تعديل الملف ‎/etc/postgresql/9.1/main/postgresql.conf ومن ثم تحديد السطر: ‎‎#listen_addresses = 'localhost‎‎'‎ ثم تغييره إلى: listen_addresses = '*'ملاحظة: للسماح باتصالات IPv4 و IPv6، استبدل «localhost» بالرمز «::». ربما تريد تعديل بقية المعاملات، إذا كنت تعرف ماذا تفعل! للتفاصيل، ارجع إلى ملف الضبط أو إلى توثيق PostgreSQL. الآن وبعد أن استطعنا الاتصال بخادوم PostgreSQL فإن الخطوة الآتية هي ضبط كلمة مرور للمستخدم postgres؛ نفذ الأمر الآتي في الطرفية للاتصال بقاعدة بيانات PostgreSQL الافتراضية: sudo -u postgres psql template1يتصل الأمر السابق بقاعدة بيانات PostgreSQL المسماة template1 كالمستخدم postgres؛ بعد أن تتصل إلى خادوم PostgreSQL وتحصل على مِحَث لإدخال تعليمات SQL، فيمكنك إدخال أمر SQL الآتي في مِحَث psql لضبط كلمة المرور للمستخدم postgres: ALTER USER postgres with encrypted password 'your_password';بعد ضبط كلمة المرور، عدِّل الملف ‎/etc/postgresql/9.1/main/pg_hba.conf لاستخدام استيثاق MD5 مع المستخدم postgres: local all postgres md5في النهاية، يجب أن تُعيد تشغيل خدمة PostgreSQL لتهيئة الضبط الجديد، وذلك بإدخال الأمر الآتي من الطرفية: sudo service postgresql restartتحذير: الضبط السابق ليس كاملًا بأي شكل من الأشكال، رجاءً راجع «PostgreSQL Administrator's Guide» لمعاملات ضبط إضافية. يمكنك اختبار اتصالات الخادوم من الأجهزة الأخرى باستخدام عملاء PostgreSQL: sudo apt-get install postgresql-client psql -h postgres.example.com -U postgres -Wملاحظة: استبدل اسم النطاق في المثال السابق باسم نطاقك الفعلي. مصادركما ذُكِر سابقًا، فإن «PostgreSQL Administrator's Guide» هو مصدر رائع، وهو متوفر أيضًا في حزمة postgresql-doc-9.1؛ نفذ ما يلي لتثبيت تلك الحزمة:sudo apt-get install postgresql-doc-9.1أدخِل الوصلة file:///usr/share/doc/postgresql-doc-9.1/html/index.html في شريط العنوان في متصفحك لمشاهدة الدليل.راجع أيضًا صفحة ويكي أوبنتو «PostgreSQL» لمزيدٍ من المعلومات.ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Databases.

تعدّ أنظمة إدارة قواعد البيانات العلاقية Relational database management systems، عنصرا أساسيا في الكثير من مواقع الويب والتطبيقات؛ فهي تتيح وسيلة مبنية لتخزين المعلومات، تنظيمها والوصول إليها. PostgrSQL (أو Postgres) هو نظام علاقي لإدارة قواعد البيانات يستخدم لغة الاستعلام SQL. يشيع استخدام PostgreSQL في المشاريع الصغيرة والكبيرة على حد السواء؛ ويتميز بتوافقه مع المعايير Standards ووجود خصائص متقدمة كثيرة مثل المعاملات Transactions الموثوقة والتزامن Concurrency دون قفل القراءة. يشرح هذا المقال كيفية تثبيت Postgres على Ubuntu 14.04 وبعض الأمور الأساسية لاستخدامه. التثبيتتحتوي المستودعات الافتراضية لأوبنتو على حزم Postgres لذا يمكننا تثبيته بدون متاعب. نبدأ بتحديث الحزم ثم تثبيت حزمتي postgresql وpostgresql-contrib. تثبت الحزمة الأخيرة أدوات مساعدة ووظائف إضافية: sudo apt-get update sudo apt-get install postgresql postgresql-contribنستطيع الآن بعد إكمال تثبيت البرنامج عرض كيفية عمله و فيمَ يختلف عن أنظمة إدارة قاعد البيانات المشابهة. استخدام قواعد بيانات PostgreSQL وأدواره Rolesيستخدم PostgreSQL مفهوم الدور للمساعدة في الاستيثاق Authentication والتصريح Authorization. يوجد شبه بين الأدوار في PostgreSQL وحسابات المستخدمين في الأنظمة الشبيهة بيونكس؛ إلا أن PostgreSQL لا يميّز بين المستخدمين والمجموعات ويفضل مفهوم الدور. يستخدم PostgreSQL مباشرة بعد تثبيته طريقة الاستيثاق ident التي تتمثل في ربط دور PostgreSQL بحساب موافق له على لينكس/يونكس. يمكن الولوج إلى دور Postgres - إن وُجد - بالولوج إلى حساب المستخدم الموافق له على النظام. تنشئ عملية التثبيت حساب مستخدم باسم postgres مربوطا بدور PostgreSQL الافتراضي. يجب الولوج إلى الحساب لكي نستطيع استخدام PostgreSQL؛ نفذ الأمر التالي لهذا الغرض: sudo -i -u postgresسيُطلب منك إدخال كلمة سرك الاعتيادية ثم تُنقَل إلى محث Prompt مستخدم PostgreSQL. نفذ الأمر التالي للحصول على محث PostgreSQL: psqlستُنقَل مباشرة إلى سطر أوامر يمكِّنك من التفاعل مع نظام قاعدة البيانات. سنشرح في الفقرات المقبلة كيفية استخدام الأدوار الأخرى وقواعد البيانات من أجل الحصول على مرونة أكثر في المستخدم وقاعدة البيانات الذين نريد العمل معهما. اخرج من محث PostgreSQL بتنفيذ الأمر: \qيعيدك الأمر إلى محث Shell الخاص بالمستخدم postgres. ملحوظة: إن نفذت الأمر psql دون الولوج إلى المستخدم postgres فستحصُل على رسالة خطأ تفيد بأن الدور الذي تستخدمه غير موجود. إنشاء دور جديديمكن لحساب postgres على لينكس الدخول إلى نظام قاعدة البيانات؛ إلا أن لديه أيضا إمكانية الوصول إلى أدوات لإنشاء الأدوار وقواعد البيانات نظرا لكونه مربوطا بالدور الإداري Postgres. نستخدم الأمر التالي لإنشاء دور جديد: createuser --interactiveالأمر في الأساس هو سكربت Shell تفاعلي يستدعي أوامر Postgres الصحيحة من أجل إنشاء دور وفقا لما تحدده. يطرح السكربت سؤالين الأول اسم الدور، والثاني هل يجب أن تكون لديه صلاحيات إدارية أم لا. في حال الإجابة بلا على السؤال الثاني تضاف بعض الأسئلة الأخرى مثل هل يُسمح له بإنشاء قاعدة بيانات. توجد خيارات أخرى للاستخدام مع أمر createuser يمكن الاطلاع عليها بتنفيذ الأمر: man createuserإنشاء قاعدة بيانات جديدةيفترض PostgreSQL عند تثبيته، إضافةً إلى طريقة الاستيثاق (ربط دور PostgreSQL بحساب موافق له على لينكس/يونكس)، وجودَ قاعدة بيانات موافقة للدور المراد الاتصال به. يعني هذا أنه إن كان يوجد دور باسم test1 فإنه سيحاول افتراضا (أي عند استخدام أمر psql دون خيارات إضافية) الاتصال بقاعدة بيانات باسم test1. ينشئ اﻷمر التالي قاعدة بيانات مناسبة: createdb test1استخدام الدور الجديد للاتصال بـPostgreSQLسنفترض أن لديك حساب لينكس باسم test1 (نفذ اﻷمر adduser test1 لإنشائه)، وأنك أنشأت دور PostgreSQL وقاعدة بيانات مع تسمية الدور وقاعدة البيانات بـtest1. نفذ الأمر التالي للانتقال لاستخدام الحساب test1 على لينكس: sudo -i -u test1ثم يمكنك بعدها الاتصال بقاعدة البيانات test1 بالدور test1: psqlستلج مباشرة إلى محث إدارة قاعدة البيانات. استخدم الخيار d- مع ذكر اسم قاعدة البيانات، إن أردت أن يتصل الدور بقاعدة بيانات مختلفة عن تلك الموافقة له في الاسم: psql -d postgresيعطيك الأمر التالي معلومات عن دور PostgreSQL الذي تستخدمه للاتصال وقاعدة البيانات التي تتصل بها: \conninfo You are connected to database "postgres" as user "postgres" via socket in "/var/run/postgresql" at port "5432". يساعد الأمر في تذكيرك بالإعدادات الحالية. إنشاء جداول البياناتنبدأ، بعد أن تعرفنا على كيفية الاتصال بنظام PostgreSQL لإدارة قواعد البيانات، بعرض طريقة تنفيذ بعض المهام الأساسية. سننشئ أولا جدولا Table نحفظ فيه بيانات، وليكن الجدول عن أدوات تُستخدَم في الملعب. في ما يلي الصيغة القاعدية لإنشاء جدول: CREATE TABLE table_name ( column_name1 col_type (field_length) column_constraints, column_name2 col_type (field_length), column_name3 col_type (field_length) );نبدأ بتعريف اسم جدول البيانات table_name، ثم الأعمدة Columns المكوِّنة للجدول (column_name2، column_name1 وcolumn_name3). نحدّد نوع البيانات التي يحويها كل عمود (col_type) وطولها (field_length). يمكن أيضا وضع قيود constraints على العمود (column_constraints). ننشئ لغرض التجربة الجدول المحدود التالي: CREATE TABLE playground ( equip_id serial PRIMARY KEY, type varchar (50) NOT NULL, color varchar (25) NOT NULL, location varchar(25) check (location in ('north', 'south', 'west', 'east', 'northeast', 'southeast', 'southwest', 'northwest')), install_date date );أنشأنا جدولا باسم playground لسرد بضع معدّات رياضية نمتلكها. العمود الأول من الجدول equip_id هو معرِّف الأداة ونوعه serial (عدد صحيح يزداد تلقائيّا مع كل إدخال للبيانات في الجدول). وضعنا القيد PRIMARY KEY على العمود الأول للإشارة إلى أن قيمة العمود يجب أن تكون وحيدة (أي لا توجد أداتان في الجدول لديهما نفس قيمة العمود الأول) وغير خاوية. العمودان الثاني والثالث يحدّدان على التوالي نوع الأداة ولونها؛ لا يمكن أن يكون أي من العمودين خاويا بسبب وضع القيد NOT NULL عليهما. وضعنا على العمود الرابع قيدا يتمثل في أن قيمة الحقل يجب أن تكون واحدة من ثمانية قيم ممكنة. يسجل العمود الأخير تاريخ تثبيت الأداة لذا أعطيناه نوع البيانات date. لم نحدّد لاثنين من الأعمدة طول البيانات، ويعود السبب في ذلك أن بعض الأنواع تحدد تلقائيا طول الحقل. نستخدم الأمر التالي لعرض الجداول الموجودة في قاعدة البيانات التي نعمل عليها: \dالنتيجة: List of relations Schema | Name | Type | Owner --------+-------------------------+----------+---------- public | playground | table | postgres public | playground_equip_id_seq | sequence | postgres (2 rows)يظهر جدول playground الذي أنشأناه؛ ولكن يوجد معه أمر آخر: playground_equip_id_seq وهو من نوع sequence (متتالية). المتتالية playground_equip_id_seq هي تمثيل لنوع البيانات serial الذي حددناه للعمود equip_id. تخزن المتتالية العدد الذي يجب أن تُعطَى قيمته للعمود عند العملية الموالية لإضافة البيانات في الجدول. يصبح الأمر على النحو التالي إن أردت رؤية الجداول فقط: \dtالنتيجة: List of relations Schema | Name | Type | Owner --------+------------+-------+---------- public | playground | table | postgres (1 row)إضافة تسجيلات لجدول، الاستعلام عنها وحذفهاالخطوة التالية لإنشاء جدول هي إضافة بيانات إليه. لإضافة تسجيلات Records إلى جدول نحدّد اسم الجدول، نسمي الأعمدة ثم نوفر البيانات لكل عمود. سنضيف لوح انزلاق Swing وأرجوحة Slide إلى جدول playground على النحو التالي: INSERT INTO playground (type, color, location, install_date) VALUES ('slide', 'blue', 'south', '2014-04-28'); INSERT INTO playground (type, color, location, install_date) VALUES ('swing', 'yellow', 'northwest', '2010-08-16'); لاحظ أن قيمة العمود يجب أن تكون بين ظفرين'' بينما لا يحتاج اسم العمود لذلك. لاحظ أيضا أننا لم نذكر اسم العمود equip_id ولم نعطه بالتالي قيمة. يعود السبب في ذلك إلى أن العمود من نوع serial أي أنه سيحصُل على قيمة موّلَّدة تلقائيا في كل مرة يُضاف فيها سطر (تسجيلة) جديد إلى الجدول. الاستعلام التالي يُظهِر جميع البيانات المخزَّنة في جدول playground: SELECT * FROM playground;النتيجة: equip_id | type | color | location | install_date ----------+-------+--------+-----------+-------------- 1 | slide | blue | south | 2014-04-28 2 | swing | yellow | northwest | 2010-08-16 (2 rows)تمكن ملاحظة أن العمود equip_id مُلئ بأعداد متتالية وأن البيانات الأخرى نُظِّمت على النحو المرغوب. افترض أن لوح الانزلاق كُسر ولم يعد ضمن المعدات التي نمتلكها؛ سنحتاج في هذه الحالة لحذفه من قاعدة البيانات، يؤدي الاستعلام التالي هذا الغرض: DELETE FROM playground WHERE type = 'slide';لنعد إظهار جميع البيانات الموجودة في الجدول: SELECT * FROM playground;النتيجة: equip_id | type | color | location | install_date ----------+-------+--------+-----------+-------------- 2 | swing | yellow | northwest | 2010-08-16 (1 row)حذف أو إضافة أعمدة إلى جدوليمكننا بسهولة إضافة أعمدة جديدة إلى جدول بعد إنشائه. يضيف الاستعلام التالي عمودا باسم last_maint لحفظ تاريخ آخر صيانة للأداة: ALTER TABLE playground ADD last_maint date;إن عرضنا البيانات المخزّنة في الجدول الآن فسنرى أن العمود الجديد أُضيف (غير أنه لا توجد به بيانات): SELECT * FROM playground;النتيجة: equip_id | type | color | location | install_date | last_maint ----------+-------+--------+-----------+--------------+------------ 2 | swing | yellow | northwest | 2010-08-16 | (1 row)يمكننا بطريقة مشابهة حذف عمود: ALTER TABLE playground DROP last_maint;تحديث بيانات جدولتناولنا كيفية إضافة تسجيلات إلى الجدول وحذفها، ولكننا لم نغطِّ بعد كيفية التعديل على بيانات موجودة. لتغيير قيمة موجودة في جدول البيانات نستعلم عن التسجيلة المُراد تعديلها ونسمي العمود الذي نريد تغيير قيمته ونعطي القيمة الجديدة. في المثال التالي نستعلم عن التسجيلات التي قيمة العمود type فيها تساوي swing ثم نبدِل قيمة العمود color في هذه التسجيلات إلى red. في حال وجود أكثر من تسجيلة ينطبق عليها الاستعلام فستُصبح قيمة العمود color فيها جميعا تساوي red. UPDATE playground SET color = 'red' WHERE type = 'swing';يمكن التأكد من نجاح تحديث البيانات بالاستعلام عن محتويات الجدول مرة أخرى: SELECT * FROM playground;النتيجة: equip_id | type | color | location | install_date | last_maint ----------+-------+-------+-----------+--------------+------------ 2 | swing | red | northwest | 2010-08-16 | (1 row)يظهر في نتيجة الاستعلام أن اللون الجديد (color) للأرجوحة (swing) هو الأحمر (red). ترجمة -وبتصرف- لمقال How To Install and Use PostgreSQL on Ubuntu 14.04 لصاحبه Justin Ellingwood.