أنا حالياً أقوم بإنشاء سير عمل أتمتة في n8n لمعالجة حمولات بيانات ثقيلة وأواجه عقبة في التنفيذ أثناء مهام ذروة الحجم.
الإعداد الحالي:
مثيل n8n مستضاف ذاتياً يتعامل مع تدفقات بيانات عالية التكرار من نقاط نهاية webhook و API متعددة.
استخدام عُقد Code متقدمة (JavaScript) لتحليل وتحويل وإعادة هيكلة كائنات JSON المتداخلة بعمق قبل دفعها إلى التطبيقات الأسفل.
التحدي:
مع نمو أحجام الدفعات، يرتفع استخدام ذاكرة التنفيذ بشكل كبير. في بعض الأحيان، تتسبب مصفوفات البيانات الكبيرة في إبطاء التنفيذ أو الوصول إلى الحدود عند التعامل مع هياكل عناصر ضخمة دفعة واحدة في كتلة تنفيذ عقدة Code واحدة.
ما أفضل الممارسات أو أنماط تصميم سير العمل التي توصي بها هذه المجتمعات لتقسيم البيانات بكفاءة وإدارة الحمل الزائد للذاكرة أو تحسين تحويلات الحمولة الضخمة في عُقد n8n Code؟
أود أن أسمع أي نصائح أو استراتيجيات توسع من بيئات الإنتاج لديكم. شكراً!
مرحباً @Maaz
لن يؤدي “Loop Over Items” بمفرده إلى تقليل ذاكرة الذروة، حيث تحتفظ العقدة بالمدخلات الأصلية وتعيد دمج كل دفعة معالجة في مخرجات “Done”، لذا تبقى مجموعة البيانات الكاملة داخل تنفيذ واحد. انقل التحويل بدلاً من ذلك: استخدم “Loop Over Items” بحجم دفعة في المئات القليلة، ثم استخدم “Execute Sub-workflow”، مع وجود عمل عقدة “Code” في سير العمل الفرعي وإرجاع مجموعة نتائج صغيرة فقط للعقدة الأصلية (معرّفات، عدادات، حالة). تتحرر الذاكرة بعد كل دفعة بدلاً من الاحتفاظ بكل عنصر في نفس الوقت.
قم بتشغيل هذه من خلال المشغل وليس التنفيذات اليدوية، فالتشغيلات اليدوية تجعل n8n ينسخ البيانات للواجهة الأمامية بالإضافة إلى ما يحتفظ به التنفيذ بالفعل.
إذا كنت تحدد حجم الصندوق لهذا النوع من الحمل، فهذا يغطيه: