Das Back to Basics – Webinar 1: Einführung in NoSQL
•Als PPTX, PDF herunterladen•
0 gefällt mir•1,562 views
Im ersten Webinar unserer Back to Basics-Reihe sprach Benjamin Lorenz, Senior Solutions Architect bei MongoDB über folgende Themen: > Die Hintergründe von NoSQL > Die Gründe für die Nachfrage nach NoSQL-Datenbanken > Die Unterschiede zwischen NoSQL- und herkömmlichen SQL-Datenbanken
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (10)
Ähnlich wie Das Back to Basics – Webinar 1: Einführung in NoSQL
Ähnlich wie Das Back to Basics – Webinar 1: Einführung in NoSQL (20)
Mehr von MongoDB
Mehr von MongoDB (20)
Das Back to Basics – Webinar 1: Einführung in NoSQL
- 2. Back to Basics 2016 : Webinar 1 Einführung in NoSQL Benjamin Lorenz Senior Solutions Architect MongoDB Frankfurt
- 4. 4 Kursplan Datum Uhrzeit Webinar 31. Mai 2016 14:00 CEST Einführung in NoSQL 16. Juni 2016 14:00 CEST Ihre erste MongoDB-Anwendung 1. Juli 2016 14:00 CEST Schema-Design – Denken in Dokumenten 12. Juli 2016 14:00 CEST Fortschrittliche Indizierung, Text- und Geoindizes 26. Juli 2016 14:00 CEST Einführung in das Aggregation-Framework 30. August 2016 14:00 CEST Produktivsetzung einer Anwendung
- 5. 5 Ablauf heute • Warum NoSQL • Unterschiedliche Typen von NoSQL-Datenbanken • MongoDB: Detaillierte Übersicht • MongoDB Dauerhaftigkeit (durability) – Replica Sets • MongoDB Skalierbarkeit – Sharding • Fragen & Antworten
- 6. 6 Relationale Datenbanken Expressive Abfragesprache & sekundäre Indizes Strenge Konsistenz Enterprise-Management & Integration
- 7. 7 Die Welt hat sich verändert Daten Risiken Zeit Kosten
- 8. 8 NoSQL Skalierbarkeit & Leistung Immer lauffähig, Globale Bereitstellung FlexibilitätExpressive Abfragesprache & sekundäre Indizes Strenge Konsistenz Enterprise-Management & Integration
- 9. 9 Nexus-Architektur Skalierbarkeit & Leistung Immer lauffähig, Globale Bereitstellung FlexibilitätExpressive Abfragesprache & sekundäre Indizes Strenge Konsistenz Enterprise-Management & Integration
- 10. 10 Typen von NoSQL-Datenbanken • Key/Value-Datenbanken • Spaltenorientierte Datenbanken • Graphdatenbanken • Multi-Model-Datenbanken • Dokumentenorientierte Datenbanken
- 11. 11 Key/Value-Datenbanken • Assoziatives Array • Extrem schnelles Single-Key-Lookup • Nicht so gut geeignet für Rückwärtssuche Key Value 12345 4567.3456787 12346 { addr1 : “The Grange”, addr2: “Dublin” } 12347 “top secret password” 12358 “Shopping basket value : 24560” 12787 12345
- 12. 12 Erinnerung: Zeilenorientierte Datenbanken (RDBMS) • Speichern Daten in Zeilen ab (traditionelles RDBMS, z.B. MySQL) • Bei Abfragen wird jedes Mal eine vollständige Zeile gelesen • Auslesen von nur ein oder zwei Spalten verschwendet Ressourcen ID Name Gehalt Start-Datum 1 Joe D 24.000 € 1. Jun 1970 2 Peter J 28.000 € 1. Feb 1972 3 Phil G 23.000 € 1. Jan 1973 1 Joe D 24.000 € 1. Jun 1970 2 Peter J 28.000 € 1. Feb 1972 3 Phil G 23.000 € 1. Jan 1973
- 13. 13 Wie funktioniert eine spaltenorientierte Datenbank? 1 2 3 ID Name Gehalt Anfangsdatum 1 Joe D 24.000 € 1. Jun 1970 2 Peter J 28.000 € 1. Feb 1972 3 Phil G 23.000 € 1. Jan 1973 Joe D Peter J Phil G 24.000 € 28.000 € 23.000 € 1. Jun 1970 1. Feb 1972 1. Jan 1973
- 14. 14 Warum ist das attraktiv? • Plattenzugriff „am Stück“ ermöglicht effizientes Lesen einer Spalte • Die Komprimierung ähnlicher Daten ist extrem effizient • Mit einem Plattenzugriff können somit mehr Daten abgerufen werden • Werden nur einzelne Spalten benötigt, müssen hierfür nicht alle Zeilen ausgelesen werden • Aber: – Zeilen zu aktualisieren oder zu löschen ist teuer • Besser für OLAP geeignet als für OLTP
- 15. 15 Graphdatenbanken • Speichern Graphen (Kanten und Ecken) • Beispiel: Soziale Netzwerke • Effizientes Folgen von Kanten • Optimiert für die Repräsentation von Verbindungen • Keine Graphen, dann keine Graphdatenbank verwenden!
- 16. 16 Multi-Model-Datenbanken • Kombination mehrerer Speicher-/Zugriffsmodelle • Häufig Graph + „X“ • Löst Problem, mehrere Datenbanken synchron halten zu müssen • Der „letzte Schrei“ im Bereich NoSQL
- 17. 17 Dokumentenorientierte Datenbanken • Keine PDF-, Word- oder HTML-Dokumente • Dokumente sind verschachtelte Strukturen, die mit Javascript Object Notation (JSON) erstellt werden { name : “Benjamin Lorenz”, title : “Senior Solutions Architect”, Address : { address : “An der Welle 4”, city : “Frankfurt”, zip_code : “60322”, } expertise: [ “MongoDB”, “Python”, “Javascript” ], employee_number : 521, location : [ 53.34, -6.26 ] }
- 18. 18 Mit MongoDB werden Dokumente typisiert { name : “Benjamin Lorenz”, title : “Senior Solutions Architect”, Address : { address : “An der Welle 4”, city : “Frankfurt”, zip_code : “60322”, } expertise: [ “MongoDB”, “Python”, “Javascript” ], employee_number : 521, location : [ 53.34, -6.26 ] } Strings Verschachteltes Dokument Array Integer Geokoordinaten
- 19. 19 MongoDB versteht JSON-Dokumente • Native JSON-Datenbank seit der ersten Version • Kann Unterstrukturen verstehen und indizieren • Speichert JSON binär als BSON • Effiziente Kodierung und Dekodierung zur Netzwerkübertragung • MongoDB kann Indizes für jedes Dokumentenfeld erstellen • ...mehr dazu im weiteren Kursverlauf
- 20. 20 Warum Dokumente? • Dynamisches Schema • Wegfall des objekt-relationalen Mappings • Implizite Denormalisierung der Daten zur Leistungssteigerung
- 21. 21 Warum Dokumente? • Dynamisches Schema • Wegfall des objekt-relationalen Mappings • Implizite Denormalisierung der Daten zur Leistungssteigerung
- 22. 22 MongoDB bietet sämtliche Funktionen Leistungsstarke Abfragen • Pauls Autos finden • Alle Frankfurter Autobesitzer zwischen 1970 und 1980 finden Geokoordinaten • Alle Autobesitzer im Umkreis von 5 km des Frankfurter Messeturms finden Textsuche • Alle Autos finden, die laut Beschreibung mit Ledersitzen ausgestattet sind Verdichtung • Durchschnittswert von Pauls Autosammlung berechnen Map Reduce • Finde Muster bzgl. Farben, Ort und Zeit („gibt es in China einen Trend zu Lila?“)
- 23. 23 Hohe Verfügbarkeit und Dauerhaftigkeit – Replica Sets SekundärSekundär Primär
- 24. 24 Erzeugung eines Replica Sets SekundärSekundär Primär Heartbeat
- 25. 25 Ausfall eines Servers SekundärSekundär Primär Kein Heartbeat
- 26. 26 Wiederherstellung der Funktionalität SekundärSekundär Heartbeat Wahl eines neuen Primär-Knotens
- 27. 27 Neues Replica Set – 2 Knoten SekundärPrimär Heartbeat Neuer Primär-Knoten
- 28. 28 Reparatur des Replica Sets SekundärPrimär Sekundär Neuer Verbund und Synchronisation
- 30. 30 Skalierbarkeit mit Sharding Shard 1 Shard 2 Shard N
- 31. 31 Skalierbarkeit mit Sharding • Shard-Schlüssel partitioniert Inhalt • MongoDB balanciert Datenmenge im Cluster automatisch • Shards können dem Live-System dynamisch hinzugefügt werden • Neue Ausbalancierung erfolgt im Hintergrund • Shard-Schlüssel ist unveränderbar • Shard-Schlüssel ermöglicht es, Abfragen an ein einzelnes Shard zu richten • Abfragen ohne Shard-Schlüssel werden an alle Shards gesendet
- 32. 32 Skalierbarkeit mit Sharding MongoS MongoS Shard 1 Shard 2 Shard N Shard-Schlüssel
- 33. 33 Abfrage-Routing • Sharded Cluster nutzen einen Router zur Verteilung der Abfragen • Daemon namens MongoS (Mongo Shard Router) • Daemon ist zustandslos • Kann so oft instanziiert werden wie nötig • Typischerweise eine Instanz pro App-Server
- 34. 34 Zusammenfassung • Warum NoSQL • Unterschiedliche Typen von NoSQL-Datenbanken • Die wichtigsten Merkmale von MongoDB • Dauerhaftigkeit in MongoDB • Skalierbarkeit in MongoDB
- 35. 35 Nächstes Webinar – Ihre erste MongoDB-Anwendung • 16. Juni 2016, 14:00 CEST • Bitte Anmeldung nicht vergessen • Entwicklung einer eigenen MongoDB-Anwendung • Datenbanken und Collections erstellen • Abfragen formulieren • Indizes erstellen • Performance verstehen • Feedback an back-to-basics@mongodb.com
Hinweis der Redaktion
- Persönliche Vorstellung und Werdegang bei MongoDB
- Ich freue mich, Sie heute begrüßen zu dürfen. Ich hoffe, dass es alle zum Webinar schaffen. Die Veranstaltungen werden aufgezeichnet und Ihnen anschließend zugesendet. Es ist also nicht schlimm, wenn Sie mal eine verpassen. Wenn Sie eine Frage haben, stellen Sie diese bitte in der Seitenleiste.
- Manche Leute denken, wir würden über relationale Datenbanken herziehen oder sie schlecht finden. Aber das stimmt nicht. Relationale Datenbanken bieten alles, was eine Datenbank braucht. Und natürlich wissen wir, dass einige ihrer Funktionen noch heute von großer Bedeutung sind. Expressive Abfragesprache & sekundäre Indizes. Als Nutzer sollte man auf seine Daten auf unterschiedliche Weise zugreifen und sie bearbeiten können. Dazu benötigt man eine geeignete Abfragesprache. Indizes sind für einen effizienten Datenzugriff grundlegend. Unserer Auffassung nach sind sie überhaupt das Herzstück jeder Datenbank. Hohe Konsistenz. Wenn wir neue Anwendungen planen, denken wir mit gutem Grund zuerst an die Konsistenz. Die Datenbank sollte stets den Zugriff auf die aktuellste Version der Daten ermöglichen. Hohe Konsistenz ist also der richtige Weg bei der Entwicklung von Datenbanken. Enterprise-Management und Integration. Schließlich sind Datenbanken auch nur ein Puzzlestück, das sich in die EDV-Infrastruktur von Unternehmen eingliedern muss. Denn die brauchen Datenbanken, die sich sichern, kontrollieren, automatisieren und in die bestehende IT-Landschaft und das entsprechende Personal wie Betriebsteams, DBA und Datenanalysten integrieren lassen können.
- Seit den Achtzigern, als die ersten relationalen Datenbanken aufkamen, hat sich die Welt enorm verändert. Einerseits sind Datenmengen und Risiken gewachsen. Zu den Daten: Halten Sie sich einmal vor Augen, dass 90 Prozent aller jemals produzierten Daten in den letzten zwei Jahren entstanden sind – 90 Prozent! 80 Prozent der Unternehmensdaten sind dabei unstrukturiert und passen nicht einmal in die am besten strukturierten Tabellen relationaler Datenbanken. Und das Wachstum solcher Daten ist doppelt so hoch wie bei strukturierten Daten. Gleichzeitig sind die Risiken des Datenbankbetriebs größer als jemals zuvor. Heute gibt es: Mehr Nutzer – Apps waren früher kleine interne Systeme mit tausenden Nutzern, heute haben sie externe Nutzerzahlen, die in die Millionen gehen. Keine Downtime – Apps müssen nicht mehr nur während der üblichen Geschäftszeiten verfügbar sein. Sondern rund um die Uhr. Weltweit – Ihre Nutzer sind überall und sie sind immer online. Andererseits sind Zeitaufwand und Kosten stark gesunken. Die Entwicklung von Apps war noch nie so einfach. Also müssen Sie: Apps in wenigen Monaten – nicht Jahren – fertigstellen können. Entwicklungsverfahren wurden vom Gießkannenprinzip auf einen iterativen Prozess umgestellt, bei dem neue Funktionen binnen Wochen – bei Unternehmen wie Amazon oder Facebook manchmal sogar mehrmals täglich – entwickelt werden. Und auch die Kosten sind stark gesunken. Unternehmen wollen: Für den Wertverlauf bezahlen: Unternehmen haben auf Open Source und SaaS umgestellt, bei denen Sie für den Wertverlauf zahlen. Cloud- und Rohstoffressourcen nutzen: So können sie die Zeit bis zur Bereitstellung ihrer Infrastruktur verkürzen und die Gesamtbetriebskosten verringern.
- Da relationale Datenbanken nicht für moderne Anwendungen entwickelt wurden, begann eine Reihe von Firmen vor etwa 10 Jahren damit, ihre eigenen, vollkommen andersartigen Datenbanken zu entwickeln. Diese werden NoSQL genannt. NoSQL-Datenbanken wurden speziell für die Welt von morgen entwickelt. Flexibilität: Sie alle verfügen über flexible Datenmodelle, um eine schnelle Iteration zu ermöglichen und die Daten heutiger Anwendungen zu bewältigen. Zwar gibt es unterschiedliche Ansätze, alle haben aber größtmögliche Flexibilität zum Ziel. Skalierbarkeit & Performance. Auch wurden sie alle unter der Maßgabe der Skalierbarkeit entwickelt, um Sharding und Partitionierung zu ermöglichen. Grundsätzlich ist es ihr Ziel, möglichst viel Leistung zu erbringen. Manche können besonders gut auslesen, andere schreiben, doch fast alle wollen die Leistungsfähigkeit relationaler Datenbanken übertreffen. Immer aktive, globale Bereitstellung Und zuletzt werden NoSQL-Datenbanken speziell für extrem verfügbare Systeme entwickelt, die allen Nutzern weltweit ein einheitliches und hochwertiges Nutzererlebnis ermöglichen wollen. Sie sollen auf unterschiedlichsten Computern funktionieren und ermöglichen die Replikation zur automatischen Synchronisierung der Daten zwischen unterschiedlichen Servern, Racks und Datenzentren. Doch wenn man diese NoSQL-Systeme genauer betrachtet, haben sie das Kind mit dem Bade ausgeschüttet. Denn sie haben die wichtigsten Datenbankfunktionen geopfert, die jeder erwartet und auf die man sich bei der Entwicklung funktionsfähiger Apps verlässt – wie Rich Querying und sekundäre Indizes, hohe Konsistenz und Enterprise-Management.
- MongoDB wurde speziell entwickelt, um diesen veränderten Bedingungen gerecht zu werden und gleichzeitig die wichtigsten Datenbankfunktionen zu erhalten, die der Bau moderner Anwendungen erfordert. Unsere Vision ist es, die Arbeit, mit der Oracle und andere in den letzten 40 Jahren relationale Datenbanken zu dem gemacht haben, was sie heute sind, aufzunehmen und weiterzuführen. Wir setzen da an, wo andere aufgehört haben und verwenden Technologien, die Internetpioniere wie Google und Amazon entwickelt haben, um den Anforderungen moderner Anwendungen gerecht zu werden. MongoDB ist die einzige Datenbank, die die Innovationen von NoSQL nutzt und gleichzeitig die Grundlagen relationaler Datenbanken fortführt. Das nennen wir Nexus-Architektur.
- Vergleiche: redis, memcached, Cochbase.
- Spaltendatenbanken, die Sie kennen und schätzen: HP Vertiva, Cassandra.
- Leistungsstarke Abfragen, Textsuche, Geokoordinaten, Verdichtung und Map Reduce können je nach Leistungsstärke des Abfragemodells eingebaut werden.