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

121–130 of 280 posts

Re: The genius and folly of MongoDB

#121

Post by yummyfajitas »

meowface wrote: post #112
yummyfajitas wrote: post #56

Earlier quoted context omitted.

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

Mongo (and other document stores) let you do pretty complex querying within JSON objects. Postgres unfortunately doesn't let you do so; that's really the only thing keeping me with Mongo at the moment.

It does with plv8. Just like in mongodb, you get to write javascript functions and use them for queries.

https://postgres.heroku.com/blog/past/2013/6/5/javascript_in...

I don't know how stable/performant it is (I've never needed to use it), however...

Re: The genius and folly of MongoDB

#122

Post by dkural »

empthought wrote: post #119
bkanber wrote: post #93

Earlier quoted context omitted.

Of course you could argue that. But so what? Having an easier path towards scalability is nice, but irrelevant for the vast majority of projects; not every project is going to turn into a startup or a real product or even something you work on for more than a few weekends! The last time you hacked together a blogging engine in Node.js one weekend, were you worried about future scalability, or just playing with new te…

> postgre. Just so you know, that's not actually a thing.

He meant postgres, as you also know. When autocorrect fails, there is empthought.

Re: The genius and folly of MongoDB

#123

Post by integraton »

bkanber wrote: post #93
swanson wrote: post #86

Earlier quoted context omitted.

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.

Of course you could argue that. But so what? Having an easier path towards scalability is nice, but irrelevant for the vast majority of projects; not every project is going to turn into a startup or a real product or even something you work on for more than a few weekends! The last time you hacked together a blogging engine in Node.js one weekend, were you worried about future scalability, or just playing with new te…

> while it's pretty easy to do schema migrations, it's not easier than _not_ doing them.

Regardless of whether you are dealing with a strict schema or flexible schema, you still have to make changes to how you structure your data as you are prototyping or otherwise iterating on it. MongoDB provides no tangible benefit in this case. If you want to rename a field, then you still need to run an update.

How are ad hoc, manual, historically opaque tweaks to data in any way better than an easily generated and version controlled series of scripts representing a replayable history of changes to the data?

If anything, manual untracked tweaks make "rapid prototyping" more difficult since lots of partially or completely undocumented changes to the structure of the data are harder to revert, replay, reason about, or share with others. It's also more work to do it manually since you need to run the commands in multiple environments, rather than just entering the same command or, more frequently, a shortcut command into a generated file.

Re: The genius and folly of MongoDB

#124

Post by mdellabitta »

rit wrote: post #35
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…

I worked for 10gen (now MongoDB) for over 2 years (I left in December). Never once while I was there did they publish a benchmark: There was a [publicly] stated company policy to not publish or comment on benchmarks. If you have evidence otherwise (i.e. benchmarks published by the folks working on MongoDB) fine, but I take this as a deliberately inflammatory (and false) statement. EDIT: The global write lock was remo…

> database level lock

But that's not anywhere close to good enough.

Re: The genius and folly of MongoDB

#125

Post by ozataman »

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…

Application design for me almost always begins with data and data structures. Whether my database has an explicit schema or not, I always have one in mind, documented or otherwise reified in the table-data structures I have in my code. I just don't get why people would want a schema-free database that is in almost every way inferior to the rock-solid power beast that is Postgres. Just use a library with proper migration support so you can propagate changes to your schema rapidly during development. You'll thank us later when you learn a little bit of SQL and start analyzing your data, running circles around the no-sql guys.

Cassandra et. al. are completely different, in that you don't use them because they are more fun to use. You use them despite their awkward, low-level interfaces because you're going to dump billions of data cells into your database from day one with no end in sight and want all the easy scaling/availability features provided.

Re: The genius and folly of MongoDB

#126

Post by functional_test »

rdtsc wrote: post #106

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 s…

I understand some of the reasons people didn't like Mongo, but this always vexed me. The default write level was very clearly documented and you could always change it as necessary. Surely it would be necessary to read the documentation of a database before rolling it out to production?

Re: The genius and folly of MongoDB

#127

Post by rsynnott »

digitailor wrote: post #104
rsynnott wrote: post #52

Earlier quoted context omitted.

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 proj…

It varies, a fair bit. MongoDB is perhaps the worst, possibly because it's easy to get up and running with, and behaves a little magically (you don't need to know how it works to use it, or at least so you might think initially). It also has a company pushing it, of course.

I'd say that this is less of a problem for the Dynamo paper databases (Riak, Voldemort, Cassandra), because really to use them at all you have to have some idea of what's going on.

I'm a bit biased here, though, while I've found Voldemort, Redis and Cassandra useful and can see Riak and a couple of others being useful, I could never really figure out a good reason that anyone would use MongoDB besides naiveté. That said, I've never really tried, as I don't have a problem that fits it (part of my issue is that I don't know what a problem that fits it would look like).

Re: The genius and folly of MongoDB

#128

Post by rsynnott »

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…

> Mongo's really great for rapid prototyping.

Has any phrase ever struck more fear into the heart of a programmer? Rapid prototypes have a nasty tendency of accidentally becoming products...

> You can always switch databases later

shudder

Re: The genius and folly of MongoDB

#129

Post by EGreg »

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 think they are upset with their marketing, like "web scale". Even the name "Mongo" is derived from "Humongous" -- but that's exactly the scale at which you'd switch away from Mongo.

Reminds me of this: http://www.youtube.com/watch?v=URJeuxI7kHo

Want NoSQL? Use RIAK!

Re: The genius and folly of MongoDB

#130

Post by functional_test »

bcoates wrote: post #109
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.

The file system is great for some things, but, for example, how would you handle the same data to having multiple indices?
Post reply on HN