Comments on “Microsoft reveals its database for the cloud” • The Register

Comments on: Microsoft reveals its database for the cloud

Back to the article
Comments on this article are now closed

Microsoft: "SQL Server not suitable for large datacentres" #

By Gordon Jahn Posted Monday 10th March 2008 20:52 GMT

When I see:

"Microsoft technical fellow Dave Campbell told Reg Dev: "We are not using an off-the-shelf SQL Server to power this, we've taken the technology and shifted it around to make it more suitable for large-scale datacenter deployment.""

...what I read is: "SQL Server is not suitable for large-scale datacentre deployment".

A property bag of name/value pairs #

By Tom Willis Posted Tuesday 11th March 2008 01:44 GMT

"A container is a collection of entities and is what you search within, analogous to a single database in a traditional model. An entity is a property bag of name/value pairs, where each item may have the same or different properties.

...every item in SSDS has a few fixed properties: an identity that is a globally unique identifier, a "kind" that identifies the category of the entity, and a version datestamp used for concurrency checking."

Sounds remarkably like a Notes database. Very useful for a lot of purposes, not new but there we go... Maybe good quality replication and offline edit access will result.

‘Microsoft reveals its database for the cloud’ #

By David Posted Tuesday 11th March 2008 03:40 GMT

you beat me to it...

To clarify a couple of points... #

By Dave Campbell Posted Friday 14th March 2008 12:50 GMT

I just want to clarify a couple of points in the comments. Firstly, there are a number of very large Internet properties that are powered by SQL Server including Microsoft's own Live properties. I believe there are > 15,000 SQL Server instances across all of our Internet properties. There are other big names you'd recognize as well. The point I was trying to make is that when you're designing for a data center containing 10^5 or 10^6 servers you do things differently than when you're designing for a typical enterprise deployment. Done right, you can drop both your capital and operational costs significantly.

Secondly, on the data model. We're starting with a pretty simple universal model to get the service up and running. Obviously this will evolve over time as we have the capabilities available in the back end to offer very rich schema and query support. What we're finding is that there are a pretty large number of interesting scenarios you can build out with just what we've announced thus far. We're looking forward to the feedback to figure out what to add next.