0

複数のソースから集約されたニュース/ブログ/フォーラム Web サイトを構築しようとしています。

ほとんどのクエリは、write_time 列の同じ期間内にある可能性が高いため、write_time で並べ替えられたクラスター化インデックスを利用することを考えています。

しかし、一意ではないため、次のような一意の ID を持つ主キーを作成することを考えています。

(written_time, site_id, article_id)

多少大きなスペースが必要になると思いますが、セカンダリ インデックスを使用するよりははるかに優れています。書き込み時間に近いクエリ結果を利用したい場合、このようにクラスターインデックスを作成するのは良い方法ですか?

次に、いくつかのユース ケース シナリオを示します。

  • Web サイトのメイン ページには、最近の集計記事が表示されます

    例えばSELECT .. FROM written_time >= datetime_1weeksago

  • ユーザーは特定の期間のすべての板の記事を見ることができます

    例えばSELECT .. FROM written_time >= datetime1 AND written_time < datetime2

  • ユーザーは特定の時間チャンク (例: 201207) の特定のキーワードを含む記事を見ることができる、ユーザーは検索条件をいくつかの選択したサイトに絞り込むことができる、検索トラフィック量は多くない、全文エンジンを使用するつもり、頻繁な検索結果はキーワードによってキャッシュされる*time_chunk.

    例えばSELECT .. FROM written_time >= '2012-07-01' AND written_time < '2012-08-01' + keyword search using full-text engine

    例えばSELECT .. FROM written_time >= '2012-07-01' AND written_time < '2012-08-01' AND site_id IN (1,3,5,7,9) + keyword search using full-text engine

  • バックグラウンド クローラーは、2 つの方法で多数の記事をフェッチし、2 つの方向に追加します: (これが、write_time でクラスター化インデックスを作成したい理由です)

    1. 最近の記事を定期的にクロールして更新します (新しい written_time のエントリを追加します)

    2. 古い記事を走り書きしてアーカイブします (write_time を含むエントリを追加します)

  • 多数の非常に活発なニュース/ブログ/フォーラムからの膨大な量の記事

4

1 に答える 1

0

InnoDB は他のすべてのインデックスに PRIMARY KEY 値を格納するため、スペースと時間の理由から、AUTO_INCREMENTInnoDB テーブルには単一ベースの主キーを使用することをお勧めします。

于 2013-05-06T18:17:27.677 に答える