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

Goodbye, MongoDB

zopyx.de

Post reply on HN
Print view View original

61–70 of 123 posts

Re: Goodbye, MongoDB

#61

Post by bunderbunder »

dlokshin wrote: post #51

I feel like 1 - 2 years ago I was reading a slew of blog posts with the title "Why We Chose MongoDB." Now it seems like all of the blog posts are some sort of "We Just Finished Migrating off of MongoDB, Here's Why." I know nothing about MongoDB and have never tried it. But the message seems pretty clear.

It's just the standard Internet hype cycle.

I'm guessing within the next year we're going to see a similar backlash against Hadoop as people who rush to it begin to discover that map/reduce isn't necessarily the best distributed processing model for their needs. This despite Hadoop continuing to be the effective (non-silver) bullet it's always been.

Re: Goodbye, MongoDB

#62

Post by bsg75 »

zacharyvoase wrote: post #12
kennystone wrote: post #9

Earlier quoted context omitted.

The trend is this: any loved technology that's been around a little while (Rails, Node, Mongo, etc) makes for dramatic farewells on hackernews. It's not unlike supermarket tabloids.

I disagree. The trend is this: any hype has an equal and opposite anti-hype. 10gen have spent (probably) millions of dollars and countless hours representing MongoDB and singing its praises in various media (conferences, user groups, Web, etc.). If you do so, you need to expect equally fierce reactions when people realise your claims are unsubstantiated (or, at the very least, not as universal and problem-free as you…

I wonder where all those millions come from? All venture capital, or is 10gen gaining paying customers?

Re: Goodbye, MongoDB

#64

Post by haberman »

> Leaving memory management to the operating is nice idea - in reality it does not scale and does not play very well.

This is why I think that Linus's tirade against O_DIRECT is misguided: https://lkml.org/lkml/2007/1/10/233

Here's the thing: the kernel is a library. It took me a long time to fully understand this deep idea. The kernel is just a library that has a different and more expensive calling convention (syscalls) and runs at a higher privilege level.

It's also much less flexible than user-space libraries. Its interface is an unholy mix of syscalls, ioctl(), /proc, vdso, etc. There is a high bar to adding new interfaces. Removing or changing existing interfaces is basically not allowed.

The resources that the kernel uses are much harder to account for or predict. How can you ensure that a process always gets at least X MB of page cache, and that some enormous "cp" that some sysadmin is running won't evict all your MongoDB pages that are caching your database? Sure you could mlock() your pages, but now you're basically side-stepping all of this smart kernel cache management that was supposed to be helping you so much in the first place.

User-space management of buffers and caches is more flexible, easier to account to its owner, and more predictable. It can't handle page faults with Linux's current interfaces, but the L4 guys have figured out how to let pagers run in user-space and handle page faults. I hope that someday this work becomes mainstream. Our 20-year-old OS design is showing its age.

Re: Goodbye, MongoDB

#65

Post by gfodor »

bunderbunder wrote: post #61
dlokshin wrote: post #51

I feel like 1 - 2 years ago I was reading a slew of blog posts with the title "Why We Chose MongoDB." Now it seems like all of the blog posts are some sort of "We Just Finished Migrating off of MongoDB, Here's Why." I know nothing about MongoDB and have never tried it. But the message seems pretty clear.

It's just the standard Internet hype cycle. I'm guessing within the next year we're going to see a similar backlash against Hadoop as people who rush to it begin to discover that map/reduce isn't necessarily the best distributed processing model for their needs. This despite Hadoop continuing to be the effective (non-silver) bullet it's always been.

Meh, Hadoop is much older than MongoDB, is an offline system, and doesn't destroy your data. There is also not much in the way of alternatives. I'm skeptical we will see many "we're switching off of Hadoop" posts anytime soon. That said, there is an growing undercurrent in the Clojure community to roll your own map reduce system instead of using Hadoop.

Re: Goodbye, MongoDB

#66

Post by mark_l_watson »

It seems like ranters against MongoDB often don't really understand how it works and thus what it is good for.

My simple mental model for MongoDB is: indices (should!) fit in memory and documents are stored contiguously on disk. That is it in a nutshell. A query involves in-memory lookups and maybe only one disk seek. Writes in place are usually possible.

I have been happiest with MongoDB in two different scenarios:

The first is in developing small web applications where there is no scaling issue, and the fact is that MongoDB is so easy to develop against and simply provides a great developer experience. As needed, I use a cron job to do a mongodump a few times a day; or, if I really need high availability (which, frankly, often I don't: if a system is unavailable one or twice a year for an hour it is no big deal) then replica sets are OK.

The second scenario where I have really liked using MongoDB was doing analytics on a modestly large stream of social media data. A single Mongo master on a large EC2 instance was adequate to handle writes and slaves on other large EC2 instances each fed a different analytics application. This setup of apps reading from a slave on the same server worked really well for me. This was a low hassle experience.

I do have one customer with really large MongoDB setups on multiple data centers, and I am working around right now on some hassles, but we haven't found anything else as cost effective for the customer's applications.

All that said, when I can use it, just using a single (no horizontal scaling) PostgreSQL server is for me the most hassle free developer experience, but I have always used PostgreSQL for small or medium sized applications - nothing that needed to scale.

Re: Goodbye, MongoDB

#67

Post by orthecreedence »

triathlete wrote: post #54

Its unfortunate that right now none of the 3 major document stores seem to be doing all that well or are easy to use straight out of the box. I use and like mongodb but only for prototyping. I havent decided what to go with longer term if my projects have a need. Couchdb is interesting but seems to be going through some serious growing pains right now with the couchbase product being very confusing to figure out and…

I've done a lot of research and testing with Riak (not had the pleasure of using it in production yet), and although some of the things that are easy in other DBs are backwards (like listing all records, for instance), I have a secret love affair with it. MongoDB claims to have simple scalability, but I've worked with it on a large project at Aol and found this to not be true at all. We basically had to implement our own sharding on top of it since its auto-sharding was so poor, and only needed to shard in the first place because of the global write lock. Riak, on the other hand, is an operations dream, and if you're a dev and ops guy in one (like me) I stay up at night thinking about using it for every project.

That said, a lot of people have started to use Riak for a general purpose tool. There are some development growing pains associated with this (and you have to think very carefully about your keys and data structure) but it's only getting easier with things like secondary indexes and Riak search. If there was a non-expensive way to enumerate all the data in a bucket, I think that'd be the one last item on the checklist before I jumped on it.

Re: Goodbye, MongoDB

#68

Post by nchuhoai »

ax wrote: post #53
dlokshin wrote: post #51

I feel like 1 - 2 years ago I was reading a slew of blog posts with the title "Why We Chose MongoDB." Now it seems like all of the blog posts are some sort of "We Just Finished Migrating off of MongoDB, Here's Why." I know nothing about MongoDB and have never tried it. But the message seems pretty clear.

The message is, just like every technology, there's an initial period where a vocal minority loves it and tries to use it for everything. Then, there's a backlash where a vocal minority hates it and thinks anyone who uses it is clearly an idiot. All the while, the silent majority go on getting work done. It's been this way for as long as I can remember.

Love it. I think Node is the hot shit right now, and Rails is starting to get into the hate-period.

It's really just hipsters and music. We are all really just hipsters.

Re: Goodbye, MongoDB

#69

Post by salimmadjd »

Blame yourself before blaming MongoDB. If you've been around the software industry you should always be mindful of fads and vaporwares. When you make a decision to use MongoDB you better have done your homework first or do some testing yourself. Given the low cost of renting bunch of EC2 machines for a few hours, it's idiotic to build a business around MongoDB or any other system that has not been fully proven without doing bunch of stress testing yourself. Yes, and don't trust software vendors, get independent advice or test it yourself.

Re: Goodbye, MongoDB

#70

Post by orthecreedence »

paulsutter wrote: post #27
hmans wrote: post #2

tl;dr We LOVED MongoDB ( http://www.zopyx.de/blog/plone-using-highcharts-and-jqgrid ) but we got burnt so it's USELESS and BRAINDEAD!

That's the common pattern. MongoDB is easy and convenient when you first start using it, but you hit the limitations pretty quickly. I had the same experience.

I really think if they had document-level locking, it would be a much more successful DB. 10gen's answer to this is "just shard!!1" except that sharding in Mongo really isn't as easy as they make it out to be...not to mention what database makes you shard just so you can support more than a few hundred writes per second? Maybe this has improved a bunch since I got burned by it on v1.6, but I believe it's very misleading to claim scalability of a product that has a global write lock. Being forced to shard when you reach the small-medium size is just sad.

All other aspects about it I love, though. It really makes development and deployment so much faster. Replica sets aren't perfect, but setting up MySQL replication w/ automatic failover on three or more machines is a recipe for disaster unless you have a DBA to sit there and baby sit it full-time.

Post reply on HN