sql-server - 自 2008 R2 版本以来，是否有任何 Sql Server 全文搜索 (FTS) 性能改进？

Question

我们正在对包含 260 万条记录的表使用 SQL Server 2008 R2 全文搜索。搜索性能通常很差，它遵循普遍报告的模式:冷系统/首次运行 ~10+ 秒，后续运行 ~1-2 秒。这与 2013 年 2 月的以下文章中报告的结果一致:

So You Think You Can Search – Comparing Microsoft SQL Server FTS and Apache Lucene

文章展示了以下使用维基百科转储数据的速度比较结果:

索引速度、大小和单个查询执行时间使用:

Lucene MS SQL FTS
索引速度 3 MB/秒 1 MB/秒
指数规模 10-25% 25-30%
简单查询 < 20 ms < 20 ms
使用自定义分数查询 < 4 秒 > 20 秒

并行查询执行(10 个线程，每个查询的平均执行时间以毫秒为单位):

MS SQL FTS Lucene(文件系统)Lucene(RAM)
冷系统:简单查询 56 643 21
提升查询 19669* 859 27
第二次执行:简单查询 14 8 < 5
提升查询 465 17 9

*平均时间，第一个查询最多可以执行 2 分钟(!)

我的问题是:

由于自这篇文章于 2013 年 2 月 8 日发布以来有几个主要的 SQL Server 版本，当他们迁移到更新的 SQL Server 版本(2012 年、2014 年)时，有人可以报告对相同数据(最好是 1+ 百万条记录)的任何 FTS 性能改进吗？和 2016 年)？

最近的 SQL Server 版本是否像 solr/lucene 一样支持放置在 RAM 中的 FTS 目录/索引？

更新:在我们的场景中，我们很少将新数据插入到 FT 目录链接表中，但经常运行只读搜索。所以，我不认为 SQL 不断重建 FTS 索引是问题所在。

Answer 1

Fulltext Search Improvements in SQL Server 2012 :

We looked at the entire code base from how queries block while waiting an ongoing index update to release a shared schema lock, from how much memory is allocated during index fragment population, to how we could reorganize the query code base as a streaming Table Value Function to optimize for TOP N search queries, how we could maintain key distribution histograms to execute search on parallel threads, all the way to how we could take better advantage of the processor compute instructions (scoring ranks for example)… End result is that we are able to significantly boost performance (10X in many cases when it comes to concurrent index updates with large query workloads) and scale without having to change any storage structures or existing API surface. All our customers going from SQL 2008 / R2 to Denali will benefit with this improvement.