Does everyone hate MongoDB? • Hacker News Board

Re: Does everyone hate MongoDB?

#71

Post by gaius » Tue, Sep 25, 2012, 6:38 PM UTC

werkshy wrote: post #69

pooriaazimi wrote: post #55

Earlier quoted context omitted.

I haven't got a 32 bit version of Mongo, but people pointed out in the other thread that 32-bit version of mongod displays a little warning every time you start it saying it can handle only 2GB of data. Can you confirm this ( because I don't have the 32-bit version installed )? It still stinks, especially because it "silently failed after hitting the threshold", but I personally would feel better about 10gen if this…

This is true, in the Ubuntu packages this is printed to the default log at /var/log/mongodb/mongodb.log. It is also abundantly clear from the documentation. I struggle to understand how one could deploy a new datastore in production without reading the "getting started" level of documentation or looking in the log at some point. The 2GB 32-bit limit of MongoDB seems like a complete non-issue to me. Wed Sep 19 17:29:2…

The issue is not the limit; it's the silent failure. 32-bit Oracle doesn't do that, it tells you it can't extend the tablespace by raising an exception.

Re: Does everyone hate MongoDB?

#72

Post by diego » Tue, Sep 25, 2012, 6:42 PM UTC

pooriaazimi wrote: post #55

diego wrote: post #43

Earlier quoted context omitted.

I like the concept of MongoDB. My main problem (which perhaps is not totally clear from my post, linked in the article) is that there are certain historical conventions about what a database should be. In particular, a database will not have the following default behavior: - return from a write call silently, when the data wasn't written and will not be. If you are going to break conventions on a multi-decade traditi…

I haven't got a 32 bit version of Mongo, but people pointed out in the other thread that 32-bit version of mongod displays a little warning every time you start it saying it can handle only 2GB of data. Can you confirm this ( because I don't have the 32-bit version installed )? It still stinks, especially because it "silently failed after hitting the threshold", but I personally would feel better about 10gen if this…

Confirmed, like others below. Installed on Ubuntu via APT.

~$ sudo service mongodb start

mongodb start/running, process 7680

Re: Does everyone hate MongoDB?

#73

Post by lgbr » Tue, Sep 25, 2012, 6:44 PM UTC

diego wrote: post #43

jandrewrogers wrote: post #20

I think a lot of the "hating" is a side effect of MongoDB being consistently oversold in terms of its capabilities and architecture. Many people who are not experts on databases discover this the hard way later. If the claims about it were qualified a little better and the limitations acknowledged more openly by its proponents it would help to mitigate this outcome. I am indifferent to MongoDB but I do caution people…

I like the concept of MongoDB. My main problem (which perhaps is not totally clear from my post, linked in the article) is that there are certain historical conventions about what a database should be. In particular, a database will not have the following default behavior: - return from a write call silently, when the data wasn't written and will not be. If you are going to break conventions on a multi-decade traditi…

> In particular, a database will not have the following default behavior:

> - return from a write call silently, when the data wasn't written and will not be

There isn't some defined set of rules for how a database should operate. This attitude implies that an asynchronous database should never ever exist. If that's the case, how could I ever use a database for HTTP logging? I can't have every single HTTP request block on a database write, that's absurd. HTTP logging is impossible with MySQL or PostgreSQL for exactly this reason.

Re: Does everyone hate MongoDB?

#74

Post by gaius » Tue, Sep 25, 2012, 6:44 PM UTC

pjungwir wrote: post #40

Zak wrote: post #31

My problems were to do with data-loss and unrecoverable corruption. I didn't write a blog-rant, but maybe I should have. I have since learned that I could have changed some configuration options to make MongoDB less likely to corrupt and/or lose data. I'm still wary though - the fact that the default configuration was prone to unrecoverable data loss suggests that any time I use MongoDB, I must carefully research the…

It's not just that the defaults are dangerous, but that if you change the default, you give up much of the performance benefit of choosing Mongo in the first place.

If you don't care whether a write succeeds or not then you can get even more performance by not making the call to the DB in the first place!

Re: Does everyone hate MongoDB?

#75

Post by pooriaazimi » Tue, Sep 25, 2012, 6:45 PM UTC

gaius wrote: post #71

werkshy wrote: post #69

Earlier quoted context omitted.

This is true, in the Ubuntu packages this is printed to the default log at /var/log/mongodb/mongodb.log. It is also abundantly clear from the documentation. I struggle to understand how one could deploy a new datastore in production without reading the "getting started" level of documentation or looking in the log at some point. The 2GB 32-bit limit of MongoDB seems like a complete non-issue to me. Wed Sep 19 17:29:2…

The issue is not the limit; it's the silent failure. 32-bit Oracle doesn't do that, it tells you it can't extend the tablespace by raising an exception.

I'm not trying to defend Mongo, but the reason it doesn't tell you is because you didn't ask for it. If you care about the data (i.e. it's not a log or something that's not very important), you ought to always use "getLastError" to see if your data was actually stored or not (some drivers, like mongoose (for Node.js), just let you specify a simple flag ("safe:true") that does this automatically).

A shitty default, no doubt. But it can be changed easily. And "most" drivers offer that. And you usually connect to MongoDB using a driver.

