my five cents - token and key are not same. it was like this long time ago (single MD5 assumed single key)
if you want ordered, you probably can arrange your data in a way so you can get it in ordered fashion. for example long ago, i had single column family with single key and about 2-3 M columns - I do not suggest you to do it this way, because is wrong way, but it is easy to understand the idea. I also had idea for semi-ordered partitioner - instead of single MD5, to have two MD5's. then you can get semi-ordered ranges, e.g. you get ordered all cities in Canada, all cities in US and so on. however in this way things may get pretty non-ballanced Nick On Thu, Aug 22, 2013 at 11:19 AM, Takenori Sato <ts...@cloudian.com> wrote: > Hi, > > I am trying to implement a custom partitioner that evenly distributes, yet > preserves order. > > The partitioner returns a token by BigInteger as RandomPartitioner does, > while does a decorated key by string as OrderPreservingPartitioner does. > * for now, since IPartitioner<T> does not support different types for > token and key, BigInteger is simply converted to string > > Then, I played around with cassandra-cli. As expected, in my 3 nodes test > cluster, get/set worked, but list(get_range_slices) didn't. > > This came from a challenge to overcome a wide row scalability. So, I want > to make it work! > > I am aware that some efforts are required to make get_range_slices work. > But are there any other critical problems? For example, it seems there is > an assumption that token and key are the same. If this is throughout the > whole C* code, this partitioner is not practical. > > Or have your tried something similar? > > I would appreciate your feedback! > > Thanks, > Takenori >
