4 ms·
The article doesn't give any insight into the cause of the performance issue because they coudn't work out what that cause was: In another instance we noticed
by chris_wot 6y ago
The article doesn't give any insight into the cause of the performance issue because they coudn't work out what that cause was:
In another instance we noticed degraded performance of our applications and managed to trace it to our MongoDB cluster. However, upon further inspection we were unable to find the actual cause of the problem. No matter what metrics we installed, tools we used or commands we ran we couldn’t find the cause.
- menzoic 6y agoTrue, but it seems like they blamed it on MongoDB just being bad without justification and proposed Postgres as the solution.
- chris_wot 6y agoNo, it seems like the diagnostics tools they were provided didn't help them get to the bottom of the very bad performance issue they were actually having with MongoDB, and then they proposed Postgres as the solution. As most companies do, eventually.
- menzoic 6y agoWithout knowing the context it's impossible to say if it was user error or application error. I don't see it as a fair write up.
- chris_wot 6y agoIt's a fair write up in that they were unable to diagnose the actual problem with MongoDB. Which leads to one of the problems with the product - it is hard to know what is causing the issue when it has problems.
- wilco_vd 6y agoHey, I was one of the developers on the team at that time. It's been fun re-reading that write up. I learned a lot since then, and I think the whole industry has learned a lot regarding NoSQL databases, their strengths and weaknesses and how to deal with those in your applications. You are correct that the biggest issue was that we couldn't diagnose problems when they occurred, and therefore we couldn't learn. Some of those problems were for sure "user error", others were absolutely problems with MongoDB at the time. It was a "young" database back in 2015.