Cassandra vs MongoDB vs CouchDB vs Redis vs Riak comparison
41–50 of 96 posts
Re: Cassandra vs MongoDB vs CouchDB vs Redis vs Riak comparison
#42One 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
#43I'm curious why you wouldn't include HBase as it's the dominant solution for NoSQL in systems requiring data consistency?
Thanks for the feedback!
Re: Cassandra vs MongoDB vs CouchDB vs Redis vs Riak comparison
#44Much 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
#45Interesting 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…
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
#46My 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...
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
#47Worth 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…
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
#48Interesting 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…
actually it is, you might take a peek at BigCouch[1], it puts the C in CouchDB.
Re: Cassandra vs MongoDB vs CouchDB vs Redis vs Riak comparison
#49My 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…
CouchDB does not version, period.
Re: Cassandra vs MongoDB vs CouchDB vs Redis vs Riak comparison
#50> 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.