[iamaleksey]

The difference is that all the cells with the same `id` would belong to the same partition and stored together, so you'd be able to write them atomically and read them together cheaply in a single operation.

What marshray suggested would look like this:

create table bucket.users (name text, field text, value text, primary key ((name, field))); - with a composite partition key. Then you'd have two separate single-cell partitions "jbellis:email" : "[e-mail]" and "jbellis:phone" : "555-5555". You don't want to do that in either Riak or Cassandra.

[cbsmith]

> What marshray suggested would look like this: create table bucket.users (name text, field text, value text, primary key ((name, field))); - with a composite partition key. Then you'd have two separate single-cell partitions "jbellis:email" : "[e-mail]" and "jbellis:phone" : "555-5555". You don't want to do that in either Riak or Cassandra.

Ah I see what you mean. I thought the intent was to group by some unique ID for the user.

[aphyr]

you'd be able to write them atomically

To clarify, this is only the case if you use Cassandra 2.0 transactions; normal batched writes are not atomic in the sense you're probably thinking.

[jeremiahjordan]

They are atomic, they are not isolated. Those are two different properties. The "A" vs the "I" in ACID. http://en.wikipedia.org/wiki/ACID

Edit: Actually, they are isolated in the sense of ACID, doesn't matter what order you do to operations, the answer will be the same. But not isolated the way you want isolated described.

[cbsmith]

The scenario that he's found is when the two timestamps are actually identical. In that scenario, Cassandra cannot maintain its atomicity guarantee.

[aphyr]

No, they are not isolated in the sense of ACID. This behavior violates P0.

[iamaleksey]

No batching here, just single-partition, two cell update. Atomic, but not isolated in the way you define isolation in your gist.

[cbsmith]

Actually, even in Cassandra 1.2, batch operations were atomic unless otherwise specified.