Fusión Paralela de Chunks Manticore Search

# Fusión paralela de fragmentos en tablas RT de Manticore Search 24.4.0

En Manticore Search 24.4.0, la compactación de tablas RT ahora se ejecuta en paralelo. Las fusiones de fragmentos en disco se lanzan simultáneamente, y cada tarea puede combinar más de dos fragmentos. Parámetros clave: parallel_chunk_merges controla el número de tareas de fusión paralelas, mientras que merge_chunks_per_job define los fragmentos por tarea. El comando OPTIMIZE aprovecha un grupo de trabajadores en segundo plano con fusiones N-vía.

Esto soluciona los retrasos en la compactación bajo cargas de datos constantes con optimize_cutoff bajo. Las tablas son buscables inmediatamente después de las inserciones, pero la optimización completa al número objetivo de fragmentos solía tomar minutos.

Prueba de rendimiento con 10 millones de documentos

Probamos una tabla RT con campos id bigint, name text (10–100 palabras), type int y optimize_cutoff='16'. Carga mediante Manticore Load Emulator:

manticore-load \
  --cache-gen-workers=5 \
  --drop \
  --batch-size=1000 \
  --threads=5 \
  --total=10000000 \
  --init="CREATE TABLE test(id bigint, name text, type int) optimize_cutoff='16'" \
  --load="INSERT INTO test(id,name,type) VALUES(<increment>,'<text/10/100>',<int/1/100>)" \
  --wait

Modo antiguo (parallel_chunk_merges=1, merge_chunks_per_job=2):

• Carga de 10M docs: 1:18.
• Compactación completa: 3:23.
• A 1:18: 53 fragmentos.

Modo nuevo (parallel_chunk_merges=3, merge_chunks_per_job=5):

• Carga: 1:18.
• Compactación completa: 1:31.
• A 1:18: 23 fragmentos.

Ganancia: tiempo total reducido un 55%, latencia de cola de fusión cortada un 90%.

Comparación de tipos de almacenamiento

| Tipo de almacenamiento | Configuración óptima | Tiempo | Configuración peor | Tiempo | Mejora |

|------------------------|------------------------------------------|--------|-----------------------------------|---------|---------|

| Por filas | parallel_chunk_merges=4, merge_chunks_per_job=5 | 14:35 | parallel_chunk_merges=1, merge_chunks_per_job=2 | 67:15 | 4.61x |

| Columnares | parallel_chunk_merges=4, merge_chunks_per_job=5 | 15:10 | parallel_chunk_merges=1, merge_chunks_per_job=2 | 99:14 | 6.80x |

Valores óptimos: parallel_chunk_merges=4–5, merge_chunks_per_job=4–5. Los nuevos valores predeterminados tardan 1:57 en los mismos 10M docs.

Factores clave de ajuste:

• Bajo merge_chunks_per_job permite más tareas paralelas.
• Valor alto acelera fusiones individuales pero limita el paralelismo.
• El equilibrio depende de E/S y carga de trabajo.

Equilibrio de parámetros

parallel_chunk_merges lanza múltiples tareas a la vez. merge_chunks_per_job dicta la carga por tarea. Con muchos fragmentos, tareas ligeras (bajo merge_chunks_per_job) liberan recursos para paralelismo. Tareas pesadas reducen pasos pero acaparan el grupo de trabajadores.

Las pruebas muestran que 3–5 en ambos parámetros minimiza el tiempo. Para cargas RT con inserciones masivas, esto reduce drásticamente los tiempos de espera de optimización sin ralentizar las inserciones.

Lecciones clave:

• Los datos son buscables de inmediato; la compactación corre en segundo plano.
• La fusión paralela reduce la latencia de cola un 90% (de 2:05 a 0:13).
• Hasta 6.8x de aceleración en almacenamiento columnar.
• Nuevos predeterminados 40% más rápidos que el modo antiguo.
• Menos fragmentos durante la carga (23 vs 53).

Recomendaciones de ajuste

• Comienza con los valores predeterminados de Manticore Search 24.4.0.
• Monitorea el conteo de fragmentos y E/S durante las cargas.
• Aumenta parallel_chunk_merges a 4–5 con CPU sobrante.
• Prueba merge_chunks_per_job=4–5 para tablas RT grandes.
• Ejecuta OPTIMIZE para forzar compactación tras lotes.

Para flujos de inserción continua con optimize_cutoff bajo, estos cambios mantienen las tablas estables sin tareas en segundo plano prolongadas.

— Editorial Team