DBA Training Session:-

Horizontal and Vertical Scaling on SQL

Server
Date: 23 NOV 2023
N SANJAY KUMAR
Outline
• Scalable services
Building scalable web
services
• A relatively easy problem?
• Why?
• HTTP: stateless, request-response protocol
• decoupled, independent requests
• How?
• divide and conquer
• replicate, partition, distribute, load balance

• In the end you want to build a Web 2.0 app that can serve millions of users with ZERO
downtime
The Variables
• Scalability - Number of users / sessions / transactions / operations
the entire system can perform
• Performance – Optimal utilization of resources
• Responsiveness – Time taken per operation
• Availability - Probability of the application or a portion of the
application being available at any given point in time
• Downtime Impact - The impact of a downtime of a
server/service/resource - number of users, type of impact etc
• Cost
• Maintenance Effort
High: scalability, availability, performance & responsiveness
Low: downtime impact, cost & maintenance effort
The Factors
• Platform selection
• Hardware
• Application Design
• Database/Data store Structure and Architecture
• Deployment Architecture
• Storage Architecture
• Abuse prevention
• Monitoring mechanisms
• … and more
Let's Start …
• We will now build an example architecture for an
example app using the following iterative incremental
steps –
• Inspect current Architecture
• Identify Scalability Bottlenecks
• Identify SPOFs and Availability Issues
• Identify Downtime Impact Risk Zones
• Apply one of -
• Vertical Scaling
• Vertical Partitioning
• Horizontal Scaling
• Horizontal Partitioning
• Repeat process
Step 1 – Let's Start …

Appserver &
DBServer
Step 2 – Vertical Scaling

Appserver, CPU
DBServer
CPU
RAM RAM
Step 2 - Vertical Scaling
• Introduction
• Increasing the hardware resources without
changing the number of nodes
• Referred to as “Scaling up” the Server
Appserver, CPU CPU
DBServer
CPU CPU • Advantages
RAM RAM
• Simple to implement
RAM RAM • Disadvantages
• Finite limit
• Hardware does not scale linearly
(diminishing returns for each incremental
unit)
• Requires downtime
• Increases downtime Impact
• Incremental costs increase exponentially
 Step 3 – Vertical Partitioning
(Services)
• Introduction
AppServer
• Deploying each service on a separate node

DBServer • Positives
• Increases per application Availability
Example • Task-based specialization, optimization and
 www.blah.com tuning possible
 mail.blah.com • better cache performance
 • Reduces context switching
images.blah.com
• No changes to App required
 shopping.blah.com
• Flexibility increases
 my.blah.com
 etc. etc.
Vertical Partitioning (Services)

• Disadvantages
• lower peak capacity
• sub-optimal resource utilization
• coarse load balancing across servers/services
• finite Scalability
• management costs
Understanding Vertical
Partitioning
• The term Vertical Partitioning denotes –
• Increase in the number of nodes by distributing the tasks/functions
• Each node (or cluster) performs separate Tasks
• Each node (or cluster) is different from the other

• Vertical Partitioning can be performed at various layers (App /

Server / Data / Hardware etc.)
Step 4 – Horizontal Scaling (App
Server)
Load Balancer • Introduction
• Increasing the number of nodes of the
App Server through Load Balancing
AppServer AppServer AppServer • Referred to as “Scaling out” the App
Server

DBServer
Understanding Horizontal
Scaling
• The term Horizontal Scaling denotes –
• Increase in the number of nodes by replicating the nodes
• Each node performs the same Tasks
• Each node is identical
• Typically, the collection of nodes maybe known as a cluster
• Also referred to as “Scaling Out”

• Horizontal Scaling can be performed for any particular type of

node (AppServer / DB Server etc.)
Load Balancer – Hardware vs
Software
• Hardware Load balancers are faster
• Software Load balancers are more customizable
• With HTTP Servers load balancing is typically combined with
http accelerators
Load Balancer – Session
Management
Sticky Sessions

• Sticky Sessions User 1 User 2

• Requests for a given user are
sent to a fixed App Server
• Observations
Load Balancer
• Asymmetrical load
distribution
• Downtime Impact – Loss of
session data AppServer AppServer AppServer
Load Balancer – Session
Management
Central Session Storage

• Central Session Store Load Balancer

• Introduces SPOF
• An additional variable AppServer AppServer AppServer
• Session reads and writes generate
Disk + Network I/O
• Also known as a Shared Session Session Store
Store Cluster
Load Balancer – Session
Management
Clustered Session Management
• Clustered Session Management Load Balancer
• Easier to setup
• No SPOF
• Network I/O increases exponentially AppServer AppServer AppServer
with increase in number of nodes
• In very rare circumstances a request
may get stale session data
• User request reaches
subsequent node faster than
intra-node message
• Intra-node communication fails
Load Balancer – Session
Management
• Recommendation
• Use Clustered Session Management if you have –
• Smaller Number of App Servers
• Fewer Session writes
• Use a Central Session Store elsewhere
• Use sticky sessions only if you have to
Load Balancer – Removing SPOF
Active-Passive LB

• In a Load Balanced App Server Users

Cluster, the LB is an SPOF

• Active-Active nevertheless Load Balancer Load Balancer
assumes that each LB is
independently able to take up AppServer AppServer AppServer
the load of the other
• If one wants ZERO downtime, Active-Active LB
then Active-Active becomes
Users
truly cost beneficial only if
multiple LBs (more than 3 to 4)
are daisy chained as Active-
Load Balancer Load Balancer
Active forming an LB Cluster

AppServer AppServer AppServer

Step 4 – Horizontal Scaling (App
Server)
• At the end of Step 4
Load Balanced
App Servers • Positives
• Increases Availability and Scalability
• No changes to App required
• Easy setup
• Negatives
DBServer
• Finite Scalability
Step 5 – Vertical Partitioning
(Hardware)
Load Balanced
App Servers
• Introduction
• Partitioning out the Storage function
using a SAN
• Positives
• Allows “Scaling Up” the DB Server
DBServer • Boosts Performance of DB Server
• Negatives
SAN • Increases Cost
Step 6 – Horizontal Scaling (DB)
Load Balanced
App Servers • Introduction
• Increasing the number of DB nodes
• Referred to as “Scaling out” the DB
Server
• Options
DBServer DBServer DBServer • Shared nothing Cluster
• Real Application Cluster (or Shared
Storage Cluster)
SAN
Shared Nothing Cluster
• Each DB Server node has its
own complete copy of the DBServer DBServer DBServer
database Database Database Database
• Nothing is shared between the
DB Server Nodes
Note: Actual DB files maybe
• This is achieved through DB stored on a central SAN
Replication at DB / Driver /
App level or through a proxy
• Supported by most database
software natively or through
3rd party software
Replication Considerations
• Master-Slave
• Writes are sent to a single master which replicates the data to multiple
slave nodes
• Replication maybe cascaded
• Simple setup
• No conflict management required

• Multi-Master
• Writes can be sent to any of the multiple masters which replicate them
to other masters and slaves
• Conflict Management required
• Deadlocks possible if same data is simultaneously modified at multiple
places
Replication Considerations
• Asynchronous
• Guaranteed, but out-of-band replication from Master to Slave
• Master updates its own db and returns a response to client
• Replication from Master to Slave takes place asynchronously
• Faster response to a client
• Slave data is marginally behind the Master
• Requires modification to App to send critical reads and writes to
master, and load balance all other reads
Replication Considerations
• Synchronous
• Guaranteed, in-band replication from Master to Slave
• Master updates its own db, and confirms all slaves have updated their
db before returning a response to client
• Slower response to a client
• Slaves have the same data as the Master at all times
• Requires modification to App to send writes to master and load balance
all reads
Replication Considerations
• Replication at RDBMS level
• Support may exist in RDBMS or through 3rd party tool
• Faster and more reliable
• App must send writes to Master, reads to any db and critical
reads to Master
• Replication at Driver level
• Driver layer ensures
• writes are performed on all connected DBs
• Reads are load balanced
• Critical reads are sent to a Master
• In most cases RDBMS agnostic
• Slower and in some cases less reliable
Real Application Cluster
• All DB Servers in the cluster share
a common storage area on a SAN DBServer DBServer DBServer

• All DB servers mount the same

block device
• The filesystem must be a Database
SAN
clustered file system (eg GFS)
• Currently only supported by
Oracle Real Application Cluster
• Can be very expensive (licensing
fees)
Recommendation
• Try and choose a DB which Load Balanced
natively supports Master-Slave App Servers

