> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# التفريع

> أنشئ فروعًا معزولة لقواعد البيانات من لقطات عند نقاط زمنية محددة لسير عمل التطوير ومرحلي والاختبار والاستعادة

يدعم ClickHouse Managed Postgres إنشاء فروع معزولة لقواعد البيانات باستخدام الاستعادة إلى نقطة زمنية محددة (PITR).

الفرع هو عملية نشر PostgreSQL مستقلة بالكامل، تُنشأ من نقطة زمنية محددة لقاعدة بيانات موجودة. ويمكن استخدام الفروع في التطوير ومرحلي والاختبار وتصحيح الأخطاء والتحقق من صحة البيانات أو في سيناريوهات الاستعادة، من دون التأثير في قاعدة البيانات المصدر.

وعلى عكس تطبيقات النسخ عند الكتابة (copy-on-write) التي تشارك التخزين مع قاعدة البيانات الأساسية، تُستعاد فروع ClickHouse Managed Postgres من النسخ الاحتياطية وتعمل كعمليات نشر PostgreSQL مستقلة.

<div id="branching">
  ## آلية عمل التفريع
</div>

يعتمد إنشاء الفرع على البنية التحتية نفسها للنسخ الاحتياطي والاستعادة المستخدمة في [الاستعادة إلى نقطة زمنية محددة (PITR)](/docs/ar/products/managed-postgres/backup-and-restore).

عند إنشاء فرع، تستعيد ClickHouse Managed Postgres نسخة احتياطية أساسية من تخزين الكائنات، ثم تعيد تشغيل مقاطع WAL المطلوبة للوصول إلى نقطة الاستعادة المطلوبة، وتوفّر مثيل PostgreSQL جديدًا انطلاقًا من الحالة المستعادة. وبمجرد اكتمال الاستعادة، يعمل الفرع بشكل مستقل عن قاعدة البيانات المصدر.

ويكون الفرع الناتج نسخة كاملة من قاعدة البيانات المصدر عند النقطة الزمنية المحددة.

<div id="common-use-cases">
  ## حالات الاستخدام الشائعة
</div>

<div id="dev-and-testing">
  ### التطوير والاختبار
</div>

أنشئ فرعًا من قاعدة بيانات الإنتاج أو من قاعدة بيانات مرحلية للتحقق من تغييرات التطبيق والترحيلات أو اختبار الميزات الجديدة على بيانات واقعية.

<div id="staging-environments">
  ### بيئات مرحلية
</div>

حافظ على بيئة مرحلية تحاكي بيئة الإنتاج الفعلية عن كثب، من دون التأثير في أعباء العمل الإنتاجية.

<div id="date-validation">
  ### التحقق من صحة البيانات
</div>

اختبر تغييرات المخطط، واستراتيجيات الفهرسة، وتحسين الاستعلامات قبل نشرها في بيئة الإنتاج.

<div id="recovery-and-investigation">
  ### الاستعادة والاستقصاء
</div>

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

<div id="branch-sizing">
  ## تحديد حجم الفرع
</div>

الفروع هي عمليات نشر مستقلة لـ PostgreSQL، ويمكن تحديد حجمها بشكل منفصل عن قاعدة البيانات المصدر.

على سبيل المثال، قد تعمل بيئة الإنتاج بإعدادات أكبر، بينما يمكن لفرع التطوير أو الفرع المرحلي استخدام ملف تعريف حوسبة أصغر لتقليل التكاليف. ويتيح ذلك للفرق إنشاء بيئات مؤقتة من دون الحاجة إلى مماثلة موارد الحوسبة المستخدمة في بيئة الإنتاج.

<div id="branch-creation-time">
  ## وقت إنشاء الفروع
</div>

نظرًا لأن ClickHouse Managed Postgres يستخدم تخزين PostgreSQL المعتمد على NVMe، تُستعاد الفروع من النسخ الاحتياطية بدلًا من إنشائها عبر آليات النسخ عند الكتابة على مستوى التخزين. لذلك، فإن إنشاء الفروع ليس فوريًا.

تتراوح المدة المعتادة لإنشاء الفروع من بضع دقائق إلى عشرات الدقائق، وذلك حسب:

* حجم قاعدة البيانات
* حجم النسخة الاحتياطية
* نقطة الاستعادة
* مقدار WAL الذي يجب إعادة تطبيقه
* التكوين العام للعنقود

في معظم عمليات النشر، تصبح الفروع متاحة خلال بضع دقائق. وقد تتطلب قواعد البيانات الأكبر وقتًا إضافيًا.

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

<div id="branches-v-local-dev">
  ## الفروع مقابل التطوير المحلي
</div>

من الأسئلة الشائعة ما إذا كان ينبغي لكل مطوّر استخدام فرع إنتاجي بوصفه بيئة التطوير الخاصة به.

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

بالنسبة إلى معظم المؤسسات، نوصي بما يلي:

* استخدام فروع PostgreSQL لسير عمل الإعداد المرحلي والاختبار واستكشاف الأخطاء وإصلاحها والتحقق.
* استخدام بيئات PostgreSQL المحلية للتطوير اليومي.
* إنشاء مجموعات بيانات تطوير اصطناعية أو استخدام مجموعات بيانات منقّحة عند الاقتضاء.
* تجنّب إجراء التطوير اليومي مباشرةً على الفروع المشتقة من بيئة الإنتاج.

يقلّل هذا النهج العبء على أنظمة الإنتاج، ويحسّن وتيرة التطوير، ويساعد على ضمان بقاء بيانات الإنتاج محمية على النحو المناسب.

للحصول على إرشادات حول إنشاء بيئات تطوير PostgreSQL محلية باستخدام Docker، راجع [بيئات التطوير المحلية](/docs/ar/products/managed-postgres/local-development).

<div id="recommended-workflow">
  ## سير العمل الموصى به
</div>

يكون سير العمل الشائع عادةً كما يلي:

```text theme={null}
Production Database
        │
        ├─────────────► Branch
        │                  │
        │                  ├── Staging
        │                  ├── Validation
        │                  ├── Migration Testing
        │                  └── Incident Investigation
        │
        └─────────────► Local Development
                               │
                               ├── Docker PostgreSQL
                               ├── Application Migrations
                               └── Synthetic Test Data
```

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