Я всегда содрогаюсь от этого, потому что любая рекомендация в некоторых случаях будет ошибочной. Моя первая рекомендация будет заключаться в том, чтобы не думать о проблеме слишком много. Некоторые очень умные люди попытались сделать весь процесс надежным. Сначала попробуйте простые вещи и настраивайте их только по мере необходимости. В частности, посмотрите на размер ваших журналов транзакций и настройте интервалы жесткой фиксации, чтобы они были «разумного размера». Помните, что штраф в основном связан с временем воспроизведения, если вы перезапустите после сбоя JVM. 15 секунд допустимо? Зачем тогда меньше?
Мы видели ситуации, в которых интервал жесткой фиксации намного короче, чем интервал мягкой фиксации, см. бит массовой индексации ниже.
Это места для начала.
ТЯЖЕЛАЯ (ОБЪЕМНАЯ) ИНДЕКСАЦИЯ
Здесь предполагается, что вы заинтересованы в том, чтобы как можно быстрее получить в индекс как можно больше данных для поиска в будущем. Я имею в виду оригинальные загрузки источника данных и т. д.
Установите достаточно длинный интервал мягкого коммита. Как за 10 минут. Мягкая фиксация связана с видимостью, и я предполагаю, что массовая индексация не связана с поиском почти в реальном времени, поэтому не выполняйте дополнительную работу по открытию какого-либо поисковика. Установите интервалы жестких коммитов на 15 секунд, openSearcher=false. Опять же, предполагается, что вы собираетесь просто передавать данные в Solr. В худшем случае вы перезагружаете свою систему и вам приходится воспроизводить примерно 15 секунд данных из вашего tlog. Если ваша система подпрыгивает вверх и вниз чаще, чем это, сначала устраните причину этого. Только после того, как вы попробуете простые вещи, вы можете подумать об уточнениях, обычно они требуются только в необычных обстоятельствах. Но они включают в себя: полное отключение tlog для операции массовой загрузки; индексирование в автономном режиме с помощью какого-либо процесса уменьшения карты; наличие только лидера на сегмент, отсутствие реплик для загрузки, затем включение реплик позже и предоставление им возможности работать в старом стиле. репликация, чтобы наверстать упущенное. Обратите внимание, что это происходит автоматически, если узел обнаруживает, что он «слишком далеко» от синхронизации с лидером, он инициирует репликацию в старом стиле. После того, как он догонит, он получит документы по мере их индексации до лидера и сохранит свой собственный tlog. и т.п.
ИНДЕКС-ТЯЖЕЛЫЙ, ЗАПРОС-ЛЕГКИЙ
Под этим я подразумеваю, скажем, поиск лог-файлов. Это тот случай, когда в систему постоянно поступает много данных. Но нагрузка запросов довольно невелика, часто для устранения неполадок или анализа использования.
Установите достаточно длинный интервал мягкой фиксации, вплоть до максимальной задержки, которую вы можете выдержать, чтобы документы были видны. Это может быть всего пара минут или намного дольше. Возможно, даже часы с возможностью выдачи жесткой фиксации (openSearcher=true) или мягкой фиксации по требованию. Установите жесткую фиксацию на 15 секунд, openSearcher=false
ИНДЕКС-ЛЕГКИЙ, ЗАПРОС-ЛЕГКИЙ ИЛИ ТЯЖЕЛЫЙ
Это относительно статичный индекс, который иногда получает небольшой всплеск индексации. Скажем, каждые 5-10 минут (или дольше) вы делаете обновление
Если не требуется функциональность NRT, я бы пропустил мягкие коммиты в этой ситуации и делал бы жесткие коммиты каждые 5-10 минут с openSearcher=true. Это ситуация, в которой, если вы индексируете с помощью одного внешнего процесса индексации, может иметь смысл, чтобы клиент выполнил жесткую фиксацию.
ИНДЕКС-ТЯЖЕЛЫЙ, ЗАПРОС-ТЯЖЕЛЫЙ
Это случай ближнего реального времени (NRT), и он действительно самый сложный из всех. Это потребует экспериментов, но я бы начал с этого.
Установите интервал мягкого коммита до тех пор, пока вы можете стоять. Не слушайте вашего менеджера по продукту, который говорит: «Нам нужно не более 1 секунды задержки». Действительно. Сильно оттолкнитесь и посмотрите, будет ли пользователь лучше обслуживаться или даже заметит. Мягкие коммиты и NRT — это прекрасно, но они не бесплатны. Установите интервал жесткой фиксации на 15 секунд.
В моем случае (тяжелый индекс, тяжелый запрос) репликация master-slave занимала слишком много времени, замедляя выполнение запросов к ведомому. Увеличив softCommit до 15 минут и увеличив hardCommit до 1 минуты, производительность значительно улучшилась. Теперь репликация работает без проблем, а серверы могут обрабатывать гораздо больше запросов в секунду.
Однако это мой вариант использования, я понял, что мне действительно не нужно, чтобы элементы были доступны на главном сервере в режиме реального времени, поскольку мастер используется только для индексации элементов, а новые элементы доступны на подчиненных устройствах каждый цикл репликации (5 минут). ), что вполне нормально для моего случая. вы должны настроить эти параметры для вашего случая.
