Я всегда содрогаюсь, потому что в некоторых случаях любая рекомендация будет неправильной. Моей первой рекомендацией было бы не задумываться над проблемой. Некоторые очень умные люди пытались сделать весь процесс устойчивым. Сначала попробуйте простые вещи и только подправьте их по мере необходимости. В частности, обратите внимание на размер журналов транзакций и настройте интервалы жесткой фиксации, чтобы сохранить их "разумным размером". Помните, что наказание в основном зависит от времени воспроизведения, если вы перезапускаетесь после сбоя 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 минут), что вполне подходит для моего случая. Вы должны настроить эти параметры для вашего случая.
