这篇博客文章由 Marius Matilionis 撰写，他是 Ivinco 的高级开发人员和 Manticore Search 专家。Ivinco 专注于提供尖端搜索解决方案、数据库优化、事件管理和可观察性设置，以帮助企业实现更快、更高效和可扩展的运营。

理解挑战

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

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

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

更高效的方法：利用 mysqldump

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

关键步骤：

• 准备表：

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

• 执行 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 方面的专业知识。