If you plan to have no redundancy, you probably aren't building anything valuable enough to care about losing some data anyways. The extra hours of my life I get back due to productivity from using mongo over something like mysql is worth it x 100. Not a big fan of the single server durability argument.
Two Reasons You Shouldn't Use MongoDB
11–20 of 28 posts
Re: Two Reasons You Shouldn't Use MongoDB
#12Bonus points for spelling "kernel" wrong.
Re: Two Reasons You Shouldn't Use MongoDB
#13Good points, I can think of a few companies who appear to be using Mongo because it's 'cool' and don't sem to understand the tradeoffs. For the applications I have in mind, there is absolutely no reason they couldn't just use postgres, other than that they want to believe they are 'cutting edge'.
The idea should be that you are picking the right tool for the job. Just because you could just use Postgres, doesn't mean that another data store wouldn't be better suited for your problem space. Could be Mongo, could be Cassandra, it very well could be Postgres, but you should be doing some up front analysis and research before you make that decision.
Re: Two Reasons You Shouldn't Use MongoDB
#14People should stop looking for silver bullets that are a) "web scale" (intentionally in quotation marks) and b) super secure/durable/consistent/whatever. It's all trade offs. MongoDB makes sense for some data but not others. Its weaknesses are its strengths and vice versa. Same goes for SQL databases. We use MongoDB for storing tons and tons of analytics data for which we don't care if some stuff occasionally gets lo…
I fail to see why analytics data seem to be considered "low quality" data ("we don't care if some stuff occasionally gets lost"). As far as I can tell, most businesses out there are driven by metrics which are derived from analytics data... so I don't agree that "it's OK to lose some".
What jacquesm said. It depends on the kind of analytics data; our data is not as important as someone else's analyitcs data. For us it's more important writes are of reasonable speed, that we can store the data in arbitrary structures in a schemaless way, that we can define arbitrary search indexes and that the data can be horizontally spread across multiple servers.
Website visit counters are a great example. I don't think many people care if a few visits get lost once in a while.
Re: Two Reasons You Shouldn't Use MongoDB
#15Bonus points for spelling "kernel" wrong.
Thanks for pointing that out, it's been fixed.
Re: Two Reasons You Shouldn't Use MongoDB
#16Good points, I can think of a few companies who appear to be using Mongo because it's 'cool' and don't sem to understand the tradeoffs. For the applications I have in mind, there is absolutely no reason they couldn't just use postgres, other than that they want to believe they are 'cutting edge'.
The idea should be that you are picking the right tool for the job. Just because you could just use Postgres, doesn't mean that another data store wouldn't be better suited for your problem space. Could be Mongo, could be Cassandra, it very well could be Postgres, but you should be doing some up front analysis and research before you make that decision.
Sure. My point is that as far as I can tell, Postgres would be better suited to the application, but they want to use Mongo because it's new, regardless of the fact that data integrity, not sheer performance, is more important for this application.
Re: Two Reasons You Shouldn't Use MongoDB
#17Well, the MongoDB docs make the same points really clear. Run master slave, or replica set. Do reads from the slaves, writes to the master. If you do this, that about covers it. In my blog, I call this MongoDB "good enough practices."
Re: Two Reasons You Shouldn't Use MongoDB
#18Good points, I can think of a few companies who appear to be using Mongo because it's 'cool' and don't sem to understand the tradeoffs. For the applications I have in mind, there is absolutely no reason they couldn't just use postgres, other than that they want to believe they are 'cutting edge'.
I'd argue that there are more people out there who could be benefitting from using Mongo but won't because SQL databases are "standard".
Re: Two Reasons You Shouldn't Use MongoDB
#19If you plan to have no redundancy, you probably aren't building anything valuable enough to care about losing some data anyways. The extra hours of my life I get back due to productivity from using mongo over something like mysql is worth it x 100. Not a big fan of the single server durability argument.
I agree; I don't get all the fuss about "single server durability." Single servers fail all the time. After many hard lessons learned, I just assume that if it's only on a single server it's as good as gone. Bad RAID controllers, etc.
If you're really worried about durability, you should be replicating anyway--and, ideally, over 3+ nodes at least two datacenters. I've always just assumed MongoDB was designed around that idea.
Re: Two Reasons You Shouldn't Use MongoDB
#20People should stop looking for silver bullets that are a) "web scale" (intentionally in quotation marks) and b) super secure/durable/consistent/whatever. It's all trade offs. MongoDB makes sense for some data but not others. Its weaknesses are its strengths and vice versa. Same goes for SQL databases. We use MongoDB for storing tons and tons of analytics data for which we don't care if some stuff occasionally gets lo…
some humor to validate your point :) http://www.xtranormal.com/watch/6995033/