我想很好地理解Solr合并行为。我对不同的合并策略做了一些研究。似乎TieredMergePolicy比旧的合并策略（LogByteSizeMergePolicy等等）更好。这就是我使用这个的原因，这是最后一个solr版本的默认策略。
首先，我给你一些有趣的链接，我已阅读以更好地了解合并过程： http://java.dzone.com/news/merge-policy-internals-solr http://blog.mikemccandless.com/2011/02/visualizing-lucenes-segment-merges.html
根据Lucene的官方文档，我想问几个问题： http://lucene.apache.org/core/3_2_0/api/all/org/apache/lucene/index/TieredMergePolicy.html
问题的
1-在官方文档中，有一种方法叫做setExpungeDeletesPctAllowed（double v）。在Solr 4.3.0中，我已经检查了TieredMergePolicy类，但我没有找到这个方法。还有另一种看起来像这样的方法，叫做：setForceMergeDeletesPctAllowed（double v）。两种方法之间有什么区别吗？
2-上述两种方法是仅在执行ExpungeDelete和优化时调用，还是在正常合并时调用它们。
3-我已经读过，段之间的合并是根据段的已删除文档百分比按比例完成的。默认情况下，此百分比设置为10％。是否可以将此值设置为0％以确保合并后索引中没有更多已删除的文档？
如果可能，我需要在没有调用optimize（）方法的情况下减小索引的大小。这就是为什么关于合并过程的任何信息对我来说都很有趣。
由于
答案 0 :(得分：3)
您似乎正在混淆您的文档。如果您使用的是Lucene 4.3.0，请使用它的文档（请参阅4.3.0中的TieredMergePolicy的正确文档），而不是版本3.2.0。
无论如何，关于这些特定问题：See #Lucene-3577
1 - 似乎主要是必要的名称更改，用于所有意图和目的。
2 - 首先，4.3.0中不再存在IndexWriter.expungeDeletes。如果必须，您可以使用IndexWriter.forceMergeDeletes()，但强烈建议不要这样做，因为它非常非常昂贵。我相信这只会影响ForceMergeDeletes()电话。如果您想支持回收删除，请使用以下内容在MergePolicy中进行设置：TieredMergePolicy.setReclaimDeletesWeight
3 - 允许的百分比就在您在第一个问题中指出的方法调用中。在调用ForceMergeDeletes()时强制所有删除被合并将有助于使已经非常昂贵的操作变得更加昂贵。
只是冒险猜测，如果您需要节省索引占用的磁盘空间，您可能会更加成功地查看您在索引中存储的数据量。当然，没有足够的信息可以肯定地说，但似乎是可以考虑的解决方案。