I’ll Give MongoDB Another Try In Ten Years • Hacker News Board

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

#61

Post by jaegerpicker » Mon, Sep 24, 2012, 4:48 PM UTC

diego wrote: post #5

Adirael wrote: post #3

Just read the documentation and learn the APIs, this is what happens when you just copy and paste code from a tutorial.

This type of attitude is not constructive. Of course I read the documentation. Much more than "copy and paste from the tutorial." I looked at tons of code samples as needed, read blog posts, etc. The limitation wasn't obvious at all. This reminds me of the attitude that I had to correct in developers that worked for me: - There is a huge difference between "it works" and "it does what the user expects in a friendly w…

The limitation WAS obvious to a great number of people. It's in the documentation, it's on the download page, and it's posted in several blogs available via google searches.

Beyond that I'm not sure why anyone would run a production system on a 32 bit system anymore. Sure the failing silently part sucks but really this seems much more like a poor deployment then a actual bug in mongodb being the root cause.

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

#62

Post by omni » Mon, Sep 24, 2012, 4:51 PM UTC

DanWaterworth wrote: post #48

agscala wrote: post #39

Earlier quoted context omitted.

This has nothing to do with the client library, so it would not matter which language you use to interface with MongoDB.

As I understand it, it has everything to do with the client library, some clients may call getLastError on every operation and raise errors when they occur, for example.

PyMongo, for instance, can do this for most operations by passing safe=True.

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

#63

Post by jcoder » Mon, Sep 24, 2012, 4:51 PM UTC

All I'm getting from this conversation is that there is a heavy prevalence of Stockholm Syndrome among MongoDB users.

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

#64

Post by DanWaterworth » Mon, Sep 24, 2012, 4:52 PM UTC

eli wrote: post #60

DanWaterworth wrote: post #23

Earlier quoted context omitted.

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

This wasn't the occasional write though, this was every write after 2GB. That should set off alarm bells somewhere.

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

#65

Post by olalonde » Mon, Sep 24, 2012, 4:53 PM UTC

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?

The people over at MongoDB who wrote the tutorial? http://api.mongodb.org/wiki/current/Ruby%20Tutorial.html#Rub...

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

#66

Post by ericcholis » Mon, Sep 24, 2012, 4:56 PM UTC

First, your friends with MongoDB are fsync and safe. These are both documented and discussed in more than a few places: http://nosql.mypopescu.com/post/1052759609/mongodb-safe-and-...

So, assuming you are writing an ecommerce application, here's where I think these flags come in.

- Session data: fsync = true. Wait for a response, and ensure it's written to disk

- Internal web analytics: safe = false. Who cares if it's written, I've got an application to serve!

- Orders: fsync = true. I know, RDBMS, transactions, blah blah blah.

People tend to look at NoSQL and wonder why it doesn't function like MySQL, then they loudly complain how bad the software is. Nobody is writing articles about how Memcached doesn't function like MySQL.

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

#67

Post by twerquie » Mon, Sep 24, 2012, 4:58 PM UTC

eli wrote: post #60

DanWaterworth wrote: post #23

Earlier quoted context omitted.

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

The problem with your code not caring if the odd record gets lost is that it probably also doesn't care if all records start getting lost.

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

#68

Post by [deleted] » Mon, Sep 24, 2012, 5:00 PM UTC

ShabbyDoo wrote: post #31

The author doesn't mention if he had called getLastError after inserting data: http://www.mongodb.org/display/DOCS/getLastError+Command The MongoDB "way" is that clients know the importance of their data and can choose write strategies which make the proper trade-off between insertion throughput/latency and durability/consistency.

[deleted]

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

#69

Post by manuscreationis » Mon, Sep 24, 2012, 5:00 PM UTC

bdcravens wrote: post #37

There's a bigger question here. I get why diego was flabbergasted by the default, and I also hear legitimate claims that the documentation should have been read. But what I want to know is: Why are MongoDB advocates in such a bad mood? It's legit to criticize a language or a database. However, it seems to me that when MongoDB gets involved, the tone is far more aggressive and defensive. What's up with that? It's just…

While I agree with the sentiment you're expressing here on some levels (people don't like it when you insult things they like, as they feel they need to defend their choice or themselves because of it), I don't think that quite applies here.

This is a case where, although the ultimate complaint of the author is the behavior of the product (which is documented, but un-intuitive in nature unless you've read up on the issue), it's the way in which he chose to frame the problem that is getting people upset.

This is a known issue, even if it seems like a completely poor design decision. The issue I think most people here are taking is that because the author did almost no research on the topic, he got himself into a problem, and is trying to blame it on Mongo.

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

#70

Post by pooriaazimi » Mon, Sep 24, 2012, 5:01 PM UTC

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…

It's stated plainly and prominently in http://www.mongodb.org/downloads that 32-bit version is limited to 2GB. It's mentioned elsewhere in the documentation, but the OP didn't bother to read them. "A gem and two lines" and it worked, so he expected it to work forever. That's not how engineers usually work. Most of the time, they over-engineer, not the other way around! They research the hell out of any new technology they want to use. I'm definitely less talented than OP and others on HN, but even I know a hell of a lot about Redis, MongoDB and CouchB, and I haven't even started to write a line of code.

And anyone who has read more than an introduction to mongo knows that you SHOULD use getLastError to be safe. If you do that, no data will be dropped.