NoSQL-Datenbanken - Abteilung Datenbanken Leipzig

NoSQL-Datenbanken
Kapitel 4: Skalierbare
Web-Anwendungen
Lars Kolb
Sommersemester 2014
Universität Leipzig
http://dbs.uni-leipzig.de
4-1
Inhaltsverzeichnis
• Skalierbarkeit
• Google App Engine: Architektur und Dienste
• Data Store, MemCache, TaskQueue
4-2
Skalierbarkeit einer Web-Anwendung
• Skalierbarkeit (für Software)
– Proportionale (lineare) Zunahme der Leistung bei Hinzufügen von Ressourcen
• Leistung-Metriken für Web-Anwendungen
– RPS (Requests per Second): Anzahl der („gleichzeitig“) verarbeiteten Requests pro
Zeitintervall
– Response-Zeit: Durchschnittliche Bearbeitungszeit eines Requests
– Anzahl der Fehler: Request konnte nicht verarbeitet werden (Time-out, ProgrammFehler, …)
• Ressourcen für Web-Anwendungen
– Horizontal: Anzahl der Server: Web-Server, Load Balancer, DB-Server, …
– Vertikal: Ressourcen eines Servers (RAM, HDD, Netzwerk, …)
4-3
Skalierbarkeit: Beispiel
• Panoramio: GAE-Anwendung zur Verknüpfung von Google Maps mit Fotos
• Bis zu 2T RPS
• Geringe/konstante Response
(meist <300ms)
• Fehlerrate meist << 1%
4-4
Inhaltsverzeichnis
• Skalierbarkeit
• Google App Engine: Architektur und Dienste
• Data Store, MemCache, TaskQueue
4-5
Google App Engine (GAE)
• Plattform zur Entwicklung und zum Hosting von Web-Anwendungen (PaaS)
– Seit 2008 verfügbar
– Ca. 200,000 Apps mit 1.5 Milliarden Pageviews pro Tag (Stand: 05/2011)
• Sehr gute Integration mit Eclipse
• Beispiel-App: Hochzeit von William+Kate
– 15 Mio Pageviews am Tag der Hochzeit, 2,000 Requests pro Sekunde
– Peak: 32,000 Requests pro Sekunde
• Ansätze für Skalierbarkeit
– Technische Beschränkung
– Spezialisierte Web-Dienste
4-6
GAE: Hosting-Service
• Webanwendungen, d.h. Zugriff via Browser (HTML) oder programmatisch
• Frontend-Instanzen (default)
– Hoch-skalierbar, Handling aller zeit-sensitiven (Web) Requests (mit Limit 30s)
• Backend-Instanzen
– Limitierte Skalierbarkeit, längere Berechnungen (z.B. cron)
• Quota-basiertes Pay-per-use
– „geringer“ Ressourcenverbrauch ist kostenlos
– Maximale Kosten pro Ressource definierbar
• Dienste
–
–
–
–
Datastore
Email
XMPP
…
Ressource
Free Quota
Pricing
Frontend-CPU
28 Std.
$0.08 / Std
Traffic (incoming)
1G
Free
Traffic (outgoing)
1G
$0.12 / GB
Datastore
1G
(50K ops)
$0.24 / GB / Monat
($0.01-$0.10 / 100K ops)
EMail
100
$0.01 / 100
4-7
GAE: Architektur
• Komponenten
– Laufzeitumgebung (Java, Python, Go)
– Datastore als Datenbank
– Skalierbare Services (z.B. E-Mail, URL Fetch, XMPP, …)
4-8
GAE: Architektur (2)
Quelle: http://www.slideshare.net/turbomanage/
develop-and-deploy-scalable-apps-with-google-app-engine
4-9
GAE-Techniken
• „Crash and restart“
Quelle: Steve Huffman - Lessons learned while at reddit.com
http://de.slideshare.net/carsonified/steve-huffman-lessons-learned-while-at-redditcom
– Abbruch (zu) lange dauernder Operationen (z.B. Frontend-Request)
– GAE: Request wird nach 30s abgebrochen;
• „Keep it stateless“
–
–
–
–
Ziel: Jeder AppServer kann jeden Request bearbeiten
Vereinfachtes Load Balancing und Skalierung
Fehler-Handling durch Neustart von AppServer
GAE: AppServer bei Fehler neu gestartet
• Separierung von Diensten
–
–
–
–
Realisierung von Funktionen als Dienste
Gruppierung ähnlicher Dienste/Daten auf gleichen Knoten (u.a. wegen Caching)
Flexiblere Skalierung unterschiedlicher Knoten-Typen
GAE: Funktionen als Dienste (z.B. XMPP, …) und nicht als Library bereitgestellt
4-10
GAE-Techniken (2)
• Flexibler, anwendungsspezifischer DataStore
–
–
–
–
Einfache und skalierbare Erweiterung des Datenbank-“Schemas“
Anwendung muss Konsistenz, Partitionierung etc. (z.T.) selbst realisieren
Query-Performanz durch eingeschränkte Anfragemächtigkeit (z.B. keine Joins)
GAE: BigTable/MegaStore
• Memcache: HashMap im Hauptspeicher
–
–
–
–
Ziel: alle Daten, die potenziell nochmal gebraucht werden, in Memcache
Query-Results, Session/User-Daten, Zwischenergebnisse, …
Minimierung des Zugriffs auf persistenten DataStore
GAE: Memcache
• Speicherung redundanter Daten
– De-normalisierte Darstellung und/oder mehrfache Speicherung in unterschiedlichen
Strukturen / Formaten
• Kein Threading - Durchführung „langer“ Berechnungen offline
– GAE: Tasks
4-11
GAE-Techniken: Vor- und Nachteile
Technik
Vorteil
Nachteil
Crash and
Restart
Keine Blockade von Ressourcen
Keep it
stateless
Einfaches Load Balancing; gute Skalierung
da keine Abhängigkeiten
DienstGruppierung von Diensten günstig für
Separierung Caching und Dienst-spezifische Skalierung
DataStore
Schema
Einfache Erweiterbarkeit
Höhere Performanz durch einfache
Anfrage(-arten)
Redundante Einfacherer / schnellerer Datenzugriff durch
Daten
de-normalisierte Darstellung und
Repräsentation in unterschiedlichen
Formaten/Strukturen
MemCache
Schneller Datenzugriff
OfflinePerformanter Online-Zugriff auf OfflineBerechnung Ergebnisse
4-12
GAE Skalierung
• Laufzeitumgebung: Sandbox ähnlich Java Virtual Machine
– Kein voller JVM-Funktionsumfang (z.B. Sockets)
– Beenden / Umsetzen von WebApp-Instanzen zur Laufzeit
• Mehrere Instanzen einer GAE-Applikation
– HTTP-Requests per Load Balancer verteilt
– Jede Instanz hat Request-Queue
– Anpassung der Anzahl der Instanzen an Hand Queue-Längen
4-13
GAE Admin Console
4-14
GAE-Programmierung
• Instanz läuft innerhalb einer Sandbox
– Keine virtuelle Maschine, eher „Linux Container“
– Schränkt Zugriff auf Funktionen des OS ein
•
•
•
•
Kein Starten neuer Prozesse / Threads
Keine Netzwerkverbindungen (also auch z.B. keine JDBC-Verbindung)
Kein File-Zugriff (nur Lesen eigener statischer Ressource-Files möglich)
Keine Interaktionen mit anderen Instanzen (der gleichen Applikation)
• Java Sandbox
– Modifikation / Konfiguration
der JVM / JRE
• Nutzung von StandardJava-Webtechnologien
(u.a. Servlet)
– Andere PS möglich:
Python, Go
Quelle: http://www.slideshare.net/turbomanage/
develop-and-deploy-scalable-apps-with-google-app-engine
4-15
GAE: Services
• DataStore, MemCache, TaskQueue (sieh nächste Folien)
• Google Cloud SQL
– mySQL-Datenbank
• BlobStore
– Speichern / Laden von Binary Large Objects (BLOBs)
• Authentifizierung
– Anmeldung mit Google Accounts
• URL Fetch
– Zugriff auf Web-Ressourcen
• Mail / XMPP
– Senden / Empfangen von E-Mails / XMPP-Nachrichten
• Weitere: Suche, Multi-Tenancy (Mehrmandantenfähigkeit),
Bildmanipulation, …
4-16
Inhaltsverzeichnis
• Skalierbarkeit
• Google App Engine: Architektur und Dienste
• Data Store, MemCache, TaskQueue
4-17
DataStore
• Basis: MegaStore ( BigTable  GFS)
• Einfache Anbindung an Programmiersprache
– Mehrwertige Properties möglich
– Kein OR-Mapping notwendig
DataStore
Java
Kind
Klasse
Entity
Objekt
Property
Feld
• Typ/Kind hat keine Implikationen auf Properties
– Bsp: Zwei Entities des selben Typs/Kind können unterschiedliche Properties haben
String kind = "book";
String isbn = "978-1-4493-9826-2";
Key key1 = KeyFactory.createKey(kind, isbn);
Entity book1 = new Entity(key1);
book1.setProperty("author", "Dan Sanderson");
book1.setProperty("title", "Programming GAE");
book1.setProperty("year", 2012);
String isbn2 = "123-4-567-01011-2";
Key key2 = KeyFactory.createKey(kind, isbn2);
Entity book2 = new Entity(key2);
book2.setProperty("editor", "James Kirk");
4-18
DataStore: Put und Get
Entity
Key key = KeyFactory.createKey(kind, id);
Entity entity = new Entity(key)
ds.put(entity);
Key key =
KeyFactory.createKey(kind, id);
Entity entity = ds.get(key);
DatastoreService ds =
DatastoreServiceFactory.getDatastoreService();
Datastore
• Put unterscheidet nicht zwischen „create“ und „update“
• Batch-Modus: Put und Get für Menge von Entities bzw. Keys
– Maximalgrößen wegen Skalierbarkeit (u.a. 1,000 Entities)
• Löschen mittels Delete unter Angabe des Keys
4-19
DataStore: Anfragen
• Ziel: performante Anfragen
– Möglichst viele Anfragen via get(key)
• Technische Einschränkungen
– Zeitlimit für Request (>Zeitlimit für Data-Store-Anfragen)
– Beschränkung der Größe des Antwortergebnisses
• Funktionale Einschränkungen
– Keine SQL-Mächtigkeit
– Einschränkungen bei mehreren Filtern („WHERE-Bedingung“) auf unterschiedlichen
Properties
– Keine Joins
– Keine Sub-Queries (z.B. für Filterbedingungen )
• Voraussetzung
– Index-Definition für alle verwendeten Properties
4-20
DataStore: Anfrage-Auswertung
• Beispiel-Query
DatastoreService ds …
Query q = new Query("book");
q.addFilter(„year",
Query.FilterOperator.LESS_THAN_OR_EQUAL, 1950);
q.addSort("year");
PrepareQuery pq = ds.prepare(q);
for (Entity result : qp.asIterable()) {
String title = result.getProperty("title");
// …
}
• Ausführung bei Zugriff auf Ergebnisse
• Zugriff via Iterator
– Übertragung im Batch-Mechanismus
4-21
MemCache
• Hochperformanter, temporärer Datenspeicher aus Hauptspeicher
• Sehr gute Zugriffszeiten
• Eintrag
– Key-Value-Paar mit eindeutigem Schlüssel und beliebigen (serialisierbaren) Value
– Größenbeschränkung (1 MB)
– Verfallszeit, wann der Eintrag aus dem Memcache entfernt werden soll
• Daten werden je nach Auslastung des Memcache früher wieder verdrängt
4-22
MemCache: Infrastruktur
• Client-Server-Prinzip
• Server
–
–
–
–
–
Hash-Table mit Key-Value-Paaren
Key max. 250 Bytes, Value max. 1MB
Kommunikation über einfaches Protokoll (put, get) per TCP/UDP
Verdrängungsstrategie: LRU (least recently used)
Keine Kenntnis über andere Server
• Client
– Bildung des Keys (ggf. Hash-Funktion)
– Mapping: Key  Server mittels Consistent Hashing (vgl. Amazon Dynamo)
– (De-)Serialisierung des Value-Objekts
4-23
GAE: TaskQueues
• Tasks = „Einheit“ für Hintergrund-Berechnung
– Implementiert als Servlet, Aufruf via URL
– Ergebnis-Weitergabe meist via DataStore oder Servlet-Aufruf (Task)
• Tasks notwendig für Berechnungen über Zeitlimit
– Bsp: Website-Crawling, komplexere Berechnungen
• Push-Queue-Konzept
– Ausführungsreihenfolge: (im Prinzip) FIFO
– Token-Bucket-Steuerung mit Parametern
• Rate: Anzahl der Tasks pro Sekunde
• Bucket-Size: maximale Anzahl der gleichzeitig ausgeführten Tasks
– Retry-Mechnismus für fehlgeschlagene Tasks (HTTP-Response-Code)
• Pull-Queue
– Anwendung steuert Verarbeitung on-demand
4-24
Zusammenfassung
• Skalierbarkeit wichtig für (populäre) Web-Anwendungen
• Hosting-Plattform: Google App Engine
• Techniken
– Begrenzte Funktionalität
– Spezialisierte Web-Dienste
4-25