>> [MUSIC SPILLE]
RICK Houlihan: All right.
Hei alle sammen.
Mitt navn er Rick Houlihan.
Jeg er en senior rektor løsningsarkitekt på AWS.
Jeg fokuserer på NoSQL og DynamoDB teknologier.
Jeg er her i dag for å snakke med du litt om dem.
>> Min bakgrunn er primært i datalaget.
Jeg tilbrakte halve min utvikling karriere skriver database,
datatilgang, løsninger for ulike bruksområder.
Jeg har vært i Cloud virtualisering for ca 20 år.
Så før Cloud var Cloud, vi pleide å kalle det utility computing.
Og ideen var, er det som PG & E, du betaler for det du bruker.
I dag kaller vi det skyen.
>> Men i løpet av de årene jeg har jobbet for et par selskaper
du har sikkert aldri hørt om.
Men jeg har samlet en liste over teknisk prestasjoner, tror jeg du ville si.
Jeg har åtte patenter i Cloud-systemer virtualisering, mikroprosessor design,
kompleks hendelse behandling, og andre områder også.
>> Så disse dager, fokuserer jeg mest på NoSQL teknologier og neste generasjon
database.
Og det er som regel hva jeg skal å være her å snakke med dere i dag om.
Så hva du kan forvente fra denne sesjonen,
vi vil gå gjennom en kort historie med databehandling.
Det er alltid nyttig å forstå hvor vi kom fra
og hvorfor vi er der vi er.
Og vi skal snakke litt litt om NoSQL teknologi
fra et fundamentalt synspunkt.
>> Vi vil få inn noen av de DynamoDB innvendige.
DynamoDB er AWS er ​​ingen smak.
Det er et fullstendig styrt og hosted NoSQL løsning.
Og vi skal snakke litt om bord struktur, APIer, datatyper, indekser,
og noen av de innvendige av at DynamoDB teknologi.
Vi vil få inn noen av design mønstre og beste praksis.
Vi skal snakke om hvordan du bruker denne teknologien for noen
av dagens programmer.
Og så får vi snakke litt om utviklingen eller fremveksten
av et nytt paradigme i programmering kalles hendelsesdrevne applikasjoner
og hvordan DynamoDB spiller i det også.
Og vi vil gi dere en liten bit av en referansearkitektur diskusjon
slik at vi kan snakke om noen av måtene du kan bruke DynamoDB.
>> Så først off-- dette er et spørsmål Jeg hører mye er, hva som er en database.
Mange mennesker tror de vet hva en database er.
Hvis du Google, vil du se dette.
Det er en en strukturert sett av data holdt i en datamaskin, spesielt en som
er tilgjengelig på forskjellige måter.
Jeg antar det er en god Definisjonen av en moderne database.
Men jeg liker det ikke, fordi det innebærer et par ting.
Det innebærer struktur.
Og det innebærer at det er på en datamaskin.
Og databaser gjorde ikke alltid eksistere på datamaskiner.
Databaser faktisk eksisterte på mange måter.
>> Så en bedre definisjon av en Databasen er noe sånt som dette.
En database er en organisert mekanisme for lagring, håndtering,
og hente informasjon.
Dette er fra About.com.
Så jeg liker dette fordi det egentlig snakker om en database være et oppbevaringssted,
et oppbevaringssted for informasjon, ikke nødvendigvis
noe som sitter på en datamaskin.
Og gjennom historien, vi har ikke alltid hatt datamaskiner.
>> Nå, hvis jeg spør den gjennomsnittlige utbygger i dag hva som er
en database, er at svaret jeg får.
Et sted jeg kan stikke ting.
Høyre?
Og det er sant.
Men det er uheldig.
Fordi databasen er virkelig grunnlaget for den moderne app.
Det er stiftelsen av hver søknad.
Og hvordan du bygger som database, hvordan du strukturere
at data kommer til å diktere hvordan det programmet utfører som du skalerer.
>> Så mye av min jobb i dag arbeider med hva
skjer når utviklere ta denne tilnærmingen
og håndtere kjølvannet av et program som
er nå skalering utover den opprinnelige intensjon og lider av dårlig design.
Så forhåpentligvis når du gange unna i dag, vil du
har et par verktøy i beltet som vil holde deg
fra å gjøre de samme feilene.
Greit.
Så la oss snakke om en liten bit av tidslinjen av databaseteknologi.
Jeg tror jeg leste et artikkelen er ikke så lenge siden
og det sa noe på lines-- det er en veldig poetisk statement.
Det sa historien databehandling er
full av høye vannmerker av data overflod.
OK.
Nå, jeg antar det er slags sant.
Men jeg faktisk ser på er som historien er faktisk fylt
med høy vannmerke av data press.
På grunn av at datahastigheten Inntak aldri går ned.
Det går bare opp.
>> Og innovasjon oppstår når vi se data press, noe som
er mengden av data som er nå i å komme inn i systemet.
Og det kan ikke behandles effektivt, enten i tid eller i pris.
Og det er når vi starter å se på data trykk.
>> Så når vi ser på første database, dette
er det en som var mellom våre ører.
Vi er alle født med det.
Det er en fin database.
Den har en høy tilgjengelighet.
Det er alltid på.
Du kan alltid få det.
>> Men det er enkelt bruker.
Jeg kan ikke dele mine tanker med deg.
Du kan ikke få mine tanker når du vil ha dem.
Og deres abilitiy er ikke så bra.
Vi glemmer ting.
Hver nå og da, en av oss blader og går videre til en annen tilværelse
og vi mister alt som var i denne databasen.
Så det er ikke alt som godt.
>> Og det fungerte bra over tid da vi var tilbake i dag
når alt vi virkelig trengte å vite er hvor skal vi gå på i morgen
eller der vi samler den beste maten.
Men som vi begynte å vokse som en sivilisasjon og regjeringen startet
å bli til, og bedrifter begynte å utvikle seg,
vi begynte å innse vi trenger litt mer enn hva
vi kunne sette i vårt hode.
Greit?
>> Vi trengte systemer av posten.
Vi trengte steder å kunne lagre data.
Så vi begynte å skrive dokumenter, lage biblioteker og arkiver.
Vi begynte å utvikle en systemet en hovedbok regnskap.
Og at ordningen med hovedbok telling kjørte hele verden i mange århundrer,
og kanskje til og med årtusener som vi slags vokste til et punkt
hvor dataene belastning gått evnen til disse systemene
å være i stand til å inneholde det.
>> Og dette faktisk skjedde på 1880-tallet.
Høyre?
I 1880 US Census.
Dette er virkelig der vende punkt moderne databehandling.
Dette er punktet hvilken mengden av data
som ble samlet inn av USAs regjering kom til et punkt
der det tok åtte år å behandle.
>> Nå, åtte years-- som du vet, den folketellingen
går hver 10 years-- så det er ganske åpenbart at etter tid vi
fikk 1890 folketelling, den mengde data som
skulle bli behandlet av regjeringen var
kommer til å overstige 10 årene at det ville ta å lansert den nye folketellingen.
Dette var et problem.
>> Så en fyr som heter Herman Hollerith kom sammen
og han oppfant enhet posten punsj kort, punsj kortleser, klippekort
tabulator, og sammenstilling av mekanismene for denne teknologien.
Og at selskapet som han dannet på tid, sammen med et par andre,
faktisk ble en av bærebjelkene i et lite selskap vi kjenner i dag kalt IBM.
>> Så IBM opprinnelig var i databasen virksomhet.
Og det er virkelig hva de gjorde.
De gjorde databehandling.
>> Som så spredning av slag kort, en genial mekanismer
for å være i stand til å utnytte denne teknologi for å hente fra sorterte resultatsett.
Du kan se på dette bildet der har vi en little--
det er litt small-- men du kan se en svært genial mekanisk mekanisme
hvor vi har et slag kort dekk.
Og noen tar en liten skrutrekker
og stikker gjennom slots og løfte den opp
å få den kampen, som sortert resultater innstilt.
>> Dette er en samling.
Vi gjør dette hele tiden dag i datamaskinen,
hvor du gjør det i databasen.
Vi pleide å gjøre det manuelt, ikke sant?
Folk setter disse tingene sammen.
Og det var proliferasjonen av disse hullkort
inn i det vi kalte data trommer og data hjulene, papir tape.
>> Databehandlingsindustrien tok en leksjon fra spilleren pianoer.
Spiller pianoer tilbake på den århundreskiftet
pleide å bruke papirruller med spalter på å fortelle det som tastene for å spille.
Slik at teknologien ble tilpasset slutt å lagre digitale data,
fordi de kunne sette disse dataene på disse papir tape hjulene.
>> Nå, som et resultat av data ble actually-- hvordan
du tilgang til denne informasjonen var direkte avhengig av hvor du har lagret det.
Så hvis jeg legger data på en tape, Jeg hadde tilgang til data lineært.
Jeg måtte rulle hele båndet for å få tilgang til alle data.
Hvis jeg legger data i slag kort, jeg kunne få tilgang til det
i litt mer tilfeldig mote, kanskje ikke så raskt.
>> Men det var begrensninger i hvordan vi tilgang til data basert på hvordan ble lagret.
Og så dette var et problem går inn i 50-tallet.
Igjen kan vi begynne å se at når vi utvikle nye teknologier for å behandle
dataene, høyre, åpner det opp døren for nye løsninger,
for nye programmer, nye applikasjoner for at data.
Og virkelig, styresett kan ha vært årsaken
Derfor har vi utviklet noen av disse systemene.
Men virksomheten ble raskt driveren bak utviklingen
av den moderne database og den moderne filsystemet.
>> Så det neste som kom opp var på 50-tallet
var filsystemet og Utviklingen av direktetilgangs lagring.
Dette var vakkert.
Nå, alle plutselig, kan vi sette vår filer hvor som helst på disse harddisker
og vi får tilgang til denne informasjonen tilfeldig.
Vi kan analysere det informasjon ut av filer.
Og vi løste all verdens problemer med databehandling.
>> Og det varte omtrent 20 eller 30 år inntil utviklingen
av relasjonsdatabasen, som er når verden vi bestemte oss nå
trenger å ha et depot som nederlagene bre av data på tvers av filen
systemer som vi har bygget. Høyre?
For mye data fordelt på for mange stedene, de-duplisering av data,
og kostnadene for lagring var enorm.
>> På 70-tallet, den dyreste ressursen at en datamaskin hadde var lagring.
Prosessoren var sett på som en fast kostnad.
Når jeg kjøper boksen, CPU gjør noe arbeid.
Det kommer til å spinne om det er faktisk fungerer eller ikke.
Det er virkelig en sunk cost.
>> Men det kostet meg som en virksomhet er lagring.
Hvis jeg må kjøpe flere disker neste måned, det er en reell kostnad som jeg betaler.
Og at lagring er dyrt.
>> Nå er vi raske frem 40 år og vi har et annet problem.
Den databehandlings er nå dyreste ressurs.
Lagringen er billig.
Jeg mener, vi kan gå hvor som helst på sky og vi kan finne billig lagring.
Men det jeg finner ikke er billig beregne.
>> Så utviklingen av dagens teknologi, database teknologi,
er veldig fokusert rundt distribuerte databaser
som ikke lider av den samme type målestokk
begrensninger av relasjonsdatabaser.
Vi skal snakke litt om hva det egentlig betyr.
>> Men en av grunnene og driveren bak dette-- vi
snakket om data press.
Data trykket er noe som driver innovasjon.
Og hvis du ser på over de siste fem årene,
Dette er et diagram av det data lasten over den generelle bedriften
ser ut i de siste fem årene.
>> Og den generelle tommelfingerregel disse days-- hvis du går Google--
er 90% av de data som vi lagrer i dag, og det var
generert i løpet av de siste to årene.
OK.
Nå er ikke dette en trend som er nytt.
Dette er en trend som har vært gå ut i 100 år.
Helt siden Herman Hollerith utviklet slag kort,
vi har vært å bygge dataregistre og samle inn data på fenomenale priser.
>> Så i løpet av de siste 100 årene, vi har sett denne trenden.
Det kommer ikke til å endre seg.
Fremover kommer vi til å se dette, hvis ikke en akselererende trend.
Og du kan se hva som ser ut som.
>> Hvis en virksomhet som i 2010 hadde en terabyte med data til forvaltning,
i dag det betyr at de er administrerende 6,5 petabyte med data.
Det er 6500 ganger mer data.
Og jeg vet dette.
Jeg jobber med disse virksomhetene hver dag.
Fem år siden, jeg ville snakke med selskaper
som ville snakke med meg om hva en smerte det er å administrere terabyte med data.
Og de ville snakke til meg om hvordan vi ser
at dette er sannsynligvis kommer å være en eller to petabyte
innen et par år.
>> De samme selskapene i dag skal jeg møte med,
og de snakker til meg om Problemet er det å ha styring
tiere, 20 petabyte med data.
Slik at eksplosjonen av data i industrien
driver den enorme trenger for bedre løsninger.
Og relasjonsdatabasen er bare ikke leve opp til etterspørselen.
>> Og så det er en lineær korrelasjon mellom data press
og teknisk innovasjon.
Historien har vist oss dette, at over tid,
når volumet av data som må bearbeides
overskrider kapasiteten til systemet å behandle det i rimelig tid
eller til en rimelig pris, deretter ny teknologi
er oppfunnet for å løse disse problemene.
De nye teknologier, i sin tur åpner døren
til et annet sett med problemer, noe samler enda mer data.
>> Nå er vi ikke kommer til å stoppe dette.
Høyre?
Vi kommer ikke til å stoppe dette.
Hvorfor?
Fordi du ikke kan vite alt det er å vite i universet.
Og så lenge vi har vært i live, Gjennom historien til mannen,
Vi har alltid drevet å vite mer.
>> Så det virker som at hver tomme vi flytter nedover stien av vitenskapelige funn,
vi multiplisere mengden av data at vi trenger å behandle eksponentielt
som vi avdekke mer og mer og mer om den interne driften av livet,
om hvordan universet fungerer, om drive vitenskapelig oppdagelse,
og oppfinnelsen at vi gjør i dag.
Volumet av data bare øker stadig.
Så å være i stand til å håndtere dette problemet er enormt.
>> Så en av de tingene vi ser så hvorfor NoSQL?
Hvordan NoSQL løse dette problemet?
Vel, relasjonsdatabaser, Structured Query Language,
SQL-- det er egentlig en konstruksjon av relasjons database-- disse tingene er
optimalisert for lagring.
>> Tilbake på 70-tallet, igjen, disk er dyrt.
Klargjørings utøvelse av lagring i bedriften tar aldri slutt.
Jeg vet.
Jeg levde det.
Jeg skrev lagringsdrivere for en enterprised superserver selskap
tilbake på 90-tallet.
Og bunnlinjen er reoler annen lagringsarray var bare noe som
skjedde hver dag i bedriften.
Og det har aldri stoppet.
Høyere tetthet lagring, etterspørsel for høy tetthet lagring,
og for mer effektiv lagring devices-- det har aldri stoppet.
>> Og NoSQL er en stor teknologi fordi det normaliserer dataene.
Det de-dupliserer data.
Det setter dataene i en struktur som er agnostiker til hver tilgang mønster.
Flere applikasjoner kan treffe som SQL database, kjøre ad hoc-spørringer,
og få data i den form som de trenger å behandle for sine arbeidsoppgaver.
Det høres fantastisk.
Men bunnlinjen er med noen system, hvis det er agnostiker til alt,
den er optimalisert for ingenting.
OK?
>> Og det er det vi får med relasjonsdatabasen.
Det er optimalisert for lagring.
Det er normalisert.
Det er relasjonell.
Den støtter ad hoc-spørringer.
Og det og det skalerer vertikalt.
>> Hvis jeg trenger å få en større SQL database eller en kraftigere SQL database,
Jeg går kjøpe et større stykke jern.
OK?
Jeg har jobbet med en rekke kunder som har vært gjennom store oppgraderinger
i sin SQL bare Infrastruktur å finne ut seks måneder senere,
de treffer veggen igjen.
Og svaret fra Oracle eller MSSQL eller noen andre er å få en større boks.
Vel før eller senere, kan du ikke kjøpe en større boks, og det er reelt problem.
Vi må faktisk endre ting.
Så hvor kommer dette arbeidet?
Det fungerer bra for offline analytics, OLAP-type arbeidsoppgaver.
Og det er egentlig der SQL tilhører.
Nå er det som brukes i dag i mange online transaksjonsbehandling-type
applikasjoner.
Og det fungerer helt fint på noen grad av utnyttelse,
men det bare ikke skalere den måten at NoSQL gjør.
Og vi skal snakke litt litt om hvorfor det er.
>> Nå, NoSQL, på den annen side, er mer optimalisert for compute.
OK?
Det er ikke agnostiker til tilgangen mønster.
Er det vi kaller de-normalisert struktur eller en hierarkisk struktur.
Dataene i en relasjonsdatabase er sluttet seg sammen fra flere tabeller
å produsere den oppfatning at du trenger.
Dataene i en NoSQL database lagres i et dokument
inneholder den hierarkiske strukturen.
Alle de data som normalt ville bli sluttet seg sammen for å produsere denne visningen
er lagret i et enkelt dokument.
Og vi skal snakke litt om hvordan det fungerer i et par diagrammer.
>> Men ideen her er at du lagrer dataene som disse instansiert utsikt.
OK?
Du skalere horisontalt.
Høyre?
Hvis jeg trenger å øke størrelsen på min NoSQL klyngen,
Jeg trenger ikke å få en større boks.
Jeg får en annen boks.
Og jeg cluster dem sammen, og jeg kan glasskår som data.
Vi skal snakke litt om hva sharding er, for å bli
stand til å skalere den databasen tvers av flere fysiske enheter
og fjerne barrieren som krever meg å skalere vertikalt.
>> Så det er egentlig bygget for online transaksjonsbehandling og skala.
Det er en stor forskjell her mellom rapportering, ikke sant?
Rapportering, jeg vet ikke det spørsmål jeg kommer til å spørre.
Høyre?
Reporting-- hvis noen fra min markedsavdelingen
ønsker å just-- hvor mange av mine kunder har denne spesielle kjennetegn som
kjøpt på denne day-- Jeg vet ikke hva spørre de kommer til å spørre.
Så jeg trenger å være agnostiker.
>> Nå, i en online transaksjons søknad,
Jeg vet hvilke spørsmål jeg spør.
Jeg bygde søknaden om en veldig spesifikk arbeidsflyt.
OK?
Så hvis jeg optimalisere data lagre for å støtte den arbeidsflyten,
det kommer til å være raskere.
Og det er derfor NoSQL kan virkelig akselerere levering
av de typer tjenester.
Greit.
>> Så vi kommer til å komme inn litt teori her.
Og noen av dere, dine øyne kan rulle tilbake litt.
Men jeg skal prøve å holde det så høyt nivå som jeg kan.
Så hvis du er i prosjektet ledelse, er det
en konstruksjon kalt trekant av begrensninger.
OK.
Trekanten av begrenser dikterer du kan ikke ha alt hele tiden.
Kan ikke ha din kaken og spise den også.
Så i prosjektledelse, som trekant begrensninger er at du kan ha det billig,
du kan ha det raskt, eller du kan ha det godt.
Plukk to.
Fordi du ikke kan ha alle tre.
Høyre?
OK.
>> Så du høre om dette mye.
Det er en trippel begrensning, trekant av triple begrensning,
eller jern trekant er oftentimes-- når du snakker til prosjektledere,
de vil snakke om dette.
Nå, databaser har sin egen jern trekant.
Og jern trekant av data er det vi kaller CAP teorem.
OK?
>> CAP teoremet dikterer hvordan databaser opererer
under en veldig spesifikk tilstand.
Og vi skal snakke om hva som tilstanden er.
Men de tre punktene i trekanten, så å si, er C, konsistens.
OK?
Så i CAP, betyr konsistens som all klienter som har tilgang til databasen
vil alltid ha en meget konsistent visning av data.
Ingens skal se to forskjellige ting.
OK?
Hvis jeg ser i databasen, Jeg ser det samme syn
som min partner som ser den samme databasen.
Det er konsistens.
>> Tilgjengelighet betyr at dersom database på nettet, hvis det kan nås,
at alle kunder vil alltid kunne lese og skrive.
OK?
Så hver klient som kan lese databasen
vil alltid kunne lese data og skrive data.
Og hvis det er tilfelle, det er et tilgjengelig system.
>> Og det tredje punkt er hva vi kaller partisjon toleranse.
OK?
Partition toleranse midler at systemet fungerer godt
til tross for fysisk nettverk skillevegger mellom nodene.
OK?
Så noder i klyngen kan ikke snakke med hverandre, hva skjer?
Greit.
>> Så relasjonsdatabaser choose-- du kan plukke to av disse.
OK.
Så relasjonsdatabaser velge å være konsekvent og tilgjengelig.
Hvis partisjonen som skjer mellom de DataNodes i datalageret,
databasen krasjer.
Høyre?
Det går bare ned.
OK.
>> Og dette er grunnen til at de har å vokse med større bokser.
Høyre?
Fordi det er no-- vanligvis, en klynge database, er det ikke så veldig mange av dem
som opererer på den måten.
Men de fleste databaser skalere vertikalt i en enkelt boks.
Fordi de trenger å bli konsekvent og tilgjengelig.
Hvis en skillevegg skulle injiseres, så du må gjøre et valg.
Du må foreta et valg mellom være konsekvent og tilgjengelig.
>> Og det er det NoSQL-databaser gjør.
Greit.
Så en NoSQL database, det kommer i to utgaver.
Vi have-- vel, det kommer i mange varianter,
men det kommer med to grunnleggende characteristics-- hva
vi vil kalle CP database, eller en konsekvent og partisjon toleranse
system.
Disse gutta gjør valget at når nodene miste kontakten med hverandre,
Vi kommer ikke til å tillate folk til å skrive noe mer.
OK?
>> Inntil denne partisjonen er fjernet, skrivetilgang blokkert.
Det betyr at de ikke er tilgjengelige.
De er konsekvent.
Når vi ser at partisjon injisere seg selv,
vi er nå konsekvent, fordi vi ikke kommer
for å tillate dataendring på to sider av skilleveggen uavhengig
fra hverandre.
Vi blir nødt til å reetablere kommunikasjon
før noen oppdatering til dataene er tillatt.
OK?
>> Den neste Smaken ville være en AP system, eller en tilgjengelig og partisjonert
toleranse system.
Disse gutta ikke bryr seg.
Høyre?
Enhver node som får en skrive, vi tar det.
Så jeg replikere min data tvers av flere noder.
Disse nodene får en klient, kommer kunden i, sier, kommer jeg til å skrive noen data.
Node sier, ikke noe problem.
Noden ved siden av ham får en skrive på den samme posten,
han kommer til å si noe problem.
Et sted tilbake på bakenden, at data kommer til å gjenskape.
Og så noen kommer til å realisere, uh-oh, de system vil innse, uh-oh,
det har vært en oppdatering til to sider.
Hva skal vi gjøre?
Og hva de gjør så er de gjør noe som
tillater dem å løse disse dataene staten.
Og vi skal snakke om at i neste figur.
>> Ting å påpeke her.
Og jeg kommer ikke til å bli for mye inn i dette, fordi denne
kommer inn dypt data teori.
Men det er en transaksjons rammeverk som
kjører i en relasjonssystem som tillater meg å trygt gjøre oppdateringer
til flere enheter i databasen.
Og disse oppdateringene vil skje alt på en gang, eller ikke i det hele tatt.
Og dette kalles ACID transaksjoner.
OK?
>> ACID gir oss atomicity, konsistens, isolasjon og holdbarhet.
OK?
Det betyr at atom, transaksjoner, alle mine oppdateringer enten skje eller de ikke.
Konsistens betyr at Databasen vil alltid
bli brakt til en konsekvent tilstand etter en oppdatering.
Jeg vil aldri forlate databasen i en dårlig tilstand etter bruk av en oppdatering.
OK?
>> Så det er litt annerledes enn CAP konsistens.
CAP konsistens betyr all min klienter kan alltid se dataene.
ACID konsistens betyr at når en transaksjon er gjort, data er bra.
Mine relasjoner er alt bra.
Jeg kommer ikke til å slette en forelder rad og la en haug med foreldreløse barn
i en annen tabell.
Det kan ikke skje hvis jeg er konsekvent i et surt transaksjon.
>> Isolasjon betyr at transaksjoner vil alltid forekomme etter hverandre.
Sluttresultatet av data vil være den samme tilstanden
som om disse transaksjonene som ble utgitt samtidig
ble henrettet serielt.
Så det er samtidighet kontroll i databasen.
Så i utgangspunktet, jeg kan ikke øke den samme verdi to ganger med to operasjoner.
>> Men hvis jeg sier legge en til denne verdien, og to transaksjoner kommer i
og prøve å gjøre det, man er skal komme dit først
og den andre ens kommer til å få det etter.
Så til slutt, la jeg to.
Du skjønner hva jeg mener?
OK.
>> Holdbarheten er ganske grei.
Når transaksjonen er anerkjent, er det
kommer til å være der selv hvis systemet krasjer.
Når dette systemet gjenoppretter, som transaksjon som ble begått
faktisk kommer til å være der.
Så det er de garantier av syre transaksjoner.
De er ganske fine garantier å ha på en database,
men de kommer på som koster.
Høyre?
>> Fordi problemet med dette rammeverket er
hvis det er en skillevegg i data sett, jeg må ta en beslutning.
Jeg er nødt til å tillate oppdateringer på den ene siden eller den andre.
Og hvis det skjer, da er jeg ikke lenger kommer
å være i stand til å opprettholde disse egenskapene.
De vil ikke være konsekvent.
De vil ikke bli isolert.
Det er der det bryter ned for relasjonsdatabaser.
Dette er grunnen til relasjons databaser skalere vertikalt.
>> På den annen side har vi det som kalles BASE-teknologi.
Og disse er dine NoSQL-databaser.
Greit.
Så vi har vår CP, AP databaser.
Og dette er hva du kaller utgangspunktet tilgjengelig, myk tilstand, til slutt
konsistent.
OK?
>> I utgangspunktet tilgjengelig, fordi de er partisjon tolerant.
De vil alltid bli der, selv om det er
et nettverk skillevegg mellom nodene.
Hvis jeg kan snakke med en node, er jeg skal være i stand til å lese data.
OK?
Jeg kan ikke alltid være i stand til å skrive data om jeg er en konsekvent plattform.
Men jeg vil være i stand til å lese data.
>> Den myke tilstand indikerer at når jeg leste at data,
det kan ikke være det samme som andre noder.
Hvis en rett ble utstedt på en node et annet sted i klyngen
og det har ikke kopiert over klynge ennå da jeg leste at data,
at staten ikke kan være konsekvent.
Imidlertid vil det bli slutt konsekvent,
noe som betyr at når en skrive Det vises til systemet
Det vil gjenskape tvers nodene.
Og til slutt, at staten vil bli brakt i orden,
og det vil være en konsistent tilstand.
>> Nå CAP teorem virkelig spiller bare i én betingelse.
Denne tilstand er når dette skjer.
Fordi når det er drift i normal modus, er det ingen partisjon,
alt er konsekvent og tilgjengelig.
Du bare bekymre CAP når vi har den partisjonen.
Så de er sjeldne.
Men hvordan systemet reagerer når de oppstår diktere hva slags system
vi arbeider med.
>> Så la oss ta en titt på hva som ser ut som for AP systemer.
OK?
AP systemer kommer i to varianter.
De kommer i smaken som er en herre master, 100%, alltid tilgjengelig.
Og de kommer i annen smaken, som sier:
vet du hva, jeg kommer til å bekymre om dette partisjone ting
når en faktisk partisjon oppstår.
Ellers kommer det til å være primær noder som kommer til å ta rettighetene.
OK?
>> Så hvis vi noe sånt som Cassandra.
Cassandra ville være en mester master, lar meg skrive til enhver node.
Så hva skjer?
Så jeg har et objekt i database som eksisterer på to noder.
La oss kalle dette objektet S. Så vi har staten for S.
Vi har noen operasjoner på S som er pågående.
Cassandra tillater meg å skrive til flere noder.
Så la oss si jeg får en skrive for s til to noder.
Vel, hva som ender opp som skjer er Vi kaller det en partisjone hendelsen.
Det kan ikke være en fysisk nettverk partisjon.
Men på grunn av utformingen av systemet, er det
faktisk partisjonering så snart som jeg får en skrive på to noder.
Det er ikke å tvinge meg til skrive alt gjennom én node.
Jeg skriver på to noder.
OK?
>> Så nå har jeg to stater.
OK?
Hva kommer til å skje er før eller senere,
det kommer til å bli en replikering hendelse.
Det kommer til å bli det vi kalles en partisjon utvinning, som
er hvor disse to landene kommer sammen igjen
og det kommer til å bli en algoritme som går inne i databasen,
bestemmer hva du skal gjøre.
OK?
Som standard, siste oppdatering vinner i de fleste AP systemer.
Så det er vanligvis en standard algoritme, hva
de kaller en tilbakeringing funksjon, noe
vil bli kalt når denne tilstanden detekteres for å utføre noen logikk
å løse den konflikten.
OK?
Standardtilbakeringing og standard resolver i de fleste AP databaser
er, gjett hva, vinner tidsstempel.
Dette var den siste oppdateringen.
Jeg kommer til å sette det oppdatering i det.
Jeg kan dumpe denne posten at jeg dumpet ut i en recovery log
slik at brukeren kan komme tilbake senere og si hei, det var en kollisjon.
Hva skjedde?
Og du kan faktisk dumpe en registrering av alle kollisjoner og rollbacks
og se hva som skjer.
>> Nå, som en bruker, kan du også inkludere logikk i at tilbakeringing.
Så du kan endre det tilbakeringing drift.
Du kan si, hei, jeg vil ha å avhjelpe disse dataene.
Og jeg ønsker å prøve og flette disse to postene.
Men det er opp til deg.
Databasen ikke vet hvordan de skal gjøre det som standard. Mesteparten av tiden,
den eneste databasen vet hvordan å gjøre er å si,
dette var den siste posten.
Det er den som kommer til å vinne, og det er verdien jeg kommer til å sette.
Når det partisjon utvinning og replikering skjer,
vi har vår stat, som Nå er S prime, som er
flettingen tilstanden til alle disse stedene.
Slik at AP-systemer har dette.
CP-systemer trenger ikke å bekymre deg for dette.
Fordi så snart en partisjon kommer inn i bildet, de bare slutte å ta
skriver.
OK?
Så det er veldig lett å forholde seg til å være konsekvent
når du ikke godta noen oppdateringer.
Det er med CP systemer gjør.
Greit.
>> Så la oss snakke litt litt om tilgangs mønstre.
Når vi snakker om NoSQL, er det handler om tilgang mønster.
Nå er SQL ad hoc, spørringer.
Det er relasjons butikken.
Vi trenger ikke å bekymre deg om tilgang mønster.
Jeg skriver en svært kompleks spørring.
Det går og får dataene.
Det er hva dette ser aktig, normalisering.
>> Så i denne strukturen, vi ser på en produkter katalog.
Jeg har forskjellige typer produkter.
Jeg har bøker.
Jeg har album.
Jeg har videoer.
Forholdet mellom produktene og en av disse bøker, album,
og videoer tabeller er 1: 1.
Greit?
Jeg har en produkt-ID, og at ID tilsvarer
til en bok, et album eller en video.
OK?
Det er en 1: 1 forhold over disse tabellene.
>> Nå books-- alt de har er rot egenskaper.
Ikke noe problem.
Det er flott.
En-til-en forhold, får jeg alle dataene jeg trenger å beskrive den boken.
Albums-- album har spor.
Dette er hva vi kaller en til mange.
Hvert album kan ha mange spor.
Så for hvert spor på albumet, jeg kunne ha
en annen post i dette barnet tabellen.
Så lager jeg en post i mitt album tabellen.
Jeg opprette flere poster i spor tabellen.
En-til-mange-relasjon.
>> Dette forholdet er hva vi kaller mange-til-mange.
OK?
Du ser at aktører kan være i mange filmer, mange videoer.
Så det vi gjør er at vi setter denne kartleggingen bordet mellom dem, som det bare
kartlegger skuespiller ID til video ID.
Nå kan jeg lage en spørring sammenføyningene videoer gjennom skuespiller video til skuespillere,
og det gir meg en fin liste over alle filmene og alle aktører
som var i den filmen.
>> OK.
Så her vi går.
En-til-en er på øverste nivå forhold; en-til-mange,
albumene til spor; mange-til-mange.
De er de tre øverste nivå relasjoner i noen database.
Hvis du vet hvordan de relasjoner arbeide sammen,
så du vet mye om database allerede.
Så NoSQL fungerer litt annerledes.
La oss tenke på for andre hva det Ser ut som å gå får alle mine produkter.
>> I en relasjons butikken, jeg ønsker å få alle mine produkter
på en liste over alle mine produkter.
Det er en masse spørsmål.
Jeg fikk en forespørsel for alle mine bøker.
Jeg fikk en forespørsel fra mine album.
Og jeg fikk en spørring for alle mine videoer.
Og jeg fikk for å si det alle sammen i en liste
og serverer den tilbake til applikasjon som er ber om det.
>> For å få bøkene mine, blir jeg Produkter og bøker.
For å få mine album, fikk jeg til å bli med Produkter, Album og spor.
Og for å få videoene mine, jeg har å bli med produkter til videoer,
delta gjennom skuespiller Videoer, og bringe i Actors.
Så det er tre spørsmål.
Svært komplekse spørringer til montere ett resultat sett.
>> Det er mindre enn optimalt.
Dette er grunnen til at når vi snakker om en datastruktur som er
bygget for å være agnostiker til tilgangs pattern-- vel det er flott.
Og du kan se dette er virkelig hyggelig hvordan vi har organisert dataene.
Og vet du hva?
Jeg har bare en rekord for en skuespiller.
>> Det er greit.
Jeg har dedupliserte alle mine skuespillere, og jeg holdt mine assosiasjoner
i denne kartleggingen tabellen.
Men får de data ut blir dyrt.
Jeg sender CPU hele systemet å bli med disse datastrukturer sammen
å være i stand til å trekke den tilbake data.
>> Så hvordan får jeg rundt det?
I NoSQL handler det om aggregering, ikke normalisering.
Så vi ønsker å si at vi ønsker å støtter tilgang mønster.
Hvis tilgangsmønsteret til programmene,
Jeg trenger å få alle mine produkter.
La oss legge alle produktene i én tabell.
Hvis jeg legge alle produktene i én tabell, Jeg kan bare velge alle produkter
fra det bordet og jeg får det hele tatt.
Vel hvordan gjør jeg det?
Vel i NoSQL det er ingen Strukturen til bordet.
Vi skal snakke litt om hvordan dette fungerer i Dynamo DB.
Men du trenger ikke ha samme attributter og de samme egenskapene
i hver enkelt rad, i hver enkelt element, som du gjør i en SQL-tabell.
Og hva gjør dette for meg å gjøre er mange ting
og gi meg en stor fleksibilitet.
I dette spesielle tilfelle, jeg har mine produkt dokumenter.
Og i dette spesielle eksempel alt
er et dokument i Produkter tabellen.
Og produktet for en bok kanskje har en type ID som angir en bok.
Og programmet ville slå på at ID.
>> På programmet tier, jeg kommer å si oh, hva oppføringstype er dette?
Å, det er en bok posten.
Bokoppføringene har disse egenskapene.
La meg lage en bok objekt.
Så jeg kommer til å fylle Boken objekt med dette elementet.
Neste element kommer og sier, hva er dette?
Vel dette elementet er et album.
Åh, jeg fikk en helt annen behandling rutine for det,
fordi det er et album.
Du skjønner hva jeg mener?
>> Så programmet tier-- jeg bare velge alle disse postene.
De begynner å komme.
De kunne være alle forskjellige typer.
Og det er programmets logikk som bytter over de typer
og bestemmer hvordan å behandle dem.
>> Igjen, så vi optimalisere skjema for tilgangsmønster.
Vi gjør det ved å kollapser disse tabellene.
Vi er i utgangspunktet tar disse normaliserte strukturer,
og vi bygger hierarkiske strukturer.
Inni hver og en av disse postene Jeg kommer til å se array-egenskaper.
>> Inne i dette dokumentet for Albums, Jeg ser matriser av låter.
Disse sporene nå become-- det er utgangspunktet dette barnet tabell som
Det finnes rett her i denne strukturen.
Så du kan gjøre dette i DynamoDB.
Du kan gjøre dette i MongoDB.
Du kan gjøre dette i noen NoSQL database.
Lag disse typene hierarkiske datastrukturer
som lar deg hente data svært raskt fordi nå jeg
trenger ikke å samsvare.
Når jeg setter inn en rad inn i Tracks bord, eller en rad inn i Albums bordet,
Jeg må samsvare med at skjema.
Jeg må ha attributtet eller Eiendommen som er definert på det bordet.
Hver og en av dem, når jeg setter den raden.
Det er ikke tilfelle i NoSQL.
>> Jeg kan ha helt forskjellig eiendommer i alle dokumenter
som jeg setter inn i samlingen.
Så veldig kraftig mekanisme.
Og det er egentlig hvordan du optimalisere systemet.
Fordi nå at søket, i stedet av å bli med alle disse tabellene
og gjennomføre et halvt dusin forespørsler å trekke tilbake den data jeg trenger,
Jeg utfører ett søk.
Og jeg gjentar over de resultater som er.
det gir deg en idé av kraften i NoSQL.
Jeg kommer til å slags gå sidelengs her og snakke litt om dette.
Det er flere typer av markedsføring eller technology--
markedsføring av teknologien type diskusjon.
Men det er viktig å forstå fordi hvis vi ser på toppen
her på denne oversikten, hva vi ser på
er det vi kaller teknologi hype-kurven.
Og hva dette betyr er nye ting kommer inn i bildet.
Folk synes det er flott.
Jeg har løst alle mine problemer.
>> Dette kan være slutten alt, være alt til alt.
Og de begynner å bruke den.
Og de sier, dette ting ikke fungerer.
Dette er ikke riktig.
Den gamle ting var bedre.
Og de går tilbake til å gjøre ting slik de var.
Og så til slutt de går, vet du hva?
Dette ting er ikke så ille.
Oh, det er hvordan det fungerer.
Og når de finne ut hvordan det verk, begynner de å bli bedre.
>> Og det morsomme med det er det slags linjer opp til hva
vi kaller Technology Adoption Curve.
Så hva skjer er at vi har en slags teknologi trigger.
I tilfelle av databaser det er data press.
Vi snakket om de høye vannpunkter av data press hele tiden.
Når disse dataene trykket treffer en viss punkt, som er en teknologi trigger.
>> Det begynner å bli for dyrt.
Det tar for lang tid å behandle dataene.
Vi trenger noe bedre.
Du får innovatørene der ute som kjører rundt,
prøver å finne ut hva som er løsningen.
Hva er den nye ideen?
>> Hva er den nest beste måten å gjøre dette?
Og de kommer opp med noe.
Og folk med reell smerte, gutta på blødning kanten,
de vil hoppe over det, fordi de trenger et svar.
Nå hva uunngåelig happens-- og det skjer akkurat nå i NoSQL.
Jeg ser det hele tiden.
>> Hva uunngåelig skjer er folk begynner å bruke det nye verktøyet
på samme måte som de anvendes på gamle verktøyet.
Og de finner ut det ikke fungerer så godt.
Jeg kan ikke huske hvem jeg var snakket med tidligere i dag.
Men det er som når Jackhammer ble oppfunnet,
folk ikke svinge den over hodet for å knuse betongen.
>> Men det er det som er skjer med NoSQL dag.
Hvis du går inn på de fleste butikker, de prøver å være NoSQL butikker.
Det de gjør er de bruker NoSQL,
og de legger det full av relasjonsskjema.
Fordi det er sånn de designe databaser.
Og de lurer på, hvorfor er det ikke presterer godt?
Gutt, stinker denne tingen.
Jeg måtte holde alle mine tiltrer in-- det er, nei, nei.
Oppretthold tiltrer?
Hvorfor er du bli med data?
Du trenger ikke bli med data i NoSQL.
Du samle det.
>> Så hvis du vil unngå dette, lære hvordan verktøyet fungerer før du faktisk
begynne å bruke det.
Ikke prøv og bruke de nye verktøyene samme måte som du brukte de gamle verktøyene.
Du kommer til å ha en dårlig opplevelse.
Og hver eneste gang det er hva dette handler om.
Når vi begynner å komme opp her, det er fordi folk har funnet ut
hvordan å bruke verktøyene.
>> De gjorde det samme når relasjonsdatabaser ble oppfunnet,
og de var erstatte filsystemer.
De prøvde å bygge filsystemer med relasjonsdatabaser
fordi det er det folk forstått.
Det fungerte ikke.
Så forstå de beste praksis av teknologien du arbeider med
er enorme.
Veldig viktig.
>> Så vi kommer til å komme inn DynamoDB.
DynamoDB er AWS s fullt klarte NoSQL-plattformen.
Hva gjør fullt klarte bety?
Det betyr at du ikke trenger å virkelig bekymre deg for noe.
>> Du kommer inn, fortelle deg oss, jeg trenger et bord.
Den trenger dette mye kapasitet.
Du trykker på knappen, og vi bestemmelsen alle infrastrukturen bak scenen.
Nå som er enorm.
>> Fordi når du snakker om skalering en database,
NoSQL data klynger på skala, kjører petabyte,
kjører millioner av transaksjoner per sekund,
disse tingene er ikke små klynger.
Vi snakker tusenvis av tilfeller.
Administrerende tusenvis av tilfeller selv virtuelle instanser,
er en reell smerte i baken.
Jeg mener, tenk om hver gang en operativsystemet patch kommer ut
eller en ny versjon av databasen.
Hva betyr det til deg operasjonelt?
Det betyr at du fikk 1200 servere som trenger å bli oppdatert.
Nå selv med automatisering, som kan ta lang tid.
Som kan føre til mye operative hodepine,
fordi jeg kanskje har tjenester ned.
>> Som jeg oppdatere disse databasene, jeg kan gjøre blågrønne distribusjoner
hvor jeg distribuere og oppgradere halv min noder, og deretter oppgradere den andre halvparten.
Ta dem ned.
Så forvalte infrastrukturen Skalaen er enormt smertefullt.
Og AWS ta smerten ut av det.
Og NoSQL-databaser kan være usedvanlig smertefull
på grunn av måten de målestokk.
>> Skalere horisontalt.
Hvis du ønsker å få en større NoSQL database, kjøper du flere noder.
Hver node du kjøper er en annen operativ hodepine.
Så la noen andre gjøre det for deg.
AWS kan gjøre det.
>> Vi støtter dokumentet sentrale verdier.
Nå vi ikke gå for mye inn på den andre figuren.
Det er mye forskjellig smaker av NoSQL.
De er alle slags få munged sammen på dette punktet.
Du kan se på DynamoDB og si ja, vi er både et dokument og en nøkkelverdi
lagre dette punktet.
Og du kan argumentere funksjonene av en over den andre.
For meg er mye av dette virkelig seks av en halvt dusin av den andre.
Hver og en av disse teknologiene er en FINE-teknologi og en fin løsning.
Jeg vil ikke si MongoDB er bedre eller verre enn Couch, så Cassandra,
da Dynamo, eller vice versa.
Jeg mener, dette er bare alternativer.
>> Det er raskt og det er konsekvent på noen skala.
Så dette er en av de største bonuser du får med AWS.
Med DynamoDB er evnen for å få en lav ensifret
millisekund ventetid på noen skala.
Det var et mål utforming av systemet.
Og vi har kunder som gjør millioner transaksjoner per sekund.
>> Nå skal jeg gå gjennom noen av de bruke saker i et par minutter her.
Integrert tilgang control-- har vi det vi kaller
Identity Access Management, eller IAM.
Det gjennomsyrer alle system, hver tjeneste som AWS tilbyr.
DynamoDB er intet unntak.
Du kan kontrollere tilgangen til DynamoDB tabeller.
Across all din AWS kontoer ved definere tilgangsroller og tillatelser
i IAM infrastruktur.
>> Og det er en viktig og integrert komponent i det vi kaller hendelsesdrevet programmering.
Nå er dette et nytt paradigme.
>> PUBLIKUM: Hvordan er din hastighet på ekte positive versus falske negativer
på adgangskontrollsystem?
RICK Houlihan: Sanne positive versus falske negative?
PUBLIKUM: Retur hva du bør komme tilbake?
I motsetning til en gang i blant det kommer ikke tilbake når det skal validere?
>> RICK Houlihan: Jeg kunne ikke fortelle deg det.
Hvis det er noen feil overhodet på det,
Jeg er ikke den personen å spørre det aktuelle spørsmålet.
Men det er et godt spørsmål.
Jeg vil være glad i å vite som meg selv, faktisk.
>> Og så igjen, nye paradigmet er hendelsesdrevet programmering.
Dette er ideen om at du kan distribuere komplekse applikasjoner som
kan operere en veldig, veldig høy skala uten infrastruktur overhodet.
Uten fast infrastruktur overhodet.
Og vi skal snakke litt om hva det betyr som vi
komme videre til neste par diagrammer.
>> Det første vi skal gjøre er vi skal snakke om bord.
API datatyper for Dynamo.
Og det første du vil legge merke til når du ser på dette,
hvis du er kjent med noen database, databaser har egentlig to slags APIer
Jeg vil kalle det.
Eller to sett med API.
En av disse ville bli administrative API.
>> De tingene de tar vare på funksjoner i databasen.
Konfigurering av lagringsmotoren, sette opp og legge bordene.
etablering av databasen kataloger og instanser.
Disse things-- i DynamoDB, du har svært korte, korte lister.
>> Så med andre databaser, du kan se dusinvis
av kommandoer, av administrative kommandoer, for å konfigurere
disse ekstra alternativer.
I DynamoDB du ikke trenger dem fordi trenger du ikke konfigurere systemet, gjør vi.
Så det eneste du trenger å gjøre er å Fortell meg hvilken størrelse tabellen trenger jeg.
Så du får en veldig begrenset sett med kommandoer.
>> Du får en Create Table Update, Table, Slett tabell, og Beskriv Table.
De er de eneste tingene du trenger for DynamoDB.
Du trenger ikke en oppbevarings motorkonfigurasjon.
Jeg trenger ikke å bekymre deg for replikering.
Jeg trenger ikke å bekymre deg sharding.
>> Jeg trenger ikke å bekymre deg om noen av disse tingene.
Vi gjør alt for deg.
Så det er en enorm mengde overhead det er bare løftes av tallerkenen din.
Da har vi crud operatører.
CRUD er noe hva vi ringe i databasen som er
Opprette, oppdatere, slette operatører.
Dette er sunn databaseoperasjoner.
Ting som put element, får varen, oppdatering elementer, slette elementer, batch spørring, skanne.
Hvis du ønsker å skanne hele tabellen.
Trekk alt av bordet.
En av de fine tingene om DynamoDB er det tillater parallell skanning.
Så du kan faktisk la meg vite hvor mange tråder du ønsker å kjøre på at skanningen.
Og vi kan kjøre disse trådene.
Vi kan spinne som skanner opp tvers av flere tråder
slik at du kan skanne hele tabellen plass veldig, veldig fort i DynamoDB.
>> Den andre API vi har er det vi kaller vår Streams API.
Vi kommer ikke til å snakke for mye om dette akkurat nå.
Jeg har fått noen innhold senere på i dekk om dette.
Men Strømmer er virkelig en running-- Tenk på det som den gang bestilt
og partisjon endringslogg.
Alt som skjer på tabellen viser opp på strømmen.
>> Hver skrive til bordet dukker opp på strømmen.
Du kan lese at strøm, og du kan gjøre ting med den.
Vi skal snakke om hva typer ting du
gjøre med de tingene som replikering, skape sekundære indekser.
Alle typer kult ting du kan gjøre med det.
>> Datatyper.
I DynamoDB støtter vi både nøkkelen verdi og dokumentere datatyper.
På venstre side av skjermen her har vi våre grunnleggende typer.
Viktige typer verdi.
Dette er strenger, tall og binærfiler.
>> Så bare tre grunnleggende typer.
Og så kan du ha sett på dem.
En av de fine tingene om NoSQL er du kan inneholde arrays som egenskaper.
Og med DynamoDB kan du inneholde arrays av grunnleggende typer som root eiendom.
>> Og så er det dokumenttypene.
Hvor mange mennesker er kjent med JSON?
Dere er kjent med JSON så mye?
Det er i utgangspunktet Javascript, Objekt, Notation.
Den lar deg i utgangspunktet definere en hierarkisk struktur.
>> Du kan lagre en JSON dokument på DynamoDB bruker felleskomponenter
eller byggesteinene som er tilgjengelige i de fleste programmeringsspråk.
Så hvis du har Java, er du se på kart og lister.
Jeg kan lage objekter som området kartet.
Et kart som sentrale verdier lagres som egenskaper.
Og det kan ha lister over verdier innenfor disse egenskapene.
Du kan lagre denne komplekse hierarkisk struktur
som en enkelt attributt av en DynamoDB element.
>> Så tabeller i DynamoDB, som de fleste NoSQL-databaser, tabeller har elementer.
I MongoDB du ville kalle disse dokumentene.
Og det ville være sofaen basen.
Også en dokumentdatabase.
Du kaller disse dokumentene.
Dokumenter eller elementer har attributter.
Attributter kan eksistere eller ikke eksisterer på elementet.
I DynamoDB, det er én obligatorisk attributt.
Akkurat som i en relasjonsdatabase, du har en primærnøkkel på bordet.
>> DynamoDB har det vi kaller en firkanttasten.
Firkanttasten må være unikt.
Så når jeg definerer en hash table, utgangspunktet hva jeg sier
er hvert element vil ha en firkanttasten.
Og hver firkanttasten må være unikt.
>> Hvert element er definert av det unike firkanttasten.
Og det kan bare være ett.
Dette er OK, men ofte hva folk trenger
er de ønsker er dette hash Nøkkelen til å gjøre litt mer
enn bare være en unik identifikator.
Ofte ønsker vi å bruke som firkanttasten som øverste nivå aggregering bøtte.
Og måten vi gjør det på er ved legge det vi kaller en rekke nøkkel.
>> Så hvis det er en hash bare tabell, dette må være unikt.
Hvis det er en hash og rekkevidde tabellen, Kombinasjonen av hasj og utvalget
må være unikt.
Så tenk på det på denne måten.
Hvis jeg har et forum.
Og formen har emner, det har poster, og det har svarene.
>> Så jeg har kanskje en hash tasten, som er tema ID.
Og jeg kan ha en rekke nøkkel, som er responsen ID.
På den måten hvis jeg ønsker å få alle svar for spesielle tema,
Jeg kan bare spørre hasj.
Jeg kan bare si gi meg alt elementene som har denne hash.
Og jeg kommer til å få alle spørsmål eller legge til det aktuelle emnet.
Disse topp samlinger er svært viktig.
De støtter den primære tilgang mønster av søknaden.
Generelt sett, denne er det vi ønsker å gjøre.
Vi ønsker at table-- som du legger på bordet,
vi ønsker å strukturere data i tabellen på en slik måte
at søknaden kan veldig raskt hente disse resultatene.
Og ofte den måten å gjøre det på er for å opprettholde disse samlinger som vi
sette inn data.
I utgangspunktet er vi spre data inn i den lyse bøtte som det kommer inn.
>> Range tastene lar me-- hash nøklene må være likestilling.
Når jeg spørre en hash, må jeg si gi meg en hash som tilsvarer dette.
Når jeg spørre et utvalg, jeg kan si gi meg et utvalg
som ved hjelp av en hvilken som helst slags rik operatør som vi støtter.
Gi meg alle elementer for en hash.
Er det like, større enn, mindre enn, begynner det med,
eksisterer det mellom disse to verdier?
Så disse typer områdespørringer at vi er alltid interessert i.
Nå er en ting om data, når du ser på tilgang til data, når
du tilgang til data, er det alltid om en aggregering.
Det handler alltid om postene som er relatert til dette.
Gi meg alt her that's-- alle transaksjonene på dette kredittkortet
for den siste måneden.
Det er en samling.
>> Nesten alt du gjør i Databasen er noen form for aggregering.
Så være i stand til å være i stand til å definere disse bøtter og gi deg disse spenner
attributter som skal være i stand til å søke på, de rike spørringer støtter mange,
mange, mange søknad tilgang mønstre.
>> Så den andre tingen på firkanttasten gjør er det gir oss en mekanisme
å være i stand til å spre data rundt.
NoSQL databaser fungerer best når dataene er jevnt
fordelt på klyngen.
Hvor mange mennesker er kjent med hashing algoritmer?
Når jeg sier hasj og en hashing-- fordi en hashing-algoritme
er en måte å være i stand til å generere en tilfeldig verdi fra en hvilken som helst gitt verdi.
Så i dette tilfellet, hash algoritme vi kjører er ND 5 basert.
>> Og hvis jeg har en ID, og ​​dette er min firkanttasten, jeg har en, to, tre.
Når jeg kjører hash algoritmen, det kommer til å komme tilbake og si:
vel en lik 7B, 2 tilsvarer 48, 3 tilsvarer CD.
De er spredt over hele nøkkelen plass.
Og hvorfor gjør du dette?
Fordi det gjør at jeg kan sette rekorder på tvers av flere noder.
>> Hvis jeg gjør dette trinnvis, 1, 2, 3.
Og jeg har en hash utvalg som kjører i dette tilfellet,
en liten hash plass, det går fra 00 til FF,
deretter postene kommer til å komme i og de kommer til å gå 1, 2, 3, 4, 5,
6, 7, 8, 9, 10, 11, 12.
Hva skjer?
Hver innsats er kommer til den samme node.
Du skjønner hva jeg mener?
>> Fordi når jeg delt plass, og jeg spre disse postene over,
og jeg partisjon, kommer jeg til å si partisjon 1 har nøkkelen plass 0-54.
Partisjon 2 er 55-89.
Partition 3 er AA til FF.
Så hvis jeg bruker lineært økes ID-er, kan du se hva som skjer.
1, 2, 3, 4, 5, 6, hele veien opp til 54.
Så som jeg hamring poster i systemet,
alt ender opp med å gå til en node.
>> Det er ikke bra.
Det er en antipattern.
I MongoDB de har dette problemet hvis du ikke bruker en firkanttasten.
MongoDB gir deg muligheten av hashing nøkkelverdien.
Du bør alltid gjøre det, hvis du bruker et økes hash
nøkkelen i MongoDB, eller vil du være spikre hver skrive til en node,
og du vil være begrensende din skrive gjennomstrømming dårlig.
>> PUBLIKUM: Er det A9 169 i desimal?
>> RICK Houlihan: Ja, det er et sted rundt der.
A9, vet jeg ikke.
Du må få min binære til desimal kalkulator.
Hjernen min virker ikke sånn.
PUBLIKUM: Bare en rask en av Mongo kommentarer.
Så er objektet ID som kommer opprinnelig med Mongo gjøre det?
RICK Houlihan: Betyr det gjøre det?
Hvis du spesifiserer det.
Med MongoDB, har du muligheten.
Du kan specify-- hvert dokument i MongoDB må ha en understrek ID.
Det er den unike verdien.
>> I MongoDB kan du angi om til hasj det eller ikke.
De bare gir deg muligheten.
Hvis du vet at det er tilfeldig, ikke noe problem.
Du trenger ikke å gjøre det.
Hvis du vet at det ikke er tilfeldig at det økes, så gjør hash.
>> Nå er ting om hashing, når du hasj
en value-- og denne er hvorfor hash tastene er alltid
unike spørringer, fordi jeg har endret verdien, nå kan jeg ikke gjøre en rekke spørsmål.
Jeg kan ikke si dette er mellom dette eller hint,
fordi hash-verdi er ikke til å være tilsvarende den faktiske verdien.
Så når du hasj som nøkkel, er det likestilling bare.
Det er derfor i DynamoDB firkanttasten spørringer er alltid likestilling bare.
>> Så nå i en rekke key-- når jeg legger til at utvalget nøkkel,
disse range viktige poster alle kommer inn og de blir lagret på samme partisjon.
Så de er veldig raskt, enkelt hentet fordi dette er den hash,
dette er rekkevidden.
Og du ser alt med den samme hash
blir lagret på samme partisjon plass.
Du kan bruke dette området for å bidra til isere dine data nær sin forelder.
Så hva er det jeg egentlig gjør her?
Dette er en en til mange forhold.
Forholdet mellom en firkanttasten og utvalget nøkkelen er en til mange.
Jeg kan ha flere hash nøkler.
Jeg kan bare ha flere utvalg tastene innenfor hver firkanttasten.
>> Hash definerer forelder, utvalget definerer barn.
Så du kan se det er analog her mellom det relasjonelle konstruksjonen
og de samme typene konstruerer i NoSQL.
Folk snakker om NoSQL som ikke-relasjons.
Det er ikke ikke-relasjons.
Data har alltid relasjoner.
Disse relasjonene bare er modellert annerledes.
La oss snakke litt litt om holdbarhet.
Når du skriver til DynamoDB, skriver alltid er tre-veis replikert.
Noe som betyr at vi har tre AZ-tallet.
AZ-er Tilgjengelighet soner.
Du kan tenke på en tilgjengelighet Sonen som et datasenter
eller en samling av datasentre.
Disse tingene er geografisk isolert fra hverandre
på tvers av ulike forkastningssoner, på tvers annet kraftnett og elveslette.
En svikt i en AZ er ikke kommer til å ta ned en annen.
De er også knyttet sammen med mørk fiber.
Den støtter én sub 1 millisekund latency mellom AZS.
Så sanntidsdata kjøringer stand i multi AZS.
>> Og ofte flere AZ distribusjoner møte de høye krav til tilgjengelighet
av de fleste bedriftsorganisasjoner.
Så DynamoDB er spredt over tre AZS som standard.
Vi skal bare kunnskap skrive når to av de tre nodene komme tilbake
og si: Ja, jeg fikk den.
Hvorfor det?
Fordi på lesesiden vi er bare kommer til å gi deg dataene tilbake når
vi får det fra to noder.
>> Hvis jeg reproduserende tvers tre, og jeg leser fra to,
Jeg er alltid garantert å ha minst ett
av dem som leser til å være mest oppdaterte versjonen av data.
Det er det som gjør DynamoDB konsekvent.
Nå kan du velge å slå de som konsekvent leser av.
I så fall kommer jeg til å si, Jeg skal bare lese fra én node.
Og jeg kan ikke garantere det kommer å være de mest aktuelle data.
>> Så hvis en skrive kommer inn, det ikke har replikert ennå,
du kommer til å få den kopien.
Det er en slutt konsekvent lese.
Og hva som er er halvparten av prisen.
Så dette er noe å tenke på.
Når du leser ut DynamoDB, og du setter opp din lesekapasitet
enheter, hvis du velger til slutt konsekvent leser, det er mye billigere,
det er omtrent halvparten av kostnadene.
>> Og så det sparer du penger.
Men det er ditt valg.
Hvis du vil ha en konsekvent lese- eller en slutt konsekvent lese.
Det er noe som du kan velge.
>> La oss snakke om indekser.
Så vi nevnte at toppnivå aggregering.
Vi har fått hasj nøkler, og vi har fått range keys.
Det er fint.
Og det er på den primære tabellen, jeg fikk en firkanttasten, fikk jeg en rekke nøkkel.
>> Hva betyr det?
Jeg har fått en attributt som jeg kan kjøre rike spørringer mot.
Det er utvalget nøkkelen.
De andre attributter på at item-- Jeg kan filtrere på disse attributtene.
Men jeg kan ikke gjøre ting som det begynner med, eller er større enn.
>> Hvordan gjør jeg det?
Jeg oppretter en indeks.
Det finnes to typer av indekser i DynamoDB.
En indeks er virkelig et annet syn på bordet.
Og den lokale videregående indeksen.
>> Det første vi skal snakke om.
Så lokale second er coexisted på samme partisjon som dataene.
Og som sådan, de er på den samme fysiske noden.
De er det vi kaller konsekvent.
Betydning, vil de erkjenne skrive sammen med bordet.
Når skrive kommer inn, vi skal skrive gjennom indeksen.
Vi skal skrive opp til bordet, og da vil vi erkjenne.
Så det er konsekvent.
Når skrive har vært erkjent fra bordet,
det er garantert at lokal videregående index
vil ha samme syn på data.
Men hva de lar deg gjøre er definere alternative range keys.
>> Nødt til å bruke samme hash tast som den primære tabellen,
fordi de er samlokalisert på samme partisjon, og de er konsekvente.
Men jeg kan lage en indeks med ulike range keys.
Så for eksempel, hvis jeg hadde en produsent som hadde en rå deler bord kommer inn.
Og rå deler kommer inn, og de er samlet ved montering.
Og kanskje det er en tilbakekalling.
>> Del som ble gjort av dette Produsenten etter denne datoen,
Jeg trenger å trekke fra min linje.
Jeg kan spinne en indeks som ville være ute,
aggregering på datoen for produksjon av den aktuelle delen.
Så hvis min topp nivå bord var allerede hashet av produsenten,
kanskje det ble arrangert på en del ID, jeg kan opprette en indeks av det bordet
som hashet av produsenten og varierte på produksjonsdato.
Og på den måten jeg kunne si, noe som ble produsert mellom disse datoene,
Jeg må trekke fra linjen.
Så det er en lokal videregående indeks.
>> Dette har effekten av begrense firkanttasten plass.
Fordi de co-eksisterte på samme lagerknuten,
de begrense firkanttasten plass til 10 gigabyte.
DynamoDB, under tabeller, vil partisjonere
bordet hver 10 gigabyte.
Når du putter 10 gigabyte data i, vi gå [PHH], og vi legge til en annen node.
>> Vi vil ikke dele LSI tvers av flere partisjoner.
Vi skal dele bordet.
Men vi vil ikke dele LSI.
Så det er noe viktig å forstå
er hvis du gjør veldig, veldig, veldig store samlinger,
så du kommer til å være begrenset 10 gigabyte på din LSIS.
>> Hvis det er tilfelle, kan vi bruke globale second.
Global second er virkelig en annen tabell.
De finnes helt av å siden av din primære tabellen.
Og de tillater meg å finne en helt annen struktur.
Så tenk på det som data blir satt inn i to forskjellige tabeller, strukturert
på to forskjellige måter.
>> Jeg kan definere en helt annerledes firkanttasten.
Jeg kan definere en helt annet utvalg nøkkelen.
Og jeg kan kjøre dette helt uavhengig av hverandre.
Som et spørsmål om faktum, har jeg klargjort min lesekapasitet
og skrive kapasitet for min globale sekundære indekser
helt uavhengig av mitt primære tabellen.
Hvis jeg definerer som indeks, sier jeg det hvor mye lese og skrive
kapasitet det kommer til å bruke.
>> Og som er atskilt fra mitt primære tabellen.
Nå begge indeksene tillate oss å ikke bare definere hasj og range keys,
men de tillater oss å projisere ekstra verdier.
Så hvis jeg ønsker å lese av indeksen, og jeg ønsker å få noen sett med data,
Jeg trenger ikke å gå tilbake til hoved bordet for å få de ekstra attributtene.
Jeg kan projisere dem ekstra attributter i tabellen
å støtte tilgangsmønster.
Jeg vet at vi sannsynligvis får inn noen virkelig, really-- komme inn ugresset
her på noen av disse tingene.
Nå fikk jeg til å drive ut av dette.
>> PUBLIKUM: [uhørbart] --table nøkkelen mente var en hash?
Den opprinnelige hash?
Multi-lamellene?
>> RICK Houlihan: Ja.
Ja.
Tabellen nøkkelen i utgangspunktet peker tilbake til elementet.
Så en indeks er en peker tilbake til de opprinnelige elementene på bordet.
Nå kan du velge å bygge en indeks som bare har nøkkelen bordet,
og ingen andre egenskaper.
Og hvorfor kan jeg gjøre det?
Vel, kanskje jeg har veldig store elementer.
>> Jeg egentlig bare trenger å vite which-- min tilgang mønster kanskje si,
hvilke elementer som inneholder denne eiendommen?
Trenger ikke å returnere varen.
Jeg trenger bare å vite hvilke elementer som inneholder det.
Så du kan bygge indekser som bare har nøkkelen bordet.
>> Men det er først og fremst hva en indeks i databasen er for.
Det er for å være i stand til raskt identifisere hvilke poster,
hvilke rader, hvilke postene i tabellen har
egenskapene som jeg søker etter.
>> GSIs, så hvordan fungerer de?
GSIs utgangspunktet er asynkron.
Oppdateringen kommer inn i tabellen, Tabellen blir deretter asynkront oppdateres
alle dine GSIs.
Dette er grunnen er GSIs slutt konsekvent.
>> Det er viktig å merke seg at når du bygger GSIs,
og du forstår du oppretter en annen dimensjon av aggregation--
Nå la oss si et godt eksempel her er en produsent.
Jeg tror jeg kunne ha snakket om en medisinsk produsent enhet.
Produsenter av medisinsk utstyr Ofte har serialiserte deler.
De delene som går inn en hofteoperasjon alle
har en liten serienummer på dem.
Og de kunne ha millioner og millioner og milliarder av deler
i alle enheter som de leverer.
Vel, de trenger å aggregere henhold forskjellige dimensjoner, alle deler
i en sammenstilling, hele deler som er gjort
på en viss linje, alt delene som kom
i fra en bestemt produsent på en bestemt dato.
Og disse samlinger noen ganger komme opp i milliardklassen.
>> Så jeg jobber med noen av disse gutta som lider
fordi de skaper disse enorm samlinger
i sine sekundære indekser.
De kan ha en rå deler tabell som kommer som hasj bare.
Hver del har et unikt serienummer.
Jeg bruker serienummeret som hasj.
Det er vakkert.
Min rå datatabellen er spredt hele nøkkelen plass.
Min [? skrive ?] [? inntak?] er kjempebra.
Jeg tar mye data.
Så hva de gjør er de oppretter en GSI.
Og jeg sier, vet du hva, jeg trenger å se alle delene for denne produsenten.
Vel, plutselig er jeg ta en milliard rader,
og stappe dem inn en node, fordi når
Jeg aggregere som Produsenten ID som hasj,
og en del tall som utvalget, da alle plutselig er jeg
sette en milliard deler inn i hva denne produsenten har levert meg.
>> Det kan føre til mye press på GSI,
igjen, fordi jeg hamrer én node.
Jeg setter alle disse setter inn en node.
Og det er en skikkelig problematisk bruk tilfelle.
Nå fikk jeg en god design mønster for hvordan du unngår det.
Og det er et av problemene at jeg alltid jobbe med.
Men hva skjer, er det GSI kanskje ikke har nok skrivekapasitet
å være i stand til å skyve alle rader i en enkelt node.
Og hva skjer da er det primære, klienten bordet,
den primære tabellen skal strupes fordi GSI ikke kan holde tritt.
Så min innsats rente vil faller på den primære tabell
som min GSI forsøker å holde tritt.
>> All right, så GSI-tallet, LSI-tallet, som en bør jeg bruke?
LSI-er konsekvent.
GSI-er etter hvert konsekvent.
Hvis det er OK, anbefaler jeg å bruke en GSI, de er mye mer fleksibel.
LSI-er kan modelleres som en GSI.
Og hvis datastørrelsen per hash nøklene i samlingen din overstiger 10 gigabyte,
så du kommer til å ønske å bruke det GSI fordi det er bare en hard grense.
>> All right, så skalering.
Gjennomstrømning i Dynamo DB, du kan bestemmelsen [uhørbart]
gjennomstrømning i en tabell.
Vi har kunder som har klargjort 60 billion--
gjør 60 milliarder forespørsler, regelmessig kjører på over en million forespørsler
per sekund på våre bord.
Det er egentlig ingen teoretisk grense for hvor mye
og hvor fort tabellen kan kjøre i Dynamo DB.
Det er noen myk begrensninger på kontoen din
at vi satt der så at du ikke gå gale.
Hvis du ønsker mer enn at det ikke er et problem.
Du kommer fortelle oss.
Vi vil slå opp urskiven.
>> Hver konto er begrenset til et visst nivå i hver service, like utenfor balltre
slik at folk ikke gå gale komme seg inn i trøbbel.
Ingen grense i størrelse.
Du kan sette et tall av elementer på et bord.
Størrelsen på en vare er begrenset til 400 kilobyte hver,
som ville være elementet ikke attributtene.
Så summen av alle attributter er begrenset til 400 kilobyte.
Og så igjen, har vi det lille LSI saken
med 10 gigabyte grense per hasj.
PUBLIKUM: Lite antall, jeg mangler hva du forteller meg, som er--
PUBLIKUM: Oh, 400 kilobyte er maksimumsstørrelsen per element.
Så et objekt har alle attributtene.
Så 400 k er den totale størrelse av dette elementet, 400 kilobyte.
Så av alle de egenskaper kombineres, alle data
det er i alle disse attributtene, rullet opp i en total størrelse,
dag i dag elementet grensen er 400 k.
Så skalering igjen, oppnådde gjennom partisjonering.
Gjennomstrømning er klargjort ved bordet nivå.
Og det er egentlig to knotter.
Vi har lest kapasitet og skrive kapasitet.
>> Så disse er justert uavhengig av hverandre.
RCU er tiltaket strengt konsekvent leser.
OK, så hvis du sier jeg vil ha 1000 RCU er de som er strengt konsekvent,
de er konsistente leser.
Hvis du sier jeg vil ha eventuell konsekvent leser,
du kan bestemmelsen 1000 RCU er, du kommer
for å få 2000 til slutt konsekvent leser.
Og halvparten av prisen for disse til slutt bestå i leser.
>> Igjen, justert uavhengig av hverandre.
Og de har throughput-- Hvis du bruker 100% av RCU,
du kommer ikke til å påvirke tilgjengeligheten av dine rettigheter.
Så de er helt uavhengig av hverandre.
All right, så en av de tingene som Jeg nevnte kort ble strupe.
Struping er dårlig.
Struping indikerer dårlig ingen SQL.
Det er ting vi kan gjøre for å hjelpe du lindre struping at du
opplever.
Men den beste løsningen til dette er la oss ta
en se på hva du gjør, fordi det er en anti-mønster i spill her.
>> Disse tingene, ting som ikke-uniform arbeidsbelastning, hurtigtaster, varme partisjoner.
Jeg treffer en bestemt nøkkel plass veldig vanskelig for noen spesiell grunn.
Hvorfor gjør jeg dette?
La oss finne det ut.
Jeg blande min varme data med kalde data.
Jeg la mine tabeller få stor, men det er egentlig
bare noen delsett av data det er veldig interessant for meg.
Så for loggdata, for eksempel en masse kunder, får de logger data hver dag.
De fikk en enorm mengde av loggdata.
>> Hvis du bare dumping alt som log data i ett stort bord, over tid
at tabellen kommer til å få massiv.
Men jeg er egentlig bare interessert i siste 24 timene, de siste sju dagene,
de siste 30 dagene.
Uansett tidsvindu at jeg er interessert i å se
for hendelsen som plager meg, eller tilfelle det er interessant for meg,
det er det eneste vinduet tiden at jeg trenger.
Så hvorfor er jeg sette 10 år verdt av loggdata i tabellen?
Hva som forårsaker er bordet fragmentet.
>> Det blir stort.
Det begynner å spre ut over tusenvis av noder.
Og siden din kapasitet er så lav, du er
faktisk rangere begrensende på hver en av de individuelle noder.
Så la oss begynne å se på hvordan gjør vi rulle tabellen over.
Hvordan skal vi håndtere disse dataene litt bedre å unngå disse problemene.
Og hva betyr det se ut?
Dette er hva som ser ut som.
Dette er hva dårlig NoSQL ser ut.
>> Jeg fikk en hurtigtast her.
Hvis du ser på siden her, disse er alle mine partisjoner.
Jeg fikk 16 partisjoner opp her på denne databasen.
Vi gjør dette hele tiden.
Jeg kjører denne for kunder hele tiden.
Det kalles kartet varmen.
Varmekartet forteller meg hvor du er tilgang til nøkkel plass.
Og hva dette forteller meg er at det er en bestemt hash
at denne fyren liker en forferdelig mye, fordi han er
treffer det veldig, veldig vanskelig.
>> Så den blå er fint.
Vi liker blått.
Vi liker ikke rødt.
Rødts der trykket kommer opp til 100%.
100%, nå er du kommer til å bli redusert.
Så når du ser noen røde linjer som dette-- og det er ikke bare Dynamo DB--
hver NoSQL database har dette problemet.
Det er anti-mønstre som kan drive disse forhold.
Det jeg gjør er at jeg jobber med kunder for å lindre disse tilstander.
>> Og hva betyr det se ut?
Og dette er å få mest mulig ut av Dynamo DB gjennomstrømning,
men det begynner virkelig å mest mulig ut av NoSQL.
Dette er ikke begrenset til Dynamo.
Dette er definitely-- jeg pleide å jobbe på Mongo.
Jeg er kjent med mange NoSQL plattformer.
Hver og en har disse typene av hurtigtast problemer.
For å få mest mulig ut av enhver NoSQL database, spesielt Dynamo DB,
du ønsker å opprette tabellene hvor firkanttasten element har
et stort antall forskjellige verdier, en høy grad av kardinalitet.
Fordi det betyr at jeg skriver til mange forskjellige skuffer.
>> Jo flere bøtter jeg er skriving til, jo mer sannsynlig
Jeg er for å spre at skrive belastning eller lese laste ut over flere noder,
jo mer sannsynlig er jeg til å ha en høy gjennomstrømning på bordet.
Og da vil jeg verdiene å være ba nokså jevnt over tid
og jevnt så tilfeldig som mulig.
Vel, det er ganske interessant, fordi jeg kan egentlig ikke
kontroll når brukerne kommer.
Så nok til å si, hvis vi spre ting ut over nøkkelen plass,
vi vil trolig være i bedre form.
>> Det er en viss tid levering
at du ikke kommer å være i stand til kontroll.
Men de er egentlig to dimensjoner som vi har,
plass, tilgang jevnt spredt, tid, forespørsler
ankommer jevnt fordelt i tid.
Og hvis de to vilkår blir oppfylt,
så det er hva det er kommer til å se ut.
Dette er mye hyggeligere.
Vi er veldig fornøyd her.
Vi har en meget jevn tilgang mønster.
Ja, kanskje du får en lite press nå og da,
men ingenting egentlig altfor omfattende.
Så det er utrolig hvor mange ganger, når jeg jobber med kunder,
som først graf med den store røde bar og alt det stygge gule det er
over alt, vi få gjort med øvelsen
etter et par måneder av re-arkitektur,
de kjører nøyaktig samme arbeidsmengde på nøyaktig samme belastning.
Og dette er hva det ser ut nå.
Så hva du får med NoSQL er en data skjema som er helt
bundet til aksessmønster.
>> Og du kan optimalisere at data skjema å støtte at tilgangen mønster.
Hvis du ikke gjør det, så du kommer å se disse typer problemer
med disse hurtigtastene.
>> PUBLIKUM: Vel, uunngåelig noen steder kommer til å bli varmere enn andre.
>> RICK Houlihan: Alltid.
Alltid.
Ja, jeg mener det er alltid a-- og igjen, det er
enkelte design patterns vi får gjennom som vil snakke om hvordan du avtale
med disse super store samlinger.
Jeg mener, jeg fikk til å ha dem, hvordan skal vi takle dem?
Jeg fikk en ganske god bruk saken at vi skal snakke om for det.
>> Greit, så la oss snakke om noen kunder nå.
Disse gutta er AdRoll.
Jeg vet ikke om du er kjent med AdRoll.
Du sannsynligvis se dem mye på nettleseren.
De er annonse re-targeting, de er den største annonse re-targeting virksomhet
der ute.
De normalt jevnlig påkjørt 60 milliarder transaksjoner per dag.
De gjør over en million transaksjoner per sekund.
De har fått en ganske enkel tabell struktur, den travleste tabellen.
Det er i utgangspunktet bare en firkanttasten er cookie,
området er den demografiske kategori, og deretter
den tredje attributten er poengsummen.
>> Så vi alle informasjonskapsler i vår nettleser fra disse gutta.
Og når du går til en deltakende kjøpmann,
de i utgangspunktet scorer du på tvers ulike demografiske kategorier.
Når du går til et nettsted og du sier jeg ønsker å se dette ad--
eller i utgangspunktet du ikke sier at-- men når du går til nettsiden
de sier at du ønsker å se denne annonsen.
Og de går får den annonsen fra AdRoll.
AdRoll ser du opp på bordet.
De finner din cookie.
Annonsørene forteller dem, jeg vil ha noen
som er middelaldrende, 40-år gammel mann, i sport.
Og de scorer du i de demografiske og de bestemmer hvorvidt
det er en god annonse for deg.
>> Nå har de en SLA med deres reklame leverandører
å gi sub-10 millisekund respons på hver enkelt forespørsel.
Så de bruker Dynamo DB for dette.
De treffer oss en million forespørsler per sekund.
De er i stand til å gjøre alle sine oppslag, triage alle disse dataene,
og få den add link tilbake til at annonsør på under 10 millisekunder.
Det er egentlig ganske fenomenalt implementering som de har.
>> Disse gutta actually-- er disse gutta.
Jeg er ikke sikker på om det er disse gutta.
Kanskje disse gutta.
Utgangspunktet fortalte us-- nei, jeg tror ikke det var dem.
Jeg tror det var noen andre.
Jeg jobbet med en kunde som fortalte meg
at nå som de har gått til Dynamo DB, de er
bruker mer penger på snacks for deres utvikling team hver måned
enn de bruker på deres database.
Så det vil gi deg en Ideen om kostnadsbesparelser
at du kan få i Dynamo DB er stort.
Greit, dropcam et annet selskap.
Disse fyren er slags of-- hvis du tror av internett av ting, dropcam
er i utgangspunktet internet security video.
Du setter kameraet der ute.
Kameraet har en bevegelsesdetektor.
Noen kommer sammen, utløser en cue point.
Kameraet begynner å ta en stund til det trenger ikke oppdage noen bevegelse lenger.
Setter at videoen opp på internett.
>> Dropcam var et selskap som er utgangspunktet byttet til Dynamo DB
fordi de var opplever enorme voksesmerter.
Og hva de fortalte oss, plutselig petabyte med data.
De hadde ingen anelse om deres tjeneste ville være så vellykket.
Mer inngående video enn YouTube er hva disse gutta får.
De bruker DynamoDB å spore alle metadata på alle sine video viktige punkter.
>> Så de har S3 bøtter de presse alle de binære gjenstander inn.
Og da de har Dynamo DB poster som
peke folk til disse S3 tre stedene.
Når de trenger å se på en video, de ser opp posten i Dynamo DB.
De klikker på linken.
De trekker ned video fra S3.
Så det er litt av hva dette ser ut som.
Og dette er rett fra deres team.
>> Dynamo DB reduserer deres leveringstid for video hendelser
fra fem til ti sekunder.
I deres gamle relasjons butikken, de pleide å ha til å gå og kjøre
flere komplekse spørringer til figuren ut hvilke videoer for å trekke ned,
til mindre enn 50 millisekunder.
Så det er utrolig, utrolig hvor mye ytelse
du kan få når du optimalisere og du tune den underliggende database
å støtte tilgangsmønster.
Halfbrick, disse gutta, hva er det, Fruit Ninja jeg antar er deres greie.
At alle kjører på Dynamo DB.
Og disse gutta, de er en stor utvikling team, stor utvikling
butikk.
>> Ikke en god ops team.
De hadde ikke mye av driftsressurser.
De kjempet for å prøve å holde sin søknad infrastruktur opp
og kjører.
De kom til oss.
De så på at Dynamo DB.
De sa, det er for oss.
De bygget sin helhet applikasjonsrammeverk på den.
Noen virkelig fine kommentarer her fra teamet på deres evne
å nå fokusere på å bygge spillet og ikke
å opprettholde infrastruktur, som
var blitt en enorm mengde av overhead for sitt lag.
Så dette er noe at-- den nytte som du får fra Dynamo DB.
>> All right, komme inn datamodellering her.
Og vi snakket litt om dette til en, en til mange,
og mange til mange type relasjoner.
Og hvordan opprett du de i Dynamo.
I Dynamo DB bruker vi indekser, generelt sett,
å rotere dataene fra en smak til den andre.
Hash nøkler, range nøkler og indekser.
>> I denne spesielle eksempel, som de fleste stater
har en lisensiering krav om at bare ett førerkort per person.
Du kan ikke gå å få to fører lisenser i delstaten Boston.
Jeg kan ikke gjøre det i Texas.
Det er på en måte sånn det er.
Og så på DMV, har vi oppslag, vi ønsker å slå opp førerkort
av personnummer.
Jeg ønsker å slå opp brukerdetaljer av førerkort nummer.
>> Så vi kan ha en brukers tabell som har en firkanttasten på serienummer,
eller personnummer, og forskjellige attributter definert på elementet.
Nå på det bordet jeg kunne definere en GSI som
knipser at rundt som sier at jeg vil ha et firkanttasten på lisensen og deretter
alle de andre elementene.
Nå hvis jeg ønsker å spørre og finne lisensnummer for enhver Social
Security-nummer, kan jeg spørhovedtabellen.
>> Hvis jeg ønsker å spørre, og jeg ønsker for å få trygd
nummer eller andre attributter ved en lisensnummer, kan jeg spørre GSI.
Denne modellen er at ett til en forhold.
Bare en svært enkel GSI, snu disse tingene rundt.
Nå, snakke om en til mange.
En til mange er i utgangspunktet din hash utvalg nøkkelen.
Hvor vi får mye med dette use case er overvåkingsdata.
Monitor data kommer i vanlig intervall, som internett av ting.
Vi får alltid alle disse poster som kommer inn hele tiden.
>> Og jeg ønsker å finne alle målinger mellom en bestemt tidsperiode.
Det er en veldig vanlig spørring i overvåking infrastruktur.
Måten gå om det er å finne en enkel tabell struktur, ett bord.
Jeg har en utstyrsmålingene bord med en firkanttasten på enheten ID.
Og jeg har en rekkevidde tast på tidsstempel, eller i dette tilfellet, det episke.
Og det gjør meg utføre komplekse spørringer mot dette området nøkkelen
og returnere disse postene som står i forhold til resultatet
satt at jeg leter etter.
Og det bygger på at man til mange relasjon
inn i det primære tabellen ved hjelp av firkanttasten, rekkevidde nøkkelen struktur.
>> Så det er slags inne i tabellen i Dynamo DB.
Når jeg definerer en hash og rekkevidde t bordet, jeg er
definerer et en til mange forhold.
Det er en foreldre-barn-forhold.
>> La oss snakke om mange til mange relasjoner.
Og for dette spesielle eksempelet, igjen, kommer vi til å bruke GSI-tallet.
Og la oss snakke om gaming scenario hvor jeg har en gitt bruker.
Jeg ønsker å finne ut alle spillene som han er registrert for eller spille inn.
Og for et gitt spill, I ønsker å finne alle brukerne.
Så hvordan gjør jeg det?
Min bruker spill bord, jeg kommer å ha en firkanttasten for bruker-ID
og en rekke nøkkel av spillet.
>> Slik at en bruker kan ha flere spill.
Det er en en til mange relasjon mellom brukeren og de kampene han spiller.
Og deretter på GSI, Jeg vil snu det rundt.
Jeg skal hash på spillet og Jeg spenner på brukeren.
Så hvis jeg ønsker å få alle Spillet brukerens spille i,
Jeg skal spørre hovedtabellen.
Hvis jeg ønsker å få alle brukere som spiller et bestemt spill,
Jeg søke i GSI.
Så du se hvordan vi gjør dette?
Du bygger disse GSI er å støtte bruk tilfellet programmet, tilgangs
mønster, søknaden.
>> Hvis jeg trenger å spørre om denne dimensjonen, la
meg å opprette en indeks på denne dimensjonen.
Hvis jeg ikke gjør det, jeg bryr meg ikke.
Og avhengig av brukstilfellet, I kan trenge indeksen eller jeg kanskje ikke.
Hvis det er en enkel en til mange, den primære tabellen er fine.
Hvis jeg trenger å gjøre disse mange til mange er, eller jeg trenger å gjøre en til seg,
så kanskje jeg trenger til andre indeksen.
Så det kommer an på det jeg prøver å gjøre
og hva jeg prøver å få dyktig.
>> Sannsynligvis jeg ikke kommer til å bruke for mye tid på å snakke om dokumenter.
Dette blir litt, sannsynligvis, dypere enn vi trenger å gå inn.
La oss snakke litt om rike spør uttrykk.
Så i Dynamo DB har vi evnen til å skape
det vi kaller projeksjon uttrykk.
Projeksjon uttrykk er rett og slett plukke felt eller verdiene
som du vil vise.
OK, så jeg gjør et valg.
Jeg gjør en spørring mot Dynamo DB.
Og jeg sier, vet du hva, showet me bare de fem stjerners anmeldelser
for dette spesielle produkt.
Så det er alt jeg ønsker å se.
Jeg ønsker ikke å se hele andre attributter for rad,
Jeg vil bare se dette.
Det er akkurat som i SQL når du si velger stjerne eller fra bordet,
du får alt.
Når jeg sier velger navn fra bordet, jeg får bare ett attributt.
Det er samme type ting i Dynamo DB eller annen NoSQL-databaser.
Filteruttrykk tillate meg å utgangspunktet kutte resultatet satt ned.
Så jeg gjør et søk.
Spørring kan komme tilbake med 500 elementer.
Men jeg vil bare de elementene som har en egenskap som sier dette.
OK, så la oss filtrere ut de elementene som ikke samsvarer med det aktuelle søket.
Så vi har filteruttrykk.
>> Filteruttrykk kan kjøres på en hvilken som helst attributt.
De er ikke som range spørringer.
Heve spørringer er mer selektive.
Filtrer spørsmål krever meg å gå få hele resultatet satt og så
skjære ut dataene jeg ikke vil ha.
Hvorfor er det viktig?
Fordi jeg leste det hele tatt.
I en spørring, kommer jeg til å lese og det kommer til å bli en gigantisk om data.
Og så kommer jeg til å skjære ut det jeg trenger.
Og hvis jeg bare carving ut en par rader, så det er OK.
Det er ikke så ineffektiv.
>> Men hvis jeg leser en hel haug av data, bare for å skjære ut ett element,
så jeg kommer til å bli bedre av ved hjelp av en rekke spørsmål,
fordi det er mye mer selektiv.
Det kommer til å spare meg mye penger, fordi jeg betale for at lese.
Der resultatene som kommer tilbake krysse at ledningen kan være mindre,
men jeg betaler for å lese.
Så forstå hvordan du får dataene.
Det er veldig viktig i Dynamo DB.
>> Betingelsesuttrykk, dette er hva du kan kalle optimistisk låsing.
Oppdater IF eksisterer, eller hvis denne verdien tilsvarer det jeg angir.
Og hvis jeg har en tidsangivelse på en posten, jeg kan lese dataene.
Jeg kan endre disse dataene.
Jeg kan gå skrive at data tilbake til databasen.
Hvis noen har endret posten, tidsstempelet kan ha endret seg.
Og på den måten min betinget Oppdateringen kan si oppdatering
hvis tidsstempel er lik denne.
Eller oppdateringen vil mislykkes fordi noen oppdatert posten i mellomtiden.
>> Det er hva vi kaller optimistisk låsing.
Det betyr at noen kan komme inn og endre det,
og jeg kommer til å oppdage det når jeg går tilbake til å skrive.
Og så kan jeg faktisk lese at data og si, oh, han endret dette.
Jeg trenger å ta hensyn til det.
Og jeg kan endre data i min spille inn og bruke en annen oppdatering.
Så du kan fange de inkrementelle oppdateringer som oppstår mellom tiden
at du leser data og gang du kan skrive data.
>> PUBLIKUM: Og filteret uttrykket egentlig betyr ikke
i antall eller not--
>> [Interposing VOICES]
RICK Houlihan: Jeg vil ikke få for mye inn i dette.
Dette er et reservert nøkkelord.
Pundet syn er en reservert søkeord i Dynamo DB.
Hver database har sin egen reservert navn for samlinger du ikke kan bruke.
Dynamo DB, hvis du angir et pund foran denne,
du kan definere disse navnene opp ovenfor.
Dette er verdien en referert.
Det er nok ikke den beste syntaks til har oppe for denne diskusjonen,
fordi det kommer inn noen real-- Jeg ville ha snakket mer
om det på et dypere nivå.
>> Men nok til å si, dette kunne være spørring skanner der de views--
heller pund utsikt er større enn 10.
Det er en numerisk verdi, ja.
Hvis du vil, kan vi snakke om at etter diskusjonen.
Greit, så vi får inn noen scenarier i beste praksis
hvor vi kommer til å snakke om noen apps her.
Hva er de bruksmåter for Dynamo DB.
Hva er design mønstre i Dynamo DB.
>> Og det første vi kommer til å snakk om er internett av ting.
Så vi får mye of-- antar jeg, det som er it mer enn 50%
av trafikken på internett i disse dager faktisk er generert av maskiner,
automatiserte prosesser, ikke av mennesker.
Jeg mener denne tingen denne tingen som du bære rundt i lommen,
hvor mye data som at ting er faktisk sender rundt uten deg
vet det er helt utrolig.
Din plassering, informasjon om hvor fort du skal.
Hvordan tror du Google Maps fungerer når de forteller deg hva trafikken er.
Det er fordi det er millioner og millioner av mennesker kjører rundt
med telefoner som sender data over stedet hele tiden.
Så en av de tingene om denne typen data
som kommer inn, overvåkingsdata, logg data, tidsseriedata, er det
vanligvis bare interessant for en liten bit av gangen.
Etter den tid, er det ikke så interessant.
Så vi snakket om, ikke la disse tabellene vokse uten grenser.
Ideen her er at jeg kanskje har fått 24 timer igjen av hendelser i min varme tabellen.
Og det hot tabellen kommer til å være klargjort på en svært høy rente,
fordi det tar mye data.
Det tar mye av data og jeg leser det mye.
Jeg har fått mange operasjon spørringer som kjører mot data.
>> Etter 24 timer, hei, du Vet du hva, jeg bryr meg ikke.
Så kanskje hver midnatt jeg roll mitt bord over til en ny tabell
og jeg deprovision denne tabellen.
Og jeg skal ta RCU og WCU er nede fordi 24 timer senere
Jeg kjører ikke så mange spørringer mot at data.
Så jeg kommer til å spare penger.
Og kanskje 30 dager senere jeg ikke engang trenger å bry seg om det hele.
Jeg kunne ta WCU s helt ned til en,
fordi du vet hva, er det aldri kommer til å bli skrevet til.
Dataene er 30 dager gamle.
Det forandrer aldri.
>> Og det er nesten aldri kommer til å få lese, så la oss bare ta det RCU ned til 10.
Og jeg sparer massevis av penger på denne data, og bare betale for mine varme data.
Så det er det viktigste å se på når du ser på en tidsserie
data som kommer inn i volum.
Dette er strategier.
Nå kunne jeg bare la det alle gå til samme bord
og bare la det bordet vokse.
Etter hvert kommer jeg til å se ytelsesproblemer.
Jeg er nødt til å begynne å arkivere noen av disse data av bordet,
hva ikke.
>> La oss mye bedre designe din søknad
slik at du kan operere på denne måten rett.
Så det er bare automatisk i applikasjonskoden.
Ved midnatt hver kveld den ruller tabellen.
Kanskje det jeg trenger er en glid vinduet i 24 timer med data.
Så på en jevnlig basis er jeg kalle data av bordet.
Jeg trimming det med en Cron jobb og jeg setter det
på disse andre tabeller, det du trenger.
Så hvis en roll fungerer, det er flott.
Hvis ikke, trimme den.
Men la oss holde det varmt data vekk fra kalde data.
Det vil spare deg for mye penger og gjøre tabellene mer utøvende.
Så neste ting vi skal snakke om er produktkatalogen.
Produktkatalog er ganske vanlig brukstilfelle.
Dette er faktisk en veldig vanlig mønster at vi vil se i en rekke ting.
Du vet, Twitter for eksempel en varm tweet.
Alle som kommer og gripe tak som tweet.
Produktkatalog, fikk jeg et salg.
Jeg fikk en varm salg.
Jeg fikk 70.000 henvendelser per andre kommer etter et produkt
beskrivelse av min produktkatalog.
Vi ser dette i person drift ganske mye.
Så hvordan håndtere vi med det?
Det er ingen måte å håndtere det.
Alle mine brukere ønsker å se samme stykke data.
De kommer inn, samtidig.
Og de er alle gjør forespørsler for samme stykke data.
Dette gir meg som hurtigtast, som store røde stripe på min diagram som vi ikke liker.
Og det er det som ser ut som.
Så over nøkkelen min plass jeg får hamret i salg elementer.
Jeg får ikke noe annet sted.
>> Hvordan lindre jeg dette problemet?
Vel, vi lindre dette med cache.
Cache, sette deg i utgangspunktet en in-memory skillevegg foran databasen.
Vi har klart [Uhørbart] cache, hvordan du
kan sette opp din egen cache, [uhørbart] cache [? d,?] hva du vil.
Sette det opp foran databasen.
Og på den måten du kan lagre disse dataene fra disse hurtigtastene opp i at cache
plass og lese gjennom cache.
>> Og da de fleste av din leser begynne å se slik ut.
Jeg fikk alle disse cache treffer deg her og jeg fikk ingenting skjer her nede
fordi database sitter bak cache og leser aldri komme gjennom.
Hvis jeg endrer dataene i database, må jeg oppdatere cache.
Vi kan bruke noe som damper å gjøre det.
Og jeg skal forklare hvordan det fungerer.
Greit, meldinger.
E-post, vi alle bruker e-post.
>> Dette er et ganske godt eksempel.
Vi har fått en slags meldinger tabellen.
Og vi fikk innboks og utboks.
Dette er hva SQL ville se ut til å bygge på at innboksen.
Vi slags bruker samme type av strategi å bruke GSI-tallet, GSI s
for min innboks og min utboks.
Så jeg fikk rå meldinger kommer inn i min meldinger tabellen.
Og den første tilnærming til dette kan være, sier, OK, ikke noe problem.
Jeg har fått rå meldinger.
Meldinger som kommer [uhørbart], Meldingen ID, det er flott.
Det er min unike hash.
Jeg kommer til å lage to GSI er, en for min innboks, en for min utboks.
Og det første jeg skal gjøre er jeg skal si min firkanttasten er
kommer til å være mottaker og Jeg kommer til å ordne på dato.
Dette er fantastisk.
Jeg fikk min fin utsikt her.
Men det er et lite problem her.
Og du kjører inn i dette i relasjonsdatabaser også.
De kalte vertikalt partisjonering.
Du ønsker å holde store data bort fra lite data.
>> Og grunnen er fordi jeg må gå lese elementer for å få attributtene.
Og hvis mine organer er alle på her, deretter lese bare noen få elementer
hvis kroppen min lengde er gjennomsnitt 256 kilobyte hver,
regnestykket blir ganske stygg.
Så sier jeg ønsker å lese David innboks.
David innboks har 50 elementer.
Gjennomsnittlig og størrelsen er 256 kilobyte.
Her er min bytteforhold for RCU s er fire kilobyte.
>> OK, la oss gå med slutt konsekvent leser.
Jeg er fortsatt spiser 1600 RCU s bare for å lese David innboks.
Au.
OK, nå la oss tenke om hvordan programmet fungerer.
Hvis jeg er i en e-post-appen og Jeg ser på min innboks,
og jeg ser på kroppen av hver melding, Nei, jeg ser på oppsummeringene.
Jeg ser på bare overskriftene.
Så la oss bygge en tabell struktur som ser mer ut som.
>> Så her er det informasjon at min arbeidsflyt trenger.
Det er i min innboks GSI.
Det er den dato, avsender, emnet, og deretter
meldingen ID, som peker tilbake til meldinger bordet
hvor jeg kan få kroppen.
Vel, disse vil være rekord IDer.
De vil peke tilbake til element IDer på Dynamo DB tabellen.
Hver indeks alltid creates-- alltid har elementet
ID som en del of-- at kommer med indeksen.
>> Greit.
PUBLIKUM: Det forteller den hvor den er lagret?
RICK Houlihan: Ja, det forteller exactly-- det er akkurat det det gjør.
Det står her er min re posten.
Og det vil peke det tilbake til min re posten.
Nettopp.
OK, så nå innboksen min er faktisk er mye mindre.
Og dette støtter faktisk arbeidsflyten av en e-post-appen.
Så innboksen min, jeg klikker.
Jeg går sammen og jeg klikker på meldingen, det er da jeg må gå får kroppen,
fordi jeg kommer til å gå til et annet syn.
Så hvis du tenker på MVC type rammeverk, modell view controller.
>> Modellen inneholder data at utsikten behov
og styreenheten kommuniserer med.
Når jeg endre ramme, når Jeg endre perspektivet,
det er greit å gå tilbake til server og fylle den på modellen,
fordi det er hva brukeren forventer.
Når de endrer utsikt, det er da vi kan gå tilbake til databasen.
Så e-post, klikk.
Jeg ser for kroppen.
Rundtur.
Gå få kroppen.
>> Jeg leser mye mindre data.
Jeg bare leser de organer som David trenger når han trenger dem.
Og jeg er ikke brenne i 1600 RCU oss bare for å vise sin innboks.
Så nå at-- dette er veien som LSI eller GSI-- Jeg beklager,
GSI, ville fungere.
Vi har fått vår hash på mottakeren.
Vi har utvalget tasten på dato.
Og vi har fått de forventede attributter at vi bare trenger å støtte synet.
>> Vi roter det til utboksen.
Hash på avsenderen.
Og i hovedsak, har vi veldig fin, ren utsikt.
Og det er basically-- vi har denne fine meldinger
tabell som blir spredt pent fordi det er hash bare, hashet melding ID.
Og vi har to indekser som roterer ut av tabellen.
All right, så Ideen her er ikke holde de store data og denne lille data
i lag.
Partition vertikalt, partisjonere disse tabellene.
Ikke lese data du ikke må.
Greit, gaming.
Vi liker alle spillene.
Minst Jeg liker spill da.
Så noen av de tingene at vi forholde seg til når
vi tenker om spill, ikke sant?
Gaming i disse dager, spesielt mobil gaming, handler om tenkning.
Og jeg kommer til å rotere her litt bort fra DynamoDB.
Jeg kommer til å få inn noen av diskusjonen
rundt noen av andre AWS teknologier.
>> Men ideen om gaming er å tenke om i form av APIer, APIer som er,
generelt sett, HTTP og JSON.
Det er hvordan mobile spill slags samhandle med sine tilbake ender.
De gjør JSON innlegg.
De får data, og det er alt, generelt sett, i fin JSON APIer.
>> Ting som får venner, få de leaderboard, utveksle data,
brukergenerert innhold, skyve tilbake til systemet,
disse er typer ting at vi kommer til å gjøre.
Binary aktivum data, disse dataene ikke kan sitte i databasen.
Dette kan sitte i en objekt butikken, ikke sant?
Men databasen skal ender opp med å fortelle systemet,
forteller programmet hvor du skal gå få det.
Og uunngåelig, multiplayer servere, back end infrastruktur,
og konstruert for høy tilgjengelighet og skalerbarhet.
Så dette er ting som vi alle ønsker i gaming infrastruktur i dag.
>> Så la oss ta en titt på hva som ser ut som.
Fikk en kjerne bakenden, veldig grei.
Vi har et system her med flere tilgjengelighet soner.
Vi snakket om AZS som being-- tror av dem som egne datasentre.
Mer enn en datasenter per AZ, men det er OK,
bare tenke på dem som separate data sentre som er geografisk
og feil isolert.
>> Vi kommer til å ha en par EC2 instanser.
Vi kommer til å ha noen back end server.
Kanskje hvis du er en arv arkitektur, er vi
bruker det vi kaller RDS, relasjonsdatabasetjenester.
Kan være MSSQL, MySQL, eller noe sånt.
Dette er måten en masse søknader er utformet i dag.
>> Vel vi kanskje vil gå med dette er når vi skalere ut.
Vi vil gå foran og sette S3 bøtte der oppe.
Og at S3 bøtte, i stedet for å tjene opp disse objektene fra vår servers--
vi kunne gjøre det.
Du setter all din binære objekter på dine servere
og du kan bruke de som server instanser for å tjene disse dataene opp.
Men det er ganske dyrt.
>> Bedre måte å gjøre er å gå foran og sette disse objektene i en S3 bøtte.
S3 er et objekt repositories.
Det er bygget spesielt for tjene opp slike ting.
Og la disse klientene be direkte fra disse objekt bøtter,
avlaste serverne.
Så vi begynner å skalere ut her.
>> Nå fikk vi brukere over hele verden.
Jeg fikk brukere.
Jeg må ha innhold lokalt ligger i nærheten av disse brukerne, ikke sant?
Jeg har opprettet en S3 bøtte som min kilde depotet.
Og jeg skal fram at med den CloudFront distribusjon.
>> CloudFront er en CD og en Content Delivery Network.
I utgangspunktet tar det data som du angir og bufrer det over hele internett
slik at brukerne overalt kan ha en meget rask respons når
de ber om disse stedene.
>> Så du får en idé.
Dere slags utnytte alle aspekter av AWS her for å få dette gjort.
Og til slutt, vi kaster i en auto-skalering gruppe.
Så våre AC2 tilfeller av våre spillservere,
som de begynner å bli travlere og travlere og travlere,
de vil bare spinne en annen eksempel spinne et annet eksempel,
spinne et annet eksempel.
Så teknologien AWS har, det lar deg spesifisere parametere
rundt der serverne vil vokse.
Så du kan ha n antall servere det ut til enhver tid.
Og hvis lasten går bort, vil de krympe, vil antallet krympe.
Og hvis lasten kommer tilbake, det vil vokse ut igjen, elastisk.
>> Så dette ser flott ut.
Vi har fått mange EC2 instanser.
Vi kan sette cache i foran databasene,
prøve og akselerere databasene.
Den neste trykkpunkt typisk folk ser
er de skalere et spill ved hjelp av en relasjonsdatabasesystem.
Jeez, databasen Forestillingen er forferdelig.
Hvordan forbedrer vi det?
La oss prøve å sette cache foran det.
>> Vel, cache fungerer ikke så stor i spill, ikke sant?
For spill, skriving er smertefullt.
Spill er veldig skrive tung.
Cache fungerer ikke når du er skrive tung fordi du har alltid
fikk å oppdatere cache.
Du oppdaterer cache, det er irrelevant å bli caching.
Det er faktisk bare ekstra arbeid.
>> Så hvor går vi her?
Du har en stor flaskehals der nede i databasen.
Og stedet å gå åpenbart er partisjonering.
Partisjonering er ikke lett å gjøre når du er
arbeider med relasjonsdatabaser.
Med relasjonsdatabaser, er du ansvarlig for å administrere, effektivt,
nøkkelen plass.
Du sier brukerne mellom A og M gå her, mellom N og Z gå dit.
Og du bytter på tvers av søknaden.
Så du arbeider med denne partisjonen datakilde.
Du har transaksjons begrensninger som ikke spenner partisjoner.
Du har alle typer messi at du er
arbeider med der nede prøver å forholde seg til skalering ut
og å bygge en større infrastruktur.
Det er bare ikke morsomt.
>> PUBLIKUM: Så sier du at økende kildepunkter raskere
prosessen?
RICK Houlihan: Økende?
PUBLIKUM: Source poeng.
RICK Houlihan: Source poeng?
PUBLIKUM: Fra informasjonen, hvor informasjonen kommer fra?
RICK Houlihan: No.
Det jeg sier er å øke antall partisjoner i datalageret
forbedrer gjennomstrømming.
Så hva er det som skjer her er brukere kommer inn i EC2 eksempel her oppe,
vel, hvis jeg trenger en bruker 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, de så de er alle lagret i forskjellige noder?
>> RICK Houlihan: Ja.
Tenk på disse som forskjellige siloer av data.
Så du trenger å gjøre dette.
Hvis du prøver å gjøre dette, hvis du prøver
å skalere på en relasjons plattform, dette er hva du gjør.
Du tar data og du klipper den ned.
Og du partisjonere den på tvers flere forekomster av databasen.
Og du administrerer alt på applikasjons tier.
Det er ikke morsomt.
Så hva gjør vi ønsker å gå?
Vi ønsker å gå DynamoDB, fullstendig styrt, NoSQL datalageret, bestemmelse gjennomstrømming.
Vi bruker sekundære indekser.
Det er i utgangspunktet HTTP API og omfatter dokumentstøtte.
Så du trenger ikke å bekymre deg om noe av det partisjonering.
Vi gjør alt for deg.
Så nå, i stedet, du bare skrive til bordet.
Hvis tabellen må være partisjonert, som skjer bak kulissene.
Du er helt isolert fra det som en utvikler.
Så la oss snakke om noen av de bruksmåter
at vi kjører inn i gaming, felles gaming scenarier, leaderboard.
Så du har brukere som kommer inn, de BoardNames at de er
på, resultatet for denne brukeren.
Vi kan hashing på BrukerID, og da har vi hold til spillet.
Så hver brukeren ønsker å se hele spillet han har spilt
og alle hans bestenotering over hele spillet.
Så det er hans personlige leaderboard.
>> Nå ønsker jeg å gå i, og jeg ønsker å get-- så jeg får disse personlige topplister.
Det jeg ønsker å gjøre er å gå får toppscore på tvers av alle brukere.
Så hvordan gjør jeg det?
Da min rekord er hashet på den UserID, varierte på spillet,
vel jeg kommer til å gå videre og restrukturere, skape en GSI,
og jeg kommer til å restrukturere disse dataene.
>> Nå skal jeg til hasj på BoardName, som er spillet.
Og jeg kommer til å variere på topp score.
Og nå har jeg laget forskjellige skuffer.
Jeg bruker den samme tabellen, den samme varen data.
Men jeg lage en bøtte som gir meg en samling av topp score av spillet.
>> Og jeg kan spørre denne tabellen å få den informasjonen.
Så jeg har satt dette søket mønster opp til være støttet av en sekundær indeks.
Nå kan de bli sortert etter BoardName og sortert etter TopScore, avhengig av.
Så du kan se, er disse typene av bruk tilfeller du får i gaming.
En annen god bruk tilfelle vi får i gaming er utmerkelser og som har vunnet priser.
Og dette er en stor use case der vi kaller sparsom indekser.
Sparsom indekser er evne til å generere
en indeks som ikke nødvendigvis inneholder hver enkelt element på bordet.
Og hvorfor ikke?
Fordi attributt som er å være indeksert ikke finnes på hvert element.
>> Så i denne spesielle bruke saken, jeg sa:
vet du hva, jeg kommer til å opprette et attributt kalt Award.
Og jeg kommer til å gi hver bruker som har en pris som attributt.
Brukere som ikke har tildelingene er ikke kommer til å ha som attributt.
Så når jeg oppretter indeksen, de eneste brukerne
som kommer til å vise opp i indeksen er
de som faktisk har vunnet priser.
Så det er en fin måte å kunne å opprette filtrerte indekser som
er veldig, veldig selektiv som ikke gjør det har å indeksere hele tabellen.
>> Så vi får lite tid her.
Jeg kommer til å gå videre og hoppe ut og hoppe over dette scenariet.
Snakke litt om--
>> PUBLIKUM: Kan jeg stille et raskt spørsmål?
En er skrive tung?
RICK Houlihan: Hva er?
PUBLIKUM: Skriv tung.
RICK Houlihan: Skriv tung.
La meg se.
>> PUBLIKUM: Eller er det ikke noe du kan bare
stemme til i løpet av sekunder?
RICK Houlihan: Vi går gjennom stemmegivning scenario.
Det er ikke så ille.
Har dere har noen få minutter?
OK.
>> Så vi skal snakke om stemmegivning.
Så sanntid stemmegivning, har vi krav til stemmegivning.
Kravene er at vi tillater hver person til å stemme bare én gang.
Vi ønsker ingen å være i stand å endre sin stemme.
Vi ønsker sanntid aggregering og analyser for demografi
at vi kommer til å være viser til brukere på nettstedet.
>> Tenk på dette scenariet.
Vi jobber mye med virkeligheten TV-programmer der de er
gjør disse eksakte type ting.
Så du kan tenke på det scenariet vi har millioner på millioner
tenåringsjenter der med sine mobiltelefoner
og stemmegivning, og stemmegivning, og stemme for hvem de er
synes å være den mest populære.
Så dette er noen av de kravene vi går tom.
>> Og så den første ta i å løse dette problemet
ville være å bygge en veldig enkelt program.
Så jeg har fått dette programmet.
Jeg har noen velgere der ute.
De kommer i, de treffer stemme app.
Jeg har fått noen rå stemmer bord Jeg vil bare dumpe disse stemmer inn.
Jeg vil ha noen samlet stemmer tabell som
vil gjøre mine analyser og demografi, og vi vil sette alt dette inn der.
>> Og dette er flott.
Livet er godt.
Livet er bra før vi finner ut at det er alltid bare én eller to
folk som er populære i et valg.
Det finnes bare én eller to ting at folk virkelig bryr seg om.
Og hvis du stemme på skala, plutselig er jeg
kommer til å bli hamret i helvete ut av to kandidater, en eller to kandidater.
Et svært begrenset antall elementer folk synes å være populære.
>> Dette er ikke en god design mønster.
Dette er faktisk en veldig dårlig design mønster
fordi det skaper akkurat det vi snakket om som var hurtigtaster.
Hurtigtaster er noe vi ikke liker.
>> Så hvordan løser vi det?
Og virkelig, er måten å fikse dette ved å ta disse kandidat bøtter
og for hver kandidat vi har, vi kommer til å legge en tilfeldig verdi,
noe som vi vet, tilfeldig verdi mellom en og 100,
mellom 100 og 1000, eller mellom en og tusen,
men mange tilfeldige verdier du vil føye på enden av at kandidaten.
>> Og hva har jeg egentlig gjort da?
Hvis jeg bruker kandidaten ID som bøtte til å samle stemmer,
hvis jeg har lagt til en tilfeldig nummer til slutten av det,
Jeg har laget nå 10 bøtter, en hundre bøtter, tusen bøtter
at jeg samle stemmer over.
>> Så jeg har millioner, og millioner, og millioner av plater som kommer inn
for disse kandidatene, er jeg nå spre de stemmer over Kandidat a_1
gjennom Kandidat A_100, fordi hver gang en stemme kommer inn,
Jeg genererer en tilfeldig en verdi mellom 100 og.
Jeg vinne den på slutten av Kandidaten vedkommendes stemme for.
Jeg dumping den inn som bøtte.
>> Nå på baksiden, jeg vet at jeg fikk hundre bøtter.
Så når jeg ønsker å gå videre og samle stemmene,
Jeg leste fra alle de bøtter.
Så jeg gå videre og legge til.
Og så jeg den scatter samle der jeg går ut og si hei,
vet du hva, dette kandidatens nøkkel mellomrom er over hundre bøtter.
Jeg kommer til å samle all Stemmer fra disse hundre bøtter.
Jeg kommer til å aggregere dem, og jeg kommer til å si,
Kandidat A har nå stemmetall telling av x.
>> Nå er både skrive spørring og lese søket
er pent fordelt fordi jeg skriver på tvers
og jeg leser over hundrevis av nøkler.
Jeg skriver ikke og lesing over en nøkkel nå.
Så det er et flott mønster.
>> Dette er faktisk trolig en av de viktigste utformingen
mønstre for skalaen i NoSQL.
Du vil se denne typen design mønster i hver smak.
MongoDB, DynamoDB, det gjør det ikke Uansett, vi alle har til å gjøre dette.
Fordi når du arbeider med de store samlinger,
du må finne ut en måte å spre dem ut over bøtter.
Så dette er måten du gjør det.
Greit, så hva du gjør akkurat nå
er du handel av lese- Kostnaden for skrive skalerbarhet.
Kostnaden for min lese er litt mer komplisert
og jeg må gå lese fra en hundre bøtter i stedet for én.
Men jeg er i stand til å skrive.
Og min gjennomstrømning, min skrive gjennomstrømning er utrolig.
Så det er vanligvis en verdifull teknikk for skalering DynamoDB,
eller noen NoSQL database for den saks skyld.
Så vi fant ut hvordan å skalere den.
Og vi skjønte hvordan eliminere våre hurtigtaster.
Og dette er fantastisk.
Og vi fikk denne fine system.
Og det har gitt oss veldig riktig å stemme fordi vi har rekord stemme de-lettlurt.
Det er bygget inn DynamoDB.
Vi snakket om betingede rettigheter.
>> Når en velger kommer inn, setter en innsats på bordet,
de setter inn med sine velgere ID, hvis de prøver å sette inn en annen stemme,
Jeg gjør en betinget skrive.
Si bare skrive dette dersom dette ikke eksisterer.
Så så snart jeg ser at at stemmen er rammet bordet,
ingen andre kommer til å bli stand til å sette sin stemme.
Og det er fantastisk.
Og vi økes våre kandidat tellere.
Og vi gjør vårt demografi og alt det der.
Men hva skjer hvis min søknaden faller over?
Nå plutselig stemmer er kommer inn, og jeg
vet ikke om de er å få behandlet i mine analyser og demografi
lenger.
Og når programmet kommer opp igjen, hvordan
faen vet jeg hva stemmer har blitt behandlet og hvor skal jeg begynne?
>> Så dette er et reelt problem når du begynner å se på denne typen scenario.
Og hvordan løser vi det?
Vi løser det med hva vi kalle DynamoDB Streams.
Strømmer er en tid bestilt og partisjonert endringslogg for hver tilgang
til bordet, hvert skrive adgang til bordet.
Eventuelle data som er skrevet til Tabellen viser opp på strømmen.
>> Det er i utgangspunktet en 24 timers kø.
Elementer treffer bekken, de lever i 24 timer.
De kan leses flere ganger.
Garantert å bli levert bare en gang til strømmen,
kan leses n antall ganger.
Så uansett hvor mange prosesser du vil konsumere disse dataene, kan du fordøye det.
Den vil vises hver oppdatering.
Hver write vil bare vises en gang på strømmen.
Så du trenger ikke å bekymre deg om å behandle den to ganger
fra den samme prosessen.
>> Det er strengt bestilles per element.
Når vi sier tid bestilt og partisjonert,
du vil se per partisjon på strømmen.
Du vil se elementer, oppdateringer i orden.
Vi er ikke garanterer på strømmen som du er
kommer til å få hver transaksjon i størrelsesorden på tvers av elementene.
>> Så bekker er idempotent.
Må vi alle vet hva idempotent betyr?
Idempotent betyr at du kan gjøre det over, og igjen, og igjen.
Resultatet kommer til å bli det samme.
>> Strømmer er idempotent, men de må være
Spilte fra startpunktet, uansett hvor du velger, til slutten,
eller de vil ikke medføre i de samme verdier.
>> Samme med MongoDB.
MongoDB har en konstruksjon de kaller oplog.
Det er nøyaktig samme konstruksjon.
Mange NoSQL-databaser har denne konstruksjonen.
De bruker den til å gjøre ting som replikering, som
er akkurat hva vi gjør med bekker.
PUBLIKUM: Kanskje en kjetterske spørsmålet, men du
snakke om apps gjør ned en så videre.
Er bekker garantert å aldri muligens gå ned?
RICK Houlihan: Yeah, bekker er garantert å aldri gå ned.
Vi forvalter infrastrukturen bak. bekker automatisk
distribuere i sin autoskalering gruppe.
Vi vil gå gjennom en liten litt om hva som skjer.
>> Jeg skal ikke si at de ikke er garantert å aldri gå ned.
Elementene er garantert skal vises i bekken.
Og strømmen vil være tilgjengelig.
Så hva går ned eller kommer tilbake opp, skjer det under.
Det covers-- det er OK.
All right, slik at du får forskjellige view typer av skjermen.
Typene view som er viktige for en programmerer vanligvis er, hva var det?
Jeg får det gamle synet.
Når en oppdatering treffer bordet, det vil skyve det gamle synet til strømmen
slik at data kan arkivere eller endring kontroll, endring identifikasjon, endring
ledelse.
>> Det nye bildet, hva det er nå etter oppdateringen, det er en annen type visning
du kan få.
Du kan få både den gamle og nye bilder.
Kanskje jeg vil ha dem begge.
Jeg ønsker å se hva det var.
Jeg ønsker å se hva det endret til.
>> Jeg har en compliance typen prosess som kjører.
Det er behov for å kontrollere at når disse ting endrer seg,
at de er innenfor visse grenser eller innenfor visse rammer.
>> Og så kanskje jeg bare trenger å vite hva som er endret.
Jeg bryr meg ikke hva elementet endret.
Jeg trenger ikke å trenge å vite hvilke attributter endret.
Jeg trenger bare å vite at elementene blir berørt.
Så er det disse typer visninger at du får av strøm
og du kan samhandle med.
>> Søknaden som forbruker strøm,
dette er slags måten dette fungerer.
DynamoDB kunde om å presse data til tabellene.
Strømmer distribuere på det vi kaller skår.
Shards er skalert uavhengig av bordet.
De trenger ikke stille opp helt til partisjonene av tabellen.
Og grunnen er fordi de stiller seg opp
til kapasiteten, den nåværende kapasitet av tabellen.
>> De distribuerer i deres egen auto skalering gruppe,
og de begynner å spinne ut avhengig på hvor mange skrivinger kommer inn,
hvor mange reads-- egentlig er det skriver.
Det er ingen reads-- men hvordan mange skriver kommer inn.
>> Og deretter på ryggen slutt, har vi det vi
kalle en KCL, eller Kinesis klientbiblioteket.
Kinesis er en strøm av data produksjonsteknologi fra Amazon.
Og bekker er bygget på det.
>> Så du bruker en KCL aktivert program for å lese bekken.
Kinesis Client Library faktisk forvalter arbeiderne for deg.
Og det gjør også noen interessante ting.
Det vil skape noen tabeller opp i DynamoDB tabell
å spore hvilke elementer har blitt behandlet.
Så denne måten hvis den faller tilbake, hvis den faller over og kommer og får
sto opp igjen, kan det avgjøre hvor var det i behandlingen av strømmen.
>> Det er veldig viktig når du snakker om replikering.
Jeg trenger å vite hva data ble blitt behandlet
og hvilke data som ennå ikke er behandlet.
Så KCL bibliotek for bekker vil gi deg mye av den funksjonaliteten.
Det tar vare på all rengjøring.
Det står opp en arbeidstaker for hver fragmentet.
Det skaper en administrativ bord for hver Shard, for hver arbeidstaker.
Og som de arbeidere brann, de opprettholder disse tabellene
slik at du vet denne posten ble lest og behandlet.
Og så på den måten hvis prosessen dør og kommer tilbake på nettet,
det kan fortsette akkurat der den tok av.
>> Så vi bruker denne for cross-regionen replikering.
Mange kunder har behov for å flytte data eller deler av sine datatabeller
rundt til forskjellige regioner.
Det er ni regioner hele verden.
Så det kan være en need-- jeg kan ha brukere i Asia, brukere
i østkysten av USA.
De har forskjellige data som må være lokalt fordelt.
Og kanskje en bruker flyr fra Asia over til USA,
og jeg ønsker å replikere hans data med ham.
Så når han får ut av flyet, har han en god opplevelse ved å bruke sin mobil app.
>> Du kan bruke cross-regionen replikering biblioteket for å gjøre dette.
I utgangspunktet har vi gitt to teknologiene.
One er en konsoll applikasjon du kan stå opp på egen hånd EC2 eksempel.
Det kjører ren replikering.
Og da vi ga deg biblioteket.
Biblioteket kan du bruke til å bygge din egen søknad hvis du
ønsker å gjøre gale ting med at data-- filter, replikere bare en del av den,
rotere data, flytte den til en annen tabell, så videre og så videre.
Så det er litt av hva som ser ut som.
>> DynamoDB Streams kan være behandlet av det vi kaller Lambda.
Vi nevnte litt om hendelsen drevne program arkitekturer.
Lambda er en viktig del av det.
Lambda er kode som fyrer on demand som respons på en bestemt hendelse.
En av disse arrangementer kan være en posten vises på strømmen.
Hvis en post vises på stream, vi kaller dette Java funksjonen.
Vel, dette er Javascript, og Lambda støtter Node.js, Java, Python,
og vil snart støtte andre språk også.
Og nok til å si, det er ren kode.
Skriv i Java, definerer du en klasse.
Du skyver JAR opp i Lambda.
Og så kan du spesifisere hvilken klasse å ringe som svar på hvilken hendelse.
Og så Lambda infrastruktur bak som vil kjøre denne koden.
>> Den koden kan behandle poster utenfor stream.
Det kan gjøre noe den ønsker med den.
I dette eksempelet, er alt vi egentlig gjør er å logge attributtene.
Men dette er bare koden.
Koden kan gjøre noe, ikke sant?
>> Så du kan rotere disse dataene.
Du kan lage et derivat visning.
Hvis det er en dokumentstruktur, du kan flate strukturen.
Du kan lage alternative indekser.
Alle slags ting du kan gjøre med DynamoDB Streams.
>> Og egentlig, det er hva det ser ut.
Så du får disse oppdateringene kommer inn.
De kommer av strengen.
De er lest av Lambda-funksjonen.
De rotere data og skyve den opp i avledede tabeller,
varsle eksterne systemer for endring, og skyve data inn ElastiCache.
>> Vi snakket om hvordan å sette cache foran database for at omsetningen
scenario.
Vel hva skjer hvis jeg oppdatere varebeskrivelsen?
Vel, hvis jeg hadde en Lambda funksjon som kjører på det bordet,
hvis jeg oppdaterer varebeskrivelsen, det vil plukke opp posten av bekken,
og det vil oppdatere ElastiCache eksempel med de nye dataene.
Så det er mye hva vi gjør med Lambda.
Det er lim koden, kontakter.
Og det gir faktisk muligheten til å starte
og til å kjøre svært komplekse applikasjoner uten en dedikert server
infrastruktur, som er virkelig kult.
>> Så la oss gå tilbake til vår sanntid stemmegivning arkitektur.
Dette er nytt og forbedret med vår bekker og KCL aktivert program.
Samme som før, kan vi håndtere eventuelle omfanget av valget.
Vi liker dette.
Vi gjør ut scatter samler tvers av flere bøtter.
Vi har fått optimistisk låsing skjer.
Vi kan holde våre velgere fra å endre sine stemmer.
De kan bare stemme én gang.
Dette er fantastisk.
Real-time feiltoleranse, skalerbar aggregering nå.
Hvis ting faller over, det vet hvor du skal starte seg selv
når det kommer opp igjen fordi vi bruker den KCL app.
Og da kan vi også bruke det KCL program for å presse data ut
til rødforskyvning for andre app analytics, eller bruk
Den elastiske MapReduce å kjøre real-time streaming samlinger off
av dataene.
>> Så dette er ting vi har ikke snakket om mye.
Men de er ekstra teknologier som kommer
å bære når du leter på disse typer scenarier.
>> Greit, så det er omtrent analytics med DynamoDB Streams.
Du kan samle de-lure data, gjøre alle typer
av fine ting, samle data i minne, lage disse avledede tabeller.
Det er en enorm use case at mange kunder
er involvert med, tar nestet egenskapene til disse JSON-dokumenter
og opprette flere indekser.
>> Vi er på slutten.
Takk for at du bærer med meg.
Så la oss snakke om referansearkitektur.
DynamoDB sitter i midten av så mye av AWS infrastruktur.
I utgangspunktet kan du koble den opp til noe du ønsker.
Applikasjoner bygget med Dynamo inkluderer Lambda, ElastiCache, CloudSearch,
skyve data ut i Elastic MapReduce, import eksport fra DynamoDB
i S3, alle typer arbeidsflyter.
Men sannsynligvis den beste ting å snakke om,
og dette er hva som er virkelig interessant er når vi
snakke om hendelsesdrevne applikasjoner.
>> Dette er et eksempel på et internt prosjekt
at vi har der vi er faktisk publisering for å samle resultatene fra undersøkelsen.
Så i en e-post link som vi sender ut, det vil
være litt link som sier klikk her for å svare på undersøkelsen.
Og når en person klikk som link, hva skjer
er de trekke ned en sikker HTML undersøkelse form fra S3.
Det er ingen server.
Dette er bare en S3 objekt.
>> At formen kommer opp, laster opp i nettleseren.
Det har ryggrad.
Det har komplekse Javascript at den kjører.
Så det er veldig rik søknad kjører i klientens nettleser.
De vet ikke at de ikke er samspill med en back end server.
På dette punktet, er det alt nettleser.
>> De publiserer resultatene til hva vi kaller Amazon API Gateway.
API Gateway er rett og slett en web-API at du kan definere og koble opp
til hva du vil.
I dette tilfellet er vi koblet til en Lambda funksjon.
>> Så min POST drift er skjer uten server.
Utgangspunktet at API Gateway sitter der.
Det koster meg ingenting før folk begynne å legge til det, ikke sant?
Lambda-funksjonen bare sitter der.
Og det koster meg ingenting før folk begynner å treffe den.
Så du kan se, som volumet øker, er at når anklagene kommer.
Jeg er ikke kjører en server 7/24.
>> Så jeg trekker form ned fra bøtta,
og jeg legger gjennom API Inngangsport til Lambda funksjonen.
Og så Lambda Funksjonen sier, du vet
hva har jeg fått noen PIIs, noen personlig identifiserbar informasjon
i disse svarene.
Jeg fikk kommentarer fra brukere.
Jeg har fått e-postadresser.
Jeg har fått brukernavn.
>> La meg dele dette av.
Jeg kommer til å generere noen metadata av denne posten.
Og jeg kommer til å skyve metadata inn DynamoDB.
Og jeg kunne kryptere all data og skyv den inn DynamoDB hvis jeg vil.
Men det er lettere for meg, i dette bruke saken for å gå videre en si,
Jeg kommer til å presse rådata inn i en kryptert S3 bøtte.
Så jeg bruke bygget i S3 server side kryptering og Amazons Key Management
Tjenesten, slik at jeg har en nøkkel som kan rotere på en vanlig intervall,
og jeg kan beskytte at PII data som en del av hele denne arbeidsflyten.
>> Så hva har jeg gjort?
Jeg har nettopp utplassert en hel program, og jeg har ingen server.
Så er hva hendelse drevet søknad arkitektur gjør for deg.
>> Nå hvis du tenker på bruk case for dette--
vi har andre kunder jeg snakker til om denne eksakte arkitektur som
kjøre fenomenalt store kampanjer, som ser på dette og går, oh my.
Fordi nå, kan de utgangspunktet skyve den ut der,
la den kampanjen bare sitte der til det lanseres, og ikke
trenger å bekymre deg en fig om hva slags infrastruktur
kommer til å være der for å støtte den.
Og så så snart at kampanjen er gjort,
det er som infrastruktur bare umiddelbart går unna
fordi det egentlig er ingen infrastruktur.
Det er bare kode som sitter på Lambda.
Det er bare data som sitter i DynamoDB.
Det er en fantastisk måte å bygge applikasjoner.
>> PUBLIKUM: Så er det mer flyktig enn det ville være
hvis den ble lagret på en faktisk server?
>> RICK Houlihan: Absolutt.
Fordi at tjenerforekomsten måtte være en 7/24.
Det må være tilgjengelig for noen til å svare på.
Vel gjett hva?
S3 er tilgjengelig 7/24.
S3 svarer alltid.
Og S3 er veldig, veldig bra på servering opp gjenstander.
Disse objektene kan være HTML-filer, eller Javascript-filer, eller hva du vil.
Du kan kjøre svært rike webapplikasjoner ut av S3 bøtter, og mennesker gjør.
>> Og så det er tanken her er å komme bort fra veien
vi pleide å tenke på det.
Vi pleide å tenke i form av servere og verter.
Det handler ikke om det lenger.
Det handler om infrastruktur som kode.
Distribuere koden til nettskyen og la skyen kjøre den for deg.
Og det er det AWS prøver å gjøre.
>> PUBLIKUM: Så din gull boksen i midten av API Gateway er ikke server-aktig,
men i stedet er just--
>> RICK Houlihan: Du kan tenke av det som server fasaden.
Alt er det er det vil ta en HTTP be om og kartlegge den til en annen prosess.
Det er alt den gjør.
Og i dette tilfellet, vi kartlegge den til en Lambda funksjon.
Greit, så det er alt jeg fikk.
Tusen takk.
Jeg setter pris på det.
Jeg vet at vi vil ha en litt over tid.
Og forhåpentligvis fikk dere en liten bit av informasjon
at du kan ta bort i dag.
Og jeg beklager hvis jeg gikk over noen av hodene,
men det er en god rekke fundamental grunnleggende kunnskap
som jeg tror er svært verdifull for deg.
Så takk for å ha meg.
[BIFALL]
PUBLIKUM: [uhørbart] er når du sa
du måtte gå gjennom ting fra begynnelsen til slutten
å få de riktige verdiene eller de samme verdier,
hvordan ville verdiene endres hvis [uhørbart].
>> RICK Houlihan: Oh, idempotent?
Hvordan ville de verdiene endres?
Vel, fordi hvis jeg ikke kjøre den helt til slutten,
så jeg vet ikke hvilke endringer ble gjort i den siste mil.
Det kommer ikke til å være det samme data som det jeg så.
PUBLIKUM: Å, så du bare har ikke fått hele innspill.
RICK Houlihan: Høyre.
Du må gå fra begynnelse til slutt, og da er det
kommer til å være en konsistent tilstand.
Kjølig.
>> PUBLIKUM: Så du viste oss DynamoDB kan gjøre dokumentet eller nøkkelverdien.
Og vi har brukt mye tid på sentral verdi med hasj og veier
å snu det rundt.
Når du har sett på disse tabellene, er at later dokumentet tilnærming?
>> RICK Houlihan: Jeg ville ikke si forlate den bak.
>> PUBLIKUM: De ble skilt fra the--
>> RICK Houlihan: Med dokumentet tilnærming, dokumenttype i DynamoDB
er bare å tenke på som en annen egenskap.
Det er en egenskap som inneholder en hierarkisk datastruktur.
Og så i spørringene, du kan bruke egenskapene
av disse objektene ved hjelp av Object Notation.
Så jeg kan filtrere på en nestet eiendommen av JSON dokumentet.
PUBLIKUM: Så hver gang jeg gjøre et dokument tilnærming,
Jeg kan liksom komme frem til tabular--
PUBLIKUM: Absolutt.
Målgruppe: --indexes og ting du bare snakket om.
RICK Houlihan: Ja, indekser og alt det der,
når du ønsker å indeksere egenskapene til JSON,
den måten at vi må gjøre det på er hvis du setter inn en JSON objekt eller et dokument
til Dynamo, vil du bruke bekker.
Strømmer ville lese innspill.
Du vil få det JSON objekt og du vil si OK,
hva er den egenskapen jeg vil indeksere?
>> Du oppretter et derivat bord.
Nå det er slik det fungerer akkurat nå.
Vi vil ikke tillate deg å indeksere direkte disse egenskapene.
>> PUBLIKUM: Tabularizing dokumentene.
>> RICK Houlihan: Nøyaktig, flatere det, tabularizing det, akkurat.
Det er hva du gjør med den.
>> PUBLIKUM: Takk.
>> RICK Houlihan: Jepp, absolutt, takk.
PUBLIKUM: Så det er på en måte Mongo møter Redis classifers.
>> RICK Houlihan: Ja, det er mye sånn.
Det er en god beskrivelse for det.
Kjølig.