Архитектура индексирования для часто обновляемого индекса solr?

У меня есть примерно 50 миллионов документов, 90 (сохраненных (20) + несохраненных (70)) полей в schema.xml, проиндексированных в одном ядре. Запросы довольно сложны, наряду с огранкой и выделением. Из этих 90 полей есть 3-4 поля (все сохранены), которые очень часто загружаются. Теперь обновление этих полей обычно требует повторного заполнения всех полей, что является сложной задачей. Если я использую атомарное/частичное обновление, нам нужно снова обновить несохраненные поля.

Наше решение. Чтобы преодолеть описанные выше проблемы, мы решили использовать запросы SolrCloud и Join. Мы разделяем индекс на два отдельных индекса/коллекции, т.е. один для сохраненных полей и один для несохраненных полей. Отношение ч/б документов является идентификатором документа. Мы сохранили часто обновляемые поля в сохраненном файле index. Сделав это, мы смогли использовать атомарные обновления. Кроме того, чтобы преодолеть ограничение запросов на соединение в облаке, мы разделили и реплицировали сохраненные поля на все узлы, но несохраненные поля не были разделены, а реплицированы на все узлы. У нас есть кластер из 5 узлов с дополнительными 3 экземплярами zookeeper. Учитывая количество документов, единственная проблема заключается в том, что запросы на соединение в конечном итоге снизят производительность поиска? Если да, то какие еще варианты я могу рассмотреть.


person ak1234    schedule 11.01.2018    source источник
comment
Просматривали ли вы обновления на месте, которые доступны с docvalues ​​и последними версиями Solr?   -  person MatsLindh    schedule 12.01.2018
comment
Невозможно использовать обновления на месте, так как для этого поля должны быть неиндексированными (indexed=false), не сохраняемыми (stored=false), однозначными (multiValued=false) . Если мы так поступим, это бесполезно   -  person ak1234    schedule 12.01.2018
comment
Если вам нужно выполнить поиск по полям (т. е. вы хотите, чтобы они были проиндексированы), то нет, вы не можете использовать обновления на месте. Часть stored будет извлечена из docValues, если вам нужно фактическое значение (поскольку Lucene может использовать docValues ​​в качестве сохраненного значения). Требование существует, поскольку обновления на месте не могут обновлять сохраненные данные в старой структуре.   -  person MatsLindh    schedule 12.01.2018


Ответы (1)


Размышление о объединениях делает Solr более похожим на реляционную базу данных. Я нашел статью об этом от команды Lucidworks Solr and Joins. Даже они говорят, что если ваше решение включает использование Join, значит, вам нужно переосмыслить это.

Думаю, у меня есть решение для вас, ребята. Прежде всего, забудьте о двух коллекциях. Вы создаете одну коллекцию, и у вас будет два документа Solr для каждого отдельного документа. Теперь в одном документе будут сохраненные поля, а в другом — несохраненные поля. Во время обновления вы обновите документ, в котором сохранено поле, и выполните операцию, связанную с поиском, в другом документе.

Теперь все, что вам нужно сделать, это во время запроса вам нужно объединить оба документа в один документ, что можно сделать, написав сервисный слой поверх Solr.

person Sanjay Dutt    schedule 11.01.2018