Leistungssteigerung fأ¼r MySQL - Die besten Title Leistungssteigerung fأ¼r MySQL - Die besten Tips -

  • View
    0

  • Download
    0

Embed Size (px)

Text of Leistungssteigerung fأ¼r MySQL - Die besten Title Leistungssteigerung fأ¼r MySQL - Die besten...

  • 1Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt

    MySQL Scaleout

    Kristian Köhntopp, Consultant,

    MySQL GmbH

    http://blog.koehntopp.de

    http://mysqldump.azundris.com

    Handy aus?

    mailto:kris@mysql.com http://blog.koehntopp.de/

  • 2Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt

    Warum machen wir das?

    • Performance Tuning hat Grenzen – Optimierung der bestehenden Anwendung durch

    • Änderung der Datenbank-Konfiguration, • Kompatible Änderung des Schemas (Typen, Indices), • Kompatible Änderung von SQL Query Strings, • Lokale Änderungen der Anwendung,

    – PT ist gut für ein Wachstum von 2x bis 3x

    • Aber auch nur, wenn der Kunde vorher schlecht war.

    • Ein Wachstum von 10x oder mehr zieht immer eine Änderung der Architektur nach sich

    – Bei einem boomenden Geschäft dient PT dazu, sich die Zeit für das Scaleout zu erkaufen

  • 3Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt

    Beispiel Mail

    • Dienste in einem Mail-Server

    – SMTP – SMTP AUTH

    • LDAP? – SSL – IMAP – POP – Spam – Antivirus – Vacation/Autoresponder – Addressbook

    • LDAP? – Mailinglisten/Mass Mailer – Web Interface

  • 4Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt

    Beispiel Mail

    • Wie sieht eine Lösung aus für

    – 2 Benutzer (Meine Freundin und mich?) – 200 Benutzer (Ein Verein wie Toppoint.de?) – 20 000 Benutzer (Eine große Firma?) – 2 000 000 Benutzer (Projektgröße hamburg.de) – 20 000 000 Benutzer (web.de) – 200 000 000 Benutzer (Google Mail, Yahoo!, Hotmail)

    • Die gebotenen Dienste sind immer dieselben. • Die Lösungen haben zum Teil keine erkennbare

    Ähnlichkeit.

    • Infrastrukturentwicklung und wachstumsinduzierter Entwicklungsaufwand werden häufig unterschätzt.

    – So etwas tötet Firmen!

  • 5Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt

    Wachstumsgrenzen

    • Pure Kistengröße

    – Theoretische Grenze:

    E 25000 von Sun = 72 CPUs, 576 GB RAM, Petabytes Storage

    – Praktisch so nicht umsetzbar:

    • Investitionsklotz zu groß • Bang/Buck Ratio nicht wirklich attraktiv

    • Aber hoher Geek-Acceptance-Faktor

    – Realistische Grenze:

    8 Core, 64 GB RAM, 28 Spindeln lokal oder SAN

  • 6Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt

    Wachstumsgrenzen

    • Synchrone Paradigmen

    – Die gewohnte Art zu programmieren saturiert nur einen Core

    • F() -> Code von F wird ausgeführt, Hauptstrang wartet

    – Das ist ein guter Ansatz für eine kurze Time-To-Market

    • Einigermaßen gut verstanden • Vergleichsweise leicht zu debuggen • Personell gut zu bestücken

  • 7Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt

    Wachstumsgrenzen

    • Asynchrone Calls erfordern Umdenken und Umstrukturieren des Codes

    – Send F() -> Return Handle H(F). – Hauptstrang arbeitet, F() arbeitet. – F benachrichtigt Hauptstrang, daß ein Result vorliegt. – Resynchronisation result(H(F)) -> Hauptstrang.

    • Aufgabe des Hauptstranges ist nun:

    – Vermeide Waits. Halte so viele Subthreads so busy wie möglich. • Thread Local Storage, Debugging, Ungeeignete API (in Unix) • Queues, Locks, Deadlocks • Latenz

  • 8Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt

    Wachstumsgrenzen

    • Wenn man sowieso asynchron arbeitet:

    – Parameter einpacken (Marshalling) – Request versenden – Parameter auspacken (Unmarshalling) – F aufrufen – Result verpacken und zurücksenden

    • Viele Kopien von F() auf vielen Kisten haben

    – Load Balancing – Livetesting, Liste von Kopien aktuell handhaben – ggf. doppelte Funktionsaufrufe (weiche Fehler behandeln)

    • MapReduce, Hadoop! – Vorteil: Subthreads müssen nicht auf der lokalen Hardware laufen – Nachteil: Latenzmaschine

  • 9Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt

    Folgerungen für die Architektur

    • SOA oder MapReduce – Vertikale Strukturierung vs. horizontale Strukturierung

    • Asynchronizität ist zwingend – 2PC ist keine Lösung!

    • Netzwerklatenz begrenzt die Commit-Frequenz

    – Wir müssen mit Inkonsistenzen leben! • ACID? • Optimistisches Locking! • Sigma2 – Sigma3 als Fehlerrate

    • Locality wird wichtiger als Normalität – Redundanzen!

    • Ausfälle! – Bei n-> unendlich ist p(Ausfall) -> 1 – Redundanzen!

  • 10Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt

    Das Write-Problem

    • Reads skalieren ist leicht!

    – Wir haben jede Menge Kopien – Wir legen nur mittleren Wert auf Konsistenz

    • Writes sind anstrengend

    – Writes müssen persistent gemacht werden. – Das erzeugt zwingend Disk-Aktivität. – Das erzeugt zwingend Replikationstraffic für die Read-Kopien.

    • Mal n

    • Writes sind entweder 2PC oder wir haben einen SPOF – Write anywhere -> 2PC + Locking Latenz – Writes central -> SPOF -> Wir brauchen ein HA-Konzept.

  • 11Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt

    Realisierung

    • LB -> Webfrontends

    – Webfrontends stateless – Was ist mit Sessions?

    • Sessions in memcached

    – Eine Datenbank ist sinnlos, wenn die Daten die Form Key -> BLOB

    haben.

    – Skalierung des memcached als Array – SessionID % Arraysize = Adresse

    • Memcached-Ausfall? – Ignorieren, Multicast-Buddies, DHT? – DHT vermutlich Overkill (behandelt hauptsächlich Churnrate)

  • 12Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt

    Realisierung

    • Persistenzlayer unterhalb von Webfrontends: 2-Tier vs. 3-Tier

    • Gründe für 3-Tier: – Web Services

    • Middleware mit Auth, http als RPC-Protokoll = Instant Web Service!

    – Entwicklungstaktische Probleme • Kapselung auf Projektebene

    – API mit Async-Calls + Async-Clients = Multithreading + Scaling

    • Gründe für 2-Tier: – Weniger Overhead – Weniger Entwicklungskomplexität

  • 13Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt

    Realisierung

    • Standardpfad:

    – Entwicklung als Monolith

    – 2-Tier

    – 3-Tier (oder Tod!)

  • 14Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt

    Redundanzen in der Datenhaltung

    • Leicht skalierbare Reads – “Ask any local copy” – Umgang mit veralteten Daten

    • Redundanzen veralten oder werden ungültig

    – Konsistenzprüfer mit entwickeln – Reparaturprogramme mit entwickeln

    – Viele Entwickler haben mit dem Konzept des partiellen Fehlers große Probleme

    • Writes skalieren sich immer noch schlecht – Siehe vorne

  • 15Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt

    Writes skalieren

    • Wie Writes skalieren?

    – Nicht schreiben (Sessions)

    – Später schreiben (innodb_flush_log_at_trx_commit = 2, ACID ist Luxus)

    – Kleine Writes (1:1 Relationen volatiler Daten) – Kleine Writes (Redo Log schreibt Columns, nicht Rows, nicht

    Pages)

    – Lineare Writes (Redo Log statt Random I/O)

    – Partitionen P(X) = { p(1)...p(n),

    ALL(x,y: x!= y): p(x) ∩ p(y) = {}, ALL(x): Up(x) = P }

    – Funktionale Trennung: 3-Tier, lokale Dienste kapseln

  • 16Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt

    Writes distributieren

    • Wir müssen die Änderungen an alle Kopien verteilen “Replikation”

    – MySQL Replikation:

    • Leicht aufzusetzen und zu betreiben. • Schlecht zu filtern. • Skaliert nicht über einen Core hinweg. • Konzeptuelle Grenzen von SBR.

    • 5.1 führt RBR ein. • RBR ist prinzipiell parallelisierbar.

    – Manuelle Datenpumpen

    • Zum Beispiel mk-table-sync aus Maatkit.

    – Queueing Services, Transaktionsmonitore • Und schon sind wir wieder 2PC.

  • 17Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt

    Standardarchitektur (mit Shared Disk) • Active/Passive

    = Private IP = 10.10.10.21

    Active Server Passive Server

    Cluster Management = Virtual IP = 10.10.10.10

    = Private IP = 10.10.10.20

    Cluster Agent

    SAN

    Web/App Server

    Web/App Server

    Cluster Agent

  • 18Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt

    Standardarchitektur (mit DRBD)

    = Private IP = 10.10.10.21

    Active Server Passive Server

    = Private IP = 10.10.10.20

    Primary DRBD Secondary DRBDDRBD

    Linux Heartbeat = Virtual IP = 10.10.10.10

    Web/App Server

    Web/App Server

  • 19Copyright 2008 MySQL AB Die populärste Open-Source-Datenbank der Welt

    Standardarchitektur

    • Der Stack: – DRBD (oder Shared Disk) – LVM – FS (xfs oder ext3) – Datenbank

    – Darüber heartbeat • Viele Kunden bereiten den Failover vor, führen ihn aber ma