缩短MarkLogic重建索引时间

Question

对于包含数百个林的离线集群中的大型数据库(>100TB)，是否有一种方法可以缩短MarkLogic重建索引时间？

在重建索引期间禁用本地磁盘故障切换(副本林)如何？这会减少重新索引的时间吗？

Answer 1

重建索引主要受IO限制。提高性能相当于提高IO吞吐量-因此答案是相同的。由于您确实希望对副本林进行索引，因此不应该禁用它们--这只会将IO延迟到您重新启用它们。由于您说这是一个“离线”集群--我假设这意味着不涉及任何生产流量，因此您可以自由地重新配置可能暂时干扰请求处理的东西--这是一个学习优化IO性能的好机会。

IO性能是一个复杂的主题-- (对不起，没有简单的答案)。首先要考虑的是您的物理拓扑--您的“本地磁盘”是什么、在哪里以及如何连接的？例如。如果这是在云环境或数据中心，您的“本地磁盘”可能是NAS或网络驱动器，在这种情况下，您的网络IO可能是瓶颈。

另一个考虑因素是集群的大小，如果您可以为此增加集群的大小--这取决于林所在的位置以及它们是否易于连接到不同的服务器。

一般来说，我建议同时监控MarkLogic的“监控历史”和您的操作系统级别的性能工具。目标是在接近理论能力的情况下实现一致的IO活动，但不是更多。如果你“推得太紧”，那么你会得到一个很大的IO后台逻辑( IO队列长度) --这会导致大量的“抖动”，并最终导致如此长的延迟，以至于系统可能开始超时并重试。

因此，您需要限制重建索引，以便在任何一个物理磁盘上都不会立即变得太难。有许多方法可以做到这一点，在marklogic中重新索引和合并参数，平衡物理磁盘wrt到森林位置，临时使一些森林脱机，然后将它们‘旋转’到适当的位置等。这需要一些实验来找到正确的混合。

最后一点--用“太长时间”是主观的。重建100TB的索引需要大量的IO。这将会花费很长很长的时间。你的目标应该是看看如何避免让事情变得更糟，而不是尝试不可能的事情，让它花的时间比它可能做到的时间更短。您可以计算出一个粗略的最小时间。假设索引需要对所有数据进行完整的读写(这需要更多的时间，但这只是一个开始)。您的群集使用其他方式读写100TB数据需要多长时间？这是完全重新索引的最低门槛。

优化您的操作系统的基本IO吞吐量，MarkLogic索引自然会随之而来。