3

現在、私はいくつかの統計情報/事実を含むPHP/MySQLのダッシュボードに取り組んでいます:売り上げ量、売上高、性別(男性/女性)ユーザーなど(すべて先週/月/年にフィルタリング可能)。データの量はそれほど多くはありません(現在は20,000のユーザー行、1.000個のアイテム、1日あたり500個のアイテムが販売されていますが、将来的にはおそらく指数関数的に増加することが予想されます)。統計情報(グラフ)のパフォーマンスデータを格納する最適な方法

戦略の変更がユーザー、収益、性別などの量に影響を与えるかどうかを確認するために、パフォーマンスを表示するグラフがいくつかあるようにしたいと思います。そのためには、1日あたりの数字が必要です。現在、ダッシュボードには「NOW() - 1週間/ 1ヶ月/ 1年」としか表示されませんが、成長を示すグラフを表示するために、これらの数値は日々保存する必要があります。

私の質問は:この場合のオプションは何ですか?これらの数値を保存し、訪問者、売上、性別の割合などをその日の日付にリンクされた行に保存する別の「パフォーマンス」または「履歴」表に書き込むために、cronジョブを設定することができます。これはパフォーマンスには良いことですが、特定のデータが失われます。もう1つの選択肢は、複雑なクエリ(毎日)などでこれらの数値を計算することですが、クエリは本番データベースで実行されるため集中的に見えます。特にデータベース構造が少し複雑であるためです。本番データベースでこれを回避することを考えた場合、ETLプロセスを使用してデータウェアハウスを設定すると、本番データベースのオーバーロードを避けるためのより良いオプションが得られます。その場合、データはライブ表示されません。

私は正直なところ、この場合の最良の選択肢は何もわかりません。私は答えに非常に興味があります!どうもありがとう。

+0

計算が遅すぎる場合は、複雑なクエリを1日に1回(深夜など)実行して、基本データから必要な統計を生成することが標準的な方法です。古い日のデータが変更されない場合、またはすべてを再作成する場合は、新しい日のデータを追加します)。今日の日付は統計では有効ではないため、「ライブ」である必要はありません。あなたの事前計算は、後で表示/フィルタリングしたいものに依存しますが、必要なすべての統計を満たす構造が1つも見つからない場合は、複数のテーブルを作成することは完全に有効です。 – Solarflare

+0

これは、あなたのテーブルについてもっと多くの情報を提供するのに役立ちます。各テーブルには何が入っていますか? –

+0

[_Summary Tables_](http://mysql.rjweb.org/doc.php/summarytables)は素晴らしいアイデアのように聞こえる。 –

答えて

0

実動データベース(特に量と複雑さが増えているデータベース)で実行されているクエリは、非常に迅速に失われます。可能性のある選択肢がたくさんありますが、基本的にビジネスインテリジェンスの分野全体がこの問題の解決策として成長しています。

本番データベースを照会するのを避けたい小さなシステムの場合、おそらくデータウェアハウスの開発はおそらく過度のものです。それ以上のことを知らなくても合理的な答えを出すことは不可能ですが、私は次のいずれかのために行くでしょう:複雑さ/結果の程度が大きくなる順に:

  1. クエリの結果を直接表示する代わりに、そのテーブルで、テーブルに
  2. クローン本番データベースを照会し、関連するデータを保存する構造にクローンを本番データベースから
  3. 抽出関連データを照会し、歴史を保存する(Googleのデータボールト)の生産を超える
  4. ダイレクトDB、またはソリューション2または3上でディメンションモデル(Google Kimball Dimensional Model)を構築します。良い仕事をするには、どのような種類のクエリーをしたいのかを考えなければならないことに注意してください。あなたは異なる要件のために異なるデザインで終わることができます。

また、どの技術を使用しているのか、利用可能なアーキテクチャで利用可能なオプションは何か関連しています。あなたが手にしているものによっては、複雑なものであっても非常に単純化された解決策があるかもしれません。いくつかの研究を行います。

関連する問題