2016-09-23 4 views
5

260万レコードのテーブルでSQL Server 2008 R2全文検索を使用しています。検索パフォーマンスはしばしば貧弱です。一般的に報告されているパターンは、コールドシステム/最初の実行〜10 +秒、その後の実行〜1〜2秒です。バージョン2008 R2以降、Sql Serverフルテキスト検索(FTS)のパフォーマンスが向上していますか?

 
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(!) 

私の質問:

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

記事は、ウィキペディアのデータをダンプ使用して、以下の速度比較結果を示しています。これは2月、2013年の日付の次の記事で報告された結果とインラインであります次のとおりです。

  1. この記事は2013年2月8日に公開されて以来、主要なSQL Serverのリリースでは、より新しいSQL Serverバージョン(2012,2014,2016)に移行したとき、同じデータ(好ましくは1〜100万レコード)

  2. 最近のSQL Serverのバージョンでは、solr/luceneのようにRAMに配置されたFTSカタログ/インデックスがサポートされていますか?

UPDATE:このシナリオでは、我々はほとんどFTカタログリンクテーブルに新しいデータを挿入していないが、唯一の非常に頻繁に検索さ読みを実行します。だから、私はSQLが常にFTSインデックスを再構築することが問題だとは思わない。

答えて

1

Fulltext Search Improvements in SQL Server 2012

私たちは、どのように、インデックスフラグメントの人口の間に割り当てられているどのくらいのメモリから、共有スキーマ・ロックを解除するために継続的なインデックス更新を待っている間のクエリをブロックする方法のコードベース全体を見てTOP N検索クエリを最適化するためのストリーミングテーブル値関数としてのクエリコードベースの再編成、並列スレッドでの検索を実行するためのキー配信ヒストグラムの維持方法、プロセッサの計算命令をより効果的に活用する方法まで例えば、スコアリングランク)...最終結果は、パフォーマンスを大幅に向上させることができるということです(多くの場合、大規模なクエリワークルを使用してインデックスを同時に更新する場合は10倍ですストレージ構造や既存のAPIサーフェスを変更することなく拡張することができます。 SQL 2008/R2からDenaliに向かうすべてのお客様は、この改善に役立ちます。

+0

コメントありがとう、非常に貴重な情報。しかし、私は現実世界の経験を探していました。 MSFTの主張に加えて、SQL Server 2008 R2からより新しいバージョンに移行したときに実際のFTSのパフォーマンスが向上したと報告することはできますか?これまでのところ、最近のSQL Serverのバージョン(たとえば2014年)でもFTSの遅さについて多くの人々が不平を感じています。 SQL Server 2005はFTSの中で最も速いリリースだったようです。 – andrews

+0

デベロッパーエディションは無料でエンタープライズと同じ機能を持っています。あなたはそれらをテスト場として使用することができます – TheGameiswar

+0

私たちはms購読しています。新しいSQLインスタンスを取得するのは問題ではありません。アップグレードするバージョンのデータを収集するだけです。検索時間が今のままであれば、FTSからsolrに移動します。 – andrews

0

SQL ServerのFTS内部構造を少し掘り下げることをお勧めします。これにより、クエリがどのように実行され、どのように動作するかを知ることができます。私はここから始めることをお勧めします:https://technet.microsoft.com/en-us/library/ms142505(v=sql.105).aspxとここに:https://msdn.microsoft.com/ru-ru/library/cc721269.aspx。内部的にFTSはテーブルとインデックスを使用します。すべての利点と欠点を持つ。したがって、他のテーブルと同様に、その内部テーブルのデータがバッファプールにない場合、SQL ServerはディスクからRAMに読み込みます。 RAM内のデータは、RAMから読み込まれます。

+0

デニス、リンクありがとう。しかし私の質問にリンクしている記事を見てください。この記事では、Solr/LuceneがRAM内のIndexの位置を明確にサポートしていることを示しています.SolrのインデックスがRAMにあるときにコールドクエリでもパフォーマンスが向上することをSQL Serverはサポートしていません。私はSQL Server FTSが最近のリリースでこの特定の機能を持っているかどうかを知りたいと思っていました。デフォルトでは通常のインデックスキャッシュをカウントしませんでした。 – andrews

+0

@andrews、はい、それは私が強調したいことです。この文は、「SQL Serverの使用ディスク、Luceneを使用するRAM」が間違っています。とにかくRAMに32 GBのRAMがありますが、インデックスが64 GBの場合は、SQL ServerもLuceneも使用できません。 –

+0

@andrews SQL Server FTSは、FTSクエリのユーザーテーブルと結合された単なるテーブルのセットです。他のテーブルと同様に、FTSデータはRAMからのみ読み取ることができるため、SQL Serverは必要なデータをRAMに取り込んでクライアントに送信する必要があります。十分なRAMであれば、そのデータはすべてRAMに残ります。これは、かなり効率的な既存のリレーショナル・メカニズムの再利用の一種です。 –

関連する問題