My experience for the last question is ... it depends. If you have NO changes to the store (which I would argue could be abnormal, it's not in a production environment allowing writes) ... then I you can do a full range/key scan and get no repeats. Factors that will impact scanning all keys include replication factor, actual partitioning, and status of replications.
If you are taking changes while scanning ... what exactly is the semantics of the key scan that you'd expect? For example, would it be acceptable to have a "low" key not be returned because it was in the data store before the full scan ended but you've already gone past that key in your iteration? I think that these questions apply to both ordered and random partitioners. On Wed, Sep 15, 2010 at 3:30 PM, Michal Augustýn <augustyn.mic...@gmail.com>wrote: > And what about uniqueness? Can we be sure that we get each row just once? > > Thanks. > > 2010/9/15 Janne Jalkanen <janne.jalka...@ecyrd.com> > > >> Correct. You can use get_range_slices with RandomPartitioner too, BUT the >> iteration order is non-predictable, that is, you will not know in which >> order you get the rows (RandomPartitioner would probably better be called >> ObscurePartitioner - it ain't random, but it's as good as if it were ;-). >> This I find to be mostly useful when you want to go through your entire >> keyspace, like when doing something map-reduce like. Or you just have a >> fairly small CF. >> >> /Janne >> >> >> On Sep 15, 2010, at 20:26 , Rana Aich wrote: >> >> Hi All, >>> >>> I was under the impression that in order to query with get_range_slices >>> one has to have a OrderPreservingPartitioner. >>> >>> Can we do get_range_slices with RandomPartitioner also? I can distinctly >>> remember I read that(OrderPreservingPartitioner for get_range_slices) in >>> Cassnadra WIKI but now somehow I'm not finding it anymore. >>> >>> Can anyone throw some light on it. >>> >>> Thanks and Regards, >>> >>> Rana >>> >> >> >
