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