Intro to scaling Databases
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Intro to scaling Databases

  • 2,756 views
Uploaded on

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

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,756
On Slideshare
2,655
From Embeds
101
Number of Embeds
5

Actions

Shares
Downloads
21
Comments
0
Likes
1

Embeds 101

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

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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