| > I have to say that I did not experience a single data loss that was a result of the database misbehaving. Okay, but numerous people have experienced data loss using MongoDB. You can spend 10 minutes on Twitter and find someone talking about it. > Memory leaks weren't a huge issue for us as well. After stabilizing the setup I have to say it was basically a fire and forget part of the stack for us. "After stabilizing the setup"? So basically you worked around MongoDB's stability problems instead of choosing a solution that didn't have stability problems? > The role of MongoDB was to act as a fast-insert and aggregation framework for other parts of the system. Sure, but there are other solutions that can do this without MongoDB's issues (i.e. Cassandra). > After a while, the setup became to expensive to run, at this point we turned it off for a cheaper solution, but in terms of functionality, it functioned pretty well. Sure, you can build something stable on sand, but it's going to be a lot harder than just building on a solid foundation. |
Never said people didn't.
> "After stabilizing the setup"? So basically you worked around MongoDB's stability problems instead of choosing a solution that didn't have stability problems?
No, I haven't worked around the limitations, after tweaking heap sizes, machine sizes and disk speeds the setup was very stable.
> Sure, but there are other solutions that can do this without MongoDB's issues (i.e. Cassandra).
Again, I DO NOT disagree, there are other solutions and today we are running a completely different setup to replace the same component.
> Sure, you can build something stable on sand, but it's going to be a lot harder than just building on a solid foundation.
I'm trying to ignore the snarky/attacking nature of your comment. Not sure if this is addressable.