Cassandra - Composite Partition Keys and Performance

1
votes

I am working on the keyspace and tables for a Cassandra environment. I understand the size limitations of Cassandra and dealing with Partition keys to keep it optimized. However, I am having a disagreement with a developer regarding how to handle the keys. Is there any downside in having a key that would include a large number of data rather than a small amount of data. For example,

I have 100k records. I can create a key that will partition this into 10k; I could also create a key that will partition this into 10 records (by day). So either I store 10k and 10 partitions or 10 records and 10,000 partitions.

1
cassandra
10k in 10 partitions sounds good to me as long as the records are not huge. Rule of thumb is the ideal partition size is 100mb, and then you can read the entire days records in a single read (or broken up by fetch size) efficiently. Perhaps sharing your two schemas your considering and how you want to query them and people can give more insight - Chris Lohfink

1 Answers

2
votes

Keep in mind that having more columns in the key requires you to specify those columns in your select statements, which sometimes isn't desired. The more partitions the better - whether by picking a better single column or having multiple columns.

Cassandra reads data via the partition key, and can get help with performance if clustering columns are used. If you have a large partition, the entire partition must be read (memory and disk) and then merged for the output. If you have large partitions, this will definitely slow you down.