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

Don't use MongoDB

pastebin.com

Post reply on HN
Print view View original

191–200 of 331 posts

Re: Don't use MongoDB

#191

Post by pnathan »

mushishi wrote: post #81
itaborai83 wrote: post #59

Earlier quoted context omitted.

I'm curious and I might be missing more than half of my brain. Would you be willing to show some examples of bad coding on their source tree?

I haven't ever used MongoDB but got interested, and first non-trivial source file I picked is this: https://github.com/mongodb/mongo/blob/master/db/btree.cpp Take a look at for example: bool BtreeBucket ::find Without even thinking about what it is doing, it's quite clear that it is not readable code, and it's not immediately obvious what the high level structure of the logic is. The function does not even fit into t…

That is characteristic of mathematical code, like btree. (ranty aside: being able to recognize this and find out information regarding btree for maintenance is(should be) one of the key reasons to get a CS degree)

I found the btree file relatively readable. Some macro stuff is not familiar to me, but I am sure I could figure it out in a few hours if I felt like. And I haven't yet rolled around to implementing a full-on btree, ever.

Re: Don't use MongoDB

#192

Post by rdtsc »

antirez wrote: post #26

I appreciate the "public service" intend of this blog post, however: 1) It is wrong to evaluate a system for bugs now fixed (but you can evaluate a software development process this way, however it is not the same as MongoDB itself, since the latter got fixed). 2) A few of the problems claimed are hard to verify, like subsystems crashing, but users can verify or deny this just looking at the mailing list if MongoDB h…

> IMHO it is a good idea if programmers learn to test very well the systems they are going to use ...

Great point. It would also help if the company that makes a DB would put flashing banner on their page to explain the trade-offs in their product. Such as "we don't have single server durability built in as a default".

I understand if they are selling dietary supplements and are touting how users will acquire magic properties for trying the product for 5 easy payments of $29.99. In other words I expect shady bogus claims there. But these people are marketing software, not to end users, but to other developers. A little honesty, won't hurt. It is not bad that they had durability turned off. It is just a choice, and it is fine. What is not fine is not making that clear on the front page.

Re: Don't use MongoDB

#193

Post by tptacek »

einhverfr wrote: post #98
mechanical_fish wrote: post #75

Earlier quoted context omitted.

