3

FTS クエリをページ分割する最良の方法は何ですか? LIMITとOFFSET思い浮かびます。ただし、制限とオフセットを使用すると、同じクエリを何度も実行することになるのではないかと心配しています (つまり、ページ 1 で 1 回、ページ 2 で 1 回など)。

PostgreSQL は、クエリ結果を透過的にキャッシュするほどスマートになりますか? したがって、その後、キャッシュからのページネーションクエリを満たしますか? そうでない場合、効率的にページネーションするにはどうすればよいですか?

編集

データベースは、単一ユーザーのデスクトップ分析用です。しかし、これがライブ OLTP アプリケーションである場合、最善の方法は何かを知りたいと思っています。ドキュメント ID の順序付けられたセットを作成し、別のテーブルの ID に対してクエリ パラメータをキャッシュすることで、過去に SQL Server で問題に対処しました。数時間ごとにキャッシュをクリアします (新しいドキュメントが結果セットに入るようにするため)。

おそらく、このアプローチはpostgresで実行可能です。それでも、データベースに存在するメカニズムと、それらを最大限に活用する方法を知りたい. もし私が DB 開発者だったら、クエリ応答キャッシュが FTS システムで動作するようにします。

4

2 に答える 2

3

セッション全体で開いたままの特定のデータベース接続にクライアント セッションを関連付けることができる場合、サーバー側の SQL カーソルをこれに効果的に使用できます。これは、異なる接続間でカーソルを共有できないためです。ただし、実行中のインスタンスごとに一意の接続を持つデスクトップ アプリであれば、問題ありません。

DECLARE CURSORのドキュメントWITH HOLDは、コミットされたトランザクションでカーソルが宣言されたときに結果セットがどのように具体化されるかを説明しています。

ロックはまったく気にする必要はありません。カーソルが既に具体化されている間にデータが変更された場合、リーダーに影響を与えたり、ライターをブロックしたりすることはありません。

それ以外に、PostgreSQL には暗黙的なクエリ キャッシュはありません。LIMIT/OFFSET 手法は、ページごとにクエリを新たに実行することを意味します。これは、実行計画の複雑さとバッファ キャッシュとディスク キャッシュの有効性によっては、最初のクエリと同じくらい遅くなる場合があります。

于 2012-08-23T16:01:02.923 に答える
2

正直なところ、クエリがライブ Cursor を返し、それを再利用して、それ (Cursor) が表す結果の特定の部分をフェッチすることが必要な場合があります。PostGre がこれをサポートしているかどうかはわかりませんが、Mongo DB はサポートしています。その道をたどってみましたが、クールではありません。例: クエリが完了してから、そのクエリの結果の 2 ページ目が要求されるまでにどれくらいの時間がかかるか知っていますか? 時間がある場合、カーソルはその量だけ留まることができますか? また、それが可能である場合、それは正確にはどういう意味ですか?リソースをブロックします。たとえば、クエリを開始してもページをナビゲートするのに時間がかかる怠惰なユーザーが多数いる場合、サーバーはロックされたカーソルによって動かなくなる可能性がありますか?

正直なところ、誰かが特定のページを要求するたびに、ページ分割されたクエリをやり直すのは問題ないと思います。まず第一に、少数のエントリを返します (一度に 10 ～ 20 を超えるエントリを表示する必要はありません)。これは非常に高速です。次に、サーバーを調整して、頻繁なリクエストを高速に実行します (インデックスを追加し、必要に応じてSolrサーバーの背後に配置するなど)、これらのクエリの実行を遅くするのではなく、それらをキャッシュします。

最後に、全文検索を本当に高速化したい場合や、大文字と小文字を区別しない、接頭辞と接尾辞を有効にするなどの派手なインデックスを使用する場合は、Luceneを調べてください。ユーザーと永続層の間の検索ソリューションとインデックス作成ソリューションの間。

于 2012-08-23T13:18:28.180 に答える