Work smart, not hard: Why choosing the right database Is better than elbow grease
Over the years DBAs have been trying hard to keep databases humming while minimizing downtime and transaction errors. Although their achievements should not be ignored, we are now entering an age where they shouldn’t have to be so clever in dealing with a tangled web of hardware and database fragments.
Those scrappy souls who have mastered finding solutions to the tangled messes of databases and their underlying IT infrastructures can be proud of the craft they have honed. It’s quite the challenge to scale databases, particularly those of the MySQL variety, to handle the voluminous mixed workloads seen in many industries today, while maintaining that seamless experience expected by today’s end user. Yet, over the years DBAs have performed technical gymnastics to keep databases humming while minimizing downtime and transaction errors. And while DBAs and IT support staff deserve a medal for their feats, we’re entering an age where they shouldn’t have to be so clever in dealing with a tangled web of hardware and database fragments.
Unfortunately, DBAs often inherit databases that were chosen in a previous era that had significantly different technical requirements. These products are simply not suited to the increasingly demanding environments characterized by increased bandwidths, more Internet users around the globe and the proliferation of mobile devices. As such, a well thought-out database strategy and architecture that will be sustainable for years to come is essential. Of course, this is a tough sell. CIOs’ tenures are only so long, and often the big structural challenges get pushed aside in the effort to put out today’s fires. However, there are a lot of companies out there who are getting it right and finding solutions that will allow their DBAs and IT staff to be the caretakers they should be and not the Macgyvers they are often forced to play.
When health data grows, fast.
One company that has managed to get it right is Viverae, a workplace wellness provider that suddenly found itself faced with difficult questions about how to prepare its database resources for the future as its user base grew exponentially. Viverae was on the Inc. 5000 list of fastest growing companies, and the volumes of data for census, claims, biometrics, lab results and more were pouring in at an astonishing rate.
Viverae had been quite happily operating on MySQL, but the company knew that the scaling limits of the platform would eventually make their database into the dreaded leviathan feared by many and conquered by few. Specifically, while the situation on MySQL was under control for the time being, staying on the platform would eventually mean sharding, a process that really is as painful as it sounds: splitting the database up into fragments that are then stored separately. Each time a new shard is split off, a DBA must manually crack open the applications accessing the database and “tell” them where the new data fragments have been moved—a process that Viverae quite wisely concluded was untenable for them in the long run. Anything, they say, is possible with time and money, and Viverae certainly could have spent big bucks to stay on MySQL and expand conventionally with sharding. Instead, they pursued alternatives, confident that a more cost- and time-efficient way was within their means.
SEE ALSO: The top 10 SQL and NoSQL databases
The company knew it needed a scale-out alternative to MySQL, and wanted one that avoided the complex application modification requirements of sharding on MySQL. It also required a database with high availability, that’s easily backed up and that doesn’t require heavy DBA support or budget.
Structure changes lives
Viverae eventually was able to address their unique blend of challenges and requirements with ClustrixDB, but the lesson of the company’s process remains the same no matter what solution ends up working for a company: the big, strategic, structural choices around databases will deeply affect the lives of those taking care of the databases. This may sound obvious, but it goes unconsidered remarkably often.
It is highly preferable for a management team to be clever for a few months and set a database up for success than it is for a whole team of people to conduct acrobatics for 30 years navigating and patching up a sharded, labyrinthine database just to keep things afloat. While there are companies that can get away with propping up the ongoing maintenance, workarounds and application disruption of scaling a MySQL database conventionally, every company should recognize that that approach might not always be smart.