El comportamiento de near real-time (NRT) en Elasticsearch está intrínsecamente ligado a su arquitectura interna de escritura. Cuando un cliente envía una solicitud de indexación, los documentos no se escriben directamente en segmentos inmutables en el disco. En su lugar, siguen un flujo de procesamiento específico:

• Los datos se almacenan inicialmente en un búfer de memoria en el nodo coordinador y se añade una entrada de recuperación al translog.
• Cada segundo (intervalo por defecto), se ejecuta una operación de refresh. Esto transfiere los datos del búfer de memoria al FileSystem Cache del sistema operativo, generando un nuevo segmento de Lucene. Solo a partir de este momento, los documentos se vuelven visibles para las operaciones de búsqueda.
• Tras completar el refresh, el búfer de memoria se limpia para liberar recursos.
• Cada 5 segundos (o según la configuración de durabilidad), el translog se sincroniza (flush) en el disco físico.
• Periódicamente, los segmentos almacenados en el FileSystem Cache se combinan y se escriben en disco mediante un flush incremental.

La latencia característica de las consultas NRT (aproximadamente 1 segundo) se debe exclusivamente al intervalo de tiempo transcurrido entre la escritura en memoria y la generación del segmento tras la operación de refresh.

Estrategias de Actualización (Refresh Policies)

Para controlar este comportamiento y equilibrar la visibilidad de los datos con el rendimiento, el motor expone tres directivas de actualización durante las operaciones de indexación:

• Inmediato (true): Fuerza una operación de refresh justo después de la operación actual, haciendo que los cambios sean visibles de inmediato para las consultas.
• Esperar (wait_for): Bloquea la respuesta de la solicitud hasta que se produzca el siguiente refresh programado por el sistema.
• Desactivado (false): No realiza ninguna acción de refresh explícita. Los cambios serán visibles en el siguiente ciclo de actualización automático del índice.

Análisis de Rendimiento en Indexación Unitaria

Al evaluar el rendimiento de la indexación de documentos individuales de forma secuencial, las diferencias entre estas estrategias son drásticas. Consideremos el siguiente fragmento de código utilizando el cliente oficial de Java para Elasticsearch:

IndexResponse respuestaIndexacion = clienteEs.index(idx -> idx
    .index("indice_objetivo")
    .id(String.valueOf(entidad.getId()))
    .document(entidad)
    .refresh(Refresh.True) // Aplicación de la estrategia de refresh
);

Los resultados de las pruebas de esfuerzo procesando 5000 registros revelan tiempos de respuesta contrastantes:

• Refresh Inmediato: ~545 segundos. El alto coste se debe a la creación constante de pequeños segmentos y la sobrecarga de operaciones de I/O.
• Sin Refresh: ~24 segundos. Al evitar la generación de segmentos, la escritura en memoria es extremadamente rápida.
• Esperar Refresh: ~5473 segundos. Este resultado contraintuitivo (el más lento de todos) requiere un análisis detallado del comportamiento de bloqueo.

Comprensión del Cuello de Botella en wait_for

El comportamiento de wait_for en bucles de escritura individual es altamente ineficiente. Si el intervalo de refresh global está configurado en 1 segundo, cada solicitud de indexación individual bloqueará el hilo de ejecución hasta que se complete el siguiente ciclo de refresh. Al observar los tiempos de procesamiento, cada documento tarda poco más de 1 segundo, ya que el hilo queda suspendido esperando el temporizador global.

Si modificamos la configuración del índice para aumentar el intervalo de actualización:

PUT /indice_objetivo/_settings
{
  "index": {
    "refresh_interval": "2s"
  }
}

El tiempo de procesamiento por documento individual aumenta a más de 2 segundos. Esto confirma que wait_for bloquea la ejecución hasta que se dispara el temporizador de refresh del índice. Por lo tanto, utilizar esta directiva en operaciones unitarias secuenciales degrada severamente el rendimiento general del sistema.

Optimización mediante Bulk API

La solución arquitectónica para maximizar el rendimiento de ingestión es utilizar la API de operaciones masivas (Bulk API). Agrupar múltiples operaciones en una sola solicitud de red reduce drásticamente la sobrecarga y permite que el motor procese los segmentos de manera mucho más eficiente.

A continuación, se muestra una implementación optimizada y corregida para la inserción en lote, aplicando la directiva de espera únicamente al final del procesamiento del lote completo:

public boolean procesarIngestionMasiva(String nombreIndice, List<Entidad> loteEntidades) {
    try {
        BulkRequest.Builder constructorBulk = new BulkRequest.Builder();
        
        for (Entidad item : loteEntidades) {
            constructorBulk.operations(op -> op.index(idx -> idx
                .index(nombreIndice)
                .id(String.valueOf(item.getId()))
                .document(item)
            ));
        }
        
        // Se aplica wait_for a nivel de la solicitud masiva completa
        BulkResponse respuestaBulk = clienteEs.bulk(constructorBulk
            .refresh(Refresh.WaitFor)
            .build());
        
        if (respuestaBulk.errors()) {
            System.err.println("Errores detectados en la ingestión masiva de documentos");
        }
        return true;
    } catch (Exception ex) {
        System.err.println("Fallo crítico en la operación masiva: " + ex.getMessage());
        return false;
    }
}

Al procesar un lote de 5000 documentos utilizando esta estrategia de Bulk combinada con wait_for al final de la solicitud, el tiempo total se reduce a aproximadamente 2.4 segundos. Esto demuestra que la agrupación de operaciones es la práctica fundamental para lograr un alto rendimiento y aprovechar correctamente las capacdiades de near real-time en Elasticsearch.