SOLR autoCommit против autoSoftCommit

Ответ 1

У вас openSearcher = false для жестких коммитов. Это означает, что, хотя совершение произошло, поисковик не был перезапущен и не видит изменений. Попробуйте изменить этот параметр, и вам не понадобится мягкая фиксация.

SoftCommit снова открывает поисковик. Поэтому, если у вас есть оба раздела, soft commit показывает новые изменения (даже если они не жестко привязаны) и - как сконфигурировано - жесткая фиксация сохраняет их на диск, но не меняет видимость.

Это позволяет помещать мягкую фиксацию в 1 секунду и быстро обнаруживать документы, а жесткие фиксации выполняются реже.

Ответ 2

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

Я всегда содрогаюсь, потому что в некоторых случаях любая рекомендация будет неправильной. Моей первой рекомендацией было бы не задумываться над проблемой. Некоторые очень умные люди пытались сделать весь процесс устойчивым. Сначала попробуйте простые вещи и только подправьте их по мере необходимости. В частности, обратите внимание на размер журналов транзакций и настройте интервалы жесткой фиксации, чтобы сохранить их "разумным размером". Помните, что наказание в основном зависит от времени воспроизведения, если вы перезапускаетесь после сбоя JVM. 15 секунд терпимо? Зачем тогда меньше?

Мы видели ситуации, когда интервал жесткого фиксирования намного короче интервала мягкого принятия, см. бит массовой индексации ниже.

Это места для начала.

ТЯЖЕЛЫЙ (БОЛЬШОЙ) ИНДЕКСНЫЙ

Здесь предполагается, что вы заинтересованы в том, чтобы как можно скорее в будущем получить как можно больше данных для индексации для поиска. Я думаю, оригинальные нагрузки источника данных и т.д.

Установите свой интервал мягкого коммита довольно долго. Как через 10 минут. Мягкая фиксация связана с видимостью, и я предполагаю, что массовая индексация не относится к поиску почти в реальном времени, поэтому не выполняйте дополнительную работу по открытию любого типа поисковика. Установите интервалы жесткой фиксации на 15 секунд, openSearcher = false. Опять же, предполагается, что вы будете просто обрабатывать данные в Solr. В худшем случае вы перезагружаете свою систему и должны воспроизвести примерно 15 секунд данных из вашего журнала. Если ваша система подпрыгивает вверх и вниз чаще, сначала исправьте причину. Только после того, как вы попробовали простые вещи, вы должны подумать об уточнениях, они обычно требуются только в необычных обстоятельствах Но они включают в себя: Полное отключение журнала для операции массовой загрузки Индексирование в автономном режиме с помощью какого-либо процесса сокращения карты Только наличие лидера на осколок, никаких реплик для загрузки, затем последующее включение реплик и разрешение им выполнять репликацию старого стиля, чтобы наверстать упущенное. Обратите внимание, что это автоматически, если узел обнаруживает, что он "слишком далеко" не синхронизирован с лидером, он запускает репликацию старого стиля. После того, как он догонит, он получит документы, которые были проиндексированы для лидера, и будет вести собственный журнал. и т.д.

INDEX-HEAVY, QUERY-LIGHT

Я имею в виду, скажем, поиск файлов журналов. Это тот случай, когда в систему поступает много данных почти все время. Но загрузка запроса довольно легкая, часто для устранения неполадок или анализа использования.

Установите интервал мягкого принятия достаточно большим, вплоть до максимальной задержки, которую вы можете выставить для отображения документов. Это может занять пару минут или намного дольше. Может быть, даже часы с возможностью выполнения жесткого коммита (openSearcher = true) или мягкого коммита по требованию. Установите жесткую фиксацию на 15 секунд, openSearcher = false

INDEX-LIGHT, QUERY-LIGHT OR HEAVY

Это относительно статический индекс, который иногда получает небольшой всплеск индексации. Скажем, каждые 5-10 минут (или дольше) вы делаете обновление

Если функциональность NRT не требуется, в этой ситуации я бы пропустил мягкие коммиты и делал бы жесткие коммиты каждые 5-10 минут с openSearcher = true. Это ситуация, в которой, если вы индексируете с помощью одного внешнего процесса индексации, может иметь смысл заставить клиента выполнить жесткую фиксацию.

INDEX-HEAVY, QUERY-HEAVY

Это случай, близкий к реальному времени (NRT), и он действительно самый хитрый из всех. Это потребует экспериментов, но здесь, где Id начать

Установите интервал мягкого коммита на столько, сколько вы можете стоять. Не слушайте своего менеджера по продукту, который говорит: "нам нужно время ожидания не более 1 секунды". В самом деле. Оттолкнись назад и посмотри, лучше ли обслужен пользователь или даже заметит. Мягкие коммиты и NRT довольно удивительны, но они не бесплатны. Установите интервал жесткой фиксации на 15 секунд.

В моем случае (индекс тяжелый, запрос большой) ведущий-ведомый репликации занимал слишком много времени, замедляя передачу запросов ведомому. При увеличении softCommit до 15 минут и увеличении hardCommit до 1 минуты улучшение производительности было значительным. Теперь репликация работает без проблем, и серверы могут обрабатывать гораздо больше запросов в секунду.

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

Ответ 3

Мягкие фиксации касаются видимости. жесткие фиксации - это прочность. оптимизация - это производительность.

Мягкие коммиты очень быстрые, изменения видны, но эти изменения не сохраняются (они только в памяти). Таким образом, во время сбоя эти изменения могут быть последними. Изменения жестких коммитов сохраняются на диске.
Оптимизация похожа на жесткую фиксацию, но она также объединяет сегменты индекса solr в один сегмент для повышения производительности. Но это очень дорого.

Операция фиксации (жесткая фиксация) делает изменения индекса видимыми для новых поисковых запросов. Жесткая фиксация использует транзакцию log, чтобы получить идентификатор последних изменений документа, а также вызывает fsync в файлах индекса, чтобы убедиться, что они были сброшены в стабильное хранилище, и никакая потеря данных не возникла бы из-за сбоя питания.

Мягкая фиксация выполняется намного быстрее, поскольку она только делает изменения индекса видимыми и не индексирует файлы fsync или записывает новый индексный дескриптор. Если JVM падает или происходит потеря мощности, изменения, которые произошли после последнего жесткого фиксация будет потеряна. Поиск коллекций, имеющих требования NRT (которые хотят быстро изменить индекс видимый для поиска) будет часто требовать мягкую фиксацию, но жесткое принятие реже. SoftCommit может быть "меньше дорогостоящим "с точки зрения времени, но не бесплатным, поскольку он может замедлять пропускную способность.

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

auto commit properties we can manage from sorlconfig.xml files.
<autoCommit>
       <maxTime>1000</maxTime>
  </autoCommit>


    <!-- SoftAutoCommit

         Perform a 'soft' commit automatically under certain conditions.
         This commit avoids ensuring that data is synched to disk.

         maxDocs - Maximum number of documents to add since the last
                   soft commit before automaticly triggering a new soft commit.

         maxTime - Maximum amount of time in ms that is allowed to pass
                   since a document was added before automaticly
                   triggering a new soft commit.
      -->

     <autoSoftCommit>
       <maxTime>1000</maxTime>
     </autoSoftCommit>

Литература:

https://wiki.apache.org/solr/SolrConfigXml

https://lucene.apache.org/solr/guide/6_6/index.html