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

161–170 of 331 posts

Re: Don't use MongoDB

#161

Post by j_baker »

moe wrote: post #129
WayneDB wrote: post #119

Earlier quoted context omitted.

I agree with your responses to 1 and 2. I take issue with the example for 3 though because Redis is nowhere near the complexity or feature set of MongoDB.

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.

Re: Don't use MongoDB

#162

Post by harryh »

fedd wrote: post #155
harryh wrote: post #141

Hi, I run engineering for foursquare. About a year and a half ago my colleagues and I and made the decision to migrate to MongoDB for our primary data store. Currently we have dozens of MongoDB instances across several different data clusters storing over a TB of data and handling 10s of thousands of requests per second (mostly reads but the write load is reasonably high as well). Have we run into problems with Mongo…

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 multiple nodes across a network partition and then have a mechanism for resolving conflicts.

Re: Don't use MongoDB

#163

Post by ajsharp »

jvehent wrote: post #123
antirez wrote: post #39

Earlier quoted context omitted.

I agree with you but my comments are more about telling what is going on in my opinion, instead of telling what I think should be the right priority list. Even if I agree I still recognize that MySQL had a much bigger effect to the database world compared to PostgreSQL, so the success of a database can sometimes take strange paths. But I think a major difference between MySQL and Redis, MongoDB, Cassandra, and all th…

> MySQL had a much bigger effect to the database world compared to PostgreSQL And if MySQL never existed, what would have happened ? Would we have all used PostgreSQL in the first place and avoided years of painful instability ? I read here all the time that fashion and ease of use are more attractive than reliability. And we introduce plenty of new software in complex architecture just because they are easy to use.…

> And if MySQL never existed, what would have happened ? Would we have all used PostgreSQL in the first place and avoided years of painful instability ?

I think you're missing the point a little. Yes, MySQL is a heap, and having to work with it in a Postgres world sucks. But, the point antirez is making in that comment (at least how I read into it) is that an active user community in ANY project is hugely important in that project's formation and "maturity" (sarcastically, of course, because Postgres is clearly more mature than MySQL). There's no extrapolation here to the top-level Mongo discussion going on in this thread -- I was just clarifying antirez's point.

Re: Don't use MongoDB

#164

Post by itaborai83 »

maxogden wrote: post #128
itaborai83 wrote: post #125

Earlier quoted context omitted.

One of the things that I love about Couch is that the standard way to shutdown the process is simply doing a kill -9 on the server process. No data loss. No Worries. Want to back up your data? rsync it and be done with it. Couch may have its warts, but it is damn reliable.

I've heard from many people that with Couch you get "all of your disappointment up front"

I feel that Couch has too much server side programming. It can be off puting sometimes. If anyone wants to make some money, I'd suggest them putting a server on top of a couch cluster that receives mongo queries.

I mean, how hard can it be to

1) Manage some indexes,

2) Keep some metadata around and

3) Build some half-assed single index query planner?

Couch is already a solid piece of technology. It just needs a better API to "sit" on top of it, kinda like what Membase is doing now.

edit: or on top of Riak, Cassandra, PostgreSQL or etc ... on the API side, Mongo has clearly won.

Re: Don't use MongoDB

#165

Post by ajsharp »

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

> But when your application is in production you need migrations even with a "schema-less" db!

I disagree. The most frequent use-case I come across is adding columns / fields to a table / collection, and not needing to ALTER TABLE and run a database migration as part of the deployment process to add said fields is extremely awesome.

Re: Don't use MongoDB

#167

Post by pbiggar »

bbulkow wrote: post #157

Disclosure: I wrote a product called Citrusleaf, which also plays in the NoSQL space. My focus in starting Citruseaf wasn't features, it was operational dependability. I had worked at companies who had to take their system offline when they had the greatest exposure - like getting massive load from the Yahoo front page (back in the day). Citrusleaf focuses on monitoring, integration with monitoring software, operatio…

Looks interesting. May I suggest you provide a hosted service? With mongo, I tried it online and got a feel for it before we signed up, and there are multiple hosted services so I didn't have to worry about setting it up in the cloud. Looking at citrusleaf.com, though the blurb sounds like I might like it, nothing else really helps me. It's NoSQL, but that doesn't say anything. I know that memcache has a use case, and I know mongo's use case, and redis', but I don't see yours.

(PS I know you're enterprise software, but still).

Re: Don't use MongoDB

#168

Post by gsharm »

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…

Where do you finally persist the data in that case?

Re: Don't use MongoDB

#169

Post by nomoremongo »

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 continued to pop up of people having trouble with MongoDB, and it seemed as though delaying would be imprudent. An anonymous warning would be more valuable than saying nothing.

So--if you choose to ignore or dismiss our claims, you're entitled. :-) I still feel satisfied that I did what I needed to do.

Re: Don't use MongoDB

#170

Post by nikcub »

vannevar wrote: post #118
nikcub wrote: post #57

Links about Foursquare's problems with MongoDB. The site was down for a while when their 1.6 instance crashed: * http://blog.foursquare.com/2010/10/05/so-that-was-a-bummer/ * http://www.infoq.com/news/2010/10/4square_mongodb_outage * http://groups.google.com/group/mongodb-user/browse_thread/th... I like MongoDB, it is easy to setup, work with and to understand. I think it has an opportunity to become the mysql of nos…

It should be noted that this was not really a problem with MongoDB. Foursquare used a poorly-chosen shard key that caused a disproportionate load on one of its shards, and on top of that did not have proper system monitoring in place to alert them that a server was running out of RAM. It should also be noted that no data was lost in the process of resolving the problem.

I thought both Foursquare and 10gen handled the situation then very well, especially considering how much traction the story got (it had all the elements - a popular service, a popular new database, etc.)

I was sort of suggesting that this anonymous post may have come from somebody at Foursquare, since what is described kinda matches what happen there. The 'politics' element could also match because of the common investor - but I see that both 10gen and 4sq have responded here saying that they do not know who wrote this - which I believe.

Post reply on HN