Как Lucene / Solr достигает высокой производительности в многопольном / граненом поиске? - PullRequest
Новая
       17

Как Lucene / Solr достигает высокой производительности в многопольном / граненом поиске?

9 голосов
/ 05 апреля 2011

Context

Это вопрос в основном о внутренностях Lucene (или, возможно, Solr). Основная тема - фасетный поиск , в котором поиск может происходить по нескольким независимым измерениям (граням) объектов (например, размер, скорость, цена автомобиля).

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

Solr рекламируется для того, чтобы хорошо справляться с граненым заданием поиска, которое, если я считаю правильным, должно быть связано с Lucene (предположительно), хорошо работающим с многопольными запросами (где поля документа связаны с фасетами объекта).

Вопрос

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

Следовательно, в Lucene предположительно имеется несколько продвинутых методов для многополевых запросов, помимо простого пересечения совпадающих документов на основе инвертированного индекса.

Итак, вопрос в том, что это за техника / трюк? В более широком смысле: почему Lucene / Solr теоретически могут добиться более высокой производительности поиска с гранями, чем RDBMS (если да)?

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

Ответы [ 2 ]

6 голосов
/ 06 апреля 2011

Огранка

Существует два ответа для огранки, потому что существует два типа огранки.Я не уверен, что любой из них быстрее, чем СУБД.

  1. Перечисление огранки.Результатом запроса является битовый вектор, в котором i-й бит равен 1, если i-й документ был совпадением.Фасет также является битовым вектором, поэтому пересечение является просто побитовым AND.Я не думаю, что это новый подход, и большинство СУБД, вероятно, поддерживают его.

  2. Field Cache.Это просто нормальный (неинвертированный) индекс.Запрос в стиле SQL, который здесь выполняется, выглядит следующим образом:

    выберите фасет, count (*) из поля field_cache, где docId в группе query_results по фасету

Опять я нене думаю, что это то, что обычные RDBMS не могут сделать.Индекс представляет собой список пропусков с ключом docId.

Многоплановый поиск

Именно здесь сияет Lucene.Почему подход Люсена так хорош, слишком долго, чтобы публиковать здесь, но я могу порекомендовать этот пост по Lucene Performance или по ссылкам в нем.

3 голосов
/ 07 апреля 2011

Объясняющий пост можно найти по адресу: http://yonik.wordpress.com/2008/11/25/solr-faceted-search-performance-improvements/

Новый метод работает путем неинвертирования индексируемого поля для огранки, что позволяет быстро найти термины в поле для любогодокумент.Это на самом деле гибридный подход - для экономии памяти и увеличения скорости, термины, которые встречаются во многих документах (более 5%), не являются неинвертированными, вместо этого для подсчета используется традиционная логика пересечения наборов.

...