6 ms·

When a No means Yes

89 points by hoonose 14y ago

gwagner85 14y ago
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....
- aeflash 14y ago
  > First, the 10gen spokesperson seems to have read only the H2 elements on my original writeup -- he seems to not have read or understood the actual text that goes along with them. Do they have some local CSS applied that makes regular text invisible? Couldn't read past that.
  - Dylan16807 14y ago
    Why? It was accurate, and it does you no favors to brag about not reading an argument.
    - aeflash 14y ago
      I suppose I was just not in the mood to read an article filled with such an overt tone of condescension.
- cpleppert 14y ago
  Actually he is quite right and MongoDB is a disaster when it comes to data reliability. The fact that some facts are hard to accept as true and cause feelings to be hurt doesn't change their validity. Not every piece of software is good just because a lot of people use it.
- josh2600 14y ago
  I don't read it as hatred at all. 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.
  - gwagner85 14y 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.
    - josh2600 14y ago
      SO I think we're almost having two separate arguments here. 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?
- KMag 14y ago
  I wouldn't call it hate. He's clearly very frustrated that he carefully worded his points, only to receive responses to points he didn't make. 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.
- deleted 14y ago
  [deleted]
hayksaakian 14y ago
It was a bit snarky, but the points he made were based in fact not opinion. I personally like and use mongo, but I don't pretend it's perfect.
ismarc 14y ago
We recently have been having to work around an issue that, on top of all the other issues we've had means we're moving away from mongo entirely. The current issue is that a mapreduce on a cluster into a sharded collection will, at some point, start silently not writing 30% of the data into the sharded collection. And from that point onward, roughly the same amount of data is lost any time it goes to that collection. We have to watch for it and create an entirely new sharded collection to mapreduce into, then everything works fine for a while until that one starts not getting some data. When we create a new collection, we just pick a new name, copy all the previous data over, update the MRs to point to that collection and hit go. I would be able to understand data loss caused by certain durability settings from a client, but on mapreduce results?
dkhenry 14y ago
I almost feel like I am missing out on hating MongoDB with others, because for me it just works, and _nothing_ I have seen people complain about is really a problem for me. Even in this article your upset because if you have multiple threads using a single connection the getLastError message won't always report the query form the current thread ? That's like saying your upset because the linux kernel does not let other threads know your in the middle of a mutation of a memory address so it may get corrupted. Its your fault deal with it. Then your upset because in the past it didn't preform like you wanted it to so somehow that should be factored into the _current_ reliability ? My takeaway is you didn't care enough about your data in the past to understand your persistence layer why do I feel you are going to do the sane thing in the present and understand your persistence layer now , it appears if it doesn't work like you want it to by default then its broken and 10gen should really be making a datastore just for you. I am more annoyed that I need to now specify that I _don't_ want to wait for confirmation of write, but I at least took the time to understand how the DB works and what I need to do with it.
- banachtarski 14y ago
  What is your usage of it? Saying it works for you might mean nothing at all if you do 5 ops/second on average and have < 10 gb of data or something. Non-gamers are perfectly happy with a shitty graphics card too.
  - mrkurt 14y ago
    Does it matter? We do a pretty continuous 400k ops/s worth of Mongo, but I don't think that's necessarily going to fix anyone's issues with it.
    - moe 14y ago
      400k ops/s? How many machines is that?
      - dkhenry 14y ago
        I can do it one one.
brennenHN 14y ago
Headlines like this are the casual references that makes tech a boys club. You don't think you're doing any harm, but by distorting an important argument about rape, you're undermining the sentiment behind "No means no" even as you use it in a different context.
- epochwolf 14y ago
  Congrats on invoking Godwins law on a topic not related to the thread.
  - luigi 14y ago
    Where did brennenHN invoke Hitler or Nazis? http://en.wikipedia.org/wiki/Godwins_law http://en.wikipedia.org/wiki/Godwins_law
  - tunesmith 14y ago
    Uh, technically, you did.
- luigi 14y ago
  Agreed, that headline is totally rapey.
- rhizome 14y ago
  Hair-trigger, there.
  - brennenHN 14y ago
    You're absolutely right. I have zero tolerance when it comes to cultural acceptance, denial, or apologizing for rape. We all know what the title is referencing, and it's implying that there are circumstances when "no means no" isn't true. The content of the article may be unrelated, but the title is still problematic.
    - deleted 14y ago
      [deleted]
spion 14y ago
Has anyone considered that maybe MongoDB attracts developers because its extremely easy to use? Consider their great homepage scenario: - click "try it out" - type "tutorial" Couple of minutes later you know enough MongoDB for most CRUD apps. Or the restriction-less API: - collections simply come into being. - store arbitrary objects without schemas - create arbitrary indexes - search by arbitrary conditions I can't imagine how one would go with lowering the barrier of entry even further... Yes, this is mostly marketing and usability. No, you can't skip on those and rely only on technical superiority - you have to fight on all fronts.

