問題タブ [freetext]

私は2つのテーブルを持っています:

Product テーブルには約 120K のレコードがあります Brand テーブルには 30K のレコードがあります

特定のキーワードに一致する名前とブランドを持つすべての製品の数を見つける必要があります。

次のようにフリーテキストの「含む」を使用します。

このクエリには約17 秒かかります。 このクエリを実行する前に、FreeText インデックスを再構築しました。

Product.Name のみをチェックする場合。クエリは 1 秒未満です。Brand.Name のみを確認した場合も同様です。OR 条件を使用すると、問題が発生します。

LIKE を使用するようにクエリを切り替えると、次のようになります。

1秒かかります。

MSDN で読みました: http://msdn.microsoft.com/en-us/library/ms187787.aspx

複数のテーブルを検索するには、FROM 句で結合テーブルを使用して、2 つ以上のテーブルの積である結果セットを検索します。

そこで、INNER JOINED テーブルを FROM に追加しました。

この結果、次のエラーが発生します: 列 'ProductName' には、フルテキスト インデックスが作成されていないため、CONTAINS または FREETEXT 述語を使用できません。

問題は、なぜ OR 条件が遅いクエリなどを引き起こす可能性があるのか​​ということです。

Microsoft SQL Server 2005 には奇妙なバグがありFREETEXT()、照合では大文字と小文字が区別されないにもかかわらず、検索で大文字と小文字が多少区別されるようです ( Latin1_General_CI_AS)。

まず、LIKEクエリでは大文字と小文字が完全に区別されないため、

と

同じ結果を返します。

また、FREETEXT実際には、たとえば、ある程度大文字と小文字が区別されません。

異なるケースで結果を返します。

しかし

に対して大文字と小文字を区別しない一致を返す一方でword、異なる結果セットが得られます。または、調査の結果、 forwordを検索すると、さまざまなケースのすべての一致が得られますwordが、 を検索するとWord、同じ PLUS 屈折結果が得られることがわかりました。

または、私が見つけた実際のケースの 1 つを使用するにmarketingleaderは、大文字と小文字に関係なく、その単語を含むすべての結果を検索すると返されますが、検索するとそれらが返されますが、小文字を検索すると表示されないMarketingleaderものだけを含む結果も返されます。 leader.

これを引き起こしている原因と、小文字の単語の屈折/あいまい検索をオンにする方法について、誰かがアイデアを持っていますか?

どんな助けでも大歓迎です。

現在SQL2000サーバーで実行されているFreeText検索に問題があります。

会社名を含む約130万行のテーブルで、FreeTextクエリを使用しようとしています。ただし、SQL Serverはインデックスを作成するときに特殊文字と単一文字を削除するため、クエリを送信するときにコードは同じことを行います。

たとえば、「Texas A＆M」のような検索では、「Texas」をクエリするだけで、無関係なレコードが大量に返されます。

この種の検索クエリを処理するためのベストプラクティスは何ですか？この問題は、SQL Serverの新しいバージョンにアップグレードすることで修正できますか？

現時点では、Luceneのようなサードパーティのインデックス作成エンジンは、問題が解決したとしてもオプションではありませんが、私にはわかりません。

Productテーブルには700Kレコードが含まれています。クエリ：

SELECT TOP 1 ID, Name FROM Product WHERE contains(Name, '"White Dress"') ORDER BY DateMadeNew desc

実行には約1分かかります。DateMadeNewには非クラスター化インデックスがあり、NameにはFreeTextインデックスがあります。

TOP1またはOrderByを削除すると、実行に1秒もかかりません。

実行計画へのリンクは次のとおりです。 http://screencast.com/t/ZDczMzg5N

FullTextMatchには400Kを超える実行があるようです。なぜこうなった？どうすればもっと速くできますか？

2010年5月3日更新

カーディナリティは、複数単語のFreeText検索ではうまくいかないようです。

オプティマイザーは、「ホワイトドレス」に一致する28Kのレコードがあると推定していますが、実際には1つしかありません 。http：//screencast.com/t/NjM3ZjE4NjAt

「白いドレス」を「白い」に置き換えると、推定数は「27,951」ですが、実際の数は「28,487」であり、はるかに優れています。

オプティマイザーは、カーディナリティを検索するフレーズの最初の単語のみを使用しているようです。

約 6 ～ 7 個の結合テーブルと、WHERE のベース テーブルの 6 列に対する FREETEXT() 述語を含むクエリがあります。

