|
|
|
|
|
|
by gwagner85
4885 days ago
|
|
|
I am not discounting due to word choice, i am discounting because his points seem to be a rant based on the whim that software never has bugs or problems. For some mongo does exactly as advertised, for some it doesn't. It is the same argument that you can pose between eventual and immediate consistency. 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?