Re: [mongodb-user] Mongodb "Shortcomings"

[Sam Millman]

Infact if you look about 8 posts down you will see a thread entitled "Some Serious Accusations". If you look at that you will get an idea.

I will add one thing. A lot of these posts punch MongoDB for being young and new and expect it to be a MySQL product in a stupid timeframe.

On 27 September 2012 09:50, sol <s...@tachium.org> wrote:

Hi there,

I'm using MongoDB quite a lot and we're also using it in our company.

Recently someone at the company came across these articles:

http://blog.engineering.kiip.me/post/20988881092/a-year-with-mongodb

http://longtermlaziness.wordpress.com/2012/08/

While I know some of the points, I don't know others, and there is also not too much context especially in the first post.

I would like to ask if these articles, or the particular (stated) problems in them, are discussed somewhere, if there are responses or anything.

I do not want to start a flame war or anything like that, nor put MongoDB into bad light, I use it myself a lot.

I am asking solely out of curiosity because I need to evaluate these things in context of our company.

Thanks in advance

--
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To post to this group, send email to mongod...@googlegroups.com
To unsubscribe from this group, send email to
mongodb-user...@googlegroups.com
See also the IRC channel -- freenode.net#mongodb

[harrym]

Many of the issues brought up in posts like these stem from the user trying to use MongoDB as a direct replacement for an RDBMS, without properly understanding how MongoDB works. Some of the complaints are certainly valid, such as the issues caused by the write lock, but 10gen seem be be making great progress on these with every release. For example, Mongo 2.2 replaces the global write lock with a database-level write lock, and I hear they're planning on doing far more granular locking in future releases.

[David K Storrs]

To address their points specifically:

http://blog.engineering.kiip.me/post/20988881092/a-year-with-mongodb

- Non-Counting B-trees => Legitimate issue.  No indication that it is being worked on, AFAIK.

- Uncompressed field names => Definitely an annoyance and should be fixed, but not an issue for small data sets.  Can be a very significant issue (in terms of storage costs) as you get into the >10M+ row range.  Their proposed solution would be ideal.  No indication that it is being worked on, AFAIK.

- Global write lock => A valid concern, but the impact of this was overstated even before 2.0 came out.  Once 2.0 was here, lock-release on page fault behavior was significantly improved.  With 2.2 this has been improved yet again and the locking level has been moved to a per-database model.  In 2.4, this will likely be moved to a per-collection level, but that's not official yet.

- Safe off by default => Very much a matter of opinion; personally, I like having the flexibility to do it either way (unlike with a traditional RDBMS).  For a financial application, yes this is nuts.  For a rapid logging application, it makes perfect sense.  The most I would say is that perhaps it could be more clearly labeled, but even then I think it's fine if you read the docs.  The docs are pretty clear that inserts are optimized for speed in a "fire and forget" mode, and that if what you're looking for is total durability, you should use getLastError or 'safe => 1'.

- Offline table compaction => A bit of a quibble with this:  if you delete data from the table, new inserts will be written into the resulting free blocks, meaning your data size shouldn't grow.  But, in general, yes, this is accurate, and is an enormous problem.  In my opinion, possibly Mongo's biggest failing.

- Secondaries do not keep hot data in RAM => I think their example is a bit of a strawman.  Running your multi-gig-in-the-working-set database off of EBS (which is notoriously slow and inappropriate for DB usage) would make no sense.  Also, failures happen infrequently enough (in my experience) that this is not a huge issue.  As to the stated issue, I don't have personal knowledge of whether it's accurate or not.

http://longtermlaziness.wordpress.com/2012/08/

This article is less clearly organized and harder to dig the specific objections out of; also, some of them are redundant with the above, so I'm probably not going to respond to everything.  Here are the ones I see:

- Schema-free sign causes maintenance headaches => Ok.  So don't use NoSQL.  This isn't a MongoDB issue.

- No joins => Ok.  So don't use NoSQL.  This isn't a MongoDB issue.

- Can't use dots in object keys => Use URL encoding.  RDMS's also have reserved words.

- Javascript not up to modern standards => There is a legitimate concern here, but not the one he raises; I've had no problems writing any JS function I needed.  The issue I HAVE had is that there is only one JS thread to run (e.g.) all map-reduce jobs.

Speaking of map-reduce, one issue that neither of them raised:  when you do a map-reduce, temporary collections are created.  These collections are not removed until the connection that did the MR job ends.  If you are MRing over a large collection and emiting a lot of records, this can impact disk usage significantly.

That said, the aggregation framework in 2.2 drastically reduces the occasions when you need MR.

Hope this helps,

Dave

[Sam Millman]

We should really make a page somewhere that we can just link to with all the info on so whenever someone posts this type of question we can just link it.

--