Your SlideShare is downloading. ×
0
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...
Upcoming SlideShare
Loading in...5
×

Intro to scaling Databases

1,647

Published on

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

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,647
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
22
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Transcript of "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>
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×