التعامل مع مجموعات البيانات الكبيرة في n8n دون إبطاء سير العمل

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

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

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

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

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

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

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

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

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

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

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

المستندات:

المنتدى:

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

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

مرحباً @Greg_John أود تجنب معالجة كل شيء في تنفيذ واحد إذا كان يمكن لمجموعة البيانات أن تكبر أو تكون غير متوقعة. الطريقة الأفضل هي معالجة البيانات في دفعات أصغر والحفاظ على كل تنفيذ خفيف الوزن.

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

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

Main Workflow
↓
Get Records
↓
Split Into Batches
↓
Execute Sub-workflow
↓
Worker 1 → Process Batch
Worker 2 → Process Batch
Worker 3 → Process Batch

إذا كنت أستخدم PostgreSQL لجلب السجلات، فسأتجنب أيضاً تحميل آلاف الصفوف بدون داعٍ:

SELECT id, customer_id, payload
FROM orders
WHERE status = 'pending'
ORDER BY id
LIMIT 500;

مرحبا @Greg_John
المعالجة على دفعات وحدها لا تقلل من ذاكرة الذروة. يحتفظ n8n بمخرجات كل عقدة طوال التنفيذ، لذا فإن 10,000 سجل مقسم إلى دفعات من 200 داخل سير عمل واحد لا يزال يحتوي على جميع 10,000 في النهاية. ما يحرر الذاكرة هو نقل العمل لكل دفعة إلى سير عمل فرعي باستخدام Execute Workflow وإرجاع نتيجة صغيرة فقط إلى الأب، لأن بيانات سير العمل الفرعي يتم تحريرها بعد انتهاء كل دفعة. لذا فإن الرقم الذي يقرر سقف ذاكرتك هو ما يعود، وليس حجم الدفعة.
الشيء الذي سيضللك أثناء الاختبار هو التنفيذ اليدوي، الذي ينسخ البيانات للواجهة الأمامية فوق كل شيء آخر، لذا فإن تشغيل يموت في المحرر يمكن أن يكون بخير في الإنتاج.

شكراً @Niffzy @Anshul_Namdev