This article should be banned for lack of references and examples. For those of you looking to learn mongodb check this out http://www.mongodb.org/display/DOCS/Production+Deployments
Don't use MongoDB
41–50 of 331 posts
Re: Don't use MongoDB
#42Burden of proof is on 10gen, not frustrated customers. This post is believable enough for me to avoid using MongoDB for write-heavy apps.
What if it's not a frustrated customer but a libelous, frustrated competitor instead?
Re: Don't use MongoDB
#43Earlier quoted context omitted.
MySQL is a poor analogy because the history of MySQL is very similar to 10gen: a 'hacker' solution originally patched together by people who didn't take their responsibility as database engineers very seriously. It's only after years (decades) of work that MySQL has managed to catch up with database technology of the 80s in terms of reliability and stability (and it still has plenty of issues, as the most recent deba…
I agree with you but my comments are more about telling what is going on in my opinion, instead of telling what I think should be the right priority list. Even if I agree I still recognize that MySQL had a much bigger effect to the database world compared to PostgreSQL, so the success of a database can sometimes take strange paths. But I think a major difference between MySQL and Redis, MongoDB, Cassandra, and all th…
MySQL was the original NoSQL.
The wrong answer, faster.
Re: Don't use MongoDB
#44There's a lot of anonymity going on here. A new HN account, an unknown company and product, and claims with no evidence. Why are't links to 10gen's Jira provided? Where's the test code that shows the problems they had with the write lock? This is an extremely shallow analysis.
And yet he makes some good points. Pretty much all of this is verifiable.
I don't agree with a lot of his conclusions, but mostly his data is correct.
Re: Don't use MongoDB
#45Burden of proof is on 10gen, not frustrated customers. This post is believable enough for me to avoid using MongoDB for write-heavy apps.
What if it's not a frustrated customer but a libelous, frustrated competitor instead?
In most case, I think 10gen will be able to dispute false claims.
With regard to nomongo's post, 10gen can check their record and say whether they did or didn't have a customer with premium support account with similar use case and issues. 10gen can also counter such complaints with testimonials from customers with similar use cases.
But note that nomongo's post is not about individual issues but about his concern that 10gen's priorities are misplaced which he should have wrote first instead of last. Rest was just about how his concern came about. Current status of technical issues he experienced are irrelevant to his concern.
Re: Don't use MongoDB
#46I've used MongoDB in production since the 1.4 days. It should be noted that my apps are NOT write heavy. But, many of the author's points can be refuted by using version 2.0. Regarding the point of using getLastError(), the author is completely correct. But the problem is not so much that MongoDB isn't good, it's that developers start using it and expect it to behave like a relational DB. Start thinking in an asynchr…
Schema-less is imho a overrated feature. ORMs like DataMapper (Ruby) and NHibernate (.NET) can generate the schema on the fly for RMDBS, so no need for migrations pre-production. But when your application is in production you need migrations even with a "schema-less" db! See, rename a field and "all your data" is lost, unless you migrate the data from the old field to the new one..
Re: Don't use MongoDB
#47No shit, nmongo.
Anyone with half a brain can go look at the MongoDB codebase and deduce that it's amateur hour.
It's start up quality code but it's supposed to keep your data safe. That's pretty much the issue here -- "cultural problems" is just another way of saying the same thing.
Compare the code base of something like PostgreSQL to Mongo, and you'll see how a real database should be coded. Even MySQL looks like it's written by the world's best programmers compared to Mongo.
I'm not trying to hate on Mongo or their programmers here, but you've basically paid the price for falling for HN hype.
Most RDBMSes have been around for 10+ years, so it's going to take a long, long time for Mongo to catch up in quality. But it won't, because once you start removing the write lock and all the other easy wins, you're going to hit the same problems that people solved 30 years ago, and your request rates are going to fall to memory/spindle speed.
Nothing's free.
Re: Don't use MongoDB
#48Burden of proof is on 10gen, not frustrated customers. This post is believable enough for me to avoid using MongoDB for write-heavy apps.
What if it's not a frustrated customer but a libelous, frustrated competitor instead?
Except that those are not the words on a libelous, frustrated competitor. I've seen these claims validated over and over again both by posts on HN but also people I trust that have worked with MongoDB under load.
Performance benchmarks stop being meaningful when you realize that you can't fix the problem you're having without committing to a system-wide shutdown of unknown duration.
The main point that the author makes is that the creators of MongoDB do not follow rigourous practices. If this doesn't bother you, please go right ahead and use anything you wish.
I hear that /dev/null is really zippy these days.
Re: Don't use MongoDB
#49People seem to be jumping on a lot of the NoSQL stuff for no good reason. You can get a lot of mileage out of something like Postgres or Mysql, and they work pretty well for a lot of things. Ok, if you get huge, you might have to figure out something else, but that's a good problem to have. On the other hand, if you've lost all your data, you're not going to get huge.
I had to use MongoDB recently, and I wasn't very pleased with it. It wasn't really appropriate for the project, which had data that would have fit better in a relational DB.
Re: Don't use MongoDB
#50Losing data is one of the most serious bugs. When I am using a DBMS in production, I have to rely on it 100%.
I believe the complains made could be real because MongoDB is highly optimized for speed. But, as long as there is no documented and maybe reproducible case, this post can't be taken for real.