自2008 R2以来,是否有任何Sql Server全文搜索(FTS)性能改进？

Question

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

所以你认为你可以搜索 - 比较Microsoft SQL Server FTS和Apache Lucene

本文使用Wikipedia转储数据显示以下速度比较结果:

Indexing speed, size and single query execution time using:

                        Lucene      MS SQL FTS
Indexing Speed          3 MB/sec    1 MB/sec
Index Size              10-25%      25-30%
Simple query            < 20 ms     < 20 ms
Query With Custom Score < 4 sec     > 20 sec

Parallel Query Executions (10 threads, average execution time per query in ms):

                                     MS SQL FTS  Lucene (File System)   Lucene (RAM)
Cold System:         Simple Query    56          643                    21
                     Boost Query     19669*      859                    27
Second executions:   Simple Query    14          8                      < 5
                     Boost Query     465         17                     9

*average time, the very first query could be executed up to 2 min(!)

我的问题是:

1. 自从该文章于2013年2月8日发布以来,有几个主要的SQL Server版本,当有人迁移到更新的SQL Server版本时,有人可以报告相同数据(最好是超过100万条记录)的任何FTS性能改进(2012年,2014年)和2016)？

2. 更新的SQL Server版本是否支持放在RAM中的FTS目录/索引,就像solr/lucene一样？

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

Answer 1

SQL Server 2012 中的全文搜索改进：

\n\n

\n

我们研究了整个代码库，从查询在等待正在进行的索引更新以释放共享模式锁时如何阻塞、在索引片段填充期间分配了多少内存，到如何将查询代码库重新组织为流式表值函数优化 TOP N 搜索查询，我们如何维护关键分布直方图以在并行线程上执行搜索，一直到我们如何更好地利用处理器计算指令（例如评分排名）\xe2\x80\xa6 End结果是，我们能够显着提高性能（在许多情况下，当涉及到具有大量查询工作负载的并发索引更新时，可以提高 10 倍）和扩展，而无需更改任何存储结构或现有 API 界面。我们所有从 SQL 2008 / R2 到 Denali 的客户都将受益于这一改进。

\n

\n