أفضل الممارسات لتحليل حمولات JSON ضخمة من ScholarAPI في عقد HTTP Request؟

أسئلة
1

مرحبا بالمجتمع،
أنا حاليًا أقوم ببناء سير عمل n8n يؤتمت استيعاب البحث الأكاديمي لقاعدة بيانات المتجهات. الهدف هو سحب المقالات العلمية وبيانات الاستشهادات بناءً على محفزات بحث محددة.
في البداية، حاولت بناء سير عمل الأتمتة باستخدام أدوات كشط أساسية عبر عقدة HTTP Request، لكن التعامل مع الوكلاء الدوارة والتغييرات الهيكلية في HTML و CAPTCHAs المفاجئة جعلت سير العمل يفشل باستمرار ويتجاوز المهلة الزمنية.
لحل هذه المشكلة، أنا الآن أتحول إلى خط أنابيب بيانات منظم. أختبر إعدادًا حيث أسحب حمولات JSON منظمة ونظيفة مباشرة إلى n8n باستخدام بنية تحتية مثل ScholarAPI. ومع ذلك، يمكن أن تصبح مصفوفات JSON الأكاديمية كبيرة جدًا (تحتوي على بيانات وصفية عميقة للمقالات وسجلات الملخصات وعناوين URL لملفات PDF).

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

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

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

كنت أود أن أسأل ما إذا كان أي شخص قد حسّن سير عمل استيعاب بيانات مشابه:

  1. هل من الأفضل التعامل مع قياس حمولة JSON الضخمة داخل معمارية Execute Workflow / Sub-workflow لمنع الحمل الزائد على الذاكرة على مثيل n8n الرئيسي؟

  2. شارك المخرجات التي أرجعتها العقدة الأخيرة

ما هي الطريقة المفضلة لديك للمرور عبر المصفوفات العميقة في n8n — الاعتماد بشكل كبير على Loop Node المدمج، أم تنفيذ Code Node مخصص نظيف (JavaScript) لتعيين المتغيرات مباشرة إلى عقد HTTP اللاحقة؟
أود أن أسمع بعض نصائح معمارية من أي شخص يقوم بتشغيل سير عمل بيانات ثقيل هنا!

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

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

مرحبا @Stream_On، أهلا وسهلا!
أفضل طريقة، في رأيي، هي أن يمكن تقسيم حمولتك إلى سير عمل فرعية ومعالجتها وتطهيرها في كل تكرار. أعتقد أن هذا سيكون أفضل نهج؛ بشكل أساسي، طالما أن سير العمل الفرعي يقوم بكل العمل على دفعات ويعطي النتيجة النهائية في كل مرة، فسيعمل دائما. أيضا، أفضل ممارسة هي تعيين هذا المتغير N8N_DEFAULT_BINARY_DATA_MODE=filesystem بحيث لا يتراكم الذاكرة وتستنزف التدفق.