Saturday, October 31, 2009

NoSQL East 2009 Redux

This content has moved permanently to:
https://blog.jonm.dev/posts/nosql-east-2009-redux/

10 comments:

Dinh said...

I believe that Redis should belong to "key-value stores" category

Tim Anglade said...

More info on tin: slides and soon, code. Cheers ;)

Ismael Juma said...

"Major advantages over Voldemort in my mind are: ability to add/subtract nodes from running clusters, tunable (per-bucket, per-request!) quorum parameters (N,R,W), plus support for pluggable consistent hashing modules, partition distribution modules, and conflict resolution modules."

I think this is a bit misleading. Voldemort has a pluggable RoutingStrategy that decides what nodes should receive a given request. The default is ConsistentRoutingStrategy.

Also, it has a pluggable InconsistencyResolver interface and the default is a chained resolver with TimeBasedInconsistencyResolver over a VectorClockInconsistencyResolver.

Regarding quorum parameters, it's true that Voldemort only allows you to set it per store. I also find that a bit limiting and filed an issue a while ago about allowing it per request (the issue was for gets, but maybe it should be allowed for everything). Internally, it's quite easy to allow for this, most of the work is purely mechanical.

Best,
Ismael

AnĂ­bal Rojas said...

I agree with pcdinh that Redis should be included in the key-value category. It is blazing fast and the configurable async persistence mechanism is very flexyble.

Different from Memcached it provides Lists, Sets, and many atomic commands like INCrease. You can model real problems with this structures.

Also in the Data Structures side a Sorted Set (ZSET) is under heavy development.

Master Slave replication is blazing fast, 10MM keys (237M dump file and 1.5GB of RAM) takes just 21 seconds in a EC2 instance.

(And yes I like it very much ;)

Anonymous said...

Jon - what was your impression of Citrusleaf ?

Sam Johnston said...

+1 for NOSQL...

Jon Moore said...

@Ismael: Thanks for the updates and corrections on Voldemort. I was probably a little too loose when writing that paragraph; that single sentence you quoted, in my mind, started off with things Voldemort didn't have and trailed over to things I knew Riak had that I was excited about.

It's good to hear Voldemort has support for the pluggable strategies, although I think in my mind not being able to add/subtract nodes on the fly from a cluster is the biggest omission from an operational point of view (at least for my use cases).

Jon Moore said...

@pcdinh, @anibal: I think I would put Redis in the key-value store category if it weren't explicitly for the asynchronous persistence. i.e. when I get a PUT come back with a successful response code, I want that to mean "it's been written to disk somewhere." There are, for sure, a lot of applications where "it'll be written to disk soon" is good enough, but it isn't for my use cases.

Also, it is expensive to scale for large datasets (disk is still much cheaper than memory).

Now, as I alluded to in the discussion of Redis, I'm open to the possibility that I need to rethink the need for to-disk persistence in a world of distributed, fault-tolerant architectures, but I'm not quite there yet (thus why I put Redis in the "not sure what to think about it yet" category).

Jon Moore said...

@Brian: Unfortunately, I didn't take in the Citrusleaf presentation due to a combination of "unconference" discussions going on and at-home work issues.

Ismael Juma said...

Hey Jon,

"It's good to hear Voldemort has support for the pluggable strategies, although I think in my mind not being able to add/subtract nodes on the fly from a cluster is the biggest omission from an operational point of view (at least for my use cases)."

Everyone seems to agree and that is Alex Feinberg's main priority as far as I understand. He recently joined LinkedIn and Voldemort is one of the main projects he will be working on.

Ismael