cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kirk True <k...@mustardgrain.com>
Subject Re: Batch update efficiency with composite key
Date Fri, 20 Jul 2012 22:04:48 GMT
I was aware of the read-then-write pattern for counters, but not 
secondary indexes. I'll have to take a look into that.

Thanks.

On 07/20/2012 02:32 AM, aaron morton wrote:
> I'm assuming the logical row is in a CQL 3 CF  with composite 
> PRIMARYKEY http://www.datastax.com/dev/blog/whats-new-in-cql-3-0
>
> It will still be a no look write. The exception being secondary 
> indexes and counters which include reads in the write path.
>
> Cheers
>
> -----------------
> Aaron Morton
> Freelance Developer
> @aaronmorton
> http://www.thelastpickle.com
>
> On 20/07/2012, at 10:26 AM, Kirk True wrote:
>
>> In Cassandra you don't read-then-write updates, you just write the 
>> updates.
>>
>> Sorry for being dense, but can you clarify a logical vs. physical row?
>>
>> Batching is useful for reducing round trips to the server.
>>
>> On 07/18/2012 06:18 AM, Leonid Ilyevsky wrote:
>>>
>>> I have a question about efficiency of updates to a CF with composite 
>>> key.
>>>
>>> Let say I have 100 of logical rows to update, and they all belong to 
>>> the same physical wide row. In my naïve understanding (correct me if 
>>> I am wrong), in order to update a logical row, Cassandra has to 
>>> retrieve the whole physical row, add columns to it, and put it back. 
>>> So I put all my 100 updates in a batch and send it over. Would 
>>> Cassandra be smart enough to recognize that they all belong to one 
>>> physical row, retrieve it once, do all the updates and put it back 
>>> once? Is my batch thing even relevant in this case? What happens if 
>>> I just send updates one by one?
>>>
>>> I want to understand why I should use batches. I don’t really care 
>>> about one timestamp for all records, I only care about efficiency. 
>>> So I thought, I want to at least save on the number of remote calls, 
>>> but I also wonder what happens on Cassandra side.
>>>
>>>
>>> ------------------------------------------------------------------------
>>> This email, along with any attachments, is confidential and may be 
>>> legally privileged or otherwise protected from disclosure. Any 
>>> unauthorized dissemination, copying or use of the contents of this 
>>> email is strictly prohibited and may be in violation of law. If you 
>>> are not the intended recipient, any disclosure, copying, forwarding 
>>> or distribution of this email is strictly prohibited and this email 
>>> and any attachments should be deleted immediately. This email and 
>>> any attachments do not constitute an offer to sell or a solicitation 
>>> of an offer to purchase any interest in any investment vehicle 
>>> sponsored by Moon Capital Management LP (“Moon Capital”). Moon 
>>> Capital does not provide legal, accounting or tax advice. Any 
>>> statement regarding legal, accounting or tax matters was not 
>>> intended or written to be relied upon by any person as advice. Moon 
>>> Capital does not waive confidentiality or privilege as a result of 
>>> this email.
>>
>


Mime
View raw message