MySQL in großen Umgebungenblog.koehntopp.de/uploads/large_mysql.pdf · MySQL in großen Umgebungen...

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