José Blakeley Partner Architect SQL Server Engine Microsoft Corporation BB07.

Developing Large Scale Web Applications And Services

José BlakeleyPartner ArchitectSQL Server EngineMicrosoft Corporation

BB07

Visual Studio & .NET“Oslo” - Modeling

Partners

To solve 90+% of the problems automatically Self Tuning Dynamic Optimization Self Configuration Self Management

The remaining percentage takes higher touch Requires careful design for scalability Good knowledge of how the RDBMS platform works This is the focus of the talk today

SQL Server Design Philosophy

Scalability requires careful design and best practices Patterns emerge codified into platform

patterns emerge … Design patterns for scalability

Partitioning – functional, data, transactions Messaging across functional components

Patterns used in real-life, large-scale applications Major US Stock Exchange Beijing Olympics – Roger Doherty MySpace.com – Hala Al-Adwan

Takeaways

SQL Server Data Platform Basic concepts – common ground

Assumptions Workloads

Design patterns for scale Functional partitioning

Case study 1 – A large US stock exchange Messages connect the functional pieces

Case Study 2 – Beijing Olympics Monitoring Data partitioning and transactions

Case study 3 – MySpace.com Summary

Outline

Dynamic Development

Beyond Relational

Pervasive Insight

Enterprise Data Platform

SQL Data PlatformAny Place, Any Type, Any Scale

SQL Server Data Platform Basic concepts – common ground

Assumptions Workloads

Design patterns for scale Functional partitioning

Case study 1 – A large US stock exchange Messages connect the functional pieces

Case Study 2 – Beijing Olympics Monitoring Data partitioning and transactions

Case study 3 – MySpace.com Summary

Outline

Workload types – next slide This talk focuses on OLTP scale out

Scale dimensions Transaction throughput No. of concurrent users Data size and growth rate

Looking for “unlimited” scale patterns Preserve locality: transactions + operations While data size grows incrementally

Assumptions and Focus

Online Transaction Processing (OLTP) Balanced read-update ratio (60%-40%) Fine-grained inserts and updates High transaction throughput e.g., 10s K/sec Usually very short transactions e.g., 1-3 tables Sometimes multi-step e.g., financial Relatively small data sizes e.g., few TBs

Data Warehousing and Business Analysis (DW) Read-mostly (90%-10%) Few updates in place, high-volume bulk inserts Concurrent query throughput e.g., 10s K / hour Snowflake, star schemas are common Complex queries (filter, join, group-by, aggregation) Very large data sizes e.g., 100s TB - PBs

Workload Types

OLTP Scale-up Mostly Solved

Jan-95 Jan-97 Jan-99 Jan-01 Jan-03 Jan-05 Jan-07 Jan-09 100

1,000

10,000

100,000

TPC-C Performance/Socket

Quad-core

Dual-core

Single-core

tpmCSQL Server results only.

TPC Results as of July 15, 2008. Graph includes both current and withdrawn (historical) results. See www.tpc.org for a complete list of TPC-C results.

Performance per socket scales with Moore's law

Jan-95 Jan-97 Jan-99 Jan-01 Jan-03 Jan-05 Jan-07 Jan-09 1,000

10,000

100,000

1,000,000

SQL Server TPC-C Results

TPC Results as of July 15, 2008. Graph includes both current and withdrawn (historical) results. See www.tpc.org for a complete list of TPC-C results.

OLTP Scale-up Mostly Solved More than 1 tpmC on standard servers

Pentium Pro - 1998

Pentium II - 1998

Pentium III - 2000

Xeon MP - 2003

AMD Opteron

Dual Core - 2005

Intel Xeon Quad-Core

- 2008

0

5000

10000

15000

20000

25000

30000

35000

1,392 2,400

7,50011,200

18,000

34,000

3-Tier SAP SD Benchmark Users on Windows and SQL Server – Industry Standard Servers

OLTP Scale-up Mostly Solved Enough capacity for most SAP customers

Provides out-of-the-box scale for ~10 TB Data compression – row and page Star join, bitmap filters, partitioned table parallelism Minimally Logged INSERT MERGE Resource governor – CPU and memory

Many successful apps for 10-100 TB running today E.g., Danske Bank, Clalit Health, US Dep. of Agriculture,

Pan-STARRS Building out-of-the-box scale for 10s-100s of TB Will not discuss DW scale further in this talk

Data WarehousingSQL Server 2008

SQL Server Data Platform Basic concepts – common ground

Assumptions Workloads

Design patterns for scale Functional partitioning

Case study 1 – A large US stock exchange Messages connect the functional pieces

Case Study 2 – Beijing Olympics Monitoring Data partitioning and transactions

Case study 3 – MySpace.com Summary

Outline

Functional Partitioning

CreateBasket

Remote Mirr

or

(Log S

hipping)

Load

Bal

ance

r

PartitionedShoppingBaskets

PartitionedCustomerAccount

Data

Pres

enta

tion

OrderProcessing

Catalog Browsing

CustomerData

ReplicatedCatalog

Submit Order

A Commerce Service AppHTTP, REST

Major US Stock Exchange

Case Study

Stock trading and order matching system Design objective: 100,000+ trades/sec Smart design to achieve overall system high

availability and performance through fault tolerance in application architecture

High-availability and disaster recovery not discussed here

Major US Stock ExchangeRequirements

Functional partitioning Message router Order maker Matching engine Journal, history

Data Partitioning Follows functional partitioning

Communication via messages and queues

Major US Stock ExchangeDesign concepts used

Initial Design

Access Series

Order Maker

Matching Engine

JournalParticipant Instrument

• Single instance• Single database• Large server hardware

• Scale-up option• Limited performance• Limited scalability• Ease of development

Access Journal

Participant Data

Instrument Data

50,000 Trades/sec

Transactional Messaging Queue Batch Messaging Queue

Functional And Data Partitioning

Access Series

Order Maker

Matching Engine

Journal data

ParticipantInstrument

Access Journal

Participant Data

Instrument Data

• Increased performance• Increased scalability• Application changes

70,000 Trades/sec

• Two instances• Two databases• Scale-up & out options

Transactional Messaging Queue Batch Messaging Queue

Functional And Data Partioning

Access Series

Order Maker

Matching Engine

Journal dataPartitions

Participant Data

Partitions

Instrument Data

Partitions

Access JournalMulti-queue Pipe

Participant DataMulti-queue Pipe

Instrument DataMulti-queue Pipe

• Increased performance• Unlimited scalability• Application changes

• Three or more instances• Three or more databases• Scale-up & out

Participant Data

Partitions

Participant Data

Partitions

Instrument Data

Partitions

Instrument Data

Partitions

Journal dataPartitions

Journal Data

Partitions

125,000 Trades/sec

Transactional Messaging Queue Batch Messaging Queue

SQL Server Data Platform Basic concepts – common ground

Assumptions Workloads

Design patterns for scale Functional partitioning

Case study 1 – A large US stock exchange Messages connect the functional pieces

Case Study 2 – Beijing Olympics Monitoring Data partitioning and transactions

Case study 3 – MySpace.com Summary

Outline

Provide exactly-once, in-order delivery Building exactly once semantics is hard

Needs durable recording of sending Needs reliable ack of receiving Reliable tracking with

partner-state-machine (activities) Can be custom-built on any communication

framework SQL Service Broker provides one built-in

Messaging Reliable Message Semantics

Communication infrastructure Two-way “Dialogs” Reliable delivery to local and remote queues Exactly-once, in-order semantics Large Message Fragmentation

Activation services on message arrival T-SQL or CLR stored procedures

MessagingSQL Service Broker

APP 1

SQL Engine SQL Engine

APP 2

NBCOlympics.com

Roger DohertySr. Technical Evangelist Developer and Platform EvangelismMicrosoft Corporation

case study

Most ambitious live and on-demand broadcast event in history Streaming video delivered for every minute of every sporting event at the

2008 Olympics summer games 2200 hours of live coverage, 3000 hours of on-demand coverage Delivered 70 million video streams encompassing 600 million minutes

Site featured innovative Silverlight 2.0 streaming coverage Adaptive streaming support for bit rates up to 1.5 mbit (near HD quality) 16:9 viewing for supported displays Picture-in-picture support Live video control room supporting up to 4 concurrent streams Integrated live statistics and scoring

