ReplicationHandler分布和优化

优化索引不是大多数用户通常应该担心的事情 - 但是在使用 ReplicationHandler 时，用户应该意识到优化索引的影响。

优化主索引所需的时间可能会有很大的变化。一个小的索引可能会在几分钟内优化。一个非常大的索引可能需要几小时。这些变量包括索引的大小和硬件的速度。

分布一个新优化的索引可能只需要几分钟或长达一个小时或更长的时间，同样取决于索引的大小以及网络连接和磁盘的性能。在优化过程中，机器处于负载状态，不能很好地处理查询。如果更新的时间表被驱动到slave服务器每小时几次，我们无法针对每个提交的快照运行优化。

复制一个优化的索引意味着整个索引需要在下一个时间传输snappull。这是一个很大的开支，但并不像运行优化那样无处不在。

请考虑下面的例子：在 three-slave one-master配置上，分布新优化的索引需要大约80秒的总计。跨层滚动更改需要每台机器（或机器组）大约十分钟。如果这个优化是通过查询层进行的，并且如果每个正在优化的slave节点都被禁用并且没有收到查询，则首次部署将需要至少二十分钟，并且可能长达一个半小时。此外，这些文件需要同步，以便下面的优化，snappull不会认为独立优化的文件在任何方面都是不同的。这也会让独立的索引受到破坏，而不是每个都完美的副本。

对master设备进行优化可以实现简单的优化操作。没有查询的slave需要停止服务。当查询正常服务时，优化的索引可以在后台分配。优化可以随时发生，方便提供索引更新的应用程序。

虽然优化在某些情况下可能会有一些好处，但快速变化的指数不会长期保留这些好处，而且由于优化是一个密集的过程，因此考虑其他选择可能会更好，如降低合并因子（在索引配置部分有介绍）。