# Using a clustering key, impact on performance, data distribution and partition size

**URL:** https://forum.scylladb.com/t/using-a-clustering-key-impact-on-performance-data-distribution-and-partition-size/2205
**Category:** ScyllaDB
**Tags:** data-model, performance, large-partitions, hot-partition
**Created:** [June 24, 2024, 4:54am UTC](https://forum.scylladb.com/t/using-a-clustering-key-impact-on-performance-data-distribution-and-partition-size/2205 "2024-06-24T04:54:53Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![Guy](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.scylladb.com/guy/32/9_2.png) [@Guy](https://forum.scylladb.com/u/Guy)
#### Post date: [June 24, 2024, 4:54am UTC](https://forum.scylladb.com/t/using-a-clustering-key-impact-on-performance-data-distribution-and-partition-size/2205/1 "2024-06-24T04:54:53Z")

</div>

> [@](#):
>
> [**Originally from the User Slack**](https://scylladb-users.slack.com/)
> 
> ![Bohdan_Smal](https://us1.discourse-cdn.com/flex016/uploads/scylladb/original/1X/7aadc5e3279ec32b46fc927c8a218c4b9f3cd6ad.jpeg) **@Bohdan\_Smal:** Hello everyone,  
> I have a somewhat general question. Could you please advise on the potential risks of not using a clustering key?  
> Currently, we have a table where the primary key is a combination of brand and client\_id, and the clustering key is transaction\_id. We have observed that we could achieve better performance and more even data distribution if we don’t use a clustering key. Instead, we would set the primary key as transaction\_id, brand, and client\_id.  
> This way, each transaction becomes a separate partition, ensuring no imbalance in partition distribution across nodes, even if some clients have more transactions. However, we are not fully aware of the potential risks associated with having a large number of partitions.  
> Can anyone explain the possible risks of this approach?  
> Thank you!
> 
> **@Karol\_Baryła:** I’m not sure what are the performance implications of large number of partitions. What comes to my mind is usability. With such a schema you can’t e.g:  
> • Select all transactions for a given user without using `ALLOW FILTERING` and making the query much slower this way.  
> • Use LWT / Batches with LWT to atomically update several transactions for a given user.
> 
> ![Bohdan_Smal](https://us1.discourse-cdn.com/flex016/uploads/scylladb/original/1X/7aadc5e3279ec32b46fc927c8a218c4b9f3cd6ad.jpeg) **@Bohdan\_Smal:** Got it, thank you for your response. Have a great day!
> 
> ![avi](https://us1.discourse-cdn.com/flex016/uploads/scylladb/original/1X/b5e08becda8d9df1abff1d3a2d9ffe1126ac3fc6.jpeg) **@avi:** In fact having more and smaller partitions is better than having fewer and larger partitions. So if you don’t need a clustering key for sorting and grouping, don’t use it.
> 
> ![Bohdan_Smal](https://us1.discourse-cdn.com/flex016/uploads/scylladb/original/1X/7aadc5e3279ec32b46fc927c8a218c4b9f3cd6ad.jpeg) **@Bohdan\_Smal:** thank you)