MYSQL IN GROßEN UMGEBUNGEN - KRISTIAN KÖHNTOPP, BOOKING.COM - DIENSTAG, 5. MAI 2009
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
MySQL in großen
Umgebungen
Kristian Köhntopp, booking.com
Dienstag, 5. Mai 2009 1Was nicht kommt
• Dieser Vortrag geht davon aus, daß die
Erstellung einer my.cnf ein gelöstes
Problem ist.
Dienstag, 5. Mai 2009 2Was nicht kommt
• Der Vortrag geht davon aus, daß
EXPLAIN, Indices usw. bekannt sind.
Dienstag, 5. Mai 2009 3Worum 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 4Was macht Booking?
Booking verkauft Hotelbuchungen an
Reisende auf Kommission.
Nur das.
Dienstag, 5. Mai 2009 5Daten bei Booking.
• Hotel Basisdaten,
• Broschüren,
• Bewertungen & Scores,
• Verfügbarkeit nach Raum, Preisplan and
Datum.
• Ein paar fette Data Warehouses.
Dienstag, 5. Mai 2009 6Booking Tech
• Frontends mit Linux, Apache, mod_perl,
• Diverse Funktionsgruppen.
• Datenbanken: MySQL,
• Diverse Funktionsgruppen.
• Eine Menge Infrastrukturserver.
Dienstag, 5. Mai 2009 7Booking 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 8Booking 2006
• 32 Bit Host.
• MySQL 4.0.
• RAID-1.
• Ca. 45G Daten.
• Ein Dutzend Slaves.
• Ein Schema für alles.
Dienstag, 5. Mai 2009 9Architektur: Synchron-Lokal
• Alle Abhängigkeiten vollständig in
Integrity-Constraints abbildbar.
• Call-Wait, Single Thread, 2-Tier.
Dienstag, 5. Mai 2009 10Call-Wait, Single-Thread
Apache
MySQL
mod_perl
Dienstag, 5. Mai 2009 11Synchron-Lokal böse?
• Leicht zu debuggen.
• Kostengünstig, kurze Time-to-market:
• Featureentwickler können ungehindert
arbeiten.
Dienstag, 5. Mai 2009 12Synchron-Lokal böse?
• Vertikal skalierbar,
• Skalierungskosten in der Datenbank.
‣ Absolute Wachtumslimits.
‣ Inakzeptabel!
Dienstag, 5. Mai 2009 13Kein DWH
• Auch außerhalb von Booking oft
anzutreffen:
• Kein ETL,
• operative Daten mit BI/DSS vermischt.
Dienstag, 5. Mai 2009 14ETL & 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 15Beispiel 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 16Beispiel MEM
• Voll normalisierter KV Storage (6NF)
• Bestandsdaten und Zeitdaten
vermengt.
• OLTP (offene Alerts) und DWH
(Meßdaten) vermengt.
• Scheitert am Expire.
• Löschung mit externem Script,
Indexqualität im Eimer.
Dienstag, 5. Mai 2009 17Beispiel MEM
• Migration in anderes Schema:
• 5.1 + Partitions (Eat Your Own
Dogfood).
• Kein DELETE, verwende DROP TABLE.
• Nicht alle Daten sind gleich.
• Näher an 3NF, ORM, etwa ‘Class
InnoDB’ ➔ bessere Locality
Dienstag, 5. Mai 2009 18Booking 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 19Verfügbarkeit
• Partition by Functionality
• HA Anforderungen differenzieren:
• Redundanz auf Master
• Redundanz auf Slaves?
• Recoveryzeiten?
• OLTP vs. Service-DWH vs. DSS
Dienstag, 5. Mai 2009 20Verfügbarkeit
• Basisverfügbarkeit:
• Verkauf bei toten Backoffice aufrecht
erhalten?
• Lose Kopplung.
• Reserven berechnen.
• Negative SLA machen.
Dienstag, 5. Mai 2009 21Master 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 22HA
• HA Masters.
• Backup Slave.
• Worker Slaves:
• Slaves mit DAS noch RAID-10, im
Grunde unnötig.
Dienstag, 5. Mai 2009 23Storage Performance
• NetApp Performance:
• Hohe Latenz, hoher Durchsatz.
• Auf den meisten DBs schneller als DAS.
• Gegenbeispiel visitstats:
• Großes DWH mit MyISAM, große
Aggregationen.
Dienstag, 5. Mai 2009 24Architektur: 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 25Integritä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 26Joins
• Beispiel: bp/av Split.
• bp hat Katalog, Raumbeschreibungen,
Policies und Reviews.
• av hat Verfügbarkeitsdaten (Räume,
Daten, Preise).
• Hotelsuche:
• av/bp Joins über Instanzgrenzen.
Dienstag, 5. Mai 2009 27Joins
• 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,
• oder anders herum.
• Limit: Intermediate Hash < Memory.
Dienstag, 5. Mai 2009 28Joins
• Angewendet auf av/bp:
• Kapselung von Zugriffen in Klassen,
die Application Side Hash Joins
durchführen.
• Auf der Datenbank:
• SELECT … WHERE id IN (…)
• IN-List < max_allowed_packet (16M)
Dienstag, 5. Mai 2009 29Konsequenz?
• Speichergesättigt.
• Deformiertes SQL: PK-Lookups.
• Queries ausprogrammiert.
• Constraints ausprogrammiert.
• Wieso dann noch SQL?
• CouchDB? Andere K/V Storages?
Dienstag, 5. Mai 2009 30Konsequenz?
• TXN?
• Concurrency?
• Reporting & Ad-Hoc Queries?
‣ Profil von MySQL 4.1 erfüllbar.
‣ Drizzle.
Dienstag, 5. Mai 2009 31Drizzle: 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 32Kapazitätsplanung
• Last- und Wachstumskurven über das
Jahr kalibrieren,
• projezieren.
• Continuous Integration auch mit
Lasttests.
• Schwer zu warten.
Dienstag, 5. Mai 2009 33Infrastrukturentwicklung
• 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 34Infrastrukturentwicklung
• Ziel von ISE ist Aufrechterhaltung
bestehender Fertigkeiten und Flexibilität
angesichts wachsender Last/
Maschinenzahl.
Dienstag, 5. Mai 2009 35Infrastrukturentwicklung
• 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 36Infrastrukturentwicklung
• 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 37Infrastrukturentwicklung
• Provisioning:
• Kickstart/Jumpstart & cfengine/puppet/Chef.
• Visibility:
• Nagios, Cacti, MEM.
• Process:
• Ticketing, Bugtracking.
• Downgrading operations:
• Web Interfaces.
Dienstag, 5. Mai 2009 38Booking 2010
Wieder speichergesättigt
256G Shards
SSD
Cache
Estimate
Queue Lose gekoppelt
Dienstag, 5. Mai 2009 39Speichersättigung
• Speichersättigung durch:
• Extreme RAM-Größen.
• Partitionierung nach Werten.
• Schema Zielgröße:
•Disk Seeks
• Warum Speichersättigung?
• Disk Seek ~ 5ms
• RAM Access ~ 5ns
‣ 1:1 000 000 (gelogen!)
• 2. Lösung: Keine Seeks mehr!
‣ SSD!
Dienstag, 5. Mai 2009 41SSD
• 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 42SSD
• Datenbank-Schreiblast:
• Bei Speichersättigung: Random-Writes,
Linear read im Warmup.
• Bei Disk-I/O: Random-Writes, Random-
Reads, ca. 1:2 bis 1:20.
• SSD um so besser, je mehr Reads.
• Intel X25-M/E derzeit die einzigen
schreibfesten SSD
Dienstag, 5. Mai 2009 43256G
• Bekannte Probleme:
• innodb_max_dirty_pct.
• Recovery mit großen
innodb_buffer_pool_size.
• Cache preheating nach Restart:
• autostart.sql + SELECT COUNT(*).
Dienstag, 5. Mai 2009 44Shards
• Funktional partitioniert:
• Schema größer als eine Instanz.
• Nach Werten partitioniert (Sharding):
• Tabelle größer als eine Instanz.
• Parallelisierungspotential
• Ganz schlecht in der API unterstützt.
Dienstag, 5. Mai 2009 45Shards
• Migration nach Sharding:
• Mapping von Werten auf Instanzen.
• Map/Reduce für Resultsets.
• Wo?
• In der Anwendung.
• Im MySQL Proxy.
Dienstag, 5. Mai 2009 46Asynchron-Verteilt
• Asynchron-Verteilt:
• Anteilige Kosten von Latenz steigen.
• Latenz steigt mit Distanz (c konstant).
• Latenzanteil steigt mit Parallelisierung.
• Ausfallwahrscheinlichkeiten steigen.
• Transaktionen vs. Netsplits.
Dienstag, 5. Mai 2009 47CAP 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.
• Operations will complete, even if individual
components are unavailable.
• Choose Any Two! (P mandatory)
Dienstag, 5. Mai 2009 48ACID
• Choose Consistency.
• 2PC und was danach kommt stoppt
angesichts von Netzwerkpartitionen.
Dienstag, 5. Mai 2009 49BASE
• Basically Available, Soft state,
Eventually consistent
• Choose Availability, vorübergehend
inkonsistent.
• Writes in Warteschlange, Writes
wiederholbar formulieren.
Dienstag, 5. Mai 2009 50Folgerung für Uniabgänger
In asynchron-verteilten Umgebungen
mußt Du gegen jede einzelne Regel
Deiner Datenbankvorlesung verstoßen.
Dienstag, 5. Mai 2009 51Dienstag, 5. Mai 2009 52
Sie können auch lesen
