4 ms·

tl;dr We LOVED MongoDB (http://www.zopyx.de/blog/plone-using-highcharts-and-jqgrid http://www.zopyx.de/blog/plone-using-highcharts-and-jqgrid) but we got burnt

by hmans 14y ago

tl;dr We LOVED MongoDB (http://www.zopyx.de/blog/plone-using-highcharts-and-jqgrid http://www.zopyx.de/blog/plone-using-highcharts-and-jqgrid) but we got burnt so it's USELESS and BRAINDEAD!

paulsutter 14y ago
That's the common pattern. MongoDB is easy and convenient when you first start using it, but you hit the limitations pretty quickly. I had the same experience.
- orthecreedence 14y ago
  I really think if they had document-level locking, it would be a much more successful DB. 10gen's answer to this is "just shard!!1" except that sharding in Mongo really isn't as easy as they make it out to be...not to mention what database makes you shard just so you can support more than a few hundred writes per second? Maybe this has improved a bunch since I got burned by it on v1.6, but I believe it's very misleading to claim scalability of a product that has a global write lock. Being forced to shard when you reach the small-medium size is just sad. All other aspects about it I love, though. It really makes development and deployment so much faster. Replica sets aren't perfect, but setting up MySQL replication w/ automatic failover on three or more machines is a recipe for disaster unless you have a DBA to sit there and baby sit it full-time.
  - mathias_10gen 14y ago
    Locking in particular has improved substantially since 1.6. For example, 2.0 introduced yielding in some cases where MongoDB would go to disk rather than page-faulting with the lock held[1]. This has been extended and improved for 2.2, along with increasing the granularity of the lock from process-wide to per-db. There are plans to increase the granularity further in future releases. [1] To see an example of the difference this makes see http://blog.pythonisito.com/2011/12/mongodbs-write-lock.html http://blog.pythonisito.com/2011/12/mongodbs-write-lock.html

by hmans 14y ago

tl;dr We LOVED MongoDB (http://www.zopyx.de/blog/plone-using-highcharts-and-jqgrid http://www.zopyx.de/blog/plone-using-highcharts-and-jqgrid) but we got burnt so it's USELESS and BRAINDEAD!

paulsutter 14y ago

That's the common pattern. MongoDB is easy and convenient when you first start using it, but you hit the limitations pretty quickly. I had the same experience.

orthecreedence 14y ago
I really think if they had document-level locking, it would be a much more successful DB. 10gen's answer to this is "just shard!!1" except that sharding in Mongo really isn't as easy as they make it out to be...not to mention what database makes you shard just so you can support more than a few hundred writes per second? Maybe this has improved a bunch since I got burned by it on v1.6, but I believe it's very misleading to claim scalability of a product that has a global write lock. Being forced to shard when you reach the small-medium size is just sad. All other aspects about it I love, though. It really makes development and deployment so much faster. Replica sets aren't perfect, but setting up MySQL replication w/ automatic failover on three or more machines is a recipe for disaster unless you have a DBA to sit there and baby sit it full-time.
- mathias_10gen 14y ago
  Locking in particular has improved substantially since 1.6. For example, 2.0 introduced yielding in some cases where MongoDB would go to disk rather than page-faulting with the lock held[1]. This has been extended and improved for 2.2, along with increasing the granularity of the lock from process-wide to per-db. There are plans to increase the granularity further in future releases. [1] To see an example of the difference this makes see http://blog.pythonisito.com/2011/12/mongodbs-write-lock.html http://blog.pythonisito.com/2011/12/mongodbs-write-lock.html