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

[RJ]

Written on 01/19/2009 19:38:43

URL: http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores

[RJ]

Comment written by Henrik Ingo on 05/18/2009 06:26:19

* ... so I forgot performance: I routinely get 10-30+k writes per second on modern HW with only 2 nodes, with a larger cluster we have production systems with 100k+ per second.

* Yes, it scales linearly unlike some stuff you tried.

The only caveat: Network latency affects performance a lot (due to ACID commit to 2 nodes). So would be interesting to see how this works on EC2.

[RJ]

Comment written by Cameron Purdy on 05/18/2009 22:44:00

It's not free, but I'd be curious how you find Oracle (previously Tangosol) Coherence to stack up ..

Peace,

Cameron.

[RJ]

Comment written by Diesel mcfadden on 05/20/2009 04:54:28

Have you revisited this issue in the last 5 months?
What did you end up choosing/doing?

[RJ]

Comment written by Diesel mcfadden on 05/20/2009 04:54:52

Have you revisited this issue in the last 5 months?

[RJ]

Comment written by Diesel mcfadden on 05/20/2009 04:55:09

or what did you end up with?

[RJ]

Comment written by Виктор Евсеев on 05/20/2009 07:41:23

Люди в таких вот случаях говорят - Белую ворону и свои заклюют. ;)

[RJ]

Comment written by Przemek on 05/24/2009 18:56:54

I'd like to add my project - SubRecord to the list which is however not stable nor finished yet (alpha), but a lot of thing have been already done. This is a Java project, to some extent similar to Voldemort, but still very different in a few aspects what makes it kind of unique. Check it out and if you are looking for a project to contribute in - please let me know.

[RJ]

Comment written by RJ on 05/25/2009 20:54:50

We haven't settled on anything yet, and since posting this there has been an explosion of new projects. Tokyo Cabinet keeps coming up, sorry I missed that the first time around. There are many, many more.

I'm going to be in San Francisco in June for "nosql" meetup, which is all about distributed kv stores: http://nosql.eventbrite.com/

This should help us narrow our options! Ping me on twitter if you will be there and want to meet up.

[RJ]

Comment written by Степан on 05/26/2009 09:23:23

Действительно интересно написанно, я наверное бы так не смог.

[RJ]

Comment written by Олег on 05/28/2009 21:04:08

Разное

[RJ]

Comment written by Петр Сычев on 05/31/2009 11:44:23

Хотя еще полностью непонятно, что там такое происходит, но на 100% могу сказать, что это не в лучшую сторону!

[RJ]

Comment written by Андрей on 06/27/2009 03:03:27

Видел что-то наподобие в англоязычном инете, в Русскоязычном интернете про такие вещи как-то не особо часто посты увидишь.

[RJ]

Comment written by Brainiac 5 on 07/06/2009 03:06:21

The guys from Scalaris explain in their FAQ why persistence to disk makes little sense for Scalaris consistency strategy, crash-stop, and will not be implemented, as it would *reduce* robustness.

"If a single failed node does crash and recover, which is not foreseen in the crash-stop model, but might happen if we have local persistent storage, we have three choices:

1. drop the persistent storage and start as new node (crash-stop model)
2. get some inconsistencies as another node already took over. For a short timeframe there might be more replicas in the system than allowed, which destroys the proper functioning of our majority based algorithms.
3. friendly join the system and update the stored peristent state with the current state in the system (one way to implement that would be (1)).

So, persistent storage does not help in improving the availability or robustness of the system.
...
Persistency as in traditional replicated databases is not intended by our system model and thereby not possible. The best alternative would be periodic snapshots, that can be done also without interrupting the service."

http://code.google.com/p/sc...

[RJ]

Comment written by kevin glenny on 07/21/2009 12:41:55

Great insight into technologies that are new to me.

Working with customers who have existing database scalability and performance problems. I am interested to hear about any case studies where an existing RDBMS was replaced with a data store?

It seems to me that data stores provide excellent scalability and performance, but only in the context of applications written from scratch due to the tight coupling of the data and application layers. For now, I cannot see their ready acceptance to solve companies existing RDBMS's problems as I point out here:
http://bigdatamatters.com/b...

[RJ]

Comment written by Marton Trencseni on 07/24/2009 11:41:00

Just out: Keyspace, a consistently replicated, fault-tolerant key-value store.

http://scalien.com/keyspace

[RJ]

Comment written by Валерий on 07/25/2009 11:13:39

Люди в таких случаях говорят - Без косы сена не накосишь. ;)

[RJ]

Comment written by banq on 11/12/2009 07:43:43

are you looking for low latency, replicated key-value? no exist!
CAP Theorem :
Consistency == low latency
Partition tolerance == replicated
key-value is high Availability.

so you break CAP Theorem !

[RJ]

Comment written by Pratik on 12/20/2009 17:56:26

Great resource.

Cassandra is on apache incubator now. The page :
http://incubator.apache.org... has good documentation and the IRC channel(#cassandra on freenode) has good population.

An update to the article would help a lot.

[RJ]

