私は現在、ユーザーに一定期間のエネルギー使用量を表示する可能性を提供するホーム オートメーション プロジェクトに取り組んでいます。現在、15 分ごとにデータをリクエストしており、最初の大規模なパイロットでは約 2000 人のユーザーを想定しています。
上司から、少なくとも半年分のデータを保存するように求められています。簡単に合計すると、約 3,500 万件のレコードが推定されます。これらのレコードは小さいですが (それぞれ約 500 バイト)、これらをデータベース (Postgres) に保存することが正しい決定であるかどうかはまだ疑問に思っています。
この量の情報を処理する方法について、良い参考資料やアドバイスを持っている人はいますか?
このようなテーブルにヒットすることがよくあります。明らかに、使用状況に基づいてインデックスを構築し (読み取りまたは書き込みが多いかどうかなど)、最初から、データの高レベルのグループ化に基づいてテーブルのパーティション分割について考えます。
また、アーカイブのアイデアを実装して、ライブ テーブルを薄く保つこともできます。歴史的な記録は決して触れられていないか、報告されていません。私の意見では、どちらも生きているテーブルには適していません。
約 1 億レコードのテーブルがあり、パフォーマンスの問題があるとは認識していないことは注目に値します。これらのパフォーマンスの改善の多くは、後でほとんど苦労せずに行うことができるため、常に常識的な解決策から始めて、パフォーマンスが低いことが証明された場合にのみ調整することができます.
今のところ、それぞれ 0.5K の 35M レコードは 37.5G のデータを意味します。これはパイロットのデータベースに適合しますが、パイロットの後の次のステップについても考える必要があります。パイロットが大成功を収め、すべてを再設計しなければ、今後数か月でシステムに 100.000 人のユーザーを追加することはできないと上司に言われても、上司は不満を抱くでしょう。さらに、VIP ユーザーが分ごとにデータを要求できる新機能についてはどうでしょうか...
これは複雑な問題であり、選択によってソフトウェアの進化が制限されます。
パイロットの場合は、製品をできるだけ安く入手できるように、できるだけシンプルにしてください --> データベースの場合は OK です。しかし、そのようなサービスを開始することはできず、週に 10.000 人の新規ユーザーを獲得する前に状況を変更する必要があることを上司に伝えてください。
次のリリースの 1 つのこと: 多くのデータ リポジトリを用意します。1 つは頻繁に更新されるユーザー データ用、もう 1 つはクエリ/統計システム用などです。
次のリリースについては RRD を参照してください。
また、更新頻度にも注意してください。2000 人のユーザーが 15 分ごとにデータを更新するということは、1 秒あたり 2.2 回の更新を意味します。100.000 人のユーザーが 5 分ごとにデータを更新するということは、1 秒あたり 333.3 回の更新を意味します。単純なデータベースがそれに追いつくことができるかどうかはわかりませんし、単一の Web サービス サーバーでは絶対に追いつけません。
遅いクエリを回避するための適切なインデックスがあれば、まともな RDBMS がその種のデータセットに苦労することはないと思います。多くの人が PostgreSQL を使用して、それよりもはるかに多くのデータを処理しています。
それがデータベースの目的です:)
まず最初に、パフォーマンス テストを行うことをお勧めします。半年で表示されるエントリの数に対応するテスト エントリを生成するプログラムを作成し、それらを挿入して結果をチェックし、クエリ時間が満足できるものかどうかを確認します。そうでない場合は、他の回答で提案されているようにインデックスを作成してみてください。ところで、15 分で生成している量のデータを実際に 15 分以内に挿入できることを確認するために、書き込みパフォーマンスを試す価値もあります。
テストを行うと、すべての問題の母を回避できます-仮定:-)
また、本番環境のパフォーマンスについても考えてください。パイロットには 2000 人のユーザーがいます。本番環境には、1 年か 2 年で 4000 人のユーザーまたは 200000 人のユーザーがいますか?
非常に大規模な環境について話している場合は、1 台のマシンに常に CPU、ディスク、およびメモリを追加できることに頼るのではなく、ノードを追加してスケールアウトできるソリューションについて考える必要があります。複数のデータベース マシンのどれが特定のユーザーの詳細をホストしているかを追跡することで、アプリケーションでこれを行うことができます。または、Postgresql クラスタリング メソッドの 1 つを使用するか、まったく異なるパス ( NoSQLアプローチ)を使用することもできます。 RDBMS から完全に離れて、水平方向にスケーリングするように構築されたシステムを使用します。
そのようなシステムはいくつかあります。私はCassandraの個人的な経験しかありません。RDBMS の世界で慣れ親しんできたものとはまったく異なる考え方をしなければなりませんが、これは少し難しいことです。データを保存する方法よりも、データにアクセスする方法について考えてください。あなたの例では、ユーザーIDをキーとしてデータを保存し、列名がタイムスタンプで列値がそのタイムスタンプのデータである列を追加すると理にかなっていると思います。次に、たとえば Web UI で結果をグラフ化するために、これらの列のスライスを要求できます。Cassandra は、UI アプリケーションに対して十分な応答時間を備えています。
nosql システムの学習と使用に時間を費やすことの利点は、より多くのスペースが必要になったときに、新しいノードを追加するだけで済むことです。より高い書き込みパフォーマンスまたはより高い読み取りパフォーマンスが必要な場合も同じです。
この問題を処理するためのテクニックはたくさんあります。最小数のレコードに触れた場合にのみパフォーマンスが得られます。あなたの場合、次のテクニックを使用できます。
さらに質問がある場合は、ranjeet1985@gmail.com にメールしてください。
個々のサンプルを全期間保持しない方がよいのではないでしょうか? 毎週/毎月のサンプルを 1 つのレコードに連結する、ある種の統合メカニズムを実装できる可能性があります。そして、スケジュールに従って前述の統合を実行します。
決定は、データベースで実行できる必要があるクエリの種類に依存する必要があります。