N H
N H

Reputation: 1

Can consecutive updates to different fields on a row in Cassandra lead to inconsistency?

Assuming you have a table with a field (column) that serves as the primary (partition) key (let say its name is "id") and the rest of the fields columns are "regular" (no clustering) - lets call them "field1", "field2", field3", "field4", etc. The logic that currently exists in the system might generate 2 separate update commands to the same row. For example:

UPDATE table SET field1='value1' WHERE id='key';
UPDATE table SET field2='value2' WHERE id='key';

These commands run one after the other in quorum.

Seldom, when you retrieve the row (quorum read) from the DB, its as if one of the updates did not happen. Is it possible that the inconsistency is because of this write pattern and can be circumvented by making one update call like this:

UPDATE table SET field1='value1',field2='value2' WHERE id='key';

This is happening on Cassandra 2.1.17

Upvotes: 0

Views: 79

Answers (2)

Gunwant
Gunwant

Reputation: 979

What I would have done,is change the table definition

        CREATE TABLE TABLE_NAME(
      id text,
      field text,
      value text
    PRIMARY KEY( id , field )

This way you don't have to worry about updates to fields for a particular key.

Your queries would be ,

        INSERT INTO TABLE_NAME (id , field , value  ) VALUES ('key','fieldname1', 'value1' );
    INSERT INTO TABLE_NAME (id , field , value  ) VALUES ('key','fieldname2', 'value2' );

The drawback of design is, if you have too many data for 'key',it would created wide row.

For select queries -

SELECT * from TABLE_NAME where id ='key';

On client side, build your object.

Upvotes: 0

Marko Švaljek
Marko Švaljek

Reputation: 2101

Yes this is totally possible.

If you need to preserve the orders when making the two statements you can to 2 things:

  1. add using timestamp to your queries and set it explicitly on client code - this will prevent the inconsistencies
  2. use batch

Upvotes: 0

Related Questions