タグ付けされた質問 「full-text-search」

ドキュメントのコレクションのテキストまたはデータベース内のフリーテキストフィールドを検索して、単語または単語の組み合わせを含むものを見つけます。

2
SQL Serverフルテキストインデックスを有効にした後、クエリの更新が遅くなる
asp.net Webサイトで、データベースに対して実行される挿入、更新、削除のクエリが多数あります。 数日前に、1つのテーブルの2つの列にフルテキストインデックスを作成します。その後、Webサイトがそのテーブルに対して更新クエリを実行すると、SQL Serverプロセスのメモリとディスクの使用量が急激に増加し、更新が遅くなることがわかりました。クエリは、フルテキストインデックスを作成する前に、パフォーマンスの問題なしに実行されました。 以前は非常に単純だった更新クエリが複雑になっていることにも気づきました。これは、実行プランに全文インデックスの更新などがあるためです。これは、フルテキストを有効にした後に複雑になった新しい実行プランの一部です。 サイトのコンテンツを更新する数時間で、5000の更新クエリを実行しました。フルテキストインデックス処理は、各行で毎回行われると思います。 行の更新の開始時に全文スキャンを無効にしてから、再度有効にする必要がありますか(この関連質問のように)? SQL Serverにフルテキストインデックス作成を5分間停止してから、新しいデータのインデックス作成を開始するように指示できますか? より良い代替手段はありますか?SQL Server 2012を使用しています。

2
行の見積もりが大幅に不正確であるため、フルテキスト検索が遅い
このデータベースに対するフルテキストクエリ(RT(リクエストトラッカー)チケットを格納する)は、実行に非常に長い時間がかかるようです。添付ファイルテーブル(フルテキストデータを含む)は約15GBです。 データベーススキーマは次のとおりで、約200万行です。 rt4 =#\ d +添付ファイル テーブル "public.attachments" コラム| タイプ| 修飾子| ストレージ| 説明文 ----------------- + ----------------------------- +- -------------------------------------------------- ------ + ---------- + ------------- id | 整数| nullではないデフォルトのnextval( 'attachments_id_seq' :: regclass)| プレーン| transactionid | 整数| nullではない| プレーン| 親| 整数| nullではないデフォルト0 | プレーン| メッセージID | キャラクター変化(160)| | 拡張| 件名| 文字の変化(255)| | 拡張| …

