[Mūzikas atskaņošanai] RICK Houlihan: Nu labi. Sveiki visiem. Mans vārds ir Rick Houlihan. Es esmu vecākais galvenā risinājumi arhitekts pie AWS. Es koncentrēties uz NoSQL un DynamoDB tehnoloģijas. Es šodien esmu šeit, lai runātu ar jūs mazliet par tiem. 

Mans fons ir galvenokārt datu slāni. Es pavadīju pusi manu attīstību karjera rakstot datubāzi, datu piekļuves, risinājumi dažādiem lietojumiem. Esmu bijis Cloud virtualizācijas apmēram 20 gadus. Tātad, pirms Cloud bija Cloud, mēs izmantojām, lai izsauktu to lietderība skaitļošanas. Un doma bija, tas ir tāpat kā PG & E, jūs maksājat par to, ko jūs izmantojat. Šodien mēs to saucam par mākonis. 

Bet gadu gaitā, es esmu strādājis par pāris uzņēmumu jūs droši vien nekad nav dzirdējuši. Bet es esmu apkopojusi sarakstu ar tehnisko sasniegumi, es domāju, jūs teiktu. Man ir astoņi patenti mākonis sistēmās virtualizācijas, mikroprocesoru dizains, komplekss pasākums apstrāde, un citās jomās, kā arī. 

Tātad šajās dienās, es koncentrēties galvenokārt uz NoSQL tehnoloģijas un nākamās paaudzes datubāzi. Un tas ir vispār, ko es eju būt šeit runāt ar jums šodien par. Tātad, ko jūs varat sagaidīt No šīs sesijas, mēs iet cauri īss Vēsture datu apstrādi. Tas vienmēr ir noderīgi saprast, kur mēs nāca no un kāpēc mēs esam, kur mēs esam. Un mēs runāsim nedaudz bit par NoSQL tehnoloģijas no pamatnostādni. 

Mēs saņemam par dažām tad DynamoDB iekšējie. DynamoDB ir AWS nav nekāds aromāts. Tas ir pilnībā pārvalda un hosted NoSQL risinājums. Un mēs runājam mazliet par tabulā struktūra, API, datu tipi, indeksi, un daži no iekšējās Minētās DynamoDB tehnoloģijas. Mēs nokļūt daži dizainu modeļus un labāko praksi. Mēs runājam par to, kā jūs izmantot šo tehnoloģiju dažiem no šodienas pieteikumus. Un tad mēs runāsim mazliet par attīstību vai parādīšanos par jaunu paradigmu plānošanā sauc par notikumu orientētu pieteikumi un cik DynamoDB spēlē, kas, kā labi. Un mēs atstāt jūs mazliet atsauce arhitektūra diskusija lai mēs varētu runāt par kādu no veidiem, kā jūs varat izmantot DynamoDB. 

Tātad vispirms off-- šis ir jautājums Es dzirdu daudz ir to, kas ir datu bāze. Daudzi cilvēki domā, ka viņi zina, kas ir datu bāze. Ja jūs Google, jūs redzēsiet šo. Tā ir strukturēta datu kopa notika datorā, jo īpaši tādu, kas ir pieejams dažādos veidos. Es domāju, ka tas ir labs definīcija mūsdienu datubāzes. Bet man nepatīk, jo tas nozīmē pāris lietas. Tas nozīmē struktūru. Un tas nozīmē, ka tas ir uz datora. Un datubāzes nebija vienmēr pastāv datoros. Datu bāzes faktiski pastāvēja daudzos veidos. 

Tātad labāka definīcija Datu bāze ir kaut kas līdzīgs šim. Datubāze tiek organizēta mehānisms, lai uzglabātu, pārvaldīšanai un informācijas izguvei. Tas ir no About.com. Tāpēc man patīk, jo tā patiešām sarunas Par datu bāze ir krātuve, krātuve informācija, ne vienmēr kaut kas, kas atrodas uz datora. Un visā vēsturē, mēs ne vienmēr ir bijis datorus. 

Tagad, ja man uzdot vidējo attīstītājs šodien, kas ir datu bāzes, kas ir atbilde man. Kaut kur es varu stick sīkumi. Tiesības? Un tā ir taisnība. Bet tas ir žēl. Jo datubāze ir patiešām pamats mūsdienu app. Tas ir pamats par katru pieteikumu. Un kā jūs veidot, ka datu bāzes, kā jūs strukturēt ka dati gatavojas diktēt, kā šis programma veic kā jūs mērogu. 

Tik daudz manu darbu šodien nodarbojas ar to, ko notiek, ja izstrādātāji šo pieeju un nodarbojas ar sekām Pieteikuma ka tagad mērogošana aiz oriģināls nodoms un ciešanas no sliktu dizainu. Tātad, cerams, kad jūs iet prom šodien, jūs ir pāris paņēmieniem jostas, kas būs uzturēt jūs no pieņemšanas šo pašu kļūdu. Viss kārtībā. Tātad parunāsim par mazliet LAIKA datu bāzes tehnoloģijas. Es domāju, ka es izlasīju raksts nav tik sen un tas kaut ko teica par lines-- tas ir ļoti dzejas paziņojums. Tā teica vēsture Datu apstrāde ir pilns ar augstu ūdenszīmes Datu pārpilnību. LABI. Tagad, es domāju, tas ir sava veida taisnība. Bet es tiešām apskatīt, ir kā vēsture ir faktiski aizpildīts ar augstu atzīmi datu spiedienu. Jo datu pārraides ātrumu norīšana nekad iet uz leju. Tas tikai iet uz augšu. 

Un inovācija rodas, ja mēs redzam datu spiedienu, kas ir datu apjomu, kas ir tagad nāk sistēmā. Un tas nevar apstrādāt efektīvi laiku vai izmaksu. Un tas ir tad, kad mēs sākam apskatīt datu spiedienu. 

Tātad, ja mēs skatāmies uz Pirmā datubāzes, šis ir viens, kas bija starp mūsu ausīm. Mēs visi esam dzimuši ar to. Tā ir jauka datubāzi. Tas ir liels pieejamību. Tas vienmēr. Jūs vienmēr varat saņemt to. 

Bet tas ir viens lietotājs. Es nevaru dalīties manas domas ar jums. Jūs nevarat saņemt manas domas kad jūs to vēlaties. Un viņu abilitiy nav tik laba. Mēs aizmirst lietas. Šad un tad, viens no mums leaves un pārceļas uz citu pastāvēšanu un mēs zaudēt visu tas bija šajā datubāzē. Tātad tas nav viss, kas labi. 

Un tas strādāja labi laika gaitā kad mēs bija atpakaļ dienā kad visi mēs tiešām vajadzēja zināt, kur mēs gatavojamies iet rīt vai ja mēs savākt labāko pārtiku. Bet kā mēs sākām augt kā civilizācija un valdība sāka nonākt būtni, un uzņēmēji sāka attīstīties, mēs sākām realizēt mēs nepieciešams nedaudz vairāk nekā tas, ko mēs varētu likt mūsu galvu. Viss kārtībā? 

Mums vajadzēja sistēmas ierakstu. Mums vajadzēja vietu, lai varētu uzglabāt datus. Tā mēs sākām rakstīšanas dokumentus, radot bibliotēkās un arhīvos. Mēs sākām attīstot SYSTEM A virsgrāmatā uzskaites. Un ka virsgrāmatā skaitīšanas sistēma skrēja pasaulē daudzus gadsimtus, un varbūt pat tūkstošiem gadu, kā mēs veida palielinājās līdz punktam ja šī informācija slodze pārspēja spēja šo sistēmu lai varētu saturēt to. 

Un tas patiesībā notika 1880. Tiesības? In 1880 ASV tautas skaitīšanas. Tas ir tiešām, ja pagrieziena norādīt modernu datu apstrādi. Tas ir punkts, kuru datu apjomu kas tika savākti ar ASV valdība ieguva uz punktu kur tas bija astoņi gadi, lai apstrādātu. 

Tagad, astoņas years-- kā jūs zināt, skaitīšanu kursē katru 10 years-- tāpēc tas ir diezgan skaidrs, ka ar laiku mēs ieguva 1890 skaitīšanu, datu apjomu, kas gatavojas apstrādāt valdība bija gatavojas pārsniedz 10 gadus, ka to būtu nepieciešams, lai uzsāka jaunu skaitīšanu. Tas bija problēma. 

Tātad puisis nosauca Herman Hollerith nāca līdzi un viņš izgudroja vienības rekordu perforators kartiņas, perforators karšu lasītājs, perfokaršu Tabulators, un apkopošana mehānismi šo tehnoloģiju. Un, ka uzņēmums, kas viņš izveidoja pie laiks, kopā ar pāris citiem, faktiski kļuva par vienu no pīlāriem neliels uzņēmums, mēs zinām šodien aicināja IBM. 

Tātad IBM sākotnēji bija Šīs datu bāzes bizness. Un tas ir patiešām to, ko viņi darīja. Viņi datu apstrādi. 

Kā tā izplatīšanu perforators kartes, asprātīgs mehānismi ir iespēja piesaistīt ka tehnoloģija, lai aptauju sakārtotās rezultātu kopas. Jūs varat redzēt šo attēlu tur mums ir little-- tas ir mazliet small-- bet jūs varat redzēt ļoti ģeniāls mehānisks mehānisms kur mums ir perforators karti klāja. Un kāds ir sagrābšana mazliet skrūvgriezis un uzlīmēšanu caur slots un paceļot to uz augšu lai iegūtu šo spēli, ka noteikt kārtoti rezultāti. 

Tas ir summēšana. Mēs to darām visu laiku šodien ar datoru, kur jūs to datu bāzē. Mēs izmantojām to darīt manuāli, vai ne? Cilvēki nodot šīs lietas kopā. Un tas bija izplatīšanās Šo perfokartēm par to, ko mēs sauc par datu bungas un datu spoles, papīra lentes. 

Datu apstrādes rūpniecība paņēma mācība no spēlētāju klavieres. Spēlētāja klavieres atpakaļ kārta gadsimta mēdzu izmantot papīra ruļļus ar nišu par to pateikt to, kas taustiņus, lai spēlētu. Tā, ka tehnoloģija tika pielāgots galu galā, lai uzglabātu digitālos datus, jo tās varētu nodot, ka dati uz šīm papīra lentes spolēs. 

Tagad, kā rezultātā, dati tika actually-- kā Jums piekļūt šie dati bija tieši atkarīgs no tā, kā jūs to saglabātu. Tātad, ja man datus uz lentes, Man bija piekļūt datiem lineāri. Man bija roll visu lente, lai piekļūtu visus datus. Ja man datus perforators kārtis, es varētu piekļūt jo nedaudz vairāk izlases mode, varbūt ne tik ātri. 

Bet tur bija ierobežojumi, kā mēs piekļuvi datiem, pamatojoties uz to, kā tika uzglabāti. Un tā tas bija problēma nonākšana '50s. Atgādināsim, ka mēs varam sākt redzēt, ka mēs izstrādāt jaunas tehnoloģijas, lai apstrādātu dati, pa labi, tā paver durvis jauniem risinājumiem, jaunas programmas, jaunas pieteikumus šiem datiem. Un tiešām, pārvaldība var būt par iemeslu Tāpēc mēs izstrādājām dažas no šīm sistēmām. Bet bizness strauji kļuva vadītājs aiz evolūcijas mūsdienu datubāzes un mūsdienu failu sistēma. 

Tātad nākamā lieta, kas nāca klajā bija '50s bija failu sistēma un attīstība brīvpiekļuves uzglabāšanu. Tas bija skaisti. Tagad, visi pēkšņi, mēs varam nodot mūsu failus jebkur uz šiem diskdziņiem un mēs varam piekļūt šos datus nejauši. Mēs varam apstrādāt, ka Informācija no failiem. Un mēs visi atrisināt pasaules problēmas ar datu apstrādi. 

Un tas ilga aptuveni 20 vai 30 gadus līdz evolūcijas relāciju datu bāzi, kurā ir tad, kad pasaule nolēma mēs tagad ir nepieciešama krātuvi, kas uzvar izplešanās datu visā failā sistēmas, kas mēs esam izveidojuši. Tiesības? Pārāk daudz datu izplatīts pārāk daudz vietas, datu de-dublēšanās, un glabāšanas izmaksas bija milzīga. 

In '70s, visdārgāko resursu ka dators bija bija glabāšana. Procesors bija uzskatīta par fiksētu cenu. Kad es nopirkt lodziņu, CPU dara kādu darbu. Tas būs vērpšanai, vai tas faktiski strādā vai ne. Tas ir patiešām nogrimis izmaksām. 

Bet ko izmaksāt man kā bizness ir glabāšana. Ja man ir nopirkt vairāk diskus blakus mēnesī, tas ir faktiskās izmaksas, kas man jāmaksā. Un tas uzglabāšana ir dārga. 

Tagad mēs ātri uz priekšu 40 gadus un mums ir cita problēma. Compute tagad ir visdārgākais resurss. Uzglabāšanas ir lēts. Es domāju, mēs varam doties jebkur uz mākonis, un mēs varam atrast lētu uzglabāšanu. Bet ko es nevaru atrast ir lēts aprēķināt. 

Tātad attīstību šodienas tehnoloģija, datu bāzes tehnoloģijas, ir patiešām koncentrēta ap izplatīto datu bāzes kas necieš no tāda paša veida skalas ierobežojumi relāciju datu bāzēm. Mēs runājam mazliet par ko tas patiesībā nozīmē. 

Bet viens no iemesliem un vadītājs aiz this-- mēs runāja par datu spiedienu. Datu spiediens ir kaut kas kas vada jauninājumus. Un, ja paskatās vairāk pēdējo piecu gadu laikā, Tas ir shēma kādi dati slodze visā vispārējās uzņēmumā Izskatās, ka pēdējo piecu gadu laikā. 

Un vispārējais noteikums īkšķis šie days-- ja jums iet Google-- ir 90% no datiem, kas mēs glabāt šodien, un tas bija radīts pēdējo divu gadu laikā. LABI. Tagad tas nav tendence, kas jauns. Tā ir tendence, kas ir bijis izbeigs 100 gadus. Kopš Herman Hollerith izstrādājusi perforators karti, mēs esam celtniecības datu krātuves un apkopojot datus phenomenal likmēm. 

Tātad pēdējo 100 gadu laikā, mēs esam redzējuši šo tendenci. Tas nav gatavojas mainīt. Iet uz priekšu, mēs ejam, lai redzētu tas, ja ne paātrināta tendence. Un jūs varat redzēt, ko tas izskatās. 

Ja bizness 2010. gadā bija viens terabaitu datu pārvaldīšanā, Šodien tas nozīmē, ka viņi pārvaldot 6.5 petabytes datus. Tas ir 6500 reizes vairāk datu. Un es zinu, tas. Es strādāju ar šiem uzņēmumiem katru dienu. Pirms pieciem gadiem, es varētu runāt ar uzņēmumu Kurš runāt ar mani par to, ko sāpēm tas ir pārvaldīt terabaitiem datu. Un viņi runā man par to, kā mēs redzam, ka tas ir iespējams, gatavojas būt petabyte vai divi kas pāris gadu laikā. 

Šie paši uzņēmumi šodien es esmu tikšanās ar, un viņi runā ar mani Par Problēma ir tur, kam pārvaldību desmitiem, 20 petabytes datus. Tātad eksplozijā dati nozarē ir braukšanas milzīgās vajag labākus risinājumus. Un relāciju datu bāze ir vienkārši nedzīvo pieprasījumam. 

Un tā tur ir lineāra korelācija starp datu spiediens un tehniskās inovācijas. Vēsture ir pierādījusi, tas, ka laika gaitā, kad datu apjomu kas ir jāapstrādā pārsniedz jaudu sistēmas apstrādāt to saprātīgā laika vai par saprātīgām izmaksām, tad jaunās tehnoloģijas ir izdomāts, lai risinātu šīs problēmas. Šīs jaunās tehnoloģijas, savukārt, atvērt durvis uz citu problēmu kopumu, kas ir vākšana vēl vairāk datu. 

Tagad mēs nebrauksim, lai apturētu to. Tiesības? Mēs nebrauksim, lai apturētu to. Kāpēc? Tāpēc, ka jūs nevarat zināt visu ir jāzina Visumā. Un kamēr mēs esam dzīvi, Visā vēsturē cilvēks, mēs esam vienmēr brauc, lai uzzinātu vairāk. 

Tāpēc šķiet, tāpat kā katru collu mēs virzāmies nosaka ceļu zinātnisko atklājumu, mēs reizinot datu apjomu ka mums ir nepieciešams, lai apstrādātu eksponenciāli kā mēs atklāt vairāk un vairāk un vairāk par iekšējo darbību dzīvē, par to, kā Visums darbojas, par braukšanas zinātnisku atklājumu, un izgudrojums, ka mēs darām šodien. Datu apjoms tikai nepārtraukti palielinās. Tātad to var tikt galā ar šī problēma ir milzīga. 

Tātad, viens no lietām mēs skatāmies kā kāpēc NoSQL? Kā NoSQL atrisināt šo problēmu? Nu, relāciju datu bāzēm, Strukturēts Query Language, SQL-- ka tiešām konstrukcija no relāciju database-- šīs lietas ir optimizēta uzglabāšanai. 

Atpakaļ '70s, atkal, disks ir dārga. Nodrošinājuma īstenošana uzglabāšanas uzņēmumā ir nebeidzams. Es zinu. Es dzīvoju to. Es uzrakstīju uzglabāšanas draiverus enterprised SuperServer uzņēmums atpakaļ '90s. Un tāds ir Plaukti cits glabāšanas masīvu bija tikai kaut kas notika katru dienu uzņēmumā. Un tas nekad nav pārtraucis. Augstākā blīvums uzglabāšana, pieprasījums augsta blīvuma glabāšanai, un efektīvāku uzglabāšanai devices-- tas nekad nav pārtraucis. 

Un NoSQL ir lieliska tehnoloģija jo tas normalizē datus. Tā de-dublē datus. Tas liek datus tādā struktūrā, kas ir agnostiķis katram piekļuves modeli. Vairāki pieteikumus var hit, ka SQL datu bāzi, palaist ad hoc vaicājumu, un saņemt datus formā, ka tie nepieciešams apstrādāt viņu darba slodze. Tas izklausās fantastiski. Bet apakšējā līnija ir ar jebkuru sistēma, ja tas ir agnostiķis, lai viss, tas ir optimizēta neko. LABI? 

Un tas, ko mēs ar relāciju datu bāzē. Tas ir optimizēta uzglabāšanai. Tas ir normalizēta. Tas ir relāciju. Tā atbalsta ad hoc vaicājumu. Un tas un tas svari vertikāli. 

Ja man ir nepieciešams, lai iegūtu lielāku SQL datu bāzi vai jaudīgāku SQL datu bāzes, Es aiziet nopirkt lielāku gabalu dzelzs. LABI? Esmu strādājis ar daudziem klientiem kas ir ar nozīmīgu uzlabojumu to SQL infrastruktūrā tikai lai uzzinātu, sešus mēnešus vēlāk, viņi hitting sienu vēlreiz. Un no Oracle vai MSSQL atbilde vai kāds cits ir iegūt lielāku kasti. Nu agrāk vai vēlāk, jūs nevarat nopirkt lielāka kaste, un tas ir reāla problēma. Mums ir nepieciešams, lai faktiski mainīt lietas. Tātad, ja tas darbojas? Tas darbojas labi bezsaistē analytics, OLAP tipa darba slodze. Un tas tiešām, ja SQL pieder. Tagad tas ir izmantots šodien daudzi tiešsaistes darījumu apstrādes tipa pieteikumi. Un tas darbojas tikai naudas sodu daži izmantošanas līmenis, bet tas vienkārši nav skalu tā, ka NoSQL dara. Un mēs runāsim nedaudz bit par to, kāpēc tas ir. 

