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

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