[Musik spiller] RICK Houlihan: Okay. Hej allesammen. Mit navn er Rick Houlihan. Jeg er en højtstående hovedstol løsninger arkitekt hos AWS. Jeg fokuserer på NoSQL og DynamoDB teknologier. Jeg er her i dag for at tale med dig en lille smule om dem. 

Min baggrund er primært i datalag. Jeg tilbragt halvdelen min udvikling karriere skriver database, dataadgang, løsninger til forskellige anvendelser. Jeg har været i Cloud virtualisering i omkring 20 år. Så før Cloud var Cloud, vi plejede at kalde det utility computing. Og ideen blev, det er ligesom PG & E, du betaler for det, du bruger. I dag kalder vi det skyen. 

Men i årenes løb, har jeg arbejdet for et par selskaber du har sikkert aldrig hørt om. Men jeg har samlet en liste over teknisk resultater, jeg tror, ​​du ville sige. Jeg har otte patenter i Cloud-systemer virtualisering, mikroprocessor-design, komplekse begivenhedsbehandlingstabellen, og andre områder. 

Så disse dage, fokuserer jeg mest på NoSQL teknologier og den næste generation database. Og det er generelt, hvad jeg har tænkt mig at være her taler til dig om. Så hvad du kan forvente fra denne session, vi vil gå igennem en kort historie databehandling. Det er altid nyttigt at forstå, hvor vi kom fra og hvorfor vi er, hvor vi er. Og vi vil tale lidt lidt om NoSQL teknologi fra et grundlæggende synspunkt. 

Vi vil komme ind i nogle af de DynamoDB interne. DynamoDB er AWS er ​​ingen smag. Det er en fuldt administreret og hostet NoSQL løsning. Og vi vil snakke lidt om bord struktur, API'er, data typer, indekser, og nogle af de interne af denne DynamoDB teknologi. Vi vil komme ind i nogle af designet mønstre og bedste praksis. Vi taler om, hvordan du bruge denne teknologi for nogle af nutidens programmer. Og så vil vi snakke lidt om udviklingen eller fremkomsten af et nyt paradigme i programmering kaldet event-driven programmer og hvordan DynamoDB spiller i, samt. Og vi vil efterlade dig en lille smule af en reference arkitektur diskussion så vi kan tale om nogle af de måder, du kan bruge DynamoDB. 

Så først off-- det er et spørgsmål Jeg hører en masse er, hvad er en database. En masse mennesker tror, ​​at de vide, hvad en database er. Hvis du Google, vil du se dette. Det er et et struktureret sæt data afholdt i en computer, især en, der er tilgængelig på forskellige måder. Jeg formoder, det er en god definition af en moderne database. Men jeg kan ikke lide det, fordi det indebærer et par ting. Det indebærer struktur. Og det indebærer, at det er på en computer. Og databaser ikke gjorde altid eksistere på computere. Databaser faktisk eksisterede på mange måder. 

Så en bedre definition af en database er noget som dette. En database er en organiseret mekanisme til lagring, styring, og hentning af information. Dette er fra About.com. Så jeg kan godt lide det, fordi det virkelig taler omkring en database, være et depot, en samling af information, ikke nødvendigvis noget, der sidder på en computer. Og gennem hele historien, vi har ikke altid haft computere. 

Nu, hvis jeg spørger gennemsnittet udvikler i dag, hvad der er en database, det er det svar, jeg får. Et eller andet sted jeg kan holde ting. Højre? Og det er sandt. Men det er uheldigt. Da databasen er virkelig grundlaget for den moderne app. Det er fundamentet af hver ansøgning. Og hvordan du bygger det database, hvordan du strukturere at data kommer til at diktere, hvordan det udfører programmet som du skalerer. 

Så en masse af mit job i dag beskæftiger sig med, hvad sker, når udviklere tage denne tilgang og beskæftiger sig med eftervirkningerne af en ansøgning, der er nu skalering ud over den oprindelige hensigt og lider af dårligt design. Så forhåbentlig når du gå væk i dag, vil du har et par værktøjer dit bælte, der vil holde dig fra at gøre de samme fejl. Okay. Så lad os tale om en lille smule af tidslinjen af ​​database teknologi. Jeg tror, ​​jeg læste en artikel ikke så længe siden og det sagde noget på lines-- det er en meget poetisk erklæring. Det sagde historien af databehandling er fuld af høje vandmærker af data overflod. OKAY. Nu, jeg tror der er slags sandt. Men jeg faktisk se på, er som historie er faktisk fyldt med high watermark af data pres. Da datahastigheden for indtagelse aldrig går ned. Det kun går op. 

Og innovation opstår, når vi ser data tryk, som er den mængde data, der er nu kommer ind i systemet. Og det kan ikke behandles effektivt enten i tid eller i omkostninger. Og det er, når vi begynder at se på data tryk. 

Så når vi ser på den første database, er dette er den, der var mellem vores ører. Vi er alle født med det. Det er en dejlig database. Det har en høj tilgængelighed. Det er altid på. Du kan altid få det. 

Men det er enkelt bruger. Jeg kan ikke dele mine tanker med dig. Du kan ikke få mine tanker når du vil have dem. Og deres abilitiy er ikke så god. Vi glemmer ting. Hvert nu og da, en af ​​os blade og går videre til en anden eksistens og vi mister alt der var i denne database. Så det er ikke så godt. 

Og dette fungerede godt over tid da vi var tilbage i dag når alle vi virkelig behov for at vide, er hvor skal vi gå på i morgen eller hvor vi samler den bedste mad. Men da vi begyndte at vokse som en civilisation og regeringen begyndte til at komme i stand, og virksomheder begyndte at udvikle sig, vi begyndte at indse, vi brug for lidt mere end hvad vi kunne sætte i vores hoved. Okay? 

Vi havde brug for systemer af rekord. Vi havde brug for steder for at kunne gemme data. Så vi begyndte at skrive dokumenter, skabe biblioteker og arkiver. Vi begyndte at udvikle et systemet en hovedbog regnskab. Og at systemet med hovedbog optælling kørte verden i mange århundreder, og måske endda årtusinder som vi slags voksede til det punkt, hvor at data belastning overgået evne til disse systemer at kunne rumme det. 

Og dette rent faktisk skete i 1880'erne. Højre? I 1880 US Census. Dette er virkelig, hvor drejningen peger moderne databehandling. Dette er det punkt, hvor mængden af ​​data der blev indsamlet af Amerikanske regering fik til det punkt hvor det tog otte år at behandle. 

Nu otte years-- som du ved, folketællingen kører hver 10 years-- så det er temmelig indlysende, at efter tid vi fik 1890 folketællingen, mængden af ​​data, ville blive behandlet af regeringen var kommer til at overstige de 10 år, at det ville tage til lanceret den nye folketælling. Dette var et problem. 

Så en fyr ved navn Herman Hollerith kom sammen og han opfandt enhed rekord dorn kort, Punch kortlæser, hulkort tabulator, og sammenstilling af mekanismerne for denne teknologi. Og det selskab, som han dannede i tidspunkt sammen med et par andre, faktisk blev en af ​​grundpillerne i et lille virksomhed, vi kender i dag kaldet IBM. 

Så IBM oprindeligt var databasen virksomhed. Og det er virkelig, hvad de gjorde. De gjorde databehandling. 

Som så spredning af Punch kort, en genial mekanismer at være i stand til at udnytte, at teknologi til at polle sorterede resultatsæt. Du kan se på dette billede der har vi en little-- det er lidt small-- men du kan se en meget sindrig mekanisk mekanisme hvor vi har en punch kort. Og nogens tage en lille skruetrækker og stikning gennem slots og løfte det op at få det match, der sorteret resultater indstillet. 

Dette er en sammenlægning. Vi gør det hele tiden dag i computeren, hvor du gør det i databasen. Vi plejede at gøre det manuelt, ikke? Folk sætte disse ting sammen. Og det var spredning af disse hulkort i, hvad vi kaldte data trommer og data ruller, papir tape. 

Databehandlingen industrien tog en lektion fra afspilleren klaverer. Spiller klaverer tilbage på den århundredeskiftet bruges til at bruge papirruller med slidser på at fortælle det, som nøgler til at spille. Så teknologien blev tilpasset i sidste ende til at lagre digitale data, fordi de kunne sætte, at data på disse papir tape ruller. 

Nu, som et resultat, data var actually-- hvordan du få adgang til disse data var direkte afhængig af, hvordan du har gemt det. Så hvis jeg sætter data på et bånd, Jeg havde adgang til data lineært. Jeg var nødt til at rulle det hele tape til at få adgang til alle data. Hvis jeg sætter data i slag kort, kunne jeg få adgang til den i lidt mere tilfældigt mode, måske ikke så hurtigt. 

Men der var begrænsninger i, hvordan vi adgang til data baseret på hvordan blev gemt. Og så dette var et problem gå i 50'erne. Igen, kan vi begynde at se, at når vi udvikle nye teknologier til at behandle de data, højre, det åbner døren for nye løsninger, for nye programmer, nye applikationer til disse data. Og virkelig, regeringsførelse kan have været grunden Derfor har vi udviklet nogle af disse systemer. Men virksomhed blev hurtigt føreren bag udviklingen af den moderne database og den moderne filsystem. 

Så den næste ting, kom op var i 50'erne var filsystemet og udvikling af random access opbevaring. Det var smukt. Nu er alle pludselig, kan vi sætte vores filer hvor som helst på disse harddiske og vi kan få adgang til disse data tilfældigt. Vi kan parse, at oplysninger ud af filer. Og vi løst alle verdens problemer med databehandling. 

Og der varede omkring 20 eller 30 år indtil udviklingen af relationsdatabasen, der er, når verden besluttede vi nu nødt til at have et arkiv, der besejrer den planløse vækst af data på tværs af filen systemer, som vi har bygget. Højre? For meget data fordelt på alt for mange steder, de-duplikering af data, og omkostningerne ved opbevaring var enorm. 

I 70'erne, den dyreste ressource at en computer havde var lageret. Processoren var ses som en fast omkostning. Når jeg køber boksen, CPU'en gør noget arbejde. Det kommer til at være spinning, om det er faktisk arbejder eller ej. Det er virkelig en sunk cost. 

Men hvad koster mig som en forretning er opbevaring. Hvis jeg nødt til at købe flere diske næste måned, det er en reel omkostning, som jeg betale. Og at opbevaring er dyrt. 

Nu skal vi hurtigt frem 40 år og vi har et andet problem. Den compute er nu den dyreste ressource. Lagringen er billige. Jeg mener, at vi kan gå et vilkårligt sted på sky og vi kan finde billige opbevaring. Men hvad jeg ikke kan finde er billig beregne. 

Så udviklingen i dagens teknologi, database teknologi, er virkelig fokuseret omkring distribuerede databaser som ikke lider af den samme type skala begrænsninger af relationelle databaser. Vi taler lidt om hvad der rent faktisk betyder. 

Men en af ​​grundene og driveren bag denne-- vi talte om det pres data. Data trykket er noget der driver innovationen. Og hvis man ser på løbet de sidste fem år, dette er et diagram over, hvad disse data belastningen over den generelle virksomhed ser ud i de sidste fem år. 

Og den generelle tommelfingerregel disse days-- hvis du går Google-- er 90% af de data, vi gemmer i dag, og det var dannes inden for de seneste to år. OKAY. Nu, dette ikke er en tendens, der er nyt. Det er en tendens, der har været gå ud til 100 år. Lige siden Herman Hollerith udviklet hulkort, vi har været bygning datalagre og indsamle data på fænomenale priser. 

Så i løbet af de sidste 100 år, vi har set denne tendens. Det kommer ikke til at ændre sig. Fremadrettet vil vi se dette, hvis ikke en fremskyndet tendens. Og du kan se, hvad det ser ud. 

Hvis en virksomhed i 2010 havde en terabyte af data under forvaltning, dag, at betyder, at de er styring 6.5 petabyte data. Det er 6.500 gange flere data. Og jeg ved dette. Jeg arbejder med disse virksomheder hver dag. For fem år siden, jeg ville tale med virksomheder hvem ville tale med mig om, hvad en smerte det er at styre terabytes af data. Og de ville tale til mig om, hvordan vi ser at dette er sandsynligvis vil at være en eller to petabyte inden for et par år. 

De samme virksomheder dag jeg møde med, og de taler til mig om Problemet er der have styring tiere, 20 petabyte data. Så eksplosionen af data i branchen kører den enorme behov for bedre løsninger. Og den relationelle database er bare ikke leve op til efterspørgslen. 

Og så der er en lineær korrelation mellem data pres og teknisk innovation. Historien har vist os dette, at over tid, når mængden af ​​data der skal behandles overstiger kapaciteten af ​​systemet at behandle det i en rimelig frist eller til en rimelig pris, derefter nye teknologier er opfundet for at løse disse problemer. Disse nye teknologier, til gengæld åbner døren til et andet sæt problemer, som er at indsamle endnu flere data. 

Nu er vi ikke til at stoppe dette. Højre? Vi kommer ikke til at stoppe dette. Hvorfor? Fordi du ikke kan vide alt der er at vide i universet. Og så længe vi har været i live, gennem hele menneskets historie, vi har altid kørt til at vide mere. 

Så det ser ud som hver tomme vi bevæger i retning af videnskabelige opdagelser, vi multiplicere mængden af ​​data at vi er nødt til at behandle eksponentielt som afdækker vi mere og mere og mere om de indre funktioner i livet, om, hvordan universet fungerer, om kørsel videnskabelig opdagelse, og opfindelsen, vi gør i dag. Mængden af ​​data bare løbende stiger. Så at kunne beskæftige sig med dette problem er enorm. 

Så en af ​​de ting, vi ser som hvorfor NoSQL? Hvordan NoSQL løse dette problem? Nå, relationsdatabaser, Structured Query Language, SQL-- det er virkelig en konstruktion af relationel database-- disse ting er optimeret til opbevaring. 

Tilbage i 70'erne, igen, disk er dyrt. Tilførsler udøvelse af lagerplads i virksomheden er uendelig. Jeg ved. Jeg boede det. Jeg skrev storage drivere til en Enterprised superserver selskab tilbage i 90'erne. Og bundlinjen er reoler anden storagesystem var bare noget, der skete hver dag i virksomheden. Og desværre også. Højere lagertæthed, efterspørgslen for høj lagringstæthed, og for mere effektiv opbevaring devices-- det har aldrig stoppet. 

Og NoSQL er en stor teknologi fordi det normaliserer dataene. Det de-dubletter dataene. Det sætter dataene i en struktur, er agnostiker til hver adgang mønster. Flere programmer kan skud afsted SQL-database, køre ad hoc-forespørgsler, og få data i den form, de brug for at behandle deres arbejdsbyrder. Det lyder fantastisk. Men bundlinjen er med enhver systemet, hvis det er agnostiker på alt, det er optimeret for ingenting. OKAY? 

Og det er, hvad vi får med relationsdatabasen. Det er optimeret til opbevaring. Det er normaliseret. Det er relationel. Det understøtter de ad hoc-forespørgsler. Og det, og det skalerer lodret. 

Hvis jeg har brug for at få en større SQL-database eller en mere kraftfuld SQL database, Jeg går købe en større stykke jern. OKAY? Jeg har arbejdet med en masse kunder der har været igennem større opgraderinger kun i deres SQL infrastruktur at finde ud af seks måneder senere, de er at ramme muren igen. Og svaret fra Oracle eller MSSQL eller nogen anden, er at få en større kasse. Nå før eller senere, kan du ikke købe en større boks, og det er reelt problem. Vi er nødt til rent faktisk at ændre tingene. Så hvor gør dette arbejde? Det fungerer godt for offline analytics, OLAP-type arbejdsbyrder. Og det er virkelig, hvor SQL tilhører. Nu er det bruges i dag i mange online transaktionsbeslutning behandling-typen anvendelser. Og det fungerer fint på en vis grad af udnyttelse, men det bare ikke skalere den måde, NoSQL gør. Og vi vil tale lidt lidt om, hvorfor det er. 

