[Musikwiedergabe] RICK Houlihan: Alles klar. Hallo, alle. Mein Name ist Rick Houlihan. Ich bin ein Senior Principal Lösungen Architekt bei der AWS. Ich konzentriere mich auf NoSQL und DynamoDB Technologien. Ich bin heute hier, um zu sprechen, Sie ein wenig über jene. 

Mein Hintergrund ist vor allem in der Datenschicht. Ich habe die Hälfte meiner Entwicklung Karriere mit dem Schreiben-Datenbank, Datenzugriff, Lösungen für verschiedene Anwendungen. Ich habe in Cloud Virtualisierung gewesen für etwa 20 Jahre. Also, bevor die Wolke der Wolke, Wir nannten es das Utility Computing. Und die Idee war, es ist wie PG & E, zahlen Sie für, was Sie verwenden. Heute nennen wir es die Wolke. 

Aber im Laufe der Jahre habe ich gearbeitet für ein paar Unternehmen haben Sie wahrscheinlich noch nie gehört. Aber ich habe eine Liste der technischen zusammengestellt Errungenschaften, ich denke, Sie sagen möchten. Ich habe acht Patente in Cloud-Systemen Virtualisierung, Mikroprozessor-Design, Complex Event Processing, und in anderen Bereichen auch. 

Also in diesen Tagen, konzentriere ich mich hauptsächlich auf NoSQL Technologien und die nächste Generation Datenbank. Und das ist in der Regel, was ich hier zu sein mit dir zu reden heute über. Also, was können Sie erwarten, von dieser Sitzung, wir werden durch eine kurze gehen Geschichte der Datenverarbeitung. Es ist immer hilfreich, zu verstehen, woher wir kommen und warum wir sind, wo wir sind. Und wir werden ein wenig sprechen wenig über NoSQL-Technologie aus fundamentaler Sicht. 

Wir werden in einige erhalten die DynamoDB Einbauten. DynamoDB ist AWS gibt keinen Geschmack. Es ist ein vollständig verwalteter und gehostet NoSQL-Lösung. Und wir werden ein wenig über Tisch sprechen Struktur, APIs, Datentypen, Indizes, und ein Teil der Einbauten dieser DynamoDB Technologie. Wir werden in einigen der Design zu erhalten Mustern und Best Practices. Wir werden Sie, wie Sie sprechen nutzen diese Technologie für einige der heutigen Anwendungen. Und dann werden wir ein wenig sprechen über die Entwicklung oder die Entstehung eines neuen Paradigmas in der Programmierung genannt ereignisgesteuerte Anwendungen und wie DynamoDB spielt in das auch. Und wir schicken Ihnen ein wenig zu verlassen eine Referenzarchitektur Diskussion so können wir über einige sprechen die Möglichkeiten, wie Sie DynamoDB verwenden. 

Also zuerst off-- das ist eine Frage Ich höre eine Menge ist, was ist eine Datenbank. Eine Menge Leute denken, dass sie wissen, was eine Datenbank ist. Wenn Sie Google, werden Sie das sehen. Es ist eine eine strukturierte Satz von Daten gehalten in einem Computer, vor allem eine, ist auf verschiedene Weise erreichen. Ich nehme an, das ist eine gute Definition einer modernen Datenbank. Aber ich mag es nicht, denn es bedeutet, ein paar Dinge. Es impliziert Struktur. Und impliziert, dass es auf einem Computer. Und Datenbanken nicht taten immer existieren auf Computern. Datenbanken tatsächlich in vielerlei Hinsicht bestand. 

So eine bessere Definition von a Datenbank ist so etwas wie dieses. Eine Datenbank ist eine organisierte Mechanismus zum Speichern, Verwalten, und Abrufen von Informationen. Dieses ist von About.com. So Ich mag das, weil es wirklich spricht über eine Datenbank, ein Repository, eine Sammlung von Informationen, die nicht unbedingt etwas, das auf einem Computer befindet. Und im Laufe der Geschichte, die wir nicht immer hatten Computern. 

Nun, wenn ich fragen Durchschnitts Entwickler heute, was ist eine Datenbank, das ist die Antwort, die ich bekommen. Irgendwo kann ich Sachen zu haften. Recht? Und es ist wahr. Aber es ist bedauerlich. Da die Datenbank ist wirklich das Fundament der modernen App. Es ist die Grundlage der jede Anwendung. Und wie Sie zu bauen, dass Datenbank, wie Sie strukturieren dass Daten gehen zu diktieren, wie die Anwendung führt Sie zu skalieren. 

So viele meiner Arbeit heute es zu tun hat, was passiert, wenn Entwickler diesen Ansatz und Umgang mit den Folgen einer Anwendung, die wird nun über die ursprüngliche Skalierung Vorsatz und leidet schlechtes Design. Hoffentlich, wenn Sie gehen heute weg, werden Sie haben ein paar Werkzeuge Gürtel, die Sie behalten werden daran, die gleichen Fehler zu machen. Gut. Also lassen Sie uns über ein wenig sprechen die Zeitleiste der Datenbanktechnologie. Ich glaube, ich lese ein Artikel nicht so lange her und sie sagte etwas auf dem lines-- es ist eine sehr poetische Aussage. Er sagte, die Geschichte Datenverarbeitung voll von Hochwasserzeichen Datenfluss. OK. Nun, ich denke, das ist irgendwie wahr. Aber ich tatsächlich sehen Sie wird als Die Geschichte ist eigentlich gefüllt mit hohem Wasserdruck von Daten. Da die Datenrate Verschlucken nie untergeht. Es geht nur bis. 

Und Innovation entsteht, wenn wir Datendruck, was zu sehen ist die Menge an Daten, die ist nun kommt in das System. Und es kann nicht verarbeitet werden kann, effizient entweder zeitlich oder in den Kosten. Und das ist, wenn wir anfangen bei Datendruck suchen. 

Also, wenn wir auf die erste Datenbank, diese ist derjenige, der zwischen den Ohren war. Wir sind alle damit geboren. Es ist eine schöne Datenbank. Es hat eine hohe Verfügbarkeit. Es ist immer wieder auf. Sie können jederzeit bekommen. 

Aber es ist einzelnen Benutzer. Ich kann meine Gedanken nicht mit Ihnen teilen. Sie können meine Gedanken nicht bekommen wenn Sie wollen, dass sie. Und ihre abilitiy ist nicht so gut. Wir vergessen Dinge. Hin und wieder, einer von uns Blättern und bewegt sich auf einer anderen Existenz und wir alles verlieren das war in dieser Datenbank. Also das ist nicht alles, was gut ist. 

Und das hat gut über die Zeit als wir wieder in den Tag wenn alles, was wir wirklich nötig zu wissen ist, wohin gehen wir auf morgen gehen oder in denen wir sammeln das beste Essen. Aber wie wir begonnen, als zu wachsen Zivilisation und Regierung begonnen zu entstehen, und Unternehmen begonnen, sich zu entwickeln, haben wir begonnen, erkennen wir, brauchen ein wenig mehr als das, was konnten wir in unserem Kopf zu setzen. Gut? 

Wir benötigten Systeme der Aufzeichnung. Wir benötigten Stellen in der Lage sein, Daten zu speichern. Also begannen wir Schreiben von Dokumenten, Erstellen von Bibliotheken und Archiven. Wir begannen die Entwicklung einer System ein Buchhaltung. Und das System der Ledger-Zählung lief die Welt seit vielen Jahrhunderten, und vielleicht sogar Jahrtausenden als wir Art wuchs bis zu dem Punkt wo das Datenlade übertroffen die Fähigkeit dieser Systeme Um ihn zu enthalten. 

Und das tatsächlich in den 1880er Jahren passiert ist. Recht? In der 1880 US-Volkszählung. Das ist wirklich, wo der Wende weisen moderne Datenverarbeitung. Dies ist der Punkt, an welche die Menge an Daten, das wurde durch die gesammelten US-Regierung bis zu dem Punkt kam wo es dauerte acht Jahre, um zu verarbeiten. 

Jetzt, acht Jahre-- als Sie wissen, die Volkszählung fährt alle 10 Jahre-- so ist es ziemlich offensichtlich, dass durch die Zeit, die wir bekam die Volkszählung 1890 die Menge an Daten, im Begriff war, verarbeitet werden durch Regierung gehen, um die 10 Jahre nicht überschreiten, dass sie würde startete die neue Volkszählung zu nehmen. Dies war ein Problem. 

So ein Typ namens Herman Hollerith kam und er erfand Einheit Rekord Punch Karten, Lochkartenleser Lochkarten Tabulator und die Zusammenstellung von Die Mechanismen für diese Technologie. Und das Unternehmen, das er auf das gebildete Zeit, zusammen mit einer Reihe von anderen, tatsächlich zu einer der Säulen der ein Kleinunternehmen, die wir heute wissen, genannt IBM. 

So IBM ursprünglich war das Datenbankgeschäft. Und das ist wirklich, was sie taten. Sie taten Datenverarbeitung. 

Da so die Verbreitung von Punch Karten, ein geniales Mechanismen der Lage zu sein, dass zu nutzen Technologie, um sortierte Ergebnismengen abrufen. Sie können in diesem Bild sehen dort haben wir eine little-- es ist ein wenig small-- aber Sie können sehen eine sehr geniale mechanischen Mechanismus wo wir eine Lochkartendeck. Und jemand Nahme ein kleiner Schraubendreher und das Festhalten durch die Slots und anheben , dass Spiel zu bekommen, dass Ergebnisse sortiert gesetzt. 

Dies ist eine Aggregation. Wir tun dies die ganze Zeit heute im Computer, wo Sie es in der Datenbank zu tun. Wir pflegten, um es manuell zu tun, nicht wahr? Menschen setzen diese Dinge zusammen. Und es war die Proliferation dieser Lochkarten in das, was wir nannten Daten Schlagzeug und Datenbandspulen, Papierband. 

Das Datenverarbeitungsindustrie fand eine Lehre aus der Klaviere. Klaviere wieder auf Jahrhundertwende verwendet werden, um Papierrollen mit Schlitzen verwenden auf, es zu sagen, welche Tasten zu spielen. So dass Technologie angepasst wurde schließlich, um digitale Daten zu speichern, weil sie diese Daten setzen auf jene Papierbandspulen. 

Jetzt als Ergebnis Daten wurde actually-- how Sie werden diese Daten direkt war abhängig von, wie Sie es gespeichert. Also, wenn ich die Daten auf einem Band, Ich hatte die Daten linear zu gelangen. Ich musste die ganze Rolle Band, alle Daten zugreifen kann. Wenn ich die Daten in Punch Karten, ich darauf zugreifen könnten in ein wenig mehr Zufalls Mode, vielleicht auch nicht so schnell. 

Aber es gab Einschränkungen, wie wir Zugriff auf Daten auf, wie gelagert wurde. Und so war dies ein Problem gehen in den 50er Jahren. Auch hier können wir damit beginnen, dass wir sehen, neue Technologien zu entwickeln, um zu verarbeiten die Daten, rechts, öffnet es die Tür für neue Lösungen, für neue Programme, neue Anwendungen für diese Daten. Und wirklich, Governance kann der Grund gewesen sein Grund haben wir einige dieser Systeme. Aber Geschäft wurde schnell der Fahrer hinter der Evolution der modernen Datenbank und die moderne Dateisystem. 

Also das nächste, was kam war in den 50er Jahren war das Dateisystem und das Entwicklung von Direktzugriffsspeicher. Das war schön. Nun, alle plötzlich, legen wir können unsere Dateien überall auf diesen Festplatten und wir können diese Daten direkt zuzugreifen. Das können wir analysieren, Informationen von Dateien. Und wir lösen die ganze Welt Probleme mit der Datenverarbeitung. 

Und das dauerte etwa 20 oder 30 Jahre, bis die Entwicklung der relationalen Datenbank, die ist, wenn die Welt haben wir beschlossen, jetzt müssen Sie ein Repository, das besiegt haben Die Zersiedelung der Daten in der gesamten Datei Systeme, die wir aufgebaut haben. Recht? Zu viele Daten in zu vielen verteilten Orte, die Deduplizierung von Daten, und die Kosten der Lagerung war enorm. 

In den 70er Jahren, die teuerste Ressource dass ein Computer hatte der Lagerung wurde. Sich der Prozessor als Fixkosten angesehen. Als ich kaufen die Box, die CPU tut etwas Arbeit. Es wird sein, ob die Spinnerei es auch richtig funktioniert oder nicht. Das ist wirklich eine versunkene Kosten. 

Aber was mich als Kosten Geschäft ist Lagerung. Wenn ich mehr Platten als nächstes kaufen Monat, das ist eine echte Kosten, die ich zu zahlen. Und das Speicher ist teuer. 

Jetzt sind wir fast forward 40 Jahre und wir haben ein anderes Problem. Die Rechen ist jetzt der teuerste Ressource. Der Speicher ist billig. Ich meine, wir überall auf dem Sprung können Wolke und wir bieten günstige Speicher finden. Aber was ich nicht finden können, ist billig zu berechnen. 

So der Evolution der heutigen Technik, der Datenbanktechnologie, wirklich rund fokussiert verteilten Datenbanken dass nicht leiden die gleiche Art von Tonleiter Einschränkungen der relationalen Datenbanken. Wir werden ein wenig darüber zu sprechen was das eigentlich bedeutet. 

Aber einer der Gründe, und der Fahrer hinter this-- wir sprach über die Datendruck. Datendruck ist etwas, daß treibt Innovationen. Und wenn man sich über Aussehen die letzten fünf Jahre, dies ist eine Tabelle, was die Daten Last über die allgemeine Unternehmens sieht aus wie in den letzten fünf Jahren. 

Und die allgemeine Faustregel diese days-- wenn Sie Google-- gehen 90% der Daten, speichern wir heute, und es war in den letzten zwei Jahren generiert. OK. Nun, dies ist nicht ein Trend, der neue ist. Dies ist ein Trend, der gewesen ist Ausgehen seit 100 Jahren. Seit Herman Hollerith entwickelt die Lochkarte, wir haben den Bau Daten-Repositories und Datenerfassung bei phänomenalen Raten. 

So in den letzten 100 Jahren, Wir haben diesen Trend zu sehen. Das ist nicht zu ändern. Auch in Zukunft werden wir sehen, dies, wenn nicht eine beschleunigte Entwicklung. Und Sie können sehen, wie das aussieht. 

Wenn ein Unternehmen im Jahr 2010 hatte eine Terabyte Daten verwaltet, heute bekannt, dass bedeutet, dass sie Verwaltung 6,5 Petabyte an Daten. Das ist 6500 Mal mehr Daten. Und ich weiß, dass dies. Ich arbeite mit diesen Unternehmen jeden Tag. Vor fünf Jahren, ich würde die Unternehmen zu sprechen die zu mir über das, was ein Schmerz zu sprechen wäre es ist, Terabytes von Daten zu verwalten. Und sie sprechen würde, mich darüber, wie wir sehen, dass dies ist wahrscheinlich ein Petabyte oder zwei innerhalb von ein paar Jahren. 

Dieselben Unternehmen Heute treffe ich mit, und sie werden zu mir sprechen über die Probleme gibt es mit Verwaltung Zehn, 20 Petabyte an Daten. So der Explosion des Daten in der Industrie treibt die enorme müssen nach besseren Lösungen. Und die relationale Datenbank ist einfach nicht leben bis zu der Forderung. 

Und so gibt es eine lineare Korrelation zwischen Datendruck und technische Innovation. Die Geschichte hat uns gezeigt, darin, daß im Laufe der Zeit, wenn das Datenvolumen, die verarbeitet werden muss, die Kapazität des Systems übersteigt um es in angemessener Zeit zu verarbeiten oder zu einem vernünftigen Preis, dann neue Technologien sind erfunden worden, um diese Probleme zu lösen. Diese neuen Technologien, die wiederum die Tür öffnen zu einem anderen Satz von Problemen, die sammelt noch mehr Daten. 

Jetzt werden wir nicht gehen, um dies zu stoppen. Recht? Wir gehen nicht, dies zu stoppen. Warum? Denn man kann nicht alles wissen gibt es im Universum kennen. Und solange wir am Leben gewesen, in der gesamten Geschichte der Menschheit, wir haben immer angesteuert, um mehr zu erfahren. 

So scheint es, wie jeder Zoll wir uns bewegen auf dem Weg der wissenschaftlichen Entdeckung, wir Multiplikation der Menge der Daten dass wir exponentiell zu verarbeiten wie wir aufzudecken mehr und mehr über das Innenleben des Lebens, darüber, wie das Universum funktioniert, etwa Antrieb der wissenschaftlichen Entdeckung, und die Erfindung, dass wir heute tun. Die Datenmenge genau kontinuierlich erhöht. So in der Lage zu bewältigen Dieses Problem ist enorm. 

So ist eines der Dinge wir als, warum NoSQL aussehen? Wie funktioniert NoSQL dieses Problem lösen? Nun, relationale Datenbanken, Strukturierte Abfragesprache, SQL-- das ist wirklich ein Konstrukt der relationale database-- diese Dinge sind optimiert für die Lagerung. 

Zurück in die 70er Jahre wieder Platte ist teuer. Die Bereitstellungs Ausübung der Speicher im Unternehmen wird niemals enden. Ich kenne. Ich lebte sie. Ich schrieb Speichertreiber für ein enterprised superserver Unternehmens zurück in den 90er Jahren. Und unter dem Strich ist ein weiterer Regal Speicher-Array war einfach etwas, passiert jeden Tag im Unternehmen. Und es nie aufgehört. Höhere Speicherdichte, Nachfrage für hochdichte Lagerung, und für eine effizientere Speicher devices-- es nie aufgehört. 

Und NoSQL ist eine großartige Technologie weil es normalisiert die Daten. Es de-dupliziert die Daten. Es setzt die Daten in einer Struktur, ist Agnostiker zu jedem Zugriffsmuster. Mehrere Anwendungen können getroffen, dass SQL-Datenbank, führen Ad-hoc-Abfragen, und erhalten Daten in der Form, dass sie müssen für die Arbeitslasten zu verarbeiten. Das klingt fantastisch. Aber unter dem Strich ist mit irgend System, wenn es Agnostiker, alles, es ist für nichts optimiert. OK? 

Und das ist, was wir mit zu bekommen Die relationale Datenbank. Es ist für die Lagerung optimiert. Es ist normiert. Es ist relational. Es unterstützt die Ad-hoc-Abfragen. Und es und es skaliert vertikal. 

Wenn ich, um eine größere SQL-Datenbank zu erhalten oder ein leistungsfähiger SQL-Datenbank, Ich gehen Sie kaufen ein größeres Stück Eisen. OK? Ich habe mit vielen Kunden zusammengearbeitet, , die durch erhebliche Verbesserungen gewesen in ihrer SQL-Infrastruktur nur bis sechs Monate später herauszufinden, sie gegen die Wand wieder. Und die Antwort von Oracle oder MSSQL oder sonst jemand ist bekommen ein größeres Kasten. Nun, früher oder später, kann man nicht kaufen ein größeren Kasten, und das ist echtes Problem. Wir brauchen, um tatsächlich die Dinge zu ändern. Also, wo funktionierts? Es funktioniert gut für die Offline- Analytik, OLAP-Typ-Workloads. Und das ist wirklich, wo SQL gehört. Nun, sie heute in vielen Online verwendet wird, Transaktionsverarbeitungstyp Anwendungen. Und es funktioniert nur bei Fein einige Auslastung, aber es funktioniert einfach nicht skalieren der Weg, der NoSQL tut. Und wir werden ein wenig sprechen wenig darüber, warum das so ist. 

