6

私たちは、最終的に数千の測定ステーションからなる測定システムを構築しています。各ステーションは、その存続期間中に 30 のスカラー値で構成される約 5 億の測定値を保存します。これらは float 値になります。各ステーションでこのデータを保存する方法を考えています。

  • 複数のタイムスケールでデータを視覚化したい (例: 1 週間、1 か月、1 年の測定値)
  • データの移動平均を作成する必要があります (たとえば、1 か月の平均を 1 年のグラフで表示するなど)。
  • データベースはクラッシュ耐性がある必要があります (停電)
  • 書き込みと読み取りのみを行っており、データの更新や削除は行っていません

さらに、たとえば 1000 の測定ステーションのデータを表示できるサーバーがもう 1 台必要です。これは、5,000 億回の測定で最大 50 TB のデータになります。測定ステーションからサーバーにデータを送信するには、ある種のデータベース レベルのレプリケーションがクリーンで効率的な方法になると考えました。

今、これらの目的のために、noSQL ソリューションが mySQL よりも優れているかどうか疑問に思っています。特に、 cupDB、Cassandra 、そしておそらくRedisのようなキーバリュー ストアは、私にとって魅力的に見えます。あなたの意見では、「測定時系列」データモデルに最も適しているのはどれですか? クラッシュの安全性や測定ステーションからメイン サーバーへのレプリケーションなど、その他の利点についてはどうですか?

4

3 に答える 3

3

CouchDB は優れたデータベースだと思いますが、大規模なデータを処理する能力には疑問があります。CouchDB の主な焦点は、必ずしもパフォーマンスやスケーラビリティではなく、開発の簡素化とオフライン レプリケーションです。CouchDB 自体はパーティショニングをサポートしていないため、BigCouch を使用するか独自のパーティショニング スキームを発明しない限り、最大ノード サイズによって制限されます。

Redis はインメモリ データベースです。RAM のデータの出し入れが非常に高速で効率的です。ディスクをストレージに使用する機能はありますが、それほど得意ではありません。頻繁に変更される制限された量のデータに最適です。Redis にはレプリケーションがありますが、パーティショニングのサポートが組み込まれていないため、ここでも自分で作業することになります。

また、Cassandraについても言及しましたが、これはあなたのユースケースにより適していると思います。Cassandra は、無限に拡大するデータベースに適しています。基本的にはオリジナルのユース ケースです。パーティショニングと可用性は組み込まれているため、あまり心配する必要はありません。データ モデルは、列の 2 番目のディメンションを追加することで、平均的なキー/値ストアよりも柔軟性が高く、1 行あたり数百万の列を実際に収容できます。これにより、たとえば、時系列データを時間範囲をカバーする行に「バケット化」できます。クラスター全体でのデータの分散 (パーティショニング) は行レベルで行われるため、行内で操作を実行するために必要なノードは 1 つだけです。

Hadoop は、MapReduce、Pig、および Hive の「ネイティブ ドライバー」を使用して Cassandra に直接プラグインされるため、収集されたデータを集約し、移動平均を具体化するために使用できる可能性があります。ベスト プラクティスは、クエリを中心にデータを形成することです。そのため、クエリの種類ごとに 1 つずつ、データの複数のコピーを「非正規化」形式で保存することをお勧めします。

Cassandra での時系列の実行に関するこの投稿を確認してください。

http://rubyscale.com/2011/basic-time-series-with-cassandra/

于 2011-11-03T23:05:45.380 に答える
2

この性質の高度に構造化されたデータ (float ベクトルの時系列) の場合、私はデータベースを一斉に敬遠する傾向があります。データベースの機能のほとんどはあまり興味深いものではありません。基本的に、原子性やトランザクションのセマンティクスなどには興味がありません。望ましい唯一の機能は、クラッシュに対する回復力です。ただし、その機能は、ファイルに追加するだけで、書き込みを元に戻す必要がない場合(更新/削除なし) に簡単に実装できます。クラッシュの回復は簡単です。ファイル名にインクリメントされたシリアル番号を持つ新しいファイルを開きます。

これの論理的な形式は、plain-old csv です。各測定が行われた後flush()、基礎となるを呼び出しますfile。複製されたデータを中央サーバーに戻す作業は、 によって効率的に解決されrsync(1)ます。その後、選択した分析ツールにデータをインポートできます。

于 2011-11-03T23:26:00.567 に答える