Nu NoSQL, på den anden side, er mere optimeret til beregne. OKAY? Det er ikke agnostiker til adgangsmønstret. Er det, vi kalder de-normaliseret struktur eller en hierarkisk struktur. Dataene i en relationel database er sammenføjet fra flere tabeller at producere den opfattelse, at du har brug for. Dataene i en NoSQL database lagres i et dokument, indeholder den hierarkiske struktur. Alle de data, der normalt ville være sammenføjet til at producere denne opfattelse er gemt i et enkelt dokument. Og vi vil snakke lidt om hvordan det fungerer i et par diagrammer. 

Men ideen her er, at du gemmer dine data, da disse instantieres udsigt. OKAY? Du skalere horisontalt. Højre? Hvis jeg har brug for at øge størrelsen af ​​min NoSQL klynge, Jeg har ikke brug for at få en større kasse. Jeg får en anden kasse. Og jeg klynge dem sammen, og jeg kan shard disse data. Vi taler lidt om hvad sharding er, at være i stand til at skalere denne database på tværs af flere fysiske enheder og fjern barriere, kræver, at jeg skalere lodret. 

Så det er virkelig bygget til online transaktionsbehandling og skala. Der er en stor forskel her mellem rapportering, right? Rapportering, jeg ikke kender spørgsmål, jeg har tænkt mig at spørge. Højre? Reporting-- hvis nogen fra min marketingafdeling ønsker at bare--, hvor mange af mine kunder har denne egenskab, der især købt på denne dag-- jeg ikke kender hvad forespørge de kommer til at spørge. Så jeg har brug for at være agnostiker. 

Nu, i et online transaktionsbeslutning ansøgning, Jeg ved, hvad spørgsmål jeg spørger. Jeg byggede ansøgningen om en meget specifik arbejdsgang. OKAY? Så hvis jeg optimere data lagre til støtte for denne arbejdsproces, det vil være hurtigere. Og det er derfor NoSQL kan virkelig fremskynde leveringen af de typer af ydelser. Okay. 

Så vi kommer til at komme ind en lille smule af teori her. Og nogle af jer, dine øjne kan rulle tilbage en lille smule. Men jeg vil prøve at holde det så højt niveau som jeg kan. Så hvis du er i projektet ledelse, er der en konstruktion kaldet trekant af begrænsninger. OKAY. Trekanten af ​​begrænsninger som diktater du kan ikke have alt hele tiden. Kan ikke have din pie og spise det også. Så i projektledelse, at trekant begrænsninger er du kan få det billigt, du kan have det hurtigt, eller du kan have det godt. Pick to. Fordi du ikke kan have alle tre. Højre? OKAY. 

Så du hører om denne meget. Det er en tredobbelt begrænsning, trekant af triple tvang, eller jern trekant er oftentimes-- når du taler med projektledere, de vil tale om det. Nu databaser deres egne jern trekant. Og jern trekant af data er det, vi kalder den fælles landbrugspolitik teorem. OKAY? 

CAP Sætning dikterer hvordan databaser fungerer under en meget specifik tilstand. Og vi vil tale om hvad denne betingelse er. Men de tre punkter i trekanten, så at sige, er C, konsistens. OKAY? Så, konsistens betyder i den fælles landbrugspolitik, at alle kunder, der kan få adgang til databasen vil altid have en meget sammenhængende billede af data. Ingen vil se to forskellige ting. OKAY? Hvis jeg ser databasen, Jeg ser den samme visning som min partner, der ser den samme database. Det er konsistens. 

Tilgængelighed betyder, at hvis database online, hvis det kan nås, at alle kunder vil altid kunne læse og skrive. OKAY? Så hver klient, kan læse databasen vil altid kunne læse data og skrive data. Og hvis det er tilfældet, det er et tilgængeligt system. 

Og det tredje punkt er, hvad vi kalder partition tolerance. OKAY? Partition tolerance betyder at systemet fungerer godt trods fysiske netværk skillevægge mellem knudepunkterne. OKAY? Så noder i klyngen ikke kan tale med hinanden, hvad sker der? Okay. 

Så relationsdatabaser choose-- du kan vælge to af disse. OKAY. Så relationsdatabaser vælger at være konsekvent og tilgængelig. Hvis partitionen sker mellem de DataNodes i datalageret, databasen går ned. Højre? Det bare går ned. OKAY. 

Og det er derfor, de har at vokse med større kasser. Højre? Fordi der er no-- normalt, en klynge database, er der ikke ret mange af dem at drive den måde. Men de fleste databaser skalere lodret i en enkelt kasse. Fordi de har brug for at være konsekvent og tilgængelig. Hvis en skillevæg blev der skal injiceres, så ville du nødt til at træffe et valg. Du er nødt til at træffe et valg mellem være konsekvent og tilgængelig. 

Og det er, hvad NoSQL databaser gør. Okay. Så en NoSQL database, kommer i to varianter. Vi have-- godt, det kommer i mange varianter, men det kommer med to grundlæggende characteristics-- hvad vi ville kalde CP-database eller en konsekvent og partition tolerance system. Disse fyre træffe det valg, at når knudepunkterne mister kontakt med hinanden, Vi kommer ikke til at tillade folk til at skrive mere. OKAY? 

Indtil denne partition er fjernet, skrive adgang er blokeret. Det betyder, de er ikke tilgængelige. De er konsekvent. Når vi ser, at partition injicere sig selv, vi nu konsekvent, fordi vi vil ikke at tillade data ændring på to sider af skillevæggen uafhængigt af hinanden. Vi bliver nødt til at genetablere kommunikation før enhver opdatering dataene er tilladt. OKAY? 

Den næste smag ville være en AP-system, eller en tilgængelig og delt tolerance system. Disse fyre er ligeglade. Højre? Enhver node, der får en skrive, vi vil tage det. Så jeg replikere mine data på tværs af flere knudepunkter. Disse knudepunkter får en klient, klient kommer i, siger, vil jeg skrive nogle data. Node siger, ikke noget problem. Den knude ved siden af ​​får ham en skrive på den samme post, han vil sige noget problem. Et eller andet sted tilbage på bagenden, at data kommer til at kopiere. Og så nogen kommer til at indse, uh-oh, de systemet vil indse, uh-oh, der har været en opdatering til to sider. Hvad gør vi? Og hvad de gør så er de gør noget, som giver dem mulighed for at løse, at data tilstand. Og vi vil tale om at i den næste diagram. 

Ting at påpege her. Og jeg har ikke tænkt mig at få alt for meget ind i dette, fordi dette kommer i dyb data teori. Men der er en transaktionsbeslutning ramme, kører i en relationel system, tillader mig at sikkert foretage opdateringer til flere enheder i databasen. Og vil forekomme disse opdateringer på én gang eller slet ikke. Og dette kaldes ACID transaktioner. OKAY? 

ACID giver os Atomicity, konsistens, isolation og holdbarhed. OKAY? Det betyder atomare, transaktioner, alt mine opdateringer enten ske, eller de ikke. Konsistens betyder, at Databasen vil altid bringes i en ensartet tilstand efter en opdatering. Jeg vil aldrig forlade databasen i en dårlig tilstand efter anvendelse en opdatering. OKAY? 

Så det er lidt anderledes end CAP konsistens. CAP konsistens betyder alle mine kunder kan altid se data. ACID konsistens betyder, at når en transaktion er gjort, data er godt. Mine relationer er alle gode. Jeg har ikke tænkt mig at slette en forælder række og efterlade en flok forældreløse børn på anden tabel. Det kan ikke ske, hvis jeg er i overensstemmelse i en syre transaktion. 

Isolation betyder, at transaktioner vil altid forekomme ene efter den anden. Det endelige resultat af de data, vil være den samme tilstand som om disse transaktioner der blev udstedt samtidigt blev henrettet serielt. Så det er samtidighed kontrol i databasen. Så dybest set, kan jeg ikke øg samme værdi to gange med to operationer. 

Men hvis jeg siger tilsættes 1 til denne værdi, og to transaktioner kommer i og forsøge at gøre det, man er kommer til at komme først og den anden er kommer til at blive der efter. Så i sidste ende, tilføjede jeg to. Ser du, hvad jeg mener? OKAY. 

Holdbarhed er temmelig ligetil. Når transaktionen er anerkendt, er det vil være der selv Hvis systemet går ned. Når dette system bedres, at transaktion, der blev begået er faktisk kommer til at være der. Så det er de garantier af syre transaktioner. De er temmelig nice garantier at have på en database, men de kommer på udgifterne. Højre? 

Fordi problemet med denne ramme er hvis der er en partition i data sæt, jeg er nødt til at træffe en beslutning. Jeg har tænkt mig at have til at tillade opdateringer om den ene eller den anden side. Og hvis det sker, så er jeg ikke længere går at kunne opretholde disse kendetegn. De vil ikke være i overensstemmelse. De vil ikke være isoleret. Det er her, det nedbryder til relationelle databaser. Dette er grunden til relationelle databaser skalere vertikalt. 

På den anden side har vi hvad har kaldt BASE teknologi. Og disse er dine NoSQL databaser. Okay. Så vi har vores CP, AP-databaser. Og disse er, hvad du kalder dybest set rådighed, blød tilstand, vinder konsekvent. OKAY? 

Grundlæggende rådighed, fordi de er partition tolerant. De vil altid være der, selv om der er et netværk skillevæg mellem knudepunkterne. Hvis jeg kan tale med en node, jeg er vil være i stand til at læse data. OKAY? Jeg er måske ikke altid være i stand til at skrive data, hvis jeg er en konsistent platform. Men jeg vil være i stand til at læse data. 

Den bløde tilstand angiver at da jeg læste, at data, det kan ikke være det samme som andre knudepunkter. Hvis en ret blev udstedt på en node et andet sted i klyngen og det har ikke den samme i klynge endnu, da jeg læste, at data, at staten måske ikke være konsekvent. Imidlertid vil det være sidst konsekvent, betyder, at når en skrive er lavet til systemet, det vil replikere på tværs af knudepunkter. Og i sidste ende, at staten vil blive bragt i orden, og det vil være en konsistent tilstand. 

Nu CAP teorem virkelig spiller kun én betingelse. Denne betingelse er, når dette sker. Fordi når det opererer i normal tilstand, er der ingen partition, alt er konsekvente og tilgængelige. Du skal kun bekymre sig om den fælles landbrugspolitik når vi har denne partition. Så dem er sjældne. Men hvordan systemet reagerer, når de, opstår diktere hvilken type system Vi har at gøre med. 

Så lad os tage et kig på, hvad der ligner til AP-systemer. OKAY? AP-systemer kommer i to varianter. De kommer i smag, der er en mester mester, 100%, altid tilgængelig. Og de kommer i anden smag, som siger, ved du hvad, jeg skal til at bekymre sig om denne opdeling ting når en faktisk partition opstår. Ellers har der kommer til at være den primære noder, der kommer til at tage rettighederne. OKAY? 

Så hvis vi noget som Cassandra. Cassandra ville være en mester mester, lad er mig skrive til enhver node. Så hvad sker der? Så jeg har et objekt i database, der findes på to knudepunkter. Lad os kalde det pågældende objekt S. Så vi har state for S. Vi har nogle operationer på S, der er i gang. Cassandra giver mig mulighed for skrive til flere noder. Så lad os sige jeg får en skrive for s til to knudepunkter. Nå, hvad ender sker, er Vi kalder det en opdeling begivenhed. Der kan ikke være en fysiske netværk partition. Men på grund af designet af systemet, er det faktisk opdele hurtigst som jeg får en skrive på to noder. Det er ikke tvinger mig til skrive alle gennem en knude. Jeg skriver på to noder. OKAY? 

Så nu har jeg to stater. OKAY? Hvad kommer til at ske er før eller senere, Der kommer til at være en replikering begivenhed. Der kommer til at være, hvad vi kaldes en partition opsving, som er, hvor disse to stater kommer sammen igen og der vil være en algoritme der løber inde i databasen, bestemmer, hvad de skal gøre. OKAY? Som standard, sidste ændring vinder i de fleste AP systemer. Så der er normalt en standard algoritme, hvad de kalder en tilbagekald funktion, hvilket vil blive kaldt, når denne betingelse detekteres at udføre en vis logik at løse denne konflikt. OKAY? Standardindstillingen tilbagekald og standard resolver i de fleste AP databaser er, gæt hvad, tidsstempel vinder. Dette var den sidste ændring. Jeg har tænkt mig at sætte det opdatering derinde. Jeg kan dumpe denne post, jeg dumpet ud i et opsving log således at brugeren kan vende tilbage senere og sige, hey, var der en kollision. Hvad skete der? Og du kan faktisk dumpe en registrering af alle kollisioner og rollbacks og se hvad der sker. 

Nu, som en bruger, kan du også omfatter logik i, at tilbagekald. Så du kan ændre det tilbagekald drift. Man kan sige, hey, jeg ønsker til at afhjælpe disse data. Og jeg ønsker at prøve og flette disse to poster. Men det er op til dig. Databasen ikke ved, hvordan man gøre det som standard. Det meste af tiden, det eneste database forstår at gøre, er at sige, dette var den sidste rekord. Det er den, der kommer til at vinde, og det er den værdi, jeg har tænkt mig at sætte. Når denne partition opsving og replikation finder sted, vi har vores stat, som nu S primtal, som er fletningen tilstand af alle disse objekter. Så AP systemer har dette. CP-systemer behøver ikke at bekymre sig om dette. Fordi så snart en partition kommer i spil, de bare stoppe med at tage skriver. OKAY? Så det er meget nemt at beskæftige sig med at være konsekvent når du ikke accepterer nogen opdateringer. Det er med CP-systemer gør. Okay. 

Så lad os tale lidt lidt om adgang mønstre. Når vi taler om NoSQL, det er alt om adgangen mønster. Nu SQL er ad hoc, forespørgsler. Det er relationel butik. Vi behøver ikke at bekymre dig om adgangen mønster. Jeg skriver en meget kompleks forespørgsel. Det går og får dataene. Det er, hvad det ser lignende, normalisering. 

Så i denne særlige struktur, vi kigger på en produkter katalog. Jeg har forskellige typer af produkter. Jeg har bøger. Jeg har albums. Jeg har videoer. Forholdet mellem varer og en af ​​disse bøger, albums, og videoer tabeller er 1: 1. Okay? Jeg har fået et produkt-id, og at ID svarer til en bog, et album eller en video. OKAY? Det er en 1: 1 forhold tværs disse tabeller. 

Nu books-- alt, hvad de har, er roden egenskaber. Intet problem. Det er godt. En-til-en-forhold, jeg får alle de data, jeg har brug for at beskrive den bog. Albums-- albums har spor. Dette er, hvad vi kalder en til mange. Hver album kunne have mange spor. Så for alle spor på albummet, jeg kunne have en anden rekord i dette barn tabellen. Så jeg oprette en rekord i min album tabellen. Jeg opretter flere poster i sporene tabellen. En-til-mange-relation. 

Dette forhold er det vi kalder mange-til-mange. OKAY? Du se, at aktørerne kunne være i mange film, mange videoer. Så hvad vi gør, er vi sætter denne kortlægning sammenhængen mellem dem, som det bare kortlægger skuespilleren id til video-id. Nu kan jeg oprette en forespørgsel sammenføjningerne videoer gennem skuespiller video til skuespillere, og det giver mig en god liste over alle de film og alle aktører der var i den film. 

OKAY. Så her vi gå. En-til-en er på øverste niveau forhold; én-til-mange, albums til spor; mange-til-mange. Det er de tre øverste niveau relationer i enhver database. Hvis du ved, hvordan de relationer arbejder sammen, så du kender en masse om database allerede. Så NoSQL fungerer lidt anderledes. Lad os tænke over for en anden, hvad det Ligner at gå få alle mine produkter. 

I en relationsdatabase butik, I ønsker at få alle mine produkter på en liste over alle mine produkter. Det er en masse forespørgsler. Jeg fik en forespørgsel til alle mine bøger. Jeg fik en forespørgsel fra mine albums. Og jeg fik en forespørgsel til alle mine videoer. Og jeg kom til at sige det alle sammen på en liste og tjene det tilbage op til program, der anmoder om den. 

