We’ll start with SQL Azure... This will give most of developers a common frame of reference as most developers are comfortable with relational databases.In a short while, I will introduce Blobs, Tables, Queues, and DrivesSQL Azure can be thought of as your SQL Server in the cloud. It is based on a subset of SQL Server 2008.Blobs are a means of storing unstructured data, such as pictures, movies, PDF’s, Word documents, and the like.Tables are a means of storing semi-structured or tabular data. Tables are similar to an Excel spreadsheet in the sense that data is tabular and there is no strict type cohesion as there would be in a SQL Server table column. Data stored in tables is partitioned and keyed for retrievalQueues are a means of buffered message delivery. There are very useful for communicating data between our Windows Azure service instances. As our service instances do not have to wait around for the I/O of delivering the message or the result of the message processing, they can dramatically improve the scalability of our software system.Drives are a recently added feature announced at the Los Angeles PDC in November 2009. Drives provide durable storage that appears to our application as an NTFS volume. The drive itself is an abstraction over the same Windows Azure Data Storage used for Blobs. You can get more information on Drives by visiting the PDC site on my slide.Applications may use multiple types of data storage at the same time. In fact, this is quite common. When we do our first Windows Azure Data Storage demo together, I will be showing you an application that uses Blobs, Tables, and Queues in concert.
It’s time now to introduce Windows Azure Data Storage Blobs.Blobs are for storage of unstructured data.We partition our data by creating Blob containers which we give names to.We can create an unlimited number of Blob Containers.We then simply place our blob data into the blob containers, supplying a unique identifier.When we want to retrieve our data, we simply provide the container and the unique identifier.
Use queues as a way of communicating w/ the backend worker rolesWRs call getmessage and pass timeoutTimeout value is importantExpiration time is important; message is marked in the queue as invisible; for duration of timeout it’s invisibleWhen we’re done processing, we call a message to remove the message through a deleteTh reason we do this is imagine we have a second worker role; if something goes wrong, once the timeout expires, the message becomes visible, and the next person to do a get message will get the message
http://www.flickr.com/photos/cav666/3562455727/http://go.microsoft.com/fwlink/?LinkId=153401Windows Azure Data Storage Tables are how we get massively scalable and highly available databases.Although there are some similarities, these tables are very different from relational database tables.Data in Windows Azure Data Storage Tables is semi-structured; The concept of a Windows Azure Data Storage Table is similar to how a spreadsheet is used to provide tabularized organization to data without strongly enforcing data cohesion.… Data is indexed in Tables for high performance retrieval, but there are no relationships between Tables.The tables support ACID transactions over single entities and rich queries over the entire table.
The PartitionKey combined with the RowKey uniquely identifies an entity in a table.
11:53Getting the all of dunnry’s post it fast because we’re selecting the entities by a partition keyGetting all of the posts after a certain is slow because we may have to traverse across multiple servers because we’re selecting entities that span partition keysA query without the partition key is really a scan
We have included this feature comparison table in anticipation of your likely questions about differences between using a relational database table as you may be currently doing with your SQL Server databases and the new Windows Azure Tables included in Windows Azure.
As I stated earlier, SQL Azure is based on SQL Server 2008. At this time it is only a subset of the features of the server product.My intention here is to convey the high level features that are supported and the ones that are not.SQL Azure will support most of the things we need… Tables, Index, Views, Stored Procedures, Triggers, and Constraints… in my book… that’s all the functionality that I need for most of my applications.There are some other adjunct technologies that ship as part of SQL Server 2008 such as SQL Reporting Services and Analysis Services which are not supported. The Service Broker is also not supported.
So let’s assume that we have designed our relational database with local developer and data modeling tools.We can begin our story then by assuming that we want to get our database deployed to the cloud.There are some tools that will expedite this process which I will show you later, but for now lets assume that we have scripted our database schema. We apply this script to SQL Azure which speaks native TDS.If you created your database through the SQL Azure Portal, then SQL Azure will have created one master database and three replicas of that database. If you create your database with the script the same will be true.These replicas are stored in different database centers from the master to provide redundancy and protection against geographical catastrophe.
Configuring our application to use SQL Azure storage instead of SQL Server is simply a matter of modifying the connection string in our application’s configuration file.When our application requests data, ADO.NET speaks to the TDS which directs our queries to the master database server. The master database server performs our query and returns the results to our application.
From our application’s point of view, there is only one SQL Azure database.As we make updates to our database, those updates are replicated to other copies stored in other data centers so that in the event that our database fails for any reason, the other databases will be standing by ready to take its place.
But what if that master database server fails for some reason?TDS is receives notification of the database failure and automatically redirects the call to the replica!The Azure Cloud Fabric is self-healing… and the details are outside the scope of this presentation; however, the fabric will get busy repairing itself like drones on a Borg mother ship… essentially with the objective of keeping three replicas online at a time.
When you created your SQL Azure database server, you supplied an administrator’s user name and password. I have named my user accordingly… to remind me of its power.The SQL Portal will offer you the ability to copy these credentials in connection string format to your clip board… tempting you into believing that you should just paste this into your configuration file.This is terrific for demos like mine… BUT you should NEVER, EVER do this…A database server system administrator password placed in a configuration file in clear text format… there has got to be something naive in the extreme going on here… and worse… no way to create non-sa-like users through the UI… you must script your database users and then apply the script to the database. And to anticipate your question… no… you can’t use SQL Server Management Studio to do this either.I will demo this as well in session 3… so hang tight…