Live data from Hacker News

Cassandra vs MongoDB vs CouchDB vs Redis vs Riak comparison

kkovacs.eu

41–50 of 96 posts

Re: Cassandra vs MongoDB vs CouchDB vs Redis vs Riak comparison

#42
Interesting and useful.

One major feature differentiator is something it doesn't really talk about, though - how conducive is each system to Massive Data?

For example, he kind of has a bone to pick with Cassandra, which is probably justified. But from what little I know, one of the features of Cassandra is that it's designed to scale pretty much to infinity. That may be true of a couple of the others, but for some (like CouchDB) it isn't a design goal at all.

Re: Cassandra vs MongoDB vs CouchDB vs Redis vs Riak comparison

#43

I'm curious why you wouldn't include HBase as it's the dominant solution for NoSQL in systems requiring data consistency?

Only beacuse I don't know HBase very well. I'll read up on it, at least try it, and then add that too (and also maybe Tokyo Cabinet).

Thanks for the feedback!

Re: Cassandra vs MongoDB vs CouchDB vs Redis vs Riak comparison

#44
Worth adding HBase?

Much below Stolen from their overview page (All needs to be confirmed): http://hbase.apache.org/

WRITTEN IN: Java

MAIN POINT: Hadoop Database

LICENSE: Apache

PROTOCOL: A REST-ful Web service gateway

This project's goal is the hosting of very large tables -- billions of rows X millions of columns -- atop clusters of commodity hardware.

HBase is an open-source, distributed, versioned, column-oriented store modeled after Google' Bigtable: A Distributed Storage System for Structured Data by Chang et al. Just as Bigtable leverages the distributed data storage provided by the Google File System, HBase provides Bigtable-like capabilities on top of Hadoop. HBase includes:

Convenient base classes for backing Hadoop MapReduce jobs with HBase tables

Query predicate push down via server side scan and get filters

Optimizations for real time queries

A high performance Thrift gateway

A REST-ful Web service gateway that supports XML, Protobuf, and binary data encoding options

Cascading, hive, and pig source and sink modules

Extensible jruby-based (JIRB) shell

Support for exporting metrics via the Hadoop metrics subsystem to files or Ganglia; or via JMX

HBase 0.20 has greatly improved on its predecessors:

No HBase single point of failure

Rolling restart for configuration changes and minor upgrades

Random access performance on par with open source relational databases such as MySQL

FOR EXAMPLE: Facebook Messaging Database

BEST USE: Use it when you need random, realtime read/write access to your Big Data.

Re: Cassandra vs MongoDB vs CouchDB vs Redis vs Riak comparison

#45
post #42

Interesting and useful. One major feature differentiator is something it doesn't really talk about, though - how conducive is each system to Massive Data? For example, he kind of has a bone to pick with Cassandra, which is probably justified. But from what little I know, one of the features of Cassandra is that it's designed to scale pretty much to infinity. That may be true of a couple of the others, but for some (l…

Good point, and it's not there since I only wanted to speak from experience; especially with rumors of Cassandra scaling problems at Reddit and Digg.

But sure thing, "infinite" scaling is probably best done with the Dynamo-like stuff like Cassandra and/or RIAK.

Re: Cassandra vs MongoDB vs CouchDB vs Redis vs Riak comparison

#46
post #2

My understanding is that in CouchDB you can't guarantee that older versions of documents will still exists (they might be there, but they could have been removed by compaction or not replicated). However, there is a fairly nice way of storing older versions of documents - hold older versions as file attachments on the document. See: http://jchrisa.net/drl/_design/sofa/_list/post/post-page?sta...

Trying to use CouchDB's versioning system seems like depending on a very leaky abstraction. That you can see it's versioning is a side-effect of how it behaves; not a feature it is providing.

If you need versioned records, you are likely better off identifying your versioning requirements and building to those than trying to piggyback off of something else poorly suited.

Re: Cassandra vs MongoDB vs CouchDB vs Redis vs Riak comparison

#47

Worth adding HBase? Much below Stolen from their overview page (All needs to be confirmed): http://hbase.apache.org/ WRITTEN IN: Java MAIN POINT: Hadoop Database LICENSE: Apache PROTOCOL: A REST-ful Web service gateway This project's goal is the hosting of very large tables -- billions of rows X millions of columns -- atop clusters of commodity hardware. HBase is an open-source, distributed, versioned, column-oriente…

Thanks, Gordon, I put it in (shortened some lines).

It would be great to have a "more general" for-example, since noone outside Facebook meets the problem of "let's build Facebook's messaging database" :) Any suggestions?

Re: Cassandra vs MongoDB vs CouchDB vs Redis vs Riak comparison

#48
post #42

Interesting and useful. One major feature differentiator is something it doesn't really talk about, though - how conducive is each system to Massive Data? For example, he kind of has a bone to pick with Cassandra, which is probably justified. But from what little I know, one of the features of Cassandra is that it's designed to scale pretty much to infinity. That may be true of a couple of the others, but for some (l…

"That may be true of a couple of the others, but for some (like CouchDB) it isn't a design goal at all."

actually it is, you might take a peek at BigCouch[1], it puts the C in CouchDB.

[1] https://github.com/cloudant/bigcouch

Re: Cassandra vs MongoDB vs CouchDB vs Redis vs Riak comparison

#49
post #33
post #2

My understanding is that in CouchDB you can't guarantee that older versions of documents will still exists (they might be there, but they could have been removed by compaction or not replicated). However, there is a fairly nice way of storing older versions of documents - hold older versions as file attachments on the document. See: http://jchrisa.net/drl/_design/sofa/_list/post/post-page?sta...

This is probably the biggest misunderstanding of couchdb, imo. The versioning system in couchdb is only there to make the seamless replication possible. There's no guarantee that previous versions will exist at a future time, like in git. Where couchdb has some immense possibilities is in distributed applications, not only server side, but also mobile phones and browsers. Since you can write and contain an entire web…

"The versioning system in couchdb is only there.."

CouchDB does not version, period.

Re: Cassandra vs MongoDB vs CouchDB vs Redis vs Riak comparison

#50
post #8

> While SQL databases are insanely useful tools, their tyranny of ~15 years is coming to an end This shit, AGAIN? Really? No, they are not.

With AppEngine at Google, MongoDB at Disqus, Cassandra at Facebook and Redis at Github you can definitely say that SQL databases are one of many options available today and don't dominate like they did 5 years ago.

probably worth to note that Disqus uses Redis as well, not for storing the comments, but for analytics: http://disqus.com/analytics/
Post reply on HN