أفضل VPS لاستضافة قواعد البيانات: اختر الإعداد المناسب لحمل عملك

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

عند شراء VPS غير مُدار، تتحمل أيضًا مسؤولية تشغيل قاعدة البيانات. تختلف ميزانيات الذاكرة بين PostgreSQL وMySQL وMariaDB، ويجب تصميم سعة التعافي مع الخادم الأساسي. ينبغي أن يترك الإعداد الأولي مساحة لعمليات النسخ الاحتياطي والصيانة، ثم يجتاز اختبارًا يمثل حمل العمل.

حدّد حجم حمل قاعدة البيانات قبل اختيار الخطة

قِس البيانات والفهارس النشطة، والعمل المتزامن للاستعلامات وقت الذروة، والنمو ومتطلبات التعافي قبل اختيار CPU والذاكرة والقرص. أضف الموارد بحسب القيد المقاس. احتسب مساحة الصيانة وذروة استهلاك التطبيق إذا شارك المضيف؛ يجب أن تغطي الميزانية فترات الانشغال والتشغيل العادي.

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

استخلص متطلبات الشراء من فترة انشغال ممثلة:

• قِس ذروة ذاكرة التطبيق إذا كان سيشارك VPS.
• سجّل حجم البيانات والفهارس، وتقدير مجموعة العمل، والعمليات المتزامنة، والنمو خلال أفق السعة المخطط.
• قِس توليد السجلات وحدّد أكبر عملية متوقعة لبناء فهرس أو إعادة كتابة جدول أو صيانة أخرى.
• حدّد هدف زمن استجابة p95 للتطبيق، ونافذة فقد البيانات المقبولة، والوقت المستهدف للاستعادة.
• قرّر مكان تشغيل التطبيق واختبر المسار بينه وبين قاعدة البيانات.

توصي وثائق المراقبة في PostgreSQL بجمع إحصاءات القاعدة مع أدوات نظام التشغيل. اجمع CPU وضغط الذاكرة ونشاط القرص مع أزمنة الاستعلامات والإيداع. يستلزم ارتفاع زمن الاستجابة أثناء النسخ الاحتياطي التحقيق حتى لو بدا فحص الخادم الخامل جيدًا.

توفر وحدات vCPU المخصصة وصولًا مستمرًا إلى موارد CPU المخصصة لك. لكنها لا تمنح خادمًا فعليًا كاملًا ولا تحدد IOPS للتخزين. قيّم تخصيص CPU والذاكرة وسلوك التخزين كلًا على حدة. إذا تجاوزت المتطلبات المقاسة خيارات VPS، فابحث في العتاد المخصص بدل الاستنتاج من اسم خطة أكبر.

طابق أحمال SQL مع إعداد أولي

استخدم PostgreSQL 16 أو MySQL 8.4 مع InnoDB أو MariaDB 11.4 مع InnoDB كبيئات بديلة للأمثلة بحسب توافق التطبيق. ليست محركات قابلة للاستبدال ولا ادعاءً بأحدث إصدار. سجّل إصدار التصحيح المثبت قبل الاختبار؛ لا تحدد الأمثلة إصدار صورة المزود المنشورة.

ضع التطبيق الصغير وقاعدته على المضيف نفسه

لقاعدة مفترضة بحجم 3 GB، ومجموعة ساخنة 1 GB، وخمسة استعلامات بسيطة مفهرسة نشطة، اختبر VPS بوحدتَي vCPU وذاكرة 4 GB وتخزين SSD أو NVMe اسمي 60 GB. يبقى الاتصال محليًا، لكن يجب أن يتسع التطبيق والقاعدة ضمن ميزانية ذروة الذاكرة نفسها.

افترض نسبة قراءة/كتابة 90/10، ونموًا شهريًا 1 GB، وعدم تشغيل تقارير طويلة أثناء النسخ. قد يناسب CPU المشترك بيئة اختبار تتحمل التفاوت. اختر التخصيص المكرس إذا جعل التنافس المستمر أزمنة الاستجابة غير مناسبة؛ مقارنة خطط الإنتاج لاحقًا تستخدم vCPU مخصصة فقط.

التوزيع التالي إطار مقترح للذاكرة، وجميع الأرقام بوحدة GB:

في MySQL أو MariaDB، اجعل مجمع InnoDB ضمن هذا الإطار. تطبيق نسبة خاصة بخادم قاعدة مخصص على المضيف كله سيستهلك ذاكرة التطبيق. في PostgreSQL، احتسب المخازن المشتركة وذاكرة العمليات منفصلتين ضمن حصة القاعدة واحتياطيها. قِس الذروة المجمعة قبل اعتماد أي إعداد.

مثال للقرص: 5 GB للنظام والسجلات، و3 GB للبيانات والفهارس، و4 GB لسجلات المحرك، و3 GB للعمل المؤقت، و6 GB للنمو، بإجمالي 21 GB. الباقي الاسمي يغطي نفقات نظام الملفات والعمل العابر؛ وليس مبررًا للاحتفاظ بالنسخ على الأساسي.

اتصل عبر مقبس محلي أو localhost. اختبر الإيداع الدائم مع تشغيل التطبيق والنسخ، بما يشمل مزامنة التخزين (fsync) التي تطلب من النظام تفريغ البيانات إلى تخزين دائم. إذا قبل المسؤول هدف نقطة تعافٍ RPO قدره 24 ساعة، أي نافذة الفقد المقبولة، وهدف زمن تعافٍ RTO قدره أربع ساعات، فاقترح نسخة أصلية ليلية خارج العقدة وأثبت زمن الاستعادة في تمرين. فشل ميزانية الذاكرة أو الاستجابة أو الاستعادة يستدعي الفصل أو التحجيم أو تعديل التعافي بعد تشخيص الاستعلامات والفهارس.

افصل قاعدة SQL للمعاملات

إذا كان التطبيق على مضيف آخر، فقاعدة SQL توضيحية بحجم 12 GB ومجموعة ساخنة 6 GB يمكن بدء اختبارها بوحدتَي vCPU مخصصتين وذاكرة نحو 16 GB وتخزين محلي نحو 50 GB. يفترض ذلك 20 استعلامًا مفهرسًا نشطًا وكتابات قصيرة وحسابًا مستمرًا منخفضًا؛ قد تُبطل العمليات الأثقل الميزانية.

افترض قراءة/كتابة 90/10 ونموًا شهريًا 1 GB لثلاثة أشهر. هذا حمل جدول المزودين المرجعي. تختلف وحدات السعة، لذا قارن الذاكرة المتاحة فعليًا وبايتات نظام الملفات القابلة للاستخدام قبل تطبيق التخصيصات.

لـVPS PostgreSQL، تبدأ إرشادات المخازن المشتركة في PostgreSQL 16 بنسبة 25% من ذاكرة النظام لخادم قاعدة مخصص لديه 1 GB RAM على الأقل. يستخدم PostgreSQL أيضًا مخبأ النظام. ميزانية 16 GB المقترحة: 4 GB للمخازن المشتركة، و2 GB للنظام والوكلاء، و2 GB لاحتياطي الاستعلامات والاتصالات والصيانة، و8 GB لمخبأ الملفات والهامش.

الاحتياطي ليس إعدادًا لـwork_mem. توضح وثائق ذاكرة عمليات الاستعلام في PostgreSQL أن الفرز والتجزئة المنفصلين قد يخصصان ذاكرة مع تشغيل جلسات متعددة. تستخدم التجزئة أيضًا hash_mem_multiplier. اضبط الحدود بحسب العمل المتزامن المسموح؛ قد يتجاوز التخصيص الكبير لكل عملية ميزانية المضيف رغم كفاية المخازن المشتركة.

لاستضافة MySQL على VPS، توصي إرشادات مجمع الذاكرة في MySQL 8.4 من Oracle عادةً بنسبة 50–75% من ذاكرة النظام مع مراعاة النظام والتخصيصات الأخرى. اختبر مجمع InnoDB بحجم 8 GB هنا، واترك الباقي للمستهلكين الآخرين والذروة.

تحتاج MariaDB إلى حساب مختلف قليلًا. تبدأ إرشادات تخصيص الذاكرة لديها للأنظمة التي يغلب عليها InnoDB عند 60–70% من الذاكرة المتاحة بعد النظام والخدمات. إذا توفر 13 GB فالنتيجة 7.8–9.1 GB؛ يناسب مجمع أولي 8 GB المثال. يتطلب MyISAM أو Aria احتساب مخبأ منفصلًا. هذه بدائل، فلا تجمع الميزانيات.

ميزانية القرص: 12 GB بيانات وفهارس + 3 GB نمو + 5 GB نظام + 4 GB سجلات + 8 GB مؤقت وصيانة = 32 GB. يترك قرص فئة 50 GB نحو 18 GB اسميًا قبل النفقات. اشترط مساحة حرة مقاسة 15 GB على الأقل؛ سجلات أطول احتفاظًا أو إعادة كتابة أكبر تُبطل المثال.

