Wetterbericht: Clouds als Storage

Transkript

1 Wetterbericht: Clouds als Storage OOP Januar 2010 in München Nightschool, Nmi 3, 27. Januar 2010 Michael C. Jaeger und Uwe Hohenstein Siemens CT T, Corporate Research and Technologies Global Technology Field System Architecture and Platforms <nur für internen Gebrauch > / Copyright Siemens M. C. Jaeger AG und U. Hohenstein. Alle Rechte Alle Rechte vorbehalten.

2 Übersicht Was uns heute erwartet! Kurzer Überblick Einheitlicher Kenntnisstand Spielarten des Cloud Storages Blobs, Tables und SQL Vor- und Nachteile Im Vergleich zum klassischen Datenbankserver Vorstellung prominenter Produkte Windows Azure, Amazon (z.b. S3), Couch und Google Generelle Überlegungen Kosten, Migration Seite 2 - OOP, München, Januar 2010

3 Cloud Computing und Cloud Storage Allgemeiner Überblick und grundlegende Konzepte <nur für internen Gebrauch > / Copyright Siemens AG Alle Rechte vorbehalten.

4 Cloud Computing Was ist das? Unter Cloud Computing verstehen wir ein neues Geschäftsmodell, das bestehende Technologien auf neuartige Weise kombiniert. Ziel des Cloud Computings ist die wirtschaftlich effiziente Bereitstellung von IT Ressourcen auf unterschiedlichen Abstraktionsebenen: Infrastruktur, Plattformen und Softwaredienste. Verwandtschaft mit: SOA und Grid Computing Utility Computing Virtualisierung Namhafte Anbieter treten in den Markt ein: Microsoft, Google, IBM, Ubuntu, Amazon mit hohen Investitionen mit neuartigen Partnerschaften und Konkurrenzsituationen Seite 4 - OOP, München, Januar 2010

5 Ebenen des Cloud Computings Kunden-Anwendung SaaS Software-as-a-Service z.b. Salesforce PaaS Platform-as-a-Service z.b. Google App Engine IaaS Infrastructure-as-a-Service z.b. Amazon Elastic Computing Cloud Seite 5 - OOP, München, Januar 2010

6 Verwandte Technologien - und deren Hauptunterschiede SOA: Paradigma, welches die Bereitstellung von Funktionalität im Sinne einer Dienstleistung anstrebt Unterschied: Cloud Computing bezieht SOA-Technologie mit ein, aber umfasst auch weitere Dinge, zum Beispiel Virtualisierung Grid Computing: Bereitstellung einer gemeinsamen Ressource durch einen homogenen Verbund Unterschied: Die Transparenz des Ortes wird zwar aufgegriffen, aber geht über das Bereitstellen einer Ressource hinaus. Virtualisierung: Umsetzung eines Schichten-Modells, um bei der Nutzung der unteren Schicht physikalische Transparenz zu erlangen Unterschied: Cloud Computing bietet Virtualisierung auf unterschiedlichen Ebenen Utility Computing: Nutzung von Computing- und Storage-Ressourcen auf Pay-Per-Use-Basis Unterschied: Utility Computing = Infrastruktur, kein SaaS Seite 6 - OOP, München, Januar 2010

7 Cloud Computing Die Geschäftsperspektive a) Einsparung durch Pay-Per-Use Dynamische Infrastruktur, Kosten werden an den Umsatz gekoppelt Dimensionierung vorab unnötig, Investitionen werden geringer Keine Kosten für Administratoren b) Rationalisierungseffekt durch größtmöglichen Maßstab Neue Generation von Rechenzentren Bedarf Zeit Quellen: Pressebilder HP Corp. & Microsoft Corp. Seite 7 - OOP, München, Januar 2010

8 Beispiele Speicher-Intensiver Applikationen Zitate des Amazon Case Study Clubs (Auswahl): Sonian: Archivierung: Dienstleistung für Unternehmen die gesetzliche Vorhaltefrist für Daten bereitzustellen. 37signals: Speicherung der Daten für Basecamp and Campfire Web- Applikationen für Projekt-Management (ca. 1TB) bei Amazon S3. Altexa: Backup Lösung für 1 USD pro GB pro Monat. ElephantDrive: Funktionsreicher Online-Speicher mit Verschlüsselung, Gastzugriffen, effizienter Übertragungstechnik. MiraiBio: Software zur Sequenzierung von Proteinen für DNA Analyse. Kommt in Verbindung mit Client-Software zum Einsatz, die auf Notebook-Computern für mobil arbeitende Biologen installiert ist. Seite 8 - OOP, München, Januar 2010