Nun NoSQL andererseits ist mehr für rechen optimiert. OK? Es ist nicht zu unabhängig das Zugriffsmuster. Das nennen wir de-normalisierte Struktur oder eine hierarchische Struktur. Die Daten in einer relationalen Datenbank ist zusammen aus mehreren Tabellen beigetreten um die Ansicht, die Sie brauchen zu produzieren. Die Daten in einer Datenbank NoSQL wird in einem Dokument gespeichert werden und enthält die hierarchische Struktur. Alle Daten, die normalerweise wäre zusammen, um diese Ansicht zu erzeugen wird in einem einzigen Dokument gespeichert. Und wir werden ein wenig darüber zu sprechen how, das in ein paar Charts funktioniert. 

Aber die Idee ist hier, dass Sie speichern Ihre Daten, da diese instanziiert Blick. OK? Sie skalieren horizontal. Recht? Wenn ich auf den Anstieg Größe meines NoSQL-Cluster, Ich brauche, um eine größere Box. Bekomme ich ein anderes Feld. Und ich Cluster diejenigen zusammen, und ich kann diese Daten Splitter. Wir werden ein wenig darüber zu sprechen was sharding ist, zu sein in der Lage, diese Datenbank zu skalieren über mehrere physische Geräte und entfernen Sie die Barriere, verlangt von mir, um vertikal zu skalieren. 

Es ist also wirklich für Online gebaut Transaktionsverarbeitung und Skalierung. Es gibt einen großen Unterschied hier zwischen der Berichterstattung, nicht wahr? Berichterstattung, weiß ich nicht, die Fragen, ich werde fragen. Recht? Reporting-- wenn jemand aus meine Marketing-Abteilung will just--, wie viele meiner Kunden haben diese besondere Eigenschaft, die auf dieser day-- Ich weiß nicht, gekauft was abfragen sie gehen, um zu fragen. Also muss ich Agnostiker zu sein. 

Nun, in einem Online- Transaktionsanwendung, Ich weiß, welche Fragen ich frage. Ich den Antrag auf gebaut eine sehr spezifische Workflow. OK? Wenn ich also die Optimierung der Daten zu speichern, um diese Workflow-Unterstützung, es wird schneller zu sein. Und deshalb kann NoSQL die Lieferung wirklich beschleunigen dieser Typen von Diensten. Gut. 

So werden wir in zu erhalten ein wenig Theorie hier. Und einige von euch, die Augen könnte ein Rollback ein wenig. Aber ich werde versuchen, es zu halten so hohen Niveau wie ich kann. Also, wenn Sie im Projekt sind Management, gibt es ein Konstrukt, genannt Dreieck von Einschränkungen. OK. Das Dreieck der Zwänge Diktat man kann nicht alles haben die ganze Zeit. Kann nicht Ihre pie und ihn auch essen. So im Projektmanagement, dass Dreieck Einschränkungen ist, dass Sie es billig haben kann, Sie können es schnell zu haben, oder Sie können es gut. Suche dir zwei aus. Da kann man nicht alle drei. Recht? OK. 

So dass Sie hören über dieses viel. Es ist eine dreifache Einschränkung, Dreieck der Dreifach-Einschränkung, oder der eisernen Dreieck ist oftentimes-- wenn Sie zu Projektmanagern zu sprechen, sie werden darüber reden. Jetzt haben Datenbanken ihre eigenen eisernen Dreieck. Und die eisernen Dreieck von Daten ist, was wir CAP-Theorem nennen. OK? 

CAP-Theorem Diktat how-Datenbanken betreiben unter einem ganz bestimmten Zustand. Und wir sprechen was diese Voraussetzung. Aber die drei Punkte des Dreiecks, sozusagen, C, Konsistenz. OK? So in CAP bedeutet Konsistenz, dass alle Kunden, die auf die Datenbank zugreifen kann immer eine ganz konsistente Ansicht der Daten. Niemand wird sehen, zwei verschiedene Dinge. OK? Wenn ich auf die Datenbank, Ich sehe die gleiche Ansicht wie mein Partner, der sieht, dieselbe Datenbank. Das ist Konsistenz. 

Verfügbarkeit bedeutet, wenn die Datenbank online, wenn es erreicht werden kann, dass alle Clients wird immer in der Lage zu lesen und zu schreiben. OK? So dass jeder Client, können die Datenbank zu lesen immer in der Lage sein, Lese Daten und Schreiben von Daten. Und wenn das der Fall ist, es ist ein System zur Verfügung. 

Und der dritte Punkt ist, was wir nennen Partitionstoleranz. OK? Partitionstoleranz Mittel dass das System arbeitet gut trotz der physischen Netzwerk Trennwände zwischen den Knoten. OK? So Knoten im Cluster kann nicht miteinander reden, was passiert? Gut. 

So relationalen Datenbanken wählen-- Sie können zwei davon holen. OK. So relationalen Datenbanken wählen konsistente und verfügbar zu sein. Wenn die Partition geschieht zwischen die Datanodes in dem Datenspeicher, die Datenbank abstürzt. Recht? Es geht nur nach unten. OK. 

Und das ist, warum sie um mit größeren Boxen wachsen. Recht? Denn es gibt in der Regel NO-, ein Cluster Datenbank, gibt es nicht sehr viele von ihnen dass auf diese Weise zu betreiben. Aber die meisten Datenbanken skalieren vertikal innerhalb einer einzigen Box. Weil sie sein müssen konsistent und verfügbar. Wenn eine Partition wurden injiziert werden soll, dann müssten Sie eine Wahl treffen. Sie haben die Wahl zwischen zu machen konsistent und verfügbar. 

Und das ist, was NoSQL-Datenbanken zu tun. Gut. So eine NoSQL Datenbank hat kommt in zwei Geschmacksrichtungen. Wir have-- gut, es kommt in verschiedenen Formen, aber es ist mit zwei Grund kommt characteristics-- was wir würden CP-Datenbank oder einen Anruf konsistente und Partitionstoleranz System. Diese Jungs machen die Wahl, dass, wenn die Knoten zu verlieren Kontakt miteinander, wir nicht zulassen, Menschen, mehr zu schreiben. OK? 

Bis diese Partition wird entfernt, Schreibzugriff ist blockiert. Das bedeutet, dass sie nicht zur Verfügung. Sie sind konsistent. Wenn wir sehen, dass Partition zu injizieren selbst, Wir sind jetzt im Einklang, denn wir werden nicht um die Datenänderungen auf beiden ermöglichen Seiten der Trennwand unabhängig von einander. Wir werden müssen wiederherzustellen Kommunikations vor jeder Aktualisierung die Daten erlaubt. OK? 

Der nächste Geschmacks wäre ein AP-System, oder eine zur Verfügung und verteilt Toleranzsystem. Diese Jungs egal. Recht? Jeder Knoten, der eine bekommt zu schreiben, nehmen wir es. Also werde ich meine Daten zu replizieren über mehrere Knoten. Diese Knoten erhalten ein Client, Client kommt in, sagt, ich werde ein paar Daten zu schreiben. Knoten sagt, kein Problem. Der Knoten neben ihm bekommt ein Schreib auf der gleichen Platte, er wird kein Problem zu sagen. Irgendwo hinten am hinteren Ende, dass Daten geht um zu replizieren. Und dann geht jemand zu erkennen, uh-oh, sie System zu realisieren, uh-oh, Es hat ein Update auf beiden Seiten. Was machen wir? Und was sie tun, dann ist sie etwas tun was ermöglicht es ihnen, dass die Datenzustand zu lösen. Und wir sprechen dass in der folgenden Tabelle. 

Sache, hier darauf hinzuweisen. Und ich werde mich nicht zu bekommen wesentlich, weil diese in diesem gerät in tiefe Daten Theorie. Aber es gibt eine Transaktions Rahmen, läuft in einem relationalen System, erlaubt mir, sicher zu machen Aktuelles um mehrere Einheiten in der Datenbank. Und diese Updates auftreten auf einmal oder überhaupt nicht. Und dies ist ACID-Transaktionen aufgerufen. OK? 

ACID gibt uns Unteilbarkeit, Konsistenz, Isolation und Haltbarkeit. OK? Das bedeutet, dass Atom, Transaktionen, alle meine Updates entweder geschehen, oder tun sie nicht. Konsistenz bedeutet, dass Die Datenbank wird immer in einen konsistenten gebracht werden Zustand nach einem Update. Ich werde nie die Datenbank in einem verlassen schlechten Zustand nach der Anwendung ein Update. OK? 

Also ist es ein bisschen anders als CAP Konsistenz. CAP Konsistenz bedeutet, alle meine Kunden können immer sehen, die Daten. ACID Konsistenz bedeutet, dass, wenn eine Transaktion fertig ist, die Daten gut. Meine Beziehungen sind alle gut. Ich werde nicht um eine übergeordnete Zeile löschen und lassen eine Reihe von Waisenkindern in einer anderen Tabelle. Es kann nicht passieren, wenn ich mich im Einklang in einem sauren Transaktion. 

Isolation bedeutet, dass Transaktionen besteht immer dann, nacheinander. Das Endergebnis des Daten wird der gleiche Zustand sein als ob diese Geschäfte , die gleichzeitig ausgegeben wurden wurden seriell ausgeführt. So ist es Parallelität Kontrolle in der Datenbank. Also im Grunde kann ich nicht erhöhen die gleichen Wert zweimal mit zwei Operationen. 

Aber wenn ich sage, fügen Sie 1 auf diesen Wert, und zwei Transaktionen kommen in und zu versuchen, es zu tun, ist eine werde es zuerst erhalten und das andere ist gehen, um dort nach dem zu bekommen. Also am Ende, ich zwei aufgenommen. Sie sehen, was ich meine? OK. 

Haltbarkeit ist ziemlich einfach. Wenn das Geschäft quittiert wird, ist es werde es sogar sein, wenn das System abstürzt. Wenn das System gewinnt, daß Transaktion, die begangen wurde, ist eigentlich los, dort zu sein. Also das ist, die Garantien der ACID-Transaktionen. Das sind ziemlich nett Garantien auf einer Datenbank, aber sie kommen zu diesem Preis. Recht? 

Weil das Problem mit dieser Rahmen wenn es eine Partition in der Daten Satz, muss ich eine Entscheidung treffen. Ich werde zu haben, um zu ermöglichen Aktualisierungen auf einer Seite oder der anderen. Und wenn das passiert, dann bin ich nicht mehr gehen in der Lage zu pflegen diese Merkmale. Sie werden nicht konsistent sein. Werden sie nicht isoliert werden. Dies ist, wo es zusammenbricht für relationale Datenbanken. Dies ist der Grund relationalen Datenbanken skalieren vertikal. 

Auf der anderen Seite, haben wir was heißt Basistechnologie. Und das sind Ihre NoSQL-Datenbanken. Gut. So haben wir unsere CP, AP-Datenbanken. Und das sind, was Sie im Grunde nennen zur Verfügung, weichen Zustand, schließlich konsistent. OK? 

Grundsätzlich möglich, weil sie sind Partition tolerant. Sie wird immer sein da, auch wenn es eine Netzwerkaufteilung zwischen den Knoten. Wenn ich zu einem Knoten zu sprechen, ich bin in der Lage sein, Daten zu lesen. OK? Ich könnte nicht immer in der Lage zu schreiben Daten, wenn ich eine einheitliche Plattform. Aber ich werde in der Lage, Daten zu lesen. 

Die weichen Zustand anzeigt, dass, wenn ich, dass die Daten zu lesen, es vielleicht nicht die gleiche wie die anderen Knoten sein. Wenn ein Recht auf einem Knoten ausgegeben woanders im Cluster und es wurde nicht über die replizierte Cluster noch, wenn ich lese, dass die Daten, dieser Zustand möglicherweise nicht konsistent sein. Jedoch wird es schließlich im Einklang, was bedeutet, dass, wenn eine Schreib wird an dem System vorgenommen, es wird über die Knoten zu replizieren. Und schließlich, dass staatliche werden in Ordnung gebracht werden, und es wird ein konsistenter Zustand. 

Nun, CAP-Theorem wirklich spielt nur in einer Bedingung. Bedingung ist, dass, wenn dies geschieht. Denn wenn es in Betrieb Normal-Modus, gibt es keine Partition, alles ist konsistent und verfügbar. Sie CAP Sorgen nur wenn wir diese Partition. Das sind also selten. Aber, wie das System reagiert, wenn diejenigen, auftreten, zu diktieren, welche Art von System wir es zu tun. 

Werfen wir also einen Blick auf das, was das sieht aus wie für die AP-Systeme. OK? AP-Systeme kommen in zwei Geschmacksrichtungen. Sie kommen in den Geschmack, der eine ist Master Master, 100%, immer verfügbar. Und sie kommen in die anderen Geschmack, der sagt: Sie wissen, was, ich werde zur Sorge zu diesem Partitionierungs Sache wenn eine tatsächliche Partition auftritt. Andernfalls es geht primär zu sein Knoten, die vor sich geht, um die Rechte zu nehmen. OK? 

Also, wenn wir so etwas wie Cassandra. Cassandra wäre ein Herr sein Master, lassen Sie mich zu einem beliebigen Knoten zu schreiben. Also, was passiert? So habe ich ein Objekt in der Datenbank, die auf zwei Knoten existiert. Nennen wir das Objekt S. So haben wir Zustand für S. Wir haben einige Operationen S auf, die laufenden sind. Cassandra ermöglicht es mir, schreiben Sie an mehrere Knoten. Also sagen wir mal ich ein Schreiben für s auf beiden Knoten. Nun, was am Ende passiert ist, fordern wir, dass eine Unterteilung Veranstaltung. Es sind möglicherweise nicht ein physische Netzwerkpartition. Aber wegen des Designs des Systems, ist es tatsächlich Partitionierung so bald wie bekomme ich eine Schreib auf beiden Knoten. Es hat mich nicht zu zwingen, schreiben alle durch einen Knoten. Ich schreibe auf beiden Knoten. OK? 

So, jetzt habe ich zwei Staaten. OK? Was wird passieren ist früher oder später, es geht um eine Replikation Ereignis. Es geht um das, was wir genannt Partition Recovery, die ist, wo diese beiden Staaten kommen wieder zusammen und es geht um ein Algorithmus sein das läuft in der Datenbank, entscheidet, was zu tun ist. OK? Standardmäßig letzten Aktualisierung gewinnt in den meisten AP-Systeme. So gibt es in der Regel ein Standard-Algorithmus, was sie einen Rückruf nennen Funktion, etwas das aufgerufen wird, wenn diese Bedingung erfaßt wird, um eine gewisse Logik ausführen , diesen Konflikt zu lösen. OK? Die Standard-Callback und Standard Resolver in den meisten AP-Datenbanken ist, wissen Sie was, gewinnt Zeitstempel. Dies war das letzte Update. Ich werde das Update in es gesetzt. Ich kann diese Platte entleeren, dass ich off in ein Wiederherstellungsprotokoll gedumpten so dass der Benutzer kann später wieder zu kommen und sagen, hey, es gab eine Kollision. Was ist passiert? Und man kann tatsächlich Dump eine Aufzeichnung alle Kollisionen und die Rollbacks und sehen was passiert. 

Nun, als Benutzer, können Sie auch eine Logik in diesem Rückruf. So können Sie das ändern Callback-Betrieb. Man kann sagen, hey, ich will um diese Daten zu sanieren. Und ich möchte, um zu versuchen, mischen Sie die verschiedenen Datensätzen. Aber das ist bis zu Ihnen. Die Datenbank enthält nicht, wie man zu tun, dass standardmäßig. Esten Zeit, das einzige, was die Datenbank weiß, wie zu tun ist, zu sagen, dieses war der letzte Datensatz. Das ist die eine, die gehen, um zu gewinnen, und das ist der Wert, ich werde setzen. Sobald dieser Partition Recovery und Replikation erfolgt, Wir haben unseren Staat, der ist jetzt im Prime, das ist, die Zusammenführung Staat für alle diese Objekte. So AP-Systeme haben diese. CP-Systeme müssen nicht zu kümmern. Denn sobald eine Trennwand kommt ins Spiel, sie einfach aufhören, schreibt. OK? Also das ist sehr einfach, befassen sich mit konsequent Wenn Sie keine Updates nicht akzeptieren. Das ist mit CP-Systemen zu tun. Gut. 

Also reden wir ein wenig wenig über Zugriffsmuster. Wenn wir über NoSQL zu sprechen, ist es alles über die Zugriffsmuster. Nun ist SQL Ad-hoc-Abfragen. Es ist relationalen Speicher. Wir haben keine Sorgen zu machen, über die Zugriffsmuster. Ich schreibe eine sehr komplexe Abfrage. Es versteht sich und bekommt die Daten. Das ist, was so aussieht wie, Normalisierung. 

Also in diesem besonderen Struktur, wir sind in einem Produktkatalog suchen. Ich habe verschiedene Arten von Produkten. Ich habe Bücher. Ich habe Alben. Ich habe Videos. Das Verhältnis zwischen den Produkten und eines dieser Bücher, Alben, und Videos Tische beträgt 1: 1. Gut? Ich habe eine Produkt-ID hat, und dass die ID entspricht ein Buch, ein Album oder ein Video. OK? Das ist eine 1: 1-Beziehung in diesen Tabellen. 

Nun, alles, was sie books-- haben, ist root Eigenschaften. Kein Problem. Das ist klasse. Eins-zu-eins-Beziehung, bekomme ich alle die Daten, die ich brauche, um das Buch zu beschreiben. Albums-- Alben haben Spuren. Dies ist, was wir als eine von vielen. Jedes Album könnte viele Spuren haben. Also für jeden Track auf das Album, ich könnte ein weiterer Rekord in dieser untergeordneten Tabelle. So erstelle ich einen Datensatz in meine Alben Tisch. Ich erstelle mehrere Datensätze in den Spuren Tabelle. Eins-zu-viele-Beziehung. 

Diese Beziehung ist, was wir nennen viele-zu-viele. OK? Sie sehen, dass Akteure könnte in vielen Filmen, viele Videos. Also, was wir tun, ist wir dieses Mapping Tisch zwischen denen, die es einfach bildet den Akteur-ID an die Video-ID. Jetzt kann ich eine Abfrage, die Verknüpfungen zu erstellen Videos über Schauspieler Video Schauspieler, und es gibt mir eine schöne Liste alle Filme und alle Akteure die in dem Film waren. 

OK. So hier gehen wir. One-to-one ist die Top-Level- Beziehung; Eins-zu-viele, Alben, um Tracks; Viele-zu-Viele. Das sind die drei Top-Level- Beziehungen in einer Datenbank. Wenn Sie wissen, wie diejenigen, Beziehungen zusammenarbeiten, dann haben Sie viel wissen über Datenbank bereits. So NoSQL funktioniert ein wenig anders. Lassen Sie uns darüber nachdenken, für eine zweite, was es Sieht aus wie zu holen alle meine Produkte. 

In einer relationalen Speicher, I will alle meine Produkte zu bekommen auf eine Liste von alle meine Produkte. Das ist eine Menge von Anfragen. Ich habe eine Abfrage für alle meine Bücher. Ich habe eine Abfrage aus meine Alben. Und ich habe eine Abfrage für alle meine Videos. Und ich habe um es alle zusammen in einer Liste und servieren es wieder auf die Anwendung, ist es anfordert. 

