Intro to scaling Databases

Einführung in die Datenbank-Skalierung bei WebApps Heiko Seebach

Schritt 1: Alles auf einem Host Host DB Web Server Web Server

Schritt 2: zwei Hosts Host Host DB Web Server Web Server

Schritt 3: mehrere WebServer-Hosts Host DB Host Web Server Web Server Host Web Server Web Server LB

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

Schritt 4b: mehrere DB-Hosts - Cluster Host DB-Master Host Web Server Web Server Host Web Server Web Server Host DB-Master LB

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 :-)

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

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

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

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”

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

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

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 :-)

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%

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

http://blog.telewebber.de	86
http://www.slideshare.net	8
http://telewebber.com	5
https://craftler.dyndns.org:1111	1

Intro to scaling Databases

by Heiko Seebach on Sep 29, 2008

Accessibility

Categories

Tags

Upload Details

Usage Rights

4 Embeds 100

Statistics

Intro to scaling Databases — Presentation Transcript