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

91–100 of 194 posts

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

#91

Post by frederico »

pooriaazimi wrote: post #73
rjzzleep wrote: post #49

i welcome the post. even though most of my stuff runs on 64bit, i actually do have a few 32 bit systems here and there. I never knew. Because as the op mentions it's not written anywhere _obvious_. another thing I didn't realize was that because of the memory mapped systems which i guess is fine performancewise it's hard to estimate memory usage on a machine. from what I understand there is no possibility to limit th…

> it's not written anywhere _obvious_. Isn't http://www.mongodb.org/downloads an obvious place?

Looks pretty obvious to me; however I am a novice when it comes to RTFM..

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

#93

Post by agscala »

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.

Oh, I thought the original article was saying that MongoDB itself would not send an error down if it was "full".

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

#94

Post by makmanalp »

bingaling wrote: post #78
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…

Can /dev/null + /bin/yes be considered a database?

tongue-in-cheek: http://www.youtube.com/watch?v=b2F-DItXtZs

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

#95

Post by Andrex »

Interesting you switched to Couch. I was hesitant to recommend it reading the post because I feared you were turned off JSON stores entirely, glad to hear that's not the case.

In general it feels like Couch actually takes storing data seriously. Append-only and whatnot. It's slower and a little bulkier than Mongo, but it does the important things right (1.0 bugs notwithstanding.)

I'd love a follow-up blog post on your experience with Couch.

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

#96

Post by wglb »

eduardordm wrote: post #90
flatline3 wrote: post #59

Earlier quoted context omitted.

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

It actually happens in some scenarios. Let's say, outside of the tech world: When you send a post card (cheap ones) to a friend, you won't receive any delivery confirmation. You just send it and go do whatever you please, believing the post card will be there. If the envelope don't get there, no biggies, you will send another on your next trip anyways. No hurt feelings. But, let's say you need to send me a check. You…

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

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

#97

Post by louischatriot »

I agree with posts stating that you should read the docs before using a tool you don't know. But I also think that these two really important points should be mentioned in the Getting Started guide, in bold: - The 32bit 2GB limitation (seriously when I started with MongoDB I wasn't expecting this!) - The fire-and-forget policy

These are really not points to be discovered in chapter whatever of the docs.

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

#98

Post by chimeracoder »

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 'insert' default to synchronous? Why shouldn't we instead have a sync_insert function instead? The only reason is that you're assuming familiarity for people coming from SQL/synchronous-oriented DBMS, but why should they be forced into an awkward design just because it's what people are familiar with from other DBMS?

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

#99

Post by meshko »

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.

Because the whole point of NoSQL movement is that you are storing Facebook "like"s and in fact would be glad if some of them get lost.

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

#100

Post by omni »

eduardordm wrote: post #83
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…

"I'm just struggling to imagine being willing to lose some amount of data purely for the sake of performance...". A foursquare check-in database could be an example where performance is actually way more valuable than consistency. (I have no idea what database they use)

They use Mongo. http://www.10gen.com/customers/foursquare
Post reply on HN