I assure you that, back when MySQL was the same age as Mongo is today, "don't use MySQL" was conventional wisdom... among those who could find and afford Oracle DBAs. ;) (Though there weren't a lot of blog posts about it, because the word blog had not been invented yet; blogs developed along with... MySQL.) It will be interesting to watch Mongo as it matures over the next ten years. Unlike MySQL, it is competing agai…

"Don't Use MySQL" still should be conventional wisdom. Indeed it's the only database system I have ever used where a system with a single transaction running only multi-row inserts into a table can (and frequently does) deadlock against itself. Don't get me wrong, time was when it was easier to use than PostgreSQL but that time is long since passed. One area I have continued to recommend MySQL has been in areas of co…

Given the size and success of MySQL deployments, it's getting awfully hard to evangelize that particular religion. I prefer Postgres, but life is too short to argue about it.

Re: Don't use MongoDB

#194

Post by harryh »

willvarfar wrote: post #189
harryh wrote: post #162

Earlier quoted context omitted.

> have users of foursquare run into problems? Of course we've run into problems from time to time. No one goes from nothing to foursquare's level of success without running into some bumps along the way. > were they serious? did someone lose money? No. > it would answer whether to use an eventually consistent db MongoDB actually isn't really an eventually consistent datastore. It doesn't (for example) allow writes to…

http://blog.foursquare.com/2010/10/05/so-that-was-a-bummer/ You had 11 hours downtime and didn't lose money? What about opportunity cost? Reputation? Now you have to share your secret :) (I guess, if you weren't profitable, you had nothing to lose?)

The 11 hours of downtime was a pretty big deal, but it had very little to do with MongoDB. It was basically a huge failure in proper monitoring.

Re: Don't use MongoDB

#195

Post by newman314 »

ehwizard wrote: post #138

From CTO of 10gen First, I tried to find any client of ours with a track record like this and have been unsuccessful. I personally have looked at every single customer case that’s every come in (there are about 1600 of them) and cannot match this story to any of them. I am confused as to the origin here, so answers cannot be complete in some cases. Some comments below, but the most important thing I wanted to say is…

Given the response, what are some best practices/gotchas for MongoDB then?

It might be helpful for 10gen to put together a short doc on what to watch out for evaluators.

Re: Don't use MongoDB

#196

Post by openmosix »

wickedchicken wrote: post #21
openmosix wrote: post #13

Well, I worked in Vodafone (and Nokia) in very large (laaarge) projects, serving ~50 milions users. Years ago, no hope for NoSQL, we used MySQL. We hit at least 10/20 bugs, solved by 'hotpatch' from Sun. So? I think as developers we should get used to bugs and patches. Should I write a post "don't use MySQL?". We also hit several bugs in the generational garbage collector. Stop using Java? I don't feel the drama here…

> Should I write a post "don't use MySQL?". yes > Stop using Java? yes Tongue-in-cheek aside, the author's point is that regardless of its current status, MongoDB has been pushed on a lot of people hungry for performance/simplicity; in that singular pursuit they may be setting themselves up for disaster later on. Most developers have a (perhaps unspoken) assumption that a successful write to a database means that dat…

Then I think it is way easier to write a post "Do not use technology, go back to the cave". Any technology has chances to fail, can be SQL, Cloud, yadda yadda. And if you want to work on the 'edge' (innovating to disrupt your competitors), that's a risk you should accept. Blaming the tools you use to achieve that point is childish.

Re: Don't use MongoDB

#197

Post by shuzchen »

newman314 wrote: post #195
ehwizard wrote: post #138

From CTO of 10gen First, I tried to find any client of ours with a track record like this and have been unsuccessful. I personally have looked at every single customer case that’s every come in (there are about 1600 of them) and cannot match this story to any of them. I am confused as to the origin here, so answers cannot be complete in some cases. Some comments below, but the most important thing I wanted to say is…

Given the response, what are some best practices/gotchas for MongoDB then? It might be helpful for 10gen to put together a short doc on what to watch out for evaluators.

Most of the best practices/gotchas can be found by reading the online documentation. Of all the replies Eliot gives they were either plainly obvious (oh, you have a system under heavy load and you're surprised that it gets worse when you give it another task to do?) or mentioned in the documentation. If you're planning on using something - especially for a production system - I sure hope you at least read all the available documentation.

I don't think a short doc is of any help for evaluators. You shouldn't be basing your decision on 400 words and some bullet points. If you're serious about your datastore then you should treat it seriously.

Re: Don't use MongoDB

#198

Post by obfuscate »

j_baker wrote: post #161
moe wrote: post #129

Earlier quoted context omitted.

I don't think that counts as an argument. When you strip MongoDB down to the parts that actually have a chance of working under load then you end up pretty close to a slow and unreliable version of redis. Namely, Mongo demonstrably slows to a crawl when your working-set exceeds your available RAM. Thus both redis and mongo are to be considered in-memory databases whereas one of them is honest about it and the other n…

If I recall correctly, mongo only requires that the index gets stored in memory. The actual data itself can go on disk.

It requires neither.

Re: Don't use MongoDB

#199

Post by [deleted] »

nomoremongo wrote: post #169
nomoremongo wrote: post #154

Pastebin author here. Refutations are going to fall into two categories, it seems: 1. Questioning my honesty 2. Questioning my competence Re #1, I'm not sure what you imagine my incentive to lie might be. I honestly just intended this to benefit the community, nothing more. I'm genuinely troubled that it might cause some problems for 10gen, b/c, again, Eliot & co are nice people. Re #2, all I can do is attempt to rea…

Some are also (fairly) questioning "why the anonymity?", and "where is the evidence?" Those two things are connected: I can't provide the evidence without revealing identity. And the reason for the anonymity is we still have some small databases with 10gen and a current support contract. I had intended to go public with all this after we had transitioned off the system entirely, but more and more reports have continu…

[deleted]

Re: Don't use MongoDB

#200

Post by [deleted] »

nomoremongo wrote: post #169
nomoremongo wrote: post #154

Pastebin author here. Refutations are going to fall into two categories, it seems: 1. Questioning my honesty 2. Questioning my competence Re #1, I'm not sure what you imagine my incentive to lie might be. I honestly just intended this to benefit the community, nothing more. I'm genuinely troubled that it might cause some problems for 10gen, b/c, again, Eliot & co are nice people. Re #2, all I can do is attempt to rea…

Some are also (fairly) questioning "why the anonymity?", and "where is the evidence?" Those two things are connected: I can't provide the evidence without revealing identity. And the reason for the anonymity is we still have some small databases with 10gen and a current support contract. I had intended to go public with all this after we had transitioned off the system entirely, but more and more reports have continu…

[deleted]
Post reply on HN