Информация о TieredMergePolicy

Question

Я хотел бы хорошо понимать поведение слияния 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- В официальной документации, есть один метод, который называется setExpu ngeDeletesPctAllowed (двойной v). И в Solr 4.3.0 я проверил в классе TieredMergePolicy, и я не нашел этот метод. Существует еще один метод, похожий на этот: setForceMergeDeletesPctAllowed (double v). Существуют ли различия между обоими методами?

2- Оба метода выше называются только при использовании ExpungeDelete и оптимизации или вызываются при нормальном слиянии.

3- Я прочитал, что слияния между сегментами выполняются в соответствии с пропорциональным процентом удаленных документов на сегменте. По умолчанию этот процент установлен на 10%. Можно ли установить это значение на 0%, чтобы убедиться, что после объединения нет более удаленных документов в индексе?

Мне нужно уменьшить размер моего индекса без метода optimize() вызова, если это возможно. Вот почему любая информация о процессе слияния была бы интересной для меня.

Спасибо,

Answer 1

похоже, что вы смешиваете свою документацию. Если вы используете Lucene 4.3.0, используйте для этого документацию (см. Правильную документацию для TieredMergePolicy в 4.3.0), а не версию 3.2.0.

Во всяком случае, на эти конкретные вопросы: See #Lucene-3577

1 - Кажется, в основном, необходимо изменить название, для всех намерений и целей.

2 - Во-первых, IndexWriter.expungeDeletes больше не существует в 4.3.0. Вы можете использовать IndexWriter.forceMergeDeletes(), если хотите, хотя это настоятельно рекомендуется, так как это очень, очень дорого. Я считаю, что это повлияет только на вызов ForceMergeDeletes(). Если вы хотите одобрить удаление исправлений, установите это в MergePolicy, используя: TieredMergePolicy.setReclaimDeletesWeight

3 - Процент разрешен прямо здесь, в вызове метода, указанном в первом вопросе. Принудительное удаление всех исключений при вызове ForceMergeDeletes() послужит еще более дорогостоящей операции, которая намного дороже.

Чтобы рискнуть предположить, если вам нужно сэкономить место на диске, сделанное вашим индексом, у вас, скорее всего, будет гораздо больше успеха, более пристально глядя на то, сколько данных у вас есть , сохраняя в индексе. Недостаточно информации, чтобы сказать наверняка, конечно, но представляется вероятным решением.