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

I’ll Give MongoDB Another Try In Ten Years

diegobasch.com

Post reply on HN
Print view View original

121–130 of 194 posts

Re: I’ll Give MongoDB Another Try In Ten Years

#121

Post by lotyrin »

chimeracoder wrote: post #98
jeffdavis wrote: post #81

I think blaming the user here is partially valid (he didn't read the docs), but that's not the whole story. There is a discontinuity between the ease-of-use story and the blame-the-user story, regardless of how well documented the async insert behavior is. And it doesn't have to be this way. There are ways of designing interfaces, APIs, and even naming that go a long way to prevent your users from shooting themselves…

> There is no reason mongo couldn't be clear about this distinction -- say, rename "insert" to "async_insert" and have "insert" be a wrapper around async_insert and getLastError. But instead, it's the user's fault because they didn't read the docs. Because if you don't read enough of the docs to understand that 'insert' is asynchronous insert, you don't understand MongoDB and haven't done your research. Why should 'i…

It's not that way because somebody in the 70's flipped a coin and decided that sync was heads.

It's because it's a reasonable assumption to make. Data loss shouldn't be a surprise, if I need speed and am willing to risk dataloss I should have the option, but should explicitly choose to use it.

Re: I’ll Give MongoDB Another Try In Ten Years

#122

Post by clintonb11 »

pjungwir wrote: post #85

I ran into this same nasty surprise building a prototype to store requests in Mongo instead of Postgres. It was enough to scare me away, too. Glad I noticed it while it was still just a script+Makefile simulation. Another problem with Mongo I never heard anyone else raise is that there are no namespaces. If I install Mongo, all the tables/collections live in the same namespace. What if I want to use it for multiple p…

You have multiple databases, just like a sql solution. One database per project.

Re: I’ll Give MongoDB Another Try In Ten Years

#123

Post by nestlequ1k »

kombine wrote: post #84

A lot of bashing of MongoDB lately is a sign to give a technology at least a try.

Great point. That's usually how you to tell when a technology is starting to disrupt things. Really smart people / experts in their field (which Diego definitely is) start to bash it. In this case, he has a point but has way overblown things. But that's ok, that means Mongo is on the right track.

Re: I’ll Give MongoDB Another Try In Ten Years

#124

Post by ukd1 »

smacktoward wrote: post #44
mtkd wrote: post #26

This is the latest in a long line of negative posts on MongoDB based solely on first impressions because either: 1) it does not behave exactly like SQL 2) the user didn't read any more than a Quickstart Guide 3) the user fundamentally misunderstands the aim of the new technology or the application it is intended for Ember.js suffers from the same ignorance. What makes it worse is all the morons who upvote without eve…

This technology has absolutely no comparison with SQL other than it persists data Except that apparently under certain circumstances it doesn't persist data, which was the author's point. Personally I wouldn't be upset about a limitation like the one described as much as I would be upset about the database not logging an error when it discards the data. Logs are a primary way you figure out what's wrong when your app…

You can get MySQL to do dumb stuff as well, though you have to specifically ask it to take more risks - http://dev.mysql.com/doc/refman/5.5/en/insert-delayed.html

Almost all of the complaints against MongoDB are down to assumptions and lack of understanding about the database.

Re: I’ll Give MongoDB Another Try In Ten Years

#125

Post by chimeracoder »

lotyrin wrote: post #121
chimeracoder wrote: post #98

Earlier quoted context omitted.

> There is no reason mongo couldn't be clear about this distinction -- say, rename "insert" to "async_insert" and have "insert" be a wrapper around async_insert and getLastError. But instead, it's the user's fault because they didn't read the docs. Because if you don't read enough of the docs to understand that 'insert' is asynchronous insert, you don't understand MongoDB and haven't done your research. Why should 'i…

It's not that way because somebody in the 70's flipped a coin and decided that sync was heads. It's because it's a reasonable assumption to make. Data loss shouldn't be a surprise, if I need speed and am willing to risk dataloss I should have the option, but should explicitly choose to use it.

> if I need speed and am willing to risk dataloss I should have the option, but should explicitly choose to use it.

You did, by choosing to use MongoDB.

