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

51–60 of 194 posts

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

#51

Post by true_religion »

diego wrote: post #18
calpaterson wrote: post #12

It's pretty incredible that the author of a post called "I’ll Give MongoDB Another Try. In Ten Years." criticises a comment on this same post telling him to read the tutorial all the way through as "unnecessarily aggressive". Aside from that, though, the 32 bit limitation is clear in the documentation and present on the download page. It's fine not to read the documentation before you use something but you can't then…

See my comment below. If you use a package manager you never see the warning.

Maybe.... just maybe you should read the documentation of the database you're installing before you actually start using it in production.

I'm sure this only bit the author because he was using MongoDB for a toy project, and in a real system he'd have done due diligence first.

I'm not a fan of MongoDB myself, but if I were to use it I know that I must read about every option available because by default MongoDB's team chose settings that are suited for speed and not reliability, durability, or (if i'm being less charitable) even sanity.

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

#52

Post by xoail »

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.

Indeed but by then there will be more advancements in software to compliment changes. If you are in technology business it is assumed that you will keep up with technology.

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

#53

Post by arielweisberg »

When I wrote some hobby code for Postgres using the PHP driver I had to manually check error codes after each and every operation. This came as no surprise to me.

Exception throwing database drivers are a relatively new thing not an old thing. The only thing MongoDB does differently is that the writes are fire and forget in that the database hasn't returned a response of any kind when the function returns.

In native code you can forget about using exceptions in a database driver because exception handling can be exceptionally broken on some platforms. SmartOS I am looking in your direction.

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

#54

Post by DanWaterworth »

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?

People who assume such trivialities would be handled for them like in every other DBMS.

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

#55

Post by manuscreationis »

diego wrote: post #18
calpaterson wrote: post #12

It's pretty incredible that the author of a post called "I’ll Give MongoDB Another Try. In Ten Years." criticises a comment on this same post telling him to read the tutorial all the way through as "unnecessarily aggressive". Aside from that, though, the 32 bit limitation is clear in the documentation and present on the download page. It's fine not to read the documentation before you use something but you can't then…

See my comment below. If you use a package manager you never see the warning.

This may be a case when using the package manager is not always the best option.

If you're talking about Ubuntu, I can attest that the default PM there is several versions out of date for a lot of things, and thus to get the version you'd expect, you're forced to install by hand.

Also, even using the PM version, didn't you get a warning when you started the server? I thought Mongo threw up a warning at start time about this exact issue (the 2GB limitation, not the silent failures)

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

#56

Post by pooriaazimi »

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)

I'm no expert in this area, but maybe if you want to use mongo for logging? Or things like that.

I kinda like TCP vs. UDP analogy. Sometimes you care more about speed than precision. A few dropped items in a log. Not a big deal. I'd rather have that, than to be forced to use a more expensive machine for the job.

That said, I absolutely think the default should be the TCP way.

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

#57

Post by jfoutz »

linuxhansl wrote: post #47
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…

I'm sorry. Which part of "It silently ignored my data" do you not understand? You call people "morons", yet it appears that you did not read the article yourself. Whether SQL or not, scalable or not, old or new, or whatever... Is completely immaterial here. When a database silently stops accepting data, and apparently has done so for 3 years, you have to at least admit that there are strange design goals at play. Now…

I think you're overlooking asynchronous writes. Exceptions kind of suck in the asynchronous world, because you need to clean up the write error and you have no idea where you are in your code.

With a getLastError model, you can do your work, then go check for errors when you're really ready.

I'm not saying it's a great api, but it does make sense in context. No idea why the tutorial the op followed didn't talk about the differences, or why asynch is hard.

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

#58

Post by omni »

mpd wrote: post #50
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."

Honest question - where would someone with no Mongo experience typically discover that?

For one, it's mentioned in Chapter 5: When To Use MongoDB in The Little MongoDB Book. http://openmymind.net/mongodb.pdf

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

#59

Post by flatline3 »

ceejayoz wrote: post #35
daveungerer wrote: post #27

It's almost like the commenters who are bashing the author of the post did not read the bit in bold, which is his main point: If you tell a database to store something, and it doesn’t complain, you should safely assume that it was stored. This has nothing to do with the 2Gb limitation. Nowhere in the documentation does it mention that it will silently discard your data. What will happen with the 64-bit version if you…

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

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

#60

Post by eli »

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)

Well, any time you'd rather have speed over completeness. Maybe you're aggregating tweets from the Twitter API and if the occasional one goes missing, it's not a big deal, or perhaps you can grab it on the next update. Maybe you're generating a real-time stats dashboard for your site and if one pageview gets lost every million, it's not a big deal.

Look, I agree that in most cases you probably want to do everything you can to make your data 100% complete. But failed writes should be really rare, and there are plenty of times I'd trade the rare missing write for cheaper/faster database servers.

Post reply on HN