
When a No means Yes - hoonose
http://hackingdistributed.com/2013/02/07/10gen-response/
======
brennenHN
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.

~~~
groby_b
And of course the HN boys club doesn't see anything wrong with the headline. I
expected nothing less :(

Seriously, people: "No means yes" is a _clear_ reference to "No means no".
It's a really bad choice of headline, because it communicates "I don't care
about issues that women are facing, if it gets me a catchy headline".

~~~
danso
I'd be inclined to be ambivalent on this, except that in the OP there is no
literal "yes" or "no" involved (i.e., something like, "I set the
MONGO_UNSAFE_DATA_COMMIT flag to 'No'") so I'm not even sure what the headline
means, except that it gets a little edge parodying the anti-rape saying.

At least you can't blame the OP for thinking too much about SEO.

------
ismarc
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
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
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
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
400k ops/s?

How many machines is that?

~~~
dkhenry
I can do it one one.

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

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

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

~~~
josh2600
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
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
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?

~~~
gwagner85
With the default settings in MySQL if you shut down an innodb database
incorrectly you will loose data if not the entire table, should we vilify them
for the same thing.

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.

~~~
jeltz
> With the default settings in MySQL if you shut down an innodb database
> incorrectly you will loose data if not the entire table, should we vilify
> them for the same thing.

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.

~~~
gwagner85
> Yes, we should. I do not think shipping unsafe defaults is ok.

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.

