Who Needs Clustrix?

Share This

More organizations than you might imagine. Your high-volume, high-value transaction–based business may struggle without ClustrixDB

Does your company see large fluctuations in website traffic—periodic spikes in which thousands of visitors concurrently transact with your organization? Does your business depend on processing these transactions instantly and accurately, or risk losing money, records, inventory, sensitive customer information or other valuable intellectual or physical property? Will your business lose customers and/or revenue if your site slows down or crashes under the duress of these thousands of near-simultaneous transactions?

ClustrixDB was built from the ground up to solve this challenge because no other solution in the marketplace could handle this type of workload cheaply, simply and effectively.

Why other solutions struggle
MySQL databases, the most common cost-effective RDBMS based on the familiar SQL query language, were built to scale this many Web browsers clicking on pages and generally poking around the site—”reads,” in DBA parlance. However, they weren’t designed to scale “writes”—transaction-oriented traffic, such as putting retail items in and out of a cart, or enabling hundreds of gamers to play an interactive online video game—at this level.

MySQL and many newer drop-in replacements for the RDBMS mainstay, most notably Amazon’s Aurora, were built on a single-box design. Although they can handle a reasonable workload, thousands of concurrent transactions will push the box’s limits, causing slowdowns or crashes. It’s not that these solutions can’t scale to process this many concurrent transactions, it’s that it won’t be cheap, easy or in many cases safe to do so. DBAs would need to resort to technically complex (and costly) tactics like sharding and read slaves—tedious, largely manual, time-consuming processes that can leave organizations extremely vulnerable to outages and/or result in the loss of valuable data if performed incorrectly.

Today, companies want to move away from arcane technical tricks like this. And their customers and end users expect the sites and the services they access to work seamlessly.

ClustrixDB: the ONLY viable offering for this environment
Thanks to its intelligent design, ClustrixDB provides superior performance—up to 10 times faster than Aurora—without making tradeoffs in terms of ease and total cost of ownership. ClustrixDB is:

  • Simple. Designed to work in a database cluster rather than a single box, Clustrix customers only need to add instances (or commodity hardware) to the database cluster with a few clicks whenever they need capacity. Increase in load? Just add nodes—and ClustrixDB continues to deliver excellent (20-milliseconds-or-less) response times. Conversely, MySQL and equivalents like Aurora begin to stall as transaction workloads approach these levels.
  • Cost-effective. With ClustrixDB, customers can “right-size” their database (i.e., pay only for the capacity they need). There’s no limit to how much ClustrixDB users can expand, should transaction traffic keep growing. And if peak periods are seasonal or otherwise temporary, customers can just as easily “Flex” back down and subtract instances when things return to normal. Plus, ClustrixDB can be deployed in the Cloud or data center. Thus, there’s no need to lock yourself into a costly, inflexible traditional on-premise database.
  • Compatible. ClustrixDB is a drop-in MySQL replacement that requires no modification of your applications.
  • Resource-efficient. ClustrixDB delivers better performance as more compute, memory, network and storage capacity are made available. In addition, because it works with the MySQL procedures with which your DBAs are already familiar, there’s no need to replatform or hire new tech folks to maintain the database. Moreover, those same DBAs won’t need to waste valuable time with the aforementioned technical workarounds.
  • Secure. ClustrixDB has no single point of failure, unlike MySQL databases once they are sharded or have read slaves applied to them. Each node is a peer to the others, which means the others can maintain database performance when one (or more) fail.

If you need to process thousands of concurrent transactions without error, your options are straightforward: 1) jerry-rig your MySQL or drop-in replacement with sharding, read slaves or other database gymnastics that leave your site vulnerable to catastrophe, 2) move to Oracle or other traditional on-premise solutions that will cost enormous sums of money up front and lock you into an expensive path down the road, or 3) choose ClustrixDB and get unparalleled performance while maintaining fault tolerance and paying only for the capacity you need.

Which is to say, the choice is simple.

Source: Clustrix