ScaleBase Webinar 8.16: ScaleUp vs. ScaleOut
-
Upload
scalebase -
Category
Technology
-
view
106 -
download
1
description
Transcript of ScaleBase Webinar 8.16: ScaleUp vs. ScaleOut
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
22
Thank You