THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

Kevin Kline

Product Watch: Scalable SQL Server Grid with XKoto. Could this be MSSQL's answer to Oracle RAC?

Microsoft SQL Server has been advancing technologically on every front with each new release.  Having spent five years as an Oracle professional (I wrote my first technical book about Oracle) before moving to SQL Server in 1995, I spent a lot of time explaining and sometimes apologizing for the technical limitations in SQL Server when compared to Oracle.  With SQL Server 2005, Microsoft finally had a product that required no apologies.  This was a product that could scale to multi-terabyte database sizes and could handle tens of thousands of transactions per second. SQL Server could now handle just about anything you threw at it. 

Despite these innovations, there's still one thing that Oracle has that SQL Server doesn't - Real Application Clusters (RAC).  RAC promises that you instantly add new servers to the Oracle cluster, adding their processing power to the cumulative total processing power available for the database application.  In a nutshell, RAC promises to deliver seemless scalability and load balancing.  (The marketing claims are just that, btw.  RAC is not nearly as easy to install, configure, or maintain as it should be.)

What if you'd like RAC-like capabilities for your SQL Server environment?  Are you out of options?  Not with Xkoto's new product called Gridscale.  Gridscale virtualizes your SQL Server database(s) thereby enabling you to scale them out.  As you add more servers, you get more power and improved availability.  I've seen a demo presented by several members of the XKoto team and, despite my skepticism, I'm impressed.  If you have extreme scalability needs or what to start with a limited amount of power today and scale up later, you should watch the on-line demo here.

As always, I welcome your comments!

Cheers,

-Kevin

Published Monday, February 02, 2009 8:35 PM by KKline
Filed under: ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Linchi Shea said:

The devil is in the detail.

February 2, 2009 10:50 PM
 

Andy Irving said:

Ah, but like all of these products (marathon, etc) they won't be a supported virtualization solution according to microsoft. so if it goes wrong you're on your own.

February 3, 2009 4:31 AM
 

eonsoy said:

Impressive indeed, but probably a very strong and big in size RAID array would be needed for the Recovery Log for busy environments.

Question in my mind is may Microsoft buy this company or this technology?

February 3, 2009 5:08 AM
 

Greg Linwood said:

RAC is a scale-out technology but this doesn't make it a highly scalable technology. It is important to note that Oracle's clustered benchmarks have never exceeded their single server benchmarks (this is still the case today & can be reviewed at www.tpc.org).

The designers of Rdb knew this way back when DEC sold the technology to Oracle in the mid-nineties & those same architects had good reason not to include a RAC feature when they were recruited by Microsoft to work on SQL7.

What RAC does theoretically give you is the ability to bolt an extra box but in practise it isn't this simple & you don't get linear scalability (as is proven by audited TPC benchmarking vs marketing fluff).

February 3, 2009 6:27 AM
 

aspiringgeek said:

Concur w/ Greg--RAC has been great for Oracle in terms of marketeering, but implementation isn't as simple as many have allowed themselves to believe.  A while ago I worked with what was believed to be the largest RAC on Windows implementation in the world.  I was called in after months & months and hundreds of thousands of dollars in licenses, support, & consulting failed to remediate RAC reporting challenges.  SSRS did everything--I mean literally everything--the company needed out-of-the-box.

Kevin, thanks for this post about XKoto.  I'm eager to learn more.

February 3, 2009 9:38 AM
 

KKline said:

I don't debate that RAC has its technical challenges and broken promises.

What definitely happens is that RAC is sold not to the technologists who have to implement and maintain it, but to the C-level executives of the organization.  These people just -LOVE- the promise of plug-n-play extensibility and scalability, even if it's not a technical reality.  Once the C-levels are sold on it, there's nothing for the poor DBA to do but suffer with the consequences.  

Nevertheless, it's a strong marketing tactic and it's definitely one that wins business for Oracle.  SQL Server needs a way, some way, to counter this argument besides a pouting "It don't work good, hmph!".

-Kev

February 3, 2009 9:49 AM
 

Adam Machanic said:

Kevin,

I assume you saw the keynote on the final day of PASS?  What are your thoughts on that material compared with this product?

February 3, 2009 9:56 AM
 

JohnC said:

This thing is just a load balancer for SQL..

If I want to have my 500 GB database with 10 servers on the back side I have to have 500GB * 10 SAN space to do it.. It does not break the database up and store part of it on each server..

I also need 10 SQL Licenses to do it.. ouch..

It's more like replication..

February 3, 2009 11:06 AM
 

noeldr said:

Totally agree with JohnC. This is just a load balancer.

