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

51–60 of 280 posts

Re: The genius and folly of MongoDB

#51

Post by yummyfajitas »

mattdeboard wrote: post #17
yummyfajitas wrote: post #15

Earlier quoted context omitted.

For what use cases is Mongo the right tool?

It's "a" right tool in any case where distributed storage of unstructured data in JSON format is wanted, where database-level locks won't be an issue of concern, and availability is the primary, overriding concern.

What does mongo offer over (possibly sharded) postgres for this use case? Postgres won't hit you with db-level locks and gives you master/slave replication for availability. You can also get great performance if you put the WAL on a ramdisk, which I think is roughly equivalent to how mongodb handles writes.

I'm really not trying to be argumentative here, I'm just trying to understand what mongodb is for.

Re: The genius and folly of MongoDB

#52

Post by rsynnott »

rogerb wrote: post #33
orthecreedence wrote: post #16

Earlier quoted context omitted.

> None of how MongoDB works is a secret. Maybe not now, but this hasn't always been the case. The fact that they had (have?) a global write lock was completely buried on the doc site for ages. Benchmarks were waved in front of developer's faces to distract them from the "drivers don't actually write data, they just blast it out in every direction and hope it lands somewhere good" BS. I don't use Mongo anymore, and I…

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

Re: The genius and folly of MongoDB

#53

Post by rsynnott »

nostrademons wrote: post #46
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).

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 (hashtables, linked lists) and then journaling out changes to the filesystem as records that are read in on startup?

That works for some things. However, it's no more a foolproof magical solution than MySQL or MongoDB or Cassandra or Oracle or... It just has different tradeoffs (non-primary key queries will tend to be a problem, you'll have to make your own replication, sharding will be a problem, etc etc).

Re: The genius and folly of MongoDB

#54

Post by yummyfajitas »

twic wrote: post #48
JulianMorrison wrote: post #28

Earlier quoted context omitted.

You have a smallish number of documents where some particular field of fixed size gets overwritten a lot, the old values are uninteresting, and it wouldn't really be a tragedy if your data got trashed. For example, it's the player's score. You want a fixed-size, rolling backlog of time series data such as logs.

Is it better than a relational database for that?

Postgres update performance is pretty bad. When running a big data migration, it's generally faster to copy the old table to a new temporary table and rename the temp table to the old table than it is to run an update.

Re: The genius and folly of MongoDB

#55

Post by rsynnott »

mattdeboard wrote: post #11
bithive123 wrote: post #4

This article doesn't really make a case for "genius" -- "saving grace", maybe. And in what universe are the Redis data structures "crazy"?

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.

Re: The genius and folly of MongoDB

#56

Post by yummyfajitas »

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
    );

Re: The genius and folly of MongoDB

#58

Post by twic »

jbooth wrote: post #18
cincinnatus wrote: post #7

Earlier quoted context omitted.

MySQL is richly deserving of ridicule as well. It's ubiquity is unfortunate.

If you're going to comment so strongly, some explanation of why it deserves such ridicule would contribute much more value to the discussion.

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 table level with MyISAM - and still at row level with InnoDB?).

As well as things like that which are actually ridiculous, there is also the substantial gap in features as compared to real databases. Things like recursive queries, user-defined types, partial indices, etc, are commonplace in the more sophisticated databases. You probably won't need them for a simple web application (or even a complex one!), but they can be very useful when trying to do more complex things, or manage a complex system efficiently.

Re: The genius and folly of MongoDB

#59

Post by justincormack »

hannibal5 wrote: post #10

Like the article says, ZFS is pretty damn good. Keystore where the "engine" is ZFS works mighty well and is reliable. There is little need for simple solutions like MongoDB if the filesystem rocks.

Filesystems are not great as kv stores if your values are usually very small (under page size). Well, they might still be better than some systems...

Re: The genius and folly of MongoDB

#60

Post by crucialfelix »

hayksaakian wrote: post #6
bsg75 wrote: post #2

> MongoDB is easy to make fun of. I think more often its easy to poke fun at _how_ its used. When any tool or tech is used globally, before knowing its limitations, problems are likely. Attempting to use MongoDB in all storage or persistence scenarios is no more sensible than using MySQL in all cases. Yes, there is marketing around this product that must be looked at critically - after taking into account that many n…

I think the difference is you don't get made fun of online for using MySQL for everything

people make fun of MySQL all the time. especially postgresql people :)

anecdotally in the more than 10 years I've used MySQL I've never had any issues. whereas with postgresql I've had a few major downtime incidents. it can be very stubborn and arcane. but at least I didn't lose any data.

Post reply on HN