(And if you chose MongoDB without being aware of that implication, you didn't choose MongoDB for the right reasons or didn't do your due diligence, because you cannot understand MongoDB's use case and tradeoffs if you were unaware of this.)

Re: I’ll Give MongoDB Another Try In Ten Years

#126

Post by justinsb »

chimeracoder wrote: post #98
jeffdavis wrote: post #81

I think blaming the user here is partially valid (he didn't read the docs), but that's not the whole story. There is a discontinuity between the ease-of-use story and the blame-the-user story, regardless of how well documented the async insert behavior is. And it doesn't have to be this way. There are ways of designing interfaces, APIs, and even naming that go a long way to prevent your users from shooting themselves…

> There is no reason mongo couldn't be clear about this distinction -- say, rename "insert" to "async_insert" and have "insert" be a wrapper around async_insert and getLastError. But instead, it's the user's fault because they didn't read the docs. Because if you don't read enough of the docs to understand that 'insert' is asynchronous insert, you don't understand MongoDB and haven't done your research. Why should 'i…

A good system is forgiving; it encourages exploration; if there's a choice between safety and performance it defaults to safety. If/when profiling shows the safe behaviour to be a bottleneck, then users can Google the issue and discover "Oh, I just need to set flag X; I can live with the consequences here".

Expecting the user to be an expert in your product from the start is simply not realistic; a well-designed system facilitates use by people of varying levels of expertise.

Re: I’ll Give MongoDB Another Try In Ten Years

#127

Post by clintonb11 »

nemesisj wrote: post #46

We've been interviewing candidates to join our team for a few months, and I've also lent some interviewing support to other startups in our area. I've noticed a trend across about 20+ candidates, all of whom are smart people: people are using Mongo without actually understanding what the hell it's trying to solve by getting away from the RDBMS paradigm. I'm not sure if this is because 10gen markets it as a general pu…

What about scalability? Trying to cluster and shard MySQL is a very difficult task, but with MongoDB it is trivial. No schema can be good, but scaling out easily is the big plus I see.

Re: I’ll Give MongoDB Another Try In Ten Years

#128

Post by chimeracoder »

justinsb wrote: post #126
chimeracoder wrote: post #98

Earlier quoted context omitted.

> There is no reason mongo couldn't be clear about this distinction -- say, rename "insert" to "async_insert" and have "insert" be a wrapper around async_insert and getLastError. But instead, it's the user's fault because they didn't read the docs. Because if you don't read enough of the docs to understand that 'insert' is asynchronous insert, you don't understand MongoDB and haven't done your research. Why should 'i…

A good system is forgiving; it encourages exploration; if there's a choice between safety and performance it defaults to safety. If/when profiling shows the safe behaviour to be a bottleneck, then users can Google the issue and discover "Oh, I just need to set flag X; I can live with the consequences here". Expecting the user to be an expert in your product from the start is simply not realistic; a well-designed syst…

> A good system is forgiving; it encourages exploration; if there's a choice between safety and performance it defaults to safety.

Not if you're choosing a system that's explicitly marked for performance over safety.

> Expecting the user to be an expert in your product from the start

The 'product' in this case is a non-relational database, not an iGadget. The user can and should be expected to be familiar with the main strengths and weaknesses of the database as a whole.

There is no way you can convince me that someone who has done a reasonable level of due-diligence in investigating MongoDB can be surprised when it behaves asynchronously.

Re: I’ll Give MongoDB Another Try In Ten Years

#129

Post by prodigal_erik »

DanWaterworth wrote: post #23
andrewvc wrote: post #16

I'm a pretty big detractor of mongo, but I don't agree with this post. One of mongo's main design decisions is to defer writes, making this sort of thing possible. I think it's a crappy tradeoff but it is one of the things that makes mongodb mongodb. If you use it without knowing this you haven't researched it well.

When is this behaviour useful? (Benchmarks don't count)

If your failure modes are uncorrelated (i.e., spread across datacenter facilities with separate power supplies), you might be happy knowing a majority has accepted the write in memory, even though none of them have stored it yet (because that's slower if you're on spinning rust).

Re: I’ll Give MongoDB Another Try In Ten Years

#130

Post by taude »

nemesisj wrote: post #46

We've been interviewing candidates to join our team for a few months, and I've also lent some interviewing support to other startups in our area. I've noticed a trend across about 20+ candidates, all of whom are smart people: people are using Mongo without actually understanding what the hell it's trying to solve by getting away from the RDBMS paradigm. I'm not sure if this is because 10gen markets it as a general pu…

I see the same thing with everyone using NODE.JS to serve traditional web applications with synchronous database access.
Post reply on HN