9 Cloud Computing - Where ist the storage? Speicher und Rechenkapazität sind Basisdienste Dimensionierung dieser Ressourcen beeinflusst wesentlich die Kosten, bei Speicher: Anschaffung von Festplatten Anschaffung von Datensicherungsmedien & Administration Dimensionierung der Anbindung des Speichers Zwei Szenarien für Storage-Nutzung: Applikation und Storage zusammen in der Cloud Einfacher Fall Applikation lokal und nur Storage in der Cloud Z.B. bei kritischer Geschäftslogik Z.B. bei Bereitstellung der Daten für verteilte Nutzergruppe Seite 9 - OOP, München, Januar 2010

10 Cloud Computing Architekturen Client Provider Cloud Anwendung läuft komplett in der Cloud, Rich Client kommuniziert über Internet mit Anwendung In House App Provider Cloud Eigene Anwendung nutzt Komponenten oder Dienste, die in der Cloud zur Verfügung gestellt werden Private / On-Premise Cloud Nutzung von Cloud Technologien, um Rationalisierungsvorteile für eigene Infrastruktur zu nutzen Kombination On-Premise Provider Cloud Nutzung der Provider Cloud unter Beibehaltung organisatorischer Rahmenbedingungen für kritischen Teil der Anwendung Seite 10 - OOP, München, Januar 2010

11 Motivationen für Cloud Storage Mit einem klassischen Datenbankserver habe ich Probleme, weil... Ich nicht weiß, wie mein Geschäft wachsen wird Anforderungen an Skalierbarkeit Integrierte Lastverteilung Ich die Investitionen nicht bereitstellen kann Start-up Phase eines jungen Unternehmens Experimentelles Geschäft Ich bestimmte Anforderungen an Zuverlässigkeit habe Automatisches Failover & Replizierung Ich Zugriff auf Daten jederzeit, überall, von jedem Gerät benötige Ich die Administration nicht zur Verfügung stellen kann Aufbau einer Datenbankadministration zu aufwändig Ich schnell in den Markt will, Speicherdienste zeitnah nutzen will Keine Zeit, um ein Datenbanksystem aufzubauen Ich mich auf die Funktionalität, auf das Kerngeschäft konzentrieren will Seite 11 - OOP, München, Januar 2010

12 Speichern in der Cloud keine Missverständnisse! Grundsätzliche Möglichkeit: Eigenen Datenbankserver in der Cloud betreiben: mitunter aufwändiges Deployment Fernadministration notwendig auf virtualisierter Plattform Nutzt nicht die Technologien zur Virtualisierung der Anbieter aus Widerspricht in vielen Punkten den genannten Motivationen Technische Möglichkeiten der Anbieter: Nutzung der Dienste im Rahmen der Cloud Umgebung Blob-, Object-, Document-Storages Table Storages Relationaler Datenbankserver Seite 12 - OOP, München, Januar 2010

13 Architekturelle Möglichkeiten 1. Desktop/Server-Applikation als Client: Zugriff auf Cloud Datenbank, wie beim klassischen RDMS: Höhere Latenzzeiten als bei einem lokalem Server Zugriff von verschiedenen Orten aus möglich 2. Web-basiertes Interface für Datenbank-Applikation in Cloud; Verbindung über Internet-Technologien: Universeller Zugriff von verschiedenen Orten Universeller Zugriff von verschiedenen Plattformen aus Hoher Aufwand für kleine Daten, häufige Zugriffe 3. Applikationslogik läuft in Cloud: Daten werden über Funktionen bereitgestellt Sinnvoll bei notwendiger Verarbeitung der Daten Seite 13 - OOP, München, Januar 2010

14 Technische Möglichkeiten Unterschiedliche Arten von Cloud Storages: Blob-, Object-, Document-Storages Table Storages Relationaler Datenbankserver <nur für internen Gebrauch > / Copyright Siemens AG Alle Rechte vorbehalten.

15 Cloud Storage BLOB Storage Speicherung von Text- und Binärdaten in der Cloud Hierarchie: Container : eindeutiger Name; enthält BLOB-Objekte Objekt = Objektdaten (Datei) + Metadaten (Attribut/Wert) + HTTP-Metadaten (ETag, Last-Modified, Content-Length, Content-Type, Content-Encoding, Content-Language etc.) Zugriff: SOAP & REST über HTTP(S) APIs dazu (JetS3t, Apache Axis oder.net) Container Objekt; hierarchisch organisiert Adressierung: &maxresults=10&include=metadata Seite 15 - OOP, München, Januar 2010

16 REST Representational State Transfer (RFC 2616) Durch Roy Fielding in seiner Dissertation geprägter Ausdruck, der Architekturstil für vernetzte Systeme beschreibt REST-Request kann entweder über HTTP oder HTTPS verschickt werden Operationen: basierend auf GET, HEAD, PUT, DELETE In REST ist alles im Web eine Ressource, die über URI zugreifbar ist XML-Dokument als Antwort Vorteil von REST: Zugriff sowohl mit Web-Browser als auch programmatisch aus verschiedenen Sprachen wie Java oder VB.NET mit Hilfe von REST- Bibliotheken Beispiel: Löschen eines BLOB-Objekts DELETE /photos/2009/barbados/beach.jpg HTTP/1.1 User-Agent: dotnet Host: s3.amazonaws.com Date: Tue, 15 Jan :20: x-amz-date: Tue, 15 Jan :20: Authorization: AWS 0PN5J17HBGZHT7JJ3X82:k3nL7gH3+PadhTEVn5EXAMPLE Seite 16 - OOP, München, Januar 2010

17 Operationen Typische Operationen: Create / Delete Container Write / Read / Delete BLOB-Object List BLOB-Objects Get / Set Metadata / Properties Spezielle Konzepte: Ergebnisbeschränkung & Next-Token Partielle Blob-Daten Seite 17 - OOP, München, Januar 2010

18 XML-Antwort <?xml version="1.0" encoding="utf-8"?> <ListBucketResult xmlns=" <Name>johnsmith</Name> <Prefix>photos/2009/</Prefix> <Marker/> <MaxKeys>10</MaxKeys> <Delimiter>/</Delimiter> <IsTruncated>false</IsTruncated> <Contents> <Key>photos/2009/index.html</Key> <LastModified> T12:00:00.000Z</LastModified> <ETag>"ce1acdafcc879d7eee54cf4e "</ETag> <Size>1234</Size> <Owner> <ID>214153b66967d86f031c7249d1d9a cd08f1cdc</ID> <DisplayName>John Smith</DisplayName> </Owner> <StorageClass>STANDARD</StorageClass> </Contents> <CommonPrefixes> <Prefix>photos/2009/January/</Prefix> </CommonPrefixes> </ListBucketResult> Seite 18 - OOP, München, Januar 2010

19 Java-Programmierung: JetS3t API /* Create a credentials object and service to access your S3 account */ AWSCredentials mycredentials = new AWSCredentials(myAccessKey, mysecretkey); S3Service myservice = new RestS3Service(myCredentials); /* Create new bucket uniquely named after a normalized directory path, */ String containername = directoryname.replace('\\','_').replace('/','_').replace(':', '_'); S3Bucket mycontainer = myservice.createbucket(myaccesskey + "." + containername); /* Add files from specified directory to bucket */ File directory = new File(directoryName); File[] files = directory.listfiles(); for (int i = 0; i < files.length; i++) { if (files[i].isfile()) { S3Object object = new S3Object(myContainer, files[i]); myservice.putobject(mycontainer, object); } } Seite 19 - OOP, München, Januar 2010

20 Cloud Storage Table Storage Speicherung von strukturierten Daten BigTable -Konzept (NoSQL): Tabelle : alle Operationen/Anfragen beziehen sich auf genau eine (riesige) Tabelle keine feste Struktur! keinerlei Beziehungen zwischen Tabellen Datensatz: Besteht aus Menge von Attributname/-wert-Paaren Datensatz wird mit angegebenen Attributen gespeichert Attribute und Datensätze haben eindeutige Namen Datentypen: diverse Einschränkungen, z.b. nur String bei Amazon Seite 20 - OOP, München, Januar 2010

21 Beispiel-Tabelle ID Category Subcat Name Color Size Make Model 01 Clothes Sweater Cathair Sweater 02 Clothes Pants Designer Jeans Siemese S, M, L Blue, Yellow, Pink 30x32,32x32 03 Car Parts Engine Turbos Audi S4 04 Motorcycle Parts Bodywork Fender Eliminator Blue Seite 21 - OOP, München, Januar 2010

22 Eigenschaften Zugriff auf Daten über REST und SOAP Nur einfache Queries (insb. kein Join!): Vergleiche =, >, >=, <, <=,!= AND, OR, NOT Reduzierte Lesekonsistenz Keine normalen Transaktionen REST-Beispiele: GET &DomainName=MyDomain &AWSAccessKeyId=<Access key ID> &Version= &Signature=<Signatur> &SignatureVersion=2 &SignatureMethod=HmacSHA256 &Timestamp= T15%3A01%3A28-07%3A00 GET $filter=(model%20eq% S4 )%20and%20(Color%20eq% Blue ) Seite 22 - OOP, München, Januar 2010

