Live data from Hacker News

Goodbye, MongoDB

zopyx.de

71–80 of 123 posts

Re: Goodbye, MongoDB

#71

> 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 (sysc…

This is why most DBMS products do their own memory management. They just suck up as much memory as you will allow and use it for their own devices. Specialized, tunable, application-level memory management will probably always beat a general-purpose, application-ignorant OS-based scheme.

But, there's something to be said for the simplicity - for most folks you don't need to manage the memory yourself. When you need it though, there's really no easy substitute.

Re: Goodbye, MongoDB

#72
My Xen VM crashed several times by day during several weeks. And, this problem disappears when I removed my mongodb database...

Re: Goodbye, MongoDB

#73
post #62

Earlier quoted context omitted.

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?

As a former Aol employee, I know of a large support contract between them and 10gen. I think a lot of money comes from large companies who have teams that want to use MongoDB, and the large company buys a huge support contract for that team and any other possible team who wants to use it. Maybe that was just Aol, but I'm guess that pattern is that same in other large tech companies too.

Re: Goodbye, MongoDB

#74
using JSON as a query language was a bad decision. The current JSON query language works for standard queries but the functionality of the operators is limited.

These two things don't go hand in hand. JSON could be used to elegantly represent complex queries. A problem with the query system isn't necessarily a problem with JSON.

Re: Goodbye, MongoDB

#75
post #5

Wow, how many "Goodbye, MongoDB" stories are coming? The last days had several ones. Not sure if this is already a trend?

IIRC We've had several "Goodbye CouchDB" articles in the past few weeks too. What's the under/over on the inevitable "Goodbye Riak" wave?

Perhaps soon, but one thing that has always struck me about Basho (and maybe why Riak isn't as well-known as the other NoSQL DBs) is that they don't have a huge hype machine. They've always been more interested in fixing the problems with their DB and cultivating a community that understands the benefits/detriments of their database than blasting out "HEY EVERY1 SHOULD USE RIAK!!!" everywhere. Their site is very specific about what Riak is good at and what it's bad at.

I've seen many mailing list responses to questions about Riak saying "maybe Riak isn't the best fit for this, try looking at X..." whereas 10gen wants everybody to use MongoDB for everything.

It just seems to be a more honest operation, and people don't get burned as much.

Re: Goodbye, MongoDB

#76

I keep reading about how mongo's use of memory mapped files is real bad. Isn't that the same technique used by varnish cache and that's what makes it awesome? Can someone explain please?

Varnish has a much simpler access pattern (which happens to fit the page-cache semantics like a glove in almost all use-cases) and was developed by a drastically more competent team.

Comparing varnish to mongodb is akin to comparing a precision Rolex from Swiss to a plastic mickey mouse watch from a gumball machine.

Re: Goodbye, MongoDB

#77

Actually, using mmap-ed files is a great idea. It's precisely what Varnish does too.

That was exactly what my thoughts were too: letting the OS do all the memory management, caching, is a strategy many great projects use, among which PostgreSQL and Varnish. However, I do feel there is something "wrong" about the approach MongoDB is taking. They need to allocate new files in huge buffers, which completely take up all I/O while being filled with zeroes. There is no logical hierarchy in the files, and i…

Thanks for the insight on the global write lock. I've searched and searched and wasn't able to find anything on why they have the global lock.

Out of curiosity, is there a simple way to explain why someone would mmap instead of just reading files directly (I've never done any programming with mmap, so I'm a bit ignorant of its use cases)?

Re: Goodbye, MongoDB

#78
post #53

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.

All developers need to understand the Gartner hype cycle.

Re: Goodbye, MongoDB

#79

> 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 (sysc…

This is why most DBMS products do their own memory management. They just suck up as much memory as you will allow and use it for their own devices. Specialized, tunable, application-level memory management will probably always beat a general-purpose, application-ignorant OS-based scheme. But, there's something to be said for the simplicity - for most folks you don't need to manage the memory yourself. When you need i…

> But, there's something to be said for the simplicity - for most folks you don't need to manage the memory yourself.

Yes, and most people don't need to implement printf() themselves, which is why there is libc. Just because you're doing it in-process, in user space, doesn't mean you're rolling your own!

Re: Goodbye, MongoDB

#80
post #53

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.

I fully agree here. A couple of years ago, when I went on interviews at startups, they were all using nosql db's and were proud of it. More recently, I've been interviewing at startups that are now bigger, need to mine the data that they've collected over the last few years, and now are migrating off of nosql db's to rdbms' (or creating strange amalgams of the 2). I did see this coming, but it was very hard to make them understand back when it was the coolest thing.
Post reply on HN