Meine Bücher zu bekommen, ich schließe mich Produkte und Bücher. Um meine Alben zu bekommen, bekam ich zu verbinden Produkte, Alben und Tracks. Und meine Videos sehen zu bekommen, habe ich um Produkte zu Videos anzuschließen, kommen durch Schauspieler Videos, und bringen in den Schauspieler. Also das ist drei Abfragen. Sehr komplexe Abfragen zu montieren eine Ergebnismenge. 

Das ist weniger als optimal. Deshalb, wenn wir sprechen um eine Datenstruktur, die ist gebaut unabhängig auf den Zugang zu sein pattern-- auch das ist großartig. Und sehen Sie, das ist wirklich schön, wie wir die Daten organisiert. Und du weißt was? Ich habe nur einen Datensatz für einen Schauspieler. 

Das ist cool. Ich habe alle meine Schauspieler dedupliziert, und ich gehalten meines Verbände in dieser Mapping-Tabelle. Allerdings bekommen die Daten Sie wird teuer. Ich schicke die CPU auf der ganzen Anlage Beitritt dieser Datenstrukturen zusammen in der Lage sein, diese Daten zurückziehen können. 

So, wie ich mich um das zu bekommen? In NoSQL es geht um Aggregation nicht Normalisierung. So zu sagen, wir wollen, wir wollen unterstützen die Zugriffsmuster. Wenn der Zugriffsmuster auf die Anwendungen, Ich muss alle meine Produkte zu erhalten. Sagen wir alle Produkte in einer Tabelle. Wenn ich alle Produkte in einer Tabelle, Ich kann einfach alle Produkte wählen aus dieser Tabelle, und ich bekomme sie alle. Nun, wie kann ich das tun? Nun, in NoSQL gibt es keine Struktur zum Tisch. Wir werden ein wenig darüber zu sprechen Wie das funktioniert in Dynamo DB. Aber man kann nicht das gleiche haben Attribute und die gleichen Eigenschaften in jeder Reihe, in jeder einzelnen Artikel, wie Sie in einer SQL-Tabelle zu tun. Und was dies ermöglicht es mir zu tun ist, eine Menge Dinge, und gib mir eine Menge Flexibilität. In diesem besonderen Fall, I meine Produktunterlagen. Und in diesem besonderen beispielsweise alles, was ist ein Dokument, in der Tabelle Products. Und das Produkt für ein Buch könnte eine Typ-ID, die ein Buch gibt. Und die Anwendung würde an diesem ID wechseln. 

Auf der Anwendungsebene, ich werde zu sagen, Oh, was Satztyp ist das? Oh, es ist ein Buch Rekord. Buchen Datensätze haben diese Eigenschaften. Lassen Sie mich ein Buch-Objekt zu erstellen. Also werde ich das zu füllen Buch-Objekt mit diesem Titel. Nächster Artikel stammt und sagt, was ist das Thema? Gut, das Einzelteil ist ein Album. Oh, ich habe eine ganz andere Verarbeitungsroutine für das, denn es ist ein Album. Sie sehen, was ich meine? 

So dass die Anwendung tier-- I wählen Sie einfach alle diese Datensätze. Sie alle beginnen wieder in. Sie könnten alle verschiedenen Typen sein. Und es Logik der Anwendung ist dass die Schalter für diese Arten und entscheidet, wie sie zu verarbeiten. 

Wieder so dass wir die Optimierung der Schema für das Zugriffsmuster. Wir tun es, indem kollabiert die Tabellen. Wir sind im Grunde nehmen Diese normierten Strukturen und wir bauen hierarchische Strukturen. In jedem von diesen Aufzeichnungen Ich werde Array-Eigenschaften zu sehen. 

Innerhalb dieses Dokuments für Alben, Ich sehe Arrays von Tracks. Diese Tracks jetzt become-- es im Grunde dieses Kind Tisch, existiert hier in dieser Struktur. So können Sie dies in DynamoDB zu tun. Sie können dies in MongoDB zu tun. Sie können dies auf jeden NoSQL-Datenbank zu tun. Erstellen Sie diese Art von hierarchischen Datenstrukturen , mit denen Sie Daten abrufen sehr schnell, weil ich jetzt haben nicht zu entsprechen. Als ich Einfügen einer Zeile in die Tracks Tabelle oder eine Zeile in die Alben Tisch, Ich habe, um zu diesem Schema entsprechen. Ich muss das Attribut oder die haben Eigenschaft, die für die Tabelle definiert ist. Jeder von ihnen, wenn ich einfügen, dass die Reihe. Das ist nicht in NoSQL der Fall. 

Ich völlig anders haben können Immobilien in jedem Dokument dass ich einfügen in die Sammlung. So sehr leistungsfähigen Mechanismus. Und es ist wirklich, wie Sie das System zu optimieren. Da nun diese Abfrage anstelle Beitritt alle diese Tabellen und Ausführen ein halbes Dutzend Anfragen um die Daten, die ich brauchen, zurückziehen, Ich bin der Ausführung einer Abfrage. Und ich bin Iteration über die Ergebnisse eingestellt. es gibt Ihnen eine Vorstellung von der Macht der NoSQL. Ich werde hier seitlich Art von gehen und sprechen ein wenig über dies. Das ist mehr die Art von Marketing oder technology-- die Vermarktung von Technologien Art der Diskussion. Aber es ist wichtig zu verstehen, denn wenn wir uns an der Spitze hier bei diesem Diagramm Was wir suchen Das nennen wir die Technologie-Hype-Kurve. Und was das bedeutet, ist Neuigkeiten ins Spiel kommt. Die Leute denken, es ist toll. Ich habe alle meine Probleme gelöst. 

Dies könnte das Ende sein alles, alles sein, alles. Und sie starten Sie es. Und sie sagen, dieses Zeug funktioniert nicht. Das ist nicht richtig. Das alte Zeug war besser. Und sie gehen zurück zu tun, die Dinge so, wie sie waren. Und dann schließlich sie gehen, wissen Sie was? Dieses Zeug ist nicht so schlimm. Oh, das ist, wie es funktioniert. Und wenn sie herausfinden, wie es Werke, sie beginnen immer besser. 

Und das Komische daran ist, es Art von Leitungen bis zu dem, was wir nennen das Technology Adoption Curve. Also, was passiert ist, wir haben eine Art Technologie-Trigger. Im Fall von Datenbanken, es ist Datendruck. Wir sprachen über die Hochwasserstellen Datendruck im Laufe der Zeit. Wenn das Datendruck trifft eine gewisse Punkt, das ist eine Technologie-Trigger. 

Es ist immer zu teuer. Es dauert zu lange, um die Daten zu verarbeiten. Wir brauchen etwas besser. Sie erhalten die Innovatoren da draußen herumlaufen, versuchen, herauszufinden, was ist die Lösung. Was ist die neue Idee? 

Was ist die nächste beste Weg, dies zu tun? Und sie kommen mit etwas. Und die Menschen, mit dem echte Schmerzen, die Jungs von der bleeding edge, sie werden alle über sie zu springen, weil sie eine Antwort. Nun, was unweigerlich happens-- und es passiert gerade in NoSQL. Ich sehe es die ganze Zeit. 

Was passiert, ist unvermeidlich Menschen beginnen mit dem neuen Werkzeug die gleiche Art, wie sie verwendet werden, das alte Werkzeug. Und sie erfahren, es nicht so gut funktionieren. Ich weiß nicht mehr, wer ich war Gespräch mit früher heute. Aber es ist wie, wenn die Presslufthammer erfunden wurde, Menschen nicht schwenken über den Kopf, um den Beton zu zerschlagen. 

Aber das ist, was ist geschieht mit NoSQL heute. Wenn Sie in den meisten Geschäften entfernt, sie versuchen, NoSQL Geschäften sein. Was sie tun ist sie sind mit NoSQL, und sie sind es Laden voll von relationalen Schema. Denn das ist, wie sie entwerfen Datenbanken. Und sie fragen sich, warum ist sie nicht auf der Bühne sehr gut? Boy, stinkt dieses Ding. Ich musste alle meine pflegen verbindet in-- es ist wie, nein, nein. Pflegen Sie verbindet? Warum sind Sie Verbindungsdaten? Sie können Daten kommen in NoSQL. Sie aggregieren. 

Also, wenn Sie dies vermeiden wollen, lernen, , wie das Tool funktioniert, bevor Sie tatsächlich starten Sie es. Versuchen Sie nicht, und verwenden Sie die neuen Werkzeuge der genauso, wie Sie verwendet die alten Werkzeuge. Du wirst eine schlechte Erfahrung gemacht haben. Und jedes einzelne Mal das ist, worum es geht. Wenn wir anfangen, hier kommen, es ist, weil die Menschen herausgefunden, wie man die Werkzeuge benutzen. 

Sie taten das Gleiche, wenn relationalen Datenbanken erfunden wurden, und sie wurden ersetzt Dateisysteme. Sie versuchten, Dateisysteme zu bauen mit relationalen Datenbanken denn das ist, was die Leute zu verstehen. Es hat nicht funktioniert. So das Verständnis der Best Practices der Technologie mit dem Sie arbeiten ist groß. Sehr wichtig. 

Wir werden also in DynamoDB zu bekommen. DynamoDB ist AWS vollständig verwaltete NoSQL-Plattform. Was bedeutet vollständig verwaltete das? Es bedeutet, dass Sie nicht brauchen, wirklich Sorgen über irgendetwas. 

Sie kommen in, sagen, uns, ich brauche eine Tabelle. Es braucht so viel Kapazität. Sie drückte auf den Knopf, und wir Vorschrift die gesamte Infrastruktur hinter den Kulissen. Nun, das ist enorm. 

Weil, wenn Sie sprechen zur Skalierung eine Datenbank, NoSQL-Datenclustern an Maßstab Lauf Petabyte, Lauf Millionen Transaktionen pro Sekunde, diese Dinge sind nicht die kleinen Clustern. Wir reden hier Tausende von Fällen. Verwaltung von Tausenden von Fällen sogar virtuelle Instanzen, ist eine echte Schmerzen in den Hintern. Ich meine, über jedes Mal, wenn ein zu denken Betriebssystem-Patch kommt aus oder eine neue Version der Datenbank. Was bedeutet das um Ihnen operativ? Das heißt, Sie bekam 1200 Server, die aktualisiert werden müssen. Jetzt auch bei Automatisierung, das kann sehr lange dauern. Das kann eine Menge bewirken Betriebs Kopfschmerzen, weil ich vielleicht Leistungen nach unten. 

Wie ich diese Datenbanken zu aktualisieren, I vielleicht blau grün-Bereitstellungen zu tun wo ich implementieren und aktualisieren die Hälfte meines Knoten, und aktualisieren Sie die andere Hälfte. Nehmen Sie die denen. So Verwaltung der Infrastruktur Maßstab ist ungeheuer schmerzhaft. Und AWS nehmen diesen Schmerz aus ihm heraus. Und NoSQL-Datenbanken möglich außerordentlich schmerzhaft wegen der Art, wie sie zu skalieren. 

Skalieren horizontal. Wenn Sie eine größere NoSQL erhalten möchten Datenbank, mehr Knoten kaufen Sie. Jeder Knoten die Sie kaufen, einen weiteren Betriebs Kopfschmerzen. Also lassen Sie jemand anderes, das zu tun für Sie. AWS kann das tun. 

Wir unterstützen Dokumentschlüsselwerte. Jetzt haben wir nicht zu viel gehen in auf der anderen Karte. Es gibt eine Menge von verschiedenen Aromen von NoSQL. Sie sind alle Art von immer an dieser Stelle zusammen munged. Sie können an DynamoDB schauen und sagen, ja, wir sind beide ein Dokument und einen Schlüsselwert speichern diesen Punkt. Und Sie können die Eigenschaften argumentieren, eines über dem anderen. Für mich ist eine Menge wirklich sechs von einem halben Dutzend der anderen ist. Jede dieser Technologien ist ein feine Technik und eine feine Lösung. Ich würde nicht sagen MongoDB ist besser oder schlimmer als Couch, dann Cassandra, dann Dynamo, oder umgekehrt. Ich meine, das sind nur Optionen. 

Es ist schnell und es ist konsistent in jedem Maßstab. Also das ist eine der größten Boni, die Sie mit AWS zu bekommen. Mit DynamoDB ist die Fähigkeit, um einen niedrigen einstelligen erhalten Millisekunde Latenzzeit in jedem Maßstab. Das war ein Entwurfsziel des Systems. Und wir haben Kunden, die tun, Millionen von Transaktionen pro Sekunde. 

Jetzt werde ich über einige von denen gehen Anwendungsfälle in ein paar Minuten hier. Integrierter Zugriff control-- Wir haben, was wir nennen Identity Access Management, IAM oder. Es durchdringt jedes System, jeden Dienst, der AWS bietet. DynamoDB ist keine Ausnahme. Sie können den Zugriff steuern zu den DynamoDB Tabellen. In allen Ihren AWS-Konten von Definition von Zugriffs Rollen und Berechtigungen in der IAM-Infrastruktur. 

Und es ist ein wesentlicher und zentraler Bestandteil in was wir als Event Driven Programming. Nun ist dies ein neues Paradigma. 

ZIELGRUPPE: Wie ist Ihre Rate der wahren Positiven gegenüber falsche Negative auf Ihrem Zutrittskontrollsystem? RICK Houlihan: wahre Positive gegenüber falsche Negative? ZIELGRUPPE: Rückkehr, was Sie sollten Rückkehr? Im Gegensatz zu und wieder es nicht zurückkehrt, wenn es zu bestätigen sollten? 

RICK Houlihan: Ich könnte nicht sagen, dass. Wenn es irgendwelche Ausfälle seitens dass, Ich bin nicht die Person zu fragen, dass bestimmte Frage. Aber das ist eine gute Frage. Ich wäre neugierig, dass ich mich eigentlich. 

Und so dann wieder, neue Paradigma ist ereignisgesteuerte Programmierung. Das ist die Idee, dass man Bereitstellung komplexer Anwendungen, dass kann eine sehr, sehr hohen Maßstab zu betreiben ohne Infrastruktur auch immer. Ohne feste Infrastruktur auch immer. Und wir werden ein wenig sprechen über das, was das bedeutet, dass wir erhalten Sie mit dem nächsten paar Charts. 

Das erste, was wir tun ist werden wir über Tabellen zu sprechen. API-Datentypen für Dynamo. Und das erste, was Sie bemerken, wenn Sie dies zu betrachten, wenn du mit jeder Datenbank vertraut sind, Datenbanken haben wirklich zwei Arten von APIs Ich würde es nennen. Oder zwei Sätze von API. Einer von denen wäre, Administrator-API. 

Die Dinge, die sie kümmern die Funktionen der Datenbank. Konfigurieren des Speicher-Engine, Einrichten und Hinzufügen von Tabellen. Erstellen von Datenbank Kataloge und Instanzen. Diese things-- in DynamoDB Sie haben sehr kurze, kurze Listen. 

Also mit anderen Datenbanken, Sie könnten Dutzende sehen von Befehlen, der Verwaltungs Befehle zum Konfigurieren diese zusätzlichen Optionen. In DynamoDB Sie nicht brauchen, weil diejenigen, Sie nicht das System zu konfigurieren, das tun wir. Das einzige, was Sie tun müssen, ist, sagen Sie mir, welche Größe Tabelle brauche ich. Also ein sehr erhalten Sie begrenzte Anzahl von Befehlen. 

Sie erhalten eine Tabelle erstellen aktualisieren, Tisch, Löschen Table und Beschreiben Tabelle. Das sind die einzigen Dinge, Sie brauchen für DynamoDB. Sie brauchen nicht eine Speicher Motorkonfiguration. Ich weiß nicht um die Replikation zu kümmern. Ich weiß nicht um Splitter zu kümmern. 

Ich brauche keine Sorgen zu machen über jede von diesem Zeug. Wir tun alles für Sie. Also das ist eine riesige Menge an Overhead- das ist nur von Ihrer Platte angehoben. Dann haben wir die CRUD-Operatoren. CRUD ist etwas, was wir rufen Sie in der Datenbank, die ist Erstellen, Aktualisieren, Löschen Betreiber. Dies sind Ihre gemeinsamen Datenbankoperationen. Dinge wie Put-Artikel, erhalten Artikel, Update Artikel, Produkte zu löschen, Batch-Abfrage, zu scannen. Wenn Sie die gesamte Tabelle scannen möchten. Ziehen Sie alles, was vom Tisch. Eines der schönen Dinge über DynamoDB ist es erlaubt die parallele Scannen. So können Sie tatsächlich lassen Sie mich wissen, wie viele Themen, die Sie auf diesem Scan ausgeführt werden soll. Und wir können diese Threads laufen. Wir können drehen, dass scannen up über mehrere Threads so können Sie die gesamte Tabelle scannen Raum sehr, sehr schnell in DynamoDB. 

Die andere API wir haben, ist was wir als unsere Streams API. Wir gehen nicht, um zu sprechen, viel über dieses Recht jetzt. Ich habe einige Inhalte später bekam auf in das Deck zu diesem. Aber Streams ist wirklich ein running-- halten sie für die Zeit bestellt und Partitionsänderungsprotokoll. Alles, was geschieht, ist auf zeigt die Tabelle auf dem Stream. 

Jeder Schreibzugriff auf die Tabelle zeigt sich auf den Strom. Sie können diesen Stream zu lesen und Sie Sachen mit ihr machen kann. Wir werden darüber reden, was Arten von Dingen, die Sie zu tun mit den Dingen wie Replikation, Erstellen von Sekundärindizes. Alle Arten von wirklich cool Dinge, die Sie mit, dass zu tun. 

Datentypen. In DynamoDB unterstützen wir sowohl die Schlüssel Wert und Dokumentdatentypen. Auf der linken Seite des Bildschirms Hier haben wir unsere Grundtypen hat. Schlüsselwert-Typen. Dies sind Zeichenfolgen, Zahlen und Binärdateien. 

Also nur drei Grundtypen. Und dann können Sie Sätze von denen. Eines der schönen Dinge über NoSQL ist Sie können Arrays als Eigenschaften enthalten. Und mit DynamoDB können Sie Arrays enthalten der Grundtypen als root-Eigenschaft. 

Und dann gibt es die Dokumenttypen. Wie viele Menschen sind mit JSON vertraut? Ihr seid mit JSON so sehr vertraut? Es ist im Grunde JavaScript, Objekt, Notation. Es ermöglicht Ihnen, im Grunde definieren Sie eine hierarchische Struktur. 

Sie können eine JSON-Dokument speichern DynamoDB mit gemeinsamen Komponenten oder Bausteine, die zur Verfügung stehen in den meisten Programmiersprachen. Also, wenn Sie Java haben, sind Sie Blick auf Karten und Listen. Ich kann Objekte zu erstellen, die Karte. Eine Karte als Schlüsselwerte als Eigenschaften gespeichert. Und es könnte Listen haben Werte innerhalb dieser Eigenschaften. Sie können diese komplexen speichern hierarchische Struktur als ein einziges Attribut eines DynamoDB Artikel. 

So Tabellen in DynamoDB, wie die meisten NoSQL-Datenbanken, Tabellen Artikel. In MongoDB würden Sie, rufen Sie diese Dokumente. Und es würde die Couch Basis sein. Auch eine Dokumentendatenbank. Sie rufen diese Dokumente. Dokumente oder Artikel in der Attribute. Attribute können vorhanden sein oder nicht auf dem Artikel vorhanden. In DynamoDB, gibt es ein obligatorisches Attribut. Genau wie in einer relationalen Datenbank, Sie haben einen Primärschlüssel auf dem Tisch. 