23 Table Storage vs. (On-Premise) Datenbankserver + Geringe Kosten für Setup und Pay-as-You-Go-Konzept: ideal für Start-ups + Verzicht auf Aufsetzen und Administration einer hochverfügbaren Cluster- Datenbank: zunehmend aufwändiger und kompliziert + Keine (komplexe) relationale Datenbank + Einfache Bereitstellung von Datenbankfunktionalität - Proprietäre Lösungen (vendor-lock-in) - Bescheidene Anfragesprache (kein Join => mehrere clientseitige Aufrufe) - Mitunter keine sofortige Sichtbarkeit von Änderungen auf Daten - Keine direkte Kontrolle über Datenbankserver: z.b. Indexe oder andere Optimierungen - Keine Stored Procedures, referenzielle Integrität etc. - Diverse Limitationen (z.b. Attributwertgröße limitiert auf 1024 Bytes & Datenbanken auf 10 GB in AWS) - Neuimplementierung bisheriger DB-basierter Lösungen - Schwere Testbarkeit, z.b. gegenüber lokalem Datenspeicher - XML-basiertes Protokoll verursacht unnötigen Overhead, Latenz und Kosten Seite 23 - OOP, München, Januar 2010

24 Cloud Storage Relationaler Datenbankserver Echter Datenbankserver in der Cloud: z.b. SQLServer (Microsoft Azure) oder MySQL (Amazon RDS) virtueller Datenbankserver zur eigenen Verwendung; mehrere Datenbanken automatische Replikation & Backup der Daten Ausfallsicherheit (nur bedingt!) Übliche API s statt REST-Protokoll Zugreifbar: Von Cloud-Applikationen Außerhalb der Cloud (z.b. über TDS-Protokoll) Spezielle URL: sqlcmd -S t17j2515ow.database.windows.net -U MyMasterUser@t17j2515ow -d MyDB Seite 24 - OOP, München, Januar 2010 generierter DB-Servername mysql -h myinstance.crwjauxgijdf.us-east-1.rds.amazonaws.com -P u MyMasterUser -p Problem: Drosselung ( throttling ) bei langen Operationen und Überlast

25 Produktauswahl Ein Auswahl prominenter Produkte und Hersteller <nur für internen Gebrauch > / Copyright Siemens AG Alle Rechte vorbehalten.

26 The Big Players Microsoft: Windows Azure Blobs, Tables und erst nicht dann doch SQL Azure Amazon Pioneer des Storage Services: S3, Simple DB, RDS CouchDB Ein Produkt, ein Open-Source-Projekt für Cloud Storages Google App Engine (GAE) Der Späteinsteiger Seite 26 - OOP, München, Januar 2010

27 Microsoft Windows Azure Quelle: Microsoft Corp Seite 27 - OOP, München, Januar 2010

28 Microsoft Windows Azure Storage Services im Windows Azure SDK: Blob Service: für große Datenvolumina Table Service: für strukturierte Daten Queue Service: (asynchroner) Datenaustausch SQL Services: SQL Azure: SQLServer in der Cloud (früher SQL Data Services oder SQL Server Data Services) Huron Data Hub (auf SQL Azure und Microsoft Sync Framework aufbauend; Synchronisation verschiedener On-Premise-Datenbankserver mit spezifizierbaren Konfliktlösungstrategien) Weitere in Arbeit: Reporting, Data Analytics etc. Seite 28 - OOP, München, Januar 2010

29 Windows Azure Services Developer Portal Seite 29 - OOP, München, Januar 2010

30 Windows Azure SDK Typen: BLOB, Table, Queue URI: Account: Repräsentiert durch DNS-Name: wird als IP-Adresse aufgelöst, die auf ein spezielles Data Center verweist Account ist Geo-Location-Einheit Wird beim Anlegen zugewiesen :10000 als DNS zum Entwicklungszeitpunkt Seite 30 - OOP, München, Januar 2010

31 BLOB Service Speichert Text- und Binärdaten: Block-Blobs: optimiert für Streaming Page-Blobs: optimiert für Read/Write-Operationen auf Teile Terminologie: Account: Namespace, global eindeutig Container: keine Schachtelung Blob: Inhalt, Eigenschaften, Metadaten; virtuelle Verzeichnishierarchie Spezielle Konzepte: Filterung: GET Snapshot: Read-only-Version eines Blobs zu einem Zeitpunkt, adressierbar über?snapshot=<zeitmarke> Restriktionen: Timeout = 30 Sekunden für BLOB-Operationen (setzbar) GET Blob 2 Minuten pro MB PUT Blob 10 Minuten pro MB Seite 31 - OOP, München, Januar 2010

