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

Infrastruktur muss mit mehreren DBs umgehen können

intern:Multi-DB-Connections in Rails

extern: SQLRelay

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

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

Zentrale User/Naming-DB,

nur grundlegende User-Daten: Authentifizierung, NLS, weiterführende DB-Adresse

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

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

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”

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

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

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%

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

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