[Speel van musiek] Rick Houlihan: Alle reg. Hallo almal. My naam is Rick Houlihan. Ek is 'n senior skoolhoof oplossings argitek by AWS. Ek fokus op NoSQL en DynamoDB tegnologie. Ek is vandag hier om te praat jy 'n bietjie oor hulle. 

My agtergrond is hoofsaaklik in die data laag. Ek het die helfte van my ontwikkeling loopbaan skryf databasis, toegang data, oplossings vir verskeie toepassings. Ek het in Wolk skynwerklikmaking is vir ongeveer 20 jaar. Dus, voordat die wolk die wolk ons gebruik om dit te noem nut afreken. En die idee is, dit is soos PG & E, jy betaal vir wat jy gebruik. Vandag noem ons dit die wolk. 

Maar oor die jare, het ek gewerk vir 'n paar maatskappye jy het waarskynlik nog nooit gehoor van. Maar ek het 'n lys van die tegniese saamgestel prestasies, ek dink jy wil sê. Ek het agt patente in Wolk stelsels skynwerklikmaking, mikroverwerker ontwerp, komplekse gebeurtenis verwerking, en ander gebiede as well. 

So hierdie dae, fokus ek meestal op NoSQL tegnologie en die volgende generasie databasis. En dit is oor die algemeen wat ek gaan om hier te wees met jou praat vandag oor. So wat jy kan verwag van hierdie sessie Ons gaan deur 'n kort geskiedenis van data verwerking. Dit is altyd nuttig om verstaan ​​waar ons vandaan kom en hoekom ons waar ons is. En ons sal 'n bietjie praat bietjie oor NoSQL tegnologie van 'n fundamentele oogpunt. 

Ons sal kry in 'n paar van die DynamoDB internals. DynamoDB is AWS se geen smaak. Dit is 'n ten volle beheer en aangebied NoSQL oplossing. En ons sal 'n bietjie oor Table Talk struktuur, APIs, datatipes, indekse, en 'n paar van die internals van daardie DynamoDB tegnologie. Ons kry in 'n paar van die ontwerp patrone en beste praktyke. Ons sal praat oor hoe jy gebruik hierdie tegnologie vir 'n paar van aansoeke vandag se. En dan sal ons 'n bietjie praat oor die evolusie of die opkoms van 'n nuwe paradigma in programmering genoem gebeurtenis gedrewe programme en hoe DynamoDB speel in wat as goed. En ons sal jou laat 'n bietjie van 'n verwysing argitektuur bespreking sodat ons kan praat oor 'n paar van die maniere waarop jy kan DynamoDB gebruik. 

So eerste off-- dit is 'n vraag Ek hoor 'n baie is, wat is 'n databasis. Baie mense dink hulle weet wat 'n databasis is. As jy Google, sal jy dit sien. Dit is 'n 'n gestruktureerde stel data gehou in 'n rekenaar, veral die een wat toeganklik is op verskeie maniere. Ek veronderstel dit is 'n goeie definisie van 'n moderne databasis. Maar ek hou nie daarvan nie, want impliseer dit 'n paar van die dinge. Dit impliseer struktuur. En dit impliseer dat dit op 'n rekenaar. En databasisse het nie bestaan ​​altyd op rekenaars. Databasisse eintlik in baie maniere bestaan. 

So 'n beter definisie van 'n databasis is iets soos hierdie. 'N databasis 'n georganiseerde meganisme vir die stoor, bestuur en die herwinning van inligting. Dit is van About.com. So ek hou hiervan, want dit is werklik gesprekke oor 'n databasis wat 'n bron, 'n bron van inligting, nie noodwendig iets wat sit op 'n rekenaar. En deur die geskiedenis, ons het nie altyd rekenaars. 

Nou, as ek vra die gemiddelde ontwikkelaar vandag wat is 'n databasis, wat is die antwoord wat ek kry. Iewers kan ek dinge vashou. Reg? En dit is waar. Maar dit is jammer. Omdat die databasis is regtig die fondament van die moderne jeug. Dit is die grondslag van elke aansoek. En hoe jy dit bou databasis, hoe jy te struktureer dat die data gaan dikteer hoe dit aansoek doen as jy op die skaal. 

So 'n baie van my werk vandag is besig met wat gebeur wanneer ontwikkelaars neem hierdie benadering en die hantering van die nadraai van 'n program wat nou skalering buite die oorspronklike bedoeling en lyding van slegte ontwerp. So hopelik wanneer jy loop vandag weg, sal jy het 'n paar van die gereedskap in jou gordel wat jy hou van die maak van die dieselfde foute. Alles reg. So laat ons praat oor 'n bietjie van die tydlyn van databasis tegnologie. Ek dink ek lees 'n artikel nie so lank gelede en dit het gesê iets op die lines-- dit is 'n baie poëtiese verklaring. Daar word gesê dat die geskiedenis van data verwerking is vol hoë water van data oorvloed. OK. Nou, ek dink dit is soort van 'n ware. Maar ek eintlik kyk is as Die geskiedenis is eintlik gevul met 'n hoë watermerk van data druk. Omdat die data koers van inname gaan nooit af. Dit gaan net op. 

En innovasie gebeur wanneer sien ons data druk, wat is die bedrag van die data wat nou in kom in die stelsel. En dit kan nie verwerk word nie doeltreffend óf in die tyd of in die koste. En dit is wanneer ons begin om te kyk na data druk. 

So wanneer ons kyk na die eerste databasis, hierdie is die een wat tussen ons ore. Ons is almal gebore met dit. Dis 'n lekker databasis. Dit het 'n hoë beskikbaarheid. Dit is altyd op. Jy kan altyd dit kry. 

Maar dit is enkele gebruiker. Ek kan nie deel van my gedagtes met jou. Jy kan nie my gedagtes te kry wanneer jy wil hê hulle. En hulle abilitiy is nie so goed nie. Ons vergeet dinge. Elke nou en dan, een van ons blare en beweeg na 'n ander bestaan en ons alles verloor dit was in daardie databasis. So dit is nie al wat goed is. 

En dit het goed gewerk met verloop van tyd toe ons terug in die dag wanneer al wat ons regtig nodig het om te weet, is waar gaan ons om te gaan op môre of waar ons versamel die beste kos. Maar as ons begin om te groei as 'n beskawing en die regering begin tot stand te kom, en besighede begin om te ontwikkel, ons begin om te besef ons moet 'n bietjie meer as wat ons kon in ons kop sit. Alles reg? 

Ons benodig stelsels van rekord. Ons benodig plekke om in staat te stoor nie. So het ons begin skryf dokumente, skep biblioteke en argiewe. Ons het begin die ontwikkeling van ' stelsel 'n grootboek rekeningkundige. En dat die stelsel van grootboek tel hardloop die wêreld vir baie eeue, en miskien selfs millennia as Ons soort gegroei tot die punt waar daardie data vrag oortref die vermoë van die stelsels in staat wees om dit te bevat. 

En dit werklik gebeur het in die 1880's. Reg? In die 1880 Amerikaanse Sensus. Dit is regtig waar die draaipunt wys moderne verwerking van data. Dit is die punt wat die bedrag van die data wat ingesamel is deur die Amerikaanse regering het tot die punt waar dit het agt jaar te verwerk. 

Nou, agt years-- as jy weet, die sensus lopies elke 10 years-- so dit is redelik duidelik dat deur die tyd wat ons het die sensus 1890, die bedrag van die data wat gaan verwerk deur die regering was gaan na die 10 jaar oorskry dat dit sou neem om van stapel gestuur die nuwe sensus. Dit was 'n probleem. 

So 'n man met die naam Herman Hollerith het saam en hy uitgevind eenheid rekord punch kaarte, punch card reader, punch kaart tabel leer, en die versameling van die meganismes vir hierdie tegnologie. En dat die maatskappy dat hy by die gevorm tyd, saam met 'n paar van die ander, eintlik het een van die pilare van 'n klein maatskappy wat ons vandag ken genoem IBM. 

So IBM oorspronklik in die databasis besigheid. En dit is werklik wat hulle gedoen het. Hulle het die verwerking van data. 

As so die verspreiding van punch kaarte, 'n vernuftige meganismes om te kan benut wat tegnologie om gesorteerde gevolg stelle poll. Jy kan sien in hierdie foto daar het ons 'n little-- dit is 'n bietjie small-- maar jy kan sien 'n baie vernuftige meganiese meganisme waar ons 'n punch kaart dek. En neem iemand se 'n bietjie skroewedraaier en vas deur die slots en hom ophef om die wedstryd te kry, wat gesorteer resultate stel. 

Dit is 'n samevoeging. Ons doen dit al die tyd vandag in die rekenaar, waar jy dit doen in die databasis. Ons gebruik word om dit te doen met die hand, reg? Mense het hierdie dinge saam. En dit was die verspreiding van hierdie ponskaarte in wat ons genoem data dromme en data rolle, papier tape. 

Die data verwerking bedryf het 'n les uit die speler klaviere. Speler klaviere terug by die draai van die eeu gebruik om papier rolle met slots gebruik op om dit te vertel wat sleutels om te speel. So dat die tegnologie is aangepas uiteindelik na digitale data stoor, omdat hulle die data kan sit op die papier tape rolle. 

Nou, as 'n gevolg, data is actually-- hoe jy toegang tot hierdie data was direk afhanklik van hoe jy dit gestoor word. So as ek die data op 'n band, Ek het toegang tot die data lineêr. Ek moes die hele rol band om toegang tot al die data. As ek die data in punch kaarte, kon ek dit toegang in 'n bietjie meer random mode, miskien nie so vinnig. 

Maar daar was beperkinge in hoe ons toegang tot data op grond van hoe gestoor. En so was dit 'n probleem gaan in die '50s. Weereens, kan ons begin om te sien dat soos ons nuwe tegnologie te ontwikkel om te verwerk die data, regs, dit maak die deur vir nuwe oplossings, vir nuwe programme, nuwe aansoeke vir die data. En regtig, bestuur kan die rede gewees het waarom ons ontwikkel 'n paar van hierdie stelsels. Maar besigheid vinnig geword die bestuurder agter die evolusie van die moderne databasis en die moderne lêer stelsel. 

So die volgende ding wat vorendag gekom het in die jare 50 was die lêerstelsel en die ontwikkeling van ewetoeganklike stoor. Dit was pragtig. Nou, almal van 'n skielike, kan ons ons lêers op enige plek op die hardeskyf en ons kan hierdie inligting lukraak toegang. Ons kan ontleed wat inligting uit lêers. En ons opgelos al die wêreld se probleme met die verwerking van data. 

En dat duur ongeveer 20 of 30 jaar tot die evolusie van die relasionele databasis, wat is wanneer die wêreld het ons besluit nou moet 'n bewaarplek wat nederlae het die uitbreiding van data oor die lêer stelsels wat ons gebou het. Reg? Te veel data versprei in te veel plekke, die de-duplisering van data, en die koste van die stoor was enorm. 

In die 70's, die duurste hulpbron dat 'n rekenaar gehad het, was die stoor. Die verwerker was beskou as 'n vaste koste. Toe ek die koop van die boks, die CPU doen 'n bietjie werk. Dit gaan spin of dit is eintlik werk of nie. Dit is regtig 'n gesink koste. 

Maar wat my kos as 'n besigheid is stoor. As ek meer skywe koop volgende maand, dit is 'n werklike koste wat ek betaal. En dat die stoor is duur. 

Nou is ons vinnig vorentoe 40 jaar en ons het 'n ander probleem. Die bereken is nou die duurste hulpbron. Die stoor is goedkoop. Ek bedoel, ons kan enige plek gaan op die wolk en ons kan goedkoop stoorplek vind. Maar wat ek nie kan kry nie goedkoop is bereken. 

So het die evolusie van vandag se tegnologie, van die databasis tegnologie, regtig om gefokus verspreide databasisse wat nie ly dieselfde tipe skaal beperkinge van relasionele databasisse. Ons sal 'n bietjie praat oor wat dit eintlik beteken. 

Maar een van die redes en die bestuurder agter this-- ons gepraat oor die data druk. Data druk is iets wat dryf innovering. En as jy kyk na oor die afgelope vyf jaar, dit is 'n grafiek wat die data vrag oor die algemene onderneming lyk soos in die laaste vyf jaar. 

En die algemene reël hierdie days-- as jy gaan Google-- is 90% van die data wat wat ons vandag op te slaan, en dit was gegenereer in die laaste twee jaar. OK. Nou, dit is nie 'n tendens wat nuut is. Dit is 'n tendens wat al gaan uit vir 100 jaar. Herman Hollerith sedert ontwikkel die punch kaart, Ons het die bou van data repositories en versamel data op fenomenale pryse. 

So oor die laaste 100 jaar, ons het hierdie tendens gesien. Dit gaan nie verander nie. Vorentoe, ons gaan om te sien hierdie, indien nie 'n versnelde tendens. En jy kan sien wat dit lyk. 

As 'n besigheid in 2010 het een terabyte van data onder bestuur, vandag beteken hulle is besturende 6,5 petabytes van data. Dit is 6500 keer meer data. En ek weet dit. Ek werk met hierdie besighede elke dag. Vyf jaar gelede het ek maatskappye sal praat wat my sou praat oor wat 'n pyn dit is om terabyte van data te bestuur. En hulle sou praat my oor hoe ons sien dat dit waarskynlik gaan 'n petabyte of twee wees binne 'n paar jaar. 

Hierdie selfde maatskappye Vandag is ek die vergadering met, en hulle praat met my oor die probleem is daar met die bestuur tien 20 petabytes van data. So het die ontploffing van die data in die bedryf ry die enorme nodig vir 'n beter oplossings. En die relasionele databasis net nie lewe tot die vraag. 

En so is daar 'n lineêre korrelasie tussen data druk en tegniese innovasie. Die geskiedenis het ons gewys dit nie, dat met verloop van tyd, wanneer die volume van data wat moet verwerk oorskry die kapasiteit van die stelsel om dit te verwerk in 'n redelike tyd of teen 'n redelike koste, dan nuwe tegnologie is uitgevind om die probleme op te los. Diegene nuwe tegnologie, op sy beurt, die deur oopmaak na 'n ander stel probleme, wat versamel nog meer data. 

Nou, ons is nie van plan om dit te stop. Reg? Ons is nie van plan om dit te stop. Hoekom? Want jy kan nie alles weet daar is om te weet in die heelal. En so lank as wat ons lewe is, regdeur die geskiedenis van die mens, ons het altyd gedryf om meer te leer ken. 

So dit lyk asof elke duim beweeg ons af in die pad van wetenskaplike ontdekking, ons die bedrag van data te vermenigvuldig wat ons nodig het om eksponensieel te verwerk soos ons ontbloot meer en meer en meer oor die innerlike werking van die lewe, oor hoe die heelal werk, oor ry die wetenskaplike ontdekking, en die uitvinding wat ons vandag doen. Die volume van die data net voortdurend toeneem. So in staat om te gaan met hierdie probleem is enorm. 

So een van die dinge ons kyk as die rede waarom NoSQL? Hoe NoSQL hierdie probleem op te los? Wel, relasionele databasisse, Structured Query Language, SQL-- dit is regtig 'n konstruk van die relasionele database-- hierdie dinge geskik vir die stoor. 

Terug in die 70's, weer, skyf is duur. Die voorsiening van die stoor oefening in die onderneming is nimmereindigende. Ek weet. Ek het dit. Ek het vir 'n stoor bestuurders enterprised Super maatskappy terug in die '90s. En die onderste lyn is racking ander stoor array was net iets wat gebeur elke dag in die onderneming. En dit het nooit gestop. Stoor hoër digtheid, vraag vir 'n hoë digtheid stoor, en vir meer doeltreffende stoor devices-- dit nooit gestop. 

En NoSQL is 'n groot tegnologie want dit normaliseer die data. Dit de-duplikate die data. Dit plaas die data in 'n struktuur wat is agnostikus elke toegang patroon. Verskeie programme kan getref dat SQL databasis, hardloop ad hoc-navrae, en kry data in die vorm dat hulle nodig om te verwerk vir hul werklading. Dit klink fantasties. Maar die bottom line is met enige stelsel, as dit agnostikus alles, dit is geskik vir niks. OK? 

En dit is wat ons kry met die relasionele databasis. Dit is geskik vir die stoor. Dit is genormaliseer. Dit is relasionele. Dit ondersteun die ad hoc-navrae. En dit en dit skale vertikaal. 

As ek nodig om 'n groter SQL databasis te kry of 'n meer kragtige SQL databasis, Ek gaan koop 'n groter stuk yster. OK? Ek het gewerk met 'n baie kliënte wat deur middel van die groot opgraderings gewees in hul SQL infrastruktuur net om uit te vind ses maande later, hulle weer slaan die muur. En die antwoord van Oracle of MSSQL of enigiemand anders is kry 'n groter boks. Wel vroeër of later, kan jy nie koop 'n groter boks, en dit is die werklike probleem. Ons moet eintlik dinge verander. So waar werk dit? Dit werk goed vir die regte analytics, OLAP-tipe werklading. En dit is regtig waar SQL behoort. Nou, dit vandag gebruik word in baie online transaksionele verwerking-tipe aansoeke. En dit werk net mooi op 'n sekere vlak van benutting, maar dit is net nie die skaal die manier waarop NoSQL doen. En ons sal 'n bietjie praat bietjie oor waarom dit. 

Nou, NoSQL, aan die ander kant, is meer geskik vir bereken. OK? Dit is nie agnosties te die toegang patroon. Is wat ons noem de-genormaliseer struktuur of 'n hiërargiese struktuur. Die data in 'n relasionele databasis is saamgevoeg uit verskeie tafels die siening wat jy nodig het te produseer. Die data in 'n databasis NoSQL word gestoor in 'n dokument wat bevat die hiërargiese struktuur. Al die data wat normaalweg sou wees saamgevoeg om daardie siening te produseer word gestoor in 'n enkele dokument. En ons sal 'n bietjie praat oor hoe dit werk in 'n paar van die kaarte. 

Maar die idee hier is dat jy te slaan jou data as hierdie geïnstantieert uitsig. OK? Jy skaal horisontaal. Reg? As ek nodig het om die verhoog grootte van my NoSQL cluster, Ek het nie nodig om 'n groter boks te kry. Ek kry 'n ander boks. En ek cluster wat saam en ek kan die data segment. Ons sal 'n bietjie praat oor wat sharding is, te wees in staat wees om die skaal wat databasis oor verskeie fisiese toestelle en verwyder die versperring wat vereis dat my vertikaal skaal. 

So dit is regtig gebou vir aanlyn transaksie verwerking en skaal. Daar is 'n groot onderskeid hier tussen verslaggewing, reg? Verslagdoening, weet ek nie die vrae ek gaan om te vra. Reg? Reporting-- as iemand uit my bemarking afdeling wil hoeveel van my kliënte just-- hierdie besondere kenmerk wat gekoop op hierdie day-- Ek weet nie wat navraag hulle gaan om te vra. So ek moet agnostikus te wees. 

Nou, in 'n aanlyn transaksionele aansoek, Ek weet watter vrae wat ek vra. Ek, die aansoek om gebou 'n baie spesifieke workflow. OK? So as ek optimaliseer die data stoor wat workflow ondersteun, dit gaan vinniger. En dit is hoekom NoSQL kan regtig versnel die lewering van hierdie tipe van dienste. Alles reg. 

So ons gaan om te kry in 'n bietjie van die teorie hier. En 'n paar van julle, julle oë kan rol terug 'n bietjie. Maar ek sal probeer om dit te hou as hoë vlak as wat ek kan. So as jy in die projek bestuur, is daar 'n konstruk genoem driehoek van beperkings. OK. Die driehoek van beperkings voorskrifte jy kan nie alles het al die tyd. Kan nie jou pie en eet dit ook. So in die projek bestuur, die driehoek beperkings is, kan jy dit goedkoop te hê, jy kan dit vinnig het, of jy kan dit goed. Kies twee. Want jy kan nie al drie. Reg? OK. 

So jy hoor oor hierdie 'n baie. Dit is 'n driedubbele beperking, driehoek van driedubbele beperking, of die yster driehoek is oftentimes-- wanneer jy praat met bestuurders projekteer, hulle sal praat oor hierdie. Nou, databasisse hul eie yster driehoek. En die yster driehoek van data is wat ons CAP stelling noem. OK? 

CAP stelling voorskrifte hoe databasisse bedryf onder 'n baie spesifieke toestand. En ons sal praat oor wat daardie toestand is. Maar die drie punte van die driehoek, om so te praat, is C, konsekwentheid. OK? So in CAP, konsekwentheid beteken dat alle kliënte wat toegang tot die databasis sal altyd 'n baie konsekwent siening van data. Gaan niemand kyk twee verskillende dinge. OK? As ek sien die databasis, Ek sien dieselfde siening as my vennoot wat sien dieselfde databasis. Dit is konsekwentheid. 

Beskikbaarheid beteken dat indien die databasis online, as dit bereik kan word, dat alle kliënte sal altyd in staat wees om te lees en skryf. OK? Sodat elke kliënt wat kan die databasis te lees sal altyd in staat wees lees data en skryf data. En as dit die geval is, dit is 'n beskikbare stelsel. 

En die derde punt is wat ons noem partisie verdraagsaamheid. OK? Partition verdraagsaamheid middel dat die stelsel werk goed ondanks fisiese netwerk mure tussen die nodes. OK? So nodusse in die cluster kan nie met mekaar praat, wat gebeur? Alles reg. 

So relasionele databasisse choose kan jy twee van hierdie te kies. OK. So relasionele databasisse te kies wees konsekwent en beskikbaar is. As die verdeling gebeur tussen die DataNodes in die data stoor, die databasis ineenstortings. Reg? Dit gaan net af. OK. 

En dit is die rede waarom hulle om te groei met 'n groter bokse. Reg? Want daar is no-- gewoonlik, 'n cluster databasis, daar is nie baie van hulle wat werk op die manier. Maar die meeste databasisse skaal vertikaal binne 'n enkele vak. Omdat hulle nodig het om te wees konsekwent en beskikbaar is. As 'n partisie was ingespuit, dan sou jy 'n keuse te maak. Jy het 'n keuse te maak tussen konsekwent en beskikbaar is. 

En dit is wat NoSQL databasisse te doen. Alles reg. So 'n NoSQL databasis, is dit kom in twee geure. Ons have-- Wel, dit kom in baie geure, maar dit kom met twee basiese characteristics-- wat sou ons CP databasis, of 'n roep konsekwent en verdeling verdraagsaamheid stelsel. Hierdie ouens die keuse maak dat wanneer die nodes verloor kontak met mekaar, ons gaan nie toelaat dat mense om meer te skryf. OK? 

Tot op daardie verdeling verwyder word, skryftoegang is geblokkeer. Dit beteken hulle is nie beskikbaar nie. Hulle is konsekwent. Wanneer ons sien dat partisie spuit self, ons is nou konsekwent, want ons gaan nie om die data verandering op twee toelaat kante van die verdeling onafhanklik van mekaar. Ons sal moet herstel kommunikasie voordat enige werk na die data word toegelaat nie. OK? 

Die volgende geur sou 'n AP stelsel, of 'n beskikbare en verdeel verdraagsaamheid stelsel. Hierdie ouens nie omgee nie. Reg? Enige node dat 'n kry skryf, ons sal dit vat. So ek replicerende my data oor verskeie nodes. Hierdie nodes kry 'n kliënt, kliënt kom in, sê, ek gaan 'n paar data te skryf. Node sê, geen probleem. Die node langs hom kry 'n skryf op dieselfde rekord, hy gaan nie 'n probleem te sê. Iewers weer op die einde terug, dat die data gaan herhaal. En dan iemand gaan om te besef, uh-oh, het hulle stelsel sal besef, uh-oh, daar is 'n werk na twee kante. Wat doen ons? En wat hulle doen dan is hulle iets doen wat hulle toelaat om die data staat te los. En ons sal praat oor dat in die volgende grafiek. 

Ding om te wys hier. En ek is nie van plan om te kry veel in hierdie, want dit kry in diep data teorie. Maar daar is 'n transaksionele raamwerk wat lopies in 'n relasionele stelsel wat laat my toe om veilig te maak updates verskeie entiteite in die databasis. En diegene updates sal plaasvind alles op een slag, of glad nie. En dit is genoem ACID transaksies. OK? 

Suur gee ons atomiciteit, konsekwentheid, isolasie, en duursaamheid. OK? Dit beteken atoom, transaksies, al my updates óf gebeur of hulle doen nie. Konsekwentheid beteken dat die databasis sal altyd in 'n bestendige gebring staat na 'n update. Ek sal nooit die databasis in 'n los swak toestand na die toepassing van 'n update. OK? 

So dit is 'n bietjie anders as CAP konsekwentheid. CAP konsekwentheid beteken al my kliënte kan altyd die data. ACID konsekwentheid beteken dat wanneer 'n transaksie gedoen is, se data goed. My verhoudings is alles goed. Ek is nie van plan om 'n ouer ry verwyder en laat 'n klomp van die weeskinders in 'n ander tafel. Dit kan nie gebeur as ek is konsekwent in 'n suur transaksie. 

Isolasie beteken dat transaksies sal altyd voorkom een ​​na die ander. Die eindresultaat van die data sal dieselfde wees staat asof daardie transaksies wat gelyktydig uitgereik is in volgorde uitgevoer word. So dit is concurrency beheer in die databasis. So basies, ek kan nie inkrementeer die dieselfde waarde twee keer met twee operasies. 

Maar as ek sê voeg 1 op hierdie waarde, en twee transaksies kom in en probeer om dit te doen, is die een gaan om daar eers en die ander een se gaan om daar na te kry. So op die ou end, het ek nog twee. Jy sien wat ek bedoel? OK. 

Duursaamheid is redelik eenvoudig. Wanneer die transaksie erken word, is dit gaan om daar te wees, selfs As die stelsel ineenstort. Wanneer die stelsel herstel, wat transaksie wat gepleeg is is eintlik gaan om daar te wees. So wat is die waarborg suur transaksies. Dit is redelik mooi waarborge om op 'n databasis, maar hulle kom op daardie koste. Reg? 

Want die probleem met hierdie raamwerk is indien daar 'n muur in die data stel, ek het 'n besluit te neem. Ek gaan om te laat updates aan die een kant of die ander. En as dit gebeur, dan is ek nie meer gaan in staat wees om in stand te hou daardie eienskappe. Hulle sal nie konsekwent wees. Hulle sal nie geïsoleer word. Dit is waar dit breek vir relasionele databasisse. Dit is die rede relasionele databasisse skaal vertikaal. 

Aan die ander kant, het ons wat genoem BASE tegnologie. En dit is jou NoSQL Databasisse. Alles reg. So het ons ons CP, AP databasisse. En dit is wat jy basies noem beskikbaar, sagte staat, uiteindelik konsekwent. OK? 

Basies beskikbaar nie, omdat hulle is partisie verdraagsaam. Hulle sal altyd daar, selfs al is daar 'n netwerk afskorting tussen die nodes. As ek 'n node kan praat, ek is gaan in staat wees om data te lees. OK? Ek kan nie altyd in staat wees om te skryf data as ek 'n konsekwente platform. Maar ek sal in staat wees om data te lees. 

Die sagte staat dui dat wanneer ek lees dat data, dit kan nie dieselfde as die ander nodes wees. As 'n reg op 'n node is uitgereik iewers anders in die cluster en dit het nie herhaal oor die cluster nog toe ek lees dat die data, dat die staat kan nie konsekwent wees. Dit sal egter wees uiteindelik konsekwent, Dit beteken dat wanneer 'n skryf gemaak om die stelsel, dit sal herhaal oor die nodes. En uiteindelik, dat die staat in orde gebring sal word, en dit sal 'n konsekwente staat. 

Nou, CAP stelling regtig speel net in een voorwaarde. Dit toestand wanneer dit gebeur. Want wanneer dit wat in normale modus, daar is geen partisie, alles is konsekwent en beskikbaar is. Jy bekommer slegs sowat CAP wanneer ons dat partisie. So dit is skaars. Maar hoe die stelsel reageer wanneer daardie voorkom dikteer watter tipe stelsel ons te doen het met. 

So laat ons neem 'n blik op wat wat lyk soos vir AP stelsels. OK? AP stelsels kom in twee weergawes. Hulle kom in die geur wat 'n meester meester, 100%, altyd beskikbaar. En hulle kom in die ander geur, wat sê, jy weet wat, ek gaan om te bekommer oor hierdie skeiding ding wanneer 'n werklike verdeling plaasvind. Andersins, daar gaan primêre wees nodes wie gaan die regte te neem. OK? 

So as ons iets soos Cassandra. Cassandra sal 'n meester wees meester, laat my skryf aan enige node. So wat gebeur? So ek het 'n voorwerp in die databasis wat bestaan ​​op twee nodes. Kom ons noem daardie voorwerp S. So ons het die staat vir die S. Ons het 'n paar operasies op S wat aan die gang. Cassandra laat my toe om skryf aan verskeie nodes. So kom ons sê ek kry 'n skryf s twee nodes. Wel, wat eindig gebeur is ons noem dat 'n skeiding gebeurtenis. Daar kan nie 'n fisiese netwerk partisie. Maar as gevolg van die ontwerp van die stelsel, dit is eintlik skeiding so gou as ek 'n skryf op twee nodes. Dit is vir my nie dwing om skryf al deur een knoop. Ek skryf op twee nodes. OK? 

So nou het ek twee state. OK? Wat gaan gebeur is vroeër of later, daar gaan 'n replikasie gebeurtenis. Daar gaan wees wat ons bekend as 'n partisie herstel, wat is waar hierdie twee state saam te kom terug en daar gaan 'n algoritme wees wat loop in die databasis, besluit wat om te doen. OK? By verstek, laaste update wen in die meeste AP stelsels. So is daar gewoonlik 'n standaard algoritme, wat hulle noem 'n terugbel funksie, iets wat sal genoem word wanneer hierdie toestand bespeur 'n paar logika voer dat die konflik op te los. OK? Die standaard terugbel en standaard resolver in die meeste AP databasisse is, raai wat, tyd stempel wen. Dit was die laaste update. Ek gaan dit update daar sit. Ek kan hierdie rekord stort dat ek gestort af in 'n herstel log sodat die gebruiker later terug kan kom en sê, hey, was daar 'n botsing. Wat het gebeur? En jy kan eintlik stort 'n rekord van al die botsings en die rollbacks en kyk wat gebeur. 

Nou, as 'n gebruiker, kan jy ook sluit logika in die callback. So jy kan dit verander terugbel operasie. Jy kan sê, hey, ek wil om hierdie data te remedieer. En ek wil om te probeer en saamsmelt daardie twee rekords. Maar dit is aan jou. Die databasis weet nie hoe om dit doen deur verstek. Die meeste van die tyd, die enigste ding wat die databasis weet hoe om te doen is sê, hierdie een was die laaste rekord. Dit is die een wat gaan om te wen, en dit is die waarde ek gaan sit. Sodra dit partisie herstel en replisering plaasvind, ons het ons staat, wat is nou se prima, wat die merge toestand van al die voorwerpe. So AP stelsels hierdie. CP stelsels hoef nie te bekommer hieroor. Want sodra 'n partisie kom in die spel, het hulle net ophou om skryf. OK? So dit is baie maklik om te hanteer konsekwent as jy nie enige updates te aanvaar. Dit is met CP stelsels te doen. Alles reg. 

So laat ons praat 'n bietjie bietjie oor toegang patrone. Wanneer ons praat oor NoSQL, dit is alles oor die toegang patroon. Nou, SQL is ad hoc, navrae. Dit is relasionele winkel. Ons hoef nie te bekommer oor die toegang patroon. Ek skryf 'n baie komplekse navraag. Dit gaan en die data kry. Dit is wat dit lyk soos, normalisering. 

So in hierdie spesifieke struktuur, Ons is op soek na 'n produk katalogus. Ek het verskillende tipes van produkte. Ek het boeke. Ek het albums. Ek het video's. Die verhouding tussen produkte en enige een van hierdie boeke, albums, en videos tafels is 1: 1. Alles reg? Ek het 'n produk ID, en dat ID ooreenstem om 'n boek, 'n album, of 'n video. OK? Dit is 'n 1: 1 verhouding oor die tafels. 

Nou, al wat hulle books-- het, is die wortel eienskappe. Geen probleem. Dit is 'n groot. Een-tot-een verhouding, ek kry al die data wat ek nodig het om daardie boek beskryf. Albums-- albums het spore. Dit is wat ons een baie bel. Elke album kon baie spore. So vir elke snit op die album, kon ek nog 'n rekord in hierdie kind tafel. So ek een skep rekord in my albums tafel. Ek verskeie rekords te skep in die tabel spore. Een-tot-baie-verhouding. 

Hierdie verhouding is wat noem ons baie-tot-baie. OK? Jy sien dat die akteurs kan wees in baie films, baie videos. So wat ons doen, is sit ons dit kartering tabel tussen die wat dit net kaarte van die akteur ID om die video ID. Nou kan ek 'n navraag van die sluit skep videos deur akteur video om akteurs, en dit gee my 'n lekker lys van al die films en al die akteurs wat in daardie fliek was. 

OK. So hier gaan ons. Een-tot-een is die top-vlak verhouding; een-tot-baie, albums om spore; baie-tot-baie. Dit is die drie top-vlak verhoudings in 'n databasis. As jy weet hoe die verhoudings werk saam, dan weet jy 'n baie oor databasis reeds. So NoSQL werk 'n bietjie anders. Kom ons dink oor vir 'n tweede wat dit lyk om te gaan kry al my produkte. 