1
各テーブルではなく、統合クエリからMATCH()AGAINST()スコアを計算します
SELECTステートメントのセクション全体のスコアを取得しようとしています SELECT *,MATCH(`result`) AGAINST('keyword') as `score` FROM `table1` WHERE MATCH(`result`) AGAINST('keyword') UNION SELECT *,MATCH(`content`) AGAINST('keyword') as `score` FROM `table2` WHERE MATCH(`content`) AGAINST('keyword') UNION SELECT *,MATCH(`text`) AGAINST('keyword') as `score` FROM `table3` WHERE MATCH(`text`) AGAINST('keyword') そのような場合、スコアはテーブルごとです+それらは関連性によって順序付けされていません しかし、私はこの方法を試しました、それは機能していますが、生産の価値はありません SELECT * FROM ( SELECT *,MATCH(`result`) AGAINST('keyword') as `score` FROM `table1` WHERE MATCH(`result`) AGAINST('keyword') UNION …

1
全文検索でLIKEよりも少ない行が返される理由
全文検索が期待どおりに機能せず、結果リストの違いがわかりません。 ステートメントの例: SELECT `meldungstext` FROM `artikel` WHERE `meldungstext` LIKE '%punkt%' 92行を返します。たとえば、 "Punkten"、 "Zwei-Punkte-Vorsprung"、 "Treffpunkt"などの一致する行がmeldungstext列に表示されます。 「meldungstext」列にフルテキストインデックスを設定し、これを試しました。 SELECT `meldungstext` FROM `artikel` WHERE MATCH (`meldungstext`) AGAINST ('*punkt*') これは8行のみを返します。「Punkt」自体に一致する行、または「i-Punkt」のように「Punkt」と見なされると思われる単語のみを受け取ります。 次にブールモードを試しました: SELECT `meldungstext` FROM `artikel` WHERE MATCH (`meldungstext`) AGAINST ('*punkt*' IN BOOLEAN MODE) 44行を返します。meldungstext列に「Zwei-Punkte-Vorsprung」または「Treffpunkt」を含む行が表示されますが、「Punkten」の行は表示されません。 なぜこれが発生し、「完全に」機能する全文検索を設定して、where句でLIKE '%%'を使用しないようにするにはどうすればよいですか?

2
複数列のPostgres全文検索、なぜ実行時ではなくインデックスで連結するのですか?
ここ数日、postgresで全文検索を行ったことがありますが、複数の列を検索するときのインデックス付けについて少し混乱しています。 postgresのドキュメントではts_vector、次のように、連結された列にインデックスを作成する方法について説明しています。 CREATE INDEX pgweb_idx ON pgweb USING gin(to_tsvector('english', title || ' ' || body)); 私はそのように検索できます: ... WHERE (to_tsvector('english', title||' '||body) @@ to_tsquery('english', 'foo')) ただし、タイトルだけ、本文だけ、または両方を検索する場合は、3つの個別のインデックスが必要になります。そして、3番目の列に追加すると、6つのインデックスになる可能性があります。 私がドキュメントで見たことのない別の方法は、2つの列に別々にインデックスを付けてから、通常のWHERE...ORクエリを使用することです。 ... WHERE (to_tsvector('english', title) @@ to_tsquery('english','foo')) OR (to_tsvector('english', body) @@ to_tsquery('english','foo')) 100万行までの2つをベンチマークしても、基本的にパフォーマンスに違いはないようです。 だから私の質問は: 列を個別にインデックス付けするだけでなく、このようにインデックスを連結したいのはなぜですか?両方の長所と短所は何ですか? 私の推測では、事前に両方の列だけを検索したい場合(一度に1つずつではない)は、どちらが少ないメモリを使用するかを連結することで1つのインデックスしか必要としないでしょう。

2
「LIKE OR LIKE、OR LIKE、OR LIKE、OR LIKE」のより良いアプローチ
この質問では、彼は私と同じ問題を抱えています。私は次のようなものが必要です: select * from blablabla where product like '%rock%' or like '%paper%' or like '%scisor%' or like '%car%' or like '%pasta%' これは醜く、インデックスを使用していません。この場合、これは実際にこれを行う唯一の方法です(文字列内の複数の単語を選択するため)、またはFULLTEXTを使用する必要がありますか? 私が理解しているように、フルテキストでは、文字列内の複数の単語を選択できます。 この質問は全文についても話します

1
フルテキスト:複数のフルテキストインデックスが作成された後、多数のFT_MASTER_MERGEがSUSPENDED状態で待機します(サーバーがハングします)
10個のデータベース、各データベースに100個の異なるスキーマ、各スキーマに10個の小さな(約50行)テーブル(合計で10K個のテーブル)があり、これらすべてにフルテキストインデックスを作成したときに、SQL Server 2014でテストを行いましたこれらすべてのデータベースのテーブルを同時に。 数分後に、SQL Serverが接続(ADMIN:.接続以外)を受け入れるために停止したことがわかりました。サーバーを再起動すると接続できますが、しばらくするとハングします。いくつかの調査の後、我々は、それがすべての作業スレッドを消費によって引き起こされることを見出し、dm_os_tasksおよびdm_os_waiting_tasksロットがあることを私たちに示したFT_MASTER_MERGEで待機SUSPENDED状態。「フルテキストはマスターマージ操作を待機しています」とグーグル検索しましたが、それに関する実際の情報は見つかりませんでした。 さまざまなフルテキストカタログ構成を試しました。DBごとに1つのカタログ、スキーマごとに1つのカタログ、インデックスごとに1つのカタログです。とにかく、サーバーはこれらすべての中断されたタスクでハングします。 待機の根本的な原因は何ですか?これをどのように修正/緩和できますか? そして、そのような大量のテーブルでフルテキストを有効にするための推奨される方法は何ですか?

2
SQL Server Filetableドキュメントのプロパティ
SQL Server 2012のFiletableを使用してドキュメントを保存し、セマンティック検索で検索しています。 すべてのドキュメントプロパティ(メタデータ)を一覧表示する方法があるかどうか疑問に思いました。フルテキスト検索でインデックスを作成し、ドキュメントのプロパティを検索する方法があります。次のステートメントを使用して、SQL Serverインデックスのプロパティのリストを作成できます。 SELECT * FROM sys.registered_search_properties; SQLまたはプログラムを使用して、このリストを拡張することもできます。 見つからなかったのは、実際の情報をリストする方法です。私が探しているのは次のようなリストです: 著者:Ruud van de Beeten タイトル: テスト文書 カスタムプロパティ:カスタム値 誰かが私を正しい方向に向けることができますか? 編集:ボブボーケミンが私の問題を説明するチケットを作成しました。DMVはプロパティ値をリストしていないため、プロジェクトで使用できません。 最終的にC#を使用して、OleDocumentPropertiesオブジェクトでカスタムプロパティを一覧表示しました。このオブジェクトは、Officeドキュメントからプロパティを読み取ることができます。私はより良い解決策を期待して、この質問を監視し続けます。

1
where句で 'contains'と '='を一緒に使用するとクエリが遅くなる
次のクエリは、12kレコードのテーブルで完了するまでに約10秒かかります select top (5) * from "Physician" where "id" = 1 or contains("lastName", '"a*"') しかし、where句を次のいずれかに変更した場合 where "id" = 1 または where contains("lastName", '"a*"') すぐに戻ります。 両方の列にインデックスが付けられ、lastName列にもフルテキストインデックスが付けられます。 CREATE TABLE Physician ( id int identity NOT NULL, firstName nvarchar(100) NOT NULL, lastName nvarchar(100) NOT NULL ); ALTER TABLE Physician ADD CONSTRAINT Physician_PK PRIMARY …

2
出現頻度の高い用語の低速全文検索
テキスト文書から抽出されたデータを含むテーブルがあります。データは、"CONTENT"GINを使用してこのインデックスを作成したという名前の列に保存されます。 CREATE INDEX "File_contentIndex" ON "File" USING gin (setweight(to_tsvector('english'::regconfig , COALESCE("CONTENT", ''::character varying)::text), 'C'::"char")); 次のクエリを使用して、テーブルで全文検索を実行します。 SELECT "ITEMID", ts_rank(setweight(to_tsvector('english', coalesce("CONTENT",'')), 'C') , plainto_tsquery('english', 'searchTerm')) AS "RANK" FROM "File" WHERE setweight(to_tsvector('english', coalesce("CONTENT",'')), 'C') @@ plainto_tsquery('english', 'searchTerm') ORDER BY "RANK" DESC LIMIT 5; ファイルテーブルには250 000行が含まれ、各"CONTENT"エントリは1つのランダムな単語とすべての行で同じテキスト文字列で構成されます。 ここで、ランダムな単語(テーブル全体で1ヒット)を検索すると、クエリは非常に高速に実行されます(<100ミリ秒)。ただし、すべての行にある単語を検索すると、クエリの実行が非常に遅くなります(10分以上)。 EXPLAIN ANALYZEは、1ヒット検索の場合、ビットマップインデックススキャンとそれに続くビットマップヒープスキャンが実行されることを示しています。遅い検索では、代わりにSeq Scanが実行されますが、これは非常に時間がかかっています。 もちろん、すべての行に同じデータを含めることは現実的ではありません。しかし、ユーザーがアップロードしたテキストドキュメントやユーザーが実行する検索を制御できないため、同様のシナリオが発生する可能性があります(DBで非常に出現頻度の高い用語で検索)。このようなシナリオで検索クエリのパフォーマンスを向上させるにはどうすればよいですか? PostgreSQL 9.3.4の実行 クエリプランEXPLAIN …

1
類似性関数の最適なインデックス
したがって、このテーブルには620万件のレコードが含まれており、列の類似性を使用して検索クエリを実行する必要があります。クエリは次のとおりです。 SELECT "lca_test".* FROM "lca_test" WHERE (similarity(job_title, 'sales executive') > 0.6) AND worksite_city = 'los angeles' ORDER BY salary ASC LIMIT 50 OFFSET 0 where(year = X、worksite_state = N、status = 'certified'、visa_class = Z)にさらに条件を追加できます。 これらのクエリの一部を実行すると、30秒を超える非常に長い時間がかかる場合があります。時々1分以上。 EXPLAIN ANALYZE 前述のクエリの私にこれを与えます: Limit (cost=0.43..42523.04 rows=50 width=254) (actual time=9070.268..33487.734 rows=2 loops=1) -> Index Scan using index_lca_test_on_salary …

1
全文索引とスカラーインデックスの組み合わせ
たとえば、全文を使用して検索できる必要のある1200万人の名前と住所のデータベースがあるが、各行には整数値も含まれているとしCOMPANYIDます。テーブルには、1,200万行を超える約250の個別のCOMPANYIDが含まれています。 フルテキストインデックスを定義するときCOMPANYに、ツリーにそれぞれ独自の「ブランチ」を与えることは可能ですか?


3
全文検索クエリでのORDER BYの最適化
entities1500万レコードまでの大きなテーブルがあります。の「ホッケー」に一致する上位5行を見つけたいname。 に全文索引がありますname。これは次のように使用されます。gin_ix_entity_full_text_search_name クエリ: SELECT "entities".*, ts_rank(to_tsvector('english', "entities"."name"::text), to_tsquery('english', 'hockey'::text)) AS "rank0.48661998202865475" FROM "entities" WHERE "entities"."place" = 'f' AND (to_tsvector('english', "entities"."name"::text) @@ to_tsquery('english', 'hockey'::text)) ORDER BY "rank0.48661998202865475" DESC LIMIT 5 期間25,623ミリ秒 計画を説明する 1制限(コスト= 12666.89..12666.89行= 5幅= 3116) 2->ソート(コスト= 12666.89..12670.18行= 6571幅= 3116) 3ソートキー:(ts_rank(to_tsvector( 'english' :: regconfig、(name):: text)、 '' 'hockey' '' :: tsquery)) 4->エンティティに対するビットマップヒープスキャン(コスト= …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.