Clustrix - Databases For The Internet
Clustrix - Databases For The Internet
Clustrix today announced the general availability of their scalable database system targeted directly at the challenges being faced by developers of internet-enabled databases. Examples would be those in use at eCommerce, social media, photo sharing and other environments where concurrency is critical and transactions per second are measured in the tens and hundreds of thousands, or greater.
Tuesday, May 4, 2010
The bulk of these environments tend to be based on MySQL. The classic work-around for scaling MySQL to handle these levels of concurrency is to implement database ‘sharding’. Sharding is the technique of using the application to partition the data that it is responsible for across isolated databases on separate servers. Queries are then routed to the appropriate database partition by the application.
While this does provide scalability to the MySQL environment it also requires substantial custom changes for the application to implement. The skill set of the database developers that know how to implement and manage sharding comes at a premium, to say the least. In addition, sharding requires complicated and manual software programming at the application layer to deal with load balancing, failover and recovery.
The Clustrix system, instead, creates a single-instance, scalable database without requiring changes, as sharding does, to the underlying applications or infrastructure. The system is a node-based scale-out cluster applied to a database system in much the same way scale-out clusters have been implemented with application servers and storage systems. Each node is identical and includes 32GB of memory, dual quad-core processors and seven 160GB SSD drives for integrated storage. Two 20Gb Infiniband backend ports for inter-node connectivity and two 1Gb Ethernet ports for front end connectivity are also provided. The system features automated load balancing, failover and recovery, along with scalable performance. If the system begins to hit a performance wall, simply add more nodes, performance is linear to the number of nodes.
Comparing the cost of the Clustrix system to that of sharding is really a comparison of operating versus capital costs. This comparison can be made both at development and implementation as well as the subsequent years when the costs of maintaining code vs maintaining hardware are realized. In both cases the Clustrix system should be considerably less expensive than the comparative sharding approach. As an example, a typical sharding project costing $1.2 million in year one could be done by a Clustrix solution costing less than $200k, with a five year savings of over $3.2 million, all while offering a better customer experience.
Briefing Report
George Crump, Senior Analyst