DynamoDB hat das, was wir eine Raute-Taste aufrufen. Hash-Schlüssel muss eindeutig sein. Also, wenn ich definieren eine Hash-Tabelle, im Grunde, was ich sage, ist jedes Einzelteil versendet einen Hash-Schlüssel haben. Und jedes Hash-Schlüssel muss eindeutig sein. 

Jedes Einzelteil wird definiert von dieser einzigartigen Raute-Taste. Und es kann nur eine geben. Das ist in Ordnung, aber oft was die Menschen brauchen ist sie wollen, ist dieser Hash Taste, um ein bisschen mehr zu tun als nur eine eindeutige Kennung darstellen. Oft, dass Hash-Schlüssel verwenden wollen wir als Top-Level-Aggregation Eimer. Und die Art, wie wir das tun, ist durch Hinzufügen, was wir eine Reihe Taste aufrufen. 

Also, wenn es ist nur eine Hash- Tabelle, muss diese eindeutig sein. Wenn es ein Hash und Bereichstabelle, die Kombination aus dem Hash und dem Bereich muss eindeutig sein. Also denken Sie darüber auf diese Weise. Wenn ich ein Forum. Und die Form hat Themen, es hat Pfosten, und es Antworten bietet. 

So könnte ich einen Hash haben Schlüssel, der die Themen-ID ist. Und ich könnte haben eine Reichweite Schlüssel, das ist die Antwortkennung. So, wenn ich will alle zu bekommen Antworten für bestimmtes Thema, Ich kann einfach abfragen, den Hash. Ich kann nur sagen, mir alle die Elemente, die diesen Hash zu haben. Und ich werde jede Frage bekommen oder Post für diesen bestimmten Thema. Diese Top-Level-Aggregationen sind sehr wichtig. Sie unterstützen den primären Zugang Muster der Anwendung. Allgemein gesprochen, diese ist das, was wir tun wollen. Wir wollen, dass table-- wie Sie die Tabelle zu laden, wir auf die Datenstruktur wollen innerhalb der Tabelle derart, dass die Anwendung sehr schnell zurück diese Ergebnisse. Und oft die Art und Weise, dies zu tun ist diese Aggregationen wie wir pflegen legen Sie die Daten. Grundsätzlich sind wir der Verbreitung der Daten in den hellen Eimer, wie es kommt in. 

Bereich Tasten ermöglichen mich- Hash Tasten haben die Gleichheit sein. Als ich abfragen, einen Hash, muss ich sagen, geben Sie mir einen Hash, das entspricht. Als ich abfragen, eine Reihe, I kann sagen, gib mir einen Bereich das ist mit irgendeiner Art von Reichen Betreiber, die wir unterstützen. Geben Sie mir die Einzelteile für einen Hash. Ist es gleich, größer als, weniger als, es von Anfang an, dauert es zwischen diesen beiden Werten gibt es? Also diese Art von Bereichsanfragen dass wir immer interessiert. Jetzt eine Sache, über Daten, wenn Sie Zugriff auf die Daten, wenn aussehen Sie auf die Daten zugreifen, es ist immer zu einer Aggregation. Es geht immer um die Datensätze die zu dieser in Zusammenhang stehen. Gib mir alles, was hier that's-- alle die Transaktionen auf dieser Kreditkarte für den letzten Monat. Das ist eine Aggregation. 

Fast alles, was Sie in das zu tun Datenbank ist eine Art Aggregation. So in der Lage, in der Lage, zu definieren Diese Eimer und geben Ihnen diese Bereich Attribute abfragen kann, eingeschaltet sein, diese reichen Anfragen unterstützen viele, viele, viele Anwendungszugriffsmuster. 

Also die andere Sache, die Raute-Taste tut, ist, es gibt uns einen Mechanismus Um die Daten um zu verteilen. NoSQL-Datenbanken funktionieren am besten, wenn die Daten gleichmäßig über den Cluster verteilt. Wie viele Menschen vertraut sind mit Hashalgorithmen? Wenn ich sage, Hash und eine hashing-- weil ein Hash-Algorithmus ist eine Weise, in der Lage zu erzeugen, ein Zufallswert von einem bestimmten Wert. So dass in diesem besonderen Fall die Hash-Algorithmus wir laufen ist ND 5 basiert. 

Und wenn ich eine ID, und das ist mein Raute-Taste, habe ich 1, 2, 3. Wenn ich den Hash-Algorithmus, es wird wieder kommen und sagen: gut 1 gleich 7B 2 gleich 48, 3 entspricht CD. Sie sind alle über den Schlüsselraum zu verbreiten. Und warum machst du das? Denn das sorgt dafür, dass ich kann, setzen die Aufzeichnungen über mehrere Knoten. 

Wenn ich das tue schrittweise, 1, 2, 3. Und ich habe eine Hash-Bereich, läuft in diesem besonderen Fall, eine kleine Hash-Raum, es läuft von 00 bis FF, dann werden die Datensätze werden kommen in und sie gehen, um zu gehen 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. Was geschieht? Jeder Einsatz ist mit dem gleichen Knoten gehen. Sie sehen, was ich meine? 

Denn wenn ich den Raum aufgeteilt, Da breitete ich diese Aufzeichnungen über, und ich Partition, werde ich sagen, Partition 1 hat Schlüsselraum 0-54. Partition 2 ist 55-89. Partition 3 AA bis FF. Also, wenn ich mit linear inkrementiert IDs können Sie sehen, was passiert. 1, 2, 3, 4, 5, 6, alle Wege bis zu 54. So wie ich das Hämmern Datensätze in das System, alles endet gehen zu einem Knoten. 

Das ist nicht gut. Das ist ein Antipattern. In MongoDB sie dieses Problem haben wenn Sie nicht mit einem Raute-Taste. MongoDB haben Sie die Möglichkeit Hashing den Schlüsselwert. Sie sollten immer zu tun, dass, wenn Sie ein Erhöhen Hash sind Schlüssel in MongoDB, oder du wirst sein Nageln jeden Schreibvorgang in einem Knoten, und Sie werden als Einschränkung Ihre Schreibdurch schlecht. 

ZIELGRUPPE: Ist das A9 169 in dezimale? 

RICK Houlihan: Ja, es ist irgendwo um dort. A9, weiß ich nicht. Man müsste meinen binären erhalten Dezimal Rechner. Mein Gehirn funktioniert so nicht funktionieren. Publikum: Nur eine schnelle eins Ihrer Mongo Kommentare. So ist die Objekt-ID, die kommt nativ mit Mongo das tun? RICK Houlihan: Ist es das? Wenn du es angeben. Mit MongoDB, haben Sie die Möglichkeit. Sie können jedes Dokument in specify-- MongoDB muss ein Unterstrich-ID verfügen. Das ist der eindeutige Wert. 

In MongoDB können Sie festlegen, ob es zu hacken, oder nicht. Sie geben einfach die Option. Wenn Sie wissen, dass es zufällige, kein Problem. Sie brauchen nicht, das zu tun. Wenn Sie wissen, dass es nicht zufällig, dass es Inkrementieren, dann tun Sie den Hash. 

Nun ist die Sache über Hashing, sobald Sie hash a value-- und dies ist warum Hash-Schlüssel sind immer einzigartigen Anfragen, denn ich habe mich verändert der Wert, jetzt kann ich nicht eine Reihe Abfrage zu tun. Ich kann nicht sagen, das ist zwischen diesem oder jenem, da der Hash-Wert wird nicht entspricht dem Ist-Wert ist. Also, wenn Sie Hash, Schlüssel, es ist nur die Gleichstellung. Deshalb ist in DynamoDB Raute-Taste Anfragen sind immer nur Gleichberechtigung. 

So, jetzt in einem Bereich key-- wenn ich hinzufügen, dass Bereich Schlüssel, diese Schlüsselbereich zeichnet alle kommen und bekommen sie auf derselben Partition gespeichert. So sind sie sehr schnell, einfach abgerufen, denn dies ist der Hash, Dies ist der Bereich. Und Sie sehen, alles, was mit dem gleichen Hash wird auf der gleichen Partition Raum gelagert. Sie können diesen Bereich Schlüssel verwenden, um zu helfen suchen Sie Ihre Daten in der Nähe von seinem übergeordneten. Also, was soll ich eigentlich hier? Dies ist ein Ein-Beziehung. Die Beziehung zwischen einer Raute-Taste und der Bereich Schlüssel ist ein für viele. Ich kann mehrere Hash-Schlüssel haben. Ich kann nur mehrere Bereich Schlüssel in jeder Raute-Taste. 

Der Hash definiert die Muttergesellschaft, der Bereich definiert die Kinder. Sie sehen also, es gibt analoge hier zwischen der relationalen Konstrukt und die gleichen Typen von Konstrukte in NoSQL. Die Leute reden über NoSQL als relationale. Es ist nicht nicht relationalen. Daten stets Beziehungen. Diese Beziehungen nur unterschiedlich modelliert. Reden wir ein wenig wenig über Haltbarkeit. Wenn Sie zu DynamoDB schreiben, schreibt, immer drei Wege repliziert. Was bedeutet, dass wir drei von AZ. AZ sind Availability Zones. Sie können von einer Verfügbarkeit denke, Zone als Rechenzentrum oder eine Sammlung von Datenzentren. Diese Dinge sind geographisch voneinander isoliert, über verschiedene Störungszonen, über verschiedene Stromnetze und Auen. Ein Fehler in einem AZ nicht gehen, take down eine andere. Sie sind auch verbunden zusammen mit dark fiber. Es unterstützt eine Unter 1 Millisekunden Latenz zwischen AZs. So Echtzeit-Daten-Replikationen Lage in Mehr AZs. 

Und oft mehr AZ-Bereitstellungen erfüllen die hohen Anforderungen an die Verfügbarkeit der meisten Unternehmen und Organisationen. So DynamoDB verbreitet über drei AZs standardmäßig. Wir sind nur gehen, um Kenntnisse der Schreib wenn zwei dieser drei Knoten wieder kommen und sagen: Ja, ich habe es. Warum das? Weil auf der Leseseite sind wir nur werde Ihnen die Daten zurück zu geben, wenn wir es aus zwei Knoten. 

Wenn ich die Replikation über drei, und ich lese aus zwei, Ich bin immer garantiert mindestens einen zu haben von denen liest, um das zu sein die aktuellste Kopie der Daten. Das ist, was DynamoDB konsequente macht. Nun können Sie wählen, drehen diejenigen, konsistente abliest. In diesem Fall werde ich sagen, Ich werde nur von einem Knoten zu lesen. Und ich kann nicht garantieren, es wird um die aktuellsten Daten zu sein. 

Also, wenn ein Schreibvorgang kommen in, es hat noch nicht repliziert, Sie gehen, um diese Kopie zu erhalten. Das ist ein schließlich konsistente Lese. Und, was das ist, ist die Hälfte der Kosten. Das ist also etwas zu denken. Wenn Sie lesen aus DynamoDB und Sie Einrichten Ihrer Lesekapazität Einheiten, wenn Sie irgendwann wählen konsistente liest, es ist viel billiger, es ist über die Hälfte der Kosten. 

Und so es spart Ihnen Geld. Aber das ist Ihre Wahl. Wenn Sie eine konsistente Lese möchten oder ein eventuell konsistente Lese. Das ist etwas, das Sie wählen können. 

Lassen Sie uns über Indizes zu sprechen. So dass wir erwähnt, Top-Level-Aggregation. Wir haben Hash-Schlüssel hat, und wir haben Bereich Schlüssel bekam. Das ist schön. Und das ist für die Primärtabelle, I bekam einen Hash-Schlüssel, bekam ich einen Bereich drücken. 

Was bedeutet das? Ich habe ein Attribut hat, dass ich kann reich Abfragen ausführen. Es ist der Bereich drücken. Die anderen Attribute auf diesem Einzelteil-- Ich kann auf diese Attribute zu filtern. Aber ich kann Dinge wie nicht zu tun, ist es beginnt mit oder größer. 

Wie mache ich das? I einen Index erstellen. Es gibt zwei Arten von Indizes in DynamoDB. Ein Index ist wirklich Ein weiterer Blick auf den Tisch. Und die lokale Sekundärindex. 

Die erste werden wir darüber zu sprechen. So lokalen Sekundär koexistierten werden auf der gleichen Partition wie die Daten. Und als solche sind sie auf die gleichen physikalischen Knoten. Sie sind, was wir als konsequent. Bedeutung, werden sie erkennen die Schreib zusammen mit dem Tisch. Wenn der Schreib kommt, wir werden durch den Index zu schreiben. Wir schreiben an den Tisch, und dann werden wir erkennen. Also das ist konsistent. Sobald die Schreibfunktion wurde aus der Tabelle bestätigt, es ist garantiert, dass die lokalen Sekundärindex haben die gleiche Vision von Daten. Aber was sie erlauben Sie tun, ist definieren alternativen Bereich Tasten. 

Müssen den gleichen Hash verwenden Schlüssel als Primärtabelle, auf die, weil sie zusammen angeordnet gleichen Partition, und sie sind konsistent. Aber ich kann einen Index erstellen mit unterschiedlichen Bereichstasten. So zum Beispiel, wenn ich ein Hersteller dass hatte einen Rohteile Tisch kommen in. Und Rohteile kommen und sie von Montage aggregiert. Und vielleicht gibt es eine Rückrufaktion. 

Jeder Teil, der durch das machte wurde Hersteller nach diesem Datum, Ich muss von meiner Linie zu ziehen. Ich kann einen Index zu spinnen dass sein würde suchen, Aggregation zum Zeitpunkt der Herstellung von diesem Teil. Also, wenn meine Top-Level-Tisch war bereits durch den Hersteller gehasht, vielleicht war es auf einem Teil-ID I angeordnet, können Sie einen Index aus der Tabelle zu erstellen wie vom Hersteller gehasht und am Tag der Herstellung reichten. Und auf diese Weise, ich könnte sagen, alles, was wurde zwischen diesen Daten hergestellt, Ich brauche, um von der Linie zu ziehen. Also das ist eine lokale Sekundärindex. 

Diese haben die Wirkung von Begrenzen Sie Ihre Hash-Schlüsselraum. Weil sie koexistiert auf der gleichen Speicherknoten, sie die Raute-Taste zu begrenzen Raum bis 10 Gigabyte. DynamoDB, unter der Tische, wird partitionieren Ihre Tabelle alle 10 Gigabyte. Als Sie 10 Konzerte von Daten, die wir go [PHH], und wir einen weiteren Knoten hinzufügen. 

Wir werden uns nicht teilen Sie die LSI über mehrere Partitionen. Wir werden in der Tabelle aufgeteilt. Aber wir werden nicht teilen Sie die LSI. Also das ist etwas, wichtig zu verstehen ist, wenn Sie sehr tust, sehr, sehr großen Aggregationen, dann sind Sie gehen zu begrenzt sind bis 10 Gigabyte auf Ihrer LSIs. 

Wenn das der Fall ist, können wir benutzen globalen Secondaries. Globale Sekundär sind wirklich eine andere Tabelle. Es gibt sie völlig aus, um der Seite des Primärtabelle. Und sie erlauben Sie mir, eine zu finden völlig andere Struktur. So betrachten Sie es als Daten eingelegt wird in zwei verschiedenen Tabellen, strukturiert auf zwei verschiedene Arten. 

I eine völlig festlegen verschiedene Raute-Taste. I eine völlig festlegen anderen Bereich drücken. Und ich kann dies ausführen völlig unabhängig. In der Tat, ich habe bereitgestellt meine Lesefähigkeit und Schreibfähigkeit für meine globalen Sekundärindizes völlig unabhängig meiner Primärtabelle. Wenn ich diesen Index zu definieren, zu sagen, ich es, wie viel lesen und schreiben Kapazität, es wird sein mit. 

Und das ist getrennt von meinem Primärtabelle. Jetzt beide Indizes ermöglichen es uns, nicht nur definieren, Hash und Bereichstasten, aber sie ermöglichen es uns, projizieren zusätzliche Werte. Also, wenn ich lesen Sie den Index, und ich möchte eine Reihe von Daten zu bekommen, Ich brauche, um wieder in das Haupt gehen Tabelle, um die zusätzlichen Attribute zu erhalten. Ich kann diese zusätzliche Projekt Attribute in der Tabelle um die Zugriffsmuster zu unterstützen. Ich weiß, dass wir uns wahrscheinlich schon in einige wirklich, really-- Einstieg in das Unkraut hier auf etwas über dieses Thema. Jetzt habe ich, um aus diesem driften. 

ZIELGRUPPE: [unverständlich] --table Schlüssel meinte, war ein Hash? Die ursprüngliche Hash? Multi-Lamellen? 

RICK Houlihan: Ja. Ja. Der Tabellenschlüssel im Grunde weist zurück auf den Punkt. So ein Index ist ein Zeiger zurück zu die Original-Artikel auf dem Tisch. Jetzt können Sie sich dazu entscheiden, eine zu bauen Index, der nur über den Tabellenschlüssel, und keine anderen Eigenschaften. Und warum kann ich das tun? Na ja, vielleicht habe ich sehr große Gegenstände. 

Ich wirklich brauchen nur zu wissen, which-- meine Zugriffsmuster könnte sagen, welche Elemente diese Eigenschaft enthalten? Brauchen Sie nicht, um das Einzelteil zurückzubringen. Ich muss nur wissen, die Gegenstände enthalten ist. So können Sie Indizes bauen dass nur die Tabellenschlüssel. 

Aber das ist in erster Linie, was ein Index in der Datenbank ist. Es ist für die Möglichkeit, schnell erkennen, welche aufzeichnet, welche Zeilen, die Einträge in der Tabelle haben die Eigenschaften, die ich suche. 

GSIs, so wie funktionieren sie? GSIs grundsätzlich asynchron sind. Das Update kommt in die Tabelle, Tabelle wird dann asynchron aktualisiert alle Ihre GSIs. Aus diesem Grund sind GSIs schließlich konsequent. 

Es ist wichtig zu beachten, dass wenn Sie bauen GSIs, und Sie verstehen, Sie erstellen andere Dimension aggregation-- Jetzt sagen wir, ein gutes Beispiel Hier ist ein Hersteller. Ich glaube, ich könnte gesprochen haben ein Hersteller von medizinischen Geräten. Medizinproduktehersteller oft haben serialisierten Teile. Die Teile, die in zu gehen ein künstliches Hüftgelenk alle haben einen kleinen Seriennummer auf sie. Und sie könnten Millionen zu haben und Millionen und Milliarden von Teile in allen Vorrichtungen, die sie transportieren. Nun, unter aggregieren müssen sie unterschiedliche Abmessungen haben alle Teile in einer Anordnung, die ganze Teile, die hergestellt wurden auf einer bestimmten Linie, die alle die Teile, die kam in von einem bestimmten Hersteller an einem bestimmten Datum. Und diese Aggregationen manchmal Aufstehen in die Milliarden. 

So arbeite ich mit einigen der diese Jungs, die leiden weil sie die Schaffung diese ginormous Aggregationen in ihrem Sekundärindizes. Sie könnten ein Rohteile haben Tabelle, die nur als Hash geht. Jedes Teil hat eine eindeutige Seriennummer. Ich benutze die Seriennummer als Hash. Es ist wunderschön. Meine Rohdaten Tabelle verteilt überall in den Schlüsselraum. Meine [? schreiben ?] [? Einnahme?] ist genial. Ich nehme eine Menge Daten. Dann, was sie tun, ist sie ein GSI erstellen. Und ich sage, weißt du was, ich brauche, um zu sehen alle Teile von diesem Hersteller. Nun, ich bin mit einem Mal unter eine Milliarde Zeilen, und stopfen sie auf einen Knoten, denn wenn Ich aggregieren die Hersteller-ID als Hash, und Teilenummer als der Bereich, dann ganz plötzlich bin ich Putting eine Milliarde Teile in das, was Dieser Hersteller hat mich ausgeliefert. 

