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

The genius and folly of MongoDB

nyeggen.com

Post reply on HN
Print view View original

101–110 of 280 posts

Re: The genius and folly of MongoDB

#101

Post by pg »

byroot wrote: post #100
nostrademons wrote: post #46

Earlier quoted context omitted.

What's wrong with the Viaweb/Arc/HackerNews/Mailinator approach of just using in-memory datastructures (hashtables, linked lists) and then journaling out changes to the filesystem as records that are read in on startup? It's incredibly simple and blindingly fast as long as you stay on one server, and you can get several thousand QPS of capacity on that one server (vs. like 10 with a Django/Rails + SQL database soluti…

> What's wrong with the Viaweb/Arc/HackerNews/Mailinator approach of just using in-memory datastructures https://news.ycombinator.com/x?fnid=cjVXpi8HxVR5TTze3bqSCa Unknown or expired link. Oh I remember now...

That's caused by using closures to create dynamically generated "callbacks" on the server, not keeping data structures in RAM. If you ask for some old item not in memory, it just gets lazily loaded.

Re: The genius and folly of MongoDB

#102

Post by threeseed »

rsynnott wrote: post #55
mattdeboard wrote: post #11

Earlier quoted context omitted.

I think the genius referred to is in its simplicity. This simplicity let MongoDB get a product to market very quickly, as well as the inherent goodness of making simple things. I think in MongoDB's case, the getting-to-market part pushed a little too hard on the make-it-simply part. Simple is good but a thing should be as simple as possible, no less.

Its apparent simplicity to _developers_ was certainly a good marketing tool, but it did come with tradeoffs; some of its limitations imply a considerable amount of developer and operational complexity if you actually want to use it.

It wasn't a good marketing tool. It was the truth.

MongoDB IS by every measure a very simple and easy to use database.

Re: The genius and folly of MongoDB

#103

Post by joevandyk »

yummyfajitas wrote: post #56
nawitus wrote: post #31

So, what's a good NoSQL database for e.g. node.js use? The only alternative I know of is CouchDB. (Yes, I should give more parameters about the intended use, but I really don't know any alternatives).

One viable option: CREATE TABLE mongodb ( key VARCHAR(256) PRIMARY KEY, value JSON );

I'd use a uuid for the key.

Also, see https://github.com/umitanuki/mongres

Postgresql speaking the mongodb protocol.

Re: The genius and folly of MongoDB

#104

Post by digitailor »

rsynnott wrote: post #52
rogerb wrote: post #33

Earlier quoted context omitted.

Sorry, but the global write lock has been public knowledge since the very early days. Mongo's done nothing to hide that. Also (i worked for 10gen at the time) the "marketing department" that you refer to, was a single person organizing events to give developers what they wanted: knowledge and a community around mongodb.

I think it's really less that 10gen itself was trying to mislead people, and more that the community itself was building up a strange mythos with little relation to reality. This, unfortunately, tends to happen rather often (node.js is magic! Java is really slow! etc.)

