فصل 3. إدارة PostGIS

قائمة المحتويات

3.1. ضبط الأداء

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

للاطلاع على تفاصيل عامة حول تحسين PostgreSQL، راجع ضبط خادم PostgreSQL.

في PostgreSQL 9.4+ يمكن ضبط الإعدادات على مستوى الخادم دون المساس بالملفين postgresql.conf أو postgresql.auto.conf وذلك باستخدام الأمر ALTER SYSTEM.

ALTER SYSTEM SET work_mem = '256MB';
-- this forces non-startup configs to take effect for new connections
SELECT pg_reload_conf();
-- show current setting value
-- use SHOW ALL to see all settings
SHOW work_mem;

إضافةً إلى إعدادات Postgres، لدى PostGIS بعض الإعدادات المخصصة المذكورة في قسم 7.22, “المتغيرات المخصصة الموحّدة الكبرى (GUCs)”.

3.1.1. عند بدء التشغيل

تُضبط هذه الإعدادات في postgresql.conf:

constraint_exclusion

القيمة الافتراضية: partition
يُستخدم هذا عمومًا لتقسيم الجداول (partitioning). وقيمته الافتراضية "partition"، وهي مثالية لـ PostgreSQL 8.4 وما بعده، إذ تُجبر المخطِّط على تحليل الجداول لمراعاة القيود فقط إذا كانت ضمن تسلسل وراثي، وتجنّبه كلفة ذلك في غير هذه الحالة.

shared_buffers

القيمة الافتراضية: نحو 128MB في PostgreSQL 9.6
اضبطه على ما بين 25% و40% تقريبًا من ذاكرة RAM المتاحة. قد لا تتمكن على Windows من ضبطه على قيمة بهذا الارتفاع.

max_worker_processes هذا الإعداد متاح فقط في PostgreSQL 9.4+. وفي PostgreSQL 9.6+ تزداد أهمية هذا الإعداد لأنه يتحكم في الحد الأقصى لعدد العمليات المتاحة للاستعلامات المتوازية.

القيمة الافتراضية: 8
يحدد الحد الأقصى لعدد العمليات الخلفية التي يمكن للنظام دعمها. لا يمكن ضبط هذا المعامل إلا عند بدء تشغيل الخادم.

3.1.2. أثناء التشغيل

work_mem - يحدد حجم الذاكرة المستخدمة لعمليات الفرز والاستعلامات المعقدة

القيمة الافتراضية: 1-4MB
ارفع قيمته لقواعد البيانات الكبيرة والاستعلامات المعقدة ووفرة ذاكرة RAM
اخفض قيمته عند وجود عدد كبير من المستخدمين المتزامنين أو قلة ذاكرة RAM.
إذا كانت لديك ذاكرة RAM كبيرة وعدد قليل من المطورين:
```
SET work_mem TO '256MB';
```

maintenance_work_mem - حجم الذاكرة المستخدمة لعمليات VACUUM وCREATE INDEX وغيرها.

القيمة الافتراضية: 16-64MB
منخفضة جدًا عمومًا، مما يُشغل عمليات الإدخال/الإخراج ويقفل الكائنات أثناء تبديل الذاكرة
يُوصى بقيمة بين 32MB و1GB على خوادم الإنتاج ذات ذاكرة RAM الكبيرة، لكن ذلك يعتمد على عدد المستخدمين المتزامنين. إذا كانت لديك ذاكرة RAM كبيرة وعدد قليل من المطورين:
```
SET maintenance_work_mem TO '1GB';
```

max_parallel_workers_per_gather

هذا الإعداد متاح فقط في PostgreSQL 9.6+ ولن يؤثر إلا في PostGIS 2.3+، لأن PostGIS 2.3+ وحده يدعم الاستعلامات المتوازية. إذا ضُبط على قيمة أعلى من 0، فإن بعض الاستعلامات، كتلك التي تتضمن دوال العلاقات مثل ST_Intersects، يمكنها استخدام عدة عمليات، وقد تعمل حينها بسرعة تزيد على الضعف. إذا كان لديك عدد كبير من المعالجات الفائضة، فعليك تغيير قيمته إلى عدد المعالجات المتوفرة لديك. وتأكد أيضًا من رفع max_worker_processes إلى قيمة لا تقل عن هذا العدد.

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

3.2. تهيئة دعم الرستر

إذا فعّلت دعم الرستر فقد ترغب في قراءة ما يلي لمعرفة كيفية تهيئته تهيئةً صحيحة.