قرّب التطبيق والقاعدة، بمسار خاص مختبر حيث يدعم، مع المصادقة وضبط الوصول والتشفير. افحص زمن الاستعلام والإيداع الدائم أثناء نقاط التحقق والتفريغ والنسخ. خصص تخزين نسخ مستقلًا؛ حالة التعافي أدناه تفصله. أعد التحجيم إذا تشبع المورد أو فشلت مساحة القرص أو أهداف التعافي بعد تشخيص الاستعلامات والفهارس.

احتسب مجموعات عمل أكبر أو كتابة مستمرة

لقاعدة مفترضة 100 GB ومجموعة ساخنة 16 GB، اختبر 4 vCPU مخصصة و32 GB RAM وتخزين NVMe نحو 300 GB. افصل التطبيق. يسمح المثال بـ30 استعلامًا مختلطًا نشطًا ونسبة قراءة/كتابة 60/40؛ قِس التنفيذ وضغط التخزين قبل زيادة الموارد.

افترض نموًا 10 GB شهريًا لثلاثة أشهر. إطار PostgreSQL: 8 GB مشتركة، و4 GB احتياطي النظام والاستعلامات والصيانة، و20 GB لمخبأ الملفات والهامش. لـMySQL أو MariaDB، مجمع InnoDB بنحو 16 GB بديل أولي بعد حجز بقية المستهلكين. لا تنقل إعدادات PostgreSQL لأي منهما.

يشمل التخزين العمل الجاري: 100 GB بيانات وفهارس + 30 GB نمو + 30 GB سجلات محتفظ بها أو منتظرة + 60 GB لأكبر عملية صيانة أو عمل مؤقت متوقعة + 10 GB نظام = 230 GB. يتبقى نحو 70 GB اسميًا. إعادة كتابة جدول أكبر تستلزم الحساب مجددًا حتى مع نمو يومي متواضع.

تميز وثائق التنظيف الدوري في PostgreSQL بين VACUUM الذي يعيد استخدام مساحة الصفوف الميتة، وVACUUM FULL الذي يكتب نسخة جديدة ويحتاج مساحة إضافية مؤقتة. شراء قرص أكبر قليلًا فقط من البيانات قد يمنع الصيانة اللازمة لاسترداد المساحة.

قِس تنفيذ CPU وضغط المخبأ وI/O الفعلي منفصلة عن زمن الكتابة. أدرج الكتابات المؤقتة ونقاط التحقق والتفريغ. تصف NVMe وCPU المخصصة الإعداد، ولا تضمن IOPS. اختبر نقل النسخ والتكرار المستمر أيضًا، مع اتصال تطبيق خاص قريب وتخزين تعافٍ مستقل. تسارع توليد السجلات يغير سعة الاحتفاظ والطلب على الشبكة. زد الأنوية أو RAM أو القرص بحسب القيد المقاس، لا لأن الخطة التالية تزيدها جميعًا.

أضف سعة التعافي إلى الإنتاج

قبول فقد 15 دقيقة وهدف استعادة ساعة يتطلب تصميم تعافٍ يتجاوز ميزانية الأساسي. احتفظ بافتراضات حمل SQL المنفصل، ثم أضف نسخًا أصلية وسجلات تعافٍ وتخزينًا مستقلًا وتمرينًا موقوتًا. هذه أهداف تخطيط؛ التمرين وحده يثبت تحقيقها.

تصف وثائق الأرشفة المستمرة في PostgreSQL نسخة أساسية وأرشيف WAL متصلًا للاستعادة إلى نقطة زمنية. تستخدم وثائق تعافي MySQL من Oracle نسخة كاملة ثم سجلات ثنائية. يستعيد إجراء PITR في MariaDB البيانات الكاملة والتزايدية قبل إعادة تشغيل السجلات الثنائية. يجب تفعيل التسجيل الثنائي لهذين المسارين في MySQL/MariaDB.

مثال للسعة: كل نسخة كاملة أو أساسية غير مضغوطة 12 GB. احتفظ بثلاث نسخ أسبوعية والسجلات المستمرة منذ بدء أقدم نسخة. احتسب حتى 21 يومًا بمعدل 2 GB يوميًا وهامش تخزين 20%:

(3 × 12 + 21 × 2) × 1.2 = 93.6 GB

خطّط لتخزين نسخ مستقل 100 GB على الأقل دون افتراض الضغط. اربط حذف السجلات بانتهاء النسخ واستبدالها الناجح. تحقق من اكتمال سلسلة النسخة والسجلات لكل نقطة تعافٍ موعودة.

استخدم نسخًا احتياطية على هدف مستقل ببيانات اعتماد وضوابط حذف منفصلة عن الأساسي. لقطة المزود وحدها لا تثبت سلسلة التعافي الأصلية. يجب أن ينشئ التمرين هدفًا نظيفًا وينقل النسخة ويستعيدها ويعيد السجلات ويتحقق من اتساق القاعدة والتطبيق ويوجه التطبيق. احسب وقت التوفير والنقل أيضًا.

قد يتطلب انقطاع أقصر نسخة مكررة مستقلة تتحمل الحمل كله. احتسب CPU وRAM والقرص منفصلة، وحدد الترقية وعزل الأساسي السابق وتوجيه العملاء. تمرّن على التسلسل. التكرار لا يحل محل النسخ، وVPS واحد ليس توافرًا عاليًا. راجع التصميم إذا تجاوزت الاستعادة ساعة أو تأخر الأرشيف عن RPO أو عجز الاحتياطي عن الحمل أو اقترب تخزين النسخ من سعته.

متى تختار VPS مُدارًا بدل غير المُدار

إذا لم يوجد من يستجيب لتنبيهات القاعدة أو يستعيدها أثناء الحادث، فاشترِ تغطية تشغيلية محددة. قد تنقل خدمة VPS المُدارة بعض الصيانة، لكن العقد يجب أن يسمي مهام القاعدة المشمولة. لوحة التحكم لا تثبت التغطية، وVPS المُدار يختلف عن قاعدة البيانات المُدارة.

يفيد الفرق بين مسؤوليات VPS المُدار وغير المُدار على مستوى كل مهمة. اعتبر الآتي قائمة شراء، لا وعدًا بتغطية واحدة لكل خدمة. تبقى البنية الفعلية مسؤولية المزود؛ برمجيات الضيف وتشغيل القاعدة يحتاجان ملكية واضحة.

سؤال تعاقدي مفيد: «إذا نفد قرص القاعدة أثناء نسخة، فمن يشخّص ويعيد الخدمة ويتأكد من نجاح النسخة التالية؟» تفرق الإجابة بين الوصول للدعم ومسؤولية النتيجة. اسأل أيضًا عن ترقية محرك فاشلة وحذف عرضي.

لقواعد البيانات المُدارة اتفاقات خاصة بدورة حياة المحرك والنسخ والتحويل عند الفشل. قد تناسبك إذا أردت نقل التعافي والترقيات. لا تستنتج ضبط التطبيق من اسم الخدمة؛ تصميم الاستعلام وسلوك التطبيق يحتاجان مسؤولًا ما لم ينص الاتفاق على غير ذلك.

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

اختر إعداد VPS لأحمال غير SQL

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

تحذر إرشادات الإدارة في Redis من أن حفظ RDB أو إعادة كتابة AOF مع كتابة كثيفة قد يستهلك ضعف الذاكرة المعتادة بحسب الصفحات المعدلة. لذا لا يمكن لبيانات 2 GB استهلاك الذاكرة كلها. تميز وثائق الاستمرارية بين لقطات RDB الدورية وسجل AOF. اختر السياسة بحسب الفقد المقبول، ثم قِس ذروة الذاكرة والقرص أثناء التشغيل.

تصف وثائق مخبأ WiredTiger في MongoDB المخبأ الداخلي ومخبأ الملفات. الافتراضي الداخلي هو الأكبر بين 50% × (RAM − 1 GB) و0.256 GB. توصي إرشادات مجموعات النسخ بثلاثة أعضاء يحملون البيانات. المصوّت الحكم لا يخزن بيانات. أضف سعة نسخ مستقلة وفعّل مصادقة MongoDB قبل وصل التطبيق.

توصي وثائق إعدادات JVM من Elastic بتحجيم heap تلقائيًا. يدويًا، ساوِ الحدين الأدنى والأقصى ولا تتجاوز 50% من الذاكرة المتاحة. تصف إرشادات مرونة العناقيد الصغيرة عقدتَي بيانات مؤهلتين للرئاسة وعقدة ترجيح مصوتة فقط. اضبط النسخ ووجه العملاء لعقد البيانات؛ تضيف عقدة الترجيح صوتًا لا نسخة. إذا استنفد الدمج أو الاحتفاظ احتياطي القرص، عدّل الميزانية قبل إضافة المستندات.

