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

181–190 of 331 posts

Re: Don't use MongoDB

#181

Post by nullymcnull »

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…

So, you've got direct engagement from the CTO above, and plenty of other commentary to consider here, but you dropped back in only to announce that "hey, all dissent falls into 2 convenient buckets, and here are my quick rebuttals to those strawmen"? Really?

If intellectual laziness like that is any indication, I doubt anyone is going to be reassured on your point #2. You've dropped a bomb on 10gen here, and done it anonymously to boot. You've got their people sifting through past issues on a Sunday, and for what? Because you fucked up a project by making poor choices, and probably took the well-deserved heat for it? Nevermind your categories. Man up and respond to these people directly, or don't respond at all.

Re: Don't use MongoDB

#182

Post by rdtsc »

christkv wrote: post #56
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…

It's good to see a voice of reason. I think we all win if NoSQL is allowed to survive. Having multiple paths to modeling and designing our applications is an enrichment of our ability to create interesting and valuable applications in our industry. The last 10 years have been about living under the modeling constraints of RDBMS's and the industry is slowly waking up to the realization that it does not need to be like…

> I think we all win if NoSQL is allowed to survive.

What does that even mean? Is it some sort of cultural practice or religion we are afraid of losing. So we should look over lost data and bad designs just because something falls under the "NoSQL" category?

I think anyone married to a technology like it is a religion is poised for failure. Technology should be evaluated as a tool. "Is this tool useful to me for this job?" Yes/No? Not "it has NoSQL in its title, it must be good, I'll use that".

Re: Don't use MongoDB

#183

Post by fdr »

zzzeek wrote: post #176
jvehent wrote: post #160

Earlier quoted context omitted.

That was 16 years ago. Since then, PostgreSQL engineers spent a LOT of time proving the reliability of their engine. And today, 16 years later, we can consider it reliable. Most key-value databases didn't prove (as in: show me actual resistance tests, not supercompany123 uses it) that they are reliable. The day they do, I'll be the first one to use them. Until then, it's just a toy for devs who don't want to deal wit…

you misunderstand me. I LOVE postgresql. It is the best database ever and I try to use it as much as possible. My only point was, they started out as unstable and untrustworthy just like anything else would.

I agree. There was no WAL logging, for instance. Most people consider 7.4 the first actually-possibly-not-a-terrible-idea release.

Then again, Postgres -- the project -- did not try to position itself (was there even such a thing as "positioning" for Postgres 16 years ago?) as a mature, stable project that one would credibly bet one's business on.

Lots of early database releases are going to be like Mongo, the question is how much the parties at play own up to the fact that their implementation is still immature and present that starkly real truth to their customers. So far, it seems commercial vendors are less likely to do that.

Re: Don't use MongoDB

#184

Post by stickfigure »

CarlHoerberg wrote: post #46
jonpaul wrote: post #30

I've used MongoDB in production since the 1.4 days. It should be noted that my apps are NOT write heavy. But, many of the author's points can be refuted by using version 2.0. Regarding the point of using getLastError(), the author is completely correct. But the problem is not so much that MongoDB isn't good, it's that developers start using it and expect it to behave like a relational DB. Start thinking in an asynchr…

Schema-less is imho a overrated feature. ORMs like DataMapper (Ruby) and NHibernate (.NET) can generate the schema on the fly for RMDBS, so no need for migrations pre-production. But when your application is in production you need migrations even with a "schema-less" db! See, rename a field and "all your data" is lost, unless you migrate the data from the old field to the new one..

See, rename a field and "all your data" is lost, unless you migrate the data from the old field to the new one

This is not true.

I wrote Objectify, a popular third-party java API to App Engine's datastore. The data migration primitives worked out building Objectify are what ScottH built into Morphia, the Java "ORM" system for MongoDB. With a small number of primitives (mostly @AlsoLoad and lifecycle callbacks) it's possible to make significant structure changes on-the-fly with zero downtime.

This is, IMHO, the best thing about schemaless datastores. There's no longer any compelling reason (at least, in the datastore) to take down a system for "scheduled maintenance".

For more information, here is the relevant section of Objectify's documentation:

http://code.google.com/p/objectify-appengine/wiki/Introducti...

Re: Don't use MongoDB

#185

Post by rfurlan »

I just recently published an article describing my experience migrating from SQL Server to MongoDB, you can read it here: http://news.ycombinator.com/item?id=3203601

I agree with the author that MongoDB is green, maybe not quite ready for prime time yet. All things considered, I realize we took a risk by switching and while I am quite happy with MongoDB, I do worry that at some point we will experience a failure condition we might not be able to recover from.

Re: Don't use MongoDB

#186

Post by jemfinch »

felix_krull wrote: post #89
mushishi wrote: post #81

Earlier quoted context omitted.

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…

this is the implementation of a b+ tree. the underlying logic has been very well researched since the 70s. if there is a part of mongodb that I am sure does not contain bugs, it is that very file you link to. if you want to know what it does, go out and read the relevant papers on data base technology. or graduate in CS.

Clearly you didn't actually read the source file. I graduated in CS. I know B+ trees.

I also know that an 85-line, 7-argument method in a 1988-line file shouldn't depend on a global variable ("guessIncreasing") modified from several other, unrelated functions. I know that in bt_insert, which (apparently) assigns to "guessIncreasing" and then resets it to false just prior to exit, should be using an RAII class to do so instead of trying to catch every exit path, especially in a codebase that uses exceptions.

This code is amateur hour.

Re: Don't use MongoDB

#187

Post by mushishi »

felix_krull wrote: post #89
mushishi wrote: post #81

Earlier quoted context omitted.

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…

this is the implementation of a b+ tree. the underlying logic has been very well researched since the 70s. if there is a part of mongodb that I am sure does not contain bugs, it is that very file you link to. if you want to know what it does, go out and read the relevant papers on data base technology. or graduate in CS.

Thanks for attacking me personally. But I have no interest to pursue it more. I made claims that clearly hold true, and they have nothing to do with what you said (I did not say anything about bugs, for example)

Re: Don't use MongoDB

#188

Post by hendler »

10gen might become a victim of it's own popularity. I have heard:

* Yes, playing with Mongo is playing with fire. Know what you are doing. We don't claim that you should use us as your only database.

* We're going to fix these issues soon. The beginning days of MySQL etc were also frightening, with Oracle and MS SQL Server admins warning of all the dangerous things that can happen.

If they confront their issues, I think it's just a matter of time before Mongo wins the NoSQL race. They have what matters most - good people, a brand, and great expectations from customers.

Re: Don't use MongoDB

#189

Post by willvarfar »

harryh wrote: post #162
fedd wrote: post #155

Earlier quoted context omitted.

have users of foursquare run into problems? were they serious? did someone lose money? let's ask. it would answer whether to use an eventually consistent db.

> 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?)

Re: Don't use MongoDB

#190

Post by willvarfar »

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.

facepalm. Indices on disk is a solved problem.
Post reply on HN