iamaleksey

Joined 18 years ago

Karma

184

Submissions

Member since

Jan 31

gmail://aleksey.yeschenko

http://www.hackernewsers.com/users/iamaleksey.html

View on Hacker News

Recent submissions

Comment · 9 years ago

Except they are. Catalogued as δ-CRDT, under Lexicographic Counter in https://arxiv.org/pdf/1603.01529.pdf

edit: Although to be fair that blog post is ancient and covers Cassandra 2.0, now no longer supported. Counters were rewritten in Cassandra 2.1.

Comment · 12 years ago

CQL is compatible with Thrift-created column families (the inverse is not true, though). Just do a DESCRIBE SCHEMA from cqlsh and see how CQL interprets a particular Thrift-created column family, then use regular INSERTs.

Comment · 12 years ago

This is not true. See this for example: http://www.datastax.com/dev/blog/thrift-to-cql3

You can do CREATE TABLE schemaless (id blob, name blob, value blob, PRIMARY KEY (id, name)) WITH COMPACT STORAGE; and have a 'schemaless' table, essenitally, just as with Thrift.

This is not a workaround either - this is first-class supported, just as you can read/write from/to 'schemaless' thrift columnfamilies using CQL.

Comment · 12 years ago

> Cassandra is really awesome at writes but reads are really expensive

This is getting old, and is just plain untrue. Reads are more expensive than the extremely cheap writes, but they really aren't expensive.

> Atomicity at the row level only

Partition level, really, in modern terminology (apologies if that's what you meant).

Comment · 13 years ago

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

Comment · 13 years 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" : "[email protected]" and "jbellis:phone" : "555-5555". You don't want to do that in either Riak or Cassandra.

Comment · 13 years ago

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

Comment · 13 years ago

In case you are talking about Cassandra collections (maps and sets), and not abstract maps/sets, then you are wrong. Only CQL3 Lists work like that - there are no UUIDs anywhere in CQL3 maps/sets implementations.

Comment · 13 years 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.