At få mine bøger, jeg slutte Produkter og bøger. For at få mine albums, fik jeg at slutte Produkter, album og spor. Og for at få mine videoer, jeg har at slutte Produkter til videoer, deltage gennem Actor videoer, og sætter i aktørerne. Så det er tre forespørgsler. Meget komplekse forespørgsler til samle et resultat sæt. 

Det er mindre end optimal. Dette er grunden til, når vi taler omkring en datastruktur, der er bygget til at være agnostiker til adgangen pattern-- godt det er fantastisk. Og du kan se det er virkelig dejligt, hvordan vi har organiseret dataene. Og ved du hvad? Jeg har kun én rekord for en skuespiller. 

Det er sejt. Jeg har deduplikerede alle mine skuespillere, og jeg fastholdt min foreninger i denne kortlægning tabellen. Men at få de data, ud bliver dyrt. Jeg sender CPU'en hele systemet forbinder de datastrukturer sammen at kunne trække det data tilbage. 

Så hvordan får jeg omkring dette? I NoSQL det handler om aggregering, ikke normalisering. Så vi ønsker at sige, vi ønsker at støtte adgangsmønster. Hvis adgangen mønster til de programmer, Jeg har brug for at få alle mine produkter. Lad os lægge alle de produkter i en tabel. Hvis jeg lægger alle de produkter i en tabel, Jeg kan bare vælge alle produkter fra tabellen, og jeg får det hele. Godt, hvordan gør jeg det? Godt i NoSQL er der ingen struktur til tabellen. Vi taler lidt om hvordan det fungerer i Dynamo DB. Men du behøver ikke have den samme egenskaber og de samme egenskaber i hvert enkelt række, i hvert enkelt element, som du gør i en SQL tabel. Og hvad det giver mig mulighed for at gøre, er en masse ting og give mig en masse fleksibilitet. I dette særlige tilfælde, jeg har mit produkt dokumenter. Og i dette særlige eksempel alt er et dokument i tabellen Produkter. Og produktet til en bog måske have en type id, der angiver en bog. Og ansøgningen ville skifte på denne id. 

Ved ansøgningen tier, vil jeg at sige åh, hvilken posttype er dette? Åh, det er en bog rekord. Bestil optegnelser har disse egenskaber. Lad mig lave en bog objekt. Så jeg har tænkt mig at fylde bog objekt med dette punkt. Næste punkt på dagsordenen kommer og siger, hvad er dette punkt? Nå denne post er et album. Åh, jeg fik en helt anden behandling rutine for at fordi det er et album. Ser du, hvad jeg mener? 

Så ansøgningen tier-- jeg bare vælge alle disse optegnelser. De har alle begynde at komme i. De kunne være alle de forskellige typer. Og det er programmets logik der skifter over de typer og beslutter, hvordan at behandle dem. 

Igen, så vi optimerer skema for adgangen mønster. Vi gør det ved kollapse disse tabeller. Vi er dybest set tager disse normaliserede strukturer, og vi er ved at bygge hierarkiske strukturer. Inde hver enkelt af disse optegnelser Jeg har tænkt mig at se array-egenskaber. 

Inde dette dokument for Albums, Jeg ser arrays af spor. Disse spor nu become-- det er dybest set dette barn tabel, findes lige her i denne struktur. Så du kan gøre dette i DynamoDB. Du kan gøre dette i MongoDB. Du kan gøre dette i enhver NoSQL database. Oprette disse typer af hierarkiske datastrukturer der giver dig hente data meget hurtigt, fordi jeg nu behøver ikke at opfylde. Når jeg indsætter en række i Tracks bord eller en række i tabellen Albums, Jeg er nødt til at være i overensstemmelse med denne skema. Jeg skal have attributten eller ejendom, der er defineret på det bord. Hver eneste af dem, når jeg indsætter den pågældende række. Det er ikke tilfældet i NoSQL. 

Jeg kan have helt forskellige egenskaber i ethvert dokument at jeg indsætte i samlingen. Så meget kraftfuld mekanisme. Og det er virkelig, hvordan du optimere systemet. Fordi nu, at forespørgslen, i stedet til sammenføjning alle disse tabeller og udførelse af en halv snes forespørgsler at trække sig tilbage de data, jeg har brug for, Jeg udfører en forespørgsel. Og jeg iteration på tværs resultaterne i. det giver dig en idé af magt NoSQL. Jeg har tænkt mig at slags gå sidelæns her og snakke lidt om dette. Dette er mere form af markedsføring eller teknologiforbedringer markedsføring af teknologi type drøftelser. Men det er vigtigt at forstå for hvis vi ser på toppen her på dette skema, hvad vi kigger på er det, vi kalder teknologi hype kurve. Og hvad det betyder er nye ting kommer i spil. Folk synes, det er fantastisk. Jeg har løst alle mine problemer. 

Dette kunne være enden alt, være alt til alt. Og de begynder at bruge det. Og de siger, det her virker ikke. Dette er ikke rigtigt. Den gamle ting var bedre. Og de går tilbage til at gøre tingene, som de var. Og så til sidst de går, ved du hvad? Denne ting er ikke så slemt. Åh, er det, hvordan det fungerer. Og når de finde ud af, hvordan det værker, begynder de at få det bedre. 

Og det sjove ved det er, den slags linjer op til hvad vi kalder Technology Adoption Curve. Så sker der det, vi har en slags teknologi trigger. I tilfælde af databaser, Det er data pres. Vi talte om de høje branddamme af data pres hele tiden. Når disse data tryk rammer en vis punkt, det er en teknologi udløser. 

Det bliver for dyrt. Det tager for lang tid at behandle oplysningerne. Vi har brug for noget bedre. Du får de innovatorer derude løbe rundt, forsøger at finde ud af, hvad er løsningen. Hvad er den nye idé? 

Hvad er det næste bedste måde at gøre denne ting? Og de kommer op med noget. Og folk med reel smerte, fyrene på den blødende kant, de vil springe over det hele, fordi de har brug for et svar. Nu, hvad uundgåeligt happens-- og det sker lige nu i NoSQL. Jeg ser det hele tiden. 

Hvad uundgåeligt sker, er folk begynder at bruge det nye værktøj på samme måde de anvendes gamle værktøj. Og de finder ud af det fungerer ikke så godt. Jeg kan ikke huske, hvem jeg var taler med tidligere i dag. Men det er ligesom, når jackhammer blev opfundet, folk ikke svinge det over deres hoved til at smadre betonen. 

Men det er, hvad der er sker med NoSQL dag. Hvis du går ind på de fleste butikker, de forsøger at være NoSQL butikker. Hvad de laver, er de bruger NoSQL, og de er lægger det fuld af relationelle skema. Fordi det er sådan de designe databaser. Og de undrer, hvorfor er det ikke udfører meget godt? Dreng, denne ting stinker. Jeg var nødt til at opretholde alle mine slutter in-- det er ligesom, nej, nej. Vedligehold slutter? Hvorfor er du deltage data? Du behøver ikke slutte data i NoSQL. Du samler den. 

Så hvis du ønsker at undgå dette, lære hvordan værktøjet fungerer, før du rent faktisk begynde at bruge det. Forsøg ikke og bruge de nye redskaber i samme måde, som du brugte de gamle værktøjer. Du kommer til at have en dårlig oplevelse. Og hver eneste gang det er hvad det handler om. Når vi begynder at kommer op her, det er fordi folk regnet ud hvordan man bruger værktøjerne. 

De gjorde det samme, når relationelle databaser blev opfundet, og de erstatte filsystemer. De forsøgte at bygge filsystemer med relationsdatabaser fordi det er hvad folk forstået. Det virkede ikke. Så forstå de bedste fremgangsmåder af den teknologi, du arbejder med er enorme. Meget vigtigt. 

Så vi kommer til at komme ind i DynamoDB. DynamoDB er AWS s fuldt styret NoSQL platform. Hvad betyder fuldt styret betyde? Det betyder, at du ikke behøver at virkelig bekymre dig om noget. 

Du kommer ind, du fortælle os, jeg har brug for et bord. Det har brug for så meget kapacitet. Du ramte knappen, og vi levering alle infrastrukturen bag scenen. Nu, er enorm. 

Fordi når du taler om skalering af en database, NoSQL data klynger på skala, kører petabyte, kører millioner af transaktioner per sekund, disse ting er ikke små klynger. Vi taler tusindvis af tilfælde. Håndtering af tusindvis af tilfælde, selv virtuelle instanser, er en reel smerte i butt. Jeg mener, tænk på hver gang en operativsystemet patch kommer ud eller en ny version af databasen. Hvad betyder det til dig operationelt? Det betyder, at du fik 1.200 servere, der skal opdateres. Nu selv med automatisering, der kan tage lang tid. Det kan forårsage en masse operationelle hovedpine, fordi jeg måske har tjenester af ned. 

Da jeg opdatere disse databaser, jeg kan gøre blå grøn implementeringer hvor jeg installere og opgradere mit halve knudepunkter, og derefter opgradere den anden halvdel. Tag dem ned. Så forvalter infrastrukturen skalaen er enormt smertefuldt. Og AWS tage at smerte ud af det. Og NoSQL databaser kan være overordentlig smertefuldt på grund af den måde, de skalere. 

Skalere horisontalt. Hvis du ønsker at få en større NoSQL database, du køber flere noder. Hver node du køber, er anden operationel hovedpine. Så lad en anden gøre det for dig. AWS kan gøre det. 

Vi støtter dokument nøgleværdier. Nu har vi ikke gå alt for meget ind på den anden diagrammet. Der er en masse forskellige varianter af NoSQL. De er alle slags få munged sammen på dette punkt. Du kan se på DynamoDB og sige ja, vi er både et dokument og en nøgle værdi gemme dette punkt. Og du kan argumentere funktionerne af en over den anden. For mig, en masse af det er virkelig seks af den ene halvdel et dusin af den anden. Hver eneste af disse teknologier er en fin teknologi og en fin løsning. Jeg vil ikke sige MongoDB er bedre eller værre end Couch, så Cassandra, derefter Dynamo, eller vice versa. Jeg mener, det er blot muligheder. 

Det er hurtigt og det er overensstemmelse i enhver skala. Så dette er en af ​​de største bonusser du får med AWS. Med DynamoDB er evnen at få en lav encifret millisekund latenstid i enhver skala. Det var et design mål af systemet. Og vi har kunder, der gør millioner af transaktioner per sekund. 

Nu vil jeg gå gennem nogle af dem, bruge tilfælde i et par minutter her. Integreret adgang control-- vi har det, vi kalder Identity Access Management, eller IAM. Det gennemsyrer alle systemer, hver tjeneste, AWS tilbyder. DynamoDB er ingen undtagelse. Du kan styre adgangen til DynamoDB tabeller. Tværs af alle dine AWS-konti ved definere adgang roller og tilladelser i IAM infrastruktur. 

Og det er en nøgle og integreret del i hvad vi kalder Begivenhed Driven Programmering. Nu er dette er et nyt paradigme. 

PUBLIKUM: Hvordan er din hastighed på sand positive versus falsk negative resultater på dit adgangskontrolsystem? RICK Houlihan: Ægte positiver versus falsk negative? PUBLIKUM: Vender tilbage, hvad du skal vende tilbage? I modsætning til en gang imellem det ikke vender tilbage, når det skal validere? 

RICK Houlihan: Jeg kunne ikke fortælle dig det. Hvis der er nogen fejl overhovedet på det, Jeg er ikke den person at spørge denne særlige spørgsmål. Men det er et godt spørgsmål. Jeg ville være nysgerrig efter at vide at jeg selv, faktisk. 

Og så så igen, nyt paradigme er hændelsesdrevet programmering. Det er den idé, at du kan implementere komplekse programmer, kan drive en meget, meget høj skala uden nogen form for infrastruktur. Uden nogen fast overhovedet infrastruktur. Og vi vil snakke lidt om, hvad det betyder, når vi komme videre til de næste par diagrammer. 

Det første, vi vil gøre er vi tale om tabeller. Typer API-data for Dynamo. Og den første ting, du vil bemærke, når du ser på dette, Hvis du er fortrolig med enhver database, databaser har virkelig to slags API'er Jeg ville kalde det. Eller to sæt API. En af dem ville være administrativ API. 

De ting, de tager sig af funktionerne af databasen. Konfiguration af storage engine, etablering og tilføje tabeller. skabe database kataloger og instanser. Disse things-- i DynamoDB, du har meget korte, korte lister. 

Så i andre databaser, du kan se snesevis af kommandoer, administrativt kommandoer, til konfiguration disse yderligere muligheder. I DynamoDB behøver du ikke dem, fordi du ikke konfigurere systemet, så gør vi. Så det eneste du skal gøre, er fortælle mig, hvad størrelse tabel har jeg brug for. Så du får en meget begrænset sæt kommandoer. 

Du får en Create Table Update, tabel, Slet tabel, og Beskriv tabel. De er de eneste ting du har brug for DynamoDB. Du behøver ikke et lager motorer. Jeg behøver ikke at bekymre dig om replikation. Jeg behøver ikke at bekymre dig om sharding. 

Jeg behøver ikke at bekymre sig om nogen af ​​disse ting. Vi gør det hele for dig. Så det er en enorm mængde af overliggende der er bare løftes din tallerken. Så har vi de CRUD operatører. CRUD er noget, hvad vi tilkalde database, der er Oprette, opdatere, slette operatører. Disse er din sunde database operationer. Ting som put post, få post, opdatere poster, slette poster, batch forespørgsel, scan. Hvis du vil scanne hele tabellen. Træk alt af bordet. En af de gode ting ved DynamoDB er det muligt parallel scanning. Så du kan faktisk lade mig vide, hvor mange tråde du ønsker at køre på denne scanning. Og vi kan køre disse tråde. Vi kan spin at scanne op på tværs af flere tråde så du kan scanne hele tabellen plads meget, meget hurtigt i DynamoDB. 

Den anden API vi har, er hvad vi kalder vores Streams API. Vi kommer ikke til at tale for meget om det lige nu. Jeg har noget indhold senere indenfor bunken om dette. Men Vandløb er virkelig en running-- tænke på det som den tid bestilt og partition ændringslog. Alt, hvad der sker på viser tabellen op på åen. 

Hver skrive til bordet dukker op på åen. Du kan læse denne strøm, og du kan gøre ting med det. Vi taler om, hvad typer af ting, du gøre med de ting som replikation, skaber sekundære indekser. Alle former for virkelig cool ting, du kan gøre med det. 

Datatyper. I DynamoDB støtter vi både nøgle værdi og dokument datatyper. På venstre side af skærmen her har vi vores grundlæggende typer. Hovedtyper værdi. Disse er strenge, tal og binære filer. 

Så blot tre grundlæggende typer. Og så kan du få sæt af dem. En af de gode ting om NoSQL er kan indeholde arrays som egenskaber. Og med DynamoDB du kan indeholde arrays af basale typer som en rod ejendom. 

Og så er der de dokumenttyper. Hvor mange mennesker er fortrolige med JSON? Du fyre er fortrolige med JSON så meget? Det er dybest set JavaScript, Objekt, Notation. Det giver dig mulighed for at stort set definere en hierarkisk struktur. 

Du kan gemme et JSON-dokument på DynamoDB ved hjælp af fælles komponenter eller byggesten, der er tilgængelige i de fleste programmeringssprog. Så hvis du har Java, er du se på kort og lister. Jeg kan lave objekter, område kort. Et kort som nøgleværdier opbevares som egenskaber. Og det kunne have lister over værdier inden for disse egenskaber. Du kan gemme denne komplekse hierarkisk struktur som en enkelt attribut en DynamoDB element. 

Så tabeller i DynamoDB, ligesom de fleste NoSQL-databaser, tabeller har elementer. I MongoDB ville du kalder disse dokumenter. Og det ville være sofaen base. Også et dokument database. Du kalder disse dokumenter. Dokumenter eller elementer har attributter. Attributter kan findes eller ikke eksistere på elementet. I DynamoDB, der en obligatorisk attribut. Ligesom i en relationel database, du har en primær nøgle på bordet. 

