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

131–140 of 194 posts

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

#131

Post by mcgwiz »

flatline3 wrote: post #59
ceejayoz wrote: post #35

Earlier quoted context omitted.

> Nowhere in the documentation does it mention that it will silently discard your data. Demonstrably false. http://www.mongodb.org/display/DOCS/getLastError+Command "MongoDB does not wait for a response by default when writing to the database. Use the getLastError command to ensure that operations have succeeded."

I fail to understand how and why silent failure is considered a reasonable default.

The problem has and always will be that MongoDB toes the line between a caching product and a database product, regardless of what 10gen decides to call it. It's extremely frustrating that 10gen can't embrace this fact, and instead perpetuates marketing that causes the product to be perceived as flawed by their target audience. But once you've discovered this, you can use it appropriately (either by overriding the default silent failure to use it as for durable persistence, or only using it for caching or as an eventually consistent store).

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

#132

Post by randallsquared »

lawn wrote: post #111
randallsquared wrote: post #106

Earlier quoted context omitted.

...and if you're building a banking app, that's relevant. If you're building a chat system, maybe things other than data integrity matter more.

Is it not relevant for a blog? Your business website? Your toy application? It is even relevant for a chat system! And the flaw of your argument: Even if there are other more important things for an application, let's just make anything else than the #1 feature shit.

I'm just saying some databases are like the mail. A chat system is one such case.

And the flaw of your argument: Even if there are other more important things for an application, let's just make anything else than the #1 feature shit.

I don't actually understand what you mean, here, but since you say it's the flaw of my argument, I'm very interested in it. Could you rephrase briefly?

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

#133

Post by justinsb »

chimeracoder wrote: post #128
justinsb wrote: post #126

Earlier quoted context omitted.

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

Kudos to you for doing your research. If you're saying "don't use MongoDB without doing at least N days of research first", then you're very much at odds with (my perception of) the 10gen marketing message.

I think you're right though: MongoDB should not be used without _lots_ of research into its limitations.

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

#134

Post by chimeracoder »

justinsb wrote: post #133
chimeracoder wrote: post #128

Earlier quoted context omitted.

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

Kudos to you for doing your research. If you're saying "don't use MongoDB without doing at least N days of research first", then you're very much at odds with (my perception of) the 10gen marketing message. I think you're right though: MongoDB should not be used without _lots_ of research into its limitations.

> I think you're right though: MongoDB should not be used without _lots_ of research into its limitations.

That's true about any database, not just MongoDB; nothing new here.

> then you're very much at odds with (my perception of) the 10gen marketing message.

10Gen is fairly straightforward about the original issue, having blogged openly several times about their decisions - but at the end of the day, any engineer should do research beyond the simple marketer's pitch.

I won't doubt that there are people who make snap judgements about fundamental architecture based on marketing pitches[1], but that's very unfortunate, and the marketers really can't be blamed, especially when they make no effort to conceal the truth or deceive you!

[1]http://www.pinaldave.com/bimg/dilbert5.jpg

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

#135

Post by jcoder »

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…

> It's probably pretty bad for a general purpose tool, but I'd be surprised if anyone serious actually considers it one.

I have talked to more than one 10gen marketing bro who insisted that MongoDB is appropriate for any and all use cases, transient to archival. It's pretty disingenuous if you ask me.

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

#136

Post by desas »

smacktoward wrote: post #89
kombine wrote: post #79

Earlier quoted context omitted.

Second every word here. The version in the Ubuntu's repositories is not the latest(which is 2.2) and they can't be more explicit about it than pointing it out on the download page and giving a message upon the database startup.

The version in the Ubuntu's repositories is not the latest(which is 2.2) What does the author's complaint have to do with the version Ubuntu is distributing? Are the 32-bit limitations present in Ubuntu's version not present in the most recent version? If they are, than who cares which of them he installed? they can't be more explicit about it than pointing it out on the download page and giving a message upon the da…

> [debconf] There's probably a way to do the same thing in RPM-based systems

Nope. In fact fedora developed packagekit said the idea was broken and caused a controversy over supporting it for ages

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

#137

Post by j_s »

