Five Signs You Are Outgrowing MySQL

3 comments

TONY BARBAGALLO<br/>ClustrixTONY BARBAGALLO
Clustrix

Tony Barbagallo brings over 25 years of product management, corporate, and channel marketing expertise to Clustrix. Prior to Clustrix, Tony led the launch of Skyera, a new entrant in the enterprise solid state storage market.

The data management landscape is rapidly evolving. With the emergence of ‘super apps,’ processing millions of user interactions per second, in addition to big data and the cloud, it’s clear organizations are in need of the “next generation” of databases.

Many have already been making the transition from MySQL to a scale-out or NewSQL database. They’ve benefited from faster analytics, increased scalability, as well as higher performance and availability of their data.

If you’re unsure your organization is ready for the change, here are five signs to help you identify whether or not you’re outgrowing your MySQL database.

Difficulty Handling Reads, Writes and Updates

Many analytics platforms are built on MySQL databases that simply can’t scale to support detailed analytics or advanced feature sets. As your load increases, if you are finding it difficult to handle additional reads and writes, you may need a different database. With a scale-out approach, administrators can easily add extra nodes to process additional demand, making the handling of increased transactions much easier.

Slow Analytics and Reporting

MySQL databases don’t provide any real-time analytics capabilities, as they offer no support for joins and other SQL constructs. To address this problem, both Multi-Version Concurrency Control (MVCC) and Massively Parallel Processing (MPP) are required for processing massive workloads because they allow writes and analytics to happen without interference and use multiple nodes and multiple cores per node to make analytic queries go faster.

Frequent Downtime

MySQL databases are built with a single point of failure, meaning if any component – such as drive, motherboard, or memory – fails, the entire database will fail. As a result, you might be experiencing frequent downtime, which can result in loss of revenue. You can use sharding and slaves, but this quickly becomes fragile. A scale-out database keeps multiple copies of your data and provides built-in fault tolerance and continues in a completely operational state even with node and / or disk failures.

High developer costs

Developers working with MySQL databases must often spend a large portion of their time fixing plumbing issues or addressing database failures. Developers who work with a scale-out database are free to instead work on developing features and getting the product to market quicker. Time to market decreases and companies are able to earn revenue quicker.

Maxed out servers

Are your servers running out of RAM and starting to page to disk or temp tables? If you see the servers maxing out for extended periods of time, or it happens frequently throughout the day, it’s a key indicator that MySQL can’t keep up with your growth. Adding hardware is the quick fix, but it’s also very expensive and isn’t a long-term solution. If organizations used a scale-out approach, data can be replicated across nodes, and as transactions increase in size and amount, workload is shifted to other nodes within the database.

As your organization and customer data grows, consider transitioning to a database that will scale to meet your needs. So if you fall into any of the five categories discussed, consider a scale-out approach.

Industry Perspectives is a content channel at Data Center Knowledge highlighting thought leadership in the data center arena. See our guidelines and submission process for information on participating. View previously published Industry Perspectives in our Knowledge Library.

Add Your Comments

  • (will not be published)

3 Comments

  1. Jonathan

    This article is so full of inaccuracies it should be taken down. No need for me to list them. Anyone with even the slightest working knowledge of MySQL, databases in general, or even basic server configuration will see it. Just...wow.

  2. M

    I completely agree with the post above me, Jonathan. In every point you make, you contradict yourself saying MySQL can't do this but a scale-out approach using something else will work. MySQL IS a scale-out database not a scale-up and that is a fundamental concept of MySQL. Seems like your knowledge isn't up to date with the last 5 years. Please take down this article as it is completely inaccurate.

  3. Nathan

    MySQL by itself does not provide scale-out or fault tolerance. while it is true that it has been used as part of highly available or scaled-out solutions, through techniques such as master/slave pairs, slaves for read fanout, and sharding, these are complex solutions which require app-level changes and present ongoing maintenance challenges. this continues to be the case even as Oracle tries to productize a generic sharding solution with their fabric offering. Compare this to a distributed database designed to scale-out from the outset, and the complexity is hidden from the application and ops staff, allowing developers and ops to focus on core business problems.