You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Drew Kutcharian <dr...@venarc.com> on 2013/04/03 21:18:13 UTC
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 + "postfix";
etc.
I know this goes against keeping updates idempotent, but there are times you need to do these kinds of operations. We currently do things like this in client code, but it would be great to be able to this on the server side to minimize the chance of race conditions.
-- Drew
Re: Any plans for read-before-write update operations in CQL3?
Posted by Drew Kutcharian <dr...@venarc.com>.
I guess it'd be safe to say that the read consistency could be the same as the consistency of the update. But regardless, that would be a lot better than reading a value, modifying it at the client side and then writing it back.
On Apr 3, 2013, at 7:12 PM, Edward Capriolo <ed...@gmail.com> wrote:
> 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 <aa...@thelastpickle.com> wrote:
> I would guess not.
>
>> I know this goes against keeping updates idempotent,
> There are also issues with consistency. i.e. is the read local or does it happen at the CL level ?
> And it makes things go slower.
>
>> We currently do things like this in client code, but it would be great to be able to this on the server side to minimize the chance of race conditions.
> Sometimes you can write the plus one into a new column and then apply the changes in the reading client thread.
>
> Cheers
>
> -----------------
> Aaron Morton
> Freelance Cassandra Consultant
> New Zealand
>
> @aaronmorton
> http://www.thelastpickle.com
>
> On 4/04/2013, at 12:48 AM, Drew Kutcharian <dr...@venarc.com> 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_NUMERIC_COLUMN = NON_COUNTER_NUMERIC_COLUMN + 1;
>>
>> UPDATE CF SET STRING_COLUMN = STRING_COLUMN + "postfix";
>>
>> etc.
>>
>> I know this goes against keeping updates idempotent, but there are times you need to do these kinds of operations. We currently do things like this in client code, but it would be great to be able to this on the server side to minimize the chance of race conditions.
>>
>> -- Drew
>
>
Re: Any plans for read-before-write update operations in CQL3?
Posted by Edward Capriolo <ed...@gmail.com>.
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 <aa...@thelastpickle.com>wrote:
> I would guess not.
>
> I know this goes against keeping updates idempotent,
>
> There are also issues with consistency. i.e. is the read local or does it
> happen at the CL level ?
> And it makes things go slower.
>
> We currently do things like this in client code, but it would be great to
> be able to this on the server side to minimize the chance of race
> conditions.
>
> Sometimes you can write the plus one into a new column and then apply the
> changes in the reading client thread.
>
> Cheers
>
> -----------------
> Aaron Morton
> Freelance Cassandra Consultant
> New Zealand
>
> @aaronmorton
> http://www.thelastpickle.com
>
> On 4/04/2013, at 12:48 AM, Drew Kutcharian <dr...@venarc.com> 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_NUMERIC_COLUMN = NON_COUNTER_NUMERIC_COLUMN + 1;
>
> UPDATE CF SET STRING_COLUMN = STRING_COLUMN + "postfix";
>
> etc.
>
> I know this goes against keeping updates idempotent, but there are times
> you need to do these kinds of operations. We currently do things like this
> in client code, but it would be great to be able to this on the server side
> to minimize the chance of race conditions.
>
> -- Drew
>
>
>
Re: Any plans for read-before-write update operations in CQL3?
Posted by Vitalii Tymchyshyn <ti...@gmail.com>.
Well, a schema've just came to my mind, that looks interesting, so I want
to share:
1) Actions are introduced. Each action receives unique I'd at coordinator
node. Client can ask for a block of ids beforehand, to make actions
idempotent.
2) Actions are applied to given row+column value. It's possible that
special column family type should be created that support actions.
3) Actions are stored for grace period to ensure repair will be working
well.
4) Along with all the actions for grace period, old value, current value
and old value hash is stored.
5) Old value is the value without currently stored actions, current value
has all currently stored actions applied
6) Old value hash has number of actions applied, time of last action
applied and hash of all the applied actions ids (only actions applied to
old value of course).
7) Current value is updated on read. So there can be actions that are not
applied yet. So on read, if there are unapplied actions, they are applied
and information about current value/applied actions is updated.
8) Actions can rely on order or not rely on order. If actions rely on order
and during update it is needed to apply out of order action, value is
recalculated, starting from old value.
9) During repair, highest (based on number of actions applied, then lowest
by time) old value is selected. Then all actions older or of the same time
of old value are dropped as already applied. Newer are merged into union
set.
10) During compaction, old value is moved to the now-grace period time.
The schema looks solid. Minus is that all the values for grace period must
be stored. May be it should be combined with some auto confirmation
mechanism when coordinator, after receiving acks for all the writes does
the second round notifying that action is fully written. This should work
for hinted handoff too. Than, old value can be propagated to the last acked
action.
4 квіт. 2013 04:59, "aaron morton" <aa...@thelastpickle.com> напис.
>
> I would guess not.
>
>> I know this goes against keeping updates idempotent,
>
> There are also issues with consistency. i.e. is the read local or does it
happen at the CL level ?
> And it makes things go slower.
>
>> We currently do things like this in client code, but it would be great
to be able to this on the server side to minimize the chance of race
conditions.
>
> Sometimes you can write the plus one into a new column and then apply the
changes in the reading client thread.
>
> Cheers
>
> -----------------
> Aaron Morton
> Freelance Cassandra Consultant
> New Zealand
>
> @aaronmorton
> http://www.thelastpickle.com
>
> On 4/04/2013, at 12:48 AM, Drew Kutcharian <dr...@venarc.com> 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_NUMERIC_COLUMN = NON_COUNTER_NUMERIC_COLUMN +
1;
>>
>> UPDATE CF SET STRING_COLUMN = STRING_COLUMN + "postfix";
>>
>> etc.
>>
>> I know this goes against keeping updates idempotent, but there are times
you need to do these kinds of operations. We currently do things like this
in client code, but it would be great to be able to this on the server side
to minimize the chance of race conditions.
>>
>> -- Drew
>
>
Re: Any plans for read-before-write update operations in CQL3?
Posted by aaron morton <aa...@thelastpickle.com>.
I would guess not.
> I know this goes against keeping updates idempotent,
There are also issues with consistency. i.e. is the read local or does it happen at the CL level ?
And it makes things go slower.
> We currently do things like this in client code, but it would be great to be able to this on the server side to minimize the chance of race conditions.
Sometimes you can write the plus one into a new column and then apply the changes in the reading client thread.
Cheers
-----------------
Aaron Morton
Freelance Cassandra Consultant
New Zealand
@aaronmorton
http://www.thelastpickle.com
On 4/04/2013, at 12:48 AM, Drew Kutcharian <dr...@venarc.com> 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_NUMERIC_COLUMN = NON_COUNTER_NUMERIC_COLUMN + 1;
>
> UPDATE CF SET STRING_COLUMN = STRING_COLUMN + "postfix";
>
> etc.
>
> I know this goes against keeping updates idempotent, but there are times you need to do these kinds of operations. We currently do things like this in client code, but it would be great to be able to this on the server side to minimize the chance of race conditions.
>
> -- Drew