diminoten wrote: post #45
ceejayoz wrote: post #35

Earlier quoted context omitted.

> Nowhere in the documentation does it mention that it will silently discard your data. Demonstrably false. http://www.mongodb.org/display/DOCS/getLastError+Command "MongoDB does not wait for a response by default when writing to the database. Use the getLastError command to ensure that operations have succeeded."

It blows my mind that you'd have to post this at all. Who's writing to mongo without making sure the write succeeded?

Me: "MongoDB, please store this: ..."

MongoDB: "Done!"

[Ed: The following is an unusual default requirement]

Me: "MongoDB, did you store what I asked?"

MongoDB: "Nope! Good thing you checked!"

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

#138

Post by justinsb »

chimeracoder wrote: post #134
justinsb wrote: post #133

Earlier quoted context omitted.

Kudos to you for doing your research. If you're saying "don't use MongoDB without doing at least N days of research first", then you're very much at odds with (my perception of) the 10gen marketing message. I think you're right though: MongoDB should not be used without _lots_ of research into its limitations.

> I think you're right though: MongoDB should not be used without _lots_ of research into its limitations. That's true about any database, not just MongoDB; nothing new here. > then you're very much at odds with (my perception of) the 10gen marketing message. 10Gen is fairly straightforward about the original issue, having blogged openly several times about their decisions - but at the end of the day, any engineer sh…

> That's true about any database, not just MongoDB; nothing new here.

That's exactly the point where we started. A well-designed system fails "safe"; it should obey the principle of least surprise. Specifically: MongoDB should default to synchronous writes to disk on every commit; official drivers should default to acknowledging every network call; MongoDB shouldn't allow remote access from the network by default. Once you want higher performance or remote access, you can read about the configuration options to change and learn on-the-fly, evaluating the trade-offs as needed.

Other systems are safe by default (e.g. PostgreSQL), and their out-of-the box performance and setup complexity suffers because of it. MongoDB could ship "safe" (with the same trade-offs), but chooses not to. That sort of marketing-led decision-making has no place in my technology stack.

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

#139

Post by esrauch »

randallsquared wrote: post #132
lawn wrote: post #111

Earlier quoted context omitted.

Is it not relevant for a blog? Your business website? Your toy application? It is even relevant for a chat system! And the flaw of your argument: Even if there are other more important things for an application, let's just make anything else than the #1 feature shit.

I'm just saying some databases are like the mail. A chat system is one such case. And the flaw of your argument: Even if there are other more important things for an application, let's just make anything else than the #1 feature shit. I don't actually understand what you mean, here, but since you say it's the flaw of my argument, I'm very interested in it. Could you rephrase briefly?

Is it actually unimportant if a chat message is dropped? It seems damn important to me, what use is a chat app if someone sends you an important message and you never receive it? I could see that being true for something like anonymized logs where you are only going to be looking at it in aggregate, but just silently ignoring chat messages really doesn't seem acceptable to me.

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

#140

Post by chimeracoder »

justinsb wrote: post #138
chimeracoder wrote: post #134

Earlier quoted context omitted.

> I think you're right though: MongoDB should not be used without _lots_ of research into its limitations. That's true about any database, not just MongoDB; nothing new here. > then you're very much at odds with (my perception of) the 10gen marketing message. 10Gen is fairly straightforward about the original issue, having blogged openly several times about their decisions - but at the end of the day, any engineer sh…

> That's true about any database, not just MongoDB; nothing new here. That's exactly the point where we started. A well-designed system fails "safe"; it should obey the principle of least surprise. Specifically: MongoDB should default to synchronous writes to disk on every commit; official drivers should default to acknowledging every network call; MongoDB shouldn't allow remote access from the network by default. On…

The Principle of Least Surprise has local scope. You may be surprised to find asynchronous writes on an arbitrary database, but not for a database that is documented, advertised, and marketed as asynchronous-by-default.

'Surprise' is relative to the current environment and paradigm (in this case, asynchronicity)- if you find that surprising, then that means that you should have read the basic documentation properly.

> MongoDB could ship "safe" (with the same trade-offs), but chooses not to.

Because that's one of the main points of choosing MongoDB...

Post reply on HN