SDS

SDS Thoughts on 5he Bus Ride to Work

carpdeus@gmail.com — Fri, 27 Feb 2009 21:07:40 GMT

It appears that I will be doing a presentation on SQL Data Services in June
at VSLive Las Vegas. When I first put the proposal together, I had a general
idea and outline. That was a couple of months ago and, since then, the SDS
team has been very quiet. They recently announced big new things coming in a
new version, probably for this MIX, so I need to go through my outline and
figure out what I can work on now that is generic, cloud information and
will have to change my specifics after the release.

I actually am giving two talks, one on SDS and another on Microsoft's
caching service but al of my demo code for both rely on SDS. So it is going
to bean interesting few months, since Velocity is due to release a new
version at MIX and I should be able to benchmark it against a memcached
instance. My belief is that memcached will win in performance and Velocity
will win on al of the features that make it not a memory-based cache. I say
that because items like fail-over and redundancy, while nice, do sort of
defeat the notion of a cache per se.

But, for the rest of today's bus ride, I think I will work on an SDS
outline.

The End of JOINs, Part 2

carpdeus@gmail.com — Sun, 01 Feb 2009 01:41:45 GMT

As I was saying last ~~week~~ ~~month~~ year in this post, JOINs in SQL Data Services are not the same as they are in SQL Server. I'd recommend going back to review that post but the upshot of it is that SDS processes JOINs differently.

Using a JOIN in SQL Server can have two possible uses. The first is to bring data together, so that columns from one table appear seamlessly with another table in the result set; the second is to filter data, the only JOIN that SDS supports if you use their JOIN command. But that doesn't mean that you can't JOIN data seamlessly between data sets, you just need to use Extensible Stylesheet Language Transformations (XSLT).

XSLT is a way to manipulate XML data, using an XSLT Engine to transform XML into something else, in this case, an XHTML document. If you look at the generated XML (zip file here), you can see that it alternates between a web site entry and then the calendar entries for that web site. One way to process the XML would be to walk the XML in code and generate output. But the XSLT Engine handles that for you, all we need to do is to tell the engine how to process the data. Below is the pertinent part of the XSLT:

On the plus side, the engine handles the transformation from XML into XHTML with just a few lines of code:

string rawXML = calender.GetData("calendar-of-events", SDSQuery.ToString());
XPathDocument doc = new XPathDocument(new StringReader(rawXML));
XslTransform xslt = new XslTransform();
MemoryStream strm = new MemoryStream();
XmlTextReader xrdr = new XmlTextReader("SDS_JoinExample.xslt");// (new StringReader(xsltTransformation));
xslt.Load(xrdr, null, null);
// Transform the document to the Writer
xslt.Transform(doc, null, strm);
strm.Position = 0;
string Output = new StreamReader(strm).ReadToEnd();

I've got a class, Events, that handles the call to the SDS and returns XML. We need to load that XML into an XPathDocument. Then the XSLT Transform and finally execute the Transform. Those few lines of code can off load a great deal of work. That's a good thing, in general, but it does highlight the problem I have with things like SDS: there's too much work being done elsewhere. I'll grant this sounds like a shell game since, whether the data gets merged at the data service or on the web server or the client, the same amount of work needs to be done; or does it? When SQL Server provides a JOINed result set, that data can be cached and returned for subsequent calls. If the web server makes the join and caches it, then the cache can be reused for clients it's serving but multiple web servers in a web farm will require multiple database calls. Finally, if the client handles the join then every call is probably going to need to hit the database.

Cloud computing is good and can be beneficial, but you should consider all of the costs involved before jumping feet-first into it.

Download the sample code here.

The End of JOINs?

carpdeus@gmail.com — Thu, 20 Nov 2008 23:28:59 GMT

So, I'm playing around with SQL Data Services (SDS), one of Microsoft's Cloud Databases. (see more here, signup forPublic CTP here). And it requires some shifts from the way that things are normally done. I've got a demo that I talk abouthere, but I've made some changes since then. The original demo only had one "table", a calendar of events. I've updated thatZip file to now include another "table".

More...

Calendar of Events -- S[S]DS

carpdeus@gmail.com — Wed, 19 Nov 2008 03:10:06 GMT

More...