sql-server - 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

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

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

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

Answer 5

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