Cassandra vs MongoDB vs CouchDB vs Redis vs Riak comparison
71–80 of 96 posts
Re: Cassandra vs MongoDB vs CouchDB vs Redis vs Riak comparison
#72Re: Cassandra vs MongoDB vs CouchDB vs Redis vs Riak comparison
#73Earlier quoted context omitted.
I'll question you on one point: "Use it when you need random, realtime read/write access to your Big Data." Does HBase now do a good job of random access? I was always under the impression that it did random access adequately, but it's real strength was with scans (based on ordering of keys).
Here's an informative presentation about how HBase has (massively) sped up random access, as of version 0.20: http://www.docstoc.com/docs/7493304/HBase-Goes-Realtime I did benchmarks on a previous version, and the results were pretty miserable (600ms/lookup on a table with several million columns). It certainly sounds like they've improved.
Re: Cassandra vs MongoDB vs CouchDB vs Redis vs Riak comparison
#74I was hoping HandlerSocket would be in here. If you don't know about it, check it out http://news.ycombinator.com/item?id=1886137
I don't know that one yet, but I promise I'll read up on it! Thanks! K.
Re: Cassandra vs MongoDB vs CouchDB vs Redis vs Riak comparison
#75Earlier quoted context omitted.
thanks. latest version of the article is here now http://blog.couchone.com/post/632718824/simple-document-vers...
THAT jchrisa, seriously? Wow, I'm honored that you chimed in! Thanks, man :)
Re: Cassandra vs MongoDB vs CouchDB vs Redis vs Riak comparison
#76> 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.
Re: Cassandra vs MongoDB vs CouchDB vs Redis vs Riak comparison
#77-------- http://bit.ly/eTAvV5 --------
-------- http://bit.ly/eTAvV5 --------
-------- http://bit.ly/eTAvV5 --------
-------- http://bit.ly/eTAvV5 --------
-------- http://bit.ly/eTAvV5 --------
Gold autumn, personality Men’s clothing Shoes, Travel bag that grabs an eye coat Chao packet Free transport
-------- http://bit.ly/eTAvV5 --------
-------- http://bit.ly/eTAvV5 --------
-------- http://bit.ly/eTAvV5 --------
-------- http://bit.ly/eTAvV5 --------
-------- http://bit.ly/eTAvV5 --------
-------- http://bit.ly/eTAvV5 --------
Re: Cassandra vs MongoDB vs CouchDB vs Redis vs Riak comparison
#78For example, CouchDB having a "Main Point" of "DB consistency" might be the case, as it is for Redis, when there is no replication. In replicated configurations, it is definitely not true. Further, the MVCC is weaker in many ways than in a Dynamo system like Riak as you have no way to influence or discover consistency between replicas.
I'm sure folks expert in other systems can identify similar errors in the rest of the post. Can someone explain to me who the target audience is for all these NoSQL comparison articles? They are universally poor, yet universally popular.
Re: Cassandra vs MongoDB vs CouchDB vs Redis vs Riak comparison
#79Worth 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
#80So if Cassandra writes are much faster than reads, why would Reddit go that route? Their comment server is consistently breaking on them, and it would seem that a sub-optimal choice of db might be partly to blame.