Solr запрашивает тайм-аут при обновлении индекса. Возможно репликация возможное решение?

Question

Мы запускаем установку Solr (все в стандартной среде Jetty, просто добавили некоторые поля в схему).

Индекс составляет около 80 тыс. Документов среднего размера (вероятно, 20 полей по 100 символов в каждом).

Проблема заключается в том, что время от времени некоторые запросы прерываются.Ну, они не тайм-аут на стороне сервера, но они занимают более 10 секунд, то есть, когда наше приложение считает это как тайм-аут.Это очень простые запросы, которые обычно не занимают более 80 мс или около того.

Кажется, это коррелирует с перестройкой индекса (мы собираем информацию из базы данных и постоянно обновляем индекс в виде кусков 200 документов).Под постоянным я подразумеваю при необходимости, если нет документов для обновления, задание индексации отправляется в спящий режим.Я бы оценил, что каждые 15-20 минут происходит коммит.

Я читаю solr faqs и прочее, и кажется, что это общая проблема, однако я не нашел решения, ноувеличить время ожидания.

Но запрос сайта, который занимает> 10 секунд, является неприемлемым.

Как я могу решить эту проблему?Я думал об использовании одного installatino для индексации и репликации его на другой, который используется для запросов.Но решит ли это эту проблему?

У вас есть идеи по этому поводу?

Answer 1

Вы в основном на правильном пути. Одним из способов решения этой проблемы является использование второго ядра для обновлений, а затем, когда эта секунда полностью обновляется и фиксируется, вы SWAP обращаетесь к первому ядру и делаете его активным.

Я думаю, что этот подход более подробно описан в книге " Solr 1.4 Enterprise Search Server " (вот фрагмент )

Answer 2

Единственная причина, по которой я могу думать, что поисковик будет медленным, это если он перестраивает свои кеши.Вы подогреваете своих искателей полезными запросами?

Мое мышление ...

Обновления сами по себе не будут блокировать чтение или запись.Коммит блокирует записи, поскольку он очищает писателя, но не читает.Одно обновление сбрасывается, новый поисковик затем инициализируется, нагревается, а затем заменяется на место старого поисковика.

Если в этот момент ваши поиски истекают, возможно, ваши первые несколько горстейзапросы сильно связаны с вводом-выводом при разогреве кэшей, от которых зависит последующий поиск.Поэтому мне интересно, если ваши поисковики нагреваются с полезными запросами.

Для обсуждения, вот пример newSearcher согревающего запроса, присутствующего в большинстве файлов по умолчанию ish solrconfig.xml:

<listener event="newSearcher" class="solr.QuerySenderListener">
  <arr name="queries">
    <lst>
      <str name="q">solr</str>
      <str name="start">0</str>
      <str name="rows">10</str>
    </lst>
    <lst>
      <str name="q">rocks</str>
      <str name="start">0</str>
      <str name="rows">10</str>
    </lst>
  </arr>
</listener>

Возможно, вы все еще используете это?:)

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

Answer 3

Если вы видите его только изредка, а количество документов продолжает расти, вы, вероятно, достигнете предела слияния.Слияние ужасно дорого, так как старые сегменты превращаются в новые сегменты, и все ваши кеши загружаются.

Вы определенно хотите выполнить настройку master / slave, SWAP (как показано выше) и т. Д., Чтобы сгладить неровности.