My sql cluster case study apr16
11 likes869 views
The document discusses the introduction and implementation of MySQL Cluster, emphasizing its architecture, use cases, and benchmarking processes for scalability, high availability, and latency demands. It highlights various case studies, including PayPal and Big Fish, showcasing how MySQL Cluster met specific database requirements and improved performance. Additionally, the document mentions enhancements in MySQL 5.7, including optimizer improvements and new features aimed at increasing efficiency and performance.
My sql cluster case study apr16
- 1. MySQL Cluster Case Study Sumi Ryu MySQL APAC Sales Consultant [email protected] 16th April 2015
- 2. Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle. 15/04/2015 Copyright 2015, oracle and/or its affiliates. All rights reserved 2
- 3. MySQL Replication MySQL Fabric DRBD Windows/S olaris/Clust erware Clustering or Oracle VM MySQL Cluster MySQL HA Solutions 19th February 2015 9 9 . 9 9 9 % Copyright 2015, Oracle and/or its affiliates. All rights reserved 3
- 4. MySQL Cluster Architecture MySQL Cluster Data Nodes Clients Application Layer Management Data Layer
- 5. MySQL Cluster 도입목적 15/04/2015 Copyright 2015, oracle and/or its affiliates. All rights reserved 5
- 6. MySQL Cluster 도입 목적 High Availability Scalability Latency Demands 15/04/2015 Copyright 2015, oracle and/or its affiliates. All rights reserved 6
- 7. When to Consider MySQL Cluster Scalability demands Sharding for write performance? Latency demands Cost of each millisecond? Uptime requirements Cost per minute of downtime? Failure versus maintenance? Application agility Developer languages and frameworks? SQL or NoSQL? 15/04/2015 Copyright 2015, oracle and/or its affiliates. All rights reserved 7
- 8. MySQL Cluster 도입 결정 15/04/2015 Copyright 2015, oracle and/or its affiliates. All rights reserved 8 • MySQL 팀에 연락해서 대상 Application이 MySQL Cluster에 적합한지 상담을 받아보실 것을 권장 – 스키마, 주요 10개 또는 20개 쿼리에 대한 정보 – 대상 데이터 용량 – 연간 데이터 증가 추정치
- 9. MySQL Cluster Benchmark Test결정 15/04/2015 Copyright 2015, oracle and/or its affiliates. All rights reserved 9
- 10. Benchmark Test 개요 15/04/2015 Copyright 2015, oracle and/or its affiliates. All rights reserved 10 • Benchmark Test 에 대한 간략한 설명을 기술 – 목적 : 어떤 것을 측정하기위한 테스트인지 기술, 목적을 분명히 하는 것이 중요합니다. 그래야 테스트 후 솔루션의 적합성을 결정할 수 있습니다. – 장소 및 일정 – 테스트 인력 및 역할 : 특히 역할부분을 분명히해야 빠지는 부분이 없이 테스트가 원활히 진행 할 수 있습니다. 특히, Application 쪽에서 개발이 필요할 경우 명시 및 담당자 기술 업무 담당자 내용 Data loading Sumi Ryu 기존 MySQL DB의 데이터를 Cluster 로 데이터를 로딩
- 11. Benchmark Test 환경 15/04/2015 Copyright 2015, oracle and/or its affiliates. All rights reserved 11 • Benchmark Test 구성환경에 대해 기술 – 구성도가 포함되면 시각적이며 좋음 – OS 및 시스템 환경정보, 구체적일 수록 좋음. 예)메모리, CPU, Network, 등. – 테스트 서버별 설치 SW 명시 예)MySQL Cluster 7.3.x 버전, MySQL팀에서 몇일에 설치완료 – Application 쪽도 반드시 명시가 필요함
- 12. Benchmark Test 구성도(샘플) 15/04/2015 Copyright 2015, oracle and/or its affiliates. All rights reserved 12 Data Node 1 Cluster Mgmt Data Node 3 SQL node 1 SQL node 2API Nodes Data Node 2 Data Node 4 Cluster Mgmt
- 13. Benchmark Test 항목 15/04/2015 Copyright 2015, oracle and/or its affiliates. All rights reserved 13 • Benchmark Test 를 통해서 확인한 결과 항목에 대해 기술, 일반적으로 동시 connection 수에 따른 아래 항목들을 점검함. – 응답시간 – 처리량 (QPS, TPS) – 시스템 자원 사용량 결과가 도출되면 각각의 항목별 그래프로 작성을 해서 비교할 수 있게 하는 것이 좋다.
- 14. Benchmark Test 시나리오 15/04/2015 Copyright 2015, oracle and/or its affiliates. All rights reserved 14 • Benchmark Test 에서 테스트할 시나리오를 기술한다. DBMS 테스트의 경우 CRUD에 대해 각각 테스트를 진행하며, Read의 경우엔 단순 SELECT와 복잡한 JOIN 쿼리를 테스트하는 것이 일반적인 시나리오임. – INSERT or BULK INSERT(필요할 경우) – UPDATE – DELETE – SELECT or JOIN
- 15. Benchmark Test 항목 (계속) 15/04/2015 Copyright 2015, oracle and/or its affiliates. All rights reserved 15 • 가용성 테스트 및 장애 테스트는 필요한 경우 항목을 추가해서 진행하게 됨 – Server 및 노드 장애 – Network 장애 – Database 장애 – Storage 장애 • DB 백업/복구
- 16. Benchmark Test 결과 15/04/2015 Copyright 2015, oracle and/or its affiliates. All rights reserved 16 • Benchmark Test 결과에 대해 기술한다. 이경우 초기에 가정했던 결과에 부합할 경우는 문제가 없지만 부합하지 않을 경우엔 Schema/Query 튜닝을 제안할 수도 있다. 결과에는 제안 HW 사양을 도출할 수도 있다. 테스트 결과를 기반으로 대상 시스템을 구축하기 위한 HW를 제안할 수 있다.
- 17. 제안 HW 사양 산정 샘플 15/04/2015 Copyright 2015, oracle and/or its affiliates. All rights reserved 17
- 18. HW 산정 근거- Data node 이관대상 데이터 : 90 GB, 각 data node는 64 GB Memory 90GB의 데이터를 수용하기 위해서는 4개의 data node가 필요하며, 각 data node는 별개의 물리서버에 위치한다고 가정함 1. Memory 산정 기준 - data memory : 45 GB = 64 GB * 70% - Index memory : 9 GB = 45(data memory) * 20% - 이외 memory : 10 GB - OS 및 cluster에서 내부적으로 사용하는 buffer를 위해 남겨둠 2. CPU 산정 기준 Cluster를 위한 필요 cores : 24 cores {ldm=8, tc=4, recv=2, send=2, io=1, main=1, repl=1} 15/04/2015 Copyright 2015, oracle and/or its affiliates. All rights reserved 18
- 19. Node Group Data Node 1 Data Node 구성 • Data node 1은 자신이 서비스할 active data 22.5 GB와 Data node 2 의 replica 22.5 GB를 가진다. 따라서 총 45 GB가 data 를 위해서 필요함. • data node는 각 22.5 GB씩 서비스하기때문에 전체 90GB를 4개의 data node에서 처리할 수 있다. 15/04/2015 Copyright 2015, oracle and/or its affiliates. All rights reserved 19 Fragment 1 Fragment 2’ Data Node 2 Fragment 1’ Fragment 2 Node Group Data Node 3 Fragment 3 Fragment 4’ Data Node 4 Fragment 3’ Fragment 4
- 20. HW 산정 근거- Data node (계속) 3. Disk 산정 기준 - LCP : 45 GB(data memory) * 3 = 135 GB - GCP : 45 GB - RAID 1+ 0 Total size of disk -> 180 GB *2 = 360 GB 한개의 data node 구성 시 LCP용 디스크와 GCP용 디스크는 별개의 물리 디스크로 구성하면 성능이 좋으므로 2개가 필요하며 RAID 1+0를 적용하면 4개의 물리 디스크가 필요함 한개의 물리 디스크의 용량은 최소 300 GB 4. Network Interface Card 최소 2 NIC 필요, 최소 1 GB이지만 10 GB를 추천함 5. Switch SPF를 피하기 위해 2개의 Switch로 구성할 것을 권장함 15/04/2015 Copyright 2015, oracle and/or its affiliates. All rights reserved 20
- 21. HW 산정 근거- SQL node 동시 Transaction 500 명 기준 각 SQL 노드는 동시 Transaction 250을 처리할 수 있어야 함 1. Memory 산정 기준 - SQL 노드의 경우 많은 메모리를 사용하지 않으므로, 8 GB 이상의 메모리를 할당하면 됨. 단, SQL node의 Inno DB 스토리지 엔진도 혼합해서 사용할 경우엔 데이터 사이즈를 감안해서 Innodb buffer pool에 해당하는 메모리를 정의 후 산정 2. CPU 산정 기준 테스트 결과 테스트 서버 기준으로 동시 Transaction 을 처리수가 도출되면 제안 서버 기준 250 동시 transaction 을 처리할 수 있게끔 CPU 사양도 정한다. 15/04/2015 Copyright 2015, oracle and/or its affiliates. All rights reserved 21
- 22. HW 산정 근거- SQLnode (계속) 3. Disk 산정 기준 - SSD 가 가능하다면 성능을 높일 수 있음 - 2 개의 디스크를 권장 4. Network Interface Card 최소 2 NIC 필요, 최소 1 GB이지만 10 GB를 추천함 5. Switch SPF를 피하기 위해 2개의 Switch로 구성할 것을 권장함 15/04/2015 Copyright 2015, oracle and/or its affiliates. All rights reserved 22
- 23. PAYPAL OVERVIEW • Processed $145bn in transactions (CY2012) • 22% year-on-year growth, 123m accounts, 190 markets CHALLENGES / OPPORTUNITIES • Build global fraud detection system • Track transactions & user sessions in real-time DATABASE REQUIREMENTS • Support 100TB & 100m+ users • ACID compliance • Read new write operations in <1 second, anywhere • Real-time analysis of user transaction history • Scale linearly with 99.999% uptime, in the cloud CUSTOMER PERSPECTIVE "Technologies such as MySQL Cluster enables users to get the best of both world’s…the agility of NoSQL systems with the trust, maturity and reliability of the SQL model " Daniel Austin, Chief Architect, PayPal RESULTS • 3x higher performance than design goal • Managing 40TB across multiple Clusters • Globally distributed to 5 x AWS regions • Self-healing http://www.mysql.com/customers/view/?id=1223 SOLUTIONS • MySQL Cluster 7.2 with Geo-Replication • AWS
- 24. OVERVIEW • World’s largest producer of Casual Games • Distributed 3bn games, 150 countries, 13 local sites CHALLENGES / OPPORTUNITIES • Personalizing the customer experience DATABASE REQUIREMENTS • High velocity data ingest from BI platform • Real time rendering of personalized content • Continuous availability for uninterrupted gaming • Enterprise SLAs and strong technology roadmap CUSTOMER PERSPECTIVE ”As a strategic project, We couldn’t afford to take any chances. MySQL Cluster provided us with a proven & trusted solution to meet the demands of both our business and our users" Sean Chighizola, Senior Director of DBA Group, Big Fish RESULTS • Reduce complexity with re-use of MySQL skills • Linear scaling: loading 25m – 1bn records • Developer Flexibility: SQL & NoSQL connectors • Automated on-line node additions and reconfiguration • Capacity to meet future growth http://www.mysql.com/why-mysql/case-studies/mysql-cs-bigfish.html SOLUTIONS • MySQL Cluster 7.2 CGE • MySQL Cluster Manager • MySQL 24x7 Premier Support
- 25. www.bigfishgames.com BI Platform User Database: Profiles, History, etc. MySQL Cluster Application Nodes MySQL Cluster Data Nodes Hot Spare User Analysis MySQL Cluster Manager User Sessions User Segmentation MMS Platform Personalized User Content User Data Sessions BigFish Implementation
- 26. PLAYFUL PLAY OVERVIEW • Developer of Latin America’s most popular FaceBook game • Based on El Chavo, massive success in LatAM, US and Spain CHALLENGES / OPPORTUNITIES • 2m users in 4 months, growing at 30k per day • Targeting 50m users in 5 years • Massive scale, especially of database writes • 99.999% uptime • Data integrity DATABASE REQUIREMENTS • 10k TPS on commodity hardware, in the cloud • Managing user avatars and sessions • In-App Purchases • Digital marketing + user response data CUSTOMER PERSPECTIVE "The MySQL support service has been essential in helping us for troubleshooting and giving recommendations for the production cluster, Thanks" Carlos Morales – DBA, Playfulplay.com México RESULTS • 45% improvement in performance • 80% reduction in DBA overhead • 99.999% uptime • Local language support, 24x7 https://blogs.oracle.com/MySQL/entry/mysql_cluster_powers_el_chavo SOLUTIONS • MySQL Cluster Carrier Grade Edition • MySQL Cluster Manager • MySQL Support & Consulting Services
- 27. Playful Play Architecture https://apps.facebook.com/lavecindaddeelchavo/ Co-Located MySQL Servers + Data Nodes MySQL Cluster
- 28. 28 “Since deploying MySQL Cluster as our eCommerce database, we have had continuous uptime with linear scalability enabling us to exceed our most stringent SLAs” — Sean Collier, CIO & COO, Shopatron Inc Shopatron: eCommerce Platform • Applications – Ecommerce back-end, user authentication, order data & fulfilment, payment data & inventory tracking. Supports several thousand queries per second • Key business benefits – Scale quickly and at low cost to meet demand – Self-healing architecture, reducing TCO • Why MySQL? – Low cost scalability – High read and write throughput – Extreme availability http://www.mysql.com/why-mysql/case-studies/mysql_cs_shopatron.php
- 29. MySQL 5.7 RC 15/04/2015 Copyright 2015, oracle and/or its affiliates. All rights reserved 29
- 30. MySQL 5.7 Release Candidate Available! 30 Enhanced InnoDB: faster online & bulk load operations Replication Improvements (incl. multi- source, multi-threaded slaves...) New Optimizer Cost Model: greater user control & better query performance Performance Schema Improvements MySQL SYS Schema Performance & Scalability Manageability 2 X Faster than MySQL 5.6 Improved Security: safer initialization, setup & management NEW! JSON Support (now in labs) RC And many more new features and enhancements... http://mysqlserverteam.com/the-mysql-5-7-7-release-candidate-is-available/
- 31. 0 1,00,000 2,00,000 3,00,000 4,00,000 5,00,000 6,00,000 7,00,000 8 16 32 64 128 256 512 1,024 QueriesperSecond Connections MySQL 5.7: Sysbench Read Only (Point Select) MySQL 5.7 MySQL 5.6 MySQL 5.5 MySQL 5.7: Sysbench: Read Only Intel(R) Xeon(R) CPU E7-4860 x86_64 4 sockets x 10 cores-HT (80 CPU threads) 2.3 GHz, 512 GB RAM Oracle Linux 6.5 2x Faster than MySQL 5.6 3x Faster than MySQL 5.5 645,000 QPS 31
- 32. • Optimizer and Parser refactoring – Improves readability, maintainability and stability – Cleanly separate the parsing, optimizing, and execution stages – Allows for easier feature additions, with lessened risk • New hint framework – Easier to manage – With support for additional new hints • Improved JSON EXPLAIN • EXPLAIN for running thread • New Cost based Optimizer • Generated Columns • Support for InnoDB based internal temp tables • Better ONLY_FULL_GROUP_BY mode • Better support for InnoDB & GIS • Many specific new optimizations Queries execute faster, while using less CPU and disk space! MySQL 5.7: Optimizer Improvements 33
- 33. MySQL 5.7 Optimizer: New Cost Model • More accurate cost estimates – Better decisions by the optimizer should improve query performance • Adapt to new hardware architectures – SSDs, larger memory sizes, improved caches • More maintainable cost model implementation – Avoid hard coded “cost constants” – Refactoring of existing cost model code • Configurable and tunable – mysql.server_cost and mysql.engine_cost tables – API for determining where data resides: on disk or in cache 34
- 34. Optimizer Cost Model: Performance Improvements DBT-3 (SizeFactor 10, CPU bound) 0 20 40 60 80 100 Q3 Q7 Q8 Q9 Q12 Executiontimerelativeto5.6(%) 5 out of 22 queries get a much improved query plan (others remain the same) MySQL 5.6 MySQL 5.7
- 35. 0 20 40 60 80 100 Q2 Q18 Executiontimerelativeto5.6(%) CPU bound 5.6 5.7 Optimizer Cost Model: Performance Improvements DBT-3 (SF10) 2 out of 22 queries get a significantly improved query plan (others remain the same) 0 20 40 60 80 100 Q2 Q18 Executiontimerelativeto5.6(%) Disk bound 5.6 5.7
- 36. MySQL 5.7: Query Rewrite Plugin • New pre and post parse query rewrite APIs – Users can write their own plug-ins • Provides a post-parse query plugin – Rewrite problematic queries without the need to make application changes – Add hints – Modify join order – Many more … • Improve problematic queries from ORMs, third party apps, etc. • Eliminates many legacy use cases for proxies 37
- 37. MySQL 5.7: SYS Schema Helper objects for DBAs, Developers and Operations staff • Helps simplify DBA / Ops tasks - Monitor server health, user, host statistics - Spot, diagnose, and tune performance issues • Easy to understand views with insights into - IO hot spots, Locking, Costly SQL statements - Schema, table and index statistics • SYS is similar to - Oracle V$ catalog views - Microsoft SQL DMVs (Dynamic Mgmnt Views) 38
- 38. • Replaced custom code with Boost.Geometry – For spatial calculations – For spatial analysis – Enabling full OGC compliance – We’re also Boost.Geometry contributors! • InnoDB R-tree based – Full ACID, MVCC, & transactional support – Index records contain minimum bounding box • GeoHash • GeoJSON • Helper functions such as ST_Distance_Sphere() and ST_MakeEnvelope() MySQL 5.7: GIS Improvements 39
- 39. • Native Partitioning – Eliminates previous limitations – Eliminates resource usage problems – Transportable tablespace support • Native Full-Text Search – Including full CJK support! • Native Spatial Indexes • Transparent page compression • Support for 32K and 64K pages – Use with transparent page compression for very high compression ratios • General TABLESPACE support – Store multiple tables in user defined shared tablespaces • Support for MySQL Group Replication – High priority transactions • Improved support for cache preloading – Load your hottest data loaded at startup • Configurable fill-factor – Allows for improvements in storage footprint • Improved bulk-data load performance MySQL 5.7: InnoDB Improvements 40
- 40. MySQL 5.7: InnoDB – Always Online • Resize the InnoDB Buffer Pool online – Allows DBAs to tune the buffer size without any downtime – Adapt in real-time to changes in database usage patterns • Separate UNDO tablespace – With automatic online truncation • Additional Online ALTER TABLE support – Enlarge VARCHAR, Rename Index • Dynamic configuration – Making existing settings dynamically configurable – As a design principle for new features & settings 41
- 41. • GTID enhancements – On-line, phased deployment of GTIDs – Binary logging on slave now optional • Enhanced Semi-synchronous replication – Write guaranteed to be received by slave before being observed by clients of the master – Option to wait on Acks from multiple slaves • Multi-Source Replication – Consolidate updates from multiple Masters into one Slave • Dynamic slave filters • 8-10x Faster slave throughput – Often removes slave as a bottleneck; keep pace with master with 8+ slave threads – Option to preserve Commit order – Automatic slave transaction retries MySQL 5.7: Replication Improvements 42 0% 50% 100% 150% 200% 250% 1 8 24 48 Slave Threads Slave throughput vs. 96 Thread Master
- 42. 15/04/2015 Copyright 2015, oracle and/or its affiliates. All rights reserved 43 Thank You!