incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josep Blanquer <blanq...@rightscale.com>
Subject Re: Remove call vs. delete mutation
Date Wed, 13 Apr 2011 00:19:15 GMT
Is there anybody else that might see a problem with just using delete
mutations instead of remove calls?

I'm thinking about changing a Cassandra client to always use delete
mutations when removing objects, that way the "delete/remove" call
interface can be kept the same:
1- the "delete/remove" client call would always support all features:
single-key/column, multi-column and slice range deletes.
2- it could be used in the same way regardless of embedding the calls
into batch mutations or removing a single column/key

 I'd like to hear some more thoughts about this change not causing the
Cassandra server to take a much higher CPU toll just because decoding
mutations is much less optimized than straight removes or something
like that...(I don't think so but...). In other words, if I do 1000
inserts or 1000 single-delete mutations, would the Cassandra server
see much of a difference?

 Cheers,

Josep M.

On Mon, Apr 11, 2011 at 3:49 PM, aaron morton <aaron@thelastpickle.com> wrote:
> AFAIK both follow the same path internally.
>
> Aaron
>
> On 12 Apr 2011, at 06:47, Josep Blanquer wrote:
>
>> All,
>>
>> From a thrift client perspective using Cassandra, there are currently
>> 2 options for deleting keys/columns/subcolumns:
>>
>> 1- One can use the "remove" call: which only takes a column path so
>> you can only delete 'one thing' at a time (an entire key, an entire
>> supercolumn, a column or a subcolumn)
>> 2- A delete mutation: which is more flexible as it allows to delete a
>> list of columns an even a slice range of them within a single call.
>>
>> The question I have is: is there a noticeable difference in
>> performance between issuing a remove call, or a mutation with a single
>> delete? In other words, why would I use the remove call if it's much
>> less flexible than the mutation?
>>
>> ...or another way to put it: is the remove call just there for
>> backwards compatibility and will be superseded by the delete mutations
>> in the future?
>>
>> Cheers,
>>
>> Josep M.
>
>

Mime
View raw message