Parallele Chunk-Zusammenführung Manticore Search

Parallele Chunk-Verschmelzung für RT-Tabellen in Manticore Search 24.4.0

In Manticore Search 24.4.0 läuft die Kompaktierung von RT-Tabellen nun parallel. Die Verschmelzung von Festplatten-Chunks startet gleichzeitig, und jeder Job kann mehr als zwei Chunks kombinieren. Wichtige Parameter: parallel_chunk_merges steuert die Anzahl paralleler Verschmelzungsjobs, während merge_chunks_per_job die Chunks pro Job festlegt. Der OPTIMIZE-Befehl nutzt einen Pool von Hintergrundarbeitern mit N-facher Verschmelzung.

Das behebt Verzögerungen bei der Kompaktierung unter kontinuierlicher Datenbelastung mit niedrigem optimize_cutoff. Tabellen sind direkt nach dem Einfügen durchsuchbar, aber die vollständige Optimierung auf die Ziele Chunk-Anzahl dauerte früher Minuten.

Benchmark mit 10 Millionen Dokumenten

Wir haben eine RT-Tabelle mit Feldern id bigint, name text (10–100 Wörter), type int und optimize_cutoff='16' getestet. Laden über 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

Alter Modus (parallel_chunk_merges=1, merge_chunks_per_job=2):

• Laden von 10M Docs: 1:18.
• Volle Kompaktierung: 3:23.
• Bei 1:18: 53 Chunks.

Neuer Modus (parallel_chunk_merges=3, merge_chunks_per_job=5):

• Laden: 1:18.
• Volle Kompaktierung: 1:31.
• Bei 1:18: 23 Chunks.

Gewinn: Gesamtzeit um 55 % reduziert, Verschmelzungs-Schwanzlatenz um 90 % gekürzt.

Vergleich der Speichertypen

| Speichertyp | Beste Einstellungen | Zeit | Schlechteste Einstellungen | Zeit | Verbesserung |

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

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

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

Optimale Werte: parallel_chunk_merges=4–5, merge_chunks_per_job=4–5. Neue Standardwerte schaffen die gleichen 10M Docs in 1:57.

Wichtige Tuning-Faktoren:

• Niedriger merge_chunks_per_job ermöglicht mehr parallele Jobs.
• Hoher Wert beschleunigt einzelne Verschmelzungen, begrenzt aber Parallelität.
• Balance hängt von I/O und Workload ab.

Parameter-Balance

parallel_chunk_merges startet mehrere Jobs gleichzeitig. merge_chunks_per_job bestimmt die Arbeitslast pro Job. Bei vielen Chunks geben leichte Jobs (niedriger merge_chunks_per_job) Ressourcen für Parallelität frei. Schwere Jobs reduzieren Schritte, binden aber den Worker-Pool.

Benchmarks zeigen: 3–5 bei beiden Parametern minimiert die Zeit. Für RT-Workloads mit Masseneinfügungen verkürzt das Optimierungs-Wartezeiten, ohne Einfügungen zu verlangsamen.

Wichtige Erkenntnisse:

• Daten sind sofort durchsuchbar; Kompaktierung läuft im Hintergrund.
• Parallele Verschmelzung reduziert Schwanzlatenz um 90 % (von 2:05 auf 0:13).
• Bis zu 6,8x Beschleunigung bei spaltenweisem Speicher.
• Neue Standards sind 40 % schneller als alter Modus.
• Weniger Chunks beim Laden (23 vs. 53).

Tuning-Empfehlungen

• Starte mit Manticore Search 24.4.0-Standards.
• Überwache Chunk-Anzahl und I/O während des Ladens.
• Erhöhe parallel_chunk_merges auf 4–5 bei freier CPU.
• Teste merge_chunks_per_job=4–5 für große RT-Tabellen.
• Führe OPTIMIZE aus, um Kompaktierung nach Batches zu erzwingen.

Bei kontinuierlichen Einfüge-Strömen mit niedrigem optimize_cutoff halten diese Änderungen Tabellen stabil, ohne lang laufende Hintergrundaufgaben.

— Editorial Team