アクセス統計のためのデータベース設計

ユーザーがシステムに申請すると、システムはユーザーがコンテンツを編集できるように一意の短縮 URL xx.xx.xx/abced1 をランダムに生成します (abcde1 はコーディングと呼ばれる短縮 URL 識別子です)
ここでアクセスをカウントする必要がありますすべてのコーディングの記録。
現在、特定のコーディングの短縮 URL にアクセスするたびに、UA 情報、IP アドレス、および有効時間がすでに存在する場合は、アルゴリズムを通じて uvmark (訪問者識別) が取得されます。テーブル内のuvmarkは、同じ人が複数回訪問した場合、この時点では挿入レコードは作成されませんが、データの数値フィールドが+1更新されます。ただし、uvmark がない場合は、挿入のレコードを追加するだけです (レコードには、コーディング、アクセスしたデバイス、システム環境、ブラウザ環境、アクセス都市、アクセス時刻などが含まれます)

ただし、訪問数が増加するにつれて、データはテーブルがとても多すぎました。データは 9,000 万件近くあり、毎日約 200 万件ずつ増加しています。大量のスキャンを伴ういくつかのコードをカウントします。たとえば、時間による SQL は次のようになります: select number from access_log wherecoding = XXXX and time_start と time_end の間の時間
取り出したデータ uv は項目数 pv は合計です。各項目の数値の合計（地域、環境などと同様） 効率は相対的に低い。短い URL の 1 日あたりのアクセス数が平均 2W の場合、過去 1 か月のアクセス数をカウントしたいのですが、それには 50 秒以上かかります
コーディングのアクセス統計を見つけました。以下の通りです


これをするのは何か間違っていますか？最適化できるものはありますか? Baidu Statistics のようなデータベースはどのように設計されていますか? また、データベースが非常に速く感じられるのはなぜですか?

ディスカッション (解決策) に返信

毎日要約し、最初からカウントするのではなく、過去の訪問が要約結果を直接取得します

毎日要約し、過去の訪問が要約結果を直接取得します結果は最初からカウントされるわけではありません

ただし、リアルタイムでカウントするモジュールがあり、特定の日であっても 30 分ごとにデータが得られます。要約すると、30 日前の 1 日の 24 時間のリアルタイム統計を計算する方法を知りたいです

30 日前の 1 日はまだリアルタイムですか? 明らかにそうではありません! 今日のデータを除いて、過去のどの日のデータも変化しません（消えてしまいます）
したがって、統計計画に従って統計結果を記録するだけで済みます

30 日前 ある日

まだ残っているでしょうかリアルタイム？ 明らかにそうではありません! 今日のデータを除いて、過去のどの日のデータも変化しません (消えてしまいます)
したがって、統計計画に従って統計結果を記録するだけで済みます

それから、私は知る必要があります 8 次のデータはどうですか毎月 1 日の 9 時から 12 時までです

それは問題ではありません、1 時間ごとに数えると、1 日のレコードは 24 件しかありません 1 分ごと、または毎分ごとにカウントすることもできます2番目に、元からやり直すよりも良くなります データをまとめるのが早いです

それは関係ありません、1時間ごとに数えると、1日のレコードは24件しかありません

数えることもできます毎分、いや毎秒でも、元のデータからまとめるよりも早くなります

教えてください。ああ、ところで、地域統計など、他の統計手法を毎日どのように集計していますか？時間条件と地域条件の両方があります

各州には都市があります

これらのデータをどのようにまとめるべきですか

これらのデータはどのように計算しましたか? 1+1 はカウントされますが、10+10 はカウントされません?

これらのデータはどのように計算しましたか?

1+1 はカウントされますが、10+10 はカウントされません?

最初のものには 1 つの条件 (時間) のみがあり、各短縮 URL の pv uv のデータを 1 時間ごとに保存できます。
2 つ目は複数条件 (時間と場所) で、地域ごとに 1 時間あたり N 個のデータを保存する必要があります。これは、#6 の蘇州でしょうか。例として下の図: 訪問数 519 はこれまでの訪問数を表し、明日の訪問数は 519 + n です
これについて疑問はありませんか?
では明日、今日の519は変わるでしょうか？もちろん変わりません