Nivel 3 · 30 min

Performance

El tuning de performance en Elasticsearch abarca throughput de indexación, latencia de queries y utilización de recursos del cluster. Entender el sizing de shards, el profiling de queries y los patrones de bulk indexing es esencial para operar clusters en producción a escala.

Sizing y Gestión de Shards

Un shard es un índice Lucene: la unidad de distribución en Elasticsearch. Cada shard tiene overhead: JVM heap, file descriptors y slots de thread pool. El over-sharding es un error común: 10.000 shards pequeños desperdician más recursos que 100 grandes. El shard size recomendado es 10-50 GB (límite hard 50 GB). Calculá: target_shards = total_data_size_gb / 30. Para datos de series temporales, usá ILM con rollover: rotá cuando size '>' 30 GB o age '>' 30 días. Evitá shards menores a 1 GB — tienen overhead desproporcionado.

Query Profiling y Slow Logs

La Profile API (agrega profile: true a tu request de búsqueda) devuelve un desglose detallado del tiempo gastado en cada cláusula de query y fase de aggregation. Usala para identificar qué cláusula domina la latencia. Los slow logs capturan queries que superan un umbral: index.search.slowlog.threshold.query.warn: 5s. La Explain API (_explain) muestra por qué un documento específico fue o no retornado y cómo se calculó su score.

Performance de Indexación

La Bulk API agrupa múltiples operaciones index/update/delete en un request HTTP: la optimización de indexación más importante. Tamaño óptimo de batch: 5-15 MB de payload (no conteo de documentos). index.refresh_interval controla cada cuánto los documentos nuevos son buscables (default 1s). Para bulk loads, seteá refresh_interval: -1 (deshabilitar) y number_of_replicas: 0 durante la carga, luego restaurá. Esto evita el segment merging constante durante la indexación. La mejora de throughput puede ser de 10x.

Puntos clave

Mantené shards entre 10-50 GB. El over-sharding desperdicia JVM heap y file descriptors. Calculá el conteo de shards a partir del tamaño de datos, no del conteo de documentos.
Profile API para depuración interactiva. Slow logs para alertas en producción. Ambos son esenciales: los slow logs detectan regresiones que nunca perfilaste con Profile.
Para bulk indexing: deshabilitar refresh (refresh_interval: -1), cero réplicas, batches de 5-15 MB. Restaurá settings después. Esto puede mejorar el throughput 10x.

Code example

// Profile a slow query\nPOST /products/_search\n{"profile": true, "query": {"match": {"name": "laptop"}'}'} \n\n// Bulk indexing setup\nPUT /products/_settings\n{"index": {"refresh_interval": "-1", "number_of_replicas": "0"}'}' \n\n// Slow log threshold\nPUT /products/_settings\n{"index.search.slowlog.threshold.query.warn": "5s"}