

Cassandra DB3.0でのテーブルのディスク使用量の見積りに関してです。  
以下の２つの式にてPartitionのサイズを見積もると思います。

Nv = Nr Nc − Npk − Ns + Ns  
[![画像の説明をここに入力](https://i.stack.imgur.com/5vuWB.png)](https://i.stack.imgur.com/5vuWB.png)

この場合、Partion単位なのでテーブル単位で見積もるには各Partitionサイズの  
総和が必要かと思います。  
今現在、見積りが必要とされているテーブルはPartitionキーのみのPKなので、  
Nrをテーブルの全行としてテーブル単位の見積りとしています。

ですが、この値は単にデータを投入しただけのテーブルのDISKサイズの数倍になります。  
これは、各トランザクション（特にTRANCATEなどのsnapshotを作りかねないもの等）に  
向けてコンパクションまでにDISK容量が耐えられる様にという認識で正しいでしょうか。

私はそうだと思っているのですが、何分Cassandraのスキルが無いので、ユーザより他から  
の根拠を求められています。

ご存知の方が居られたら、教えて頂けないでしょうか。

何卒よろしくお願い申し上げます。


CC BY-SA 4.0
2020-04-03T08:55:44.960
65330
2022-11-06T12:00:30.073
38178
question
cassandra
Cassandra DBのユーザ・データ・サイズ見積り（テーブル単位）


提示された式は、パーティションのサイズのみを純粋に試算するものです。  
式において、`Nr` はパーティション内に格納されるCQLの行数を表します。

Apache
Cassandraは、パーティションキーに紐づくパーティションを、クラスタリングカラムの値に応じて分割して格納することができます。例えば、以下のようなテーブル定義において、

[code]

    CREATE TABLE events (
      event_id text,
      event_time int,
      value text,
      PRIMARY KEY ((event_id), event_time)
    );
    
[/code]

`PRIMARY KEY` の定義の最初のカラム `event_id` がパーティションキー、 `event_time` がクラスタリングカラムとなります。  
このテーブルに以下の二つをINSERTすると、

[code]

    INSERT INTO events (event_id, event_time, value) VALUES ('event1', 1, 'aaa');
    INSERT INTO events (event_id, event_time, value) VALUES ('event1', 2, 'bbb');
    
[/code]

ざっくりですが、以下のようにCassandraに格納されます。

[code]

    ------------------------------------
    | 'event1' | 1 | 'aaa' | 2 | 'bbb' |
    ------------------------------------
    
[/code]

これをサイジングの式に当てはめると、

  * `Ck` パーティションキー = 'event1'
  * `Cs` スタティックカラム = なし
  * `Nr` CQL行数 = 2
  * `Cr` カラム = 'aaa' と 'bbb'
  * `Cc` クラスタリングカラム = 1 と 2

になります。(Nv...の部分は内部保持するタイムスタンプなどなので無視して構いません。)

クラスタリングカラムがない場合、一つのパーティションには1行しか格納されないため、 式の `Nr` は常に1になります。

上記とは別に、サイジングの際に重要になってくるのが、レプリケーションファクターとコンパクションのオーバーヘッドです。  
レプリケーションファクターは、キースペースの定義時に設定するもので、データのコピーをいくつ持つかになります。レプリケーションファクターが3の場合は、一つのデータに対して3つコピーをクラスター内で保持するため、ノード当たりに保持するデータも3倍になります。

また、コンパクションのオーバーヘッドとは、Apache
Cassandraのディスク上のデータが不変なため、マージ作業を行うために必要な領域を確保しておくことです。最悪のケースでは、保持しているデータと同じサイズの空き容量が必要です。


CC BY-SA 4.0
2020-04-06T08:00:05.177
65397
2020-04-06T08:00:05.177
4157
65330
answer