اعتبارًا من PostGIS 2.1.3، تكون الرسترات المخزّنة خارج قاعدة البيانات (out-db) وجميع مشغّلات الرستر معطّلةً افتراضيًا. ولإعادة تفعيلها، يلزمك ضبط متغيرَي البيئة التاليين POSTGIS_GDAL_ENABLED_DRIVERS وPOSTGIS_ENABLE_OUTDB_RASTERS في بيئة الخادم. وفي PostGIS 2.2 يمكنك استخدام الطريقة الأكثر توافقًا بين المنصات بضبط قسم 7.22, “المتغيرات المخصصة الموحّدة الكبرى (GUCs)” المقابلة.

إذا أردت تفعيل الرستر غير المتصل (المخزّن خارج قاعدة البيانات):

POSTGIS_ENABLE_OUTDB_RASTERS=1

أي إعداد آخر أو عدم وجود إعداد على الإطلاق سيعطّل الرسترات المخزّنة خارج قاعدة البيانات.

لتفعيل جميع مشغّلات GDAL المتاحة في تثبيت GDAL لديك، اضبط متغير البيئة هذا كما يلي

POSTGIS_GDAL_ENABLED_DRIVERS=ENABLE_ALL

إذا أردت تفعيل مشغّلات محددة فقط، فاضبط متغير البيئة كما يلي:

POSTGIS_GDAL_ENABLED_DRIVERS="GTiff PNG JPEG GIF XYZ"


	إذا كنت تعمل على Windows، فلا تضع قائمة المشغّلات بين علامتي اقتباس

تختلف طريقة ضبط متغيرات البيئة باختلاف نظام التشغيل. بالنسبة إلى PostgreSQL المثبّت على Ubuntu أو Debian عبر apt-postgresql، فالطريقة المفضّلة هي تحرير الملف /etc/postgresql/10/main/environment حيث يشير 10 إلى إصدار PostgreSQL ويشير main إلى العنقود (cluster).

على Windows، إذا كنت تشغّل PostgreSQL كخدمة، يمكنك الضبط عبر متغيرات النظام (System variables)، والتي يمكنك الوصول إليها في Windows 7 بالنقر بزر الفأرة الأيمن على Computer->Properties Advanced System Settings أو بالانتقال في المستكشف إلى Control Panel\All Control Panel Items\System. ثم النقر على Advanced System Settings ->Advanced->Environment Variables وإضافة متغيرات نظام جديدة.

بعد ضبط متغيرات البيئة، ستحتاج إلى إعادة تشغيل خدمة PostgreSQL لكي تسري التغييرات.

3.3. إنشاء قواعد بيانات مكانية

3.3.1. تفعيل الدعم المكاني لقاعدة البيانات باستخدام EXTENSION

إذا كنت تستخدم PostgreSQL 9.1+ وقمت بتصريف وتثبيت وحدات extensions/postgis، فيمكنك تحويل قاعدة بيانات إلى قاعدة بيانات مكانية باستخدام آلية EXTENSION.

يتضمن امتداد postgis الأساسي الأنواع geometry وgeography والجدول spatial_ref_sys وجميع الدوال والتعليقات. أما الرستر والطوبولوجيا فهما محزّمان كامتدادين منفصلين.

شغّل مقتطف SQL التالي في قاعدة البيانات التي تريد تفعيل الدعم المكاني فيها:

CREATE EXTENSION IF NOT EXISTS plpgsql;
      CREATE EXTENSION postgis;
      CREATE EXTENSION postgis_raster; -- OPTIONAL
      CREATE EXTENSION postgis_topology; -- OPTIONAL

3.3.2. تفعيل الدعم المكاني لقاعدة البيانات دون استخدام EXTENSION (غير مستحسن)


	لا يلزم هذا عمومًا إلا إذا كنت لا تستطيع أو لا ترغب في تثبيت PostGIS في دليل امتدادات PostgreSQL (مثلًا أثناء الاختبار أو التطوير أو في بيئة مقيّدة).

تتم إضافة كائنات PostGIS وتعريفات دوالها إلى قاعدة بياناتك بتحميل ملفات sql المختلفة الموجودة في [prefix]/share/contrib كما حُدّد أثناء مرحلة البناء.

توجد كائنات PostGIS الأساسية (النوعان geometry وgeography ودوال دعمهما) في السكربت postgis.sql. وتوجد كائنات الرستر في السكربت rtpostgis.sql. وتوجد كائنات الطوبولوجيا في السكربت topology.sql.

للحصول على مجموعة كاملة من معرّفات تعريفات أنظمة الإحداثيات EPSG، يمكنك أيضًا تحميل ملف التعريفات spatial_ref_sys.sql وتعبئة الجدول spatial_ref_sys. سيتيح لك ذلك إجراء عمليات ST_Transform() على الأشكال الهندسية.

