latest updates from easySERVICE™
MySQL has long been the go-to database of the Web. It has powered some of the largest websites on the planet, as well as countless installations of open source software on every scale imaginable. But as many have learned, at a certain point, MySQL can become a burden to scale efficiently.
Scott Sullivan, vice president of technical account management at NewSQL vendor Clustrix, explains MySQL’s limitations and details how NewSQL databases provide a fresh alternative. — Paul Venezia
How to tell you’re outgrowing MySQL
Rampant growth in data has left us scrambling to find better data management solutions. Most companies with a sizable user base have long outgrown the single database server that hosts all applications — and now live in a bewilderingly complex ecosystem of multiple data management systems.
You may already have swarms of read slaves backing an elastic set of memcached MySQL servers, answering queries from your various Web/application farms in the cloud. You’ve probably already configured geographically distributed multimaster replication for handling writes into your database. Or maybe you just think you need to figure all of that out sooner rather than later.
Whether you have done none or all of the above, there comes a time when you outgrow what you have — in many cases, the time-honored MySQL database — and need to expand to meet current or anticipated growth. How do you know it’s time?
1. Latency increases during peak traffic
If your services perform well off-hours, but seem sluggish during the peak part of your day, that’s a strong indicator that you need more capacity or a shift in architecture.
Many teams naturally try to identify the offending load generators: adding indexes, rewriting queries to be more efficient, returning fewer results per page view, and so on — and those efforts are often rewarded with improved user experiences. But those are 1 percent solutions. If you find yourself doing this day after day, you need a double-digit improvement often provided by additional hardware resources.
MySQL can scale up to the limits of today’s technology as well as any system, but scaling out is limited. Common attempts to scale out a MySQL platform range from simple approaches — such as deploying read-only slaves — all the way to complex solutions like sharding or off-loading queries to a NoSQL architecture. All of these require changing your application’s logic and data access methods and perhaps even your data model and user experience. None of these changes can be deployed quickly to combat rising latencies.
NewSQL solutions such as ClustrixDB are designed to scale out by incorporating additional hardware resources effortlessly, increasing capacity without requiring any work other than the rack and stack of new servers — no application changes, no alteration of your data model. NewSQL delivers on the promise that a relational database can simply outgrow today’s single instance hardware limits through clustering across affordable servers.
2. Delays in reporting and analytics
DBAs cringe when management wants to run reports against the production database. That’s because the production database often runs full-tilt during the day and cannot afford to service the heavy calculations required to tell you how your service is performing. Running your reports on production not only takes longer than normal, but your user experience suffers.
Your DBA may have already set up a copy of production (a read slave) specifically for analytics and reports. The data on this dedicated reporting server may be slightly behind your production traffic due to replication delays, but at least your reports run quickly. This is like having a company car reserved for you and you alone. If you are not driving, it sits idle, waiting. Wouldn’t it be better to put that reporting server to work serving user requests — and be able to run reports quickly when you need them?
NewSQL systems can dynamically incorporate additional servers into a single database service, which no MySQL architecture can do efficiently. By overprovisioning a NewSQL system, your excess capacity can serve not just the occasional report, but surges in user traffic as well.
3. Regular and/or lengthy downtimes
MySQL systems that have grown to serve large loads tend to have many potential points of failure.
You can design around this by creating multiple masters or read slaves, increasing cost and complexity. But each additional replica of your database is another link that has to be managed and kept in sync. Each is susceptible to data inconsistencies, falling behind, or dropping out due to software or hardware failures. Plus, the more systems you have, the greater the odds that one of them will fail at any given time.
Each failure requires manual investigation and recovery — or automated processes and recovery systems that your team has to develop.
By contrast, NewSQL systems are designed to act as a single unit. You have one primary database to manage, along with a second disaster recovery (DR) system at a remote geographic data center. Whether your database server is made up of a few or dozens of servers doesn’t matter; from a DBA’s perspective, it’s a single system. Hardware failures should be handled automatically as the system routes requests around the down components.
Smart NewSQL systems can self-heal and restore their ability to tolerate additional hardware failures without human intervention. Having these high-availability features and self-healing built into your scale-out database can reduce downtime events from hours to seconds.
4. High development costs
When your MySQL architecture is bumping up against the limits of single-instance servers, your developers start spending more time solving scale-out problems than they do working on features for your business.
On top of that, every new feature you request must be developed around your increasingly complex MySQL architecture rather than simple SQL principles. Simple requests become complicated. When your developers spend a lot of time scaling out your database systems, you have to decide if this method of scale is a differentiating factor for your business or time that could be put to better use.
5. Shopping for exotic hardware
Scaling up a single-instance MySQL database can only take you so far with current commodity hardware. You can swap in the most powerful CPUs your system can hold or buy an armload of RAM, but once your motherboard is full, that’s it.
Upgrading beyond commodity hardware is a desperate last attempt to close the performance gap. A superfast system with all flash drives, 512GB of RAM, and the fastest processor money can buy will cost you more than a cluster of commodity systems.
True scale-out NewSQL solutions are designed to run on cheap, commodity hardware at the knee in today’s price-performance curve. This keeps your operating expenses predictable, so they scale with your revenue rather than surpassing it.
Source: Associated Press