(IMHO NOT a good thing for SQL Server Cache)

Hype!

February 3, 2009 11:58 AM
 

jchang said:

In theory, RAC scales out everything, read and write.

Xkoto scales out reads (write SQL is sent to all nodes)

My recollection of the MS PASS demo (a company MS bought in Mission Viejo?) was that it was aimed at MPP, ie, powering through a single query on all nodes. which means it is important to distribute data across nodes in a useful manner.

I am not inclined to think that either RAC or xkoto can generate a parallel execution plan across multiple nodes. Rather, these two are meant to distribute separate queries across nodes.

Lets compared xkoto versus mirroring. If we had an intermediate layer that could distribute read queries to the mirror nodes, we could get scale-out on reads. The mirror requires sending log writes (?) to the read-only nodes, and the remote nodes may not be concurrent with the master.

In xkoto, the issues is whether your paticular db will work with xkoto. xkoto must be able to determine whether a query is read or write, and the identity or newid must synch. If an app uses dynamic SQL that could be either R or W (I know, a really stupid idea), then xkoto cannot handle it. I think there might be issues if your app inserts rows, then immediately uses the identity or newid values (check with xkoto on this)

Kevin is right on RAC illusions/delusions versus reality. What it comes down to is that a remote memory access is far more expensive compared to a local memory access (1-3 usec versus 100ns). When RAC was first announced at Oracle world (2003?) larry spouted off on how big iron was dead, and RAC was the answer. If bothered to check his own price list, it would be apparent that even if RAC did scale, it would simply be the difference between buying really expensive hw versus really expensive sw, no net dollars saved.

back to RAC tech, RAC could work with GE, but Infini-Band (IB) was the other option. remote memory access was much lower overhead with IB than GE. But IB is much more expensive than GE, meaning RAC would not be cheap in HW either.

More than 10 years ago, before RAC, there was a group at Intel trying to put the protocol for remote node memory access into the memory controller, but I don't think they spelled out (or justified) the benefit vs cost.

It is possible that if RAC could be done directly on AMD HT or Intel QPI, but this is in the future

February 3, 2009 12:06 PM
 

jchang said:

I neglected to summarize the options are:

1. Buy really expensive HW that may or may not solve performance scaling problems (plus additional SQL Server licenses).

2. Buy really expensive SW that may or may not solve said problems.

3. Expend alot of effort with internal staff working in areas out of their expertize.

4. hire a really REALLY expensive consulting company that will not solve anything.

5. hire a really expensive consultant who may or may not solve your problems (hint)

February 3, 2009 12:24 PM
 

alee said:

I appreciate all the comments on Kevin’s blog regarding xkoto and GRIDSCALE. As a disclaimer, I work at xkoto, but I’m not wearing a marketing hat, I’m the strategy guy – in fact I may have met some of you at PASS 2007 or 2008.  While we often get compared to Oracle RAC, we’re quite different (RAC is shared everything, we’re shared nothing). Our GRIDSCALE technology is also different from Project Madison (we don’t require partitioning), and mirroring solutions (we are active-active so databases are always updated and consistent without the sync behavior penalty).  While we entered the SQL Server market late last year, I can say that we’ve done deep testing with the SQL CAT team and the MTC labs, so we know we’ve got software that works and makes SQL Server much more competitive.  Plus we’ve learned a lot from our many production customers who have been running on db2 distributed, some for 2+ years.   See you around, hopefully before PASS 2009. Please keep the comments coming and we will be happy to answer any and all questions you might have.

February 3, 2009 1:45 PM
 

jchang said:

there is one nice capability of xkoto that has nothing to with scalability, and the ability keep multiple copies of the database in sync. So we can apply a hotfix, or service pack to one node, while keeping the other node in the original configuration. Now I do wonder if xkoto will help you keep track of what errors occured on one system but not the other. xkoto will also allow one node to be SQL 2005 and the other 2008 (assuming your code is compatible with both)

February 4, 2009 11:00 AM
 

alphatross said:

I think HP's Polyserve product allows "Shared-Everything" type Scale-Out with SQL Server - but as Andy said above, it's a scary thought introducing a non-Microsoft Supported component into your Environment. Remember that Disks are the performance bottle-neck, so having multiple Nodes all talking to the same data "hot-spots" on disk mean only CPU and Memory are being taken advantage of by scaled out Nodes (and Buffer contents have to be kept in Sync - another overhead), which could explain the Oracle RAC Benchmark results Greg talked about. The Teradata DB uses Shared-Nothing Scale-Out technology for scalability via little Virtual Machines called AMPS, that operate on partitioned Tables, which the Gridscale stuff reminds me of.

