Является ли полнотекстовый поиск SQL Server правильным инструментом для поиска фраз, а не документов?

Question

30 миллионов различных фраз, а не документов, в диапазоне от одного слова до предложения из 10 слов, и мне нужно поддерживать поиск по слову / фразе. В основном, что где содержит (фраза, «книга» или «переполнение стека») предлагает.

У меня есть экземпляр SQL Server 2005 (32-разрядный, 4-процессовый, 4 ГБ), работающий с несколькими полнотекстовыми каталогами, и производительность при поиске слов с высокой мощностью очень высока.

Вот мои мысли, чтобы ускорить процесс, возможно, кто-то может предложить руководство -

1) Обновление до 2008 iFTS, 64 бита. Sql Server 2005 FTS служба Windows никогда не превышает 50 МБ. Из того, что я собрал, он использует кеш файловой системы для поиска каталожных индексов. Мои заполненные каталоги на диске составляют всего около 300 Мб, так почему же все это не может быть в памяти? Может ли помочь новая архитектура памяти iFTS, которая является частью процесса sqlserver?

2) Масштабирование каталогов до нескольких серверов. Будут ли запросы к связанным серверам FTS выполняться параллельно?

3) Так как я ищу здесь фразы, а не документы, возможно, полнотекстовый поиск в Sql Server не является ответом. Lucene.NET? Поместить индекс каталога на оперативную память?

Answer 1

Lucene.Net может предложить очень высокую производительность для такого рода приложений наряду с довольно простым API. Выпуск 2.3.2 близится к завершению, что обеспечивает дополнительное повышение производительности по сравнению с выпуском 2.1. Хотя размещение индекса Lucene в RAMDirectory (структура индекса на основе памяти Lucene) будет обеспечивать еще большую производительность, мы видим отличные результаты даже с FSDirectory (индекс на основе диска).

Answer 2

Я немного удивлен, что FTS скрипит под такой нагрузкой. Однако, если это так, то классический подход (Гэри Килдалл разработал его для поиска компакт-дисков!) Заключался бы в использовании индекса инверсии. Я использовал эту технику в течение длительного времени с целым рядом приложений. Обычно его называют индексной техникой «Inverted» или «Inversion». (см. http://en.wikipedia.org/wiki/Search_engine_indexing#Inverted_indices). Техника очень хорошо масштабируется, и я протестировал ее, проиндексировав до 8 миллионов документов. Даже при поиске в восьми миллионах документов, он получает результаты в течение трех секунд, если индексы верны. Часто это намного быстрее, чем это.

Я использую индекс Инверсии, чтобы получить (до допустимого числа через TOP x) пул вероятных кандидатов, а затем выполняю их перебор с помощью регулярного выражения. Работает очень хорошо.

Answer 3

Взгляните на Apache Solr . Это поисковый сервер, который упаковывает Lucene с HTTP-интерфейсом. Каждая из ваших фраз будет отображаться в документе Solr. 30M документов - это не много для Solr, потому что ваши документы будут очень короткими. Окончательная производительность также будет зависеть от того, сколько запросов / сек вам нужно.

Answer 4

В качестве готового решения я бы предпочел использовать «Microsoft Office SharePoint Server» для индексации и поиска по содержимому документов. Бесплатная альтернатива - библиотека Lucene.Net, если вы хотите написать свой собственный сервис для индексации и поиска. Создание собственной службы полнотекстового поиска с Lucene.Net обеспечит вам всю необходимую гибкость (да, вы можете хранить индекс на внешнем хранилище, если хотите).