On Sat, Jul 21, 2012 at 12:04 AM, Kirk True 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
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
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
Freel
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 up
Cassandra doesn't do reads before writes. It just places the updates in
memtables. In effect updates are the same as inserts.Batches certainly help
with network latency, and some minor amount of code repetitiion on the server
side. - Original Message -From: "Leonid Ilyevsky"
>;lilyev.
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 p