DynamoDB har det, vi kalder en hash nøgle. Hash nøgle skal være unikt. Så når jeg definerer en hash tabel, dybest set, hvad jeg siger er hver post vil have en hash nøgle. Og hver hash nøgle skal være unik. 

Hvert element er defineret ved denne unikke hash nøgle. Og der kan kun være én. Det er OK, men oftentimes hvad folk har brug for er, de ønsker, er denne hash nøglen til at gøre en lille smule mere end blot være en entydig identifikator. Ofte vi ønsker at bruge, at hash nøgle som det øverste niveau sammenlægning spand. Og den måde, vi gør det på er ved tilføjer det, vi kalder en række nøgle. 

Så hvis det er kun en hash tabel, skal dette være unik. Hvis det er en hash og rækkevidde tabel, Kombinationen af ​​hash og området skal være unikt. Så tænker over det på denne måde. Hvis jeg har et forum. Og formen har emner, har det stillinger, og det har svar. 

Så jeg kunne have en hash nøgle, som er emnet ID. Og jeg kunne have en række nøgle, som er svaret ID. Den måde, hvis jeg ønsker at få alle de svar for bestemt emne, Jeg kan bare forespørge hash. Jeg kan bare sige give mig alle de elementer, der har denne hash. Og jeg har tænkt mig at få alle spørgsmål eller post for den pågældende emne. Disse øverste niveau aggregeringer er meget vigtige. De støtter den primære adgang mønster af ansøgningen. Generelt er dette er, hvad vi ønsker at gøre. Vi ønsker, at table-- som du lægger bordet, vi ønsker at strukturere data i tabellen på en sådan måde at ansøgningen kan meget hurtigt hente disse resultater. Og ofte den måde at gøre det er at opretholde disse grupperinger som vi indsætte data. Dybest set, er vi sprede data ind i den lyse spand, som det kommer i. 

Range nøgler tillader mig-- hash nøgler skal være lighed. Når jeg forespørge en hash, jeg har at sige give mig en hash, der er lig med dette. Når jeg forespørge et interval, jeg kan sige give mig en vifte der bruger enhver form for rige operatør, vi støtter. Giv mig alle elementer til en hash. Er det lige, større end, mindre end, betyder det at begynde med, betyder det eksisterer mellem disse to værdier? Så disse typer af range forespørgsler at vi er altid interesseret i. Nu er en ting om data, når du ser på adgang til data, når du få adgang til data, er det altid om en sammenlægning. Det er altid om posterne der er relateret til dette. Giv mig alt her that's-- alle transaktionerne på dette kreditkort for den sidste måned. Det er en sammenlægning. 

Næsten alt, hvad du gør i database er en slags aggregering. Så at kunne være i stand til at definere disse spande og give dig disse rækkevidde egenskaber til at være i stand til at forespørge på, disse rige forespørgsler støtter mange, mange, mange ansøgning adgang mønstre. 

Så den anden ting på firkanttasten gør, er det giver os en mekanisme at kunne sprede data rundt. NoSQL databaser fungerer bedst når dataene er jævnt fordelt over hele klyngen. Hvor mange mennesker kender med hashing algoritmer? Når jeg siger hash og en hashing-- fordi en hashingalgoritme er en måde at være i stand til at generere en tilfældig værdi fra en given værdi. Så i dette tilfælde, den hash algoritme vi kører, er ND 5 baseret. 

Og hvis jeg har et ID, og ​​dette er min hash nøgle, jeg har 1, 2, 3. Når jeg kører hash-algoritme, det kommer til at komme tilbage og sige, godt 1 er 7B, 2 lig 48, 3 er lig med cd. De er fordelt over hele den centrale plads. Og hvorfor gør man det? Fordi det gør sikker på, at jeg kan sætte posterne på tværs af flere noder. 

Hvis jeg gør det trinvist, 1, 2, 3. Og jeg har en hash område, der kører i dette særlige tilfælde, en lille hash plads, det kører fra 00 til FF, derefter optegnelserne vil komme i og de kommer til at gå 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. Hvad der sker? Hver indsatsen går til samme node. Ser du, hvad jeg mener? 

Fordi når jeg opdele rummet, og jeg spreder disse optegnelser over, og jeg partition, jeg har tænkt mig at sige partition 1 har nøglen plads 0-54. Partition 2 er 55-89. Partition 3 er AA til FF. Så hvis jeg bruger lineært forøgelse Id'er, kan du se, hvad der sker. 1, 2, 3, 4, 5, 6, hele vejen op til 54. Så som jeg hamre optegnelser i systemet, alt ender med at gå til en knude. 

Det er ikke godt. Det er en antipattern. I MongoDB de har dette problem Hvis du ikke bruger en hash nøgle. MongoDB giver dig mulighed af hashing nøglen værdi. Du bør altid gøre det, hvis du bruger en forøgelse hash nøglen i MongoDB, eller vil du være sømning hver skrive til en knude, og du vil være begrænsende din skrive gennemløb dårligt. 

PUBLIKUM: Er det A9 169 i decimal? 

RICK Houlihan: Ja, det er et sted omkring der. A9, ved jeg ikke. Du er nødt til at få min binære til decimal lommeregner. Min hjerne virker ikke sådan. PUBLIKUM: Bare en hurtig én af dine Mongo kommentarer. Så er det objekt-id, der kommer indbygget med Mongo gøre det? RICK Houlihan: Er det gøre det? Hvis du angiver det. Med MongoDB, har du mulighed for. Du kan specify-- hvert dokument i MongoDB skal have en understregning id. Det er den unikke værdi. 

I MongoDB kan du angive om at hash det eller ej. De bare give dig mulighed. Hvis du ved, at det er tilfældig, ikke noget problem. Du behøver ikke at gøre det. Hvis du ved, at det ikke er tilfældigt, at det er forøgelse, så gør hash. 

Nu ting om hashing, når du hash a value-- og det er hvorfor hash nøgler er altid unikke forespørgsler, fordi jeg har ændret værdien, nu kan jeg ikke gøre et interval forespørgsel. Jeg kan ikke sige, er dette mellem dette eller hint, fordi hash-værdi ikke vil at svare til den faktiske værdi. Så når du hash, at nøgle, det er kun lighed. Det er derfor, i DynamoDB hash nøgle forespørgsler er altid kun lighed. 

Så nu i en række key-- når jeg tilføje, at rækkevidde nøgle, disse range nøgle poster alle kommer ind og de bliver opbevaret på samme partition. Så de er meget hurtigt, nemt hentet, fordi det er det hash, dette er intervallet. Og du se alt med samme hash bliver gemt på samme partition plads. Du kan bruge dette område nøgle til at hjælpe lokalisere dine data tæt på sin forælder. Så hvad skal jeg egentlig laver her? Dette er en for mange-relation. Forholdet mellem en hash nøgle og udvalget nøglen er én for mange. Jeg kan have flere hash nøgler. Jeg kan kun have flere rækkevidde nøgler inden hver hash nøgle. 

Hash definerer forælder, området definerer børn. Så du kan se, at der er analog her mellem den relationelle konstruktion og de samme typer af konstruktioner i NoSQL. Folk taler om NoSQL som ikke-relationelle. Det er ikke ikke-relationelle. Data, altid har relationer. Disse relationer bare er modelleret forskelligt. Lad os snakke lidt lidt om holdbarhed. Når du skriver til DynamoDB, skriver er altid trevejs replikeret. Hvilket betyder, at vi har tre AZ. AZ er Tilgængelighed Zones. Du kan tænke på en Tilgængelighed Zone som et datacenter eller en samling af datacentre. Disse ting er geografisk isoleret fra hinanden tværs af forskellige fejl zoner, på tværs forskellige elnet og flodsletter. En fejl i en AZ er ikke kommer til at tage ned en anden. De er også forbundet sammen med mørke fibre. Det understøtter en sub 1 millisekund latenstid mellem AZS. Så realtidsdata replikationer stand i multi AZS. 

Og ofte multi AZ implementeringer opfylde de høje rådighedskrav af de fleste enterprise organisationer. Så DynamoDB spredes på tværs af tre AZS som standard. Vi kun vil viden skrivningen når to af disse tre knudepunkter vende tilbage og sige, Ja, jeg fik det. Hvorfor det? Fordi vi på read side er kun vil give dig de data tilbage, når vi får det fra to noder. 

Hvis jeg replikere tværs tre, og jeg læser fra to, Jeg er altid garanteret at have mindst én af dem læser at være mest aktuelle kopi af data. Det er, hvad der gør DynamoDB konsekvent. Nu kan du vælge at slå dem konsekvent læser fra. I hvilket tilfælde jeg har tænkt mig at sige, Jeg vil kun læse fra én node. Og jeg kan ikke garantere det vil at være de mest aktuelle data. 

Så hvis en skrive kommer ind, det har ikke replikeres endnu, du kommer til at få kopien. Det er en efterhånden konsekvent læse. Og hvad det er, er halvdelen af ​​omkostningerne. Så dette er noget at tænke over. Når du læser ud DynamoDB, og du indstiller din læst kapacitet enheder, hvis du vælger til sidst konsekvent læser, det er meget billigere, det er omkring halvdelen af ​​omkostningerne. 

Og så det sparer dig penge. Men det er dit valg. Hvis du vil have en konsekvent læse eller en efterhånden konsekvent læse. Det er noget, som du kan vælge. 

Lad os tale om indekser. Så vi nævnte, at øverste niveau aggregering. Vi har fået hash nøgler, og vi har range nøgler. Det er fedt. Og det er på den primære tabel, jeg fik en hash-nøgle, jeg fik en rækkevidde nøgle. 

Hvad betyder det? Jeg har fået en attribut, som jeg kan køre rige forespørgsler mod. Det er området tasten. De andre attributter på denne item-- Jeg kan filtrere på disse attributter. Men jeg kan ikke gøre ting som det begynder med eller er større end. 

Hvordan gør jeg det? Jeg oprette et indeks. Der er to typer af indekser i DynamoDB. Et indeks er virkelig andet syn på bordet. Og den lokale sekundære indeks. 

Det første vi vil tale om. Så lokale secondaries er sameksisteret på samme partition som dataene. Og som sådan er de på den samme fysiske knude. De er det, vi kalder konsekvent. Betydning, vil de erkende write sammen med bordet. Når write kommer ind, Vi vil skrive gennem indekset. Vi vil skrive op til bordet, og så vil vi erkende. Så det er konsekvent. Når skrivningen er blevet erkendt fra bordet, det er garanteret, at lokale sekundære indeks vil have den samme vision af data. Men hvad de tillader du skal gøre er definere alternative range nøgler. 

Nødt til at bruge den samme hash nøgle som den primære tabel, fordi de er placeret sammen på samme partition, og de er konsekvent. Men jeg kan oprette et indeks med forskellige range taster. Så for eksempel, hvis jeg havde en producent der havde en rå dele bord kommer ind. Og rå dele kommer i, og de er aggregeret ved samling. Og måske er der en tilbagekaldelse. 

Enhver del, der blev foretaget af denne producent efter denne dato, Jeg har brug for at trække fra min linje. Jeg kan dreje et indeks der ville være på udkig, aggregere på datoen for fremstilling af denne særlige del. Så hvis min top niveau tabel var allerede hashet af fabrikanten, måske det var arrangeret på en del-id, jeg kan skabe et indeks fra tabellen som hashet af fabrikanten og varierede på produktionsdatoen. Og på den måde, jeg kunne sige, noget, blev fremstillet mellem disse datoer, Jeg har brug for at trække fra linjen. Så det er en lokal sekundært indeks. 

Disse har den virkning, begrænse dit firkanttasten plads. Fordi de co-eksisterede på samme oplagring node, de begrænser hash nøgle plads til 10 gigabyte. DynamoDB, under borde, vil opdele dit bord hver 10 gigabyte. Når du lægger 10 gigs af data, vi gå [PHH], og vi tilføjer en anden node. 

Vi vil ikke opdele LSI på tværs af flere partitioner. Vi vil opdele tabellen. Men vi vil ikke opdele LSI. Så det er noget vigtigt at forstå er, hvis du laver meget, meget, meget store aggregeringer, så du kommer til at være begrænset til 10 gigabyte på din LSI- chips. 

Hvis det er tilfældet, kan vi bruge globale secondaries. Globale secondaries er virkelig en anden tabel. De eksisterer helt ud til den side af din primære tabel. Og de tillader mig at finde en helt anderledes struktur. Så tænk på det som data bliver indsat i to forskellige tabeller, struktureret på to forskellige måder. 

Jeg kan definere en helt forskellige hash nøgle. Jeg kan definere en helt forskelligt område nøgle. Og jeg kan køre dette helt uafhængigt af hinanden. Som en kendsgerning, har jeg klargjort min læse kapacitet og skrive kapaciteten for min globale sekundære indekser fuldstændig uafhængigt min primære tabel. Hvis jeg definere, at indekset, siger jeg det, hvor meget læse og skrive kapacitet det kommer til at bruge. 

Og der er adskilt fra min primære tabel. Nu begge indekser tillade os at ikke kun definere hash og range taster, men de giver os mulighed for at projicere yderligere værdier. Så hvis jeg ønsker at aflæse indekset, og jeg ønsker at få nogle sæt data, Jeg behøver ikke at gå tilbage til de vigtigste tabel for at få de ekstra attributter. Jeg kan projicere dem yderligere attributter i tabellen at støtte adgangsmønster. Jeg ved, vi sandsynligvis komme ind i nogle virkelig, really-- komme ind ukrudt her på nogle af disse ting. Nu fik jeg at glide ud af denne. 

PUBLIKUM: [uhørligt] --table nøgle mente var en hash? Den oprindelige hash? Multi-lameller? 

RICK Houlihan: Ja. Ja. Tabellen tasten grundlæggende peger tilbage til emnet. Så et indeks er en pointer tilbage til de oprindelige punkter på bordet. Nu kan du vælge at opbygge en indeks, der kun har tabelnøglen, og ingen andre egenskaber. Og hvorfor kan jeg gøre det? Nå, måske jeg har meget store emner. 

Jeg egentlig kun brug for at vide which-- min adgang mønster kan sige, hvilke elementer indeholder denne ejendom? Behøver ikke at returnere varen. Jeg har bare brug for at vide hvilke elementer indeholder den. Så du kan bygge indekser at kun få tabelnøglen. 

Men det er, hvad primært et indeks i databasen er for. Det er for at være i stand til hurtigt identificere, hvilke poster, hvilke rækker, der poster i tabellen har de egenskaber, som jeg søger efter. 

GSIS, så hvordan fungerer de? GSIS dybest set er asynkron. Opdateringen kommer i tabellen, Tabellen er derefter opdateret asynkront alle dine GSIS. Dette er grunden til GSIS er vinder konsekvent. 

Det er vigtigt at bemærke, at når du bygger GSIS, og du forstår du opretter en anden dimension af aggregation-- lad os nu sige et godt eksempel her er en producent. Jeg tror, ​​jeg kunne have talt om en producent af medicinsk udstyr. Medicinsk udstyr fabrikanter oftentimes har føljeton dele. De dele, der går ind en hofte alle har en lille serienummer på dem. Og de kunne have millioner og millioner og milliarder af dele i alle de enheder, som de skib. Tja, de har brug for at aggregere under forskellige dimensioner, alle dele i en enhed, hele dele, der blev foretaget på en bestemt strækning, alle de dele, der kom langs en bestemt producent på en bestemt dato. Og disse aggregater tider komme op i milliarder. 

Så jeg arbejder med nogle af disse fyre, der lider fordi de er ved at oprette disse ginormous aggregeringer i deres sekundære indekser. De har måske en rå dele tabel, der kommer som kun hash. Hver del har et unikt serienummer. Jeg bruger serienummeret som hash. Det er smukt. Min rådata tabel spredes hele nøglen plads. Mine [? skrive ?] [? indtagelse?] er awesome. Jeg tager en masse data. Så hvad de gør, er de skaber en GSI. Og jeg siger, ved du hvad, jeg har brug for at se alle dele til denne producent. Nå, pludselig er jeg tage en milliard rækker, og kram dem på en knude, fordi når Jeg aggregerer som fabrikant-id som hash, og en del nummer som intervallet, derefter alle de pludselige jeg sætte en milliard dele i, hvad denne producent har leveret mig. 