32 Table Service Terminologie: Account: Namespace, Grundlage für Authentifizierung Table: Tabelle Entity: hat Primärschlüssel (RowKey < 1 KB) und bis zu 255 Key-Value-Paare; Begrenzung auf 1 MB in Summe Vordefinierte Eigenschaften: PartitionKey, RowKey, Timestamp Datentypen: byte[], bool, DateTime, double, Guid, Int32, Int64, String Adressierung: MyTable )?$filter=(rating%20ge%203)%20and%20(rating%20le%206) Ergebnis ist sortiert nach PartitionKey, RowKey (keine benutzerdefinierte Sortierung) Restriktion: Query-Ergebnis: max Sätze, 5 Sekunden Berechnungszeit (andernfalls NextToken) Seite 32 - OOP, München, Januar 2010

33 Microsoft SQL Azure Datenbankserver in der Cloud, genauer in Microsoft Data Centers Windows Azure Plattform-Kennung zur Nutzung aller Azure-Funktionalitäten: Grundlage für Abrechnung aller Service-Nutzungen Je Azure-Kennung mit Login: mehrere SQL Azure Server (nicht alle als SQLServer-Instanz implementiert) jeder Server hat eine Master-Datenbank (wie beim SQLServer) wenig Unterschiede ggü. SQLServer Erzeugung und Management über SQL Azure Portal Je SQL Azure-Server: mehrere Datenbanken; anlegbar mit CREATE DATABASE oder über SQL Azure Portal SQL Azure baut auf SQLServer-Technologie auf: Relationales Datenmodell: Tabellen, Stored Procedures etc. Vertrautheit: kein Erlernen neuer Tools, Programmier-Plattformen und Datenmodelle TDS-Netzwerkprotokoll (ADO.NET, ODBC, JDBC etc.) Security-Prinzipien wie beim SQLServer: SQLServer-Logins, Rollen und Datenbankbenutzer für Tabellenzugriffe Benutzung von On-Premise Software wie Management Studio und Reporting Services Seite 33 - OOP, München, Januar 2010

34 Microsoft SQL Azure Keine Administration wie Monitoring und Dimensionierung der Platten bzw. Log-Dateien erforderlich Hochverfügbarkeit, Zuverlässigkeit und Sicherheit Automatisches Failover und Lastbalancierung: Daten werden über mehrere physikalische Server verteilt innerhalb derselben Geo-Location Verbesserte Performanz durch Geo-Location (über Portal wählbar) auf SQLServer-Ebene Synchronisation von Applikationen und Client-Devices über gemeinsamen Data Hub Einfaches Erzeugen, Prototyping und Deployment von Applikationen, die Daten integrieren Restriktion der Datenbank-Größe auf derzeit 1 10 GB (beim Anlegen) Seite 34 - OOP, München, Januar 2010

35 Microsoft SQL Azure Nutzung Quelle: Microsoft Corp Seite 35 - OOP, München, Januar 2010

36 Amazon Web Services (AWS) Amazon Web Services (AWS): Bezahlbares, hoch-performantes, skalierbares Netzwerk von Applikationen, für Jedermann mit Amazon.com Kennung zugreifbar Sofortige Infrastruktur zum Erstellen neuer Webapplikationen für Jedermann Zugreifbar über das Internet (SOAP, REST) Libraries für verschiedene Programmiersprachen Produktpalette mit Services: Elastic Compute Cloud (EC2) => infrastrukturelles Angebot an Rechenkapazität Simple Storage Service (S3) => Datenspeicher (BLOB), hohe Bandbreite SimpleDB => verteiltes Datenbanksystem Relational DB Service (RDS) => MySQL Datenbank Simple Queue Service (SQS) => MoM, Austausch 1000 Nachrichten pro Min Seite 36 - OOP, München, Januar 2010

37 APIs und Authentifizierung Zur Nutzung eines AWS Web Service: AWS-Kennung (auch Bestehende) Über zu beziehen Auch Benutzungsberichte und Zugriffsdaten darüber abfragbar AWS erzeugt erzeugt zwei Schlüssel: Einen 20-Zeichen, alphanumerischen Access Key ID Einen 40-Zeichen Secret Access Key Normalerweise Programmiersprachen-spezifische Library (z.b. für Java) Kein Aufwand mit Signaturen, Zertifikaten, Signierung etc. Seite 37 - OOP, München, Januar 2010

