Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <4EBF0865.6000600@gmail.com>
References: <4EBC2754.2080700@gmail.com>
	<4EBF0865.6000600@gmail.com>
Date: Sat, 12 Nov 2011 18:41:09 -0800
Message-ID: 
 <CAL+hLkQZgMTW8s8+qBdukdgHRBUOGu3+cPE7S_Bu5sbKQHAQ7A@mail.gmail.com>
Subject: Re: indexes from CassandraSF
From: Ed Anuff <ed@anuff.com>
To: user@cassandra.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

1) The index updates should be eventually consistent.  This does mean
that you can get a transient false-positive on your search results.
If this doesn't work for you, then you either need to use ZK or some
other locking solution or do "read repair" by making sure that the row
you retrieve contains the value you're searching for before passing it
on to the rest of your applicaiton.

2)  You should be able to reapply the batch updates til they succeed.
The update is idempotent.  One thing that's important that the slides
don't make clear is that this requires using time-based uuids as your
timestamp components.  Take a look at the sample code.

Hope this helps,

Ed

On Sat, Nov 12, 2011 at 3:59 PM, Guy Incognito <dnd1066@gmail.com> wrote:
> help?
>
> On 10/11/2011 19:34, Guy Incognito wrote:
>>
>> hi,
>>
>> i've been looking at the model below from Ed Anuff's presentation at
>> Cassandra CF (http://www.slideshare.net/edanuff/indexing-in-cassandra).
>> =A0Couple of questions:
>>
>> 1) Isn't there still the chance that two concurrent updates may end up
>> with the index containing two entries for the given user, only one of wh=
ich
>> would be match the actual value in the Users cf?
>>
>> 2) What happens if your batch fails partway through the update? =A0If i
>> understand correctly there are no guarantees about ordering when a batch=
 is
>> executed, so isn't it possible that eg the previous
>> value entries in Users_Index_Entries may have been deleted, and then the
>> batch fails before the entries in Indexes are deleted, ie the mechanism =
has
>> 'lost' those values? =A0I assume this can be addressed
>> by not deleting the old entries until the batch has succeeded (ie put th=
e
>> previous entry deletion into a separate, subsequent batch). =A0this at l=
east
>> lets you retry at a later time.
>>
>> perhaps i'm missing something?
>>
>> SELECT {"location"}..{"location", *}
>> FROM Users_Index_Entries WHERE KEY =3D <user_key>;
>>
>> BEGIN BATCH
>>
>> DELETE {"location", ts1}, {"location", ts2}, ...
>> FROM Users_Index_Entries WHERE KEY =3D <user_key>;
>>
>> DELETE {<value1>, <user_key>, ts1}, {<value2>, <user_key>, ts2}, ...
>> FROM Indexes WHERE KEY =3D "Users_By_Location";
>>
>> UPDATE Users_Index_Entries SET {"location", ts3} =3D <value3>
>> WHERE KEY=3D<user_key>;
>>
>> UPDATE Indexes SET {<value3>, <user_key>, ts3) =3D null
>> WHERE KEY =3D "Users_By_Location";
>>
>> UPDATE Users SET location =3D <value3>
>> WHERE KEY =3D <user_key>;
>>
>> APPLY BATCH
>>
>
>