0

次のシナリオでは、検索でユーザーID値のリスト（1、2、3、4、5、6など）が返されます。検索を再度実行すると、しばらくすると結果が変わることが保証されます。 。ただし、将来使用するために検索結果のインスタンスを保存する必要があります。

現在の実装（レガシー）があります。これは、条件を使用してsearch_idのレコードを作成し、関連付けられたsearch_idを使用して返されるすべての行を別のテーブルに挿入します。

table search_results
   search_id unsigned int FK, PK (clustered index)
   user_id unsigned int FK

このテーブルは数百万のレコードに成長しているため、これは受け入れられないアプローチです。テーブルをパーティション分割することを検討しましたが、どちらの場合も多数のパーティション（1000）があります。

他の場所で使用されない限り、検索結果が期限切れになる既存のテーブルを最適化したため、すべての検索結果は他の場所で参照されます。

現在のスキーマでは、結果をシリアル化された配列またはXMLとして保存できません。検索結果情報を効率的に保存し、レコード数に煩わされることなく、後で効率的にアクセスできるようにしたいと考えています。

編集：回答ありがとうございます。検索自体の実行に問題はありませんが、この場合、検索の結果セットは受信者リストに使用され、何度も使用されます。保存の目的は次のとおりです。特定の時間のデータのスナップショットを正確に取得します。

4

2 に答える 2

2

答えは、クエリ結果を保存しないことです。それはひどい考えです！

  • それはあなたが本当に（本当に本当に）それを必要としない限り、非常に悪いステートフルネスを導入します
  • スケーラブルではありません（ご存知のように）
  • データは保存されるとすぐに古くなります

正しいアプローチは、クエリ/データベースを修正して、すぐに受け入れられるようにすることです。

より優れた SQL やインデックスなどを使用してクエリを高速化できない場合は、 lucene (またはテキストベースの検索エンジン) を使用してデータベースを非正規化することをお勧めします。Lucene クエリは非常に高速です。


私は最近、あなたがしていることを行っていた大規模なWebサイトでこれを正確に行いました:セッションオブジェクトの本番リレーショナルデータベースからのクエリ結果をキャッシュして、クエリを高速化しようとしましたが、それは混乱であり、そうではありませんでした。とにかくずっと速い - 私の時代の前に、実際にはばかだった "上級" Java 開発者 (名前は Jam.. で始まり、.illiams で終わる) は、それが良い考えだと判断しました。

私は Solr (Java に合わせた lucene 実装) を入れ、Solr をリレーショナル データベース (ワーク キューを使用) で最新の状態に保ち、Web クエリはわずか数ミリ秒になりました。

于 2012-10-27T20:08:51.103 に答える
0

すべての検索を保存する必要がある理由はありますか? ユーザーが利用できる最新の情報が必要ですか?

最初に認めますが、これは優れたソリューションではありません。

  • 現在のデータベースと一緒に別のデータベースをセットアップします [SYS_Searches]
  • 保存スクリプトは SELECT INTO [SYS_Searches].Results_{Search_ID} を使用できます
  • 取得するスクリプトは、一致するテーブルから単純な SELECT を実行できます。

利点：

  • すべての検索は、[できれば別の DB にある] 独自のテーブルにきちんとまとめられています。
  • 検索クエリは非常に単純です
  • 取得時間は非常に速く、大規模なテーブル スキャンは必要ありません。

欠点:

  • ユーザーが保存できる x ユーザー * y 検索ごとにテーブルが作成されます。

これは、管理者が結果を期限切れにするか、ユーザーがキャッシュされた検索結果セットを 1 つしか持てない場合を除き、非常にばかげたものになる可能性があります。

きれいではありませんが、別の方法は考えられません。

于 2012-10-27T19:25:32.037 に答える