Contact Us

Resources

Product Brief
Learn how you can easily and seamlessly deploy the Clustrix database

download >>

White Paper
Learn more about the technology at the heart of the Clustrix database

download >>

view all resources >>

Why Database Operations Hit the Wall

One thing at Clustrix we’ve seen over and over again is the mixed surprise, delight, and fear about a rapidly scaling online business. In some cases, seemingly over a weekend, an operations team goes from scaling just fine to complete meltdown. How can this be? How come your operations team was able to scale from 0 to 200,000 users, but couldn’t go from 200,000 users to 300,000 users?

Here’s some analysis of why this happens. It comes down to the inability of existing solutions to scale incrementally with load. The problem is the database. The database your team was using to build the back-end system only scales to a certain point. What was working all through development, QA, and initial deployment may The Scenario suddenly fail at the worst possible time—as soon as your application starts to grow.

The following graphs are typical performance data, along with a projected project timeline. This mirrors the experience of many web application groups.

The Scenario

Here is a description of the trap that we’ve seen a lot of folks fall into. You’ve built your application, customers are starting to take notice, and you’re growing. Things are taking off.

describe the image

Every day more and more people are taking notice. You want to really accelerate things, so you launch a big promotion and have your first huge weekend. This weekend could be “company making” for you guys, and it’s all hands on deck to make sure nothing bad happens.

But something bad does happen—something terrible.

describe the image

A Custom Project, Not A Solution

This is based on test run data from a MySQL server on a production level box. What happened here? We climbed up a slope of performance and concurrency and suddenly everything cratered. After the initial peak, each attempt to add more load was met with less throughput, not more. The MySQL server has reached capacity in terms of its ability to process requests. It can do no more work than it’s doing now. This isn’t some fundamental flaw in MySQL—this is a fundamental flaw in design of any database that can’t do clustering for scale- out. This results in lost users, lost business, and a painful way to watch an opportunity go down the drain.

At this point the operations and dev team works up a plan. Maybe buying a bigger box can delay the problem, but that’s only a temporary solution. What are you going to do once you hit the limits of that box? The most common solution is something called “sharding”. When team start sharding, they break what used to be a single database into a bunch of individual databases. They write software to glue things back together again. This breaks most of the benefits that these databases were designed to deliver, and produces a very brittle and easy to fail application stack. [For more on sharding read our sharding development page here]. Sharding is the development-heavy solution to the problem of not having scalable database solutions available. People spend months writing very complex code, and then the maintenance of this code goes on and on ... forever. The people who can do this kind of work are hard to find, very expensive, and specialize in these sorts of infrastructure problems that have workarounds which are extremely application specific. The solution for one application doesn’t work for any others because it’s a baked in part of the application architecture. It’s a custom project, not a solution.

The Clustrix System

But now with Clustrix you have a real, permanent, and simple solution. Instead having your dev team embark on a giant software development project, you can install a Clustrix database. Our database grows simply by adding nodes into the cluster. Let’s zoom out on that earlier data plot and look at how Clustrix compares to that MySQL server.

describe the image

What this shows is that adding nodes to a Clustrix cluster results in on the fly scale and performance. No matter what your operational scalability and performance needs, the Clustrix database can handle it.

This contrast with sharding is why our customers tell us that Clustrix has saved them hundreds of thousands, and sometimes millions of dollars, in development cost and unplanned downtime. Think about the time to market advantage of having the infrastructure challenges already solved. If you don’t, you’re competitors will. Take advantage of the proven scale-out capabilities of the Clustrix cluster.

Now, anybody anywhere in the world can build scalable web applications without having to worry about the database. To read about how other organizations have scaled with the Clustrix database, check out our customer success stories.

Content

No Sharding!

Database sharding is expensive and risky. It introduces significant opportunity cost and risk by requiring additional application code and operational complexity.

Clustrix diminishes the cost and complexity of sharding. Clustrix has created a distributed database that grows online through clustering.

To learn more, read our white paper, Scaling Databases and the Sharding Deep Freeze. Just fill out the form to download.