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 D5A08DB80 for ; Thu, 16 Aug 2012 12:30:06 +0000 (UTC) Received: (qmail 64566 invoked by uid 500); 16 Aug 2012 12:30:04 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 63863 invoked by uid 500); 16 Aug 2012 12:29:57 -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 63835 invoked by uid 99); 16 Aug 2012 12:29:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Aug 2012 12:29:56 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [192.174.58.133] (HELO XEDGEB.nrel.gov) (192.174.58.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Aug 2012 12:29:52 +0000 Received: from XHUBA.nrel.gov (10.20.4.58) by XEDGEB.nrel.gov (192.174.58.133) with Microsoft SMTP Server (TLS) id 8.3.245.1; Thu, 16 Aug 2012 06:29:25 -0600 Received: from MAILBOX2.nrel.gov ([fe80::19a0:6c19:6421:12f]) by XHUBA.nrel.gov ([::1]) with mapi; Thu, 16 Aug 2012 06:29:30 -0600 From: "Hiller, Dean" To: "user@cassandra.apache.org" Date: Thu, 16 Aug 2012 06:29:29 -0600 Subject: Re: indexing question related to playOrm on github Thread-Topic: indexing question related to playOrm on github Thread-Index: Ac17qsgaB1QR6PdORB6ZVJ2VS43q2A== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org Yes, the synch may work, and no, I do "not" want a transaction=85I want a d= ifferent kind of eventually consistent That might work. Let's say server 1 sends a mutation (65 is the pk) Remove: <65> Add <65> Server 2 also sends a mutation (65 is the pk) Remove: <65> Add <65> What everyone does not want is to end up with a row that has <65> and = <65>. With the wide row pattern, we would like to have ONE or the ot= her. I am not sure synchronization fixes that=85=85It would be kind of nic= e if the column <65> would not actually be removed until after all se= rvers are eventually consistent AND would keep a reference to the add that = was happening so that when it goes to resolve eventually consistent between= the servers, it would see that <65> is newer and it would decide to = drop the first add completely. Ie. In a full process it might look like this Cassandra node 1 receives remove <65>, add <65> AND in the remov= e column stores info about the add <65> until eventual consistency is = completed Cassandra node 2 one ms later receives remove <65> and <65> AND = in the remove column stores info about the add <65> until eventual con= sistency is completed Eventual consistency starts comparing node 1 and node 2 and finds <65= > is being removed by different servers and finds add info attached to that= . ONLY THE LAST add info is acknowledged and it makes the row consistent a= cross the cluster. That makes everyone's wide row indexing pattern tend to get less corrupt ov= er time. Thanks, Dean From: aaron morton = > Reply-To: "user@cassandra.apache.org" > Date: Wednesday, August 15, 2012 8:26 PM To: "user@cassandra.apache.org" > Subject: Re: indexing question related to playOrm on github 1. Can playOrm be listed on cassandra's list of ORMs? It supports a JQL/H= QL query on a trillion rows in under 100ms (partitioning is the trick so yo= u can JQL a partition) No sure if we have an ORM specific page. If it's a client then feel free to= add it to http://wiki.apache.org/cassandra/ClientOptions I was wondering if cassandra has or will ever support eventual constancy wh= ere it keeps both the REMOVE AND the ADD together such until it is on all 3= replicated nodes and in resolving the consistency would end up with an ind= ex that only has the very last one in the index. Not sure I fully understand but it sounds like you want a transaction, whic= h is not going to happen. Internally when Cassandra updates a secondary index it does the same thing.= But it synchronises updates around the same row so one thread will apply t= he changes at a time. Hope that helps. ----------------- Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 16/08/2012, at 12:34 PM, "Hiller, Dean" > wrote: 1. Can playOrm be listed on cassandra's list of ORMs? It supports a JQL/H= QL query on a trillion rows in under 100ms (partitioning is the trick so yo= u can JQL a partition) 2. Many applications have a common indexing problem and I was wondering if= cassandra has or could have any support for this in the future=85. When using wide row indexes, you frequently have . as the composite key. This means when you have your object like so in th= e database Activity { pk: 65 name: bill } And then two servers want to save it as Activity { pk:65 name:tim } Activity { pk:65 name:mike } Each server will remove <65> and BOTH servers will add <65> AND = <65> BUT one of them will really be a lie!!!!! I was wondering if ca= ssandra has or will ever support eventual constancy where it keeps both the= REMOVE AND the ADD together such until it is on all 3 replicated nodes and= in resolving the consistency would end up with an index that only has the = very last one in the index. Thanks, Dean