Comment written by RJ on 12/20/2009 19:04:27

I've added a note to the top of the article to draw attention to the fact that *lots* has changed since I wrote this. I won't be updating the article tho.

[RJ]

Comment written by Alex on 12/25/2009 10:15:45

I gather that people here mostly compare the key-value store system to a relational database. And indeed some KV stores resemble RDBMS - indexing, processing on data... But generally key-value stores have much more common with file systems. If you do a complexity list than RDBMS would be sitting at the top (semi-structured namespace, complex queries, procedures, ACID), file systems would occupy the second place (hierarchical namespace, rather simple metadata, POSIX) and then there are key-value stores (flat namespace, no other metadata, no security...). The simplicity is advantage here as the speed and scalability comes with it. Anyway, project FAWN has interesting (experimental) key-value store - http://www.cs.cmu.edu/~fawn...

[RJ]

Comment written by Alex on 12/25/2009 10:55:02

Oh, and another KV store that does not seem to be mentioned here is Riak - http://riak.basho.com/arch.... Pretty similar to Dynamo (consistent hashing, vector clocks, merkle tree).

[RJ]

Comment written by Mo on 01/06/2010 00:27:55

great resource!

Most of the resources I have found, lightly touch on BI aspects - i.e. doc based stores (like Mongodb etc.) are not best suited for BI especially adhoc reporting.

We are considering moving part of oracle data to mongodb. I am wondering how to best address the BI needs for our end users? Do we setup an ETL to create a relational datawarehouse that can use traditional BI tools like business objects/cognos etc.?

If we use our developers to create adhoc reports on docbase datastore then the cost adds up.

Any other approach?

Since BI (Adhoc reporting, dashboarding, olap etc.) is an important byproduct of the database, I wonder how do these docbased data store handle it?

[RJ]

Comment written by Manu Subramanian on 02/02/2010 04:12:03

Could you please recompile this post with the new data, adding those that were not in the list.

Thanks in advance

[RJ]

Comment written by Remon Oldenbeuving on 04/06/2010 14:28:30

Maybe it's a good idea to rebuild this blogpost? Many things have happend since the post. And I was wondering what would be a good reason not to use Cassandra, since the reason you give won't apply anymore?

[RJ]

Comment written by Scott Jones on 04/08/2010 15:57:52

Has anybody bothered to look at the commercial solutions that have been running very large, scalable systems for decades?
People should look at InterSystem's Caché and Ensemble products...
Use it as a key/value store, as an object database, as a relational database, or even a Pick style multivalue database...
NoSQL is not a very good name for such a database... it is marketed as a "post-relational" database...

[RJ]

Comment written by rob on 05/19/2010 22:57:46

Has anyone looked at clustrix' claims ... 'best of both worlds' ... scalable SQL database and key value store ... just curious

[RJ]

Comment written by Albert on 10/19/2010 13:09:16

I commented this post 1 year ago when I was looking for a solution. I just wanted to say that my final choice was Redis, and I've been using it in a couple of sites as the only storage (and caching) system.

It works like a charm and is fast as hell and although it sounds subjective it is also confirmed in the numbers.

[RJ]

Comment written by Дежурный on 10/26/2010 01:34:25

MySQL can be used as NoSQL storage:
http://yoshinorimatsunobu.b...

You should consider adding it to the comparison.

[RJ]

Comment written by Perry Krug on 11/01/2010 17:31:51

Just stumbled across this article, great writeup and comparison. The enormous amount of comments clearly show how worthwhile this was.

I'd like to throw a new project into the mix: Membase. It is an open-source project created by the makers of Memcached and provides a slew of features above and beyond Memcached while remaining completely compatible with the protocol.

-Perry

[RJ]

Comment written by дешевые диваны, самые дешевые on 11/18/2010 11:52:05

Мебельная фабрика- эконом класс диваны дешево

[RJ]

Comment written by Martin Schneider on 02/16/2011 23:46:41

I know this is old - but should be updated for Riak/Basho!

[RJ]

Comment written by deadbeat millionaire bonus on 03/09/2011 16:33:40

Awesome post man,

I haven't tried thrudb yet but I cant wait!

[RJ]

Comment written by Waqar Ahmad Khan on 04/08/2011 09:08:59

Nice post.Thanks for sharing useful information.Please keep sharing like this kind of information with us.
mlm lead system pro

[RJ]

Comment written by NABH on 05/28/2011 09:46:03

I really appreciate your post and you explain each and every point very well.Thanks for sharing this information.And I’ll love to read your next post too.
Regards:
NABH

[RJ]

Comment written by Waqar Ahmad Khan on 05/30/2011 09:19:30

Nice article .I really appreciate your work.Thanks for the nice breakdown of services.Keep it up.
Mike Dillard

[RJ]

Comment written by Tomaz Bracic on 07/12/2011 05:54:00

What about MongoDB?

[RJ]

Comment written by Aashay Desai on 08/01/2011 21:27:47

+1 to Membase.  The way they handle horizontal scaling is worth looking into, and may suit your needs quite well