In 'n relasionele winkel, ek wil al my produkte te kry op 'n lys van al my produkte. Dit is 'n baie navrae. Ek het 'n navraag vir al my boeke. Ek het 'n navraag van my albums. En ek het 'n navraag vir al my videos. En ek het om dit te sit almal saam in 'n lys en dien dit terug na die program wat is wat dit versoek. 

Om my boeke te kry, sluit ek by Produkte en boeke. Om my albums te kry, ek het om aan te sluit Produkte, albums en liedjies. En om my video's te kry, ek het na Produkte sluit in video's, sluit deur akteur video's, en bring die akteurs. So dit is drie navrae. Baie komplekse navrae aan vergader een gevolg stel. 

Dit is minder as optimale. Dit is hoekom wanneer ons praat oor 'n datastruktuur wat gebou agnostikus die toegang te wees pattern-- goed dit is groot. En jy kan sien dit is regtig mooi hoe ons die data het georganiseer. En jy weet wat? Ek het net een rekord vir 'n akteur. 

Dis koel. Ek het al my akteurs deduplicated, en ek behou my verenigings in hierdie kartering tafel. Maar, kry die data uit raak duur. Ek stuur die CPU regoor die stelsel by hierdie data strukture saam in staat wees om die data terug te trek. 

So hoe kry ek rond dit? In NoSQL dit gaan oor samevoeging, nie normalisering. So wil ons sê ons wil ondersteun die toegang patroon. As die toegang patroon om die aansoeke, Ek moet al my produkte te kry. Kom ons sit al die produkte in een tabel. As ek al die produkte in een tabel, Ek kan net kies al die produkte uit daardie tafel en ek kry dit alles. Goed hoe doen ek dit? Wel, in NoSQL daar is geen struktuur na die tafel. Ons sal 'n bietjie praat oor hoe dit werk in Dynamo DB. Maar jy hoef nie dieselfde te hê eienskappe en dieselfde eienskappe in elke enkele ry, in elke enkele item, soos jy doen in 'n SQL tafel. En wat dit moontlik maak om my te doen, is 'n baie dinge en gee my 'n baie buigsaamheid. In hierdie spesifieke geval, ek het my produk dokumente. En in hierdie spesifieke Byvoorbeeld, alles is 'n dokument wat in die tabel produkte. En die produk vir 'n boek mag 'n soort ID wat 'n boek spesifiseer. En die toepassing sou oorskakel op daardie ID. 

Aan die aansoek toegeroep, ek gaan om te sê o, wat rekord tipe is dit? O, dit is 'n boek rekord. Book rekords het hierdie eienskappe. Laat my 'n boek voorwerp te skep. So ek gaan die vul boek voorwerp met hierdie item. Volgende item kom en sê, wat is hierdie item? Wel hierdie item is 'n album. O, ek het 'n hele ander verwerking roetine vir wat, want dit is 'n album. Jy sien wat ek bedoel? 

So het die aansoek tier-- ek kies al hierdie rekords. Hulle het almal begin kom in. Hulle kan wees al die verskillende tipes. En dit is logika die aansoek se wat wissel oor die tipes en besluit hoe om dit te verwerk. 

Weereens, so ons die optimalisering van die skema vir die toegang patroon. Ons doen dit deur ineenstort die tafels. Ons is basies neem hierdie genormaliseer strukture, en ons bou hiërargiese strukture. Binne elkeen van hierdie rekords Ek gaan verskeidenheid eiendomme te sien. 

Binne hierdie dokument vir Albums, Ek sien skikkings van spore. Diegene spore nou become-- dit basies hierdie kind tabel bestaan ​​hier in hierdie struktuur. So jy kan dit doen in DynamoDB. Jy kan dit doen in MongoDB. Jy kan dit doen in enige NoSQL databasis. Skep hierdie tipe hiërargiese datastrukture dat jy data toelaat haal baie vinnig, want nou is ek hoef nie te voldoen. Toe ek voeg 'n ry in die Tracks tafel, of 'n ry in die tabel in Albums, Ek het om te voldoen aan die skema. Ek moet die kenmerk of die het eiendom wat gedefinieer word op die tafel. Elke een van hulle, toe ek voeg die ry. Dit is nie die geval in NoSQL. 

Ek kan heeltemal anders het eiendomme in elke dokument dat ek voeg in die versameling. So baie kragtige meganisme. En dit is regtig hoe jy optimaliseer die stelsel. Want nou die soektog, in plaas van die aansluiting by al hierdie tafels en uitvoering van 'n half dosyn navrae om terug te trek die data wat ek nodig het, Ek is die uitvoering van 'n navraag. En ek iterating oor die stel resultate. dit gee jou 'n idee van die krag van NoSQL. Ek gaan soort van sywaarts hier gaan en praat 'n bietjie oor hierdie. Dit is meer van die soort bemarking of technology-- die bemarking van tegnologie tipe bespreking. Maar dit is belangrik om te verstaan want as ons kyk na die top hier op hierdie grafiek, wat ons is op soek na is wat ons noem die tegnologie hype kurwe. En wat dit beteken is nuwe dinge kom in die spel. Mense dink dit is wonderlik. Ek het al my probleme opgelos. 

Dit kan die einde alles, wees almal om alles. En hulle begin om dit te gebruik. En hulle sê: hierdie dinge nie werk nie. Dit is nie reg nie. Die ou dinge was beter. En hulle gaan terug om te doen dinge wat die manier waarop hulle was. En dan uiteindelik hulle gaan, jy weet wat? Hierdie dinge is nie so sleg nie. O, dit is hoe dit werk. En sodra hulle uitvind hoe dit werke, het hulle begin beter. 

En die snaakse ding oor dit is, is dit soort van lyne tot watter noem ons die Tegnologie Aanneming Curve. So wat gebeur is ons het 'n soort tegnologie sneller. In die geval van 'n databasis, dit is data druk. Ons het gepraat oor die hoë waterpunte van data druk regdeur tyd. Wanneer die data druk treffers van 'n sekere punt, dit is 'n tegnologie sneller. 

Dit raak te duur. Dit neem te lank om die data te verwerk. Ons moet iets beter. Jy kry die innoveerders daar rondhardloop, probeer om uit te vind wat is die oplossing. Wat is die nuwe idee? 

Wat is die volgende beste manier om hierdie saak te doen? En hulle kom met iets. En die mense met die werklike pyn, die ouens by die bloeding rand, hulle sal almal spring oor dit, omdat hulle nodig het 'n antwoord. Nou wat onvermydelik happens-- en dit gebeur nou in NoSQL. Ek sien dit al die tyd. 

Wat gebeur is onvermydelik mense begin met behulp van die nuwe instrument op dieselfde manier het hulle die ou instrument. En hulle uitvind dit nie so goed werk. Ek kan nie onthou wie ek is praat vroeër vandag. Maar dit is soos wanneer die jackhammer is uitgevind, mense het nie swaai dit oor hulle hoof na die konkrete smash. 

Maar dit is wat is gebeur met NoSQL vandag. As jy loop in die meeste winkels, hulle probeer om te wees NoSQL winkels. Wat hulle doen, is hulle gebruik NoSQL, en hulle is die laai dit vol relasionele skema. Want dit is hoe hulle ontwerp databasisse. En hulle wonder, hoekom is dit nie presteer baie goed? Boy, hierdie ding stink. Ek moes al my handhaaf sluit in-- dit is soos, nee, nee. Handhaaf sluit? Hoekom is jy by data? Jy hoef nie aan te sluit in data NoSQL. Jy saamvoeg nie. 

So as jy wil om dit te vermy, leer hoe die program werk voordat jy eintlik begin dit te gebruik. Moenie probeer en gebruik die nuwe gereedskap die op dieselfde manier wat jy gebruik die ou gereedskap. Jy gaan 'n slegte ervaring. En elke keer dit is wat dit is oor. Wanneer ons begin kom hier, dit is omdat mense uitgepluis hoe om die gereedskap te gebruik. 

Hulle het dieselfde ding wanneer relasionele databasisse uitgevind, en hulle is vervang lêer stelsels. Hulle het probeer om lêerstelsels bou met relasionele databasisse want dit is wat mense verstaan. Dit het nie gewerk nie. So verstaan ​​die beste praktyke van die tegnologie jy werk met is groot. Baie belangrik. 

So ons gaan om te kry in DynamoDB. DynamoDB is AWS se ten volle beheer NoSQL platform. Wat beteken ten volle beheer beteken? Dit beteken dat jy nie nodig het om te regtig bekommerd oor enige iets. 

Jy kom in, vertel ons, ek moet 'n tafel. Dit moet soveel kapasiteit. Jy druk die knoppie, en ons voorsiening al die infrastruktuur agter die toneel dood. Nou dat is enorm. 

Want wanneer jy praat oor skalering 'n databasis, NoSQL data trosse aan skaal, hardloop petabytes, hardloop miljoene transaksies per sekonde, hierdie dinge is nie klein trosse. Ons praat van duisende gevalle. Besturende duisende gevalle selfs virtuele gevalle is 'n ware pyn in die boude. Ek bedoel, dink oor elke keer 'n bedryfstelsel kol kom uit of 'n nuwe weergawe van die databasis. Wat beteken dit om jou operasioneel? Dit beteken dat jy het 1200 bedieners wat moet verander. Nou selfs met outomatisasie, wat kan 'n lang tyd neem. Dit kan 'n baie laat operasionele hoofpyn, want ek kan dienste af. 

As ek werk hierdie databasisse, ek dalk blou groen ontplooi doen waar ek sit en op te gradeer helfte van my nodes, en dan die opgradering van die ander helfte. Neem dié van. So die bestuur van die infrastruktuur skaal is geweldig pynlik. En AWS neem dat die pyn uit. En NoSQL databasisse kan wees buitengewoon pynlike as gevolg van die manier waarop hulle die skaal. 

Skaal horisontaal. As jy wil 'n groter NoSQL kry databasis, jy koop meer nodes. Elke node jy koop is 'n ander operasionele hoofpyn. So laat iemand anders dit doen vir jou. AWS kan dit doen. 

Ons ondersteun dokument kernwaardes. Nou het ons nie te veel gaan in die ander grafiek. Daar is 'n baie verskillende geure van NoSQL. Hulle is al die soort van kry saam munged op hierdie punt. Jy kan kyk na DynamoDB en sê ja, Ons is albei 'n dokument en 'n sleutel waarde stoor hierdie punt. En jy kan die eienskappe argumenteer een oor die ander. Vir my is 'n baie van hierdie is regtig ses een helfte van 'n dosyn van die ander. Elkeen van hierdie tegnologie is 'n fyn tegnologie en 'n boete oplossing. Ek sou nie sê MongoDB is beter of erger as Couch, dan Cassandra, dan Dynamo, of andersom. Ek bedoel, dit is net 'opsies. 

Dit is vinnig en dit is konsekwent op enige skaal. So dit is een van die grootste bonusse wat jy kry met AWS. Met DynamoDB is die vermoë om 'n lae enkelsyfers te kry millisekonde latency op enige skaal. Dit was 'n ontwerp doel van die stelsel. En ons het kliënte wat doen miljoene transaksies per sekonde. 

Nou sal ek gaan deur 'n paar van daardie gebruik gevalle in 'n paar minute hier. Geïntegreerde toegang control-- ons het wat ons noem Identiteit Access Management, of IAM. Dit deurdring elke stelsel, elke diens wat AWS bied. DynamoDB is geen uitsondering nie. Jy kan toegang beheer die DynamoDB tafels. In al jou AWS rekeninge deur definieer toegang rolle en regte in die IAM infrastruktuur. 

En dit is 'n belangrike en integrale komponent in wat ons Event noem gedrewe programmering. Nou is dit 'n nuwe paradigma. 

GEHOOR: Hoe is jou tempo van die ware positiewe versus vals negatiewe op jou toegangsbeheer stelsel? Rick Houlihan: True positiewe versus vals negatiewe? GEHOOR: Returning wat jy moet terugkeer word? In teenstelling met een keer in 'terwyl dit nie terug wanneer dit moet bekragtig? 

Rick Houlihan: Ek kon nie vertel nie. As daar enige mislukkings hoegenaamd op dat Ek is nie die persoon om te vra daardie spesifieke vraag. Maar dit is 'n goeie vraag. Ek sou nuuskierig wees om te weet wat myself, eintlik. 

En so dan weer, nuwe paradigma is gebeurtenis gedrewe programmering. Dit is die idee dat jy kan ontplooi komplekse programme wat kan 'n baie, baie hoë skaal bedryf sonder enige infrastruktuur hoegenaamd nie. Sonder enige vaste infrastruktuur hoegenaamd nie. En ons sal 'n bietjie praat oor wat dit beteken as ons kry op die volgende paar kaarte. 

Die eerste ding wat ons sal doen is ons praat oor tafels. Tipes API data vir Dynamo. En die eerste ding wat jy sal oplet wanneer jy kyk na hierdie, As jy vertroud is met enige databasis, databasisse regtig twee soort van API's Ek sal dit noem. Of twee stelle API. Een van dié sou wees administratiewe API. 

Die dinge wat hulle sorg die funksies van die databasis. Die stoor enjin instel, opstel en die toevoeging van tafels. skep van databasis katalogusse en gevalle. Hierdie things-- in DynamoDB jy het 'n baie kort, kort lyste. 

So in ander databasisse, jy dalk dekades sien instruksies, van administratiewe opdragte, vir die instel hierdie bykomende opsies. In DynamoDB jy hoef nie die gevolg jy nie die stelsel instel, ons doen. Dus is die enigste ding wat jy hoef te doen is vertel my wat grootte tafel het ek nodig. Sodat jy 'n baie te kry beperkte stel van opdragte. 

Jy kry 'n Skep Table Update, Table, Verwyder Table, en beskryf Table. Dit is die enigste dinge jy nodig het vir DynamoDB. Jy hoef nie 'n stoor nodig enjin opset. Ek het nie nodig om te bekommer oor replikasie. Ek het nie nodig om te bekommer oor sharding. 

Ek het nie nodig om te bekommer oor enige van hierdie dinge. Ons doen dit alles vir jou. So dit is 'n groot hoeveelheid van die oorhoofse wat net gelig jou bord. Dan het ons die CRUD operateurs. CRUD is iets wat ons noem in die databasis wat Skep, Update, verwyder operateurs. Dit is jou algemene databasis bedrywighede. Dinge soos put item, kry item, update items, items te verwyder, joernaal navraag, scan. As jy wil hê dat die hele tabel scan. Trek alles van die tafel af. Een van die mooi dinge oor DynamoDB is dit laat parallel skandering. Sodat jy kan eintlik laat my weet hoeveel drade wat jy wil om te hardloop op daardie scan. En ons kan hardloop diegene drade. Ons kan spin dat scan up oor verskeie drade sodat jy kan die hele tabel scan ruimte baie, baie vinnig in DynamoDB. 

Die ander API ons het, is wat ons noem ons Streams API. Ons gaan nie te praat om veel oor hierdie nou. Ek het 'n paar inhoud later het in die dek oor hierdie. Maar Streams is regtig 'n running-- dink aan dit as die tyd bestel en verdeling verandering log. Alles wat gebeur op die tabel toon op die stroom. 

Elke skryf aan die tafel dui op die stroom. Jy kan daardie stroom lees en jy kan doen met dit. Ons sal praat oor wat tipes dinge wat jy doen met die dinge soos replikasie, skep sekondêre indekse. Alle vorme van regtig cool dinge wat jy kan doen met dit. 

Datatipes. In DynamoDB, sowel sleutel ondersteun ons waarde en die dokument data tipes. Op die linkerkant van die skerm hier, ons het ons basiese tipes. Sleutel tipes waarde. Dit is snare, getalle en installasie. 

Dus net drie basiese tipes. En dan kan jy stelle van daardie het. Een van die mooi dinge oor NoSQL is jy kan skikkings as eienskappe bevat. En met DynamoDB kan jy skikkings bevat basiese tipes soos 'n wortel eiendom. 

En dan is daar die dokument tik. Hoeveel mense is vertroud met into? Julle vertroud met into so baie? Dit is basies JavaScript, Voorwerp, notasie. Dit kan jy basies definieer 'n hiërargiese struktuur. 

Jy kan 'n dokument oor te slaan into DynamoDB die gebruik van gemeenskaplike komponente of boustene wat beskikbaar is in die meeste programmeertale. So as jy Java, is jy op soek na kaarte en lyste. Ek kan voorwerpe te skep daardie gebied kaart. A kaart as kernwaardes gestoor as eienskappe. En dit kan lyste van het waardes binne daardie eienskappe. Jy kan hierdie komplekse stoor hiërargiese struktuur as 'n enkele kenmerk van 'n DynamoDB item. 

So tafels in DynamoDB, soos die meeste NoSQL databasisse, tabelle items. In MongoDB jy sou noem hierdie dokumente. En dit sou die rusbank basis. Ook 'n dokument databasis. Jy noem hierdie dokumente. Dokumente of items eienskappe. Eienskappe kan bestaan ​​of bestaan ​​nie op die item. In DynamoDB, daar is een verpligte kenmerk. Net soos in 'n relasionele databasis, jy het 'n primêre sleutel op die tafel. 

