1

私は、多くの時系列データ ( time=value,time=value... ) を収集/保存する組織で働いています。今日、私たちはこのデータを収集して処理するために歴史家を使用しています。ヒストリアンを使用する主な利点は、データを圧縮し、データ ストレージに関してより効率的になることです。しかし、ビッグデータや NoSQL などのテクノロジーでは、データを圧縮する努力 (ストレージ $$ のため) は薄れつつあり、トレンドは「大量の」データを保存することです。

  1. 時系列ヒストリアンを BigData ソリューションに置き換える実験をした人はいますか? 私は OpenTSDB を知っていますが、これを IT 以外の役割で使用した人はいますか?
  2. NoSQL データベース ( Cassandra... ) は時系列データに適していますか? もしそうなら、実装はどのように見えるでしょうか?
4

1 に答える 1

0

単に収集または保存することが重要ですか、それとも分析の速度または容易さが不可欠​​ですか?

ほとんどの妥当なデータ サイズでは、標準 SQL で十分です。

その上で、特に分析の場合は、メモリ内および列指向のデータベースが望ましいでしょう。最上位では、これはすべての主要な銀行で使用されている kx.com による kdb を意味します ($$ 高価です)。ただし、オープン ソースについて具体的に質問された場合は、データ サイズとアクセス要件に応じて、メモリ内の monetdb または mysql を検討します。

Cassandra は、nosql バンドルからのより適切な選択肢の 1 つであり、人々はすでにそれを使用しようとしています: http://www.datastax.com/dev/blog/advanced-time-series-with-cassandra http://synfin.net /sock_stream/technology/advanced-time-series-metric-data-with-cassandra

物事を機能させるために最小のデータ レベルでハッキングし、多くの冗長なコードを作成することに多くの時間を費やしていることがわかりました。次に、データを複数のサーバーに分散させ、複数のマシンを使用して非効率的なストレージを補おうとしました. 評価してみると、It's time サポートや時間を操作する機能が貧弱で、範囲を簡単に引き出す以上のことができませんでした。これらの理由から、cassandra から移行しました。

于 2013-03-30T10:51:34.927 に答える