Индекс должен быть оптимизирован после возрастающих индексов в Lucene?
Ваш объект JSON имеет неверный формат. Это должно выглядеть следующим образом:
{
"TC":{
"test_case":"ITCFScenario12",
"data_type":"testcomplete"
},
"3":{
"scenariodescription":"Create Client"
},
"7":{
"scenariodescription":"CreateServicePlan"
}
}
Используйте любые онлайн-инструменты для проверки объекта JSON. Чтобы проверить это в правильном формате или нет. https://jsonformatter.org/ Так что, если вы получаете его из внешнего интерфейса, это нужно исправить.
После того, как его в правильном формате, платформа Newtonsoft JSON может использоваться для всех других операций.
2 ответа
Циновка, так как у Вас, кажется, есть хорошая идея, сколько времени Ваш текущий процесс берет, я предлагаю, чтобы Вы удалили optimize() и измерили влияние.
многие документы изменяются в тех 2-часовых окнах? Если только небольшая часть (50,000/700,000 приблизительно 7%) инкрементно повторно индексируется, то я не думаю, что Вы вытаскиваете много значения из optimize().
Некоторые идеи:
- не делают возрастающего
optimize()вообще. Мой опыт говорит, что Вы не видите огромное улучшение запроса так или иначе. - Делают
optimize()ежедневно вместо 2-почасового. - Делают
optimize()в течение времен низкого объема (который является тем, что javadoc говорит).
И удостоверяются, что Вы проводите измерения. Эти виды изменений могут быть выстрелом в темноте без них.
optimize операция читает и пишет весь индекс, который является, почему это - так интенсивный IO!
идея позади оптимизирует операции, должен повторно объединить все различные сегменты в индексе Lucene в один единственный сегмент, который может значительно уменьшить времена запроса, поскольку Вы не должны открывать и искать несколько файлов на запрос. При использовании нормальной структуры индексного файла Lucene (а не объединенная структура), Вы получаете новый сегмент на операцию фиксации; то же как Ваши переиндексы я принимаю?
я думаю , Matt имеет большой совет, и я был бы второй все, что он говорит - управляться по условию Вы имеете. Я на самом деле пошел бы шаг вперед и только optmize a) когда Вы должны и b) когда у Вас есть низкий объем запроса.
, Поскольку производительность запросов глубоко связывается с количеством сегментов в Вашем индексе, простым ls -1 index/segments_* | count мог быть полезный индикатор для того, когда в оптимизации действительно необходим.
, С другой стороны, отслеживание производительности запросов и объема и начинания оптимизирование при достижении недопустимой низкой эффективности с приемлемо низким объемом, было бы более хорошим решением.