Remove call vs. delete mutation

[Josep Blanquer <bl...@rightscale.com>]

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.

Re: Remove call vs. delete mutation

[Josep Blanquer <bl...@rightscale.com>]

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 <aa...@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.
>
>

Re: Remove call vs. delete mutation

[aaron morton <aa...@thelastpickle.com>]

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.