現在、このクエリは昨年 (2 秒未満で) 正常に機能し、実質的に変更されていません (古いバージョンを試してみましたが、問題は解決しません)。

そのため、今日、突然、同じクエリに約 1 ～ 1.5 分かかりました。

SQL Server 2005 で実行計画を確認した後、そのテーブルの FULLTEXT インデックスを再構築し、FULLTEXT インデックスを再編成し、インデックスを最初から作成し、SQL Server サービスを再起動し、サーバー全体を再起動しました。

LIKEこれを理解するまで、代わりに使用するクエリを一時的に切り替えました（現在は約6秒かかります）。

クエリ パフォーマンス アナライザーでクエリを見ると、「FREETEXT」クエリと「LIKE」クエリを比較すると、前者の読み取り数は 350 倍 (4921261 対 13943)、20 倍 (38937 対 1938) です。後者のCPU使用率。

したがって、実際には「FREETEXT」述語が非常に遅くなります。

理由が何であるかについて誰かが何か考えを持っていますか? または、さらにテストを行うことができますか？

[編集]

さて、実行計画を取得するためにクエリを再度実行したところ、変更を加えることなく、再び 2 ～ 5 秒かかりましたが、昨日の問題はまだ存在していました。先週の木曜日に最初に問題をテストしたときに、データベースにアクセスするすべてのアプリケーションを停止したので、それは外的要因によるものではなく、他の負荷によるものではありませんでした.

まあ、実行計画はまだ含めますが、すべてが再び機能するようになったので、あまり役に立たないかもしれません...そして、これは変更できないレガシーデータベースへの巨大なクエリです（つまり、データを正規化したり、いくつかの不要な中間テーブルを取り除きます)

クエリ プラン

ここに完全なクエリがあります

それが正確に何をするのかを説明しなければならないかもしれません。基本的に、求人広告の検索結果を取得します。ここには、プレミアム広告と通常広告の 2 種類の広告があります。結果は 1 ページあたり 25 の結果にページ分割され、十分な数がある場合は、10 のプレミアム結果が一番上に、15 の通常の結果がその後に表示されます。

そのため、必要な数のプレミアム/ノーマル クエリを選択する 2 つの内部クエリがあり (たとえば、10 ページでは、上位 100 のプレミアム クエリと上位 150 の通常クエリをフェッチします)、これら 2 つのクエリは、row_number() コマンドといくつかの数学でインターリーブされます。 . 次に、組み合わせが行番号順に並べられ、クエリが返されます。別の場所で、現在のページに必要な 25 個の広告を取得するために使用されます。

ああ、このクエリ全体は巨大なレガシーColdfusionファイルで構築されており、うまく機能しているので、これまでのところ大部分を触れたり変更したりすることはできませんでした...実行中のシステムなどには触れないでください;）変更などの小さなものだけです中央の where 節のビット。

このファイルは、基本的に同じことを行う他のクエリも生成しますが、プレミアム/非プレミアムの区別と、このクエリの他の多くのバリエーションがないため、それらの1つを変更すると他のクエリがどのように変更されるかはわかりません.. .

問題が再び表面化していないので、マーティンに賞金を与えました。彼はこれまでで最も役に立ち、賞金が不必要に期限切れになりたくなかったからです。他の皆さんの努力に感謝します。また同じことが起こったら、あなたの提案を試してみます :)

関連リンクセクションのような機能を作りたい小さなウェブサイトを運営しています。

そのために、フルテキスト カタログとインデックスを作成しました。

これまでのところ、Google のように動作する検索クエリを作成するために多くの方法を試しましたが、Google が行っていることに 10% も近づいていなかったと言えます。私の調査中に私が見つけたのは、次のクエリだけが良いレコードを引き出していることでした。

特定のテキストのより良い関連レコードを取得するのに役立つ全文検索クエリを作成する良い方法はありますか?

ありがとう

現在、最大 2 ミルのレコードで非常に高速な検索を実行する必要があるアプリケーションがあります。

検索では、さまざまな関数/計算と並べ替えに加えて、大きなフリーテキスト フィールドと、さまざまな範囲の整数/小数フィールドの両方を検索する必要があります。

現在、これは大規模な MSSQL データベースで処理されており、組み込みのフリーテキスト エンジンとレプリケーションを使用して、トランザクション テーブルから負荷を移動しています。

ただし、ご想像のとおり、このソリューションは最もスケーラブルではありません。

