Paralelní sloučení chunků Manticore Search

Paralelní kompaktrace RT tabulek v Manticore Search 24.4.0

V verzi Manticore Search 24.4.0 se kompaktrace RT tabulek přesunula na paralelní provádění. Nyní se slučování diskových chunků spouští současně a každá úloha může sloučit více než dva chunky. Klíčové parametry: parallel_chunk_merges – počet paralelních úloh slučování, merge_chunks_per_job – počet chunků na úlohu. Příkaz OPTIMIZE funguje přes pool pozadíových workerů s N-cestným slučováním.

Toto řeší problém zpoždění kompaktrace při neustálém načítání dat s nízkým optimize_cutoff. Tabulka je dostupná pro vyhledávání hned po vložení, ale úplná optimalizace na cílový počet chunků dříve trvala minuty.

Benchmark s 10 miliony dokumentů

Testovali jsme RT tabulku s poli id bigint, name text (10–100 slov), type int a optimize_cutoff='16'. Načítání přes 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

Starý režim (parallel_chunk_merges=1, merge_chunks_per_job=2):

• Načítání 10M dokumentů: 1:18.
• Úplná kompaktrace: 3:23.
• Po 1:18 – 53 chunků.

Nový režim (parallel_chunk_merges=3, merge_chunks_per_job=5):

• Načítání: 1:18.
• Úplná kompaktrace: 1:31.
• Po 1:18 – 23 chunků.

Výhoda: celkový čas o 55 % kratší, zpoždění slučování se snížilo o 90 %.

Srovnání podle typů úložiště

| Úložiště | Nejlepší nastavení | Čas | Nejhorší nastavení | Čas | Zlepšení |

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

| Řádkové | parallel_chunk_merges=4, merge_chunks_per_job=5 | 14:35 | parallel_chunk_merges=1, merge_chunks_per_job=2 | 67:15 | 4.61x |

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

Optimální hodnoty: parallel_chunk_merges=4–5, merge_chunks_per_job=4–5. Nové výchozí hodnoty zvládnou stejných 10M dokumentů za 1:57.

Klíčové faktory ladění:

• Nízký merge_chunks_per_job umožňuje více paralelních úloh.
• Vysoká hodnota urychluje slučování, ale omezuje paralelizmus.
• Rovnováha závisí na I/O a zatížení.

Rovnováha parametrů

parallel_chunk_merges spouští několik úloh současně. merge_chunks_per_job určuje objem na úlohu. Při velkém počtu chunků malé úlohy (merge_chunks_per_job nízký) nechávají zdroje pro paralelizmus. Těžké úlohy snižují kroky, ale blokují pool.

V benchmarkách kombinace 3–5 u obou parametrů minimalizuje čas. Pro RT zatížení s hromadnými vloženími nastavení zkracuje čekání na optimalizaci bez vlivu na rychlost vložení.

Co je důležité:

• Načítání dat je hned dostupné pro vyhledávání, kompaktrace běží na pozadí.
• Paralelní slučování snižuje zpoždění o 90 % (z 2:05 na 0:13).
• Zlepšení až 6,8x u sloupcového úložiště.
• Nové výchozí hodnoty jsou o 40 % rychlejší než starý režim.
• Tabulka má během načítání méně chunků (23 vs 53).

Doporučení pro nastavení

• Začněte s výchozími hodnotami Manticore Search 24.4.0.
• Monitorujte počet chunků a I/O během načítání.
• Zvyšte parallel_chunk_merges na 4–5 při rezervě CPU.
• Testujte merge_chunks_per_job=4–5 pro velké RT tabulky.
• Používejte OPTIMIZE pro nucenou kompaktraci po dávkách.

Pro scénáře s neustálým proudem vložení a nízkým optimize_cutoff tyto změny zajišťují stabilní stav tabulky bez dlouhých pozadíových operací.

— Editorial Team