February 4, 2009 5:16 PM
 

Salim said:

XKoto has great usability ( in theory, i haven't tried it yet, but thinking about it) as a disaster recovery tool, and at  the same time the DR site is being online and load balanced with the rest of the DB Servers !

February 6, 2009 3:10 AM
 

alee said:

Regarding PolyServe - it's a clustered file system with good HA but scale requires moving the SQL Server instance to another server in the pool - so in reality it's not scaling out as much as up.

Disk I/O is definitely a huge constraint on improving database performance - while GRIDSCALE does maintain multiple identical & consistent databases in its pool, queries are load balanced to relieve I/O contention.  With a read-heavy workload you can see some pretty significant scale by doing this I/O distribution.

February 20, 2009 9:57 AM
 

Vinnie Cardoso said:

Hi,

I would like to reply some of JCHANG's comments as I think he missed the point on GRIDSCALE:

1. GRIDSCALE does not require expensive hardware or expensive storage solution either (i.e. SAN). It uses commodit hardware. You can plug any type of machine.

2. The software cost is much cheaper than the cost of downtime of most organisations that requires 24/7 systems.

3. GRIDSCALE can be installed and configured in a couple of hours. Easy to use and does not require special expertise. Any SQL Server DBA can easily learn GRIDSCALE...

4. GRIDSCALE has the intelligence to identify READs and WRITEs. It will send the read request to the less busy server, therefore minimising impact. Writes are spreaded out to all nodes asynchronouly, and will respond back to the application as soon as the first node responds back.

Customers using GRIDSCALE at the moment seems to be really happy. They don't have to worry about maintenance windows anymore. They don't need to call their DBAs on Sunday at 2 am to fix the system. They can simply add new nodes to the cluster if the demand increses. They can also apply fixpacks during normal hours while other nodes of the cluster are keep up and running. GRIDSCALE keeps a log with all transactions that had happen at that time in order to apply it to the server that has just received maintenance...

So, to sum up there are much more benefits far beyond to any software or hardware cost, while addressing HA + DR, scallability, data redundancy (so you don't have to worrie about any disk failure...) etc.

I hope it helps.

Vinnie

March 20, 2009 2:26 AM
 

Vinnie Cardoso said:

By the way, you can find more info here...

http://www.datasync.com.au/index.php?id=92

Cheers

March 20, 2009 2:31 AM
 

SimonS Blog on SQL Server Stuff said:

I was recently emailed by one of my readers asking about SQL Server scaleout. They had been told of something

March 20, 2009 4:44 PM
 

Massimo said:

Big Doubts:

-if I use stored procedure to write or read, passing only parameters this soft is not useful ?!

-if I use identity rows and an insert fails on one server, I will probably have different PK for the same rows !?

ps: I want a product to scale writes, I can scale reads with other solution (log shipping, mirroring, ecc. without multiply storage.

May 25, 2009 9:35 AM
 

Chuck Lathrope said:

xKoto doesn't support TDS yet. End of summer they say. There is also pcticorp.com DBx product which does synchronous writes and fastest available server reads. But, you do have to recode for Uniqueidentifer and Getdate() updates. Plus they have been in business doing this for quite a while. Marketing sucks...They are SQL 2008 compliant now too.

-Chuck

June 16, 2009 3:07 PM
 

Matthew Smith said:

Tried to enquire about Gridscale today, but got an email back stating the company had been purchased by an as yet unamed buyer and that Gridscale has been taken off the market.

Shame as it looked promising

May 17, 2010 10:58 AM
 

KKline said:

Hi Matthew,

Yes, it's true.  Xkoto has been acquired.  I know some of the details, but don't believe I'm able to speak publicly about them.  I'll post more details when I know that it's ok to do so.

Thanks for the comment,

-Kev

May 17, 2010 4:39 PM
 

Tim Knoob said:

Xboto was acquired by Teradata, who preceded to remove Gridscale from the market.

October 1, 2010 5:16 PM
 

KKline said:

Thanks for mentioning this, Tim.  I didn't know if the information was public yet or not.  

I'm sad though that Gridscale was pulled.  I assume it was intended to protect something Teradata has in the market.  I wonder what?

October 7, 2010 11:58 AM

Leave a Comment

(required) 
(required) 
Submit

About KKline

Kevin Kline is a well-known database industry expert, author, and speaker. Kevin is a long-time Microsoft MVP and was one of the founders of PASS, www.sqlpass.org.

This Blog

Syndication

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement