1 00:00:00,000 --> 00:00:04,969 >> [Prehrávanie hudby] 2 00:00:04,969 --> 00:00:06,010 RICK Houlihan: Dobre. 3 00:00:06,010 --> 00:00:06,600 Ahojte všetci. 4 00:00:06,600 --> 00:00:07,670 Volám sa Rick Houlihan. 5 00:00:07,670 --> 00:00:10,330 Som senior riaditeľ Riešenie architekt spoločnosti AWS. 6 00:00:10,330 --> 00:00:14,070 Zameriavam sa na NoSQL a Technológie DynamoDB. 7 00:00:14,070 --> 00:00:16,930 Som tu dnes hovoriť ste trochu o nich. 8 00:00:16,930 --> 00:00:18,970 >> Moje pozadie je predovšetkým v dátovej vrstvy. 9 00:00:18,970 --> 00:00:21,390 Strávil som polku rozvoj kariéra písanie databázu, 10 00:00:21,390 --> 00:00:25,930 prístup k dátam, riešenie pre rôzne aplikácie. 11 00:00:25,930 --> 00:00:30,000 Bol som v oblasti virtualizácie Cloud asi 20 rokov. 12 00:00:30,000 --> 00:00:33,460 Takže pred tým, než Cloud Cloud, sme boli zvyknutí hovoriť utility computing. 13 00:00:33,460 --> 00:00:37,170 A nápad bol, je to ako PG & E, budete platiť za to, čo používate. 14 00:00:37,170 --> 00:00:38,800 Dnes ju nazývame mrak. 15 00:00:38,800 --> 00:00:41,239 >> Ale v priebehu rokov som pracoval pre pár firiem 16 00:00:41,239 --> 00:00:42,530 ste pravdepodobne nikdy nepočuli. 17 00:00:42,530 --> 00:00:47,470 Ale ja som zostavil zoznam technických úspechy, myslím, že by som. 18 00:00:47,470 --> 00:00:51,620 Mám osem patentov v Cloud systémy virtualizácie, mikroprocesor dizajn, 19 00:00:51,620 --> 00:00:54,440 komplexné spracovanie udalostí, a iných oblastiach. 20 00:00:54,440 --> 00:00:58,290 >> Takže v týchto dňoch, som sa zameriavajú predovšetkým na NoSQL technológie a budúcej generácie 21 00:00:58,290 --> 00:00:59,450 databáz. 22 00:00:59,450 --> 00:01:03,370 A to je to všeobecne, čo budem tu byť s tebou hovoriť dnes o. 23 00:01:03,370 --> 00:01:06,030 Takže to, čo môžete očakávať z tohto zasadnutia, 24 00:01:06,030 --> 00:01:08,254 pôjdeme cez krátke História spracovania dát. 25 00:01:08,254 --> 00:01:10,420 Je vždy užitočné pochopiť, odkiaľ sme prišli 26 00:01:10,420 --> 00:01:12,400 a dôvod, prečo sme tam, kde sme. 27 00:01:12,400 --> 00:01:15,600 A budeme hovoriť trochu bit o technológii NoSQL 28 00:01:15,600 --> 00:01:17,500 od základnej hľadiska. 29 00:01:17,500 --> 00:01:19,870 >> Dostaneme sa do niektorej z vnútorné vybavenie DynamoDB. 30 00:01:19,870 --> 00:01:24,350 DynamoDB je AWS to nie je chuť. 31 00:01:24,350 --> 00:01:27,340 Je plne organizovaná a Hostované riešenie NoSQL. 32 00:01:27,340 --> 00:01:32,420 A budeme hovoriť trochu o stôl štruktúra, API, dátové typy, indexy, 33 00:01:32,420 --> 00:01:35,177 a niektoré z niternost tohto DynamoDB technológie. 34 00:01:35,177 --> 00:01:37,760 Dostaneme sa do niektorej z dizajnu vzory a osvedčených postupov. 35 00:01:37,760 --> 00:01:39,968 Budeme hovoriť o tom, ako použitie tejto technológie pre niektoré 36 00:01:39,968 --> 00:01:41,430 dnešných aplikácií. 37 00:01:41,430 --> 00:01:44,820 A potom budeme hovoriť trochu o vývoji či vzniku 38 00:01:44,820 --> 00:01:48,980 novej paradigmy programovania tzv aplikácie udalosťami riadené 39 00:01:48,980 --> 00:01:51,580 a ako DynamoDB hrá v, že rovnako. 40 00:01:51,580 --> 00:01:54,690 A my vám necháme trochu referenčnej architektúry diskusie 41 00:01:54,690 --> 00:01:59,540 takže môžeme hovoriť o niektorých spôsoby, ako môžete použiť DynamoDB. 42 00:01:59,540 --> 00:02:04,116 >> Takže najprv off-- je to otázka Počul som, že veľa, je to, čo je databáza. 43 00:02:04,116 --> 00:02:06,240 Mnoho ľudí si myslí, že viete, čo je databáza. 44 00:02:06,240 --> 00:02:08,360 Ak ste Google, uvidíte to. 45 00:02:08,360 --> 00:02:11,675 Je to štruktúrovaný súbor údajov konalo v počítači, najmä ten, ktorý 46 00:02:11,675 --> 00:02:13,600 je k dispozícii vo rôznymi spôsobmi. 47 00:02:13,600 --> 00:02:16,992 Myslím, že je to dobrý Definícia modernej databázy. 48 00:02:16,992 --> 00:02:19,450 Ale nepáči sa mi to, pretože to znamená niekoľko vecí. 49 00:02:19,450 --> 00:02:20,935 To znamená štruktúru. 50 00:02:20,935 --> 00:02:23,120 A to znamená, že je to v počítači. 51 00:02:23,120 --> 00:02:25,750 A databázy nie vždy existovať na počítačoch. 52 00:02:25,750 --> 00:02:28,020 Databázy vlastne existoval v mnohých ohľadoch. 53 00:02:28,020 --> 00:02:32,000 >> Takže lepšie definície Databáza je niečo také. 54 00:02:32,000 --> 00:02:34,786 Databáza je organizovaná mechanizmus pre ukladanie, správu, 55 00:02:34,786 --> 00:02:35,910 a získavanie informácií. 56 00:02:35,910 --> 00:02:36,868 To je od About.com. 57 00:02:36,868 --> 00:02:42,080 Tak som to rád, pretože je to naozaj hovorí o databáze, že je úložisko, 58 00:02:42,080 --> 00:02:44,800 studnicou informácie, nie nevyhnutne 59 00:02:44,800 --> 00:02:46,780 niečo, čo sedí na počítači. 60 00:02:46,780 --> 00:02:49,290 A celej histórii, my nie vždy mali počítačov. 61 00:02:49,290 --> 00:02:52,110 >> A teraz, keď som sa opýtať priemer developer dnes to, čo je 62 00:02:52,110 --> 00:02:54,770 databázu, že je odpoveď som si. 63 00:02:54,770 --> 00:02:56,070 Niekde som si držať veci. 64 00:02:56,070 --> 00:02:56,670 Doprava? 65 00:02:56,670 --> 00:02:58,725 A je to pravda. 66 00:02:58,725 --> 00:02:59,600 Ale je to nešťastné. 67 00:02:59,600 --> 00:03:02,700 Vzhľadom k tomu, databázy je naozaj základom modernej aplikácie. 68 00:03:02,700 --> 00:03:04,810 To je základ z každej aplikácie. 69 00:03:04,810 --> 00:03:07,240 A ako si vybudovať, že databázy, ako štruktúrovať 70 00:03:07,240 --> 00:03:11,750 že dáta sa bude diktovať, ako, že Aplikácia vystupuje ako merítka. 71 00:03:11,750 --> 00:03:14,640 >> Takže mnoho mojej práce dnes sa zaoberá, čo 72 00:03:14,640 --> 00:03:17,180 sa stane, keď vývojári tento prístup 73 00:03:17,180 --> 00:03:19,510 a riešiť následky aplikácie, ktorá 74 00:03:19,510 --> 00:03:24,966 Teraz je škálovanie nad rámec pôvodnej zámer a utrpenie zo zlého návrhu. 75 00:03:24,966 --> 00:03:26,840 Takže dúfajme, že keď vás odísť dnes, budete 76 00:03:26,840 --> 00:03:29,010 majú niekoľko nástrojov v tvoj pás, ktorý ťa držať 77 00:03:29,010 --> 00:03:32,566 od robiť tie isté chyby. 78 00:03:32,566 --> 00:03:33,066 Dobre. 79 00:03:33,066 --> 00:03:36,360 Tak poďme hovoriť o trochou časová os databázových technológií. 80 00:03:36,360 --> 00:03:38,830 Myslím, že som čítal článok Nie je to tak dávno 81 00:03:38,830 --> 00:03:43,020 a povedal niečo na lines-- je to veľmi poetické vyhlásení. 82 00:03:43,020 --> 00:03:46,590 To povedal, že história dát spracovanie je 83 00:03:46,590 --> 00:03:49,350 plná vysokých vodoznakov hojnosti dát. 84 00:03:49,350 --> 00:03:49,920 OK. 85 00:03:49,920 --> 00:03:52,532 A teraz, myslím, že je celkom pravda. 86 00:03:52,532 --> 00:03:54,990 Ale ja som vlastne pozrieť, je, ako história bola skutočne naplnená 87 00:03:54,990 --> 00:03:56,820 s vysokým vodoznakom tlaku dát. 88 00:03:56,820 --> 00:04:00,040 Vzhľadom k tomu, rýchlosť prenosu dát z Požitie nikdy klesá. 89 00:04:00,040 --> 00:04:01,360 Je to len ide hore. 90 00:04:01,360 --> 00:04:03,670 >> A inovácie nastane, keď vidíme tlak dát, čo 91 00:04:03,670 --> 00:04:07,825 je množstvo dát, ktoré je teraz v prichádza do systému. 92 00:04:07,825 --> 00:04:12,027 A to nie je možné spracovať účinne buď v čase, alebo z hľadiska nákladov. 93 00:04:12,027 --> 00:04:14,110 A to je, keď začneme sa pozrieť na tlaku dát. 94 00:04:14,110 --> 00:04:15,920 >> Takže keď sme sa pozrieť na prvý databáz, toto 95 00:04:15,920 --> 00:04:17,180 je ten, ktorý bol medzi naše uši. 96 00:04:17,180 --> 00:04:18,310 Sme všetci s tým narodil. 97 00:04:18,310 --> 00:04:19,194 Je to pekná databázy. 98 00:04:19,194 --> 00:04:21,110 To má vysokú dostupnosť. 99 00:04:21,110 --> 00:04:21,959 Je to vždy. 100 00:04:21,959 --> 00:04:23,930 Vždy sa môžete dostať. 101 00:04:23,930 --> 00:04:24,890 >> Ale je to pre jedného používateľa. 102 00:04:24,890 --> 00:04:26,348 Nemožno zdieľať svoje myšlienky s vami. 103 00:04:26,348 --> 00:04:28,370 Nemôžete dostať svoje myšlienky keď ich chcete mať. 104 00:04:28,370 --> 00:04:30,320 A ich abilitie nie je tak dobrá. 105 00:04:30,320 --> 00:04:32,510 Zabúdame veci. 106 00:04:32,510 --> 00:04:36,540 Tu a tam, jeden z nás listy a presunie na iný existenciu 107 00:04:36,540 --> 00:04:39,110 a stratíme všetko ktorá bola v tejto databáze. 108 00:04:39,110 --> 00:04:40,640 Takže to nie je tak dobré. 109 00:04:40,640 --> 00:04:43,189 >> A to fungovalo dobre v priebehu času keď sme boli späť v deň 110 00:04:43,189 --> 00:04:46,230 keď všetko, čo sme naozaj potrebovali vedieť, je, kde budeme pokračovať zajtra 111 00:04:46,230 --> 00:04:49,630 alebo tam, kde sme sa zhromaždiť najlepšie jedlo. 112 00:04:49,630 --> 00:04:52,820 Ale keď sme začali pestovať ako civilizácie a vláda začala 113 00:04:52,820 --> 00:04:55,152 vstúpiť do bytia, a podniky začali vyvíjať, 114 00:04:55,152 --> 00:04:57,360 sme začali si uvedomíme, Potrebujeme trochu viac, než to, čo 115 00:04:57,360 --> 00:04:58,210 sme mohli dať do našej hlave. 116 00:04:58,210 --> 00:04:58,870 Dobre? 117 00:04:58,870 --> 00:05:00,410 >> Potrebovali sme systémy záznamu. 118 00:05:00,410 --> 00:05:02,220 Potrebovali sme miesta, aby ukladanie dát schopné. 119 00:05:02,220 --> 00:05:05,450 Tak sme začali písať dokumenty vytváranie knižníc a archívov. 120 00:05:05,450 --> 00:05:08,000 Začali sme vyvíjať Systém Ledger účtovníctva. 121 00:05:08,000 --> 00:05:12,200 A že systém počítania saldokontné bežal svet pre mnoho storočí, 122 00:05:12,200 --> 00:05:15,580 A možno aj tisícročia as sme trochu rástla k veci 123 00:05:15,580 --> 00:05:18,420 pokiaľ tento náklad údaje predčil schopnosť týchto systémov 124 00:05:18,420 --> 00:05:19,870 aby bolo možné ho obsahovať. 125 00:05:19,870 --> 00:05:22,070 >> A to sa skutočne stalo v 1880s. 126 00:05:22,070 --> 00:05:22,570 Doprava? 127 00:05:22,570 --> 00:05:24,390 V 1880 amerického sčítania ľudu. 128 00:05:24,390 --> 00:05:26,976 To je naozaj, kde sústruženie bod moderné spracovanie dát. 129 00:05:26,976 --> 00:05:28,850 To je bod, v čo je množstvo dát 130 00:05:28,850 --> 00:05:32,060 ktorý bol zhromaždené Vláda USA sa dostal do bodu, 131 00:05:32,060 --> 00:05:34,005 kde to trvalo osem rokov spracovať. 132 00:05:34,005 --> 00:05:36,350 >> Teraz, osem years-- as viete, sčítanie ľudu 133 00:05:36,350 --> 00:05:39,180 premáva každých 10 years--, takže je to celkom zrejmé, že keď sme 134 00:05:39,180 --> 00:05:41,419 dostal 1890 sčítanie ľudu, Množstvo dát, ktoré 135 00:05:41,419 --> 00:05:43,210 išiel byť spracované vládou bol 136 00:05:43,210 --> 00:05:46,335 bude prekračujú 10 rokov to tak by sa do začala nové sčítanie ľudu. 137 00:05:46,335 --> 00:05:47,250 To bol problém. 138 00:05:47,250 --> 00:05:49,000 >> Takže chlapík menom Herman Hollerith prišiel 139 00:05:49,000 --> 00:05:52,640 a on vynašiel prístroj nahrá punč karty, punč čítačka kariet, stĺpcové dierne štítky 140 00:05:52,640 --> 00:05:58,420 tabulátor, a kolace mechanizmy pre túto technológiu. 141 00:05:58,420 --> 00:06:01,860 A že spoločnosť, ktorá sa tvoril u čas, spolu s niekoľkými ďalšími, 142 00:06:01,860 --> 00:06:05,450 v skutočnosti sa stal jedným z piliermi malá firma poznáme dnes vyzvala IBM. 143 00:06:05,450 --> 00:06:08,417 >> Takže IBM pôvodne bol v obchodné databázy. 144 00:06:08,417 --> 00:06:09,750 A to je naozaj to, čo urobili. 145 00:06:09,750 --> 00:06:11,110 Urobili spracovanie dát. 146 00:06:11,110 --> 00:06:15,400 >> Ako tak šíreniu punč karty, geniálny mechanizmy 147 00:06:15,400 --> 00:06:18,560 že budú môcť využiť, že Technológie na hlasovanie roztriedené sady výsledkov. 148 00:06:18,560 --> 00:06:20,726 Môžete vidieť v tejto snímke K dispozícii máme little-- 149 00:06:20,726 --> 00:06:23,970 je to trochu small-- ale môžete vidieť veľmi dômyselný mechanický mechanizmus 150 00:06:23,970 --> 00:06:26,970 kde máme punč balíček kariet. 151 00:06:26,970 --> 00:06:28,720 A brať niečí trochu skrutkovač 152 00:06:28,720 --> 00:06:31,400 a lepenie prostredníctvom sloty a zdvihnutím nahor 153 00:06:31,400 --> 00:06:34,820 sa dostať, že zápas, ktorý zoradené výsledky set. 154 00:06:34,820 --> 00:06:36,270 >> Toto je agregácie. 155 00:06:36,270 --> 00:06:38,690 Robíme to po celú dobu dnes v počítači, 156 00:06:38,690 --> 00:06:40,100 kde to robíte v databáze. 157 00:06:40,100 --> 00:06:41,620 Použili sme to urobiť ručne, je to tak? 158 00:06:41,620 --> 00:06:42,994 Ľudia dať tieto veci dohromady. 159 00:06:42,994 --> 00:06:45,440 A bolo to šírenie týchto diernych štítkov 160 00:06:45,440 --> 00:06:50,070 do toho, čo sme nazvali dátových bubnov a dátové kotúče, papierové pásky. 161 00:06:50,070 --> 00:06:55,980 >> Spracovanie dát priemysel vzal poučenie z klavírov hráčov. 162 00:06:55,980 --> 00:06:57,855 Piana staré na prelome storočí 163 00:06:57,855 --> 00:07:02,100 používali papierové kotúče s drážkami na to povedať, ktoré kľúče hrať. 164 00:07:02,100 --> 00:07:05,380 Tak, že technológia bola upravená nakoniec pre ukladanie digitálnych dát, 165 00:07:05,380 --> 00:07:08,070 pretože oni mohli dať, že dáta na týchto papierovú pásku rolách. 166 00:07:08,070 --> 00:07:10,870 >> Teraz, ako výsledok, údaje bol actually-- ako 167 00:07:10,870 --> 00:07:14,960 máte prístup tieto dáta bola priamo v závislosti na tom, ako ste ich uložili. 168 00:07:14,960 --> 00:07:17,825 Takže keď som dal dáta na pásku, Mal som lineárne prístup k dátam. 169 00:07:17,825 --> 00:07:20,475 Musel som sa vrátiť celú Páska prístup ku všetkým dátam. 170 00:07:20,475 --> 00:07:22,600 Mám chcete vložiť dáta do punč karty, mohol som to prístup 171 00:07:22,600 --> 00:07:26,270 v trochu viac náhodný móda, možno nie tak rýchlo. 172 00:07:26,270 --> 00:07:30,770 >> Ale tam bolo obmedzenie v tom, ako prístup k dátam na základe toho, ako bol uložený. 173 00:07:30,770 --> 00:07:32,890 A tak to bol problém, ísť do 50. rokov. 174 00:07:32,890 --> 00:07:37,890 Opäť platí, že môžeme začať vidieť, že ako my vyvíjať nové technológie pre spracovanie 175 00:07:37,890 --> 00:07:41,670 dáta, vpravo, otvára dvere pre nové riešenia, 176 00:07:41,670 --> 00:07:45,852 pre nové programy, nové Žiadosti o týchto dát. 177 00:07:45,852 --> 00:07:47,810 A naozaj, správa vecí verejných mohol byť dôvodom 178 00:07:47,810 --> 00:07:49,435 Preto sme vyvinuli niektoré z týchto systémov. 179 00:07:49,435 --> 00:07:52,290 Ale firma sa rýchlo stal sa Vodič za evolúciu 180 00:07:52,290 --> 00:07:54,720 moderné databázy a moderný systém súborov. 181 00:07:54,720 --> 00:07:56,870 >> Takže ďalšia vec, ktorá sa prišiel bol v 50. rokoch 182 00:07:56,870 --> 00:08:00,780 bol systém súborov a Vývoj náhodného skladovania prístupu. 183 00:08:00,780 --> 00:08:02,050 To bola krásna. 184 00:08:02,050 --> 00:08:06,230 Teraz sú všetky náhle, môžeme dať naše súbory kdekoľvek na týchto pevných diskoch 185 00:08:06,230 --> 00:08:09,760 a môžeme prístup k týmto dátam náhodne. 186 00:08:09,760 --> 00:08:11,950 Môžeme analyzovať, že Informácie zo súborov. 187 00:08:11,950 --> 00:08:14,920 A sme vyriešili všetkých svetových problémy s spracovania dát. 188 00:08:14,920 --> 00:08:17,550 >> A to trvalo asi 20 alebo 30 rokov až do evolúcie 189 00:08:17,550 --> 00:08:22,100 relačné databázy, ktorá je, keď sa svet rozhodli sme sa teraz 190 00:08:22,100 --> 00:08:27,940 musí mať úložisko, ktoré prekazí rozlieha dát naprieč súboru 191 00:08:27,940 --> 00:08:29,540 systémy, ktoré sme vytvorili. Doprava? 192 00:08:29,540 --> 00:08:34,270 Príliš veľa dát distribuovaných v príliš veľa miesta, de-duplikácia dát, 193 00:08:34,270 --> 00:08:37,120 a náklady na skladovanie bol obrovský. 194 00:08:37,120 --> 00:08:43,760 >> V 70. rokoch, najdrahšie zdroj že počítač mal bol skladovanie. 195 00:08:43,760 --> 00:08:46,200 Procesor bol vnímaná ako fixné náklady. 196 00:08:46,200 --> 00:08:49,030 Keď som sa kúpiť box, CPU robí nejakú prácu. 197 00:08:49,030 --> 00:08:51,960 Bude to byť pradenia, či je to vlastne pracuje, alebo nie. 198 00:08:51,960 --> 00:08:53,350 To je naozaj fixných nákladov. 199 00:08:53,350 --> 00:08:56,030 >> Ale to, čo ma stálo ako podnikania je skladovanie. 200 00:08:56,030 --> 00:09:00,020 Mám-li kúpiť viac diskov ďalšie mesiac, to je skutočné náklady, ktoré som zaplatiť. 201 00:09:00,020 --> 00:09:01,620 A že skladovanie je drahé. 202 00:09:01,620 --> 00:09:05,020 >> Teraz sme rýchlo dopredu 40 rokov a máme iný problém. 203 00:09:05,020 --> 00:09:10,020 Compute je teraz najdrahšie zdroj. 204 00:09:10,020 --> 00:09:11,470 Úložisko je lacné. 205 00:09:11,470 --> 00:09:14,570 Myslím, že sme môže ísť kamkoľvek na cloud a môžeme nájsť lacné skladovanie. 206 00:09:14,570 --> 00:09:17,190 Ale to, čo nemôžem nájsť je lacná výpočtovej. 207 00:09:17,190 --> 00:09:20,700 >> Takže evolúcie dnešnej Technológie, databázové technológie, 208 00:09:20,700 --> 00:09:23,050 je naozaj zamerané na distribuovanej databázy 209 00:09:23,050 --> 00:09:26,960 že netrpia rovnaký typ stupnice 210 00:09:26,960 --> 00:09:29,240 obmedzenia relačných databáz. 211 00:09:29,240 --> 00:09:32,080 Budeme hovoriť trochu o čo to vlastne znamená. 212 00:09:32,080 --> 00:09:34,760 >> Ale jeden z dôvodov, prečo a Vodič za tohle-- my 213 00:09:34,760 --> 00:09:38,290 hovoril o tlaku dát. 214 00:09:38,290 --> 00:09:41,920 Tlak dát je niečo, že podporuje inováciu. 215 00:09:41,920 --> 00:09:44,610 A keď sa pozriete na viac ako posledných päť rokov, 216 00:09:44,610 --> 00:09:48,180 toto je tabuľka na čo sa údaje zaťaženie v rámci všeobecného podniku 217 00:09:48,180 --> 00:09:49,640 vyzerá v posledných piatich rokoch. 218 00:09:49,640 --> 00:09:52,570 >> A všeobecné pravidlo Tieto days-- ak idete Google-- 219 00:09:52,570 --> 00:09:55,290 90% z údajov, ktoré ukladáme dnes, a to bolo 220 00:09:55,290 --> 00:09:57,330 vytvorených v posledných dvoch rokoch. 221 00:09:57,330 --> 00:09:57,911 OK. 222 00:09:57,911 --> 00:09:59,410 Teraz, sa nejedná o trend, ktorý je nový. 223 00:09:59,410 --> 00:10:01,230 To je trend, ktorý bol chodiť na 100 rokov. 224 00:10:01,230 --> 00:10:03,438 Od tej doby, Herman Hollerith vyvinul stĺpcové dierne štítky, 225 00:10:03,438 --> 00:10:08,040 sme boli budovanie dátových úložísk a zber údajov na fenomenálne sadzby. 226 00:10:08,040 --> 00:10:10,570 >> Takže v priebehu posledných 100 rokov, sme videli tento trend. 227 00:10:10,570 --> 00:10:11,940 To nebude meniť. 228 00:10:11,940 --> 00:10:14,789 Do budúcnosti budeme vidieť to, ak nie zrýchlené trend. 229 00:10:14,789 --> 00:10:16,330 A môžete vidieť, ako to vyzerá. 230 00:10:16,330 --> 00:10:23,510 >> Ak sa firma v roku 2010 mal jeden terabyte dát v rámci konania, 231 00:10:23,510 --> 00:10:27,080 Dnes to znamená, že sú spravovanie 6,5 petabajtov dát. 232 00:10:27,080 --> 00:10:30,380 To je 6500 krát viac dát. 233 00:10:30,380 --> 00:10:31,200 A viem, že toto. 234 00:10:31,200 --> 00:10:33,292 Každý deň som sa pracovať s týmito podnikmi. 235 00:10:33,292 --> 00:10:35,000 Pred piatimi rokmi som by sa hovoriť na spoločnosti 236 00:10:35,000 --> 00:10:38,260 kto by so mnou hovoriť o tom, čo bolesti to je riadiť terabajtov dát. 237 00:10:38,260 --> 00:10:39,700 A oni by sa hovoriť so mnou o tom, ako vidíme 238 00:10:39,700 --> 00:10:41,825 že je to pravdepodobne bude byť petabyte alebo dva 239 00:10:41,825 --> 00:10:43,030 v priebehu niekoľkých rokov. 240 00:10:43,030 --> 00:10:45,170 >> Tieto rovnaké spoločnosti Dnes mám schôdzku s, 241 00:10:45,170 --> 00:10:48,100 a oni so mnou hovoriť o Problémom sú tu majú riadiace 242 00:10:48,100 --> 00:10:51,440 desiatky, 20 petabajtov dát. 243 00:10:51,440 --> 00:10:53,590 Takže Explózia Dáta v priemysle 244 00:10:53,590 --> 00:10:56,670 poháňa obrovský Potrebujete pre lepšie riešenie. 245 00:10:56,670 --> 00:11:00,980 A relačnej databázy je proste žiť až do dopytu. 246 00:11:00,980 --> 00:11:03,490 >> A tak je tu lineárny korelácia medzi tlakom dát 247 00:11:03,490 --> 00:11:05,210 a technické inovácie. 248 00:11:05,210 --> 00:11:07,780 História nám ukázala, to, že v priebehu doby, 249 00:11:07,780 --> 00:11:11,090 vždy, keď sa objem dát ktoré musia byť spracované 250 00:11:11,090 --> 00:11:15,490 presahuje kapacitu systému spracovať ju v rozumnom čase 251 00:11:15,490 --> 00:11:18,870 alebo za rozumnú cenu, potom nové technológie 252 00:11:18,870 --> 00:11:21,080 sú vynájdené na riešenie týchto problémov. 253 00:11:21,080 --> 00:11:24,090 Tieto nové technológie, naopak, otvorte dvierka 254 00:11:24,090 --> 00:11:27,840 na inú sadu problémov, ktoré zbiera aj ďalšie dáta. 255 00:11:27,840 --> 00:11:29,520 >> Teraz, nebudeme to zastaviť. 256 00:11:29,520 --> 00:11:30,020 Doprava? 257 00:11:30,020 --> 00:11:31,228 Nebudeme to zastaviť. 258 00:11:31,228 --> 00:11:31,830 Prečo? 259 00:11:31,830 --> 00:11:35,520 Vzhľadom k tomu, nemôžete vedieť všetko tam je poznať vo vesmíre. 260 00:11:35,520 --> 00:11:40,510 A tak dlho, ako sme boli nažive, v celej histórii človeka, 261 00:11:40,510 --> 00:11:43,440 sme vždy riadený vedieť viac. 262 00:11:43,440 --> 00:11:49,840 >> Takže to vyzerá, že každý palec sa pohybujeme po ceste vedeckého objavu, 263 00:11:49,840 --> 00:11:54,620 sme sa množia množstvo dát že musíme spracovať exponenciálne 264 00:11:54,620 --> 00:11:59,920 ako odhaliť viac a viac a viac o vnútornom fungovaní života, 265 00:11:59,920 --> 00:12:04,530 o tom, ako vesmír funguje, o riadil vedecký objav, 266 00:12:04,530 --> 00:12:06,440 a vynález, ktorý robíme dnes. 267 00:12:06,440 --> 00:12:09,570 Objem dát len neustále zvyšuje. 268 00:12:09,570 --> 00:12:12,120 Takže je schopný vysporiadať sa s Tento problém je obrovský. 269 00:12:12,120 --> 00:12:14,790 270 00:12:14,790 --> 00:12:17,410 >> Takže jedna z vecí sa pozrieme, ako, prečo NoSQL? 271 00:12:17,410 --> 00:12:19,200 Ako NoSQL tento problém vyriešiť? 272 00:12:19,200 --> 00:12:24,980 No, relačné databázy, Structured Query Language, 273 00:12:24,980 --> 00:12:28,600 SQL--, že je naozaj konštrukt relačné database-- tieto veci sú 274 00:12:28,600 --> 00:12:30,770 optimalizovaný pre skladovanie. 275 00:12:30,770 --> 00:12:33,180 >> Späť v 70. rokoch, sa znova, disk je drahé. 276 00:12:33,180 --> 00:12:36,990 Dotačné Výkon skladovanie V podniku je nikdy nekončiaci. 277 00:12:36,990 --> 00:12:37,490 Viem. 278 00:12:37,490 --> 00:12:38,020 Žil som to. 279 00:12:38,020 --> 00:12:41,250 Napísal som ovládače úložisko pre enterprised SuperServer firmy 280 00:12:41,250 --> 00:12:42,470 späť v 90. rokoch. 281 00:12:42,470 --> 00:12:45,920 A faktom je stáčanie ďalší diskové pole bolo len niečo, 282 00:12:45,920 --> 00:12:47,600 každý deň v podniku stalo. 283 00:12:47,600 --> 00:12:49,030 A to nikdy neprestalo. 284 00:12:49,030 --> 00:12:52,690 Vyššia hustota skladovanie, dopyt pre vysokou hustotou skladovanie, 285 00:12:52,690 --> 00:12:56,340 a pre efektívnejšie ukladanie devices-- to nikdy neprestalo. 286 00:12:56,340 --> 00:13:00,160 >> A NoSQL je špičkovou technológiou preto, že normalizuje dáta. 287 00:13:00,160 --> 00:13:02,210 Je to de-kopíruje dáta. 288 00:13:02,210 --> 00:13:07,180 Kladie dáta v štruktúre, ktorá je agnostik na každú vzorku prístup. 289 00:13:07,180 --> 00:13:11,600 Viac aplikácií, ktoré môže zasiahnuť SQL databázy, spúšťať dotazy ad hoc, 290 00:13:11,600 --> 00:13:15,950 a získať dáta v tvare, ktorý sa je potrebné spracovať pre svoje pracovné záťaže. 291 00:13:15,950 --> 00:13:17,570 To znie fantasticky. 292 00:13:17,570 --> 00:13:21,350 Ale faktom je, s akýmkoľvek systém, ak je to agnostik ku všetkému, 293 00:13:21,350 --> 00:13:23,500 je optimalizovaný pre nič za nič. 294 00:13:23,500 --> 00:13:24,050 OK? 295 00:13:24,050 --> 00:13:26,386 >> A to je to, čo sme si s relačnej databázy. 296 00:13:26,386 --> 00:13:27,510 Je optimalizovaný pre skladovanie. 297 00:13:27,510 --> 00:13:28,280 To je normalizovaná. 298 00:13:28,280 --> 00:13:29,370 Je to relačná. 299 00:13:29,370 --> 00:13:31,660 Podporuje otázky ad hoc. 300 00:13:31,660 --> 00:13:34,000 A to je a to váhy zvisle. 301 00:13:34,000 --> 00:13:39,030 >> Ak je potreba získať väčší SQL databáze alebo silnejšie SQL databázy, 302 00:13:39,030 --> 00:13:41,090 Idem si kúpiť väčší kus železa. 303 00:13:41,090 --> 00:13:41,600 OK? 304 00:13:41,600 --> 00:13:44,940 Pracoval som s mnohými zákazníkov ktoré boli prostredníctvom významnej modernizácie 305 00:13:44,940 --> 00:13:48,340 iba v ich SQL infraštruktúry zistiť, o šesť mesiacov neskôr, 306 00:13:48,340 --> 00:13:49,750 oni biť do steny znovu. 307 00:13:49,750 --> 00:13:55,457 A odpoveď z Oracle alebo MSSQL alebo niekto iný, je dostať väčší krabici. 308 00:13:55,457 --> 00:13:58,540 Tak skôr alebo neskôr, nemôžete kúpiť väčšie box, a to je skutočný problém. 309 00:13:58,540 --> 00:14:00,080 Musíme skutočne niečo zmeniť. 310 00:14:00,080 --> 00:14:01,080 Takže tam, kde to funguje? 311 00:14:01,080 --> 00:14:06,560 Funguje to dobre pre offline analytika, OLAP typu zaťaženia. 312 00:14:06,560 --> 00:14:08,670 A to je naozaj, kde SQL patrí. 313 00:14:08,670 --> 00:14:12,540 Teraz, to je dnes používaný v mnohých online transakčné spracovanie typu 314 00:14:12,540 --> 00:14:13,330 aplikácie. 315 00:14:13,330 --> 00:14:16,460 A funguje to v pohode na určitá úroveň využitia, 316 00:14:16,460 --> 00:14:18,670 ale to jednoducho nie je meradlo tak, že NoSQL robí. 317 00:14:18,670 --> 00:14:20,660 A budeme hovoriť trochu bit o tom, prečo to je. 318 00:14:20,660 --> 00:14:23,590 >> Teraz, NoSQL, na druhej strane, je viac optimalizovaný pre výpočtovo. 319 00:14:23,590 --> 00:14:24,540 OK? 320 00:14:24,540 --> 00:14:26,830 Nie je k agnostik prístup vzor. 321 00:14:26,830 --> 00:14:31,620 Je to, čo nazývame de-normalizoval štruktúra alebo hierarchická štruktúra. 322 00:14:31,620 --> 00:14:35,000 Dáta v relačnej databáze spojené dohromady z viacerých tabuliek 323 00:14:35,000 --> 00:14:36,850 produkovať názor, že potrebujete. 324 00:14:36,850 --> 00:14:40,090 Dáta v databáze NoSQL je uložený v dokumente, ktorý 325 00:14:40,090 --> 00:14:42,100 obsahuje hierarchickú štruktúru. 326 00:14:42,100 --> 00:14:45,670 Všetky dáta, ktoré by normálne spojili produkovať tento názor 327 00:14:45,670 --> 00:14:47,160 je uložený v jedinom dokumente. 328 00:14:47,160 --> 00:14:50,990 A budeme hovoriť trochu o ako to funguje v niekoľkých grafov. 329 00:14:50,990 --> 00:14:55,320 >> Ale myšlienka je, že budete ukladať Vaše dáta sú tieto konkretizované výhľadom. 330 00:14:55,320 --> 00:14:56,410 OK? 331 00:14:56,410 --> 00:14:58,610 Tie vodorovne škálovať. 332 00:14:58,610 --> 00:14:59,556 Doprava? 333 00:14:59,556 --> 00:15:02,100 Ak je potreba zvýšiť veľkosť môjho klastra NoSQL, 334 00:15:02,100 --> 00:15:03,700 Nepotrebujem, aby si väčšiu krabicu. 335 00:15:03,700 --> 00:15:05,200 Mám ďalšie krabicu. 336 00:15:05,200 --> 00:15:07,700 A ja klastra ty dohromady, a ja si črep, že dáta. 337 00:15:07,700 --> 00:15:10,780 Porozprávame sa niečo o čo sharding je, že 338 00:15:10,780 --> 00:15:14,270 schopné škálovať tejto databázy cez viac fyzických zariadení 339 00:15:14,270 --> 00:15:18,370 a odstrániť bariéru, ktorá vyžaduje, aby som meradle zvisle. 340 00:15:18,370 --> 00:15:22,080 >> Takže je to naozaj postavené pre on-line spracovanie transakcií a meradlo. 341 00:15:22,080 --> 00:15:25,480 Je tu veľký rozdiel tu medzi hlásenie, že jo? 342 00:15:25,480 --> 00:15:27,810 Reporting, ja nepoznáte Otázky Idem sa opýtať. 343 00:15:27,810 --> 00:15:28,310 Doprava? 344 00:15:28,310 --> 00:15:30,570 Reporting-- ak niekto z môj marketingové oddelenie 345 00:15:30,570 --> 00:15:34,520 chce jen--, koľko z mojich zákazníkov mať túto zvláštnu vlastnosť, ktorá 346 00:15:34,520 --> 00:15:37,850 kúpil na tejto day-- neviem čo dotaz idú opýtať. 347 00:15:37,850 --> 00:15:39,160 Tak som treba byť agnostik. 348 00:15:39,160 --> 00:15:41,810 >> Teraz, v on-line transakčné aplikácie, 349 00:15:41,810 --> 00:15:43,820 Viem, aké otázky sa pýtam. 350 00:15:43,820 --> 00:15:46,581 Postavil som žiadosť o veľmi špecifický workflow. 351 00:15:46,581 --> 00:15:47,080 OK? 352 00:15:47,080 --> 00:15:50,540 Takže keď som optimalizovať údaje ukladať na podporu tohto pracovného postupu, 353 00:15:50,540 --> 00:15:52,020 že to bude rýchlejšie. 354 00:15:52,020 --> 00:15:55,190 A to je dôvod, prečo môže NoSQL Naozaj urýchliť dodávku 355 00:15:55,190 --> 00:15:57,710 z týchto typov služieb. 356 00:15:57,710 --> 00:15:58,210 Dobre. 357 00:15:58,210 --> 00:16:00,501 >> Takže sme sa dostať do trochu teórie tu. 358 00:16:00,501 --> 00:16:03,330 A niektorí z vás, vaše oči môže vrátiť späť trochu. 359 00:16:03,330 --> 00:16:06,936 Ale budem sa snažiť, aby to ako vysokej úrovni ako ja. 360 00:16:06,936 --> 00:16:08,880 Takže ak ste v projekte management, je tu 361 00:16:08,880 --> 00:16:12,280 konštrukt nazvaný trojuholník obmedzenia. 362 00:16:12,280 --> 00:16:12,936 OK. 363 00:16:12,936 --> 00:16:16,060 Trojuholník obmedzuje diktátu nemôžete mať všetko čas. 364 00:16:16,060 --> 00:16:17,750 Nemôžete mať svoj koláč a jesť to príliš. 365 00:16:17,750 --> 00:16:22,310 Takže v oblasti projektového riadenia, že trojuholník obmedzenie ich môžete mať lacné, 366 00:16:22,310 --> 00:16:24,710 môžete mať to rýchlo, alebo môžete mať to dobré. 367 00:16:24,710 --> 00:16:25,716 Vyberte si dva. 368 00:16:25,716 --> 00:16:27,090 Vzhľadom k tomu, nemôžete mať všetky tri. 369 00:16:27,090 --> 00:16:27,460 Doprava? 370 00:16:27,460 --> 00:16:27,820 OK. 371 00:16:27,820 --> 00:16:28,920 >> Takže ste počul o tom veľa. 372 00:16:28,920 --> 00:16:31,253 Je to trojitý obmedzenia, trojuholník trojité obmedzenia, 373 00:16:31,253 --> 00:16:34,420 alebo železo trojuholník je oftentimes-- Keď hovoríte s projektovým manažérom, 374 00:16:34,420 --> 00:16:35,420 oni Porozprávame sa o tom. 375 00:16:35,420 --> 00:16:37,640 Teraz, databázy majú ich vlastné železo trojuholník. 376 00:16:37,640 --> 00:16:40,350 A železo trojuholník údajov je to, čo nazývame veta CAP. 377 00:16:40,350 --> 00:16:41,580 OK? 378 00:16:41,580 --> 00:16:43,770 >> CAP teorém diktuje ako fungujú databázy 379 00:16:43,770 --> 00:16:45,627 za veľmi špecifických podmienok. 380 00:16:45,627 --> 00:16:47,460 A budeme hovoriť o tom, čo je táto podmienka. 381 00:16:47,460 --> 00:16:52,221 Ale tri body trojuholníka, tak povediac, sú C, konzistencia. 382 00:16:52,221 --> 00:16:52,720 OK? 383 00:16:52,720 --> 00:16:56,760 Takže v CAP, konzistencie znamená, že všetky Klienti, ktorí majú prístup k databáze 384 00:16:56,760 --> 00:16:59,084 bude mať vždy veľmi konzistentné pohľad na dáta. 385 00:16:59,084 --> 00:17:00,750 Nikto sa bude vidieť dve rôzne veci. 386 00:17:00,750 --> 00:17:01,480 OK? 387 00:17:01,480 --> 00:17:04,020 Keď vidím databázu, Vidím rovnaký pohľad 388 00:17:04,020 --> 00:17:06,130 ako môj partner, ktorý vidí rovnakej databázy. 389 00:17:06,130 --> 00:17:07,470 To je konzistencia. 390 00:17:07,470 --> 00:17:12,099 >> Dostupnosť znamená, že v prípade, že databázy on-line, v prípade, že môže byť dosiahnutý, 391 00:17:12,099 --> 00:17:14,760 že všetci klienti budú vždy byť schopný čítať a písať. 392 00:17:14,760 --> 00:17:15,260 OK? 393 00:17:15,260 --> 00:17:17,010 Takže každý klient, ktorý môžete prečítať databázy 394 00:17:17,010 --> 00:17:18,955 budú vždy schopní čítanie Údaje údaje a písať. 395 00:17:18,955 --> 00:17:21,819 A ak je to tak, je to k dispozícii systém. 396 00:17:21,819 --> 00:17:24,230 >> A tretí bod je to, čo nazývame tolerancia oddielu. 397 00:17:24,230 --> 00:17:24,730 OK? 398 00:17:24,730 --> 00:17:28,160 Tolerancia Partition prostriedky že systém funguje dobre 399 00:17:28,160 --> 00:17:32,000 aj cez fyzické siete priečky medzi uzlami. 400 00:17:32,000 --> 00:17:32,760 OK? 401 00:17:32,760 --> 00:17:36,270 Takže uzly v klastri nemôže hovoriť k sebe navzájom, čo sa stane? 402 00:17:36,270 --> 00:17:36,880 Dobre. 403 00:17:36,880 --> 00:17:39,545 >> Takže relačnej databázy vyberte-- si môžete vybrať dva z nich. 404 00:17:39,545 --> 00:17:40,045 OK. 405 00:17:40,045 --> 00:17:43,680 Takže relačnej databázy vyberte byť konzistentné a sú k dispozícii. 406 00:17:43,680 --> 00:17:47,510 Ak oddiel sa deje medzi že DataNodes v úložisku dát, 407 00:17:47,510 --> 00:17:48,831 databázy havaruje. 408 00:17:48,831 --> 00:17:49,330 Doprava? 409 00:17:49,330 --> 00:17:50,900 Je to len ide dole. 410 00:17:50,900 --> 00:17:51,450 OK. 411 00:17:51,450 --> 00:17:54,230 >> A to je dôvod, prečo majú rast s väčšími boxy. 412 00:17:54,230 --> 00:17:54,730 Doprava? 413 00:17:54,730 --> 00:17:58,021 Pretože tam je no-- obvykle, cluster Databázy, že to nie je moc veľa z nich 414 00:17:58,021 --> 00:17:59,590 že fungujú týmto spôsobom. 415 00:17:59,590 --> 00:18:03,019 Ale väčšina databáz mierka vo zvislom smere v rámci jediného poľa. 416 00:18:03,019 --> 00:18:05,060 Vzhľadom k tomu, že musí byť konzistentné a sú k dispozícii. 417 00:18:05,060 --> 00:18:10,320 Ak oddiel mal byť aplikovaný, potom budete musieť urobiť voľbu. 418 00:18:10,320 --> 00:18:13,720 Musíte si vybrať medzi je v súlade a sú k dispozícii. 419 00:18:13,720 --> 00:18:16,080 >> A to je to, čo databázy NoSQL robiť. 420 00:18:16,080 --> 00:18:16,580 Dobre. 421 00:18:16,580 --> 00:18:20,950 Takže databázy NoSQL to, prichádza v dvoch príchutiach. 422 00:18:20,950 --> 00:18:22,990 My have-- dobre, to prichádza v mnohých príchutiach, 423 00:18:22,990 --> 00:18:26,140 ale prichádza s dvoma základnými characteristics-- čo 424 00:18:26,140 --> 00:18:30,050 by sme nazvali CP databázy, alebo konzistentné a oddiel tolerancie 425 00:18:30,050 --> 00:18:31,040 systém. 426 00:18:31,040 --> 00:18:34,930 Títo chlapi či sa rozhodne, že keď uzly strate kontaktu spolu navzájom, 427 00:18:34,930 --> 00:18:37,091 nebudeme dovoliť ľudia písať viac. 428 00:18:37,091 --> 00:18:37,590 OK? 429 00:18:37,590 --> 00:18:41,855 >> Do tej doby bude oddiel odstránený, Prístup pre zápis je blokovaný. 430 00:18:41,855 --> 00:18:43,230 To znamená, že to nie je k dispozícii. 431 00:18:43,230 --> 00:18:44,510 Sú konzistentné. 432 00:18:44,510 --> 00:18:46,554 Keď vidíme, že partition injekciu sám, 433 00:18:46,554 --> 00:18:48,470 sme teraz konzistentné, pretože my nejdeme 434 00:18:48,470 --> 00:18:51,517 aby zmenu dát na dva strany prepážky samostatne 435 00:18:51,517 --> 00:18:52,100 na sebe. 436 00:18:52,100 --> 00:18:54,130 Budeme sa musieť obnoviť komunikáciu 437 00:18:54,130 --> 00:18:56,930 pred akýmkoľvek aktualizáciu dáta je povolené. 438 00:18:56,930 --> 00:18:58,120 OK? 439 00:18:58,120 --> 00:19:02,650 >> Ďalšie variant by bol systém AP, alebo k dispozícii a rozdelí 440 00:19:02,650 --> 00:19:03,640 tolerancia systém. 441 00:19:03,640 --> 00:19:05,320 Títo chlapci to jedno. 442 00:19:05,320 --> 00:19:06,020 Doprava? 443 00:19:06,020 --> 00:19:08,960 Akýkoľvek uzol, ktorý dostane písať, budeme si to. 444 00:19:08,960 --> 00:19:11,480 Takže som svoju replikáciu dát cez viac uzlov. 445 00:19:11,480 --> 00:19:14,730 Tieto uzly sa klient, klient príde V hovorí, budem zapisovať niektoré údaje. 446 00:19:14,730 --> 00:19:16,300 Node hovorí, žiadny problém. 447 00:19:16,300 --> 00:19:18,580 Uzol Vedľa neho dostane Zápis na rovnakom zázname, 448 00:19:18,580 --> 00:19:20,405 že to bude hovoriť žiadny problém. 449 00:19:20,405 --> 00:19:23,030 Niekde späť na konci zadnej, že dáta to bude replikovať. 450 00:19:23,030 --> 00:19:27,360 A potom niekto to bude realizovať, uh-oh, ale systém bude realizovať, uh-oh, 451 00:19:27,360 --> 00:19:28,870 Stala sa aktualizácie dvoch strán. 452 00:19:28,870 --> 00:19:30,370 Čo budeme robiť? 453 00:19:30,370 --> 00:19:33,210 A to, čo robia, je potom robia niečo, čo 454 00:19:33,210 --> 00:19:36,080 im umožňuje riešiť tento stav dát. 455 00:19:36,080 --> 00:19:39,000 A budeme hovoriť o tom, že v nasledujúcom grafe. 456 00:19:39,000 --> 00:19:40,000 >> Thing poukázať tu. 457 00:19:40,000 --> 00:19:42,374 A ja nebudem mať moc omnoho do toho, pretože to 458 00:19:42,374 --> 00:19:43,510 dostane do hlbokej teórie dát. 459 00:19:43,510 --> 00:19:46,670 Ale je tu transakčné rámec, ktorý 460 00:19:46,670 --> 00:19:50,680 prebieha v relačnej systému, ktorý mi umožňuje bezpečne vykonávať aktualizácie 461 00:19:50,680 --> 00:19:53,760 na viac subjektov v databáze. 462 00:19:53,760 --> 00:19:58,320 A tieto aktualizácie budú vyskytovať naraz, alebo vôbec nie. 463 00:19:58,320 --> 00:20:00,500 A to sa nazýva ACID transakcie. 464 00:20:00,500 --> 00:20:01,000 OK? 465 00:20:01,000 --> 00:20:06,570 >> ACID nám dáva Atomicita, konzistencia, izolácia, a trvanlivosť. 466 00:20:06,570 --> 00:20:07,070 OK? 467 00:20:07,070 --> 00:20:13,550 To znamená, že atómové, transakcie, všetko moje aktualizácie buď stáť, alebo nie. 468 00:20:13,550 --> 00:20:16,570 Konzistencie znamená, že Databáza bude vždy 469 00:20:16,570 --> 00:20:19,780 byť uvedená do konzistentné stav po aktualizácii. 470 00:20:19,780 --> 00:20:23,900 Ja sa nikdy opustiť databázy v po použití aktualizácie zlý stav. 471 00:20:23,900 --> 00:20:24,400 OK? 472 00:20:24,400 --> 00:20:26,720 >> Takže je to trochu inak než konzistencia CAP. 473 00:20:26,720 --> 00:20:29,760 Konzistencia CAP znamená, že všetky moje klienti môžu vždy zobraziť údaje. 474 00:20:29,760 --> 00:20:34,450 ACID konzistencie znamená, že keď transakcie sa stalo, údaje je dobré. 475 00:20:34,450 --> 00:20:35,709 Moje vzťahy sú dobré. 476 00:20:35,709 --> 00:20:38,750 Nebudem odstrániť nadradený riadok a zanechať veľa osirelých detí 477 00:20:38,750 --> 00:20:40,970 v inej tabuľke. 478 00:20:40,970 --> 00:20:44,320 To sa nemôže stať, či som v súlade v kyslom transakcie. 479 00:20:44,320 --> 00:20:49,120 >> Izolácie znamená, že transakcia dôjde vždy po sebe. 480 00:20:49,120 --> 00:20:51,920 Konečný výsledok dát bude rovnaký stav 481 00:20:51,920 --> 00:20:54,770 ako keby tieto transakcie ktoré boli vydané súbežne 482 00:20:54,770 --> 00:20:57,340 boli popravení sériovo. 483 00:20:57,340 --> 00:21:00,030 Takže je to súbežnosť kontrola v databáze. 484 00:21:00,030 --> 00:21:04,130 Takže v podstate, nemôžem zvýšiť Rovnaká hodnota dvakrát s dvoma operáciami. 485 00:21:04,130 --> 00:21:08,580 >> Ale keď poviem pridať 1 k tejto hodnote, a dve transakcie prísť 486 00:21:08,580 --> 00:21:10,665 a pokúsiť sa urobiť to, niečí tam dostane ako prvý 487 00:21:10,665 --> 00:21:12,540 a druhý je bude sa tam dostať po. 488 00:21:12,540 --> 00:21:15,210 Takže nakoniec, som pridal dva. 489 00:21:15,210 --> 00:21:16,170 Vieš, čo tým myslím? 490 00:21:16,170 --> 00:21:16,670 OK. 491 00:21:16,670 --> 00:21:19,220 492 00:21:19,220 --> 00:21:21,250 >> Trvanlivosť je veľmi jednoduché. 493 00:21:21,250 --> 00:21:23,460 Keď je transakcia Uznáva sa, že je to 494 00:21:23,460 --> 00:21:26,100 Bude tam aj v prípade, že systém sa zrúti. 495 00:21:26,100 --> 00:21:29,230 Keď sa tento systém využíva, že Transakcie, ktorá bola spáchaná 496 00:21:29,230 --> 00:21:30,480 je v skutočnosti tam bude. 497 00:21:30,480 --> 00:21:33,130 Tak to je záruky kyseliny transakcií. 498 00:21:33,130 --> 00:21:35,470 To sú celkom pekné záruky mať na databázu, 499 00:21:35,470 --> 00:21:36,870 ale prídu na týchto nákladov. 500 00:21:36,870 --> 00:21:37,640 Doprava? 501 00:21:37,640 --> 00:21:40,520 >> Vzhľadom k tomu, problém s tento rámec 502 00:21:40,520 --> 00:21:44,540 v prípade, že je oddiel v dátach set, musím urobiť rozhodnutie. 503 00:21:44,540 --> 00:21:48,000 Budem musieť umožniť Aktualizácie na jednej alebo druhej strane. 504 00:21:48,000 --> 00:21:50,310 A ak sa tak stane, potom som už ísť 505 00:21:50,310 --> 00:21:52,630 aby bolo možné zachovať tieto vlastnosti. 506 00:21:52,630 --> 00:21:53,960 Nebudú konzistentné. 507 00:21:53,960 --> 00:21:55,841 Nebudú byť izolované. 508 00:21:55,841 --> 00:21:58,090 To je miesto, kde sa rozkladá pre relačnej databázy. 509 00:21:58,090 --> 00:22:01,360 To je dôvod, relačná databáz mierka vertikálne. 510 00:22:01,360 --> 00:22:05,530 >> Na druhej strane, máme čo sa nazýva BASE technológie. 511 00:22:05,530 --> 00:22:07,291 A to sú vaše NoSQL databázy. 512 00:22:07,291 --> 00:22:07,790 Dobre. 513 00:22:07,790 --> 00:22:10,180 Takže máme CP, databázy AP. 514 00:22:10,180 --> 00:22:14,720 A to sú v podstate to, čo hovoríte k dispozícii, mäkký stav, prípadne 515 00:22:14,720 --> 00:22:15,740 konzistentné. 516 00:22:15,740 --> 00:22:16,420 OK? 517 00:22:16,420 --> 00:22:19,690 >> V podstate k dispozícii, pretože sú to oddiel tolerantní. 518 00:22:19,690 --> 00:22:21,470 Budú vždy tam, a to aj v prípade, že je 519 00:22:21,470 --> 00:22:23,053 deliaca sieť medzi uzlami. 520 00:22:23,053 --> 00:22:25,900 Môžem Ak hovoriť k uzlu, ja som bude schopný čítať dáta. 521 00:22:25,900 --> 00:22:26,460 OK? 522 00:22:26,460 --> 00:22:30,810 Aj nemusí byť vždy schopný napísať Údaje, či som konzistentné platformu. 523 00:22:30,810 --> 00:22:32,130 Ale budem môcť čítať dáta. 524 00:22:32,130 --> 00:22:34,960 525 00:22:34,960 --> 00:22:38,010 >> Mäkká stav označuje že keď som si prečítal, že dáta, 526 00:22:38,010 --> 00:22:40,790 to nemusí byť rovnaké ako ostatných uzlov. 527 00:22:40,790 --> 00:22:43,390 Ak právo bolo vydané v uzle niekde inde v klastri 528 00:22:43,390 --> 00:22:46,650 a nebola replikované naprieč klaster ale keď som čítal, že údaje, 529 00:22:46,650 --> 00:22:48,680 že štát nemusí byť konzistentné. 530 00:22:48,680 --> 00:22:51,650 Avšak, to bude nakoniec konzistentné, 531 00:22:51,650 --> 00:22:53,870 čo znamená, že keď je pre zápis sa vykonáva v systéme, 532 00:22:53,870 --> 00:22:56,480 sa bude replikovať cez uzly. 533 00:22:56,480 --> 00:22:59,095 A nakoniec, že ​​štátna budú uvedené do poriadku, 534 00:22:59,095 --> 00:23:00,890 a to bude konzistentným stave. 535 00:23:00,890 --> 00:23:05,000 >> Teraz, teorém CAP naozaj hrá len v jednom stave. 536 00:23:05,000 --> 00:23:08,700 Táto podmienka je, keď sa to stane. 537 00:23:08,700 --> 00:23:13,710 Vzhľadom k tomu, kedykoľvek je to pracovať v normálny režim, neexistuje žiadny oddiel, 538 00:23:13,710 --> 00:23:16,370 všetko je konzistentné a sú k dispozícii. 539 00:23:16,370 --> 00:23:19,990 Stačí len starať o SPP keď máme tento oddiel. 540 00:23:19,990 --> 00:23:21,260 Takže tie sú zriedkavé. 541 00:23:21,260 --> 00:23:25,360 Ale ako systém reaguje, keď tí, dochádza diktovať, aký typ systému 542 00:23:25,360 --> 00:23:26,750 máme čo do činenia s. 543 00:23:26,750 --> 00:23:31,110 >> Takže poďme sa pozrieť na to, čo že vyzerá ako na AP systémy. 544 00:23:31,110 --> 00:23:32,621 OK? 545 00:23:32,621 --> 00:23:34,830 Systémy AP prichádzajú v dvoch príchutiach. 546 00:23:34,830 --> 00:23:38,514 Prichádzajú v chuti, ktorá je master master, 100%, vždy k dispozícii. 547 00:23:38,514 --> 00:23:40,430 A prichádzajú v iná varianta, ktorá hovorí, 548 00:23:40,430 --> 00:23:43,330 Vieš čo, ja budem robiť starosti o Toto rozdelenie veci 549 00:23:43,330 --> 00:23:44,724 v prípade, že skutočná partition dôjde. 550 00:23:44,724 --> 00:23:47,890 Inak to bude primárne uzly, kto bude mať práva. 551 00:23:47,890 --> 00:23:48,500 OK? 552 00:23:48,500 --> 00:23:50,040 >> Ak teda niečo ako Cassandra. 553 00:23:50,040 --> 00:23:54,440 Cassandra by byť majster master, dovoľte mi, aby som to zapísať do ktoréhokoľvek uzla. 554 00:23:54,440 --> 00:23:55,540 Takže čo sa stane? 555 00:23:55,540 --> 00:23:58,270 Takže mám objekt v databázy, ktorá existuje na dvoch uzlov. 556 00:23:58,270 --> 00:24:01,705 Hovorme tento objekt S. Takže máme stať pre S. 557 00:24:01,705 --> 00:24:04,312 Máme niektoré operácie na S, ktoré prebiehajú. 558 00:24:04,312 --> 00:24:06,270 Cassandra mi dovoľuje píšte na viac uzlov. 559 00:24:06,270 --> 00:24:08,550 Takže povedzme, že som sa dostať písať pre s dvoma uzlami. 560 00:24:08,550 --> 00:24:12,274 No, čo skončí deje, je hovoríme, že rozdeľovacom udalosti. 561 00:24:12,274 --> 00:24:14,190 Tam nemusí byť oddiel fyzická sieť. 562 00:24:14,190 --> 00:24:15,950 Avšak z dôvodu konštrukcie systému, to je 563 00:24:15,950 --> 00:24:18,449 v skutočnosti rozdelenie akonáhle ako som si písať na dvoch uzlov. 564 00:24:18,449 --> 00:24:20,830 Nie je to ma núti napísať celý jeden uzol. 565 00:24:20,830 --> 00:24:22,340 Píšem na dvoch uzlov. 566 00:24:22,340 --> 00:24:23,330 OK? 567 00:24:23,330 --> 00:24:25,740 >> Takže teraz mám dva stavy. 568 00:24:25,740 --> 00:24:26,360 OK? 569 00:24:26,360 --> 00:24:28,110 Čo sa bude diať je skôr alebo neskôr, 570 00:24:28,110 --> 00:24:29,960 tam to bude udalosť replikácie. 571 00:24:29,960 --> 00:24:33,300 Tam to bude to, čo sme volal zotavenie oddiel, ktorý 572 00:24:33,300 --> 00:24:35,200 je miesto, kde tieto dva štáty vrátiť spolu 573 00:24:35,200 --> 00:24:37,310 a tam to bude algoritmus ktorý beží vnútri databázy, 574 00:24:37,310 --> 00:24:38,540 sa rozhodne, čo má robiť. 575 00:24:38,540 --> 00:24:39,110 OK? 576 00:24:39,110 --> 00:24:43,057 V predvolenom nastavení, posledná aktualizácia víťazí vo väčšine systémov AP. 577 00:24:43,057 --> 00:24:44,890 Takže tam je zvyčajne predvolený algoritmus, čo 578 00:24:44,890 --> 00:24:47,400 hovoria spätné volanie funkcie, niečo, 579 00:24:47,400 --> 00:24:51,000 bude volaná, keď táto podmienka je detekovaný vykonávať nejakú logiku 580 00:24:51,000 --> 00:24:52,900 k vyriešeniu tohto konfliktu. 581 00:24:52,900 --> 00:24:53,850 OK? 582 00:24:53,850 --> 00:24:58,770 Východiskové spätné volanie a východiskové resolver vo väčšine AP databázach 583 00:24:58,770 --> 00:25:01,130 je, vieš čo, timestamp vyhráva. 584 00:25:01,130 --> 00:25:02,380 To bola posledná aktualizácia. 585 00:25:02,380 --> 00:25:04,320 Chystám sa dať túto aktualizáciu tam. 586 00:25:04,320 --> 00:25:08,440 Možno som výpis tento záznam, ktorý som dumpingové off do protokolu obnovy 587 00:25:08,440 --> 00:25:11,670 takže užívateľ môže prísť neskôr a povedať, hej, došlo ku kolízii. 588 00:25:11,670 --> 00:25:12,320 Čo sa stalo? 589 00:25:12,320 --> 00:25:16,370 A môžete skutočne výpis záznam všetky kolízie a vrátenie vykonaných zmien 590 00:25:16,370 --> 00:25:17,550 a uvidíme, čo sa stane. 591 00:25:17,550 --> 00:25:21,580 >> Teraz, ako užívateľ, môžete tiež obsahovať logiku do tohto spätného volania. 592 00:25:21,580 --> 00:25:24,290 Takže si môžete zmeniť spätné volanie operácie. 593 00:25:24,290 --> 00:25:26,730 Môžete povedať, hej, ja chcem k náprave tohto dátumu. 594 00:25:26,730 --> 00:25:28,880 A ja chcem, aby sa pokúsila zlúčiť tieto dva záznamy. 595 00:25:28,880 --> 00:25:30,050 Ale to je len na vás. 596 00:25:30,050 --> 00:25:32,880 Databázy nevie, ako sa tomu, že v predvolenom nastavení. Najviac času, 597 00:25:32,880 --> 00:25:34,850 jediné, čo je databáza Vie, ako urobiť, je povedať, 598 00:25:34,850 --> 00:25:36,100 tento bol posledný záznam. 599 00:25:36,100 --> 00:25:39,183 To je ten, ktorý vyhrá, a to je hodnota idem dať. 600 00:25:39,183 --> 00:25:41,490 Akonáhle to oddiel zotavenie a dôjde k replikáciu, 601 00:25:41,490 --> 00:25:43,930 máme štát, ktorý Teraz je S prvočíslo, čo je 602 00:25:43,930 --> 00:25:46,890 zlúčenie stav všetkých týchto objektov. 603 00:25:46,890 --> 00:25:49,700 Takže systémy AP toto. 604 00:25:49,700 --> 00:25:51,615 CP systémy nepotrebujú sa starať o to. 605 00:25:51,615 --> 00:25:54,490 Vzhľadom k tomu, akonáhle oddiel prichádza do hry, jednoducho prestať užívať 606 00:25:54,490 --> 00:25:55,530 píše. 607 00:25:55,530 --> 00:25:56,180 OK? 608 00:25:56,180 --> 00:25:58,670 Takže je to veľmi jednoduché vysporiadať s tým, že v súlade 609 00:25:58,670 --> 00:26:01,330 ak nechcete prijímať žiadne aktualizácie. 610 00:26:01,330 --> 00:26:04,620 To je s CP systémy robia. 611 00:26:04,620 --> 00:26:05,120 Dobre. 612 00:26:05,120 --> 00:26:07,590 >> Takže poďme hovoriť trochu niečo o prístupových vzory. 613 00:26:07,590 --> 00:26:11,580 Keď hovoríme o NoSQL, je to všetko o vzorku prístup. 614 00:26:11,580 --> 00:26:13,550 Teraz, SQL je ad hoc otázky. 615 00:26:13,550 --> 00:26:14,481 Je to relačná obchod. 616 00:26:14,481 --> 00:26:16,480 Nemusíme sa báť o vzorku prístup. 617 00:26:16,480 --> 00:26:17,688 Píšem veľmi zložitý dotaz. 618 00:26:17,688 --> 00:26:19,250 Ide to a získava dáta. 619 00:26:19,250 --> 00:26:21,210 To je to, čo to vyzerá ako, normalizácia. 620 00:26:21,210 --> 00:26:24,890 >> Takže v tomto konkrétnu štruktúru, pozeráme na katalóg produktov. 621 00:26:24,890 --> 00:26:26,640 Mám rôzne druhy výrobkov. 622 00:26:26,640 --> 00:26:27,217 Mám knihy. 623 00:26:27,217 --> 00:26:27,800 Mám albumu. 624 00:26:27,800 --> 00:26:30,090 Mám videa. 625 00:26:30,090 --> 00:26:33,370 Vzťah medzi výrobkami a niektorý z týchto kníh, albumov, 626 00:26:33,370 --> 00:26:34,860 a videá tabuliek je 1: 1. 627 00:26:34,860 --> 00:26:35,800 Dobre? 628 00:26:35,800 --> 00:26:38,860 Mám ID produktu, a že ID zodpovedá 629 00:26:38,860 --> 00:26:41,080 na knihu, album, alebo video. 630 00:26:41,080 --> 00:26:41,580 OK? 631 00:26:41,580 --> 00:26:44,350 To je vzťah 1: 1 po týchto tabuľkách. 632 00:26:44,350 --> 00:26:46,970 >> Teraz, books-- všetko, čo majú vlastnosti je root. 633 00:26:46,970 --> 00:26:47,550 Žiaden problém. 634 00:26:47,550 --> 00:26:48,230 To je skvelé. 635 00:26:48,230 --> 00:26:52,130 One-to-one vzťah, som si všetky údaje musím opísať tú knihu. 636 00:26:52,130 --> 00:26:54,770 Albums-- albumu majú stopy. 637 00:26:54,770 --> 00:26:56,470 To je to, čo nazývame jeden k veľa. 638 00:26:56,470 --> 00:26:58,905 Každé album môže mať mnoho stôp. 639 00:26:58,905 --> 00:27:00,780 Takže pre každé dráhe na album, mohol by som mať 640 00:27:00,780 --> 00:27:02,570 ďalší rekord v tomto podriadenej tabuľke. 641 00:27:02,570 --> 00:27:04,680 Tak som vytvoriť jeden záznam v mojom albumu tabuľke. 642 00:27:04,680 --> 00:27:06,700 Vytvoriť viac záznamov v tabuľke stop. 643 00:27:06,700 --> 00:27:08,850 One-to-many vzťah. 644 00:27:08,850 --> 00:27:11,220 >> Tento vzťah je to, čo nazývame many-to-many. 645 00:27:11,220 --> 00:27:11,750 OK? 646 00:27:11,750 --> 00:27:17,000 Vidíte, že herci by mohla byť v mnohých filmoch, mnoho videí. 647 00:27:17,000 --> 00:27:21,450 Takže to, čo robíme, je, že sme dať toto mapovanie tabuľku medzi tými, ktoré sa práve 648 00:27:21,450 --> 00:27:24,040 mapuje herca ID do ID videa. 649 00:27:24,040 --> 00:27:28,464 Teraz môžem vytvoriť dotaz spoje videa cez herec videa do hercov, 650 00:27:28,464 --> 00:27:31,130 a to mi dáva pekný zoznam všetky filmy a všetci herci 651 00:27:31,130 --> 00:27:32,420 ktorí boli v tom filme. 652 00:27:32,420 --> 00:27:33,290 >> OK. 653 00:27:33,290 --> 00:27:33,880 Tak ideme na to. 654 00:27:33,880 --> 00:27:38,040 One-to-one je najvyššej úrovne vzťah; one-to-many, 655 00:27:38,040 --> 00:27:40,240 albumu skladieb; many-to-many. 656 00:27:40,240 --> 00:27:44,990 To sú tri najvyššie úrovne vzťahy v žiadnej databáze. 657 00:27:44,990 --> 00:27:48,050 Ak viete, ako tí, vzťahy pracovať spoločne, 658 00:27:48,050 --> 00:27:51,490 potom viete veľa o už databázy. 659 00:27:51,490 --> 00:27:55,660 Takže NoSQL trochu funguje inak. 660 00:27:55,660 --> 00:27:58,930 Poďme sa zamyslieť nad za druhé to, čo to Vyzerá to, ísť pre všetky svoje produkty. 661 00:27:58,930 --> 00:28:01,096 >> V relačné obchode, ja sa chcú dostať všetky svoje produkty 662 00:28:01,096 --> 00:28:02,970 na zozname všetkých mojich výrobkov. 663 00:28:02,970 --> 00:28:04,910 To je veľa otázok. 664 00:28:04,910 --> 00:28:07,030 Mám otázku pre všetky moje knihy. 665 00:28:07,030 --> 00:28:08,470 Mám otázku od svojich albumov. 666 00:28:08,470 --> 00:28:09,970 A ja mám otázku pre všetkých mojich videí. 667 00:28:09,970 --> 00:28:11,719 A ja musím dať všetko dohromady v zozname 668 00:28:11,719 --> 00:28:15,250 a slúži to späť až do výšky aplikácie, ktorá je o to požiada. 669 00:28:15,250 --> 00:28:18,000 >> Ak chcete získať svoje knihy, som sa pripojiť Produkty a knihy. 670 00:28:18,000 --> 00:28:21,680 Ak chcete získať moje albumu, som sa pripojiť Produkty, albumu a skladby. 671 00:28:21,680 --> 00:28:25,330 A aby sa moje videá, mám pripojiť produktov na videá, 672 00:28:25,330 --> 00:28:28,890 pripojiť cez hercov videa, a priniesť hercov. 673 00:28:28,890 --> 00:28:31,020 Tak to je tri otázky. 674 00:28:31,020 --> 00:28:34,560 Veľmi zložité otázky na zhromaždiť jednu sadu výsledkov. 675 00:28:34,560 --> 00:28:36,540 >> To je menej ako optimálny. 676 00:28:36,540 --> 00:28:39,200 To je dôvod, prečo, keď hovoríme o dátové štruktúry, ktorá je 677 00:28:39,200 --> 00:28:42,900 postavená tak, aby agnostik s prístupom pattern-- dobre, že je to skvelé. 678 00:28:42,900 --> 00:28:45,730 A vidíte, je to naozaj pekné, ako sme organizovali dáta. 679 00:28:45,730 --> 00:28:46,550 A viete čo? 680 00:28:46,550 --> 00:28:49,750 Mám len jeden záznam pre herca. 681 00:28:49,750 --> 00:28:50,440 >> To je v pohode. 682 00:28:50,440 --> 00:28:53,750 Ja som deduplikované všetky svoje herca, a ja udržiavané svoje združenie 683 00:28:53,750 --> 00:28:55,200 V tejto tabuľke mapovanie. 684 00:28:55,200 --> 00:29:00,620 Avšak, ako sa dáta out sa stáva drahšie. 685 00:29:00,620 --> 00:29:04,500 Posielam CPU celého systému spájajúcej tieto dátové štruktúry spolu 686 00:29:04,500 --> 00:29:05,950 aby bolo možné vytiahnuť, že dáta späť. 687 00:29:05,950 --> 00:29:07,310 >> Tak ako to mám dostať okolo, že? 688 00:29:07,310 --> 00:29:11,200 V NoSQL je to o agregácie, nie normalizácie. 689 00:29:11,200 --> 00:29:13,534 Takže chceme povedať chceme podporovať prístup vzor. 690 00:29:13,534 --> 00:29:15,283 Ak vzorka prístup k aplikáciám, 691 00:29:15,283 --> 00:29:16,770 Musím sa dostať všetky svoje výrobky. 692 00:29:16,770 --> 00:29:19,027 Poďme dať všetky produkty v jednej tabuľke. 693 00:29:19,027 --> 00:29:22,110 Keď som dal všetky produkty v jednej tabuľke, Ja si len vybrať všetky produkty 694 00:29:22,110 --> 00:29:23,850 Z tejto tabuľky, a ja si to všetko. 695 00:29:23,850 --> 00:29:25,240 Tak ako to mám urobiť, že? 696 00:29:25,240 --> 00:29:28,124 No v NoSQL nie je štruktúra k stolu. 697 00:29:28,124 --> 00:29:30,540 Budeme hovoriť trochu o Ako to funguje Dynamo DB. 698 00:29:30,540 --> 00:29:33,570 Ale nemusíte mať rovnaký atribúty a rovnaké vlastnosti 699 00:29:33,570 --> 00:29:37,751 v každom rade, v každom jednotlivom položky, ako vy v tabuľke SQL. 700 00:29:37,751 --> 00:29:39,750 A čo mi to dovoľuje urobiť, je veľa vecí 701 00:29:39,750 --> 00:29:41,124 a dal mi veľkú flexibilitu. 702 00:29:41,124 --> 00:29:45,360 V tomto konkrétnom prípade, I majú svoj produkt doklady. 703 00:29:45,360 --> 00:29:49,090 A v tomto konkrétnom príklad, všetko 704 00:29:49,090 --> 00:29:51,930 je dokument, v tabuľke Výrobky. 705 00:29:51,930 --> 00:29:56,510 A produkt pre knihu by mohol majú ID typu, ktorý určuje knihu. 706 00:29:56,510 --> 00:29:59,180 A aplikácie by sa malo prepnúť na tomto ID. 707 00:29:59,180 --> 00:30:02,570 >> V aplikačnej vrstve, idem hovoriť ach, aký typ záznamu je to? 708 00:30:02,570 --> 00:30:04,100 Oh, to je kniha rekord. 709 00:30:04,100 --> 00:30:05,990 Book záznamy majú tieto vlastnosti. 710 00:30:05,990 --> 00:30:08,100 Dovoľte mi, aby som vytvoriť knihu objekt. 711 00:30:08,100 --> 00:30:11,289 Takže ja idem pre naplnenie kniha objekt s touto položkou. 712 00:30:11,289 --> 00:30:13,080 Ďalšia položka príde a hovorí, čo je táto položka? 713 00:30:13,080 --> 00:30:14,560 No táto položka je album. 714 00:30:14,560 --> 00:30:17,340 Oh, mám úplne iná rutina pre spracovanie, ktoré, 715 00:30:17,340 --> 00:30:18,487 pretože je to album. 716 00:30:18,487 --> 00:30:19,320 Vieš, čo tým myslím? 717 00:30:19,320 --> 00:30:21,950 >> Takže aplikácie tier-- I stačí vybrať všetky tieto záznamy. 718 00:30:21,950 --> 00:30:23,200 Všetci začnú prichádzať dovnútra. 719 00:30:23,200 --> 00:30:24,680 Mohli by byť všetky typy. 720 00:30:24,680 --> 00:30:27,590 A je to logika aplikácie ktorý prepína naprieč týchto typov 721 00:30:27,590 --> 00:30:29,530 a rozhodne, ako ich spracovať. 722 00:30:29,530 --> 00:30:33,640 >> Opäť, takže sme optimalizáciu schéma vzorka prístup. 723 00:30:33,640 --> 00:30:36,390 Robíme to tým, rúca tie tabuľky. 724 00:30:36,390 --> 00:30:39,670 Sme v podstate prevzatia Tieto štandardizovanej štruktúry, 725 00:30:39,670 --> 00:30:42,000 a staviame hierarchickej štruktúry. 726 00:30:42,000 --> 00:30:45,130 Vnútri každej z týchto záznamov Idem vidieť vlastnosti poľa. 727 00:30:45,130 --> 00:30:49,400 >> Vnútri tohto dokumentu pre albumu, Vidím matice stop. 728 00:30:49,400 --> 00:30:53,900 Tieto stopy teraz become-- je to v podstate toto dieťa tabuľka 729 00:30:53,900 --> 00:30:56,520 existuje priamo tu v tejto štruktúre. 730 00:30:56,520 --> 00:30:57,975 Takže môžete to urobiť v DynamoDB. 731 00:30:57,975 --> 00:30:59,810 Môžete to urobiť v MongoDB. 732 00:30:59,810 --> 00:31:01,437 Môžete to urobiť v akejkoľvek databáze NoSQL. 733 00:31:01,437 --> 00:31:03,520 Vytvorte tieto typy hierarchickej dátovej štruktúry 734 00:31:03,520 --> 00:31:07,120 ktoré umožňujú načítanie dát veľmi rýchlo, pretože teraz 735 00:31:07,120 --> 00:31:08,537 Nemusíte odpovedať. 736 00:31:08,537 --> 00:31:11,620 Keď som sa vložiť riadok do koľajniciach stôl, alebo o riadok do tabuľky Alba 737 00:31:11,620 --> 00:31:13,110 Musím odpovedať tomuto schémy. 738 00:31:13,110 --> 00:31:18,060 Musím mať atribút alebo majetok, ktorý je definovaný na tejto tabuľke. 739 00:31:18,060 --> 00:31:20,480 Každý z nich, keď som vložte tento riadok. 740 00:31:20,480 --> 00:31:21,910 To nie je prípad v NoSQL. 741 00:31:21,910 --> 00:31:24,440 >> Môžem mať úplne odlišné vlastnosti v každom dokumente 742 00:31:24,440 --> 00:31:26,100 že som sa vložiť do zbierky. 743 00:31:26,100 --> 00:31:30,480 Takže veľmi silný mechanizmus. 744 00:31:30,480 --> 00:31:32,852 A je to naozaj, ako vás optimalizáciu systému. 745 00:31:32,852 --> 00:31:35,310 Vzhľadom k tomu, teraz, že otázka, namiesto spájanie všetky tieto tabuľky 746 00:31:35,310 --> 00:31:39,160 a vykonávanie pol tucta otázky vytiahnuť späť dáta, čo potrebujem, 747 00:31:39,160 --> 00:31:40,890 Som vykonávajúci jeden dotaz. 748 00:31:40,890 --> 00:31:43,010 A ja som iterácie cez výsledky uvedené. 749 00:31:43,010 --> 00:31:46,512 to vám dáva predstavu o sile NoSQL. 750 00:31:46,512 --> 00:31:49,470 Chystám sa ísť trochu bokom tu a hovoriť trochu o tom. 751 00:31:49,470 --> 00:31:53,240 To je viac druhov marketing alebo technology-- 752 00:31:53,240 --> 00:31:55,660 marketing technológie typ diskusie. 753 00:31:55,660 --> 00:31:58,672 Ale je dôležité pochopiť, pretože keď sa pozrieme na vrchole 754 00:31:58,672 --> 00:32:00,380 tu na tento graf, čo sa pozeráme 755 00:32:00,380 --> 00:32:04,030 je to, čo nazývame Technológie humbuk krivka. 756 00:32:04,030 --> 00:32:06,121 A čo to znamená, nové veci prichádza do hry. 757 00:32:06,121 --> 00:32:07,120 Ľudia si myslia, že je to skvelé. 758 00:32:07,120 --> 00:32:09,200 Ja som vyriešil všetky moje problémy. 759 00:32:09,200 --> 00:32:11,630 >> To by mohlo byť koniec všetci, byť všetko, na všetko. 760 00:32:11,630 --> 00:32:12,790 A začnú používať. 761 00:32:12,790 --> 00:32:14,720 A oni hovoria, toto nefunguje. 762 00:32:14,720 --> 00:32:17,600 To nie je správne. 763 00:32:17,600 --> 00:32:19,105 Staré veci boli lepšie. 764 00:32:19,105 --> 00:32:21,230 A oni sa vrátiť k robeniu veci tak, ako boli. 765 00:32:21,230 --> 00:32:22,730 A potom nakoniec idú, vieš čo? 766 00:32:22,730 --> 00:32:24,040 Toto nie je tak zlé. 767 00:32:24,040 --> 00:32:26,192 Ach, to je, ako to funguje. 768 00:32:26,192 --> 00:32:28,900 A akonáhle sa zistiť, ako to práce, začnú stále lepší. 769 00:32:28,900 --> 00:32:32,050 >> A legrační vec, o tom Je to trochu liniek až na to, čo 770 00:32:32,050 --> 00:32:34,300 nazývame Technology osvojenie dieťaťa krivky. 771 00:32:34,300 --> 00:32:36,910 Takže čo sa stane, je, že sme sa nejaká technológia spúšť. 772 00:32:36,910 --> 00:32:39,100 V prípade databáz, to je tlak dát. 773 00:32:39,100 --> 00:32:42,200 Hovorili sme o vysokých vodných bodov tlaku dát po celú dobu. 774 00:32:42,200 --> 00:32:46,310 Keď tieto dáta tlak zasiahne určité bod, to je technológia spúšť. 775 00:32:46,310 --> 00:32:47,830 >> Začína to príliš drahé. 776 00:32:47,830 --> 00:32:49,790 To trvá príliš dlho, aby spracovanie dát. 777 00:32:49,790 --> 00:32:50,890 Potrebujeme niečo lepšie. 778 00:32:50,890 --> 00:32:52,890 Získate inovátorov tam vonku pobehujú, 779 00:32:52,890 --> 00:32:55,050 snaží zistiť, aké je riešenie. 780 00:32:55,050 --> 00:32:56,050 Čo je to nová myšlienka? 781 00:32:56,050 --> 00:32:58,170 >> Aký je ďalší najlepší spôsob, ako túto vec? 782 00:32:58,170 --> 00:32:59,530 A oni prídu s niečím. 783 00:32:59,530 --> 00:33:03,140 A ľudia s skutočnú bolesť, chlapci na drsne, 784 00:33:03,140 --> 00:33:06,390 budú skákať cez to všetko, pretože potrebujú odpoveď. 785 00:33:06,390 --> 00:33:09,690 A teraz, čo nevyhnutne happens-- a to sa práve teraz deje v NoSQL. 786 00:33:09,690 --> 00:33:11,090 Vidím to po celú dobu. 787 00:33:11,090 --> 00:33:13,610 >> Čo sa nevyhnutne stane, je ľudia začnú používať nový nástroj 788 00:33:13,610 --> 00:33:15,490 rovnaký spôsob, akým používa staré nástroje. 789 00:33:15,490 --> 00:33:17,854 A oni zistili to nefunguje tak dobre. 790 00:33:17,854 --> 00:33:20,020 Nemôžem si spomenúť, kto som hovoriť dneska. 791 00:33:20,020 --> 00:33:22,080 Ale je to ako, keď sa zbíjačka bol vynájdený, 792 00:33:22,080 --> 00:33:24,621 ľudia nemali hojdačka ju ich hlava rozbiť betón. 793 00:33:24,621 --> 00:33:27,360 794 00:33:27,360 --> 00:33:30,610 >> Ale to je to, čo je deje NoSQL dnes. 795 00:33:30,610 --> 00:33:33,900 Pôjdete Ak vo väčšine obchodov, sa snaží byť NoSQL obchodov. 796 00:33:33,900 --> 00:33:36,510 To, čo robíte, je Používajú NoSQL, 797 00:33:36,510 --> 00:33:39,900 a oni ho načítanie plná relačného schémy. 798 00:33:39,900 --> 00:33:41,630 Vzhľadom k tomu, že to, ako navrhujú databáz. 799 00:33:41,630 --> 00:33:44,046 A oni sú zvedaví, prečo je to nefunguje dobre? 800 00:33:44,046 --> 00:33:45,230 Páni, táto vec smrdí. 801 00:33:45,230 --> 00:33:49,900 Musel som sa udržať všetky moje pripojí in-- je to ako, nie, nie. 802 00:33:49,900 --> 00:33:50,800 Udržiavať sa pripojí? 803 00:33:50,800 --> 00:33:52,430 Prečo sa pripojí dáta? 804 00:33:52,430 --> 00:33:54,350 Nemusíte pripojiť dáta v NoSQL. 805 00:33:54,350 --> 00:33:55,850 Agregovať to. 806 00:33:55,850 --> 00:34:00,690 >> Takže ak chcete, aby sa tomu zabránilo, učiť sa ako nástroj funguje pred vami vlastne 807 00:34:00,690 --> 00:34:02,010 začať používať. 808 00:34:02,010 --> 00:34:04,860 Nesnažte sa používať nové nástroje pre Rovnakým spôsobom ste použili staré nástroje. 809 00:34:04,860 --> 00:34:06,500 Budeš mať zlú skúsenosť. 810 00:34:06,500 --> 00:34:08,848 A zakaždým to je to, o čo ide. 811 00:34:08,848 --> 00:34:11,389 Keď sme sa začnú prichádzať tu je to preto, že ľudia zistili, 812 00:34:11,389 --> 00:34:13,449 ako používať nástroje. 813 00:34:13,449 --> 00:34:16,250 >> Urobili rovnakú vec, keď relačnej databázy boli vynájdené, 814 00:34:16,250 --> 00:34:17,969 a oni boli nahradenie súborové systémy. 815 00:34:17,969 --> 00:34:20,420 Snažili sa vybudovať súborové systémy s relačných databáz 816 00:34:20,420 --> 00:34:22,159 pretože to je to, čo ľudia pochopili. 817 00:34:22,159 --> 00:34:23,049 Nefungovalo to. 818 00:34:23,049 --> 00:34:26,090 Takže pochopenie osvedčených postupov technológia pracujete s 819 00:34:26,090 --> 00:34:26,730 je obrovský. 820 00:34:26,730 --> 00:34:29,870 Veľmi dôležité. 821 00:34:29,870 --> 00:34:32,440 >> Takže sme sa dostať do DynamoDB. 822 00:34:32,440 --> 00:34:36,480 DynamoDB je AWS je Plne riadené NoSQL platformy. 823 00:34:36,480 --> 00:34:37,719 Čo znamená plne riadené znamená? 824 00:34:37,719 --> 00:34:40,010 To znamená, že nemusíte naozaj o nič starať. 825 00:34:40,010 --> 00:34:42,060 >> Môžete prísť, poviete us, potrebujem tabuľku. 826 00:34:42,060 --> 00:34:43,409 Je potrebné toľko kapacity. 827 00:34:43,409 --> 00:34:47,300 Stlačíte tlačidlo, a my ustanovenia všetka infraštruktúra za scény. 828 00:34:47,300 --> 00:34:48,310 Teraz, keď je obrovský. 829 00:34:48,310 --> 00:34:51,310 >> Vzhľadom k tomu, keď hovoríte škálovanie o databázy, 830 00:34:51,310 --> 00:34:53,917 NoSQL dátové klastre na stupnice, prevádzkové petabajtov, 831 00:34:53,917 --> 00:34:55,750 beží milióny transakcií za sekundu, 832 00:34:55,750 --> 00:34:58,180 tieto veci nie sú malé zhluky. 833 00:34:58,180 --> 00:35:00,830 Hovoríme tisíce inštancií. 834 00:35:00,830 --> 00:35:04,480 Správa tisíce prípadov, dokonca aj virtuálne inštancie, 835 00:35:04,480 --> 00:35:06,350 je skutočnou bolesť v zadku. 836 00:35:06,350 --> 00:35:09,110 Mám na mysli, premýšľať o tom, zakaždým, keď Systém náplasť prevádzkové vyjde 837 00:35:09,110 --> 00:35:11,552 alebo novú verziu databázy. 838 00:35:11,552 --> 00:35:13,260 Čo to znamená vám prevádzkovo? 839 00:35:13,260 --> 00:35:16,330 To znamená, že máš 1200 servery, ktoré je potrebné aktualizovať. 840 00:35:16,330 --> 00:35:18,960 Teraz ešte s automatizáciou, ktorý môže trvať dlhý čas. 841 00:35:18,960 --> 00:35:21,480 To môže spôsobiť veľa prevádzkové bolesti hlavy, 842 00:35:21,480 --> 00:35:23,090 preto, že som mohol mať služby nadol. 843 00:35:23,090 --> 00:35:26,070 >> Keď som aktualizovať tieto databázy, ja mohli robiť modrá zelená nasadenie 844 00:35:26,070 --> 00:35:29,420 kde som nasadiť a upgrade polovica mojej uzly, a potom inovovať druhú polovicu. 845 00:35:29,420 --> 00:35:30,490 Vezmite tie dole. 846 00:35:30,490 --> 00:35:33,410 Takže riadenie infraštruktúry Mierka je nesmierne bolestivé. 847 00:35:33,410 --> 00:35:36,210 A AWS prijať, že bolesť z nej. 848 00:35:36,210 --> 00:35:39,210 A databázy NoSQL môže byť mimoriadne bolestivá 849 00:35:39,210 --> 00:35:41,780 vzhľadom na spôsob ich mierku. 850 00:35:41,780 --> 00:35:42,926 >> Mierka vodorovne. 851 00:35:42,926 --> 00:35:45,550 Ak chcete mať väčšiu NoSQL databázy, kupujete viac uzlov. 852 00:35:45,550 --> 00:35:48,660 Každý uzol si kúpite, je ďalší operačný bolesť hlavy. 853 00:35:48,660 --> 00:35:50,830 Tak nech niekto iný urobí za vás. 854 00:35:50,830 --> 00:35:52,000 AWS môže urobiť. 855 00:35:52,000 --> 00:35:54,587 >> Podporujeme hodnoty kľúčového dokumentu. 856 00:35:54,587 --> 00:35:56,670 Teraz sme nešli moc do na strane grafu. 857 00:35:56,670 --> 00:35:58,750 Je tu mnoho rôznych chuťou NoSQL. 858 00:35:58,750 --> 00:36:02,670 Sú to všetky druhy získavanie munged spoločne v tomto bode. 859 00:36:02,670 --> 00:36:06,260 Môžete sa pozrieť na DynamoDB a povedať áno, obaja sme dokument a kľúčovou hodnotou 860 00:36:06,260 --> 00:36:08,412 uložiť tento bod. 861 00:36:08,412 --> 00:36:10,620 A môžete argumentovať funkcie jedného nad druhým. 862 00:36:10,620 --> 00:36:13,950 Pre mňa, veľa je to naozaj six jednej pol tucta druhého. 863 00:36:13,950 --> 00:36:18,710 Každý z týchto technológií je jemné technológie a kvalitné riešenie. 864 00:36:18,710 --> 00:36:23,390 Nepovedal by som, že je lepší alebo MongoDB horšie ako Couch, potom Cassandra, 865 00:36:23,390 --> 00:36:25,994 potom Dynamo, alebo naopak. 866 00:36:25,994 --> 00:36:27,285 Chcem povedať, že to sú len možnosti. 867 00:36:27,285 --> 00:36:29,850 868 00:36:29,850 --> 00:36:32,700 >> Je to rýchle a je to konzistentné v akomkoľvek meradle. 869 00:36:32,700 --> 00:36:36,210 Takže to je jedna z najväčších bonusy získate s AWS. 870 00:36:36,210 --> 00:36:40,850 S DynamoDB je schopnosť získať nízke jednu číslicu 871 00:36:40,850 --> 00:36:44,040 milisekunda oneskorenie v akomkoľvek meradle. 872 00:36:44,040 --> 00:36:45,720 To bol cieľ dizajnu systému. 873 00:36:45,720 --> 00:36:49,130 A máme zákazníkov, ktoré robia milióny transakcií za sekundu. 874 00:36:49,130 --> 00:36:52,670 >> Teraz budem ísť cez niektoré z tých, prípadov použitia za niekoľko minút tu. 875 00:36:52,670 --> 00:36:55,660 Integrovaný prístup control-- máme to, čo nazývame 876 00:36:55,660 --> 00:36:57,920 Identity Access Management, alebo IAM. 877 00:36:57,920 --> 00:37:01,980 To prestupuje všetky systémy, každá služba, ktorá ponúka AWS. 878 00:37:01,980 --> 00:37:03,630 DynamoDB nie je výnimkou. 879 00:37:03,630 --> 00:37:06,020 Môžete riadiť prístup k DynamoDB tabuliek. 880 00:37:06,020 --> 00:37:09,960 Cez všetky vaše AWS účtov definovanie prístupových rolí a oprávnení 881 00:37:09,960 --> 00:37:12,140 v IAM infraštruktúry. 882 00:37:12,140 --> 00:37:16,630 >> A to je kľúč a neoddeliteľnou zložkou to, čo nazývame udalosťami riadené programovanie. 883 00:37:16,630 --> 00:37:19,056 Teraz sa jedná o nové paradigma. 884 00:37:19,056 --> 00:37:22,080 >> Divákov: Ako je na tom vaša rýchlosť true pozitíva oproti falošne negatívnych 885 00:37:22,080 --> 00:37:24,052 vo vašom systéme riadenia prístupu? 886 00:37:24,052 --> 00:37:26,260 RICK Houlihan: Pravda pozitívy proti falošne negatívne? 887 00:37:26,260 --> 00:37:28,785 Publikum: Vrátenie čo mali by ste sa vracia? 888 00:37:28,785 --> 00:37:33,720 Na rozdiel od raz za čas to nevracia, kedy by mal overiť? 889 00:37:33,720 --> 00:37:36,260 890 00:37:36,260 --> 00:37:38,050 >> RICK Houlihan: Nemohla som ti to povedať. 891 00:37:38,050 --> 00:37:40,140 Ak existuje nejaké poruchy vôbec na to, 892 00:37:40,140 --> 00:37:42,726 Nie som človek sa opýtať že osobitné otázka. 893 00:37:42,726 --> 00:37:43,850 Ale to je dobrá otázka. 894 00:37:43,850 --> 00:37:45,905 Bol by som zvedavý že sám, v skutočnosti. 895 00:37:45,905 --> 00:37:48,810 896 00:37:48,810 --> 00:37:51,320 >> A tak opäť, nové paradigma je udalosťami riadené programovanie. 897 00:37:51,320 --> 00:37:55,160 To je myšlienka, že môžete nasadiť komplexné aplikácie, ktoré 898 00:37:55,160 --> 00:37:59,720 môže pracovať veľmi, veľmi vysoká merítka bez akejkoľvek infraštruktúry vôbec. 899 00:37:59,720 --> 00:38:02,120 Bez stanovených infraštruktúru vôbec. 900 00:38:02,120 --> 00:38:04,720 A budeme hovoriť trochu o tom, čo to znamená, že ako my 901 00:38:04,720 --> 00:38:06,550 dostať sa na ďalší pár grafov. 902 00:38:06,550 --> 00:38:08,716 >> Prvá vec, ktorú urobíme ich budeme hovoriť o tabuľkách. 903 00:38:08,716 --> 00:38:10,857 Dátové typy API pre Dynamo. 904 00:38:10,857 --> 00:38:13,190 A prvá vec, ktorú budete Všimnite si, keď sa pozriete na to, 905 00:38:13,190 --> 00:38:17,930 ak ste oboznámení s ľubovoľnou databázou, databázy majú naozaj dva druhy API 906 00:38:17,930 --> 00:38:18,430 Ja by som to hovoriť. 907 00:38:18,430 --> 00:38:21,570 Alebo dve sady API. 908 00:38:21,570 --> 00:38:23,840 Jednou z nich by bol administratívne API. 909 00:38:23,840 --> 00:38:26,710 >> Veci, ktoré sa starajú o Funkcie databázy. 910 00:38:26,710 --> 00:38:31,340 Konfigurácia engine pre ukladanie, zriaďovanie a pridávanie tabuliek. 911 00:38:31,340 --> 00:38:35,180 vytvorenie databázy katalógy a inštancie. 912 00:38:35,180 --> 00:38:40,450 Tie things-- v DynamoDB, budete majú veľmi krátky, krátky zoznamy. 913 00:38:40,450 --> 00:38:43,120 >> Takže v iných databázach, môžete vidieť desiatky 914 00:38:43,120 --> 00:38:45,680 príkazov, správnych príkazy, pre konfiguráciu 915 00:38:45,680 --> 00:38:47,290 tieto ďalšie možnosti. 916 00:38:47,290 --> 00:38:51,234 V DynamoDB nepotrebujete, pretože tí, nenakonfigurujete systém, čo robíme. 917 00:38:51,234 --> 00:38:54,150 Takže jediná vec, ktorú musíte urobiť, je povedz mi, čo veľkosť tabuľky potrebujem. 918 00:38:54,150 --> 00:38:55,660 Tak dostanete veľmi obmedzený súbor príkazov. 919 00:38:55,660 --> 00:38:58,618 >> Získate CREATE TABLE aktualizácie, tabuľka, Odstrániť tabuľku a označenie stolových. 920 00:38:58,618 --> 00:39:01,150 To sú jediné veci, čo potrebujete pre DynamoDB. 921 00:39:01,150 --> 00:39:03,294 Nemusíte úložisko konfigurácia motora. 922 00:39:03,294 --> 00:39:04,960 Nepotrebujem sa starať o replikáciu. 923 00:39:04,960 --> 00:39:06,490 Nepotrebujem sa starať o sharding. 924 00:39:06,490 --> 00:39:07,800 >> Nepotrebujem sa obávať o niektorý z týchto vecí. 925 00:39:07,800 --> 00:39:08,740 Robíme to všetko za vás. 926 00:39:08,740 --> 00:39:11,867 Tak to je obrovské množstvo réžia to je len zdvihne tanier. 927 00:39:11,867 --> 00:39:13,200 Potom máme operátormi CRUD. 928 00:39:13,200 --> 00:39:17,740 CRUD je niečo, čo sme volať v databáze, ktorá je 929 00:39:17,740 --> 00:39:19,860 Vytvoriť, aktualizovať, mazať operátorov. 930 00:39:19,860 --> 00:39:24,180 To sú vaše bežné databázové operácie. 931 00:39:24,180 --> 00:39:31,299 Veci ako put položku, dostať položku, aktualizácia položky, mazať položky, šarže dotaz, skenovať. 932 00:39:31,299 --> 00:39:32,840 Ak chcete skenovať celú tabuľku. 933 00:39:32,840 --> 00:39:34,220 Vytiahnite všetko zo stola. 934 00:39:34,220 --> 00:39:37,130 Jedna z pekné veci o DynamoDB Je to umožňuje paralelné skenovanie. 935 00:39:37,130 --> 00:39:40,602 Takže môžete v skutočnosti, dajte mi vedieť, koľko nite chcete spustiť na tom skenu. 936 00:39:40,602 --> 00:39:41,810 A môžeme spustiť tieto závity. 937 00:39:41,810 --> 00:39:43,985 Môžeme točiť, že skenovať hore naprieč viac vlákien 938 00:39:43,985 --> 00:39:49,060 takže môžete skenovať celú tabuľku space veľmi, veľmi rýchlo DynamoDB. 939 00:39:49,060 --> 00:39:51,490 >> Ďalší API máme, je to, čo nazývame Streams API. 940 00:39:51,490 --> 00:39:52,940 Nebudeme hovoriť príliš veľa o tom práve teraz. 941 00:39:52,940 --> 00:39:55,189 Mám nejaký obsah neskôr Na v balíčku o tom. 942 00:39:55,189 --> 00:39:59,910 Ale prúdy je naozaj running-- myslieť na to, ako čas objednať 943 00:39:59,910 --> 00:40:01,274 a zmena oddiel log. 944 00:40:01,274 --> 00:40:03,940 Všetko, čo sa deje na V tabuľke sa objaví na prúde. 945 00:40:03,940 --> 00:40:05,940 >> Každý zapísať do tabuľky sa objaví na prúde. 946 00:40:05,940 --> 00:40:08,370 Môžete si prečítať tento prúd, a môžete robiť, čo s ním. 947 00:40:08,370 --> 00:40:10,150 Porozprávame sa o tom, čo typy vecí, 948 00:40:10,150 --> 00:40:13,680 činenia s vecami, ako sú replikácia, vznikajú sekundárne indexy. 949 00:40:13,680 --> 00:40:17,620 Všetky druhy naozaj cool veci, ktoré môžete urobiť s tým. 950 00:40:17,620 --> 00:40:19,150 >> Dátové typy. 951 00:40:19,150 --> 00:40:23,320 V DynamoDB, podporujeme aj kľúč hodnota a dátové typy dokumentov. 952 00:40:23,320 --> 00:40:26,350 Na ľavej strane obrazovky tu, máme naše základné typy. 953 00:40:26,350 --> 00:40:27,230 Typy hodnoty kľúča. 954 00:40:27,230 --> 00:40:30,040 Sú to reťazce, čísla a binárne súbory. 955 00:40:30,040 --> 00:40:31,640 >> Takže len tri základné typy. 956 00:40:31,640 --> 00:40:33,700 A potom môžete mať sady tie. 957 00:40:33,700 --> 00:40:37,650 Jedna z pekné veci o NoSQL je môžete obsahovať pole ako vlastnosti. 958 00:40:37,650 --> 00:40:42,050 A s DynamoDB môžete obsahovať pole základných typov ako koreňová vlastnosť. 959 00:40:42,050 --> 00:40:43,885 >> A potom je tu typy dokumentov. 960 00:40:43,885 --> 00:40:45,510 Koľko ľudí sú oboznámení s JSON? 961 00:40:45,510 --> 00:40:47,130 Vy oboznámenie s JSON toľko? 962 00:40:47,130 --> 00:40:49,380 Je to v podstate JavaScript Object, notácie. 963 00:40:49,380 --> 00:40:52,510 To vám umožní v podstate definujú hierarchickú štruktúru. 964 00:40:52,510 --> 00:40:58,107 >> Môžete uložiť dokument o JSON DynamoDB použitia bežných komponentov 965 00:40:58,107 --> 00:41:00,940 alebo stavebné bloky, ktoré sú k dispozícii vo väčšine programovacích jazykoch. 966 00:41:00,940 --> 00:41:03,602 Takže ak máte Javu, budete pri pohľade na mapách a zoznamy. 967 00:41:03,602 --> 00:41:05,060 Môžem vytvoriť objekty, ktoré Mapa oblasti. 968 00:41:05,060 --> 00:41:08,030 Mapa ako kľúčové hodnoty uložená ako vlastnosti. 969 00:41:08,030 --> 00:41:10,890 A to by mohlo mať zoznamy hodnôt v rámci týchto vlastností. 970 00:41:10,890 --> 00:41:13,490 Môžete ukladať tento komplex hierarchická štruktúra 971 00:41:13,490 --> 00:41:16,320 ako jediný atribút z položky DynamoDB. 972 00:41:16,320 --> 00:41:19,010 973 00:41:19,010 --> 00:41:24,460 >> Takže tabuliek v DynamoDB, rovnako ako väčšina Databáza NoSQL, tabuľky majú položky. 974 00:41:24,460 --> 00:41:26,469 V MongoDB by ste volanie týchto dokumentov. 975 00:41:26,469 --> 00:41:27,760 A to by bol gauč základňa. 976 00:41:27,760 --> 00:41:28,900 Tiež dokument databázy. 977 00:41:28,900 --> 00:41:29,941 Zavoláte týchto dokumentov. 978 00:41:29,941 --> 00:41:32,930 Dokumenty alebo položky majú atribúty. 979 00:41:32,930 --> 00:41:35,850 Atribúty môžu existovať alebo neexistuje na položku. 980 00:41:35,850 --> 00:41:38,520 V DynamoDB, je tu jedným povinný atribút. 981 00:41:38,520 --> 00:41:43,880 Rovnako ako v relačnej databáze, máte primárny kľúč na stole. 982 00:41:43,880 --> 00:41:46,010 >> DynamoDB má to, čo nazývame hash kľúč. 983 00:41:46,010 --> 00:41:48,280 Hash kľúč musí byť jedinečný. 984 00:41:48,280 --> 00:41:52,580 Takže keď som definovať hash tabuľky, v podstate to, čo hovorím 985 00:41:52,580 --> 00:41:54,110 je každá položka bude mať hash kľúč. 986 00:41:54,110 --> 00:41:58,520 A každý krížikom musí byť jedinečný. 987 00:41:58,520 --> 00:42:01,200 >> Každá položka je definovaná touto unikátnou krížik. 988 00:42:01,200 --> 00:42:02,940 A tam môže byť len jeden. 989 00:42:02,940 --> 00:42:05,820 To je v poriadku, ale častokrát to, čo ľudia potrebujú 990 00:42:05,820 --> 00:42:08,170 je chcú, je to hash Kľúčom k tomu trochu viac 991 00:42:08,170 --> 00:42:11,010 než byť len jedinečný identifikátor. 992 00:42:11,010 --> 00:42:15,240 Často chceme použiť tento hash kľúč ako najvyššej úrovne agregácie vedra. 993 00:42:15,240 --> 00:42:19,160 A spôsob, ako to urobiť, je tým, pridávanie hovoríme rozsah kľúč. 994 00:42:19,160 --> 00:42:22,460 >> Takže ak je to len hash stôl, musí to byť jedinečná. 995 00:42:22,460 --> 00:42:27,040 Pokiaľ sa jedná o hash a rozsah tabuľky sa kombinácia hash a rozsah 996 00:42:27,040 --> 00:42:28,640 musí byť jedinečný. 997 00:42:28,640 --> 00:42:30,110 Takže myslíte, že o tom týmto spôsobom. 998 00:42:30,110 --> 00:42:32,140 Ak mám fórum. 999 00:42:32,140 --> 00:42:39,010 A forma má tém, má stĺpiky, a to má odpovede. 1000 00:42:39,010 --> 00:42:42,630 >> Takže som mohol mať hash kľúč, čo je téma ID. 1001 00:42:42,630 --> 00:42:46,650 A ja mohla mať rozsah kľúč, čo je ID odpoveď. 1002 00:42:46,650 --> 00:42:49,650 Tak, keď chcem, aby si všetky odpovede na určitú tému, 1003 00:42:49,650 --> 00:42:52,370 Môžem len dotaz hash. 1004 00:42:52,370 --> 00:42:55,190 Môžem len povedať, daj mi všetky položky, ktoré majú túto hash. 1005 00:42:55,190 --> 00:43:01,910 A budem sa dostať na každú otázku alebo poštou na túto konkrétnu tému. 1006 00:43:01,910 --> 00:43:03,910 Tieto špičkové úrovne agregácie sú veľmi dôležité. 1007 00:43:03,910 --> 00:43:07,370 Podporujú primárny prístup vzor žiadosti. 1008 00:43:07,370 --> 00:43:09,420 Všeobecne povedané, toto je to, čo chceme robiť. 1009 00:43:09,420 --> 00:43:11,780 Chceme, aby table-- ako si nahrať tabuľku, 1010 00:43:11,780 --> 00:43:16,640 chceme štruktúrovať dáta v tabuľke tak, 1011 00:43:16,640 --> 00:43:20,140 že aplikácia môže veľmi rýchlo získať tieto výsledky. 1012 00:43:20,140 --> 00:43:24,510 A často spôsob, ako to urobiť, je udržiavať tieto agregáciou ako my 1013 00:43:24,510 --> 00:43:25,650 vložiť dáta. 1014 00:43:25,650 --> 00:43:31,110 V podstate sme šírenia dát do jasného vedra, ako to prichádza v. 1015 00:43:31,110 --> 00:43:35,210 >> Rozsah tlačidlá umožňujú me-- hash Klávesy majú byť rovnosť. 1016 00:43:35,210 --> 00:43:39,490 Keď som dotazu hash, musím povedať, daj mi hash, ktorá sa rovná toto. 1017 00:43:39,490 --> 00:43:41,950 Keď som dotaz rozsah, ja Dá sa povedať, daj mi rozsah 1018 00:43:41,950 --> 00:43:47,040 že je použitie akejkoľvek bohatý subjekt, ktorý podporujeme. 1019 00:43:47,040 --> 00:43:49,200 Daj mi všetky položky pre hash. 1020 00:43:49,200 --> 00:43:52,520 Je to rovnaké, väčšie ako, menej ako, to začína, 1021 00:43:52,520 --> 00:43:54,145 to existujú medzi týmito dvoma hodnotami? 1022 00:43:54,145 --> 00:43:56,811 Takže tieto typy rozsahu otázok že máme vždy zaujíma. 1023 00:43:56,811 --> 00:43:59,650 A teraz jedna vec, o dátumoch, kedy sa pozriete na prístup k dátam, kedy 1024 00:43:59,650 --> 00:44:02,360 máte prístup k dátam, je to Vždy ide o agregáciu. 1025 00:44:02,360 --> 00:44:05,770 Je to vždy o záznamoch ktoré sa vzťahujú k tejto. 1026 00:44:05,770 --> 00:44:10,390 Dajte mi tu všetko that's-- všetky transakcie na tejto kreditnej karty 1027 00:44:10,390 --> 00:44:12,500 za posledný mesiac. 1028 00:44:12,500 --> 00:44:13,960 To je agregácie. 1029 00:44:13,960 --> 00:44:17,490 >> Takmer všetko, čo robíte v Databáza je nejaký druh agregácie. 1030 00:44:17,490 --> 00:44:21,530 Tak budú môcť byť schopní definovať Tieto vedierka a dá vám tieto rozsah 1031 00:44:21,530 --> 00:44:24,950 atribúty, aby bolo možné na dotaz na, tie bohaté otázok podporuje veľa, 1032 00:44:24,950 --> 00:44:27,165 mnoho, mnoho prístup k aplikáciám vzory. 1033 00:44:27,165 --> 00:44:30,990 1034 00:44:30,990 --> 00:44:35,000 >> Takže ďalšia vec, s krížikom robí je, že nám dáva mechanizmus 1035 00:44:35,000 --> 00:44:37,740 aby bolo možné rozšíriť dáta okolo. 1036 00:44:37,740 --> 00:44:40,390 Databáza NoSQL fungujú najlepšie keď sú dáta rovnomerne 1037 00:44:40,390 --> 00:44:41,740 distribuovaná po klastra. 1038 00:44:41,740 --> 00:44:44,530 1039 00:44:44,530 --> 00:44:47,050 Koľko ľudí pozná s algoritmy hash? 1040 00:44:47,050 --> 00:44:49,860 Keď poviem, že hash a hashing-- pretože je algoritmus hash 1041 00:44:49,860 --> 00:44:54,140 je spôsob, ako byť schopný generovať náhodná hodnota z akejkoľvek danej hodnoty. 1042 00:44:54,140 --> 00:44:59,300 Takže v tomto konkrétnom prípade hashovacie algoritmus prevádzkujeme je ND 5 na základe. 1043 00:44:59,300 --> 00:45:04,765 >> A ak mám ID, a to je môj krížikom, mám 1, 2, 3. 1044 00:45:04,765 --> 00:45:07,390 Keď spustím hash algoritmu, to bude, aby sa vrátil a povedal, 1045 00:45:07,390 --> 00:45:10,800 dobre 1 rovná 7B, 2 sa rovná 48, 3 sa rovná CD. 1046 00:45:10,800 --> 00:45:13,092 Sú rozšírili do celého kľúča priestoru. 1047 00:45:13,092 --> 00:45:14,050 A prečo to robíte? 1048 00:45:14,050 --> 00:45:17,120 Vzhľadom na to, že zabezpečí, že môžem dal záznamy cez viac uzlov. 1049 00:45:17,120 --> 00:45:19,574 >> Ak by som to robím postupne, 1, 2, 3. 1050 00:45:19,574 --> 00:45:21,990 A mám hash rozsah, ktorý prebieha v tomto konkrétnom prípade, 1051 00:45:21,990 --> 00:45:24,785 malý hash priestor, beží od 00 do FF, 1052 00:45:24,785 --> 00:45:27,951 potom záznamy sa chystáte prísť a oni sa chystáte ísť 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 Čo sa deje? 1055 00:45:31,800 --> 00:45:34,860 Každá vložka bude rovnakom uzla. 1056 00:45:34,860 --> 00:45:36,070 Vieš, čo tým myslím? 1057 00:45:36,070 --> 00:45:40,910 >> Pretože keď som sa rozdeliť priestor, a ja sa šíri cez tieto záznamy, 1058 00:45:40,910 --> 00:45:45,950 a oddiel ja, ja som chcel povedať, oddiel 1 má kľúčový priestor, 0 až 54. 1059 00:45:45,950 --> 00:45:47,720 Oddiel 2 je 55 až 89. 1060 00:45:47,720 --> 00:45:49,780 Oddiel 3 AA až FF. 1061 00:45:49,780 --> 00:45:53,740 Takže keď som pomocou lineárne zvyšovanie ID, môžete vidieť, čo sa deje. 1062 00:45:53,740 --> 00:45:57,410 1, 2, 3, 4, 5, 6, všetko až po 54. 1063 00:45:57,410 --> 00:46:00,030 Takže ako som zatĺkať záznamy do systému, 1064 00:46:00,030 --> 00:46:02,030 všetko skončí ísť do jedného uzla. 1065 00:46:02,030 --> 00:46:03,160 >> To nie je dobré. 1066 00:46:03,160 --> 00:46:04,820 To je antipattern. 1067 00:46:04,820 --> 00:46:08,760 V MongoDB majú tento problém ak nechcete použiť hash kľúč. 1068 00:46:08,760 --> 00:46:11,325 MongoDB vám dáva možnosť z hash hodnotu kľúča. 1069 00:46:11,325 --> 00:46:13,950 Vždy by ste mali urobiť, ak vy používate incrementing hash 1070 00:46:13,950 --> 00:46:17,380 Zadajte MongoDB, alebo budete pribil každý zápis do jedného uzla, 1071 00:46:17,380 --> 00:46:21,290 a budete obmedzujúce Váš zápis priepustnosť zle. 1072 00:46:21,290 --> 00:46:24,896 >> Divákov: Je to A9 169 v desiatkovej sústave? 1073 00:46:24,896 --> 00:46:28,450 >> RICK Houlihan: Jo, to je niekde okolo tam. 1074 00:46:28,450 --> 00:46:29,950 A9, ja neviem. 1075 00:46:29,950 --> 00:46:32,200 Musel by ste, aby mi binárne na desatinné kalkulačka. 1076 00:46:32,200 --> 00:46:34,237 Môj mozog nefunguje takto. 1077 00:46:34,237 --> 00:46:36,320 Divákov: Len rýchly jedným Vaše pripomienky Mongo. 1078 00:46:36,320 --> 00:46:39,530 Tak je objekt, ID, ktorý je dodávaný natívne s Mongo robiť, že? 1079 00:46:39,530 --> 00:46:40,179 1080 00:46:40,179 --> 00:46:41,470 RICK Houlihan: Má to urobiť? 1081 00:46:41,470 --> 00:46:42,970 Ak ho špecifikovať. 1082 00:46:42,970 --> 00:46:45,030 S MongoDB, máte možnosť. 1083 00:46:45,030 --> 00:46:48,930 Môžete specify-- každý dokument v MongoDB musí mať podčiarnik ID. 1084 00:46:48,930 --> 00:46:50,300 To je unikátny hodnota. 1085 00:46:50,300 --> 00:46:55,240 >> V MongoDB môžete zadať či hash, alebo nie. 1086 00:46:55,240 --> 00:46:56,490 Proste vám možnosť. 1087 00:46:56,490 --> 00:46:58,198 Ak viete, že je to náhodný, žiadny problém. 1088 00:46:58,198 --> 00:46:59,640 Nemusíte to robiť. 1089 00:46:59,640 --> 00:47:04,260 Ak viete, že to nie je náhodné, že to postupne, potom to hash. 1090 00:47:04,260 --> 00:47:06,880 >> Teraz vec, o zatrieďovanie, akonáhle sa hash 1091 00:47:06,880 --> 00:47:08,800 value-- a to je Prečo hash kľúče sú vždy 1092 00:47:08,800 --> 00:47:13,740 unikátnych otázok, pretože som sa zmenil je hodnota, teraz nemôžem urobiť dotaz rozsahu. 1093 00:47:13,740 --> 00:47:15,640 Nemôžem povedať, že je to medzi to či ono, 1094 00:47:15,640 --> 00:47:20,800 pretože hodnota hash nebude sa rovná skutočnej hodnoty. 1095 00:47:20,800 --> 00:47:24,570 Takže keď hash, že kľúč, je to len rovnosť. 1096 00:47:24,570 --> 00:47:28,700 To je dôvod, prečo v DynamoDB krížik otázky sú vždy len rovnosť. 1097 00:47:28,700 --> 00:47:32,090 1098 00:47:32,090 --> 00:47:34,700 >> Takže teraz v rozmedzí key-- keď som sa dodať, že rozsah kľúč, 1099 00:47:34,700 --> 00:47:38,180 tieto záznamy dôležité spektrum všetci prísť a oni sa ukladajú na rovnaký oddiel. 1100 00:47:38,180 --> 00:47:42,430 Tak oni sú veľmi rýchlo, ľahko načítať, pretože to je hash, 1101 00:47:42,430 --> 00:47:43,220 to je rad. 1102 00:47:43,220 --> 00:47:44,928 A vidíte všetko s rovnakou hash 1103 00:47:44,928 --> 00:47:48,550 je uložená na rovnakom oddielu priestoru. 1104 00:47:48,550 --> 00:47:53,889 Môžete použiť tento rozsah kľúč pomôcť lokalizovať dáta v blízkosti jeho rodičia. 1105 00:47:53,889 --> 00:47:55,180 Tak čo mám vlastne tu robíš? 1106 00:47:55,180 --> 00:47:57,320 To je jedným mnohých vzťahu. 1107 00:47:57,320 --> 00:48:01,490 Vzťah medzi krížik a rozsah kľúč je, kto veľa. 1108 00:48:01,490 --> 00:48:03,490 Môžem mať viac hash kľúčov. 1109 00:48:03,490 --> 00:48:07,610 Môžem mať len viac rozsah kľúče v každej krížik. 1110 00:48:07,610 --> 00:48:11,910 >> Hash definuje rodičia, rozsah definuje deti. 1111 00:48:11,910 --> 00:48:15,240 Takže môžete vidieť, že je analógový tu medzi relačné konštruktu 1112 00:48:15,240 --> 00:48:18,840 a rovnaké typy konštrukty v NoSQL. 1113 00:48:18,840 --> 00:48:20,760 Ľudia hovoria o NoSQL ako Nonrelational. 1114 00:48:20,760 --> 00:48:22,200 Nie je to Nonrelational. 1115 00:48:22,200 --> 00:48:24,680 Údaje má vždy vzťahy. 1116 00:48:24,680 --> 00:48:28,172 Tieto vzťahy len sú modelované inak. 1117 00:48:28,172 --> 00:48:29,880 Poďme hovoriť trochu niečo o trvanlivosť. 1118 00:48:29,880 --> 00:48:34,860 Pri písaní sa DynamoDB, píše sú vždy trojcestný replikované. 1119 00:48:34,860 --> 00:48:37,550 To znamená, že máme tri AZ je. 1120 00:48:37,550 --> 00:48:39,160 AZ to sú voľné zóny. 1121 00:48:39,160 --> 00:48:43,430 Môžete myslieť na dostupnosť Zone ako dátové centrum 1122 00:48:43,430 --> 00:48:45,447 alebo súbor dátových centier. 1123 00:48:45,447 --> 00:48:47,780 Tieto veci sú geograficky izolované od seba navzájom 1124 00:48:47,780 --> 00:48:51,610 naprieč rôznymi zlomové, naprieč odlišný rozvodnej siete a záplavových oblastí. 1125 00:48:51,610 --> 00:48:54,510 Zlyhanie v jednej AZ nie je bude trvať dole ďalšie. 1126 00:48:54,510 --> 00:48:56,890 Oni sú tiež spojené spolu s tmavým vláknom. 1127 00:48:56,890 --> 00:49:01,240 To podporuje jeden sub 1 milisekunda oneskorenie medzi AZS. 1128 00:49:01,240 --> 00:49:05,390 Takže dáta replikácie v reálnom čase schopné v bytových AZS. 1129 00:49:05,390 --> 00:49:09,990 >> A často multi nasadenie AZ spĺňali požiadavky na vysokú dostupnosť 1130 00:49:09,990 --> 00:49:12,930 väčšiny podnikových organizácií. 1131 00:49:12,930 --> 00:49:16,139 Takže DynamoDB sa šíri v troch AZS v predvolenom nastavení. 1132 00:49:16,139 --> 00:49:19,430 Budeme len k poznaniu Write keď sa dva z týchto troch uzlov vráti 1133 00:49:19,430 --> 00:49:21,470 a hovoria, Jo, mám to. 1134 00:49:21,470 --> 00:49:22,050 Prečo tomu tak je? 1135 00:49:22,050 --> 00:49:25,950 Vzhľadom k tomu, na čítanie stranu sme len dám vám dáta späť, ak 1136 00:49:25,950 --> 00:49:27,570 sme ho dostať z dvoch uzlov. 1137 00:49:27,570 --> 00:49:30,490 >> Ak som replikácie naprieč tri, a čítam z dvoch, 1138 00:49:30,490 --> 00:49:32,840 Ja som vždy zaručená mať aspoň jeden 1139 00:49:32,840 --> 00:49:35,720 z nich číta, že je Najaktuálnejšie kópie dát. 1140 00:49:35,720 --> 00:49:38,340 To je to, čo robí DynamoDB konzistentné. 1141 00:49:38,340 --> 00:49:42,450 Teraz si môžete vybrať otočiť tie konzistentné číta off. 1142 00:49:42,450 --> 00:49:45,070 V tom prípade budem hovoriť, Budem čítať iba z jedného uzla. 1143 00:49:45,070 --> 00:49:47,430 A nemôžem zaručiť, aby to bude byť najviac aktuálne dáta. 1144 00:49:47,430 --> 00:49:49,450 >> Takže ak write prichádza, to nebola replikované doteraz, 1145 00:49:49,450 --> 00:49:50,360 budete sa dostať, že kópia. 1146 00:49:50,360 --> 00:49:52,220 To je nakoniec konzistentné čítanie. 1147 00:49:52,220 --> 00:49:54,640 A čo to je, je polovicu nákladov. 1148 00:49:54,640 --> 00:49:56,140 Takže to je o čom premýšľať. 1149 00:49:56,140 --> 00:50:00,160 Keď čítate von DynamoDB, a je nastavovanie čítanie kapacity 1150 00:50:00,160 --> 00:50:04,430 jednotiek, ak sa rozhodnete nakoniec konzistentné číta, je to oveľa lacnejšie, 1151 00:50:04,430 --> 00:50:06,010 je to o polovicu nákladov. 1152 00:50:06,010 --> 00:50:09,342 >> A tak sa ušetrí peniaze. 1153 00:50:09,342 --> 00:50:10,300 Ale to je vaša voľba. 1154 00:50:10,300 --> 00:50:12,925 Ak chcete, konzistentné čítanie alebo nakoniec konzistentné čítanie. 1155 00:50:12,925 --> 00:50:15,720 To je niečo, čo si môžete vybrať. 1156 00:50:15,720 --> 00:50:17,659 >> Poďme sa baviť o indexoch. 1157 00:50:17,659 --> 00:50:19,450 Tak sme sa zmienili, že najvyššej úrovne agregácie. 1158 00:50:19,450 --> 00:50:23,720 Máme hash kľúče, a máme rozsah kľúče. 1159 00:50:23,720 --> 00:50:24,320 To je pekné. 1160 00:50:24,320 --> 00:50:26,950 A to je na primárnej tabuľky, ja má jedno krížikom, mám jeden rozsah kľúč. 1161 00:50:26,950 --> 00:50:27,783 >> Čo to znamená? 1162 00:50:27,783 --> 00:50:30,410 Mám jeden atribút, že som môže bežať bohaté otázky proti. 1163 00:50:30,410 --> 00:50:31,800 Je to rozsah kľúč. 1164 00:50:31,800 --> 00:50:35,530 Ostatné atribúty na tej item-- Môžem filtrovať na tých atribútoch. 1165 00:50:35,530 --> 00:50:40,050 Ale nemôžem robiť veci ako, to začína, alebo je väčšia ako. 1166 00:50:40,050 --> 00:50:40,820 >> Ako to mám urobiť? 1167 00:50:40,820 --> 00:50:42,860 Aj vytvoriť index. 1168 00:50:42,860 --> 00:50:45,340 Sú dva typy indexy v DynamoDB. 1169 00:50:45,340 --> 00:50:49,002 Index je naozaj Iný pohľad na tabuľky. 1170 00:50:49,002 --> 00:50:50,490 A miestne sekundárne index. 1171 00:50:50,490 --> 00:50:51,781 >> Prvý z nich budeme hovoriť. 1172 00:50:51,781 --> 00:50:57,740 Takže miestne pobočníci sa koexistovali na rovnakom oddielu ako dáta. 1173 00:50:57,740 --> 00:51:00,240 A ako také, sú na rovnaké fyzikálne uzol. 1174 00:51:00,240 --> 00:51:01,780 Oni sú to, čo nazývame konzistentné. 1175 00:51:01,780 --> 00:51:04,599 Význam, budú uznávať zápisu spolu s tabuľkou. 1176 00:51:04,599 --> 00:51:06,890 Pri zápise príde, budeme písať cez index. 1177 00:51:06,890 --> 00:51:09,306 Budeme písať až k stolu, a potom budeme potvrdiť. 1178 00:51:09,306 --> 00:51:10,490 Tak to je konzistentné. 1179 00:51:10,490 --> 00:51:13,174 Akonáhle je zápis bol uznala od stola, 1180 00:51:13,174 --> 00:51:15,090 je zaručené, že miestna sekundárne index 1181 00:51:15,090 --> 00:51:18,380 bude mať rovnakú víziu dát. 1182 00:51:18,380 --> 00:51:22,390 Ale to, čo vám umožní urobiť, je definovať alternatívne kľúče rozsah. 1183 00:51:22,390 --> 00:51:25,260 >> Musia používať rovnaký hash key ako primárny tabuľke, 1184 00:51:25,260 --> 00:51:29,050 preto, že sú umiestnené na rovnakom mieste na rovnaký oddiel, a sú konzistentné. 1185 00:51:29,050 --> 00:51:33,110 Ale môžem vytvoriť index s rôznymi kľúčmi dosahu. 1186 00:51:33,110 --> 00:51:41,590 Tak napríklad, ak som mal výrobca že mal časti tabuľky surové prichádzať. 1187 00:51:41,590 --> 00:51:44,590 A RAW diely dodávame v a oni sú agregované zostavou. 1188 00:51:44,590 --> 00:51:46,840 A možno je tu odvolanie. 1189 00:51:46,840 --> 00:51:50,240 >> Každá časť, ktorá bola vyrobená týmto Výrobca po tomto dátume, 1190 00:51:50,240 --> 00:51:52,840 Musím vytiahnuť z môjho linky. 1191 00:51:52,840 --> 00:51:55,950 Dokážem točiť index že bude hľadať, 1192 00:51:55,950 --> 00:52:00,760 agregáciu dňom Výroba tejto konkrétnej časti. 1193 00:52:00,760 --> 00:52:03,930 Takže ak môj stôl najvyššiu úroveň bola už klasifikované podľa výrobcu, 1194 00:52:03,930 --> 00:52:07,655 Možno to bolo usporiadané na čiastočný ID, ja Môžete vytvoriť index off tejto tabuľke 1195 00:52:07,655 --> 00:52:11,140 ako hash výrobcu a pohybovala na dáta výroby. 1196 00:52:11,140 --> 00:52:14,490 A takto by som mohol povedať, že čokoľvek bol vyrobený medzi týmito dátami, 1197 00:52:14,490 --> 00:52:16,804 Musím vytiahnuť z linky. 1198 00:52:16,804 --> 00:52:18,220 Tak to je miestna sekundárne index. 1199 00:52:18,220 --> 00:52:22,280 >> Tie majú za následok obmedziť svoju kľúčovú priestor hash. 1200 00:52:22,280 --> 00:52:24,360 Vzhľadom k tomu, že koexistovali na rovnakej úložné uzla, 1201 00:52:24,360 --> 00:52:26,860 obmedzujú s krížikom priestor na 10 GB. 1202 00:52:26,860 --> 00:52:28,950 DynamoDB, pod stoly, sa rozdelí 1203 00:52:28,950 --> 00:52:31,380 Váš stôl každých 10 gigabajtov. 1204 00:52:31,380 --> 00:52:34,760 Keď dáte 10 koncerty dát v, my go [PHH], a my sme pridať ďalšie uzol. 1205 00:52:34,760 --> 00:52:38,120 1206 00:52:38,120 --> 00:52:42,070 >> Nebudeme rozdeliť LSI cez viac oddielov. 1207 00:52:42,070 --> 00:52:43,200 Budeme rozdeliť tabuľku. 1208 00:52:43,200 --> 00:52:44,679 Ale nebudeme rozdeliť LSI. 1209 00:52:44,679 --> 00:52:46,470 Tak to je niečo, dôležité pochopiť 1210 00:52:46,470 --> 00:52:50,070 je, ak robíte veľa, veľmi, veľmi veľké zhluky, 1211 00:52:50,070 --> 00:52:53,860 potom ste bude obmedzený 10 GB na vašom LSIS. 1212 00:52:53,860 --> 00:52:56,640 >> Ak tomu tak je, môžeme použiť globálne Sekundárne. 1213 00:52:56,640 --> 00:52:58,630 Globálne secondaries sú Naozaj iné tabuľky. 1214 00:52:58,630 --> 00:53:01,720 Existujú úplne preč strana primárnej tabuľky. 1215 00:53:01,720 --> 00:53:04,680 A dovoľte mi, aby som nájsť úplne odlišná štruktúra. 1216 00:53:04,680 --> 00:53:08,010 Takže myslíte, že na to, ako sa vkladá údaje do dvoch rôznych tabuliek, štruktúrované 1217 00:53:08,010 --> 00:53:09,220 dvoma rôznymi spôsobmi. 1218 00:53:09,220 --> 00:53:11,360 >> Môžem definovať úplne iný krížikom. 1219 00:53:11,360 --> 00:53:13,490 Môžem definovať úplne iný kľúč rozsah. 1220 00:53:13,490 --> 00:53:15,941 A môžem bežať to úplne nezávisle na sebe. 1221 00:53:15,941 --> 00:53:18,190 Ako v skutočnosti, som dotovaný mojej čítanie kapacity 1222 00:53:18,190 --> 00:53:21,090 a písať kapacity pre moju globálne sekundárne indexy 1223 00:53:21,090 --> 00:53:24,240 úplne nezávisle môj primárny tabuľky. 1224 00:53:24,240 --> 00:53:26,640 Keby som ustanovujú tento index, poviem to, ako moc čítať a písať 1225 00:53:26,640 --> 00:53:28,610 Kapacita to bude používať. 1226 00:53:28,610 --> 00:53:31,490 >> A to je samostatná z môjho primárnej tabuľky. 1227 00:53:31,490 --> 00:53:35,240 Teraz obaja indexy nám umožňujú nielen definovať hash a rozsah kláves, 1228 00:53:35,240 --> 00:53:38,610 ale oni nám umožňujú premietať ďalšie hodnoty. 1229 00:53:38,610 --> 00:53:44,950 Takže ak chcem odpočítajte index, a chcem získať nejaké sadu dát, 1230 00:53:44,950 --> 00:53:48,327 Nepotrebujem sa vrátiť do hlavného Tabuľka získať ďalšie atribúty. 1231 00:53:48,327 --> 00:53:50,660 Aj môže premietať tie ďalšie atribútov do tabuľky 1232 00:53:50,660 --> 00:53:53,440 podporovať prístup vzor. 1233 00:53:53,440 --> 00:53:57,700 Viem, že sme asi dostať do niektorých Naozaj, really-- dostať do burinu 1234 00:53:57,700 --> 00:53:58,910 tu na niektoré z týchto vecí. 1235 00:53:58,910 --> 00:54:02,725 Teraz mám sa nechať unášať z toho. 1236 00:54:02,725 --> 00:54:07,320 >> Divákov: [Nepočuteľné] --table kľúč znamenalo, hash? 1237 00:54:07,320 --> 00:54:08,840 Pôvodný hash? 1238 00:54:08,840 --> 00:54:09,340 Multi-lamely? 1239 00:54:09,340 --> 00:54:10,200 >> RICK Houlihan: Áno. 1240 00:54:10,200 --> 00:54:11,070 Áno. 1241 00:54:11,070 --> 00:54:15,260 Tabuľka kľúč v podstate poukazuje späť do položky. 1242 00:54:15,260 --> 00:54:19,280 Tak že index je ukazovateľ späť do pôvodnej položky na stole. 1243 00:54:19,280 --> 00:54:22,910 Teraz si môžete vybrať vybudovať index, ktorý má len tabuľku kľúč, 1244 00:54:22,910 --> 00:54:24,840 a žiadne iné vlastnosti. 1245 00:54:24,840 --> 00:54:26,570 A prečo by som to robil? 1246 00:54:26,570 --> 00:54:28,570 No, možno mám veľmi veľké položky. 1247 00:54:28,570 --> 00:54:31,660 >> Naozaj len potrebujem vedieť which-- môj prístup vzor by sa povedať, 1248 00:54:31,660 --> 00:54:33,760 položky, ktoré obsahujú túto nehnuteľnosť? 1249 00:54:33,760 --> 00:54:35,780 Nepotrebujete vrátiť položku. 1250 00:54:35,780 --> 00:54:37,800 Proste potrebujem vedieť, položky, ktoré obsahujú to. 1251 00:54:37,800 --> 00:54:40,700 Takže si môžete vytvoriť indexy ktoré majú len tabuľku kľúč. 1252 00:54:40,700 --> 00:54:43,360 >> Ale to je v prvom rade to, čo index v databáze je pre. 1253 00:54:43,360 --> 00:54:46,280 Je to, že sú schopné rýchlo určiť, ktoré zaznamenáva, 1254 00:54:46,280 --> 00:54:49,470 ktoré riadky, ktoré položky v tabuľke majú 1255 00:54:49,470 --> 00:54:51,080 vlastnosti, ktoré som hľadali. 1256 00:54:51,080 --> 00:54:53,610 1257 00:54:53,610 --> 00:54:54,860 >> GSIS, tak ako fungujú? 1258 00:54:54,860 --> 00:54:58,340 GSIS v podstate sú asynchrónne. 1259 00:54:58,340 --> 00:55:02,570 Aktualizácia prichádza do tabuľky, Tabuľka je potom asynchrónne aktualizovaný 1260 00:55:02,570 --> 00:55:03,720 všetky vaše GSIS. 1261 00:55:03,720 --> 00:55:06,680 To je dôvod, prečo sú GSIS nakoniec konzistentné. 1262 00:55:06,680 --> 00:55:09,440 >> Je dôležité poznamenať, že keď staviate GSIS, 1263 00:55:09,440 --> 00:55:13,110 a pochopíte, budete vytvárať ďalší rozmer aggregation-- 1264 00:55:13,110 --> 00:55:16,594 Teraz povedzme, že dobrý príklad Tu je výrobca. 1265 00:55:16,594 --> 00:55:19,260 Myslím, že by som mohol mať hovoril o lekárske výrobcu zariadenia. 1266 00:55:19,260 --> 00:55:23,870 Výrobcovia Lekárske zariadenia častokrát majú Serializovaná časti. 1267 00:55:23,870 --> 00:55:28,070 Časti, ktoré idú do náhradné hip všetko 1268 00:55:28,070 --> 00:55:30,200 mať trochu sériové číslo na ne. 1269 00:55:30,200 --> 00:55:33,584 A oni mohli mať milióny a milióny a miliardy dielov 1270 00:55:33,584 --> 00:55:35,000 vo všetkých zariadeniach, ktoré sa loď. 1271 00:55:35,000 --> 00:55:37,440 No, oni potrebujú k agregáciu v rámci rôzne rozmery, všetky diely 1272 00:55:37,440 --> 00:55:39,520 v zostave, akékoľvek diely, ktoré boli vykonané 1273 00:55:39,520 --> 00:55:41,670 na určité línie, všetko časti, ktoré prišli 1274 00:55:41,670 --> 00:55:44,620 v od určitého výrobcu k určitému dátumu. 1275 00:55:44,620 --> 00:55:47,940 A tieto zhluky niekedy dostať až do miliárd. 1276 00:55:47,940 --> 00:55:50,550 >> Tak som sa pracovať s niektorými z títo ľudia, ktorí trpia 1277 00:55:50,550 --> 00:55:53,156 pretože sú vytváranie Tieto GINORMOUS agregácie 1278 00:55:53,156 --> 00:55:54,280 v ich sekundárnych indexov. 1279 00:55:54,280 --> 00:55:57,070 Môžu mať surové diely stôl, ktorý je dodávaný iba ako hash. 1280 00:55:57,070 --> 00:55:59,090 Každá časť má unikátne sériové číslo. 1281 00:55:59,090 --> 00:56:00,975 Ja používam sériové číslo ako hash. 1282 00:56:00,975 --> 00:56:01,600 Je to krásne. 1283 00:56:01,600 --> 00:56:04,160 Môj surové dáta tabuľky sa rozprestiera po celej kľúča priestoru. 1284 00:56:04,160 --> 00:56:05,930 My [? napísať?] [? Požitie?] Je úžasné. 1285 00:56:05,930 --> 00:56:07,876 Beriem veľké množstvo dát. 1286 00:56:07,876 --> 00:56:09,500 Potom to, čo robia, je, že vytvorí GSI. 1287 00:56:09,500 --> 00:56:12,666 A ja hovorím, vieš čo, musím vidieť Všetky diely pre tohto výrobcu. 1288 00:56:12,666 --> 00:56:15,060 No, zrazu som si pričom miliardy riadkov, 1289 00:56:15,060 --> 00:56:17,550 a tak je na jeden uzol, pretože keď 1290 00:56:17,550 --> 00:56:21,170 Aj agregovať ako Výrobca ID ako hash, 1291 00:56:21,170 --> 00:56:25,410 a číslo dielu ako oblasť, potom všetci naraz, že som 1292 00:56:25,410 --> 00:56:30,530 uvedenie miliardy diely do čoho Tento výrobca ma doručená. 1293 00:56:30,530 --> 00:56:34,447 >> To môže spôsobiť veľa tlaku na GSI, 1294 00:56:34,447 --> 00:56:36,030 znova, pretože som príklepom jeden uzol. 1295 00:56:36,030 --> 00:56:38,350 Dávam všetky tieto vloží do jedného uzla. 1296 00:56:38,350 --> 00:56:40,940 A to je skutočný problematický prípad použitia. 1297 00:56:40,940 --> 00:56:43,479 Teraz som dostal dobrý dizajn vzor pre to, ako sa vyhnúť to. 1298 00:56:43,479 --> 00:56:45,770 A to je jeden z problémov že som vždy pracovať. 1299 00:56:45,770 --> 00:56:49,590 Ale čo sa stane, je GSI môže Nie je dostatok zápisu kapacity 1300 00:56:49,590 --> 00:56:52,330 aby bolo možné posunúť všetky tie riadkov do jedného uzla. 1301 00:56:52,330 --> 00:56:55,390 A čo sa stane, potom je primárne, klient tabuľka, 1302 00:56:55,390 --> 00:57:00,180 primárnej tabuľke bude škrtil pretože GSI nemôže držať krok. 1303 00:57:00,180 --> 00:57:02,980 Takže môj vložka sadzba spadnúť na primárnej tabuľky 1304 00:57:02,980 --> 00:57:06,230 ako môj GSI snaží držať krok. 1305 00:57:06,230 --> 00:57:08,850 >> Dobre, takže GSI je, LSI je, ktorý z nich by som mal použiť? 1306 00:57:08,850 --> 00:57:12,290 LSI je byť konzistentné. 1307 00:57:12,290 --> 00:57:13,750 GSI to sú nakoniec konzistentné. 1308 00:57:13,750 --> 00:57:17,490 Ak to je v poriadku, odporúčam pomocou GSI, sú oveľa flexibilnejšie. 1309 00:57:17,490 --> 00:57:20,270 LSI môže byť modelovaná ako GSI. 1310 00:57:20,270 --> 00:57:27,040 A v prípade, že veľkosť dát na hash kľúčov vaša zbierka prekročí 10 gigabajtov, 1311 00:57:27,040 --> 00:57:31,050 potom budete chcieť použiť, že GSI, pretože je to len pevný limit. 1312 00:57:31,050 --> 00:57:32,035 >> Dobre, takže škálovanie. 1313 00:57:32,035 --> 00:57:35,210 1314 00:57:35,210 --> 00:57:37,460 Výkon v Dynamo DB, vy ustanovenia môže [nepočuteľných] 1315 00:57:37,460 --> 00:57:38,680 priepustnosť do tabuľky. 1316 00:57:38,680 --> 00:57:42,740 Máme zákazníkov, ktorí majú dotovaný 60 billion-- 1317 00:57:42,740 --> 00:57:45,970 robia 60 miliárd žiadostí, pravidelne beží na viac ako milión žiadostí 1318 00:57:45,970 --> 00:57:47,790 za sekundu na našich stoloch. 1319 00:57:47,790 --> 00:57:50,360 To fakt nie je teoretický limit, koľko 1320 00:57:50,360 --> 00:57:53,730 a ako rýchlo sa tabuľka je možné spustiť v Dynamo DB. 1321 00:57:53,730 --> 00:57:55,920 Tam sú niektoré mäkké limity na vašom účte 1322 00:57:55,920 --> 00:57:58,170 že sme dali tam tak že nemusíte zblázniť. 1323 00:57:58,170 --> 00:58:00,070 Ak chcete viac ako že, nie je problém. 1324 00:58:00,070 --> 00:58:00,820 Prišiel si povedzte nám. 1325 00:58:00,820 --> 00:58:02,810 Budeme zase až voličom. 1326 00:58:02,810 --> 00:58:08,210 >> Každý účet je obmedzená na určitej úrovni v každej službe, len kúsok od netopiera 1327 00:58:08,210 --> 00:58:11,920 takže ľudia nemajú zblázniť dostať sa do problémov. 1328 00:58:11,920 --> 00:58:12,840 Žiadny limit veľkosti. 1329 00:58:12,840 --> 00:58:14,940 Môžete dať ľubovoľný počet položiek na stole. 1330 00:58:14,940 --> 00:58:17,620 Veľkosť položky je obmedzená na 400 kB každý, 1331 00:58:17,620 --> 00:58:20,050 ktoré by boli položka sa atribúty. 1332 00:58:20,050 --> 00:58:24,200 Takže súčet všetkých atribútov je obmedzená na 400 kB. 1333 00:58:24,200 --> 00:58:27,300 A potom znova, máme ten malý LSI otázka 1334 00:58:27,300 --> 00:58:30,405 s 10 GB limitu na hash. 1335 00:58:30,405 --> 00:58:33,280 Publikum: malý počet, mi chýba to, čo mi hovoríte, že je-- 1336 00:58:33,280 --> 00:58:36,830 Publikum: Oh, 400kb je maximálna veľkosť za položku. 1337 00:58:36,830 --> 00:58:39,570 Takže položka má všetky atribúty. 1338 00:58:39,570 --> 00:58:43,950 Takže 400 k je celková veľkosť tejto položky, 400 kilobajtov. 1339 00:58:43,950 --> 00:58:46,170 Takže zo všetkých atribútov kombinované, všetky údaje 1340 00:58:46,170 --> 00:58:49,140 to je vo všetkých tých atribútoch, zrolované do celkovej veľkosti, 1341 00:58:49,140 --> 00:58:51,140 V súčasnej dobe dnes limit položka 400 k. 1342 00:58:51,140 --> 00:58:54,390 1343 00:58:54,390 --> 00:58:57,046 Takže znovu mierky, dosiahol cez rozdelenie. 1344 00:58:57,046 --> 00:58:58,920 Priepustnosť je dotovaný na úrovni tabuľky. 1345 00:58:58,920 --> 00:59:00,160 A je to naozaj dva gombíky. 1346 00:59:00,160 --> 00:59:02,400 Čítali sme kapacitu a písať kapacity. 1347 00:59:02,400 --> 00:59:05,530 >> To sú teda upravené nezávisle na sebe. 1348 00:59:05,530 --> 00:59:08,640 RCU meradlom prísne v súlade číta. 1349 00:59:08,640 --> 00:59:13,005 OK, takže ak ste hovoril chcem 1000 RCU to tie sú prísne konzistentné, 1350 00:59:13,005 --> 00:59:14,130 tie sú v súlade číta. 1351 00:59:14,130 --> 00:59:17,130 Keď poviete, chcem Eventuálne konzistentné číta, 1352 00:59:17,130 --> 00:59:19,402 môžete ustanovenia 1000 RCU je, budete 1353 00:59:19,402 --> 00:59:21,840 dostať 2.000 nakoniec konzistentné číta. 1354 00:59:21,840 --> 00:59:25,940 A polovičnú cenu pre tých, nakoniec spočíva v číta. 1355 00:59:25,940 --> 00:59:28,520 >> Opäť platí, upravené nezávisle na sebe. 1356 00:59:28,520 --> 00:59:32,900 A oni majú throughput-- Ak budete konzumovať 100% svojej diaľkovom ovládači, 1357 00:59:32,900 --> 00:59:35,960 vy nebudete mať dopad na dostupnosť vašich práv. 1358 00:59:35,960 --> 00:59:40,161 Takže sú úplne nezávisle na sebe. 1359 00:59:40,161 --> 00:59:43,160 Dobre, takže jedna z vecí, ktoré Zmienil som sa krátko bol škrtenia. 1360 00:59:43,160 --> 00:59:44,320 Škrtenia je zlé. 1361 00:59:44,320 --> 00:59:47,311 Škrtenia označuje zlý žiadne SQL. 1362 00:59:47,311 --> 00:59:50,310 Tam sú veci, ktoré môžeme urobiť, aby pomohla ste zmierniť škrtenia, ktoré vás 1363 00:59:50,310 --> 00:59:51,040 zažívajú. 1364 00:59:51,040 --> 00:59:53,240 Ale najlepším riešením je to, poďme 1365 00:59:53,240 --> 00:59:58,000 Pozrite sa na to, čo robíte, pretože tam je anti-vzor v hre tu. 1366 00:59:58,000 --> 01:00:02,140 >> Tieto veci, veci, ako je non-uniforme záťaže, horúce klávesy, horúce priečky. 1367 01:00:02,140 --> 01:00:06,210 Som biť konkrétny kľúčový priestor veľmi ťažké pre nejakého konkrétneho dôvodu. 1368 01:00:06,210 --> 01:00:07,080 Prečo to robím? 1369 01:00:07,080 --> 01:00:08,710 Poďme zistiť, že von. 1370 01:00:08,710 --> 01:00:10,427 Ja som miešanie mojej horúce dáta s dátami za studena. 1371 01:00:10,427 --> 01:00:12,510 Nechávam mojej tabuľky dostať obrovský, ale je to naozaj 1372 01:00:12,510 --> 01:00:15,970 iba niektoré podmnožinu dát to je naozaj pre mňa zaujímavé. 1373 01:00:15,970 --> 01:00:20,290 Takže pre dát protokolu, napríklad, veľa Zákazníci, dostanú dáta protokolu každý deň. 1374 01:00:20,290 --> 01:00:22,490 Majú obrovské množstvo dát protokolu. 1375 01:00:22,490 --> 01:00:25,940 >> Ak ste práve dumping všetkých, ktorí sa prihlasujú Dáta do jedného veľkého stola, v priebehu času 1376 01:00:25,940 --> 01:00:28,070 že tabuľka sa dostane masívne. 1377 01:00:28,070 --> 01:00:30,950 Ale ja som naozaj zaujíma len posledných 24 hodín, posledných sedem dní, 1378 01:00:30,950 --> 01:00:31,659 počas posledných 30 dní. 1379 01:00:31,659 --> 01:00:34,074 Bez ohľadu na časové okno že mám záujem pri hľadaní 1380 01:00:34,074 --> 01:00:37,010 Pre prípad, že mi vadí, alebo udalosť, ktorá je pre mňa zaujímavé, 1381 01:00:37,010 --> 01:00:39,540 to je jediná doba, okno, ktoré potrebujem. 1382 01:00:39,540 --> 01:00:42,470 Tak prečo som dávať 10 rokov v hodnote dát protokolu v tabuľke? 1383 01:00:42,470 --> 01:00:45,030 To, čo spôsobuje, že je tabuľka fragment. 1384 01:00:45,030 --> 01:00:45,880 >> To dostane obrovský. 1385 01:00:45,880 --> 01:00:48,340 To začne sa šíriť von cez tisícov uzlov. 1386 01:00:48,340 --> 01:00:51,380 A od tej doby svojej funkcii je tak nízka, že ste 1387 01:00:51,380 --> 01:00:54,090 v skutočnosti obmedzenie rýchlosti na každom jeden z týchto jednotlivých uzlov. 1388 01:00:54,090 --> 01:00:57,120 Takže poďme začať hľadať na to, ako máme vrátiť túto tabuľku cez. 1389 01:00:57,120 --> 01:01:01,502 Ako sa nám podarí, aby údaje o niečo lepšie sa vyhnúť týmto problémom. 1390 01:01:01,502 --> 01:01:02,710 A čo to vyzerá? 1391 01:01:02,710 --> 01:01:04,370 To je, čo to vyzerá. 1392 01:01:04,370 --> 01:01:06,790 To je to, čo zlé, NoSQL vyzerá. 1393 01:01:06,790 --> 01:01:07,830 >> Mám horúcu kláves tu. 1394 01:01:07,830 --> 01:01:10,246 Ak sa pozriete na strane tu, to všetko sú moje oddiely. 1395 01:01:10,246 --> 01:01:12,630 Dostal som 16 oddielov sem na tento konkrétny databázy. 1396 01:01:12,630 --> 01:01:13,630 Robíme to po celú dobu. 1397 01:01:13,630 --> 01:01:15,046 Bežím to pre zákazníkov všetkých čias. 1398 01:01:15,046 --> 01:01:16,550 Volá sa teplo mapa. 1399 01:01:16,550 --> 01:01:20,590 Teplo mapu mi hovorí, ako ste prístupu k kľúč priestor. 1400 01:01:20,590 --> 01:01:23,700 A čo to mi hovorí, je že tam je jeden konkrétny hash 1401 01:01:23,700 --> 01:01:26,330 že tento človek má rád strašne moc, pretože je 1402 01:01:26,330 --> 01:01:28,250 biť to naozaj, naozaj ťažké. 1403 01:01:28,250 --> 01:01:29,260 >> Takže modrá je pekná. 1404 01:01:29,260 --> 01:01:29,900 Máme radi modrú. 1405 01:01:29,900 --> 01:01:30,720 Nemáme radi červené. 1406 01:01:30,720 --> 01:01:33,120 Red, kde je tlak dostane až do výšky 100%. 1407 01:01:33,120 --> 01:01:35,560 100%, teraz si bude škrtil. 1408 01:01:35,560 --> 01:01:39,030 Takže kedykoľvek budete vidieť žiadne červené čiary, ako je tohle--, a nie je to len Dynamo DB-- 1409 01:01:39,030 --> 01:01:41,630 každá databáza NoSQL má tento problém. 1410 01:01:41,630 --> 01:01:44,640 Tam sú anti-vzory, ktoré môžu riadiť tieto typy podmienok. 1411 01:01:44,640 --> 01:01:49,070 Čo mám robiť, je, že som pracovať so zákazníkmi pre zmiernenie týchto podmienok. 1412 01:01:49,070 --> 01:01:51,840 >> A čo to vyzerá? 1413 01:01:51,840 --> 01:01:54,260 A to už je čo najviac z Dynamo DB priepustnosti, 1414 01:01:54,260 --> 01:01:56,176 ale je to naozaj dostať najviac z NoSQL. 1415 01:01:56,176 --> 01:01:58,740 To sa neobmedzuje iba na Dynamo. 1416 01:01:58,740 --> 01:02:02,050 To je definitely-- I pracoval v Mongo. 1417 01:02:02,050 --> 01:02:04,090 Som oboznámený s mnohými NoSQL platformách. 1418 01:02:04,090 --> 01:02:06,830 Každý, kto má tieto typy horúce kľúčových problémov. 1419 01:02:06,830 --> 01:02:10,320 Ak chcete získať čo najviac z akéhokoľvek NoSQL databázy, konkrétne Dynamo DB, 1420 01:02:10,320 --> 01:02:13,320 Ak chcete vytvoriť tabuľky kde hash kľúčovým prvkom má 1421 01:02:13,320 --> 01:02:18,590 veľké množstvo odlišných hodnôt, vysoký stupeň mohutnosť. 1422 01:02:18,590 --> 01:02:22,530 Pretože to znamená, že píšem na mnohých rôznych vedierka. 1423 01:02:22,530 --> 01:02:24,870 >> Čím viac som vedierka písomne, tým väčšia je pravdepodobnosť 1424 01:02:24,870 --> 01:02:29,100 Som šíriť túto záťaž zápisu alebo čítať zaťaženie sa cez viac uzlov, 1425 01:02:29,100 --> 01:02:33,560 tým je pravdepodobnejšie, som mať vysoký výkon na stole. 1426 01:02:33,560 --> 01:02:37,440 A potom chcem hodnoty, aby požiadala celkom rovnomerne v priebehu času 1427 01:02:37,440 --> 01:02:39,430 a jednotne náhodne ako je to možné. 1428 01:02:39,430 --> 01:02:42,410 No, to je celkom zaujímavé, pretože nemôžem 1429 01:02:42,410 --> 01:02:43,960 Ovládanie keď používatelia prídu. 1430 01:02:43,960 --> 01:02:47,645 Takže stačí povedať, ak budeme šíriť veci sa cez kľúča priestoru, 1431 01:02:47,645 --> 01:02:49,270 budeme pravdepodobne v lepšej forme. 1432 01:02:49,270 --> 01:02:51,522 >> Je tu určitá Množstvo čase dodania 1433 01:02:51,522 --> 01:02:53,230 že nejdeš Aby bolo možné kontrolu. 1434 01:02:53,230 --> 01:02:55,438 Ale to sú naozaj dva rozmery, ktoré máme, 1435 01:02:55,438 --> 01:02:58,800 priestor, prístup rovnomerne šírenie, čas, žiadosti 1436 01:02:58,800 --> 01:03:01,040 ktorí prichádzajú rovnomerne rozložené v čase. 1437 01:03:01,040 --> 01:03:03,110 A ak tí dvaja sú splnené podmienky, 1438 01:03:03,110 --> 01:03:05,610 potom je to to, čo to je vyzerať. 1439 01:03:05,610 --> 01:03:07,890 To je oveľa krajší. 1440 01:03:07,890 --> 01:03:08,890 Sme tu naozaj šťastný. 1441 01:03:08,890 --> 01:03:10,432 Máme veľmi rovnaký prístup vzor. 1442 01:03:10,432 --> 01:03:13,098 Jo, možno ste stále malý tlak tu a tam, 1443 01:03:13,098 --> 01:03:14,830 ale nič naozaj príliš rozsiahle. 1444 01:03:14,830 --> 01:03:17,660 Takže je to úžasné, koľkokrát, keď som sa pracovať so zákazníkmi, 1445 01:03:17,660 --> 01:03:20,670 že ako prvý graf s veľkým červeným bar a všetko, čo škaredé žltej je to 1446 01:03:20,670 --> 01:03:23,147 všade, sme si urobil s výkonom 1447 01:03:23,147 --> 01:03:24,980 po niekoľkých mesiacoch spätného architektúry, 1448 01:03:24,980 --> 01:03:28,050 Utekajú presne rovnaké pracovná záťaž na presne rovnakú záťažou. 1449 01:03:28,050 --> 01:03:30,140 A to je to, čo vyzerá to ako teraz. 1450 01:03:30,140 --> 01:03:36,600 Takže to, čo dostanete s NoSQL je Dáta schémy, ktorý je úplne 1451 01:03:36,600 --> 01:03:38,510 viazaná na vzorku prístup. 1452 01:03:38,510 --> 01:03:42,170 >> A môžete optimalizovať, že dáta schéma na podporu tohto prístupu vzor. 1453 01:03:42,170 --> 01:03:45,490 Ak nie, potom budete vidieť tie druhy problémov 1454 01:03:45,490 --> 01:03:46,710 s týmito horúcich kláves. 1455 01:03:46,710 --> 01:03:50,518 >> Divákov: No, nevyhnutne niektoré miesta sa bude teplejšie ako ostatné. 1456 01:03:50,518 --> 01:03:51,450 >> RICK Houlihan: Vždy. 1457 01:03:51,450 --> 01:03:51,960 Vždycky. 1458 01:03:51,960 --> 01:03:54,620 Jo, myslím, že je vždy je-- a znova, je tu 1459 01:03:54,620 --> 01:03:56,980 niektoré návrhové vzory sa dostaneme cez ktorý bude hovoriť o tom, ako sa vysporiadať 1460 01:03:56,980 --> 01:03:58,480 s týmito extra veľkými agregácie. 1461 01:03:58,480 --> 01:04:01,260 Myslím, že musím mať je, ako sme sa s nimi vysporiadať? 1462 01:04:01,260 --> 01:04:03,760 Mám celkom dobrý prípad použitia že budeme hovoriť o za to. 1463 01:04:03,760 --> 01:04:05,940 >> V poriadku, takže poďme hovoriť asi niektorí teraz zákazníci. 1464 01:04:05,940 --> 01:04:06,950 Títo chlapi sú AdRoll. 1465 01:04:06,950 --> 01:04:08,990 Ja neviem, či ste oboznámení s AdRoll. 1466 01:04:08,990 --> 01:04:10,781 Pravdepodobne ste vidieť veľa na prehliadači. 1467 01:04:10,781 --> 01:04:14,230 Sú ad re-targeting, sú najväčšie obchodné ad re-zacielenie 1468 01:04:14,230 --> 01:04:14,940 tam vonku. 1469 01:04:14,940 --> 01:04:17,792 Obvykle pravidelne prejsť 60 miliárd transakcií za deň. 1470 01:04:17,792 --> 01:04:20,000 Robia cez milión transakcií za sekundu. 1471 01:04:20,000 --> 01:04:22,660 Majú tam celkom jednoduchú tabuľku štruktúra, najrušnejšie tabuľky. 1472 01:04:22,660 --> 01:04:26,450 Je to v podstate len krížikom je cookie, 1473 01:04:26,450 --> 01:04:29,010 rozsah je demografický kategórie, a potom 1474 01:04:29,010 --> 01:04:31,220 Tretia atribút je skóre. 1475 01:04:31,220 --> 01:04:33,720 >> Takže máme všetci cookies náš prehliadač od týchto chalanov. 1476 01:04:33,720 --> 01:04:35,900 A keď idete na účasť obchodníka, 1477 01:04:35,900 --> 01:04:39,390 Oni v podstate skóre vás naprieč rôzne demografické kategórie. 1478 01:04:39,390 --> 01:04:42,070 Keď idete na webové stránky a Hovoríte, že chcete vidieť túto ad-- 1479 01:04:42,070 --> 01:04:44,920 alebo v podstate nemusíte hovoriť that-- ale keď idete na webových stránkach 1480 01:04:44,920 --> 01:04:47,550 hovoria, že chcete vidieť túto reklamu. 1481 01:04:47,550 --> 01:04:49,370 A oni idú dostať, že reklama AdRoll. 1482 01:04:49,370 --> 01:04:51,130 AdRoll vás pozrie sa na ich stolu. 1483 01:04:51,130 --> 01:04:52,115 Zistí, že je váš cookie. 1484 01:04:52,115 --> 01:04:53,990 Inzerenti rozprávanie im, chcem niekoho 1485 01:04:53,990 --> 01:04:58,632 kto je v strednom veku, 40-ročný muž, do športu. 1486 01:04:58,632 --> 01:05:01,590 A oni skóre vás v tých demografii a oni sa rozhodnú, či 1487 01:05:01,590 --> 01:05:02,740 že je to dobrý reklama pre vás. 1488 01:05:02,740 --> 01:05:10,330 >> Teraz majú SLA s ich poskytovateľov reklamné 1489 01:05:10,330 --> 01:05:14,510 poskytovať sub-10 milisekúnd Odozva na jednotlivých vyžiadanie. 1490 01:05:14,510 --> 01:05:16,090 Takže oni používate Dynamo DB pre toto. 1491 01:05:16,090 --> 01:05:18,131 Oni nás biť milión požiadaviek za sekundu. 1492 01:05:18,131 --> 01:05:21,120 Sú schopní robiť všetky svoje číselníkov, triedenie všetko údaje, 1493 01:05:21,120 --> 01:05:26,130 a dostať, že doplnok odkaz späť na ktorý inzerenta za menej ako 10 milisekúnd. 1494 01:05:26,130 --> 01:05:29,800 Je to naozaj celkom fenomenálne implementácia, ktoré majú. 1495 01:05:29,800 --> 01:05:36,210 >> Títo chalani actually-- sú tí chlapi. 1496 01:05:36,210 --> 01:05:38,010 Nie som si istý, či je to tých chlapov. 1497 01:05:38,010 --> 01:05:40,127 Môže byť týchto ľudí. 1498 01:05:40,127 --> 01:05:42,210 V podstate povedal us-- nie, ja si nemyslím, že to boli oni. 1499 01:05:42,210 --> 01:05:43,000 Myslím, že to bol niekto iný. 1500 01:05:43,000 --> 01:05:44,750 Pracoval som s zákazník, ktorý mi povedal, 1501 01:05:44,750 --> 01:05:47,040 že teraz, keď som šiel do Dynamo DB, sú 1502 01:05:47,040 --> 01:05:50,330 míňať viac peňazí na občerstvenie pre ich vývojový tím každý mesiac 1503 01:05:50,330 --> 01:05:52,886 než minú za svoje databázy. 1504 01:05:52,886 --> 01:05:54,760 Tak to ti dám Myšlienka úspor nákladov 1505 01:05:54,760 --> 01:05:57,889 že sa môžete dostať do Dynamo DB je obrovský. 1506 01:05:57,889 --> 01:05:59,430 Dobre, dropcam je iná spoločnosť. 1507 01:05:59,430 --> 01:06:02,138 Tieto chlap druh of-- ak si myslíte, internetového vecí, dropcam 1508 01:06:02,138 --> 01:06:05,150 je v podstate Internet Security videa. 1509 01:06:05,150 --> 01:06:06,660 Dáte svoj fotoaparát vonku. 1510 01:06:06,660 --> 01:06:08,180 Kamera má detektor pohybu. 1511 01:06:08,180 --> 01:06:10,290 Niekto príde, spúšťa štartovací bod. 1512 01:06:10,290 --> 01:06:13,540 Fotoaparát začne nahrávať na chvíľu až do nezistí žiadny pohyb ešte. 1513 01:06:13,540 --> 01:06:15,310 Kladie, že videá sa na internet. 1514 01:06:15,310 --> 01:06:19,800 >> Dropcam bola spoločnosť, ktorá je v podstate prešiel na Dynamo DB 1515 01:06:19,800 --> 01:06:22,200 pretože oni prežívali obrovské rastúce bolesti. 1516 01:06:22,200 --> 01:06:25,820 A to, čo nám povedali, Zrazu petabajtov dát. 1517 01:06:25,820 --> 01:06:28,070 Netušili, svoje služby by bol tak úspešný. 1518 01:06:28,070 --> 01:06:32,310 Viac ako YouTube video prichádzajúce je to, čo títo ľudia dostávajú. 1519 01:06:32,310 --> 01:06:36,780 Oni používajú DynamoDB sledovať všetky metadáta na všetkých svojich videa kľúčových bodoch. 1520 01:06:36,780 --> 01:06:40,282 >> Takže oni majú S3 vedierka, ktoré posúvajú Všetky binárne artefakty do. 1521 01:06:40,282 --> 01:06:41,990 A potom, že majú Dynamo DB záznamy, ktoré 1522 01:06:41,990 --> 01:06:44,070 poukazujú na tých ľudí, S3, tri objekty. 1523 01:06:44,070 --> 01:06:47,070 Keď sa treba pozrieť sa na video, oni vyhľadať záznam v Dynamo DB. 1524 01:06:47,070 --> 01:06:47,903 Oni kliknite na odkaz. 1525 01:06:47,903 --> 01:06:49,770 Oni strhnúť na video z S3. 1526 01:06:49,770 --> 01:06:51,590 Takže to je to trochu, ako to vyzerá. 1527 01:06:51,590 --> 01:06:53,580 A to je priamo z ich tímu. 1528 01:06:53,580 --> 01:06:56,010 >> Dynamo DB znižuje ich dodacia lehota pre video udalosti 1529 01:06:56,010 --> 01:06:57,590 od piatich do 10 sekúnd. 1530 01:06:57,590 --> 01:07:00,470 Vo svojom starom relačné obchode, oni používali musieť ísť a vykonať 1531 01:07:00,470 --> 01:07:03,780 viac zložité otázky k obrázku out, ktorá videa strhnúť, 1532 01:07:03,780 --> 01:07:06,690 do menej ako 50 milisekúnd. 1533 01:07:06,690 --> 01:07:08,990 Takže je to úžasné, úžasné, ako moc výkon 1534 01:07:08,990 --> 01:07:12,990 môžete získať, keď optimalizovať a ladíte podkladové databázy 1535 01:07:12,990 --> 01:07:15,110 podporovať prístup vzor. 1536 01:07:15,110 --> 01:07:20,500 Halfbrick, títo chlapci, čo to je, Fruit Ninja Myslím, že je ich vec. 1537 01:07:20,500 --> 01:07:22,590 Že všetky beží na Dynamo DB. 1538 01:07:22,590 --> 01:07:26,810 A títo ľudia, oni sú skvelý Vývojový tím, veľký rozvoj 1539 01:07:26,810 --> 01:07:27,670 obchod. 1540 01:07:27,670 --> 01:07:29,364 >> To nie je dobrý ops tím. 1541 01:07:29,364 --> 01:07:31,280 Nemali veľa prevádzkových prostriedkov. 1542 01:07:31,280 --> 01:07:33,940 Oni boli snaží sa snaží udržať ich aplikačnej infraštruktúry up 1543 01:07:33,940 --> 01:07:34,290 a beží. 1544 01:07:34,290 --> 01:07:35,000 Prišli k nám. 1545 01:07:35,000 --> 01:07:36,251 Pozerali sa na tomto Dynamo DB. 1546 01:07:36,251 --> 01:07:37,291 Hovorili, že je to pre nás. 1547 01:07:37,291 --> 01:07:39,470 Oni stavali ich celok aplikačný framework na to. 1548 01:07:39,470 --> 01:07:43,640 Niektoré naozaj pekné komentáre tu z tímu na ich schopnosti 1549 01:07:43,640 --> 01:07:46,800 sa teraz zameriavajú na budovanie hra a nie 1550 01:07:46,800 --> 01:07:49,010 nutnosti udržanie infraštruktúra, ktorá 1551 01:07:49,010 --> 01:07:51,910 stal sa obrovské množstvo réžia pre ich tím. 1552 01:07:51,910 --> 01:07:56,170 Takže to je niečo, čo that-- úžitok, že dostanete od Dynamo DB. 1553 01:07:56,170 --> 01:08:00,930 >> Dobre, ako sa dostať do modelovanie dát tu. 1554 01:08:00,930 --> 01:08:03,440 A hovorili sme trochu o to jedna ku jednej, kto veľa, 1555 01:08:03,440 --> 01:08:05,060 a mnoho mnoho vzťahov typu. 1556 01:08:05,060 --> 01:08:07,630 A ako si udržať tie v Dynamu. 1557 01:08:07,630 --> 01:08:10,500 V Dynamo DB používame indexy, všeobecne povedané, 1558 01:08:10,500 --> 01:08:12,910 k otáčaniu dáta z jednu príchuť do druhej. 1559 01:08:12,910 --> 01:08:15,210 Hash kľúče, rozsah kľúče a indexy. 1560 01:08:15,210 --> 01:08:18,540 >> V tomto konkrétnom Napríklad, ako je väčšine štátov 1561 01:08:18,540 --> 01:08:23,802 majú požiadavku licenciu, ktorá iba jeden vodičský preukaz na osobu. 1562 01:08:23,802 --> 01:08:26,510 Nemôžete ísť do dostať vodiča dvoch je licencií v štáte Bostone. 1563 01:08:26,510 --> 01:08:27,500 Nemôžem to urobiť v Texase. 1564 01:08:27,500 --> 01:08:28,708 Je to niečo, ako to je. 1565 01:08:28,708 --> 01:08:32,779 A tak na DMV, máme vyhľadávanie, my Chcete sa pozrieť na vodiča licenciu 1566 01:08:32,779 --> 01:08:35,180 počtom sociálneho zabezpečenia. 1567 01:08:35,180 --> 01:08:39,990 Chcem sa pozrieť do podrobnosti užívateľa licenčné číslo vodiča. 1568 01:08:39,990 --> 01:08:43,620 >> Takže by sme mohli mať tabuľku užívateľa, že Má hash kľúč na sériové číslo, 1569 01:08:43,620 --> 01:08:47,830 alebo číslo sociálneho zabezpečenia, a rôzne atribúty definované na položku. 1570 01:08:47,830 --> 01:08:49,859 Teraz na tejto tabuľke I by mohlo definovať, ktorý GSI 1571 01:08:49,859 --> 01:08:53,370 vyletí, že okolo toho hovorí, že chcem, hash kľúč na licenciu a potom 1572 01:08:53,370 --> 01:08:54,252 všetky ostatné položky. 1573 01:08:54,252 --> 01:08:57,210 A teraz, keď chcem, aby otázka a nájsť licenčné číslo pre danú sociálnu 1574 01:08:57,210 --> 01:08:59,609 Bezpečnostné číslo, môžem dotaz na hlavnej tabuľky. 1575 01:08:59,609 --> 01:09:02,130 >> Ak chcem, aby otázka a ja chcem dostať sociálneho zabezpečenia 1576 01:09:02,130 --> 01:09:05,735 číslo alebo iné atribúty tavnou licenčné číslo, môžem dotaz GSI. 1577 01:09:05,735 --> 01:09:08,689 Tento model je, že jeden do jedného vzťahu. 1578 01:09:08,689 --> 01:09:12,460 Len veľmi jednoduchý GSI, otočiť tie veci okolo seba. 1579 01:09:12,460 --> 01:09:13,979 Teraz, hovoriť o tom, kto veľa. 1580 01:09:13,979 --> 01:09:16,450 Jedným z mnohých je v zásade Váš hash rozsah kľúč. 1581 01:09:16,450 --> 01:09:20,510 Tam, kde sme si veľa s týmto use case sú dáta monitora. 1582 01:09:20,510 --> 01:09:23,880 Dáta Monitor je dodávaný v pravidelnej interval, ako je internet vecí. 1583 01:09:23,880 --> 01:09:26,890 Vždy sme si všetky tieto Záznamy prichádza po celú dobu. 1584 01:09:26,890 --> 01:09:31,420 >> A ja chcem nájsť všetky údaje medzi konkrétne časové obdobie. 1585 01:09:31,420 --> 01:09:34,220 Je to veľmi časté dotazu monitoring infraštruktúry. 1586 01:09:34,220 --> 01:09:38,430 Spôsob, akým ísť o to je nájsť jednoduchá štruktúra tabuľky, jedna tabuľka. 1587 01:09:38,430 --> 01:09:42,250 Mám tabuľku mier zariadení s krížikom na ID zariadenia. 1588 01:09:42,250 --> 01:09:47,340 A mám rozsah kľúč na strane timestamp, alebo v tomto prípade, epos. 1589 01:09:47,340 --> 01:09:50,350 A to mi umožňuje vykonávať zložité otázky voči ktoré siahajú kľúče 1590 01:09:50,350 --> 01:09:54,950 a vrátiť tie záznamy, ktoré sú vztiahnuté k výsledku 1591 01:09:54,950 --> 01:09:56,310 nastaviť, že som hľadal. 1592 01:09:56,310 --> 01:09:58,360 A to, že jeden buduje mnohých vzťah 1593 01:09:58,360 --> 01:10:02,340 do primárnej tabuľky pomocou krížikom, rozsah kľúčová štruktúra. 1594 01:10:02,340 --> 01:10:04,600 >> Takže to trochu postavený do tabuľky v Dynamo DB. 1595 01:10:04,600 --> 01:10:07,290 Keď som sa definovať hash a rozsah t stôl, ja som 1596 01:10:07,290 --> 01:10:09,240 definovanie jedného na mnohé vzťah. 1597 01:10:09,240 --> 01:10:12,770 Je to vzťah rodič-dieťa. 1598 01:10:12,770 --> 01:10:14,620 >> Poďme sa baviť o mnoho mnohých vzťahov. 1599 01:10:14,620 --> 01:10:19,170 A pre tento konkrétny príklad, znova, budeme používať GSI je. 1600 01:10:19,170 --> 01:10:23,500 A poďme hovoriť o hranie scenár, kde mám daného užívateľa. 1601 01:10:23,500 --> 01:10:26,500 Chcem zistiť všetky hry, ktoré on je zapísaná pre alebo hranie v. 1602 01:10:26,500 --> 01:10:29,600 A pre danú hru, ja Chcete nájsť všetkých užívateľov. 1603 01:10:29,600 --> 01:10:31,010 Tak ako to mám urobiť? 1604 01:10:31,010 --> 01:10:34,330 Môj užívateľský hry stôl, idem mať hash kľúč ID užívateľa 1605 01:10:34,330 --> 01:10:35,810 a rozsah kľúč hry. 1606 01:10:35,810 --> 01:10:37,810 >> Užívateľ teda môže mať viac hier. 1607 01:10:37,810 --> 01:10:41,380 Je to, kto mnohých vzťah medzi Používateľ a hry hrá. 1608 01:10:41,380 --> 01:10:43,410 A potom na GSI, Budem preklopiť, že okolo. 1609 01:10:43,410 --> 01:10:46,679 Budem hash na hru a Budem sa pohybujú na užívateľa. 1610 01:10:46,679 --> 01:10:48,970 Takže ak chcem, aby si všetky Hra používateľa hrá v, 1611 01:10:48,970 --> 01:10:49,950 Budem dotaz hlavnej tabuľky. 1612 01:10:49,950 --> 01:10:52,699 Ak chcem, aby si všetky užívateľa ktoré hrajú určitú hru, 1613 01:10:52,699 --> 01:10:53,887 Ja dotaz GSI. 1614 01:10:53,887 --> 01:10:54,970 Tak vidíte, ako to urobíme? 1615 01:10:54,970 --> 01:10:58,369 Staviate na podporu týchto GSI je prípad použitia, aplikácie, prístup 1616 01:10:58,369 --> 01:10:59,410 vzor, ​​žiadosť. 1617 01:10:59,410 --> 01:11:01,440 >> Ak je potreba, aby na dotaz táto dimenzia, nech 1618 01:11:01,440 --> 01:11:03,500 me vytvoriť index na tejto dimenzii. 1619 01:11:03,500 --> 01:11:05,850 Ak nemám, je mi to jedno. 1620 01:11:05,850 --> 01:11:09,060 A v závislosti na use case, ja môže potrebovať indexu, alebo ja tiež nie. 1621 01:11:09,060 --> 01:11:12,390 Ak je to jednoduchý pre mnohých, primárnej tabuľky je v poriadku. 1622 01:11:12,390 --> 01:11:15,860 Ak je potreba, aby sa tieto mnoho Veľa je, alebo musím urobiť jeden až tých, 1623 01:11:15,860 --> 01:11:18,390 potom možno Ja potrebujem na druhé miesto index. 1624 01:11:18,390 --> 01:11:20,840 Takže to všetko závisí na tom, čo sa snažím robiť 1625 01:11:20,840 --> 01:11:24,550 a to, čo sa snažím dostať dokonalý. 1626 01:11:24,550 --> 01:11:28,000 >> Asi nebudem tráviť moc veľa času hovorí o dokumentoch. 1627 01:11:28,000 --> 01:11:31,460 To dostane trochu, pravdepodobne, hlbšie, než musíme ísť do. 1628 01:11:31,460 --> 01:11:33,710 Hovorme trochu o bohatý výraz dotazu. 1629 01:11:33,710 --> 01:11:37,831 Takže Dynamo DB máme schopnosť vytvoriť 1630 01:11:37,831 --> 01:11:39,330 to, čomu hovoríme projekcie výrazy. 1631 01:11:39,330 --> 01:11:42,660 Projekčné výrazy sú jednoducho vyberanie poľa alebo hodnôt 1632 01:11:42,660 --> 01:11:44,290 ktoré chcete zobraziť. 1633 01:11:44,290 --> 01:11:46,000 OK, tak som urobiť výber. 1634 01:11:46,000 --> 01:11:48,010 Robím dotazu proti Dynamo DB. 1635 01:11:48,010 --> 01:11:51,730 A ja hovorím, vieš čo, show len mi päť hviezd recenzia 1636 01:11:51,730 --> 01:11:54,544 pre tento konkrétny výrobok. 1637 01:11:54,544 --> 01:11:55,710 Tak to je všetko, čo chcem vidieť. 1638 01:11:55,710 --> 01:11:57,320 Nechcem vidieť všetky ďalšie atribúty riadku, 1639 01:11:57,320 --> 01:11:58,319 Len chcem vidieť. 1640 01:11:58,319 --> 01:12:01,209 Je to ako v SQL, keď ste hovoria, vyberte hviezdy alebo z tabuľky, 1641 01:12:01,209 --> 01:12:02,000 dostanete všetko. 1642 01:12:02,000 --> 01:12:05,450 Keď hovorím, vyberte meno zo stôl, len som si jeden atribút. 1643 01:12:05,450 --> 01:12:09,070 Je to rovnaký druh veci v Dynamo DB alebo iný databáz NoSQL. 1644 01:12:09,070 --> 01:12:14,510 Filter výrazy mi dovoľte, aby som sa v podstate znížiť sadu výsledkov nadol. 1645 01:12:14,510 --> 01:12:15,540 Tak som sa, aby sa dotaz. 1646 01:12:15,540 --> 01:12:17,260 Dotaz môže vrátiť s 500 položkami. 1647 01:12:17,260 --> 01:12:20,255 Ale ja som len chcú, aby položky, ktoré majú atribút, ktorý hovorí, že tento. 1648 01:12:20,255 --> 01:12:23,380 OK, takže poďme odfiltrovať tie položky, ktoré sa nezhodujú, že konkrétne dotaz. 1649 01:12:23,380 --> 01:12:25,540 Takže máme výrazy filtra. 1650 01:12:25,540 --> 01:12:28,310 >> Filter výrazy môžu je možné spustiť na každom atribútu. 1651 01:12:28,310 --> 01:12:30,260 Sú to nebude páčiť rozsah otázky. 1652 01:12:30,260 --> 01:12:32,690 Vyvolávajú otázky sú viac selektívne. 1653 01:12:32,690 --> 01:12:36,470 Filter otázky vyžadujú, aby som šiel Získajte Kompletné výsledky nastaviť a potom 1654 01:12:36,470 --> 01:12:39,170 vybojovať dáta nechcem. 1655 01:12:39,170 --> 01:12:40,660 Prečo je to dôležité? 1656 01:12:40,660 --> 01:12:42,770 Vzhľadom k tomu, Čítal som to všetko. 1657 01:12:42,770 --> 01:12:46,597 V dotazu, budem čítať a že to bude obrovský o dátach. 1658 01:12:46,597 --> 01:12:48,430 A potom budem vybojovať čo potrebujem. 1659 01:12:48,430 --> 01:12:52,080 A keď ja som len vybojovať pár riadkov, potom je to v poriadku. 1660 01:12:52,080 --> 01:12:53,620 Nie je to tak neefektívne. 1661 01:12:53,620 --> 01:12:57,800 >> Ale keď som čítal celú hromadu Údaje, len aby vybojovať jednu položku, 1662 01:12:57,800 --> 01:13:01,490 Potom som sa chystám byť lepší vypnúť pomocou dotazu rozsah, 1663 01:13:01,490 --> 01:13:03,030 pretože je to oveľa vyberavejšie. 1664 01:13:03,030 --> 01:13:06,330 Bude to mi ušetriť veľa peniaze, pretože som za to zaplatiť čítanie. 1665 01:13:06,330 --> 01:13:10,430 V prípade, že výsledky, ktoré prichádza späť kríž, že drôt môže byť nižšia, 1666 01:13:10,430 --> 01:13:11,890 ale ja som platiť za čítanie. 1667 01:13:11,890 --> 01:13:14,340 Tak pochopiť, ako ste dostať dáta. 1668 01:13:14,340 --> 01:13:16,420 To je veľmi dôležité v Dynamo DB. 1669 01:13:16,420 --> 01:13:19,710 >> Podmienené výrazy, to je to, čo by sa dalo nazvať optimistické uzamykanie. 1670 01:13:19,710 --> 01:13:28,470 Aktualizáciu, ak existuje, alebo ak je táto hodnota je ekvivalentná tomu, čo som špecifikovať. 1671 01:13:28,470 --> 01:13:31,494 A keď mám časovú pečiatku na rekord, mohol by som čítať dáta. 1672 01:13:31,494 --> 01:13:32,535 I sa môže zmeniť, že dáta. 1673 01:13:32,535 --> 01:13:35,030 Mohol by som ísť písať, že dáta späť do databázy. 1674 01:13:35,030 --> 01:13:38,100 Ak niekto zmenil záznam, časovú pečiatku mohli zmeniť. 1675 01:13:38,100 --> 01:13:40,370 A takto môj podmienenej Aktualizácia by sa povedať aktualizácia 1676 01:13:40,370 --> 01:13:42,340 v prípade, že sa rovná tejto časovú pečiatku. 1677 01:13:42,340 --> 01:13:46,290 Alebo aktualizácie zlyhá, pretože niekto aktualizované záznam v medziobdobí. 1678 01:13:46,290 --> 01:13:48,290 >> To je to, čo nazývame optimistické uzamykanie. 1679 01:13:48,290 --> 01:13:50,670 To znamená, že niekto môže prísť a zmeniť to, 1680 01:13:50,670 --> 01:13:53,100 a budem detekovať keď som sa vrátiť do písať. 1681 01:13:53,100 --> 01:13:56,106 A potom som si skutočne čítal, že dát a hovoria, ach, on zmenil to. 1682 01:13:56,106 --> 01:13:57,230 Potrebujem účet za to. 1683 01:13:57,230 --> 01:14:00,490 A môžem zmeniť údaje v mojom nahrať a aplikovať ďalšiu aktualizáciu. 1684 01:14:00,490 --> 01:14:04,330 Takže si môžete chytiť tie prírastkové Aktualizácie, ktoré sa vyskytujú v čase medzi 1685 01:14:04,330 --> 01:14:08,740 že budete čítať dáta a Čas môžete zapísať dáta. 1686 01:14:08,740 --> 01:14:11,520 >> Divákov: A filter Výraz vlastne znamená nie 1687 01:14:11,520 --> 01:14:13,020 v počte alebo ne-- 1688 01:14:13,020 --> 01:14:14,316 >> [Vložením hlasy] 1689 01:14:14,316 --> 01:14:16,232 RICK Houlihan: Nebudem príliš veľa na to. 1690 01:14:16,232 --> 01:14:17,700 To je rezervované kľúčové slovo. 1691 01:14:17,700 --> 01:14:20,130 Pohľad libra je vyhradené kľúčové slovo v Dynamo DB. 1692 01:14:20,130 --> 01:14:24,500 Každá databáza má svoje vlastné vyhradené Mená pre vymáhanie pohľadávok nemožno použiť. 1693 01:14:24,500 --> 01:14:27,240 Dynamo DB, ak zadáte libru pred touto, 1694 01:14:27,240 --> 01:14:29,310 môžete definovať tieto názvy hore. 1695 01:14:29,310 --> 01:14:31,840 Toto je odkazované hodnota. 1696 01:14:31,840 --> 01:14:34,880 Je to asi nie je najlepší syntax majú tam pre túto diskusiu, 1697 01:14:34,880 --> 01:14:38,090 preto, že sa dostane do niektorých real-- Bol by som hovoril viac 1698 01:14:38,090 --> 01:14:41,360 o, že na hlbšej úrovni. 1699 01:14:41,360 --> 01:14:46,130 >> Ale stačí povedať, mohlo by to byť dotaz skenovať, kde views-- 1700 01:14:46,130 --> 01:14:50,190 ani názory libra je väčší ako 10. 1701 01:14:50,190 --> 01:14:54,660 Je to číselná hodnota, áno. 1702 01:14:54,660 --> 01:14:57,322 Ak chcete, môžeme hovoriť o že po diskusii. 1703 01:14:57,322 --> 01:15:00,030 Dobre, takže sa dostávame do niektoré scenáre v osvedčených postupoch 1704 01:15:00,030 --> 01:15:02,000 kam ideme hovoriť o niektorých aplikácií tu. 1705 01:15:02,000 --> 01:15:03,810 Aké sú prípady použitia pre Dynamo DB. 1706 01:15:03,810 --> 01:15:06,120 Aké sú konštrukcie vzory v Dynamo DB. 1707 01:15:06,120 --> 01:15:09,110 >> A prvý, kto budeme hovoriť o je internet vecí. 1708 01:15:09,110 --> 01:15:15,010 Tak sme si veľa of-- myslím, čo je to-- viac ako 50% 1709 01:15:15,010 --> 01:15:19,370 prevádzky na internete v týchto dňoch je skutočne vyrobenej pomocou strojov, 1710 01:15:19,370 --> 01:15:21,930 automatizované procesy, ktoré nie sú ľuďmi. 1711 01:15:21,930 --> 01:15:25,140 Mám na mysli túto vec túto vec, ktorá sa budete nosiť vo vrecku, 1712 01:15:25,140 --> 01:15:28,840 koľko dát, ktorá je tá vec vlastne posiela okolo bez teba 1713 01:15:28,840 --> 01:15:30,550 s vedomím, že je úplne úžasné. 1714 01:15:30,550 --> 01:15:34,970 Vaša poloha, informácie o tom, ako rýchlo sa budete. 1715 01:15:34,970 --> 01:15:38,400 Ako myslíš, že Google Maps diela keď tí, čo je prevádzka. 1716 01:15:38,400 --> 01:15:41,275 Je to preto, že tam sú milióny a milióny ľudí jazdí po 1717 01:15:41,275 --> 01:15:44,667 s telefónmi, ktoré sú odosielanie Údaje celé miesto po celú dobu. 1718 01:15:44,667 --> 01:15:46,500 Takže jedna z vecí o údaje tohto druhu 1719 01:15:46,500 --> 01:15:50,980 že príde, údaje prístroja, prihláste údaje, časové rady, je, že je 1720 01:15:50,980 --> 01:15:53,540 zvyčajne len zaujímavý na trochu času. 1721 01:15:53,540 --> 01:15:55,580 Po uplynutí tejto doby, to je nie je tak zaujímavé. 1722 01:15:55,580 --> 01:15:58,390 Tak sme hovorili o, nenechajte tieto tabuľky rast bez hraníc. 1723 01:15:58,390 --> 01:16:03,410 Myšlienka je, že možno mám 24 hodiny v hodnote udalostí v mojej horúcej tabuľke. 1724 01:16:03,410 --> 01:16:06,160 A to horúci tabuľka bude opravná položka vo veľmi vysokej rýchlosti, 1725 01:16:06,160 --> 01:16:07,950 pretože to trvá veľa dát. 1726 01:16:07,950 --> 01:16:10,920 Trvá to veľké množstvo dát a ja som to čítal veľa. 1727 01:16:10,920 --> 01:16:14,560 Mám veľa prevádzky Otázky spustené voči tejto dát. 1728 01:16:14,560 --> 01:16:18,120 >> Po 24 hodinách, hej, ty Vieš čo, je mi to jedno. 1729 01:16:18,120 --> 01:16:21,150 Takže možno každý Aj role polnoci môj stôl sa k novej tabuľky 1730 01:16:21,150 --> 01:16:22,430 a ja deprovision túto tabuľku. 1731 01:16:22,430 --> 01:16:26,440 A ja si vezmem RCU je a WCU je dole, pretože o 24 hodín neskôr 1732 01:16:26,440 --> 01:16:28,630 Nie som beží toľko otázky voči týmto údajom. 1733 01:16:28,630 --> 01:16:30,200 Takže budem sporiť. 1734 01:16:30,200 --> 01:16:32,940 A možno 30 dní neskôr, vôbec sa mi nepáči ani potreba sa starať o to všetko. 1735 01:16:32,940 --> 01:16:35,020 Mohol by som vziať WCU je celú cestu dole na jeden, 1736 01:16:35,020 --> 01:16:36,990 preto, že viete, čo je to nikdy dostať zapisovať. 1737 01:16:36,990 --> 01:16:38,300 Dáta sú 30 dní stará. 1738 01:16:38,300 --> 01:16:40,000 To sa nikdy nezmení. 1739 01:16:40,000 --> 01:16:44,200 >> A to takmer nikdy dostane čítať, tak nech to jednoducho prijať, že RCU až 10. 1740 01:16:44,200 --> 01:16:49,372 A Šetrím tony peňazí na to Dáta, a to len platiť za moje horúce dát. 1741 01:16:49,372 --> 01:16:52,330 Tak to je dôležité sa pozrieť u, keď sa pozriete na časové rady 1742 01:16:52,330 --> 01:16:54,716 Dáta prichádzať v objeme. 1743 01:16:54,716 --> 01:16:55,590 Sú to stratégie. 1744 01:16:55,590 --> 01:16:58,010 Teraz som mohol len nechať to všetci do jedného stola 1745 01:16:58,010 --> 01:16:59,461 a nechať že tabuľka rast. 1746 01:16:59,461 --> 01:17:01,460 Nakoniec budem pozri problémy s výkonom. 1747 01:17:01,460 --> 01:17:04,060 Budem musieť začať do archívu niektoré z týchto dát mimo stôl, 1748 01:17:04,060 --> 01:17:04,720 čo nie. 1749 01:17:04,720 --> 01:17:07,010 >> Poďme oveľa lepšie navrhnite aplikácii 1750 01:17:07,010 --> 01:17:08,900 takže môžete ovládať týmto spôsobom pravdu. 1751 01:17:08,900 --> 01:17:11,460 Takže je to len automatické v kóde aplikácie. 1752 01:17:11,460 --> 01:17:13,580 O polnoci každý večer to valí tabuľku. 1753 01:17:13,580 --> 01:17:17,170 Možno, že to, čo potrebujete, je posuvná Okno 24 hodín dát. 1754 01:17:17,170 --> 01:17:20,277 Potom sa pravidelne, že som volať dáta z tabuľky. 1755 01:17:20,277 --> 01:17:22,360 Som orezávanie to s Cronu a ja som ho uvedenia 1756 01:17:22,360 --> 01:17:24,160 na týchto iných tabuliek, čo budete potrebovať. 1757 01:17:24,160 --> 01:17:25,940 Takže ak prevrátenie funguje, to je skvelé. 1758 01:17:25,940 --> 01:17:27,080 Ak nie, trim to. 1759 01:17:27,080 --> 01:17:29,640 Ale poďme si tú horúci údaje od svojich chladných dát. 1760 01:17:29,640 --> 01:17:32,535 To vám ušetrí veľa peňazí a Urob si svoj tabuliek viac vedie. 1761 01:17:32,535 --> 01:17:35,960 1762 01:17:35,960 --> 01:17:38,210 Takže ďalšia vec, ktorú budeme hovoriť o tom, je katalóg výrobkov. 1763 01:17:38,210 --> 01:17:42,000 Katalóg je celkom obyčajný prípad použitia. 1764 01:17:42,000 --> 01:17:46,600 To je vlastne veľmi časté vzor že uvidíme v rade vecí. 1765 01:17:46,600 --> 01:17:48,870 Viete, pre Twitter Príkladom, horúci tweet. 1766 01:17:48,870 --> 01:17:51,280 Každý, kto príde a schmatol ten tweet. 1767 01:17:51,280 --> 01:17:52,680 Katalóg, mám predaja. 1768 01:17:52,680 --> 01:17:54,120 Dostal som horúci predaja. 1769 01:17:54,120 --> 01:17:57,277 Mám 70.000 žiadostí za druhý príchod pre výrobok 1770 01:17:57,277 --> 01:17:58,860 opis z môjho katalógu výrobkov. 1771 01:17:58,860 --> 01:18:02,384 Vidíme to na maloobchodnom Prevádzka celkom dosť. 1772 01:18:02,384 --> 01:18:03,550 Tak ako sme sa s tým vysporiadať? 1773 01:18:03,550 --> 01:18:04,924 Neexistuje žiadny spôsob, ako sa s tým vysporiadať. 1774 01:18:04,924 --> 01:18:07,110 Všetci moji užívatelia chcú vidieť rovnaký údaj. 1775 01:18:07,110 --> 01:18:09,410 Oni prichádzajú, súbežne. 1776 01:18:09,410 --> 01:18:11,920 A oni sú všetci robiť žiadosti za rovnaký kus dát. 1777 01:18:11,920 --> 01:18:16,240 To mi dáva, že horúce klávesy, že veľké červené pruh na mojom grafe, ktoré sa nám nepáči. 1778 01:18:16,240 --> 01:18:17,720 A to je to, čo to vyzerá. 1779 01:18:17,720 --> 01:18:22,290 Takže cez môj kľúčový priestor Dostávam kladivom v predaji položky. 1780 01:18:22,290 --> 01:18:24,070 Začínam nič nikde inde. 1781 01:18:24,070 --> 01:18:26,050 >> Ako mám tento problém zmierniť? 1782 01:18:26,050 --> 01:18:28,410 No, my zmierniť to s cache. 1783 01:18:28,410 --> 01:18:33,630 Cache, dáte v podstate v pamäti partition v prednej časti databázy. 1784 01:18:33,630 --> 01:18:37,260 Podarilo sa [Nepočuteľný] cache, ako vás 1785 01:18:37,260 --> 01:18:40,260 Môžete nastaviť vlastné cache, [nepočuteľných] medzipamäť [? d ,?], čo chcete. 1786 01:18:40,260 --> 01:18:42,220 Dať, že sa pred databázy. 1787 01:18:42,220 --> 01:18:47,250 A to spôsob, ako môžete ukladať, že dáta z týchto horúcich klávesov až v tejto pamäti cache 1788 01:18:47,250 --> 01:18:49,390 priestor a prečítajte si cache. 1789 01:18:49,390 --> 01:18:51,962 >> A potom s najväčšou vašich číta začať hľadať takhle. 1790 01:18:51,962 --> 01:18:54,920 Dostal som všetky tieto keše sem a ja nemám nič v ceste sem 1791 01:18:54,920 --> 01:18:59,330 pretože databáza je usadnutí za vyrovnávacej pamäte a číta sa nikdy prejsť. 1792 01:18:59,330 --> 01:19:02,520 Keď zmením údaje do systému databázy, musím aktualizovať vyrovnávaciu pamäť. 1793 01:19:02,520 --> 01:19:04,360 Môžeme použiť niečo ako par to urobiť. 1794 01:19:04,360 --> 01:19:07,360 A ja vám vysvetlím, ako to funguje. 1795 01:19:07,360 --> 01:19:09,060 Dobre, zasielanie správ. 1796 01:19:09,060 --> 01:19:11,180 E-mail, my všetci používať e-mail. 1797 01:19:11,180 --> 01:19:12,540 >> To je celkom dobrý príklad. 1798 01:19:12,540 --> 01:19:14,950 Máme nejaký správ tabuľky. 1799 01:19:14,950 --> 01:19:17,040 A my sme dostali doručenej pošty a Pošta na odoslanie. 1800 01:19:17,040 --> 01:19:19,760 To je to, čo by SQL vyzerať ako na stavať, že e-mailové schránky. 1801 01:19:19,760 --> 01:19:23,350 Sme trochu používajú rovnaký druh stratégie použiť GSI, GSI je 1802 01:19:23,350 --> 01:19:25,320 pre moje e-mailové schránky a môj Pošta na odoslanie. 1803 01:19:25,320 --> 01:19:27,600 Tak som sa dostal surové správy prichádzajúce do mojej správy tabuľky. 1804 01:19:27,600 --> 01:19:30,194 A prvý prístup k tejto by mohlo byť, povedzme, v poriadku, žiadny problém. 1805 01:19:30,194 --> 01:19:31,110 Mám surové správy. 1806 01:19:31,110 --> 01:19:33,710 Správy prichádzajúce [nepočuteľných], ID správy, to je skvelé. 1807 01:19:33,710 --> 01:19:35,070 To je môj unikátny hash. 1808 01:19:35,070 --> 01:19:38,280 Chystám sa vytvoriť dvoma GSI je, jeden pre moje e-mailové schránky, jeden pre moju Pošta na odoslanie. 1809 01:19:38,280 --> 01:19:40,530 A prvá vec, ktorú urobím je Poviem môj hash kľúč 1810 01:19:40,530 --> 01:19:43,310 Bude príjemca a Idem zariadiť dňom. 1811 01:19:43,310 --> 01:19:44,220 To je fantastické. 1812 01:19:44,220 --> 01:19:45,890 Ja tu mám pekný výhľad. 1813 01:19:45,890 --> 01:19:47,780 Ale je to trochu problém tu. 1814 01:19:47,780 --> 01:19:50,891 A sa dostanete do toho relačnej databázy rovnako. 1815 01:19:50,891 --> 01:19:52,390 Hovorili vertikálne delenie. 1816 01:19:52,390 --> 01:19:55,840 Chcete, aby sa vaše spracovanie veľkých objemov dát od svojich malých dát. 1817 01:19:55,840 --> 01:20:00,470 >> A dôvod, prečo je, pretože musím go čítať položky, ktoré chcete získať atribúty. 1818 01:20:00,470 --> 01:20:05,570 A ak moje telá sú všetci tu, potom číta len niekoľko položiek 1819 01:20:05,570 --> 01:20:08,560 keď moje telo je dĺžka v priemere 256 kilobajtov každý, 1820 01:20:08,560 --> 01:20:10,991 matematický dostane docela škaredý. 1821 01:20:10,991 --> 01:20:12,490 Takže povedať, že chcete prečítať Dávidov e-mailovej schránky. 1822 01:20:12,490 --> 01:20:14,520 Dávidova Doručená pošta má 50 položiek. 1823 01:20:14,520 --> 01:20:17,880 Priemerná a veľkosť je 256 kB. 1824 01:20:17,880 --> 01:20:21,730 Tu je môj konverzný pomer pre RCU je je štyri kilobajtov. 1825 01:20:21,730 --> 01:20:24,450 >> OK, poďme sa nakoniec konzistentné číta. 1826 01:20:24,450 --> 01:20:28,640 Som stále jesť 1600 RCU je len na čítanie Dávidov e-mailovej schránky. 1827 01:20:28,640 --> 01:20:29,950 Ouch. 1828 01:20:29,950 --> 01:20:31,980 OK, teraz poďme premýšľať o tom, ako aplikácia funguje. 1829 01:20:31,980 --> 01:20:35,340 Ak som v e-mailovej aplikácii a Pozerám sa na mojej e-mailovej schránky, 1830 01:20:35,340 --> 01:20:39,680 a ja sa na telo každej správy, Nie, ja som pri pohľade na zhrnutie. 1831 01:20:39,680 --> 01:20:41,850 Pozerám sa na iba hlavičky. 1832 01:20:41,850 --> 01:20:46,310 Takže poďme postaviť štruktúru tabuľky že vyzerá takto. 1833 01:20:46,310 --> 01:20:49,470 >> Tak tu je informácia že moje workflow potrebuje. 1834 01:20:49,470 --> 01:20:50,890 Je to v mojej e-mailovej schránky GSI. 1835 01:20:50,890 --> 01:20:53,800 Je to dátum, odosielateľ, predmet, a potom 1836 01:20:53,800 --> 01:20:56,790 ID správy, ktoré body späť k stolu správ 1837 01:20:56,790 --> 01:20:57,850 kde by som mohol dostať telo. 1838 01:20:57,850 --> 01:21:01,260 1839 01:21:01,260 --> 01:21:04,420 No, to by bolo rekordné ID. 1840 01:21:04,420 --> 01:21:09,850 Oni by ukazovať späť do položka ID na stole Dynamo DB. 1841 01:21:09,850 --> 01:21:12,220 Každý index vždy creates-- má vždy položku 1842 01:21:12,220 --> 01:21:15,750 ID ako súčasť of-- že prichádza s indexom. 1843 01:21:15,750 --> 01:21:17,414 >> Dobre. 1844 01:21:17,414 --> 01:21:19,080 Divákov: Je to o tom, kde je uložený? 1845 01:21:19,080 --> 01:21:21,420 RICK Houlihan: Áno, je to hovorí exactly--, že je to presne to, čo robí. 1846 01:21:21,420 --> 01:21:22,644 To hovorí, že tu je moja re rekord. 1847 01:21:22,644 --> 01:21:24,310 A to bude ukazovať ju späť do svojho opätovného záznamu. 1848 01:21:24,310 --> 01:21:26,460 Presne tak. 1849 01:21:26,460 --> 01:21:29,490 OK, tak teraz moja schránka v skutočnosti oveľa menší. 1850 01:21:29,490 --> 01:21:32,210 A to vlastne podporuje pracovného postupu z e-mailovej aplikácie. 1851 01:21:32,210 --> 01:21:34,230 Takže mojej e-mailovej schránky, som kliknite na tlačidlo. 1852 01:21:34,230 --> 01:21:38,160 Idem ďalej a ja kliknite na správu, to je, keď musím ísť pre telo, 1853 01:21:38,160 --> 01:21:40,180 pretože budem prejsť do iného pohľadu. 1854 01:21:40,180 --> 01:21:43,870 Takže ak si myslíte, že o type MVC mesta rámec, pohľad modelu regulátora. 1855 01:21:43,870 --> 01:21:46,120 >> Tento model obsahuje údaje, ktoré potrebuje pohľad 1856 01:21:46,120 --> 01:21:48,130 a regulátor interaguje s. 1857 01:21:48,130 --> 01:21:51,670 Keď som sa zmeniť rám, kedy Aj zmeniť perspektívu, 1858 01:21:51,670 --> 01:21:55,080 to je v poriadku sa vrátiť do Server a repopulate modelu, 1859 01:21:55,080 --> 01:21:56,860 pretože to je to, čo používateľ očakáva. 1860 01:21:56,860 --> 01:22:00,530 Keď sa zmení zobrazenie, to je, keď môžeme ísť späť do databázy. 1861 01:22:00,530 --> 01:22:02,480 Tak e-mail, kliknite na tlačidlo. 1862 01:22:02,480 --> 01:22:03,710 Hľadám pre telo. 1863 01:22:03,710 --> 01:22:04,330 Cesta tam a späť. 1864 01:22:04,330 --> 01:22:05,680 Choď telo. 1865 01:22:05,680 --> 01:22:06,950 >> Čítal som veľa menej dát. 1866 01:22:06,950 --> 01:22:09,960 Ja som len čítanie orgánov, ktoré David potrebuje, keď ich potrebuje. 1867 01:22:09,960 --> 01:22:14,230 A ja nie som horieť v roku 1600 RCU jednoducho ukázať svoje e-mailové schránky. 1868 01:22:14,230 --> 01:22:17,670 Takže teraz that-- je to spôsob, že LSI alebo GSI-- Je mi to ľúto, 1869 01:22:17,670 --> 01:22:19,900 GSI, bude fungovať. 1870 01:22:19,900 --> 01:22:25,450 Máme našu hash na príjemcu. 1871 01:22:25,450 --> 01:22:27,030 Máme rozsah kľúč na dátume. 1872 01:22:27,030 --> 01:22:31,380 A máme plánované atribúty že musíme len podporujú názor. 1873 01:22:31,380 --> 01:22:34,300 >> Otočíme, že pre odchádzajúcich správ. 1874 01:22:34,300 --> 01:22:35,770 Hash odosielateľa. 1875 01:22:35,770 --> 01:22:39,612 A v podstate, máme veľmi pekný, čistý výhľad. 1876 01:22:39,612 --> 01:22:41,570 A je to basically-- sme už túto príjemnú správy 1877 01:22:41,570 --> 01:22:45,870 tabuľka, ktorá sa šíri pekne, pretože je to len hash, hash ID správy. 1878 01:22:45,870 --> 01:22:51,750 A máme dva indexy, ktoré sa otáčajú z tejto tabuľky. 1879 01:22:51,750 --> 01:22:57,411 Dobre, takže myšlienka tu je nie uchovávať veľké dáta a tento malý údaje 1880 01:22:57,411 --> 01:22:57,910 spoločne. 1881 01:22:57,910 --> 01:23:00,700 Rozdeliť zvisle, rozdeliť tie tabuľky. 1882 01:23:00,700 --> 01:23:03,150 Nečítajte dáta, nemusíte. 1883 01:23:03,150 --> 01:23:04,850 Dobre, herné. 1884 01:23:04,850 --> 01:23:06,990 Všetci sme radi hry. 1885 01:23:06,990 --> 01:23:10,902 Aspoň sa mi páči hry potom. 1886 01:23:10,902 --> 01:23:12,735 Takže niektoré z vecí, že sa zaoberáme, keď 1887 01:23:12,735 --> 01:23:14,193 premýšľame o hranie, nie? 1888 01:23:14,193 --> 01:23:16,999 Herné týchto dňoch, a to najmä mobilné hranie hier, je o myslenie. 1889 01:23:16,999 --> 01:23:19,540 A budem otáčať tu trochu ďaleko od DynamoDB. 1890 01:23:19,540 --> 01:23:21,373 Idem, aby v niektoré z diskusie 1891 01:23:21,373 --> 01:23:24,240 okolo niektorých z iné technológie AWS. 1892 01:23:24,240 --> 01:23:28,930 >> Ale myšlienka o hranie je myslieť o čo sa týka API, API, ktoré sú, 1893 01:23:28,930 --> 01:23:31,730 Všeobecne povedané, HTTP a JSON. 1894 01:23:31,730 --> 01:23:34,550 Je to, ako mobilné hry druh komunikovať s ich zadnými konci. 1895 01:23:34,550 --> 01:23:35,850 Oni robia JSON vysielania. 1896 01:23:35,850 --> 01:23:40,660 Dostanú dát, a to je všetko, Všeobecne povedané, v peknom JSON API. 1897 01:23:40,660 --> 01:23:44,950 >> Veci ako získať priateľov, získať leaderboard, vymieňať dáta, 1898 01:23:44,950 --> 01:23:47,699 užívateľmi generovaný obsah, tlačiť späť do systému, 1899 01:23:47,699 --> 01:23:49,740 sa jedná o typy vecí že budeme robiť. 1900 01:23:49,740 --> 01:23:52,542 Binárne dáta aktív, tieto dáta nemusí sedieť v databáze. 1901 01:23:52,542 --> 01:23:54,250 To by mohlo sedieť vo objekt obchod, nie? 1902 01:23:54,250 --> 01:23:56,541 Ale databáza bude skončiť hovorí systému, 1903 01:23:56,541 --> 01:23:59,140 hovorí aplikácie kam ísť si to. 1904 01:23:59,140 --> 01:24:03,550 A nevyhnutne, multiplayer servery, back end infraštruktúry, 1905 01:24:03,550 --> 01:24:06,180 a určené pre vysoko dostupnosť a škálovateľnosť. 1906 01:24:06,180 --> 01:24:09,400 To sú veci, ktoré chceme všetci v hernom infraštruktúry dnes. 1907 01:24:09,400 --> 01:24:12,160 >> Takže poďme sa pozrieť na ako to vyzerá. 1908 01:24:12,160 --> 01:24:16,070 Mám základný zadný koniec, veľmi jednoduché. 1909 01:24:16,070 --> 01:24:19,880 Máme systém, tu sa viacnásobné dostupnosť zón. 1910 01:24:19,880 --> 01:24:23,780 Hovorili sme o AZS as being-- myslíte z nich ako samostatné dátových centier. 1911 01:24:23,780 --> 01:24:26,040 Viac ako jedna dátové centrá per AZ, ale to je v poriadku, 1912 01:24:26,040 --> 01:24:28,831 len myslieť na nich ako samostatný dát strediská, ktoré sú geograficky 1913 01:24:28,831 --> 01:24:30,090 a porucha izolované. 1914 01:24:30,090 --> 01:24:32,172 >> Budeme mať inštancie pár EC2. 1915 01:24:32,172 --> 01:24:33,880 Budeme mať niektorí back end servera. 1916 01:24:33,880 --> 01:24:35,800 Možno, ak ste starší architektúra, my sme 1917 01:24:35,800 --> 01:24:38,920 s použitím čo nazývame RDS, relačnej databázy služby. 1918 01:24:38,920 --> 01:24:42,040 Mohol by to byť MSSQL, MySQL, alebo niečo také. 1919 01:24:42,040 --> 01:24:47,080 To je spôsob, ako veľa aplikácií sú navrhnuté tak dnes. 1920 01:24:47,080 --> 01:24:49,594 >> Tak by sme mohli chcieť ísť s to je, keď sme škálovanie. 1921 01:24:49,594 --> 01:24:51,510 Budeme pokračovať a dať vedro S3 tam hore. 1922 01:24:51,510 --> 01:24:54,200 A to S3 lopaty, namiesto porcie up týchto objektov z našej servers-- 1923 01:24:54,200 --> 01:24:55,220 sme mohli urobiť. 1924 01:24:55,220 --> 01:24:57,210 Dáte všetky vaše binárne objekty na vašich serveroch 1925 01:24:57,210 --> 01:24:59,751 a môžete použiť tie servera inštancie slúžiť, že dáta hore. 1926 01:24:59,751 --> 01:25:01,860 Ale to je dosť drahé. 1927 01:25:01,860 --> 01:25:05,107 >> Lepší spôsob, ako urobiť, je ísť dopredu a dať tieto objekty v S3 vedra. 1928 01:25:05,107 --> 01:25:06,315 S3 je objekt úložiska. 1929 01:25:06,315 --> 01:25:10,860 Je postavený špeciálne pre servírujú tieto typy vecí. 1930 01:25:10,860 --> 01:25:13,690 A nech títo klienti vyžiadať priamo z týchto objektov vedier, 1931 01:25:13,690 --> 01:25:15,390 zložiť servery. 1932 01:25:15,390 --> 01:25:17,020 Takže začíname mierka tu. 1933 01:25:17,020 --> 01:25:19,140 >> Teraz sme sa dostali užívateľov po celom svete. 1934 01:25:19,140 --> 01:25:19,730 Mám užívateľov. 1935 01:25:19,730 --> 01:25:23,380 Musím mať obsah lokálne sa nachádza v blízkosti týchto užívateľov, nie? 1936 01:25:23,380 --> 01:25:26,200 Vytvoril som S3 vedro ako môj zdrojový úložisko. 1937 01:25:26,200 --> 01:25:29,370 A ja budem vpredu, že s distribúcie CloudFront. 1938 01:25:29,370 --> 01:25:31,720 >> CloudFront je CD a content delivery network. 1939 01:25:31,720 --> 01:25:35,750 V podstate to znamená dáta, ktoré ste určili a ukladá to všetko cez internet 1940 01:25:35,750 --> 01:25:39,230 takže užívatelia môžu mať všade veľmi rýchla odozva pri 1941 01:25:39,230 --> 01:25:40,960 žiadajú o tieto objekty. 1942 01:25:40,960 --> 01:25:41,960 >> Tak dostanete nápad. 1943 01:25:41,960 --> 01:25:48,230 Ste typ pákového efektu všetky aspekty AWS sem si to urobiť. 1944 01:25:48,230 --> 01:25:50,790 A nakoniec, vyhodíme v skupine auto škálovanie. 1945 01:25:50,790 --> 01:25:52,737 Takže naše prípady AC2 našich herných serverov, 1946 01:25:52,737 --> 01:25:54,820 ako začnú dostať rušnejšie a bohatší a rušnejšie, 1947 01:25:54,820 --> 01:25:57,236 oni si len točiť ďalší inštancie, točiť ďalšie inštanciu, 1948 01:25:57,236 --> 01:25:58,210 točiť ďalšie inštanciu. 1949 01:25:58,210 --> 01:26:02,090 Takže technológia AWS má, ho umožňuje zadať parametre 1950 01:26:02,090 --> 01:26:04,650 okolo ktoré vaše servery budú rásť. 1951 01:26:04,650 --> 01:26:08,110 Takže môžete mať n počet serverov tam u nejakého daného času. 1952 01:26:08,110 --> 01:26:11,870 A ak váš náklad zmizne, oni budú zmenšovať, číslo sa bude zmenšovať. 1953 01:26:11,870 --> 01:26:15,250 A v prípade, že zaťaženie vráti, to bude pestovať späť, pružne. 1954 01:26:15,250 --> 01:26:17,050 >> Tak to vyzerá skvele. 1955 01:26:17,050 --> 01:26:19,800 Máme veľa inštancií EC2. 1956 01:26:19,800 --> 01:26:21,671 Môžeme dať cache front z databáz, 1957 01:26:21,671 --> 01:26:23,045 pokúsiť sa urýchliť databáz. 1958 01:26:23,045 --> 01:26:25,030 Budúci tlakový bod typicky ľudia vidia 1959 01:26:25,030 --> 01:26:28,850 je, že meradlo hru pomocou relačný databázový systém. 1960 01:26:28,850 --> 01:26:30,790 Ježišu, databázy výkon je hrozné. 1961 01:26:30,790 --> 01:26:31,932 Ako sa môžeme zlepšiť, že? 1962 01:26:31,932 --> 01:26:33,640 Skúsme uvedenie vyrovnávacej pamäti pred, že. 1963 01:26:33,640 --> 01:26:36,780 >> No, medzipamäte nefunguje tak skvelé hry, nie? 1964 01:26:36,780 --> 01:26:39,330 U hier, písanie je bolestivé. 1965 01:26:39,330 --> 01:26:40,930 Hry sú veľmi ťažké písať. 1966 01:26:40,930 --> 01:26:43,610 Cache nefunguje, keď ste napísať ťažké, pretože ste vždy 1967 01:26:43,610 --> 01:26:44,610 dostal k aktualizácii pamäte cache. 1968 01:26:44,610 --> 01:26:47,780 Aktualizovať vyrovnávacej pamäti, je to irelevantné, ktoré majú byť cache. 1969 01:26:47,780 --> 01:26:49,780 Je to vlastne len práca navyše. 1970 01:26:49,780 --> 01:26:51,970 >> Takže, kde sme ísť sem? 1971 01:26:51,970 --> 01:26:54,400 Máš veľkú zúženie tam dole v databáze. 1972 01:26:54,400 --> 01:26:57,661 A miesto, kam ísť samozrejme je rozdelenie. 1973 01:26:57,661 --> 01:26:59,410 Rozdelenie disku nie je ľahké robiť, keď ste 1974 01:26:59,410 --> 01:27:01,900 rokovania s relačnej databázy. 1975 01:27:01,900 --> 01:27:05,080 U relačných databáz, že ste Zodpovedajú za riadenie, efektívne, 1976 01:27:05,080 --> 01:27:06,210 kľúč priestor. 1977 01:27:06,210 --> 01:27:10,527 Hovoríte, že užívateľov medzi A a M ísť sem, medzi N a Z ísť tam. 1978 01:27:10,527 --> 01:27:12,360 A vy spínanie po aplikácii. 1979 01:27:12,360 --> 01:27:15,000 Takže máte čo do činenia s tento oddiel zdroj dát. 1980 01:27:15,000 --> 01:27:18,670 Máte transakčné obmedzenia ktoré nemajú span oddiely. 1981 01:27:18,670 --> 01:27:20,560 Máte všetky druhy neporiadok, že ste 1982 01:27:20,560 --> 01:27:23,040 zaoberajúca sa tam snažia vysporiadať sa s škálovanie out 1983 01:27:23,040 --> 01:27:25,120 a budovanie väčšej infraštruktúry. 1984 01:27:25,120 --> 01:27:27,284 Je to len žiadna sranda. 1985 01:27:27,284 --> 01:27:30,930 >> Divákov: Takže vravíte, že rastúcim zdrojom body urýchľuje 1986 01:27:30,930 --> 01:27:31,430 proces? 1987 01:27:31,430 --> 01:27:32,513 RICK Houlihan: Zvýšenie? 1988 01:27:32,513 --> 01:27:33,520 Divákov: Zdroj bodov. 1989 01:27:33,520 --> 01:27:34,410 RICK Houlihan: Zdroj body? 1990 01:27:34,410 --> 01:27:37,500 Divákov: Z informácií, kde sa informácia prichádza? 1991 01:27:37,500 --> 01:27:38,250 RICK Houlihan: Nie. 1992 01:27:38,250 --> 01:27:41,820 To, čo hovorím, je zvyšovanie počet oddielov v úložisku dát 1993 01:27:41,820 --> 01:27:44,060 zvyšuje výkon. 1994 01:27:44,060 --> 01:27:48,300 Takže to, čo sa tu deje, je užívatelia prichádzajúce do inštancie EC2 tu, 1995 01:27:48,300 --> 01:27:50,780 dobre, keď potrebujem užívateľa To je na M, pôjdem sem. 1996 01:27:50,780 --> 01:27:53,560 Od N k p, pôjdem sem. 1997 01:27:53,560 --> 01:27:55,060 Od P do Z, pôjdem sem. 1998 01:27:55,060 --> 01:27:57,120 >> Publikum: OK, ty, tak to sú všetky uložené v rôznych uzloch? 1999 01:27:57,120 --> 01:27:57,911 >> RICK Houlihan: Áno. 2000 01:27:57,911 --> 01:28:00,210 Myslite na to, ako rôzne silá dát. 2001 01:28:00,210 --> 01:28:01,660 Takže máte na to urobiť. 2002 01:28:01,660 --> 01:28:02,910 Ak sa snažíte urobiť, to, ak sa snažíte 2003 01:28:02,910 --> 01:28:05,730 meradle na relačné platforme, To je to, čo robíte. 2004 01:28:05,730 --> 01:28:08,100 Beriete dát a ste rezanie dole. 2005 01:28:08,100 --> 01:28:10,975 A vy oddielov to cez viac inštancií databázy. 2006 01:28:10,975 --> 01:28:13,580 A vy riadenie všetko, čo v aplikačnej vrstve. 2007 01:28:13,580 --> 01:28:14,729 Nie je to žiadna sranda. 2008 01:28:14,729 --> 01:28:15,770 Takže to, čo chceme ísť? 2009 01:28:15,770 --> 01:28:20,240 Chceme ísť DynamoDB, plne spravované, NoSQL úložisko dát, poskytovanie priepustnosť. 2010 01:28:20,240 --> 01:28:22,680 Využívame sekundárne indexy. 2011 01:28:22,680 --> 01:28:26,154 Je to v podstate HTTP API a zahŕňa podporu dokumentu. 2012 01:28:26,154 --> 01:28:28,570 Takže nemusíte mať strach približne ktorákoľvek hodnota z tohto delenia. 2013 01:28:28,570 --> 01:28:30,740 Robíme to všetko za vás. 2014 01:28:30,740 --> 01:28:33,260 Takže teraz, namiesto toho, budete stačí napísať do tabuľky. 2015 01:28:33,260 --> 01:28:36,490 Pokiaľ je treba tabuľku byť rozdelený, že sa deje v zákulisí. 2016 01:28:36,490 --> 01:28:40,642 Vy ste kompletne izolované z toho ako vývojár. 2017 01:28:40,642 --> 01:28:42,350 Tak poďme hovoriť o niektoré z prípadov použitia 2018 01:28:42,350 --> 01:28:47,564 že narazíme na v hraní, obyčajný herné scenáre, rebríčka. 2019 01:28:47,564 --> 01:28:49,980 Takže ste dostali užívatelia prichádza, sa BoardNames, že sú 2020 01:28:49,980 --> 01:28:52,930 na, skóre pre tohto používateľa. 2021 01:28:52,930 --> 01:28:57,700 Môžeme byť hashovanie na userid, a potom máme rad na hru. 2022 01:28:57,700 --> 01:28:59,960 Takže každý užívateľ chce vidieť všetko hra on hral 2023 01:28:59,960 --> 01:29:01,770 a všetky jeho najvyššie skóre naprieč všetkými hre. 2024 01:29:01,770 --> 01:29:04,000 Tak to je jeho osobný rebríčku. 2025 01:29:04,000 --> 01:29:10,010 >> Teraz chcem ísť a ja chcem, aby get-- tak som si tieto osobné rebríčkov. 2026 01:29:10,010 --> 01:29:12,827 To, čo chcem urobiť, je ísť dostať najvyššie skóre naprieč všetkými užívateľmi. 2027 01:29:12,827 --> 01:29:13,660 Tak ako to mám urobiť? 2028 01:29:13,660 --> 01:29:18,070 Keď je môj rekord zatriedená na ID užívateľa, sa pohybovala na hru, 2029 01:29:18,070 --> 01:29:20,740 dobre Chystám sa pokračovať a reštrukturalizovať, vytvoriť GSI, 2030 01:29:20,740 --> 01:29:22,370 a budem o reštrukturalizácii, že dáta. 2031 01:29:22,370 --> 01:29:27,310 >> Teraz budem k transformácii na BoardName, čo je hra. 2032 01:29:27,310 --> 01:29:29,800 A budem pohybovať na najvyššie skóre. 2033 01:29:29,800 --> 01:29:31,540 A teraz som vytvoril rôzne vedierka. 2034 01:29:31,540 --> 01:29:34,790 Ja som za použitia rovnakej tabuľky, rovnaké dáta položky. 2035 01:29:34,790 --> 01:29:39,870 Ale ja som vytvoriť vedierko, ktorý dáva me agregáciou najvyššie skóre zverou. 2036 01:29:39,870 --> 01:29:43,180 >> A môžem dotaz, ktorý tabuľku túto informáciu získať. 2037 01:29:43,180 --> 01:29:50,890 Tak som nastaviť, aby dotazu vzor až do byť podporené sekundárne indexu. 2038 01:29:50,890 --> 01:29:54,556 Teraz môžu byť radené podľa BoardName a zoradené podľa TopScore, v závislosti na. 2039 01:29:54,556 --> 01:29:57,180 Takže môžete vidieť, sú to typy z prípadov použitia sa dostanete do hry. 2040 01:29:57,180 --> 01:30:02,190 Ďalšia dobrá use case sme sa dostať do hry je ocenenie a kto vyhral ocenenie. 2041 01:30:02,190 --> 01:30:05,340 A je to skvelý prípad použitia kde hovoríme riedke indexy. 2042 01:30:05,340 --> 01:30:07,340 Riedke indexy sú schopnosť vytvárať 2043 01:30:07,340 --> 01:30:10,850 index, ktorý nie je nevyhnutne obsahovať každú položku na stole. 2044 01:30:10,850 --> 01:30:11,470 A prečo nie? 2045 01:30:11,470 --> 01:30:14,540 Vzhľadom k tomu, že to je atribút indexovaný neexistuje na každom kuse. 2046 01:30:14,540 --> 01:30:16,460 >> Takže v tomto konkrétnom prípad použitia, hovorím, 2047 01:30:16,460 --> 01:30:19,240 viete čo, budem vytvoriť atribút nazvaný Award. 2048 01:30:19,240 --> 01:30:22,970 A ja dám každému užívateľovi že má cenu, ktorá atribút. 2049 01:30:22,970 --> 01:30:25,950 Používatelia, ktorí nemajú ocenenia sú nebude mať tento atribút. 2050 01:30:25,950 --> 01:30:27,800 Takže keď som sa vytvoriť index, iba užívatelia 2051 01:30:27,800 --> 01:30:28,960 že ukážeme up v indexe sú 2052 01:30:28,960 --> 01:30:31,050 tie, ktoré skutočne získali ocenenia. 2053 01:30:31,050 --> 01:30:34,440 Takže je to skvelý spôsob, ako byť schopní vytvoriť filtrované indexy 2054 01:30:34,440 --> 01:30:40,580 sú veľmi, veľmi selektívne, že nie majú indexovať celú tabuľku. 2055 01:30:40,580 --> 01:30:43,050 >> Takže my sme stále málo času. 2056 01:30:43,050 --> 01:30:49,190 Chystám sa ísť dopredu a preskočte out a preskočiť tento scenár. 2057 01:30:49,190 --> 01:30:52,625 Porozprávajte sa trochu about-- 2058 01:30:52,625 --> 01:30:54,460 >> Divákov: Môžem sa opýtať na rýchly dotaz? 2059 01:30:54,460 --> 01:30:56,722 Jedným z nich je písať ťažké? 2060 01:30:56,722 --> 01:30:57,680 RICK Houlihan: Čo je to? 2061 01:30:57,680 --> 01:30:58,596 Divákov: Napíšte ťažký. 2062 01:30:58,596 --> 01:31:01,270 RICK Houlihan: Napíšte ťažký. 2063 01:31:01,270 --> 01:31:03,460 Dovoľ mi pozrieť sa. 2064 01:31:03,460 --> 01:31:06,220 >> Divákov: Alebo je, že nie niečo, čo môžete len 2065 01:31:06,220 --> 01:31:08,809 hlas behom niekoľkých sekúnd? 2066 01:31:08,809 --> 01:31:10,850 RICK Houlihan: Ideme prostredníctvom hlasovania scenára. 2067 01:31:10,850 --> 01:31:11,670 Nie je to tak zlé. 2068 01:31:11,670 --> 01:31:14,580 Myslíte si, chlapci majú pár minút? 2069 01:31:14,580 --> 01:31:15,860 OK. 2070 01:31:15,860 --> 01:31:17,890 >> Takže budeme hovoriť o hlasovaní. 2071 01:31:17,890 --> 01:31:20,250 Takže v reálnom čase hlasovania, máme požiadavky pre hlasovanie. 2072 01:31:20,250 --> 01:31:25,250 Požiadavky sú, že umožníme každá osoba, ktorá má hlasovať iba raz. 2073 01:31:25,250 --> 01:31:28,060 Chceme nikto byť schopní zmeniť svoj hlas. 2074 01:31:28,060 --> 01:31:31,045 Chceme, aby v reálnom čase agregácie a analytika pre demografie 2075 01:31:31,045 --> 01:31:34,210 že budeme mať ukazuje užívateľom na webe. 2076 01:31:34,210 --> 01:31:35,200 >> Myslite na tento scenár. 2077 01:31:35,200 --> 01:31:37,550 Pracujeme veľa reality TV ukazuje, kde sú 2078 01:31:37,550 --> 01:31:38,960 robí tieto presný typ vecí. 2079 01:31:38,960 --> 01:31:41,584 Takže si môžete myslieť na scenár, máme milióny a milióny 2080 01:31:41,584 --> 01:31:43,959 tam of dospievajúce dievčatá s ich mobilné telefóny 2081 01:31:43,959 --> 01:31:46,250 a hlasovanie a hlasovanie, a hlasovať pre toho, kto sú 2082 01:31:46,250 --> 01:31:48,610 si, že je najobľúbenejší. 2083 01:31:48,610 --> 01:31:50,830 Tak to sú niektoré z Požiadavky nám dôjde. 2084 01:31:50,830 --> 01:31:52,990 >> A tak sa ako prvý prijať pri riešení tohto problému 2085 01:31:52,990 --> 01:31:55,090 by bolo vybudovať Veľmi jednoduchá aplikácia. 2086 01:31:55,090 --> 01:31:56,490 Tak som dostal túto aplikáciu. 2087 01:31:56,490 --> 01:31:57,950 Mám nejaké voliča vonku. 2088 01:31:57,950 --> 01:31:59,980 Prichádzajú v, narazí na hlasovacie aplikácie. 2089 01:31:59,980 --> 01:32:03,440 Mám nejaké surové hlasov tabuľku Ja si len výpis týchto hlasov do. 2090 01:32:03,440 --> 01:32:05,780 Budem mať nejaké agregát hlasov tabuľka, ktorá 2091 01:32:05,780 --> 01:32:09,490 bude robiť Analytics a demografie, a dáme to všetko tam. 2092 01:32:09,490 --> 01:32:11,420 >> A to je skvelé. 2093 01:32:11,420 --> 01:32:12,332 Život je dobrý. 2094 01:32:12,332 --> 01:32:15,040 Život je dobrý, kým nezistíme, že je tu vždy len jedna alebo dve 2095 01:32:15,040 --> 01:32:16,879 ľudia, ktorí sú populárne vo voľbách. 2096 01:32:16,879 --> 01:32:19,420 Je tu len jedna alebo dve veci že ľudia naozaj záleží. 2097 01:32:19,420 --> 01:32:22,340 A ak ste na hlasovaní mierka, zrazu som si 2098 01:32:22,340 --> 01:32:26,360 bude zatĺkať sakra z dvaja kandidáti, jeden alebo dva záujemcovia. 2099 01:32:26,360 --> 01:32:29,390 Veľmi obmedzený počet kusov ľudia nájdu byť populárny. 2100 01:32:29,390 --> 01:32:31,710 >> To nie je dobrý dizajn vzor. 2101 01:32:31,710 --> 01:32:33,549 To je vlastne veľmi zlé návrhový vzor 2102 01:32:33,549 --> 01:32:36,340 pretože vytvára presne to, čo sme Hovoril o tom, ktoré bolo klávesov. 2103 01:32:36,340 --> 01:32:38,960 Horúce klávesy sú niečo, čo sa nám nepáči. 2104 01:32:38,960 --> 01:32:40,470 >> Tak ako to napraviť? 2105 01:32:40,470 --> 01:32:47,640 A naozaj, ako to opraviť, je tým, že sa tie kandidátske vedierka 2106 01:32:47,640 --> 01:32:51,490 a pre každého kandidáta máme, budeme pripojiť náhodnú hodnotu, 2107 01:32:51,490 --> 01:32:54,192 niečo, čo vieme, náhodné hodnota medzi jedným a 100, 2108 01:32:54,192 --> 01:32:56,620 medzi 100 a 1000, alebo medzi jednou a 1000, 2109 01:32:56,620 --> 01:32:59,940 však mnoho náhodné hodnoty, ktoré chcete pripojiť na koniec tohto kandidáta. 2110 01:32:59,940 --> 01:33:01,330 >> A čo som vlastne urobil potom? 2111 01:33:01,330 --> 01:33:05,830 Ak som pomocou číslo kandidáta ako papuče agregovať hlasovania, 2112 01:33:05,830 --> 01:33:08,780 či som pridal náhodný Číslo na koniec, ktorý, 2113 01:33:08,780 --> 01:33:12,000 Vytvoril som teraz 10 vedierka, je Stotisíc vedierka, vedierka 2114 01:33:12,000 --> 01:33:14,160 že som agregáciu hlasov naprieč. 2115 01:33:14,160 --> 01:33:18,030 >> Takže mám milióny a milióny, a milióny záznamov prichádza 2116 01:33:18,030 --> 01:33:22,050 pre tieto kandidátov, som teraz šíri tieto hlasy naprieč Candidate a_1 2117 01:33:22,050 --> 01:33:24,630 cez kandidáta A_100, pretože zakaždým, keď hlas príde, 2118 01:33:24,630 --> 01:33:26,530 Som generovanie náhodných Hodnota medzi jedným a 100. 2119 01:33:26,530 --> 01:33:29,446 Som pripínanie ho na konci Kandidát, že osoba je hlasovať pre. 2120 01:33:29,446 --> 01:33:31,120 Ja dumping to do tej vedra. 2121 01:33:31,120 --> 01:33:33,910 >> Teraz na zadnej strane, ja viem, že som sto vedierka. 2122 01:33:33,910 --> 01:33:36,350 Takže keď chcem ísť dopredu a agregovať hlasy, 2123 01:33:36,350 --> 01:33:38,244 Čítal som zo všetkých tých vedier. 2124 01:33:38,244 --> 01:33:39,160 Tak som sa do toho pustite a pridať. 2125 01:33:39,160 --> 01:33:42,410 A potom som si bodový zhromaždiť kde som ísť von a povedať hej, 2126 01:33:42,410 --> 01:33:45,399 viete čo, kľúč tohto uchádzača priestory je viac ako sto lopaty. 2127 01:33:45,399 --> 01:33:47,940 Chystám sa zhromaždiť všetky hlasy od tých sto vedier. 2128 01:33:47,940 --> 01:33:49,981 Idem k agregácii im a budem hovoriť, 2129 01:33:49,981 --> 01:33:53,830 Kandidáta má teraz Celkový počet hlasovaní o x. 2130 01:33:53,830 --> 01:33:55,690 >> Teraz obaja zápisu dotaz a dotaz čítanie 2131 01:33:55,690 --> 01:33:58,160 sú pekne distribuované pretože píšem naprieč 2132 01:33:58,160 --> 01:34:00,320 a ja som čítal cez stovky kľúčov. 2133 01:34:00,320 --> 01:34:03,500 Nie som písanie a čítanie cez jeden kľúč teraz. 2134 01:34:03,500 --> 01:34:04,950 Takže je to skvelý vzor. 2135 01:34:04,950 --> 01:34:08,090 >> Toto je v skutočnosti pravdepodobne jedným z najdôležitejších dizajnu 2136 01:34:08,090 --> 01:34:10,420 vzory pre mierku v NoSQL. 2137 01:34:10,420 --> 01:34:14,470 Uvidíte tento typ návrhový vzor v každom chuť. 2138 01:34:14,470 --> 01:34:19,100 MongoDB, DynamoDB, to nie je ohľadu na to, my všetci musíme to urobiť. 2139 01:34:19,100 --> 01:34:21,840 Pretože keď máte čo do činenia s tých obrovských agregácie, 2140 01:34:21,840 --> 01:34:26,650 budete musieť vymyslieť spôsob, ako na šíri von cez vedierka. 2141 01:34:26,650 --> 01:34:29,512 Takže toto je spôsob, ako to urobiť. 2142 01:34:29,512 --> 01:34:31,220 Dobre, tak čo robíte práve teraz 2143 01:34:31,220 --> 01:34:35,252 Je ste obchodovanie off čítanie náklady na zápis škálovateľnosť. 2144 01:34:35,252 --> 01:34:37,085 Náklady na mojej čítanie je trochu zložitejšie 2145 01:34:37,085 --> 01:34:40,220 a ja musím ísť čítať zo Sto vedierka namiesto jedného. 2146 01:34:40,220 --> 01:34:41,310 Ale som schopný napísať. 2147 01:34:41,310 --> 01:34:44,860 A má priepustnosť, môj zápis priepustnosť je neuveriteľné. 2148 01:34:44,860 --> 01:34:49,450 Takže je to väčšinou cenný technika pre škálovanie DynamoDB, 2149 01:34:49,450 --> 01:34:51,350 alebo akejkoľvek databázy NoSQL na to príde. 2150 01:34:51,350 --> 01:34:53,824 2151 01:34:53,824 --> 01:34:55,240 Tak sme sa na to, ako ho škálovať. 2152 01:34:55,240 --> 01:34:56,930 A sme prišli, ako sa eliminovať naše horúcich kláves. 2153 01:34:56,930 --> 01:34:57,820 A to je fantastické. 2154 01:34:57,820 --> 01:34:58,960 A my sme dostali tento pekný systém. 2155 01:34:58,960 --> 01:35:02,043 A to nám veľmi správne hlasovanie pretože máme záznam, hodnotené de-Dupe. 2156 01:35:02,043 --> 01:35:03,130 Je postavený do DynamoDB. 2157 01:35:03,130 --> 01:35:05,380 Hovorili sme o podmienených práv. 2158 01:35:05,380 --> 01:35:08,170 >> Ak volič príde, dá vložku na stole, 2159 01:35:08,170 --> 01:35:11,220 oni vložka s ich voličskej ID, ak sa pokúsite vložiť iný hlas, 2160 01:35:11,220 --> 01:35:13,320 Ja podmienené zápis. 2161 01:35:13,320 --> 01:35:16,960 Povedzme, že len napísať to ak táto neexistuje. 2162 01:35:16,960 --> 01:35:19,270 Takže akonáhle som vidieť, že že hlasovanie hit stôl, 2163 01:35:19,270 --> 01:35:20,460 nikto iný to bude schopný dať svoj hlas v. 2164 01:35:20,460 --> 01:35:21,634 A to je fantastické. 2165 01:35:21,634 --> 01:35:23,550 A my zvyšovanie Naši pulty kandidátskych. 2166 01:35:23,550 --> 01:35:25,466 A robíme otázky demografia a tak. 2167 01:35:25,466 --> 01:35:29,110 Ale čo sa stane, keď je moje Aplikácia padá cez? 2168 01:35:29,110 --> 01:35:31,350 A teraz zrazu hlasov sú prichádza, a ja 2169 01:35:31,350 --> 01:35:34,840 Neviem, či sú stále spracovávané do mojej analýzy a demografia 2170 01:35:34,840 --> 01:35:36,040 už nie. 2171 01:35:36,040 --> 01:35:38,462 A keď aplikácie príde späť, ako 2172 01:35:38,462 --> 01:35:41,420 sakra viem, čo máte hlasov bola spracovaná a kde mám začať? 2173 01:35:41,420 --> 01:35:44,530 >> Tak to je skutočný problém, keď vás začať sa pozerať na tento typ scenára. 2174 01:35:44,530 --> 01:35:45,571 A ako to riešime, že? 2175 01:35:45,571 --> 01:35:48,070 Riešime to s tým, čo volajte DynamoDB prúdov. 2176 01:35:48,070 --> 01:35:53,470 Potoky je čas objednať a rozdelí zmena protokol o každom prístupe 2177 01:35:53,470 --> 01:35:55,700 k stolu, každý napísať prístup k stolu. 2178 01:35:55,700 --> 01:35:58,810 Všetky dáta, ktoré to napísané na Tabuľka sa objaví na prúde. 2179 01:35:58,810 --> 01:36:01,815 >> Je to v podstate 24 hodín front. 2180 01:36:01,815 --> 01:36:03,690 Položky zasiahol prúd, žijú po dobu 24 hodín. 2181 01:36:03,690 --> 01:36:05,990 Môžu byť čítať viackrát. 2182 01:36:05,990 --> 01:36:09,400 Garantovaná ktoré majú byť dodané iba raz do prúdu, 2183 01:36:09,400 --> 01:36:11,180 by bolo možné čítať n počet opakovaní. 2184 01:36:11,180 --> 01:36:14,910 Takže však mnoho procesy, ktoré chcete konzumovať, že dáta, môžete konzumovať. 2185 01:36:14,910 --> 01:36:16,350 To sa zobrazí pri každom aktualizácii. 2186 01:36:16,350 --> 01:36:18,455 Každý zápis bude len sa objaví raz na potoku. 2187 01:36:18,455 --> 01:36:20,621 Takže nemusíte mať strach asi dvojnásobok ich spracovanie 2188 01:36:20,621 --> 01:36:22,500 z rovnakého procesu. 2189 01:36:22,500 --> 01:36:25,350 >> Je to prísne nariadil za položku. 2190 01:36:25,350 --> 01:36:28,180 Keď hovoríme čas objednal a rozdelia, 2191 01:36:28,180 --> 01:36:30,680 uvidíte za prepážkou na potoku. 2192 01:36:30,680 --> 01:36:33,169 Uvidíte položky, aktualizácia v poriadku. 2193 01:36:33,169 --> 01:36:35,210 Nie sme zaručujúce streamu, že ste 2194 01:36:35,210 --> 01:36:40,240 dostane každú transakciu v poradí cez položiek. 2195 01:36:40,240 --> 01:36:42,440 >> Takže prúdy sú idempotentních. 2196 01:36:42,440 --> 01:36:44,037 Máme všetci vieme, čo idempotentních znamená? 2197 01:36:44,037 --> 01:36:46,620 Idempotentních znamená, že môžete to urobiť cez, a znova, a znova. 2198 01:36:46,620 --> 01:36:48,200 Výsledok to bude rovnaká. 2199 01:36:48,200 --> 01:36:49,991 >> Prúdy sú idempotentních, ale musí byť 2200 01:36:49,991 --> 01:36:54,860 hral od východzieho bodu, tam, kde si vyberiete, až do konca, 2201 01:36:54,860 --> 01:36:57,950 alebo nebudú mať za následok v rovnakých hodnotách. 2202 01:36:57,950 --> 01:36:59,727 >> To isté sa MongoDB. 2203 01:36:59,727 --> 01:37:01,560 MongoDB má konštrukt oni volajú oplog. 2204 01:37:01,560 --> 01:37:04,140 Je to presne rovnakej konštrukcie. 2205 01:37:04,140 --> 01:37:06,500 Mnoho databáz NoSQL majú tento konštrukt. 2206 01:37:06,500 --> 01:37:08,790 Používajú ju robiť veci ako replikácie, ktorý 2207 01:37:08,790 --> 01:37:10,475 je presne to, čo robíme s prúdmi. 2208 01:37:10,475 --> 01:37:12,350 Publikum: Možno kacírsky otázka, ale vy 2209 01:37:12,350 --> 01:37:13,975 hovoriť o tom apps dole po tak ďalej. 2210 01:37:13,975 --> 01:37:16,089 Sú prúdy zaručene Nikdy možná ísť dole? 2211 01:37:16,089 --> 01:37:18,630 RICK Houlihan: Jo, potoky je zaručené, že sa nikdy ísť dole. 2212 01:37:18,630 --> 01:37:21,040 Riadime infraštruktúru za sebou. prúdy automaticky 2213 01:37:21,040 --> 01:37:22,498 rozmiestniť svoje auto škálovanie skupiny. 2214 01:37:22,498 --> 01:37:25,910 Prejdeme trochu niečo o tom, čo sa stane. 2215 01:37:25,910 --> 01:37:30,060 >> Nemal by som povedať, že to nie je zaručené, že sa nikdy ísť dole. 2216 01:37:30,060 --> 01:37:33,110 Prvky sú zaručené sa objaví v prúde. 2217 01:37:33,110 --> 01:37:36,740 A prúd bude prístupná. 2218 01:37:36,740 --> 01:37:40,580 Takže to, čo ide dole alebo sa vráti späť up, že sa deje pod ním. 2219 01:37:40,580 --> 01:37:43,844 Je covers--, že je to v poriadku. 2220 01:37:43,844 --> 01:37:46,260 Dobre, takže máte iný Typy zobrazenia mimo obrazovku. 2221 01:37:46,260 --> 01:37:51,040 Typy zobrazenia, ktoré sú dôležité pre programátor sú zvyčajne, čo to bolo? 2222 01:37:51,040 --> 01:37:52,370 Mám starý názor. 2223 01:37:52,370 --> 01:37:55,630 Ak aktualizácia dopadne na stôl, bude to vytlačte starý pohľad do prúdu 2224 01:37:55,630 --> 01:38:02,070 takže dáta môžu archivovať, alebo zmena kontrola, identifikácia zmien, zmena 2225 01:38:02,070 --> 01:38:03,600 Riadenie. 2226 01:38:03,600 --> 01:38:07,160 >> Nový list, čo to je teraz, po aktualizácie, to je iný druh pohľadu 2227 01:38:07,160 --> 01:38:07,660 môžete získať. 2228 01:38:07,660 --> 01:38:09,660 Môžete získať staré aj nové obrazy. 2229 01:38:09,660 --> 01:38:10,660 Možno, že chcem obaja. 2230 01:38:10,660 --> 01:38:11,790 Chcem vidieť, čo to bolo. 2231 01:38:11,790 --> 01:38:13,290 Chcem vidieť, čo to sa zmenilo na. 2232 01:38:13,290 --> 01:38:15,340 >> Mám typ zhody procesu, ktorý beží. 2233 01:38:15,340 --> 01:38:17,430 Je potrebné overiť, či ak sa zmení tieto veci, 2234 01:38:17,430 --> 01:38:21,840 že sú v určitých medziach alebo v rámci určitých parametrov. 2235 01:38:21,840 --> 01:38:23,840 >> A potom možno som len Potrebujem vedieť, čo sa zmenilo. 2236 01:38:23,840 --> 01:38:26,240 Nezaujíma ma, čo zmene položky. 2237 01:38:26,240 --> 01:38:28,580 Nepotrebujem, aby potrebujete vedieť aké atribúty zmenil. 2238 01:38:28,580 --> 01:38:30,882 Len potrebujem vedieť, že položky sú dotkol. 2239 01:38:30,882 --> 01:38:33,340 To sú teda spôsoby zobrazovania že sa dostanete z prúdu 2240 01:38:33,340 --> 01:38:35,960 a môžete komunikovať s. 2241 01:38:35,960 --> 01:38:37,840 >> Aplikácia, ktorá spotrebováva prúd, 2242 01:38:37,840 --> 01:38:39,298 to je tak trochu, ako to funguje. 2243 01:38:39,298 --> 01:38:42,570 DynamoDB klient požiadať, aby tlačiť dát do tabuliek. 2244 01:38:42,570 --> 01:38:44,750 Prúdy nasadiť na to, čo hovoríme črepy. 2245 01:38:44,750 --> 01:38:47,380 Črepy sú odstupňované nezávisle na tabuľky. 2246 01:38:47,380 --> 01:38:50,660 Nemajú zarovnané úplne sa rozdelí váš stôl. 2247 01:38:50,660 --> 01:38:52,540 A dôvod, prečo je pretože line up 2248 01:38:52,540 --> 01:38:55,430 kapacite, aktuálny Kapacita tabuľky. 2249 01:38:55,430 --> 01:38:57,600 >> Ich nasadenie v ich vlastné auto škálovanie skupina, 2250 01:38:57,600 --> 01:39:00,800 a začnú vymykať závislosti na tom, koľko zápisy prichádzajú, 2251 01:39:00,800 --> 01:39:03,090 koľko reads-- v skutočnosti je to píše. 2252 01:39:03,090 --> 01:39:05,820 Nie je reads-- ale ako Mnoho zápisy prichádzajú. 2253 01:39:05,820 --> 01:39:08,200 >> A potom na chrbte koniec, máme to, čo máme 2254 01:39:08,200 --> 01:39:11,390 volať KCI, alebo Kinesis klientskú knižnicu. 2255 01:39:11,390 --> 01:39:19,190 Kinesis je prúd dát technológia spracovania od Amazonu. 2256 01:39:19,190 --> 01:39:22,040 A potokov je postavená na tom. 2257 01:39:22,040 --> 01:39:25,670 >> Takže ste použiť KCL povolený Aplikácie pre čítanie prúdu. 2258 01:39:25,670 --> 01:39:28,752 Kinesis Klient knižnica vlastne spravuje robotníkov pre vás. 2259 01:39:28,752 --> 01:39:30,460 A to tiež robí niektoré zaujímavé veci. 2260 01:39:30,460 --> 01:39:35,630 To bude vytvárať nejaké tabuľky up v DynamoDB tabuľkovom 2261 01:39:35,630 --> 01:39:38,410 sledovať, ktoré položky boli spracované. 2262 01:39:38,410 --> 01:39:41,190 Takže týmto spôsobom, ak to padá späť, ak spadne a príde a dostane 2263 01:39:41,190 --> 01:39:45,570 postavil späť hore, to môže zistiť, kde to bolo pri spracovaní prúdu. 2264 01:39:45,570 --> 01:39:48,360 >> To je veľmi dôležité, keď hovoríte o replikáciu. 2265 01:39:48,360 --> 01:39:50,350 Musím vedieť, čo Dáta bola spracovaná 2266 01:39:50,350 --> 01:39:52,810 a aké údaje musia byť ešte len spracované. 2267 01:39:52,810 --> 01:39:57,380 Takže knižnica KCL pre prúdov bude vám veľa tejto funkcii. 2268 01:39:57,380 --> 01:39:58,990 To sa stará o všetku domácnosť. 2269 01:39:58,990 --> 01:40:01,140 To sa postaví pracovníka pre každý črep. 2270 01:40:01,140 --> 01:40:04,620 To vytvorí administratívne tabuľku za každý črep, pre každého pracovníka. 2271 01:40:04,620 --> 01:40:07,560 A ako títo pracovníci oheň, udržujú tie tabuľky 2272 01:40:07,560 --> 01:40:10,510 takže viete, tento záznam bola prečítaná a spracovaná. 2273 01:40:10,510 --> 01:40:13,850 A potom, že spôsob, ako v prípade, že proces zomrie a prejde do režimu online, 2274 01:40:13,850 --> 01:40:17,940 to môže pokračovať presne tam, kde je to vzlietlo. 2275 01:40:17,940 --> 01:40:20,850 >> Tak sme sa použiť pre cross-región replikácie. 2276 01:40:20,850 --> 01:40:24,680 Mnoho zákazníkov má potrebu presunúť dáta alebo časti ich dátových tabuliek 2277 01:40:24,680 --> 01:40:25,920 okolo rôznych oblastiach. 2278 01:40:25,920 --> 01:40:29,230 Existuje deväť regiónov po celom svete. 2279 01:40:29,230 --> 01:40:32,100 Tak by mohlo dôjsť k need-- I môže mať používateľa v Ázii, užívatelia 2280 01:40:32,100 --> 01:40:34,150 vo východnom pobreží Spojených štátov. 2281 01:40:34,150 --> 01:40:38,980 Majú rôzne údaje, ktoré musí byť na mieste rozdelenie. 2282 01:40:38,980 --> 01:40:42,510 A možno, že užívateľ lieta od Ázie cez do Spojených štátov, 2283 01:40:42,510 --> 01:40:45,020 a chcem, aby replikovať jeho dáta s ním. 2284 01:40:45,020 --> 01:40:49,340 Takže keď sa dostane z lietadla, má dobrá skúsenosť pomocou svojho mobilného aplikácie. 2285 01:40:49,340 --> 01:40:52,360 >> Môžete použiť cross-región Knižnica replikácie to urobiť. 2286 01:40:52,360 --> 01:40:55,730 V podstate máme poskytla dve technológie. 2287 01:40:55,730 --> 01:40:59,400 Jeden je aplikácia konzoly môžete postaviť na svoje vlastné EC2 inštancie. 2288 01:40:59,400 --> 01:41:01,240 To beží čisté replikácie. 2289 01:41:01,240 --> 01:41:02,720 A potom sme vám dali do knižnice. 2290 01:41:02,720 --> 01:41:06,070 Knižnica môžete použiť na vybudovanie vlastné aplikácie, ak vás 2291 01:41:06,070 --> 01:41:10,740 chcú robiť šialené veci, s tým data-- filter, kopírovať len časť z toho, 2292 01:41:10,740 --> 01:41:14,120 otáčať dát, presuňte ho na A iné tabuľky, a tak ďalej a tak ďalej. 2293 01:41:14,120 --> 01:41:18,700 2294 01:41:18,700 --> 01:41:20,520 Takže to je to trochu ako to vyzerá. 2295 01:41:20,520 --> 01:41:23,690 >> DynamoDB Streams môže byť spracovať čo nazývame Lambda. 2296 01:41:23,690 --> 01:41:27,394 Zmienili sme sa trochu o udalosti aplikačných architektúry. 2297 01:41:27,394 --> 01:41:28,810 Lambda je kľúčovým prvkom, ktorý. 2298 01:41:28,810 --> 01:41:32,840 Lambda je kód, ktorý vystrelí na požiadanie v reakcii na konkrétne udalosti. 2299 01:41:32,840 --> 01:41:36,020 Jedným z týchto prípadov by mohol byť záznam sa objaví na potoku. 2300 01:41:36,020 --> 01:41:39,100 Ak sa na potoku sa objaví záznam, zavoláme túto funkciu Java. 2301 01:41:39,100 --> 01:41:44,980 No, to je JavaScript a Lambda podporuje Node.js, Java, Python, 2302 01:41:44,980 --> 01:41:47,820 a čoskoro podporí ďalšie jazyky rovnako. 2303 01:41:47,820 --> 01:41:50,940 A stačí povedať, že je to čistý kód. 2304 01:41:50,940 --> 01:41:53,610 napísať V Jave, definujete triedu. 2305 01:41:53,610 --> 01:41:55,690 Môžete tlačiť JAR hore do lambda. 2306 01:41:55,690 --> 01:42:00,200 A potom sa určiť, ktorá trieda volať v reakcii na ktorom udalosť. 2307 01:42:00,200 --> 01:42:04,770 A potom infraštruktúra Lambda za tým pobeží ten kód. 2308 01:42:04,770 --> 01:42:06,730 >> Tento kód dokáže spracovať Záznamy mimo potoku. 2309 01:42:06,730 --> 01:42:08,230 To môže robiť čokoľvek, chce s ním. 2310 01:42:08,230 --> 01:42:11,650 V tomto konkrétnom príklade, všetci sme naozaj robia, je protokolovanie atribúty. 2311 01:42:11,650 --> 01:42:13,480 Ale to je len kód. 2312 01:42:13,480 --> 01:42:15,260 Kód môže robiť čokoľvek, že jo? 2313 01:42:15,260 --> 01:42:16,600 >> Takže môžete otáčať, že dáta. 2314 01:42:16,600 --> 01:42:18,160 Môžete vytvárať odvodené pohľad. 2315 01:42:18,160 --> 01:42:21,160 Ak je to štruktúra dokumentov, môžete vyrovnať štruktúru. 2316 01:42:21,160 --> 01:42:24,300 Môžete si vytvoriť alternatívne indexy. 2317 01:42:24,300 --> 01:42:27,100 Všetky druhy vecí, ktoré môžete činenia s DynamoDB prúdmi. 2318 01:42:27,100 --> 01:42:28,780 >> A naozaj, to je to, čo to vyzerá. 2319 01:42:28,780 --> 01:42:29,940 Takže ste si tieto aktualizácie prichádzať. 2320 01:42:29,940 --> 01:42:31,190 Idú mimo reťazec. 2321 01:42:31,190 --> 01:42:32,720 Sú čítať pomocou funkcie Lambda. 2322 01:42:32,720 --> 01:42:37,480 Sú otáčania údaje a tlačí to v tabuľkách finančných derivátov, 2323 01:42:37,480 --> 01:42:42,200 oznamovanie externých systémov zmeny, a tlačí dáta do ElastiCache. 2324 01:42:42,200 --> 01:42:45,900 >> Hovorili sme o tom, ako dať cache v prednej časti databázy pre tento predaja 2325 01:42:45,900 --> 01:42:46,450 scenár. 2326 01:42:46,450 --> 01:42:50,049 No, čo sa stane, keď som aktualizuje opis položky? 2327 01:42:50,049 --> 01:42:52,340 No, keby som mal Lambda Funkcia beží na tejto tabuľke, 2328 01:42:52,340 --> 01:42:55,490 keď som aktualizovať opis položky, bude to vyzdvihnúť záznam z potoka, 2329 01:42:55,490 --> 01:42:58,711 a to bude aktualizovať ElastiCache inštancie s novými dátami. 2330 01:42:58,711 --> 01:43:00,460 Tak to je veľa Čo robíme s Lambda. 2331 01:43:00,460 --> 01:43:02,619 Je to lepidlo kód, konektory. 2332 01:43:02,619 --> 01:43:04,410 A to vlastne dáva schopnosť začať 2333 01:43:04,410 --> 01:43:07,930 a prevádzkovať veľmi zložitých aplikácií bez dedikovaný server 2334 01:43:07,930 --> 01:43:10,371 infraštruktúra, ktorá je naozaj cool. 2335 01:43:10,371 --> 01:43:13,100 >> Takže poďme späť k našim real-time hlasovanie architektúry. 2336 01:43:13,100 --> 01:43:17,984 To je nová a lepšia s našimi potokov a KCL povolené žiadosť. 2337 01:43:17,984 --> 01:43:20,150 Rovnako ako predtým, môžeme zvládnuť akúkoľvek mierka volieb. 2338 01:43:20,150 --> 01:43:21,100 My takto. 2339 01:43:21,100 --> 01:43:24,770 Robíme z bodový zhromažďuje cez viac vedier. 2340 01:43:24,770 --> 01:43:26,780 Máme optimistickejší zamykanie deje. 2341 01:43:26,780 --> 01:43:30,192 Môžeme udržať naše voliča meniť ich hlasy. 2342 01:43:30,192 --> 01:43:31,400 Môžu hlasovať iba raz. 2343 01:43:31,400 --> 01:43:32,880 To je fantastické. 2344 01:43:32,880 --> 01:43:35,895 Real-time odolnosť proti chybám, Teraz škálovateľné agregácie. 2345 01:43:35,895 --> 01:43:38,270 V prípade, že vec spadne, ju vie, kde o reštartovanie samotného 2346 01:43:38,270 --> 01:43:41,300 keď sa vráti, pretože sme pomocou aplikácie KCL. 2347 01:43:41,300 --> 01:43:45,700 A potom môžeme použiť tiež, že KCL aplikácie, aby sa zasadila dát von 2348 01:43:45,700 --> 01:43:48,820 k RedShift pre iné analytika app, alebo použitie 2349 01:43:48,820 --> 01:43:51,990 Elastické MapReduce spustiť real-time streaming agregáciou off 2350 01:43:51,990 --> 01:43:53,180 týchto údajov. 2351 01:43:53,180 --> 01:43:55,480 >> To sú veci, ktoré by sme Nehovoril o moc. 2352 01:43:55,480 --> 01:43:57,375 Ale sú ďalšie technológie, ktoré prichádzajú 2353 01:43:57,375 --> 01:44:00,310 niesť, keď hľadáte na týchto typoch scenárov. 2354 01:44:00,310 --> 01:44:03,160 >> Dobre, takže to je asi analytics s DynamoDB prúdov. 2355 01:44:03,160 --> 01:44:05,340 Môžete vyberať de-Dupe Údaje, robiť všetky druhy 2356 01:44:05,340 --> 01:44:09,490 pekná vecí, súhrnné údaje v pamäť, vytvorenie týchto tabuľkách finančných derivátov. 2357 01:44:09,490 --> 01:44:13,110 To je obrovský prípad použitia že veľa zákazníkov 2358 01:44:13,110 --> 01:44:16,950 sa zaoberajú, pričom vnorená Vlastnosti týchto dokumentov JSON 2359 01:44:16,950 --> 01:44:18,946 a vytvorenie ďalších indexov. 2360 01:44:18,946 --> 01:44:21,680 2361 01:44:21,680 --> 01:44:23,150 >> Sme na konci. 2362 01:44:23,150 --> 01:44:26,689 Ďakujeme vám za ložiská so mnou. 2363 01:44:26,689 --> 01:44:28,480 Tak poďme hovoriť o referenčná architektúra. 2364 01:44:28,480 --> 01:44:33,440 DynamoDB sedí v strede tak, veľkú časť infraštruktúry AWS. 2365 01:44:33,440 --> 01:44:37,090 V podstate môžete pripojiť ho až na čokoľvek chcete. 2366 01:44:37,090 --> 01:44:45,600 Aplikácií pomocou Dynamo zahŕňajú Lambda, ElastiCache, CloudSearch, 2367 01:44:45,600 --> 01:44:49,890 tlačiť dáta von do Elastic MapReduce, export import z DynamoDB 2368 01:44:49,890 --> 01:44:52,370 do S3, všetky druhy pracovných postupov. 2369 01:44:52,370 --> 01:44:54,120 Ale pravdepodobne najlepšie vec hovoriť, 2370 01:44:54,120 --> 01:44:56,119 a to je to, čo je naozaj Zaujímavé je, keď sme 2371 01:44:56,119 --> 01:44:58,350 hovoriť o udalosti riadené aplikácie. 2372 01:44:58,350 --> 01:45:00,300 >> Toto je príklad interný projekt 2373 01:45:00,300 --> 01:45:04,850 že máme kde sme vlastne publikovanie zhromažďovať výsledky prieskumu. 2374 01:45:04,850 --> 01:45:07,700 Takže v e-maile odkaz, ktorý vyšleme, tam bude 2375 01:45:07,700 --> 01:45:11,350 byť trochu odkaz porekadlá click tu v reakcii na zisťovanie. 2376 01:45:11,350 --> 01:45:14,070 A keď sa človek kliknutie odkazujúce, čo sa stane, 2377 01:45:14,070 --> 01:45:18,020 je, že sa strhnúť bezpečné Formulár prieskumu HTML z S3. 2378 01:45:18,020 --> 01:45:18,980 Neexistuje žiadny server. 2379 01:45:18,980 --> 01:45:20,600 To je len objekt S3. 2380 01:45:20,600 --> 01:45:22,770 >> Táto forma príde, načíta do prehliadača. 2381 01:45:22,770 --> 01:45:24,240 Má to chrbtica. 2382 01:45:24,240 --> 01:45:30,160 Má to zložitý JavaScript že je to beh. 2383 01:45:30,160 --> 01:45:33,557 Takže je to veľmi bohatá aplikácia beží v prehliadači klienta. 2384 01:45:33,557 --> 01:45:36,390 Oni nevedia, že oni nie sú interakciu s back end. 2385 01:45:36,390 --> 01:45:38,220 V tomto bode, je to všetko prehliadač. 2386 01:45:38,220 --> 01:45:41,780 >> Oni zverejňovať výsledky na to, čo nazývame Amazon API Gateway. 2387 01:45:41,780 --> 01:45:46,270 API Gateway je jednoducho web API že môžete definovať a pripojiť 2388 01:45:46,270 --> 01:45:47,760 na čo chcete. 2389 01:45:47,760 --> 01:45:50,990 V tomto konkrétnom prípade, my sme zahnutý do funkcie Lambda. 2390 01:45:50,990 --> 01:45:54,797 >> Takže moje POST operácie deje žiadny server. 2391 01:45:54,797 --> 01:45:56,380 V podstate, že API brány sedí tam. 2392 01:45:56,380 --> 01:45:58,770 To mi nič nestojí, kým ľudí štart vysielania na to, že jo? 2393 01:45:58,770 --> 01:46:00,269 Funkcia Lambda tam jednoducho sedí. 2394 01:46:00,269 --> 01:46:03,760 A mňa to nič nestojí, kým ľudia začnú biť ju. 2395 01:46:03,760 --> 01:46:07,270 Takže môžete vidieť, ako objem sa zvyšuje, to je, keď sa obvinenia prísť. 2396 01:46:07,270 --> 01:46:09,390 Nie som spustený server 7/24. 2397 01:46:09,390 --> 01:46:12,310 >> Tak som vytiahnuť formulár dole z nádoby, 2398 01:46:12,310 --> 01:46:15,719 a ja som písať prostredníctvom rozhrania API Brána do funkcie Lambda. 2399 01:46:15,719 --> 01:46:17,510 A potom Lambda funkcie hovorí, viete, 2400 01:46:17,510 --> 01:46:20,600 to, čo som dostal nejaké PIIS, niektorí osobné údaje 2401 01:46:20,600 --> 01:46:21,480 V týchto odpovedí. 2402 01:46:21,480 --> 01:46:23,020 Dostal som komentáre prichádzajúce z užívateľov. 2403 01:46:23,020 --> 01:46:24,230 Mám e-mailové adresy. 2404 01:46:24,230 --> 01:46:26,190 Mám užívateľské mená. 2405 01:46:26,190 --> 01:46:27,810 >> Dovoľte mi, aby som rozdelil to preč. 2406 01:46:27,810 --> 01:46:30,280 Budem vytvárať nejaké metadáta z tohto záznamu. 2407 01:46:30,280 --> 01:46:32,850 A budem tlačiť metadáta do DynamoDB. 2408 01:46:32,850 --> 01:46:36,059 A mohol by som šifrovať všetky údaje a zatlačte ju do DynamoDB keď budem chcieť. 2409 01:46:36,059 --> 01:46:38,600 Ale je to pre mňa jednoduchšie, v tomto prípad použitia, pokračovať o slovo, 2410 01:46:38,600 --> 01:46:42,800 Budem tlačiť raw dát do šifrované S3 lopaty. 2411 01:46:42,800 --> 01:46:47,240 Tak som použiť postavený v S3 strane servera šifrovanie a správy kľúčov Amazon 2412 01:46:47,240 --> 01:46:51,600 Služba tak, že mám kľúč, ktorý sa môže otáčať v pravidelných intervaloch, 2413 01:46:51,600 --> 01:46:55,010 a ja môžem ochrániť, že PII dát ako súčasť celého tohto pracovného postupu. 2414 01:46:55,010 --> 01:46:55,870 >> Tak čo som to urobil? 2415 01:46:55,870 --> 01:47:00,397 Práve som nasadený celok aplikácie, a ja nemám server. 2416 01:47:00,397 --> 01:47:02,980 Tak je to, čo udalosť riadený aplikácii architektúra urobí za vás. 2417 01:47:02,980 --> 01:47:05,730 >> Teraz, ak si myslíte, že o v prípade použitia pre tohle-- 2418 01:47:05,730 --> 01:47:08,730 Máme iné zákazníkov, ja hovorím sa o tomto presnom architektúre, ktorí 2419 01:47:08,730 --> 01:47:14,560 spustiť neobyčajne veľké kampane, ktorí sú pri pohľade na to a ísť, oh my. 2420 01:47:14,560 --> 01:47:17,840 Pretože teraz, môžu v podstate tlačiť to tam, 2421 01:47:17,840 --> 01:47:21,900 dovoľte, že kampaň len sedieť tam, kým sa na trh, a nie 2422 01:47:21,900 --> 01:47:24,400 musieť starať o obr o aký druh infraštruktúry 2423 01:47:24,400 --> 01:47:26,120 bude tam na jej podporu. 2424 01:47:26,120 --> 01:47:28,600 A potom, akonáhle že kampaň je hotovo, 2425 01:47:28,600 --> 01:47:31,520 je to ako na infraštruktúru Len okamžite zmizne 2426 01:47:31,520 --> 01:47:33,680 pretože tam naozaj žiadna infraštruktúra. 2427 01:47:33,680 --> 01:47:35,660 Je to len kód, ktorý sedí na Lambda. 2428 01:47:35,660 --> 01:47:38,560 Je to len dáta, ktoré sedí v DynamoDB. 2429 01:47:38,560 --> 01:47:41,340 Je to úžasný spôsob, pri tvorbe aplikácií. 2430 01:47:41,340 --> 01:47:43,970 >> Divákov: Tak to je viac pominuteľný, než by bolo 2431 01:47:43,970 --> 01:47:45,740 ak to bolo uložené na skutočné serveru? 2432 01:47:45,740 --> 01:47:46,823 >> RICK Houlihan: Rozhodne. 2433 01:47:46,823 --> 01:47:49,190 Vzhľadom k tomu, že inštancia servera by mala byť 7 dvadsať čtyřitin. 2434 01:47:49,190 --> 01:47:51,954 To má byť k dispozícii pre niekto reagovať. 2435 01:47:51,954 --> 01:47:52,620 Tak vieš čo? 2436 01:47:52,620 --> 01:47:55,410 S3 je k dispozícii 7 dvadsať čtyřitin. 2437 01:47:55,410 --> 01:47:57,100 S3 vždy odpovie. 2438 01:47:57,100 --> 01:47:59,320 A S3 je veľmi, veľmi dobrá pri servírujú objekty. 2439 01:47:59,320 --> 01:48:02,590 Tieto objekty môžu byť HTML súbory, alebo JavaScript súbory, alebo čokoľvek chcete. 2440 01:48:02,590 --> 01:48:07,430 Môžete spustiť veľmi bohatých webových aplikácií z S3 vedierka, a ľudia robia. 2441 01:48:07,430 --> 01:48:10,160 >> A tak to je myšlienka tu je dostať sa preč od cesty 2442 01:48:10,160 --> 01:48:11,270 sme sa o tom premýšľať. 2443 01:48:11,270 --> 01:48:14,270 Všetci sme si myslela, že v Podmienky serverov a hostiteľov. 2444 01:48:14,270 --> 01:48:16,580 Nie je to o tom ešte. 2445 01:48:16,580 --> 01:48:19,310 Je to o infraštruktúry ako kód. 2446 01:48:19,310 --> 01:48:22,470 Nasadiť kód do cloudu a nechajte oblak spustite ho za vás. 2447 01:48:22,470 --> 01:48:24,980 A to je to, čo AWS sa snaží robiť. 2448 01:48:24,980 --> 01:48:29,690 >> Divákov: Takže vaše zlaté poľa v stredu API brány nie je serverom-like, 2449 01:48:29,690 --> 01:48:30,576 ale namiesto toho je jen-- 2450 01:48:30,576 --> 01:48:32,850 >> RICK Houlihan: Môžete si myslieť o tom ako fasáda servera. 2451 01:48:32,850 --> 01:48:38,040 Všetko, čo to je, je to bude trvať HTTP požadovať a mapovať na iný proces. 2452 01:48:38,040 --> 01:48:39,192 To je všetko, čo robí. 2453 01:48:39,192 --> 01:48:41,525 A v tomto prípade, my mapovanie to na funkciu Lambda. 2454 01:48:41,525 --> 01:48:44,119 2455 01:48:44,119 --> 01:48:45,410 Dobre, takže to je všetko, čo mám. 2456 01:48:45,410 --> 01:48:46,190 Ďakujem mnohokrát. 2457 01:48:46,190 --> 01:48:46,800 Cením si to. 2458 01:48:46,800 --> 01:48:48,100 Viem, že chceme trochu v čase. 2459 01:48:48,100 --> 01:48:49,980 A dúfajme, že vy ste dostal trochu informácií 2460 01:48:49,980 --> 01:48:51,410 ktoré si môžete odniesť aj dnes. 2461 01:48:51,410 --> 01:48:53,520 A ospravedlňujem sa, ak som išiel cez niektoré z vašich hláv, 2462 01:48:53,520 --> 01:48:56,697 ale je tu veľká kopa základné znalosti foundational 2463 01:48:56,697 --> 01:48:58,280 si myslím, že je veľmi cenné pre vás. 2464 01:48:58,280 --> 01:48:59,825 Takže ďakujem za to, že ma. 2465 01:48:59,825 --> 01:49:00,325 [APPLAUSE] 2466 01:49:00,325 --> 01:49:02,619 Divákov: [Nepočuteľné] je, keď ste hovoril 2467 01:49:02,619 --> 01:49:05,160 museli ste prejsť vec od začiatku až do konca 2468 01:49:05,160 --> 01:49:07,619 získať správne hodnoty alebo rovnakej hodnoty, 2469 01:49:07,619 --> 01:49:09,410 ako by sa hodnoty ak [nepočuteľný] zmeniť. 2470 01:49:09,410 --> 01:49:10,480 >> RICK Houlihan: Oh, idempotentních? 2471 01:49:10,480 --> 01:49:11,800 Ako by sa hodnoty zmenia? 2472 01:49:11,800 --> 01:49:15,180 No, pretože keby som nebol spustený to celú cestu až do konca, 2473 01:49:15,180 --> 01:49:19,770 potom neviem, aké zmeny boli vykonané v poslednú míľu. 2474 01:49:19,770 --> 01:49:22,144 Nebude to byť rovnaké údaje ako to, čo som videl. 2475 01:49:22,144 --> 01:49:24,560 Publikum: Oh, takže stačí nedostal celý vstup. 2476 01:49:24,560 --> 01:49:24,770 RICK Houlihan: Správne. 2477 01:49:24,770 --> 01:49:26,895 Musíte ísť od začiatku až do konca, a potom je to 2478 01:49:26,895 --> 01:49:29,280 Bude konzistentného stavu. 2479 01:49:29,280 --> 01:49:31,520 Super. 2480 01:49:31,520 --> 01:49:35,907 >> Divákov: Takže ste nám ukázal DynamoDB môže robiť dokument alebo hodnotu kľúča. 2481 01:49:35,907 --> 01:49:38,740 A my sme strávili veľa času na Hodnota kľúče s hash a spôsoby 2482 01:49:38,740 --> 01:49:40,005 hodiť okolo. 2483 01:49:40,005 --> 01:49:43,255 Keď sa pozrel na týchto tabuliek, je to, že odchádzajúci za prístupu dokumentu? 2484 01:49:43,255 --> 01:49:44,600 >> RICK Houlihan: Ja by som nie hovoria, opúšťať to za sebou. 2485 01:49:44,600 --> 01:49:45,855 >> Divákov: Oni boli oddelení od the-- 2486 01:49:45,855 --> 01:49:49,140 >> RICK Houlihan: S dokumentom prístup, typ dokument DynamoDB 2487 01:49:49,140 --> 01:49:50,880 Je len myslieť ako ďalší atribút. 2488 01:49:50,880 --> 01:49:53,560 Je to vlastnosť, ktorá obsahuje hierarchická štruktúra dát. 2489 01:49:53,560 --> 01:49:56,980 A potom sa v dotazoch, môžete použiť vlastnosti 2490 01:49:56,980 --> 01:49:59,480 z týchto objektov pomocou Object Notation. 2491 01:49:59,480 --> 01:50:03,562 Tak som môžete filtrovať na vnorené vlastnosť dokumentu JSON. 2492 01:50:03,562 --> 01:50:05,520 Divákov: Takže kedykoľvek som sa urobiť prístup dokumentu, 2493 01:50:05,520 --> 01:50:07,906 Môžem nejako doraziť na tabular-- 2494 01:50:07,906 --> 01:50:08,780 Divákov: Rozhodne. 2495 01:50:08,780 --> 01:50:09,800 Publikum: --indexes a veci, ktoré práve hovorili. 2496 01:50:09,800 --> 01:50:11,280 RICK Houlihan: Jo, ten indexy a všetko, 2497 01:50:11,280 --> 01:50:13,363 keď chcete indexu vlastnosti JSON, 2498 01:50:13,363 --> 01:50:18,230 tak, že budeme musieť urobiť, je, ak vložíte objekt JSON alebo dokumentu 2499 01:50:18,230 --> 01:50:20,780 do Dynamu, mali by ste použiť prúdy. 2500 01:50:20,780 --> 01:50:22,400 Prúdy by čítať vstup. 2501 01:50:22,400 --> 01:50:24,340 Vy by ste dostať, že JSON objekt a vy by ste povedal OK, 2502 01:50:24,340 --> 01:50:26,030 čo je to vlastnosť chcem index? 2503 01:50:26,030 --> 01:50:28,717 >> Môžete vytvárať odvodené tabuľky. 2504 01:50:28,717 --> 01:50:30,300 Teraz, keď je to tak, ako to funguje práve teraz. 2505 01:50:30,300 --> 01:50:32,650 Nechceme, aby vás na indexe priamo tieto vlastnosti. 2506 01:50:32,650 --> 01:50:33,520 >> Divákov: Tabularizing dokumentov. 2507 01:50:33,520 --> 01:50:36,230 >> RICK Houlihan: Presne tak, sploštenie to, tabularizing to presne. 2508 01:50:36,230 --> 01:50:37,415 To je to, čo s tým robiť. 2509 01:50:37,415 --> 01:50:37,860 >> Divákov: Ďakujem. 2510 01:50:37,860 --> 01:50:39,609 >> RICK Houlihan: Jo, absolútne, ďakujem. 2511 01:50:39,609 --> 01:50:42,240 Divákov: Takže je to trochu Mongo stretáva REDIS classifers. 2512 01:50:42,240 --> 01:50:43,990 >> RICK Houlihan: Jo, to je veľa ako to. 2513 01:50:43,990 --> 01:50:45,940 To je dobrý popis pre neho. 2514 01:50:45,940 --> 01:50:47,490 Super. 2515 01:50:47,490 --> 01:50:49,102