Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Introduction to High Performance for MySQL, Vla...

Introduction to High Performance for MySQL, Vlad Fedorkov (ProxySQL)

This presentation was given at ProxySQL Technology Day Ghent 2019 by Vlad Fedorkov who worked at ProxySQL as Senior Consultant in 2016-2019.

ProxySQL LLC

October 03, 2019
Tweet

More Decks by ProxySQL LLC

Other Decks in Technology

Transcript

  1. ProxySQL Technology Day: a housekeeping minute •Keep doors open •Grab

    your favorite drink and ask questions •You can catch me, Jesmar or Stacy for any requests •We’ll have a 25 minutes break for snacks at 18:45 • And something else later •Please feel free to share photos and twits with #ProxySQL hashtag • Also ProxySQL team is available for selfies •A side note: talks are being recorded!
  2. ProxySQL Tech Day specials: We are giving away ProxySQL T-shirts

    for your best questions! A FREE 2-hour consulting gig for ProxySQL comes with every business card on the table! And we’ve just released ProxySQL 2.0.7! Go download it for free! ☺
  3. About me •Working with MySQL • Last 19+ years •

    Still like it •Helping companies to survive growth pains and traffic spikes • Last 10+ years •Working for ProxySQL for the last 3 years • And enjoying it a lot •Happy to learn from others and share my own experience
  4. Goals for DBAs 20 years ago and today •In year

    2000 I felt like a super star installing MySQL 3.23.56 on the single box. •Dealing with 100k+ QPS today I don’t feel even close to it… •What’s changed?
  5. Company capitalizations have also changed 1. Microsoft 904,860 2. Apple

    Inc. 895,670 3. Amazon.com 874,710 4. Alphabet Inc. 818,160 5. Berkshire Hathaway 493,750 6. Facebook 475,730 7. Alibaba Group 472,940 8. Tencent 440,980 9. Johnson & Johnson 372,230 10. ExxonMobil 342,170 … Ford motors 38,221
  6. Online store in 2001 •Actual brick-and-mortar store you can walk

    in. •On the website • Catalogue • Item page • Shopping cart • User page (user info & orders) •Order confirmation via the phone. •Single server: if it gets stuck, we’ll just reboot it.
  7. Online store today (year 2019) •Most of the sales come

    from the website • Offline store may not even exist •Payments made online •The website • No one even counts how many pages are there • We count in services • Integrated back office •24/7 availability is a must • 5% drop in user requests is considered as a major outage
  8. Infrastructure goals have changed •Single box can’t handle all load

    anymore • Even if it’s 128 core box •Larger amount of boxes means larger amount of outages • Both hardware and software • Single point of failure will cause a trouble •“Capacity” goes beyond “Performance” today • Do we have enough capacity to serve the existing customers? • How many customers can we serve with the existing hardware? • How many customers can we serve with the current architecture? •“Capacity” is the number of boxes we need to have to serve all our traffic with acceptable latency.
  9. Capacity in MySQL •One thread per connection to MySQL server

    •Every query is served by a single thread •Every query is a combination of data processing (CPU) and data reading/writing (IO) •IO is relatively slow • so some data is cached in memory to decrease the number of IO requests •In general, capacity is always a combination of latency and throughput
  10. Where latency is coming from? • Some steps to mention

    • Forming SQL query with ORM library • MySQL client API call • Network driver calls in OS kernel • Network transmission • Packet reception on MySQL side • Query parsing • Query execution plan • MySQL API calls to storage engine • Necessary IO requests to the disks • More network calls in case of attached disks • Dataset processing on the CPU side • Dataset transmission to the client • Data post-processing on the client sides
  11. What’s the problem with the latency? •Query time includes latency

    of all components + pure execution time •Lower latency means higher amount of served requests •Faster response time • For some applications it’s a key requirement •The cost of lower latency is increasing exponentially • Faster hardware may be far more expensive •So we have to scale out to keep cost manageable
  12. Scalability •To scale out, you need to… •be able to

    balance traffic load across nodes •be able to detect failures and overloads • add and remove nodes transparently for the application •be able to understand database traffic •be able to manage it •All of the above is not supported by “classic” MySQL! • You have to code this logic yourself. • Or install additional tools…
  13. Load balancers are key for the infrastructure •We had a

    lot of tools for balancing HTTP traffic loads. •Proxying of database traffic is more complicated. •A number of tools are available on the MySQL market: HAProxy, MaxScale, MySQL Router, Vitesse, etc. •And apparently ProxySQL.
  14. ProxySQL •ProxySQL understands SQL language. • Unlike layer 4 ISO/OSI

    proxies working on transport level… •ProxySQL knows everything about the query – including its processing, the state of connection, authorization and results. •ProxySQL uses internal connection pool with connection multiplexing to re-use existing connections. •ProxySQL’s able to route queries based on various filters: • By user, by database (schema name) and by query itself •You’ll learn more about it from the next speaker! ☺