Avoiding
database
burnout
Practical tips on how to design
and maintain your databases
Follow instructions
Overworked and overlooked
When your boss hasn’t had a proper
holiday or a raise in 27 months, they
get cranky as hell.
They’re somehow tired and wild at the same time, they boast
the patience and serenity of a chain smoker who’s been stuck
in a lift for eight hours, and their head is overflowing with so much
accumulated rubbish that they can hardly focus on a single task
for longer than the time it takes for the light from their monitor
to hit their eyeball.
The result is that their performance
goes down the toilet. Not that you would
ever tell them. We call this burnout.
So it is with databases, of all things. The modern database
is overworked and underappreciated. They need a good
work-life balance. Some looking after.
A bit of TLC.
In an application-first world, how your application performs
is the foremost determinant of your business success.
But when your databases get cranky,
you applications start getting sluggish and
stubborn. And success becomes harder.
So here are some practical tips on how to build and maintain
your databases so that they bring your applications to life,
and don’t ever get cranky.
2
The right tool for the job
You wouldn’t use a mallet to conduct
the Royal Philharmonic Orchestra.
Having the right kind of database – configured precisely for the job
at hand – is essential for getting the most out of your applications.
But there are so many varieties that assessing your needs now and,
crucially, in the future, is the first step of any database project.
What are your needs?
There’s a lot to consider. Here are some guiding questions
for assessing functional considerations:
•
•
•
•
•
•
•
•
•
•
•
•
How much data will you need to collect?
How many peak concurrent transactions do you expect?
What level of security do you need?
Are there compliance concerns?
Do you need backup? How often?
What about resilience and disaster recovery?
If so, what is the target time period for restoring service (recovery point
objective - RPO) and how long could you survive without that data
(recovery time objective - RTO)?
What do you expect your growth rate to be over one month,
then six months, a year , two years, five…ten?
Will there be seasonal variations in utilisation?
Are there any upcoming business strategies or trends
that will affect transaction peaks or rate of change?’
What is the anticipated rate of change of the connected applications?
Will it need to integrate with other business intelligence systems?
Then you need to decide on your
operational needs...
3
Building with the end in mind
Your database is a means
to a business end.
You should try to build your business logic into your choice
of database platform and management system, rather than just
into the connected applications. This will make your application
much more portable and will allow your solution to scale.
It’s worth noting that you can’t have it all. You’re going
to have to make sacrifices.
What’s more important to you?
Budget or performance? Simplicity
or resilience? Control or freedom?
First things first... choosing an environment
There are four main options when choosing an environment
for your databases:
D.I.Y.:
this gives you maximum control over your data, which can allay
any regulatory and security concerns, but puts the tedious hardware
maintenance work on your shoulders. Limited resilience.
Hosting specialist:
takes away the facility and hardware management headache
and frees you to focus on your IT core competencies. But you need
to find a managed services partner that is a good fit and that you trust.
Public cloud:
lets you deploy faster and can be a great option for volatile traffic
databases, as well as a site for backup and DR. But resource utilization
can go up fast, especially over the long-term.
Hybrid:
You can combine on-premises and public cloud – using the most
appropriate environment for different workloads. For example, companies
often use the cloud for fast-changing lateral workloads, whilst keeping
the back end on-premises.
4
The tyranny of choice
Once you’ve chosen an environment,
you’ve got to settle on a type of database.
There are two main ones:
Once you’ve chosen a platform and a type
of database, you then need to choose
a database management system (DBMS).
Relational (e.g. MySQL, SQL):
The environment and DBMS you use are critical determinants
of the performance of your application and need to work together.
For example, the latest version of Microsoft SQL is designed to
incorporate Cloud Burst functionality with Microsoft Azure.
These are the linchpin of most existing IT systems. Its strength
is its robust implementation of ACID: transactional atomicity,
consistency, isolation and durability. Transactions will either reliably
complete, or terminate with no effect. The result is a ‘single truth’,
which makes for a stable application.
Non-relational (e.g. DocumentDB):
These are understood today as ‘not only’ SQL databases.
They’re generally distributed (decentralised), open source
and horizontally scalable. They are becoming popular for
web-scale, big data and analytical implementations – any
sets of large, highly-variable, unstructured data.
But the options available can be daunting.
Here it’s worth talking to an expert about the long-term suitability
of each DBMS and how they suit your business needs.
A
B
C
It’s easy to get going with NoSQL if setting up in a hurry,
however, performance won’t be optimised so make sure
to consider future needs.
5
How to manage your database
Every database needs some kind
of management to keep them from
getting cranky.
But a few months in – maybe a few years if you’re lucky – and
then the crankiness sets in. Your applications start slowing down
and eventually grind to a complete halt. The database equivalent
of a nervous breakdown.
Over time, databases get scattered (fragmented), which leads
to sluggish performance. An overworked database wears down
quicker and costs you more in the long run because
of poor performance.
Whilst there are plenty of tools that can provide a certain amount
of management automation, you ultimately need someone there
to manage your data.
Remember: proactive database
management and monitoring is smarter
and more cost effective than reactive
database administration.
Some of our customers came to us because they set up a database
and…sort of figured it would be fine if left to its own devices.
And it is! For a while.
A little and often...
If you catch and tackle mismanagement early you avoid
problems and stop them exploding into much larger ones.
It’s worth remembering that brute force is rarely the answer.
If your database is running slowly, don’t just throw hardware at the
problem, assuming that it’s a CPU or RAM issue. Any performance
increase you achieve this way will only be a short-term relief
to a deeper problem.
Poorly designed and managed systems
perform poorly regardless of their
hardware specification.
6
The DBA: Data Bad-Ass
A good database administrator
will do more than just administrate.
Your database informs business-critical decision-making
so the technology you’re using and who’s looking after it can
be the difference between failure and success.
A good DBA will be able to assess your database needs accurately
and suggest the smartest solution for the results you need, rather
than something that just meets capacity and power requirements.
They’ll also ensure that your databases are optimised to take
maximum advantage of the physical or virtual hardware on which
they are hosted, and follow a checklist of daily, weekly and monthly
maintenance tasks. These are continually refined to anticipate,
prevent, detect and resolve problems.
Lastly, they’ll always have the future in mind, sitting down with
you to capacity plan and anticipate business trends that could
substantially affect your database needs.
Here are some of the necessary tasks that
a Data Bad-Ass will complete for you:
• Keep up to date with vendor releases/announcements
• Perform Database Consistency Checks (DBCC)
• Update database statistics
• Housekeeping of system and customer databases
• Repair databases where required
• Run scheduled integrity checks that will analyse,
check, optimise and auto-repair all of your databases
• Respond to alerts and events from the monitoring system
• Index optimisation
• Resource checks and capacity management:
CPU, Memory, IO, Capacity planning
• Amend memory utilisation on the MS SQL Server application
to suit the need of the application/database
• Maintaining and testing backups, system and database restores
• Weekly general system report
• Capacity planning and trend analysis
7
Join our webinar!
29th September at 4pm
Managing databases to drive
application performance: Optimise
performance, avoid pitfalls, fine-tune
monitoring
Register here