1

次のアイデアを思いついたばかりですが、それが本番アプリケーションに適用できるかどうかを判断する知識がありません。

簡単にするために PHP/mySQL 上に構築された Web アプリケーションがあります。データベース内のテーブルは大きくなる傾向があります - 簡単に数百万のレコードになるため、ここではテーブルのシャーディングがオプションになる場合があります。

プロセスが機能することを想像した方法は次のとおりです。

キャッシュされたファイルには、データベースで使用可能なテーブルのリストが含まれています。各テーブルには最大 100 万行が含まれ、これに達すると、新しいテーブルが作成された後にキャッシュされたリストが再作成されます。

明らかに、テーブルへの書き込みごとに行数をチェックするのは良い考えではないため、100 万個のデータが作成される速さに応じて、1 週間または毎日などの設定された間隔でこれを行うことができます。

これは、大量のデータを処理し、インデックス サイズをかなり小さく保つのに適した方法でしょうか?

ありがとう

4

4 に答える 4

3

莫大な成長の可能性を前もって計画している場合 (たとえば、ゲームがバイラルになった場合)、以前の手順に従って NoSQL に移行できます。

Couchbase / powers Zinga (個人的にお気に入り)
Apache Cassandra / powers Twitter
mongoDB / powers Craiglist

しかし、「簡単にする」ために php/MySQLでサイトを構築しているので、非常に大きな問題で車輪を再発明しないでください。

データをいじらないでください。実績のあるソリューションを求めてください。MySQL が含まれています。

于 2010-08-13T18:53:22.283 に答える
2

水平分割を使用し、テーブルをレコード数で分割し、すべてのパーティションに 100 万のレコードがあるとします。そのようにして、mysql が内部的に分割を処理し、1 つの大きなインデックスの代わりに、インデックスも同様に分割されます。

ここで詳細を読むhttp://dev.mysql.com/tech-resources/articles/performance-partitioning.html

于 2010-08-13T19:36:01.313 に答える
1

正直なところ、それは素晴らしいアイデアだとは思いません。古いデータをアーカイブするか、MONgo のような NoSQL ソリューションを検討する必要があります。

于 2010-08-13T18:43:22.290 に答える
1

インデックスのパフォーマンスは、テーブルのサイズに比例して低下するわけではありません。それが問題になる前に、テーブルは非常に大きくなければなりません。パフォーマンスの問題が発生している場合は、mysql の「explains」を開始し、すべてのクエリができる限り少ない量の行スキャンを実行していることを確認します。実際のボトルネックが何であるかに驚かれるかもしれません。

したがって、基本的に、データが必要な場合、私はそれをいじりません。一方、セッション データのようなものであれば、古すぎる行を削除するだけです。

于 2010-08-13T19:44:22.343 に答える