OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für die Cloud
•Descargar como PPTX, PDF•
3 recomendaciones•2,042 vistas
Präsentation von der OOP 2014
Recomendados
Recomendados
Más contenido relacionado
Destacado
Destacado (20)
Similar a OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für die Cloud
Similar a OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für die Cloud (20)
Más de AWS Germany
Más de AWS Germany (20)
OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für die Cloud
- 1. SQL oder NoSQL die Auswahl der richtigen Datenbankplattform für die Cloud Steffen Krause Technical Evangelist @sk_bln skrause@amazon.de
- 2. Das richtige Werkzeug Wenn man nur einen Hammer hat sieht jedes Problem wie ein Nagel aus
- 5. Ihr Stack Load Balancer Application Tier Database tier
- 6. Ihr Stack der Sorgen Load balancer Sicherheit, Skalierung, Verfügbarkeit… Application tier Sicherheit, Innovation, Skalierung, Performance, Verfügbarkeit… Database tier Sicherheit, Innovation, Skalierung, Transaktionen, Performance, Persistenz, Verfügbarkeit, Kenntnisse..
- 7. Spektrum der Optionen SQL Do-it yourself NoSQL Vollständig verwaltet
- 8. Wo ist das Problem? CAP Theorem
- 9. CAP Theorem Consistency Availability Partition Tolerance Wähle 2 beliebige aus*
- 10. OL(T?)P
- 13. Transaktionen Konto A Kontoauszug A Konto B Kontoauszug B Image Credit: http://www.taxfix.co.uk/
- 15. Komplexes Schema
- 16. Flexibler, standardisierter Zugriff ETL APP A APP C APP B
- 17. Point in Time Recovery Restore hier Mo Mi Di Fr Do So Sa Di Mo Do Mi Sa Fr Mo So
- 18. Demo: Point in Time Recovery http://youtu.be/yL6m2lEK5Dc
- 19. Skalierung Vertikale Skalierung – RAM, CPU usw.
- 20. IOPS
- 21. Optionen - Relational Do-it Yourself Jede relationale x64/x86 Datenbank die Sie wollen Oracle SQL Server MySQL Postgres MariaDB DB2 Sybase … Vollständig verwaltet Relational Database Service (RDS)
- 23. Best Practices: RDBMS auf AWS • Verwenden Sie mehrere Availability Zones – RDS bietet MultiAZ für Oracle, PostgreSQL und MySQL • Verwenden Sie Provisioned IOPs – Bis zu 30000 für RDS – Bis zu 4000 für EBS Volumes • Striping (RAID 0) möglich für mehr • Backup nach S3 – Verwendung von DB Snapshots oder EBS Snapshots oder direktes S3 Backup wenn unterstützt (z.B. Oracle RMAN) • Verwenden Sie geeignete Instanztypen -> m3, c3, m2 • Skalierung hoch/runter innerhalb von 5-20 Minuten durch Änderung des Instanztyps
- 26. Flexibles Schema 2 Wochen später
- 27. Niedrige Latenz
- 28. NoSQL BA •Basically Available S •Soft state E •Eventually consistent * Aber einige NoSQL Datenbanken bieten voll transaktionale Schreiboperationen
- 29. Scaling Horizontales Scaling – RAM, CPU usw.
- 30. Typen von NoSQL Datenbanken Stark vereinfacht, ohne Memory Caches & Analytische Datenbanken Schlüssel Wert Schlüssel Spalte Spalte Spalte Schlüssel Wert Schlüssel Spalte Spalte Spalte z.B. Riak z.B. DynamoDB, Cassandra Schlüssel { “document” : “JSON” } Schlüssel { “document” : “JSON” } z.B. MongoDB, ClouchDB Node Node Node Node Node z.B. Neo4j + diverse andere Typen
- 31. NoSQL Datenbanken auf AWS • Whitepaper dokumentieren NoSQL Datenbanken auf AWS – http://aws.amazon.com/whitepapers – Couchbase on AWS – Riak on AWS – MongoDB on AWS • Für persistente Datenbanken: Cluster aus Hoch-IOPS Instanzen – I2 Instanzen haben bis zu 350000 Write-IOPs – Instance Store Disks, wenn Cluster redundant ist
- 32. NoSQL Datenbank DynamoDB NoSQL Datenbank mit provisioniertem Durchsatz Hohe, vorhersagbare Performance Vollständig verteilte, fehlertolerante Architektur Feature Details Provisionierter Durchsatz Deployment & Administration Storage Vorhersagbare Performance Durchschnittliche Latenz im einstelligen Millisekunden-Bereich durch SSDs Starke Konsistenz App Services Compute Lese/Schreibdurchsatz einfach nach Bedarf erhöhen und vermindern Fehlertolerant Database Monitoring Sicher Networking Elastic MapReduce AWS Global Infrastructure Sicheres Lesen der aktuellsten Werte Daten repliziert über mehrere Availability Zones Integration mit CloudWatch Integration mit AWS Identity and Access Management (IAM) Integration mit Elastic MapReduce (Hadoop) für komplexe Analysen oder große Datenmengen
- 33. Demo: Flexibles Schema & NoSQL Performance http://bit.ly/LKBfVO
- 34. Data Warehousing Reporting & Analytics
- 35. Komplexes Schema
- 36. Komplexes Schema OK, hatten wir schon: Relational (RDS oder EC2) Wenn die Datenmenge nicht zu groß ist
- 37. Spaltenbasierte Datenbanken Image credit: http://www.flickr.com/photos/aakanayev/9489895437/
- 39. Verteiltes Data Warehouse JDBC/ODBC 10 GigE (HPC) Ingestion Backup Restore
- 40. Amazon Redshift Redshift Schnelle und performante Analyse großer Datenmengen 1/10 der Kosten eines traditionellen Data Warehouse Automatisches Deployment & Administration Feature Skalierung Deployment & Administration Niedrige Kosten Columnstore App Services Fehlertolerant Compute Storage Database Vollständig verwaltet Networking AWS Global Infrastructure Sicher Kompatibel Details Skaliert von Terabytes bis Petabytes Preise ab US$999/TB/Jahr Spaltenweise Speicherung optimiert für DWH Workloads Automatische Ersetzung von Nodes & Disks, Automatisches Backup nach S3 Automatisches OS & Software Patching Redshift Daten können verschlüsselt werden Kompatibel mit populären BI Tools über ODBC und JDBC Treiber
- 42. Nett, aber... Geht das nicht schneller?
- 44. In Memory cr1.8xlarge und i2.8xlarge haben 244 GB RAM! Image Copyright by StuSeeger http://www.flickr.com/photos/stuseeger/
- 45. 2*2 Arten Nur In Memory z.B. Columnstore Rowstore Hybrid mit On-disk z.B.
- 47. Elastic MapReduce Halt, was ist mit Hadoop? • Viele Kunden verwenden Hadoop für DWH-artige Workloads – Weil das lange Zeit die einzige skalierbare, kostengünstige Möglichkeit war – In vielen Fällen ist ein relationaler DWH-Dienst für DWH Workloads schneller und preiswerter • Hadoop/EMR ist erste Wahl für komplexe Berechnungen auf großen Datenmengen – Auch für explorative oder ETL-artige Jobs
- 48. Sind wir jetzt fertig?
- 49. Es muss nicht immer eine Datenbank sein…
- 50. Storage Strukturiert – Komplexe Abfragen • SQL – Amazon RDS (MySQL, Oracle, SQL Server, PostgreSQL) • Data Warehouse – Amazon Redshift Strukturiert – Einfache Abfragen • NoSQL – Amazon DynamoDB • Cache – Amazon ElastiCache (Memcached, Redis) • Search – Amazon CloudSearch Unstrukturiert – Eigene Abfragen • Hadoop/HDFS – Amazon Elastic MapReduce (EMR) Unstrukturiert – keine Abfragen • Cloud Storage – Amazon S3 – Amazon Glacier
- 52. ElastiCache Amazon DynamoDB Amazon RDS Cloud Search Amazon Redshift Amazon EMR (Hive) Mittlere Latenz ms ms ms,sec ms,sec sec,min sec,min,h ms,sec,min rs (~ Größe) hrs Datenmenge GB GB–TBs (unbegrenzt) GB–TB (3 TB Max) GB–TB TB–PB (1.6 PB max) GB–PB (~nodes) GB–PB (unbegrenzt) GB–PB (unbegrenzt) KB (64 KB max) KB (~ Zeilengröße) KB (1 MB max) KB (64 K max) KB-MB KB-GB (5 TB max) GB (40 TB max) Hoch Hoch Niedrig Niedrig Niedrig– Sehr Hoch (unbegrenzt) Sehr Niedrig (unbegrenzt) Elementgröße B-KB Abfragerate Sehr Hoch Sehr Hoch Amazon S3 Amazon Glacier Kosten $$ ($/GB/Monat) ¢¢ ¢¢ $ ¢ ¢ ¢ ¢ Dauerhaftigkeit Sehr Hoch Hoch Hoch Hoch Hoch Sehr Hoch Sehr Hoch Niedrig Mittel
- 53. Beispiel-Datenarchitektur Join via Facebook Add a Skill Page Web Servers + MS SQL Server in RDS Raw Data Amazon S3 User Action Trace Events Invite Friends Get Data Aggregated Data Amazon Redshift Amazon S3 Raw Events EMR • Tableau Excel • • Data Analyst Internal Web Hive Scripts Process Content Process log files with regular expressions to parse out the info we need. Processes cookies into useful searchable data such as Session, UserId, API Security token. Filters surplus info like internal varnish logging.
- 54. Zusammenfassung • Wählen Sie das richtige Werkzeug für die Aufgabe • Ihre Wahl: Relational oder NoSQL – Verwenden Sie RDS für Prototyping und hochwertige Daten – Verwenden Sie Amazon DynamoDB für hochperformante, persistente, kostengünstige Speicherung – Verwenden Sie Redshift für skalierbares, kostengünstiges Data Warehousing • Ihre Wahl: Do-it-yourself oder voll verwaltet – Verwaltete Dienste ermöglichen Ihnen den Fokus auf die eigentliche Aufgabe
- 55. Ressourcen • http://aws.amazon.com/de • Getting started with Free Tier: http://aws.amazon.com/de/free/ • 25 US$ credits für neue Kunden: http://aws.amazon.com/de/campaigns/account/ • Twitter: @AWS_Aktuell • Facebook: http://www.facebook.com/awsaktuell • Webinare: http://aws.amazon.com/de/about-aws/events/ • Slides: http://de.slideshare.net/AWSAktuell • Diese Präsentation: http://bit.ly/OOP2014Krause
- 56. WE ARE HIRING! • Amazon Web Services wächst in Deutschland • Wir suchen technische Sales – Consultants Entwickler (m/w) in: – Berlin – München • Wir suchen Software – Entwickler (m/w) in: – Dresden – Berlin • Bewerben Sie sich noch heute und wachsen Sie mit uns! http://aws.amazon.com/de/careers/
Notas del editor
- Konsistenz (C): Alle Knoten sehen zur selben Zeit dieselben Daten. Diese Konsistenz sollte nicht verwechselt werden mit der Konsistenz aus der ACID-Transaktionen, die nur die innere Konsistenz eines Datenbestandes betrifft.Verfügbarkeit (A): Alle Anfragen an das System werden stets beantwortet.Partitionstoleranz (P): Das System arbeitet auch bei Verlust von Nachrichten, einzelner Netzknoten oder Partition des Netzes weiter.Quelle: http://de.wikipedia.org/wiki/CAP-Theorem
- http://de.wikipedia.org/wiki/ACID Atomarität (Abgeschlossenheit)Von einer atomaren Operation spricht man, wenn eine Sequenz von Daten-Operationen entweder ganz oder gar nicht ausgeführt wird (Alles-oder-nichts-Eigenschaft).[2] Dies wird üblicherweise durch Verwendung von Transaktionen erreicht. Das DBMS verhält sich dabei gegenüber dem Benutzer so, als ob die Transaktion eine einzelne elementare Operation wäre, die nicht von anderen Operationen unterbrochen werden kann. Praktisch werden die einzelnen Datenbankanweisungen, aus denen sich die Transaktion zusammensetzt, natürlich nacheinander ausgeführt, aber global erst dann „für gültig erklärt und in Kraft gesetzt“, wenn sie erfolgreich vollständig abgeschlossen sind. Sollte sich jedoch während der Transaktion herausstellen, dass diese nicht vollständig abgeschlossen werden kann, wird der ursprüngliche Bereich als gültig erklärt und ein Rollback durchgeführt, d. h. alle bisherig ausgeführten Anweisungen wieder rückgängig gemacht, sofern notwendig - oder einfach der zwischenzeitlich für die Änderungen genutzte Speicherbereich wieder freigegeben und die Gültigkeit beim bisherigen belassen.KonsistenzerhaltungKonsistenz heißt, dass eine Sequenz von Daten-Operationen nach Beendigung einen konsistenten Datenzustand hinterlässt, falls die Datenbank davor auch konsistent war. Dies wird durch Normalisierung des Datenbestands, sowie explizit definierte Integritätsbedingungen, insbesondere von Schlüssel- und Fremdschlüsselbedingungen, erreicht.Das Konsistenz-Kriterium bezieht sich vor allem auf die inhaltliche und referentielle Integrität eines Datenbestandes, die vor und nach einer Sequenz von Daten-Operationen gewährleistet bleiben muss. Während die Wahrung der inhaltlichen Integrität hauptsächlich von den verwendeten Datenbank-Operationen abhängt, lässt sich die referentielle Integrität automatisch gewährleisten, solange alle Redundanzen im Datenbestand automatisiert gehandhabt werden.Die Normalisierung eines Datenbestands hat zum Ziel, dass dort alle Redundanzen außer durch Primärschlüssel und Fremdschlüssel vermieden werden. Letztere Art von Redundanz ist unvermeidlich, da sie zur Definition von Relationen benötigt wird. Alle nach der Normalisierung übrig bleibenden Redundanzen (Fremdschlüssel, absichtlich erhaltene Redundanzen, usw.) müssen dann durch Integritätsbedingungen so gehandhabt werden, dass die referentielle Integrität bei allen möglichen Daten-Operationen gewahrt bleibt.Isolation (Abgrenzung)Durch das Prinzip der Isolation wird verhindert/eingeschränkt, dass sich nebenläufig in Ausführung befindliche Daten-Operationen gegenseitig beeinflussen. Realisiert wird dies üblicherweise durch Anwendung von Transaktionen bei gemischten Lese- und Schreib-Sequenzen, sowie insbesondere auch bei reinen Lesesequenzen. Der transaktionale Isolationsgrad definiert dabei die erlaubte Art der Beeinflussung, verbreitete Einstellungen sind dabei READ COMMITTED, REPEATABLE READ sowie SERIALIZABLE.Dauerhaftigkeit[Der Begriff Dauerhaftigkeit sagt aus, dass Daten nach dem erfolgreichen Abschluss einer Transaktion garantiert dauerhaft in der Datenbank gespeichert sind. Die dauerhafte Speicherung der Daten muss auch nach einem Systemfehler (Software-Fehler oder Hardware-Ausfall) garantiert sein. Insbesondere darf es nach einem Ausfall des Hauptspeichers nicht zu Datenverlusten kommen. Dauerhaftigkeit kann durch das Schreiben eines Transaktionslogs sichergestellt werden. Ein Transaktionslog erlaubt es, nach einem Systemausfall alle in der Datenbank fehlenden Schreib-Operationen zu reproduzieren.