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

私は次のようなテーブルを使用して、MySqlデータベースで作業しています。 +--------------+ | table_name | +--------------+ | myField | +--------------+ ...そして、私はこのような多くのクエリを作成する必要があります（リストに5〜10文字列）： SELECT myField FROM table_name WHERE myField IN ('something', 'other stuff', 'some other a bit longer'...) 約24.000.000の一意の行があります 1）FULLTEXTまたはにINDEXキーを使用する必要がありますVARCHAR(150)か？ 2）文字を150から220または250に増やした場合、大きな違いが生じますか？（それを計算する方法はありますか？） 3）私が言ったように、それらはユニークになるので、myFieldはPRIMARY KEYでなければなりません。すでにVARCHAR INDEX / FULLTEXTであるフィールドにPRIMARY KEYを追加することはまれではありませんか？

40 mysql  index  full-text-search  varchar 

GoogleやYahooが非常に大量のデータに対してキーワードを検索する方法を知っている人はいますか？このためにどのような種類のデータベースまたはテクノロジーを採用していますか？ 数ミリ秒かかりますが、10億ページ以上のインデックスが作成されています。

32 database-design  full-text-search 

フルテキストインデックスを維持するには、どのガイドラインを考慮する必要がありますか？ フルテキストカタログを再構築または再編成する必要があります（BOLを参照）。合理的なメンテナンスケイデンスとは何ですか？どのようなヒューリスティック（10％および30％の断片化しきい値に類似）を使用して、メンテナンスが必要かを判断できますか？ （以下はすべて、質問について詳しく説明し、これまでに考えたことを示す追加情報です。） 追加情報：最初の調査 Bツリーインデックスのメンテナンスに関するリソースは多数あります（たとえば、この質問、Ola Hallengrenのスクリプト、および他のサイトの主題に関する多数のブログ投稿）。ただし、これらのリソースのいずれも、フルテキストインデックスを維持するための推奨事項またはスクリプトを提供していないことがわかりました。 ベーステーブルのBツリーインデックスを最適化し、フルテキストカタログでREORGANIZEを実行するとパフォーマンスが向上する可能性があることを記載したMicrosoftのドキュメントがありますが、それ以上の具体的な推奨事項については触れていません。 私もこの質問を見つけましたが、それは主に変更追跡（基になるテーブルへのデータ更新がフルテキストインデックスに伝播される方法）に焦点を当てており、インデックスの効率を最大化できるタイプの定期的なメンテナンスではありません。 追加情報：基本的なパフォーマンステスト このSQL Fiddleには、AUTO変更追跡を伴うフルテキストインデックスを作成し、テーブル内のデータが変更されたときのインデックスのサイズとクエリパフォーマンスの両方を調べるために使用できるコードが含まれています。（フィドルの人工的に製造されたデータとは対照的に）生産データのコピーでスクリプトのロジックを実行すると、各データ変更ステップの後に表示される結果の概要は次のとおりです。 このスクリプトの更新ステートメントはかなり不自然でしたが、このデータは定期的なメンテナンスによって多くのことが得られることを示しているようです。 追加情報：最初のアイデア 毎晩または毎週のタスクを作成することを考えています。このタスクは、REBUILDまたはREORGANIZEを実行できるようです。 フルテキストインデックスは非常に大きい（数千または数億行）可能性があるため、カタログ内のインデックスがREBUILD / REORGANIZEが保証されるほど十分に断片化されていることを検出できるようにしたいと思います。ヒューリスティックがそのために何を意味するのか、私には少しわかりません。

29 sql-server  full-text-search  index-maintenance 

LIKE演算子が現在のデータベースシステム（MySQLやPostgresなど）にどのように実装されているかを説明できますか？またはそれを説明するいくつかの参照を教えてください？ 素朴なアプローチは、各レコードを検査し、対象フィールドで正規表現または部分的な文字列の一致を実行することですが、これらのシステムがよりスマートに動作することを感じています。

22 mysql  postgresql  performance  full-text-search  pattern-matching 

