2

頻繁にクエリするには大きすぎる (500m 以上の行) 非常に大きな MySQL テーブルがあります。私が行ったことは、必要な結果を「最近」と呼ばれる別のテーブルにキャッシュすることです。

「最近の」テーブルでは、スキーマは次のようになります

ユーザーID

PAGE_ID

表示順

このテーブルにはユーザーごとに最大 64 レコードしか格納したくないので、USER_ID と DISPLAY_ORDER に一意のインデックスを設定しました。そのため、DISPLAY_ORDER は単純に 64 までの int です。行は REPLACE INTO を使用して更新されます。

これは良いアプローチですか?または、ユーザーが 64 行を超えたら、定期的にテーブルからデータを削除する必要があります。パフォーマンスを考慮する必要があります。5 億のマスター テーブルは、今後数か月で 10 億に増加し、ユーザーあたり 64 行ということは、「最近の」テーブルも非常に大きくなることを意味します...

助けてくれてありがとう。

4

2 に答える 2

0

私があなたなら、ビッグデータ NoSQL データベースへの移行を真剣に検討します。Cassandra や HBase のようなもので、どちらも大規模なデータ セットで非常に優れたパフォーマンスを発揮します。1 台の巨大なモノリシック サーバーが多数のレコードをスキャンしてシークしようとするのではなく、MapReduce を使用して 5 ~ 10 個のクラスター化されたノードに作業を任せてください。

于 2014-04-24T20:33:14.563 に答える