Earlier quoted context omitted.
To be honest, Mongo's execs have done pretty much the same thing. As I said in another comment, the Changelog episode on Mongo was very illuminating with regards to the marketing tactics of 10gen. I do like both, as well.
Is this the episode? http://thechangelog.com/post/3742814720/episode-0-5-1-mongod...
It's Time to Drop the "F" Bomb - or "Lies, Damn Lies, and NoSQL."
21–30 of 67 posts
Re: It's Time to Drop the "F" Bomb - or "Lies, Damn Lies, and NoSQL."
#22Earlier quoted context omitted.
I hate subliminal attacks like these ... if you have a problem with someone, come out and say it, don't let me have to figure out what or who you're getting at. And with regards to Mongo ... they've since added a feature that allows 'safe' writes to your database (confirms the data is written before returning a response) ... so what's the rant about?
The 'safe' feature isn't on by default, yet. Also, the benchmarks 10gen publishes are based on default setup, so basically, Mongo writes to RAM, therefore it's fast. I love Mongo and am using it in a few apps, but their marketing does blow, I admit. Also, Eliot Horowitz came out and bashed on Riak's eventual consistency promise by basically misleading devs into thinking that writing to MongoDB will always result in '…
I transcribed the MongoDB vs. Riak part of the Changelog webcast (available at http://thechangelog.com/post/3742814720/episode-0-5-1-mongod...):
------------------------
Riak and all the dynamo-style databases are really distributed key/value stores and I think, you know, I've never used Riak in production, but I have no reason not to believe it's not a very good, highly scalable distributed key/value store.
The difference between something like Riak and Mongo is that Mongo tries to solve a more generic problem. A couple of key points: one is consistency. Mongo is fully consistent, and all dynamo implementations are eventually consistent and for a lot of developers and a lot of applications, eventual consistency just is not an option. So I think for the default data store for a web site, you need something that's fully consistent.
The other major difference is just data model and query-ability and being able to manipulate data. So for example with Mongo you can index on any fields you want, you can have compound indexes, you can sort, you know, all the same types of queries you do with a relational database work with Mongo. In addition, you can update individual fields, you can increment counters, you can do a lot of the same kinds of update operations you would do with a relational database. It maps much closer to a relational database than to a key/value store. Key/value stores are great if you've got billions of keys and you need to store them, they'll work very well, but if you need to replace a relational database with something that is pretty feature-comparable, they're not designed to do that.
-----------------------
It starts at minute 17.
edited: formatting.
Re: It's Time to Drop the "F" Bomb - or "Lies, Damn Lies, and NoSQL."
#23Earlier quoted context omitted.
The 'safe' feature isn't on by default, yet. Also, the benchmarks 10gen publishes are based on default setup, so basically, Mongo writes to RAM, therefore it's fast. I love Mongo and am using it in a few apps, but their marketing does blow, I admit. Also, Eliot Horowitz came out and bashed on Riak's eventual consistency promise by basically misleading devs into thinking that writing to MongoDB will always result in '…
10gen doesn't publish any benchmarks. See http://www.mongodb.org/display/DOCS/Benchmarks for the official position. I transcribed the MongoDB vs. Riak part of the Changelog webcast (available at http://thechangelog.com/post/3742814720/episode-0-5-1-mongod... ): ------------------------ Riak and all the dynamo-style databases are really distributed key/value stores and I think, you know, I've never used Riak in produc…
Can you please explain this for a case where there are multiple replica sets, the database is sharded and nodes are across data centers? What's sacrificed? Something must be.
Re: It's Time to Drop the "F" Bomb - or "Lies, Damn Lies, and NoSQL."
#24Earlier quoted context omitted.
10gen doesn't publish any benchmarks. See http://www.mongodb.org/display/DOCS/Benchmarks for the official position. I transcribed the MongoDB vs. Riak part of the Changelog webcast (available at http://thechangelog.com/post/3742814720/episode-0-5-1-mongod... ): ------------------------ Riak and all the dynamo-style databases are really distributed key/value stores and I think, you know, I've never used Riak in produc…
>Mongo is fully consistent Can you please explain this for a case where there are multiple replica sets, the database is sharded and nodes are across data centers? What's sacrificed? Something must be.
Re: It's Time to Drop the "F" Bomb - or "Lies, Damn Lies, and NoSQL."
#25Earlier quoted context omitted.
10gen doesn't publish any benchmarks. See http://www.mongodb.org/display/DOCS/Benchmarks for the official position. I transcribed the MongoDB vs. Riak part of the Changelog webcast (available at http://thechangelog.com/post/3742814720/episode-0-5-1-mongod... ): ------------------------ Riak and all the dynamo-style databases are really distributed key/value stores and I think, you know, I've never used Riak in produc…
>Mongo is fully consistent Can you please explain this for a case where there are multiple replica sets, the database is sharded and nodes are across data centers? What's sacrificed? Something must be.
With replica sets, we're still only dealing with one master. We can get inconsistant reads from the replicas, but we're always writing to a single master, which allows that master to determine the integrity of a write.
With sharding, we're still only dealing with one canonical home for a specific key(defined by the shard key). (besides latency, I'm not sure how datacenters would affect this)
What we're giving up in this case is availability. If an entire replica set goes down, we can't read or write any data for the key ranges contained on those machines. This is where Riak shines.
With Riak, any node can accept writes, and nodes contain copys of several other nodes data. What that means is, as long as we have one node up, we can write to the database. Because of this, there is the possibility of nodes having different views of the data. This is handled in a number of ways(read repairs, vector clocks, etc). Check out the Amazon Dynamo paper for more info, great read.
I'm sure I'm missing some stuff, but I think that covers the gist of it.
EDIT: One thing that I want to make clear, I don't think that one architecture is better than the other. They each have their own pros and cons, and are really suited to solve different problems.
Re: It's Time to Drop the "F" Bomb - or "Lies, Damn Lies, and NoSQL."
#26Earlier quoted context omitted.
It was a thinly veiled bash on Mongo.
Not just Mongo though, there are a lot of NoSQL companies out there right now whose marketing claims the impossible.
For example, I do lots of experiment logging to a mongodb. If the power goes out, and the data is lost who cares? The data was no longer valid or useful -- but if I slow down my writes for 'safety' I will be causing problems by introducing delay in ways that could cause conflict.
Re: It's Time to Drop the "F" Bomb - or "Lies, Damn Lies, and NoSQL."
#27Earlier quoted context omitted.
>Mongo is fully consistent Can you please explain this for a case where there are multiple replica sets, the database is sharded and nodes are across data centers? What's sacrificed? Something must be.
The implication is that the people for whom eventual consistency is not an option will never reach a data set size or availability requirement that'll require them to use replication and experience the lag (and eventual consistency) involved.
Re: It's Time to Drop the "F" Bomb - or "Lies, Damn Lies, and NoSQL."
#28I think the problem with NoSQL is that they are targeting the wrong people - the lazy people. One of the DBs we reviewed (can't remember which) did not have single datacentre durability, lost like 80% data while crash during updating table contents and was boasting some geo-coordinate built-in datatype on their website. Its the priorities plague. Is built-in geo more important than data?
Why do NoSQL databases have to be all distributed beyond sharding? I think because thats what people wrongly perceive out of them. Google, LinkedIn all use NoSQL which is distributed, so if a NoSQL DB doesn't do it, its a shame. Thats the root of misjudgment I believe. Every DB, NoSQL or not, needs to have a place. One size fits all is what will kill NoSQL, whether enforced by engineering or marketing. Thats why I think marketing "lie".
CouchDB, Riak and Redis are only few exceptions I know of which seemed to have a vision and stuck to it.
Re: It's Time to Drop the "F" Bomb - or "Lies, Damn Lies, and NoSQL."
#29Earlier quoted context omitted.
10gen doesn't publish any benchmarks. See http://www.mongodb.org/display/DOCS/Benchmarks for the official position. I transcribed the MongoDB vs. Riak part of the Changelog webcast (available at http://thechangelog.com/post/3742814720/episode-0-5-1-mongod... ): ------------------------ Riak and all the dynamo-style databases are really distributed key/value stores and I think, you know, I've never used Riak in produc…
>Mongo is fully consistent Can you please explain this for a case where there are multiple replica sets, the database is sharded and nodes are across data centers? What's sacrificed? Something must be.
You can never have multi-master with MongoDB, which is required for "always writable." However, it can be readable. Our CEO did a series of posts on distributed consistency, see http://blog.mongodb.org/post/475279604/on-distributed-consis....
Re: It's Time to Drop the "F" Bomb - or "Lies, Damn Lies, and NoSQL."
#30Peace and love to the human family.
- Lil' B