Postgres 9.1データベースには、table1約150万行と1列のテーブルがありますlabel（この質問のために簡略化された名前）。 機能的なtrigram-indexがありますlower(unaccent(label))（インデックスでunaccent()使用できるように不変にされています）。 次のクエリは非常に高速です。 SELECT count(*) FROM table1 WHERE (lower(unaccent(label)) like lower(unaccent('%someword%'))); count ------- 1 (1 row) Time: 394,295 ms ただし、次のクエリは遅くなります。 SELECT count(*) FROM table1 WHERE (lower(unaccent(label)) like lower(unaccent('%someword and some more%'))); count ------- 1 (1 row) Time: 1405,749 ms また、検索がより厳密であっても、単語の追加はさらに遅くなります。 私は最初の単語のサブクエリを実行し、次に完全な検索文字列でクエリを実行する簡単なトリックを試しましたが、クエリプランナは（悲しいことに）私の陰謀を見ました： EXPLAIN ANALYZE SELECT * FROM ( SELECT id, …

16 postgresql  full-text-search  postgresql-9.1  postgresql-9.4  pattern-matching 

運用サーバーの1つがログのエラーを報告しています エラー：701、重大度：17、状態：123。 このクエリを実行するには、リソースプール '内部'にシステムメモリが不足しています。 このエラーを検索しましたが、バグであり、Service Pack 2にホットフィックスがあります。これらはサーバーの詳細です。 Microsoft SQL Server 2008 R2（SP2）-10.50.4000.0 Standard Edition（64ビット） プロセッサー数：24（2つのNUMAノード、それぞれ12コア） メモリ：24 GB RAMがSQL Serverに割り当てられています。 クエリバッチロード/分：5000以上 私の質問は なぜこのエラーが発生するのですか？ それは深刻な問題ですか？ どうすれば解決できますか？ メモリステータスの編集： MEMORYBROKER_FOR_RESERVE (internal) Pages ---------------------------------------- ---------- Allocations 200362 Rate 4510 Target Allocations 200362 Future Allocations 588626 Overall 2521497 Last Notification 0 MEMORYBROKER_FOR_STEAL (internal) Pages ---------------------------------------- ---------- …

15 sql-server  sql-server-2008-r2  full-text-search 

これをクエリして結果を取得したい： SELECT * FROM ( SELECT id, subject FROM mailboxes WHERE tsv @@ plainto_tsquery('avail') ) AS t1 ORDER by id DESC; これは機能し、をtsv含む行を返しますAvailable。しかし、私が使用avai（ドロップlable）した場合、何も見つかりません。 すべてのクエリは辞書にある必要がありますか？このような文字だけを照会することはできませんか？電子メールの本文（コンテンツ）を含むデータベースがあり、毎秒成長するにつれて高速にしたいと思います。現在使用しています ... WHERE content ~* 'letters`

13 postgresql  full-text-search  pattern-matching 

当社のWebサイトには、Webサイト検索用のフルテキストインデックスを備えたSQL Server 2008 R2 Express Editionデータベースがあります。インデックスが作成されたテーブルの1つで新しいレコードが追加または更新されるたびに、インデックス作成プロセスが完了しないようです。 このサイトで見つかった基本的に同じクエリを使用して、過去数週間にわたってステータスを監視しています：http : //www.sqlmonster.com/Uwe/Forum.aspx/sql-server-search/2155/Why-is-this -人口がかかるほど長い これは、クエリを実行したときに表示されるものです（クリックするとフルサイズになります）。 インデックス付きテーブル内の最新のレコードは完全なものではなく、検索できません。テーブルにあまり多くのデータはありませんが、インデックス作成が完了するかどうかを確認するために何日も待機しましたが、何も変化しません。 インデックス作成を正常に完了することができる唯一の方法は、カタログを再構築するか、すべてのインデックスを削除して再作成することです。 私がそれをするたびに、最初の新しいレコードが追加されるとすぐに同じ問題が再発します。 念のため、サーバーの統計を以下に示します。 クアッドコアAMD Opteron 2.34GHz 4GB RAM Windows Server 2008 R2 Enterprise SP1 x64 SQL Server 2008 R2 Express Edition with Advanced Services x64

13 sql-server  sql-server-2008-r2  full-text-search  sql-server-express 

したがって、次のjsonbようなエントリを持つ列があります：https : //pastebin.com/LxJ8rKk4 jsonb列全体に全文検索を実装する方法はありますか？

13 postgresql  full-text-search  json 

現在、Stack Overflowのコメントのデータダンプに対していくつかのクエリを実行しようとしています。スキーマは次のようになります。 CREATE TABLE `socomments` ( `Id` int(11) NOT NULL, `PostId` int(11) NOT NULL, `Score` int(11) DEFAULT NULL, `Text` varchar(600) NOT NULL, `CreationDate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `UserId` int(11) NOT NULL, PRIMARY KEY (`Id`), KEY `idx_socomments_PostId` (`PostId`), KEY `CreationDate` (`CreationDate`), FULLTEXT KEY `Text` (`Text`) ) ENGINE=InnoDB …

12 mysql  innodb  full-text-search 

フルテキストインデックスを最新の状態に保つためのデータベーステーブルがあります。ただし、これが発生しているのはまったくわかりません（最後に表示されたログは手動でトリガーしたときだったため、ログにエラーはありません）。 これが私が見ているものです... テーブルの上に... これが自動的に行われない理由ですか？

12 sql-server-2012  index  full-text-search  change-tracking 

私はこれを取得していません。 これらのインデックスを持つテーブルがあります PRIMARY post_id INDEX topic_id FULLTEXT post_text テーブルには（のみ）346 000行があります。2つのクエリを実行しようとしています。 SELECT post_id FROM phpbb_posts WHERE topic_id = 144017 AND post_id != 155352 AND MATCH(post_text) AGAINST('http://rapidshare.com/files/5494794/photo.rar') 4.05秒かかります SELECT post_id FROM phpbb_posts WHERE topic_id=144017 AND post_id != 155352 AND post_text LIKE ('%http://rapidshare.com/files/5494794/photo.rar%') 0.027秒かかります。 EXPLAINは、唯一の違いがpossible_keysにあることを示しています（fulltextpost_textが含まれていますが、含まれてLIKEいません） それは本当に奇妙です。 この背後にあるものは何ですか？バックグラウンドで何が起こっていますか？LIKEインデックスを使用していない場合はどのように高速になり、インデックスを使用している場合はFULLTEXTが非常に遅くなりますか？ アップデート1： 実際には約0.5秒かかりますが、テーブルがロックされた可能性がありますが、プロファイリングをオンにすると、FULLTEXT INITIALIZATIONに0.2秒かかったことが示されます。調子はどう？ 1 LIKE秒あたり10倍、フルテキストは2倍でテーブルをクエリできます UPDATE2： …

12 mysql  full-text-search 

SQL Server 2014 Expressエディションと高度なサービスをインストールしました。全文検索機能を試してみたいと思っていました。ここで、全文検索が2014 Express Editionでサポートされていることを読みました。しかし、フルテキストインデックスをインストールして作成しようとすると、このバージョンのSQLサーバーではフルテキストインデックスがサポートされていないというエラーが表示されます。 全文索引は実際にサポートされていますか？間違ったバージョン（高度なサービスではない）をインストールする可能性はありますか？念のため、アンインストールと再インストールを2回行いましたが、どちらも同じ問題です。Advanced Servicesインストーラーを使用してインストールすることに同意します。 Windows 7、64ビットを使用しています。

11 sql-server  full-text-search  sql-server-agent 

SQL Server Management Studioを使用して、新しいデータベース、いくつかのテーブル、フルテキストインデックスとカタログを問題なく作成しました。私は、それぞれのT-SQL作成スクリプトをコピーして、ドキュメントに含めたかったのです。データベース、テーブル、外部キー、およびカタログの作成スクリプトを取得できますが、フルテキストインデックスが見つからないようです。私は関連するテーブルのスクリプトテーブルを次のようにチェックしました-> CREATE Toであり、そこにもありませんし、カタログにもありません。何か案は？SQL Server Standardエディションのみを実行しているためですか？

11 full-text-search  ssms 

私はこのクエリを持っています： SELECT * FROM location WHERE to_tsvector('simple',unaccent2("city")) @@ to_tsquery('simple',unaccent2('wroclaw')) order by displaycount 私はそれに満足しています： "Sort (cost=3842.56..3847.12 rows=1826 width=123) (actual time=1.915..2.084 rows=1307 loops=1)" " Sort Key: displaycount" " Sort Method: quicksort Memory: 206kB" " -> Bitmap Heap Scan on location (cost=34.40..3743.64 rows=1826 width=123) (actual time=0.788..1.208 rows=1307 loops=1)" " Recheck Cond: (to_tsvector('simple'::regconfig, unaccent2((city)::text)) …

11 postgresql  performance  index  full-text-search