Tengo un flujo de trabajo n8n que extrae miles de registros de una API, los transforma y luego escribe los resultados en una base de datos.
Funciona bien con conjuntos de datos más pequeños, pero cuando la API devuelve decenas de miles de registros, la ejecución se vuelve muy lenta y a veces se bloquea porque hay demasiados datos en memoria.
Actualmente estoy pensando en procesar los datos en lotes más pequeños: const batchSize = 100;
return $input.all().slice(0, batchSize);
¿Me recomendarías usar lotes, paginación, streaming, sub-flujos o una combinación de estos para mantener bajo el uso de memoria mientras mantienes un buen rendimiento y confiabilidad?
Describe el problema/error/pregunta
¿Cuál es el mensaje de error (si la hay)?
Por favor, comparte tu flujo de trabajo
(Selecciona los nodos en tu lienzo y usa los atajos de teclado CMD+C/CTRL+C y CMD+V/CTRL+V para copiar y pegar el flujo de trabajo.)
Para conjuntos de datos grandes, evitaré cargar todo en una sola ejecución de n8n. Usaría paginación + procesamiento por lotes, y movería el procesamiento más pesado a sub-flujos de trabajo cuando sea necesario
En lugar de una solicitud masiva, usa la Paginación integrada del nodo HTTP Request.
En el nodo HTTP Request, ve a Add Option > Pagination. Configúralo según si tu API usa “Offset/Limit”, “Números de página” o “Cursores”.
@Emmas mover el procesamiento más pesado hacia sub-flujos de trabajo también es lo correcto
¡Hola @Catherine! ¡Bienvenida!
La paginación no reducirá tu memoria. La documentación la describe como una solución para resultados demasiado grandes para que la API los devuelva en una sola llamada, y obtiene todas las páginas en la salida del nodo, por lo que 50.000 registros siguen estando activos en esa ejecución. Resuelve el límite de la API en lugar del fallo.
El procesamiento por lotes dentro del mismo flujo de trabajo tampoco libera memoria, porque n8n mantiene la salida de cada nodo durante toda la ejecución. Lo que la libera es trasladar el trabajo por lotes a un subfllujo de trabajo con Execute Workflow y devolver solo un resultado pequeño, ya que los datos del subfllujo de trabajo desaparecen tan pronto como se completa cada lote.
Por otra parte, $input.all().slice(0, batchSize) no es procesamiento por lotes. Mantiene los primeros 100 elementos y descarta el resto.
Lo que necesitas abordar es la paginación en su origen. El hecho de que se esté usando $input.all() es la clave. Ese comando ya carga todos los elementos en memoria antes de que se ejecute slice(), por lo que realmente no ayudará a largo plazo.
Intenta usar los parámetros de paginación de tu API (page/offset o cursor) dentro de un bucle para que solo obtengas una página a la vez y luego pases cada página a través de “Loop Over Items” (Split In Batches) para tus pasos de transformación y escritura. Esto mantendría la memoria acotada independientemente del número total de registros.
Si tienes un paso de transformación más pesado, intenta delegarlo a un subworkflow. Cuando se usa subworkflow, cada ejecución obtiene su propio contexto de memoria que se libera cuando finaliza; esto ayuda en ejecuciones grandes. N8n no tiene verdadero streaming entre nodos, así que es mejor optar por una combinación de subworkflow y paginación aquí.