Tagad, NoSQL, no otras puses, ir vairāk optimizēta compute. LABI? Tas nav agnostiķis ar piekļuves modelis. Vai tas, ko mēs saucam de normalizētas struktūra vai hierarhiska struktūra. Ar relāciju datu bāzē dati ir apvienojušies no vairākām tabulām ražot uzskatu, ka jums ir nepieciešams. Ar a NoSQL datubāzes dati tiek glabāta dokumentā, kas satur hierarhisko struktūru. Visi dati, kas parasti būtu savienoti kopā, lai iegūtu šo viedokli tiek glabāta vienā dokumentā. Un mēs runājam mazliet par Kā tas darbojas pāris kartēm. 

Bet ideja ir tāda, ka jūs uzglabāt Jūsu dati kā šiem instantiated viedokļiem. LABI? Jūs mēroga horizontāli. Tiesības? Ja man ir nepieciešams, lai palielinātu izmērs mana NoSQL klastera, Man nav nepieciešams, lai iegūtu lielāku kasti. Man vēl lodziņu. Un es kopu tos kopā, un es varu Shard, ka dati. Mēs runājam mazliet par ko sharding ir, lai būtu spējīgs mēroga šai datubāzei vairākās fiziskajām ierīcēm un noņemt šķēršļus, kas prasa man mēroga vertikāli. 

Tātad, tas ir patiešām būvēts online darījumu apstrādes un mērogs. Tur ir liela atšķirība šeit starp ziņošanu, vai ne? Ziņojumi, es nezinu Jautājumi es esmu gatavojas lūgt. Tiesības? Reporting-- ja kāds no mana mārketinga nodaļa grib just-- cik daudzi no maniem klientiem ir šo konkrēto īpašība, kas nopirka šo day-- es nezinu ko vaicājumu viņi gatavojas lūgt. Tāpēc man ir nepieciešams, lai būtu agnostiķis. 

Tagad, kādā tiešsaistē darījumu pieteikums, Es zinu, ko jautājumi es esmu lūdzot. Man būvētas pieteikumu ļoti specifisks darbplūsmu. LABI? Tātad, ja es optimizēt datus uzglabāt, lai atbalstītu šo darbplūsmu, tas būs ātrāk. Un tas ir iemesls, kāpēc NoSQL var tiešām paātrinātu piegādi no šiem pakalpojumu veidiem. Viss kārtībā. 

Tātad mēs ejam, lai nokļūt mazliet teorijas šeit. Un daži no jums, jūsu acis varētu roll atpakaļ mazliet. Bet es mēģināšu to saglabāt augsta līmeņa, kā es varu. Tātad, ja tu esi projektā vadība, tur ir konstrukts sauc trijstūris ierobežojumiem. LABI. Par ierobežo diktāta trijstūris Jūs nevarat būt viss visu laiku. Nevar būt jūsu pīrāgs un ēst tā pārāk. Tātad projektu vadību, ka trijstūris ierobežojumi ir jūs varat to lēti, jūs varat to ātri, vai arī jums var būt tas ir labi. Pick divi. Tāpēc, ka jūs nevarat būt visas trīs. Tiesības? LABI. 

Tātad jūs uzzinājāt par šo partiju. Tas ir triple ierobežojums, trijstūris triple ierobežojumiem, vai dzelzs trijstūris ir oftentimes-- kad tu runā ar projektu vadītāji, tie būs runāt par to. Tagad, datu bāzes ir to pašu dzelzs trijstūris. Un dzelzs trijstūris datu ir tas, ko mēs saucam CAP teorēma. LABI? 

CAP teorēma diktē kā datubāzes darbojas ar ļoti īpašu nosacījumu. Un mēs runājam par ko šis nosacījums ir. Bet trīs punkti trīsstūra, tā sakot, ir C, konsistence. LABI? Tātad KLP, konsekvence nozīmē, ka visi klienti, kas var piekļūt datu bāzei vienmēr būs ļoti konsekventa skats datus. Neviens nav gonna redzēt divas dažādas lietas. LABI? Ja es redzu datu bāzi, Es esmu redzēt to pašu viedokli kā mans partneris, kas redz tāds pats datu bāzē. Tas ir konsekvence. 

Pieejamība nozīmē, ka tad, ja datu bāzes internetā, ja to var sasniegt, ka visi klienti būs vienmēr jāspēj lasīt un rakstīt. LABI? Tātad katrs klients, kas var lasīt datubāzi vienmēr būs iespēja lasīt dati un rakstīt datus. Un, ja tas ir gadījumā, tā ir pieejama sistēma. 

Un trešais punkts ir tas, ko mēs saucam starpsienu toleranci. LABI? Sadalīšanās pielaides līdzekļi ka sistēma darbojas labi neskatoties uz fizisko tīklu starpsienām starp mezgliem. LABI? Tātad mezgliem klastera nevar runāt viens ar otru, kas notiek? Viss kārtībā. 

Tātad relāciju datubāzes choose-- Jūs varat izvēlēties divus no tiem. LABI. Tātad relāciju datubāzes izvēlēties jābūt konsekventiem un pieejams. Ja nodalījums notiek starp tad DataNodes datu krātuvē, Šīs datu bāzes avarē. Tiesības? Tas tikai iet uz leju. LABI. 

Un tas ir iemesls, kāpēc viņi ir augt ar lielākiem kastes. Tiesības? Jo tur no-- parasti, klastera datubāzes, tur nav ļoti daudzi no viņiem kas darbojas, ka veidā. Bet lielākā daļa datubāzes mērogu vertikāli vienā kastē. Tāpēc, ka tiem ir jābūt konsekventa un pieejams. Ja nodalījums tiktu ievadīts, tad jums būs izdarīt izvēli. Jums izdarīt izvēli starp konsekventi un pieejams. 

Un tas, ko NoSQL datubāzēm. Viss kārtībā. Tātad NoSQL datu bāzes, to nāk divi garšu. Mēs have-- labi, to nāk daudzos flavors, bet tas nāk ar diviem pamata characteristics-- ko mēs sauktu CP datu bāzi vai konsekventa un starpsienu tolerance sistēma. Šie puiši izdarīt izvēli, kas, ja mezgli zaudē kontaktu ar otru, mēs nebrauksim, lai ļautu cilvēki rakstīt vairāk. LABI? 

Līdz ka nodalījums ir noņemta, rakstīšanas ir bloķēts. Tas nozīmē, ka viņi nav pieejami. Viņi konsekventi. Kad mēs redzam, ka nodalījums injicēt sevi, Tagad mēs esam konsekventi, jo mēs nebrauksim lai ļautu datu maiņu uz divām puses nodalījumā patstāvīgi viens no otra. Mums būs atjaunot saziņu pirms atjauninājums dati tiek atļauta. LABI? 

Nākamais garša būtu AP sistēma, vai pieejama un sadalīts tolerance sistēma. Šie puiši vienalga. Tiesības? Jebkura mezglā ka izpaužas rakstīt, mēs ņemšu to. Tāpēc es esmu replicē manus datus vairākiem punktiem. Šie mezgli saņemt klients, klients nāk in, saka, es esmu gatavojas rakstīt dažus datus. Node saka, nav problēmu. Mezglu blakus viņam izpaužas rakstīšanas par to pašu ierakstu, viņš gatavojas teikt nekādu problēmu. Kaut kur atpakaļ uz muguras beigās, ka dati gatavojas atkārtot. Un tad kāds gatavojas realizēt, uh-oh, viņi sistēma sapratīs, uh-oh, tur ir bijis atjauninājums abām pusēm. Ko mēs darām? Un ko viņi dara, tad ir viņi dara kaut ko, ļauj viņiem, lai atrisinātu šo Datu valsts. Un mēs runājam par ka nākamajā tabulā. 

Lieta norādīt šeit. Un es neesmu gatavojas saņemt pārāk daudz par šo, jo tas iekļūst dziļi datu teorijā. Bet tur ir darījumu sistēma, kas trašu relāciju sistēmu, kas man ļauj droši veikt atjauninājumus vairākiem subjektiem datu bāzē. Un šie atjauninājumi notiks visu uzreiz vai nemaz. Un to sauc AKII darījumus. LABI? 

ACID dod mums Atomitāte, konsekvence, izolācija, un izturību. LABI? Tas nozīmē, atomu, darījumus, visi Mani atjauninājumi nu gadās, vai tās nav. Konsekvence nozīmē, ka datubāze būs vienmēr ievest konsekventi valsts pēc atjauninājumu. Es nekad atstāt datubāzē tādā slikts stāvoklis pēc pieteikšanās atjauninājumu. LABI? 

Tātad, tas ir nedaudz atšķirīgs nekā KLP konsekvenci. CAP konsistence ir visas manas klienti vienmēr var redzēt datus. ACID Konsekvence nozīmē, ka tad, kad darījums ir darīts, dati ir labs. Manas attiecības ir viss labi. Es neesmu gatavojas dzēst mātes rindu un atstāt ķekars bāreņiem kādā citā tabulā. Tas nevar notikt, ja es esmu konsekventi skābā darījumā. 

Izolēšana nozīmē, ka darījumi vienmēr notiek viens pēc otra. Gala rezultāts datu būs tāds pats valsts kā tad, ja šiem darījumiem kas tika izsniegtas vienlaicīgi Tika izpildīts sērijveidā. Tātad, tas ir laiksakritība kontrole datu bāzē. Vārdu sakot, es nevaru izmainiet pati vērtība divreiz ar divām darbībām. 

Bet, ja es saku pievienot 1 līdz šai vērtībai, un divi darījumi nonāk un mēģināt to darīt, viens ir gatavojas nokļūt vispirms un otrs ir gatavojas nokļūt pēc. Tātad galu galā, es pievienoju divus. Redzi, ko es domāju? LABI. 

Izturība ir diezgan vienkārši. Kad darījums Tiek atzīts, tas ir būs tur pat ja sistēma atteici. Kad šī sistēma atgūst, ka darījums, kas tika izdarīts faktiski būs tur. Tātad tas ir garantijas skābes darījumiem. Tie ir diezgan jauki garantijas būt uz datu bāzi, bet viņi nāk pie šīm izmaksām. Tiesības? 

Jo problēma ar šī sistēma ir ja ir nodalījums ar datu komplekts, man ir jāpieņem lēmums. Es esmu nāksies ļaut atjauninājumus par vienu vai otru pusi. Un, ja tas notiks, tad es esmu vairs iet lai varētu uzturēt šīs pazīmes. Tie nebūs konsekventa. Tie netiks izolēti. Tas ir, ja tas sabojājas par relāciju datu bāzēm. Tas ir iemesls, relāciju datubāzes mēroga vertikāli. 

No otras puses, mums ir ko sauc Base Technology. Un tie ir jūsu NoSQL datu bāzēm. Viss kārtībā. Tātad mums ir mūsu CP, AP datu bāzes. Un šie ir tas, ko jūs saucat būtībā pieejami, mīksts valsts, beidzot konsekventa. LABI? 

Būtībā pieejami, jo viņi partition iecietīgi. Viņi vienmēr būs tur, pat ja tur ir tīkls nodalījums starp mezgliem. Ja es varētu runāt ar mezglu, es esmu gatavojas, lai varētu nolasīt datus. LABI? Es ne vienmēr varēs uzrakstīt dati, ja es esmu konsekventa platforma. Bet es būšu spējīgs nolasīt datus. 

Mīksts stāvoklis norāda ka tad, kad es izlasīju, ka dati, tas varētu būt tāds pats kā citiem punktiem. Ja tiesības tika izdots mezglu kaut kur citur klastera un tā nav atkārtot pāri klasteris tomēr, kad es izlasīju, ka dati, ka valsts varētu būt konsekventa. Tomēr, tā būs beidzot konsekventi, tas nozīmē, ka tad, kad rakstīt tiek veikta uz sistēmu, tas būs atkārtot pāri mezgliem. Un galu galā, ka valsts tiks ievestas rīkojumu, un tas būs konsekventa valsts. 

Tagad, CAP teorēma patiešām spēlē tikai vienā stāvoklī. Šis nosacījums ir, kad tas notiek. Jo, kad vien tas ir darbojas normālā režīmā, nav nodalījumu, viss ir konsekventa un pieejams. Jums tikai jāuztraucas par KLP kad mums ir šajā nodalījumā. Tātad tie ir reti. Bet, kā sistēma reaģē, kad tie notikt diktēt, kāda veida sistēmai mums ir darīšana ar. 

Tātad pieņemsim apskatīt to, kas kas izskatās pēc AP sistēmām. LABI? AP sistēmas nonāk divi garšu. Tās ir aromāts, kas ir master master, 100%, vienmēr ir pieejama. Un viņi nāk Cita garša, kurā teikts, jūs zināt, ko es esmu gatavojas jāuztraucas par šo lietu sadalīšanu ja faktiskais partition notiek. Pretējā gadījumā būs primārais mezgli, kurš gatavojas veikt tiesības. LABI? 

Tātad, ja mēs kaut kā Cassandra. Cassandra būtu kapteinis meistars, pieņemsim man rakstīt jebkuru mezglu. Tātad, kas notiek? Tāpēc man ir objektu datu bāze, kas pastāv uz diviem mezgliem. Sauksim šo objektu S. Tāpēc mums ir stāvoklis attiecībā uz S. Mums ir dažas operācijas uz S, ka turpinās. Cassandra ļauj man rakstiet uz vairākiem punktiem. Tātad pieņemsim, ka es saņemt rakstīt s līdz diviem punktiem. Nu, ko nonāks notiek, ir mēs saucam par sadalīšanas gadījumā. Tur nevar būt fiziskais tīkls nodalījums. Bet tāpēc, ka dizains no sistēmas, tas ir faktiski šķērssienu tiklīdz kā man rakstīt par diviem punktiem. Tas nav piespiežot man rakstīt visu caur vienu mezglu. Es rakstu par diviem punktiem. LABI? 

Tāpēc tagad man ir divas valstis. LABI? Kas notiks ir agrāk vai vēlāk, tur būs replikācijas notikums. Tur būs ko mēs sauc partition atgūšana, kas ir, ja šīs divas valstis atgriezties kopā un tur būs algoritms kas darbojas iekšpusē datu bāzē, izlemj, ko darīt. LABI? Pēc noklusējuma, pēdējais update uzvar lielākajā AP sistēmās. Tātad tur parasti noklusējuma algoritms, ko viņi sauc atzvanīłanu funkcija, kaut kas tiks izsaukta, kad šis nosacījums ir konstatēta izpildīt kādu loģiku lai atrisinātu šo konfliktu. LABI? Noklusējuma Atzvans un noklusēto Risinātāja vairumā AP datubāzēs ir, uzmini, timestamp uzvar. Šī bija pēdējā update. Es esmu gatavojas nodot šo atjauninājumu tur. Es varētu dump šo ierakstu, ka es dempinga ietecēt atjaunošanas žurnālu tā, ka lietotājs var atgriezties vēlāk un teikt, hey, tur bija sadursme. Kas notika? Un jūs tiešām varat dump reģistrē visi sadursmes un rollbacks un redzēt, kas notiek. 

Tagad, kā lietotājs, jūs varat arī ietver loģika vērā šo atzvanu. Tātad jūs varat mainīt, ka atzvanīšanas operācija. Jūs varat teikt, hey, es gribu lai mazinātu šo informāciju. Un es gribu, lai mēģinātu apvienot šos divus ierakstus. Bet tas ir atkarīgs no jums. Datubāzē nezina, kā to darīt pēc noklusējuma. Lielākā daļa laika, vienīgā lieta datu bāzes zina, kā to izdarīt, ir pateikt, tas viens bija pēdējais ieraksts. Tas ir tas, kas notiek, lai uzvarētu, un tas ir vērtība es esmu gatavojas īstenot. Kad šī partition atgūšana un vairošanās notiek, mums ir mūsu valsts, kuras tagad S prime, kas ir sapludināšanas stāvoklis visiem šiem objektiem. Tātad AP sistēmas ir šis. KP sistēmām nav vajadzīga jāuztraucas par to. Jo, tiklīdz starpsienu nāk spēlē, viņi vienkārši pārtrauciet raksta. LABI? Tātad tas ir ļoti viegli risinātu konsekventi ja jums nav pieņemt nekādus atjauninājumus. Tas ir ar CP sistēmas darīt. Viss kārtībā. 

So parunāsim mazliet bit par piekļuves modeļiem. Kad mēs runājam par NoSQL, tas ir Viss par piekļuves modeli. Tagad, SQL ir ad hoc, vaicājumus. Tas ir relāciju veikals. Mums nav jāuztraucas par piekļuves modeli. Es uzrakstīt ļoti sarežģītu jautājumu. Tā iet un saņem datus. Tas, ko tas izskatās piemēram, normalizācija. 

Tātad šajā konkrētajā struktūrā, mēs meklējam pie produktu katalogu. Man ir dažāda veida produktus. Man ir grāmatas. Man ir albumus. Man ir video. Attiecības starp produktiem un kāds no šīm grāmatām, albumi, un video tabulas ir 1: 1. Viss kārtībā? Man produkta ID, un ka ID Atbilst uz grāmatu, albumu, vai video. LABI? Tas ir 1: 1 attiecības pāri šīm tabulām. 

Tagad, books-- visi viņi ir, ir sakņu īpašības. Nekādu problēmu. Tas ir lieliski. One-to-one attiecības, man visi dati man ir nepieciešams, lai aprakstītu šo grāmatu. Albums-- albums ir dziesmas. Tas ir tas, ko mēs saucam viens pret daudziem. Katrs albums varētu būt daudzas dziesmas. Tātad par katru dziesmu par albumu, es varētu būt vēl viens rekords šajā bērnu galda. Tāpēc es izveidot vienu ierakstu manā albumu tabulā. Es izveidot vairākus ierakstus in dziesmas tabulā. Viens pret daudziem attiecības. 

Šīs attiecības ir kas mēs aicinām daudzi pret daudziem. LABI? Jūs redzēsiet, ka dalībnieki varētu būt daudzās filmās, daudzi video. Tātad, ko mēs darām, ir mēs ieliekam šo kartēšanu galds starp tiem, kuriem tas vienkārši kartes aktieris ID video ID. Tagad es varu izveidot vaicājumu, pievienojas videoklipus, izmantojot aktieri video dalībniekiem, un tas dod man jauku sarakstu visas filmas un visi dalībnieki kas bija šajā filmā. 

LABI. Tātad, šeit mēs iet. One-to-one ir augstākā līmeņa attiecības; viens pret daudziem, albumi dziesmas; daudzi pret daudziem. Tie ir trīs augstākā līmeņa attiecības jebkuru datu bāzi. Ja jūs zināt, kā tie, attiecības strādāt kopā, tad jūs zināt daudz par datu bāzē jau. Tātad NoSQL darbojas nedaudz atšķirīgi. Padomāsim par par otro, ko tā Izskatās, iet saņemt visus savus produktus. 

