>> [Jouer de la musique]
RICK HOULIHAN: Très bien.
Salut tout le monde.
Mon nom est Rick Houlihan.
Je suis un directeur principal architecte de solutions AWS.
Je me concentre sur NoSQL et DynamoDB technologies.
Je suis ici aujourd'hui pour parler vous un peu plus sur ceux-ci.
>> Mon arrière-plan est principalement dans la couche de données.
Je passais la moitié de mon développement carrière en écrivant base de données,
accès aux données, des solutions pour diverses applications.
Je suis allé dans la virtualisation Couverture depuis environ 20 ans.
Donc, avant de le Cloud était le Cloud, nous avions l'habitude de l'appeler l'informatique utilitaire.
Et l'idée a été, il est comme PG & E, vous payez ce que vous utilisez.
Aujourd'hui, nous appelons le nuage.
>> Mais au fil des ans, je travaille pour un couple de sociétés
vous avez probablement jamais entendu parler.
Mais je l'ai compilé une liste de techniques réalisations, je suppose que vous dites.
Je dois huit brevets dans les systèmes de Cloud la virtualisation, la conception des microprocesseurs,
traitement des événements complexes, et d'autres domaines aussi.
>> Donc, ces jours, je me concentre principalement sur NoSQL technologies et la prochaine génération
base de données.
Et qui est généralement ce que je vais d'être ici à vous parler aujourd'hui au sujet.
Donc, ce que vous pouvez vous attendre de cette session,
nous allons passer par une brève histoire de traitement des données.
Il est toujours utile de comprendre d'où nous venons
et pourquoi nous sommes là où nous sommes.
Et nous allons parler un peu peu de technologies NoSQL
à partir d'un point de vue fondamental.
>> Nous allons entrer dans quelques-uns des les internes DynamoDB.
DynamoDB est sans saveur d'AWS.
Il est entièrement géré et solution NoSQL hébergé.
Et nous allons parler un peu plus sur la table structure, API, types de données, index,
et une partie des équipements internes de cette technologie de DynamoDB.
Nous allons entrer dans une partie de la conception les modèles et les meilleures pratiques.
Nous allons parler de la façon dont vous utiliser cette technologie pour certains
des applications d'aujourd'hui.
Et puis nous allons parler un peu à propos de l'évolution ou l'émergence
d'un nouveau paradigme dans la programmation applications appelées event-driven
et comment DynamoDB joue dans cette ainsi.
Et nous allons vous laisser un peu de une discussion de l'architecture de référence
afin que nous puissions parler de certaines des les façons dont vous pouvez utiliser DynamoDB.
>> Alors d'abord off-- cela est une question Je entends beaucoup est, ce qui est une base de données.
Beaucoup de gens pensent qu'ils savoir ce qu'est une base de données est.
Si vous Google, vous verrez cela.
Il est un un ensemble structuré de données tenue dans un ordinateur, en particulier celle qui
est accessible de diverses manières.
Je suppose que ce un bon définition d'une base de données moderne.
Mais je ne l'aime pas, parce elle implique un certain nombre de choses.
Elle implique structure.
Et cela implique que ce soit sur un ordinateur.
Et les bases de données ne l'ont pas existent toujours sur les ordinateurs.
Bases de données existaient effectivement à bien des égards.
>> Donc, une meilleure définition d'un base de données est quelque chose comme ça.
Une base de données est un organisé mécanisme de stockage, la gestion,
et la récupération d'informations.
Ceci est d'About.com.
Donc, je l'aime parce que cela parle vraiment à propos de la base de données étant un référentiel,
un référentiel de informations, pas nécessairement
quelque chose qui se trouve sur un ordinateur.
Et tout au long de l'histoire, nous ont pas toujours eu les ordinateurs.
>> Maintenant, si je demande à la moyenne ce qui est aujourd'hui développeur
une base de données, qui est la réponse que je reçois.
Quelque part, je peux coller des trucs.
Droit?
Et il est vrai.
Mais il est malheureux.
Parce que la base de données est vraiment le fondement de l'application moderne.
Il est le fondement de chaque application.
Et comment vous construisez que base de données, comment vous structurez
que les données va dicter que application effectue comme vous échelle.
>> Il ya donc beaucoup de mon travail aujourd'hui est face à ce
qui se passe lorsque les développeurs cette approche
et faire face aux conséquences d'une application qui
est maintenant mise à l'échelle au-delà de l'original l'intention et la souffrance de la mauvaise conception.
Alors, espérons quand vous à pied aujourd'hui, vous
avoir un couple d'outils dans votre ceinture que vous tiendrons
de faire les mêmes erreurs.
D'accord.
Donc, parlons un peu de la chronologie de la technologie de base de données.
Je crois avoir lu un Article pas si longtemps,
et il a dit quelque chose sur le lines-- il est une déclaration très poétique.
Il dit l'histoire de traitement des données est
plein de talons filigranes de l'abondance de données.
D'ACCORD.
Maintenant, je suppose que ce genre de vrai.
Mais en fait je regarde est aussi l'histoire est en réalité rempli
avec high watermark de la pression des données.
Étant donné que le débit de données l'ingestion ne se couche jamais.
Il ne monte.
>> Et lorsque se produit l'innovation nous voyons la pression de données, ce qui
est la quantité de données qui est maintenant à venir dans le système.
Et il ne peut pas être traitée efficace dans le temps ou de coût.
Et voilà où nous commençons de regarder à la pression des données.
>> Alors, quand on regarde la première base de données, cette
est celui qui était entre nos oreilles.
Nous sommes tous nés avec elle.
Il est une belle base de données.
Il a une haute disponibilité.
Il est toujours sur.
Vous pouvez toujours obtenir.
>> Mais il est seul utilisateur.
Je ne peux pas partager mes pensées avec vous.
Vous ne pouvez pas obtenir mes pensées quand vous le souhaitez.
Et leur abilitiy est pas si bon.
Nous oublions les choses.
Chaque maintenant et puis, l'un de nous feuilles et se déplace à une autre existence
et nous perdons tout qui était dans cette base de données.
Voilà donc pas tout ce que bon.
>> Et cela a bien fonctionné au fil du temps quand nous étions de retour dans la journée
quand tout ce que nous avions vraiment besoin de savoir est où allons-nous aller demain
ou lorsque nous nous réunissons la meilleure nourriture.
Mais comme nous avons commencé à grandir en tant que la civilisation et de gouvernement ont commencé
de naître, et les entreprises ont commencé à évoluer,
nous avons commencé à nous rendre compte besoin d'un peu plus que ce que
nous pourrions mettre dans notre tête.
D'accord?
>> Nous avions besoin de systèmes d'enregistrement.
Nous avions besoin d'endroits pour être capables de stocker des données.
Nous avons donc commencé la rédaction de documents, création bibliothèques et les archives.
Nous avons commencé le développement d'un Un système de comptabilité du grand livre.
Et ce système de comptage livre a couru le monde depuis de nombreux siècles,
et peut-être même des millénaires que nous sorte de grandi au point
où cette charge de données dépassé la capacité de ces systèmes
pour être en mesure de le contenir.
>> Et ce réellement passé dans les années 1880.
Droit?
Dans le recensement américain de 1880.
Ceci est vraiment là où le tournage signaler traitement de données moderne.
Ceci est le point lequel la quantité de données
qui a été recueilli par le Gouvernement américain est arrivé au point
où il a fallu huit ans pour traiter.
>> Aujourd'hui, huit années-- que vous le savez, le recensement
circule toutes les 10 années-- il est donc assez évident que par le temps que nous
obtenu le recensement de 1890, la quantité de données que
allait être traitée par le gouvernement était
va dépasser les 10 années qu'il porterait à lancé le nouveau recensement.
Ce fut un problème.
>> Donc, un gars nommé Herman Hollerith venu
et il a inventé l'unité enregistrement fractionné cartes, lecteur de cartes perforées, carte perforée
tabulation, et le classement de les mécanismes de cette technologie.
Et cette société qu'il forme à la temps, avec quelques autres,
effectivement devenu l'un des piliers d'une petite entreprise que nous connaissons aujourd'hui appelé IBM.
>> Ainsi était à l'origine dans IBM l'entreprise de base de données.
Et qui est vraiment ce qu'ils ont fait.
Ils ont fait le traitement des données.
>> Comme si la prolifération de punch cartes, un des mécanismes ingénieux
d'être en mesure de tirer parti de cette la technologie d'interroger triés jeux de résultats.
Vous pouvez voir sur cette photo là, nous avons un little--
il est un peu small-- mais vous pouvez voir un mécanisme mécanique très ingénieux
où nous avons un jeu de cartes perforées.
Et la prise de quelqu'un un petit tournevis
et coller à travers le fentes et soulevant
pour obtenir ce match, qui résultats triés fixés.
>> Ceci est une agrégation.
Nous le faisons tout le temps aujourd'hui dans l'ordinateur,
où vous le faites dans la base de données.
Nous avons utilisé le faire manuellement, non?
Les gens mettent ces choses ensemble.
Et ce fut la prolifération de ces cartes perforées
dans ce que nous appelions tambours de données et moulinets de données, ruban de papier.
>> L'industrie de transformation de données a une leçon des pianos mécaniques.
Pianos de retour à Le tournant du siècle
l'habitude d'utiliser des bobines de papier avec des fentes à dire ce qui touches à jouer.
Alors que la technologie a été adaptée éventuellement à stocker des données numériques,
parce qu'ils ne pouvaient mettre que les données sur les bobines de bande de papier.
>> Or, à la suite, des données a été actually-- comment
vous accédez à ces données était directement dépendant de la façon dont vous l'avez enregistré.
Donc, si je mets les données sur une bande, Je devais accéder aux données de façon linéaire.
Je devais rouler l'ensemble bande pour accéder à toutes les données.
Si je mets les données dans Punch cartes, je ne pouvais y accéder
dans un peu plus aléatoire la mode, peut-être pas aussi rapidement.
>> Mais il y avait des limites à la façon dont nous l'accès aux données sur la base de la façon dont a été stockée.
Et cela a donc été un problème aller dans les années 50.
Encore une fois, nous pouvons commencer à voir que, comme nous développer de nouvelles technologies pour traiter
les données, à droite, il ouvre la porte à de nouvelles solutions,
pour de nouveaux programmes, de nouveaux demandes de ces données.
Et vraiment, la gouvernance peut avoir été la raison
pourquoi nous avons développé certains de ces systèmes.
Mais les affaires devient rapidement le pilote derrière l'évolution
de la base de données et moderne le système de fichiers moderne.
>> Donc, la prochaine chose que a été soulevé dans les années 50
était le système de fichiers et le développement de stockage à accès aléatoire.
Ce était belle.
Maintenant, tout d'un coup, nous pouvons mettre notre fichiers partout sur ces disques durs
et nous pouvons accéder à ces données de façon aléatoire.
Nous pouvons analyser que informations sur les fichiers.
Et nous avons résolu tous le monde de problèmes avec le traitement des données.
>> Et qui a duré environ 20 ou 30 ans jusqu'à ce que l'évolution
de la base de données relationnelle, qui est où le monde nous avons décidé maintenant
besoin d'avoir un référentiel qui bat l'étalement des données dans le fichier
les systèmes que nous avons construit. Droit?
Trop de données distribués en trop endroits, la déduplication des données,
et le coût de stockage était énorme.
>> Dans les années 70, la ressource la plus chère un ordinateur qui avait été le stockage.
Le processeur était vu comme un coût fixe.
Quand je achète la boîte, le CPU fait un peu de travail.
Ça va être de savoir si la filature ça fonctionne réellement ou non.
Voilà vraiment un coût irrécupérable.
>> Mais ce qui me coûter un entreprise est le stockage.
Si je dois acheter plus de disques prochaine mois, qui est un coût réel que je paie.
Et que le stockage est coûteux.
>> Maintenant, nous avance rapide de 40 années et nous avons un problème différent.
Le calcul est maintenant le ressource la plus coûteuse.
Le stockage est pas cher.
Je veux dire, nous ne pouvons aller nulle part sur le Cloud et nous pouvons trouver de stockage pas cher.
Mais ce que je ne peux pas trouver de calcul est pas cher.
>> Ainsi, l'évolution des aujourd'hui la technologie, de la technologie de base de données,
est vraiment concentré autour bases de données distribuées
qui ne souffrent pas de le même type d'échelle
limitations de bases de données relationnelles.
Nous parlerons un peu ce que cela signifie réellement.
>> Mais l'une des raisons, et le pilote derrière this-- nous
parlé de la pression des données.
La pression des données est quelque chose qui entraîne l'innovation.
Et si vous regardez plus les cinq dernières années,
ceci est un tableau de ce que les données charge à travers l'entreprise générale
ressemble dans les cinq dernières années.
>> Et la règle générale de pouce ces days-- Si vous allez Google--
est de 90% des données qui nous stockons aujourd'hui, et il était
généré au cours des deux dernières années.
D'ACCORD.
Maintenant, ce ne est pas une tendance qui est nouveau.
Ceci est une tendance qui a été sortir pour 100 ans.
Depuis Herman Hollerith développé la carte de pointage,
nous avons construit des référentiels de données et la collecte de données à des vitesses phénoménales.
>> Donc, au cours des 100 dernières années, nous avons vu cette tendance.
Cela ne va pas changer.
À l'avenir, nous allons voir ce, sinon une tendance accélérée.
Et vous pouvez voir à quoi ça ressemble.
>> Si une entreprise en 2010 avait un téraoctet de données sous gestion,
aujourd'hui que signifie qu'ils sont la gestion de 6,5 pétaoctets de données.
Voilà 6.500 fois plus de données.
Et je sais que cela.
Je travaille avec ces entreprises chaque jour.
Il ya cinq ans, je parlerait aux entreprises
qui me parler de ce qu'une douleur il est de gérer des téraoctets de données.
Et ils parleraient pour moi sur la façon dont nous voyons
que ce va probablement être un pétaoctet ou deux
au sein d'un couple d'années.
>> Ces mêmes sociétés aujourd'hui, je vais rencontrer,
et ils me parler de la problème y at-il d'avoir la gestion
des dizaines, 20 pétaoctets de données.
Donc, l'explosion de la données de l'industrie
est le moteur de l'énorme besoin de meilleures solutions.
Et la base de données relationnelle est tout simplement pas à la hauteur de la demande.
>> Et donc il ya un linéaire corrélation entre les données de pression
et l'innovation technique.
L'histoire nous a montré ce, que dans le temps,
chaque fois que le volume de données qui doit être traité
dépasse la capacité du système de le traiter en un temps raisonnable
ou à un coût raisonnable, puis les nouvelles technologies
sont inventés pour résoudre ces problèmes.
Ces nouvelles technologies, à son tour, ouvrir la porte
une autre série de problèmes, dont est la collecte des données encore plus.
>> Maintenant, on ne va pas pour arrêter cela.
Droit?
On ne va pas pour arrêter cela.
Pourquoi?
Parce que vous ne pouvez pas tout savoir qu'il ya à savoir dans l'univers.
Et tant que nous avons été en vie, tout au long de l'histoire de l'homme,
nous avons toujours poussé à en savoir plus.
>> Donc, il semble que chaque pouce nous nous déplaçons sur le chemin de la découverte scientifique,
nous multiplions la quantité de données que nous devons traiter de façon exponentielle
comme nous découvrir plus et de plus en plus sur les rouages ​​de la vie,
sur la façon dont fonctionne l'univers, à propos de entraînement de la découverte scientifique,
et que l'invention nous faisons aujourd'hui.
Le volume de données tout augmente continuellement.
Donc, être en mesure de faire face à ce problème est énorme.
>> Donc, l'une des choses nous attendons que pourquoi NoSQL?
Comment ne NoSQL résoudre ce problème?
Eh bien, bases de données relationnelles, Structured Query Language,
SQL-- qui est vraiment une construction de la relationnelle database-- ces choses sont
optimisé pour le stockage.
>> Retour dans les années 70, encore une fois, disque est coûteux.
L'exercice de provisionnement du stockage dans l'entreprise est sans fin.
Je sais.
Je l'ai vécu.
Je l'ai écrit des pilotes de stockage pour un société de superserver Enterprised
Retour dans les années 90.
Et la ligne de fond engrange une autre baie de stockage était juste quelque chose qui
événements tous les jours dans l'entreprise.
Et il n'a jamais cessé.
Stockage de densité supérieure, la demande pour le stockage haute densité,
et pour le stockage plus efficace devices-- il n'a jamais arrêté.
>> Et NoSQL est une grande technologie parce qu'il normalise les données.
Il de-duplication des données.
Il place les données dans une structure qui est agnostique à chaque modèle d'accès.
Plusieurs applications peuvent frapper que Base de données SQL, exécuter des requêtes ad hoc,
et obtenir des données sous la forme qu'ils besoin de traiter de leurs charges de travail.
Cela semble fantastique.
Mais la ligne de fond est avec tout système, si elle est agnostique à tout,
il est optimisé pour rien.
D'accord?
>> Et qui est ce que nous obtenons avec la base de données relationnelle.
Il est optimisé pour le stockage.
Il est normalisé.
Il est relationnelle.
Il prend en charge les requêtes ad hoc.
Et lui et il échelles verticalement.
>> Si je dois obtenir une plus grande base de données SQL ou une base de données SQL plus puissant,
Je vais acheter un plus gros morceau de fer.
D'accord?
Je travaille avec un grand nombre de clients qui ont été par le biais d'importantes améliorations
dans leur infrastructure SQL seulement à savoir six mois plus tard,
ils sont à nouveau frapper le mur.
Et la réponse d'Oracle ou MSSQL ou quelqu'un d'autre est d'obtenir une boîte plus grande.
Eh bien, tôt ou tard, vous ne pouvez pas acheter un plus grande boîte, et que ce problème réel.
Nous devons effectivement changer les choses.
Alors d'où vient ce travail?
Il fonctionne bien pour déconnecté analyse, les charges de travail de type OLAP.
Et qui est vraiment là SQL appartient.
Maintenant, il est utilisé aujourd'hui dans de nombreux en ligne type de traitement transactionnel
applications.
Et cela fonctionne très bien au un certain niveau d'utilisation,
mais il n'a tout simplement pas à l'échelle la façon dont NoSQL fait.
Et nous allons parler un peu peu pourquoi ce qui est.
>> Maintenant, NoSQL, d'autre part, est plus optimisé pour calculer.
D'accord?
Il est pas agnostique le modèle d'accès.
Est ce que nous appelons de-normalisée une structure ou une structure hiérarchique.
Les données en une base de données relationnelle est réunis à partir de plusieurs tables
pour produire le point de vue que vous avez besoin.
Les données dans une base de données NoSQL sont stockées dans un document
contient la structure hiérarchique.
Toutes les données qui serait normalement réunis pour produire cette vue
sont stockées dans un seul document.
Et nous allons parler un peu de comment ça marche dans un couple de graphiques.
>> Mais l'idée ici est que vous stockez vos données que ces points de vue instancié.
D'accord?
Vous évolutivité horizontale.
Droit?
Si je dois augmenter la taille de mon groupe NoSQL,
Je ne dois pas avoir une plus grande boîte.
Je reçois une autre boîte.
Et je Cluster ceux ensemble, et je peux Shard que les données.
Nous parlerons un peu ce sharding est, pour être
capable d'évoluer cette base de données à travers de multiples dispositifs physiques
et de supprimer la barrière qui exige de moi à l'échelle verticale.
>> Donc, il est vraiment construit pour ligne le traitement des transactions et de l'échelle.
Il ya une grande distinction ici entre les rapports, non?
Compte-rendu, je ne connais pas la questions que je vais poser.
Droit?
Reporting-- si quelqu'un de mon département marketing
veut just-- combien de mes clients avoir cette caractéristique particulière qui
acheté sur ce day-- Je ne sais pas ce interroger qu'ils vont demander.
Donc je dois être agnostique.
>> Or, dans une ligne application transactionnelle,
Je sais quelles sont les questions que je pose.
Je construit pour l'application un flux de travail très spécifique.
D'accord?
Donc, si je optimiser les données stocker pour soutenir ce flux de travail,
ça va être plus rapide.
Et voilà pourquoi peut NoSQL vraiment accélérer la livraison
de ces types de services.
D'accord.
>> Donc, nous allons entrer dans un peu de théorie ici.
Et certains d'entre vous, vos yeux pourrait reculer un peu.
Mais je vais essayer de le garder niveau aussi élevé que possible.
Donc, si vous êtes dans le projet la gestion, il est
un produit d'assemblage appelé le triangle de contraintes.
D'ACCORD.
Le triangle des Contraint diktats vous ne pouvez pas tout avoir tout le temps.
Vous ne pouvez pas avoir votre gâteau et le manger aussi.
Donc, dans la gestion de projet, ce triangle contraintes est que vous pouvez avoir pas cher,
vous pouvez le faire rapidement, ou vous pouvez avoir une bonne.
Choisis en deux.
Parce que vous ne pouvez pas avoir tous les trois.
Droit?
D'ACCORD.
>> Donc vous entendu parler de ce lot.
Il est une triple contrainte, triangle de la triple contrainte,
ou le triangle de fer est oftentimes-- quand vous parlez aux gestionnaires de projets,
ils vont parler.
Maintenant, les bases de données ont leur propre triangle de fer.
Et le triangle de fer des données est ce que nous appelons la PAC théorème.
D'accord?
>> PAC diktats théorème comment fonctionnent les bases de données
sous une condition très spécifique.
Et nous allons parler ce que cette condition est.
Mais les trois points du triangle, pour ainsi dire, sont C, la cohérence.
D'accord?
Donc, dans la PAC, la cohérence signifie que tous les les clients qui peuvent accéder à la base de données
aura toujours une très vue cohérente des données.
Personne ne va voir deux choses différentes.
D'accord?
Si je vois la base de données, Je vois la même vue
que mon partenaire qui voit la même base de données.
Voilà la cohérence.
>> Disponibilité signifie que si le base de données en ligne, si elle peut être atteint,
que tous les clients seront toujours être capable de lire et d'écrire.
D'accord?
Ainsi, chaque client qui peut lire la base de données
sera toujours en mesure de lecture données de données et à écrire.
Et si tel est le cas, il est un système disponible.
>> Et le troisième point est ce que nous appelons la tolérance de partition.
D'accord?
Des moyens de tolérance de partition que le système fonctionne bien
en dépit de réseau physique cloisons entre les nœuds.
D'accord?
Donc nœuds dans le cluster ne peut pas parler les uns aux autres, ce qui se passe?
D'accord.
>> Bases de données relationnelles Donc choisir-- vous pouvez choisir deux de ces derniers.
D'ACCORD.
Bases de données relationnelles donc choisir d'être cohérent et disponible.
Si la partition qui se passe entre les DataNodes dans le magasin de données,
la base de données se bloque.
Droit?
Il va juste en bas.
D'ACCORD.
>> Et c'est pourquoi ils ont à grandir avec de grosses boîtes.
Droit?
Parce qu'il n'y a no-- généralement, un cluster base de données, il n'y a pas beaucoup d'entre eux
qui fonctionnent de cette façon.
Mais la plupart des bases de données échelle verticalement dans une seule boîte.
Parce qu'ils ont besoin d'être cohérente et disponible.
Si une partition devait être injectée, alors vous auriez à faire un choix.
Vous devez faire un choix entre étant compatible et disponible.
>> Et qui est ce que les bases de données NoSQL font.
D'accord.
Donc, une base de données NoSQL, il est disponible en deux saveurs.
Nous have-- bien, il vient en plusieurs saveurs,
mais il est livré avec deux de base characteristics-- ce
nous pourrions appeler la base de données de CP, ou d'un la tolérance et la partition cohérente
système.
Ces gars-là font le choix que lorsque les noeuds perdent le contact avec l'autre,
on ne va pas pour permettre les gens à écrire plus.
D'accord?
>> Jusqu'à cette partition est supprimée, l'accès en écriture est bloqué.
Cela signifie qu'ils ne sont pas disponibles.
Ils sont cohérents.
Quand on voit que partition elle-même injecter,
nous sommes maintenant cohérente, parce que nous ne sommes pas aller
pour permettre la modification des données sur deux côtés de la cloison de façon indépendante
les uns des autres.
Nous devrons rétablir la communication
avant toute mise à jour les données sont admis.
D'accord?
>> La saveur prochaine serait un système AP, ou un disponible et partagé
Système de tolérance.
Ces gars-là ne se soucient pas.
Droit?
Tout nœud qui obtient un écrivons, nous allons le prendre.
Donc, je suis reproduire mes données sur plusieurs nœuds.
Ces nœuds obtiennent un client, client vient en, dit, je vais écrire des données.
Noeud dit, pas de problème.
Le noeud à côté de lui se une écriture sur le même enregistrement,
il va dire aucun problème.
Quelque part en arrière sur la fin de dos, que les données va répliquer.
Et puis quelqu'un va réaliser, uh-oh, ils se rendront compte système, uh-oh,
il ya eu une mise à jour pour les deux côtés.
Qu'est-ce qu'on fait?
Et ce qu'ils font est alors ils font quelque chose qui
leur permet de résoudre cet état de données.
Et nous allons parler que, dans la liste suivante.
>> Chose à souligner ici.
Et je ne vais pas être trop beaucoup en cela, parce que ce
pénètre dans la théorie de données de profondeur.
Mais il ya une transactionnel cadre qui
courses dans un système relationnel qui me permet de faire des mises à jour en toute sécurité
à plusieurs entités dans la base de données.
Et ces mises à jour auront lieu tout à la fois ou pas du tout.
Et ce qu'on appelle les transactions ACID.
D'accord?
>> ACIDE nous donne atomicité, cohérence, l'isolement, et la durabilité.
D'accord?
Cela signifie atomiques, les transactions, tout mes mises à jour se produisent soit ou ils ne le font pas.
La cohérence signifie que la base de données sera toujours
être amené dans une cohérentes Etat après une mise à jour.
Je ne quitterai jamais la base de données dans un mauvais état après avoir appliqué une mise à jour.
D'accord?
>> Donc, il est un peu différent que la cohérence de la PAC.
Signifie la cohérence de la PAC tout mon les clients peuvent toujours voir les données.
Signifie que, lorsque la consistance ACIDE une transaction est fait, les données de bon.
Mes relations sont tous bons.
Je ne vais pas à supprimer une ligne de parent et laisser un groupe d'enfants orphelins
dans une autre table.
Il ne peut pas se passer si je suis cohérente dans une transaction acide.
>> Isolement signifie que les transactions toujours se produire une après l'autre.
Le résultat de la fin de données sera le même état
comme si ces transactions qui ont été émis simultanément
ont été exécutés en série.
Il est donc la concurrence contrôle dans la base de données.
Donc, fondamentalement, je ne peux pas incrémenter le même valeur deux fois avec deux opérations.
>> Mais si je dis ajouter 1 à cette valeur, et deux opérations viennent dans
et essayer de le faire, on est va y arriver en premier
et de l'autre allez y arriver après.
Donc à la fin, je ajouté deux.
Vous voyez ce que je veux dire?
D'ACCORD.
>> La durabilité est assez simple.
Lorsque la transaction est reconnu, il est
allez y être encore si le système se bloque.
Lorsque ce système récupère, qui transaction qui a été commis
est en fait va être là.
Voilà donc les garanties des transactions ACID.
Ce sont de belles garanties jolie à disposer sur une base de données,
mais ils viennent à ce prix.
Droit?
>> Étant donné que le problème avec ce cadre est
si il y a une partition dans les données ensemble, je dois prendre une décision.
Je vais avoir à permettre mises à jour sur un côté ou de l'autre.
Et si cela arrive, alors je suis ne va plus
pour être en mesure de maintenir ces caractéristiques.
Ils ne seront pas cohérents.
Ils ne seront pas isolés.
Cette est l'endroit où il se décompose pour les bases de données relationnelles.
Ceci est la raison relationnelle bases de données échelle verticale.
>> D'autre part, nous avons ce qu'on appelle la technologie de BASE.
Et ce sont des bases de données NoSQL vos.
D'accord.
Donc, nous avons notre CP, bases de données AP.
Et ce sont ce que vous appelez essentiellement disponibles, état mou, finalement
cohérent.
D'accord?
>> Fondamentalement disponibles, parce ils sont tolérants partition.
Ils seront toujours là, même si il ya
une partition de réseau entre les noeuds.
Si je peux parler à un nœud, je suis va être en mesure de lire les données.
D'accord?
Je ne pourrais pas toujours être capable d'écrire données si je suis une plate-forme cohérente.
Mais je serai en mesure de lire les données.
>> L'état indique douce que quand je lis que les données,
il pourrait ne pas être le même que les autres nœuds.
Si un droit a été émis sur un noeud ailleurs dans le cluster
et il n'a pas répliqué à travers le grappe encore quand je lis que les données,
cet état pourrait ne pas être compatible.
Cependant, il sera éventuellement cohérentes,
ce qui signifie que lorsqu'une écriture est réalisée dans le système,
il se répliquera dans les noeuds.
Et finalement, l'état sera mis en ordre,
et ce sera un état cohérent.
>> Maintenant, le théorème CAP vraiment joue que dans un seul état.
Cette condition est quand cela arrive.
Parce que chaque fois qu'il est en fonctionnement mode normal, il n'y a pas de partition,
tout est conforme et disponible.
Vous vous inquiétez seulement PAC quand nous avons cette partition.
Donc, ce sont rares.
Mais comment le système réagit lorsque ceux- se produisent dicter ce type de système
nous traitons.
>> Donc, nous allons jeter un oeil à ce que qui ressemble à des systèmes d'AP.
D'accord?
AP Systems viennent dans deux saveurs.
Ils viennent dans la saveur qui est un master master, 100%, toujours disponible.
Et ils viennent dans le autre saveur, qui dit,
vous savez quoi, je vais vous inquiétez à propos de cette chose de partitionnement
lorsque se produit une partition réelle.
Sinon, il va y être primaire nœuds qui va prendre les droits.
D'accord?
>> Donc, si nous quelque chose comme Cassandra.
Cassandra serait un maître maître, me laisse écrire à toute noeud.
Donc ce qui arrive?
Je dois donc un objet dans le base de données qui existe sur deux noeuds.
Appelons cet objet S. Nous avons donc l'Etat pour S.
Nous avons quelques opérations sur S qui sont en cours.
Cassandra me permets écrire à plusieurs nœuds.
Alors disons que je reçois un écrire pour s à deux noeuds.
Eh bien, ce qui finit par se produire est nous appelons ce qu 'un événement de partitionnement.
Il ne peut pas être un partition de réseau physique.
Mais en raison de la conception du système, il est
effectivement partitionnement dès que je reçois une écriture sur deux noeuds.
Il me forçant à ne pas écrire tout au long d'un nœud.
Je vous écris sur deux nœuds.
D'accord?
>> Alors maintenant, je dois deux états.
D'accord?
Ce qu'il va se passer est tôt ou tard,
il va y avoir un événement de réplication.
Il va y avoir ce que nous appelé récupération de partition, qui
est où ces deux États revenir ensemble
et il va y avoir un algorithme qui fonctionne à l'intérieur de la base de données,
décide quoi faire.
D'accord?
Par défaut, dernière mise à jour gagne dans la plupart des systèmes d'AP.
Donc, il ya habituellement une algorithme par défaut, ce qui
qu'ils appellent un rappel fonction, quelque chose qui
sera appelé lorsque cette condition est détecté pour exécuter une certaine logique
pour résoudre ce conflit.
D'accord?
Le rappel et par défaut par défaut dans la plupart des bases de données résolveur AP
est, devinez quoi, timestamp gagne.
Ce fut la dernière mise à jour.
Je vais mettre ce jour là.
Je peux vider ce record que je déversés au large dans un journal de reprise
de sorte que l'utilisateur peut revenir plus tard et dire, bon, il y avait une collision.
Qu'est ce qui s'est passé?
Et vous pouvez réellement vider un record de toutes les collisions et les reculs
et de voir ce qui se passe.
>> Maintenant, en tant qu'utilisateur, vous pouvez aussi inclure une logique qui en rappel.
Ainsi, vous pouvez changer cela opération rappel.
Vous pouvez dire, hey, je veux pour remédier à ces données.
Et je veux essayer de fusionner ces deux dossiers.
Mais cela est à vous.
La base de données ne sait pas comment faire que par défaut. La plupart du temps,
la seule chose que la base de données sait faire est de dire,
celui-ci était le dernier enregistrement.
Voilà celui qui va gagner, et que la valeur est, je vais mettre.
Une fois que la récupération de partition et la réplication se produit,
nous avons notre Etat, qui est maintenant le premier, qui est
l'état de fusion de tous ces objets.
Donc systèmes AP ont cette.
Systèmes de CP ne doivent à vous en soucier.
Parce que dès que vient une partition en jeu, ils arrêtent tout simplement prendre
écrit.
D'accord?
Donc, ce qui est très facile à traiter étant compatible
quand vous ne l'acceptez pas de mises à jour.
Voilà avec les systèmes de CP font.
D'accord.
>> Parlons donc un peu peu de modèles d'accès.
Lorsque nous parlons de NoSQL, il est tout sur le modèle d'accès.
Maintenant, SQL est ad hoc, les requêtes.
Il est relationnelle magasin.
Nous ne devons pas nous inquiéter sur le modèle de l'accès.
Je vous écris une requête très complexe.
Il va chercher les données.
Voilà ce que cela ressemble comme, la normalisation.
>> Donc, dans cette structure particulière, nous cherchons à un catalogue de produits.
Je dois différents types de produits.
Je dois livres.
Je dois albums.
Je dois vidéos.
La relation entre les produits et l'un quelconque de ces livres, albums,
et vidéos tables est de 1: 1.
D'accord?
Je dois un ID de produit, et qui correspond d'identité
un livre, un album ou une vidéo.
D'accord?
Voilà une relation 1: 1 à travers ces tableaux.
>> Maintenant, tout ce qu'ils books-- avoir des propriétés est de racine.
Pas de problème.
C'est génial.
One-to-one relation, je reçois tout les données que je besoin de décrire ce livre.
Album Albums-- ont pistes.
Ceci est ce que nous appelons un à plusieurs.
Chaque album pourrait avoir de nombreuses pistes.
Ainsi, pour chaque piste sur l'album, je pourrait avoir
un autre record dans cette table enfant.
Je crée donc un enregistrement dans ma table d'albums.
Je crée plusieurs enregistrements dans le tableau des titres.
Un-à-plusieurs.
>> Cette relation est ce que nous appelons many-to-many.
D'accord?
Vous voyez que les acteurs pourraient être dans de nombreux films, de nombreuses vidéos.
Donc, ce que nous faisons est que nous mettons cette cartographie table entre ceux-ci, dont il vient
cartes de l'ID de l'acteur à l'ID de la vidéo.
Maintenant, je peux créer une requête les jointures vidéos à travers acteur vidéo sur les acteurs,
et il me donne une belle liste de tous les films et tous les acteurs
qui étaient dans ce film.
>> D'ACCORD.
Alors on y va.
One-to-one est le plus haut niveau relation; un-à-plusieurs,
Album à des pistes; plusieurs à plusieurs.
Ce sont le plus haut niveau de trois- relations dans une base de données.
Si vous savez comment ceux relations travaillent ensemble,
alors vous savez beaucoup de choses à propos de la base de données déjà.
Donc NoSQL fonctionne un peu différemment.
Pensons à une seconde ce qu'il On dirait d'aller chercher tous mes produits.
>> Dans un magasin relationnelle, je vouloir obtenir tous mes produits
sur une liste de tous mes produits.
Cela fait beaucoup de questions.
Je suis une requête pour tous mes livres.
Je suis une requête de mes albums.
Et je suis une requête pour toutes mes vidéos.
Et je suis arrivé à mettre tous ensemble dans une liste
et servez-le remonter à la demande qui a fait la demande.
>> Pour obtenir mes livres, je me joins Produits et livres.
Pour obtenir mes albums, je suis arrivé à rejoindre Produits, Albums, et les pistes.
Et pour obtenir mes vidéos, je dois à se joindre à Products Vidéos,
rejoindre travers Acteur Vidéos, et apporter les acteurs.
Voilà donc trois requêtes.
Requêtes très complexes assembler un jeu de résultats.
>> Voilà moins de optimale.
Voilà pourquoi, lorsque nous parlons sur une structure de données qui est
construit pour être agnostique à l'accès pattern-- bien que ce grand.
Et vous pouvez voir ce qui est vraiment belle la façon dont nous avons organisé les données.
Et vous savez quoi?
Je dois seulement un record pour un acteur.
>> C'est super.
Je l'ai dédupliquées tous mes acteurs, et je maintenais mes associations
dans ce tableau de la cartographie.
Cependant, l'obtention des données devient hors coûteux.
Je l'envoi de la CPU dans le système rejoindre ces structures de données ensemble
pour être en mesure de tirer que les données en arrière.
>> Alors, comment puis-je obtenir à ce sujet?
Dans NoSQL il est à propos de agrégation, non normalisation.
Donc, nous voulons dire que nous voulons soutenir le modèle d'accès.
Si le motif d'accès les applications,
Je dois obtenir tous mes produits.
Mettons tous les produits dans un tableau.
Si je mets tous les produits dans un tableau, Je peux vous suffit de sélectionner tous les produits
à partir de cette table et je comprends tout.
Eh bien, comment puis-je faire cela?
Eh bien dans NoSQL il n'y a pas la structure de la table.
Nous parlerons un peu comment cela fonctionne dans Dynamo DB.
Mais vous ne devez pas la même les attributs et les mêmes propriétés
dans chaque rangée, dans chaque simple article, comme vous le faites dans une table SQL.
Et ce que cela me permets à faire est beaucoup de choses
et me donner beaucoup de flexibilité.
Dans ce cas particulier, je avoir mes documents produits.
Et dans ce cas particulier Ainsi, tout
est un document dans le tableau des produits.
Et le produit pour un livre pourrait avoir un ID de type qui spécifie un livre.
Et l'application passeraient sur cette ID.
>> Au niveau de l'application, je vais à-dire oh, ce type d'enregistrement est-ce?
Oh, il est un record de livre.
Réservez dossiers ont ces propriétés.
Permettez-moi de créer un objet livre.
Donc, je vais remplir le livre objet avec cet article.
Article suivant vient et dit, quel est cet objet?
Cet article est un album.
Oh, je suis toute une différente routine de traitement pour que,
car il est un album.
Vous voyez ce que je veux dire?
>> Donc, l'application tier-- I il suffit de sélectionner tous ces dossiers.
Ils commencent tous à venir dans.
Ils pourraient être tous les différents types.
Et il est la logique de l'application qui commute à travers ces types
et décide comment les traiter.
>> Encore une fois, nous sommes donc l'optimisation de la le schéma de combinaison d'accès.
Nous le faisons par effondrer ces tables.
Nous sommes fondamentalement en prenant ces structures normalisées,
et nous construisons structures hiérarchiques.
A l'intérieur de chacun de ces enregistrements Je vais voir les propriétés de tableau.
>> A l'intérieur de ce document pour les albums, Je vois réseaux de pistes.
Ces pistes become-- maintenant il est essentiellement cette table enfant
existe ici, dans cette structure.
Donc, vous pouvez le faire dans DynamoDB.
Vous pouvez le faire dans MongoDB.
Vous pouvez le faire dans une base de données NoSQL.
Créer ces types de structures de données hiérarchiques
qui vous permettent de récupérer des données très rapidement parce que maintenant je
ne pas avoir à se conformer.
Quand je insérer une ligne dans les chansons table, ou une ligne dans le tableau des albums,
Je dois à se conformer à ce schéma.
Je dois avoir l'attribut ou la propriété qui est défini sur cette table.
Chacun d'entre eux, lorsque je insère cette ligne.
Cela ne veut pas le cas dans NoSQL.
>> Je peux avoir totalement différent propriétés dans chaque document
que je l'insère dans la collection.
Donc mécanisme très puissant.
Et il est vraiment comment vous optimiser le système.
Parce que maintenant cette requête, la place de se joindre à tous ces tableaux
et l'exécution d'une demi-douzaine de requêtes à retirer les données que je dois,
Je exécution d'une requête.
Et je itération à travers les résultats fixés.
il vous donne une idée de la puissance de NoSQL.
Je vais type de déraper ici et parler un peu à ce sujet.
Ceci est plus du genre commercialisation ou technology--
la commercialisation de la technologie type de discussion.
Mais il est important de comprendre parce que si nous regardons en haut
ici, à ce tableau, ce que nous cherchons à
est ce que nous appelons le la technologie courbe de battage.
Et ce que cela signifie est slideshows nouveaux entre en jeu.
Les gens pensent qu'il est génial.
Je l'ai résolu tous mes problèmes.
>> Cela pourrait être la fin tout, être tout à tout.
Et ils commencent à l'utiliser.
Et ils disent, ça ne fonctionne pas.
Ce n'est pas juste.
Le vieux truc était mieux.
Et ils retournent à faire les choses comme elles étaient.
Et puis finalement ils vont, vous savez quoi?
Ce truc est pas si mal.
Oh, ce Voilà comment cela fonctionne.
Et une fois qu'ils comprendre comment il œuvres, ils commencent à aller mieux.
>> Et le plus drôle à ce sujet est, il sorte de lignes jusqu'à ce que
nous appelons la courbe d'adoption de la technologie.
Donc ce qui arrive est que nous avons certains déclenchement de la technologie de tri.
Dans le cas de bases de données, il est la pression de données.
Nous avons parlé des points d'eau élevés de la pression de données à travers le temps.
Lorsque que la pression de données atteint un certain le point, qui est un élément déclencheur de la technologie.
>> Ça devient trop cher.
Il prend trop de temps pour traiter les données.
Nous avons besoin de quelque chose de mieux.
Vous obtenez les innovateurs là-bas courir,
essayer de savoir quelle est la solution.
Quelle est la nouvelle idée?
>> Quelle est la meilleure façon de faire cette chose?
Et ils viennent avec quelque chose.
Et les personnes atteintes de la vraie douleur, les gars à la fine pointe,
ils vont sauter sur elle, parce qu'ils ont besoin d'une réponse.
Maintenant, ce qui inévitablement et happens-- ça se passe en ce moment dans NoSQL.
Je le vois tout le temps.
>> Ce qui se passe est inévitablement les gens commencent à l'aide du nouvel outil
de la même manière ils ont utilisé l'ancien outil.
Et ils découvrent qu'il ne fonctionne pas si bien.
Je ne me souviens pas qui je suis parler plus tôt aujourd'hui.
Mais il est comme, lorsque le marteau-piqueur a été inventé,
les gens ne se balancer au-dessus leur tête pour casser le béton.
>> Mais qui est ce qui est passe avec NoSQL aujourd'hui.
Si vous marchez dans la plupart des magasins, ils essaient d'être boutiques NoSQL.
Ce qu'ils font est ils utilisent NoSQL,
et ils le charger pleine de schéma relationnel.
Parce que voilà comment ils conçoivent des bases de données.
Et ils se demandent, pourquoi est- il pas de très bons résultats?
Boy, cette chose pue.
Je devais maintenir toute ma rejoint in-- il est comme, non, non.
Maintenir rejoint?
Pourquoi êtes-vous joignez données?
Vous ne participez pas à des données dans NoSQL.
Vous les agréger.
>> Donc, si vous voulez éviter cela, apprendre fonctionnement de l'outil avant de vous
commencer à l'utiliser.
Ne pas essayer d'utiliser les nouveaux outils de la même manière que vous avez utilisé les outils anciens.
Vous allez avoir une mauvaise expérience.
Et à chaque fois voilà ce qu'il en est.
Lorsque nous commençons à venir ici, il est parce que les gens ont compris
comment utiliser les outils.
>> Ils ont fait la même chose quand bases de données relationnelles ont été inventés,
et ils remplaçaient les systèmes de fichiers.
Ils ont essayé de construire des systèmes de fichiers bases de données relationnelles
parce que ce que les gens ont compris.
Cela n'a pas fonctionné.
Donc, comprendre les meilleures pratiques de la technologie vous travaillez avec
est énorme.
Très important.
>> Donc, nous allons entrer dans DynamoDB.
DynamoDB est SAPN entièrement géré plateforme NoSQL.
Ce qui ne signifie entièrement géré?
Cela signifie que vous ne devez pas soucier vraiment de quoi que ce soit.
>> Vous venez, vous dites nous, je besoin d'une table.
Il a besoin de cette grande capacité.
Vous appuyez sur le bouton, et la fourniture de nous toute l'infrastructure derrière la scène.
Maintenant que est énorme.
>> Parce que quand vous parlez sur l'extension de la base de données,
NoSQL clusters de données à échelle, pétaoctets fonctionnement,
exécutant des millions de transactions par seconde,
ces choses ne sont pas de petites grappes.
Nous parlons des milliers de cas.
Gestion des milliers de cas, même des instances virtuelles,
est une vraie douleur dans le cul.
Je veux dire, pense à tous un temps exploitation correctif du système sort
ou une nouvelle version de la base de données.
Qu'est-ce que ça veut dire vous opérationnel?
Cela signifie que vous avez 1200 serveurs qui ont besoin d'être mis à jour.
Maintenant, même avec l'automatisation, qui peut prendre un certain temps.
Cela peut causer beaucoup de maux de tête opérationnelles,
parce que je pourrais avoir des services vers le bas.
>> Comme je mettre à jour ces bases de données, je pourrait faire déploiements vert bleu
où je déployer et mettre à niveau la moitié de ma nœuds, et ensuite mettre à niveau l'autre moitié.
Prenez ceux d'en bas.
Ainsi, la gestion de l'infrastructure l'échelle est extrêmement douloureuse.
Et AWS prendre que la douleur hors de lui.
Et bases de données NoSQL peut être extraordinairement douloureuse
en raison de la façon dont ils l'échelle.
>> L'échelle horizontale.
Si vous voulez obtenir une plus grande NoSQL base de données, vous achetez plusieurs noeuds.
Chaque nœud que vous achetez est un autre casse-tête opérationnel.
Donc laisser quelqu'un d'autre le faire pour vous.
AWS peut le faire.
>> Nous soutenons les valeurs de documents clés.
Maintenant, nous ne sommes pas allés trop dans l'autre tableau.
Il ya beaucoup de différents saveurs de NoSQL.
Ils sont tous les types d'obtenir munged ensemble à ce point.
Vous pouvez regarder DynamoDB et dire oui, nous sommes à la fois un document et une valeur de clé
stocker ce point.
Et vous pouvez faire valoir les caractéristiques de une sur l'autre.
Pour moi, beaucoup de ce qui est vraiment six d'une demi-douzaine de l'autre.
Chacune de ces technologies est un technologie fine et une solution bien.
Je ne dirais pas MongoDB est meilleur ou pire que Couch, puis Cassandra,
puis Dynamo, ou vice versa.
Je veux dire, ce ne sont que des options.
>> Il est rapide et il est conforme à toutes les échelles.
Donc, ceci est un des plus grands bonus que vous obtenez avec AWS.
Avec DynamoDB est la capacité pour obtenir un faible chiffre unique
milliseconde de latence à toute échelle.
Cela a été un objectif de conception du système.
Et nous avons des clients qui font des millions de transactions par seconde.
>> Maintenant, je vais passer en revue certains de ceux des cas d'utilisation en quelques minutes ici.
Control-- d'accès intégré nous avons ce que nous appelons
Identity Access Management, ou IAM.
Il imprègne chaque système, chaque service AWS propose.
DynamoDB ne fait pas exception.
Vous pouvez contrôler l'accès pour les tables de DynamoDB.
Sur tous vos comptes par AWS la définition des rôles et des autorisations d'accès
dans l'infrastructure IAM.
>> Et il est un élément clé et solidaire en ce que nous appelons l'événement de programmation Driven.
Maintenant, ceci est un nouveau paradigme.
>> Public: Comment est votre taux de vrai positifs par rapport aux faux négatifs
sur votre système de contrôle d'accès?
RICK HOULIHAN: vrais positifs par rapport à des faux négatifs?
PUBLIC: ce retour vous devriez être retournez?
Par opposition à de temps en temps il ne retourne pas quand il devrait valider?
>> RICK HOULIHAN: Je ne saurais vous le dire.
Si il ya des échecs que ce soit à ce sujet,
Je ne suis pas la personne à poser cette question particulière.
Mais cela est une bonne question.
Je serais curieux de savoir moi-même, en fait.
>> Et là encore, nouveau paradigme est programmation événementielle.
Telle est l'idée que vous pouvez déployer des applications complexes
peut fonctionner une très haute échelle très, sans infrastructure que ce soit.
Sans aucune fixe infrastructures que ce soit.
Et nous allons parler un peu à propos de ce que cela signifie que nous
passer à la prochaine quelques graphiques.
>> La première chose que nous ferons est que nous allons parler de tables.
Les types de données de l'API pour Dynamo.
Et la première chose que vous aurez remarquerez quand vous regardez ce,
si vous êtes familier avec toute base de données, bases de données ont vraiment deux types d'API
Je l'appellerais.
Ou deux ensembles de API.
Un de ceux serait API d'administration.
>> Les choses qu'ils prennent soin de les fonctions de la base de données.
Configuration du moteur de stockage, la mise en place et l'ajout de tables.
créer la base de données des catalogues et des instances.
Ces things-- dans DynamoDB, vous ont très courts, des listes courtes.
>> Donc, en d'autres bases de données, vous pourriez voir des dizaines
des commandes, des fonctions administratives commandes pour configurer
ces options supplémentaires.
Dans DynamoDB vous ne devez pas ceux parce vous ne configurez pas le système, nous le faisons.
Donc, la seule chose que vous devez faire est de me dire quelle taille dois-je la table.
Ainsi, vous obtenez une très ensemble limité de commandes.
>> Vous obtenez un CREATE TABLE mise à jour, le tableau, Supprimer de table, et de décrire le tableau.
Ce sont les seules choses vous avez besoin pour DynamoDB.
Vous n'êtes pas besoin d'un stockage configuration du moteur.
Je ne veux pas à vous soucier de la réplication.
Je ne veux pas à vous soucier de sharding.
>> Je ne veux pas à vous soucier sur l'un de ces trucs.
Nous faisons tout pour vous.
Voilà donc une énorme quantité de frais généraux qui est juste soulevé de votre assiette.
Ensuite, nous avons les opérateurs CRUD.
CRUD est quelque chose de ce que nous appel à la base de données qui est
Create, Update, Delete opérateurs.
Ce sont votre commune les opérations de base de données.
Des choses comme put l'article, obtenir un objet, la mise à jour articles, supprimer des éléments, requête par lot, numériser.
Si vous souhaitez numériser l'ensemble du tableau.
Tirez tout sur la table.
Une des belles choses sur DynamoDB est qu'il permet balayage parallèle.
Donc vous pouvez réellement me faire savoir combien les discussions que vous voulez exécuter sur cette analyse.
Et nous pouvons lancer ces discussions.
Nous pouvons tourner que de numériser jusqu'à sur plusieurs threads
de sorte que vous pouvez numériser l'ensemble du tableau espace très, très vite dans DynamoDB.
>> L'autre est que nous avons API ce que nous appelons notre API de flux.
On ne va pas parler trop beaucoup de ça maintenant.
Je dois une partie du contenu tard dans le pont à ce sujet.
Mais Streams est vraiment un running-- penser à elle comme le temps ordonné
et le changement de partition journal.
Tout ce qui se passe sur le tableau apparaît sur le flux.
>> Chaque écriture à la table montre sur le flux.
Vous pouvez lire ce flux, et vous pouvez faire des choses avec elle.
Nous allons parler de ce types de choses que vous
faire avec les choses comme la réplication, la création d'index secondaires.
Toutes sortes de vraiment cool choses que vous pouvez faire avec cela.
>> Types de données.
Dans DynamoDB, nous appuyons à la fois clé types de valeur et de documenter les données.
Sur le côté gauche de l'écran ici, nous avons nos types de base.
Principaux types de valeur.
Ce sont des chaînes, numéros, et les fichiers binaires.
>> Donc, seulement trois types de base.
Et puis vous pouvez avoir des ensembles de ceux-ci.
Une des belles choses sur NoSQL est vous pouvez contenir des tableaux que des propriétés.
Et avec DynamoDB vous pouvez contenir des tableaux des types de base comme une propriété de la racine.
>> Et puis il ya les types de documents.
Combien de gens sont familiers avec JSON?
Vous les gars familiers avec JSON autant?
Il est fondamentalement JavaScript, Objet, notation.
Il vous permet essentiellement définir une structure hiérarchique.
>> Vous pouvez enregistrer un document sur JSON DynamoDB utilisant des composants communs
ou blocs de construction qui sont disponibles dans la plupart des langages de programmation.
Donc, si vous avez Java, vous êtes regarder des cartes et des listes.
Je peux créer des objets qui Plan de la zone.
Une carte comme valeurs clés stockées sous forme de propriétés.
Et il pourrait avoir des listes de des valeurs au sein de ces propriétés.
Vous pouvez stocker ce complexe structure hiérarchique
comme un seul attribut d'un élément DynamoDB.
>> Donc tables dans DynamoDB, comme la plupart Bases de données NoSQL, tables ont des articles.
Dans MongoDB vous le feriez appeler ces documents.
Et ce serait la base de canapé.
Aussi une base de données documentaire.
Vous appelez ces documents.
Documents ou objets ont des attributs.
Les attributs peuvent exister ou pas exister sur la question.
Dans DynamoDB, il ya un attribut obligatoire.
Tout comme dans une base de données relationnelle, vous avez une clé primaire sur la table.
>> DynamoDB a ce que nous appelons une clé de hachage.
Touche Dièse doit être unique.
Alors, quand je définis une table de hachage, essentiellement ce que je dis
est chaque article aura une clé de hachage.
Et chaque clé de hachage doit être unique.
>> Chaque élément est défini par cette clé de hachage unique.
Et il ne peut en être un.
Ceci est OK, mais souvent ce que les gens ont besoin
est qu'ils veulent est ce hachage clé pour faire un peu plus
que de simplement être un identifiant unique.
Souvent, nous voulons utiliser cette clé de hachage comme l'agrégation de haut niveau seau.
Et la façon dont nous faisons cela est par ajoutant ce que nous appelons une clé de gamme.
>> Donc, si il est seulement un hachage table, ce doit être unique.
Si il est une table de hachage et de la gamme, la combinaison de la table de hachage et la gamme
doit être unique.
Alors, pensez-y de cette façon.
Si je dois un forum.
Et la forme a sujets, il a postes, et il a les réponses.
>> Donc, je pourrais avoir un hachage clé, qui est l'ID de rubrique.
Et je pourrais avoir une clé de gamme, qui est l'ID de réponse.
De cette façon, si je veux obtenir toutes les réponses pour sujet particulier,
Je peux juste interroger le hachage.
Je peux juste dire me donner tout les éléments qui ont ce hachage.
Et je vais obtenir toutes les questions , ou les poster sur le thème concerné.
Ces agrégations de haut niveau sont très importants.
Ils soutiennent l'accès principal motif de la demande.
D'une manière générale, cette est ce que nous voulons faire.
Nous voulons que table-- que vous chargez la table,
nous voulons structurer les données dans la table de telle manière
que l'application peut très récupérer rapidement les résultats.
Et souvent la façon de le faire est pour maintenir ces agrégations que nous
insérer les données.
Fondamentalement, nous écartons les données dans le seau brillant qu'il entre en jeu.
>> Touches de Range permettent hachage moi-- clés doivent être l'égalité.
Lorsque je questionne une table de hachage, je dois dire me donner un hachage qui équivaut à cela.
Lorsque je questionne une gamme, je peut dire me donne une gamme
ce qui est d'utiliser tout type de riche opérateur que nous soutenons.
Donnez-moi tous les éléments pour une table de hachage.
Est-il égal, supérieur, moins, ça commence avec,
Existe t-il entre ces deux valeurs?
Ainsi, ces types de requêtes de gamme que nous sommes toujours intéressés.
Maintenant, une chose à propos des données, lorsque vous regardez l'accès aux données, lorsque
vous accédez aux données, il est toujours à une agrégation.
Il est toujours sur les dossiers qui sont liés à ce produit.
Donnez-moi tout ici that's-- tous les transactions sur cette carte de crédit
pour le dernier mois.
Voilà une agrégation.
>> Presque tout ce que vous faites dans le base de données est une sorte d'agrégation.
Donc, être en mesure d'être en mesure de définir Ces godets et vous donner à ces choix
attributs pour être en mesure d'interroger sur, ces requêtes riches soutiennent beaucoup,
beaucoup, beaucoup de modèles d'accès de l'application.
>> Donc, l'autre chose de la touche dièse fait est qu'il nous donne un mécanisme
pour être en mesure de diffuser les données autour.
Bases de données NoSQL fonctionnent le mieux lorsque les données sont uniformément
distribué à travers le cluster.
Combien de gens sont familiers avec des algorithmes de hachage?
Quand je dis hachage et un hashing-- car un algorithme de hachage
est une manière d'être en mesure de générer une valeur aléatoire de toute valeur donnée.
Donc, dans ce cas particulier, le algorithme de hachage nous courons est ND 5 sur la base.
>> Et si je dois un ID, et cela est ma clé de hachage, je dois 1, 2, 3.
Quand je lance l'algorithme de hachage, il va revenir et dire,
ainsi 1 égale 7B, 2 est égal à 48, 3 = CD.
Ils sont répartis sur tout l'espace des clés.
Et pourquoi faites-vous cela?
Parce que cela fait en sorte que je peux mettre les dossiers sur plusieurs nœuds.
>> Si je fais cela incrémentielle, 1, 2, 3.
Et je dois une gamme de hachage courses dans ce cas particulier,
un petit espace de hachage, il fonctionne de 00 à FF,
alors les enregistrements vont venir et ils vont aller 1, 2, 3, 4, 5,
6, 7, 8, 9, 10, 11, 12.
Ce qui se produit?
Chaque insert va au même nœud.
Vous voyez ce que je veux dire?
>> Parce que quand je partage l'espace, et je répands ces documents à l'échelle,
et je partage, je vais dire partition 1 possède un espace dédié touche 0 à 54 ans.
Partition 2 est de 55 à 89.
Partition 3 est AA à FF.
Donc, si je suis en utilisant linéairement incrémentation ID, vous pouvez voir ce qui se passe.
1, 2, 3, 4, 5, 6, tout chemin jusqu'à 54.
Donc, comme je suis martelant le les enregistrements dans le système,
tout finit par aller à un nœud.
>> Ce n'est pas bien.
Voilà un anti-modèle.
Dans MongoDB qu'ils ont ce problème si vous ne l'utilisez une clé de hachage.
MongoDB vous donne la possibilité hachage de la valeur de clé.
Vous devriez toujours le faire, si vous utilisez un hachage incrémentation
clé dans MongoDB, ou vous serez clouer chaque écriture d'un noeud,
et vous limiterez votre écriture débit mal.
>> Public: Est-ce A9 169 en décimal?
>> RICK HOULIHAN: Ouais, il est quelque part par là.
A9, je ne sais pas.
Vous auriez à obtenir mon binaire au calculateur décimal.
Mon cerveau ne fonctionne pas comme ça.
AUDIENCE: Juste un rapide de vos commentaires Mongo.
Ainsi est l'ID d'objet qui vient nativement avec Mongo faire cela?
RICK HOULIHAN: Faut-il faire cela?
Si vous spécifiez.
Avec MongoDB, vous avez la possibilité.
Vous pouvez specify-- chaque document MongoDB doit avoir un ID de soulignement.
Voilà la valeur unique.
>> Dans MongoDB vous pouvez spécifier si pour hacher ou non.
Ils vous donnent juste l'option.
Si vous savez qu'il est aléatoire, pas de problème.
Vous ne devez pas le faire.
Si vous savez qu'il est pas aléatoire, que il est incrémentation, puis faire le hachage.
>> Maintenant, la chose à propos hachage, une fois que vous hachez
un value-- et cela est pourquoi clés de hachage sont toujours
requêtes uniques, parce que je l'ai changé la valeur, maintenant je ne peut pas faire une requête de gamme.
Je ne peux pas dire est-ce entre ceci ou cela,
parce que la valeur de hachage ne va pas comme équivalente à la valeur réelle.
Ainsi, lorsque vous hachage clé, il est seulement une égalité.
Voilà pourquoi, dans DynamoDB clé de hachage les requêtes sont toujours l'égalité seulement.
>> Alors maintenant, dans une gamme KEY-- quand je ajouter cette touche de gamme,
ces dossiers clés de gamme viennent tous et ils sont stockés sur la même partition.
Donc ils sont très rapidement, facilement récupéré parce que cela est le hachage,
cela est la gamme.
Et vous voyez tout avec le même hachage
est stocké sur le même espace de séparation.
Vous pouvez utiliser cette clé de gamme pour aider localiser vos données à proximité de son parent.
Alors, que vais-je vraiment fais ici?
Ceci est une relation un à plusieurs.
La relation entre une clé de hachage et la clé de gamme est un à plusieurs.
Je peux avoir des clés de hachage multiples.
Je ne peux avoir éventail multiple clés au sein de chaque clé de hachage.
>> Le hachage définit le parent, la gamme définit les enfants.
Donc vous pouvez voir qu'il ya ici analogique entre le produit d'assemblage relationnelle
et les mêmes types de construit en NoSQL.
Les gens parlent NoSQL comme non relationnelles.
Il est pas non relationnelles.
Les données possède toujours les relations.
Ces relations juste sont modélisés différemment.
Parlons un peu de peu de durabilité.
Lorsque vous écrivez à DynamoDB, écrit sont répliqués toujours à trois voies.
Ce qui signifie que nous avons trois AZ de.
AZ de zones de disponibilité sont.
Vous pouvez penser à une disponibilité Zone comme un centre de données
ou un ensemble de centres de données.
Ces choses sont géographiquement isolé de l'autre
à travers différentes zones de failles, à travers différents réseaux électriques et des plaines inondables.
Une défaillance de l'un AZ est pas va prendre une autre vers le bas.
Ils sont également liés ensemble avec la fibre noire.
Il prend en charge un sous 1 milliseconde de latence entre AZS.
Ainsi réplications de données en temps réel capable de AZS multiples.
>> Et souvent multiples déploiements AZ répondre aux exigences de haute disponibilité
la plupart des organisations d'entreprise.
Donc DynamoDB se propage à travers trois AZS par défaut.
Nous allons seulement à la connaissance d'écriture lorsque deux de ces trois nœuds reviennent
et dire, oui, je l'ai eu.
Pourquoi donc?
Parce que sur le côté de lecture nous sommes seulement vais vous donner les données en arrière quand
nous l'obtenons à partir de deux nœuds.
>> Si je suis la réplication entre trois, et je lis de deux,
Je suis toujours garanti d'avoir au moins une
de ceux qui se lit comme le la plus exemplaire à jour des données.
Voilà ce qui rend DynamoDB cohérente.
Maintenant, vous pouvez choisir d'activer ceux qui sont compatibles indique OFF.
Dans ce cas, je vais dire, Je ne lis que d'un nœud.
Et je ne peux pas garantir que ça va être les données les plus actuelles.
>> Donc, si une écriture est à venir dans, il n'a pas encore répliqué,
vous allez obtenir cette copie.
Voilà une lecture finalement cohérente.
Et ce qui est est la moitié du coût.
Donc ceci est quelque chose à penser.
Lorsque vous lisez sur DynamoDB, et vous configurez votre capacité de lecture
unités, si vous choisissez éventuellement lectures cohérentes, il est beaucoup moins cher,
il est environ la moitié du coût.
>> Et si il vous fait gagner de l'argent.
Mais cela est votre choix.
Si vous voulez une lecture cohérente ou une lecture finalement cohérente.
Voilà quelque chose que vous pouvez choisir.
>> Parlons indices.
Donc, nous avons mentionné que agrégation de niveau supérieur.
Nous avons les clés de hachage, et nous avons les clés de gamme.
C'est bien.
Et qui est sur la table primaire, je obtenu une clé de hachage, je suis une clé de gamme.
>> Qu'est-ce que ça veut dire?
Je dois un attribut que je peut exécuter des requêtes riches contre.
Il est la clé de la gamme.
Les autres attributs de ce que item-- Je peux filtrer sur ces attributs.
Mais je ne peux pas faire des choses comme, il commence par, ou est supérieur.
>> Comment est-ce que je fais ça?
Je crée un index.
Il ya deux types de index dans DynamoDB.
Un index est vraiment une autre vue de la table.
Et l'index secondaire locale.
>> Le premier que nous allons parler.
Donc secondaires locales coexistaient sur la même partition en tant que données.
Et en tant que tels, ils sont sur le même nœud physique.
Ils sont ce que nous appelons cohérente.
Sens, ils reconnaîtront l'écriture avec la table.
Lorsque l'écriture arrive, nous écrirons par l'index.
Nous écrirons à la table, et puis nous allons reconnaître.
Voilà donc cohérente.
Une fois l'écriture a été reconnu de la table,
il est garanti que le index secondaire locale
auront la même vision de données.
Mais ce qu'ils permettent que vous faites est définir des clés de gamme suppléants.
>> Avoir à utiliser le même hachage touche que la table primaire,
parce qu'ils sont co-située sur la même partition, et ils sont compatibles.
Mais je peux créer un index avec des touches de portée différentes.
Ainsi, par exemple, si je devais un fabricant qui avait une table de pièces première venant en.
Et pièces brutes viennent dans et ils sont regroupés par assemblage.
Et peut-être il ya un rappel.
>> Toute partie qui a été faite par ce fabricant après cette date,
Je dois tirer de ma ligne.
Je peux tourner un indice qui serait à la recherche,
agrégation à la date de fabrication de cette partie.
Donc, si ma table de haut niveau était déjà haché par le fabricant,
Peut-être qu'il a été disposé sur une partie ID, je peut créer un index de cette table
comme haché par le fabricant et distance sur la date de fabrication.
Et de cette façon que je pourrais dire, tout ce qui a été fabriqué entre ces deux dates,
Je dois tirer de la ligne.
Voilà donc un index secondaire locale.
>> Ceux-ci ont pour effet de limiter votre espace de clé de hachage.
Parce qu'ils ont coexisté sur le même noeud de stockage,
ils limitent la touche dièse espace pour 10 gigaoctets.
DynamoDB, sous la tables, se répartiront
votre table tous les 10 gigaoctets.
Lorsque vous mettez 10 Go de données, nous go [PHH], et nous ajoutons un autre nœud.
>> Nous ne serons pas diviser la LSI sur plusieurs partitions.
Nous allons séparer la table.
Mais nous ne serons pas diviser la LSI.
Voilà donc quelque chose important de comprendre
est si vous faites très, très, très grands rassemblements,
alors vous allez être limité à 10 giga-octets sur votre LSI.
>> Si tel est le cas, nous pouvons utiliser secondaires mondiaux.
Secondaires mondiaux sont vraiment une autre table.
Ils existent complètement à le côté de votre table primaire.
Et ils me permettent de trouver un structure totalement différente.
Alors, pensez à ce que des données est inséré en deux tables différentes, structuré
de deux manières différentes.
>> Je peux définir un totalement différente clé de hachage.
Je peux définir un totalement clé différente de gamme.
Et je peux exécuter ce totalement indépendante.
En fait, je l'ai provisionné ma qualité de lecture
et écrire la capacité pour mon index secondaires mondiaux
totalement indépendante de ma table primaire.
Si je définis que l'indice, je dis combien il lire et écrire
la capacité que ça va être l'aide.
>> Et qui est séparé de ma table primaire.
Maintenant, les deux indices nous permettent de non seulement définir des clés de hachage et de portée,
mais ils nous permettent de projeter les valeurs supplémentaires.
Donc, si je veux lire sur l'indice, et je veux obtenir une série de données,
Je ne dois pas revenir à la principale table pour obtenir les attributs supplémentaires.
Je peux projeter ceux supplémentaires attributs dans la table
pour soutenir le modèle d'accès.
Je sais que nous allons probablement entrer dans une certaine vraiment, really-- entrer dans les mauvaises herbes
ici, sur certaines de ces choses.
Maintenant, je suis à la dérive de cette.
>> AUDIENCE: [inaudible] clé --table signifiait un hachage?
Le hachage originale?
Multi-lames?
>> RICK HOULIHAN: Oui.
Oui.
La clé de table essentiellement pointe vers l'article.
Ainsi, un indice est un pointeur sur les articles originaux sur la table.
Maintenant, vous pouvez choisir de construire un indice qui a seulement la clé de la table,
et pas d'autres propriétés.
Et pourquoi aurais-je faire cela?
Eh bien, peut-être ai-je très grandes pièces.
>> Je vraiment besoin de savoir qui-- mon modèle d'accès pourrait-on dire,
les éléments qui contiennent cette propriété?
Ne pas besoin de retourner l'article.
Je dois juste savoir les éléments qui en contiennent.
Ainsi, vous pouvez créer des index qui ont seulement la clé de table.
>> Mais cela est surtout ce que un index dans la base de données est pour.
Il est pour être en mesure de rapidement identifier qui enregistre,
les lignes qui éléments de la table ont
les propriétés que je cherche.
>> GSI, alors comment fonctionnent-ils?
GSI sont essentiellement asynchrone.
La mise à jour vient dans la table, tableau est ensuite mis à jour de manière asynchrone
tous vos GSI.
Voilà pourquoi GSI sont finalement cohérente.
>> Il est important de noter que quand vous construisez GSI,
et vous comprenez que vous créez une autre dimension de aggregation--
Maintenant, disons un bon exemple ici est un fabricant.
Je pense que je pourrais avoir parlé un fabricant de dispositif médical.
Fabricants de dispositifs médicaux ont souvent des pièces sérialisés.
Les pièces qui entrent dans la tout un remplacement de la hanche
avoir un petit numéro de série sur eux.
Et ils pourraient avoir des millions et des millions et des milliards de pièces
dans tous les dispositifs qu'ils expédient.
Eh bien, ils ont besoin d'agréger sous dimensions différentes, toutes les parties
dans un assemblage, d'autant pièces qui ont été faites
sur une certaine ligne, tous les les pièces qui sont venus
à partir d'un certain fabricant à une certaine date.
Et parfois ces agrégations monter dans les milliards.
>> Donc, je travaille avec quelques-uns des ces gars-là qui souffrent
parce qu'ils créent ces agrégations ginormous
dans leurs indices secondaires.
Ils pourraient avoir une pièces brutes table qui vient comme hachage seulement.
Chaque partie dispose d'un numéro de série unique.
Je l'utilise le numéro de série comme le hachage.
C'est beau.
Mon tableau de données brutes se propage tous à travers l'espace clé.
Ma [? écrit ?] [? l'ingestion?] est génial.
Je prends beaucoup de données.
Alors qu'est-ce qu'ils font est ils créent un GSI.
Et je dis, vous savez quoi, je dois voir toutes les parties pour ce fabricant.
Eh bien, tout d'un coup je suis prenant un milliard de lignes,
et les farcir sur un noeud, parce que quand
Je globale que la ID fabricant que le hachage,
et le numéro de la pièce que la gamme, puis tout d'un coup, je suis
mettre un milliard de pièces dans ce ce fabricant m'a délivré.
>> Cela peut causer beaucoup de pression sur l'ICF,
encore une fois, parce que je suis martelant un noeud.
Je mets tous ces insère dans un noeud.
Et qui est un véritable problème de cas d'utilisation.
Maintenant, je suis un bon design modèle pour la façon dont vous éviter cela.
Et qui est l'un des problèmes que je travaille toujours avec.
Mais ce qui se passe, est la GSI pourrait ne pas avoir la capacité d'écriture assez
pour être en mesure de pousser tous ceux rangées dans un seul nœud.
Et ce qui se passe ensuite est le primaire, la table du client,
la table primaire sera étranglé parce que le GSI ne peut pas suivre.
Donc, mon taux d'insert tomber sur la table primaire
comme mon GSI essaie de garder le rythme.
>> Très bien, alors de GSI, LSI, qui dois-je utiliser?
LSI sont compatibles.
De GSI sont finalement cohérente.
Si cela est OK, je recommande d'utiliser un GSI, ils sont beaucoup plus souple.
LSI peut être modélisée comme un GSI.
Et si la taille des données par clés de hachage en votre collection dépasse 10 gigaoctets,
alors vous allez vouloir l'utiliser GSI parce qu'elle est juste une limite dure.
>> Très bien, alors mise à l'échelle.
Débit en Dynamo DB, vous Can disposition [inaudible]
débit pour une table.
Nous avons des clients qui ont provisionné 60 billion--
font 60 milliards de requêtes, régulièrement courir à plus d'un million de demandes
par seconde sur nos tables.
Il n'y a vraiment pas limite théorique à la quantité
et à quelle vitesse la table peut fonctionner dans Dynamo DB.
Il ya quelques doux limites sur votre compte
que nous mettons en at-il tant que vous ne vous affolez pas.
Si vous voulez plus de que, pas un problème.
Vous venez de nous dire.
Nous allons tourner le cadran.
>> Chaque compte est limitée à un certain niveau dans chaque service, juste à côté de la chauve-souris
de sorte que les gens ne vont pas fou eux-mêmes avoir des ennuis.
Pas de limite de taille.
Vous pouvez mettre un nombre quelconque des articles sur une table.
La taille d'un objet est limité à 400 kilo-octets chacune,
ce serait un objet pas les attributs.
Ainsi, la somme de tous les attributs est limitée à 400 kilo-octets.
Et puis, nous avons ce petit problème LSI
avec la limite de 10 gigaoctet par hachage.
AUDIENCE: Petit nombre, il me manque ce que vous me dites, que est--
AUDIENCE: Oh, 400 kilo-octet est la taille maximale par article.
Donc, un article a tous les attributs.
Donc 400 k est la taille totale de cet article, 400 kilo-octets.
Donc, de tous les attributs combinés, toutes les données
qui est dans tous ces attributs, enroulé dans une taille totale,
actuellement aujourd'hui la limite d'article est de 400 k.
Donc, à nouveau mise à l'échelle, obtenu via le partitionnement.
Le débit est provisionné au niveau de la table.
Et il n'y a vraiment deux boutons.
Nous avons lu la capacité et écrire la capacité.
>> Donc, ce sont ajustés indépendamment l'un de l'autre.
La mesure de l'UCR strictement lectures cohérentes.
OK, si vous dites que je veux de 1000 RCU de ceux qui sont strictement conformes,
ceux qui sont lectures cohérentes.
Si vous dites que je veux éventuelle lectures cohérentes,
vous pouvez disposition 1000 RCU de, vous allez
pour obtenir finalement 2000 lectures cohérentes.
Et la moitié du prix pour ceux éventuellement consister en lit.
>> Encore une fois, ajusté indépendamment l'un de l'autre.
Et ils ont le throughput-- Si vous consommez 100% de votre télécommande,
tu ne vas pas à l'impact de la la disponibilité de vos droits.
Donc, ils sont complètement indépendamment les uns des autres.
Très bien, alors l'une des choses qui Je l'ai mentionné brièvement été étrangle.
Étranglement est mauvais.
Étranglement indique mauvais pas SQL.
Il ya des choses que nous pouvons faire pour aider à soulager l'étranglement que vous
connaissent.
Mais la meilleure solution à ceci est Prenons
Un regard sur ce que vous faites, parce il ya un anti-modèle en jeu ici.
>> Ces choses, des choses comme non uniforme les charges de travail, les touches de raccourci, partitions chaudes.
Je suis frappé un espace clé particulière très difficile pour une raison particulière.
Pourquoi je fais cela?
Essayons d'imaginer cela.
Je mélange mes données chaudes avec des données froides.
Je laisse mes tableaux se énorme, mais il n'y a vraiment
seulement un sous-ensemble des données qui est vraiment intéressant pour moi.
Donc, pour les données du journal, par exemple, beaucoup de clients, ils obtiennent les données du journal tous les jours.
Ils ont eu une énorme quantité de données du journal.
>> Si vous êtes juste le dumping tout ce journal données en une seule grande table, au fil du temps
cette table va devenir massif.
Mais je suis vraiment seulement intéressé par dernières 24 heures, les sept derniers jours,
les 30 derniers jours.
Quelle que soit la fenêtre de temps que je suis intéressé par la recherche
pour l'événement qui me dérange, ou l'événement qui est intéressant pour moi,
qui est la seule fenêtre de temps que je dois.
Alors pourquoi je mets 10 ans la valeur de données des journaux dans le tableau?
Qu'est-ce qui provoque est la table le fragment.
>> Il devient énorme.
Il commence à étaler à travers des milliers de nœuds.
Et puisque votre capacité est si faible, vous êtes
effectivement la limitation de débit sur chaque l'un de ces noeuds individuels.
Donc, nous allons commencer à regarder comment faisons nous roulons sur cette table.
Comment gérons-nous que les données un peu mieux pour éviter ces problèmes.
Et ce que cela ressemble?
Ceci est ce que cela ressemble.
Ceci est ce mauvais NoSQL ressemble.
>> Je suis une touche de raccourci ici.
Si vous regardez sur le côté ici, ce sont tous mes partitions.
Je me suis 16 partitions ici sur cette base de données particulière.
Nous le faisons tout le temps.
Je lance ce pour les clients de tous les temps.
Il a appelé la carte de chaleur.
Carte de chaleur me dit comment vous êtes accès à votre espace de clé.
Et ce que cela me dit est qu'il ya un hachage particulier
que ce gars aime une énormément, parce qu'il est
frapper vraiment, vraiment dur.
>> Donc, le bleu est agréable.
Nous aimons bleu.
Nous ne voulons pas rouge.
Où la pression de Red reçoit jusqu'à 100%.
100%, maintenant vous allez être étranglé.
Donc, chaque fois que vous voyez des lignes rouges comme this-- et il n'y a pas que le Dynamo DB--
base de données NoSQL a tous ce problème.
Il sont anti-modèles qui peuvent conduire ces types de conditions.
Ce que je fais est que je travaille avec les clients de pallier ces conditions.
>> Et ce que cela ressemble?
Et cela devient le plus sur Dynamo DB débit,
mais il devient vraiment le maximum de NoSQL.
Cela ne se limite pas à Dynamo.
Ceci est definitely-- I utilisé pour travailler à Mongo.
Je suis familier avec de nombreuses plateformes NoSQL.
Chacun a ces types des problèmes clés chauds.
Pour tirer le meilleur parti de toute NoSQL base de données, spécifiquement Dynamo DB,
vous voulez créer les tables où l'élément clé de hachage a
un grand nombre de valeurs distinctes, un haut degré de cardinal.
Parce que cela signifie que je vais écrire à beaucoup de différentes tranches.
>> Les plus de seaux je suis écrit, plus il est probable
Je suis à se répandre que la charge d'écriture ou lire charger à travers plusieurs nœuds,
plus il est probable que je suis d'avoir un haut débit sur la table.
Et puis je veux que les valeurs à demandé assez uniformément dans le temps
et uniformément de façon aussi aléatoire que possible.
Eh bien, que ce genre d'intéressant, parce que je ne peux vraiment pas
contrôle lorsque les utilisateurs viennent.
Donc, il suffit de dire, si nous répandons les choses à travers l'espace des clés,
nous allons probablement être en meilleure forme.
>> Il ya une certaine montant de la livraison de temps
que tu ne vas pas pour être en mesure de contrôle.
Mais ceux qui sont vraiment les deux dimensions que nous avons,
l'espace, l'accès uniformément propagation, le temps, les demandes
arrivant régulièrement espacées dans le temps.
Et si ces deux conditions sont remplies,
alors ce est ce qu'il est va ressembler.
Cela est beaucoup plus agréable.
Nous sommes vraiment heureux ici.
Nous avons un modèle d'accès très homogène.
Ouais, peut-être vous obtenez un peu de pression chaque maintenant et puis,
mais rien de vraiment trop étendue.
Donc, il est étonnant de voir combien de fois, quand je travaille avec des clients,
ce premier graphique avec le Big Red bar et tout ce qui est laid jaune, il
partout, nous se fait avec l'exercice
après une couple de mois de ré-architecture,
ils courent exactement la même la charge de travail à la même charge exacte.
Et ceci est ce qu'il cherche comme maintenant.
Donc ce que vous obtenez avec NoSQL est un schéma de données qui est absolument
lié à la structure d'accès.
>> Et vous pouvez optimiser ce schéma de données pour soutenir ce modèle d'accès.
Si vous ne le faites pas, alors vous allez de voir ces types de problèmes
avec ces touches de raccourci.
>> AUDIENCE: Eh bien, inévitablement certains endroits vont être plus chaud que d'autres.
>> RICK HOULIHAN: Toujours.
Toujours.
Ouais, je veux dire il ya toujours a-- et encore, il ya
certains modèles de conception, nous allons passer à travers qui va parler de la façon dont vous traitez
avec ces super-grands rassemblements.
Je veux dire, je suis arrivé à les avoir, comment pouvons-nous y faire face?
Je suis un très bon cas d'utilisation que nous allons parler de cela.
>> Le discours de tous les droits, alors laissez- au sujet de certains clients maintenant.
Ces gars-là sont AdRoll.
Je ne sais pas si vous êtes familier avec AdRoll.
Vous les voyez probablement beaucoup sur le navigateur.
Ils sont ad re-ciblage, ils sont la plus grande entreprise annonce reciblage
là-bas.
Ils fonctionnent normalement régulièrement sur 60 milliards de transactions par jour.
Ils font plus d'un million transactions par seconde.
Ils ont un tableau assez simple la structure, le tableau le plus achalandé.
Il est fondamentalement juste un clé de hachage est le cookie,
la gamme est la situation démographique catégorie, puis
le troisième attribut est le score.
>> Donc, nous avons tous les cookies dans notre navigateur à partir de ces gars-là.
Et quand vous allez à un marchand participant,
ils vous marquez essentiellement à travers diverses catégories démographiques.
Quand vous allez à un site Web et vous dites que je veux voir ce ad--
ou, fondamentalement, vous ne dites pas that-- mais quand vous allez sur le site
ils disent que vous voulez voir cette annonce.
Et ils vont obtenir cette annonce de AdRoll.
AdRoll vous regarde sur leur table.
Ils trouvent votre cookie.
Les annonceurs disent eux, je veux quelqu'un
qui est d'âge moyen, 40-year-old man, dans le sport.
Et ils vous marquez dans les données démographiques et ils décident si oui ou non
qui est une bonne annonce pour vous.
>> Maintenant, ils ont un SLA avec leurs fournisseurs de publicité
pour fournir 10 sous-milliseconde réponse à chaque demande unique.
Donc ils utilisent Dynamo DB pour cela.
Ils nous a frapper millions de requêtes par seconde.
Ils sont capables de faire tout leur les recherches, le triage de toutes ces données,
et obtenir ce lien de rajouter à cette annonceur en moins de 10 millisecondes.
Il est vraiment assez phénoménale la mise en œuvre qu'ils ont.
>> Ces gars-là actually-- ce sont là les gars.
Je ne suis pas sûr que ce soit ces gars-là.
Peut-être ces gars-là.
Fondamentalement us-- dit non, je ne pense pas que ce sont eux.
Je pense qu'il était quelqu'un d'autre.
Je travaillais avec un client qui m'a dit
que maintenant qu'ils ont allé à Dynamo DB, ils sont
dépenser plus d'argent sur les collations pour leur équipe de développement de chaque mois
que ce qu'ils consacrent à leur base de données.
Donc, il va vous donner une idée des économies de coûts
que vous pouvez obtenir en Dynamo DB est énorme.
Tout droit, Dropcam est une autre société.
Ce mec est un peu de-- si vous pensez de l'internet des objets, Dropcam
est fondamentalement Internet Security vidéo.
Vous mettez votre appareil photo là-bas.
Appareil dispose d'un détecteur de mouvement.
Quelqu'un vient le long, déclenche un point de repère.
L'appareil photo commence l'enregistrement pendant un certain temps jusqu'à ce il ne détecte plus aucun mouvement.
Met cette vidéo sur Internet.
>> Dropcam était une entreprise qui est essentiellement tournés vers Dynamo DB
parce qu'ils éprouvaient d'énormes douleurs de croissance.
Et ce qu'ils nous ont dit, pétaoctets soudain des données.
Ils avaient aucune idée de leur service serait un tel succès.
Plus vidéo entrant de YouTube est ce que ces gars-là obtiennent.
Ils utilisent DynamoDB pour suivre tous les métadonnées sur tous les points clés vidéo.
>> Donc, ils ont seaux S3 qu'ils poussent tous les objets binaires en.
Et puis ils ont Dossiers Dynamo DB qui
pointer les gens à ces trois objets S3.
Quand ils ont besoin pour regarder une vidéo, ils regardent l'enregistrement dans Dynamo DB.
Ils cliquent sur le lien.
Ils tirent en bas de la vidéo à partir de S3.
Voilà donc le genre de ce que cela ressemble.
Et cela est directement à partir de leur équipe.
>> Dynamo DB réduit leur délai de livraison pour les événements vidéo
de cinq à dix secondes.
Dans leur magasin relationnelle vieux, ils l'habitude d'avoir à aller exécuter
plusieurs requêtes complexes à la figure quels vidéos à tirer vers le bas,
à moins de 50 millisecondes.
Donc, il est incroyable, incroyable quel niveau de performance
vous pouvez obtenir lorsque vous optimisez et de peaufiner la base de données sous-jacente
pour soutenir le modèle d'accès.
Halfbrick, ces gars-là, quel est-il, Fruit Ninja je pense est leur chose.
Toutes les courses sur Dynamo DB.
Et ces gars-là, ils sont une grande équipe de développement, un grand développement
boutique.
>> Pas une bonne équipe de l'OPS.
Ils ne disposent pas d'un lot des ressources de fonctionnement.
Ils ont du mal en essayant de garder leur infrastructure d'application jusqu'à
et en cours d'exécution.
Ils sont venus nous.
Ils se regardèrent que Dynamo DB.
Ils ont dit, voilà pour nous.
Ils ont construit leur ensemble cadre d'application sur elle.
Quelques très bons commentaires ici de l'équipe de leur capacité
de se concentrer désormais sur le renforcement le jeu et non
ayant pour maintenir la infrastructures, qui
devenait une énorme quantité des frais généraux pour leur équipe.
Donc ceci est quelque chose that-- la avantage que vous obtenez de Dynamo DB.
>> Tout droit, entrer dans la modélisation de données ici.
Et nous avons parlé un peu de celui-ci à un, un à plusieurs,
et beaucoup à de nombreuses relations de type.
Et comment voulez-vous maintenir ceux de Dynamo.
En Dynamo DB nous utilisons index, de façon générale,
faire tourner les données de une saveur à l'autre.
Hash touches, des touches de gamme, et les index.
>> Dans ce cas particulier par exemple, que la plupart des Etats
avoir une exigence de licence qui qu'une licence d'pilote par personne.
Vous ne pouvez pas aller à obtenir deux conducteur licences dans l'État de Boston.
Je ne peux pas le faire dans le Texas.
Cela est le genre de la façon dont elle est.
Et donc à la DMV, nous avons recherches, nous vouloir rechercher le permis de conduire
par le numéro de sécurité sociale.
Je veux regarder les détails de l'utilisateur par le numéro de permis de conduire.
>> Donc, nous pourrions avoir la table d'un utilisateur a une clé de hachage sur le numéro de série,
ou le numéro de sécurité sociale, et divers attributs définis sur la question.
Maintenant, sur cette table, je pourrait définir un GSI que
flips qu'environ dit que je veux une clé de hachage sur la licence et ensuite
tous les autres éléments.
Maintenant, si je veux interroger et trouver le numéro de licence pour toute donnée sociale
Numéro de sécurité, je ne peux interroger la table principale.
>> Si je veux interroger et je veux pour obtenir la sécurité sociale
Numéro ou d'autres attributs par une numéro de licence, je peux interroger le GSI.
Ce modèle est que l'on une relation.
Juste un très simple GSI, retourner ces choses autour.
Maintenant, parler de un à plusieurs.
Un à plusieurs est essentiellement la clé de votre gamme de hachage.
Où nous recevons beaucoup avec ce cas d'utilisation est données de surveillance.
Les données du moniteur est livré dans régulière intervalle, comme l'Internet des objets.
Nous avons toujours tous ces dossiers à venir dans tout le temps.
>> Et je veux trouver toutes les lectures entre une période de temps particulière.
Il est une requête très commun dans infrastructure de surveillance.
La façon aller à ce sujet est de trouver un structure de table simple, une table.
Je ai un tableau des mesures du dispositif avec une clé de hachage sur l'ID du périphérique.
Et je dois une clé de gamme sur le timestamp, ou dans ce cas, l'épopée.
Et cela me permet exécuter complexe des requêtes sur cette touche de gamme
et retourner les enregistrements sont liés à la suite
mis que je suis à la recherche.
Et ce que l'on construit pour beaucoup relation
dans la table primaire en utilisant la clé de hachage, structure clé de gamme.
>> Voilà donc sorte de construit dans le tableau de la Dynamo DB.
Quand je définis un hachage et la table gamme de t, je suis
la définition d'une relation un à plusieurs.
Il est une relation parent-enfant.
>> Parlons de nombreux de nombreuses relations.
Et pour cet exemple particulier, encore une fois, nous allons utiliser de GSI.
Et parlons de jeux scénario où je dois un utilisateur donné.
Je veux trouver tous les jeux que il a enregistré pour ou en jouant dans.
Et pour un jeu donné, je voulez trouver tous les utilisateurs.
Alors, comment puis-je faire?
Ma table de jeux de l'utilisateur, je vais d'avoir une clé de hachage de l'ID utilisateur
et une clé de gamme de la partie.
>> Ainsi, un utilisateur peut avoir plusieurs jeux.
Il est une relation un à plusieurs entre l'utilisateur et les jeux qu'il joue.
Et puis sur le GSI, Je vais flip autour.
Je vais hachage sur le jeu et Je range sur l'utilisateur.
Donc, si je veux obtenir toutes les jeu à l'utilisateur de jouer dans,
Je vais interroger la table principale.
Si je veux obtenir tous les utilisateurs qui jouent un jeu particulier,
Je questionne le GSI.
Donc, vous voyez la façon dont nous le faisons?
Vous construisez de ces GSI pour soutenir le cas d'utilisation, l'application, l'accès
motif, l'application.
>> Si je dois interroger sur cette dimension, laissez-
moi créer un index sur cette dimension.
Si je ne le fais pas, je ne me soucie pas.
Et selon le cas d'utilisation, je peuvent avoir besoin de l'index ou je ne pourrais pas.
Si elle est un simple pour beaucoup, la table primaire est très bien.
Si je dois faire ces nombreux à beaucoup de, ou je dois faire un à ceux,
alors peut-être je ne dois à la seconde l'indice.
Donc tout dépend de ce que je suis en train de le faire
et ce que je vais essayer d'obtenir accompli.
>> Probablement, je ne vais pas passer trop beaucoup de temps à parler de documents.
Cela devient un peu, sans doute, plus profond que nous devons aller dans.
Parlons un peu sur la riche expression de la requête.
Donc, en Dynamo DB nous avons la possibilité de créer
ce que nous appelons expressions de projection.
Expressions de projection sont tout simplement ramasser les champs ou les valeurs
que vous souhaitez afficher.
OK, donc je fais une sélection.
Je fais une requête contre le Dynamo DB.
Et je dis, vous savez quoi, spectacle moi seulement cinq étoiles critiques
pour ce produit particulier.
Voilà donc tout ce que je veux voir.
Je ne veux pas voir tous les d'autres attributs de la rangée,
Je veux juste voir cela.
Il est juste comme dans SQL lorsque vous dire sélectionnez étoile ou de la table,
vous obtenez tout.
Quand je dis sélectionnez le nom de table, je ne reçois un attribut.
Il est le même genre de chose dans Dynamo DB ou encore des bases de données NoSQL.
Les expressions de filtre me permettent de essentiellement couper le jeu de résultats vers le bas.
Donc je fais une requête.
Requête peut revenir avec 500 articles.
Mais je veux seulement les éléments qui avoir un attribut qui dit cela.
OK, nous allons donc filtrer les articles qui ne correspondent pas à cette requête particulière.
Donc, nous avons des expressions de filtre.
>> Les expressions de filtre peut être exécuté sur n'importe quel attribut.
Ils ne sont pas comme les requêtes de plages.
Soulever des questions sont plus sélectifs.
Requêtes de filtrage me demandent d'aller Obtenez les résultats ensemble complet et ensuite
tailler les données que je ne veux pas.
Pourquoi est-ce important?
Parce que je l'ai lu tout.
Dans une requête, je vais lire et ça va être un géant sur les données.
Et puis je vais tailler ce que je dois.
Et si je ne fais que tailler une quelques lignes, puis qui est OK.
Il est pas si inefficace.
>> Mais si je lis tout un tas de les données, juste pour se tailler un poste,
alors je vais être mieux hors aide d'une requête de gamme,
parce qu'il est beaucoup plus sélective.
Il va me sauver beaucoup de l'argent, parce que je paie pour cette lecture.
Lorsque les résultats qui revient traverser ce fil pourrait être plus petit,
mais je dois payer pour la lecture.
Donc, comprendre comment vous obtenez les données.
Cela est très important dans le Dynamo DB.
>> Les expressions conditionnelles, voici ce que vous pourriez appeler le verrouillage optimiste.
Mise à jour si existe, ou si cette valeur est équivalent à ce que je spécifie.
Et si je dois un horodatage sur un dossier, je pourrais lire les données.
Je pourrais changer ces données.
Je pourrais aller écriture qui Retour de données à la base de données.
Si quelqu'un a changé le dossier, l'horodatage pourrait avoir changé.
Et de cette façon mon conditionnelle mise à jour pourrait dire la mise à jour
si l'horodatage est égal à cela.
Ou la mise à jour va échouer parce que quelqu'un mis à jour le dossier dans l'intervalle.
>> Voilà ce que nous appelons le verrouillage optimiste.
Cela signifie que quelqu'un peut entrer et changer,
et je vais le détecter quand je reviens à écrire.
Et puis je peux effectivement lu que données et dire, oh, il a changé cela.
Je dois tenir compte de cela.
Et je peux changer les données dans mon enregistrer et appliquer une autre mise à jour.
Ainsi, vous pouvez attraper ceux incrémentale mises à jour qui surviennent entre le moment
que vous lisiez les données et la fois que vous pourriez écrire les données.
>> Public: Et le filtre expression signifie en fait pas
dans le nombre ou pas--
>> [Interposition VOIX]
RICK HOULIHAN: je ne veux pas trop entrer dans cette.
Ceci est un mot clé réservé.
La vue de la livre est une réservés mot-clé dans Dynamo DB.
Chaque base de données dispose de sa propre réserve noms pour les collections que vous ne pouvez pas utiliser.
Dynamo DB, si vous spécifiez une livre en face de cela,
vous pouvez définir ces noms au-dessus.
Ceci est une valeur de référence.
Il est probablement pas la meilleure syntaxe pour avoir là-haut pour cette discussion,
parce qu'il obtient dans certains bien-- Je vous ai parlé plus
à ce sujet à un niveau plus profond.
>> Mais il suffit de dire, cela pourrait soient requête de scan où ils views--
ni livres vues est supérieur à 10.
Il est une valeur numérique, oui.
Si vous voulez, nous pouvons parler de que, après la discussion.
Très bien, alors que nous entrons dans certains scénarios dans les meilleures pratiques
où nous allons parler à propos de certaines applications ici.
Quels sont les cas d'utilisation pour Dynamo DB.
Quels sont la conception modèles dans Dynamo DB.
>> Et le premier nous allons parler est l'internet des objets.
Donc, nous recevons beaucoup de-- je suppose, ce qui est it-- plus de 50%
du trafic sur l'Internet ces jours- est générée par les machines,
des processus automatisés, pas par les humains.
Je veux dire cette chose que cette chose vous portez dans votre poche,
la quantité de données que cette chose est envoyer réellement autour sans vous
sachant qu'il est absolument incroyable.
Votre localité, informations à quelle vitesse vous allez.
Comment pensez-vous que Google Maps œuvres quand ils vous disent ce que le trafic est.
Il est parce que il ya des millions et des millions de personnes autour de la conduite
avec les téléphones qui envoient toutes les données de plus de endroit tout le temps.
Donc, l'une des choses sur ce type de données
qui vient dans, données de surveillance, connectez-vous les données, les données de séries chronologiques, est qu'il est
habituellement seulement intéressante pour un peu de temps.
Après ce temps, il est pas si intéressant.
Donc, nous avons parlé, ne laissez pas ces tables se développer sans limites.
L'idée ici est que peut-être je dois 24 heures de dollars de événements dans ma table chaude.
Et cette table chaude va être provisionnées à un taux très élevé,
parce que cela prend beaucoup de données.
Ça prend beaucoup de données et je lis beaucoup.
Je dois beaucoup de fonctionnement l'exécution de requêtes contre ces données.
>> Après 24 heures, hey, vous sais quoi, je ne me soucie pas.
Alors peut-être que je chaque rouleau de minuit ma table sur une nouvelle table
et je déprovisionner ce tableau.
Et je vais prendre de l'URC et Le bas de WCU parce 24 heures plus tard
Je ne vais pas courir autant des requêtes sur ces données.
Donc, je vais économiser de l'argent.
Et peut-être 30 jours plus tard, je ne sais pas même pas besoin de se soucier de tout cela.
Je pourrais prendre le WCU de tout le chemin vers le bas à une,
parce que vous savez quoi, il est ne va jamais se écrite.
Les données est de 30 jours.
Il ne change jamais.
>> Et il est presque jamais va se lire, donc nous allons simplement prendre ce RCU vers le bas à 10.
Et je suis économiser une tonne d'argent sur ce données, et ne payant que pour mes données chaudes.
Voilà la chose importante à regarder à quand vous regardez une série de temps
les données venant en volume.
Ce sont des stratégies.
Maintenant, je ne pouvais le laisser vont tous à la même table
et juste laisser cette table grandir.
Finalement, je vais des problèmes de performances.
Je vais devoir commencer à archiver certaines de ces données de la table,
étagère.
>> Voyons beaucoup mieux concevoir votre application
de sorte que vous pouvez fonctionner de cette façon droite.
Donc, il est juste automatique dans le code d'application.
A minuit tous les soirs il roule la table.
Peut-être que ce que je besoin est un coulissant fenêtre de 24 heures de données.
Ensuite, sur une base régulière, je suis appelant les données de la table.
Je coupe avec un Cron et je suis le mettre
sur ces autres tables, tout ce que tu veux.
Donc, si un retournement fonctionne, qui est très bien.
Si non, la tailler.
Mais gardons que les données à chaud loin de vos données froides.
Il va vous faire économiser beaucoup d'argent et faire vos tables plus performants.
Donc, la prochaine chose que nous allons parler est sur le catalogue de produits.
Le catalogue des marchandises est cas d'utilisation assez commun.
Ceci est en fait un motif très fréquent que nous verrons dans une variété de choses.
Vous savez, pour Twitter par exemple, un tweet chaud.
Tout le monde est à venir et saisissant ce tweet.
Le catalogue des marchandises, je me suis une vente.
Je suis une vente chaude.
Je me suis 70.000 demandes par seconde venue pour un produit
Description de mon catalogue de produits.
Nous le voyons sur le commerce de détail opération un peu.
Alors, comment pouvons-nous régler ce problème?
Il n'y a pas moyen de faire face à cela.
Tous mes utilisateurs veulent voir le même élément de données.
Ils arrivent, en même temps.
Et ils sont tous faire des demandes pour le même élément de données.
Cela me donne cette touche de raccourci, ce gros rouge rayure sur mon tableau qui ne nous plaît pas.
Et voilà à quoi ça ressemble.
Donc, dans mon espace clé Je suis en train martelé dans les articles en vente.
Je ne suis rien obtenir nulle part ailleurs.
>> Comment puis-je résoudre ce problème?
Eh bien, nous soulageons avec ce cache.
Cache, vous mettez essentiellement un en mémoire Cloison en face de la base de données.
Nous avons réussi [Inaudible] cache, comment vous
peut mettre en place votre propre cache, [inaudible] cache [? d,?] ce que vous voulez.
Mettez cela en face de la base de données.
Et de cette façon vous pouvez stocker ces données de ces touches de raccourci vers le haut dans ce cache
l'espace et le lire à travers le cache.
>> Et puis la plupart de votre lit commencer à regarder comme ça.
Je me suis tout cela cache HITS ici et je me suis rien qui se passe ici-bas
parce que la base de données est assis derrière le cache et les lectures ne viennent jamais à travers.
Si je change les données dans le base de données, je dois mettre à jour le cache.
Nous pouvons utiliser quelque chose comme les vapeurs de le faire.
Et je vais vous expliquer comment cela fonctionne.
Tout droit, messagerie.
E-mail, nous utilisons tous courriel.
>> Ceci est un très bon exemple.
Nous avons une sorte de table des messages.
Et nous avons courrier entrant et sortant.
Ceci est ce que le SQL serait ressemblent à construire cette boîte de réception.
Nous type d'utilisation le même genre de la stratégie à utiliser de GSI, GSI de
pour ma boîte de réception et ma boîte d'envoi.
Alors je me suis messages premières à venir dans mon tableau des messages.
Et la première approche de cette pourrait être, dire, OK, pas de problème.
Je dois messages premières.
Messages à venir [inaudible], ID de message, qui est grand.
Voilà mon hash unique.
Je vais créer deux de GSI, un pour ma boîte de réception, un pour ma boîte d'envoi.
Et la première chose que je vais faire est que je vais dire ma clé de hachage est
va être le bénéficiaire et Je vais organiser à la date.
C'est fantastique.
Je suis ma belle vue ici.
Mais il ya un petit problème ici.
Et vous rencontrez ce dans bases de données relationnelles ainsi.
Ils ont appelé partitionnement verticalement.
Vous voulez garder votre Big Data loin de vos peu de données.
>> Et la raison en est parce que je dois allez lire les articles pour avoir les attributs.
Et si mes organes sont tous ici, puis en lisant quelques articles
si ma longueur du corps est en moyenne 256 kilo-octets chacun,
le calcul devient assez laid.
Donc, dire que je veux lire la boîte de réception de David.
La boîte de réception de David a 50 articles.
La moyenne et la taille est de 256 kilo-octets.
Voici mon ratio de conversion pour RCU est de quatre kilo-octets.
>> OK, allons-y éventuellement lectures cohérentes.
Je suis toujours manger de 1,600 RCU suffit de lire la boîte de réception de David.
Aie.
OK, maintenant nous allons réfléchir sur la façon dont l'application fonctionne.
Si je suis dans une application de courrier électronique et Je regarde ma boîte de réception,
et je regarde le corps de chaque message, Non, je regarde les résumés.
Je regarde seulement les en-têtes.
Donc, nous allons construire une structure de table qui ressemble plus que.
>> Alors, voici l'information que mon flux de travail a besoin.
Il est dans ma boîte de réception GSI.
Il est de la date, l'expéditeur, le sujet, puis
l'ID de message, qui indique Retour à la table des messages
où je peux obtenir le corps.
Eh bien, ceux-ci seraient ID d'enregistrement.
Ils pointent vers le ID objet sur la table Dynamo DB.
Chaque indice creates-- toujours a toujours l'élément
ID dans le cadre de-- que est livré avec l'indice.
>> D'accord.
PUBLIC: Il raconte là où il est stocké?
RICK HOULIHAN: Oui, il raconte exactly-- qui est exactement ce qu'il fait.
Il est dit ici est mon record de re.
Et il va pointer de nouveau à mon dossier de re.
Exactement.
OK, maintenant ma boîte de réception est en réalité beaucoup plus petit.
Et cela prend effectivement le flux de travail d'une application e-mail.
Donc, ma boîte de réception, je clique.
Je vais le long et je clique sur le message, qui est quand je dois aller chercher le corps,
parce que je vais aller à un point de vue différent.
Donc, si vous pensez que sur le type de MVC cadre, la vue du modèle contrôleur.
>> Le modèle contient la des données que les besoins en vue
et le dispositif de commande coopère avec.
Quand je change le cadre, lorsque Je change la perspective,
il est OK pour revenir à la serveur et repeupler le modèle,
parce que ce que l'utilisateur attend.
Quand ils changent vues, qui est à ce moment nous pouvons revenir à la base de données.
Donc, e-mail, cliquez sur.
Je suis à la recherche pour le corps.
Aller-retour.
Allez chercher le corps.
>> Je lis beaucoup moins de données.
Je ne fais que lire les organismes qui David a besoin quand il a besoin d'eux.
Et je ne brûle en 1600 RCU est juste pour montrer sa boîte de réception.
Alors maintenant that-- cela est la manière LSI ou GSI-- je suis désolé,
GSI, cela fonctionnerait.
Nous avons notre hachage sur le destinataire.
Nous avons eu la clé de la plage sur la date.
Et nous avons les attributs projetés que nous devons seulement pour soutenir la vue.
>> Nous faisons une rotation pour que la boîte d'envoi.
Hachage sur l'expéditeur.
Et en substance, nous avons la très belle, vue propre.
Et il est que nous basically-- avoir cette gentils messages
tableau qui est propagée bien parce il est hachage seulement, haché ID de message.
Et nous avons deux index sont en rotation hors de ce tableau.
Très bien, alors idée ici est ne pas garder les grandes données et cette petite données
ensemble.
Partition verticalement, partitionner les tables.
Ne pas lire les données que vous ne devez pas.
Tout droit, jeux.
Nous aimons tous les jeux.
Au moins, je aime les jeux alors.
Donc, certaines des choses que nous traitons lorsque
nous pensons au sujet du jeu, non?
Gaming ces jours, en particulier mobiles jeu, est tout au sujet de la pensée.
Et je vais tourner ici peu loin de DynamoDB.
Je vais apporter partie de la discussion
dans une partie de la d'autres technologies d'AWS.
>> Mais l'idée de jeu est de penser environ en termes d'API, les API qui sont,
de manière générale, HTTP et JSON.
Il est comment les jeux mobiles type de interagir avec leurs extrémités arrière.
Ils font affichage JSON.
Ils obtiennent des données, et il est tout, de manière générale, dans de beaux API JSON.
>> Des choses comme faire des amis, se les données leaderboard, change,
contenu généré par l'utilisateur, repousser jusqu'à le système,
ce sont les types de choses que nous allons faire.
Les données d'actifs binaire, ces données pourrait ne pas siéger dans la base de données.
Cela pourrait s'asseoir dans un magasin d'objets, non?
Mais la base de données va finir par dire le système,
dire l'application où aller le chercher.
Et forcément, multijoueur serveurs, de retour infrastructure de fin,
et conçu pour une grande la disponibilité et l'évolutivité.
Donc, ce sont des choses que nous voulons tous dans l'infrastructure de jeu aujourd'hui.
>> Donc, nous allons jeter un oeil à à quoi ça ressemble.
Vous avez une extrémité arrière central, très simple.
Nous avons un système ici avec multiples zones de disponibilité.
Nous avons parlé de AZS que being-- penser d'entre eux en tant que centres de données distincts.
Plus d'un centre de données par AZ, mais ce est OK,
il suffit de penser à eux comme données séparé des centres qui sont géographiquement
et faute isolé.
>> Nous allons avoir un deux instances EC2.
Nous allons avoir un serveur de back-end.
Peut-être que si vous êtes un héritage architecture, nous sommes
en utilisant ce que nous appelons RDS, services de bases de données relationnelles.
Pourrait être MSSQL, MySQL, ou quelque chose comme ça.
Ceci est ainsi une des applications de lot sont conçus aujourd'hui.
>> Eh bien, nous pourrions aller avec cela est quand nous scale-out.
Nous irons de l'avant et mettre le seau S3 là-haut.
Et que S3 seau, au lieu de servir jusqu'à ces objets de notre servers--
nous pourrions le faire.
Vous mettez tout votre binaire objets sur vos serveurs
et vous pouvez les utiliser serveur instances de données qui servent vers le haut.
Mais cela est assez cher.
>> Meilleure façon de faire est d'aller de l'avant et mettre ces objets dans un seau à S3.
S3 est un dépôts d'objets.
Il est construit spécifiquement pour servir jusqu'à ces types de choses.
Et que ces clients demandent directement à partir de ces seaux d'objets,
décharger les serveurs.
Donc, nous commençons à l'échelle ici.
>> Maintenant, nous avons des utilisateurs partout dans le monde.
Je suis arrivé utilisateurs.
Je dois avoir un contenu local situé à proximité de ces utilisateurs, non?
Je ai créé un seau S3 comme mon référentiel source.
Et je vais avant que, avec la distribution CloudFront.
>> CloudFront est un CD et un Content Delivery Network.
Fondamentalement, il prend les données que vous spécifiez et met en cache partout sur l'internet
afin que les utilisateurs peuvent avoir partout une réponse très rapide quand
ils demandent ces objets.
>> Ainsi, vous obtenez une idée.
Vous genre de tirer parti de toutes les aspects de AWS ici pour obtenir ce fait.
Et finalement, nous jetons dans un groupe de mise à l'échelle automatique.
Donc, nos instances de AC2 de nos serveurs de jeu,
comme ils commencent à devenir plus occupé et plus en plus occupés,
ils vont simplement tourner une autre exemple, tourner un autre cas,
tourner une autre instance.
Donc, la technologie AWS dispose, il vous permet de spécifier les paramètres
autour de laquelle vos serveurs vont grandir.
Ainsi vous pouvez avoir un nombre n de serveurs là-bas à un moment donné.
Et si votre charge disparaît, ils vont rétrécir, le nombre va diminuer.
Et si la charge revient, il va grandir revenir en arrière, de manière élastique.
>> Donc, cela ressemble beaucoup.
Nous avons beaucoup d'instances EC2.
Nous pouvons mettre en cache avant de la base de données,
essayer et accélérer les bases de données.
Le point de pression prochaine généralement les gens voient
Ils escaladent est un jeu utilisant un Système de base de données relationnelle.
Jeez, la base de données la performance est terrible.
Comment pouvons-nous améliorer cela?
Essayons de mettre cache en face de cela.
>> Eh bien, cache ne fonctionne pas si grande dans les jeux, non?
Pour les jeux, l'écriture est douloureuse.
Les jeux sont très écrivent lourde.
Cache ne fonctionne pas lorsque vous êtes écrire lourde parce que vous avez toujours
obtenu de mettre à jour le cache.
Vous mettez à jour le cache, il est rien à être mise en cache.
Il est en fait juste un travail supplémentaire.
>> Alors, où nous allons ici?
Vous avez un gros goulot d'étranglement là-bas dans la base de données.
Et l'endroit où aller est évidemment le partitionnement.
Le partitionnement est pas facile à faire quand vous êtes
traiter avec les bases de données relationnelles.
Avec bases de données relationnelles, vous êtes responsable de la gestion, de manière efficace,
l'espace des clés.
Vous dites que les utilisateurs entre A et M rendez-vous ici, entre N et Z y aller.
Et vous êtes de commutation à travers l'application.
Donc, vous avez affaire à cette source de données de la partition.
Vous avez des contraintes transactionnelles qui ne couvrent pas les partitions.
Vous avez toutes sortes de désordre que vous êtes
traiter là-bas essayer pour faire face à la montée en puissance
et la construction d'une infrastructure plus large.
Il est juste pas drôle.
>> Auditoire: Alors, dites-vous que augmentant points sources accélère
le processus?
RICK HOULIHAN: augmentation?
Points Source: l'auditoire.
RICK HOULIHAN: points de Source?
Public: A partir de l'information, où l'information vient de?
RICK HOULIHAN: Non
Ce que je dis est l'augmentation de la nombre de partitions dans le magasin de données
améliore le débit.
Donc ce qui se passe ici est utilisateurs entrée en l'instance EC2 ici,
Eh bien, si je dois un utilisateur voilà A à M, je vais aller ici.
De N à P, je vais aller ici.
De P à Z, je vais aller ici.
>> AUDIENCE: OK, ce sont donc ceux tous stockés dans différents nœuds?
>> RICK HOULIHAN: Oui.
Pensez à ceux-ci comme différents silos de données.
Donc, vous êtes d'avoir à le faire.
Si vous essayez de le faire cela, si vous essayez
à l'échelle sur une plate-forme relationnelle, ceci est ce que vous faites.
Vous prenez les données et il vous abattre.
Et vous êtes le partitionner travers plusieurs instances de la base de données.
Et vous gérez tout ce qui au niveau de l'application.
Il n'y a pas de plaisir.
Alors, que voulons-nous aller?
Nous voulons aller DynamoDB, entièrement géré, Magasin de données NoSQL, disposition débit.
Nous utilisons des index secondaires.
Il est fondamentalement HTTP API et comprend support de document.
Donc, vous ne devez pas vous inquiéter que sur l'un de partitionnement.
Nous faisons tout pour vous.
Alors maintenant, à la place, vous il suffit d'écrire à la table.
Si le tableau doit être partitionné, ce qui se passe dans les coulisses.
Vous êtes complètement isolés à partir de cela comme un promoteur.
Alors parlons certains des cas d'utilisation
que nous nous heurtons à des jeux en commun scénarios de jeu, leaderboard.
Donc, vous avez utilisateurs venant, les BoardNames qu'ils sont
sur, les scores pour cet utilisateur.
Nous pourrions être hachage sur l'ID utilisateur, et puis nous avons la gamme sur le jeu.
Ainsi, chaque utilisateur veut voir tout le jeu qu'il a joué
et toute son meilleur score à travers tout le jeu.
Voilà donc son classement personnel.
>> Maintenant, je veux y aller et je veux get-- si je reçois ces classements personnels.
Ce que je veux faire est aller chercher le meilleur score de tous les utilisateurs.
Alors, comment puis-je faire?
Lorsque mon record est haché sur l'identification de l'utilisateur, se situait sur le jeu,
bien, je vais aller de l'avant et de restructurer, de créer un GSI,
et je vais restructurer ces données.
>> Maintenant, je vais sur le hachage BoardName, qui est le jeu.
Et je vais aller sur le plus haut score.
Et maintenant, je l'ai créé différents seaux.
Je suis en utilisant la même table, les mêmes données de l'élément.
Mais je crée un seau qui donne moi une agrégation de haut score en jeu.
>> Et je peux interroger cette table pour obtenir cette information.
Donc, je me suis fixé ce modèle de requête jusqu'à être soutenu par un index secondaire.
Maintenant, ils peuvent être triés par BoardName et classés par topscore, selon.
Donc vous pouvez le voir, ce sont des types d'utiliser des cas, vous obtenez dans le jeu.
Un autre bon cas d'utilisation nous obtenons dans le jeu est récompenses et qui a remporté les prix.
Et ceci est un grand cas d'utilisation où nous appelons indices épars.
Indices épars sont les capacité à générer
un indice qui ne signifie pas nécessairement contenir chaque article sur la table.
Et pourquoi pas?
Parce que l'attribut qui est en cours indexée ne existe pas sur chaque article.
>> Donc, dans ce cas particulier cas d'utilisation, je veux dire,
vous savez quoi, je vais créer un attribut appelé Award.
Et je vais donner à chaque utilisateur qui a un prix qui attribut.
Les utilisateurs qui ne disposent pas récompenses sont ne va pas avoir cet attribut.
Alors, quand je crée de la index, les seuls utilisateurs
qui vont montrer dans l'indice sont
ceux qui ont effectivement remporté des prix.
Voilà donc un excellent moyen d'être en mesure pour créer des index filtrées
sont très, très sélective qui ne le font pas avoir à l'index de la table entière.
>> Nous allons donc faire ici bas sur le temps.
Je vais aller de l'avant et sauter et sauter sur ce scénario.
Parlez-nous un peu about--
>> AUDIENCE: Puis-je poser une brève question?
On est lourde écrire?
RICK HOULIHAN: Qu'est-ce?
AUDIENCE: Ecrire lourde.
RICK HOULIHAN: Ecrire lourde.
Laisse moi voir.
>> AUDIENCE: Ou est-ce pas quelque chose que vous pouvez juste
voix dans une affaire de secondes?
RICK HOULIHAN: Nous allons à travers le scénario de vote.
C'est pas si mal.
Avez-vous les gars avez quelques minutes?
D'ACCORD.
>> Donc, nous allons parler de vote.
Donc vote en temps réel, nous avons exigences pour voter.
Les exigences sont que nous permettons chaque personne de voter qu'une seule fois.
Nous voulons que personne ne soit en mesure de modifier leur vote.
Nous voulons l'agrégation en temps réel et d'analyse pour la démographie
que nous allons être montrant aux utilisateurs sur le site.
>> Pensez à ce scénario.
Nous travaillons beaucoup de la réalité TV montre où ils sont
faire ce type exacte des choses.
Alors vous pouvez penser le scénario, nous avons des millions et des millions
là les filles de l'adolescence avec leurs téléphones cellulaires
et le vote et le vote, et voter pour qui ils sont
trouver d'être le plus populaire.
Donc, ce sont quelques-uns des exigences nous manquons.
>> Et donc la première prendre à résoudre ce problème
serait de construire un application très simple.
Donc, je dois cette application.
Je dois certains électeurs là-bas.
Ils viennent, ils ont frappé l'application de vote.
Je dois une certaine table votes premières Je vais simplement vider ces votes en.
Je vais devoir certains agrégats table de votes que
ferai de mon analyse et de la démographie, et nous allons mettre tout cela là-dedans.
>> Et ce qui est excellent.
La vie est belle.
La vie est bonne jusqu'à ce que nous découvrons que il ya toujours un ou deux seulement
les gens qui sont populaires à une élection.
Il ya seulement une ou deux choses que les gens se soucient vraiment.
Et si vous allez voter à échelle, tout d'un coup je suis
aller à marteler l'enfer hors de deux candidats, un ou deux candidats.
Un nombre très limité d'articles les gens trouvent à être populaire.
>> Ce ne sont pas un bon modèle de conception.
Ceci est en fait une très mauvais design pattern
parce qu'elle crée exactement ce que nous parlé qui était touches de raccourci.
Touches de raccourci sont quelque chose que nous ne voulons pas.
>> Alors, comment pouvons-nous résoudre ce problème?
Et vraiment, la façon de résoudre ce problème est en prenant ces seaux candidats
et pour chacun des candidats, nous avons, nous allons ajouter une valeur aléatoire,
quelque chose que nous savons, aléatoire valeur comprise entre un et 100,
entre 100 et 1000, ou entre une et 1000,
Cependant de nombreuses valeurs aléatoires que vous voulez ajouter sur l'extrémité de ce candidat.
>> Et qu'ai-je vraiment fait alors?
Si je suis en utilisant l'ID de candidat le seau pour ensemble des voix,
si je l'ai ajouté un hasard nombre à la fin de cette,
Je ai créé maintenant 10 seaux, un cent mille seaux, seaux
que je agrégation votes travers.
>> Donc je dois millions et des millions, et des millions de disques à venir dans
pour ces candidats, je suis répand maintenant ces votes à travers A_1 candidat
A_100 travers du candidat, parce chaque fois un vote arrive,
Je générer un hasard valeur comprise entre un et 100.
Je clouant sur la fin de la candidat à cette personne de voter pour.
Je le déverser dans le seau.
>> Maintenant, sur le dos, je sais que je me suis une centaine de seaux.
Alors, quand je veux aller de l'avant et agréger les votes,
Je lis de tous ces seaux.
Donc, je vais de l'avant et ajouter.
Et puis je ne comprends la dispersion où je sors et dis hey,
vous savez quoi, la clé de ce candidat espaces est plus d'une centaine seaux.
Je vais rassembler tous les les votes de ces cent seaux.
Je vais regrouper eux et je vais dire,
Un candidat a maintenant vote compte total de x.
>> Maintenant, les deux l'écriture requête et la requête de lecture
sont bien distribués parce que je vous écris pour
et je lis à travers des centaines de clés.
Je ne suis pas l'écriture et la lecture à travers une clé maintenant.
Voilà donc un excellent modèle.
>> Ceci est en fait probablement l'un de la conception la plus importante
modèles pour échelle dans NoSQL.
Vous verrez ce type de modèle de conception dans chaque saveur.
MongoDB, DynamoDB, il ne fait pas la matière, nous avons tous à faire.
Parce que quand vous avez affaire avec ces énormes rassemblements,
vous devez trouver un moyen de les étaler dans des seaux.
Donc, cela est la façon dont vous le faites.
Très bien, alors ce vous faites en ce moment
est que vous êtes négoce hors lecture le coût pour l'écriture évolutivité.
Le coût de ma lecture est un peu plus complexe
et je dois aller lire à partir d'un cent des seaux au lieu d'un.
Mais je suis capable d'écrire.
Et mon débit, mon écriture débit est incroyable.
Donc, il est généralement une précieuse technique de mise à l'échelle DynamoDB,
ou de toute base de données NoSQL pour cette question.
Donc, nous avons compris comment à l'échelle il.
Et nous avons pensé comment éliminer nos touches de raccourci.
Et cela est fantastique.
Et nous avons eu cette belle système.
Et il nous a donné le vote très correct parce que nous avons vote fiche de-dupe.
Il est construit dans DynamoDB.
Nous avons parlé des droits conditionnels.
>> Quand un électeur vient dans, puts un insert sur la table,
ils insèrent leur carte d'identité avec des électeurs, si elles essaient d'insérer un autre vote,
Je fais une écriture conditionnelle.
Dites seulement écrire ce si cela ne existe pas.
Donc dès que je vois que ce vote allons frapper la table,
personne d'autre va être en mesure de mettre leur vote.
Et cela est fantastique.
Et nous incrémentation nos comptoirs de candidats.
Et nous faisons de notre démographie et tout ça.
Mais qu'advient-il si mon demande tombe?
Maintenant, tout d'un soudaines votes sont à venir, et je
ne sais pas si ils se traitées dans mes analyses et démographie
plus.
Et lorsque l'application revient, comment
l'enfer que je sais ce votes ont été traitées et où dois-je commencer?
>> Donc, cela est un réel problème lorsque vous commencer à regarder ce type de scénario.
Et comment pouvons-nous résoudre cela?
Nous résolvons avec ce que nous appeler DynamoDB Streams.
Streams est un temps ordonné et partitionné journal de changement de tous les accès
à la table, chaque écriture accès à la table.
Toutes les données qui est écrit à la tableau montre sur le flux.
>> Il est fondamentalement une file d'attente de 24 heures.
Articles frappé le flux, ils vivent pendant 24 heures.
Ils peuvent être lus plusieurs fois.
Garanti pour être livrés une seule fois dans le flux,
pouvait-on lire n certain nombre de fois.
Donc, cependant le nombre de processus que vous voulez consommer que les données, vous pouvez consommer.
Il apparaîtra à chaque mise à jour.
Chaque écriture sera seulement apparaître une fois sur le flux.
Donc, vous ne devez pas vous inquiéter sur le traitement deux fois
à partir du même processus.
>> Il est strictement commandé par article.
Quand nous disons que le temps ordonné et partagé,
vous verrez par partition sur le flux.
Vous verrez articles, mises à jour dans l'ordre.
Nous ne sommes pas garantissons sur le flux que vous êtes
allez obtenir toutes les transactions dans l'ordre entre les items.
>> Donc, les ruisseaux sont idempotent.
Devons-nous savons tous ce que signifie idempotent?
Idempotent signifie que vous pouvez faire plus, et plus, et plus encore.
Le résultat va être la même chose.
>> Les flux sont idempotent, mais ils doivent être
joué du point de départ, où que vous choisissez, à la fin,
ou ils ne seront pas résulter dans les mêmes valeurs.
>> Même chose avec MongoDB.
MongoDB a une construction qu'ils appellent le oplog.
Il est de la même construction exacte.
Bases de données NoSQL Beaucoup cette construction.
Ils l'utilisent pour faire des choses comme la réplication, ce qui
est exactement ce que nous faisons avec des ruisseaux.
AUDIENCE: Peut-être un question hérétique, mais vous
parler applications faisant descendre un ainsi de suite.
Sont des flux garantis jamais peut-être aller vers le bas?
RICK HOULIHAN: Ouais, les ruisseaux sont garantis de ne jamais descendre.
Nous gérons l'infrastructure derrière. automatique des flux
déployer dans leur groupe de mise à l'échelle automatique.
Nous allons passer par un peu peu de ce qui se passe.
>> Je ne devrais pas dire qu'ils ne sont pas garantie de ne jamais descendre.
Les éléments sont garantis à apparaître dans le courant.
Et le flux sera accessible.
Donc ce qui se passe vers le bas ou revient jusqu'à, ce qui se passe en dessous.
Il désigne: il est OK.
Très bien, alors vous obtenez différente Voir les types hors de l'écran.
Les types de vue qui sont importantes pour un programmeur sont généralement, qu'est-ce?
Je reçois l'ancienne vue.
Lorsqu'une mise à jour sur la table, ça va pousser l'ancienne vue au flux
afin que les données peuvent archiver, ou de changement le contrôle, le changement identification, le changement
la gestion.
>> La nouvelle image, ce qu'elle est maintenant, après la mise à jour, qui est un autre type de vue
Tu peux recevoir.
Vous pouvez obtenir à la fois les anciennes et les nouvelles images.
Peut-être que je les veux à la fois.
Je veux voir ce qu'il était.
Je veux voir ce que cela a changé pour.
>> Je dois un type de conformité des processus qui exécute.
Il convient de vérifier que quand ces choses changent,
qu'ils sont dans certaines limites ou à l'intérieur de certains paramètres.
>> Et puis peut-être que je ne besoin de savoir ce qui a changé.
Je ne me soucie pas de ce que l'article modifié.
Je ne dois pas besoin de savoir ce attributs modifiés.
Je dois juste savoir que les articles sont touchés.
Donc, ce sont les types de vues que vous descendez le courant
et vous pouvez interagir avec.
>> L'application qui consomme le flux,
cela est une sorte de la façon dont cela fonctionne.
Client DynamoDB demander de des données vers les tables.
Streams déployer sur ce que nous appelons tessons.
Shards sont redimensionnées indépendamment de la table.
Ils ne sont pas alignés complètement les partitions de votre table.
Et la raison pour laquelle est parce qu'ils alignent
à la capacité, le courant la capacité de la table.
>> Ils se déploient dans leur propre groupe de mise à l'échelle automatique,
et ils commencent à tourner hors fonction sur le nombre d'écritures sont à venir dans,
combien reads-- vraiment qu'il est écrit.
Il n'y a pas reads-- mais comment de nombreuses écritures arrivent.
>> Et puis sur le dos fin, nous avons ce que nous
appeler un KCL ou Client Library Kinesis.
Kinesis est un flux de données la technologie de traitement d'Amazon.
Et flux est construit sur cela.
>> Donc, vous utilisez un KCL activé application de lire le flux.
Le Client Library Kinesis effectivement gère les travailleurs pour vous.
Et il fait aussi de la choses intéressantes.
Il va créer quelques tables jusqu'à dans votre DynamoDB tablespace
pour suivre quels articles ont été traitées.
Ainsi de cette façon si elle tombe en arrière, si il tombe et vient et obtient
se releva, il peut déterminer où était dans le traitement du flux.
>> Cela est très important lorsque vous parlez de la réplication.
Je dois savoir ce que a été traitée données
et quelles données n'a pas encore été traitée.
Donc, la bibliothèque KCL pour les flux volonté vous donner beaucoup de cette fonctionnalité.
Il prend soin de tout le ménage.
Il se lève un travailleur pour chaque fragment.
Il crée une table administrative pour chaque fragment, pour chaque travailleur.
Et que ceux des travailleurs feu, ils maintiennent ces tables
si vous savez ce disque a été lu et traité.
Et puis cette façon si le processus meurt et revient en ligne,
il peut reprendre là où il a décollé.
>> Donc, nous utilisons ce pour contre-région réplication.
Beaucoup de clients ont la nécessité de déplacer des données ou des parties de tableaux de données
autour de différentes régions.
Il ya neuf régions dans le monde entier.
Donc il pourrait y avoir un I need-- pourraient avoir les utilisateurs en Asie, les utilisateurs
dans la côte Est des États-Unis.
Ils ont des données différentes qui doit être distribuée localement.
Et peut-être un utilisateur d'oiseau de Asie vers les Etats-Unis,
et je tiens à répliquer ses données avec lui.
Alors, quand il descend de l'avion, il a une bonne expérience de l'utilisation de son application mobile.
>> Vous pouvez utiliser la croix-région bibliothèque de réplication pour ce faire.
Fondamentalement, nous avons fourni deux technologies.
Un est une application de la console, vous pouvez se tenir debout sur votre propre instance EC2.
Il fonctionne réplication pure.
Et puis nous vous avons donné la bibliothèque.
La bibliothèque vous pouvez utiliser pour construire votre propre application si vous
vouloir faire des choses folles avec ce data-- filtre, reproduire une partie seulement de celui-ci,
pivoter les données, le déplacer dans un table différente, ainsi de suite et ainsi de suite.
Voilà donc le genre de ce qui ressemble.
>> DynamoDB flux peuvent être traitées par ce que nous appelons Lambda.
Nous avons mentionné un peu plus sur l'événement architectures applicatives entraînés.
Lambda est un élément clé de cette.
Lambda est le code qui se déclenche à la demande en réponse à un événement particulier.
L'un de ces événements pourrait être un dossier apparaissant sur le flux.
Si un enregistrement apparaît sur le flux, nous appelons cette fonction Java.
Eh bien, ce que JavaScript et Lambda soutient Node.js, Java, Python,
et va bientôt soutenir d'autres langues aussi.
Et il suffit de dire, il est pur code.
écrite en Java, vous définissez une classe.
Vous poussez le JAR haut dans Lambda.
Et puis vous spécifiez quelle classe d'appeler en réponse à laquelle événement.
Et puis l'infrastructure Lambda derrière qui se déroulera ce code.
>> Ce code peut traiter enregistrements hors du flux.
Il peut faire ce qu'il veut avec elle.
Dans cet exemple particulier, tout ce que nous sommes vraiment faire est connecter les attributs.
Mais cela est tout simplement le code.
Code peut faire quelque chose, non?
>> Donc vous pouvez faire pivoter ces données.
Vous pouvez créer une vue dérivée.
Si il est une structure de document, vous pouvez aplatir la structure.
Vous pouvez créer des index suppléants.
Toutes sortes de choses que vous pouvez faire avec les Streams DynamoDB.
>> Et vraiment, voilà à quoi ça ressemble.
Ainsi, vous obtenez les mises à jour à venir dans.
Ils arrivent au large de la chaîne.
Ils sont lus par la fonction Lambda.
Ils sont en rotation les données et poussant vers le haut dans les tableaux dérivés,
notifient les systèmes externes de changement, et en poussant des données dans ElastiCache.
>> Nous avons parlé de la façon de mettre le cache en face de la base de données pour que les ventes
scénario.
Eh bien ce qui se passe si je mettre à jour la description de l'article?
Eh bien, si je devais un Lambda la fonction en cours d'exécution sur cette table,
si je mets à jour la description de l'article, il va ramasser la fiche hors du flux,
et il va mettre à jour le ElastiCache exemple avec les nouvelles données.
Voilà donc un grand nombre de ce que nous faisons avec Lambda.
Il est le code de la colle, des connecteurs.
Et il donne en réalité la capacité de lancer
et d'exécuter des applications très complexes sans un serveur dédié
infrastructures, ce qui est vraiment cool.
>> Donc, revenons à notre en temps réel de l'architecture de vote.
Ceci est nouveau et amélioré avec notre ruisseaux et KCL permis application.
Comme avant, nous pouvons gérer toute échelle de l'élection.
Nous aimons ça.
Nous faisons des fronces de dispersion sur plusieurs godets.
Nous avons verrouillage optimiste passe.
Nous pouvons garder nos électeurs de modifier leurs votes.
Ils ne peuvent voter qu'une seule fois.
C'est fantastique.
Tolérance de panne en temps réel, agrégation évolutive maintenant.
Si la chose tombe, il sait où se relancer
quand il revient parce que nous utilisons l'application KCL.
Et puis nous pouvons également utiliser cette Demande KCL à pousser sur des données
Redshift à d'autres analyse d'applications, ou de l'utilisation
les MapReduce élastiques à courir streaming en temps réel hors agrégations
de ces données.
>> Donc, ce sont des choses que nous ont pas beaucoup parlé.
Mais ils sont plus technologies qui viennent
à porter lorsque vous êtes à la recherche à ces types de scénarios.
>> Très bien, alors que ce sujet de Analytics avec DynamoDB Streams.
Vous pouvez gagner de-dupe les données, faire toutes sortes
des trucs sympa, les données agrégées dans la mémoire, de créer ces tables dérivés.
Voilà un énorme cas d'utilisation que beaucoup de clients
sont impliqués avec, en prenant le imbriquée propriétés de ces documents JSON
et la création d'index supplémentaires.
>> Nous sommes à la fin.
Merci pour porter avec moi.
Alors parlons architecture de référence.
DynamoDB se trouve au milieu de tant une grande partie de l'infrastructure AWS.
Fondamentalement, vous pouvez le brancher jusqu'à ce que vous voulez.
Les applications créées à l'aide Dynamo comprennent Lambda, ElastiCache, CloudSearch,
pousser les données dehors dans Elastic MapReduce, import export de DynamoDB
en S3, tous les types de flux de travail.
Mais sans doute le meilleur chose à parler,
et ceci est ce qui est vraiment intéressant est lorsque nous
parler des applications Event Driven.
>> Ceci est un exemple de un projet interne
que nous avons où nous sommes effectivement l'édition de recueillir des résultats de l'enquête.
Ainsi, dans un lien e-mail que nous envoyons, il y
être un peu cliquez sur le lien en disant ici pour répondre à l'enquête.
Et quand une personne clics ce lien, ce qui se passe
est qu'ils renversent une sécurisé HTML formulaire d'enquête à partir de S3.
Il n'y a pas serveur.
Ceci est juste un objet S3.
>> Cette forme apparaît, charges dans le navigateur.
Il est obtenu Backbone.
Il faut que ce complexe JavaScript qu'il est en cours d'exécution.
Donc, il est l'application très riche exécute dans le navigateur du client.
Ils ne savent pas qu'ils ne sont pas interagir avec un serveur dorsal.
À ce stade, il est tout navigateur.
>> Ils publient les résultats à ce nous appelons la passerelle API Amazon.
Passerelle API est simplement une API web que vous pouvez définir et brancher
à ce que vous voulez.
Dans ce cas particulier, nous sommes accroché à une fonction lambda.
>> Donc mon opération POST est passe avec aucun serveur.
Fondamentalement, ce que la passerelle API est assis là.
Il ne me coûte rien tant que les gens commencer à poster à elle, non?
La fonction lambda se trouve juste là.
Et cela me coûte rien jusqu'à les gens commencent à le frapper.
Donc vous pouvez voir, que le volume augmentations, qui est quand les accusations viennent.
Je ne vais pas tourner un serveur 7/24.
>> Donc, je tire la forme bas du seau,
et je posterai via l'API Porte d'entrée dans la fonction Lambda.
Et puis le Lambda Fonction dit, vous savez
ce qui, je l'ai obtenu quelques PII, certains informations personnellement identifiables
dans ces réponses.
Je me suis commentaires provenant des utilisateurs.
Je dois adresses e-mail.
Je dois les noms d'utilisateur.
>> Permettez-moi de partager ce off.
Je vais générer des métadonnées hors cette fiche.
Et je vais pousser le métadonnées dans DynamoDB.
Et je ne pouvais crypter toutes les données et le pousser dans DynamoDB si je veux.
Mais il est plus facile pour moi, dans ce utiliser cas, à aller de l'avant d'un mot à dire,
Je vais pousser les données brutes dans un seau S3 crypté.
Donc je utiliser construit dans le côté du serveur S3 chiffrement et de gestion des clés d'Amazon
Service de sorte que je dois une clé qui peut tourner sur un intervalle régulier,
et je peux protéger que les données PII dans le cadre de l'ensemble de ce flux de travail.
>> Donc, qu'ai-je fait?
Je viens déployé ensemble demande, et je ne serveur.
Alors est-ce que l'événement demande entraînée l'architecture fait pour vous.
>> Maintenant, si vous pensez le cas d'utilisation pour this--
nous avons d'autres clients dont je parle à environ cette architecture exacte qui
lancer de grandes campagnes phénoménale, qui sont à la recherche sur la question et va, oh mon.
Parce que maintenant, ils peuvent essentiellement pousser là-bas,
laisser cette campagne se asseoir là jusqu'à ce qu'il lance, et non
avoir à se soucier d'une guigne ce genre d'infrastructure
va être là pour le soutenir.
Et puis, dès que cette campagne est faite,
il est comme l'infrastructure va juste immédiatement loin
car il vraiment a pas d'infrastructure.
Il est juste le code qui se trouve sur Lambda.
Il est juste que les données se trouve dans DynamoDB.
Il est un moyen extraordinaire pour construire des applications.
>> AUDIENCE: Donc, il est plus éphémère qu'il ne le serait
si elle a été stockée sur un serveur actuel?
>> RICK HOULIHAN: Absolument.
Parce que l'instance du serveur devra être un 7/24.
Il doit être disponible pour quelqu'un pour répondre à.
Eh bien devinez quoi?
S3 est disponible 7/24.
S3 répond toujours.
Et S3 est très, très bon à servir des objets.
Ces objets peuvent être des fichiers HTML, ou Fichiers Javascript, ou ce que vous voulez.
Vous pouvez courir très riches applications Web sur seaux S3, et les gens le font.
>> Et pour que l'idée est ici est de sortir de la voie
nous avons l'habitude de penser à ce sujet.
Nous avons tous l'habitude de penser en termes de serveurs et hôtes.
Cela ne concerne pas ça.
Il est à propos de l'infrastructure code.
Déployer le code pour le nuage et laissez le nuage exécuté pour vous.
Et qui est ce que AWS essaie de faire.
>> AUDIENCE: Donc, votre boîte d'or au milieu de la passerelle API est pas comme serveur,
mais est just--
>> RICK HOULIHAN: Vous pouvez penser de ce que la façade du serveur.
Tout ce qu'il est est il va prendre un HTTP demander et la carte à un autre processus.
Voilà tout ce qu'il fait.
Et dans ce cas, nous allons cartographier à une fonction Lambda.
Tout droit, de sorte que tout est je suis arrivé.
Merci beaucoup.
Je vous en suis reconnaissant.
Je sais que nous voulons un peu plus de temps.
Et nous espérons que vous les gars GOT un peu de l'information
que vous pouvez emporter aujourd'hui.
Et je me excuse si je suis allé sur certains de vos têtes,
mais il ya un bon nombre de connaissances fondamentales fondamentale
que je pense est très précieux pour vous.
Je vous remercie de me recevoir.
[APPLAUDISSEMENTS]
AUDIENCE: [inaudible] est lorsque vous disiez
vous avez eu à passer par la chose du début jusqu'à la fin
pour obtenir les bonnes valeurs ou les mêmes valeurs,
comment serait les valeurs changer si [inaudible].
>> RICK HOULIHAN: Oh, idempotent?
Comment les valeurs allaient changer?
Eh bien, parce que si je ne courais pas tout le chemin jusqu'à la fin,
alors je ne sais pas ce qui change ont été faites dans le dernier mile.
Il ne va pas être le mêmes données que ce que je voyais.
AUDIENCE: Oh, si vous venez de ont pas obtenu l'entrée entière.
RICK HOULIHAN: Droit.
Vous devez aller du début à la fin, et alors il est
va être un état cohérent.
Cool.
>> Auditoire: Alors, vous nous avez montré DynamoDB peut faire document ou la valeur de clé.
Et nous avons passé beaucoup de temps sur le valeur de la clé avec un hachage et les moyens
pour la retourner autour.
Lorsque vous avez regardé ces tableaux, est que laissant derrière lui l'approche de document?
>> RICK HOULIHAN: Je ne voudrais pas dire laisser derrière eux.
>> AUDIENCE: Ils ont été séparés de the--
>> RICK HOULIHAN: Avec le document approche, le type de document dans DynamoDB
est il suffit de penser comme un autre attribut.
Il est un attribut qui contient une structure de données hiérarchique.
Et puis dans les requêtes, vous pouvez utiliser les propriétés
de ces objets à l'aide Object Notation.
Donc, je peux filtrer sur un imbriquée propriété du document JSON.
Auditoire: Alors, chaque fois que je faire une approche de documents,
Je peux sorte d'arriver à l'tabular--
AUDIENCE: Absolument.
Audience: --indexes et choses que vous venez de parler.
RICK HOULIHAN: Ouais, le index et tout ce qui,
lorsque vous souhaitez indexer le propriétés du JSON,
la façon dont nous aurions à faire est si vous insérez un objet JSON ou un document
en Dynamo, vous souhaitez utiliser les flux.
Streams liraient l'entrée.
Vous obtiendrez ce que JSON objet et vous diriez OK,
ce qui est la propriété Je veux à l'index?
>> Vous créez une table dérivée.
Maintenant que est la façon dont cela fonctionne en ce moment.
Nous ne vous permettons pas à l'index directement ces propriétés.
>> AUDIENCE: Tabularizing vos documents.
>> RICK HOULIHAN: Exactement, aplatissement il, tabularizing il, exactement.
Voilà ce que vous faites avec lui.
>> AUDIENCE: Je vous remercie.
>> RICK HOULIHAN: Yep, absolument, je vous remercie.
Auditoire: Alors, il est une sorte de Mongo rencontre classifers Redis.
>> RICK HOULIHAN: Ouais, il est un peu comme ça.
Voilà une bonne description pour elle.
Cool.