[ https://issues.apache.org/jira/browse/CASSANDRA-7520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15120402#comment-15120402 ]
Jeremy Hanna commented on CASSANDRA-7520: ----------------------------------------- I think this is what [~iamaleksey] was getting at but range scans such as for spark queries would no longer be contiguous. Other than that, it sounds like there are instances where it could be beneficial. > Permit sorting sstables by raw partition key, as opposed to token > ----------------------------------------------------------------- > > Key: CASSANDRA-7520 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7520 > Project: Cassandra > Issue Type: Improvement > Reporter: Benedict > > At the moment we have some counter-intuitive behaviour, which is that with a > hashed partitioner (recommended) the more compacted the data is, the more > randomly distributed it is amongst the file. This means that data access > locality is made pretty much as bad as possible, and we rely on the OS to do > its best to fix that for us with its page cache. > [~jasobrown] mentioned this at the NGCC, but thinking on it some more it > seems that many use cases may benefit from dropping the token at the storage > level and sorting based on the raw key data. For workloads where nearness of > key => likelihood of being coreferenced, this could improve data locality and > cache hit rate dramatically. Timeseries workloads spring to mind, but I doubt > this is constrained to them. Most likely any non-random access pattern could > benefit. A random access pattern would most likely suffer from this scheme, > as we can index more efficiently into the hashed data. However there's no > reason we could not support both schemes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)