إذا رغبت في إضافة تعليقات إلى دوال PostGIS، فستجدها في السكربت postgis_comments.sql. ويمكن عرض التعليقات بمجرد كتابة \dd [function_name] من نافذة طرفية psql.

شغّل أوامر Shell التالية في الطرفية:

DB=[yourdatabase]
    SCRIPTSDIR=`pg_config --sharedir`/contrib/postgis-3.5/

    # Core objects
    psql -d ${DB} -f ${SCRIPTSDIR}/postgis.sql
    psql -d ${DB} -f ${SCRIPTSDIR}/spatial_ref_sys.sql
    psql -d ${DB} -f ${SCRIPTSDIR}/postgis_comments.sql # OPTIONAL

    # Raster support (OPTIONAL)
    psql -d ${DB} -f ${SCRIPTSDIR}/rtpostgis.sql
    psql -d ${DB} -f ${SCRIPTSDIR}/raster_comments.sql # OPTIONAL

    # Topology support (OPTIONAL)
    psql -d ${DB} -f ${SCRIPTSDIR}/topology.sql
    psql -d ${DB} -f ${SCRIPTSDIR}/topology_comments.sql # OPTIONAL

3.4. ترقية قواعد البيانات المكانية

قد تكون ترقية قواعد البيانات المكانية الموجودة أمرًا صعبًا لأنها تتطلب استبدال تعريفات كائنات PostGIS أو إدخال تعريفات جديدة.

للأسف لا يمكن استبدال جميع التعريفات بسهولة في قاعدة بيانات قيد التشغيل، لذا قد يكون الخيار الأفضل أحيانًا هو عملية التفريغ وإعادة التحميل (dump/reload).

يوفّر PostGIS إجراء ترقية مرنة (SOFT UPGRADE) للإصدارات الفرعية أو إصدارات إصلاح الأخطاء، وإجراء ترقية كاملة (HARD UPGRADE) للإصدارات الرئيسية.

قبل محاولة ترقية PostGIS، يُستحسن دائمًا أخذ نسخة احتياطية من بياناتك. إذا استخدمت الخيار -Fc مع pg_dump فستتمكن دائمًا من استعادة التفريغ بترقية كاملة (HARD UPGRADE).

3.4.1. الترقية المرنة

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

3.4.1.1. الترقية المرنة في 9.1+ باستخدام الامتدادات

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

إذا كنت تستخدم PostGIS 3 أو أحدث، فعليك استخدام الدالة PostGIS_Extensions_Upgrade للترقية إلى أحدث إصدار مثبّت لديك.

SELECT postgis_extensions_upgrade();

إذا كنت تستخدم PostGIS 2.5 أو أقدم، فنفّذ ما يلي:

ALTER EXTENSION postgis UPDATE;
SELECT postgis_extensions_upgrade();
-- This second call is needed to rebundle postgis_raster extension
SELECT postgis_extensions_upgrade();

إذا كانت لديك عدة إصدارات مثبّتة من PostGIS ولا تريد الترقية إلى أحدثها، فيمكنك تحديد الإصدار صراحةً كما يلي:

ALTER EXTENSION postgis UPDATE TO "3.6.4";
ALTER EXTENSION postgis_topology UPDATE TO "3.6.4";

إذا ظهر لك إشعار خطأ يشبه ما يلي:

No migration path defined for … to 3.6.4

فستحتاج إلى أخذ نسخة احتياطية من قاعدة بياناتك، وإنشاء قاعدة بيانات جديدة كما هو موضّح في قسم 3.3.1, “تفعيل الدعم المكاني لقاعدة البيانات باستخدام EXTENSION”، ثم استعادة النسخة الاحتياطية فوق قاعدة البيانات الجديدة هذه.

إذا ظهرت لك رسالة إشعار مثل:

Version "3.6.4" of extension "postgis" is already installed

فهذا يعني أن كل شيء محدَّث بالفعل ويمكنك تجاهلها بأمان. إلا إذا كنت تحاول الترقية من إصدار تطويري إلى الإصدار التالي (الذي لا يحصل على رقم إصدار جديد)؛ وفي هذه الحالة يمكنك إلحاق "next" بسلسلة الإصدار، وفي المرة التالية ستحتاج إلى حذف اللاحقة "next" مجددًا:

ALTER EXTENSION postgis UPDATE TO "3.6.4next";
ALTER EXTENSION postgis_topology UPDATE TO "3.6.4next";


	إذا كنت قد ثبّتّ PostGIS في الأصل دون تحديد إصدار، فيمكنك غالبًا تخطّي إعادة تثبيت امتداد postgis قبل الاستعادة، لأن النسخة الاحتياطية تحتوي فقط على `CREATE EXTENSION postgis` وبالتالي تلتقط أحدث إصدار أثناء الاستعادة.

إذا كنت تُرقّي امتداد PostGIS من إصدار سابق للإصدار 3.0.0، فسيظهر لديك امتداد جديد هو postgis_raster يمكنك حذفه بأمان إن لم تكن بحاجة إلى دعم الرستر. يمكنك حذفه كما يلي:

DROP EXTENSION postgis_raster;

3.4.1.2. الترقية المرنة لما قبل 9.1+ أو دون امتدادات

ينطبق هذا القسم فقط على من ثبّتوا PostGIS دون استخدام الامتدادات. إذا كانت لديك امتدادات وحاولت الترقية بهذه الطريقة فستظهر لك رسائل مثل:

can't drop … because postgis extension depends on it

ملاحظة: إذا كنت تنتقل من PostGIS 1.* إلى PostGIS 2.* أو من PostGIS 2.* السابق للمراجعة r7409، فلا يمكنك استخدام هذا الإجراء بل ستحتاج إلى إجراء ترقية كاملة (HARD UPGRADE).

بعد التصريف والتثبيت (make install) يُفترض أن تجد مجموعة من ملفات *_upgrade.sql في مجلدات التثبيت. يمكنك سردها جميعًا باستخدام:

ls `pg_config --sharedir`/contrib/postgis-3.6.4/*_upgrade.sql

حمّلها جميعًا بالترتيب، بدءًا من postgis_upgrade.sql.

psql -f postgis_upgrade.sql -d your_spatial_database

ينطبق الإجراء نفسه على امتدادات الرستر والطوبولوجيا وsfcgal، مع ملفات ترقية تحمل الأسماء rtpostgis_upgrade.sql وtopology_upgrade.sql وsfcgal_upgrade.sql على التوالي. إن كنت بحاجة إليها:

psql -f rtpostgis_upgrade.sql -d your_spatial_database

psql -f topology_upgrade.sql -d your_spatial_database

psql -f sfcgal_upgrade.sql -d your_spatial_database

يُنصح بالتحول إلى تثبيت قائم على الامتدادات بتشغيل

psql -c "SELECT postgis_extensions_upgrade();"


	إذا لم تجد ملف `postgis_upgrade.sql` الخاص بترقية إصدارك، فأنت تستخدم إصدارًا أقدم من أن تصلح له الترقية المرنة وتحتاج إلى إجراء ترقية كاملة (HARD UPGRADE).

يُفترض أن تُعلمك الدالة PostGIS_Full_Version بالحاجة إلى إجراء هذا النوع من الترقية عبر رسالة "procs need upgrade".

3.4.2. الترقية الكاملة

نعني بالترقية الكاملة (HARD UPGRADE) التفريغ وإعادة التحميل الكاملين لقواعد البيانات المفعّل فيها PostGIS. تحتاج إلى ترقية كاملة عندما يتغير التخزين الداخلي لكائنات PostGIS أو عندما لا تكون الترقية المرنة ممكنة. ويذكر ملحق ملاحظات الإصدار لكل إصدار ما إذا كنت تحتاج إلى التفريغ وإعادة التحميل (HARD UPGRADE) للترقية.

يُساعد في عملية التفريغ وإعادة التحميل السكربت postgis_restore الذي يتولى تخطّي جميع التعريفات التابعة لـ PostGIS (بما فيها القديمة) من التفريغ، مما يتيح لك استعادة مخططاتك وبياناتك إلى قاعدة بيانات مثبّت فيها PostGIS دون ظهور أخطاء تكرار الرموز أو نقل كائنات مهجورة.

تتوفر تعليمات إضافية لمستخدمي Windows في الترقية الكاملة على Windows.

الإجراء كما يلي:

أنشئ تفريغًا بـ"التنسيق المخصص" (custom-format) لقاعدة البيانات التي تريد ترقيتها (لنسمّها olddb) متضمنًا الكائنات الثنائية الكبيرة (-b) ومخرجات مفصّلة (-v). يمكن أن يكون المستخدم مالك قاعدة البيانات، ولا يلزم أن يكون حساب postgres الفائق.
```
pg_dump -h localhost -p 5432 -U postgres -Fc -b -v -f "/somepath/olddb.backup" olddb
```
ثبّت PostGIS تثبيتًا جديدًا في قاعدة بيانات جديدة، وسنشير إلى قاعدة البيانات هذه باسم newdb. يُرجى الرجوع إلى قسم 3.3.2, “تفعيل الدعم المكاني لقاعدة البيانات دون استخدام EXTENSION (غير مستحسن)” وقسم 3.3.1, “تفعيل الدعم المكاني لقاعدة البيانات باستخدام EXTENSION” للاطلاع على تعليمات القيام بذلك.

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

إذا كانت قاعدة بياناتك قديمة جدًا أو كنت تعلم أنك تستخدم دوالًا مهجورة منذ زمن طويل في عروضك ودوالك، فقد تحتاج إلى تحميل legacy.sql لكي تعود جميع دوالك وعروضك وغيرها على نحو صحيح. لا تفعل ذلك إلا عند الحاجة الفعلية. وفكّر بدلًا من ذلك في تحديث عروضك ودوالك قبل التفريغ إن أمكن. ويمكن لاحقًا إزالة الدوال المهجورة بتحميل uninstall_legacy.sql.
استعِد نسختك الاحتياطية إلى قاعدة البيانات الجديدة newdb باستخدام postgis_restore. ستطبع psql الأخطاء غير المتوقعة، إن وُجدت، إلى مجرى الخطأ القياسي. احتفظ بسجل لها.
```
postgis_restore "/somepath/olddb.backup" | psql -h localhost -p 5432 -U postgres newdb 2> errors.txt
```

قد تظهر أخطاء في الحالات التالية:

بعض عروضك أو دوالك تستخدم كائنات PostGIS مهجورة. ولإصلاح ذلك يمكنك محاولة تحميل السكربت legacy.sql قبل الاستعادة، وإلا فعليك الاستعادة إلى إصدار من PostGIS لا يزال يحتوي على تلك الكائنات ثم محاولة الترحيل مجددًا بعد تحديث شيفرتك. وإذا نجحت معك طريقة legacy.sql، فلا تنسَ إصلاح شيفرتك للتوقف عن استخدام الدوال المهجورة ثم حذفها بتحميل uninstall_legacy.sql.
بعض السجلات المخصصة في spatial_ref_sys داخل ملف التفريغ لها قيمة SRID غير صالحة. قيم SRID الصالحة أكبر من 0 وأصغر من 999000. القيم في النطاق 999000.999999 محجوزة للاستخدام الداخلي، بينما القيم > 999999 لا يمكن استخدامها إطلاقًا. ستُحفظ جميع سجلاتك المخصصة ذات قيم SRID غير الصالحة، مع نقل ما كان منها > 999999 إلى النطاق المحجوز، لكن الجدول spatial_ref_sys سيفقد قيد التحقق (check constraint) الذي يضمن بقاء هذا الشرط، وربما أيضًا مفتاحه الأساسي (عندما تتحول عدة قيم SRID غير صالحة إلى قيمة SRID المحجوزة نفسها).

لإصلاح ذلك عليك نسخ النظام المرجعي المكاني المخصص لديك إلى SRID ذي قيمة صالحة (ربما في النطاق 910000..910999)، وتحويل جميع جداولك إلى قيمة SRID الجديدة (انظر UpdateGeometrySRID)، وحذف المُدخل غير الصالح من spatial_ref_sys، ثم إعادة إنشاء قيد (قيود) التحقق باستخدام:
```
ALTER TABLE spatial_ref_sys ADD CONSTRAINT spatial_ref_sys_srid_check check (srid 
> 0 AND srid < 999000 );
```
```
ALTER TABLE spatial_ref_sys ADD PRIMARY KEY(srid));
    
```
إذا كنت تُرقّي قاعدة بيانات قديمة تحتوي على خرائط IGN الفرنسية، فمن المحتمل أن تكون لديك قيم SRID خارج النطاق، وسترى عند استيراد قاعدة بياناتك مشكلات مثل هذه:
```
WARNING: SRID 310642222 converted to 999175 (in reserved zone)
```
في هذه الحالة، يمكنك تجربة الخطوات التالية: أولًا أزِل IGN كليًا من ملف sql الناتج عن postgis_restore. أي بعد تشغيل:
```
postgis_restore "/somepath/olddb.backup" > olddb.sql
```
شغّل هذا الأمر:
```
grep -v IGNF olddb.sql > olddb-without-IGN.sql
```
ثم أنشئ قاعدة البيانات newdb، وفعّل امتدادات PostGIS المطلوبة، وأدرج نظام IGN الفرنسي على نحو صحيح باستخدام: هذا السكربت وبعد هذه العمليات، استورد بياناتك:
```
psql -h localhost -p 5432 -U postgres -d newdb -f olddb-without-IGN.sql  2> errors.txt
```