DynamoDB het wat ons 'n hash sleutel noem. Hash sleutel moet uniek wees. So toe ek 'n hash tafel definieer, basies wat ek sê is elke item sal 'n gemors sleutel. En elke hash sleutel moet uniek wees. 

Elke item word gedefinieer deur daardie unieke hash sleutel. En daar kan net een wees. Dit is OK, maar dikwels wat mense nodig is wat hulle wil hê, is hierdie hash sleutel tot 'n bietjie meer te doen as net 'n unieke identifiseerder wees. Dikwels wil ons dat hash sleutel as die boonste vlak samevoeging emmer. En die manier waarop ons dit doen, is deur toevoeging van wat ons 'n reeks belangrike skakel. 

So as dit is net 'n hash tafel, moet hierdie unieke wees. As dit is 'n hash en omvang tafel, die kombinasie van die hash en die reeks moet uniek wees. So dink oor dit op hierdie manier. As ek 'n forum. En die vorm het onderwerpe, dit het poste, en dit het die antwoorde. 

So ek kan 'n hash het sleutel, wat is die onderwerp ID. En ek kan 'n verskeidenheid sleutel, wat is die reaksie ID. So as ek wil al die kry antwoorde vir spesifieke onderwerp, Ek kan net navraag die hash. Ek kan net sê gee my al die items wat hierdie hash het. En ek gaan elke vraag te kry of pos vir daardie spesifieke onderwerp. Hierdie top vlak swerms is baie belangrik. Hulle ondersteun die primêre toegang patroon van die aansoek. Oor die algemeen, hierdie is wat ons wil doen. Ons wil hê dat die table-- as jy die tafel te laai, ons wil die data te struktureer binne die tafel in so 'n manier dat die aansoek kan baie vinnig die resultate op te haal. En dikwels die manier om dit te doen, is hierdie swerms as ons handhaaf voeg die data. Basies, ons die data versprei in die helder emmer as dit kom in. 

Range sleutels toelaat me-- hash sleutels het om gelykheid te wees. Toe ek navraag n hash, ek het om te sê gee my 'n hash dat dit gelyk. Toe ek navraag van 'n reeks, ek kan sê gee my 'n verskeidenheid wat die gebruik van enige soort ryk operateur wat ons ondersteun. Gee my al die items vir 'n hash. Is dit gelyk, groter as, minder as, beteken dit mee te begin, dit bestaan ​​tussen hierdie twee waardes? So hierdie tipe reeks navrae dat ons altyd geïnteresseerd in. Nou een ding oor data, wanneer jy kyk na die toegang tot data, wanneer jy toegang tot die data, is dit altyd oor 'n samevoeging. Dit is altyd oor die rekords wat verband hou met hierdie. Gee my alles hier that's-- al die transaksies op hierdie kredietkaart vir die afgelope maand. Dit is 'n samevoeging. 

Byna alles wat jy doen in die databasis is 'n soort van samevoeging. So in staat is om in staat wees om te definieer hierdie emmers en gee jou die reeks eienskappe om in staat wees om 'n navraag op, diegene wat ryk navrae ondersteun baie, baie, baie toegang aansoek patrone. 

So het die ander ding wat die hash sleutel doen, is dit gee ons 'n meganisme in staat wees om die data te versprei. NoSQL databasisse werk die beste wanneer die data is eweredig versprei oor die cluster. Hoeveel mense is vertroud met hashing algoritmes? Toe ek en 'n hash hashing-- sê omdat 'n hashing algoritme is 'n manier om te kan genereer 'n ewekansige waarde van enige gegewe waarde. So in hierdie spesifieke geval, die hash algoritme loop ons is ND 5 gebaseer. 

En as ek 'n ID, en dit is my hash sleutel, ek het 1, 2, 3. Wanneer ek hardloop die hash algoritme, dit gaan om terug te kom en sê: goed 1 gelyk 7B, 2 gelyk 48, 3 gelyk CD. Hulle is versprei oor die sleutel ruimte. En hoekom doen jy dit? Want dit maak seker dat ek kan sit die rekords oor verskeie nodes. 

As ek dit doen inkrementeel, 1, 2, 3. En ek het 'n hash reeks wat lopies in hierdie spesifieke geval, 'n klein hash ruimte, dit loop van 00 tot VF, dan is die rekords gaan om in te kom en hulle gaan om te gaan 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. Wat gebeur? Elke insetsel gaan dieselfde knoop. Jy sien wat ek bedoel? 

Want toe ek verdeel die ruimte, en ek versprei hierdie rekords oor, en ek partisie, ek gaan om te sê partisie 1 het die sleutel ruimte 0-54. Partition 2 is 55-89. Partition 3 is AA VF. So as ek gebruik lineêr die verhoog ID's, kan jy sien wat gebeur. 1, 2, 3, 4, 5, 6, al manier tot 54. So as ek gehamer die rekords in die stelsel, alles eindig gaan een knoop. 

Dit is nie goed nie. Dit is 'n antipattern. In MongoDB hulle hierdie probleem As jy nie 'n hash sleutel te gebruik. MongoDB gee jou die opsie van hashing die sleutel waarde. Jy moet altyd doen, as jy 'n verhoog van hash sleutel MongoDB, of jy sal spyker elke skryf een knoop, en jy sal die beperking jou skryf deurset sleg. 

GEHOOR: Is dit A9 169 in desimale? 

Rick Houlihan: Ja, dit is iewers daar rond. A9, ek weet nie. Jy wil hê om my binêre kry om desimale sakrekenaar. My brein werk nie so nie. GEHOOR: Net 'n vinnige een jou Mongo kommentaar. So is die voorwerp ID wat kom native met Mongo dit doen? Rick Houlihan: Is dit dit? As jy dit spesifiseer. Met MongoDB, jy het die opsie. Jy kan elke dokument in specify-- MongoDB het om 'n underscore ID het. Dit is die unieke waarde. 

In MongoDB jy kan spesifiseer of om dit hash of nie. Hulle gee jou net die opsie. As jy weet dat dit random, geen probleem. Jy hoef nie om dit te doen. As jy weet dat dit is nie random, wat dit is die verhoog, doen dan die hash. 

Nou is die ding oor hashing, sodra jy hash 'n value-- en dit is Hoekom hash sleutels is altyd unieke navrae, want ek het verander die waarde, nou kan ek nie 'n reeks navraag te doen. Ek kan nie sê dit is tussen hierdie of daardie, omdat die hash waarde is nie van plan gelykstaande aan die werklike waarde. So wanneer jy hash wat sleutel, dit is net gelykheid. Dit is die rede waarom in DynamoDB hash sleutel navrae is altyd net gelykheid. 

So nou in 'n reeks key-- toe ek byvoeg dat reeks sleutel, diegene reeks sleutel rekords almal kom in en hulle kry gestoor word op dieselfde partisie. So hulle is baie vinnig, maklik opgespoor, want dit is die hash, dit is die reeks. En jy sien alles met dieselfde hash kry gestoor op dieselfde partisie ruimte. Jy kan daardie reeks sleutel gebruik om te help soek jou data naby aan sy ouer. So, wat ek eintlik hier? Dit is 'n baie-verhouding. Die verhouding tussen 'n hash sleutel en die reeks sleutel is een van baie. Ek kan verskeie hash sleutels het. Ek kan net het verskeie reeks sleutels in elke hash sleutel. 

Die hash definieer die ouer, die reeks definieer die kinders. Sodat jy kan sien daar is analoog hier tussen die relasionele konstruk en dieselfde tipes bou in NoSQL. Mense praat oor NoSQL as nonrelational. Dit is nie nonrelational. Data het altyd verhoudings. Daardie verhoudings net is anders geskoei. Kom ons praat 'n bietjie bietjie oor duursaamheid. Wanneer jy skryf DynamoDB, skryf is altyd drie-manier herhaal. Dit beteken dat ons drie AZ se. AZ se Beskikbaarheid sones. Jy kan dink van 'n Beskikbaarheid Sone as 'n data-sentrum of 'n versameling van data sentrums. Hierdie dinge is geografies geïsoleerd van mekaar oor verskillende skuld sones, oor verskillende krag roosters en vloedvlaktes. 'N versuim in een AZ is nie gaan om af te haal 'n ander. Hulle is ook gekoppel saam met 'n donker vesel. Dit ondersteun die een sub 1 millisekonde latency tussen AZS. So real time data herhalings staat in 'n multi AZS. 

En dikwels multi AZ ontplooi voldoen aan die hoë beskikbaarheid vereistes van die meeste onderneming organisasies. So DynamoDB versprei oor drie AZS by verstek. Ons gaan net om kennis van die skryf wanneer twee van die drie nodes terug te kom en sê: Ja, ek het dit. Hoekom is dit? Want op die lees kant ons is net gaan jy die data terug te gee wanneer ons kry dit uit twee nodes. 

As ek replicerende oor drie, en ek lees van twee, Ek is altyd gewaarborg om ten minste een het van daardie lui die wees mees onlangse afskrif van data. Dit is wat maak DynamoDB konsekwent. Nou kan jy kies om te draai diegene konsekwent lees af. In welke geval ek gaan om te sê, Ek sal net lees van een knoop. En ek kan nie waarborg dit gaan te wees van die mees onlangse data. 

So as 'n skryf kom in, dit is nog nie herhaal, jy gaan om dit te kry kopie. Dit is 'n uiteindelik konsekwent lees. En wat dit is, is die helfte van die koste. So dit is iets om oor te dink. Wanneer jy lees uit DynamoDB en jy die oprigting van jou lees kapasiteit eenhede, as jy uiteindelik kies konsekwent lees, is dit 'n baie goedkoper, dit gaan oor die helfte van die koste. 

En so dit spaar jy geld. Maar dit is jou keuse. As jy wil 'n konsekwente lees of 'n uiteindelik konsekwent lees. Dit is iets wat jy kan kies. 

Kom ons praat oor indekse. So ons dat genoemde boonste vlak samevoeging. Ons het hash sleutels, en ons het reeks sleutels. Dit is lekker. En dit is op die primêre tafel, ek een gekry hash sleutel, ek het een reeks sleutel. 

Wat beteken dit? Ek het een spesifieke eienskap het dat ek kan ryk navrae teen hardloop. Dit is die reeks sleutel. Die ander eienskappe op daardie item-- Ek kan filter op daardie eienskappe. Maar ek kan nie dinge doen soos dit begin met, of is groter as. 

Hoe kan ek dit doen? Ek skep 'n indeks. Daar is twee tipes indekse in DynamoDB. 'N indeks is regtig 'n ander siening van die tafel. En die plaaslike sekondêre indeks. 

Die eerste een wat ons sal praat oor. So plaaslike sekondêre word saambestaan op dieselfde partisie as die data. En as sodanig, is hulle op dieselfde fisiese knoop. Hulle is wat ons konsekwent te bel. Betekenis, sal hulle erken die skryf saam met die tafel. Wanneer die skryf kom in, ons sal skryf deur die indeks. Ons sal tot die tafel te skryf, en dan sal ons erken. So dit is konsekwent. Sodra die skryf was erken van die tafel, dit is gewaarborg dat die plaaslike sekondêre indeks sal dieselfde visie van data het. Maar wat hulle toelaat om te doen, is definieer alternatiewe reeks sleutels. 

Moet dieselfde hash gebruik sleutel as die primêre tafel, omdat hulle saam geleë op die dieselfde partisie, en hulle is konsekwent. Maar ek kan 'n indeks te skep met verskillende reeks sleutels. So byvoorbeeld, as ek 'n vervaardiger Dit was 'n rou dele tafel kom. En rou dele kom, en hulle saamgevoeg word deur die gemeente. En miskien is daar 'n herroeping. 

Enige deel wat gemaak is deur hierdie vervaardiger na hierdie datum, Ek nodig het om te trek uit my lyn. Ek kan 'n indeks spin wat sal kyk, saamgevoeg op die datum van vervaardig van daardie spesifieke deel. So as my top vlak tafel was reeds hashed deur vervaardiger, Miskien was dit gereël op 'n deel ID, ek kan 'n indeks af die tafel te skep as hashed deur vervaardiger en gewissel op die datum van vervaardiging. En op die manier wat ek kan sê, iets wat vervaardig tussen hierdie datums, Ek nodig het om te trek uit die lyn. So dit is 'n plaaslike sekondêre indeks. 

Hulle het die effek van beperking van jou hash sleutel ruimte. Omdat hulle mede-bestaan op dieselfde stoor knoop, hulle beperk die hash sleutel ruimte om 10 GB. DynamoDB, onder die tafels, sal partisie jou tafel elke 10 GB. Wanneer jy 10 gigs van data in ons gaan [PHH], en ons nog 'n knoop. 

Ons sal nie verdeel die LSI oor verskeie partisies. Ons sal die tafel te verdeel. Maar ons sal nie verdeel die LSI. So dit is iets belangrik om te verstaan is as jy baie doen, baie, baie groot swerms, dan is jy gaan beperk 10 GB op jou LSI. 

As dit die geval is, kan ons gebruik globale sekondêre. Global sekondêre is regtig 'n ander tafel. Hulle bestaan ​​heeltemal af te die kant van jou primêre tafel. En hulle laat my 'n te vind heeltemal ander struktuur. So dink aan dit as data word ingevoeg in twee verskillende tafels, gestruktureerde in twee verskillende maniere. 

Ek kan 'n heeltemal definieer verskillende hash sleutel. Ek kan 'n heeltemal definieer verskillende reeks sleutel. En ek kan dit loop heeltemal onafhanklik. As 'n saak van die feit, ek het bevoorraad my lees kapasiteit en skryf kapasiteit vir my globale sekondêre indekse heeltemal onafhanklik van my primêre tafel. As ek definieer die indeks, sê ek dit hoeveel lees en skryf kapasiteit dit gaan gebruik. 

En dit is aparte uit my primêre tafel. Nou beide van die indekse ons toelaat om nie net definieer hash en omvang sleutels, maar hulle ons toelaat om projekteer bykomende waardes. So as ek wil om te lees van die indeks, en ek wil 'n paar stel data te kry, Ek het nie nodig om terug te gaan na die hoof tabel om die bykomende eienskappe kry. Ek kan daardie bykomende projekteer eienskappe in die tabel in ter ondersteuning van die toegang patroon. Ek weet ons is waarskynlik om in sommige regtig, really-- om in die onkruid hier op sommige van hierdie dinge. Nou het ek om weg te dryf uit hierdie. 

GEHOOR: [onhoorbaar] --table sleutel bedoel was 'n gemors? Die oorspronklike hash? Multi-stroke? 

Rick Houlihan: Ja. Ja. Die tabel sleutel basies wys terug na die item. So 'n indeks is 'n wyser terug na die oorspronklike items op die tafel. Nou kan jy kies om 'n te bou indeks wat net het die tafel sleutel, en geen ander eienskappe. En hoekom kan ek dit doen? Wel, miskien is ek het baie groot items. 

Ek het regtig net nodig om te weet which-- my toegang patroon kan sê, watter items hierdie eiendom bevat? Hoef nie die item terug te keer. Ek het net nodig om te weet watter items bevat nie. Sodat jy kan indekse bou wat net die tafel sleutel. 

Maar dit is hoofsaaklik wat 'n indeks in die databasis is vir. Dit is vir die feit dat in staat om vinnig identifiseer wat rekords, wat rye, wat items in die tabel het die eienskappe wat ek soek. 

AVIP, so hoe werk dit? AVIP basies asynchrone. Die update kom in die tafel, tafel is dan asynchroon opgedateer al jou AVIP. Dit is die rede waarom AVIP is uiteindelik konsekwent. 

Dit is belangrik om daarop te let dat wanneer jy die bou van AVIP, en jy verstaan ​​wat jy skep 'n ander dimensie van aggregation-- nou kom ons sê 'n goeie voorbeeld hier is 'n vervaardiger. Ek dink ek het dalk gepraat oor 'n mediese toestel vervaardiger. Mediese toestel vervaardigers dikwels het serialized dele. Die dele wat gaan in 'n heupvervanging al 'n bietjie reeksnommer op hulle. En hulle kon miljoene het en miljoene en miljarde dele in al die toerusting wat hulle skip. Wel, wat hulle nodig het om saam te voeg onder verskillende dimensies, al die dele in 'n vergadering, al die dele wat gemaak is op 'n sekere lyn, al die dele wat gekom in van 'n sekere vervaardiger op 'n sekere datum. En dit swerms soms opstaan ​​in die biljoene. 

So ek werk met 'n paar van hierdie ouens wat ly want hulle is die skep van hierdie ginormous swerms in hul sekondêre indekse. Hulle kan 'n rou dele het tafel wat kom as net hash. Elke deel het 'n unieke reeksnommer. Ek gebruik die reeksnommer as die hash. Dis pragtig. My rou data tafel is versprei regoor die sleutel ruimte. My [? skryf?] [? inname?] is awesome. Ek neem 'n baie van die data. Dan wat hulle doen, is hulle 'n GSI. En ek sê, jy weet wat ek nodig het om te sien al die dele vir hierdie vervaardiger. Wel, almal van 'n skielike Ek is neem van 'n miljard rye, en stop hulle op een knoop, want toe Ek saam te voeg as die vervaardiger ID as die hash, en 'n deel nommer as die reeks, dan sal al die skielike Ek is om 'n miljard dele wat hierdie vervaardiger het my gered. 

Dit kan 'n baie laat druk op die GSI, weer, want ek gehamer een knoop. Ek sit al hierdie voeg in een knoop. En dit is 'n ware problematies gebruik geval. Nou, ek het 'n goeie ontwerp patroon vir hoe jy vermy. En dit is een van die probleme dat ek altyd werk met. Maar wat gebeur, is die GSI kan genoeg skryf kapasiteit nie in staat wees om te stoot almal rye in 'n enkele knoop. En wat gebeur dan is die primêre, die kliënt tafel, die primêre tabel sal gewurg omdat die GSI nie kan byhou nie. So my insetsel koers sal val op die primêre tafel as my GSI probeer om tred te hou. 

Alle reg, sodat GSI se LSI se watter een moet ek gebruik? LSI se stem ooreen. GSI se uiteindelik konsekwent. As dit is OK, ek beveel die gebruik van 'n GSI, hulle is baie meer buigsaam. LSI se gemodelleer kan word as 'n GSI. En as die data grootte per hash sleutels in jou versameling van meer as 10 GB, dan is jy gaan wil om dit te gebruik GSI want dit is net 'n harde limiet. 

Alle reg, sodat skalering. Deurset in Dynamo DB, jy kan voorsiening [onhoorbaar] deurset om 'n tafel. Ons het kliënte wat bevoorraad 60 billion-- doen 60000000000 versoeke, gereeld loop op oor 'n miljoen versoeke per sekonde op ons tafels. Daar is werklik geen teoretiese beperking op hoeveel en hoe vinnig die tafel kan hardloop in Dynamo DB. Daar is 'n paar sagte beperkings op jou rekening dat ons sit daar in so dat jy nie gaan mal. As jy wil meer as dat nie 'n probleem nie. Jy kom vertel ons. Ons sal draai die inbel. 

Elke rekening word beperk tot 'n sekere vlak in elke diens nie, net van die kolf af So het die volk nie gaan mal kry hulself in die moeilikheid. Geen beperking in grootte. Jy kan enige aantal sit van die items op 'n tafel. Die grootte van 'n item is beperk tot 400 kilogrepe elk, dit sou wees item nie die eienskappe. So die som van al die eienskappe is beperk tot 400 kilogrepe. En dan weer, ons het wat min LSI kwessie met die 10 gigagreep limiet per hash. GEHOOR: Klein nommer, ek mis wat jy my nou vertel dat is-- GEHOOR: O, 400 kilogreep is die maksimum grootte per item. So 'n item het al die eienskappe. So 400 k is die totale grootte van daardie item, 400 kilogrepe. So van al die eienskappe gekombineer word, al die data dit is in al die eienskappe, opgerol in 'n totale grootte, tans vandag die item limiet is 400 k. So weer skalering, bereik deur skeiding. Deurset is bevoorraad by die tafel vlak. En daar is eintlik twee knoppe. Ons het gelees kapasiteit en skryf kapasiteit. 

So hierdie is aangepas onafhanklik van mekaar. RCU se maat streng in ooreenstemming lees. OK, so as jy sê ek wil 1000 RCU se dit is streng in ooreenstemming, dit is in ooreenstemming lees. As jy sê ek wil uiteindelike konsekwent lees, jy kan voorsiening 1000 RCU se, jy gaan om uiteindelik 2000 konsekwent lees. En die helfte van die prys vir diegene uiteindelik bestaan ​​in lees. 

Weereens, aangepas onafhanklik van mekaar. En hulle het die throughput-- As jy verbruik 100% van jou RCU, jy is nie van plan om die impak beskikbaarheid van jou regte. Sodat hulle is heeltemal onafhanklik van mekaar. Alle reg, sodat een van die dinge wat Ek het genoem is kort wurg. Wurgend is sleg. Wurgend dui slegte geen SQL. Daar is dinge wat ons kan doen om te help jy die wurgend verlig dat jy ervaar. Maar die beste oplossing hierdie is laat ons 'n blik op wat jy doen nie, want daar is 'n anti-patroon in die spel hier. 

Hierdie dinge, dinge soos nie-uniform werklading, warm sleutels, warm mure. Ek slaan 'n spesifieke sleutel ruimte baie moeilik vir 'n paar spesifieke rede. Hoekom doen ek dit? Kom ons vind dat uit. Ek meng my warm data met koue data. Ek laat my tafels kry groot, maar daar is regtig slegs 'n paar van die data subset dit is baie interessant vir my. So vir log data, byvoorbeeld, 'n baie kliënte, hulle kry teken data elke dag. Hulle het 'n groot hoeveelheid van die log data. 

As jy net die storting alles wat log data in een groot tafel, met verloop van tyd tafel gaan massiewe kry. Maar ek is eintlik net in belangstel afgelope 24 uur, die afgelope sewe dae, die laaste 30 dae. Wat ook al die venster van die tyd dat ek belangstel in soek vir die geleentheid wat my pla, of die geval dat is interessant vir my, dit is die enigste venster tyd wat ek nodig het. So hoekom is ek om 10 jaar waarde van log data in die tabel? Wat is wat veroorsaak dat die tafel van die fragment. 

Dit raak groot. Dit begin sprei oor duisende nodes. En sedert jou vermoë is so laag is, is jy eintlik koers beperking op elke een van daardie individu nodes. So laat ons begin kyk na hoe doen ons rol tafel verby. Hoe kry ons dat die data 'n bietjie beter om hierdie probleme te vermy. En wat beteken dit lyk? Dit is wat dit lyk. Dit is wat slegte NoSQL lyk. 

Ek het hier 'n warm sleutel. As jy kyk op die kant hier, dit is al my mure. Ek het 16 partisies hier op hierdie spesifieke databasis. Ons doen dit al die tyd. Ek hardloop vir kliënte alle tye. Dit is bekend as die hitte kaart. Verhit kaart vertel my hoe jy toegang tot jou sleutel ruimte. En wat is dit vir my sê is dat daar 'n bepaalde hash dat dit 'n man hou van verskriklik baie, want hy is ' slaan dit regtig, regtig hard. 

So die blou is lekker. Ons hou van blou. Ons hou nie van rooi. Red se waar die druk kry tot 100%. 100%, nou is jy gaan om gewurg. So wanneer jy sien 'n rooi lyne soos this-- en dit is nie net Dynamo DB-- elke NoSQL databasis het hierdie probleem. Daar is anti-patrone wat kan ry hierdie tipe van toestande. Wat ek doen, is ek werk met kliënte om hierdie toestande te verlig. 

En wat beteken dit lyk? En dit is om die mees uit Dynamo DB deurset, maar dit is regtig om die meeste uit van NoSQL. Dit is nie beperk tot Dynamo. Dit is definitely-- ek gebruik om te werk aan Mongo. Ek is vertroud met baie NoSQL platforms. Elke mens het hierdie tipe warm sleutel probleme. Om die meeste uit van 'n NoSQL databasis, spesifiek Dynamo DB, jy wil die tabelle te skep waar die hash sleutel element het 'n groot aantal van verskillende waardes, 'n hoë graad van kardinaliteit. Want dit beteken ek skryf om baie van die verskillende emmers. 

Die meer emmers Ek is skriftelik aan, hoe meer waarskynlik Ek is te skryf dat lading versprei of lees laai uit oor verskeie nodusse, die meer geneig om 'n ek het hoë deurset op die tafel. En dan wil ek die waardes te wees versoek redelik eweredig oor tyd en egalig lukraak as moontlik. Wel, dit is soort van interessante, want ek kan nie regtig beheer wanneer die gebruikers kom. So voldoende om te sê, as ons versprei dinge uit oor die sleutel ruimte, ons sal waarskynlik in 'n beter vorm. 

Daar is 'n sekere bedrag van die tyd aflewering dat jy nie gaan om in staat te beheer. Maar dit is eintlik die twee dimensies wat ons het, ruimte, toegang eweredig verspreiding, tyd, versoeke aankom eweredig in die tyd. En as daardie twee voorwaardes voldoen word, dan is dit wat dit is gaan lyk. Dit is baie lekkerder. Ons is hier regtig gelukkig. Ons het 'n baie, selfs toegang patroon. Ja, miskien is jy kry 'n bietjie druk elke nou en dan, maar niks regtig te omvangryk. So dit is ongelooflik hoe baie keer, wanneer ek werk met kliënte, dat die eerste grafiek met die groot rooi bar en alles wat lelik geel dis al oor die plek, ons gedoen te kry met die oefening na 'n paar maande van re-argitektuur, hulle loop presies dieselfde werklading op presies dieselfde lading. En dit is wat dit is op soek soos nou. So, wat jy kry met NoSQL is 'n data skedule dit is absoluut gekoppel aan die toegang patroon. 

En jy kan die data skema te optimaliseer te ondersteun wat toegang patroon. As jy dit nie doen nie, dan is jy gaan om hierdie tipe van probleme sien met dié warm sleutels. 

GEHOOR: Wel, onvermydelik sommige plekke gaan warmer wees as ander. 

Rick Houlihan: Altyd. Altyd. Ja, ek bedoel daar is altyd a-- en weer, daar is sommige ontwerp patrone ons sal deurkom wat sal praat oor hoe jy dit hanteer met hierdie super groot swerms. Ek bedoel, ek het om hulle te hê, Hoe hanteer ons met hulle? Ek het 'n goeie gebruik geval dat ons oor sal praat vir wat. 

Alle reg, so laat ons praat oor 'n paar kliënte nou. Hierdie ouens is AdRoll. Ek weet nie of jy vertroud is met AdRoll. Jy sien hulle waarskynlik 'n baie op die leser. Hulle is ad re-fokus, hulle is die grootste advertensie re-teiken besigheid daar buite. Hulle gewoonlik gereeld loop oor 60000000000 transaksies per dag. Hulle doen oor 'n miljoen transaksies per sekonde. Hulle het 'n mooi eenvoudige tafel het struktuur, die besigste tafel. Dit is basies net 'n hash sleutel is die koekie, die reeks is die demografiese kategorie, en dan die derde kenmerk is die telling. 

So het ons almal koekies in ons leser van hierdie ouens. En wanneer jy gaan na 'n deelnemende handelaar, hulle basies kan jy score oor verskeie demografiese kategorieë. Wanneer jy na 'n webwerf en jy sê ek wil hierdie ad-- sien of basies het jy nie that-- sê maar wanneer jy gaan na die webwerf hulle sê jy wil hierdie advertensie te sien. En hulle gaan kry dat die advertensie van AdRoll. AdRoll lyk jy op hul tafel. Hulle vind jou koekie. Die adverteerders vertel hulle, ek wil iemand wie se middeljarige, 40-jarige man, in sport. En hulle kan jy score in die demografie en hulle besluit of nie dit is 'n goeie advertensie vir jou. 

Nou het hulle 'n SLA met hul advertensies verskaffers om sub-10 millisekonde verskaf reaksie op elke enkele aanvraag. So hulle gebruik Dynamo DB vir hierdie. Hulle is vir ons 'n tref miljoen versoeke per sekonde. Hulle is in staat om alles te doen hul soektogte, triage alles wat data, en kry wat add skakel terug na daardie adverteerders in onder 10 millisekondes. Dit is regtig mooi fenomenale implementering wat hulle het. 

Hierdie ouens actually-- is hierdie die ouens. Ek is nie seker of dit hierdie ouens. Dalk hierdie ouens. Basies gesê us-- nee, ek dink nie dit was hulle. Ek dink dit was iemand anders. Ek is besig met 'n kliënt wat my vertel wat nou dat hulle het gegaan om Dynamo DB, hulle is spandeer meer geld op snacks vir hul ontwikkeling span elke maand as wat hulle spandeer op hul databasis. So dit gee jou 'n gee idee van die kostebesparings wat jy kan kry in Dynamo DB is groot. Alle reg, dropcam is 'n ander maatskappy. Hierdie man is soort of-- as jy dink van internet van dinge, dropcam is basies internet sekuriteit video. Jy sit jou kamera daar buite. Kamera het 'n mosie detector. Iemand kom saam, snellers 'n wit punt. Kamera begin opname vir 'n rukkie totdat dit nie enige beweging meer op te spoor. Plaas dat die video op die internet. 

Dropcam was 'n maatskappy wat basies oorgeskakel na Dynamo DB omdat hulle ervaar enorme groeipyne. En wat hulle vir ons gesê, skielik petabytes van data. Hulle het geen idee gehad hulle diens sou so suksesvol te wees. Meer inkomende video as YouTube is wat hierdie ouens kry. Hulle gebruik DynamoDB te spoor al die metadata op al hul video belangrike punte. 

So het hulle S3 emmers hulle stoot al die binêre artefakte in. En dan het hulle Dynamo DB rekords wat wys mense aan diegene S3 drie voorwerpe. Wanneer hulle nodig het om te kyk na 'n video, hulle kyk op die rekord in Dynamo DB. Hulle klik op die skakel. Hulle trek die video van S3. So dit is soort van wat dit lyk soos. En dit is reguit uit hul span. 

Dynamo DB verminder hul lewering tyd vir video gebeure van vyf tot 10 sekondes. In hul ou relasionele winkel, hulle gebruik het om te gaan en uit te voer verskeie komplekse navrae aan figuur watter videos af te trek, tot minder as 50 millisekondes. So dit is ongelooflik, amazing hoeveel prestasie wat jy kan kry as jy optimaliseer en jy tune die onderliggende databasis ter ondersteuning van die toegang patroon. Halfbrick, hierdie ouens, wat is dit, Vrugte Ninja ek dink is hulle ding. Dat alle lopies op Dynamo DB. En hierdie ouens, hulle is 'n groot ontwikkeling span, groot ontwikkeling winkel. 

Nie 'n goeie span ops. Hulle het nie 'n baie van die operasie hulpbronne. Hulle sukkel om aan te hou probeer hul aansoek infrastruktuur up en hardloop. Hulle het gekom om ons. Hulle kyk na wat Dynamo DB. Hulle het gesê, dit is vir ons. Hulle het hul hele aansoek raamwerk op dit. Hier 'n paar baie mooi kommentaar uit die span op hul vermoë nou fokus op die bou die spel en nie om te handhaaf die infrastruktuur, wat was besig om 'n enorme bedrag van oorhoofse vir hul span. So dit is iets that-- die voordeel wat jy kry van Dynamo DB. 

Alle reg, om in data modelle hier. En ons het gepraat 'n bietjie oor hierdie een tot een, een vir baie, en baie baie tipe verhoudings. En hoe kan jy in stand te hou wat in Dynamo. In Dynamo DB gebruik ons indekse algemeen om die data van roteer een geur aan die ander kant. Hash sleutels, reeks sleutels, en indekse. 

In hierdie spesifieke Byvoorbeeld, as die meeste lande 'n vereiste dat die lisensiëring net een bestuurder lisensie se per persoon. Jy kan nie na twee bestuurder kry lisensies in die staat van Boston. Ek kan dit nie doen nie in Texas. Dit is soort van die manier waarop dit is. En so by die DMV, ons het soektogte, ons wil om te kyk up die rybewys deur die sosiale sekerheid nommer. Ek wil om te kyk die gebruiker besonderhede deur die bestuurder se lisensie nommer. 

So kan ons tafel 'n gebruiker se het dat het 'n hash sleutel op die reeksnommer, of die sosiale sekerheid nommer, en verskeie eienskappe gedefinieer op die item. Nou op die tafel ek 'n GSI kan definieer wat flips dat ongeveer wat sê ek wil 'n hash sleutel op die lisensie en dan al die ander items. Nou as ek wil navraag en vind die lisensie nommer vir enige gegewe Maatskaplike Security nommer, ek kan navraag die hooftafel. 

As ek wil navraag en ek wil om die sosiale sekerheid te kry nommer of ander eienskappe deur 'n lisensie nommer, kan ek navraag die GSI. Dit model is dat 'n mens tot een verhouding. Net 'n baie eenvoudige GSI, flip die dinge rondom. Nou, praat oor een vir baie. Een baie basies jou hash reeks sleutel. Waar kry ons 'n baie met hierdie gebruik geval is monitor data. Monitor data kom in gereelde interval, soos die internet van die dinge. Ons kry altyd al hierdie rekords kom in al die tyd. 

