Równoległe scalanie chunków Manticore Search

Równoległa kompresja tabel RT w Manticore Search 24.4.0

W wersji Manticore Search 24.4.0 kompresja tabel RT przeszła na wykonywanie równoległe. Teraz scalanie dyskowych chunków uruchamia się jednocześnie, a każda operacja może łączyć więcej niż dwa chunki. Kluczowe parametry: parallel_chunk_merges — liczba równoległych zadań scalania, merge_chunks_per_job — liczba chunków na zadanie. Polecenie OPTIMIZE działa poprzez pulę wątków w tle z N-stronnym scalaniem.

To rozwiązuje problem opóźnień kompresji przy ciągłym obciążeniu danymi i niskim optimize_cutoff. Tabela jest dostępna do wyszukiwania natychmiast po wstawieniu, ale pełna optymalizacja do docelowej liczby chunków wcześniej trwała minuty.

Testy wydajności z 10 milionami dokumentów

Testowaliśmy tabelę RT z polami id bigint, name text (10–100 słów), type int i optimize_cutoff='16'. Ładowanie za pomocą 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

Stary tryb (parallel_chunk_merges=1, merge_chunks_per_job=2):

• Ładowanie 10M dokumentów: 1:18.
• Pełna kompresja: 3:23.
• Po 1:18 — 53 chunków.

Nowy tryb (parallel_chunk_merges=3, merge_chunks_per_job=5):

• Ładowanie: 1:18.
• Pełna kompresja: 1:31.
• Po 1:18 — 23 chunków.

Zysk: całkowity czas krótszy o 55%, ogon scalania zredukowany o 90%.

Porównanie według typów przechowywania

| Przechowywanie | Najlepsze ustawienia | Czas | Najgorsze ustawienia | Czas | Poprawa |

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

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

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

Optymalne wartości: parallel_chunk_merges=4–5, merge_chunks_per_job=4–5. Nowe domyślne ustawienia dają 1:57 na te same 10M dokumentów.

Kluczowe czynniki strojenia:

• Niski merge_chunks_per_job pozwala na więcej równoległych zadań.
• Wysoki parametr przyspiesza scalanie, ale ogranicza paralelizm.
• Balans zależy od I/O i obciążenia.

Balans parametrów

parallel_chunk_merges uruchamia kilka zadań jednocześnie. merge_chunks_per_job określa objętość na zadanie. Przy dużej liczbie chunków lekkie zadania (merge_chunks_per_job niski) zostawiają zasoby na paralelizm. Ciężkie zadania skracają kroki, ale blokują pulę.

W testach kombinacja 3–5 dla obu parametrów minimalizuje czas. Dla obciążeń RT z masowymi wstawieniami konfiguracja skraca oczekiwanie na optymalizację bez wpływu na prędkość wstawiania.

Co ważne:

• Ładowanie danych jest dostępne do wyszukiwania natychmiast, kompresja w tle.
• Równoległe scalanie redukuje ogon o 90% (z 2:05 do 0:13).
• Poprawa do 6,8x w przechowywaniu kolumnowym.
• Nowe domyślne już szybsze o 40% od starego trybu.
• Tabela trzyma mniej chunków podczas ładowania (23 vs 53).

Zalecenia konfiguracyjne

• Zacznij od domyślnych Manticore Search 24.4.0.
• Monitoruj liczbę chunków i I/O podczas ładowania.
• Zwiększaj parallel_chunk_merges do 4–5 przy zapasie CPU.
• Testuj merge_chunks_per_job=4–5 dla dużych tabel RT.
• Używaj OPTIMIZE do wymuszonej kompresji po batchach.

Dla scenariuszy z ciągłym strumieniem wstawień i niskim optimize_cutoff te zmiany zapewniają stabilny stan tabeli bez długich operacji w tle.

— Editorial Team