38 Amazon S3 BLOB Storage On demand Speicher für das Internet ( persönliche Festplatte ) 2006 in USA (und EU) vorgestellt Terminologie: Bucket = Container (bis zu 100 je Kennung) Object = Objektdaten (Datei) + Metadaten (Attribut/Wert) + HTTP-Metadaten Unbegrenzte Anzahl Objekte, bis zu 5 GB Größe Adressierung: Schlüssel: lokal eindeutig innerhalb Bucket Z.B. Zugriff: SOAP 1.1, REST, APIs für Java, C#, Perl, PHP, Python, Ruby Seite 38 - OOP, München, Januar 2010

39 Spezielle Konzepte Konkurrierende Zugriffe: Änderungen werden aufgrund einer internen Replikation nicht sofort sichtbar Atomare Schreib-/Leseoperation Keine Sperren: der letzte Schreiber gewinnt Kostenreduktion durch: POST Upload (Inhalt wird direkt an S3 geleitet, kein Umweg über Web Server) Requester Pay: Download-Kosten beim Aufrufer (auch: Kopplung zum Amazon DevPay-Bezahlmechanismus) Amazon Import/Export: Service zum schnellen Upload von Tera-Bytes Chunked Downloads Geographical Region Zugriffskontrolle über Access Control Policy (ACP) für Bucket oder Objekt: Grantee (Owner, User by , User by Canonical Representation, AWS User Group, Anonymous Group) Permission (READ, WRITE, READ_ACP, WRITE_ACP, FULL_CONTROL) Seite 39 - OOP, München, Januar 2010

40 Amazon SimpleDB Table Storage Eigenschaften: Datenbank in der Cloud 80% der Anforderungen an Datenbanken abdecken Einfachheit: einfacher, zugeschnittener Zugriff ohne Schnick-Schnack Flexibilität: kein vordefiniertes DB-Schema, automatische Indexierung Skalierbarkeit mit Datenvolumen Hochverfügbarkeit: Verwaltung in Amazon s Hochverfügbarkeitszentren Kosteneffizienz: Bezahlung nach aktuellem Verbrauch Optimierung für Betrieb mit S3 und EC2: innerhalb AWS anfallender Verkehr wird nicht gezählt APIs: REST (HTTP(S)) & SOAP mit/ohne WS Security (nur HTTPS) Amazon SimpleDB is not a database! [N. Shalom] Seite 40 - OOP, München, Januar 2010

41 Amazon SimpleDB Domäne (Domain): Entspricht im Wesentlichen einer Tabelle ohne feste Struktur Bis zu 100 Domänen möglich je Benutzer, 10 GB je Domain Keinerlei Beziehungen zwischen Domänen Alle Operationen/Anfragen beziehen sich auf genau eine Domäne Item: Entspricht Datensatz in Tabelle Besteht aus Menge von Attributname-/Wert-Paaren Item wird mit angegebenen Attributen gespeichert Attribut: kann mengenwertig sein, z.b. Color = { blue, red } 256 Attribute pro Item Attributwert < 1024 Bytes 1 Milliarde Attribute pro Domäne Attribute und Items haben eindeutige Namen Typen: nur String (lexikographische Ordnung)! Seite 41 - OOP, München, Januar 2010

42 Amazon RDS Cloud-Datenbankserver Amazon Relational Database Service (Amazon RDS): Einfacher Setup, Betrieb und Skalierung einer relationalen Datenbank (MySQL 5.1) in der Cloud Liefert kosten-effiziente, erweiterbare relationale Datenbank (Industriestandard) Übernimmt Management allgemeiner Datenbankadministrationsaufgaben Code, Applikationen und Werkzeuge funktionieren wie mit existierender MySQL-Datenbank ohne Modifikationen Zu Beachten: Wöchentliches 4-stündiges Wartungsintervall (evtl. Mit Down-Zeit) Vorab-Festlegung der Datenbankgröße und Instanzklasse Kein Verkleinern der Datenbank; nur 10% Vergrößerung Abfragen von DB-Metriken Anlegen einer Datenbank: rds-create-db-instance myinstance s 50 c db.m1.large - backup -retention-period 3 u super p pw - preferred-maintenance-window Tue:00:30-Tue:04:30 Seite 42 - OOP, München, Januar 2010

