incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eran Kutner <e...@gigya-inc.com>
Subject Re: Questions while evaluating Cassandra
Date Fri, 05 Mar 2010 11:11:46 GMT
Thank you Jonathan!


On Fri, Mar 5, 2010 at 00:03, Jonathan Ellis <jbellis@gmail.com> wrote:
> On Thu, Mar 4, 2010 at 2:51 AM, Eran Kutner <eran@gigya-inc.com> wrote:
>> On Tue, Mar 2, 2010 at 15:44, Jonathan Ellis <jbellis@gmail.com> wrote:
>>>
>>> On Tue, Mar 2, 2010 at 6:43 AM, Eran Kutner <eran@gigya.com> wrote:
>>> > Is the procedure described in the description of ticket CASSANDRA-44 really
>>> > the way to do schema changes in the latest release? I'm not sure what's
your
>>> > thoughts about this but our experience is that every release of our software
>>> > requires schema changes because we add new column families for indexes.
>>>
>>> Yes, that is how it is for 0.5 and 0.6.  0.7 will add online schema
>>> changes (i.e., fix -44), Gary is working on that now.
>>
>> So just to be clear, that would require a complete cluster restart as
>> well as stopping the client app (to prevent new writes from coming in
>> after doing the flush), right? Do you know how others are handling it
>> on a live system?
>
> If you're just adding new CFs then you don't need to worry about the
> commitlog.  So in production just leave the old ones defined and
> remove the data files from the FS, client doesn't have to care, and
> you can do a rolling restart of your cassandra nodes.
>
>>> DatacenterShardStrategy will put multiple replicas in each DC, for use
>>> with CL.DCQUORUM, that is, a majority of replicas in the same DC as
>>> the coordinator node for the current request.  DCQOURUM is not yet
>>> finished, though; currently it behaves the same as CL.ALL.
>>
>> Is it planned for any specific release?
>
> It's planned as soon as someone wants it badly enough to finish it. :)
>
>>> The short answer is, we maintained backwards compatibility for 0.4 ->
>>> 0.5 -> 0.6, but we are going to break things in 0.7 moving from String
>>> keys to byte[] and possibly other changes.
>>
>> hmmm... My assumption was that although keys are strings they are
>> still compared as bytes when using the OPP right? That would be the
>> difference between the OPP and the COPP, right? Just confirming
>> because otherwise creating composite keys with different data types
>> may prove problematic.
>
> Right.
>
> -Jonathan
>

Mime
View raw message