Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go Cry on Somebody Else's Shoulder: MongoDB is fine

blog.slyphon.com

Post reply on HN
Print view View original

41–50 of 54 posts

Re: Go Cry on Somebody Else's Shoulder: MongoDB is fine

#41

Post by nullymcnull »

cperciva wrote: post #19

I hate to break it to the poster (and I would if they hadn’t chickened out and actually put their name on their post) but software has bugs. This is not a valid excuse. This is like running a red light, smashing into someone, and then telling them "hey, you should have looked before entering the intersection... you should know that people sometimes run red lights". Yes, you should have backups. No, that doesn't make…

The anon poster claimed to have deployed an early version of Mongo, at a "high profile" company with tens of millions of users, and yet seemed surprised by basic RTFM facts like 'must use getLastError after calls if you need to ensure your write was taken', even well into a production deploy. That should raise huge alarm bells for anyone who is considering taking the guy seriously.

It's just not clear that there were bona-fide 'data-loss bugs' in play here. Seems at least as likely that misuse and misunderstanding of Mongo led to data-loss that could have been avoided.

So, I'd revise your simile. This is more like ignoring a lot of perfectly safe roads which lead to where you're trying to go, instead choosing to chance a more exciting looking shortcut filled with lava pits and dinosaurs. And putting on a blindfold before driving on to it.

Look, NoSQL is wild and wooly and full of tradeoffs, that's a truism by now. If you use such tech without thoroughly understanding it, and consequently run your company's data off a cliff, absolutely it's on you. Mongo does not have a responsibility to put training wheels on and save naive users from themselves, because there should not be naive users. These are data stores, the center of gravity for an application or a business. People involved in choosing and deploying them should not be whinging about default settings being dangerous, about not getting write confirmations when they didn't ask for write confirmations, etc. There's just no excuse for relying blindly upon default settings. Reading the manual on such tech is not optional. Those who don't and run into problems, well, they'd be well-advised to chalk it up as a learning experience and do better next time. Posting "ZOMG X SUCKS BECAUSE I BURNED MYSELF WITH IT" is just silly, reactionary stuff, and it depresses me that HN falls for it and upvotes it like it's worth a damn, every freaking time.

Re: Go Cry on Somebody Else's Shoulder: MongoDB is fine

#42

Post by ubernostrum »

CaptainZapp wrote: post #36
ubernostrum wrote: post #25

Earlier quoted context omitted.

Mongo is fine until it's not. My experience is that this is true of every database system (relational or non-). The thing is that they all break in different ways at different points, and so the smart thing to do is make choices based on that information. The stupid thing to do is write blog posts about how Software Package X sucks and nobody should use it for anything.

I work with databases in extremely high OLTP workload environments since 20 or so years. We're talking enterprise products, mostly Sybase, some Postgresql and very little Oracle. Have I encountered bugs? Sure, tons of them. Some of them grave enough to render the specific version of the database software unusable in the context of the project I worked on. However, in all this time I probably dealt with no more then 3…

So...

If you actually go through the various stuff posted, you find a recurring theme: people who lose data fall into a pattern of "well, they told me not to do this, but I did it anyway, so now it must be their fault".

Which, I think you'll find, is a far cry from "database corruption is inherent in the design".

But hey, learning that sort of thing would require reading; much easier to jump on a bandwagon, badmouth a product and downvote anyone who disagrees, amirite?

Re: Go Cry on Somebody Else's Shoulder: MongoDB is fine

#43

Post by campnic »

Joeri wrote: post #18
bluemoon wrote: post #16

Earlier quoted context omitted.

As he highlights, it is software it will likely have bugs

Yes, but i've been using oracle databases for almost a decade and have never known it to drop data on the floor through bugs (only through user error). Not saying it doesn't happen, just that it's not a common event. It seems with mongo you should expect dataloss.

This is the difference between a database product that has been developed for more then 40 years and a developing software product that has been public for 2.5 years. If mongo has the longevity that Oracle has had with their db product, my guess is that in 40 years we will not be talking about mongo data loss. (However, my guess is that in 40 years we will not be talking about mongo)

Re: Go Cry on Somebody Else's Shoulder: MongoDB is fine

#44

Post by wisty »

rdtsc wrote: post #40
wisty wrote: post #32

Earlier quoted context omitted.

Mongo people may say that's a good thing - if you aren't planning on dataloss, you are just begging for a disaster. And Mongo will force you to deal with recovery early on. That's no excuse for the DB being buggy, but some of Mongo's problems are due to hard design constraints - it's not so easy to make a DB that is fast and reliable, and easy to configure. Other's are due to it being immature. Some of it is concerni…

> if you aren't planning on dataloss, you are just begging for a disaster. General rule for picking products -- if a product, by design is supposed to teach you a lesson about backup strategies, don't use that product.

No, just that there's an upside to their risky design philosophy.

