Click to learn more about author Thomas LaRock.
Historically, databases were like digital filing cabinets, not sources for marketing information and new business opportunities. Today, we gather data at a seemingly manic pace – and as quickly as it’s collected, it’s analyzed and parsed. As the famous saying from a few years back goes, “Data is the new oil.” Whether or not that’s true is in dispute, but one thing is for sure: Data is increasingly a focal point for business.
Modern databases aren’t one-size-fits-all. Each platform has its specific strengths (and weaknesses). And extracting the information and maintaining the database is why database professionals get paid.
Throw Hardware at the Problem
Many of us who spent hours tuning relational databases don’t first think of throwing hardware at a problem. With modern workloads, that’s how to respond: Throw hardware at the problem, and then figure out the code later. Instead of optimizing one query or taking a long look at the data itself, modern systems often benefit from two or three extra nodes.
This change in thinking reflects the difference in how modern databases run. They’re increasingly cloud-native, and the server is no longer a few feet away from the DBA’s desk. Instead, it’s likely with AWS or Azure in a data center. Today’s DBAs must understand how this technology requires a different set of metrics.
As a former colleague of mine used to say, “The names change – the crimes don’t.” In other words, DBAs still work at performance-tuning optimization – the bottlenecks remain the same (memory, CPU, network, disk, locking/blocking), but the terminology differs between platforms.
It takes a certain amount of flexibility to work in this new world, but if you’re an experienced DBA, there’s not much to fear. You already know how to administer a database. It’s just that now there’s a different language to learn, along with different code structures to work with.
Just as you could probably figure out how to order a restaurant meal in Paris without knowing any French, you can figure your way through the database problem in front of you. Of course, visiting Paris involves more than ordering a sandwich. You’ll also need to buckle down and learn a new vocabulary. But remember, the rules haven’t changed. The underlying problems remain the same, even with the cloud. After all, even “serverless” runs on a server somewhere.
Use the Right Tools
No matter what, the modern database itself is doing the same work – but it’s located elsewhere. Certain aspects are no longer under the control of the DBA. In the early days, you could order a new network card. Today, if it’s on a VM in Azure, you can undoubtedly upsize the VM, but you can’t physically touch the systems. Thus, there’s a necessary shift in critical thinking when it comes to fixing the system – it’s now more logical than physical.
It’s also essential to use the right database performance monitoring tool for the right job. In the old days, maybe one tool was good enough for most use cases – cavemen could do a lot of things with just one rock. But just as we now have a Home Depot full of specialized tools, we have technologies for every kind of job.
There are a lot of different ways to solve business problems using databases. But many businesses seem to have tunnel vision: They focus on making things work with the database tools they already have. In effect, they force round things into square holes. I regularly see examples of SQL Server being used as the back end for an application when it isn’t the best option. There are cases where any kind of relational database isn’t the best fit. In some cases, a NoSQL database is better.
But there are always going to be advantages and disadvantages to whatever database you choose. Perhaps a document DB is a better fit for one database, but it’s also a niche application that can’t do relations – it’s vital in one area but falls flat in another.
This advantage/disadvantage binary applies to NoSQL databases too. Many NoSQL solutions give DBAs the ability for increased capacity and scale instantaneously. However, the cost is consistency across the database.
In short, DBAs must discover their level of fault tolerance. How long can you be without your data? How long does it take to update all the nodes? There’s never one correct answer. And remember, your needs will change over time.
The secret is to keep your options open. Make sure you’re aware of the best way to accomplish your goal. For that reason, it’s a risk to go all-in with any single database vendor. Perhaps a single vendor offers you some simplicity, but it also removes the flexibility you’ll need.
Monitor for Performance
A net-new, cloud-based startup and an enterprise organization laden with legacy tech could both store the same data. Despite the differing sizes and infrastructure complexity for these organizations, the data is the same. Data isn’t self-aware; it doesn’t sense that it’s in the cloud and decide to act differently. The difference lies in how the user interacts with the data. As complexity enters the picture with modern distributed systems, the traditional ways of looking at performance monitoring and tuning also need to shift.
DPM, or database performance monitoring, can be used to monitor the cloud-native databases behind your cloud-native apps and systems. DPM is needed because cloud-native is the modern workload. With DPM, you will know when the latency is up – and to scale out with extra nodes right away.
Traditional database monitoring systems don’t provide the same metrics as DPM. Traditional systems focus on things like top-10 queries by CPU, which aren’t going to help with modern distributed workloads. As with everything with modern databases, you need new tools to handle the new ways of working. But the same work goals and guiding principles must apply.
Some things about being a DBA haven’t changed at all.