Federations in SQL Azure: Building Large Scale, Elastic Data Tiers in the Cloud


Published on

Federations simply bring in the sharding pattern into SQL Azure as a first class citizen. Sharding pattern is used for building many of your favorite sites on the web such as social networking sites, auction sites or scalable email applications such as Facebook, eBay and Hotmail. By bringing in the sharding pattern into SQL Azure, federations enable building scalable and elastic database tiers and greatly simplify developing and managing modern multi-tenant cloud applications.

Federations scalability model is something you are already greatly familiar with: Imagine a canonical multi-tier application: these applications scale-out their front and middle tiers for scalability. As the demand on the application varies, administrators add and remove new instances of the front end and middle tier nodes to handle the variance in the workload. With Windows Azure Platform this is easily achieved through easy provisioning of new capacity and the pay as you go model of the cloud. However database tiers have typically not provided support for the same elastic scale-out model. However with federations, SQL Azure enable database tiers to scale-out in a similar model. With federations, database tiers can be elastically scaled-out much like the middle and front tiers of the application based on application workload. Using federations, applications can expand and contract the number of nodes that service the database workload without requiring any downtime!

-Cihan Biyikoglu

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Speakers should use this slide to identify content, related to their presentation, being offered in other sessions or labs at TechReady. Your Track PM can provide a full listing of all of the sessions, webcasts, hands-on labs and instructor-led labs in your track, as well as the other tracks.If there is additional content available that attendees should know about, please add a section for Additional Resources to the slide. In this section you can call out whitepapers or websites that you and your team have created.Track PMs are listed below:Track Name, Acronym and Track PMArchitecture (ARC) – Miha Kralj, Terra SuddarthBusiness Intelligence (BIN) – Peter SpragueBusiness Solutions (MSDY) - Pattie Grimm, Scarlet LeungDatabase (DB) –Dandy Weyn, Kevin Ashby, Maxine CooDevelopment Tools & Technologies (DEV) – Bijan JavidiExchange and Lync (EXL) – Lauren Horgan, Navin Chand, Becki CulbertIT Service Management (ITSM) - Bebe AcciavattiMiddleware and Integration (MWI) – Tony Meleg, Joe KlugManagement, Operations and Deployment (MOD) – Aurora Santiago, Juliet HossmanOffice 365 (OFC) - Mike Naughton, Lori Skinner-StudleyOffice and SharePoint (OSP) – Olaf Hubel, Hila Grinberger, Andy O’Donald, Monica Watson, Lita SprattOptimization (OPT) – Yoav Land, Angela EarleyReadyTech (RT) - Joe Culp, KariLynne GratzerSecurity, Identity & Privacy (SIP) – Christopher Pelletier, Aurora Santiago, Juliet HossmanVirtualization (VIR) – Aurora Santiago, Juliet HossmanWindows Azure platform (AZR) - Vikram Rana, Terri SladeWindows Client (CLI) – Jean Taylor, Angie Nelson, Lisa PuchosicWindows Phone (WP) – Tim McAfee, Rob TiffanyWindows Server (SVR) – Aurora Santiago, Juliet HossmanCross Track CoverageApplication Platform – APS/DB/AZR/ARC Solution Accelerators – Michelle Arney, Michelle Walls Compete – Mike Brevard Trustworthy Computing – Christopher Pelletier Next Web – Olga Londer User Experience – Alison ClarkPrivate Cloud – Aurora Santiago Windows Embedded – Olivier Bloch
  • Federations in SQL Azure: Building Large Scale, Elastic Data Tiers in the Cloud

    1. 1. Building Large Scale Database Applications in the Cloud Federations in SQL Azure Cihan Biyikoglu Program Manager – SQL Azure
    2. 2. Scalability Model for the Cloud• Cloud Apps Require Scale Beyond Scale-Up – Massive aggregate capacity: 100s of nodes available for use• Cloud Apps Demand the Best Economics – Best Price/Performance • Many commodity nodes for the economics – Elasticity + Pay-as-you-go • Provision just in time and without downtime! • Reduce overcapacity
    3. 3. Introducing Federations in SQL Azure• Canonical 3 tier app scales by adding and removing nodes in front and middle tiers.• Federations extend the model to the DB Tier
    4. 4. Why use Federations?• Gain practically unlimited scale by harnessing 100s of SQL Azure nodes – Go beyond the limits of a single SQL Azure Database• Create an elastic database tier that can expand and contract with your applications workload… And without downtime!
    5. 5. Why use Federations?• Build Multi-tenant Solutions – Single tenants per db works… But what about very small tenants and very large tenants?• Tenant Management with Federations – Federations makes tenant placement and replacement easy. – Change your tenant placement any time without downtime. Tenancy Models Single tenant per database Multiple-tenants per database Multiple databases per tenant
    6. 6. Who are Federations for?• A few examples – Web Scale DB Solutions – Multi Tenant SaaS ISVs – Workloads with Spikes, Bursts, Peaks etc… – …And also NoSQL Applications • Apps that need bigdata, big scale, massive parallelism, eventual consistency, lightweights local storage, semi structured data etc.
    8. 8. Overview - Architecture• Federations: Federation define the scheme for the federation – Federations are objects contained within a user database just like other objects.• Federation Root: DB that houses federation object – This is the central repository for information about distribution of scaled-out data• Federation Members: System managed SQL Azure DBs that make up the federation – Each federation member contain parts of federations data CREATE FEDERATION Orders_Federation(tenant_id BIGINT RANGE) Federations SalesDB Orders_federation Orders_federation Orders_Fed Federation Root Federation Members
    9. 9. Overview - Concepts• Federation Distribution Key – The key used for data distribution in the federations.• Atomic Unit – Represent a single instance of a federation key. An AU contains all rows in all federated tables with the same federation key value. Federations member: Range [1000, 2000) SalesDB AU AU AU PK=5 PK=25 PK=35 Orders_federation Orders_federation AU PK=5 AU PK=25 AU PK=35 Orders_Fed AU PK=1005 AU PK=1025 AU PK=1035 Federation Root Federation Members Atomic Units
    10. 10. Overview – Architecture cont.• Repartitioning Operations without Downtime! – SPLIT members to spread workloads over to more nodes – DROP members to shrink back to fewer nodes ALTER FEDERATION Orders_Federation SPLIT AT (tenant_id=7500) SalesDB Orders_federation Orders_federation Orders_Fed [5000, 7500) & [7500, 10000) [5000, 10000)
    11. 11. Reliable Routing• Built-in Data-Dependent Routing (DDR) – DDR ensure app can discover where the data is just-in-time – Apps no longer has to cache ‘shard map’ – Federations guarantee routing to the right member even when repartitioning operations are going on in the background. USE FEDERATION Orders_Federation(tenant_id=7509) WITH RESET SalesDB Orders_federation Orders_federation Orders_Fed [5000, 7500) & [7500, 10000)
    12. 12. Related Content• Federations on the Web – Online Product Documentation • http://msdn.microsoft.com/en-us/library/windowsazure/hh597452.aspx – A fresh overview of federations • http://social.technet.microsoft.com/wiki/contents/articles/2281.aspx – My blog • http://blogs.msdn.com/b/cbiyikoglu