43 Eigenschaften Zuverlässigkeit: Amazon RDS läuft auf derselben hoch-zuverlässigen Infrastruktur wie andere Amazon Web Services Hochverfügbarkeit erst später! Automatischer Backup-Service: Zurücksetzen auf beliebigen Zeitpunkt (innerhalb spezifizierbarer Aufbewahrungsperiode) Bestandteil der AWS-Produktfamilie: Integration mit anderen Produkten Geringe Latenzzeit für Zugriff aus Amazon EC2 Sicherheit: Konfigurierbare Firewall Seite 43 - OOP, München, Januar 2010

44 CloudDB Relax! Dokumenten-Speicher Dokument = Inhalt + Metadaten Dokumenten-orientierte" Datenbank Nutzt JavaScript Object Notation (JSON) Strukturiert Daten in B-Trees Wird bereits benutzt in Ubutu 9.10, integriert in Productivity Apps 'ubuntu one' Cloudant SaaS Provider Content Management System (CMS) beim BBC CMS für einige Websites (z.b. Facebook Anwendungen) CAP Theorem trade-off zw. Konsistenz, Verfügbarkeit und Partitionierung CouchDB fokussiert auf Verfügbarkeit und Partitionierung Stellt nicht sicher, dass überall gleiche Sicht vorhanden ist Stattdessen: Mögliche Konsistenz", warten auf Agreements ausgelassen Kann für bestimmte Anwendungen von Vorteil sein Seite 44 - OOP, München, Januar 2010

45 CouchDB - Datenverarbeitung Nebenläufigkeit ohne Sperren, optimistischer Ansatz Multi-Version Concurrency Control (MVCC) Änderungen erzeugen neue Version, zwischenzeitliche Lesezugriffe erhalten alte Version Nebenläufige Änderungen führen zum Konflikt bei der später sichernden Partei Eigene Verfahren zur Konfliktbewältigung möglich Schreiboperationen werden versucht, konsistent zu halten Änderungen als Sequenz von Schreiboperationen Im Falle eines Fehlers geht eine Reihe von Änderungen verloren Zweistufiger Schreibprozess (auf Festplatte): Header und Schreiben der Daten jeweils atomar Seite 45 - OOP, München, Januar 2010

46 CouchDB - Datenorganisation Konzept von Sichten Eine Sicht definiert eine Menge von Dokumenten aus der DB Definition einer Sicht wird ebenfalls in DB gespeichert Eine Sicht ist eine Funktion, die auf ein Dokument angewendet wird Performanzproblem: kontinuierlich gepflegter Index Eine Sicht kann sehr schnell abgerufen werden, die Aktualisierung benötigt u.u. etwas länger Replizierung zwischen verschiedenen CouchDB Servern möglich Durch das anknüpfende Schreiben von Aktualisierungen leicht koordinierbar Priorität ist ein non-destructive resolve Selbst modifizierbares Verfahren entscheidet im Konfliktfall Andere(s) bleiben in CouchDB, werden nur nicht als aktuelles markiert Seite 46 - OOP, München, Januar 2010

47 Google Chrome / Google App Engine Google s Plattform für Anwendungen Small Business, Hobby und vielleicht Enterprise Starke Limits (zurzeit geplant) 1MB Limit für jede Datenstruktur 1GB Datenbank maximal 30 Sek. Dauer zur Bearbeitung einer Anfrage maximal 1000 Einträge pro Abfrage Überlastschutz für Rechenzeit und Anzahl der Anfragen Zwei Datenspeicher: BigTable und MemCache MemCache: einfacher Datenspeicher für schnellen Zugriff Temporärer Speicher BigTable: Non-relationaler Tabellenspeicher Dateisystem nur Lesezugriff Seite 47 - OOP, München, Januar 2010

48 BigTable Non-Relational? Zugriff unter Java: Kein Schema Definition über Klassen Java: JDO oder JPA / DataNucleus Access Plattform Hauptproblem: Verteilung von Tabellen vs. Performanz Lösung: Verteilung weglassen GQL (statt JPQL) Einfache WHERE Statements, keine Konjunktionen keine JOIN Statements Seite 48 - OOP, München, Januar 2010

49 Allgemeine Aspekte Kostenmodelle und Migration <nur für internen Gebrauch > / Copyright Siemens AG Alle Rechte vorbehalten.

50 Kostenmodell Pay-as-You-Go-Modell Keine Fixkosten Nur aktueller Verbrauch ( per use ) Bezahlung nach Speicherplatzbelegung in der Cloud Ein-/ausgehender Datentransfer (XML!) CPU-Benutzung oder Anzahl Requests DB-Konfiguration Seite 50 - OOP, München, Januar 2010