Relāciju veikalā, es vēlos saņemt visus savus produktus par sarakstu ar visiem maniem produktiem. Tas ir daudz vaicājumiem. Man vaicājumu par visiem maniem grāmatām. Man vaicājumu no maniem albumiem. Un es saņēmu vaicājumu par visiem maniem video. Un es saņēmu nodot to visi kopā sarakstā un kalpot tai atpakaļ līdz programma, kas ir to pieprasa. 

Lai iegūtu manas grāmatas, es pievienojos Produkti un grāmatas. Lai saņemtu manus albumus, es saņēmu pievienoties Produkti, Albumi, un dziesmas. Un, lai saņemtu manu video, man ir pievienoties Produkti, video, pievienoties caur Aktieris video, un ienest aktieriem. Tā ka ir trīs jautājumiem. Ļoti sarežģītu jautājumu līdz montēt vienu rezultātu kopu. 

Tas ir mazāk nekā optimāls. Tas ir tāpēc, kad mēs runājam par datu struktūru, kas ir būvēts būt agnostiķis ar piekļuvi pattern-- arī tas ir lieliski. Un jūs varat redzēt, tas ir patiešām jauki, cik mēs esam organizēti datus. Un jūs zināt, ko? Man ir tikai viens ieraksts par aktieris. 

Tas ir forši. Esmu deduplicated visas manas dalībniekus, un es uztur manu asociācijas Šajā kartēšanas tabulā. Tomēr kļūst datus ārā kļūst dārgāka. Es esmu nosūtot CPU visā sistēmā savieno šos datu struktūras kopā lai varētu pull, ka datus atpakaļ. 

Tātad, kā es varu saņemt ap to? In NoSQL tas ir par apkopošana, ne normalizācija. Tāpēc mēs vēlamies teikt, ka mēs vēlamies, lai atbalstīt piekļuves modeli. Ja piekļuves modeli pieteikumiem, Man vajag, lai saņemtu visus savus produktus. Palūkosimies visus produktus vienā tabulā. Ja man visus produktus vienā tabulā, Es varu tikai izvēlēties visus produktus No šīs tabulas un man to visu. Nu kā es varu darīt? Nu NoSQL tur nav struktūra uz galda. Mēs runājam mazliet par kā tas darbojas Dinamo DB. Bet jums nav tas pats atribūti un tās pašas īpašības katrā atsevišķā rindā, katrā atsevišķā posteni, kā jūs darīt, SQL tabulā. Un ko tas dod man to darīt, ir daudz lietas un dod man lielu elastību. Šajā konkrētajā gadījumā, es ir mans produkts dokumentus. Un šajā konkrētajā Piemēram, viss ir dokuments, ar produktiem tabulā. Un produkts grāmatas varētu ir tipa ID, kas nosaka grāmatu. Un pieteikums varētu pāriet uz šo ID. 

Pēc pieteikuma līmeņa, es eju teikt ak, kāda ieraksta tips tas ir? Ak, tas ir grāmata ieraksts. Grāmatu ieraksti ir šīs īpašības. Ļaujiet man izveidot grāmatu objektu. Tāpēc es esmu gatavojas aizpildīt grāmata objekts ar šo posteni. Nākamā prece nāk un saka, kas ir šo ziņu? Nu šis postenis ir albums. Ak, es saņēmu visai atšķirīgs apstrāde rutīnas, ka, jo tas ir albums. Redzi, ko es domāju? 

Tātad pieteikums tier-- I vienkārši izvēlieties visus šos ierakstus. Viņi visi sāk nāk. Tie varētu būt visi dažādu veidu. Un tas ir, piemērojot loģika kas pārslēdz pāri šiem veidiem un nolemj, kā tos apstrādāt. 

Atkal, tāpēc mēs esam optimizēt shēma par piekļuves modeli. Mēs darām to, ko sabrukšanu šīm tabulām. Mēs būtībā ņemot šie normalizēto struktūras, un mēs esam celtniecības hierarhiskās struktūras. Inside katru no šiem ierakstiem Es esmu gatavojas redzēt masīvu īpašības. 

Inside šī dokumenta albumos, Es esmu redzēt masīvus dziesmas. Šīs dziesmas tagad become-- tas ir Būtībā šis bērns tabula ka eksistē tepat šajā struktūrā. Tātad jūs varat izdarīt DynamoDB. Jūs varat izdarīt MongoDB. To var izdarīt jebkurā NoSQL datu bāzē. Izveidojiet šos tipus hierarhijas datu struktūras kas ļauj jums iegūt datus ļoti ātri, jo tagad es nav jāatbilst. Kad es ievietotu rindu uz sliedēm galds, vai rinda uz albumi tabulā, Man ir jāatbilst šo shēmu. Man ir jābūt atribūtu meklētājam vai īpašums, kas ir noteikts par šī galda. Ik viens no tiem, kad es ievietot šo rindu. Tas nav gadījums NoSQL. 

Es varu būt pilnīgi atšķirīgi īpašības katru dokumentu ka es ievietot kolekcijā. Tik ļoti spēcīgs mehānisms. Un tas tiešām ir, kā jūs optimizēt sistēmu. Jo tagad, vaicājumu, nevis pievienoties visas šīs tabulas un izpildot pusi duci vaicājumu vilkt atpakaļ datus man ir nepieciešams, Es esmu izpildot vienu vaicājumu. Un es esmu atkārtojot pāri noteiktajiem rezultātiem. tas dod jums ideja no jaudas NoSQL. Es esmu gatavojas veida iet sāniski šeit un runāt mazliet par to. Tas ir vairāk sava veida tirdzniecības vai technology-- mārketinga tehnoloģijas diskusijas veids. Bet tas ir svarīgi saprast jo, ja mēs skatāmies uz augšu šeit šajā diagrammā, mēs esam apskatot ko ir tas, ko mēs saucam par tehnoloģija hype līkne. Un ko tas nozīmē, Jaunais sīkumi sāk spēlēt. Cilvēki domā, tas ir lieliski. Es esmu atrisinājis visas manas problēmas. 

Tas varētu būt beigas visi, būs visiem visu. Un viņi sāk to izmantot. Un viņi saka, šī stuff nedarbojas. Tas nav pareizi. Vecais sīkumi bija labāks. Un viņi iet atpakaļ, lai dara lietas, kā viņi bija. Un tad beidzot viņi iet, jūs zināt, ko? Šī stuff nav tik slikti. Ak, tas ir, kā tas darbojas. Un, kad viņi izdomāt, kā to darbi, viņi sāk kļūst labāk. 

Un smieklīgi lieta par to ir, tā veida līniju līdz ko mēs saucam par tehnoloģiju pārņemšana līkni. Tātad, kas notiek, ir mums kaut kāda tehnoloģija sliekšņa. Attiecībā uz datu bāzēm, tas ir dati spiediens. Mēs runājām par augstu ūdens ņemšanas vietas Datu spiediena visā laika. Ja, ka dati spiediens hits noteiktu punkts, tas ir tehnoloģija sprūda. 

Tas kļūst pārāk dārga. Tas aizņem pārāk ilgu laiku, lai apstrādātu datus. Mums vajag kaut ko labāku. Jūs saņemsiet novatorus kas tur skraida, mēģina noskaidrot, kas ir risinājums. Kas ir jauna ideja? 

Kas ir nākamais labākais veids, kā to darīt šo lietu? Un viņi nāk klajā ar kaut ko. Un cilvēki ar reālo sāpēm, puiši pie asiņošana malu, tie būs lēkt pa visu to, jo tie ir atbilde. Tagad to, kas neizbēgami happens-- un tas notiek tieši tagad NoSQL. Es to redzu visu laiku. 

Kas neizbēgami notiek, ir cilvēki sāk izmantot jauno instrumentu tāpat viņi izmantoja veco rīks. Un viņi uzzinātu, to nedarbojas tik labi. Es nevaru atcerēties, kas es esmu runājot ar agrāk šodien. Bet tas ir tāpat, kad Pneimatiskais āmurs tika izgudrots, cilvēki nav šūpoles pāri to galvenais sagraut betona. 

Bet tas ir tas, kas ir notiek ar NoSQL šodien. Ja jūs staigāt, lai lielākā daļa veikalu, viņi cenšas būt NoSQL veikali. Ko viņi dara, ir viņi izmanto NoSQL, un viņi ielādējot to pilns ar relāciju shēmu. Jo tas, kā viņi dizains datubāzes. Un viņi jautājums, kāpēc ir tas nedarbojas ļoti labi? Boy, šī lieta smird. Man bija saglabāt visu manu pievienojas in-- tas ir, piemēram, nē, nē. Uzturēt pievienojas? Kāpēc jūs pievienoties datus? Jums nav pievienoties dati NoSQL. Jūs apkopot to. 

Tātad, ja jūs vēlaties, lai no tā izvairītos, mācīties kā instruments darbojas, pirms jūs faktiski sākt to lietot. Nemēģiniet un izmantot jaunus instrumentus Tāpat jūs izmantojāt senos darba rīkus. Jūs esat nāksies slikta pieredze. Un katru reizi, kad tas, kas tas ir par. Kad mēs sākam nāk šurp, tas ir tāpēc, ka cilvēki izpētījuši, kā izmantot instrumentus. 

Viņi darīja to pašu, kad relāciju datubāzes tika izgudrots, un tie tika aizstāt failu sistēmas. Viņi centās veidot failu sistēmas ar relāciju datu bāzēm jo tas, ko cilvēki saprot. Tas nestrādāja. Tātad izpratne labāko praksi no tehnoloģijām jūs strādājat ar ir milzīgs. Ļoti svarīgs. 

Tātad mēs ejam, lai nokļūt DynamoDB. DynamoDB ir AWS s pilnībā pārvalda NoSQL platformu. Kāda pilnībā pārvalda nozīmē? Tas nozīmē, ka Jums nav nepieciešams tiešām jāuztraucas par neko. 

Tu nāc, jūs pastāstīt mums, man ir nepieciešams galds. Tai ir tik daudz jaudas. Jūs hit pogu, un mēs noteikums visa infrastruktūra aiz skatuves. Tagad tas ir milzīgs. 

Jo, kad jūs runājat par mērogošana datu bāzi, NoSQL datu kopas at skala, skriešanas petabytes, rādīt miljoniem darījumiem sekundē, šīs lietas nav mazas kopas. Mēs runājam tūkstošiem instancēs. Managing tūkstošiem gadījumu, pat virtuālo gadījumi, ir reālas sāpes muca. Es domāju, domāju, ka par katru reizi, kad operētājsistēma plāksteris nāk ārā vai jaunu versiju datu bāzē. Ko tas nozīmē ar jums operatīvi? Tas nozīmē, ka jums 1200 serveriem, kas ir jāatjaunina. Tagad pat ar automatizāciju, kas var aizņemt ilgu laiku. Tas var izraisīt daudz darbības galvassāpes, jo es varētu būt pakalpojumi leju. 

Kā es varu atjaunināt šīs datu bāzes, I varētu darīt zils zaļš izvietošanu kur es izmantot un uzlabot manu pusi mezglus, un pēc tam paaugstināt otru pusi. Veikt tos uz leju. Tātad pārvaldīt infrastruktūru skala ir ļoti sāpīga. Un AWS pieņemt, ka sāpes no tā. Un NoSQL datubāzēm būt ārkārtīgi sāpīga jo, kā viņi skalu. 

Scale horizontāli. Ja jūs vēlaties, lai iegūtu lielāku NoSQL datubāzes, jūs pērkat vairāk mezgliem. Katrs mezgls jūs pērkat, ir cits operatīvā galvassāpes. So let kāds cits darīt jums. AWS var darīt. 

Mēs atbalstām dokuments galvenās vērtības. Tagad mēs negāja pārāk daudz vērā no otras chart. Tur ir daudz dažādi flavors NoSQL. Viņi visu veidu, kā iegūt munged kopā šajā brīdī. Jūs varat ielūkoties DynamoDB un saka, jā, mēs abi esam dokuments un galvenā vērtība uzglabāt šo punktu. Un jūs varat apgalvot funkcijas no pār otru. Lai man, daudz tas ir patiešām seši no vienas Pusduci no otras puses. Ikviens no šīm tehnoloģijām ir smalkās tehnoloģijas un soda risinājumu. Es neteiktu, ka MongoDB ir labāks vai sliktāks nekā dīvāna, tad Cassandra, tad Dynamo, vai otrādi. Es domāju, tie ir tikai iespējas. 

Tas ir ātri un tas ir konsekventa jebkurā mērogā. Tātad šis ir viens no lielākajiem prēmijas jums ar AWS. Ar DynamoDB ir spēja lai iegūtu zemu vienu ciparu milisekunžu latentuma jebkurā mērogā. Ka bija konstrukcija mērķis sistēmas. Un mums ir klienti, kas dara miljoniem darījumu sekundē. 

Tagad es iešu cauri dažiem no tiem, lietošanas gadījumi pēc dažām minūtēm šeit. Integrētā pieeja control-- mēs esam tas, ko mēs saucam Identity Access Management, vai IAM. Tas caurvij ikvienu sistēmu, katrs pakalpojums, kas AWS piedāvā. DynamoDB nav izņēmums. Jūs varat kontrolēt piekļuvi uz DynamoDB tabulām. Visās jūsu AWS kontus, ko nosakot piekļuves lomas un atļaujas IAM infrastruktūrā. 

Un tas ir galvenais un neatņemama sastāvdaļa tas, ko mēs saucam Event Dzenošā programmēšana. Tagad tas ir jauna paradigma. 

Mērķauditorija: Kā ir jūsu likme ir taisnība pozitīvi, salīdzinot ar viltus negatīviem Jūsu piekļuves kontroles sistēmu? RICK Houlihan: True pozitīvi pret viltus negatīvi? Mērķauditorija: Atgriežoties ko Jums vajadzētu atgriezties? Atšķirībā reizi brītiņa tas neatgriežas, ja tas būtu jāapstiprina? 

RICK Houlihan: Es nevarēju pateikt, ka. Ja tur ir kādi neveiksmes nekādā veidā, ka, Es neesmu cilvēks jautāt ka attiecīgais jautājums. Bet tas ir labs jautājums. Es būtu ziņkārīgs zināt ka sevi, faktiski. 

Un tā tad atkal, jaunā paradigma ir notikums virza programmēšana. Tā ir ideja, ka jūs varat izvietot sarežģītas programmas, var darboties ļoti, ļoti liels skalu bez infrastruktūras whatsoever. Bez noteikta infrastruktūra whatsoever. Un mēs runājam mazliet par to, ko tas nozīmē, kā mēs nokļūt uz nākamo pāris kartēm. 

Pirmā lieta, ko mēs darīsim ir mēs runājam par tabulām. API datu tipi Dynamo. Un pirmā lieta, jūs paziņojums, ja paskatās uz to, Ja Jūs esat iepazinušies ar jebkuru datu bāzi, datubāzes ir patiešām divas veida API Es gribētu to sauc. Vai divas API. Viens no tiem varētu būt administratīvais API. 

Lietas, viņi rūpējas par funkcijas datubāzes. Uzglabāšanas dzinēju konfigurēšana, izveidojot un pievienojot tabulas. izveidojot datubāzi katalogi un gadījumi. Tie things-- in DynamoDB, jūs ir ļoti īsus, īsus sarakstus. 

Tātad citām datu bāzēm, jūs varētu redzēt desmitiem no komandas, no administratīvā komandas, konfigurēšanu šie papildu iespējas. In DynamoDB jums nav nepieciešams tos, jo Jums nav konfigurēt sistēmu, mēs to darām. Tātad vienīgā lieta, kas jums jādara, ir man pateikt, kāda izmēra galds man vajag. Tātad jūs saņemsiet ļoti ierobežots noteikts komandu. 

Jūs saņemsiet izveidot tabulu Update, galda, Dzēst tabulu, un aprakstītu galda. Tie ir tikai lietas Jums nepieciešams DynamoDB. Jums nav nepieciešams uzglabāšanu dzinēja konfigurācija. Man nav jāuztraucas par replikāciju. Man nav jāuztraucas par sharding. 

Man nav jāuztraucas par kādu no šo stuff. Mēs darām visu, lai jums. Tātad tas ir milzīgs daudzums virs galvas kas ir vienkārši pacelts jūsu plate. Tad mums ir Crud operatoriem. Crud ir kaut ko mēs zvanīt datu bāzē, kas ir Izveidot, Update, Delete operatoriem. Tie ir jūsu kopējā datu bāzes darbību. Lietas, piemēram, put posteni, iegūt objektu, atjauninājumu priekšmeti, svītrot tos, partijas vaicājumu, skenēt. Ja vēlaties skenēt visu tabulu. Pull viss pie galda. Viens no nice lietas par DynamoDB tas ļauj paralēli skenēšana. Tātad jūs faktiski var ļaujiet man zināt, cik daudz pavedieni jūs vēlaties palaist šo skenēšanu. Un mēs varam palaist šos pavedienus. Mēs varam spin ka skenēt up vairākiem diegiem lai jūs varētu skenēt visu tabulu telpa ļoti, ļoti ātri DynamoDB. 

Otrs API mums ir tas, ko mēs saucam par mūsu plūsmas API. Mēs nebrauksim runāt pārāk daudz par to tieši tagad. Man daži saturs vēlāk uz klāja par to. Bet Streams ir patiešām running-- domāt par to, kā laiks pasūtīt un starpsienu izmaiņas log. Viss, kas notiek uz tabula rāda uz augšu uz plūsmā. 

Katru rakstiet uz galda parādās uz strauta. Jūs varat izlasīt šo straumi, un jūs varat darīt lietas ar to. Mēs runājam par to, ko veidu lietas, jums darīt ar, piemēram, replikācijas lietām, rada tālāku indeksi. Visi tiešām foršs veidi lietas jūs varat darīt ar to. 

Datu tipi. In DynamoDB, mēs atbalstām gan atslēga vērtību un dokumentu datu tipi. Uz kreisajā pusē ekrāna šeit, mēs esam ieguvuši mūsu pamata veidi. Galvenās vērtības veidi. Tie ir stīgas, numurus un binaries. 

Tātad tikai trīs pamatveidi. Un tad jūs varat būt komplekti tiem. Viens no nice lietas par NoSQL ir Jūs varat saturēt blokiem, kā īpašības. Un ar DynamoDB jūs var saturēt bloki no pamatgrupās kā saknes īpašumu. 

Un tad tur ir dokumentu veidus. Cik daudz cilvēku ir iepazinušies ar JSON? Jūs puiši iepazinušies ar JSON tik daudz? Tas būtībā JavaScript, Objekts, Apzīmējumi. Tas ļauj jums, lai būtībā noteikt hierarhisku struktūru. 

Jūs varat uzglabāt JSON dokumentu DynamoDB izmantojot kopīgas sastāvdaļas vai celtniecības blokiem, kas ir pieejami vairumā programmēšanas valodas. Tātad, ja jums ir Java, jūs esat Aplūkojot kartes un sarakstiem. Es varu izveidot objektus, ka platība karte. Karte, kā galvenajām vērtībām saglabāts kā īpašības. Un tas varētu būt sarakstus vērtībām šajās īpašībām. Jūs varat uzglabāt šo kompleksu hierarhiskā struktūra kā vienu atribūtu no DynamoDB posteni. 

Tātad tabulām DynamoDB, tāpat kā lielākā daļa NoSQL datu bāzes, tabulas ir pozīcijas. In MongoDB turat zvaniet šos dokumentus. Un tas būtu dīvāns bāze. Arī dokumentu datu bāzes. Jūs zvanīt šos dokumentus. Dokumenti vai posteņi ir atribūtus. Atribūti var pastāvēt vai nepastāv uz objektu. In DynamoDB, tur ir viens obligāts atribūts. Tāpat kā relāciju datu bāzē, Jums ir primārā atslēga uz galda. 

