Вопрос

Кто-нибудь использовал Lucene.NET вместо полнотекстового поиска, поставляемого с sql Server?

Если это так, мне было бы интересно узнать, как вы это реализовали.

Вы, например, написали службу Windows, которая запрашивала базу данных каждый час, а затем сохраняла результаты в индексе lucene.net?

Это было полезно?

Решение

Да, я использовал это именно для того, что вы описываете. У нас было два сервиса - один для чтения, другой для записи, но только потому, что у нас было несколько читателей. Я уверен, что мы могли бы сделать это только с одним сервисом (писателем) и встроить ридер в веб-приложение и сервисы.

Я использовал lucene.net в качестве основного индексатора базы данных, поэтому я получил в основном идентификаторы БД (для индексированных сообщений электронной почты), и я также использовал его, чтобы получить достаточно информации для заполнения результатов поиска или чего-то подобного не касаясь базы данных. Он отлично работает в обоих случаях, так как SQL может работать немного медленнее, так как вам нужно получить идентификатор, выбрать идентификатор и т. Д. Мы справились с этим, создав временную таблицу (с одной строкой идентификатора в ней) и массовая вставка из файла (который был выводом из lucene) с последующим присоединением к таблице сообщений. Было намного быстрее.

Lucene не идеален, и вам нужно немного подумать за рамкой реляционной базы данных, потому что она ПОЛНОСТЬЮ не единая, но она очень хорошо справляется со своими задачами. Стоит посмотреть, и, как мне сказали, у вас нет символа "Ой, извините, вам нужно заново перестроить индекс" " проблемы, которые делает FTI MS SQL.

Кстати, мы имели дело с 20-50 миллионами электронных писем (и около 1 миллиона уникальных вложений), на мой взгляд, около 20 ГБ индекса lucene и 250 + ГБ базы данных SQL + вложения.

Производительность была фантастической, если не сказать больше - просто подумайте и настройте факторы слияния (когда они объединяют сегменты индекса). Нет проблем с наличием более одного сегмента, но может возникнуть БОЛЬШАЯ проблема, если вы попытаетесь объединить два сегмента, каждый из которых имеет 1 мил, и у вас есть поток наблюдателя, который убивает процесс, если он занимает слишком много времени ... .. (да, это надрал нам задницу некоторое время). Поэтому держите максимальное количество документов на штуку НИЗКИМ (т. Е. Не устанавливайте максимальное значение, как мы!)

РЕДАКТИРОВАТЬ Corey Trager задокументировал, как использовать Lucene.NET в BugTracker.NET здесь .

Другие советы

Я еще не сделал это с базой данных, ваш вопрос вроде открыт.

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

Я думаю, что нам не нужен другой индексатор, который не знает о том, что он делает, и каждый раз переиндексирует, или использует ресурсы расточительно.

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

Что касается различий между сервером sql и lucene, то основная проблема полнотекстового поиска sql server 2005 заключается в том, что служба отделена от реляционного механизма, поэтому объединяет, упорядочивает, объединяет и фильтрует результаты полнотекстового поиска и реляционные столбцы. Microsoft заявляет, что эти проблемы были решены в SQL Server 2008, поскольку в них встроен полнотекстовый поиск внутри реляционного механизма, но они не проверялись. Они также сделали весь полнотекстовый поиск намного более прозрачным, в предыдущих версиях стеммеры, стоп-слова и некоторые другие части индексации были похожи на черный ящик и были трудны для понимания, а в новой версии легче было увидеть, как они работают.

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

Я использовал Lucene.NET вместе с MySQL.Мой подход заключался в том, чтобы сохранить первичный ключ записи базы данных в документе Lucene вместе с индексированным текстом.В псевдокоде это выглядит следующим образом:

  • Хранить запись:

    вставить текст, другие данные в таблицу
    получить последний вставленный идентификатор
    создать документ lucene
    поместить (идентификатор, текст) в документ lucene обновить индекс lucene

  • Запрашивающий
    поиск по индексу lucene
    для каждого документа lucene в результирующем наборе загружайте данные из базы данных по идентификатору сохраненной записи

Просто хочу отметить, что я переключился с Lucene на Сфинкс благодаря этому достигается превосходная производительность

Я думаю, что эта статья является хорошей отправной точкой:

http://www.aspfree.com/ с / а / Braindump / рабочий-с Lucene-нетто /

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top