Re: [mongodb-user] Some Serious Accusation

[Octavian Covalschi]

You may be interested in reading this too

http://blog.serverdensity.com/does-everyone-hate-mongodb/ 

On Tue, Sep 25, 2012 at 9:51 AM, grant li <goldf...@gmail.com> wrote:

Hi,

  We are a team trying to use mongoDB. But we found this article saying several severe issues they encountered when using Mongo. They eventually turned away from Mongo.

  Can someone explain if these drawbacks are true? What can be done for each of the drawbacks? Is mongo reliable?

http://caffeinbean.wordpress.com/2012/07/29/reallife-experience-with-mongodb-and-why-we-are-dumping-it/  

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

[Octavian Covalschi]

I cannot speak about mongodb's source code, but I can truly say I don't care much, as long it works as expected and  issues are fixed pretty quickly.

I honestly don't understand why people are complaining about memory and disk space usage. Does anyone complain on fuel economy on a 500 hp car ? I doubt it. It's the law of nature, you gain something, but most likely you'll lose somewhere else... it's just up to you if the gain outweighs lost. I'm sure with time this will be improved, but I don't see much problems with that since memory is pretty cheap at the moment. Is there a mongodb fork that does the same job with much less memory usage?

If postgresql was running fine for years, why bother replacing it in 1st place? Mongodb is a tool that doesn't solve all the problems, you use it where it makes sense.

I do hope I will not change my mind once I'll start using mongodb in more critical projects. 

On Wed, Sep 26, 2012 at 10:34 AM, Maciej Gajewski <maciej.g...@gmail.com> wrote:

Mongo is nice product and occupies unique niche on the market, but I wouldn't use it for mission-critical production data.

I use Mongo a lot to store and analyze some auxiliary, expendable data, and it works well. It's nice in small deployments and in prototyping, but the issues are real, serious, and - the most grave accusation - they probably never going to be fixed!

Let me elaborate.

1. Mongo will use unbeliveable amounts of disk space and memory. When we replaced our postgresdb, that was running happily for years alongside other apps on some server in the corner of the data-centre, it was all fine initially, but after 100M or so documents we had to migrate it to new box with hundreds TB of disk and tenths GB of RAM. Hidden, unexpected cost.

And I don't think this is going to be fixed, because of the products architecture - it is simplistic. It uses the same data format (BSON) everywhere: from client driver, through the network communication, db internals all the way down to the disk. Sure, it makes things simpler and sometimes faster, but it makes replacing and redeveloping product components impossible; you can not add compression to the on-disk or on-the wire format when you are mapping the data directly into memory and use as your internal data structure.

2. Mongo is haunted with gazillion of tiny problems which you may miss or ignore during the evaluation phase. You may fall in love with all the nice features, and then wake up dying a dead by thousand cuts; These issues are: inconsistent API, difficulties with running server-side code, terrible performance and concurrency issues (2.2 improves things only slightly), problems with compiling and using C++ driver, reliability issues etc.

And I don't thing they are going to be fixed anytime soon as well. If you inspect Mongo's source code, you'll understand; It's poor craftsmanship all over. It's so bad that you would have to don protective goggles to save your eyeballs from imminent cancer. The code is really that bad. And I can't see any major architectural improvements coming into new versions; only new features and bug fixes.

The sad thing is that 10GEN management doesn't seem to be concerned about it. I've been attending one if the recent Mongo conferences and seen a "tour of the source code" by one of the directors. He was showing off the code proudly. Younger attendees were delighted, more experienced ones (including me) couldn't believe their eyes. Seriously.

Summary:

Mongo is nice and useful toy, but don't make your business depend on it. You need to remember that despite being open-source project, it's a commercial product with significant marketing budget. Take everything you read with grain of salt (including my rant here :) ) and test mongo thoroughly in all scenarios, under heavy load etc before using it.

[Rob Moore]

Here is my take based on my usage.  Your mileage may vary.

* Slow writes:
I guess they could be slow but I think the real point is that for each request you can decide between speed and durability.  For my current project we almost always choose speed and I can assure you there are a lot of products that we have tried and MongoDB is by far the fastest and most flexible.

* Queryability:
Yes you need an index to quickly retrieve data and sometimes getting the right index is non-obvious as this thread shows:
   https://groups.google.com/d/topic/mongodb-user/wcUyBdxFFXc/discussion
Not sure if the author expected MongoDB to be a magic bullet or defy the laws of computer science: O(N) is still a long time if N is big.

* Lack of Compression
I can see that having the server compress documents might be a nice option for some workloads but the overhead would be a deal breaker for others.  It would make indexing more interesting at a minimum and full table scans perform even worse. Disk is fairly cheap these days and there is nothing stopping you from compressing documents before they go into MongoDB if you really needed to save the space (I have done something similar to reduce the "serialization overhead").  Compressing across documents I would think is a complexity non-starter.

* Memory Monster
Yes it is.

* Lack of Tools
I think MongoDB is much more in the Unix camp here of offering simple tools that do one thing well instead of a swiss army knife monolith.  If you like the Unix model your fine (I do).  If you want the swiss army knife I think you just found a niche you could fill.

* Undependable Tools.
Not my experience.  I have found most of the tools to just work.  I have found MongoDB to be very good at finding weaknesses in infrastructure and exposing them.  Is it MongoDB's fault my SAN is a piece of...? 

* Huge storage requirements.
This is a big one.  For my primary workload, insert/update/delete, the disk used just keeps growing until we do a repair for the database.  It is a world better in 2.2 with the power-of-2 allocator.

* Operations.
I've had the exact opposite experience.  If you use the redundancy MongoDB provides and have your monitoring in place to detect and fix faults the cluster can run itself for weeks or months without intervention.  If you have not done the work up front to get everything in place then your operations people won't be sleeping for more than a few weeks.

Rob.