通常、「最良の」データベースはありません。これらはすべて、ある種のトレードオフを伴うためです。また、1分あたりの挿入数(挿入あたりのデータ量)以外にパフォーマンスのニーズについては何も言わず、「スケーラビリティ」が必要であるため、質問も非常にあいまいです。
また、「 [MySQL]にはこのプロジェクトに必要なスケーラビリティが不足しているように感じる」と言うため、時期尚早の最適化のケースのように見えますが、これが実際の問題であるかどうかを確認するためのテストを実行したようには思えません。重要なアーキテクチャ上の決定を「感情」に基づいて行うよりも、実際のデータを取得する方が常に優れています。
ここに提案があります:
- 1分あたり10,000行のサンプルデータを挿入する簡単なテストプログラムを作成します
- プログラムを適切な時間(数日以上)実行して、かなりの量のテストデータを生成します
- クエリを実行して、パフォーマンスのニーズを満たしているかどうかを確認します(指定していません。どのくらいの速さである必要がありますか?どのくらいの頻度で実行されますか?どのくらい複雑ですか?)
ここでは、少なくとも2つのことをテストしています。データベースが1分あたり10,000の挿入を処理できるかどうか、および大量のデータがある場合にクエリが十分に高速に実行されるかどうかです。大規模なデータセットでは、高速クエリ用のインデックスが必要になるため、これらは競合する優先順位になりますが、インデックスは時間の経過とともに挿入の速度を低下させ始めます。ある時点で、パフォーマンスと実用上の理由(有限のストレージスペース)の両方から、データのアーカイブ(または履歴データが必要ない場合はパージ)についても考慮する必要があります。
これらは、どのデータベースを選択しても問題になります。検索のニーズ(「特定の特性を持つデータのカウント」と「プロットのための単純な出力」)についてほとんど何も言わなかったことから、どのタイプのデータベースでも機能するように思えます。開発の容易さ(どの言語とツールを使用していますか?)、展開、管理、コードの保守性など、他の懸念事項がより重要である可能性があります。
これは私たちが話しているセンサーデータであるため、RRDToolなどのラウンドロビンデータベース(RRD)を調べて、そのアプローチがニーズに適しているかどうかを確認することもできます。