This guys arguments are really bad because he makes them from a very narrow one sided point of view. It is actually hard to read through the hatred....
If you read the Mongo rebuttal it seems as though they willfully misconstrued the points he made in his original post.
Mongo was broken by default in 2.0, that's why they changed the default behavior in subsequent versions. The author even went out of his way to talk about the changed behavior in his first post.
I don't know, this is the first critique of Mongo I've seen that really attacks Mongo stability and I'm eager to see how Mongo responds. The author is correct that Jason's (from Mongo) response left a lot to be desired.
Yes the author appears to dislike Mongo, but if his reasons are correct and his points are valid, discounting his opinion due to word choice seems unnecessary.
Also i will be the first to agree that Mongo does not hold up well to all points but to say that data gets lost is pretty bold. I have been using it for quite some time now and by following mongo best practices, i have not lost any data. In fact by following mongo best practices i have saved myself from a few data-catastrophes.
The argument that it doesn't come configured correctly out of the box is pretty weak too (at least that is how i am reading his statement of "broken by default"). What is configuration too hard. Sure they put their software out in a way that is more in tune with a lab / development atmosphere... but if your using mongo in production and you do not do the proper configuration steps, then maybe you should hang up your devops hat and hand that job off to someone else. Even mysql sucks for production out of the box, it is a security nightmare. Innodb looses data when shutdown incorrectly especially if the journal is corrupt. Saying that there is only one drive fault tolerance just means that your not striping your data properly. All the arguments are based upon a lazy implementation not actual problems.
And YES you should know something about how your backend software works. You should know it intimately so that you can debug and make it more bullet proof. So ya, i think the arguments are weak and full of hate and not something made off of experience and ability to work with a software vendor. Do i think mongo is perfect for the tinkerer like mysql is, no. Do i think mongo is good enough to hold BI data that is critical, yes.
On the one hand we're talking about Mongo working out of the box and on the other we're talking about developer skill. I'll agree with you that an unskilled developer is going to have a bad time running any Database, but I take issue with the idea that defaults aren't important.
The default settings are the defaults for a reason. Whether that reason is ease of adoption or performance testing, there's a reason. Mongo's default behavior was not sensible and has since been corrected to be more sensible, and I think we both agree on this point.
Mongo is a really cool database with a lot of neat features, but it doesn't get a pass just because it's cool. If the defaults on Mongo could cause data loss, they should change the defaults, right?
I agree you should understand your backend, but I also see a lot of value in having sane default settings. To be honest, the majority of users may never pass beyond the default settings, which is a shame, but true.
So the author's rant is just that, but he's not wrong. He might be mistaken about the potential of Mongo, but he's not really mistaken about Mongo "out-of-the-box".
Does that clarify my position with respect to the author's opinions?
I am not saying he is wrong, and i am not saying that mongo is wrong either. I feel, if you RTFM, that they are very very clear as to the state of things. They are not hiding anything and if anything they are providing and application state that is not ideal for said user too bad IMO. I am not going to setup a new linux box without changing the root password, or setup a wordpress site without altering the config and locking down apache. Did you know a linux system is not 100% secure out of the box, WHAT A SHOCKER.
Yes, we should. I do not think shipping unsafe defaults is ok.
> I am not going to setup a new linux box without changing the root password
This is why most Linux installers prompt you for the password.
Isn't it the difference between shipping a product open enough and with enough barriers torn down to get the hobbyist hooked (drug dealers) and the expert will have a script to fix all those hols anyway. And agreed, shipping with unsafe defaults is bad for the expert but very very good for the novice.
> This is why most Linux installers prompt you for the password.
The key word there is MOST.
We've all had those co-workers who come to us with tough to debug problems that we correctly diagnose for them and lay out for them, only to have them gloss over the details and claim the issue we found isn't an issue at all. Their inability to follow the details was the root of their inability to debug the problem. In the case of the blog post, the guy who diagnosed the issue is the one coming to the person with the bug, but this blog post is the same old your-inattention-to-subtle-detail-always-makes-you-come-to-me-I've-always-been-right-in-the-past-so-just-try-my-suggested-fix-before-arguing argument, but happening out in public on the Interwebs.
Couldn't read past that.