One weekend, I had to cut down a tree in our yard. So I got out the chainsaw and went to work. It was very slow going, a little bit of saw-dust and a lot of smoke everywhere. My chainsaw wasn’t cutting well at all. The teeth on the chainsaw blade were not sharp at all, and so all the chain was really doing was burning through the dead wood. At this point I’ve probably spend 15 to 20 minutes on the tree, and I have one cut about an inch and a half deep, and another one maybe an inch deep.I went ahead and changed the blade on the saw, got it all set up properly, and went back to the tree. This time, with the sharp chainsaw, the tree was down within 5 minutes.Using the dull blade, I still would have been able to fell the tree; it just would have taken me hours, and much wear and tear on my tools (the chain would have been ruined, and all that heat probably would also have ruined the bar too). However, when I spent the time to use the right tool for the job, and to properly maintain that tool, the job was so much easier.
We all end up using the wrong tools for some jobs. Sometimes we just don’t have the right tools around, so we improvise. Sometimes we hear about this cool new tool and somehow we are convinced it will fix all our problems. We are currently dealing with one such tool. For one of our processes, we are using MongoDB basically as a read/write heavy cache. If you know much about MongoDB, you probably know that this is exactly the type of problem MongoDB should not be used for. Why did we use it? At the time that we built the process, it was the cool new kid on the block, and some developer or two wanted to play with it. So we went ahead and put it in prod. Why not?
Now fast forward a few years, and guess what, MongoDB doesn’t perform very well for this operation. Increased load on the system is pushing Mongo harder than we ever really anticipated for. Part of our performance issues are simply that we haven’t really done much any maintenance on MongoDB since we put it in. This is used in kind of an obscure part of the system that nobody really cares about, until it breaks. Most of our problem however, is just that MongoDB is not the right tool for the job. The operations are read/write heavy. We have well-structured relational data. We have well-structured queries. Does any of that scream NoSQL? However, instead of just fixing the tooling, we just keep putting on small, quick fixes that hide the issue for a couple of weeks, or even a month, and revisit the exact same thing again and again.Why does it always seem so hard to switch out the wrong tool for the right one? When you’re in the middle of cutting down a tree, you don’t want to run to the store to buy a new chainsaw blade. Even though you know that the time it takes you to run to the store, get the new thing, and install it will end up taking less time than working with what you already have. If it is already (sometimes) working in production, there is so much fear of changing the tool, even if everybody agrees that the tool isn’t the best fit, that it takes a great force to move to the right tool.
Originally Posted on my Blogger site June of 2017