Das kann eine Menge bewirken der Druck auf die GSI, einmal, weil ich hämmerte einen Knoten. Ich setze alles Einsätze in einem Knoten. Und das ist ein echter Problemanwendungsfall. Nun, ich habe ein gutes Design Muster für die, wie Sie verhindern, dass sie. Und das ist eines der Probleme, dass ich arbeiten immer mit. Aber was passiert, ist die GSI könnten nicht genug Schreibkapazität der Lage sein, alle diejenigen zu drücken Zeilen in einem einzigen Knoten. Und was passiert, dann ist das Primär wird die Client-Tabelle, der primäre Tabellen wird gedrosselt werden weil der GSI nicht mithalten kann. Also mein Einsatzrate fallen für die Primärtabelle wie mein GSI versucht, Schritt zu halten. 

In Ordnung, so GSI, LSI, Welche soll ich verwenden? LSIs sind konsistent. GSI sind schließlich konsequent. Wenn es das ist OK, empfehle ich mit ein GSI, sie sind sehr viel flexibler. LSI als GSI modelliert werden. Und wenn die Datengröße pro Hash-Schlüssel in Ihre Sammlung von mehr als 10 Gigabyte, dann sind Sie gehen zu wollen, dass du verwenden GSI, weil es nur eine harte Grenze. 

In Ordnung, so Skalierung. Durchsatz in Dynamo DB, die Sie kann vorgesehen [unverständlich] Durchsatz auf einem Tisch. Wir haben Kunden, die haben bereitgestellt 60 billion-- machen 60 Milliarden Anfragen, regelmäßig laufen auf über eine Million Anfragen pro Sekunde auf unseren Tischen. Es gibt wirklich keine theoretische Limit, wie viel und wie schnell der Tisch kann in Dynamo DB laufen. Es gibt einige, weichen Grenzen auf Ihrem Konto dass wir setzen es in so dass Sie nicht verrückt. Wenn Sie mehr als wünschen daß kein Problem. Sie kommen uns sagen. Wir drehen Sie den Regler. 

Jedes Konto wird bis zu einem gewissen Maß begrenzt in jedem Service, nur von der Fledermaus so dass die Leute nicht verrückt holen sich in Schwierigkeiten. Keine Begrenzung in der Größe. Sie können beliebig viele setzen der Elemente auf einem Tisch. Die Größe einer Nachricht ist zu je 400 Kilobyte begrenzt, das wäre Element nicht die Attribute sein. Also die Summe aller Attribute auf 400 Kilobyte begrenzt. Und dann wieder, wir haben dass kleine LSI Thema mit der 10-Gigabyte-Grenze pro Hash. ZIELGRUPPE: kleine Zahl, ich vermisse was du mir erzählst, dass ist-- ZIELGRUPPE: Oh, 400 Kilobyte ist die maximale Größe pro Stück. So ein Element hat alle Attribute. So 400 k die Gesamtgröße dieser Artikel, 400 Kilobyte. So aller Attribute kombiniert, werden alle Daten das ist in all den Attributen, bis zu einer Gesamtgröße gewalzt, derzeit noch heute das Einzel Grenze ist 400 k. So Skalierung wieder erreicht durch Partitionierung. Der Durchsatz wird bereitgestellt auf Tabellenebene. Und es gibt wirklich zwei Knöpfe. Wir haben Kapazität lesen und Schreibfähigkeit. 

So dass diese angepasst werden unabhängig voneinander sind. RCU Maßnahme strikt im Einklang liest. OK, also, wenn du sagst, ich will 1000 RCU das sind streng im Einklang, davon konsistent liest. Wenn Sie sagen, ich will eventuelle einheitliche liest, Sie können Rückstellung 1.000 RCU, Sie gehen bis 2000 schließlich erhalten konsistente liest. Und die Hälfte des Preises für die, schließlich bestehen in liest. 

Wieder eingestellt unabhängig voneinander sind. Und sie haben die throughput-- Wenn Sie verbrauchen 100% Ihrer RCU, du wirst doch nicht um die Auswirkungen Verfügbarkeit Ihrer Rechte. So dass sie vollständig sind unabhängig voneinander sind. Na gut, so eine der Dinge, Ich kurz erwähnt wurde Drosselung. Throttling ist schlecht. Throttling zeigt schlechten keine SQL. Es gibt Dinge, die wir tun können, um zu helfen, Sie die Drosselung zu lindern, dass Sie erleben. Aber die beste Lösung um dies lassen Sie uns einen Blick auf, was du tust, denn gibt es ein Anti-Muster im Spiel hier. 

Diese Dinge, Dinge wie ungleichmäßige Workloads, Hotkeys, hot-Partitionen. Ich schlage eine bestimmte Taste Raum sehr hart, aus bestimmten Gründen. Warum mache ich das? Lassen Sie uns das herausfinden. Ich Misch meine heiße Daten mit kaltem Daten. Ich lasse meine Tabellen erhalten riesig, aber es gibt wirklich Nur eine Teilmenge des Daten das ist wirklich interessant für mich. So dass für Protokolldaten, beispielsweise eine Menge von Kunden, bekommen sie Log-Daten jeden Tag. Sie haben eine riesige Menge von Log-Daten. 

Wenn Sie gerade Dumping ganze Protokoll Daten in einem großen Tisch, im Laufe der Zeit dass Tisch geht massiv zu bekommen. Aber ich bin wirklich nur daran interessiert, letzten 24 Stunden, die letzten sieben Tage, die letzten 30 Tage. Unabhängig von der Zeitfenster, dass mich interessiert suchen für den Fall, dass mich stört, oder die Veranstaltung, die interessant ist für mich, das ist der einzige Zeitfenster, die ich brauche. Also warum bin ich Putting 10 Jahre Wert der Log-Daten in der Tabelle? Was das verursacht ist der Tisch das Fragment. 

Es wird riesig. Sie beginnt Ausbreiten über Tausende von Knoten. Und da Ihre Fähigkeit so gering ist, sind Sie tatsächlich bewerten Begrenzung auf jedem eine dieser Einzelknoten. Lassen Sie uns also beginnen, wie tun wir rollen die Tabelle über. Wie schaffen wir, dass die Daten ein wenig besser, diese Probleme zu vermeiden. Und was bedeutet das aussehen? Dies ist, wie das aussieht. Dies ist, was schlechte NoSQL aussieht. 

Ich bekam einen heißen Schlüssel hier. Wenn Sie auf der Seite hier, diese sind alle meine Partitionen. Ich habe 16 Partitionen hier auf dieser bestimmten Datenbank. Wir tun dies die ganze Zeit. Ich dies für die Kunden aller Zeiten. Es heißt die Heatmap. Heatmap sagt mir, wie du bist Zugriff auf Ihren Schlüsselraum. Und was das sagt mir ist , dass es einen bestimmten Hash- dass dieser Kerl mag ein sehr viel, weil er wirklich es schlagen, wirklich hart. 

Also das Blau ist schön. Wir mögen blau. Wir mögen es nicht rot. Red, wo der Druck wird bis zu 100%. 100%, jetzt wirst du gedrosselt werden. Also, wenn Sie keine roten Linien wie zu sehen this-- und es ist nicht nur Dynamo DB-- jedes NoSQL-Datenbank hat dieses Problem. Es gibt Anti-Muster, die können fahren diese Arten von Bedingungen. Was ich tue, ist, ich arbeite mit Kunden um diese Bedingungen zu lindern. 

Und was bedeutet das aussehen? Und das ist das Beste von Dynamo DB Durchsatz, aber es ist wirklich immer das Beste aus NoSQL. Dies ist nicht auf Dynamo beschränkt. Dies ist definitely-- I verwendet werden, um im Mongo zu arbeiten. Ich bin mit vielen NoSQL-Plattformen vertraut. Jeder dieser Typen hat heißer Schlüsselprobleme. Um das Beste aus jeder NoSQL erhalten Datenbank, die speziell Dynamo DB, Sie die Tabellen erstellen möchten wo die Raute-Taste Element eine große Anzahl von unterschiedlichen Werten, ein hohes Maß an Mächtigkeit. Weil das bedeutet, ich schreibe , viele verschiedene Eimer. 

Je mehr Eimer Ich bin schriftlich, desto wahrscheinlicher Ich bin, dass die Schreib-Last zu verteilen oder Lesen Sie laden sich über mehrere Knoten, desto eher bin ich ein Baby haben Hochdurchsatz auf dem Tisch. Und dann möchte ich die Werte zu sein ziemlich gleichmäßig über die Zeit angefordert und gleichmäßig zufällig wie möglich. Nun, das ist irgendwie interessant, weil ich kann nicht wirklich Kontrolle, wenn die Benutzer kommen. So genügt zu sagen, wenn wir zu verbreiten Dinge über den Schlüsselraum, wir wahrscheinlich besser in Form zu sein. 

Es gibt eine gewisse Zeit Lieferung dass du nicht gehst, in der Lage Kontrolle. Aber das sind wirklich die zwei Dimensionen, die wir haben, Raum, Zugänge gleichmäßig Verbreitung, Zeit, Anfragen anreisen gleichmäßig in der Zeit angeordnet. Und wenn diese beiden Bedingungen erfüllt sind, dann ist das, was es heißt, aussehen würde. Das ist viel schöner. Wir sind hier sehr glücklich. Wir haben eine sehr gleichmäßige Zugriffsmuster hat. Ja, vielleicht, Sie bekommen ein wenig Druck hin und wieder, aber nichts wirklich zu umfangreich. Also es ist erstaunlich, wie oft, wenn ich mit Kunden, dass erste Graph mit dem großen roten Bar und all das hässliche gelbe es ganz über dem Platz, wir mit der Ausübung zu erledigen nach ein paar Monaten der Re-Architektur, sie läuft exakt die gleichen sind Arbeitsbelastung an der exakt gleichen Last. Und das ist, wie es ist nun auf der Suche. Also, was Sie mit NoSQL bekommen, ist eine Datenschema, das absolut ist an die Zugriffsmuster gebunden. 

Und Sie können die Datenschema zu optimieren zu unterstützen, dass der Zugang Muster. Wenn Sie dies nicht tun, dann wirst du um diese Art von Problemen zu sehen mit den Hotkeys. 

ZIELGRUPPE: Nun, unweigerlich einige Orte gehen wärmer zu sein als andere. 

RICK Houlihan: Immer. Immer. Ja, ich meine es gibt immer a-- wieder, gibt es einige Entwurfsmuster werden wir durchkommen das wird, wie Sie befassen sprechen mit diesen super großen Aggregationen. Ich meine, ich habe, sie zu haben, wie gehen wir damit um? Ich habe eine ziemlich gute Anwendungsfall dass wir über zum reden. 

In Ordnung, so lassen Sie uns sprechen über einige Kunden jetzt. Diese Jungs sind AdRoll. Ich weiß nicht, wenn Sie vertraut mit AdRoll. Sie sehen sie wahrscheinlich eine Menge auf dem Browser. Sie sind ad re-Targeting, sie sind die größte Anzeige Re-Targeting-Geschäfts dort draußen. Sie normalerweise regelmäßig überfahren 60 Milliarden Transaktionen pro Tag. Sie tun mehr als einer Million Transaktionen pro Sekunde. Sie haben eine ziemlich einfache Tisch bekamen Struktur, der verkehrsreichste Tabelle. Es ist im Grunde nur ein Raute-Taste wird das Cookie, der Bereich ist die demografische Kategorie, und dann das dritte Attribut ist die Punktzahl. 

So haben wir alle Cookies unsere Browser von diesen Jungs. Und wenn Sie ein zu gehen teilnehmenden Händler, sie im Grunde punkten Sie stoßen verschiedenen demografischen Kategorien. Wenn Sie auf eine Website gehen und Sie sagen, ich möchte diese ad-- sehen oder im Grunde Sie nicht sagen, dass-- aber wenn Sie auf die Website gehen sie sagen, Sie um diese Werbung sehen wollen. Und sie gehen bekommen, dass ad von AdRoll. AdRoll sieht man auf ihren Tisch. Sie finden Ihre Cookie. Die Inserenten erzählen ihnen: Ich will jemanden Wer ist im mittleren Alter, 40-jähriger Mann, in den Sport. Und sie punkten Sie in diesen Demografie und sie auch nicht entscheiden das ist eine gute Anzeige für Sie. 

Jetzt haben sie eine SLA mit haben ihre Werbeanbieter Sub-10 Millisekunden liefern Antwort auf jede einzelne Anfrage. So dass sie mit Dynamo DB für diese. Sie schlagen uns Millionen Anfragen pro Sekunde. Sie sind in der Lage, alle tun ihr Lookups, Triage alles, Daten, und erhalten, dass Add Link zurück zu, dass Anzeigen unter 10 Millisekunden. Es ist wirklich ziemlich phänomenal Umsetzung die sie haben. 

Diese Jungs actually-- das sind die Jungs. Ich bin mir nicht sicher, ob es diese Jungs. Könnten diese Jungs zu sein. Im Grunde erzählt us-- nein, ich glaube nicht, dass sie es waren. Ich glaube, es war jemand anderes. Ich war mit einer Arbeits Kunden, die mir sagte, , dass jetzt, dass sie schon Dynamo DB gegangen, sie sind mehr Geld für Snacks für ihre Entwicklungsteam jeden Monat als sie auf ihre Datenbank zu verbringen. So ist es gebe Ihnen ein Idee der Kosteneinsparungen dass Sie in Dynamo DB erhalten können, ist riesig. In Ordnung, dropcam ein anderes Unternehmen. Dies ist eine Art Kerl von-- wenn Sie denken, des Internet der Dinge, dropcam ist im Grunde Internet-Sicherheit Video. Sie stellen Ihre Kamera gibt. Kamera verfügt über einen Bewegungsmelder. Jemand kommt, löst einen Cue-Punkt. Kamera startet die Aufnahme für eine Weile, bis er keine Bewegung mehr festzustellen. Legt das Video auf dem Internet. 

Dropcam ein Unternehmen, das ist war, grundsätzlich Dynamo DB schaltet denn sie erlebten enorme Wachstumsschmerzen. Und was sie sagte uns, plötzlich Petabyte an Daten. Sie hatten keine Ahnung ihren Dienst so erfolgreich zu sein. Weitere eingehende Video über YouTube ist es, was diese Jungs bekommen. Sie nutzen DynamoDB alle der Spur Metadaten auf alle ihre Video wichtigsten Punkte. 

So dass sie S3 Eimer schieben sie haben alle binären Artefakte in. Und dann haben sie Dynamo DB Datensätze, weisen Menschen auf jene S3 drei Objekte. Wenn sie benötigen, um in einem Video sehen, sie sehen den Datensatz in Dynamo DB. Sie klicken Sie auf den Link. Sie öffnen Sie das Video von S3. Also das ist eine Art, wie das aussieht. Und das ist gerade von ihrem Team. 

Dynamo DB reduziert ihre Lieferzeit für Video-Events von fünf bis 10 Sekunden. In ihrem alten relationalen Speicher, sie müssen verwendet werden, um zu gehen, und führen mehrere komplexe Abfragen zu Figur aus denen Videos nach unten ziehen, auf weniger als 50 Millisekunden. Also, es ist erstaunlich, erstaunlich, wie viel Leistung Sie bekommen können, wenn Sie zu optimieren und Sie stimmen der zugrunde liegenden Datenbank um die Zugriffsmuster zu unterstützen. Halfbrick, diese Jungs, was ist es, Fruit Ninja ich schätze, ist ihre Sache. Dass alle Läufe auf Dynamo DB. Und diese Jungs, sie sind eine großartige Entwicklungs-Team, große Entwicklung Shop. 

Kein gutes ops Team. Sie hatten nicht viel Betriebsressourcen. Sie wurden zu kämpfen versuchen, zu halten ihre Anwendungsinfrastruktur up und läuft. Sie kamen zu uns. Sie sahen, dass Dynamo DB. Sie sagten, das ist für uns. Sie bauten ihr ganzes Anwendungs-Framework auf sie. Einige wirklich nette Kommentare hier aus dem Team von ihrer Fähigkeit jetzt auf den Aufbau konzentrieren das Spiel und nicht dass die Aufrechterhaltung Infrastruktur, die wurde immer eine enorme Menge Overhead für ihr Team. Also das ist etwas, das dass-- profitieren, dass Sie von Dynamo DB zu bekommen. 

Also gut, immer in Datenmodellierung hier. Und wir sprachen ein wenig über Dieses 1-1, eins zu mehreren, und viele, viele Typ-Beziehungen. Und wie sehen Sie halten die in Dynamo. In Dynamo DB verwenden wir Indizes, allgemein gesprochen, die Daten von drehen einem Aromastoff zu dem anderen. Hash-Schlüssel, Bereichstasten und Indizes. 

In diesem besonderen beispielsweise als die meisten Staaten eine Genehmigungspflicht, dass nur eine Lizenz Fahrer pro Person. Du kannst nicht gehen, um zwei Fahrer erhalten Lizenzen im Bundesstaat Boston. Ich kann es nicht in Texas. Das ist irgendwie so wie es ist. Und so an der DMV bieten wir Lookups, wir nachschlagen möchten den Führerschein durch die Sozialversicherungsnummer. Ich möchte sehen die Benutzerdetails über Lizenznummer des Fahrers. 

So könnten wir Tabelle eines Benutzers haben, dass hat eine Raute-Taste auf der Seriennummer, oder Sozialversicherungsnummer, und verschiedene Attribute auf das Element definiert. Jetzt auf die Tabelle I könnte eine GSI festlegen, dass Flips, dass rund um das sagt Ich möchte ein Hash-Schlüssel auf dem Lizenz-und dann alle anderen Elemente. Wenn ich nun zur Abfrage und finden die Lizenznummer für jede gegebene Sozial Valorennummer, kann ich Abfrage der Haupttabelle. 

Wenn ich abfragen, und ich möchte, um die soziale Sicherheit zu erhalten Nummer oder andere Attribute, die von einem Lizenznummer, kann ich die GSI abzufragen. Das Modell ist, dass man einer Beziehung. Nur eine sehr einfache GSI, Flip die Dinge um. Nun, sprechen über ein bis viele. Eine von vielen ist im Grunde Ihre Hash-Bereich drücken. Wo wir bekommen eine Menge mit diesem Anwendungsfall ist Monitordaten. Monitor-Daten in Standard Intervall, wie Internet der Dinge. Wir alle diese immer Aufzeichnungen kommen in all der Zeit. 

Und ich möchte, um alle Messwerte zu finden zwischen einem bestimmten Zeitraum. Es ist eine sehr häufige Abfrage in Monitoring-Infrastruktur. Der Weg dazu ist, ein zu finden einfache Tabellenstruktur, ein Tisch. Ich habe ein Gerät Messungen Tisch bekamen mit einer Raute-Taste auf der Geräte-ID. Und ich habe eine Reihe Taste auf der Zeitstempel, oder in diesem Fall, das Epos. Und das erlaubt mir auszuführen Komplex Abfragen für diesen Bereich Schlüssel und kehren die Datensätze, bezüglich zu dem Ergebnis, gesetzt, dass ich suche. Und es baut, dass man n-Beziehung in der Haupttabelle mit Hilfe der Raute-Taste, Bereich Schlüsselstruktur. 

Also das ist Art gebaut in die Tabelle in Dynamo DB. Als ich definieren eine Hash- und Reichweite t Tisch, ich bin Definieren einer Eins in Beziehung. Es ist eine Eltern-Kind-Beziehung. 

