Gridscale easy scaleout of SQL Server - my view

I was recently emailed by one of my readers asking about SQL Server scaleout. They had been told of something but couldn't find it, and wondered if I knew what it was, I didn't but they eventually came back and told me they had found Gridscale.

So I looked into Gridscale. Kevin has a post with some good comments regarding Gridscale http://sqlblog.com/blogs/kevin_kline/archive/2009/02/02/product-watch-scalable-sql-server-grid-with-xkoto-could-this-be-mssql-s-answer-to-oracle-rac.aspx

Looking at it, it scales about by acting as a middle man in between your app and SQL Server. It distributes writes to all nodes to make sure all nodes are consistent but it only sends reads to a single node. Given most apps are heavily read intensive this means you can scale your system beyond what you can on one server. However, in a well tuned system, reads are going to come from cache but writes have to write to disk and so you have an inherent performance difference between reads and writes.

If your server is maxing out on writes then I can't see how Gridscale will help you. Because all the servers will have the same write IO needs.

One of the benefits of how Gridscale works is the that servers can be taken off line, patched and then bought back on line. From a maintenance, DR perspective this is great. I really wanted this at Totaljobs as I wanted to implement a two active data center operation. We already had a replication topology that allowed reads to be served from different servers, ths downside was we replicated from one node and failing over replication to a new site is a pain (for the distribution database).

My biggest concern with any replication type solution is what happens when something goes wrong. What happens when one server goes out of sync, whats the process for rebuilding it.

So in summary I think this a good solution although I would like to see more information. You are going to have n copies of your data and so need storage to support it. Whats more your storage needs to support the n times number of IOs your servers will generate. I have no idea on costs but I would expect that the cost will be similar to implementing your own replication topology.

Whats more if you really what scale out you need to design your application to scale out, this has to involve partitioning or some sort.

But with servers becoming faster, memory being cheap and solid state disks on the way. Do we need to scale out?


-
Published 20 March 2009 20:30 by simonsabin

Comments

24 March 2009 09:27 by GrumpyOldDBA

# re: Gridscale easy scaleout of SQL Server - my view

P2P will also achieve scale out but again at the expense of duplicating the data store. I personally don't see this as true scale out, as you say it still doesn't balance the load across the servers which is what you really want to achieve. Servers are not actually becoming faster, we're only adding more cores and unless we use increased parallel processing and programming we're just thinking we're gaining more power. Moore's law no longer applies for CPU. My own view is that federated servers will give scale out - despite rumours ms is planning to drop support. SSD's are also great, but the SSDs for use in enterprise systems remain very expensive compared with disk. 6GB SAS disks will give your io system a considerable boost as long as you have enough spindles and spin speed.