On 2010-04-08 18:29, Brandon Williams wrote:
> The method is the same for both partitioners: get_range_slices. The key
> difference is, with RP you don't really have a useful order, it's based
> on the hash of the row key.
That's fine; I don't care about the order. I just want the ability to
walk
On Thu, Apr 8, 2010 at 2:38 PM, Peter Chang wrote:
> I thought OPP was required for get_range_slices. Is this no longer the case
> for 0.6?
Right, get_range_slices works with either partitioner.
-Brandon
I thought OPP was required for get_range_slices. Is this no longer the case
for 0.6?
On Thu, Apr 8, 2010 at 11:29 AM, Brandon Williams wrote:
> On Thu, Apr 8, 2010 at 1:26 PM, Peter Chang wrote:
>
>> Sorry, I've read through the docs (although not too recently) and have
>> followed this mailing
On Thu, Apr 8, 2010 at 1:26 PM, Peter Chang wrote:
> Sorry, I've read through the docs (although not too recently) and have
> followed this mailing list for a bit. But I haven't seen how it's possible
> to iterate with RP? Could you kindly point out to me where it shows how to
> do this? TIA.
T
Sorry, I've read through the docs (although not too recently) and have
followed this mailing list for a bit. But I haven't seen how it's possible
to iterate with RP? Could you kindly point out to me where it shows how to
do this? TIA.
On Wed, Apr 7, 2010 at 4:37 PM, Benjamin Black wrote:
> It wa
It was not, but is now.
On Wed, Apr 7, 2010 at 4:23 PM, David Strauss wrote:
> On 2010-04-07 23:00, Benjamin Black wrote:
>> If you are using RP and your own, secondary indices, you have no way
>> to access rows except by get on the key. Thus, if you lose or corrupt
>> your indices, you may no l
On 2010-04-07 23:00, Benjamin Black wrote:
> If you are using RP and your own, secondary indices, you have no way
> to access rows except by get on the key. Thus, if you lose or corrupt
> your indices, you may no longer know all your row keys. With OPP and
> range queries, you can discover them.
On Wed, Apr 7, 2010 at 3:13 PM, Paul Prescod wrote:
>
> Also: Dominic Williams says that one of the advantages of the
> OrderPreservingPartitioner is: "3. If you screw up, you can scan over
> your data to recover/delete orphaned keys"
>
> Does anyone know off the top of their head what he might ha
On Wed, 2010-04-07 at 15:13 -0700, Paul Prescod wrote:
> "With OrderPreservingPartitioner the keys themselves are used to place
> on the ring. One of the potential drawbacks of this approach is that
> if rows are inserted with sequential keys, all the write load will go
> to the same node."
Yeah,
"With OrderPreservingPartitioner the keys themselves are used to place
on the ring. One of the potential drawbacks of this approach is that
if rows are inserted with sequential keys, all the write load will go
to the same node."
http://wiki.apache.org/cassandra/StorageConfiguration
Wouldn't the "
10 matches
Mail list logo