DynamoDB ir tas, ko mēs saucam hash taustiņu. Hash galvenais jābūt unikālam. Tātad, kad es noteikt hash tabulu, būtībā tas, ko es saku ir katrs punkts būs hash taustiņu. Un katru hash Galvenais jābūt unikālam. 

Katrs punkts ir definēts ar šo unikālo hash atslēgu. Un tur var būt tikai viens. Tas ir OK, bet nereti ko cilvēki ir nepieciešams ir viņi vēlas, ir tas hash Galvenais, lai darīt mazliet vairāk nekā vienkārši unikāls identifikators. Bieži mēs vēlamies izmantot šo hash atslēga kā top līmeņa apkopošanas spainī. Un kā mēs darīt, ir, piebilstot, ko mēs saucam virkni taustiņu. 

Tātad, ja tas ir tikai hash galds, tas ir unikāls. Ja tas ir hash un diapazons galds, kombinācija hash un diapazons jābūt unikālam. Tāpēc domāju par to šādā veidā. Ja man ir forums. Un forma ir tēmas, tas ir amatu, un tā ir atbildes. 

Tāpēc es varētu būt hash atslēga, kas ir tēmu ID. Un es varētu būt virkne atslēgu, kas ir atbilde ID. Tādā veidā, ja es vēlos saņemt visus Atbildes uz konkrētu tēmu, Es varu tikai vaicājumu hash. Es varu tikai teikt, dod man visu preces, kas ir šī hash. Un es esmu gatavojas saņemt katru jautājumu vai pastu par konkrēto tēmu. Šie top līmeņa kolonijas ir ļoti svarīgi. Viņi atbalsta primāro piekļuvi modelis pieteikumu. Vispārēji runājot, šis ir tas, ko mēs vēlamies darīt. Mēs gribam, lai table-- kā jūs ielādēt tabulu, mēs vēlamies, lai strukturētu datu tabulas ietvaros, tādā veidā, ka pieteikumu var ļoti ātri ielādēt šos rezultātus. Un nereti veids, kā to darīt, ir saglabāt šos apkopojumus, kā mēs ievietot datus. Būtībā, mēs izplatot datus uz spilgti spainī, kā tas nāk. 

Vidējā klase taustiņi ļauj me-- hash atslēgas jābūt vienlīdzība. Kad es vaicājumu hash, man jāsaka man hash kas vienāds šis. Kad es vaicājumu diapazonu, es var teikt man diapazonu kas izmanto jebkura veida bagāts uzņēmējs, ka mēs atbalstām. Dodiet man visus priekšmetus jaucējkoda. Tas ir vienāds, lielāks nekā, mazāk nekā, tas sākas ar, tā pastāv starp šīm divām vērtībām? Tātad šie diapazona vaicājumu veidi ka mēs esam vienmēr ieinteresēti. Tagad viena lieta par datiem, kad paskatās piekļūt datiem, kad jums piekļūt datiem, tas ir vienmēr par summēšanu. Tas vienmēr ir par ierakstiem kas ir saistīti ar to. Dodiet man viss šeit that's-- visu darījumi par šo kredītkarti par pēdējo mēnesi. Tas ir summēšana. 

Gandrīz viss, kas jums darīt Datu bāze ir sava veida apkopošanu. Tā ir iespēja, lai varētu noteikt tie spaiņi un dot jums šo klāstu atribūtus, lai varētu vaicājumu par, šie bagāti vaicājumus atbalstīt daudz, daudz, daudz pieteikumu piekļuves modeļus. 

Tātad otra lieta hash atslēgu Vai tas dod mums mehānismu lai varētu izplatīt datus apkārt. NoSQL datubāzes darbojas vislabāk kad dati ir vienmērīgi izplatīti visā klasterī. Cik daudzi cilvēki ir iepazinušies ar sajaukšanai algoritmi? Kad es saku hash un hashing-- jo sajaukšanai algoritmu ir veids, kas spēj radīt izlases vērtība, no jebkurā vērtībā. Tātad šajā konkrētajā gadījumā hash algoritms mēs palaist ir ND 5 pamatā. 

Un, ja man ir ID, un tas ir mans hash galvenais, man ir 1, 2, 3. Kad es palaist hash algoritmu, tas nāks atpakaļ un saka, labi 1 vienāds 7b, 2 vienāds 48, 3. vienāds CD. Viņi izplatās pa visu galveno telpu. Un kāpēc jūs darīt? Jo tas padara pārliecināts, ka es varu ielieciet ierakstus vairākiem mezgliem. 

Ja es esmu to izdarīt pakāpeniski, 1, 2, 3. Un man ir hash diapazonu, kas Darbojas šajā konkrētajā gadījumā, mazs hash telpa, tas ilgst no 00 līdz FF, tad ieraksti gatavojas nākt un viņi, kas iet 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. Kas notiek? Katrs ieliktnis, kas notiek ar to pašu mezglā. Redzi, ko es domāju? 

Jo, kad es sadalīt telpu, un es izplatīt šos ierakstus pāri, un es starpsienu, es esmu gatavojas teikt nodalījums 1 ir galvenais telpas 0 līdz 54. Sadalīšanās 2 ir 55 līdz 89. Sadalīšanās 3 ir AA līdz FF. Tātad, ja es esmu, izmantojot lineāri palielināšanai ID, jūs varat redzēt, kas notiek. 1, 2, 3, 4, 5, 6, visi ceļu līdz 54. Tā kā es esmu kalšanai ieraksti sistēmā, viss beidzas dodas uz vienu mezglu. 

Tas nav labi. Tas ir antipattern. In MongoDB viņiem ir šī problēma ja jūs neizmantojat hash taustiņu. MongoDB dod jums iespēju no sajaukšanai galveno vērtību. Jums vienmēr vajadzētu darīt, ja lietojat palielināšanai hash Ievadiet MongoDB, vai jūs būsiet naglām ik rakstiet vienu mezglu, un jums tiks ierobežot Jūsu rakstīt caurlaide slikti. 

Mērķauditorija: Vai tas A9 169 aiz komata? 

RICK Houlihan: Jā, tas ir kaut kur ap tur. A9, es nezinu. Jūs ir, lai saņemtu savu bināro lai aiz kalkulatoru. Manas smadzenes nedarbojas, piemēram, ka. Mērķauditorija: Just a quick vienu Sava Mongo komentārus. Tātad ir objekts ID, kas nāk natively ar Mongo darīt? RICK Houlihan: Vai tā darīt? Ja jūs norādiet to. Ar MongoDB, jums ir iespēja. Jūs varat specify-- katru dokumentu MongoDB ir jābūt pasvītrojumu ID. Tas ir unikāla vērtība. 

In MongoDB varat norādīt vai hash vai nē. Viņi tikai dod jums iespēju. Ja jūs zināt, ka tas ir izlases, nekādu problēmu. Jums nav nepieciešams, lai to izdarītu. Ja jūs zināt, ka tas nav nejauši, ka tas ir palielināšanai, tad darīt to hash. 

Tagad lieta par sajaukšanai, kad jūs hash value-- un tas ir Kāpēc hash taustiņi vienmēr unikālie vaicājumi, jo es esmu mainījies vērtība, tagad es nevaru darīt virkni jautājumu. Es nevaru teikt, tas ir starp to vai citu, jo hash vērtība nav dodas būt līdzvērtīga faktiskajai vērtībai. Tātad, ja jūs hash ka Galvenais, tas ir tikai vienlīdzību. Tas ir iemesls, kāpēc DynamoDB hash atslēgā vaicājumi vienmēr ir tikai vienlīdzību. 

Tāpēc tagad diapazonā key-- kad es pievienoju šajā diapazonā atslēga, šie klāsts galvenie ieraksti viss nāk un tie saņemt saglabāti tajā pašā nodalījumā. Tātad tie ir ļoti ātri, viegli izgūti jo tas ir hash, tas ir diapazons. Un jūs redzat visu ar tādu pašu hash izpaužas uzglabā tajā pašā nodalījumā telpā. Jūs varat izmantot šo diapazons taustiņu, lai palīdzētu atrodiet savus datus tuvu tās vecākiem. Tātad, ko es patiešām dara šeit? Tas ir viens daudziem attiecības. Attiecības starp hash atslēgu un diapazons galvenais ir viens daudziem. Es varu būt vairākas hash atslēgas. Es varu būt tikai vairākas klāsts Atslēgas laikā katru hash taustiņu. 

Hash nosaka vecāks, diapazons definē bērnus. Tātad jūs varat redzēt, tur ir analogs šeit starp relāciju konstrukcijas un tie paši veidi konstrukcijas in NoSQL. Cilvēki runā par NoSQL kā nonrelational. Tas nav nonrelational. Datu vienmēr ir attiecības. Šīs attiecības tikko tiek modelēta savādāk. Parunāsim nedaudz bit par izturību. Kad jūs rakstīt DynamoDB, raksta vienmēr ir trīsceļu atkārtot. Tas nozīmē, ka mums ir trīs AZ. AZ ir Pieejamība zonas. Jūs varat domāt par pieejamību Zona kā datu centrā vai kolekcija datu centriem. Šīs lietas ir ģeogrāfiski izolēti viens no otra dažādās bojājuma zonās, pāri atšķirīgs energosistēmas un palieņu. Traucējumi vienā AZ nav iet, lai ņemtu nosaka citu. Tās ir saistītas arī kopā ar tumšās šķiedras. Tā atbalsta vienu sub 1 milisekunžu latentuma starp AZS. Tātad reālā laika datus replikācijas spējīgi multi AZS. 

Un nereti multi AZ izvietošanu sasniegtu augstu pieejamības prasības vairumā uzņēmumu organizāciju. Tātad DynamoDB izplatās pāri trim AZS pēc noklusējuma. Mēs esam tikai gatavojas zināšanām rakstīt kad divi no šiem trim punktiem atgriezties un teikt, jā, es saņēmu to. Kāpēc ir tā, ka? Jo par lasīšanas puses mēs esam tikai gatavojas sniegt jums datus atpakaļ, kad mēs to no diviem mezgliem. 

Ja es esmu replicē pāri trīs, un es esmu lasījums no diviem, Es esmu vienmēr garantēta lai ir vismaz viens no tiem skan būt lielākā daļa pašreizējo kopiju datiem. Tas, kas padara DynamoDB konsekventa. Tagad jūs varat izvēlēties, lai ieslēgtu tie saskan nolasa. Tādā gadījumā es esmu gatavojas teikt, Es izlasīju tikai no viena mezgla. Un es nevaru garantēt, ka tas notiek, būt visvairāk pašreizējie dati. 

Tātad, ja rakstīt nāk, tas vēl nav kopēt, jūs gatavojas iegūt šo kopiju. Tas ir beidzot konsekventi lasīt. Un kas tas ir, ir puse no izmaksām. Tātad tas ir kaut kas domāt par. Kad jūs lasāt out DynamoDB, un jūs izveidot savu lasīšanas spējas vienības, ja jūs izvēlaties beidzot konsekventa skan, tas ir daudz lētāk, tas ir par pusi izmaksu. 

Un tā tas ietaupa jūsu naudu. Bet tas ir jūsu izvēle. Ja vēlaties konsekventu lasīt vai beidzot konsekventi lasīt. Tas ir kaut kas, ka jūs varat izvēlēties. 

Parunāsim par indeksu. Tātad mēs minēts, ka augstākā līmeņa apkopošana. Mēs esam ieguvuši hash atslēgas, un mēs esam ieguvuši diapazons atslēgas. Tas ir jauki. Un tas ir par primāro galda, es ieguva vienu hash atslēga, es saņēmu vienu diapazons taustiņu. 

Ko tas nozīmē? Man viens atribūts, ka es var palaist bagāts vaicājumus. Tas ir diapazons taustiņu. Pārējie atribūti par šo item-- Es varu filtrēt uz šiem atribūtiem. Bet es nevaru darīt lietas, piemēram, to sākas ar, vai ir lielāka nekā. 

Kā es varu darīt? Es izveidot indeksu. Ir divu veidu indeksi DynamoDB. Indekss ir patiešām cits skats uz galda. Un vietējā sekundārs rādītājs. 

Pirmais mēs runājam par. Tāpēc vietējie secondaries ir līdzās tajā pašā nodalījumā kā datiem. Un kā tādi, tie ir pats fiziskās mezglā. Tie ir tas, ko mēs saucam konsekventa. Nozīme, viņi atzīst, rakstīšanas kopā ar tabulā. Kad rakstīt nāk, mēs rakstīt, izmantojot indeksu. Mēs rakstīt pie galda, un tad mēs atzīstam. Tātad tas ir konsekventa. Kad rakstīt ir atzīts no galda, tas ir garantēts, ka vietējais sekundārā indekss būs tajā pašā redzamības datus. Bet ko tie ļauj jums darīt, ir definēt aizstājējus diapazons atslēgas. 

Ir izmantot to pašu hash Galvenais kā primāro galda, jo tie vienlaikus atrodas uz pats nodalījums, un viņi konsekventi. Bet es varu izveidot indeksu ar dažādās areāla atslēgām. Tā, piemēram, ja man bija ražotājs ka bija neapstrādātu daļas tabulu nāk. Un izejvielas daļas nāk, un viņi apkopotais montāža. Un varbūt tur ir atgādināt. 

Jebkura daļa, kas tika veikts ar šo ražotājs pēc šī datuma, Man vajag, lai vilktu no manas līnijas. Es varu spin indekss ka būtu meklē, apkopojot dienā ražošana no konkrēto daļu. Tātad, ja mans augstākā līmeņa galds bija jau sajaukts ar ražotāja varbūt tā bija izvietots uz nepilnu ID, es var izveidot indeksu off tabulas kā sajaukts ar ražotāja un svārstījās no ražošanas datuma. Un tas veids, kā es varētu teikt, kaut kas starp šiem datumiem ir ražots, Man vajag, lai vilktu no līnijas. Tātad tas ir vietējais sekundārs rādītājs. 

Tās ir sekas ierobežojot savu hash galveno vietu. Tāpēc, ka viņi kopīgi pastāvēja tajā pašā uzglabāšanas mezglā, tie ierobežo hash taustiņu telpa līdz 10 gigabaitiem. DynamoDB, saskaņā ar galdi, būs sadalīt jūsu galda ik pēc 10 gigabaitiem. Kad jūs nodot 10 gigs datu, mēs iet [PhH], un mēs pievienot citu mezglā. 

Mēs ne sadalīt LSI vairākās starpsienas. Mēs sadalīt tabulu. Bet mēs ne sadalīt LSI. Tātad tas ir kaut kas svarīgi saprast ir, ja jūs darāt ļoti, ļoti, ļoti lielas kolonijas, tad jūs esat būs ierobežota līdz 10 gigabaitiem jūsu LSIs. 

Ja tas ir gadījumā, mēs varam izmantot globālo secondaries. Globālie secondaries ir tiešām citā tabulā. Tie pastāv pilnīgi off pusē jūsu primāro galda. Un viņi ļauj man atrast pilnīgi atšķirīga struktūra. Tāpēc domāju par to, kā tiek ievietota informācija divās dažādās tabulās, strukturēta divos dažādos veidos. 

Es varu definēt pilnīgi atšķirīgs hash atslēgu. Es varu definēt pilnīgi atšķirīgs diapazons atslēgu. Un es varu palaist šo pilnīgi patstāvīgi. Kā Faktiski, es esmu uzkrājumi manu lasīšanas spējas un rakstīt spēju manu pasaules sekundārās indeksi pilnīgi patstāvīgi mana primārā galda. Ja es definēt šo indeksu, es saku tas, cik daudz lasīt un rakstīt ietilpība tas būs izmantojot. 

Un tas ir atsevišķs no mana primārā galda. Tagad abiem indeksiem ļauj mums ne tikai definēt hash un rādiusa taustiņus, bet tie ļauj mums projekta papildu vērtības. Tātad, ja es gribu, lai nolasa indeksu, un es gribu iegūt kādu datu kopumu, Man nav nepieciešams, lai dotos atpakaļ uz galvenā tabula, lai iegūtu papildu atribūtus. Es varu projekta tos papildu atribūtus uz galda lai atbalstītu piekļuves modelis. Es zinu, ka mēs droši vien nokļūst daži tiešām, really-- nokļūst nezālēm šeit daži no šo stuff. Tagad es saņēmu drift no šīs. 

Mērķauditorija: [dzirdams] --table atslēga nozīmēja bija hash? Sākotnējais hash? Multi-līstes? 

RICK Houlihan: Jā. Jā. Tabula atslēga būtībā norāda atpakaļ uz posteni. Tātad indekss ir rādītājs atpakaļ sākotnējie priekšmetus uz galda. Tagad jūs varat izvēlēties, lai izveidotu indekss, kas ir tikai galda atslēgu, un nekādas citas īpašības. Un kāpēc es varētu darīt? Nu, varbūt man ir ļoti liels objektus. 

Man tiešām ir tikai jāzina which-- mana pieeja modelis varētu teikt, kas preces satur šo īpašumu? Nav nepieciešams atgriezt preci. Man vienkārši vajag zināt kas preces satur to. Tātad jūs varat veidot indeksus kas ir tikai galda taustiņu. 

Bet tas ir galvenokārt ko indekss datubāzē ir. Tas ir, lai to varētu ātri noteikt, kuras ieraksti, kas rindas, kas Preces tabulā ir īpašības, ka es esmu meklē. 

GSIs, tā kā tās darbojas? GSIs būtībā ir asinhronas. Atjauninājums nonāk tabulā, tabula ir tad asinhroni atjaunināta visiem jūsu GSIs. Tas ir iemesls, kāpēc ir GSIs beidzot konsekventa. 

Ir svarīgi atzīmēt, ka kad jūs esat celtniecības GSIs, un jūs saprotat, jūs veidojat cita dimensija aggregation-- Tagad pieņemsim, ka labs piemērs šeit ir ražotājs. Es domāju, ka es varētu būt runājuši par medicīnas ierīces ražotājs. Medicīnas ierīču ražotāji nereti ir serializēja daļas. Daļas, kas iet gūžas nomaiņa visu ir maz sērijas numuru par tiem. Un tie varētu būt miljoniem un miljoniem un miljardiem daļām visās ierīcēs, ka tie piegādā. Nu, viņiem ir nepieciešams apkopot zem dažādi izmēri, visas detaļas komplekta, visi daļas, kas tika veikti uz noteiktu līniju, visi daļām, kas nāca no noteiktā ražotāja noteiktā datumā. Un šīs kolonijas dažreiz piecelties uz miljardiem. 

Tāpēc es strādāju ar dažiem šie puiši, kuri cieš jo viņi radītu šie ginormous kolonijas to sekundāro indeksu. Tie varētu būt izejvielu daļas Tabulā, kas nāk kā vienīgo hash. Katru daļu ir unikāls sērijas numurs. Es izmantoju sērijas numuru, kā hash. Tas ir skaisti. Mans izejas dati tabula ir sadalīts visā atslēgu telpā. Mans [? rakstīt?] [? norīšana?] ir awesome. Es daudz datu. Tad ko viņi dara, ir tie rada GSI. Un es saku, jūs zināt, ko, man ir nepieciešams, lai redzētu visas daļas Šim ražotājam. Nu, visi pēkšņi es esmu Ņemot miljardu rindas, un stuff tos uz viens mezgls, jo, kad Es apkopot kā ražotājs ID kā hash, un daļas numurs kā diapazonā, tad visi pēkšņi es esmu liekot miljardu daļas par to, kas šis ražotājs ir mani izglāba. 