Designed to add value to, not supplant, TV coverage Monetized using video pre-roll advertising Record setting average 27 minute session!

Average for other sites was 3 minutes

Background

Existing monitoring solutions don’t cover client experience Real-time logging service needed to track client QoS + usage

Silverlight 2.0 client logging instrumentation must: Throttle Avoid chattiness Not block Permit dynamic updates

Logging service must: Handle unpredictable load, stay available and responsive Not lose data Provide near real-time reporting and analytics Permit dynamic updates

Time to build and deploy: < 2 weeks

Challenges

Web Tier

Logging Service (WCF)

Send Message (TSQL)

Initiator Service (SSB)

Transmission Queue(SSB)

Data Tier

Target Queue (SSB)

Activator (TSQL)

Deserialize Message

(CLR)

Insert RawLog (TSQL)

RawLog

Logging Client

Target Service (SSB)

Initiator service stores message in

transmission queue until

service broker can forward to target service endpoint

Logging service calls send

message SP with incoming message

Target service enqueues message

Activation stored procedure fires,

dequeues message, calls CLR

deserialization procedure with message, then

inserts row into RawLog table

Client constructs message and calls

logging serviceSend message SP starts dialog

between initiator and target service

and sends message

Logging Service Design

Loosely coupled message schema Simple name/value pair schema Pros: Allows for addition of new attributes without changing message

schema or contracts Cons: Attributes mapped to columns using metadata

Serialized at client Deserialized once in data tier using SQLCLR Fire and forget message pattern

Conversation handle pooling critical

Message Design

<nvc f="1"> <nvp i="1" n="BrowserName" v="IE 7" /> <nvp i="2" n="BrowserVersion" v="7.4.5678" /> … <nvp i="24" n="VideoUrlEx" v="http://www.phelpsvideo.com" /> <nvp i="25" n="ServerLogTime" v="1965-11-06 00:00:00.0000000" /> </nvc>

Physical Architecture – ORCSWeb.com

Silverlight 2.0 Clients• 60% IE, 40% other

IP Load Balancer (Redundant Pair)• 5.4 million hits during peak day• 40 million unique users

Web Tier (15 Web Servers)• WS2K8, IIS 7.0, ASP.NET, WCF• SQL2K8 SSB Initiator Queues

Data Tier (Write Only)• WS2K8, SQL2K8• SQL2K8 SSB Target Queue, RawLog Table

Data Warehouse (Read Only)• WS2K8, SQL2K8, SSIS, SSRS, SSAS• RawLog Dimensional Model

End-To-End Solution Scope

Collect

Submit

Log

Transform

Report

Respond

Demo – QoS Logging Service

SQL Server Data Platform Basic concepts – common ground

Assumptions Workloads

Design patterns for scale Functional partitioning

Case study 1 – A large US stock exchange Messages connect the functional pieces

Case Study 2 – Beijing Olympics Monitoring Data partitioning and transactions

Case study 3 – MySpace.com Summary

Outline

Properties of an entity: A “data group” scoped to reside in a node Identified by a globally unique id Scoped to preserve locality of transactions + operations

throughout partitions Entities have a unique id

Entities may span multiple tables tables must share the unique entity id

Data PartitioningEntities are the units of partitioning

The application’s data is factored into entities, eachof which has a unique id

Each entity will reside on a single node (ignoring replication & H/A)

EntityId = “A21”

EntityId = “W47”

EntityId = “Q17”

EntityId = “U15”

Entity id defines the scope that cannot be fragmented partition functions based on the entity id

Scalable code and apps Can assume entities are local to a node; work on an entity at once Never operate on more than one entity at once

Entities and PartitioningEntities migrate across nodes as a unit

Entity“JKL”

Entity“EFG”

Entity“FXQ”

Entity“ABC”

Entity“DEF”

Entity“XYZ”

Entity“LMN”

Entity“XYZ”

Entity“LMN”

Entity“ABZ”

Entity“GHI”

Entity“RST”

Entity“XYZ”

Entity“RST”

Entity“LMN”

Entity“JKL”

Entity“RAA”

Entity“KZU”

Entity“JAA”

Entity“NAO”

