Webinar Scaling MySQL: Scale Up versus Scale Out

August 16, 2012

2

Agenda

1. Who We Are 2. The Scalability Problem

3. Scale Up vs. Scale Out

4. Customer ROI/Case Studies

5. Q & A

(please type questions directly into the GoToWebinar side panel)

3

Who We Are

Presenters: Paul Campaniello,

VP of Global Marketing 25 year technology veteran with marketing experience at Mendix, Lumigent, Savantis and Precise.

Doron Levari, Founder A technologist and long-time

veteran of the database industry. Prior to founding ScaleBase, Doron

was CEO to Aluna.

4

Pain Points – The Scalability Problem

• Thousands of new online and mobile

apps launching every day

• Demand climbs for these apps and

databases can’t keep up

• App must provide uninterrupted

access and availability

• Database performance and

scalability is critical

5

Big Data = Big Scaling Needs

The 451 Group & Teradata

Big Data = Transactions + Interactions + Observations

BIG

DA

TA

ER

P

CR

M

WE

B

Petabytes

Terabytes

Gigabytes

Megabytes

Increasing Data Variety and Complexity

Purchase Detail

Purchase Record

Payment Record

Segmentation

Offer Details

Customer Touches

Support Contacts

Web Logs

Offer History A/B Testing

Dynamic Pricing

Affiliate Networks

Search Marketing

Behavioral

Targeting

Dynamic

Funnels

Sensors/RFID/Devices

User Click Stream

Mobile Web

Sentiment

User Generated Content

Social Interactions & Feeds

Spatial & GPS Coordinates

External

Demographics

Business Data

Feeds

HD Video, Audio, Images

Speech to Text

Product/Service Logs

SMS/MMS

6

Scalability Pain

You just lost

customers

Infrastructure Cost $

time

Large

Capital

Expenditure

Opportunity

Cost

Predicted Demand

Traditional Hardware

Actual Demand

Dynamic Scaling

7

Scale Up

Instance Tuning

SQL Tuning

Partitioning Hardware Upscale

SSD

http://forge.mysql.com/wiki/Top10SQLPerformanceTips

innodb_buffer_pool_size

query_cache_size

EXPLAIN

Indexes

SELECT *

DISTINCT vs. GROUP BY

8

Partitioning Performance

• See excellent presentation by Giuseppe Maxia from 2010

– http://www.slideshare.net/datacharmer/partitions-performance-with-

mysql-51-and-55

• Keeps data objects at their sweet spot

• Helps fit indexes in RAM

• Distributes sessions load over disks

Engine No Partitions Partitions

InnoDB 4min 30s 13.19s

MyISAM 25.03s 4.45s

9

Scaling Up Hardware

• Usually DB gets the strongest servers

• However – there is a limit to how much performance

improvement can be derived from increasing hardware

• Some data:

http://www.mysqlperformanceblog.com/2011/01/26/modeling-innodb-scalability-on-multi-core-servers/

10

Scale Up Pros & Cons

Pros Cons

May result in major performance improvements

Tedious, never ending…

Mostly transparent to the application SQL modifications are not always an option

HW upscale is easy Expensive

Requires unique skill set

Requires downtime

Limited. At one (near) point – the database engine itself becomes the bottleneck

11

The Database Engine is the Bottleneck...

• Every write operation is At Least 4 write operations inside the DB:

– Data segment

– Index segment

– Undo segment

– Transaction log

• And Multiple Activities in the DB engine memory:

– Buffer management

– Locking

– Thread locks/semaphores

– Recovery tasks

12

• Every write operation is At Least 4 write operations inside the DB:

– Data segment

– Index segment

– Undo segment

– Transaction log

• And Multiple Activities in the DB engine memory:

– Buffer management

– Locking

– Thread locks/semaphores

– Recovery tasks

The Database Engine is the Bottleneck

Now multiply by 10TB and

10,000 concurrent

sessions

13

Scale Out (two methods)

Write

Read

Replication

Read/Write Splitting

Data Distribution (sharding)

1

2

14

Read/Write Splitting

• Write to master, read from (1 or more) slaves

• Good for scaling reads

– Although big data is still big data

• Not good for scaling writes

• Many issues:

– A-synchronous replication’s lag – read might not be up to date

– A “query my update” inside a transaction will always be out of date

– Adhere transactions isolation with stickiness?

– Requires code changes

15

Data Distribution (sharding)

• If done right and all the way:

– The ultimate scaling machine

– Provides significant performance improvements

– The only way to really improve read and also writes

• However if done in-house, (and not done properly), it can cause:

– Substantial development efforts

– Silos of data with no merging

http://www.scalebase.com/don’t-ever-ever-write-your-own-sharding-code

16

Scale Out Features and Benefits

Feature Benefit

Automatic data distribution (sharding) Scale data-, read-, write- intensive applications

Parallel query execution Great performance of cross-db queries & maintenance commands

Query result aggregation Support of sophisticated cross-db queries, even with ORDER BY, GROUP BY, LIMIT, Aggregate functions…

Online data redistribution Flexibility: no need to over-provision No downtime

Read/Write splitting Easily scale read-intensive applications

Replication lag-based routing Improves data consistency and isolation

Read stickiness after writes Ensure consistent and isolated database operation

100% compatible MySQL proxy Applications unmodified Standard MySQL tools and interfaces

MySQL databases untouched Data is safe within MySQL InnoDB/MyISAM/any

Data distribution review and analysis Optimization of data distribution policy

Data consistency verifier Validate system-wide data consistency

Real-time monitoring and alerts Simplify management, reduce TCO

17

Scale Out Provides Immediate & Tangible Value

Application Server

BI

Management

Application Server

Database A Standby A

Database B Standby B

Database C Standby C

Database D Standby D

18

Typical Scale Out (ScaleBase) Deployment

Database B

Database C

Database D

Database A Standby A

Standby B

Standby C

Standby D

ScaleBase

Data Traffic Manager

Application Server

BI

Management

Application Server

ScaleBase

Central Management

19

Scaling Out Achieves Unlimited Scalability

6000 12000

24000

36000

48000

60000

84000

500 500 1000

1500 1500 2000

2500

0

20000

40000

60000

80000

100000

120000

140000

160000

1 2 4 6 8 10 14

Thro

ugh

pu

t

Number of Databases

Throughput (TPM)

Total DB Size (MB)

# Connections

20

Summary

• Database scalability is a significant problem

– Growing trends such as Big Data and mobile only compound it

• Scale Up helps somewhat, but has limitations

• Scale Out provides a longer term and more cost effective solution

• ScaleBase has an effective scale out solution with a proven ROI

– ScaleBase improves performance and requires NO changes to your

existing infrastructure

21

Questions (please enter directly into the GTW side panel)

617.630.2800

www.ScaleBase.com

doron.levari@scalebase.com

paul.campaniello@scalebase.com

22

Thank You