From user-return-22167-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Wed Nov 9 10:54:11 2011 Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 224C2727A for ; Wed, 9 Nov 2011 10:54:11 +0000 (UTC) Received: (qmail 69022 invoked by uid 500); 9 Nov 2011 10:54:09 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 68998 invoked by uid 500); 9 Nov 2011 10:54:08 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 68990 invoked by uid 99); 9 Nov 2011 10:54:08 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Nov 2011 10:54:08 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jakers@gmail.com designates 209.85.161.172 as permitted sender) Received: from [209.85.161.172] (HELO mail-gx0-f172.google.com) (209.85.161.172) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Nov 2011 10:54:02 +0000 Received: by ggnv1 with SMTP id v1so1905151ggn.31 for ; Wed, 09 Nov 2011 02:53:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=TYyf5WX4P2TKwb2+96P4aTXkg7K+2uOGudrdswdKi6w=; b=EtsCNiuEiCvWp2VooIywoUU/uldoC06rswfTE1PpJ+RSjxhpUcFcS4k55WWAbuiIeC 5HFSs0VSa9pkRDjRzbsYTCukH1rbAlBVqswSNOPQLdr0LDZHgzqgTlFTkKTxARPYMd+B D0OP63Zrt+oUEf4nXabApPjC0a38kLKboPYmg= Received: by 10.68.17.193 with SMTP id q1mr4279219pbd.98.1320836021111; Wed, 09 Nov 2011 02:53:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.169.4 with HTTP; Wed, 9 Nov 2011 02:53:20 -0800 (PST) In-Reply-To: References: <33B8FB45-22A6-47B8-9112-C57331541EEF@gmx.net> From: Jake Luciani Date: Wed, 9 Nov 2011 10:53:20 +0000 Message-ID: Subject: Re: Second Cassandra users survey To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=bcaec520ea43d84d3504b14b1951 X-Virus-Checked: Checked by ClamAV on apache.org --bcaec520ea43d84d3504b14b1951 Content-Type: text/plain; charset=ISO-8859-1 Hi Todd, Entity Groups : https://issues.apache.org/jira/browse/CASSANDRA-1684 -Jake On Wed, Nov 9, 2011 at 6:44 AM, Todd Burruss wrote: > I believe I heard someone talk at Cassandra SF conference about creating a > partitioner that was a derivation of RandomPartitioner. It essentially > would look for keys that adhere to a certain pattern, like :. > The portion would be used for determining the location on the ring, > but : for actually storing. This would allow groups of data > (all having the same ) to reside on the same node, while still > maintaining uniqueness across the entire keyspace. > > Unbalanced nodes could still occur, but I don't think any worse than > wide/large rows can cause. > > > On 11/8/11 1:29 AM, "Daniel Doubleday" wrote: > > >Ah cool - thanks for the pointer! > > > >On Nov 7, 2011, at 5:25 PM, Ed Anuff wrote: > > > >> This is basically what entity groups are about - > >> https://issues.apache.org/jira/browse/CASSANDRA-1684 > >> > >> On Mon, Nov 7, 2011 at 5:26 AM, Peter Lin wrote: > >>> This feature interests me, so I thought I'd add some comments. > >>> > >>> Having used partition features in existing databases like DB2, Oracle > >>> and manual partitioning, one of the biggest challenges is keeping the > >>> partitions balanced. What I've seen with manual partitioning is that > >>> often the partitions get unbalanced. Usually the developers take a > >>> best guess and hope it ends up balanced. > >>> > >>> Some of the approaches I've used in the past were zip code, area code, > >>> state and some kind of hash. > >>> > >>> So my question related deterministic sharding is this, "what rebalance > >>> feature(s) would be useful or needed once the partitions get > >>> unbalanced?" > >>> > >>> Without a decent plan for rebalancing, it often ends up being a very > >>> painful problem to solve in production. Back when I worked mobile > >>> apps, we saw issues with how OpenWave WAP servers partitioned the > >>> accounts. The early versions randomly assigned a phone to a server > >>> when it is provisioned the first time. Once the phone was associated > >>> to that server, it was stuck on that server. If the load on that > >>> server was heavier than the others, the only choice was to "scale up" > >>> the hardware. > >>> > >>> My understanding of Cassandra's current sharding is consistent and > >>> random. Does the new feature sit some where in-between? Are you > >>> thinking of a pluggable API so that you can provide your own hash > >>> algorithm for cassandra to use? > >>> > >>> > >>> > >>> On Mon, Nov 7, 2011 at 7:54 AM, Daniel Doubleday > >>> wrote: > >>>> Allow for deterministic / manual sharding of rows. > >>>> > >>>> Right now it seems that there is no way to force rows with different > >>>>row keys will be stored on the same nodes in the ring. > >>>> This is our number one reason why we get data inconsistencies when > >>>>nodes fail. > >>>> > >>>> Sometimes a logical transaction requires writing rows with different > >>>>row keys. If we could use something like this: > >>>> > >>>> prefix.uniquekey and let the partitioner use only the prefix the > >>>>probability that only part of the transaction would be written could > >>>>be reduced considerably. > >>>> > >>>> > >>>> > >>>> On Nov 1, 2011, at 11:59 PM, Jonathan Ellis wrote: > >>>> > >>>>> Hi all, > >>>>> > >>>>> Two years ago I asked for Cassandra use cases and feature requests. > >>>>> [1] The results [2] have been extremely useful in setting and > >>>>> prioritizing goals for Cassandra development. But with the release > >>>>>of > >>>>> 1.0 we've accomplished basically everything from our original wish > >>>>> list. [3] > >>>>> > >>>>> I'd love to hear from modern Cassandra users again, especially if > >>>>> you're usually a quiet lurker. What does Cassandra do well? What > >>>>>are > >>>>> your pain points? What's your feature wish list? > >>>>> > >>>>> As before, if you're in stealth mode or don't want to say anything in > >>>>> public, feel free to reply to me privately and I will keep it off the > >>>>> record. > >>>>> > >>>>> [1] > >>>>> > http://www.mail-archive.com/cassandra-dev@incubator.apache.org/msg0114 > >>>>>8.html > >>>>> [2] > >>>>> > http://www.mail-archive.com/cassandra-user@incubator.apache.org/msg014 > >>>>>46.html > >>>>> [3] > >>>>>http://www.mail-archive.com/dev@cassandra.apache.org/msg01524.html > >>>>> > >>>>> -- > >>>>> Jonathan Ellis > >>>>> Project Chair, Apache Cassandra > >>>>> co-founder of DataStax, the source for professional Cassandra support > >>>>> http://www.datastax.com > >>>> > >>>> > >>> > > > > -- http://twitter.com/tjake --bcaec520ea43d84d3504b14b1951 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Todd,


