mysql in großen umgebungenblog.koehntopp.de/uploads/large_mysql.pdf · mysql in großen umgebungen...
TRANSCRIPT
MySQL in großen UmgebungenKristian Köhntopp, booking.com
Mittwoch, 29. April 2009
Was nicht kommt
• Dieser Vortrag geht davon aus, daß die Erstellung einer my.cnf ein gelöstes Problem ist.
Mittwoch, 29. April 2009
Was nicht kommt
• Der Vortrag geht davon aus, daß EXPLAIN, Indices usw. bekannt sind.
Mittwoch, 29. April 2009
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.
Mittwoch, 29. April 2009
Was macht Booking?
Booking verkauft Hotelbuchungen an Reisende auf Kommission.
Nur das.
Mittwoch, 29. April 2009
Daten bei Booking.
• Hotel Basisdaten,
• Broschüren,
• Bewertungen & Scores,
• Verfügbarkeit nach Raum, Preisplan and Datum.
• Ein paar fette Data Warehouses.
Mittwoch, 29. April 2009
Booking Tech
• Frontends mit Linux, Apache, mod_perl,
• Diverse Funktionsgruppen.
• Datenbanken: MySQL,
• Diverse Funktionsgruppen.
• Eine Menge Infrastrukturserver.
Mittwoch, 29. April 2009
Booking Größe
• FE zu DB ratio: ca. 4-6 to 1.
• Ca. 160 slaves, ein Dutzend Schemata.
• Ca. 1000 Rechner.
• Schnell wachsend.
Mittwoch, 29. April 2009
Booking 2006
• 32 Bit Host.
• MySQL 4.0.
• RAID-1.
• Ca. 45G Daten.
• Ein Dutzend Slaves.
• Ein Schema für alles.
Mittwoch, 29. April 2009
Architektur: Synchron-Lokal
• Alle Abhängigkeiten vollständig in Integrity-Constraints abbildbar.
• Call-Wait, Single Thread, 2-Tier.
Mittwoch, 29. April 2009
Call-Wait, Single-Thread
Apachemod_perl MySQL
Mittwoch, 29. April 2009
Synchron-Lokal böse?
• Leicht zu debuggen.
• Kostengünstig, kurze Time-to-market:
• Featureentwickler können ungehindert arbeiten.
Mittwoch, 29. April 2009
Synchron-Lokal böse?
• Vertikal skalierbar,
• Skalierungskosten in der Datenbank.
‣ Absolute Wachtumslimits.
‣ Inakzeptabel!
Mittwoch, 29. April 2009
Kein DWH
• Auch außerhalb von Booking oft anzutreffen:
• Kein ETL,
• operative Daten mit BI/DSS vermischt.
Mittwoch, 29. April 2009
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?
Mittwoch, 29. April 2009
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.
Mittwoch, 29. April 2009
Beispiel 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.
Mittwoch, 29. April 2009
Beispiel 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
Mittwoch, 29. April 2009
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.
Mittwoch, 29. April 2009
Verfügbarkeit
• Partition by Functionality
• HA Anforderungen differenzieren:
• Redundanz auf Master
• Redundanz auf Slaves?
• Recoveryzeiten?
• OLTP vs. Service-DWH vs. DSS
Mittwoch, 29. April 2009
Verfügbarkeit
• Basisverfügbarkeit:
• Verkauf bei toten Backoffice aufrecht erhalten?
• Lose Kopplung.
• Reserven berechnen.
• Negative SLA machen.
Mittwoch, 29. April 2009
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.
Mittwoch, 29. April 2009
HA
• HA Masters.
• Backup Slave.
• Worker Slaves:
• Slaves mit DAS noch RAID-10, im Grunde unnötig.
Mittwoch, 29. April 2009
Storage Performance
• NetApp Performance:
• Hohe Latenz, hoher Durchsatz.
• Auf den meisten DBs schneller als DAS.
• Gegenbeispiel visitstats:
• Großes DWH mit MyISAM, große Aggregationen.
Mittwoch, 29. April 2009
Architektur: Verteilt-Lokal
• Datenbankzugriff gekapselt,
• Constraints über Instanzgrenzen validiert,
• Datenbankschema größer als eine Instanz.
• 2-Tier Call-Wait, single threaded.
• ETL + korrektes DWH.
Mittwoch, 29. April 2009
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.
Mittwoch, 29. April 2009
Joins
• 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.
Mittwoch, 29. April 2009
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,
• oder anders herum.
• Limit: Intermediate Hash < Memory.Mittwoch, 29. April 2009
Joins
• 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)
Mittwoch, 29. April 2009
Konsequenz?
• Speichergesättigt.
• Deformiertes SQL: PK-Lookups.
• Queries ausprogrammiert.
• Constraints ausprogrammiert.
• Wieso dann noch SQL?
• CouchDB? Andere K/V Storages?
Mittwoch, 29. April 2009
Konsequenz?
• TXN?
• Concurrency?
• Reporting & Ad-Hoc Queries?
‣ Profil von MySQL 4.1 erfüllbar.
‣ Drizzle.
Mittwoch, 29. April 2009
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.
Mittwoch, 29. April 2009
Kapazitätsplanung
• Last- und Wachstumskurven über das Jahr kalibrieren,
• projezieren.
• Continuous Integration auch mit Lasttests.
• Schwer zu warten.
Mittwoch, 29. April 2009
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?
Mittwoch, 29. April 2009
Infrastrukturentwicklung
• Ziel von ISE ist Aufrechterhaltung bestehender Fertigkeiten und Flexibilität angesichts wachsender Last/Maschinenzahl.
Mittwoch, 29. April 2009
Infrastrukturentwicklung
• ISE unterscheidet sich von FE
• Keine Halbfertigprodukte:
• Payoff nur bei NULL manuellen Eingriffen, dann jedoch komplett.
• Teletubbies vs. militärisch geführt.
Mittwoch, 29. April 2009
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).
Mittwoch, 29. April 2009
Infrastrukturentwicklung
• Provisioning:
• Kickstart/Jumpstart & cfengine/puppet/Chef.
• Visibility:
• Nagios, Cacti, MEM.
• Process:
• Ticketing, Bugtracking.
• Downgrading operations:
• Web Interfaces.Mittwoch, 29. April 2009
Booking 2010Wieder speichergesättigt
Lose gekoppelt
256GSSD
Shards
Queue
EstimateCache
Mittwoch, 29. April 2009
Speichersättigung
• Speichersättigung durch:
• Extreme RAM-Größen.
• Partitionierung nach Werten.
• Schema Zielgröße:
• <128G pro Shard.
Mittwoch, 29. April 2009
Disk Seeks
• Warum Speichersättigung?
• Disk Seek ~ 5ms
• RAM Access ~ 5ns
‣ 1:1 000 000 (gelogen!)
• 2. Lösung: Keine Seeks mehr!
‣ SSD!
Mittwoch, 29. April 2009
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.Mittwoch, 29. April 2009
SSD• 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
Mittwoch, 29. April 2009
256G
• Bekannte Probleme:
• innodb_max_dirty_pct.
• Recovery mit großen innodb_buffer_pool_size.
• Cache preheating nach Restart:
• autostart.sql + SELECT COUNT(*).
Mittwoch, 29. April 2009
Shards• 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.
Mittwoch, 29. April 2009
Shards
• Migration nach Sharding:
• Mapping von Werten auf Instanzen.
• Map/Reduce für Resultsets.
• Wo?
• In der Anwendung.
• Im MySQL Proxy.
Mittwoch, 29. April 2009
Asynchron-Verteilt
• Asynchron-Verteilt:
• Anteilige Kosten von Latenz steigen.
• Latenz steigt mit Distanz (c konstant).
• Latenzanteil steigt mit Parallelisierung.
• Ausfallwahrscheinlichkeiten steigen.
• Transaktionen vs. Netsplits.
Mittwoch, 29. April 2009
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.
• Operations will complete, even if individual components are unavailable.
• Choose Any Two! (P mandatory)
Mittwoch, 29. April 2009
ACID
• Choose Consistency.
• 2PC und was danach kommt stoppt angesichts von Netzwerkpartitionen.
Mittwoch, 29. April 2009
BASE
• Basically Available, Soft state, Eventually consistent
• Choose Availability, vorübergehend inkonsistent.
• Writes in Warteschlange, Writes wiederholbar formulieren.
Mittwoch, 29. April 2009
Folgerung für Uniabgänger
In asynchron-verteilten Umgebungen mußt Du gegen jede einzelne Regel Deiner Datenbankvorlesung verstoßen.
Mittwoch, 29. April 2009
Mittwoch, 29. April 2009