0

5 分ごとに読み取られる約 50,000 のサードパーティ データ フィードがあります。アイデアは、更新されたコンテンツをチェックすることです。次のテーブルがあります。

フィード

  • ID
  • 名前
  • URL

投稿

  • ID
  • feed_id
  • 題名
  • コンテンツ
  • URL
  • unique_hash (URL + タイトルに基づく)

私の最初のアプローチは、posts.unique_hash を一意のインデックス フィールドにして、INSERT を試行すると失敗するようにすることでした。INSERT の大部分は (意図したとおり) 単純に失敗します。ただし、私の問題は、「posts」テーブルで SELECT を頻繁に実行する必要があることです (このアプリケーションの別の部分のために)。

もちろん、INSERT を試みる前に「posts」テーブルで SELECT を実行することもできますが、それはさらに多くのリソースを消費します。

多くの SELECT クエリを作成するために「posts」テーブルのリソースを解放しておく最善の方法を探しています。インデックス テーブルを使用しますか? キャッシュメカニズムを使用しますか?

4

1 に答える 1

0

(一意の) キーは複数のフィールドにすることができるため、ハッシュを計算する必要はありません。重複した情報が挿入されるのを防ぐために、feed_id、タイトル、および url の組み合わせを一意のキーにすることができます。

より多くのリソースをキャッシュするインデックスの量などに専念させること以外にできることはあまりありません...単純にINSERTを実行すると、サーバーへのクエリが最も少なくなるからです。一意のインデックスを使用すると、不適切な挿入が失敗するだけで、挿入する必要があるかどうかを確認するために選択などを行う必要がなくなります。

投稿から SELECT を行う方法は、かなり異なる場合があります。何を引き戻したいか (select * from posts where feed_id = ?または他の何かなど...) を指定する必要があります。情報のクエリ方法に応じて、そのテーブルで追加のインデックスがどのように機能するかが決まります。

于 2012-04-12T00:54:38.367 に答える