On Sat, Jul 21, 2012 at 12:04 AM, Kirk True <k...@mustardgrain.com> wrote: > I was aware of the read-then-write pattern for counters, but not secondary > indexes. I'll have to take a look into that.
Fyi, if you are interested by the subject, https://issues.apache.org/jira/browse/CASSANDRA-2897 is relevant. -- Sylvain > > 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. > > > >
