У меня есть сайт для объявлений … У меня есть Solr, который выполняет поиск объявлений, а затем возвращает ID: nrs, которые затем я использую для ввода в массив. Затем я использую этот массив, чтобы найти любые объявления в базе данных MySql, где идентификатор: s соответствует ID: s в массиве, возвращаемом Solr.
Теперь, поскольку этот массив может быть очень большим (100 тыс. Записей или более), тогда мне нужно будет «отобразить» результаты, чтобы, возможно, 100, которые возвращались за раз. И затем используйте эти 100 ID: s в MySql, чтобы найти объявления.
Итак, можно ли использовать страницу SOLR?
И если да, то как? Мне нужен пример кода … И каковы будут результаты.
В основном мне нужен подробный пример!
благодаря
Взгляните на IBM . Может быть, это приведет вас к правильному курсу.
Количество результатов: Указывает максимальное количество возвращаемых результатов.
Начало: смещение для начала в результирующем наборе. Это полезно для разбивки на страницы.
Поэтому вы, вероятно, хотите
<str name="rows">10</str> <str name="start">0</str> Ваш solr-клиент должен предоставить некоторый способ получить общее количество результатов без особых проблем.
Пейджинг управляется параметрами start и rows , например:
?q=something&rows=10&start=20
даст вам 10 документов, начиная с документа 20.
О получении другой информации от MySQL вы сами. Я и другие люди уже предлагали вам хранить все в Solr, чтобы избежать дополнительных запросов к MySQL.
Вероятно, немного старый вопрос и много полезных ответов и рекомендаций, но я постараюсь обобщить результаты и описать решение для разбиения больших больших наборов данных с помощью курсора , bec. Недавно я столкнулся с этой проблемой.
Как упоминалось Yonik, проблема обычного start / rows заключается в том, что когда у нас есть большой набор данных, а start немного дальше ( намного дальше ), чем ноль, у нас есть хорошие накладные расходы с точки зрения эффективности и памяти. Это связано с тем, что выборка из 20 документов из «среднего» 500K записей + с использованием сортировки требует, по крайней мере, сортировки всего набора данных ( сортировка внутренних уникальных элементов ). Более того, если поиск будет распространен, он будет еще более ресурсоемким, bec. набор данных ( из 500 020 строк ) из каждого осколка должен быть возвращен в узел агрегатора для объединения, чтобы найти применимые 20 строк.
Solr не может вычислить, какой соответствующий документ является результатом 999001st в отсортированном порядке, без предварительного определения того, что первые 999000 сопоставимых результатов.
Решение здесь – использовать Solr cursorMark .
В первом запросе вы объявляете, что &cursorMark=* . Это означает следующее:
Вы можете думать, что это похоже на
start=0как способ сказать Solr « начать с начала моих отсортированных результатов », за исключением того, что он также сообщает Solr, что вы хотите использовать Курсор.
! Одно «оговорку» здесь заключается в том, что ваши предложения типа должны включать уникальное поле « Ключ» . Это может быть поле id если оно уникально.
Часть первого запроса будет выглядеть так:
?sort=price desc,id asc&start=0&cursorMark=* ...
В результате вы получите следующую структуру
{ "response":{"numFound":20,"start":0,"docs":[ /* docs here */ ]}, "nextCursorMark":"AoIIRPoAAFBX" // Here is cursor mark for next "page" }
Чтобы получить следующую страницу, следующий запрос будет выглядеть следующим образом:
?sort=price desc,id asc&start=0&cursorMark=AoIIRPoAAFBX ...
Обратите внимание на cursorMark из предыдущего ответа. И в результате вы получите следующую страницу результатов ( такую же структуру, как и первый ответ, но с другим значением nextCursorMarker ). И так далее …
Этот подход идеально подходит для бесконечной прокрутки прокрутки, но для его использования в классической разбивке на страницы есть некоторые вещи, о которых нужно думать :).
Вот некоторые справочные материалы, которые я нашел для решения этой проблемы, надеюсь, что это поможет кому-то сделать это.
Параметр «start» управляет смещением в результатах поиска, а параметр «rows» контролирует, сколько документов будет возвращено оттуда.
Если вы выполняете «глубокий пейджинг» (итерация по многим страницам), вы можете добиться гораздо большей производительности, используя курсор для повторения по набору результатов.
Я думаю, что стоит сказать, что solr возвращает вместе с текущей страницей результаты подсчета общего количества найденных записей.
Например, вызов:
http://192.168.0.1:8983/solr/select?qt=edismax&fl=*,score&qf=content^2%20metatag.description^3%20title^5%20metatag.keywords^10&q=something&start=20&rows=10&wt=xml&version=2.2
Ответ:
<response> <lst name="responseHeader"> <int name="status">0</int> <int name="QTime">1</int> <lst name="params"> <str name="fl">*,score</str> <str name="q">something</str> <str name="qf">content^2 metatag.description^3 title^5 metatag.keywords^10</str> <str name="qt">edismax</str> <str name="wt">xml</str> <str name="rows">10</str> <str name="version">2.2</str> </lst> </lst> <result name="response" numFound="1801" start="0" maxScore="0.15953878"> <doc>...</doc> <doc>...</doc> <doc>...</doc> ...
Используя solrj, запрос метода возвращает SolrDocumentList, который имеет метод: getNumFound ().