Intro to scaling Databases
- 1. Einführung in die Datenbank-Skalierung bei WebApps Heiko Seebach
- 2. Schritt 1: Alles auf einem Host Host DB Web Server Web Server
- 3. Schritt 2: zwei Hosts Host Host DB Web Server Web Server
- 4. Schritt 3: mehrere WebServer-Hosts Host DB Host Web Server Web Server Host Web Server Web Server LB
- 5. Schritt 4a: mehrere DB-Hosts - Replication Infrastruktur muss mit mehreren DBs umgehen können intern:Multi-DB-Connections in Rails extern: SQLRelay Host Host DB-Master Host Web Server Web Server Host Web Server Web Server Host DB-Slave LB
- 6. Schritt 4b: mehrere DB-Hosts - Cluster Host DB-Master Host Web Server Web Server Host Web Server Web Server Host DB-Master LB
- 7. Und nun? Webserver skalieren mit weiteren Hosts linear weiter, die DB nicht! Mächtigere DB-Hosts Immer mehr manuell optimierte DB-Statements Komplexere DB-Setups: z.B. Cluster plus Master/Slave-Replication in mehreren Kaskaden Partitionierung/Sharding Sehr ähnlich, größter Unterschied: Partitionierung -> oldschool Sharding -> Hype :-)
- 8. Schritt 5: DB-Partitionierung/Sharding Zentrale User/Naming-DB, nur grundlegende User-Daten: Authentifizierung, NLS, weiterführende DB-Adresse Host Host Zentrale DB User/Naming Host Web Server Web Server Host Web Server Web Server Host DB Nr. 1 LB
- 9. Sharding ID-Management: kein Auto-Increment! User-IDs der zentralen User-DB überall nutzen Für andere Entitäten: Zentrale ID-Vergabe (in Chargen) Inkrement um Anzahl der DBs plus Offset Typischerweise große Code-Änderungen notwendig
- 10. Sharding Denormalisierte Daten Pro: weniger Joins, lokale Operationen Con: mehr Redundanz Parallelisierte Daten über viele physische Hosts Pro: günstigere HW kleinere Datenmengen HA: einfachere Backup-Konzepte, etc Keine Replication notwendig
- 11. Sharding Aufsplitten nach welchen Kriterien? Con: es gibt nicht die richtige Antwort ”Rebalancing” von Shards Con: oft heftige Downtime wegen Migration Con: solide Vorarbeit notwendig, für einen Fall, der nur evtl. notwendig wird SQL-Joins: Con: Über DB-Grenzen hinweg? Con: Web2.-0/Social-Networks: ”Jeder kann mit Jedem” Junge Thematik: Con: wenig Expertise Con: wenig (keine?) ausgereiften Bibliotheken -> ”Selbst ist die Frau”
- 12. Schritt 5: DB-Partitionierung/Sharding Host Host Host Host Zentrale DB User/Naming Host Web Server Web Server Host DB-Master- Cluster Nr. 1 LB Host Static Files Server Host langlaufende Prozesse Host Host DB-Slaves Nr. 1 Host Session/ Suche/ Reporting
- 13. Lösungen? Vorher nachdenken! Sharding nur als ”letzte Lösung” sehen? Trade-Off zwischen Aufwand am Anfang und erst wenn es notwendig wird -> YAGNI? Aber: Wenn absehbar, dass sharding sein muss, dann lieber heute als morgen schon implementieren und mitlaufen lassen, nicht den ”Big-Bang” abwarten
- 14. Und was noch? Weitere Ansätze zur DB-Entlastung Session-Storage auslagern Weitere DB-Aufgaben auf replizierte Slaves Textsuche Stammdaten-Import-Export Reporting Backup Unterschied OLTP/OLAP leben (evtl. DWH) Generell: Langlaufende Operationen auslagern (hilft auch dem Webserver :-)
- 15. Weitere Ansätze zur DB-Entlastung Squid - Caching-Proxy Memcached – wahnsinnig schnell, einfach Framework-spezifisches Caching Sehr abhängig von den Anforderungen! Paradebeispiel Wikipedia: 78% squid, 7% memcached -> DB nur 15%
- 16. Weblinks Squid: http://www.squid-cache.org/ Memcached: http://www.danga.com/memcached/ SQLRelay: http://sqlrelay.sourceforge.net/ Hibernate Shards: http://www.hibernate.org/414.html Rails-spezifisch: BackgrounDRb (Hintergrund-Prozesse): http://backgroundrb.rubyforge.org/ Interlock (memcache-lib): http://blog.evanweaver.com/files/doc/fauna/interlock/files/README.html Ferret (Textsuche): http://projects.jkraemer.net/acts_as_ferret/ Heiko Seebach http://www.xing.com/profile/Heiko_Seebach