> ## 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.

# معالجة خطأ "Too many parts" في ClickHouse

> تعرّف على كيفية معالجة خطأ "Too many parts" في ClickHouse من خلال تحسين معدلات الإدراج، وضبط إعدادات MergeTree، وإدارة الأقسام بفعالية.

{frontMatter.description}

<div id="dbexception-too-many-parts-252-merges-are-processing-significantly-slower-than-inserts">
  ## DB::Exception: Too many parts (خطأ: 252). تتم عمليات الدمج بوتيرة أبطأ بكثير من عمليات الإدراج
</div>

لقد وصلت إلى الإعداد `parts_to_throw_insert` في جدول MergeTree.

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

```sql theme={null}
select count(*) from system.parts where table = '<table_name>' and active == 1
```

المطلب الأساسي عند الإدراج في ClickHouse هو: يجب ألا ترسل أبدًا عددًا كبيرًا جدًا من عبارات `INSERT` في الثانية. ومن الناحية المثالية: عملية إدراج واحدة كل ثانية / كل بضع ثوانٍ.

لذلك يمكنك إدراج 100K صف في الثانية، ولكن فقط باستخدام عبارة `INSERT` واحدة كبيرة مجمّعة. عندما ترسل مئات / آلاف عبارات الإدراج في الثانية إلى \*MergeTree table فستحصل دائمًا على بعض الأخطاء، ولا يمكن تغيير ذلك بمجرد تعديل بعض الإعدادات.

إذا لم تتمكن من دمج عدد كبير من عمليات الإدراج في عبارة إدراج مجمّعة كبيرة واحدة على الطرف الخارجي - فعليك إنشاء Buffer table قبل \*MergeTree table.

1. كل عملية إدراج تنشئ مجلدًا في `/var/lib/clickhouse/.../table_name/`. وداخل ذلك المجلد يوجد ملفان لكل عمود - أحدهما للبيانات (مضغوطة)، والثاني للفهرس. وتُرتَّب البيانات فعليًا حسب المفتاح الأساسي داخل تلك الملفات. وتُسمى هذه المجلدات '**parts**'.

2. يدمج ClickHouse هذه الأجزاء الصغيرة في أجزاء أكبر في الخلفية. ويختار الأجزاء التي سيجري دمجها وفقًا لبعض القواعد. بعد دمج جزأين (أو أكثر)، يُنشأ جزء أكبر واحد وتُوضَع الأجزاء القديمة في قائمة انتظار لحذفها. تتيح الإعدادات التي ذكرتها ضبط قواعد دمج الأجزاء بدقة. والهدف من عملية الدمج هو الإبقاء على جزء كبير واحد لكل partition (أو بضعة أجزاء كبيرة لكل partition لا تستحق الدمج لأنها كبيرة جدًا). يُرجى أيضًا مراجعة هذا [التعليق](https://github.com/yandex/ClickHouse/issues/1661#issuecomment-352739726).

3. إذا أنشأت أجزاء جديدة بسرعة كبيرة جدًا (على سبيل المثال عبر تنفيذ عدد كبير من عمليات الإدراج الصغيرة)، ولم يكن ClickHouse قادرًا على دمجها بالسرعة المناسبة (بحيث تصل الأجزاء الجديدة أسرع مما يستطيع ClickHouse دمجه) - فستظهر لك الاستثناء 'Merges are processing significantly slower than inserts'. يمكنك محاولة زيادة الحد، لكن قد ينتهي بك الأمر إلى مشكلات في filesystem بسبب العدد الكبير جدًا من الملفات / الأدلة (مثل حد inodes).

4. إذا كنت تُدرج في عدد كبير من partitions دفعة واحدة، فإن المشكلة تتضاعف بعدد partitions المتأثرة بالإدراج.

5. يمكنك محاولة ضبط سلوك ClickHouse باستخدام أحد الإعدادات المذكورة، أو باستخدام max\_insert\_block\_size / max\_block\_size / insert\_format\_max\_block\_size / max\_client\_network\_bandwidth. ولكن: الحل الأفضل هو ببساطة إدراج البيانات بالوتيرة المتوقعة. والوتيرة المتوقعة هي: **عملية إدراج واحدة كل 1-2 ثانية، وكل عملية إدراج تحتوي على 10K-500K صف من البيانات**.

6. لذا فإن الحل الصحيح لمعالجة "Merges are processing significantly slower than inserts" هو ضبط عدد عمليات الإدراج في الثانية وعدد الصفوف في كل عملية إدراج. استخدم الإدراج على دفعات لدمج عمليات الإدراج الصغيرة في عملية أكبر إذا كانت البيانات تصل صفًا بصف. وخفّف وتيرة عمليات الإدراج الضخمة إذا كان لديك قدر كبير جدًا من البيانات لإدراجه دفعة واحدة. لا تغيّر مكوّنات ClickHouse الداخلية، إلا إذا كنت تفهم جيدًا فعلًا ما يعنيه ذلك.

7. إذا كانت بياناتك تصل أسرع من 500K صف في الثانية - ففي الغالب أنت بحاجة إلى المزيد من الخوادم في cluster لخدمة هذا الحمل، وليس إلى تعديل الإعدادات.

8. تعتمد سرعة عمليات الدمج في الخلفية عادةً على سرعة التخزين، وإعدادات Compression المستخدمة، وخيار MergeTree (خوارزمية الدمج - دمج عادي/تجميعي/تلخيصي/collapsing، إلخ)، وsorting key المستخدم.