Monday, September 14, 2009

Building applications on SQL Azure

SQL Azure – Database as a Service

  • Jeremy Boyd
  • Mindscape
  • DAT301

SQL Data Services

  • Previous incarnation
    • Entity-Value style
    • Provided REST based access to resources
  • Matched similar competitor offerings
  • Lacked familiar SQL Server syntax and capabilities
  • Use Azure Table+Blob Storage as replacement
SQL Azure Database
  • Clear feedback
  • I want RDBMS in the cloud
Provisioning Model
  • Account = zero or more servers
  • Server = each server has one or more databases
  • Database = each database has standard SQL objects
Compatibility Goals
  • Version 1: Address the needs of 95% or more standard application functionality (web/enterprise)
  • Support common application patterns
  • Consistent patterns for Azure and SQL
  • Multi-tenancy considerations
Building Applications
  • Can target SQL Azure either remotely from on-premise or from Windows Azure
  • Can promote existing applications or build new applications
  • SQL Azure offering currently favours:
    • Cacheable data sets
    • Blah
    • Blah
On Premise over Azure
  • Data is typically located outside the firewall from where your application runs
  • Be aware of latency (~150ms from NZ to US)
  • Try to pre-fetch as much as possible
Impact on System Design
  • Expect poor latency
  • Avoid chatty calls = code for chunky calls
Windows Azure over SQL Azure
  • Application Code runs within the Azure network that your data resides on
  • Same connection string as with remote
  • Check that your SQL and App instances are on the same location group (e.g. US – Southwest)
  • Note: Caching may still be appropriate
  • SQL Azure and Windows Azure will generally provide a “better together”: experience
  • Azure offers a great data synchronisation point: high availability, scalable
  • Sync Framework “Project Huron” for sync
  • Common Scenarios
    • Mobile device access to corporate data
    • Business to business sharing
    • Secure digital data hub
Database Size
  • Max single db size is currently 10GB
  • Database size calculation
    • Includes: primary replica data, objects and indexes
    • Does NOT include: logs, master database, system tables, server catalogues or additional replicas
  • V does not support auto-partitioning
  • Use Scale Out (Sharding) approach to solve if needed and applicable
Sharding with SQL Azure
  • Several databases are used to store a portion of the application's data
  • Blah
  • Two plans
    • US$9.99 per month for 1GB (Web Edition
    • US$99.99 per month for 10GB (Business Edition)
    • SLA – 99% availability
  • Price is per database
    • Each database gets a server instance
    • No limits on CPU/RAM consumption unlike Azure
    • Automatically replicated, no admin cost
  • Best to think of price in “per day” terms
Release Plan
  • Currently in CTP
  • Commercial availability in November 2009
    • Launches alongside Windows Azure

No comments:

Post a Comment