4 ms·
The problems with early rev SQL servers were similar (in inconvenience) but, with feedback from users and hard work from developers, they soon moved beyond MVP.
by mtkd 14y ago
The problems with early rev SQL servers were similar (in inconvenience) but, with feedback from users and hard work from developers, they soon moved beyond MVP.
I'm willing to suck up some inconvenience with MongoDB, it's one of the most inspiring technologies of the last decade. Web application persistance feels more like a fully connected limb now.
I can understand the gripes but do urge people to give 10gen some slack and appreciate that what they are building takes time - it's clear that the team are working hard on features driven by community feedback.
- cmer 14y agoIt's more than inconvenience when your whole service is down because some database queries take up to 30 seconds to complete (and often time out), and when replication on some servers is days behind (and some are up to date). We also had to completely flush our data a few times because of some corruption we couldn't recover from. The truth is, MongoDB is awesome if your dataset fits in memory, but if you're in a write-intensive environment with 400-500GB of data, it's just not there yet.
- dmytton 14y agoNot true. We're processing 12TB of data each month with thousands of writes per second and sub-millisecond response times. You simply have to understand how to use MongoDB correctly which isn't difficult with the out of the box settings and by reading some of the documentation. Figuring out your working set is the most difficult part but that doesn't take long to calculate based on understanding the queries you're doing and creating the appropriate indexes. Since you seem to be fairly negative about MongoDB but light on details, perhaps you should write up your experiences so others can learn from what you did wrong.