4

私はMySqlデータベースの構造を計画しており、より熟練した専門家からのアドバイスを使用することができます。DBが所属するサイトは、登録ユーザーごとに90日間の気象データを収集し、数百万人のユーザーをサポートする必要があります。

ログイン情報と連絡先情報を含むユーザー用のテーブルがすでにありますが、すべての気象データ用に2番目のテーブルが必要であると想定しています...

私がやろうとしているのは、基本的に、すべてのユーザーの平均気温、湿度、風向などを1日あたり4番目に保存することです。そして、すべてのユーザーについて、昨日のエントリ（ただし、89日間の古いデータと当日のデータに限定されます）を保持しながら、DBは毎日新しい日のデータで更新されます。

さて、すべてのユーザー（数百万のユーザー）に対して90行の巨大な「データ」テーブルを1つ持つのが最も理にかなっていますか？または、パフォーマンス上の理由などで、これを行うためのより賢い方法はありますか？

ユーザーがログインして自分のプロファイルを表示するたび、または他のユーザーのプロファイルを参照するたびに、90日間のデータにアクセス（読み取りや表示など）されます。ただし、更新されるのは1日1回のみです（最も古いエントリを上書きし、ユーザーあたり90行の制限を維持します）。

4

5 に答える 5

2

編集：各ユーザーが異なる気象データを持っていることを今見ました。答えに「共有データ」を保持しますが、2番目のケースに興味があります。

ユーザーは気象データを共有します

たとえば、最寄りの気象観測所IDに基づいています。

（userId、stationId、isActive、isPreferred）テーブルを保存して、ユーザーが関心のあるデータを確認してから、stationWeatherDataに対してクエリを実行して、そのステーションの90行の気象データを取得します。

各ユーザーは独自の気象データを持っています

9億人のユーザーを処理する上で特に問題はないはずです。本当に必要な場合は、userIdに基づいてさまざまなテーブルを「シャーディング」できます。たとえば、テーブルweather174は、（userId％1000）が174を与えるすべてのユーザーのデータを保持し、1000個のテーブルがあることに気付くでしょう。さまざまなサーバー-1000分の1のサイズ。

したがって、1つの大きなテーブルから始めて、シャーディングの準備をします（または、クラウドストレージと非SQLキーストアデータベース（MongoDB、VoltDBなど）に移行します）。または、UserIDがたとえば100万に達するとすぐに、UserIDに基づいてパーティションを作成します。

または、データベースをまったく使用しません。DBは、データを検索または相関/結合する必要がある場合に意味があります。ここでは、ユーザーの「気象観測所」にアクセスしているだけです。

「湿度が60％のユーザーは何人ですか？」とクエリを実行することはなく、常に「ユーザー1234567のデータは何ですか？」とクエリする必要がない場合は、データをバイナリ、JSON、またはHTML形式（クラウドストレージ、S3、またはMongoDB-ユーザーごとに1つのドキュメントのみ）。その場合、更新されるデータがどのように到着するか、つまり、コンセントレーターからの1つの大きなバッチ、または各ユーザーが独自のデータをアップロードする方法に大きく依存します。

于 2012-07-09T06:19:16.737 に答える
1

私の答え（以下）では、データはユーザーの個人的な裏庭の気象観測所など、ユーザーに固有のものであると想定しました。それが他のユーザーと共有されているデータである場合、私の答えは最適ではありません。

それは理にかなっているようですが、なぜ90日で停止するのですか？有効なユーザーである限り、各ユーザーの毎日の情報を保持します。記述されたクエリは常に次のようなものです

SELECT temperature_avg, humidity, wind_direction, wind_speed
FROM weather_summary
WHERE user_id = (current_user)
ORDER BY sample_date DESC
LIMIT 90;

sample_dateとにインデックスがある限りuser_id、これは非常に効率的です。

ユーザーごとに個別のテーブルを用意することは、私の経験ではうまくいきませんでした。

于 2012-07-09T06:13:18.420 に答える
1

各ユーザーの場所を保存する場合は、場所に基づいて気象データを保存し、オンデマンドでユーザーにマッピングする方が簡単です。

UserId->LocationId->天気の詳細。

平均して、各場所から複数のユーザーがいると仮定すると、これによりデータベースサイズが大幅に削減され、拡張性も向上するはずです。

于 2012-07-09T06:15:21.163 に答える
1

天気データには、日付で分割された単一のテーブルをお勧めします（範囲の分割に関するMySQLのドキュメントを参照してください）。

このようにして、古いデータを簡単に取り除くことができ（最も古いパーティションを削除するだけです）、日数の範囲（たとえば、過去7日間の平均気温）のクエリは非常に効率的です。

于 2012-07-09T06:26:13.813 に答える
0
  1. テーブル列にインデックスを作成します（id、フルテキストインデックス）。
  2. アイデアとして、このテーブルにいくつかのビューを作成できます。このビューには、場所、日、週、月、四半期、アルファベット、またはその他の基準に基づいてフィルタリングされたデータが含まれ、それに基づいてコードがどのビューを使用しての検索結果。
  3. または、テーブルに多くの挿入/更新操作がある場合は、複数のテーブルを作成し、いくつかの基準に基づいて、サーバー側のプログラミング言語でデータを更新/挿入するテーブル名を選択できます。
于 2012-07-09T06:20:49.620 に答える