1 00:00:00,000 --> 00:00:04,969 >> [MUSIC nagpe-play] 2 00:00:04,969 --> 00:00:06,010 RICK Houlihan: Lahat ng karapatan. 3 00:00:06,010 --> 00:00:06,600 Hi, lahat. 4 00:00:06,600 --> 00:00:07,670 Ang pangalan ko ay Rick Houlihan. 5 00:00:07,670 --> 00:00:10,330 Ako ay isang senior principal solusyon arkitekto sa AWS. 6 00:00:10,330 --> 00:00:14,070 I-focus sa NoSQL at DynamoDB teknolohiya. 7 00:00:14,070 --> 00:00:16,930 Naririto ako ngayon upang makipag-usap sa sa iyo ng kaunti tungkol sa mga. 8 00:00:16,930 --> 00:00:18,970 >> Aking background ay lalo na sa layer data. 9 00:00:18,970 --> 00:00:21,390 Ako na ginugol ang kalahati ng aking pag-unlad karera pagsulat database, 10 00:00:21,390 --> 00:00:25,930 access ng data, mga solusyon para sa iba't ibang mga application. 11 00:00:25,930 --> 00:00:30,000 Ako sa Cloud virtualization para sa mga tungkol sa 20 taon. 12 00:00:30,000 --> 00:00:33,460 Kaya bago ang Cloud ay ang Cloud, ginamit namin upang tumawag ito utility computing. 13 00:00:33,460 --> 00:00:37,170 At ang mga ideya ay, ito ay tulad PG & E, magbabayad ka para sa kung ano ang iyong gamitin. 14 00:00:37,170 --> 00:00:38,800 Ngayon tinatawag naming ito sa cloud. 15 00:00:38,800 --> 00:00:41,239 >> Ngunit sa paglipas ng mga taon, ako ay nagtrabaho para sa isang pares ng mga kumpanya 16 00:00:41,239 --> 00:00:42,530 marahil mo na hindi kailanman narinig ng. 17 00:00:42,530 --> 00:00:47,470 Ngunit ko na naipon ng isang listahan ng mga teknikal na kabutihan, Hulaan ko gusto mong sabihin. 18 00:00:47,470 --> 00:00:51,620 Mayroon akong walong mga patente sa sistema Cloud virtualization, microprocessor disenyo, 19 00:00:51,620 --> 00:00:54,440 complex pagpoproseso ng kaganapan, at iba pang mga lugar na rin. 20 00:00:54,440 --> 00:00:58,290 >> Kaya sa panahon ngayon, ang focus ko karamihan sa NoSQL teknolohiya at ang susunod na henerasyon 21 00:00:58,290 --> 00:00:59,450 database. 22 00:00:59,450 --> 00:01:03,370 At na sa pangkalahatan ay kung ano ako pagpunta na dito ang pakikipag-usap sa iyo ngayon tungkol sa. 23 00:01:03,370 --> 00:01:06,030 Kaya kung ano ang maaari mong asahan mula sa session na ito, 24 00:01:06,030 --> 00:01:08,254 kami ay pumunta sa pamamagitan ng isang maikling kasaysayan ng data processing. 25 00:01:08,254 --> 00:01:10,420 Ito ay palaging kapaki-pakinabang sa maunawaan kung saan kami ay dumating mula sa 26 00:01:10,420 --> 00:01:12,400 at kung bakit hindi namin kung saan kami. 27 00:01:12,400 --> 00:01:15,600 At kami ay makipag-usap sa isang maliit na kaunti tungkol NoSQL technology 28 00:01:15,600 --> 00:01:17,500 mula sa isang pangunahing kinatatayuan. 29 00:01:17,500 --> 00:01:19,870 >> Makikipag-ugnay kami sa ilan sa mga ang DynamoDB internals. 30 00:01:19,870 --> 00:01:24,350 DynamoDB ay AWS ni walang lasa. 31 00:01:24,350 --> 00:01:27,340 Ito ay isang ganap na pinamamahalaang at naka-host NoSQL solusyon. 32 00:01:27,340 --> 00:01:32,420 At kami na makipag-usap nang kaunti tungkol sa talahanayan istraktura, mga API, mga uri ng data, index, 33 00:01:32,420 --> 00:01:35,177 at ang ilan sa mga internals ng na teknolohiya DynamoDB. 34 00:01:35,177 --> 00:01:37,760 Babalikan ka namin sa ilan sa mga disenyo pattern at pinakamahusay na kasanayan. 35 00:01:37,760 --> 00:01:39,968 Susubukan naming makipag-usap tungkol sa kung paano mo gamitin ang teknolohiyang ito para sa ilang 36 00:01:39,968 --> 00:01:41,430 ng application ngayon. 37 00:01:41,430 --> 00:01:44,820 At pagkatapos ay namin makipag-usap nang kaunti tungkol sa paglaki o ang paglitaw 38 00:01:44,820 --> 00:01:48,980 ng isang bagong tularan sa programming tinatawag na mga aplikasyon kaganapang hinihimok ng 39 00:01:48,980 --> 00:01:51,580 at kung paano gumaganap DynamoDB sa na rin. 40 00:01:51,580 --> 00:01:54,690 At kami ay umalis sa iyo ng isang maliit na piraso ng isang architecture reference talakayan 41 00:01:54,690 --> 00:01:59,540 upang maaari naming makipag-usap tungkol sa ilan sa ang mga paraan na maaari mong gamitin DynamoDB. 42 00:01:59,540 --> 00:02:04,116 >> Kaya unang off-- ito ay isang tanong Marinig ko ng maraming ay, kung ano ang isang database. 43 00:02:04,116 --> 00:02:06,240 Ang isang pulutong ng mga tao sa tingin nila alam kung ano ang isang database ay. 44 00:02:06,240 --> 00:02:08,360 Kung ikaw Google, makikita mo na ito. 45 00:02:08,360 --> 00:02:11,675 Ito ay isang isang naka-balangkas na hanay ng mga data na hawak sa isang computer, lalo na ang isa na 46 00:02:11,675 --> 00:02:13,600 ay naa-access sa iba't-ibang mga paraan. 47 00:02:13,600 --> 00:02:16,992 Ipagpalagay ko na ang isang magandang kahulugan ng isang modernong database. 48 00:02:16,992 --> 00:02:19,450 Ngunit hindi ko gusto ito, dahil ay nagpapahiwatig ng isang pares ng mga bagay-bagay. 49 00:02:19,450 --> 00:02:20,935 Ito ay nagpapahiwatig ng istraktura. 50 00:02:20,935 --> 00:02:23,120 At ito ay nagpapahiwatig na ito ay sa isang computer. 51 00:02:23,120 --> 00:02:25,750 At database ay hindi palaging umiiral sa mga computer. 52 00:02:25,750 --> 00:02:28,020 Mga Database talagang umiiral sa maraming paraan. 53 00:02:28,020 --> 00:02:32,000 >> Kaya ang isang mas mahusay na kahulugan ng isang database ay isang bagay na tulad nito. 54 00:02:32,000 --> 00:02:34,786 Ang database ay isang organisado mekanismo para sa pagtatago, pamamahala, 55 00:02:34,786 --> 00:02:35,910 at pagkuha ng impormasyon. 56 00:02:35,910 --> 00:02:36,868 Ito ay mula sa About.com. 57 00:02:36,868 --> 00:02:42,080 Kaya gusto ko ito dahil ito ay talagang pag-uusap tungkol sa isang database sa pagiging isang repository, 58 00:02:42,080 --> 00:02:44,800 isang lalagyan ng impormasyon, hindi kinakailangan 59 00:02:44,800 --> 00:02:46,780 isang bagay na nakapatong sa isang computer. 60 00:02:46,780 --> 00:02:49,290 At sa buong kasaysayan, kami ay hindi laging may mga computer. 61 00:02:49,290 --> 00:02:52,110 >> Ngayon, kung tatanungin ko ang average developer ngayon kung ano ang 62 00:02:52,110 --> 00:02:54,770 isang database, na ang sagot na nakukuha ko. 63 00:02:54,770 --> 00:02:56,070 Sa isang lugar ang maaari kong stick stuff. 64 00:02:56,070 --> 00:02:56,670 Right? 65 00:02:56,670 --> 00:02:58,725 At ito ay totoo. 66 00:02:58,725 --> 00:02:59,600 Ngunit ito ay kapus-palad. 67 00:02:59,600 --> 00:03:02,700 Dahil ang mga database ay talagang ang pundasyon ng modernong app. 68 00:03:02,700 --> 00:03:04,810 Ito ay ang pundasyon ng bawat application. 69 00:03:04,810 --> 00:03:07,240 At kung paano mo magtayo na database, kung paano mo istraktura 70 00:03:07,240 --> 00:03:11,750 ang data na iyon ay pagpunta sa utos kung paano na gumaganap application bilang masukat mo. 71 00:03:11,750 --> 00:03:14,640 >> Kaya ng maraming ng aking trabaho ngayon ay ang pagharap sa kung ano ang 72 00:03:14,640 --> 00:03:17,180 ang mangyayari kapag ang mga developer kumuha ito diskarte 73 00:03:17,180 --> 00:03:19,510 at pakikitungo sa mga resulta ng isang application na 74 00:03:19,510 --> 00:03:24,966 ay scaling ngayon lampas sa orihinal na layunin at paghihirap mula sa masamang disenyo. 75 00:03:24,966 --> 00:03:26,840 Kaya sana kapag ikaw lakarin ang layo sa araw, makikita mo 76 00:03:26,840 --> 00:03:29,010 magkaroon ng isang pares ng mga kasangkapan sa iyong sinturon na kailangan panatilihin mo 77 00:03:29,010 --> 00:03:32,566 mula sa paggawa ng mga parehong mga pagkakamali. 78 00:03:32,566 --> 00:03:33,066 Lahat tama. 79 00:03:33,066 --> 00:03:36,360 Kaya sabihin makipag-usap tungkol sa isang maliit na piraso ng ang timeline ng teknolohiya database. 80 00:03:36,360 --> 00:03:38,830 Sa tingin ko ko basahin ang isang hindi na matagal na article ago 81 00:03:38,830 --> 00:03:43,020 at sinabi ng isang bagay sa lines-- ito ay isang napaka mala-tula statement. 82 00:03:43,020 --> 00:03:46,590 Ito ang sinabi ng history ng data processing ay 83 00:03:46,590 --> 00:03:49,350 puno ng mataas watermark ng kasaganaan data. 84 00:03:49,350 --> 00:03:49,920 SIGE. 85 00:03:49,920 --> 00:03:52,532 Ngayon, hulaan ko na ang uri ng tunay. 86 00:03:52,532 --> 00:03:54,990 Ngunit ang tunay na ako ay tumingin sa ay bilang ang kasaysayan ay aktwal na napuno 87 00:03:54,990 --> 00:03:56,820 na may mataas na antas ng tubig ng presyon data. 88 00:03:56,820 --> 00:04:00,040 Dahil ang mga rate ng data ng paglunok hindi napupunta down. 89 00:04:00,040 --> 00:04:01,360 Napupunta up lamang ito. 90 00:04:01,360 --> 00:04:03,670 >> At pagbabago ay nangyayari kapag nakikita namin na presyon ng data, na kung saan 91 00:04:03,670 --> 00:04:07,825 ay ang halaga ng data na ngayon sa darating na sa system. 92 00:04:07,825 --> 00:04:12,027 At ito ay hindi maasikaso mahusay sa alinman sa panahon o sa gastos. 93 00:04:12,027 --> 00:04:14,110 At na kapag nagsimula kami upang tumingin sa presyon ng data. 94 00:04:14,110 --> 00:04:15,920 >> Kaya kapag tinitingnan namin ang mga unang database, ito 95 00:04:15,920 --> 00:04:17,180 ay ang isa na ay sa pagitan ng aming mga tainga. 96 00:04:17,180 --> 00:04:18,310 Lahat ng Kami ay ipinanganak sa mga ito. 97 00:04:18,310 --> 00:04:19,194 Ang ganda ng database. 98 00:04:19,194 --> 00:04:21,110 Ito ay may isang mataas na availability. 99 00:04:21,110 --> 00:04:21,959 Ito ay palaging on. 100 00:04:21,959 --> 00:04:23,930 Maaari mong palaging makakuha ng ito. 101 00:04:23,930 --> 00:04:24,890 >> Ngunit ito ay single user. 102 00:04:24,890 --> 00:04:26,348 Hindi ko ibahagi ang aking mga saloobin sa iyo. 103 00:04:26,348 --> 00:04:28,370 Hindi ka maaaring makakuha ng aking mga saloobin kapag gusto mo ito. 104 00:04:28,370 --> 00:04:30,320 At ang kanilang abilitiy ay hindi mabuti. 105 00:04:30,320 --> 00:04:32,510 Nakalimutan namin mga bagay-bagay. 106 00:04:32,510 --> 00:04:36,540 Tuwing ngayon at pagkatapos, isa sa amin dahon at gumagalaw sa sa isa pang pag-iral 107 00:04:36,540 --> 00:04:39,110 at mawala ang namin ang lahat na nasa na database. 108 00:04:39,110 --> 00:04:40,640 Kaya na hindi lahat na mabuti. 109 00:04:40,640 --> 00:04:43,189 >> At ito ay nagtrabaho rin sa paglipas ng panahon kapag kami ay bumalik sa araw 110 00:04:43,189 --> 00:04:46,230 kapag ang lahat ng tunay na kailangan naming malaman ay saan tayo pupunta upang pumunta sa bukas 111 00:04:46,230 --> 00:04:49,630 o kung saan kami lumikom ng pinakamahusay na pagkain. 112 00:04:49,630 --> 00:04:52,820 Ngunit bilang namin na nagsimula sa paglaki bilang isang kabihasnan at pamahalaan na nagsimula 113 00:04:52,820 --> 00:04:55,152 na dumating sa pagiging, at nagsimula sa mga negosyo na nagbabago, 114 00:04:55,152 --> 00:04:57,360 namin na nagsimula sa Napagtanto namin kailangan ng kaunti pa kaysa sa kung ano 115 00:04:57,360 --> 00:04:58,210 maaari naming ilagay sa aming mga ulo. 116 00:04:58,210 --> 00:04:58,870 Lahat tama? 117 00:04:58,870 --> 00:05:00,410 >> Kailangan naming ang mga sistema ng mga record. 118 00:05:00,410 --> 00:05:02,220 Kailangan naming ang mga lugar upang ma-imbak ng data. 119 00:05:02,220 --> 00:05:05,450 Kaya't nagsimula kaming mga dokumento ng pagsulat, paglikha ng mga aklatan at mga archive. 120 00:05:05,450 --> 00:05:08,000 Sinimulan namin ang pagbuo ng isang sistema ng isang ledger accounting. 121 00:05:08,000 --> 00:05:12,200 At sistemang iyon ng ledger pagbilang bumangga sa mundo para sa maraming siglo, 122 00:05:12,200 --> 00:05:15,580 at marahil kahit na millennia bilang namin uri ng lumago hanggang sa punto 123 00:05:15,580 --> 00:05:18,420 kung saan daig na load data sa kakayahan ng mga sistema ng 124 00:05:18,420 --> 00:05:19,870 para ma-naglalaman ito. 125 00:05:19,870 --> 00:05:22,070 >> At ito ang tunay na nangyari sa 1880s. 126 00:05:22,070 --> 00:05:22,570 Right? 127 00:05:22,570 --> 00:05:24,390 Sa 1880 US Census. 128 00:05:24,390 --> 00:05:26,976 Ito ay talagang kung saan ang pagpalit point modernong data processing. 129 00:05:26,976 --> 00:05:28,850 Ito ang punto kung na kung saan ang halaga ng data 130 00:05:28,850 --> 00:05:32,060 na na nakolekta sa pamamagitan ng Nakakuha gobyerno ng Estados Unidos sa punto 131 00:05:32,060 --> 00:05:34,005 kung saan ito kinuha walong taon upang maproseso. 132 00:05:34,005 --> 00:05:36,350 >> Ngayon, walong years-- bilang alam mo, ang census 133 00:05:36,350 --> 00:05:39,180 Nagpapatakbo bawat 10 years-- kaya medyo maliwanag na sa pamamagitan ng oras namin 134 00:05:39,180 --> 00:05:41,419 Nakakuha ang 1890 census, ang dami ng data na 135 00:05:41,419 --> 00:05:43,210 ay pagpunta upang ma-process sa pamamagitan ng pamahalaan ay 136 00:05:43,210 --> 00:05:46,335 pagpunta sa lampasan ang 10 taon na ito nais kumuha sa inilunsad ang bagong census. 137 00:05:46,335 --> 00:05:47,250 Ito ay isang problema. 138 00:05:47,250 --> 00:05:49,000 >> Kaya ang isang tao na may pangalang Herman Hollerith ay dumating kasama 139 00:05:49,000 --> 00:05:52,640 at siya imbento unit record suntok cards, dating ng card reader, suntok card 140 00:05:52,640 --> 00:05:58,420 tabiyuleitor, at ang paghahambing ng ang mga mekanismo para sa teknolohiyang ito. 141 00:05:58,420 --> 00:06:01,860 At na kumpanya na siya nabuo sa panahon, kasama ang isang pares ng mga iba, 142 00:06:01,860 --> 00:06:05,450 tunay na naging isa sa mga haligi ng isang maliit na kumpanya alam natin ngayon na tinatawag na IBM. 143 00:06:05,450 --> 00:06:08,417 >> Kaya IBM orihinal ay sa ang database ng negosyo. 144 00:06:08,417 --> 00:06:09,750 At na talaga kung ano ang kanilang ginawa. 145 00:06:09,750 --> 00:06:11,110 Ginawa nila pagpoproseso ng data. 146 00:06:11,110 --> 00:06:15,400 >> Bilang kaya ang paglaganap ng suntok cards, isang mapanlikha mekanismo 147 00:06:15,400 --> 00:06:18,560 ng pagiging able sa pagkilos na technology sa poll pinagsunod-sunod na mga hanay ng mga resulta. 148 00:06:18,560 --> 00:06:20,726 Maaari mong makita sa larawan na ito doon kami ay may isang little-- 149 00:06:20,726 --> 00:06:23,970 ito ay isang maliit small-- ngunit maaari mong makita isang napaka mapanlikha mekanismo ng makina 150 00:06:23,970 --> 00:06:26,970 kung saan mayroon kaming isang suntok card deck. 151 00:06:26,970 --> 00:06:28,720 At pagkuha ng isang tao isang maliit na birador 152 00:06:28,720 --> 00:06:31,400 at nananatili sa pamamagitan ng slot at pag-aangat up ito 153 00:06:31,400 --> 00:06:34,820 upang makakuha ng na tumutugma, na itakda pinagsunod-sunod ng mga resulta. 154 00:06:34,820 --> 00:06:36,270 >> Ito ay isang pagsasama-sama. 155 00:06:36,270 --> 00:06:38,690 Ginagawa namin ito sa lahat ng oras ngayon sa mga computer, 156 00:06:38,690 --> 00:06:40,100 kung saan mo ito sa database. 157 00:06:40,100 --> 00:06:41,620 Ginamit namin upang gawin ito nang manu-mano, di ba? 158 00:06:41,620 --> 00:06:42,994 Mga tao na ilagay ang mga bagay na sama-sama. 159 00:06:42,994 --> 00:06:45,440 At ito ay ang paglaganap sa mga dating ng mga card 160 00:06:45,440 --> 00:06:50,070 sa kung ano ang tinatawag naming drums data at reels data, paper tape. 161 00:06:50,070 --> 00:06:55,980 >> Kinuha ang industriya ng pagpoproseso ng data isang aralin mula sa mga piano player. 162 00:06:55,980 --> 00:06:57,855 Piano pabalik Player sa ang turn ng siglo 163 00:06:57,855 --> 00:07:02,100 ginagamit upang gamitin ang papel reels na may mga puwang sa upang sabihin dito kung aling mga key upang i-play. 164 00:07:02,100 --> 00:07:05,380 Kaya na teknolohiya ay iniangkop huli sa tindahan ng mga digital na data, 165 00:07:05,380 --> 00:07:08,070 dahil maaari nilang ilagay ang data na iyon papunta sa mga paper tape reels. 166 00:07:08,070 --> 00:07:10,870 >> Ngayon, bilang isang resulta, ang data ay actually-- paano 167 00:07:10,870 --> 00:07:14,960 na-access mo ang data na ito nang direkta ay nakasalalay sa kung paano mo na naka-imbak sa mga ito. 168 00:07:14,960 --> 00:07:17,825 Kaya kung ko bang ilagay ang data sa isang tape, Ako ay ma-access ang data nang linear. 169 00:07:17,825 --> 00:07:20,475 Ako ay upang pagulungin ang buong tape upang ma-access ang lahat ng mga data. 170 00:07:20,475 --> 00:07:22,600 Kung ko bang ilagay ang data sa suntok cards, maaari ko ma-access ito 171 00:07:22,600 --> 00:07:26,270 sa isang maliit na mas random fashion, marahil hindi bilang mabilis. 172 00:07:26,270 --> 00:07:30,770 >> Ngunit may mga limitasyon sa kung paano namin pag-access sa data batay sa kung paano ay naka-imbak. 173 00:07:30,770 --> 00:07:32,890 At kaya ito ay isang problema pagpunta sa '50s. 174 00:07:32,890 --> 00:07:37,890 Muli, maaari naming simulan upang makita na bilang namin bumuo ng mga bagong teknolohiya upang i-proseso 175 00:07:37,890 --> 00:07:41,670 ang data, kanan, ito ay bubukas up ang pinto para sa mga bagong solusyon, 176 00:07:41,670 --> 00:07:45,852 para sa mga bagong programa, ang mga bagong aplikasyon para sa data na iyon. 177 00:07:45,852 --> 00:07:47,810 At talagang, pamamahala maaaring ang dahilan 178 00:07:47,810 --> 00:07:49,435 kung bakit namin binuo ang ilan sa mga sistema. 179 00:07:49,435 --> 00:07:52,290 Ngunit mabilis na naging negosyo ang driver sa likod ng ebolusyon 180 00:07:52,290 --> 00:07:54,720 ng modernong database at modernong file system. 181 00:07:54,720 --> 00:07:56,870 >> Kaya ang susunod na bagay na dumating up ay sa '50s 182 00:07:56,870 --> 00:08:00,780 ay ang file system at ang pag-unlad ng random storage access. 183 00:08:00,780 --> 00:08:02,050 Ito ay maganda. 184 00:08:02,050 --> 00:08:06,230 Ngayon, ang lahat ng mga biglaang, maaari naming ilagay ang aming file sa kahit saan sa mga hard drive 185 00:08:06,230 --> 00:08:09,760 at maaari naming ma-access nang sapalaran ang data na ito. 186 00:08:09,760 --> 00:08:11,950 Maaari naming i-parse na impormasyon sa labas ng mga file. 187 00:08:11,950 --> 00:08:14,920 At nalutas namin ang lahat ng mundo ni problema sa pagpoproseso ng data. 188 00:08:14,920 --> 00:08:17,550 >> At na tumagal tungkol sa 20 o 30 taon hanggang sa paglaki 189 00:08:17,550 --> 00:08:22,100 ng pamanggit database, na kung saan ay kapag nagpasya kami ngayon sa mundo 190 00:08:22,100 --> 00:08:27,940 kailangang magkaroon ng isang lalagyan na pagkatalo mga paligid ng lungsod ng data sa kabuuan ng file 191 00:08:27,940 --> 00:08:29,540 sistema na nakagawa kami. Right? 192 00:08:29,540 --> 00:08:34,270 Masyadong maraming data na ibinahagi sa masyadong maraming lugar, ang mga de-pagkopya ng data, 193 00:08:34,270 --> 00:08:37,120 at ang gastos ng imbakan ay napakalubha. 194 00:08:37,120 --> 00:08:43,760 >> Sa '70s, ang pinakamahal na mapagkukunan na ang isang computer ay ay ang storage. 195 00:08:43,760 --> 00:08:46,200 Ang processor ay tiningnan bilang isang takdang halaga. 196 00:08:46,200 --> 00:08:49,030 Kapag bumili ako ng kahon, ang CPU ay ang ilang mga trabaho. 197 00:08:49,030 --> 00:08:51,960 Ito ay pagpunta sa umiikot kung tunay na ito ay gumagana o hindi. 198 00:08:51,960 --> 00:08:53,350 Iyan ay tunay na isang mas mababa gastos. 199 00:08:53,350 --> 00:08:56,030 >> Ngunit kung ano ang halaga sa akin bilang negosyo ay storage. 200 00:08:56,030 --> 00:09:00,020 Kung kailangan kong bumili ng higit pang mga disk susunod buwan, na ang isang tunay na gastos na babayaran ko. 201 00:09:00,020 --> 00:09:01,620 At imbakan na mahal. 202 00:09:01,620 --> 00:09:05,020 >> Ngayon fast forward 40 taon namin at kami ay may isang iba't ibang mga problema. 203 00:09:05,020 --> 00:09:10,020 Compute Ang ngayon ay ang pinaka mahal na mapagkukunan. 204 00:09:10,020 --> 00:09:11,470 Storage ay mura. 205 00:09:11,470 --> 00:09:14,570 Ibig kong sabihin, maaari naming pumunta sa kahit saan sa ulap at maaari naming mahanap ang cheap storage. 206 00:09:14,570 --> 00:09:17,190 Ngunit kung ano ang hindi ko mahanap ang murang compute. 207 00:09:17,190 --> 00:09:20,700 >> Kaya ang paglaki ng ngayong araw teknolohiya, ng teknolohiya database, 208 00:09:20,700 --> 00:09:23,050 ay talagang nakatuon sa paligid ipinamamahagi database 209 00:09:23,050 --> 00:09:26,960 na hindi magtiis sa ang parehong uri ng scale 210 00:09:26,960 --> 00:09:29,240 limitasyon ng pamanggit database. 211 00:09:29,240 --> 00:09:32,080 Susubukan naming makipag-usap nang kaunti tungkol sa kung ano na ang tunay na ibig sabihin. 212 00:09:32,080 --> 00:09:34,760 >> Ngunit isa sa mga dahilan at ang driver sa likod this-- namin 213 00:09:34,760 --> 00:09:38,290 usapan tungkol sa presyon ng data. 214 00:09:38,290 --> 00:09:41,920 Presyon ng Data ay isang bagay na na nag-mamaneho sa pagbabago. 215 00:09:41,920 --> 00:09:44,610 At kung titingnan mo sa paglipas ng sa huling limang taon, 216 00:09:44,610 --> 00:09:48,180 ito ay isang tsart ng kung ano ang data load sa buong pangkalahatang enterprise 217 00:09:48,180 --> 00:09:49,640 Mukhang sa huling limang taon. 218 00:09:49,640 --> 00:09:52,570 >> At ang mga pangkalahatang patakaran ng hinlalaki mga days-- kung pumunta ka Google-- 219 00:09:52,570 --> 00:09:55,290 ay 90% ng data na tindahan namin ngayon, at ito ay 220 00:09:55,290 --> 00:09:57,330 nabuo sa loob ng nakaraang dalawang taon. 221 00:09:57,330 --> 00:09:57,911 SIGE. 222 00:09:57,911 --> 00:09:59,410 Ngayon, ito ay hindi isang trend na ang bago. 223 00:09:59,410 --> 00:10:01,230 Ito ay isang trend na ang nangyaring pagpunta sa labas para sa 100 taon. 224 00:10:01,230 --> 00:10:03,438 Mula pa nang Herman Hollerith binuo ang dating ng card, 225 00:10:03,438 --> 00:10:08,040 Na-pagbuo namin repositoryo data at pagtitipon ng data sa mga kahanga-hanga rate. 226 00:10:08,040 --> 00:10:10,570 >> Kaya sa nakaraang 100 taon, nakakita kami ng lakad na ito. 227 00:10:10,570 --> 00:10:11,940 Iyan ay hindi pagpunta sa pagbabago. 228 00:10:11,940 --> 00:10:14,789 Pasulong, kami ay pagpunta upang makita ang ito, kung hindi isang pinabilis na trend. 229 00:10:14,789 --> 00:10:16,330 At maaari mong makita kung ano na kamukha. 230 00:10:16,330 --> 00:10:23,510 >> Kung ang isang negosyo noong 2010 ay nagkaroon ng isa terabyte ng data sa ilalim ng pamamahala, 231 00:10:23,510 --> 00:10:27,080 sa araw na iyon ay nangangahulugan na ang mga ito pamamahala 6.5 petabytes ng data. 232 00:10:27,080 --> 00:10:30,380 Iyan ay 6,500 beses na mas maraming data. 233 00:10:30,380 --> 00:10:31,200 At alam ko na ito. 234 00:10:31,200 --> 00:10:33,292 Ako ng trabaho sa mga negosyo sa bawat araw. 235 00:10:33,292 --> 00:10:35,000 Limang taon ang nakaraan, ako ay makipag-usap sa mga kumpanya 236 00:10:35,000 --> 00:10:38,260 na nais makipag-usap sa akin tungkol sa kung ano ang isang sakit ito ay upang pamahalaan terabytes ng data. 237 00:10:38,260 --> 00:10:39,700 At ang mga ito ay makipag-usap sa akin tungkol sa kung paano namin makita 238 00:10:39,700 --> 00:10:41,825 na ito ay marahil pagpunta upang maging isang petabyte o dalawang 239 00:10:41,825 --> 00:10:43,030 sa loob ng ilang taon. 240 00:10:43,030 --> 00:10:45,170 >> Ang mga kompanya ng ngayon ako pagtugon sa, 241 00:10:45,170 --> 00:10:48,100 at sila ay pakikipag-usap sa akin tungkol sa mga Ang problema ay may pagkakaroon ng pamamahala 242 00:10:48,100 --> 00:10:51,440 sampu, 20 petabytes ng data. 243 00:10:51,440 --> 00:10:53,590 Kaya ang pagsabog ng data sa industriya 244 00:10:53,590 --> 00:10:56,670 ang nagtutulak sa mga napakalaking kailangan para sa mas mahusay na solusyon. 245 00:10:56,670 --> 00:11:00,980 At ang pamanggit database ay hindi lamang ang buhay hanggang sa ang demand. 246 00:11:00,980 --> 00:11:03,490 >> At kaya may isang linear ugnayan sa pagitan ng presyon ng data 247 00:11:03,490 --> 00:11:05,210 at teknikal na pagbabago. 248 00:11:05,210 --> 00:11:07,780 Kasaysayan ay ipinapakita sa amin na ito, na sa paglipas ng panahon, 249 00:11:07,780 --> 00:11:11,090 kapag ang dami ng data na na mga pangangailangan upang ma-process 250 00:11:11,090 --> 00:11:15,490 lumampas sa kapasidad ng sistema upang i-proseso ang mga ito sa isang makatwirang panahon 251 00:11:15,490 --> 00:11:18,870 o sa isang makatwirang gastos, pagkatapos ay ang mga bagong teknolohiya 252 00:11:18,870 --> 00:11:21,080 ay imbento upang malutas ang mga problema. 253 00:11:21,080 --> 00:11:24,090 Ang mga bagong teknolohiya, naman, buksan ang pinto 254 00:11:24,090 --> 00:11:27,840 sa isa pang hanay ng mga problema, na kung saan ay pagtitipon ng mas maraming data. 255 00:11:27,840 --> 00:11:29,520 >> Ngayon, hindi namin pagpunta upang ihinto ito. 256 00:11:29,520 --> 00:11:30,020 Right? 257 00:11:30,020 --> 00:11:31,228 Hindi namin pagpunta upang ihinto ito. 258 00:11:31,228 --> 00:11:31,830 Bakit? 259 00:11:31,830 --> 00:11:35,520 Dahil hindi ka maaaring malaman ang lahat doon ay upang malaman sa uniberso. 260 00:11:35,520 --> 00:11:40,510 At hangga't kami ay buhay, sa buong kasaysayan ng tao, 261 00:11:40,510 --> 00:11:43,440 palagi naming hinihimok na malaman pa. 262 00:11:43,440 --> 00:11:49,840 >> Kaya ito ay tila sa bawat inch ilipat namin down ang landas ng pagkatuklas sa agham, 263 00:11:49,840 --> 00:11:54,620 ay multiply namin ang dami ng data na kailangan namin upang i-proseso exponentially 264 00:11:54,620 --> 00:11:59,920 bilang alisan ng takip kami ng higit pa at sa mga tungkol sa loob workings ng buhay, 265 00:11:59,920 --> 00:12:04,530 tungkol sa kung paano gumagana ang daigdig, tungkol sa na nagtutulak ng mga pagkatuklas sa agham, 266 00:12:04,530 --> 00:12:06,440 at ang mga likha na ang aming ginagawa ngayon. 267 00:12:06,440 --> 00:12:09,570 Ang dami ng data lamang patuloy na tataas. 268 00:12:09,570 --> 00:12:12,120 Kaya ang pagiging able sa pakikitungo sa ang problemang ito ay napakalubha. 269 00:12:12,120 --> 00:12:14,790 270 00:12:14,790 --> 00:12:17,410 >> Kaya isa sa mga bagay-bagay inaabangan namin ang bilang kung bakit NoSQL? 271 00:12:17,410 --> 00:12:19,200 Paano gumagana NoSQL malutas ang problemang ito? 272 00:12:19,200 --> 00:12:24,980 Well, pamanggit database, Nakabalangkas na Query Wika, 273 00:12:24,980 --> 00:12:28,600 SQL-- na talagang isang bumuo ng database-- pamanggit mga bagay na ito 274 00:12:28,600 --> 00:12:30,770 optimize para sa imbakan. 275 00:12:30,770 --> 00:12:33,180 >> Bumalik sa '70s, muli, disk ay magastos. 276 00:12:33,180 --> 00:12:36,990 Ang provisioning exercise ng imbakan sa enterprise ay walang katapusan. 277 00:12:36,990 --> 00:12:37,490 Alam ko. 278 00:12:37,490 --> 00:12:38,020 Ako ay nakatira dito. 279 00:12:38,020 --> 00:12:41,250 Sinulat ko ang driver na imbakan para sa isang Enterprised superserver kumpanya 280 00:12:41,250 --> 00:12:42,470 bumalik sa '90s. 281 00:12:42,470 --> 00:12:45,920 At ang bottom line ay napakasakit isa pang imbakan array ay lamang ng isang bagay na 282 00:12:45,920 --> 00:12:47,600 ang nangyari sa bawat araw sa enterprise. 283 00:12:47,600 --> 00:12:49,030 At ito ay hindi kailanman tumigil. 284 00:12:49,030 --> 00:12:52,690 Mas mataas na density ng imbakan, demand para sa mataas na storage density, 285 00:12:52,690 --> 00:12:56,340 at para sa mas mahusay na imbakan devices-- ito ay hindi kailanman tumigil. 286 00:12:56,340 --> 00:13:00,160 >> At NoSQL ay isang mahusay na teknolohiya dahil ito normalizes ang data. 287 00:13:00,160 --> 00:13:02,210 Ito de-duplicate ang data. 288 00:13:02,210 --> 00:13:07,180 Inilalagay nito ang data sa isang istraktura na ay agnostic sa bawat pattern access. 289 00:13:07,180 --> 00:13:11,600 Maaaring hit Maramihang mga application na SQL database, patakbuhin ad hoc query, 290 00:13:11,600 --> 00:13:15,950 at makakuha ng data sa hugis na sila kailangan sa proseso para sa kanilang mga workloads. 291 00:13:15,950 --> 00:13:17,570 Na tunog hindi kapani-paniwala. 292 00:13:17,570 --> 00:13:21,350 Ngunit sa ilalim na linya ay may anumang system, kung ito ay agnostiko sa lahat ng bagay, 293 00:13:21,350 --> 00:13:23,500 ito ay na-optimize para sa wala. 294 00:13:23,500 --> 00:13:24,050 SIGE? 295 00:13:24,050 --> 00:13:26,386 >> At iyon ang makuha namin sa ang pamanggit database. 296 00:13:26,386 --> 00:13:27,510 Ito ay na-optimize para sa imbakan. 297 00:13:27,510 --> 00:13:28,280 Ito ay naging normal. 298 00:13:28,280 --> 00:13:29,370 Ito ay pamanggit. 299 00:13:29,370 --> 00:13:31,660 Ito ay sumusuporta sa mga query sa pangyayaring ito. 300 00:13:31,660 --> 00:13:34,000 At ito at ito kaliskis patayo. 301 00:13:34,000 --> 00:13:39,030 >> Kung kailangan ko upang makakuha ng isang mas malaking database SQL o ng isang mas malakas na database SQL, 302 00:13:39,030 --> 00:13:41,090 Pumunta ako bumili ng mas malaking piraso ng bakal. 303 00:13:41,090 --> 00:13:41,600 SIGE? 304 00:13:41,600 --> 00:13:44,940 Nagtrabaho ako sa isang pulutong ng mga customer na sa pamamagitan ng malaking upgrade 305 00:13:44,940 --> 00:13:48,340 sa kanilang imprastraktura SQL lamang upang malaman ang anim na buwan, 306 00:13:48,340 --> 00:13:49,750 sila ay pagpindot muli sa pader. 307 00:13:49,750 --> 00:13:55,457 At ang sagot mula sa Oracle o MSSQL o kahit sinong tao ay makakuha ng isang mas malaking box. 308 00:13:55,457 --> 00:13:58,540 Well maaga o huli, hindi ka maaaring bumili ng isang mas malaking box, at iyon ang tunay na problema. 309 00:13:58,540 --> 00:14:00,080 Kailangan namin na talagang baguhin ang mga bagay. 310 00:14:00,080 --> 00:14:01,080 Kaya kung saan ito gumagana? 311 00:14:01,080 --> 00:14:06,560 Ito ay mahusay na gumagana para sa offline analytics, OLAP-type workloads. 312 00:14:06,560 --> 00:14:08,670 At iyan ay talagang kung saan nabibilang SQL. 313 00:14:08,670 --> 00:14:12,540 Ngayon, ito ay ginagamit ngayon sa maraming online transactional processing-type 314 00:14:12,540 --> 00:14:13,330 aplikasyon. 315 00:14:13,330 --> 00:14:16,460 At ito ay gumagana lamang multa sa ilang mga antas ng paggamit, 316 00:14:16,460 --> 00:14:18,670 ngunit ito lamang ay hindi scale ang paraan na gumagana ang NoSQL. 317 00:14:18,670 --> 00:14:20,660 At kami ay makipag-usap sa isang maliit na kaunti tungkol sa kung bakit na. 318 00:14:20,660 --> 00:14:23,590 >> Ngayon, NoSQL, sa kabilang banda, ay mas na-optimize para compute. 319 00:14:23,590 --> 00:14:24,540 SIGE? 320 00:14:24,540 --> 00:14:26,830 Ito ay hindi agnostic sa ang access pattern. 321 00:14:26,830 --> 00:14:31,620 Ay kung ano ang tawag namin sa de-normalize istraktura o ng isang hierarchical istraktura. 322 00:14:31,620 --> 00:14:35,000 Ang data sa isang pamanggit database ay nagsama-sama mula sa maramihang mga talahanayan 323 00:14:35,000 --> 00:14:36,850 upang makabuo ng mga pananaw na kailangan mo. 324 00:14:36,850 --> 00:14:40,090 Ang data sa isang NoSQL database ay naka-imbak sa isang dokumento na 325 00:14:40,090 --> 00:14:42,100 naglalaman ng mga hierarchical istraktura. 326 00:14:42,100 --> 00:14:45,670 Ang lahat ng mga data na normal na nagsama-sama upang makabuo ng pananaw na 327 00:14:45,670 --> 00:14:47,160 ay naka-imbak sa isang solong dokumento. 328 00:14:47,160 --> 00:14:50,990 At kami na makipag-usap nang kaunti tungkol sa paano na gumagana sa loob ng ilang mga chart. 329 00:14:50,990 --> 00:14:55,320 >> Ngunit ang ideya dito ay na-imbak mo ang iyong data bilang mga instantiated views. 330 00:14:55,320 --> 00:14:56,410 SIGE? 331 00:14:56,410 --> 00:14:58,610 Masukat mo horizontally. 332 00:14:58,610 --> 00:14:59,556 Right? 333 00:14:59,556 --> 00:15:02,100 Kung kailangan ko upang dagdagan ang laki ng aking NoSQL kumpol, 334 00:15:02,100 --> 00:15:03,700 Hindi ko na kailangan upang makakuha ng isang mas malaking box. 335 00:15:03,700 --> 00:15:05,200 Makakuha ako ng isa pang box. 336 00:15:05,200 --> 00:15:07,700 At kumpol ko ang mga sama-sama, at maaari ba akong Shard na data. 337 00:15:07,700 --> 00:15:10,780 Susubukan naming makipag-usap ng kaunti tungkol sa ano sharding ay, upang maging 338 00:15:10,780 --> 00:15:14,270 ma-scale na database sa kabuuan ng maramihang mga pisikal na device 339 00:15:14,270 --> 00:15:18,370 at alisin ang mga hadlang na nangangailangan ako sa scale patayo. 340 00:15:18,370 --> 00:15:22,080 >> Kaya ito ay tunay na binuo para sa mga online pagproseso ng transaksyon at scale. 341 00:15:22,080 --> 00:15:25,480 May isang malaking pagkakaiba dito sa pagitan ng pag-uulat, right? 342 00:15:25,480 --> 00:15:27,810 Pag-uulat, hindi ko alam ang tanong ako ng pagpunta sa magtanong. 343 00:15:27,810 --> 00:15:28,310 Right? 344 00:15:28,310 --> 00:15:30,570 Reporting-- kung ang isang tao mula aking marketing department 345 00:15:30,570 --> 00:15:34,520 gustong just-- kung ilan sa aking mga customer na ito ay may mga partikular na katangian na 346 00:15:34,520 --> 00:15:37,850 bumili sa mga ito day-- Hindi ko alam kung ano ang query ang kanilang pagpunta sa magtanong. 347 00:15:37,850 --> 00:15:39,160 Kaya kailangan kong maging agnostiko. 348 00:15:39,160 --> 00:15:41,810 >> Ngayon, sa isang online transactional application, 349 00:15:41,810 --> 00:15:43,820 Alam ko kung ano mga tanong ako nagtatanong. 350 00:15:43,820 --> 00:15:46,581 Ako na binuo ng application para sa isang napaka-tukoy na workflow. 351 00:15:46,581 --> 00:15:47,080 SIGE? 352 00:15:47,080 --> 00:15:50,540 Kaya kung io-optimize ang data imbak sa suporta na workflow, 353 00:15:50,540 --> 00:15:52,020 ito ay magiging mas mabilis. 354 00:15:52,020 --> 00:15:55,190 At iyon ang dahilan kung bakit NoSQL Maaari talagang mapabilis ang paghahatid 355 00:15:55,190 --> 00:15:57,710 sa mga uri ng mga serbisyo. 356 00:15:57,710 --> 00:15:58,210 Lahat tama. 357 00:15:58,210 --> 00:16:00,501 >> Kaya kami ay pagpunta upang makakuha ng sa isang maliit na piraso ng theory dito. 358 00:16:00,501 --> 00:16:03,330 At ang ilan sa inyo, ang inyong mga mata maaaring ibalik ang isang maliit na bit. 359 00:16:03,330 --> 00:16:06,936 Ngunit kukunin ko na subukan upang panatilihin ito bilang ng mataas na antas ng aking makakaya. 360 00:16:06,936 --> 00:16:08,880 Kaya't kung ikaw ay nasa mga proyekto pamamahala, may 361 00:16:08,880 --> 00:16:12,280 isang tayuan tinatawag na ang tatsulok ng limitasyon. 362 00:16:12,280 --> 00:16:12,936 SIGE. 363 00:16:12,936 --> 00:16:16,060 Ang tatsulok ng constrains atas Hindi ka maaaring magkaroon ng lahat ng oras sa lahat ng bagay. 364 00:16:16,060 --> 00:16:17,750 Hindi maaaring magkaroon ng iyong pie at kumain ito masyadong. 365 00:16:17,750 --> 00:16:22,310 Kaya sa pamamahala ng proyekto, na tatsulok limitasyon ay maaari mong makuha ito murang, 366 00:16:22,310 --> 00:16:24,710 maaari kang magkaroon ng mga ito nang mabilis, o maaari mong makuha ito ng mabuti. 367 00:16:24,710 --> 00:16:25,716 Pumili ng dalawang. 368 00:16:25,716 --> 00:16:27,090 Dahil hindi ka maaaring magkaroon ng lahat ng tatlong. 369 00:16:27,090 --> 00:16:27,460 Right? 370 00:16:27,460 --> 00:16:27,820 SIGE. 371 00:16:27,820 --> 00:16:28,920 >> Kaya maririnig mo tungkol sa mga ito ng isang pulutong. 372 00:16:28,920 --> 00:16:31,253 Ito ay isang triple sapilitan, tatsulok ng triple sapilitan, 373 00:16:31,253 --> 00:16:34,420 o ang bakal tatsulok ay oftentimes-- kapag kinakausap mo ang mga tagapamahala ng proyekto, 374 00:16:34,420 --> 00:16:35,420 ang mga ito ay makipag-usap tungkol sa mga ito. 375 00:16:35,420 --> 00:16:37,640 Ngayon, database ay may kanilang sariling mga bakal na tatsulok. 376 00:16:37,640 --> 00:16:40,350 At ang mga bakal tatsulok ng data ay kung ano ang tawag namin sa Cap teorama. 377 00:16:40,350 --> 00:16:41,580 SIGE? 378 00:16:41,580 --> 00:16:43,770 >> Cap theorem atas paano database gumana 379 00:16:43,770 --> 00:16:45,627 sa ilalim ng isang tiyak na takdang kalagayan. 380 00:16:45,627 --> 00:16:47,460 At kami ay makipag-usap tungkol kung ano ang kalagayan ay. 381 00:16:47,460 --> 00:16:52,221 Ngunit ang tatlong punto ng tatsulok, wika nga, ay C, pabago-bago. 382 00:16:52,221 --> 00:16:52,720 SIGE? 383 00:16:52,720 --> 00:16:56,760 Kaya sa Cap, pare-pareho ay nangangahulugan na ang lahat kliyente na maaaring ma-access ang database 384 00:16:56,760 --> 00:16:59,084 ay laging magkaroon ng isang napaka pare-pareho na view ng data. 385 00:16:59,084 --> 00:17:00,750 Gonna ninuman makita ang dalawang magkaibang mga bagay. 386 00:17:00,750 --> 00:17:01,480 SIGE? 387 00:17:01,480 --> 00:17:04,020 Kung nakikita ko ang mga database, Nakakakita ako ng parehong view 388 00:17:04,020 --> 00:17:06,130 bilang aking partner kung sino ang nakakakita ang parehong database. 389 00:17:06,130 --> 00:17:07,470 Iyan ay pare-pareho. 390 00:17:07,470 --> 00:17:12,099 >> Availability nangangahulugan na kung ang database online, kung maaari itong mapupuntahan, 391 00:17:12,099 --> 00:17:14,760 na ang lahat ng mga kliyente ay palaging maaaring magbasa at magsulat. 392 00:17:14,760 --> 00:17:15,260 SIGE? 393 00:17:15,260 --> 00:17:17,010 Kaya ang bawat client na maaaring basahin ang mga database 394 00:17:17,010 --> 00:17:18,955 ay palaging ma read data at isulat ang data. 395 00:17:18,955 --> 00:17:21,819 At kung iyon ang kaso, ito ay isang magagamit na system. 396 00:17:21,819 --> 00:17:24,230 >> At ang ikatlong punto ay kung ano ang ang tawag namin sa partition tolerance. 397 00:17:24,230 --> 00:17:24,730 SIGE? 398 00:17:24,730 --> 00:17:28,160 Tolerance Partition paraan na ang sistema ay gumagana ng mabuti 399 00:17:28,160 --> 00:17:32,000 sa kabila ng pisikal na network partisyon sa pagitan ng nodes. 400 00:17:32,000 --> 00:17:32,760 SIGE? 401 00:17:32,760 --> 00:17:36,270 Kaya nodes sa kumpol ay maaaring hindi makipag-usap sa bawat isa, ano ang mangyayari? 402 00:17:36,270 --> 00:17:36,880 Lahat tama. 403 00:17:36,880 --> 00:17:39,545 >> Database So pamanggit choose-- maaari kang pumili ng dalawang ng mga ito. 404 00:17:39,545 --> 00:17:40,045 SIGE. 405 00:17:40,045 --> 00:17:43,680 Database So pamanggit piliin upang maging pare-pareho at available. 406 00:17:43,680 --> 00:17:47,510 Kung nangyari ang pagkahati sa pagitan ng ang DataNodes sa tindahan ng data, 407 00:17:47,510 --> 00:17:48,831 ang database nag-crash. 408 00:17:48,831 --> 00:17:49,330 Right? 409 00:17:49,330 --> 00:17:50,900 Napupunta down Ito lamang. 410 00:17:50,900 --> 00:17:51,450 SIGE. 411 00:17:51,450 --> 00:17:54,230 >> At ito ang dahilan kung bakit sila ay may na lalaki sa mas malaking box. 412 00:17:54,230 --> 00:17:54,730 Right? 413 00:17:54,730 --> 00:17:58,021 Dahil mayroong no-- kadalasan, isang kumpol database, may hindi masyadong marami sa kanila 414 00:17:58,021 --> 00:17:59,590 na gumana na paraan. 415 00:17:59,590 --> 00:18:03,019 Subalit ang karamihan sa mga database masukat patayo sa loob ng iisang kahon. 416 00:18:03,019 --> 00:18:05,060 Dahil kailangan nila upang maging pare-pareho at available. 417 00:18:05,060 --> 00:18:10,320 Kung ang isang partition ay na iturok, pagkatapos ay kailangan mong gumawa ng isang pagpipilian. 418 00:18:10,320 --> 00:18:13,720 Kailangan ninyong gumawa ng isang pagpipilian sa pagitan pagiging pare-pareho at magagamit. 419 00:18:13,720 --> 00:18:16,080 >> At na kung ano NoSQL database gawin. 420 00:18:16,080 --> 00:18:16,580 Lahat tama. 421 00:18:16,580 --> 00:18:20,950 Kaya ang isang NoSQL database, ito lumapit sa dalawang flavors. 422 00:18:20,950 --> 00:18:22,990 Have-- Kami rin, ito ay dumating sa maraming flavors, 423 00:18:22,990 --> 00:18:26,140 ngunit ito ay may dalawang pangunahing characteristics-- ano 424 00:18:26,140 --> 00:18:30,050 gusto naming tumawag database CP, o isang pare-pareho at partition tolerance 425 00:18:30,050 --> 00:18:31,040 system. 426 00:18:31,040 --> 00:18:34,930 Ang mga guys gawin ang mga pagpipilian na kapag ang nodes mawalan ng contact sa bawat isa, 427 00:18:34,930 --> 00:18:37,091 hindi namin pagpunta upang payagan mga tao na magsulat sa anumang iba pa. 428 00:18:37,091 --> 00:18:37,590 SIGE? 429 00:18:37,590 --> 00:18:41,855 >> Hanggang sa na partition ay tinanggal, write access ay hinarangan. 430 00:18:41,855 --> 00:18:43,230 Iyon ay nangangahulugang ang mga ito ay hindi magagamit. 431 00:18:43,230 --> 00:18:44,510 Ang mga ito ay pare-pareho. 432 00:18:44,510 --> 00:18:46,554 Kapag nakita namin na pagkahati-iniksyon mismo, 433 00:18:46,554 --> 00:18:48,470 na kami ngayon pare-pareho, dahil hindi namin pagpunta 434 00:18:48,470 --> 00:18:51,517 upang payagan ang mga pagbabago sa data sa dalawang panig ng partition malaya 435 00:18:51,517 --> 00:18:52,100 ng bawat isa. 436 00:18:52,100 --> 00:18:54,130 Kami ay may sa muling ibalik ang komunikasyon 437 00:18:54,130 --> 00:18:56,930 bago ng anumang mga update sa ang data ay pinapayagan. 438 00:18:56,930 --> 00:18:58,120 SIGE? 439 00:18:58,120 --> 00:19:02,650 >> Ang susunod na lasa ay magiging isang AP system, o ang magagamit at partitioned 440 00:19:02,650 --> 00:19:03,640 tolerance system. 441 00:19:03,640 --> 00:19:05,320 Ang mga guys ay hindi na mahalaga. 442 00:19:05,320 --> 00:19:06,020 Right? 443 00:19:06,020 --> 00:19:08,960 Anumang node na nakukuha ng isang magsulat, kami ay kumuha ng mga ito. 444 00:19:08,960 --> 00:19:11,480 Kaya ako Kinokopya ang aking data sa kabuuan ng maramihang nodes. 445 00:19:11,480 --> 00:19:14,730 Makakuha ng mga nodes sa isang client, dumating client in, sabi, ako pagpunta sa sumulat ng ilang data. 446 00:19:14,730 --> 00:19:16,300 Node sabi, walang problema. 447 00:19:16,300 --> 00:19:18,580 Node Ang susunod sa kanya ay makakakuha ng isang sumulat sa parehong record, 448 00:19:18,580 --> 00:19:20,405 siya ay pagpunta sa sabihin walang problema. 449 00:19:20,405 --> 00:19:23,030 Sa isang lugar sa likod sa likod ng pagtatapos, ang data na iyon ay pagpunta sa magtiklop. 450 00:19:23,030 --> 00:19:27,360 At pagkatapos ay isang tao ay pagpunta sa mapagtanto, uh-oh, ikaw ay mapagtanto nila system, uh-oh, 451 00:19:27,360 --> 00:19:28,870 mayroong nangyaring isang update sa dalawang gilid. 452 00:19:28,870 --> 00:19:30,370 Ano ang gagawin namin? 453 00:19:30,370 --> 00:19:33,210 At ano pagkatapos ng ginagawa nila ay gawin nila ang isang bagay na 454 00:19:33,210 --> 00:19:36,080 ay nagbibigay-daan sa kanila upang malutas na ang estado ng data. 455 00:19:36,080 --> 00:19:39,000 At kami ay makipag-usap tungkol na sa susunod na chart. 456 00:19:39,000 --> 00:19:40,000 >> Bagay na ituro dito. 457 00:19:40,000 --> 00:19:42,374 At hindi ako pagpunta upang makakuha ng masyadong marami sa mga ito, dahil ito 458 00:19:42,374 --> 00:19:43,510 makakakuha ng sa malalim na teorya data. 459 00:19:43,510 --> 00:19:46,670 Subalit mayroong isang transactional framework na 460 00:19:46,670 --> 00:19:50,680 ay tumatakbo sa isang sistema ng pamanggit na ay nagbibigay-daan sa akin na ligtas na gumawa ng mga update 461 00:19:50,680 --> 00:19:53,760 sa maramihang mga nilalang sa database. 462 00:19:53,760 --> 00:19:58,320 At ang mga update ay magaganap nang sabay-sabay o hindi sa lahat. 463 00:19:58,320 --> 00:20:00,500 At ito ay tinatawag na acid transaksyon. 464 00:20:00,500 --> 00:20:01,000 SIGE? 465 00:20:01,000 --> 00:20:06,570 >> Acid ay nagbibigay sa amin atomicity, pagbabago, paghihiwalay, at tibay. 466 00:20:06,570 --> 00:20:07,070 SIGE? 467 00:20:07,070 --> 00:20:13,550 Iyon ay nangangahulugang ang atomic, transaksyon, ang lahat ng ang aking mga update ng alinman mangyari o hindi sila. 468 00:20:13,550 --> 00:20:16,570 Pare-pareho ay nangangahulugan na ang database ay palaging 469 00:20:16,570 --> 00:20:19,780 nagdala sa isang pare-pareho estado pagkatapos ng isang update. 470 00:20:19,780 --> 00:20:23,900 Hindi kita iiwan sa database sa isang masamang kalagayan pagkatapos ng paglalapat ng isang update. 471 00:20:23,900 --> 00:20:24,400 SIGE? 472 00:20:24,400 --> 00:20:26,720 >> Kaya ito ay isang maliit na naiiba kaysa sa Cap-pareho. 473 00:20:26,720 --> 00:20:29,760 Cap-pareho ang ibig sabihin ng lahat ng aking kliyente ay maaaring palaging makita ang data. 474 00:20:29,760 --> 00:20:34,450 Acid-pareho ay nangangahulugan na kapag isang transaksyon ay tapos na, ang data ng mabuti. 475 00:20:34,450 --> 00:20:35,709 Aking relasyon ay ang lahat ng mabuti. 476 00:20:35,709 --> 00:20:38,750 Hindi ako pupunta upang tanggalin ang isang magulang row at mag-iwan ng isang bungkos ng mga ulila anak 477 00:20:38,750 --> 00:20:40,970 sa ibang table. 478 00:20:40,970 --> 00:20:44,320 Hindi ito maaaring mangyari kung hindi ako pare-pareho sa isang asido transaksyon. 479 00:20:44,320 --> 00:20:49,120 >> Paghihiwalay ay nangangahulugan na ang mga transaksyon ay palaging nangyari ang isa pagkatapos ng isa. 480 00:20:49,120 --> 00:20:51,920 Ang huling resulta ng data ay ang parehong estado 481 00:20:51,920 --> 00:20:54,770 bilang kung ang mga transaksyon na inisyu concurrently 482 00:20:54,770 --> 00:20:57,340 ay pinaandar tinatanggap. 483 00:20:57,340 --> 00:21:00,030 Kaya ito ay concurrency control sa database. 484 00:21:00,030 --> 00:21:04,130 Kaya talaga, Hindi ko ma-dagdagan ang parehong halaga ng dalawang beses sa dalawang operasyon. 485 00:21:04,130 --> 00:21:08,580 >> Ngunit kung sabihin ko magdagdag ng 1 sa halaga na ito, at dumating sa dalawang mga transaksyon 486 00:21:08,580 --> 00:21:10,665 at subukan na gawin ito, ang isa ay pagpunta sa makarating doon muna 487 00:21:10,665 --> 00:21:12,540 at ang iba pang isa pagpunta sa makarating doon matapos. 488 00:21:12,540 --> 00:21:15,210 Kaya sa katapusan, nagdagdag ako ng dalawa. 489 00:21:15,210 --> 00:21:16,170 Makikita mo kung ano ang ibig sabihin ko? 490 00:21:16,170 --> 00:21:16,670 SIGE. 491 00:21:16,670 --> 00:21:19,220 492 00:21:19,220 --> 00:21:21,250 >> Tibay ay medyo direkta. 493 00:21:21,250 --> 00:21:23,460 Kapag ang transaksyon ay kinikilala, ito ay 494 00:21:23,460 --> 00:21:26,100 pagpunta sa maging kahit doon kung nag-crash ang system. 495 00:21:26,100 --> 00:21:29,230 Kapag recovers system na, na transaksyon na ipinamahala 496 00:21:29,230 --> 00:21:30,480 ay tunay na pagpunta sa maging doon. 497 00:21:30,480 --> 00:21:33,130 Kaya na ang mga garantiya ng acid transaksyon. 498 00:21:33,130 --> 00:21:35,470 Ang mga ay pretty nice garantiya upang magkaroon sa isang database, 499 00:21:35,470 --> 00:21:36,870 ngunit sila ay dumating sa na gastos. 500 00:21:36,870 --> 00:21:37,640 Right? 501 00:21:37,640 --> 00:21:40,520 >> Dahil ang problema sa balangkas na ito ay 502 00:21:40,520 --> 00:21:44,540 kung mayroong isang pagkahati sa data set, kailangan kong gumawa ng isang desisyon. 503 00:21:44,540 --> 00:21:48,000 Pupunta ako sa may upang payagan update sa isang bahagi o sa iba. 504 00:21:48,000 --> 00:21:50,310 At kung nangyari iyon, pagkatapos ay hindi na pagpunta ako 505 00:21:50,310 --> 00:21:52,630 upang ma-maintain mga katangian. 506 00:21:52,630 --> 00:21:53,960 Hindi sila ay pare-pareho. 507 00:21:53,960 --> 00:21:55,841 Hindi sila ay ihiwalay. 508 00:21:55,841 --> 00:21:58,090 Ito ay kung saan ito Pinaghihiwa-hiwalay para sa pamanggit database. 509 00:21:58,090 --> 00:22:01,360 Ito ang dahilan kung pamanggit database masukat patayo. 510 00:22:01,360 --> 00:22:05,530 >> Sa kabilang banda, mayroon kaming ano ang tinatawag na teknolohiya BASE. 511 00:22:05,530 --> 00:22:07,291 At ito ay ang iyong NoSQL Database. 512 00:22:07,291 --> 00:22:07,790 Lahat tama. 513 00:22:07,790 --> 00:22:10,180 Kaya na namin ang aming CP, AP database. 514 00:22:10,180 --> 00:22:14,720 At ang mga ito ay kung ano ang tawag mo talaga magagamit, soft estado, sa huli 515 00:22:14,720 --> 00:22:15,740 pare-pareho. 516 00:22:15,740 --> 00:22:16,420 SIGE? 517 00:22:16,420 --> 00:22:19,690 >> Karaniwang magagamit, dahil ang mga ito ay partition mapagparaya. 518 00:22:19,690 --> 00:22:21,470 Sila ay palaging magiging doon, kahit na may 519 00:22:21,470 --> 00:22:23,053 isang partition network sa pagitan ng nodes. 520 00:22:23,053 --> 00:22:25,900 Kung ang maaari kong makipag-usap sa isang node, ako pagpunta sa magagawang upang basahin ang data. 521 00:22:25,900 --> 00:22:26,460 SIGE? 522 00:22:26,460 --> 00:22:30,810 Baka ako hindi palaging ma-isulat data kung ako ay isang pare-pareho platform. 523 00:22:30,810 --> 00:22:32,130 Ngunit kailangan ma-basahin ang data ko. 524 00:22:32,130 --> 00:22:34,960 525 00:22:34,960 --> 00:22:38,010 >> Ipinahihiwatig ng soft estado na kapag ako basahin na data, 526 00:22:38,010 --> 00:22:40,790 maaaring hindi ito katulad ng iba pang mga node. 527 00:22:40,790 --> 00:22:43,390 Kung ang isang karapatan ay inisyu sa isang node sa ibang lugar sa cluster 528 00:22:43,390 --> 00:22:46,650 at ito ay hindi kinokopya sa buong cluster pa kapag ako basahin na data, 529 00:22:46,650 --> 00:22:48,680 Maaaring hindi maging pare-pareho na estado. 530 00:22:48,680 --> 00:22:51,650 Gayunman, ito ay huli pare-pareho, 531 00:22:51,650 --> 00:22:53,870 ibig sabihin na kapag ang isang write ay ginawa sa sistema, 532 00:22:53,870 --> 00:22:56,480 ito ay magtiklop buong nodes. 533 00:22:56,480 --> 00:22:59,095 At sa huli, na ang estado ay nagdala sa order, 534 00:22:59,095 --> 00:23:00,890 at ito ay isang pare-pareho ng estado. 535 00:23:00,890 --> 00:23:05,000 >> Ngayon, Cap theorem talagang gumaganap lamang sa isang kundisyon. 536 00:23:05,000 --> 00:23:08,700 Kondisyon na ito ay kapag nangyari ito. 537 00:23:08,700 --> 00:23:13,710 Dahil kapag ito ay operating sa normal mode, walang partisyon, 538 00:23:13,710 --> 00:23:16,370 lahat ng bagay ay pare-pareho at available. 539 00:23:16,370 --> 00:23:19,990 Mag-alala ka lamang tungkol sa Cap kapag kami ay may na partition. 540 00:23:19,990 --> 00:23:21,260 Kaya ang mga ay bukod-tangi. 541 00:23:21,260 --> 00:23:25,360 Ngunit kung ano ang reaksiyon sistema kapag ang mga mangyari utos kung ano ang uri ng sistema 542 00:23:25,360 --> 00:23:26,750 kami ay pagharap sa. 543 00:23:26,750 --> 00:23:31,110 >> Kaya sabihin kumuha ng isang pagtingin sa kung ano na ganito ang hitsura para sa AP systems. 544 00:23:31,110 --> 00:23:32,621 SIGE? 545 00:23:32,621 --> 00:23:34,830 Systems AP dumating sa dalawang flavors. 546 00:23:34,830 --> 00:23:38,514 Sila ay dumating sa lasa na ay isang master master, 100%, palaging magagamit. 547 00:23:38,514 --> 00:23:40,430 At sila ay dumating sa iba pang mga lasa, na nagsasabing, 548 00:23:40,430 --> 00:23:43,330 alam mo kung ano, ako pagpunta sa mag-alala tungkol sa partitioning bagay 549 00:23:43,330 --> 00:23:44,724 kapag naganap ang isang aktwal na partition. 550 00:23:44,724 --> 00:23:47,890 Kung hindi man, may pagpunta sa maging pangunahing nodes sino ang pagpunta sa gawin ang mga karapatan. 551 00:23:47,890 --> 00:23:48,500 SIGE? 552 00:23:48,500 --> 00:23:50,040 >> Kaya kung namin ang isang bagay tulad ng Cassandra. 553 00:23:50,040 --> 00:23:54,440 Cassandra ay isang master master, sabihin ay sa akin magsulat sa anumang node. 554 00:23:54,440 --> 00:23:55,540 Kaya kung ano ang mangyayari? 555 00:23:55,540 --> 00:23:58,270 Kaya ko ng isang bagay sa database na umiiral sa dalawang nodes. 556 00:23:58,270 --> 00:24:01,705 Sabihin tumawag na object S. Kaya kami ng estado para sa S. 557 00:24:01,705 --> 00:24:04,312 Mayroon kaming ilang mga operasyon sa S na ay patuloy. 558 00:24:04,312 --> 00:24:06,270 Ay nagbibigay-daan sa akin Cassandra sa sumulat sa maramihang nodes. 559 00:24:06,270 --> 00:24:08,550 Kaya sabihin nating kumuha ako ng isang isulat para s dalawang nodes. 560 00:24:08,550 --> 00:24:12,274 Well, kung ano ang nagtatapos up nangyayari ay ang tawag namin na ang isang kaganapan partitioning. 561 00:24:12,274 --> 00:24:14,190 May hindi maaaring maging isang pisikal na pagkahati network. 562 00:24:14,190 --> 00:24:15,950 Ngunit dahil sa ang disenyo ng sistema, ito ay 563 00:24:15,950 --> 00:24:18,449 talagang partisyon sa lalong madaling makakuha ako ng isang write sa dalawang nodes. 564 00:24:18,449 --> 00:24:20,830 Ito ay hindi sapilitan kong isulat ang lahat sa pamamagitan ng isang node. 565 00:24:20,830 --> 00:24:22,340 Sumulat ako sa dalawang nodes. 566 00:24:22,340 --> 00:24:23,330 SIGE? 567 00:24:23,330 --> 00:24:25,740 >> Kaya ngayon mayroon akong dalawang mga katayuan. 568 00:24:25,740 --> 00:24:26,360 SIGE? 569 00:24:26,360 --> 00:24:28,110 Ano kaya ang mangyari ay maaga o huli, 570 00:24:28,110 --> 00:24:29,960 may pagpunta sa maging isang kaganapan pagtitiklop. 571 00:24:29,960 --> 00:24:33,300 May pupuntahan maging kung ano tayo tinatawag na isang partition recovery, na kung saan 572 00:24:33,300 --> 00:24:35,200 ay kung saan ang dalawang states bumalik magkasama 573 00:24:35,200 --> 00:24:37,310 at doon ay magiging isang algorithm na tumatakbo sa loob ng database, 574 00:24:37,310 --> 00:24:38,540 nagpapasya kung ano ang gagawin. 575 00:24:38,540 --> 00:24:39,110 SIGE? 576 00:24:39,110 --> 00:24:43,057 Sa pamamagitan ng default, huling update nanalo sa karamihan ng mga sistema ng AP. 577 00:24:43,057 --> 00:24:44,890 Kaya mayroong karaniwang isang default algorithm, kung ano 578 00:24:44,890 --> 00:24:47,400 sila tumawag ng callback function, isang bagay na 579 00:24:47,400 --> 00:24:51,000 ay tinatawag na kapag ang kundisyong ito ay nakita upang magsagawa ng ilang lohika 580 00:24:51,000 --> 00:24:52,900 upang malutas na conflict. 581 00:24:52,900 --> 00:24:53,850 SIGE? 582 00:24:53,850 --> 00:24:58,770 Ang default na callback at default resolver sa karamihan ng mga database AP 583 00:24:58,770 --> 00:25:01,130 ay, hulaan kung ano, timestamp na panalo. 584 00:25:01,130 --> 00:25:02,380 Ito ay ang huling update. 585 00:25:02,380 --> 00:25:04,320 Pupunta ako upang ilagay ang update na sa doon. 586 00:25:04,320 --> 00:25:08,440 Maaari ko tambakan ng basura ang ulat na ito na aking itinapon off sa isang log sa pagbawi 587 00:25:08,440 --> 00:25:11,670 kaya na maaaring bumalik sa paggamit sa ibang pagkakataon at sabihin, hey, nagkaroon ng isang banggaan. 588 00:25:11,670 --> 00:25:12,320 Anong nangyari? 589 00:25:12,320 --> 00:25:16,370 At maaari mong aktwal na tambakan ng isang talaan ng mga lahat ng mga banggaan at ang rollbacks 590 00:25:16,370 --> 00:25:17,550 at makita kung ano ang mangyayari. 591 00:25:17,550 --> 00:25:21,580 >> Ngayon, bilang isang user, maaari mo ring isama ang logic sa na callback. 592 00:25:21,580 --> 00:25:24,290 Kaya maaari mong baguhin na callback operasyon. 593 00:25:24,290 --> 00:25:26,730 Maaari mong sabihin, hey, gusto kong muling mamamagitan ang data na ito. 594 00:25:26,730 --> 00:25:28,880 At gusto kong subukan at pagsamahin ang dalawang mga tala sa mga iyon. 595 00:25:28,880 --> 00:25:30,050 Ngunit iyon lamang ang nasa sa iyo. 596 00:25:30,050 --> 00:25:32,880 Ang database ay hindi alam kung paano gawin na sa pamamagitan ng default. Karamihan sa mga oras, 597 00:25:32,880 --> 00:25:34,850 ang tanging bagay na ang mga database nakakaalam kung paano gawin ay sabihin, 598 00:25:34,850 --> 00:25:36,100 ang isang ito ay ang huling record. 599 00:25:36,100 --> 00:25:39,183 Iyon ang isa na ang pagpunta sa manalo, at na ang halaga Pupunta ako sa ilagay. 600 00:25:39,183 --> 00:25:41,490 Kapag na partition recovery at pagtitiklop nangyayari, 601 00:25:41,490 --> 00:25:43,930 na namin ang aming estado, na ay ang S ngayon prime, na kung saan ay 602 00:25:43,930 --> 00:25:46,890 ang estado merge ng lahat ng mga bagay. 603 00:25:46,890 --> 00:25:49,700 Kaya systems AP mayroon ito. 604 00:25:49,700 --> 00:25:51,615 CP sistema ay hindi kailangan mag-alala tungkol sa mga ito. 605 00:25:51,615 --> 00:25:54,490 Dahil sa lalong madaling isang partition ay dumating sa pag-play, stop lang nila ang pagkuha 606 00:25:54,490 --> 00:25:55,530 nagsusulat. 607 00:25:55,530 --> 00:25:56,180 SIGE? 608 00:25:56,180 --> 00:25:58,670 Kaya na ay napakadaling pakikitungo sa pagiging pare-pareho 609 00:25:58,670 --> 00:26:01,330 kapag hindi mo tatanggapin ang anumang mga update. 610 00:26:01,330 --> 00:26:04,620 Iyan ay may gawin CP systems. 611 00:26:04,620 --> 00:26:05,120 Lahat tama. 612 00:26:05,120 --> 00:26:07,590 >> Kaya sabihin makipag-usap sa isang maliit na bit tungkol sa mga pattern access. 613 00:26:07,590 --> 00:26:11,580 Kapag ang usapan namin tungkol NoSQL, ito ay lahat ng tungkol sa pag-access pattern. 614 00:26:11,580 --> 00:26:13,550 Ngayon, SQL ay ad hoc, queries. 615 00:26:13,550 --> 00:26:14,481 Ito ay pamanggit store. 616 00:26:14,481 --> 00:26:16,480 Hindi namin kailangang mag-alala tungkol sa pag-access pattern. 617 00:26:16,480 --> 00:26:17,688 Sumulat ako ng isang napaka-komplikadong query. 618 00:26:17,688 --> 00:26:19,250 Ito napupunta at makakakuha ng data. 619 00:26:19,250 --> 00:26:21,210 Iyon ay kung ano ang mukhang tulad ng, normalization. 620 00:26:21,210 --> 00:26:24,890 >> Kaya sa partikular na istraktura, kami ay naghahanap sa isang catalog ng mga produkto. 621 00:26:24,890 --> 00:26:26,640 Mayroon akong iba't ibang uri ng produkto. 622 00:26:26,640 --> 00:26:27,217 Mayroon akong mga libro. 623 00:26:27,217 --> 00:26:27,800 Mayroon akong mga album. 624 00:26:27,800 --> 00:26:30,090 Mayroon akong mga video. 625 00:26:30,090 --> 00:26:33,370 Ang relasyon sa pagitan ng mga produkto at ang anumang isa sa mga libro, album, 626 00:26:33,370 --> 00:26:34,860 at mga video talahanayan ay 1: 1. 627 00:26:34,860 --> 00:26:35,800 Lahat tama? 628 00:26:35,800 --> 00:26:38,860 Mayroon akong isang ID ng produkto, at na tumutugma ID 629 00:26:38,860 --> 00:26:41,080 sa isang libro, isang album, o isang video. 630 00:26:41,080 --> 00:26:41,580 SIGE? 631 00:26:41,580 --> 00:26:44,350 Iyan ay isang 1: 1 na relasyon sa kabuuan ng mga tables. 632 00:26:44,350 --> 00:26:46,970 >> Ngayon, books-- lahat sila Mayroon ay root properties. 633 00:26:46,970 --> 00:26:47,550 Walang problema. 634 00:26:47,550 --> 00:26:48,230 Mabuti iyan. 635 00:26:48,230 --> 00:26:52,130 One-sa-isang relasyon, nakukuha ko lahat ng ang data na kailangan ko upang ilarawan ang librong iyon. 636 00:26:52,130 --> 00:26:54,770 Albums-- album ay may mga track. 637 00:26:54,770 --> 00:26:56,470 Ito ay kung ano ang tawag namin sa isa sa maraming. 638 00:26:56,470 --> 00:26:58,905 Bawat album ay maaaring magkaroon ng maraming mga track. 639 00:26:58,905 --> 00:27:00,780 Kaya para sa bawat track sa ang album, maaari ba akong magkaroon 640 00:27:00,780 --> 00:27:02,570 isa pang record sa batang ito table. 641 00:27:02,570 --> 00:27:04,680 Kaya ako gumawa ng isang tala sa aking mga talahanayan album. 642 00:27:04,680 --> 00:27:06,700 Gumawa ako ng maraming mga talaan sa talahanayan ng mga track. 643 00:27:06,700 --> 00:27:08,850 One-sa-maraming relasyon. 644 00:27:08,850 --> 00:27:11,220 >> Relasyon na ito ay kung ano ang ang tawag namin sa many-to-maraming. 645 00:27:11,220 --> 00:27:11,750 SIGE? 646 00:27:11,750 --> 00:27:17,000 Ang makikita mo na aktor ay maaaring sa maraming mga pelikula, maraming mga video. 647 00:27:17,000 --> 00:27:21,450 Kaya kung ano ang ginagawa namin ay namin ilagay ito mapping mesa sa pagitan ng mga, na kung saan ito lamang 648 00:27:21,450 --> 00:27:24,040 mga mapa ang mga artista ID sa video ID. 649 00:27:24,040 --> 00:27:28,464 Ngayon ay maaari kong lumikha ng isang query sa pagsali mga video sa pamamagitan ng aktor video na aktor, 650 00:27:28,464 --> 00:27:31,130 at ito ay nagbibigay sa akin ng isang magandang listahan ng mga ang lahat ng mga pelikula at lahat ng mga aktor 651 00:27:31,130 --> 00:27:32,420 na nasa na movie. 652 00:27:32,420 --> 00:27:33,290 >> SIGE. 653 00:27:33,290 --> 00:27:33,880 Kaya dito namin pumunta. 654 00:27:33,880 --> 00:27:38,040 One-to-one ay ang top-level relasyon; isa-sa-marami, 655 00:27:38,040 --> 00:27:40,240 mga album sa mga track; maraming-sa-marami. 656 00:27:40,240 --> 00:27:44,990 Ang mga ay ang tatlong nangungunang antas relasyon sa anumang database. 657 00:27:44,990 --> 00:27:48,050 Kung alam mo kung paano ang mga relasyon magtulungan, 658 00:27:48,050 --> 00:27:51,490 pagkatapos ay alam mo ng maraming tungkol sa database na. 659 00:27:51,490 --> 00:27:55,660 Kaya NoSQL gumagana ng kaunti naiiba. 660 00:27:55,660 --> 00:27:58,930 Isipin ang tungkol para sa isang segundo kung ano ito hitsura tulad ng upang pumunta makakuha ng lahat ng aking mga produkto. 661 00:27:58,930 --> 00:28:01,096 >> Sa isang pamanggit store, ako nais na makakuha ng lahat ng aking mga produkto 662 00:28:01,096 --> 00:28:02,970 sa isang listahan ng lahat ng aking mga produkto. 663 00:28:02,970 --> 00:28:04,910 Iyan ay isang pulutong ng mga query. 664 00:28:04,910 --> 00:28:07,030 Nakakuha ako ng isang query para sa lahat ng aking mga libro. 665 00:28:07,030 --> 00:28:08,470 Nakakuha ako ng isang query mula sa aking mga album. 666 00:28:08,470 --> 00:28:09,970 At Nakakuha ako ng isang query para sa lahat ng aking mga video. 667 00:28:09,970 --> 00:28:11,719 At nakuha ko upang ilagay ito lahat ng sama-sama sa isang listahan 668 00:28:11,719 --> 00:28:15,250 at maglingkod ito back up sa application na humihiling ito. 669 00:28:15,250 --> 00:28:18,000 >> Upang makakuha ng mga libro ko, sumali ako Mga Produkto at Books. 670 00:28:18,000 --> 00:28:21,680 Upang makakuha ng aking mga album, ang nakuha ko upang sumali Products, Albums, at Tracks. 671 00:28:21,680 --> 00:28:25,330 At upang makakuha ng aking mga video, mayroon akong upang sumali mga Produkto sa video, 672 00:28:25,330 --> 00:28:28,890 sumali sa pamamagitan ng artista Videos, at dalhin sa aktor. 673 00:28:28,890 --> 00:28:31,020 Kaya na ang tatlong tanong. 674 00:28:31,020 --> 00:28:34,560 Napaka kumplikadong mga query na magtipon ng isang set na resulta. 675 00:28:34,560 --> 00:28:36,540 >> Iyon ay mas mababa kaysa optimal. 676 00:28:36,540 --> 00:28:39,200 Ito ay kung bakit kapag ang usapan namin tungkol sa isang istraktura ng data na 677 00:28:39,200 --> 00:28:42,900 itinayo upang maging agnostic sa access pattern-- rin na malaki. 678 00:28:42,900 --> 00:28:45,730 At maaari mong makita na ito ay talagang maganda kung paano namin inayos na ang data. 679 00:28:45,730 --> 00:28:46,550 At alam mo kung ano? 680 00:28:46,550 --> 00:28:49,750 Isa lang ang aking record para sa isang artista. 681 00:28:49,750 --> 00:28:50,440 >> Iyan ay cool. 682 00:28:50,440 --> 00:28:53,750 Deduplicated ko na ang lahat ng aking mga aktor, at pinananatili ko ang aking mga asosasyon 683 00:28:53,750 --> 00:28:55,200 sa talahanayan ng pagmamapa. 684 00:28:55,200 --> 00:29:00,620 Gayunman, ang pagkuha ng data out nagiging mahal. 685 00:29:00,620 --> 00:29:04,500 Ako ipadala ang CPU sa buong sistema pagsali sa mga istruktura ng data nang sama-sama 686 00:29:04,500 --> 00:29:05,950 para ma-pull na bumalik data. 687 00:29:05,950 --> 00:29:07,310 >> Kaya paano ako makakakuha ng paligid na? 688 00:29:07,310 --> 00:29:11,200 Sa NoSQL ito ay tungkol sa pagsasama-sama, hindi normalization. 689 00:29:11,200 --> 00:29:13,534 Kaya gusto naming sabihin na gusto naming suportahan ang access pattern. 690 00:29:13,534 --> 00:29:15,283 Kung ang access pattern sa mga application, 691 00:29:15,283 --> 00:29:16,770 Kailangan ko upang makakuha ng lahat ng aking mga produkto. 692 00:29:16,770 --> 00:29:19,027 Maglagay ng lahat ng mga produkto sa isang mesa. 693 00:29:19,027 --> 00:29:22,110 Kung ko bang ilagay ang lahat ng mga produkto sa isang table, Maaari ko lang piliin ang lahat ng mga produkto 694 00:29:22,110 --> 00:29:23,850 mula sa mesa at kumuha ako ng lahat ng ito. 695 00:29:23,850 --> 00:29:25,240 Well paano ko gawin iyon? 696 00:29:25,240 --> 00:29:28,124 Well in NoSQL walang istraktura sa mga table. 697 00:29:28,124 --> 00:29:30,540 Susubukan naming makipag-usap nang kaunti tungkol sa paano ito gumagana sa Dynamo DB. 698 00:29:30,540 --> 00:29:33,570 Ngunit hindi mo na magkaroon ng parehong mga katangian at ng parehong mga katangian 699 00:29:33,570 --> 00:29:37,751 sa bawat isang hilera, sa bawat solong item, tulad ng gagawin mo sa isang SQL table. 700 00:29:37,751 --> 00:29:39,750 At kung ano ang nagbibigay-daan sa akin gawin ay isang pulutong ng mga bagay-bagay 701 00:29:39,750 --> 00:29:41,124 at magbigay sa akin ng isang pulutong ng flexibility. 702 00:29:41,124 --> 00:29:45,360 Sa partikular na kasong, ako ang aking mga dokumento produkto. 703 00:29:45,360 --> 00:29:49,090 At sa mga partikular na Halimbawa, ang lahat ng bagay 704 00:29:49,090 --> 00:29:51,930 ay isang dokumento sa talahanayan ng Mga Produkto. 705 00:29:51,930 --> 00:29:56,510 At ang produkto para sa isang libro baka magkaroon ng isang uri ng ID na tumutukoy ng isang libro. 706 00:29:56,510 --> 00:29:59,180 At ang mga application ay lumipat sa ID na. 707 00:29:59,180 --> 00:30:02,570 >> Sa tier application, pupuntahan ko sabihin o, anong uri ng talaan ito? 708 00:30:02,570 --> 00:30:04,100 Oh, ito ay isang record book. 709 00:30:04,100 --> 00:30:05,990 Talaan Book ay may mga ari-arian. 710 00:30:05,990 --> 00:30:08,100 Hayaan akong lumikha ng isang bagay na libro. 711 00:30:08,100 --> 00:30:11,289 Kaya ako pagpunta upang punan ang book object sa item na ito. 712 00:30:11,289 --> 00:30:13,080 Susunod na item ay dumating at sabi, kung ano ang item na ito? 713 00:30:13,080 --> 00:30:14,560 Well item na ito ay isang album. 714 00:30:14,560 --> 00:30:17,340 Oh, Nakatanggap ako ng isang buong iba't ibang processing routine para sa na, 715 00:30:17,340 --> 00:30:18,487 dahil sa ito ay isang album. 716 00:30:18,487 --> 00:30:19,320 Makikita mo kung ano ang ibig sabihin ko? 717 00:30:19,320 --> 00:30:21,950 >> Kaya ang application tier-- ko piliin lamang ang lahat ng mga talaan. 718 00:30:21,950 --> 00:30:23,200 Lahat sila ay simulan ang pagdating sa. 719 00:30:23,200 --> 00:30:24,680 Sila ay maaaring maging lahat ng iba't ibang mga uri. 720 00:30:24,680 --> 00:30:27,590 At ito ay logic ng application na switch sa kabuuan ng mga uri 721 00:30:27,590 --> 00:30:29,530 at nagpapasya kung paano i-proseso ang mga ito. 722 00:30:29,530 --> 00:30:33,640 >> Muli, kaya kami ay pag-optimize ang schema para sa access pattern. 723 00:30:33,640 --> 00:30:36,390 Ginagawa namin ito sa pamamagitan ng collapsing mga tables. 724 00:30:36,390 --> 00:30:39,670 Kami talaga ay pagkuha mga naging normal na kaayusan, 725 00:30:39,670 --> 00:30:42,000 at kami ay gusali hierarchical na kaayusan. 726 00:30:42,000 --> 00:30:45,130 Sa loob ng bawat isa sa mga talang ito Pupunta ako upang makita ang mga ari-arian array. 727 00:30:45,130 --> 00:30:49,400 >> Inside ang dokumentong ito para sa Albums, Nakakakita ako ng mga array ng mga track. 728 00:30:49,400 --> 00:30:53,900 Ang mga track sa ngayon become-- ito ay talaga ito bata table na 729 00:30:53,900 --> 00:30:56,520 umiiral dito mismo sa structure na ito. 730 00:30:56,520 --> 00:30:57,975 Kaya maaari mong gawin ito sa DynamoDB. 731 00:30:57,975 --> 00:30:59,810 Maaari mo itong gawin sa MongoDB. 732 00:30:59,810 --> 00:31:01,437 Maaari mong gawin ito sa anumang NoSQL database. 733 00:31:01,437 --> 00:31:03,520 Lumikha ng ganitong mga uri ng hierarchical istruktura ng data 734 00:31:03,520 --> 00:31:07,120 na nagpapahintulot sa iyo na makuha ang data masyadong mabilis dahil ngayon ko 735 00:31:07,120 --> 00:31:08,537 Hindi mo na kailangang tumalima. 736 00:31:08,537 --> 00:31:11,620 Kapag ako magpasok ng isang hilera sa mga Tracks mesa, o ng isang hilera sa talahanayan Albums, 737 00:31:11,620 --> 00:31:13,110 Kailangan ko bang sumunod sa panukala. 738 00:31:13,110 --> 00:31:18,060 Mayroon akong magkaroon ang katangian o ang ari-arian na tinukoy sa table na. 739 00:31:18,060 --> 00:31:20,480 Bawat isa sa kanila, kapag ipasok ko na hilera. 740 00:31:20,480 --> 00:31:21,910 Iyan ay hindi ang kaso sa NoSQL. 741 00:31:21,910 --> 00:31:24,440 >> Maaari ba akong magkaroon ganap na kakaiba mga katangian sa bawat dokumento 742 00:31:24,440 --> 00:31:26,100 na ako ipasok sa koleksyon. 743 00:31:26,100 --> 00:31:30,480 Kaya napaka malakas na mekanismo. 744 00:31:30,480 --> 00:31:32,852 At ito ay talagang kung paano mo i-optimize ang sistema. 745 00:31:32,852 --> 00:31:35,310 Dahil ngayon na query, sa halip ng pagsali sa lahat ng mga talahanayan 746 00:31:35,310 --> 00:31:39,160 at Isinasagawa ng isang kalahating dosenang mga query upang hilahin pabalik ang data na kailangan ko, 747 00:31:39,160 --> 00:31:40,890 Ako Isinasagawa isa query. 748 00:31:40,890 --> 00:31:43,010 At ako iterating sa kabila ng mga resulta set. 749 00:31:43,010 --> 00:31:46,512 ito ay nagbibigay sa iyo ng isang ideya ng kapangyarihan ng NoSQL. 750 00:31:46,512 --> 00:31:49,470 Pupunta ako sa uri ng pumunta patagilid dito at makipag-usap nang kaunti tungkol sa mga ito. 751 00:31:49,470 --> 00:31:53,240 Ito ay higit pang uri ng marketing o technology-- 752 00:31:53,240 --> 00:31:55,660 ang marketing ng teknolohiya uri ng talakayan. 753 00:31:55,660 --> 00:31:58,672 Ngunit ito ay mahalaga na maunawaan dahil kung titingnan natin sa tuktok 754 00:31:58,672 --> 00:32:00,380 dito sa tsart na ito, kung ano ang namin ang pagtingin sa 755 00:32:00,380 --> 00:32:04,030 ay kung ano ang tawag namin sa technology hype curve. 756 00:32:04,030 --> 00:32:06,121 At kung ano ang ibig sabihin nito ay bagong bagay-bagay ay dumating sa play. 757 00:32:06,121 --> 00:32:07,120 Akala ng mga tao ito ay mahusay. 758 00:32:07,120 --> 00:32:09,200 Ko na lutasin ang lahat ng aking mga problema. 759 00:32:09,200 --> 00:32:11,630 >> Maaaring ito ay ang end lahat, maging lahat sa lahat. 760 00:32:11,630 --> 00:32:12,790 At simulan nila ang paggamit nito. 761 00:32:12,790 --> 00:32:14,720 At sinasabi nila, ang bagay na ito ay hindi gumagana. 762 00:32:14,720 --> 00:32:17,600 Hindi ito tama. 763 00:32:17,600 --> 00:32:19,105 Ang lumang bagay-bagay ay mas mahusay. 764 00:32:19,105 --> 00:32:21,230 At sila ay bumalik sa paggawa mga bagay sa paraan sila ay. 765 00:32:21,230 --> 00:32:22,730 At pagkatapos ay sa wakas pumunta sila, alam mo kung ano? 766 00:32:22,730 --> 00:32:24,040 Ang bagay na ito ay hindi masama. 767 00:32:24,040 --> 00:32:26,192 Oh, na kung paano ito gumagana. 768 00:32:26,192 --> 00:32:28,900 At sa sandaling malaman nila kung paano ito gawa, sila ay mas mahusay na magsimula sa pagkuha. 769 00:32:28,900 --> 00:32:32,050 >> At ang nakakatawa bagay tungkol dito ay, ito uri ng mga linya ng hanggang sa kung ano ang 770 00:32:32,050 --> 00:32:34,300 ang tawag namin sa Adoption Technology Curve. 771 00:32:34,300 --> 00:32:36,910 Kaya kung ano ang mangyayari ay mayroon kaming ilang trigger teknolohiya sort. 772 00:32:36,910 --> 00:32:39,100 Sa kaso ng mga database, ito ay ang presyon ng data. 773 00:32:39,100 --> 00:32:42,200 Usapan natin ang tungkol sa mga mataas na tubig puntos ng presyon data sa buong panahon. 774 00:32:42,200 --> 00:32:46,310 Kapag na presyon ng data umabot sa isang tiyak point, na ang isang trigger teknolohiya. 775 00:32:46,310 --> 00:32:47,830 >> Ito ay pagkuha ng masyadong mahal. 776 00:32:47,830 --> 00:32:49,790 Ito ay tumatagal ng masyadong mahaba upang i-proseso ang data. 777 00:32:49,790 --> 00:32:50,890 Kailangan natin ng isang bagay na mas mahusay. 778 00:32:50,890 --> 00:32:52,890 Makukuha mo ang mga innovators out there tumatakbo sa paligid, 779 00:32:52,890 --> 00:32:55,050 sinusubukan na alamin kung ano ang solusyon. 780 00:32:55,050 --> 00:32:56,050 Ano ang mga bagong ideya? 781 00:32:56,050 --> 00:32:58,170 >> Ano ang susunod na pinakamahusay na paraan upang gawin ang bagay na ito? 782 00:32:58,170 --> 00:32:59,530 At dumating sila sa isang bagay. 783 00:32:59,530 --> 00:33:03,140 At ang mga tao sa tunay na sakit, ang guys sa dumudugo gilid, 784 00:33:03,140 --> 00:33:06,390 ang mga ito ay tumalon ang lahat ng higit sa mga ito, dahil kailangan nila ng isang sagot. 785 00:33:06,390 --> 00:33:09,690 Ngayon kung ano ang hindi maaaring hindi happens-- at ito ay nangyayari sa NoSQL ngayon. 786 00:33:09,690 --> 00:33:11,090 Makita ko ito sa lahat ng oras. 787 00:33:11,090 --> 00:33:13,610 >> Anong hindi maaaring hindi mangyayari ay mga tao simulan ang paggamit ng bagong tool 788 00:33:13,610 --> 00:33:15,490 sa parehong paraan na ginamit nila ang mga lumang kasangkapan. 789 00:33:15,490 --> 00:33:17,854 At makikita nila ang mga ito ay hindi gumagana nang maayos. 790 00:33:17,854 --> 00:33:20,020 Hindi ko matandaan kung sino ako pakikipag-usap sa mas maaga sa araw. 791 00:33:20,020 --> 00:33:22,080 Ngunit ito ay tulad ng, kapag ang jackhammer ay imbento, 792 00:33:22,080 --> 00:33:24,621 ay hindi ugoy ito tao sa paglipas ng ang kanilang mga ulo sa bagsak ang kongkreto. 793 00:33:24,621 --> 00:33:27,360 794 00:33:27,360 --> 00:33:30,610 >> Ngunit iyon ay kung ano ang nangyayari sa NoSQL ngayon. 795 00:33:30,610 --> 00:33:33,900 Kung ituturo sa iyo sa karamihan sa mga tindahan, sila ay nagsisikap na maging NoSQL tindahan. 796 00:33:33,900 --> 00:33:36,510 Ano ang kanilang ginagawa ay sila ay gumagamit NoSQL, 797 00:33:36,510 --> 00:33:39,900 at sila ay loading ito puno ng schema pamanggit. 798 00:33:39,900 --> 00:33:41,630 Dahil na kung paano sila disenyo database. 799 00:33:41,630 --> 00:33:44,046 At sila ay nagtataka, kung bakit hindi ito gumaganap nang mahusay? 800 00:33:44,046 --> 00:33:45,230 Boy, ang bagay na ito ay bulok. 801 00:33:45,230 --> 00:33:49,900 Ako ay upang mapanatili ang lahat ng aking Sinamahan in-- ito ay tulad ng, hindi, hindi. 802 00:33:49,900 --> 00:33:50,800 Panatilihin pagsali? 803 00:33:50,800 --> 00:33:52,430 Bakit mo siya sumali sa data? 804 00:33:52,430 --> 00:33:54,350 Hindi mo na sumali sa data sa NoSQL. 805 00:33:54,350 --> 00:33:55,850 Pinagsasama-sama mo ito. 806 00:33:55,850 --> 00:34:00,690 >> Kaya kung nais mong maiwasan ito, alamin kung paano gumagana ang tool bago mo talaga 807 00:34:00,690 --> 00:34:02,010 simulan ang paggamit nito. 808 00:34:02,010 --> 00:34:04,860 Huwag subukan at gamitin ang bagong tool na ito ang parehong paraan na ginamit mo ang mga lumang kasangkapan. 809 00:34:04,860 --> 00:34:06,500 Ikaw ay pagpunta sa may isang masamang karanasan. 810 00:34:06,500 --> 00:34:08,848 At sa bawat isang oras na kung ano ito ay tungkol sa. 811 00:34:08,848 --> 00:34:11,389 Kapag simulan pagdating namin dito, ito ay dahil ang mga tao korte kung 812 00:34:11,389 --> 00:34:13,449 kung paano gamitin ang tool. 813 00:34:13,449 --> 00:34:16,250 >> Sila ay ang mga parehong bagay kapag pamanggit database ay imbento, 814 00:34:16,250 --> 00:34:17,969 at sila ay pinapalitan file system. 815 00:34:17,969 --> 00:34:20,420 Sinubukan nila upang bumuo ng mga sistema ng file sa pamanggit database 816 00:34:20,420 --> 00:34:22,159 dahil iyon ang naunawaan ng mga tao. 817 00:34:22,159 --> 00:34:23,049 Hindi ito gumana. 818 00:34:23,049 --> 00:34:26,090 Kaya pag-unawa sa mga pinakamahusay na kasanayan ng teknolohiya ikaw ay nagtatrabaho sa 819 00:34:26,090 --> 00:34:26,730 ay malaking. 820 00:34:26,730 --> 00:34:29,870 Napaka importante. 821 00:34:29,870 --> 00:34:32,440 >> Kaya kami ay pagpunta upang makakuha ng sa DynamoDB. 822 00:34:32,440 --> 00:34:36,480 DynamoDB ay AWS ni fully-pinamamahalaang NoSQL platform. 823 00:34:36,480 --> 00:34:37,719 Ano ang fully-pinamamahalaang ibig sabihin nito? 824 00:34:37,719 --> 00:34:40,010 Ang ibig sabihin nito ay hindi mo na kailangan na talagang mag-alala tungkol sa anumang bagay. 825 00:34:40,010 --> 00:34:42,060 >> Dumating ka sa, sabihin sa iyo , Kailangan ko sa amin ng isang table. 826 00:34:42,060 --> 00:34:43,409 Kailangan itong ganito karami kapasidad. 827 00:34:43,409 --> 00:34:47,300 Pindutin mo ang pindutan, at pagkakaloob namin lahat ng mga imprastraktura sa likod ng mga eksena. 828 00:34:47,300 --> 00:34:48,310 Ngayon na ay napakalubha. 829 00:34:48,310 --> 00:34:51,310 >> Dahil kapag makipag-usap sa iyo tungkol sa scaling ng isang database, 830 00:34:51,310 --> 00:34:53,917 Tumpok data NoSQL sa scale, na tumatakbo petabytes, 831 00:34:53,917 --> 00:34:55,750 tumatakbo milyon-milyong mga mga transaksyon sa bawat segundo, 832 00:34:55,750 --> 00:34:58,180 mga bagay na ito ay hindi maliit na kumpol. 833 00:34:58,180 --> 00:35:00,830 Pinag-uusapan natin ang libu-libong pagkakataon. 834 00:35:00,830 --> 00:35:04,480 Pamamahala ng libo-libo ng mga pagkakataon, kahit virtual pagkakataon, 835 00:35:04,480 --> 00:35:06,350 ay isang tunay na sakit sa puwit. 836 00:35:06,350 --> 00:35:09,110 Ang ibig kong sabihin, mag-isip tungkol sa bawat oras na ang isang patch sistema operating ay out 837 00:35:09,110 --> 00:35:11,552 o ng isang bagong bersyon ng database. 838 00:35:11,552 --> 00:35:13,260 Ano ang kahulugan nito sa iyo operationally? 839 00:35:13,260 --> 00:35:16,330 Iyon ay nangangahulugang ang iyong nakuha 1,200 server na kailangan upang ma-update. 840 00:35:16,330 --> 00:35:18,960 Ngayon kahit sa automation, na maaaring tumagal ng isang mahabang panahon. 841 00:35:18,960 --> 00:35:21,480 Iyon ay maaaring maging sanhi ng maraming sakit ng ulo na pagpapatakbo, 842 00:35:21,480 --> 00:35:23,090 dahil maaaring mayroon ako ng mga serbisyo down. 843 00:35:23,090 --> 00:35:26,070 >> Bilang update ko ang mga database, ako maaaring gawin ng blue green deployments 844 00:35:26,070 --> 00:35:29,420 kung saan ako lumawak at i-upgrade ang kalahati ng aking nodes, at pagkatapos ay mag-upgrade ang iba pang kalahati. 845 00:35:29,420 --> 00:35:30,490 Dalhin ang mga down. 846 00:35:30,490 --> 00:35:33,410 Kaya pamamahala ng infrastructure scale ay sobrang sobra masakit. 847 00:35:33,410 --> 00:35:36,210 At AWS kumuha ng sakit na lumitaw ng ito. 848 00:35:36,210 --> 00:35:39,210 At NoSQL database Maaari maging extraordinarily masakit 849 00:35:39,210 --> 00:35:41,780 dahil sa mga paraan masukat nila. 850 00:35:41,780 --> 00:35:42,926 >> Scale horizontally. 851 00:35:42,926 --> 00:35:45,550 Kung nais mong makakuha ng isang mas malaking NoSQL database, bumili ka ng higit pang mga nodes. 852 00:35:45,550 --> 00:35:48,660 Bawat node bumili ay isa pang operational sakit ng ulo. 853 00:35:48,660 --> 00:35:50,830 Kaya ipaalam sa ibang tao gawin iyon para sa iyo. 854 00:35:50,830 --> 00:35:52,000 AWS maaaring gawin na. 855 00:35:52,000 --> 00:35:54,587 >> Sinusuportahan namin ang mga halaga ng key dokumento. 856 00:35:54,587 --> 00:35:56,670 Ngayon hindi namin ay pumunta masyadong maraming sa sa iba pang mga chart. 857 00:35:56,670 --> 00:35:58,750 May isang pulutong ng mga iba't-ibang flavors ng NoSQL. 858 00:35:58,750 --> 00:36:02,670 Ang mga ito ang lahat ng uri ng pagkuha ng munged magkasama sa puntong ito. 859 00:36:02,670 --> 00:36:06,260 Maaari mong tingnan ang DynamoDB at sabihin ninyo ang oo, kami ay parehong isang dokumento at isang susi halaga 860 00:36:06,260 --> 00:36:08,412 tindahan ng puntong ito. 861 00:36:08,412 --> 00:36:10,620 At maaari mong magtaltalan ang mga tampok ng isa sa mga iba. 862 00:36:10,620 --> 00:36:13,950 Para sa akin, ang isang pulutong ng mga ito ay talagang anim ng isa sa kalahati ng isang dosenang ng iba. 863 00:36:13,950 --> 00:36:18,710 Ang bawat isa sa mga teknolohiyang ito ay isang mainam na teknolohiya at ng masarap na solusyon. 864 00:36:18,710 --> 00:36:23,390 Hindi ko sasabihin MongoDB ay mas mahusay o mas masahol pa kaysa Couch, pagkatapos Cassandra, 865 00:36:23,390 --> 00:36:25,994 pagkatapos Dynamo, o vice versa. 866 00:36:25,994 --> 00:36:27,285 Ibig kong sabihin, ito ay lamang na pagpipilian. 867 00:36:27,285 --> 00:36:29,850 868 00:36:29,850 --> 00:36:32,700 >> Ito ay mabilis at ito ay pare-pareho sa anumang scale. 869 00:36:32,700 --> 00:36:36,210 Kaya ito ay isa sa mga pinakamalaking bonus kang makakuha ng may AWS. 870 00:36:36,210 --> 00:36:40,850 Sa DynamoDB ay ang kakayahan upang makakuha ng isang mababang solong digit 871 00:36:40,850 --> 00:36:44,040 millisecond latency sa anumang scale. 872 00:36:44,040 --> 00:36:45,720 Iyon ay isang disenyo ng layunin ng sistema. 873 00:36:45,720 --> 00:36:49,130 At kami ay may mga customer na ang ginagawa milyon-milyong mga transaksyon sa bawat segundo. 874 00:36:49,130 --> 00:36:52,670 >> Ngayon kukunin ko na pumunta sa pamamagitan ng ilan sa mga gamitin ang mga kaso sa loob ng ilang minuto dito. 875 00:36:52,670 --> 00:36:55,660 Integrated access control-- mayroon kaming kung ano ang tawag namin 876 00:36:55,660 --> 00:36:57,920 Identity Pamamahala ng Access, o IAM. 877 00:36:57,920 --> 00:37:01,980 Ito'y nakikita sa bawat system, bawat serbisyo na nag-aalok ng AWS. 878 00:37:01,980 --> 00:37:03,630 DynamoDB ay walang exception. 879 00:37:03,630 --> 00:37:06,020 Maaari mong kontrolin ang pag-access sa DynamoDB tables. 880 00:37:06,020 --> 00:37:09,960 Sa lahat ng iyong AWS account sa pamamagitan ng pagtukoy ginagampanan access at mga pahintulot 881 00:37:09,960 --> 00:37:12,140 sa IAM infrastructure. 882 00:37:12,140 --> 00:37:16,630 >> At ito ay isang susi at mahalagang bahagi sa ano ang tawag namin Kaganapan hinihimok Programming. 883 00:37:16,630 --> 00:37:19,056 Ngayon, ito ay isang bagong tularan. 884 00:37:19,056 --> 00:37:22,080 >> Madla: Paano kung ang iyong rate ng tunay na positibo kumpara maling negatibo 885 00:37:22,080 --> 00:37:24,052 sa iyong pag-access control system? 886 00:37:24,052 --> 00:37:26,260 RICK Houlihan: True positibo kumpara sa maling negatibo? 887 00:37:26,260 --> 00:37:28,785 Madla: Bumabalik kung ano dapat ay bumabalik? 888 00:37:28,785 --> 00:37:33,720 Bilang laban sa isang beses sa isang habang ito hindi nagbabalik kapag ito ay dapat patunayan? 889 00:37:33,720 --> 00:37:36,260 890 00:37:36,260 --> 00:37:38,050 >> RICK Houlihan: hindi ko maaaring sabihin sa iyo na. 891 00:37:38,050 --> 00:37:40,140 Kung may anumang mga pagkabigo kahit ano pa man sa mga iyon, 892 00:37:40,140 --> 00:37:42,726 Hindi ako ang tao na magtanong na ang partikular na tanong. 893 00:37:42,726 --> 00:37:43,850 Ngunit iyon lamang ang isang magandang katanungan. 894 00:37:43,850 --> 00:37:45,905 Gusto ko maging mausisa malaman na ang aking sarili, talaga. 895 00:37:45,905 --> 00:37:48,810 896 00:37:48,810 --> 00:37:51,320 >> At kaya pagkatapos muli, bagong tularan ay programming driven na kaganapan. 897 00:37:51,320 --> 00:37:55,160 Ito ay ang ideya na maaari mong lumawak kumplikadong mga aplikasyon na 898 00:37:55,160 --> 00:37:59,720 maaaring patakbuhin ang isang tunay, mataas na proporsyon nang walang anumang infrastructure ano pa man. 899 00:37:59,720 --> 00:38:02,120 Nang walang anumang mga nakapirming infrastructure ano pa man. 900 00:38:02,120 --> 00:38:04,720 At kami na makipag-usap nang kaunti tungkol sa kung ano ang ibig sabihin na ang bilang namin 901 00:38:04,720 --> 00:38:06,550 makakuha ng sa sa susunod na pares ng mga chart. 902 00:38:06,550 --> 00:38:08,716 >> Ang unang bagay na gagawin namin ay namin makipag-usap tungkol sa mga talahanayan. 903 00:38:08,716 --> 00:38:10,857 Uri ng data API para sa Dynamo. 904 00:38:10,857 --> 00:38:13,190 At ang unang bagay bibigyan mo paunawa kapag tiningnan mo ang mga ito, 905 00:38:13,190 --> 00:38:17,930 kung hindi ka pamilyar sa anumang database, database ay may talagang dalawang mga uri ng mga API 906 00:38:17,930 --> 00:38:18,430 Gusto kong tumawag ito. 907 00:38:18,430 --> 00:38:21,570 O dalawang set ng mga API. 908 00:38:21,570 --> 00:38:23,840 Isa sa mga nais maging administrative API. 909 00:38:23,840 --> 00:38:26,710 >> Ang mga bagay na sila ay kumuha ng pag-aalaga ng ang mga function ng database. 910 00:38:26,710 --> 00:38:31,340 Pag-configure ng imbakan engine, set up at pagdaragdag ng mga talahanayan. 911 00:38:31,340 --> 00:38:35,180 paglikha database katalogo at pagkakataon. 912 00:38:35,180 --> 00:38:40,450 Ang mga bagay- sa DynamoDB, ikaw Mayroon masyadong maikli, maikling listahan. 913 00:38:40,450 --> 00:38:43,120 >> Kaya sa iba pang mga database, maaari kang makakita ng mga dose-dosenang 914 00:38:43,120 --> 00:38:45,680 ng mga utos, ng administrative command, para sa pagsasaayos 915 00:38:45,680 --> 00:38:47,290 ang mga karagdagang mga pagpipilian. 916 00:38:47,290 --> 00:38:51,234 Sa DynamoDB hindi mo kailangan ng mga dahil hindi mo na i-configure ang sistema, ginagawa namin. 917 00:38:51,234 --> 00:38:54,150 Kaya ang tanging bagay na kailangan mong gawin ay ang sabihin sa akin kung ano ang laki ng talahanayan ang kailangan ko. 918 00:38:54,150 --> 00:38:55,660 Kaya mo makakuha ng isang napaka limitadong hanay ng mga utos. 919 00:38:55,660 --> 00:38:58,618 >> Makakakuha ka ng isang Lumikha Update Table, Table, Tanggalin ang Table, at Ilarawan Table. 920 00:38:58,618 --> 00:39:01,150 Ang mga ay ang tanging bagay kailangan mo para DynamoDB. 921 00:39:01,150 --> 00:39:03,294 Hindi mo kailangan ng isang storage configuration engine. 922 00:39:03,294 --> 00:39:04,960 Hindi ko kailangan mag-alala tungkol sa pagtitiklop. 923 00:39:04,960 --> 00:39:06,490 Hindi ko kailangan mag-alala tungkol sharding. 924 00:39:06,490 --> 00:39:07,800 >> Hindi ko kailangan mag-alala tungkol sa alinman sa mga bagay-bagay na ito. 925 00:39:07,800 --> 00:39:08,740 Ginagawa namin ang lahat ng ito para sa iyo. 926 00:39:08,740 --> 00:39:11,867 Kaya na ang isang malaking halaga ng overhead na lang ang itinaas-off ang iyong mga plate. 927 00:39:11,867 --> 00:39:13,200 Pagkatapos kami ay may CRUD operator. 928 00:39:13,200 --> 00:39:17,740 CRUD ay isang bagay na kung ano ang aming tumawag sa database na 929 00:39:17,740 --> 00:39:19,860 Gumawa, I-update, Tanggalin operator. 930 00:39:19,860 --> 00:39:24,180 Ang mga ito ay ang iyong karaniwang operasyon ng database. 931 00:39:24,180 --> 00:39:31,299 Mga bagay na tulad ilagay item, kumuha ng item, i-update item, tanggalin ang mga item, batch query, i-scan. 932 00:39:31,299 --> 00:39:32,840 Kung nais mong i-scan ang buong table. 933 00:39:32,840 --> 00:39:34,220 Hilahin off ng talahanayan ang lahat. 934 00:39:34,220 --> 00:39:37,130 Isa sa mga magagandang bagay tungkol sa DynamoDB ay nagbibigay-daan ito parallel na pag-scan. 935 00:39:37,130 --> 00:39:40,602 Kaya maaari mong aktwal na ipaalam sa akin kung gaano karaming thread na gusto mong patakbuhin sa na scan. 936 00:39:40,602 --> 00:39:41,810 At maaari naming patakbuhin ang mga thread. 937 00:39:41,810 --> 00:39:43,985 Maaari naming iikot na scan up sa kabuuan ng maramihang mga thread 938 00:39:43,985 --> 00:39:49,060 sa gayon maaari mong i-scan ang buong table space tunay, tunay mabilis sa DynamoDB. 939 00:39:49,060 --> 00:39:51,490 >> Ang iba pang mga API na mayroon kami ay kung ano ang tawag namin sa aming Streams API. 940 00:39:51,490 --> 00:39:52,940 Hindi namin pagpunta sa makipag-usap ng masyadong marami tungkol sa mga ito ngayon. 941 00:39:52,940 --> 00:39:55,189 Mayroon akong ilang mga nilalaman sa ibang pagkakataon on sa deck tungkol dito. 942 00:39:55,189 --> 00:39:59,910 Ngunit Streams ay talagang isang running-- tingin ng mga ito bilang ng oras order 943 00:39:59,910 --> 00:40:01,274 at baguhin ang partition log. 944 00:40:01,274 --> 00:40:03,940 Lahat ng bagay na nangyayari sa ang talahanayan ay nagpapakita ng hanggang sa stream. 945 00:40:03,940 --> 00:40:05,940 >> Bawat sumulat sa talahanayan nagpapakita up sa stream. 946 00:40:05,940 --> 00:40:08,370 Maaari mong basahin na stream, at maaari mong gawin ang mga bagay sa mga ito. 947 00:40:08,370 --> 00:40:10,150 Susubukan naming makipag-usap tungkol sa kung ano mga uri ng mga bagay-bagay sa iyo 948 00:40:10,150 --> 00:40:13,680 kinalaman sa mga bagay na tulad ng pagtitiklop, paglikha pangalawang index. 949 00:40:13,680 --> 00:40:17,620 Lahat ng uri ng mga talagang cool na mga bagay na maaari mong gawin sa mga iyon. 950 00:40:17,620 --> 00:40:19,150 >> Uri ng data. 951 00:40:19,150 --> 00:40:23,320 Sa DynamoDB, sinusuportahan namin ang parehong mga key halaga at data na dokumento uri. 952 00:40:23,320 --> 00:40:26,350 Sa kaliwang bahagi ng screen dito, namin nakuha ang aming pangunahing mga uri. 953 00:40:26,350 --> 00:40:27,230 Key mga uri ng halaga. 954 00:40:27,230 --> 00:40:30,040 Ang mga ito ay mga string, numero, at binaries. 955 00:40:30,040 --> 00:40:31,640 >> Kaya lang tatlong pangunahing mga uri. 956 00:40:31,640 --> 00:40:33,700 At pagkatapos ay maaari kang magkaroon ng mga hanay ng mga iyon. 957 00:40:33,700 --> 00:40:37,650 Isa sa mga magagandang bagay tungkol sa NoSQL ay maaari mong maglaman array bilang properties. 958 00:40:37,650 --> 00:40:42,050 At sa pamamagitan DynamoDB maaari mong maglaman array ng mga pangunahing uri gaya ng ugat sa ari-arian. 959 00:40:42,050 --> 00:40:43,885 >> At pagkatapos ay may mga uri ng dokumento. 960 00:40:43,885 --> 00:40:45,510 Gaano karaming mga tao ay pamilyar sa JSON? 961 00:40:45,510 --> 00:40:47,130 Ikaw guys pamilyar sa gayon JSON? 962 00:40:47,130 --> 00:40:49,380 Ito ay isa lamang JavaScript, Bagay, pagtatanda. 963 00:40:49,380 --> 00:40:52,510 Ito ay nagbibigay-daan sa iyo upang talaga tukuyin ang isang hierarchical istraktura. 964 00:40:52,510 --> 00:40:58,107 >> Maaari mong i-imbak ang isang JSON dokumento sa DynamoDB gamit ang karaniwang mga sangkap 965 00:40:58,107 --> 00:41:00,940 o mga bloke ng gusali na magagamit sa karamihan ng mga wika programming. 966 00:41:00,940 --> 00:41:03,602 Kaya kung mayroon kang Java, ikaw ay naghahanap sa mapa at mga listahan. 967 00:41:03,602 --> 00:41:05,060 Maaari ba akong lumikha ng mga bagay na lugar ng mapa. 968 00:41:05,060 --> 00:41:08,030 Ang isang mapa bilang susi halaga naka-imbak na mga katangian. 969 00:41:08,030 --> 00:41:10,890 At ito ay maaaring magkaroon ng mga listahan ng mga mga halaga sa loob ng mga katangian. 970 00:41:10,890 --> 00:41:13,490 Maaari mong itabi ang complex na ito hierarchical istraktura 971 00:41:13,490 --> 00:41:16,320 bilang isang solong attribute ng isang DynamoDB item. 972 00:41:16,320 --> 00:41:19,010 973 00:41:19,010 --> 00:41:24,460 >> Kaya talahanayan sa DynamoDB, tulad ng karamihan NoSQL mga database, mga talahanayan ay may mga item. 974 00:41:24,460 --> 00:41:26,469 Sa MongoDB gagawin mo tumawag sa mga dokumento. 975 00:41:26,469 --> 00:41:27,760 At magiging sopa base. 976 00:41:27,760 --> 00:41:28,900 Gayundin isang database dokumento. 977 00:41:28,900 --> 00:41:29,941 Tawagan mo ang mga dokumentong ito. 978 00:41:29,941 --> 00:41:32,930 Magkaroon ng mga katangian ng mga dokumento o mga bagay. 979 00:41:32,930 --> 00:41:35,850 Maaaring umiiral Katangian o Hindi umiiral ang item. 980 00:41:35,850 --> 00:41:38,520 Sa DynamoDB, may isa sapilitan attribute. 981 00:41:38,520 --> 00:41:43,880 Katulad ng sa isang pamanggit database, ikaw ay may isang pangunahing susi sa mesa. 982 00:41:43,880 --> 00:41:46,010 >> DynamoDB may kung ano ang tawag namin sa isang hash key. 983 00:41:46,010 --> 00:41:48,280 Ay dapat na natatangi hash key. 984 00:41:48,280 --> 00:41:52,580 Kaya kapag ko tutukuyin ang isang hash table, talaga kung ano ako sinasabi 985 00:41:52,580 --> 00:41:54,110 ay ang bawat item ay magkakaroon ng isang hash key. 986 00:41:54,110 --> 00:41:58,520 At bawat hash key ay dapat na kakaiba. 987 00:41:58,520 --> 00:42:01,200 >> Ang bawat item ay tinukoy sa pamamagitan ng na natatanging hash key. 988 00:42:01,200 --> 00:42:02,940 At doon ay maaari lamang maging isa. 989 00:42:02,940 --> 00:42:05,820 Ito ay OK, ngunit malimit kung ano ang kailangan ng mga tao 990 00:42:05,820 --> 00:42:08,170 ay ang nais nila ay ang hash key upang makagawa ng higit pa sa isang maliit na piraso 991 00:42:08,170 --> 00:42:11,010 kaysa sa maging lamang ng isang natatanging identifier. 992 00:42:11,010 --> 00:42:15,240 Madalas gusto naming gamitin na hash key bilang sa itaas ng pagsasama-sama antas bucket. 993 00:42:15,240 --> 00:42:19,160 At ang paraan namin na sa pamamagitan ng pagdagdag ng kung ano ang tawag namin sa isang hanay key. 994 00:42:19,160 --> 00:42:22,460 >> Kaya kung ito ay isang hash lamang table, ito ay dapat na kakaiba. 995 00:42:22,460 --> 00:42:27,040 Kung ito ay isang hash at hanay ng talahanayan, ang mga kumbinasyon ng hash at ang hanay 996 00:42:27,040 --> 00:42:28,640 dapat na kakaiba. 997 00:42:28,640 --> 00:42:30,110 Kaya mag-isip tungkol sa mga ito sa ganitong paraan. 998 00:42:30,110 --> 00:42:32,140 Kung mayroon akong isang forum. 999 00:42:32,140 --> 00:42:39,010 At ang mga form ay may mga paksa, ito ay may nag-post, at ito ay may mga sagot. 1000 00:42:39,010 --> 00:42:42,630 >> Kaya maaari ba akong magkaroon ng isang hash key, na kung saan ay ang ID topic. 1001 00:42:42,630 --> 00:42:46,650 At maaari ba akong magkaroon ng isang hanay key, kung saan ay ang ID na tugon. 1002 00:42:46,650 --> 00:42:49,650 Sa ganoong paraan kung gusto kong makuha ang lahat ng mga tugon para sa partikular na paksa, 1003 00:42:49,650 --> 00:42:52,370 Maaari ko lang i-query ang hash. 1004 00:42:52,370 --> 00:42:55,190 Maaari ko bang sabihin lamang magbigay sa akin ang lahat ang mga item na may ganitong hash. 1005 00:42:55,190 --> 00:43:01,910 At ako pagpunta upang makakuha ng lahat ng tanong o mag-post para sa partikular na paksa. 1006 00:43:01,910 --> 00:43:03,910 Ang mga top level aggregations ay lubhang mahalaga. 1007 00:43:03,910 --> 00:43:07,370 Sinusuportahan nila ang mga pangunahing access pattern ng application. 1008 00:43:07,370 --> 00:43:09,420 Sa pangkalahatan, ito ay kung ano ang gusto naming gawin. 1009 00:43:09,420 --> 00:43:11,780 Nais namin na ang table-- load ka sa table, 1010 00:43:11,780 --> 00:43:16,640 gusto naming buuin ang data sa loob ng talahanayan sa paraan 1011 00:43:16,640 --> 00:43:20,140 na ang application ay maaaring tunay mabilis na makuha ang mga resulta. 1012 00:43:20,140 --> 00:43:24,510 At madalas ang mga paraan upang gawin iyon ay upang mapanatili ang mga pagsasama-sama bilang namin 1013 00:43:24,510 --> 00:43:25,650 ipasok ang data. 1014 00:43:25,650 --> 00:43:31,110 Talaga, kami ay nagkakalat ang data sa maliwanag na bucket na ito ay dumating sa. 1015 00:43:31,110 --> 00:43:35,210 >> Saklaw keys payagan me-- hash keys kailangang maging pagkakapantay-pantay. 1016 00:43:35,210 --> 00:43:39,490 Kapag query ako ng hash, kailangan kong sabihin bigyan ako ng isang hash na katumbas na ito. 1017 00:43:39,490 --> 00:43:41,950 Kapag query ko ang isang hanay, ako masasabi ninyo ako ng hanay 1018 00:43:41,950 --> 00:43:47,040 na gumagamit ng anumang uri ng mayaman operator na sinusuportahan namin. 1019 00:43:47,040 --> 00:43:49,200 Bigyan mo ako ng lahat ng mga item para sa isang hash. 1020 00:43:49,200 --> 00:43:52,520 Ito ba ay pantay-pantay, mas malaki kaysa sa, mas mababa sa, nag-uumpisa ito sa, 1021 00:43:52,520 --> 00:43:54,145 ang umiiral sa pagitan ng dalawang mga halaga? 1022 00:43:54,145 --> 00:43:56,811 Kaya ang mga uri ng mga query na hanay na kami ay laging interesado sa. 1023 00:43:56,811 --> 00:43:59,650 Ngayon ang isang bagay tungkol sa data, kapag tumingin ka sa pag-access ng data, kapag 1024 00:43:59,650 --> 00:44:02,360 access mo ang data, ito ay palaging tungkol sa isang pagsasama-sama. 1025 00:44:02,360 --> 00:44:05,770 Ito ay palaging tungkol sa mga talaan na may kaugnayan sa mga ito. 1026 00:44:05,770 --> 00:44:10,390 Bigyan mo ako ng lahat ng bagay dito that's-- lahat ang mga transaksyon na ito sa credit card 1027 00:44:10,390 --> 00:44:12,500 para sa nakaraang buwan. 1028 00:44:12,500 --> 00:44:13,960 Iyan ay isang pagsasama-sama. 1029 00:44:13,960 --> 00:44:17,490 >> Halos lahat ng ginagawa mo sa database ay ilang mga uri ng pagsasama-sama. 1030 00:44:17,490 --> 00:44:21,530 Kaya ng kakayahang ma-define mga bucket at magbibigay sa iyo ng mga hanay 1031 00:44:21,530 --> 00:44:24,950 katangian para ma-i-query sa, sumusuporta sa mga mayaman na mga query sa marami, 1032 00:44:24,950 --> 00:44:27,165 maraming, maraming mga pattern access application. 1033 00:44:27,165 --> 00:44:30,990 1034 00:44:30,990 --> 00:44:35,000 >> Kaya ang iba pang mga bagay ang hash key ay ito ay nagbibigay sa amin ng isang mekanismo 1035 00:44:35,000 --> 00:44:37,740 para ma-kumalat ang data sa paligid. 1036 00:44:37,740 --> 00:44:40,390 Pinakamahusay NoSQL database gumagana kapag ang data ay pantay-pantay 1037 00:44:40,390 --> 00:44:41,740 ipinamamahagi sa buong kumpol. 1038 00:44:41,740 --> 00:44:44,530 1039 00:44:44,530 --> 00:44:47,050 Gaano karaming mga tao ay pamilyar may hashing algorithms? 1040 00:44:47,050 --> 00:44:49,860 Kapag sinasabi ko hash at isang hashing-- dahil ang isang hashing algorithm 1041 00:44:49,860 --> 00:44:54,140 ay isang paraan ng pagiging magagawang upang bumuo ng isang random na halaga mula sa anumang ibinigay na halaga. 1042 00:44:54,140 --> 00:44:59,300 Kaya sa ganitong kaso, ang hash algorithm tumakbo kami ay nd 5 based. 1043 00:44:59,300 --> 00:45:04,765 >> At kung mayroon akong isang ID, at ito ay ang aking hash key, Mayroon akong 1, 2, 3. 1044 00:45:04,765 --> 00:45:07,390 Kapag tumakbo ang hash algorithm, ito ay pagpunta sa bumalik at sabihin, 1045 00:45:07,390 --> 00:45:10,800 well 1 ay katumbas ng 7B, 2 ay katumbas ng 48, 3 ay katumbas ng CD. 1046 00:45:10,800 --> 00:45:13,092 Ang mga ito ay kumalat sa buong key space. 1047 00:45:13,092 --> 00:45:14,050 At bakit mo gawin ito? 1048 00:45:14,050 --> 00:45:17,120 Dahil na tinitiyak na makakaya ko ilagay ang mga tala sa maramihang nodes. 1049 00:45:17,120 --> 00:45:19,574 >> Kung ako gawin ito paunti-unti, 1, 2, 3. 1050 00:45:19,574 --> 00:45:21,990 At ako ay may isang hanay hash na tumatakbo sa partikular na kasong, 1051 00:45:21,990 --> 00:45:24,785 isang maliit na espasyo hash, ito ay tumatakbo mula sa 00 na FF, 1052 00:45:24,785 --> 00:45:27,951 pagkatapos ay ang mga talaan ay pagpunta sa dumating sa at sila ay pagpunta sa pumunta sa 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 Ano ang mangyayari? 1055 00:45:31,800 --> 00:45:34,860 Bawat insert ay pagpunta sa parehong node. 1056 00:45:34,860 --> 00:45:36,070 Makikita mo kung ano ang ibig sabihin ko? 1057 00:45:36,070 --> 00:45:40,910 >> Dahil kapag ako split ang space, at ikakalat ko ang mga talaang kabuuan, 1058 00:45:40,910 --> 00:45:45,950 at ako partition, pupuntahan ko sabihin partition 1 ay may key space 0-54. 1059 00:45:45,950 --> 00:45:47,720 Partition 2 ay 55-89. 1060 00:45:47,720 --> 00:45:49,780 Partition 3 ay AA sa FF. 1061 00:45:49,780 --> 00:45:53,740 Kaya kung gumagamit ako ng linearly incrementing ID, maaari mong makita kung ano ang nangyayari. 1062 00:45:53,740 --> 00:45:57,410 1, 2, 3, 4, 5, 6, ang lahat ng mga paraan ng hanggang sa 54. 1063 00:45:57,410 --> 00:46:00,030 Kaya bilang ako pagmamartilyo ang records sa system, 1064 00:46:00,030 --> 00:46:02,030 nagtatapos up sa lahat ng pagpunta sa isa node. 1065 00:46:02,030 --> 00:46:03,160 >> Iyan ay hindi mabuti. 1066 00:46:03,160 --> 00:46:04,820 Iyan ay isang antipattern. 1067 00:46:04,820 --> 00:46:08,760 Sa MongoDB nila ang problemang ito kung hindi ka gumagamit ng isang hash key. 1068 00:46:08,760 --> 00:46:11,325 Binibigyan ka MongoDB ang pagpipilian ng hashing ang key na halaga. 1069 00:46:11,325 --> 00:46:13,950 Ikaw ay dapat palaging gawin iyon, kung gumagamit ka ng isang incrementing hash 1070 00:46:13,950 --> 00:46:17,380 key sa MongoDB, o kayo ay ipinapako bawat write sa isa node, 1071 00:46:17,380 --> 00:46:21,290 at ikaw ay takda iyong write throughput masama. 1072 00:46:21,290 --> 00:46:24,896 >> Madla: Ay na A9 169 in decimal? 1073 00:46:24,896 --> 00:46:28,450 >> RICK Houlihan: Oo, ito ay isang lugar sa paligid doon. 1074 00:46:28,450 --> 00:46:29,950 A9, hindi ko alam. 1075 00:46:29,950 --> 00:46:32,200 Gusto mo na makuha ang aking binary sa calculator decimal. 1076 00:46:32,200 --> 00:46:34,237 Ang aking utak ay hindi gumagana tulad na. 1077 00:46:34,237 --> 00:46:36,320 Madla: lamang ng isang mabilis na isa ng iyong Mongo komento. 1078 00:46:36,320 --> 00:46:39,530 Kaya ay ang object ID na nanggagaling natively sa Mongo gawin iyon? 1079 00:46:39,530 --> 00:46:40,179 1080 00:46:40,179 --> 00:46:41,470 RICK Houlihan: gawin ba ito na? 1081 00:46:41,470 --> 00:46:42,970 Kung tinukoy mo ito. 1082 00:46:42,970 --> 00:46:45,030 Sa MongoDB, mayroon kang pagpipilian. 1083 00:46:45,030 --> 00:46:48,930 Maaari mong specify-- bawat dokumento MongoDB ay upang magkaroon ng isang underscore ID. 1084 00:46:48,930 --> 00:46:50,300 Iyan ang mga natatanging halaga. 1085 00:46:50,300 --> 00:46:55,240 >> Sa MongoDB maaari mong tukuyin ang kung mag-hash ito o hindi. 1086 00:46:55,240 --> 00:46:56,490 Sila lang bigyan ka ng opsyon. 1087 00:46:56,490 --> 00:46:58,198 Kung alam mo na ito ay random, walang problema. 1088 00:46:58,198 --> 00:46:59,640 Hindi mo na kailangan na gawin iyon. 1089 00:46:59,640 --> 00:47:04,260 Kung alam mo na ito ay hindi random, na ito ay incrementing, pagkatapos ay gawin ang hash. 1090 00:47:04,260 --> 00:47:06,880 >> Ngayon ang mga bagay tungkol sa hashing, sa sandaling sumira sa iyo 1091 00:47:06,880 --> 00:47:08,800 isang value-- at ito ay bakit hash key ay palaging 1092 00:47:08,800 --> 00:47:13,740 natatanging mga tanong, dahil ko na nagbago ang halaga, ngayon ay hindi ko gawin ang isang query range. 1093 00:47:13,740 --> 00:47:15,640 Hindi ko masabi ito pagitan ng mga ito o na, 1094 00:47:15,640 --> 00:47:20,800 dahil ang halaga ng hash ay hindi pagpunta upang maging katumbas sa aktwal na halaga. 1095 00:47:20,800 --> 00:47:24,570 Kaya kapag hash mo na key, ito ay ang pagkakapantay-pantay lamang. 1096 00:47:24,570 --> 00:47:28,700 Ito ang dahilan kung bakit sa DynamoDB hash key mga tanong ay palaging ang pagkakapantay-pantay lamang. 1097 00:47:28,700 --> 00:47:32,090 1098 00:47:32,090 --> 00:47:34,700 >> Kaya ngayon sa isang hanay key-- kapag nagdagdag ako na hanay key, 1099 00:47:34,700 --> 00:47:38,180 lahat ng dumating sa mga talaang hanay key at sila makakuha ng mga naka-imbak sa parehong partition. 1100 00:47:38,180 --> 00:47:42,430 Kaya ikaw ay masyadong mabilis ang mga ito, madaling nabawi dahil ito ay ang hash, 1101 00:47:42,430 --> 00:47:43,220 ito ay ang saklaw. 1102 00:47:43,220 --> 00:47:44,928 At nakita mo ang lahat ng bagay na may parehong hash 1103 00:47:44,928 --> 00:47:48,550 makakakuha ng naka-imbak sa parehong puwang partition. 1104 00:47:48,550 --> 00:47:53,889 Maaari mong gamitin na hanay key upang makatulong hanapin ang iyong data ng malapit sa kanyang magulang. 1105 00:47:53,889 --> 00:47:55,180 Kaya kung ano ay talagang ginagawa ko dito? 1106 00:47:55,180 --> 00:47:57,320 Ito ang isa sa maraming relasyon. 1107 00:47:57,320 --> 00:48:01,490 Ang relasyon sa pagitan ng isang hash key at ang hanay key ay isa sa maraming. 1108 00:48:01,490 --> 00:48:03,490 Maaari ba akong magkaroon ng maramihang mga hash key. 1109 00:48:03,490 --> 00:48:07,610 Maaari ko lamang magkaroon ng maramihang mga hanay susi sa loob ng bawat hash key. 1110 00:48:07,610 --> 00:48:11,910 >> Hash tumutukoy sa mga magulang, ang hanay na tumutukoy sa mga bata. 1111 00:48:11,910 --> 00:48:15,240 Kaya maaari mong makita doon ang analog dito sa pagitan ng mga pamanggit tayuan 1112 00:48:15,240 --> 00:48:18,840 at ang parehong mga uri ng constructs sa NoSQL. 1113 00:48:18,840 --> 00:48:20,760 Nagsasalita ang mga tao tungkol sa NoSQL bilang nonrelational. 1114 00:48:20,760 --> 00:48:22,200 Ito ay hindi nonrelational. 1115 00:48:22,200 --> 00:48:24,680 Laging may relasyon Data. 1116 00:48:24,680 --> 00:48:28,172 Ang mga relasyon lamang ay imo-modelo na naiiba. 1117 00:48:28,172 --> 00:48:29,880 Makipag-usap sa isang maliit Ipaalam kaunti tungkol sa tibay. 1118 00:48:29,880 --> 00:48:34,860 Kapag nagsulat ka sa DynamoDB, nagsusulat ay laging may tatlong paraan Ginagaya. 1119 00:48:34,860 --> 00:48:37,550 Ibig sabihin na may tatlong AZ ni namin. 1120 00:48:37,550 --> 00:48:39,160 AZ ni ay Availability Zones. 1121 00:48:39,160 --> 00:48:43,430 Maaari mong isipin na ang isang Availability Zone bilang isang data center 1122 00:48:43,430 --> 00:48:45,447 o isang koleksyon ng data centers. 1123 00:48:45,447 --> 00:48:47,780 Ang mga bagay ay heograpiya nakahiwalay mula sa bawat isa 1124 00:48:47,780 --> 00:48:51,610 sa iba't ibang mga fault zone, sa kabuuan iba't-ibang kapangyarihan grids at floodplains. 1125 00:48:51,610 --> 00:48:54,510 Ang isang kabiguan sa isa sa AZ ay hindi pagpunta sa kumuha ng down-isa. 1126 00:48:54,510 --> 00:48:56,890 Ang mga ito ay naka-link din kasama ang madilim na hibla. 1127 00:48:56,890 --> 00:49:01,240 Ito ay sumusuporta sa isang sub 1 millisecond latency sa pagitan Azs. 1128 00:49:01,240 --> 00:49:05,390 Kaya real time replications data may kaya sa multi Azs. 1129 00:49:05,390 --> 00:49:09,990 >> At malimit multi AZ deployments matugunan ang mga mataas na mga kinakailangan availability 1130 00:49:09,990 --> 00:49:12,930 ng karamihan sa mga organisasyon enterprise. 1131 00:49:12,930 --> 00:49:16,139 Kaya DynamoDB ay kumakalat sa kabuuan ng tatlong Azs pamamagitan ng default. 1132 00:49:16,139 --> 00:49:19,430 Tanging Kami ay pagpunta sa kaalaman ang write kapag ang dalawang sa mga tatlong nodes ay bumalik 1133 00:49:19,430 --> 00:49:21,470 at sabihin, Oo, nakuha ko ito. 1134 00:49:21,470 --> 00:49:22,050 Bakit na? 1135 00:49:22,050 --> 00:49:25,950 Dahil sa nabasa na side hindi namin lamang pagpunta sa iyo ang data sa likod kapag 1136 00:49:25,950 --> 00:49:27,570 makuha namin ito mula sa dalawang nodes. 1137 00:49:27,570 --> 00:49:30,490 >> Kung ako Kinokopya kabuuan tatlo, at ako sa pagbabasa mula sa dalawa, 1138 00:49:30,490 --> 00:49:32,840 Lagi akong garantisadong na magkaroon ng hindi bababa sa isang 1139 00:49:32,840 --> 00:49:35,720 sa mga bumabasa na ang pinaka-kasalukuyang kopya ng data. 1140 00:49:35,720 --> 00:49:38,340 Iyon ay kung bakit pare-pareho DynamoDB. 1141 00:49:38,340 --> 00:49:42,450 Ngayon ay maaari mong piliin upang i-on pare-pareho sa mga nagbabasa ng off. 1142 00:49:42,450 --> 00:49:45,070 Sa anong kaso ako pagpunta sa sabihin, Kukunin ko lamang basahin mula sa isang node. 1143 00:49:45,070 --> 00:49:47,430 At hindi ko masisiguro na ito ay pagpunta na ang pinaka-kasalukuyang data. 1144 00:49:47,430 --> 00:49:49,450 >> Kaya kung ang isang write ay dumarating, ito ay hindi pa kinokopya, 1145 00:49:49,450 --> 00:49:50,360 ikaw ay pagpunta upang makakuha ng kopya. 1146 00:49:50,360 --> 00:49:52,220 Iyan ay isang pare-pareho sa huli read. 1147 00:49:52,220 --> 00:49:54,640 At ano na ang kalahati ng gastos. 1148 00:49:54,640 --> 00:49:56,140 Kaya ito ay isang bagay na isipin ang tungkol. 1149 00:49:56,140 --> 00:50:00,160 Kapag ikaw ay pagbabasa out DynamoDB, at naka-set up ang iyong kapasidad read 1150 00:50:00,160 --> 00:50:04,430 units, kung pinili mo sa huli pare-pareho bumabasa, ito ay isang pulutong mas mura, 1151 00:50:04,430 --> 00:50:06,010 ito ay tungkol sa kalahati ng gastos. 1152 00:50:06,010 --> 00:50:09,342 >> At kaya ito makakatipid ka ng pera. 1153 00:50:09,342 --> 00:50:10,300 Ngunit iyon lamang ang iyong mga pagpipilian. 1154 00:50:10,300 --> 00:50:12,925 Kung nais mo ang isang pare-pareho read o isang pare-pareho sa huli read. 1155 00:50:12,925 --> 00:50:15,720 Iyan ay isang bagay na maaari mong piliin. 1156 00:50:15,720 --> 00:50:17,659 >> Makipag-usap tungkol index Hayaan. 1157 00:50:17,659 --> 00:50:19,450 Kaya nabanggit namin na tuktok na antas ng pagsasama-sama. 1158 00:50:19,450 --> 00:50:23,720 Mayroon kami ng hash key, at Nakakuha kami ng hanay keys. 1159 00:50:23,720 --> 00:50:24,320 Maganda yan. 1160 00:50:24,320 --> 00:50:26,950 At na sa pangunahing table, ako got isa hash key, Nakatanggap ako ng isa hanay key. 1161 00:50:26,950 --> 00:50:27,783 >> Ano ang ibig sabihin nito? 1162 00:50:27,783 --> 00:50:30,410 Mayroon akong isang katangian na ako maaaring tumakbo mayaman tanong laban. 1163 00:50:30,410 --> 00:50:31,800 Ito ay ang hanay key. 1164 00:50:31,800 --> 00:50:35,530 Ang iba pang mga katangian sa na item-- Maaari ko bang i-filter sa mga katangiang iyon. 1165 00:50:35,530 --> 00:50:40,050 Ngunit hindi ko maaaring gumawa ng mga bagay tulad ng, ito nagsisimula sa, o ay mas malaki sa. 1166 00:50:40,050 --> 00:50:40,820 >> Paano ko gagawin yan? 1167 00:50:40,820 --> 00:50:42,860 Gumawa ako ng isang index. 1168 00:50:42,860 --> 00:50:45,340 Mayroong dalawang uri ng mga index sa DynamoDB. 1169 00:50:45,340 --> 00:50:49,002 Ang isang index ay talagang isa pang view ng talahanayan. 1170 00:50:49,002 --> 00:50:50,490 At ang mga lokal na sekundaryong index. 1171 00:50:50,490 --> 00:50:51,781 >> Ang unang isa namin makipag-usap tungkol sa. 1172 00:50:51,781 --> 00:50:57,740 Kaya lokal secondaries ay coexisted sa parehong partition bilang ang data. 1173 00:50:57,740 --> 00:51:00,240 At dahil dito, ang mga ito sa parehong pisikal na node. 1174 00:51:00,240 --> 00:51:01,780 Ang mga ito ay kung ano ang tawag namin pare-pareho. 1175 00:51:01,780 --> 00:51:04,599 Ibig sabihin, sila ay kinikilala ang sumulat kasama ng table. 1176 00:51:04,599 --> 00:51:06,890 Kapag dumarating sa write, makikita namin magsulat sa pamamagitan ng index. 1177 00:51:06,890 --> 00:51:09,306 Makikita isulat namin up sa table, at pagkatapos ay namin kinikilala. 1178 00:51:09,306 --> 00:51:10,490 Kaya na pare-pareho. 1179 00:51:10,490 --> 00:51:13,174 Kapag ang mga write ay kinikilala mula sa talahanayan, 1180 00:51:13,174 --> 00:51:15,090 ito ay garantisadong na ang lokal na sekundaryong index 1181 00:51:15,090 --> 00:51:18,380 ay magkakaroon ng parehong paningin ng data. 1182 00:51:18,380 --> 00:51:22,390 Ngunit kung ano ang pinapayagan nila ang gagawin mo ay tukuyin ang kahaliling hanay keys. 1183 00:51:22,390 --> 00:51:25,260 >> Magkaroon upang gamitin ang parehong hash key bilang pangunahing table, 1184 00:51:25,260 --> 00:51:29,050 dahil sila ay co-matatagpuan sa parehong partition, at ang mga ito ay pare-pareho. 1185 00:51:29,050 --> 00:51:33,110 Ngunit maaari kong lumikha ng isang index may iba't ibang hanay keys. 1186 00:51:33,110 --> 00:51:41,590 Kaya halimbawa, kung ako ay isang tagagawa na nagkaroon ng isang raw talahanayan bahagi pagdating sa. 1187 00:51:41,590 --> 00:51:44,590 At raw bahagi dumating sa, at sila ay pinagsama-sama sa pamamagitan ng pagpupulong. 1188 00:51:44,590 --> 00:51:46,840 At siguro mayroong isang pagpapabalik. 1189 00:51:46,840 --> 00:51:50,240 >> Anumang bahagi na ginawa sa pamamagitan na ito tagagawa pagkatapos ng petsang ito, 1190 00:51:50,240 --> 00:51:52,840 Kailangan ko upang hilahin mula sa aking linya. 1191 00:51:52,840 --> 00:51:55,950 Maaari ko bang iikot ng isang index na ay naghahanap, 1192 00:51:55,950 --> 00:52:00,760 pinagsasama-sama sa petsa ng paggawa ng mga partikular na bahagi. 1193 00:52:00,760 --> 00:52:03,930 Kaya kung ang aking table top level ay nai-hash pamamagitan ng tagagawa, 1194 00:52:03,930 --> 00:52:07,655 marahil ito ay nakaayos sa bahagi ID, ako ay maaaring lumikha ng isang index off table na 1195 00:52:07,655 --> 00:52:11,140 bilang hash pamamagitan ng tagagawa at ranged sa petsa ng paggawa. 1196 00:52:11,140 --> 00:52:14,490 At ang paraan na kaya kong sabihin, anumang bagay na ay gawa sa pagitan ng mga petsang ito, 1197 00:52:14,490 --> 00:52:16,804 Kailangan ko upang hilahin mula sa linya. 1198 00:52:16,804 --> 00:52:18,220 Kaya na ang isang lokal na sekundaryong index. 1199 00:52:18,220 --> 00:52:22,280 >> Ang mga ito ay ang epekto ng takda sa inyong space hash key. 1200 00:52:22,280 --> 00:52:24,360 Dahil ang mga ito co-umiiral sa parehong node storage, 1201 00:52:24,360 --> 00:52:26,860 limitasyon nila ang hash key space sa 10 gigabytes. 1202 00:52:26,860 --> 00:52:28,950 DynamoDB, sa ilalim ng mga talahanayan, ay pagkahati 1203 00:52:28,950 --> 00:52:31,380 iyong talahanayan bawat 10 gigabytes. 1204 00:52:31,380 --> 00:52:34,760 Kapag inilagay mo ang 10 gig ng data sa, kami pumunta [PHH], at magdagdag ng isa pang node. 1205 00:52:34,760 --> 00:52:38,120 1206 00:52:38,120 --> 00:52:42,070 >> Hindi namin ay nahati ang LSI sa kabuuan ng maramihang mga partisyon. 1207 00:52:42,070 --> 00:52:43,200 Susubukan naming hatiin ang table. 1208 00:52:43,200 --> 00:52:44,679 Ngunit hindi pa namin ay nahati ang LSI. 1209 00:52:44,679 --> 00:52:46,470 Kaya na ang isang bagay Mahalaga na maunawaan 1210 00:52:46,470 --> 00:52:50,070 ay kung ikaw ay gumagawa ng tunay, napaka, napakalaking aggregations, 1211 00:52:50,070 --> 00:52:53,860 pagkatapos ikaw ay pagpunta sa magiging limitado hanggang 10 gigabytes sa iyong LSIs. 1212 00:52:53,860 --> 00:52:56,640 >> Kung iyon ang kaso, maaari naming gamitin ang global secondaries. 1213 00:52:56,640 --> 00:52:58,630 Global secondaries ay talagang ibang table. 1214 00:52:58,630 --> 00:53:01,720 Sila ay umiiral ganap off sa sa gilid ng iyong pangunahing table. 1215 00:53:01,720 --> 00:53:04,680 At payagan sila sa akin upang makahanap ng isang ganap na naiibang mga istraktura. 1216 00:53:04,680 --> 00:53:08,010 Kaya sa tingin ng mga ito bilang ang data ay nakapasok sa dalawang iba't ibang mga talahanayan, nakabalangkas 1217 00:53:08,010 --> 00:53:09,220 sa dalawang magkaibang paraan. 1218 00:53:09,220 --> 00:53:11,360 >> Maaari ko bang tukuyin ang isang ganap na iba't ibang hash key. 1219 00:53:11,360 --> 00:53:13,490 Maaari ko bang tukuyin ang isang ganap na iba't-ibang mga hanay key. 1220 00:53:13,490 --> 00:53:15,941 At maaari kong patakbuhin ang ganap na malaya. 1221 00:53:15,941 --> 00:53:18,190 Bilang isang bagay ng katotohanan, na ako provision aking read kapasidad 1222 00:53:18,190 --> 00:53:21,090 at isulat ang kapasidad para sa aking global pangalawang index 1223 00:53:21,090 --> 00:53:24,240 ganap na malaya ng aking pangunahing table. 1224 00:53:24,240 --> 00:53:26,640 Kung ako tukuyin index na, sinasabi ko ito kung magkano ang basahin at isulat 1225 00:53:26,640 --> 00:53:28,610 kapasidad na ito ay pagpunta sa gumagamit. 1226 00:53:28,610 --> 00:53:31,490 >> At iyon ay hiwalay na mula sa aking pangunahing table. 1227 00:53:31,490 --> 00:53:35,240 Ngayon ang parehong mga ini-index ng daan sa amin upang tukuyin hindi lamang hash at hanay key, 1228 00:53:35,240 --> 00:53:38,610 ngunit pinapayagan nila sa amin upang proyekto ng karagdagang halaga. 1229 00:53:38,610 --> 00:53:44,950 Kaya kung gusto kong basahin off ang index, at gusto kong makakuha ng ilang mga hanay ng data, 1230 00:53:44,950 --> 00:53:48,327 Hindi ko na kailangan upang bumalik sa pangunahing talahanayan upang makuha ang mga karagdagang katangian. 1231 00:53:48,327 --> 00:53:50,660 Maaari ko bang project ang mga karagdagang katangian sa talahanayan 1232 00:53:50,660 --> 00:53:53,440 upang suportahan ang access pattern. 1233 00:53:53,440 --> 00:53:57,700 Alam ko marahil kami ay pagkuha sa ilang talaga, really-- pagkuha sa mga damo 1234 00:53:57,700 --> 00:53:58,910 dito sa ilan sa mga bagay-bagay na ito. 1235 00:53:58,910 --> 00:54:02,725 Ngayon Nakatanggap ako sa naaanod na out ng mga ito. 1236 00:54:02,725 --> 00:54:07,320 >> Madla: [hindi marinig] --table key sinadya ay isang hash? 1237 00:54:07,320 --> 00:54:08,840 Ang orihinal na hash? 1238 00:54:08,840 --> 00:54:09,340 Multi-slats? 1239 00:54:09,340 --> 00:54:10,200 >> RICK Houlihan Oo. 1240 00:54:10,200 --> 00:54:11,070 Oo. 1241 00:54:11,070 --> 00:54:15,260 Ang mga pangunahing talahanayan talaga puntos pabalik sa mga item. 1242 00:54:15,260 --> 00:54:19,280 Kaya isang index ay isang pointer pabalik sa mga orihinal na item sa talahanayan. 1243 00:54:19,280 --> 00:54:22,910 Ngayon ay maaari kang pumili upang bumuo ng isang index na may table na key lamang, 1244 00:54:22,910 --> 00:54:24,840 at walang iba pang mga katangian. 1245 00:54:24,840 --> 00:54:26,570 At bakit maaari ko na? 1246 00:54:26,570 --> 00:54:28,570 Well, siguro mayroon akong napakalaking item. 1247 00:54:28,570 --> 00:54:31,660 >> Ko talagang lamang ang kailangan upang malaman which-- Maaaring sabihin ng aking mga pattern access, 1248 00:54:31,660 --> 00:54:33,760 kung aling mga item na naglalaman ng mga ari-arian na ito? 1249 00:54:33,760 --> 00:54:35,780 Huwag kailangan upang bumalik ang mga item. 1250 00:54:35,780 --> 00:54:37,800 Kailangan ko lang malaman kung aling mga item na naglalaman ng mga ito. 1251 00:54:37,800 --> 00:54:40,700 Kaya maaari kang bumuo ng index na mayroon lamang sa talahanayan key. 1252 00:54:40,700 --> 00:54:43,360 >> Ngunit iyon lamang ang una kung ano isang index sa database ay para sa. 1253 00:54:43,360 --> 00:54:46,280 Ito ay para sa pagiging magagawang upang mabilis na makilala na talaan, 1254 00:54:46,280 --> 00:54:49,470 na mga hilera, kung saan item sa talahanayan ay may 1255 00:54:49,470 --> 00:54:51,080 ang mga katangian na ako na naghahanap para sa. 1256 00:54:51,080 --> 00:54:53,610 1257 00:54:53,610 --> 00:54:54,860 >> GSIS, kaya kung paano gumagana ang mga ito? 1258 00:54:54,860 --> 00:54:58,340 GSIS talaga ay asynchronous. 1259 00:54:58,340 --> 00:55:02,570 Update lumapit sa table, mesa ay pagkatapos asynchronously update 1260 00:55:02,570 --> 00:55:03,720 ang lahat ng iyong GSIS. 1261 00:55:03,720 --> 00:55:06,680 Ito ay kung bakit GSIS ay huli pare-pareho. 1262 00:55:06,680 --> 00:55:09,440 >> Ito ay mahalaga na tandaan na ang kapag ikaw ay gusali GSIS, 1263 00:55:09,440 --> 00:55:13,110 at nauunawaan mo ikaw ay lumilikha ng isa pang dimensyon ng aggregation-- 1264 00:55:13,110 --> 00:55:16,594 ngayon sabihin natin ng magandang halimbawa dito ay isang tagagawa. 1265 00:55:16,594 --> 00:55:19,260 Sa tingin ko ay maaaring magkaroon ng usapan ko ang tungkol isang tagagawa ng medikal na aparato. 1266 00:55:19,260 --> 00:55:23,870 Tagagawa Medikal na aparato malimit may serialized bahagi. 1267 00:55:23,870 --> 00:55:28,070 Ang mga bahagi na pumunta sa isang hip kapalit lahat 1268 00:55:28,070 --> 00:55:30,200 magkaroon ng isang maliit na serial number sa mga ito. 1269 00:55:30,200 --> 00:55:33,584 At maaari silang magkaroon ng milyun-milyon at milyon-milyong at bilyon-bilyong mga bahagi 1270 00:55:33,584 --> 00:55:35,000 sa lahat ng mga lalang na kanilang barko. 1271 00:55:35,000 --> 00:55:37,440 Well, kailangan nila upang pagsama-samahin sa ilalim iba't-ibang mga sukat, ang lahat ng mga bahagi 1272 00:55:37,440 --> 00:55:39,520 sa isang pagpupulong, ang lahat ng mga bahagi na ang ginawa 1273 00:55:39,520 --> 00:55:41,670 sa isang tiyak na linya, ang lahat ang mga bahagi na dumating 1274 00:55:41,670 --> 00:55:44,620 in mula sa isang tiyak na tagagawa sa isang tiyak na petsa. 1275 00:55:44,620 --> 00:55:47,940 At ang mga ito aggregations minsan makakuha ng hanggang sa bilyon-bilyong. 1276 00:55:47,940 --> 00:55:50,550 >> Kaya ako ng trabaho sa ilan sa mga mga guys na paghihirap 1277 00:55:50,550 --> 00:55:53,156 dahil ang mga ito ay ang paglikha ng mga Ginormous aggregations 1278 00:55:53,156 --> 00:55:54,280 sa kanilang pangalawang index. 1279 00:55:54,280 --> 00:55:57,070 Sila ay maaaring magkaroon ng isang raw na bahagi mesa na dumating bilang hash lamang. 1280 00:55:57,070 --> 00:55:59,090 Ang bawat bahagi ay may isang natatanging serial number. 1281 00:55:59,090 --> 00:56:00,975 Gamitin ko ang mga serial number ng mga hash. 1282 00:56:00,975 --> 00:56:01,600 Ang ganda. 1283 00:56:01,600 --> 00:56:04,160 Mesa My raw data ay kumalat lahat sa buong key space. 1284 00:56:04,160 --> 00:56:05,930 Aking [? isulat?] [? paglunok?] ay kahanga-hangang. 1285 00:56:05,930 --> 00:56:07,876 Kumuha ako ng maraming data. 1286 00:56:07,876 --> 00:56:09,500 Pagkatapos ay kung ano ang ginagawa nila ay silang lumikha ng isang GSI. 1287 00:56:09,500 --> 00:56:12,666 At sinasabi ko, alam mo kung ano, kailangan ko na makita lahat ng mga bahagi para sa tagagawa. 1288 00:56:12,666 --> 00:56:15,060 Well, ang lahat ng isang biglaang ako pagkuha ng isang bilyong mga hilera, 1289 00:56:15,060 --> 00:56:17,550 at bagay-bagay ang mga ito papunta isa node, dahil kapag 1290 00:56:17,550 --> 00:56:21,170 Pinagsasama-sama ko na rin ang ID tagagawa bilang ang hash, 1291 00:56:21,170 --> 00:56:25,410 at part number bilang ng hanay, at pagkatapos ang lahat ng mga biglaang ako 1292 00:56:25,410 --> 00:56:30,530 paglalagay ng isang bilyong mga bahagi sa kung ano ang tagagawa na ito ay inihatid sa akin. 1293 00:56:30,530 --> 00:56:34,447 >> Iyon ay maaaring maging sanhi ng maraming ng presyon sa GSI, 1294 00:56:34,447 --> 00:56:36,030 muli, dahil ako pagmamartilyo isa node. 1295 00:56:36,030 --> 00:56:38,350 Ako ng paglalagay ng lahat ng mga pagsingit sa isang node. 1296 00:56:38,350 --> 00:56:40,940 At iyon ay isang tunay na problema na gamitin ang kaso. 1297 00:56:40,940 --> 00:56:43,479 Ngayon, nakakuha ako ng magandang disenyo pattern para sa kung paano mo maiwasan na. 1298 00:56:43,479 --> 00:56:45,770 At iyon ang isa sa mga problema na ako palaging gumagana sa. 1299 00:56:45,770 --> 00:56:49,590 Ngunit ano ang mangyayari, ay ang GSI maaaring walang sapat na kapasidad write 1300 00:56:49,590 --> 00:56:52,330 para ma-itulak ang lahat ng mga mga hilera sa isang solong node. 1301 00:56:52,330 --> 00:56:55,390 At ano ang mangyayari pagkatapos ay ang primary, ang mga talahanayan client, 1302 00:56:55,390 --> 00:57:00,180 ang pangunahing talahanayan ay throttled dahil ang GSI ay hindi maaaring panatilihin up. 1303 00:57:00,180 --> 00:57:02,980 Kaya ang aking insert rate ay tumama ang pangunahing talahanayan 1304 00:57:02,980 --> 00:57:06,230 bilang aking GSI sumusubok na panatilihin up. 1305 00:57:06,230 --> 00:57:08,850 >> Lahat ng karapatan, kaya GSI ni, LSI, ang kung saan ang isa ay dapat kong gamitin? 1306 00:57:08,850 --> 00:57:12,290 LSI ni ay pare-pareho. 1307 00:57:12,290 --> 00:57:13,750 GSI ni ay pare-pareho sa huli. 1308 00:57:13,750 --> 00:57:17,490 Kung iyon ang OK, inirerekumenda ko ang paggamit ng isang GSI, ang mga ito ay mas may kakayahang umangkop. 1309 00:57:17,490 --> 00:57:20,270 LSI ay maaaring ma-imo-modelo bilang GSI. 1310 00:57:20,270 --> 00:57:27,040 At kung ang laki ng data sa bawat hash key in lumampas ang iyong koleksyon ng 10 gigabytes, 1311 00:57:27,040 --> 00:57:31,050 pagkatapos ikaw ay pagpunta sa nais na gumamit na GSI dahil ito lamang ay isang mahirap na limitasyon. 1312 00:57:31,050 --> 00:57:32,035 >> Lahat ng karapatan, kaya scaling. 1313 00:57:32,035 --> 00:57:35,210 1314 00:57:35,210 --> 00:57:37,460 Throughput sa Dynamo DB, ikaw lata pagkakaloob [hindi marinig] 1315 00:57:37,460 --> 00:57:38,680 throughput sa isang table. 1316 00:57:38,680 --> 00:57:42,740 Mayroon kaming mga customer na magkaroon ng provision 60 billion-- 1317 00:57:42,740 --> 00:57:45,970 ginagawa 60 bilyon na mga kahilingan, regular tumatakbo sa loob ng isang milyong mga kahilingan 1318 00:57:45,970 --> 00:57:47,790 bawat segundo sa aming mga talahanayan. 1319 00:57:47,790 --> 00:57:50,360 Mayroon talagang hindi panteorya limitasyon sa kung magkano 1320 00:57:50,360 --> 00:57:53,730 at kung gaano kabilis ang mga talahanayan maaaring tumakbo sa Dynamo DB. 1321 00:57:53,730 --> 00:57:55,920 May ilang mga soft mga limitasyon sa iyong account 1322 00:57:55,920 --> 00:57:58,170 na inilalagay namin sa may kaya na hindi mo na mabaliw. 1323 00:57:58,170 --> 00:58:00,070 Kung nais mo ng higit sa na iyon, hindi isang problema. 1324 00:58:00,070 --> 00:58:00,820 Dumating ka sabihin sa amin. 1325 00:58:00,820 --> 00:58:02,810 Makikita i-up kami ng dial. 1326 00:58:02,810 --> 00:58:08,210 >> Ang bawat account ay limitado sa ilang mga antas sa bawat serbisyo, i-off ang bat 1327 00:58:08,210 --> 00:58:11,920 kaya ang mga tao ay hindi mabaliw makakuha ng kanilang sarili sa problema. 1328 00:58:11,920 --> 00:58:12,840 Walang limitasyon sa laki. 1329 00:58:12,840 --> 00:58:14,940 Maaari mong ilagay ang anumang bilang ng mga bagay sa isang table. 1330 00:58:14,940 --> 00:58:17,620 Ang laki ng isang item ay limitado sa 400 kilobytes bawat isa, 1331 00:58:17,620 --> 00:58:20,050 na magiging item hindi ang mga katangian. 1332 00:58:20,050 --> 00:58:24,200 Kaya ang kabuuan ng lahat ng mga katangian ay limitado sa 400 kilobytes. 1333 00:58:24,200 --> 00:58:27,300 At pagkatapos ay muli, kami ay na maliit LSI isyu 1334 00:58:27,300 --> 00:58:30,405 may limit 10 gigabyte per hash. 1335 00:58:30,405 --> 00:58:33,280 Madla: Small number, ako nawawala kung ano ang sinasabi mo sa akin, na is-- 1336 00:58:33,280 --> 00:58:36,830 Madla: Oh, 400 kilobyte ay ang pinakamataas na sukat ng bawat item. 1337 00:58:36,830 --> 00:58:39,570 Kaya ito ay may lahat ng mga katangian ng isang item. 1338 00:58:39,570 --> 00:58:43,950 Kaya 400 k ay ang kabuuang sukat ng bagay na iyon, 400 kilobytes. 1339 00:58:43,950 --> 00:58:46,170 Kaya sa lahat ng katangian pinagsama, ang lahat ng mga data 1340 00:58:46,170 --> 00:58:49,140 na sa lahat ng mga katangian, pinagsama sa isang kabuuang sukat, 1341 00:58:49,140 --> 00:58:51,140 kasalukuyang ngayon ang limitasyon item ay 400 k. 1342 00:58:51,140 --> 00:58:54,390 1343 00:58:54,390 --> 00:58:57,046 Kaya pagsusukat muli, nakakamit sa pamamagitan ng pag-partisyon. 1344 00:58:57,046 --> 00:58:58,920 Throughput napaglaanan sa antas ng table. 1345 00:58:58,920 --> 00:59:00,160 At mayroon talagang dalawang knobs. 1346 00:59:00,160 --> 00:59:02,400 Kami ay basahin ang kapasidad at isulat ang kapasidad. 1347 00:59:02,400 --> 00:59:05,530 >> Kaya ang mga ito ay naaakma malaya ng bawat isa. 1348 00:59:05,530 --> 00:59:08,640 Ang panukalang-batas RCU ni mahigpit na pare-pareho na nagbabasa. 1349 00:59:08,640 --> 00:59:13,005 OK, kaya kung ikaw ay sinasabi na gusto ko 1,000 RCU ni ang mga ito ay mahigpit na pare-pareho, 1350 00:59:13,005 --> 00:59:14,130 ang mga ito ay pare-pareho na nagbabasa. 1351 00:59:14,130 --> 00:59:17,130 Kung sinasabi mo na gusto ko wakas pare-pareho nagbabasa, 1352 00:59:17,130 --> 00:59:19,402 Maaari mong pagkakaloob 1,000 RCU ni, ikaw ay pagpunta 1353 00:59:19,402 --> 00:59:21,840 upang makakuha ng 2,000 huli pare-pareho bumabasa. 1354 00:59:21,840 --> 00:59:25,940 At kalahati ang presyo para sa mga kalaunan ay binubuo sa nagbabasa. 1355 00:59:25,940 --> 00:59:28,520 >> Muli, nababagay malaya ng bawat isa. 1356 00:59:28,520 --> 00:59:32,900 At sila ay may mga throughput-- Kung ubusin mo ang 100% ng iyong RCU, 1357 00:59:32,900 --> 00:59:35,960 hindi ka pagpunta sa epekto sa availability ng iyong mga karapatan. 1358 00:59:35,960 --> 00:59:40,161 Kaya ang mga ito ay ganap na independiyenteng ng bawat isa. 1359 00:59:40,161 --> 00:59:43,160 Lahat ng karapatan, kaya isa sa mga bagay na Nabanggit ko sa madaling sabi ay Throttling. 1360 00:59:43,160 --> 00:59:44,320 Throttling ay masama. 1361 00:59:44,320 --> 00:59:47,311 Throttling nagpapahiwatig masamang walang SQL. 1362 00:59:47,311 --> 00:59:50,310 May mga bagay na maaari naming gawin upang matulungan mong magpakalma ang Throttling na kayo 1363 00:59:50,310 --> 00:59:51,040 nararanasan. 1364 00:59:51,040 --> 00:59:53,240 Ngunit ang pinakamahusay na solusyon na ito ay ipaalam sa tumagal ng 1365 00:59:53,240 --> 00:59:58,000 isang pagtingin sa kung ano ang iyong ginagawa, dahil mayroong isang anti-pattern sa pag-play dito. 1366 00:59:58,000 --> 01:00:02,140 >> Ang mga bagay, ang mga bagay tulad ng mga di-unipormeng workloads, hot keys, hot partisyon. 1367 01:00:02,140 --> 01:00:06,210 Ako pagpindot sa isang partikular na space key napakahirap para sa ilang partikular na dahilan. 1368 01:00:06,210 --> 01:00:07,080 Bakit ako ginagawa ito? 1369 01:00:07,080 --> 01:00:08,710 Sabihin malaman na natin. 1370 01:00:08,710 --> 01:00:10,427 Ako paghahalo aking mainit na data na may malamig na data. 1371 01:00:10,427 --> 01:00:12,510 Ako pagpapaalam sa aking mga talahanayan makakakuha napakalaking, ngunit may tunay 1372 01:00:12,510 --> 01:00:15,970 lamang ng ilang mga subset ng data iyan ay talagang kawili-wili sa akin. 1373 01:00:15,970 --> 01:00:20,290 Kaya para sa data ng log, halimbawa, ng maraming mga customer, sila ay kumuha ng data mag-log sa bawat araw. 1374 01:00:20,290 --> 01:00:22,490 Nakuha nila ang isang malaking halaga ng data ng log. 1375 01:00:22,490 --> 01:00:25,940 >> Kung naka-paglalaglag lamang ang lahat ng log na data sa isang malaking table, sa paglipas ng panahon 1376 01:00:25,940 --> 01:00:28,070 mesa na pagpunta upang makakuha ng malaki at mabigat. 1377 01:00:28,070 --> 01:00:30,950 Ngunit ako ay talagang lamang na interesado sa huling 24 na oras, sa nakaraang pitong araw, 1378 01:00:30,950 --> 01:00:31,659 sa huling 30 araw. 1379 01:00:31,659 --> 01:00:34,074 Anuman ang window ng oras na ako interesado sa mga naghahanap 1380 01:00:34,074 --> 01:00:37,010 para sa kaganapan na bothers sa akin, o ang kaganapan na kawili-wili sa akin, 1381 01:00:37,010 --> 01:00:39,540 na ang tanging oras window na kailangan ko. 1382 01:00:39,540 --> 01:00:42,470 Kaya bakit ako ng paglagay ng 10 taon nagkakahalaga ng data ng log sa talahanayan? 1383 01:00:42,470 --> 01:00:45,030 Ano na nagiging sanhi ay talahanayan ng mga fragment. 1384 01:00:45,030 --> 01:00:45,880 >> Malaking Ito ay makakakuha. 1385 01:00:45,880 --> 01:00:48,340 Ito ay nagsisimula sa pagkalat out kabuuan libu-libong mga nodes. 1386 01:00:48,340 --> 01:00:51,380 At dahil ang iyong kapasidad ay kaya mababa, ikaw ay 1387 01:00:51,380 --> 01:00:54,090 talagang rate takda sa bawat isa sa mga indibidwal na nodes. 1388 01:00:54,090 --> 01:00:57,120 Kaya natin simulan ang pagtingin sa kung paano ipaalam gawin namin gumulong table na over. 1389 01:00:57,120 --> 01:01:01,502 Paano namin pamahalaan ang data na iyon sa isang maliit na mas mahusay na upang maiwasan ang mga problemang ito. 1390 01:01:01,502 --> 01:01:02,710 At kung ano na ang hitsura? 1391 01:01:02,710 --> 01:01:04,370 Ito ay kung ano na kamukha. 1392 01:01:04,370 --> 01:01:06,790 Ito ay kung ano ang hitsura masamang NoSQL gusto. 1393 01:01:06,790 --> 01:01:07,830 >> Nakakuha ako ng isang hot key dito. 1394 01:01:07,830 --> 01:01:10,246 Kung tumingin ka sa gilid dito, ang mga ito ay ang lahat ng aking mga partisyon. 1395 01:01:10,246 --> 01:01:12,630 Nakakuha ako ng 16 partisyon up dito sa partikular na database. 1396 01:01:12,630 --> 01:01:13,630 Ginagawa namin ito sa lahat ng oras. 1397 01:01:13,630 --> 01:01:15,046 Tumakbo ko ito para sa mga customer sa lahat ng oras. 1398 01:01:15,046 --> 01:01:16,550 Ito ay tinatawag na ang heat map. 1399 01:01:16,550 --> 01:01:20,590 Sinasabi sa akin Heat mapa kung paano ikaw ay pag-access ng iyong mga susi space. 1400 01:01:20,590 --> 01:01:23,700 At kung ano ito ay nagsasabi sa akin ay na mayroong isang partikular na hash 1401 01:01:23,700 --> 01:01:26,330 na ang tao ang may gusto ng isang kakila-kilabot maraming, dahil siya ang 1402 01:01:26,330 --> 01:01:28,250 pagpindot ito talaga, talagang mahirap. 1403 01:01:28,250 --> 01:01:29,260 >> Kaya ang asul ay nice. 1404 01:01:29,260 --> 01:01:29,900 Gusto naming asul. 1405 01:01:29,900 --> 01:01:30,720 Hindi namin gusto ang red. 1406 01:01:30,720 --> 01:01:33,120 Red kung saan ang presyon ay makakakuha ng hanggang sa 100%. 1407 01:01:33,120 --> 01:01:35,560 100%, na ngayon ang iyong pagpunta sa throttled. 1408 01:01:35,560 --> 01:01:39,030 Kaya kapag nakita mo ang anumang mga pulang linya tulad ng this-- at ito ay hindi lamang Dynamo DB-- 1409 01:01:39,030 --> 01:01:41,630 bawat NoSQL database ay may problemang ito. 1410 01:01:41,630 --> 01:01:44,640 May mga anti-pattern na maaari himukin ang mga uri ng mga kondisyon. 1411 01:01:44,640 --> 01:01:49,070 Ano ang gagawin ko ay ako ng trabaho sa mga customer upang magpakalma ang mga kondisyon. 1412 01:01:49,070 --> 01:01:51,840 >> At kung ano na ang hitsura? 1413 01:01:51,840 --> 01:01:54,260 At ito ay ang pagkuha ng pinaka out of Dynamo DB throughput, 1414 01:01:54,260 --> 01:01:56,176 ngunit ang talagang nakakakuha ito ng ang pinaka-out ng NoSQL. 1415 01:01:56,176 --> 01:01:58,740 Ito ay hindi limitado sa Dynamo. 1416 01:01:58,740 --> 01:02:02,050 Ito ang definitely-- ko ginagamit sa trabaho sa Mongo. 1417 01:02:02,050 --> 01:02:04,090 Ako ay pamilyar sa maraming mga NoSQL platform. 1418 01:02:04,090 --> 01:02:06,830 Bawat isa ay may ganitong mga uri ng hot key problema. 1419 01:02:06,830 --> 01:02:10,320 Upang makuha ang pinaka-out ng anumang NoSQL database, partikular Dynamo DB, 1420 01:02:10,320 --> 01:02:13,320 na nais mong lumikha ng mga talahanayan kung saan ang mga elemento hash key ay 1421 01:02:13,320 --> 01:02:18,590 isang malaking bilang ng natatanging mga halaga, isang mataas na antas ng cardinality. 1422 01:02:18,590 --> 01:02:22,530 Dahil nangangahulugan na ako ng sulat sa maraming iba't-ibang mga bucket. 1423 01:02:22,530 --> 01:02:24,870 >> Ang mas maraming mga bucket Ako pagsulat sa, mas malamang na 1424 01:02:24,870 --> 01:02:29,100 Ako na kumalat na ang load write o basahin load out sa maramihang nodes, 1425 01:02:29,100 --> 01:02:33,560 mas malamang na ako na magkaroon ng isang mataas na throughput sa mesa. 1426 01:02:33,560 --> 01:02:37,440 At pagkatapos ay gusto ko ang mga halaga na maging hiniling na medyo pantay-pantay sa paglipas ng panahon 1427 01:02:37,440 --> 01:02:39,430 at pantay na random na panahon. 1428 01:02:39,430 --> 01:02:42,410 Well, na ang uri ng kawili-wili, dahil hindi ko makakaya talaga 1429 01:02:42,410 --> 01:02:43,960 control kapag dumating ang mga gumagamit. 1430 01:02:43,960 --> 01:02:47,645 Kaya makasapat upang sabihin, kung ikakalat namin out ng mga bagay sa kabuuan ng key na espasyo, 1431 01:02:47,645 --> 01:02:49,270 kami ay malamang na maging mas mahusay na hugis. 1432 01:02:49,270 --> 01:02:51,522 >> May isang tiyak na halaga ng oras na paghahatid 1433 01:02:51,522 --> 01:02:53,230 na hindi ka pagpunta para ma control. 1434 01:02:53,230 --> 01:02:55,438 Ngunit ang mga ay talagang ang dalawang sukat na mayroon kami, 1435 01:02:55,438 --> 01:02:58,800 space, access pantay-pantay spread, oras, mga kahilingan 1436 01:02:58,800 --> 01:03:01,040 ang pagdating pantay-pantay spaced sa oras. 1437 01:03:01,040 --> 01:03:03,110 At kung ang mga dalawang kondisyon ay natutugunan, 1438 01:03:03,110 --> 01:03:05,610 pagkatapos na kung ano ito ay pagpunta sa hitsura. 1439 01:03:05,610 --> 01:03:07,890 Ito ay marami nicer. 1440 01:03:07,890 --> 01:03:08,890 Kami ay talagang masaya dito. 1441 01:03:08,890 --> 01:03:10,432 Nakakuha kami ng isang napaka-kahit na pattern access. 1442 01:03:10,432 --> 01:03:13,098 Oo, siguro makakakuha ka ng isang maliit na presyon bawat ngayon at pagkatapos, 1443 01:03:13,098 --> 01:03:14,830 ngunit wala talagang masyadong malawak. 1444 01:03:14,830 --> 01:03:17,660 Kaya ito ay amazing kung gaano karaming beses, kapag ako ng trabaho sa mga customer, 1445 01:03:17,660 --> 01:03:20,670 na ang unang graph na may malaking red bar at ang lahat na pangit yellow ito ay 1446 01:03:20,670 --> 01:03:23,147 lahat ng dako ng lugar, tayo makakuha ng tapos na may mga exercise 1447 01:03:23,147 --> 01:03:24,980 pagkatapos ng isang pares ng mga buwan ng re-architecture, 1448 01:03:24,980 --> 01:03:28,050 sila ay nagpapatakbo ng parehong workload sa eksaktong parehong load. 1449 01:03:28,050 --> 01:03:30,140 At ito ay kung ano ito ay naghahanap tulad ngayon. 1450 01:03:30,140 --> 01:03:36,600 Kaya kung ano ang makukuha mo sa NoSQL ay isang schema data na ay ganap na 1451 01:03:36,600 --> 01:03:38,510 nakatali sa access pattern. 1452 01:03:38,510 --> 01:03:42,170 >> At maaari mong i-optimize na schema data upang suportahan ang ganoong access pattern. 1453 01:03:42,170 --> 01:03:45,490 Kung hindi mo nagawa, pagkatapos ikaw ay pagpunta upang makita ang mga uri ng mga problema 1454 01:03:45,490 --> 01:03:46,710 may mga hot keys. 1455 01:03:46,710 --> 01:03:50,518 >> Madla: Well, hindi maaaring hindi ilang mga lugar ay magiging mas mainit kaysa sa iba. 1456 01:03:50,518 --> 01:03:51,450 >> RICK Houlihan: Laging. 1457 01:03:51,450 --> 01:03:51,960 Laging. 1458 01:03:51,960 --> 01:03:54,620 Oo, ang ibig sabihin ko may laging a-- at muli, may 1459 01:03:54,620 --> 01:03:56,980 ang ilang mga pattern na disenyo babalikan ka namin sa pamamagitan ng na makipag-usap tungkol sa kung paano makitungo sa iyo 1460 01:03:56,980 --> 01:03:58,480 sa mga sobrang malalaking pagsasama-sama. 1461 01:03:58,480 --> 01:04:01,260 Ibig sabihin ko, nakuha ko na magkaroon ng mga ito, paano namin pakikitungo sa kanila? 1462 01:04:01,260 --> 01:04:03,760 Nakakuha ako ng isang magandang magandang pagkakataon ng paggamit na makikita usapan namin para doon. 1463 01:04:03,760 --> 01:04:05,940 >> Lahat ng karapatan, kaya sabihin talk tungkol sa ilang mga customer ngayon. 1464 01:04:05,940 --> 01:04:06,950 Ang mga guys ay AdRoll. 1465 01:04:06,950 --> 01:04:08,990 Hindi ko alam kung ikaw ay pamilyar sa AdRoll. 1466 01:04:08,990 --> 01:04:10,781 Ikaw ay malamang na makita ang mga ito isang pulutong sa browser. 1467 01:04:10,781 --> 01:04:14,230 Sila ad muling pagta-target, ang mga ito ang pinakamalaking business ad re-targeting 1468 01:04:14,230 --> 01:04:14,940 doon. 1469 01:04:14,940 --> 01:04:17,792 Sila ay karaniwang regular na magpatakbo ng higit sa 60 bilyong mga transaksyon sa bawat araw. 1470 01:04:17,792 --> 01:04:20,000 Sila ay gumagawa ng higit sa isang milyong mga transaksyon sa bawat segundo. 1471 01:04:20,000 --> 01:04:22,660 Sila na nakuha ng isang medyo simpleng mesa istraktura, ang pinaka-abalang table. 1472 01:04:22,660 --> 01:04:26,450 Ito ay karaniwang lamang ng isang hash key ay ang cookie, 1473 01:04:26,450 --> 01:04:29,010 ang hanay ay ang demographic kategorya, at pagkatapos ay 1474 01:04:29,010 --> 01:04:31,220 ang ikatlong katangian ay ang marka. 1475 01:04:31,220 --> 01:04:33,720 >> Kaya namin ang lahat ng mga cookies sa ang aming browser mula sa mga guys. 1476 01:04:33,720 --> 01:04:35,900 At kapag ikaw ay pupunta sa isang kalahok na merchant, 1477 01:04:35,900 --> 01:04:39,390 sila talaga ang puntos mo sa kabuuan iba't-ibang mga demographic na mga kategorya. 1478 01:04:39,390 --> 01:04:42,070 Kapag pumunta ka sa isang website at sinasabi mo na gusto kong makita ang ad-- 1479 01:04:42,070 --> 01:04:44,920 o talaga hindi mo sasabihin na- ngunit kapag ikaw ay pumunta sa website 1480 01:04:44,920 --> 01:04:47,550 sinasabi nila na gusto mong makita ang ad na ito. 1481 01:04:47,550 --> 01:04:49,370 At pumunta sila makakuha na ad mula AdRoll. 1482 01:04:49,370 --> 01:04:51,130 Mukhang mong AdRoll up sa kanilang mga mesa. 1483 01:04:51,130 --> 01:04:52,115 Sila mahanap ang iyong mga cookie. 1484 01:04:52,115 --> 01:04:53,990 Ang mga advertiser na nagsasabi , gusto ko ang mga ito ng isang tao 1485 01:04:53,990 --> 01:04:58,632 sino ang nasa katanghaliang-gulang, 40-taon gulang na tao, sa sports. 1486 01:04:58,632 --> 01:05:01,590 At ang puntos mo sila sa mga demographics at magpasya kung o hindi sila 1487 01:05:01,590 --> 01:05:02,740 iyan ay isang magandang ad para sa iyo. 1488 01:05:02,740 --> 01:05:10,330 >> Ngayon ay mayroon sila ng isang SLA sa kanilang mga nagbibigay ng advertising 1489 01:05:10,330 --> 01:05:14,510 upang magbigay ng sub-10 millisecond Bilang tugon sa bawat solong kahilingan. 1490 01:05:14,510 --> 01:05:16,090 Kaya sila ay gumagamit ng Dynamo DB para sa mga ito. 1491 01:05:16,090 --> 01:05:18,131 Sila ay pagpindot sa amin ng isang milyong mga kahilingan sa bawat segundo. 1492 01:05:18,131 --> 01:05:21,120 Ang mga ito ay maaaring gawin ang lahat ng kanilang mga lookups, triage ang lahat ng data na iyon, 1493 01:05:21,120 --> 01:05:26,130 at kumuha na link add bumalik sa na advertiser sa ilalim ng 10 milliseconds. 1494 01:05:26,130 --> 01:05:29,800 Ito ay talagang pretty kahanga-hanga pagpapatupad na mayroon sila. 1495 01:05:29,800 --> 01:05:36,210 >> Ang mga guys actually-- ay ang mga ito sa mga guys. 1496 01:05:36,210 --> 01:05:38,010 Hindi ako sigurado kung ito ay ang mga guys. 1497 01:05:38,010 --> 01:05:40,127 Maaaring maging ang mga guys. 1498 01:05:40,127 --> 01:05:42,210 Talaga sinabi us-- no, ako hindi nag-iisip na ito ay ang mga ito. 1499 01:05:42,210 --> 01:05:43,000 Sa tingin ko ito ay may ibang tao. 1500 01:05:43,000 --> 01:05:44,750 Ako ay nagtatrabaho sa isang customer na sinabi sa akin 1501 01:05:44,750 --> 01:05:47,040 na ngayon na sila na wala na sa Dynamo DB, ang mga ito ay 1502 01:05:47,040 --> 01:05:50,330 higit pa sa paggastos ng pera sa mga meryenda para sa ang kanilang mga koponan sa pag-unlad ng bawat buwan 1503 01:05:50,330 --> 01:05:52,886 kaysa sa gastusin nila sa kanilang database. 1504 01:05:52,886 --> 01:05:54,760 Kaya ito ay magbibigay sa iyo ng isang ideya ng mga pagtitipid ng gastos 1505 01:05:54,760 --> 01:05:57,889 na maaari mong makuha sa Dynamo DB ay malaking. 1506 01:05:57,889 --> 01:05:59,430 Lahat ng karapatan, dropcam ang isa pang kumpanya. 1507 01:05:59,430 --> 01:06:02,138 Ang mga tao ay uri of-- kung sa tingin mo ng internet ng mga bagay, dropcam 1508 01:06:02,138 --> 01:06:05,150 ay talaga internet security video. 1509 01:06:05,150 --> 01:06:06,660 Mong ilagay ang iyong camera out doon. 1510 01:06:06,660 --> 01:06:08,180 Camera ay may motion detector. 1511 01:06:08,180 --> 01:06:10,290 May isang tao ay kasama, trigger ng isang cue point. 1512 01:06:10,290 --> 01:06:13,540 Nagsisimula Camera record para sa isang habang hanggang ito ay hindi nakakita ng anumang paggalaw anymore. 1513 01:06:13,540 --> 01:06:15,310 Naglalagay ng video na hanggang sa internet. 1514 01:06:15,310 --> 01:06:19,800 >> Dropcam ay isang kumpanya na ay talaga inililipat sa Dynamo DB 1515 01:06:19,800 --> 01:06:22,200 dahil sila ay nakakaranas napakalaking lumalaki ng panganganak. 1516 01:06:22,200 --> 01:06:25,820 At kung ano ang sinabi nila sa amin, biglang petabytes ng data. 1517 01:06:25,820 --> 01:06:28,070 Sila ay walang mga ideya sa kanilang serbisyo ay magiging matagumpay. 1518 01:06:28,070 --> 01:06:32,310 Iba pa dumarating video sa YouTube ay kung ano ang mga guys ay pagkuha. 1519 01:06:32,310 --> 01:06:36,780 Ginagamit nila DynamoDB upang subaybayan ang lahat ng mga metadata sa lahat ng kanilang mga video key points. 1520 01:06:36,780 --> 01:06:40,282 >> Kaya sila S3 buckets sila itulak lahat ng mga binary artifacts sa. 1521 01:06:40,282 --> 01:06:41,990 At pagkatapos ay mayroon sila Dynamo DB talaan na 1522 01:06:41,990 --> 01:06:44,070 punto ng mga tao sa mga S3 tatlong bagay. 1523 01:06:44,070 --> 01:06:47,070 Kapag kailangan nila upang tumingin sa isang video, maghanap sila ng record sa Dynamo DB. 1524 01:06:47,070 --> 01:06:47,903 Sila-click ang link. 1525 01:06:47,903 --> 01:06:49,770 Sila pull down ang video mula sa S3. 1526 01:06:49,770 --> 01:06:51,590 Kaya na uri ng kung ano ito ay ganito ang hitsura. 1527 01:06:51,590 --> 01:06:53,580 At ito ay tuwid mula sa kanilang team. 1528 01:06:53,580 --> 01:06:56,010 >> Dynamo DB binabawasan ang kanilang paghahatid ng oras para sa mga kaganapan na video 1529 01:06:56,010 --> 01:06:57,590 mula sa lima hanggang 10 segundo. 1530 01:06:57,590 --> 01:07:00,470 Sa kanilang lumang store relational, ginagamit ang mga ito upang magkaroon ng upang pumunta at isakatuparan 1531 01:07:00,470 --> 01:07:03,780 maramihang mga kumplikadong mga query sa figure kung aling mga video sa pull down, 1532 01:07:03,780 --> 01:07:06,690 sa mas mababa sa 50 milliseconds. 1533 01:07:06,690 --> 01:07:08,990 Kaya ito ay amazing, amazing kung magkano ang pagganap 1534 01:07:08,990 --> 01:07:12,990 maaari kang makakuha ng kapag na-optimize at sa iyo na ibagay ang kalakip na database 1535 01:07:12,990 --> 01:07:15,110 upang suportahan ang access pattern. 1536 01:07:15,110 --> 01:07:20,500 Halfbrick, ang mga guys, kung ano ang mga ito, Fruit Ninja Hulaan ko ay ang kanilang mga bagay. 1537 01:07:20,500 --> 01:07:22,590 Na ang lahat ay tumatakbo sa Dynamo DB. 1538 01:07:22,590 --> 01:07:26,810 At ang mga lalaki, ang mga ito ay isang mahusay na unlad ng koponan, mahusay na pag-unlad 1539 01:07:26,810 --> 01:07:27,670 shop. 1540 01:07:27,670 --> 01:07:29,364 >> Hindi isang magandang team ops. 1541 01:07:29,364 --> 01:07:31,280 Hindi nila ay may isang pulutong ng mga mapagkukunan ng operasyon. 1542 01:07:31,280 --> 01:07:33,940 Sila ay nahihirapan sinusubukan na panatilihin kanilang imprastraktura up application 1543 01:07:33,940 --> 01:07:34,290 at tumatakbo. 1544 01:07:34,290 --> 01:07:35,000 Sila ay dumating sa amin. 1545 01:07:35,000 --> 01:07:36,251 Sila ay tumingin sa na Dynamo DB. 1546 01:07:36,251 --> 01:07:37,291 Sinabi nila, na para sa amin. 1547 01:07:37,291 --> 01:07:39,470 Binuo nila ang kanilang buong application framework sa mga ito. 1548 01:07:39,470 --> 01:07:43,640 Ang ilang mga talagang maganda ang mga komento dito mula sa koponan sa kanilang kakayahan 1549 01:07:43,640 --> 01:07:46,800 sa ngayon focus sa gusali ang laro at hindi 1550 01:07:46,800 --> 01:07:49,010 pagkakaroon upang mapanatili ang imprastraktura, na 1551 01:07:49,010 --> 01:07:51,910 ay nagiging isang malaking halaga ng sa itaas para sa kanilang koponan. 1552 01:07:51,910 --> 01:07:56,170 Kaya ito ay isang bagay na na- ang makinabang na nakukuha mo mula sa Dynamo DB. 1553 01:07:56,170 --> 01:08:00,930 >> Lahat ng mga karapatan, sa pagkuha sa modeling dito data. 1554 01:08:00,930 --> 01:08:03,440 At pinag-usapan namin ng kaunti tungkol sa ito ang isa sa isa, isa sa maraming, 1555 01:08:03,440 --> 01:08:05,060 at marami sa maraming mga relasyon type. 1556 01:08:05,060 --> 01:08:07,630 At paano mo mapanatili ang mga nasa Dynamo. 1557 01:08:07,630 --> 01:08:10,500 Sa Dynamo DB ginagamit namin ini-index, karaniwang pagsasalita, 1558 01:08:10,500 --> 01:08:12,910 upang i-rotate ang mga data mula sa isa lasa sa iba. 1559 01:08:12,910 --> 01:08:15,210 Hash key, hanay key, at ini-index. 1560 01:08:15,210 --> 01:08:18,540 >> Sa partikular na Halimbawa, tulad ng karamihan ng mga estado 1561 01:08:18,540 --> 01:08:23,802 magkaroon ng isang pangangailangan sa paglilisensya na lamang ng lisensya sa isa sa pagmamaneho bawat tao. 1562 01:08:23,802 --> 01:08:26,510 Hindi ka maaaring pumunta upang makakuha ng dalawang pagmamaneho lisensya sa estado ng Boston. 1563 01:08:26,510 --> 01:08:27,500 Hindi ko kayang gawin ito sa Texas. 1564 01:08:27,500 --> 01:08:28,708 Iyon uri ng mga paraan na ito ay. 1565 01:08:28,708 --> 01:08:32,779 At kaya sa DMV, mayroon kaming lookup, namin gusto mong maghanap ng lisensya sa pagmamaneho 1566 01:08:32,779 --> 01:08:35,180 sa pamamagitan ng mga social security number. 1567 01:08:35,180 --> 01:08:39,990 Gusto kong tumingin up ang mga detalye ng gumagamit sa pamamagitan ng numero ng lisensya sa pagmamaneho. 1568 01:08:39,990 --> 01:08:43,620 >> Kaya maaari naming magkaroon ng talahanayan ng isang gumagamit na may hash key sa serial number, 1569 01:08:43,620 --> 01:08:47,830 o ang numero ng social security, at iba't-ibang mga katangian na tinukoy sa item. 1570 01:08:47,830 --> 01:08:49,859 Now on na mesa ko maaaring tukuyin ang isang GSI na 1571 01:08:49,859 --> 01:08:53,370 flips na sa paligid na nagsasabing gusto ko sumira ng isang key sa lisensya at pagkatapos ay 1572 01:08:53,370 --> 01:08:54,252 lahat ng iba pang mga item. 1573 01:08:54,252 --> 01:08:57,210 Ngayon kung gusto ko para sa mga tanong at hanapin ang numero ng lisensya para sa anumang naibigay Social 1574 01:08:57,210 --> 01:08:59,609 Number Security, maaari ko query sa pangunahing table. 1575 01:08:59,609 --> 01:09:02,130 >> Kung gusto ko para sa mga tanong at gusto ko upang makuha ang social security 1576 01:09:02,130 --> 01:09:05,735 numero o iba pang mga katangian sa pamamagitan ng isang numero ng lisensya, ang maaari kong i-query ang GSI. 1577 01:09:05,735 --> 01:09:08,689 Modelo na ito ay isa na sa isang relasyon. 1578 01:09:08,689 --> 01:09:12,460 Lamang ng isang napaka-simpleng GSI, flip ang mga bagay sa paligid. 1579 01:09:12,460 --> 01:09:13,979 Ngayon, makipag-usap tungkol sa isa sa maraming. 1580 01:09:13,979 --> 01:09:16,450 Isa sa maraming ay isa lamang iyong saklaw ng hash key. 1581 01:09:16,450 --> 01:09:20,510 Saan kami makakuha ng isang pulutong na may ganitong gamitin kaso ay data monitor. 1582 01:09:20,510 --> 01:09:23,880 Monitor data lumapit sa regular pagitan, tulad ng internet ng mga bagay. 1583 01:09:23,880 --> 01:09:26,890 Kami ay palaging makakuha ng lahat ng mga talaan darating sa lahat ng oras. 1584 01:09:26,890 --> 01:09:31,420 >> At gusto ko upang mahanap ang lahat ng mga pagbasa sa pagitan ng isang partikular na tagal ng panahon. 1585 01:09:31,420 --> 01:09:34,220 Ito ay isang napaka-pangkaraniwan query sa monitoring infrastructure. 1586 01:09:34,220 --> 01:09:38,430 Ang paraan go tungkol sa na ay upang mahanap ang isang simpleng istraktura ng talahanayan, isa table. 1587 01:09:38,430 --> 01:09:42,250 Mayroon akong isang sukat device talahanayan may isang hash key sa ID ng aparato. 1588 01:09:42,250 --> 01:09:47,340 At ako ay may isang hanay na key sa timestamp, o sa kasong ito, ang epic. 1589 01:09:47,340 --> 01:09:50,350 At na nagbibigay-daan sa akin isakatuparan kumplikadong tanong laban na hanay key 1590 01:09:50,350 --> 01:09:54,950 at bumalik sa mga talaan na mga kamag-anak sa mga resulta 1591 01:09:54,950 --> 01:09:56,310 set na ako naghahanap. 1592 01:09:56,310 --> 01:09:58,360 At ito ay gagawa ng isa na sa maraming mga relasyon 1593 01:09:58,360 --> 01:10:02,340 sa pangunahing talahanayan gamit ang hash key, range key istraktura. 1594 01:10:02,340 --> 01:10:04,600 >> Kaya na uri ng built sa talahanayan sa Dynamo DB. 1595 01:10:04,600 --> 01:10:07,290 Kapag ko tutukuyin ang isang hash at hanay t table, ako 1596 01:10:07,290 --> 01:10:09,240 pagtukoy sa isang isa sa maraming relasyon. 1597 01:10:09,240 --> 01:10:12,770 Ito ay isang magulang-anak relasyon. 1598 01:10:12,770 --> 01:10:14,620 >> Makipag-usap tungkol sa maraming Ipaalam sa maraming mga relasyon. 1599 01:10:14,620 --> 01:10:19,170 At para sa partikular na halimbawa, muli, kami ay pagpunta sa gamitin ang GSI ni. 1600 01:10:19,170 --> 01:10:23,500 At makipag-usap tungkol gaming ipaalam sitwasyon kung saan mayroon akong isang ibinigay na user. 1601 01:10:23,500 --> 01:10:26,500 Gusto kong malaman ang lahat ng mga laro na nakarehistro siya para sa o nagpe-play sa. 1602 01:10:26,500 --> 01:10:29,600 At para sa isang ibinigay na laro, ako nais na mahanap ang lahat ng mga gumagamit. 1603 01:10:29,600 --> 01:10:31,010 Kaya paano ko gawin iyon? 1604 01:10:31,010 --> 01:10:34,330 Mesa My games user, pupuntahan ko na magkaroon ng isang hash key ng user ID 1605 01:10:34,330 --> 01:10:35,810 at isang hanay key ng laro. 1606 01:10:35,810 --> 01:10:37,810 >> Kaya ang isang user ay maaaring magkaroon ng maramihang mga games. 1607 01:10:37,810 --> 01:10:41,380 Ito ay isang isa sa maraming mga relasyon sa pagitan ng mga user at ang mga laro siya ay gumaganap. 1608 01:10:41,380 --> 01:10:43,410 At pagkatapos sa GSI, Kukunin ko i-flip na paligid. 1609 01:10:43,410 --> 01:10:46,679 Kukunin ko hash sa laro at Kukunin ko ng saklaw sa mga gumagamit. 1610 01:10:46,679 --> 01:10:48,970 Kaya kung nais ko upang makakuha ng lahat ng mga laro ng gumagamit sa pag-play sa, 1611 01:10:48,970 --> 01:10:49,950 Kukunin ko i-query ang pangunahing table. 1612 01:10:49,950 --> 01:10:52,699 Kung gusto ko upang makakuha ng lahat ng mga gumagamit na ay naglalaro ng isang partikular na laro, 1613 01:10:52,699 --> 01:10:53,887 Query ko ang GSI. 1614 01:10:53,887 --> 01:10:54,970 Kaya mo makita kung paano namin gawin ito? 1615 01:10:54,970 --> 01:10:58,369 Bumuo ka ng mga GSI upang suportahan ang mga gamitin ang kaso, ang application na ito, ang pag-access 1616 01:10:58,369 --> 01:10:59,410 pattern, ang mga application. 1617 01:10:59,410 --> 01:11:01,440 >> Kung kailangan ko upang i-query sa sukat na ito, ipaalam sa 1618 01:11:01,440 --> 01:11:03,500 ako gumawa ng isang index sa na dimensyon. 1619 01:11:03,500 --> 01:11:05,850 Kung hindi ako, Wala akong pakialam. 1620 01:11:05,850 --> 01:11:09,060 At depende sa paggamit kaso, ako maaaring kailangan ang index o huwag akong. 1621 01:11:09,060 --> 01:11:12,390 Kung ito ay isang simpleng isa sa maraming, ang pangunahing talahanayan ay fine. 1622 01:11:12,390 --> 01:11:15,860 Kung kailangan kong gawin ito ng maraming sa maraming, o kailangan kong gawin ang isa sa mga iyan, 1623 01:11:15,860 --> 01:11:18,390 pagkatapos ay marahil na kailangan ko sa ikalawang ang index. 1624 01:11:18,390 --> 01:11:20,840 Kaya lahat ng ito ay depende sa ano ang sinusubukan ko na gawin 1625 01:11:20,840 --> 01:11:24,550 at kung ano ang sinusubukan ko upang makakuha ng tapos na. 1626 01:11:24,550 --> 01:11:28,000 >> Marahil hindi ako pagpunta sa gastusin ng masyadong karaming oras ng pakikipag-usap tungkol sa mga dokumento. 1627 01:11:28,000 --> 01:11:31,460 Ito ay makakakuha ng isang maliit na piraso, marahil, mas malalim kaysa sa kailangan namin upang pumunta sa. 1628 01:11:31,460 --> 01:11:33,710 Makipag-usap nang kaunti Ipaalam tungkol sa mga rich expression query. 1629 01:11:33,710 --> 01:11:37,831 Kaya sa Dynamo DB kami ang kakayahan na gumawa 1630 01:11:37,831 --> 01:11:39,330 ano ang tawag namin projection expression. 1631 01:11:39,330 --> 01:11:42,660 Projection expression ay lamang pagpili ng mga patlang o ang mga halaga 1632 01:11:42,660 --> 01:11:44,290 na gusto mong ipakita. 1633 01:11:44,290 --> 01:11:46,000 OK, kaya gumawa ako ng isang seleksyon. 1634 01:11:46,000 --> 01:11:48,010 Gumawa ako ng isang query laban Dynamo DB. 1635 01:11:48,010 --> 01:11:51,730 At sinasabi ko, alam mo kung ano, palabas sa akin lamang ang limang star na mga review 1636 01:11:51,730 --> 01:11:54,544 para sa partikular na produkto. 1637 01:11:54,544 --> 01:11:55,710 Kaya na ang lahat na gusto kong makita. 1638 01:11:55,710 --> 01:11:57,320 Hindi ko nais na makita ang lahat ng iba pang mga katangian ng hilera, 1639 01:11:57,320 --> 01:11:58,319 Gusto ko lang upang makita ito. 1640 01:11:58,319 --> 01:12:01,209 Ito ay tulad ng sa SQL kapag ikaw sabihin piliin star o mula sa table, 1641 01:12:01,209 --> 01:12:02,000 makakakuha ka ng lahat ng bagay. 1642 01:12:02,000 --> 01:12:05,450 Kapag sinasabi ko piliin ang pangalan mula table, ako lamang makakuha ng isa attribute. 1643 01:12:05,450 --> 01:12:09,070 Ito ay ang parehong uri ng bagay sa Dynamo DB o iba NoSQL database. 1644 01:12:09,070 --> 01:12:14,510 Payagan ako Filter expression upang talaga kunin ang mga resulta set down. 1645 01:12:14,510 --> 01:12:15,540 Kaya ako gumawa ng isang query. 1646 01:12:15,540 --> 01:12:17,260 Query ay maaaring bumalik sa 500 na mga aytem. 1647 01:12:17,260 --> 01:12:20,255 Ngunit tanging gusto ko ang mga bagay na ay may isang katangian na nagsasabing ito. 1648 01:12:20,255 --> 01:12:23,380 OK, salain ang mga item na iyon upang ipaalam na hindi tumutugma sa partikular na query. 1649 01:12:23,380 --> 01:12:25,540 Kaya kami ay may filter expression. 1650 01:12:25,540 --> 01:12:28,310 >> Filter expression Maaari tumakbo sa anumang attribute. 1651 01:12:28,310 --> 01:12:30,260 Hindi sila ay gusto query range. 1652 01:12:30,260 --> 01:12:32,690 Itaas ang mga query ay mas pumipili. 1653 01:12:32,690 --> 01:12:36,470 Nangangailangan ako Filter query upang pumunta makakuha ng set at pagkatapos ay ang buong mga resulta 1654 01:12:36,470 --> 01:12:39,170 mag-ukit out ang data hindi ko gusto. 1655 01:12:39,170 --> 01:12:40,660 Bakit na mahalaga? 1656 01:12:40,660 --> 01:12:42,770 Dahil nabasa ko ang lahat ng ito. 1657 01:12:42,770 --> 01:12:46,597 Sa isang query, ako pagpunta upang basahin at ito ay magiging isang higanteng tungkol data. 1658 01:12:46,597 --> 01:12:48,430 At pagkatapos ay ako pagpunta sa mag-ukit out kung ano ang kailangan ko. 1659 01:12:48,430 --> 01:12:52,080 At kung ako lamang ang larawang inukit ang isang pares ng mga hilera, pagkatapos na ang OK. 1660 01:12:52,080 --> 01:12:53,620 Ito ay hindi kaya walang kakayahan. 1661 01:12:53,620 --> 01:12:57,800 >> Ngunit kung ako sa pagbabasa ng isang buong tumpok ng data, upang mag-ukit lamang out ng isang item, 1662 01:12:57,800 --> 01:13:01,490 pagkatapos ay ako pagpunta upang maging mas mahusay off ang paggamit ng isang query na hanay, 1663 01:13:01,490 --> 01:13:03,030 dahil ito ay mas pumipili. 1664 01:13:03,030 --> 01:13:06,330 Ito ay pagpunta upang i-save sa akin ng maraming pera, dahil babayaran ko para sa na read. 1665 01:13:06,330 --> 01:13:10,430 Saan ang mga resulta na dumating likod cross na wire ay maaaring maging mas maliit, 1666 01:13:10,430 --> 01:13:11,890 ngunit ako nagbabayad para sa mga nabasa na. 1667 01:13:11,890 --> 01:13:14,340 Kaya maunawaan kung paano ikaw ay nakakakuha ng data. 1668 01:13:14,340 --> 01:13:16,420 Iyan ay napakahalaga sa Dynamo DB. 1669 01:13:16,420 --> 01:13:19,710 >> Kondisyong expression, ito ay kung ano maaari mong tawagan maasahin locking. 1670 01:13:19,710 --> 01:13:28,470 Update KUNG umiiral, o kung ang halaga na ito ay katumbas ng kung ano ang aking tinukoy. 1671 01:13:28,470 --> 01:13:31,494 At kung ako ay may time stamp sa isang rekord, maaari ako basahin ang data. 1672 01:13:31,494 --> 01:13:32,535 Baka ako baguhin na data. 1673 01:13:32,535 --> 01:13:35,030 Baka pumunta ako write na data pabalik sa database. 1674 01:13:35,030 --> 01:13:38,100 Kung ang isang tao ay nagbago ang record, baka nagbago ang timestamp. 1675 01:13:38,100 --> 01:13:40,370 At ang paraan ng aking kondisyon masasabi update update 1676 01:13:40,370 --> 01:13:42,340 kung katumbas ito ng timestamp. 1677 01:13:42,340 --> 01:13:46,290 O ang pag-update ay mabibigo dahil sa isang tao na-update ang mga rekord sa habang panahon. 1678 01:13:46,290 --> 01:13:48,290 >> Iyon ay kung ano ang tawag namin maasahin locking. 1679 01:13:48,290 --> 01:13:50,670 Ito ay nangangahulugan na ang isang tao maaaring dumating sa at baguhin ito, 1680 01:13:50,670 --> 01:13:53,100 at ako pagpunta upang makita ito kapag pumunta ako pabalik na magsulat. 1681 01:13:53,100 --> 01:13:56,106 At pagkatapos ay ako maaaring aktwal na basahin na data at sabihin, oh, siya ay nagbago ito. 1682 01:13:56,106 --> 01:13:57,230 Kailangan ko na account para sa. 1683 01:13:57,230 --> 01:14:00,490 At maaari ko bang baguhin ang data sa aking i-record at mag-aplay ng isa pang update. 1684 01:14:00,490 --> 01:14:04,330 Kaya maaari mong abutin ang mga incremental update na nangyari sa pagitan ng oras 1685 01:14:04,330 --> 01:14:08,740 na basahin mo ang data at ang mga oras maaari mong isulat ang data. 1686 01:14:08,740 --> 01:14:11,520 >> Madla: At ang mga filter expression aktwal na nangangahulugan na hindi 1687 01:14:11,520 --> 01:14:13,020 sa numero o not-- 1688 01:14:13,020 --> 01:14:14,316 >> [INTERPOSING tinig] 1689 01:14:14,316 --> 01:14:16,232 RICK Houlihan: Ayaw ko makakuha ng masyadong marami sa mga ito. 1690 01:14:16,232 --> 01:14:17,700 Ito ba ang isang reserved keyword. 1691 01:14:17,700 --> 01:14:20,130 Ang pound view ay isang reserved keyword sa Dynamo DB. 1692 01:14:20,130 --> 01:14:24,500 Bawat database ay may sariling reserved pangalan para sa mga koleksyon na hindi mo maaaring gamitin. 1693 01:14:24,500 --> 01:14:27,240 Dynamo DB, kung tinukoy mo ang ng kalahating kilong sa harap ng mga ito, 1694 01:14:27,240 --> 01:14:29,310 maaari mong tukuyin ang hanggang sa mga pangalan sa itaas. 1695 01:14:29,310 --> 01:14:31,840 Ito ay isang na-reference na halaga. 1696 01:14:31,840 --> 01:14:34,880 Ito ay marahil hindi ang pinakamahusay na syntax na Mayroon up doon para sa talakayang ito, 1697 01:14:34,880 --> 01:14:38,090 dahil ito ay nakakakuha sa ilang real-- Gusto ko ay pakikipag-usap ng mas maraming 1698 01:14:38,090 --> 01:14:41,360 tungkol na sa isang mas malalim na antas. 1699 01:14:41,360 --> 01:14:46,130 >> Ngunit makasapat upang sabihin, ito ay maaaring maging query scan kung saan sila views-- 1700 01:14:46,130 --> 01:14:50,190 hindi rin nakakita pound ay mas malaki sa 10. 1701 01:14:50,190 --> 01:14:54,660 Ito ay isang de-numerong halaga, yes. 1702 01:14:54,660 --> 01:14:57,322 Kung gusto mo, maaari kaming makipag-usap tungkol sa na pagkatapos ng talakayan. 1703 01:14:57,322 --> 01:15:00,030 Lahat ng karapatan, kaya kami ay nakakakuha sa ilang mga pangyayari sa mga pinakamahusay na kasanayan 1704 01:15:00,030 --> 01:15:02,000 kung saan kami ay pagpunta sa makipag-usap tungkol sa ilang mga apps dito. 1705 01:15:02,000 --> 01:15:03,810 Ano ang mga kaso ng paggamit para Dynamo DB. 1706 01:15:03,810 --> 01:15:06,120 Ano ang mga disenyo pattern sa Dynamo DB. 1707 01:15:06,120 --> 01:15:09,110 >> At ang unang isa namin ang pagpunta sa makipag-usap tungkol ay ang internet ng mga bagay. 1708 01:15:09,110 --> 01:15:15,010 Kaya makakuha kami ng maraming of-- Hulaan ko, ano ang it-- higit sa 50% 1709 01:15:15,010 --> 01:15:19,370 ng trapiko sa internet mga araw na ito ay tunay na binuo sa pamamagitan ng machine, 1710 01:15:19,370 --> 01:15:21,930 automated na proseso, hindi sa pamamagitan ng mga kawani na tao. 1711 01:15:21,930 --> 01:15:25,140 Ibig sabihin ko ang bagay na ito ang bagay na ito na dalhin mo sa paligid sa iyong bulsa, 1712 01:15:25,140 --> 01:15:28,840 kung magkano ang data na bagay na aktwal na pagpapadala sa paligid nang hindi mo 1713 01:15:28,840 --> 01:15:30,550 pag-alam ito ay ganap amazing. 1714 01:15:30,550 --> 01:15:34,970 Ang iyong lokasyon, impormasyon tungkol sa kung paano mabilis na ikaw ay pagpunta. 1715 01:15:34,970 --> 01:15:38,400 Paano mo tingin mga gawa Google Maps kapag sinabi mo sa mga ito kung ano ang trapiko ay. 1716 01:15:38,400 --> 01:15:41,275 Ito ay dahil may mga milyon-milyon at milyon-milyong mga tao sa pagmamaneho sa paligid 1717 01:15:41,275 --> 01:15:44,667 may phone na pagpapadala data sa lahat ng dako ng lugar sa lahat ng oras. 1718 01:15:44,667 --> 01:15:46,500 Kaya isa sa mga bagay-bagay tungkol sa ganitong uri ng data 1719 01:15:46,500 --> 01:15:50,980 na nanggagaling sa, data monitor, mag-log data, data oras serye, ay ito ay 1720 01:15:50,980 --> 01:15:53,540 karaniwang mga kagiliw-giliw lamang para sa isang maliit na piraso ng oras. 1721 01:15:53,540 --> 01:15:55,580 Pagkatapos ng oras na iyon, ito ay hindi kaya kawili-wili. 1722 01:15:55,580 --> 01:15:58,390 Kaya pinag-usapan namin ang tungkol sa, huwag hayaang mga tables lumaki nang walang hangganan. 1723 01:15:58,390 --> 01:16:03,410 Ang ideya dito ay na siguro Mayroon akong 24 oras na halaga ng mga kaganapan sa aking mainit na table. 1724 01:16:03,410 --> 01:16:06,160 At na hot talahanayan ay magiging provision sa isang mataas na rate, 1725 01:16:06,160 --> 01:16:07,950 dahil ito ay ang pagkuha ng isang pulutong ng data. 1726 01:16:07,950 --> 01:16:10,920 Ito ay ang pagkuha ng isang pulutong ng data sa loob at ako pagbabasa ito ng maraming. 1727 01:16:10,920 --> 01:16:14,560 Mayroon akong isang pulutong ng mga operasyon mga query na tumatakbo laban sa data na iyon. 1728 01:16:14,560 --> 01:16:18,120 >> Matapos ang 24 oras, hey, ikaw malaman kung ano, Wala akong pakialam. 1729 01:16:18,120 --> 01:16:21,150 Kaya marahil bawat hatinggabi ko roll ang aking mga talahanayan sa ibabaw sa isang bagong mesa 1730 01:16:21,150 --> 01:16:22,430 at deprovision ko talahanayan na ito. 1731 01:16:22,430 --> 01:16:26,440 At kukunin ko na gawin ang mga RCU at Pababa WCU dahil 24 na oras mamaya 1732 01:16:26,440 --> 01:16:28,630 Hindi ko pinapatakbo sa bilang ng maraming mga tanong laban sa data na iyon. 1733 01:16:28,630 --> 01:16:30,200 Kaya ako pagpunta sa i-save ang pera. 1734 01:16:30,200 --> 01:16:32,940 At siguro 30 na araw sa paglaon hindi ako kahit na kailangan sa pag-aalaga tungkol sa lahat ng ito. 1735 01:16:32,940 --> 01:16:35,020 Kaya kong gawin ang WCU ni lahat ng mga paraan pababa sa isa, 1736 01:16:35,020 --> 01:16:36,990 dahil alam mo kung ano, ito ay hindi kailanman pagpunta upang makakuha ng nakasulat na. 1737 01:16:36,990 --> 01:16:38,300 Ang data ay 30 araw na ang edad. 1738 01:16:38,300 --> 01:16:40,000 Ito ay hindi nagbabago. 1739 01:16:40,000 --> 01:16:44,200 >> At ito ay halos hindi kailanman pagpunta upang makakuha ng basahin, kaya lang kumuha na RCU pababa sa 10 ipaalam. 1740 01:16:44,200 --> 01:16:49,372 At ako nagse-save ng isang tonelada ng pera sa mga ito data, at pagbabayad lamang para sa aking mainit na data. 1741 01:16:49,372 --> 01:16:52,330 Kaya na ang mga mahahalagang bagay na sa hitsura at kapag tumingin ka sa isang serye ng oras 1742 01:16:52,330 --> 01:16:54,716 data na nanggagaling sa sa dami. 1743 01:16:54,716 --> 01:16:55,590 Ang mga ito ay mga estratehiya. 1744 01:16:55,590 --> 01:16:58,010 Ngayon, maaari ko lamang ipaalam ito lahat ng pumunta sa parehong mesa 1745 01:16:58,010 --> 01:16:59,461 at ipaalam lamang sa table na palaguin. 1746 01:16:59,461 --> 01:17:01,460 Sa paglaon, ako pagpunta sa makita ang mga isyu sa pagganap. 1747 01:17:01,460 --> 01:17:04,060 Pupunta ako sa may upang simulan ang pag-archive ng ang ilan sa mga data na iyon mula sa mesa, 1748 01:17:04,060 --> 01:17:04,720 kung ano ang hindi. 1749 01:17:04,720 --> 01:17:07,010 >> Sabihin mas mas mahusay na disenyo ng iyong application 1750 01:17:07,010 --> 01:17:08,900 sa gayon ay maaari mong patakbuhin ang ganitong paraan ng karapatan. 1751 01:17:08,900 --> 01:17:11,460 Kaya lamang automatic sa application code. 1752 01:17:11,460 --> 01:17:13,580 Sa hatinggabi gabi-gabi ito listahan ng talahanayan. 1753 01:17:13,580 --> 01:17:17,170 Siguro kung ano ang kailangan ko ay isang sliding window ng 24 na oras ng data. 1754 01:17:17,170 --> 01:17:20,277 Pagkatapos ay sa isang regular na batayan Ako pagtawag off ang talahanayan ng data. 1755 01:17:20,277 --> 01:17:22,360 Ako dekorasyon ito na may isang Cron trabaho at ako ng paglagay ito 1756 01:17:22,360 --> 01:17:24,160 papunta sa mga iba pang mga talahanayan, kahit anong kailangan mo. 1757 01:17:24,160 --> 01:17:25,940 Kaya kung gumagana ng rollover, na malaki. 1758 01:17:25,940 --> 01:17:27,080 Kung hindi, putulin ito. 1759 01:17:27,080 --> 01:17:29,640 Ngunit panatilihin na hot data ipaalam layo mula sa iyong malamig na data. 1760 01:17:29,640 --> 01:17:32,535 Makikita ito i-save ka ng maraming pera at gawin ang iyong mga talahanayan ng higit na gumaganap. 1761 01:17:32,535 --> 01:17:35,960 1762 01:17:35,960 --> 01:17:38,210 Kaya ang susunod na bagay na makikita namin makipag-usap tungkol ay produkto ng catalog. 1763 01:17:38,210 --> 01:17:42,000 Produkto catalog ay pretty karaniwang pagkakataon ng paggamit. 1764 01:17:42,000 --> 01:17:46,600 Ito ay talagang isang napaka-karaniwang pattern na makikita namin makita sa isang iba't ibang mga bagay. 1765 01:17:46,600 --> 01:17:48,870 Alam mo yun, Twitter para sa Halimbawa, ang isang hot tweet. 1766 01:17:48,870 --> 01:17:51,280 Ang bawat ay darating at daklot na tweet. 1767 01:17:51,280 --> 01:17:52,680 Produkto catalog, Nakatanggap ako ng sale. 1768 01:17:52,680 --> 01:17:54,120 Nakakuha ako ng isang hot sale. 1769 01:17:54,120 --> 01:17:57,277 Nakakuha ako ng 70,000 mga kahilingan sa bawat ikalawang pagdating para sa isang produkto 1770 01:17:57,277 --> 01:17:58,860 paglalarawan sa labas ng aking mga produkto catalog. 1771 01:17:58,860 --> 01:18:02,384 Nakita namin ito sa retail operasyon pa ng kaunti. 1772 01:18:02,384 --> 01:18:03,550 Kaya kung paano namin pakikitungo sa mga iyon? 1773 01:18:03,550 --> 01:18:04,924 Walang paraan upang harapin ang mga iyon. 1774 01:18:04,924 --> 01:18:07,110 Lahat ng aking mga gumagamit na nais upang makita ang ang parehong piraso ng data. 1775 01:18:07,110 --> 01:18:09,410 Ang mga ito ay nagmumula sa, Kasabay. 1776 01:18:09,410 --> 01:18:11,920 At lahat sila ay paggawa ng mga kahilingan para sa parehong piraso ng data. 1777 01:18:11,920 --> 01:18:16,240 Nagbibigay sa akin ito na ang hot key, na malaki red guhit sa aking mga chart na hindi namin gusto. 1778 01:18:16,240 --> 01:18:17,720 At na kung ano na kamukha. 1779 01:18:17,720 --> 01:18:22,290 Kaya sa kabuuan ng aking key space ko nakukuha hammered sa mga item sale. 1780 01:18:22,290 --> 01:18:24,070 Wala ko natatanggap kahit saan pa. 1781 01:18:24,070 --> 01:18:26,050 >> Paano ko magpakalma ang problemang ito? 1782 01:18:26,050 --> 01:18:28,410 Well, magpakalma namin sa cache. 1783 01:18:28,410 --> 01:18:33,630 Cache, ilagay mo talaga ng isang in-memory pagkahati sa harap ng database. 1784 01:18:33,630 --> 01:18:37,260 Kami ay pinamamahalaang [Hindi marinig] cache, kung paano mo 1785 01:18:37,260 --> 01:18:40,260 maaaring i-set up ang iyong sariling mga cache, [hindi marinig] cache [? d,?] kahit anong gusto mo. 1786 01:18:40,260 --> 01:18:42,220 Ilagay na up sa harap ng database. 1787 01:18:42,220 --> 01:18:47,250 At ang paraan na maaari mong iimbak ang data mula sa mga hot keys up sa na cache 1788 01:18:47,250 --> 01:18:49,390 space at basahin sa pamamagitan ng cache. 1789 01:18:49,390 --> 01:18:51,962 >> At pagkatapos ay ang karamihan ng iyong mga nagbabasa simulan ang hinahanap tulad nito. 1790 01:18:51,962 --> 01:18:54,920 Lahat ang nakuha ko hit up dito mga cache at ang nakuha ko walang pagpunta sa down dito 1791 01:18:54,920 --> 01:18:59,330 dahil database ay nakaupo sa likod ng cache at ang mga nagbabasa ay hindi kailanman dumating sa pamamagitan ng. 1792 01:18:59,330 --> 01:19:02,520 Kung babaguhin ko ang mga data sa database, kailangan kong i-update ang cache. 1793 01:19:02,520 --> 01:19:04,360 Maaari naming gamitin ang isang bagay tulad steams upang gawin iyon. 1794 01:19:04,360 --> 01:19:07,360 At kukunin ko na ipaliwanag kung paano na gumagana. 1795 01:19:07,360 --> 01:19:09,060 Lahat ng karapatan, messaging. 1796 01:19:09,060 --> 01:19:11,180 Email, namin ang lahat ng gamitin ang email. 1797 01:19:11,180 --> 01:19:12,540 >> Ito ay isang medyo magandang halimbawa. 1798 01:19:12,540 --> 01:19:14,950 Nakakuha kami ng ilang mga uri ng mga mensahe table. 1799 01:19:14,950 --> 01:19:17,040 At nakuha namin inbox at outbox. 1800 01:19:17,040 --> 01:19:19,760 Ito ay kung ano ang SQL gagawin hitsura upang bumuo ng inbox na iyon. 1801 01:19:19,760 --> 01:19:23,350 Uri namin ng gamitin ang parehong uri ng mga diskarte upang gamitin GSI ni, GSI ni 1802 01:19:23,350 --> 01:19:25,320 para sa aking inbox at ang aking outbox. 1803 01:19:25,320 --> 01:19:27,600 Kaya ang nakuha ko raw mga mensahe pagdating sa aking mga mensahe table. 1804 01:19:27,600 --> 01:19:30,194 At ang unang diskarte sa ito ay maaaring maging, sabihin, OK, walang problema. 1805 01:19:30,194 --> 01:19:31,110 Mayroon akong raw mensahe. 1806 01:19:31,110 --> 01:19:33,710 Mga Mensahe darating [hindi marinig], message ID, na malaki. 1807 01:19:33,710 --> 01:19:35,070 Iyon ang aking natatanging hash. 1808 01:19:35,070 --> 01:19:38,280 Pupunta ako upang lumikha ng dalawang GSI, isa para sa aking inbox, isa para sa aking outbox. 1809 01:19:38,280 --> 01:19:40,530 At ang unang bagay na kailangan kong gawin ay kukunin ko na sabihin ang aking hash key ay 1810 01:19:40,530 --> 01:19:43,310 magiging ang tatanggap at Pupunta ako upang ayusin ang petsa. 1811 01:19:43,310 --> 01:19:44,220 Ito ay walang katotohanan. 1812 01:19:44,220 --> 01:19:45,890 Nakatanggap ako ang aking magandang tanawin dito. 1813 01:19:45,890 --> 01:19:47,780 Subalit mayroong isang maliit na isyu dito. 1814 01:19:47,780 --> 01:19:50,891 At tumakbo ka sa ito sa pamanggit database pati na rin. 1815 01:19:50,891 --> 01:19:52,390 Sila ay tinatawag na patayo partitioning. 1816 01:19:52,390 --> 01:19:55,840 Gusto mong panatilihin ang iyong malaking data layo mula sa iyong maliit na data. 1817 01:19:55,840 --> 01:20:00,470 >> At ang dahilan kung bakit ay dahil ako gotta pumunta basahin ang mga item upang makakuha ng mga katangian. 1818 01:20:00,470 --> 01:20:05,570 At kung ang aking katawan ay ang lahat sa dito, pagkatapos ay pagbabasa lamang ng ilang mga item 1819 01:20:05,570 --> 01:20:08,560 kung ang aking katawan haba ay average ng 256 kilobytes bawat isa, 1820 01:20:08,560 --> 01:20:10,991 ang matematika ay makakakuha ng medyo mainit ang ulo. 1821 01:20:10,991 --> 01:20:12,490 Kaya sabihin na gusto kong basahin inbox ni David. 1822 01:20:12,490 --> 01:20:14,520 Inbox ni David ay may 50 na mga aytem. 1823 01:20:14,520 --> 01:20:17,880 Ang average at laki ay 256 kilobytes. 1824 01:20:17,880 --> 01:20:21,730 Ito ang aking ratio ng conversion para RCU ay apat na kilobytes. 1825 01:20:21,730 --> 01:20:24,450 >> OK, sabihin pumunta sa pare-pareho sa huli bumabasa. 1826 01:20:24,450 --> 01:20:28,640 Ako kumakain 1600 RCU pa rin lamang na basahin ang inbox ni David. 1827 01:20:28,640 --> 01:20:29,950 Ouch. 1828 01:20:29,950 --> 01:20:31,980 OK, sabihin isipin ngayon hayaan tungkol sa kung paano gumagana ang app. 1829 01:20:31,980 --> 01:20:35,340 Kung ako sa isang email app at Naghahanap ako sa aking inbox, 1830 01:20:35,340 --> 01:20:39,680 at ako ay tumingin sa katawan ng bawat mensahe, Wala, Naghahanap ako ng sa mga buod. 1831 01:20:39,680 --> 01:20:41,850 Naghahanap ako sa lamang ang mga header. 1832 01:20:41,850 --> 01:20:46,310 Kaya ipaalam sa bumuo ng isang istraktura ng talahanayan na mukhang mas tulad ng. 1833 01:20:46,310 --> 01:20:49,470 >> Kaya dito ay ang mga impormasyon na ang mga pangangailangan ng aking workflow. 1834 01:20:49,470 --> 01:20:50,890 Ito ay sa aking inbox GSI. 1835 01:20:50,890 --> 01:20:53,800 Ito ay ang petsa, ang nagpadala, ang paksa, at pagkatapos ay 1836 01:20:53,800 --> 01:20:56,790 ang ID na mensahe, na puntos bumalik sa mga mensahe ng talahanayan 1837 01:20:56,790 --> 01:20:57,850 kung saan ako makakakuha ng katawan. 1838 01:20:57,850 --> 01:21:01,260 1839 01:21:01,260 --> 01:21:04,420 Well, ang mga ito ay magiging record ID. 1840 01:21:04,420 --> 01:21:09,850 Gusto nila point bumalik sa item IDs sa Dynamo DB table. 1841 01:21:09,850 --> 01:21:12,220 Bawat index laging creates-- laging may item 1842 01:21:12,220 --> 01:21:15,750 ID bilang bahagi of-- na nanggagaling sa mga index. 1843 01:21:15,750 --> 01:21:17,414 >> Lahat tama. 1844 01:21:17,414 --> 01:21:19,080 Madla: Ito ay nagsasabi na ito kung saan naka-imbak ito? 1845 01:21:19,080 --> 01:21:21,420 RICK Houlihan: Oo, ito ay nagsasabi exactly-- na eksakto kung ano ang ginagawa nito. 1846 01:21:21,420 --> 01:21:22,644 Sinasabi nito dito ang aking record re. 1847 01:21:22,644 --> 01:21:24,310 At makikita ito ituro ito pabalik sa aking record re. 1848 01:21:24,310 --> 01:21:26,460 Mismong. 1849 01:21:26,460 --> 01:21:29,490 OK, ang aking inbox kaya ngayon ay talagang mas maliit. 1850 01:21:29,490 --> 01:21:32,210 At ito ang tunay na sinusuportahan ang daloy ng trabaho ng isang email app. 1851 01:21:32,210 --> 01:21:34,230 Kaya ang aking inbox, i-click ko. 1852 01:21:34,230 --> 01:21:38,160 Pumunta ako kasama at i-click ako sa mensahe, na kapag kailangan ko upang pumunta makakuha ng katawan, 1853 01:21:38,160 --> 01:21:40,180 dahil ako pagpunta sa pumunta sa isang iba't ibang mga view. 1854 01:21:40,180 --> 01:21:43,870 Kaya kung sa tingin mo ang tungkol sa mga uri ng MVC framework, tingnan model controller. 1855 01:21:43,870 --> 01:21:46,120 >> Naglalaman ng model ang mga data na ang mga pangangailangan na view 1856 01:21:46,120 --> 01:21:48,130 at ang controller nakikipag-ugnayan sa. 1857 01:21:48,130 --> 01:21:51,670 Kapag binago ko ang mga frame, kapag Baguhin ko ang pananaw, 1858 01:21:51,670 --> 01:21:55,080 ito ay ang OK upang bumalik sa server at repopulate sa modelo, 1859 01:21:55,080 --> 01:21:56,860 dahil na kung ano ang inaasahan sa gumagamit. 1860 01:21:56,860 --> 01:22:00,530 Kapag binago nila ang nakakita, na kapag maaari naming bumalik sa database. 1861 01:22:00,530 --> 01:22:02,480 Kaya email, i-click ang. 1862 01:22:02,480 --> 01:22:03,710 Naghahanap ako ng katawan. 1863 01:22:03,710 --> 01:22:04,330 Papunta at pabalik. 1864 01:22:04,330 --> 01:22:05,680 Pumunta makakuha ng katawan. 1865 01:22:05,680 --> 01:22:06,950 >> Ako basahin ang isang pulutong ng mas kaunting data. 1866 01:22:06,950 --> 01:22:09,960 Ako ng pagbabasa lamang ang mga katawan na David pangangailangan kapag siya ay nangangailangan ng mga ito. 1867 01:22:09,960 --> 01:22:14,230 At hindi ako sumunog sa 1600 RCU upang ipakita lamang ang kanyang inbox. 1868 01:22:14,230 --> 01:22:17,670 Kaya ngayon na- ito ay ang paraan na LSI o GSI-- Sorry, 1869 01:22:17,670 --> 01:22:19,900 GSI, ay gumagana out. 1870 01:22:19,900 --> 01:22:25,450 Mayroon kami ng aming hash sa mga tatanggap. 1871 01:22:25,450 --> 01:22:27,030 Mayroon din kaming mga hanay na key sa petsa. 1872 01:22:27,030 --> 01:22:31,380 At nakuha namin ang mga inaasahang katangian na kailangan lamang namin upang suportahan ang mga view. 1873 01:22:31,380 --> 01:22:34,300 >> Paikutin namin na para sa outbox. 1874 01:22:34,300 --> 01:22:35,770 Sumira sa nagpadala. 1875 01:22:35,770 --> 01:22:39,612 At sa kakanyahan, kami ay ang very nice, clean view. 1876 01:22:39,612 --> 01:22:41,570 At ito ay basically-- namin na ito ay may magandang mensahe 1877 01:22:41,570 --> 01:22:45,870 mesa na ini kumalat mabuti dahil ito ay hash lamang, na-hash ID mensahe. 1878 01:22:45,870 --> 01:22:51,750 At kami ay may dalawang index na ay umiikot off ng talahanayan. 1879 01:22:51,750 --> 01:22:57,411 Lahat ng karapatan, kaya ideya dito ay hindi panatilihin ang malaking data at ito maliit na data 1880 01:22:57,411 --> 01:22:57,910 sama-sama. 1881 01:22:57,910 --> 01:23:00,700 Partisyon patayo, pagkahati mga tables. 1882 01:23:00,700 --> 01:23:03,150 Huwag basahin ang data na hindi mo na kailangang. 1883 01:23:03,150 --> 01:23:04,850 Lahat ng karapatan, gaming. 1884 01:23:04,850 --> 01:23:06,990 Namin ang lahat ng mga laro. 1885 01:23:06,990 --> 01:23:10,902 Hindi bababa sa gusto ko pagkatapos games. 1886 01:23:10,902 --> 01:23:12,735 Kaya ang ilan sa mga bagay-bagay na aming pakikitungo sa kapag 1887 01:23:12,735 --> 01:23:14,193 pinag-iisipan namin ang tungkol sa gaming, di ba? 1888 01:23:14,193 --> 01:23:16,999 Paglalaro ng mga araw, lalo na mobile gaming, ay tungkol sa lahat na pag-iisip. 1889 01:23:16,999 --> 01:23:19,540 At ako pagpunta upang i-rotate dito ng isang maliit na piraso ang layo mula DynamoDB. 1890 01:23:19,540 --> 01:23:21,373 Pupunta ako upang dalhin sa ang ilan sa mga talakayan 1891 01:23:21,373 --> 01:23:24,240 sa paligid ang ilan sa mga iba pang mga teknolohiya AWS. 1892 01:23:24,240 --> 01:23:28,930 >> Ngunit ang mga ideya tungkol sa gaming ay mag-isip tungkol sa mga tuntunin ng API API na,, 1893 01:23:28,930 --> 01:23:31,730 karaniwang pagsasalita, HTTP at JSON. 1894 01:23:31,730 --> 01:23:34,550 Ito ay kung paano mobile games uri ng makipag-ugnayan sa kanilang mga dulo ng likod. 1895 01:23:34,550 --> 01:23:35,850 Gawin nila ang JSON-post. 1896 01:23:35,850 --> 01:23:40,660 Makakuha ng mga ito ng data, at ito ay ang lahat, karaniwang pagsasalita, sa ganda ng JSON APIs. 1897 01:23:40,660 --> 01:23:44,950 >> Mga bagay tulad ng makakuha ng mga kaibigan, kumuha ng ang data leaderboard, exchange, 1898 01:23:44,950 --> 01:23:47,699 nilalamang binuo ng gumagamit, uurong up sa sistema, 1899 01:23:47,699 --> 01:23:49,740 ang mga ito ay mga uri ng mga bagay-bagay na kami ay pagpunta sa gawin. 1900 01:23:49,740 --> 01:23:52,542 Binary data asset, ang data na ito Maaaring hindi umupo sa database. 1901 01:23:52,542 --> 01:23:54,250 Ito ay maaaring umupo sa isang object store, di ba? 1902 01:23:54,250 --> 01:23:56,541 Ngunit ang mga database ay pagpunta sa end up na nagsasabi sa sistema, 1903 01:23:56,541 --> 01:23:59,140 nagsasabi ng application kung saan pumunta makakuha ng ito. 1904 01:23:59,140 --> 01:24:03,550 At hindi maaaring hindi, Multiplayer servers, end infrastructure back, 1905 01:24:03,550 --> 01:24:06,180 at dinisenyo para sa mataas na availability at kakayahang sumukat. 1906 01:24:06,180 --> 01:24:09,400 Kaya ang mga ito ay mga bagay na namin ang lahat ng gusto sa imprastraktura gaming ngayon. 1907 01:24:09,400 --> 01:24:12,160 >> Kaya sabihin kumuha ng isang pagtingin sa kung ano na kamukha. 1908 01:24:12,160 --> 01:24:16,070 Mayroon ka bang isang core likod ng pagtatapos, tunay tapat. 1909 01:24:16,070 --> 01:24:19,880 Nakakuha kami ng isang sistema dito sa maramihang availability zones. 1910 01:24:19,880 --> 01:24:23,780 Usapan natin ang tungkol Azs bilang being-- tingin ng mga ito bilang mga hiwalay na mga data center. 1911 01:24:23,780 --> 01:24:26,040 Higit sa isang data center per AZ, ngunit iyan ay OK, 1912 01:24:26,040 --> 01:24:28,831 lamang sa tingin ng mga ito bilang mga hiwalay na data centers na heograpiya 1913 01:24:28,831 --> 01:24:30,090 at kasalanan ihiwalay. 1914 01:24:30,090 --> 01:24:32,172 >> Kami ay pagpunta sa magkaroon ng isang pagkakataon pares EC2. 1915 01:24:32,172 --> 01:24:33,880 Kami ay pagpunta sa may ilang back end server. 1916 01:24:33,880 --> 01:24:35,800 Siguro kung ikaw ay isang legacy architecture, hindi namin 1917 01:24:35,800 --> 01:24:38,920 gamit ang kung ano ang tawag namin sa RDS, pamanggit database ng mga serbisyo. 1918 01:24:38,920 --> 01:24:42,040 Puwede na MSSQL, MySQL, o isang bagay tulad na. 1919 01:24:42,040 --> 01:24:47,080 Ito ang paraan ng maraming mga application ay dinisenyo ngayon. 1920 01:24:47,080 --> 01:24:49,594 >> Well kami maaaring gusto mong pumunta sa ito ay kapag ang scale out namin. 1921 01:24:49,594 --> 01:24:51,510 Susubukan naming sige, at ilagay ang S3 bucket up doon. 1922 01:24:51,510 --> 01:24:54,200 At na S3 bucket, sa halip ng paghahatid up ang mga bagay mula sa aming mga servers-- 1923 01:24:54,200 --> 01:24:55,220 maaari naming gawin iyon. 1924 01:24:55,220 --> 01:24:57,210 Ilagay mo ang lahat ng iyong mga binary bagay sa iyong server 1925 01:24:57,210 --> 01:24:59,751 at maaari mong gamitin ang mga server mga pagkakataon upang maglingkod na data up. 1926 01:24:59,751 --> 01:25:01,860 Ngunit iyon lamang ang medyo mahal. 1927 01:25:01,860 --> 01:25:05,107 >> Mas mahusay na paraan upang gawin ay magpatuloy at maglagay ng mga bagay sa isang S3 bucket. 1928 01:25:05,107 --> 01:25:06,315 S3 ay isang object repositoryo. 1929 01:25:06,315 --> 01:25:10,860 Partikular na ito ay binuo para sa serving up ang mga uri ng mga bagay-bagay. 1930 01:25:10,860 --> 01:25:13,690 At hayaang humiling sa mga kliyente direkta mula sa mga object bucket, 1931 01:25:13,690 --> 01:25:15,390 offload ang mga server. 1932 01:25:15,390 --> 01:25:17,020 Kaya kami ay nagsisimula upang masukat out dito. 1933 01:25:17,020 --> 01:25:19,140 >> Ngayon namin nakuha ang mga gumagamit sa buong mundo. 1934 01:25:19,140 --> 01:25:19,730 Nakatanggap ako ng mga gumagamit. 1935 01:25:19,730 --> 01:25:23,380 Kailangan kong magkaroon ng nilalaman sa isang lugar lamang na matatagpuan malapit sa mga user na ito, i-right? 1936 01:25:23,380 --> 01:25:26,200 Lumikha ako ng isang S3 bucket bilang aking pinagmulan repository. 1937 01:25:26,200 --> 01:25:29,370 At kukunin ko na front na may ang CloudFront pamamahagi. 1938 01:25:29,370 --> 01:25:31,720 >> CloudFront ay isang CD at isang ang paghahatid ng network ng nilalaman. 1939 01:25:31,720 --> 01:25:35,750 Karaniwang ito ay tumatagal ng data na iyong tinukoy at mga cache lahat ng ito sa internet 1940 01:25:35,750 --> 01:25:39,230 upang ang mga gumagamit sa lahat ng dako ay maaaring magkaroon ng isang mabilis na tugon kapag 1941 01:25:39,230 --> 01:25:40,960 silang humiling ng mga bagay. 1942 01:25:40,960 --> 01:25:41,960 >> Kaya mo makakuha ng isang ideya. 1943 01:25:41,960 --> 01:25:48,230 Uri ng Ikaw ay pagdaragdag ng lahat ng mga aspeto ng AWS dito upang makakuha ng ito tapos. 1944 01:25:48,230 --> 01:25:50,790 At sa huli, itapon namin sa isang auto scaling group. 1945 01:25:50,790 --> 01:25:52,737 Kaya ang aming mga pagkakataon AC2 ng aming mga server ng laro, 1946 01:25:52,737 --> 01:25:54,820 simulan nila upang makakuha ng busier at busier at busier, 1947 01:25:54,820 --> 01:25:57,236 makikita lang nila iikot ang isa pang Halimbawa, iikot ang isa pang halimbawa, 1948 01:25:57,236 --> 01:25:58,210 iikot ng isa pang halimbawa. 1949 01:25:58,210 --> 01:26:02,090 Kaya ang teknolohiya AWS ay may, ito ay nagpapahintulot sa iyo na tukuyin ang mga parameter 1950 01:26:02,090 --> 01:26:04,650 sa paligid ng kung saan ang iyong mga server ay lalaki. 1951 01:26:04,650 --> 01:26:08,110 Kaya maaari kang magkaroon n bilang ng mga server out there sa anumang naibigay na oras. 1952 01:26:08,110 --> 01:26:11,870 At kung ang iyong load napupunta ang layo, makikita nila pag-urong, ang bilang ay pag-urong. 1953 01:26:11,870 --> 01:26:15,250 At kung ang load ay bumalik, Makikita ito maging likod out, elastically. 1954 01:26:15,250 --> 01:26:17,050 >> Kaya mahusay na ito ay mukhang. 1955 01:26:17,050 --> 01:26:19,800 Nakakuha kami ng isang pulutong ng mga pagkakataon EC2. 1956 01:26:19,800 --> 01:26:21,671 Maaari naming ilagay ang cache in harap ng mga database, 1957 01:26:21,671 --> 01:26:23,045 subukan at mapabilis ang mga database. 1958 01:26:23,045 --> 01:26:25,030 Ang susunod na presyon ng point karaniwang mga tao na makita 1959 01:26:25,030 --> 01:26:28,850 ay ang laki sila ng isang laro gamit ang isang pamanggit database system. 1960 01:26:28,850 --> 01:26:30,790 Jeez, ang database pagganap ay napakahirap. 1961 01:26:30,790 --> 01:26:31,932 Paano pagbutihin namin iyon? 1962 01:26:31,932 --> 01:26:33,640 Subukan ang paglagay Ipaalam cache sa harap ng mga iyon. 1963 01:26:33,640 --> 01:26:36,780 >> Well, cache ay hindi gumagana kaya mahusay sa games, di ba? 1964 01:26:36,780 --> 01:26:39,330 Para sa mga laro, ang pagsusulat ay masakit. 1965 01:26:39,330 --> 01:26:40,930 Mga Laro ay napaka isulat mabigat. 1966 01:26:40,930 --> 01:26:43,610 Cache ay hindi gumagana kapag ikaw ay isulat mabigat dahil na sa iyo na laging 1967 01:26:43,610 --> 01:26:44,610 Nakakuha upang i-update ang cache. 1968 01:26:44,610 --> 01:26:47,780 I-update mo ang cache, ito ay hindi kaugnay na pag-cache. 1969 01:26:47,780 --> 01:26:49,780 Ito ay talagang lamang dagdag na trabaho. 1970 01:26:49,780 --> 01:26:51,970 >> Kaya kung saan tayo pupunta dito? 1971 01:26:51,970 --> 01:26:54,400 Nakuha mo na ang isang malaking bottleneck down doon sa database. 1972 01:26:54,400 --> 01:26:57,661 At ang lugar na dapat puntahan malinaw naman ay partisyon. 1973 01:26:57,661 --> 01:26:59,410 Partitioning ay hindi madaling gawin kapag ikaw ay 1974 01:26:59,410 --> 01:27:01,900 pagharap sa pamanggit database. 1975 01:27:01,900 --> 01:27:05,080 Sa pamanggit database, ikaw ay responsable para sa pamamahala, mabisa, 1976 01:27:05,080 --> 01:27:06,210 ang susi space. 1977 01:27:06,210 --> 01:27:10,527 Ikaw ay sinasabi ang mga gumagamit sa pagitan ng A at M pumunta dito, sa pagitan ng N at Z pumunta doon. 1978 01:27:10,527 --> 01:27:12,360 At lilipat ka sa kabila ng application. 1979 01:27:12,360 --> 01:27:15,000 Kaya ikaw ay pagharap sa ito partition data source. 1980 01:27:15,000 --> 01:27:18,670 Mayroon kang limitasyon transactional na hindi sumasaklaw sa partisyon. 1981 01:27:18,670 --> 01:27:20,560 Nakuha mo na ang lahat ng uri ng messiness na kayo 1982 01:27:20,560 --> 01:27:23,040 pagharap sa ibaba roon sinusubukan upang harapin ang scaling out 1983 01:27:23,040 --> 01:27:25,120 at pagbuo ng isang mas malaking infrastructure. 1984 01:27:25,120 --> 01:27:27,284 Ito lang ang hindi masaya. 1985 01:27:27,284 --> 01:27:30,930 >> Madla: Kaya ikaw ay sinasabi na pagtaas ng mga puntos na source pinapabilis 1986 01:27:30,930 --> 01:27:31,430 ang proseso? 1987 01:27:31,430 --> 01:27:32,513 RICK Houlihan: Ang pagtaas? 1988 01:27:32,513 --> 01:27:33,520 Madla: Source points. 1989 01:27:33,520 --> 01:27:34,410 RICK Houlihan: Source points? 1990 01:27:34,410 --> 01:27:37,500 Madla: Mula sa impormasyon, kung saan ang impormasyon ay nagmumula? 1991 01:27:37,500 --> 01:27:38,250 RICK Houlihan: No. 1992 01:27:38,250 --> 01:27:41,820 Ano ako sinasabi ay ang pagtaas ng bilang ng mga partitions sa tindahan ng data 1993 01:27:41,820 --> 01:27:44,060 nagpapabuti throughput. 1994 01:27:44,060 --> 01:27:48,300 Kaya kung ano ang nangyayari dito ay gumagamit ng pagdating sa EC2 halimbawa dito, 1995 01:27:48,300 --> 01:27:50,780 well, kung kailangan ko ng isang user iyan ay isang m, kailangan ko pumunta dito. 1996 01:27:50,780 --> 01:27:53,560 Mula N sa p, kukunin ko na pumunta dito. 1997 01:27:53,560 --> 01:27:55,060 Mula P hanggang Z, kailangan ko pumunta dito. 1998 01:27:55,060 --> 01:27:57,120 >> Madla: OK, mga kaya ang mga ito ay lahat ng naka-imbak sa iba't-ibang mga nodes? 1999 01:27:57,120 --> 01:27:57,911 >> RICK Houlihan Oo. 2000 01:27:57,911 --> 01:28:00,210 Mag-isip ng mga ito bilang iba't ibang silos ng data. 2001 01:28:00,210 --> 01:28:01,660 Kaya ikaw ay may sa gawin ito. 2002 01:28:01,660 --> 01:28:02,910 Kung sinusubukan na gawin ito, kung sinusubukan 2003 01:28:02,910 --> 01:28:05,730 sa scale sa isang pamanggit platform, ito ay kung ano ang ginagawa mo. 2004 01:28:05,730 --> 01:28:08,100 Ikaw ay ang pagkuha ng data at ikaw ay pagputol ito pababa. 2005 01:28:08,100 --> 01:28:10,975 At ikaw ay partitioning ito sa buong maraming mga pagkakataon ng database. 2006 01:28:10,975 --> 01:28:13,580 At namamahala ka ng lahat na sa tier application. 2007 01:28:13,580 --> 01:28:14,729 Ito ay hindi masaya. 2008 01:28:14,729 --> 01:28:15,770 Kaya kung ano ang gusto namin upang pumunta? 2009 01:28:15,770 --> 01:28:20,240 Gusto naming pumunta DynamoDB, ganap na pinamamahalaang, NoSQL store data, pagkakaloob throughput. 2010 01:28:20,240 --> 01:28:22,680 Ginagamit namin ang pangalawang index. 2011 01:28:22,680 --> 01:28:26,154 Ito ay isa lamang HTTP API at kabilang ang suporta ng dokumento. 2012 01:28:26,154 --> 01:28:28,570 Kaya hindi mo na kailangang mag-alala tungkol sa anumang ng na-partisyon. 2013 01:28:28,570 --> 01:28:30,740 Ginagawa namin ang lahat ng ito para sa iyo. 2014 01:28:30,740 --> 01:28:33,260 Kaya ngayon, sa halip, maaari mo isulat lang sa table. 2015 01:28:33,260 --> 01:28:36,490 Kung kailangan ng talahanayan upang Hahatiin, na ang mangyayari sa likod ng mga eksena. 2016 01:28:36,490 --> 01:28:40,642 Ganap ka insulated mula sa na bilang isang developer. 2017 01:28:40,642 --> 01:28:42,350 Kaya sabihin makipag-usap tungkol ang ilan sa mga kaso na paggamit 2018 01:28:42,350 --> 01:28:47,564 na tumakbo kami sa sa paglalaro, karaniwang pangyayari gaming, leaderboard. 2019 01:28:47,564 --> 01:28:49,980 Kaya mayroon ka gumagamit na pumapasok, ang BoardNames na ang mga ito 2020 01:28:49,980 --> 01:28:52,930 on, ang mga marka para sa gumagamit na ito. 2021 01:28:52,930 --> 01:28:57,700 Maaari naming maging hashing sa inyong ID, at pagkatapos ay mayroon kaming hanay sa laro. 2022 01:28:57,700 --> 01:28:59,960 Kaya ang nagnanais na makita ang bawat user lahat ng mga laro siya ay nag-play 2023 01:28:59,960 --> 01:29:01,770 at ang lahat ng kanyang pinakamataas na iskor sa lahat ng mga laro. 2024 01:29:01,770 --> 01:29:04,000 Kaya na ang kanyang personal na leaderboard. 2025 01:29:04,000 --> 01:29:10,010 >> Ngayon, gusto kong pumunta sa at gusto kong get-- kaya nakukuha ko ang mga personal na mga leaderboard. 2026 01:29:10,010 --> 01:29:12,827 Ano ang gusto kong gawin ay pumunta makakuha ng ang pinakamataas na iskor sa lahat ng mga gumagamit. 2027 01:29:12,827 --> 01:29:13,660 Kaya paano ko gawin iyon? 2028 01:29:13,660 --> 01:29:18,070 Kapag ang aking record ay na-hash sa ang inyong ID, ranged sa laro, 2029 01:29:18,070 --> 01:29:20,740 well ako pagpunta sa sige at restructure, lumikha ng isang GSI, 2030 01:29:20,740 --> 01:29:22,370 at ako pagpunta sa restructure na data. 2031 01:29:22,370 --> 01:29:27,310 >> Ngayon ako pagpunta sa hash sa BoardName, na kung saan ay ang laro. 2032 01:29:27,310 --> 01:29:29,800 At ako pagpunta sa hanay sa itaas na marka. 2033 01:29:29,800 --> 01:29:31,540 At ngayon Ako ay lumikha ng iba't ibang mga bucket. 2034 01:29:31,540 --> 01:29:34,790 Ako gamit ang parehong mesa, ang parehong data item. 2035 01:29:34,790 --> 01:29:39,870 Ngunit Lumilikha ako ng isang bucket na nagbibigay sa sa akin ng isang pagsasama-sama ng pinakamataas na iskor sa pamamagitan ng laro. 2036 01:29:39,870 --> 01:29:43,180 >> At maaari kong i-query table na upang makakuha ng impormasyon na iyon. 2037 01:29:43,180 --> 01:29:50,890 Kaya ko na-set na pattern query hanggang sa suportahan ng isang pangalawang index. 2038 01:29:50,890 --> 01:29:54,556 Ngayon ay maaari silang nakaayos ayon BoardName at nakaayos ayon sa TopScore, depende sa. 2039 01:29:54,556 --> 01:29:57,180 Kaya maaari mong makita, ang mga ito ay mga uri ng gamitin ang mga kaso na makukuha mo sa paglalaro. 2040 01:29:57,180 --> 01:30:02,190 Ang isa pang mahusay na gamitin ang kaso na nakukuha namin sa gaming ay parangal at kung sino ang nanalo sa awards. 2041 01:30:02,190 --> 01:30:05,340 At ito ay isang mahusay na pagkakataon ng paggamit kung saan ang tawag namin sa kalat-kalat na ini-index. 2042 01:30:05,340 --> 01:30:07,340 Kalat-kalat na index ay ang mga kakayahan upang makabuo ng 2043 01:30:07,340 --> 01:30:10,850 isang index na ay hindi kinakailangang maglaman ang bawat isang item sa talahanayan. 2044 01:30:10,850 --> 01:30:11,470 At bakit hindi? 2045 01:30:11,470 --> 01:30:14,540 Dahil ang mga katangiang iyon ay pagiging na-index na ay hindi umiiral sa bawat item. 2046 01:30:14,540 --> 01:30:16,460 >> Kaya sa mga partikular na gamitin ang kaso, ako sinasabi, 2047 01:30:16,460 --> 01:30:19,240 alam mo kung ano, ako pagpunta sa lumikha ng isang katangian na tinatawag Award. 2048 01:30:19,240 --> 01:30:22,970 At ako pagpunta upang bigyan ang bawat user na may isang award na attribute. 2049 01:30:22,970 --> 01:30:25,950 Ang mga gumagamit na hindi magkaroon ng parangal ay hindi pagpunta sa may katangiang iyon. 2050 01:30:25,950 --> 01:30:27,800 Kaya kapag gumawa ako ng index, ang mga gumagamit lamang 2051 01:30:27,800 --> 01:30:28,960 na pagpunta sa ipakita up sa index ay 2052 01:30:28,960 --> 01:30:31,050 ang mga na talagang may won awards. 2053 01:30:31,050 --> 01:30:34,440 Kaya na ang isang mahusay na paraan upang ma upang lumikha ng mga filter sa mga index na 2054 01:30:34,440 --> 01:30:40,580 ay tunay, tunay pumipili na hindi kung index ang buong table. 2055 01:30:40,580 --> 01:30:43,050 >> Kaya kami ay nakakakuha ng mababa sa oras dito. 2056 01:30:43,050 --> 01:30:49,190 Pupunta ako sa sige at laktawan out at laktawan ang sitwasyong ito. 2057 01:30:49,190 --> 01:30:52,625 Makipag-usap nang kaunti about-- 2058 01:30:52,625 --> 01:30:54,460 >> Madla: Maaari ko bang hilingin ang isang mabilis na tanong? 2059 01:30:54,460 --> 01:30:56,722 Ang isa ay sumulat ng mabigat? 2060 01:30:56,722 --> 01:30:57,680 RICK Houlihan: Ano? 2061 01:30:57,680 --> 01:30:58,596 Madla: Magsulat mabigat. 2062 01:30:58,596 --> 01:31:01,270 RICK Houlihan: Sumulat mabigat. 2063 01:31:01,270 --> 01:31:03,460 Hayaan akong makita. 2064 01:31:03,460 --> 01:31:06,220 >> Madla: O ay na hindi isang bagay na maaari mo lamang 2065 01:31:06,220 --> 01:31:08,809 boses sa sa isang bagay ng segundo? 2066 01:31:08,809 --> 01:31:10,850 RICK Houlihan: Pumunta kami sa pamamagitan ng mga sitwasyon sa pagboto. 2067 01:31:10,850 --> 01:31:11,670 Ito ay hindi na masamang. 2068 01:31:11,670 --> 01:31:14,580 Ka guys ay may ilang mga minuto? 2069 01:31:14,580 --> 01:31:15,860 SIGE. 2070 01:31:15,860 --> 01:31:17,890 >> Kaya makikita namin makipag-usap tungkol sa pagboto. 2071 01:31:17,890 --> 01:31:20,250 Kaya real time sa pagboto, kami ay mga kinakailangan para sa pagboto. 2072 01:31:20,250 --> 01:31:25,250 Kinakailangan ay na pinapayagan namin sa bawat tao na bumoto nang isang beses lamang. 2073 01:31:25,250 --> 01:31:28,060 Gusto naming walang tao para ma upang baguhin ang kanilang boto. 2074 01:31:28,060 --> 01:31:31,045 Gusto naming real-time ng pagsasama-sama at analytics para sa demographics 2075 01:31:31,045 --> 01:31:34,210 na kami ay magiging nagpapakita sa mga gumagamit sa site. 2076 01:31:34,210 --> 01:31:35,200 >> Mag-isip ng ganitong sitwasyon. 2077 01:31:35,200 --> 01:31:37,550 Kami ay isang pulutong ng mga katotohanan TV ay nagpapakita kung saan ang mga ito ay 2078 01:31:37,550 --> 01:31:38,960 paggawa ng mga tumpak na uri ng mga bagay-bagay. 2079 01:31:38,960 --> 01:31:41,584 Kaya maaari mong isipin ang sitwasyon, kami ay may milyon-milyong at milyon-milyong 2080 01:31:41,584 --> 01:31:43,959 ng mga dalagitang doon sa kanilang mga cell phone 2081 01:31:43,959 --> 01:31:46,250 at pagboto, at pagboto, at pagboto para sa sino man sila 2082 01:31:46,250 --> 01:31:48,610 mahanap na ang pinaka-popular. 2083 01:31:48,610 --> 01:31:50,830 Kaya ang mga ito ay ilan sa mga kinakailangan namin tumakbo out. 2084 01:31:50,830 --> 01:31:52,990 >> At kaya ang unang kumuha ng sa paglutas ng problemang ito 2085 01:31:52,990 --> 01:31:55,090 ay upang bumuo ng isang napaka-simpleng application. 2086 01:31:55,090 --> 01:31:56,490 Kaya Mayroon akong app na ito. 2087 01:31:56,490 --> 01:31:57,950 Mayroon akong ilang mga botante out doon. 2088 01:31:57,950 --> 01:31:59,980 Dumating sila, sila ay pindutin ang app pagboto. 2089 01:31:59,980 --> 01:32:03,440 Mayroon akong ilang mga talahanayan raw boto Kukunin ko na lang tambakan ng mga boto sa. 2090 01:32:03,440 --> 01:32:05,780 Kukunin ko ang ilang mga pinagsama-samang boto table na 2091 01:32:05,780 --> 01:32:09,490 ang gagawin ng aking analytics at demograpiko, at kami ay ilagay ang lahat ng ito sa doon. 2092 01:32:09,490 --> 01:32:11,420 >> At ito ay mahusay. 2093 01:32:11,420 --> 01:32:12,332 Maganda ang buhay. 2094 01:32:12,332 --> 01:32:15,040 Buhay mabuti hanggang sa nakita namin out na may laging lamang ng isa o dalawang 2095 01:32:15,040 --> 01:32:16,879 tao na sikat sa isang halalan. 2096 01:32:16,879 --> 01:32:19,420 Mayroon lamang ng isa o dalawang mga bagay-bagay na ang mga tao talagang nagmamalasakit tungkol sa. 2097 01:32:19,420 --> 01:32:22,340 At kung ikaw ay boboto sa scale, ang lahat ng isang biglaang ako 2098 01:32:22,340 --> 01:32:26,360 magiging pagmamartilyo ang impiyerno sa labas ng dalawang kandidato, ang isa o dalawang kandidato. 2099 01:32:26,360 --> 01:32:29,390 Ang isang limitadong bilang ng mga item mga tao na mahanap na maging popular. 2100 01:32:29,390 --> 01:32:31,710 >> Ito ay hindi isang magandang pattern disenyo. 2101 01:32:31,710 --> 01:32:33,549 Ito ay talagang isang napakasama pattern disenyo 2102 01:32:33,549 --> 01:32:36,340 dahil ito ay lumilikha ng eksakto kung ano ang aming usapan tungkol sa kung saan ay hot keys. 2103 01:32:36,340 --> 01:32:38,960 Hot key ay isang bagay na hindi namin gusto. 2104 01:32:38,960 --> 01:32:40,470 >> Kaya paano namin ayusin na? 2105 01:32:40,470 --> 01:32:47,640 At talagang, ang mga paraan upang ayusin ito ay sa pamamagitan ng pagkuha ng mga kandidato timba 2106 01:32:47,640 --> 01:32:51,490 at para sa bawat kandidato na namin, kami ay pagpunta upang isama ang isang random na halaga, 2107 01:32:51,490 --> 01:32:54,192 isang bagay na alam natin, random halaga sa pagitan ng isa at 100, 2108 01:32:54,192 --> 01:32:56,620 sa pagitan ng 100 at 1000, o sa pagitan ng isa at 1000, 2109 01:32:56,620 --> 01:32:59,940 subalit maraming mga random na mga halaga na nais mong ikakabit papunta sa dulo ng kandidatong iyon. 2110 01:32:59,940 --> 01:33:01,330 >> At kung ano ang ko talagang gawin pagkatapos? 2111 01:33:01,330 --> 01:33:05,830 Kung gumagamit ako ng kandidato ID bilang mga bucket sa pinagsama-samang boto, 2112 01:33:05,830 --> 01:33:08,780 kung nagdagdag ako ng isang random number sa dulo ng mga iyon, 2113 01:33:08,780 --> 01:33:12,000 Na aking nilikha ngayon 10 buckets, isang daang mga bucket, ang isang libong mga bucket 2114 01:33:12,000 --> 01:33:14,160 na ako ng pagsasama-sama ng mga boto sa kabuuan. 2115 01:33:14,160 --> 01:33:18,030 >> Kaya ko bang milyon-milyong, at milyon-milyon, at milyon-milyong mga talaan na pumapasok 2116 01:33:18,030 --> 01:33:22,050 para sa mga kandidato, ngayon ako nagkakalat mga boto sa buong Candidate A_1 2117 01:33:22,050 --> 01:33:24,630 sa pamamagitan ng Kandidato A_100, dahil sa bawat oras na ang isang boto ay dumating sa, 2118 01:33:24,630 --> 01:33:26,530 Ako sa pagbuo ng isang random halaga sa pagitan ng isa at 100. 2119 01:33:26,530 --> 01:33:29,446 Ako tacking ito papunta sa dulo ng kandidato ng taong iyon ang pagboto para sa. 2120 01:33:29,446 --> 01:33:31,120 Ako paglalaglag ito sa na bucket. 2121 01:33:31,120 --> 01:33:33,910 >> Ngayon sa likuran, alam ko na nakuha ko sa isang daang mga bucket. 2122 01:33:33,910 --> 01:33:36,350 Kaya kapag gusto ko na sige at pinagsasama-sama ang mga boto, 2123 01:33:36,350 --> 01:33:38,244 Nabasa ko mula sa lahat ng mga bucket. 2124 01:33:38,244 --> 01:33:39,160 Kaya ko sige at idagdag. 2125 01:33:39,160 --> 01:33:42,410 At pagkatapos ay ako ang scatter magtipon kung saan ako pumunta at sabihin hey, 2126 01:33:42,410 --> 01:33:45,399 alam mo kung ano, key kandidato na ito ni puwang ay higit sa isang daang mga bucket. 2127 01:33:45,399 --> 01:33:47,940 Pupunta ako upang tipunin ang lahat ng Binoboto mula sa mga daang bucket. 2128 01:33:47,940 --> 01:33:49,981 Pupunta ako sa pinagsama-samang ang mga ito at ako pagpunta sa sabihin, 2129 01:33:49,981 --> 01:33:53,830 Candidate A ay mayroon na ngayong kabuuang bilang ng boto ng mga x. 2130 01:33:53,830 --> 01:33:55,690 >> Ngayon parehong mga write Query at ang read query 2131 01:33:55,690 --> 01:33:58,160 ay mabuti ipinamamahagi dahil ako ng sulat sa kabuuan 2132 01:33:58,160 --> 01:34:00,320 at ako pagbabasa sa daan-daang mga susi. 2133 01:34:00,320 --> 01:34:03,500 Hindi ko na pagsulat at pagbabasa sa kabuuan ng isa key na ngayon. 2134 01:34:03,500 --> 01:34:04,950 Kaya na ang isang mahusay na pattern. 2135 01:34:04,950 --> 01:34:08,090 >> Ito ay tunay na marahil ang isa sa pinaka mahalagang mga disenyo 2136 01:34:08,090 --> 01:34:10,420 mga pattern para sa scale sa NoSQL. 2137 01:34:10,420 --> 01:34:14,470 Makikita mo ang ganitong uri ng design pattern sa bawat lasa. 2138 01:34:14,470 --> 01:34:19,100 MongoDB, DynamoDB, ito ay hindi matter, namin ang lahat ng may sa gawin ito. 2139 01:34:19,100 --> 01:34:21,840 Dahil kapag ikaw ay pakikitungo may mga malaking aggregations, 2140 01:34:21,840 --> 01:34:26,650 ikaw ay may upang malaman ng isang paraan upang ikakalat ang mga ito sa labas sa kabila bucket. 2141 01:34:26,650 --> 01:34:29,512 Kaya ito ay ang paraan na gawin mo iyon. 2142 01:34:29,512 --> 01:34:31,220 Lahat ng karapatan, kaya kung ano ang ikaw ay gumagawa ngayon 2143 01:34:31,220 --> 01:34:35,252 ay ikaw ay Trading off read gastos para sa write kakayahang sumukat. 2144 01:34:35,252 --> 01:34:37,085 Ang gastos ng aking basahin ay isang maliit na mas kumplikadong 2145 01:34:37,085 --> 01:34:40,220 at kailangan kong pumunta basahin mula sa isang daang mga bucket halip ng isa. 2146 01:34:40,220 --> 01:34:41,310 Ngunit ako magagawang magsulat. 2147 01:34:41,310 --> 01:34:44,860 At ang aking throughput, ang aking write throughput ay hindi kapani-paniwala. 2148 01:34:44,860 --> 01:34:49,450 Kaya ito ay karaniwang isang mahalagang pamamaraan para sa pagsusukat DynamoDB, 2149 01:34:49,450 --> 01:34:51,350 o anumang NoSQL database para sa mga bagay. 2150 01:34:51,350 --> 01:34:53,824 2151 01:34:53,824 --> 01:34:55,240 Kaya naisip namin kung paano upang masukat ang mga ito. 2152 01:34:55,240 --> 01:34:56,930 At naisip namin kung paano sa puksain ang aming hot keys. 2153 01:34:56,930 --> 01:34:57,820 At ito ay walang katotohanan. 2154 01:34:57,820 --> 01:34:58,960 At nakuha namin ang ganda ng system. 2155 01:34:58,960 --> 01:35:02,043 At ito ay nagbigay sa amin napaka-tama sa pagboto dahil kami ay may record na boto de-manloko. 2156 01:35:02,043 --> 01:35:03,130 Ito ay binuo sa DynamoDB. 2157 01:35:03,130 --> 01:35:05,380 Usapan natin ang tungkol kondisyong karapatan. 2158 01:35:05,380 --> 01:35:08,170 >> Kapag ang isang botante sa, naglalagay isang isingit sa table, 2159 01:35:08,170 --> 01:35:11,220 ipasok ang mga ito sa kanilang mga botante ID, kung sila ay subukan upang magsingit ng isa pang boto, 2160 01:35:11,220 --> 01:35:13,320 Gagawin ko ang isang kondisyon write. 2161 01:35:13,320 --> 01:35:16,960 Sabihin lamang isulat ito kung ito ay hindi umiiral. 2162 01:35:16,960 --> 01:35:19,270 Kaya sa lalong madaling nakikita ko na hit na boto sa table, 2163 01:35:19,270 --> 01:35:20,460 walang ibang tao ay magiging maaaring ilagay ang kanilang mga boto sa. 2164 01:35:20,460 --> 01:35:21,634 At iyan ay hindi kapani-paniwala. 2165 01:35:21,634 --> 01:35:23,550 At kami ay incrementing aming mga kandidato counter. 2166 01:35:23,550 --> 01:35:25,466 At ang aming ginagawa sa aming mga demograpiko at ang lahat na. 2167 01:35:25,466 --> 01:35:29,110 Ngunit ano ang mangyayari kung ang aking application ay bumaba sa ibabaw? 2168 01:35:29,110 --> 01:35:31,350 Ngayon ang lahat ng isang biglaang mga boto ay pumapasok, at ako 2169 01:35:31,350 --> 01:35:34,840 hindi alam kung sila ay nakakakuha naproseso sa aking analytics at demograpiko 2170 01:35:34,840 --> 01:35:36,040 anymore. 2171 01:35:36,040 --> 01:35:38,462 At kapag ang application dumating back up, kung paano 2172 01:35:38,462 --> 01:35:41,420 ang impiyerno ko malalaman kung ano ang mayroon boto na-proseso at kung saan ako magsisimula? 2173 01:35:41,420 --> 01:35:44,530 >> Kaya ito ay isang tunay na problema kapag ikaw simulan upang tumingin sa ganitong uri ng sitwasyon. 2174 01:35:44,530 --> 01:35:45,571 At paano namin malutas na? 2175 01:35:45,571 --> 01:35:48,070 Malutas namin ito sa kung ano ang aming tumawag DynamoDB Stream. 2176 01:35:48,070 --> 01:35:53,470 Streams ay iniutos ng isang oras at partitioned pagbabago log ng bawat access 2177 01:35:53,470 --> 01:35:55,700 sa talahanayan, ang bawat isulat access sa mga table. 2178 01:35:55,700 --> 01:35:58,810 Ang anumang data na nakasulat sa na talahanayan ay nagpapakita ng hanggang sa stream. 2179 01:35:58,810 --> 01:36:01,815 >> Ito ay karaniwang isang 24 na oras na queue. 2180 01:36:01,815 --> 01:36:03,690 Item pindutin ang stream, sila nakatira sa loob ng 24 na oras. 2181 01:36:03,690 --> 01:36:05,990 Sila ay maaaring basahin ng maraming beses. 2182 01:36:05,990 --> 01:36:09,400 Ginagarantiya upang maihatid lamang ng isang beses sa stream, 2183 01:36:09,400 --> 01:36:11,180 mabasa n bilang ng beses. 2184 01:36:11,180 --> 01:36:14,910 Kaya gayunpaman maraming mga proseso na nais mong ubusin na data, maaari mong tunawin. 2185 01:36:14,910 --> 01:36:16,350 Ito ay lilitaw sa bawat update. 2186 01:36:16,350 --> 01:36:18,455 Bawat write ay lamang lumitaw nang isang beses sa stream. 2187 01:36:18,455 --> 01:36:20,621 Kaya hindi mo na kailangang mag-alala tungkol sa pagpoproseso ng ito ng dalawang beses 2188 01:36:20,621 --> 01:36:22,500 mula sa parehong proseso. 2189 01:36:22,500 --> 01:36:25,350 >> Mahigpit na ito ay iniutos sa bawat item. 2190 01:36:25,350 --> 01:36:28,180 Kapag sinabi naming oras iniutos at partitioned, 2191 01:36:28,180 --> 01:36:30,680 makikita mo ang bawat pagkahati sa stream. 2192 01:36:30,680 --> 01:36:33,169 Makikita mo na mga aytem, ​​mga update sa order. 2193 01:36:33,169 --> 01:36:35,210 Hindi namin ay guaranteeing sa stream na kayo 2194 01:36:35,210 --> 01:36:40,240 pagpunta upang makakuha ng bawat transaksyon sa pagkakasunud-sunod sa kabuuan item. 2195 01:36:40,240 --> 01:36:42,440 >> Kaya batis ay idempotent. 2196 01:36:42,440 --> 01:36:44,037 Huwag namin ang lahat ng kung ano ang ibig sabihin idempotent? 2197 01:36:44,037 --> 01:36:46,620 Idempotent nangangahulugan na maaari mong gawin ito loob, at higit, at sa muli. 2198 01:36:46,620 --> 01:36:48,200 Ang resulta ay magiging pareho. 2199 01:36:48,200 --> 01:36:49,991 >> Stream ay idempotent, ngunit mayroon sila upang maging 2200 01:36:49,991 --> 01:36:54,860 play mula sa panimulang punto, kung saan ninyo pumili, sa dulo, 2201 01:36:54,860 --> 01:36:57,950 o hindi sila ay magreresulta sa parehong halaga. 2202 01:36:57,950 --> 01:36:59,727 >> Parehong bagay sa MongoDB. 2203 01:36:59,727 --> 01:37:01,560 MongoDB ay isang tayuan tinatawag nila ang oplog. 2204 01:37:01,560 --> 01:37:04,140 Ito ay ang eksaktong parehong tayuan. 2205 01:37:04,140 --> 01:37:06,500 Maraming mga database NoSQL magkaroon ng ganitong tayuan. 2206 01:37:06,500 --> 01:37:08,790 Ginagamit nila ito upang gawin ang mga bagay tulad ng pagtitiklop, na 2207 01:37:08,790 --> 01:37:10,475 ay kung ano mismo ang ginagawa namin sa batis. 2208 01:37:10,475 --> 01:37:12,350 Madla: Maaari isang erehe tanong, ngunit ikaw 2209 01:37:12,350 --> 01:37:13,975 makipag-usap tungkol apps ginagawa down ng isang iba pa. 2210 01:37:13,975 --> 01:37:16,089 Sigurado garantisadong stream na hindi kailanman pumunta down marahil? 2211 01:37:16,089 --> 01:37:18,630 RICK Houlihan: Oo, batis ay garantisadong hindi kailanman pumunta down. 2212 01:37:18,630 --> 01:37:21,040 Pangasiwaan namin ang infrastructure sa likod. awtomatikong stream 2213 01:37:21,040 --> 01:37:22,498 lumawak sa kanilang auto scaling group. 2214 01:37:22,498 --> 01:37:25,910 Kami ay pumunta sa pamamagitan ng isang maliit na bit tungkol sa kung ano ang mangyayari. 2215 01:37:25,910 --> 01:37:30,060 >> Hindi ko dapat sabihin na ang mga ito ay hindi garantisadong hindi kailanman pumunta pababa. 2216 01:37:30,060 --> 01:37:33,110 Ang mga elemento ay garantisadong na lumitaw sa mga stream. 2217 01:37:33,110 --> 01:37:36,740 At ang stream ay maa-access. 2218 01:37:36,740 --> 01:37:40,580 Kaya kung ano ang napupunta down o lumapit sa likod up, na ang mangyayari sa ilalim. 2219 01:37:40,580 --> 01:37:43,844 Ito covers-- ito ay OK. 2220 01:37:43,844 --> 01:37:46,260 Lahat ng karapatan, kaya makakakuha ka ng iba't-ibang view ng uri ng off ang screen. 2221 01:37:46,260 --> 01:37:51,040 Ang mga uri ng view na mahalaga sa isang karaniwang programmer ay, kung ano ang ito? 2222 01:37:51,040 --> 01:37:52,370 Nakukuha ko ang lumang view. 2223 01:37:52,370 --> 01:37:55,630 Kapag ang isang pag-update ay pinindot niya ang table, makikita ito itulak ang mga lumang tanawin ng stream 2224 01:37:55,630 --> 01:38:02,070 kaya maaaring ilagay sa archive ng data, o baguhin control, baguhin ang pagkilala, pagbabago 2225 01:38:02,070 --> 01:38:03,600 management. 2226 01:38:03,600 --> 01:38:07,160 >> Ang bagong imahe, kung ano ito ngayon pagkatapos ng ang update, iyon ang isa pang uri ng view 2227 01:38:07,160 --> 01:38:07,660 maaari kang makakuha. 2228 01:38:07,660 --> 01:38:09,660 Maaari kang makakuha ng parehong luma at bagong larawan. 2229 01:38:09,660 --> 01:38:10,660 Siguro gusto ko sa kanila pareho. 2230 01:38:10,660 --> 01:38:11,790 Gusto kong makita kung ano iyon. 2231 01:38:11,790 --> 01:38:13,290 Gusto kong makita kung ano ang nagbago ito sa. 2232 01:38:13,290 --> 01:38:15,340 >> Mayroon akong isang uri ng pagsunod ng proseso na tumatakbo. 2233 01:38:15,340 --> 01:38:17,430 Ito mga pangangailangan upang i-verify na kapag nagbago ang mga bagay-bagay, 2234 01:38:17,430 --> 01:38:21,840 na ang mga ito sa loob ng ilang mga limitasyon o sa loob ng ilang mga parameter. 2235 01:38:21,840 --> 01:38:23,840 >> At pagkatapos ay marahil ko lamang kailangan malaman kung ano ang nagbago. 2236 01:38:23,840 --> 01:38:26,240 Wala akong pakialam kung ano ang item nagbago. 2237 01:38:26,240 --> 01:38:28,580 Hindi ko kailangan sa kailangan upang malaman ano ang mga katangian nagbago. 2238 01:38:28,580 --> 01:38:30,882 Kailangan ko lang malaman na ang mga bagay ay hinawakan. 2239 01:38:30,882 --> 01:38:33,340 Kaya ito ang mga uri ng mga tanawin na makakuha ka off ang stream 2240 01:38:33,340 --> 01:38:35,960 at maaari kang makipag-ugnay sa. 2241 01:38:35,960 --> 01:38:37,840 >> Ang application na consumes ang stream, 2242 01:38:37,840 --> 01:38:39,298 ito ay uri ng ang paraan na ito ay gumagana. 2243 01:38:39,298 --> 01:38:42,570 DynamoDB client hilingin na itulak ang data sa mga mesa. 2244 01:38:42,570 --> 01:38:44,750 Streams deploy sa kung ano ang tawag namin shards. 2245 01:38:44,750 --> 01:38:47,380 Shards ay naka-scale malaya ng table. 2246 01:38:47,380 --> 01:38:50,660 Hindi nila pumila ganap sa partisyon ng iyong talahanayan. 2247 01:38:50,660 --> 01:38:52,540 At ang dahilan kung bakit dahil sila line up 2248 01:38:52,540 --> 01:38:55,430 sa kakayahan, ang kasalukuyang kapasidad ng table. 2249 01:38:55,430 --> 01:38:57,600 >> Lumawak ang mga ito sa kanilang mga sariling auto scaling group, 2250 01:38:57,600 --> 01:39:00,800 at simulan nila upang paikutin out depende sa kung gaano karaming magsusulat ay darating sa, 2251 01:39:00,800 --> 01:39:03,090 kung gaano karaming mga reads-- talagang ito ay nagsusulat. 2252 01:39:03,090 --> 01:39:05,820 Walang reads-- ngunit kung paano maraming magsusulat ay darating in. 2253 01:39:05,820 --> 01:39:08,200 >> At pagkatapos ay sa likod end, kami ay kung ano ang aming 2254 01:39:08,200 --> 01:39:11,390 tumawag sa isang KCL, o Kinesis Client Library. 2255 01:39:11,390 --> 01:39:19,190 Kinesis ay isang data stream processing teknolohiya mula sa Amazon. 2256 01:39:19,190 --> 01:39:22,040 At ang mga batis ay binuo sa mga iyon. 2257 01:39:22,040 --> 01:39:25,670 >> Kaya gamitin mo pinagana ang isang KCL application na basahin ang mga stream. 2258 01:39:25,670 --> 01:39:28,752 Ang Kinesis Client Library talagang namamahala sa mga manggagawa para sa iyo. 2259 01:39:28,752 --> 01:39:30,460 At ito rin ay ilang kagiliw-giliw na mga bagay-bagay. 2260 01:39:30,460 --> 01:39:35,630 Ito ay lumikha ng ilang mga talahanayan up sa iyong DynamoDB tablespace 2261 01:39:35,630 --> 01:39:38,410 upang subaybayan kung aling mga item ay na-proseso. 2262 01:39:38,410 --> 01:39:41,190 Kaya sa ganitong paraan na ito ay bumaba sa likod, kung ito ay bumaba sa loob at lumapit at nakakakuha 2263 01:39:41,190 --> 01:39:45,570 nakatayo back up, maaari itong matukoy kung saan ay ito sa pagproseso ng stream. 2264 01:39:45,570 --> 01:39:48,360 >> Iyon ay lubhang mahalaga kapag ikaw ay pakikipag-usap tungkol sa pagtitiklop. 2265 01:39:48,360 --> 01:39:50,350 Kailangan kong malaman kung ano ang ay na-proseso ang data 2266 01:39:50,350 --> 01:39:52,810 at kung ano ang data ay hindi pa na-proseso. 2267 01:39:52,810 --> 01:39:57,380 Kaya ang KCL library para sa mga daloy ay magbibigay sa iyo ng isang pulutong ng mga na pag-andar. 2268 01:39:57,380 --> 01:39:58,990 Ito ay tumatagal ng pag-aalaga ng lahat ng mga gawaing-bahay. 2269 01:39:58,990 --> 01:40:01,140 Ito ay nakatayo up ang isang manggagawa para sa bawat share. 2270 01:40:01,140 --> 01:40:04,620 Ito ay lumilikha ng isang administrative talahanayan para sa bawat share, para sa bawat worker. 2271 01:40:04,620 --> 01:40:07,560 At bilang mga fire manggagawa, mapanatili nila ang mga talahanayan 2272 01:40:07,560 --> 01:40:10,510 upang malaman mo ang ulat na ito Binasa at naproseso. 2273 01:40:10,510 --> 01:40:13,850 At pagkatapos na ang paraan kung ang proseso namatay at nag-online sa likod, 2274 01:40:13,850 --> 01:40:17,940 maaari itong ipagpatuloy ang karapatan kung saan ito kinuha off. 2275 01:40:17,940 --> 01:40:20,850 >> Kaya ito ay ginagamit namin para sa cross-rehiyon pagtitiklop. 2276 01:40:20,850 --> 01:40:24,680 Ang isang pulutong ng mga customer ang mga pangangailangan upang ilipat ang data o mga bahagi ng kanilang mga talahanayan ng data 2277 01:40:24,680 --> 01:40:25,920 paligid sa iba't ibang mga rehiyon. 2278 01:40:25,920 --> 01:40:29,230 Mayroong siyam na mga rehiyon sa buong mundo. 2279 01:40:29,230 --> 01:40:32,100 Kaya ito ay maaaring maging isang need-- ako doon Maaaring magkaroon ng mga gumagamit sa Asya, ang mga gumagamit 2280 01:40:32,100 --> 01:40:34,150 sa East Coast ng Estados Unidos. 2281 01:40:34,150 --> 01:40:38,980 Sila ay may iba't ibang mga data na Kailangang ma lokal na ibinahagi. 2282 01:40:38,980 --> 01:40:42,510 At siguro ang isang user ay lilipad mula sa Asya sa ibabaw sa Estados Unidos, 2283 01:40:42,510 --> 01:40:45,020 at gusto kong magtiklop ang kanyang mga data sa kanya. 2284 01:40:45,020 --> 01:40:49,340 Kaya kapag siya ay makakakuha ng off ang eroplano, siya ay isang mahusay na karanasan sa paggamit ng kanyang mobile app. 2285 01:40:49,340 --> 01:40:52,360 >> Maaari mong gamitin ang cross-rehiyon pagtitiklop library upang gawin ito. 2286 01:40:52,360 --> 01:40:55,730 Talaga kami ibinigay ng dalawang mga teknolohiya. 2287 01:40:55,730 --> 01:40:59,400 One ay isang console application maaari kang tumayo sa iyong sariling EC2 halimbawa. 2288 01:40:59,400 --> 01:41:01,240 Ito ay nagpapatakbo ng purong pagtitiklop. 2289 01:41:01,240 --> 01:41:02,720 At pagkatapos ay ibinigay namin sa inyo ang library. 2290 01:41:02,720 --> 01:41:06,070 Ang aklatan ay maaari mong gamitin upang bumuo ng ng iyong sariling mga application kung ikaw 2291 01:41:06,070 --> 01:41:10,740 nais na gawin nakatutuwang mga bagay na may na data-- filter, ginagaya lamang ng bahagi ng mga ito, 2292 01:41:10,740 --> 01:41:14,120 i-rotate ang data, ilipat ito sa isang iba't-ibang mga talahanayan, kaya sa at iba pa. 2293 01:41:14,120 --> 01:41:18,700 2294 01:41:18,700 --> 01:41:20,520 Kaya na uri ng kung ano na kamukha. 2295 01:41:20,520 --> 01:41:23,690 >> DynamoDB Streams maaaring maging proseso sa pamamagitan ng kung ano ang tawag namin sa Lambda. 2296 01:41:23,690 --> 01:41:27,394 Binanggit namin ng kaunti tungkol sa event driven architecture application. 2297 01:41:27,394 --> 01:41:28,810 Lambda ay isang pangunahing bahagi ng mga iyon. 2298 01:41:28,810 --> 01:41:32,840 Lambda ay code na apoy on demand bilang tugon sa isang partikular na kaganapan. 2299 01:41:32,840 --> 01:41:36,020 Isa sa mga pangyayaring iyon ay maaaring isang record na lumalabas sa stream. 2300 01:41:36,020 --> 01:41:39,100 Kung ang isang record ay lilitaw sa stream, kami ay tumawag ito Java function. 2301 01:41:39,100 --> 01:41:44,980 Well, ito ay ang JavaScript, at Lambda Sinusuportahan Node.js, Java, Python, 2302 01:41:44,980 --> 01:41:47,820 at malapit nang suportahan iba pang mga wika pati na rin. 2303 01:41:47,820 --> 01:41:50,940 At makasapat upang sabihin, ito ay purong code. 2304 01:41:50,940 --> 01:41:53,610 isulat Sa Java, tukuyin ang isang klase. 2305 01:41:53,610 --> 01:41:55,690 Itulak mo ang jar up sa Lambda. 2306 01:41:55,690 --> 01:42:00,200 At pagkatapos mong tukuyin kung aling mga klase na tumawag sa mga tugon sa na kaganapan. 2307 01:42:00,200 --> 01:42:04,770 At pagkatapos ay ang infrastructure Lambda sa likod na tatakbo na code. 2308 01:42:04,770 --> 01:42:06,730 >> Maaaring iproseso ang code na iyon talaan off ang stream. 2309 01:42:06,730 --> 01:42:08,230 Maaari itong gawin anumang bagay na ito ay nais sa mga ito. 2310 01:42:08,230 --> 01:42:11,650 Sa partikular na halimbawa kung lahat tayo talagang ginagawa ng pag-log ang mga katangian. 2311 01:42:11,650 --> 01:42:13,480 Ngunit ito ay code lamang. 2312 01:42:13,480 --> 01:42:15,260 Code ay maaaring gumawa ng kahit ano, tama? 2313 01:42:15,260 --> 01:42:16,600 >> Kaya maaari mong i-rotate na data. 2314 01:42:16,600 --> 01:42:18,160 Maaari kang lumikha ng mga hinangong view. 2315 01:42:18,160 --> 01:42:21,160 Kung ito ay isang dokumento na istraktura, maaari mong patagin ang istraktura. 2316 01:42:21,160 --> 01:42:24,300 Maaari kang lumikha ng kahaliling mga index. 2317 01:42:24,300 --> 01:42:27,100 Lahat ng uri ng bagay na maaari mong gawin sa mga DynamoDB Stream. 2318 01:42:27,100 --> 01:42:28,780 >> At talagang, na kung ano na kamukha. 2319 01:42:28,780 --> 01:42:29,940 Kaya makakakuha ka ng mga update darating in. 2320 01:42:29,940 --> 01:42:31,190 Sila ay darating off ang string. 2321 01:42:31,190 --> 01:42:32,720 Ang mga ito ay basahin sa pamamagitan ng Lambda function. 2322 01:42:32,720 --> 01:42:37,480 Sila ay umiikot ang data at pagtulak ito sa loob ng mga hinalaw na mga talahanayan, 2323 01:42:37,480 --> 01:42:42,200 aabiso panlabas na mga sistema ng pagbabago, at pagtulak ng data sa ElastiCache. 2324 01:42:42,200 --> 01:42:45,900 >> Usapan natin ang tungkol sa kung paano ilagay ang cache sa harap ng database para sa mga benta na 2325 01:42:45,900 --> 01:42:46,450 sitwasyon. 2326 01:42:46,450 --> 01:42:50,049 Well kung ano ang mangyayari kung ako i-update ang paglalarawan ng item? 2327 01:42:50,049 --> 01:42:52,340 Well, kung ako ay isang Lambda function na tumatakbo sa table na, 2328 01:42:52,340 --> 01:42:55,490 kung ako i-update ang paglalarawan ng item, makikita ito pick up ang mga record off ang stream, 2329 01:42:55,490 --> 01:42:58,711 at ia-update nito ang ElastiCache halimbawa sa mga bagong data. 2330 01:42:58,711 --> 01:43:00,460 Kaya na ang isang pulutong ng mga kung ano ang ginagawa namin sa Lambda. 2331 01:43:00,460 --> 01:43:02,619 Ito ay pandikit code, konektor. 2332 01:43:02,619 --> 01:43:04,410 At ito ang tunay na nagbibigay ng kakayahan upang ilunsad 2333 01:43:04,410 --> 01:43:07,930 at upang patakbuhin ang napaka-komplikadong mga aplikasyon walang isang dedikado server 2334 01:43:07,930 --> 01:43:10,371 infrastructure, na kung saan ay talagang cool. 2335 01:43:10,371 --> 01:43:13,100 >> Kaya sabihin bumalik sa aming real-time architecture pagboto. 2336 01:43:13,100 --> 01:43:17,984 Ito ang bago at pinahusay na gamit ang aming batis at KCL pinagana application. 2337 01:43:17,984 --> 01:43:20,150 Kapareho ng mga bago, maaari naming humawak ng anumang laki ng halalan. 2338 01:43:20,150 --> 01:43:21,100 Tulad namin ito. 2339 01:43:21,100 --> 01:43:24,770 Kami ay gumagawa out scatter nangangalap sa kabuuan ng maramihang mga bucket. 2340 01:43:24,770 --> 01:43:26,780 Mayroon kami ng maasahin locking nangyayari. 2341 01:43:26,780 --> 01:43:30,192 Maaari naming panatilihin ang aming mga botante mula sa pagbabago ng kanilang mga boto. 2342 01:43:30,192 --> 01:43:31,400 Sila ay maaari lamang bumoto nang isang beses lamang. 2343 01:43:31,400 --> 01:43:32,880 Ito ay walang katotohanan. 2344 01:43:32,880 --> 01:43:35,895 Real-time kasalanan pagpapaubaya, scalable pagsasama-sama ngayon. 2345 01:43:35,895 --> 01:43:38,270 Kung ang mga bagay ay bumaba sa paglipas, ito alam kung saan upang i-restart ang sarili 2346 01:43:38,270 --> 01:43:41,300 pagdating back up dahil kami ay gumagamit ng KCL app. 2347 01:43:41,300 --> 01:43:45,700 At pagkatapos ay maaari naming ring gamitin na KCL application upang itulak data sa labas 2348 01:43:45,700 --> 01:43:48,820 na redshift para sa iba pang app analytics, o paggamit 2349 01:43:48,820 --> 01:43:51,990 ang nababanat MapReduce na tumakbo real-time streaming off aggregations 2350 01:43:51,990 --> 01:43:53,180 ng data na iyon. 2351 01:43:53,180 --> 01:43:55,480 >> Kaya ito ang mga bagay na aming hindi uusapang tungkol magkano. 2352 01:43:55,480 --> 01:43:57,375 Ngunit ang mga ito ng karagdagang mga teknolohiya na dumating 2353 01:43:57,375 --> 01:44:00,310 upang dalhin kapag naghahanap ka sa ganitong mga uri ng mga sitwasyon. 2354 01:44:00,310 --> 01:44:03,160 >> Lahat ng karapatan, kaya na ang tungkol sa analytics na may DynamoDB Stream. 2355 01:44:03,160 --> 01:44:05,340 Maaari mong mangolekta ng de-lokohin data, gawin ang lahat ng uri 2356 01:44:05,340 --> 01:44:09,490 ng ganda ng mga bagay-bagay, pinagsama-samang data sa memory, lumikha ng mga hinangong mga talahanayan. 2357 01:44:09,490 --> 01:44:13,110 Iyan ay isang malaking pagkakataon ng paggamit na ang isang pulutong ng mga customer 2358 01:44:13,110 --> 01:44:16,950 ay kasangkot sa, pagkuha ng mga nested mga katangian ng mga JSON dokumento 2359 01:44:16,950 --> 01:44:18,946 at paglikha ng karagdagang mga index. 2360 01:44:18,946 --> 01:44:21,680 2361 01:44:21,680 --> 01:44:23,150 >> Humihingi kami sa dulo. 2362 01:44:23,150 --> 01:44:26,689 Salamat sa iyo para sa tindig sa akin. 2363 01:44:26,689 --> 01:44:28,480 Kaya sabihin makipag-usap tungkol architecture reference. 2364 01:44:28,480 --> 01:44:33,440 DynamoDB nakapatong sa gitna ng kaya marami ng imprastraktura AWS. 2365 01:44:33,440 --> 01:44:37,090 Talaga maaari mong isabit ito hanggang sa anumang nais mo. 2366 01:44:37,090 --> 01:44:45,600 Aplikasyon binuo gamit Dynamo isama Lambda, ElastiCache, CloudSearch, 2367 01:44:45,600 --> 01:44:49,890 itulak ang data sa nababanat MapReduce, import export mula DynamoDB 2368 01:44:49,890 --> 01:44:52,370 sa S3, ang lahat ng mga uri ng daloy ng trabaho. 2369 01:44:52,370 --> 01:44:54,120 Ngunit marahil ang pinakamahusay na bagay na pag-uusapan, 2370 01:44:54,120 --> 01:44:56,119 at ito ay kung ano ang talagang kagiliw-giliw na ay kapag kami 2371 01:44:56,119 --> 01:44:58,350 makipag-usap tungkol sa mga aplikasyon driven na kaganapan. 2372 01:44:58,350 --> 01:45:00,300 >> Ito ay isang halimbawa ng isang panloob na proyekto 2373 01:45:00,300 --> 01:45:04,850 na kami kung saan kami talaga publishing upang makalikom ng mga resulta ng survey. 2374 01:45:04,850 --> 01:45:07,700 Kaya sa isang email na link na magpadala out namin, may makikita 2375 01:45:07,700 --> 01:45:11,350 maging isang maliit na link na nagsasabi click dito upang tumugon sa mga survey. 2376 01:45:11,350 --> 01:45:14,070 At kapag ang isang tao pag-click na link, kung ano ang mangyayari 2377 01:45:14,070 --> 01:45:18,020 ay ang pull down sila ng isang ligtas na HTML survey form mula sa S3. 2378 01:45:18,020 --> 01:45:18,980 Walang server. 2379 01:45:18,980 --> 01:45:20,600 Ito ay lamang ng isang S3 object. 2380 01:45:20,600 --> 01:45:22,770 >> Form na lumalabas, naglo-load ng hanggang sa browser. 2381 01:45:22,770 --> 01:45:24,240 Ito ay nakuha ng gulugod. 2382 01:45:24,240 --> 01:45:30,160 Ito ay nakuha ng complex JavaScript na ito ay tumatakbo. 2383 01:45:30,160 --> 01:45:33,557 Kaya napaka-mayaman na application tumatakbo sa browser ng kliyente. 2384 01:45:33,557 --> 01:45:36,390 Hindi nila alam na sila ay hindi nakikipag-ugnayan sa isang back end server. 2385 01:45:36,390 --> 01:45:38,220 Sa puntong ito, ito ay ang lahat ng browser. 2386 01:45:38,220 --> 01:45:41,780 >> Sila-publish ang mga resulta sa kung ano ang ang tawag namin sa Amazon API Gateway. 2387 01:45:41,780 --> 01:45:46,270 API Gateway ay lamang ng isang web API na maaari mong tukuyin at isabit 2388 01:45:46,270 --> 01:45:47,760 sa kung anong gusto mo. 2389 01:45:47,760 --> 01:45:50,990 Sa partikular na kasong, hindi namin baluktot up sa isang Lambda function. 2390 01:45:50,990 --> 01:45:54,797 >> Kaya ang aking POST operasyon ay nangyayari na walang server. 2391 01:45:54,797 --> 01:45:56,380 Karaniwang na API Gateway nakapatong doon. 2392 01:45:56,380 --> 01:45:58,770 Sa akin wala hanggang sa mga tao Nagkakahalaga ito simulan pag-post sa mga ito, right? 2393 01:45:58,770 --> 01:46:00,269 Ang Lambda function na lamang nakapatong doon. 2394 01:46:00,269 --> 01:46:03,760 At wala ito gastos sa akin hanggang simulan tao pagpindot ito. 2395 01:46:03,760 --> 01:46:07,270 Kaya maaari mong makita, pati na ang lakas ng tunog mga pagtaas, na kapag ang mga singil darating. 2396 01:46:07,270 --> 01:46:09,390 Hindi ko pinapatakbo sa isang server 7/24. 2397 01:46:09,390 --> 01:46:12,310 >> Kaya makuha ko ang form down sa labas ng bucket, 2398 01:46:12,310 --> 01:46:15,719 at i-post ko sa pamamagitan ng API Gateway sa Lambda function. 2399 01:46:15,719 --> 01:46:17,510 At pagkatapos ay ang Lambda sabi function, alam mo 2400 01:46:17,510 --> 01:46:20,600 ano, Mayroon akong ilang PIIs, ang ilang mga personal na makikilalang impormasyon 2401 01:46:20,600 --> 01:46:21,480 sa mga kasagutan. 2402 01:46:21,480 --> 01:46:23,020 Nakatanggap ako ng komento na nanggagaling mula sa mga gumagamit. 2403 01:46:23,020 --> 01:46:24,230 Mayroon akong email address. 2404 01:46:24,230 --> 01:46:26,190 Mayroon akong mga username. 2405 01:46:26,190 --> 01:46:27,810 >> Hayaan akong nahati ito off. 2406 01:46:27,810 --> 01:46:30,280 Pupunta ako upang bumuo ng ilang metadata off ang talang ito. 2407 01:46:30,280 --> 01:46:32,850 At ako pagpunta sa itulak ang metadata sa DynamoDB. 2408 01:46:32,850 --> 01:46:36,059 At ako ay maaaring i-encrypt ang lahat ng data at itulak ito sa DynamoDB kung gusto ko. 2409 01:46:36,059 --> 01:46:38,600 Ngunit ito ay mas madali para sa akin, sa ganitong gamitin ang kaso, sige isang sabihin, 2410 01:46:38,600 --> 01:46:42,800 Pupunta ako upang itulak ang raw data na ito sa isang naka-encrypt na S3 bucket. 2411 01:46:42,800 --> 01:46:47,240 Kaya gamitin ko built in S3 server side encryption at Key Management Amazon 2412 01:46:47,240 --> 01:46:51,600 Serbisyo upang ako ay may isang key na maaaring i-rotate sa isang regular na pagitan, 2413 01:46:51,600 --> 01:46:55,010 at maaari kong protektahan ang data na iyon PII bilang bahagi ng mga ito ang buong daloy ng trabaho. 2414 01:46:55,010 --> 01:46:55,870 >> Kaya kung ano ang ginawa ko? 2415 01:46:55,870 --> 01:47:00,397 Lamang ko na ipinakalat ng isang buong application, at wala akong mga server. 2416 01:47:00,397 --> 01:47:02,980 Kaya kung ano ang kaganapang hinihimok application architecture ay para sa iyo. 2417 01:47:02,980 --> 01:47:05,730 >> Ngayon kung sa tingin mo ang tungkol sa ang paggamit kaso para this-- 2418 01:47:05,730 --> 01:47:08,730 kami ay may iba pang mga customer ko pakikipag-usap na tungkol sa eksaktong architecture na 2419 01:47:08,730 --> 01:47:14,560 tumakbo phenomenally malaking kampanya, na ay tumitingin sa mga ito at tuloy, oh aking. 2420 01:47:14,560 --> 01:47:17,840 Dahil ngayon, maaari nilang itulak talaga ito doon, 2421 01:47:17,840 --> 01:47:21,900 hayaan kampanya na umupo lamang doon hanggang naglulunsad ito, at hindi 2422 01:47:21,900 --> 01:47:24,400 mag-alala ang isang fig tungkol kung anong uri ng infrastructure 2423 01:47:24,400 --> 01:47:26,120 ay magiging doon upang suportahan ang mga ito. 2424 01:47:26,120 --> 01:47:28,600 At pagkatapos ay sa lalong madaling kampanya na ay tapos na, 2425 01:47:28,600 --> 01:47:31,520 ito ay tulad ng infrastructure lang agad napupunta ang layo 2426 01:47:31,520 --> 01:47:33,680 dahil may tunay Walang infrastructure. 2427 01:47:33,680 --> 01:47:35,660 Ito ay code lamang na nakapatong sa Lambda. 2428 01:47:35,660 --> 01:47:38,560 Ito lang ang data na makikita sa DynamoDB. 2429 01:47:38,560 --> 01:47:41,340 Ito ay isang kamangha-manghang paraan upang bumuo ng mga application. 2430 01:47:41,340 --> 01:47:43,970 >> Madla: Kaya ito ay mas ephemeral sa magiging 2431 01:47:43,970 --> 01:47:45,740 kung ito ay naka-imbak sa isang aktwal na server? 2432 01:47:45,740 --> 01:47:46,823 >> RICK Houlihan: Ganap. 2433 01:47:46,823 --> 01:47:49,190 Dahil na halimbawa server ay kailangang maging isang 7/24. 2434 01:47:49,190 --> 01:47:51,954 Ito ay upang maging magagamit para sa isang tao na tumugon sa. 2435 01:47:51,954 --> 01:47:52,620 Well hulaan kung ano? 2436 01:47:52,620 --> 01:47:55,410 S3 ay magagamit 7/24. 2437 01:47:55,410 --> 01:47:57,100 Laging tumugon S3. 2438 01:47:57,100 --> 01:47:59,320 At S3 ay tunay, tunay mabuti serving up ng mga bagay. 2439 01:47:59,320 --> 01:48:02,590 Ang mga bagay ay maaaring maging HTML file, o File ng JavaScript, o kahit anong gusto mo. 2440 01:48:02,590 --> 01:48:07,430 Maaari kang magpatakbo ng napaka-mayaman mga web application sa labas ng S3 balde, at ang mga tao gawin. 2441 01:48:07,430 --> 01:48:10,160 >> At kaya na ang mga ideya dito ay upang makakuha ng layo mula sa mga paraan 2442 01:48:10,160 --> 01:48:11,270 ginamit namin upang isipin ang tungkol dito. 2443 01:48:11,270 --> 01:48:14,270 Namin ang lahat ng ginamit upang isipin in mga tuntunin ng mga server at host. 2444 01:48:14,270 --> 01:48:16,580 Ito ay hindi tungkol sa ngayon. 2445 01:48:16,580 --> 01:48:19,310 Ito ay tungkol sa imprastraktura ng code. 2446 01:48:19,310 --> 01:48:22,470 I-deploy ang code sa ulap at pabayaan ang mga ulap tumakbo ito para sa iyo. 2447 01:48:22,470 --> 01:48:24,980 At iyan ang AWS ay sinusubukan na gawin. 2448 01:48:24,980 --> 01:48:29,690 >> Madla: Kaya ang iyong kahon ng ginto sa gitna ng API Gateway ay hindi server-like, 2449 01:48:29,690 --> 01:48:30,576 ngunit sa halip ay just-- 2450 01:48:30,576 --> 01:48:32,850 >> RICK Houlihan: Maaari mong isipin ng mga ito bilang facade server. 2451 01:48:32,850 --> 01:48:38,040 Lahat ng ito ay ay makikita itong tumagal ng isang HTTP humiling at mapa ito sa isa pang proseso. 2452 01:48:38,040 --> 01:48:39,192 Iyan na ang lahat ng ginagawa nito. 2453 01:48:39,192 --> 01:48:41,525 At sa kasong ito, kami ay paggawa ng mga mapa ito sa isang Lambda function. 2454 01:48:41,525 --> 01:48:44,119 2455 01:48:44,119 --> 01:48:45,410 Lahat ng karapatan, kaya na ang lahat nakuha ko. 2456 01:48:45,410 --> 01:48:46,190 Maraming salamat. 2457 01:48:46,190 --> 01:48:46,800 Pinapahalagahan ko ito. 2458 01:48:46,800 --> 01:48:48,100 Alam ko gusto namin ng isang maliit na piraso sa paglipas ng panahon. 2459 01:48:48,100 --> 01:48:49,980 At sana ka guys got isang maliit na piraso ng impormasyon 2460 01:48:49,980 --> 01:48:51,410 na maaari mong gawin ang layo sa araw na ito. 2461 01:48:51,410 --> 01:48:53,520 At humihingi ako ng paumanhin kung ako nagpunta higit sa ilan sa inyong mga ulo, 2462 01:48:53,520 --> 01:48:56,697 ngunit mayroong isang magandang maraming pangunahing foundational kaalaman 2463 01:48:56,697 --> 01:48:58,280 na sa tingin ko ay lubos na mahalaga para sa iyo. 2464 01:48:58,280 --> 01:48:59,825 Kaya salamat sa iyo para sa pagkakaroon ng akin. 2465 01:48:59,825 --> 01:49:00,325 [Palakpakan] 2466 01:49:00,325 --> 01:49:02,619 Madla: [hindi marinig] ay kapag ikaw ay sinasabi 2467 01:49:02,619 --> 01:49:05,160 kayo ay pumunta sa pamamagitan ng mga bagay mula sa simula hanggang sa wakas 2468 01:49:05,160 --> 01:49:07,619 upang makuha ang tamang mga halaga o sa parehong halaga, 2469 01:49:07,619 --> 01:49:09,410 kung paano gagawin ang mga halaga baguhin kung [hindi marinig]. 2470 01:49:09,410 --> 01:49:10,480 >> RICK Houlihan: Oh, idempotent? 2471 01:49:10,480 --> 01:49:11,800 Paano baguhin ang mga halaga? 2472 01:49:11,800 --> 01:49:15,180 Well, dahil kung ako ay hindi tatakbo ito sa lahat ng mga paraan sa dulo, 2473 01:49:15,180 --> 01:49:19,770 pagkatapos ay hindi ko alam kung ano ang mga pagbabago ay ginawa sa huling milya. 2474 01:49:19,770 --> 01:49:22,144 Ito ay hindi magiging ang parehong data bilang kung ano ang nakita ko. 2475 01:49:22,144 --> 01:49:24,560 Madla: Oh, kaya mo lamang hindi tapat na paraan ang buong input. 2476 01:49:24,560 --> 01:49:24,770 RICK Houlihan: Kanan. 2477 01:49:24,770 --> 01:49:26,895 Mayroon kang pumunta mula sa simula sa dulo, at pagkatapos ito ay 2478 01:49:26,895 --> 01:49:29,280 pagpunta sa isang pare-pareho ng estado. 2479 01:49:29,280 --> 01:49:31,520 Cool. 2480 01:49:31,520 --> 01:49:35,907 >> Madla: Kaya ka nagpakita sa amin DynamoDB maaaring gawin dokumento o ang key na halaga. 2481 01:49:35,907 --> 01:49:38,740 At kami na ginugol ng maraming oras sa key halaga na may hash at ang mga paraan 2482 01:49:38,740 --> 01:49:40,005 upang i-flip ito sa paligid. 2483 01:49:40,005 --> 01:49:43,255 Kapag tumingin ka sa mga talahanayan, ay na Aalis sa likod ng mga diskarte dokumento? 2484 01:49:43,255 --> 01:49:44,600 >> RICK Houlihan: hindi ko ibig sabihin iwan dito sa likod. 2485 01:49:44,600 --> 01:49:45,855 >> Madla: Sila ay hiwalay mula the-- 2486 01:49:45,855 --> 01:49:49,140 >> RICK Houlihan: Gamit ang mga dokumento diskarte, ang uri dokumento DynamoDB 2487 01:49:49,140 --> 01:49:50,880 ay sa tingin lamang ng isa pang katangian. 2488 01:49:50,880 --> 01:49:53,560 Ito ay isang katangian na naglalaman ng isang hierarchical istraktura ng data. 2489 01:49:53,560 --> 01:49:56,980 At pagkatapos ay sa query, maaari mong gamitin ang mga katangian 2490 01:49:56,980 --> 01:49:59,480 ng mga bagay gamit ang Bagay pagtatanda. 2491 01:49:59,480 --> 01:50:03,562 Kaya ang maaari kong i-filter sa isang nested ari-arian ng JSON dokumento. 2492 01:50:03,562 --> 01:50:05,520 Madla: Kaya anumang oras na ako gawin ang isang diskarte na dokumento, 2493 01:50:05,520 --> 01:50:07,906 Maaari ko bang uri ng makarating sa tabular-- 2494 01:50:07,906 --> 01:50:08,780 Madla: Ganap. 2495 01:50:08,780 --> 01:50:09,800 Madla: --indexes at bagay uusapang mo lang ang tungkol. 2496 01:50:09,800 --> 01:50:11,280 RICK Houlihan: Oo, ang ini-index at ang lahat na, 2497 01:50:11,280 --> 01:50:13,363 kapag gusto mong i-index ang mga katangian ng JSON, 2498 01:50:13,363 --> 01:50:18,230 ang paraan na gusto namin upang gawin iyon ay kung mong ipasok ang isang JSON object o isang dokumento 2499 01:50:18,230 --> 01:50:20,780 sa Dynamo, nais mong gamitin stream. 2500 01:50:20,780 --> 01:50:22,400 Streams ay basahin ang input. 2501 01:50:22,400 --> 01:50:24,340 Gusto mong makakuha na JSON bagay at gusto mong sabihin OK, 2502 01:50:24,340 --> 01:50:26,030 kung ano ang mga ari-arian na gusto kong i-index? 2503 01:50:26,030 --> 01:50:28,717 >> Lumikha ka ng isang hinalaw na table. 2504 01:50:28,717 --> 01:50:30,300 Ngayon na ang paraan na ito ay gumagana sa ngayon. 2505 01:50:30,300 --> 01:50:32,650 Hindi namin pinapayagan sa iyo upang index direkta sa mga properties. 2506 01:50:32,650 --> 01:50:33,520 >> Madla: Tabularizing iyong mga dokumento. 2507 01:50:33,520 --> 01:50:36,230 >> RICK Houlihan: Eksakto, pagyupi ito, tabularizing ito, eksakto. 2508 01:50:36,230 --> 01:50:37,415 Iyon ay kung ano ang gagawin mo sa mga ito. 2509 01:50:37,415 --> 01:50:37,860 >> Madla: Salamat sa iyo. 2510 01:50:37,860 --> 01:50:39,609 >> RICK Houlihan: Oo, ganap na, salamat. 2511 01:50:39,609 --> 01:50:42,240 Madla: Kaya ito ay uri ng Mongo nakakatugon Redis classifers. 2512 01:50:42,240 --> 01:50:43,990 >> RICK Houlihan: Oo, ito ay isang pulutong na tulad ng. 2513 01:50:43,990 --> 01:50:45,940 Iyon ay isang mahusay na paglalarawan para sa mga ito. 2514 01:50:45,940 --> 01:50:47,490 Cool. 2515 01:50:47,490 --> 01:50:49,102