En ek wil al die lesings vind tussen 'n bepaalde tydperk. Dit is 'n baie algemene navraag in monitering infrastruktuur. Die pad gaan oor wat 'n te vind eenvoudige tafel struktuur, 'n tafel. Ek het 'n tafel metings toestel het met 'n hash sleutel op die toestel ID. En ek het 'n reeks-sleutel op die tyd stempel, of in hierdie geval, die epiese. En dat laat my kompleks voer navrae teen daardie reeks sleutel en terug te keer die rekords wat relatief tot die resultaat stel dat ek is op soek na. En dit bou dat 'n mens baie-verhouding in die primêre tabel deur die hash sleutel, reeks sleutel struktuur. 

So dit is soort van 'n ingeboude in die tabel in Dynamo DB. Toe ek 'n hash definieer en verskeidenheid t tafel, ek is definisie van 'n een tot baie-verhouding. Dit is 'n ouer-kind verhouding. 

Kom ons praat oor baie baie verhoudings. En vir hierdie spesifieke voorbeeld, weer, gaan ons GSI se gebruik. En laat ons praat oor die spel scenario waar ek 'n gegewe gebruiker. Ek wil om uit te vind al die speletjies wat hy geregistreer of speel in. En vir 'n gegewe spel, ek wil al die gebruikers te vind. So hoe kan ek dit doen? My gebruiker speletjies tafel, ek gaan 'n hash sleutel van gebruiker ID het en 'n reeks sleutel van die spel. 

So 'n gebruiker kan het veelvuldige speletjies. Dit is 'n een tot baie-verwantskap tussen die gebruiker en die games wat hy speel. En dan op die GSI, Ek sal dat ongeveer flip. Ek op die spel sal hash en Ek sal wissel op die gebruiker. So as ek wil al die kry spel die gebruiker se speel in, Ek sal die hooftafel navraag. As ek wil al die gebruikers kry wat speel 'n spesifieke spel, Ek bevraagteken die GSI. So jy sien hoe ons dit doen? Jy bou hierdie GSI om die steun gebruik geval, die aansoek, die toegang patroon, die aansoek. 

As ek nodig om 'n navraag op hierdie dimensie, laat my te skep 'n indeks op daardie dimensie. As ek dit nie doen nie, kan ek nie om nie. En afhangende van die gebruik geval, ek kan die indeks nodig het of ek dalk nie. As dit is 'n eenvoudige een tot baie die primêre tafel is goed. As ek nodig het om hierdie baie doen om baie se, of ek moet die een na kinders te doen, dan miskien ek hoef tweede die indeks. So dit hang alles af wat ek probeer om te doen en wat ek probeer om te kry voldonge. 

Waarskynlik Ek gaan nie te spandeer veel tyd praat oor dokumente. Dit kry 'n bietjie, waarskynlik, dieper as wat ons nodig het om in te gaan. Kom ons praat 'n bietjie oor ryk navraag uitdrukking. So in Dynamo DB ons het die vermoë om te skep wat ons noem projeksie uitdrukkings. Projeksie uitdrukkings is eenvoudig pluk die velde of die waardes wat jy wil om te wys. OK, so ek maak 'n keuse. Ek maak 'n navraag teen Dynamo DB. En ek sê, jy weet wat, show my net die vyf ster resensies vir hierdie produk. So dit is al wat ek wil sien. Ek wil nie al die sien ander eienskappe van die ry, Ek wil net om dit te sien. Dit is net soos in SQL wanneer jy sê kies ster of van die tafel, jy alles. Wanneer ek sê kies naam tafel, ek kry net een kenmerk. Dit is dieselfde soort ding in Dynamo DB of ander NoSQL databasisse. Filter uitdrukkings toelaat om my te basies sny die stel af gevolg. So maak ek 'n navraag. Navraag kan terug kom met 500 items. Maar ek wil net die items wat 'n kenmerk dat dit sê. OK, so laat filter diegene items wat nie ooreenstem met die spesifieke navraag. So het ons filter uitdrukkings. 

Filter uitdrukkings kan uitgevoer word op 'n kenmerk. Hulle is nie soos reeks navrae. Samel navrae is meer selektief. Navrae Filter vereis my om te gaan kry die hele resultate stel en dan kerf uit die data wat ek wil nie. Hoekom is dit belangrik? Want ek lees dit alles. In 'n navraag, ek gaan om te lees en dit gaan 'n reuse-oor die data wees. En dan gaan ek kerf uit wat ek nodig het. En as ek net 'n kerf paar rye, dan is dit OK. Dit is nie so ondoeltreffend. 

Maar as ek lees van 'n hele stapel data, net om uit te kerf een item, dan gaan ek beter wees af met behulp van 'n verskeidenheid navraag, want dit is baie meer selektief. Dit gaan om my te red 'n baie geld, want ek betaal vir daardie lees. Waar die resultate wat terug kom steek wat draad kleiner mag wees, maar ek betaal vir die lees. So verstaan ​​hoe jy kry die data. Dit is baie belangrik in Dynamo DB. 

Voorwaardelike uitdrukkings, dit is wat jy dalk optimisties locking noem. Update indien bestaan, of indien hierdie waarde is gelykstaande aan wat ek spesifiseer. En as ek 'n tyd stempel op 'n rekord, kan ek die data te lees. Ek kan die data verander. Ek kan gaan skryf dat data terug na die databasis. As iemand het verander die rekord, die tyd stempel verander het. En op die manier my voorwaardelike update kan update sê indien die tyd stempel gelyk hiervan. Of die update sal misluk omdat iemand opgedateer die rekord in die tussentyd. 

Dit is wat ons optimisties locking noem. Dit beteken dat iemand kan in te kom en dit verander, en ek gaan om dit te spoor wanneer ek terug gaan om te skryf. En dan kan ek eintlik lees dat data en sê: Ag, hierdie verander hy gesê. Ek nodig het om rekenskap te gee. En ek kan die data in te verander my teken en 'n ander update toe te pas. So kan jy die inkrementele vang updates wat plaasvind tussen die tyd dat jy die data en die lees tyd wat jy kan die data te skryf. 

GEHOOR: En die filter uitdrukking beteken eintlik nie in die aantal of not-- 

[INTERPOSING VOICES] Rick Houlihan: Ek sal nie kry te veel in hierdie. Dit is 'n gereserveerde navraag. Die pond View is 'n voorbehou navraag in Dynamo DB. Elke databasis het sy eie voorbehou name versamelings kan jy nie gebruik nie. Dynamo DB, as jy spesifiseer 'n pond in die voorkant van hierdie, kan jy die name bo definieer up. Dit is 'n gekla waarde. Dit is waarskynlik nie die beste sintaksis om het daar vir hierdie bespreking, want dit kry in 'n paar real-- Ek sou gewees praat meer oor dat op 'n dieper vlak. 

Maar voldoende om te sê nie, kan dit wees navraag scan waar hulle views-- nie menings pond is groter as 10. Dit is 'n numeriese waarde, ja. As jy wil, kan ons praat oor dat na die bespreking. Alle reg, sodat ons kry in sommige gevalle in die beste praktyke waar ons gaan om te praat oor 'n paar apps hier. Wat is die gebruik gevalle vir Dynamo DB. Wat is die ontwerp patrone in Dynamo DB. 

En die eerste een wat ons gaan praat oor die internet van die dinge. So kry ons 'n baie of-- dink ek, Wat is it-- meer as 50% van die verkeer op die internet hierdie dae is eintlik deur masjiene gegenereer word, outomatiese prosesse, nie deur die mens. Ek bedoel hierdie ding ding wat jy rond te dra in jou sak, hoeveel data dat ding is eintlik stuur om sonder jou wetende dat dit is absoluut amazing. Jou plek, inligting oor hoe vinnig jy gaan. Hoe dink jy Google Maps werke wanneer hulle jou vertel wat die verkeer is. Dit is omdat daar miljoene en miljoene mense rondry met selfone wat stuur data oor die hele tyd plaasvind. So een van die dinge oor hierdie tipe van data wat kom in, monitor data, teken data, tydreeksdata, is dit gewoonlik net interessante vir 'n bietjie van die tyd. Na daardie tyd, is dit nie so interessant. So het ons gepraat oor, moenie toelaat die tafels groei sonder grense. Die idee hier is dat miskien ek het 24 uur se gebeure in my warm tafel. En dat warm tafel gaan wees bevoorraad op 'n baie hoë koers, want dit is die neem van 'n baie data. Dit neem 'n baie van die data in en ek lees dit baie. Ek het 'n baie van die operasie het navrae hardloop teen daardie data. 

Na 24 uur, hey, jy weet wat, ek gee nie om nie. So miskien elke middernag ek roll my tafel oor na 'n nuwe tabel en ek deprovision hierdie tabel. En Ek neem die RCU en WCU se af, want 24 uur later Ek hardloop nie soveel navrae teen daardie data. So ek gaan om geld te spaar. En miskien 30 dae later het ek nie eens nodig om te sorg oor dit alles. Ek kon neem die WCU se al die pad af aan die een, omdat jy weet wat, dis nooit gaan kry geskryf na. Die data is 30 dae oud. Dit verander nooit. 

En dit is byna nooit gaan kry te lees, so laat ons neem net wat RCU af na 10. En Ek spaar 'n ton geld op hierdie data, en slegs betaal vir my warm data. So wat is die belangrikste ding om te kyk op as jy kyk na 'n tyd reeks data kom in volume. Hierdie is strategieë. Nou, ek kan net laat dit al gaan na die tafel en net laat die tafel te groei. Uiteindelik, ek gaan sien prestasie. Ek gaan om te begin na argief sommige van daardie data van die tafel af, wat nie. 

Kom ons baie beter ontwerp jou aansoek sodat jy kan op hierdie manier te werk. So dit is net 'n outomatiese in die aansoek-kode. Middernag elke aand dit rolle die tafel. Miskien wat ek nodig het, is 'n gly venster van 24 uur van data. Dan op 'n gereelde basis Ek is roep data van die tafel af. Ek is dit met 'n snoei Cron en ek sit dit op die ander tafels, alles wat jy nodig het. So as 'n roll werk, dit is 'n groot. Indien nie, snoei nie. Maar laat ons hou dat warm data weg van jou koue data. Dit sal red jy 'n klomp geld en jou tafels meer presteer. So die volgende ding wat ons sal praat oor is 'n produk katalogus. Produk katalogus is redelik algemeen gebruik geval. Dit is eintlik 'n baie algemene patroon dat ons sal sien in 'n verskeidenheid van dinge. Jy weet, Twitter vir Byvoorbeeld, 'n warm tweet. Almal se koms en gryp wat tweet. Produk katalogus, ek het 'n verkoop. Ek het 'n warm verkoop. Ek het 70.000 versoeke per wederkoms vir 'n produk beskrywing uit my produk katalogus. Ons sien dit op die kleinhandel werking nogal 'n bietjie. So hoe hanteer ons dit? Daar is geen manier om te gaan met dit. Al my gebruikers wil sien dieselfde stuk data. Hulle is kom in, gelyktydig. En hulle is almal versoeke vir dieselfde stuk data. Dit gee my dat warm sleutel, dat die groot rooi streep op my grafiek dat ons nie hou nie. En dit is wat die lyk. So oor my sleutel ruimte Ek kry gehamer in die verkoop items. Ek kry niks nêrens anders. 

Hoe kan ek hierdie probleem te verlig? Wel, ons dit verlig met kas. Kas, basies 'n sit jy in-geheue partisie in die voorkant van die databasis. Ons het daarin geslaag [Onhoorbaar] kas, hoe jy kan die opstel van jou eie kas, [onhoorbaar] kas [? d,?] wat jy wil. Sit dit in die voorkant van die databasis. En op die manier wat jy kan stoor data van dié warm sleutels in daardie kas ruimte en lees deur die kas. 

En dan die meeste van jou lees begin soek soos hierdie. Ek het al hierdie kas treffers hier en ek het niks aan die gang hier af omdat databasis sit agter die kas en die lui nooit deur. As ek die data in die verander databasis, ek het in die kas te werk. Ons kan iets gebruik soos stoom om dit te doen. En Ek sal verduidelik hoe dit werk. Alle reg, boodskappe. E-pos, ons almal gebruik e-pos. 

Dit is 'n baie goeie voorbeeld. Ons het 'n soort van boodskappe tafel. En ons het posbus en outbox. Dit is wat die SQL sou kyk graag dat posbus te bou. Ons soort van gebruik dieselfde soort strategie om GSI se gebruik GSI se vir my inbox en outbox my. So ek het rou boodskappe kom in my boodskappe tafel. En die eerste benadering tot hierdie mag wees, sê OK, geen probleem. Ek het rou boodskappe gekry. Boodskappe kom [onhoorbaar], boodskap ID, dit is 'n groot. Dit is my unieke hash. Ek gaan om te skep twee GSI se een vir my inbox, een vir my outbox. En die eerste ding wat ek sal doen is ek sal sê my hash sleutel is gaan na die ontvanger en Ek gaan om te reël op die datum. Dit is fantasties. Ek het my mooi uitsig hier. Maar daar is hier 'n bietjie kwessie. En jy loop in hierdie in relasionele databasisse sowel. Hulle het vertikaal skeiding. Jy wil jou groot data hou weg van jou min data. 

En die rede hoekom is omdat ek moet gaan lees die items na die eienskappe kry. En as my liggaam is almal hier, dan lees net 'n paar items As my liggaam lengte is gemiddeld 256 kilogrepe elk, die wiskunde kry redelik lelik. So sê Ek wil Dawid se posbus te lees. David se posbus het 50 items. Die gemiddelde grootte en is 256 kilogrepe. Hier is my bekering verhouding vir RCU se vier kilogrepe. 

OK, laat ons gaan met uiteindelik konsekwent lees. Ek is nog steeds eet 1600 RCU se net na Dawid se posbus te lees. Ouch. OK, nou, laat ons dink oor hoe die jeug werk. As ek in 'n e-pos app en Ek is op soek na my inbox, en ek kyk na die liggaam van elke boodskap, Nee, ek is op soek na die opsommings. Ek is op soek na net die headers. So laat bou 'n tafel struktuur wat lyk meer soos dit. 

So hier is die inligting dat my workflow nodig het. Dit is in my inbox GSI. Dit is die datum, die sender, die onderwerp, en dan die boodskap ID, wat dui terug na die tafel boodskappe waar ek die liggaam kan kry. Wel, hierdie sou wees rekord ID. Hulle sou wys terug na die item-ID's op die Dynamo DB tafel. Elke indeks altyd creates-- het altyd die item ID as deel of-- dat kom met die indeks. 

Alles reg. GEHOOR: Dit vertel dit waar dit gestoor word? Rick Houlihan: Ja, dit vertel exactly-- dit is presies wat dit doen. Dit sê hier is my re-rekord. En dit sal wys dit terug na my re-rekord. Presies. OK, so nou is my inbox is eintlik baie kleiner. En dit eintlik ondersteun die workflow van 'n e-pos artikels. So my inbox, ek klik. Ek gaan saam en ek op die boodskap, Dis toe dat ek nodig het om te gaan kry die liggaam, want ek gaan om gaan na 'n ander siening. So as jy dink oor MVC tipe raamwerk, model oog kontroleerder. 

Die model bevat die data wat in die behoeftes oog en die beheerder interaksie het. Toe ek die raam verander, wanneer Ek verander die perspektief, dit is OK om terug te gaan na die bediener en repopulate die model, want dit is wat die gebruiker verwag. Wanneer hulle verander sienings, dit is wanneer ons terug na die databasis kan gaan. So e-pos, klik. Ek is op soek na die liggaam. Ronde trip. Gaan kry die liggaam. 

Ek lees 'n baie minder data. Ek is maar net die lees van die liggame wat David moet toe hy hulle nodig het. En ek is nie brand in 1600 RCU se net sy posbus te wys. So nou that-- dit is die manier dat LSI of GSI-- Ek is jammer, GSI, sou uitwerk. Ons het ons hash op die ontvanger. Ons het die reeks sleutel op die datum. En ons het die geprojekteerde eienskappe het dat ons net nodig het om die siening te ondersteun. 

Ons draai dat vir die outbox. Hash op sender. En in wese, ons het die baie mooi, skoon uitsig. En dit is wat ons basically-- het hierdie mooi boodskappe tabel word mooi, want is versprei dit is hash slegs hashed boodskap ID. En ons het twee indekse wat roteer af van daardie tafel. Alle reg, sodat idee hier is nie hou die groot data en dié klein data saam. Partisie vertikaal, afskort die tafels. Moenie data nie lees jy nie hoef te. Alle reg, speel. Ons almal wil speletjies. Ten minste het ek graag speletjies dan. So 'n paar van die dinge dat ons hanteer wanneer ons dink oor die spel, reg? Gaming hierdie dae, veral mobiele speel, is al oor die denke. En ek gaan om hier 'n draai bietjie weg van DynamoDB. Ek gaan in te bring sommige van die bespreking rondom 'n paar van die ander AWS tegnologie. 

Maar die idee oor die spel is om te dink oor in terme van API's, APIs wat, algemeen, HTTP en into. Dit is hoe mobiele speletjies soort interaksie met hulle rug eindig. Hulle doen into plaas. Hulle kry data, en dit is al, algemeen in mooi into APIs. 

Dinge soos te kry vriende, kry die leader, ruil data, gebruiker-gegenereerde inhoud, stoot terug tot die stelsel, dit is soort dinge dat ons gaan om dit te doen. Binary bate data, hierdie data dalk nie sit in die databasis. Dit kan in 'n sit voorwerp winkel, reg? Maar die databasis gaan beland vertel die stelsel, vertel die aansoek waar om te gaan kry. En onvermydelik, multiplayer bedieners, agterkant infrastruktuur, en is ontwerp vir 'n hoë beskikbaarheid en scalability. So dit is die dinge wat ons almal wil hê in die spel infrastruktuur vandag. 

So laat ons neem 'n blik op wat dit lyk. Het jy 'n kern agterkant, baie eenvoudig. Ons het 'n stelsel het hier met verskeie beskikbaarheid sones. Ons het gepraat oor AZS as being-- dink van hulle as afsonderlike data sentrums. Meer as een data sentrum per AZ, maar dit is OK, dink net aan hulle as afsonderlike data sentrums wat geografies en skuld geïsoleer. 

Ons gaan 'n het paar EC2 gevalle. Ons gaan hê sommige agterkant bediener. Miskien as jy 'n nalatenskap argitektuur, ons is die gebruik van wat ons RDS noem, relasionele databasis dienste. Kan wees MSSQL, MySQL, of iets soos dit. Dit is 'n baie aansoeke manier is ontwerp vandag. 

Wel, ons kan wil om te gaan met Dit is wanneer ons die skaal uit. Ons sal voortgaan en sit die S3 emmer daar. En dat S3 emmer, in plaas daarvan om up die voorwerpe van ons servers-- ons kon doen. Jy het al jou binêre voorwerpe op jou bedieners en jy kan die bediener gebruik gevalle dat die data op te dien. Maar dit is redelik duur. 

Beter manier om dit te doen is gaan voort en sit die voorwerpe in 'n S3 emmer. S3 is 'n voorwerp repositories. Dit is spesifiek gebou vir dien tot hierdie tipe van dinge. En laat die kliënte versoek direk van die voorwerp emmers, laai die bedieners. So ons begin hier uit te skaal. 

Nou het ons gebruikers oor die hele wêreld. Ek het die gebruikers. Ek het nodig om inhoud plaaslik het geleë naby die gebruikers, reg? Ek het 'n S3 emmer geskep as my bron repository. En ek sal voor die wat saam met die CloudFront verspreiding. 

CloudFront is 'n CD en 'n inhoud aflewering netwerk. Eintlik is dit die data wat jy spesifiseer neem en caches dit alles oor die internet sodat gebruikers oral kan hê 'n baie vinnige reaksie wanneer hulle versoek die voorwerpe. 

Sodat jy 'n idee kry. Jy soort van gebruik te maak van al die aspekte van AWS hier te kry dit gedoen. En uiteindelik, ons gooi in 'n motor skalering groep. So ons AC2 gevalle van ons game servers, as hulle begin om te kry besiger en besiger en besiger, hulle sal net nog 'n draai Byvoorbeeld, spin 'n ander geval, spin n ander geval. So het die tegnologie AWS het, is dit laat jou die parameters spesifiseer rondom jou bedieners sal groei. Sodat jy kan n aantal bedieners daar op enige gegewe tyd. En as jou las gaan weg, sal hulle krimp, sal die aantal krimp. En as die las terug kom, dit sal groei terug uit elastiche. 

So dit lyk groot. Ons het 'n baie EC2 gevalle. Ons kan kas sit in voorkant van die databasisse Probeer en versnel die databasisse. Die volgende druk punt tipies mense sien is hulle skaal 'n spel met 'n relasionele databasis stelsel. Jeez, die databasis prestasie is verskriklik. Hoe weet ons dat verbeter? Kom ons probeer om kas in die voorkant van dit. 

Wel, kas nie werk nie so groot in die speletjies, reg? Vir speletjies, skryf is pynlik. Speletjies is baie skryf swaar. Kas nie werk nie wanneer jy skryf swaar omdat jy altyd het in die kas te werk. Jy werk die kas, dit is irrelevant word kas. Dit is eintlik net ekstra werk. 

So, waar ons hier gaan? Jy het 'n groot knelpunt het af daar in die databasis. En die plek om te gaan natuurlik is skeiding. Skeiding is nie maklik om te doen wanneer jy hantering van relasionele databasisse. Met relasionele databasisse, is jy verantwoordelik vir die bestuur, doeltreffend, die sleutel ruimte. Jy sê gebruikers tussen A en M gaan hier tussen N en Z daar gaan. En jy skakel oor die aansoek. So jy met hierdie partisie data bron. Jy het transaksionele beperkings wat nie mure strek. Jy het alle vorme van het messiness dat jy hantering af daar probeer om te gaan met skalering uit en die bou van 'n groter infrastruktuur. Dis net nie lekker. 

GEHOOR: So jy sê dat toenemende bron punte versnel die proses? Rick Houlihan: Toenemende? GEHOOR: Bron punte. Rick Houlihan: Bron punte? GEHOOR: Van die inligting, waar die inligting vandaan kom? Rick Houlihan: No. Wat ek sê, is die verhoging van die aantal partisies in die data store verbeter deurvoer. So wat hier gebeur is gebruikers kom in die EC2 byvoorbeeld hier, Wel, as ek 'n gebruiker Dit is 'n M, ek sal hier gaan. Van N na p, sal ek hier gaan. Vanaf P tot Z, sal ek hier gaan. 

GEHOOR: OK, diegene So dit is al gestoor in verskillende nodes? 

Rick Houlihan: Ja. Dink aan hierdie as verskillende silo's van data. So jy hoef te doen. As jy probeer om te doen hierdie, as jy probeer skaal op 'n relasionele platform, dit is wat jy doen. Jy neem data en jy sny dit af. En jy skeiding dit oor verskeie gevalle van die databasis. En jy bestuur alles wat by die toepassing vlak. Dit is geen pret. So, wat wil ons gaan? Ons wil gaan DynamoDB, ten volle beheer, NoSQL data stoor, voorsiening deurvoer. Ons gebruik sekondêre indekse. Dit is basies HTTP API en sluit dokument ondersteuning. Sodat jy nie hoef te bekommer oor enige van daardie skeiding. Ons doen dit alles vir jou. So nou, in plaas daarvan, jy net skryf om die tafel. As die tafel moet verdeel, wat gebeur agter die skerms. Jy heeltemal geïsoleer uit dat 'n ontwikkelaar. So laat ons praat oor sommige van die gebruik gevalle dat ons loop in in die spel, 'n gemeenskaplike spel scenario's, leader. So jy het die gebruikers kom, die BoardNames dat hulle op die tellings vir hierdie gebruiker. Ons kan hashing op die UserID, en dan het ons reeks op die spel. Sodat elke gebruiker wil sien al die spel wat hy gespeel en al sy hoogste telling oor al die spel. So dit is sy persoonlike leader. 

Nou wil ek om in te gaan en ek wil get-- so ek kry hierdie persoonlike puntelys. Wat ek wil doen, is gaan kry die hoogste telling in alle gebruikers. So hoe kan ek dit doen? Toe my rekord hashed op die UserID, het gewissel van die spel, Wel, ek is van plan om voort te gaan en te herstruktureer, skep 'n GSI, en ek gaan die data te herstruktureer. 

Nou gaan ek oor die hash BoardName, wat is die spel. En ek gaan wissel op die top telling. En nou het ek verskillende emmers geskep. Ek gebruik dieselfde tafel, dieselfde item data. Maar ek skep 'n emmer wat gee vir my 'n samevoeging van top telling deur spel. 

En ek kan daardie tafel navraag om daardie inligting te kry. So ek gestel dat navraag patroon tot word ondersteun deur 'n sekondêre indeks. Nou kan hulle gesorteer word deur BoardName en gesorteer volgens topscore, afhangende van. Sodat jy kan sien, dit is tipes van gebruik gevalle jy in die spel. Nog 'n goeie gebruik geval kry ons in die spel is toekennings en wie het die toekennings. En dit is 'n groot gebruik geval waar ons noem yl indekse. Yl indekse is die vermoë om te genereer 'n indeks wat nie noodwendig beteken bevat elke enkele item op die tafel. En hoekom nie? Omdat die eienskap wat die wese geïndekseer bestaan ​​nie op elke item. 

So in hierdie spesifieke gebruik geval, ek sê, jy weet wat, ek gaan skep 'n kenmerk genaamd Award. En ek gaan elke gebruiker te gee wat 'n toekenning wat toe te skryf. Gebruikers wat nie toekennings is gaan nie daardie kenmerk het. So wanneer ek die skep van die indeks, die enigste gebruikers wat gaan om te wys in die indeks is die mense wat eintlik toekennings gewen het. So dit is 'n goeie manier om in staat wees om om gefiltreer te skep wat indekse is baie, baie selektiewe wat nie het na die indeks die hele tafel. 

So ons laag op tyd om hier. Ek gaan om voort te gaan en oor te slaan uit en slaan hierdie scenario. Praat 'n bietjie about-- 

GEHOOR: Kan ek 'n vinnige vraag vra? Een daarvan is skryf swaar? Rick Houlihan: Wat is? GEHOOR: Skryf swaar. Rick Houlihan: Skryf swaar. Laat ek sien. 

GEHOOR: Of is dit nie iets wat jy kan net stem in 'n kwessie van sekondes? Rick Houlihan: Ons gaan deur die stem scenario. Dit is nie so sleg nie. Het jy ouens het 'n paar minute? OK. 

So sal ons praat oor stem. So reële tyd te stem, het ons vereistes om te stem. Vereistes is dat ons toelaat dat elke persoon om net een keer stem. Ons wil niemand in staat wees om om hul stem te verander. Ons wil real-time samevoeging en analytics vir demografie dat ons gaan om te wees toon aan gebruikers op die werf. 

Dink aan hierdie scenario. Ons werk baie van die werklikheid TV-programme waar hulle doen hierdie presiese tipe dinge. So jy kan dink van die scenario, ons het miljoene tienermeisies daar met hul selfone en stem, en stem, en stem vir wie hulle is vind die mees gewild te wees. So dit is 'n paar van die vereistes wat ons loop uit. 

En so het die eerste te neem in die oplossing van die probleem sou wees om 'n te bou baie eenvoudige toepassing. So ek het hierdie inligting. Ek het 'n paar kiesers daar buite. Hulle kom in, hulle druk op die stem app. Ek het 'n paar rou stemme tafel het Ek sal net stort die stemme in. Ek sal 'n paar totaal het stemme tabel sal my analytics en demografie te doen, en ons sal dit alles in daar te vestig. 

En dit is groot. Die lewe is goed. Die lewe se goeie totdat ons uitvind dat daar is altyd net een of twee mense wat gewild is in 'n verkiesing. Daar is net een of twee dinge dat mense regtig omgee. En as jy op stem skaal, almal van 'n skielike Ek is gaan word gehamer die hel uit twee kandidate, een of twee kandidate. 'N baie beperkte aantal items mense vind gewild te wees. 

Dit is nie 'n goeie ontwerp patroon. Dit is eintlik 'n baie slegte ontwerp patroon want dit skep presies wat ons gepraat oor wat warm sleutels was. Warm sleutels is iets wat ons nie hou nie. 

So hoe doen ons dit regmaak? En regtig, die manier om dit op te los, is deur die neem van die kandidaat emmers en vir elke kandidaat wat ons het, ons gaan 'n ewekansige waarde heg, iets wat ons weet, ewekansige waarde tussen een en 100, tussen 100 en 1000, of tussen een en 1000, egter baie ewekansige waardes wat jy wil voeg op die einde van daardie kandidaat. 

En wat het ek regtig dan gedoen? As ek met behulp van die kandidaat ID as die emmer om totaal stemme, as ek het bygevoeg 'n ewekansige nommer die einde van daardie, Ek het nou geskep 10 emmers, 'n honderd emmers, 'n duisend emmers dat ek saamgevoeg stemme oor. 

So ek het miljoene en miljoene, en miljoene rekords kom in vir hierdie kandidate, ek is nou versprei die stemme oor Kandidaat A_1 deur Kandidaat A_100, want elke keer 'n stem kom in, Ek genereer 'n ewekansige waarde tussen een en 100. Ek koppel dit op die einde van die kandidaat daardie persoon se stem vir. Ek is die storting dit in die emmer. 

Nou op die agterkant, ek weet dat ek 'n honderd emmers. So wanneer ek wil om voort te gaan en die geheel het die stemme, Ek lees van al die emmers. So ek gaan voort en voeg. En dan het ek nie die strooi versamel waar ek gaan uit en sê hey, jy weet wat, hierdie kandidaat sleutel ruimtes is oor 'n honderd emmers. Ek gaan om te versamel al die stemme van daardie honderd emmers. Ek gaan om te versamel hulle en ek gaan om te sê, Kandidaat A het nou totale aantal stemme van x. 

Nou beide die skryf navraag en die lees navraag is mooi versprei omdat ek oor skryf en ek lees oor honderde sleutels. Ek skryf nie en lees oor een van die belangrikste nou. So dit is 'n groot patroon. 

Dit is eintlik waarskynlik een van die belangrikste ontwerp patrone vir skaal in NoSQL. Jy sal hierdie soort sien ontwerp patroon in elke smaak. MongoDB, DynamoDB, is dit nie saak, ons almal het om dit te doen. Want as jy te doen met dié groot swerms, jy het om uit te vind 'n manier om versprei hulle uit oor emmers. So, dit is die manier waarop jy dit doen. Alle reg, so what jy nou doen is jy die handel af lees koste vir skryf scalability. Die koste van my lees is 'n bietjie meer kompleks en ek het om te gaan lees van 'n honderd emmers in plaas van een. Maar ek is in staat om te skryf. En my deurset, my skryf deurset is ongelooflik. So dit is gewoonlik 'n waardevolle tegniek vir skalering DynamoDB, of enige NoSQL databasis vir die saak. Sodat ons uitgepluis het hoe om dit te skaal. En ons het gedink hoe om skakel ons warm sleutels. En dit is fantasties. En ons het hierdie mooi stelsel. En dit is aan ons gegee baie korrekte stem want ons het rekord stem de-bedrieg. Dit is gebou in DynamoDB. Ons het gepraat oor voorwaardelike regte. 

Wanneer 'n kieser kom in, sit 'n insetsel op die tafel, hulle steek met hul kieser ID, as hulle probeer om 'n ander stemming te plaas, Ek doen 'n voorwaardelike skryf. Sê net skryf dit As dit nie bestaan ​​nie. So gou as ek sien dat daardie stem se druk op die tafel, niemand anders gaan wees in staat wees om hul stem in plaas. En dit is fantasties. En ons is die verhoog ons kandidaat tellers. En ons van ons doen demografie en alles wat. Maar wat gebeur as my aansoek omval? Nou het al van 'n skielike stemme kom in, en ek weet nie of hulle kry verwerk in my analytics en demografie meer. En toe die aansoek kom terug, hoe die hel moet ek weet wat stemme het verwerk en waar begin ek? 

So, dit is 'n werklike probleem wanneer jy begin om te kyk na hierdie tipe van scenario. En hoe los ons dit? Ons los dit met wat ons noem DynamoDB Streams. Strome is 'n tyd bestel en verdeel verandering log elke toegang na die tafel, elke skryf toegang tot die tafel. Enige data wat geskryf om die tabel toon op die stroom. 

Dit is basies 'n 24 uur ry. Items getref die stroom, hulle leef vir 24 uur. Hulle kan verskeie kere gelees word. Gewaarborg om gered te word slegs een keer na die spruit kon N aantal kere gelees word. So egter baie prosesse wat jy wil verteer wat data, kan jy dit verteer. Dit sal elke update verskyn. Elke skryf, sal net verskyn een keer op die stroom. Sodat jy nie hoef te bekommer oor die verwerking van dit twee keer van dieselfde proses. 

Dit is streng beveel per item. Wanneer ons tyd sê bestel en verdeel, jy sal sien per partisie op die stroom. Jy sal items, updates sien in orde is. Ons is nie die waarborg op die stroom wat jy gaan elke transaksie te kry in die volgorde oor items. 

So strome is idempotente. Het ons almal weet wat idempotente beteken? Idempotente beteken jy kan dit doen oor en oor en oor weer. Die gevolg gaan dieselfde wees. 

Strome is idempotente, maar hulle moet wees gespeel vanaf die beginpunt, waar jy kies om die einde, of hulle sal nie lei in dieselfde waardes. 

