لا تُظهر قاعدة البيانات البطيئة رسالة خطأ في كل مرة؛ غالباً ما تظهر على شكل صفحات تستغرق ثانيتين قبل أن تُعرض، ومستخدمين يضغطون على تحديث الصفحة. وعلى خادم VPS، نادراً ما يكون عنق الزجاجة حيث يبحث الجميع أولاً. قبل إضافة ذاكرة، من المفيد فهم ما يفعله القرص والذاكرة وعدد محدود من الإعدادات باستعلاماتك فعلاً: فيما يلي ترتيب القياس، وما يهم حقاً، ومتى يصبح الانتقال إلى خطة أعلى هو الجواب الصحيح.
لماذا تحدد قاعدة البيانات السرعة المحسوسة
في أي تطبيق إداري، يتبع زمن الاستجابة السلسلة نفسها في كل مرة: يصل الطلب، يستعلم التطبيق من قاعدة البيانات، يبحث المحرك عن الصفحات التي يحتاجها، ثم يعود بالنتيجة. يعمل المعالج بالميكروثانية، والقرص بالمللي ثانية: هذه الفجوة، مضروبة في آلاف المرات كل ساعة، هي ما يفصل واجهة سلسة عن واجهة مرهقة.
النتيجة العملية بسيطة: قاعدة بيانات مضبوطة جيداً على خادم صغير تتفوق غالباً على قاعدة مضبوطة بشكل سيئ على جهاز بضعف الحجم. العتاد يحدد السقف، والإعدادات تحدد المسافة بينك وبينه.
NVMe أم SATA: ما الذي يتغيّر فعلاً لمحرك قاعدة البيانات
ما يمنحه NVMe حقاً
لا يقرأ محرك قاعدة البيانات ملفات ضخمة دفعة واحدة، بل يقرأ صفحات بحجم 8 أو 16 كيلوبايت مبعثرة على وحدة التخزين، عدة صفحات في الوقت نفسه. هذا هو نمط الوصول العشوائي (Random Access)، وهو المجال الذي يتقدم فيه NVMe بأكبر فارق على الأقراص الميكانيكية، ويحافظ فيه على تفوقه على أقراص SATA. ويظهر الفرق في طوابير الانتظار قبل أن يظهر في مخططات معدل النقل.
ما لا يعالجه NVMe
لا يلغي القرص السريع استعلاماً مكتوباً بشكل سيئ: المسح الكامل للجدول، والفهرس الغائب، والفرز على عمود غير مفهرس، ستبقى بطيئة. كذلك تفقد وحدة تخزين NVMe ممتلئة بنسبة 95% معظم تفوقها، لأن المتحكم يضطر إلى إدارة استهلاك الخلايا وتُعاد جدولة عمليات الكتابة.
- زمن الاستجابة (Latency): ما يشعر به تطبيقك استعلاماً باستعلام.
- معدل النقل (Throughput): ما يهم في النسخ الاحتياطي والاستعادة.
- طول الطابور والمساحة الحرة: المؤشران على تخلف وحدة التخزين.
حجم البيانات النشط مقابل الذاكرة: نقطة التحول الحقيقية
حجم البيانات النشط (Working Set) هو مجموعة الصفحات التي تلمسها قاعدة البيانات فعلاً خلال يوم عمل: الفهارس الساخنة، وأكثر الجداول قراءة، وبعض الصفوف كثيفة الاستخدام. وطالما بقي هذا الحجم داخل الذاكرة المتاحة، يجيب المحرك دون الرجوع إلى القرص؛ وبمجرد أن يتجاوزه، يصبح كل استعلام بحاجة إلى قراءة فعلية من القرص.
لذلك قِس حجم البيانات النشط قبل أن تفكر بالجيجابايت. فهرس منتجات بحجم 20 جيجابايت، لا يُقرأ منه يومياً سوى 2 جيجابايت، لا يحتاج إلى 20 جيجابايت من الذاكرة؛ وبالمقابل، جدول بحجم 800 ميغابايت يُقرأ كاملاً عند كل اتصال سيُغرق جهازاً بذاكرة 1 جيجابايت. ثم راقب نسبة القراءات المخدومة من الذاكرة المؤقتة (Cache Hit Ratio): فإن بقيت دون 95%، فالذاكرة ناقصة قبل المعالج.
الإعدادات الستة التي تهم فعلاً
تفسر ستة معاملات معظم الفروق بين قاعدة بيانات بطيئة وأخرى مقبولة. تُضبط بهذا الترتيب، وواحداً في كل مرة.
الذاكرة الممنوحة للمحرك
shared_buffers في PostgreSQL وinnodb_buffer_pool_size في MariaDB وMySQL: هذه هي الذاكرة المؤقتة الداخلية للمحرك، التي تحتفظ بالصفحات الساخنة قريبة. ربع الذاكرة نقطة بداية معقولة في PostgreSQL؛ وعلى خادم مخصص لقاعدة البيانات يمكن رفع مخزن InnoDB أكثر. فمنح كل الذاكرة للمحرك يحرم نظام التشغيل من ذاكرة الملفات المؤقتة، وهي أيضاً تؤدي عملاً حقيقياً.
عمليات الفرز والاتصالات
تُحتسب work_mem لكل عملية فرز، لا لكل استعلام: فقيمة سخية مضروبة في خمسين اتصالاً متزامناً قد تستنفد الذاكرة. أما effective_cache_size فلا تخصص شيئاً، بل تخبر المخطط بما يستطيع النظام الاحتفاظ به في الذاكرة المؤقتة. وأخيراً تُضبط max_connections مع تجميع الاتصالات (Connection Pooling) في جانب التطبيق: عشر اتصالات نشطة مستغلة جيداً أفضل من مئتي اتصال في الانتظار.
الكتابة والمتانة
إعدادات المتانة (Durability) — مزامنة السجلات، وحجم سجل المعاملات، وتكرار نقاط التحقق — توازن بين الأمان والسرعة. فالتساهل فيها يسرّع الإدراج الكثيف، لكنه يعرّض آخر المعاملات للفقدان عند انقطاع مفاجئ: هذا قرار تشغيلي يجب توثيقه، وليس إعداداً يُنسخ من مدونة.
التخزين المؤقت أمام المحرك
الطبقة الأرخص ثمناً ليست داخل قاعدة البيانات في الغالب. فذاكرة مؤقتة للتطبيق تحتفظ بنتائج الاستعلامات المكلفة، وتخزين مؤقت كامل للصفحات موجه للزوار المجهولين، وشبكة توصيل محتوى (CDN) للملفات الثابتة، كلها تحذف آلاف الطلبات قبل أن تصل إلى الخادم. قاعدة أسرع بالضعف أقل أثراً من قاعدة تستعلمها نصف عدد المرات.
قِس قبل أن تضبط
الضبط دون نقطة مرجعية يشبه القيادة دون لوحة عدادات:
- ثبّت مرجعاً: زمن الاستجابة عند المئين 95، وعدد الاستعلامات في الثانية، وزمن أبطأ صفحة، في وقت الذروة وخارجه.
- رتّب الاستعلامات بحسب الزمن الكلي باستخدام pg_stat_statements أو performance_schema: ليس أبطأ استعلام، بل الذي يستهلك أكبر حصة من الزمن.
- راقب القرص: متوسط زمن الانتظار، ونسبة الاستخدام، وطول الطابور. فوحدة تخزين قاربت التشبع تفسر تباطؤاً أكثر من معالج يعمل بنسبة 60%.
- تحقق من الذاكرة: القراءات المخدومة من الذاكرة المؤقتة، واستخدام منطقة التبديل (Swap)، والذاكرة المتاحة الفعلية.
- غيّر إعداداً واحداً ثم أعد القياس في الظروف نفسها: تغيير إعدادين معاً يمنع معرفة أيّهما أفاد.
من الأخطاء الشائعة مقارنة قياس أُخذ أثناء إعادة بناء الفهارس بقياس من صباح هادئ. سجّل الوقت والحمل وعدد الاتصالات مع كل قياس.
أي خطة VPS تناسب أي حمل
يُستنتج الحجم المناسب من حجم البيانات النشط وعدد الاتصالات المتزامنة، لا من الحجم الكلي لقاعدة البيانات. يلخص الجدول الخطط الأربع المتوسطة؛ وتُنشر القائمة الكاملة للأسعار على صفحة الأسعار لدى Open Vista.
| الخطة | vCPU / الذاكرة | NVMe | الملف المناسب لقاعدة البيانات | دولار / شهر | درهم دون ضريبة / شهر |
|---|---|---|---|---|---|
| VPS-2G Business | 1 vCPU / 2 جيجابايت | 40 جيجابايت | حجم نشط بين 1 و1.5 جيجابايت، عشرات الاتصالات | 19.99 | 189.06 |
| VPS-3G Performance | 2 vCPU / 3 جيجابايت | 50 جيجابايت | قاعدة وتطبيق على الجهاز نفسه، ذاكرة مؤقتة معتدلة | 34.99 | 330.93 |
| VPS-4G Avancé | 2 vCPU / 4 جيجابايت | 80 جيجابايت | قاعدة مخصصة بحجم نشط بين 2 و3 جيجابايت، كتابة منتظمة | 39.99 | 378.22 |
| VPS-5G Ultra | 3 vCPU / 5 جيجابايت | 100 جيجابايت | حمل مختلط قراءة وكتابة، عدة قواعد أو قاعدة كبيرة واحدة | 49.99 | 472.80 |
تشمل كل خطة عنوان IPv4 مخصصاً، ونطاق ترددي غير محدود، ووصولاً كامل الجذر (Root)، ولوحة إدارة، ونسخاً احتياطية تلقائية، وجدار حماية مع حماية من هجمات DDoS، ومراقبة على مدار الساعة، ودعماً ستة أيام في الأسبوع، واتفاقية مستوى خدمة (SLA) بنسبة 99.9% على البنية التحتية. تُستضاف الخوادم في مركز بيانات بنيويورك؛ ويوجد مركز بيانات مُعلن في الرباط، لكنه لم يُفتح بعد. ويتم التسليم في أقل من خمس عشرة دقيقة، والانتقال إلى خطة أعلى يتم دون ترحيل مؤلم.
الأسئلة الشائعة (FAQ)
هل أحتاج ذاكرة أكبر أم معالجاً أقوى لقاعدة بيانات بطيئة؟
ابدأ بنسبة القراءات المخدومة من الذاكرة المؤقتة وبمعدل استخدام القرص. فنسبة لا ترتفع وطوابير قرص تطول تشيران إلى الذاكرة والإدخال والإخراج، لا إلى المعالج. أما معالج قارب التشبع مع ذاكرة مؤقتة مريحة فيشير إلى الحساب: راجع الفهارس والاستعلامات قبل شراء عتاد إضافي.
هل يمكن استضافة قاعدة البيانات والتطبيق على خادم VPS واحد؟
نعم، وهذا هو السيناريو الأكثر شيوعاً حتى عشرات الآلاف من الزيارات الشهرية. يجب عندئذ حجز ذاكرة المحرك بحذر، وتحديد سقف للاتصالات، ومراقبة الذرى: فمهمة استيراد واحدة قد تستهلك الذاكرة التي تحتاجها قاعدة البيانات. ويصبح فصل الجهازين مجدياً عندما تتنافس الحمولتان على المورد نفسه في الساعات نفسها.
هل يكفي NVMe لجعل قاعدة البيانات سريعة؟
لا. يخفّض NVMe كلفة القراءات العشوائية، وهذا يساعد كثيراً عندما يتجاوز حجم البيانات النشط الذاكرة، لكنه لا يعوض فهرساً غائباً أو فرزاً في موضع خاطئ. وعلى قاعدة يتسع حجمها النشط للذاكرة، يكون أثر قرص أسرع محدوداً: أصلح الاستعلامات أولاً.
كيف أعرف أن وحدة التخزين هي عنق الزجاجة؟
قارن متوسط زمن الانتظار على عمليات الإدخال والإخراج بزمن استجابة التطبيق، وراقب طول الطابور خلال فترة مزدحمة. فإن ارتفع الاثنان معاً كانت وحدة التخزين هي السبب. وإن بقي زمن القرص منخفضاً بينما يتباطأ التطبيق، فابحث في الأقفال أو نفاد الاتصالات.
الخلاصة: قِس، ثم اضبط، ثم حدد الحجم
قاعدة البيانات السريعة على خادم VPS ليست مسألة ميزانية في الغالب، بل مسألة ترتيب العمليات: قِس زمن الاستجابة الحقيقي، ورتّب الاستعلامات بحسب الكلفة الكلية، وتأكد من أن حجم البيانات النشط يتسع للذاكرة، ثم غيّر إعداداً واحداً في كل مرة. وفي معظم الحالات يمنحك هذا العمل أكثر مما يمنحه الانتقال إلى جهاز أكبر، ويجعل ذلك الانتقال مفيداً فعلاً عندما يصبح ضرورياً.
الخطوة التالية عملية: افتح صفحة خوادم VPS NVMe لدى Open Vista، وقارن الخطط الخمس بحسب حجم بياناتك النشط المقاس، واختر ما يناسب حملك الحالي. وإن ترددت بين مستويين فابدأ بالأصغر، لأن الترقية تتم دون ترحيل مؤلم في الشهر التالي.