This content has moved permanently to:
https://blog.jonm.dev/posts/nosql-east-2009-redux/
Saturday, October 31, 2009
Subscribe to:
Post Comments (Atom)
skip to main |
skip to sidebar
The Art of Writing Software
All articles Copyright © 2007-2019 by Jon Moore. All rights reserved.
11 comments:
I believe that Redis should belong to "key-value stores" category
More info on tin: slides and soon, code. Cheers ;)
"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
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 ;)
Jon - what was your impression of Citrusleaf ?
+1 for NOSQL...
@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).
@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).
@Brian: Unfortunately, I didn't take in the Citrusleaf presentation due to a combination of "unconference" discussions going on and at-home work issues.
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
Appreciate you bloggingg this
Post a Comment