Det kan forårsage en masse pres på GSI, igen, fordi jeg hamre en knude. Jeg lægger alle disse indsættes i en knude. Og det er en rigtig problematisk brug tilfælde. Nu fik jeg et godt design mønster for, hvordan du undgår det. Og det er et af de problemer at jeg arbejder altid med. Men hvad sker der, er GSI måske ikke nok skrive kapacitet at kunne skubbe alle de rækker i en enkelt node. Og hvad sker der så er den primære, kunden bordet, den primære tabel vil blive droslet fordi GSI ikke kan holde op. Så min indsats sats vil falder på den primære tabel som min GSI forsøger at holde op. 

Okay, så GSI s, LSI s, som man skal jeg bruge? LSI er er konsekvent. GSI s er vinder konsekvent. Hvis det er OK, jeg anbefaler at bruge en GSI, de er meget mere fleksible. LSI s kan modelleres som en GSI. Og hvis datastørrelsen pr hash nøgler i din samling overstiger 10 gigabyte, så du vil ønsker at bruge, at GSI fordi det er bare en hård grænse. 

Okay, så skalering. Gennemløb i Dynamo DB, du dåse bestemmelse [uhørligt] gennemløb til en tabel. Vi har kunder, der har klargjort 60 billion-- gør 60 milliarder anmodninger, regelmæssigt kører på over en million anmodninger per sekund på vores borde. Der er virkelig ingen teoretisk grænse for, hvor meget og hvor hurtigt tabellen kan køre i Dynamo DB. Der er nogle bløde grænser for din konto at vi sætter i der så at du ikke gå amok. Hvis du ønsker mere end at, ikke et problem. Du kommer fortælle os. Vi vil skrue op for drejeknappen. 

Hver konto er begrænset til en vis grad i enhver tjeneste, lige ved bat så folk ikke gå amok få sig selv ind i problemer. Ingen grænse i størrelse. Du kan sætte et vilkårligt antal af elementer på et bord. Størrelsen på en vare er begrænset til 400 kilobyte hver, det ville være element ikke attributterne. Så summen af ​​alle attributter er begrænset til 400 kilobyte. Og så igen, vi har den lille LSI problem med 10 gigabyte grænse pr hash. PUBLIKUM: Lille antal, jeg mangler hvad du fortæller mig, at is-- PUBLIKUM: Åh, 400 kilobyte er den maksimale størrelse per post. Så et emne har alle de attributter. Så 400 k er den samlede størrelse af denne post, 400 kilobyte. Så af alle attributterne kombineret, alle data det er i alle disse attributter, rulles op i en total størrelse, i øjeblikket i dag posten grænse er 400 k. Så skalering igen, opnås gennem partitionering. Gennemløb er klargjort ved bordet niveau. Og der er virkelig to drejeknapper. Vi har læst kapacitet og skrive kapacitet. 

Så disse er justeret uafhængigt af hinanden. RCU s foranstaltning strengt konsekvente læser. OK, så hvis du siger jeg vil 1.000 RCU er dem, er strengt konsekvente, de er i overensstemmelse læser. Hvis du siger, jeg ønsker eventuel konsekvent læser, du kan 1.000 bestemmelse RCU er, er du nødt at få 2.000 vinder konsekvent læser. Og halv pris for dem i sidste ende består i læser. 

Igen, justeret uafhængigt af hinanden. Og de har throughput-- Hvis du spiser 100% af din RCU, du kommer ikke til at påvirke tilgængeligheden af ​​dine rettigheder. Så de er helt uafhængige af hinanden. Okay, så en af ​​de ting, Jeg nævnte kort blev kvæle. Neddrosling er dårlig. Neddrosling indikerer dårlig ingen SQL. Der er ting, vi kan gøre for at hjælpe du lindre drosling, du oplever. Men den bedste løsning til dette er lad os tage Et kig på hvad du laver, fordi der er en anti-mønster i spil her. 

Disse ting, ting som uensartet arbejdsbyrder, genvejstaster, hot partitioner. Jeg rammer en bestemt nøgle plads meget svært for nogle særlig grund. Hvorfor gør jeg det? Lad os finde ud af. Jeg blande min varme data med koldt data. Jeg lade mine tabeller få enorm, men der er virkelig kun en vis delmængde af data det er virkelig interessant for mig. Så for logdata, for eksempel en masse kunder, de får logdata hver dag. De fik en enorm mængde af logdata. 

Hvis du bare dumping alt, log data til én stor tabel, over tid tabellen kommer til at få massiv. Men jeg er virkelig kun interesseret i seneste 24 timer, de sidste syv dage, de sidste 30 dage. Uanset vindue af tid at jeg er interesseret i at kigge til arrangementet, der generer mig, eller tilfælde, der er interessant for mig, det er den eneste vindue gang, at jeg har brug for. Så hvorfor skal jeg sætte 10 år værd af logdata i tabellen? Hvad der forårsager er tabellen fragmentet. 

Det bliver enorm. Det begynder at sprede sig på tværs af tusindvis af knuder. Og da din evne er så lav, er du faktisk hastighedsbegrænsende på hver en af ​​de individuelle knudepunkter. Så lad os begynde at kigge på, hvordan gør vi ruller tabellen forbi. Hvordan kan vi styre, at data lidt bedre at undgå disse problemer. Og hvad betyder det så se ud? Dette er, hvad der ligner. Dette er, hvad dårlig NoSQL ser ud. 

Jeg fik en genvejstast her. Hvis man ser på siden her, disse er alle mine partitioner. Jeg fik 16 partitioner heroppe på denne særlige database. Vi gør det hele tiden. Jeg køre dette for kunder hele tiden. Det hedder zonekort. Zonekort fortæller mig, hvordan du er adgang til din nøgle plads. Og hvad det fortæller mig, er at der er en bestemt hash at denne fyr kan lide en frygtelig masse, fordi han er at ramme det virkelig, virkelig hårdt. 

Så den blå er rart. Vi kan godt lide blå. Vi kan ikke lide rød. Rødes hvor trykket bliver op til 100%. 100%, nu er du kommer til at blive kvalt. Så når du ser nogen røde linjer som denne-- og det er ikke bare Dynamo DB-- hver NoSQL database dette problem. Der er anti-mønstre, der kan drive disse typer af betingelser. Hvad jeg gør, er jeg arbejder med kunder at afhjælpe disse betingelser. 

Og hvad betyder det så se ud? Og det er at få det mest ud fra Dynamo DB gennemløb, men det er virkelig at få mest ud af NoSQL. Dette er ikke begrænset til Dynamo. Dette er definitely-- I bruges til at arbejde på Mongo. Jeg er bekendt med mange NoSQL platforme. Hver eneste har disse typer af varme centrale problemer. For at få mest ud af enhver NoSQL database, specielt Dynamo DB, du ønsker at skabe tabellerne hvor hash nøgleelement har et stort antal forskellige værdier, en høj grad af kardinalitet. Fordi det betyder jeg skriver til masser af forskellige spande. 

Jo flere spande jeg er skriver til, jo mere sandsynligt Jeg er at sprede at skrive belastning eller læse indlæse ud på tværs af flere knudepunkter, jo mere sandsynligt jeg skal have en high throughput på bordet. Og så vil jeg værdierne at være anmodet nogenlunde jævnt over tid og ensartet som tilfældigt som muligt. Tja, der er slags interessant, fordi jeg kan ikke rigtig kontrol, når brugerne kommer. Så tilstrækkeligt for at sige, hvis vi spreder ting ud over den centrale plads, Vi vil sandsynligvis være i bedre form. 

Der er en vis tid levering at du ikke vil at kunne kontrol. Men de er virkelig to dimensioner, vi har, og adgangsforhold jævnt spredning, tid, anmodninger ankommer jævnt fordelt i tid. Og hvis de to betingelser er opfyldt, så det er hvad det er kommer til at se ud. Det er meget pænere. Vi er virkelig glad her. Vi har fået en meget jævn adgang mønster. Ja, måske du får en lidt pres nu og da, men intet virkelig for omfattende. Så det er forbløffende, hvor mange gange, når jeg arbejder med kunder, den første graf med den store røde bar og alt det grimme gul det er over det hele, vi få gjort med øvelsen efter et par måneder af re-arkitektur, de kører nøjagtig samme arbejdsbyrde på nøjagtig samme belastning. Og dette er, hvad det ser ud nu. Så hvad du får med NoSQL er en data-skema, der er absolut bundet til adgangsmønster. 

Og du kan optimere, at data-skema at støtte, at adgang mønster. Hvis du ikke gør, så du kommer at se disse typer af problemer med disse genvejstaster. 

PUBLIKUM: Nå, uundgåeligt nogle steder vil være varmere end andre. 

RICK Houlihan: Altid. Altid. Ja, jeg mener der er altid en-- og igen, er der nogle design mønstre, vi får igennem som vil fortælle om, hvordan du behandler med disse super store aggregeringer. Jeg mener, jeg fik at have dem, hvordan kan vi håndtere dem? Jeg fik en temmelig god brug tilfælde at vi vil tale om for det. 

Okay, så lad os tale om nogle kunder nu. Disse fyre er AdRoll. Jeg ved ikke, om du er bekendt med AdRoll. Du sandsynligvis se dem en masse på browseren. De er ad re-targeting, de er den største annonce re-targeting forretning der ude. De normalt regelmæssigt kørt over 60 milliarder transaktioner pr dag. De gør over en million transaktioner per sekund. De har fået en temmelig simpel tabel struktur, den travleste bordet. Det er dybest set bare en hash nøgle er cookien, intervallet er den demografiske kategori, og derefter den tredje egenskab er scoren. 

Så vi har alle cookies i vores browser fra disse fyre. Og når du går til en deltagende handlende, de dybest set scorer du på tværs forskellige demografiske kategorier. Når du går til et websted og du siger, jeg ønsker at se denne ad-- eller dybest set behøver du ikke sige at-- men når du går til hjemmesiden de siger, du ønsker at se denne annonce. Og de gå få den pågældende annonce fra AdRoll. AdRoll ser dig op på deres bord. De finder din cookie. Annoncører fortæller dem, jeg vil have nogen hvem der er midaldrende, 40-årig mand, i sport. Og de scorer du i disse demografi og de beslutter, hvorvidt det er en god annonce for dig. 

Nu har de en SLA med deres reklame udbydere at give sub-10 millisekund svar på hver enkelt anmodning. Så de bruger Dynamo DB til dette. De er rammer os en millioner forespørgsler i sekundet. De er i stand til at gøre alle deres opslag, triage alle disse data, og få det add link tilbage til det annoncør på under 10 millisekunder. Det er virkelig temmelig fænomenal gennemførelse, de har. 

Disse fyre actually-- er disse fyrene. Jeg er ikke sikker på, om det er disse fyre. Kan være disse fyre. Grundlæggende fortalte os-- nej, jeg tror ikke, det var dem. Jeg tror, ​​det var en anden. Jeg arbejdede med en kunde, der fortalte mig, at nu, at de har gået til Dynamo DB, de er bruge flere penge på snacks til deres udvikling hold hver måned end de bruger på deres database. Så det vil give dig et idé om de besparelser at du kan få i Dynamo DB er enorm. Okay, dropcam er et andet selskab. Disse fyr er lidt of-- hvis du tror af tingenes internet, dropcam er dybest set internetsikkerhed video. Du sætter dit kamera derude. Kameraet har en bevægelsesdetektor. Nogen kommer sammen, udløser en cue punkt. Kamera begynder at optage i et stykke tid indtil Det registrerer ikke nogen bevægelse længere. Sætter den video op på internettet. 

Dropcam var en virksomhed, der er dybest set skiftet til Dynamo DB fordi de oplevede enorme vokseværk. Og hvad de fortalte os, pludselig petabyte data. De havde ingen idé deres service ville være så vellykket. Mere indgående video end YouTube er, hvad disse fyre får. De bruger DynamoDB at spore alle metadata på alle deres video centrale punkter. 

Så de har S3 spande de skubbe alle de binære artefakter ind. Og så har de Dynamo DB poster, pege folk til disse S3 tre objekter. Når de har brug for at se på en video, de ser op rekord i Dynamo DB. De klikker på linket. De trække ned videoen fra S3. Så det er lidt, hvad det ser ud. Og det er lige fra deres hold. 

Dynamo DB reducerer deres leveringstid til video begivenheder fra fem til 10 sekunder. I deres gamle relationelle butik, de plejede at have til at gå og udføre flere komplekse forespørgsler til figur ud af, hvilke videoer til at trække ned, til mindre end 50 millisekunder. Så det er fantastisk, fantastisk hvor meget ydelse du kan få, når du optimere og du stiller den underliggende database at støtte adgangsmønster. Halfbrick, disse fyre, hvad er det, Fruit Ninja jeg gætte er deres ting. At alle kører på Dynamo DB. Og disse fyre, de er en stor udvikling team, stor udvikling butik. 

Ikke en god ops team. De havde ikke en masse af drift ressourcer. De kæmpede forsøger at holde deres ansøgning infrastruktur op og kører. De kom til os. De kiggede på det Dynamo DB. De sagde, det er for os. De byggede deres helhed ansøgning rammer på det. Nogle virkelig rart kommentarer her fra holdet på deres evne til nu fokusere på bygningen spillet og ikke skulle vedligeholde infrastruktur, som var ved at blive en enorm mængde overhead til deres hold. Så det er noget at-- den fordel, at du får fra Dynamo DB. 

Okay, at komme ind datamodellering her. Og vi snakkede lidt om denne 00:59, en til mange, og mange til mange type relationer. Og hvordan kan du holde dem i Dynamo. I Dynamo DB bruger vi indekser, generelt, at rotere data fra en smag til den anden. Hash nøgler, range nøgler og indekser. 

I dette særlige eksempel som de fleste stater have en licens krav om, at kun én kørekort per person. Du kan ikke gå for at få to førerens licenser i staten Boston. Jeg kan ikke gøre det i Texas. Det er form for den måde, det er. Og så på DMV, har vi opslag, vi ønsker at se op kørekort med CPR-nummer. Jeg ønsker at se op brugeroplysninger af kørekort nummer. 

Så vi har måske en brugers tabel, har en hash tast på serienummeret, eller CPR-nummer, og forskellige attributter defineret på elementet. Nu på det bord jeg kunne definere en GSI at flips, at omkring der siger jeg vil en hash nøgle på licensen og derefter alle de andre emner. Nu, hvis jeg ønsker at forespørge og finde licensnummer for en given social Sikkerhed nummer, kan jeg forespørge hovedtabellen. 

Hvis jeg ønsker at forespørge og jeg vil have at få den sociale sikring nummer eller andre egenskaber ved en licensnummer, kan jeg forespørge GSI. Denne model er, at man et forhold. Bare en meget enkel GSI, flip disse ting rundt. Nu taler om en til mange. En til mange er dybest set din hash rækkevidde nøgle. Hvor vi får en masse med dette use case er overvåge data. Overvåg data kommer i regelmæssig interval, ligesom tingenes internet. Vi får altid alle disse optegnelser kommer ind hele tiden. 

Og jeg ønsker at finde alle aflæsninger mellem en bestemt tidsperiode. Det er en meget almindelig forespørgsel i overvågning infrastruktur. Den måde, gå om det er at finde en simpel tabel struktur, én tabel. Jeg har en enhed målinger tabel med en hash-tasten på enhedens id. Og jeg har en rækkevidde tast på tidsstempel, eller i dette tilfælde, det episke. Og det giver mig udføre komplekse forespørgsler mod dette interval nøgle og returnere disse poster, er i forhold til resultatet sæt, at jeg leder efter. Og det bygger, at man til mange-relation ind i den primære tabel ved hjælp af hash nøgle, rækkevidde nøgle struktur. 

Så der er slags bygget i tabellen i Dynamo DB. Når jeg definere en hash og rækkevidde t bord, er jeg definerer en en til mange-relation. Det er en forældre-barn forhold. 

