التعامل مع الحمولات الكبيرة

أسئلة
1

مرحبا لدي سير عمل يستقبل حمولات JSON كبيرة من واجهة برمجية، وأحيانا تحتوي على آلاف السجلات مع كائنات متداخلة.
سير العمل يعمل بشكل جيد مع الطلبات الأصغر، لكن مع نمو الحمولة، يزداد استهلاك الذاكرة بشكل كبير ويمكن أن تصبح العمال غير مستقرة في النهاية.
أنا أفكر في تخزين الحمولة الخام في PostgreSQL أو تخزين الكائنات أولاً، ثم معالجتها في أجزاء أصغر بدلاً من الاحتفاظ بكل شيء داخل تنفيذ n8n.
هل تعالج/تعالج البيانات عادة على دفعات، أم تخزن الحمولة أولاً وتترك سير عمل منفصل لمعالجتها؟
أيضاً، كيف تقرر متى تكون الحمولة كبيرة بما يكفي بحيث لا يجب تمريرها عبر سير العمل بالكامل؟

وصف المشكلة/الخطأ/السؤال

ما رسالة الخطأ (إن وجدت)؟

يرجى مشاركة سير العمل الخاص بك

(حدد العقد على لوحتك واستخدم اختصارات لوحة المفاتيح CMD+C/CTRL+C و CMD+V/CTRL+V لنسخ ولصق سير العمل.)

شارك الإخراج المرجع من قبل العقدة الأخيرة

معلومات حول إعداد n8n الخاص بك

  • إصدار n8n:
  • قاعدة البيانات (الافتراضي: SQLite):
  • إعداد n8n EXECUTIONS_PROCESS (الافتراضي: own, main):
  • تشغيل n8n عبر (Docker, npm, n8n cloud, تطبيق سطح المكتب):
  • نظام التشغيل:
2

مرحباً @Ethan_Mitchell، بينما تنتظر الرد، إليك بعض الأشياء التي قد تساعدك:

الموارد المقترحة

تم المطابقة تلقائياً مع سؤالك.

المستندات:

المنتدى:

@Niffzy - لقد ساعدت في حل مشاكل مماثلة من قبل، هل يمكنك إلقاء نظرة؟

تم الاقتراح تلقائياً بواسطة بوت مجتمع n8n. إنه تجريبي - يرجى مشاركة الملاحظات هنا.

3

مرحبا @Ethan_Mitchell قم بالتخزين أولاً، ثم المعالجة على دفعات. هذا ما توصي به مستندات الذاكرة في n8n.

  1. الاستقبال: Webhook → احفظ الحمولة الأولية في Postgres/S3 → رد برمز 200. ثم ابدأ المعالج باستخدام Execute Workflow (مع إيقاف “الانتظار لإكمال سير العمل الفرعي”)، أو اجعل مشغّل Schedule يختار الحمولات المعلقة.
  2. المعالج: اقرأ 200-500 سجل في كل مرة وأرسل كل دفعة إلى سير عمل فرعي يعيد فقط نتيجة صغيرة جداً. يتم تحرير ذاكرته بعد كل دفعة.

3. أوقف “حفظ التنفيذات الناجحة” على المعالج.

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

5

مرحباً @Ethan_Mitchell، يجب أن يحدث الجلب (fetch) داخل سير العمل الدفعي أيضاً. يقوم HTTP Request المدمج بجمع الصفحات قبل إرجاعها، لذا فإن إضافة Loop Over Items بعد ذلك لا يزيل تكلفة الذاكرة الأولية.

مرر مؤشراً (cursor) إلى سير عمل فرعي، واجلب صفحة واحدة مع إيقاف Automatic Pagination، ومعالجة/حفظ البيانات، وإرجاع المؤشر التالي وعدد فقط. أبقِ على Wait for Sub-Workflow Completion مفعلاً في حلقة الأب حتى لا تتراكم الدفعات.

إذا كانت واجهة برمجية التطبيقات (API) ترجع استجابة JSON ضخمة واحدة فقط، قسّمها في المنبع (upstream) إلى كائنات أصغر أو صفوف قاعدة بيانات. حفظها في S3 بعد أن يحللها n8n لن يمنع ارتفاع الذاكرة الأول.

لا يوجد حد عام بالميجابايت أو عدد السجلات. اختبر الأحمال المتداخلة التمثيلية في بيئة الاختبار عند التزامن المتوقع لديك، وقس ذاكرة RAM العامل بقيمتها القصوى، واختر حجم دفعة يترك مساحة كافية أقل من حد العامل.

6

بالنسبة للحمولات الكبيرة، أفضل نمط للإنتاج هو:

التخزين أولاً → المعالجة على دفعات

الطريقة الموصى بها

1. Webhook / HTTP Request يستقبل الحمولة

2. تخزين فوري للحمولة الخام (PostgreSQL jsonb أو S3/MinIO/تخزين الكائنات)

3. إرجاع 200 OK سريع للمتصل

4. بدء سير عمل معالجة منفصل (أو نفس سير العمل في خطوة لاحقة) يقوم بـ:

•  قراءة الحمولة على دفعات

•  المعالجة باستخدام **Split In Batches** (على سبيل المثال 50–200 سجل في المرة)

•  إجراء العمل الفعلي