MySQL in großen Umgebungenblog.koehntopp.de/uploads/large_mysql.pdf · MySQL in großen Umgebungen Kristian Köhntopp, booking.com Mittwoch, 29. April 2009. Was nicht kommt • Dieser

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.


Was nicht kommt

• Der Vortrag geht davon aus, daß EXPLAIN, Indices usw. bekannt sind.


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.


Was macht Booking?

Booking verkauft Hotelbuchungen an Reisende auf Kommission.

Nur das.


Daten bei Booking.

• Hotel Basisdaten,

• Broschüren,

• Bewertungen & Scores,

• Verfügbarkeit nach Raum, Preisplan and Datum.

• Ein paar fette Data Warehouses.


Booking Tech

• Frontends mit Linux, Apache, mod_perl,

• Diverse Funktionsgruppen.

• Datenbanken: MySQL,

• Diverse Funktionsgruppen.

• Eine Menge Infrastrukturserver.


Booking Größe

• FE zu DB ratio: ca. 4-6 to 1.

• Ca. 160 slaves, ein Dutzend Schemata.

• Ca. 1000 Rechner.

• Schnell wachsend.


Booking 2006

• 32 Bit Host.

• MySQL 4.0.

• RAID-1.

• Ca. 45G Daten.

• Ein Dutzend Slaves.

• Ein Schema für alles.


Architektur: Synchron-Lokal

• Alle Abhängigkeiten vollständig in Integrity-Constraints abbildbar.

• Call-Wait, Single Thread, 2-Tier.


Call-Wait, Single-Thread

Apachemod_perl MySQL


Synchron-Lokal böse?

• Leicht zu debuggen.

• Kostengünstig, kurze Time-to-market:

• Featureentwickler können ungehindert arbeiten.


Synchron-Lokal böse?

• Vertikal skalierbar,

• Skalierungskosten in der Datenbank.

‣ Absolute Wachtumslimits.

‣ Inakzeptabel!


Kein DWH

• Auch außerhalb von Booking oft anzutreffen:

• Kein ETL,

• operative Daten mit BI/DSS vermischt.


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?


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.


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.


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


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.


Verfügbarkeit

• Partition by Functionality

• HA Anforderungen differenzieren:

• Redundanz auf Master

• Redundanz auf Slaves?

• Recoveryzeiten?

• OLTP vs. Service-DWH vs. DSS


Verfügbarkeit

• Basisverfügbarkeit:

• Verkauf bei toten Backoffice aufrecht erhalten?

• Lose Kopplung.

• Reserven berechnen.

• Negative SLA machen.


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.


HA

• HA Masters.

• Backup Slave.

• Worker Slaves:

• Slaves mit DAS noch RAID-10, im Grunde unnötig.


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.


Architektur: Verteilt-Lokal

• Datenbankzugriff gekapselt,

• Constraints über Instanzgrenzen validiert,

• Datenbankschema größer als eine Instanz.

• 2-Tier Call-Wait, single threaded.

• ETL + korrektes DWH.


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.


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.


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)


Konsequenz?

• Speichergesättigt.

• Deformiertes SQL: PK-Lookups.

• Queries ausprogrammiert.

• Constraints ausprogrammiert.

• Wieso dann noch SQL?

• CouchDB? Andere K/V Storages?


Konsequenz?

• TXN?

• Concurrency?

• Reporting & Ad-Hoc Queries?

‣ Profil von MySQL 4.1 erfüllbar.

‣ Drizzle.


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.


Kapazitätsplanung

• Last- und Wachstumskurven über das Jahr kalibrieren,

• projezieren.

• Continuous Integration auch mit Lasttests.

• Schwer zu warten.


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?



• Ziel von ISE ist Aufrechterhaltung bestehender Fertigkeiten und Flexibilität angesichts wachsender Last/Maschinenzahl.



• ISE unterscheidet sich von FE

• Keine Halbfertigprodukte:

• Payoff nur bei NULL manuellen Eingriffen, dann jedoch komplett.

• Teletubbies vs. militärisch geführt.



• 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).



• 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


Speichersättigung

• Speichersättigung durch:

• Extreme RAM-Größen.

• Partitionierung nach Werten.

• Schema Zielgröße:

• <128G pro Shard.


Disk Seeks

• Warum Speichersättigung?

• Disk Seek ~ 5ms

• RAM Access ~ 5ns

‣ 1:1 000 000 (gelogen!)

• 2. Lösung: Keine Seeks mehr!

‣ SSD!


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


256G

• Bekannte Probleme:

• innodb_max_dirty_pct.

• Recovery mit großen innodb_buffer_pool_size.

• Cache preheating nach Restart:

• autostart.sql + SELECT COUNT(*).


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.


Shards

• Migration nach Sharding:

• Mapping von Werten auf Instanzen.

• Map/Reduce für Resultsets.

• Wo?

• In der Anwendung.

• Im MySQL Proxy.


Asynchron-Verteilt

• Asynchron-Verteilt:

• Anteilige Kosten von Latenz steigen.

• Latenz steigt mit Distanz (c konstant).

• Latenzanteil steigt mit Parallelisierung.

• Ausfallwahrscheinlichkeiten steigen.

• Transaktionen vs. Netsplits.


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)


ACID

• Choose Consistency.

• 2PC und was danach kommt stoppt angesichts von Netzwerkpartitionen.


BASE

• Basically Available, Soft state, Eventually consistent

• Choose Availability, vorübergehend inkonsistent.

• Writes in Warteschlange, Writes wiederholbar formulieren.


Folgerung für Uniabgänger

In asynchron-verteilten Umgebungen mußt Du gegen jede einzelne Regel Deiner Datenbankvorlesung verstoßen.



Documents

MySQL in großen Umgebungenblog.koehntopp.de/uploads/large_mysql.pdf · MySQL in großen Umgebungen Kristian Köhntopp, booking.com Mittwoch, 29. April 2009. Was nicht kommt • Dieser