Lad os tale om mange til mange relationer. Og til dette særlige eksempel igen, vi kommer til at bruge GSI s. Og lad os tale om gaming scenario, hvor jeg har en given bruger. Jeg ønsker at finde ud af alle de spil, der han er registreret for eller spille i. Og for en given spil, jeg ønsker at finde alle brugere. Så hvordan gør jeg det? Min bruger spil bord, jeg har tænkt mig at have en hash nøgle af bruger-id og en række nøgle af spillet. 

Således at en bruger kan have flere spil. Det er en en til mange-relation mellem brugeren og de spil han spiller. Og derefter på GSI, Jeg vil vende det rundt. Jeg hash på spillet og Jeg vil spænde på brugeren. Så hvis jeg ønsker at få alle de spil brugerens spille i, Jeg vil forespørge hovedtabellen. Hvis jeg ønsker at få alle brugere der spiller et bestemt spil, Jeg forespørge GSI. Så du se, hvordan vi gør det? Du bygger disse GSI s at støtte use case, programmet, adgang mønster, ansøgningen. 

Hvis jeg har brug for at forespørge på denne dimension, så lad mig med at oprette et indeks på denne dimension. Hvis jeg ikke gør det, jeg er ligeglad. Og afhængigt af brugen tilfældet, jeg kan have brug for det indeks eller jeg måske ikke. Hvis det er en simpel en til mange, den primære tabel er fint. Hvis jeg har brug for at gøre disse mange til mange s, eller jeg skal gøre en til dem, så måske jeg har brug for til andet indekset. Så det hele afhænger af hvad jeg forsøger at gøre og hvad jeg forsøger at få gennemført. 

Sandsynligvis Jeg har ikke tænkt mig at bruge for meget tid på at tale om dokumenter. Dette får en lille smule, formentlig, dybere, end vi har brug for at gå ind. Lad os snakke lidt om rige forespørgsel ekspression. Så i Dynamo DB har vi evnen til at skabe hvad vi kalder projektion udtryk. Projektion udtryk er simpelthen plukke markerne eller værdierne at du ønsker at vise. OK, så jeg foretage et valg. Jeg laver en forespørgsel mod Dynamo DB. Og jeg siger, ved du hvad, show mig kun de fem stjernede anmeldelser for dette særlige produkt. Så det er alt jeg ønsker at se. Jeg ønsker ikke at se alle de andre attributter af rækken, Jeg vil bare gerne se dette. Det er ligesom i SQL, når du sige Vælg stjerne eller fra bordet, du får alt. Når jeg siger at vælge navn fra bord, får jeg kun én attribut. Det er den samme slags ting i Dynamo DB eller anden NoSQL databaser. Filterudtryk tillade mig at dybest set skære resultat sættes af. Så jeg laver en forespørgsel. Query kan komme tilbage med 500 poster. Men jeg ønsker kun de elementer, har en egenskab, der siger dette. OK, så lad os bortfiltrere disse elementer der ikke matcher den pågældende forespørgsel. Så vi har filterudtryk. 

Filterudtryk kan køres på en attribut. De er ikke ligesom range forespørgsler. Raise forespørgsler er mere selektive. Filter forespørgsler kræver mig til at gå få hele resultater indstillet og derefter udelade de data, jeg ikke ønsker. Hvorfor er det vigtigt? Fordi jeg læste det hele. I en forespørgsel, vil jeg til at læse og det vil være en kæmpe om data. Og så vil jeg skære ud af hvad jeg har brug for. Og hvis jeg kun udelader en par rækker, så det er OK. Det er ikke så ineffektivt. 

Men hvis jeg læser en hel bunke af data, bare for at skabe sig et element, så jeg har tænkt mig at være bedre off hjælp af en række forespørgsel, fordi det er meget mere selektive. Det kommer til at spare mig en masse penge, fordi jeg betale for at læse. Hvis de resultater, der kommer tilbage krydse denne tråd kan være mindre, men jeg betaler for læsning. Så forstå, hvordan på at få det data. Det er meget vigtigt i Dynamo DB. 

Betingede udtryk, det er det, man kan kalde optimistisk låsning. Opdatering Hvis der, eller hvis denne værdi svarer til, hvad jeg angiver. Og hvis jeg har et tidsstempel på en rekord, kunne jeg læse dataene. Jeg kan ændre disse data. Jeg kan gå skrive, at data tilbage til databasen. Hvis nogen har ændret rekord, tidsstemplet kunne have ændret sig. Og på den måde min betingede opdatering kunne sige opdatering hvis tidsstemplet lig dette. Eller opdateringen mislykkes fordi nogen opdateret rekorden i mellemtiden. 

Det er, hvad vi kalder optimistisk låsning. Det betyder, at nogen kan komme ind og ændre det, og jeg har tænkt mig at opdage det når jeg går tilbage til at skrive. Og så kan jeg faktisk læst, at data og sige, åh, skiftede han dette. Jeg har brug for at tage højde for det. Og jeg kan ændre dataene i min registrere og anvende en anden opdatering. Så du kan fange dem trinvis opdateringer, der opstår mellem den tid at du læser de data og den tid du måske skrive data. 

PUBLIKUM: Og filteret udtryk betyder faktisk ikke i antallet eller not-- 

[Indskyde VOICES] RICK Houlihan: Jeg vil ikke få for meget ind i dette. Dette er et reserveret nøgleord. Pundet synspunkt er en reserveret søgeord i Dynamo DB. Hver database har sin egen reserveret navne for samlinger, du ikke kan bruge. Dynamo DB, hvis du angiver et pund foran dette, du kan definere disse navne op over. Dette er en refereres værdi. Det er nok ikke det bedste syntaks til har op der for denne diskussion, fordi det bliver ind i nogle real-- Jeg ville have talt mere om, at der på et dybere niveau. 

Men tilstrækkeligt for at sige, det kunne være forespørgsel scanne hvor de views-- heller pund udsigt er større end 10. Det er en numerisk værdi, ja. Hvis du ønsker, kan vi tale om at efter diskussionen. Okay, så vi får ind nogle scenarier i bedste praksis hvor vi kommer til at tale om nogle apps her. Hvad er tilfælde for Dynamo DB brug. Hvad er design mønstre i Dynamo DB. 

Og det første vi kommer til at snak om, er tingenes internet. Så vi får en masse of-- jeg gætte, hvad der er it-- mere end 50% af trafikken på internettet i disse dage er faktisk genereres af maskiner, automatiserede processer, ikke af mennesker. Jeg mener denne ting denne ting, du bære rundt i lommen, hvor mange data, at den ting er faktisk sende rundt uden dig at vide det er helt fantastisk. Din placering, information om, hvor hurtigt du skal hen. Hvordan tror du, at Google Maps værker når de fortæller dig, hvad trafikken er. Det er fordi der er millioner og millioner af mennesker kørsel rundt med telefoner, der sender data overalt sted hele tiden. Så en af ​​de ting, om denne type data der kommer i, overvåge data, log data, tidsseriedata, er det normalt kun interessant for en lille smule tid. Efter den tid, det er ikke så interessant. Så vi talte om, lad ikke disse tabeller vokse uden grænser. Ideen her er, at jeg måske har fået 24 timer værd af begivenheder i min varme tabel. Og det varme bord vil være hensættelser på et meget højt tempo, fordi det tager en masse data. Det tager en masse data i og jeg læser det en masse. Jeg har fået en masse operation forespørgsler kører mod, at data. 

Efter 24 timer, hey, du ved, hvad, jeg er ligeglad. Så måske hver midnat I roll mit bord over til en ny tabel og jeg deprovision denne tabel. Og jeg vil tage fjernbetjeningen-og WCU er nede, fordi 24 timer senere Jeg kører ikke så mange forespørgsler mod at data. Så jeg har tænkt mig at spare penge. Og måske 30 dage senere gør jeg ikke engang behøver at bekymre sig om det hele. Jeg kunne tage WCU s hele vejen ned til én, fordi du ved, hvad det er aldrig kommer til at få skrevet til. Dataene er 30 dage gamle. Det ændrer aldrig. 

Og det er næsten aldrig kommer til at få læst, så lad os bare tage det RCU ned til 10. Og jeg spare et ton af penge på dette data, og kun betale for mine varme data. Så det er det vigtige ting at kigge på, når man ser på en tidsserie data, der kommer i volumen. Disse er strategier. Nu kunne jeg bare lade det alle gå til den samme tabel og bare lade tabellen vokse. Til sidst, vil jeg se problemer med ydeevnen. Jeg har tænkt mig at nødt til at begynde at arkivere nogle af disse data af bordet, hvad ikke. 

Lad os meget bedre designe din ansøgning så du kan betjene denne måde ret. Så det er bare automatisk i ansøgningen kode. Ved midnat hver nat det ruller tabellen. Måske hvad jeg behøver, er en glidende vindue af 24 timers data. Derefter regelmæssigt jeg ringer af data af bordet. Jeg trimning det med en Cron job, og jeg sætte det på disse andre tabeller, uanset hvad du har brug for. Så hvis en rollover fungerer, det er fantastisk. Hvis ikke, trimme det. Men lad os holde det varmt data væk fra dine kolde data. Det vil spare dig for en masse penge og gøre dine tabeller mere udførelse. Så den næste ting, vi vil tale om, er produktkatalog. Produktkatalog er temmelig almindelig brug tilfælde. Dette er faktisk et meget almindeligt mønster at vi vil se i en række forskellige ting. Du ved, Twitter for eksempel en varm tweet. Alle der kommer og opsigtsvækkende, at tweet. Produktkatalog, fik jeg et salg. Jeg fik en varm salg. Jeg fik 70.000 anmodninger pr andet komme efter et produkt beskrivelse ud af mit produktkatalog. Vi ser dette på detailmarkedet operation ganske lidt. Så hvordan kan vi håndtere det? Der er ingen måde at beskæftige sig med det. Alle mine brugere ønsker at se det samme stykke data. De er kommer ind, samtidigt. Og de er alle gør anmodninger for det samme stykke data. Det giver mig, at genvejstast, at store røde stribe på min diagram, vi ikke kan lide. Og det er, hvad der ligner. Så hele min nøgle plads jeg får hamret i salg elementer. Jeg får intet andre steder. 

Hvordan kan jeg afhjælpe dette problem? Nå, vi afhjælpe dette med cache. Cache, du lægger dybest set en in-memory partition foran databasen. Vi har formået [Uhørligt] cache, hvordan du kan oprette din egen cache, [uhørligt] cache [? d,?] hvad du vil. Sætte det op foran databasen. Og på den måde kan du gemme disse data fra de varme nøgler op i at cache rum og læse cachen. 

Og så de fleste af dine læser begynde at kigge på denne måde. Jeg fik alle disse cache hits heroppe og jeg fik intet foregår hernede fordi databasen sidder bag cache og læser aldrig komme igennem. Hvis jeg ændre dataene i database, jeg er nødt til at opdatere cachen. Vi kan bruge noget ligesom damper til at gøre det. Og jeg vil forklare, hvordan det fungerer. Okay, messaging. E-mail, vi alle bruger e-mail. 

Dette er et temmelig godt eksempel. Vi har fået en slags beskeder bordet. Og vi fik indbakke og udbakke. Dette er, hvad SQL ville ser gerne bygge det indbakke. Vi slags bruge den samme slags strategi til at bruge GSI s, GSI s for min indbakke og min udbakke. Så jeg fik rå budskaber kommer ind i min beskeder bord. Og den første tilgang til dette måtte være, siger, OK, ikke noget problem. Jeg har fået rå beskeder. Beskeder, der kommer [uhørligt], besked-id, det er fantastisk. Det er min unikke hash. Jeg har tænkt mig at lave to GSI s, en til min indbakke, en til min udbakke. Og det første, jeg vil gøre er jeg vil sige min hash nøglen er kommer til at være modtager og Jeg har tænkt mig at arrangere på datoen. Det er fantastisk. Jeg fik min dejlig udsigt her. Men der er et lille problem her. Og du løber ind i dette i relationelle databaser så godt. De kaldte lodret opdeling. Du ønsker at holde din big data væk fra dine små data. 

Og grunden er, fordi jeg skal gå læse elementer til at få attributterne. Og hvis mine organer er alle på her, derefter læse blot et par punkter hvis min krop længde er gennemsnit 256 kilobyte hver, math får temmelig grim. Så siger jeg ønsker at læse Davids indbakke. Davids indbakke har 50 poster. Den gennemsnitlige størrelse og er 256 kilobyte. Her er min konvertering til RCU s er fire kilobyte. 

OK, lad os gå med sidst konsekvent læser. Jeg er stadig spise 1600 RCU s bare at læse Davids indbakke. Av. OK, lad os nu tænke om, hvordan app fungerer. Hvis jeg i en e-mail app og Jeg kigger på min indbakke, og jeg ser på kroppen af ​​hver besked, nej, jeg ser på de resuméer. Jeg kigger på kun overskrifter. Så lad os bygge en tabelstruktur der ligner mere det. 

Så her er de oplysninger at min arbejdsgang behov. Det er i min indbakke GSI. Det er den dato, afsenderen, emnet, og derefter beskeden id, som peger tilbage til beskeder tabellen hvor jeg kan få kroppen. Nå, ville disse være rekord id'er. De vil gerne tilbage til item id'er på Dynamo DB bordet. Hvert indeks altid creates-- altid har elementet ID som en del of-- at kommer med indekset. 

Okay. PUBLIKUM: Det fortæller den, hvor den er gemt? RICK Houlihan: Ja, det fortæller exactly-- det er præcis, hvad den gør. Der står her er min re rekord. Og det vil påpege det tilbage til min re rekord. Nøjagtig. OK, så nu er min indbakke er faktisk meget mindre. Og dette rent faktisk understøtter workflowet af en e-mail app. Så min indbakke, jeg klikker. Jeg går sammen, og jeg klikker på meddelelsen, det er når jeg har brug for at gå få kroppen, fordi jeg har tænkt mig at gå til en anden opfattelse. Så hvis du tænker over MVC type ramme, modelvisning controller. 

Modellen indeholder data, som visningen behov og controlleren interagerer med. Når jeg ændre rammen, når Jeg ændre perspektivet, det er OK at gå tilbage til server og vende modellen, fordi det er hvad brugeren forventer. Når de ændrer synspunkter, det er når vi kan gå tilbage til databasen. Så e-mail, skal du klikke på. Jeg leder efter kroppen. Rundtur. Hent kroppen. 

Jeg læste en masse mindre data. Jeg er kun læser de organer, der David behov, når han har brug for dem. Og jeg er ikke brænde i 1600 RCU bare for at vise sin indbakke. Så nu at-- det er den måde at LSI eller GSI-- Jeg er ked af, GSI, ville arbejde ud. Vi har fået vores hash på modtageren. Vi har fået det område tasten på dato. Og vi har fået de forventede attributter at vi behøver kun at støtte det synspunkt. 

Vi roterer at for udbakken. Hash på afsenderen. Og i det væsentlige, vi har det meget rart, ren visning. Og det er basically-- vi har denne pæne beskeder tabel, der bliver spredt pænt, fordi det er kun hash, hashed besked-ID. Og vi har to indekser, roterer ud af denne tabel. Okay, så ideen her er ikke holde store data og denne lille data sammen. Partition lodret, opdele disse tabeller. Må ikke læse data, du behøver ikke at. Okay, spil. Vi alle gerne spil. Mindst Jeg kan lide spil dengang. Så nogle af de ting at vi beskæftiger os med, når Vi tænker på spil, ikke? Gaming disse dage, især mobil spil, handler om tænkning. Og jeg har tænkt mig at rotere her en lidt væk fra DynamoDB. Jeg har tænkt mig at bringe i nogle af diskussionen omkring nogle af andre AWS teknologier. 

Men ideen om gaming er at tænke om i form af API'er, API'er, der er, generelt HTTP og JSON. Det er hvordan mobile spil slags interagere med deres bagende. De gør JSON udstationering. De får oplysninger, og det er alt, generelt i pæne JSON API'er. 

