لماذا تستضيف قاعدة بياناتك على VPS الخاص بك
استضافة قاعدة بياناتك ذاتيًا على VPS تمنحك سيطرة كاملة على إصدار المحرك، ومعاملات الضبط (tuning)، والتشفير، وزمن استجابة الشبكة نحو تطبيقك. وبدلًا من تحمّل حدود الاتصالات والتكلفة الإضافية لقاعدة بيانات مُدارة، تضع قاعدة البيانات والتطبيق معًا على الشبكة الخاصة نفسها للحصول على استجابات دون المللي ثانية. يتفوّق PostgreSQL في المخططات المعقّدة والقيود الصارمة وJSONB القابل للفهرسة والاستعلامات التحليلية والإضافات (PostGIS، pg_trgm، البحث في النص الكامل). أما MySQL (أو MariaDB) فيظل لا يُضاهى في البساطة، مدعوم جيدًا من أنظمة إدارة المحتوى وأطر PHP، مع قراءات سريعة. يعتمد الخيار الصحيح على طبيعة بياناتك، لا على تفضيل مبدئي.
ما الذي تقدّمه الاستضافة الذاتية لقاعدة بياناتك
- زمن استجابة أدنى بوضع قاعدة البيانات على الشبكة الخاصة نفسها للتطبيق
- سيطرة كاملة على الضبط:
shared_buffersوinnodb_buffer_pool_sizeوالحد الأقصى للاتصالات - حرية اختيار الإصدار وجدول التحديث
- نسخ احتياطية منطقية وفيزيائية مجدولة حسب احتياجاتك الفعلية
- تناسخ وقراءة موزّعة مُعدَّان على طريقتك
- تشفير أثناء السكون ووصول مقيَّد بالشبكة الداخلية للـ VPS فقط
متطلبات قاعدة بيانات على VPS
قاعدة بيانات تطوير أو موقع صغير تعيش بأريحية على 1 vCPU و1 غيغابايت من الذاكرة. في الإنتاج، القاعدة الذهبية هي تحجيم الذاكرة كي يتّسع فهرس العمل في التخزين المؤقت: استهدف 2 إلى 4 غيغابايت لـ PostgreSQL (shared_buffers حوالي 25% من الذاكرة) وinnodb_buffer_pool_size يغطي مجموعة بياناتك النشطة في MySQL. قرص SSD/NVMe غير قابل للتفاوض بالنسبة إلى عمليات الكتابة. جهّز Docker وCompose، ووحدة تخزين دائمة مخصصة للبيانات، والأهم: لا تكشف منفذ قاعدة البيانات على الإنترنت أبدًا. يتم الوصول عبر شبكة Docker الداخلية أو نفق SSH.
نشر PostgreSQL (أو MySQL) على VPS باستخدام Docker
إنشاء وحدة تخزين دائمة
عرِّف وحدة تخزين باسم pgdata (أو mysqldata) في Compose. لا تخزّن البيانات أبدًا في الطبقة الزائلة للحاوية: يجب ألا يدمّر docker compose down قاعدة بياناتك.
ضبط الخدمة والأسرار
عرِّف الصورة postgres:16 أو mysql:8، وأدخِل بيانات الاعتماد عبر ملف .env (لا تضعها نصًا صريحًا في ملف compose)، واربط المنفذ محليًا فقط: 127.0.0.1:5432:5432. يجب ألا تكون قاعدة البيانات قابلة للوصول من الخارج.
التشغيل والتحقق
نفِّذ docker compose up -d ثم اختبر الاتصال داخليًا بـ docker compose exec db psql -U app -d maBase (أو mysql -u). تحقّق من الترميز (UTF8/utf8mb4) منذ الإنشاء لتجنّب المفاجآت.
تطبيق الضبط
ركِّب ملف إعدادات مخصصًا لضبط shared_buffers وwork_mem وmax_connections (PostgreSQL) أو innodb_buffer_pool_size وmax_connections (MySQL) وفقًا للذاكرة الفعلية للـ VPS. أعِد تشغيل الخدمة للتطبيق.
إعداد النسخ الاحتياطية
جدوِل تفريغًا منتظمًا عبر cron: pg_dump أو mysqldump مضغوطًا ومنسوخًا خارج الـ VPS. اختبر الاستعادة: نسخة احتياطية لم تُستعَد أبدًا ليست نسخة احتياطية.
تأمين وصول التطبيق
اجعل التطبيق وقاعدة البيانات يتواصلان عبر شبكة Docker الداخلية فقط. للوصول الإداري عن بُعد، استخدم نفق SSH بدلًا من فتح المنفذ. أنشئ مستخدمًا للتطبيق بصلاحيات محدودة، منفصلًا عن المستخدم الخارق (superuser).
| المعيار | PostgreSQL | MySQL / MariaDB |
|---|---|---|
| نموذج البيانات | غني: أنواع مخصصة، مصفوفات، JSONB | متين، أكثر كلاسيكية |
| دعم JSON | JSONB قابل للفهرسة وعالي الأداء | JSON موجود، فهرسة أكثر محدودية |
| الامتثال لـ SQL / القيود | صارم جدًا (CHECK، الأنواع، معاملات DDL) | أكثر تساهلًا |
| البحث في النص الكامل / الجغرافي | أصلي + PostGIS، pg_trgm | أساسي، إضافات طرف ثالث |
| قراءات بسيطة عالية التردد | جيدة جدًا | ممتازة ومُحسَّنة جدًا |
| التناسخ | بثّي، منطقي | سيّد-تابع، سهل الإعداد |
| منظومة CMS/PHP | جيدة | المرجع (WordPress، إلخ) |
| بصمة الذاكرة | معتدلة | خفيفة إلى معتدلة |
أيًّا كان المحرك، لا تدع تطبيق ويب يفتح اتصالًا مباشرًا لكل طلب: في PostgreSQL ضع PgBouncer كمُجمِّع (pooler)، وفي MySQL اضبط max_connections مع تجميع (pool) من جهة التطبيق. الـ VPS الذي ينهار تحت الحِمل يعاني في الغالب من مشكلة اتصالات غير مُجمَّعة أكثر من نقص القدرة الخام.
