Solr query - есть ли способ ограничить размер текстового поля в ответе - PullRequest
4 голосов
/ 25 января 2011

Есть ли способ ограничить объем текста в текстовом поле из запроса?Вот быстрый сценарий ....

У меня есть 2 поля:

  • docId - int
  • text - string.

Я сделаю запрос в поле docId и хочу получить текст «предварительного просмотра» из текстового поля из 200 символов.В среднем текстовое поле содержит 600-2000 символов, но мне нужен только предварительный просмотр.

например.[mySolrCore] / select? q = docId: 123 & fl = text

Есть ли способ сделать это, поскольку я не вижу смысла возвращать все текстовое поле, если мне нужен только небольшой предварительный просмотр?

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

Надеюськто-то может указать мне правильное направление!

Ура!

Ответы [ 5 ]

4 голосов
/ 28 января 2011

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

http://solr:8080/solr/select/?q=*:*&rows=10&fl=author,title&hl=true&hl.snippets=0&hl.fl=sku&hl.fragsize=0&hl.alternateField=description&hl.maxAlternateFieldLength=50

Примечания:

  • Убедитесь, что ваше альтернативное поле не существует в параметре списка полей (fl)
  • Убедитесь, что ваше поле выделения (hl.fl) на самом деле не содержит текст, который вы хотите найти

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

3 голосов
/ 25 января 2011

Я решил превратить свой комментарий в ответ.

Я бы посоветовал вам не хранить ваши текстовые данные в Solr / Lucene.Индексируйте данные только для поиска и сохраняйте уникальный идентификатор или URL-адрес для идентификации документа.Содержимое документа следует извлекать из отдельной системы хранения.

Solr / Lucene оптимизированы для поиска.Они не являются вашим хранилищем данных или базой данных, и их не следует использовать таким образом.Когда вы храните в Solr больше данных, чем необходимо, вы оказываете негативное влияние на всю поисковую систему.Вы увеличиваете размер индексов, увеличиваете время репликации между ведущими и ведомыми устройствами, реплицируете данные, для которых вам нужна только одна копия, и тратите кэш-память на кеши документов, которые следует использовать для ускорения поиска.Я бы предложил 2 вещи.

Во-первых, оптимально, удалите текстовое хранилище целиком из поискового индекса.Извлечение текста предварительного просмотра и всего текста из вторичной системы, которая оптимизирована для хранения документов, например, файлового сервера.

Во-вторых, неоптимально, сохраните только текст предварительного просмотра в поисковом индексе.Храните весь документ в другом месте, например на файловом сервере.

0 голосов
/ 28 января 2017

Мое желание, которое, как я подозреваю, разделяют многие сайты, - предложить фрагмент текста с каждым ответом на запрос. Это обновляет то, что пользователь видит из простых заголовков или аналогичных. Это нормальная (см. Google в качестве примера) и продуктивная техника. В настоящее время мы не можем легко справиться с отправкой всего тела контента из Solr / Lucene в программу веб-презентации и создать там фрагмент кода вместе со многими другими в виде набора ответов, поскольку это является существенной проблемой сети, ЦП и памяти (подумайте имеет дело со многими мульти-МБ файлами).

Разумно для Solr / Lucene иметь возможность отправлять только первые N байтов контента по запросу, тем самым избавляя от множества проблем на местах. Kludges с осветительными приборами и так далее, только мешают правильному использованию. Мы помним, что механизмы подачи материала в Solr / ucene могут не выполнять синтаксический анализ файлов, поэтому эти фидеры не могут создавать фрагменты.

0 голосов
/ 25 января 2011

Linkedin поиск в реальном времени http://snaprojects.jira.com/browse/ZOIE

Для хранения больших данных http://project -voldemort.com /

0 голосов
/ 25 января 2011

вы можете добавить дополнительное поле, такое как выдержка / резюме, которое состоит из первых 200 символов в тексте, и вместо этого вернуть это поле

...