Tas var izraisīt daudz spiedienu uz GSI, atkal, jo es esmu kalšanai vienu mezglu. Es esmu liekot visiem šiem ievieto vienā mezglā. Un tas ir īsts problemātisks lietošanas gadījumu. Tagad, es saņēmu labu dizainu raksts par to, kā izvairīties no tā. Un tas ir viens no problēmām ka es vienmēr strādāt. Bet kas notiek, ir GSI varētu nav pietiekami daudz rakstīšanas spējas lai varētu virzīt visiem tiem rindas uz vienu mezglu. Un kas notiek, tad ir galvenais, klients galds, primārais tabula tiks mitināts jo GSI nevar sekot līdzi. Tāpēc mans ievietot likme krist uz primāro galda kā mans GSI cenšas sekot līdzi. 

Labi, tāpēc GSI s, LSI s, kuriem viens man vajadzētu izmantot? LSI s ir konsekventa. GSI s ir beidzot konsekventi. Ja tas ir OK, es ieteiktu izmantot GSI, viņi daudz elastīgāki. LSI s var modelēt kā GSI. Un, ja datu apjoms par hash atslēgām Jūsu kolekcija pārsniedz 10 gigabaitu, tad jūs gatavojas vēlaties izmantot ka GSI, jo tā ir tikai grūti robeža. 

Labi, tāpēc mērogošana. Caurlaide dinamo DB, jūs CAN noteikums [nedzirdama] caurlaidi uz galda. Mums ir klienti, kuriem ir nodrošināta 60 billion-- darāt 60 miljardus pieprasījumus, regulāri darbojas vairāk nekā miljons lūgumiem sekundē uz mūsu galdiem. Tur tiešām nav teorētiskā limits, cik daudz un cik ātri galds var palaist Dinamo DB. Ir daži soft ierobežojumus savā kontā ka mēs ieliekam tur tik ka jums nav iet crazy. Ja jūs vēlaties vairāk nekā ka nav problēma. Tu nāc pateikt mums. Mēs uzlocīt ripu. 

Katrs konts ir ierobežots zināmā līmenī katrā dienestā, tieši pie nūja tāpēc cilvēki nav iet crazy saņemt sevi nepatikšanas. Nekādu ierobežojumu lieluma. Jūs varat ievietot jebkuru numuru vienību uz galda. Posteņa lielums ir ierobežots līdz 400 kilobaitiem katra, tas būtu prece nav atribūti. Tātad no visiem atribūtiem summu ir ierobežots līdz 400 kilobaiti. Un tad atkal, mums ir ka maz LSI jautājums ar 10 gigabaitu limitu hash. Mērķauditorija: Mazs numurs, es esmu trūkst ko jūs man saki, ka is-- Mērķauditorija: Ak, 400 kilobaiti ir maksimālais izmērs vienība. Tātad postenis ir visas īpašības. Tātad 400 k ir kopējais izmērs šī posteņa, 400 kilobaitiem. Tātad no visiem atribūtiem kombinētie, visi dati tas ir visās šajās atribūtiem, rolled augšup kopējo platību, Pašlaik šodien postenis robeža ir 400 k. Tātad mērogošana atkal sasniegts caur sadalīšanu. Caurlaide tiek nodrošināta pie galda līmenī. Un tur tiešām divas pogas. Mēs esam iepazinušies jaudu un rakstīt spējas. 

Tātad tie ir pielāgoti neatkarīgi viena no otras. RCU s pasākums stingri konsekventa skan. Labi, tāpēc, ja jūs sakāt, es gribu 1000 RCU s tie ir stingri konsekventa, tie saskan skan. Ja jūs sakāt es gribu iespējamo konsekventa skan, Jūs varat noteikums 1000 RCU s, jūs gatavojas iegūt par 2000 beidzot konsekventa lasījuši. Un puse cena tiem beidzot veido skan. 

Atkal, koriģēts neatkarīgi viena no otras. Un tie ir throughput-- Ja tu patērē 100% no jūsu RCU, Jūs neesat gatavojas ietekmi uz pieejamība savām tiesībām. Tāpēc viņi ir pilnīgi neatkarīgi viens no otra. Labi, tāpēc viena no lietām, kas Es teicu īsi bija droselēšanas. Throttling ir slikti. Throttling norāda slikti nav SQL. Ir lietas, ko mēs varam darīt, lai palīdzētu jūs mazināt droselēšanas ka jums piedzīvo. Bet labākais risinājums ir tas, pieņemsim Paskaties, ko jūs darāt, jo tur ir anti-modelis spēlēt šeit. 

Šīs lietas, lietas, piemēram, nav vienotu darba slodze, karstie taustiņi, karstā starpsienas. Es esmu hitting īpašu atslēgu telpu ļoti grūti kādu īpašu iemeslu dēļ. Kāpēc man to izdarīt? Pieņemsim izdomāt. Es esmu sajaucot manu karsto datus ar aukstām datiem. Es esmu ļaujot manas tabulas nokļūt milzīgs, bet tur tiešām tikai daži apakškopa datu tas ir patiešām interesanti man. Tā, lai log datiem, piemēram, daudz klienti, viņiem log datus katru dienu. Viņi ieguva milzīgu žurnāla datiem. 

Ja jūs tikai dempinga visu šo žurnālu datu vienā lielā galda, laika gaitā ka tabula ir gatavojas saņemt milzīgi. Bet es esmu patiesi interesē tikai pēdējās 24 stundas, pēdējo septiņu dienu laikā, pēdējās 30 dienas. Neatkarīgi logs laika ka es esmu ieinteresēts meklē par notikumu, kas traucē man, vai notikums, kas ir interesanti man, tas ir vienīgais logs reize, kad man vajag. Tātad, kāpēc es esmu liekot 10 gadi vērts žurnāla datus tabulā? Kas tas ir izraisa galds fragments. 

Tas izpaužas milzīgs. Tā sākas izklāšana pāri tūkstošiem mezglu. Un tā kā jūsu spējas ir tik zems, jūs esat faktiski likme ierobežojot katrā viens no tiem atsevišķiem mezgliem. Tāpēc sāksim meklē veidus, kā mēs roll šo tabulu vairāk. Kā mēs vadīt, ka dati ir nedaudz labāk, lai izvairītos no šīs problēmas. Un ko tas izskatīsies? Tas ir tas, ka izskatās. Tas ir tas, ko slikts NoSQL izskatās. 

Man karsto taustiņu šeit. Ja paskatās uz pusi šeit, tie visi mani starpsienas. Man 16 nodalījumi šeit par šo konkrēto datu bāzē. Mēs to darām visu laiku. Es palaist šo klientiem visu laiku. To sauc par siltuma karte. Siltuma karte man stāsta, kā tu esi piekļūt jūsu atslēgu telpu. Un kas tas ir spēcīgi mani ir ka tur ir viens īpaši hash ka šis puisis patīk šausmīgi daudz, jo viņš ir hitting to tiešām, tiešām grūti. 

Tātad zilā ir jauki. Mums patīk zilā krāsā. Mums nepatīk sarkana. Red kur spiediens saņem līdz pat 100%. 100%, tagad jūs esat būs aizliegti. Tātad, ja jūs redzat sarkanās līnijas, piemēram, this-- un tas nav tikai Dynamo DB-- katrs NoSQL datu bāzē ir šī problēma. Ir anti-modeļus, kas var vadīt šos nosacījumu veidus. Ko man darīt, ir es strādāju ar klientiem lai atvieglotu šos nosacījumus. 

Un ko tas izskatīsies? Un tas kļūst visvairāk no Dynamo DB caurlaides, bet tas tiešām kļūst visvairāk no NoSQL. Tas neattiecas tikai uz Dinamo. Tas ir definitely-- I izmantoti, lai strādātu pie Mongo. Es esmu iepazinies ar daudziem NoSQL platformām. Ik viens ir šie tipi Karsto galvenajām problēmām. Lai iegūtu vislabāko no jebkuras NoSQL datubāzi, īpaši Dynamo DB, jūs vēlaties, lai izveidotu tabulas ja hash galvenais elements ir liels skaits atšķirīgu vērtību, augstu cardinality. Jo tas nozīmē, ka es esmu rakstiski uz daudz dažādu spaiņiem. 

Jo vairāk spaiņi Esmu rakstiski, jo lielāka iespēja Es esmu, lai izplatītu šo rakstīt slodzi vai lasīt ielādēt no vairākiem punktiem, jo lielāka iespēja, es esmu, lai būtu augstu caurlaides uz galda. Un tad es gribu vērtības būt pieprasīja diezgan vienmērīgi laika gaitā un vienādi kā nejauši, cik vien iespējams. Nu, tas ir diezgan interesants, jo es nevaru īsti kontrole, kad lietotāji nāk. Tātad pietiek pateikt, ja mēs parādīsim lietas visā galveno telpu, mēs droši vien būtu labāks. 

Tur ir zināma laika sprīdī piegādi ka jūs nebrauksim Lai varētu kontroli. Bet tie ir patiešām divas dimensijas, kas mums ir, telpa, piekļuve vienmērīgi izplatīšanās, laiks, pieprasījumi tiek saņemti vienmērīgi izvietotas laicīgi. Un, ja tie divi nosacījumi tiek ievēroti, tad tas ir tas, ko tas ir gatavojas izskatās. Tas ir daudz jaukāk. Mēs esam patiesi priecīgi šeit. Mēs esam ieguvuši ļoti pat piekļūt modeli. Jā, varbūt jūs saņemat maz spiediens katru tagad un tad, bet nekas īsti pārāk plašs. Tātad, tas ir pārsteidzošs, cik daudz reižu, kad es strādāju ar klientiem, ka pirmais diagramma ar Big Red bārs un visu, kas neglīts dzeltens tas ir visas vietas, mēs paveikt ar īstenošanu pēc pāris mēnešiem Atkārtotas arhitektūru, viņi darbojas tieši tā pati slodze uz tieši tādu pašu slodzi. Un tas ir tas, ko meklē kā tagad. Tātad, ko jūs saņemsiet ar NoSQL ir dati shēma, kas ir absolūti saistīts ar piekļuves modeli. 

Un jūs varat optimizēt ka datu shēmu atbalstīt šo piekļuves modeli. Ja jums nav, tad jūs gatavojas redzēt šos veida problēmām ar šiem karstie taustiņi. 

Mērķauditorija: Nu neizbēgami dažas vietas gribam būt karstāks nekā citi. 

RICK Houlihan: Vienmēr. Vienmēr. Jā, es domāju tur vienmēr a-- un atkal, tur ir daži dizaina modeļus mēs nokļūt cauri kas runā par to, kā jūs risināt ar šiem super lielu baru. Es domāju, es saņēmu, lai tos, kā mēs galā ar viņiem? Es saņēmu diezgan laba izmantošanas gadījumā ka mēs runājam par par to. 

Labi, tāpēc parunāsim Par daži klienti tagad. Šie puiši ir AdRoll. Es nezinu, vai jūs esat iepazinušies ar AdRoll. Jūs, iespējams redzēt daudz par pārlūku. Viņi ad re-mērķauditorijas, viņi lielākais ad re-mērķauditorijas bizness tur ārā. Tie parasti regulāri sabraukt 60 miljardi darījumu dienā. Viņi dara vairāk nekā miljons darījumiem sekundē. Tie esam ieguvuši diezgan vienkāršu tabulu struktūra, aktīvākais galds. Tas ir būtībā tikai hash galvenais ir cookie, diapazons ir demogrāfiskā grupa, un pēc tam trešais atribūts ir rezultāts. 

Tāpēc mums visiem ir sīkdatnes mūsu pārlūku no šiem puišiem. Un, kad jūs dodaties uz piedalās komersants, viņi būtībā score jums pāri dažādas demogrāfiskās kategorijas. Kad jūs doties uz mājas lapā un jūs sakāt, es gribu redzēt šo ad-- vai būtībā jums nav teikt that-- bet, kad jūs iet uz mājas lapā viņi saka, jūs vēlaties redzēt šo reklāmu. Un viņi iet saņemt šo reklāmu no AdRoll. AdRoll izskatās jums līdzi sava galda. Viņi atrast savu cookie. Reklāmdevēji stāsta viņiem, es gribu kādu kas ir pusmūža, 40 gadus vecs vīrietis, ar sportu. Un viņi score jums šajos demogrāfijas un viņi izlemj, vai tas ir labs reklāmas jums. 

Tagad viņi ir SLA ar viņu reklāmas pakalpojumu sniedzējiem nodrošināt sub-10 milisekundi atbilde par katru pieprasījumu. Tātad viņi izmanto Dynamo DB šim. Viņi dodas mums miljons pieprasījumi sekundē. Viņi spēj darīt visu to lookups, šķirošana viss, ka dati, un saņemt, ka saites pievienot atpakaļ, ka reklāmdevējam zem 10 milisekundes. Tas ir patiešām diezgan fenomenāls īstenošanu, ka viņi ir. 

Šie puiši actually-- ir šie puiši. Es neesmu pārliecināts, vai tas ir šie puiši. Varētu būt šie puiši. Būtībā us-- teicis nē, es nedomāju, ka tas bija viņiem. Es domāju, ka tas bija kāds cits. Es strādāju ar klients, kas man teica ka tagad, kad tie esam devusies uz Dinamo DB, viņi tērēt vairāk naudas par uzkodas to attīstība komanda katru mēnesi nekā viņi tērē par to datu bāzē. Tātad tas došu jums Ideja par izmaksu ietaupījumu ka jūs varat Dinamo DB ir milzīgs. Labi, dropcam ir cits uzņēmums. Tie puisis ir sava of-- ja jūs domājat, ka interneta lietas, dropcam pamatā ir interneta drošības video. Jūs varat ievietot savu kameru, kas tur. Kamera ir kustības detektors. Kāds nāk kopā, izraisa cue punktu. Kamera sāk ierakstu, bet līdz tas nenosaka nekādas kustību vairs. Padara šo video līdzi internetā. 

Dropcam bija uzņēmums, kas ir būtībā pārgāja uz Dinamo DB jo tie bija vērojama milzīgas augšanas sāpes. Un ko viņi mums teica, pēkšņi petabytes datu. Viņiem nebija ne jausmas savu pakalpojumu būtu tik veiksmīgs. Vairāk ienākošo video nekā YouTube ir tas, ko šie puiši kļūst. Viņi izmanto DynamoDB izsekot visiem metadati par visiem saviem video galvenajiem punktiem. 

Tāpēc viņi ir S3 kausi viņi push visi binārā artifacts into. Un tad viņi ir Dynamo DB ierakstus, norāda cilvēkus tiem S3 trim objektiem. Kad viņi ir nepieciešams apskatīt video, tie izskatās up ierakstu dinamo DB. Viņi noklikšķiniet uz saites. Viņi nojaukt video no S3. Tātad tas ir sava veida, kā tas izskatās. Un tas ir tieši no savas komandas. 

Dynamo DB samazina to piegādes laiks video notikumiem no pieciem līdz 10 sekundēm. Savā vecajā relāciju veikalu, viņi izmanto, lai iet un izpildīt vairākas sarežģītu jautājumu, lai noskaidrotu , kura video nojaukt, līdz mazāk nekā 50 milisekundēm. Tātad, tas ir pārsteidzošs, pārsteidzošs cik daudz sniegumu jūs varat saņemt, ja jums optimizēt un klausoties pamatinstrumentu datu bāze lai atbalstītu piekļuves modelis. Halfbrick, šie puiši, kas tas ir, Augļu Ninja Es domāju, ir viņu lieta. Ka visi iet uz Dinamo DB. Un šie puiši, tie ir lielisks attīstības komanda, lieliski attīstība veikals. 

Nav laba ops komanda. Viņiem nebija daudz Darbības resursiem. Viņi bija cīnās, cenšoties saglabāt to piemērošana infrastruktūra up un darbojas. Viņi nāca pie mums. Viņi paskatījās tajā Dinamo DB. Viņi teica, ka ir par mums. Viņi uzcēla savu veselumu lietojumprogrammu sistēma par to. Daži patiešām jauku komentāri šeit no komandas par savām spējām tagad koncentrēties uz ēkas spēle un nav kam, lai saglabātu infrastruktūra, kas kļuva ļoti daudz no gaisvadu viņu komandai. Tātad tas ir kaut that-- labums, ka jūs saņemsiet no Dinamo DB. 

Labi, nokļūst datu modelēšanas šeit. Un mēs runājām, mazliet par šis viens pret vienu, viens pret daudziem, un daudzi daudziem tipa attiecības. Un kā jūs saglabāt tiem Dinamo. Dinamo DB mēs izmantojam indeksi, vispārīgi runājot, lai pagrieztu datus no viens aromāts uz otru. Hash atslēgas, Apgriezienu diapazona atslēgas, un indeksi. 

Šajā konkrētajā Piemēram, kā lielākajā daļā valstu ir prasība, licencēšanas, ka Tikai viena vadītāja apliecība vienai personai. Jūs nevarat iet, lai iegūtu divas vadītāja licences stāvoklī Boston. Es nevaru darīt to Teksasā. Tas ir sava veida, kā tas ir. Un tā pie DMV, mums ir lookups, mēs vēlaties meklēt vadītāja apliecība ar sociālās apdrošināšanas numuru. Es gribu, lai uzmeklētu lietotāja datus ar vadītāja apliecības numuru. 

Tātad mēs varētu būt lietotāja tabulu, kas ir hash taustiņu uz sērijas numuru, vai sociālās apdrošināšanas numurs, un dažādi atribūti noteikts uz objektu. Tagad par šo galda I varētu noteikt, ka GSI flips ka apkārt, ka saka, ka es gribu hash galvenais licencē un pēc tam visi citi priekšmeti. Tagad, ja es gribu, lai vaicājumu un atrast licences numurs par kādu konkrētu Social Apdrošināšanas numuru, es varu vaicājumu galveno tabulu. 

Ja es gribu, lai vaicājumu, un es gribu lai iegūtu sociālo nodrošinājumu numurs vai citi atribūti, ko licences numurs, es var vaicājumu GSI. Tas modelis ir tas, ka viens vienam attiecības. Tikai ļoti vienkāršs GSI, uzsist tās lietas apkārt. Tagad runāt par vienu daudziem. Viens daudziem būtībā Jūsu hash diapazons atslēga. Kur mēs iegūtu daudz ar šo lietošanas gadījumu ir monitora dati. Monitor dati nāk regulāri intervāls, piemēram, internetā lietām. Mēs vienmēr iegūt visus šos ieraksti nāk visu laiku. 

Un es gribu, lai atrastu visus rādījumus starp noteiktā laika periodā. Tas ir ļoti bieži vaicājumu monitoringa infrastruktūra. Tas, kā iet par to, ka ir atrast vienkāršs tabulas struktūra, viena tabula. Man ierīču mērījumus tabulu ar hash taustiņu uz ierīces ID. Un man ir virkne taustiņu timestamp, vai šajā gadījumā episko. Un tas ļauj man veikt kompleksu vaicājumi pret šajā diapazonā atslēgu un atgriezt šos ierakstus, kas ir attiecināti pret rezultāta noteikt, ka es esmu meklē. Un tas uzkrājas, ka viens daudziem attiecības uz primārajā tabulā izmantojot principu hash atslēga, diapazons taustiņš struktūra. 

