xkoto launches support for Microsoft SQL Server

Today xkoto announced that they've added Microsoft's SQL Server to the list of database management systems that they're supporting in GRIDSCALE, fulfilling a promise to expand their offering to support many databases made when they exited stealth mode in December 2007. For those keeping track, I introduced xkoto GRIDSCALE and its capability to virtualize database access in the post, xkoto’s GridScale virtualizes data access.

This is a different approach to the problem of database scalability, performance, availability and reliability that others are fielding.

What does xkoto do?

Here's a snippet from my original post:

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.

Snapshot analysis

As more and more of an organization's applications become available to customers through some sort of web-based front end, the reliability and performance of the database behind the application becomes a critical success factor. Many suppliers have taken a swing at providing tools making it possible for these organizations to addess this issue by supporting database clusters or supporting database or file system replication.

The approach taken by xkoto is based upon a different view. xkoto inserts its software in between applications and the database management system. It then can replicate SQL statements, optimize those statements, or as this announcement points out, allow database clusters made up of different database engines to be created.

I found this to be a very interesting approach. You just might agree. If you're interested, please visit xkoto's website and learn more.