Cassandra DB user data size estimation (per table)

The formula provided is a pure estimate of the size of the partition only.
In the formula, Nr represents the number of CQL lines stored in the partition.

Apache Cassandra can store partitions that are tied to partition keys divided according to the values in the clustering column.For example, in the following table definitions,

CREATE TABLE events(
  event_id text,
  event_time int,
  value text,
  PRIMARY KEY(event_id), event_time)
);

The first column event_id in the PRIMARY KEY definition is the partition key and the event_time is the clustering column.
If you INSERT the following two into this table,

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

Roughly enough, it will be stored in Cassandra as follows:

 ---------------------------------------------
| 'event1' | 1 | 'aaa' | 2 | 'bbb' |
------------------------------------

If you apply this to the sizing formula,

• CkPartition Key='event1'
• CsStatic column=none
• NrCQL lines=2
• CrColumns = 'aaa' and 'bbb'
• CcClustering columns=1 and 2

will be .(You can ignore the Nv... part because it is a timestamp that you want to keep internally.)

If there is no clustering column, the expression Nr is always 1.

Apart from the above, the replication factor and compaction overhead are important when sizing.
The replication factor is what you set when defining a key space and will have several copies of the data.If the replication factor is 3, it keeps three copies of one data in the cluster, so you keep three times as much data per node.

Additionally, the overhead of the compaction is to ensure that the data on the Apache Cassandra disk is immutable and that there is space required to perform the merge operation.In the worst case scenario, you need the same amount of free space as the data you have.