私は小さな Lucene ベースのドキュメント ストアを作成しましたが、一般的に結果に非常に感銘を受けており、テキスト検索の所要時間は 1/2 秒 (100,000 レコードの場合) よりも長くはありません。

難点はパラメトリック検索です。Lucene が基本的な範囲マッチングを行うことは知っていますが、もっと強力なものが必要だと感じています。

強力なクエリ機能を備えた db4o を使用して小さなテスト データベースを作成しましたが、これらのクエリは非常に遅く、わずか 10 万レコードで 15 秒以上かかります。SQL ではフリーテキストとパラメトリック検索に約 1.5 秒かかります。

また、私たちのデータベースは 10 分未満の更新解像度を持つ必要があり、レコードの約 15% が毎日変更されます。私たちの SQL サーバーは現在これを処理していますが、きしみ始めています。

適切な技術とアプローチに関するガイダンスをいただければ幸いです。

乾杯、デイブ

現在、ナレッジベースアプリを構築している最中であり、ドキュメント情報を保存してインデックスを作成するための最良の方法が少しわかりません。

ユーザーはドキュメントをアップロードします。その際、ドロップダウンリストからいくつかのオプション（カテゴリ、トピック、エリアなど、これらはすべて必須ではないことに注意してください）を選択し、いくつかのキーワードとドキュメントの説明も入力します。現時点では、選択されたカテゴリ（およびその他）は、カテゴリテーブルのIDを使用して、ドキュメントテーブルに外部キーとして保存されます。私たちができるようにしたいのは、ドキュメントが配置されているvarchar（max）列内の情報だけでなく、カテゴリ名、トピック名、エリア名などについてもFREETEXTTABLEまたはCONTAINSTABLEを実行することです。

インデックス付きビューを作成するオプションを検討しましたが、カテゴリ列に対するLEFT JOINが原因で、これは不可能でした。ですから、これを実行できるようにする方法がわかりません。どんなアイデアでも大歓迎です。

私はいくつかの機能を実装する必要がある検索を構築しています。

1- 誰かがソファを検索した場合など、すべての同義語が表示される必要があります。そのソファに一致する結果と、言語の一致 (ソファ、クッションなど) が表示される必要があります。それを達成するために、全文検索を使用しています。

私のクエリでは FreeText を使用していますが、必要な結果が得られません。それが私がすることです、

もちろん、クッション、ソファ、カウチを含む名前を表示する必要がありますが、カウチを含む名前のみを表示します。これは、単純な Like クエリでも実行できます。解決策はありますか？

2-タイプミスをチェックする必要があります。たとえば、誰かが入力した場合soofa、ソファ、カウチなどの結果が表示されるはずです。

これを達成するためのヒントやアイデアはありますか? 前もって感謝します。

SQL Server 2008にフルテキストのインデックス付きテーブルがあり、FULLTEXTを使用して完全に一致するフレーズをクエリしようとしています。CONTAINSまたはLIKEの使用がこれに適しているとは思いません。他の場合、クエリが正確でない可能性があり（ユーザーがフレーズを二重引用符で囲まない）、一般にFREETEXTの柔軟性が必要だからです。

FREETEXTのドキュメント[MSDN]によると：

freetext_stringが二重引用符で囲まれている場合、代わりにフレーズ一致が実行されます。ステミングとシソーラスは実行されません。

これは私にこのようなクエリを信じさせるでしょう：

[説明]フィールドに「市庁舎」という用語が表示されている場合にのみ結果が返されますが、代わりに次のような結果が得られます。

1マニングホールのハンディキャップランプの設計。
2アンテナ調査。クライアント：City of Cranston EngineeringDept.3
国際テニス殿堂の火災による被害に関する構造調査。
4調査ヘラルドホールで提案された衛星設計のための屋根調査。
...など

明らかに、これらの結果には、私のフレーズの少なくとも1つの単語が含まれていますが、フレーズ自体は含まれていません。さらに悪いことに、結果はランク付けされると思っていましたが、実際に必要だった2つの結果（実際のフレーズが含まれているため）は埋もれています。

1マサチューセッツ州クインシーの既存の市庁舎の大規模な外装と内装の改修
2漏れに悩まされているポータケット市庁舎の塔の大まかな構造調査。

これは私がドキュメントを理解していない場合だと確信していますが、私が探しているものを達成する方法はありますか？つまり、引用符なしで検索文字列を渡して、現在取得しているものを正確に取得したり、引用符を使用して正確なフレーズのみを取得したりできるようにするにはどうすればよいでしょうか。