Я знаю, что в прошлом были вопросы о SQL 2005 по сравнению с Lucene.NET, но с 2008 года вышли, и они внесли в него много изменений и задавались вопросом, любой может дать мне за/против (или ссылку на статью).Полный текстовый поиск SQL Server 2008 (FTS) по сравнению с Lucene.NET
Я построил среднюю базу знаний (возможно, 2 ГБ проиндексированного текста) поверх FTS SQL Server 2005 в 2006 году и теперь перенес ее в iFTS 2008 года. Обе ситуации сработали хорошо для меня, но переход с 2005 по 2008 год был для меня действительно улучшением.
Моя ситуация не была такой, как StackOverflow в том смысле, что я индексировал данные, которые обновлялись только ночью, однако я пытался присоединиться к результатам поиска из нескольких операторов CONTAINSTABLE обратно друг к другу и в реляционные таблицы.
В 2005 году FTS это означало, что каждый CONTAINSTABLE должен был выполнять поиск по индексу, возвращать полные результаты, а затем приводить к тому, что механизм БД соединяет эти результаты с реляционными таблицами (все это было прозрачно для меня, но это было происходило и было дорого для запросов). В 2008 году iFTS улучшил эту ситуацию, потому что интеграция с базой данных позволяет нескольким CONTAINSTABLE результатам стать частью плана запросов, что сделало многие поиски более эффективными.
Я думаю, что оба двигателя FTS 2005 и 2008 годов, а также Lucene.NET, имеют архитектурные компромиссы, которые будут лучше или хуже соответствовать многим обстоятельствам проекта - мне просто повезло, что обновление работало в мою пользу. Я могу полностью понять, почему iFTS в 2008 году не будет работать в той же конфигурации, что и в 2005 году, для высокой точности OLTP для использования, например StackOverflow.com. Тем не менее, я бы не стал снижать вероятность того, что iFTS 2008 года может быть изолирован от тяжелой загрузки транзакции вставки ... но это также звучит так, как будто это может быть столько же, что и для перехода на Lucene.NET ... и круто фактор Lucene.NET трудно игнорировать;)
В любом случае, для меня легкость и эффективность iFTS SQL 2008 в большинстве ситуаций, вероятно, устраняет «классный» фактор Lucene (хотя он прост в использовании, I «я никогда не использовал его в производственной системе, поэтому я оставляю комментарий на этом»). Мне было бы интересно узнать, насколько эффективнее Lucene (как оказалось, она реализована сейчас?) В StackOverflow или подобных ситуациях.
Это может помочь: http://blog.stackoverflow.com/2008/11/sql-2008-full-text-search-problems/
Не использовали SQL Server 2008 лично, хотя и на основе этой записи в блоге, это выглядит как функциональность полнотекстового поиска медленнее, чем это было в 2005 году
мы используем возможности полнотекстового поиска, но, на мой взгляд, это зависит от самих данных и ваших потребностей.
Мы масштабируем с помощью веб-серверов, и поэтому мне нравится lucene, потому что у меня нет такой большой нагрузки на sql-сервер.
Для начинающих с нуля и желающих иметь полнотекстовый поиск, я бы предпочел решение sql-сервера, потому что я считаю, что очень быстро получить результаты, если вы хотите, чтобы lucene вам нужно было реализовать больше при запуске (а также получить некоторые ноу-хау).
SQL Server FTS будет проще управлять для небольшого развертывания. Поскольку FTS интегрирована с БД, СУРБД автоматически обновляет индекс. Консоль здесь заключается в том, что у вас нет очевидного решения масштабирования, которое не соответствует репликационным БД. Поэтому, если вам не нужно масштабировать, SQL Server FTS, вероятно, «безопаснее». В политическом плане большинство магазинов будет более комфортно с использованием чистого решения SQL Server.
На стороне Lucene я бы предпочел SOLR над линейкой Lucene. В любом решении вам нужно больше работать над обновлением индекса при изменении данных, а также с отображением данных в индекс SOLR/Lucene. Плюсы в том, что вы можете легко масштабировать, добавляя дополнительные индексы. Вы можете запускать эти индексы на очень скудных серверах linux, что устраняет некоторые издержки на лицензию. Если вы возьмете маршрут Lucene/SOLR, я бы поставил цель разместить ВСЕ данные, которые вам нужны непосредственно в индекс, вместо того, чтобы помещать указатели обратно в базу данных в индексе. Вы можете включать данные в индекс, который не доступен для поиска, поэтому, например, вы могли бы предварительно создать HTML или XML, хранящиеся в индексе, и обслуживать его как результат поиска. При таком подходе ваша БД может быть отключена, но вы по-прежнему можете обслуживать результаты поиска в отключенном режиме.
Я никогда не видел сравнительного сравнения производительности между SQL Server 2008 и Lucene, но хотел бы его увидеть.
Одно из соображений, которое вам нужно иметь в виду, - это то, какие ограничения поиска у вас есть в дополнение к полнотекстовому ограничению. Если вы выполняете ограничения, которые lucene не может предоставить, вы почти наверняка захотите использовать FTS. Одна из приятных событий 2008 года заключается в том, что они улучшили интеграцию FTS со стандартными запросами сервера sql, поэтому производительность должна быть лучше со смешанной базой данных и ограничениями по ФТ, чем в 2005 году.