I was just reading through a list of questions and answers about the new, more SQL Server-like SDS, on the SDS team blog and had a thought. Here’s three points that are made in the post:
When? or to quote JamieT “When do I get to party on this new service”?
We’re on track to deliver a public CTP mid-calendar year 2009 and ship in the second half of calendar year 2009.
The blog entry states “If it works with SQL Server, it will largely work with SQL Data Services.”. That word “largely” bothers me a little – it suggests the functionality is going to be reduced slightly. Details please?
We will be providing documentation soon on what is and is not supported in SDS. I’ll post an entry to the blog once the guidance is available and you can also keep an eye out for it on our MSDN Dev Center. But, to answer the question – We say *largely* due to the fact that there are things that just don’t apply in a cloud based world like setting the location of a data or log file or making server wide configuration changes. In v1 we expect to deliver a surface area that will support the vast majority of SQL Server database applications.
Will you offer hosted SSIS/SSAS/SSRS?
It’s on the product roadmap, but I can’t comment on specifics or timing.
So, we’ll get a CTP in a few months, it’s going to be mostly compatible with existing SQL Server apps, but we’re not going to get Analysis Services in the cloud just yet. What can we do while we’re waiting for cloud-based SSAS then? Well…
- It seems highly likely that we’ll be able to hook a normal, server-based instance of SSAS up to SDS and use it as a data source for building cubes. It would be a pretty silly thing to do though, I’m sure, because it would take ages to process a cube, but…
- Wouldn’t that make ROLAP a more attractive option as a storage mode? No processing needed then, just SQL queries generated whenever the data is needed. However, ROLAP is slow now and is likely to be even slower when you’re querying SDS, but…
- For some OLAP apps, you could dispense with a server-based instance of SSAS altogether. One little-known (and little-used) feature of SSAS is the ability to build ROLAP local cubes. As you probably know, a local cube (.cub file) is a portable cube that doesn’t need full Analysis Services installed anywhere. Since storing a local cube file somewhere in the cloud would be dead easy, I can imagine a scenario where you create a ROLAP local cube file – which would be no bigger than a few KB in size – allow people to download it, and then when they connect to their cube from Excel or wherever the local cube would then in turn retrieve the data it needs from SDS. Not exactly SSAS in the cloud, and probably only likely to work for small amounts of data and simple queries, but it’s an approach and not unlike what CubeSlice has been offering for a few years.
- With local cubes you could always convert them to MOLAP storage if you wanted faster query performance (at the expense of having longer processing times) and of course local cubes seem to be an important part of the Gemini story too. What we’d really need are easier ways to create local cubes and support for easy switching of storage modes (from ROLAP to MOLAP/Gemini) to make this as smooth as possible.