8

毎分約1つのエントリを生成する多数(数千から数万)のセンサーからリモートでデータを保存するためのデータベースを選択する必要があります。

上記のデータは、統計のための特定の特性を持つデータのカウントから、プロットのための単純な出力まで、さまざまな方法で照会する必要があります。

適切なツールを探しています。MySQLから始めましたが、このプロジェクトに必要なスケーラビリティが不足しているように感じます。そのため、私はあまり知らないnoSQLデータベースにたどり着きました。

リレーショナルかどうかにかかわらず、どのデータベースが適切な選択でしょうか?

ありがとう。

4

3 に答える 3

9

通常、「最良の」データベースはありません。これらはすべて、ある種のトレードオフを伴うためです。また、1分あたりの挿入数(挿入あたりのデータ量)以外にパフォーマンスのニーズについては何も言わず、「スケーラビリティ」が必要であるため、質問も非常にあいまいです。

また、「 [MySQL]にはこのプロジェクトに必要なスケーラビリティが不足しているように感じる」と言うため、時期尚早の最適化のケースのように見えますが、これが実際の問題であるかどうかを確認するためのテストを実行したようには思えません。重要なアーキテクチャ上の決定を「感情」に基づいて行うよりも、実際のデータを取得する方が常に優れています。

ここに提案があります:

  1. 1分あたり10,000行のサンプルデータを挿入する簡単なテストプログラムを作成します
  2. プログラムを適切な時間(数日以上)実行して、かなりの量のテストデータを生成します
  3. クエリを実行して、パフォーマンスのニーズを満たしているかどうかを確認します(指定していません。どのくらいの速さである必要がありますか?どのくらいの頻度で実行されますか?どのくらい複雑ですか?)

ここでは、少なくとも2つのことをテストしています。データベースが1分あたり10,000の挿入を処理できるかどうか、および大量のデータがある場合にクエリが十分に高速に実行されるかどうかです。大規模なデータセットでは、高速クエリ用のインデックスが必要になるため、これらは競合する優先順位になりますが、インデックスは時間の経過とともに挿入の速度を低下させ始めます。ある時点で、パフォーマンスと実用上の理由(有限のストレージスペース)の両方から、データのアーカイブ(または履歴データが必要ない場合はパージ)についても考慮する必要があります。

これらは、どのデータベースを選択しても問題になります。検索のニーズ(「特定の特性を持つデータのカウント」と「プロットのための単純な出力」)についてほとんど何も言わなかったことから、どのタイプのデータベースでも機能するように思えます。開発の容易さ(どの言語とツールを使用していますか?)、展開、管理、コードの保守性など、他の懸念事項がより重要である可能性があります。

これは私たちが話しているセンサーデータであるため、RRDToolなどのラウンドロビンデータベース(RRD)を調べて、そのアプローチがニーズに適しているかどうかを確認することもできます。

于 2012-06-29T18:53:51.867 に答える
2

「センサーデータのデータベース」をグーグルで検索しているときにこの質問を見つけました(このSOの質問とともに)非常に役立つ検索結果の1つは、このブログでした:

実際、私は同様のプロジェクト(http://reatha.de)を開始しましたが、利用できる最高のテクノロジーを使用していないことに気づきました。私のアプローチはMySQL+PHPに似ていました。最後に、これはスケーラブルではないことに気づき、プロジェクトを停止しました。

さらに、Herokuのデータベースのリストを確認することから始めることをお勧めします。データベースを使用している場合は、最悪のデータベースではないはずです。

これがお役に立てば幸いです。

于 2014-01-31T13:37:57.517 に答える
-3

RedisnoSQLデータベースの使用を試みることができます

于 2012-06-29T09:24:11.013 に答える