The genius and folly of MongoDB • Hacker News Board

Re: The genius and folly of MongoDB

#81

Post by oijaf888 » Sun, Oct 20, 2013, 7:47 PM UTC

rgo wrote: post #77

Previous versions of my startup's enterprise product used to be based on relational DBs (mostly Oracle, MySQL also). This year we switched to Mongo and dropped RDBMS support. RDBMS performance was fine most of the time as we're not doing big data really. Our problem was developing and maintaining a schema that holds lots of metadata many levels deep. Our app allows for unlimited user defined forms and fields, some of…

Perhaps your customers were receptive because you were supporting it and they were happy with the existing support you got and unhappy with their internal DBA department? Its possible that they didn't care about the technology and just realized that the support was going to be better.

Re: The genius and folly of MongoDB

#82

Post by ak217 » Sun, Oct 20, 2013, 7:48 PM UTC

invisible wrote: post #38

rogerbinns wrote: post #14

There are also people using MongoDB and finding it meets their needs well, and don't feel the need to keep writing about how everything sucks or is wonderful. (I'm one of them.) None of how MongoDB works is a secret. And just like everything else it has sweet spots and problem areas. And like many others, development continues and it gets better. The database does not get the job done - it is a tool to help get the j…

Mongos (the routing for MongoDB when clustering) has a bunch of drawbacks that make MongoDB worse. One of which is dropping all connections when a master switches. Have you dealt with those problems yet? MongoDB is generally perfect at small scale is what I have perceived. The new database level lock in 2.2 is also annoying (and arbitrary) but it is better than the global lock.

I'm curious, how do other DBMSs handle a master switch/other cluster updates? I'm familiar enough with mongos to know how it works but not what e.g. redis or postgres or mysql does.

Re: The genius and folly of MongoDB

#83

Post by andrewvc » Sun, Oct 20, 2013, 7:48 PM UTC

rgo wrote: post #77

Previous versions of my startup's enterprise product used to be based on relational DBs (mostly Oracle, MySQL also). This year we switched to Mongo and dropped RDBMS support. RDBMS performance was fine most of the time as we're not doing big data really. Our problem was developing and maintaining a schema that holds lots of metadata many levels deep. Our app allows for unlimited user defined forms and fields, some of…

Well written post. Even as a detractor of mongo I'll agree that it works for your use case. But the key is "Our app allows for unlimited user defined forms and fields, some of which may hold grids". That really isn't a very common case. SQL is not great at representing large groups of documents without any common structure.

The vast majority of apps just don't deal with that problem. If MongoDB was really only used by people that its a good fit for (like yourself), it'd really be a niche product. They're marketing it as a general purpose product, which is why they've earned scorn from so many.

Re: The genius and folly of MongoDB

#84

Post by bkanber » Sun, Oct 20, 2013, 7:50 PM UTC

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 schema at the db level, it can store any type of document in any collection without complaining, it's really easy to install and configure, the query language is simple and only takes a couple of minutes to learn, it's pretty fast in most use cases, it's pretty safe in most use cases, and it's easy to create a replica set once your prototype gets usage and starts scaling.

Mongo does everything well up until you reach the level where you need heavy-hitting, at-scale, mission-critical performance and reliability. Most projects out there (99 in 100?) will never reach the level of scale that requires better tools than mongo. And since the rest of it is so easy to use, that makes mongo a great starting point for most projects. You can always switch databases later, but mongo gives you the flexibility to concentrate on more important things in the early stages of a project.

Re: The genius and folly of MongoDB

#85

Post by arohner » Sun, Oct 20, 2013, 7:56 PM UTC

lttlrck wrote: post #79

arohner wrote: post #26

Earlier quoted context omitted.

Then where did the "Mongo is web scale", and sharding and performance come from? The fact remains that Mongo just doesn't scale, and 10gen was never honest about that.

Define "just doesn't scale"

Global write lock. Abysmal performance when your data set doesn't fit in ram. Clustering with durability. Clustering in a way that isn't horribly complex and fragile.

Re: The genius and folly of MongoDB

#86

Post by swanson » Sun, Oct 20, 2013, 7:58 PM UTC

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…

Couldn't you argue that e.g. Postgres and ActiveRecord give you the same rapid prototyping ability but with an easier (and more established) path towards scalability? It is easy to change your schema with migrations at the beginning of a project - just go edit the original ones and nuke your database. And I don't have to worry about properly configuring write-locks, replica sets, or writing map reduce javascript.

Re: The genius and folly of MongoDB

#87

Post by danpalmer » Sun, Oct 20, 2013, 8:15 PM UTC

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 the database, and use something like Postgres/MySQL/etc.

Re: The genius and folly of MongoDB

#88

Post by regularfry » Sun, Oct 20, 2013, 8:20 PM UTC

asperous wrote: post #66

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…

Besides the corruption, that just sounds like it's missing features. Missing features is ridicule worthy?

It can be when you look at how long people have been asking for these things.

Re: The genius and folly of MongoDB

#89

Post by theatrus2 » Sun, Oct 20, 2013, 8:23 PM UTC

rsynnott wrote: post #30

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…

> Attempting to use MongoDB in all storage or persistence scenarios is no more sensible than using MySQL in all cases. Substantially less sensible in many cases. MySQL has its issues (it has a lot of issues), but people have been able to get it to work surprisingly well in roles that it wasn't designed for (albeit sometimes by just building a database on top of it, as with Twitter's thing).

MySQL fills the "networked reliable transnational BTrees on disk" niche fairly well.

Re: The genius and folly of MongoDB

#90

Post by ams6110 » Sun, Oct 20, 2013, 8:26 PM UTC

yummyfajitas wrote: post #54

twic wrote: post #48

Earlier quoted context omitted.

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.

This is the case with all RDMBS I've used.