Кто-нибудь использовал Lucene.NET вместо использования полного текстового поиска, который поставляется с SQL-сервером?
Если так, мне будет интересно, как вы его реализовали.
Вы, например, пишете службу Windows, которая каждый час запрашивала базу данных, а затем сохраняла результаты в индексе lucene.net?
Да, я использовал его для того, что вы описываете. У нас было две службы - одна для чтения и одна для записи, но только потому, что у нас было несколько читателей. Я уверен, что мы могли бы сделать это только с одной службой (автором) и встроить читателя в веб-приложение и службы.
Я использовал lucene.net в качестве общего индексатора базы данных, поэтому то, что я получил, было в основном DB id (для индексированных сообщений электронной почты), и я также использую его для получения достаточной информации для заполнения результатов поиска или таких не касаясь базы данных. Он работал отлично в обоих случаях, SQL может немного замедлить работу, поскольку вам в значительной степени нужно получить идентификатор, выбрать идентификатор и т.д. Мы обошли это, создав временную таблицу (с только строкой идентификатора в ней) и массовая вставка из файла (который был результатом lucene), затем присоединение к таблице сообщений. Было намного быстрее.
Lucene не идеальна, и вам нужно немного подумать о выходе из реляционной базы данных, потому что она TOTALLY не одна, но она очень хороша в том, что она делает. Стоит посмотреть, и, как мне сказали, у меня нет проблем "oops, извините, вам нужно перестроить ваш индекс", что MS SQL FTI делает.
Кстати, мы имели дело с 20-50 миллионами писем (и около 1 миллиона уникальных вложений), всего около 20 ГБ индекса lucene, я думаю, и 250 + GB базы данных SQL + вложения.
Производительность была фантастической, если не сказать больше, просто убедитесь, что вы думаете и настраиваете свои коэффициенты слияния (когда он объединяет сегменты индекса). Нет проблем в работе с несколькими сегментами, но может возникнуть проблема с BIG, если вы попытаетесь объединить два сегмента, каждый из которых имеет по 1 миллилитру элементов, и у вас есть поток наблюдателей, который убивает процесс, если он занимает слишком много времени..... (да, это немного ударило нас в задницу). Так что держите максимальное количество документов на предмет LOW (т.е. Не устанавливайте его в maxint, как мы это делали!)
EDIT Corey Trager документировал, как использовать Lucene.NET в BugTracker.NET здесь.
Я еще не делал этого в отношении базы данных, ваш вопрос открыт.
Если вы хотите найти db и можете использовать Lucene, я также предполагаю, что вы можете управлять, когда данные вставляются в базу данных. Если это так, есть небольшая причина для опроса db, чтобы узнать, нужно ли вам переиндексировать, просто индексировать при вставке или создавать таблицу очередей, которая может использоваться, чтобы сообщить lucene, что индексировать.
Я думаю, нам не нужен другой индекс, который не знает, что он делает, и переиндексирует каждый раз, или использует ресурсы расточительно.
Я использовал lucene.net также как механизм хранения, потому что проще распространять и настраивать альтернативные машины с индексом, чем с базой данных, это просто копия файловой системы, вы можете индексировать на одной машине и просто копировать новые файлы на другие машины для распространения индекса. Все поисковые запросы и данные отображаются из индекса lucene, и база данных используется только для редактирования. Эта настройка была доказана как очень масштабируемое решение для наших нужд.
Что касается различий между sql-сервером и lucene, основной проблемой полнотекстового поиска sql server 2005 является то, что служба отделена от реляционного движка, поэтому объединяет, упорядочивает, агрегатирует и фильтрует между полными текстовыми результатами и реляционными столбцами являются очень дорогими в плане производительности, Microsoft утверждает, что эти проблемы были рассмотрены в SQL Server 2008, интегрируя полный текстовый поиск внутри реляционного движка, но я его не тестировал. Они также сделали весь полнотекстовый поиск намного более прозрачным, в предыдущих версиях - стволовые, стоп-слова и несколько других частей индексации, где, как черный ящик, и их трудно понять, а в новой версии легче увидеть, как они работают.
По моему опыту, если sql-сервер соответствует вашим требованиям, это будет самый простой способ, если вы ожидаете большого роста, сложных запросов или нуждаетесь в большом контроле полного текстового поиска, вы можете подумать о работе с lucene с начать, потому что будет легче масштабировать и персонализировать.
Я думаю, что эта статья является хорошей отправной точкой:
http://www.aspfree.com/c/a/braindump/working-with-lucene-net/
Я использовал Lucene.NET вместе с MySQL. Мой подход состоял в том, чтобы хранить первичный ключ записи db в документе Lucene вместе с индексированным текстом. В псевдокоде это выглядит так:
Сохранить запись:
вставить текст, другие данные в таблицу
получить последние вставленные ID
создать документ lucene
put (ID, текст) в документ lucene
Обновить индекс lucene
Запросы
поиск lucene index
для каждого документа lucene в результирующем наборе данных нагрузки из БД с помощью сохраненного идентификатора записи
Чтобы отметить, я переключился с Lucene на Sphinx из-за превосходной производительности