Go Cry on Somebody Else's Shoulder: MongoDB is fine • Hacker News Board

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

#51

Post by cmer » Mon, Nov 07, 2011, 3:57 PM UTC

eropple wrote: post #12

cmer wrote: post #9

Mongo is fine until it's not. It's been fine for us for many months, but once you hit its limitations, it's pretty horrible. We're in this situation right now and we're seriously considering moving back to MySQL or Postgres. Basically, "it doesn't scale" unless you throw tons of machines/shards at it. Once they fix a few of their main issues such as the global write lock and fix many of the bugs, it could become an o…

Have you considered Riak? (I ask mostly because I've been looking at both, having a little MongoDB experience but having heard great things about Riak.)

Riak is definitely an option I'll consider, but experience has taught me one thing: most of the time it's better to stay with the most mainstream tools, such as MySQL, even if that means not using the absolute best tool. As long as it gets the job done and is "good enough".

There are better options than MySQL out there (such as Postgres and Riak probably), but when shit hits the fan in production and you need to quickly bring your servers back up, you'll be happy you chose a tool that has a lot of outstanding consultants and immense amounts of documentation. Finding help for MySQL is very easy. Help for Riak or even Postgres is much more scarse. Also, MySQL is very likely to still be around in a few years. We can't say the same for most of the new NoSQL stuff.

I tried to stay true to this as much as possible in the past and it served me well. I made this mistake with MongoDB, however.

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

#52

Post by randomdata » Mon, Nov 07, 2011, 4:33 PM UTC

tomlin wrote: post #49

sqrt17 wrote: post #20

New slogan: "MongoDB. Better than JSON file blobs on an NFS store."

JSON file blobs don't require any configuration on my part, so IMHO, JSON is better than MongoDB.

Unless you only need single key indexes, your custom made indexer/querier is going to require a lot of configuration. If you only need single key indexes, you wouldn't choose MongoDB anyway.

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

#53

Post by eropple » Mon, Nov 07, 2011, 4:51 PM UTC

cmer wrote: post #51

eropple wrote: post #12

Earlier quoted context omitted.

Have you considered Riak? (I ask mostly because I've been looking at both, having a little MongoDB experience but having heard great things about Riak.)

Riak is definitely an option I'll consider, but experience has taught me one thing: most of the time it's better to stay with the most mainstream tools, such as MySQL, even if that means not using the absolute best tool. As long as it gets the job done and is "good enough". There are better options than MySQL out there (such as Postgres and Riak probably), but when shit hits the fan in production and you need to quic…

That's fair. Riak seems interesting to me more from an almost academic perspective; as I said, I haven't used it. My go-to are MySQL and Postgres, too (though I use Redis a decent bit as a communication pipeline).

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

#54

Post by sk5t » Mon, Nov 07, 2011, 5:40 PM UTC

wisty wrote: post #32

Joeri wrote: post #18

Earlier quoted context omitted.

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.

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're suggesting that "traditional" databases operate without thinking about OS cache, unbuffered IO when called-for, memmap, etc., I strongly believe you're way off.