本文由 Marius Matilionis 撰写，他是 Ivinco 公司的高级开发人员和 Manticore Search 专家。Ivinco 专注于提供前沿的搜索解决方案、数据库优化、事件管理以及可观测性设置，帮助企业在运营中实现更快、更高效和可扩展的操作。

理解挑战

大规模 Manticore Search 表的完整重新索引可能是一个耗时且资源密集的任务。当表配置发生重大更改时，例如修改异常或调整数据结构，通常需要进行完整重新索引以确保搜索结果的准确性。

传统方法：基于脚本的重新索引

传统方法涉及编写自定义脚本来遍历文档、解析它们并将其发送到表中。虽然这种方法提供了灵活性，但对于大型数据集来说可能很慢。性能瓶颈通常在于该过程的迭代性质，这可能导致显著的开销。

更高效的方法：利用 mysqldump

mysqldump 是一个强大的工具，用于备份和恢复 MySQL 数据库，可以有效地用于简化重新索引过程。通过直接转储和恢复表数据，我们可以显著减少此操作所需的时间。

关键步骤：

• 准备表：

  • 存储文本索引列： 确保所有文本索引列以文本形式存储，以优化转储和恢复过程。这种格式在数据传输中更高效，并可最小化重新索引期间的潜在问题。
  • 创建新表： 创建一个具有所需配置的新表以适应更改。

• 执行 mysqldump：

  • 使用以下 mysqldump 命令转储表数据：

    mysqldump -etc --replace -P7103 -h0 manticore rt_index_2 | mysql -P7103 -h0
    

• 优化表（可选。如果启用了 auto_optimize（默认启用），则不需要此步骤）：

  • 运行优化（optimize table rt_index_2 option sync=1）： 重新索引后，表大小为 8.9GB。优化过程有助于回收磁盘空间（优化后表大小为 4.4GB），并优化表结构。此步骤对于确保最佳性能和减少存储开销至关重要。

性能分析与考虑

我们的测试显示，使用 mysqldump 时性能显著提升：

如您所见，虽然将文本索引列存储为存储格式会增加初始表大小 25%（从 3.5GB 增加到 4.4GB），但它显著减少了重新索引时间，从 94 分钟减少到 17 分钟，实现了 6 倍的速度提升。

关键考虑因素：

• 磁盘空间： 虽然 mysqldump 在重新索引过程中需要额外的磁盘空间，但优化后表的最终大小保持不变。在我们的情况下，初始表大小为 4.4GB，重新索引后表大小增加到 8.9GB。然而，经过调试压缩后，大小又减少回 4.4GB。
• 表结构： 表的特定结构可能会影响两种方法的性能。可能需要进行实验以确定最适合您特定用例的优化方法。
• 数据一致性： 确保重新索引过程中的数据一致性并避免冲突，尤其是在表正在被更新时。这可能涉及使用锁定或异步更新等技术。
• 硬件和软件配置： 重新索引过程的性能可能受到硬件资源（CPU、内存、磁盘 I/O）、数据库配置和网络延迟等因素的影响。

结论

通过利用 mysqldump 进行重新索引，我们可以显著减少与这一关键任务相关的耗时和资源需求。这种优化对于大规模搜索表尤其有益，其中性能和效率至关重要。在考虑重新索引策略时，请仔细评估您应用程序和基础设施的具体需求，以确定最适合的方法。

Marius Matilionis 是 Ivinco 公司的高级开发人员和 Manticore Search 专家，该公司专注于搜索解决方案、数据库优化、事件管理和可观测性设置。本文反映了他在为大规模应用程序优化 Manticore Search 方面的专业知识。