يُعدّ Odoo أشهر نظام تخطيط موارد المؤسسات (ERP) مفتوح المصدر، لكنه أيضاً نظام «جائع للموارد»: أداؤه يعتمد بشكل مباشر على تحجيم صحيح للمعالج والذاكرة وقاعدة بيانات PostgreSQL. فما يكفي شركة بـ100 مستخدم قد ينهار تماماً عند 500 أو 1500. في هذا الدليل نعرض ثلاث معماريات لـبنية Odoo حسب حجم شركتك، مع تقدير الموارد المطلوبة لكل حجم — CPU وRAM وعدد العمّال وPostgreSQL والتوافر العالي — لتختار البنية الصحيحة من البداية بدل ترقية مؤلمة لاحقاً.
محتويات الدليل
لماذا تحجيم بنية Odoo مهم؟
يعمل Odoo بنموذج «العمّال» (Workers): عمليات متعددة تعالج طلبات المستخدمين بالتوازي. نقص العمّال أو الذاكرة يعني بطئاً وتوقّفاً وقت الذروة، بينما الإفراط يهدر المال. لذلك يبدأ تصميم بنية Odoo السليمة من فهم ثلاثة عوامل:
- المستخدمون المتزامنون: ليس إجمالي المستخدمين، بل من يعمل فعلاً في اللحظة نفسها (عادةً ~20% من الإجمالي).
- عدد العمّال (Workers): يحدّد كم طلباً يُعالَج بالتوازي.
- قاعدة البيانات PostgreSQL: قلب الأداء، وأكثر ما يتأثّر بالحمل.
الخطأ الأكثر شيوعاً هو التعامل مع Odoo كأي تطبيق ويب خفيف؛ فهو في الحقيقة نظام أعمال متكامل يشغّل المحاسبة والمخزون والمبيعات والموارد البشرية معاً، وكل وحدة مثبّتة تضيف حملاً إضافياً على المعالج والذاكرة. لذلك التحجيم الصحيح ليس رفاهية بل شرط أساسي لعمل النظام بثبات وقت الذروة.
كيف تُحسب موارد Odoo؟
قبل عرض المعماريات، إليك مبادئ التحجيم التي تُبنى عليها التقديرات:
- عدد العمّال ≈ (عدد الأنوية × 2) + 1، مع تخصيص عامل إضافي للمهام المجدولة (Cron).
- الذاكرة لكل عامل: تقديرياً ~150MB للطلبات الثقيلة و~60MB للخفيفة.
- قاعدة كل عامل يخدم عدداً من المتزامنين: كلما زاد المتزامنون، لزم عمّال أكثر ومعالج أقوى.
- PostgreSQL يحتاج ذاكرته الخاصة منفصلة عن ذاكرة عمّال Odoo.
راجع توثيق النشر الرسمي من Odoo لصيغ العمّال والإعدادات الإنتاجية بالتفصيل.
الأهم أن هذه المعادلات نقطة بداية لا وصفة نهائية؛ فيبقى القياس الفعلي تحت حملك الحقيقي هو الحكم الأخير. عدد الوحدات المثبّتة، وعدد الشركات (Companies) داخل النظام، وحجم البيانات المتراكمة — كلها تغيّر المعادلة صعوداً أو نزولاً.
بنية Odoo لـ100 مستخدم
للشركات الصغيرة حتى ~100 مستخدم (≈20 متزامناً)، تكفي بنية Odoo على خادم واحد مُحكم يجمع التطبيق وقاعدة البيانات:
| المورد | التقدير الإرشادي (100 مستخدم) |
|---|---|
| المعالج | ~4 vCPU |
| الذاكرة | ~8 GB |
| العمّال (Workers) | ~4–5 |
| PostgreSQL | على نفس الخادم (حصة ذاكرة مخصّصة) |
| المنتج المناسب | VPS قوي أو VDS |
بنية Odoo لـ500 مستخدم
عند ~500 مستخدم (≈100 متزامناً)، يصبح جمع كل شيء على خادم واحد عنق زجاجة. الحلّ في بنية Odoo عند هذا الحجم هو فصل التطبيق عن قاعدة البيانات على خادمين:
| المورد | خادم التطبيق | خادم PostgreSQL |
|---|---|---|
| المعالج | ~8 vCPU | ~8 vCPU |
| الذاكرة | ~16–24 GB | ~16 GB |
| العمّال | ~12–16 | — |
| ملاحظة | فصل التطبيق يخفّف الحمل | قاعدة منفصلة = ثبات أعلى |
هذا الفصل يمنح كل طبقة مواردها الخاصة، ويسمح بترقية كلٍّ منهما باستقلال — وهو المستوى المثالي لخطط VDS بموارد مضمونة.
بنية Odoo لـ1500 مستخدم
عند ~1500 مستخدم (≈300 متزامناً) وأكثر، تتطلّب بنية Odoo توزيعاً كاملاً: عدة عقد تطبيق خلف موزّع حمل، وقاعدة PostgreSQL مخصّصة بنسخة قراءة، مع توافر عالٍ:
| المكوّن | التقدير الإرشادي (1500 مستخدم) |
|---|---|
| موزّع الحمل | عقدة موزّع حمل (Load Balancer) |
| عقد التطبيق | 2–3 عقد × ~8–16 vCPU / 32GB لكل عقدة |
| PostgreSQL | خادم مخصّص ~16–32 vCPU / 64GB+ مع Replica |
| التوافر | توزيع + تكرار + مراقبة (HA) |
| المنتج المناسب | Dedicated أو عنقود مخصّص |
PostgreSQL: قلب أداء Odoo
مهما كبرت بنية Odoo، تبقى PostgreSQL هي العامل الحاسم في الأداء، لأنها تعالج كل استعلامات النظام. لتحجيمها بذكاء:
- خصّص لها ذاكرة كافية (shared_buffers وwork_mem) منفصلة عن Odoo.
- افصلها على خادمها الخاص بدءاً من الأحجام المتوسطة.
- أضِف نسخ قراءة (Replicas) لتوزيع القراءة عند الأحجام الكبيرة.
- فهرِس الجداول الثقيلة وراقب الاستعلامات البطيئة.
قاعدة عملية: راقب استهلاك PostgreSQL أولاً عند أي تباطؤ، فغالباً يكون هو الاختناق قبل المعالج أو الذاكرة. ومع نمو البيانات، يصبح ضبط إعداداتها وفهرسة جداولها أهمّ من مجرّد إضافة عمّال لتطبيق Odoo.
التوافر العالي وخطة التعافي
كلما كبرت المؤسسة، ازدادت خطورة التوقّف. لذلك تحتاج بنية Odoo المؤسّسية إلى توافر عالٍ (عدة عقد بلا نقطة فشل واحدة) وخطة تعافٍ من الكوارث (نسخ احتياطي خارجي وتكرار). فمنظومة ERP متوقّفة تعني توقّف العمليات والمبيعات والمحاسبة كلها في آنٍ واحد.
- التوافر العالي: عقد تطبيق متعددة + PostgreSQL بنسخة احتياطية جاهزة.
- خطة التعافي: نسخ احتياطي خارجي غير قابل للتغيير + سيناريو استعادة مختبَر.
فقدان بيانات نظام ERP أخطر بكثير من فقدان موقع عادي، لأنه يمسّ سجلّاتك المالية والمحاسبية ومخزونك مباشرةً. لذلك يُنصح بنسخ احتياطي خارجي منتظم وخطة تعافٍ مختبَرة لأي نظام Odoo إنتاجي جادّ.
أي منتج مرام يناسب كل حجم؟
يمكن مطابقة كل حجم من بنية Odoo بمنتج مرام المناسب، مع ترقية سلسة كلما نمت شركتك:
| حجم الشركة | البنية | منتج مرام |
|---|---|---|
| حتى 100 مستخدم | خادم واحد | VPS قوي أو VDS |
| ~500 مستخدم | تطبيق + PostgreSQL منفصل | VDS بموارد مضمونة |
| ~1500 مستخدم فأكثر | عقد متعددة + HA | Dedicated أو عنقود |
🤝 من واقع مرام
نساعد الشركات على تصميم بنية Odoo المناسبة لحجمها فعلياً — لا الأكبر ولا الأصغر. كثيراً ما نبدأ عميلاً بخادم مُحكم، ثم نفصل PostgreSQL ونضيف عقداً مع نموّه، فينمو نظامه دون إعادة بناء أو توقّف مكلف.
الخلاصة
لا توجد بنية Odoo واحدة تناسب الجميع؛ بل بنية تناسب حجم شركتك ونمط استخدامها. ابدأ بتقدير مستخدميك المتزامنين، احسب العمّال والذاكرة، افصل PostgreSQL حين تكبر، وأضِف العقد والتوافر العالي عند الأحجام المؤسّسية. التحجيم الصحيح من البداية يجنّبك تباطؤاً محرجاً وترقيات مؤلمة — ويجعل نظام ERP الخاص بك يكبر بثبات مع أعمالك.
بنية Odoo تنمو مع شركتك
من خادم واحد إلى عنقود مؤسّسي بـHA — مرام هوست توفّر الموارد المضمونة والبنية المرنة لتشغيل Odoo بأي حجم.
جهّز بنية Odoo مع مرام ←