> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-trino-dialect.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# معالجة استثناء "Too many parts" في ClickHouse

> تعرّف على كيفية تشخيص استثناء "Too many parts" ومعالجته من خلال تجميع عمليات الإدراج، واستخدام عمليات الإدراج غير المتزامنة، واختيار مفتاح تقسيم مناسب.

<div id="what-the-exception-means">
  ## ما الذي يعنيه هذا الاستثناء
</div>

يرفع ClickHouse الاستثناء `Too many parts` عندما يؤدي تنفيذ `INSERT` إلى تجاوز حد مُعدّ مسبقًا لعدد أجزاء البيانات النشطة في جدول `MergeTree`. وغالبًا ما يتضمن الاستثناء الرسالة `Merges are processing significantly slower than inserts`.

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

يمكن أن يحدث هذا الاستثناء بسبب أيٍّ من هذين الإعدادين:

* [`parts_to_throw_insert`](/ar/reference/settings/merge-tree-settings/parts-to#parts_to_throw_insert)، الذي يحدّ من عدد الأجزاء النشطة في قسم واحد.
* [`max_parts_in_total`](/ar/reference/settings/merge-tree-settings/max-parts#max_parts_in_total)، الذي يحدّ من العدد الإجمالي للأجزاء النشطة في table.

<div id="diagnose-the-cause">
  ## تشخيص السبب
</div>

استخدم الاستعلام التالي للعثور على الأقسام التي تضم أكبر عدد من الأجزاء النشطة:

```sql theme={null}
SELECT
    database,
    table,
    partition_id,
    count() AS active_parts,
    sum(rows) AS rows,
    formatReadableSize(sum(bytes_on_disk)) AS size_on_disk
FROM system.parts
WHERE active
  AND database = '<database_name>'
  AND table = '<table_name>'
GROUP BY
    database,
    table,
    partition_id
ORDER BY active_parts DESC;
```

للتحقق من الحد المفروض على مستوى الجدول بواسطة `max_parts_in_total`، احسب جميع الأجزاء النشطة في الجدول:

```sql theme={null}
SELECT
    database,
    table,
    count() AS active_parts,
    sum(rows) AS rows,
    formatReadableSize(sum(bytes_on_disk)) AS size_on_disk
FROM system.parts
WHERE active
  AND database = '<database_name>'
  AND table = '<table_name>'
GROUP BY
    database,
    table;
```

تشمل الأسباب الشائعة ما يلي:

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

يمكنك فحص عمليات الدمج الجارية حاليًا في [`system.merges`](/ar/reference/system-tables/merges) ومراجعة سجلات الخادم للتحقق من حالات فشل الدمج.

<div id="resolve-the-exception">
  ## حلّ الاستثناء
</div>

<div id="batch-synchronous-inserts">
  ### عمليات الإدراج المتزامنة على دفعات
</div>

جمّع الصفوف في دفعات على جانب العميل قبل إدراجها. يجب أن تحتوي كل دفعة على 1,000 صف على الأقل، ومن الأفضل أن تضم بين 10,000 و100,000 صف. استهدف تنفيذ عملية `INSERT` متزامنة واحدة تقريبًا كل ثانية. فكلما قلّ عدد عمليات الإدراج وكبر حجمها، قلّ عدد الأجزاء التي يتم إنشاؤها وتراجع العمل المطلوب من عمليات الدمج في الخلفية.

<div id="use-asynchronous-inserts">
  ### استخدم عمليات الإدراج غير المتزامنة
</div>

إذا لم يكن التجميع على جهة العميل خيارًا عمليًا، فاستخدم [عمليات الإدراج غير المتزامنة](/ar/concepts/best-practices/selecting-an-insert-strategy#asynchronous-inserts) لكي يتمكن ClickHouse من تجميع البيانات الواردة على الخادم:

```sql theme={null}
INSERT INTO <table_name>
SETTINGS
    async_insert = 1,
    wait_for_async_insert = 1
VALUES (...);
```

أبقِ `wait_for_async_insert = 1` لكي لا يؤكّد ClickHouse عملية إدراج إلا بعد كتابة البيانات بنجاح.

<div id="review-the-partitioning-key">
  ### راجع مفتاح التقسيم
</div>

استخدم مفتاح تقسيم ذي عدد قيم مميّزة منخفض، وتجنب التقسيم بحسب قيم مثل معرّفات المستخدمين أو الطلبات. لا يدمج ClickHouse الأجزاء إلا ضمن القسم نفسه، لذا فإن العدد الكبير من الأقسام يمنع الدمج بفعالية. للحصول على إرشادات، راجع [اختيار مفتاح تقسيم](/ar/concepts/best-practices/partitioning-keys).

<div id="investigate-merge-bottlenecks">
  ### استقصِ اختناقات الدمج
</div>

إذا كانت عمليات الإدراج مُجمَّعة بالفعل بالشكل المناسب، فتحقّق من أداء التخزين، ومساحة القرص المتاحة، ومهام خلفية المتنافسة. يعتمد معدّل الدمج على نظام التخزين، ومحرك الجدول، ومفتاح الترتيب، والضغط، وسعة CPU وI/O المتاحة.

<div id="avoid-increasing-part-limits-as-the-primary-fix">
  ### تجنّب زيادة حدود الأجزاء باعتبارها الحل الأساسي
</div>

إن زيادة `parts_to_throw_insert` أو `max_parts_in_total` لا تعالج السبب وراء الإنشاء المفرط للأجزاء. قد تؤدي الحدود الأعلى إلى تأخير ظهور الاستثناء، لكنها قد تزيد أيضًا العبء على نظام الملفات والبيانات الوصفية وتقلل من أداء الاستعلامات. لا تغيّر هذه الإعدادات إلا بعد تحديد السبب والتأكد من أن النظام يتمتع بسعة كافية.

<div id="verify-the-recovery">
  ## تحقّق من التعافي
</div>

أعِد تشغيل استعلام التشخيص بعد تغيير استراتيجية الإدراج أو مخطط التقسيم. ينبغي أن يستقر عدد الأجزاء النشطة ثم يبدأ بالانخفاض مع تدارك عمليات الدمج في الخلفية للتراكم. واصل مراقبة حالات فشل الإدراج، ومساحة القرص الحرة، و[`system.merges`](/ar/reference/system-tables/merges) حتى يزول التراكم.