1

統計データを保存するための最適なアプローチについてアドバイスが必要です。Djangoには、30000のオンラインゲームのデータベース（mysql）を持つプロジェクトがあります。

各ゲームには3つの統計パラメータがあります。

  • ビューの数、
  • 演劇の数、
  • いいねの数

ここで、これら3つのパラメーターの履歴データを毎日保存する必要があるため、5つの列を持つ単一のデータベースを作成することを考えていました。 

gameid, number of views, plays, likes, date (day-month-year data).

つまり、最終的には、すべてのゲームの毎日が1行に記録されるため、このテーブルは1日で30000行、10日で300000行、1年で10950000行になります。 。私はDBAの専門家ではありませんが、これはすぐにパフォーマンスの問題になると私は言います。私は5年後に何が起こるかについて話していません。この表に収集されたデータは、単純なグラフに必要です

(daily, weekly, monthly, custom range).

たぶん、このデータを保存する方法についてもっと良いアイデアがありますか？この場合、noSQLの方が適しているのではないでしょうか。本当にこれについてのあなたのアドバイスが必要です。d

4

5 に答える 5

5

postgresqlでのパーティショニングは、大きなログに最適です。まず、親テーブルを作成します。

create table  game_history_log (
    gameid integer,
    views integer,
    plays integer,
    likes integer,
    log_date date
);

次に、パーティションを作成します。この場合、毎月1つ、900k行が適切です。

create table game_history_log_201210 (
    check (log_date between '2012-10-01' and '2012-10-31')
) inherits (game_history_log);

create table game_history_log_201211 (
    check (log_date between '2012-11-01' and '2012-11-30')
) inherits (game_history_log);

各パーティションのチェック制約に注意してください。間違ったパーティションに挿入しようとした場合：

insert into game_history_log_201210 (
    gameid, views, plays, likes, log_date
) values (1, 2, 3, 4, '2012-09-30');
ERROR:  new row for relation "game_history_log_201210" violates check constraint "game_history_log_201210_log_date_check"
DETAIL:  Failing row contains (1, 2, 3, 4, 2012-09-30).

パーティショニングの利点の1つは、正しいパーティションでのみ検索するため、データの年数に関係なく、検索サイズが大幅に一貫して削減されることです。ここでは、特定の日付の検索について説明します。

explain
select *
from game_history_log
where log_date = date '2012-10-02';
                                              QUERY PLAN                                              
------------------------------------------------------------------------------------------------------
 Result  (cost=0.00..30.38 rows=9 width=20)
   ->  Append  (cost=0.00..30.38 rows=9 width=20)
         ->  Seq Scan on game_history_log  (cost=0.00..0.00 rows=1 width=20)
               Filter: (log_date = '2012-10-02'::date)
         ->  Seq Scan on game_history_log_201210 game_history_log  (cost=0.00..30.38 rows=8 width=20)
               Filter: (log_date = '2012-10-02'::date)

親テーブルとは別に、正しいパーティションのみをスキャンしたことに注意してください。明らかに、順次スキャンを回避するためにパーティションにインデックスを付けることができます。

継承 パーティショニング

于 2012-10-29T11:32:27.747 に答える
3

11M行は過剰ではありませんが、一般的なインデックス作成と主キーのクラスタリングがより重要になります（InnoDB上）。特定のゲームに関するすべてのデータのクエリが連続した行になるように、主キーに（game_id、date）を提案します。また、最新の数値だけが必要な場合は、ランキングゲームなどの現在の値だけを別のテーブルに保持することもできます。

于 2012-10-28T16:31:44.007 に答える
1

10kkデータのMySQLではパフォーマンスの問題はありません。ゲームIDでパーティショニングを適用するだけです（少なくとも5.5バージョンが必要です）。

私はこのようなデータを含むMySQLDBを持っていますが、現在980kk行で問題はありません。

于 2012-10-28T16:01:46.637 に答える
1

リレーショナルデータベースは一切使用しないことをお勧めします。スタティックティクスは、新しいデータが絶えず到着しているため、非常に急速に変化している種類のものです。ここでは、新しいレコードの追加がより高速に機能するため、HBaseのようなsmthの方が適していると思います。

于 2012-10-28T18:49:11.383 に答える
0

すべての行を保持する代わりに、最近のデータを高精度で、中間のデータをmdeiumの精度で、長期のデータを低精度で保持します。これはrrdtoolが採用したアプローチであり、mysqlよりも優れている可能性があります。

于 2012-10-28T15:56:29.593 に答える