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

141–150 of 194 posts

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

#141

Post by mattmanser »

chimeracoder wrote: post #102
gnufied wrote: post #21

Earlier quoted context omitted.

No. He is saying out of all faults Mongo has - blog author picks the one which is rather well known.

Worse, it's the necessary tradeoff of one of MongoDB's self-proclaimed benefits (asynchronicity) - it's not an edge case; it's part of the core reasons you'd switch to MongoDB (or at least take into account when making that choice). If that surprises you, it's because you haven't switched for the right reasons or haven't researched enough to know that every benefit has a tradeoff (and to know what those tradeoffs are…

Where on this page is the word asynchronous mentioned:

http://www.mongodb.org/

If they just wrote asynch on that page somewhere most experienced programmers would immediately understand the implications. And also understand how the amazing performance was being achieved.

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

#142

Post by pjungwir »

clintonb11 wrote: post #122
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.

Can you elaborate please? With a Postgres/MySQL/Oracle installation I can say `CREATE DATABASE` and get a new namespace. I couldn't find anything like that with Mongo. Am I just missing something?

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

#143

Post by michaelt »

tlack wrote: post #107
wglb wrote: post #96

Earlier quoted context omitted.

Surely you don't think that this is a reasonable model for how a database should work, do you?

If you can turn that behavior on and off (by using getLastError or whatever), why not have this feature? If I'm logging upvotes on a post or comments on a blog, which is about as serious as 99% of these b.s. startups are doing, I think it's fair to ignore errors. I do agree that this should be pointed out in huge blinking letters though, or be a driver flag that is on by default. The amount of people who don't know t…

  If I'm logging upvotes on a post or comments on a blog, 
  [...] I think it's fair to ignore errors.
Even in that situation, you need to know whether you're discarding 1% of upvotes or 99% of upvotes.

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

#144

Post by justinsb »

chimeracoder wrote: post #140
justinsb wrote: post #138

Earlier quoted context omitted.

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

I understand where you're coming from, though I disagree.

I hope you continue to explain these caveats to everyone considering MongoDB. I hope you recognize that not everyone is an expert in these limitations, and that you clearly explain to those that might not know it that MongoDB's "2GB limit" really means "data loss"; as does 'asynchronous'. Then you'll see fewer blog posts from people that didn't see through the marketing speak and were bitten by the defaults.

Right now, I think all these blog posts describing MongoDB losing data or performing poorly are getting upvoted because people are learning of these limitations for the first time.

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

#145

Post by cheald »

diego wrote: post #4
ceejayoz wrote: post #2

Not reading the documentation (or hell, the red "note" text under each 32 bit download link at http://www.mongodb.org/downloads ) for basic limitations will bite you in the ass in 2022 just as easily as it will in 2012.

Except that it was hidden deeply in the documentation. It's like making a car that has the gas and brake pedals switched, and then blaming accidents on people not reading section 5 of the owner's manual. I'm hardly an inexperienced programmer. I've used Cassandra, SimpleDB, Voldemort, etc. I wrote part of the Inktomi Search Engine in the 90s, and plenty of (what today would be called) NoSQL stores over the years. A d…

It blares it at you if you try to start up a 32-bit Mongo binary. And it's on the downloads page. And in the documentation. And in every blog post about MongoDB ever.

That 2009 post is the canonical post about the issue, which is why it has such page rank. Its position is a consequence of the fact that it's linked to from all over the web, not because nobody has discussed it since.

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

#146

Post by cheald »

ceejayoz wrote: post #41
xoail wrote: post #10

The world is moving towards 64 bit. 9 out of 10 machines I lay hands on run 64 bit. Just move on and stop complaining.

In fairness, this would eventually happen on a 64 bit machine too, just not as quickly. No excuse for not reading the docs, though.

The 64-bit limit is 8.6 exabytes. There won't be anyone using Mongo that runs into that limit this century.

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

#147

Post by randallsquared »

esrauch wrote: post #139
randallsquared wrote: post #132

Earlier quoted context omitted.

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.

Well, in practice, it's not too uncommon to send chat messages or SMS messages that just vanish, or arrive out of order, or arrive the day after they were sent. People do not, then, say that SMS is completely useless; instead, they accept that once in a while a message won't get through, and that they should call if it's important.

I'm not saying it's not at all important that chat messages actually get sent, and if it happens every single day to a user, then they might well look for alternatives, but it's not of the same importance as losing a banking transaction. If accepting that occasional writes will be dropped on the floor allows you to get your product out in October instead of December, that could be an acceptable tradeoff. Certainly not every use case is like this, but some are.

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

#148

Post by cheald »

j_s wrote: post #137
diminoten wrote: post #45

Earlier quoted context omitted.

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!"

But if you actually read about how it works...

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

MongoDB: "Okay, I've accepted your request. I'll get around to it eventually. Go about your business, there's no sense in you hanging around here waiting on me."

Or, if you really want to be sure it's done:

Me: "MongoDB, please store this. It's important, so let me know when it's done."

MongoDB: "Sure boss. This'll take me a little bit, but you said it's important, so I'm sure you don't mind waiting. I'll let you know when it's done."

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

#149

Post by cheald »

pjungwir wrote: post #142
clintonb11 wrote: post #122

Earlier quoted context omitted.

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

Can you elaborate please? With a Postgres/MySQL/Oracle installation I can say `CREATE DATABASE` and get a new namespace. I couldn't find anything like that with Mongo. Am I just missing something?

"use foobar" creates a new database called foobar.

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

#150

Post by CJefferson »

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?

If it blows your mind that people would write to mongo without making sure the write succeeded, then doesn't that make the default behaviour itself mindblowing?

Perhaps a better option would be to have an 'unsafe_write' option. But then of course, benchmarks would look less impressive which didn't use a function with 'unsafe' in the name.

Post reply on HN