http://www.mongodb.org/display/DOCS/getLastError+Command

Re: Does everyone hate MongoDB?

#76

Post by saurik » Tue, Sep 25, 2012, 6:47 PM UTC

lgbr wrote: post #73

diego wrote: post #43

Earlier quoted context omitted.

I like the concept of MongoDB. My main problem (which perhaps is not totally clear from my post, linked in the article) is that there are certain historical conventions about what a database should be. In particular, a database will not have the following default behavior: - return from a write call silently, when the data wasn't written and will not be. If you are going to break conventions on a multi-decade traditi…

> In particular, a database will not have the following default behavior: > - return from a write call silently, when the data wasn't written and will not be There isn't some defined set of rules for how a database should operate. This attitude implies that an asynchronous database should never ever exist. If that's the case, how could I ever use a database for HTTP logging? I can't have every single HTTP request blo…

PostgreSQL allows you to select this behavior on a per-transaction basis using the synchronous_commit variable: the default (which what we are discussing here) is "don't return until the data hits disk", but you can set it as strict as "don't return until the data has not only hit a local disk but has been acknowledged by a standby slave" or as lax as "return immediately: sync my data when you get around to it, it isn't important"; (so, don't claim something is impossible with someone's tool without first looking into it deeply).

Re: Does everyone hate MongoDB?

#77

Post by diego » Tue, Sep 25, 2012, 6:48 PM UTC

werkshy wrote: post #69

pooriaazimi wrote: post #55

Earlier quoted context omitted.

I haven't got a 32 bit version of Mongo, but people pointed out in the other thread that 32-bit version of mongod displays a little warning every time you start it saying it can handle only 2GB of data. Can you confirm this ( because I don't have the 32-bit version installed )? It still stinks, especially because it "silently failed after hitting the threshold", but I personally would feel better about 10gen if this…

This is true, in the Ubuntu packages this is printed to the default log at /var/log/mongodb/mongodb.log. It is also abundantly clear from the documentation. I struggle to understand how one could deploy a new datastore in production without reading the "getting started" level of documentation or looking in the log at some point. The 2GB 32-bit limit of MongoDB seems like a complete non-issue to me. Wed Sep 19 17:29:2…

Normally people look at logs when things go wrong. Do you look at the log anytime something starts successfully and seems to be working? You must spend lots of time looking at logs.

This is a message that MUST be displayed on the console when you install the server for the first time. It's too important.

Also, you learn a tool before going into production. I never went into "production" with mongodb. All I did was experiment with a toy project. I never needed to look at the log.

Re: Does everyone hate MongoDB?

#78

Post by lgbr » Tue, Sep 25, 2012, 7:01 PM UTC

saurik wrote: post #76

lgbr wrote: post #73

Earlier quoted context omitted.

> In particular, a database will not have the following default behavior: > - return from a write call silently, when the data wasn't written and will not be There isn't some defined set of rules for how a database should operate. This attitude implies that an asynchronous database should never ever exist. If that's the case, how could I ever use a database for HTTP logging? I can't have every single HTTP request blo…

PostgreSQL allows you to select this behavior on a per-transaction basis using the synchronous_commit variable: the default (which what we are discussing here) is "don't return until the data hits disk", but you can set it as strict as "don't return until the data has not only hit a local disk but has been acknowledged by a standby slave" or as lax as "return immediately: sync my data when you get around to it, it is…

You're right, that's my fault. You can set synchronous_commit to off, which makes this possible. However, this is a database wide variable, so you can't use this database server for anything else, presumably, if you set synchronous_commit to off.

Re: Does everyone hate MongoDB?

#79

Post by saurik » Tue, Sep 25, 2012, 7:03 PM UTC

lgbr wrote: post #78

saurik wrote: post #76

Earlier quoted context omitted.

PostgreSQL allows you to select this behavior on a per-transaction basis using the synchronous_commit variable: the default (which what we are discussing here) is "don't return until the data hits disk", but you can set it as strict as "don't return until the data has not only hit a local disk but has been acknowledged by a standby slave" or as lax as "return immediately: sync my data when you get around to it, it is…

You're right, that's my fault. You can set synchronous_commit to off, which makes this possible. However, this is a database wide variable, so you can't use this database server for anything else, presumably, if you set synchronous_commit to off.

Again, no: it is per each and every individual transaction. (edit:) To be very clear, this means that a single HTTP log table in a single database could have some requests marked synchronous_commit (as they are to a resource that you charge for, and for which you need accurate logs), while for others it is not set (as you just want the fastest performance).

Re: Does everyone hate MongoDB?

#80

Post by marshray » Tue, Sep 25, 2012, 7:29 PM UTC

jeffdavis wrote: post #58

"Getting your working set in memory is one of the most difficult things to calculate and plan for with MongoDB." I am a little bothered when I see a working set described as though it was a property of the user or workload. A large part of database research has gone into allowing the user or the system to make the working set smaller. An obvious example is an index, which makes the working set smaller if you don't mi…

Isn't one of the defining characteristics of Mongo-like systems that they tend to aggressively favor using RAM to achieve performance? I.e., their strategy is to complete each query as quickly as possible rather than attempt to optimize for fairness of long-running transactions.