Cassandraの時系列データ、1つのキースペースではなく月単位のキースペース？

Question

カサンドラに保存したい測定時系列データを生成する数千ものセンサーがあります。 現在、1日に5億件のレコードを保存していますが、次回は5〜10倍になります。

ほとんどの場合、最新の測定データを使用しています。古い測定データはほとんど読み取られません。私たちは、主に（すなわち、1週齢）最新の測定結果から読み取る

• 、（月未満の年齢を持つすなわち、）
• 古い測定はまれにしか（10回読まれていません、）週
• 非常に古い測定（すなわち、非常にまれつまり、読んだことがない、6カ月以上前
• 測定が寒くなると想定されている、（月1回）読まれていない）1-6ヶ月の年齢を持ちます。

コンパクション戦略として、DTCSを使用します。 ttlの設定は、アーカイブ目的で測定データを保存する必要があるため、オプションではありません。

「古いデータはほとんど寒い」という事実にどう対処するかはまだわかりません。

アップデート：私は避けたい何 ：すべてであれば18TBは、年に一度だけ、のは言わせて、使用されている私のカサンドラクラスタ、20 TBを持ちます。私は必要ではない18TBの支払いをしたくありません。 ttlの設定はオプションではありません。2013年3月などのデータを読み込めるようにする必要があります（このようなリクエストの追加費用は問題ありません）。 ttlを6ヵ月などに設定した場合、適切に設定することはできません。

我々は現在、2つの設計案を評価し、最もコスト効率を探しています：同じと月あたりのパーティションキー（sensor_id、measurement_date）と

1. 一つの鍵空間、
2. 一つの鍵空間、パーティションキー（sensor_id、measurement_date）

（両方のケースでは、我々は100Kよりも、主に以下の行あたり最大500Kの列、であります）

2の欠点は、<が1ではなく100のキースペースを持ち、データを読み込む際の複雑さが増すことです。 2の利点は、毎月スナップショット/バックアップ/削除/リストアができるということです。オプション1を使用すると、私の理解では簡単にはできません。この方法では、サイズを変更する必要はありません実際に寒いテラバイトのデータを保持するカッサンドラのクラスターです。

私の質問： 私たちのユースケースには合理的な選択肢か、これはカッサンドラの反パターンと考えられますか？

ありがとうございました！

Answer 1

データのスキーマおよびメタデータの詳細を保存するように設計されているため、実際のデータパーティションはパーティション/クラスタリングキーに基づいて実装する必要があるため、同一のキースペースまたはテーブルのシーケンス間でデータをパーティション分割することはお勧めしません。

スナップショットを使用してデータをバックアップすることは、毎月行われるわけではありませんが、おそらくincremental backupsを使用して、フラッシュされたステルスを1か月間一緒に保存するカスタムソリューションを使用できます。データを削除するために、TTLを使用することは、時系列データを処理し、ディスク領域を使い果たしていないことを確認する最も一般的な方法です。

Answer 2

一般的に、以前のコールドデータを別のキースペースに保存することは望ましくありません。現在、データをどのように分割しているかによって、チャレンジは非常に広い行に見えます。代わりに私はあなたが月ごとにデータを "バケツ"提案します。これはパーティションキーを次のように変更することで可能です：

PRIMARY KEY ((year,month,sensor_id), measurement_date) 

余分な括弧は、複数の列をパーティションキーとして宣言するためのCQL構文です。つまり、このテーブルから読み取る年、月、sensor_idを常に指定する必要があります。ただし、Cassandra Primary Keys（リレーショナルデータベースとは異なります）では、データがクラスタ全体でどのように分散されるかを定義してください。それで、私たちがやっていることは、1年ごとにセンサデータをそれ自身の行に収めることです。したがって、私たちは基本的に、複数のキースペースを使って考えていたことを達成していますが、Cassandraと開発者にとってはより親しみやすい方法です。

このテーブルにデータを挿入するのはかなり簡単です。取得timeuuidから現在の時間のための

1. timeuuid（UUIDv1）を生成
2. ：そのmeasurement_dateと仮定するとtimeuuid（それはそうでなければ、データを上書きすることができるべきである）ここで、一般的にはあなたのコードはどうなるフローのです年と月の部分続い

3. INSERTのためにあなたのCQLを実行します。

   • INSERT time_series（年、月、sensor_id、measurement_date）VALUES INTO（2016,4、 'ここtimeuuid発生した'、 'sensor_id'） ;

は、私はかなりまっすぐ進むべきであるテーブルからデータを読み出す前に述べたと同様。さらに詳しい情報が必要な場合は、データモデリングに関する質問 hereに関連する、より長い応答があります。

1日あたり500Kの測定値を書いているので、このデータをさらにバケット化する必要があります（詳細は上記のSOの回答を参照）。なぜなら、クラスタリングの列が10kを超えると、C * 。

最後に、Optimizing Cold SS Tablesを読むとよいでしょう。Optimizing Cold SS Tablesは、その中にいくつかの優れた情報を提供しています。たとえば、cold_reads_to_omitを調整して、非常にコールド・テーブルを圧縮する時間を無駄にしないようにすることができます。 DTCSでは、max_sstable_age_daysを設定して、特定の年齢のSSテーブルの圧縮を停止し、コールドテーブルにIOを保存することができます。

更新：ストレージサイズ管理： すべての場合に1つのテーブルだけを使用したい場合は、いくつかの調整が必要です。まず、テーブルが圧縮（理想的にはlz4）を使用していることを確認し、次に、スペースを節約するレプリケーションファクタを下げることができます。私はあなたが古いデータのキースペースが異なっていて、スペースを節約するためにそれぞれ別々のRFを持つことができると思います。

あなたが押して、アーカイブする必要があるデータ量については、GraphiteやInfluxDBのような時系列データベース（TSDB）を調べることをお勧めします。あなたの目標と課題については、TSDBはCassandraをタイムリーなデータにマッサージするよりもはるかに使いやすくなります。