0
  • 関心のある 4 つのテキスト列があります。
  • 各列は約 100 文字までです。
  • 3 つの列のテキストは、ほとんどがラテン語です。（データは生物のカタログであり、これらは物の名前です。）
  • 現在、データは約 500 行です。これが1000を超えるとは思えません。
  • 少数のユーザー (10 人未満) には、データを追加、更新、および削除するための編集権限があります。これらのユーザーがデータベースに大きな負荷をかけるとは思いません。

したがって、これはすべて、考慮すべき非常に小さなデータセットを示唆しています。

少なくとも 1 列に検索テキストが含まれる行の 4 列すべてで検索を実行する必要があります (大文字と小文字は区別されません)。クエリは、Web アプリケーションを介して発行されます (および結果が提供されます)。私はそれにアプローチする方法について少し迷っています。

PostgreSQL には、テキスト検索速度を向上させるためのオプションがいくつか用意されています。私が検討してきた PostgreSQL に組み込まれている可能なオプションは次のとおりです。

  1. これをまったく索引付けしようとしないでください。ILIKE、LIKEonなどを使用しlowerてください。（インデックスなし？）
  2. 検索速度を向上させるために pg_trgm でインデックスを作成します。何らかの形で連結にインデックスを付ける必要があると思います。
  3. 全文検索。これには、インデックスの連結も含まれると思います。

残念ながら、私はこれらのいずれかの期待されるパフォーマンスや利点とトレードオフについてあまり詳しくないので、最初に何を試すべきで、何を考慮すべきでないかを知ることは困難です. 私が読んだいくつかのことは、2 と 3 のインデックス付けを行うのがかなり遅いことを示唆しています。また、言語が混在しているため、全文検索は魅力的ではないように見えます。複数の言語を同時に処理できない限り、言語ベースのように見えるからです。この小さなデータの場合、単純なILIKEまたはおそらくLIKEonlowerで十分に高速であると期待できますか? それとも、これほど小さなデータに対する変更の負荷が低いのに、インデックス作成は十分に高速なのでしょうか? データベース以外のものを探した方がよいでしょうか?

確かに、これらすべてを実際にベンチマークして、何が最速かを確認する必要がありますが、残念ながら、このプロジェクトにはあまり時間がありません。では、これらの方法の利点とトレードオフは何ですか? この種の問題を解決するのに適切でないオプションはどれですか? 検討する価値のある他のタイプのソリューション (データベース外の可能性を含む) は何ですか?

(PG でのテキスト検索に関するある種の初心者向けチュートリアルが役立つと思うかもしれませんが、私の検索ではほとんどの場合、全文検索が表示されます。それが私にとって役立つかどうかさえわかりません。)

私は PG 9.2.4 を使用しているため、9.3 より前の機能はオプションです。

4

2 に答える 2

3

更新: この回答を詳細なブログ投稿に拡張しました。

純粋に速度を重視するのではなく、まず検索のセマンティクスを考慮してください。要件を定義します。

たとえば、ユーザーは用語の順序に基づいて区別できる必要がありますか? したほうがいい

radiata pinus

探す：

pinus radiata

? 列間の単語と同じ規則が列内の単語に適用されますか?

スペースは常に単語の区切り文字ですか、それとも検索語の列部分内のスペースですか?

ワイルドカードは必要ですか? もしそうなら、左アンカーのワイルドカードだけが必要ですか ( と考えstaph%てください)、それとも右アンカーまたは挿入ワイルドカード ( %ccus, p%s) も必要ですか? 中置pg_tgrmワイルドカードでのみ役立ちます。サフィックスのワイルドカードは、単語のインデックスで処理できますが、reverse()すぐに扱いにくくなるため、実際pg_tgrmには最適なオプションです。

to_tsvector主に個別の単語を検索していて、単語の順序が重要でない場合は、 andを使用した Pg の全文検索to_tsqueryが望ましいでしょう。左アンカーのワイルドカード検索、重み付け、カテゴリなどをサポートしています。

主に個別の列のプレフィックス検索を行っている場合は、列LIKEごとの通常の b ツリー インデックスに対する単純なクエリが適しています。

そう。何が必要かを考えてから、それをどのように行うか。あなたの現在の不確実性は、おそらく、自分が何を望んでいるのかをよくわかっていないことに部分的に起因しているのでしょう。

于 2013-08-26T08:12:07.617 に答える
1

LIKE1000行の場合、と一緒にするとlower()十分に高速になると思います。数回のクエリの後、テーブルはおそらく完全にキャッシュされます。

pg_trgm を使用したインデックス作成について: テーブルへの「時折の」更新/挿入について話している。トリグラム インデックスを使用することによる追加コストは、そのテーブルを頻繁に更新/挿入した場合 (1 秒間に数回など) にのみ発生すると思います。

「ときどき」が 1 時間に数回 (またはそれ以下) だけを意味する場合、実際のライブで違いがわかるとは思えません。Depesz のブロブのどこかに、トライグラム インデックスがある場合とない場合の挿入速度を比較した記事もあったと思いますが、もう見つかりません。

于 2013-08-26T08:01:05.537 に答える