Entity“MOE” No promise

that twodifferententities stayon the samenode!!

Entity“GHI”

Entity“FAW”

A transaction may update a single entity Business operations work on single entities A transaction must not ever update two entities

Even if the two live on one node today Tomorrow, they may repartition to different nodes

Minimize or avoid distributed transactions

Entities and TransactionsLocality is key to unlimited scale

Entity“A21”

Entity“D24”

Transaction

MySpace.com

Hala Al-AdwanVice President of Data

customer

MySpace is your space… MySpace is the country’s most trafficked site on the Internet 25% of Americans are on MySpace, in the UK it’s as common to have a

MySpace as it is to own a dog MySpace has nearly 122 million monthly active users around

the globe On average 300,000 new people sign up to MySpace every day

How much space does MySpace take up? MySpace is one of the fastest growing websites of all time:

100 Billion rows of data 14 Billion comments on the site 20 Billion mails on the site total 50 Million mails per day (more than Yahoo, Hotmail, or Google) 10 Billion friend relationships 1.5 Billion images 8 Million images uploaded daily 60,000 new videos uploaded to MySpaceTV daily More than 5 million artists and bands on MySpace Music

MySpaceA Place for Friends

MySpaceA Place for Databases Database classifications using SQL Server 2005:

Database Storage: 3Par SAN, 6 frames, 1,120 drives/frame IOPS on all SAN frames, 184k per second Average, 280k per second Peak

MySpace DB AverageConnections/Server

AverageRequests/sec/Server

Profile 6,800 1,100 Mail 4,400 775 Shared 2,000 1,600 Features 800 400 Security 4,800 3,700 Search 300 500 Browse 80 500 Dispatcher 6 1200

MySpace System Architecture

MySpace.com Web

Server Tier Service

Layer

Cache

Persistent Data Store

User Data

Pre-populator

Transaction Manager

Service Dispatcher

MySpace Database Partitioning

•User Data – profiles, messaging•Feature Data – music, videos, IM•Read only Data – browse, search

Functional Partitioning

•By million userID ranges•By modulo of userID

User Partitioning

•Horizontal table partitioning (poor man’s partitioning)•Vertical table partitioning

Table Partitioning

Yay! Asynchronous transactional communication between databases

Boo! Unicast messages: SSB requires a physical route between each service and database instance

Solution: Service Dispatcher Centralized SSB routes maintained in a central

db farm with gateway services on each db Multicast messaging Abstracts complex SSB components using a set

of API stored procedures allowing for fast application development

Service Dispatcher: Service Broker ala MySpace

Service Dispatcher

Initiator Database Target Database

Dispatcher Database

Client Initiator Service

Client Target Service

Gateway

Gateway

Gateway

SQL Server Data Platform Basic concepts – common ground

Assumptions Workloads

Design patterns for scale Functional partitioning

Case study 1 – A large US stock exchange Messages connect the functional pieces

Case Study 2 – Beijing Olympics Monitoring Data partitioning and transactions

Case study 3 – MySpace.com Summary

Outline

SQL Data Platform Comprehensive – any place, any type, any scale Solves the majority of scaling challenges

automatically Largest scale apps and services require careful

design Design patterns for scalability

Partitioning – functional, data, transactions Messaging across functional components

Patterns illustrated by existing large-scale apps

Summary

Evals & Recordings

Please fill

out your

evaluation for

this session at:

This session will be available as a recording at:

www.microsoftpdc.com

Please use the microphones provided

Q&A

Microsoft SQL Server 2008 case studies http://www.microsoft.com/sqlserver/2008/en/

us/case-studies.aspx

SQL Server best practices http://technet.microsoft.com/en-us/sqlserver/

bb671430.aspx

SQL Server Customer Advisory Team http://sqlcat.com/Default.aspx

PC39 Inside the Olympics: An Architecture and Development Review, Eric Schmidt, Wednesday 1:15-2:30 pm, Room 411

Resources

Microsoft SQL Server 2008: New and Future T-SQL Programmability – Michael Wang

SQL Server 2008: Enabling Developers to Go Beyond Relational – Michael Rys

Microsoft SQL Server 2008: Deep Dive into Spatial Data – Isaac Kunen Microsoft SQL Server 2008: Developing Secure Applications

