ScaleBase Webinar 8.16: ScaleUp vs. ScaleOut


Published on

Published in: Technology
  • Be the first to comment

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

No notes for slide

ScaleBase Webinar 8.16: ScaleUp vs. ScaleOut

  1. 1. WebinarScaling MySQL: Scale Up versus Scale OutAugust 16, 2012
  2. 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)2
  3. 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.3
  4. 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 critical4
  5. 5. Big Data = Big Scaling Needs Big Data = Transactions + Interactions + Observations Sensors/RFID/Devices Mobile Web User Generated Content Spatial & GPS Coordinates BIG DATAPetabytes User Click Stream Sentiment Social Interactions & Feeds Web Logs Dynamic Pricing Search Marketing WEB Offer History A/B Testing Affiliate NetworksTerabytes External Demographics Segmentation Customer Touches CRM Business Data Offer Details Support Contacts FeedsGigabytes HD Video, Audio, Images Behavioral ERP Purchase Detail Targeting Speech to Text Purchase Record Product/Service Logs Payment Record Dynamic Funnels SMS/MMSMegabytes Increasing Data Variety and Complexity 5 The 451 Group & Teradata
  6. 6. Scalability PainInfrastructureCost $ Large You just lost Capital customers Expenditure Predicted Demand Opportunity Traditional Cost Hardware Actual Demand Dynamic Scaling time 6
  7. 7. Scale Up innodb_buffer_pool_size Instance query_cache_size Tuning EXPLAIN SSD SQL Tuning Indexes SELECT * DISTINCT vs. GROUP BY Hardware Partitioning Upscale7
  8. 8. Partitioning Performance • See excellent presentation by Giuseppe Maxia from 2010 – mysql-51-and-55 Engine No Partitions Partitions InnoDB 4min 30s 13.19s MyISAM 25.03s 4.45s • Keeps data objects at their sweet spot • Helps fit indexes in RAM • Distributes sessions load over disks8
  9. 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: scalability-on-multi-core-servers/9
  10. 10. Scale Up Pros & ConsPros ConsMay result in major performance Tedious, never ending…improvementsMostly transparent to the application SQL modifications are not always an optionHW upscale is easy Expensive Requires unique skill set Requires downtime Limited. At one (near) point – the database engine itself becomes the bottleneck10
  11. 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 tasks11
  12. 12. The Database Engine is the Bottleneck • Every write operation is At Least 4 write operations inside the DB: – Data segment – Index segment – Undo segment Now multiply – Transaction log by 10TB and • And Multiple Activities in the DB engine memory: 10,000 – Buffer management concurrent – Locking sessions – Thread locks/semaphores – Recovery tasks12
  13. 13. Scale Out (two methods) Read Write Read/Write1 Splitting Replication Data Distribution2 (sharding) 13
  14. 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 changes14
  15. 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’t-ever-ever-write-your-own-sharding-code15
  16. 16. Scale Out Features and Benefits Feature Benefit Automatic data distribution (sharding) Scale data-, read-, write- intensive applications Great performance of cross-db queries & maintenance  Parallel query execution commands Support of sophisticated cross-db queries, even with ORDER  Query result aggregation BY, GROUP BY, LIMIT, Aggregate functions… Flexibility: no need to over-provision  Online data redistribution 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 TCO16
  17. 17. Scale Out Provides Immediate & Tangible Value Application Server Database A Standby A Application Server Database B Standby B Database C Standby C BI Database D Standby D Management17
  18. 18. Typical Scale Out (ScaleBase) Deployment Application Server Database A Standby A ScaleBase Central Management Application Server Database B Standby B ScaleBase Data Traffic Manager Database C Standby C BI Database D Standby D Management18
  19. 19. Scaling Out Achieves Unlimited Scalability 160000 140000 120000 100000Throughput 84000 80000 Throughput (TPM) Total DB Size (MB) 60000 60000 # Connections 48000 40000 36000 24000 2500 20000 2000 12000 1500 1500 6000 1000 0 500 500 1 2 4 6 8 10 14 Number of Databases 19
  20. 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 infrastructure20
  21. 21. Questions (please enter directly into the GTW side panel)617.630.2800www.ScaleBase.comdoron.levari@scalebase.compaul.campaniello@scalebase.com21
  22. 22. Thank You22