SQL Server 2008全文本搜索（FTS）与Lucene.NET

Question

我知道过去一直存在关于SQL 2005与Lucene.NET的问题，但自2008年问世以来，他们对它做了很多更改，并且想知道是否任何人都可以给我优点/缺点（或链接到一篇文章）。

Answer 1

2006年，我在SQL Server 2005的FTS之上构建了一个中等规模的知识库（可能是2GB索引文本），现在已经将它移至2008的iFTS。这两种情况对我而言都很好，但从2005年到2008年的这一举措对我来说实际上是一种改进。

我的情况并不像StackOverflow的意义上说，我只是每晚刷新数据的索引，但是我试图将多个CONTAINSTABLE语句的搜索结果返回给对方和关系表。

在2005年的FTS中，这意味着每个CONTAINSTABLE必须在索引上执行搜索，返回完整结果，然后让DB引擎将这些结果加入到关系表中（这对我来说都是透明的，但它是发生并且查询费用昂贵）。 2008年的iFTS改善了这种情况，因为数据库集成允许多个CONTAINSTABLE结果成为查询计划的一部分，这使得大量搜索更加高效。

我认为，2005年和2008年的FTS引擎，以及Lucene。NET的架构折衷方案将会与许多项目情况相比更好或更差 - 我很幸运，升级对我有利。我可以完全明白为什么2008年的iFTS不能像2005年那样在StackOverflow.com这种用例的高度OLTP性质上运行。然而，我不会打折2008年iFTS可能与繁重的插入事务负载隔离的可能性......但是这听起来像完成转移到Lucene.NET一样多的工作......以及酷因为Lucene.NET的因素很难忽略;）对于我来说，SQL 2008的iFTS在大多数情况下的易用性和效率可能会导致Lucene的'酷'因素（尽管它易于使用，我从未在生产系统中使用它，所以我保留对此的评论）。我很有兴趣知道在StackOverflow或类似的情况下，Lucene是多么高效（现在已经实现了吗？）。

Answer 2

这可能帮助： http://blog.stackoverflow.com/2008/11/sql-2008-full-text-search-problems/

没有使用SQL Server 2008中的个人，但基于该博客条目，它看起来像全文搜索功能比它慢于2005年

Answer 3

我们使用全文搜索的可能性，但在我看来，它取决于数据本身和您的需求。

我们使用网络服务器进行扩展，因此我喜欢lucene，因为我没有那么多的sql-server负载。

对于从零开始，并希望有一个全文搜索，我宁愿sql-server解决方案，因为我认为这是真的很快得到的结果，如果你想lucene你必须在开始实施更多（也获得一些技巧）。

Answer 4

SQL Server FTS对于小型部署将更容易管理。由于FTS与数据库集成，因此RDBMS会自动更新索引。这意味着你没有一个明显的缩放解决方案，没有复制数据库。所以如果你不需要扩展，SQL Server FTS可能是“更安全”的。在政治上，大多数商店将会更加适应纯粹的SQL Server解决方案。

在Lucene方面，我赞成直接使用Lucene的SOLR。无论使用哪种解决方案，您都必须在数据更改时自己更新索引，并将数据映射到SOLR/Lucene索引。专业人员可以通过添加其他索引轻松进行缩放。您可以在非常精简的Linux服务器上运行这些索引，从而消除一些许可成本。如果你采用Lucene/SOLR路线，我会把你需要的所有数据直接放到索引中，而不是把索引放回数据库。您可以在索引中包含不可搜索的数据，例如，您可以将预先构建的HTML或XML存储在索引中，并将其作为搜索结果提供。采用这种方法，您的数据库可能会关闭，但您仍然可以在断开模式下提供搜索结果。

我从来没有见过SQL Server 2008和Lucene之间的头对头的性能比较，但很想看到一个。

Answer 5

需要注意的一点是除了全文约束之外，还有什么样的搜索约束条件。如果你正在做lucene无法提供的约束，那么你几乎肯定会使用FTS。 2008年的好处之一是，他们改进了FTS与标准SQL服务器查询的集成，因此混合数据库和FT约束条件下的性能应该比2005年更好。