|
| Featured Contents |
| Question of the Day |
|
| The Voice of the DBA |
Ten Database Commandments I love the Notorious B.I.G. His music isn't for everyone, but I enjoy it. This piece takes one of his songs (NSFW - Ten Crack Commandments) and applies the list to databases. Each item from the song is listed, along with the way it might be changed for database work. The list is from Ottertune, which is a service designed to help you optimize your use of AWS RDS and Aurora databases, with AI. If you believe their hype, their service will get better performance and lower costs for you. In any case, with regard to databases, I suspect that the author is having some fun with the rules, and a few of them made me smile. They are cloud-related, but a few will apply to any environment. The first one is about budgets, noting you should not disclose your budget, which is in general a good rule whenever you are buying something. Don't disclose information, and someone working for a vendor of tools, I think that most budget conversations aren't something technical people should worry about. Decide what value you get from some tool/service/process/etc. and if there are time savings. Then let someone else decide if the ROI is worth the cost. Rule 2 is a stretch, but I do think that looking at new tools can be helpful. The caveat here is that many people, don't often learn enough about existing tools to understand if they will solve issues. There are a lot of things you can do with many tools, so don't just look for some magical new tool. Learn to use your tools well, and if you want to try a new one, keep in mind you will need to invest some time both learning about it and practicing some skills before you really know if it's helpful. The other thing to remember is every new tool increases the bar for new staff. Try to limit the number of tools you use to those you need. Security is important and rule 3 is remembering not to give out more permissions than needed, especially to developers. I love this quote: "You don’t want randos at your organization logging in and running queries that they found on Stack Overflow." A number of the other rules have to do with performance, which is certainly Ottertune's business, but these are good basic practices that I see organizations not following. Too often management wants to save money and technical people make decisions that compromise performance. Lots of people overload systems, and then they can't handle the workload well. I get that many CFOs and others want to see high CPU usage, which means they're using the resources they pay for, but databases can be very bursty with resource usage. At the same time, you don't want to over-provision resources because you are scared. Learn to find a balance that doesn't waste money, but handles your workload well. Perhaps one of the best things about the cloud is that if we do make bad decisions, we can often provision more resources. It can take time to move to a new tier of service, so don't expect instance response up or down, but if you need to double the CPUs for month-end processing, you can likely plan for the time to scale up your database instance and then scale down again when all the work is complete. It's a fun article, and if you're looking for some fun Notorious B.I.G.-related database content, grab a cup of coffee when you need a break and a smile. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums |
|
| Featured Contents |
