Когда нужно использовать SOLR над Lucene в сборке Sitecore 7?

У моего клиента нет бюджета для настройки и поддержки сервера SOLR для использования в производственной среде. Если я правильно понимаю API Sitecore 7 Content Search API, то не нужно настраивать вещи вместо Lucene. По большей части конфигурация будет схожей, и код будет таким же, и сервер SOLR может быть заменен позже.

У сайта есть

  • факсированная страница поиска
  • перечисление компонентов при посадке и на других страницах, которые будут использовать API поиска контента
  • ведра с пользовательскими гранями

На сайте имеется около 5000 страниц и компонентов, не содержащих элементы медиабиблиотеки. Есть ли проблемы с простотой использования Lucene?

Основной вопрос: когда, во время вашей архитектуры или этапа проектирования, вы знаете, что вам обязательно нужно выбрать SOLR над Lucene? Каковы основные признаки того, что вы рекомендуете это?

ОТВЕТЫ

Ответ 1

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

В сценарии Sitecore я бы начал рассматривать Solr, если:

  • Вам нужно индексировать большое количество элементов - скажем, 50 тыс. вверх - Lucene довольна этими типами чисел, но Solr улучшила кеширование запросов и предназначено для этих больших количеств элементов.
  • Устойчивость уровня поиска имеет максимальное значение для бизнеса (т.е. сайт основан исключительно на поиске). Solr предоставляет более надежную систему репликации/ошпаривания и восстановления после сбоев с помощью SolrCloud.
  • Важным является повторное назначение уровня поиска в другом приложении (не Sitecore). Solr - это приложение поиска, доступ к которому осуществляется через HTTP с помощью XML/JSON и т.д., что упрощает интеграцию с внешними системами.
  • Вам нужна определенная дополнительная особенность Solr, которой нет у Lucene.

.. но как вы говорите, если вы хотите поменять Lucene для Solr на более позднем этапе, мы упорно трудились, чтобы убедиться, что этот процесс как можно более простым. Стоит отметить несколько моментов:

  • В то время как ваши запросы LINQ останутся прежними, ваша конфигурация будет немного отличаться и потребуется внимание на порт.
  • Понимание того, как Solr работает как приложение, и как работает схема, важно знать, но есть отличные книги и богатые знания.
  • Solr имеет несколько отличающиеся (более новые) анализаторы и механизмы подсчета очков, поэтому ваши результаты поиска могут быть немного разными (иногда клиенты могут быть встревожены этим: P)

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

Ответ 2

Стивен в значительной степени затронул вопрос, но я просто хотел добавить еще один сценарий. Необходимо учитывать настройку сервера в рабочей среде. Если вы собираетесь использовать несколько серверов доставки контента за балансировщиком нагрузки, я бы подумал о Solr с самого начала, пытаясь убедиться, что индекс Lucene на каждом сервере доставки синхронизирован. 100% времени может быть болезненным.

Ответ 3

Я бы рекомендовал планировать план спасения от Lucene, когда вы начинаете думать о нескольких компакт-дисках, и вот почему:

A) Каждый сервер должен поддерживать свою собственную индексную копию:

  • Любой неожиданный перезапуск может привести к тому, что несколько документов не будут добавлены в индекс в одном поле, что делает индексы отличными от сервера к серверу. Это приведет к тому, что на другой странице будут отображаться разные страницы.
  • Каждый сервер должен обновлять индексы - использовать процессор и дисковое пространство; скорость ответа снижается после завершения операции публикации =/
  • В соответствии с руководством по безопасности на компакт-дисках должен быть удален интерфейс Sitecore Shell, поэтому индекс не может быть легко перестроен из панели управления =\

B) Lucene не предназначен для больших объемов контента. Каждая операция поиска выполняется примерно следующим образом:

  • Создайте массив с размером, равным общему количеству документов в индексе
  • Если документ соответствует поиску, установите флаг в массиве

В то время как это работает как прелесть для индексов малого размера (~ 10K элементов), огромная деградация производительности возникает после увеличения объема контента.

Выделенный массив заканчивается Large Object Heap, который по умолчанию не уплотняется, тем самым быстро фрагментируется.

Сценарий:

  • Выполните поиск документов 100K → массив, созданный в памяти

  • Выполните еще один поиск в другом потоке → создайте еще один огромный массив

  • Обновить индекс → теперь 100K + 10 документов

  • Первая операция была завершена; LOH имеет пространство для массива 100K.

  • Повторить попытку снова → 100K + 10 массив должен быть создан; освобожденная "дыра" памяти недостаточно велика, поэтому требуется больше ОЗУ.

  • Процесс w3wp.exe продолжает потреблять все больше ОЗУ.

Это обычный случай для агрегирования Google Analytics, поскольку индекс заполняется сразу несколькими потоками. Через некоторое время на экземпляре обработки вы увидите много оперативной памяти.

C) Последний выпуск Lucene.NET был выполнен 5 лет назад.

В то время как SOLR активно развивается.

Чем раньше вы переключитесь на SOLR, тем проще будет.