51 Kostenmodell: Amazon S3 BLOB Storage Speicherbelegung (Europa): $ 0.18 per GB für die ersten 50 TB / Monat (=> $ 180 für ein TB!) $ 0.17 per GB für die nächsten 50 TB / Monat $ 0.16 per GB für die nächsten 400 TB / Monat $ 0.15 per GB über 500 TB eingehender Datentransfer: $ 0.10 per GB ausgehender Datentransfer: $ 0.17 per GB für die ersten 10 TB / Monat $ 0.13 per GB für die nächsten 40 TB / Monat $ 0.11 per GB für die nächsten 100 TB / Monat $ 0.10 per GB über 150 TB / Monat Anzahl Requests: $ pro 1,000 PUT, COPY, POST, or LIST Requests $ pro 10,000 GET und alle anderen Requests; keine Kosten für delete Seite 51 - OOP, München, Januar 2010

52 Kostenmodell: Amazon SimpleDB Speicherbelegung: 1 GB frei $ 0.25 pro GB-Monat SimpleDB misst Größe der Daten: Raw Bytes des Uploads + 45 Bytes Overhead für jedes Item, Attributname und Attribut-Wert-Paar CPU-Benutzung: 25 SimpleDB Maschinenstunden pro Monat frei $ 0.14 pro nachfolgender verbrauchter SimpleDB Maschinenstunde Jede Operation liefert CPU-Verbrauch Datentransfer: 1 GB pro Monat frei für ein/ausgehenden Datentransfer $ 0.10 pro GB eingehenden Datentransfer danach Für ausgehenden Datentransfer: $ 0.17 pro GB für die ersten 10 TB (danach günstiger) Seite 52 - OOP, München, Januar 2010

53 Kostenmodell: Amazon RDS DB-Konfiguration: (anzugeben beim Anlegen der DB) Small $ 0.11 (jeweils pro Stunde) Large $ 0.44 Extra Large $ 0.88 Double Extra Large $ 1.55 Quadruple Extra Large $ 3.10 Speicherbelegung: (von 5 GB bis zu 1 TB, anzugeben beim Anlegen der DB) $ 0.10 pro GB-Monat $ 0.10 je 1 Million I/O-Requests kein Schrumpfen! Backup-Speicherung: automatische Backups & nutzerinitiierte DB-Snapshots; festlegbarer Aufbewahrungszeitraum Frei bis zu 100% der provisionierten Speicherbelegung $ 0.15 pro weiteren GB-Monat (auch nach Ende des Datenbankserver-Betriebs) Datentransfer: eingehend: $ 0.10 pro GB ausgehend: $ 0.17 pro GB, ab 10 TB günstiger Seite 53 - OOP, München, Januar 2010

54 Migration -- Klärungsbedarf Grundsätzlich muss das Preismodell überprüft werden Wird die Migration zu finanziellen Einsparungen führen? Limitationen können auf Grund des Preismodells interessant werden Z.B. Preissprung bei 1GB Datenbankgröße Es muss beachtet werden, dass On-Premise Lösungen zusätzlichen Synchronisationsaufwand erzeugen (=> zusätzlicher Verkehr) Die Anwendung muss für Multi-Instance Betrieb ausgelegt sein SLA muss überprüft werden Wie werden Wartungsarbeiten umgesetzt? Backup? Spezielle Ausrichtungen bei Geo Location können wichtig sein Es bringt Vorteile bei einer Datenbank-Familie zu bleiben Z.B. Microsoft SQL Server nach SQL Azure (basierend auf SQL Server) oder MySQL nach Amazon RDS BigTable-Ansatz eher geeignet für Neuentwicklung von Anwendungen? Seite 54 - OOP, München, Januar 2010

55 Technische Besonderheiten Cloud Computing ist (noch) ein dynamisches Feld, ständige Änderungen an den APIs und den Limitierungen Im Projekt sind mehrere API-Änderungen möglich Zum Beispiel: Microsoft, Google App Engine: Gleiche Toollandschaft Gute Integration in Visual Studio bzw. Eclipse oder Ant Keine Kontrolle über Hard- und Software Kein Aufruf von Betriebssystemfunktionen, bei GAE z.b. keine Threads möglich Sicherheitsbedenken beim Transfer zwischen Provider Cloud und On-Premise Clouds Wie werden die Daten auch bei Übertragung geschützt Hohe Latenz möglich In SF Bay Area 6 msec to GAE, aber in München? Cloud Storage Lösungen haben andere Datentypen => Verlust von primitiven Typen möglich Seite 55 - OOP, München, Januar 2010

56 Zum Mitnehmen <nur für internen Gebrauch > / Copyright Siemens AG Alle Rechte vorbehalten.