我知道过去有过关于SQL 2005与Lucene.NET的问题，但是自2008年问世以来，他们对它进行了很多修改，并且想知道是否有人可以给我优缺点（或链接到文章） ）。
答案 0 :(得分：19)
对于小型部署，SQL Server FTS将更容易管理。由于FTS与DB集成，因此RDBMS会自动处理索引更新。这里的问题是，你没有一个明显的扩展解决方案，而不是复制数据库。因此，如果您不需要扩展，SQL Server FTS可能“更安全”。在政治上，大多数商店对纯SQL Server解决方案会更加满意。
在Lucene方面，我赞成SOLR而不是直接的Lucene。使用任一解决方案，您都必须在数据更改时自行更新索引，以及将数据本身映射到SOLR / Lucene索引。优点是您可以通过添加其他索引轻松扩展。您可以在非常精简的Linux服务器上运行这些索引，从而消除了一些许可证成本。如果采用Lucene / SOLR路由，我的目标是将所需的所有数据直接放入索引中，而不是将指针放回索引中的DB。您可以在索引中包含不可搜索的数据，例如，您可以在索引中存储预先构建的HTML或XML，并将其作为搜索结果提供。使用这种方法，您的数据库可能已关闭，但您仍然可以在断开连接模式下提供搜索结果。
我从未见过SQL Server 2008和Lucene之间的头对头性能比较，但很想看到它。
答案 1 :(得分：16)
我在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的效率是多少（现在已经实现了吗？）。
答案 2 :(得分：4)
这可能会有所帮助： http://blog.stackoverflow.com/2008/11/sql-2008-full-text-search-problems/
没有亲自使用SQL Server 2008，虽然基于该博客条目，看起来全文搜索功能比2005年慢。
答案 3 :(得分：4)
我们使用全文搜索的可能性，但在我看来，这取决于数据本身和您的需求。
我们使用Web服务器扩展，因此我喜欢lucene，因为我在sql-server上没有那么多负载。
从null开始并希望有一个全文搜索我更喜欢sql-server解决方案，因为我认为获得结果真的很快，如果你想要lucene你必须在开始时实现更多（并且还得到一些技术诀窍。
答案 4 :(得分：0)
您需要记住的一个考虑因素是除了全文约束之外还有哪种搜索约束。如果你正在做lucene无法提供的约束，那么你几乎肯定会想要使用FTS。 2008年的一个好处是它们改进了FTS与标准sql server查询的集成，因此混合数据库和FT约束的性能应该比2005年更好。