Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
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 <ul><ul><li>Infrastruktur muss mit mehreren DBs umgehen können </li></ul></ul><...
Schritt 4b: mehrere DB-Hosts - Cluster Host DB-Master Host Web Server Web Server Host Web Server Web Server Host DB-Master...
Und nun? <ul><ul><li>Webserver skalieren mit weiteren Hosts linear weiter, die DB nicht! </li></ul></ul><ul><ul><li>Mächti...
Schritt 5: DB-Partitionierung/Sharding <ul><ul><li>Zentrale User/Naming-DB,  </li></ul></ul><ul><ul><ul><li>nur grundlegen...
Sharding <ul><li>ID-Management:  </li></ul><ul><ul><li>kein Auto-Increment! </li></ul></ul><ul><ul><li>User-IDs der zentra...
Sharding <ul><li>Denormalisierte Daten </li></ul><ul><ul><li>Pro: weniger Joins, lokale Operationen </li></ul></ul><ul><ul...
Sharding <ul><ul><ul><li>Aufsplitten nach welchen Kriterien? </li></ul></ul></ul><ul><ul><ul><ul><li>Con: es gibt nicht  d...
Schritt 5: DB-Partitionierung/Sharding Host Host Host Host Zentrale DB User/Naming Host Web Server Web Server Host DB-Mast...
Lösungen? <ul><li>Vorher nachdenken! </li></ul><ul><li>Sharding nur als ”letzte Lösung” sehen? </li></ul><ul><li>Trade-Off...
Und was noch? <ul><li>Weitere Ansätze zur DB-Entlastung </li></ul><ul><ul><li>Session-Storage auslagern </li></ul></ul><ul...
Weitere Ansätze zur DB-Entlastung <ul><li>Squid - Caching-Proxy </li></ul><ul><li>Memcached – wahnsinnig schnell, einfach ...
Weblinks <ul><ul><li>Squid:  http://www.squid-cache.org/ </li></ul></ul><ul><ul><li>Memcached:  http://www.danga.com/memca...
Nächste SlideShare
Wird geladen in …5
×

Intro to scaling Databases

2.145 Aufrufe

Veröffentlicht am

Introduction on scaling databases. Held on Barcamp Stuttgart in Sep 2008

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

Intro to scaling Databases

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

×