SQL Server 2008 全文搜索 (FTS) 与 Lucene.NET

Question

我知道过去有关于 SQL 2005 与 Lucene.NET 的问题，但自 2008 年问世以来，他们对其进行了很多更改，并想知道是否有人可以给我优点/缺点（或链接到文章)。

Answer 1

SQL Server FTS 将更易于管理小型部署。由于 FTS 与 DB 集成在一起，RDBMS 会自动处理更新索引。这里的缺点是除了复制数据库之外，您没有明显的扩展解决方案。因此，如果您不需要扩展，SQL Server FTS 可能“更安全”。从政治上讲，大多数商店会更愿意使用纯 SQL Server 解决方案。

在 Lucene 方面，我更喜欢 SOLR 而不是直接的 Lucene。无论使用哪种解决方案，您都必须自己做更多的工作来在数据更改时更新索引，以及自己将数据映射到 SOLR/Lucene 索引。优点是您可以通过添加其他索引轻松扩展。您可以在非常精简的 linux 服务器上运行这些索引，从而消除一些许可成本。如果您采用 Lucene/SOLR 路线，我的目标是将您需要的所有数据直接放入索引中，而不是将指针放回索引中的数据库。您可以在索引中包含不可搜索的数据，例如，您可以在索引中存储预构建的 HTML 或 XML，并将其作为搜索结果提供。使用这种方法，您的数据库可能会关闭，但您仍然可以在断开连接的模式下提供搜索结果。

我从未见过 SQL Server 2008 和 Lucene 之间的直接性能比较，但我很想看看。

Answer 2

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

我的情况与 StackOverflow 的情况不同，因为我正在索引仅在夜间刷新的数据，但是我试图将来自多个 CONTAINSTABLE 语句的搜索结果重新连接到彼此和关系表中。

在 2005 年的 FTS 中，这意味着每个 CONTAINSTABLE 都必须在索引上执行搜索，返回完整结果，然后让数据库引擎将这些结果连接到关系表中（这对我来说是透明的，但它正在发生并且查询成本很高）。 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 3

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

个人没有使用过 SQL Server 2008，但根据那篇博客文章，全文搜索功能似乎比 2005 年慢。

Answer 4

我们同时使用全文搜索的可能性，但我认为这取决于数据本身和您的需求。

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

对于从 null 开始并希望进行全文搜索，我更喜欢 sql-server 解决方案，因为我认为获得结果真的很快，如果你想要 lucene，你必须在开始时实现更多（并且还得到一些诀窍）。

Answer 5

您需要牢记的一个注意事项是，除了全文约束之外，您还有哪些类型的搜索约束。如果您正在做 lucene 无法提供的约束，那么您几乎肯定会想要使用 FTS。 2008 年的一大优点是他们改进了 FTS 与标准 sql server 查询的集成，因此混合数据库和 FT 约束的性能应该比 2005 年更好。