解析 ScholarAPI 的大型 JSON 資料到 HTTP Request 節點的最佳做法？

問題
1

嗨社群，
我目前正在建構一個 n8n 工作流程，用於自動化學術研究擷取到向量資料庫。目的是根據特定的搜尋觸發器拉取學術文章和引用資料。
最初，我嘗試使用 HTTP Request 節點透過基本爬蟲程式建構自動化工作流程，但處理旋轉代理伺服器、HTML 結構變化和突然出現的 CAPTCHA 導致工作流程不斷失敗和逾時。
為了解決這個問題，我改為採用結構化資料管道。我正在測試一個設置，使用 ScholarAPI 之類的基礎設施將乾淨的結構化 JSON 負載直接拉入 n8n。不過，學術 JSON 陣列的規模可能會相當大（包含深層文章後設資料、摘要日誌和 PDF URL）。

描述問題/錯誤/問題

錯誤訊息是什麼（如有的話）？

請分享你的工作流程

我想詢問是否有人最佳化過類似的資料擷取工作流程：

  1. 是否最好在 Execute Workflow / Sub-workflow 架構內處理龐大的 JSON 負載擴展，以防止主 n8n 執行個體上的記憶體負擔？

  2. 分享最後一個節點傳回的輸出

你在 n8n 中迴圈遍歷深層陣列的首選方式是什麼──大量依賴內建的 Loop Node，還是執行乾淨的自訂 Code Node（JavaScript）將變數直接對應到後續的 HTTP 節點？
很樂意聽聽任何在這裡執行大型資料工作流程的人提供的架構建議！

關於你的 n8n 設置的資訊

  • n8n 版本：
  • 資料庫（預設：SQLite）：
  • n8n EXECUTIONS_PROCESS 設定（預設：own、main）：
  • 執行 n8n 的方式（Docker、npm、n8n cloud、桌面應用程式）：
  • 作業系統：
2

嗨 @Stream_On，歡迎！
我認為最好的做法是，如果你的 payload 可以分解為子工作流，並在每次迭代運行時進行處理和清除。我認為那會是最好的方法；基本上，只要你的子工作流以批次方式完成所有工作並每次都輸出最終結果，它就總能正常運作。此外，最佳做法是設定這個變數 N8N_DEFAULT_BINARY_DATA_MODE=filesystem，這樣記憶體就不會堆積起來並耗盡流程。