That's what made me drop research into NoSQL a couple of years ago- the overly optimistic and magical thinking seemed to be really pervasive. I don't want to get burned from joining in a group delusion. (I'm not trying to say that's what's going on specifically in Mongo or anything else, just acknowledging that the mythos phenomenon mentioned above can repel me.) Since you've coined the term, are there any NoSQL projects you've seen that don't suffer from the mythos issue?

Re: The genius and folly of MongoDB

#105

Post by yxhuvud »

AlisdairO wrote: post #72
twic wrote: post #58

Earlier quoted context omitted.

No check constraints. Spotty transaction isolation. Silent data corruption if you happen to make certain kinds of updates while using statement-based replication. No on-line schema updates (is that still true?). Complete inability to execute joins of any size in reasonable time due to the lack of merge or hash join strategies. Corresponding inability to handle subqueries of any complexity. Readers block writers (at t…

I believe that InnoDB is an MVCC implementation, so readers blocking writes shouldn't happen. Another thing to add to your list is missing window functions. I'm not a big MySQL fan at all, but it's still leaps and bounds ahead of mongo technologically.

Readers blocking writes may have been changed in a never version than what we use, but it still exist in at least some versions of 5.x.

Re: The genius and folly of MongoDB

#106

Post by rdtsc »

The problem with MongoDB is their shadiness. The shipped with unacknowledged writes up until not too long ago. In other words you would write to it and there wouldn't be an ok or fail response, you'd just sort of hoped it would go in.

They fixed that problem but it was too late. In my eyes they proved they are not to be trusted with data.

Had they called themselves MangoCache or MongoProbabilisticStorage, fine, can silently drop writes, I don't care it is not database. But telling people they are a "database" and then tweaking their default to look good in stupid little benchmarks, and telling people they are webscale, sealed the deal for me. Never looking at that product again.

Re: The genius and folly of MongoDB

#107

Post by Lazare »

nawitus wrote: post #31

So, what's a good NoSQL database for e.g. node.js use? The only alternative I know of is CouchDB. (Yes, I should give more parameters about the intended use, but I really don't know any alternatives).

Well, the obvious answer to your question is: CouchDB! It's a brilliant, underrated database, and hey, it backs NPM!

On the other hand, Redis, Cassandra, Riak, and many more are also excellent NoSQL databases. But none of them, including CouchDB, are excellent at everything. What are you planning on making? You can write a lot of different things in node.js. If you're writing, say, a blogging engine you probably should look into flat files, or maybe Postgres, and forget the NoSQL kool-aid. :)

Re: The genius and folly of MongoDB

#108

Post by spamizbad »

danpalmer wrote: post #87
bkanber wrote: post #84

I posted this further down the thread, but I thought I'd share my thoughts on why I like mongo. Most people don't like mongo because 10gen gives the impression that mongo is better than it actually is, many people feel that mongo is not reliable enough for at-scale applications. They're right; it's not. But that's ok, because: Mongo's really great for rapid prototyping. You don't need to worry about updating the sche…

The case for using it as a prototyping database is the best use-case I've seen for Mongo, however I'm not sure it's always a good idea. For a hack-weekend sort of project, fine, but if you are in any way attempting to make a product, it strikes me as the sort of thing that would be really difficult to change later down the line, and so worth investing the very little extra effort it takes to include your schema in th…

It is really difficult to change down the line. My company tried and failed. Now we're stuck with MongoDB. Huge mistake, but a lesson was learned.

Edit: "tried and failed" in the political sense. You don't change horses in midstream etc.

Re: The genius and folly of MongoDB

#109

Post by bcoates »

bkanber wrote: post #84

I posted this further down the thread, but I thought I'd share my thoughts on why I like mongo. Most people don't like mongo because 10gen gives the impression that mongo is better than it actually is, many people feel that mongo is not reliable enough for at-scale applications. They're right; it's not. But that's ok, because: Mongo's really great for rapid prototyping. You don't need to worry about updating the sche…

I just use the filesystem for that sort of thing. Everyone justifies using MongoDB because its easy and general but compared to the tool and compatibility ecosystem around files it's awkward and primitive.

Re: The genius and folly of MongoDB

#110

Post by gaius »

spamizbad wrote: post #108
danpalmer wrote: post #87

Earlier quoted context omitted.

The case for using it as a prototyping database is the best use-case I've seen for Mongo, however I'm not sure it's always a good idea. For a hack-weekend sort of project, fine, but if you are in any way attempting to make a product, it strikes me as the sort of thing that would be really difficult to change later down the line, and so worth investing the very little extra effort it takes to include your schema in th…

It is really difficult to change down the line. My company tried and failed. Now we're stuck with MongoDB. Huge mistake, but a lesson was learned. Edit: "tried and failed" in the political sense. You don't change horses in midstream etc.

If this was a proprietary database we'd call that vendor lock-in and advocate an open source solution. 10gen is a company that earns it's revenue from selling support. They are highly incentivized to lure you in and trap you in a situation that requires a lot of consulting.
Post reply on HN