Kristian Köhntopp, booking.com

MySQL in großen
Umgebungen
Kristian Köhntopp, booking.com
Dienstag, 5. Mai 2009
1
Was nicht kommt
•
Dienstag, 5. Mai 2009
Dieser Vortrag geht davon aus, daß die
Erstellung einer my.cnf ein gelöstes
Problem ist.
2
Was nicht kommt
•
Dienstag, 5. Mai 2009
Der Vortrag geht davon aus, daß
EXPLAIN, Indices usw. bekannt sind.
3
Worum geht es dann?
•
Manche Probleme sind nur durch brutale
Gewalt und ein Datacenter voll Kisten zu
zu lösen.
•
Das hat Auswirkungen auf die
Architektur der Lösung.
Dienstag, 5. Mai 2009
4
Was macht Booking?
Booking verkauft Hotelbuchungen an
Reisende auf Kommission.
Nur das.
Dienstag, 5. Mai 2009
5
Daten bei Booking.
•
Hotel Basisdaten,
•
Broschüren,
•
Bewertungen & Scores,
•
Verfügbarkeit nach Raum, Preisplan and
Datum.
•
Ein paar fette Data Warehouses.
Dienstag, 5. Mai 2009
6
Booking Tech
•
Frontends mit Linux, Apache, mod_perl,
•
•
Diverse Funktionsgruppen.
Datenbanken: MySQL,
•
•
Dienstag, 5. Mai 2009
Diverse Funktionsgruppen.
Eine Menge Infrastrukturserver.
7
Booking Größe
•
FE zu DB ratio: ca. 4-6 to 1.
•
Ca. 160 slaves, ein Dutzend Schemata.
•
Ca. 1000 Rechner.
•
Schnell wachsend.
Dienstag, 5. Mai 2009
8
Booking 2006
•
32 Bit Host.
•
MySQL 4.0.
•
RAID-1.
•
Ca. 45G Daten.
•
Ein Dutzend Slaves.
•
Ein Schema für alles.
Dienstag, 5. Mai 2009
9
Architektur: Synchron-Lokal
•
Alle Abhängigkeiten vollständig in
Integrity-Constraints abbildbar.
•
Call-Wait, Single Thread, 2-Tier.
Dienstag, 5. Mai 2009
10
Call-Wait, Single-Thread
Apache
mod_perl
Dienstag, 5. Mai 2009
MySQL
11
Synchron-Lokal böse?
•
Leicht zu debuggen.
•
Kostengünstig, kurze Time-to-market:
•
Dienstag, 5. Mai 2009
Featureentwickler können ungehindert
arbeiten.
12
Synchron-Lokal böse?
•
Vertikal skalierbar,
•
Skalierungskosten in der Datenbank.
‣
Absolute Wachtumslimits.
‣
Inakzeptabel!
Dienstag, 5. Mai 2009
13
Kein DWH
•
Auch außerhalb von Booking oft
anzutreffen:
•
Kein ETL,
•
operative Daten mit BI/DSS vermischt.
Dienstag, 5. Mai 2009
14
ETL & DWH
•
Bei gleicher Anzahl von Artikeln, Kunden
und Verkäufen, ist die Schemagröße über
die Zeit stabil?
•
Existieren Tabellen mit Time im PK oder
Tabellen mit Partition by Time?
Dienstag, 5. Mai 2009
15
Beispiel MEM
•
Wir monitoren 160 Hosts mit
statistischen Daten.
•
Wir monitoren das SQL von ca. 20 Hosts.
•
1.2G Statistik + 5G SQL pro Tag.
•
Das heißt, wir löschen 6.2G Dreck pro
Tag.
Dienstag, 5. Mai 2009
16
Beispiel MEM
•
Voll normalisierter KV Storage (6NF)
•
Bestandsdaten und Zeitdaten
vermengt.
•
OLTP (offene Alerts) und DWH
(Meßdaten) vermengt.
•
Scheitert am Expire.
•
Dienstag, 5. Mai 2009
Löschung mit externem Script,
Indexqualität im Eimer.
17
Beispiel MEM
•
Migration in anderes Schema:
•
5.1 + Partitions (Eat Your Own
Dogfood).
•
Kein DELETE, verwende DROP TABLE.
•
Nicht alle Daten sind gleich.
•
Dienstag, 5. Mai 2009
Näher an 3NF, ORM, etwa ‘Class
InnoDB’ ➔ bessere Locality
18
Booking 2008
•
64 Bit Host, speichergesättigt.
•
MySQL 5.0.
•
DAS: RAID-10, Netapp.
•
HA: Heartbeat.
•
Multiple Schemata funktional partitioniert
(50G - 1000G), nach Schema: 2-60 Slaves
‣
Synchron-Verteilt.
Dienstag, 5. Mai 2009
19
Verfügbarkeit
•
Partition by Functionality
•
HA Anforderungen differenzieren:
•
Redundanz auf Master
•
Redundanz auf Slaves?
•
Recoveryzeiten?
•
Dienstag, 5. Mai 2009
OLTP vs. Service-DWH vs. DSS
20
Verfügbarkeit
•
Basisverfügbarkeit:
•
Verkauf bei toten Backoffice aufrecht
erhalten?
•
Lose Kopplung.
•
Reserven berechnen.
•
Negative SLA machen.
Dienstag, 5. Mai 2009
21
Master HA
•
DAS: RAID-10 local, DRBD zwischen
Master und Standby Master.
•
NetApp: multipathd.
•
Failover: heartbeat oder manuell.
•
LVM, XFS:
•
mylvmbackup.
•
Clone Source: Backup Slave.
Dienstag, 5. Mai 2009
22
HA
•
HA Masters.
•
Backup Slave.
•
Worker Slaves:
•
Dienstag, 5. Mai 2009
Slaves mit DAS noch RAID-10, im
Grunde unnötig.
23
Storage Performance
•
NetApp Performance:
•
Hohe Latenz, hoher Durchsatz.
•
Auf den meisten DBs schneller als DAS.
•
Gegenbeispiel visitstats:
•
Dienstag, 5. Mai 2009
Großes DWH mit MyISAM, große
Aggregationen.
24
Architektur: Verteilt-Lokal
•
Datenbankzugriff gekapselt,
•
Constraints über Instanzgrenzen
validiert,
•
Datenbankschema größer als eine
Instanz.
•
2-Tier Call-Wait, single threaded.
•
ETL + korrektes DWH.
Dienstag, 5. Mai 2009
25
Integrität
•
Schema-beschreibende Tabellen:
•
•
Domain Constraints, Foreign Keys,
State Transitions über Instanzgrenzen.
Zugriffe in Class DBI/DBIx gekapselt:
•
Validierung inkrementell beim Zugriff.
•
Validierung global durch Cronjob.
•
Validierung abschaltbar.
Dienstag, 5. Mai 2009
26
Joins
•
Beispiel: bp/av Split.
•
bp hat Katalog, Raumbeschreibungen,
Policies und Reviews.
•
av hat Verfügbarkeitsdaten (Räume,
Daten, Preise).
•
Hotelsuche:
•
Dienstag, 5. Mai 2009
av/bp Joins über Instanzgrenzen.
27
Joins
•
Situation wie bei MySQL Cluster:
•
•
Join von zwei Tabellen auf verschiedenen
Nodes.
Wünschenswert: Hash-Join.
•
Scan T1, Hash of Matches bauen.
•
Scan T2, für jeden Match Hashlookup,
•
•
Dienstag, 5. Mai 2009
oder anders herum.
Limit: Intermediate Hash < Memory.
28
Joins
•
Angewendet auf av/bp:
•
Kapselung von Zugriffen in Klassen,
die Application Side Hash Joins
durchführen.
•
Auf der Datenbank:
Dienstag, 5. Mai 2009
•
SELECT … WHERE id IN (…)
•
IN-List < max_allowed_packet (16M)
29
Konsequenz?
•
Speichergesättigt.
•
Deformiertes SQL: PK-Lookups.
•
Queries ausprogrammiert.
•
Constraints ausprogrammiert.
•
Wieso dann noch SQL?
•
CouchDB? Andere K/V Storages?
Dienstag, 5. Mai 2009
30
Konsequenz?
•
TXN?
•
Concurrency?
•
Reporting & Ad-Hoc Queries?
‣
Profil von MySQL 4.1 erfüllbar.
‣
Dienstag, 5. Mai 2009
Drizzle.
31
Drizzle: MySQL&Clouds
•
MySQL 5.x Fork:
•
minus 2/3 der Codebasis,
•
plus APIs für Plugins für die fehlende
Funktionalität.
•
Experimentell & Instabil.
•
Nicht rückwärtskompatibel.
Dienstag, 5. Mai 2009
32
Kapazitätsplanung
•
Last- und Wachstumskurven über das
Jahr kalibrieren,
•
•
projezieren.
Continuous Integration auch mit
Lasttests.
•
Dienstag, 5. Mai 2009
Schwer zu warten.
33
Infrastrukturentwicklung
•
Wie nennt man das, wenn Sysadmins
manuell auf Kisten rumkriechen um
Dinge zu fixen?
•
Wie nennt man das, wenn Sysadmins
Installations- und Monitoringscripte
schreiben?
Dienstag, 5. Mai 2009
34
Infrastrukturentwicklung
•
Dienstag, 5. Mai 2009
Ziel von ISE ist Aufrechterhaltung
bestehender Fertigkeiten und Flexibilität
angesichts wachsender Last/
Maschinenzahl.
35
Infrastrukturentwicklung
•
ISE unterscheidet sich von FE
•
Keine Halbfertigprodukte:
•
Payoff nur bei NULL manuellen
Eingriffen, dann jedoch komplett.
•
Teletubbies vs. militärisch geführt.
Dienstag, 5. Mai 2009
36
Infrastrukturentwicklung
•
Mantra: Du kannst Dinge nur drei Mal
tun.
•
Zeige, daß es geht (Machbarkeit).
•
Zeige, daß es kein Zufall war
(Reproduzierbarkeit).
•
Automatisiere oder lehre es
(Automation).
Dienstag, 5. Mai 2009
37
Infrastrukturentwicklung
•
Provisioning:
•
•
Kickstart/Jumpstart & cfengine/puppet/Chef.
Visibility:
•
•
Nagios, Cacti, MEM.
Process:
•
•
Ticketing, Bugtracking.
Downgrading operations:
•
Dienstag, 5. Mai 2009
Web Interfaces.
38
Booking 2010
Wieder speichergesättigt
256G
Shards
SSD
Estimate
Queue
Dienstag, 5. Mai 2009
Cache
Lose gekoppelt
39
Speichersättigung
•
Speichersättigung durch:
•
Extreme RAM-Größen.
•
Partitionierung nach Werten.
•
Schema Zielgröße:
•
Dienstag, 5. Mai 2009
<128G pro Shard.
40
Disk Seeks
•
Warum Speichersättigung?
•
Disk Seek ~ 5ms
•
RAM Access ~ 5ns
‣
1:1 000 000 (gelogen!)
•
2. Lösung: Keine Seeks mehr!
‣
Dienstag, 5. Mai 2009
SSD!
41
SSD
•
SAN: Latenz.
•
Wann ist DAS schneller als SAN?
•
Latenzanteil an Transaktionszeit?
•
SSD = RAM at a distance.
•
RAM/Flash am lokalen Bus.
•
Flash mit HDD Interface.
•
RAM/Flash am SAN.
Dienstag, 5. Mai 2009
42
SSD
•
Datenbank-Schreiblast:
•
Bei Speichersättigung: Random-Writes,
Linear read im Warmup.
•
Bei Disk-I/O: Random-Writes, RandomReads, ca. 1:2 bis 1:20.
•
SSD um so besser, je mehr Reads.
•
Dienstag, 5. Mai 2009
Intel X25-M/E derzeit die einzigen
schreibfesten SSD
43
256G
•
Bekannte Probleme:
•
innodb_max_dirty_pct.
•
Recovery mit großen
innodb_buffer_pool_size.
•
Cache preheating nach Restart:
•
Dienstag, 5. Mai 2009
autostart.sql + SELECT COUNT(*).
44
Shards
•
Funktional partitioniert:
•
•
Schema größer als eine Instanz.
Nach Werten partitioniert (Sharding):
•
•
Tabelle größer als eine Instanz.
Parallelisierungspotential
•
Dienstag, 5. Mai 2009
Ganz schlecht in der API unterstützt.
45
Shards
•
Migration nach Sharding:
•
Mapping von Werten auf Instanzen.
•
Map/Reduce für Resultsets.
•
Wo?
•
In der Anwendung.
•
Im MySQL Proxy.
Dienstag, 5. Mai 2009
46
Asynchron-Verteilt
•
Asynchron-Verteilt:
•
Anteilige Kosten von Latenz steigen.
•
Latenz steigt mit Distanz (c konstant).
•
Latenzanteil steigt mit Parallelisierung.
•
Ausfallwahrscheinlichkeiten steigen.
•
Dienstag, 5. Mai 2009
Transaktionen vs. Netsplits.
47
CAP Theorem
•
Consistency:
•
•
The client perceives that a set of operations has
occurred all at once.
Availability
•
•
Every operation must terminate in an intended
response.
Partition tolerance.
•
•
Dienstag, 5. Mai 2009
Operations will complete, even if individual
components are unavailable.
Choose Any Two! (P mandatory)
48
ACID
•
Choose Consistency.
•
2PC und was danach kommt stoppt
angesichts von Netzwerkpartitionen.
Dienstag, 5. Mai 2009
49
BASE
•
Basically Available, Soft state,
Eventually consistent
•
Choose Availability, vorübergehend
inkonsistent.
•
Writes in Warteschlange, Writes
wiederholbar formulieren.
Dienstag, 5. Mai 2009
50
Folgerung für Uniabgänger
In asynchron-verteilten Umgebungen
mußt Du gegen jede einzelne Regel
Deiner Datenbankvorlesung verstoßen.
Dienstag, 5. Mai 2009
51
Dienstag, 5. Mai 2009
52