Question about counters read before write behavior

Hi, We're trying to confirm on a counter write that the entire partition is read from disk vs. just the row and column of the partition to increment. We've trade the code to this line

Re: Any plans for read-before-write update operations in CQL3?

013, at 12:48 AM, Drew Kutcharian wrote: > >> Hi Guys, >> >> Are there any short/long term plans to support UPDATE operations that require read-before-write, such as increment on a numeric non-counter column? >> i.e. >> >> UPDATE CF SET NON_COUNTER_NUMERI

Re: Any plans for read-before-write update operations in CQL3?

Counters are currently read before write, some collection operations on List > are read before write. > > > On Wed, Apr 3, 2013 at 9:59 PM, aaron morton wrote: > I would guess not. > >> I know this goes against keeping updates idempotent, > There are also issues with

Re: Any plans for read-before-write update operations in CQL3?

Counters are currently read before write, some collection operations on List are read before write. On Wed, Apr 3, 2013 at 9:59 PM, aaron morton wrote: > I would guess not. > > I know this goes against keeping updates idempotent, > > There are also issues with consistency. i

Re: Any plans for read-before-write update operations in CQL3?

rton http://www.thelastpickle.com On 4/04/2013, at 12:48 AM, Drew Kutcharian wrote: > Hi Guys, > > Are there any short/long term plans to support UPDATE operations that require > read-before-write, such as increment on a numeric non-counter column? > i.e. > > UPDATE CF

Any plans for read-before-write update operations in CQL3?

Hi Guys, Are there any short/long term plans to support UPDATE operations that require read-before-write, such as increment on a numeric non-counter column? i.e. UPDATE CF SET NON_COUNTER_NUMERIC_COLUMN = NON_COUNTER_NUMERIC_COLUMN + 1; UPDATE CF SET STRING_COLUMN = STRING_COLUMN + "po

Re: Read before Write

If you are reading and making decisions about what to write just remember there are no transactions. You are essentially running at a Read Uncommitted level of transaction isolation, with regard of batch mutations (a mutation for a single row is atomic). If you can it may be less headache to wr

Re: Read before Write

t;>> >>> I have: >>> >>> day of year (row key) -> SomeId (column key) -> byte[0] >>> >>> I need to make sure that I write SomeId, but in around 80% of the cases >>> it will be already present (so I would essentially replace it with

Re: Read before Write

I haven't benchmarked so it's purely theoretical. If there's no caching then I'm pretty sure just writing would yield better performance. If you do cache rows/keys it really depends on your hit ratio. Naturally if you have a small data set and high cache ratio and use row caching I'm pretty sure it

Re: Read before Write

I think Just writing all the time is much better, as most of replacements will be done in memtable. also you should set a large memtable size, in compared with the average row size. 2010/8/27 Daniel Doubleday > Hi people > > I was wondering if anyone already benchmarked such a situation: > > I

Read before Write

Hi people I was wondering if anyone already benchmarked such a situation: I have: day of year (row key) -> SomeId (column key) -> byte[0] I need to make sure that I write SomeId, but in around 80% of the cases it will be already present (so I would essentially replace it with itself). RF will