1 00:00:00,000 --> 00:00:04,969 >> [REPRODUCCIÓ DE MÚSICA] 2 00:00:04,969 --> 00:00:06,010 RICK Houlihan: D'acord. 3 00:00:06,010 --> 00:00:06,600 Hola a tothom. 4 00:00:06,600 --> 00:00:07,670 El meu nom és Rick Houlihan. 5 00:00:07,670 --> 00:00:10,330 Jo sóc un director d'alt nivell arquitecte de solucions de AWS. 6 00:00:10,330 --> 00:00:14,070 Em concentro en NoSQL i Tecnologies DynamoDB. 7 00:00:14,070 --> 00:00:16,930 Estic avui aquí per parlar que una mica sobre ells. 8 00:00:16,930 --> 00:00:18,970 >> La meva formació és principalment a la capa de dades. 9 00:00:18,970 --> 00:00:21,390 Vaig passar la meitat del meu desenvolupament carrera escrivint base de dades, 10 00:00:21,390 --> 00:00:25,930 d'accés a dades, solucions per a diverses aplicacions. 11 00:00:25,930 --> 00:00:30,000 He estat a la virtualització del núvol durant uns 20 anys. 12 00:00:30,000 --> 00:00:33,460 Així que abans que el núvol era Núvol, solíem dir-utility computing. 13 00:00:33,460 --> 00:00:37,170 I la idea va ser, és com PG & E, que paga pel que fa servir. 14 00:00:37,170 --> 00:00:38,800 Avui en diem el núvol. 15 00:00:38,800 --> 00:00:41,239 >> Però amb els anys, he treballat durant un parell d'empreses 16 00:00:41,239 --> 00:00:42,530 probablement mai has sentit parlar. 17 00:00:42,530 --> 00:00:47,470 Però he compilat una llista de tècnics èxits, suposo que diries. 18 00:00:47,470 --> 00:00:51,620 Tinc 8 patents en els sistemes del núvol virtualització, disseny de microprocessadors, 19 00:00:51,620 --> 00:00:54,440 processament d'esdeveniments complexos, i altres àrees també. 20 00:00:54,440 --> 00:00:58,290 >> Així que en aquests dies, em centre sobretot en NoSQL tecnologies i la propera generació 21 00:00:58,290 --> 00:00:59,450 base de dades. 22 00:00:59,450 --> 00:01:03,370 I això és en general el que vaig estar aquí parlant amb vostè avui sobre. 23 00:01:03,370 --> 00:01:06,030 Llavors, què es pot esperar d'aquesta sessió, 24 00:01:06,030 --> 00:01:08,254 anirem a través d'una breu història de processament de dades. 25 00:01:08,254 --> 00:01:10,420 Sempre és útil entendre d'on venim 26 00:01:10,420 --> 00:01:12,400 i per què som on som. 27 00:01:12,400 --> 00:01:15,600 I parlarem una mica poc sobre la tecnologia NoSQL 28 00:01:15,600 --> 00:01:17,500 des d'un punt de vista fonamental. 29 00:01:17,500 --> 00:01:19,870 >> Anem a entrar en alguns les interioritats DynamoDB. 30 00:01:19,870 --> 00:01:24,350 DynamoDB és de AWS sense sabor. 31 00:01:24,350 --> 00:01:27,340 És una totalment gestionat i NoSQL solució allotjada. 32 00:01:27,340 --> 00:01:32,420 I parlarem una mica sobre la taula estructura, API, tipus de dades, índexs, 33 00:01:32,420 --> 00:01:35,177 i alguns dels internals que la tecnologia DynamoDB. 34 00:01:35,177 --> 00:01:37,760 Anem a entrar en alguns dels dissenys patrons i millors pràctiques. 35 00:01:37,760 --> 00:01:39,968 Anem a parlar de com es utilitzar aquesta tecnologia per a alguns 36 00:01:39,968 --> 00:01:41,430 de les aplicacions d'avui en dia. 37 00:01:41,430 --> 00:01:44,820 I després anem a parlar una mica sobre l'evolució o de l'emergència 38 00:01:44,820 --> 00:01:48,980 d'un nou paradigma en la programació cridats aplicacions orientades a esdeveniments 39 00:01:48,980 --> 00:01:51,580 i com juga DynamoDB en això també. 40 00:01:51,580 --> 00:01:54,690 I us deixem una mica de una arquitectura de referència discussió 41 00:01:54,690 --> 00:01:59,540 pel que podem parlar d'algunes de les formes en què es poden utilitzar DynamoDB. 42 00:01:59,540 --> 00:02:04,116 >> Així que primer off-- aquesta és una pregunta He sentit parlar molt és, el que és una base de dades. 43 00:02:04,116 --> 00:02:06,240 Molta gent pensa que sap el que és una base de dades. 44 00:02:06,240 --> 00:02:08,360 Si Google, veuràs això. 45 00:02:08,360 --> 00:02:11,675 És un un conjunt estructurat de dades celebrada en un ordinador, especialment un que 46 00:02:11,675 --> 00:02:13,600 accessible de diverses maneres. 47 00:02:13,600 --> 00:02:16,992 Suposo que és una bona definició d'una base de dades modern. 48 00:02:16,992 --> 00:02:19,450 Però no m'agrada, perquè implica un parell de coses. 49 00:02:19,450 --> 00:02:20,935 Implica estructura. 50 00:02:20,935 --> 00:02:23,120 I això implica que està en un ordinador. 51 00:02:23,120 --> 00:02:25,750 I les bases de dades no ho van fer sempre existirà en els ordinadors. 52 00:02:25,750 --> 00:02:28,020 Bases de dades realment existien en moltes maneres. 53 00:02:28,020 --> 00:02:32,000 >> Així que una millor definició d'un base de dades és una cosa com això. 54 00:02:32,000 --> 00:02:34,786 Una base de dades és una organitzada mecanisme per emmagatzemar, gestionar, 55 00:02:34,786 --> 00:02:35,910 i recuperació d'informació. 56 00:02:35,910 --> 00:02:36,868 Es tracta d'About.com. 57 00:02:36,868 --> 00:02:42,080 Així que m'agrada això perquè realment parla sobre una base de dades és un repositori, 58 00:02:42,080 --> 00:02:44,800 un dipòsit de informació, no necessàriament 59 00:02:44,800 --> 00:02:46,780 cosa que s'asseu en un ordinador. 60 00:02:46,780 --> 00:02:49,290 I a través de la història, no sempre han tingut els ordinadors. 61 00:02:49,290 --> 00:02:52,110 >> Ara, si li pregunto a la mitjana avui desenvolupador el que és 62 00:02:52,110 --> 00:02:54,770 una base de dades, que és la resposta que rebo. 63 00:02:54,770 --> 00:02:56,070 En algun lloc que puc ficar coses. 64 00:02:56,070 --> 00:02:56,670 Oi? 65 00:02:56,670 --> 00:02:58,725 I és cert. 66 00:02:58,725 --> 00:02:59,600 Però és lamentable. 67 00:02:59,600 --> 00:03:02,700 A causa de que la base de dades és realment el fonament de l'aplicació moderna. 68 00:03:02,700 --> 00:03:04,810 És la base de cada aplicació. 69 00:03:04,810 --> 00:03:07,240 I la manera de construir que base de dades, com s'estructura 70 00:03:07,240 --> 00:03:11,750 que les dades que va a dictar la forma en què aplicació realitza com es canvia l'escala. 71 00:03:11,750 --> 00:03:14,640 >> Així que una gran part del meu treball avui es tracta del que 72 00:03:14,640 --> 00:03:17,180 passa quan els desenvolupadors adoptar aquest enfocament 73 00:03:17,180 --> 00:03:19,510 i fer front a les seqüeles d'una aplicació que 74 00:03:19,510 --> 00:03:24,966 ara està més enllà de l'escala original intenció i el sofriment de mal disseny. 75 00:03:24,966 --> 00:03:26,840 Així que espero que quan allunyar d'avui, podràs 76 00:03:26,840 --> 00:03:29,010 tenir un parell d'eines el cinturó que et mantindrà 77 00:03:29,010 --> 00:03:32,566 de fer els mateixos errors. 78 00:03:32,566 --> 00:03:33,066 Tot bé. 79 00:03:33,066 --> 00:03:36,360 Així que anem a parlar una mica de la línia de temps de la tecnologia de base de dades. 80 00:03:36,360 --> 00:03:38,830 Crec que vaig llegir un article no fa tant de temps 81 00:03:38,830 --> 00:03:43,020 i va dir alguna cosa sobre la lines-- que és una declaració molt poètic. 82 00:03:43,020 --> 00:03:46,590 Va dir que la història de processament de dades és 83 00:03:46,590 --> 00:03:49,350 plena d'altes marques d'aigua de l'abundància de dades. 84 00:03:49,350 --> 00:03:49,920 D'ACORD. 85 00:03:49,920 --> 00:03:52,532 Ara, suposo que això és part de veritat. 86 00:03:52,532 --> 00:03:54,990 Però jo en realitat mirar és com la història és en realitat plena 87 00:03:54,990 --> 00:03:56,820 amb alta marca d'aigua de la pressió de dades. 88 00:03:56,820 --> 00:04:00,040 A causa de que la velocitat de dades de la ingestió no es posa. 89 00:04:00,040 --> 00:04:01,360 Només puja. 90 00:04:01,360 --> 00:04:03,670 >> I la innovació es produeix quan veiem pressió de dades, que 91 00:04:03,670 --> 00:04:07,825 és la quantitat de dades que és Ara a que entra al sistema. 92 00:04:07,825 --> 00:04:12,027 I no pot ser processada de manera eficient, ja sigui en el temps o en el cost. 93 00:04:12,027 --> 00:04:14,110 I va ser llavors quan vam començar per mirar la pressió de dades. 94 00:04:14,110 --> 00:04:15,920 >> Així que quan ens fixem en la primera base de dades, aquesta 95 00:04:15,920 --> 00:04:17,180 és el que estava entre els nostres oïdes. 96 00:04:17,180 --> 00:04:18,310 Tots naixem amb ella. 97 00:04:18,310 --> 00:04:19,194 És una base de dades bé. 98 00:04:19,194 --> 00:04:21,110 Té una alta disponibilitat. 99 00:04:21,110 --> 00:04:21,959 És sempre encès. 100 00:04:21,959 --> 00:04:23,930 Vostè sempre pot aconseguir-ho. 101 00:04:23,930 --> 00:04:24,890 >> Però és sol usuari. 102 00:04:24,890 --> 00:04:26,348 No puc compartir els meus pensaments amb vosaltres. 103 00:04:26,348 --> 00:04:28,370 No es pot tenir en els meus pensaments quan vulguis. 104 00:04:28,370 --> 00:04:30,320 I la seva abilitiy no és tan bo. 105 00:04:30,320 --> 00:04:32,510 Ens oblidem de les coses. 106 00:04:32,510 --> 00:04:36,540 De tant en tant, un de nosaltres fulles i es mou a una altra existència 107 00:04:36,540 --> 00:04:39,110 i perdem tot això va ser en aquesta base de dades. 108 00:04:39,110 --> 00:04:40,640 Així que no és tan bo. 109 00:04:40,640 --> 00:04:43,189 >> I això va funcionar bé amb el temps quan estàvem de tornada en el dia 110 00:04:43,189 --> 00:04:46,230 quan tot el que realment necessitem saber és ¿A on anirem demà 111 00:04:46,230 --> 00:04:49,630 o quan ens reunim el millor menjar. 112 00:04:49,630 --> 00:04:52,820 Però, com hem començat a créixer com la civilització i el govern van començar 113 00:04:52,820 --> 00:04:55,152 per venir a ser, i les empreses van començar a evolucionar, 114 00:04:55,152 --> 00:04:57,360 comencem a adonar-nos que necessiten una mica més del que 115 00:04:57,360 --> 00:04:58,210 podríem posar en el nostre cap. 116 00:04:58,210 --> 00:04:58,870 Tot bé? 117 00:04:58,870 --> 00:05:00,410 >> Necessitàvem els sistemes de registre. 118 00:05:00,410 --> 00:05:02,220 Necessitàvem llocs per ser capaços d'emmagatzemar dades. 119 00:05:02,220 --> 00:05:05,450 Així que vam començar a escriure documents, la creació de biblioteques i arxius. 120 00:05:05,450 --> 00:05:08,000 Comencem el desenvolupament d'un sistema d'un llibre major de comptabilitat. 121 00:05:08,000 --> 00:05:12,200 I aquest sistema de comptatge de llibre major va córrer el món durant molts segles, 122 00:05:12,200 --> 00:05:15,580 i potser fins i tot mil·lennis com quin tipus de créixer fins al punt 123 00:05:15,580 --> 00:05:18,420 on aquesta càrrega de dades va superar la capacitat d'aquests sistemes 124 00:05:18,420 --> 00:05:19,870 per ser capaç de contenir-lo. 125 00:05:19,870 --> 00:05:22,070 >> I això realment va ocórrer en la dècada de 1880. 126 00:05:22,070 --> 00:05:22,570 Oi? 127 00:05:22,570 --> 00:05:24,390 Als EUA Cens 1880. 128 00:05:24,390 --> 00:05:26,976 Això és realment on el gir punt de processament de dades modern. 129 00:05:26,976 --> 00:05:28,850 Aquest és el punt en que la quantitat de dades 130 00:05:28,850 --> 00:05:32,060 que estava sent recollit pel Govern dels Estats Units va arribar al punt 131 00:05:32,060 --> 00:05:34,005 on va prendre vuit anys per processar. 132 00:05:34,005 --> 00:05:36,350 >> Ara, vuit anys-- com vostè sap, el cens 133 00:05:36,350 --> 00:05:39,180 surt cada 10 anys-- pel que és bastant obvi que per al moment en què 134 00:05:39,180 --> 00:05:41,419 té el cens de 1890, la quantitat de dades que 135 00:05:41,419 --> 00:05:43,210 que anava a ser processat pel govern era 136 00:05:43,210 --> 00:05:46,335 va superar els 10 anys que portaria a posat en marxa el nou cens. 137 00:05:46,335 --> 00:05:47,250 Això era un problema. 138 00:05:47,250 --> 00:05:49,000 >> Així que un tipus anomenat Herman Hollerith va arribar 139 00:05:49,000 --> 00:05:52,640 i va inventar ponx registre de la unitat targetes, lector de targetes perforades, targetes perforades 140 00:05:52,640 --> 00:05:58,420 tabulador, i la confrontació de els mecanismes per a aquesta tecnologia. 141 00:05:58,420 --> 00:06:01,860 I aquesta empresa que es va formar al temps, juntament amb un parell dels altres, 142 00:06:01,860 --> 00:06:05,450 en realitat es va convertir en un dels pilars d'un petita empresa que avui coneixem diu IBM. 143 00:06:05,450 --> 00:06:08,417 >> Així IBM originalment estava en el negoci de base de dades. 144 00:06:08,417 --> 00:06:09,750 I això és realment el que van fer. 145 00:06:09,750 --> 00:06:11,110 Ho van fer de processament de dades. 146 00:06:11,110 --> 00:06:15,400 >> Com el que la proliferació de cop targetes, 01:00 mecanismes enginyosos 147 00:06:15,400 --> 00:06:18,560 de ser capaç d'aprofitar aquest tecnologia per sondejar conjunts de resultats ordenats. 148 00:06:18,560 --> 00:06:20,726 Es pot veure en aquesta foto no tenim un poc-- 149 00:06:20,726 --> 00:06:23,970 que és una mica small-- però es pot veure un mecanisme mecànic molt enginyós 150 00:06:23,970 --> 00:06:26,970 on tenim una baralla de targetes perforades. 151 00:06:26,970 --> 00:06:28,720 I la presa d'algú una mica de tornavís 152 00:06:28,720 --> 00:06:31,400 i ajustar-se a través de la ranures i aixecant 153 00:06:31,400 --> 00:06:34,820 per aconseguir que el partit, que resultats ordenats estableixen. 154 00:06:34,820 --> 00:06:36,270 >> Aquesta és una agregació. 155 00:06:36,270 --> 00:06:38,690 Fem això tot el temps avui a l'ordinador, 156 00:06:38,690 --> 00:06:40,100 quan ho fas a la base de dades. 157 00:06:40,100 --> 00:06:41,620 Solíem fer-ho manualment, no? 158 00:06:41,620 --> 00:06:42,994 La gent posa aquestes coses juntes. 159 00:06:42,994 --> 00:06:45,440 I va ser la proliferació d'aquestes targetes perforades 160 00:06:45,440 --> 00:06:50,070 en el que anomenem la bateria de dades i rodets de dades, cinta de paper. 161 00:06:50,070 --> 00:06:55,980 >> La indústria de processament de dades es va dur una lliçó dels jugadors pianos. 162 00:06:55,980 --> 00:06:57,855 Reproductor de pianos de tornada a el canvi de segle 163 00:06:57,855 --> 00:07:02,100 utilitzat per utilitzar bobines de paper amb ranures a dir-li que què tecles per jugar. 164 00:07:02,100 --> 00:07:05,380 Així que la tecnologia es va adaptar finalment per emmagatzemar dades digitals, 165 00:07:05,380 --> 00:07:08,070 perquè podrien posar aquestes dades en aquests rodets de cinta de paper. 166 00:07:08,070 --> 00:07:10,870 >> Ara, com a resultat, les dades va ser actually-- com 167 00:07:10,870 --> 00:07:14,960 accedeix a aquesta dada va anar directament depèn del que vas guardar. 168 00:07:14,960 --> 00:07:17,825 Així que si poso les dades en una cinta, Vaig tenir accés a les dades de forma lineal. 169 00:07:17,825 --> 00:07:20,475 Vaig haver de rodar el tot cinta per accedir a totes les dades. 170 00:07:20,475 --> 00:07:22,600 Si poso les dades en el cop targetes, que podrien accedir-hi 171 00:07:22,600 --> 00:07:26,270 en una mica més a l'atzar la moda, potser no tan ràpid. 172 00:07:26,270 --> 00:07:30,770 >> Però hi va haver limitacions en la forma en què accés a les dades en funció de com es va emmagatzemar. 173 00:07:30,770 --> 00:07:32,890 I pel que aquest era un problema entrar en els '50s. 174 00:07:32,890 --> 00:07:37,890 Un cop més, podem començar a veure que a mesura que desenvolupar noves tecnologies per processar 175 00:07:37,890 --> 00:07:41,670 les dades, a la dreta, s'obre la porta a noves solucions, 176 00:07:41,670 --> 00:07:45,852 per als nous programes, nous les sol·licituds d'aquestes dades. 177 00:07:45,852 --> 00:07:47,810 I realment, la governança va poder haver estat la raó 178 00:07:47,810 --> 00:07:49,435 Per això hem desenvolupat alguns d'aquests sistemes. 179 00:07:49,435 --> 00:07:52,290 Però el negoci es va convertir ràpidament el conductor darrere de l'evolució 180 00:07:52,290 --> 00:07:54,720 de la base de dades modern i el sistema d'arxius modern. 181 00:07:54,720 --> 00:07:56,870 >> Així que la propera cosa que ocórrer va ser en els anys 50 182 00:07:56,870 --> 00:08:00,780 va ser el sistema d'arxius i la desenvolupament d'emmagatzematge d'accés aleatori. 183 00:08:00,780 --> 00:08:02,050 Aquesta era bonica. 184 00:08:02,050 --> 00:08:06,230 Ara, de sobte, podem posar la nostra arxius en qualsevol part d'aquests discos durs 185 00:08:06,230 --> 00:08:09,760 i podem accedir a aquestes dades a l'atzar. 186 00:08:09,760 --> 00:08:11,950 Podem analitzar que la informació dels arxius. 187 00:08:11,950 --> 00:08:14,920 I hem resolt tot el món problemes amb el processament de dades. 188 00:08:14,920 --> 00:08:17,550 >> I que va durar al voltant de 20 o 30 anys, fins a l'evolució 189 00:08:17,550 --> 00:08:22,100 de la base de dades relacional, que és quan el món va decidir que ara 190 00:08:22,100 --> 00:08:27,940 necessita tenir un repositori que derrota la dispersió de les dades a través de l'arxiu 191 00:08:27,940 --> 00:08:29,540 sistemes que hem construït. Oi? 192 00:08:29,540 --> 00:08:34,270 Massa dades distribuïts en massa llocs, la de-duplicació de dades, 193 00:08:34,270 --> 00:08:37,120 i el cost d'emmagatzematge va ser enorme. 194 00:08:37,120 --> 00:08:43,760 >> En els anys 70, el recurs més car que un equip tenia era el d'emmagatzematge. 195 00:08:43,760 --> 00:08:46,200 El processador era vist com un cost fix. 196 00:08:46,200 --> 00:08:49,030 Quan compro la caixa, la CPU fa algun treball. 197 00:08:49,030 --> 00:08:51,960 Es va a estar girant si que està treballant o no en realitat. 198 00:08:51,960 --> 00:08:53,350 Això és realment un cost enfonsat. 199 00:08:53,350 --> 00:08:56,030 >> Però el que m'ha costat com negoci és l'emmagatzematge. 200 00:08:56,030 --> 00:09:00,020 Si he de comprar més discos proper mes, això és un cost real que he de pagar. 201 00:09:00,020 --> 00:09:01,620 I que l'emmagatzematge és car. 202 00:09:01,620 --> 00:09:05,020 >> Ara tenim avanç ràpid 40 anys i tenim un problema diferent. 203 00:09:05,020 --> 00:09:10,020 El càlcul és ara la recurs més car. 204 00:09:10,020 --> 00:09:11,470 L'emmagatzematge és barat. 205 00:09:11,470 --> 00:09:14,570 Vull dir, podem anar a qualsevol part de la Cloud i podem trobar emmagatzematge barat. 206 00:09:14,570 --> 00:09:17,190 Però el que no puc trobar és computi barat. 207 00:09:17,190 --> 00:09:20,700 >> Així que l'evolució d'avui la tecnologia, de la tecnologia de base de dades, 208 00:09:20,700 --> 00:09:23,050 que realment està centrat al voltant bases de dades distribuïdes 209 00:09:23,050 --> 00:09:26,960 que no pateixen de el mateix tipus d'escala 210 00:09:26,960 --> 00:09:29,240 limitacions de les bases de dades relacionals. 211 00:09:29,240 --> 00:09:32,080 Parlarem una mica sobre el que realment significa. 212 00:09:32,080 --> 00:09:34,760 >> Però una de les raons i el conductor darrere d'això- ens 213 00:09:34,760 --> 00:09:38,290 va parlar de la pressió de dades. 214 00:09:38,290 --> 00:09:41,920 Les dades de pressió és una cosa que impulsa la innovació. 215 00:09:41,920 --> 00:09:44,610 I si ens fixem en més de els últims cinc anys, 216 00:09:44,610 --> 00:09:48,180 aquesta és una gràfica del que les dades càrrega a través de l'empresa en general 217 00:09:48,180 --> 00:09:49,640 sembla que en els últims cinc anys. 218 00:09:49,640 --> 00:09:52,570 >> I la regla general aquests days-- si van Google-- 219 00:09:52,570 --> 00:09:55,290 és 90% de les dades que emmagatzemem avui, i va ser 220 00:09:55,290 --> 00:09:57,330 generada en els últims dos anys. 221 00:09:57,330 --> 00:09:57,911 D'ACORD. 222 00:09:57,911 --> 00:09:59,410 Ara, això no és una tendència que hi ha de nou. 223 00:09:59,410 --> 00:10:01,230 Aquesta és una tendència que ha estat sortir per 100 anys. 224 00:10:01,230 --> 00:10:03,438 Des Herman Hollerith desenvolupat la targeta perforada, 225 00:10:03,438 --> 00:10:08,040 hem estat construint dipòsits de dades i la recol·lecció de dades a velocitats fenomenals. 226 00:10:08,040 --> 00:10:10,570 >> Així que en els últims 100 anys, que hem vist aquesta tendència. 227 00:10:10,570 --> 00:10:11,940 Això no canviarà. 228 00:10:11,940 --> 00:10:14,789 En el futur, veurem això, si no una tendència accelerada. 229 00:10:14,789 --> 00:10:16,330 I vostè pot veure el que sembla. 230 00:10:16,330 --> 00:10:23,510 >> Si un negoci en l'any 2010 tenia una terabyte de dades sota gestió, 231 00:10:23,510 --> 00:10:27,080 avui que vol dir que són la gestió de 6,5 petabytes de dades. 232 00:10:27,080 --> 00:10:30,380 Això és 6.500 vegades més dades. 233 00:10:30,380 --> 00:10:31,200 I sé que això. 234 00:10:31,200 --> 00:10:33,292 Jo treball amb aquests negocis cada dia. 235 00:10:33,292 --> 00:10:35,000 Fa cinc anys, seria parlar amb empreses 236 00:10:35,000 --> 00:10:38,260 qui parlar amb mi sobre el que és un dolor que és gestionar terabytes de dades. 237 00:10:38,260 --> 00:10:39,700 I que parlarien a mi sobre com veiem 238 00:10:39,700 --> 00:10:41,825 que aquest és probablement va ser un petabyte o dos 239 00:10:41,825 --> 00:10:43,030 aquí a un parell d'anys. 240 00:10:43,030 --> 00:10:45,170 >> Aquestes mateixes empreses avui em vaig a reunir amb, 241 00:10:45,170 --> 00:10:48,100 i que estan parlant amb mi sobre la problema s'hagi tenint gestió 242 00:10:48,100 --> 00:10:51,440 desenes, 20 petabytes de dades. 243 00:10:51,440 --> 00:10:53,590 Així l'explosió de la dades en la indústria 244 00:10:53,590 --> 00:10:56,670 està impulsant l'enorme la necessitat de millors solucions. 245 00:10:56,670 --> 00:11:00,980 I la base de dades relacional és simplement no viure d'acord a la demanda. 246 00:11:00,980 --> 00:11:03,490 >> I així hi ha un lineal correlació entre la pressió de dades 247 00:11:03,490 --> 00:11:05,210 i la innovació tècnica. 248 00:11:05,210 --> 00:11:07,780 La història ens ha demostrat això, que amb el temps, 249 00:11:07,780 --> 00:11:11,090 sempre que el volum de dades que necessita ser processada 250 00:11:11,090 --> 00:11:15,490 excedeix la capacitat del sistema de per processar-ho en un temps raonable 251 00:11:15,490 --> 00:11:18,870 oa un cost raonable, a continuació, les noves tecnologies 252 00:11:18,870 --> 00:11:21,080 han estat inventats per resoldre aquests problemes. 253 00:11:21,080 --> 00:11:24,090 Aquestes noves tecnologies, al seu torn, obre la porta 254 00:11:24,090 --> 00:11:27,840 a una altra sèrie de problemes, que està reunint encara més dades. 255 00:11:27,840 --> 00:11:29,520 >> Ara, nosaltres no pararem això. 256 00:11:29,520 --> 00:11:30,020 Oi? 257 00:11:30,020 --> 00:11:31,228 No pararem això. 258 00:11:31,228 --> 00:11:31,830 Per què? 259 00:11:31,830 --> 00:11:35,520 Perquè no es pot saber tot que cal saber en l'univers. 260 00:11:35,520 --> 00:11:40,510 I mentre hem estat vius, en tota la història de l'home, 261 00:11:40,510 --> 00:11:43,440 sempre hem impulsat saber més. 262 00:11:43,440 --> 00:11:49,840 >> Així que sembla que cada polzada que avancem pel camí dels descobriments científics, 263 00:11:49,840 --> 00:11:54,620 estem multiplicant la quantitat de dades que necessitem per processar de forma exponencial 264 00:11:54,620 --> 00:11:59,920 com descobrim més i més i més sobre el funcionament intern de la vida, 265 00:11:59,920 --> 00:12:04,530 sobre com funciona l'univers, sobre conduint el descobriment científic, 266 00:12:04,530 --> 00:12:06,440 i la invenció que que estem fent avui. 267 00:12:06,440 --> 00:12:09,570 El volum de dades simplement augmenta contínuament. 268 00:12:09,570 --> 00:12:12,120 Així que ser capaç de fer front aquest problema és enorme. 269 00:12:12,120 --> 00:12:14,790 270 00:12:14,790 --> 00:12:17,410 >> Així que una de les coses mirem com per què NoSQL? 271 00:12:17,410 --> 00:12:19,200 Com NoSQL a resoldre aquest problema? 272 00:12:19,200 --> 00:12:24,980 Bé, bases de dades relacionals, Structured Query Language, 273 00:12:24,980 --> 00:12:28,600 SQL-- això és realment una construcció de la relacional database-- aquestes coses són 274 00:12:28,600 --> 00:12:30,770 optimitzat per a l'emmagatzematge. 275 00:12:30,770 --> 00:12:33,180 >> Allà pels anys 70, de nou, disc és car. 276 00:12:33,180 --> 00:12:36,990 L'exercici d'aprovisionament d'emmagatzematge a l'empresa és de mai acabar. 277 00:12:36,990 --> 00:12:37,490 Ho sé. 278 00:12:37,490 --> 00:12:38,020 Jo ho vaig viure. 279 00:12:38,020 --> 00:12:41,250 Vaig escriure controladors d'emmagatzematge per a un empresa SuperServer Enterprised 280 00:12:41,250 --> 00:12:42,470 allà pels anys 90. 281 00:12:42,470 --> 00:12:45,920 I el resultat final està acumulant una altra matriu d'emmagatzematge era només una cosa que 282 00:12:45,920 --> 00:12:47,600 passar tots els dies a l'empresa. 283 00:12:47,600 --> 00:12:49,030 I mai es va aturar. 284 00:12:49,030 --> 00:12:52,690 Major densitat d'emmagatzematge, la demanda per a l'emmagatzematge d'alta densitat, 285 00:12:52,690 --> 00:12:56,340 i per a l'emmagatzematge més eficient devices-- mai es va aturar. 286 00:12:56,340 --> 00:13:00,160 >> I NoSQL és una gran tecnologia perquè normalitza les dades. 287 00:13:00,160 --> 00:13:02,210 És de-duplica les dades. 288 00:13:02,210 --> 00:13:07,180 Es posa les dades en una estructura que és agnòstic a cada patró d'accés. 289 00:13:07,180 --> 00:13:11,600 Múltiples aplicacions poden arribar a aquest Base de dades SQL, executar consultes ad hoc, 290 00:13:11,600 --> 00:13:15,950 i obtenir dades en la forma que hagi de processar per les seves càrregues de treball. 291 00:13:15,950 --> 00:13:17,570 Això sona fantàstic. 292 00:13:17,570 --> 00:13:21,350 Però la conclusió és que amb qualsevol sistema, si és agnòstic a tot, 293 00:13:21,350 --> 00:13:23,500 està optimitzat per a res. 294 00:13:23,500 --> 00:13:24,050 D'ACORD? 295 00:13:24,050 --> 00:13:26,386 >> I això és el que vam aconseguir amb la base de dades relacional. 296 00:13:26,386 --> 00:13:27,510 Està optimitzat per al seu emmagatzematge. 297 00:13:27,510 --> 00:13:28,280 És normalitzada. 298 00:13:28,280 --> 00:13:29,370 És relacional. 299 00:13:29,370 --> 00:13:31,660 És compatible amb les consultes ad hoc. 300 00:13:31,660 --> 00:13:34,000 I ella i s'escala verticalment. 301 00:13:34,000 --> 00:13:39,030 >> Si he d'aconseguir una base de dades SQL gran o una base de dades SQL més potent, 302 00:13:39,030 --> 00:13:41,090 Vaig comprar un tros més gran de ferro. 303 00:13:41,090 --> 00:13:41,600 D'ACORD? 304 00:13:41,600 --> 00:13:44,940 He treballat amb molts clients que han estat a través de millores importants 305 00:13:44,940 --> 00:13:48,340 en la seva infraestructura de SQL única per esbrinar sis mesos més tard, 306 00:13:48,340 --> 00:13:49,750 que estan colpejant la paret de nou. 307 00:13:49,750 --> 00:13:55,457 I la resposta d'Oracle o MSSQL o qualsevol altra persona és aconseguir una caixa més gran. 308 00:13:55,457 --> 00:13:58,540 Bé, tard o d'hora, no es pot comprar una caixa més gran, i això és un problema real. 309 00:13:58,540 --> 00:14:00,080 Hem de canviar realment les coses. 310 00:14:00,080 --> 00:14:01,080 Llavors, on funciona això? 311 00:14:01,080 --> 00:14:06,560 Funciona bé per fora de línia anàlisi, les càrregues de treball de tipus OLAP. 312 00:14:06,560 --> 00:14:08,670 I això és realment on SQL pertany. 313 00:14:08,670 --> 00:14:12,540 Ara, s'utilitza avui dia en molts en línia transaccional de tipus de processament 314 00:14:12,540 --> 00:14:13,330 aplicacions. 315 00:14:13,330 --> 00:14:16,460 I funciona molt bé en un cert nivell d'utilització, 316 00:14:16,460 --> 00:14:18,670 però simplement no escala la forma en què NoSQL fa. 317 00:14:18,670 --> 00:14:20,660 I parlarem una mica poc sobre per què és així. 318 00:14:20,660 --> 00:14:23,590 >> Ara, NoSQL, d'altra banda, està més optimitzat per a càlcul. 319 00:14:23,590 --> 00:14:24,540 D'ACORD? 320 00:14:24,540 --> 00:14:26,830 No és agnòstic a el patró d'accés. 321 00:14:26,830 --> 00:14:31,620 És el que anomenem de-normalitzada estructura o una estructura jeràrquica. 322 00:14:31,620 --> 00:14:35,000 Les dades en una base de dades relacional és unit de diverses taules 323 00:14:35,000 --> 00:14:36,850 per produir l'opinió que el que necessita. 324 00:14:36,850 --> 00:14:40,090 Les dades a la base de dades NoSQL 1 s'emmagatzema en un document que 325 00:14:40,090 --> 00:14:42,100 conté l'estructura jeràrquica. 326 00:14:42,100 --> 00:14:45,670 Totes les dades que normalment seria unit per produir aquest punt de vista 327 00:14:45,670 --> 00:14:47,160 s'emmagatzema en un únic document. 328 00:14:47,160 --> 00:14:50,990 I parlarem una mica sobre el que funciona en un parell de cartes. 329 00:14:50,990 --> 00:14:55,320 >> Però la idea és que vostè emmagatzema les dades mentre que aquests punts de vista instanciados. 330 00:14:55,320 --> 00:14:56,410 D'ACORD? 331 00:14:56,410 --> 00:14:58,610 Vostè escalar horitzontalment. 332 00:14:58,610 --> 00:14:59,556 Oi? 333 00:14:59,556 --> 00:15:02,100 Si he de augmentar el mida de la meva grup de NoSQL, 334 00:15:02,100 --> 00:15:03,700 No necessito aconseguir una caixa més gran. 335 00:15:03,700 --> 00:15:05,200 Tinc una altra caixa. 336 00:15:05,200 --> 00:15:07,700 I jo Clúster les juntes, i puc fragmentar aquestes dades. 337 00:15:07,700 --> 00:15:10,780 Parlarem una mica sobre el sharding és, per a ser 338 00:15:10,780 --> 00:15:14,270 capaç d'escalar aquesta base de dades a través de múltiples dispositius físics 339 00:15:14,270 --> 00:15:18,370 i treure la barrera que em requereix per escalar verticalment. 340 00:15:18,370 --> 00:15:22,080 >> Així que és realment construït per en línia processament de transaccions i l'escala. 341 00:15:22,080 --> 00:15:25,480 Hi ha una gran diferència aquí entre la informació, no? 342 00:15:25,480 --> 00:15:27,810 Informes, jo no sé la preguntes vaig a preguntar. 343 00:15:27,810 --> 00:15:28,310 Oi? 344 00:15:28,310 --> 00:15:30,570 Reporting-- si algú de meu departament de màrqueting 345 00:15:30,570 --> 00:15:34,520 vol sol-- com molts dels meus clients tenir aquesta característica particular que 346 00:15:34,520 --> 00:15:37,850 comprat en aquest dia-- No sé ho consulta van a preguntar. 347 00:15:37,850 --> 00:15:39,160 Així que he de ser agnòstic. 348 00:15:39,160 --> 00:15:41,810 >> Ara, en una línia aplicació transaccional, 349 00:15:41,810 --> 00:15:43,820 Jo sé el que estic demanant preguntes. 350 00:15:43,820 --> 00:15:46,581 Vaig construir la sol·licitud d' un flux de treball molt específic. 351 00:15:46,581 --> 00:15:47,080 D'ACORD? 352 00:15:47,080 --> 00:15:50,540 Així que si puc optimitzar les dades emmagatzemar per recolzar aquest flux de treball, 353 00:15:50,540 --> 00:15:52,020 que serà més ràpid. 354 00:15:52,020 --> 00:15:55,190 I és per això que NoSQL pot realment accelerar el lliurament 355 00:15:55,190 --> 00:15:57,710 d'aquests tipus de serveis. 356 00:15:57,710 --> 00:15:58,210 Tot bé. 357 00:15:58,210 --> 00:16:00,501 >> Així que entrarem en una mica de la teoria aquí. 358 00:16:00,501 --> 00:16:03,330 I alguns de vostès, els seus ulls podria fer retrocedir una mica. 359 00:16:03,330 --> 00:16:06,936 Però vaig a tractar de mantenir-lo tan alt nivell com pugui. 360 00:16:06,936 --> 00:16:08,880 Així que si vostè està en projecte gestió, hi ha 361 00:16:08,880 --> 00:16:12,280 un constructe anomenat triangle de restriccions. 362 00:16:12,280 --> 00:16:12,936 D'ACORD. 363 00:16:12,936 --> 00:16:16,060 El triangle de Restringeix dictats no es pot tenir tot, tot el temps. 364 00:16:16,060 --> 00:16:17,750 No pot tenir el seu pastís i menjar-se'l també. 365 00:16:17,750 --> 00:16:22,310 Així que en la gestió de projectes, aquest triangle limitacions és que es pot tenir barat, 366 00:16:22,310 --> 00:16:24,710 es pot tenir ràpid, o es pot tenir bona. 367 00:16:24,710 --> 00:16:25,716 Esculli dos. 368 00:16:25,716 --> 00:16:27,090 A causa de que no es pot tenir als tres. 369 00:16:27,090 --> 00:16:27,460 Oi? 370 00:16:27,460 --> 00:16:27,820 D'ACORD. 371 00:16:27,820 --> 00:16:28,920 >> Així es va assabentar d'això molt. 372 00:16:28,920 --> 00:16:31,253 És una triple restricció, triangle de la triple restricció, 373 00:16:31,253 --> 00:16:34,420 o en el triangle de ferro és oftentimes-- quan parles amb els gerents de projecte, 374 00:16:34,420 --> 00:16:35,420 van a parlar d'això. 375 00:16:35,420 --> 00:16:37,640 Ara, bases de dades tenen el seu propi triangle de ferro. 376 00:16:37,640 --> 00:16:40,350 I el triangle de ferro de les dades és el que anomenem teorema CAP. 377 00:16:40,350 --> 00:16:41,580 D'ACORD? 378 00:16:41,580 --> 00:16:43,770 >> Dictats teorema CAP com funcionen les bases de dades 379 00:16:43,770 --> 00:16:45,627 sota una condició molt específica. 380 00:16:45,627 --> 00:16:47,460 I parlarem de el que la condició és. 381 00:16:47,460 --> 00:16:52,221 Però els tres punts del triangle, per així dir-ho, són C, la consistència. 382 00:16:52,221 --> 00:16:52,720 D'ACORD? 383 00:16:52,720 --> 00:16:56,760 Així que en la PAC, la coherència significa que totes clients que poden accedir a la base de dades 384 00:16:56,760 --> 00:16:59,084 sempre tindrà un vista consistent de les dades. 385 00:16:59,084 --> 00:17:00,750 Ningú va a veure dues coses diferents. 386 00:17:00,750 --> 00:17:01,480 D'ACORD? 387 00:17:01,480 --> 00:17:04,020 Si veig a la base de dades, Estic veient la mateixa vista 388 00:17:04,020 --> 00:17:06,130 com el meu company que veu la mateixa base de dades. 389 00:17:06,130 --> 00:17:07,470 Aquesta és la consistència. 390 00:17:07,470 --> 00:17:12,099 >> Disponibilitat vol dir que si el base de dades en línia, si es pot arribar, 391 00:17:12,099 --> 00:17:14,760 que tots els clients serà sempre ser capaç de llegir i escriure. 392 00:17:14,760 --> 00:17:15,260 D'ACORD? 393 00:17:15,260 --> 00:17:17,010 Així que cada client que pot llegir la base de dades 394 00:17:17,010 --> 00:17:18,955 sempre serà capaç de llegir dades de dades i escriure. 395 00:17:18,955 --> 00:17:21,819 I si aquest és el cas, és un sistema disponible. 396 00:17:21,819 --> 00:17:24,230 >> I el tercer punt és el que que anomenem tolerància partició. 397 00:17:24,230 --> 00:17:24,730 D'ACORD? 398 00:17:24,730 --> 00:17:28,160 Mitjans de tolerància de repartiment que el sistema funciona bé 399 00:17:28,160 --> 00:17:32,000 malgrat xarxa física particions entre els nodes. 400 00:17:32,000 --> 00:17:32,760 D'ACORD? 401 00:17:32,760 --> 00:17:36,270 Així que els nodes del clúster no pot parlar l'un a l'altre, què passa? 402 00:17:36,270 --> 00:17:36,880 Tot bé. 403 00:17:36,880 --> 00:17:39,545 >> Bases de dades relacionals Així choose-- vostè pot escollir dos d'ells. 404 00:17:39,545 --> 00:17:40,045 D'ACORD. 405 00:17:40,045 --> 00:17:43,680 Bases de dades relacionals Així que trien ser consistents i disponibles. 406 00:17:43,680 --> 00:17:47,510 Si la partició ocorre entre els DataNodes al magatzem de dades, 407 00:17:47,510 --> 00:17:48,831 la base de dades es bloqueja. 408 00:17:48,831 --> 00:17:49,330 Oi? 409 00:17:49,330 --> 00:17:50,900 Simplement va cap avall. 410 00:17:50,900 --> 00:17:51,450 D'ACORD. 411 00:17:51,450 --> 00:17:54,230 >> I és per això que tenen per créixer amb les caixes més grans. 412 00:17:54,230 --> 00:17:54,730 Oi? 413 00:17:54,730 --> 00:17:58,021 Perquè hi ha no-- En general, un clúster base de dades, no hi ha molts d'ells 414 00:17:58,021 --> 00:17:59,590 que funcionen d'aquesta manera. 415 00:17:59,590 --> 00:18:03,019 Però la majoria de les bases de dades d'escala verticalment dins d'una sola caixa. 416 00:18:03,019 --> 00:18:05,060 A causa de que han de ser consistent i disponible. 417 00:18:05,060 --> 00:18:10,320 Si una partició anaven a ser injectat, llavors vostè hauria de prendre una decisió. 418 00:18:10,320 --> 00:18:13,720 Vostè ha de fer una elecció entre ser coherent i disponible. 419 00:18:13,720 --> 00:18:16,080 >> I això és el que les bases de dades NoSQL fan. 420 00:18:16,080 --> 00:18:16,580 Tot bé. 421 00:18:16,580 --> 00:18:20,950 Així que una base de dades NoSQL, es ve en dos sabors. 422 00:18:20,950 --> 00:18:22,990 Ens tener-- bé, ve en molts sabors, 423 00:18:22,990 --> 00:18:26,140 però ve amb dues concepcions fonamentals characteristics-- ho 424 00:18:26,140 --> 00:18:30,050 que anomenaríem base de dades de PC, o un tolerància consistent i partició 425 00:18:30,050 --> 00:18:31,040 sistema. 426 00:18:31,040 --> 00:18:34,930 Aquests nois prendre la decisió de que quan els nodes perden contacte entre si, 427 00:18:34,930 --> 00:18:37,091 no permetrem que gent escrigui més. 428 00:18:37,091 --> 00:18:37,590 D'ACORD? 429 00:18:37,590 --> 00:18:41,855 >> Fins que s'elimina la partició, es bloqueja l'accés a escriptura. 430 00:18:41,855 --> 00:18:43,230 Això vol dir que no estan disponibles. 431 00:18:43,230 --> 00:18:44,510 Són consistents. 432 00:18:44,510 --> 00:18:46,554 Quan veiem que partició injectar si mateix, 433 00:18:46,554 --> 00:18:48,470 ara som coherents, perquè no anem 434 00:18:48,470 --> 00:18:51,517 per permetre el canvi de dades en dos costats de la partició de forma independent 435 00:18:51,517 --> 00:18:52,100 l'un de l'altre. 436 00:18:52,100 --> 00:18:54,130 Haurem de restablir la comunicació 437 00:18:54,130 --> 00:18:56,930 abans de qualsevol actualització de es deixa que la de dades. 438 00:18:56,930 --> 00:18:58,120 D'ACORD? 439 00:18:58,120 --> 00:19:02,650 >> El següent gust seria un sistema AP, o disponibles i es va repartir 440 00:19:02,650 --> 00:19:03,640 sistema de tolerància. 441 00:19:03,640 --> 00:19:05,320 Aquests nois no els importa. 442 00:19:05,320 --> 00:19:06,020 Oi? 443 00:19:06,020 --> 00:19:08,960 Qualsevol node que rep una escrivim, el prendrem. 444 00:19:08,960 --> 00:19:11,480 Així que estic replicant les meves dades a través de múltiples nodes. 445 00:19:11,480 --> 00:19:14,730 Aquests nodes reben un client, client ve en, diu, vaig a escriure algunes dades. 446 00:19:14,730 --> 00:19:16,300 Node diu, cap problema. 447 00:19:16,300 --> 00:19:18,580 El node al costat d'ell aconsegueix una escriptura en el mateix registre, 448 00:19:18,580 --> 00:19:20,405 ell dirà que no hi ha problema. 449 00:19:20,405 --> 00:19:23,030 En algun lloc de nou a la part de darrere, que les dades que va a replicar. 450 00:19:23,030 --> 00:19:27,360 I llavors algú va a realitzar, uh-oh, que el sistema s'adonarà, uh-oh, 451 00:19:27,360 --> 00:19:28,870 ha hagut una actualització de dos costats. 452 00:19:28,870 --> 00:19:30,370 Què fem? 453 00:19:30,370 --> 00:19:33,210 I el que fan és, llavors, fan alguna cosa que 454 00:19:33,210 --> 00:19:36,080 els permet resoldre aquest estat de dades. 455 00:19:36,080 --> 00:19:39,000 I parlarem de que, en la següent taula. 456 00:19:39,000 --> 00:19:40,000 >> Cosa a destacar aquí. 457 00:19:40,000 --> 00:19:42,374 I jo no vaig a ser massa molt en això, perquè aquest 458 00:19:42,374 --> 00:19:43,510 es fica en la teoria de les dades de profunditat. 459 00:19:43,510 --> 00:19:46,670 Però hi ha una transaccional marc que 460 00:19:46,670 --> 00:19:50,680 s'executa en un sistema relacional que em permet fer de forma segura les actualitzacions 461 00:19:50,680 --> 00:19:53,760 a múltiples entitats a la base de dades. 462 00:19:53,760 --> 00:19:58,320 I aquests canvis es produiran tots alhora o no en absolut. 463 00:19:58,320 --> 00:20:00,500 I això es diu transaccions ACID. 464 00:20:00,500 --> 00:20:01,000 D'ACORD? 465 00:20:01,000 --> 00:20:06,570 >> ÀCID ens dóna l'atomicidad, consistència, l'aïllament i la durabilitat. 466 00:20:06,570 --> 00:20:07,070 D'ACORD? 467 00:20:07,070 --> 00:20:13,550 Això vol dir atòmiques, transaccions, tot les actualitzacions o bé ocorren o no ho fan. 468 00:20:13,550 --> 00:20:16,570 La consistència vol dir que la base de dades serà sempre 469 00:20:16,570 --> 00:20:19,780 ser portat a un constant estat després d'una actualització. 470 00:20:19,780 --> 00:20:23,900 Mai deixaré la base de dades en un mal estat després d'aplicar una actualització. 471 00:20:23,900 --> 00:20:24,400 D'ACORD? 472 00:20:24,400 --> 00:20:26,720 >> Així que és una mica diferent que la PAC consistència. 473 00:20:26,720 --> 00:20:29,760 CAP consistència significa tota la meva clients sempre poden veure les dades. 474 00:20:29,760 --> 00:20:34,450 Significa que quan la consistència ACID una transacció ha fet, de les dades bones. 475 00:20:34,450 --> 00:20:35,709 Els meus relacions són tots bons. 476 00:20:35,709 --> 00:20:38,750 Jo no vaig a eliminar una fila pare i deixar un munt de nens orfes 477 00:20:38,750 --> 00:20:40,970 en alguna altra taula. 478 00:20:40,970 --> 00:20:44,320 No pot succeir si sóc coherent en una transacció d'àcid. 479 00:20:44,320 --> 00:20:49,120 >> Aïllament significa que les transaccions sempre ocórrer un després de l'altre. 480 00:20:49,120 --> 00:20:51,920 El resultat final de les dades serà el mateix estat 481 00:20:51,920 --> 00:20:54,770 com si aquestes transaccions que es van emetre simultàniament 482 00:20:54,770 --> 00:20:57,340 van ser executats en sèrie. 483 00:20:57,340 --> 00:21:00,030 Així que és de concurrència control a la base de dades. 484 00:21:00,030 --> 00:21:04,130 Així que, bàsicament, no puc incrementar el mateix valor dues vegades amb dues operacions. 485 00:21:04,130 --> 00:21:08,580 >> Però si dic afegir 1 a aquest valor, i dues transaccions vénen en 486 00:21:08,580 --> 00:21:10,665 i tractar de fer-ho, una és va a arribar primer 487 00:21:10,665 --> 00:21:12,540 i l'altre d'un sol heu d'arribar a. 488 00:21:12,540 --> 00:21:15,210 Així que al final, he afegit dos. 489 00:21:15,210 --> 00:21:16,170 Veus el que vull dir? 490 00:21:16,170 --> 00:21:16,670 D'ACORD. 491 00:21:16,670 --> 00:21:19,220 492 00:21:19,220 --> 00:21:21,250 >> La durabilitat és bastant senzill. 493 00:21:21,250 --> 00:21:23,460 Quan la transacció es reconeix, és 494 00:21:23,460 --> 00:21:26,100 va a ser-hi, fins i tot si el sistema es bloqueja. 495 00:21:26,100 --> 00:21:29,230 Quan aquest sistema es recupera, que transacció que es va cometre 496 00:21:29,230 --> 00:21:30,480 és en realitat va a ser-hi. 497 00:21:30,480 --> 00:21:33,130 Així que aquesta és la garantia de transaccions ACID. 498 00:21:33,130 --> 00:21:35,470 Aquestes són molt bones garanties per tenir a una base de dades, 499 00:21:35,470 --> 00:21:36,870 però vénen a aquest cost. 500 00:21:36,870 --> 00:21:37,640 Oi? 501 00:21:37,640 --> 00:21:40,520 >> A causa que el problema amb aquest marc és 502 00:21:40,520 --> 00:21:44,540 si hi ha una partició de dades en el conjunt, he de prendre una decisió. 503 00:21:44,540 --> 00:21:48,000 Vaig a haver de permetre actualitzacions d'un costat o de l'altre. 504 00:21:48,000 --> 00:21:50,310 I si això passa, llavors jo ja no sóc d'anar 505 00:21:50,310 --> 00:21:52,630 per ser capaç de mantenir aquestes característiques. 506 00:21:52,630 --> 00:21:53,960 No seran consistent. 507 00:21:53,960 --> 00:21:55,841 No van a ser aïllats. 508 00:21:55,841 --> 00:21:58,090 Aquí és on es trenca per a bases de dades relacionals. 509 00:21:58,090 --> 00:22:01,360 Aquesta és la raó relacional bases de dades escalar verticalment. 510 00:22:01,360 --> 00:22:05,530 >> D'altra banda, tenim el que crida l'tecnologia BASE. 511 00:22:05,530 --> 00:22:07,291 I aquests són les seves bases de dades NoSQL. 512 00:22:07,291 --> 00:22:07,790 Tot bé. 513 00:22:07,790 --> 00:22:10,180 Així que tenim el nostre CP, les bases de dades d'AP. 514 00:22:10,180 --> 00:22:14,720 I aquests són el que s'anomena bàsicament disponible, estat tou, finalment 515 00:22:14,720 --> 00:22:15,740 consistent. 516 00:22:15,740 --> 00:22:16,420 D'ACORD? 517 00:22:16,420 --> 00:22:19,690 >> Bàsicament disponible, perquè són tolerants partició. 518 00:22:19,690 --> 00:22:21,470 Sempre seran allà, fins i tot si hi ha 519 00:22:21,470 --> 00:22:23,053 una partició de xarxa entre els nodes. 520 00:22:23,053 --> 00:22:25,900 Si puc parlar amb un node, estic serà capaç de llegir dades. 521 00:22:25,900 --> 00:22:26,460 D'ACORD? 522 00:22:26,460 --> 00:22:30,810 No sempre podria ser capaç d'escriure dades si sóc una plataforma consistent. 523 00:22:30,810 --> 00:22:32,130 Però seré capaç de llegir les dades. 524 00:22:32,130 --> 00:22:34,960 525 00:22:34,960 --> 00:22:38,010 >> L'estat tou indica que quan vaig llegir que les dades, 526 00:22:38,010 --> 00:22:40,790 potser no és el mateix que la resta dels nodes. 527 00:22:40,790 --> 00:22:43,390 Si el dret es va emetre en un node en un altre lloc en el clúster 528 00:22:43,390 --> 00:22:46,650 i no s'ha replicat a tot el raïm però, quan vaig llegir que les dades, 529 00:22:46,650 --> 00:22:48,680 aquest estat podria no ser consistent. 530 00:22:48,680 --> 00:22:51,650 No obstant això, serà finalment consistent, 531 00:22:51,650 --> 00:22:53,870 el que significa que quan una escriptura es fa al sistema, 532 00:22:53,870 --> 00:22:56,480 es replicarà en tots els nodes. 533 00:22:56,480 --> 00:22:59,095 I amb el temps, aquest estat serà posat en ordre, 534 00:22:59,095 --> 00:23:00,890 i serà un estat coherent. 535 00:23:00,890 --> 00:23:05,000 >> Ara, CAP teorema realment juga només en una condició. 536 00:23:05,000 --> 00:23:08,700 Aquesta condició és quan això succeeix. 537 00:23:08,700 --> 00:23:13,710 Com que cada vegada s'està operant en manera normal, no hi ha cap partició, 538 00:23:13,710 --> 00:23:16,370 tot és coherent i disponible. 539 00:23:16,370 --> 00:23:19,990 Només es preocupi per la PAC quan tenim aquesta partició. 540 00:23:19,990 --> 00:23:21,260 Així que aquests són rars. 541 00:23:21,260 --> 00:23:25,360 Però, ¿com reacciona el sistema quan els ocorren dictar quin tipus de sistema 542 00:23:25,360 --> 00:23:26,750 que estem tractant. 543 00:23:26,750 --> 00:23:31,110 >> Així que donem una ullada al que es veu com per als sistemes d'AP. 544 00:23:31,110 --> 00:23:32,621 D'ACORD? 545 00:23:32,621 --> 00:23:34,830 Sistemes d'AP són de dos tipus. 546 00:23:34,830 --> 00:23:38,514 Vénen en el gust que és un estimo estimo, 100%, sempre disponible. 547 00:23:38,514 --> 00:23:40,430 I vénen al un altre gust, que diu: 548 00:23:40,430 --> 00:23:43,330 Saps què, jo em vaig a preocupar sobre aquesta cosa de particions 549 00:23:43,330 --> 00:23:44,724 quan es produeix una partició real. 550 00:23:44,724 --> 00:23:47,890 En cas contrari, no serà primària nodes que prendrà els drets. 551 00:23:47,890 --> 00:23:48,500 D'ACORD? 552 00:23:48,500 --> 00:23:50,040 >> Així que si tenim una mena Cassandra. 553 00:23:50,040 --> 00:23:54,440 Cassandra seria un mestre mestra, anem a escriure a qualsevol node. 554 00:23:54,440 --> 00:23:55,540 Llavors, què passa? 555 00:23:55,540 --> 00:23:58,270 Així que tinc un objecte al base de dades que existeix en dos nodes. 556 00:23:58,270 --> 00:24:01,705 Anem a trucar a aquest objecte S. Així que tenim l'estat de S. 557 00:24:01,705 --> 00:24:04,312 Tenim algunes operacions en S que estan en curs. 558 00:24:04,312 --> 00:24:06,270 Cassandra em permet escriure en diversos nodes. 559 00:24:06,270 --> 00:24:08,550 Així que diguem que rebo una escriure per s de dos nodes. 560 00:24:08,550 --> 00:24:12,274 Bé, el que acaba succeint és cridem a que un esdeveniment de partició. 561 00:24:12,274 --> 00:24:14,190 Pot ser que no hi hagi una partició de xarxa física. 562 00:24:14,190 --> 00:24:15,950 Però a causa del disseny del sistema, és 563 00:24:15,950 --> 00:24:18,449 en realitat particions tan aviat com puc obtenir una escriptura en dos nodes. 564 00:24:18,449 --> 00:24:20,830 No m'està obligant a escriure tot a través d'un node. 565 00:24:20,830 --> 00:24:22,340 Estic escrivint en dos nodes. 566 00:24:22,340 --> 00:24:23,330 D'ACORD? 567 00:24:23,330 --> 00:24:25,740 >> Així que ara tinc dos estats. 568 00:24:25,740 --> 00:24:26,360 D'ACORD? 569 00:24:26,360 --> 00:24:28,110 ¿Què passarà és més aviat o més tard, 570 00:24:28,110 --> 00:24:29,960 que serà un esdeveniment de replicació. 571 00:24:29,960 --> 00:24:33,300 No va ser el que anomenat recuperació de la partició, el qual 572 00:24:33,300 --> 00:24:35,200 és on aquests dos estats vénen de nou junts 573 00:24:35,200 --> 00:24:37,310 i no hi haurà un algoritme que s'executa dins de la base de dades, 574 00:24:37,310 --> 00:24:38,540 decideix què fer. 575 00:24:38,540 --> 00:24:39,110 D'ACORD? 576 00:24:39,110 --> 00:24:43,057 Per defecte, darrera actualització guanya en la majoria dels sistemes d'AP. 577 00:24:43,057 --> 00:24:44,890 Així que en general hi ha una algoritme per defecte, el que 578 00:24:44,890 --> 00:24:47,400 que ells anomenen una devolució de trucada funció, cosa que 579 00:24:47,400 --> 00:24:51,000 serà cridat quan aquesta condició es detecta per executar alguna lògica 580 00:24:51,000 --> 00:24:52,900 per resoldre aquest conflicte. 581 00:24:52,900 --> 00:24:53,850 D'ACORD? 582 00:24:53,850 --> 00:24:58,770 La devolució de trucada per defecte i per defecte resoldre la majoria de les bases de dades d'AP en 583 00:24:58,770 --> 00:25:01,130 És a dir, endevinin què, marca de temps guanya. 584 00:25:01,130 --> 00:25:02,380 Aquesta va ser l'última actualització. 585 00:25:02,380 --> 00:25:04,320 Me'n vaig a posar aquesta actualització en aquest país. 586 00:25:04,320 --> 00:25:08,440 Puc bolcar aquest disc que em objecte de dúmping fora en un registre de recuperació 587 00:25:08,440 --> 00:25:11,670 de manera que l'usuari pot tornar més tard i dir, bé, hi va haver una col·lisió. 588 00:25:11,670 --> 00:25:12,320 Que ha passat? 589 00:25:12,320 --> 00:25:16,370 I en realitat es pot bolcar un registre de totes les col·lisions i les reversions 590 00:25:16,370 --> 00:25:17,550 i veure què passa. 591 00:25:17,550 --> 00:25:21,580 >> Ara, com a usuari, també pot incloure lògica en aquesta devolució de trucada. 592 00:25:21,580 --> 00:25:24,290 Així que vostè pot canviar això operació de devolució de trucada. 593 00:25:24,290 --> 00:25:26,730 Es pot dir, bé, jo vull per remeiar aquestes dades. 594 00:25:26,730 --> 00:25:28,880 I vull intentar fusionar aquests dos registres. 595 00:25:28,880 --> 00:25:30,050 Però això depèn de tu. 596 00:25:30,050 --> 00:25:32,880 La base de dades no sap com fer-ho per defecte. La major part del temps, 597 00:25:32,880 --> 00:25:34,850 l'únic que la base de dades sap que fer és a dir, 598 00:25:34,850 --> 00:25:36,100 aquest va ser l'últim registre. 599 00:25:36,100 --> 00:25:39,183 Aquest és el que guanyarà, i aquest és el valor que posaré. 600 00:25:39,183 --> 00:25:41,490 Una vegada que la recuperació de la partició i la replicació es produeix, 601 00:25:41,490 --> 00:25:43,930 tenim el nostre estat, que ara és el Primer, que és 602 00:25:43,930 --> 00:25:46,890 l'estat de combinació de tots aquests objectes. 603 00:25:46,890 --> 00:25:49,700 Així que els sistemes d'AP tenen això. 604 00:25:49,700 --> 00:25:51,615 Sistemes de CP no necessiten de preocupar per això. 605 00:25:51,615 --> 00:25:54,490 Perquè tan aviat com arriba una partició en joc, simplement deixen de prendre 606 00:25:54,490 --> 00:25:55,530 escriu. 607 00:25:55,530 --> 00:25:56,180 D'ACORD? 608 00:25:56,180 --> 00:25:58,670 Així que això és molt fàcil tractar de ser coherent 609 00:25:58,670 --> 00:26:01,330 quan vostè no accepta les actualitzacions. 610 00:26:01,330 --> 00:26:04,620 Això és amb els sistemes CP fan. 611 00:26:04,620 --> 00:26:05,120 Tot bé. 612 00:26:05,120 --> 00:26:07,590 >> Així que anem a parlar una mica poc sobre els patrons d'accés. 613 00:26:07,590 --> 00:26:11,580 Quan parlem de NoSQL, és tot sobre el patró d'accés. 614 00:26:11,580 --> 00:26:13,550 Ara, SQL és ad hoc, les consultes. 615 00:26:13,550 --> 00:26:14,481 És magatzem relacional. 616 00:26:14,481 --> 00:26:16,480 No hem de preocupar sobre el patró d'accés. 617 00:26:16,480 --> 00:26:17,688 Escric una consulta molt complexa. 618 00:26:17,688 --> 00:26:19,250 Es va i obté les dades. 619 00:26:19,250 --> 00:26:21,210 Això és el que això es veu com, la normalització. 620 00:26:21,210 --> 00:26:24,890 >> Així que en aquesta estructura particular, estem mirant un catàleg de productes. 621 00:26:24,890 --> 00:26:26,640 Tinc diferents tipus de productes. 622 00:26:26,640 --> 00:26:27,217 Tinc llibres. 623 00:26:27,217 --> 00:26:27,800 Tinc àlbums. 624 00:26:27,800 --> 00:26:30,090 Tinc vídeos. 625 00:26:30,090 --> 00:26:33,370 La relació entre els productes i qualsevol d'aquests llibres, àlbums, 626 00:26:33,370 --> 00:26:34,860 i vídeos de taules és de 1: 1. 627 00:26:34,860 --> 00:26:35,800 Tot bé? 628 00:26:35,800 --> 00:26:38,860 Tinc un identificador de producte, i que correspon identificació 629 00:26:38,860 --> 00:26:41,080 a un llibre, un àlbum o un vídeo. 630 00:26:41,080 --> 00:26:41,580 D'ACORD? 631 00:26:41,580 --> 00:26:44,350 Això és una relació 1: 1 a través d'aquestes taules. 632 00:26:44,350 --> 00:26:46,970 >> Ara, tot el que books-- tenir és les propietats de l'arrel. 633 00:26:46,970 --> 00:26:47,550 Cap problema. 634 00:26:47,550 --> 00:26:48,230 Això és genial. 635 00:26:48,230 --> 00:26:52,130 Un a un, relació, em surt tot les dades que necessita per descriure aquest llibre. 636 00:26:52,130 --> 00:26:54,770 Àlbums Albums-- tenen pistes. 637 00:26:54,770 --> 00:26:56,470 Això és el que anomenem un a molts. 638 00:26:56,470 --> 00:26:58,905 Cada àlbum podria tenir moltes pistes. 639 00:26:58,905 --> 00:27:00,780 Així, per cada pista en l'àlbum, que podria tenir 640 00:27:00,780 --> 00:27:02,570 un altre rècord en aquesta taula secundària. 641 00:27:02,570 --> 00:27:04,680 Així que puc crear un registre a la meva taula d'àlbums. 642 00:27:04,680 --> 00:27:06,700 Puc crear diversos registres a la taula de pistes. 643 00:27:06,700 --> 00:27:08,850 Un-a-molts relació. 644 00:27:08,850 --> 00:27:11,220 >> Aquesta relació és el que que anomenem de molts a molts. 645 00:27:11,220 --> 00:27:11,750 D'ACORD? 646 00:27:11,750 --> 00:27:17,000 Vostè veu que els actors podrien ser en moltes pel·lícules, molts vídeos. 647 00:27:17,000 --> 00:27:21,450 Així que el que fem és que posem aquest mapeig taula, entre els quals només 648 00:27:21,450 --> 00:27:24,040 mapes de la ID d'actor per a l'ID de vídeo. 649 00:27:24,040 --> 00:27:28,464 Ara puc crear una consulta de les unions vídeos a través actor de vídeo als actors, 650 00:27:28,464 --> 00:27:31,130 i em dóna una bona llista de totes les pel·lícules i tots els actors 651 00:27:31,130 --> 00:27:32,420 que estaven en aquesta pel·lícula. 652 00:27:32,420 --> 00:27:33,290 >> D'ACORD. 653 00:27:33,290 --> 00:27:33,880 Així que aquí anem. 654 00:27:33,880 --> 00:27:38,040 Un-a-un és el de nivell superior relació; un-a-molts, 655 00:27:38,040 --> 00:27:40,240 àlbums a les pistes; molts-a-molts. 656 00:27:40,240 --> 00:27:44,990 Aquests són els tres de nivell superior relacions en qualsevol base de dades. 657 00:27:44,990 --> 00:27:48,050 Si vostè sap com els relacions treballen junts, 658 00:27:48,050 --> 00:27:51,490 llavors vostè sap molt sobre la base de dades ja. 659 00:27:51,490 --> 00:27:55,660 Així NoSQL funciona una mica diferent. 660 00:27:55,660 --> 00:27:58,930 Pensem per un segon que sembla que anar a buscar tots els meus productes. 661 00:27:58,930 --> 00:28:01,096 >> En un magatzem relacional, jo que desitgi obtenir tots els meus productes 662 00:28:01,096 --> 00:28:02,970 en una llista de tots els meus productes. 663 00:28:02,970 --> 00:28:04,910 Això és un munt de preguntes. 664 00:28:04,910 --> 00:28:07,030 Tinc una consulta per tots els meus llibres. 665 00:28:07,030 --> 00:28:08,470 Tinc una pregunta dels meus discos. 666 00:28:08,470 --> 00:28:09,970 I tinc una consulta per tots els meus vídeos. 667 00:28:09,970 --> 00:28:11,719 I he de dir- tots junts en una llista 668 00:28:11,719 --> 00:28:15,250 i servir de nou fins a la aplicació que se sol·licitin. 669 00:28:15,250 --> 00:28:18,000 >> Per aconseguir els meus llibres, m'uneixo a Productes i Llibres. 670 00:28:18,000 --> 00:28:21,680 Per obtenir els meus àlbums, vaig arribar a unir-se Productes, àlbums i cançons. 671 00:28:21,680 --> 00:28:25,330 I per aconseguir els meus vídeos, tinc per unir-se als productes als vídeos, 672 00:28:25,330 --> 00:28:28,890 unir-se a través Actor Videos, i portar als actors. 673 00:28:28,890 --> 00:28:31,020 Així que això és tres consultes. 674 00:28:31,020 --> 00:28:34,560 Consultes molt complexes a acoblar un conjunt de resultats. 675 00:28:34,560 --> 00:28:36,540 >> Això és menys que òptim. 676 00:28:36,540 --> 00:28:39,200 Per això, quan parlem sobre una estructura de dades que és 677 00:28:39,200 --> 00:28:42,900 construït per ser agnòstic a l'accés pattern-- bé això és genial. 678 00:28:42,900 --> 00:28:45,730 I es pot veure que això és realment agradable com hem organitzat les dades. 679 00:28:45,730 --> 00:28:46,550 ¿I saps què? 680 00:28:46,550 --> 00:28:49,750 Només tinc un rècord per a un actor. 681 00:28:49,750 --> 00:28:50,440 >> Això està bé. 682 00:28:50,440 --> 00:28:53,750 He deduplicado tots els meus actors, i vaig mantenir meus associacions 683 00:28:53,750 --> 00:28:55,200 en aquesta taula d'assignacions. 684 00:28:55,200 --> 00:29:00,620 Però, obtenir les dades fora es converteix en car. 685 00:29:00,620 --> 00:29:04,500 Estic enviant la CPU en tot el sistema unir-se a aquestes estructures de dades juntament 686 00:29:04,500 --> 00:29:05,950 ser capaç de tirar de tornar dades. 687 00:29:05,950 --> 00:29:07,310 >> Llavors, com faig perquè tot això? 688 00:29:07,310 --> 00:29:11,200 En NoSQL es tracta agregació, no normalització. 689 00:29:11,200 --> 00:29:13,534 Per això volem dir que volem donar suport al patró d'accés. 690 00:29:13,534 --> 00:29:15,283 Si el patró d'accés a les aplicacions, 691 00:29:15,283 --> 00:29:16,770 He de aconseguir tots els meus productes. 692 00:29:16,770 --> 00:29:19,027 Posarem tots els productes en una sola taula. 693 00:29:19,027 --> 00:29:22,110 Si poso tots els productes en una taula, Jo només puc seleccionar tots els productes 694 00:29:22,110 --> 00:29:23,850 d'aquesta taula i em surt tot. 695 00:29:23,850 --> 00:29:25,240 Bé, com ho faig? 696 00:29:25,240 --> 00:29:28,124 Bé, en NoSQL no hi ha estructura a la taula. 697 00:29:28,124 --> 00:29:30,540 Parlarem una mica sobre com funciona això en Dynamo DB. 698 00:29:30,540 --> 00:29:33,570 Però vostè no té el mateix atributs i les mateixes propietats 699 00:29:33,570 --> 00:29:37,751 en cada filera, en cada tema, com ho fa en una taula de SQL. 700 00:29:37,751 --> 00:29:39,750 I el que això em permet de fer un munt de coses 701 00:29:39,750 --> 00:29:41,124 i em dóna molta flexibilitat. 702 00:29:41,124 --> 00:29:45,360 En aquest cas particular, tenir les meves documents de productes. 703 00:29:45,360 --> 00:29:49,090 I en aquest particular, exemple, tot 704 00:29:49,090 --> 00:29:51,930 és un document a la taula Productes. 705 00:29:51,930 --> 00:29:56,510 I el producte d'un llibre pot tenir un ID de tipus que especifica un llibre. 706 00:29:56,510 --> 00:29:59,180 I l'aplicació canviaria en aquest ID. 707 00:29:59,180 --> 00:30:02,570 >> En el nivell d'aplicació, vaig per dir oh, quin tipus de registre és això? 708 00:30:02,570 --> 00:30:04,100 Oh, és un registre de llibres. 709 00:30:04,100 --> 00:30:05,990 Registres de la Llibreta tenen aquestes propietats. 710 00:30:05,990 --> 00:30:08,100 Déjame crear un objecte de llibre. 711 00:30:08,100 --> 00:30:11,289 Així que em vaig a omplir el llibre objecte amb aquest concepte. 712 00:30:11,289 --> 00:30:13,080 Següent article ve i diu, què és aquest article? 713 00:30:13,080 --> 00:30:14,560 Bé, aquest article és un àlbum. 714 00:30:14,560 --> 00:30:17,340 Oh, tinc tota una diferent rutina de processament perquè, 715 00:30:17,340 --> 00:30:18,487 perquè és un àlbum. 716 00:30:18,487 --> 00:30:19,320 Veus el que vull dir? 717 00:30:19,320 --> 00:30:21,950 >> Així que l'aplicació tier-- I només has de seleccionar tots aquests registres. 718 00:30:21,950 --> 00:30:23,200 Tots comencen a entrar. 719 00:30:23,200 --> 00:30:24,680 Podrien ser tots els tipus diferents. 720 00:30:24,680 --> 00:30:27,590 I és la lògica de l'aplicació que els commutadors a través d'aquests tipus 721 00:30:27,590 --> 00:30:29,530 i decideix com processar ells. 722 00:30:29,530 --> 00:30:33,640 >> Un cop més, pel que estem optimitzant el esquema per l'esquema d'accés. 723 00:30:33,640 --> 00:30:36,390 Ho estem fent per col·lapse aquestes taules. 724 00:30:36,390 --> 00:30:39,670 Bàsicament estem prenent aquestes estructures normalitzades, 725 00:30:39,670 --> 00:30:42,000 i estem construint estructures jeràrquiques. 726 00:30:42,000 --> 00:30:45,130 Dins de cada un d'aquests registres Vaig a veure propietats de la matriu. 727 00:30:45,130 --> 00:30:49,400 >> Dins d'aquest document per als àlbums, Estic veient sèries de pistes. 728 00:30:49,400 --> 00:30:53,900 Aquestes pistes ara become-- és bàsicament aquesta taula secundària que 729 00:30:53,900 --> 00:30:56,520 existeix aquí mateix en aquesta estructura. 730 00:30:56,520 --> 00:30:57,975 Així que vostè pot fer això en DynamoDB. 731 00:30:57,975 --> 00:30:59,810 Vostè pot fer això en MongoDB. 732 00:30:59,810 --> 00:31:01,437 Vostè pot fer això en qualsevol base de dades NoSQL. 733 00:31:01,437 --> 00:31:03,520 Crear aquest tipus de estructures de dades jeràrquiques 734 00:31:03,520 --> 00:31:07,120 que li permeten recuperar dades molt ràpidament perquè ara 735 00:31:07,120 --> 00:31:08,537 no han de conformar-se. 736 00:31:08,537 --> 00:31:11,620 En inserir una fila a les Pistes taula, o una fila a la taula Àlbums, 737 00:31:11,620 --> 00:31:13,110 He de complir amb aquest esquema. 738 00:31:13,110 --> 00:31:18,060 He de tenir l'atribut o la propietat que es defineix en aquesta taula. 739 00:31:18,060 --> 00:31:20,480 Cada un d'ells, quan inserit aquesta fila. 740 00:31:20,480 --> 00:31:21,910 Aquest no és el cas en el NoSQL. 741 00:31:21,910 --> 00:31:24,440 >> Puc tenir totalment diferent propietats en tots els documents 742 00:31:24,440 --> 00:31:26,100 que inserit en la col·lecció. 743 00:31:26,100 --> 00:31:30,480 Així mecanisme molt poderós. 744 00:31:30,480 --> 00:31:32,852 I és realment com optimitzar el sistema. 745 00:31:32,852 --> 00:31:35,310 Perquè ara aquesta consulta, en lloc d'unir-se a totes aquestes taules 746 00:31:35,310 --> 00:31:39,160 i l'execució d'una mitja dotzena de consultes a retirar les dades que necessito, 747 00:31:39,160 --> 00:31:40,890 Estic executant una consulta. 748 00:31:40,890 --> 00:31:43,010 I estic iteració a través dels conjunt de resultats. 749 00:31:43,010 --> 00:31:46,512 que et dóna una idea del poder de NoSQL. 750 00:31:46,512 --> 00:31:49,470 Vaig a classe d'anar de costat aquí i parlar una mica sobre això. 751 00:31:49,470 --> 00:31:53,240 Això és més classe de la comercialització o la tecnologia, com 752 00:31:53,240 --> 00:31:55,660 la comercialització de la tecnologia tipus de discussió. 753 00:31:55,660 --> 00:31:58,672 Però és important entendre perquè si ens fixem en la part superior 754 00:31:58,672 --> 00:32:00,380 aquí en aquesta taula, el que estem veient 755 00:32:00,380 --> 00:32:04,030 és el que anomenem el corba bombo tecnologia. 756 00:32:04,030 --> 00:32:06,121 I el que això significa és coses noves entra en joc. 757 00:32:06,121 --> 00:32:07,120 La gent pensa que és genial. 758 00:32:07,120 --> 00:32:09,200 He resolt tots els meus problemes. 759 00:32:09,200 --> 00:32:11,630 >> Aquest podria ser el final tot, ser tot per a tot. 760 00:32:11,630 --> 00:32:12,790 I comencen a usar-lo. 761 00:32:12,790 --> 00:32:14,720 I diuen, això no funciona. 762 00:32:14,720 --> 00:32:17,600 Això no està bé. 763 00:32:17,600 --> 00:32:19,105 El material vell era millor. 764 00:32:19,105 --> 00:32:21,230 I tornen a fer les coses com estaven. 765 00:32:21,230 --> 00:32:22,730 I després, finalment, que vagin, saps què? 766 00:32:22,730 --> 00:32:24,040 Aquest material no és tan dolent. 767 00:32:24,040 --> 00:32:26,192 Oh, així és com funciona. 768 00:32:26,192 --> 00:32:28,900 I una vegada que esbrinar com obres, comencen a millorar. 769 00:32:28,900 --> 00:32:32,050 >> I el curiós al respecte és, quin tipus de línies fins a quin 770 00:32:32,050 --> 00:32:34,300 que anomenem la corba d'adopció de tecnologia. 771 00:32:34,300 --> 00:32:36,910 Així que el que passa és que tenim alguns gallet tecnologia tipus. 772 00:32:36,910 --> 00:32:39,100 En el cas de bases de dades, que és la pressió de dades. 773 00:32:39,100 --> 00:32:42,200 Parlem dels punts alts d'aigua de la pressió de les dades a través del temps. 774 00:32:42,200 --> 00:32:46,310 Quan la pressió que realitza un cert dades punt, que és un disparador tecnologia. 775 00:32:46,310 --> 00:32:47,830 >> S'està fent massa car. 776 00:32:47,830 --> 00:32:49,790 Es triga massa temps per processar les dades. 777 00:32:49,790 --> 00:32:50,890 Necessitem una mica millor. 778 00:32:50,890 --> 00:32:52,890 Vostè obté els innovadors per aquí donant voltes, 779 00:32:52,890 --> 00:32:55,050 tractant d'esbrinar quina és la solució. 780 00:32:55,050 --> 00:32:56,050 Quina és la nova idea? 781 00:32:56,050 --> 00:32:58,170 >> Quina és la millor alternativa manera de fer això? 782 00:32:58,170 --> 00:32:59,530 I vénen amb alguna cosa. 783 00:32:59,530 --> 00:33:03,140 I la gent, el veritable mal, els nois de la punta de llança, 784 00:33:03,140 --> 00:33:06,390 que van a saltar per tot arreu, perquè necessiten una resposta. 785 00:33:06,390 --> 00:33:09,690 Ara el que inevitablement happens-- i està succeint ara mateix a NoSQL. 786 00:33:09,690 --> 00:33:11,090 Ho veig tot el temps. 787 00:33:11,090 --> 00:33:13,610 >> El que passa, inevitablement, és la gent comença a utilitzar la nova eina 788 00:33:13,610 --> 00:33:15,490 de la mateixa manera que utilitza l'eina d'edat. 789 00:33:15,490 --> 00:33:17,854 I s'adonen que no funciona tan bé. 790 00:33:17,854 --> 00:33:20,020 No puc recordar qui era jo parlant amb el dia d'avui. 791 00:33:20,020 --> 00:33:22,080 Però és com, quan el martell pneumàtic va ser inventat, 792 00:33:22,080 --> 00:33:24,621 la gent no swing més el seu cap per trencar el formigó. 793 00:33:24,621 --> 00:33:27,360 794 00:33:27,360 --> 00:33:30,610 >> Però això és el que hi ha passant amb NoSQL avui. 795 00:33:30,610 --> 00:33:33,900 Si entres en la majoria de botigues, que estan tractant de ser botigues NoSQL. 796 00:33:33,900 --> 00:33:36,510 El que estan fent és que estan fent servir NoSQL, 797 00:33:36,510 --> 00:33:39,900 i estan carregar plena d'esquema relacional. 798 00:33:39,900 --> 00:33:41,630 Perquè així és com dissenyar bases de dades. 799 00:33:41,630 --> 00:33:44,046 I estan preguntant, per què és no dur a terme molt bé? 800 00:33:44,046 --> 00:33:45,230 Noi, això fa pudor. 801 00:33:45,230 --> 00:33:49,900 Vaig haver de mantenir tot el meu uneix en-- és com, no, no. 802 00:33:49,900 --> 00:33:50,800 Mantenir uneix? 803 00:33:50,800 --> 00:33:52,430 Per què estan unint a les dades? 804 00:33:52,430 --> 00:33:54,350 No s'inscriu dades NoSQL. 805 00:33:54,350 --> 00:33:55,850 Vostè agregada ella. 806 00:33:55,850 --> 00:34:00,690 >> Així que si vols evitar això, aprendre com funciona l'eina abans que realment 807 00:34:00,690 --> 00:34:02,010 començar a usar-lo. 808 00:34:02,010 --> 00:34:04,860 No tractar d'utilitzar les noves eines de la mateixa manera que va utilitzar les velles eines. 809 00:34:04,860 --> 00:34:06,500 Vas a tenir una mala experiència. 810 00:34:06,500 --> 00:34:08,848 I cada vegada això és el que es tracta. 811 00:34:08,848 --> 00:34:11,389 Quan vam començar a venir aquí, és perquè la gent descobert 812 00:34:11,389 --> 00:34:13,449 com usar les eines. 813 00:34:13,449 --> 00:34:16,250 >> Ells van fer el mateix quan bases de dades relacionals es van inventar, 814 00:34:16,250 --> 00:34:17,969 i van ser reemplaçant als sistemes d'arxius. 815 00:34:17,969 --> 00:34:20,420 Van tractar de crear sistemes de fitxers amb bases de dades relacionals 816 00:34:20,420 --> 00:34:22,159 perquè això és el entenen les persones. 817 00:34:22,159 --> 00:34:23,049 No va funcionar. 818 00:34:23,049 --> 00:34:26,090 Així que la comprensió de les millors pràctiques de la tecnologia que està treballant 819 00:34:26,090 --> 00:34:26,730 és enorme. 820 00:34:26,730 --> 00:34:29,870 Molt important. 821 00:34:29,870 --> 00:34:32,440 >> Així que entrarem en DynamoDB. 822 00:34:32,440 --> 00:34:36,480 DynamoDB és de AWS totalment gestionats plataforma NoSQL. 823 00:34:36,480 --> 00:34:37,719 Què significa gestionats totalment vol dir? 824 00:34:37,719 --> 00:34:40,010 Això vol dir que no cal realment preocupar de res. 825 00:34:40,010 --> 00:34:42,060 >> Entres, li dius nosaltres, que ens cal una taula. 826 00:34:42,060 --> 00:34:43,409 Es necessita tanta capacitat. 827 00:34:43,409 --> 00:34:47,300 Es prem el botó, i la provisió que tota la infraestructura darrere de l'escena. 828 00:34:47,300 --> 00:34:48,310 Ara que és enorme. 829 00:34:48,310 --> 00:34:51,310 >> Perquè quan parles sobre l'expansió d'una base de dades, 830 00:34:51,310 --> 00:34:53,917 Clústers de dades NoSQL en escala, petabytes de funcionament, 831 00:34:53,917 --> 00:34:55,750 corrent milions de transaccions per segon, 832 00:34:55,750 --> 00:34:58,180 aquestes coses no són petits raïms. 833 00:34:58,180 --> 00:35:00,830 Estem parlant de milers de casos. 834 00:35:00,830 --> 00:35:04,480 La gestió de milers de casos, fins i tot instàncies virtuals, 835 00:35:04,480 --> 00:35:06,350 és un veritable mal al cul. 836 00:35:06,350 --> 00:35:09,110 Vull dir, penso cada vegada que un pegat de sistema operatiu surt 837 00:35:09,110 --> 00:35:11,552 o una nova versió de la base de dades. 838 00:35:11,552 --> 00:35:13,260 Què vol dir això a vostè operacionalment? 839 00:35:13,260 --> 00:35:16,330 Això vol dir que tens 1200 servidors que necessiten ser actualitzats. 840 00:35:16,330 --> 00:35:18,960 Ara, fins i tot amb l'automatització, que pot portar molt de temps. 841 00:35:18,960 --> 00:35:21,480 Això pot causar una gran quantitat de mals de cap operacionals, 842 00:35:21,480 --> 00:35:23,090 perquè vaig a tenir serveis de sota. 843 00:35:23,090 --> 00:35:26,070 >> Com puc actualitzar aquestes bases de dades, que podria fer desplegaments verd blau 844 00:35:26,070 --> 00:35:29,420 on puc implementar i actualitzar la meitat del meu nodes i, a continuació, actualitzar l'altra meitat. 845 00:35:29,420 --> 00:35:30,490 Prengui els baix. 846 00:35:30,490 --> 00:35:33,410 Per tant la gestió de la infraestructura escala és enormement dolorós. 847 00:35:33,410 --> 00:35:36,210 I AWS prendre que el dolor fora d'ell. 848 00:35:36,210 --> 00:35:39,210 I les bases de dades NoSQL pot ser extraordinàriament dolorosa 849 00:35:39,210 --> 00:35:41,780 causa de la manera en què l'escala. 850 00:35:41,780 --> 00:35:42,926 >> Escala horitzontal. 851 00:35:42,926 --> 00:35:45,550 Si vols aconseguir un NoSQL gran base de dades, vostè compra més nodes. 852 00:35:45,550 --> 00:35:48,660 Cada node que vostè compra és un altre mal de cap operativa. 853 00:35:48,660 --> 00:35:50,830 Així que deixeu que algú més ho faci per vostè. 854 00:35:50,830 --> 00:35:52,000 AWS pot fer això. 855 00:35:52,000 --> 00:35:54,587 >> Donem suport valors clau document. 856 00:35:54,587 --> 00:35:56,670 Ara no vam ser massa en en l'altre gràfic. 857 00:35:56,670 --> 00:35:58,750 Hi ha un munt de diferents sabors de NoSQL. 858 00:35:58,750 --> 00:36:02,670 Són tot tipus d'aconseguir munged junts en aquest punt. 859 00:36:02,670 --> 00:36:06,260 Vostè pot mirar DynamoDB i dir que sí, els dos som un document i un valor clau 860 00:36:06,260 --> 00:36:08,412 emmagatzemar aquest punt. 861 00:36:08,412 --> 00:36:10,620 I vostè pot discutir les característiques d'un sobre l'altre. 862 00:36:10,620 --> 00:36:13,950 Per a mi, molt d'això és realment de sis de la meitat d'una dotzena dels altres. 863 00:36:13,950 --> 00:36:18,710 Cadascuna d'aquestes tecnologies és una tecnologia fina i una multa solució. 864 00:36:18,710 --> 00:36:23,390 Jo no diria que MongoDB és millor o pitjor que Couch, a continuació, Cassandra, 865 00:36:23,390 --> 00:36:25,994 llavors Dynamo, o viceversa. 866 00:36:25,994 --> 00:36:27,285 Vull dir, aquests són només opcions. 867 00:36:27,285 --> 00:36:29,850 868 00:36:29,850 --> 00:36:32,700 >> És ràpid i és consistent en qualsevol escala. 869 00:36:32,700 --> 00:36:36,210 Així que aquest és un dels més grans bonificacions que reben amb AWS. 870 00:36:36,210 --> 00:36:40,850 Amb DynamoDB és la capacitat per obtenir un sol dígit sota 871 00:36:40,850 --> 00:36:44,040 latència de milisegons a qualsevol escala. 872 00:36:44,040 --> 00:36:45,720 Aquest va ser un objectiu de disseny del sistema. 873 00:36:45,720 --> 00:36:49,130 I tenim clients que estan fent milions de transaccions per segon. 874 00:36:49,130 --> 00:36:52,670 >> Ara vaig a anar a través d'alguns dels casos d'ús en pocs minuts aquí. 875 00:36:52,670 --> 00:36:55,660 Control-- accés integrat tenim el que anomenem 876 00:36:55,660 --> 00:36:57,920 Identitat Access Management o IAM. 877 00:36:57,920 --> 00:37:01,980 Impregna tot sistema, tots els serveis que ofereix AWS. 878 00:37:01,980 --> 00:37:03,630 DynamoDB no és una excepció. 879 00:37:03,630 --> 00:37:06,020 Podeu controlar l'accés a les taules DynamoDB. 880 00:37:06,020 --> 00:37:09,960 A través de tots els comptes de AWS definició de funcions d'accés i permisos 881 00:37:09,960 --> 00:37:12,140 en la infraestructura d'IAM. 882 00:37:12,140 --> 00:37:16,630 >> I és un component essencial en el el que anomenem Esdeveniment Programació Driven. 883 00:37:16,630 --> 00:37:19,056 Ara bé, aquest és un nou paradigma. 884 00:37:19,056 --> 00:37:22,080 >> AUDIÈNCIA: Com és la seva taxa de veritat positius davant falsos negatius 885 00:37:22,080 --> 00:37:24,052 en el seu sistema de control d'accés? 886 00:37:24,052 --> 00:37:26,260 RICK Houlihan: Els veritables positius enfront de falsos negatius? 887 00:37:26,260 --> 00:37:28,785 AUDIÈNCIA: Tornant el vostè ha de tornar? 888 00:37:28,785 --> 00:37:33,720 A diferència de tant en tant no torna quan hauria de validar? 889 00:37:33,720 --> 00:37:36,260 890 00:37:36,260 --> 00:37:38,050 >> RICK Houlihan: No li podia dir això. 891 00:37:38,050 --> 00:37:40,140 Si hi ha qualsevol error algun en què, 892 00:37:40,140 --> 00:37:42,726 No sóc la persona per preguntar aquesta pregunta en particular. 893 00:37:42,726 --> 00:37:43,850 Però això és una bona pregunta. 894 00:37:43,850 --> 00:37:45,905 Seria curiós saber que jo, en realitat. 895 00:37:45,905 --> 00:37:48,810 896 00:37:48,810 --> 00:37:51,320 >> I així, de nou, nou paradigma és la programació orientada a esdeveniments. 897 00:37:51,320 --> 00:37:55,160 Aquesta és la idea que pugui implementar aplicacions complexes que 898 00:37:55,160 --> 00:37:59,720 pot operar una molt alta escala molt sense qualsevol infraestructura de cap tipus. 899 00:37:59,720 --> 00:38:02,120 Sense cap tipus fix infraestructura. 900 00:38:02,120 --> 00:38:04,720 I parlarem una mica sobre el que això significa, ja que 901 00:38:04,720 --> 00:38:06,550 arribar a la següent parell de cartes. 902 00:38:06,550 --> 00:38:08,716 >> El primer que farem és parlarem de taules. 903 00:38:08,716 --> 00:38:10,857 Tipus de dades API per Dynamo. 904 00:38:10,857 --> 00:38:13,190 I la primera cosa que vostè compte quan ens fixem en això, 905 00:38:13,190 --> 00:38:17,930 si està familiaritzat amb qualsevol base de dades, bases de dades tenen realment dos tipus d'APIs 906 00:38:17,930 --> 00:38:18,430 Jo en diria. 907 00:38:18,430 --> 00:38:21,570 O dos conjunts d'API. 908 00:38:21,570 --> 00:38:23,840 Un d'ells seria API administrativa. 909 00:38:23,840 --> 00:38:26,710 >> Les coses que s'ocupen de les funcions de la base de dades. 910 00:38:26,710 --> 00:38:31,340 Configuració del motor d'emmagatzematge, la configuració i l'addició de taules. 911 00:38:31,340 --> 00:38:35,180 base de dades de creació catàlegs i instàncies. 912 00:38:35,180 --> 00:38:40,450 Aquests coses-- en DynamoDB, que tenen molt curts, llistes curtes. 913 00:38:40,450 --> 00:38:43,120 >> Així que en altres bases de dades, vostè pot veure a desenes 914 00:38:43,120 --> 00:38:45,680 d'ordres, d'administratiu comandaments, per configurar 915 00:38:45,680 --> 00:38:47,290 aquestes opcions addicionals. 916 00:38:47,290 --> 00:38:51,234 En DynamoDB que no cal perquè els no configura el sistema, el que fem. 917 00:38:51,234 --> 00:38:54,150 Així que l'únic que ha de fer és digues-me quina mida de la taula em cal. 918 00:38:54,150 --> 00:38:55,660 Així s'obté una molt conjunt limitat d'ordres. 919 00:38:55,660 --> 00:38:58,618 >> Vostè rep un CREATE TABLE actualització, Taula, Eliminar la taula, i descriure la taula. 920 00:38:58,618 --> 00:39:01,150 Aquestes són les úniques coses el que necessites per DynamoDB. 921 00:39:01,150 --> 00:39:03,294 Vostè no necessita un emmagatzematge configuració del motor. 922 00:39:03,294 --> 00:39:04,960 No necessito de preocupar sobre la replicació. 923 00:39:04,960 --> 00:39:06,490 No necessito de preocupar sharding. 924 00:39:06,490 --> 00:39:07,800 >> No necessito de preocupar sobre qualsevol d'aquestes coses. 925 00:39:07,800 --> 00:39:08,740 Ho fem tot per vostè. 926 00:39:08,740 --> 00:39:11,867 Així que això és una gran quantitat de sobrecàrrega això és només aixecar el seu plat. 927 00:39:11,867 --> 00:39:13,200 Després tenim els operadors CRUD. 928 00:39:13,200 --> 00:39:17,740 CRUD és una cosa del que trucar a la base de dades que és 929 00:39:17,740 --> 00:39:19,860 Crear, actualitzar, eliminar operadors. 930 00:39:19,860 --> 00:39:24,180 Aquests són el comú les operacions de base de dades. 931 00:39:24,180 --> 00:39:31,299 Coses com a punt de venda, aconsegueix l'article, actualització elements, eliminar elements, consulta per lots, escanejar. 932 00:39:31,299 --> 00:39:32,840 Si voleu escanejar tota la taula. 933 00:39:32,840 --> 00:39:34,220 Tiri tota la taula. 934 00:39:34,220 --> 00:39:37,130 Una de les coses bones de DynamoDB és que permet l'escaneig paral·lel. 935 00:39:37,130 --> 00:39:40,602 Així que en realitat es pot fer-me saber quants fils desitja executar en aquesta exploració. 936 00:39:40,602 --> 00:39:41,810 I podem executar aquests fils. 937 00:39:41,810 --> 00:39:43,985 Podem girar que mira cap amunt a través de múltiples fils 938 00:39:43,985 --> 00:39:49,060 així que vostè pot escanejar tota la taula espai molt, molt ràpidament en DynamoDB. 939 00:39:49,060 --> 00:39:51,490 >> L'altra API que tenim és el que anomenem la nostra API Rierols. 940 00:39:51,490 --> 00:39:52,940 No anem a parlar massa molt d'això ara. 941 00:39:52,940 --> 00:39:55,189 Tinc una mica de contingut més tard en la baralla sobre això. 942 00:39:55,189 --> 00:39:59,910 Però Streams és realment un running-- pensar en ell com el temps va ordenar 943 00:39:59,910 --> 00:40:01,274 i registre de canvis de particions. 944 00:40:01,274 --> 00:40:03,940 Tot el que està succeint en la taula es mostra en la seqüència. 945 00:40:03,940 --> 00:40:05,940 >> Cada escriptura en la taula apareix en el corrent. 946 00:40:05,940 --> 00:40:08,370 Vostè pot llegir aquest corrent, i es poden fer coses amb ell. 947 00:40:08,370 --> 00:40:10,150 Anem a parlar del que tipus de coses que vostè 948 00:40:10,150 --> 00:40:13,680 veure amb les coses com la replicació, la creació d'índexs secundaris. 949 00:40:13,680 --> 00:40:17,620 Tot tipus de genial coses que pots fer amb això. 950 00:40:17,620 --> 00:40:19,150 >> Els tipus de dades. 951 00:40:19,150 --> 00:40:23,320 En DynamoDB, donem suport tant clau de valor i dades de documents tipus. 952 00:40:23,320 --> 00:40:26,350 A la part esquerra de la pantalla aquí, tenim els nostres tipus bàsics. 953 00:40:26,350 --> 00:40:27,230 Tipus de valor clau. 954 00:40:27,230 --> 00:40:30,040 Aquests són cadenes, nombres i els binaris. 955 00:40:30,040 --> 00:40:31,640 >> Així que només tres tipus bàsics. 956 00:40:31,640 --> 00:40:33,700 I llavors vostè pot tenir conjunts d'aquests. 957 00:40:33,700 --> 00:40:37,650 Una de les coses bones de NoSQL és pot contenir matrius com a propietats. 958 00:40:37,650 --> 00:40:42,050 I amb DynamoDB pot contenir matrius de tipus bàsics com una propietat arrel. 959 00:40:42,050 --> 00:40:43,885 >> I després hi ha els tipus de documents. 960 00:40:43,885 --> 00:40:45,510 Quantes persones estan familiaritzats amb JSON? 961 00:40:45,510 --> 00:40:47,130 Vostès estan familiaritzats amb JSON tant? 962 00:40:47,130 --> 00:40:49,380 Es tracta bàsicament de JavaScript, Objecte, notació. 963 00:40:49,380 --> 00:40:52,510 Li permet, bàsicament, definir una estructura jeràrquica. 964 00:40:52,510 --> 00:40:58,107 >> Podeu desar un document en JSON DynamoDB usant components comuns 965 00:40:58,107 --> 00:41:00,940 o blocs de construcció que estan disponibles en la majoria dels llenguatges de programació. 966 00:41:00,940 --> 00:41:03,602 Així que si vostè té Java, ets mirant els mapes i llistes. 967 00:41:03,602 --> 00:41:05,060 Puc crear objectes que del mapa. 968 00:41:05,060 --> 00:41:08,030 Un mapa com a valors clau emmagatzemat com propietats. 969 00:41:08,030 --> 00:41:10,890 I podria tenir llistes de valors dins d'aquestes propietats. 970 00:41:10,890 --> 00:41:13,490 Pot emmagatzemar aquest complex estructura jeràrquica 971 00:41:13,490 --> 00:41:16,320 com un sol atribut d'un element DynamoDB. 972 00:41:16,320 --> 00:41:19,010 973 00:41:19,010 --> 00:41:24,460 >> Així taules en DynamoDB, com la majoria Bases de dades NoSQL, taules tenen elements. 974 00:41:24,460 --> 00:41:26,469 En MongoDB ho faria cridar a aquests documents. 975 00:41:26,469 --> 00:41:27,760 I seria la base sofà. 976 00:41:27,760 --> 00:41:28,900 També una base de dades documental. 977 00:41:28,900 --> 00:41:29,941 Vostè crida a aquests documents. 978 00:41:29,941 --> 00:41:32,930 Documents o elements tenen atributs. 979 00:41:32,930 --> 00:41:35,850 Poden existir atributs o no existeix en l'article. 980 00:41:35,850 --> 00:41:38,520 En DynamoDB, hi ha un atribut obligatori. 981 00:41:38,520 --> 00:41:43,880 Igual que en una base de dades relacional, vostè té una clau principal a la taula. 982 00:41:43,880 --> 00:41:46,010 >> DynamoDB té el que anomenem una clau hash. 983 00:41:46,010 --> 00:41:48,280 Clau hash ha de ser únic. 984 00:41:48,280 --> 00:41:52,580 Així que quan em defineixo una taula hash, bàsicament el que estic dient 985 00:41:52,580 --> 00:41:54,110 és cada article tindrà una clau hash. 986 00:41:54,110 --> 00:41:58,520 I cada tecla coixinet ha de ser únic. 987 00:41:58,520 --> 00:42:01,200 >> Cada article es defineix per aquesta clau hash únic. 988 00:42:01,200 --> 00:42:02,940 I només pot haver un. 989 00:42:02,940 --> 00:42:05,820 Això està bé, però moltes vegades el que la gent necessita 990 00:42:05,820 --> 00:42:08,170 és que volen és aquest hash clau per fer una mica més 991 00:42:08,170 --> 00:42:11,010 que simplement ser un identificador únic. 992 00:42:11,010 --> 00:42:15,240 Moltes vegades volem utilitzar-la hash com la part superior de cub agregació nivell. 993 00:42:15,240 --> 00:42:19,160 I la manera de fer això és per afegint el que anomenem una clau gamma. 994 00:42:19,160 --> 00:42:22,460 >> Així que si és només un hash taula, aquest ha de ser únic. 995 00:42:22,460 --> 00:42:27,040 Si es tracta d'una taula hash i el rang, la combinació de l'haixix i la gamma 996 00:42:27,040 --> 00:42:28,640 ha de ser únic. 997 00:42:28,640 --> 00:42:30,110 Així que pensar-hi d'aquesta manera. 998 00:42:30,110 --> 00:42:32,140 Si tinc un fòrum. 999 00:42:32,140 --> 00:42:39,010 I la forma té temes, té llocs, i té respostes. 1000 00:42:39,010 --> 00:42:42,630 >> Així que vaig a tenir un hash clau, que és l'identificador de tema. 1001 00:42:42,630 --> 00:42:46,650 I jo podria tenir una clau de gamma, que és la ID de resposta. 1002 00:42:46,650 --> 00:42:49,650 D'aquesta forma si vull obtenir tota la respostes per a determinat tema, 1003 00:42:49,650 --> 00:42:52,370 Jo només puc consultar el hash. 1004 00:42:52,370 --> 00:42:55,190 Jo només puc dir em dóna tot els elements que tenen aquest hash. 1005 00:42:55,190 --> 00:43:01,910 I jo vaig a posar totes les preguntes o publicar-los per aquest tema en particular. 1006 00:43:01,910 --> 00:43:03,910 Aquestes agrupacions de primer nivell són molt importants. 1007 00:43:03,910 --> 00:43:07,370 Donen suport a l'accés primari patró de l'aplicació. 1008 00:43:07,370 --> 00:43:09,420 En termes generals, aquest és el que volem fer. 1009 00:43:09,420 --> 00:43:11,780 Volem que table-- com es carrega la taula, 1010 00:43:11,780 --> 00:43:16,640 volem estructurar les dades dins de la taula d'una manera tal 1011 00:43:16,640 --> 00:43:20,140 que l'aplicació pot molt recuperar ràpidament els resultats. 1012 00:43:20,140 --> 00:43:24,510 I sovint la forma de fer-ho és per mantenir aquestes agregacions com ens 1013 00:43:24,510 --> 00:43:25,650 inserir les dades. 1014 00:43:25,650 --> 00:43:31,110 Bàsicament, estem estenent les dades a la galleda brillant, ja que ve a. 1015 00:43:31,110 --> 00:43:35,210 >> Tecles Range permeten picada mi-- claus han d'haver igualtat. 1016 00:43:35,210 --> 00:43:39,490 Quan consulta un coixinet, que he de dir dóna'm un hash que és igual a això. 1017 00:43:39,490 --> 00:43:41,950 Quan consulta una gamma, que pot dir-me una gamma 1018 00:43:41,950 --> 00:43:47,040 que és l'ús de qualsevol tipus de rica operador que donem suport. 1019 00:43:47,040 --> 00:43:49,200 Dóna'm tots els elements per a un hash. 1020 00:43:49,200 --> 00:43:52,520 És igual, més gran que, menys, què començar, 1021 00:43:52,520 --> 00:43:54,145 ¿Existeix entre aquests dos valors? 1022 00:43:54,145 --> 00:43:56,811 Així que aquest tipus de consultes de rang que estem sempre interessats en. 1023 00:43:56,811 --> 00:43:59,650 Ara una cosa sobre les dades, quan ens fixem en l'accés a les dades, quan 1024 00:43:59,650 --> 00:44:02,360 accedir a les dades, és Sempre es tracta d'una agregació. 1025 00:44:02,360 --> 00:44:05,770 Sempre es tracta dels registres que tenen a veure amb això. 1026 00:44:05,770 --> 00:44:10,390 Dóna'm tot el que aquí Això és-- tot les transaccions en aquesta targeta de crèdit 1027 00:44:10,390 --> 00:44:12,500 per a l'últim mes. 1028 00:44:12,500 --> 00:44:13,960 Això és una agregació. 1029 00:44:13,960 --> 00:44:17,490 >> Gairebé tot el que fas en el base de dades és una espècie d'agregació. 1030 00:44:17,490 --> 00:44:21,530 Així que ser capaç de ser capaç de definir aquests cubs i donar-li aquests van 1031 00:44:21,530 --> 00:44:24,950 atributs per poder consultar a, aquestes consultes rics donen suport a molts, 1032 00:44:24,950 --> 00:44:27,165 molts, molts patrons d'accés de l'aplicació. 1033 00:44:27,165 --> 00:44:30,990 1034 00:44:30,990 --> 00:44:35,000 >> Així que l'altra cosa la tecla coixinet fa és que ens dóna un mecanisme 1035 00:44:35,000 --> 00:44:37,740 per ser capaç de difondre les dades voltant. 1036 00:44:37,740 --> 00:44:40,390 Bases de dades NoSQL funcionen millor quan les dades són uniformement 1037 00:44:40,390 --> 00:44:41,740 distribuït en tot el clúster. 1038 00:44:41,740 --> 00:44:44,530 1039 00:44:44,530 --> 00:44:47,050 Quantes persones són familiars amb algoritmes hash? 1040 00:44:47,050 --> 00:44:49,860 Quan dic hash i un hashing-- perquè un algoritme de hash 1041 00:44:49,860 --> 00:44:54,140 és una manera de ser capaç de generar un valor aleatori de qualsevol valor donat. 1042 00:44:54,140 --> 00:44:59,300 Així que en aquest cas particular, l' algoritme de hash correm és ND 5 basat. 1043 00:44:59,300 --> 00:45:04,765 >> I si tinc una identificació, i això és el meu clau hash, tinc 1, 2, 3. 1044 00:45:04,765 --> 00:45:07,390 Quan executo l'algoritme de hash, que va a tornar i dir, 1045 00:45:07,390 --> 00:45:10,800 bé 1 és igual a 7B, 2 és igual a 48, 3 és igual a CD. 1046 00:45:10,800 --> 00:45:13,092 Estan repartits per tot l'espai de claus. 1047 00:45:13,092 --> 00:45:14,050 I per què fas això? 1048 00:45:14,050 --> 00:45:17,120 A causa que s'assegura que puc posar els registres a través de múltiples nodes. 1049 00:45:17,120 --> 00:45:19,574 >> Si jo estic fent això incremental, 1, 2, 3. 1050 00:45:19,574 --> 00:45:21,990 I tinc un rang hash que carreres en aquest cas particular, 1051 00:45:21,990 --> 00:45:24,785 un petit espai de hash, que va des de 00 a FF, 1052 00:45:24,785 --> 00:45:27,951 a continuació, els registres vindran a i que van a anar a 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 Què passa? 1055 00:45:31,800 --> 00:45:34,860 Cada inserit va al mateix node. 1056 00:45:34,860 --> 00:45:36,070 Veus el que vull dir? 1057 00:45:36,070 --> 00:45:40,910 >> Perquè quan em vaig separar l'espai, i jo vaig estendre aquests registres a través de, 1058 00:45:40,910 --> 00:45:45,950 i la partició jo, jo vaig a dir partició 1 té espai de claus 0-54. 1059 00:45:45,950 --> 00:45:47,720 Partició 2 és 55-89. 1060 00:45:47,720 --> 00:45:49,780 Partició 3 és AA a FF. 1061 00:45:49,780 --> 00:45:53,740 Així que si estic fent servir linealment incrementant Identificadors, es pot veure el que està succeint. 1062 00:45:53,740 --> 00:45:57,410 1, 2, 3, 4, 5, 6, tot el camí fins a 54. 1063 00:45:57,410 --> 00:46:00,030 Així com estic colpejant la registres en el sistema, 1064 00:46:00,030 --> 00:46:02,030 tot acaba anant a un node. 1065 00:46:02,030 --> 00:46:03,160 >> Això no és bo. 1066 00:46:03,160 --> 00:46:04,820 Aquest és un anti patró. 1067 00:46:04,820 --> 00:46:08,760 En MongoDB tenen aquest problema si vostè no utilitza una clau hash. 1068 00:46:08,760 --> 00:46:11,325 MongoDB li dóna l'opció de hash el valor clau. 1069 00:46:11,325 --> 00:46:13,950 Vostè sempre ha de fer això, si utilitzeu un hash incrementant 1070 00:46:13,950 --> 00:46:17,380 clau en MongoDB, o serà clavant cada escriptura per a un node, 1071 00:46:17,380 --> 00:46:21,290 i se li limitant el seu rendiment d'escriptura malament. 1072 00:46:21,290 --> 00:46:24,896 >> AUDIÈNCIA: És que A9 169 en decimal? 1073 00:46:24,896 --> 00:46:28,450 >> RICK Houlihan: Sí, és en algun lloc per allà. 1074 00:46:28,450 --> 00:46:29,950 A9, jo no ho sé. 1075 00:46:29,950 --> 00:46:32,200 Caldria aconseguir el meu binària a la calculadora decimal. 1076 00:46:32,200 --> 00:46:34,237 El meu cervell no funciona d'aquesta manera. 1077 00:46:34,237 --> 00:46:36,320 AUDIÈNCIA: Només una ràpida dels seus comentaris Mongo. 1078 00:46:36,320 --> 00:46:39,530 Així és l'ID d'objecte que ve nativa amb Mongo fer això? 1079 00:46:39,530 --> 00:46:40,179 1080 00:46:40,179 --> 00:46:41,470 RICK Houlihan: Fa això? 1081 00:46:41,470 --> 00:46:42,970 Si s'especifica la mateixa. 1082 00:46:42,970 --> 00:46:45,030 Amb MongoDB, vostè té l'opció. 1083 00:46:45,030 --> 00:46:48,930 Pot specify-- cada document en MongoDB ha de tenir un ID de subratllat. 1084 00:46:48,930 --> 00:46:50,300 Aquest és el valor únic. 1085 00:46:50,300 --> 00:46:55,240 >> En MongoDB pot especificar ja sigui per discutir o no. 1086 00:46:55,240 --> 00:46:56,490 Ells només li donen l'opció. 1087 00:46:56,490 --> 00:46:58,198 Si vostè sap que és a l'atzar, cap problema. 1088 00:46:58,198 --> 00:46:59,640 Vostè no ha de fer això. 1089 00:46:59,640 --> 00:47:04,260 Si vostè sap que no és a l'atzar, que està incrementant, i després fer el hash. 1090 00:47:04,260 --> 00:47:06,880 >> Ara el que passa hash, una vegada que hash de 1091 00:47:06,880 --> 00:47:08,800 1 value-- i això és per què claus hash són sempre 1092 00:47:08,800 --> 00:47:13,740 consultes úniques, perquè he canviat el valor, ara no pot fer una consulta gamma. 1093 00:47:13,740 --> 00:47:15,640 No puc dir que és això entre això o allò, 1094 00:47:15,640 --> 00:47:20,800 pel fet que el valor de resum no va ser equivalent al valor real. 1095 00:47:20,800 --> 00:47:24,570 Així que quan vostè hash que clau, és només la igualtat. 1096 00:47:24,570 --> 00:47:28,700 Per això, en clau hash DynamoDB consultes són sempre només la igualtat. 1097 00:47:28,700 --> 00:47:32,090 1098 00:47:32,090 --> 00:47:34,700 >> Així que ara en un rang key-- quan afegeixo aquesta clau gamma, 1099 00:47:34,700 --> 00:47:38,180 aquests registres claus abast tots entren i que s'emmagatzemen en la mateixa partició. 1100 00:47:38,180 --> 00:47:42,430 Així que són molt ràpidament, fàcilment recuperada perquè aquest és el haixix, 1101 00:47:42,430 --> 00:47:43,220 aquest és el rang. 1102 00:47:43,220 --> 00:47:44,928 I es veu tot amb el mateix hash 1103 00:47:44,928 --> 00:47:48,550 s'emmagatzema en el mateix espai de partició. 1104 00:47:48,550 --> 00:47:53,889 Vostè pot usar aquesta clau gamma per ajudar localitzar les seves dades a prop del seu pare. 1105 00:47:53,889 --> 00:47:55,180 Llavors, què estic fent realment aquí? 1106 00:47:55,180 --> 00:47:57,320 Aquesta és una d'un a molts relació. 1107 00:47:57,320 --> 00:48:01,490 La relació entre una clau hash i la tecla de rang és d'un a molts. 1108 00:48:01,490 --> 00:48:03,490 Puc tenir diverses claus hash. 1109 00:48:03,490 --> 00:48:07,610 Només puc tenir rang múltiple claus dins de cada tecla coixinet. 1110 00:48:07,610 --> 00:48:11,910 >> El hash defineix el pare, el rang defineix els nens. 1111 00:48:11,910 --> 00:48:15,240 Així que vostè pot veure que hi ha analògic aquí entre el constructe relacional 1112 00:48:15,240 --> 00:48:18,840 i els mateixos tipus de construeix en NoSQL. 1113 00:48:18,840 --> 00:48:20,760 La gent parla de NoSQL com no relacional. 1114 00:48:20,760 --> 00:48:22,200 No és no relacional. 1115 00:48:22,200 --> 00:48:24,680 Les dades sempre té relacions. 1116 00:48:24,680 --> 00:48:28,172 Aquestes relacions simplement es modelen de manera diferent. 1117 00:48:28,172 --> 00:48:29,880 Anem a parlar una mica poc sobre la durabilitat. 1118 00:48:29,880 --> 00:48:34,860 Quan s'escriu a DynamoDB, escriu són sempre tres vies replicat. 1119 00:48:34,860 --> 00:48:37,550 El que vol dir que tenim tres AZ de. 1120 00:48:37,550 --> 00:48:39,160 AZ de són zones de disponibilitat. 1121 00:48:39,160 --> 00:48:43,430 Vostè pot pensar en una disponibilitat Zona com un centre de dades 1122 00:48:43,430 --> 00:48:45,447 o una col·lecció de centres de dades. 1123 00:48:45,447 --> 00:48:47,780 Aquestes coses són geogràficament aïllats els uns dels altres 1124 00:48:47,780 --> 00:48:51,610 a través de diferents zones de falles, a través de diferents xarxes elèctriques i les planes d'inundació. 1125 00:48:51,610 --> 00:48:54,510 Una fallada en un AZ no és va acabar amb l'altre. 1126 00:48:54,510 --> 00:48:56,890 Ells també estan vinculats juntament amb la fibra fosca. 1127 00:48:56,890 --> 00:49:01,240 És compatible amb una sub 1 latència de mil·lisegons entre AZS. 1128 00:49:01,240 --> 00:49:05,390 Així replicacions de dades en temps real capaç en múltiples AZS. 1129 00:49:05,390 --> 00:49:09,990 >> I moltes vegades els desplegaments múltiples Alfabet complir amb els requisits d'alta disponibilitat 1130 00:49:09,990 --> 00:49:12,930 de la majoria de les organitzacions empresarials. 1131 00:49:12,930 --> 00:49:16,139 Així DynamoDB es propaga a través de tres AZS per defecte. 1132 00:49:16,139 --> 00:49:19,430 Només anem al coneixement de l'escriptura quan dos d'aquests tres nodes tornen 1133 00:49:19,430 --> 00:49:21,470 i dic: Sí, ho tinc. 1134 00:49:21,470 --> 00:49:22,050 Perquè és això? 1135 00:49:22,050 --> 00:49:25,950 A causa de que en el costat de lectura només estem vaig a donar les dades de nou quan 1136 00:49:25,950 --> 00:49:27,570 ho fem a partir de dos nodes. 1137 00:49:27,570 --> 00:49:30,490 >> Si estic replicant en tot 3, i estic llegint de dos, 1138 00:49:30,490 --> 00:49:32,840 Sempre estic garantit per tenir almenys una 1139 00:49:32,840 --> 00:49:35,720 dels que llegeix ser el més còpia actualitzada de les dades. 1140 00:49:35,720 --> 00:49:38,340 Això és el que fa DynamoDB consistent. 1141 00:49:38,340 --> 00:49:42,450 Ara vostè pot optar per activar aquells consistents llegeix fora. 1142 00:49:42,450 --> 00:49:45,070 En aquest cas vaig a dir, Jo només vaig a llegir d'un node. 1143 00:49:45,070 --> 00:49:47,430 I no puc garantir que va sent les dades més actuals. 1144 00:49:47,430 --> 00:49:49,450 >> Així que si una escriptura està entrant, no ha replicat encara, 1145 00:49:49,450 --> 00:49:50,360 vostè va a aconseguir que la còpia. 1146 00:49:50,360 --> 00:49:52,220 Aquesta és una lectura finalment coherent. 1147 00:49:52,220 --> 00:49:54,640 I el que és això és la meitat del cost. 1148 00:49:54,640 --> 00:49:56,140 Així que això és una cosa en què pensar. 1149 00:49:56,140 --> 00:50:00,160 Quan vostè està llegint DynamoDB, i està configurant la seva capacitat de lectura 1150 00:50:00,160 --> 00:50:04,430 unitats, si es trien amb el temps lectures consistents, és molt més barat, 1151 00:50:04,430 --> 00:50:06,010 que és aproximadament la meitat del cost. 1152 00:50:06,010 --> 00:50:09,342 >> I pel que li estalvia diners. 1153 00:50:09,342 --> 00:50:10,300 Però aquesta és la seva elecció. 1154 00:50:10,300 --> 00:50:12,925 Si vols una lectura consistent o una lectura finalment coherent. 1155 00:50:12,925 --> 00:50:15,720 Això és una cosa que es pot triar. 1156 00:50:15,720 --> 00:50:17,659 >> Anem a parlar dels índexs. 1157 00:50:17,659 --> 00:50:19,450 Així esmentem que agregació de nivell superior. 1158 00:50:19,450 --> 00:50:23,720 Tenim claus hash, i tenim claus abast. 1159 00:50:23,720 --> 00:50:24,320 Això està bé. 1160 00:50:24,320 --> 00:50:26,950 I això és a la taula principal, I ens van donar una clau hash, tinc una clau gamma. 1161 00:50:26,950 --> 00:50:27,783 >> Què vol dir això? 1162 00:50:27,783 --> 00:50:30,410 Tinc un atribut que pot executar consultes rics contra. 1163 00:50:30,410 --> 00:50:31,800 És la clau gamma. 1164 00:50:31,800 --> 00:50:35,530 Els altres atributs en què item-- Puc filtrar aquests atributs. 1165 00:50:35,530 --> 00:50:40,050 Però jo no puc fer coses similars, comença amb, o és més gran que. 1166 00:50:40,050 --> 00:50:40,820 >> Com puc fer això? 1167 00:50:40,820 --> 00:50:42,860 Puc crear un índex. 1168 00:50:42,860 --> 00:50:45,340 Hi ha dos tipus de índexs en DynamoDB. 1169 00:50:45,340 --> 00:50:49,002 Un índex és realment una altra vista de la taula. 1170 00:50:49,002 --> 00:50:50,490 I l'índex secundari local. 1171 00:50:50,490 --> 00:50:51,781 >> La primera d'elles parlarem. 1172 00:50:51,781 --> 00:50:57,740 Així que secundàries locals es van coexistir en la mateixa partició que les dades. 1173 00:50:57,740 --> 00:51:00,240 I com a tals, són en el mateix node físic. 1174 00:51:00,240 --> 00:51:01,780 Són el que anomenem consistent. 1175 00:51:01,780 --> 00:51:04,599 Significat, van a reconèixer l'escriptura juntament amb la taula. 1176 00:51:04,599 --> 00:51:06,890 Quan l'escriptura ve, anem a escriure a través de l'índex. 1177 00:51:06,890 --> 00:51:09,306 Anem a escriure fins a la taula, i després anem a reconèixer. 1178 00:51:09,306 --> 00:51:10,490 Així que això és consistent. 1179 00:51:10,490 --> 00:51:13,174 Una vegada que l'escriptura ha estat reconegut de la taula, 1180 00:51:13,174 --> 00:51:15,090 està garantit que la índex secundari locals 1181 00:51:15,090 --> 00:51:18,380 tindrà la mateixa visió de les dades. 1182 00:51:18,380 --> 00:51:22,390 Però el que permeten que fas és definir tecles de rang alterns. 1183 00:51:22,390 --> 00:51:25,260 >> Ha de fer servir el mateix hash tecla que la taula principal, 1184 00:51:25,260 --> 00:51:29,050 perquè ells són co-ubicat a la mateixa partició, i són consistents. 1185 00:51:29,050 --> 00:51:33,110 Però puc crear un índex amb diferents claus abast. 1186 00:51:33,110 --> 00:51:41,590 Així, per exemple, si jo tingués un fabricant que tenia una taula de peces en brut que entra. 1187 00:51:41,590 --> 00:51:44,590 I parts primes vénen en i que estan agregats pel muntatge. 1188 00:51:44,590 --> 00:51:46,840 I potser hi ha un recés. 1189 00:51:46,840 --> 00:51:50,240 >> Qualsevol part que va ser fet per aquest fabricant després d'aquesta data, 1190 00:51:50,240 --> 00:51:52,840 He de tirar de la meva línia. 1191 00:51:52,840 --> 00:51:55,950 Puc girar un índex que estaria buscant, 1192 00:51:55,950 --> 00:52:00,760 afegint a la data de fabricació d'aquesta part en particular. 1193 00:52:00,760 --> 00:52:03,930 Així que si la meva taula d'alt nivell va ser ja hash pel fabricant, 1194 00:52:03,930 --> 00:52:07,655 potser es va organitzar en part ID, I pot crear un índex d'aquesta taula 1195 00:52:07,655 --> 00:52:11,140 com hash segons el fabricant i oscil·lat en la data de fabricació. 1196 00:52:11,140 --> 00:52:14,490 I d'aquesta manera jo podria dir, tot el que va ser fabricat entre aquestes dates, 1197 00:52:14,490 --> 00:52:16,804 He de tirar de la línia. 1198 00:52:16,804 --> 00:52:18,220 Així que això és un índex secundari local. 1199 00:52:18,220 --> 00:52:22,280 >> Aquests tenen l'efecte de limitant el seu espai clau hash. 1200 00:52:22,280 --> 00:52:24,360 A causa que co-existit en el mateix node d'emmagatzematge, 1201 00:52:24,360 --> 00:52:26,860 limiten la tecla coixinet espai per a 10 gigabytes. 1202 00:52:26,860 --> 00:52:28,950 DynamoDB, sota la taules, es particions 1203 00:52:28,950 --> 00:52:31,380 seva taula cada 10 gigabytes. 1204 00:52:31,380 --> 00:52:34,760 Quan vostè posa 10 gigues de dades, ens anar [PHH], i afegim un altre node. 1205 00:52:34,760 --> 00:52:38,120 1206 00:52:38,120 --> 00:52:42,070 >> No anem a dividir l'LSI en diverses particions. 1207 00:52:42,070 --> 00:52:43,200 Anem a dividir la taula. 1208 00:52:43,200 --> 00:52:44,679 Però no anem a dividir el LSI. 1209 00:52:44,679 --> 00:52:46,470 Així que això és una cosa important entendre 1210 00:52:46,470 --> 00:52:50,070 és si ho estàs fent molt, molt, molt grans agregacions, 1211 00:52:50,070 --> 00:52:53,860 llavors vostè va a estar limitada 10 gigabytes en el seu LSI. 1212 00:52:53,860 --> 00:52:56,640 >> Si aquest és el cas, podem utilitzar secundaris globals. 1213 00:52:56,640 --> 00:52:58,630 Secundàries globals són realment una altra taula. 1214 00:52:58,630 --> 00:53:01,720 Hi completament fora de el costat de la taula principal. 1215 00:53:01,720 --> 00:53:04,680 I ells em permeten trobar una completament diferent estructura. 1216 00:53:04,680 --> 00:53:08,010 Així que pensar-hi com s'està inserint dades en dues taules diferents, estructurats 1217 00:53:08,010 --> 00:53:09,220 de dues maneres diferents. 1218 00:53:09,220 --> 00:53:11,360 >> Puc definir una totalment diferent clau hash. 1219 00:53:11,360 --> 00:53:13,490 Puc definir una totalment clau diferent rang. 1220 00:53:13,490 --> 00:53:15,941 I puc executar aquest de forma totalment independent. 1221 00:53:15,941 --> 00:53:18,190 Com a qüestió de fet, tinc aprovisionat la meva capacitat de lectura 1222 00:53:18,190 --> 00:53:21,090 i escriure capacitat per a mi índexs secundaris globals 1223 00:53:21,090 --> 00:53:24,240 de forma totalment independent de la meva taula principal. 1224 00:53:24,240 --> 00:53:26,640 Si defineixo aquest índex, li dic que la quantitat de lectura i escriptura 1225 00:53:26,640 --> 00:53:28,610 la capacitat que utilitzarà. 1226 00:53:28,610 --> 00:53:31,490 >> I això és separada des del meu taula principal. 1227 00:53:31,490 --> 00:53:35,240 Ara, tant dels índexs ens permeten no només definir claus de hash i d'abast, 1228 00:53:35,240 --> 00:53:38,610 però ens permeten projectar valors addicionals. 1229 00:53:38,610 --> 00:53:44,950 Així que si vull llegir l'índex, i vull aconseguir algun conjunt de dades, 1230 00:53:44,950 --> 00:53:48,327 No necessito tornar a la principal taula per obtenir els atributs addicionals. 1231 00:53:48,327 --> 00:53:50,660 Puc projectar aquells addicional atributs en la taula 1232 00:53:50,660 --> 00:53:53,440 per donar suport al patró d'accés. 1233 00:53:53,440 --> 00:53:57,700 Sé que probablement estem arribant a algun Realment, realmente-- entrar a la mala herba 1234 00:53:57,700 --> 00:53:58,910 aquí a algunes d'aquestes coses. 1235 00:53:58,910 --> 00:54:02,725 Ara tinc a la deriva fora d'això. 1236 00:54:02,725 --> 00:54:07,320 >> AUDIÈNCIA: [inaudible] clau --table volia dir era un hash? 1237 00:54:07,320 --> 00:54:08,840 El hash original? 1238 00:54:08,840 --> 00:54:09,340 Multi-lames? 1239 00:54:09,340 --> 00:54:10,200 >> RICK Houlihan: Sí. 1240 00:54:10,200 --> 00:54:11,070 Sí. 1241 00:54:11,070 --> 00:54:15,260 La clau de la taula, bàsicament, apunta de nou al tema. 1242 00:54:15,260 --> 00:54:19,280 Així que un índex és un punter de nou a els elements originals en la taula. 1243 00:54:19,280 --> 00:54:22,910 Ara vostè pot triar per construir un índex que només té la clau de la taula, 1244 00:54:22,910 --> 00:54:24,840 i no hi ha altres propietats. 1245 00:54:24,840 --> 00:54:26,570 ¿I per què podria jo fer això? 1246 00:54:26,570 --> 00:54:28,570 Bé, potser tinc articles molt grans. 1247 00:54:28,570 --> 00:54:31,660 >> En realitat només necessito saber which-- el meu patró d'accés podria dir: 1248 00:54:31,660 --> 00:54:33,760 els elements que contenen aquesta propietat? 1249 00:54:33,760 --> 00:54:35,780 No cal retornar l'article. 1250 00:54:35,780 --> 00:54:37,800 Només necessito saber els elements que contenen. 1251 00:54:37,800 --> 00:54:40,700 Així que vostè pot construir índexs que només tenen la clau de la taula. 1252 00:54:40,700 --> 00:54:43,360 >> Però això és principalment el que un índex a la base de dades és per. 1253 00:54:43,360 --> 00:54:46,280 És per poder ràpidament identificar que registra, 1254 00:54:46,280 --> 00:54:49,470 què files, les quals els elements de la taula tenen 1255 00:54:49,470 --> 00:54:51,080 les propietats que estic buscant. 1256 00:54:51,080 --> 00:54:53,610 1257 00:54:53,610 --> 00:54:54,860 >> GSI, així que com funcionen? 1258 00:54:54,860 --> 00:54:58,340 GSI bàsicament són asíncrones. 1259 00:54:58,340 --> 00:55:02,570 L'actualització entra a la taula, A continuació, s'actualitza la taula de forma asíncrona 1260 00:55:02,570 --> 00:55:03,720 tota la seva GSI. 1261 00:55:03,720 --> 00:55:06,680 Aquesta és la raó per GSI són finalment consistent. 1262 00:55:06,680 --> 00:55:09,440 >> És important assenyalar que quan vostè està construint GSI, 1263 00:55:09,440 --> 00:55:13,110 i entén que està creant una altra dimensió de aggregation-- 1264 00:55:13,110 --> 00:55:16,594 Ara diguem que un bon exemple aquí és un fabricant. 1265 00:55:16,594 --> 00:55:19,260 Crec que podria haver parlat un fabricant de dispositius mèdics. 1266 00:55:19,260 --> 00:55:23,870 Fabricants de dispositius mèdics moltes vegades tenen parts serialitzats. 1267 00:55:23,870 --> 00:55:28,070 Les parts que intervenen en la un reemplaçament de maluc tot 1268 00:55:28,070 --> 00:55:30,200 tenir un petit nombre de sèrie en ells. 1269 00:55:30,200 --> 00:55:33,584 I podrien tenir milions i milions i milers de milions de peces 1270 00:55:33,584 --> 00:55:35,000 en tots els dispositius que envien. 1271 00:55:35,000 --> 00:55:37,440 Bé, han de agregar sota diferents dimensions, totes les peces 1272 00:55:37,440 --> 00:55:39,520 en una assemblea, tota la parts que es van fer 1273 00:55:39,520 --> 00:55:41,670 en una determinada línia, tot les parts que vénen 1274 00:55:41,670 --> 00:55:44,620 des d'un cert fabricant en una data determinada. 1275 00:55:44,620 --> 00:55:47,940 I aquestes agregacions de vegades aixecar-se als milers de milions. 1276 00:55:47,940 --> 00:55:50,550 >> Així que jo treball amb alguns aquests nois que estan patint 1277 00:55:50,550 --> 00:55:53,156 perquè estan creant aquestes agregacions ginormous 1278 00:55:53,156 --> 00:55:54,280 en els seus índexs secundaris. 1279 00:55:54,280 --> 00:55:57,070 Pot ser que tinguin unes parts primes taula que ve ja que només hash. 1280 00:55:57,070 --> 00:55:59,090 Cada part té un número de sèrie únic. 1281 00:55:59,090 --> 00:56:00,975 Jo ús el número de sèrie que el hash. 1282 00:56:00,975 --> 00:56:01,600 És bonic. 1283 00:56:01,600 --> 00:56:04,160 El meu taula de dades en brut es propaga tot l'espai de claus. 1284 00:56:04,160 --> 00:56:05,930 La meva [? escriure?] [? la ingestió?] és impressionant. 1285 00:56:05,930 --> 00:56:07,876 Tinc una gran quantitat de dades. 1286 00:56:07,876 --> 00:56:09,500 Llavors el que fan és que creen un GSI. 1287 00:56:09,500 --> 00:56:12,666 I dic jo, saps què, he de veure totes les parts d'aquest fabricant. 1288 00:56:12,666 --> 00:56:15,060 Bé, de sobte estic tenint un bilió de files, 1289 00:56:15,060 --> 00:56:17,550 i ficar-los en un node, perquè quan 1290 00:56:17,550 --> 00:56:21,170 Jo agregada com el ID del fabricant com el haixix, 1291 00:56:21,170 --> 00:56:25,410 i el nombre de peça com el rang, llavors de cop i volta estic 1292 00:56:25,410 --> 00:56:30,530 posar mil milions d'parts en el que aquest fabricant m'ha lliurat. 1293 00:56:30,530 --> 00:56:34,447 >> Això pot causar una gran quantitat de pressió sobre el GSI, 1294 00:56:34,447 --> 00:56:36,030 de nou, perquè estic martellejant un node. 1295 00:56:36,030 --> 00:56:38,350 Estic posant tot això s'insereix en un node. 1296 00:56:38,350 --> 00:56:40,940 I això és un cas real ús problemàtic. 1297 00:56:40,940 --> 00:56:43,479 Ara, tinc un bon disseny patró de com evitar això. 1298 00:56:43,479 --> 00:56:45,770 I aquest és un dels problemes que jo sempre treball amb. 1299 00:56:45,770 --> 00:56:49,590 Però el que passa, és el GSI podria no tenen suficient capacitat d'escriptura 1300 00:56:49,590 --> 00:56:52,330 per ser capaç d'empènyer tots aquells files en un sol node. 1301 00:56:52,330 --> 00:56:55,390 I el que passa a continuació és la primària, la taula de clients, 1302 00:56:55,390 --> 00:57:00,180 la taula principal serà estrangulat pel fet que el GSI no pot seguir el ritme. 1303 00:57:00,180 --> 00:57:02,980 Així que la meva taxa d'inserció serà caure en la taula principal 1304 00:57:02,980 --> 00:57:06,230 com el meu GSI tracta de mantenir el ritme. 1305 00:57:06,230 --> 00:57:08,850 >> Molt bé, així GSI de, LSI de, quina hauria d'utilitzar? 1306 00:57:08,850 --> 00:57:12,290 LSI de són consistents. 1307 00:57:12,290 --> 00:57:13,750 GSI de són finalment consistent. 1308 00:57:13,750 --> 00:57:17,490 Si això està bé, recomano l'ús d'un GSI, són molt més flexibles. 1309 00:57:17,490 --> 00:57:20,270 LSI de es pot modelar com un GSI. 1310 00:57:20,270 --> 00:57:27,040 I si la mida de les dades per claus hash en la seva col·lecció supera els 10 gigabytes, 1311 00:57:27,040 --> 00:57:31,050 llavors vostè va a voler usar aquest GSI perquè és només un límit dur. 1312 00:57:31,050 --> 00:57:32,035 >> Molt bé, pel que l'escala. 1313 00:57:32,035 --> 00:57:35,210 1314 00:57:35,210 --> 00:57:37,460 El rendiment en el Dynamo DB, prestació llauna [inaudible] 1315 00:57:37,460 --> 00:57:38,680 rendiment per a una taula. 1316 00:57:38,680 --> 00:57:42,740 Tenim clients que tenen aprovisionat 60 billion-- 1317 00:57:42,740 --> 00:57:45,970 estan fent 60 mil milions de sol·licituds, amb regularitat funcionant a més d'un milió sol·licituds 1318 00:57:45,970 --> 00:57:47,790 per segon a les nostres taules. 1319 00:57:47,790 --> 00:57:50,360 En realitat no hi ha límit teòric a la quantitat de 1320 00:57:50,360 --> 00:57:53,730 i la rapidesa amb la taula es pot executar en Dynamo DB. 1321 00:57:53,730 --> 00:57:55,920 Hi ha alguns suau límits en el seu compte 1322 00:57:55,920 --> 00:57:58,170 que posem allà, així que no tornar-se boig. 1323 00:57:58,170 --> 00:58:00,070 Si voleu més que, no és un problema. 1324 00:58:00,070 --> 00:58:00,820 Vens dir-nos. 1325 00:58:00,820 --> 00:58:02,810 Anem a pujar el dial. 1326 00:58:02,810 --> 00:58:08,210 >> Cada compte està limitada a un cert nivell en cada servei, just al costat del pal 1327 00:58:08,210 --> 00:58:11,920 de manera que les persones no es tornen bojos es fiquen en problemes. 1328 00:58:11,920 --> 00:58:12,840 No hi ha límit de mida. 1329 00:58:12,840 --> 00:58:14,940 Vostè pot posar qualsevol nombre d'elements en una taula. 1330 00:58:14,940 --> 00:58:17,620 La mida d'un element és limitat a 400 kilobytes cadascun, 1331 00:58:17,620 --> 00:58:20,050 això seria no tema els atributs. 1332 00:58:20,050 --> 00:58:24,200 Així que la suma de tots els atributs està limitat a 400 kilobytes. 1333 00:58:24,200 --> 00:58:27,300 I, de nou, tenim aquest petit problema de LSI 1334 00:58:27,300 --> 00:58:30,405 amb el límit de 10 gigabytes per hash. 1335 00:58:30,405 --> 00:58:33,280 AUDIÈNCIA: Petit nombre, estic desapareguts el que m'estàs dient, que és-- 1336 00:58:33,280 --> 00:58:36,830 AUDIÈNCIA: Oh, 400 kilobytes és la mida màxima per article. 1337 00:58:36,830 --> 00:58:39,570 Així que un element té tots els atributs. 1338 00:58:39,570 --> 00:58:43,950 Així que 400 k és la mida total d'aquest article, 400 kilobytes. 1339 00:58:43,950 --> 00:58:46,170 Així que de tots els atributs combinats, totes les dades 1340 00:58:46,170 --> 00:58:49,140 això és en tots aquests atributs, enrotllat en una mida total, 1341 00:58:49,140 --> 00:58:51,140 Actualment l'actualitat el límit d'elements és de 400 k. 1342 00:58:51,140 --> 00:58:54,390 1343 00:58:54,390 --> 00:58:57,046 Així escalat de nou, aconseguit a través de la partició. 1344 00:58:57,046 --> 00:58:58,920 El rendiment s'aprovisiona a nivell de taula. 1345 00:58:58,920 --> 00:59:00,160 I no hi ha realment dos perillós. 1346 00:59:00,160 --> 00:59:02,400 Hem llegit la capacitat i escriure capacitat. 1347 00:59:02,400 --> 00:59:05,530 >> Així que aquests s'ajusten independentment un de l'altre. 1348 00:59:05,530 --> 00:59:08,640 Mesura de RCU estrictament llegeix consistent. 1349 00:59:08,640 --> 00:59:13,005 OK, així que si vostè està dient que vull 1000 UCR d'aquests són estrictament coherent, 1350 00:59:13,005 --> 00:59:14,130 aquests són lectures consistents. 1351 00:59:14,130 --> 00:59:17,130 Si dius que vull eventual coherent llegeix, 1352 00:59:17,130 --> 00:59:19,402 vostè pot aprovisionar 1000 UCR de, vas 1353 00:59:19,402 --> 00:59:21,840 per arribar finalment 2000 llegeix consistent. 1354 00:59:21,840 --> 00:59:25,940 I la meitat del preu dels finalment consistir en llegeix. 1355 00:59:25,940 --> 00:59:28,520 >> Un cop més, ajustat independentment un de l'altre. 1356 00:59:28,520 --> 00:59:32,900 I tenen la throughput-- Si vostè consumeix 100% del seu comandament a distància, 1357 00:59:32,900 --> 00:59:35,960 vostè no va a afectar el disponibilitat dels seus drets. 1358 00:59:35,960 --> 00:59:40,161 Pel que són completament independents entre si. 1359 00:59:40,161 --> 00:59:43,160 Molt bé, així que una de les coses que Vaig esmentar breument estava estrangulant. 1360 00:59:43,160 --> 00:59:44,320 Throttling és dolent. 1361 00:59:44,320 --> 00:59:47,311 Throttling indica malament sense SQL. 1362 00:59:47,311 --> 00:59:50,310 Hi ha coses que podem fer per ajudar a alleujar l'estrangulació que 1363 00:59:50,310 --> 00:59:51,040 estan experimentant. 1364 00:59:51,040 --> 00:59:53,240 Però la millor solució a això és que tirem 1365 00:59:53,240 --> 00:59:58,000 Una mirada al que està fent, perquè hi ha un anti-patró en joc aquí. 1366 00:59:58,000 --> 01:00:02,140 >> Aquestes coses, coses com no uniforme les càrregues de treball, tecles d'accés ràpid, particions calents. 1367 01:00:02,140 --> 01:00:06,210 Estic colpejant un espai clau particular molt dur per alguna raó en particular. 1368 01:00:06,210 --> 01:00:07,080 Per què estic fent això? 1369 01:00:07,080 --> 01:00:08,710 Anem a donar-se compte d'això. 1370 01:00:08,710 --> 01:00:10,427 Estic barrejant les meves dades calents amb les dades fredes. 1371 01:00:10,427 --> 01:00:12,510 Jo vaig a deixar els meus quadres aconsegueixen enorme, però no hi ha realment 1372 01:00:12,510 --> 01:00:15,970 només alguns subconjunt de les dades això és molt interessant per a mi. 1373 01:00:15,970 --> 01:00:20,290 Així que per a les dades de registre, per exemple, una gran quantitat de clients, que reben dades de registre cada dia. 1374 01:00:20,290 --> 01:00:22,490 Tenen una enorme quantitat de dades de registre. 1375 01:00:22,490 --> 01:00:25,940 >> Si acaba d'abocament tot aquest registre dades en una gran taula, amb el temps 1376 01:00:25,940 --> 01:00:28,070 aquesta taula es posarà massiva. 1377 01:00:28,070 --> 01:00:30,950 Però estic realment només interessat en últimes 24 hores, els últims set dies, 1378 01:00:30,950 --> 01:00:31,659 els últims 30 dies. 1379 01:00:31,659 --> 01:00:34,074 Qualsevol que sigui la finestra de temps que estic interessat en mirar 1380 01:00:34,074 --> 01:00:37,010 per al cas que em molesta, o el cas que és interessant per a mi, 1381 01:00:37,010 --> 01:00:39,540 aquesta és l'única ocasió en la finestra que necessito. 1382 01:00:39,540 --> 01:00:42,470 Així que per què estic posant 10 anys el valor de les dades de registre a la taula? 1383 01:00:42,470 --> 01:00:45,030 El que fa és la taula del fragment. 1384 01:00:45,030 --> 01:00:45,880 >> Es posa enorme. 1385 01:00:45,880 --> 01:00:48,340 Comença estesa a través de milers de nodes. 1386 01:00:48,340 --> 01:00:51,380 I ja que la seva capacitat és tan baixa, que està 1387 01:00:51,380 --> 01:00:54,090 en realitat la limitació de velocitat a cada un d'aquests nodes individuals. 1388 01:00:54,090 --> 01:00:57,120 Així que anem a començar a mirar com fem vam rodar aquesta taula. 1389 01:00:57,120 --> 01:01:01,502 Com gestionem les dades una mica millor evitar-los. 1390 01:01:01,502 --> 01:01:02,710 I ¿què s'assemblen? 1391 01:01:02,710 --> 01:01:04,370 Això és el que sembla. 1392 01:01:04,370 --> 01:01:06,790 Això és el dolent NoSQL es sembla. 1393 01:01:06,790 --> 01:01:07,830 >> Vaig rebre una tecla d'accés ràpid aquí. 1394 01:01:07,830 --> 01:01:10,246 Si ens fixem en el costat aquí, aquests són tots els meus particions. 1395 01:01:10,246 --> 01:01:12,630 Tinc 16 particions aquí en aquesta base de dades particular. 1396 01:01:12,630 --> 01:01:13,630 Ho fem tot el temps. 1397 01:01:13,630 --> 01:01:15,046 Corro això per als clients de tots els temps. 1398 01:01:15,046 --> 01:01:16,550 Es diu el mapa de calor. 1399 01:01:16,550 --> 01:01:20,590 Mapa de calor em diu el que ets l'accés al seu espai de claus. 1400 01:01:20,590 --> 01:01:23,700 I el que això m'està dient és que hi ha un coixinet especial 1401 01:01:23,700 --> 01:01:26,330 que aquest noi li agrada 1 moltíssim, perquè és 1402 01:01:26,330 --> 01:01:28,250 copejant molt, molt difícil. 1403 01:01:28,250 --> 01:01:29,260 >> Així que el blau és agradable. 1404 01:01:29,260 --> 01:01:29,900 Ens agrada blau. 1405 01:01:29,900 --> 01:01:30,720 No ens agrada el vermell. 1406 01:01:30,720 --> 01:01:33,120 Xarxa on la pressió s'incorpora al 100%. 1407 01:01:33,120 --> 01:01:35,560 100%, ara seràs estrangulat. 1408 01:01:35,560 --> 01:01:39,030 Així que cada vegada que hi ha línies vermelles com esto-- i no es tracta només Dynamo DB-- 1409 01:01:39,030 --> 01:01:41,630 cada base de dades NoSQL té aquest problema. 1410 01:01:41,630 --> 01:01:44,640 No són anti-patrons que poden conduir aquest tipus de condicions. 1411 01:01:44,640 --> 01:01:49,070 El que faig és que treball amb els clients per alleujar aquestes condicions. 1412 01:01:49,070 --> 01:01:51,840 >> I ¿què s'assemblen? 1413 01:01:51,840 --> 01:01:54,260 I això és cada vegada més fora del Dynamo DB rendiment, 1414 01:01:54,260 --> 01:01:56,176 però és realment arribar el màxim profit de NoSQL. 1415 01:01:56,176 --> 01:01:58,740 Això no es limita a Dynamo. 1416 01:01:58,740 --> 01:02:02,050 Això és el definitely-- solia treballar en Mongo. 1417 01:02:02,050 --> 01:02:04,090 Estic familiaritzat amb moltes plataformes NoSQL. 1418 01:02:04,090 --> 01:02:06,830 Cada un té aquest tipus dels problemes claus calents. 1419 01:02:06,830 --> 01:02:10,320 Per treure el màxim partit de qualsevol NoSQL base de dades, específicament Dynamo DB, 1420 01:02:10,320 --> 01:02:13,320 Per crear les taules on l'element clau hash té 1421 01:02:13,320 --> 01:02:18,590 un gran nombre de valors diferents, un alt grau de cardinalitat. 1422 01:02:18,590 --> 01:02:22,530 Perquè això vol dir que estic escrivint a un munt de diferents cubs. 1423 01:02:22,530 --> 01:02:24,870 >> Els més cubs estic escrit a, més probable 1424 01:02:24,870 --> 01:02:29,100 Estic a difondre que la càrrega d'escriptura o llegir carregar a terme a través de múltiples nodes, 1425 01:02:29,100 --> 01:02:33,560 és més probable que sóc i tenir una d'alt rendiment a la taula. 1426 01:02:33,560 --> 01:02:37,440 I després vull que els valors siguin sol·licitat de manera bastant uniforme en el temps 1427 01:02:37,440 --> 01:02:39,430 i uniformement com a l'atzar com sigui possible. 1428 01:02:39,430 --> 01:02:42,410 Bé, això és força interessant, perquè no puc realment 1429 01:02:42,410 --> 01:02:43,960 control quan els usuaris entren. 1430 01:02:43,960 --> 01:02:47,645 Així que n'hi ha prou amb dir, si vam difondre coses fora de tot l'espai de claus, 1431 01:02:47,645 --> 01:02:49,270 probablement estarem en millor forma. 1432 01:02:49,270 --> 01:02:51,522 >> Hi ha una certa quantitat de temps de lliurament 1433 01:02:51,522 --> 01:02:53,230 que no vas ser capaços de control. 1434 01:02:53,230 --> 01:02:55,438 Però aquests són en realitat el dues dimensions que tenim, 1435 01:02:55,438 --> 01:02:58,800 espai, l'accés de manera uniforme propagació, el temps, les sol·licituds 1436 01:02:58,800 --> 01:03:01,040 arribin uniformement espaiades en el temps. 1437 01:03:01,040 --> 01:03:03,110 I si aquests dos s'estan complint les condicions, 1438 01:03:03,110 --> 01:03:05,610 llavors això és el que és va a semblar. 1439 01:03:05,610 --> 01:03:07,890 Això és molt més bonic. 1440 01:03:07,890 --> 01:03:08,890 Estem molt feliços aquí. 1441 01:03:08,890 --> 01:03:10,432 Tenim un esquema d'accés molt parell. 1442 01:03:10,432 --> 01:03:13,098 Sí, potser vostè està rebent un poca pressió de tant en tant, 1443 01:03:13,098 --> 01:03:14,830 però res realment massa extensa. 1444 01:03:14,830 --> 01:03:17,660 Així que és increïble la quantitat de vegades, quan treballo amb els clients, 1445 01:03:17,660 --> 01:03:20,670 aquesta primera gràfica la gran vermella bar i tot el lleig de color groc que és 1446 01:03:20,670 --> 01:03:23,147 per tot el lloc, ens aconseguir fet amb l'exercici 1447 01:03:23,147 --> 01:03:24,980 després d'un parell de mesos de la re-arquitectura, 1448 01:03:24,980 --> 01:03:28,050 estan corrent la mateixa exacta càrrega de treball en la mateixa càrrega exacta. 1449 01:03:28,050 --> 01:03:30,140 I això és el que està buscant com ara. 1450 01:03:30,140 --> 01:03:36,600 Així que el que obtens amb NoSQL és un esquema de dades que és absolutament 1451 01:03:36,600 --> 01:03:38,510 lligat al patró d'accés. 1452 01:03:38,510 --> 01:03:42,170 >> I vostè pot optimitzar aquest esquema de dades per donar suport aquest patró d'accés. 1453 01:03:42,170 --> 01:03:45,490 Si no ho fa, llavors vostè va veure aquests tipus de problemes 1454 01:03:45,490 --> 01:03:46,710 amb aquestes tecles d'accés ràpid. 1455 01:03:46,710 --> 01:03:50,518 >> AUDIÈNCIA: Bé, inevitablement, alguns llocs seran més calent que altres. 1456 01:03:50,518 --> 01:03:51,450 >> RICK Houlihan: Sempre. 1457 01:03:51,450 --> 01:03:51,960 Sempre. 1458 01:03:51,960 --> 01:03:54,620 Sí, vull dir que sempre hi ha A-- i una altra, no hi ha 1459 01:03:54,620 --> 01:03:56,980 alguns patrons de disseny que van a obtenir a través d' que va a parlar sobre com tractar 1460 01:03:56,980 --> 01:03:58,480 amb aquestes súper grans agregacions. 1461 01:03:58,480 --> 01:04:01,260 Vull dir, he de tenir-les, Com ens ocupem d'ells? 1462 01:04:01,260 --> 01:04:03,760 Tinc un molt bon cas d'ús que anem a parlar d'això. 1463 01:04:03,760 --> 01:04:05,940 >> Molt bé, així que anem a parlar sobre alguns clients ara. 1464 01:04:05,940 --> 01:04:06,950 Aquests nois són Adroll. 1465 01:04:06,950 --> 01:04:08,990 No sé si estàs familiaritzats amb Adroll. 1466 01:04:08,990 --> 01:04:10,781 És probable que els vegi molt en el navegador. 1467 01:04:10,781 --> 01:04:14,230 Són ad re-focalització, són el negoci més gran ad re-focalització 1468 01:04:14,230 --> 01:04:14,940 per allà. 1469 01:04:14,940 --> 01:04:17,792 Normalment surten regularment sobre 60 mil milions de transaccions per dia. 1470 01:04:17,792 --> 01:04:20,000 Estan fent més d'un milió transaccions per segon. 1471 01:04:20,000 --> 01:04:22,660 Tenen una taula bastant simple estructura, la taula més concorreguda. 1472 01:04:22,660 --> 01:04:26,450 És bàsicament un clau hash és la galeta, 1473 01:04:26,450 --> 01:04:29,010 la gamma és el demogràfic categoria, i després 1474 01:04:29,010 --> 01:04:31,220 el tercer atribut és la puntuació. 1475 01:04:31,220 --> 01:04:33,720 >> Així que tots tenim galetes nostre navegador d'aquests nois. 1476 01:04:33,720 --> 01:04:35,900 I quan vas a un comerç participant, 1477 01:04:35,900 --> 01:04:39,390 que bàsicament s'anoten en tot diverses categories demogràfiques. 1478 01:04:39,390 --> 01:04:42,070 Quan vas a un lloc web i vostè diu que vull veure aquesta ad-- 1479 01:04:42,070 --> 01:04:44,920 o bàsicament no dius que-- però quan vas a la pàgina web 1480 01:04:44,920 --> 01:04:47,550 ells diuen que vostè desitja veure aquest anunci. 1481 01:04:47,550 --> 01:04:49,370 I van aconseguir aquest anunci de Adroll. 1482 01:04:49,370 --> 01:04:51,130 Adroll que mira cap amunt a la seva taula. 1483 01:04:51,130 --> 01:04:52,115 Ells troben que el seu galeta. 1484 01:04:52,115 --> 01:04:53,990 Els anunciants diuen ells, em volen a algú 1485 01:04:53,990 --> 01:04:58,632 que és de mitjana edat, Home de 40 anys d'edat, en els esports. 1486 01:04:58,632 --> 01:05:01,590 I et anoten en aquestes dades demogràfiques i decideixen si és o no 1487 01:05:01,590 --> 01:05:02,740 això és un bon anunci per a tu. 1488 01:05:02,740 --> 01:05:10,330 >> Ara tenen un SLA amb seus proveïdors de publicitat 1489 01:05:10,330 --> 01:05:14,510 per proporcionar sub-10 milisegons resposta a cada petició individual. 1490 01:05:14,510 --> 01:05:16,090 Així que estan usant Dynamo DB per això. 1491 01:05:16,090 --> 01:05:18,131 Ells ens estan colpejant un milió de sol·licituds per segon. 1492 01:05:18,131 --> 01:05:21,120 Són capaços de fer tot el seu recerques, triatge totes aquestes dades, 1493 01:05:21,120 --> 01:05:26,130 i aconseguir que l'enllaç afegir de nou a aquest anunciant en menys de 10 milisegons. 1494 01:05:26,130 --> 01:05:29,800 És realment bastant fenomenal aplicació que tenen. 1495 01:05:29,800 --> 01:05:36,210 >> Aquests nois actually-- són aquests els nois. 1496 01:05:36,210 --> 01:05:38,010 No estic segur de si es tracta d'aquests nois. 1497 01:05:38,010 --> 01:05:40,127 Podria ser que aquests nois. 1498 01:05:40,127 --> 01:05:42,210 Bàsicament nosaltres-- vaig dir que no, em no crec que eren ells. 1499 01:05:42,210 --> 01:05:43,000 Crec que va ser una altra persona. 1500 01:05:43,000 --> 01:05:44,750 Jo estava treballant amb un al client que em va dir 1501 01:05:44,750 --> 01:05:47,040 que ara que han anat a Dynamo DB, són 1502 01:05:47,040 --> 01:05:50,330 gastar més diners en entrepans per el seu equip de desenvolupament de cada mes 1503 01:05:50,330 --> 01:05:52,886 el que gasten a la base de dades. 1504 01:05:52,886 --> 01:05:54,760 Així que ell es pot donar una idea dels estalvis de costos 1505 01:05:54,760 --> 01:05:57,889 que es pot obtenir en el Dynamo DB és enorme. 1506 01:05:57,889 --> 01:05:59,430 Molt bé, Dropcam és una altra companyia. 1507 01:05:59,430 --> 01:06:02,138 Aquests tipus és tipus de-- si vostè pensa d'Internet de les coses, Dropcam 1508 01:06:02,138 --> 01:06:05,150 és bàsicament el vídeo de seguretat d'Internet. 1509 01:06:05,150 --> 01:06:06,660 Vostè posa el seu càmera per aquí. 1510 01:06:06,660 --> 01:06:08,180 La càmera té un detector de moviment. 1511 01:06:08,180 --> 01:06:10,290 Algú ve, desencadena un punt de referència. 1512 01:06:10,290 --> 01:06:13,540 Cambra comença a gravar durant un temps fins no detecta cap moviment més. 1513 01:06:13,540 --> 01:06:15,310 Posa aquest vídeo en l'internet. 1514 01:06:15,310 --> 01:06:19,800 >> Dropcam era una empresa que és bàsicament canviat a Dynamo DB 1515 01:06:19,800 --> 01:06:22,200 perquè estaven experimentant enormes dolors de creixement. 1516 01:06:22,200 --> 01:06:25,820 I el que ens van dir, sobtadament petabytes de dades. 1517 01:06:25,820 --> 01:06:28,070 No tenien idea del seu servei seria tan reeixit. 1518 01:06:28,070 --> 01:06:32,310 Més de vídeo d'entrada de YouTube és el que aquests nois estan rebent. 1519 01:06:32,310 --> 01:06:36,780 Utilitzen DynamoDB seguir fins al metadades en tots els seus punts clau de vídeo. 1520 01:06:36,780 --> 01:06:40,282 >> Així que tenen cubs S3 que empenyen tots els artefactes binaris en. 1521 01:06:40,282 --> 01:06:41,990 I després tenen Registres Dynamo DB que 1522 01:06:41,990 --> 01:06:44,070 assenyalar a la gent als tres objectes S3. 1523 01:06:44,070 --> 01:06:47,070 Quan necessiten per mirar un vídeo, es veuen fins al registre a Dynamo DB. 1524 01:06:47,070 --> 01:06:47,903 Fer clic a l'enllaç. 1525 01:06:47,903 --> 01:06:49,770 Que tiri cap avall el vídeo de S3. 1526 01:06:49,770 --> 01:06:51,590 Així que això és una cosa del que això es sembla. 1527 01:06:51,590 --> 01:06:53,580 I això és directament del seu equip. 1528 01:06:53,580 --> 01:06:56,010 >> Dynamo DB redueix la seva temps de lliurament d'esdeveniments de vídeo 1529 01:06:56,010 --> 01:06:57,590 de cinc a 10 segons. 1530 01:06:57,590 --> 01:07:00,470 A la seva botiga relacional d'edat, solien haver d'anar i executar 1531 01:07:00,470 --> 01:07:03,780 múltiples consultes complexes a la figura quins vídeos per tirar avall, 1532 01:07:03,780 --> 01:07:06,690 a menys de 50 milisegons. 1533 01:07:06,690 --> 01:07:08,990 Així que és increïble, increïble quant rendiment 1534 01:07:08,990 --> 01:07:12,990 vostè pot aconseguir quan optimitzar i sintonitza la base de dades subjacent 1535 01:07:12,990 --> 01:07:15,110 per donar suport al patró d'accés. 1536 01:07:15,110 --> 01:07:20,500 Halfbrick, aquests nois, ¿què és, Fruit Ninja Suposo que és el seu. 1537 01:07:20,500 --> 01:07:22,590 Que totes les carreres i Dynamo DB. 1538 01:07:22,590 --> 01:07:26,810 I aquests nois, que són una gran equip de desenvolupament, gran desenvolupament 1539 01:07:26,810 --> 01:07:27,670 botiga. 1540 01:07:27,670 --> 01:07:29,364 >> No és un bon equip d'operacions. 1541 01:07:29,364 --> 01:07:31,280 Ells no tenen molt dels recursos d'operació. 1542 01:07:31,280 --> 01:07:33,940 Ells estaven lluitant tractant de mantenir la seva infraestructura d'aplicacions fins 1543 01:07:33,940 --> 01:07:34,290 i en execució. 1544 01:07:34,290 --> 01:07:35,000 Ells van venir a nosaltres. 1545 01:07:35,000 --> 01:07:36,251 Es veien en aquest Dynamo DB. 1546 01:07:36,251 --> 01:07:37,291 Ells van dir, això és per a nosaltres. 1547 01:07:37,291 --> 01:07:39,470 Van construir la seva totalitat marc d'aplicació de la mateixa. 1548 01:07:39,470 --> 01:07:43,640 Alguns comentaris molt bonics aquí De l'equip de la seva capacitat 1549 01:07:43,640 --> 01:07:46,800 ara a centrar-se en la creació el joc i no 1550 01:07:46,800 --> 01:07:49,010 haver de mantenir la infraestructura, que 1551 01:07:49,010 --> 01:07:51,910 s'estava convertint en una quantitat enorme de les despeses generals per al seu equip. 1552 01:07:51,910 --> 01:07:56,170 Així que això és una cosa que-- el benefici que s'obté de Dynamo DB. 1553 01:07:56,170 --> 01:08:00,930 >> Molt bé, entrar en modelatge de dades aquí. 1554 01:08:00,930 --> 01:08:03,440 I parlem una mica sobre aquest un a un, un a molts, 1555 01:08:03,440 --> 01:08:05,060 i molts de moltes relacions de tipus. 1556 01:08:05,060 --> 01:08:07,630 I ¿com mantenir els de Dynamo. 1557 01:08:07,630 --> 01:08:10,500 En Dynamo DB fem servir índexs, parlant en general, 1558 01:08:10,500 --> 01:08:12,910 per girar les dades de un sabor a l'altra. 1559 01:08:12,910 --> 01:08:15,210 Claus hash, claus abast, i els índexs. 1560 01:08:15,210 --> 01:08:18,540 >> En aquest particular, exemple, com la majoria dels estats 1561 01:08:18,540 --> 01:08:23,802 tenir un requisit de llicència que Només una llicència d'un conductor per persona. 1562 01:08:23,802 --> 01:08:26,510 Vostè no pot anar a aconseguir dos controlador de llicències en l'estat de Boston. 1563 01:08:26,510 --> 01:08:27,500 Jo no puc fer-ho a Texas. 1564 01:08:27,500 --> 01:08:28,708 Això és una cosa de la manera que és. 1565 01:08:28,708 --> 01:08:32,779 I així en el DMV, tenim les recerques, que vulgueu cercar la llicència de conduir 1566 01:08:32,779 --> 01:08:35,180 pel nombre d'assegurança social. 1567 01:08:35,180 --> 01:08:39,990 Vull veure els detalls d'usuari per nombre de llicència de conduir. 1568 01:08:39,990 --> 01:08:43,620 >> Així que pot ser que tinguem la taula d'un usuari que té una clau hash en el nombre de sèrie, 1569 01:08:43,620 --> 01:08:47,830 o el nombre d'assegurança social, i diversos atributs definits en l'article. 1570 01:08:47,830 --> 01:08:49,859 Ara en aquesta taula I podria definir un GSI que 1571 01:08:49,859 --> 01:08:53,370 mou d'una tirada que al voltant del qual diu que vull Un resum en la llicència i després 1572 01:08:53,370 --> 01:08:54,252 tots els altres articles. 1573 01:08:54,252 --> 01:08:57,210 Ara si vull consultar i trobar la número de llicència per a qualsevol Social donada 1574 01:08:57,210 --> 01:08:59,609 Nombre d'assegurança, puc consultar la taula principal. 1575 01:08:59,609 --> 01:09:02,130 >> Si vull consultar i vull per aconseguir la seguretat social 1576 01:09:02,130 --> 01:09:05,735 nombre o altres atributs per una número de llicència, puc consultar el GSI. 1577 01:09:05,735 --> 01:09:08,689 Aquest model és que un una relació. 1578 01:09:08,689 --> 01:09:12,460 Només un molt simple GSI, voltejar aquestes coses. 1579 01:09:12,460 --> 01:09:13,979 Ara, parlar d'un a molts. 1580 01:09:13,979 --> 01:09:16,450 Un de molts és, bàsicament, seva clau gamma hash. 1581 01:09:16,450 --> 01:09:20,510 D'on traiem molt amb aquest de casos d'ús és dades del monitor. 1582 01:09:20,510 --> 01:09:23,880 Les dades del monitor ve en regulars interval, com Internet de les coses. 1583 01:09:23,880 --> 01:09:26,890 Sempre ens donen tots aquests registres venint en tot el temps. 1584 01:09:26,890 --> 01:09:31,420 >> I vull trobar totes les lectures entre un període de temps determinat. 1585 01:09:31,420 --> 01:09:34,220 És una consulta molt comú en infraestructura de monitorització. 1586 01:09:34,220 --> 01:09:38,430 La manera d'anar sobre que és trobar un senzilla estructura de la taula, una taula. 1587 01:09:38,430 --> 01:09:42,250 Tinc una taula de mesuraments del dispositiu amb una clau hash en l'identificador de dispositiu. 1588 01:09:42,250 --> 01:09:47,340 I tinc una clau de rang en la marca de temps, o en aquest cas, l'èpica. 1589 01:09:47,340 --> 01:09:50,350 I això em permet executar complexes consultes en aquesta clau gamma 1590 01:09:50,350 --> 01:09:54,950 i tornar els registres que són en relació amb el resultat 1591 01:09:54,950 --> 01:09:56,310 vaig proposar que jo estic buscant. 1592 01:09:56,310 --> 01:09:58,360 I és que un construeix a molts relació 1593 01:09:58,360 --> 01:10:02,340 a la taula principal utilitzant la clau hash, estructura clau gamma. 1594 01:10:02,340 --> 01:10:04,600 >> Així que això és quelcom construït en la taula de Dynamo DB. 1595 01:10:04,600 --> 01:10:07,290 Quan defineixo un hash i la gamma t taula, estic 1596 01:10:07,290 --> 01:10:09,240 la definició d'una relació d'un a molts. 1597 01:10:09,240 --> 01:10:12,770 És una relació pare-fill. 1598 01:10:12,770 --> 01:10:14,620 >> Anem a parlar de molts a moltes relacions. 1599 01:10:14,620 --> 01:10:19,170 I per aquest exemple en particular, de nou, utilitzarem GSI de. 1600 01:10:19,170 --> 01:10:23,500 I anem a parlar dels jocs escenari en el qual tinc un usuari determinat. 1601 01:10:23,500 --> 01:10:26,500 Vull saber tots els jocs que que ha registrat a favor o jugant a. 1602 01:10:26,500 --> 01:10:29,600 I per a un determinat joc, em que vulgueu trobar tots els usuaris. 1603 01:10:29,600 --> 01:10:31,010 Llavors, com ho faig? 1604 01:10:31,010 --> 01:10:34,330 La meva taula jocs d'usuari, vaig tenir una clau hash del ID d'usuari 1605 01:10:34,330 --> 01:10:35,810 i una clau gamma del joc. 1606 01:10:35,810 --> 01:10:37,810 >> Així, un usuari pot tenir diversos jocs. 1607 01:10:37,810 --> 01:10:41,380 És un un a molts relació entre l'usuari i els partits en què juga. 1608 01:10:41,380 --> 01:10:43,410 I després en el GSI, Vaig a la FLIP que al voltant. 1609 01:10:43,410 --> 01:10:46,679 Vaig hash en el joc i Vaig a oscil·lar en l'usuari. 1610 01:10:46,679 --> 01:10:48,970 Així que si vull obtenir tota la joc l'usuari de jugar a, 1611 01:10:48,970 --> 01:10:49,950 Vaig a consultar la taula principal. 1612 01:10:49,950 --> 01:10:52,699 Si vull aconseguir tots els usuaris que estan jugant un joc en particular, 1613 01:10:52,699 --> 01:10:53,887 Jo consultar el GSI. 1614 01:10:53,887 --> 01:10:54,970 Així que ja veus com fem això? 1615 01:10:54,970 --> 01:10:58,369 Vostè construeix d'aquests GSI per donar suport a la de cas d'ús, l'aplicació, l'accés 1616 01:10:58,369 --> 01:10:59,410 patró, l'aplicació. 1617 01:10:59,410 --> 01:11:01,440 >> Si he de consultar a aquesta dimensió, anem 1618 01:11:01,440 --> 01:11:03,500 em crea un índex en aquesta dimensió. 1619 01:11:03,500 --> 01:11:05,850 Si no ho faig, no m'importa. 1620 01:11:05,850 --> 01:11:09,060 I depenent del cas d'ús, I pot necessitar l'índex o jo no podria. 1621 01:11:09,060 --> 01:11:12,390 Si és una simple un a molts, la taula principal està molt bé. 1622 01:11:12,390 --> 01:11:15,860 Si he de fer això a molts a molts, o que han de fer una per a uns, 1623 01:11:15,860 --> 01:11:18,390 llavors potser ho necessito al segon índex. 1624 01:11:18,390 --> 01:11:20,840 Així que tot depèn de el que estic tractant de fer 1625 01:11:20,840 --> 01:11:24,550 i el que jo estic tractant d'aconseguir consumat. 1626 01:11:24,550 --> 01:11:28,000 >> Probablement no vaig a gastar massa molt de temps parlant de documents. 1627 01:11:28,000 --> 01:11:31,460 Això posa una mica, probablement, més profund que hem d'entrar. 1628 01:11:31,460 --> 01:11:33,710 Anem a parlar una mica sobre la rica expressió de consulta. 1629 01:11:33,710 --> 01:11:37,831 Així que en Dynamo DB tenim la capacitat de crear 1630 01:11:37,831 --> 01:11:39,330 el que anomenem expressions de projecció. 1631 01:11:39,330 --> 01:11:42,660 Expressions de projecció són simplement recollint els camps o els valors 1632 01:11:42,660 --> 01:11:44,290 que vol mostrar. 1633 01:11:44,290 --> 01:11:46,000 OK, així que faig una selecció. 1634 01:11:46,000 --> 01:11:48,010 Faig una consulta contra Dynamo DB. 1635 01:11:48,010 --> 01:11:51,730 I dic jo, saps què, espectacle em només les cinc estrelles comentaris 1636 01:11:51,730 --> 01:11:54,544 per a aquest producte en particular. 1637 01:11:54,544 --> 01:11:55,710 Així que això és tot el que vull veure. 1638 01:11:55,710 --> 01:11:57,320 No vull veure a tota la altres atributs de la fila, 1639 01:11:57,320 --> 01:11:58,319 Només vull veure això. 1640 01:11:58,319 --> 01:12:01,209 És com en SQL quan dir selecte estrella o de la taula, 1641 01:12:01,209 --> 01:12:02,000 vostè aconsegueix tot. 1642 01:12:02,000 --> 01:12:05,450 Quan dic seleccioneu el nom de taula, només tinc un atribut. 1643 01:12:05,450 --> 01:12:09,070 És el mateix tipus de cosa en Dynamo DB o altres bases de dades NoSQL. 1644 01:12:09,070 --> 01:12:14,510 Expressions Filtrar em permeten bàsicament tallar el resultat establert. 1645 01:12:14,510 --> 01:12:15,540 Així que faig una consulta. 1646 01:12:15,540 --> 01:12:17,260 Consulta pot tornar amb 500 articles. 1647 01:12:17,260 --> 01:12:20,255 Però jo només vull que els elements que tenen un atribut que diu això. 1648 01:12:20,255 --> 01:12:23,380 OK, així que anem a filtrar cap a fora els articles que no concorden amb aquesta consulta particular. 1649 01:12:23,380 --> 01:12:25,540 Així que tenim expressions de filtre. 1650 01:12:25,540 --> 01:12:28,310 >> Expressions filtre pot ser executat en qualsevol atribut. 1651 01:12:28,310 --> 01:12:30,260 No són com consultes de rang. 1652 01:12:30,260 --> 01:12:32,690 Raise consultes són més selectius. 1653 01:12:32,690 --> 01:12:36,470 Consultes Filtrar em requereixen per anar obtenir tot el conjunt de resultats i després 1654 01:12:36,470 --> 01:12:39,170 tallar les dades que jo no vull. 1655 01:12:39,170 --> 01:12:40,660 Per què és important? 1656 01:12:40,660 --> 01:12:42,770 Perquè he llegit tot. 1657 01:12:42,770 --> 01:12:46,597 En una consulta, vaig a llegir i que serà un gegant sobre les dades. 1658 01:12:46,597 --> 01:12:48,430 I després vaig a tallar el que necessito. 1659 01:12:48,430 --> 01:12:52,080 I si només estic tallant un parell de files, llavors això està bé. 1660 01:12:52,080 --> 01:12:53,620 No és tan ineficient. 1661 01:12:53,620 --> 01:12:57,800 >> Però si estic llegint tota una pila de dades, només per llaurar-se un article, 1662 01:12:57,800 --> 01:13:01,490 llavors jo seré millor fora mitjançant una consulta gamma, 1663 01:13:01,490 --> 01:13:03,030 perquè és molt més selectiu. 1664 01:13:03,030 --> 01:13:06,330 Es em va a estalviar un munt de diners, perquè he de pagar per aquesta lectura. 1665 01:13:06,330 --> 01:13:10,430 Quan els resultats que ve de tornada creuar aquest filferro podria ser més petit, 1666 01:13:10,430 --> 01:13:11,890 però jo estic pagant per la lectura. 1667 01:13:11,890 --> 01:13:14,340 Així entendre com que està rebent les dades. 1668 01:13:14,340 --> 01:13:16,420 Això és molt important en Dynamo DB. 1669 01:13:16,420 --> 01:13:19,710 >> Les expressions condicionals, això és el que que es podria anomenar el bloqueig optimista. 1670 01:13:19,710 --> 01:13:28,470 Actualització SI EXISTEIX, o si aquest valor és equivalent al que específic. 1671 01:13:28,470 --> 01:13:31,494 I si tinc una marca de temps en un registre, podria llegir les dades. 1672 01:13:31,494 --> 01:13:32,535 Jo podria canviar aquestes dades. 1673 01:13:32,535 --> 01:13:35,030 Jo podria anar d'escriptura que tornar a la base de dades. 1674 01:13:35,030 --> 01:13:38,100 Si algú ha canviat el registre, la marca de temps podria haver canviat. 1675 01:13:38,100 --> 01:13:40,370 I d'aquesta manera la meva condicional actualització podria dir d'actualització 1676 01:13:40,370 --> 01:13:42,340 Si la marca de temps és igual a aquest. 1677 01:13:42,340 --> 01:13:46,290 O l'actualització fallarà perquè algú actualitzat el registre en el interí. 1678 01:13:46,290 --> 01:13:48,290 >> Això és el que anomenem el bloqueig optimista. 1679 01:13:48,290 --> 01:13:50,670 Això vol dir que algú pot entrar i canviar-la, 1680 01:13:50,670 --> 01:13:53,100 i jo vaig a detectar- quan torni a escriure. 1681 01:13:53,100 --> 01:13:56,106 I llavors puc realment llegit que dades i dir, oh, va canviar això. 1682 01:13:56,106 --> 01:13:57,230 He de donar compte d'això. 1683 01:13:57,230 --> 01:14:00,490 I puc canviar les dades de la meva gravar i aplicar una altra actualització. 1684 01:14:00,490 --> 01:14:04,330 Així que vostè pot agafar els incrementals canvis que es produeixen entre el moment 1685 01:14:04,330 --> 01:14:08,740 que llegeixi les dades i la el temps és possible escriure les dades. 1686 01:14:08,740 --> 01:14:11,520 >> AUDIÈNCIA: I el filtre expressió en realitat no vol dir 1687 01:14:11,520 --> 01:14:13,020 en el nombre o no-- 1688 01:14:13,020 --> 01:14:14,316 >> [Interposant VEUS] 1689 01:14:14,316 --> 01:14:16,232 RICK Houlihan: No ho faré tenir massa en això. 1690 01:14:16,232 --> 01:14:17,700 Aquesta és una paraula clau reservada. 1691 01:14:17,700 --> 01:14:20,130 La vista lliures és una reserva paraula clau en Dynamo DB. 1692 01:14:20,130 --> 01:14:24,500 Cada base de dades té el seu propi reservats noms per a col·leccions que no es pot utilitzar. 1693 01:14:24,500 --> 01:14:27,240 Dynamo DB, si especifica una lliura enfront d'això, 1694 01:14:27,240 --> 01:14:29,310 pot definir els noms amunt. 1695 01:14:29,310 --> 01:14:31,840 Aquest és un valor de referència. 1696 01:14:31,840 --> 01:14:34,880 Probablement no sigui la millor sintaxi per tenir-hi per aquesta discussió, 1697 01:14:34,880 --> 01:14:38,090 perquè es fica en alguns real-- Jo he estat parlant més 1698 01:14:38,090 --> 01:14:41,360 sobre això en un nivell més profund. 1699 01:14:41,360 --> 01:14:46,130 >> Però n'hi ha prou amb dir, això podria siguin consulta escanejar on views-- 1700 01:14:46,130 --> 01:14:50,190 ni vistes lliures és més gran que 10. 1701 01:14:50,190 --> 01:14:54,660 És un valor numèric, si. 1702 01:14:54,660 --> 01:14:57,322 Si vols, podem parlar de que després de la discussió. 1703 01:14:57,322 --> 01:15:00,030 Molt bé, així que estem ficant alguns escenaris en les millors pràctiques 1704 01:15:00,030 --> 01:15:02,000 on parlarem sobre algunes aplicacions aquí. 1705 01:15:02,000 --> 01:15:03,810 Quins són els casos d'ús per Dynamo DB. 1706 01:15:03,810 --> 01:15:06,120 Quins són el disseny patrons en Dynamo DB. 1707 01:15:06,120 --> 01:15:09,110 >> I el primer que anem a parlar és l'Internet de les coses. 1708 01:15:09,110 --> 01:15:15,010 Així que tenim una gran quantitat de-- suposo, el que és it-- més del 50% 1709 01:15:15,010 --> 01:15:19,370 del trànsit a Internet en aquests dies en realitat és generat per les màquines, 1710 01:15:19,370 --> 01:15:21,930 processos automatitzats i no per éssers humans. 1711 01:15:21,930 --> 01:15:25,140 Vull dir aquesta cosa aquesta cosa que que portes a la butxaca, 1712 01:15:25,140 --> 01:15:28,840 la quantitat de dades que aquesta cosa és enviar realment tot sense tu 1713 01:15:28,840 --> 01:15:30,550 sabent que és absolutament increïble. 1714 01:15:30,550 --> 01:15:34,970 La seva ubicació, la informació sobre què tan ràpid se'n va. 1715 01:15:34,970 --> 01:15:38,400 Com creus que Google Maps obres quan et diuen el que el trànsit és. 1716 01:15:38,400 --> 01:15:41,275 És perquè hi ha milions i milions de persones que condueixen al voltant 1717 01:15:41,275 --> 01:15:44,667 amb els telèfons que estan enviant dades en tot lloc tot el temps. 1718 01:15:44,667 --> 01:15:46,500 Així que una de les coses sobre aquest tipus de dades 1719 01:15:46,500 --> 01:15:50,980 que ve en, dades de monitorització, registre les dades, les dades de sèries de temps, és que és 1720 01:15:50,980 --> 01:15:53,540 en general només és interessant per una mica de temps. 1721 01:15:53,540 --> 01:15:55,580 Després d'aquest temps, és no tan interessant. 1722 01:15:55,580 --> 01:15:58,390 Així que parlem, no deixis aquestes taules créixer sense límits. 1723 01:15:58,390 --> 01:16:03,410 La idea és que potser tinc 24 hores de valor dels esdeveniments a la meva taula calent. 1724 01:16:03,410 --> 01:16:06,160 I aquesta taula calenta serà aprovisionat a un ritme molt alt, 1725 01:16:06,160 --> 01:16:07,950 perquè està tenint una gran quantitat de dades. 1726 01:16:07,950 --> 01:16:10,920 Es tracta de prendre una gran quantitat de dades i estic llegint molt. 1727 01:16:10,920 --> 01:16:14,560 Tinc un munt de funcionament consultes que s'executen en contra que les dades. 1728 01:16:14,560 --> 01:16:18,120 >> Després de 24 hores, bé, sé què, no m'importa. 1729 01:16:18,120 --> 01:16:21,150 Així que potser cada rotlle mitjanit la meva taula a una nova taula 1730 01:16:21,150 --> 01:16:22,430 i jo desproveir aquesta taula. 1731 01:16:22,430 --> 01:16:26,440 I vaig a prendre de la UCR i A baix de WCU perquè 24 hores després 1732 01:16:26,440 --> 01:16:28,630 No estic corrent fins consultes en aquestes dades. 1733 01:16:28,630 --> 01:16:30,200 Així que em vaig a estalviar diners. 1734 01:16:30,200 --> 01:16:32,940 I potser 30 dies després no ho faig fins i tot necessitat de preocupar-se per tot. 1735 01:16:32,940 --> 01:16:35,020 Jo podria prendre la UMM de tot el camí a un, 1736 01:16:35,020 --> 01:16:36,990 perquè saps què, és mai va a quedar per escrit a. 1737 01:16:36,990 --> 01:16:38,300 Les dades són de 30 dies d'edat. 1738 01:16:38,300 --> 01:16:40,000 Mai canvia. 1739 01:16:40,000 --> 01:16:44,200 >> I gairebé mai aconseguirà llegir, així que anem a prendre aquest UCR fins a 10. 1740 01:16:44,200 --> 01:16:49,372 I jo estic estalviant un munt de diners en aquest de dades, i només per pagar les meves dades calents. 1741 01:16:49,372 --> 01:16:52,330 Així que això és el més important per buscar en tant ens fixem en una sèrie temporal 1742 01:16:52,330 --> 01:16:54,716 dades que entren en el volum. 1743 01:16:54,716 --> 01:16:55,590 Aquestes són estratègies. 1744 01:16:55,590 --> 01:16:58,010 Ara, jo podria deixar-ho tots van a la mateixa taula 1745 01:16:58,010 --> 01:16:59,461 i deixar que la taula creixi. 1746 01:16:59,461 --> 01:17:01,460 Amb el temps, vaig a veure els problemes de rendiment. 1747 01:17:01,460 --> 01:17:04,060 Vaig a haver de començar a arxivar alguns que les dades de la taula, 1748 01:17:04,060 --> 01:17:04,720 el que no. 1749 01:17:04,720 --> 01:17:07,010 >> Anem molt millor dissenyar l'aplicació 1750 01:17:07,010 --> 01:17:08,900 perquè pugui operar d'aquesta manera dreta. 1751 01:17:08,900 --> 01:17:11,460 Així que és només automàtic en el codi d'aplicació. 1752 01:17:11,460 --> 01:17:13,580 A la mitjanit cada nit roda de la taula. 1753 01:17:13,580 --> 01:17:17,170 Potser el que necessito és una esllavissada finestra de 24 hores de dades. 1754 01:17:17,170 --> 01:17:20,277 A continuació, de forma regular estic trucant a les dades de la taula. 1755 01:17:20,277 --> 01:17:22,360 Estic retallada amb un Cron treball i m'estic posant 1756 01:17:22,360 --> 01:17:24,160 en aquestes altres taules, tot el que necessitis. 1757 01:17:24,160 --> 01:17:25,940 Així que si un tomb funciona, això és genial. 1758 01:17:25,940 --> 01:17:27,080 Si no, retallar-lo. 1759 01:17:27,080 --> 01:17:29,640 Però anem a mantenir aquestes dades en calent lluny de les seves dades fredes. 1760 01:17:29,640 --> 01:17:32,535 Li estalviarà molts diners i fer els seus quadres més rendiment. 1761 01:17:32,535 --> 01:17:35,960 1762 01:17:35,960 --> 01:17:38,210 Així que el següent que anem a parlar aproximadament és el catàleg de productes. 1763 01:17:38,210 --> 01:17:42,000 Catàleg de productes és cas d'ús molt comú. 1764 01:17:42,000 --> 01:17:46,600 Això és en realitat un patró molt comú que veurem en una varietat de coses. 1765 01:17:46,600 --> 01:17:48,870 Ja saps, per Twitter exemple, un tweet calent. 1766 01:17:48,870 --> 01:17:51,280 Tothom ve i agafant aquest tweet. 1767 01:17:51,280 --> 01:17:52,680 Catàleg de productes, tinc una venda. 1768 01:17:52,680 --> 01:17:54,120 Tinc una venda calenta. 1769 01:17:54,120 --> 01:17:57,277 Tinc 70.000 sol·licituds per la segona vinguda d'un producte 1770 01:17:57,277 --> 01:17:58,860 Descripció del meu catàleg de productes. 1771 01:17:58,860 --> 01:18:02,384 Veiem això en la venda al detall operació bastant. 1772 01:18:02,384 --> 01:18:03,550 Llavors, com podem fer davant d'això? 1773 01:18:03,550 --> 01:18:04,924 No hi ha manera de tractar amb això. 1774 01:18:04,924 --> 01:18:07,110 Tots els meus usuaris volen veure la mateixa peça de dades. 1775 01:18:07,110 --> 01:18:09,410 Estan estan arribant, al mateix temps. 1776 01:18:09,410 --> 01:18:11,920 I tots estan fent peticions per a la mateixa peça de dades. 1777 01:18:11,920 --> 01:18:16,240 Això em dóna aquesta tecla d'accés ràpid, que vermell gran ratlla en la meva carta que no ens agrada. 1778 01:18:16,240 --> 01:18:17,720 I això és el que sembla. 1779 01:18:17,720 --> 01:18:22,290 Així que a través del meu espai de claus que estic rebent martillado en els articles de la venda. 1780 01:18:22,290 --> 01:18:24,070 M'estic posant res en cap altre lloc. 1781 01:18:24,070 --> 01:18:26,050 >> Com puc solucionar aquest problema? 1782 01:18:26,050 --> 01:18:28,410 Bé, ens alleugem això amb memòria cau. 1783 01:18:28,410 --> 01:18:33,630 Cache, que va posar bàsicament un in-memory partició al davant de la base de dades. 1784 01:18:33,630 --> 01:18:37,260 Hem aconseguit [Inaudible] memòria cau, com 1785 01:18:37,260 --> 01:18:40,260 pot configurar la seva pròpia memòria cau, [inaudible] memòria cau [? d ,?] el que vulguis. 1786 01:18:40,260 --> 01:18:42,220 Posa això al davant de la base de dades. 1787 01:18:42,220 --> 01:18:47,250 I d'aquesta manera vostè pot emmagatzemar les dades d'aquestes tecles d'accés ràpid en aquest cau 1788 01:18:47,250 --> 01:18:49,390 espai i llegir a través de la memòria cau. 1789 01:18:49,390 --> 01:18:51,962 >> I llavors la majoria de les teves lectures començar a buscar d'aquesta manera. 1790 01:18:51,962 --> 01:18:54,920 Vaig aconseguir tots aquests encerts de memòria cau aquí i jo no tinc res passa aquí baix 1791 01:18:54,920 --> 01:18:59,330 perquè la base de dades està assegut darrere de la memòria cau i mai llegeix vénen a través. 1792 01:18:59,330 --> 01:19:02,520 Si canvi de les dades de la base de dades, he de actualitzar la memòria cau. 1793 01:19:02,520 --> 01:19:04,360 Podem usar alguna cosa com vapors de fer això. 1794 01:19:04,360 --> 01:19:07,360 I vaig a explicar com funciona. 1795 01:19:07,360 --> 01:19:09,060 Molt bé, la missatgeria. 1796 01:19:09,060 --> 01:19:11,180 Correu electrònic, tots fem servir correu electrònic. 1797 01:19:11,180 --> 01:19:12,540 >> Aquest és un molt bon exemple. 1798 01:19:12,540 --> 01:19:14,950 Tenim una espècie de taula de missatges. 1799 01:19:14,950 --> 01:19:17,040 I arribem safata d'entrada i safata de sortida. 1800 01:19:17,040 --> 01:19:19,760 Això és el que l'SQL faria semblar-se a construir aquesta safata d'entrada. 1801 01:19:19,760 --> 01:19:23,350 És com que fem servir el mateix tipus de l'estratègia d'utilitzar GSI de, GSI de 1802 01:19:23,350 --> 01:19:25,320 per la meva safata d'entrada i la meva safata de sortida. 1803 01:19:25,320 --> 01:19:27,600 Així que em van donar missatges primeres procedents en el meu taula de missatges. 1804 01:19:27,600 --> 01:19:30,194 I la primera aproximació a aquest podria ser, per exemple, està bé, cap problema. 1805 01:19:30,194 --> 01:19:31,110 Tinc missatges primeres. 1806 01:19:31,110 --> 01:19:33,710 Missatges propers [inaudible], ID de missatge, que és gran. 1807 01:19:33,710 --> 01:19:35,070 Aquesta és la meva hash únic. 1808 01:19:35,070 --> 01:19:38,280 Vaig a crear de dues GSI d'un per la meva safata d'entrada, un per la meva bústia de sortida. 1809 01:19:38,280 --> 01:19:40,530 I el primer que faré és que em vaig a dir la meva clau hash és 1810 01:19:40,530 --> 01:19:43,310 serà el receptor i Vaig a organitzar en la data. 1811 01:19:43,310 --> 01:19:44,220 Això és fantàstic. 1812 01:19:44,220 --> 01:19:45,890 Tinc la meva bonica vista aquí. 1813 01:19:45,890 --> 01:19:47,780 Però hi ha un petit problema aquí. 1814 01:19:47,780 --> 01:19:50,891 I arribes a tenir això en bases de dades relacionals, així. 1815 01:19:50,891 --> 01:19:52,390 Van cridar a la partició vertical. 1816 01:19:52,390 --> 01:19:55,840 Vostè vol mantenir les seves dades gran lluny de les seves poques dades. 1817 01:19:55,840 --> 01:20:00,470 >> I la raó és perquè he de veu a llegir els articles per obtenir els atributs. 1818 01:20:00,470 --> 01:20:05,570 I si els meus òrgans són tots aquí, després de llegir uns pocs articles 1819 01:20:05,570 --> 01:20:08,560 si el meu longitud del cos és una mitjana de 256 kilobytes cadascun, 1820 01:20:08,560 --> 01:20:10,991 les matemàtiques es posa molt lletja. 1821 01:20:10,991 --> 01:20:12,490 Així que dic vull llegir la safata d'entrada de David. 1822 01:20:12,490 --> 01:20:14,520 Safata d'entrada de David té 50 articles. 1823 01:20:14,520 --> 01:20:17,880 La mitjana i la mida és de 256 kilobytes. 1824 01:20:17,880 --> 01:20:21,730 Aquí està la meva relació de conversió per a la UCR de és quatre kilobytes. 1825 01:20:21,730 --> 01:20:24,450 >> OK, anirem amb llegeix finalment consistent. 1826 01:20:24,450 --> 01:20:28,640 Encara estic menjant 1600 RCU de només per llegir la safata d'entrada de David. 1827 01:20:28,640 --> 01:20:29,950 Ouch. 1828 01:20:29,950 --> 01:20:31,980 Bé, ara anem a pensar sobre com funciona l'aplicació. 1829 01:20:31,980 --> 01:20:35,340 Si estic en una aplicació de correu electrònic i Estic buscant a la meva safata d'entrada, 1830 01:20:35,340 --> 01:20:39,680 i miro el cos de cada missatge, no, jo estic mirant als resums. 1831 01:20:39,680 --> 01:20:41,850 Estic mirant només les capçaleres. 1832 01:20:41,850 --> 01:20:46,310 Així que anem a construir una estructura de taula que s'assembla més a això. 1833 01:20:46,310 --> 01:20:49,470 >> Així que aquí està la informació que el meu flux de treball necessita. 1834 01:20:49,470 --> 01:20:50,890 Està en la meva safata d'entrada de GSI. 1835 01:20:50,890 --> 01:20:53,800 És la data, el remitent, el tema, i després 1836 01:20:53,800 --> 01:20:56,790 l'ID de missatge, que apunta tornar a la taula de missatges 1837 01:20:56,790 --> 01:20:57,850 on puc aconseguir el cos. 1838 01:20:57,850 --> 01:21:01,260 1839 01:21:01,260 --> 01:21:04,420 Bé, aquests serien els ID de registre. 1840 01:21:04,420 --> 01:21:09,850 Ells assenyalar de nou a la ID d'elements sobre la taula Dynamo DB. 1841 01:21:09,850 --> 01:21:12,220 Cada índex sempre creates-- sempre té l'element 1842 01:21:12,220 --> 01:21:15,750 ID com a part de-- que ve amb l'índex. 1843 01:21:15,750 --> 01:21:17,414 >> Tot bé. 1844 01:21:17,414 --> 01:21:19,080 AUDIÈNCIA: Es diu que on s'emmagatzema? 1845 01:21:19,080 --> 01:21:21,420 RICK Houlihan: Sí, diu exactly-- això és exactament el que fa. 1846 01:21:21,420 --> 01:21:22,644 Es diu que aquí està el meu disc re. 1847 01:21:22,644 --> 01:21:24,310 I que va assenyalar de nou al meu disc re. 1848 01:21:24,310 --> 01:21:26,460 Exactament. 1849 01:21:26,460 --> 01:21:29,490 OK, així que ara la meva safata d'entrada és en realitat molt més petit. 1850 01:21:29,490 --> 01:21:32,210 I això dóna suport realitat el flux de treball d'una aplicació de correu electrònic. 1851 01:21:32,210 --> 01:21:34,230 Així que la meva safata d'entrada, faig clic. 1852 01:21:34,230 --> 01:21:38,160 Que avanço i faig clic al missatge, això és quan he d'anar a buscar el cos, 1853 01:21:38,160 --> 01:21:40,180 perquè jo vaig a anar a un punt de vista diferent. 1854 01:21:40,180 --> 01:21:43,870 Així que si vostè pensa sobre el tipus de MVC marc, model vista controlador. 1855 01:21:43,870 --> 01:21:46,120 >> El model conté la dades que les necessitats vista 1856 01:21:46,120 --> 01:21:48,130 i el controlador interactua amb. 1857 01:21:48,130 --> 01:21:51,670 Quan canvi la trama, al Puc canviar la perspectiva, 1858 01:21:51,670 --> 01:21:55,080 que està bé per tornar a la servidor i repoblar el model, 1859 01:21:55,080 --> 01:21:56,860 perquè això és el que espera l'usuari. 1860 01:21:56,860 --> 01:22:00,530 Quan canvien punts de vista, que és quan podem tornar a la base de dades. 1861 01:22:00,530 --> 01:22:02,480 Així de correu electrònic, feu clic a. 1862 01:22:02,480 --> 01:22:03,710 Estic buscant el cos. 1863 01:22:03,710 --> 01:22:04,330 Viatge d'anada i tornada. 1864 01:22:04,330 --> 01:22:05,680 Aneu a buscar el cos. 1865 01:22:05,680 --> 01:22:06,950 >> Llegeixo molt menys dades. 1866 01:22:06,950 --> 01:22:09,960 Jo només estic llegint els cossos que David necessita quan les necessita. 1867 01:22:09,960 --> 01:22:14,230 I no em cremo en 1600 UCR de simplement per mostrar la safata d'entrada. 1868 01:22:14,230 --> 01:22:17,670 Així que ara que-- aquest és el camí que LSI o GSI-- ho sento, 1869 01:22:17,670 --> 01:22:19,900 GSI, anava a sortir. 1870 01:22:19,900 --> 01:22:25,450 Tenim la nostra haixix al destinatari. 1871 01:22:25,450 --> 01:22:27,030 Tenim la clau de rang en la data. 1872 01:22:27,030 --> 01:22:31,380 I tenim els atributs projectats que només hem de recolzar a la vista. 1873 01:22:31,380 --> 01:22:34,300 >> Girem per que a la bústia de sortida. 1874 01:22:34,300 --> 01:22:35,770 Hash en el remitent. 1875 01:22:35,770 --> 01:22:39,612 I en essència, tenim la molt agradable, vista neta. 1876 01:22:39,612 --> 01:22:41,570 I és que basically-- tenir aquest agradable missatges 1877 01:22:41,570 --> 01:22:45,870 taula que està sent difós molt bé perquè és només haixix, ID de missatge hash. 1878 01:22:45,870 --> 01:22:51,750 I tenim dos índexs que estan girant fora d'aquest quadre. 1879 01:22:51,750 --> 01:22:57,411 Molt bé, així que la idea aquí no és fer mantenir els grans dades i aquesta petita dades 1880 01:22:57,411 --> 01:22:57,910 junts. 1881 01:22:57,910 --> 01:23:00,700 Partició vertical, particions les taules. 1882 01:23:00,700 --> 01:23:03,150 No llegeixi les dades que vostè no ha de. 1883 01:23:03,150 --> 01:23:04,850 Molt bé, els jocs. 1884 01:23:04,850 --> 01:23:06,990 A tots ens agrada els jocs. 1885 01:23:06,990 --> 01:23:10,902 Almenys m'agraden els jocs llavors. 1886 01:23:10,902 --> 01:23:12,735 Així que algunes de les coses que ens ocupem quan 1887 01:23:12,735 --> 01:23:14,193 estem pensant en el joc, no? 1888 01:23:14,193 --> 01:23:16,999 Gaming aquests dies, especialment mòbil jocs, té a veure amb el pensament. 1889 01:23:16,999 --> 01:23:19,540 I vaig a girar aquí mica lluny de DynamoDB. 1890 01:23:19,540 --> 01:23:21,373 Vaig a portar Part de la discussió 1891 01:23:21,373 --> 01:23:24,240 al voltant d'alguns dels altres tecnologies de AWS. 1892 01:23:24,240 --> 01:23:28,930 >> Però la idea de joc és pensar sobre en termes d'API, API que són, 1893 01:23:28,930 --> 01:23:31,730 en termes generals, HTTP i JSON. 1894 01:23:31,730 --> 01:23:34,550 És la forma de jocs mòbils tipus de interactuar amb els seus extrems posteriors. 1895 01:23:34,550 --> 01:23:35,850 Ho fan JSON publicació. 1896 01:23:35,850 --> 01:23:40,660 S'obtenen les dades, i és tot, en termes generals, en les API JSON agradables. 1897 01:23:40,660 --> 01:23:44,950 >> Coses com aconseguir amics, aconsegueixen les dades de la taula de posicions, de canvi, 1898 01:23:44,950 --> 01:23:47,699 contingut generat per usuaris, fer retrocedir al sistema, 1899 01:23:47,699 --> 01:23:49,740 aquests són els tipus de coses que farem. 1900 01:23:49,740 --> 01:23:52,542 Dades actiu binari, aquestes dades podria no seure a la base de dades. 1901 01:23:52,542 --> 01:23:54,250 Això podria seure en una magatzem d'objectes, oi? 1902 01:23:54,250 --> 01:23:56,541 Però la base de dades es va a acabar dient al sistema, 1903 01:23:56,541 --> 01:23:59,140 dient l'aplicació on anar a buscar-ho. 1904 01:23:59,140 --> 01:24:03,550 I inevitablement, multijugador servidors, infraestructura back-end, 1905 01:24:03,550 --> 01:24:06,180 i dissenyat per a alta disponibilitat i escalabilitat. 1906 01:24:06,180 --> 01:24:09,400 Així que aquestes són les coses que tots volem en la infraestructura de joc avui. 1907 01:24:09,400 --> 01:24:12,160 >> Així que donem una ullada a del que sembla. 1908 01:24:12,160 --> 01:24:16,070 Va aconseguir un extrem posterior del nucli, molt senzill. 1909 01:24:16,070 --> 01:24:19,880 Tenim un sistema d'aquí amb múltiples zones de disponibilitat. 1910 01:24:19,880 --> 01:24:23,780 Parlem de AZS com being-- pensar d'ells com a centres de dades independents. 1911 01:24:23,780 --> 01:24:26,040 Més d'un centre de dades per AZ, però això està bé, 1912 01:24:26,040 --> 01:24:28,831 només pensar en ells com dades independent centres que estan geogràficament 1913 01:24:28,831 --> 01:24:30,090 i es va aïllar decisió. 1914 01:24:30,090 --> 01:24:32,172 >> Tindrem un casos parella EC2. 1915 01:24:32,172 --> 01:24:33,880 Tindrem algun servidor back-end. 1916 01:24:33,880 --> 01:24:35,800 Potser si vostè és un llegat arquitectura, estem 1917 01:24:35,800 --> 01:24:38,920 utilitzant el que anomenem RDS, serveis de bases de dades relacionals. 1918 01:24:38,920 --> 01:24:42,040 Podria ser MSSQL, MySQL, o alguna cosa per l'estil. 1919 01:24:42,040 --> 01:24:47,080 Aquesta és la manera moltes de les aplicacions avui són dissenyats. 1920 01:24:47,080 --> 01:24:49,594 >> Bé podríem desitjar anar amb això és quan escalem a terme. 1921 01:24:49,594 --> 01:24:51,510 Seguirem endavant i posar el cub S3 fins allà. 1922 01:24:51,510 --> 01:24:54,200 I aquest cub S3, en comptes de servir fins als objectes del nostre servers-- 1923 01:24:54,200 --> 01:24:55,220 podríem fer això. 1924 01:24:55,220 --> 01:24:57,210 Poses tota la teva binària objectes en els seus servidors 1925 01:24:57,210 --> 01:24:59,751 i pot utilitzar els servidors casos per servir que les dades dalt. 1926 01:24:59,751 --> 01:25:01,860 Però això és bastant car. 1927 01:25:01,860 --> 01:25:05,107 >> Millor manera de fer-ho és seguir endavant i posar els objectes en una galleda de S3. 1928 01:25:05,107 --> 01:25:06,315 S3 és una repositoris d'objectes. 1929 01:25:06,315 --> 01:25:10,860 Està construït específicament per servint aquest tipus de coses. 1930 01:25:10,860 --> 01:25:13,690 I que sol·liciten els clients directament des d'aquests cubs d'objecte, 1931 01:25:13,690 --> 01:25:15,390 descarregar els servidors. 1932 01:25:15,390 --> 01:25:17,020 Així que estem començant a escalar aquí. 1933 01:25:17,020 --> 01:25:19,140 >> Ara que tenim els usuaris de tot el món. 1934 01:25:19,140 --> 01:25:19,730 Tinc usuaris. 1935 01:25:19,730 --> 01:25:23,380 Necessito tenir contingut localment situat a prop d'aquests usuaris, no? 1936 01:25:23,380 --> 01:25:26,200 He creat una galleda S3 com el meu repositori de codi font. 1937 01:25:26,200 --> 01:25:29,370 I vaig a cara que amb la distribució CloudFront. 1938 01:25:29,370 --> 01:25:31,720 >> CloudFront és un CD i un xarxa de lliurament de contingut. 1939 01:25:31,720 --> 01:25:35,750 Bàsicament es pren les dades que especifiqui i emmagatzema en memòria cau tot a internet 1940 01:25:35,750 --> 01:25:39,230 perquè els usuaris de tot el món poden tenir una resposta molt ràpida quan 1941 01:25:39,230 --> 01:25:40,960 sol·liciten aquests objectes. 1942 01:25:40,960 --> 01:25:41,960 >> Perquè pugui obtenir una idea. 1943 01:25:41,960 --> 01:25:48,230 Estàs tipus d'aprofitament de tot el aspectes de AWS aquí per fer això. 1944 01:25:48,230 --> 01:25:50,790 I finalment, ens tirem en un grup d'escala automàtica. 1945 01:25:50,790 --> 01:25:52,737 Així que els nostres casos AC2 dels nostres servidors de joc, 1946 01:25:52,737 --> 01:25:54,820 quan comencen a aconseguir més concorregut i cada vegada més ocupat, 1947 01:25:54,820 --> 01:25:57,236 ells només fan girar una altra exemple, girar una altra instància, 1948 01:25:57,236 --> 01:25:58,210 girar una altra instància. 1949 01:25:58,210 --> 01:26:02,090 Així que la tecnologia AWS té, és li permet especificar els paràmetres 1950 01:26:02,090 --> 01:26:04,650 al voltant de la qual els servidors creixerà. 1951 01:26:04,650 --> 01:26:08,110 Així que vostè pot tenir un nombre n de servidors per aquí en un moment donat. 1952 01:26:08,110 --> 01:26:11,870 I si la càrrega es va, que va reduir la mida, el nombre es reduirà. 1953 01:26:11,870 --> 01:26:15,250 I si la càrrega es torna, que tornarà a créixer cap a fora, elàsticament. 1954 01:26:15,250 --> 01:26:17,050 >> Així que això es veu molt bé. 1955 01:26:17,050 --> 01:26:19,800 Tenim una gran quantitat d'instàncies de EC2. 1956 01:26:19,800 --> 01:26:21,671 Podem posar en memòria cau davant de les bases de dades, 1957 01:26:21,671 --> 01:26:23,045 tractar d'accelerar les bases de dades. 1958 01:26:23,045 --> 01:26:25,030 El següent punt de pressió normalment la gent veu 1959 01:26:25,030 --> 01:26:28,850 és que l'escala d'un joc utilitzant un sistema de base de dades relacional. 1960 01:26:28,850 --> 01:26:30,790 Per Déu, la base de dades rendiment és terrible. 1961 01:26:30,790 --> 01:26:31,932 Com podem millorar això? 1962 01:26:31,932 --> 01:26:33,640 Anem a tractar de posar cau davant d'això. 1963 01:26:33,640 --> 01:26:36,780 >> Bé, cau no funciona tan gran en els jocs, oi? 1964 01:26:36,780 --> 01:26:39,330 Pels jocs, l'escriptura és dolorós. 1965 01:26:39,330 --> 01:26:40,930 Els jocs són molt escriuen pesat. 1966 01:26:40,930 --> 01:26:43,610 Memòria cau no funciona quan estàs escriure pesada perquè tens sempre 1967 01:26:43,610 --> 01:26:44,610 ha de refrescar la cau. 1968 01:26:44,610 --> 01:26:47,780 Actualitza la memòria cau, és irrellevant per ser l'emmagatzematge en memòria cau. 1969 01:26:47,780 --> 01:26:49,780 En realitat és només una feina extra. 1970 01:26:49,780 --> 01:26:51,970 >> Llavors, on anem aquí? 1971 01:26:51,970 --> 01:26:54,400 Tens un gran coll d'ampolla allà a la base de dades. 1972 01:26:54,400 --> 01:26:57,661 I el lloc per anar òbviament està particionat. 1973 01:26:57,661 --> 01:26:59,410 La partició no és fàcil de fer quan estàs 1974 01:26:59,410 --> 01:27:01,900 es tracta de bases de dades relacionals. 1975 01:27:01,900 --> 01:27:05,080 Amb les bases de dades relacionals, ets responsable de la gestió, de manera efectiva, 1976 01:27:05,080 --> 01:27:06,210 l'espai de claus. 1977 01:27:06,210 --> 01:27:10,527 Estàs dient que els usuaris entre A i M anar aquí, entre N i Z van allà. 1978 01:27:10,527 --> 01:27:12,360 I vostè està canviant a través de l'aplicació. 1979 01:27:12,360 --> 01:27:15,000 Així que vostè està tractant amb aquesta font de dades de la partició. 1980 01:27:15,000 --> 01:27:18,670 Vostè té limitacions transaccionals que no abasten les particions. 1981 01:27:18,670 --> 01:27:20,560 Tens tota mena de desordre que ets 1982 01:27:20,560 --> 01:27:23,040 es tracta d'allà baix tractant per fer front a escalar 1983 01:27:23,040 --> 01:27:25,120 i la construcció d'una infraestructura més gran. 1984 01:27:25,120 --> 01:27:27,284 És simplement no és divertit. 1985 01:27:27,284 --> 01:27:30,930 >> AUDIÈNCIA: Llavors, estàs dient que augmentant els punts d'origen accelera 1986 01:27:30,930 --> 01:27:31,430 el procés de? 1987 01:27:31,430 --> 01:27:32,513 RICK Houlihan: L'augment? 1988 01:27:32,513 --> 01:27:33,520 Punts Font: AUDIÈNCIA. 1989 01:27:33,520 --> 01:27:34,410 RICK Houlihan: punts d'origen? 1990 01:27:34,410 --> 01:27:37,500 AUDIÈNCIA: A partir de la informació, on la informació està venint? 1991 01:27:37,500 --> 01:27:38,250 RICK Houlihan: No. 1992 01:27:38,250 --> 01:27:41,820 El que estic dient és l'augment de la nombre de particions al magatzem de dades 1993 01:27:41,820 --> 01:27:44,060 millora el rendiment. 1994 01:27:44,060 --> 01:27:48,300 Llavors, què està passant aquí és que els usuaris que entra a la instància EC2 aquí, 1995 01:27:48,300 --> 01:27:50,780 així, si necessito un usuari aquesta és la A a la M, aniré aquí. 1996 01:27:50,780 --> 01:27:53,560 Des N fins p, aniré aquí. 1997 01:27:53,560 --> 01:27:55,060 Des de P fins Z, aniré aquí. 1998 01:27:55,060 --> 01:27:57,120 >> AUDIÈNCIA: OK, així que aquests són els tots els emmagatzemats en diferents nodes? 1999 01:27:57,120 --> 01:27:57,911 >> RICK Houlihan: Sí. 2000 01:27:57,911 --> 01:28:00,210 Penseu en això com diferents sitges de dades. 2001 01:28:00,210 --> 01:28:01,660 Així que has de fer això. 2002 01:28:01,660 --> 01:28:02,910 Si vostè està tractant de fer això, si vostè està tractant 2003 01:28:02,910 --> 01:28:05,730 a escala en una plataforma relacional, això és el que estàs fent. 2004 01:28:05,730 --> 01:28:08,100 Vostè està prenent les dades i que està a tallar-lo. 2005 01:28:08,100 --> 01:28:10,975 I vostè està a l'altre costat de la partició diverses instàncies de la base de dades. 2006 01:28:10,975 --> 01:28:13,580 I va administrar tot el que en el nivell d'aplicació. 2007 01:28:13,580 --> 01:28:14,729 No és divertit. 2008 01:28:14,729 --> 01:28:15,770 Llavors, què és el que volem anar? 2009 01:28:15,770 --> 01:28:20,240 Volem anar DynamoDB, va aconseguir plenament, Magatzem de dades NoSQL, rendiment disposició. 2010 01:28:20,240 --> 01:28:22,680 Utilitzem índexs secundaris. 2011 01:28:22,680 --> 01:28:26,154 Es tracta bàsicament d'HTTP API i inclou suport de documents. 2012 01:28:26,154 --> 01:28:28,570 Així que vostè no ha de preocupar res d'això partició. 2013 01:28:28,570 --> 01:28:30,740 Ho fem tot per vostè. 2014 01:28:30,740 --> 01:28:33,260 Així que ara, en canvi, simplement escriure a la taula. 2015 01:28:33,260 --> 01:28:36,490 Si la taula ha de ser dividit, això succeeix darrere de les escenes. 2016 01:28:36,490 --> 01:28:40,642 Vostè està completament aïllat que com a desenvolupador. 2017 01:28:40,642 --> 01:28:42,350 Així que anem a parlar de alguns dels casos d'ús 2018 01:28:42,350 --> 01:28:47,564 que ens trobem en els jocs, comuna escenaris de joc, taula de classificació. 2019 01:28:47,564 --> 01:28:49,980 Així que tens als usuaris a arribar, els BoardNames que són 2020 01:28:49,980 --> 01:28:52,930 des d'ara, les qualificacions d'aquest usuari. 2021 01:28:52,930 --> 01:28:57,700 Podríem estar hash en la identificació d'usuari, i després tenim varietat en el joc. 2022 01:28:57,700 --> 01:28:59,960 Així que cada usuari vol veure tot el joc que ha jugat 2023 01:28:59,960 --> 01:29:01,770 i tota la seva puntuació més alta a través de tot el joc. 2024 01:29:01,770 --> 01:29:04,000 Així que aquest és el seu classificació personal. 2025 01:29:04,000 --> 01:29:10,010 >> Ara vull anar i vull get-- de manera que obtenir aquestes taules de classificació personals. 2026 01:29:10,010 --> 01:29:12,827 El que vull fer és anar a buscar la puntuació més alta entre tots els usuaris. 2027 01:29:12,827 --> 01:29:13,660 Llavors, com ho faig? 2028 01:29:13,660 --> 01:29:18,070 Quan es hash en el meu disc la ID d'usuari, va oscil·lar en el joc, 2029 01:29:18,070 --> 01:29:20,740 així que seguiré endavant i reestructurar, crear un GSI, 2030 01:29:20,740 --> 01:29:22,370 i jo vaig a reestructurar aquestes dades. 2031 01:29:22,370 --> 01:29:27,310 >> Ara em vaig per discutir sobre la BoardName, que és el joc. 2032 01:29:27,310 --> 01:29:29,800 I jo vaig a anar a la puntuació més alta. 2033 01:29:29,800 --> 01:29:31,540 I ara que he creat diferents cubs. 2034 01:29:31,540 --> 01:29:34,790 Estic usant la mateixa taula, les mateixes dades de l'element. 2035 01:29:34,790 --> 01:29:39,870 Però estic creant una galleda que dóna em una agregació de puntuació màxima per joc. 2036 01:29:39,870 --> 01:29:43,180 >> I puc consultar aquesta taula per obtenir aquesta informació. 2037 01:29:43,180 --> 01:29:50,890 Així que m'he fixat que el patró de consulta fins amb el suport d'un índex secundari. 2038 01:29:50,890 --> 01:29:54,556 Ara poden ordenar-se per BoardName i ordenats per topscore, depenent. 2039 01:29:54,556 --> 01:29:57,180 Així es pot veure, es tracta de tipus dels casos d'ús que obté en els videojocs. 2040 01:29:57,180 --> 01:30:02,190 Un altre bon cas d'ús que obtenim en els jocs és premis i que ha guanyat els premis. 2041 01:30:02,190 --> 01:30:05,340 I aquest és un gran cas d'ús on ens diem índexs dispersos. 2042 01:30:05,340 --> 01:30:07,340 Escassos són els índexs capacitat de generar 2043 01:30:07,340 --> 01:30:10,850 un índex que no necessàriament contenir cada article sobre la taula. 2044 01:30:10,850 --> 01:30:11,470 I per què no? 2045 01:30:11,470 --> 01:30:14,540 A causa de que l'atribut que està sent indexada no existeix en cada article. 2046 01:30:14,540 --> 01:30:16,460 >> Així que en aquest particular, cas d'ús, el que estic dient, 2047 01:30:16,460 --> 01:30:19,240 Saps què, vaig a crear un atribut anomenat Premi. 2048 01:30:19,240 --> 01:30:22,970 I jo vaig a donar a cada usuari que té un premi que atribueixen. 2049 01:30:22,970 --> 01:30:25,950 Els usuaris que no tenen premis són No va tenir aquest atribut. 2050 01:30:25,950 --> 01:30:27,800 Així que quan va crear el índex, els únics usuaris 2051 01:30:27,800 --> 01:30:28,960 que es van a mostrar en l'índex són 2052 01:30:28,960 --> 01:30:31,050 els que realment han guanyat premis. 2053 01:30:31,050 --> 01:30:34,440 Així que això és una gran manera de poder per crear índexs filtrats que 2054 01:30:34,440 --> 01:30:40,580 són molt, molt selectiu que no ho fan que índex de tota la taula. 2055 01:30:40,580 --> 01:30:43,050 >> Així que ens estem sota el temps aquí. 2056 01:30:43,050 --> 01:30:49,190 Vaig a seguir endavant i saltar i ometre aquest escenari. 2057 01:30:49,190 --> 01:30:52,625 Parli una mica sobre-- 2058 01:30:52,625 --> 01:30:54,460 >> AUDIÈNCIA: Puc fer una pregunta ràpida? 2059 01:30:54,460 --> 01:30:56,722 Un és escriure pesat? 2060 01:30:56,722 --> 01:30:57,680 RICK Houlihan: Què és? 2061 01:30:57,680 --> 01:30:58,596 AUDIÈNCIA: Escrigui pesat. 2062 01:30:58,596 --> 01:31:01,270 RICK Houlihan: Escriure pesat. 2063 01:31:01,270 --> 01:31:03,460 Deixa'm veure. 2064 01:31:03,460 --> 01:31:06,220 >> AUDIÈNCIA: O és que no una cosa que vostè pot simplement 2065 01:31:06,220 --> 01:31:08,809 veu a en qüestió de segons? 2066 01:31:08,809 --> 01:31:10,850 RICK Houlihan: Anem a través de l'escenari electoral. 2067 01:31:10,850 --> 01:31:11,670 No és tan dolent. 2068 01:31:11,670 --> 01:31:14,580 Vostès tenen un parell de minuts? 2069 01:31:14,580 --> 01:31:15,860 D'ACORD. 2070 01:31:15,860 --> 01:31:17,890 >> Així que anem a parlar sobre la votació. 2071 01:31:17,890 --> 01:31:20,250 Així que la votació en temps real, tenim requisits per a votar. 2072 01:31:20,250 --> 01:31:25,250 Els requisits són que permetem cada persona a votar només una vegada. 2073 01:31:25,250 --> 01:31:28,060 Volem que ningú sigui capaç canviar el seu vot. 2074 01:31:28,060 --> 01:31:31,045 Volem que l'agregació en temps real i l'anàlisi de dades demogràfiques 2075 01:31:31,045 --> 01:31:34,210 que nosaltres serem mostrant als usuaris en el lloc. 2076 01:31:34,210 --> 01:31:35,200 >> Penseu en aquest escenari. 2077 01:31:35,200 --> 01:31:37,550 Treballem molt de la realitat Programes de televisió on estan 2078 01:31:37,550 --> 01:31:38,960 fent aquest tipus exacte de les coses. 2079 01:31:38,960 --> 01:31:41,584 Així que vostè pot pensar en l'escenari, tenim milions i milions 2080 01:31:41,584 --> 01:31:43,959 nenes d'adolescents allà amb els seus telèfons mòbils 2081 01:31:43,959 --> 01:31:46,250 i el vot, i la votació, i votar per qualsevol que siguin 2082 01:31:46,250 --> 01:31:48,610 trobar a ser el més popular. 2083 01:31:48,610 --> 01:31:50,830 Així que aquests són alguns dels requisits que s'esgotin. 2084 01:31:50,830 --> 01:31:52,990 >> I així, la primera presa en la solució d'aquest problema 2085 01:31:52,990 --> 01:31:55,090 seria la de construir un aplicació molt simple. 2086 01:31:55,090 --> 01:31:56,490 Així que tinc aquesta aplicació. 2087 01:31:56,490 --> 01:31:57,950 Tinc alguns votants que hi ha. 2088 01:31:57,950 --> 01:31:59,980 Vénen en, que arribin a l'aplicació de la votació. 2089 01:31:59,980 --> 01:32:03,440 Tinc una mica de taula qualifiquen prima Només vaig a bolcar aquests vots en. 2090 01:32:03,440 --> 01:32:05,780 Vaig a tenir algun agregat taula de vots que 2091 01:32:05,780 --> 01:32:09,490 Faré la meva anàlisi i les dades demogràfiques, i posarem tot això en aquest país. 2092 01:32:09,490 --> 01:32:11,420 >> I això és molt bo. 2093 01:32:11,420 --> 01:32:12,332 La vida és bona. 2094 01:32:12,332 --> 01:32:15,040 De bona fins que ens adonem que la vida sempre hi ha un o dos 2095 01:32:15,040 --> 01:32:16,879 les persones que són populars en una elecció. 2096 01:32:16,879 --> 01:32:19,420 Hi ha només una o dues coses que la gent realment es preocupen. 2097 01:32:19,420 --> 01:32:22,340 I si vostè està votant en escala, de sobte estic 2098 01:32:22,340 --> 01:32:26,360 va a estar colpejant a la merda de dos candidats, un o dos candidats. 2099 01:32:26,360 --> 01:32:29,390 Un nombre molt limitat d'articles persones troben per ser popular. 2100 01:32:29,390 --> 01:32:31,710 >> Aquest no és un bon patró de disseny. 2101 01:32:31,710 --> 01:32:33,549 Això és realment una patró de disseny molt dolent 2102 01:32:33,549 --> 01:32:36,340 perquè crea exactament el que va parlar que era tecles d'accés ràpid. 2103 01:32:36,340 --> 01:32:38,960 Tecles d'accés són una cosa que no ens agrada. 2104 01:32:38,960 --> 01:32:40,470 >> Llavors, com solucionar-ho? 2105 01:32:40,470 --> 01:32:47,640 I realment, la forma de fer això és mitjançant l'adopció d'aquests cubs candidats 2106 01:32:47,640 --> 01:32:51,490 i per a cada candidat que tenim, anem a afegir un valor aleatori, 2107 01:32:51,490 --> 01:32:54,192 una cosa que sabem, a l'atzar valor entre un i 100, 2108 01:32:54,192 --> 01:32:56,620 entre 100 i 1.000, o entre un i 1.000, 2109 01:32:56,620 --> 01:32:59,940 No obstant això molts valors aleatoris que volen annexar a l'extrem d'aquest candidat. 2110 01:32:59,940 --> 01:33:01,330 >> I què he fet realment llavors? 2111 01:33:01,330 --> 01:33:05,830 Si estic fent servir la identificació de candidat el cub als vots totals, 2112 01:33:05,830 --> 01:33:08,780 si he afegit un atzar nombre al final d'això, 2113 01:33:08,780 --> 01:33:12,000 He creat ara 10 galledes, un cent cubs, mil cubs 2114 01:33:12,000 --> 01:33:14,160 que estic agregant qualifiquen d'ample. 2115 01:33:14,160 --> 01:33:18,030 >> Així que tinc milions i milions, i milions de registres procedents de 2116 01:33:18,030 --> 01:33:22,050 per a aquests candidats, ara estic difonent aquests vots en tot A_1 Candidat 2117 01:33:22,050 --> 01:33:24,630 a través A_100 Candidat, perquè cada vegada que un vot entra, 2118 01:33:24,630 --> 01:33:26,530 Estic generant un atzar valor entre un i 100. 2119 01:33:26,530 --> 01:33:29,446 Estic virades sobre l'extrem de la candidat a aquesta persona de votar a favor. 2120 01:33:29,446 --> 01:33:31,120 Estic de dúmping en aquest cub. 2121 01:33:31,120 --> 01:33:33,910 >> Ara a la part posterior, ho sé que em van donar cent cubs. 2122 01:33:33,910 --> 01:33:36,350 Així que quan em vull anar per davant i afegir els vots, 2123 01:33:36,350 --> 01:33:38,244 He llegit de tots els cubs. 2124 01:33:38,244 --> 01:33:39,160 Així que segueixo endavant i afegir. 2125 01:33:39,160 --> 01:33:42,410 I llavors jo recullo la dispersió on surto i dic bé, 2126 01:33:42,410 --> 01:33:45,399 vostè sap el que, la clau d'aquest candidat espais és més de cent cubs. 2127 01:33:45,399 --> 01:33:47,940 Vaig a reunir tota la els vots dels cent cubs. 2128 01:33:47,940 --> 01:33:49,981 Vaig a afegir ells i vaig a dir, 2129 01:33:49,981 --> 01:33:53,830 Candidat A té ara recompte total de vots de x. 2130 01:33:53,830 --> 01:33:55,690 >> Ara tant l'escriptura consulta i la consulta de lectura 2131 01:33:55,690 --> 01:33:58,160 estan molt ben distribuïda perquè jo estic escrivint un altre costat 2132 01:33:58,160 --> 01:34:00,320 i jo estic llegint a través de centenars de claus. 2133 01:34:00,320 --> 01:34:03,500 No estic escrivint i la lectura a través d'una clau ara. 2134 01:34:03,500 --> 01:34:04,950 Així que això és un gran model. 2135 01:34:04,950 --> 01:34:08,090 >> Això és en realitat probablement un del disseny més important 2136 01:34:08,090 --> 01:34:10,420 les pautes d'escala en NoSQL. 2137 01:34:10,420 --> 01:34:14,470 Vostè veurà aquest tipus de patró de disseny de tots els sabors. 2138 01:34:14,470 --> 01:34:19,100 MongoDB, DynamoDB, no ho fa importa, tots hem de fer això. 2139 01:34:19,100 --> 01:34:21,840 Perquè quan es tracta amb aquests enormes agregacions, 2140 01:34:21,840 --> 01:34:26,650 vostè ha de trobar una manera de escamparan per tot galledes. 2141 01:34:26,650 --> 01:34:29,512 Així que aquesta és la forma de fer això. 2142 01:34:29,512 --> 01:34:31,220 Molt bé, així que el que que estàs fent en aquest moment 2143 01:34:31,220 --> 01:34:35,252 és el que està operant fora de lectura cost per escriure escalabilitat. 2144 01:34:35,252 --> 01:34:37,085 El cost de la meva lectura és una mica més complex 2145 01:34:37,085 --> 01:34:40,220 i he d'anar a llegir a partir d'un cent cubs en lloc d'un. 2146 01:34:40,220 --> 01:34:41,310 Però sóc capaç d'escriure. 2147 01:34:41,310 --> 01:34:44,860 I el meu rendiment, la meva escriptura rendiment és increïble. 2148 01:34:44,860 --> 01:34:49,450 Així que és en general una valuosa tècnica per escalar DynamoDB, 2149 01:34:49,450 --> 01:34:51,350 o qualsevol base de dades NoSQL per al cas. 2150 01:34:51,350 --> 01:34:53,824 2151 01:34:53,824 --> 01:34:55,240 Llavors ens vam adonar de com escalar ella. 2152 01:34:55,240 --> 01:34:56,930 I ens vam adonar de com eliminar les claus calents. 2153 01:34:56,930 --> 01:34:57,820 I això és fantàstic. 2154 01:34:57,820 --> 01:34:58,960 I tenim aquest bonic sistema. 2155 01:34:58,960 --> 01:35:02,043 I ens ha donat de votació molt correcte perquè tenim registre de vot de-dupe. 2156 01:35:02,043 --> 01:35:03,130 Està construït en DynamoDB. 2157 01:35:03,130 --> 01:35:05,380 Parlem dels drets condicionals. 2158 01:35:05,380 --> 01:35:08,170 >> Quan un votant entra, posa una inserció a la taula, 2159 01:35:08,170 --> 01:35:11,220 s'insereixen amb la seva credencial d'elector, si tracten d'inserir una altra votació, 2160 01:35:11,220 --> 01:35:13,320 Faig una escriptura condicional. 2161 01:35:13,320 --> 01:35:16,960 Diguem només escriure aquest si això no existeix. 2162 01:35:16,960 --> 01:35:19,270 Així que tan aviat com veig que que el vot de colpejar la taula, 2163 01:35:19,270 --> 01:35:20,460 ningú més serà capaç de posar el seu vot en. 2164 01:35:20,460 --> 01:35:21,634 I això és fantàstic. 2165 01:35:21,634 --> 01:35:23,550 I estem incrementant els nostres comptadors de candidats. 2166 01:35:23,550 --> 01:35:25,466 I estem fent el nostre demografia i tot això. 2167 01:35:25,466 --> 01:35:29,110 Però què passa si el meu aplicació es cau? 2168 01:35:29,110 --> 01:35:31,350 Ara, de sobte vots estan entrant, i jo 2169 01:35:31,350 --> 01:35:34,840 no saben si estan rebent processats en les meves anàlisis i demografia 2170 01:35:34,840 --> 01:35:36,040 més. 2171 01:35:36,040 --> 01:35:38,462 I quan l'aplicació torna, com 2172 01:35:38,462 --> 01:35:41,420 diables vaig a saber el que qualifiquen tenen estat processat i per on començo? 2173 01:35:41,420 --> 01:35:44,530 >> Així que aquest és un problema real quan començar a mirar aquest tipus d'escenari. 2174 01:35:44,530 --> 01:35:45,571 ¿I com es resol això? 2175 01:35:45,571 --> 01:35:48,070 Resolem amb el que cridar DynamoDB Rierols. 2176 01:35:48,070 --> 01:35:53,470 Corrents s'ordena la vegada i registre de canvis particions de cada accés 2177 01:35:53,470 --> 01:35:55,700 a taula, cada escriptura l'accés a la taula. 2178 01:35:55,700 --> 01:35:58,810 Totes les dades que s'escriuen en el taula apareix en la seqüència. 2179 01:35:58,810 --> 01:36:01,815 >> Es tracta bàsicament d'una cua de 24 hores. 2180 01:36:01,815 --> 01:36:03,690 Els productes que arribin al rierol, viuen durant 24 hores. 2181 01:36:03,690 --> 01:36:05,990 Es poden llegir diverses vegades. 2182 01:36:05,990 --> 01:36:09,400 Garantit per ser lliurats només una vegada a la corrent, 2183 01:36:09,400 --> 01:36:11,180 es podia llegir un nombre n de vegades. 2184 01:36:11,180 --> 01:36:14,910 Així que no obstant això molts processos que vols consumir aquestes dades, es pot consumir. 2185 01:36:14,910 --> 01:36:16,350 Apareixerà cada actualització. 2186 01:36:16,350 --> 01:36:18,455 Cada escriptura només es aparèixer una vegada en la seqüència. 2187 01:36:18,455 --> 01:36:20,621 Així que vostè no ha de preocupar sobre el processament de dues vegades 2188 01:36:20,621 --> 01:36:22,500 De la mateixa procés. 2189 01:36:22,500 --> 01:36:25,350 >> Està estrictament ordenat per article. 2190 01:36:25,350 --> 01:36:28,180 Quan diem que el temps ordenat i es va repartir, 2191 01:36:28,180 --> 01:36:30,680 veuràs per partició en la seqüència. 2192 01:36:30,680 --> 01:36:33,169 Veurà articles, actualitzacions en ordre. 2193 01:36:33,169 --> 01:36:35,210 No estem garantint sobre el rierol que ets 2194 01:36:35,210 --> 01:36:40,240 posarà cada transacció en l'ordre a través d'articles. 2195 01:36:40,240 --> 01:36:42,440 >> Així rierols són idempotent. 2196 01:36:42,440 --> 01:36:44,037 Tenim tots sabem el idempotent significa? 2197 01:36:44,037 --> 01:36:46,620 Idempotent vol dir que vostè pot fer-ho una altra vegada, i una altra, i una altra. 2198 01:36:46,620 --> 01:36:48,200 El resultat va ser el mateix. 2199 01:36:48,200 --> 01:36:49,991 >> Streams són idempotent, però han de ser 2200 01:36:49,991 --> 01:36:54,860 jugat des del punt de partida, on sigui que triï, fins al final, 2201 01:36:54,860 --> 01:36:57,950 o que no es traduirà en els mateixos valors. 2202 01:36:57,950 --> 01:36:59,727 >> El mateix amb MongoDB. 2203 01:36:59,727 --> 01:37:01,560 MongoDB té una construcció que ells anomenen el oplog. 2204 01:37:01,560 --> 01:37:04,140 És la mateixa construcció exacta. 2205 01:37:04,140 --> 01:37:06,500 Moltes bases de dades NoSQL tenir aquest constructe. 2206 01:37:06,500 --> 01:37:08,790 El fan servir per fer les coses com la replicació, que 2207 01:37:08,790 --> 01:37:10,475 és exactament el que fem amb els corrents. 2208 01:37:10,475 --> 01:37:12,350 AUDIÈNCIA: Potser una pregunta herètica, però 2209 01:37:12,350 --> 01:37:13,975 parlar d'aplicacions fent de sòl així successivament. 2210 01:37:13,975 --> 01:37:16,089 Són corrents garantits per Mai possiblement baixar? 2211 01:37:16,089 --> 01:37:18,630 RICK Houlihan: Sí, rierols estan garantits per no baixar. 2212 01:37:18,630 --> 01:37:21,040 Gestionem la infraestructura darrere. rierols automàticament 2213 01:37:21,040 --> 01:37:22,498 implementar en el seu grup d'escala automàtica. 2214 01:37:22,498 --> 01:37:25,910 Anem a anar a través d'una petita poc sobre el que succeeix. 2215 01:37:25,910 --> 01:37:30,060 >> No hauria de dir que no són garantit per no baixar. 2216 01:37:30,060 --> 01:37:33,110 Els elements estan garantits a aparèixer en el corrent. 2217 01:37:33,110 --> 01:37:36,740 I el corrent serà accessible. 2218 01:37:36,740 --> 01:37:40,580 Llavors, què cau o es torna dalt, això passa per sota. 2219 01:37:40,580 --> 01:37:43,844 Es Cobertes està bé. 2220 01:37:43,844 --> 01:37:46,260 Molt bé, de manera que obtenir diferents tipus de vista de la pantalla. 2221 01:37:46,260 --> 01:37:51,040 Els tipus de vista que són importants per a un programador normalment són, què era? 2222 01:37:51,040 --> 01:37:52,370 Tinc la vella visió. 2223 01:37:52,370 --> 01:37:55,630 Quan una actualització colpeja la taula, que va empènyer l'antiga visió del corrent 2224 01:37:55,630 --> 01:38:02,070 el que les dades es poden arxivar o canvi control, identificació canvi, canvi 2225 01:38:02,070 --> 01:38:03,600 gestió. 2226 01:38:03,600 --> 01:38:07,160 >> La nova imatge, el que és ara, després de l'actualització, que és un altre tipus de vista 2227 01:38:07,160 --> 01:38:07,660 vostè pot aconseguir. 2228 01:38:07,660 --> 01:38:09,660 Vostè pot obtenir tant les velles i noves imatges. 2229 01:38:09,660 --> 01:38:10,660 Potser els dos vulgui. 2230 01:38:10,660 --> 01:38:11,790 Vull veure el que era. 2231 01:38:11,790 --> 01:38:13,290 Vull veure el que ha canviat a. 2232 01:38:13,290 --> 01:38:15,340 >> Tinc un tipus de compliment del procés que s'executa. 2233 01:38:15,340 --> 01:38:17,430 Ha de verificar que Quan aquestes coses canvien, 2234 01:38:17,430 --> 01:38:21,840 que estan dins de certs límits o dins de certs paràmetres. 2235 01:38:21,840 --> 01:38:23,840 >> I llavors potser només necessitat de saber el que ha canviat. 2236 01:38:23,840 --> 01:38:26,240 No m'importa el que el tema va canviar. 2237 01:38:26,240 --> 01:38:28,580 No necessito a necessitar saber ho atribueix canviat. 2238 01:38:28,580 --> 01:38:30,882 Només necessito saber que els articles estan sent tocats. 2239 01:38:30,882 --> 01:38:33,340 Així que aquests són els tipus de vistes que es baixi el corrent 2240 01:38:33,340 --> 01:38:35,960 i es pot interactuar. 2241 01:38:35,960 --> 01:38:37,840 >> L'aplicació que consumeix el corrent, 2242 01:38:37,840 --> 01:38:39,298 això és una espècie de la forma en que funciona. 2243 01:38:39,298 --> 01:38:42,570 Client DynamoDB demani enviar dades a les taules. 2244 01:38:42,570 --> 01:38:44,750 Streams desplegar en el que anomenem fragments. 2245 01:38:44,750 --> 01:38:47,380 Fragments s'escalen independentment de la taula. 2246 01:38:47,380 --> 01:38:50,660 Ells no s'alineen completament a les particions de la taula. 2247 01:38:50,660 --> 01:38:52,540 I la raó per la qual és perquè s'alineen 2248 01:38:52,540 --> 01:38:55,430 a la capacitat, el corrent la capacitat de la taula. 2249 01:38:55,430 --> 01:38:57,600 >> Es despleguen en el seu propi grup d'escalat automàtic, 2250 01:38:57,600 --> 01:39:00,800 i comencen a girar a terme en funció de la quantitat d'escriptures estan entrant, 2251 01:39:00,800 --> 01:39:03,090 quants reads-- realitat és escriu. 2252 01:39:03,090 --> 01:39:05,820 No hi ha reads-- sinó com moltes escriptures estan arribant. 2253 01:39:05,820 --> 01:39:08,200 >> I després a la part posterior fi, tenim el que 2254 01:39:08,200 --> 01:39:11,390 trucar a un KCL o Kinesis Client Library. 2255 01:39:11,390 --> 01:39:19,190 Kinesis és un flux de dades tecnologia de processament d'Amazon. 2256 01:39:19,190 --> 01:39:22,040 I rierols es construeix en això. 2257 01:39:22,040 --> 01:39:25,670 >> Així s'utilitza un KCL habilitat aplicació llegir el corrent. 2258 01:39:25,670 --> 01:39:28,752 La biblioteca de clients Kinesis realitat gestiona els treballadors per a vostè. 2259 01:39:28,752 --> 01:39:30,460 I també fa alguns coses interessants. 2260 01:39:30,460 --> 01:39:35,630 Es crearà algunes taules fins en el seu espai de taula DynamoDB 2261 01:39:35,630 --> 01:39:38,410 per rastrejar quins articles han estat processats. 2262 01:39:38,410 --> 01:39:41,190 Així d'aquesta manera si es cau de nou, si cau una i ve i es posa 2263 01:39:41,190 --> 01:39:45,570 es va posar dret, es pot determinar on era que en la tramitació del corrent. 2264 01:39:45,570 --> 01:39:48,360 >> Això és molt important quan vostè està parlant de replicació. 2265 01:39:48,360 --> 01:39:50,350 Necessito saber el les dades s'ha processat 2266 01:39:50,350 --> 01:39:52,810 i el que les dades encara no s'ha processat. 2267 01:39:52,810 --> 01:39:57,380 Així que la biblioteca KCL per als fluxos voluntat li donarà una gran quantitat d'aquesta funcionalitat. 2268 01:39:57,380 --> 01:39:58,990 S'ocupa de tot el servei de neteja. 2269 01:39:58,990 --> 01:40:01,140 Es posa dret a un treballador per cada fragment. 2270 01:40:01,140 --> 01:40:04,620 Es crea una taula administrativa per a cada fragment, per cada treballador. 2271 01:40:04,620 --> 01:40:07,560 I a mesura que els treballadors d'incendis, mantenen aquestes taules 2272 01:40:07,560 --> 01:40:10,510 perquè sàpiga aquest registre va ser llegida i processada. 2273 01:40:10,510 --> 01:40:13,850 I després d'aquesta manera si el procés mor i ve de nou en línia, 2274 01:40:13,850 --> 01:40:17,940 pot reprendre just on va desenganxar. 2275 01:40:17,940 --> 01:40:20,850 >> Així que fem servir això per replicació creuada regió. 2276 01:40:20,850 --> 01:40:24,680 Molts clients tenen la necessitat de moure dades o parts de les seves taules de dades 2277 01:40:24,680 --> 01:40:25,920 voltant de les diferents regions. 2278 01:40:25,920 --> 01:40:29,230 Hi ha nou regions al voltant del món. 2279 01:40:29,230 --> 01:40:32,100 Així que podria haver-hi un jo need-- podria tenir els usuaris a Àsia, els usuaris 2280 01:40:32,100 --> 01:40:34,150 a la costa est dels Estats Units. 2281 01:40:34,150 --> 01:40:38,980 Tenen diferents dades que necessita ser distribuït localment. 2282 01:40:38,980 --> 01:40:42,510 I potser un usuari vola des Àsia als Estats Units, 2283 01:40:42,510 --> 01:40:45,020 i vull replicar les seves dades amb ell. 2284 01:40:45,020 --> 01:40:49,340 Així que quan ell es baixa de l'avió, que té una bona experiència en l'ús de la seva aplicació mòbil. 2285 01:40:49,340 --> 01:40:52,360 >> Podeu utilitzar la regió creu biblioteca de replicació per fer això. 2286 01:40:52,360 --> 01:40:55,730 Bàsicament tenim proporcionat dues tecnologies. 2287 01:40:55,730 --> 01:40:59,400 Un és una aplicació de consola que pugui posar-se dret a la seva pròpia instància EC2. 2288 01:40:59,400 --> 01:41:01,240 S'executa la replicació pur. 2289 01:41:01,240 --> 01:41:02,720 I després us vam donar la biblioteca. 2290 01:41:02,720 --> 01:41:06,070 La biblioteca es pot utilitzar per construir seva pròpia aplicació si 2291 01:41:06,070 --> 01:41:10,740 voler fer coses boges amb aquest data-- filtre, replicar només part d'ella, 2292 01:41:10,740 --> 01:41:14,120 rotar les dades, moure en un diferent de taula, així successivament i així successivament. 2293 01:41:14,120 --> 01:41:18,700 2294 01:41:18,700 --> 01:41:20,520 Així que això és una cosa del que sembla. 2295 01:41:20,520 --> 01:41:23,690 >> DynamoDB Streams pot haver processat pel que anomenem Lambda. 2296 01:41:23,690 --> 01:41:27,394 Hem esmentat una mica sobre esdeveniments arquitectures d'aplicacions accionades. 2297 01:41:27,394 --> 01:41:28,810 Lambda és un component clau d'això. 2298 01:41:28,810 --> 01:41:32,840 Lambda és el codi que dispara la demanda en resposta a un esdeveniment en particular. 2299 01:41:32,840 --> 01:41:36,020 Un d'aquests esdeveniments podria ser una registre que apareix en la seqüència. 2300 01:41:36,020 --> 01:41:39,100 Si un registre apareix a la corrent, anem a cridar aquesta funció Java. 2301 01:41:39,100 --> 01:41:44,980 Bé, aquest és JavaScript i Lambda dóna suport NODE.JS, Java, Python, 2302 01:41:44,980 --> 01:41:47,820 i aviat donar suport altres idiomes també. 2303 01:41:47,820 --> 01:41:50,940 I n'hi ha prou amb dir, és de codi pur. 2304 01:41:50,940 --> 01:41:53,610 escriure En Java, es defineix una classe. 2305 01:41:53,610 --> 01:41:55,690 Vostè prem el JAR dalt a Lambda. 2306 01:41:55,690 --> 01:42:00,200 I a continuació, s'especifica quina classe trucar en resposta a quin esdeveniment. 2307 01:42:00,200 --> 01:42:04,770 I llavors la infraestructura Lambda darrere que s'executarà aquest codi. 2308 01:42:04,770 --> 01:42:06,730 >> Aquest codi pot processar registres fora del corrent. 2309 01:42:06,730 --> 01:42:08,230 Pot fer el que vulgui amb ell. 2310 01:42:08,230 --> 01:42:11,650 En aquest exemple en particular, tots estem realment fent és registrar els atributs. 2311 01:42:11,650 --> 01:42:13,480 Però això és només codi. 2312 01:42:13,480 --> 01:42:15,260 El codi pot fer qualsevol cosa, oi? 2313 01:42:15,260 --> 01:42:16,600 >> Així que vostè pot girar aquestes dades. 2314 01:42:16,600 --> 01:42:18,160 Podeu obtenir una vista derivada. 2315 01:42:18,160 --> 01:42:21,160 Si es tracta d'una estructura de document, vostè pot aplanar l'estructura. 2316 01:42:21,160 --> 01:42:24,300 Podeu crear índexs alternatius. 2317 01:42:24,300 --> 01:42:27,100 Tots els tipus de coses que vostè pot veure amb els corrents DynamoDB. 2318 01:42:27,100 --> 01:42:28,780 >> I realment, això és el que sembla. 2319 01:42:28,780 --> 01:42:29,940 Perquè pugui obtenir aquestes actualitzacions entrant. 2320 01:42:29,940 --> 01:42:31,190 Estan sortint de la cadena. 2321 01:42:31,190 --> 01:42:32,720 Són llegits per la funció de Lambda. 2322 01:42:32,720 --> 01:42:37,480 Estan girant les dades i empenyent-la cap amunt en les taules derivades, 2323 01:42:37,480 --> 01:42:42,200 notificar a sistemes externs de canvi, i empenyent dades en ElastiCache. 2324 01:42:42,200 --> 01:42:45,900 >> Parlem de com posar la memòria cau al davant de la base de dades perquè les vendes 2325 01:42:45,900 --> 01:42:46,450 escenari. 2326 01:42:46,450 --> 01:42:50,049 Bé, què passa si actualitzar la descripció de l'article? 2327 01:42:50,049 --> 01:42:52,340 Bé, si jo tingués un Lambda funció que s'executa en aquesta taula, 2328 01:42:52,340 --> 01:42:55,490 si actualitzo la descripció de l'article, que va recollir el registre del corrent, 2329 01:42:55,490 --> 01:42:58,711 i que va a actualitzar el ElastiCache instància amb les noves dades. 2330 01:42:58,711 --> 01:43:00,460 Així que això és una gran quantitat de el que fem amb Lambda. 2331 01:43:00,460 --> 01:43:02,619 És codi cola, connectors. 2332 01:43:02,619 --> 01:43:04,410 I el que realment dóna la capacitat de llançar 2333 01:43:04,410 --> 01:43:07,930 i per executar aplicacions molt complexes sense un servidor dedicat 2334 01:43:07,930 --> 01:43:10,371 infraestructura, que és realment genial. 2335 01:43:10,371 --> 01:43:13,100 >> Així que anem a tornar al nostre en temps real l'arquitectura de votació. 2336 01:43:13,100 --> 01:43:17,984 Això és nou i millorat amb el nostre rierols i KCL habilitat aplicació. 2337 01:43:17,984 --> 01:43:20,150 Igual que abans, podem gestionar qualsevol escala de les eleccions. 2338 01:43:20,150 --> 01:43:21,100 Ens agrada això. 2339 01:43:21,100 --> 01:43:24,770 Estem fent fora frunzits de dispersió a través de múltiples cubs. 2340 01:43:24,770 --> 01:43:26,780 Tenim bloqueig optimista passant. 2341 01:43:26,780 --> 01:43:30,192 Podem mantenir els nostres votants canviïn els seus vots. 2342 01:43:30,192 --> 01:43:31,400 Només poden votar només una vegada. 2343 01:43:31,400 --> 01:43:32,880 Això és fantàstic. 2344 01:43:32,880 --> 01:43:35,895 Tolerància a fallades en temps real, agregació escalable ara. 2345 01:43:35,895 --> 01:43:38,270 Si la cosa es cau, es sap on per reiniciar en si 2346 01:43:38,270 --> 01:43:41,300 quan es tracta d'una còpia de seguretat, ja estem fent servir l'aplicació KCL. 2347 01:43:41,300 --> 01:43:45,700 I llavors també podem usar aquesta Aplicació KCL per empènyer dades fora 2348 01:43:45,700 --> 01:43:48,820 al desplaçament al vermell per a altres anàlisi d'aplicacions, o l'ús 2349 01:43:48,820 --> 01:43:51,990 MapReduce els elàstics per executar agregacions de streaming en temps real fos 2350 01:43:51,990 --> 01:43:53,180 d'aquestes dades. 2351 01:43:53,180 --> 01:43:55,480 >> Així que aquestes són les coses que nosaltres no han parlat molt. 2352 01:43:55,480 --> 01:43:57,375 Però són addicionals tecnologies que vénen 2353 01:43:57,375 --> 01:44:00,310 tenir quan estàs buscant en aquests tipus d'escenaris. 2354 01:44:00,310 --> 01:44:03,160 >> Molt bé, així que això és tot anàlisi amb DynamoDB Rierols. 2355 01:44:03,160 --> 01:44:05,340 Vostè pot obtenir de-dupe dades, fer tot tipus 2356 01:44:05,340 --> 01:44:09,490 de coses boniques, les dades agregades en memòria, crear aquestes taules derivades. 2357 01:44:09,490 --> 01:44:13,110 Això és un cas d'ús enorme que molts dels clients 2358 01:44:13,110 --> 01:44:16,950 estan involucrats amb, prenent el niada propietats dels documents JSON 2359 01:44:16,950 --> 01:44:18,946 i la creació d'índexs addicionals. 2360 01:44:18,946 --> 01:44:21,680 2361 01:44:21,680 --> 01:44:23,150 >> Som al final. 2362 01:44:23,150 --> 01:44:26,689 Gràcies per la seva paciència amb mi. 2363 01:44:26,689 --> 01:44:28,480 Així que anem a parlar de arquitectura de referència. 2364 01:44:28,480 --> 01:44:33,440 DynamoDB es troba enmig del gran part de la infraestructura de AWS. 2365 01:44:33,440 --> 01:44:37,090 Bàsicament, vostè pot connectar fins al que vulguis. 2366 01:44:37,090 --> 01:44:45,600 Les aplicacions creades usant Dynamo inclou Lambda, ElastiCache, CloudSearch, 2367 01:44:45,600 --> 01:44:49,890 empènyer les dades cap elàstic MapReduce, importació i exportació de DynamoDB 2368 01:44:49,890 --> 01:44:52,370 en S3, tots els tipus de fluxos de treball. 2369 01:44:52,370 --> 01:44:54,120 Però probablement la millor cosa que parlar, 2370 01:44:54,120 --> 01:44:56,119 i això és el que és realment interessant és quan 2371 01:44:56,119 --> 01:44:58,350 parlar d'aplicacions per esdeveniments. 2372 01:44:58,350 --> 01:45:00,300 >> Aquest és un exemple de un projecte intern 2373 01:45:00,300 --> 01:45:04,850 que tenim quan estem en realitat publicació per recollir resultats de l'enquesta. 2374 01:45:04,850 --> 01:45:07,700 Així que en un enllaç de correu electrònic que que vam enviar, hi haurà 2375 01:45:07,700 --> 01:45:11,350 ser una mica clic enllaç que diu aquí per respondre a l'enquesta. 2376 01:45:11,350 --> 01:45:14,070 I quan una persona fa clic aquest vincle, el que passa 2377 01:45:14,070 --> 01:45:18,020 és que tiri avall d'una assegurança HTML formulari d'enquesta de S3. 2378 01:45:18,020 --> 01:45:18,980 No hi ha servidor. 2379 01:45:18,980 --> 01:45:20,600 Això és només un objecte S3. 2380 01:45:20,600 --> 01:45:22,770 >> Aquesta forma apareix, càrrega en el navegador. 2381 01:45:22,770 --> 01:45:24,240 Té Backbone. 2382 01:45:24,240 --> 01:45:30,160 Té complex JavaScript que s'està executant. 2383 01:45:30,160 --> 01:45:33,557 Així que és d'aplicació molt rica s'executa en el navegador del client. 2384 01:45:33,557 --> 01:45:36,390 Ells no saben que no ho són interactuar amb un servidor back-end. 2385 01:45:36,390 --> 01:45:38,220 En aquest punt, és tot navegador. 2386 01:45:38,220 --> 01:45:41,780 >> Publiquen els resultats al cridem a l'API d'Amazon Gateway. 2387 01:45:41,780 --> 01:45:46,270 API Gateway és simplement una API web que es pot definir i connectar 2388 01:45:46,270 --> 01:45:47,760 al que vulguis. 2389 01:45:47,760 --> 01:45:50,990 En aquest cas particular, estem connectat a una funció lambda. 2390 01:45:50,990 --> 01:45:54,797 >> Així que la meva operació POST és passant amb cap servidor. 2391 01:45:54,797 --> 01:45:56,380 Bàsicament aquesta porta d'enllaç API s'asseu allà. 2392 01:45:56,380 --> 01:45:58,770 Em costa res fins que la gent comença a publicar a ella, no? 2393 01:45:58,770 --> 01:46:00,269 La funció de Lambda només se senti allà. 2394 01:46:00,269 --> 01:46:03,760 I em costa res fins la gent comença a colpejar-lo. 2395 01:46:03,760 --> 01:46:07,270 Així es pot veure, ja que el volum augmenta, aquí és quan les acusacions vénen. 2396 01:46:07,270 --> 01:46:09,390 No estic corrent un servidor 24.7. 2397 01:46:09,390 --> 01:46:12,310 >> Així que em tiri de la forma baixar de la galleda, 2398 01:46:12,310 --> 01:46:15,719 i he posat a través de l'API Porta d'entrada a la funció de Lambda. 2399 01:46:15,719 --> 01:46:17,510 I llavors el Lambda funció diu, ja saps 2400 01:46:17,510 --> 01:46:20,600 la qual cosa, tinc alguns PII, alguns informació d'identificació personal 2401 01:46:20,600 --> 01:46:21,480 en aquestes respostes. 2402 01:46:21,480 --> 01:46:23,020 Vaig aconseguir comentaris procedents dels usuaris. 2403 01:46:23,020 --> 01:46:24,230 Tinc adreces de correu electrònic. 2404 01:46:24,230 --> 01:46:26,190 Tinc els noms d'usuari. 2405 01:46:26,190 --> 01:46:27,810 >> Déjame dividir això. 2406 01:46:27,810 --> 01:46:30,280 Vaig a generar una mica de metadades fora d'aquest registre. 2407 01:46:30,280 --> 01:46:32,850 I vaig a empènyer el metadades en DynamoDB. 2408 01:46:32,850 --> 01:46:36,059 I podria xifrar totes les dades i poseu-lo a DynamoDB si vull. 2409 01:46:36,059 --> 01:46:38,600 Però és més fàcil per a mi, en aquest utilitzi cas, perquè endavant un exemple, 2410 01:46:38,600 --> 01:46:42,800 Vaig a empènyer les dades en brut en una galleda de S3 xifrat. 2411 01:46:42,800 --> 01:46:47,240 Així que utilitzar construït a la banda del servidor S3 encriptació i gestió de claus d'Amazon 2412 01:46:47,240 --> 01:46:51,600 Servei de manera que tinc una clau que pot girar en un interval regular, 2413 01:46:51,600 --> 01:46:55,010 i puc protegir les dades PII com a part de tot aquest flux de treball. 2414 01:46:55,010 --> 01:46:55,870 >> Llavors, què he fet? 2415 01:46:55,870 --> 01:47:00,397 Acabo desplegat en el seu conjunt aplicació, i no tinc cap servidor. 2416 01:47:00,397 --> 01:47:02,980 Així que és el que de successos d'aplicació impulsada arquitectura fa per vostè. 2417 01:47:02,980 --> 01:47:05,730 >> Ara bé, si es pensa en el cas d'ús de esto-- 2418 01:47:05,730 --> 01:47:08,730 tenim altres clients que estic parlant al voltant d'aquesta arquitectura exacta que 2419 01:47:08,730 --> 01:47:14,560 executar fenomenalment grans campanyes, que estan mirant això i va, oh el meu. 2420 01:47:14,560 --> 01:47:17,840 Perquè ara, que poden bàsicament empènyer fora d'allà, 2421 01:47:17,840 --> 01:47:21,900 deixar que la campanya simplement seure allà fins que llança, i no 2422 01:47:21,900 --> 01:47:24,400 has de preocupar un rave quin tipus d'infraestructura 2423 01:47:24,400 --> 01:47:26,120 va a ser-hi per donar-li suport. 2424 01:47:26,120 --> 01:47:28,600 I llavors tan aviat com que la campanya es porta a terme, 2425 01:47:28,600 --> 01:47:31,520 és com la infraestructura acaba immediatament desapareix 2426 01:47:31,520 --> 01:47:33,680 perquè realment hi ha infraestructura. 2427 01:47:33,680 --> 01:47:35,660 És codi només que seu a Lambda. 2428 01:47:35,660 --> 01:47:38,560 És només que les dades es troba a DynamoDB. 2429 01:47:38,560 --> 01:47:41,340 És una manera increïble per crear aplicacions. 2430 01:47:41,340 --> 01:47:43,970 >> AUDIÈNCIA: Llavors, és més efímer del que seria 2431 01:47:43,970 --> 01:47:45,740 si s'emmagatzema en un servidor real? 2432 01:47:45,740 --> 01:47:46,823 >> RICK Houlihan: Per descomptat. 2433 01:47:46,823 --> 01:47:49,190 Perquè aquesta instància de servidor hauria de ser un 7/24. 2434 01:47:49,190 --> 01:47:51,954 Ha d'estar disponible per algú per respondre a. 2435 01:47:51,954 --> 01:47:52,620 Bé endevinin què? 2436 01:47:52,620 --> 01:47:55,410 S3 està disponible 7/24. 2437 01:47:55,410 --> 01:47:57,100 S3 sempre respon. 2438 01:47:57,100 --> 01:47:59,320 I S3 és molt, molt bo a servir els objectes. 2439 01:47:59,320 --> 01:48:02,590 Aquests objectes poden ser arxius HTML, o Arxius JavaScript, o el que vulguis. 2440 01:48:02,590 --> 01:48:07,430 Podeu executar aplicacions web molt rics de cubs S3, i la gent fa. 2441 01:48:07,430 --> 01:48:10,160 >> I així, aquesta és la idea aquí és allunyar-se de la forma 2442 01:48:10,160 --> 01:48:11,270 solíem pensar-hi. 2443 01:48:11,270 --> 01:48:14,270 A tots ens acostumem a pensar en termes de servidors i els tècnics. 2444 01:48:14,270 --> 01:48:16,580 No es tracta d'això. 2445 01:48:16,580 --> 01:48:19,310 Es tracta de la infraestructura com a codi. 2446 01:48:19,310 --> 01:48:22,470 Implementar el codi per al núvol i deixeu que el núvol dirigit per vostè. 2447 01:48:22,470 --> 01:48:24,980 I això és el AWS està tractant de fer. 2448 01:48:24,980 --> 01:48:29,690 >> AUDIÈNCIA: Així que la seva caixa d'or en el medi de la porta d'enllaç API no és com al servidor, 2449 01:48:29,690 --> 01:48:30,576 però en canvi és sol-- 2450 01:48:30,576 --> 01:48:32,850 >> RICK Houlihan: Vostè pot pensar això com a façana servidor. 2451 01:48:32,850 --> 01:48:38,040 Tot el que és és que va a prendre un HTTP sol·licitar i assignar a un altre procés. 2452 01:48:38,040 --> 01:48:39,192 Això és tot el que fa. 2453 01:48:39,192 --> 01:48:41,525 I en aquest cas, estem cartografia a una funció Lambda. 2454 01:48:41,525 --> 01:48:44,119 2455 01:48:44,119 --> 01:48:45,410 Molt bé, així que això és tot el que tinc. 2456 01:48:45,410 --> 01:48:46,190 Moltes gràcies. 2457 01:48:46,190 --> 01:48:46,800 T'ho agraeixo. 2458 01:48:46,800 --> 01:48:48,100 Sé que volem una mica més de temps. 2459 01:48:48,100 --> 01:48:49,980 I espero que vostès ja ha rebut una mica d'informació 2460 01:48:49,980 --> 01:48:51,410 que es pot portar a l'actualitat. 2461 01:48:51,410 --> 01:48:53,520 I demano disculpes si em vaig anar sobre alguns dels seus caps, 2462 01:48:53,520 --> 01:48:56,697 però hi ha una bona quantitat de coneixements bàsics fonamentals 2463 01:48:56,697 --> 01:48:58,280 que crec que és molt valuós per a vostè. 2464 01:48:58,280 --> 01:48:59,825 Així que gràcies per convidar-me. 2465 01:48:59,825 --> 01:49:00,325 [Aplaudiments] 2466 01:49:00,325 --> 01:49:02,619 AUDIÈNCIA: [inaudible] és quan vostè deia 2467 01:49:02,619 --> 01:49:05,160 que havia d'anar a través de la cosa des del principi fins al final 2468 01:49:05,160 --> 01:49:07,619 per obtenir els valors correctes o els mateixos valors, 2469 01:49:07,619 --> 01:49:09,410 Com els valors canviar si [inaudible]. 2470 01:49:09,410 --> 01:49:10,480 >> RICK Houlihan: Oh, idempotent? 2471 01:49:10,480 --> 01:49:11,800 Com canviarien els valors? 2472 01:49:11,800 --> 01:49:15,180 Bé, perquè si jo no corro tot el camí fins al final, 2473 01:49:15,180 --> 01:49:19,770 llavors jo no sé el que canvia es van fer en l'última milla. 2474 01:49:19,770 --> 01:49:22,144 No serà el mateixes dades que el que vaig veure. 2475 01:49:22,144 --> 01:49:24,560 AUDIÈNCIA: Oh, de manera que només no han aconseguit l'entrada completa. 2476 01:49:24,560 --> 01:49:24,770 RICK Houlihan: Correcte. 2477 01:49:24,770 --> 01:49:26,895 Has d'anar des del principi a fi, i llavors és 2478 01:49:26,895 --> 01:49:29,280 serà un estat coherent. 2479 01:49:29,280 --> 01:49:31,520 Fresc. 2480 01:49:31,520 --> 01:49:35,907 >> AUDIÈNCIA: ¿Així que ens heu mostrat DynamoDB pot fer de documents o el valor de la clau. 2481 01:49:35,907 --> 01:49:38,740 I ens vam passar un munt de temps en el valor de la clau amb un hash i les formes 2482 01:49:38,740 --> 01:49:40,005 per donar-li la volta al voltant. 2483 01:49:40,005 --> 01:49:43,255 Quan es mirava en aquestes taules, és que deixant enrere l'enfocament document? 2484 01:49:43,255 --> 01:49:44,600 >> RICK Houlihan: Jo no ho faria dir deixant enrere. 2485 01:49:44,600 --> 01:49:45,855 >> AUDIÈNCIA: Ells van ser separats d'ell-- 2486 01:49:45,855 --> 01:49:49,140 >> RICK Houlihan: Amb el document enfocament, el tipus de document en DynamoDB 2487 01:49:49,140 --> 01:49:50,880 és només pensar en com un altre atribut. 2488 01:49:50,880 --> 01:49:53,560 És un atribut que conté una estructura de dades jeràrquica. 2489 01:49:53,560 --> 01:49:56,980 I després, a les consultes, pot utilitzar les propietats 2490 01:49:56,980 --> 01:49:59,480 d'aquests objectes utilitzant notació d'objectes. 2491 01:49:59,480 --> 01:50:03,562 Així que pot filtrar en una imbricada propietat del document JSON. 2492 01:50:03,562 --> 01:50:05,520 AUDIÈNCIA: Així que cada vegada que fer un enfocament document, 2493 01:50:05,520 --> 01:50:07,906 Puc espècie d'arribar a la tabular-- 2494 01:50:07,906 --> 01:50:08,780 AUDIÈNCIA: Absolutament. 2495 01:50:08,780 --> 01:50:09,800 Audiència: --indexes i coses que acabem de parlar. 2496 01:50:09,800 --> 01:50:11,280 RICK Houlihan: Sí, la índexs i tot això, 2497 01:50:11,280 --> 01:50:13,363 quan es vol indexar el propietats de la JSON, 2498 01:50:13,363 --> 01:50:18,230 la forma en què ens agradaria haver de fer això és si insereix un objecte JSON o un document 2499 01:50:18,230 --> 01:50:20,780 en Dynamo, utilitzaria els rierols. 2500 01:50:20,780 --> 01:50:22,400 Streams llegirien l'entrada. 2501 01:50:22,400 --> 01:50:24,340 Vostè aconseguiria que JSON objecte i que anaves a dir OK, 2502 01:50:24,340 --> 01:50:26,030 ¿Quina és la propietat que vull índex? 2503 01:50:26,030 --> 01:50:28,717 >> Es crea una taula derivada. 2504 01:50:28,717 --> 01:50:30,300 Ara aquesta és la forma en què funciona ara. 2505 01:50:30,300 --> 01:50:32,650 Nosaltres no permetem a l'índex directament aquestes propietats. 2506 01:50:32,650 --> 01:50:33,520 >> AUDIÈNCIA: Tabularizing seus documents. 2507 01:50:33,520 --> 01:50:36,230 >> RICK Houlihan: Exactament, aplanant que, tabularizing, exactament. 2508 01:50:36,230 --> 01:50:37,415 Això és el que fas amb ell. 2509 01:50:37,415 --> 01:50:37,860 >> AUDIÈNCIA: Gràcies. 2510 01:50:37,860 --> 01:50:39,609 >> RICK Houlihan: Sí, absolutament, gràcies. 2511 01:50:39,609 --> 01:50:42,240 AUDIÈNCIA: Així que és una espècie de Mongo compleix classifers Redis. 2512 01:50:42,240 --> 01:50:43,990 >> RICK Houlihan: Sí, que és molt semblant a això. 2513 01:50:43,990 --> 01:50:45,940 Aquesta és una bona descripció de la mateixa. 2514 01:50:45,940 --> 01:50:47,490 Fresc. 2515 01:50:47,490 --> 01:50:49,102