Ting som får venner, får leaderboardet, udveksle data, brugergenereret indhold, skubbe tilbage til systemet, disse er typer af ting at vi kommer til at gøre. Binary aktiv data, disse data kan ikke sidde i databasen. Dette kan sidde i en objekt butik, right? Men databasen vil ender fortæller systemet, fortæller ansøgningen hvor de skal gå få det. Og uundgåeligt, multiplayer servere, bagenden infrastruktur, og designet til høj tilgængelighed og skalerbarhed. Så disse er ting, som vi alle ønsker i gaming infrastrukturen i dag. 

Så lad os tage et kig på hvad der ligner. Fik en kerne back-end, meget ligetil. Vi har et system, her med flere ledige zoner. Vi talte om AZS som being-- tror af dem som separate datacentre. Mere end et datacenter pr AZ, men det er OK, bare tænke på dem som særskilte data centre, der er geografisk og fejlen isoleret. 

Vi kommer til at have en par EC2 instanser. Vi kommer til at have nogle tilbage ende server. Måske hvis du er en arv arkitektur, men vi er hjælp hvad vi kalder RDS, relationelle database tjenester. Kunne være MSSQL, MySQL, eller sådan noget. Dette er måde en masse applikationer er udformet i dag. 

Nå vi måske ønsker at gå med dette er, når vi skalere. Vi vil gå videre og sætte S3 spanden deroppe. Og at S3 spand, i stedet for at tjene op disse objekter fra vores servers-- vi kunne gøre det. Du sætter alle dine binære objekter på dine servere og du kan bruge dem server forekomster til at tjene, at data op. Men det er temmelig dyrt. 

Bedre måde at gøre, er at gå videre og sætte disse objekter i en S3 spand. S3 er et objekt repositories. Det er bygget specielt til tjener op disse typer af ting. Og lad disse kunder anmode direkte fra disse objekt spande, aflaste serverne. Så vi er begyndt at skalere ud her. 

Nu fik vi brugere over hele verden. Jeg fik brugere. Jeg har brug for at have indhold lokalt placeret tæt på disse brugere, ikke? Jeg har oprettet en S3 spand som min kilde repository. Og jeg vil foran, at med Den CloudFront distribution. 

CloudFront er en cd og en levering af indhold netværk. Dybest set, det tager data, som du angiver og cacher det hele over internettet så brugerne overalt kan have en meget hurtig reaktion, når de anmoder disse objekter. 

Så du får en idé. Du er slags udnytte alle de aspekter af AWS her for at få dette gjort. Og til sidst, vi smider i en auto skalering gruppe. Så vores AC2 forekomster af vores spilservere, da de begynder at få travle og travle og travle, de vil bare spinde en anden Eksempelvis spinde et andet tilfælde spinde en anden instans. Så teknologien AWS har det giver dig angive parametrene omkring hvilken dine servere vil vokse. Så du kan have n antal servere derude på ethvert givet tidspunkt. Og hvis din belastning går væk, de vil skrumpe, vil antallet skrumpe. Og hvis belastningen kommer tilbage, det vil vokse ud igen, elastisk. 

Så dette ser godt ud. Vi har fået en masse EC2 instanser. Vi kan sætte cachen i forsiden af ​​databaserne, forsøge at accelerere databaserne. Den næste trykpunktet typisk folk se er de skalere et spil ved hjælp af en relationsdatabase. Jeez, databasen ydeevne er forfærdeligt. Hvordan kan vi forbedre dette? Lad os prøve at sætte cache foran det. 

Nå, er cachen ikke arbejde så stor i spil, ikke? For spil, skrivning er smertefuldt. Spil er meget skrive tung. Cache fungerer ikke, når du er skriver tungt fordi du har altid fik at opdatere cachen. Du opdaterer cachen, det er irrelevant at caching. Det er faktisk bare ekstra arbejde. 

Så hvor vi går her? Du har fået en stor flaskehals dernede i databasen. Og stedet at gå naturligvis er partitionering. Partitionering er ikke let at gøre, når du er beskæftiger sig med relationelle databaser. Med relationelle databaser, du er ansvarlig for forvaltningen, effektivt, nøglen plads. Du siger brugere mellem A og M gå her, mellem N og Z derned. Og du skifter på tværs af ansøgningen. Så du har at gøre med denne partition datakilde. Du har transaktionelle begrænsninger som ikke spænder partitioner. Du har fået alle former for messiness, at du er beskæftiger sig med dernede forsøger at behandle skalering ud og opbygge en større infrastruktur. Det er bare ikke sjovt. 

PUBLIKUM: Så du siger, at stigende kildepunkter fremskynder processen? RICK Houlihan: Stigende? PUBLIKUM: Source point. RICK Houlihan: Source point? PUBLIKUM: Ud fra de oplysninger, hvor oplysningerne kommer fra? RICK Houlihan: Nej. Hvad jeg siger er at øge Antallet af partitioner i datalageret forbedrer gennemløb. Så hvad der sker her er brugere kommer ind i EC2 instans heroppe, godt, hvis jeg har brug for en bruger det er A til M, vil jeg gå her. Fra N til p, vil jeg gå her. Fra P til Z, vil jeg gå her. 

PUBLIKUM: OK, der så dem er alle gemt i forskellige noder? 

RICK Houlihan: Ja. Tænk på disse som forskellige siloer af data. Så du har at gøre dette. Hvis du forsøger at gøre dette, hvis du prøver at skalere på en relationel platform, dette er hvad du laver. Du tager af data og du skære det ned. Og du partitionering det på tværs flere forekomster af databasen. Og du administrerer alt, på ansøgningen tier. Det er ikke sjovt. Så hvad gør vi ønsker at gå? Vi ønsker at gå DynamoDB, fuldt styret, NoSQL datalager, bestemmelse gennemløb. Vi bruger sekundære indekser. Det er grundlæggende HTTP-API og omfatter dokument support. Så du behøver ikke at bekymre dig om noget af det partitionering. Vi gør det hele for dig. Så nu, i stedet, du bare skrive til bordet. Hvis tabellen skal fordeles, der sker bag kulisserne. Du er helt isoleret fra det som en udvikler. Så lad os tale om nogle af de use cases at vi løber ind i spil, fælles gaming scenarier, leaderboard. Så du har fået brugere kommer ind, de BoardNames, at de er om, at scores for denne bruger. Vi kan hashing på BrugerID, og så har vi rækkevidde på spillet. Så hver bruger ønsker at se alle spillet han har spillet og hele hans top score på tværs af alle spillet. Så det er hans personlige rangliste. 

Nu vil jeg gå i, og jeg vil gerne get-- så jeg får disse personlige leaderboards. Hvad jeg ønsker at gøre, er at gå få den øverste score på tværs af alle brugere. Så hvordan gør jeg det? Når min rekord hashet på UserID, lå på spillet, godt jeg har tænkt mig at gå videre og omstrukturere, oprette en GSI, og jeg har tænkt mig at omstrukturere disse data. 

Nu vil jeg hash på BoardName, som er spillet. Og jeg har tænkt mig at ligge på den øverste score. Og nu har jeg lavet forskellige spande. Jeg bruger det samme bord, samme regnskabspost data. Men jeg opretter en spand, der giver mig en sammenlægning af top score ved spillet. 

Og jeg kan forespørge tabellen at få disse oplysninger. Så jeg har sat, at forespørgslen mønster op til understøttes af en sekundær indeks. Nu kan de sorteres efter BoardName og sorteret efter topscore, afhængigt. Så du kan se, er disse typer af use cases, du får i spil. En anden god brug tilfælde, vi får i spil er priser og hvem der vandt priser. Og det er en stor brug sag hvor vi kalder sparsomme indekser. Sparsomme indekser er evne til at generere et indeks, der ikke nødvendigvis indeholder hvert enkelt element på bordet. Og hvorfor ikke? Fordi attribut, der er at være indekseret eksisterer ikke for hver genstand. 

Så i dette særlige bruger sagen, jeg siger, ved du hvad, jeg vil skabe en attribut kaldet Award. Og jeg har tænkt mig at give hver bruger der har en pris, der attribut. Brugere, der ikke har priser er ikke vil have, at attribut. Så når jeg opretter indeks, de eneste brugere der kommer til at vise op i indekset er dem, der rent faktisk har vundet priser. Så det er en fantastisk måde at være i stand at skabe filtreret indekser, er meget, meget selektiv, der ikke gør nødt til at indeksere hele tabellen. 

Så vi får lav på tid her. Jeg har tænkt mig at gå videre og springe ud og springe dette scenario. Snakke lidt om-- 

PUBLIKUM: Kan jeg stille et hurtigt spørgsmål? Den ene er at skrive tung? RICK Houlihan: Hvad er? PUBLIKUM: Skriv tung. RICK Houlihan: Skriv tung. Lad mig se. 

PUBLIKUM: Eller er, at ikke noget du kan bare stemme i løbet af få sekunder? RICK Houlihan: Vi går gennem afstemninger scenario. Det er ikke så slemt. Har du fyre har et par minutter? OKAY. 

Så vi taler om at stemme. Så realtid afstemninger, vi har krav til afstemning. Krav er, at vi tillader hver person til at stemme kun én gang. Vi ønsker ingen at være i stand at ændre deres stemme. Vi ønsker realtid sammenlægning og analytics til demografi at vi kommer til at være viser at brugerne på sitet. 

Tænk på dette scenario. Vi arbejder meget af virkeligheden TV viser, hvor de er gør disse nøjagtige type ting. Så du kan tænke på det scenario, Vi har millioner og atter millioner af teenagepiger der med deres mobiltelefoner og afstemning, og afstemning, og stemme for hvem de er finde på at være den mest populære. Så dette er nogle af de krav, vi løber tør. 

Og så først tage løse dette problem ville være at bygge en meget simpel applikation. Så jeg har fået denne app. Jeg har nogle vælgere derude. De kommer ind, de ramte afstemningen app. Jeg har fået nogle rå stemmer bord Jeg vil bare dumpe disse stemmer ind. Jeg vil have nogle aggregat stemmer tabel, vil gøre mine analytics og demografi, og vi vil sætte alt dette i der. 

Og det er fantastisk. Livet er godt. Livets gode, indtil vi finder ud af, at der er altid kun en eller to mennesker, der er populære i et valg. Der er kun én eller to ting at folk virkelig bekymrer sig om. Og hvis du stemme på skala, pludselig er jeg vil være hamre helvede ud af to kandidater, en eller to kandidater. Et meget begrænset antal emner folk finde på at være populære. 

Dette er ikke et godt design mønster. Dette er faktisk en meget dårlig mønster fordi det skaber præcis, hvad vi talte om som var genvejstaster. Genvejstaster er noget, vi ikke kan lide. 

Så hvordan kan vi løse det? Og virkelig, den måde at løse dette er ved at tage de ansøgerlande spande og for hver kandidat, vi har, vi kommer til at tilføje en tilfældig værdi, noget, som vi kender, tilfældige værdi mellem en og 100, mellem 100 og 1.000, eller mellem en og 1000, men mange tilfældige værdier, du ønsker at vedhæfte på enden af ​​denne kandidat. 

Og hvad har jeg virkelig gjort så? Hvis jeg bruger den kandidat-id, som spanden til aggregerede stemmer, hvis jeg har tilføjet en tilfældig nummer til slutningen af ​​det, Jeg har oprettet nu 10 spande, en hundrede spande, tusind spande at jeg sammenlægning stemmer på tværs. 

Så jeg har millioner og millioner, og millioner af plader, der kommer i for disse kandidater, jeg nu at sprede disse stemmer på tværs af Candidate A_1 gennem Candidate A_100, fordi hver gang en afstemning kommer ind, Jeg genererer en tilfældig værdi mellem en og 100. Jeg krydse det på enden af kandidat, persons stemme for. Jeg dumping det ind i denne spand. 

Nu på bagsiden, jeg kender at jeg fik hundrede spande. Så når jeg ønsker at gå videre og samle stemmerne, Jeg læste fra alle disse spande. Så jeg gå videre og tilføje. Og så ved jeg scatter indsamle hvor jeg går ud og siger hej, ved du hvad, denne kandidat nøgle rum er over hundrede spande. Jeg har tænkt mig at samle alle de stemmer fra de hundrede spande. Jeg har tænkt mig at samle dem, og jeg har tænkt mig at sige, Kandidat A har nu samlet stemme til at tælle af x. 

Nu både skrive forespørgsel og læse forespørgslen er pænt fordelt fordi jeg skriver på tværs og jeg læser på tværs af hundredvis af nøgler. Jeg er ikke at skrive og ved at gennemgå en nøgle nu. Så det er en stor mønster. 

Dette er faktisk sandsynligvis en af de vigtigste design mønstre for skalaen i NoSQL. Du vil se denne type mønster i hver smag. MongoDB, DynamoDB, det ikke sag, vi alle nødt til at gøre dette. Fordi når du beskæftiger sig med disse enorme aggregeringer, du nødt til at finde ud af en måde at sprede dem ud over spande. Så dette er den måde, du gør det. Okay, så hvad du laver lige nu er du handler off læse omkostninger til skrive skalerbarhed. Udgifterne til mit read er lidt mere kompliceret og jeg er nødt til at gå læse fra en hundred spande i stedet for én. Men jeg er i stand til at skrive. Og min gennemløb, min skrive gennemløb er utroligt. Så det er som regel en værdifuld teknik til skalering DynamoDB, eller enhver NoSQL database for den sags skyld. Så vi regnede ud, hvordan at skalere det. Og vi regnede hvordan fjerne vores genvejstaster. Og det er fantastisk. Og vi fik denne nice system. Og det har givet os meget korrekt afstemning fordi vi har rekord stemme de-dupe. Den er bygget ind DynamoDB. Vi talte om betingede rettigheder. 

Når en vælger kommer ind, sætter en indsats på bordet, de indsætter med deres vælgere id, hvis de forsøger at indsætte en anden stemme, Jeg gør en betinget skrive. Sig kun skrive dette hvis det ikke eksisterer. Så så snart jeg kan se, at at afstemningen er ramt tabellen, ingen andre kommer til at være stand til at sætte deres stemme i. Og det er fantastisk. Og vi forøgelse vores kandidat tællere. Og vi gør vores demografi og alt det der. Men hvad sker der, hvis min ansøgning falder over? Nu pludselig stemmer er kommer ind, og jeg ved ikke, om de får bearbejdet i mine analytics og demografi længere. Og når ansøgningen kommer op igen, hvordan fanden gør jeg, hvad stemmer har blevet behandlet og hvor skal jeg starte? 

Så dette er et reelt problem, når du begynde at se på denne type scenarie. Og hvordan løser vi det? Vi løser det med, hvad vi kalder DynamoDB Vandløb. Vandløb er en tid bestilles og partitioneret ændring log over hver adgang til tabellen, hver skriver adgang til tabellen. Alle data, der er skrevet til tabel viser op på åen. 

Det er dybest set en 24 timers kø. Elementer ramte åen, de lever i 24 timer. De kan læses flere gange. Garanteret at blive leveret kun én gang på strømmen, kunne læses n antal gange. Så uanset hvor mange processer, du ønsker at forbruge, at data, kan du forbruge det. Det vil blive vist hver opdatering. Hver skrive vil kun vises en gang på åen. Så du behøver ikke at bekymre dig om behandling af det to gange fra den samme proces. 

Det er strengt bestilt per post. Når vi siger tid bestilt og delt, du vil se pr partition på åen. Du vil se elementer, opdateringer i orden. Vi er ikke garanterer på åen, at du er kommer til at få hver transaktion i størrelsesordenen på tværs varer. 

Så vandløb er idempotent. Må vi alle ved, hvad idempotent betyder? Idempotent betyder, at du kan gøre det i og over, og igen. Resultatet kommer til at være den samme. 

Vandløb er idempotent, men de skal være spillet fra udgangspunktet, uanset hvor du vælger, til enden, eller de vil ikke medføre i de samme værdier. 

