>> [Muzikos grojimo]
RICK Houlihan: Visos dešinę.
Labas visiems.
Mano vardas yra Rick Houlihan.
Aš vyresnysis pagrindinis sprendimai architektas AWS.
Aš sutelkti dėmesį į NoSQL ir DynamoDB technologijos.
Aš čia šiandien kalbėti Jūs šiek tiek apie tuos.
>> Mano fonas visų pirma duomenų sluoksnis.
Aš praleido pusę savo plėtrą Karjera raštu duomenų bazę,
prieigos prie duomenų, sprendimai įvairių programų.
Aš jau Cloud Virtualizacija apie 20 metų.
Taigi prieš Cloud buvo Cloud mes naudojome jį pavadinti naudingumo skaičiavimo.
Ir idėja buvo, tai kaip PG & E, jūs mokate už tai, ką naudojate.
Šiandien mes jį vadiname debesis.
>> Bet per tuos metus aš dirbau už įmonių pora
jūs tikriausiai niekada girdėjote apie.
Bet aš parengė techninių sąrašą pasiekimus, manau, norite pasakyti.
Turiu aštuonias patentų Cloud sistemos Virtualizacija, mikroprocesorius dizainas,
kompleksas renginys apdorojimo, ir kitose srityse, taip pat.
>> Taigi šių dienų, aš daugiausia orientavosi į NoSQL technologijas ir naujos kartos
duomenų bazė.
Ir tai dažniausiai ką aš ruošiuosi būti čia su jumis kalbėti šiandien apie tai.
Taigi, ką jūs galite tikėtis iš šios sesijos
mes eiti per trumpas Istorija duomenis.
Jis visada naudinga suprasti, kur mes atėjo iš
ir kodėl mes, kur mes esame.
Ir mes kalbame šiek tiek tiek apie NoSQL technologijos
iš pagrindinių požiūriu.
>> Mes patekti į kai kuriuos kad DynamoDB vidinės.
DynamoDB yra AWS anketa Nr skonio.
Tai visiškai valdoma ir Patalpinta NoSQL sprendimas.
Ir mes kalbame šiek tiek apie stalo struktūra, API, duomenų tipai, indeksai,
o kai kurie iš vidinės tos DynamoDB technologija.
Mes patekti į kai kuriuos dizaino modeliai ir geriausia praktika.
Mes kalbame apie tai, kaip naudoja šią technologiją kai
šiandienos programas.
Ir tada mes kalbame šiek tiek apie evoliucijos arba atsiradimas
naujos paradigmos programavimo vadinamas įvykiu pagrįsti prašymai
ir kaip DynamoDB vaidina tuo, kad taip pat.
Ir mes palikti jums šiek tiek nuoroda architektūra diskusijos
todėl mes galime kalbėti apie kai būdų, kaip galite naudoti DynamoDB.
>> Taigi, pirmiausia off-- tai klausimas Girdžiu daug yra, kas duomenų bazę.
Daug žmonių galvoja, kad jie žinau, kas yra duomenų bazė yra.
Jei Google, pamatysite tai.
Tai struktūrinė duomenų rinkinys vyksta į kompiuterį, ypač vienas, kad
yra prieinama įvairiais būdais.
Aš manau, kad tai geras apibrėžimas modernią bazę.
Bet man nepatinka tai, nes tai reiškia keletą dalykų.
Tai reiškia, struktūrą.
Ir tai reiškia, kad ji kompiuteryje.
Ir duomenų bazių nebuvo visada egzistuoja kompiuteriuose.
Duomenų bazės tikrųjų egzistavo įvairiais būdais.
>> Taigi geriau apibrėžimas duomenų bazė yra kažkas panašaus į tai.
Yra organizuotas duomenų mechanizmas saugoti, valdyti,
ir išrinkti informaciją.
Tai iš About.com.
Taigi man patinka tai, nes ji tikrai kalba apie duomenų bazė yra saugykloje,
iš saugyklos informacija, nebūtinai
kažkas, kad sėdi ant kompiuterio.
Ir per visą istoriją, mes ne visada turėjo kompiuterius.
>> Dabar, jei aš prašau vidurkį kūrėjas šiandien kas
duomenų bazė, tai atsakymas man.
Kažkur galiu klijuoti medžiagą.
Teisė?
Ir tai tiesa.
Bet tai gaila.
Kadangi duomenų yra tikrai šiuolaikinės app pamatas.
Tai pamatai apie kiekvieną paraišką.
Ir kaip jums sukurti, kad duomenų, kaip jūs struktūrizuoti
kad duomenys ketina diktuoti, kaip kad taikymas atlieka kaip jūs mastelį.
>> Taigi mano darbas šiandien daug yra susijusios su tuo, ką
atsitinka, kai kūrėjai šio požiūrio
ir susijusius su padariniais Paraiškos, kad
dabar mastelio už originalą ketinimų ir kenčia nuo blogo dizaino.
Taigi, tikiuosi, kai jūs pėsčiomis šiandien, jums
turėti įrankių pora Jūsų diržo, kad bus jus
nuo priėmimo tuos pačius klaidų.
Gerai.
Taigi pakalbėkime apie šiek tiek iš duomenų bazių technologija tvarkaraštis.
Manau, kad skaityti Straipsnis ne taip seniai,
ir ji sakė kažką apie lines-- tai labai poetiška pareiškimas.
Jis sakė, kad istorija Duomenų tvarkymas
pilnas aukštų vandens ženklais duomenų gausą.
GERAI.
Dabar, aš manau, kad tai rūšies tiesa.
Bet aš iš tikrųjų pažvelgti į tai, kaip istorija iš tikrųjų yra užpildytas
su aukštos vandenženkliui duomenų slėgiui.
Kadangi duomenų tarifą Prarijus niekada krinta.
Tai tik pakyla.
>> Ir inovacijos atsiranda, kai matome duomenų spaudimą, kuris
yra duomenų kiekis, kuris yra dabar ateina į sistemą.
Ir jis negali būti apdoroti efektyviai vienu metu arba sąnaudų.
Ir tai, kai mes pradedame ieškoti duomenų spaudimą.
>> Taigi, kai mes žiūrime ne pirmoji duomenų bazė, šis
yra vienas, kad buvo tarp mūsų ausų.
Mes visi gimė su juo.
Tai gražus duomenų.
Ji turi aukštą prieinamumą.
Tai visada.
Jūs visada galite jį gauti.
>> Bet tai vienas vartotojas.
Aš negaliu pasidalinti savo mintimis su jumis.
Jūs negalite gauti savo mintimis kai norite juos.
Ir jų abilitiy yra ne taip gerai.
Mes pamirštame dalykų.
Kas dabar ir tada, vienas iš mūsų lapai ir pereina į kitą egzistencijos
ir mes prarasti viską kad buvo toje duomenų bazėje.
Taigi tai dar ne viskas, kad geras.
>> Ir tai gerai dirbo per tam tikrą laiką kai mes buvome atgal per dieną
kai visi mes tikrai reikia žinoti, yra kur mes ketiname eiti rytoj
arba kai mes renkame geriausią maistą.
Bet kaip mes pradėjo augti kaip civilizacija ir Vyriausybė pradėjo
ateiti į būties ir įmonės pradėjo vystytis,
mes pradėjome suvokti, mes reikia šiek tiek daugiau nei
galėtume įdėti mūsų galvos.
Gerai?
>> Mums reikėjo sistemas įrašo.
Mums reikia vietos, kad būtų galima saugoti duomenis.
Taigi mes pradėjo rašyti dokumentus, kurti bibliotekas ir archyvus.
Mes pradėjo kurti A sistema knygos apskaita.
Ir kad Didžiosios knygos skaičiavimo sistema bėgo pasaulį daugelį šimtmečių,
o gal net tūkstantmečius kaip mes rūšies išaugo iki taško,
kur tie duomenys apkrova pranoko šių sistemų gebėjimas
gebėti jį apriboti.
>> Ir tai iš tiesų nutiko 1880.
Teisė?
Per 1880 JAV surašymas.
Tai tikrai kur tekinimo atkreipti modernią duomenis.
Tai yra ne taškas kurioje duomenų kiekis
kuri buvo surinkta, padarytais JAV vyriausybė gavo iki taško
kur jis paėmė aštuonerius metus apdoroti.
>> Dabar, aštuoni years-- kaip žinote, surašymą
kursuoja kiekvieną 10 years-- todėl gana akivaizdu, kad laiko mes
gavo 1890 surašymą, duomenų kiekis, kad
ketino būti tvarkomi vyriausybės buvo
ketina viršyti 10 metų, kad jame būtų imtis, kad atidarė naują surašymo.
Tai buvo problema.
>> Taigi vyrukas vardu Hermanas Hollerith atėjo kartu
ir jis išrado vieneto rekordinį Punch kortelės, Punch kortelės skaitytuvas, perfokortų
Tabulator, o lyginimas už šios technologijos mechanizmai.
Ir tai kompanija, kuri subūrė ne laikas, kartu su kitų, pora,
iš tikrųjų tapo vienu iš A statramsčių maža įmonė žinome šiandien vadinama IBM.
>> Taigi IBM pradžių buvo duomenų bazė verslas.
Ir tai tikrai tai, ką jie padarė.
Jie padarė duomenis.
>> Kaip todėl Punch platinimu kortelės, An originalių mechanizmai
kad galėtų išnaudoti, kad technologija apklausti surūšiuotas rezultatas rinkinius.
Jūs galite pamatyti šiame paveikslėlyje ten mes turime little--
tai šiek tiek small-- bet jūs galite pamatyti labai išradinga mechaninis mechanizmas
kur mes turime Punch kortelės denio.
Ir kažkieno paėmimas šiek tiek atsuktuvas
ir gyvuos per lizdai ir kėlimo jį
gauti, kad rungtynės, kad rūšiuojami rezultatai nustatyti.
>> Tai agregacija.
Mes tai visą laiką šiandien į kompiuterį,
kur tai padaryti duomenų bazėje.
Mes naudojome tai padaryti rankiniu būdu, tiesa?
Žmonės įdėti šiuos dalykus kartu.
Ir tai buvo proliferacija Šių Punch korteles
į tai, ką mes vadinami duomenų būgnai ir duomenų ritės, popieriaus juosta.
>> Duomenų perdirbimo pramonė buvo pamoka iš grotuvo fortepijonams.
Žaidėjo fortepijonams atgal iš amžių sandūroje
jį naudoti popierinius rites su grioveliais nuo pasakyti, kuri klavišus žaisti.
Taigi, kad technologija buvo pritaikyta galiausiai saugoti skaitmeninius duomenis,
nes jie gali įdėti, kad duomenis ant tų popieriaus juosta ritės.
>> Dabar, kaip rezultatas, duomenų buvo actually-- kaip
jums prieigą šie duomenys buvo tiesiogiai priklauso nuo to, kaip įrašėte ją.
Taigi, jei aš įdėti duomenis į vaizdajuostę, Aš turėjau prieiti prie duomenų tiesiškai.
Turėjau sukite visą juosta prieiti prie visų duomenis.
Jei aš įdėti duomenis Punch kortelės, galėčiau jį pasiekti
Šiek tiek daugiau atsitiktinių mada, o gal ir ne taip greitai.
>> Bet ten buvo ribojami, kaip mes prieiga prie duomenų pagal tai, kaip buvo saugomi.
Ir taip, tai buvo problema vyksta į '50s.
Vėlgi, mes galime pradėti rodyti, kad mes kurti naujas technologijas apdoroti
duomenys, tiesa, ji atveria už naujų sprendimų durys,
naujų programų, nauja paraiškos dėl šių duomenų.
Ir tikrai, valdymas galėjo būti priežastis,
kodėl mes sukūrė kai kurie iš šių sistemų.
Tačiau verslo greitai tapo vairuotojas už evoliuciją
Šiuolaikinės duomenų bazės ir modernus failų sistema.
>> Taigi kitas dalykas, kad atėjo buvo '50s
buvo failų sistema ir plėtra laisvosios kreipties saugojimui.
Tai buvo gražus.
Dabar, visi staiga, mes galime įdėti mūsų failus kur šių kietieji diskai
ir mes galime pasiekti šiuos duomenis atsitiktinai.
Galime apdoroti, kad informaciją iš failų.
Ir mes išspręsti visų pasaulio problemos su duomenų tvarkymu.
>> Ir tai truko apie 20 ar 30 metų, kol evoliucija
iš reliacinės duomenų bazės, kuri yra kai pasaulis nusprendė dabar
reikia turėti saugyklą, kad nugali duomenų plėtra visoje failą
sistemos, kad mes pastatyti. Teisė?
Per daug duomenų platinami per daug vietos, de-dubliavimo duomenų,
ir laikymo kaina buvo didžiulė.
>> Per 70-ųjų, pats brangiausias šaltinis kad kompiuteris buvo, saugojimo.
Procesorius buvo žiūrima kaip fiksuota kaina.
Kai aš pirkti langelį, CPU daro tam tikrą darbą.
Tai bus verpimo ar tai tikrai dirba, ar ne.
Tai tikrai sumažėjusių sąnaudų.
>> Bet kas man kainuos kaip verslas yra sandėlys.
Jeigu aš turiu pirkti daugiau diskus Kitas mėnesį, tai reali kaina, kurią moku.
Ir kad saugykla yra brangus.
>> Dabar mes Fast Forward 40 metų ir turime kitą problemą.
Apskaičiuoti dabar Brangiausia išteklių.
Saugojimo yra pigus.
Aš turiu galvoje, mes galime eiti bet kur debesis ir mes galime rasti pigūs saugykla.
Bet ką aš nerandu yra pigus apskaičiuoti.
>> Taigi šiandienos evoliucija technologijų, duomenų bazių technologija,
tikrai sutelktas aplink Paskirstyta duomenų bazės
kad ne kenčia nuo to paties tipo skalę
apribojimai reliacinių duomenų bazių.
Mes kalbame šiek tiek apie ką tai iš tikrųjų reiškia.
>> Tačiau viena iš priežasčių, ir vairuotojas už this-- mes
kalbėjo apie duomenų spaudimą.
Duomenų slėgis yra kažkas kad diskai naujoves.
Ir jei peržvelgsite per per pastaruosius penkerius metus,
tai, ką duomenų diagrama apkrova visoje bendrojo įmonė
atrodo per pastaruosius penkerius metus.
>> Ir bendra taisyklė nykščio Šie days-- jei jūs einate Google--
yra 90%, kad duomenų, kad mes aukštesnėje šiandien, ir tai buvo
sukurtas per pastaruosius dvejus metus.
GERAI.
Dabar, tai yra ne tendencija, kad naujo.
Tai yra tendencija, kad buvo vakarėliai 100 metų.
Nuo Herman Hollerith sukūrė perfokortų,
mes jau pastato duomenų saugyklas ir rinkti duomenis fenomenaliai normos.
>> Taigi per pastaruosius 100 metų, mes matėme šią tendenciją.
Štai nesiruošia keisti.
Žvelgiant į ateitį, mes ketiname pamatyti tai, jei ne pagreitinto tendencija.
Ir jūs galite pamatyti, ką tai atrodo.
>> Jeigu 2010 metais verslo turėjo vieną terabaito duomenų pagal valdymo,
šiandien tai reiškia, kad jie valdant 6,5 petabaitus duomenų.
Štai 6500 kartų daugiau duomenų.
Ir aš žinau tai.
Aš dirbu su šių įmonių kiekvieną dieną.
Prieš penkerius metus aš būtų pasikalbėti su įmonių
kuris būtų kalbėti su manimi apie tai, kas skausmo tai yra valdyti terabaitų duomenų.
Ir jie kalba man apie tai, kaip mes matome
kad tai tikriausiai vyksta būti Petabaitas arba du
per porą metų.
>> Tos pačios įmonės šiandien aš susitikti su,
ir jie su manim kalbi apie problema ten, turintys tvarkymą
dešimtys, 20 petabytes duomenų.
Taigi sprogimo duomenys pramonėje
vairuoja milžiniškas reikia geresnių sprendimų.
Ir reliacinės duomenų bazės yra tik ne gyvena iki paklausa.
>> Ir taip ten linijinis koreliacija tarp duomenų slėgio
ir technikos naujovės.
Istorija mums parodė tai, kad, laikui bėgant,
kiekvieną kartą, kai kiekis duomenų kad turi būti apdorojami
viršija sistemos pajėgumą apdoroti ją per priimtiną laiką
arba už priimtiną kainą, Tada naujos technologijos
išrado išspręsti šias problemas.
Šios naujos technologijos, savo ruožtu, atidaryti duris
į kitą problemų rinkinys, kuris yra surinkti dar daugiau duomenų.
>> Dabar mes nesiruošia sustoti tai.
Teisė?
Mes neketiname sustoti tai.
Kodėl?
Kadangi jūs negalite žinoti viską yra žinoti visatoje.
Ir tol, kol mes jau gyvas, visoje žmonijos istorijoje,
mes visada skatino sužinoti daugiau.
>> Taigi atrodo, kad kiekvieną colių mes einame žemyn mokslinių atradimų keliu,
mes dauginant duomenų kiekį kad mums reikia apdoroti eksponentiškai
kaip mes atskleisti vis daugiau ir daugiau ir daugiau apie vidaus darbu gyvenime,
apie tai, kaip visata veikia, apie vairavimo mokslinį atradimą,
ir šis išradimas, kad mes darome šiandien.
Duomenų apimtis tik nuolat didėja.
Taigi, kad galėtų susidoroti su Ši problema yra milžiniškas.
>> Taigi, viena iš ko mes žiūrime kaip, kodėl NoSQL?
Kaip NoSQL išspręsti šią problemą?
Na, reliacinės duomenų bazės, Struktūrinių užklausų kalba,
SQL--, kad tikrai iš konstruktas reliacinės database-- šie dalykai yra
optimizuotas saugojimui.
>> Atgal į 70-ųjų, vėlgi, diskas yra brangus.
Atidėjinių pratybų saugojimo įmonėje yra nesibaigiantis.
Aš žinau.
Aš gyvenau ją.
Parašiau saugojimo tvarkykles enterprised superserver įmonė
atgal į "90s.
Ir Esmė yra stelažai kitą saugojimo masyvas buvo tiesiog kažkas, kad
atsitiko kiekvieną dieną įmonėje.
Ir ji niekada sustojo.
Didesnio tankio saugojimo, paklausa už didelio tankio saugojimo,
ir efektyviau saugojimo devices-- jis nesiliovė.
>> Ir NoSQL yra puikus technologijų nes jis normalizuoja duomenis.
Ji de dublikatų duomenis.
Ji pateikia duomenis į struktūrą, kuri yra agnostikas, kad kiekviena prieiga modelio.
Įvairios taikymo sritys gali smūgį SQL duomenų bazės, paleisti ad hoc užklausas,
ir gauti duomenis formos, kad jie reikia apdoroti jų darbo krūvis.
Tai skamba fantastiškai.
Bet Esmė yra su bet sistema, jei ji agnostikas viską,
jis yra optimizuotas nieko.
GERAI?
>> Ir tai, ką mes gauname su reliacinės duomenų bazės.
Jis optimizuotas saugojimui.
Tai normalizuotas.
Tai santykinė.
Jis remia ad hoc užklausas.
Ir jį, ir jis svarstyklės vertikaliai.
>> Jei man reikia gauti didesnę SQL duomenų bazės arba galingesnis SQL duomenų bazės,
Aš einu pirkti didesnį gabalėlį geležies.
GERAI?
Aš dirbau su daug klientų kad buvo per didelių atnaujinimų
savo SQL infrastruktūrai sužinoti šešių mėnesių,
jie pataikyti sienos dar kartą.
Ir iš "Oracle" ar MSSQL atsakymas ar kas nors kitas yra gauti didesnį langelį.
Na, anksčiau ar vėliau, jūs negalite pirkti didesnis langas, ir tai reali problema.
Turime iš tikrųjų kažką pakeisti.
Taigi, kur tai veikia?
Jis gerai dirba neprisijungus Google Analytics, OLAP tipo darbo krūviai.
Ir tai tikrai, jei SQL priklauso.
Dabar jis naudojamas šiandien daugelis interneto sandorio apdorojimo tipo
programos.
Ir tai veikia tik bauda už kai panaudojimo lygis,
bet tai tiesiog nėra masto taip, kad NoSQL daro.
Ir mes kalbame šiek tiek tiek apie tai, kodėl tai yra.
>> Dabar, NoSQL, kita vertus, yra daugiau optimizuotas Compute.
GERAI?
Tai nėra agnostikas į prieigos modelis.
Ar tai, ką mes vadiname de normalizuotas konstrukcijos arba hierarchinė struktūra.
Į reliacinės duomenų bazės duomenys sujungtos iš kelių lentelių
gaminti, kad jums reikia.
Sprendimo A NoSQL duomenis į duomenų bazę yra saugomi dokumento, kuris
yra hierarchinės struktūros.
Visi duomenų, kad paprastai būtų sujungtos tarpusavyje, kad pagaminti minėtą vaizdą
yra saugomi viename dokumente.
Ir mes kalbame šiek tiek apie kaip tai veikia daugelyje topų pora.
>> Bet idėja čia yra, kad jums laikyti Jūsų duomenys, nes šios instantiated nuomonę.
GERAI?
Jūs masto horizontaliai.
Teisė?
Jei man reikia padidinti dydis mano NoSQL klasterį,
Man nereikia, kad gauti didesnį langelį.
Gaunu kitą langelį.
Ir aš klasteris tie kartu, ir aš galiu Shard, kad duomenis.
Mes kalbame tiek apie kas sharding yra, būti
sugebėti masto, kad duomenų bazės keliose fizinių įrenginių
ir pašalinti kliūtis, kad reikia man masto vertikaliai.
>> Taigi tai tikrai pastatytas internete sandorių apdorojimas ir masto.
Yra didelis skirtumas čia tarp ataskaitų, tiesa?
Ataskaitos, aš nežinau Klausimai aš ruošiuosi paklausti.
Teisė?
Reporting--, jei kas nors iš mano Marketingo skyrius
nori just-- kiek iš mano klientų turėti šią konkrečią charakteristiką, kas
nusipirkau šį day-- nežinau kas užklausa jie ketina prašyti.
Taigi man reikia būti agnostikas.
>> Dabar, internete taikymo sandorio,
Aš žinau, kokius klausimus aš prašau.
Aš pastatė už paraišką labai specifinė darbo eigos.
GERAI?
Taigi, jei aš optimizuoti duomenis saugoti paremti šį eigą,
jis bus greitesnis.
Ir štai kodėl NoSQL gali tikrai paspartinti pristatymas
iš šių paslaugų rūšys.
Gerai.
>> Taigi mes ketiname patekti į šiek tiek teorijos čia.
Ir kai kurie iš jūsų, jūsų akys gali įvirsta truputį.
Bet aš pabandysiu ją išlaikyti kaip aukšto lygio, kaip aš galiu.
Taigi, jei esate projektą valdymo, ten
konstrukciją, vadinamas trikampis apribojimus.
GERAI.
Iš riboja diktato trikampis jūs negalite turėti visko laiką.
Negali turėti savo tortą ir valgo jis taip pat.
Taigi projekto valdymą, kad trikampis apribojimai yra, galite ją pigus,
Jums jis gali būti greitai, ar jūs galite turėti tai gerai.
Pick du.
Kadangi jūs negalite turėti visus tris.
Teisė?
GERAI.
>> Taigi sužinojote apie šį daug.
Tai triguba apribojimas, trikampis triguba apribojimų,
arba geležies trikampis yra oftentimes-- kai jūs kalbate su projektų vadovams,
jie apie tai kalbėti.
Dabar, duomenų bazės turi savo geležies trikampis.
Ir geležis trikampis duomenų yra tai, ką mes vadiname BŽŪP teorema.
GERAI?
>> BŽŪP teorema diktuoja kaip duomenų bazės veikia
pagal labai konkrečią būklę.
Ir mes kalbame apie ką ši sąlyga.
Tačiau trys taškai trikampio, taip sakant, yra C, nuoseklumas.
GERAI?
Taigi BŽŪP, nuoseklumas reiškia, kad visi klientai, kurie gali prieiti prie duomenų bazės
visada turės labai nuoseklų duomenų.
Niekieno gonna mato du skirtingus dalykus.
GERAI?
Jei matau duomenų bazę, Matau tą patį vaizdą
kaip mano partnerio, kuris mato tas pats duomenų.
Štai nuoseklumas.
>> Likutis reiškia, kad jei duomenų bazė internete, jei ji gali būti pasiektas,
kad visi klientai bus visada gebėti skaityti ir rašyti.
GERAI?
Taigi kiekvienas klientas, gali skaityti duomenų bazę
visada galės Skaityti duomenų ir rašyti duomenis.
Ir jei tai toks atvejis, tai yra prieinama sistema.
>> Ir trečias dalykas yra ką mes vadiname skirsnių toleranciją.
GERAI?
Pasiskirstymo tolerancijos priemonės kad sistema veikia gerai
nepaisant fizinio tinklo pertvaros tarp mazgų.
GERAI?
Taigi mazgų klasterius negali kalbėtis tarpusavyje, kas atsitiks?
Gerai.
>> Taigi reliacinės duomenų bazės choose-- galite pasirinkti du iš jų.
GERAI.
Taigi reliacinės duomenų bazės pasirinkti būti nuoseklūs ir prieinama.
Jei skaidinys vyksta tarp Į duomenų saugyklos DataNodes,
duomenų bazė sugenda.
Teisė?
Jis tiesiog krinta.
GERAI.
>> Ir tai, kodėl jie turi augti su didesniais dėžės.
Teisė?
Nes ten no-- paprastai klasteris duomenų bazė, ten nėra labai daug iš jų
kad veikia, kad taip.
Tačiau dauguma duomenų bazės mastelį vertikaliai per vieną langelį.
Kadangi jie turi būti nuosekli ir prieinama.
Jei skaidinys būtų švirkščiamas, tada jums reikės rinktis.
Jūs turite rinktis tarp yra nuoseklus ir prieinama.
>> Ir tai, ką NoSQL duomenų bazės daryti.
Gerai.
Taigi NoSQL duomenų bazę, yra dviejų skonių.
Mes have-- Na, tai ateina daug skonių,
bet ji ateina su dviejų pagrindinių characteristics-- ką
mes vadiname CP duomenų bazę arba nuosekli ir pertvarų tolerancija
sistema.
Šie vaikinai padaryti pasirinkimą, kad kai mazgai praranda kontaktą vienas su kitu,
mes neketiname leisti žmonių rašyti, bet daugiau.
GERAI?
>> Iki skaidinys bus pašalintas, Rašymo prieiga užblokuotas.
Tai reiškia, kad jie nėra prieinami.
Jie nuoseklūs.
Kai matome, kad Pasiskirstymo švirkšti pats,
dabar mes esame nuoseklūs, nes mes neketiname
leisti pakeisti duomenis dėl dviejų pusės disko savarankiškai
viena nuo kitos.
Turėsime atkurti ryšį
prieš bet kokį atnaujintoje duomenys yra leidžiamas.
GERAI?
>> Kitas skonis būtų AP sistema, arba prieinama ir suskirstyti
tolerancija sistema.
Šie vaikinai nerūpi.
Teisė?
Bet mazgas, kad gauna rašyti, mes jį priimti.
Taigi, aš atkartoti savo duomenis keliose mazgų.
Šie mazgai gauti kliento, kliento ateina į, sako, aš ruošiuosi rašyti kai kuriuos duomenis.
Mazgas sako, jokių problemų.
Mazgas šalia jo gauna ant to paties įrašo rašymo,
jis ketina pasakyti jokių problemų.
Kažkur atgal ant nugaros pabaigoje, kad duomenys ketina atkartoti.
Ir tada kažkas vyksta suvokti, Oi, jie sistema suprasite, uh-oh,
ten buvo panaudotas dviejų pusių atnaujinti.
Ką mes darome?
Ir ką jie daro, tada yra jie kažką,
leidžia jiems išspręsti, kad Valstybinė duomenų.
Ir mes kalbame apie kad kitam diagramos.
>> Dalykas atkreipti dėmesį į čia.
Ir aš nesiruošia gauti per daug į tai, nes šis
patenka į gilią duomenų teorija.
Bet ten sandorio sistema,
Veikia reliacinės sistemos, leidžia man saugiai padaryti atnaujinimai
keliems subjektams duomenų bazėje.
Ir tie atnaujinimai įvyks visos iš karto arba ne visi.
Ir tai vadinama RŪGŠTIS sandorius.
GERAI?
>> RŪGŠTIS suteikia mums nedalomumo, nuoseklumo, izoliacija ir ilgaamžiškumą.
GERAI?
Tai reiškia, kad atominio, sandorius, visa Mano atnaujinimai arba atsitiks ar jie neturi.
Derėjimas reiškia, kad duomenų bazę visada
būti įtraukti į nuoseklią būklė po atnaujinimo.
Aš niekada palikti duomenų bazėje blogos būklės tepdami atnaujinti.
GERAI?
>> Taigi tai šiek tiek kitoks nei BŽŪP nuoseklumo.
BŽŪP nuoseklumas reiškia visų mano klientai visada gali matyti duomenis.
RŪGŠTIS nuoseklumas reiškia, kad kai sandoris padaryta, duomenų gera.
Mano santykiai yra viskas gerai.
Nesiruošiu ištrinti patronuojanti eilutę ir palikti našlaičiai krūva
kai kitos lentelės.
Tai negali atsitikti, jei aš nuosekliai rūgštinėje sandorį.
>> Izoliacija reiškia, kad sandoriai visada įvyks vienas po kito.
Galutinis rezultatas duomenis bus tas pats būklė
kaip jei šie sandoriai kad buvo išduotas kartu
buvo įvykdyta serijiniu.
Taigi, tai lygiagrečiai valdymo duomenų bazėje.
Taigi, iš esmės, aš negaliu prieaugio pačios vertės du kartus su dviejų operacijų.
>> Bet jei aš sakau, pridėti 1 iki šios vertės, ir du sandoriai būna
ir pabandykite tai padaryti, vienas yra vyksta pirmasis ten patekti
o kitas s ketina po ten.
Taigi, galų gale, aš pridėjo du.
Jūs matote, ką turiu galvoje?
GERAI.
>> Ilgaamžiškumas yra gana paprasta.
Kai sandoris Pripažįstama, kad tai
bus ten net jei sistema sugenda.
Kai ši sistema susitraukia, kad sandoris, kuris buvo padarytas
iš tikrųjų bus ten.
Taigi, kad garantijos Rūgščių sandorius.
Tai yra labai gražus garantijos turėti į duomenų bazę,
bet jie tuo kainą.
Teisė?
>> Kadangi problemos su šia sistema yra
jei yra į duomenų pertvara rinkinys, turiu priimti sprendimą.
Aš ruošiuosi leisti atnaujinimai vieną ar kitą pusę.
Ir jei tai atsitiks, tada aš nebėra vyksta
kad būtų galima palaikyti šios savybės.
Jie nebus nuoseklūs.
Jie nebus izoliuota.
Tai kur jis skyla už reliacinių duomenų bazių.
Tai yra priežastis, reliacinė duomenų bazės mastelį vertikaliai.
>> Kita vertus, turime tai, kas vadinama BASE technologiją.
Ir tai yra jūsų NoSQL duomenų bazės.
Gerai.
Taigi, mes turime CP, ap duomenų bazių.
Ir tai yra tai, ką jūs vadinate esmės galima, minkštas valstybė, galiausiai
nuoseklūs.
GERAI?
>> Iš esmės galima, nes jie pertvarų tolerantiškas.
Jie visada bus ten, net jei ten
tinklo disko tarp mazgų.
Jei aš galiu pasikalbėti su mazge, aš bus galima skaityti duomenis.
GERAI?
Aš ne visada gali būti suteikta galimybė rašyti duomenys, jei aš nuosekliai platforma.
Bet aš galės skaityti duomenis.
>> Minkštas būklė rodo kad, kai aš perskaičiau, kad duomenys,
jis gali būti toks pat, kaip kitų mazgų.
Jei teisė buvo išduotas mazgas kažkur kitur klasterio
ir tai nebuvo pakartotas visoje klasteris dar kai aš perskaičiau, kad duomenys,
kad valstybės gali būti nuoseklūs.
Tačiau, ji bus galiausiai nuosekliai,
Tai reiškia, kad, kai rašymo yra pagamintas prie sistemos,
jis pasidaugina visoje mazgų.
Ir, galų gale, kad valstybės bus pradėta tam,
ir ji bus nuosekliai būklė.
>> Dabar, BŽŪP teorema tikrai vaidina tik viena sąlyga.
Ši sąlyga yra tada, kai tai atsitiks.
Nes kai jis veikia normalus režimas, nėra pertvarų,
viskas atitinka ir prieinama.
Jums tik nerimauti BŽŪP kai mes turime tą skyrių.
Taigi tie, kurie retai.
Bet, kaip sistema reaguoja, kai tie įvyksta, diktuoja, kokio tipo sistemos
mes susiduriame su.
>> Taigi leiskite pažvelgti, kas kad atrodo už AP sistemas.
GERAI?
AP sistemos būna dviejų skonių.
Jie būna skonį, kuris yra Meistras, 100%, visada prieinama.
Ir jie ateina į Kitų skonių, kurie sako,
jūs žinote, ką aš ruošiuosi jaudintis apie šį skaidymo dalykas
kai faktinis pertvarų pasitaiko.
Priešingu atveju, ten bus pagrindinis mazgai, kuris ketina imtis teises.
GERAI?
>> Taigi, jei mes kažką panašaus Kasandra.
Kasandra būtų meistras meistras, tegul man rašyti į bet mazgas.
Taigi, kas atsitiks?
Taigi turiu objekte duomenų, kad egzistuoja dviejų mazgų.
Pavadinkime šį objektą S. Taigi, mes turime būseną S.
Mes turime keletą operacijų nuo S, kad tebevyksta.
Kasandra leidžia man rašyti kelių mazgų.
Taigi tarkim gaunu rašyti s iki dviejų mazgų.
Na, ką baigiasi vyksta, mes vadiname, kad tam skaidymo atveju.
Gali būti ne fizinė tinklo pertvara.
Bet todėl, kad konstrukcijos iš sistemos, tai yra
iš tikrųjų atitvarų kuo greičiau kaip aš galiu gauti dėl dviejų mazgų rašyti.
Tai ne privertė mane rašyti visi per vieną mazgą.
Aš rašau dėl dviejų mazgų.
GERAI?
>> Taigi dabar turiu dvi valstybes.
GERAI?
Kas nutiks anksčiau ar vėliau,
ten bus replikacijos įvykis.
Ten bus ką mes vadinamas disko atkūrimo, kuris
kur šių dviejų narės grįžti kartu
ir ten bus algoritmas kuri veikia viduje duomenų bazėje,
nusprendžia, ką daryti.
GERAI?
Pagal nutylėjimą, Paskutiniai pakeitimai laimi daugelyje AP sistemas.
Taigi ten paprastai Numatytasis algoritmas, kas
jie vadina atg funkcija, kažkas, kad
vadinsis jei ši sąlyga aptinkamas vykdyti tam tikrą logiką
išspręsti šio konflikto.
GERAI?
Numatytoji atgalinių nevykdymas Resolverio daugumoje AP duomenų bazėse
yra atspėti, ką, laiko žymos laimi.
Tai buvo Paskutiniai pakeitimai.
Aš ruošiuosi įdėti, kad atnaujinti ten.
Aš gali sąvartynas šį įrašą, kad aš dempingo ne į atkūrimo Prisijungti
taip, kad vartotojas gali grįžti vėliau ir sako, ei, ten buvo susidūrimas.
Kas atsitiko?
Ir jūs iš tikrųjų galite iškelties įrašus visi susidūrimai ir rollbacks
ir pamatyti, kas atsitiks.
>> Dabar, kaip vartotojas, taip pat galite įtraukti logika į tą atg.
Taigi jūs galite pakeisti, kad atgalinių operacija.
Galite pasakyti, ei, aš noriu priemonių atitaisyti šiuos duomenis.
Ir aš noriu pabandyti ir sujungti šiuos du įrašus.
Bet tai priklauso nuo jūsų.
Duomenų bazė neturi žinoti, kaip padaryti, kad pagal nutylėjimą. Dauguma laiko,
vienintelis dalykas, duomenų bazės žino, kaip padaryti, tai pasakyti,
tai vienas buvo paskutinis įrašas.
Štai vienas, kad laimės, ir tai vertė Aš ruošiuosi įdėti.
Kai tą Partition Recovery ir replikacija įvyksta,
mes turime savo valstybę, kuri dabar yra S svarbiausias, kuris yra
suliejimo valstybė visų tų objektų.
Taigi AP sistemos turi tai.
CP sistemos nereikia nerimauti tai.
Nes kaip tik skaidinys ateina į žaidimą, jie tiesiog nustoti vartoti
rašo.
GERAI?
Taigi, kad labai lengva spręsti yra suderinamas
kai jūs nesutinkate visus atnaujinimus.
Štai su CP sistemos padaryti.
Gerai.
>> Taigi pakalbėkime šiek tiek tiek apie prieigos modelius.
Kai kalbame apie NoSQL, tai Viskas apie prieigos modelio.
Dabar, SQL ad hoc užklausas.
Tai reliacinės parduotuvė.
Neturime nerimauti apie prieigos modelis.
Aš rašau labai sudėtingą užklausą.
Jis eina ir gauna duomenis.
Štai ką tai atrodo kaip, normalizavimas.
>> Taigi, šio konkretaus struktūrą, mes ieškome ne produktų katalogą.
I turi skirtingas produktų rūšis.
Turiu knygas.
Turiu albumus.
Turiu vaizdo įrašus.
Skirtumas tarp produktų santykiai ir bet kurios šių knygų, albumų viena,
ir video lentelės yra 1: 1.
Gerai?
Aš turiu produkto ID, ir tokiu ID Atitinka
į knygą, albumą arba įrašą.
GERAI?
Štai 1: 1 santykis visoje tose lentelėse.
>> Dabar books-- visi jie turi root savybės.
Jokiu problemu.
Tai puiku.
Vienas prie vieno santykiai, gaunu visus duomenys man reikia apibūdinti šią knygą.
Albums-- Fotoalbumai takelius.
Tai yra tai, ką mes vadiname vienas su daugeliu.
Kiekvienas albumai galėtų turėti daug takelius.
Taigi už kiekvieną kūrinį albumas, galėčiau
dar vienas rekordas šiame vaikų stalo.
Taigi aš sukurti vieną įrašą į Mano albumai stalo.
Galiu sukurti kelis įrašus Takeliai stalo.
Vienas su daugeliu santykiai.
>> Šis ryšys yra tai, ką mes vadiname daugelis su daugeliu ".
GERAI?
Jūs matote, kad aktoriai galėtų būti daug filmų, daug video.
Taigi, ką mes darome, yra mes įdėti šią kartografavimo Lentelėje tarp tų, kurių ji tiesiog
žemėlapiai aktorius ID į vaizdo įrašo ID.
Dabar galiu kurti užklausą, prisijungia video per aktorius video į veikėjų,
ir tai man suteikia gražią sąrašą visi filmai ir visi aktoriai
kurie buvo tame filme.
>> GERAI.
Taigi čia mes einame.
Vienas prie vieno yra aukščiausio lygio santykiai; vienas su daug,
Fotoalbumai į takelius; daugelis su daugeliu ".
Tie trys aukščiausio lygio santykiai į jokią duomenų bazę.
Jei žinote, kaip tie, santykiai dirbti kartu,
tuomet jūs žinote, daug apie duomenų bazėje jau.
Taigi NoSQL veikia šiek tiek kitaip.
Pagalvokime apie sekundę, kas tai Atrodo, kad eiti gauti visus savo produktus.
>> Be reliacinės parduotuvėje, aš nori gauti visas savo produktus
nuo visų mano produktų sąrašą.
Štai užklausų daug.
Gavau visų mano knygų užklausą.
Gavau iš mano albumų užklausą.
Ir aš turiu visų mano video užklausą.
Ir aš įdėti jį visi kartu į sąrašą,
ir tarnauti jį atgal į viršų į programa, kuri manimi prašydamas.
>> Norėdami gauti savo knygas, aš prisijungti Produktai ir knygos.
Norėdami gauti savo albumus, gavau prisijungti Produktai, albumai, ir kelio protokolai.
Ir gauti savo vaizdo įrašus, turiu prisijungti Produktai video,
prisijungti per aktorius video, ir atnešti Aktoriai.
Štai trys užklausas.
Labai sudėtingas užklausas surinkti vieną rezultatų rinkinį.
>> Štai mažiau nei optimalus.
Tai kodėl kai kalbame apie duomenų struktūros ŠTAI
pastatytas būti agnostikas į prieigos pattern-- gerai tai puiku.
Ir jūs galite pamatyti tai tikrai gražus kaip mes organizuotas duomenis.
Ir žinote ką?
Aš turiu tik vieną rekordą aktorius.
>> Tai kieta.
Aš deduplicated visus mano veikėjus, ir aš išlaikė savo asociacijas
Šiame žemėlapių lentelę.
Tačiau vis duomenis iš tampa brangus.
Aš siunčiant CPU visame sistema prisijungti šių duomenų struktūras kartu
gebėti ištraukti tą duomenis atgal.
>> Taigi, kaip man gauti aplink, kad?
Be NoSQL tai apie agregacija, o ne normalizavimas.
Taigi mes norime pasakyti, kad mes norime remti prieigos modelis.
Jei prieigos modelį į paraiškas,
Man reikia gauti visus savo produktus.
Leiskite įdėti visus produktus į vieną lentelę.
Jei aš įdėti visas produktus į vieną lentelę, Aš galiu tik pasirinkti visus produktus
Iš šios lentelės ir man visa tai.
Na, kaip man tai padaryti?
Na NoSQL nėra struktūra į lentelę.
Mes kalbame šiek tiek apie kaip tai veikia Dinamo dB.
Bet jūs neturite pats požymiai ir tie patys savybės
į kiekvieną eilutę, į kiekvieną elementą, kaip jūs padaryti SQL lentelę.
Ir ką tai leidžia man padaryti yra daug dalykų,
ir man labai lanksčiai.
Šiuo konkrečiu atveju, aš turiu produktų dokumentus.
Ir tai ypač Pavyzdžiui, viskas
yra šių produktų stalo dokumentas.
Ir už knygą produktas gali turėti tipo ID, kuriame nurodoma knygą.
Ir paraiška būtų pereiti tą ID.
>> Tuo paraiškos pakopos, aš ruošiuosi pasakyti O, koks tipo įraše tai yra?
Oi, tai knyga įrašas.
Rezervuokite įrašai turi šias savybes.
Leiskite sukurti knyga objektą.
Taigi, aš ruošiuosi užpildyti knyga objektas šią prekę nėra.
Sekanti prekė ateina ir sako, kas tai daiktas?
Na šis straipsnis yra albumas.
Oi, aš gavau visai kita apdorojimas rutina, kad
nes tai albumas.
Jūs matote, ką turiu galvoje?
>> Taigi prašymas tier-- aš tiesiog pasirinkite visus šiuos įrašus.
Jie visi pradėti ateina.
Jie gali būti visų skirtingų rūšių.
Ir tai paraiška logika kad persijungia per šių tipų
ir nusprendžia, kaip juos apdoroti.
>> Vėlgi, todėl mes optimizuojant schema, skirta prieigos modelio.
Mes darome jį griūva tas lenteles.
Mes iš esmės atsižvelgiant Šie normalizuoja struktūros,
ir mes pastatas hierarchinės struktūros.
Viduje kiekvieno iš šių įrašų Aš ruošiuosi pamatyti masyvo savybes.
>> Viduje šio dokumento Albumai, Matau matricos takelius.
Šios trasos dabar become-- tai Iš esmės tai vaiko stalo, kad
egzistuoja čia, šioje struktūroje.
Taigi jūs galite tai padaryti DynamoDB.
Jūs galite tai padaryti MongoDB.
Jūs galite tai padaryti bet kuriuo NoSQL duomenų bazę.
Sukurti šių tipų hierarchinės duomenų struktūros
kad leidžia jums gauti duomenis labai greitai, nes dabar aš
neturi, kad atitiktų.
Kai aš įterpti eilutę į Takeliai stalo arba eilutė į albumų stalo,
Turiu atitikti tą schemą.
Aš turėti atributą arba parengimą nuosavybė, kuri yra apibrėžta toje lentelėje.
Kiekvienas iš jų, kai aš įdėti šią eilutę.
Tai ne į NoSQL atveju.
>> Galiu turėti visiškai skirtingas savybės kiekvieną dokumentą
kad aš įterpti į kolekciją.
Taigi labai galingas mechanizmas.
Ir tai tikrai, kaip jūs optimizuoti sistemą.
Nes dabar, kad užklausą, o ne Stojant į visas šias lenteles
ir vykdyti pusė tuzino užklausas atsitraukti duomenis man reikia,
Aš surašant vieną užklausą.
Ir aš Iteracja visoje nustatytus rezultatus.
ji suteikia jums idėja iš NoSQL galia.
Aš ruošiuosi rūšies eiti į šoną čia ir kalbėti šiek tiek apie tai.
Tai yra daugiau rūšies iš rinkodaros ar technology--
technologijų rinkodara tipo diskusija.
Tačiau svarbu suprasti, nes jei pažvelgsime į viršų
čia ne šioje schemoje, mes ieškome, kas
yra tai, ką mes vadiname technologija hype kreivė.
Ir ką tai reiškia naujų dalykų ateina į žaidimą.
Žmonės galvoja, tai puiku.
Aš išspręsti visas savo problemas.
>> Tai gali būti galas gale, būti visiems viskuo.
Ir jie pradeda jį naudoti.
Ir jie sako, ši medžiaga neveikia.
Tai nėra teisinga.
Senas dalykų buvo geriau.
Ir jie grįžti į darai dalykai, kaip jie buvo.
Ir tada galiausiai jie išeina, žinote, ką?
Ši medžiaga yra ne taip jau blogai.
Oi, tai, kaip ji veikia.
Ir kai jie išsiaiškinti, kaip ją darbai, jie pradeda vis geriau.
>> Ir juokingas dalykas apie tai yra, tai kokios linijos iki ko
mes vadiname technologijų įdiegimą kreivė.
Taigi, kas atsitinka, yra mes turime kai rūšiuoti technologija gaiduką.
Atsižvelgiant į duomenų bazių atveju, tai duomenys spaudimo.
Mes kalbėjome apie didelių vandens kiekis Duomenų slėgio visoje laiką.
Kai kurie duomenys slėgio hitai tam tikras taškas, tai technologija gaiduką.
>> Tai vis per brangu.
Tai užtrunka pernelyg ilgai apdoroti duomenis.
Mes turime kažką geriau.
Jūs gaunate novatoriai ten bėgioja,
bando išsiaiškinti, kas yra sprendimas.
Kokia naujoji idėja?
>> Kas yra šalia geriausias būdas tai padaryti šį dalyką?
Ir jie sugalvoti kažką.
Ir su nekilnojamojo skausmo žmonės, kad tuo kraujavimo krašto vaikinai,
jie šokinėti per jį, nes jie turi atsakyti.
Dabar, kas neišvengiamai happens-- ir tai vyksta dabar į NoSQL.
Matau jį visą laiką.
>> Kas atsitinka, yra neišvengiamai žmonės pradeda naudoti naują nuorodą
tas pats, kaip jie panaudojo seną nuorodą.
Ir jie išsiaiškinti ją neveikia taip pat.
Aš negaliu prisiminti, kas man buvo kalbėti anksčiau šiandien.
Bet tai kaip, kai Pneumatinis Gręžimo plaktukas buvo išrastas,
žmonės neturėjo sūpynės jį per jų galvos sutriuškinti betoną.
>> Bet tai, kas vyksta su NoSQL šiandien.
Jei eisi į daugumos parduotuvių, jie bando būti NoSQL parduotuvės.
Ką jie daro yra jie naudoja NoSQL,
ir jie dėdami pilnas reliacinės schemos.
Nes tai, kaip jos dizainas duomenų bazes.
Ir jie įdomu, kodėl jis neatlieka labai gerai?
Vaikinas, šis dalykas dvokia.
Aš turėjau išlaikyti visas mano prisijungia in-- tai kaip, ne, ne.
Išlaikyti prisijungia?
Kodėl jūs sujungiant duomenis?
Jūs neturite prisijungti prie duomenų NoSQL.
Jūs apdoroja ją.
>> Taigi, jei norite to išvengti, išmokti kaip įrankis veikia kol jūs iš tikrųjų
pradėti jį naudoti.
Nesistenkite ir naudoti Naujomis priemonėmis Tas pats būdas, kurį naudojote senus įrankius.
Jūs ketinate turėti blogos patirties.
Ir kiekvieną kartą tai, kas tai yra apie.
Kai mes pradedame artėja čia tai, nes žmonės suprato,
kaip naudoti įrankius.
>> Jie padarė tą patį, kai reliacinės duomenų bazės buvo išrastas,
ir jie buvo pakeisti failų sistemas.
Jie bandė sukurti failų sistemas su reliacinių duomenų bazių
nes tai, ką žmonės supranta.
Tai neveikia.
Taigi suprasti geriausią praktiką technologijos dirbate su
yra didžiulis.
Labai svarbus.
>> Taigi mes ketiname patekti į DynamoDB.
DynamoDB yra AWS s visiškai valdoma NoSQL platformą.
Ką visiškai valdoma reiškia?
Tai reiškia, kad jūs nereikia tikrai jaudintis dėl nieko.
>> Jūs ateiti, pasakyti mums, man reikia staliuką.
Jis turi tai daug pajėgumus.
Paspausite mygtuką, ir mes nuostata visa infrastruktūra, už scenos.
Dabar tai yra milžiniškas.
>> Nes kai jūs kalbate apie mastelio duomenų bazę,
NoSQL duomenų klasteriai at masto, veikia petabaitus,
veikia milijonus Pirkimas per sekundę,
šie dalykai yra ne mažas grupes.
Mes kalbame tūkstančius egzempliorių.
Valdymas tūkstančius atvejų, net virtualių atvejų,
yra tikras skausmas užpakalis.
Aš turiu galvoje, manau, kad apie kiekvieną kartą, kai operacinė sistema pleistras išeina
arba naujas duomenų bazės versija.
Ką tai reiškia Jums operatyviai?
Tai reiškia, kad jūs turite 1,200 serveriai, kurie turi būti atnaujintas.
Dabar net su automatika, kad gali būti ilgą laiką.
Tai gali sukelti daug veiklos galvos skausmas,
nes aš gali turėti paslaugas žemyn.
>> Kaip atnaujinti šias duomenų bazes, aš gali padaryti mėlyna žalia diegimą
kur aš įdiegti ir atnaujinti pusė mano mazgai, ir tada atnaujinti kitą pusę.
Paimkite tuos žemyn.
Taigi valdyti infrastruktūrą skalė yra labai skausminga.
Ir AWS imtis, kad skausmas iš jo.
Ir NoSQL duomenų bazės gali būti ypač skausminga
dėl to, kad, kaip jie skalę.
>> Scale horizontaliai.
Jei norite gauti didesnį NoSQL duomenų, perkate daugiau mazgų.
Kiekvienas mazgas perkate Kita veiklos galvos skausmas.
Tad kažkas tai padaryti už jus.
AWS gali tai padaryti.
>> Mes palaikome dokumentas pagrindines vertybes.
Dabar mes nėjo per daug į kita diagramos.
Yra įvairių daug skonių NoSQL.
Jie visi gauti natūra munged kartu šiuo klausimu.
Jūs galite peržvelgti DynamoDB ir pasakyti "taip", mes abu dokumentas ir rakto
laikyti šį punktą.
Ir jūs galite ginčytis savybes viena virš kitos.
Man Daug tai yra tikrai šešių vieno pusę nuo kito dešimčių.
Kiekvienas iš šių technologijų vienas yra FINE technologijos ir bauda sprendimas.
Nepasakyčiau MongoDB yra geresnė ar blogiau nei sofos, tada Cassandra,
tada Dinamo, arba atvirkščiai.
Aš turiu galvoje, tai yra tik galimybės.
>> Tai greitas ir tai atitinka bet skalę.
Taigi tai yra viena iš didžiausių premijas jūs gaunate su AWS.
Su DynamoDB yra gebėjimas gauti mažą vienaženklis
milisekundės latentinis bet skalę.
Kad buvo projektavimo tikslas sistemos.
Ir mes turime klientų, kurie yra daro milijonai operacijų per sekundę.
>> Dabar aš eisiu per kai kurias iš tų, naudoti atvejus per kelias minutes čia.
Integruotą prieigą control-- mes turime, ką mes vadiname
Tapatybės prieigos valdymo arba Iam.
Jis persmelkia kiekvieną sistemą, kas paslauga, kuri siūlo AWS.
DynamoDB yra ne išimtis.
Jūs galite kontroliuoti prieigą į DynamoDB lentelėse.
Visose savo AWS sąskaitos pagal apibrėžti prieigos vaidmenis ir leidimus
į IAM infrastruktūrą.
>> Ir tai labai svarbus ir neatsiejamas komponentas ką mes vadiname įvykį Skatinami Programavimas.
Dabar tai yra nauja paradigma.
>> Auditorija: Kaip tavo kursas tiesa pozityvai, palyginti su netikrų neigiamų
Jūsų prieigos kontrolės sistema?
RICK Houlihan: Tikrai teigiamų palyginti su netikrų neigiamų?
Auditorija: Grįžimas ką Jums reikia grąžinti?
Skirtingai nei vieną kartą, o tai negrąžina, kai ji turi patvirtinti?
>> RICK Houlihan: aš negalėjau pasakyti, kad.
Jei yra kokių nors nesėkmes kokia apie tai,
Nesu asmuo paklausti kad visų pirma klausimas.
Bet tai geras klausimas.
Būčiau įdomu žinoti kad aš, iš tikrųjų.
>> Ir taip, tada vėl nauja paradigma yra įvykis, vykdomas programas.
Tai yra idėja, kad jūs galite dislokuoti sudėtingas programas,
gali veikti labai, labai didelis skalę be jokios infrastruktūros kokia.
Be jokios fiksuotos infrastruktūra apskritai.
Ir mes kalbame šiek tiek apie tai, ką tai reiškia, kaip mes
gauti į kitą porą diagramas.
>> Pirmas dalykas, kurį mes padarysime yra mes kalbame apie lentelių.
API duomenų tipai Dynamo.
Ir pirmas dalykas, kurį jūs pastebėsite, kai jums pažvelgti į tai,
Jei esate susipažinę su bet duomenų bazėje, duomenų bazės tikrai du rūšies API
Aš jį vadiname.
Arba dvi API.
Vienas iš tų, būtų administracinis API.
>> Tai, ką jie rūpinasi Duomenų bazės funkcijos.
Saugojimo variklį konfigūravimas, steigti ir pridedant lentelių.
sukurti duomenų katalogai ir atvejų.
Tai Quake į DynamoDB, jums turi labai trumpus, trumpus sąrašus.
>> Taigi kitomis duomenų bazėmis, jūs galite pamatyti dešimtis
komandų, iš administracinių komandas, konfigūravimas
Šios papildomos galimybės.
Be DynamoDB jums nereikia tiems nes Jums nereikia konfigūruoti sistemą, mes darome.
Taigi vienintelis dalykas, ką jums reikia padaryti, tai pasakykite man, ką Dydžių lentelė man reikia.
Taigi Jūs gaunate labai ribotas rinkinys komandas.
>> Gauni CREATE TABLE Update, Stalo, Ištrinti lentelę, ir aprašyti lentelę.
Tie, kurie tik ką jums reikia DynamoDB.
Jums nereikia saugojimo Variklio konfigūracija.
Man nereikia nerimauti replikacija.
Man nereikia nerimauti sharding.
>> Man nereikia jaudintis apie bet kokį šio stuff.
Mes visa tai už jus.
Taigi, kad didžiulis pridėtinių kad tiesiog nuimti savo plokštelę.
Tada mes turime CRUD operatorius.
CRUD yra kažkas, ką mes skambinti duomenų bazėje ŠTAI
Kurti, atnaujinti, naikinti operatorius.
Tai yra jūsų bendra duomenų bazės operacijų.
Dalykų, pavyzdžiui, pripilk punkte, gauti elementą, atnaujinimas daiktų, ištrinti elementus, partijos užklausą, nuskaityti.
Jei norite nuskaityti visą lentelę.
Ištraukite viską nuo stalo.
Vienas iš gražumynai apie DynamoDB tai leidžia lygiagrečiai skenavimas.
Taigi jūs iš tikrųjų galite leiskite man žinoti, kiek Siūlai norite paleisti tą nuskaitymas.
Ir mes galime paleisti tuos temas.
Mes galime nugara, kad nuskaityti iki keliose temas
todėl jūs galite nuskaityti visą lentelę vietos labai, labai greitai DynamoDB.
>> Kitas API mes turime yra ką mes vadiname mūsų Srautai API.
Mes neketiname kalbėti per daug apie tai dabar.
Aš turiu kai turinys vėliau On, apie tai denio.
Bet Srautai yra tikrai running-- galvoti apie tai, kaip laikas užsisakyti
ir pertvarų Pakeitimai registruojami.
Viskas, kas vyksta ant Lentelėje rodo ant upelio.
>> Kiekvienas rašyti prie stalo rodo ant upelio.
Galite skaityti, kad srautą ir galite daryti tai, ko su juo.
Mes kalbame apie tai, ką rūšių dalykų, kuriuos
daryti su, pavyzdžiui, replikacijos dalykų, kuriant antrinius rodiklius.
Visi tikrai cool rūšių dalykų, kuriuos galite padaryti, kad.
>> Duomenų tipai.
Be DynamoDB, mes remiame tiek raktą Pigūs ir dokumentų duomenų tipai.
Kairėje pusėje ekrano čia mes turime mūsų pagrindinius tipus.
Pagrindiniai vertės rūšių.
Tai yra įsipareigojimų, numeriai ir dvejetainius.
>> Taigi tik trys pagrindinės rūšys.
Ir tada jūs galite turėti rinkiniai tie.
Vienas iš gražumynai apie NoSQL yra Jums gali būti masyvus, kaip savybėmis.
Ir su DynamoDB galite būti masyvus Pagrindinių tipų kaip šaknis turtą.
>> Ir tada ten dokumentų tipus.
Kiek žmonių yra susipažinę su JSON?
Vaikinai susipažinę su JSON tiek daug?
Tai iš esmės Javaskriptą, Objektas, Žymėjimai.
Jis leidžia jums esmės apibrėžti hierarchinis struktūrą.
>> Galite išsaugoti JSON dokumentą DynamoDB naudojant bendrus komponentus
arba statybiniai blokai, kurie yra prieinami daugeliu programavimo kalbų.
Taigi, jei turite Java, jūs žiūri žemėlapius ir sąrašus.
Galiu sukurti objektai, kad Apylinkių žemėlapis.
Žemėlapį kaip pagrindinių vertybių saugomi kaip savybėmis.
Ir tai gali turėti sąrašus vertės per šių savybių.
Galite išsaugoti šį kompleksą hierarchinė struktūra
kaip vieną atributą iš DynamoDB prekę nėra.
>> Taigi lenteles DynamoDB, kaip ir dauguma NoSQL duomenų bazės, lentelės turi daiktų.
Be MongoDB darytumėte skambinti šiuos dokumentus.
Ir tai būtų sofos bazę.
Dokumentas taip pat duomenų.
Jūs vadinate šiuos dokumentus.
Dokumentai arba turėti atributus.
Atributai gali egzistuoti arba nėra ant elemento.
Be DynamoDB, ten vienas privalomas atributas.
Tiesiog norėčiau į reliacinės duomenų bazės, turite pirminį raktą ant stalo.
>> DynamoDB turi tai, ką mes vadiname maišos klavišą.
Hash raktas turi būti unikalus.
Taigi, kai aš apibrėžti maišos lentelę, Iš esmės, ką aš sakau
yra kiekvienas daiktas turi maišos klavišą.
Ir kas maišos raktas turi būti unikalus.
>> Kiekvienas elementas yra apibrėžta tos unikalios maišos raktu.
Ir ten gali būti tik vienas.
Tai gerai, bet dažnai ką žmonės turi
yra jie nori tai maišos raktas padaryti šiek tiek daugiau
nei tiesiog būti nurodomas unikalus identifikatorius.
Dažnai mes norime naudoti šią maišos raktą kaip aukščiausio lygio agregavimo kibirą.
Ir kaip mes tai padaryti yra pridedant tai, ką mes vadiname nuotolio klavišą.
>> Taigi, jei tai tik maišos stalo, tai turi būti unikalus.
Jei tai maišos ir asortimentas lentelė, derinys maišos ir intervale
turi būti unikalus.
Taigi manau, apie tai šiuo būdu.
Jei turiu forumą.
Ir forma yra temos, ji turi pareigų, jis turi atsakymus.
>> Taigi, aš gali turėti maišos raktas, kuris yra tema ID.
Ir aš gali turėti nuotolio raktą, kuris yra atsakas ID.
Tokiu būdu, jei noriu gauti visi Atsakymai tikra tema,
Aš galiu tik užklausti maišos.
Galiu tik pasakyti, man visi elementus, kurie turi šį maišos.
Ir aš ruošiuosi gauti kiekvieną klausimą arba rašyti šiuo konkrečiu klausimu.
Šie aukščiausio lygio agregavimai yra labai svarbūs.
Jie remia pagrindinį prieigą modelio taikymo.
Apskritai, šis yra tai, ką mes norime daryti.
Mes norime, kad table-- kaip jums įkelti lentelę,
norime struktūrizuoti duomenis per tokiu būdu, stalo
kad paraiška gali labai greitai gauti tuos rezultatus.
Ir dažnai būdas tai padaryti yra išlaikyti šias sankaupas, kaip mes
įterpti duomenis.
Iš esmės, mes skleisti duomenis į šviesią kibirą, nes ji ateina.
>> Klasės raktai leidžia me-- maišos raktai turi būti lygybė.
Kai aš užklausą maišos, turiu pasakyti, duok man maišos, lygią tai.
Kai aš užklausti asortimentą, aš galima sakyti, duok man asortimentą
kad yra naudojant bet kokios rūšies turtingas operatorius, mes remiame.
Duok man visas maišos elementus.
Ar tai lygūs, didesnė mažiau nei, ji prasideda,
ji egzistuoja tarp šių dviejų verčių?
Todėl šie diapazono užklausų tipai kad mes visada domina.
Dabar vienas dalykas apie duomenis, kai pažvelgti prieigą prie duomenų, kai
Jums prieiti prie duomenų, tai visada apie An agregaciją.
Jis visada apie įrašų , kurie yra susiję su tai.
Duok man viską čia that's-- visi dėl šio kredito kortelės sandorių
paskutinį mėnesį.
Tai labai agregacija.
>> Beveik viską, ką daryti į duomenų bazė yra keletas sumavimo natūra.
Taigi, kad galėtų būti suteikta apibrėžti Šie kaušai ir duoti jums šias asortimentą
atributus, kad būtų galima užklausti apie, turtuoliams užklausos remti daug,
daug, daug taikymas prieigos modelius.
>> Taigi kitas dalykas maišos pagrindinis Ar tai suteikia mums mechanizmą
kad būtų galima skleisti duomenis aplink.
NoSQL duomenų bazės geriausiai veikia kai duomenys yra tolygiai
pasiskirstęs klasterius.
Kiek žmonių yra susipažinę su maišos algoritmai?
Kai aš sakau, maišos ir hashing-- nes yra maišos algoritmą
yra, kad galėtų generuoti būdas atsitiktinis vertė iš bet kurios vertė.
Taigi, šiame konkrečiu atveju maišos algoritmas mes paleisti ND 5 pagrįsta.
>> Ir jei turiu ID, ir tai mano maišos raktas, turiu 1, 2, 3.
Kai aš paleisti maišos algoritmą, jis ketina grįžti ir pasakyti,
gerai 1 lygu 7B, 2 lygi 48, 3 yra lygus CD.
Jie išplito visame rakto erdvėje.
Ir kodėl jums tai padaryti?
Nes tai užtikrina, kad galiu įdėti įrašus keliose mazgų.
>> Jei darau tai pakopomis, 1, 2, 3.
Ir aš turiu maišos asortimentą, kuris Veikia šiuo konkrečiu atveju,
mažas maišos erdvės, ji veikia nuo 00 iki FF,
tada įrašai ketinate ateiti ir jie ketina eiti 1, 2, 3, 4, 5,
6, 7, 8, 9, 10, 11, 12.
Kas atsitinka?
Kiekvienas įdėklas vyksta prie to paties mazge.
Jūs matote, ką turiu galvoje?
>> Nes kai aš padalinti erdvę, ir aš skleisti šiuos įrašus visoje,
ir aš pertvarų, aš ruošiuosi pasakyti 1 skaidinys turi svarbų vietos 0 iki 54.
Pasiskirstymo 2 yra nuo 55 iki 89.
Pasiskirstymo 3 AA FF.
Taigi, jei aš naudoju tiesiškai incrementing ID, jūs galite pamatyti, kas vyksta.
1, 2, 3, 4, 5, 6, visi būdas iki 54.
Taigi, kaip aš kala įrašų į sistemą,
viskas baigiasi vyksta į vieną mazgą.
>> Tai nėra gerai.
Tai labai antipattern.
Be MongoDB jie turi šią problemą Jei nenorite naudoti maišos klavišą.
MongoDB suteikia jums galimybę iš maišos pagrindinį vertę.
Jūs visada turėtumėte daryti, jei Jūs naudojate incrementing maišos
raktas MongoDB, ar jums bus vinimis kas rašyti į vieną mazgą,
ir jums bus apriboti Jūsų Parašyti pralaidumas blogai.
>> Auditorija: Ar tai A9 169 dešimtosios?
>> RICK Houlihan: Taip, tai kažkur aplink ten.
A9, aš nežinau.
Jūs norite turėti gauti mano dvejetainis į dešimtainį skaičiuoklė.
Mano smegenys neveikia, kaip kad.
Auditorija: Tiesiog greitai vienas Jūsų Mongo komentarus.
Taigi yra Objekto ID, kuris ateina gimtoji su Mongo tai padaryti?
RICK Houlihan: Ar tai padaryti?
Jei tai nurodyti.
Su MongoDB, jūs turite galimybę.
Galite specify-- kiekvieną dokumentą MongoDB turi turėti pabraukimo ID.
Štai unikalus vertė.
>> Be MongoDB galite nurodyti ar maišos, ar ne.
Jie tiesiog suteikti jums galimybę.
Jei žinote, kad tai atsitiktinai, ne problema.
Jums nereikia daryti.
Jei žinote, kad tai nėra atsitiktiniai, kad tai pokyčio, tada padaryti maišos.
>> Dabar apie ką maišos, kai jūs maišos
value-- ir tai yra kodėl maišos raktai visada
unikalių užklausos, nes aš pasikeitė vertė, dabar aš negaliu padaryti nuotolio užklausą.
Aš negaliu pasakyti, ar tai tarp tą ar aną,
nes maišos vertė nesiruošia būtų lygiavertė tikrosios vertės.
Taigi, kai jūs maišos, kad raktas, tai tik lygybė.
Tai kodėl DynamoDB maišos raktą užklausos visada tik lygybė.
>> Taigi, dabar tam tikrame intervale key-- kai aš pridėti, kad svyruoja raktą,
tie klasės pagrindiniai fiksuoja visus ateiti ir jie gauti saugomi ant tos pačios disko.
Taigi jie yra labai greitai, lengvai Gauta, nes tai yra maišos,
tai yra intervalas.
Ir jūs matote viską su tuo pačiu maišos
pasireiškia saugomi ant tos pačios pasiskirstymo erdvėje.
Jūs galite naudoti tą intervalą raktą padėti rasti savo duomenis arti savo tėvų.
Taigi, ką aš tikrai čia darai?
Tai yra vienas su daugeliu santykius.
Skirtumas tarp maišos rakto santykiai ir asortimentas raktas yra vienas, kad daugelis.
Galiu turėti kelis maišos raktus.
Aš gali turėti tik kelis asortimentą raktai per kiekvieną maišos klavišą.
>> Maišos apibrėžia tėvų, diapazonas apibrėžia vaikus.
Taigi jūs galite pamatyti ten analoginis čia tarp reliacinės konstrukto
ir tie patys tipai stato į NoSQL.
Žmonės kalbėti apie NoSQL kaip nonrelational.
Tai ne nonrelational.
Duomenų visada turi santykius.
Šie santykiai tik modeliuojami skirtingai.
Pakalbėkime šiek tiek tiek apie ilgaamžiškumą.
Rašydami į DynamoDB, rašo visada trieigis pakartotas.
Tai reiškia, kad mes turime tris AZ-aisiais.
AZ produkto "yra prieinamumas zonose.
Jūs galite galvoti prieinamumas Zona, kaip duomenų centre
arba duomenų centrų kolekcija.
Šie dalykai yra geografiškai izoliuotos viena nuo kitos
įvairiose gedimų zonų visoje skiriasi elektros tinklų ir salpos.
A viena AZ nepakankamumas nėra ketina imtis žemyn kitą.
Jie taip pat susijęs kartu su tamsiai pluošto.
Jis palaiko vieną sub 1 milisekundės latentinis tarp AZS.
Taigi realaus laiko duomenų atsikirtimai gali daugiabučiuose AZS.
>> Ir dažnai multi AZ dislokavimo atitinka aukštus prieinamumo reikalavimus
Daugumos įmonių organizacijų.
Taigi DynamoDB plinta per tris AZS pagal nutylėjimą.
Mes tik ketina žinių įrašymo kai du iš šių trijų mazgų grįžti
ir pasakyti, Taip, aš turiu jį.
Kodėl taip yra?
Kadangi ant nuskaitymo pusėje mes tik ketina suteikti jums duomenis atgal, kai
mes gauti iš dviejų mazgų.
>> Jei aš atkartojantis visoje trys, o aš skaitau iš dviejų,
Aš visada garantuota turėti bent vieną
iš tų, skaito būti Naujausią kopija duomenis.
Štai ką daro DynamoDB nuoseklūs.
Dabar galite pasirinkti pasukti tie nuosekliai skaito išjungtas.
Tokiu atveju aš ruošiuosi pasakyti, Aš perskaičiau tik iš vienos mazgas.
Ir aš negaliu garantuoti, kad jis ketina būti naujausią duomenų.
>> Taigi, jei Parašyti ateina, ji nėra pakartotas dar,
jūs ketinate gauti, kad kopija.
Tai labai galiausiai nuosekliai skaityti.
Ir kas tai yra pusė išlaidų.
Taigi tai yra kažkas galvoti apie tai.
Kai jūs skaitote iš DynamoDB ir jūs įkurti savo skaitymo gebėjimus
vienetai, jei pasirinksite galiausiai nuosekliai skaito, tai daug pigiau,
tai apie pusę kainos.
>> Ir todėl taupo jūsų pinigus.
Bet tai yra jūsų pasirinkimas.
Jei norite nuosekliai skaityti ar ir galiausiai jas nuosekliai skaityti.
Štai kažkas, kad jūs galite pasirinkti.
>> Pakalbėkime apie indeksus.
Taigi mes paminėti, kad aukščiausio lygio agregacija.
Mes turime maišos raktus ir mes turime nuotolio raktus.
Štai gražus.
Ir tai pirminėje stalo, aš gavo vieną maišos raktą, aš vieną diapazoną klavišą.
>> Ką tai reiškia?
Aš turiu vieną atributą, kad aš galite paleisti turtingas užklausas.
Tai diapazonas raktas.
Kiti atributai tą item-- Galiu filtruoti tuos atributus.
Bet aš negaliu daryti dalykus, pavyzdžiui, ją prasideda, arba yra didesnis nei.
>> Kaip man tai padaryti?
Galiu sukurti indeksą.
Yra dviejų tipų indeksai DynamoDB.
Indeksas yra tikrai kitą lentelės vaizdas.
Ir vietinių antrinių indeksas.
>> Pirmasis mes kalbame apie.
Taigi vietos antrinių yra egzistavo ant to paties disko, kaip ir duomenys.
Ir kaip toks, jie yra ant tas pats fizinis mazgas.
Jie yra tai, ką mes vadiname nuoseklūs.
Kitaip tariant, jie bus pripažinti išilgai su stalo rašymo.
Kai Parašyti ateina, mes rašyti per indeksą.
Mes parašyti į lentelę, ir tada mes pripažįstame.
Taigi, kad nuoseklūs.
Kai rašymo buvo pripažino iš lentelės,
tai garantuoja, kad vietinių antrinių puslapis
turės tą pačią viziją duomenimis.
Bet ką jie leidžia jums padaryti, tai nustatyti pakaitinių nuotolio raktus.
>> Turi naudoti tą patį maišos klavišą pirminės stalo,
nes jie yra bendrai, esantį ant pats pertvarų, ir jie nuoseklūs.
Bet aš galiu sukurti indeksą su įvairiais nuotolio raktus.
Taigi, pavyzdžiui, jei aš turėjo gamintojas kad buvo žalias dalys lentelė ateina.
Ir žaliavinį dalys būna ir jie sudedami surenkant.
O gal ten atminties.
>> Bet dalis, kuri buvo padaryta ši Gamintojas po šios datos,
Man reikia traukti iš mano linija.
Galiu nugara indeksą kad būtų ieškote,
sumuojant nuo dienos Gaminame tos tikrą dalį.
Taigi, jei mano aukščiausio lygio stalo buvo jau sumaišomas Gamintojo,
gal tai buvo išdėstyti dalis ID, aš gali sukurti išjungti, kad stalo indeksą
kaip sumaišomas pagal gamintoją ir svyravo nuo pagaminimo datos.
Ir tokiu būdu galėčiau pasakyti, nieko, kad buvo pagamintas tarp šių datų,
Man reikia traukti iš geležinkelio linijos.
Taigi, kad vietos vidurinė indeksas.
>> Tai turi poveikį, apriboti savo maišos pagrindinį erdvę.
Nes jie bendrai egzistavo ant tos pačios saugojimo mazgas,
jie riboja maišos raktą erdvė 10 gigabaitų.
DynamoDB pagal stalai, bus išskaidyti
jūsų stalo kas 10 gigabaitų.
Kai jūs galėsite įdėti 10 koncertai duomenų, mes eiti [PhH], ir mes pridėsime dar vieną mazgą.
>> Mes ne padalinti LSI visoje keletą skirsnių.
Mes padalinti lentelę.
Bet mes ne padalinti LSI.
Taigi, kad kažkas Svarbu suprasti
yra, jei jūs darote labai, labai, labai dideli apibendrinus,
tada jūs ketinate būti apribota 10 gigabaitų jūsų LSIs.
>> Jei tai toks atvejis, mes galime naudoti pasaulinius antrinių.
Global antrinių yra tikrai kito stalo.
Jie egzistuoja visiškai išjungti Jūsų pirminės lentelės pusėje.
Ir jie leidžia man rasti visiškai kitokia struktūra.
Taigi manau, apie tai, kaip duomenys yra įdėta į dvi skirtingas lenteles, struktūra
dviem skirtingais būdais.
>> Galiu apibrėžti visiškai skiriasi maišos raktas.
Galiu apibrėžti visiškai skiriasi asortimentas raktas.
Ir aš galiu paleisti tai visiškai nepriklausomai.
Kaip iš tiesų, aš numatęs mano skaitymo gebėjimus
ir rašyti pajėgumus Mano pasauliniai vidurinės indeksai
visiškai nepriklausomai mano pirminės stalo.
Jei aš apibrėžti šio indekso, sakau tai, kiek skaityti ir rašyti
talpa tai ketinate naudoti.
>> Ir tai yra atskiras nuo mano pirminio stalo.
Dabar abi indeksų leisti mus ne tik apibrėžti maišos ir nuotolio raktus,
tačiau jie leidžia mums projekto papildomos vertės.
Taigi, jei aš noriu skaityti nuo indekso, ir aš noriu kažkiek duomenų rinkinys,
Man nereikia grįžti į pagrindinis Lentelėje gauti papildomus atributus.
Galiu projektuoti šias papildomas atributus į lentelę
remti prieigos modelis.
Aš žinau, mes tikriausiai patekti į kai tikrai, really-- patekti į piktžolių
čia kai šios medžiagos.
Dabar aš turiu dreifas iš šio.
>> Auditorija: [nesigirdi] --table raktas reiškė buvo maišos?
Originali maišos?
Multi-skersiniai?
>> RICK Houlihan: Taip.
Taip.
Lentelėje raktas iš esmės atkreipia atgal į elementą.
Taigi indeksas yra rodyklė atgal į originalūs daiktai ant stalo.
Dabar galite pasirinkti statyti puslapis, kuris turi tik stalo raktą,
ir jokių kitų savybių.
Ir kodėl gali tai padaryti?
Na, gal aš turiu labai daug daiktų.
>> Aš tikrai tik reikia žinoti which-- Mano prieiga modelis gali pasakyti,
kokie daiktai yra šį objektą?
Nereikia grąžinti daiktą.
Aš tiesiog reikia žinoti kokie daiktai yra ją.
Taigi galite sukurti indeksus kad tik stalo klavišą.
>> Bet tai daugiausia ką in indeksas, duomenų bazės yra.
Tai už tai, kad galėtų greitai nustatyti, kurie fiksuoja,
kurios eilutės, kurios Produktai stalo turi
savybės, kad aš ieško.
>> GSIs, taip, kaip jie veikia?
GSIs esmės yra asinchroninis.
Atnaujinimo ateina į lentelę, lentelė tada asinchroniškai atnaujinama
visus savo GSIs.
Tai kodėl GSIs yra galiausiai suderintos.
>> Svarbu pažymėti, kad jei esate pastate GSIs,
ir jūs suprantate, kuriate Kitas aspektas aggregation--
Dabar tarkime, gerą pavyzdį čia yra gamintojas.
Manau, kad galėjo kalbėjo apie medicinos prietaiso gamintojas.
Medicinos prietaisų gamintojai Neretai turi išspausdintas dalių.
Dalys, kad pereiti į klubo keitimas visiems
turėti šiek tiek serijinį numerį ant jų.
Ir jie gali turėti milijonus ir milijonai ir milijardai dalys
visose prietaisų, kad jie laivą.
Na, jiems reikia sumuoti pagal įvairių matmenų, visos dalys
agregate, visi dalys, kurie buvo pagaminti
tam tikra linija, visa dalys, atėjo
nuo tam tikro gamintojo tam tikrą dieną.
Ir šie apibendrinus kartais keltis į milijardus.
>> Taigi dirbu su kai Šie vaikinai, kurie kenčia
nes jie sukurti Šie Ginormous agregavimai
jų antrinių rodiklių.
Jie gali turėti žalią dalys stalo, kad ateina kaip tik maišos.
Kiekviena dalis turi unikalų serijinį numerį.
Aš naudoju serijos numerį kaip maišos.
Gražu.
Mano žalias duomenų lentelė plinta visoje rakto erdvėje.
Mano [? rašyti?] [? Prarijus?] yra awesome.
Aš daug duomenų.
Tada, ką jie padaryti, tai jie sukurti GSI.
Ir aš sakau, jūs žinote, ką, man reikia pamatyti visi šio gamintojo dalys.
Na, visi staiga aš atsižvelgiant milijardo eilutes,
ir kita juos į vienas mazgas, nes kai
I agreguoja kaip Gamintojas ID kaip maišos,
ir dalies numeris kaip diapazone, tada visi staiga aš
Eksploatacijos mlrd dalis į ką tai gamintojas ir išlaisvino mane.
>> Tai gali sukelti daug slėgio dėl GSI,
vėl, nes aš kala vieną viršūnę.
Aš pradėti visa tai įterpia į vieną mazge.
Ir tai tikra problemiškas naudojimo atveju.
Dabar, aš turiu gerą dizainą raštas, kaip jūs išvengti.
Ir tai viena iš problemų kad aš visada dirbti.
Bet kas atsitinka, yra GSI gali neturi pakankamai pajėgumų rašymo
kad būtų galima stumti visi tie, eilutės į vieną mazgą.
Ir kas atsitinka tada yra pagrindinis klientas lentelė,
pirminė lentelė bus paminti nes GSI negali suspėti.
Taigi, mano įterpti norma kristi ant pirminės lentelės
kaip mano GSI bando suspėti.
>> Visos teisės, todėl GSI-ųjų LSI s, kurį iš jų turėčiau naudoti?
LSI s yra nuoseklūs.
GSI s yra galiausiai suderintos.
Jei tai gerai, aš rekomenduoju, naudojant GSI, jie daug lankstesnis.
LSI s gali būti modeliuojama kaip GSI.
Ir jei duomenų dydis vienam maišos raktų savo kolekciją viršija 10 gigabaitų,
tada jūs ketinate norite naudoti, kad GSI, nes tai tik sunku riba.
>> Visos teisės, todėl pleiskanojimas.
Pralaidumas Dinamo BP jūs CAN nuostata [nesigirdi]
pralaidumas prie stalo.
Mes turime klientų, kurie numatęs 60 billion--
darai 60 milijardų prašymus, nuolat veikia daugiau kaip milijono prašymų
per sekundę ant mūsų stalų.
Yra tikrai ne teorinė riba, kiek
ir kaip greitai lentelė galima paleisti "Dinamo" DB.
Yra keletas minkštas ribas savo paskyros
kad mes įdėti ten, kad jums nereikia eiti iš proto.
Jei norite daugiau nei , kad nėra problema.
Jūs ateiti mums pasakyti.
Mes riesti ratuką.
>> Kiekviena sąskaita yra tik tam tikru lygiu kiekvienoje tarnyboje, vos ne šikšnosparnis
todėl žmonės neturi išprotėti gauti sau į bėdą.
Jokia riba dydžio.
Jūs galite įdėti bet kokį skaičių daiktų ant stalo.
Iš elemento dydis tik 400 kilobaitų kiekvienas,
kad būtų punktas nėra atributai.
Taigi visų atributų suma yra ribojamas iki 400 kilobaitų.
Ir tada vėl, mes turime kad mažai LSI klausimas
su 10 gigabaitų dydžio vienam maišos.
Auditorija: Mažas skaičius, aš trūksta ką jūs man sakai, kad is--
AUDITORIJA: Oi, 400 kilobaitų ilgio yra maksimalus dydis už vienetą.
Taigi elementas turi visus atributus.
Taigi, 400 k yra bendras dydis to elemento, 400 kilobaitų.
Taigi, visų požymius kartu, visi duomenys
tai visų tų savybių, suvyniotos į viso dydžio
Šiuo metu šiandien punktas riba yra 400 k.
Taigi mastelio vėl pasiekti per padalijimo.
Pralaidumas atidėjiniai tuo stalo lygiu.
Ir ten tikrai dvi rankenėles.
Mes perskaitėme pajėgumus ir rašyti pajėgumus.
>> Taigi jie yra reguliuojamas nepriklausomai vienas nuo kito.
NVP matas griežtai atitinka skaito.
Gerai, kad jei jūs sakote noriu 1000 RCU s tas yra griežtai nuoseklus,
tie, kurie atitinka skaito.
Jei sakai, kad aš noriu galiausiai nuosekliai skaito,
galite nuostata 1000 RCU s, jūs ketinate
gauti 2,000 galiausiai nuosekliai skaito.
Ir pusė tiems kaina galiausiai susideda iš skaito.
>> Vėlgi, reguliuojamas nepriklausomai vienas nuo kito.
Ir jie turi throughput-- Jei suvartojama 100% savo NVP,
esate nesiruošia POVEIKIS Prieinamumas savo teises.
Taigi jie yra visiškai nepriklausomi vienas nuo kito.
Visos teisės, todėl vienas iš dalykų, kad Minėjau trumpai buvo pristabdyta.
Greičio yra blogai.
Greičio rodo blogai ne SQL.
Yra dalykų, mes galime padaryti, siekiant padėti Jums sumažinti droselio kad jus
patiriame.
Bet geriausias sprendimas yra tai, galime imtis
pažvelgti, ką jūs darote, nes ten anti-modelis žaisti čia.
>> Šie dalykai, dalykų, pavyzdžiui, ne uniforma darbo krūviai, karštieji klavišai, karšto pertvaros.
Aš pataikyti ypatingą pagrindinį erdvę labai sunku dėl kokios nors ypatingos priežasties.
Kodėl aš darau tai?
Leiskite suprasti, kad iš.
Aš maišymo Mano karštas duomenis šalto duomenis.
Aš nuomos Mano stalai gauti didžiulis, bet ten tikrai
tik kai kurie iš duomenų poaibis tai tikrai įdomu man.
Taigi, log duomenų, pavyzdžiui, daug klientai, jie gauna prisijunkite duomenis kiekvieną dieną.
Jie gavo didžiulę sumą žurnalo duomenis.
>> Jei jūs tik dempingo visą tą žurnalą duomenis į vieną didelį stalo, per tam tikrą laiką
Ši lentelė ketina gauti masyvi.
Bet aš tikrai domina tik paskutiniai 24 valandas per pastarąsias septynias dienas,
paskutinių 30 dienų.
Nepriklausomai nuo laiko langas kad aš domiuosi ieško
už įvykį, kad trukdo me, arba įvykis, įdomu man,
tai vienintelis langas laikas, kad man reikia.
Tad kodėl aš išleisti 10 metų Verta Rąstinių duomenų lentelėje?
Ką tai sukelia yra Lentelėje fragmentas.
>> Ji gauna milžiniškas.
Jis prasideda išskleidimas visoje tūkstančių mazgų.
Ir nuo jūsų pajėgumas yra toks mažas, jūs
iš tikrųjų, greitį ribojantis vienas nuo vienas iš tų atskirų mazgų.
Taigi pradėkime žiūri kaip mes įdiegti šią lentelę virš.
Kaip mes valdyti, kad duomenys šiek tiek geriau išvengti šių problemų.
Ir ką tai atrodo?
Tai, ką tai atrodo.
Tai yra tai, ką blogai NoSQL atrodo.
>> Gavau klavišų čia.
Jei pažvelgti į šoną čia visa tai yra mano pertvaros.
Aš turiu 16 pertvaros čia dėl šio konkretaus duomenų bazę.
Mes tai visą laiką.
Aš paleisti šio klientams visą laiką.
Tai vadinama šilumos žemėlapis.
Šilumos žemėlapis pasakoja man, kaip jūs gauti savo pagrindinį erdvę.
Ir ką tai sako man yra kad ten vienas pirma maišos
kad šis vaikinas sako, kad patinka siaubingai daug, nes jis
pataikyti ją tikrai, tikrai sunku.
>> Taigi mėlyna yra gražus.
Mums patinka mėlyna spalva.
Mums nepatinka raudona spalva.
Red kur slėgis gauna iki 100%.
100%, dabar jūs ketinate būti paminti.
Taigi, jei matote bet raudonąsias linijas, pavyzdžiui, this-- ir tai ne tik Dinamo DB--
kas NoSQL duomenų turi šią problemą.
Yra anti-modeliai, kurie gali vairuoti šias sąlygas tipus.
Kas man yra Dirbu su klientais sumažinti šias sąlygas.
>> Ir ką tai atrodo?
Ir tai vis labiausiai iš Dinamo DB pralaidumą,
bet tai tikrai gauti labiausiai iš NoSQL.
Tai ne tik Dynamo.
Tai definitely-- aš naudojami dirbti Mongo.
Aš esu susipažinęs su daugeliu NoSQL platformų.
Kiekvienas iš jų turi šių rūšių karšto pagrindinių problemų.
Norėdami gauti maksimalią naudą iš bet NoSQL duomenų, konkrečiai Dinamo DB
norite sukurti lenteles kur maišos pagrindinis elementas yra
daug skirtingų reikšmių, didelis galingumo.
Nes tai reiškia, kad aš rašau į daug įvairių kaušų.
>> Kuo daugiau kaušai aš raštu, tuo labiau tikėtina,
Esu skleisti tą rašymo apkrovos arba skaityti įkelti iš visoje kelių mazgų,
tuo labiau tikėtina, Esu turėti didelio našumo ant stalo.
Ir tada aš noriu vertybės turi būti paprašė gana tolygiai per tam tikrą laiką
ir vienodai, nes atsitiktinai, kaip įmanoma.
Na, tai kokios įdomios, nes aš tikrai negali
kontrolė, kai vartotojai ateiti.
Taigi pakanka pasakyti, jei mes skleisti viskas iš visos rakto erdvėje,
mes tikriausiai bus geresnės formos.
>> Yra tam tikras dydis pristatymo laiko
kad jūs nesiruošia , kad būtų galima kontroliuoti.
Tačiau tie, kurie tikrai du matmenys, kad mes turime,
vietos, prieigos tolygiai plitimą, laikas, prašymai
Pavėlavus tolygiai išdėstyti laike.
Ir jei tie du sąlygos yra įvykdytos,
tada tai, ką jis atrodys.
Tai daug gražiau.
Mes tikrai laimingas čia.
Mes turime labai net prieigos modelis.
Taip, gal jūs gaunate tiek spaudimo, kas dabar ir tada,
bet nieko tikrai per platus.
Taigi, tai nuostabu, kiek kartų, kai dirbu su klientais,
kad pirmasis grafikas su Big Red baras ir visi, kad negraži geltona tai
visur, mes gauti padaryti su pratybų
Po porą mėnesių pakartotinio architektūra,
jie veikia lygiai toks pats darbo krūvis per tą patį krovinį.
Ir tai, ką jis atrodo kaip dabar.
Taigi, ką jūs gaunate su NoSQL yra duomenų schemos, kuri yra absoliučiai
susieta su prieigos modelio.
>> Ir jūs galite optimizuoti, kad duomenų schema siekiant remti šį prieigos modelis.
Jei ne, tada jūs ketinate pamatyti tuos problemas rūšys
su tais karštieji klavišai.
>> Auditorija: Na, neišvengiamai keletas vietų ketinate būti šilčiau nei kiti.
>> RICK Houlihan: Visada.
Visada.
Taip, aš turiu galvoje, visada a-- ir vėl, ten
kai dizaino modelius mes gauti per kad kalbės apie tai, kaip jums susidoroti
su šiomis super didelių apibendrinimo.
Aš turiu galvoje, aš turiu juos, kaip mes su jais susidoroti?
Aš turiu labai gerą naudojimo atveju kad mes kalbame apie, kad.
>> Visos teisės, todėl pakalbėkime apie kai klientai dabar.
Šie vaikinai yra Adroll.
Aš nežinau, jei esate susipažinęs su Adroll.
Jūs tikriausiai pamatyti juos ant naršyklėje aikštelė.
Jie ad naujo nukreipimas, jie didžiausia skelbimą Re nukreipimą verslo
ten.
Jie paprastai reguliariai suvažinėti 60 milijardų sandorių per dieną.
Jie daro per milijoną Pirkimas per sekundę.
Jie gavo gana paprastą lentelę struktūra, judriausių stalo.
Tai iš esmės tik maišos raktas yra slapukas,
diapazonas yra demografinis kategorija, ir tada
trečiasis požymis yra rezultatas.
>> Taigi, mes visi turime slapukus Mūsų naršyklė iš šių vaikinai.
Ir kai jūs einate į dalyvauja pirklys,
jie iš esmės rezultatas jus per įvairūs demografiniai kategorijos.
Kai jūs einate į svetainę ir jūs sakote, aš noriu pamatyti šį ad--
arba iš esmės jūs neturite pasakyti that-- bet kai jūs einate į svetainę
jie sako norite matyti šį skelbimą.
Ir jie eikite gauti tą reklamą Adroll.
Adroll atrodo jus ant savo stalo.
Jie suprato, kad savo slapuką.
Reklamuotojai pasakojantys juos, aš noriu ką nors
kas vidutinio amžiaus, 40-metų vyras, į sportą.
Ir jie nesunkiai jus tose demografija ir jie sprendžia, ar ne
kad tai geras skelbimą Jums.
>> Dabar jie turi SLA su jų reklamos teikėjai
teikti subrangos 10 milisekundės atsakas į kiekvieną prašymą.
Taigi jie naudoja Dinamo DB už tai.
Jie pradeda mums milijonas per sekundę.
Jie gali padaryti visi jų paieška ", pagalbos pirmumo nustatymas visiems, kad duomenys,
ir gauti, kad pridėti nuorodą į tai reklamuotojas, pagal 10 milisekundžių.
Tai tikrai gana fenomenalus įgyvendinimas, kad jie turi.
>> Šie vaikinai actually-- Ar šie vaikinai.
Aš nesu įsitikinęs, jei tai šie vaikinai.
Gali būti šie vaikinai.
Iš esmės pasakė us-- ne, aš nemanau, kad tai buvo jų.
Manau, tai buvo kažkas.
Dirbau su klientų, kurie man pasakė,
kad dabar jie jau nuėjo į "Dinamo" DB, jie
išleidžia daugiau pinigų užkandžiai jų kūrimo komanda kiekvieną mėnesį
nei jie išleidžia savo duomenų bazę.
Taigi duosiu jums Idėja iš sutaupytų
kad jūs galite gauti Dinamo DB yra didžiulis.
Gerai, dropcam kita bendrovė.
Tai vaikinas natūra of--, jei jūs manote interneto dalykų, dropcam
iš esmės yra Internet Security vaizdo.
Jūs įdėti savo fotoaparatą ten.
Kamera turi judesio detektorius.
Kažkas ateina kartu, sukelia duotąja tašką.
Kamera pradeda įrašinėti, o iki jis neturi aptikti bet kokį judesį nebėra.
Pateikia kad vaizdo į internetą.
>> Dropcam buvo įmonė, kuri yra iš esmės perėjo į "Dinamo DB
nes jie buvo patirti milžiniški augimo skausmus.
Ir ką jie mums pasakė, staiga petabytes duomenų.
Jie neturėjo jokio supratimo, savo paslaugas būtų toks sėkmingas.
Daugiau atvykstamasis vaizdo nei "YouTube" yra tai, ką šie vaikinai gauti.
Jie naudoja DynamoDB sekti visus metaduomenis apie visus savo vaizdo pagrindinių punktų.
>> Taigi jie turi S3 kibirai jie stumti visi dvejetainiai artefaktai į.
Ir tada jie turi Dinamo DB įrašus,
žmonių atkreipti dėmesį į tuos S3 tris objektus.
Kai jiems reikia pažvelgti vaizdo, jie atrodo iki Dinamo DB rekordą.
Jie spustelėkite nuorodą.
Jie išgriauti video iš S3.
Taigi, kad tipo kas tai atrodo.
Ir tai yra tiesiai iš savo komanda.
>> Dinamo DB sumažina jų pristatymo laikas vaizdo renginių
nuo penkių iki 10 sekundžių.
Savo senosios reliacinės parduotuvėje, jie naudojami turite eiti ir vykdyti
daug sudėtingas užklausas išsiaiškinti iš kurios video traukti žemyn,
iki mažiau nei 50 milisekundžių.
Taigi, tai nuostabi, nuostabi kiek veiklos
Jūs galite gauti, kai jūs optimizuoti ir klausantis pagrindinės duomenų
remti prieigos modelis.
Halfbrick, šie vaikinai, kas tai yra, Vaisiai Ninja spėju yra jų dalykas.
Kad visi veikia Dinamo dB.
Ir šie vaikinai, jie yra puikus plėtros komanda, puikus plėtra
parduotuvė.
>> Nėra geras ops komanda.
Jie neturėjo daug Veiklos išteklius.
Jie buvo sunkiai bando išlaikyti jų taikymas infrastruktūra iki
ir veikia.
Jie atėjo pas mus.
Jie atrodė tuo Dinamo dB.
Jie sakė, kad tai už mus.
Jie pastatė visą jų taikymo pagrindas ant jo.
Tikrai gražus komentarų čia iš jų gebėjimo komanda
dabar sutelkti dėmesį į pastato žaidimas, o ne
turintys išlaikyti infrastruktūros, kuri
buvo tapti milžiniška suma važtaraščius jų komanda.
Taigi tai yra kažkas that-- naudos, kad jūs gaunate iš "Dinamo" DB.
>> Gerai, patekti į duomenų modeliavimo čia.
Ir mes kalbėjomės apie mažai tai vienas prie vieno, vienas daug,
ir daug daug tipo santykius.
Ir kaip jums išlaikyti tuos Dynamo.
Dinamo DB mes naudojame indeksai, apskritai kalbant,
pasukti duomenis iš vienas skonio į kitą.
Hash raktai, klasės klavišai ir indeksai.
>> Šiuo konkrečiu Pavyzdžiui, daugelyje valstybių
turėti licencijavimo reikalavimas, kad Tik vienas vairuotojo pažymėjimas vienam asmeniui.
Jūs negalite eiti, kad gauti du vairuotojo licencijas Bostono narėje.
Aš negaliu padaryti Teksase.
Tai tipo kaip ji yra.
Ir būdamas DMV, turime paieška ", mes norite ieškoti vairuotojo pažymėjimą
pagal socialinio draudimo numerį.
Noriu ieškoti naudotojo duomenis Iki vairuotojo licencijos numeris.
>> Taigi, mes galime turėti vartotojo anketa lentelę, turi maišos klavišą serijos numerį,
arba socialinio draudimo numeris, ir įvairūs atributai apibrėžta ant elemento.
Dabar tos lentelės I gali apibrėžti GSI, kad
salto, kad aplink, kad sako noriu maišos klavišą ant licencijos ir tada
visi kiti daiktai.
Dabar, jei aš noriu užklausą ir rasti licencijos numeris bet kokiam teikti socialinę
Draudimo numeris, galiu užklausti pagrindinę lentelę.
>> Jei aš noriu užklausti, ir aš noriu gauti socialinę apsaugą
numeris arba kitus atributus pagal licencijos numeris, galiu užklausti GSI.
Tai modelis, kad vienas į vieną santykius.
Tiesiog labai paprastas GSI, apversti tuos dalykus aplink.
Dabar kalbame apie vieną, kad daugelis.
Vienas su daugeliu iš esmės yra Jūsų maišos asortimentas raktas.
Kur mes gauti daug su šia naudojimo atveju yra stebėti duomenis.
Monitorius duomenys ateina reguliariai intervalas, pavyzdžiui, daiktų interneto.
Mes visada gausite visa tai įrašų ateina visą laiką.
>> Ir aš noriu surasti visus rodmenis tarp tam tikrą laikotarpį.
Tai labai dažna užklausą stebėsenos infrastruktūrą.
Būdas eiti apie tai rasti paprasta lentelės struktūrą, vienas stalas.
Aš turiu prietaiso matavimų lentelę su grotelėmis raktu ant prietaiso ID.
Ir aš turiu range klavišą timestamp, ar šiuo atveju, epas.
Ir tai leidžia man atlikti kompleksą užklausas, kad svyruoja raktą
ir grąžinti tuos įrašus, kad yra santykinės rezultato
nustatyti, kad aš ieškojau.
Ir tai stato, kad vienas į daugelį santykių
į pirminę lentelės naudojant tiesiogiai maišos raktas, raktas asortimentas struktūra.
>> Taigi, kad tipo pastatytas į "Dinamo" DB lentelėje.
Kai aš apibrėžti maišos ir asortimentas T stalo, aš
apibrėžti vieną daugeliui santykius.
Tai tėvų ir vaikų santykiai.
>> Pakalbėkime apie daug daug santykius.
Ir šiuo konkrečiu pavyzdžiui, vėl, mes ketiname naudoti GSI-aisiais.
Ir pakalbėkime apie žaidimų scenarijus, kai turiu tam tikrą vartotoją.
Noriu išsiaiškinti visus žaidimus, jis registruotas, arba žaisti.
Ir už tam tikrą žaidimą, aš nori surasti visus vartotojus.
Taigi, kaip man tai padaryti?
Mano vartotojo žaidimai stalo, aš ruošiuosi turėti maišos raktą vartotojo ID
ir asortimentas raktas į žaidimą.
>> Taigi vartotojas gali turėti kelis žaidimus.
Tai vienas į daugelį santykių vartotojas ir žaidimai groja.
Ir tada ant GSI, Aš apversti, kad aplink.
Aš maišos ant žaidimo ir Aš svyruoja nuo vartotojo.
Taigi, jei aš noriu gauti visi žaidimas vartotojo anketa žaisti,
Aš užklausą pagrindinę lentelę.
Jei aš noriu gauti visus vartotojus kurie vaidina ypatingą žaidimą,
Aš užklausą GSI.
Taigi, kaip matote, kaip mes tai darome?
Jūs pastatyti šie GSI s remti naudojimo atveju, prašymas, prieigos
modelis, prašymas.
>> Jei man reikia užklausti apie Šis matmuo, tegul
man sukurti apie tą aspektą indeksą.
Jei aš ne, man tai nerūpi.
Ir, priklausomai nuo panaudojimo atveju, aš gali prireikti indeksą ar man gali nebūti.
Jei tai paprasta daug, pirminė lentelė yra gerai.
Jei man reikia padaryti tai daugelis daug s, arba man reikia padaryti vieną į tuos,
tada gal man tikrai reikia antrosios indeksas.
Taigi viskas priklauso nuo ką aš bandau padaryti
ir ką aš bandau gauti vykdymą.
>> Tikriausiai aš nesiruošia praleisti per kiek laiko kalbėti apie dokumentus.
Tai pasireiškia šiek tiek, turbūt, giliau nei mums reikia eiti į.
Pakalbėkime šiek tiek apie turtingą užklausos išraiška.
Taigi Dinamo DB turime gebėjimas sukurti
ką mes vadiname projektavimo išraiškas.
Projekciniai išraiškos yra tiesiog skinti laukus ar vertybes
kad norite rodyti.
Gerai, kad aš padaryti pasirinkimą.
Aš padaryti prieš Dinamo DB užklausą.
Ir aš sakau, jūs žinote, ką, rodyti man tik penkių žvaigždučių atsiliepimai
šiuo konkrečiu produktu.
Taigi, kad viskas, ką aš noriu pamatyti.
Aš nenoriu matyti visi kiti atributai eilės,
Aš tik noriu pamatyti tai.
Tai kaip SQL, kai jūs sako pasirinkite žvaigždę arba stalo,
gausite viską.
Kai aš sakau, pasirinkite vardą iš stalo, aš tik gauti vieną atributą.
Tai tos pačios rūšies dalykas Dinamo dB ar dar NoSQL duomenų bazės.
Filtruoti posakiai leisti man iš esmės sumažinti rezultatą išlaipinti.
Taigi, aš padaryti užklausą.
Užklausa gali grįžti su 500 daiktų.
Bet aš tik noriu elementus, turi atributą, kuris sako tai.
Gerai, kad galime filtruoti tuos elementus kad nesutampa, kad ypač užklausą.
Taigi, mes turime filtro išraiškas.
>> Filtruoti išraiškos būti paleisti bet atributas.
Jie nemėgsta nuotolio užklausas.
Pakelkite užklausos daugiau selektyvus.
Filtruoti užklausos reikalauja mane eiti Gaukite visą rezultatai nustatyti ir tada
nesivadovauti duomenis nenoriu.
Kodėl tai svarbu?
Nes aš visa tai skaityti.
Į užklausą, aš ruošiuosi skaityti ir tai bus milžiniškas apie duomenis.
Ir tada aš ruošiuosi nesivadovauti, ko man reikia.
Ir jei aš tik išskirti pora eilučių, tada, kad viskas OK.
Tai nėra taip neefektyvu.
>> Bet jei aš skaitau visa krūva duomenys, tiesiog nesivadovauti vieną elementą,
tada aš ruošiuosi būti geriau išjungti naudojant spektrą užklausą
nes tai daug daugiau selektyvus.
Jis ketina išsaugoti man daug pinigų, nes aš mokėti už tą skaityti.
Jeigu rezultatai, kad grįžta kirsti tą laidą gali būti mažesnis,
bet aš mokėti už skaityti.
Taigi suprasti, kaip jūs gaunate duomenis.
Tai labai svarbu Dinamo dB.
>> Sąlyginis išraiška, tai yra tai, ką galite skambinti optimistiškai užblokavimo.
Atnaujinti JEI egzistuoja, arba jei šios vertės yra lygiavertė tai, ką galiu nurodyti.
Ir jei turiu laiko spaudą įrašo, galiu skaityti duomenis.
Galėčiau pakeisti, kad duomenis.
Galėčiau eiti parašyti, kad duomenis į duomenų bazę.
Jei kas nors pasikeitė įrašą, laiko žyma gali būti pasikeitę.
Ir kad taip mano sąlyga atnaujinimas, galima sakyti atnaujinimas
jei timestamp lygi tai.
Arba atnaujinimas žlugs, nes kažkam atnaujino Tuo tarpu rekordą.
>> Štai ką mes vadiname optimistiškai užblokavimo.
Tai reiškia, kad kažkas gali ateiti ir jį pakeisti,
ir aš ruošiuosi aptikti jį kai aš grįžti rašyti.
Ir tada aš iš tikrųjų gali skaityti, kad duomenys ir sako, oi, jis pakeitė tai.
Man reikia atsiskaityti už tai.
Ir aš galiu pakeisti duomenis Mano įrašyti ir taikyti kitą naujinimą.
Taigi jūs galite sugauti tuos pažangus atnaujinimai, kurie atsiranda nuo to momento,
kad jūs skaityti duomenis ir laikas jums gali rašyti duomenis.
>> Auditorija: Ir filtras išraiška iš tikrųjų reiškia ne
numerį arba not--
>> [Tarpines BALSAS]
RICK Houlihan: aš ne gauti per daug į tai.
Tai saugomos raktinį žodį.
Svaras vaizdas yra saugomos raktinį žodį "Dinamo" DB.
Kiekvienas duomenų turi savo saugomos pavadinimai kolekcijų jūs negalite naudoti.
Dinamo DB, jei nurodysite yra vienas priešais šį svaras,
galite nustatyti tuos pavadinimus iki viršaus.
Tai yra nurodoma vertė.
Tai tikriausiai ne geriausias sintaksė turėti iki ten šią diskusiją,
nes jis gauna į kai real-- Norėčiau buvo kalbama daugiau
apie tai ne gilesniame lygmenyje.
>> Tačiau pakanka pasakyti, tai gali būti užklausa nuskaityti kur jie views--
nei svaras peržiūros yra didesnis nei 10.
Tai yra skaitmeninė vertė, taip.
Jei norite, mes galime kalbėti apie kad po diskusijų.
Visos teisės, todėl mes vis į Kai kurie geriausios praktikos scenarijai
kur mes ketiname kalbėti apie kai kurias programas čia.
Kokie naudojimo atvejai Dynamo dB.
Kas yra dizainas modeliai Dinamo dB.
>> Ir pirmasis mes ketiname kalbėti apie tai, ko internete.
Taigi mes gauname daug of-- Spėju, kas it-- daugiau nei 50%
eismo internete šių dienų iš tikrųjų sukuriama mašinos,
automatiniai procesai, o ne žmonėms.
Aš turiu galvoje tai, ką šis dalykas, kad Jums nešiotis kišenėje,
kiek duomenų, kad šis dalykas yra iš tikrųjų siunčiant aplink be tavęs
žinant tai yra absoliučiai nuostabios.
Jūsų vieta, informacija apie tai, kaip greitai jūs einate.
Kaip manote, Google Maps darbus kai jie pasakys, ką eismas yra.
Tai todėl, kad yra milijonai ir milijonai žmonių važinėjantis
su telefonais kurie yra siunčiančiosios duomenys visame vietoje visą laiką.
Taigi, viena iš ko apie šį duomenų tipą
kuris ateina, stebėti duomenų, prisijunkite duomenys, laiko eilučių duomenų, tai yra
paprastai tik įdomu už šiek tiek laiko.
Po to laiko, tai ne taip įdomu.
Taigi, mes kalbėjome apie, neleiskite tas lenteles augti be ribų.
Idėja yra tai, kad gal aš turiu 24 valandos verta įvykių mano karšto lentelėje.
Ir tai karšta lentelė bus numatęs labai dideliu greičiu,
nes jis, atsižvelgiant daug duomenų.
Tai atsižvelgiant daug duomenų ir aš jį skaityti daug.
Aš turiu eksploatavimo daug užklausos veikia nuo šių duomenų.
>> Po 24 valandų, ei, jūs žinoti, kas, man tai nerūpi.
Taigi gal kas vidurnakčio Aš ritinys mano stalo perkelti į naują lentelę
ir aš deprovision šią lentelę.
Ir Imsiu RCU "ir WCU anketa žemyn, nes po 24 valandų
Nesu veikia kaip daugelis užklausas šių duomenų.
Taigi, aš ruošiuosi sutaupyti pinigų.
O gal 30 dienų, aš ne net nereikia rūpintis visa tai.
Galėčiau imtis WCU s visą kelią žemyn į vieną,
nes jūs žinote, ką tai niekada gauti parašyta.
Duomenys yra 30 dienų.
Jis niekada nesikeičia.
>> Ir tai beveik niekada ketinate gauti skaityti, tad tiesiog imtis, kad NVP iki 10.
Ir aš sutaupyti pinigų ton apie tai duomenys, ir tik mokėti už mano karšto duomenis.
Taigi, kad svarbiausia ieškoti ne, kai jūs pažvelgti laiko eilučių
duomenys ateina apimtis.
Tai yra strategijos.
Dabar, galėčiau tiesiog leiskite ją visi eiti į tą pačią lentelę
ir leiskite, kad stalo augti.
Galų gale, aš ruošiuosi matyti našumo problemas.
Aš ruošiuosi pradėti archyvas kai kurie iš minėtų duomenų išjungimo stalo,
kas ne.
>> Leiskite daug geriau dizainas jūsų prašymą
taip, kad jūs galite valdyti šį kelią dešinėje.
Taigi tai tik automatinė paraiškos kodą.
Vidurnaktį kiekvieną naktį jis ritininis stalą.
Gal ko man reikia yra stumdomas langas 24 valandas nuo duomenų.
Tada reguliariai Aš paskambinę duomenis nuo stalo.
Aš apkarpymas su Cron ir aš pradėti jį
ant šių kitų lentelių, ką reikia.
Taigi, jei virtimo veikia, tai puiku.
Jei ne, apdaila ją.
Bet tegul laikyti, kad karšto duomenis nuo savo šalto duomenis.
Tai bus jums sutaupyti daug pinigų ir Padarykite savo lenteles daugiau našumą.
Taigi kitas dalykas mes kalbame apie tai, produktų katalogas.
Prekių katalogas yra gana bendro naudojimo atveju.
Tai iš tikrųjų labai dažnas modelis kad mes matome įvairių dalykų.
Žinote, Twitter Pavyzdžiui, karšto Čivināšana.
Kiekvienas ateina ir greiferiniai kad Čivināšana.
Prekių katalogas, aš turiu parduoti.
Gavau karštą pardavimą.
Gavau 70.000 prašymus per Antrasis ateina produkto
Aprašymas iš mano produktų katalogą.
Mes tai matome mažmeninės operacija gana šiek tiek.
Taigi, kaip mes susidoroti su tuo?
Nėra būdas kovoti su tuo.
Visi mano vartotojai nori pamatyti tas pats gabalas duomenimis.
Jie ateina iš, kartu.
Ir jie visi padaryti prašymus už tą patį gabalas duomenimis.
Tai suteikia man, kad karšto klavišą, kad didelis raudonas juostele ant mano diagramą, kad mums nepatinka.
Ir tai, kas, kad atrodo.
Taigi per mano pagrindinis erdvėje gaunu įkalama į pardavimo daiktais.
Gaunu nieko niekur kitur.
>> Kaip man sumažinti šią problemą?
Na, mes sumažinti tai su talpyklą.
Cache, jūs įtraukėte esmės in-atminties pertvarų priešais duomenų bazėje.
Mums pavyko [Nesigirdi] talpyklą, kaip jūs
galite sukurti savo talpyklą, [nesigirdi] talpyklos [? D,?] ką nori.
Įdėti, kad priešais duomenų bazėje.
Ir tokiu būdu jūs galite laikyti, kad duomenys iš tų karštų klavišų iki toje talpyklos
erdvė ir skaityti per talpyklą.
>> Ir tada dauguma jūsų skaito pradėti ieškoti, kaip šis.
Aš turiu visa tai talpyklos hitai čia ir aš nieko vyksta žemyn čia
nes duomenų sėdi atsilieka nuo talpyklos ir skaito niekada ateiti per.
Jei aš pakeisti duomenų duomenų, turiu atnaujinti talpyklą.
Mes galime naudoti kažką kaip Garų tai padaryti.
Ir aš paaiškinti, kaip tai veikia.
Gerai, pranešimų.
Paštas, mes visi naudotis elektroniniu paštu.
>> Tai gana geras pavyzdys.
Mes turime tam tikrą pranešimų stalo rūšiuoti.
Ir mes turime "Gautieji" ir katalogą Siunčiamieji.
Tai yra tai, ką SQL būtų atrodyti statyti tą dėžutę.
Mes rūšies naudoti tos pačios rūšies strategiją naudoti GSI-ųjų GSI s
mano pašto dėžutę ir mano Siunčiami.
Taigi gavau žaliavos pranešimai ateina į mano messages stalo.
Ir pirmasis požiūris į tai gali būti, tarkim, gerai, jokių problemų.
Aš turiu žaliavų pranešimus.
Pranešimus, gaunamus [nesigirdi] žinutė ID, tai puiku.
Štai mano unikalus maišos.
Aš ruošiuosi sukurti du GSI s, vieną mano pašto dėžutę, vienas mano Siunčiami.
Ir aš pirmas dalykas, tai padaryti yra pasakysiu mano maišos raktas
bus gavėjas ir Aš ruošiuosi organizuoti ant datos.
Tai fantastinis.
Aš gavau mano gražus vaizdas čia.
Bet yra šiek tiek klausimas čia.
Ir jūs paleisti į tai reliacinių duomenų bazių, taip pat.
Jie paragino vertikaliai atitvarų.
Jūs norite, kad jūsų didelis duomenis nuo jūsų mažai duomenų.
>> Ir priežastis, kodėl, nes aš turiu eiti skaityti elementus gauti atributus.
Ir jei mano organai yra viskas čia tada skaityti tik keli daiktai
jei mano kūnas ilgis yra vidutiniškai 256 kilobaitų kas,
matematika gauna gana negraži.
Taigi pasakyti, kad aš noriu skaityti Dovydo dėžutę.
Dovydo Gautieji yra 50 elementai.
Vidutinis ir dydis yra 256 kilobaitų.
Štai mano konvertavimo santykis už RCU s yra keturi kilobaitų.
>> Gerai, eikime su galiausiai nuosekliai skaito.
Aš vis dar valgo 1600 RCU s tik skaityti Dovydo dėžutę.
Ouch.
Gerai, dabar pagalvokime apie tai, kaip programa veikia.
Jei aš elektroninio pašto programą ir Žiūriu mano pašto dėžutę,
ir aš pažvelgti į kiekvieną pranešimą, kūno, Ne, aš žiūriu santraukos.
Žiūriu tik antraštėse.
Taigi leiskite sukurti lentelės struktūrą kad atrodo labiau patinka.
>> Taigi čia informacija kad mano darbo eigos poreikius.
Tai mano pašto dėžutę GSI.
Tai data, siuntėjas, objektas, ir tada
pranešimas ID, kuris nurodo Atgal į pranešimus stalo
kur galiu gauti kūną.
Na, tai būtų įrašyti idėjas.
Jie norėtų atkreipti atgal į punktas ID dėl Dinamo DB lentelėje.
Kiekvienas puslapis visada creates-- visada turi elementą
ID numeris dalis of-- kad ateina su indeksu.
>> Gerai.
Auditorija: Jis pasakoja, jeigu jis saugomas?
RICK Houlihan: Taip, tai pasako exactly-- tai, ką jis daro.
Ji sako čia mano naujo įrašo.
Ir jis bus nukreipti jį atgal į savo naujo įrašo.
Būtent.
Gerai, kad dabar mano pašto dėžutė iš tikrųjų daug mažesnis.
Ir tai iš tikrųjų palaiko elektroninio pašto app eiga.
Taigi mano pašto dėžutę, aš spustelėkite.
Aš einu kartu ir aš spustelėkite pranešimą, tai kai man reikia eiti gauti kūną,
nes aš ruošiuosi pereiti prie kitokios nuomonės.
Taigi, jei jūs manote apie MVC tipą sistema, modelis vaizdas valdiklis.
>> Šis modelis būtų pateikiama duomenų, kad peržiūrėti poreikiai
ir kontroleris bendrauja su.
Kai aš pakeisti rėmo kai Pakeisti perspektyvą,
viskas OK, jei norite grįžti į serveris ir repopulate modelį,
nes tai, ką vartotojas tikisi.
Kai jie pakeisti požiūrį, kad, kai galime grįžti prie duomenų bazės.
Taigi siųsti, paspauskite.
Aš ieškau kūno.
Jei kūdikiui kelionės.
Grįžti gauti kūną.
>> Aš perskaičiau daug mažiau duomenų.
Aš tik skaityti įstaigas, Davidas reikia, kai jis turi juos.
Ir aš nedegina 1600 RCU tiesiog parodyti savo dėžutę.
Taigi dabar that-- tai yra būdas kad LSI arba GSI-- aš atsiprašau,
GSI, būtų dirbti.
Mes turime mūsų maišos gavėjui.
Mes turime spektrą klavišą dienos.
Ir mes turime numatomus atributus kad mums reikia tik patvirtina nuomonę.
>> Mes pasukti, kad už Siunčiami.
Hash nuo siuntėjo.
Ir iš esmės, mes turime labai gražus, švarus vaizdas.
Ir tai basically-- mes turi šį gražus pranešimus
stalo, kad manimi skleidžiamas gražiai, nes tai maišos tik sumaišomas žinutė ID.
Ir mes turime du indeksus, kad sukasi ne iš tos lentelės.
Visos teisės, todėl idėja čia yra ne išlaikyti didelius duomenis ir šį nedidelį duomenis
kartu.
Pasiskirstymo vertikaliai, padalyti šias lenteles.
Negalima skaityti duomenis jūs neturite.
Gerai, žaidimų.
Mes visi norėtume žaidimai.
Bent jau aš norėčiau žaidimai tada.
Taigi keletas dalykų kad mes dirbame su kai
mes galvoti apie žaidimų, tiesa?
Žaidimų šių dienų, ypač mobiliųjų Žaidimų, yra visa informacija apie mąstymą.
Ir aš ruošiuosi sukti Čia Šiek tiek atokiau nuo DynamoDB.
Aš ruošiuosi atnešti kai diskusijos
aplink vieni iš kiti AWS technologijos.
>> Bet apie žaidimų idėja yra galvoti apie pagal API API, kurie,
apskritai kalbant, HTTP ir JSON.
Tai kaip mobiliųjų žaidimų natūra bendrauti su savo užpakalinių galų.
Jie JSON komandiravimo.
Jie gauna duomenis, ir viskas, Apskritai kalbant, gražus JSON API.
>> Dalykų, pavyzdžiui, gauti draugų, gauti Iškabos, keistis duomenimis,
vartotojų kuriamo turinio, stumti atgal iki sistemos,
tai tipų dalykų kad mes ketiname daryti.
Dvejetainiai turto duomenys, šie duomenys gali ne sėdėti duomenų bazę.
Tai gali sėdėti objektas parduotuvė, tiesa?
Bet duomenų bazė ketina galų gale pasako sistemai,
sakau paraišką kur eiti jį gauti.
Ir neišvengiamai Multiplayer serveriai, atgal pabaigoje infrastruktūra,
ir skirtas aukštos prieinamumas ir mastelio.
Taigi tai yra tai, kas mes visi norime į žaidimų infrastruktūros šiandien.
>> Taigi leiskite pažvelgti ką tai atrodo.
Turite pagrindinę atgal pabaigoje, labai paprasta.
Mes turime sistemą, čia su kelis prieinamumas zonose.
Mes kalbėjome apie AZS kaip being-- manote iš jų, kaip atskirų duomenų centruose.
Daugiau nei vienas duomenų centras už AZ, bet tai gerai,
tiesiog galvoti apie juos kaip atskirą duomenų centrai, kurie yra geografiškai
ir gedimų izoliuota.
>> Mes ketiname turėti pora EC2 atvejų.
Mes ketiname turėti kai atgal end serveris.
Galbūt, jei esate palikimas architektūra, mes
naudojant, ką mes vadiname RDS, reliacinės duomenų bazės paslaugos.
Galėtų būti MSSQL, MySQL, ar kažkas panašaus.
Tai būdas daug paraiškų yra skirtos šiandien.
>> Na mes galbūt norėsite eiti su tai kai mes mastelį iš.
Mes eiti į priekį ir padėkite S3 kibiras ten.
Ir tai S3 kibiras, o ne tarnauja iki šių objektų iš mūsų servers--
mes galime padaryti, kad.
Jūs įdėti visą savo dvejetainis objektus į savo serverius
ir jūs galite naudoti šiuos serverį atvejų tarnauti, kad duomenų aukštyn.
Bet tai gana brangu.
>> Geriau būdas tai padaryti yra eiti į priekį ir įdėti tuos objektus į S3 kibirą.
S3 objektas saugyklos.
Jis pastatytas specialiai tarnauja iki šių dalykų tipus.
Ir tegul tie klientai prašyti tiesiogiai iš šių objektų kibirai,
iškrauti serverius.
Taigi mes pradedame mastelį čia.
>> Dabar mes turime vartotojams visame pasaulyje.
Gavau vartotojams.
Man reikia turėti turinį vietoje netoli šių vartotojų, tiesa?
Aš sukūriau S3 kibirą kaip mano kodo saugyklą.
Ir aš priekyje, kad su CloudFront platinimas.
>> CloudFront yra CD ir turinio pristatymo tinklo.
Iš esmės ji mano duomenis, kad jums nurodyti ir išsaugo ją visame internete
todėl vartotojai gali turėti visur labai greitai reaguoti, kai
jie prašo tuos objektus.
>> Taigi jūs gaunate idėja.
Jūs esate rūšies sverto visi aspektai AWS čia Norėdami gauti šią padaryta.
Ir, galų gale, mes išmetame į auto skalių grupei.
Taigi mūsų AC2 atvejais mūsų žaidimų serverių,
kaip jie pradeda gauti užsiėmęs ir užsiėmęs ir užsiėmęs,
jie bus tiesiog nugara kitą pavyzdžiui, nugara kitą atvejį,
nugara kitą atvejį.
Taigi technologiją AWS turi, tai Leidžia nustatyti parametrus
aplink kurį jūsų serveriai bus augti.
Taigi jūs galite turėti n skaičių serveriuose ten bet kuriuo metu.
Ir jei jūsų apkrovos nueina, jie trauktis, skaičius mažės.
Ir jei apkrovos grįžta, jis bus atauga iš, elastingai.
>> Taigi, tai atrodo puikiai.
Mes gavome EC2 atvejais daug.
Mes galime įdėti talpyklos Priešais duomenų bazių,
pabandyti ir pagreitinti duomenų bazes.
Kitas spaudimo taškas paprastai žmonės mato
yra jie masto žaidimą naudojant reliacinės duomenų bazės sistema.
Pas duomenų bazė veikimas yra baisi.
Kaip mes pagerinti, kad?
Pabandykime išleidimą talpyklos priešais, kad.
>> Na, talpyklos neveikia toks didelis žaidimų, tiesa?
Žaidimų, rašymas yra skausminga.
Žaidimai yra labai rašyti sunkus.
Laikinoji neveikia, kai esate rašyti sunki, nes jūs visada
turiu atnaujinti talpyklą.
Jūs atnaujinti talpyklą, tai nesvarbus būti spartinimo.
Tai iš tikrųjų tik papildomas darbas.
>> Taigi, kur mes einame čia?
Jūs turite didelį butelio ten į duomenų bazę.
Ir kur eiti akivaizdžiai yra atitvarų.
Pertvara yra ne lengva padaryti, kai esate
susiduriame su reliacinių duomenų bazių.
Su reliacinių duomenų bazių, jūs atsakinga už, efektyviai,
pagrindinis plotas.
Jūs sakote vartotojams tarp A ir M eikite čia, tarp N ir Z ten.
Ir jūs perjungimo visoje paraiškoje.
Taigi jūs susiduriame su šiame skirsnyje duomenų šaltinis.
Turite sudaryti sandorį apribojimus kad ne span skirsnius.
Jūs turite visų rūšių Bałaganienie, kad esate
bendraujant su ten bando susidoroti su mastelio dėmesį
ir kurti didesnę infrastruktūrą.
Tai tiesiog nėra įdomus.
>> Auditorija: Taigi tu sakai, kad padidinti šaltinio taškų pagreitina
procesas?
RICK Houlihan: Didinti?
Auditorija: Source taškai.
RICK Houlihan: Source taškai?
Auditorija: Nuo informacijos kur informacija yra iš?
RICK Houlihan: Ne
Ką aš sakau, didinant skaičius pertvaromis į duomenų saugykloje
pagerina pralaidumą.
Taigi, kas vyksta čia yra vartotojai ateina į EC2 pavyzdžiui čia,
Na, jei man reikia vartotoją tai A iki M, aš eisiu čia.
Iš N P, aš eisiu čia.
Iš P Z, aš eisiu čia.
>> Auditorija: Gerai, tie taip tie, kurie visi saugomi skirtingose ​​mazgų?
>> RICK Houlihan: Taip.
Pagalvokite apie tai, kaip skirtingų bunkeriai duomenų.
Taigi jūs, turintys tai padaryti.
Jei bandote padaryti tai, jei jūs bandote
mastelį ant reliacinės platforma, Tai yra tai, ką jūs darote.
Jūs vartojate duomenis ir jūs sumažinate jį žemyn.
Ir jūs atitvarų jį per keli atvejai duomenų bazę.
Ir jūs valdyti visa tai klijavimo pakopos.
Tai nėra smagu.
Taigi, ką mes norime eiti?
Mes norime eiti DynamoDB, pilnai valdomas, NoSQL duomenų saugyklos, nuostata pralaidumas.
Mes naudojame antrinių indeksus.
Tai iš esmės HTTP API ir apima dokumento paramą.
Taigi jūs neturite jaudintis apie bet kokius šio padalijimo.
Mes visa tai už jus.
Taigi dabar, vietoj to, galite tiesiog parašyti į lentelę.
Jei lentelėje turi būti padalintas, tai atsitiks užkulisiuose.
Jūs esate visiškai izoliuotas nuo kaip kūrėjas.
Taigi pakalbėkime apie kai naudojimo atvejais
kad mes paleisti į lošimo, bendra žaidimų scenarijai, Iškabos.
Taigi, jūs turite vartotojai ateina, kad BoardNames, kad jie
ant, už šį klientą balai.
Mes galime būti maišos ant UserId, ir tada mes turime įvairių apie žaidimą.
Taigi kiekvienas vartotojas nori pamatyti visi žaidimas jis grojo
ir visi jo geriausias rezultatas visose žaidimo.
Taigi, kad jo asmens Iškabos.
>> Dabar aš noriu eiti, ir aš noriu get-- todėl aš gauti šiuos asmens Lyderių.
Ką aš noriu padaryti, tai eikite gauti top rezultatas visiems vartotojams.
Taigi, kaip man tai padaryti?
Kai mano įrašas yra sumaišomas su userid, svyravo nuo žaidimo,
gerai aš ruošiuosi eiti į priekį ir restruktūrizuoti, sukurti GSI,
ir aš ruošiuosi pertvarkyti, kad duomenis.
>> Dabar aš ruošiuosi maišos ant BoardName, kuri yra žaidimas.
Ir aš ruošiuosi svyruoja ant viršaus rezultatą.
Ir dabar aš sukūriau skirtingus kibirus.
Aš naudoju tą patį stalą, to paties objekto duomenų.
Bet aš sukurti kibirą, kuris suteikia man aukščiausios rezultatas agregaciją žaidimą.
>> Ir aš galiu užklausti šią lentelę gauti šią informaciją.
Taigi aš nustatyti, kad užklausos modelio iki būti palaikoma antrinio indekso.
Dabar jie gali būti rūšiuojami pagal BoardName ir rūšiuojami pagal geriausias rezultatas, priklausomai nuo.
Taigi matote, tai yra rūšys naudojimo atvejais jūs gaunate žaidimų.
Dar viena gera naudojimo atveju mes gauname iš žaidimų yra apdovanojimai ir kas laimėjo apdovanojimus.
Ir tai yra puiki naudojimo atveju kur mes vadiname retus indeksus.
Sparse indeksai yra Gebėjimas generuoti
indeksas, kad nebūtinai būti kiekvieną elementą ant stalo.
Ir kodėl gi ne?
Kadangi atributas, kad manimi yra indeksuotą neegzistuoja kiekvieną elementą.
>> Taigi, šis konkretus naudojimo atveju, aš sakau,
jūs žinote, ką aš ruošiuosi sukurti atributas vadinamas apdovanojimas.
Ir aš ruošiuosi duoti kiekvienam vartotojui kad turi apdovanojimą, kad atributas.
Vartotojai, kurie neturi apdovanojimai nesiruošia turėti, kad atributas.
Taigi, kai aš sukurti indeksas, tik vartotojai
kad ketiname parodyti iki indekse yra
tie, kurie iš tikrųjų turi laimėjo apdovanojimus.
Štai puikus būdas, kad būtų galima sukurti filtruojami indeksus, kad
yra labai, labai selektyvus, kad ne turi indeksuoti visą lentelę.
>> Taigi mes vis mažai laiko čia.
Aš ruošiuosi eiti į priekį ir praleisti , ir praleisti šį scenarijų.
Kalbėti šiek tiek about--
>> Auditorija: Ar galiu paklausti, greitai klausimą?
Vienas iš jų yra parašyti sunki?
RICK Houlihan: Kas yra?
Auditorija: Rašyti sunkus.
RICK Houlihan: Rašyti sunkus.
Leisk pažiūrėti.
>> Auditorija: ar tai, kad nėra ką jūs galite tiesiog
balsas per kelias sekundes klausimu?
RICK Houlihan: Mes einame per balsavimo scenarijų.
Tai nereiškia, kad blogai.
Ar vaikinai turi keletą minučių?
GERAI.
>> Taigi mes kalbame apie balsavimo.
Taigi realaus laiko balsavimo, mes turime reikalavimai balsavimo.
Reikalavimai yra tai, kad mes leidžiame kiekvienas asmuo balsuoti tik vieną kartą.
Mes norime, kad niekas, kad būtų galima pakeisti savo balsą.
Mes norime, kad realaus laiko agregaciją ir analitikai demografija
kad mes ketiname būti rodo, kad vartotojams svetainėje.
>> Pagalvokite apie šį scenarijų.
Mes dirbame realybės daug TV šou, kur jie
daro šias tikslaus tipo dalykų.
Taigi jūs galite galvoti scenarijų, mes turime milijonus
iš paauglės ten su savo mobiliuosius telefonus
ir balsuoti, ir balsuoti, ir balsuosiu už tas, kas jie yra
rasti labiausiai populiarus.
Taigi jie yra vieni iš reikalavimai mes baigsis.
>> Ir taip pirmasis imtis sprendžiant šią problemą
būtų pastatyti labai paprasta programa.
Taigi aš turiu šią programą.
Turiu kai kurių rinkėjų ten.
Jie būna, jie nukentėjo balsavimo programą.
Aš turiu šiek tiek žalio balsų lentelę Aš tiesiog iškelties tuos balsus į.
Aš turiu šiek tiek agregatas balsų stalas,
darysiu Analytics ir demografija, ir mes įdėti visa tai ten.
>> Ir tai yra didelis.
Gyvenimas yra geras.
Gyvenimas geras, kol randame, kad visada tik vienas ar du
žmonės, kurie populiarūs rinkimus.
Yra tik vienas ar du dalykai kad žmonės tikrai rūpi.
Ir jei jūs balsuodamas masto, visi staiga aš
bus kala pragarą iš du kandidatai, vienas arba du kandidatų.
Labai nedaug daiktų žmonių mano, kad būtų populiarus.
>> Tai nėra geras dizainas modelis.
Tai iš tikrųjų labai blogas dizainas modelis
nes ji sukuria būtent tai, ko mes kalbėjo apie kurį buvo karštieji klavišai.
Klavi kažkas mums nepatinka.
>> Taigi, kaip mes nustatyti, kad?
Ir tikrai, būdas išspręsti šią problemą yra atsižvelgiant tas kandidates kibirai
ir kiekvieno kandidato mes, mes ketiname pridėti atsitiktinis vertę,
kažkas, kad mes žinome, atsitiktinai vertė tarp vieno ir 100,
tarp 100 ir 1000, arba tarp vieno ir 1000,
Tačiau daugelis atsitiktinių dydžių norite prideda ant tos kandidato pabaigoje.
>> Ir ką aš tikrai padaryti tada?
Jei aš naudojant kandidato ID, kaip į suvestinius balsų kibiras,
jei aš pridėjome atsitiktinis numeris, kad pabaigoje,
Aš sukūriau dabar 10 kibirai A šimtą kibirai, tūkstantis kaušai
kad aš sudedant balsus visoje.
>> Taigi turiu milijonus ir milijonus, ir milijonai įrašų ateinantį
šių kandidatų, aš dabar plinta tie balsai visoje A_1 kandidatinį
per A_100 kandidačių, nes kiekvieną kartą, kai balsas ateina,
Aš generuoti atsitiktinis vertė tarp vieno ir 100.
Aš sujungdamas jį į galutinio Kandidatas kad asmens balsuoti už.
Aš dempingo ją į tą kibirą.
>> Dabar reversas, aš žinau, kad aš turiu šimtus kibirų.
Taigi, kai aš noriu eiti į priekį ir apibendrinti balsus,
Aš perskaičiau iš visų tų kibirų.
Taigi aš eiti į priekį ir pridėti.
Ir tada aš sklaida surinkti kur aš išeiti ir pasakyti ei,
Žinai ką, Kandidatą raktas tarpai yra daugiau nei šimtą kaušai.
Aš ruošiuosi surinkti visus balsus iš tų šimto kibirų.
Aš ruošiuosi kaupti juos ir aš ruošiuosi pasakyti,
Kandidatas dabar Iš viso balsų skaičiavimo x.
>> Dabar tiek rašymo Užklausa ir skaityti užklausa
gražiai pasiskirsto nes aš rašau visoje
ir aš skaitau visoje šimtus raktus.
Aš ne rašyti ir skaityti per vieną raktą dabar.
Štai puikus modelis.
>> Tai iš tikrųjų turbūt vienas iš svarbiausių dizaino
modelius masto NoSQL.
Jūs pamatysite šį tipą projektavimo šablono kiekvieną skonį.
MongoDB, DynamoDB, ji neturi Nesvarbu, mes visi turime tai padaryti.
Nes kai jūs susiduriame su tais didžiuliais apibendrinimo,
jūs turite išsiaiškinti, kaip į skleisti juos visoje kibirai.
Taigi tai yra būdas jums tai padaryti.
Gerai, kad tai, kas jūs darote dabar
yra jūs prekybos išjungti skaityti išlaidos rašymo mastelio.
Mano perskaitytą kaina šiek tiek daugiau kompleksas
ir aš turiu eiti perskaityti iš šimtas vienas kibirai vietoj.
Bet aš galėtų parašyti.
Ir mano pralaidumas, mano rašymo pralaidumas yra neįtikėtinas.
Taigi, tai paprastai yra vertingas technika mastelio DynamoDB,
ar NoSQL duomenų šiuo klausimu.
Taigi, mes suprato, kaip jo mastelį.
Ir mes sugalvojome kaip pašalinti mūsų sparčiuosius klavišus.
Ir tai yra fantastinis.
Ir mes turime šį gražią sistemą.
Ir tai mums suteikė labai teisingą balsavimo nes mes turime įrašyti balsų de-Dupe.
Jis pastatytas į DynamoDB.
Mes kalbėjome apie sąlyginių teisių.
>> Kai rinkėjas ateina, užsideda on stalo įterpti,
jie įterpti savo rinkėjų ID, jei jie bando įterpti dar vieną balsą,
Aš sąlyginį rašyti.
Pasakykite rašyti tik ši jei tai neegzistuoja.
Taigi kuo greičiau matau, kad kad balsas hito lentelę,
niekas ketina būti galėtų įdėti savo balsą.
Ir tai fantastinis.
Ir mes incrementing Mūsų kandidatės skaitikliai.
Ir mes darome demografijos ir visa kita.
Bet kas atsitinka, jei mano taikymas patenka per?
Dabar visi staiga balsų yra ateinantį ir man
nežinau, jei jie gauti perdirbti į mano analitikai ir demografija
nebėra.
Ir kai paraiška grįžta iki, kaip
po velnių aš žinau, ką balsai buvo tvarkomi ir kur man pradėti?
>> Taigi tai yra tikra problema, kai jūs pradėti ieškoti šio scenarijaus tipo.
Ir kaip mes sprendžiame, kad?
Mes ją išspręsti, ką mes skambinti DynamoDB srautus.
Srautai yra laikas užsisakyti ir atitverta Pakeitimai registruojami kiekvieno galimybės
į lentelę, kiekvienas rašyti prieiga prie stalo.
Bet duomenys, parašyta į Lentelėje parodyta, ant upelio.
>> Tai iš esmės 24 valandų eilėje.
Daiktai nukentėjo srautą, jie gyvena 24 valandas.
Jie gali būti skaitomos kelis kartus.
Garantuotas turi būti pristatytas tik vieną kartą į srautą,
galėtų būti skaitomos n skaičių kartų.
Taigi, tačiau daugelis procesų norite vartojame tuos duomenis, galite jį valgo.
Jis bus rodomas kiekvieną atnaujinimą.
Kiekvienas Parašyti bus tik kartą ant upelio.
Taigi jūs neturite jaudintis apie ją apdoroti du kartus
iš to paties proceso metu.
>> Jis griežtai įsakė už vienetą.
Kai mes sakome laikas užsisakyti ir atitverta,
pamatysite už pertvaros nuo upelio.
Pamatysite elementus, atnaujinimus tvarka.
Mes nesame garantuoti ant upelio, kad jūs
ketinate gauti kiekvienas sandoris į visoje daiktų tvarka.
>> Taigi srautai yra idempotent.
Ar mes visi žinome, kas idempotent reiškia?
Idempotent reiškia, kad jūs galite tai padaryti daugiau, ir daugiau, ir vėl.
Rezultatas ketina būti ta pati.
>> Srautai yra idempotent, tačiau jie turi būti
grojo nuo pradinio taško, kur jums pasirinkti iki galo,
ar jie nebus tose pačiose vertėmis.
>> Tas pats su MongoDB.
MongoDB turi konstruktą jie vadina oplog.
Tai yra lygiai toks pats konstruktas.
Daugelis NoSQL duomenų bazės turi šį konstruktą.
Jie naudoja jį daryti tai, ko kaip replikacija, kuris
yra būtent tai, ką mes darome su upelių.
Auditorija: Gal erezija klausimas, bet jūs
kalbėti apie programos daro žemyn kt.
Ar srautai garantuotai niekada galbūt eiti?
RICK Houlihan: Taip, upelių garantuoja, kad niekada eiti.
Mes valdyti infrastruktūrą atsilieka. upelių automatiškai
dislokuoti savo Automatinis mastelio grupei.
Mes eiti per mažai tiek apie tai, kas vyksta.
>> Aš ne pasakyti, kad jie nėra garantuoja, kad niekada eiti.
Elementai yra garantuotas atvykti į srautą.
Ir srautas bus prieinama.
Taigi, kas krinta arba grįžta aukštyn, kad vyksta apačioje.
Tai covers-- viskas OK.
Gerai, taigi, galėsite gauti skirtingi Peržiūrėti tipai išjungti ekrano.
Į view tipų, kurie yra svarbūs iki A programuotojas paprastai yra, kas tai buvo?
Man seną vaizdą.
Kai atnaujinimas hitai lentelę, jis bus stumti seną vaizdą į upelį
todėl duomenys gali archyvuoti ar pakeitimas valdymo, pokyčių nustatymas, pakeitimas
valdymas.
>> Naujas įvaizdis, kas jis yra dabar, po atnaujinimas, tai kita nuomone tipas
galite gauti.
Jūs galite gauti tiek senų ir naujų nuotraukų.
Gal aš noriu juos abu.
Noriu pamatyti, kas tai buvo.
Noriu pamatyti, ką ji pasikeitė.
>> Turiu atitikties tipą proceso, kuris veikia.
Ji turi patikrinti, ar kai šie dalykai pakeisti,
kad jie tam tikrose ribose arba per tam tikrus parametrus.
>> Ir tada gal aš tik reikia žinoti, kas pasikeitė.
Man nerūpi, ką punktas pakeistas.
Man nereikia, kad reikia žinoti kas atributus pasikeitė.
Aš tiesiog reikia žinoti, kad elementai yra palietė.
Taigi tai yra nuomonėmis tipai kad jūs išlipti srautas
ir jūs galite bendrauti su.
>> Prašymas, kad sunaudoja srautą,
tai yra rūšies, kaip ši dirba.
DynamoDB klientas paprašys stumti duomenis lentelėse.
Srautai dislokuoti apie tai, ką mes vadiname šukių.
Šukės yra mastelis nepriklausomai lentelėje.
Jie neturi išsirikiuoti visiškai prie jūsų stalo pertvaros.
Ir priežastis, kodėl yra nes jie išsirikiuoja
su gebėjimu, dabartinis talpa lentelėje.
>> Jie dislokuoti savo savo auto mastelio grupė
ir jie pradeda suktis iš priklausomai kiek rašo ateina į,
kiek reads-- tikrai tai rašo.
Nėra reads-- bet kaip daug rašo ateina į.
>> Ir tada ant nugaros Galų gale, mes turime tai, ką mes
skambinti KCl, ar kineziterapeutai Client biblioteka.
Kinesis yra upelis duomenys apdorojimo technologija iš "Amazon".
Ir upelių yra pastatytas, kad.
>> Taigi jūs naudojate "KCL įjungta taikymas skaityti srautą.
Kinesis Klientas biblioteka iš tikrųjų valdo darbuotojams už jus.
Ir jis taip pat daro kai įdomių dalykų.
Ji sukurs keletą lentelių iki Jūsų DynamoDB tablespace
sekti, kokie daiktai buvo tvarkomi.
Taigi tokiu būdu, jei jis patenka atgal, jei jis patenka daugiau ir ateina ir gauna
stovėjo atgal, ji gali nustatyti, kur Tai buvo perdirbti srautas.
>> Tai labai svarbu, kai jūs kalbate apie replikacija.
Man reikia žinoti, ką duomenys buvo apdorotas
ir kokie duomenys dar turi būti tvarkomi.
Taigi KCL biblioteka srautai duoti jums tą funkcionalumą daug.
Ji rūpinasi visais buityje.
Ji atsistoja už kiekvieną Shard darbuotoją.
Jis sukuria administracinę lentelę už kiekvieną Shard, kiekvienam darbuotojui.
Ir kaip tiems darbuotojams, gaisro, jie gali išlaikyti tas lenteles
kad jūs žinote šį įrašą buvo skaityti ir tvarkomi.
Ir tada, kad taip, jei procesas miršta ir grįžta internete,
jis gali tęsti ten, kur jis išskrido.
>> Taigi, mes naudoti šį kryžminio regionas replikacija.
Daug klientų turime poreikį perkelti duomenis ar dalį savo duomenų lenteles
aplink skirtingų regionų.
Yra devyni regionai visame pasaulyje.
Taigi gali būti need-- aš gali turėti vartotojams Azijoje, vartotojai
į rytinėje JAV.
Jie turi skirtingus duomenis, reikia lokaliai paskirstytas.
O gal vartotojas skrenda iš Azija daugiau į Jungtines Amerikos Valstijas,
ir aš noriu pakartoti jo duomenys su juo.
Taigi, kai jis gauna iš lėktuvo, jis turi gera patirtis naudojant savo mobilųjį app.
>> Galite naudoti kryžminio regioną replikacijos biblioteka tai padaryti.
Iš esmės mes turime jeigu dvi technologijas.
One konsolės programa jūs galite atsistoti ant savo EC2 pavyzdžiui.
Jis veikia grynas replikaciją.
Ir tada mes davė jums biblioteką.
Biblioteka galite naudoti norėdami sukurti savo paraišką, jei jums
nori daryti beprotiškus dalykus, kad data-- filtras, atkartoti tik dalį jo,
pasukti duomenis, perkelti jį į "A skiriasi lentelėje, taip toliau ir taip toliau.
Taigi, kad tipo kas tai atrodo.
>> DynamoDB Srautai gali būti tvarkomi, ką mes vadiname Lambda.
Mes paminėti šiek tiek apie renginį orientuotų technologijų taikymo architektūros.
Lambda "yra pagrindinė sudedamoji dalis, kad.
Lambda "yra kodas, kuris gaisrai pagal pareikalavimą reaguojant į tam tikrą atveju.
Vienas iš šių įvykių gali būti įrašas rodomas upelio.
Jei ant upelio atrodo įrašas, mes tai vadiname "Java" funkciją.
Na, tai yra JavaScript ir "Lambda" palaiko Node.js, Java, Python,
ir netrukus remti Kitos kalbos taip pat.
Ir pakanka pasakyti, kad tai grynas kodą.
rašyti Java, galite apibrėžti klasę.
Jūs stumti JAR aukštyn į Lambda.
Ir tada jūs nurodote kurią klasę skambinti reaguojant į kurį renginį.
Ir tada "Lambda infrastruktūra atsilieka, kad bus paleisti tą kodą.
>> Tas kodas gali apdoroti įrašų off upelio.
Jis gali daryti ką ji nori su juo.
Šiuo konkrečiu Pavyzdžiui, visi mes tikrai daro prisijungia atributus.
Bet tai tik kodas.
Kodas nieko negali padaryti, tiesa?
>> Taigi, galite pasukti, kad duomenis.
Jūs galite kurti išvestinį vaizdą.
Jei tai dokumentas, struktūra, galite priploti struktūrą.
Jūs galite kurti pakaitinius rodiklius.
Visi rūšių dalykų galite daryti su DynamoDB srautus.
>> Ir tikrai, tai ką tai atrodo.
Taigi Jūs gaunate tie atnaujinimai ateina.
Jie atskilimas eilutę.
Jie skaitys Lambda funkcija.
Jie sukasi duomenis ir stumia jį į išvestines lenteles,
pranešdama apie išorines sistemas kaita, ir stumia duomenis į ElastiCache.
>> Mes kalbėjome apie tai, kaip įdėti atminties turinį priešais duomenų bazėje, kad pardavimo
scenarijus.
Na, kas atsitinka, jei aš atnaujinti elemento aprašymą?
Na, jei aš buvo "Lambda" funkcija veikia toje lentelėje,
jei aš atnaujinti elemento aprašymą, jis bus pasiimti įrašą išjungti srovę,
ir jis bus atnaujinti ElastiCache pavyzdžiui, su naujais duomenimis.
Taigi, kad daug Ką mes darome su Lambda.
Tai klijai kodas, jungtys.
Ir tai iš tikrųjų suteikia gebėjimas pradėti
ir paleisti labai sudėtingas programas be serveris
infrastruktūra, kuri yra tikrai cool.
>> Taigi grįžkime prie mūsų realaus laiko balsavimo architektūra.
Tai naujas ir patobulintas su mūsų upelių ir KCL leido paraišką.
Tas pats, kaip ir anksčiau, mes galime dirbti bet rinkimuose mastą.
Mums patinka tai.
Mes darome iš sklaida, renkasi kelis kibirus.
Mes turime optimistiškai fiksavimo vyksta.
Mes galime išlaikyti mūsų rinkėjus keisti savo balsus.
Jie gali balsuoti tik vieną kartą.
Tai fantastinis.
Realaus laiko kaltė, tolerancija, keičiamo dydžio agregacija dabar.
Jei dalykas patenka daugiau, tai žino, kur iš naujo save
kai kalbama apie atsargines kopijas, nes mes naudojant KCl programą.
Ir tada mes taip pat galime naudoti, kad KCL taikymas stumti duomenis iš
į Redshift kitiems App Analytics "arba naudoti
elastinga MapReduce paleisti realaus laiko transliacijos apibendrinus išjungt
tos duomenų.
>> Taigi tai yra tai, ką mes ne kalbėjo apie daug.
Bet jie papildomai technologijos, kurios ateina
padengti, kai jūs ieškote Šiuose scenarijų tipų.
>> Gerai, kad yra apie Analytics DynamoDB srautus.
Jūs galite rinkti de-Dupe duomenys, tai visų rūšių
Nicos stuff, Užpildų duomenys atmintis, sukurti tų išvestinių lentelių.
Tai didžiulis naudojimo atveju kad daug klientų
yra susiję su, atsižvelgiant lizdinė savybės tų JSON dokumentų
ir sukurti papildomų rodykles.
>> Mes pabaigoje.
Dėkojame už guolis su manimi.
Taigi pakalbėkime apie Pamatinė architektūra.
DynamoDB sėdi viduryje taip daug AWS infrastruktūrą.
Iš esmės, galite jį prijungti iki ko norite.
Programos sukurta naudojant "Dinamo" apima Lambda ", ElastiCache, CloudSearch,
stumti duomenis iš į Elastinis MapReduce, importas eksportas iš DynamoDB
į S3, visų rūšių darbo krūvius.
Bet turbūt geriausias dalykas kalbėti apie,
ir tai, kas iš tikrųjų Įdomu tai, kai mes
kalbėti apie įvykį lėmė programų.
>> Tai yra pavyzdys vidinis projektas
kad mes turime kur mes iš tikrųjų leidyba surinkti tyrimo rezultatus.
Taigi saitą el, kad mes siunčiame, ten
būti šiek tiek nurodo sakydamas paspaudimas čia atsakyti į apklausos.
Ir kai žmogus spustels kurie nurodo, kas atsitinka,
yra jos išgriauti saugus HTML apklausos forma nuo S3.
Nėra serveris.
Tai yra tik S3 objektas.
>> Tai forma ateina, krovinius iki naršyklėje.
Jis gavo pagrindas.
Jis gavo kompleksas "JavaScript" kad jis veikia.
Taigi tai labai turtingas programa veikia kliento naršyklėje.
Jie nežino, kad jie ne bendrauja su nugaros pabaigos serveryje.
Šiuo metu, tai visi naršyklėje.
>> Jie paskelbia į rezultatus kas mes vadiname Amazonės API Vartai.
API Vartai yra tiesiog Web API kad jūs galite nustatyti ir Pajungti
į ką nori.
Šiuo konkrečiu atveju, mes užsikabinęs Lambda funkcija.
>> Taigi, mano siuntimo operacija vyksta be serverio.
Iš esmės, kad API Vartai sėdi ten.
Tai kainuoja man nieko, kol žmonės Pradėti rašyti į ją, tiesa?
Lambda funkcija tiesiog sėdi ten.
Ir tai kainuoja man nieko, kol žmonės pradeda pataikyti ją.
Taigi matote, kaip tūrio padidėja, tai kai mokesčiai ateis.
Nesu veikia serverio 7/24.
>> Taigi aš traukti formą krinta iš kibiro,
ir aš rašyti per API Vartai į Lambda funkcija.
Ir tada "Lambda" funkcija sako, žinote,
ką, aš turiu keletą PIIs, kai asmeniškai identifikuojančią informaciją
Šiose atsakymų.
Gavau komentarus mašinos iš vartotojų.
Aš turiu elektroninio pašto adresus.
Aš turiu vardus.
>> Leiskite padalinti šią funkciją.
Aš ruošiuosi generuoti kai metaduomenų išjungti šio įrašo.
Ir aš ruošiuosi stumti metaduomenis į DynamoDB.
Ir aš galėčiau užšifruoti visus duomenis ir stumti jį į DynamoDB jei noriu.
Bet tai lengviau man, šiame naudojimo atveju, eiti į priekį žinutę nuomonę,
Aš ruošiuosi stumti neapdorotus duomenis į saugiame S3 kibirą.
Tad aš naudoju pastatytas S3 serverio pusėje šifravimo ir "Amazon" raktų valdymo
Paslaugų kad turiu raktą, galima pasukti reguliariai intervalu,
ir aš galiu apsaugoti, kad PCAD duomenis kaip visą šią darbo eigą.
>> Taigi, ką aš padariau?
Aš ką tik įdiegta visa taikymo, ir aš neturiu serverio.
Taigi, kas įvykis lėmė taikymą architektūra daro už jus.
>> Dabar, jei jūs manote apie naudojimo atveju už this--
turime kitų klientų Aš kalbu iki maždaug taisyti architektūros, kuris
paleisti fenomenaliai didelės kampanijas, kurie žiūri tai ir vyksta, Oh my.
Nes dabar, jie gali iš esmės stumti jį iš ten,
leisti, kad kampaniją tiesiog sėdėti ten tol, kol ji pradeda, o ne
jaudintis figos apie kokios infrastruktūros
bus ten ją paremti.
Ir tada, kai tik kad kampanija bus padaryta,
tai kaip infrastruktūros tiesiog iš karto nueina
nes ten tikrai jokios infrastruktūros.
Tai tiesiog kodas, kuris sėdi ant Lambda.
Tai tiesiog duomenų, kad sėdi DynamoDB.
Tai nuostabi būdas kurti programas.
>> Auditorija: Taigi tai daugiau efemeriška, nei ji būtų
jei jis buvo saugomi faktinė serverio?
>> RICK Houlihan: Absoliučiai.
Nes Server turėtų būti 7/24.
Ji turi būti prieinama nors reaguoti į.
Na atspėti, ką?
S3 yra 7/24.
S3 visada reaguoja.
Ir S3 yra labai, labai gera ne tarnauja iki objektus.
Šie objektai gali būti HTML failus, arba JavaScript failus, arba ką nori.
Galite paleisti labai turtingą interneto programas iš S3 kaušai, ir žmonės.
>> Ir taip tai idėja čia yra gauti iš to, kaip toli
mes naudojome apie tai galvoti.
Mes visi naudojami galvoti sąlygos serverių ir šeimininkai.
Tai ne apie tai daugiau.
Tai apie infrastruktūrą, kaip kodą.
Pasinaudokite kodą į debesis ir tegul debesis paleisti jį už jus.
Ir tai, ką AWS bando daryti.
>> Auditorija: Taigi savo aukso lauke viduryje API Vartai yra ne serveris-kaip,
bet vietoj yra just--
>> RICK Houlihan: Jūs galite galvoti apie tai, kaip serverio fasadas.
Visa tai yra tai paimsiu HTTP prašyti ir map jį į kitą procesą.
Štai visa tai daro.
Ir šiuo atveju, mes kartografavimo jį į Lambda funkcija.
Gerai, kad viskas, ką aš turiu.
Labai ačiū.
Aš tai vertinu.
Aš žinau, mes norime šiek tiek per tam tikrą laiką.
Ir tikiuosi jus vaikinai gavo šiek tiek informacijos
kad jūs galite pasiimti šiandien.
Ir aš atsiprašau, jei aš per kai kurie iš jūsų galvų,
bet ten geras daug pagrindinė pamatinių žinių
kad aš manau, yra labai vertinga už jus.
Taigi ačiū už tai, kad mane.
[Plojimai]
Auditorija: [nesigirdi] yra, kai jums buvo sakydamas
Jums teko eiti per dalykas nuo pradžios iki pabaigos
gauti teisingas vertybes arba tie patys dydžiai,
Kaip vertybės jei [nesigirdi] keistis.
>> RICK Houlihan: Oi, idempotent?
Kaip vertybės pakeisti?
Na, nes jei aš ne paleisti visa tai būdas iki galo,
tada aš nežinau, ką keičia buvo padaryta paskutinės mylios.
Jis nesiruošia būti patys duomenys, kaip tai, ką aš pamačiau.
AUDITORIJA: O, todėl jūs tiesiog ne Dotarłeś visą įvestį.
RICK Houlihan: Teisė.
Jūs turite eiti nuo pradžios iki pabaigos, ir tada jis
bus nuosekliai valstybė.
Saunus.
>> Auditorija: Taigi jūs mums parodė DynamoDB gali padaryti dokumentą arba rakto.
Ir mes praleido daug laiko ant rakto su maišos ir būdų
apversti jį aplink.
Kai pažvelgė tose lentelėse, yra tai, kad paliekant dokumento požiūrį?
>> RICK Houlihan: aš ne sako paliekant nuošalyje.
>> Auditorija: Jie buvo atskirti nuo the--
>> RICK Houlihan: Su dokumento požiūris, dokumentas tipas DynamoDB
tiesiog manau, kaip ir kitas atributas.
Tai požymis, kad yra hierarchinė duomenų struktūra.
Ir tada į užklausas, galite naudoti savybes
iš tų objektų, naudojant Object Notation.
Taigi aš galiu filtruoti lizdinė nuosavybė JSON dokumentą.
Auditorija: Taigi bet kuriuo metu aš padaryti dokumento požiūrį,
Galiu rūšiuoti atvykti į tabular--
Auditorija: Absoliučiai.
Auditorija: --indexes ir dalykų, kuriuos tiesiog kalbama.
RICK Houlihan: Taip, indeksai ir visa tai,
kai norite indeksuoti savybės JSON,
būdas, kad mes norime daryti, kad yra, jei įdedate JSON ar dokumentą
į Dynamo, turėtumėte naudoti srautus.
Srautai būtų perskaityti įvestį.
Norite gauti, kad JSON objektas ir norite pasakyti Gerai,
kas yra nuosavybė Aš noriu indeksas?
>> Jūs sukuriate išvestinį lentelę.
Dabar tai, kaip ji veikia dabar.
Mes neleidžiame jums indeksą tiesiogiai tos savybės.
>> Auditorija: Tabularizing savo dokumentus.
>> RICK Houlihan: Būtent, plokštesnės IT, tabularizing jį tiksliai.
Štai ką jūs darote su juo.
>> Auditorija: Ačiū.
>> RICK Houlihan: Yep, absoliučiai, ačiū.
Auditorija: Taigi tai tipo Mongo atitinka REDIS classifers.
>> RICK Houlihan: Taip, tai patinka, kad daug.
Tai geras aprašymas už jį.
Saunus.