windows azure: is the relational database dead?
DESCRIPTION
Windows Azure: Is the Relational Database Dead?. Benjamin Day http://benday.com. Who am I?. Owner, Benjamin Day Consulting, Inc. Email: [email protected] Web: http://www.benday.com Blog: http://blog.benday.com Trainer, Consultant Visual Studio Team System, Team Foundation Server - PowerPoint PPT PresentationTRANSCRIPT
Windows Azure: Is the Relational Database Dead?Benjamin Dayhttp://benday.com
Who am I?
Owner, Benjamin Day Consulting, Inc.– Email: [email protected]– Web: http://www.benday.com– Blog: http://blog.benday.com
Trainer, Consultant– Visual Studio Team System, Team Foundation Server
Microsoft MVP for VSTS Microsoft VSTS/TFS Customer Advisory Council Microsoft Cloud Services Advisory Group Leader of Beantown.NET INETA User Group
Agenda Big thanks to
– Steve Marx @ Microsoft– Manuvir Das @ Microsoft– David Aiken @ Microsoft
Is the relational database dead? What is Windows Azure? Develop Your Application Deploy To Staging and Production Some Stuff To Think About
Is the relational database dead?
It depends. (Probably not.) Cloud will change everything. Relational database “best practices” are
probably dead…
…at least in the cloud.
AZURE
The Azure Platform
The Azure Platform
The “cloud” in Cloud Services?
Think data-center somewhere on the internet
Allows you to run your app Allows you to read and write data
Ok. So what’s Windows Azure?
Microsoft’s “cloud”– Every cloud has an Azure lining?
Custom version of Windows– Optimized for utility computing applications– Always runs virtualized on the Azure Fabric
Azure Fabric– Runs instances of your apps– Handles “everything”
Azure Storage Azure SDK for Visual Studio
Why Azure? “I’ve got my awesome data-center so…” No more worrying about…
– Buying, configuring, maintaining hardware– Buying, configuring, maintaining the operating
system – Network infrastructure• Routers, Switches, Load Balancers– Your data-center’s power and internet
connections– Failovers
Worry less about…– App deployment– Capacity planning
Focus on writing your app
Simple Scale Out
Changes in traffic
Need more servers?
Need fewer servers?
I want everything…
…and it should be easy. Azure let’s you worry about writing your
app Don’t have to learn a whole bunch of
new stuff Leverage your existing dev skills
Azure: The Developer View
Write it in Visual Studio– New project types– Debug your code
.NET, ASP.NET, WCF, IIS7, LINQ Azure Storage
– Database in the cloud– (with a few caveats)
Desktop development versions of– Azure Fabric– Azure Storage
Demo 1: Hello, World
Hello, World: Discuss.
Doesn’t look like much but…– that’s “internet scale”-able– Highly available
Mostly stuff you already know
Debugging In The Cloud
We can debug a service in Visual Studio How do you debug a service that has
been deployed?– Answer: you don’t
Logging is the answer RoleManager.WriteToLog(eventLogName
, message)– Event log name values: Error, Information,
Warning, Debug, Critical
Demo 1.1: Hello World + Logging
AZURE STORAGE
Azure Storage
Simple database in the cloud– Tables (aka. “structured storage”)– Blobs– Queues
You don’t worry about replication Scales like nobody’s business Development version
– DevelopmentStorage.exe– Uses SQL Server Express
Table Storage Every row has RowKey & Partition Key RowKey = primary key PartitionKey
– Helps you tell Azure how to scale your data– You have to think about how you’ll be querying– By State? By Hour? Other?
RowKey PartitionKey FirstName LastName1 MA Ben Day2 MA John Malkovich3 WA Bill Gates4 CA Steve Jobs
PartitionKey Your partitions could be on different
servers Best practice: If you know your
PartitionKey, add it to the WHERE clause No PartitionKey in the WHERE insane
table scans Recommendation: More partitions is
(probably) better
Think hard about your partition key in the beginning– Else, roll your own re-partitioning
Column Data Types
Partition key and Row key– String (up to 64KB)
Other properties– String (up to 64KB)– Binary (up to 64KB)– Bool– DateTime – GUID– Int– Int64– Double
Demo 2: Azure Table Storage
RELATIONAL VS CLOUD
What is “relational” Tables, Rows, & Columns
– All rows in the table have the same column structure
– You design the database BEFORE you add the data
Relationships between the tables Constraints on the columns Normalization eliminates duplicate
data– Data “nuggets” stored in one place only– Makes it clear what the definitive version
is
Relational in your app Data is organized for the sake of the
data rather than the sake of the app– App is temporary but Schema is forever.– Represents itself as normalization and
relationships between the tables Scales nicely on a single node but
going to a cluster, it gets ugly
Relational DB Engine Does A Lot
Non-trivial SELECT p.FirstName, p.LastName,
ph.PhoneNumberFROMPerson pLEFT JOINPhone phONp.Id = ph.PersonIdWHEREp.LastName LIKE 'D%'
Performance Issues in Relational Avoiding duplication can cause
performance issues De-normalizing If you de-normalize and duplicate
some data:– you can lower the number of required to
build an "object"– You can lower the amount of "heavy lifting"
that the db has to do to retrieve your data That JOIN isn't easy Indexes help but it still is a lot of work
Why Stored Procedures? (1 of 2)
Abstraction between the app & data Externalize the queries
– Remove them from the code– Makes the queries live with the data
more "database me me me!"
Why Stored Procedures? (2 of 2)
Security– lock down direct access to the tables– Users get rights to specific procs
Performance– Less compelling: cached execution plan• Largely irrelevant after SQL Server 7– More compelling: the query logic is near
the data
Stored Procedures In The Cloud
Azure can distribute physical location of data by partition key – Is the stored proc near the data anymore?
(Well, that pretty much wraps it up for stored procedures.)
What you won’t get in Azure Storage
Stored Procedures Views Triggers Foreign Keys Database enforced referential integrity User defined indexes
– (Maybe later.)
While I’ve “dissed” relational…
I’m not saying “skip best practices.” Don’t put everything in the same table You’ll still have relationships between
tables– …the relationships just won’t be enforced by
the DB
THE VERDICT?
WHAT DO YOU THINK?
OK. MOVING ON.
MORE THAN JUST ASPX
Utility Compute without a UI
Azure uses the concept of “Roles” Hello, World used a “Web Role” The other role is a “Worker Role”
– Think windows service in the cloud
Web & Worker
Demo 3: Worker Role and a Queue
In a web role, create an ASP.NET page– Creates a queue– Writes to a queue– Gets queue depth
Worker Role– Reads the queue– “Processes” the message
DEPLOYMENT
Demo 4: Deploy To The Cloud
Change the storage config to use production servers
MISCELLANEOUS
Things to think about
No foreign keys No triggers No stored procedures In Table storage, strings can only be 64k
– You’ll need to use a mix of Blob and Tables Think hard about what config values you
put in web.config/app.config vs ServiceConfiguration.cscfg
The Big Questions
When?– Sometime in 2009
An actual Service Level Agreement (SLA)
More data-centers– Now in US only– Global at go-live
What will it cost?– It will depend on what you use
More resources
My Blog– http://blog.benday.com– Sample code– More Azure content to come…
Steve Marx’s blog– http://blog.smarx.com/ – Evangelist for the Azure team
Azure.com
Final questions?
Who am I?
Owner, Benjamin Day Consulting, Inc.– Email: [email protected]– Web: http://www.benday.com– Blog: http://blog.benday.com
Trainer, Consultant– Visual Studio Team System, Team Foundation Server
Microsoft MVP for VSTS Microsoft VSTS/TFS Customer Advisory Council Microsoft Cloud Services Advisory Group Leader of Beantown.NET INETA User Group