[RJ]

Comment written by henter on 09/08/2011 06:54:40

HOHO~

[RJ]

Comment written by Justin on 11/08/2011 19:29:08

I know this article is old and I read the comments and updates at the top, but it's the first results in Google.

I've been doing research trying to find a good .NET or Windows based DISTRIBUTED Key\Value store.  I ran across Microsoft's AppFabric, which sells itself as caching, not necessarily a key\value store.

Anyway, it'd be nice if you updated this list with a few windows stack options.  I also ran across RaptorDB which looks interesting, but I don't think it scales.

Justin

http://www.SEOArbiter.com

[RJ]

Comment written by Seref Arikan on 12/23/2011 18:55:50

This post and following comments has helped me more than hours of reading! Thanks to everyone who has commented.
I have been looking for a flexible solution to build a custom persistence and computation layer. Basically, I wanted to build on top of a key/value store, but ACID and transactions would be required also.
Among the solutions given here, Scalaris may be one of the most interesting ones, but its lack of persistence would be a problem for my use case.
Seeing that it has not been mentioned before, I'd like to add Infinispan ( http://www.jboss.org/infini... ) to the list. It appears to be very similar to Scalaris in terms of its goals, but its features are probably more advanced. I have not found a comparison of the two yet, but based on some very superficial reading, Infinispan appears to support two key things: a joined heap, and disk persistence with some nice options.

Thanks again for the great blog post, and insightful comments.

[RJ]

Comment written by andres_socha on 01/03/2012 19:08:24

great job and thank you very much for all this information the table help me more easily understand the protocols clients .. Best wishes .... 

Trabajos
en Casahttp://trabajox5.com/

[RJ]

Comment written by escorte on 03/20/2012 16:23:43

It s rare for me to find something on the web that s as entertaining and intriguing as what you ve got here. Your page is lovely, your graphics are great, and what s more, you use source that are relevant to what you are talking about. You are certainly one in a million, well done!

[RJ]

Comment written by Bsm on 06/28/2012 18:37:32

Just looking at the list of reasons in the context of NuoDB (disclosure I represent NuoDB).1. You're suffering from Cloud-computing Mania - 
 Check.  Dynamic/elastic scale-out/scale-in on commodity servers, on-premise, public cloud or hybrid.

2.  You need an excuse to 'get your Erlang on'
Umm.  You'll have to explain what makes Erland unable to interface with full featured databases :-)

3.  You heard CouchDB was cool.
You might think assembly language is also cool.  But it's not what your employer wants yo to use, in most cases.

4.  You hate MySQL, and although PostgreSQL is much better, it still doesn't have decent replication. There's no chance you're buying Oracle licenses.
Now there is a free (at MySQL scale) fully featured SQL database that does the equivalent of replication in a completely hassle free fashion.

5.  Your data is stored and retrieved mainly by primary key, without complex joins.
Fair enough.  Don't use a fully featured database if all you need is a file system or a blob-store.

6.  You have a non-trivial amount of data, and the thought of managing lots of RDBMS shards and replication failure scenarios gives you the fear.
Sharding is a great idea if you have no other ideas.  NuoDB does no sharding or partitioning, though it will happily use the distributed storage of an underlying blobstore.

That's right - NuoDB is a SQL/ACID RDBMS uses a KV-store as it's backend storage.  So we love all the systems listed above.  They are exactly what is needed as a substrate for a next generation SQL database.  Take a look at nuodb.com if you are interested in the future of databases.

[RJ]

Comment written by Don Pinto on 11/27/2012 20:44:25

It will be good to see Couchbase as well here. www.couchbase.com

[RJ]

Comment written by priya on 08/21/2013 11:24:34

HI.. i was looking for some help on hbase

[RJ]

Comment written by Jaimie on 08/07/2015 11:15:09

You can improve your current RDBMS structure by including a layer of distributed cache or completely replace it.
You can use in-memory data grids in both ways such as http://www.tayzgrid.com/

[RJ]

Comment written by reginaerzbeth on 09/24/2016 08:39:21

Helpful post - I learned a lot from the points - Does someone know if my company can get access to a template CA Trust Transfer Grant Deed form to edit ?

[RJ]

Comment written by Madhavrao Peshwa on 05/06/2017 17:56:11

More than 8 years and lets see who is where?
1)ThruDB-Last commit happened 8 years back!
2)CouchDB- Not as popular as it was before and i recall ,part of it was rewritten in C.
3)Scalaris- Last release March 2016
4)Hadoop and Cassandra- Hype is settled down. You don't hear "Hadoop developers earning 200$/Hr as we heard in 2009/2010"
5)Posgre/Mysql- quietly doing CRUD without much hype and making us earn salary!

[RJ]

Comment written by finnich on 07/30/2018 11:58:11

I loved this site....its really great and promising.

[RJ]

Comment written by Prateek Jain on 10/09/2019 16:09:23

This tutorial features a brief knowledge of CouchDB, the procedures for setting it up, and how CURL communicates with the CouchDB server. It also tells us how to create, update and delete databases and documents.