-Jake

On Wed, Nov 9, 2011 at 6:44 AM, Todd Burruss <bburruss@expedia.com> wrote:=
I believe I heard someone talk at Cassandra SF conference about creating a<= br> partitioner that was a derivation of RandomPartitioner. =A0It essentially would look for keys that adhere to a certain pattern, like <key>:<= subkey>.
=A0The <key> portion would be used for determining the location on th= e ring,
but <key>:<subkey> for actually storing. =A0This would allow gr= oups of data
(all having the same <key>) to reside on the same node, while still maintaining uniqueness across the entire keyspace.

Unbalanced nodes could still occur, but I don't think any worse than wide/large rows can cause.


On 11/8/11 1:29 AM, "Daniel Doubleday" <daniel.doubleday@gmx.net> wrote:

>Ah cool - thanks for the pointer!
>
>On Nov 7, 2011, at 5:25 PM, Ed Anuff wrote:
>
>> This is basically what entity groups are about -
>> https://issues.apache.org/jira/browse/CASSANDRA-1684 >>
>> On Mon, Nov 7, 2011 at 5:26 AM, Peter Lin <woolfel@gmail.com> wrote:
>>> This feature interests me, so I thought I'd add some comme= nts.
>>>
>>> Having used partition features in existing databases like DB2,= Oracle
>>> and manual partitioning, one of the biggest challenges is keep= ing the
>>> partitions balanced. What I've seen with manual partitioni= ng is that
>>> often the partitions get unbalanced. Usually the developers ta= ke a
>>> best guess and hope it ends up balanced.
>>>
>>> Some of the approaches I've used in the past were zip code= , area code,
>>> state and some kind of hash.
>>>
>>> So my question related deterministic sharding is this, "w= hat rebalance
>>> feature(s) would be useful or needed once the partitions get >>> unbalanced?"
>>>
>>> Without a decent plan for rebalancing, it often ends up being = a very
>>> painful problem to solve in production. Back when I worked mob= ile
>>> apps, we saw issues with how OpenWave WAP servers partitioned = the
>>> accounts. The early versions randomly assigned a phone to a se= rver
>>> when it is provisioned the first time. Once the phone was asso= ciated
>>> to that server, it was stuck on that server. If the load on th= at
>>> server was heavier than the others, the only choice was to &qu= ot;scale up"
>>> the hardware.
>>>
>>> My understanding of Cassandra's current sharding is consis= tent and
>>> random. Does the new feature sit some where in-between? Are yo= u
>>> thinking of a pluggable API so that you can provide your own h= ash
>>> algorithm for cassandra to use?
>>>
>>>
>>>
>>> On Mon, Nov 7, 2011 at 7:54 AM, Daniel Doubleday
>>> <daniel.doubled= ay@gmx.net> wrote:
>>>> Allow for deterministic / manual sharding of rows.
>>>>
>>>> Right now it seems that there is no way to force rows with= different
>>>>row keys will be stored on the same nodes in the ring.
>>>> This is our number one reason why we get data inconsistenc= ies when
>>>>nodes fail.
>>>>
>>>> Sometimes a logical transaction requires writing rows with= different
>>>>row keys. If we could use something like this:
>>>>
>>>> prefix.uniquekey and let the partitioner use only the pref= ix the
>>>>probability that only part of the transaction would be writ= ten could
>>>>be reduced considerably.
>>>>
>>>>
>>>>
>>>> On Nov 1, 2011, at 11:59 PM, Jonathan Ellis wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Two years ago I asked for Cassandra use cases and feat= ure requests.
>>>>> [1] =A0The results [2] have been extremely useful in s= etting and
>>>>> prioritizing goals for Cassandra development. =A0But w= ith the release
>>>>>of
>>>>> 1.0 we've accomplished basically everything from o= ur original wish
>>>>> list. [3]
>>>>>
>>>>> I'd love to hear from modern Cassandra users again= , especially if
>>>>> you're usually a quiet lurker. =A0What does Cassan= dra do well? =A0What
>>>>>are
>>>>> your pain points? =A0What's your feature wish list= ?
>>>>>
>>>>> As before, if you're in stealth mode or don't = want to say anything in
>>>>> public, feel free to reply to me privately and I will = keep it off the
>>>>> record.
>>>>>
>>>>> [1]
>>>>>http://www.mail-archive.com/c= assandra-dev@incubator.apache.org/msg0114
>>>>>8.html
>>>>> [2]
>>>>>http://www.mail-archive.com/c= assandra-user@incubator.apache.org/msg014
>>>>>46.html
>>>>> [3]
>>>>>http://www.mail-archive.com/dev@c= assandra.apache.org/msg01524.html
>>>>>
>>>>> --
>>>>> Jonathan Ellis
>>>>> Project Chair, Apache Cassandra
>>>>> co-founder of DataStax, the source for professional Ca= ssandra support
>>>>> = http://www.datastax.com
>>>>
>>>>
>>>
>




--
= http://twitter.com/t= jake
--bcaec520ea43d84d3504b14b1951--