Tātad, kas ir sava veida būvēts uz galda Dinamo DB. Kad es noteikt hash un diapazons t galds, es esmu nosakot viens pret daudziem attiecības. Tas ir vecāku un bērnu attiecības. 

Parunāsim par daudz daudziem attiecības. Un par šo konkrēto piemēru, atkal, mēs spēsim izmantot GSI s. Un parunāsim par spēļu scenārijs, kur man ir dota lietotāju. Es gribu, lai uzzinātu visas spēles, kas viņš ir reģistrēts vai spēlē. Un attiecībā uz konkrētu spēli, es gribu atrast visus lietotājus. Tātad, kā es varu darīt? Mans lietotājvārds spēles galds, es eju lai būtu hash atslēga lietotāja ID un virkne galvenais spēli. 

Tātad lietotājs var būt vairākas spēles. Tas ir viens pret daudziem attiecības starp lietotājs un spēles viņš spēlē. Un tad uz GSI, Es uzsist ka aptuveni. Es hash par spēli un Es svārstās no lietotāja. Tātad, ja es vēlos saņemt visus spēle lietotāja spēlē, Es vaicājumu galveno tabulu. Ja es gribu, lai saņemtu visus lietotājus kas spēlē konkrētu spēli, Es vaicājumu GSI. Tātad jūs redzat, kā mēs to darām? Jums veidot šos GSI ir atbalstīt izmantošanas gadījumā, pieteikumu, piekļuves modelis, pieteikums. 

Ja man ir nepieciešams, lai vaicājumu par Šī dimensija, ļaujiet me izveidot indekss par šo aspektu. Ja man nav, man ir vienalga. Un atkarībā no izmantošanas gadījumā, es var būt nepieciešams indeksu vai es varētu ne. Ja tas ir vienkāršs viens daudziem, primārais tabula ir labi. Ja man ir jādara tiem daudzi daudzi ir, vai man ir nepieciešams veikt vienu uz tiem, tad varbūt man vajag uz otro indekss. Tātad tas viss ir atkarīgs no ko es cenšos darīt un to, ko es cenšos iegūt paveikto. 

Droši vien es neesmu gatavojas tērēt pārāk daudz laika runājot par dokumentiem. Tas izpaužas mazliet, iespējams, dziļāk nekā mums nepieciešams iedziļināties. Parunāsim mazliet Par bagāts vaicājums izteiksme. Tātad Dinamo BP mums spēja radīt tas, ko mēs saucam projekcijas izteiksmes. Projekcijas izteiksmes ir vienkārši picking laukus vai vērtības ka jūs vēlaties, lai parādītu. Labi, tāpēc es izdarīt izvēli. Es veicu vaicājumu pret Dinamo DB. Un es saku, jūs zināt, ko, parādīt me tikai piecu zvaigžņu atsauksmes šim konkrētajam produktam. Tātad tas ir viss, ko es gribu redzēt. Es nevēlos, lai redzētu visus citi atribūti rindas, Es tikai gribu redzēt šo. Tas ir tāpat kā SQL, kad jūs saka izvēlieties zvaigzni vai no galda, Jūs saņemsiet visu. Kad es saku izvēlieties vārdu no galds, es tikai saņemt vienu atribūtu. Tā ir tāda paša veida lieta Dynamo DB vai vēl NoSQL datu bāzēm. Filter izteiksmes ļaujiet man būtībā samazināt rezultātu izlaist. Tāpēc es veicu vaicājumu. Vaicājums var atgriezties ar 500 vienību. Bet es tikai gribu priekšmetus, kas ir atribūtu, kas saka, ka tas. Labi, tāpēc pieņemsim atfiltrēt šos priekšmetus kas nesakrīt šo konkrēto jautājumu. Tātad mums ir filtra izteiksmes. 

Filter izteiksmes var palaist uz jebkuru atribūtu. Viņi nepatīk diapazons vaicājumiem. Paaugstināt vaicājumi ir vairāk selektīvs. Filter vaicājumi prasa man iet saņemt noteiktā visa rezultātus un pēc tam meklējumos datus es nevēlos. Kāpēc ir tik svarīgi? Tā kā es izlasīju to visu. In vaicājumu, es esmu gatavojas lasīt un tas būs milzu par datiem. Un tad es esmu gatavojas meklējumos, ko man vajag. Un, ja es esmu tikai atkāpes no pāris rindas, tad tas ir OK. Tas nav tik neefektīva. 

Bet, ja es lasu veselu kaudzi dati, tikai meklējumos vienu objektu, tad es esmu būs labāk izslēgt, izmantojot virkni jautājumu, jo tas ir daudz vairāk selektīvs. Tas notiek, lai saglabātu man daudz nauda, ​​jo man ir jāmaksā par šo lasīt. Ja rezultāti, kas nāk atpakaļ šķērsot vadu varētu būt mazāks, bet es esmu maksājot par lasīt. Tātad, saprast, kā saņemat datus. Tas ir ļoti svarīgi, jo Dinamo DB. 

Nosacījuma izteiksmes, tas ir tas, ko jūs varētu aicināt optimistisku bloķēšanu. Atjauninājumu, ja ir, vai ja šo vērtību ir līdzvērtīgs tam, ko es precizēt. Un, ja man ir laika zīmogs par kādas ieraksts, es varētu nolasīt datus. Es varētu mainīt šo informāciju. Es varētu iet rakstīt, ka dati atpakaļ uz datu bāzē. Ja kāds ir mainījis ierakstu, laikspiedolu varētu būt mainījusies. Un tādā veidā mana nosacīta update varētu teikt atjauninājumu ja timestamp vienāds šis. Vai update nebūs tāpēc, ka kāds aktualizēja ierakstu starplaikā. 

Tas, ko mēs saucam par optimistisku bloķēšanu. Tas nozīmē, ka kāds var nākt un mainīt to, un es esmu gatavojas atklāt to kad es iet atpakaļ, lai rakstītu. Un tad es patiesībā var lasīt, ka datu un teikt, ak, viņš mainīja šo. Man vajag, lai ņemtu vērā, ka. Un es varu mainīt datus manā ierakstīt un piemērot citu atjauninājumu. Tātad jūs varat noķert tos papildu atjauninājumus, kas notiek laikā starp jums izlasīt datus un reizi, kad jūs varētu rakstīt datus. 

Mērķauditorija: Un filtru izteiksme patiesībā nozīmē ne skaita vai not-- 

[Iestarpinot Voices] RICK Houlihan: es ne pārāk daudz par to. Tas ir rezervēts atslēgvārdu. Mārciņa skats ir rezervēta atslēgvārds Dinamo DB. Katram datu bāzē ir savs aizsargātas nosaukumi kolekcijās jūs nevarat izmantot. Dinamo DB, ja jūs norādāt mārciņu priekšā to, Jūs varat definēt šos vārdus augšas. Tas ir atsauce vērtība. Tas ir iespējams, nav labākais sintakse ir tur par šo diskusiju, jo tas nonāk dažu real-- Es būtu bijis runāt vairāk par to, ka pie dziļākā līmenī. 

Bet pietiek pateikt, tas varētu būt vaicājumu skenēt kur viņi views-- ne £ rādījumi ir lielāka nekā 10. Tas ir skaitliska vērtība, jā. Ja vēlaties, mēs varam runāt par ka pēc diskusijām. Labi, tāpēc mēs esam nokļūst daži scenāriji paraugpraksi kur mēs ejam, lai runātu par kādu progr šeit. Kādas ir lietošanas gadījumi Dynamo DB. Kas ir dizains modeļi Dinamo DB. 

Un pirmais, mēs spēsim runāt par ir lietiskais internets. Tātad mēs iegūtu daudz of-- es domāju, kas ir it-- vairāk nekā 50% satiksmes internetā šīm dienām mašīna ir faktiski saražots, automatizēto procesu, ne cilvēki. Es domāju šī lieta šī lieta, kas jūs veikt ap jūsu kabatā, cik daudz datu, ka šī lieta ir faktiski nosūtot apkārt bez tevis zinot to ir absolūti pārsteidzošs. Jūsu atrašanās vieta, informācija par to, cik ātri jūs iet. Kā jūs domājat, ka Google Maps darbus kad viņi jums pateiks, kāda ir satiksme. Tas ir tāpēc, ka ir miljoniem un miljoniem cilvēku braukšanas apkārt ar telefoniem, kas ir nosūtot datus par vietu visu visu laiku. Tātad, viens no lietām par šāda veida dati kas nāk, monitora dati, piesakieties dati, laika rindas dati, tas ir parasti tikai interesants par mazliet laika. Pēc šī laika, tas ir nav tik interesanti. Tātad mēs runājām par, neļaujiet šīs tabulas augt bez robežām. Ideja ir tāda, ka varbūt es esam ieguvuši 24 stundas vērtu notikumiem manā karstā tabulā. Un tas karstais galds būs nodrošināti ar ļoti lielu ātrumu, jo tas ir ņemot daudz datu. Tas ir ņemot daudz datu un es lasu to daudz. Man daudz operācijas vaicājumi darbojas pret šiem datiem. 

Pēc 24 stundām, hey, jūs zināt, ko, man vienalga. Tātad, varbūt katrs pusnakts I roll mana galda uz jaunu tabulu un es deprovision šo tabulu. Un es ņemšu RCU s un WCU ir uz leju, jo 24 stundas vēlāk Es esmu nedarbojas tik daudz vaicājumus par šiem datiem. Tāpēc es esmu gatavojas, lai ietaupītu naudu. Un varbūt 30 dienas vēlāk man nav pat nepieciešams rūpēties par to visu. Es varētu veikt WCU s visu ceļu uz leju, lai vienu, jo jūs zināt, kas tas ir nekad gatavojas saņemt rakstījis. Dati ir 30 dienas vecs. Tas nekad nemainās. 

Un tas ir gandrīz nekad gatavojas saņemt lasīt, tāpēc pieņemsim tikai pieņemt, ka RCU līdz 10. Un es esmu ietaupot ton naudu par šo dati, un tikai maksājot par manu karsto datiem. Tā ka ir svarīga lieta, lai meklētu at kad paskatās laikrindu dati nāk apjoma. Tie ir stratēģijas. Tagad, es varētu tikai ļaujiet tai visi iet pie viena galda un tikai ļaujiet ka tabula augt. Galu galā, es esmu gatavojas skatīt veiktspējas problēmas. Es esmu nāksies sākt arhīvs daži no šiem datiem pie galda, kas ne. 

Let 's daudz labāk dizains savu pieteikumu lai jūs varētu strādāt šādā veidā labi. Tātad, tas ir tikai automātiskā pieteikuma kodu. Pusnaktī katru nakti tas ruļļos tabulu. Varbūt to, kas man ir nepieciešams, ir bīdāmas logu 24 stundas pēc datiem. Tad regulāri es esmu zvanot datus pie galda. Es esmu apgriešanas to ar Cron darbu un es varēšu to uz šiem citiem galdiem, kāds jums ir nepieciešams. Tātad, ja apgāšanās darbojas, tas ir lieliski. Ja tā nav, sagrieziet to. Bet pieņemsim saglabātu šo karstā dati prom no saviem aukstā datiem. Tas būs ietaupīt jums daudz naudas un Padariet savu galdiņi darbojas. Tātad nākamā lieta, mēs runājam par to ir produktu katalogs. Produktu katalogs ir diezgan kopējā lietošanas gadījumu. Tas ir tiešām ļoti bieži modelis ka mēs redzēsim dažādas lietas. Jūs zināt, čivināt Piemēram, karstā čivināt. Ikvienam nāk un satveršanas ka čivināt. Produktu katalogs, es saņēmu pārdošanu. Man karstu pārdošanu. Man 70.000 pieprasījumus vienā otro atnākšanu produktam apraksts no manas produktu katalogu. Mēs redzam šo par mazumtirdzniecības darbība pavisam nedaudz. Tātad, kā mēs galā ar šo? Nav veids, kā tikt galā ar to. Visi mani lietotāji vēlas redzēt pats gabals datu. Viņi nāk, vienlaikus. Un viņi visi padarot pieprasījumus par to pašu gabals datiem. Tas dod man, ka karstais taustiņš, ka liels sarkans svītra manā topā, kas mums nepatīk. Un tas, ko tas izskatās. Tātad pa manu galveno telpā es saņemu metālkalumi pārdošanu posteņiem. Es saņemu nekas nekur citur. 

Kā es varu mazinātu šo problēmu? Nu, mēs mazinātu to ar kešatmiņu. Cache, jūs likts būtībā in-atmiņa šķērssienas priekšā datu bāzē. Mums ir izdevies [Dzirdams] cache, kā jūs var izveidot savu kešatmiņu, [nedzirdama] cache [? d,?] ko jūs vēlaties. Put, ka līdz priekšā datu bāzē. Un tādā veidā jūs varat saglabāt datus No šiem karstie taustiņi uz augšu šajā cache telpu un izlasīt kešatmiņā. 

Un tad lielākā daļa no jūsu lasījuši sākt meklēt, kā šis. Man visi šie cache hits šeit un es got nekas notiek šeit lejā jo datu bāze sēž aiz cache un lasa nekad nāk caur. Ja es mainīt šos datus ir datubāzi, man ir, lai atjauninātu kešatmiņu. Mēs varam izmantot kaut piemēram, tvaiku, lai to izdarītu. Un es paskaidrot, kā tas darbojas. Labi, ziņapmaiņu. E-pasts, mēs visi izmantot e-pastu. 

Tas ir diezgan labs piemērs. Mēs esam ieguvuši kādu ziņu tabulas veida. Un mēs saņēmām iesūtni un Izsūtne. Tas ir tas, ko SQL būtu izskatās veidot šo inbox. Mēs veida izmantot to pašu veida Stratēģijas izmantot GSI s, GSI s manu iesūtni un manu Izsūtne. Tāpēc es saņēmu raw ziņas nāk manā ziņojumus tabulā. Un pirmais pieeja šo varētu būt, teiksim, OK, nav problēmu. Man izejvielas ziņojumus. Vēstules nāk [nedzirdama], ziņa ID, tas ir lieliski. Tas ir mans unikāls hash. Es esmu gatavojas izveidot divas GSI s, viens par manu inbox, vienu manu Izsūtne. Un pirmais, ko es darīšu ir es saku mans hash Galvenais ir būs saņēmējs un Es esmu gatavojas organizēt dienā. Tas ir fantastiski. Es saņēmu savu skaistu skatu šeit. Bet tur ir mazliet problēma šeit. Un jūs satikt šo relāciju datu bāzēm, kā arī. Tās sauc par vertikāli sadalīšanu. Jūs vēlaties, lai saglabātu savu lielo datu prom no jūsu maz datu. 

Un iemesls, kāpēc ir tāpēc, ka es gotta iet lasīt priekšmetus, lai iegūtu atribūtus. Un, ja manas iestādes ir visi šeit, tad lasot tikai dažus priekšmetus ja mana ķermeņa garums ir vidēji 256 kilobaiti katrs, math izpaužas diezgan neglīts. Tāpēc teikt, es gribu lasīt Dāvida inbox. Dāvida inbox ir 50 pozīcijas. Vidējā un izmērs ir 256 kilobaiti. Te ir mana konversijas koeficients par RCU s ir četri kilobaiti. 

OK, iesim ar beidzot konsekventi lasījuši. Es joprojām ēd 1600 RCU s tikai lasīt Dāvida inbox. Sakta. Labi, tagad pieņemsim domāt par to, kā app darbojas. Ja es esmu e-pasta app un Es skatos uz manu iesūtni, un es paskatos ķermeņa katru ziņu, nē, es esmu meklē kopsavilkumiem. Es skatos tikai sadalītājiem. Tātad pieņemsim izveidot tabulu struktūra kas izskatās vairāk, piemēram, ka. 

Tātad, šeit ir informācija ka mans darbplūsmas vajadzībām. Tas ir manā pastkastītē GSI. Tas ir datums, sūtītājs, priekšmets, un pēc tam ziņa ID, kas norāda atpakaļ uz galda ziņas kur es varu saņemt ķermeni. Nu, tie būtu ieraksta ID. Viņi norāda atpakaļ uz postenis ID uz Dynamo DB tabulā. Katrs rādītājs vienmēr creates-- vienmēr ir objektu ID kā daļa of-- ka nāk ar indeksu. 

Viss kārtībā. Mērķauditorija: Tā stāsta to, kur tas tiek uzglabāts? RICK Houlihan: Jā, tā stāsta exactly-- tas ir tieši tas, ko tā dara. Tajā teikts, šeit ir mana re ieraksts. Un tas būs jānorāda to atpakaļ uz manu atkārtotu ierakstu. Tieši tā. Labi, tāpēc tagad mana iesūtne tiešām daudz mazākas. Un tas patiesībā atbalsta darbplūsma, e-pasta app. Tātad manā pastkastītē, es noklikšķiniet. Es iet kopā, un es noklikšķiniet uz ziņojuma, tas ir tad, kad man ir nepieciešams, lai iet saņemt ķermeni, jo es esmu gatavojas pārietu uz citu skatu. Tātad, ja jūs domājat par MVC veida regulējums, modelis skats kontrolieris. 

Modelī satur dati, ka skats vajadzības un kontrolieris mijiedarbojas ar. Kad es mainīt rāmi, kad Es mainīt perspektīvu, tas ir OK, lai dotos atpakaļ uz serveris un repopulate modeli, jo tas, ko lietotājs sagaida. Kad viņi maina uzskatus, tas ir, kad mēs varam atgriezties pie datu bāzi. Tātad e-pastu, noklikšķiniet. Es meklēju, lai organismā. Turp un atpakaļ. Iet saņemt ķermeni. 

Es izlasīju daudz mazāk datu. Es esmu tikai lasot struktūras, kas David vajadzībām, kad viņš tās ir nepieciešamas. Un es neesmu apdegums 1600 RCU ir tikai, lai parādītu savu inbox. Tāpēc tagad that-- tas ir veids, ka LSI vai GSI-- Es atvainojos, GSI, varētu strādāt out. Mēs esam ieguvuši mūsu hash par saņēmēju. Mēs esam ieguvuši diapazons taustiņu datuma. Un mēs esam ieguvuši prognozētās atribūtus ka mums ir nepieciešams tikai, lai atbalstītu viedokli. 

Mēs pagriezt ka Izsūtne. Hash uz sūtītāja. Un būtībā, mēs esam ļoti jauks, tīrs skats. Un tas ir basically-- mums ir šī jaukas ziņas Tabulā, kas ir tiek izplatīties labi, jo tas ir hash tikai, sajaukts ziņa ID. Un mums ir divi indeksi, kas griežas pie šī galda. Labi, tāpēc ideja šeit ir ne saglabāt lielas datus un šo mazo datus kopā. Sadalīšanās vertikāli, sadalīt šīm tabulām. Nelasa datus, jums nav. Labi, spēļu. Mums visiem patīk spēles. Vismaz man patīk spēles, tad. Tāpēc dažas no lietām ka mēs galā ar kad mēs domāt par spēļu, labi? Spēļu šajās dienās, jo īpaši mobilo spēļu, ir visu par domāšanu. Un es esmu gatavojas, lai pagrieztu šeit Mazliet prom no DynamoDB. Es esmu gatavojas celt daži no diskusijas ap daži no citas AWS tehnoloģijas. 

