1 00:00:00,000 --> 00:00:04,969 >> [Jouer de la musique] 2 00:00:04,969 --> 00:00:06,010 RICK HOULIHAN: Très bien. 3 00:00:06,010 --> 00:00:06,600 Salut tout le monde. 4 00:00:06,600 --> 00:00:07,670 Mon nom est Rick Houlihan. 5 00:00:07,670 --> 00:00:10,330 Je suis un directeur principal architecte de solutions AWS. 6 00:00:10,330 --> 00:00:14,070 Je me concentre sur NoSQL et DynamoDB technologies. 7 00:00:14,070 --> 00:00:16,930 Je suis ici aujourd'hui pour parler vous un peu plus sur ceux-ci. 8 00:00:16,930 --> 00:00:18,970 >> Mon arrière-plan est principalement dans la couche de données. 9 00:00:18,970 --> 00:00:21,390 Je passais la moitié de mon développement carrière en écrivant base de données, 10 00:00:21,390 --> 00:00:25,930 accès aux données, des solutions pour diverses applications. 11 00:00:25,930 --> 00:00:30,000 Je suis allé dans la virtualisation Couverture depuis environ 20 ans. 12 00:00:30,000 --> 00:00:33,460 Donc, avant de le Cloud était le Cloud, nous avions l'habitude de l'appeler l'informatique utilitaire. 13 00:00:33,460 --> 00:00:37,170 Et l'idée a été, il est comme PG & E, vous payez ce que vous utilisez. 14 00:00:37,170 --> 00:00:38,800 Aujourd'hui, nous appelons le nuage. 15 00:00:38,800 --> 00:00:41,239 >> Mais au fil des ans, je travaille pour un couple de sociétés 16 00:00:41,239 --> 00:00:42,530 vous avez probablement jamais entendu parler. 17 00:00:42,530 --> 00:00:47,470 Mais je l'ai compilé une liste de techniques réalisations, je suppose que vous dites. 18 00:00:47,470 --> 00:00:51,620 Je dois huit brevets dans les systèmes de Cloud la virtualisation, la conception des microprocesseurs, 19 00:00:51,620 --> 00:00:54,440 traitement des événements complexes, et d'autres domaines aussi. 20 00:00:54,440 --> 00:00:58,290 >> Donc, ces jours, je me concentre principalement sur NoSQL technologies et la prochaine génération 21 00:00:58,290 --> 00:00:59,450 base de données. 22 00:00:59,450 --> 00:01:03,370 Et qui est généralement ce que je vais d'être ici à vous parler aujourd'hui au sujet. 23 00:01:03,370 --> 00:01:06,030 Donc, ce que vous pouvez vous attendre de cette session, 24 00:01:06,030 --> 00:01:08,254 nous allons passer par une brève histoire de traitement des données. 25 00:01:08,254 --> 00:01:10,420 Il est toujours utile de comprendre d'où nous venons 26 00:01:10,420 --> 00:01:12,400 et pourquoi nous sommes là où nous sommes. 27 00:01:12,400 --> 00:01:15,600 Et nous allons parler un peu peu de technologies NoSQL 28 00:01:15,600 --> 00:01:17,500 à partir d'un point de vue fondamental. 29 00:01:17,500 --> 00:01:19,870 >> Nous allons entrer dans quelques-uns des les internes DynamoDB. 30 00:01:19,870 --> 00:01:24,350 DynamoDB est sans saveur d'AWS. 31 00:01:24,350 --> 00:01:27,340 Il est entièrement géré et solution NoSQL hébergé. 32 00:01:27,340 --> 00:01:32,420 Et nous allons parler un peu plus sur la table structure, API, types de données, index, 33 00:01:32,420 --> 00:01:35,177 et une partie des équipements internes de cette technologie de DynamoDB. 34 00:01:35,177 --> 00:01:37,760 Nous allons entrer dans une partie de la conception les modèles et les meilleures pratiques. 35 00:01:37,760 --> 00:01:39,968 Nous allons parler de la façon dont vous utiliser cette technologie pour certains 36 00:01:39,968 --> 00:01:41,430 des applications d'aujourd'hui. 37 00:01:41,430 --> 00:01:44,820 Et puis nous allons parler un peu à propos de l'évolution ou l'émergence 38 00:01:44,820 --> 00:01:48,980 d'un nouveau paradigme dans la programmation applications appelées event-driven 39 00:01:48,980 --> 00:01:51,580 et comment DynamoDB joue dans cette ainsi. 40 00:01:51,580 --> 00:01:54,690 Et nous allons vous laisser un peu de une discussion de l'architecture de référence 41 00:01:54,690 --> 00:01:59,540 afin que nous puissions parler de certaines des les façons dont vous pouvez utiliser DynamoDB. 42 00:01:59,540 --> 00:02:04,116 >> Alors d'abord off-- cela est une question Je entends beaucoup est, ce qui est une base de données. 43 00:02:04,116 --> 00:02:06,240 Beaucoup de gens pensent qu'ils savoir ce qu'est une base de données est. 44 00:02:06,240 --> 00:02:08,360 Si vous Google, vous verrez cela. 45 00:02:08,360 --> 00:02:11,675 Il est un un ensemble structuré de données tenue dans un ordinateur, en particulier celle qui 46 00:02:11,675 --> 00:02:13,600 est accessible de diverses manières. 47 00:02:13,600 --> 00:02:16,992 Je suppose que ce un bon définition d'une base de données moderne. 48 00:02:16,992 --> 00:02:19,450 Mais je ne l'aime pas, parce elle implique un certain nombre de choses. 49 00:02:19,450 --> 00:02:20,935 Elle implique structure. 50 00:02:20,935 --> 00:02:23,120 Et cela implique que ce soit sur un ordinateur. 51 00:02:23,120 --> 00:02:25,750 Et les bases de données ne l'ont pas existent toujours sur les ordinateurs. 52 00:02:25,750 --> 00:02:28,020 Bases de données existaient effectivement à bien des égards. 53 00:02:28,020 --> 00:02:32,000 >> Donc, une meilleure définition d'un base de données est quelque chose comme ça. 54 00:02:32,000 --> 00:02:34,786 Une base de données est un organisé mécanisme de stockage, la gestion, 55 00:02:34,786 --> 00:02:35,910 et la récupération d'informations. 56 00:02:35,910 --> 00:02:36,868 Ceci est d'About.com. 57 00:02:36,868 --> 00:02:42,080 Donc, je l'aime parce que cela parle vraiment à propos de la base de données étant un référentiel, 58 00:02:42,080 --> 00:02:44,800 un référentiel de informations, pas nécessairement 59 00:02:44,800 --> 00:02:46,780 quelque chose qui se trouve sur un ordinateur. 60 00:02:46,780 --> 00:02:49,290 Et tout au long de l'histoire, nous ont pas toujours eu les ordinateurs. 61 00:02:49,290 --> 00:02:52,110 >> Maintenant, si je demande à la moyenne ce qui est aujourd'hui développeur 62 00:02:52,110 --> 00:02:54,770 une base de données, qui est la réponse que je reçois. 63 00:02:54,770 --> 00:02:56,070 Quelque part, je peux coller des trucs. 64 00:02:56,070 --> 00:02:56,670 Droit? 65 00:02:56,670 --> 00:02:58,725 Et il est vrai. 66 00:02:58,725 --> 00:02:59,600 Mais il est malheureux. 67 00:02:59,600 --> 00:03:02,700 Parce que la base de données est vraiment le fondement de l'application moderne. 68 00:03:02,700 --> 00:03:04,810 Il est le fondement de chaque application. 69 00:03:04,810 --> 00:03:07,240 Et comment vous construisez que base de données, comment vous structurez 70 00:03:07,240 --> 00:03:11,750 que les données va dicter que application effectue comme vous échelle. 71 00:03:11,750 --> 00:03:14,640 >> Il ya donc beaucoup de mon travail aujourd'hui est face à ce 72 00:03:14,640 --> 00:03:17,180 qui se passe lorsque les développeurs cette approche 73 00:03:17,180 --> 00:03:19,510 et faire face aux conséquences d'une application qui 74 00:03:19,510 --> 00:03:24,966 est maintenant mise à l'échelle au-delà de l'original l'intention et la souffrance de la mauvaise conception. 75 00:03:24,966 --> 00:03:26,840 Alors, espérons quand vous à pied aujourd'hui, vous 76 00:03:26,840 --> 00:03:29,010 avoir un couple d'outils dans votre ceinture que vous tiendrons 77 00:03:29,010 --> 00:03:32,566 de faire les mêmes erreurs. 78 00:03:32,566 --> 00:03:33,066 D'accord. 79 00:03:33,066 --> 00:03:36,360 Donc, parlons un peu de la chronologie de la technologie de base de données. 80 00:03:36,360 --> 00:03:38,830 Je crois avoir lu un Article pas si longtemps, 81 00:03:38,830 --> 00:03:43,020 et il a dit quelque chose sur le lines-- il est une déclaration très poétique. 82 00:03:43,020 --> 00:03:46,590 Il dit l'histoire de traitement des données est 83 00:03:46,590 --> 00:03:49,350 plein de talons filigranes de l'abondance de données. 84 00:03:49,350 --> 00:03:49,920 D'ACCORD. 85 00:03:49,920 --> 00:03:52,532 Maintenant, je suppose que ce genre de vrai. 86 00:03:52,532 --> 00:03:54,990 Mais en fait je regarde est aussi l'histoire est en réalité rempli 87 00:03:54,990 --> 00:03:56,820 avec high watermark de la pression des données. 88 00:03:56,820 --> 00:04:00,040 Étant donné que le débit de données l'ingestion ne se couche jamais. 89 00:04:00,040 --> 00:04:01,360 Il ne monte. 90 00:04:01,360 --> 00:04:03,670 >> Et lorsque se produit l'innovation nous voyons la pression de données, ce qui 91 00:04:03,670 --> 00:04:07,825 est la quantité de données qui est maintenant à venir dans le système. 92 00:04:07,825 --> 00:04:12,027 Et il ne peut pas être traitée efficace dans le temps ou de coût. 93 00:04:12,027 --> 00:04:14,110 Et voilà où nous commençons de regarder à la pression des données. 94 00:04:14,110 --> 00:04:15,920 >> Alors, quand on regarde la première base de données, cette 95 00:04:15,920 --> 00:04:17,180 est celui qui était entre nos oreilles. 96 00:04:17,180 --> 00:04:18,310 Nous sommes tous nés avec elle. 97 00:04:18,310 --> 00:04:19,194 Il est une belle base de données. 98 00:04:19,194 --> 00:04:21,110 Il a une haute disponibilité. 99 00:04:21,110 --> 00:04:21,959 Il est toujours sur. 100 00:04:21,959 --> 00:04:23,930 Vous pouvez toujours obtenir. 101 00:04:23,930 --> 00:04:24,890 >> Mais il est seul utilisateur. 102 00:04:24,890 --> 00:04:26,348 Je ne peux pas partager mes pensées avec vous. 103 00:04:26,348 --> 00:04:28,370 Vous ne pouvez pas obtenir mes pensées quand vous le souhaitez. 104 00:04:28,370 --> 00:04:30,320 Et leur abilitiy est pas si bon. 105 00:04:30,320 --> 00:04:32,510 Nous oublions les choses. 106 00:04:32,510 --> 00:04:36,540 Chaque maintenant et puis, l'un de nous feuilles et se déplace à une autre existence 107 00:04:36,540 --> 00:04:39,110 et nous perdons tout qui était dans cette base de données. 108 00:04:39,110 --> 00:04:40,640 Voilà donc pas tout ce que bon. 109 00:04:40,640 --> 00:04:43,189 >> Et cela a bien fonctionné au fil du temps quand nous étions de retour dans la journée 110 00:04:43,189 --> 00:04:46,230 quand tout ce que nous avions vraiment besoin de savoir est où allons-nous aller demain 111 00:04:46,230 --> 00:04:49,630 ou lorsque nous nous réunissons la meilleure nourriture. 112 00:04:49,630 --> 00:04:52,820 Mais comme nous avons commencé à grandir en tant que la civilisation et de gouvernement ont commencé 113 00:04:52,820 --> 00:04:55,152 de naître, et les entreprises ont commencé à évoluer, 114 00:04:55,152 --> 00:04:57,360 nous avons commencé à nous rendre compte besoin d'un peu plus que ce que 115 00:04:57,360 --> 00:04:58,210 nous pourrions mettre dans notre tête. 116 00:04:58,210 --> 00:04:58,870 D'accord? 117 00:04:58,870 --> 00:05:00,410 >> Nous avions besoin de systèmes d'enregistrement. 118 00:05:00,410 --> 00:05:02,220 Nous avions besoin d'endroits pour être capables de stocker des données. 119 00:05:02,220 --> 00:05:05,450 Nous avons donc commencé la rédaction de documents, création bibliothèques et les archives. 120 00:05:05,450 --> 00:05:08,000 Nous avons commencé le développement d'un Un système de comptabilité du grand livre. 121 00:05:08,000 --> 00:05:12,200 Et ce système de comptage livre a couru le monde depuis de nombreux siècles, 122 00:05:12,200 --> 00:05:15,580 et peut-être même des millénaires que nous sorte de grandi au point 123 00:05:15,580 --> 00:05:18,420 où cette charge de données dépassé la capacité de ces systèmes 124 00:05:18,420 --> 00:05:19,870 pour être en mesure de le contenir. 125 00:05:19,870 --> 00:05:22,070 >> Et ce réellement passé dans les années 1880. 126 00:05:22,070 --> 00:05:22,570 Droit? 127 00:05:22,570 --> 00:05:24,390 Dans le recensement américain de 1880. 128 00:05:24,390 --> 00:05:26,976 Ceci est vraiment là où le tournage signaler traitement de données moderne. 129 00:05:26,976 --> 00:05:28,850 Ceci est le point lequel la quantité de données 130 00:05:28,850 --> 00:05:32,060 qui a été recueilli par le Gouvernement américain est arrivé au point 131 00:05:32,060 --> 00:05:34,005 où il a fallu huit ans pour traiter. 132 00:05:34,005 --> 00:05:36,350 >> Aujourd'hui, huit années-- que vous le savez, le recensement 133 00:05:36,350 --> 00:05:39,180 circule toutes les 10 années-- il est donc assez évident que par le temps que nous 134 00:05:39,180 --> 00:05:41,419 obtenu le recensement de 1890, la quantité de données que 135 00:05:41,419 --> 00:05:43,210 allait être traitée par le gouvernement était 136 00:05:43,210 --> 00:05:46,335 va dépasser les 10 années qu'il porterait à lancé le nouveau recensement. 137 00:05:46,335 --> 00:05:47,250 Ce fut un problème. 138 00:05:47,250 --> 00:05:49,000 >> Donc, un gars nommé Herman Hollerith venu 139 00:05:49,000 --> 00:05:52,640 et il a inventé l'unité enregistrement fractionné cartes, lecteur de cartes perforées, carte perforée 140 00:05:52,640 --> 00:05:58,420 tabulation, et le classement de les mécanismes de cette technologie. 141 00:05:58,420 --> 00:06:01,860 Et cette société qu'il forme à la temps, avec quelques autres, 142 00:06:01,860 --> 00:06:05,450 effectivement devenu l'un des piliers d'une petite entreprise que nous connaissons aujourd'hui appelé IBM. 143 00:06:05,450 --> 00:06:08,417 >> Ainsi était à l'origine dans IBM l'entreprise de base de données. 144 00:06:08,417 --> 00:06:09,750 Et qui est vraiment ce qu'ils ont fait. 145 00:06:09,750 --> 00:06:11,110 Ils ont fait le traitement des données. 146 00:06:11,110 --> 00:06:15,400 >> Comme si la prolifération de punch cartes, un des mécanismes ingénieux 147 00:06:15,400 --> 00:06:18,560 d'être en mesure de tirer parti de cette la technologie d'interroger triés jeux de résultats. 148 00:06:18,560 --> 00:06:20,726 Vous pouvez voir sur cette photo là, nous avons un little-- 149 00:06:20,726 --> 00:06:23,970 il est un peu small-- mais vous pouvez voir un mécanisme mécanique très ingénieux 150 00:06:23,970 --> 00:06:26,970 où nous avons un jeu de cartes perforées. 151 00:06:26,970 --> 00:06:28,720 Et la prise de quelqu'un un petit tournevis 152 00:06:28,720 --> 00:06:31,400 et coller à travers le fentes et soulevant 153 00:06:31,400 --> 00:06:34,820 pour obtenir ce match, qui résultats triés fixés. 154 00:06:34,820 --> 00:06:36,270 >> Ceci est une agrégation. 155 00:06:36,270 --> 00:06:38,690 Nous le faisons tout le temps aujourd'hui dans l'ordinateur, 156 00:06:38,690 --> 00:06:40,100 où vous le faites dans la base de données. 157 00:06:40,100 --> 00:06:41,620 Nous avons utilisé le faire manuellement, non? 158 00:06:41,620 --> 00:06:42,994 Les gens mettent ces choses ensemble. 159 00:06:42,994 --> 00:06:45,440 Et ce fut la prolifération de ces cartes perforées 160 00:06:45,440 --> 00:06:50,070 dans ce que nous appelions tambours de données et moulinets de données, ruban de papier. 161 00:06:50,070 --> 00:06:55,980 >> L'industrie de transformation de données a une leçon des pianos mécaniques. 162 00:06:55,980 --> 00:06:57,855 Pianos de retour à Le tournant du siècle 163 00:06:57,855 --> 00:07:02,100 l'habitude d'utiliser des bobines de papier avec des fentes à dire ce qui touches à jouer. 164 00:07:02,100 --> 00:07:05,380 Alors que la technologie a été adaptée éventuellement à stocker des données numériques, 165 00:07:05,380 --> 00:07:08,070 parce qu'ils ne pouvaient mettre que les données sur les bobines de bande de papier. 166 00:07:08,070 --> 00:07:10,870 >> Or, à la suite, des données a été actually-- comment 167 00:07:10,870 --> 00:07:14,960 vous accédez à ces données était directement dépendant de la façon dont vous l'avez enregistré. 168 00:07:14,960 --> 00:07:17,825 Donc, si je mets les données sur une bande, Je devais accéder aux données de façon linéaire. 169 00:07:17,825 --> 00:07:20,475 Je devais rouler l'ensemble bande pour accéder à toutes les données. 170 00:07:20,475 --> 00:07:22,600 Si je mets les données dans Punch cartes, je ne pouvais y accéder 171 00:07:22,600 --> 00:07:26,270 dans un peu plus aléatoire la mode, peut-être pas aussi rapidement. 172 00:07:26,270 --> 00:07:30,770 >> 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. 173 00:07:30,770 --> 00:07:32,890 Et cela a donc été un problème aller dans les années 50. 174 00:07:32,890 --> 00:07:37,890 Encore une fois, nous pouvons commencer à voir que, comme nous développer de nouvelles technologies pour traiter 175 00:07:37,890 --> 00:07:41,670 les données, à droite, il ouvre la porte à de nouvelles solutions, 176 00:07:41,670 --> 00:07:45,852 pour de nouveaux programmes, de nouveaux demandes de ces données. 177 00:07:45,852 --> 00:07:47,810 Et vraiment, la gouvernance peut avoir été la raison 178 00:07:47,810 --> 00:07:49,435 pourquoi nous avons développé certains de ces systèmes. 179 00:07:49,435 --> 00:07:52,290 Mais les affaires devient rapidement le pilote derrière l'évolution 180 00:07:52,290 --> 00:07:54,720 de la base de données et moderne le système de fichiers moderne. 181 00:07:54,720 --> 00:07:56,870 >> Donc, la prochaine chose que a été soulevé dans les années 50 182 00:07:56,870 --> 00:08:00,780 était le système de fichiers et le développement de stockage à accès aléatoire. 183 00:08:00,780 --> 00:08:02,050 Ce était belle. 184 00:08:02,050 --> 00:08:06,230 Maintenant, tout d'un coup, nous pouvons mettre notre fichiers partout sur ces disques durs 185 00:08:06,230 --> 00:08:09,760 et nous pouvons accéder à ces données de façon aléatoire. 186 00:08:09,760 --> 00:08:11,950 Nous pouvons analyser que informations sur les fichiers. 187 00:08:11,950 --> 00:08:14,920 Et nous avons résolu tous le monde de problèmes avec le traitement des données. 188 00:08:14,920 --> 00:08:17,550 >> Et qui a duré environ 20 ou 30 ans jusqu'à ce que l'évolution 189 00:08:17,550 --> 00:08:22,100 de la base de données relationnelle, qui est où le monde nous avons décidé maintenant 190 00:08:22,100 --> 00:08:27,940 besoin d'avoir un référentiel qui bat l'étalement des données dans le fichier 191 00:08:27,940 --> 00:08:29,540 les systèmes que nous avons construit. Droit? 192 00:08:29,540 --> 00:08:34,270 Trop de données distribués en trop endroits, la déduplication des données, 193 00:08:34,270 --> 00:08:37,120 et le coût de stockage était énorme. 194 00:08:37,120 --> 00:08:43,760 >> Dans les années 70, la ressource la plus chère un ordinateur qui avait été le stockage. 195 00:08:43,760 --> 00:08:46,200 Le processeur était vu comme un coût fixe. 196 00:08:46,200 --> 00:08:49,030 Quand je achète la boîte, le CPU fait un peu de travail. 197 00:08:49,030 --> 00:08:51,960 Ça va être de savoir si la filature ça fonctionne réellement ou non. 198 00:08:51,960 --> 00:08:53,350 Voilà vraiment un coût irrécupérable. 199 00:08:53,350 --> 00:08:56,030 >> Mais ce qui me coûter un entreprise est le stockage. 200 00:08:56,030 --> 00:09:00,020 Si je dois acheter plus de disques prochaine mois, qui est un coût réel que je paie. 201 00:09:00,020 --> 00:09:01,620 Et que le stockage est coûteux. 202 00:09:01,620 --> 00:09:05,020 >> Maintenant, nous avance rapide de 40 années et nous avons un problème différent. 203 00:09:05,020 --> 00:09:10,020 Le calcul est maintenant le ressource la plus coûteuse. 204 00:09:10,020 --> 00:09:11,470 Le stockage est pas cher. 205 00:09:11,470 --> 00:09:14,570 Je veux dire, nous ne pouvons aller nulle part sur le Cloud et nous pouvons trouver de stockage pas cher. 206 00:09:14,570 --> 00:09:17,190 Mais ce que je ne peux pas trouver de calcul est pas cher. 207 00:09:17,190 --> 00:09:20,700 >> Ainsi, l'évolution des aujourd'hui la technologie, de la technologie de base de données, 208 00:09:20,700 --> 00:09:23,050 est vraiment concentré autour bases de données distribuées 209 00:09:23,050 --> 00:09:26,960 qui ne souffrent pas de le même type d'échelle 210 00:09:26,960 --> 00:09:29,240 limitations de bases de données relationnelles. 211 00:09:29,240 --> 00:09:32,080 Nous parlerons un peu ce que cela signifie réellement. 212 00:09:32,080 --> 00:09:34,760 >> Mais l'une des raisons, et le pilote derrière this-- nous 213 00:09:34,760 --> 00:09:38,290 parlé de la pression des données. 214 00:09:38,290 --> 00:09:41,920 La pression des données est quelque chose qui entraîne l'innovation. 215 00:09:41,920 --> 00:09:44,610 Et si vous regardez plus les cinq dernières années, 216 00:09:44,610 --> 00:09:48,180 ceci est un tableau de ce que les données charge à travers l'entreprise générale 217 00:09:48,180 --> 00:09:49,640 ressemble dans les cinq dernières années. 218 00:09:49,640 --> 00:09:52,570 >> Et la règle générale de pouce ces days-- Si vous allez Google-- 219 00:09:52,570 --> 00:09:55,290 est de 90% des données qui nous stockons aujourd'hui, et il était 220 00:09:55,290 --> 00:09:57,330 généré au cours des deux dernières années. 221 00:09:57,330 --> 00:09:57,911 D'ACCORD. 222 00:09:57,911 --> 00:09:59,410 Maintenant, ce ne est pas une tendance qui est nouveau. 223 00:09:59,410 --> 00:10:01,230 Ceci est une tendance qui a été sortir pour 100 ans. 224 00:10:01,230 --> 00:10:03,438 Depuis Herman Hollerith développé la carte de pointage, 225 00:10:03,438 --> 00:10:08,040 nous avons construit des référentiels de données et la collecte de données à des vitesses phénoménales. 226 00:10:08,040 --> 00:10:10,570 >> Donc, au cours des 100 dernières années, nous avons vu cette tendance. 227 00:10:10,570 --> 00:10:11,940 Cela ne va pas changer. 228 00:10:11,940 --> 00:10:14,789 À l'avenir, nous allons voir ce, sinon une tendance accélérée. 229 00:10:14,789 --> 00:10:16,330 Et vous pouvez voir à quoi ça ressemble. 230 00:10:16,330 --> 00:10:23,510 >> Si une entreprise en 2010 avait un téraoctet de données sous gestion, 231 00:10:23,510 --> 00:10:27,080 aujourd'hui que signifie qu'ils sont la gestion de 6,5 pétaoctets de données. 232 00:10:27,080 --> 00:10:30,380 Voilà 6.500 fois plus de données. 233 00:10:30,380 --> 00:10:31,200 Et je sais que cela. 234 00:10:31,200 --> 00:10:33,292 Je travaille avec ces entreprises chaque jour. 235 00:10:33,292 --> 00:10:35,000 Il ya cinq ans, je parlerait aux entreprises 236 00:10:35,000 --> 00:10:38,260 qui me parler de ce qu'une douleur il est de gérer des téraoctets de données. 237 00:10:38,260 --> 00:10:39,700 Et ils parleraient pour moi sur la façon dont nous voyons 238 00:10:39,700 --> 00:10:41,825 que ce va probablement être un pétaoctet ou deux 239 00:10:41,825 --> 00:10:43,030 au sein d'un couple d'années. 240 00:10:43,030 --> 00:10:45,170 >> Ces mêmes sociétés aujourd'hui, je vais rencontrer, 241 00:10:45,170 --> 00:10:48,100 et ils me parler de la problème y at-il d'avoir la gestion 242 00:10:48,100 --> 00:10:51,440 des dizaines, 20 pétaoctets de données. 243 00:10:51,440 --> 00:10:53,590 Donc, l'explosion de la données de l'industrie 244 00:10:53,590 --> 00:10:56,670 est le moteur de l'énorme besoin de meilleures solutions. 245 00:10:56,670 --> 00:11:00,980 Et la base de données relationnelle est tout simplement pas à la hauteur de la demande. 246 00:11:00,980 --> 00:11:03,490 >> Et donc il ya un linéaire corrélation entre les données de pression 247 00:11:03,490 --> 00:11:05,210 et l'innovation technique. 248 00:11:05,210 --> 00:11:07,780 L'histoire nous a montré ce, que dans le temps, 249 00:11:07,780 --> 00:11:11,090 chaque fois que le volume de données qui doit être traité 250 00:11:11,090 --> 00:11:15,490 dépasse la capacité du système de le traiter en un temps raisonnable 251 00:11:15,490 --> 00:11:18,870 ou à un coût raisonnable, puis les nouvelles technologies 252 00:11:18,870 --> 00:11:21,080 sont inventés pour résoudre ces problèmes. 253 00:11:21,080 --> 00:11:24,090 Ces nouvelles technologies, à son tour, ouvrir la porte 254 00:11:24,090 --> 00:11:27,840 une autre série de problèmes, dont est la collecte des données encore plus. 255 00:11:27,840 --> 00:11:29,520 >> Maintenant, on ne va pas pour arrêter cela. 256 00:11:29,520 --> 00:11:30,020 Droit? 257 00:11:30,020 --> 00:11:31,228 On ne va pas pour arrêter cela. 258 00:11:31,228 --> 00:11:31,830 Pourquoi? 259 00:11:31,830 --> 00:11:35,520 Parce que vous ne pouvez pas tout savoir qu'il ya à savoir dans l'univers. 260 00:11:35,520 --> 00:11:40,510 Et tant que nous avons été en vie, tout au long de l'histoire de l'homme, 261 00:11:40,510 --> 00:11:43,440 nous avons toujours poussé à en savoir plus. 262 00:11:43,440 --> 00:11:49,840 >> Donc, il semble que chaque pouce nous nous déplaçons sur le chemin de la découverte scientifique, 263 00:11:49,840 --> 00:11:54,620 nous multiplions la quantité de données que nous devons traiter de façon exponentielle 264 00:11:54,620 --> 00:11:59,920 comme nous découvrir plus et de plus en plus sur les rouages ​​de la vie, 265 00:11:59,920 --> 00:12:04,530 sur la façon dont fonctionne l'univers, à propos de entraînement de la découverte scientifique, 266 00:12:04,530 --> 00:12:06,440 et que l'invention nous faisons aujourd'hui. 267 00:12:06,440 --> 00:12:09,570 Le volume de données tout augmente continuellement. 268 00:12:09,570 --> 00:12:12,120 Donc, être en mesure de faire face à ce problème est énorme. 269 00:12:12,120 --> 00:12:14,790 270 00:12:14,790 --> 00:12:17,410 >> Donc, l'une des choses nous attendons que pourquoi NoSQL? 271 00:12:17,410 --> 00:12:19,200 Comment ne NoSQL résoudre ce problème? 272 00:12:19,200 --> 00:12:24,980 Eh bien, bases de données relationnelles, Structured Query Language, 273 00:12:24,980 --> 00:12:28,600 SQL-- qui est vraiment une construction de la relationnelle database-- ces choses sont 274 00:12:28,600 --> 00:12:30,770 optimisé pour le stockage. 275 00:12:30,770 --> 00:12:33,180 >> Retour dans les années 70, encore une fois, disque est coûteux. 276 00:12:33,180 --> 00:12:36,990 L'exercice de provisionnement du stockage dans l'entreprise est sans fin. 277 00:12:36,990 --> 00:12:37,490 Je sais. 278 00:12:37,490 --> 00:12:38,020 Je l'ai vécu. 279 00:12:38,020 --> 00:12:41,250 Je l'ai écrit des pilotes de stockage pour un société de superserver Enterprised 280 00:12:41,250 --> 00:12:42,470 Retour dans les années 90. 281 00:12:42,470 --> 00:12:45,920 Et la ligne de fond engrange une autre baie de stockage était juste quelque chose qui 282 00:12:45,920 --> 00:12:47,600 événements tous les jours dans l'entreprise. 283 00:12:47,600 --> 00:12:49,030 Et il n'a jamais cessé. 284 00:12:49,030 --> 00:12:52,690 Stockage de densité supérieure, la demande pour le stockage haute densité, 285 00:12:52,690 --> 00:12:56,340 et pour le stockage plus efficace devices-- il n'a jamais arrêté. 286 00:12:56,340 --> 00:13:00,160 >> Et NoSQL est une grande technologie parce qu'il normalise les données. 287 00:13:00,160 --> 00:13:02,210 Il de-duplication des données. 288 00:13:02,210 --> 00:13:07,180 Il place les données dans une structure qui est agnostique à chaque modèle d'accès. 289 00:13:07,180 --> 00:13:11,600 Plusieurs applications peuvent frapper que Base de données SQL, exécuter des requêtes ad hoc, 290 00:13:11,600 --> 00:13:15,950 et obtenir des données sous la forme qu'ils besoin de traiter de leurs charges de travail. 291 00:13:15,950 --> 00:13:17,570 Cela semble fantastique. 292 00:13:17,570 --> 00:13:21,350 Mais la ligne de fond est avec tout système, si elle est agnostique à tout, 293 00:13:21,350 --> 00:13:23,500 il est optimisé pour rien. 294 00:13:23,500 --> 00:13:24,050 D'accord? 295 00:13:24,050 --> 00:13:26,386 >> Et qui est ce que nous obtenons avec la base de données relationnelle. 296 00:13:26,386 --> 00:13:27,510 Il est optimisé pour le stockage. 297 00:13:27,510 --> 00:13:28,280 Il est normalisé. 298 00:13:28,280 --> 00:13:29,370 Il est relationnelle. 299 00:13:29,370 --> 00:13:31,660 Il prend en charge les requêtes ad hoc. 300 00:13:31,660 --> 00:13:34,000 Et lui et il échelles verticalement. 301 00:13:34,000 --> 00:13:39,030 >> Si je dois obtenir une plus grande base de données SQL ou une base de données SQL plus puissant, 302 00:13:39,030 --> 00:13:41,090 Je vais acheter un plus gros morceau de fer. 303 00:13:41,090 --> 00:13:41,600 D'accord? 304 00:13:41,600 --> 00:13:44,940 Je travaille avec un grand nombre de clients qui ont été par le biais d'importantes améliorations 305 00:13:44,940 --> 00:13:48,340 dans leur infrastructure SQL seulement à savoir six mois plus tard, 306 00:13:48,340 --> 00:13:49,750 ils sont à nouveau frapper le mur. 307 00:13:49,750 --> 00:13:55,457 Et la réponse d'Oracle ou MSSQL ou quelqu'un d'autre est d'obtenir une boîte plus grande. 308 00:13:55,457 --> 00:13:58,540 Eh bien, tôt ou tard, vous ne pouvez pas acheter un plus grande boîte, et que ce problème réel. 309 00:13:58,540 --> 00:14:00,080 Nous devons effectivement changer les choses. 310 00:14:00,080 --> 00:14:01,080 Alors d'où vient ce travail? 311 00:14:01,080 --> 00:14:06,560 Il fonctionne bien pour déconnecté analyse, les charges de travail de type OLAP. 312 00:14:06,560 --> 00:14:08,670 Et qui est vraiment là SQL appartient. 313 00:14:08,670 --> 00:14:12,540 Maintenant, il est utilisé aujourd'hui dans de nombreux en ligne type de traitement transactionnel 314 00:14:12,540 --> 00:14:13,330 applications. 315 00:14:13,330 --> 00:14:16,460 Et cela fonctionne très bien au un certain niveau d'utilisation, 316 00:14:16,460 --> 00:14:18,670 mais il n'a tout simplement pas à l'échelle la façon dont NoSQL fait. 317 00:14:18,670 --> 00:14:20,660 Et nous allons parler un peu peu pourquoi ce qui est. 318 00:14:20,660 --> 00:14:23,590 >> Maintenant, NoSQL, d'autre part, est plus optimisé pour calculer. 319 00:14:23,590 --> 00:14:24,540 D'accord? 320 00:14:24,540 --> 00:14:26,830 Il est pas agnostique le modèle d'accès. 321 00:14:26,830 --> 00:14:31,620 Est ce que nous appelons de-normalisée une structure ou une structure hiérarchique. 322 00:14:31,620 --> 00:14:35,000 Les données en une base de données relationnelle est réunis à partir de plusieurs tables 323 00:14:35,000 --> 00:14:36,850 pour produire le point de vue que vous avez besoin. 324 00:14:36,850 --> 00:14:40,090 Les données dans une base de données NoSQL sont stockées dans un document 325 00:14:40,090 --> 00:14:42,100 contient la structure hiérarchique. 326 00:14:42,100 --> 00:14:45,670 Toutes les données qui serait normalement réunis pour produire cette vue 327 00:14:45,670 --> 00:14:47,160 sont stockées dans un seul document. 328 00:14:47,160 --> 00:14:50,990 Et nous allons parler un peu de comment ça marche dans un couple de graphiques. 329 00:14:50,990 --> 00:14:55,320 >> Mais l'idée ici est que vous stockez vos données que ces points de vue instancié. 330 00:14:55,320 --> 00:14:56,410 D'accord? 331 00:14:56,410 --> 00:14:58,610 Vous évolutivité horizontale. 332 00:14:58,610 --> 00:14:59,556 Droit? 333 00:14:59,556 --> 00:15:02,100 Si je dois augmenter la taille de mon groupe NoSQL, 334 00:15:02,100 --> 00:15:03,700 Je ne dois pas avoir une plus grande boîte. 335 00:15:03,700 --> 00:15:05,200 Je reçois une autre boîte. 336 00:15:05,200 --> 00:15:07,700 Et je Cluster ceux ensemble, et je peux Shard que les données. 337 00:15:07,700 --> 00:15:10,780 Nous parlerons un peu ce sharding est, pour être 338 00:15:10,780 --> 00:15:14,270 capable d'évoluer cette base de données à travers de multiples dispositifs physiques 339 00:15:14,270 --> 00:15:18,370 et de supprimer la barrière qui exige de moi à l'échelle verticale. 340 00:15:18,370 --> 00:15:22,080 >> Donc, il est vraiment construit pour ligne le traitement des transactions et de l'échelle. 341 00:15:22,080 --> 00:15:25,480 Il ya une grande distinction ici entre les rapports, non? 342 00:15:25,480 --> 00:15:27,810 Compte-rendu, je ne connais pas la questions que je vais poser. 343 00:15:27,810 --> 00:15:28,310 Droit? 344 00:15:28,310 --> 00:15:30,570 Reporting-- si quelqu'un de mon département marketing 345 00:15:30,570 --> 00:15:34,520 veut just-- combien de mes clients avoir cette caractéristique particulière qui 346 00:15:34,520 --> 00:15:37,850 acheté sur ce day-- Je ne sais pas ce interroger qu'ils vont demander. 347 00:15:37,850 --> 00:15:39,160 Donc je dois être agnostique. 348 00:15:39,160 --> 00:15:41,810 >> Or, dans une ligne application transactionnelle, 349 00:15:41,810 --> 00:15:43,820 Je sais quelles sont les questions que je pose. 350 00:15:43,820 --> 00:15:46,581 Je construit pour l'application un flux de travail très spécifique. 351 00:15:46,581 --> 00:15:47,080 D'accord? 352 00:15:47,080 --> 00:15:50,540 Donc, si je optimiser les données stocker pour soutenir ce flux de travail, 353 00:15:50,540 --> 00:15:52,020 ça va être plus rapide. 354 00:15:52,020 --> 00:15:55,190 Et voilà pourquoi peut NoSQL vraiment accélérer la livraison 355 00:15:55,190 --> 00:15:57,710 de ces types de services. 356 00:15:57,710 --> 00:15:58,210 D'accord. 357 00:15:58,210 --> 00:16:00,501 >> Donc, nous allons entrer dans un peu de théorie ici. 358 00:16:00,501 --> 00:16:03,330 Et certains d'entre vous, vos yeux pourrait reculer un peu. 359 00:16:03,330 --> 00:16:06,936 Mais je vais essayer de le garder niveau aussi élevé que possible. 360 00:16:06,936 --> 00:16:08,880 Donc, si vous êtes dans le projet la gestion, il est 361 00:16:08,880 --> 00:16:12,280 un produit d'assemblage appelé le triangle de contraintes. 362 00:16:12,280 --> 00:16:12,936 D'ACCORD. 363 00:16:12,936 --> 00:16:16,060 Le triangle des Contraint diktats vous ne pouvez pas tout avoir tout le temps. 364 00:16:16,060 --> 00:16:17,750 Vous ne pouvez pas avoir votre gâteau et le manger aussi. 365 00:16:17,750 --> 00:16:22,310 Donc, dans la gestion de projet, ce triangle contraintes est que vous pouvez avoir pas cher, 366 00:16:22,310 --> 00:16:24,710 vous pouvez le faire rapidement, ou vous pouvez avoir une bonne. 367 00:16:24,710 --> 00:16:25,716 Choisis en deux. 368 00:16:25,716 --> 00:16:27,090 Parce que vous ne pouvez pas avoir tous les trois. 369 00:16:27,090 --> 00:16:27,460 Droit? 370 00:16:27,460 --> 00:16:27,820 D'ACCORD. 371 00:16:27,820 --> 00:16:28,920 >> Donc vous entendu parler de ce lot. 372 00:16:28,920 --> 00:16:31,253 Il est une triple contrainte, triangle de la triple contrainte, 373 00:16:31,253 --> 00:16:34,420 ou le triangle de fer est oftentimes-- quand vous parlez aux gestionnaires de projets, 374 00:16:34,420 --> 00:16:35,420 ils vont parler. 375 00:16:35,420 --> 00:16:37,640 Maintenant, les bases de données ont leur propre triangle de fer. 376 00:16:37,640 --> 00:16:40,350 Et le triangle de fer des données est ce que nous appelons la PAC théorème. 377 00:16:40,350 --> 00:16:41,580 D'accord? 378 00:16:41,580 --> 00:16:43,770 >> PAC diktats théorème comment fonctionnent les bases de données 379 00:16:43,770 --> 00:16:45,627 sous une condition très spécifique. 380 00:16:45,627 --> 00:16:47,460 Et nous allons parler ce que cette condition est. 381 00:16:47,460 --> 00:16:52,221 Mais les trois points du triangle, pour ainsi dire, sont C, la cohérence. 382 00:16:52,221 --> 00:16:52,720 D'accord? 383 00:16:52,720 --> 00:16:56,760 Donc, dans la PAC, la cohérence signifie que tous les les clients qui peuvent accéder à la base de données 384 00:16:56,760 --> 00:16:59,084 aura toujours une très vue cohérente des données. 385 00:16:59,084 --> 00:17:00,750 Personne ne va voir deux choses différentes. 386 00:17:00,750 --> 00:17:01,480 D'accord? 387 00:17:01,480 --> 00:17:04,020 Si je vois la base de données, Je vois la même vue 388 00:17:04,020 --> 00:17:06,130 que mon partenaire qui voit la même base de données. 389 00:17:06,130 --> 00:17:07,470 Voilà la cohérence. 390 00:17:07,470 --> 00:17:12,099 >> Disponibilité signifie que si le base de données en ligne, si elle peut être atteint, 391 00:17:12,099 --> 00:17:14,760 que tous les clients seront toujours être capable de lire et d'écrire. 392 00:17:14,760 --> 00:17:15,260 D'accord? 393 00:17:15,260 --> 00:17:17,010 Ainsi, chaque client qui peut lire la base de données 394 00:17:17,010 --> 00:17:18,955 sera toujours en mesure de lecture données de données et à écrire. 395 00:17:18,955 --> 00:17:21,819 Et si tel est le cas, il est un système disponible. 396 00:17:21,819 --> 00:17:24,230 >> Et le troisième point est ce que nous appelons la tolérance de partition. 397 00:17:24,230 --> 00:17:24,730 D'accord? 398 00:17:24,730 --> 00:17:28,160 Des moyens de tolérance de partition que le système fonctionne bien 399 00:17:28,160 --> 00:17:32,000 en dépit de réseau physique cloisons entre les nœuds. 400 00:17:32,000 --> 00:17:32,760 D'accord? 401 00:17:32,760 --> 00:17:36,270 Donc nœuds dans le cluster ne peut pas parler les uns aux autres, ce qui se passe? 402 00:17:36,270 --> 00:17:36,880 D'accord. 403 00:17:36,880 --> 00:17:39,545 >> Bases de données relationnelles Donc choisir-- vous pouvez choisir deux de ces derniers. 404 00:17:39,545 --> 00:17:40,045 D'ACCORD. 405 00:17:40,045 --> 00:17:43,680 Bases de données relationnelles donc choisir d'être cohérent et disponible. 406 00:17:43,680 --> 00:17:47,510 Si la partition qui se passe entre les DataNodes dans le magasin de données, 407 00:17:47,510 --> 00:17:48,831 la base de données se bloque. 408 00:17:48,831 --> 00:17:49,330 Droit? 409 00:17:49,330 --> 00:17:50,900 Il va juste en bas. 410 00:17:50,900 --> 00:17:51,450 D'ACCORD. 411 00:17:51,450 --> 00:17:54,230 >> Et c'est pourquoi ils ont à grandir avec de grosses boîtes. 412 00:17:54,230 --> 00:17:54,730 Droit? 413 00:17:54,730 --> 00:17:58,021 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 414 00:17:58,021 --> 00:17:59,590 qui fonctionnent de cette façon. 415 00:17:59,590 --> 00:18:03,019 Mais la plupart des bases de données échelle verticalement dans une seule boîte. 416 00:18:03,019 --> 00:18:05,060 Parce qu'ils ont besoin d'être cohérente et disponible. 417 00:18:05,060 --> 00:18:10,320 Si une partition devait être injectée, alors vous auriez à faire un choix. 418 00:18:10,320 --> 00:18:13,720 Vous devez faire un choix entre étant compatible et disponible. 419 00:18:13,720 --> 00:18:16,080 >> Et qui est ce que les bases de données NoSQL font. 420 00:18:16,080 --> 00:18:16,580 D'accord. 421 00:18:16,580 --> 00:18:20,950 Donc, une base de données NoSQL, il est disponible en deux saveurs. 422 00:18:20,950 --> 00:18:22,990 Nous have-- bien, il vient en plusieurs saveurs, 423 00:18:22,990 --> 00:18:26,140 mais il est livré avec deux de base characteristics-- ce 424 00:18:26,140 --> 00:18:30,050 nous pourrions appeler la base de données de CP, ou d'un la tolérance et la partition cohérente 425 00:18:30,050 --> 00:18:31,040 système. 426 00:18:31,040 --> 00:18:34,930 Ces gars-là font le choix que lorsque les noeuds perdent le contact avec l'autre, 427 00:18:34,930 --> 00:18:37,091 on ne va pas pour permettre les gens à écrire plus. 428 00:18:37,091 --> 00:18:37,590 D'accord? 429 00:18:37,590 --> 00:18:41,855 >> Jusqu'à cette partition est supprimée, l'accès en écriture est bloqué. 430 00:18:41,855 --> 00:18:43,230 Cela signifie qu'ils ne sont pas disponibles. 431 00:18:43,230 --> 00:18:44,510 Ils sont cohérents. 432 00:18:44,510 --> 00:18:46,554 Quand on voit que partition elle-même injecter, 433 00:18:46,554 --> 00:18:48,470 nous sommes maintenant cohérente, parce que nous ne sommes pas aller 434 00:18:48,470 --> 00:18:51,517 pour permettre la modification des données sur deux côtés de la cloison de façon indépendante 435 00:18:51,517 --> 00:18:52,100 les uns des autres. 436 00:18:52,100 --> 00:18:54,130 Nous devrons rétablir la communication 437 00:18:54,130 --> 00:18:56,930 avant toute mise à jour les données sont admis. 438 00:18:56,930 --> 00:18:58,120 D'accord? 439 00:18:58,120 --> 00:19:02,650 >> La saveur prochaine serait un système AP, ou un disponible et partagé 440 00:19:02,650 --> 00:19:03,640 Système de tolérance. 441 00:19:03,640 --> 00:19:05,320 Ces gars-là ne se soucient pas. 442 00:19:05,320 --> 00:19:06,020 Droit? 443 00:19:06,020 --> 00:19:08,960 Tout nœud qui obtient un écrivons, nous allons le prendre. 444 00:19:08,960 --> 00:19:11,480 Donc, je suis reproduire mes données sur plusieurs nœuds. 445 00:19:11,480 --> 00:19:14,730 Ces nœuds obtiennent un client, client vient en, dit, je vais écrire des données. 446 00:19:14,730 --> 00:19:16,300 Noeud dit, pas de problème. 447 00:19:16,300 --> 00:19:18,580 Le noeud à côté de lui se une écriture sur le même enregistrement, 448 00:19:18,580 --> 00:19:20,405 il va dire aucun problème. 449 00:19:20,405 --> 00:19:23,030 Quelque part en arrière sur la fin de dos, que les données va répliquer. 450 00:19:23,030 --> 00:19:27,360 Et puis quelqu'un va réaliser, uh-oh, ils se rendront compte système, uh-oh, 451 00:19:27,360 --> 00:19:28,870 il ya eu une mise à jour pour les deux côtés. 452 00:19:28,870 --> 00:19:30,370 Qu'est-ce qu'on fait? 453 00:19:30,370 --> 00:19:33,210 Et ce qu'ils font est alors ils font quelque chose qui 454 00:19:33,210 --> 00:19:36,080 leur permet de résoudre cet état de données. 455 00:19:36,080 --> 00:19:39,000 Et nous allons parler que, dans la liste suivante. 456 00:19:39,000 --> 00:19:40,000 >> Chose à souligner ici. 457 00:19:40,000 --> 00:19:42,374 Et je ne vais pas être trop beaucoup en cela, parce que ce 458 00:19:42,374 --> 00:19:43,510 pénètre dans la théorie de données de profondeur. 459 00:19:43,510 --> 00:19:46,670 Mais il ya une transactionnel cadre qui 460 00:19:46,670 --> 00:19:50,680 courses dans un système relationnel qui me permet de faire des mises à jour en toute sécurité 461 00:19:50,680 --> 00:19:53,760 à plusieurs entités dans la base de données. 462 00:19:53,760 --> 00:19:58,320 Et ces mises à jour auront lieu tout à la fois ou pas du tout. 463 00:19:58,320 --> 00:20:00,500 Et ce qu'on appelle les transactions ACID. 464 00:20:00,500 --> 00:20:01,000 D'accord? 465 00:20:01,000 --> 00:20:06,570 >> ACIDE nous donne atomicité, cohérence, l'isolement, et la durabilité. 466 00:20:06,570 --> 00:20:07,070 D'accord? 467 00:20:07,070 --> 00:20:13,550 Cela signifie atomiques, les transactions, tout mes mises à jour se produisent soit ou ils ne le font pas. 468 00:20:13,550 --> 00:20:16,570 La cohérence signifie que la base de données sera toujours 469 00:20:16,570 --> 00:20:19,780 être amené dans une cohérentes Etat après une mise à jour. 470 00:20:19,780 --> 00:20:23,900 Je ne quitterai jamais la base de données dans un mauvais état après avoir appliqué une mise à jour. 471 00:20:23,900 --> 00:20:24,400 D'accord? 472 00:20:24,400 --> 00:20:26,720 >> Donc, il est un peu différent que la cohérence de la PAC. 473 00:20:26,720 --> 00:20:29,760 Signifie la cohérence de la PAC tout mon les clients peuvent toujours voir les données. 474 00:20:29,760 --> 00:20:34,450 Signifie que, lorsque la consistance ACIDE une transaction est fait, les données de bon. 475 00:20:34,450 --> 00:20:35,709 Mes relations sont tous bons. 476 00:20:35,709 --> 00:20:38,750 Je ne vais pas à supprimer une ligne de parent et laisser un groupe d'enfants orphelins 477 00:20:38,750 --> 00:20:40,970 dans une autre table. 478 00:20:40,970 --> 00:20:44,320 Il ne peut pas se passer si je suis cohérente dans une transaction acide. 479 00:20:44,320 --> 00:20:49,120 >> Isolement signifie que les transactions toujours se produire une après l'autre. 480 00:20:49,120 --> 00:20:51,920 Le résultat de la fin de données sera le même état 481 00:20:51,920 --> 00:20:54,770 comme si ces transactions qui ont été émis simultanément 482 00:20:54,770 --> 00:20:57,340 ont été exécutés en série. 483 00:20:57,340 --> 00:21:00,030 Il est donc la concurrence contrôle dans la base de données. 484 00:21:00,030 --> 00:21:04,130 Donc, fondamentalement, je ne peux pas incrémenter le même valeur deux fois avec deux opérations. 485 00:21:04,130 --> 00:21:08,580 >> Mais si je dis ajouter 1 à cette valeur, et deux opérations viennent dans 486 00:21:08,580 --> 00:21:10,665 et essayer de le faire, on est va y arriver en premier 487 00:21:10,665 --> 00:21:12,540 et de l'autre allez y arriver après. 488 00:21:12,540 --> 00:21:15,210 Donc à la fin, je ajouté deux. 489 00:21:15,210 --> 00:21:16,170 Vous voyez ce que je veux dire? 490 00:21:16,170 --> 00:21:16,670 D'ACCORD. 491 00:21:16,670 --> 00:21:19,220 492 00:21:19,220 --> 00:21:21,250 >> La durabilité est assez simple. 493 00:21:21,250 --> 00:21:23,460 Lorsque la transaction est reconnu, il est 494 00:21:23,460 --> 00:21:26,100 allez y être encore si le système se bloque. 495 00:21:26,100 --> 00:21:29,230 Lorsque ce système récupère, qui transaction qui a été commis 496 00:21:29,230 --> 00:21:30,480 est en fait va être là. 497 00:21:30,480 --> 00:21:33,130 Voilà donc les garanties des transactions ACID. 498 00:21:33,130 --> 00:21:35,470 Ce sont de belles garanties jolie à disposer sur une base de données, 499 00:21:35,470 --> 00:21:36,870 mais ils viennent à ce prix. 500 00:21:36,870 --> 00:21:37,640 Droit? 501 00:21:37,640 --> 00:21:40,520 >> Étant donné que le problème avec ce cadre est 502 00:21:40,520 --> 00:21:44,540 si il y a une partition dans les données ensemble, je dois prendre une décision. 503 00:21:44,540 --> 00:21:48,000 Je vais avoir à permettre mises à jour sur un côté ou de l'autre. 504 00:21:48,000 --> 00:21:50,310 Et si cela arrive, alors je suis ne va plus 505 00:21:50,310 --> 00:21:52,630 pour être en mesure de maintenir ces caractéristiques. 506 00:21:52,630 --> 00:21:53,960 Ils ne seront pas cohérents. 507 00:21:53,960 --> 00:21:55,841 Ils ne seront pas isolés. 508 00:21:55,841 --> 00:21:58,090 Cette est l'endroit où il se décompose pour les bases de données relationnelles. 509 00:21:58,090 --> 00:22:01,360 Ceci est la raison relationnelle bases de données échelle verticale. 510 00:22:01,360 --> 00:22:05,530 >> D'autre part, nous avons ce qu'on appelle la technologie de BASE. 511 00:22:05,530 --> 00:22:07,291 Et ce sont des bases de données NoSQL vos. 512 00:22:07,291 --> 00:22:07,790 D'accord. 513 00:22:07,790 --> 00:22:10,180 Donc, nous avons notre CP, bases de données AP. 514 00:22:10,180 --> 00:22:14,720 Et ce sont ce que vous appelez essentiellement disponibles, état mou, finalement 515 00:22:14,720 --> 00:22:15,740 cohérent. 516 00:22:15,740 --> 00:22:16,420 D'accord? 517 00:22:16,420 --> 00:22:19,690 >> Fondamentalement disponibles, parce ils sont tolérants partition. 518 00:22:19,690 --> 00:22:21,470 Ils seront toujours là, même si il ya 519 00:22:21,470 --> 00:22:23,053 une partition de réseau entre les noeuds. 520 00:22:23,053 --> 00:22:25,900 Si je peux parler à un nœud, je suis va être en mesure de lire les données. 521 00:22:25,900 --> 00:22:26,460 D'accord? 522 00:22:26,460 --> 00:22:30,810 Je ne pourrais pas toujours être capable d'écrire données si je suis une plate-forme cohérente. 523 00:22:30,810 --> 00:22:32,130 Mais je serai en mesure de lire les données. 524 00:22:32,130 --> 00:22:34,960 525 00:22:34,960 --> 00:22:38,010 >> L'état indique douce que quand je lis que les données, 526 00:22:38,010 --> 00:22:40,790 il pourrait ne pas être le même que les autres nœuds. 527 00:22:40,790 --> 00:22:43,390 Si un droit a été émis sur un noeud ailleurs dans le cluster 528 00:22:43,390 --> 00:22:46,650 et il n'a pas répliqué à travers le grappe encore quand je lis que les données, 529 00:22:46,650 --> 00:22:48,680 cet état pourrait ne pas être compatible. 530 00:22:48,680 --> 00:22:51,650 Cependant, il sera éventuellement cohérentes, 531 00:22:51,650 --> 00:22:53,870 ce qui signifie que lorsqu'une écriture est réalisée dans le système, 532 00:22:53,870 --> 00:22:56,480 il se répliquera dans les noeuds. 533 00:22:56,480 --> 00:22:59,095 Et finalement, l'état sera mis en ordre, 534 00:22:59,095 --> 00:23:00,890 et ce sera un état cohérent. 535 00:23:00,890 --> 00:23:05,000 >> Maintenant, le théorème CAP vraiment joue que dans un seul état. 536 00:23:05,000 --> 00:23:08,700 Cette condition est quand cela arrive. 537 00:23:08,700 --> 00:23:13,710 Parce que chaque fois qu'il est en fonctionnement mode normal, il n'y a pas de partition, 538 00:23:13,710 --> 00:23:16,370 tout est conforme et disponible. 539 00:23:16,370 --> 00:23:19,990 Vous vous inquiétez seulement PAC quand nous avons cette partition. 540 00:23:19,990 --> 00:23:21,260 Donc, ce sont rares. 541 00:23:21,260 --> 00:23:25,360 Mais comment le système réagit lorsque ceux- se produisent dicter ce type de système 542 00:23:25,360 --> 00:23:26,750 nous traitons. 543 00:23:26,750 --> 00:23:31,110 >> Donc, nous allons jeter un oeil à ce que qui ressemble à des systèmes d'AP. 544 00:23:31,110 --> 00:23:32,621 D'accord? 545 00:23:32,621 --> 00:23:34,830 AP Systems viennent dans deux saveurs. 546 00:23:34,830 --> 00:23:38,514 Ils viennent dans la saveur qui est un master master, 100%, toujours disponible. 547 00:23:38,514 --> 00:23:40,430 Et ils viennent dans le autre saveur, qui dit, 548 00:23:40,430 --> 00:23:43,330 vous savez quoi, je vais vous inquiétez à propos de cette chose de partitionnement 549 00:23:43,330 --> 00:23:44,724 lorsque se produit une partition réelle. 550 00:23:44,724 --> 00:23:47,890 Sinon, il va y être primaire nœuds qui va prendre les droits. 551 00:23:47,890 --> 00:23:48,500 D'accord? 552 00:23:48,500 --> 00:23:50,040 >> Donc, si nous quelque chose comme Cassandra. 553 00:23:50,040 --> 00:23:54,440 Cassandra serait un maître maître, me laisse écrire à toute noeud. 554 00:23:54,440 --> 00:23:55,540 Donc ce qui arrive? 555 00:23:55,540 --> 00:23:58,270 Je dois donc un objet dans le base de données qui existe sur deux noeuds. 556 00:23:58,270 --> 00:24:01,705 Appelons cet objet S. Nous avons donc l'Etat pour S. 557 00:24:01,705 --> 00:24:04,312 Nous avons quelques opérations sur S qui sont en cours. 558 00:24:04,312 --> 00:24:06,270 Cassandra me permets écrire à plusieurs nœuds. 559 00:24:06,270 --> 00:24:08,550 Alors disons que je reçois un écrire pour s à deux noeuds. 560 00:24:08,550 --> 00:24:12,274 Eh bien, ce qui finit par se produire est nous appelons ce qu 'un événement de partitionnement. 561 00:24:12,274 --> 00:24:14,190 Il ne peut pas être un partition de réseau physique. 562 00:24:14,190 --> 00:24:15,950 Mais en raison de la conception du système, il est 563 00:24:15,950 --> 00:24:18,449 effectivement partitionnement dès que je reçois une écriture sur deux noeuds. 564 00:24:18,449 --> 00:24:20,830 Il me forçant à ne pas écrire tout au long d'un nœud. 565 00:24:20,830 --> 00:24:22,340 Je vous écris sur deux nœuds. 566 00:24:22,340 --> 00:24:23,330 D'accord? 567 00:24:23,330 --> 00:24:25,740 >> Alors maintenant, je dois deux états. 568 00:24:25,740 --> 00:24:26,360 D'accord? 569 00:24:26,360 --> 00:24:28,110 Ce qu'il va se passer est tôt ou tard, 570 00:24:28,110 --> 00:24:29,960 il va y avoir un événement de réplication. 571 00:24:29,960 --> 00:24:33,300 Il va y avoir ce que nous appelé récupération de partition, qui 572 00:24:33,300 --> 00:24:35,200 est où ces deux États revenir ensemble 573 00:24:35,200 --> 00:24:37,310 et il va y avoir un algorithme qui fonctionne à l'intérieur de la base de données, 574 00:24:37,310 --> 00:24:38,540 décide quoi faire. 575 00:24:38,540 --> 00:24:39,110 D'accord? 576 00:24:39,110 --> 00:24:43,057 Par défaut, dernière mise à jour gagne dans la plupart des systèmes d'AP. 577 00:24:43,057 --> 00:24:44,890 Donc, il ya habituellement une algorithme par défaut, ce qui 578 00:24:44,890 --> 00:24:47,400 qu'ils appellent un rappel fonction, quelque chose qui 579 00:24:47,400 --> 00:24:51,000 sera appelé lorsque cette condition est détecté pour exécuter une certaine logique 580 00:24:51,000 --> 00:24:52,900 pour résoudre ce conflit. 581 00:24:52,900 --> 00:24:53,850 D'accord? 582 00:24:53,850 --> 00:24:58,770 Le rappel et par défaut par défaut dans la plupart des bases de données résolveur AP 583 00:24:58,770 --> 00:25:01,130 est, devinez quoi, timestamp gagne. 584 00:25:01,130 --> 00:25:02,380 Ce fut la dernière mise à jour. 585 00:25:02,380 --> 00:25:04,320 Je vais mettre ce jour là. 586 00:25:04,320 --> 00:25:08,440 Je peux vider ce record que je déversés au large dans un journal de reprise 587 00:25:08,440 --> 00:25:11,670 de sorte que l'utilisateur peut revenir plus tard et dire, bon, il y avait une collision. 588 00:25:11,670 --> 00:25:12,320 Qu'est ce qui s'est passé? 589 00:25:12,320 --> 00:25:16,370 Et vous pouvez réellement vider un record de toutes les collisions et les reculs 590 00:25:16,370 --> 00:25:17,550 et de voir ce qui se passe. 591 00:25:17,550 --> 00:25:21,580 >> Maintenant, en tant qu'utilisateur, vous pouvez aussi inclure une logique qui en rappel. 592 00:25:21,580 --> 00:25:24,290 Ainsi, vous pouvez changer cela opération rappel. 593 00:25:24,290 --> 00:25:26,730 Vous pouvez dire, hey, je veux pour remédier à ces données. 594 00:25:26,730 --> 00:25:28,880 Et je veux essayer de fusionner ces deux dossiers. 595 00:25:28,880 --> 00:25:30,050 Mais cela est à vous. 596 00:25:30,050 --> 00:25:32,880 La base de données ne sait pas comment faire que par défaut. La plupart du temps, 597 00:25:32,880 --> 00:25:34,850 la seule chose que la base de données sait faire est de dire, 598 00:25:34,850 --> 00:25:36,100 celui-ci était le dernier enregistrement. 599 00:25:36,100 --> 00:25:39,183 Voilà celui qui va gagner, et que la valeur est, je vais mettre. 600 00:25:39,183 --> 00:25:41,490 Une fois que la récupération de partition et la réplication se produit, 601 00:25:41,490 --> 00:25:43,930 nous avons notre Etat, qui est maintenant le premier, qui est 602 00:25:43,930 --> 00:25:46,890 l'état de fusion de tous ces objets. 603 00:25:46,890 --> 00:25:49,700 Donc systèmes AP ont cette. 604 00:25:49,700 --> 00:25:51,615 Systèmes de CP ne doivent à vous en soucier. 605 00:25:51,615 --> 00:25:54,490 Parce que dès que vient une partition en jeu, ils arrêtent tout simplement prendre 606 00:25:54,490 --> 00:25:55,530 écrit. 607 00:25:55,530 --> 00:25:56,180 D'accord? 608 00:25:56,180 --> 00:25:58,670 Donc, ce qui est très facile à traiter étant compatible 609 00:25:58,670 --> 00:26:01,330 quand vous ne l'acceptez pas de mises à jour. 610 00:26:01,330 --> 00:26:04,620 Voilà avec les systèmes de CP font. 611 00:26:04,620 --> 00:26:05,120 D'accord. 612 00:26:05,120 --> 00:26:07,590 >> Parlons donc un peu peu de modèles d'accès. 613 00:26:07,590 --> 00:26:11,580 Lorsque nous parlons de NoSQL, il est tout sur le modèle d'accès. 614 00:26:11,580 --> 00:26:13,550 Maintenant, SQL est ad hoc, les requêtes. 615 00:26:13,550 --> 00:26:14,481 Il est relationnelle magasin. 616 00:26:14,481 --> 00:26:16,480 Nous ne devons pas nous inquiéter sur le modèle de l'accès. 617 00:26:16,480 --> 00:26:17,688 Je vous écris une requête très complexe. 618 00:26:17,688 --> 00:26:19,250 Il va chercher les données. 619 00:26:19,250 --> 00:26:21,210 Voilà ce que cela ressemble comme, la normalisation. 620 00:26:21,210 --> 00:26:24,890 >> Donc, dans cette structure particulière, nous cherchons à un catalogue de produits. 621 00:26:24,890 --> 00:26:26,640 Je dois différents types de produits. 622 00:26:26,640 --> 00:26:27,217 Je dois livres. 623 00:26:27,217 --> 00:26:27,800 Je dois albums. 624 00:26:27,800 --> 00:26:30,090 Je dois vidéos. 625 00:26:30,090 --> 00:26:33,370 La relation entre les produits et l'un quelconque de ces livres, albums, 626 00:26:33,370 --> 00:26:34,860 et vidéos tables est de 1: 1. 627 00:26:34,860 --> 00:26:35,800 D'accord? 628 00:26:35,800 --> 00:26:38,860 Je dois un ID de produit, et qui correspond d'identité 629 00:26:38,860 --> 00:26:41,080 un livre, un album ou une vidéo. 630 00:26:41,080 --> 00:26:41,580 D'accord? 631 00:26:41,580 --> 00:26:44,350 Voilà une relation 1: 1 à travers ces tableaux. 632 00:26:44,350 --> 00:26:46,970 >> Maintenant, tout ce qu'ils books-- avoir des propriétés est de racine. 633 00:26:46,970 --> 00:26:47,550 Pas de problème. 634 00:26:47,550 --> 00:26:48,230 C'est génial. 635 00:26:48,230 --> 00:26:52,130 One-to-one relation, je reçois tout les données que je besoin de décrire ce livre. 636 00:26:52,130 --> 00:26:54,770 Album Albums-- ont pistes. 637 00:26:54,770 --> 00:26:56,470 Ceci est ce que nous appelons un à plusieurs. 638 00:26:56,470 --> 00:26:58,905 Chaque album pourrait avoir de nombreuses pistes. 639 00:26:58,905 --> 00:27:00,780 Ainsi, pour chaque piste sur l'album, je pourrait avoir 640 00:27:00,780 --> 00:27:02,570 un autre record dans cette table enfant. 641 00:27:02,570 --> 00:27:04,680 Je crée donc un enregistrement dans ma table d'albums. 642 00:27:04,680 --> 00:27:06,700 Je crée plusieurs enregistrements dans le tableau des titres. 643 00:27:06,700 --> 00:27:08,850 Un-à-plusieurs. 644 00:27:08,850 --> 00:27:11,220 >> Cette relation est ce que nous appelons many-to-many. 645 00:27:11,220 --> 00:27:11,750 D'accord? 646 00:27:11,750 --> 00:27:17,000 Vous voyez que les acteurs pourraient être dans de nombreux films, de nombreuses vidéos. 647 00:27:17,000 --> 00:27:21,450 Donc, ce que nous faisons est que nous mettons cette cartographie table entre ceux-ci, dont il vient 648 00:27:21,450 --> 00:27:24,040 cartes de l'ID de l'acteur à l'ID de la vidéo. 649 00:27:24,040 --> 00:27:28,464 Maintenant, je peux créer une requête les jointures vidéos à travers acteur vidéo sur les acteurs, 650 00:27:28,464 --> 00:27:31,130 et il me donne une belle liste de tous les films et tous les acteurs 651 00:27:31,130 --> 00:27:32,420 qui étaient dans ce film. 652 00:27:32,420 --> 00:27:33,290 >> D'ACCORD. 653 00:27:33,290 --> 00:27:33,880 Alors on y va. 654 00:27:33,880 --> 00:27:38,040 One-to-one est le plus haut niveau relation; un-à-plusieurs, 655 00:27:38,040 --> 00:27:40,240 Album à des pistes; plusieurs à plusieurs. 656 00:27:40,240 --> 00:27:44,990 Ce sont le plus haut niveau de trois- relations dans une base de données. 657 00:27:44,990 --> 00:27:48,050 Si vous savez comment ceux relations travaillent ensemble, 658 00:27:48,050 --> 00:27:51,490 alors vous savez beaucoup de choses à propos de la base de données déjà. 659 00:27:51,490 --> 00:27:55,660 Donc NoSQL fonctionne un peu différemment. 660 00:27:55,660 --> 00:27:58,930 Pensons à une seconde ce qu'il On dirait d'aller chercher tous mes produits. 661 00:27:58,930 --> 00:28:01,096 >> Dans un magasin relationnelle, je vouloir obtenir tous mes produits 662 00:28:01,096 --> 00:28:02,970 sur une liste de tous mes produits. 663 00:28:02,970 --> 00:28:04,910 Cela fait beaucoup de questions. 664 00:28:04,910 --> 00:28:07,030 Je suis une requête pour tous mes livres. 665 00:28:07,030 --> 00:28:08,470 Je suis une requête de mes albums. 666 00:28:08,470 --> 00:28:09,970 Et je suis une requête pour toutes mes vidéos. 667 00:28:09,970 --> 00:28:11,719 Et je suis arrivé à mettre tous ensemble dans une liste 668 00:28:11,719 --> 00:28:15,250 et servez-le remonter à la demande qui a fait la demande. 669 00:28:15,250 --> 00:28:18,000 >> Pour obtenir mes livres, je me joins Produits et livres. 670 00:28:18,000 --> 00:28:21,680 Pour obtenir mes albums, je suis arrivé à rejoindre Produits, Albums, et les pistes. 671 00:28:21,680 --> 00:28:25,330 Et pour obtenir mes vidéos, je dois à se joindre à Products Vidéos, 672 00:28:25,330 --> 00:28:28,890 rejoindre travers Acteur Vidéos, et apporter les acteurs. 673 00:28:28,890 --> 00:28:31,020 Voilà donc trois requêtes. 674 00:28:31,020 --> 00:28:34,560 Requêtes très complexes assembler un jeu de résultats. 675 00:28:34,560 --> 00:28:36,540 >> Voilà moins de optimale. 676 00:28:36,540 --> 00:28:39,200 Voilà pourquoi, lorsque nous parlons sur une structure de données qui est 677 00:28:39,200 --> 00:28:42,900 construit pour être agnostique à l'accès pattern-- bien que ce grand. 678 00:28:42,900 --> 00:28:45,730 Et vous pouvez voir ce qui est vraiment belle la façon dont nous avons organisé les données. 679 00:28:45,730 --> 00:28:46,550 Et vous savez quoi? 680 00:28:46,550 --> 00:28:49,750 Je dois seulement un record pour un acteur. 681 00:28:49,750 --> 00:28:50,440 >> C'est super. 682 00:28:50,440 --> 00:28:53,750 Je l'ai dédupliquées tous mes acteurs, et je maintenais mes associations 683 00:28:53,750 --> 00:28:55,200 dans ce tableau de la cartographie. 684 00:28:55,200 --> 00:29:00,620 Cependant, l'obtention des données devient hors coûteux. 685 00:29:00,620 --> 00:29:04,500 Je l'envoi de la CPU dans le système rejoindre ces structures de données ensemble 686 00:29:04,500 --> 00:29:05,950 pour être en mesure de tirer que les données en arrière. 687 00:29:05,950 --> 00:29:07,310 >> Alors, comment puis-je obtenir à ce sujet? 688 00:29:07,310 --> 00:29:11,200 Dans NoSQL il est à propos de agrégation, non normalisation. 689 00:29:11,200 --> 00:29:13,534 Donc, nous voulons dire que nous voulons soutenir le modèle d'accès. 690 00:29:13,534 --> 00:29:15,283 Si le motif d'accès les applications, 691 00:29:15,283 --> 00:29:16,770 Je dois obtenir tous mes produits. 692 00:29:16,770 --> 00:29:19,027 Mettons tous les produits dans un tableau. 693 00:29:19,027 --> 00:29:22,110 Si je mets tous les produits dans un tableau, Je peux vous suffit de sélectionner tous les produits 694 00:29:22,110 --> 00:29:23,850 à partir de cette table et je comprends tout. 695 00:29:23,850 --> 00:29:25,240 Eh bien, comment puis-je faire cela? 696 00:29:25,240 --> 00:29:28,124 Eh bien dans NoSQL il n'y a pas la structure de la table. 697 00:29:28,124 --> 00:29:30,540 Nous parlerons un peu comment cela fonctionne dans Dynamo DB. 698 00:29:30,540 --> 00:29:33,570 Mais vous ne devez pas la même les attributs et les mêmes propriétés 699 00:29:33,570 --> 00:29:37,751 dans chaque rangée, dans chaque simple article, comme vous le faites dans une table SQL. 700 00:29:37,751 --> 00:29:39,750 Et ce que cela me permets à faire est beaucoup de choses 701 00:29:39,750 --> 00:29:41,124 et me donner beaucoup de flexibilité. 702 00:29:41,124 --> 00:29:45,360 Dans ce cas particulier, je avoir mes documents produits. 703 00:29:45,360 --> 00:29:49,090 Et dans ce cas particulier Ainsi, tout 704 00:29:49,090 --> 00:29:51,930 est un document dans le tableau des produits. 705 00:29:51,930 --> 00:29:56,510 Et le produit pour un livre pourrait avoir un ID de type qui spécifie un livre. 706 00:29:56,510 --> 00:29:59,180 Et l'application passeraient sur cette ID. 707 00:29:59,180 --> 00:30:02,570 >> Au niveau de l'application, je vais à-dire oh, ce type d'enregistrement est-ce? 708 00:30:02,570 --> 00:30:04,100 Oh, il est un record de livre. 709 00:30:04,100 --> 00:30:05,990 Réservez dossiers ont ces propriétés. 710 00:30:05,990 --> 00:30:08,100 Permettez-moi de créer un objet livre. 711 00:30:08,100 --> 00:30:11,289 Donc, je vais remplir le livre objet avec cet article. 712 00:30:11,289 --> 00:30:13,080 Article suivant vient et dit, quel est cet objet? 713 00:30:13,080 --> 00:30:14,560 Cet article est un album. 714 00:30:14,560 --> 00:30:17,340 Oh, je suis toute une différente routine de traitement pour que, 715 00:30:17,340 --> 00:30:18,487 car il est un album. 716 00:30:18,487 --> 00:30:19,320 Vous voyez ce que je veux dire? 717 00:30:19,320 --> 00:30:21,950 >> Donc, l'application tier-- I il suffit de sélectionner tous ces dossiers. 718 00:30:21,950 --> 00:30:23,200 Ils commencent tous à venir dans. 719 00:30:23,200 --> 00:30:24,680 Ils pourraient être tous les différents types. 720 00:30:24,680 --> 00:30:27,590 Et il est la logique de l'application qui commute à travers ces types 721 00:30:27,590 --> 00:30:29,530 et décide comment les traiter. 722 00:30:29,530 --> 00:30:33,640 >> Encore une fois, nous sommes donc l'optimisation de la le schéma de combinaison d'accès. 723 00:30:33,640 --> 00:30:36,390 Nous le faisons par effondrer ces tables. 724 00:30:36,390 --> 00:30:39,670 Nous sommes fondamentalement en prenant ces structures normalisées, 725 00:30:39,670 --> 00:30:42,000 et nous construisons structures hiérarchiques. 726 00:30:42,000 --> 00:30:45,130 A l'intérieur de chacun de ces enregistrements Je vais voir les propriétés de tableau. 727 00:30:45,130 --> 00:30:49,400 >> A l'intérieur de ce document pour les albums, Je vois réseaux de pistes. 728 00:30:49,400 --> 00:30:53,900 Ces pistes become-- maintenant il est essentiellement cette table enfant 729 00:30:53,900 --> 00:30:56,520 existe ici, dans cette structure. 730 00:30:56,520 --> 00:30:57,975 Donc, vous pouvez le faire dans DynamoDB. 731 00:30:57,975 --> 00:30:59,810 Vous pouvez le faire dans MongoDB. 732 00:30:59,810 --> 00:31:01,437 Vous pouvez le faire dans une base de données NoSQL. 733 00:31:01,437 --> 00:31:03,520 Créer ces types de structures de données hiérarchiques 734 00:31:03,520 --> 00:31:07,120 qui vous permettent de récupérer des données très rapidement parce que maintenant je 735 00:31:07,120 --> 00:31:08,537 ne pas avoir à se conformer. 736 00:31:08,537 --> 00:31:11,620 Quand je insérer une ligne dans les chansons table, ou une ligne dans le tableau des albums, 737 00:31:11,620 --> 00:31:13,110 Je dois à se conformer à ce schéma. 738 00:31:13,110 --> 00:31:18,060 Je dois avoir l'attribut ou la propriété qui est défini sur cette table. 739 00:31:18,060 --> 00:31:20,480 Chacun d'entre eux, lorsque je insère cette ligne. 740 00:31:20,480 --> 00:31:21,910 Cela ne veut pas le cas dans NoSQL. 741 00:31:21,910 --> 00:31:24,440 >> Je peux avoir totalement différent propriétés dans chaque document 742 00:31:24,440 --> 00:31:26,100 que je l'insère dans la collection. 743 00:31:26,100 --> 00:31:30,480 Donc mécanisme très puissant. 744 00:31:30,480 --> 00:31:32,852 Et il est vraiment comment vous optimiser le système. 745 00:31:32,852 --> 00:31:35,310 Parce que maintenant cette requête, la place de se joindre à tous ces tableaux 746 00:31:35,310 --> 00:31:39,160 et l'exécution d'une demi-douzaine de requêtes à retirer les données que je dois, 747 00:31:39,160 --> 00:31:40,890 Je exécution d'une requête. 748 00:31:40,890 --> 00:31:43,010 Et je itération à travers les résultats fixés. 749 00:31:43,010 --> 00:31:46,512 il vous donne une idée de la puissance de NoSQL. 750 00:31:46,512 --> 00:31:49,470 Je vais type de déraper ici et parler un peu à ce sujet. 751 00:31:49,470 --> 00:31:53,240 Ceci est plus du genre commercialisation ou technology-- 752 00:31:53,240 --> 00:31:55,660 la commercialisation de la technologie type de discussion. 753 00:31:55,660 --> 00:31:58,672 Mais il est important de comprendre parce que si nous regardons en haut 754 00:31:58,672 --> 00:32:00,380 ici, à ce tableau, ce que nous cherchons à 755 00:32:00,380 --> 00:32:04,030 est ce que nous appelons le la technologie courbe de battage. 756 00:32:04,030 --> 00:32:06,121 Et ce que cela signifie est slideshows nouveaux entre en jeu. 757 00:32:06,121 --> 00:32:07,120 Les gens pensent qu'il est génial. 758 00:32:07,120 --> 00:32:09,200 Je l'ai résolu tous mes problèmes. 759 00:32:09,200 --> 00:32:11,630 >> Cela pourrait être la fin tout, être tout à tout. 760 00:32:11,630 --> 00:32:12,790 Et ils commencent à l'utiliser. 761 00:32:12,790 --> 00:32:14,720 Et ils disent, ça ne fonctionne pas. 762 00:32:14,720 --> 00:32:17,600 Ce n'est pas juste. 763 00:32:17,600 --> 00:32:19,105 Le vieux truc était mieux. 764 00:32:19,105 --> 00:32:21,230 Et ils retournent à faire les choses comme elles étaient. 765 00:32:21,230 --> 00:32:22,730 Et puis finalement ils vont, vous savez quoi? 766 00:32:22,730 --> 00:32:24,040 Ce truc est pas si mal. 767 00:32:24,040 --> 00:32:26,192 Oh, ce Voilà comment cela fonctionne. 768 00:32:26,192 --> 00:32:28,900 Et une fois qu'ils comprendre comment il œuvres, ils commencent à aller mieux. 769 00:32:28,900 --> 00:32:32,050 >> Et le plus drôle à ce sujet est, il sorte de lignes jusqu'à ce que 770 00:32:32,050 --> 00:32:34,300 nous appelons la courbe d'adoption de la technologie. 771 00:32:34,300 --> 00:32:36,910 Donc ce qui arrive est que nous avons certains déclenchement de la technologie de tri. 772 00:32:36,910 --> 00:32:39,100 Dans le cas de bases de données, il est la pression de données. 773 00:32:39,100 --> 00:32:42,200 Nous avons parlé des points d'eau élevés de la pression de données à travers le temps. 774 00:32:42,200 --> 00:32:46,310 Lorsque que la pression de données atteint un certain le point, qui est un élément déclencheur de la technologie. 775 00:32:46,310 --> 00:32:47,830 >> Ça devient trop cher. 776 00:32:47,830 --> 00:32:49,790 Il prend trop de temps pour traiter les données. 777 00:32:49,790 --> 00:32:50,890 Nous avons besoin de quelque chose de mieux. 778 00:32:50,890 --> 00:32:52,890 Vous obtenez les innovateurs là-bas courir, 779 00:32:52,890 --> 00:32:55,050 essayer de savoir quelle est la solution. 780 00:32:55,050 --> 00:32:56,050 Quelle est la nouvelle idée? 781 00:32:56,050 --> 00:32:58,170 >> Quelle est la meilleure façon de faire cette chose? 782 00:32:58,170 --> 00:32:59,530 Et ils viennent avec quelque chose. 783 00:32:59,530 --> 00:33:03,140 Et les personnes atteintes de la vraie douleur, les gars à la fine pointe, 784 00:33:03,140 --> 00:33:06,390 ils vont sauter sur elle, parce qu'ils ont besoin d'une réponse. 785 00:33:06,390 --> 00:33:09,690 Maintenant, ce qui inévitablement et happens-- ça se passe en ce moment dans NoSQL. 786 00:33:09,690 --> 00:33:11,090 Je le vois tout le temps. 787 00:33:11,090 --> 00:33:13,610 >> Ce qui se passe est inévitablement les gens commencent à l'aide du nouvel outil 788 00:33:13,610 --> 00:33:15,490 de la même manière ils ont utilisé l'ancien outil. 789 00:33:15,490 --> 00:33:17,854 Et ils découvrent qu'il ne fonctionne pas si bien. 790 00:33:17,854 --> 00:33:20,020 Je ne me souviens pas qui je suis parler plus tôt aujourd'hui. 791 00:33:20,020 --> 00:33:22,080 Mais il est comme, lorsque le marteau-piqueur a été inventé, 792 00:33:22,080 --> 00:33:24,621 les gens ne se balancer au-dessus leur tête pour casser le béton. 793 00:33:24,621 --> 00:33:27,360 794 00:33:27,360 --> 00:33:30,610 >> Mais qui est ce qui est passe avec NoSQL aujourd'hui. 795 00:33:30,610 --> 00:33:33,900 Si vous marchez dans la plupart des magasins, ils essaient d'être boutiques NoSQL. 796 00:33:33,900 --> 00:33:36,510 Ce qu'ils font est ils utilisent NoSQL, 797 00:33:36,510 --> 00:33:39,900 et ils le charger pleine de schéma relationnel. 798 00:33:39,900 --> 00:33:41,630 Parce que voilà comment ils conçoivent des bases de données. 799 00:33:41,630 --> 00:33:44,046 Et ils se demandent, pourquoi est- il pas de très bons résultats? 800 00:33:44,046 --> 00:33:45,230 Boy, cette chose pue. 801 00:33:45,230 --> 00:33:49,900 Je devais maintenir toute ma rejoint in-- il est comme, non, non. 802 00:33:49,900 --> 00:33:50,800 Maintenir rejoint? 803 00:33:50,800 --> 00:33:52,430 Pourquoi êtes-vous joignez données? 804 00:33:52,430 --> 00:33:54,350 Vous ne participez pas à des données dans NoSQL. 805 00:33:54,350 --> 00:33:55,850 Vous les agréger. 806 00:33:55,850 --> 00:34:00,690 >> Donc, si vous voulez éviter cela, apprendre fonctionnement de l'outil avant de vous 807 00:34:00,690 --> 00:34:02,010 commencer à l'utiliser. 808 00:34:02,010 --> 00:34:04,860 Ne pas essayer d'utiliser les nouveaux outils de la même manière que vous avez utilisé les outils anciens. 809 00:34:04,860 --> 00:34:06,500 Vous allez avoir une mauvaise expérience. 810 00:34:06,500 --> 00:34:08,848 Et à chaque fois voilà ce qu'il en est. 811 00:34:08,848 --> 00:34:11,389 Lorsque nous commençons à venir ici, il est parce que les gens ont compris 812 00:34:11,389 --> 00:34:13,449 comment utiliser les outils. 813 00:34:13,449 --> 00:34:16,250 >> Ils ont fait la même chose quand bases de données relationnelles ont été inventés, 814 00:34:16,250 --> 00:34:17,969 et ils remplaçaient les systèmes de fichiers. 815 00:34:17,969 --> 00:34:20,420 Ils ont essayé de construire des systèmes de fichiers bases de données relationnelles 816 00:34:20,420 --> 00:34:22,159 parce que ce que les gens ont compris. 817 00:34:22,159 --> 00:34:23,049 Cela n'a pas fonctionné. 818 00:34:23,049 --> 00:34:26,090 Donc, comprendre les meilleures pratiques de la technologie vous travaillez avec 819 00:34:26,090 --> 00:34:26,730 est énorme. 820 00:34:26,730 --> 00:34:29,870 Très important. 821 00:34:29,870 --> 00:34:32,440 >> Donc, nous allons entrer dans DynamoDB. 822 00:34:32,440 --> 00:34:36,480 DynamoDB est SAPN entièrement géré plateforme NoSQL. 823 00:34:36,480 --> 00:34:37,719 Ce qui ne signifie entièrement géré? 824 00:34:37,719 --> 00:34:40,010 Cela signifie que vous ne devez pas soucier vraiment de quoi que ce soit. 825 00:34:40,010 --> 00:34:42,060 >> Vous venez, vous dites nous, je besoin d'une table. 826 00:34:42,060 --> 00:34:43,409 Il a besoin de cette grande capacité. 827 00:34:43,409 --> 00:34:47,300 Vous appuyez sur le bouton, et la fourniture de nous toute l'infrastructure derrière la scène. 828 00:34:47,300 --> 00:34:48,310 Maintenant que est énorme. 829 00:34:48,310 --> 00:34:51,310 >> Parce que quand vous parlez sur l'extension de la base de données, 830 00:34:51,310 --> 00:34:53,917 NoSQL clusters de données à échelle, pétaoctets fonctionnement, 831 00:34:53,917 --> 00:34:55,750 exécutant des millions de transactions par seconde, 832 00:34:55,750 --> 00:34:58,180 ces choses ne sont pas de petites grappes. 833 00:34:58,180 --> 00:35:00,830 Nous parlons des milliers de cas. 834 00:35:00,830 --> 00:35:04,480 Gestion des milliers de cas, même des instances virtuelles, 835 00:35:04,480 --> 00:35:06,350 est une vraie douleur dans le cul. 836 00:35:06,350 --> 00:35:09,110 Je veux dire, pense à tous un temps exploitation correctif du système sort 837 00:35:09,110 --> 00:35:11,552 ou une nouvelle version de la base de données. 838 00:35:11,552 --> 00:35:13,260 Qu'est-ce que ça veut dire vous opérationnel? 839 00:35:13,260 --> 00:35:16,330 Cela signifie que vous avez 1200 serveurs qui ont besoin d'être mis à jour. 840 00:35:16,330 --> 00:35:18,960 Maintenant, même avec l'automatisation, qui peut prendre un certain temps. 841 00:35:18,960 --> 00:35:21,480 Cela peut causer beaucoup de maux de tête opérationnelles, 842 00:35:21,480 --> 00:35:23,090 parce que je pourrais avoir des services vers le bas. 843 00:35:23,090 --> 00:35:26,070 >> Comme je mettre à jour ces bases de données, je pourrait faire déploiements vert bleu 844 00:35:26,070 --> 00:35:29,420 où je déployer et mettre à niveau la moitié de ma nœuds, et ensuite mettre à niveau l'autre moitié. 845 00:35:29,420 --> 00:35:30,490 Prenez ceux d'en bas. 846 00:35:30,490 --> 00:35:33,410 Ainsi, la gestion de l'infrastructure l'échelle est extrêmement douloureuse. 847 00:35:33,410 --> 00:35:36,210 Et AWS prendre que la douleur hors de lui. 848 00:35:36,210 --> 00:35:39,210 Et bases de données NoSQL peut être extraordinairement douloureuse 849 00:35:39,210 --> 00:35:41,780 en raison de la façon dont ils l'échelle. 850 00:35:41,780 --> 00:35:42,926 >> L'échelle horizontale. 851 00:35:42,926 --> 00:35:45,550 Si vous voulez obtenir une plus grande NoSQL base de données, vous achetez plusieurs noeuds. 852 00:35:45,550 --> 00:35:48,660 Chaque nœud que vous achetez est un autre casse-tête opérationnel. 853 00:35:48,660 --> 00:35:50,830 Donc laisser quelqu'un d'autre le faire pour vous. 854 00:35:50,830 --> 00:35:52,000 AWS peut le faire. 855 00:35:52,000 --> 00:35:54,587 >> Nous soutenons les valeurs de documents clés. 856 00:35:54,587 --> 00:35:56,670 Maintenant, nous ne sommes pas allés trop dans l'autre tableau. 857 00:35:56,670 --> 00:35:58,750 Il ya beaucoup de différents saveurs de NoSQL. 858 00:35:58,750 --> 00:36:02,670 Ils sont tous les types d'obtenir munged ensemble à ce point. 859 00:36:02,670 --> 00:36:06,260 Vous pouvez regarder DynamoDB et dire oui, nous sommes à la fois un document et une valeur de clé 860 00:36:06,260 --> 00:36:08,412 stocker ce point. 861 00:36:08,412 --> 00:36:10,620 Et vous pouvez faire valoir les caractéristiques de une sur l'autre. 862 00:36:10,620 --> 00:36:13,950 Pour moi, beaucoup de ce qui est vraiment six d'une demi-douzaine de l'autre. 863 00:36:13,950 --> 00:36:18,710 Chacune de ces technologies est un technologie fine et une solution bien. 864 00:36:18,710 --> 00:36:23,390 Je ne dirais pas MongoDB est meilleur ou pire que Couch, puis Cassandra, 865 00:36:23,390 --> 00:36:25,994 puis Dynamo, ou vice versa. 866 00:36:25,994 --> 00:36:27,285 Je veux dire, ce ne sont que des options. 867 00:36:27,285 --> 00:36:29,850 868 00:36:29,850 --> 00:36:32,700 >> Il est rapide et il est conforme à toutes les échelles. 869 00:36:32,700 --> 00:36:36,210 Donc, ceci est un des plus grands bonus que vous obtenez avec AWS. 870 00:36:36,210 --> 00:36:40,850 Avec DynamoDB est la capacité pour obtenir un faible chiffre unique 871 00:36:40,850 --> 00:36:44,040 milliseconde de latence à toute échelle. 872 00:36:44,040 --> 00:36:45,720 Cela a été un objectif de conception du système. 873 00:36:45,720 --> 00:36:49,130 Et nous avons des clients qui font des millions de transactions par seconde. 874 00:36:49,130 --> 00:36:52,670 >> Maintenant, je vais passer en revue certains de ceux des cas d'utilisation en quelques minutes ici. 875 00:36:52,670 --> 00:36:55,660 Control-- d'accès intégré nous avons ce que nous appelons 876 00:36:55,660 --> 00:36:57,920 Identity Access Management, ou IAM. 877 00:36:57,920 --> 00:37:01,980 Il imprègne chaque système, chaque service AWS propose. 878 00:37:01,980 --> 00:37:03,630 DynamoDB ne fait pas exception. 879 00:37:03,630 --> 00:37:06,020 Vous pouvez contrôler l'accès pour les tables de DynamoDB. 880 00:37:06,020 --> 00:37:09,960 Sur tous vos comptes par AWS la définition des rôles et des autorisations d'accès 881 00:37:09,960 --> 00:37:12,140 dans l'infrastructure IAM. 882 00:37:12,140 --> 00:37:16,630 >> Et il est un élément clé et solidaire en ce que nous appelons l'événement de programmation Driven. 883 00:37:16,630 --> 00:37:19,056 Maintenant, ceci est un nouveau paradigme. 884 00:37:19,056 --> 00:37:22,080 >> Public: Comment est votre taux de vrai positifs par rapport aux faux négatifs 885 00:37:22,080 --> 00:37:24,052 sur votre système de contrôle d'accès? 886 00:37:24,052 --> 00:37:26,260 RICK HOULIHAN: vrais positifs par rapport à des faux négatifs? 887 00:37:26,260 --> 00:37:28,785 PUBLIC: ce retour vous devriez être retournez? 888 00:37:28,785 --> 00:37:33,720 Par opposition à de temps en temps il ne retourne pas quand il devrait valider? 889 00:37:33,720 --> 00:37:36,260 890 00:37:36,260 --> 00:37:38,050 >> RICK HOULIHAN: Je ne saurais vous le dire. 891 00:37:38,050 --> 00:37:40,140 Si il ya des échecs que ce soit à ce sujet, 892 00:37:40,140 --> 00:37:42,726 Je ne suis pas la personne à poser cette question particulière. 893 00:37:42,726 --> 00:37:43,850 Mais cela est une bonne question. 894 00:37:43,850 --> 00:37:45,905 Je serais curieux de savoir moi-même, en fait. 895 00:37:45,905 --> 00:37:48,810 896 00:37:48,810 --> 00:37:51,320 >> Et là encore, nouveau paradigme est programmation événementielle. 897 00:37:51,320 --> 00:37:55,160 Telle est l'idée que vous pouvez déployer des applications complexes 898 00:37:55,160 --> 00:37:59,720 peut fonctionner une très haute échelle très, sans infrastructure que ce soit. 899 00:37:59,720 --> 00:38:02,120 Sans aucune fixe infrastructures que ce soit. 900 00:38:02,120 --> 00:38:04,720 Et nous allons parler un peu à propos de ce que cela signifie que nous 901 00:38:04,720 --> 00:38:06,550 passer à la prochaine quelques graphiques. 902 00:38:06,550 --> 00:38:08,716 >> La première chose que nous ferons est que nous allons parler de tables. 903 00:38:08,716 --> 00:38:10,857 Les types de données de l'API pour Dynamo. 904 00:38:10,857 --> 00:38:13,190 Et la première chose que vous aurez remarquerez quand vous regardez ce, 905 00:38:13,190 --> 00:38:17,930 si vous êtes familier avec toute base de données, bases de données ont vraiment deux types d'API 906 00:38:17,930 --> 00:38:18,430 Je l'appellerais. 907 00:38:18,430 --> 00:38:21,570 Ou deux ensembles de API. 908 00:38:21,570 --> 00:38:23,840 Un de ceux serait API d'administration. 909 00:38:23,840 --> 00:38:26,710 >> Les choses qu'ils prennent soin de les fonctions de la base de données. 910 00:38:26,710 --> 00:38:31,340 Configuration du moteur de stockage, la mise en place et l'ajout de tables. 911 00:38:31,340 --> 00:38:35,180 créer la base de données des catalogues et des instances. 912 00:38:35,180 --> 00:38:40,450 Ces things-- dans DynamoDB, vous ont très courts, des listes courtes. 913 00:38:40,450 --> 00:38:43,120 >> Donc, en d'autres bases de données, vous pourriez voir des dizaines 914 00:38:43,120 --> 00:38:45,680 des commandes, des fonctions administratives commandes pour configurer 915 00:38:45,680 --> 00:38:47,290 ces options supplémentaires. 916 00:38:47,290 --> 00:38:51,234 Dans DynamoDB vous ne devez pas ceux parce vous ne configurez pas le système, nous le faisons. 917 00:38:51,234 --> 00:38:54,150 Donc, la seule chose que vous devez faire est de me dire quelle taille dois-je la table. 918 00:38:54,150 --> 00:38:55,660 Ainsi, vous obtenez une très ensemble limité de commandes. 919 00:38:55,660 --> 00:38:58,618 >> Vous obtenez un CREATE TABLE mise à jour, le tableau, Supprimer de table, et de décrire le tableau. 920 00:38:58,618 --> 00:39:01,150 Ce sont les seules choses vous avez besoin pour DynamoDB. 921 00:39:01,150 --> 00:39:03,294 Vous n'êtes pas besoin d'un stockage configuration du moteur. 922 00:39:03,294 --> 00:39:04,960 Je ne veux pas à vous soucier de la réplication. 923 00:39:04,960 --> 00:39:06,490 Je ne veux pas à vous soucier de sharding. 924 00:39:06,490 --> 00:39:07,800 >> Je ne veux pas à vous soucier sur l'un de ces trucs. 925 00:39:07,800 --> 00:39:08,740 Nous faisons tout pour vous. 926 00:39:08,740 --> 00:39:11,867 Voilà donc une énorme quantité de frais généraux qui est juste soulevé de votre assiette. 927 00:39:11,867 --> 00:39:13,200 Ensuite, nous avons les opérateurs CRUD. 928 00:39:13,200 --> 00:39:17,740 CRUD est quelque chose de ce que nous appel à la base de données qui est 929 00:39:17,740 --> 00:39:19,860 Create, Update, Delete opérateurs. 930 00:39:19,860 --> 00:39:24,180 Ce sont votre commune les opérations de base de données. 931 00:39:24,180 --> 00:39:31,299 Des choses comme put l'article, obtenir un objet, la mise à jour articles, supprimer des éléments, requête par lot, numériser. 932 00:39:31,299 --> 00:39:32,840 Si vous souhaitez numériser l'ensemble du tableau. 933 00:39:32,840 --> 00:39:34,220 Tirez tout sur la table. 934 00:39:34,220 --> 00:39:37,130 Une des belles choses sur DynamoDB est qu'il permet balayage parallèle. 935 00:39:37,130 --> 00:39:40,602 Donc vous pouvez réellement me faire savoir combien les discussions que vous voulez exécuter sur cette analyse. 936 00:39:40,602 --> 00:39:41,810 Et nous pouvons lancer ces discussions. 937 00:39:41,810 --> 00:39:43,985 Nous pouvons tourner que de numériser jusqu'à sur plusieurs threads 938 00:39:43,985 --> 00:39:49,060 de sorte que vous pouvez numériser l'ensemble du tableau espace très, très vite dans DynamoDB. 939 00:39:49,060 --> 00:39:51,490 >> L'autre est que nous avons API ce que nous appelons notre API de flux. 940 00:39:51,490 --> 00:39:52,940 On ne va pas parler trop beaucoup de ça maintenant. 941 00:39:52,940 --> 00:39:55,189 Je dois une partie du contenu tard dans le pont à ce sujet. 942 00:39:55,189 --> 00:39:59,910 Mais Streams est vraiment un running-- penser à elle comme le temps ordonné 943 00:39:59,910 --> 00:40:01,274 et le changement de partition journal. 944 00:40:01,274 --> 00:40:03,940 Tout ce qui se passe sur le tableau apparaît sur le flux. 945 00:40:03,940 --> 00:40:05,940 >> Chaque écriture à la table montre sur le flux. 946 00:40:05,940 --> 00:40:08,370 Vous pouvez lire ce flux, et vous pouvez faire des choses avec elle. 947 00:40:08,370 --> 00:40:10,150 Nous allons parler de ce types de choses que vous 948 00:40:10,150 --> 00:40:13,680 faire avec les choses comme la réplication, la création d'index secondaires. 949 00:40:13,680 --> 00:40:17,620 Toutes sortes de vraiment cool choses que vous pouvez faire avec cela. 950 00:40:17,620 --> 00:40:19,150 >> Types de données. 951 00:40:19,150 --> 00:40:23,320 Dans DynamoDB, nous appuyons à la fois clé types de valeur et de documenter les données. 952 00:40:23,320 --> 00:40:26,350 Sur le côté gauche de l'écran ici, nous avons nos types de base. 953 00:40:26,350 --> 00:40:27,230 Principaux types de valeur. 954 00:40:27,230 --> 00:40:30,040 Ce sont des chaînes, numéros, et les fichiers binaires. 955 00:40:30,040 --> 00:40:31,640 >> Donc, seulement trois types de base. 956 00:40:31,640 --> 00:40:33,700 Et puis vous pouvez avoir des ensembles de ceux-ci. 957 00:40:33,700 --> 00:40:37,650 Une des belles choses sur NoSQL est vous pouvez contenir des tableaux que des propriétés. 958 00:40:37,650 --> 00:40:42,050 Et avec DynamoDB vous pouvez contenir des tableaux des types de base comme une propriété de la racine. 959 00:40:42,050 --> 00:40:43,885 >> Et puis il ya les types de documents. 960 00:40:43,885 --> 00:40:45,510 Combien de gens sont familiers avec JSON? 961 00:40:45,510 --> 00:40:47,130 Vous les gars familiers avec JSON autant? 962 00:40:47,130 --> 00:40:49,380 Il est fondamentalement JavaScript, Objet, notation. 963 00:40:49,380 --> 00:40:52,510 Il vous permet essentiellement définir une structure hiérarchique. 964 00:40:52,510 --> 00:40:58,107 >> Vous pouvez enregistrer un document sur JSON DynamoDB utilisant des composants communs 965 00:40:58,107 --> 00:41:00,940 ou blocs de construction qui sont disponibles dans la plupart des langages de programmation. 966 00:41:00,940 --> 00:41:03,602 Donc, si vous avez Java, vous êtes regarder des cartes et des listes. 967 00:41:03,602 --> 00:41:05,060 Je peux créer des objets qui Plan de la zone. 968 00:41:05,060 --> 00:41:08,030 Une carte comme valeurs clés stockées sous forme de propriétés. 969 00:41:08,030 --> 00:41:10,890 Et il pourrait avoir des listes de des valeurs au sein de ces propriétés. 970 00:41:10,890 --> 00:41:13,490 Vous pouvez stocker ce complexe structure hiérarchique 971 00:41:13,490 --> 00:41:16,320 comme un seul attribut d'un élément DynamoDB. 972 00:41:16,320 --> 00:41:19,010 973 00:41:19,010 --> 00:41:24,460 >> Donc tables dans DynamoDB, comme la plupart Bases de données NoSQL, tables ont des articles. 974 00:41:24,460 --> 00:41:26,469 Dans MongoDB vous le feriez appeler ces documents. 975 00:41:26,469 --> 00:41:27,760 Et ce serait la base de canapé. 976 00:41:27,760 --> 00:41:28,900 Aussi une base de données documentaire. 977 00:41:28,900 --> 00:41:29,941 Vous appelez ces documents. 978 00:41:29,941 --> 00:41:32,930 Documents ou objets ont des attributs. 979 00:41:32,930 --> 00:41:35,850 Les attributs peuvent exister ou pas exister sur la question. 980 00:41:35,850 --> 00:41:38,520 Dans DynamoDB, il ya un attribut obligatoire. 981 00:41:38,520 --> 00:41:43,880 Tout comme dans une base de données relationnelle, vous avez une clé primaire sur la table. 982 00:41:43,880 --> 00:41:46,010 >> DynamoDB a ce que nous appelons une clé de hachage. 983 00:41:46,010 --> 00:41:48,280 Touche Dièse doit être unique. 984 00:41:48,280 --> 00:41:52,580 Alors, quand je définis une table de hachage, essentiellement ce que je dis 985 00:41:52,580 --> 00:41:54,110 est chaque article aura une clé de hachage. 986 00:41:54,110 --> 00:41:58,520 Et chaque clé de hachage doit être unique. 987 00:41:58,520 --> 00:42:01,200 >> Chaque élément est défini par cette clé de hachage unique. 988 00:42:01,200 --> 00:42:02,940 Et il ne peut en être un. 989 00:42:02,940 --> 00:42:05,820 Ceci est OK, mais souvent ce que les gens ont besoin 990 00:42:05,820 --> 00:42:08,170 est qu'ils veulent est ce hachage clé pour faire un peu plus 991 00:42:08,170 --> 00:42:11,010 que de simplement être un identifiant unique. 992 00:42:11,010 --> 00:42:15,240 Souvent, nous voulons utiliser cette clé de hachage comme l'agrégation de haut niveau seau. 993 00:42:15,240 --> 00:42:19,160 Et la façon dont nous faisons cela est par ajoutant ce que nous appelons une clé de gamme. 994 00:42:19,160 --> 00:42:22,460 >> Donc, si il est seulement un hachage table, ce doit être unique. 995 00:42:22,460 --> 00:42:27,040 Si il est une table de hachage et de la gamme, la combinaison de la table de hachage et la gamme 996 00:42:27,040 --> 00:42:28,640 doit être unique. 997 00:42:28,640 --> 00:42:30,110 Alors, pensez-y de cette façon. 998 00:42:30,110 --> 00:42:32,140 Si je dois un forum. 999 00:42:32,140 --> 00:42:39,010 Et la forme a sujets, il a postes, et il a les réponses. 1000 00:42:39,010 --> 00:42:42,630 >> Donc, je pourrais avoir un hachage clé, qui est l'ID de rubrique. 1001 00:42:42,630 --> 00:42:46,650 Et je pourrais avoir une clé de gamme, qui est l'ID de réponse. 1002 00:42:46,650 --> 00:42:49,650 De cette façon, si je veux obtenir toutes les réponses pour sujet particulier, 1003 00:42:49,650 --> 00:42:52,370 Je peux juste interroger le hachage. 1004 00:42:52,370 --> 00:42:55,190 Je peux juste dire me donner tout les éléments qui ont ce hachage. 1005 00:42:55,190 --> 00:43:01,910 Et je vais obtenir toutes les questions , ou les poster sur le thème concerné. 1006 00:43:01,910 --> 00:43:03,910 Ces agrégations de haut niveau sont très importants. 1007 00:43:03,910 --> 00:43:07,370 Ils soutiennent l'accès principal motif de la demande. 1008 00:43:07,370 --> 00:43:09,420 D'une manière générale, cette est ce que nous voulons faire. 1009 00:43:09,420 --> 00:43:11,780 Nous voulons que table-- que vous chargez la table, 1010 00:43:11,780 --> 00:43:16,640 nous voulons structurer les données dans la table de telle manière 1011 00:43:16,640 --> 00:43:20,140 que l'application peut très récupérer rapidement les résultats. 1012 00:43:20,140 --> 00:43:24,510 Et souvent la façon de le faire est pour maintenir ces agrégations que nous 1013 00:43:24,510 --> 00:43:25,650 insérer les données. 1014 00:43:25,650 --> 00:43:31,110 Fondamentalement, nous écartons les données dans le seau brillant qu'il entre en jeu. 1015 00:43:31,110 --> 00:43:35,210 >> Touches de Range permettent hachage moi-- clés doivent être l'égalité. 1016 00:43:35,210 --> 00:43:39,490 Lorsque je questionne une table de hachage, je dois dire me donner un hachage qui équivaut à cela. 1017 00:43:39,490 --> 00:43:41,950 Lorsque je questionne une gamme, je peut dire me donne une gamme 1018 00:43:41,950 --> 00:43:47,040 ce qui est d'utiliser tout type de riche opérateur que nous soutenons. 1019 00:43:47,040 --> 00:43:49,200 Donnez-moi tous les éléments pour une table de hachage. 1020 00:43:49,200 --> 00:43:52,520 Est-il égal, supérieur, moins, ça commence avec, 1021 00:43:52,520 --> 00:43:54,145 Existe t-il entre ces deux valeurs? 1022 00:43:54,145 --> 00:43:56,811 Ainsi, ces types de requêtes de gamme que nous sommes toujours intéressés. 1023 00:43:56,811 --> 00:43:59,650 Maintenant, une chose à propos des données, lorsque vous regardez l'accès aux données, lorsque 1024 00:43:59,650 --> 00:44:02,360 vous accédez aux données, il est toujours à une agrégation. 1025 00:44:02,360 --> 00:44:05,770 Il est toujours sur les dossiers qui sont liés à ce produit. 1026 00:44:05,770 --> 00:44:10,390 Donnez-moi tout ici that's-- tous les transactions sur cette carte de crédit 1027 00:44:10,390 --> 00:44:12,500 pour le dernier mois. 1028 00:44:12,500 --> 00:44:13,960 Voilà une agrégation. 1029 00:44:13,960 --> 00:44:17,490 >> Presque tout ce que vous faites dans le base de données est une sorte d'agrégation. 1030 00:44:17,490 --> 00:44:21,530 Donc, être en mesure d'être en mesure de définir Ces godets et vous donner à ces choix 1031 00:44:21,530 --> 00:44:24,950 attributs pour être en mesure d'interroger sur, ces requêtes riches soutiennent beaucoup, 1032 00:44:24,950 --> 00:44:27,165 beaucoup, beaucoup de modèles d'accès de l'application. 1033 00:44:27,165 --> 00:44:30,990 1034 00:44:30,990 --> 00:44:35,000 >> Donc, l'autre chose de la touche dièse fait est qu'il nous donne un mécanisme 1035 00:44:35,000 --> 00:44:37,740 pour être en mesure de diffuser les données autour. 1036 00:44:37,740 --> 00:44:40,390 Bases de données NoSQL fonctionnent le mieux lorsque les données sont uniformément 1037 00:44:40,390 --> 00:44:41,740 distribué à travers le cluster. 1038 00:44:41,740 --> 00:44:44,530 1039 00:44:44,530 --> 00:44:47,050 Combien de gens sont familiers avec des algorithmes de hachage? 1040 00:44:47,050 --> 00:44:49,860 Quand je dis hachage et un hashing-- car un algorithme de hachage 1041 00:44:49,860 --> 00:44:54,140 est une manière d'être en mesure de générer une valeur aléatoire de toute valeur donnée. 1042 00:44:54,140 --> 00:44:59,300 Donc, dans ce cas particulier, le algorithme de hachage nous courons est ND 5 sur la base. 1043 00:44:59,300 --> 00:45:04,765 >> Et si je dois un ID, et cela est ma clé de hachage, je dois 1, 2, 3. 1044 00:45:04,765 --> 00:45:07,390 Quand je lance l'algorithme de hachage, il va revenir et dire, 1045 00:45:07,390 --> 00:45:10,800 ainsi 1 égale 7B, 2 est égal à 48, 3 = CD. 1046 00:45:10,800 --> 00:45:13,092 Ils sont répartis sur tout l'espace des clés. 1047 00:45:13,092 --> 00:45:14,050 Et pourquoi faites-vous cela? 1048 00:45:14,050 --> 00:45:17,120 Parce que cela fait en sorte que je peux mettre les dossiers sur plusieurs nœuds. 1049 00:45:17,120 --> 00:45:19,574 >> Si je fais cela incrémentielle, 1, 2, 3. 1050 00:45:19,574 --> 00:45:21,990 Et je dois une gamme de hachage courses dans ce cas particulier, 1051 00:45:21,990 --> 00:45:24,785 un petit espace de hachage, il fonctionne de 00 à FF, 1052 00:45:24,785 --> 00:45:27,951 alors les enregistrements vont venir et ils vont aller 1, 2, 3, 4, 5, 1053 00:45:27,951 --> 00:45:30,390 6, 7, 8, 9, 10, 11, 12. 1054 00:45:30,390 --> 00:45:31,800 Ce qui se produit? 1055 00:45:31,800 --> 00:45:34,860 Chaque insert va au même nœud. 1056 00:45:34,860 --> 00:45:36,070 Vous voyez ce que je veux dire? 1057 00:45:36,070 --> 00:45:40,910 >> Parce que quand je partage l'espace, et je répands ces documents à l'échelle, 1058 00:45:40,910 --> 00:45:45,950 et je partage, je vais dire partition 1 possède un espace dédié touche 0 à 54 ans. 1059 00:45:45,950 --> 00:45:47,720 Partition 2 est de 55 à 89. 1060 00:45:47,720 --> 00:45:49,780 Partition 3 est AA à FF. 1061 00:45:49,780 --> 00:45:53,740 Donc, si je suis en utilisant linéairement incrémentation ID, vous pouvez voir ce qui se passe. 1062 00:45:53,740 --> 00:45:57,410 1, 2, 3, 4, 5, 6, tout chemin jusqu'à 54. 1063 00:45:57,410 --> 00:46:00,030 Donc, comme je suis martelant le les enregistrements dans le système, 1064 00:46:00,030 --> 00:46:02,030 tout finit par aller à un nœud. 1065 00:46:02,030 --> 00:46:03,160 >> Ce n'est pas bien. 1066 00:46:03,160 --> 00:46:04,820 Voilà un anti-modèle. 1067 00:46:04,820 --> 00:46:08,760 Dans MongoDB qu'ils ont ce problème si vous ne l'utilisez une clé de hachage. 1068 00:46:08,760 --> 00:46:11,325 MongoDB vous donne la possibilité hachage de la valeur de clé. 1069 00:46:11,325 --> 00:46:13,950 Vous devriez toujours le faire, si vous utilisez un hachage incrémentation 1070 00:46:13,950 --> 00:46:17,380 clé dans MongoDB, ou vous serez clouer chaque écriture d'un noeud, 1071 00:46:17,380 --> 00:46:21,290 et vous limiterez votre écriture débit mal. 1072 00:46:21,290 --> 00:46:24,896 >> Public: Est-ce A9 169 en décimal? 1073 00:46:24,896 --> 00:46:28,450 >> RICK HOULIHAN: Ouais, il est quelque part par là. 1074 00:46:28,450 --> 00:46:29,950 A9, je ne sais pas. 1075 00:46:29,950 --> 00:46:32,200 Vous auriez à obtenir mon binaire au calculateur décimal. 1076 00:46:32,200 --> 00:46:34,237 Mon cerveau ne fonctionne pas comme ça. 1077 00:46:34,237 --> 00:46:36,320 AUDIENCE: Juste un rapide de vos commentaires Mongo. 1078 00:46:36,320 --> 00:46:39,530 Ainsi est l'ID d'objet qui vient nativement avec Mongo faire cela? 1079 00:46:39,530 --> 00:46:40,179 1080 00:46:40,179 --> 00:46:41,470 RICK HOULIHAN: Faut-il faire cela? 1081 00:46:41,470 --> 00:46:42,970 Si vous spécifiez. 1082 00:46:42,970 --> 00:46:45,030 Avec MongoDB, vous avez la possibilité. 1083 00:46:45,030 --> 00:46:48,930 Vous pouvez specify-- chaque document MongoDB doit avoir un ID de soulignement. 1084 00:46:48,930 --> 00:46:50,300 Voilà la valeur unique. 1085 00:46:50,300 --> 00:46:55,240 >> Dans MongoDB vous pouvez spécifier si pour hacher ou non. 1086 00:46:55,240 --> 00:46:56,490 Ils vous donnent juste l'option. 1087 00:46:56,490 --> 00:46:58,198 Si vous savez qu'il est aléatoire, pas de problème. 1088 00:46:58,198 --> 00:46:59,640 Vous ne devez pas le faire. 1089 00:46:59,640 --> 00:47:04,260 Si vous savez qu'il est pas aléatoire, que il est incrémentation, puis faire le hachage. 1090 00:47:04,260 --> 00:47:06,880 >> Maintenant, la chose à propos hachage, une fois que vous hachez 1091 00:47:06,880 --> 00:47:08,800 un value-- et cela est pourquoi clés de hachage sont toujours 1092 00:47:08,800 --> 00:47:13,740 requêtes uniques, parce que je l'ai changé la valeur, maintenant je ne peut pas faire une requête de gamme. 1093 00:47:13,740 --> 00:47:15,640 Je ne peux pas dire est-ce entre ceci ou cela, 1094 00:47:15,640 --> 00:47:20,800 parce que la valeur de hachage ne va pas comme équivalente à la valeur réelle. 1095 00:47:20,800 --> 00:47:24,570 Ainsi, lorsque vous hachage clé, il est seulement une égalité. 1096 00:47:24,570 --> 00:47:28,700 Voilà pourquoi, dans DynamoDB clé de hachage les requêtes sont toujours l'égalité seulement. 1097 00:47:28,700 --> 00:47:32,090 1098 00:47:32,090 --> 00:47:34,700 >> Alors maintenant, dans une gamme KEY-- quand je ajouter cette touche de gamme, 1099 00:47:34,700 --> 00:47:38,180 ces dossiers clés de gamme viennent tous et ils sont stockés sur la même partition. 1100 00:47:38,180 --> 00:47:42,430 Donc ils sont très rapidement, facilement récupéré parce que cela est le hachage, 1101 00:47:42,430 --> 00:47:43,220 cela est la gamme. 1102 00:47:43,220 --> 00:47:44,928 Et vous voyez tout avec le même hachage 1103 00:47:44,928 --> 00:47:48,550 est stocké sur le même espace de séparation. 1104 00:47:48,550 --> 00:47:53,889 Vous pouvez utiliser cette clé de gamme pour aider localiser vos données à proximité de son parent. 1105 00:47:53,889 --> 00:47:55,180 Alors, que vais-je vraiment fais ici? 1106 00:47:55,180 --> 00:47:57,320 Ceci est une relation un à plusieurs. 1107 00:47:57,320 --> 00:48:01,490 La relation entre une clé de hachage et la clé de gamme est un à plusieurs. 1108 00:48:01,490 --> 00:48:03,490 Je peux avoir des clés de hachage multiples. 1109 00:48:03,490 --> 00:48:07,610 Je ne peux avoir éventail multiple clés au sein de chaque clé de hachage. 1110 00:48:07,610 --> 00:48:11,910 >> Le hachage définit le parent, la gamme définit les enfants. 1111 00:48:11,910 --> 00:48:15,240 Donc vous pouvez voir qu'il ya ici analogique entre le produit d'assemblage relationnelle 1112 00:48:15,240 --> 00:48:18,840 et les mêmes types de construit en NoSQL. 1113 00:48:18,840 --> 00:48:20,760 Les gens parlent NoSQL comme non relationnelles. 1114 00:48:20,760 --> 00:48:22,200 Il est pas non relationnelles. 1115 00:48:22,200 --> 00:48:24,680 Les données possède toujours les relations. 1116 00:48:24,680 --> 00:48:28,172 Ces relations juste sont modélisés différemment. 1117 00:48:28,172 --> 00:48:29,880 Parlons un peu de peu de durabilité. 1118 00:48:29,880 --> 00:48:34,860 Lorsque vous écrivez à DynamoDB, écrit sont répliqués toujours à trois voies. 1119 00:48:34,860 --> 00:48:37,550 Ce qui signifie que nous avons trois AZ de. 1120 00:48:37,550 --> 00:48:39,160 AZ de zones de disponibilité sont. 1121 00:48:39,160 --> 00:48:43,430 Vous pouvez penser à une disponibilité Zone comme un centre de données 1122 00:48:43,430 --> 00:48:45,447 ou un ensemble de centres de données. 1123 00:48:45,447 --> 00:48:47,780 Ces choses sont géographiquement isolé de l'autre 1124 00:48:47,780 --> 00:48:51,610 à travers différentes zones de failles, à travers différents réseaux électriques et des plaines inondables. 1125 00:48:51,610 --> 00:48:54,510 Une défaillance de l'un AZ est pas va prendre une autre vers le bas. 1126 00:48:54,510 --> 00:48:56,890 Ils sont également liés ensemble avec la fibre noire. 1127 00:48:56,890 --> 00:49:01,240 Il prend en charge un sous 1 milliseconde de latence entre AZS. 1128 00:49:01,240 --> 00:49:05,390 Ainsi réplications de données en temps réel capable de AZS multiples. 1129 00:49:05,390 --> 00:49:09,990 >> Et souvent multiples déploiements AZ répondre aux exigences de haute disponibilité 1130 00:49:09,990 --> 00:49:12,930 la plupart des organisations d'entreprise. 1131 00:49:12,930 --> 00:49:16,139 Donc DynamoDB se propage à travers trois AZS par défaut. 1132 00:49:16,139 --> 00:49:19,430 Nous allons seulement à la connaissance d'écriture lorsque deux de ces trois nœuds reviennent 1133 00:49:19,430 --> 00:49:21,470 et dire, oui, je l'ai eu. 1134 00:49:21,470 --> 00:49:22,050 Pourquoi donc? 1135 00:49:22,050 --> 00:49:25,950 Parce que sur le côté de lecture nous sommes seulement vais vous donner les données en arrière quand 1136 00:49:25,950 --> 00:49:27,570 nous l'obtenons à partir de deux nœuds. 1137 00:49:27,570 --> 00:49:30,490 >> Si je suis la réplication entre trois, et je lis de deux, 1138 00:49:30,490 --> 00:49:32,840 Je suis toujours garanti d'avoir au moins une 1139 00:49:32,840 --> 00:49:35,720 de ceux qui se lit comme le la plus exemplaire à jour des données. 1140 00:49:35,720 --> 00:49:38,340 Voilà ce qui rend DynamoDB cohérente. 1141 00:49:38,340 --> 00:49:42,450 Maintenant, vous pouvez choisir d'activer ceux qui sont compatibles indique OFF. 1142 00:49:42,450 --> 00:49:45,070 Dans ce cas, je vais dire, Je ne lis que d'un nœud. 1143 00:49:45,070 --> 00:49:47,430 Et je ne peux pas garantir que ça va être les données les plus actuelles. 1144 00:49:47,430 --> 00:49:49,450 >> Donc, si une écriture est à venir dans, il n'a pas encore répliqué, 1145 00:49:49,450 --> 00:49:50,360 vous allez obtenir cette copie. 1146 00:49:50,360 --> 00:49:52,220 Voilà une lecture finalement cohérente. 1147 00:49:52,220 --> 00:49:54,640 Et ce qui est est la moitié du coût. 1148 00:49:54,640 --> 00:49:56,140 Donc ceci est quelque chose à penser. 1149 00:49:56,140 --> 00:50:00,160 Lorsque vous lisez sur DynamoDB, et vous configurez votre capacité de lecture 1150 00:50:00,160 --> 00:50:04,430 unités, si vous choisissez éventuellement lectures cohérentes, il est beaucoup moins cher, 1151 00:50:04,430 --> 00:50:06,010 il est environ la moitié du coût. 1152 00:50:06,010 --> 00:50:09,342 >> Et si il vous fait gagner de l'argent. 1153 00:50:09,342 --> 00:50:10,300 Mais cela est votre choix. 1154 00:50:10,300 --> 00:50:12,925 Si vous voulez une lecture cohérente ou une lecture finalement cohérente. 1155 00:50:12,925 --> 00:50:15,720 Voilà quelque chose que vous pouvez choisir. 1156 00:50:15,720 --> 00:50:17,659 >> Parlons indices. 1157 00:50:17,659 --> 00:50:19,450 Donc, nous avons mentionné que agrégation de niveau supérieur. 1158 00:50:19,450 --> 00:50:23,720 Nous avons les clés de hachage, et nous avons les clés de gamme. 1159 00:50:23,720 --> 00:50:24,320 C'est bien. 1160 00:50:24,320 --> 00:50:26,950 Et qui est sur la table primaire, je obtenu une clé de hachage, je suis une clé de gamme. 1161 00:50:26,950 --> 00:50:27,783 >> Qu'est-ce que ça veut dire? 1162 00:50:27,783 --> 00:50:30,410 Je dois un attribut que je peut exécuter des requêtes riches contre. 1163 00:50:30,410 --> 00:50:31,800 Il est la clé de la gamme. 1164 00:50:31,800 --> 00:50:35,530 Les autres attributs de ce que item-- Je peux filtrer sur ces attributs. 1165 00:50:35,530 --> 00:50:40,050 Mais je ne peux pas faire des choses comme, il commence par, ou est supérieur. 1166 00:50:40,050 --> 00:50:40,820 >> Comment est-ce que je fais ça? 1167 00:50:40,820 --> 00:50:42,860 Je crée un index. 1168 00:50:42,860 --> 00:50:45,340 Il ya deux types de index dans DynamoDB. 1169 00:50:45,340 --> 00:50:49,002 Un index est vraiment une autre vue de la table. 1170 00:50:49,002 --> 00:50:50,490 Et l'index secondaire locale. 1171 00:50:50,490 --> 00:50:51,781 >> Le premier que nous allons parler. 1172 00:50:51,781 --> 00:50:57,740 Donc secondaires locales coexistaient sur la même partition en tant que données. 1173 00:50:57,740 --> 00:51:00,240 Et en tant que tels, ils sont sur le même nœud physique. 1174 00:51:00,240 --> 00:51:01,780 Ils sont ce que nous appelons cohérente. 1175 00:51:01,780 --> 00:51:04,599 Sens, ils reconnaîtront l'écriture avec la table. 1176 00:51:04,599 --> 00:51:06,890 Lorsque l'écriture arrive, nous écrirons par l'index. 1177 00:51:06,890 --> 00:51:09,306 Nous écrirons à la table, et puis nous allons reconnaître. 1178 00:51:09,306 --> 00:51:10,490 Voilà donc cohérente. 1179 00:51:10,490 --> 00:51:13,174 Une fois l'écriture a été reconnu de la table, 1180 00:51:13,174 --> 00:51:15,090 il est garanti que le index secondaire locale 1181 00:51:15,090 --> 00:51:18,380 auront la même vision de données. 1182 00:51:18,380 --> 00:51:22,390 Mais ce qu'ils permettent que vous faites est définir des clés de gamme suppléants. 1183 00:51:22,390 --> 00:51:25,260 >> Avoir à utiliser le même hachage touche que la table primaire, 1184 00:51:25,260 --> 00:51:29,050 parce qu'ils sont co-située sur la même partition, et ils sont compatibles. 1185 00:51:29,050 --> 00:51:33,110 Mais je peux créer un index avec des touches de portée différentes. 1186 00:51:33,110 --> 00:51:41,590 Ainsi, par exemple, si je devais un fabricant qui avait une table de pièces première venant en. 1187 00:51:41,590 --> 00:51:44,590 Et pièces brutes viennent dans et ils sont regroupés par assemblage. 1188 00:51:44,590 --> 00:51:46,840 Et peut-être il ya un rappel. 1189 00:51:46,840 --> 00:51:50,240 >> Toute partie qui a été faite par ce fabricant après cette date, 1190 00:51:50,240 --> 00:51:52,840 Je dois tirer de ma ligne. 1191 00:51:52,840 --> 00:51:55,950 Je peux tourner un indice qui serait à la recherche, 1192 00:51:55,950 --> 00:52:00,760 agrégation à la date de fabrication de cette partie. 1193 00:52:00,760 --> 00:52:03,930 Donc, si ma table de haut niveau était déjà haché par le fabricant, 1194 00:52:03,930 --> 00:52:07,655 Peut-être qu'il a été disposé sur une partie ID, je peut créer un index de cette table 1195 00:52:07,655 --> 00:52:11,140 comme haché par le fabricant et distance sur la date de fabrication. 1196 00:52:11,140 --> 00:52:14,490 Et de cette façon que je pourrais dire, tout ce qui a été fabriqué entre ces deux dates, 1197 00:52:14,490 --> 00:52:16,804 Je dois tirer de la ligne. 1198 00:52:16,804 --> 00:52:18,220 Voilà donc un index secondaire locale. 1199 00:52:18,220 --> 00:52:22,280 >> Ceux-ci ont pour effet de limiter votre espace de clé de hachage. 1200 00:52:22,280 --> 00:52:24,360 Parce qu'ils ont coexisté sur le même noeud de stockage, 1201 00:52:24,360 --> 00:52:26,860 ils limitent la touche dièse espace pour 10 gigaoctets. 1202 00:52:26,860 --> 00:52:28,950 DynamoDB, sous la tables, se répartiront 1203 00:52:28,950 --> 00:52:31,380 votre table tous les 10 gigaoctets. 1204 00:52:31,380 --> 00:52:34,760 Lorsque vous mettez 10 Go de données, nous go [PHH], et nous ajoutons un autre nœud. 1205 00:52:34,760 --> 00:52:38,120 1206 00:52:38,120 --> 00:52:42,070 >> Nous ne serons pas diviser la LSI sur plusieurs partitions. 1207 00:52:42,070 --> 00:52:43,200 Nous allons séparer la table. 1208 00:52:43,200 --> 00:52:44,679 Mais nous ne serons pas diviser la LSI. 1209 00:52:44,679 --> 00:52:46,470 Voilà donc quelque chose important de comprendre 1210 00:52:46,470 --> 00:52:50,070 est si vous faites très, très, très grands rassemblements, 1211 00:52:50,070 --> 00:52:53,860 alors vous allez être limité à 10 giga-octets sur votre LSI. 1212 00:52:53,860 --> 00:52:56,640 >> Si tel est le cas, nous pouvons utiliser secondaires mondiaux. 1213 00:52:56,640 --> 00:52:58,630 Secondaires mondiaux sont vraiment une autre table. 1214 00:52:58,630 --> 00:53:01,720 Ils existent complètement à le côté de votre table primaire. 1215 00:53:01,720 --> 00:53:04,680 Et ils me permettent de trouver un structure totalement différente. 1216 00:53:04,680 --> 00:53:08,010 Alors, pensez à ce que des données est inséré en deux tables différentes, structuré 1217 00:53:08,010 --> 00:53:09,220 de deux manières différentes. 1218 00:53:09,220 --> 00:53:11,360 >> Je peux définir un totalement différente clé de hachage. 1219 00:53:11,360 --> 00:53:13,490 Je peux définir un totalement clé différente de gamme. 1220 00:53:13,490 --> 00:53:15,941 Et je peux exécuter ce totalement indépendante. 1221 00:53:15,941 --> 00:53:18,190 En fait, je l'ai provisionné ma qualité de lecture 1222 00:53:18,190 --> 00:53:21,090 et écrire la capacité pour mon index secondaires mondiaux 1223 00:53:21,090 --> 00:53:24,240 totalement indépendante de ma table primaire. 1224 00:53:24,240 --> 00:53:26,640 Si je définis que l'indice, je dis combien il lire et écrire 1225 00:53:26,640 --> 00:53:28,610 la capacité que ça va être l'aide. 1226 00:53:28,610 --> 00:53:31,490 >> Et qui est séparé de ma table primaire. 1227 00:53:31,490 --> 00:53:35,240 Maintenant, les deux indices nous permettent de non seulement définir des clés de hachage et de portée, 1228 00:53:35,240 --> 00:53:38,610 mais ils nous permettent de projeter les valeurs supplémentaires. 1229 00:53:38,610 --> 00:53:44,950 Donc, si je veux lire sur l'indice, et je veux obtenir une série de données, 1230 00:53:44,950 --> 00:53:48,327 Je ne dois pas revenir à la principale table pour obtenir les attributs supplémentaires. 1231 00:53:48,327 --> 00:53:50,660 Je peux projeter ceux supplémentaires attributs dans la table 1232 00:53:50,660 --> 00:53:53,440 pour soutenir le modèle d'accès. 1233 00:53:53,440 --> 00:53:57,700 Je sais que nous allons probablement entrer dans une certaine vraiment, really-- entrer dans les mauvaises herbes 1234 00:53:57,700 --> 00:53:58,910 ici, sur certaines de ces choses. 1235 00:53:58,910 --> 00:54:02,725 Maintenant, je suis à la dérive de cette. 1236 00:54:02,725 --> 00:54:07,320 >> AUDIENCE: [inaudible] clé --table signifiait un hachage? 1237 00:54:07,320 --> 00:54:08,840 Le hachage originale? 1238 00:54:08,840 --> 00:54:09,340 Multi-lames? 1239 00:54:09,340 --> 00:54:10,200 >> RICK HOULIHAN: Oui. 1240 00:54:10,200 --> 00:54:11,070 Oui. 1241 00:54:11,070 --> 00:54:15,260 La clé de table essentiellement pointe vers l'article. 1242 00:54:15,260 --> 00:54:19,280 Ainsi, un indice est un pointeur sur les articles originaux sur la table. 1243 00:54:19,280 --> 00:54:22,910 Maintenant, vous pouvez choisir de construire un indice qui a seulement la clé de la table, 1244 00:54:22,910 --> 00:54:24,840 et pas d'autres propriétés. 1245 00:54:24,840 --> 00:54:26,570 Et pourquoi aurais-je faire cela? 1246 00:54:26,570 --> 00:54:28,570 Eh bien, peut-être ai-je très grandes pièces. 1247 00:54:28,570 --> 00:54:31,660 >> Je vraiment besoin de savoir qui-- mon modèle d'accès pourrait-on dire, 1248 00:54:31,660 --> 00:54:33,760 les éléments qui contiennent cette propriété? 1249 00:54:33,760 --> 00:54:35,780 Ne pas besoin de retourner l'article. 1250 00:54:35,780 --> 00:54:37,800 Je dois juste savoir les éléments qui en contiennent. 1251 00:54:37,800 --> 00:54:40,700 Ainsi, vous pouvez créer des index qui ont seulement la clé de table. 1252 00:54:40,700 --> 00:54:43,360 >> Mais cela est surtout ce que un index dans la base de données est pour. 1253 00:54:43,360 --> 00:54:46,280 Il est pour être en mesure de rapidement identifier qui enregistre, 1254 00:54:46,280 --> 00:54:49,470 les lignes qui éléments de la table ont 1255 00:54:49,470 --> 00:54:51,080 les propriétés que je cherche. 1256 00:54:51,080 --> 00:54:53,610 1257 00:54:53,610 --> 00:54:54,860 >> GSI, alors comment fonctionnent-ils? 1258 00:54:54,860 --> 00:54:58,340 GSI sont essentiellement asynchrone. 1259 00:54:58,340 --> 00:55:02,570 La mise à jour vient dans la table, tableau est ensuite mis à jour de manière asynchrone 1260 00:55:02,570 --> 00:55:03,720 tous vos GSI. 1261 00:55:03,720 --> 00:55:06,680 Voilà pourquoi GSI sont finalement cohérente. 1262 00:55:06,680 --> 00:55:09,440 >> Il est important de noter que quand vous construisez GSI, 1263 00:55:09,440 --> 00:55:13,110 et vous comprenez que vous créez une autre dimension de aggregation-- 1264 00:55:13,110 --> 00:55:16,594 Maintenant, disons un bon exemple ici est un fabricant. 1265 00:55:16,594 --> 00:55:19,260 Je pense que je pourrais avoir parlé un fabricant de dispositif médical. 1266 00:55:19,260 --> 00:55:23,870 Fabricants de dispositifs médicaux ont souvent des pièces sérialisés. 1267 00:55:23,870 --> 00:55:28,070 Les pièces qui entrent dans la tout un remplacement de la hanche 1268 00:55:28,070 --> 00:55:30,200 avoir un petit numéro de série sur eux. 1269 00:55:30,200 --> 00:55:33,584 Et ils pourraient avoir des millions et des millions et des milliards de pièces 1270 00:55:33,584 --> 00:55:35,000 dans tous les dispositifs qu'ils expédient. 1271 00:55:35,000 --> 00:55:37,440 Eh bien, ils ont besoin d'agréger sous dimensions différentes, toutes les parties 1272 00:55:37,440 --> 00:55:39,520 dans un assemblage, d'autant pièces qui ont été faites 1273 00:55:39,520 --> 00:55:41,670 sur une certaine ligne, tous les les pièces qui sont venus 1274 00:55:41,670 --> 00:55:44,620 à partir d'un certain fabricant à une certaine date. 1275 00:55:44,620 --> 00:55:47,940 Et parfois ces agrégations monter dans les milliards. 1276 00:55:47,940 --> 00:55:50,550 >> Donc, je travaille avec quelques-uns des ces gars-là qui souffrent 1277 00:55:50,550 --> 00:55:53,156 parce qu'ils créent ces agrégations ginormous 1278 00:55:53,156 --> 00:55:54,280 dans leurs indices secondaires. 1279 00:55:54,280 --> 00:55:57,070 Ils pourraient avoir une pièces brutes table qui vient comme hachage seulement. 1280 00:55:57,070 --> 00:55:59,090 Chaque partie dispose d'un numéro de série unique. 1281 00:55:59,090 --> 00:56:00,975 Je l'utilise le numéro de série comme le hachage. 1282 00:56:00,975 --> 00:56:01,600 C'est beau. 1283 00:56:01,600 --> 00:56:04,160 Mon tableau de données brutes se propage tous à travers l'espace clé. 1284 00:56:04,160 --> 00:56:05,930 Ma [? écrit ?] [? l'ingestion?] est génial. 1285 00:56:05,930 --> 00:56:07,876 Je prends beaucoup de données. 1286 00:56:07,876 --> 00:56:09,500 Alors qu'est-ce qu'ils font est ils créent un GSI. 1287 00:56:09,500 --> 00:56:12,666 Et je dis, vous savez quoi, je dois voir toutes les parties pour ce fabricant. 1288 00:56:12,666 --> 00:56:15,060 Eh bien, tout d'un coup je suis prenant un milliard de lignes, 1289 00:56:15,060 --> 00:56:17,550 et les farcir sur un noeud, parce que quand 1290 00:56:17,550 --> 00:56:21,170 Je globale que la ID fabricant que le hachage, 1291 00:56:21,170 --> 00:56:25,410 et le numéro de la pièce que la gamme, puis tout d'un coup, je suis 1292 00:56:25,410 --> 00:56:30,530 mettre un milliard de pièces dans ce ce fabricant m'a délivré. 1293 00:56:30,530 --> 00:56:34,447 >> Cela peut causer beaucoup de pression sur l'ICF, 1294 00:56:34,447 --> 00:56:36,030 encore une fois, parce que je suis martelant un noeud. 1295 00:56:36,030 --> 00:56:38,350 Je mets tous ces insère dans un noeud. 1296 00:56:38,350 --> 00:56:40,940 Et qui est un véritable problème de cas d'utilisation. 1297 00:56:40,940 --> 00:56:43,479 Maintenant, je suis un bon design modèle pour la façon dont vous éviter cela. 1298 00:56:43,479 --> 00:56:45,770 Et qui est l'un des problèmes que je travaille toujours avec. 1299 00:56:45,770 --> 00:56:49,590 Mais ce qui se passe, est la GSI pourrait ne pas avoir la capacité d'écriture assez 1300 00:56:49,590 --> 00:56:52,330 pour être en mesure de pousser tous ceux rangées dans un seul nœud. 1301 00:56:52,330 --> 00:56:55,390 Et ce qui se passe ensuite est le primaire, la table du client, 1302 00:56:55,390 --> 00:57:00,180 la table primaire sera étranglé parce que le GSI ne peut pas suivre. 1303 00:57:00,180 --> 00:57:02,980 Donc, mon taux d'insert tomber sur la table primaire 1304 00:57:02,980 --> 00:57:06,230 comme mon GSI essaie de garder le rythme. 1305 00:57:06,230 --> 00:57:08,850 >> Très bien, alors de GSI, LSI, qui dois-je utiliser? 1306 00:57:08,850 --> 00:57:12,290 LSI sont compatibles. 1307 00:57:12,290 --> 00:57:13,750 De GSI sont finalement cohérente. 1308 00:57:13,750 --> 00:57:17,490 Si cela est OK, je recommande d'utiliser un GSI, ils sont beaucoup plus souple. 1309 00:57:17,490 --> 00:57:20,270 LSI peut être modélisée comme un GSI. 1310 00:57:20,270 --> 00:57:27,040 Et si la taille des données par clés de hachage en votre collection dépasse 10 gigaoctets, 1311 00:57:27,040 --> 00:57:31,050 alors vous allez vouloir l'utiliser GSI parce qu'elle est juste une limite dure. 1312 00:57:31,050 --> 00:57:32,035 >> Très bien, alors mise à l'échelle. 1313 00:57:32,035 --> 00:57:35,210 1314 00:57:35,210 --> 00:57:37,460 Débit en Dynamo DB, vous Can disposition [inaudible] 1315 00:57:37,460 --> 00:57:38,680 débit pour une table. 1316 00:57:38,680 --> 00:57:42,740 Nous avons des clients qui ont provisionné 60 billion-- 1317 00:57:42,740 --> 00:57:45,970 font 60 milliards de requêtes, régulièrement courir à plus d'un million de demandes 1318 00:57:45,970 --> 00:57:47,790 par seconde sur nos tables. 1319 00:57:47,790 --> 00:57:50,360 Il n'y a vraiment pas limite théorique à la quantité 1320 00:57:50,360 --> 00:57:53,730 et à quelle vitesse la table peut fonctionner dans Dynamo DB. 1321 00:57:53,730 --> 00:57:55,920 Il ya quelques doux limites sur votre compte 1322 00:57:55,920 --> 00:57:58,170 que nous mettons en at-il tant que vous ne vous affolez pas. 1323 00:57:58,170 --> 00:58:00,070 Si vous voulez plus de que, pas un problème. 1324 00:58:00,070 --> 00:58:00,820 Vous venez de nous dire. 1325 00:58:00,820 --> 00:58:02,810 Nous allons tourner le cadran. 1326 00:58:02,810 --> 00:58:08,210 >> Chaque compte est limitée à un certain niveau dans chaque service, juste à côté de la chauve-souris 1327 00:58:08,210 --> 00:58:11,920 de sorte que les gens ne vont pas fou eux-mêmes avoir des ennuis. 1328 00:58:11,920 --> 00:58:12,840 Pas de limite de taille. 1329 00:58:12,840 --> 00:58:14,940 Vous pouvez mettre un nombre quelconque des articles sur une table. 1330 00:58:14,940 --> 00:58:17,620 La taille d'un objet est limité à 400 kilo-octets chacune, 1331 00:58:17,620 --> 00:58:20,050 ce serait un objet pas les attributs. 1332 00:58:20,050 --> 00:58:24,200 Ainsi, la somme de tous les attributs est limitée à 400 kilo-octets. 1333 00:58:24,200 --> 00:58:27,300 Et puis, nous avons ce petit problème LSI 1334 00:58:27,300 --> 00:58:30,405 avec la limite de 10 gigaoctet par hachage. 1335 00:58:30,405 --> 00:58:33,280 AUDIENCE: Petit nombre, il me manque ce que vous me dites, que est-- 1336 00:58:33,280 --> 00:58:36,830 AUDIENCE: Oh, 400 kilo-octet est la taille maximale par article. 1337 00:58:36,830 --> 00:58:39,570 Donc, un article a tous les attributs. 1338 00:58:39,570 --> 00:58:43,950 Donc 400 k est la taille totale de cet article, 400 kilo-octets. 1339 00:58:43,950 --> 00:58:46,170 Donc, de tous les attributs combinés, toutes les données 1340 00:58:46,170 --> 00:58:49,140 qui est dans tous ces attributs, enroulé dans une taille totale, 1341 00:58:49,140 --> 00:58:51,140 actuellement aujourd'hui la limite d'article est de 400 k. 1342 00:58:51,140 --> 00:58:54,390 1343 00:58:54,390 --> 00:58:57,046 Donc, à nouveau mise à l'échelle, obtenu via le partitionnement. 1344 00:58:57,046 --> 00:58:58,920 Le débit est provisionné au niveau de la table. 1345 00:58:58,920 --> 00:59:00,160 Et il n'y a vraiment deux boutons. 1346 00:59:00,160 --> 00:59:02,400 Nous avons lu la capacité et écrire la capacité. 1347 00:59:02,400 --> 00:59:05,530 >> Donc, ce sont ajustés indépendamment l'un de l'autre. 1348 00:59:05,530 --> 00:59:08,640 La mesure de l'UCR strictement lectures cohérentes. 1349 00:59:08,640 --> 00:59:13,005 OK, si vous dites que je veux de 1000 RCU de ceux qui sont strictement conformes, 1350 00:59:13,005 --> 00:59:14,130 ceux qui sont lectures cohérentes. 1351 00:59:14,130 --> 00:59:17,130 Si vous dites que je veux éventuelle lectures cohérentes, 1352 00:59:17,130 --> 00:59:19,402 vous pouvez disposition 1000 RCU de, vous allez 1353 00:59:19,402 --> 00:59:21,840 pour obtenir finalement 2000 lectures cohérentes. 1354 00:59:21,840 --> 00:59:25,940 Et la moitié du prix pour ceux éventuellement consister en lit. 1355 00:59:25,940 --> 00:59:28,520 >> Encore une fois, ajusté indépendamment l'un de l'autre. 1356 00:59:28,520 --> 00:59:32,900 Et ils ont le throughput-- Si vous consommez 100% de votre télécommande, 1357 00:59:32,900 --> 00:59:35,960 tu ne vas pas à l'impact de la la disponibilité de vos droits. 1358 00:59:35,960 --> 00:59:40,161 Donc, ils sont complètement indépendamment les uns des autres. 1359 00:59:40,161 --> 00:59:43,160 Très bien, alors l'une des choses qui Je l'ai mentionné brièvement été étrangle. 1360 00:59:43,160 --> 00:59:44,320 Étranglement est mauvais. 1361 00:59:44,320 --> 00:59:47,311 Étranglement indique mauvais pas SQL. 1362 00:59:47,311 --> 00:59:50,310 Il ya des choses que nous pouvons faire pour aider à soulager l'étranglement que vous 1363 00:59:50,310 --> 00:59:51,040 connaissent. 1364 00:59:51,040 --> 00:59:53,240 Mais la meilleure solution à ceci est Prenons 1365 00:59:53,240 --> 00:59:58,000 Un regard sur ce que vous faites, parce il ya un anti-modèle en jeu ici. 1366 00:59:58,000 --> 01:00:02,140 >> Ces choses, des choses comme non uniforme les charges de travail, les touches de raccourci, partitions chaudes. 1367 01:00:02,140 --> 01:00:06,210 Je suis frappé un espace clé particulière très difficile pour une raison particulière. 1368 01:00:06,210 --> 01:00:07,080 Pourquoi je fais cela? 1369 01:00:07,080 --> 01:00:08,710 Essayons d'imaginer cela. 1370 01:00:08,710 --> 01:00:10,427 Je mélange mes données chaudes avec des données froides. 1371 01:00:10,427 --> 01:00:12,510 Je laisse mes tableaux se énorme, mais il n'y a vraiment 1372 01:00:12,510 --> 01:00:15,970 seulement un sous-ensemble des données qui est vraiment intéressant pour moi. 1373 01:00:15,970 --> 01:00:20,290 Donc, pour les données du journal, par exemple, beaucoup de clients, ils obtiennent les données du journal tous les jours. 1374 01:00:20,290 --> 01:00:22,490 Ils ont eu une énorme quantité de données du journal. 1375 01:00:22,490 --> 01:00:25,940 >> Si vous êtes juste le dumping tout ce journal données en une seule grande table, au fil du temps 1376 01:00:25,940 --> 01:00:28,070 cette table va devenir massif. 1377 01:00:28,070 --> 01:00:30,950 Mais je suis vraiment seulement intéressé par dernières 24 heures, les sept derniers jours, 1378 01:00:30,950 --> 01:00:31,659 les 30 derniers jours. 1379 01:00:31,659 --> 01:00:34,074 Quelle que soit la fenêtre de temps que je suis intéressé par la recherche 1380 01:00:34,074 --> 01:00:37,010 pour l'événement qui me dérange, ou l'événement qui est intéressant pour moi, 1381 01:00:37,010 --> 01:00:39,540 qui est la seule fenêtre de temps que je dois. 1382 01:00:39,540 --> 01:00:42,470 Alors pourquoi je mets 10 ans la valeur de données des journaux dans le tableau? 1383 01:00:42,470 --> 01:00:45,030 Qu'est-ce qui provoque est la table le fragment. 1384 01:00:45,030 --> 01:00:45,880 >> Il devient énorme. 1385 01:00:45,880 --> 01:00:48,340 Il commence à étaler à travers des milliers de nœuds. 1386 01:00:48,340 --> 01:00:51,380 Et puisque votre capacité est si faible, vous êtes 1387 01:00:51,380 --> 01:00:54,090 effectivement la limitation de débit sur chaque l'un de ces noeuds individuels. 1388 01:00:54,090 --> 01:00:57,120 Donc, nous allons commencer à regarder comment faisons nous roulons sur cette table. 1389 01:00:57,120 --> 01:01:01,502 Comment gérons-nous que les données un peu mieux pour éviter ces problèmes. 1390 01:01:01,502 --> 01:01:02,710 Et ce que cela ressemble? 1391 01:01:02,710 --> 01:01:04,370 Ceci est ce que cela ressemble. 1392 01:01:04,370 --> 01:01:06,790 Ceci est ce mauvais NoSQL ressemble. 1393 01:01:06,790 --> 01:01:07,830 >> Je suis une touche de raccourci ici. 1394 01:01:07,830 --> 01:01:10,246 Si vous regardez sur le côté ici, ce sont tous mes partitions. 1395 01:01:10,246 --> 01:01:12,630 Je me suis 16 partitions ici sur cette base de données particulière. 1396 01:01:12,630 --> 01:01:13,630 Nous le faisons tout le temps. 1397 01:01:13,630 --> 01:01:15,046 Je lance ce pour les clients de tous les temps. 1398 01:01:15,046 --> 01:01:16,550 Il a appelé la carte de chaleur. 1399 01:01:16,550 --> 01:01:20,590 Carte de chaleur me dit comment vous êtes accès à votre espace de clé. 1400 01:01:20,590 --> 01:01:23,700 Et ce que cela me dit est qu'il ya un hachage particulier 1401 01:01:23,700 --> 01:01:26,330 que ce gars aime une énormément, parce qu'il est 1402 01:01:26,330 --> 01:01:28,250 frapper vraiment, vraiment dur. 1403 01:01:28,250 --> 01:01:29,260 >> Donc, le bleu est agréable. 1404 01:01:29,260 --> 01:01:29,900 Nous aimons bleu. 1405 01:01:29,900 --> 01:01:30,720 Nous ne voulons pas rouge. 1406 01:01:30,720 --> 01:01:33,120 Où la pression de Red reçoit jusqu'à 100%. 1407 01:01:33,120 --> 01:01:35,560 100%, maintenant vous allez être étranglé. 1408 01:01:35,560 --> 01:01:39,030 Donc, chaque fois que vous voyez des lignes rouges comme this-- et il n'y a pas que le Dynamo DB-- 1409 01:01:39,030 --> 01:01:41,630 base de données NoSQL a tous ce problème. 1410 01:01:41,630 --> 01:01:44,640 Il sont anti-modèles qui peuvent conduire ces types de conditions. 1411 01:01:44,640 --> 01:01:49,070 Ce que je fais est que je travaille avec les clients de pallier ces conditions. 1412 01:01:49,070 --> 01:01:51,840 >> Et ce que cela ressemble? 1413 01:01:51,840 --> 01:01:54,260 Et cela devient le plus sur Dynamo DB débit, 1414 01:01:54,260 --> 01:01:56,176 mais il devient vraiment le maximum de NoSQL. 1415 01:01:56,176 --> 01:01:58,740 Cela ne se limite pas à Dynamo. 1416 01:01:58,740 --> 01:02:02,050 Ceci est definitely-- I utilisé pour travailler à Mongo. 1417 01:02:02,050 --> 01:02:04,090 Je suis familier avec de nombreuses plateformes NoSQL. 1418 01:02:04,090 --> 01:02:06,830 Chacun a ces types des problèmes clés chauds. 1419 01:02:06,830 --> 01:02:10,320 Pour tirer le meilleur parti de toute NoSQL base de données, spécifiquement Dynamo DB, 1420 01:02:10,320 --> 01:02:13,320 vous voulez créer les tables où l'élément clé de hachage a 1421 01:02:13,320 --> 01:02:18,590 un grand nombre de valeurs distinctes, un haut degré de cardinal. 1422 01:02:18,590 --> 01:02:22,530 Parce que cela signifie que je vais écrire à beaucoup de différentes tranches. 1423 01:02:22,530 --> 01:02:24,870 >> Les plus de seaux je suis écrit, plus il est probable 1424 01:02:24,870 --> 01:02:29,100 Je suis à se répandre que la charge d'écriture ou lire charger à travers plusieurs nœuds, 1425 01:02:29,100 --> 01:02:33,560 plus il est probable que je suis d'avoir un haut débit sur la table. 1426 01:02:33,560 --> 01:02:37,440 Et puis je veux que les valeurs à demandé assez uniformément dans le temps 1427 01:02:37,440 --> 01:02:39,430 et uniformément de façon aussi aléatoire que possible. 1428 01:02:39,430 --> 01:02:42,410 Eh bien, que ce genre d'intéressant, parce que je ne peux vraiment pas 1429 01:02:42,410 --> 01:02:43,960 contrôle lorsque les utilisateurs viennent. 1430 01:02:43,960 --> 01:02:47,645 Donc, il suffit de dire, si nous répandons les choses à travers l'espace des clés, 1431 01:02:47,645 --> 01:02:49,270 nous allons probablement être en meilleure forme. 1432 01:02:49,270 --> 01:02:51,522 >> Il ya une certaine montant de la livraison de temps 1433 01:02:51,522 --> 01:02:53,230 que tu ne vas pas pour être en mesure de contrôle. 1434 01:02:53,230 --> 01:02:55,438 Mais ceux qui sont vraiment les deux dimensions que nous avons, 1435 01:02:55,438 --> 01:02:58,800 l'espace, l'accès uniformément propagation, le temps, les demandes 1436 01:02:58,800 --> 01:03:01,040 arrivant régulièrement espacées dans le temps. 1437 01:03:01,040 --> 01:03:03,110 Et si ces deux conditions sont remplies, 1438 01:03:03,110 --> 01:03:05,610 alors ce est ce qu'il est va ressembler. 1439 01:03:05,610 --> 01:03:07,890 Cela est beaucoup plus agréable. 1440 01:03:07,890 --> 01:03:08,890 Nous sommes vraiment heureux ici. 1441 01:03:08,890 --> 01:03:10,432 Nous avons un modèle d'accès très homogène. 1442 01:03:10,432 --> 01:03:13,098 Ouais, peut-être vous obtenez un peu de pression chaque maintenant et puis, 1443 01:03:13,098 --> 01:03:14,830 mais rien de vraiment trop étendue. 1444 01:03:14,830 --> 01:03:17,660 Donc, il est étonnant de voir combien de fois, quand je travaille avec des clients, 1445 01:03:17,660 --> 01:03:20,670 ce premier graphique avec le Big Red bar et tout ce qui est laid jaune, il 1446 01:03:20,670 --> 01:03:23,147 partout, nous se fait avec l'exercice 1447 01:03:23,147 --> 01:03:24,980 après une couple de mois de ré-architecture, 1448 01:03:24,980 --> 01:03:28,050 ils courent exactement la même la charge de travail à la même charge exacte. 1449 01:03:28,050 --> 01:03:30,140 Et ceci est ce qu'il cherche comme maintenant. 1450 01:03:30,140 --> 01:03:36,600 Donc ce que vous obtenez avec NoSQL est un schéma de données qui est absolument 1451 01:03:36,600 --> 01:03:38,510 lié à la structure d'accès. 1452 01:03:38,510 --> 01:03:42,170 >> Et vous pouvez optimiser ce schéma de données pour soutenir ce modèle d'accès. 1453 01:03:42,170 --> 01:03:45,490 Si vous ne le faites pas, alors vous allez de voir ces types de problèmes 1454 01:03:45,490 --> 01:03:46,710 avec ces touches de raccourci. 1455 01:03:46,710 --> 01:03:50,518 >> AUDIENCE: Eh bien, inévitablement certains endroits vont être plus chaud que d'autres. 1456 01:03:50,518 --> 01:03:51,450 >> RICK HOULIHAN: Toujours. 1457 01:03:51,450 --> 01:03:51,960 Toujours. 1458 01:03:51,960 --> 01:03:54,620 Ouais, je veux dire il ya toujours a-- et encore, il ya 1459 01:03:54,620 --> 01:03:56,980 certains modèles de conception, nous allons passer à travers qui va parler de la façon dont vous traitez 1460 01:03:56,980 --> 01:03:58,480 avec ces super-grands rassemblements. 1461 01:03:58,480 --> 01:04:01,260 Je veux dire, je suis arrivé à les avoir, comment pouvons-nous y faire face? 1462 01:04:01,260 --> 01:04:03,760 Je suis un très bon cas d'utilisation que nous allons parler de cela. 1463 01:04:03,760 --> 01:04:05,940 >> Le discours de tous les droits, alors laissez- au sujet de certains clients maintenant. 1464 01:04:05,940 --> 01:04:06,950 Ces gars-là sont AdRoll. 1465 01:04:06,950 --> 01:04:08,990 Je ne sais pas si vous êtes familier avec AdRoll. 1466 01:04:08,990 --> 01:04:10,781 Vous les voyez probablement beaucoup sur le navigateur. 1467 01:04:10,781 --> 01:04:14,230 Ils sont ad re-ciblage, ils sont la plus grande entreprise annonce reciblage 1468 01:04:14,230 --> 01:04:14,940 là-bas. 1469 01:04:14,940 --> 01:04:17,792 Ils fonctionnent normalement régulièrement sur 60 milliards de transactions par jour. 1470 01:04:17,792 --> 01:04:20,000 Ils font plus d'un million transactions par seconde. 1471 01:04:20,000 --> 01:04:22,660 Ils ont un tableau assez simple la structure, le tableau le plus achalandé. 1472 01:04:22,660 --> 01:04:26,450 Il est fondamentalement juste un clé de hachage est le cookie, 1473 01:04:26,450 --> 01:04:29,010 la gamme est la situation démographique catégorie, puis 1474 01:04:29,010 --> 01:04:31,220 le troisième attribut est le score. 1475 01:04:31,220 --> 01:04:33,720 >> Donc, nous avons tous les cookies dans notre navigateur à partir de ces gars-là. 1476 01:04:33,720 --> 01:04:35,900 Et quand vous allez à un marchand participant, 1477 01:04:35,900 --> 01:04:39,390 ils vous marquez essentiellement à travers diverses catégories démographiques. 1478 01:04:39,390 --> 01:04:42,070 Quand vous allez à un site Web et vous dites que je veux voir ce ad-- 1479 01:04:42,070 --> 01:04:44,920 ou, fondamentalement, vous ne dites pas that-- mais quand vous allez sur le site 1480 01:04:44,920 --> 01:04:47,550 ils disent que vous voulez voir cette annonce. 1481 01:04:47,550 --> 01:04:49,370 Et ils vont obtenir cette annonce de AdRoll. 1482 01:04:49,370 --> 01:04:51,130 AdRoll vous regarde sur leur table. 1483 01:04:51,130 --> 01:04:52,115 Ils trouvent votre cookie. 1484 01:04:52,115 --> 01:04:53,990 Les annonceurs disent eux, je veux quelqu'un 1485 01:04:53,990 --> 01:04:58,632 qui est d'âge moyen, 40-year-old man, dans le sport. 1486 01:04:58,632 --> 01:05:01,590 Et ils vous marquez dans les données démographiques et ils décident si oui ou non 1487 01:05:01,590 --> 01:05:02,740 qui est une bonne annonce pour vous. 1488 01:05:02,740 --> 01:05:10,330 >> Maintenant, ils ont un SLA avec leurs fournisseurs de publicité 1489 01:05:10,330 --> 01:05:14,510 pour fournir 10 sous-milliseconde réponse à chaque demande unique. 1490 01:05:14,510 --> 01:05:16,090 Donc ils utilisent Dynamo DB pour cela. 1491 01:05:16,090 --> 01:05:18,131 Ils nous a frapper millions de requêtes par seconde. 1492 01:05:18,131 --> 01:05:21,120 Ils sont capables de faire tout leur les recherches, le triage de toutes ces données, 1493 01:05:21,120 --> 01:05:26,130 et obtenir ce lien de rajouter à cette annonceur en moins de 10 millisecondes. 1494 01:05:26,130 --> 01:05:29,800 Il est vraiment assez phénoménale la mise en œuvre qu'ils ont. 1495 01:05:29,800 --> 01:05:36,210 >> Ces gars-là actually-- ce sont là les gars. 1496 01:05:36,210 --> 01:05:38,010 Je ne suis pas sûr que ce soit ces gars-là. 1497 01:05:38,010 --> 01:05:40,127 Peut-être ces gars-là. 1498 01:05:40,127 --> 01:05:42,210 Fondamentalement us-- dit non, je ne pense pas que ce sont eux. 1499 01:05:42,210 --> 01:05:43,000 Je pense qu'il était quelqu'un d'autre. 1500 01:05:43,000 --> 01:05:44,750 Je travaillais avec un client qui m'a dit 1501 01:05:44,750 --> 01:05:47,040 que maintenant qu'ils ont allé à Dynamo DB, ils sont 1502 01:05:47,040 --> 01:05:50,330 dépenser plus d'argent sur les collations pour leur équipe de développement de chaque mois 1503 01:05:50,330 --> 01:05:52,886 que ce qu'ils consacrent à leur base de données. 1504 01:05:52,886 --> 01:05:54,760 Donc, il va vous donner une idée des économies de coûts 1505 01:05:54,760 --> 01:05:57,889 que vous pouvez obtenir en Dynamo DB est énorme. 1506 01:05:57,889 --> 01:05:59,430 Tout droit, Dropcam est une autre société. 1507 01:05:59,430 --> 01:06:02,138 Ce mec est un peu de-- si vous pensez de l'internet des objets, Dropcam 1508 01:06:02,138 --> 01:06:05,150 est fondamentalement Internet Security vidéo. 1509 01:06:05,150 --> 01:06:06,660 Vous mettez votre appareil photo là-bas. 1510 01:06:06,660 --> 01:06:08,180 Appareil dispose d'un détecteur de mouvement. 1511 01:06:08,180 --> 01:06:10,290 Quelqu'un vient le long, déclenche un point de repère. 1512 01:06:10,290 --> 01:06:13,540 L'appareil photo commence l'enregistrement pendant un certain temps jusqu'à ce il ne détecte plus aucun mouvement. 1513 01:06:13,540 --> 01:06:15,310 Met cette vidéo sur Internet. 1514 01:06:15,310 --> 01:06:19,800 >> Dropcam était une entreprise qui est essentiellement tournés vers Dynamo DB 1515 01:06:19,800 --> 01:06:22,200 parce qu'ils éprouvaient d'énormes douleurs de croissance. 1516 01:06:22,200 --> 01:06:25,820 Et ce qu'ils nous ont dit, pétaoctets soudain des données. 1517 01:06:25,820 --> 01:06:28,070 Ils avaient aucune idée de leur service serait un tel succès. 1518 01:06:28,070 --> 01:06:32,310 Plus vidéo entrant de YouTube est ce que ces gars-là obtiennent. 1519 01:06:32,310 --> 01:06:36,780 Ils utilisent DynamoDB pour suivre tous les métadonnées sur tous les points clés vidéo. 1520 01:06:36,780 --> 01:06:40,282 >> Donc, ils ont seaux S3 qu'ils poussent tous les objets binaires en. 1521 01:06:40,282 --> 01:06:41,990 Et puis ils ont Dossiers Dynamo DB qui 1522 01:06:41,990 --> 01:06:44,070 pointer les gens à ces trois objets S3. 1523 01:06:44,070 --> 01:06:47,070 Quand ils ont besoin pour regarder une vidéo, ils regardent l'enregistrement dans Dynamo DB. 1524 01:06:47,070 --> 01:06:47,903 Ils cliquent sur le lien. 1525 01:06:47,903 --> 01:06:49,770 Ils tirent en bas de la vidéo à partir de S3. 1526 01:06:49,770 --> 01:06:51,590 Voilà donc le genre de ce que cela ressemble. 1527 01:06:51,590 --> 01:06:53,580 Et cela est directement à partir de leur équipe. 1528 01:06:53,580 --> 01:06:56,010 >> Dynamo DB réduit leur délai de livraison pour les événements vidéo 1529 01:06:56,010 --> 01:06:57,590 de cinq à dix secondes. 1530 01:06:57,590 --> 01:07:00,470 Dans leur magasin relationnelle vieux, ils l'habitude d'avoir à aller exécuter 1531 01:07:00,470 --> 01:07:03,780 plusieurs requêtes complexes à la figure quels vidéos à tirer vers le bas, 1532 01:07:03,780 --> 01:07:06,690 à moins de 50 millisecondes. 1533 01:07:06,690 --> 01:07:08,990 Donc, il est incroyable, incroyable quel niveau de performance 1534 01:07:08,990 --> 01:07:12,990 vous pouvez obtenir lorsque vous optimisez et de peaufiner la base de données sous-jacente 1535 01:07:12,990 --> 01:07:15,110 pour soutenir le modèle d'accès. 1536 01:07:15,110 --> 01:07:20,500 Halfbrick, ces gars-là, quel est-il, Fruit Ninja je pense est leur chose. 1537 01:07:20,500 --> 01:07:22,590 Toutes les courses sur Dynamo DB. 1538 01:07:22,590 --> 01:07:26,810 Et ces gars-là, ils sont une grande équipe de développement, un grand développement 1539 01:07:26,810 --> 01:07:27,670 boutique. 1540 01:07:27,670 --> 01:07:29,364 >> Pas une bonne équipe de l'OPS. 1541 01:07:29,364 --> 01:07:31,280 Ils ne disposent pas d'un lot des ressources de fonctionnement. 1542 01:07:31,280 --> 01:07:33,940 Ils ont du mal en essayant de garder leur infrastructure d'application jusqu'à 1543 01:07:33,940 --> 01:07:34,290 et en cours d'exécution. 1544 01:07:34,290 --> 01:07:35,000 Ils sont venus nous. 1545 01:07:35,000 --> 01:07:36,251 Ils se regardèrent que Dynamo DB. 1546 01:07:36,251 --> 01:07:37,291 Ils ont dit, voilà pour nous. 1547 01:07:37,291 --> 01:07:39,470 Ils ont construit leur ensemble cadre d'application sur elle. 1548 01:07:39,470 --> 01:07:43,640 Quelques très bons commentaires ici de l'équipe de leur capacité 1549 01:07:43,640 --> 01:07:46,800 de se concentrer désormais sur le renforcement le jeu et non 1550 01:07:46,800 --> 01:07:49,010 ayant pour maintenir la infrastructures, qui 1551 01:07:49,010 --> 01:07:51,910 devenait une énorme quantité des frais généraux pour leur équipe. 1552 01:07:51,910 --> 01:07:56,170 Donc ceci est quelque chose that-- la avantage que vous obtenez de Dynamo DB. 1553 01:07:56,170 --> 01:08:00,930 >> Tout droit, entrer dans la modélisation de données ici. 1554 01:08:00,930 --> 01:08:03,440 Et nous avons parlé un peu de celui-ci à un, un à plusieurs, 1555 01:08:03,440 --> 01:08:05,060 et beaucoup à de nombreuses relations de type. 1556 01:08:05,060 --> 01:08:07,630 Et comment voulez-vous maintenir ceux de Dynamo. 1557 01:08:07,630 --> 01:08:10,500 En Dynamo DB nous utilisons index, de façon générale, 1558 01:08:10,500 --> 01:08:12,910 faire tourner les données de une saveur à l'autre. 1559 01:08:12,910 --> 01:08:15,210 Hash touches, des touches de gamme, et les index. 1560 01:08:15,210 --> 01:08:18,540 >> Dans ce cas particulier par exemple, que la plupart des Etats 1561 01:08:18,540 --> 01:08:23,802 avoir une exigence de licence qui qu'une licence d'pilote par personne. 1562 01:08:23,802 --> 01:08:26,510 Vous ne pouvez pas aller à obtenir deux conducteur licences dans l'État de Boston. 1563 01:08:26,510 --> 01:08:27,500 Je ne peux pas le faire dans le Texas. 1564 01:08:27,500 --> 01:08:28,708 Cela est le genre de la façon dont elle est. 1565 01:08:28,708 --> 01:08:32,779 Et donc à la DMV, nous avons recherches, nous vouloir rechercher le permis de conduire 1566 01:08:32,779 --> 01:08:35,180 par le numéro de sécurité sociale. 1567 01:08:35,180 --> 01:08:39,990 Je veux regarder les détails de l'utilisateur par le numéro de permis de conduire. 1568 01:08:39,990 --> 01:08:43,620 >> Donc, nous pourrions avoir la table d'un utilisateur a une clé de hachage sur le numéro de série, 1569 01:08:43,620 --> 01:08:47,830 ou le numéro de sécurité sociale, et divers attributs définis sur la question. 1570 01:08:47,830 --> 01:08:49,859 Maintenant, sur cette table, je pourrait définir un GSI que 1571 01:08:49,859 --> 01:08:53,370 flips qu'environ dit que je veux une clé de hachage sur la licence et ensuite 1572 01:08:53,370 --> 01:08:54,252 tous les autres éléments. 1573 01:08:54,252 --> 01:08:57,210 Maintenant, si je veux interroger et trouver le numéro de licence pour toute donnée sociale 1574 01:08:57,210 --> 01:08:59,609 Numéro de sécurité, je ne peux interroger la table principale. 1575 01:08:59,609 --> 01:09:02,130 >> Si je veux interroger et je veux pour obtenir la sécurité sociale 1576 01:09:02,130 --> 01:09:05,735 Numéro ou d'autres attributs par une numéro de licence, je peux interroger le GSI. 1577 01:09:05,735 --> 01:09:08,689 Ce modèle est que l'on une relation. 1578 01:09:08,689 --> 01:09:12,460 Juste un très simple GSI, retourner ces choses autour. 1579 01:09:12,460 --> 01:09:13,979 Maintenant, parler de un à plusieurs. 1580 01:09:13,979 --> 01:09:16,450 Un à plusieurs est essentiellement la clé de votre gamme de hachage. 1581 01:09:16,450 --> 01:09:20,510 Où nous recevons beaucoup avec ce cas d'utilisation est données de surveillance. 1582 01:09:20,510 --> 01:09:23,880 Les données du moniteur est livré dans régulière intervalle, comme l'Internet des objets. 1583 01:09:23,880 --> 01:09:26,890 Nous avons toujours tous ces dossiers à venir dans tout le temps. 1584 01:09:26,890 --> 01:09:31,420 >> Et je veux trouver toutes les lectures entre une période de temps particulière. 1585 01:09:31,420 --> 01:09:34,220 Il est une requête très commun dans infrastructure de surveillance. 1586 01:09:34,220 --> 01:09:38,430 La façon aller à ce sujet est de trouver un structure de table simple, une table. 1587 01:09:38,430 --> 01:09:42,250 Je ai un tableau des mesures du dispositif avec une clé de hachage sur l'ID du périphérique. 1588 01:09:42,250 --> 01:09:47,340 Et je dois une clé de gamme sur le timestamp, ou dans ce cas, l'épopée. 1589 01:09:47,340 --> 01:09:50,350 Et cela me permet exécuter complexe des requêtes sur cette touche de gamme 1590 01:09:50,350 --> 01:09:54,950 et retourner les enregistrements sont liés à la suite 1591 01:09:54,950 --> 01:09:56,310 mis que je suis à la recherche. 1592 01:09:56,310 --> 01:09:58,360 Et ce que l'on construit pour beaucoup relation 1593 01:09:58,360 --> 01:10:02,340 dans la table primaire en utilisant la clé de hachage, structure clé de gamme. 1594 01:10:02,340 --> 01:10:04,600 >> Voilà donc sorte de construit dans le tableau de la Dynamo DB. 1595 01:10:04,600 --> 01:10:07,290 Quand je définis un hachage et la table gamme de t, je suis 1596 01:10:07,290 --> 01:10:09,240 la définition d'une relation un à plusieurs. 1597 01:10:09,240 --> 01:10:12,770 Il est une relation parent-enfant. 1598 01:10:12,770 --> 01:10:14,620 >> Parlons de nombreux de nombreuses relations. 1599 01:10:14,620 --> 01:10:19,170 Et pour cet exemple particulier, encore une fois, nous allons utiliser de GSI. 1600 01:10:19,170 --> 01:10:23,500 Et parlons de jeux scénario où je dois un utilisateur donné. 1601 01:10:23,500 --> 01:10:26,500 Je veux trouver tous les jeux que il a enregistré pour ou en jouant dans. 1602 01:10:26,500 --> 01:10:29,600 Et pour un jeu donné, je voulez trouver tous les utilisateurs. 1603 01:10:29,600 --> 01:10:31,010 Alors, comment puis-je faire? 1604 01:10:31,010 --> 01:10:34,330 Ma table de jeux de l'utilisateur, je vais d'avoir une clé de hachage de l'ID utilisateur 1605 01:10:34,330 --> 01:10:35,810 et une clé de gamme de la partie. 1606 01:10:35,810 --> 01:10:37,810 >> Ainsi, un utilisateur peut avoir plusieurs jeux. 1607 01:10:37,810 --> 01:10:41,380 Il est une relation un à plusieurs entre l'utilisateur et les jeux qu'il joue. 1608 01:10:41,380 --> 01:10:43,410 Et puis sur le GSI, Je vais flip autour. 1609 01:10:43,410 --> 01:10:46,679 Je vais hachage sur le jeu et Je range sur l'utilisateur. 1610 01:10:46,679 --> 01:10:48,970 Donc, si je veux obtenir toutes les jeu à l'utilisateur de jouer dans, 1611 01:10:48,970 --> 01:10:49,950 Je vais interroger la table principale. 1612 01:10:49,950 --> 01:10:52,699 Si je veux obtenir tous les utilisateurs qui jouent un jeu particulier, 1613 01:10:52,699 --> 01:10:53,887 Je questionne le GSI. 1614 01:10:53,887 --> 01:10:54,970 Donc, vous voyez la façon dont nous le faisons? 1615 01:10:54,970 --> 01:10:58,369 Vous construisez de ces GSI pour soutenir le cas d'utilisation, l'application, l'accès 1616 01:10:58,369 --> 01:10:59,410 motif, l'application. 1617 01:10:59,410 --> 01:11:01,440 >> Si je dois interroger sur cette dimension, laissez- 1618 01:11:01,440 --> 01:11:03,500 moi créer un index sur cette dimension. 1619 01:11:03,500 --> 01:11:05,850 Si je ne le fais pas, je ne me soucie pas. 1620 01:11:05,850 --> 01:11:09,060 Et selon le cas d'utilisation, je peuvent avoir besoin de l'index ou je ne pourrais pas. 1621 01:11:09,060 --> 01:11:12,390 Si elle est un simple pour beaucoup, la table primaire est très bien. 1622 01:11:12,390 --> 01:11:15,860 Si je dois faire ces nombreux à beaucoup de, ou je dois faire un à ceux, 1623 01:11:15,860 --> 01:11:18,390 alors peut-être je ne dois à la seconde l'indice. 1624 01:11:18,390 --> 01:11:20,840 Donc tout dépend de ce que je suis en train de le faire 1625 01:11:20,840 --> 01:11:24,550 et ce que je vais essayer d'obtenir accompli. 1626 01:11:24,550 --> 01:11:28,000 >> Probablement, je ne vais pas passer trop beaucoup de temps à parler de documents. 1627 01:11:28,000 --> 01:11:31,460 Cela devient un peu, sans doute, plus profond que nous devons aller dans. 1628 01:11:31,460 --> 01:11:33,710 Parlons un peu sur la riche expression de la requête. 1629 01:11:33,710 --> 01:11:37,831 Donc, en Dynamo DB nous avons la possibilité de créer 1630 01:11:37,831 --> 01:11:39,330 ce que nous appelons expressions de projection. 1631 01:11:39,330 --> 01:11:42,660 Expressions de projection sont tout simplement ramasser les champs ou les valeurs 1632 01:11:42,660 --> 01:11:44,290 que vous souhaitez afficher. 1633 01:11:44,290 --> 01:11:46,000 OK, donc je fais une sélection. 1634 01:11:46,000 --> 01:11:48,010 Je fais une requête contre le Dynamo DB. 1635 01:11:48,010 --> 01:11:51,730 Et je dis, vous savez quoi, spectacle moi seulement cinq étoiles critiques 1636 01:11:51,730 --> 01:11:54,544 pour ce produit particulier. 1637 01:11:54,544 --> 01:11:55,710 Voilà donc tout ce que je veux voir. 1638 01:11:55,710 --> 01:11:57,320 Je ne veux pas voir tous les d'autres attributs de la rangée, 1639 01:11:57,320 --> 01:11:58,319 Je veux juste voir cela. 1640 01:11:58,319 --> 01:12:01,209 Il est juste comme dans SQL lorsque vous dire sélectionnez étoile ou de la table, 1641 01:12:01,209 --> 01:12:02,000 vous obtenez tout. 1642 01:12:02,000 --> 01:12:05,450 Quand je dis sélectionnez le nom de table, je ne reçois un attribut. 1643 01:12:05,450 --> 01:12:09,070 Il est le même genre de chose dans Dynamo DB ou encore des bases de données NoSQL. 1644 01:12:09,070 --> 01:12:14,510 Les expressions de filtre me permettent de essentiellement couper le jeu de résultats vers le bas. 1645 01:12:14,510 --> 01:12:15,540 Donc je fais une requête. 1646 01:12:15,540 --> 01:12:17,260 Requête peut revenir avec 500 articles. 1647 01:12:17,260 --> 01:12:20,255 Mais je veux seulement les éléments qui avoir un attribut qui dit cela. 1648 01:12:20,255 --> 01:12:23,380 OK, nous allons donc filtrer les articles qui ne correspondent pas à cette requête particulière. 1649 01:12:23,380 --> 01:12:25,540 Donc, nous avons des expressions de filtre. 1650 01:12:25,540 --> 01:12:28,310 >> Les expressions de filtre peut être exécuté sur n'importe quel attribut. 1651 01:12:28,310 --> 01:12:30,260 Ils ne sont pas comme les requêtes de plages. 1652 01:12:30,260 --> 01:12:32,690 Soulever des questions sont plus sélectifs. 1653 01:12:32,690 --> 01:12:36,470 Requêtes de filtrage me demandent d'aller Obtenez les résultats ensemble complet et ensuite 1654 01:12:36,470 --> 01:12:39,170 tailler les données que je ne veux pas. 1655 01:12:39,170 --> 01:12:40,660 Pourquoi est-ce important? 1656 01:12:40,660 --> 01:12:42,770 Parce que je l'ai lu tout. 1657 01:12:42,770 --> 01:12:46,597 Dans une requête, je vais lire et ça va être un géant sur les données. 1658 01:12:46,597 --> 01:12:48,430 Et puis je vais tailler ce que je dois. 1659 01:12:48,430 --> 01:12:52,080 Et si je ne fais que tailler une quelques lignes, puis qui est OK. 1660 01:12:52,080 --> 01:12:53,620 Il est pas si inefficace. 1661 01:12:53,620 --> 01:12:57,800 >> Mais si je lis tout un tas de les données, juste pour se tailler un poste, 1662 01:12:57,800 --> 01:13:01,490 alors je vais être mieux hors aide d'une requête de gamme, 1663 01:13:01,490 --> 01:13:03,030 parce qu'il est beaucoup plus sélective. 1664 01:13:03,030 --> 01:13:06,330 Il va me sauver beaucoup de l'argent, parce que je paie pour cette lecture. 1665 01:13:06,330 --> 01:13:10,430 Lorsque les résultats qui revient traverser ce fil pourrait être plus petit, 1666 01:13:10,430 --> 01:13:11,890 mais je dois payer pour la lecture. 1667 01:13:11,890 --> 01:13:14,340 Donc, comprendre comment vous obtenez les données. 1668 01:13:14,340 --> 01:13:16,420 Cela est très important dans le Dynamo DB. 1669 01:13:16,420 --> 01:13:19,710 >> Les expressions conditionnelles, voici ce que vous pourriez appeler le verrouillage optimiste. 1670 01:13:19,710 --> 01:13:28,470 Mise à jour si existe, ou si cette valeur est équivalent à ce que je spécifie. 1671 01:13:28,470 --> 01:13:31,494 Et si je dois un horodatage sur un dossier, je pourrais lire les données. 1672 01:13:31,494 --> 01:13:32,535 Je pourrais changer ces données. 1673 01:13:32,535 --> 01:13:35,030 Je pourrais aller écriture qui Retour de données à la base de données. 1674 01:13:35,030 --> 01:13:38,100 Si quelqu'un a changé le dossier, l'horodatage pourrait avoir changé. 1675 01:13:38,100 --> 01:13:40,370 Et de cette façon mon conditionnelle mise à jour pourrait dire la mise à jour 1676 01:13:40,370 --> 01:13:42,340 si l'horodatage est égal à cela. 1677 01:13:42,340 --> 01:13:46,290 Ou la mise à jour va échouer parce que quelqu'un mis à jour le dossier dans l'intervalle. 1678 01:13:46,290 --> 01:13:48,290 >> Voilà ce que nous appelons le verrouillage optimiste. 1679 01:13:48,290 --> 01:13:50,670 Cela signifie que quelqu'un peut entrer et changer, 1680 01:13:50,670 --> 01:13:53,100 et je vais le détecter quand je reviens à écrire. 1681 01:13:53,100 --> 01:13:56,106 Et puis je peux effectivement lu que données et dire, oh, il a changé cela. 1682 01:13:56,106 --> 01:13:57,230 Je dois tenir compte de cela. 1683 01:13:57,230 --> 01:14:00,490 Et je peux changer les données dans mon enregistrer et appliquer une autre mise à jour. 1684 01:14:00,490 --> 01:14:04,330 Ainsi, vous pouvez attraper ceux incrémentale mises à jour qui surviennent entre le moment 1685 01:14:04,330 --> 01:14:08,740 que vous lisiez les données et la fois que vous pourriez écrire les données. 1686 01:14:08,740 --> 01:14:11,520 >> Public: Et le filtre expression signifie en fait pas 1687 01:14:11,520 --> 01:14:13,020 dans le nombre ou pas-- 1688 01:14:13,020 --> 01:14:14,316 >> [Interposition VOIX] 1689 01:14:14,316 --> 01:14:16,232 RICK HOULIHAN: je ne veux pas trop entrer dans cette. 1690 01:14:16,232 --> 01:14:17,700 Ceci est un mot clé réservé. 1691 01:14:17,700 --> 01:14:20,130 La vue de la livre est une réservés mot-clé dans Dynamo DB. 1692 01:14:20,130 --> 01:14:24,500 Chaque base de données dispose de sa propre réserve noms pour les collections que vous ne pouvez pas utiliser. 1693 01:14:24,500 --> 01:14:27,240 Dynamo DB, si vous spécifiez une livre en face de cela, 1694 01:14:27,240 --> 01:14:29,310 vous pouvez définir ces noms au-dessus. 1695 01:14:29,310 --> 01:14:31,840 Ceci est une valeur de référence. 1696 01:14:31,840 --> 01:14:34,880 Il est probablement pas la meilleure syntaxe pour avoir là-haut pour cette discussion, 1697 01:14:34,880 --> 01:14:38,090 parce qu'il obtient dans certains bien-- Je vous ai parlé plus 1698 01:14:38,090 --> 01:14:41,360 à ce sujet à un niveau plus profond. 1699 01:14:41,360 --> 01:14:46,130 >> Mais il suffit de dire, cela pourrait soient requête de scan où ils views-- 1700 01:14:46,130 --> 01:14:50,190 ni livres vues est supérieur à 10. 1701 01:14:50,190 --> 01:14:54,660 Il est une valeur numérique, oui. 1702 01:14:54,660 --> 01:14:57,322 Si vous voulez, nous pouvons parler de que, après la discussion. 1703 01:14:57,322 --> 01:15:00,030 Très bien, alors que nous entrons dans certains scénarios dans les meilleures pratiques 1704 01:15:00,030 --> 01:15:02,000 où nous allons parler à propos de certaines applications ici. 1705 01:15:02,000 --> 01:15:03,810 Quels sont les cas d'utilisation pour Dynamo DB. 1706 01:15:03,810 --> 01:15:06,120 Quels sont la conception modèles dans Dynamo DB. 1707 01:15:06,120 --> 01:15:09,110 >> Et le premier nous allons parler est l'internet des objets. 1708 01:15:09,110 --> 01:15:15,010 Donc, nous recevons beaucoup de-- je suppose, ce qui est it-- plus de 50% 1709 01:15:15,010 --> 01:15:19,370 du trafic sur l'Internet ces jours- est générée par les machines, 1710 01:15:19,370 --> 01:15:21,930 des processus automatisés, pas par les humains. 1711 01:15:21,930 --> 01:15:25,140 Je veux dire cette chose que cette chose vous portez dans votre poche, 1712 01:15:25,140 --> 01:15:28,840 la quantité de données que cette chose est envoyer réellement autour sans vous 1713 01:15:28,840 --> 01:15:30,550 sachant qu'il est absolument incroyable. 1714 01:15:30,550 --> 01:15:34,970 Votre localité, informations à quelle vitesse vous allez. 1715 01:15:34,970 --> 01:15:38,400 Comment pensez-vous que Google Maps œuvres quand ils vous disent ce que le trafic est. 1716 01:15:38,400 --> 01:15:41,275 Il est parce que il ya des millions et des millions de personnes autour de la conduite 1717 01:15:41,275 --> 01:15:44,667 avec les téléphones qui envoient toutes les données de plus de endroit tout le temps. 1718 01:15:44,667 --> 01:15:46,500 Donc, l'une des choses sur ce type de données 1719 01:15:46,500 --> 01:15:50,980 qui vient dans, données de surveillance, connectez-vous les données, les données de séries chronologiques, est qu'il est 1720 01:15:50,980 --> 01:15:53,540 habituellement seulement intéressante pour un peu de temps. 1721 01:15:53,540 --> 01:15:55,580 Après ce temps, il est pas si intéressant. 1722 01:15:55,580 --> 01:15:58,390 Donc, nous avons parlé, ne laissez pas ces tables se développer sans limites. 1723 01:15:58,390 --> 01:16:03,410 L'idée ici est que peut-être je dois 24 heures de dollars de événements dans ma table chaude. 1724 01:16:03,410 --> 01:16:06,160 Et cette table chaude va être provisionnées à un taux très élevé, 1725 01:16:06,160 --> 01:16:07,950 parce que cela prend beaucoup de données. 1726 01:16:07,950 --> 01:16:10,920 Ça prend beaucoup de données et je lis beaucoup. 1727 01:16:10,920 --> 01:16:14,560 Je dois beaucoup de fonctionnement l'exécution de requêtes contre ces données. 1728 01:16:14,560 --> 01:16:18,120 >> Après 24 heures, hey, vous sais quoi, je ne me soucie pas. 1729 01:16:18,120 --> 01:16:21,150 Alors peut-être que je chaque rouleau de minuit ma table sur une nouvelle table 1730 01:16:21,150 --> 01:16:22,430 et je déprovisionner ce tableau. 1731 01:16:22,430 --> 01:16:26,440 Et je vais prendre de l'URC et Le bas de WCU parce 24 heures plus tard 1732 01:16:26,440 --> 01:16:28,630 Je ne vais pas courir autant des requêtes sur ces données. 1733 01:16:28,630 --> 01:16:30,200 Donc, je vais économiser de l'argent. 1734 01:16:30,200 --> 01:16:32,940 Et peut-être 30 jours plus tard, je ne sais pas même pas besoin de se soucier de tout cela. 1735 01:16:32,940 --> 01:16:35,020 Je pourrais prendre le WCU de tout le chemin vers le bas à une, 1736 01:16:35,020 --> 01:16:36,990 parce que vous savez quoi, il est ne va jamais se écrite. 1737 01:16:36,990 --> 01:16:38,300 Les données est de 30 jours. 1738 01:16:38,300 --> 01:16:40,000 Il ne change jamais. 1739 01:16:40,000 --> 01:16:44,200 >> Et il est presque jamais va se lire, donc nous allons simplement prendre ce RCU vers le bas à 10. 1740 01:16:44,200 --> 01:16:49,372 Et je suis économiser une tonne d'argent sur ce données, et ne payant que pour mes données chaudes. 1741 01:16:49,372 --> 01:16:52,330 Voilà la chose importante à regarder à quand vous regardez une série de temps 1742 01:16:52,330 --> 01:16:54,716 les données venant en volume. 1743 01:16:54,716 --> 01:16:55,590 Ce sont des stratégies. 1744 01:16:55,590 --> 01:16:58,010 Maintenant, je ne pouvais le laisser vont tous à la même table 1745 01:16:58,010 --> 01:16:59,461 et juste laisser cette table grandir. 1746 01:16:59,461 --> 01:17:01,460 Finalement, je vais des problèmes de performances. 1747 01:17:01,460 --> 01:17:04,060 Je vais devoir commencer à archiver certaines de ces données de la table, 1748 01:17:04,060 --> 01:17:04,720 étagère. 1749 01:17:04,720 --> 01:17:07,010 >> Voyons beaucoup mieux concevoir votre application 1750 01:17:07,010 --> 01:17:08,900 de sorte que vous pouvez fonctionner de cette façon droite. 1751 01:17:08,900 --> 01:17:11,460 Donc, il est juste automatique dans le code d'application. 1752 01:17:11,460 --> 01:17:13,580 A minuit tous les soirs il roule la table. 1753 01:17:13,580 --> 01:17:17,170 Peut-être que ce que je besoin est un coulissant fenêtre de 24 heures de données. 1754 01:17:17,170 --> 01:17:20,277 Ensuite, sur une base régulière, je suis appelant les données de la table. 1755 01:17:20,277 --> 01:17:22,360 Je coupe avec un Cron et je suis le mettre 1756 01:17:22,360 --> 01:17:24,160 sur ces autres tables, tout ce que tu veux. 1757 01:17:24,160 --> 01:17:25,940 Donc, si un retournement fonctionne, qui est très bien. 1758 01:17:25,940 --> 01:17:27,080 Si non, la tailler. 1759 01:17:27,080 --> 01:17:29,640 Mais gardons que les données à chaud loin de vos données froides. 1760 01:17:29,640 --> 01:17:32,535 Il va vous faire économiser beaucoup d'argent et faire vos tables plus performants. 1761 01:17:32,535 --> 01:17:35,960 1762 01:17:35,960 --> 01:17:38,210 Donc, la prochaine chose que nous allons parler est sur le catalogue de produits. 1763 01:17:38,210 --> 01:17:42,000 Le catalogue des marchandises est cas d'utilisation assez commun. 1764 01:17:42,000 --> 01:17:46,600 Ceci est en fait un motif très fréquent que nous verrons dans une variété de choses. 1765 01:17:46,600 --> 01:17:48,870 Vous savez, pour Twitter par exemple, un tweet chaud. 1766 01:17:48,870 --> 01:17:51,280 Tout le monde est à venir et saisissant ce tweet. 1767 01:17:51,280 --> 01:17:52,680 Le catalogue des marchandises, je me suis une vente. 1768 01:17:52,680 --> 01:17:54,120 Je suis une vente chaude. 1769 01:17:54,120 --> 01:17:57,277 Je me suis 70.000 demandes par seconde venue pour un produit 1770 01:17:57,277 --> 01:17:58,860 Description de mon catalogue de produits. 1771 01:17:58,860 --> 01:18:02,384 Nous le voyons sur le commerce de détail opération un peu. 1772 01:18:02,384 --> 01:18:03,550 Alors, comment pouvons-nous régler ce problème? 1773 01:18:03,550 --> 01:18:04,924 Il n'y a pas moyen de faire face à cela. 1774 01:18:04,924 --> 01:18:07,110 Tous mes utilisateurs veulent voir le même élément de données. 1775 01:18:07,110 --> 01:18:09,410 Ils arrivent, en même temps. 1776 01:18:09,410 --> 01:18:11,920 Et ils sont tous faire des demandes pour le même élément de données. 1777 01:18:11,920 --> 01:18:16,240 Cela me donne cette touche de raccourci, ce gros rouge rayure sur mon tableau qui ne nous plaît pas. 1778 01:18:16,240 --> 01:18:17,720 Et voilà à quoi ça ressemble. 1779 01:18:17,720 --> 01:18:22,290 Donc, dans mon espace clé Je suis en train martelé dans les articles en vente. 1780 01:18:22,290 --> 01:18:24,070 Je ne suis rien obtenir nulle part ailleurs. 1781 01:18:24,070 --> 01:18:26,050 >> Comment puis-je résoudre ce problème? 1782 01:18:26,050 --> 01:18:28,410 Eh bien, nous soulageons avec ce cache. 1783 01:18:28,410 --> 01:18:33,630 Cache, vous mettez essentiellement un en mémoire Cloison en face de la base de données. 1784 01:18:33,630 --> 01:18:37,260 Nous avons réussi [Inaudible] cache, comment vous 1785 01:18:37,260 --> 01:18:40,260 peut mettre en place votre propre cache, [inaudible] cache [? d,?] ce que vous voulez. 1786 01:18:40,260 --> 01:18:42,220 Mettez cela en face de la base de données. 1787 01:18:42,220 --> 01:18:47,250 Et de cette façon vous pouvez stocker ces données de ces touches de raccourci vers le haut dans ce cache 1788 01:18:47,250 --> 01:18:49,390 l'espace et le lire à travers le cache. 1789 01:18:49,390 --> 01:18:51,962 >> Et puis la plupart de votre lit commencer à regarder comme ça. 1790 01:18:51,962 --> 01:18:54,920 Je me suis tout cela cache HITS ici et je me suis rien qui se passe ici-bas 1791 01:18:54,920 --> 01:18:59,330 parce que la base de données est assis derrière le cache et les lectures ne viennent jamais à travers. 1792 01:18:59,330 --> 01:19:02,520 Si je change les données dans le base de données, je dois mettre à jour le cache. 1793 01:19:02,520 --> 01:19:04,360 Nous pouvons utiliser quelque chose comme les vapeurs de le faire. 1794 01:19:04,360 --> 01:19:07,360 Et je vais vous expliquer comment cela fonctionne. 1795 01:19:07,360 --> 01:19:09,060 Tout droit, messagerie. 1796 01:19:09,060 --> 01:19:11,180 E-mail, nous utilisons tous courriel. 1797 01:19:11,180 --> 01:19:12,540 >> Ceci est un très bon exemple. 1798 01:19:12,540 --> 01:19:14,950 Nous avons une sorte de table des messages. 1799 01:19:14,950 --> 01:19:17,040 Et nous avons courrier entrant et sortant. 1800 01:19:17,040 --> 01:19:19,760 Ceci est ce que le SQL serait ressemblent à construire cette boîte de réception. 1801 01:19:19,760 --> 01:19:23,350 Nous type d'utilisation le même genre de la stratégie à utiliser de GSI, GSI de 1802 01:19:23,350 --> 01:19:25,320 pour ma boîte de réception et ma boîte d'envoi. 1803 01:19:25,320 --> 01:19:27,600 Alors je me suis messages premières à venir dans mon tableau des messages. 1804 01:19:27,600 --> 01:19:30,194 Et la première approche de cette pourrait être, dire, OK, pas de problème. 1805 01:19:30,194 --> 01:19:31,110 Je dois messages premières. 1806 01:19:31,110 --> 01:19:33,710 Messages à venir [inaudible], ID de message, qui est grand. 1807 01:19:33,710 --> 01:19:35,070 Voilà mon hash unique. 1808 01:19:35,070 --> 01:19:38,280 Je vais créer deux de GSI, un pour ma boîte de réception, un pour ma boîte d'envoi. 1809 01:19:38,280 --> 01:19:40,530 Et la première chose que je vais faire est que je vais dire ma clé de hachage est 1810 01:19:40,530 --> 01:19:43,310 va être le bénéficiaire et Je vais organiser à la date. 1811 01:19:43,310 --> 01:19:44,220 C'est fantastique. 1812 01:19:44,220 --> 01:19:45,890 Je suis ma belle vue ici. 1813 01:19:45,890 --> 01:19:47,780 Mais il ya un petit problème ici. 1814 01:19:47,780 --> 01:19:50,891 Et vous rencontrez ce dans bases de données relationnelles ainsi. 1815 01:19:50,891 --> 01:19:52,390 Ils ont appelé partitionnement verticalement. 1816 01:19:52,390 --> 01:19:55,840 Vous voulez garder votre Big Data loin de vos peu de données. 1817 01:19:55,840 --> 01:20:00,470 >> Et la raison en est parce que je dois allez lire les articles pour avoir les attributs. 1818 01:20:00,470 --> 01:20:05,570 Et si mes organes sont tous ici, puis en lisant quelques articles 1819 01:20:05,570 --> 01:20:08,560 si ma longueur du corps est en moyenne 256 kilo-octets chacun, 1820 01:20:08,560 --> 01:20:10,991 le calcul devient assez laid. 1821 01:20:10,991 --> 01:20:12,490 Donc, dire que je veux lire la boîte de réception de David. 1822 01:20:12,490 --> 01:20:14,520 La boîte de réception de David a 50 articles. 1823 01:20:14,520 --> 01:20:17,880 La moyenne et la taille est de 256 kilo-octets. 1824 01:20:17,880 --> 01:20:21,730 Voici mon ratio de conversion pour RCU est de quatre kilo-octets. 1825 01:20:21,730 --> 01:20:24,450 >> OK, allons-y éventuellement lectures cohérentes. 1826 01:20:24,450 --> 01:20:28,640 Je suis toujours manger de 1,600 RCU suffit de lire la boîte de réception de David. 1827 01:20:28,640 --> 01:20:29,950 Aie. 1828 01:20:29,950 --> 01:20:31,980 OK, maintenant nous allons réfléchir sur la façon dont l'application fonctionne. 1829 01:20:31,980 --> 01:20:35,340 Si je suis dans une application de courrier électronique et Je regarde ma boîte de réception, 1830 01:20:35,340 --> 01:20:39,680 et je regarde le corps de chaque message, Non, je regarde les résumés. 1831 01:20:39,680 --> 01:20:41,850 Je regarde seulement les en-têtes. 1832 01:20:41,850 --> 01:20:46,310 Donc, nous allons construire une structure de table qui ressemble plus que. 1833 01:20:46,310 --> 01:20:49,470 >> Alors, voici l'information que mon flux de travail a besoin. 1834 01:20:49,470 --> 01:20:50,890 Il est dans ma boîte de réception GSI. 1835 01:20:50,890 --> 01:20:53,800 Il est de la date, l'expéditeur, le sujet, puis 1836 01:20:53,800 --> 01:20:56,790 l'ID de message, qui indique Retour à la table des messages 1837 01:20:56,790 --> 01:20:57,850 où je peux obtenir le corps. 1838 01:20:57,850 --> 01:21:01,260 1839 01:21:01,260 --> 01:21:04,420 Eh bien, ceux-ci seraient ID d'enregistrement. 1840 01:21:04,420 --> 01:21:09,850 Ils pointent vers le ID objet sur la table Dynamo DB. 1841 01:21:09,850 --> 01:21:12,220 Chaque indice creates-- toujours a toujours l'élément 1842 01:21:12,220 --> 01:21:15,750 ID dans le cadre de-- que est livré avec l'indice. 1843 01:21:15,750 --> 01:21:17,414 >> D'accord. 1844 01:21:17,414 --> 01:21:19,080 PUBLIC: Il raconte là où il est stocké? 1845 01:21:19,080 --> 01:21:21,420 RICK HOULIHAN: Oui, il raconte exactly-- qui est exactement ce qu'il fait. 1846 01:21:21,420 --> 01:21:22,644 Il est dit ici est mon record de re. 1847 01:21:22,644 --> 01:21:24,310 Et il va pointer de nouveau à mon dossier de re. 1848 01:21:24,310 --> 01:21:26,460 Exactement. 1849 01:21:26,460 --> 01:21:29,490 OK, maintenant ma boîte de réception est en réalité beaucoup plus petit. 1850 01:21:29,490 --> 01:21:32,210 Et cela prend effectivement le flux de travail d'une application e-mail. 1851 01:21:32,210 --> 01:21:34,230 Donc, ma boîte de réception, je clique. 1852 01:21:34,230 --> 01:21:38,160 Je vais le long et je clique sur le message, qui est quand je dois aller chercher le corps, 1853 01:21:38,160 --> 01:21:40,180 parce que je vais aller à un point de vue différent. 1854 01:21:40,180 --> 01:21:43,870 Donc, si vous pensez que sur le type de MVC cadre, la vue du modèle contrôleur. 1855 01:21:43,870 --> 01:21:46,120 >> Le modèle contient la des données que les besoins en vue 1856 01:21:46,120 --> 01:21:48,130 et le dispositif de commande coopère avec. 1857 01:21:48,130 --> 01:21:51,670 Quand je change le cadre, lorsque Je change la perspective, 1858 01:21:51,670 --> 01:21:55,080 il est OK pour revenir à la serveur et repeupler le modèle, 1859 01:21:55,080 --> 01:21:56,860 parce que ce que l'utilisateur attend. 1860 01:21:56,860 --> 01:22:00,530 Quand ils changent vues, qui est à ce moment nous pouvons revenir à la base de données. 1861 01:22:00,530 --> 01:22:02,480 Donc, e-mail, cliquez sur. 1862 01:22:02,480 --> 01:22:03,710 Je suis à la recherche pour le corps. 1863 01:22:03,710 --> 01:22:04,330 Aller-retour. 1864 01:22:04,330 --> 01:22:05,680 Allez chercher le corps. 1865 01:22:05,680 --> 01:22:06,950 >> Je lis beaucoup moins de données. 1866 01:22:06,950 --> 01:22:09,960 Je ne fais que lire les organismes qui David a besoin quand il a besoin d'eux. 1867 01:22:09,960 --> 01:22:14,230 Et je ne brûle en 1600 RCU est juste pour montrer sa boîte de réception. 1868 01:22:14,230 --> 01:22:17,670 Alors maintenant that-- cela est la manière LSI ou GSI-- je suis désolé, 1869 01:22:17,670 --> 01:22:19,900 GSI, cela fonctionnerait. 1870 01:22:19,900 --> 01:22:25,450 Nous avons notre hachage sur le destinataire. 1871 01:22:25,450 --> 01:22:27,030 Nous avons eu la clé de la plage sur la date. 1872 01:22:27,030 --> 01:22:31,380 Et nous avons les attributs projetés que nous devons seulement pour soutenir la vue. 1873 01:22:31,380 --> 01:22:34,300 >> Nous faisons une rotation pour que la boîte d'envoi. 1874 01:22:34,300 --> 01:22:35,770 Hachage sur l'expéditeur. 1875 01:22:35,770 --> 01:22:39,612 Et en substance, nous avons la très belle, vue propre. 1876 01:22:39,612 --> 01:22:41,570 Et il est que nous basically-- avoir cette gentils messages 1877 01:22:41,570 --> 01:22:45,870 tableau qui est propagée bien parce il est hachage seulement, haché ID de message. 1878 01:22:45,870 --> 01:22:51,750 Et nous avons deux index sont en rotation hors de ce tableau. 1879 01:22:51,750 --> 01:22:57,411 Très bien, alors idée ici est ne pas garder les grandes données et cette petite données 1880 01:22:57,411 --> 01:22:57,910 ensemble. 1881 01:22:57,910 --> 01:23:00,700 Partition verticalement, partitionner les tables. 1882 01:23:00,700 --> 01:23:03,150 Ne pas lire les données que vous ne devez pas. 1883 01:23:03,150 --> 01:23:04,850 Tout droit, jeux. 1884 01:23:04,850 --> 01:23:06,990 Nous aimons tous les jeux. 1885 01:23:06,990 --> 01:23:10,902 Au moins, je aime les jeux alors. 1886 01:23:10,902 --> 01:23:12,735 Donc, certaines des choses que nous traitons lorsque 1887 01:23:12,735 --> 01:23:14,193 nous pensons au sujet du jeu, non? 1888 01:23:14,193 --> 01:23:16,999 Gaming ces jours, en particulier mobiles jeu, est tout au sujet de la pensée. 1889 01:23:16,999 --> 01:23:19,540 Et je vais tourner ici peu loin de DynamoDB. 1890 01:23:19,540 --> 01:23:21,373 Je vais apporter partie de la discussion 1891 01:23:21,373 --> 01:23:24,240 dans une partie de la d'autres technologies d'AWS. 1892 01:23:24,240 --> 01:23:28,930 >> Mais l'idée de jeu est de penser environ en termes d'API, les API qui sont, 1893 01:23:28,930 --> 01:23:31,730 de manière générale, HTTP et JSON. 1894 01:23:31,730 --> 01:23:34,550 Il est comment les jeux mobiles type de interagir avec leurs extrémités arrière. 1895 01:23:34,550 --> 01:23:35,850 Ils font affichage JSON. 1896 01:23:35,850 --> 01:23:40,660 Ils obtiennent des données, et il est tout, de manière générale, dans de beaux API JSON. 1897 01:23:40,660 --> 01:23:44,950 >> Des choses comme faire des amis, se les données leaderboard, change, 1898 01:23:44,950 --> 01:23:47,699 contenu généré par l'utilisateur, repousser jusqu'à le système, 1899 01:23:47,699 --> 01:23:49,740 ce sont les types de choses que nous allons faire. 1900 01:23:49,740 --> 01:23:52,542 Les données d'actifs binaire, ces données pourrait ne pas siéger dans la base de données. 1901 01:23:52,542 --> 01:23:54,250 Cela pourrait s'asseoir dans un magasin d'objets, non? 1902 01:23:54,250 --> 01:23:56,541 Mais la base de données va finir par dire le système, 1903 01:23:56,541 --> 01:23:59,140 dire l'application où aller le chercher. 1904 01:23:59,140 --> 01:24:03,550 Et forcément, multijoueur serveurs, de retour infrastructure de fin, 1905 01:24:03,550 --> 01:24:06,180 et conçu pour une grande la disponibilité et l'évolutivité. 1906 01:24:06,180 --> 01:24:09,400 Donc, ce sont des choses que nous voulons tous dans l'infrastructure de jeu aujourd'hui. 1907 01:24:09,400 --> 01:24:12,160 >> Donc, nous allons jeter un oeil à à quoi ça ressemble. 1908 01:24:12,160 --> 01:24:16,070 Vous avez une extrémité arrière central, très simple. 1909 01:24:16,070 --> 01:24:19,880 Nous avons un système ici avec multiples zones de disponibilité. 1910 01:24:19,880 --> 01:24:23,780 Nous avons parlé de AZS que being-- penser d'entre eux en tant que centres de données distincts. 1911 01:24:23,780 --> 01:24:26,040 Plus d'un centre de données par AZ, mais ce est OK, 1912 01:24:26,040 --> 01:24:28,831 il suffit de penser à eux comme données séparé des centres qui sont géographiquement 1913 01:24:28,831 --> 01:24:30,090 et faute isolé. 1914 01:24:30,090 --> 01:24:32,172 >> Nous allons avoir un deux instances EC2. 1915 01:24:32,172 --> 01:24:33,880 Nous allons avoir un serveur de back-end. 1916 01:24:33,880 --> 01:24:35,800 Peut-être que si vous êtes un héritage architecture, nous sommes 1917 01:24:35,800 --> 01:24:38,920 en utilisant ce que nous appelons RDS, services de bases de données relationnelles. 1918 01:24:38,920 --> 01:24:42,040 Pourrait être MSSQL, MySQL, ou quelque chose comme ça. 1919 01:24:42,040 --> 01:24:47,080 Ceci est ainsi une des applications de lot sont conçus aujourd'hui. 1920 01:24:47,080 --> 01:24:49,594 >> Eh bien, nous pourrions aller avec cela est quand nous scale-out. 1921 01:24:49,594 --> 01:24:51,510 Nous irons de l'avant et mettre le seau S3 là-haut. 1922 01:24:51,510 --> 01:24:54,200 Et que S3 seau, au lieu de servir jusqu'à ces objets de notre servers-- 1923 01:24:54,200 --> 01:24:55,220 nous pourrions le faire. 1924 01:24:55,220 --> 01:24:57,210 Vous mettez tout votre binaire objets sur vos serveurs 1925 01:24:57,210 --> 01:24:59,751 et vous pouvez les utiliser serveur instances de données qui servent vers le haut. 1926 01:24:59,751 --> 01:25:01,860 Mais cela est assez cher. 1927 01:25:01,860 --> 01:25:05,107 >> Meilleure façon de faire est d'aller de l'avant et mettre ces objets dans un seau à S3. 1928 01:25:05,107 --> 01:25:06,315 S3 est un dépôts d'objets. 1929 01:25:06,315 --> 01:25:10,860 Il est construit spécifiquement pour servir jusqu'à ces types de choses. 1930 01:25:10,860 --> 01:25:13,690 Et que ces clients demandent directement à partir de ces seaux d'objets, 1931 01:25:13,690 --> 01:25:15,390 décharger les serveurs. 1932 01:25:15,390 --> 01:25:17,020 Donc, nous commençons à l'échelle ici. 1933 01:25:17,020 --> 01:25:19,140 >> Maintenant, nous avons des utilisateurs partout dans le monde. 1934 01:25:19,140 --> 01:25:19,730 Je suis arrivé utilisateurs. 1935 01:25:19,730 --> 01:25:23,380 Je dois avoir un contenu local situé à proximité de ces utilisateurs, non? 1936 01:25:23,380 --> 01:25:26,200 Je ai créé un seau S3 comme mon référentiel source. 1937 01:25:26,200 --> 01:25:29,370 Et je vais avant que, avec la distribution CloudFront. 1938 01:25:29,370 --> 01:25:31,720 >> CloudFront est un CD et un Content Delivery Network. 1939 01:25:31,720 --> 01:25:35,750 Fondamentalement, il prend les données que vous spécifiez et met en cache partout sur l'internet 1940 01:25:35,750 --> 01:25:39,230 afin que les utilisateurs peuvent avoir partout une réponse très rapide quand 1941 01:25:39,230 --> 01:25:40,960 ils demandent ces objets. 1942 01:25:40,960 --> 01:25:41,960 >> Ainsi, vous obtenez une idée. 1943 01:25:41,960 --> 01:25:48,230 Vous genre de tirer parti de toutes les aspects de AWS ici pour obtenir ce fait. 1944 01:25:48,230 --> 01:25:50,790 Et finalement, nous jetons dans un groupe de mise à l'échelle automatique. 1945 01:25:50,790 --> 01:25:52,737 Donc, nos instances de AC2 de nos serveurs de jeu, 1946 01:25:52,737 --> 01:25:54,820 comme ils commencent à devenir plus occupé et plus en plus occupés, 1947 01:25:54,820 --> 01:25:57,236 ils vont simplement tourner une autre exemple, tourner un autre cas, 1948 01:25:57,236 --> 01:25:58,210 tourner une autre instance. 1949 01:25:58,210 --> 01:26:02,090 Donc, la technologie AWS dispose, il vous permet de spécifier les paramètres 1950 01:26:02,090 --> 01:26:04,650 autour de laquelle vos serveurs vont grandir. 1951 01:26:04,650 --> 01:26:08,110 Ainsi vous pouvez avoir un nombre n de serveurs là-bas à un moment donné. 1952 01:26:08,110 --> 01:26:11,870 Et si votre charge disparaît, ils vont rétrécir, le nombre va diminuer. 1953 01:26:11,870 --> 01:26:15,250 Et si la charge revient, il va grandir revenir en arrière, de manière élastique. 1954 01:26:15,250 --> 01:26:17,050 >> Donc, cela ressemble beaucoup. 1955 01:26:17,050 --> 01:26:19,800 Nous avons beaucoup d'instances EC2. 1956 01:26:19,800 --> 01:26:21,671 Nous pouvons mettre en cache avant de la base de données, 1957 01:26:21,671 --> 01:26:23,045 essayer et accélérer les bases de données. 1958 01:26:23,045 --> 01:26:25,030 Le point de pression prochaine généralement les gens voient 1959 01:26:25,030 --> 01:26:28,850 Ils escaladent est un jeu utilisant un Système de base de données relationnelle. 1960 01:26:28,850 --> 01:26:30,790 Jeez, la base de données la performance est terrible. 1961 01:26:30,790 --> 01:26:31,932 Comment pouvons-nous améliorer cela? 1962 01:26:31,932 --> 01:26:33,640 Essayons de mettre cache en face de cela. 1963 01:26:33,640 --> 01:26:36,780 >> Eh bien, cache ne fonctionne pas si grande dans les jeux, non? 1964 01:26:36,780 --> 01:26:39,330 Pour les jeux, l'écriture est douloureuse. 1965 01:26:39,330 --> 01:26:40,930 Les jeux sont très écrivent lourde. 1966 01:26:40,930 --> 01:26:43,610 Cache ne fonctionne pas lorsque vous êtes écrire lourde parce que vous avez toujours 1967 01:26:43,610 --> 01:26:44,610 obtenu de mettre à jour le cache. 1968 01:26:44,610 --> 01:26:47,780 Vous mettez à jour le cache, il est rien à être mise en cache. 1969 01:26:47,780 --> 01:26:49,780 Il est en fait juste un travail supplémentaire. 1970 01:26:49,780 --> 01:26:51,970 >> Alors, où nous allons ici? 1971 01:26:51,970 --> 01:26:54,400 Vous avez un gros goulot d'étranglement là-bas dans la base de données. 1972 01:26:54,400 --> 01:26:57,661 Et l'endroit où aller est évidemment le partitionnement. 1973 01:26:57,661 --> 01:26:59,410 Le partitionnement est pas facile à faire quand vous êtes 1974 01:26:59,410 --> 01:27:01,900 traiter avec les bases de données relationnelles. 1975 01:27:01,900 --> 01:27:05,080 Avec bases de données relationnelles, vous êtes responsable de la gestion, de manière efficace, 1976 01:27:05,080 --> 01:27:06,210 l'espace des clés. 1977 01:27:06,210 --> 01:27:10,527 Vous dites que les utilisateurs entre A et M rendez-vous ici, entre N et Z y aller. 1978 01:27:10,527 --> 01:27:12,360 Et vous êtes de commutation à travers l'application. 1979 01:27:12,360 --> 01:27:15,000 Donc, vous avez affaire à cette source de données de la partition. 1980 01:27:15,000 --> 01:27:18,670 Vous avez des contraintes transactionnelles qui ne couvrent pas les partitions. 1981 01:27:18,670 --> 01:27:20,560 Vous avez toutes sortes de désordre que vous êtes 1982 01:27:20,560 --> 01:27:23,040 traiter là-bas essayer pour faire face à la montée en puissance 1983 01:27:23,040 --> 01:27:25,120 et la construction d'une infrastructure plus large. 1984 01:27:25,120 --> 01:27:27,284 Il est juste pas drôle. 1985 01:27:27,284 --> 01:27:30,930 >> Auditoire: Alors, dites-vous que augmentant points sources accélère 1986 01:27:30,930 --> 01:27:31,430 le processus? 1987 01:27:31,430 --> 01:27:32,513 RICK HOULIHAN: augmentation? 1988 01:27:32,513 --> 01:27:33,520 Points Source: l'auditoire. 1989 01:27:33,520 --> 01:27:34,410 RICK HOULIHAN: points de Source? 1990 01:27:34,410 --> 01:27:37,500 Public: A partir de l'information, où l'information vient de? 1991 01:27:37,500 --> 01:27:38,250 RICK HOULIHAN: Non 1992 01:27:38,250 --> 01:27:41,820 Ce que je dis est l'augmentation de la nombre de partitions dans le magasin de données 1993 01:27:41,820 --> 01:27:44,060 améliore le débit. 1994 01:27:44,060 --> 01:27:48,300 Donc ce qui se passe ici est utilisateurs entrée en l'instance EC2 ici, 1995 01:27:48,300 --> 01:27:50,780 Eh bien, si je dois un utilisateur voilà A à M, je vais aller ici. 1996 01:27:50,780 --> 01:27:53,560 De N à P, je vais aller ici. 1997 01:27:53,560 --> 01:27:55,060 De P à Z, je vais aller ici. 1998 01:27:55,060 --> 01:27:57,120 >> AUDIENCE: OK, ce sont donc ceux tous stockés dans différents nœuds? 1999 01:27:57,120 --> 01:27:57,911 >> RICK HOULIHAN: Oui. 2000 01:27:57,911 --> 01:28:00,210 Pensez à ceux-ci comme différents silos de données. 2001 01:28:00,210 --> 01:28:01,660 Donc, vous êtes d'avoir à le faire. 2002 01:28:01,660 --> 01:28:02,910 Si vous essayez de le faire cela, si vous essayez 2003 01:28:02,910 --> 01:28:05,730 à l'échelle sur une plate-forme relationnelle, ceci est ce que vous faites. 2004 01:28:05,730 --> 01:28:08,100 Vous prenez les données et il vous abattre. 2005 01:28:08,100 --> 01:28:10,975 Et vous êtes le partitionner travers plusieurs instances de la base de données. 2006 01:28:10,975 --> 01:28:13,580 Et vous gérez tout ce qui au niveau de l'application. 2007 01:28:13,580 --> 01:28:14,729 Il n'y a pas de plaisir. 2008 01:28:14,729 --> 01:28:15,770 Alors, que voulons-nous aller? 2009 01:28:15,770 --> 01:28:20,240 Nous voulons aller DynamoDB, entièrement géré, Magasin de données NoSQL, disposition débit. 2010 01:28:20,240 --> 01:28:22,680 Nous utilisons des index secondaires. 2011 01:28:22,680 --> 01:28:26,154 Il est fondamentalement HTTP API et comprend support de document. 2012 01:28:26,154 --> 01:28:28,570 Donc, vous ne devez pas vous inquiéter que sur l'un de partitionnement. 2013 01:28:28,570 --> 01:28:30,740 Nous faisons tout pour vous. 2014 01:28:30,740 --> 01:28:33,260 Alors maintenant, à la place, vous il suffit d'écrire à la table. 2015 01:28:33,260 --> 01:28:36,490 Si le tableau doit être partitionné, ce qui se passe dans les coulisses. 2016 01:28:36,490 --> 01:28:40,642 Vous êtes complètement isolés à partir de cela comme un promoteur. 2017 01:28:40,642 --> 01:28:42,350 Alors parlons certains des cas d'utilisation 2018 01:28:42,350 --> 01:28:47,564 que nous nous heurtons à des jeux en commun scénarios de jeu, leaderboard. 2019 01:28:47,564 --> 01:28:49,980 Donc, vous avez utilisateurs venant, les BoardNames qu'ils sont 2020 01:28:49,980 --> 01:28:52,930 sur, les scores pour cet utilisateur. 2021 01:28:52,930 --> 01:28:57,700 Nous pourrions être hachage sur l'ID utilisateur, et puis nous avons la gamme sur le jeu. 2022 01:28:57,700 --> 01:28:59,960 Ainsi, chaque utilisateur veut voir tout le jeu qu'il a joué 2023 01:28:59,960 --> 01:29:01,770 et toute son meilleur score à travers tout le jeu. 2024 01:29:01,770 --> 01:29:04,000 Voilà donc son classement personnel. 2025 01:29:04,000 --> 01:29:10,010 >> Maintenant, je veux y aller et je veux get-- si je reçois ces classements personnels. 2026 01:29:10,010 --> 01:29:12,827 Ce que je veux faire est aller chercher le meilleur score de tous les utilisateurs. 2027 01:29:12,827 --> 01:29:13,660 Alors, comment puis-je faire? 2028 01:29:13,660 --> 01:29:18,070 Lorsque mon record est haché sur l'identification de l'utilisateur, se situait sur le jeu, 2029 01:29:18,070 --> 01:29:20,740 bien, je vais aller de l'avant et de restructurer, de créer un GSI, 2030 01:29:20,740 --> 01:29:22,370 et je vais restructurer ces données. 2031 01:29:22,370 --> 01:29:27,310 >> Maintenant, je vais sur le hachage BoardName, qui est le jeu. 2032 01:29:27,310 --> 01:29:29,800 Et je vais aller sur le plus haut score. 2033 01:29:29,800 --> 01:29:31,540 Et maintenant, je l'ai créé différents seaux. 2034 01:29:31,540 --> 01:29:34,790 Je suis en utilisant la même table, les mêmes données de l'élément. 2035 01:29:34,790 --> 01:29:39,870 Mais je crée un seau qui donne moi une agrégation de haut score en jeu. 2036 01:29:39,870 --> 01:29:43,180 >> Et je peux interroger cette table pour obtenir cette information. 2037 01:29:43,180 --> 01:29:50,890 Donc, je me suis fixé ce modèle de requête jusqu'à être soutenu par un index secondaire. 2038 01:29:50,890 --> 01:29:54,556 Maintenant, ils peuvent être triés par BoardName et classés par topscore, selon. 2039 01:29:54,556 --> 01:29:57,180 Donc vous pouvez le voir, ce sont des types d'utiliser des cas, vous obtenez dans le jeu. 2040 01:29:57,180 --> 01:30:02,190 Un autre bon cas d'utilisation nous obtenons dans le jeu est récompenses et qui a remporté les prix. 2041 01:30:02,190 --> 01:30:05,340 Et ceci est un grand cas d'utilisation où nous appelons indices épars. 2042 01:30:05,340 --> 01:30:07,340 Indices épars sont les capacité à générer 2043 01:30:07,340 --> 01:30:10,850 un indice qui ne signifie pas nécessairement contenir chaque article sur la table. 2044 01:30:10,850 --> 01:30:11,470 Et pourquoi pas? 2045 01:30:11,470 --> 01:30:14,540 Parce que l'attribut qui est en cours indexée ne existe pas sur chaque article. 2046 01:30:14,540 --> 01:30:16,460 >> Donc, dans ce cas particulier cas d'utilisation, je veux dire, 2047 01:30:16,460 --> 01:30:19,240 vous savez quoi, je vais créer un attribut appelé Award. 2048 01:30:19,240 --> 01:30:22,970 Et je vais donner à chaque utilisateur qui a un prix qui attribut. 2049 01:30:22,970 --> 01:30:25,950 Les utilisateurs qui ne disposent pas récompenses sont ne va pas avoir cet attribut. 2050 01:30:25,950 --> 01:30:27,800 Alors, quand je crée de la index, les seuls utilisateurs 2051 01:30:27,800 --> 01:30:28,960 qui vont montrer dans l'indice sont 2052 01:30:28,960 --> 01:30:31,050 ceux qui ont effectivement remporté des prix. 2053 01:30:31,050 --> 01:30:34,440 Voilà donc un excellent moyen d'être en mesure pour créer des index filtrées 2054 01:30:34,440 --> 01:30:40,580 sont très, très sélective qui ne le font pas avoir à l'index de la table entière. 2055 01:30:40,580 --> 01:30:43,050 >> Nous allons donc faire ici bas sur le temps. 2056 01:30:43,050 --> 01:30:49,190 Je vais aller de l'avant et sauter et sauter sur ce scénario. 2057 01:30:49,190 --> 01:30:52,625 Parlez-nous un peu about-- 2058 01:30:52,625 --> 01:30:54,460 >> AUDIENCE: Puis-je poser une brève question? 2059 01:30:54,460 --> 01:30:56,722 On est lourde écrire? 2060 01:30:56,722 --> 01:30:57,680 RICK HOULIHAN: Qu'est-ce? 2061 01:30:57,680 --> 01:30:58,596 AUDIENCE: Ecrire lourde. 2062 01:30:58,596 --> 01:31:01,270 RICK HOULIHAN: Ecrire lourde. 2063 01:31:01,270 --> 01:31:03,460 Laisse moi voir. 2064 01:31:03,460 --> 01:31:06,220 >> AUDIENCE: Ou est-ce pas quelque chose que vous pouvez juste 2065 01:31:06,220 --> 01:31:08,809 voix dans une affaire de secondes? 2066 01:31:08,809 --> 01:31:10,850 RICK HOULIHAN: Nous allons à travers le scénario de vote. 2067 01:31:10,850 --> 01:31:11,670 C'est pas si mal. 2068 01:31:11,670 --> 01:31:14,580 Avez-vous les gars avez quelques minutes? 2069 01:31:14,580 --> 01:31:15,860 D'ACCORD. 2070 01:31:15,860 --> 01:31:17,890 >> Donc, nous allons parler de vote. 2071 01:31:17,890 --> 01:31:20,250 Donc vote en temps réel, nous avons exigences pour voter. 2072 01:31:20,250 --> 01:31:25,250 Les exigences sont que nous permettons chaque personne de voter qu'une seule fois. 2073 01:31:25,250 --> 01:31:28,060 Nous voulons que personne ne soit en mesure de modifier leur vote. 2074 01:31:28,060 --> 01:31:31,045 Nous voulons l'agrégation en temps réel et d'analyse pour la démographie 2075 01:31:31,045 --> 01:31:34,210 que nous allons être montrant aux utilisateurs sur le site. 2076 01:31:34,210 --> 01:31:35,200 >> Pensez à ce scénario. 2077 01:31:35,200 --> 01:31:37,550 Nous travaillons beaucoup de la réalité TV montre où ils sont 2078 01:31:37,550 --> 01:31:38,960 faire ce type exacte des choses. 2079 01:31:38,960 --> 01:31:41,584 Alors vous pouvez penser le scénario, nous avons des millions et des millions 2080 01:31:41,584 --> 01:31:43,959 là les filles de l'adolescence avec leurs téléphones cellulaires 2081 01:31:43,959 --> 01:31:46,250 et le vote et le vote, et voter pour qui ils sont 2082 01:31:46,250 --> 01:31:48,610 trouver d'être le plus populaire. 2083 01:31:48,610 --> 01:31:50,830 Donc, ce sont quelques-uns des exigences nous manquons. 2084 01:31:50,830 --> 01:31:52,990 >> Et donc la première prendre à résoudre ce problème 2085 01:31:52,990 --> 01:31:55,090 serait de construire un application très simple. 2086 01:31:55,090 --> 01:31:56,490 Donc, je dois cette application. 2087 01:31:56,490 --> 01:31:57,950 Je dois certains électeurs là-bas. 2088 01:31:57,950 --> 01:31:59,980 Ils viennent, ils ont frappé l'application de vote. 2089 01:31:59,980 --> 01:32:03,440 Je dois une certaine table votes premières Je vais simplement vider ces votes en. 2090 01:32:03,440 --> 01:32:05,780 Je vais devoir certains agrégats table de votes que 2091 01:32:05,780 --> 01:32:09,490 ferai de mon analyse et de la démographie, et nous allons mettre tout cela là-dedans. 2092 01:32:09,490 --> 01:32:11,420 >> Et ce qui est excellent. 2093 01:32:11,420 --> 01:32:12,332 La vie est belle. 2094 01:32:12,332 --> 01:32:15,040 La vie est bonne jusqu'à ce que nous découvrons que il ya toujours un ou deux seulement 2095 01:32:15,040 --> 01:32:16,879 les gens qui sont populaires à une élection. 2096 01:32:16,879 --> 01:32:19,420 Il ya seulement une ou deux choses que les gens se soucient vraiment. 2097 01:32:19,420 --> 01:32:22,340 Et si vous allez voter à échelle, tout d'un coup je suis 2098 01:32:22,340 --> 01:32:26,360 aller à marteler l'enfer hors de deux candidats, un ou deux candidats. 2099 01:32:26,360 --> 01:32:29,390 Un nombre très limité d'articles les gens trouvent à être populaire. 2100 01:32:29,390 --> 01:32:31,710 >> Ce ne sont pas un bon modèle de conception. 2101 01:32:31,710 --> 01:32:33,549 Ceci est en fait une très mauvais design pattern 2102 01:32:33,549 --> 01:32:36,340 parce qu'elle crée exactement ce que nous parlé qui était touches de raccourci. 2103 01:32:36,340 --> 01:32:38,960 Touches de raccourci sont quelque chose que nous ne voulons pas. 2104 01:32:38,960 --> 01:32:40,470 >> Alors, comment pouvons-nous résoudre ce problème? 2105 01:32:40,470 --> 01:32:47,640 Et vraiment, la façon de résoudre ce problème est en prenant ces seaux candidats 2106 01:32:47,640 --> 01:32:51,490 et pour chacun des candidats, nous avons, nous allons ajouter une valeur aléatoire, 2107 01:32:51,490 --> 01:32:54,192 quelque chose que nous savons, aléatoire valeur comprise entre un et 100, 2108 01:32:54,192 --> 01:32:56,620 entre 100 et 1000, ou entre une et 1000, 2109 01:32:56,620 --> 01:32:59,940 Cependant de nombreuses valeurs aléatoires que vous voulez ajouter sur l'extrémité de ce candidat. 2110 01:32:59,940 --> 01:33:01,330 >> Et qu'ai-je vraiment fait alors? 2111 01:33:01,330 --> 01:33:05,830 Si je suis en utilisant l'ID de candidat le seau pour ensemble des voix, 2112 01:33:05,830 --> 01:33:08,780 si je l'ai ajouté un hasard nombre à la fin de cette, 2113 01:33:08,780 --> 01:33:12,000 Je ai créé maintenant 10 seaux, un cent mille seaux, seaux 2114 01:33:12,000 --> 01:33:14,160 que je agrégation votes travers. 2115 01:33:14,160 --> 01:33:18,030 >> Donc je dois millions et des millions, et des millions de disques à venir dans 2116 01:33:18,030 --> 01:33:22,050 pour ces candidats, je suis répand maintenant ces votes à travers A_1 candidat 2117 01:33:22,050 --> 01:33:24,630 A_100 travers du candidat, parce chaque fois un vote arrive, 2118 01:33:24,630 --> 01:33:26,530 Je générer un hasard valeur comprise entre un et 100. 2119 01:33:26,530 --> 01:33:29,446 Je clouant sur la fin de la candidat à cette personne de voter pour. 2120 01:33:29,446 --> 01:33:31,120 Je le déverser dans le seau. 2121 01:33:31,120 --> 01:33:33,910 >> Maintenant, sur le dos, je sais que je me suis une centaine de seaux. 2122 01:33:33,910 --> 01:33:36,350 Alors, quand je veux aller de l'avant et agréger les votes, 2123 01:33:36,350 --> 01:33:38,244 Je lis de tous ces seaux. 2124 01:33:38,244 --> 01:33:39,160 Donc, je vais de l'avant et ajouter. 2125 01:33:39,160 --> 01:33:42,410 Et puis je ne comprends la dispersion où je sors et dis hey, 2126 01:33:42,410 --> 01:33:45,399 vous savez quoi, la clé de ce candidat espaces est plus d'une centaine seaux. 2127 01:33:45,399 --> 01:33:47,940 Je vais rassembler tous les les votes de ces cent seaux. 2128 01:33:47,940 --> 01:33:49,981 Je vais regrouper eux et je vais dire, 2129 01:33:49,981 --> 01:33:53,830 Un candidat a maintenant vote compte total de x. 2130 01:33:53,830 --> 01:33:55,690 >> Maintenant, les deux l'écriture requête et la requête de lecture 2131 01:33:55,690 --> 01:33:58,160 sont bien distribués parce que je vous écris pour 2132 01:33:58,160 --> 01:34:00,320 et je lis à travers des centaines de clés. 2133 01:34:00,320 --> 01:34:03,500 Je ne suis pas l'écriture et la lecture à travers une clé maintenant. 2134 01:34:03,500 --> 01:34:04,950 Voilà donc un excellent modèle. 2135 01:34:04,950 --> 01:34:08,090 >> Ceci est en fait probablement l'un de la conception la plus importante 2136 01:34:08,090 --> 01:34:10,420 modèles pour échelle dans NoSQL. 2137 01:34:10,420 --> 01:34:14,470 Vous verrez ce type de modèle de conception dans chaque saveur. 2138 01:34:14,470 --> 01:34:19,100 MongoDB, DynamoDB, il ne fait pas la matière, nous avons tous à faire. 2139 01:34:19,100 --> 01:34:21,840 Parce que quand vous avez affaire avec ces énormes rassemblements, 2140 01:34:21,840 --> 01:34:26,650 vous devez trouver un moyen de les étaler dans des seaux. 2141 01:34:26,650 --> 01:34:29,512 Donc, cela est la façon dont vous le faites. 2142 01:34:29,512 --> 01:34:31,220 Très bien, alors ce vous faites en ce moment 2143 01:34:31,220 --> 01:34:35,252 est que vous êtes négoce hors lecture le coût pour l'écriture évolutivité. 2144 01:34:35,252 --> 01:34:37,085 Le coût de ma lecture est un peu plus complexe 2145 01:34:37,085 --> 01:34:40,220 et je dois aller lire à partir d'un cent des seaux au lieu d'un. 2146 01:34:40,220 --> 01:34:41,310 Mais je suis capable d'écrire. 2147 01:34:41,310 --> 01:34:44,860 Et mon débit, mon écriture débit est incroyable. 2148 01:34:44,860 --> 01:34:49,450 Donc, il est généralement une précieuse technique de mise à l'échelle DynamoDB, 2149 01:34:49,450 --> 01:34:51,350 ou de toute base de données NoSQL pour cette question. 2150 01:34:51,350 --> 01:34:53,824 2151 01:34:53,824 --> 01:34:55,240 Donc, nous avons compris comment à l'échelle il. 2152 01:34:55,240 --> 01:34:56,930 Et nous avons pensé comment éliminer nos touches de raccourci. 2153 01:34:56,930 --> 01:34:57,820 Et cela est fantastique. 2154 01:34:57,820 --> 01:34:58,960 Et nous avons eu cette belle système. 2155 01:34:58,960 --> 01:35:02,043 Et il nous a donné le vote très correct parce que nous avons vote fiche de-dupe. 2156 01:35:02,043 --> 01:35:03,130 Il est construit dans DynamoDB. 2157 01:35:03,130 --> 01:35:05,380 Nous avons parlé des droits conditionnels. 2158 01:35:05,380 --> 01:35:08,170 >> Quand un électeur vient dans, puts un insert sur la table, 2159 01:35:08,170 --> 01:35:11,220 ils insèrent leur carte d'identité avec des électeurs, si elles essaient d'insérer un autre vote, 2160 01:35:11,220 --> 01:35:13,320 Je fais une écriture conditionnelle. 2161 01:35:13,320 --> 01:35:16,960 Dites seulement écrire ce si cela ne existe pas. 2162 01:35:16,960 --> 01:35:19,270 Donc dès que je vois que ce vote allons frapper la table, 2163 01:35:19,270 --> 01:35:20,460 personne d'autre va être en mesure de mettre leur vote. 2164 01:35:20,460 --> 01:35:21,634 Et cela est fantastique. 2165 01:35:21,634 --> 01:35:23,550 Et nous incrémentation nos comptoirs de candidats. 2166 01:35:23,550 --> 01:35:25,466 Et nous faisons de notre démographie et tout ça. 2167 01:35:25,466 --> 01:35:29,110 Mais qu'advient-il si mon demande tombe? 2168 01:35:29,110 --> 01:35:31,350 Maintenant, tout d'un soudaines votes sont à venir, et je 2169 01:35:31,350 --> 01:35:34,840 ne sais pas si ils se traitées dans mes analyses et démographie 2170 01:35:34,840 --> 01:35:36,040 plus. 2171 01:35:36,040 --> 01:35:38,462 Et lorsque l'application revient, comment 2172 01:35:38,462 --> 01:35:41,420 l'enfer que je sais ce votes ont été traitées et où dois-je commencer? 2173 01:35:41,420 --> 01:35:44,530 >> Donc, cela est un réel problème lorsque vous commencer à regarder ce type de scénario. 2174 01:35:44,530 --> 01:35:45,571 Et comment pouvons-nous résoudre cela? 2175 01:35:45,571 --> 01:35:48,070 Nous résolvons avec ce que nous appeler DynamoDB Streams. 2176 01:35:48,070 --> 01:35:53,470 Streams est un temps ordonné et partitionné journal de changement de tous les accès 2177 01:35:53,470 --> 01:35:55,700 à la table, chaque écriture accès à la table. 2178 01:35:55,700 --> 01:35:58,810 Toutes les données qui est écrit à la tableau montre sur le flux. 2179 01:35:58,810 --> 01:36:01,815 >> Il est fondamentalement une file d'attente de 24 heures. 2180 01:36:01,815 --> 01:36:03,690 Articles frappé le flux, ils vivent pendant 24 heures. 2181 01:36:03,690 --> 01:36:05,990 Ils peuvent être lus plusieurs fois. 2182 01:36:05,990 --> 01:36:09,400 Garanti pour être livrés une seule fois dans le flux, 2183 01:36:09,400 --> 01:36:11,180 pouvait-on lire n certain nombre de fois. 2184 01:36:11,180 --> 01:36:14,910 Donc, cependant le nombre de processus que vous voulez consommer que les données, vous pouvez consommer. 2185 01:36:14,910 --> 01:36:16,350 Il apparaîtra à chaque mise à jour. 2186 01:36:16,350 --> 01:36:18,455 Chaque écriture sera seulement apparaître une fois sur le flux. 2187 01:36:18,455 --> 01:36:20,621 Donc, vous ne devez pas vous inquiéter sur le traitement deux fois 2188 01:36:20,621 --> 01:36:22,500 à partir du même processus. 2189 01:36:22,500 --> 01:36:25,350 >> Il est strictement commandé par article. 2190 01:36:25,350 --> 01:36:28,180 Quand nous disons que le temps ordonné et partagé, 2191 01:36:28,180 --> 01:36:30,680 vous verrez par partition sur le flux. 2192 01:36:30,680 --> 01:36:33,169 Vous verrez articles, mises à jour dans l'ordre. 2193 01:36:33,169 --> 01:36:35,210 Nous ne sommes pas garantissons sur le flux que vous êtes 2194 01:36:35,210 --> 01:36:40,240 allez obtenir toutes les transactions dans l'ordre entre les items. 2195 01:36:40,240 --> 01:36:42,440 >> Donc, les ruisseaux sont idempotent. 2196 01:36:42,440 --> 01:36:44,037 Devons-nous savons tous ce que signifie idempotent? 2197 01:36:44,037 --> 01:36:46,620 Idempotent signifie que vous pouvez faire plus, et plus, et plus encore. 2198 01:36:46,620 --> 01:36:48,200 Le résultat va être la même chose. 2199 01:36:48,200 --> 01:36:49,991 >> Les flux sont idempotent, mais ils doivent être 2200 01:36:49,991 --> 01:36:54,860 joué du point de départ, où que vous choisissez, à la fin, 2201 01:36:54,860 --> 01:36:57,950 ou ils ne seront pas résulter dans les mêmes valeurs. 2202 01:36:57,950 --> 01:36:59,727 >> Même chose avec MongoDB. 2203 01:36:59,727 --> 01:37:01,560 MongoDB a une construction qu'ils appellent le oplog. 2204 01:37:01,560 --> 01:37:04,140 Il est de la même construction exacte. 2205 01:37:04,140 --> 01:37:06,500 Bases de données NoSQL Beaucoup cette construction. 2206 01:37:06,500 --> 01:37:08,790 Ils l'utilisent pour faire des choses comme la réplication, ce qui 2207 01:37:08,790 --> 01:37:10,475 est exactement ce que nous faisons avec des ruisseaux. 2208 01:37:10,475 --> 01:37:12,350 AUDIENCE: Peut-être un question hérétique, mais vous 2209 01:37:12,350 --> 01:37:13,975 parler applications faisant descendre un ainsi de suite. 2210 01:37:13,975 --> 01:37:16,089 Sont des flux garantis jamais peut-être aller vers le bas? 2211 01:37:16,089 --> 01:37:18,630 RICK HOULIHAN: Ouais, les ruisseaux sont garantis de ne jamais descendre. 2212 01:37:18,630 --> 01:37:21,040 Nous gérons l'infrastructure derrière. automatique des flux 2213 01:37:21,040 --> 01:37:22,498 déployer dans leur groupe de mise à l'échelle automatique. 2214 01:37:22,498 --> 01:37:25,910 Nous allons passer par un peu peu de ce qui se passe. 2215 01:37:25,910 --> 01:37:30,060 >> Je ne devrais pas dire qu'ils ne sont pas garantie de ne jamais descendre. 2216 01:37:30,060 --> 01:37:33,110 Les éléments sont garantis à apparaître dans le courant. 2217 01:37:33,110 --> 01:37:36,740 Et le flux sera accessible. 2218 01:37:36,740 --> 01:37:40,580 Donc ce qui se passe vers le bas ou revient jusqu'à, ce qui se passe en dessous. 2219 01:37:40,580 --> 01:37:43,844 Il désigne: il est OK. 2220 01:37:43,844 --> 01:37:46,260 Très bien, alors vous obtenez différente Voir les types hors de l'écran. 2221 01:37:46,260 --> 01:37:51,040 Les types de vue qui sont importantes pour un programmeur sont généralement, qu'est-ce? 2222 01:37:51,040 --> 01:37:52,370 Je reçois l'ancienne vue. 2223 01:37:52,370 --> 01:37:55,630 Lorsqu'une mise à jour sur la table, ça va pousser l'ancienne vue au flux 2224 01:37:55,630 --> 01:38:02,070 afin que les données peuvent archiver, ou de changement le contrôle, le changement identification, le changement 2225 01:38:02,070 --> 01:38:03,600 la gestion. 2226 01:38:03,600 --> 01:38:07,160 >> La nouvelle image, ce qu'elle est maintenant, après la mise à jour, qui est un autre type de vue 2227 01:38:07,160 --> 01:38:07,660 Tu peux recevoir. 2228 01:38:07,660 --> 01:38:09,660 Vous pouvez obtenir à la fois les anciennes et les nouvelles images. 2229 01:38:09,660 --> 01:38:10,660 Peut-être que je les veux à la fois. 2230 01:38:10,660 --> 01:38:11,790 Je veux voir ce qu'il était. 2231 01:38:11,790 --> 01:38:13,290 Je veux voir ce que cela a changé pour. 2232 01:38:13,290 --> 01:38:15,340 >> Je dois un type de conformité des processus qui exécute. 2233 01:38:15,340 --> 01:38:17,430 Il convient de vérifier que quand ces choses changent, 2234 01:38:17,430 --> 01:38:21,840 qu'ils sont dans certaines limites ou à l'intérieur de certains paramètres. 2235 01:38:21,840 --> 01:38:23,840 >> Et puis peut-être que je ne besoin de savoir ce qui a changé. 2236 01:38:23,840 --> 01:38:26,240 Je ne me soucie pas de ce que l'article modifié. 2237 01:38:26,240 --> 01:38:28,580 Je ne dois pas besoin de savoir ce attributs modifiés. 2238 01:38:28,580 --> 01:38:30,882 Je dois juste savoir que les articles sont touchés. 2239 01:38:30,882 --> 01:38:33,340 Donc, ce sont les types de vues que vous descendez le courant 2240 01:38:33,340 --> 01:38:35,960 et vous pouvez interagir avec. 2241 01:38:35,960 --> 01:38:37,840 >> L'application qui consomme le flux, 2242 01:38:37,840 --> 01:38:39,298 cela est une sorte de la façon dont cela fonctionne. 2243 01:38:39,298 --> 01:38:42,570 Client DynamoDB demander de des données vers les tables. 2244 01:38:42,570 --> 01:38:44,750 Streams déployer sur ce que nous appelons tessons. 2245 01:38:44,750 --> 01:38:47,380 Shards sont redimensionnées indépendamment de la table. 2246 01:38:47,380 --> 01:38:50,660 Ils ne sont pas alignés complètement les partitions de votre table. 2247 01:38:50,660 --> 01:38:52,540 Et la raison pour laquelle est parce qu'ils alignent 2248 01:38:52,540 --> 01:38:55,430 à la capacité, le courant la capacité de la table. 2249 01:38:55,430 --> 01:38:57,600 >> Ils se déploient dans leur propre groupe de mise à l'échelle automatique, 2250 01:38:57,600 --> 01:39:00,800 et ils commencent à tourner hors fonction sur le nombre d'écritures sont à venir dans, 2251 01:39:00,800 --> 01:39:03,090 combien reads-- vraiment qu'il est écrit. 2252 01:39:03,090 --> 01:39:05,820 Il n'y a pas reads-- mais comment de nombreuses écritures arrivent. 2253 01:39:05,820 --> 01:39:08,200 >> Et puis sur le dos fin, nous avons ce que nous 2254 01:39:08,200 --> 01:39:11,390 appeler un KCL ou Client Library Kinesis. 2255 01:39:11,390 --> 01:39:19,190 Kinesis est un flux de données la technologie de traitement d'Amazon. 2256 01:39:19,190 --> 01:39:22,040 Et flux est construit sur cela. 2257 01:39:22,040 --> 01:39:25,670 >> Donc, vous utilisez un KCL activé application de lire le flux. 2258 01:39:25,670 --> 01:39:28,752 Le Client Library Kinesis effectivement gère les travailleurs pour vous. 2259 01:39:28,752 --> 01:39:30,460 Et il fait aussi de la choses intéressantes. 2260 01:39:30,460 --> 01:39:35,630 Il va créer quelques tables jusqu'à dans votre DynamoDB tablespace 2261 01:39:35,630 --> 01:39:38,410 pour suivre quels articles ont été traitées. 2262 01:39:38,410 --> 01:39:41,190 Ainsi de cette façon si elle tombe en arrière, si il tombe et vient et obtient 2263 01:39:41,190 --> 01:39:45,570 se releva, il peut déterminer où était dans le traitement du flux. 2264 01:39:45,570 --> 01:39:48,360 >> Cela est très important lorsque vous parlez de la réplication. 2265 01:39:48,360 --> 01:39:50,350 Je dois savoir ce que a été traitée données 2266 01:39:50,350 --> 01:39:52,810 et quelles données n'a pas encore été traitée. 2267 01:39:52,810 --> 01:39:57,380 Donc, la bibliothèque KCL pour les flux volonté vous donner beaucoup de cette fonctionnalité. 2268 01:39:57,380 --> 01:39:58,990 Il prend soin de tout le ménage. 2269 01:39:58,990 --> 01:40:01,140 Il se lève un travailleur pour chaque fragment. 2270 01:40:01,140 --> 01:40:04,620 Il crée une table administrative pour chaque fragment, pour chaque travailleur. 2271 01:40:04,620 --> 01:40:07,560 Et que ceux des travailleurs feu, ils maintiennent ces tables 2272 01:40:07,560 --> 01:40:10,510 si vous savez ce disque a été lu et traité. 2273 01:40:10,510 --> 01:40:13,850 Et puis cette façon si le processus meurt et revient en ligne, 2274 01:40:13,850 --> 01:40:17,940 il peut reprendre là où il a décollé. 2275 01:40:17,940 --> 01:40:20,850 >> Donc, nous utilisons ce pour contre-région réplication. 2276 01:40:20,850 --> 01:40:24,680 Beaucoup de clients ont la nécessité de déplacer des données ou des parties de tableaux de données 2277 01:40:24,680 --> 01:40:25,920 autour de différentes régions. 2278 01:40:25,920 --> 01:40:29,230 Il ya neuf régions dans le monde entier. 2279 01:40:29,230 --> 01:40:32,100 Donc il pourrait y avoir un I need-- pourraient avoir les utilisateurs en Asie, les utilisateurs 2280 01:40:32,100 --> 01:40:34,150 dans la côte Est des États-Unis. 2281 01:40:34,150 --> 01:40:38,980 Ils ont des données différentes qui doit être distribuée localement. 2282 01:40:38,980 --> 01:40:42,510 Et peut-être un utilisateur d'oiseau de Asie vers les Etats-Unis, 2283 01:40:42,510 --> 01:40:45,020 et je tiens à répliquer ses données avec lui. 2284 01:40:45,020 --> 01:40:49,340 Alors, quand il descend de l'avion, il a une bonne expérience de l'utilisation de son application mobile. 2285 01:40:49,340 --> 01:40:52,360 >> Vous pouvez utiliser la croix-région bibliothèque de réplication pour ce faire. 2286 01:40:52,360 --> 01:40:55,730 Fondamentalement, nous avons fourni deux technologies. 2287 01:40:55,730 --> 01:40:59,400 Un est une application de la console, vous pouvez se tenir debout sur votre propre instance EC2. 2288 01:40:59,400 --> 01:41:01,240 Il fonctionne réplication pure. 2289 01:41:01,240 --> 01:41:02,720 Et puis nous vous avons donné la bibliothèque. 2290 01:41:02,720 --> 01:41:06,070 La bibliothèque vous pouvez utiliser pour construire votre propre application si vous 2291 01:41:06,070 --> 01:41:10,740 vouloir faire des choses folles avec ce data-- filtre, reproduire une partie seulement de celui-ci, 2292 01:41:10,740 --> 01:41:14,120 pivoter les données, le déplacer dans un table différente, ainsi de suite et ainsi de suite. 2293 01:41:14,120 --> 01:41:18,700 2294 01:41:18,700 --> 01:41:20,520 Voilà donc le genre de ce qui ressemble. 2295 01:41:20,520 --> 01:41:23,690 >> DynamoDB flux peuvent être traitées par ce que nous appelons Lambda. 2296 01:41:23,690 --> 01:41:27,394 Nous avons mentionné un peu plus sur l'événement architectures applicatives entraînés. 2297 01:41:27,394 --> 01:41:28,810 Lambda est un élément clé de cette. 2298 01:41:28,810 --> 01:41:32,840 Lambda est le code qui se déclenche à la demande en réponse à un événement particulier. 2299 01:41:32,840 --> 01:41:36,020 L'un de ces événements pourrait être un dossier apparaissant sur le flux. 2300 01:41:36,020 --> 01:41:39,100 Si un enregistrement apparaît sur le flux, nous appelons cette fonction Java. 2301 01:41:39,100 --> 01:41:44,980 Eh bien, ce que JavaScript et Lambda soutient Node.js, Java, Python, 2302 01:41:44,980 --> 01:41:47,820 et va bientôt soutenir d'autres langues aussi. 2303 01:41:47,820 --> 01:41:50,940 Et il suffit de dire, il est pur code. 2304 01:41:50,940 --> 01:41:53,610 écrite en Java, vous définissez une classe. 2305 01:41:53,610 --> 01:41:55,690 Vous poussez le JAR haut dans Lambda. 2306 01:41:55,690 --> 01:42:00,200 Et puis vous spécifiez quelle classe d'appeler en réponse à laquelle événement. 2307 01:42:00,200 --> 01:42:04,770 Et puis l'infrastructure Lambda derrière qui se déroulera ce code. 2308 01:42:04,770 --> 01:42:06,730 >> Ce code peut traiter enregistrements hors du flux. 2309 01:42:06,730 --> 01:42:08,230 Il peut faire ce qu'il veut avec elle. 2310 01:42:08,230 --> 01:42:11,650 Dans cet exemple particulier, tout ce que nous sommes vraiment faire est connecter les attributs. 2311 01:42:11,650 --> 01:42:13,480 Mais cela est tout simplement le code. 2312 01:42:13,480 --> 01:42:15,260 Code peut faire quelque chose, non? 2313 01:42:15,260 --> 01:42:16,600 >> Donc vous pouvez faire pivoter ces données. 2314 01:42:16,600 --> 01:42:18,160 Vous pouvez créer une vue dérivée. 2315 01:42:18,160 --> 01:42:21,160 Si il est une structure de document, vous pouvez aplatir la structure. 2316 01:42:21,160 --> 01:42:24,300 Vous pouvez créer des index suppléants. 2317 01:42:24,300 --> 01:42:27,100 Toutes sortes de choses que vous pouvez faire avec les Streams DynamoDB. 2318 01:42:27,100 --> 01:42:28,780 >> Et vraiment, voilà à quoi ça ressemble. 2319 01:42:28,780 --> 01:42:29,940 Ainsi, vous obtenez les mises à jour à venir dans. 2320 01:42:29,940 --> 01:42:31,190 Ils arrivent au large de la chaîne. 2321 01:42:31,190 --> 01:42:32,720 Ils sont lus par la fonction Lambda. 2322 01:42:32,720 --> 01:42:37,480 Ils sont en rotation les données et poussant vers le haut dans les tableaux dérivés, 2323 01:42:37,480 --> 01:42:42,200 notifient les systèmes externes de changement, et en poussant des données dans ElastiCache. 2324 01:42:42,200 --> 01:42:45,900 >> Nous avons parlé de la façon de mettre le cache en face de la base de données pour que les ventes 2325 01:42:45,900 --> 01:42:46,450 scénario. 2326 01:42:46,450 --> 01:42:50,049 Eh bien ce qui se passe si je mettre à jour la description de l'article? 2327 01:42:50,049 --> 01:42:52,340 Eh bien, si je devais un Lambda la fonction en cours d'exécution sur cette table, 2328 01:42:52,340 --> 01:42:55,490 si je mets à jour la description de l'article, il va ramasser la fiche hors du flux, 2329 01:42:55,490 --> 01:42:58,711 et il va mettre à jour le ElastiCache exemple avec les nouvelles données. 2330 01:42:58,711 --> 01:43:00,460 Voilà donc un grand nombre de ce que nous faisons avec Lambda. 2331 01:43:00,460 --> 01:43:02,619 Il est le code de la colle, des connecteurs. 2332 01:43:02,619 --> 01:43:04,410 Et il donne en réalité la capacité de lancer 2333 01:43:04,410 --> 01:43:07,930 et d'exécuter des applications très complexes sans un serveur dédié 2334 01:43:07,930 --> 01:43:10,371 infrastructures, ce qui est vraiment cool. 2335 01:43:10,371 --> 01:43:13,100 >> Donc, revenons à notre en temps réel de l'architecture de vote. 2336 01:43:13,100 --> 01:43:17,984 Ceci est nouveau et amélioré avec notre ruisseaux et KCL permis application. 2337 01:43:17,984 --> 01:43:20,150 Comme avant, nous pouvons gérer toute échelle de l'élection. 2338 01:43:20,150 --> 01:43:21,100 Nous aimons ça. 2339 01:43:21,100 --> 01:43:24,770 Nous faisons des fronces de dispersion sur plusieurs godets. 2340 01:43:24,770 --> 01:43:26,780 Nous avons verrouillage optimiste passe. 2341 01:43:26,780 --> 01:43:30,192 Nous pouvons garder nos électeurs de modifier leurs votes. 2342 01:43:30,192 --> 01:43:31,400 Ils ne peuvent voter qu'une seule fois. 2343 01:43:31,400 --> 01:43:32,880 C'est fantastique. 2344 01:43:32,880 --> 01:43:35,895 Tolérance de panne en temps réel, agrégation évolutive maintenant. 2345 01:43:35,895 --> 01:43:38,270 Si la chose tombe, il sait où se relancer 2346 01:43:38,270 --> 01:43:41,300 quand il revient parce que nous utilisons l'application KCL. 2347 01:43:41,300 --> 01:43:45,700 Et puis nous pouvons également utiliser cette Demande KCL à pousser sur des données 2348 01:43:45,700 --> 01:43:48,820 Redshift à d'autres analyse d'applications, ou de l'utilisation 2349 01:43:48,820 --> 01:43:51,990 les MapReduce élastiques à courir streaming en temps réel hors agrégations 2350 01:43:51,990 --> 01:43:53,180 de ces données. 2351 01:43:53,180 --> 01:43:55,480 >> Donc, ce sont des choses que nous ont pas beaucoup parlé. 2352 01:43:55,480 --> 01:43:57,375 Mais ils sont plus technologies qui viennent 2353 01:43:57,375 --> 01:44:00,310 à porter lorsque vous êtes à la recherche à ces types de scénarios. 2354 01:44:00,310 --> 01:44:03,160 >> Très bien, alors que ce sujet de Analytics avec DynamoDB Streams. 2355 01:44:03,160 --> 01:44:05,340 Vous pouvez gagner de-dupe les données, faire toutes sortes 2356 01:44:05,340 --> 01:44:09,490 des trucs sympa, les données agrégées dans la mémoire, de créer ces tables dérivés. 2357 01:44:09,490 --> 01:44:13,110 Voilà un énorme cas d'utilisation que beaucoup de clients 2358 01:44:13,110 --> 01:44:16,950 sont impliqués avec, en prenant le imbriquée propriétés de ces documents JSON 2359 01:44:16,950 --> 01:44:18,946 et la création d'index supplémentaires. 2360 01:44:18,946 --> 01:44:21,680 2361 01:44:21,680 --> 01:44:23,150 >> Nous sommes à la fin. 2362 01:44:23,150 --> 01:44:26,689 Merci pour porter avec moi. 2363 01:44:26,689 --> 01:44:28,480 Alors parlons architecture de référence. 2364 01:44:28,480 --> 01:44:33,440 DynamoDB se trouve au milieu de tant une grande partie de l'infrastructure AWS. 2365 01:44:33,440 --> 01:44:37,090 Fondamentalement, vous pouvez le brancher jusqu'à ce que vous voulez. 2366 01:44:37,090 --> 01:44:45,600 Les applications créées à l'aide Dynamo comprennent Lambda, ElastiCache, CloudSearch, 2367 01:44:45,600 --> 01:44:49,890 pousser les données dehors dans Elastic MapReduce, import export de DynamoDB 2368 01:44:49,890 --> 01:44:52,370 en S3, tous les types de flux de travail. 2369 01:44:52,370 --> 01:44:54,120 Mais sans doute le meilleur chose à parler, 2370 01:44:54,120 --> 01:44:56,119 et ceci est ce qui est vraiment intéressant est lorsque nous 2371 01:44:56,119 --> 01:44:58,350 parler des applications Event Driven. 2372 01:44:58,350 --> 01:45:00,300 >> Ceci est un exemple de un projet interne 2373 01:45:00,300 --> 01:45:04,850 que nous avons où nous sommes effectivement l'édition de recueillir des résultats de l'enquête. 2374 01:45:04,850 --> 01:45:07,700 Ainsi, dans un lien e-mail que nous envoyons, il y 2375 01:45:07,700 --> 01:45:11,350 être un peu cliquez sur le lien en disant ici pour répondre à l'enquête. 2376 01:45:11,350 --> 01:45:14,070 Et quand une personne clics ce lien, ce qui se passe 2377 01:45:14,070 --> 01:45:18,020 est qu'ils renversent une sécurisé HTML formulaire d'enquête à partir de S3. 2378 01:45:18,020 --> 01:45:18,980 Il n'y a pas serveur. 2379 01:45:18,980 --> 01:45:20,600 Ceci est juste un objet S3. 2380 01:45:20,600 --> 01:45:22,770 >> Cette forme apparaît, charges dans le navigateur. 2381 01:45:22,770 --> 01:45:24,240 Il est obtenu Backbone. 2382 01:45:24,240 --> 01:45:30,160 Il faut que ce complexe JavaScript qu'il est en cours d'exécution. 2383 01:45:30,160 --> 01:45:33,557 Donc, il est l'application très riche exécute dans le navigateur du client. 2384 01:45:33,557 --> 01:45:36,390 Ils ne savent pas qu'ils ne sont pas interagir avec un serveur dorsal. 2385 01:45:36,390 --> 01:45:38,220 À ce stade, il est tout navigateur. 2386 01:45:38,220 --> 01:45:41,780 >> Ils publient les résultats à ce nous appelons la passerelle API Amazon. 2387 01:45:41,780 --> 01:45:46,270 Passerelle API est simplement une API web que vous pouvez définir et brancher 2388 01:45:46,270 --> 01:45:47,760 à ce que vous voulez. 2389 01:45:47,760 --> 01:45:50,990 Dans ce cas particulier, nous sommes accroché à une fonction lambda. 2390 01:45:50,990 --> 01:45:54,797 >> Donc mon opération POST est passe avec aucun serveur. 2391 01:45:54,797 --> 01:45:56,380 Fondamentalement, ce que la passerelle API est assis là. 2392 01:45:56,380 --> 01:45:58,770 Il ne me coûte rien tant que les gens commencer à poster à elle, non? 2393 01:45:58,770 --> 01:46:00,269 La fonction lambda se trouve juste là. 2394 01:46:00,269 --> 01:46:03,760 Et cela me coûte rien jusqu'à les gens commencent à le frapper. 2395 01:46:03,760 --> 01:46:07,270 Donc vous pouvez voir, que le volume augmentations, qui est quand les accusations viennent. 2396 01:46:07,270 --> 01:46:09,390 Je ne vais pas tourner un serveur 7/24. 2397 01:46:09,390 --> 01:46:12,310 >> Donc, je tire la forme bas du seau, 2398 01:46:12,310 --> 01:46:15,719 et je posterai via l'API Porte d'entrée dans la fonction Lambda. 2399 01:46:15,719 --> 01:46:17,510 Et puis le Lambda Fonction dit, vous savez 2400 01:46:17,510 --> 01:46:20,600 ce qui, je l'ai obtenu quelques PII, certains informations personnellement identifiables 2401 01:46:20,600 --> 01:46:21,480 dans ces réponses. 2402 01:46:21,480 --> 01:46:23,020 Je me suis commentaires provenant des utilisateurs. 2403 01:46:23,020 --> 01:46:24,230 Je dois adresses e-mail. 2404 01:46:24,230 --> 01:46:26,190 Je dois les noms d'utilisateur. 2405 01:46:26,190 --> 01:46:27,810 >> Permettez-moi de partager ce off. 2406 01:46:27,810 --> 01:46:30,280 Je vais générer des métadonnées hors cette fiche. 2407 01:46:30,280 --> 01:46:32,850 Et je vais pousser le métadonnées dans DynamoDB. 2408 01:46:32,850 --> 01:46:36,059 Et je ne pouvais crypter toutes les données et le pousser dans DynamoDB si je veux. 2409 01:46:36,059 --> 01:46:38,600 Mais il est plus facile pour moi, dans ce utiliser cas, à aller de l'avant d'un mot à dire, 2410 01:46:38,600 --> 01:46:42,800 Je vais pousser les données brutes dans un seau S3 crypté. 2411 01:46:42,800 --> 01:46:47,240 Donc je utiliser construit dans le côté du serveur S3 chiffrement et de gestion des clés d'Amazon 2412 01:46:47,240 --> 01:46:51,600 Service de sorte que je dois une clé qui peut tourner sur un intervalle régulier, 2413 01:46:51,600 --> 01:46:55,010 et je peux protéger que les données PII dans le cadre de l'ensemble de ce flux de travail. 2414 01:46:55,010 --> 01:46:55,870 >> Donc, qu'ai-je fait? 2415 01:46:55,870 --> 01:47:00,397 Je viens déployé ensemble demande, et je ne serveur. 2416 01:47:00,397 --> 01:47:02,980 Alors est-ce que l'événement demande entraînée l'architecture fait pour vous. 2417 01:47:02,980 --> 01:47:05,730 >> Maintenant, si vous pensez le cas d'utilisation pour this-- 2418 01:47:05,730 --> 01:47:08,730 nous avons d'autres clients dont je parle à environ cette architecture exacte qui 2419 01:47:08,730 --> 01:47:14,560 lancer de grandes campagnes phénoménale, qui sont à la recherche sur la question et va, oh mon. 2420 01:47:14,560 --> 01:47:17,840 Parce que maintenant, ils peuvent essentiellement pousser là-bas, 2421 01:47:17,840 --> 01:47:21,900 laisser cette campagne se asseoir là jusqu'à ce qu'il lance, et non 2422 01:47:21,900 --> 01:47:24,400 avoir à se soucier d'une guigne ce genre d'infrastructure 2423 01:47:24,400 --> 01:47:26,120 va être là pour le soutenir. 2424 01:47:26,120 --> 01:47:28,600 Et puis, dès que cette campagne est faite, 2425 01:47:28,600 --> 01:47:31,520 il est comme l'infrastructure va juste immédiatement loin 2426 01:47:31,520 --> 01:47:33,680 car il vraiment a pas d'infrastructure. 2427 01:47:33,680 --> 01:47:35,660 Il est juste le code qui se trouve sur Lambda. 2428 01:47:35,660 --> 01:47:38,560 Il est juste que les données se trouve dans DynamoDB. 2429 01:47:38,560 --> 01:47:41,340 Il est un moyen extraordinaire pour construire des applications. 2430 01:47:41,340 --> 01:47:43,970 >> AUDIENCE: Donc, il est plus éphémère qu'il ne le serait 2431 01:47:43,970 --> 01:47:45,740 si elle a été stockée sur un serveur actuel? 2432 01:47:45,740 --> 01:47:46,823 >> RICK HOULIHAN: Absolument. 2433 01:47:46,823 --> 01:47:49,190 Parce que l'instance du serveur devra être un 7/24. 2434 01:47:49,190 --> 01:47:51,954 Il doit être disponible pour quelqu'un pour répondre à. 2435 01:47:51,954 --> 01:47:52,620 Eh bien devinez quoi? 2436 01:47:52,620 --> 01:47:55,410 S3 est disponible 7/24. 2437 01:47:55,410 --> 01:47:57,100 S3 répond toujours. 2438 01:47:57,100 --> 01:47:59,320 Et S3 est très, très bon à servir des objets. 2439 01:47:59,320 --> 01:48:02,590 Ces objets peuvent être des fichiers HTML, ou Fichiers Javascript, ou ce que vous voulez. 2440 01:48:02,590 --> 01:48:07,430 Vous pouvez courir très riches applications Web sur seaux S3, et les gens le font. 2441 01:48:07,430 --> 01:48:10,160 >> Et pour que l'idée est ici est de sortir de la voie 2442 01:48:10,160 --> 01:48:11,270 nous avons l'habitude de penser à ce sujet. 2443 01:48:11,270 --> 01:48:14,270 Nous avons tous l'habitude de penser en termes de serveurs et hôtes. 2444 01:48:14,270 --> 01:48:16,580 Cela ne concerne pas ça. 2445 01:48:16,580 --> 01:48:19,310 Il est à propos de l'infrastructure code. 2446 01:48:19,310 --> 01:48:22,470 Déployer le code pour le nuage et laissez le nuage exécuté pour vous. 2447 01:48:22,470 --> 01:48:24,980 Et qui est ce que AWS essaie de faire. 2448 01:48:24,980 --> 01:48:29,690 >> AUDIENCE: Donc, votre boîte d'or au milieu de la passerelle API est pas comme serveur, 2449 01:48:29,690 --> 01:48:30,576 mais est just-- 2450 01:48:30,576 --> 01:48:32,850 >> RICK HOULIHAN: Vous pouvez penser de ce que la façade du serveur. 2451 01:48:32,850 --> 01:48:38,040 Tout ce qu'il est est il va prendre un HTTP demander et la carte à un autre processus. 2452 01:48:38,040 --> 01:48:39,192 Voilà tout ce qu'il fait. 2453 01:48:39,192 --> 01:48:41,525 Et dans ce cas, nous allons cartographier à une fonction Lambda. 2454 01:48:41,525 --> 01:48:44,119 2455 01:48:44,119 --> 01:48:45,410 Tout droit, de sorte que tout est je suis arrivé. 2456 01:48:45,410 --> 01:48:46,190 Merci beaucoup. 2457 01:48:46,190 --> 01:48:46,800 Je vous en suis reconnaissant. 2458 01:48:46,800 --> 01:48:48,100 Je sais que nous voulons un peu plus de temps. 2459 01:48:48,100 --> 01:48:49,980 Et nous espérons que vous les gars GOT un peu de l'information 2460 01:48:49,980 --> 01:48:51,410 que vous pouvez emporter aujourd'hui. 2461 01:48:51,410 --> 01:48:53,520 Et je me excuse si je suis allé sur certains de vos têtes, 2462 01:48:53,520 --> 01:48:56,697 mais il ya un bon nombre de connaissances fondamentales fondamentale 2463 01:48:56,697 --> 01:48:58,280 que je pense est très précieux pour vous. 2464 01:48:58,280 --> 01:48:59,825 Je vous remercie de me recevoir. 2465 01:48:59,825 --> 01:49:00,325 [APPLAUDISSEMENTS] 2466 01:49:00,325 --> 01:49:02,619 AUDIENCE: [inaudible] est lorsque vous disiez 2467 01:49:02,619 --> 01:49:05,160 vous avez eu à passer par la chose du début jusqu'à la fin 2468 01:49:05,160 --> 01:49:07,619 pour obtenir les bonnes valeurs ou les mêmes valeurs, 2469 01:49:07,619 --> 01:49:09,410 comment serait les valeurs changer si [inaudible]. 2470 01:49:09,410 --> 01:49:10,480 >> RICK HOULIHAN: Oh, idempotent? 2471 01:49:10,480 --> 01:49:11,800 Comment les valeurs allaient changer? 2472 01:49:11,800 --> 01:49:15,180 Eh bien, parce que si je ne courais pas tout le chemin jusqu'à la fin, 2473 01:49:15,180 --> 01:49:19,770 alors je ne sais pas ce qui change ont été faites dans le dernier mile. 2474 01:49:19,770 --> 01:49:22,144 Il ne va pas être le mêmes données que ce que je voyais. 2475 01:49:22,144 --> 01:49:24,560 AUDIENCE: Oh, si vous venez de ont pas obtenu l'entrée entière. 2476 01:49:24,560 --> 01:49:24,770 RICK HOULIHAN: Droit. 2477 01:49:24,770 --> 01:49:26,895 Vous devez aller du début à la fin, et alors il est 2478 01:49:26,895 --> 01:49:29,280 va être un état cohérent. 2479 01:49:29,280 --> 01:49:31,520 Cool. 2480 01:49:31,520 --> 01:49:35,907 >> Auditoire: Alors, vous nous avez montré DynamoDB peut faire document ou la valeur de clé. 2481 01:49:35,907 --> 01:49:38,740 Et nous avons passé beaucoup de temps sur le valeur de la clé avec un hachage et les moyens 2482 01:49:38,740 --> 01:49:40,005 pour la retourner autour. 2483 01:49:40,005 --> 01:49:43,255 Lorsque vous avez regardé ces tableaux, est que laissant derrière lui l'approche de document? 2484 01:49:43,255 --> 01:49:44,600 >> RICK HOULIHAN: Je ne voudrais pas dire laisser derrière eux. 2485 01:49:44,600 --> 01:49:45,855 >> AUDIENCE: Ils ont été séparés de the-- 2486 01:49:45,855 --> 01:49:49,140 >> RICK HOULIHAN: Avec le document approche, le type de document dans DynamoDB 2487 01:49:49,140 --> 01:49:50,880 est il suffit de penser comme un autre attribut. 2488 01:49:50,880 --> 01:49:53,560 Il est un attribut qui contient une structure de données hiérarchique. 2489 01:49:53,560 --> 01:49:56,980 Et puis dans les requêtes, vous pouvez utiliser les propriétés 2490 01:49:56,980 --> 01:49:59,480 de ces objets à l'aide Object Notation. 2491 01:49:59,480 --> 01:50:03,562 Donc, je peux filtrer sur un imbriquée propriété du document JSON. 2492 01:50:03,562 --> 01:50:05,520 Auditoire: Alors, chaque fois que je faire une approche de documents, 2493 01:50:05,520 --> 01:50:07,906 Je peux sorte d'arriver à l'tabular-- 2494 01:50:07,906 --> 01:50:08,780 AUDIENCE: Absolument. 2495 01:50:08,780 --> 01:50:09,800 Audience: --indexes et choses que vous venez de parler. 2496 01:50:09,800 --> 01:50:11,280 RICK HOULIHAN: Ouais, le index et tout ce qui, 2497 01:50:11,280 --> 01:50:13,363 lorsque vous souhaitez indexer le propriétés du JSON, 2498 01:50:13,363 --> 01:50:18,230 la façon dont nous aurions à faire est si vous insérez un objet JSON ou un document 2499 01:50:18,230 --> 01:50:20,780 en Dynamo, vous souhaitez utiliser les flux. 2500 01:50:20,780 --> 01:50:22,400 Streams liraient l'entrée. 2501 01:50:22,400 --> 01:50:24,340 Vous obtiendrez ce que JSON objet et vous diriez OK, 2502 01:50:24,340 --> 01:50:26,030 ce qui est la propriété Je veux à l'index? 2503 01:50:26,030 --> 01:50:28,717 >> Vous créez une table dérivée. 2504 01:50:28,717 --> 01:50:30,300 Maintenant que est la façon dont cela fonctionne en ce moment. 2505 01:50:30,300 --> 01:50:32,650 Nous ne vous permettons pas à l'index directement ces propriétés. 2506 01:50:32,650 --> 01:50:33,520 >> AUDIENCE: Tabularizing vos documents. 2507 01:50:33,520 --> 01:50:36,230 >> RICK HOULIHAN: Exactement, aplatissement il, tabularizing il, exactement. 2508 01:50:36,230 --> 01:50:37,415 Voilà ce que vous faites avec lui. 2509 01:50:37,415 --> 01:50:37,860 >> AUDIENCE: Je vous remercie. 2510 01:50:37,860 --> 01:50:39,609 >> RICK HOULIHAN: Yep, absolument, je vous remercie. 2511 01:50:39,609 --> 01:50:42,240 Auditoire: Alors, il est une sorte de Mongo rencontre classifers Redis. 2512 01:50:42,240 --> 01:50:43,990 >> RICK HOULIHAN: Ouais, il est un peu comme ça. 2513 01:50:43,990 --> 01:50:45,940 Voilà une bonne description pour elle. 2514 01:50:45,940 --> 01:50:47,490 Cool. 2515 01:50:47,490 --> 01:50:49,102