Samme ting med MongoDB. MongoDB har en konstruktion de kalder OPLOG. Det er nøjagtig den samme konstruktion. Mange NoSQL databaser har denne konstruktion. De bruger det til at gøre tingene Ligesom replikation, hvilket er præcis, hvad vi gør med vandløb. PUBLIKUM: Måske en kætterske spørgsmål, men du taler om apps gør ned en så videre. Er vandløb garanteret aldrig eventuelt gå ned? RICK Houlihan: Ja, vandløb er garanteret til aldrig gå ned. Vi administrerer infrastrukturen bag. vandløb automatisk implementere i deres auto skalering gruppe. Vi vil gå gennem en lille lidt om hvad der sker. 

Jeg skal ikke sige, at de ikke er garanteret aldrig gå ned. Elementerne er garanteret at dukke op i åen. Og strømmen vil være tilgængelig. Så hvad går ned eller kommer tilbage up, der sker nedenunder. Det covers-- det er OK. Okay, så du får forskellige view typer væk fra skærmen. Udsigten typer, der er vigtige for en programmør typisk er, hvad var det? Jeg får den gamle opfattelse. Når en opdatering rammer bordet, det vil skubbe gamle henblik på strømmen så data kan arkivere, eller ændre kontrol, ændre identifikation, ændring ledelse. 

Det nye billede, hvad det er nu efter opdateringen, det er en anden type visning du kan få. Du kan få både de gamle og nye billeder. Måske jeg vil have dem begge. Jeg vil gerne se, hvad det var. Jeg ønsker at se, hvad det ændret til. 

Jeg har en compliance typen proces, der kører. Den har brug for at kontrollere, at når disse ting ændrer sig, at de er inden for visse grænser eller inden for visse parametre. 

Og så måske kun jeg brug for at vide hvad der er ændret. Jeg er ligeglad, hvad post ændret. Jeg behøver ikke at have behov for at vide hvilke attributter ændret. Jeg har bare brug for at vide, at produkterne sendes rørt. Så det er disse typer af synspunkter at du får ud af åen og du kan interagere med. 

Det program, der forbruger strømmen, dette er slags af den måde det fungerer. DynamoDB klient beder til sende data til tabellerne. Vandløb implementere på det, vi kalder skårene. Shards skaleres uafhængigt af bordet. De behøver ikke line op helt til skillevægge i din tabel. Og grunden er fordi de linje op til kapaciteten, den aktuelle kapacitet tabellen. 

De implementere i deres egen auto skalering gruppe, og de begynder at spinde ud afhængigt hvor mange skrivninger kommer ind, hvor mange reads-- virkelig det skriver. Der er ingen reads-- men hvordan mange skrivninger kommer i. 

Og så på ryggen ende, vi har, hvad vi kalde en KCL eller Kinesis Client Library. Kinesis er en strøm af data teknologi fra Amazon. Og vandløb er bygget på det. 

Så du bruger en KCL aktiveret program til at læse åen. Kinesis Client Library faktisk forvalter arbejderne for dig. Og det gør også nogle interessante ting. Det vil skabe nogle tabeller op i dit DynamoDB tablespace at spore, hvilke emner er blevet behandlet. Så på denne måde, hvis det falder tilbage, hvis det falder igen og kommer og får stod op igen, kan det afgøre, hvor var det i behandlingen af ​​åen. 

Det er meget vigtigt, når du taler om replikation. Jeg har brug for at vide, hvad data blevet behandlet og hvilke data der endnu skal bearbejdes. Så KCL bibliotek til vandløb vil give dig en masse af denne funktionalitet. Det tager sig af alle husholdning. Det står op en arbejdstager for hver Shard. Det skaber en administrativ tabel for hver Shard, for hver arbejdstager. Og som de arbejdstagere brand, de opretholder disse tabeller så du ved denne rekord blev læst og behandlet. Og derefter den måde, hvis processen dør og kommer online igen, Det kan genoptage højre, hvor den tog fart. 

Så vi bruger dette for cross-region replikation. En masse kunder har behov for at flytte data eller dele af deres datatabeller rundt til forskellige regioner. Der er ni regioner i hele verden. Så der kan være en need-- I kan have brugere i Asien, brugere i østkysten af ​​USA. De har forskellige data, skal lokalt fordelt. Og måske en bruger flyver fra Asien over til USA, og jeg ønsker at replikere hans data med ham. Så da han får ud af flyet, har han en god oplevelse ved hjælp af hans mobile app. 

Du kan bruge cross-regionen replikering bibliotek til at gøre dette. Dybest set har vi tilvejebragt to teknologier. Man er en konsol applikation, du kan stå op på din egen EC2 instans. Det kører rent replikation. Og så gav vi dig biblioteket. Biblioteket, du kan bruge til at bygge din egen ansøgning, hvis du ønsker at gøre skøre ting med det data-- filter, replikere kun en del af det, rotere data, flytte den ind i en anden tabel, så videre og så videre. Så det er lidt af, hvad der ligner. 

DynamoDB Streams kan være behandles af det, vi kalder Lambda. Vi nævnte en lille smule om begivenhed drevet ansøgning arkitekturer. Lambda er en nøglekomponent i det. Lambda er kode, der brande på efterspørgslen som reaktion på en bestemt begivenhed. En af disse begivenheder kunne være en rekord optræder på åen. Hvis en post vises på åen, vi vil kalde denne Java-funktion. Nå, det er JavaScript og Lambda understøtter node.js, Java, Python, og vil snart understøtte andre sprog så godt. Og nok til at sige, det er ren kode. skrive i Java, du definerer en klasse. Du skubber JAR op i Lambda. Og så skal du angive, hvilken klasse at ringe reaktion på hvilken begivenhed. Og så Lambda-infrastruktur bag der vil køre denne kode. 

Denne kode kan behandle optegnelser off åen. Det kan gøre noget den vil med det. I dette særlige eksempel alt er vi virkelig gør, er at logge attributterne. Men dette er blot kode. Kode kan gøre noget, ikke? 

Så du kan rotere disse data. Du kan oprette et derivat visning. Hvis det er et dokument struktur, du kan flade struktur. Du kan oprette alternative indekser. Alle former for ting, du kan gøre med DynamoDB Streams. 

Og virkelig, det er hvad der ligner. Så du får disse opdateringer kommer. De kommer fra strengen. De er læst af Lambda funktionen. De er at dreje data skubbe den op i afledte tabeller, anmelde eksterne systemer af forandring, og skubbe data i ElastiCache. 

Vi talte om, hvordan man kan sætte cachen foran databasen for at salget scenario. Tja, hvad sker der, hvis jeg opdatere varebetegnelse? Tja, hvis jeg havde en Lambda funktion, der kører på det bord, hvis jeg opdatere elementet beskrivelse, det vil afhente posten fra åen, og det vil opdatere ElastiCache eksempel med de nye data. Så det er en masse hvad vi gør med Lambda. Det er lim kode, stik. Og det faktisk giver evnen til at iværksætte og at køre meget komplekse applikationer uden en dedikeret server infrastruktur, som er virkelig cool. 

Så lad os gå tilbage til vores realtid stemme arkitektur. Dette er nyt og forbedret med vores vandløb og KCL aktiveret program. Samme som før, vi kan håndtere enhver omfanget af valget. Vi kan godt lide dette. Vi laver ud scatter samler på tværs af flere spande. Vi har fået optimistisk låsning foregår. Vi kan holde vores vælgere fra at ændre deres stemmer. De kan kun stemme én gang. Det er fantastisk. Real-time fejltolerance, skalerbar sammenlægning nu. Hvis ting vælter, det ved, hvor at genstarte sig selv når det kommer tilbage, fordi vi bruger den KCL app. Og så kan vi også bruge det KCL program til at skubbe data ud at rødforskydning for andre app analytics, eller brug De elastiske MapReduce at køre realtid streaming aggregeringer off af disse data. 

Så dette er ting, vi har ikke talt om meget. Men de er ekstra teknologier, der kommer at bære, når du søger på disse typer af scenarier. 

Okay, så det er om analytics med DynamoDB streams. Du kan indsamle de-dupe data, gøre alle former af nice stuff, aggregerede data i hukommelse, oprette disse afledte tabeller. Det er en kæmpe brug sag at en masse kunder er involveret i, idet den indlejrede egenskaber i disse dokumenter JSON og skabe yderligere indekser. 

Vi er i slutningen. Tak fordi du bærer med mig. Så lad os tale om henvises arkitektur. DynamoDB sidder i midten af ​​så meget af AWS infrastruktur. Dybest set kan du tilslutte den op til noget, du ønsker. Applikationer bygget ved hjælp af Dynamo omfatter Lambda, ElastiCache, CloudSearch, skubbe data ud i Elastic MapReduce, import eksport fra DynamoDB i S3, alle former for arbejdsgange. Men sandsynligvis den bedste ting at tale om, og det er hvad der virkelig interessant er, når vi taler om drevet event applikationer. 

Dette er et eksempel på et internt projekt at vi har, hvor vi er faktisk udgivelse at samle undersøgelsens resultater. Så i en e-mail link, vi sender ud, er der ll være lidt link siger klik her for at reagere på undersøgelsen. Og når en person klikker dette link, hvad der sker er de trække ned en sikker HTML undersøgelse form fra S3. Der er ingen server. Dette er blot et S3 objekt. 

Denne formular kommer op, indlæser op i browseren. Det har fået Backbone. Det har fået kompleks JavaScript at det kører. Så det er meget rig ansøgning kører i kundens browser. De ved ikke, at de ikke er interagere med en bagende server. På dette tidspunkt, det hele browseren. 

De offentliggør resultaterne til, hvad vi kalder Amazon API Gateway. API Gateway er simpelthen en web API at du kan definere og tilslutte til hvad du vil. I dette særlige tilfælde, er vi hooked op til en Lambda funktion. 

Så mit POST operation er sker med ingen server. Dybest set, at API Gateway sidder der. Det koster mig intet indtil folk begynde at sende til det, ikke? Lambda-funktionen bare sidder der. Og det koster mig intet indtil folk begynder at ramme den. Så du kan se, da lydstyrken stiger, det er når afgifterne kommer. Jeg er ikke kører en server 7/24. 

Så jeg trækker formularen ned fra spanden, og jeg sender gennem API Gateway i Lambda-funktionen. Og så Lambda funktion siger, du ved hvad, jeg har fået nogle PIIs, nogle personligt identificerbare oplysninger i disse responser. Jeg fik kommentarer fra brugerne. Jeg har e-mail adresser. Jeg har brugernavne. 

Lad mig opdele denne off. Jeg har tænkt mig at generere nogle metadata off denne rekord. Og jeg har tænkt mig at skubbe metadata i DynamoDB. Og jeg kunne kryptere alle data og skub den ind DynamoDB hvis jeg vil. Men det er lettere for mig, i dette bruger sagen, til at gå videre en sige, Jeg har tænkt mig at skubbe rådata i en krypteret S3 bucket. Så jeg bruger bygget i S3 server side kryptering og Amazons Key Management Service, så jeg har en nøgle, der kan rotere på en regelmæssig interval, og jeg kan beskytte at data PII som en del af hele denne arbejdsgang. 

Så hvad har jeg gjort? Jeg har netop indsat en hel ansøgning, og jeg har ingen server. Så er hvad begivenhed drevet ansøgning arkitektur gør for dig. 

Nu, hvis du tænker over brugen tilfældet for denne-- vi har andre kunder jeg taler til ca. netop arkitektur, der køre fænomenalt store kampagner, der ser på dette og gå, åh min. Fordi nu, kan de dybest set skubbe det derude, lad kampagnen bare sidde der indtil det lanceres, og ikke behøver at bekymre dig en figen om hvilken slags infrastruktur vil være der for at støtte den. Og så så snart at kampagnen er gjort, det er ligesom infrastrukturen lige straks går væk fordi der virkelig er ingen infrastruktur. Det er bare kode, der sidder på Lambda. Det er bare data, der sidder i DynamoDB. Det er en fantastisk måde at bygge applikationer. 

PUBLIKUM: Så er det mere flygtig, end det ville være hvis det blev gemt på en faktiske server? 

RICK Houlihan: Absolut. Fordi det serversubsystem skulle være en 7/24. Det skal være til rådighed for nogen til at reagere på. Nå gæt hvad? S3 findes 7/24. S3 altid reagerer. Og S3 er meget, meget god ved betjener op objekter. Disse objekter kan være HTML-filer, eller JavaScript-filer, eller hvad du ønsker. Du kan køre meget rige webapplikationer ud af S3 spande, og folk gør. 

Og så er ideen her er at komme væk fra den måde vi plejede at tænke over det. Vi er alle bruges til at tænke i form af servere og værter. Det handler ikke om det længere. Det handler om infrastruktur som kode. Implementer koden til skyen og Lad skyen køre det for dig. Og det er, hvad AWS forsøger at gøre. 

PUBLIKUM: Så dit guld box i midten af API Gateway ikke server-lignende, men i stedet er bare-- 

RICK Houlihan: Du kan tænke af det som server facade. Alt det er, er det vil tage en HTTP anmode om og knytte det til en anden proces. Det er alt, den gør. Og i dette tilfælde, vi kortlægger det til en Lambda funktion. Okay, så det er alt, jeg fik. Mange tak. Det er jeg glad for. Jeg ved, at vi vil have en lille smule over tid. Og forhåbentlig jer fik en lille smule information at du kan tage væk i dag. Og jeg undskylder, hvis jeg gik over nogle af jeres hoveder, men der er en god masse fundamental grundlæggende viden som jeg synes er meget værdifuld for dig. Så tak for at have mig. [BIFALD] PUBLIKUM: [uhørligt] er, når du sagde du måttet gå igennem ting fra begyndelsen til slutningen at få de rigtige værdier eller de samme værdier, hvordan ville værdierne ændre sig, hvis [uhørligt]. 

RICK Houlihan: Åh, idempotent? Hvordan ville værdierne ændre sig? Tja, for hvis jeg ikke køre det hele vejen til enden, så jeg ved ikke, hvilke ændringer blev foretaget i den sidste mil. Det kommer ikke til at være den samme data som hvad jeg så. PUBLIKUM: Åh, så du bare har ikke fået hele input. RICK Houlihan: Right. Du skal gå fra start til ende, og så er det vil være en konsistent tilstand. Afkøle. 

PUBLIKUM: Så du viste os DynamoDB kan gøre dokument eller tasten værdi. Og vi har brugt meget tid på nøgle værdi med en hash og de måder at vende den rundt. Når du kigget på disse tabeller, er, at efterlader dokumentet fremgangsmåde? 

RICK Houlihan: Jeg ville ikke sige overlade det bagefter. 

PUBLIKUM: De blev separeret fra til-- 

RICK Houlihan: Med dokumentet tilgang, dokumenttypen i DynamoDB bare tænker på som en anden attribut. Det er en egenskab, som indeholder en hierarkisk datastruktur. Og derefter i de forespørgsler, kan du bruge egenskaberne af disse objekter ved hjælp Object Notation. Så jeg kan filtrere på en indlejret ejendom JSON dokumentet. PUBLIKUM: Så enhver tid, jeg gør et dokument tilgang, Jeg kan slags ankommer til tabular-- PUBLIKUM: Absolut. Publikum: --indexes og ting, du bare talt om. RICK Houlihan: Yeah, det indekser og alt det, når du ønsker at indeksere egenskaber af JSON, den måde, at vi ville have at gøre det er, hvis du indsætter et JSON objekt eller et dokument, ind i Dynamo, ville du bruge streams. Vandløb vil læse input. Du vil få det JSON objekt, og du ville sige OK, hvad er ejendommen Jeg ønsker at indeksere? 

Du opretter et derivat bord. Nu det er den måde, det fungerer lige nu. Vi tillader ikke at indeksere direkte disse egenskaber. 

PUBLIKUM: Tabularizing dine dokumenter. 

RICK Houlihan: Præcis, udfladning det, tabularizing det, nøjagtigt. Det er, hvad du gør med det. 

PUBLIKUM: Tak. 

RICK Houlihan: Jep, absolut, tak. PUBLIKUM: Så det er lidt Mongo møder REDIS classifers. 

RICK Houlihan: Ja, det er meget sådan. Det er en god beskrivelse af det. Afkøle.