I like Mongo because of its documentation. It's really really great. And good documentation = widespread adoption, and a team who actually cares about user's needs. What they really need is a lengthy tutorial on backups (which they already have written), linked from every page in their documentation. Because their reliability not something they should be hiding.

Re: Go Cry on Somebody Else's Shoulder: MongoDB is fine

#45

Post by rdtsc »

wisty wrote: post #44
rdtsc wrote: post #40

Earlier quoted context omitted.

> if you aren't planning on dataloss, you are just begging for a disaster. General rule for picking products -- if a product, by design is supposed to teach you a lesson about backup strategies, don't use that product.

No, just that there's an upside to their risky design philosophy. I like Mongo because of its documentation. It's really really great. And good documentation = widespread adoption, and a team who actually cares about user's needs. What they really need is a lengthy tutorial on backups (which they already have written), linked from every page in their documentation. Because their reliability not something they should…

Sure there is an upside, nothing against, but the trade-off they made should have been advertised on their front page (before they fixed the defaults) in large bold flashing letters -- "you might lose your data if you use this product with default options". That is all.

Why? Because they are making a database not an rrd logger or in memory caching server.

> What they really need is a lengthy tutorial on backups.

As I put it the grandparent post, as a general rule, avoid products whose mission is by design to teach you backup discipline. That is all.

> a team who actually cares about user's needs.

You know what is a better way to care about users' needs? Not losing their data because of a bad design. We are not talking about generating a wrong color for a webpage or even exceptions that are thrown and server needing restart, we are talking about data being corrupted silently without users noticing. Guess what, even backups become useless. You have no idea your data is corrupted, so you keep backing up corrupted data.

Re: Go Cry on Somebody Else's Shoulder: MongoDB is fine

#46

Post by foolinator »

nullymcnull wrote: post #41
cperciva wrote: post #19

I hate to break it to the poster (and I would if they hadn’t chickened out and actually put their name on their post) but software has bugs. This is not a valid excuse. This is like running a red light, smashing into someone, and then telling them "hey, you should have looked before entering the intersection... you should know that people sometimes run red lights". Yes, you should have backups. No, that doesn't make…

The anon poster claimed to have deployed an early version of Mongo, at a "high profile" company with tens of millions of users, and yet seemed surprised by basic RTFM facts like 'must use getLastError after calls if you need to ensure your write was taken', even well into a production deploy. That should raise huge alarm bells for anyone who is considering taking the guy seriously. It's just not clear that there were…

I still can't find a company that processes millions of dollars that uses MongoDB without the help of real databases.

Re: Go Cry on Somebody Else's Shoulder: MongoDB is fine

#47

Post by Peaker »

Djehngo wrote: post #35
pilif wrote: post #4

In my opinion, there is but one feature that a database really must have: whatever data I write into it, if I don't delete it, I want to read it back - unaltered (preferably without needing at least three machines, but I'm willing to compromise) Software that cannot provide this single feature just isn't something I would call database. If it's unsafe default configurations or just bugs. I don't care. Between these t…

For what it's worth the original was a dumb hoax (as was heavily implied by the 10gen CTO's rebuttal comment) http://news.ycombinator.com/item?id=3205573

Another claim of authorship: http://news.ycombinator.com/item?id=3203169

More credible than nmongo.

Re: Go Cry on Somebody Else's Shoulder: MongoDB is fine

#48

Post by adabsurdo »

rdtsc wrote: post #38
adabsurdo wrote: post #37

Earlier quoted context omitted.

> preferably without needing at least three machines if you don't have such redundancy your data is not safe, no matter what database engine you are running.

I see where you are headed but that is bad logic. It is like saying your car may catch on fire anytime or a meteorite can strike so why bother also wearing a seat belt? Sorry you cannot possibly defend un-acknowledged writes as a default setting on a product that calls itself a database. Saying you need 3 machines anyway. By coming up with more arguments and excuses as a defense for this design you are actually makin…

i didn't mean to imply that. i do agree that your db client should check for write errors if you care about your data, and that mongodb should make their official drivers have safer defaults.

but the poster to which i was replying seemed to be saying that machine redundancy was somehow optional. it is not. hardware fails, and the architecture of whatever db server you are using is irrelevant when it does.

Re: Go Cry on Somebody Else's Shoulder: MongoDB is fine

#50

Post by ceejayoz »

foolinator wrote: post #46
nullymcnull wrote: post #41

Earlier quoted context omitted.

The anon poster claimed to have deployed an early version of Mongo, at a "high profile" company with tens of millions of users, and yet seemed surprised by basic RTFM facts like 'must use getLastError after calls if you need to ensure your write was taken', even well into a production deploy. That should raise huge alarm bells for anyone who is considering taking the guy seriously. It's just not clear that there were…

I still can't find a company that processes millions of dollars that uses MongoDB without the help of real databases.

Why would you? That's not what it's made for.

No one's doing nuclear physics simulations using JavaScript, but that doesn't make it useless for client-side validation.

Post reply on HN