replication
• Use Master-Slave Async
replication
• Write your layer to ensure
DBServer
• writes are sent to a single DB
• reads are load balanced DBServer DBServer

• Critical reads are sent to a master

Writes & Critical Reads
Other Reads
Step 6 – Horizontal Scaling (DB)
Load Balanced
App Servers • Our architecture now looks like this
• Positives
• As Web servers grow, Database nodes can be
added
• DB Server is no longer SPOF
DB DB DB
• Negatives
DB Cluster • Finite limit

SAN
Step 7 – Vertical / Horizontal
Partitioning (DB)
Load Balanced
App Servers • Introduction
• Increasing the number of DB Clusters by
dividing the data
• Options
DB DB DB • Vertical Partitioning - Dividing tables /
columns
DB Cluster
• Horizontal Partitioning - Dividing by rows
(value)
SAN
Vertical Partitioning (DB)
• Take a set of tables and move them
onto another DB App Cluster
• Eg in a social network - the users table
and the friends table can be on
separate DB clusters
• Each DB Cluster has different tables DB Cluster 1 DB Cluster 2

• Application code or Driver code or a Table 1

Table 2
Table 3
Table 4
proxy knows where a given table is
and directs queries to the
appropriate DB
• Can also be done at a column level
by moving a set of columns into a
separate table
Vertical Partitioning (DB)
• Negatives App Cluster
• One cannot perform SQL joins or
maintain referential integrity
• Finite Limit DB Cluster 1 DB Cluster 2
Table 1 Table 3
Table 2 Table 4
Horizontal Partitioning (DB)
• Take a set of rows and move them
onto another DB App Cluster
• Eg in a social network – each DB Cluster
can contain all data for 1 million users
• Each DB Cluster has identical tables
DB Cluster 1 DB Cluster 2
• Application code or Driver code or a
proxy knows where a given row is Table 1
Table 2
Table 1
Table 2
and directs queries to the Table 3 Table 3
appropriate DB Table 4 Table 4
1 million users 1 million users
• Negatives
• SQL unions for search type queries
must be performed within code
Horizontal Partitioning (DB)
• Techniques
• FCFS
• 1st million users are stored on cluster 1 and the next on cluster 2
• Round Robin
• Least Used (Balanced)
• Each time a new user is added, a DB cluster with the least users is chosen
• Hash based
• A hashing function is used to determine the DB Cluster in which the user data
should be inserted
• Value Based
• User ids 1 to 1 million stored in cluster 1 OR
• all users with names starting from A-M on cluster 1
• Except for Hash and Value based all other techniques also require an
independent lookup map – mapping user to Database Cluster
• This map itself will be stored on a separate DB (which may further need
to be replicated)
Step 7 – Vertical / Horizontal
Partitioning (DB) • Our architecture now looks like
Load Balanced
App Servers this
Lookup
Map
• Positives
• As App servers grow, Database
Clusters can be added
DB DB DB DB DB DB • Note: This is not the same as
table partitioning provided by
DB Cluster DB Cluster
the db (eg MSSQL)
• We may want to further
SAN
segregate these into Sets, each
serving a collection of users
(refer next slide
Step 8 – Separating Sets
• Now we consider each deployment as a single Set serving a
collection of users Global
Lookup
Global Redirector Map

Load Balanced Load Balanced

App Servers App Servers
Lookup Lookup
Map Map

DB DB DB DB DB DB DB DB DB DB DB DB

DB Cluster DB Cluster DB Cluster DB Cluster

SAN SAN

SET 1 – 10 million users SET 2 – 10 million users

Creating Sets
• The goal behind creating sets is easier manageability
• Each Set is independent and handles transactions for a set of
users
• Each Set is architecturally identical to the other
• Each Set contains the entire application with all its data
structures
• Sets can even be deployed in separate datacenters
• Users may even be added to a Set that is closer to them in
terms of network latency
Step 8 – Horizontal Partitioning
(Sets)
Global Redirector • Our architecture now looks like
this
• Positives
App Servers App Servers • Infinite Scalability
Cluster Cluster
• Negatives
DB Cluster DB Cluster • Aggregation of data across sets is
complex
DB Cluster DB Cluster • Users may need to be moved
across Sets if sizing is improper
SAN SAN • Global App settings and
preferences need to be replicated
SET 1 SET 2 across Sets
Questions?

Thank you!