I’ve always loved the story about the way Ford build his automotive imperium. It was during the Industrial Revolution when it became more and more important to automate certain things in the way an automobile was made, that gave Ford a big advantage over his competitors. Ford knew that creating a car faster and more efficient would give him a huge advantage. Developing an assembly line as well as a selling method (you could buy a Model T in every color as long as it was black :D). If you want to know more on how Ford changed the automotive industry (and much more) there is plenty of information to find on the interwebs.
In the next couple of posts, I would like to dive a little deeper into why databases and keeping your databases healthy in the digital revolution is so darn important. So please, let’s dive into the first puzzle of this important part of the Database Infrastructure we call storage.
As I already said I really love the story of Ford and the way he changed the world forever. We however live in a revolution that is changing the world even faster and it seems (and seems is the right word if you ask me) to focus on software instead of hardware. Given that the Digital Revolution is still relatively young, we must be like Henry and think like pioneers in this new space.
In the database realm, it seems to be very hard to know what the performance, or lack thereof, is and where we should look to solve the problems at hand. In a lot of cases it is almost automatic to blame it all on the storage, as the title already implied, but knowledge is power as my friend SpongeBob has known for so long…
Storage is an important part of the Database world, and with constantly changing and evolving hardware technology, we can squeeze more and more performance out of our databases. That being said, there is always a bottleneck. Off course it could be that storage is the bottleneck we’re looking for when our databases aren’t performing like we thought they would. But in the end, we need to know what the bottleneck is and how we can fix that. Even more important is the ability to analyse and monitor the environment in a way that we can predict and modify it in such a way that the performance of the database can be adjusted as needed even before problems occur.
Henry Ford was looking for ways to fine tune the way a car was built, and ultimately developied an assembly line for that purpose. By doing so, he cut the time it took to build a car with 12 hours to a whooping two and half hours beating his competitors big time. In a database world speed is important, but blaming storage and focussing on solving only part of the database puzzle is short sighted. Knowing your infrastructure and being able to tweak and solve problems before they start messing with your performance is where it all start. Or is do think otherwise? Please let me know if I forgot something, or got it all wrong. Would love to start the discussion and see you on the next post
Source: solarwinds GEEK SPEAK