Lassen Sie uns über viele sprechen zu viele Beziehungen. Zu diesem speziellen Beispiel wieder, wir werden GSI verwenden. Und lassen Sie uns darüber sprechen, Gaming Szenario, in dem ich einen bestimmten Benutzer. Ich möchte herausfinden, alle Spiele, die er für oder spielen in registriert. Und für einen bestimmten Spiel, ich wollen alle Benutzer zu finden. So, wie ich das tun? Mein Benutzerspieltisch, ich werde einen Hash-Schlüssel von Benutzer-ID haben und eine Reihe Schlüssel des Spiels. 

So kann ein Benutzer mehrere Spiele zu haben. Es ist ein one to many Beziehung zwischen der Benutzer und die Spiele, wenn er spielt. Und dann auf der GSI, Ich werde diese rund kippen. Ich werde auf das Spiel und hash Ich werde auf dem Benutzerbereich. Also, wenn ich das ganze zu bekommen das Benutzer-Spiel spielt in, Ich werde die Haupttabelle abfragen. Wenn ich will, um alle Nutzer erhalten dass das Spielen sind ein bestimmtes Spiel, I Abfrage der GSI. So können Sie sehen, wie wir das tun? Sie bauen die diese GSI, die Unterstützung Anwendungsfall ist die Anwendung, die Zugriff Muster, die Anwendung. 

Wenn ich die Abfrage auf diese Dimension, lassen me erstellen einen Index für diese Dimension. Wenn ich nicht, es ist mir egal. Und je nach Anwendungsfall, I können Sie den Index benötigen, oder ich vielleicht nicht. Wenn es sich um eine einfache, viele, Primärtabelle ist in Ordnung. Wenn ich, diese vielen tun müssen viele von, oder muss ich ein, um diejenigen zu tun, dann vielleicht ich brauche zum zweiten der Index. Also es hängt alles von was ich versuche zu tun, und was ich versuche geführt, um zu bekommen. 

Wahrscheinlich werde ich nicht, zu verbringen, viel Zeit im Gespräch über Dokumente. Diese bekommt ein wenig, wahrscheinlich, tiefer als wir brauchen, um in zu gehen. Reden wir ein bisschen über reiche Abfrageausdruck. So in Dynamo DB wir die Fähigkeit zu schaffen was wir als Projektions Ausdrücke. Projection Ausdrücke sind einfach Kommissionierung die Felder oder die Werte dass Sie anzeigen möchten. OK, also habe ich eine Auswahl treffen. Ich mache eine Abfrage gegen Dynamo DB. Und ich sage, Sie wissen, was, Show mir nur die Fünf-Sterne-Bewertungen für diese spezielle Produkt. Also das ist alles was ich will, um zu sehen. Ich will nicht, um alle zu sehen andere Attribute der Reihe, Ich will einfach nur das zu sehen. Es ist wie in SQL, wenn Sie sagen wählen Stern oder vom Tisch, Sie erhalten alles, was. Als ich select name from sagen Tisch, ich bekomme nur ein Attribut. Es ist die gleiche Art der Sache in Dynamo DB oder andere NoSQL-Datenbanken. Filterausdrücke erlauben Sie mir, Grundsätzlich schneiden die Ergebnismenge nach unten. Also mache ich eine Anfrage. Abfrage kann mit 500 Einzelteile zurück zu kommen. Aber ich die Einzelteile wünschen nur, dass ein Attribut, die das sagt. OK, also lasst uns herausfiltern, die Elemente , die nicht übereinstimmen, dass bestimmte Abfrage. So haben wir Filterausdrücke. 

Filterausdrücke können auf jedem Attribut ausgeführt werden. Sie sind nicht wie Bereichsabfragen. Heben Sie Abfragen sind selektiver. Filterabfragen erfordern mich zu gehen Erhalte die komplette Ergebnismenge und dann schnitzen, die Daten, die ich nicht wollen. Warum ist das wichtig? Da las ich sie alle. In einer Abfrage, werde ich zu lesen und es geht um ein Riese über Daten sein. Und dann bin ich los schnitzen, was ich brauche. Und wenn ich nur Carving ein paar Zeilen, dann ist das OK. Es ist nicht so ineffizient. 

Aber wenn ich lese einen ganzen Haufen von Daten, nur zu schnitzen, ein Einzelteil, dann werde ich, besser zu sein off mit einer Bereichsabfrage, denn es ist viel selektiver. Es wird mir eine Menge, um zu speichern Geld, weil ich für die Lese zu zahlen. Wo die Ergebnisse, die zurückkommt Kreuz, das Draht könnte kleiner sein, aber ich zahle für die Lese. So verstehen, wie Sie bekommen die Daten sind. Das ist in Dynamo DB sehr wichtig. 

Bedingte Ausdrücke, das ist was Sie könnten optimistische Sperren nennen. Update IF EXISTS, oder wenn dieser Wert entspricht, was ich geben. Und wenn ich einen Zeitstempel für ein Rekord, könnte ich die Daten zu lesen. Ich könnte diese Daten zu ändern. Ich könnte schreiben zu gehen, dass Daten wieder in die Datenbank. Wer hat den Rekord verändert, der Zeitstempel geändert haben könnten. Und das, wie mein bedingte Update Update könnte sagen, wenn der Zeitstempel entspricht dieser. Oder das Update wird, weil jemand nicht den Rekord in der Zwischenzeit aktualisiert. 

Das ist, was wir nennen das optimistische Sperren. Es bedeutet, dass jemand können kommen und zu verändern, und ich werde es zu erkennen wenn ich zurück zu schreiben. Und dann kann ich wirklich lesen, dass Daten und sagen, oh, änderte er dies. Ich muss das erklären. Und ich kann die Daten in meinem ändern aufzeichnen und gelten ein weiteres Update. So dass Sie diese inkrementelle fangen kann Updates, die zwischen der Zeit auftreten, dass Sie die Daten und das Lesen Zeit, die Sie vielleicht die Daten zu schreiben. 

Publikum: Und das Filter Ausdruck bedeutet tatsächlich nicht in der Anzahl oder nicht-- 

[Zwischen Stimmen] RICK Houlihan: Ich will nicht bekommen zu viel in diese. Dies ist ein reserviertes Schlüsselwort. Das Pfund Ansicht ist ein reserviertes Stichwort in Dynamo DB. Jede Datenbank verfügt über eine eigene vorbehalten Namen für Sammlungen, die Sie nicht verwenden können. Dynamo DB, wenn Sie angeben, Pfund vor diesem, Sie können diese Namen oben zu definieren. Dies ist eine referenzierte Wert. Es ist wahrscheinlich nicht die beste Syntax haben dort für diese Diskussion, weil es in einigen real-- bekommt Ich hätte reden mehr etwa, dass auf einer tieferen Ebene. 

Aber es genügt zu sagen, dies könnte sein Abfrage scannen, wo sie views-- noch pound Blick größer als 10. Es ist ein numerischer Wert, ja. Wenn Sie möchten, können wir reden dass nach der Diskussion. Na gut, so dass wir in immer einige Szenarien, in Best Practices wohin wir gehen, um zu sprechen über einige apps hier. Was sind die Anwendungsfälle für Dynamo DB. Was sind das Design Muster in Dynamo DB. 

Und die erste, die wir zu gehen Vortrag über das Internet der Dinge. So erhalten wir eine Menge von-- Ich schätze, was es-- mehr als 50% der Verkehr auf dem Internet heutzutage tatsächlich von Maschinen erzeugt wird, automatisierte Prozesse, nicht durch den Menschen. Ich meine, diese Sache, die da Sie herumtragen in der Tasche, wie viele Daten, dass das Ding tatsächlich das Senden der Umgebung ohne dich zu wissen, es ist absolut erstaunlich. Ihr Standort, Informationen darüber, wie schnell du gehst. Wie beurteilen Sie die Google-Karte Arbeiten denken wenn sie sagen, was der Verkehr ist. Es ist, weil es Millionen und Millionen von Menschen herumfahren mit Handys, die senden, Daten der ganzen Ort, die ganze Zeit. So ist eines der Dinge über diese Art der Daten das kommt in, Überwachungsdaten, melden Daten, die Zeitreihendaten, es ist in der Regel nur interessant für ein wenig Zeit. Nach dieser Zeit ist es nicht so interessant. Also sprachen wir über, lassen Sie sich nicht diese Tabellen wachsen, ohne Grenzen. Die Idee dabei ist, dass vielleicht ich bekam 24 Stunden im Wert von Veranstaltungen in meinen heißen Tisch. Und das heiße Tisch sein wird bei einer sehr hohen Rate bereitgestellt wird, denn es nimmt eine Vielzahl von Daten. Es nimmt eine Menge von Daten in und ich lese es sehr. Ich habe eine Menge Betriebs bekam Abfragen dieser Daten läuft. 

Nach 24 Stunden, hey, du Weißt du was, ist mir egal. Also vielleicht jede Mitternacht I Roll meinem Tisch auf eine neue Tabelle und ich deprovisionieren diese Tabelle. Und ich nehme die RCU und WCU ist nach unten, weil 24 Stunden später Ich bin nicht läuft so viele Abfragen dieser Daten. Also werde ich um Geld zu sparen. Und vielleicht 30 Tage später ich nicht einmal, um über alles zu kümmern. Ich konnte die WCU nehmen den ganzen Weg hinunter zu eins, weil Sie wissen, was, es ist nie wieder geschrieben zu werden. Die Daten sind 30 Tage alt sind. Es ändert sich nie. 

Und es ist fast nie zu lesen bekommen, also lassen Sie uns nehmen Sie nur, dass RCU bis zu 10. Und ich bin sparen eine Menge Geld auf diese Daten und nur die Zahlung für meine heiße Daten. Also das ist die wichtige Sache zu sehen an, wenn Sie an einer Zeitreihe zu suchen Daten, die in der Lautstärke. Dies sind Strategien. Nun konnte ich lass es einfach alle zum selben Tisch und lassen Sie diese Tabelle zu wachsen. Schließlich bin ich zu gehen siehe Performance-Probleme. Ich werde anfangen müssen, die archiviert werden einige dieser Daten vom Tisch, was nicht. 

Lassen Sie uns besser gestalten Sie Ihre Anwendung so dass Sie auf diese Weise richtig zu betreiben. So ist es nur automatische im Anwendungscode. Um Mitternacht jede Nacht es rollt die Tabelle. Vielleicht, was ich brauche ist ein Schiebe Fenster von 24 Stunden nach Daten. Dann auf einer regelmäßigen Basis, ich bin ruft Daten vom Tisch. Ich Trimmen Sie es mit ein Cron-Job und ich setzen sie auf diese anderen Tabellen, was auch immer du brauchst. Also, wenn ein Rollover funktioniert, das ist toll. Wenn nicht, schneiden Sie es. Aber lassen Sie uns zu halten, dass heiße Daten weg von Ihrem kalten Daten. Es wird Ihnen eine Menge Geld zu sparen und Ihren Fahrplan Mehr Durchführung. Also das nächste, was wir reden etwa ist Produktkatalog. Produktkatalog ist ziemlich häufig Anwendungsfall. Dies ist tatsächlich eine sehr häufige Muster dass wir in einer Vielzahl von Dingen zu sehen. Wissen Sie, für Twitter beispielsweise eine heiße Tweet. Jeder kommt und Grabbing dass tweet. Produktkatalog, bekam ich einen Verkauf. Ich bekam einen heißen Verkauf. Ich bekam 70.000 Anfragen pro zweite Kommen für ein Produkt Beschreibung aus meinem Produktkatalog. Wir sehen dies auf den Einzelhandel Betrieb ganz ein bisschen. Wie können wir damit umgehen? Es gibt keinen Weg, damit umzugehen. Alle meine Benutzer sehen wollen, das gleiche Stück von Daten. Sie kommen in, gleichzeitig. Und sie sind alle so dass Anfragen für den gleichen Teil der Daten. Das gibt mir die Hotkey, dass big red Streifen auf meinem Diagramm, das wir nicht mögen. Und das ist, wie das aussieht. Also über meine Schlüsselraum Ich erhalte in den Verkauf Artikel gehämmert. Ich bekomme nichts anderswo. 

Wie kann ich dieses Problem zu lindern? Nun, wir lindern dies mit Cache. Cache, setzen Sie im Grunde eine In-Memory- Trennwand vor der Datenbank. Wir haben es geschafft [Unverständlich] Cache, wie Sie können Sie Ihre eigenen Cache einrichten, [unverständlich] Cache [? d,?], was auch immer Sie wollen. Setzen Sie, dass sich vor der Datenbank. Und auf diese Weise können die Daten speichern können von diesen Hot-Keys in diesem Cache Raum und durch den Cache zu lesen. 

Und dann die meisten Ihrer liest beginnen, wie diese. Ich habe alle diese Cache-Treffer hier und ich habe nichts los hier unten weil Datenbank befindet sich hinter der Sitz Cache und die Lesevorgänge nie durchkommen. Wenn ich die Daten in das ändern Datenbank, habe ich, um den Cache zu aktualisieren. Wir können etwas verwenden wie Dämpfe, das zu tun. Und ich werde erklären, wie das funktioniert. In Ordnung, Messaging. E-Mail, die wir alle nutzen E-Mail. 

Das ist ein ziemlich gutes Beispiel. Wir haben eine Art von Nachrichten Tisch bekamen. Und wir haben Eingang und Ausgang. Dies ist, was die SQL würde sehen aus wie, dass Posteingang zu bauen. Wir Art verwenden die gleiche Art der Strategie, GSI, verwenden GSI für meinen Posteingang und Postausgang. Also habe ich rohe Nachrichten kommen in meinem Tisch Nachrichten. Und der erste Ansatz dazu könnte sein, sagen, OK, kein Problem. Ich habe Roh Nachrichten bekam. Nachrichten kommen [unverständlich], Message-ID, das ist toll. Das ist mein eindeutigen Hash. Ich werde zu erstellen zwei GSI, ein für meinen Posteingang, eine für meine Postausgang. Und das erste, was ich tun werde, ist werde ich sagen, meine Hash-Schlüssel werde der Empfänger und Ich werde an dem Tag zu arrangieren. Das ist fantastisch. Ich habe meine schöne Aussicht hier. Aber es gibt ein kleines Problem hier. Und Sie in diese eingefahren relationale Datenbanken als auch. Sie nannten vertikal Partitionierung. Sie möchten Ihre Big Data zu halten weg von Ihrem wenig Daten. 

Und der Grund dafür ist, weil ich muss gehen lesen Sie die Einzelteile, um die Attribute zu erhalten. Und wenn mein Körper sind alle hier, dann nur ein paar Artikel zu lesen wenn meine Körperlänge ist Mittelung jeweils 256 Kilobyte, die Mathematik wird ziemlich hässlich. Also sage ich will Davids Posteingang lesen. Davids Posteingang verfügt über 50 Artikel. Die mittlere und die Größe beträgt 256 Kilobyte. Hier ist meine Umtauschverhältnis für RCU ist vier Kilobyte. 

OK, lassen Sie uns mit zu gehen schließlich einheitliche liest. Ich bin immer noch essen 1600 RCU nur um Davids Posteingang lesen. Autsch. OK, jetzt zu denken lassen darüber, wie die Anwendung funktioniert. Wenn ich in einer E-Mail App und Ich freue mich auf meinem Posteingang, und ich freue mich auf den Körper von jeder Nachricht, nein, ich freue mich auf den Zusammenfassungen. Ich freue mich auf nur die Kopfzeilen. Also lasst uns bauen eine Tabellenstruktur dass sieht eher aus wie, dass. 

Also hier ist die Information dass meine Arbeitsabläufe. Es ist in meinem Posteingang GSI. Es ist das Datum, Absender, das Subjekt, und dann die Nachrichten-ID, die Punkte zurück zum Tisch Nachrichten wo ich den Körper zu bekommen. Nun, diese würden Datensatz-IDs sein. Sie würden auf den Punkt zurück Artikel-IDs auf dem Dynamo DB-Tabelle. Jeder Index immer creates-- hat immer das Element ID als Teil von--, dass kommt mit dem Index. 

Gut. Publikum: Es erzählt sie, wo sie gespeichert sind? RICK Houlihan: Ja, es sagt exactly-- das ist genau das, was sie tut. Er sagt, hier ist meine Wieder Rekord. Und es wird es zurück zu meiner Wiederrekord verweisen. Genau. OK, so jetzt meinem Posteingang ist eigentlich viel kleiner. Und dies tatsächlich unterstützt der Arbeitsablauf eines E-Mail-App. So meinem Posteingang, ich klicken. Ich entlang gehen und ich auf die Nachricht klicken, das ist, wenn ich gehen müssen den Körper, weil ich zu gehen gehen Sie zu einer anderen Ansicht. Also, wenn Sie über MVC Art von denken, Rahmen, Model View Controller. 

Das Modell enthält die Daten, die die Ansicht Bedürfnisse und die Steuereinrichtung wirkt mit. Als ich den Rahmen zu ändern, wenn Ich die Perspektive, es ist OK, um wieder auf dem Sprung Server und wieder zu bevölkern das Modell, weil das, was der Benutzer erwartet. Als sie Ansichten zu ändern, das ist, wenn können wir wieder in der Datenbank zu gehen. So E-Mail, klicken Sie auf. Ich interessiere mich für den Körper. Hin-und Rückfahrt. Geh und hol den Körper. 

Ich lese sehr viel weniger Daten. Ich bin nur das Lesen der Gremien, David muss, wenn er sie braucht. Und ich bin nicht im Jahr 1600 zu brennen RCU uns einfach an seine Posteingang zu zeigen. So, jetzt dass-- dies ist der Weg dass LSI oder GSI-- Es tut mir leid, GSI, funktionieren würde. Wir haben unsere Hash auf den Empfänger hat. Wir haben den Bereich Schlüssel am Tag bekam. Und wir haben die projizierten Attribute erhielt dass wir nur, um die Ansicht zu unterstützen. 

Wir drehen, dass für den Postausgang. Hash am Sender. Und im Grunde haben wir das sehr schön, sauber Blick. Und es ist basically-- wir Lassen Sie sich diese schönen Nachrichten Tabelle, die sehr schön, weil verbreitet ist es ist nur Hash, Hash Message-ID. Und wir haben zwei Indizes, ausgeschaltet sind der Tabelle zu drehen. In Ordnung, so Idee hier ist nicht halten die Big Data und dieses kleine Daten zusammen. Partitionieren vertikal, partitionieren diese Tabellen. Keine Daten zu lesen müssen Sie nicht auf. In Ordnung, Gaming. Wir alle mögen Spiele. Zumindest, wie ich spiele dann. So einige der Dinge, dass wir uns mit, wenn wir über Spiel denken, nicht wahr? Gaming in diesen Tagen, vor allem Mobil Gaming, dreht sich alles um Denken. Und ich werde hier ein Drehen wenig weg von DynamoDB. Ich werde bringen ein Teil der Diskussion rund um einige der andere AWS-Technologien. 

Aber die Idee, über Gaming ist zu denken, etwa in Bezug auf die APIs, APIs, die sind, allgemein gesprochen, HTTP und JSON. Es ist, wie Handy-Spielen Art interagieren mit ihren hinteren Enden. Sie machen JSON Buchung. Sie erhalten Daten, und es ist alles, allgemein gesprochen, in schöner JSON APIs. 

