并行块合并 Manticore Search

Manticore Search 24.4.0 RT 表并行块合并优化

在 Manticore Search 24.4.0 中，RT 表的压缩现在支持并行运行。磁盘块合并可以同时启动多个任务，每个任务能合并超过两个块。主要参数：parallel_chunk_merges 控制并行合并任务数量，merge_chunks_per_job 设置每个任务处理的块数。OPTIMIZE 命令利用后台工作线程池进行 N 路合并。

这解决了在持续数据加载且 optimize_cutoff 较低时出现的压缩延迟问题。数据插入后表立即可搜索，但以前达到目标块数的全优化需要几分钟时间。

1000 万文档基准测试

我们测试了一个 RT 表，字段包括 id bigint、name text（10–100 个词）、type int，并设置 optimize_cutoff='16'。使用 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

旧模式（parallel_chunk_merges=1，merge_chunks_per_job=2）：

• 加载 1000 万文档：1:18。
• 完整压缩：3:23。
• 1:18 时：53 个块。

新模式（parallel_chunk_merges=3，merge_chunks_per_job=5）：

• 加载：1:18。
• 完整压缩：1:31。
• 1:18 时：23 个块。

提升：总时间缩短 55%，合并尾部延迟减少 90%。

存储类型对比

| 存储类型 | 最佳设置 | 时间 | 最差设置 | 时间 | 提升倍数 |

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

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

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

最佳值：parallel_chunk_merges=4–5，merge_chunks_per_job=4–5。新默认设置下，同等 1000 万文档仅需 1:57。

关键调优因素：

• 较低的 merge_chunks_per_job 可启用更多并行任务。
• 较高值加速单个合并，但限制并行度。
• 平衡取决于 I/O 和负载。

参数平衡

parallel_chunk_merges 允许同时启动多个任务。merge_chunks_per_job 决定每个任务的工作量。当块数较多时，轻量任务（低 merge_chunks_per_job）能释放资源支持并行。重负载任务减少步骤但占用工作线程池。

基准测试显示，两参数设为 3–5 时时间最短。对于批量插入的 RT 负载，这大幅缩短优化等待时间，同时不影响插入速度。

关键要点：

• 数据插入后立即可搜索；压缩在后台运行。
• 并行合并将尾部延迟降低 90%（从 2:05 到 0:13）。
• 列式存储加速高达 6.8 倍。
• 新默认比旧模式快 40%。
• 加载期间块数更少（23 vs 53）。

调优建议

• 从 Manticore Search 24.4.0 默认值开始。
• 监控加载期间的块数和 I/O。
• 有闲置 CPU 时，将 parallel_chunk_merges 调至 4–5。
• 大型 RT 表测试 merge_chunks_per_job=4–5。
• 批次后运行 OPTIMIZE 强制压缩。

对于低 optimize_cutoff 的连续插入流，这些改动确保表稳定，无需长时间后台任务。

— Editorial Team