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
> 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 mongodb-user@googlegroups.com
> To unsubscribe from this group, send email to
> mongodb-user+unsubscribe@googlegroups.com
> See also the IRC channel -- freenode.net#mongodb
> 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
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.
> 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
- 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.
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.
> 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
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.
On 27 September 2012 21:40, David K Storrs <da...@channelmeter.com> wrote:
> - 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.
> 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
> On Thursday, September 27, 2012 1:50:31 AM UTC-7, sol 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:
>> 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 mongodb-user@googlegroups.com
> To unsubscribe from this group, send email to
> mongodb-user+unsubscribe@googlegroups.com
> See also the IRC channel -- freenode.net#mongodb
To me it's definitely a matter of aligning people's expectations with the current state of mongodb.
These articles seem to blame mongodb for some shortcomings but all those should already be known and understood when you're choosing a database for your project.
I would blame mongodb (or any product that I choose willingly) for *surprising* behaviour, like unexpected performance issues, bugs, or promises that it fails to keep. So far I've not had any reason to.
It boils down to picking the right tool for the right job! And I feel that with all the new features of the 2.x branches there are more and more jobs that mongo can be perfect for. BUT, that shouldn't be a reason for choosing it without understanding its feature set and architecture!
On Thursday, September 27, 2012 11:26:56 PM UTC+2, Sammaye wrote:
> 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.
> On 27 September 2012 21:40, David K Storrs <da...@channelmeter.com<javascript:> > > wrote:
>> - 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.
>> 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
>> On Thursday, September 27, 2012 1:50:31 AM UTC-7, sol 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:
>>> 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<javascript:> >> To unsubscribe from this group, send email to >> mongodb-user...@googlegroups.com <javascript:> >> See also the IRC channel -- freenode.net#mongodb
like someone mentioned before, it reads as they tried to use a NoSQL Database (in this case MongoDB) as a direct substitute for a RDBMS without giving nough thought, what the differences are. Every NoSQL solution has its use cases and when you need use joins and such stuff, normally NoSQL just isn't the proper tool for your needs.
Let me come to some of their points in detail:
Only 400 writes per second due to global lock? Well, don't know what they did there, but even on my first test machine (MBP with only 8GB RAM ^^ ) I had a small DB with just 2.5m log entries and I used those to filter some data using a small MR and wrote them back into a second MonoDB collection. Having 3.5k writes per second on this machine wasn't that bad, heh? I could improve this performance with two proper servers using a sharded system and ended up with about 8k inserts per second. So, if you know about the write lock issue, which I have to admit is an issue, but it is being worked on (v2.2 -> database model, etc) and you know about MongoDBs concept of using sharded systems for optimized writes performance, why not using it? It was mentioned in the article, that they didn't want to scale in this way. Well, why choosing a technology and than not using it in the way it should be used? It's like developing in Java and than complaining about the idea of objects.
No counting B-Trees: Ok, that's definitely a valid point here. But giving in mind, that you should know that before you start using a technology, you should be able to learn how to navigate your way around this issue. Personally I was lucky so far, not to get into any big troubles regarding this.
Uncompressed field names: Well, giving the first thought this seems to be super annoying, but frankly it's noting that you should bothered by, because you shouldn't write directly to the database, but always use an abstraction level.
Set safe off: Hmm, personally I think this is a matter of opinion and comes to the point for which use case you choose MongoDB. Yes, it can be painful, but they tell you about this in every talk and it can be read in the docs. Again it seems that they used MongoDB without enough R&D to learn, how MongoDB works and more important, why it does things like it does.
There are more points on both articles, which in my opinion all come to the same things: Do proper evaluation work! Understand how and why things are done in their way! Use the proper tool for the right problem! Don't use any NoSQL solution, just because it's hip! Train your staff properly!
Lately I have seen so many companies shifting to NoSQL solutions and when you ask the responsible person why they did that, most times it's because it's new and fast. Giving no thought, that it works differently, you have to start thinking in a different way as when using traditional RDBMS. there is no use to move to a complete new technology and no one of your high skilled MySQL gurus is able to work with the new stuff, because you did not train them.
MongoDB as well as several other NoSQL solutions have their pros and cons and their special use cases. Personally I choose MongoDB for being my favorite for the following reasons: It covers more use cases than most of the other NoSQL databases I looked at. The community is getting bigger and bigger and always it super helpful (10Gen is doing a great job with their community management here). The payed support by 10Gen is amazing! (Even non payed support by the developers when meeting them at conferences or twitter was super helpful!)
For your initial question: Davids post covers even more detailed points of the articles and I can second them completely. This should give you enough material for your evaluation I think. When it comes to the point of using MongoDB in your company, try to have the five points in mind I mentioned earlier. A good tip is: give one of the MongoDB sales persons a call. They hooked me up with one of their developers and we had an hourly talk about what our plans are, why I would like to start using MongoDB and for which problem. This call was more than helpful. I over thought some of my ideas after that and in the end it was the outcome of this call what convinced my boss using MongoDB for SOME of our stuff.
> 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
> 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
