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

191–200 of 280 posts

Re: The genius and folly of MongoDB

#191

Post by functional_test »

clwk wrote: post #187
functional_test wrote: post #179

Earlier quoted context omitted.

I would also read the manual of a car I just bought before driving it. I guess that's just my style. Don't get me wrong, I'm not saying your assumption is unreasonable. But in the end, it's on you as a conscientious developer to read the documentation. I'm not even suggesting cover to cover - in this case though they are very up front about write concerns. There is no real excuse to find this out any other way, it's…

Out of curiosity, have you ever bought a car, and did you actually read the whole manual before driving it? It's a nice hypothetical, and that might be your style. Most real-world car purchase scenarios I'm familiar with would make that style impractical.

Literally 1 month ago, I bought a car and did exactly this. What's impractical about spending a little time to read?

Re: The genius and folly of MongoDB

#192

Post by [deleted] »

Goopplesoft wrote: post #181
continuations wrote: post #158

Earlier quoted context omitted.

> Having a schemaless, easy to manage database is a step forward for sooo many use cases Can you explain why can't you do schemaless with an RDBMS? From what I understand MongoDB is schemaless by storing all fields as one single JSON document. So what stops you from doing the same in an RDBMS - have a catch-all field "JSON" and store all your data there?

That'd be an unqueryable string field in most sql databases. Not at all the same thing.

[deleted]

Re: The genius and folly of MongoDB

#193

Post by edvinbesic »

rdtsc wrote: post #169
functional_test wrote: post #126

Earlier quoted context omitted.

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?

> Surely it would be necessary to read the documentation of a database before rolling it out to production? You buy a car. It comes with brakes disabled because for whatever reasons that also lets it get to a higher top speed. You are expected to read you car owner manual and on page 54 you find that you have to hold "enable brakes" button under the console for 10 seconds to turn on your brakes. Would it vex you that…

This is a pretty silly argument. The people whom it affects are not people buying cars, it's more like launching a shuttle mission, at which point I would assume you have read the f*ing manual.

Re: The genius and folly of MongoDB

#194

Post by orthecreedence »

integraton wrote: post #164
dodyg wrote: post #154

Earlier quoted context omitted.

This is where a nice query/manipulation language come handy http://www.rethinkdb.com/api/#js

Agreed. PostgreSQL: ALTER TABLE posts RENAME COLUMN author TO writer; MongoDB: db.posts.update({}, {$rename:{"author":"writer"}}, false, true); (I'm excluding RethinkDB since it's still under development and doesn't have a rename command yet)

I don't think it really needs a `rename` command. The query language supports it without:

    r.table('posts').replace(function(item) { return item.without('author').merge({writer: item('name')}); })

Re: The genius and folly of MongoDB

#195

Post by vanadium »

functional_test wrote: post #191
clwk wrote: post #187

Earlier quoted context omitted.

Out of curiosity, have you ever bought a car, and did you actually read the whole manual before driving it? It's a nice hypothetical, and that might be your style. Most real-world car purchase scenarios I'm familiar with would make that style impractical.

Literally 1 month ago, I bought a car and did exactly this. What's impractical about spending a little time to read?

Your approach is wholly impractical on its face, actually.

So, let me get this straight: You laid down tens of thousands of dollars on a vehicle that you only post-purchase read the manual of, and you're raising this as some sort of standard people should follow?

Honestly, asking the right questions (and test-driving) upfront should be what lands the purchase, and not discovering the folly of purchasing a car with such ass-backwards issues you only discover after the fact when you bother to dig out the manual.

You drove it off the lot after you bought it, right? Or did you read the manual in the lot right after signing the papers locking you into the purchase?

Re: The genius and folly of MongoDB

#196

Post by mritun »

threeseed wrote: post #92
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.

Configuring write-locks ? I guess you have never actually used MongoDB before which explains why absolutely none of what you said makes any sense. MongoDB is far easier to use, manage the schema with and scale than PostgreSQL.

... if you don't care about your data!

It's not a database that by default just throws your data at the wall and well, doesn't even care to look if it stuck.

Re: The genius and folly of MongoDB

#197

Post by ak217 »

rsynnott wrote: post #137
ak217 wrote: post #82

Earlier quoted context omitted.

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.

Most master-slave databases don't do auto-promotion themselves; it's a bit of a minefield. (In particular, in cases of network partition, where some applications servers may have a different view to others on whether the master is dead or not).

OK, but that's a different concern. If a database admin manually switches a master (called a primary in Mongo), then someone is responsible for deciding what to do with queries that are in flight. In Mongo, the driver drops them, which is less than optimal. It certainly is a hard problem for writes, but not so for reads.

To your point, I think deployments on modern architectures generally want the ability to scale out and tolerate network partitions, which makes the ability to drop and re-elect masters, reconcile a node that rejoins after a partition, manage shards, avoid hosing remaining nodes, etc. critical. Inability to do so really hurts on a platform like AWS (or in any multi-datacenter deployment, really).

Re: The genius and folly of MongoDB

#198

Post by CoffeeDregs »

edvinbesic wrote: post #193
rdtsc wrote: post #169

Earlier quoted context omitted.

> Surely it would be necessary to read the documentation of a database before rolling it out to production? You buy a car. It comes with brakes disabled because for whatever reasons that also lets it get to a higher top speed. You are expected to read you car owner manual and on page 54 you find that you have to hold "enable brakes" button under the console for 10 seconds to turn on your brakes. Would it vex you that…

This is a pretty silly argument. The people whom it affects are not people buying cars, it's more like launching a shuttle mission, at which point I would assume you have read the f*ing manual.

Grandparent seems to make a valid argument.

    it's more like launching a shuttle mission
Given how much we spend time talking about MVPs, Lean Startup, etc, I think people on this site are trying to avoid launch a shuttle mission. [Often] They're looking at building startups and are looking for both time-tested and new-but-advantage-providing technologies and techniques. At first glance, MongoDB appears to be advantage-providing so people adopted it quickly. They didn't read the manual; they put it in production on a small site and got surprised by the lack of durability.

Re: The genius and folly of MongoDB

#199

Post by revetkn »

functional_test wrote: post #191
clwk wrote: post #187

Earlier quoted context omitted.

Out of curiosity, have you ever bought a car, and did you actually read the whole manual before driving it? It's a nice hypothetical, and that might be your style. Most real-world car purchase scenarios I'm familiar with would make that style impractical.

Literally 1 month ago, I bought a car and did exactly this. What's impractical about spending a little time to read?

> What's impractical about spending a little time to read?

It's impractical because people live a finite amount of time and this is a terrible use of it

Re: The genius and folly of MongoDB

#200

Post by rdtsc »

functional_test wrote: post #191
clwk wrote: post #187

Earlier quoted context omitted.

Out of curiosity, have you ever bought a car, and did you actually read the whole manual before driving it? It's a nice hypothetical, and that might be your style. Most real-world car purchase scenarios I'm familiar with would make that style impractical.

Literally 1 month ago, I bought a car and did exactly this. What's impractical about spending a little time to read?

What is impractical is that something like brakes not working is not something you want to find in the manual on page 54. You don't want the car to start without that feature unless you enter a special code, and confirm you know what you are doing.

A database that has default configured that ends up corrupting users' data silently is like buying a car with the brakes disabled.

Well except that in the car case may brakes disabled won't make the car go faster, but in case of MongoDB I remember fans strutting write benchmarks around comparing it to Postgres, Couch and other database and telling how it is webscale. The reason that design decision was made is shady. That was my initial point.

Post reply on HN