

 Anti-RDBMS: A list of distributed key-value stores - ropiku
http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores/

======
amix
The author praises Scalaris - it promises a lot of things, unfortunately its
performance sucks based on my own benchmarks (that isn't published anywhere,
but you could try to do 100.000 sets and compare it vs. CouchDB or that like).

One of the most impressive k-v databases I have read about and used is Tokyo
Tyrant ( <http://tokyocabinet.sourceforge.net/tyrantdoc/> ). It's coded in C,
has been in development for about 2 years and is used in production on
Plurk.com and mixi.jp. It also offers master-master replication.

~~~
richcollins
We use TC for our site. The C server is a thin wrapper over it and does 8000
write requests per second on my 1st generation MacBook with the benchmarker
running on it as well.

The client is written entirely in javascript and does the expensive operations
like joins.

Were hoping we will be able to run the site off of one server forever. People
complain that "developer cycles are expensive" but so is purchasing and
managing a bunch of servers.

------
CalmQuiet
It all sounds rather not-ready for prime-time. Might it not be better use of
time to _get-over_ those six "reasons". They're hardly insurmountable. Not
likely to drag me away from generalized RDBMS solutions that can work with
either MySQL or PostgreSQL.

~~~
mdasen
It's not that they aren't ready for prime-time necessarily. Technologies like
memcached are great compliments to any RDBMS-backed website. For a little
theory: an RDBMS will store data and allow you to query it. So, when you say,
get me article #15, it scans through its index in approx. log(n) time and
finds the row you're looking for, fetches the row and gives it back to you.
Memcached, on the other hand, will do hash(#15), grab that row. That's all
done in O(1) time and so it's a lot more scalable. However, with an RDBMS you
can say something like, "get me the articles written in the past month" and
you can't do that with memcached. Memcached allows key lookups only.

A lot of it is a tradeoff between scalability and convenience and using the
right tool for the job.

~~~
neilc
O(log n) tree search vs. O(1) hash lookup is _not_ the reason for any
scalability differences that might exist between RDBMS and key-value stores.
RDBMSs with hash indexes are commonplace, and allow O(1) lookups and a b+-tree
lookup over a few million rows only does a few I/Os (the fanout in a typical
disk-based tree index is on the order of 100, and the nodes in the first level
or two of the tree are likely to be cached). Any differences in _scalability_
has more to do with architectural differences (easier to do horizontal
partitioning with key-value stores, no need/expectation of ACID transactions,
no need to parse + optimize queries at runtime, no need for a complex query
executor, etc.)

But I agree that a SQL RDBMS allows much more flexible ad-hoc queries than a
key-value store does.

