Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Riak/C* noob here. Couldn't I just store data as column cells in Riak?

    bucket: 'users'
    'jbellis/email', 'jbellis@example.com'
    'jbellis/phone', '555-5555'
What would I lose by doing this?


Performance, mostly. To read both the email and the phone you'll have to make two requests (or a single multiget). The keys have a good chance of belonging to different replicas, too, and even if they don't, you are still going to have 2x disk reads.


You're also giving up atomicity on writes when you actually do want to update multiple fields at once.


I believe that is precisely what Riak does in the "Riak now does this" link provided, and that's effectively what is going on under the hood with Cassandra. This means more overhead per column and the loss of the ability to just encode the data fields in an application native serialization structure.

In effect, you throw out a lot of the less talked about advantages of NoSQL and end up with something more like traditional SQL databases (not necessarily a bad thing, just different).


It's not how Riak does this, and it's not what's going on under the hood with Cassandra, either.


Riak has something pretty close to this, and if your table in cassandra looked like:

create bucket.users ( id uuid, username text, email text, phone text, primary key (uuid, username) );

That would be exactly how the data was encoded.


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" : "jbellis@example.com" and "jbellis:phone" : "555-5555". You don't want to do that in either Riak or Cassandra.


> 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" : "jbellis@example.com" 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.


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.


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.


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


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


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


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




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: