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

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

对于小型部署,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之间的头对头性能比较,但很想看到一个.

我在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有多高效(现在已经实现了吗？)？