Fusion Parallèle de Chunks Manticore Search

Fusion parallèle de chunks pour les tables RT dans Manticore Search 24.4.0

Dans Manticore Search 24.4.0, la compaction des tables RT s'exécute désormais en parallèle. Les fusions de chunks sur disque se lancent simultanément, et chaque tâche peut combiner plus de deux chunks. Paramètres clés : parallel_chunk_merges contrôle le nombre de tâches de fusion parallèles, tandis que merge_chunks_per_job définit le nombre de chunks par tâche. La commande OPTIMIZE exploite un pool de workers en arrière-plan avec une fusion N-voies.

Cela résout les retards de compaction sous charges de données constantes avec un optimize_cutoff bas. Les tables restent consultables immédiatement après les insertions, mais l'optimisation complète vers le nombre cible de chunks prenait auparavant plusieurs minutes.

Benchmark avec 10 millions de documents

Nous avons testé une table RT avec les champs id bigint, name text (10–100 mots), type int, et optimize_cutoff='16'. Chargement via 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

Mode ancien (parallel_chunk_merges=1, merge_chunks_per_job=2) :

• Chargement 10M docs : 1:18.
• Compaction complète : 3:23.
• À 1:18 : 53 chunks.

Nouveau mode (parallel_chunk_merges=3, merge_chunks_per_job=5) :

• Chargement : 1:18.
• Compaction complète : 1:31.
• À 1:18 : 23 chunks.

Gain : temps total réduit de 55 %, latence de fusion terminale divisée par 90 %.

Comparaison des types de stockage

| Type de stockage | Meilleurs réglages | Temps | Pire réglages | Temps | Amélioration |

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

| Ligne par ligne | parallel_chunk_merges=4, merge_chunks_per_job=5 | 14:35 | parallel_chunk_merges=1, merge_chunks_per_job=2 | 67:15 | 4,61x |

| Colonnes | parallel_chunk_merges=4, merge_chunks_per_job=5 | 15:10 | parallel_chunk_merges=1, merge_chunks_per_job=2 | 99:14 | 6,80x |

Valeurs optimales : parallel_chunk_merges=4–5, merge_chunks_per_job=4–5. Les nouveaux réglages par défaut atteignent 1:57 pour les mêmes 10M docs.

Facteurs d'ajustement clés :

• Un merge_chunks_per_job bas permet plus de tâches parallèles.
• Une valeur élevée accélère les fusions individuelles mais limite le parallélisme.
• L'équilibre dépend de l'I/O et de la charge.

Équilibre des paramètres

parallel_chunk_merges lance plusieurs tâches simultanément. merge_chunks_per_job détermine la charge par tâche. Avec de nombreux chunks, des tâches légères (faible merge_chunks_per_job) libèrent des ressources pour le parallélisme. Des tâches lourdes réduisent les étapes mais monopolisent le pool de workers.

Les benchmarks montrent que 3–5 sur les deux paramètres minimisent le temps. Pour les charges RT avec insertions en masse, cela réduit drastiquement les temps d'attente d'optimisation sans ralentir les insertions.

Points clés :

• Les données sont consultables immédiatement ; la compaction s'exécute en arrière-plan.
• La fusion parallèle réduit la latence terminale de 90 % (de 2:05 à 0:13).
• Jusqu'à 6,8x d'accélération sur stockage colonnaire.
• Les nouveaux réglages par défaut sont 40 % plus rapides que l'ancien mode.
• Moins de chunks pendant le chargement (23 contre 53).

Recommandations d'ajustement

• Commencez par les réglages par défaut de Manticore Search 24.4.0.
• Surveillez le nombre de chunks et l'I/O pendant les chargements.
• Augmentez parallel_chunk_merges à 4–5 si CPU disponible.
• Testez merge_chunks_per_job=4–5 pour les grandes tables RT.
• Exécutez OPTIMIZE pour forcer la compaction après les lots.

Pour les flux d'insertions continus avec un optimize_cutoff bas, ces changements maintiennent les tables stables sans tâches en arrière-plan trop longues.

— Editorial Team