Bet ideja par spēļu ir jādomā par izteiksmē API, API, kas ir, vispārīgi runājot, HTTP un JSON. Tā kā mobilo spēles veida mijiedarboties ar to atpakaļ galiem. Tie JSON norīkošanu. Viņiem datus, un tas ir viss, vispārīgi runājot, jauka JSON API. 

Lietas, piemēram, iegūt draugus, iegūt līderu, datu apmaiņu, lietotāju radīts saturs, push atpakaļ uz augšu ar sistēmu, tie ir veidi lietas ka mēs esam gatavojas darīt. Bināro aktīvs dati, šie dati iespējams, nav sēdēt datu bāzē. Tas varētu sēdēt objekts veikals, vai ne? Bet datu bāzē gatavojas galu galā stāsta sistēmu, stāsta pieteikumu kur iet saņemt to. Un neizbēgami, multiplayer serveri, back end infrastruktūra, un paredzēts augsts pieejamību un mērogojamību. Tātad šie ir lietas, ko mēs visi vēlamies ar spēļu infrastruktūrā šodien. 

Tātad, pieņemsim to apskatīt ko tas izskatās. Got galveno atpakaļ beigām, ļoti vienkārša. Mēs esam ieguvuši sistēma šeit ar Vairāku pieejamības zonas. Mēs runājām par AZS kā being-- domāt no tiem kā atsevišķas datu centriem. Vairāk nekā viens datu centrs per AZ, bet tas ir OK, tikai domā par to kā atsevišķu datu centri, kas ir ģeogrāfiski un vaina izolēti. 

Mēs ejam, lai būtu Pāris EC2 gadījumi. Mēs ejam, lai būtu daži back end serveri. Varbūt, ja tu esi mantojums arhitektūra, mēs esam izmantojot to, ko mēs saucam RDS, relāciju datu bāzu pakalpojumi. Varētu būt MSSQL, MySQL, vai kaut kas tamlīdzīgs. Tas ir veids, kā daudz pieteikumi ir paredzētas šodien. 

Nu mēs varētu vēlēties, lai iet ar Tas ir tad, kad mēs mēroga out. Mēs iet uz priekšu un nodot S3 spainis tur augšā. Un tas S3 spainis, nevis kalpo up šiem objektiem no mūsu servers-- mēs varētu darīt. Jūs varat ievietot visu savu bināro objektus uz jūsu serveriem un jūs varat izmantot šos serveri gadījumi kalpot ka datu augšu. Bet tas ir diezgan dārgi. 

Labāks veids to darīt, ir iet uz priekšu un likt šos objektus ar S3 spainī. S3 ir objekts reģistriem. Tas ir būvēts speciāli apkalpo šos lietas veidu. Un lai šie klienti pieprasa tieši no šiem objektu spaiņiem, izkraut serveriem. Tātad mēs sākam mērogā šeit. 

Tagad mēs saņēmām lietotājiem visā pasaulē. Man lietotājiem. Man vajag, lai ir saturs, lokāli atrodas tuvu šiem lietotājiem, vai ne? Esmu izveidojis S3 kauss kā manu avotu glabātavā. Un es ņemšu priekšā, ka ar CloudFront izplatīšanu. 

CloudFront ir CD un satura piegādes tīkls. Būtībā tas aizņem datus, ka jūs, precizējiet un kešatmiņas to visu internetā lai lietotāji visur var būt ļoti ātri reaģēt, ja viņi pieprasa šos objektus. 

Tātad jūs saņemsiet ideja. Jūs esat veida piesaistot visu aspekti AWS šeit, lai iegūtu šo izdarīt. Un galu galā, mēs mest kādā auto mērogošanas grupā. Tātad mūsu AC2 instancēs Mūsu spēļu serveriem, jo viņi sāk saņemt busier un busier un busier, tie būs tikai spin cits Piemēram, spin citu gadījumu, spin citu gadījumu. Tātad tehnoloģiju AWS ir, to ļauj norādīt parametrus ap kuru jūsu serveri augs. Tātad jūs varat būt n skaitu serveriem tur jebkurā brīdī. Un, ja jūsu slodze iet prom, tie būs sarukt skaits saruks. Un, ja krava nāk atpakaļ, tas būs augt atpakaļ ārā, elastīgi. 

Tātad tas izskatās lieliski. Mēs esam ieguvuši daudz EC2 instancēs. Mēs varam nodot kešatmiņu priekšā datu bāzēm, mēģināt paātrināt datu bāzes. Nākamais spiediens punkts Parasti cilvēki redz ir tie mēroga spēli izmantojot relāciju datu bāzes sistēma. Jeez, datu bāzes sniegums ir briesmīgi. Kā mēs uzlabot šo? Pamēģināsim liekot cache priekšā kas. 

Nu, cache nedarbojas tik liels spēles, vai ne? Par spēlēm, rakstiski ir sāpīga. Spēles ir ļoti rakstīt smags. Cache nedarbojas, ja esat rakstīt smags, jo jūs esat vienmēr got atjaunināt kešatmiņu. Jūs atjaunināt kešatmiņu, tas ir nav nozīmes, kas caching. Tas ir faktiski tikai papildu darbu. 

Tātad, ja mēs ejam šeit? Jūs esat ieguvuši lielu sašaurinājumu uz leju tur datu bāzē. Un vieta, kur iet acīmredzot ir šķērssienu. Sadalīšana nav viegli darīt, ja jūs esat nodarbojas ar relāciju datu bāzēm. Ar relāciju datu bāzēm, tu esi atbild par, faktiski, galvenais telpa. Jūs sakāt lietotājus starp A un M iet šeit, starp N un Z iet uz turieni. Un jūs pārejot pāri pieteikumu. Tātad jums ir darīšana ar Tas partition datu avots. Jums ir darījumu ierobežojumi ka nav span starpsienas. Jūs esat ieguvuši visu veidu messiness ka jūs esat nodarbojas ar tur lejā mēģinot galā ar mērogošanas out un veidojot lielāku infrastruktūru. Tas ir tikai nav jautri. 

Mērķauditorija: Tātad jūs sakāt, ka palielinot avota punktus paātrina process? RICK Houlihan: palielināšana? Mērķauditorija: Source punkti. RICK Houlihan: Source punkti? Mērķauditorija: No informācijas, ja informācija nāk no? RICK Houlihan: Nē. Ko es saku, ir palielinot vairāki starpsienas datu krātuvē uzlabo caurlaides. Tātad, kas notiek šeit ir lietotāji nonāk EC2 Piemēram šeit, labi, ja man ir nepieciešams lietotājam Tas ir M, es iešu šeit. No N p, es iešu šeit. No P līdz Z, es iešu šeit. 

Mērķauditorija: Labi, tādi, tie ir viss glabājas dažādu mezglu? 

RICK Houlihan: Jā. Domājiet par šiem, kā dažādi Silos datus. Tātad jums ir to darīt. Ja jūs mēģināt darīt tas, ja jūs cenšaties mēroga uz relāciju platformas, tas ir tas, ko jūs darāt. Jūs lietojat datus un jūs samazināt to uz leju. Un jūs šķērssienu to pāri vairāki gadījumi no datubāzes. Un jūs pārvaldīt visu, kas aplikācijas līmeņa. Tas nav jautri. Tātad, ko mēs vēlamies iet? Mēs vēlamies, lai iet DynamoDB, pilnībā pārvalda, NoSQL datu krātuve, noteikums caurlaide. Mēs izmantojam sekundārās indeksi. Tas ir būtībā HTTP API un ietver dokumenta atbalstu. Tātad jums nav jāuztraucas par kādu no šī sadalīšanu. Mēs darām visu, lai jums. Tāpēc tagad, tā vietā, jūs vienkārši uzrakstīt uz galda. Ja tabula ir jāsadala, kas notiek aiz ainas. Jūs esat pilnībā izolēti no kā attīstītājs. Tātad parunāsim par daži no lietošanas gadījumi ka mēs uzskriet spēļu, kopējā spēļu scenāriji, līderu. Tātad jūs esat ieguvuši lietotāju nāk, tad BoardNames ka viņi gada, tad punktu skaits lietotāju. Mēs varētu sajaukšanai uz lietotāja ID, un tad mums ir diapazonu spēli. Tātad katrs lietotājs vēlas redzēt visu spēli viņš spēlēja un visi viņa labākais rezultāts visās spēli. Tātad tas ir viņa personīgā līderu. 

Tagad es gribu iet un es vēlos get-- tāpēc man šīs personas līderu. Ko es gribu darīt, ir iet saņemt top rezultāts visiem lietotājiem. Tātad, kā es varu darīt? Kad mans ieraksts tiek sajaukts uz Lietotāja ID, bija par spēli, arī es iešu uz priekšu un pārstrukturēt, izveidot GSI, un es esmu gatavojas, lai pārstrukturētu, ka dati. 

Tagad es esmu gatavojas Hash uz BoardName, kas ir spēle. Un es esmu gatavojas svārstīties par top rezultātu. Un tagad es esmu izveidojis dažādus spaiņus. Es esmu, izmantojot to pašu tabulu, paši posteņu dati. Bet es esmu radot kausu, kas dod me summēšana no top rezultātu, ko spēlē. 

Un es varu vaicājumu, kas tabulu lai iegūtu šo informāciju. Tāpēc es esmu, kas šo vaicājumu modeli līdz jāatbalsta ar sekundāru indeksu. Tagad viņi var kārtot pēc BoardName un sakārtoti pēc TopScore, atkarībā. Tātad jūs varat redzēt, tie ir veidi lietošanas gadījumu jūs saņemsiet spēļu. Vēl viens labs lietošanas gadījumu mēs spēļu ir balvas un kurš ir ieguvis balvas. Un tas ir lielisks lietošanas gadījumu kur mēs saucam skraji indeksi. Reti indeksi ir spēja radīt indekss, kas nav obligāti saturēt katru posteni uz galda. Un kāpēc ne? Jo atribūts, kas ir to indeksēti neeksistē par katru posteni. 

Tātad šajā konkrētajā lietošanas gadījumu, es saku, jūs zināt, ko es esmu gatavojas izveidot atribūtu sauc Award. Un es esmu gatavojas sniegt katram lietotājam kas ir balvu ka atribūtu. Lietotāji, kas nav balvas ir nav nāksies šo atribūtu. Tātad, ja es izveidotu indekss, vienīgie lietotāji kas gatavojas parādīt up indeksā ir tie, kas patiesībā esam ieguva balvas. Tātad tas ir lielisks veids, lai varētu radīt filtrē indeksi ka ir ļoti, ļoti selektīva, ka nav ir indeksēt visu tabulu. 

Tātad mēs esam nonākuši zema laiku šeit. Es iešu uz priekšu un izlaist ārā un izlaist šo scenāriju. Runāt mazliet about-- 

Mērķauditorija: Vai es varu lūgt ātrs jautājums? Viens no tiem ir rakstīt smags? RICK Houlihan: Kas ir? Mērķauditorija: Rakstīt smags. RICK Houlihan: Rakstīt smags. Ļauj man paskatīties. 

Mērķauditorija: Vai ir tā, ka nav kaut ko jūs varat vienkārši balsi, kas dažu sekunžu laikā? RICK Houlihan: Mēs ejam caur balsošanas scenāriju. Tas nav tik slikti. Vai jums puiši ir dažas minūtes? LABI. 

Tātad mēs runājam par balsošanu. Tātad reālā laika balsošanas, mēs esam prasības balsošanas. Prasības ir tādas, ka mēs ļaujam katrs cilvēks balsot tikai vienu reizi. Mēs vēlamies, neviens, lai varētu mainīt savu balsojumu. Mēs vēlamies reālā laika agregāciju un analītika par demogrāfiju ka mēs ejam, lai būtu parādot lietotājiem uz vietas. 

Padomā par šo scenāriju. Mēs strādājam daudz realitātes TV parāda, kur viņi veicot šīs precīzu veida lietām. Tātad jūs varat iedomāties scenāriju, mums ir miljoniem un miljoniem no pusaudzes tur ar saviem mobilajiem tālruņiem un balsošana, un balsošana, un balsojot par kurš tās ir atrast ir vispopulārākais. Tātad šie ir daži no Prasības mēs izsīkšanai. 

Un tā pirmā ņemt atrisināt šo problēmu būtu veidot ļoti vienkāršs pieteikums. Tāpēc es esam ieguvuši šo app. Man ir daži vēlētājiem, kas tur. Viņi nāk, tie hit balsošanas lietotni. Man dažas jēlu balsis tabulu Es ņemšu tikai dump šos balsis into. Es ņemšu dažus kopējus balsis galda ka darīšu analīzes un demogrāfija, un mēs nodot to visu tur. 

Un tas ir lieliski. Dzīve ir laba. Dzīve ir labi līdz brīdim, kad mēs uzzinātu, ka tur ir vienmēr tikai viens vai divi cilvēki, kas ir populāras vēlēšanās. Tur ir tikai viena vai divas lietas ka cilvēki patiešām rūp. Un, ja jūs balsojot mērogs, visi pēkšņi es esmu būs kalšanai elle no divi kandidāti, viens vai divi kandidāti. Ļoti ierobežots skaits vienību cilvēki atrast ir populārs. 

Tas nav labs dizains modelis. Tas ir faktiski ļoti slikts dizains modelis jo tas rada tieši tas, ko mēs runāja par kuru bija karstie taustiņi. Karstie taustiņi ir kaut kas mums nepatīk. 

Tātad, kā mēs varam noteikt, ka? Un tiešām, ir veids, kā noteikt, tas ir veicot šos kandidātvalstis kausi un par katru kandidātu mums ir, mēs spēsim pievienot izlases vērtību, kaut kas, mēs zinām, izlases vērtība no viena līdz 100, no 100 līdz 1000, vai starp vienu un 1000, Tomēr daudzi izlases vērtībām vēlaties pievienot uz beigām šo kandidātu. 

Un ko es esmu patiešām darīts pēc tam? Ja es esmu, izmantojot kandidāta ID kā spainis uz kopējām balsīm, ja es esmu pievienojis izlases numurs līdz beigām ka, Esmu izveidojis tagad 10 kausi A simts spaiņi, tūkstoš spaiņi ka es esmu apkopojot balsis pāri. 

Tāpēc man ir miljoniem un miljoniem, un miljoniem ierakstu nāk par šiem kandidātiem, es esmu tagad izplatās tās balsis pāri kandidātu a_1 caur kandidātu A_100, jo Katru reizi, kad balsojums nāk, Es esmu radot izlases vērtība no viena līdz 100. Es esmu tacking to uz beigām kandidāts, ka personas balsojot par. Es esmu antidempinga to šajā spainī. 

Tagad uz krēsla, es zinu ka es saņēmu simts kausi. Tātad, ja es gribu iet uz priekšu un apkopot balsis, Es izlasīju No visiem šiem spaiņiem. Tāpēc es iet uz priekšu un pievienot. Un tad es izkliedes apkopot kur man iet ārā un saka hey, jūs zināt, ko, šī kandidāta taustiņš telpas ir vairāk nekā simts kausu. Es esmu gatavojas, lai savāktu visus balsis no šiem simts spaiņiem. Es esmu gatavojas apkopot viņiem, un es esmu gatavojas teikt, Kandidāts tagad ir Kopējais balsu skaitīšanas x. 

Tagad gan rakstīt vaicājumu un lasīt vaicājumu ir labi sadalītas jo es esmu rakstiski pāri un es lasu pāri simtiem atslēgas. Es neesmu rakstiski un pārlasot vienu taustiņu tagad. Tātad tas ir lielisks modelis. 

Tas faktiski ir iespējams, ir viens no svarīgākajiem dizainu modeļu mēroga NoSQL. Jūs redzēsiet šāda veida dizains modelis katrā garšu. MongoDB, DynamoDB, tā nav jautājums, mums visiem ir jādara. Jo, kad jūs nodarbojas ar šiem milzīgu baru, jums ir izdomāt veidu, kā izplatīt tos pa spaiņiem. Tātad šis ir veids, kā jūs to darīt. Labi, lai to, ko jūs darāt tieši tagad tiek jūs tirdzniecības off lasīt izmaksas rakstīt mērogojamību. Mana lasīt izmaksas ir nedaudz sarežģītāka un man ir jāiet lasīt no simts spaiņi nevis viens. Bet es esmu spējīgs uzrakstīt. Un mans caurlaide, mans rakstīšanas apgrozījums ir neticami. Tātad, tas parasti ir vērtīgs paņēmiens mērogošana DynamoDB, vai kāds NoSQL datubāzes par šo jautājumu. Tātad mēs izpētījuši, kā mērogu. Un mēs rakstainas, kā likvidēt mūsu karstie taustiņi. Un tas ir fantastiski. Un mēs saņēmām šo nice sistēmu. Un tas ir devis ļoti pareizu balsošanu jo mums ir ieraksts balsu de-piekrāptais. Tas ir iebūvēts DynamoDB. Mēs runājām par nosacītu tiesībām. 

Ja vēlētājs nāk, liek ievietot uz galda, viņi ievietot ar savu vēlētāju ID, ja viņi cenšas, lai iekļautu citu balsojumu, Man nosacītu rakstīt. Teikt tikai rakstīt šo ja šis nav. Tātad, tiklīdz es redzu, ka ka balsojums ir hit tabulu, neviens cits būs iespēja nodot savu balsojumu. Un tas ir fantastiski. Un mēs esam palielināšanai Mūsu kandidāts skaitītāji. Un mēs darām demogrāfijas un visu to. Bet kas notiek, ja mani pieteikums apgāžoties? Tagad visi pēkšņi balsis nāk, un es nezinu, vai viņi kļūst apstrādāti manā analītikas un demogrāfija vairs. Un, ja pieteikums nāk atpakaļ uz augšu, kā ellē es varu zināt, kas ir nobalsojuši apstrādāta un kur es varu sākt? 

Tātad šī ir reāla problēma, kad jūs sāk skatīties uz šāda veida scenāriju. Un kā mēs atrisināt šo? Mēs atrisināt to ar ko mēs zvaniet DynamoDB plūsmas. Streams ir laiks pasūtīts un sadalīts maiņa log katru piekļuves pie galda, katrs rakstīt piekļuve tabulā. Jebkura informācija, kas ir rakstīts uz tabula rāda uz augšu uz plūsmā. 

Tas būtībā 24 stundu rindā. Preces hit straumi, viņi dzīvo uz 24 stundām. Tos var izlasīt vairākas reizes. Garantētā jāpiegādā tikai vienu reizi uz straumi, varētu izlasīt n reižu skaitu. Tātad tomēr daudzi procesi vēlaties patērēt, ka dati, jūs varat patērēt to. Tas parādīsies katru atjauninājumu. Katru rakstīt būs tikai vienu reizi uz plūsmā. Tātad jums nav jāuztraucas par apstrādi to divreiz no tajā pašā procesā. 

Tas ir stingri pasūtīts vienība. Kad mēs sakām laiks pasūtīts un sadalīts, Jūs redzēsiet vienu nodalījuma straumi. Jūs redzēsiet objektus, atjauninājumus kārtībā. Mēs neesam garantējot uz strauta, kas tu esi gatavojas saņemt katru darījumu šajā visā posteņiem kārtībā. 

Tātad plūsmas ir idempotent. Vai mēs visi zinām, kas idempotent nozīmē? Idempotent nozīmē, ka jūs varat darīt to vairāk, un vairāk, un atkal. Rezultāts būs tāds pats. 

Plūsmas ir idempotent, bet tām ir jābūt spēlēja no sākumpunkta, kur jūs izvēlaties, līdz beigām, vai tie neradīs tajās pašās vērtībās. 

