Poor performance from your MongoDB database? Look at the shard key
gobitcan.com
gobitcan.com
So I think it's super important to de-risk MongoDB as quickly as possible and then move on with life. If you can use bare metal, just switch to using SSDs or even FusionIO cards. The new AWS SSD instance types should also be ok. Pay the money you need to service providers like AWS, Rackspace or Softlayer etc. to get it done.
In a best-case situation, you can keep upgrading every 12-18 months and rely on Moore's law to allow your MongoDB machines to scale with your growth. But even in a bad situation where your database is growing in size too fast, this vertical scaling strategy should still give you 6-12 months of breathing room, to allow your dev team to cleanly switch over to a different database.
I see a lot of teams starting out with MongoDB, but the smart ones know it's a big risk and once they find market fit, their first major initiative is to switch over the database backend to use something like Cassandra + Mysql.
Not literally immutable, because you can change it, but changing it is more difficult and more perilous than starting from scratch.
Wasn't the point of MongoDB was supposed to be that it's all flexible and schemaless? You might ask that. You might not get an answer. Like I said, I never use MongoDB as a distributed system anymore.
Has anyone ever built a non trivial application on MongoDB and been happy with their decision, say, 1 year later? If so, what kind of use case was it? I am genuinely curious.
The impression I've received is that Mongo is ridiculously easy to get started with but the flaws become more and more of a hindrance over time, eventually making certain types of application features virtually impossible to implement.
Slide 4 shows eBay's MongoDB cluster size: Hundreds of nodes, > 50TB, > 2 billion ops/day
http://www.mongodb.com/presentations/storing-ebays-media-met...
Here's another deck from 2012: http://www.slideshare.net/mongodb/mongodb-at-ebay