Thank you Jeff, So, if I understood your email correctly, there is no restriction but I should be using clustering for performance reasons. I am expecting to store 10B rows per year in this table and each row will have a user defined type with an approx size of 1500 bytes. The access to the data in this table will be random as it stores the "raw" data. There will be other tables with processed data organized by time in a clustering column to access in sequence for the system. Each row represents an event and it has a UUID which I am planning to use as the partition key. Should I find another field for the partition and use the UUID for the clustering instead?
F Javier Pareja On Wed, Mar 7, 2018 at 2:36 PM, Jeff Jirsa <jji...@gmail.com> wrote: > There is no limit > > The token range of murmur3 is 2^64, but Cassandra properly handles token > overlaps (we use a key that’s effectively a tuple of the token/hash and the > underlying key itself), so having more than 2^64 partitions won’t hurt > anything in theory > > That said, having that many partitions would be an incredibly huge data > set, and unless modeled properly, would be very likely to be unwieldy in > practice. > > Tables without clustering keys are often deceptively expensive to compact, > as a lot of work (relative to the other cell boundaries) happens on > partition boundaries. > > -- > Jeff Jirsa > > > > On Mar 7, 2018, at 3:06 AM, Javier Pareja <pareja.jav...@gmail.com> > wrote: > > > > Hello all, > > > > I have been trying to find an answer to the following but I have had no > luck so far: > > Is there any limit to the number of partitions that a table can have? > > Let's say a table has a partition key an no clustering key, is there a > recommended limit on the number of values that this partition key can have? > Is it recommended to have a clustering key to reduce this number by storing > several rows in each partition instead of one row per partition. > > > > Regards, > > > > F Javier Pareja > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org > For additional commands, e-mail: user-h...@cassandra.apache.org > >