Dinge wie zu Freunden, zu erhalten Das Leaderboard, Daten austauschen, Nutzergenerierte Inhalte, Druckboden bis zu dem System, diese sind Arten der Dinge dass wir tun werden. Binary Asset-Daten, diese Daten vielleicht nicht in der Datenbank zu sitzen. Dies könnte in einem sitzen Objektspeicher, nicht wahr? Aber die Datenbank zu gehen Ende erzählt das System, erzählt die Anwendung wohin sie gehen, um es. Und unvermeidlich, Multiplayer- Server, Back-End-Infrastruktur, und für Hoch ausgelegt Verfügbarkeit und Skalierbarkeit. Das sind Dinge, die wir alle wollen, in der Gaming-Infrastruktur heute. 

Werfen wir also einen Blick auf , wie das aussieht. Haben Sie einen Core Backend, sehr einfach. Wir haben ein System, hier bekam mehrere Availability Zones. Wir sprachen über AZs als being-- denken von ihnen als getrennte Rechenzentren. Mehr als ein Rechenzentrum pro AZ, aber das ist OK, man denke nur an sie als separate Daten Zentren, die geografisch sind und Fehler isoliert. 

Wir werden eine haben Paar EC2-Instanzen. Wir gehen zu müssen einige Back-End-Server. Vielleicht, wenn du ein Erbe sind Architektur, wir sind mit, was wir RDS nennen, relationale Datenbankdienstleistungen. Könnte MSSQL, MySQL zu sein, oder etwas ähnliches. Das ist so eine Menge Anwendungen heute gestaltet. 

Nun, wir möchten Sie vielleicht mit zu gehen das ist, wenn wir skalieren. Wir werden weitermachen und legte Die S3-Bucket dort oben. Und das S3-Bucket, statt zu dienen bis die Objekte aus unserem servers-- könnten wir das tun. Sie setzen alle Ihre binäre Objekte auf Ihren Servern und Sie können diese Server verwenden Fällen, dass die Daten bis zu dienen. Aber das ist ziemlich teuer. 

Besseren Weg zu tun ist, gehen Sie vor und setzen diese Objekte in einem S3-Bucket. S3 ist ein Objekt-Repositories. Es ist speziell für den Einbau serviert diese Art von Dingen. Und lassen Sie diese Kunden anzufordern die direkt von diesen Objekt Eimer, entlasten die Server. So beginnen wir, hier zu skalieren. 

Jetzt haben wir den Benutzern auf der ganzen Welt. Ich bekam Nutzer. Ich brauche, um Inhalte lokal haben in der Nähe dieser Nutzer, nicht wahr? Ich habe eine S3-Bucket erstellt wie mein Quell-Repository. Und ich werde vorne, dass mit Die Cloudfront-Verteilung. 

Cloudfront ist eine CD und eine Content Delivery Network. Im Grunde ist es Daten, die Sie angeben, nimmt und speichert sie alle über das Internet so dass die Benutzer überall haben können eine sehr schnelle Reaktion, wenn sie fordern diese Objekte. 

So erhalten Sie eine Idee. Sie sind Art von Nutzung alle Aspekte der AWS Sie hier, um dieses zu erhalten getan. Und schließlich, werfen wir in einem Auto Scaling Group. Also unsere AC2-Instanzen unserer Spielserver, wie sie beginnen mehr los zu werden und mehr zu tun, Sie werden nur zu spinnen ein weiterer So drehen Sie eine andere Instanz, spinnen eine andere Instanz. So dass die Technologie AWS hat, es Hier können Sie die Parameter festlegen um den sich Ihre Server wird wachsen. So können Sie n Anzahl der Server haben dort zu einem bestimmten Zeitpunkt. Und wenn Sie Ihre Ladung geht weg, werden sie schrumpfen, wird die Anzahl schrumpfen. Und wenn die Last kommt zurück, es komme wieder wachsen, elastisch. 

Also das sieht gut aus. Wir haben eine Menge von EC2-Instanzen bekam. Wir können Cache setzen vor den Datenbanken versuchen und zu beschleunigen, die Datenbanken. Die nächste Druckpunkt in der Regel die Menschen sehen, ist sie ein Spiel mit einer Skala relationales Datenbanksystem. Herrgott, die Datenbank Leistung ist schrecklich. Wie verbessern wir das? Lassen Sie uns versuchen Sie, Cache vor, dass. 

Nun, Cache funktioniert nicht so groß, in Spielen, nicht wahr? Für Spiele, Schreiben ist schmerzhaft. Spiele sind sehr schwer zu schreiben. Cache funktioniert nicht, wenn Sie Schreiben schwer, weil Sie schon immer bekam, um den Cache zu aktualisieren. Sie aktualisieren den Cache, es ist irrelevant werden Caching. Es ist eigentlich nur zusätzliche Arbeit. 

Also, wo wir jetzt? Sie haben einen großen Engpass bekommen da unten in der Datenbank. Und der Ort zu gehen offensichtlich ist die Partitionierung. Partitionierung ist nicht einfach zu tun, wenn Sie Umgang mit relationalen Datenbanken. Mit relationalen Datenbanken, du bist verantwortlich für die Verwaltung, effektiv der Schlüsselraum. Sie sagen Benutzer zwischen A und M gehen Sie hier, zwischen N und Z dorthin zu gehen. Und du bist Schalt über die Anwendung. So dass Sie es zu tun haben diese Partition-Datenquelle. Sie haben transaktionale Beschränkungen dass nicht überspannen Partitionen. Sie haben alle Arten von bekam Unordnung, die Sie Umgang mit dort versuchen mit Skalierung umgehen und den Aufbau einer größeren Infrastruktur. Es ist einfach kein Spaß. 

ZIELGRUPPE: Also sagen Sie, dass Erhöhung Quellpunkte beschleunigt der Prozess? RICK Houlihan: Erhöhung? ZIELGRUPPE: Source Punkten. RICK Houlihan: Source Punkte? ZIELGRUPPE: Aus den Informationen, wo die Information aus? RICK Houlihan: Nein Was ich sage, ist die Erhöhung der Anzahl der Partitionen im Datenspeicher verbessert den Durchsatz. Also, was hier passiert ist, Benutzern kommen in den EC2-Instanz hier oben, Nun, wenn ich einen Benutzer das ist A bis M, werde ich hier. Von N auf p, werde ich hier. Von P bis Z, werde ich hier. 

ZIELGRUPPE: OK, so diejenigen, die sind alle in verschiedenen Knoten gespeichert? 

RICK Houlihan: Ja. Denken Sie an diese als verschiedene Datensilos. Also die Sie haben, dies zu tun. Wenn Sie versuchen zu tun Dies, wenn Sie versuchen, um auf einer relationalen Plattformwaage, das ist, was du tust. Du nimmst Daten und Sie schneiden Sie es auf. Und du bist die Partitionierung es über mehrere Instanzen der Datenbank. Und du bist alles was die Verwaltung auf der Anwendungsebene. Es macht keinen Spaß. Also, was wollen wir hin? Wir wollen gehen DynamoDB, vollständig verwaltete, NoSQL-Datenspeicher, die Bereitstellung Durchsatz. Wir verwenden Sekundärindizes. Es ist im Grunde HTTP-API und umfasst Dokument Unterstützung. Sie müssen sich also keine Sorgen machen, über irgendwelche dieser Partitionierung. Wir tun alles für Sie. So, jetzt, anstatt, Sie schreiben Sie einfach den Tisch. Wenn die Tabelle muss partitioniert werden, das passiert hinter den Kulissen. Sie sind vollständig isoliert davon als Entwickler. Also lassen Sie uns darüber reden einige der Anwendungsfälle dass wir in in Gaming, gemeinsam laufen Gaming-Szenarien, Bestenliste. So haben Sie Nutzer kommen in, die BoardNames, dass sie auf, die Scores für diesen Benutzer. Wir könnten über die UserID Hashing werden, und dann haben wir Bereich auf das Spiel. Also jeder Benutzer sehen will all das Spiel er spielte und alle seine Bestnote in allen das Spiel. Also das ist, seine persönliche Bestenliste. 

Jetzt möchte ich in zu gehen und ich möchte get-- damit ich diese persönliche Bestenlisten. Was ich tun möchte, ist unterwegs zu bekommen die höchste Punktzahl für alle Benutzer. So, wie ich das tun? Als mein Rekord auf gehasht die Benutzer-ID, lag auf dem Spiel, gut, ich werde weitermachen und umzustrukturieren, erstellen Sie eine GSI, und ich werde, dass die Daten neu zu strukturieren. 

Jetzt werde ich auf die Hash- Boardname, der das Spiel ist. Und ich werde reichen auf die höchste Punktzahl. Und jetzt habe ich verschiedene Eimer erstellt. Ich bin mit den gleichen Tisch, die gleichen Positionsdaten. Aber ich bin die Schaffung eines Eimer, ergibt mir eine Aggregation von oben Punktzahl durch Spiel. 

Und ich kann die Tabelle abfragen um diese Informationen zu erhalten. Also habe ich diese Abfrage-Muster bis zu setzen von einem Sekundärindex unterstützt werden. Jetzt können sie durch Boardname sortiert und sortiert TopScore, abhängig. Damit Sie sehen können, sind diese Typen Anwendungsfälle Sie in Gaming zu erhalten. Eine weitere gute Verwendung, falls wir in Gaming zu erhalten ist ausgezeichnet und wer die Preise gewonnen. Und dieses eine große Anwendungsfall ist wo wir als spärlich Indizes. Sparse-Indizes sind das Fähigkeit, zu erzeugen ein Index, der nicht notwendigerweise enthält jedes einzelne Element auf den Tisch. Und warum nicht? Da das Attribut, das Wesen indizierten nicht auf jeden Artikel vorhanden. 

Also in diesem besonderen benutzen Fall ich sage, Sie wissen, was, ich bin zu gehen erstellen ein Attribut namens Award. Und ich werde jeden Anwender geben das hat eine Auszeichnung, zuzuschreiben. Benutzer, die nicht über Auszeichnungen sind nicht gehen, um das Attribut zu haben. Also, wenn ich das schaffen Index, die einzigen Benutzer die gehen, um zu zeigen, bis im Index diejenigen, die tatsächlich haben Preise gewonnen. Also das ist eine gute Möglichkeit, in der Lage sein, um gefilterte Indizes erstellen, sind sehr, sehr selektiven, die nicht haben zu indizieren die gesamte Tabelle. 

So bekommen wir wenig Zeit hier. Ich werde weitermachen und überspringen aus und überspringen Sie dieses Szenario. Sprechen Sie ein wenig about-- 

Publikum: Kann ich eine kurze Frage stellen? Eine schreib schwer? RICK Houlihan: Was ist? ZIELGRUPPE: Schreiben schwer. RICK Houlihan: Schreiben schwer. Lass mich nachsehen. 

ZIELGRUPPE: Oder ist das nicht etwas, was Sie können einfach Stimme in einer Angelegenheit von Sekunden? RICK Houlihan: Wir gehen durch die Abstimmungs Szenario. Ist doch nicht schlimm. Habt ihr ein paar Minuten? OK. 

So werden wir über Stimmrechts sprechen. So Echtzeitabstimmungs, haben wir Anforderungen zur Abstimmung. Voraussetzungen sind, dass wir es zulassen, jede Person nur einmal abstimmen. Wir wollen, dass niemand zu können ihre Stimme ändern. Wir wollen, dass Echtzeit-Aggregation und Analytics für Demografie dass wir gehen, zu sein zeigt an Benutzer auf die Website. 

Stellen Sie sich dieses Szenario. Wir arbeiten viel der Wirklichkeit TV-Shows, wo sie sind Doing diese genaue Art der Dinge. So dass Sie das Szenario vorstellen können, wir Millionen und Abermillionen haben der Mädchen im Teenageralter gibt mit ihren Handys und an der Abstimmung und Abstimmung, und Stimmabgabe für wer immer sie sind zu finden sein die populärste. Das sind also einige der Anforderungen, die wir auslaufen. 

Und so ist die erste zu nehmen bei dieser Problemlösung wäre, eine zu bauen sehr einfache Anwendung. Also habe ich diese app hat. Ich habe einige Wähler da draußen. Sie kommen in, können sie das Abstimmungs App getroffen. Ich habe einige raw Stimmen Tisch bekamen Ich werde einfach Dump jene Stimmen in. Ich werde einige Aggregat haben Stimmen Tabelle, meine Analysen und Demographie zu tun, und wir werden alles in es gesetzt. 

Und das ist großartig. Das leben ist gut. Das Leben ist gut, bis wir herausfinden, dass es gibt immer nur ein oder zwei Menschen, die in einem Wahl beliebt sind. Es gibt nur ein oder zwei Dinge dass die Menschen wirklich über. Und wenn Sie an der Abstimmung sind Skala, ganz plötzlich bin ich gehen zu hämmern die Hölle aus zwei Kandidaten, ein oder zwei Kandidaten. Eine sehr begrenzte Anzahl der Elemente Leute finden, beliebt zu sein. 

Dies ist nicht ein gutes Design-Muster. Dies ist tatsächlich eine sehr schlecht Entwurfsmuster denn es schafft, was wir sprach über die Hot-Keys war. Hot-Keys sind etwas, was wir nicht mögen. 

So, wie wir das beheben? Und wirklich, die Art und Weise, dies zu beheben ist indem sie jene Kandidaten Eimer und für jeden Kandidaten haben wir, wir werden einen zufälligen Wert anhängen, etwas, das wir wissen, Zufalls Wert zwischen einem und 100, zwischen 100 und 1.000, oder zwischen einer und 1000 bedeutet, aber viele zufällige Werte Sie möchten angehängt an das Ende dieses Kandidaten. 

Und was habe ich wirklich dann getan? Wenn ich mit der Kandidaten-ID als die Schaufel, um Gesamtstimmenzahl, wenn ich eine zufällige hinzugefügt Zahl an das Ende davon, Jetzt die ich angelegt habe 10 Eimer, ein Hundert Eimer, tausend Eimer dass ich Aggregation Stimmen gegenüber. 

So habe ich Millionen und Millionen, und Millionen von Datensätzen kommen in für diesen Kandidaten, bin ich jetzt verbreiten diese Stimmen für Kandidat A_1 durch Candidate A_100, denn jedes Mal, wenn eine Abstimmung kommt, Ich Erzeugen einer Zufalls Wert zwischen einem und 100. Ich Heften es auf das Ende der Kandidaten, die Person, die für die Abstimmung. Ich Dumping sie in diesem Eimer. 

Jetzt auf der Rückseite, ich weiß, dass ich hundert Eimer. Also, wenn ich will weitermachen und aggregieren die Stimmen, Ich von all den Eimer zu lesen. Also ich voran gehen und hinzufügen. Und dann weiß ich das Streuerfassungs wo ich gehen und sagen, hey, Sie wissen, was, Schlüsseldies Kandidaten Räumen ist über hundert Eimer. Werde ich sammeln alle Stimmen aus jenen hundert Eimer. Ich werde zu aggregieren sie und ich werde sagen, Kandidat A hat jetzt Gesamt Stimme von x. 

Nun sowohl das Schreib Abfrage und die Leseabfrage sind schön verteilt weil ich über das Schreiben und ich bin über Hunderte von Schlüssel Lese. Ich schreibe und Lesen über einen Schlüssel bekommen. Also das ist ein großer Muster. 

Dies ist tatsächlich wahrscheinlich eine der wichtigsten Design- Muster für den Maßstab in NoSQL. Sie werden diese Art von zu sehen Entwurfsmuster in jedem Geschmack. MongoDB, DynamoDB, ist es nicht Egal, wir alle haben, dies zu tun. Weil, wenn Sie tun mit diesen riesigen Ansammlungen, Sie müssen herausfinden, einen Weg, breitete sie in Eimern. Das ist also die Art, wie Sie das tun. Na gut, so was Sie gerade tun wird sie den Handel off Lese sind Kosten für Schreib Skalierbarkeit. Die Kosten für meine Lese ist ein wenig komplexer und ich muss von einem gelesen markieren hundert Schaufeln statt einer. Aber ich bin in der Lage, zu schreiben. Und mein Durch, mein Schreib Durchsatz ist unglaublich. So ist es in der Regel ein wertvolles Technik für die Skalierung DynamoDB, oder jede NoSQL-Datenbank für diese Angelegenheit. So haben wir herausgefunden, wie man es zu skalieren. Und wir gefunden, wie man Beseitigung unserer Hotkeys. Und das ist fantastisch. Und wir haben diese schöne Anlage. Und es ist uns sehr korrekt Abstimmungs gegeben denn wir haben Rekord Stimme de-dupe. Es ist in DynamoDB gebaut. Wir sprachen über bedingte Rechte. 

Wenn ein Wähler kommt, puts ein Einsatz auf dem Tisch, sie stecken mit ihren Wähler ID, wenn sie versuchen, eine andere Stimme einzufügen, Ich mache eine bedingte Schreib. Nur sagen, dies schreibe wenn diese nicht vorhanden ist. Also, sobald ich sehe, dass dass die Abstimmung ging nur an den Tisch, niemand sonst los zu sein in der Lage, ihre Stimme in. Und das ist fantastisch. Und wir Inkrementieren unser Kandidat Zähler. Und wir tun unser Demografie und das alles. Aber was passiert, wenn mein Anwendungs ​​umfällt? Jetzt ganz plötzlich Stimmen sind herein, und ich weiß nicht, ob sie bekommen verarbeitet in meinen Analysen und Demografie nicht mehr. Und wenn die Anwendung wieder aufgebaut wird, wie zum Teufel tun, ich weiß, was Stimmen haben verarbeitet und wo soll ich anfangen? 

Also das ist ein echtes Problem, wenn Sie starten, um an dieser Art von Szenario zu suchen. Und wie wir zu lösen Sie das? Wir lösen es mit dem, was wir rufen DynamoDB Streams. Ströme wird eine Zeit bestellt und partitioniert Änderungsprotokoll von jedem Zugriff auf den Tisch, schreiben Sie jeden Zugriff auf die Tabelle. Alle Daten, die auf der geschrieben hat Tabelle zeigt auf dem Stream. 

Es ist im Grunde ein 24-Stunden-Warteschlange. Artikel traf den Strom, sie leben für 24 Stunden. Sie kann mehrfach gelesen werden. Garantierte geliefert werden nur einmal in den Stream, kann n-mal ausgelesen werden. So wie viele Prozesse, die Sie wollen, verbrauchen diese Daten, können Sie es zu konsumieren. Es wird jedes Update angezeigt. Jeder Schreib wird nur erscheinen, sobald auf dem Strom. Sie müssen sich also keine Sorgen machen, etwa doppelt Verarbeitung es aus demselben Verfahren. 

Es ist strikt pro Stück bestellt. Wenn wir sagen, Zeit bestellt und verteilt, Sie werden pro Partition auf dem Stream zu sehen. Sie erhalten Einzelteilen, Updates, um zu sehen. Wir sind nicht garantiert auf den Strom, der du bist gehen, um jede Transaktion zu erhalten in der Reihenfolge, in Einzelteile. 

So Streams sind idempotent. Haben wir alle wissen, was idempotent bedeutet? Idempotent bedeutet, dass Sie es tun können über und über, und immer wieder. Das Ergebnis geht um die gleiche sein. 

Streams sind idempotent, aber sie müssen vom Ausgangspunkt gespielt, wo immer Sie sich entscheiden, bis zum Ende, oder sie werden nicht zur Folge haben in den gleichen Werten. 

