システムでは、ユーザーがレポートを表示して閉じることができます。レポートを閉じると、レポートはデータベース内の一時テーブルに移動され、24時間保持され、アーカイブテーブル（レポートは今後7年間保存されます）に移動します。 7年間のどの時点でも、ユーザーはレポートを「再オープン」して作業することができます。問題は、アーカイブのストレージが大きくなり、レポートの検索/再オープンが時間がかかることです。そして、私は時々（すなわち、報告日、クライアント、平均の長さが "開かれた"など）、アーカイブについての統計を得る必要があります。私は大きなデータアプローチを使いたいと思いますが、Hadoop、Cassandraなどを使用するかどうかはわかりません。誰かが私にいくつかのガイドラインを提供して、どのように使い始めるべきかを決める方法はありますか？Hadoop vs Cassandra：次のシナリオではどちらが良いでしょうか？
あなたはアーカイブする場合大きく、あなたがそれからレポートを取得したいのですが、あなたはそれがデータを集計する簡単な手段を持っていないとして、単にカサンドラを使用することはできません。 HadoopとCassandraを同じノードに配置することになります。
多くの書き込みがある場合（私たちはバックアップsysyemのバックエンドで試したことがある）、私の経験から、アーカイブ（一度書き込む - 多くを読み込む）はCassandraにとって最適なケースではありません。あなたのコンパクション戦略に応じて、あなたはそれを持つためにスペースでもiopsでも支払うでしょう。追加された変更はSSTable階層を介して伝播され、元の変更よりも多くの書き込みが行われます。
他の変数を知らなくても、フルであなたの質問に答えることはできません。どのくらいのハードウェア（サーバ、そのRAM/CPU/HDD/SSD）あなたは割り当てするつもりですか？それぞれの「レポート」エントリのサイズはどれくらいですか？あなたは毎日何度読んだり書いたりしますか？今あなたのアーカイブストレージはどれくらいですか？
カサンドラは正常に動作する可能性があります。 2つのテーブル、レポート、レポートを保管してください。書き込み増幅を最小限に抑えるために
CREATE TABLE reports (
...
) WITH default_time_to_live = 86400;
CREATE TABLE reports_archive (
...
) WITH default_time_to_live = 86400 * 365 * 7;
を使用して、新しいタイムウィンドウ圧縮戦略（のTWC）：TTL 24の時間と7年を使用してスキーマを定義します。レポートメタデータを格納し、別々のテーブルにバイナリデータを報告することは有益です。
ロールアップ解析の場合は、Spark with Cassandraを使用してください。データのサイズについては言及していませんが、Cassandraノードあたり約1〜3 TBと言えばうまく動作します。 RF = 3を使うと、少なくとも3つのノードが必要になります。