Same problem here. But can't understand why to use TimeUUID instead just long. it make the same job and much more simple
On Tue, Dec 22, 2009 at 2:48 PM, Daniel Lundin <d...@eintr.org> wrote: > I'm pondering order preservation and TimeUUID keys, in particular how to > get distribution across the cluster while maintaining "rangeability". > > Basically, I'm working on a logging app, where rows are TimeUUIDs. To be > able to do range scans we're using OrderPreservingPartitioner. > > To get partitioning working, I've currently transformed keys, prepending > a partitioning token (in my testcase, the day-of-week). > Basically, this means two range queries to get data for a set spanning > two days. Crude, but kinda works, and the specialization is alright for > my case. But it feels a bit hackish, so I begun studying the partitioner > code a bit, seeking enlightenment. > > Has anybody already spent energy + time thinking about generic TimeUUID > partitioning? Seems like it could be a useful thing, since time series > data is quite common. > > Perhaps a TimeUUIDPartitioner with configurable time resolution for > tokenization (token = uuid.time % resolution, more or less) would be > sufficient? > > Or could it be even more general, i e no configuration necessary? > > /d >
