Anti-RDBMS: A list of distributed key-value stores | Hacker News Reader

Anti-RDBMS: A list of distributed key-value stores

metabrew.com

75 pointsropiku16 comments

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.

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.

Tokyocabinet and its ancillary bits are nice, but lets not pretend that master-master replication makes a database _distributed_. Once you can get that number of masters over three we can talk...

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.

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.

Check out Oracle Coherence.

RDBMS and Memchash work well together. Using the RDBMS as an index lets you keep the whole thing in RAM, and then store your data in Memchash. You can store a lot of useful information into 1kb or less records and then store 1+ million records per GB in RAM.

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.

You should go back to that article and make a note of every site that is mentioned by name in the article and the comments. You will find a certain correlation between the size of a datastore and their interest in pursuing something other than an RDBMS.

This is not a coincidence. Nor are these people who just don't know about the holy doctrines of RDBMS and blunder on in ignorance, either. These are people who have had to scale above RDBMS.

They know what they are doing, and why they are doing it.

Will you now? Databases of tens of terabytes are commonplace now in the relational world. Petabytes are the new frontier.

Now if you had said that there was a correlation between a particular data access pattern and the interest in a non-relational datastore you might be onto something, but size most definitly isn't it, and TPS isn't it either.

"Now if you had said that there was a correlation between a particular data access pattern and the interest in a non-relational datastore you might be onto something," - actually, that's what I was really getting at here with my comment that "They know what they are doing, and why they are doing it." These are not people who are puttering around with a few million rows and throwing up their hands in disgrace because they screwed up their keys. These are people who have tried everything to make RDBMS work, and RDBMS just couldn't do it. Repeatedly. (Seems like every major web site tells that story.)

RDBMS are awesome. They are not the absolute last word in data storage. (Heck, RDBMS as they stand today aren't even the last word in relational data storage.)

It's amazing how much time and money people will spend to avoid buying Oracle :-P

These are people who have had to scale above RDBMS.

We know the limits of MySQL and PostgreSQL, but do we know the limits of RDBMS? Consider the promise of H-Store.

What I care about are the limits of products which are ready for prime time, or that we can easily get to that point.

I haven't heard much about H-Store but it doesn't look like it's ready for production use.

It's pretty hard to get over reason #6.

Why? You only need to get into weird "sharding" schemes if you need to workaround sucky concurrent write performance of individual instances. You can do thousands of commits/sec on a single instance of a serious RDBMS on off-the-shelf kit.

Reply on news.ycombinator.com