4

1単語から10単語の文まで、ドキュメントではなく3,000万の異なるフレーズがあり、単語/フレーズ検索をサポートする必要があります。基本的に、contains（phrase、"'book'または'stackoverflow'"）が提供するもの。

SQL Server 2005（32ビット、4 proc、4gb）のインスタンスがいくつかのフルテキストカタログに反しており、カーディナリティの高い単語検索ではパフォーマンスがひどいです。

これが物事をスピードアップするための私の考えです、おそらく誰かがガイダンスを提供することができます-

1）2008 iFTS、64ビットにアップグレードします。Sql Server2005FTSのWindowsサービスは50MBを超えることはありません。私が収集したものから、カタログインデックスを検索するためにファイルシステムキャッシュを使用します。ディスクに入力されたカタログは約300MBしかないのに、なぜこれをすべてメモリに保存できないのでしょうか。sqlserverプロセスの一部であるiFTSの新しいメモリアーキテクチャは、ここで役立ちますか？

2）カタログを複数のサーバーにスケールアウトします。リンクされたFTSサーバーへのクエリは並行して実行されますか？

3）ここではドキュメントではなくフレーズを検索しているので、SQLServerの全文検索は答えではないかもしれません。Lucene.NET？カタログインデックスをRAMドライブに配置しますか？

4

4 に答える 4

2

Lucene.Net は、非常に単純な API とともに、この種のアプリケーションに非常に高いパフォーマンスを提供できます。リリース 2.3.2 は完成に近づいており、リリース 2.1 よりもさらにパフォーマンスが向上しています。Lucene インデックスを RAMDirectory (Lucene のメモリベースのインデックス構造) に配置すると、さらに優れたパフォーマンスが得られますが、FSDirectory (ディスクベースのインデックス) でも優れた結果が得られます。

于 2009-02-07T00:30:14.040 に答える
1

FTS がこの種の負荷の下できしむ音を立てていることに少し驚いています。ただし、これが事実であることが判明した場合、古典的なアプローチ (Gary Kildall が CD を検索するために開発したものです!) は、反転インデックスを使用することになります。私は、この手法を一連のアプリケーションで長い間使用してきました。これは通常、「反転」または「反転」指数技法と呼ばれます。( http://en.wikipedia.org/wiki/Search_engine_indexing#Inverted_indicesを参照)。この手法は非常にうまく拡張でき、最大 800 万のドキュメントのインデックス作成をテストしました。800万件の文書を検索しても、インデックスが正しければ3秒以内に結果が得られます。多くの場合、これよりもはるかに高速です。

Inversion インデックスを使用して (TOP x を介して耐えられる数まで) 可能性のある候補のプールを取得し、正規表現を使用してこれらのブルート フォース検索を行います。それは非常にうまく機能します。

于 2009-02-06T08:54:36.097 に答える
0

Apache Solrを見てください。Lucene を HTTP インターフェイスでラップする検索サーバーです。各フレーズは、Solr ドキュメントにマップされます。ドキュメントは非常に短いため、Solr にとって 30M のドキュメントは多くありません。最終的なパフォーマンスは、必要な 1 秒あたりのクエリ数にも依存します。

于 2009-06-29T18:51:09.260 に答える
0

すぐに使用できるソリューションとして、ドキュメントのコンテンツ内のインデックス作成と検索に「Microsoft Office SharePoint Server」を使用することをお勧めします。インデックス作成と検索のための独自のサービスを作成する場合、無料の代替手段は Lucene.Net ライブラリです。Lucene.Net を使用して独自の全文検索サービスを作成すると、必要なすべての柔軟性が得られます (必要に応じて、インデックスを外部ストレージに保存できます)。

于 2009-02-06T15:50:33.230 に答える