3

多くのカウンターを格納する時間別テーブルを維持する必要があります。古いデータは私にとって重要ではないので、いつでも現在の時間別テーブルと前の時間別テーブルだけを保持する予定です。

たとえば。時刻が午後 4 時 30 分の場合、午後 3 時から午後 4 時までの時間別テーブルと、午後 4 時から 4 時 30 分までの現在の時間別テーブルがあります。時間が午後 5 時を超えると、午後 3 時から 4 時までのテーブルを削除します。

1 時間ごとの各テーブルは最大サイズ 7 ～ 8 GB まで拡大し、クエリは高度な同時実行および書き込み指向です (10:1 書き込み: 読み取り、1 秒あたり平均 20,000 回の書き込み、および 1 秒あたり 2000 回の読み取り)。

データのサイズが小さく (私のデータベースでは最大 10 GB)、すべてのクエリがカウンターの増分であるため、Cassandra (カウンター列) のようなキー val ストアまたは Redis のようなインメモリ データベースを使用する必要があります。(膨大な書き込み負荷を分割するためにデータベースを分割する予定です)?

ありがとう。

4

1 に答える 1

1

これは、メモリ内処理のタスクのように思えます。HashMap は、最速のデータベースよりもはるかに高速です。したがって、hazelcast (http://www.hazelcast.com/) または storm (https://github.com/nathanmarz/storm) を参照することをお勧めします。

クエリを簡単にするために、一部のインメモリ DB (Redis や Memcached など) へのカウンターの定期的なダンプが行われる場合があります。ただし、DB バックエンドがまったくなくても、純粋にメモリ内で実行できます。

Cassandra はそのタスクにはやり過ぎのように見えます。テラバイト単位のデータをレプリケートされた高可用性の方法で永久に保存する必要がある場合、Cassandra は驚くべきものですが、以前にそれを行ったことがない場合、高負荷用に設定するのは簡単なことではありません。

于 2012-09-18T22:50:00.187 に答える