You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Paul Prescod <pa...@prescod.net> on 2010/04/08 00:13:05 UTC
Is this sentence slightly inaccurate
"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 "insertion point" tend to be replicated on more than one
node in most configurations? Does every "insertion point" exist on a
single "primary" machine or are writes load-balanced to
ReplicationFactor nodes? I presume that writes can fail-over, so I
cannot see why they could not be load balanced.
===
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 have meant by that?
Paul
Re: Is this sentence slightly inaccurate
Posted by Eric Evans <ee...@rackspace.com>.
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, this isn't very good IMO, (incomplete and misleading at best).
> http://wiki.apache.org/cassandra/StorageConfiguration
>
> Wouldn't the "insertion point" tend to be replicated on more than one
> node in most configurations? Does every "insertion point" exist on a
> single "primary" machine or are writes load-balanced to
> ReplicationFactor nodes? I presume that writes can fail-over, so I
> cannot see why they could not be load balanced.
Keys are routed to a node based on the key and the partitioner used.
Replica placement is based off of this location (node). In the simple
case (rack-unaware strategy), this is simply the next N-1 nodes.
> 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 have meant by
> that?
Using key enumeration when you no longer know what your keys are? I
dunno. I imagine that whatever he was referring to, it's no longer worth
mentioning in the context of the OrderPreservingPartitioner since you
can also enumerate keys with RandomPartitioner (that wasn't always the
case).
--
Eric Evans
eevans@rackspace.com
Re: Is this sentence slightly inaccurate
Posted by David Strauss <da...@fourkitchens.com>.
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 all rows and prune stuff.
--
David Strauss
| david@fourkitchens.com
Four Kitchens
| http://fourkitchens.com
| +1 512 454 6659 [office]
| +1 512 870 8453 [direct]
Re: Is this sentence slightly inaccurate
Posted by Brandon Williams <dr...@gmail.com>.
On Thu, Apr 8, 2010 at 2:38 PM, Peter Chang <pe...@gmail.com> 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
Re: Is this sentence slightly inaccurate
Posted by Peter Chang <pe...@gmail.com>.
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 <dr...@gmail.com> wrote:
> On Thu, Apr 8, 2010 at 1:26 PM, Peter Chang <pe...@gmail.com> 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.
>
>
> 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.
>
> -Brandon
>
Re: Is this sentence slightly inaccurate
Posted by Brandon Williams <dr...@gmail.com>.
On Thu, Apr 8, 2010 at 1:26 PM, Peter Chang <pe...@gmail.com> 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.
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.
-Brandon
Re: Is this sentence slightly inaccurate
Posted by Peter Chang <pe...@gmail.com>.
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 <b...@b3k.us> wrote:
> It was not, but is now.
>
> On Wed, Apr 7, 2010 at 4:23 PM, David Strauss <da...@fourkitchens.com>
> 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 longer know all your row keys. With OPP and
> >> range queries, you can discover them. Cold comfort, imo.
> >
> > Is it possible to iterate through RP keys? I've gotten mixed answers.
> >
> > --
> > David Strauss
> > | david@fourkitchens.com
> > Four Kitchens
> > | http://fourkitchens.com
> > | +1 512 454 6659 [office]
> > | +1 512 870 8453 [direct]
> >
> >
>
Re: Is this sentence slightly inaccurate
Posted by Benjamin Black <b...@b3k.us>.
It was not, but is now.
On Wed, Apr 7, 2010 at 4:23 PM, David Strauss <da...@fourkitchens.com> 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 longer know all your row keys. With OPP and
>> range queries, you can discover them. Cold comfort, imo.
>
> Is it possible to iterate through RP keys? I've gotten mixed answers.
>
> --
> David Strauss
> | david@fourkitchens.com
> Four Kitchens
> | http://fourkitchens.com
> | +1 512 454 6659 [office]
> | +1 512 870 8453 [direct]
>
>
Re: Is this sentence slightly inaccurate
Posted by David Strauss <da...@fourkitchens.com>.
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. Cold comfort, imo.
Is it possible to iterate through RP keys? I've gotten mixed answers.
--
David Strauss
| david@fourkitchens.com
Four Kitchens
| http://fourkitchens.com
| +1 512 454 6659 [office]
| +1 512 870 8453 [direct]
Re: Is this sentence slightly inaccurate
Posted by Benjamin Black <b...@b3k.us>.
On Wed, Apr 7, 2010 at 3:13 PM, Paul Prescod <pa...@prescod.net> 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 have meant by that?
>
>
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. Cold comfort, imo.
b