12

時系列のようなデータを扱うサイド プロジェクトを計画しており、これらのピカピカの新しい NoSQL DB の 1 つを試して、推奨事項を探しています。

(成長している) I のセットの場合、 ( , ) タプル (時間の経過とともに増加)symbolsのリストがあります。すべてが更新されるわけではありません。更新されるものもあれば更新されないものもあれば、完全に新しいものが追加されることもあります。timevaluesymbolssymbolssymbols

したがって、データベースは次のことを許可する必要があります。

  • 初期の 1 要素 (タプル) リストでシンボルを追加します。例 A: [(2012-04-14 10:23, 50)]
  • 新しいタプルでシンボルを更新します。(そのタプルをそのシンボルのリストに追加します)。
  • 指定されたシンボルのデータを読み取ります。(理想的には、データが返される時間枠を指定させてください)

作成操作と更新操作は、おそらくアトミックである必要があります。一度に複数のシンボルを読み取ることができれば、それは興味深いことです。

パフォーマンスは重要ではありません。更新/作成は、およそ数時間に 1 回行われます。

4

2 に答える 2

17

文字通り、すべての主要な NoSQL データベースがその要件をサポートすると信じています。特に、実際に大量のデータがない場合はそうです (なぜ NoSQL なのかという疑問が生じます)。

そうは言っても、私は最近、時系列データ用の NoSQL データベースを設計して使用する必要があったので、その設計に関する入力を提供し、それを他のすべてのものに推定することができます。

選択したデータベースはCassandraで、設計は次のとおりです。

  • すべての「シンボル」に対する単一のキースペース
  • 各シンボルは新しい行でした
  • エントリがその関連する行の新しい列になるたびに
  • 各値 (複数の値の場合もある) は時間エントリの値の部分でした

これにより、要求したすべてを達成できます。最も注目すべきは、単一​​のシンボルのデータを読み取り、必要に応じて範囲を使用することです (列範囲呼び出し)。パフォーマンスは重要ではないとおっしゃいましたが、それは私たちにとって重要であり、これも非常にパフォーマンスが高かったです.1つのシンボルのすべてのデータは、定義によりソートされ（列名のソート）、常に同じノードに保存されます（単純なクエリのクロスノード通信はありません） ）。最後に、この設計は、動的列を持つ他の NoSQL データベースにうまく変換されます。

これに加えて、時系列ストアでの MongoDB (および必要に応じてキャップ付きコレクション) の使用に関する情報を次に示します:時系列データベースとしての MongoDB

最後に、時系列の SQL と NoSQL の説明を次に示します: https://dba.stackexchange.com/questions/7634/timeseries-sql-or-nosql

その議論に次のことを追加できます。

  • NoSQL の学習曲線は高くなります。「ソフト コスト」の点で、追加の柔軟性と機能を無料で手に入れることはできません。このデータベースの運用をサポートするのは誰ですか?
  • この機能が将来的に拡張されることが予想される場合 (各時間エントリに追加されるフィールドが増えるか、シンボルの数またはシンボルの時系列のサイズに関してはるかに大きな容量になるかのいずれか)、間違いなく NoSQL を使用してください。柔軟性の利点は非常に大きく、(上記の設計で) 「シンボルごと」と「シンボルの数」の両方で得られるスケーラビリティはほぼ無制限です (ほぼ無制限と言います - 行あたりの最大列数は数十億、最大キースペースあたりの行数は無制限だと思います）。
于 2012-04-14T22:46:58.150 に答える
4

hbase を使用するオープンソースの時系列データベースである opentsdb.org をご覧ください。彼らは TS の保管方法に優れています。ここで十分に文書化されています：http://opentsdb.net/misc/opentsdb-hbasecon.pdf

于 2012-06-18T15:10:58.873 に答える