xkoto's GridScale virtualizes data access

I had a lovely conversation with both David Patrick, CEO, and Albert Lee, Chief Strategy Officer, of xkoto about their new product, GridScale. I've known David for quite some time. We met at Ximian's Cambridge offices long before Novell acquired the company. If my memory serves me, David later become VP and General Manager of Novell's Linux, Open Source and Services group. Although I'm sure that I've met Albert at some time in the past, neither of us can recall when we met.

Their company, xkoto, has developed a very innovative way to virtualize data access for database systems. When used properly, this technology can improve scalability, reliability and availability and provide non-stop, "continuous availability" for data stored in a database. They simply create a highly scalable, high performance database cluster or grid (pick your favorite term.)

Here's how the company describes their product, GridScale:

The GRIDSCALE Database Load Balancer uses patent pending technology to enable commercial off-the-shelf databases to run on a cluster of commodity systems with the same or better reliability and performance as much more expensive proprietary systems.

With GRIDSCALE, customers gain a number of benefits including continuous availability 24x7, data scalability on demand, the elimination of down time/maintenance windows, complete safety for data across multiple sites, and better utilization of hardware assets.

What's GridScale really doing?

Although I'm sure that Albert would wince at this non-technical presentation of what GridScale actually does, I'm going to charge in where industry analysts fear to tread and have a go at describing what's happening.

GridScale captures the flow of SQL statements before the database has an opportunity to see them. The statements are replicated using a sophisticated store-and-forward queuing system to other machines so that changes made to the data can be reproduced on all of the systems as appropriate. The systems in this "application level cluster" don't have to be identical, their storage subsystems don't have to be shared and they only have to see SQL statements that effect data that they actually have access to.

Snapshot Analysis

Providing high performance, reliable, scalable access to database data for virtual systems is clearly a challenge for many organizations. Keeping database data inside of the virtual server can make the configuration simple but, that approach really isn't scalable or reliable. Keeping the data on a storage server can provide higher levels of access and reliability but, it also means deploying parallel database software (so that multiple virtual servers have access to the same data), either storage or database replication software (so that the data can be replicated to several different storage servers for reliability/availability) and, of course sophisticated management software allowing administrators to oversee the operations of all of these different tools.

xkoto has looked at the problem of data access, performance, scalability and availability in a new way. Rather than trying to monitor the buffers in the database, monitor output buffers in the operating system, or monitoring the storage subsystem in the hopes of catching changes as they happen and replicate them elsewhere, they've done something new. They're monitoring the input to the database and replicating the SQL commands. The change in thinking appears simple, but the impact is quite profound.

SQL statements are much smaller than blocks or tracks of data. Replication would most certainly be faster and simpler. Tricky coding allowing monitoring and control of the raplidly changing internal database buffers or output buffers for the operating system isn't necessary. It also isn't necessary to scan storage subsystems for changes (a little bit like trying to boil the ocean don't you think?).

I'm impressed by both the simplicity of this approach and all of the wonderful things that could be done once the SQL stream can be monitored. I can envision a number of future abilities that xkoto could choose to develop based upon this new way to look at the problem.

• It would be possible optimize database operations based upon real application usage without requiring developers to change a single application. The product could "fix up" the SQL statements on the fly before the database engine(s) had a chance to see them.
• It would be possible to improve database security by knowing which systems had access to what data and preventing the injection of malicious SQL statements from systems outside of the cluster.
• With a bit of discipline in the development of database schemas, it would be possible to "cluster" database servers based upon totally different operating systems and database engines.

I could go on and on about the opportunities for new features and services this approach offers. I suspect we're going to hear about partnerships and alliances xkoto will develop with most of the major hardware suppliers, database suppliers, suppliers of management software for virtualized resources.

If you're interested in learning more, I'd suggest a quick visit to the company's website.