Das Gleiche gilt für MongoDB. MongoDB hat ein Konstrukt sie nennen das oplog. Es ist genau das gleiche Konstrukt. Viele NoSQL-Datenbanken haben diese Konstrukt. Sie verwenden es, Dinge zu tun wie Replikation, die ist genau das, was wir tun, mit Bächen. ZIELGRUPPE: Vielleicht ein ketzerische Frage, aber Sie sprechen über apps da unten ein so weiter. Werden Ströme gewährleistet nie möglicherweise nach unten gehen? RICK Houlihan: Ja, Bäche garantiert nie nach unten gehen. Wir verwalten die Infrastruktur hinter. Ströme automatisch Bereitstellen in ihrem Auto Scaling Group. Wir werden durch ein kleines gehen wenig über, was geschieht. 

Ich sollte nicht sagen, dass sie nicht garantiert nie nach unten gehen. Die Elemente sind garantiert um im Strom angezeigt. Und der Strom wird zugänglich sein. Also, was unten geht oder kommt zurück bis, vor, dass darunter. Es-Abdeckungen, es ist OK. Na gut, so dass Sie verschiedene bekommen Ansichtstypen aus dem Bildschirm. Die Ansichtstypen, die wichtig für eine sind Programmierer in der Regel sind, was war es? Ich bekomme die alte Ansicht. Wenn ein Update geht an den Tisch, es wird drücken Sie die alte Ansicht, um den Stream so können die Daten zu archivieren, oder ändern Kontrolle, Änderungsidentifikation, ändern Management. 

Das neue Bild, was es jetzt ist, nachdem die Aktualisierung, die eine andere Art von Blick ist du kannst bekommen. Sie können sowohl die alte und neue Bilder zu bekommen. Vielleicht will ich sie beide. Ich möchte sehen, was es war. Ich möchte sehen, was es zu ändern. 

Ich habe eine Compliance-Typ der Prozess, der läuft. Es braucht, um zu überprüfen, dass wenn diese Dinge zu ändern, dass sie innerhalb bestimmter Grenzen sind oder innerhalb bestimmter Parameter. 

Und dann vielleicht nur ich müssen wissen, was geändert wurde. Es ist mir egal, welche Artikel verändert. Ich brauche nicht zu wissen müssen welche Attribute geändert. Ich muss nur wissen, dass die Gegenstände berührt. Das sind also die Ansichtsarten dass Sie aus dem Stream und Sie können mit interagieren. 

Die Anwendung, verbraucht den Strom, Dies ist eine Art der Art und Weise dies funktioniert. DynamoDB Kunden auffordern, Push-Daten an die Tische. Ströme bereitstellen, was wir nennen Scherben. Shards skaliert werden unabhängig von der Tabelle. Sie überlagern sich nicht komplett auf die Partitionen der Tabelle. Und der Grund dafür ist, weil sie line up die Kapazität der Strom Kapazität der Tabelle. 

Sie entfalten in ihren eigenen Auto Scaling Group, und sie beginnen sich zu drehen aus je wie viele Schreibvorgänge auf sich warten, wie viele reads-- eigentlich ist es schreibt. Es gibt keinen reads-- aber wie viele Schreibvorgänge auf sich warten. 

Und dann auf der Rückseite Ende, wir haben, was wir rufen Sie einen KCL oder Kinesis-Client-Bibliothek. Kinesis ist ein Strom-Daten Verarbeitungstechnologie von Amazon. Und Bäche auf, dass gebaut. 

So verwenden Sie ein KCL aktiviert Anwendung, um den Stream zu lesen. Die Kinesis-Client-Bibliothek tatsächlich verwaltet die Arbeiter für Sie. Und das tut sie auch einiges interessante Dinge. Es wird einige Tabellen erstellen up in Ihrer DynamoDB Table an welche Objekte verfolgen verarbeitet wurden. Also auf diese Weise, wenn er fällt zurück, wenn es fällt über und kommt und bekommt stand wieder auf, kann sie bestimmen, wo war es bei der Verarbeitung des Stream. 

Das ist sehr wichtig, wenn Sie Replikation redest. Ich muss wissen, was Daten verarbeitet wurde und welche Daten noch zu verarbeiten sind. Also das KCL-Bibliothek für Ströme geben Sie eine Menge von dieser Funktionalität. Es kümmert sich um alle die Hauswirtschaft. Es steht auf einem Arbeitnehmer für jedes Shard. Es schafft eine Verwaltungstabelle für jedes Shard für jeden Arbeiter. Und als dieser Arbeitnehmer Feuer, sie diese Tabellen pflegen so dass Sie diesen Datensatz wissen wurde gelesen und verarbeitet. Und dann so, wenn der Prozess stirbt und wieder online ist, es rechts wieder aufzunehmen, wo sie zog. 

So nutzen wir dies für Quer Region Replikation. Viele Kunden haben das Bedürfnis, Verschieben von Daten oder Teile ihrer Datentabellen herum zu verschiedenen Regionen. Es gibt neun Regionen auf der ganzen Welt. So könnte es ein need-- I sein könnten Benutzer in Asien haben, Nutzer An der Ostküste der Vereinigten Staaten. Sie haben verschiedene Daten, muss lokal verteilt werden. Und vielleicht ein Benutzer aus fliegt Asien über die Vereinigten Staaten, und ich möchte zu replizieren seine Daten mit ihm. Also, wenn er bekommt aus dem Flugzeug, muss er eine gute Erfahrung mit seinem Mobil App. 

Sie können die Cross-Region nutzen Replikation Bibliothek, um dies zu tun. Im Grunde haben wir vorgesehen beiden Technologien. One ist eine Konsolenanwendung möglich stand auf dem eigenen EC2-Instanz. Es wird mit reinem Replikation. Und dann haben wir Ihnen die Bibliothek. Die Bibliothek, die Sie verwenden können, um zu bauen Ihre eigene Anwendung, wenn Sie wollen verrückte Sachen damit zu tun data-- Filter, replizieren nur ein Teil davon, Drehen Sie die Daten, verschieben Sie sie in einen andere Tabelle, so weiter und so fort. Also das ist eine Art, wie das aussieht. 

DynamoDB Streams kann durch das, was wir als Lambda verarbeitet. Wir erwähnten, ein wenig über Ereignis angetrieben Anwendungsarchitekturen. Lambda ist ein wichtiger Bestandteil davon. Lambda ist Code, der auf Anfrage feuert in Reaktion auf ein bestimmtes Ereignis. Eines dieser Ereignisse könnte ein Rekord auf der Strom erscheinen. Wenn ein Datensatz im Stream angezeigt wird, wir werden dieses Java-Funktion aufrufen. Nun, dies ist JavaScript und Lambda unterstützt Node.js, Java, Python, und bald unterstützen andere Sprachen. Und es genügt zu sagen, es ist pure Code. schreiben In Java eine Klasse fest. Sie drücken Sie die JAR-up in Lambda. Und geben Sie dann, welche Klasse Sie in Antwort auf die Ereignis aufgerufen. Und dann wird die Lambda-Infrastruktur hinter das wird, dass Code ausgeführt werden. 

Dieser Code verarbeiten kann, Aufzeichnungen aus dem Stream. Es kann alles, was es mit ihm zu tun will. In diesem speziellen Beispiel, alle wir sind wirklich tun, ist die Protokollierung der Attribute. Aber das ist nur Code. Code können alles tun, oder? 

So können Sie diese Daten zu drehen. Sie können ein Derivat Ansicht erstellen. Wenn es eine Dokumentstruktur, Sie können die Struktur zu glätten. Sie können alternative Indizes erstellen. Alle Arten von Sachen, die Sie zu tun mit den DynamoDB Streams. 

Und wirklich, das ist, wie das aussieht. So erhalten Sie die Updates kommen in. Sie kommen aus dem String. Sie werden von der Lambda-Funktion zu lesen. Sie sind Drehen der Daten und Schieben Sie es in derivative Tische, Benachrichtigung externen Systemen des Wandels, und Schieben von Daten in ElastiCache. 

Wir sprachen darüber, wie Sie den Cache setzen vor der Datenbank für diesen Verkaufs Szenario. Nun, was passiert, wenn ich aktualisieren Sie die Artikelbeschreibung? Nun, wenn ich eine Lambda Funktion für diese Tabelle ausgeführt wird, wenn ich die Artikelbeschreibung zu aktualisieren, wird es holen die Rekord aus dem Strom, und es wird die ElastiCache aktualisieren weise mit den neuen Daten. Also das ist eine Menge von was wir mit Lambda. Es ist Glue-Code, Anschlüsse. Und es gibt tatsächlich die Fähigkeit, zu starten und zu sehr komplexen Anwendungen ausführen ohne einen dedizierten Server Infrastruktur, die wirklich cool ist. 

Also gehen wir zurück zu unserem Echtzeit-Abstimmungs Architektur. Das ist neu und verbessert mit unseren Bäche und KCL fähige Anwendung. Gleiche wie vorher, wir können hand jede Skala von Wahlen. Wir mögen diese. Wir machen aus Streu Raffungen über mehrere Eimer. Wir müssen optimistische Sperr vorgeht. Wir können unsere Wähler zu halten von Veränderung ihrer Stimmen. Sie können nur nur einmal abstimmen. Das ist fantastisch. Echtzeit-Fehlertoleranz, skalierbare Aggregation jetzt. Wenn das Ding umfällt, es weiß, wo er sich selbst neu zu starten wenn er zurückkommt, weil wir sind mit dem KCL App. Und dann können wir auch, dass KCL-Anwendung, um Daten aus drücken nach anderen Redshift App Analytik, oder die Nutzung die Elastic MapReduce zu laufen Echtzeit-Streaming-Aggregationen aus dieser Daten. 

Das sind Dinge, die wir nicht zu viel geredet. Aber sie sind zusätzliche Technologien, die kommen, zu tragen, wenn Sie schauen, auf diese Arten von Szenarien. 

In Ordnung, das ist also zu Analytik mit DynamoDB Streams. Sie können de-dupe sammeln Daten, tun alle Arten von nice stuff, aggregierte Daten in Gedächtnis, schaffen jene derivativen Tabellen. Das ist eine riesige Anwendungsfall dass eine Menge von Kunden werden mit einbezogen, wobei die verschachtelten Eigenschaften dieser JSON Dokumenten und die Schaffung von zusätzlichen Indizes. 

Wir sind am Ende. Vielen Dank für Lager mit mir. Also lassen Sie uns darüber reden Referenzarchitektur. DynamoDB sitzt in der Mitte der so viel von der AWS-Infrastruktur. Grundsätzlich können Sie es Haken bis zu, was Sie wollen. Anwendungen, die mit Dynamo schließen Lambda, ElastiCache, Cloud, schieben Sie die Daten aus in Elastic MapReduce, Import-Export aus DynamoDB in S3, alle Arten von Workflows. Aber wahrscheinlich das beste Sache, darüber zu sprechen, und das ist, was wirklich Interessant ist, wenn wir sprechen über ereignisgesteuerte Anwendungen. 

Dies ist ein Beispiel für ein internes Projekt dass wir, wo wir sind eigentlich Veröffentlichen auf Umfrageergebnisse zu sammeln. So in einer E-Mail-Link, wir aussenden, es werde ein wenig Link sagen Klick Sie hier, um auf die Umfrage reagiert. Und wenn eine Person Klicks dass Link, was passiert, ist, dass sie eine sichere unten ziehen HTML-Umfrageformular aus S3. Es gibt keinen Server. Dies ist nur eine S3-Objekt. 

Diese Form kommt, lädt im Browser. Es hat Backbone. Es hat komplexe JavaScript- , dass es läuft. So ist es sehr reich Anwendung im Browser des Clients ausgeführt werden. Sie wissen nicht, dass sie nicht Interaktion mit einem Back-End-Server. An diesem Punkt, es ist alles Browser. 

Sie veröffentlichen die Ergebnisse an, was wir nennen das Amazon-API-Gateway. API-Gateway ist einfach eine Web-API dass Sie definieren und hook up kann , was auch immer Sie wollen. In diesem speziellen Fall sind wir bis zu einer Lambda-Funktion eingehakt. 

Also meine POST-Operation ist geschieht ohne Server. Im Grunde, dass API-Gateway sitzt. Es kostet mich nichts, bis Menschen veröffentlichen, um es zu, nicht wahr? Die Lambda-Funktion sitzt nur da. Und es kostet mich nichts, bis Menschen beginnen, es schlagen. So können Sie sehen, wie das Volumen erhöht, das ist, wenn die Einnahmen stammen. Ich bin nicht einen Server 24.7 läuft. 

Also habe ich die Form ziehen nach unten aus dem Eimer, und ich Post über die API Gateway in den Lambda-Funktion. Und dann die Lambda Funktion sagt, Sie wissen, was habe ich einige PIIs bekam, einige persönliche Daten in diesen Reaktionen. Ich habe Kommentare aus Nutzern. Ich habe per E-Mail-Adressen einsehen. Ich habe Benutzernamen erhielt. 

Lassen Sie mich dies abgespalten. Ich werde einige generieren Metadaten aus dieser Platte. Und ich werde mit der Schub Metadaten in DynamoDB. Und ich konnte alle Daten zu verschlüsseln und schieben Sie es in DynamoDB, wenn ich will. Aber es ist einfacher für mich, in diesem benutzen Fall, gehen Sie vor ein Wort, Ich werde die Rohdaten drücken in einen verschlüsselten S3 Eimer. So dass ich in S3 Server-Seite gebaut Verschlüsselung und Amazons Key Management Service, so dass ich einen Schlüssel, kann auf einem regelmäßigen Intervall zu drehen, und ich kann diese PII Daten zu schützen als Teil dieser gesamten Workflow. 

So was habe ich getan? Ich habe gerade im Einsatz eine ganze Anwendung, und ich habe keinen Server. So ist das, was ereignisgesteuerte Anwendung Architektur für Sie tut. 

Nun, wenn Sie darüber nachdenken, der Anwendungsfall für this-- wir haben andere Kunden Ich rede mehr über diese genaue Architektur, die laufen phänomenal großen Kampagnen, die Momentan sind auf der Suche und gehen, oh mein. Denn jetzt, können sie im Grunde schieben Sie es da draußen, lassen Sie diese Kampagne nur sitzen dort, bis es startet, und nicht müssen ein Bild zu befürchten welche Art von Infrastruktur wird da sein, um sie zu unterstützen. Und dann, sobald dass Kampagne durchgeführt wird, es ist wie der Infrastruktur nur geht sofort entfernt weil es wirklich keine Infrastruktur. Es ist nur Code, der auf Lambda sitzt. Es ist nur Daten, die in DynamoDB sitzt. Es ist eine erstaunliche Art und Weise um Anwendungen zu erstellen. 

Publikum: So ist es mehr ephemeren als es wäre, wenn es auf einem vorhandenen Server gespeichert? 

RICK Houlihan: Absolut. Da dieser Serverinstanz müsste ein 7/24 sein. Es hat für die zur Verfügung stehen jemanden zu reagieren. Nun raten Sie mal? S3 ist verfügbar 24.7. S3 reagiert immer. Und S3 ist sehr, sehr gut zumin serviert Objekte. Diese Objekte können HTML-Dateien sein, oder JavaScript-Dateien, oder was auch immer Sie wollen. Sie können sehr reich Web-Anwendungen laufen von S3 Eimer, und Leute tun. 

Und damit ist die Idee hier ist, um weg von dem Weg wir benutzt, um darüber nachzudenken. Wir alle verwendet werden, um in der Meinung Bezug auf Server und Hosts. Es geht nicht darum, dass mehr. Es ist an der Infrastruktur als Code. Implementieren Sie den Code in die Cloud und lassen Sie die Wolke führen Sie es für Sie. Und das ist, was AWS zu tun versucht. 

Publikum: So Ihre Goldfeld in der Mitte der API-Gateway ist keine Server-like, sondern stattdessen just-- 

RICK Houlihan: Sie können denken, es als Server-Fassade. Alles, was es ist, es wird ein HTTP-nehmen fordern und wo es sich an einen anderen Prozess. Das ist alles, es tut. Und in diesem Fall, wir Kartierung Einem Lambda-Funktion. In Ordnung, so dass alles, was ich bekam. Danke schön. Ich schätze es. Ich weiß, wir wollen ein wenig über die Zeit. Und hoffentlich werden Sie Jungs haben ein bisschen von Informationen dass man sich heute zu nehmen. Und ich entschuldige mich, wenn ich ging über einige Ihrer Köpfe, aber es gibt eine gute Menge Grundlagengrundlagenwissen dass ich denke, ist sehr wertvoll für Sie. Ich danke Ihnen für die Einladung. [BEIFALL] ZIELGRUPPE: [unverständlich] ist, wenn Sie sagten Sie mussten durch die Sache gehen vom Anfang bis zum Ende um die richtigen Werte zu erhalten oder die gleichen Werte, Wie würde die Werte ändern, wenn [unverständlich]. 

RICK Houlihan: Oh, idempotent? Wie würden sich die Werte ändern? Nun, weil, wenn ich nicht laufen es den ganzen Weg bis zum Ende, dann weiß ich nicht, welche Änderungen wurden in der letzten Meile machte. Es wird nicht auf das sein, dieselben Daten wie, was ich sah. ZIELGRUPPE: Oh, so dass Sie nur nicht die gesamte Eingabe geworden. RICK Houlihan: Richtig. Sie müssen von Anfang gehen bis zum Ende, und dann ist es geht in einen konsistenten Zustand zu sein. Cool. 

ZIELGRUPPE: Sie zeigte uns DynamoDB kann Dokument oder den Schlüsselwert zu tun. Und wir verbrachten viel Zeit auf die Schlüssel-Wert mit einem Hash und die Möglichkeiten, um es umzudrehen um. Wenn Sie in diesen Tabellen sah, ist, dass hinterlässt das Dokument Ansatz? 

RICK Houlihan: Ich würde nicht sagen, verlassen sie hinter sich. 

Publikum: Sie wurden aus the-- getrennt 

RICK Houlihan: Mit dem Dokument Ansatz, der Dokumenttyp in DynamoDB befindet sich nur vorstellen wie ein anderes Attribut. Es ist ein Attribut, das enthält eine hierarchische Datenstruktur. Und dann in den Abfragen, Sie können die Eigenschaften verwenden dieser Objekte mit Object Notation. So kann ich auf einem verschachtelten filtern Eigentum des JSON-Dokument. ZIELGRUPPE: Also jedes Mal wenn ich tun ein Dokument Ansatz, Ich kann Art kommen am tabular-- ZIELGRUPPE: Absolut. ZIELGRUPPE: --indexes und Dinge, die Sie gerade gesprochen. RICK Houlihan: Ja, das Indizes und all das, wenn Sie die Index möchten Eigenschaften der JSON, die Art und Weise, die wir würde, das zu tun ist, wenn Sie ein JSON-Objekt oder ein Dokument einfügen in Dynamo Sie Ströme verwenden würden. Strömen würde die Eingabe zu lesen. Sie würden, dass JSON erhalten Objekt und Sie würden sagen, OK, was ist die Eigenschaft Ich möchte index? 

Sie erstellen ein Derivat Tisch. Nun, das ist die Art, wie es jetzt funktioniert. Wir erlauben Ihnen, Index direkt diese Eigenschaften. 

ZIELGRUPPE: Tabularizing Ihrer Dokumente. 

RICK Houlihan: Genau, Abflachung es, tabularizing es, genau. Das ist, was Sie damit machen. 

ZIELGRUPPE: Vielen Dank. 

RICK Houlihan: Yep, absolut, ich danke Ihnen. Publikum: So ist es Art ist Mongo erfüllt Redis classifers. 

RICK Houlihan: Ja, es ist viel ähnlich. Das ist eine gute Beschreibung dafür. Cool.