5 ms·

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

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?

iamaleksey 13y ago
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.
- jbellis 13y ago
  You're also giving up atomicity on writes when you actually do want to update multiple fields at once.
cbsmith 13y ago
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).
- iamaleksey 13y ago
  It's not how Riak does this, and it's not what's going on under the hood with Cassandra, either.
  - cbsmith 13y ago
    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.
    - iamaleksey 13y ago
      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.
      - cbsmith 13y ago
        > 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.
      - aphyr 13y ago
        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.
        iamaleksey 13y ago
        No batching here, just single-partition, two cell update. Atomic, but not isolated in the way you define isolation in your gist.
        cbsmith 13y ago
        Actually, even in Cassandra 1.2, batch operations were atomic unless otherwise specified.
        jeremiahjordan 13y ago
        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 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.

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?

iamaleksey 13y ago

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.

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

cbsmith 13y ago

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).

iamaleksey 13y ago
It's not how Riak does this, and it's not what's going on under the hood with Cassandra, either.
- cbsmith 13y ago
  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.
  - iamaleksey 13y ago
    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.
    - cbsmith 13y ago
      > 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.
    - aphyr 13y ago
      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.
      - iamaleksey 13y ago
        No batching here, just single-partition, two cell update. Atomic, but not isolated in the way you define isolation in your gist.
      - cbsmith 13y ago
        Actually, even in Cassandra 1.2, batch operations were atomic unless otherwise specified.
      - jeremiahjordan 13y ago
        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 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.