"Don't use MongoDB" post was a hoax(h-online.com)
h-online.com
"Don't use MongoDB" post was a hoax
http://www.h-online.com/open/news/item/MongoDB-FUD-or-Hoax-controversy-spreads-online-1374710.html
11 comments
"If you are working with a database, I would hope that you do not allow your expectations to be set by the marketing department. If you don't do your due diligence then you deserve to be bitten."
That's the real definition of "hard to use": you have to research everything yourself and send the product through QA just to use it.
There's a very high value in products where you don't have to do a lot of research on the implementation quality and caveats. If you start using it, and it appears to work for your needs, you won't be bitten too badly later. In my opinion, PostgreSQL is an example of such a product.
Of course there is always some opportunity to do the wrong thing. It's a question of degree.
Following your advice would essentially mean "only big companies can ever release anything" because you'd need a team of full-time people to sit around doing research and QA for libc and the kernel and everything else you depend on.
That's the real definition of "hard to use": you have to research everything yourself and send the product through QA just to use it.
There's a very high value in products where you don't have to do a lot of research on the implementation quality and caveats. If you start using it, and it appears to work for your needs, you won't be bitten too badly later. In my opinion, PostgreSQL is an example of such a product.
Of course there is always some opportunity to do the wrong thing. It's a question of degree.
Following your advice would essentially mean "only big companies can ever release anything" because you'd need a team of full-time people to sit around doing research and QA for libc and the kernel and everything else you depend on.
Maybe I'm just weird, but all of this drama around a database does not make much sense to me.
Because it's the most painful point of tech. If you need to change programming languages to meet a latency requirement, that sucks. If you find your servers go down and they need rebooting, that sucks too. If you lose your data, it's gone and you can never get it back.
The troll did well to zero in on this. You don't really know how stable a database is under certain conditions until you start hitting the roadblocks. With NoSQL databases, you have less time in the wild vs RBDMSs, so anything which indicates there are hidden gotchas are going to set potential adopters' teeth on edge.
Even better, with database issues, you don't know about them until you have them, so you often do have to rely on folk knowledge about how well they turn out in practice after months/years of deployment.
It was a well-targeted troll.
Because it's the most painful point of tech. If you need to change programming languages to meet a latency requirement, that sucks. If you find your servers go down and they need rebooting, that sucks too. If you lose your data, it's gone and you can never get it back.
The troll did well to zero in on this. You don't really know how stable a database is under certain conditions until you start hitting the roadblocks. With NoSQL databases, you have less time in the wild vs RBDMSs, so anything which indicates there are hidden gotchas are going to set potential adopters' teeth on edge.
Even better, with database issues, you don't know about them until you have them, so you often do have to rely on folk knowledge about how well they turn out in practice after months/years of deployment.
It was a well-targeted troll.
and it is a easily trollable target as well. Had he tried to to attack durability on probably any other database, it probably would not have worked as well as it did.
Whether its a troll attempt or not, remains to be seen, but I completely agree with this specific, albeit very generic, part of the text.
> Databases must be right, or as-right-as-possible, b/c database mistakes are so much more severe than almost every other variation of mistake. Not only does it have the largest impact on uptime, performance, expense, and value (the inherit value of the data), but data has inertia. Migrating TBs of data on-the-fly is a massive undertaking compared to changing drcses or fixing the average logic error in your code. Recovering TBs of data while down, limited by what spindles can do for you, is a helpless feeling.
Whether its a troll attempt or not, remains to be seen, but I completely agree with this specific, albeit very generic, part of the text.
> Databases must be right, or as-right-as-possible, b/c database mistakes are so much more severe than almost every other variation of mistake. Not only does it have the largest impact on uptime, performance, expense, and value (the inherit value of the data), but data has inertia. Migrating TBs of data on-the-fly is a massive undertaking compared to changing drcses or fixing the average logic error in your code. Recovering TBs of data while down, limited by what spindles can do for you, is a helpless feeling.
Couldn't agree more about trolling the issue tracker of a project you plan on adopting. It does wonders as far as learning the ins and outs of a project and how the team works/what they prioritize.
Also, +1 on the rest of what you said.
Also, +1 on the rest of what you said.
The person claiming it is a hoax submitted the story to HN, but only after another account (nomoremongo) posted it in a comment. These do not appear to be the same person:
http://news.ycombinator.com/threads?id=nomoremongo
http://news.ycombinator.com/item?id=3206367
http://news.ycombinator.com/threads?id=nomoremongo
http://news.ycombinator.com/item?id=3206367
It's the same guy. He creates an account, makes a comment, but doesn't know how to submit his own story? Bullocks.
No, it wasn't:
http://news.ycombinator.com/item?id=3205221
(This is the only throwaway account I've ever used. I dunno who those other dudes are.)
http://news.ycombinator.com/item?id=3205221
(This is the only throwaway account I've ever used. I dunno who those other dudes are.)
This link, posted here on HN, contains barely anything except a summary of another thread here on HN, which is barely even off the front page. Time to take a break, guys.
This is a particularly poorly sourced article. Most of the story was pieced together from multiple throwaway accounts here. There's nothing by way of verification at all.
If true, a truly shitty thing to do.
It would be great to find out who did the (possible) troll - tarnish their brand.
It would be great to find out who did the (possible) troll - tarnish their brand.
If this is true then that was a particularly shitty troll. What motivation would someone have to do this? It couldn't possibly have been for the lulz, or could it?
Not for the lulz, but I think to metaphorically slap the entire community in the face and show us how fickle we can be with our emotions/decision making processes.
I think it is a valid point... I wouldn't have made it the same way, but there was value to it.
I only think good came out of this for 10gen and Mongo -- how many people are now aware of Mongo and exactly what it does/doesn't do and what 10gen is doing to fix those issues, that had NO IDEA what Mongo was before this happened?
If 10gen wasn't such a strong company, I'd say all the negative attention would likely slow them down and beat them into submission, but it is quite the opposite.
I don't particularly love Mongo or 10gen, but there is no way you can't say that team isn't a powerhouse.
I doubt this hickup did more than cost them an afternoon of a few emails in time, but likely laser-focused their attention on what matters for the 2.x series.
I think it is a valid point... I wouldn't have made it the same way, but there was value to it.
I only think good came out of this for 10gen and Mongo -- how many people are now aware of Mongo and exactly what it does/doesn't do and what 10gen is doing to fix those issues, that had NO IDEA what Mongo was before this happened?
If 10gen wasn't such a strong company, I'd say all the negative attention would likely slow them down and beat them into submission, but it is quite the opposite.
I don't particularly love Mongo or 10gen, but there is no way you can't say that team isn't a powerhouse.
I doubt this hickup did more than cost them an afternoon of a few emails in time, but likely laser-focused their attention on what matters for the 2.x series.
Lovely, now the cycle is complete and we're reading about (and commenting about!) stories that refer to Hacker News comments.
No argument here -- its a bit much, but I didn't realize it had been outed as a hoax and I thought there was value to that.
Given over 1000 upvotes between the 3 stories here and over 1500 on reddit, it seemed worth passing around.
But again, I agree... the horse is dead... and we are all still kicking it.
Given over 1000 upvotes between the 3 stories here and over 1500 on reddit, it seemed worth passing around.
But again, I agree... the horse is dead... and we are all still kicking it.
Nice troll. Is that you, Ted?
To me, it is simple. Do your research:
* Go to https://jira.mongodb.org/ and look at the issues
* Read the documentation at http://www.mongodb.org/display/DOCS/Home
More than likely, if you have to ask the question "should I use a NoSQL db" then the answer is no - just stick with SQL. MongoDB (and most other NoSQL dbs) is a specialized tool that is fit for specific use cases only.
There is no need for all of this ridiculous hyperventilating drama.
I have heard it said that the marketing department at 10gen was not good at "managing expectations". If you are working with a database, I would hope that you do not allow your expectations to be set by the marketing department. If you don't do your due diligence then you deserve to be bitten.
As to the original "Don't Use MongoDB" post. Whether it was a hoax or not was completely besides the point. Every single section in there was completely unsupported by any evidence other than the authors experience.
If you are going to talk about data loss then link to a bug report or a Google query pointing to a bug report or something. Anecdotes are not data.