قارن الخطط غير المُدارة المناسبة لإعدادك

لمثال SQL المنفصل، صفِّ الخطط على حد أدنى 2 vCPU مخصصة وذاكرة فئة 16 GB وتخزين محلي فئة 50 GB. اجتياز الحد يجعل الخطة مرشحة للاختبار. اختلاف الحزم والوحدات والتزامات الفوترة يمنع اعتبار الصفوف عتادًا متكافئًا أو ترتيب أداء.

النشر المرجعي Linux ذاتي الإدارة في ألمانيا أو وسط أوروبا القريب، ببيانات صغيرة وميزانية ذاكرة أكبر. القرب لا يعني زمن استجابة متطابقًا. الاتصال المقصود خاص حيث يدعم؛ الأسعار تبقي IPv4 العامة القياسية المتاحة. افترض النقل دون جميع الحصص المذكورة.

تضع وثائق اختيار DigitalOcean خطط Memory-Optimized ضمن خيارات SQL/NoSQL والمخابئ. أوصي بالعائلة المجمعة لهذا الحمل قليل القرص وكثيف الذاكرة. VPS المحسن للذاكرة ليس حصرًا على SQL. إذا أظهرت القياسات أن سعة التخزين أو طلبه المستمر هو القيد، فقيّم عائلة Storage-Optimized منفصلة.

تستوفي الخطط الخمس الحد المرجعي مع موارد CPU وقرص إضافية مختلفة. قد تستوعب النمو، لكنها لا تثبت أفضلية سرعة دون اختبار. إدراج Hetzner لا يضمن مخزون الطلب. توثق Akamai استخدام SSD في G7 Dedicated. فئة Optimized Memory من Vultr منفصلة عن High Frequency Compute المشتركة.

يناسب تخصيصنا المكرس الإعداد ذاتي الإدارة بالسعر المعروض. قارن الموارد والعملات والتزام الفوترة ورسوم IPv4 لكل مزود قبل الحكم على القيمة الكلية.

احتسب الملكية: حوسبة + عنوان + تخزين وطلبات ونقل النسخ المستقلة + سعة اختبار الاستعادة + احتياطي اختياري. الرسوم المجهولة ليست صفرًا. احصل على أسعار التعافي الحالية وتحقق من الخطة والموقع ومسار الترقية قبل الالتزام. لا تستنتج فاتورة سنوية بضرب مكافئ شهري مقرب.

بعد اختيار محرك SQL متوافق، تقلل تطبيقاتنا بنقرة واحدة خطوات التثبيت. PostgreSQL وMySQL وMariaDB اختيارات منفصلة؛ اختيار أحدها لا يثبت الثلاثة. يبقى النشر ذاتي الإدارة، والتصحيح والضبط والتعافي مسؤوليتك.

الأسئلة الشائعة

هل تكشف نسبة إصابات مخبأ PostgreSQL بطء التخزين؟

لا. توضح وثائق إحصاءات I/O في PostgreSQL أن مخبأ النظام قد يلبي القراءة دون الوصول للقرص. اجمع نسبة الإصابة مع قياسات I/O النظام وأزمنة الاستعلام. النسبة وحدها لا تميز تأخر التخزين الفعلي عن قراءة من ذاكرة النواة.

هل يمكن استخدام تصدير PostgreSQL منطقي للاستعادة الزمنية عبر WAL؟

لا. تنص متطلبات الأرشفة المستمرة في PostgreSQL على أن التصدير المنطقي يفتقر لمعلومات إعادة WAL. يعيد التصدير الحالة الملتقطة؛ تتطلب الاستعادة الزمنية WAL نسخة أساسية مناسبة وأرشفة WAL متصلة. اختر صيغة النسخ حسب طريقة التعافي المقصودة.

هل يستخدم مخبأ MongoDB ذاكرة المضيف عند التشغيل داخل حاوية؟

استخدم الذاكرة المتاحة للحاوية. تحذر إرشادات ذاكرة الحاويات في MongoDB من أن WiredTiger قد لا يحسب حد الحاوية الأقل في بعض الحالات. اضبط المخبأ دون الحد مع مساحة لبقية العمليات؛ قد تبالغ ذاكرة المضيف الكلية في المتاح للقاعدة.