Kristian Köhntopp, booking.com
Werbung
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