89 points by hoonose 14y ago

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....

aeflash 14y ago
> First, the 10gen spokesperson seems to have read only the H2 elements on my original writeup -- he seems to not have read or understood the actual text that goes along with them. Do they have some local CSS applied that makes regular text invisible? Couldn't read past that.
- Dylan16807 14y ago
  Why? It was accurate, and it does you no favors to brag about not reading an argument.
  - aeflash 14y ago
    I suppose I was just not in the mood to read an article filled with such an overt tone of condescension.
cpleppert 14y ago
Actually he is quite right and MongoDB is a disaster when it comes to data reliability. The fact that some facts are hard to accept as true and cause feelings to be hurt doesn't change their validity. Not every piece of software is good just because a lot of people use it.
josh2600 14y ago
I don't read it as hatred at all. 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.
- gwagner85 14y 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.
  - josh2600 14y ago
    SO I think we're almost having two separate arguments here. 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?
KMag 14y ago
I wouldn't call it hate. He's clearly very frustrated that he carefully worded his points, only to receive responses to points he didn't make. 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.
deleted 14y ago
[deleted]

hayksaakian 14y ago

It was a bit snarky, but the points he made were based in fact not opinion. I personally like and use mongo, but I don't pretend it's perfect.

ismarc 14y ago

We recently have been having to work around an issue that, on top of all the other issues we've had means we're moving away from mongo entirely. The current issue is that a mapreduce on a cluster into a sharded collection will, at some point, start silently not writing 30% of the data into the sharded collection. And from that point onward, roughly the same amount of data is lost any time it goes to that collection. We have to watch for it and create an entirely new sharded collection to mapreduce into, then everything works fine for a while until that one starts not getting some data. When we create a new collection, we just pick a new name, copy all the previous data over, update the MRs to point to that collection and hit go. I would be able to understand data loss caused by certain durability settings from a client, but on mapreduce results?

dkhenry 14y ago

I almost feel like I am missing out on hating MongoDB with others, because for me it just works, and _nothing_ I have seen people complain about is really a problem for me. Even in this article your upset because if you have multiple threads using a single connection the getLastError message won't always report the query form the current thread ? That's like saying your upset because the linux kernel does not let other threads know your in the middle of a mutation of a memory address so it may get corrupted. Its your fault deal with it. Then your upset because in the past it didn't preform like you wanted it to so somehow that should be factored into the _current_ reliability ? My takeaway is you didn't care enough about your data in the past to understand your persistence layer why do I feel you are going to do the sane thing in the present and understand your persistence layer now , it appears if it doesn't work like you want it to by default then its broken and 10gen should really be making a datastore just for you. I am more annoyed that I need to now specify that I _don't_ want to wait for confirmation of write, but I at least took the time to understand how the DB works and what I need to do with it.

banachtarski 14y ago
What is your usage of it? Saying it works for you might mean nothing at all if you do 5 ops/second on average and have < 10 gb of data or something. Non-gamers are perfectly happy with a shitty graphics card too.
- mrkurt 14y ago
  Does it matter? We do a pretty continuous 400k ops/s worth of Mongo, but I don't think that's necessarily going to fix anyone's issues with it.
  - moe 14y ago
    400k ops/s? How many machines is that?
    - dkhenry 14y ago
      I can do it one one.

brennenHN 14y ago

Headlines like this are the casual references that makes tech a boys club. You don't think you're doing any harm, but by distorting an important argument about rape, you're undermining the sentiment behind "No means no" even as you use it in a different context.

epochwolf 14y ago
Congrats on invoking Godwins law on a topic not related to the thread.
- luigi 14y ago
  Where did brennenHN invoke Hitler or Nazis? http://en.wikipedia.org/wiki/Godwins_law http://en.wikipedia.org/wiki/Godwins_law
- tunesmith 14y ago
  Uh, technically, you did.
luigi 14y ago
Agreed, that headline is totally rapey.
rhizome 14y ago
Hair-trigger, there.
- brennenHN 14y ago
  You're absolutely right. I have zero tolerance when it comes to cultural acceptance, denial, or apologizing for rape. We all know what the title is referencing, and it's implying that there are circumstances when "no means no" isn't true. The content of the article may be unrelated, but the title is still problematic.
  - deleted 14y ago
    [deleted]

spion 14y ago

Has anyone considered that maybe MongoDB attracts developers because its extremely easy to use? Consider their great homepage scenario: - click "try it out" - type "tutorial" Couple of minutes later you know enough MongoDB for most CRUD apps. Or the restriction-less API: - collections simply come into being. - store arbitrary objects without schemas - create arbitrary indexes - search by arbitrary conditions I can't imagine how one would go with lowering the barrier of entry even further... Yes, this is mostly marketing and usability. No, you can't skip on those and rely only on technical superiority - you have to fight on all fronts.