Репликация SolrCloud и Solr master-slave

На этой неделе у меня возникла проблема с индексом Solr: http://lucene.472066.n3.nabble.com/corrupted-index-in-slave-td4054769.html,

Сегодня эта ошибка начала происходить постоянно почти для каждого запроса, и я создал проблему JIRA, потому что думал, что это ошибка https://issues.apache.org/jira/browse/SOLR-4707

Как вы можете прочитать, в конце концов это произошло из-за сбоя в репликации Solr master-slave, и теперь я не знаю, стоит ли нам думать о переходе на SolrCloud, поскольку репликации Solr master-slave, похоже, не подходят для нашей требования:

  • размер индекса: ~20 миллионов документов, ~9 ГБ
  • ~1200 обновлений/мин
  • ~10000 запросов/мин (распределено по 2 ведомым устройствам) MoreLikeThis, RealTimeGet, TermVectorComponent, SearchHandler

Буду признателен, если кто-нибудь поможет мне ответить на следующие вопросы:

  • Было бы целесообразно перейти на SolrCloud? Повлияет ли это на производительность репликации?
  • В таком случае, что будет иметь лучшую производительность? поддерживать копию индекса на каждом сервере или использовать серверы сегментов?
  • Сколько сегментов и реплик вы бы посоветовали для обеспечения высокой доступности?

С уважением,

Виктор


solr solrcloud
person vruizext    schedule 12.04.2013    source источник
comment
Если бы вы могли немного подождать, Solr 5 выйдет в течение следующего года, и в нем есть множество положительных изменений, которые еще больше поддерживают SolrCloud. Поддержка IMO 4.x для SolrCloud требует дальнейшего обслуживания, поэтому, если вы можете подождать, я бы просто подождал. Также решение о том, как осколки отстой.   -  person Xinzz    schedule 10.12.2013
comment
Я решил проблему благодаря этой статье searchhub.org/2013/08/23/ прочитав его, я понял, что время мягкого коммита было неправильно сконфигурировано в соответствии с нашими требованиями (индекс-тяжелый, запрос-тяжелый), у нас было слишком много мягких коммитов, но нам не нужно было, чтобы данные были доступны в режиме реального времени. Поэтому, как следует из статьи, я попытался установить интервал мягкого коммита достаточно большим, а для жесткого коммита — небольшим значением, в моем случае 15 секунд.   -  person vruizext    schedule 24.02.2014
comment
Кроме того, оптимизация процесса индексации путем отправки сообщений с массовыми обновлениями, содержащих несколько элементов, вместо отправки одного запроса для каждого индексируемого элемента, а также выбор лучшей стратегии кэширования результатов запросов помогли снизить нагрузку на серверы solr и улучшить общее качество. предоставляемых услуг   -  person vruizext    schedule 24.02.2014

Ответы (1)


arrow_upward
3
arrow_downward

Что ж, ответ на все ваши вопросы зависит от того, что именно вы хотите от solrcloud.

  • Да, было бы целесообразно перейти на solrcloud, поскольку он обеспечивает высокую доступность, масштабируемость и поиск почти в реальном времени, а также автоматическую горячую репликацию. Но эти функции достигаются за счет небольшого снижения производительности (вы хотите даже в хорошо сконфигурированном кластере).
  • Я бы посоветовал вам использовать общую конфигурацию, чтобы позволить solr поддерживать данные индекса для вас (я уверен, что вы вызовете улыбку у сотрудников TechOps, если сделаете это). Это также уменьшит человеческие ошибки и потребность в ресурсах.
  • Ответ на ваш последний вопрос полностью зависит от вашего облачного развертывания. Вам следует попробовать конфигурацию с 2 сегментами и 2 репликами, а затем создать тестовое развертывание, чтобы убедиться, что оно соответствует вашим потребностям. Если нет, попробуйте разные комбинации числа сегментов и реплик, пока не получите то, что ты хочешь (я знаю его боль!).

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

person Community    schedule 28.10.2013