Pats ar MongoDB. MongoDB ir būvēt viņi sauc oplog. Tas ir tieši tā pati konstrukcija. Daudzi NoSQL datubāzes ir šo konstrukciju. Viņi izmanto to darīt lietas piemēram, replikācijas, kas ir tieši tas, ko mēs darām ar plūsmām. Mērķauditorija: Varbūt ķecerīgs jautājums, bet tu runāt par apps darot leju tā tālāk. Vai straumes garantēta nekad, iespējams, iet uz leju? RICK Houlihan: Jā, strautiem tiek garantēta nekad iet uz leju. Mēs pārvaldīt infrastruktūru atpaliek. strautiem automātiski izvietot savā auto mērogošanas grupā. Mēs iet cauri mazliet bit par to, kas notiek. 

Es nesaku, ka viņi nav garantēta nekad iet uz leju. Šie elementi ir garantēta parādīties straumi. Un straume būs pieejami. Tātad, kas iet uz leju vai nāk atpakaļ up, kas notiek zem. Tas covers-- tas ir OK. Labi, lai jūs iegūtu atšķirīgs skata veidi pie ekrāna. Uzskats veidi, kas ir svarīgi, lai programmētājs parasti ir, kas tas bija? Man veco skatu. Kad update hits galda, tas būs push veco skatu uz straumi tāpēc dati var arhivēt, vai maiņa kontrole, maiņa identifikācija, maiņa vadība. 

Jaunais tēls, kas tas ir tagad pēc update, tas ir cits veids, ņemot jūs varat saņemt. Jūs varat iegūt gan vecas un jaunas bildes. Varbūt es gribu tos abus. Es gribu redzēt, kas tas bija. Es gribu redzēt, ko tas ir mainījis to. 

Man ir atbilstības veids no procesa, kas darbojas. Tas nepieciešams, lai pārliecinātos, ka kad šīs lietas mainīt, ka viņi noteiktās robežās vai ar noteiktiem parametriem. 

Un tad varbūt es tikai ir jāzina, kas mainījies. Man vienalga, ko postenis mainījies. Man nav nepieciešams jāzina ko atribūti mainīta. Man vienkārši vajag zināt, ka preces tiek pieskāries. Tātad tie ir veidi viedokļu ka jūs izkāpt straumi un jūs varat sazināties ar. 

Pieteikumā ka patērē straumi, Tas ir sava veida, kā tas darbojas. DynamoDB klients lūgt push datu tabulām. Straumes izvietot uz to, ko mēs saucam gabaliņi. Shards tiek samazināts neatkarīgi no tabulā. Viņi nav rindā pilnīgi ar starpsienām jūsu galda. Un iemesls, kāpēc ir jo viņi rindā ietilpībai, pašreizējā jauda galda. 

Viņi izvietot savu Sava auto mērogošana grupa, un viņi sāk spin out atkarībā par cik raksta nāk, cik reads-- tiešām tā raksta. Nav reads-- bet kā daudzi raksta nāk. 

Un tad uz muguras beigas, mēs esam tas, ko mēs izsaukt KCl, vai Kinesis Client bibliotēka. Kinesis ir plūsma datu apstrādes tehnoloģija no Amazon. Un straumes ir veidota uz to. 

Tātad jūs izmantot KCL ļāva lietojumprogrammai lasīt straumi. Kinesis Client Library faktiski pārvalda darbiniekus par jums. Un tas arī nav dažu interesantas lietas. Tas radīs dažas tabulas up Jūsu DynamoDB tablespace izsekot, kuras preces ir apstrādāti. Tātad šādā veidā, ja tas nokrīt atpakaļ, ja tas apgāžoties un nāk un izpaužas bija atpakaļ uz augšu, tā var noteikt, kur bija to apstrādājot straumi. 

Tas ir ļoti svarīgi, ja jūs runājat par vairoties. Man vajag zināt, ko dati tika apstrādāta un kādi dati ir vēl jāapstrādā. Tātad KCL bibliotēka plūsmām būs dos jums daudz šo funkcionalitāti. Tā rūpējas par visu mājturība. Tā pieceļas strādājoša katram Shard. Tas rada administratīvu tabulu par katru Shard, katram darbiniekam. Un, tā kā šie darba ņēmēji uguns, viņi uztur šīs tabulas lai jūs zināt šo ierakstu bija lasīt un apstrādāt. Un tad, ka veids, ja process nomirst un nāk atpakaļ tiešsaistē, tas var atsākt tieši tur, kur tas bija off. 

Tāpēc mēs izmantojam šo par pārrobežu reģionā replikācija. Vairāki klienti daudz ir nepieciešamību pārvietot datus vai daļu savas datu tabulas ap dažādiem reģioniem. Ir deviņi reģioni visapkārt pasaulei. Tātad tur varētu būt need-- I varētu būt lietotājus Āzijā, lietotāji in East Coast no ASV. Tie ir dažādi dati, kas ir jābūt uz vietas sadalītas. Un varbūt lietotājs lido no Asia vairāk nekā uz Amerikas Savienotajām Valstīm, un es gribu atkārtot viņa dati ar viņu. Tad, kad viņš saņem no lidmašīnas, viņš ir laba pieredze, izmantojot savu mobilo lietotni. 

Jūs varat izmantot pārrobežu reģionu replikācijas bibliotēka, lai to paveiktu. Būtībā mēs esam sniedza divas tehnoloģijas. Viens ir konsole pieteikumu jūs varat piecelties uz savu EC2 instancē. Tā darbojas tīru replikāciju. Un tad mēs deva jums bibliotēku. Bibliotēka jūs varat izmantot, lai izveidotu savu pieteikumu, ja jums gribu darīt trakas lietas ar to data-- filtrs, atkārtot tikai daļa no tā, pagriezt datus, pārvietotu to par atšķirīgs galds, tā tālāk un tā tālāk. Tātad tas ir sava veida ko tas izskatās. 

DynamoDB Streams var būt apstrādā, ko mēs saucam Lambda. Mēs minēts mazliet par notikumu piedziņas pieteikuma arhitektūras. Lambda ir galvenais komponents, kas. Lambda ir kods, kas ugunsgrēki pēc pieprasījuma atbildot uz konkrētā gadījumā. Viens no šiem gadījumiem varētu būt ieraksts parādās plūsmā. Ja ieraksts parādās uz strauta, mēs saucam šo Java funkciju. Nu, tas ir JavaScript, un Lambda atbalsta Node.js, Java, Python, un drīz atbalstīs citās valodās, kā arī. Un pietiek pateikt, tas ir tīrs kods. rakstīt Java, jūs definētu klasi. Jūs spiediet JAR augšup Lambda. Un tad jums norādīt, kuru klase zvanīt, atbildot uz kuriem notikums. Un tad Lambda infrastruktūra aiz ka darbosies šo kodu. 

Šo kodu var apstrādāt ieraksti off straumi. To var darīt kaut ko tā vēlas ar to. Šajā konkrētajā piemērā, visi mēs esam īsti dara, ir piesakoties atribūtus. Bet tas ir tikai kods. Kods var darīt jebko, vai ne? 

Tātad jūs varat pagriezt, ka dati. Jūs varat izveidot atvasinātu viedokli. Ja tas ir dokumenta struktūra, Jūs varat saplacināt struktūru. Jūs varat izveidot aizstājējus indeksus. Visu veidu lietas, jūs varat darīt ar DynamoDB plūsmas. 

Un tiešām, tas, ko tas izskatās. Tātad jūs saņemsiet šos atjauninājumus nāk. Viņi nāk pie virknes. Viņi lasa ar Lambda funkciju. Viņi pagriežot datus un spiežot to atvasinātajos tabulās, paziņojot ārējās sistēmas izmaiņām, un stumšanas datus ElastiCache. 

Mēs runājām par to, kā likt kešatmiņu pie datu bāzē, ka pārdošanas scenārijs. Nu kas notiek, ja es atjaunināt posteņa nosaukums? Nu, ja man bija Lambda funkcija darbojas uz šo tabulu, ja es atjaunināt objektu aprakstu, tas būs uzņemt ierakstu pie strauta, un tas būs atjaunināt ElastiCache instance ar jaunajiem datiem. Tātad tas ir daudz Ko mēs darām ar Lambda. Tas ir līme kods, savienotāji. Un tas tiešām dod spēja uzsākt un palaist ļoti sarežģītas lietojumprogrammas bez speciālu serveri infrastruktūra, kas ir patiešām foršs. 

So iesim atpakaļ uz mūsu reāllaika balsošana arhitektūra. Tas ir jauns un uzlabots ar mūsu strauti un KCL ļāva pieteikumu. Tāds pats kā iepriekš, mēs varam rīkoties ar jebkura mēroga vēlēšanām. Mums patīk šis. Mēs darām out izkliedes apkopo vairākiem spaiņiem. Mēs esam ieguvuši optimistisks atslēga notiek. Mēs varam saglabāt mūsu vēlētājiem mainīt savas balsis. Tie var balsot tikai vienu reizi. Tas ir fantastiski. Real-time vaina tolerance, mērogojams apkopošana tagad. Ja lieta apgāžoties, to zina, kur restartēt sevi kad tas nāk atpakaļ uz augšu, jo mēs esam izmantojot KCl lietotni. Un tad mēs varam izmantot arī, ka KCL pieteikumu virzīt datu out uz sarkano nobīdi par citu app analytics, vai izmantošana elastīga MapReduce palaist reāllaika straumēšanas kolonijas off no šiem datiem. 

Tātad šie ir lietas, ko mēs nav runājuši par daudz. Bet viņi papildu tehnoloģijām, kas nāk sedz, ja jūs meklējat pie šiem scenārijiem veidiem. 

Labi, tā ka ir par analytics ar DynamoDB plūsmas. Jūs varat savākt de-piekrāptais dati, darīt visu veidu jauku sīkumi, apkopoti dati atmiņu, veidot šos atvasinātos tabulas. Tas ir milzīgs lietošanas gadījumu ka daudz klientu ir saistīti ar, ņemot ligzdotu īpašības šiem JSON dokumentu un radot papildu rādītājus. 

Mēs esam beigās. Paldies par gultnis ar mani. Tātad parunāsim par atsauce arhitektūra. DynamoDB sēž vidū uz tā daudz AWS infrastruktūru. Būtībā jūs varat aizšmaukt līdz visu, ko jūs vēlaties. Pieteikumus veidota, izmantojot Dynamo ietvert Lambda, ElastiCache, CloudSearch, push datus ārā Elastīgs MapReduce, imports, eksports no DynamoDB uz S3, visos darbplūsmas veidu. Bet, iespējams, ir labākais lieta runāt, un tas ir tas, kas ir patiešām Interesanti ir tad, kad mēs runāt par notikumu orientētu pieteikumiem. 

Tas ir piemērs iekšēja projekts ka mēs esam, kur mēs esam patiesībā publishing apkopot aptaujas rezultātus. Tātad e-pasta saites, kas mēs izsūtīt, tur būs būt mazliet saite sakot klikšķi šeit, lai reaģētu uz aptauju. Un, kad persona noklikšķina ka saikne, kas notiek ir tie nojaukt droša HTML Anketā no S3. Nav servera. Tas ir tikai S3 objekts. 

Šo veidlapu nāk uz augšu, slodzes up pārlūkprogrammā. Tas ir got mugurkauls. Tas ir ieguvuši komplekss JavaScript ka tas darbojas. Tātad, tas ir ļoti bagāts pieteikumu darbojas klienta pārlūkprogrammu. Viņi nezina, ka viņi nav mijiedarbojas ar back end serveri. Šajā brīdī, tas viss ir pārlūks. 

Viņi publicēt rezultātus, ko mēs saucam par Amazon API Gateway. API Gateway ir vienkārši web API ka jūs varat definēt un hook up lai neatkarīgi vēlaties. Šajā konkrētajā gadījumā mēs esam saliekts līdz Lambda funkciju. 

Tātad mans POST darbība ir notiek bez serveri. Būtībā, ka API Gateway sēž tur. Tas maksā man neko, kamēr cilvēki sākt norīkošanu uz to, vai ne? Lambda funkciju tikai sēž tur. Un tas maksā man neko līdz cilvēki sāk hitting to. Tātad jūs varat redzēt, kā apjoma palielinās, tas ir, kad maksa nāk. Es neesmu darbojas serverī 7/24. 

Tāpēc es pull formu uz leju no spaiņa, un es post caur API Gateway uz Lambda funkciju. Un tad Lambda funkcija saka, jūs zināt ko, es esam ieguvuši dažas PIIs, daži personu identificējoša informācija Šajās atbildēs. Es saņēmu komentārus, kas nāk no lietotājiem. Man e-pasta adreses. Man lietotājvārdus. 

Ļaujiet man dalīt off. Es esmu gatavojas, lai radītu dažus metadati off šajā ierakstā. Un es esmu gatavojas virzīt metadati par DynamoDB. Un es varētu šifrēt visus datus un push to DynamoDB ja es gribu. Bet tas ir vieglāk par mani, šajā izmantot gadījumu, lai iet uz priekšu ir teikšana, Es esmu gatavojas virzīt izejas datus uz šifrētā S3 spainī. Tāpēc es izmantot uzcelta S3 servera pusē šifrēšana un Amazon Key Management Pakalpojumu tāpēc, ka man ir atslēga, kas var pagriezt par regulāru intervālu, un es varu aizsargāt ka profesionālās atbildības apdrošināšana dati kā daļu no šī visa darbplūsmu. 

Tātad, ko es esmu darījis? Esmu tikko izvērsta vesela pieteikums, un man nav servera. Tātad, ir tas, ko notikums virza pieteikumu arhitektūra dara jums. 

Tagad, ja jūs domājat par izmantošana gadījumā this-- mums ir citi klienti es runāju copyright precīzu arhitektūru, kas palaist fenomenāli lielas kampaņas, kas meklē to un iet, ak. Jo tagad, viņi var būtībā push to, kas tur, pieņemsim, ka kampaņa vienkārši sēdēt tur līdz tā uzsāk, un nav jāuztraucas vīģes par kāda veida infrastruktūras būs tur, lai atbalstītu to. Un tad, tiklīdz ka kampaņa tiek darīts, tas ir tāpat kā ar infrastruktūru vienkārši uzreiz dodas prom jo tur tiešām Nav infrastruktūra. Tas ir tikai kods, kas atrodas uz Lambda. Tas ir tikai dati, kas sēž DynamoDB. Tas ir pārsteidzošs veids veidot lietojumprogrammas. 

Mērķauditorija: Tātad tas ir vairāk gaistoša nekā tas būtu ja tas tika glabāti faktisko serveri? 

RICK Houlihan: Protams. Tā kā šī servera instancē būtu jābūt 7/24. Tā ir jābūt pieejamai kāds atbildēt. Nu guess what? S3 ir 7/24. S3 vienmēr atbild. Un S3 ir ļoti, ļoti labs at apkalpo up objektus. Šie objekti var būt HTML failus, vai JavaScript failus, vai neatkarīgi vēlaties. Jūs varat palaist ļoti bagāts tīmekļa lietojumprogrammas no S3 spaiņiem, un cilvēki. 

Un tā tas ir ideja šeit ir, lai saņemtu prom no tā, kā mēs izmantojām, lai domāt par to. Mēs visi izmanto domāt Noteikumi serveriem un saimniekiem. Tas nav par to vairs. Tas ir par infrastruktūru, kā kodu. Izvietot kodu mākonis un ļaujiet mākonis palaist to jums. Un tas, ko AWS mēģina darīt. 

Mērķauditorija: Tātad jūsu zelta lodziņā vidū API Gateway nav servera, piemēram, bet tā vietā ir just-- 

RICK Houlihan: Jūs varat domāt par to kā servera fasādi. Viss tas ir tas, ņemšu HTTP pieprasīt un karte to uz citu procesu. Tas ir viss, tā dara. Un šajā gadījumā, mēs esam kartēšanu tā, lai Lambda funkciju. Labi, tā ka ir viss, ko es saņēmu. Liels paldies. Es novērtēju to. Es zinu, ka mēs gribam mazliet laika gaitā. Un cerams, jūs guys got mazliet informācijas ka jūs varat atņemt šodien. Un es atvainojos, ja es devos vairāk nekā daži no jūsu galvas, bet tur ir laba daudz fundamentāls fundamentālās zināšanas ka es domāju, ka ir ļoti vērtīgs, lai jums. Tātad paldies par to, ka mani. [Aplausi] Mērķauditorija: [dzirdams] ir tad, kad jūs bijāt sakot Jums bija iet cauri lieta no sākuma līdz beigām lai iegūtu tiesības vērtības vai tās pašas vērtības, kā būtu vērtības mainīties, ja [nedzirdama]. 

RICK Houlihan: Ak, idempotent? Kā vērtības mainās? Nu, jo, ja man nav palaist to visu ceļu līdz beigām, tad es nezinu, kādas izmaiņas tika veikti pēdējo jūdzi. Tas nav gatavojas būt tie paši dati, kā tas, ko es redzēju. Mērķauditorija: Ak, lai jūs vienkārši nav gotten visu ievadi. RICK Houlihan: Right. Jums ir jāiet no sākuma līdz beigām, un tad tas ir būs konsekventa valsts. Cool. 

Mērķauditorija: Tātad jūs mums parādīja DynamoDB var darīt dokumentu vai atslēgas vērtību. Un mēs pavadījām daudz laika uz galvenā vērtība ar hash un veidus uzsist to apkārt. Kad jūs paskatījās šajās tabulās, ir tas, ka atstājot aiz dokumenta pieeja? 

RICK Houlihan: es nebūtu saka atstājot novārtā. 

Mērķauditorija: Viņi bija atdalīta no the-- 

RICK Houlihan: Ar dokumenta pieeja, dokumentu tips DynamoDB ir tikai domā par kā cita atribūtu. Tas ir atribūts, kas satur hierarhiska datu struktūra. Un tad rodas jautājumi, Jūs varat izmantot rekvizītus no šiem objektiem, izmantojot objektu notāciju. Lai es varētu filtrēt uz ligzdotu īpašumā JSON dokumenta. Mērķauditorija: Tātad jebkurš laiks es do dokumentu pieeju, Es varu veida ierasties pie tabular-- Mērķauditorija: Absolutely. Mērķauditorija: --indexes un lietas, jūs vienkārši runāja par. RICK Houlihan: Jā, tad indeksi un visu, kas, ja jūs vēlaties, lai indeksēt īpašības JSON, tā, ka mēs būtu jādara, tas ir, ja Ievietojot JSON objektu vai dokumentu uz Dinamo, jūs varētu izmantot plūsmas. Straumes varētu lasīt ievadi. Tu gribētu saņemt, ka JSON iebilst un jūs teiktu OK, kāda ir īpašums es gribu indekss? 

Jūs veidojat atvasinātu tabulu. Tagad tas ir veids, kā tas darbojas šobrīd. Mēs neļaujam jums indeksēt tieši šie īpašumi. 

Mērķauditorija: Tabularizing savus dokumentus. 

RICK Houlihan: Tieši tā, izlīdzināšanai tas, tabularizing to, tieši tā. Tas ir tas, ko jūs darīt ar to. 

Mērķauditorija: Paldies. 

RICK Houlihan: Yep, absolūti, paldies. Mērķauditorija: Tātad, tas ir sava veida Mongo tiekas REDIS classifers. 

RICK Houlihan: Jā, tas ir daudz, piemēram, ka. Tas ir labs apraksts par to. Cool.