– Il-Sung Lee Microsoft Sync Framework Advances – Lev Novik Microsoft SQL Server: Data-Driven Applications from Device to Cloud -

Dave Campbell Under the Hood: Building SQL Server Data Services – Istvan Cseri and

Gopal Kakivaya SQL Server Data Services: Tips and Tricks for High-Throughput Data-

Driven Applications – David Robinson SQL Server Data Services: Futures – Patrick McElroy A Lap around SQL Server Data Services – Soumitra Sengupta

Related SQL Server Talks

AppendixDetailed data on SAP benchmarks

Certification Number 1998012 SAP SD standard R/3 3.1H application benchmark in 3-Tier configuration certified on June 15th, 1998 with Number of benchmark users & comp.: 1,392 SD (Sales & Distribution) with an average dialog response time: 1.901seconds running Windows NT4 SQL Server7EE on RDBMS database server. Configuration: RDBMS server: Compaq Proliant 5500R6/200, 4-way SMP, Pentium Pro, 0.2GHz, 1 MB L2 cache, 4 GB main memory. For more details, see http://www.sap.com/benchmark

Certification Number 1998036 SAP SD standard R/3 3.1H application benchmark in 3-Tier configuration certified on July 9th, 1998 with Number of benchmark users & comp.: 2,400 SD (Sales & Distribution) with an average dialog response time: 1.89seconds running Windows NT4 SQL Server7EE on RDBMS database server. Configuration: RDBMS server: Unisys Aquanta QS/2, 4-way SMP, Xeon II, 0.4GHz, 1 MB SLC, 4 GB main memory. For more details, see http://www.sap.com/benchmark

Certification Number 2000009: SAP SD standard R/3 4.0Bapplication benchmark in 3-Tier configuration certified on March 31, 2000 with Number of benchmark users & comp.: 7,500 SD (Sales & Distribution) with an average dialog response time: 1.73 seconds running Windows 2003 Enterprise Edition SQL Server 2000 on RDBMS database server. Configuration: RDBMS server: HP ProLiant Model 8500, 8-way SMP, Intel Pentium III, 0.7GHz, 2 MB L2 cache, 4 GB main memory. For more details, see http://www.sap.com/benchmark

Certification Number 2003039: SAP SD standard R/3 Enterprise 4.70 application benchmark in 3-Tier configuration certified on July 14, 2003 with Number of benchmark users & comp.: 11,200 SD (Sales & Distribution) with an average dialog response time: 1.87 seconds running Windows 2000 Enterprise Edition SQL Server 2000 on RDBMS database server. Configuration: RDBMS server: HP ProLiant Model DL760 G2, 8-way SMP, Intel Xeon MP, 2.8 GHz, 2 MB L3 cache, 8 GB main memory. For more details, see http://www.sap.com/benchmark

(2) Certification Number 2005030: SAP SD standard R/3 Enterprise 4.70 application benchmark in 3-Tier configuration certified on June 27, 2005 with Number of benchmark users & comp.: 18,000 SD (Sales & Distribution) with average dialog response time: 1.87 seconds running Windows Server 2003 Enterprise Edition (64-bit) and SQL Server 2005 (64-bit) on RDBMS server. Configuration: Database server: HP ProLiant DL585, 4-way SMP, Dual-core AMD Opteron processor Model 875 (2.2 GHz), 128 KB L1 cache, 2 MB L2 cache, 32 GB main memory. For more details, see http://www.sap.com/benchmark

(3) Certification Number 2008003: SAP SD standard SAP ERP 6.0 (2005) application benchmark in 3-Tier configuration certified on 02/26/08 with Number of benchmark users & comp.: 34,000 SD (Sales & Distribution) with an average dialog response time: 1.99 seconds running Windows Server 2008 Enterprise Edition (64-Bit) and SQL Server 2008 (64-bit) on RDBMS database server. Hardware configuration of RDBMS server: HP ProLiant BL680c G5, 4 socket/16 core/16 thread Quad-Core Intel Xeon E7340 / 2.40GHz, 64GB RAM. For more details, see http://www.sap.com/benchmark

© 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market

conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.