Cassandra Total Space Calculation

It depends.

Data in cassandra is stored gzipped when you use the LZ4Compressor, which is default. If we omit the compression rate at all for simplicity reasons, you could use this tool to calculate the node load:

https://www.ecyrd.com/cassandracalculator/

With a cluster size of 6 i would suggest a RF=3, meaning each node would have to hold 50% of data, which is 5TB in your case then (uncompressed).

Even with a RF=1 (which you should not use) each node would have to hold 17% of the total data.

This is good question that is relatively hard to answer. The sizing of the Cassandra nodes really depends on the number of factors, not only on the size of the data:

• you need to take into account denormalization of your data to be able to run queries that you need to execute
• what kind of data you're storing in the database - numbers, text, binary, etc. - this will affect the compression ratio if you're using compression. (I've seen different values - from compressing to the 10% of original data size, to the negative compression ratios, when data is not compressable)
• partitioning schema for tables (wide vs narrow partitions, because for hot data with narrow partitions you may need to disable compression, etc.)
• you need to take into account the overhead of storing metadata, such as TTL & writetime (the more columns you have, higher will be overhead)
• you need to take into account the recommendation about free disk space that is necessary for maintenance tasks, like, compaction, snapshots, etc.
• ...

Typically, it's recommended to create a test environment (for example, on AWS), and perform data generation & load testing to find the right size for hardware, and understand how much data will be stored on the disk. I personally can recommend to use NoSQLBench that is high performance & very flexible regarding the data generation - there is a big number of existing schemas that could be used for initial testing, and you can create your own schemas as well. (You can still use built-in cassandra-stress, but it's less flexible. There is also tlp-stress, but it also could be slightly less flexible than NoSQLBench)

There is a number of existing documents that may help with capacity planning, and tuning, like (there is much more, of course):

• Capacity planning and hardware selection for Apache Cassandra implementations
• Data model and schema configuration checks
• Schema configuration tuning
• Testing your cluster before production
• ...

Regarding your specific setup, with recommended RF=3 and 6 nodes, and reserved disk space (the pessimistic case is 50% of all disk space, we can say that it could be 30-35% of disk space), your cluster may store ~2.5-2.6Tb of data (without use of any compression): (2Tb x 0.65 x 6)/3. To get it store 10Tb of data, your compression ratio should be ~25% of original size, but this may not possible for your data.

Cassandra cluster sizing depends on multiple factors not only on raw data as it appears into RDBMS.

Consistency - You should consider your read/write consistency and accordingly you have to decide your RF(replication factor) Data modeling - You have to make sure your data model, need to take care about partitioning and collections you are using. Compaction strategy - In Cassandra, three types of compaction strategies are available. All are for different purpose like

1. STCS is good for write
2. LCS is good for read
3. TWCS is good for time-series where we are aware about TTL.

and you have to make sure around 50% of disk are free for these compactions.