这篇博文由 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 时性能显著提升：

如您所见，虽然将文本索引列存储为 stored 会使初始表大小增加 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 方面的专业知识。