Как solr работает с данными, разделенными на разные сервисы и, следовательно, не синхронно доступными? - PullRequest
0 голосов
/ 24 марта 2012

возьмите, например, интернет-магазин с каталогом и ценовыми данными в различных веб-сервисах. Теперь мы знаем, что solr не разрешает частичное обновление поля документа ( ошибка JIRA ), так как вы индексируете эти две службы? У меня было три варианта, но я не уверен, какой из них правильный:

  1. Частичное обновление - невозможно
  2. Solr join - иметь цену и каталог в отдельном индексе и объединять их в solr . Вы не можете присоединить их к своему клиентскому коду, не путая нумерацию страниц и количество фасетов. Я не знаю, возможно ли это в pre-solr 4.0

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

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

Из всех этих методов только # 3.2 выглядит жизнеспособным для меня - кто-нибудь знает, как вы делаете такие вещи с DIH? Потому что теперь у вас есть две разные точки входа (2 разных веб-сервиса) для индексации, и каждая должна проверить другую

Ответы [ 2 ]

0 голосов
/ 29 марта 2012

Подход 3.2 является наиболее распространенным, хотя я думаю об этом немного по-другому. Сначала подумайте, что вам нужно в результатах поиска, а затем создайте один документ Solr для каждого потенциального результата, содержащий как можно больше информации. Если все в порядке с отсутствующей ценой, добавьте документ таким образом.

Возможно, вы также захотите сопоставить документы в Solr, но получите последние данные для отображения из веб-сервисов. Это дает свежие результаты и позволяет избежать перекоса между пакетным обновлением Solr и оперативными данными.

Не задерживайте дыхание, чтобы добавить мелкие обновления в Solr и Lucene. Он получает большую часть своей скорости от отсутствия блокировки и обновления на уровне записи.

0 голосов
/ 26 марта 2012

Обычный способ решить эту проблему близок к вашему 3.2: написать код, который создает документ, который вы хотите проиндексировать, из различных доступных сервисов.Обычный процесс - выборка всех товаров из каталога, а затем выборка цен при индексации.Независимо от того, хотите ли вы, чтобы в поиске по каталогу были товары, цены на которые отсутствуют, зависит от ваших бизнес-правил обслуживания.Если вы хотите ускорить процесс (получить продукт, получить цену, повторить), разверните API, чтобы получить 1000 продуктов, а затем цены на все продукты одновременно.

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

Насколько я помню, 4.0, вероятно, будет поддерживать частичные обновления, поскольку он перемещается на новый уровень абстракции для индексафайлы, хотя я не уверен, что это сделает вашу ситуацию намного более гибкой.

...