Hola chicos, estoy trabajando en un flujo de trabajo de n8n que procesa una gran cantidad de registros, e intento evitar situaciones en las que el uso de memoria crezca demasiado o las ejecuciones se vuelvan innecesariamente lentas.
El flujo de trabajo es aproximadamente: Obtener Datos → 10,000+ Registros → Transformar → API Externa → Guardar Resultados
En este momento, procesar todo en una sola ejecución parece arriesgado, especialmente cuando la cantidad de datos no es predecible.
¿Cómo decidís el tamaño de lote razonable?
¿Cuándo usarías subflujos en lugar de mantener todo en un único flujo de trabajo?
¿Cómo previenen que una ejecución grande consuma demasiada memoria?
¿Hay alguna característica o patrón de n8n que haya funcionado particularmente bien para esto?
Me interesará escuchar cómo otros manejan el procesamiento de datos de alto volumen sin hacer que sus flujos de trabajo sean innecesariamente complejos.
Describir el problema/error/pregunta
¿Cuál es el mensaje de error (si hay alguno)?
Comparta su flujo de trabajo
(Seleccione los nodos en su lienzo y use los atajos de teclado CMD+C/CTRL+C y CMD+V/CTRL+V para copiar y pegar el flujo de trabajo.)
Comparta el resultado devuelto por el último nodo
Información sobre su configuración de n8n
Versión de n8n:
Base de datos (predeterminado: SQLite):
Configuración de n8n EXECUTIONS_PROCESS (predeterminado: own, main):
Ejecutando n8n a través de (Docker, npm, n8n cloud, aplicación de escritorio):
Hola @Greg_John, evitaría procesar todo en una única ejecución si el conjunto de datos puede ser grande o impredecible. Un mejor enfoque es procesar los datos en lotes más pequeños y mantener cada ejecución ligera.
El tamaño del lote depende de la carga de trabajo. Si cada elemento requiere una llamada a API o una transformación pesada, comenzaría con un tamaño más pequeño e iría aumentándolo mientras monitoreo la memoria, el tiempo de ejecución y los límites de velocidad de la API.
Para cargas de trabajo realmente grandes, también consideraría usar sub-flujos de trabajo y modo de cola con múltiples trabajadores para que el procesamiento se pueda distribuir en lugar de que una única ejecución haga todo.
Main Workflow ↓ Get Records ↓ Split Into Batches ↓ Execute Sub-workflow ↓ Worker 1 → Process Batch Worker 2 → Process Batch Worker 3 → Process Batch
Si estoy usando PostgreSQL para obtener los registros, también evitaría cargar miles de filas innecesariamente:
SELECT id, customer_id, payload FROM orders WHERE status = 'pending' ORDER BY id LIMIT 500;
Hola @Greg_John
El lote por sí solo no reduce la memoria máxima. n8n mantiene la salida de cada nodo durante toda la ejecución, por lo que 10.000 registros divididos en lotes de 200 dentro de un flujo de trabajo siguen teniendo los 10.000 activos al final. Lo que libera memoria es trasladar el trabajo por lote a un subflujo de trabajo con Execute Workflow y devolver solo un pequeño resultado al padre, porque los datos del subflujo de trabajo se liberan una vez que finaliza cada lote. Entonces, el número que decide tu límite de memoria es lo que regresa, no el tamaño del lote.
Lo que te puede confundir mientras pruebas es la ejecución manual, que copia los datos para la interfaz además de todo lo demás, por lo que una ejecución que falla en el editor puede funcionar bien en producción.