Dieselfde ding met MongoDB. MongoDB het 'n konstruk hulle noem die oplog. Dit is presies dieselfde konstruk. Baie NoSQL databasisse hierdie konstruk. Hulle gebruik dit om dinge te doen soos replisering, wat is presies wat ons doen met strome. GEHOOR: Miskien is 'n ketterse vraag, maar jy praat oor apps doen teen 'n so meer. Is gewaarborg om strome nooit moontlik gaan af? Rick Houlihan: Ja, strome is gewaarborg om nooit gaan af. Ons bestuur die infrastruktuur agter. strome outomaties ontplooi in hul motor skalering groep. Ons gaan deur 'n bietjie bietjie oor wat gebeur. 

Ek moet sê nie hulle is nie gewaarborg om nooit gaan af. Die elemente is gewaarborg om te verskyn in die stroom. En die stroom sal toeganklik wees. So, wat gaan af of kom terug up, dit gebeur onder. Dit covers-- dit is OK. Alle reg, sodat jy verskillende kry tipes siening van die skerm af. Die tipes siening dat belangrik om 'n is programmeerder tipies is, wat was dit? Ek kry die ou siening. Wanneer 'n update treffers die tafel, dit sal stoot die ou oog op die stroom so data kan argief, of verandering beheer, identifikasie verandering, verandering bestuur. 

Die nuwe beeld, wat dit nou is ná die werk, dit is 'n ander tipe van die oog wat jy kan kry. Jy kan kry beide die ou en nuwe beelde. Miskien wil ek hulle albei. Ek wil om te sien wat dit was nie. Ek wil om te sien wat dit verander na. 

Ek het 'n tipe nakoming van die proses wat loop. Dit moet seker maak dat En as hierdie dinge verander, dat hulle binne sekere perke of binne sekere parameters. 

En dan slegs miskien is ek nodig om te weet wat verander. Ek gee nie om wat item verander. Ek het nie nodig om te weet wat veranderde eienskappe. Ek het net nodig om te weet dat die items word geraak. So dit is die tipes van aansigte dat jy uit die stroom en jy kan interaksie met. 

Die program wat verorber die stroom, dit is soort van die wyse waarop hierdie werk. DynamoDB kliënt vra om stoot data na die tafels. Strome ontplooi op wat ons skerwe noem. Skerwe afgeskaal onafhanklik van die tafel. Hulle het nie heeltemal in lyn om die mure van jou tafel. En die rede hoekom is omdat hulle line-up om die kapasiteit, die huidige kapasiteit van die tafel. 

Hulle sit in hul eie motor skalering groep en hulle het begin om te draai, afhangende hoeveel skryf kom in, hoeveel reads-- regtig dis skryf. Daar is geen reads-- maar hoe baie skryf kom in. 

En dan op die rug einde, ons het wat ons noem 'n KCL, of Kinesis kliënt biblioteek. Kinesis is 'n stroom data verwerking tegnologie van Amazon. En strome is gebou op dit. 

So gebruik jy 'n KCL enabled aansoek om die stroom te lees. Die Kinesis kliënt Biblioteek eintlik bestuur die werkers vir jou. En dit nie ook 'n paar interessante dinge. Dit sal 'n paar tafels skep up in jou DynamoDB table space waartoe items op te spoor verwerk. So op hierdie manier as dit val terug, as dit val oor en kom en kry staan ​​terug, kan dit bepaal waar was dit in die verwerking van die stroom. 

Dit is baie belangrik wanneer jy praat replikasie. Ek moet weet wat data is verwerk en wat data het nog verwerk moet word. So die KCL biblioteek vir strome sal gee jou 'n baie van daardie funksie. Dit sorg vir al die huishouding. Dit staan ​​op 'n werker vir elke segment. Dit skep 'n administratiewe tafel vir elke segment, vir elke werker. En as dié werkers vuur hulle handhaaf die tafels sodat jy weet hierdie rekord gelees en verwerk. En dan so as die proses sterf en kom terug online, dit kan hervat reg waar dit opgestyg het. 

Sodat ons dit gebruik vir kruis-streek replikasie. Baie kliënte het die behoefte om data of dele van hul data tafels beweeg om na die verskillende streke. Daar is nege streke oor die hele wêreld. So is daar 'n need-- ek dalk kan gebruikers in Asië, gebruikers in die ooskus van die Verenigde State van Amerika. Hulle het verskillende data wat moet plaaslik versprei word. En miskien 'n gebruiker vlieg van Asië na die Verenigde State, en ek wil om te herhaal sy data met hom. So wanneer hy kry uit die vliegtuig, het hy 'n goeie ervaring met behulp van sy foon. 

Jy kan die kruis-streek gebruik replikasie biblioteek om dit te doen. Basies het ons verskaf twee tegnologie. Een is 'n konsole aansoek wat jy kan staan ​​op jou eie EC2 byvoorbeeld. Dit loop pure replikasie. En dan het ons u die biblioteek. Die biblioteek wat jy kan gebruik om te bou jou eie aansoek as jy wil mal dinge te doen met daardie data-- filter, herhaal net deel van dit, draai die data, beweeg dit in 'n ander tafel, so aan en so voort. So dit is soort van wat dit lyk. 

DynamoDB strome kan verwerk deur wat ons Lambda noem. Ons genoem 'n bietjie oor gebeurtenis gedryf aansoek argitekture. Lambda is 'n belangrike komponent van daardie. Lambda is kode wat vure op aanvraag in reaksie op 'n spesifieke gebeurtenis. Een van die gebeure kan 'n rekord wat op die stroom. As 'n rekord verskyn op die stroom, ons sal hierdie Java funksie noem. Wel, dit is JavaScript en Lambda ondersteun Node.js, Java, Python, en sal binnekort ondersteun ander tale. En voldoende om te sê, dit is suiwer-kode. skryf In Java, jy 'n klas te definieer. Jy druk die JAR tot in Lambda. En dan spesifiseer watter klas wat jy om te skakel in reaksie op wat geval. En dan is die Lambda infrastruktuur agter wat daardie kode hardloop. 

Dit kode kan verwerk rekords van die stroom. Dit kan enigiets wat dit wil doen met dit. In hierdie spesifieke voorbeeld, al wat ons is eintlik doen is teken die eienskappe. Maar dit is net die kode. Kode kan niks doen nie, reg? 

So kan jy die data te draai. Jy kan 'n afgeleide oog te skep. As dit is 'n dokument struktuur, kan jy die struktuur plat. Jy kan alternatiewe indekse skep. Alle vorme van dinge wat jy kan doen met die DynamoDB Streams. 

En regtig, dit is wat die lyk. So jy diegene updates kom in. Hulle kom uit die string. Hulle is gelees deur die Lambda funksie. Hulle is die draai van die data en stoot dit in afgeleide tafels, kennis te stel eksterne stelsels van verandering, en stoot data in ElastiCache. 

Ons het gepraat oor hoe om die kas te sit in die voorkant van die databasis vir daardie verkope scenario. Wel, wat gebeur as ek werk die item beskrywing? Wel, as ek 'n Lambda funksie wat uitgevoer word op die tafel, as ek werk die item beskrywing, sal dit haal die rekord van die stroom, en dit sal die ElastiCache werk byvoorbeeld met die nuwe data. So dit is 'n baie wat ons doen met Lambda. Dit is die gom kode, aansluiting. En dit is eintlik gee die vermoë om te loods en baie komplekse toepassings hardloop sonder 'n toegewyde bediener infrastruktuur, wat is regtig cool. 

So laat ons gaan terug na ons real-time stem argitektuur. Dit is 'n nuwe en verbeterde met ons strome en KCL enabled aansoek. Dieselfde as voorheen, kan ons hanteer enige skaal van die verkiesing. Ons hou van hierdie. Ons doen uit strooi versamel oor verskeie emmers. Ons het optimisties locking aangaan. Ons kan nie ons kiesers te hou van die verandering van hul stemme. Hulle kan net een keer stem. Dit is fantasties. Real-time skuld verdraagsaamheid, skaalbare samevoeging nou. As die ding val oor dit weet waar om te begin self wanneer dit kom terug omdat Ons gebruik die KCL app. En dan kan ons ook dat KCL aansoek om data uit te druk om rooi verschuiving vir ander app analytics, of gebruik Die elastiese MapReduce om te hardloop real-time streaming swerms af van daardie data. 

So dit is dinge wat ons het nie gepraat oor veel. Maar hulle is addisionele tegnologie wat kom om te dra wanneer jy op soek is by hierdie tipe van scenario's. 

Alle reg, sodat dit is oor analytics met DynamoDB Streams. Jy kan de-bedrieg samel data, doen allerhande mooi dinge, totaal data in geheue, skep die afgeleide tafels. Dit is 'n groot gebruik geval dat baie van die kliënte is betrokke by, neem die geneste eienskappe van die into dokumente en die skep van bykomende indekse. 

Ons is aan die einde. Dankie vir julle geduld met my. So laat ons praat oor verwysing argitektuur. DynamoDB sit in die middel van so baie van die AWS infrastruktuur. Basies kan jy dit haak tot enigiets wat jy wil. Aansoeke gebou met behulp van Dynamo sluit Lambda, ElastiCache, CloudSearch, stoot die data uit in Elastiese MapReduce, invoer uitvoer van DynamoDB in S3, alle vorme van werkstromen. Maar waarskynlik die beste ding om te praat oor, en dit is wat regtig interessant is, is wanneer ons praat oor gebeurtenis gedrewe programme. 

Dit is 'n voorbeeld van 'n interne projek dat ons waar ons is eintlik publishing opname resultate te samel. So in 'n e-pos skakel wat ons stuur, sal daar 'n bietjie skakel gesê kliek hier om te reageer op die opname. En wanneer 'n persoon druk wat verwys, wat gebeur is hulle trek 'n veilige HTML opname vorm van S3. Daar is geen bediener. Dit is net 'n S3 voorwerp. 

Dit vorm kom, laai in die leser. Dit het Backbone. Dit het komplekse JavaScript dat dit loop. So dit is 'n baie ryk aansoek hardloop in die leser van die kliënt. Hulle weet nie dat hulle nie interaksie met 'n agterkant bediener. Op hierdie punt, dit is alles leser. 

Hulle publiseer die resultate wat ons die Amazon API Gateway noem. API Gateway is bloot 'n web API wat jy kan definieer en haak om alles wat jy wil. In hierdie spesifieke geval, ons is verslaaf aan 'n Lambda funksie. 

So my POST werking is gebeur met geen bediener. Basies dat API Gateway sit daar. Dit kos my niks totdat mense begin plaas om dit, reg? Die Lambda funksie sit net daar. En dit kos my niks te gebruik totdat mense begin slaan het. Sodat jy kan sien, as die volume toeneem, dit is wanneer die koste kom. Ek is nie 'n bediener 24/07. 

So ek trek die vorm af uit die emmer, en ek plaas deur die API Gateway na die Lambda funksie. En dan is die Lambda funksie sê, jy weet wat, het ek 'n paar PIIs het, 'n paar persoonlike inligting in hierdie antwoorde. Ek het kommentaar kom van die gebruikers. Ek het e-pos adresse. Ek het gebruikers. 

Laat my verdeel dit af. Ek gaan 'n paar te genereer metadata uit hierdie rekord. En ek gaan na die druk metadata in DynamoDB. En ek kon al die data te enkripteer en druk dit in DynamoDB as ek wil. Maar dit is makliker vir my, in hierdie gebruik geval, om voort te gaan 'n sê, Ek gaan die rou data te stoot in 'n geïnkripteer S3 emmer. So ek gebruik gebou in S3 bediener kant enkripsie en Sleutel Management Amazon se Service so dat ek 'n sleutel wat kan draai op 'n gereelde interval, en ek kan dit PII data te beskerm as deel van hierdie hele workflow. 

So, wat het ek gedoen? Ek het net 'n hele ontplooi aansoek, en ek het geen bediener. So is wat gebeurtenis gedrewe aansoek argitektuur doen vir jou. 

Nou as jy dink oor die gebruik geval vir this-- ons het ander kliënte ek praat om oor hierdie presiese argitektuur wat hardloop fenomenaal groot veldtogte, wat is op soek na hierdie en gaan, oh my. Want nou het, kan hulle stoot dit basies daar buite, laat die veldtog net sit daar tot dit lanseer, en nie 'n vyeboom bekommer oor watter soort infrastruktuur gaan daar wees om dit te ondersteun. En dan so gou as die veldtog gedoen word, dit is soos die infrastruktuur net onmiddellik gaan weg want daar is regtig is geen infrastruktuur. Dis net-kode wat sit op Lambda. Dis net data wat sit in DynamoDB. Dit is 'n ongelooflike manier om programme op te bou. 

GEHOOR: So is dit meer efemere as wat dit sou wees As dit is gestoor op 'n werklike bediener? 

Rick Houlihan: Absoluut. Want dit bediener byvoorbeeld sou 'n 24/7 te wees. Dit het tot die beskikbare wees vir iemand om te reageer op. Wel raai wat? S3 is beskikbaar 24/7. S3 reageer altyd. En S3 is baie, baie goed om te dien op voorwerpe. Diegene voorwerpe kan wees HTML-lêers, of JavaScript-lêers, of wat jy wil. Jy kan 'n baie ryk web programme te hardloop uit S3 emmers, en mense doen. 

En so dit is die idee hier is om weg van die pad te kry ons gebruik om te dink oor dit. Ons almal gebruik om te dink in terme van bedieners en gashere. Dit gaan nie oor wat nie. Dit gaan oor die infrastruktuur-kode. Ontplooi die kode om die wolk en laat die wolk loop dit vir jou. En dit is wat AWS probeer om te doen. 

GEHOOR: So jou goue boks in die middel van die API Gateway is nie bediener-agtige, maar in plaas daarvan is just-- 

Rick Houlihan: Jy kan dink dit as bediener gevel. Al wat dit is, is dit sal 'n HTTP neem versoek en kaart na 'n ander proses. Dit is al wat dit doen nie. En in hierdie geval, ons kartering dat dit 'n Lambda funksie. Alle reg, so dit is al wat ek het. Baie dankie. Ek waardeer dit. Ek weet ons wil 'n bietjie oor die tyd. En hopelik het julle ouens 'n bietjie van inligting dat jy vandag kan wegneem. En ek is jammer as ek gaan oor 'n paar van julle hoofde, maar daar is 'n goeie klomp fundamentele kennis fundamentele wat ek dink is baie waardevol vir jou. So dankie vir die feit dat my. [Applous] GEHOOR: [onhoorbaar] is wanneer jy sê jy het om te gaan deur middel van die ding van die begin tot die einde om die regte waardes te kry of dieselfde waardes, hoe sou die waardes verander as [onhoorbaar]. 

Rick Houlihan: O, idempotente? Hoe sou die waardes verander? Wel, want as ek nie hardloop dit al die pad tot die einde, dan weet ek nie wat verander gemaak in die laaste myl. Dit gaan nie om die wees dieselfde data as wat ek gesien het. GEHOOR: O, so jy net het nie die hele insette gekry. Rick Houlihan: Right. Jy het om te gaan van die begin aan die einde, en dan is dit gaan om 'n konsekwente staat. Koel. 

GEHOOR: So jy ons gewys DynamoDB kan dokument of die sleutel waarde nie. En ons het 'n baie tyd op die sleutel waarde met 'n hash en die maniere om dit te draai om. Wanneer jy kyk na die tafels, is dat vertrek agter die dokument benadering? 

Rick Houlihan: Ek sou nie sê laat dit agter. 

GEHOOR: Hulle was geskei van the-- 

Rick Houlihan: Met die dokument benadering, die tipe dokument DynamoDB is dink net as 'n ander kenmerk. Dit is 'n eienskap wat bevat 'n hiërargiese struktuur data. En dan in die navrae, kan jy die eienskappe te gebruik van daardie voorwerpe met Object notasie. So ek kan filter op 'n sub- eiendom van die into dokument. GEHOOR: So enige tyd wat ek doen 'n dokument benadering, Ek kan soort van kom by die tabular-- GEHOOR: Absoluut. GEHOOR: --indexes en dinge wat jy net gepraat oor. Rick Houlihan: Ja, die indekse en alles wat, wanneer jy wil die indeks die eienskappe van die into die manier waarop ons wil hê om dit te doen, is as 'n into voorwerp of 'n dokument voeg in Dynamo, sou jy strome te gebruik. Strome sal die insette te lees. Jy wil kry dat into beswaar en jy wil sê OK, wat is die eiendom wil ek indeks? 

Jy skep 'n afgeleide tafel. Nou dit is die manier waarop dit nou werk. Ons vra nie dat jy toelaat dat indeks direk daardie eiendomme. 

GEHOOR: Tabularizing jou dokumente. 

Rick Houlihan: Presies, plat te slaan dit tabularizing dit, presies. Dit is wat jy doen met dit. 

GEHOOR: Dankie. 

Rick Houlihan: Yep, absoluut, dankie. GEHOOR: So dit is soort van Mongo vergader Redis classifers. 

Rick Houlihan: Ja, dit is 'n baie soos dit. Dit is 'n goeie beskrywing vir dit. Koel.