Полный текстовый поиск SQL Server 2008 (FTS) по сравнению с Lucene.NET

Ответ 1

В 2006 году я построил базу знаний среднего размера (возможно, 2 ГБ проиндексированного текста) поверх FTS SQL Server 2005 и теперь перенес ее в 2008 iFTS. Обе ситуации сработали хорошо для меня, но переход с 2005 по 2008 год был для меня хорошим улучшением.

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

В 2005 году FTS это означало, что каждый CONTAINSTABLE должен был бы выполнять свой поиск по индексу, возвращать полные результаты, а затем приводить к тому, что механизм БД соединяет эти результаты с реляционными таблицами (все это было прозрачно для меня, но это происходило и был дорогим для запросов). 2008 iFTS улучшила эту ситуацию, поскольку интеграция с базой данных позволяет нескольким результатам CONTAINSTABLE стать частью плана запросов, что сделало много запросов более эффективным.

Я думаю, что как 2005, так и 2008 FTS-движки, а также Lucene.NET, имеют архитектурные компромиссы, которые будут лучше или хуже соответствовать многим обстоятельствам проекта. Мне просто повезло, что обновление работало в мою пользу. Я могу полностью понять, почему iFTS в 2008 году не будет работать в той же конфигурации, что и в 2005 году, для высокопоставленного типа использования OLTP, например StackOverflow.com. Тем не менее, я бы не стал снижать вероятность того, что iFTS 2008 года может быть изолирован от тяжелой загрузки транзакции вставки... но это также звучит так, как будто это может быть столько же, что и для перехода на Lucene.NET... и круто фактор Lucene.NET трудно игнорировать;)

В любом случае, для меня легкость и эффективность iFTS SQL 2008 в большинстве ситуаций, вероятно, устраняет фактор Lucene "cool" (хотя он прост в использовании, я никогда не использовал его в производственной системе, м замечания относительно этого). Мне было бы интересно узнать, насколько эффективнее Lucene (оказалось, что она реализована сейчас?) В StackOverflow или подобных ситуациях.

Ответ 2

SQL Server FTS будет легче управлять для небольшого развертывания. Поскольку FTS интегрирована с БД, СУРБД автоматически обновляет индекс. Консоль здесь заключается в том, что у вас нет очевидного решения масштабирования, которое не соответствует репликационным БД. Поэтому, если вам не нужно масштабировать, SQL Server FTS, вероятно, "безопаснее". В политическом плане большинство магазинов будет более комфортно с чистым решением SQL Server.

На стороне Lucene я бы одобрил SOLR над линейкой Lucene. В любом решении вам нужно больше работать над обновлением индекса при изменении данных, а также с отображением данных в индекс SOLR/Lucene. Плюсы в том, что вы можете легко масштабировать, добавляя дополнительные индексы. Вы можете запускать эти индексы на очень скудных серверах linux, что устраняет некоторые издержки на лицензию. Если вы возьмете маршрут Lucene/SOLR, я бы поставил цель разместить ВСЕ данные, которые вам нужны непосредственно в индекс, вместо того, чтобы помещать указатели обратно в базу данных в индексе. Вы можете включать данные в индекс, который не доступен для поиска, поэтому, например, вы могли бы предварительно создать HTML или XML, хранящиеся в индексе, и обслуживать его как результат поиска. При таком подходе ваша БД может быть отключена, но вы все еще можете обслуживать результаты поиска в отключенном режиме.

Я никогда не видел сравнительного сравнения производительности между SQL Server 2008 и Lucene, но хотел бы увидеть его.

Ответ 3

Это может помочь: http://blog.stackoverflow.com/2008/11/sql-2008-full-text-search-problems/

Не использовал SQL Server 2008 лично, хотя на основе этой записи в блоге похоже, что полнотекстовый поиск работает медленнее, чем в 2005 году.

Ответ 4

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

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

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

Ответ 5

Одно соображение, которое вам нужно иметь в виду, - это какие ограничения поиска у вас есть в дополнение к полнотекстовому ограничению. Если вы выполняете ограничения, которые lucene не может предоставить, вы почти наверняка захотите использовать FTS. Одна из приятных событий 2008 года заключается в том, что они улучшили интеграцию FTS со стандартными SQL-серверами, поэтому производительность должна быть лучше со смешанной базой данных и ограничениями FT, чем в 2005 году.