[Musiikkia] RICK Houlihan: Selvä. Hei kaikki. Nimeni on Rick Houlihan. Olen vanhempi pääasiallinen ratkaisut arkkitehti AWS. I keskittyä NoSQL ja DynamoDB tekniikoita. Olen täällä tänään puhua olet hieman näistä. 

Oma taustani on ensisijaisesti tiedot kerros. Vietin puoli minun kehitys ura kirjallisesti tietokanta, tietojen saatavuutta, ratkaisut erilaisiin sovelluksiin. Olen ollut Cloud virtualisointi noin 20 vuotta. Joten ennen Cloud oli Cloud, käytimme kutsua Utility Computing. Ja ajatus oli, se on kuin PG & E, maksat siitä mitä käytät. Tänään me kutsumme sitä pilvi. 

Mutta vuosien mittaan, olen työskennellyt pari yritykset olet todennäköisesti koskaan kuullut. Mutta olen koonnut luettelon teknisen saavutuksia, kai haluat sanoa. Minulla on kahdeksan patentteja Cloud järjestelmät virtualisointi, mikroprosessori suunnittelu, monimutkainen tapahtuma käsittely, ja muilla aloilla. 

Niin näinä päivinä, keskityn lähinnä NoSQL teknologioita ja seuraavan sukupolven tietokanta. Ja se on yleensä mitä aion olla täällä puhumassa teille tänään. Mitä voit odottaa Tämän istunnon, käymme läpi lyhyt historia tietojenkäsittelyä. On aina hyödyllistä ymmärtää mistä tulimme ja miksi olemme missä olemme. Ja me puhumme hieman vähän siitä NoSQL tekniikka alkaen perustavanlaatuinen näkökulmasta. 

Saamme joihinkin DynamoDB sisäosat. DynamoDB on AWS: n ei maku. Se on täysin onnistunut ja isännöi NoSQL ratkaisu. Ja me puhumme hieman siitä taulukko rakenne, API, tietotyypit, hakemistot, ja jotkut sisäosat Tämän DynamoDB tekniikkaa. Pääsemme joitakin suunnittelu malleja ja parhaita käytäntöjä. Puhutaan miten käyttää tätä tekniikkaa joidenkin nykypäivän sovelluksia. Ja sitten me jutellaan vähän noin evoluutio tai syntymistä uuden paradigman ohjelmoinnin nimeltään tapahtumapohjainen sovelluksia ja miten DynamoDB soittaa että samoin. Ja me jättää sinut hieman viittaus arkkitehtuuri keskustelu jotta voimme puhua joistakin miten voit käyttää DynamoDB. 

Joten ensimmäinen off-- tämä on kysymys Kuulen paljon on, mitä tietokanta. Monet ihmiset ajattelevat, että he tietävät, mitä tietokannassa on. Jos Google, näet tämän. Se on jäsennelty joukko tietoja hallussa tietokoneessa, varsinkin sellainen, joka on saatavilla eri tavoin. Oletan, että on hyvä määritelmä modernin tietokannan. Mutta en pidä siitä, koska se merkitsee pari asiaa. Se merkitsee rakenne. Ja se merkitsee, että se on tietokoneessa. Ja tietokannat eivät aina olemassa tietokoneissa. Tietokannat todella olemassa monin tavoin. 

Joten parempi määrittely tietokanta on jotain tällaista. Tietokanta on organisoitu mekanismi tallentamiseen, hallintaan, ja tiedonhaku. Tämä on peräisin About.com. Joten Pidän tästä, koska se todella puhuu noin tietokanta on arkiston, arkisto tietoja, ei välttämättä jotain, joka istuu tietokoneella. Ja läpi historian, me ei ole aina ollut tietokoneita. 

Nyt, jos kysyn keskimäärin kehittäjä tänään mitä tietokanta, joka on vastaus saan. Jossain Voin kiinni kamaa. Oikea? Ja se on totta. Mutta se on valitettavaa. Koska tietokanta on todella perusta nykyaikaisen sovelluksen. Se on perusta jokaisen hakemuksen. Ja miten rakentaa, että tietokanta, miten rakenne että tiedot on menossa sanella miten että sovellus toimii kuten mittakaavassa. 

Niin paljon työni tänään käsittelee mitä tapahtuu, kun kehittäjät tätä lähestymistapaa ja käsittelevät jälkimainingeissa hakemuksen, joka on nyt skaalaus yli alkuperäisen tahallisuus ja kärsii huonosta suunnittelusta. Joten toivottavasti kun kävelymatkan päässä tänään, luultavasti on pari työkaluja vyöhön että pitää sinut tekemästä niitä samoja virheitä. Selvä. Joten Puhutaanpa hieman aikajana tietokantateknologia. Taisin lukea artikkeli ei niin kauan sitten ja se sanoi jotain lines-- se on hyvin runollinen lausunto. Se sanoi historia Tietojen käsittely on täynnä korkea vesileimat Tietojen runsaus. OK. Nyt, oletan, että on tavallaan totta. Mutta olen itse tarkastella on kuin historia on todella täynnä korkea vesileima tietojen paine. Koska datanopeus nauttiminen ei koskaan mene alas. Se vain menee ylös. 

Ja innovaatio tapahtuu, kun näemme tiedot paine, joka on datan määrä, joka on nyt tulossa järjestelmään. Ja se ei voi käsitellä tehokkaasti joko eri aikaan tai eri kustannuksia. Ja silloin alamme tarkastella tietoja paineessa. 

Joten kun katsomme ensimmäinen tietokanta, tämä on yksi, joka oli välillä korvat. Olemme kaikki syntyneet kanssa. Se on kiva tietokanta. Se on korkean käytettävyyden. Se on aina päällä. Voit aina saada sitä. 

Mutta se on yksi käyttäjä. En voi jakaa ajatuksiani kanssanne. Et voi saada ajatukseni kun haluat niitä. Ja heidän abilitiy ei ole niin hyvä. Me unohtaa asioita. Aina silloin tällöin, yksi meistä lehdet ja siirtyy toiseen olemassaoloon ja menetämme kaiken joka oli, että tietokantaan. Niin, että ei ole kaikki, että hyvä. 

Ja tämä toimi hyvin ajan kun olimme takaisin seuraavana päivänä kun kaikki me todella tarvitaan tietää Mihin olemme menossa huomenna tai jos keräämme parasta ruokaa. Mutta kun aloimme kasvaa sivistyksen ja hallitus käynnisti että otetaan käyttöön, ja yritykset alkoivat kehittyä, aloimme ymmärtää me tarvitsevat hieman enemmän kuin mitä voisimme laittaa meidän pään. Selvä? 

Tarvitsimme järjestelmien ennätys. Tarvitsimme paikkoja voi tallentaa tietoja. Aloimme kirjallisesti asiakirjat, luodaan kirjastojen ja arkistojen. Aloitimme kehittää järjestelmä Ledger kirjanpito. Ja että järjestelmä Ledger laskenta juoksi maailman vuosisatojen ajan, ja ehkä jopa vuosituhansia kuin me tavallaan kasvoi pisteeseen jos tietojen kuormitus ylitti kyky näiden järjestelmien pystyä sisältää sitä. 

Ja tämä todella tapahtui 1880-luvulla. Oikea? Vuonna 1880 US Census. Tämä on todella, jossa käännön kohta moderni tietojenkäsittely. Tämä on piste jossa datan määrä että keräsi Yhdysvaltain hallitus tulleet pisteeseen jossa se kesti kahdeksan vuotta käsitellä. 

Nyt, kahdeksan years-- kuten tiedät, väestönlaskenta kulkee joka 10 years-- joten se on melko selvää, että aika sai 1890 väestönlaskenta, datan määrä, joka piti käsitellä valtion oli tulee ylittämään 10 vuotta, että se kestäisi käynnisti uuden väestönlaskennan. Tämä oli ongelma. 

Joten kaveri nimeltä Herman Hollerith tulivat ja hän keksi yksikkö ennätys booli kortit, booli kortinlukija, reikäkorttikoneilla tabulaattoria, ja kokoamista mekanismeja tätä tekniikkaa. Ja että yhtiö hän muodostettu aika, sekä pari muuta, itse asiassa tuli yksi peruspilareista pieni yritys tunnemme tänään nimeltään IBM. 

Joten IBM alunperin oli tietokanta liiketoimintaa. Ja se on todella mitä he tekivät. He tekivät tietojenkäsittely. 

Kuten niin leviämisen booli kortteja, nerokas mekanismeja että voimme hyödyntää että teknologia kyselyn lajiteltua tulosjoukkoja. Voit nähdä tässä kuvassa siellä meillä little-- se on hieman small-- mutta voit nähdä erittäin nerokas mekaaninen mekanismi jossa meillä on booli kortin pakalla. Ja joku vie pieni ruuvimeisseli ja kiinni kautta lähtö ja nostamalla sitä ylös saada, että ottelu, että lajiteltu tulokset asetettu. 

Tämä on yhdistäminen. Teemme tämän kaiken aikaa tänään tietokone, jossa teet sen tietokantaan. Käytimme tehdä sen manuaalisesti, eikö? Ihmiset laittaa nämä asiat yhteen. Ja se oli leviämisen Näiden reikäkortteja mitä me kutsutaan tietojen rummut ja tiedot kelat, paperi nauha. 

Tietojenkäsittely teollisuus otti opetus soittimesta pianot. Pelaajan pianos takaisin vuosisadan vaihteessa tapana käyttää paperirullien kanssa lähtö on kertoa se mitä näppäimiä pelata. Jotta teknologia mukautettiin lopulta tallentaa digitaalista tietoa, koska ne voisi laittaa, että tiedot asemia paperi nauha rullia. 

Nyt, sen seurauksena, tiedot oli actually-- miten käytät näitä tietoja oli suoraan riippuu siitä, kuinka se on tallennettu. Joten jos laitan tietoja nauhalle, Minulla oli käyttää tietoja lineaarisesti. Minulla oli roll koko nauha käyttää kaikkia tietoja. Jos laitan tiedot booli kortteja, voisin käyttää sitä hieman enemmän satunnaisia muoti, ehkä ei niin nopeasti. 

Mutta on rajoituksia siinä, miten pääsy tietoihin perustuvat kuinka säilytettiin. Ja niin tämä oli ongelma menee 50-luvulla. Jälleen voimme alkaa nähdä, että me kehittää uutta teknologiaa käsitellä tiedot, oikea, se avautuu ovi uusia ratkaisuja, uusien ohjelmien, uusi Hakemukset että tiedot. Ja todella, hallintotapa saattanut olla syy miksi olemme kehittäneet joitakin näistä järjestelmistä. Mutta liike tuli nopeasti kuljettaja takana evoluutio modernin tietokannan ja moderni tiedostojärjestelmä. 

Joten seuraava asia, että tuli oli 50-luvulla oli tiedostojärjestelmä ja kehittäminen random access varastoinnin. Tämä oli kaunis. Nyt kaikki äkillinen, voimme ottaa tiedostoja tahansa näistä kiintolevyt ja voimme käyttää näitä tietoja satunnaisesti. Voimme jäsentää että tietoa ulos tiedostoja. Ja me ratkaista kaikki maailman ongelmia tietojenkäsittely. 

Ja joka kesti noin 20 tai 30 vuotta kunnes kehitys on relaatiotietokannan, joka on kun maailma päätti nyt täytyy olla arkisto tyhjäksi hajautumista dataa tiedosto järjestelmät että olemme rakentaneet. Oikea? Liian paljon tietoa jaetaan liikaa paikkoja, de-päällekkäisyyksiä tietojen, ja kustannukset varastointi oli valtava. 

70-luvulla, kallein resurssi että tietokone oli ollut varastointi. Prosessori oli pitää kiinteät kustannukset. Kun ostan laatikko, CPU tekee jonkin verran työtä. Se tulee pyöriä onko Se on itse asiassa toimii tai ei. Se on todella uponneita kustannuksia. 

Mutta mitä maksaa minulle liiketoiminta on varastointi. Jos minun täytyy ostaa enemmän levyjä seuraavaksi kuukaudessa, se on todellisia kustannuksia että voin maksaa. Ja että varastointi on kallista. 

Nyt nopeasti eteenpäin 40 vuotta ja meillä on erilainen ongelma. Laske on nyt kallein voimavara. Varastointi on halpaa. Tarkoitan, voimme mennä minne tahansa pilvi ja voimme löytää halpoja varastointi. Mutta mitä en löydä on halpa laskea. 

Joten kehitys nykypäivän teknologia, tietokanta teknologia, on todella keskittynyt noin hajautettujen tietokantojen että eivät kärsi samantyyppistä mittakaavassa rajoitukset relaatiotietokantojen. Puhutaan hieman siitä mitä se todella tarkoittaa. 

Mutta yksi syy ja kuljettaja takana this-- me puhui tiedot paine. Tiedot paine on jotain että innovaatioiden lähde. Ja jos tarkastellaan yli viimeisten viiden vuoden aikana, tämä on kaavio, mitä tietoja kuormitus koko yrityksen yleisiin näyttää viimeisten viiden vuoden aikana. 

Ja Nyrkkisääntönä nämä days-- jos menet Google-- on 90%: n tietoja, jotka Tallennamme tänään, ja se oli joka syntyy kahden viime vuoden aikana. OK. Nyt, tämä ei ole trendi, joka on uusi. Tämä on suuntaus, joka on ollut menee ulos 100 vuotta. Siitä lähtien Herman Hollerith kehitti reikäkorttikoneilla, olemme rakentaneet tietovarastot ja keräämällä tietoja ilmiömäinen hinnat. 

Joten viime 100 vuotta, olemme nähneet tämän suuntauksen. Se ei aio muuttaa. Jatkossa aiomme nähdä Tässä, jos ei kiihtynyt suuntaus. Ja näet mitä se näyttää. 

Jos yritys vuonna 2010 oli yksi teratavun tietojen hallinnoitavien, tänään, että tarkoittaa, että ne ovat toimitusjohtaja 6.5 petatavua dataa. Se on 6500 kertaa enemmän tietoa. Ja tiedän tämän. Työskentelen näitä yrityksiä päivittäin. Viisi vuotta sitten, olen puhuisit yritykset jotka puhua minulle mitä kipu se on hallita teratavua dataa. Ja he puhuvat minulle miten näemme että tämä on todennäköisesti aio olla petatavun tai kaksi sisällä pari vuotta. 

Nämä samat yritykset Tänään olen tapaaminen, ja he puhuvat minulle ongelma on siellä ottaa hallintaan kymmeniä, 20 petatavua dataa. Niin räjähdys tiedot alan ajaa valtava tarvitset parempia ratkaisuja. Ja relaatiotietokannan on vain ole elää jopa kysyntää. 

Ja niin siellä on lineaarinen korrelaatio tiedot paineen ja teknisiä innovaatioita. Historia on osoittanut tämä, että ajan mittaan, kun tietomäärä joka on käsitelty ylittää järjestelmän kapasiteetin käsitellä sitä kohtuullisessa ajassa tai kohtuullisin kustannuksin, sitten uudet teknologiat ovat keksineet ratkaista nämä ongelmat. Näiden tekniikoiden, puolestaan ​​avaa oven toiseen joukko ongelmia, jotka kerää vieläkin tietoja. 

Nyt emme aio lopettaa tähän. Oikea? Emme aio lopettaa tähän. Miksi? Koska et voi tietää kaikkea on tietää maailmankaikkeudessa. Ja niin kauan kuin olemme olleet elossa, Kautta historian mies, olemme aina ajanut tietää enemmän. 

Joten se tuntuu jokaisen sentin siirrymme tiellä tieteellisen löydön, Olemme kertomalla datan määrä että meidän täytyy käsitellä eksponentiaalisesti kuten me paljastaa enemmän ja enemmän ja enemmän sen sisäisestä toiminnasta elämän, siitä, miten maailmankaikkeus toimii, noin ajo tieteellinen löytö, ja keksintö, joka teemme tänään. Tietomäärä vain jatkuvasti lisää. Niin että voimme käsitellä tämä ongelma on valtava. 

Niin yksi niistä asioista katsomme kuten miksi NoSQL? Miten NoSQL ratkaista tämän ongelman? No, relaatiotietokantojen, Structured Query Language, SQL-- se on todella konstruktin ihmissuhteisiin database-- nämä asiat ovat optimoitu varastointi. 

Takaisin 70-luvulla, uudelleen, levy on kallista. Provisioinnin harjoittaminen varastointi yrityksessä on loputon. Tiedän. Olen elänyt sen. Kirjoitin varastointi ajurit enterprised superserver yritys takaisin 90-luvulla. Ja tärkeintä on raastava toinen tallennusjärjestelmä oli vain jotain, joka tapahtui päivittäin yrityksessä. Ja se koskaan lopettanut. Suurempi tiheys varastointi, kysyntä korkean tiheyden varastointiin, ja tehokkaamman varastoinnin devices-- se ei ole koskaan lopettanut. 

Ja NoSQL on hyvä tekniikka koska se normalisoi data. Se de-monistaa tiedot. Siinä tiedot rakenne, joka on agnostikko jokaiseen käyttötapa. Useita sovelluksia voi lyödä, että SQL-tietokannan, suorita ad hoc kyselyjä, ja saada tietoja muotoon, että ne tarvitsevat prosessin niiden työmääriä. Kuulostaa fantastinen. Mutta tärkeintä on kanssa tahansa järjestelmä, jos se on agnostikko kaiken, se on optimoitu mitään. OK? 

Ja sitähän saamme kanssa relaatiotietokannan. Se on optimoitu varastointi. Se on normalisoitu. Se on suhteissaan. Se tukee ad hoc kyselyt. Ja se ja se skaalaa pystysuunnassa. 

Jos minun täytyy saada isompi SQL-tietokannan tai tehokkaampi SQL-tietokannan, Menen ostaa isompi pala rautaa. OK? Olen työskennellyt paljon asiakkaita jotka ovat käyneet läpi merkittäviä parannuksia niiden SQL infrastruktuurissa selvittää kuusi kuukautta myöhemmin, he lyömällä seinään uudelleen. Ja vastaus Oracle tai MSSQL tai joku muu on saada isompi laatikko. No ennemmin tai myöhemmin, et voi ostaa isompi laatikko, ja se on todellinen ongelma. Meidän on todella muuttaa asioita. Joten jos tämä toimii? Se toimii hyvin offline analytiikan, OLAP-tyypin työtaakka. Ja se on todella jossa SQL kuuluu. Nyt sitä käytetään nykyään monissa verkossa Kaupallisen Processing-tyyppinen sovelluksissa. Ja se toimii vain sakko jonkin verran käyttöaste, mutta se vain ei mittakaavassa siten, että NoSQL ei. Ja me puhumme hieman vähän siitä, miksi näin on. 

Nyt, NoSQL, toisaalta, on enemmän optimoitu laskentatehoa. OK? Se ei ole agnostikko käyttötapa. Me kutsumme de-normalisoitu rakenne tai hierarkkisen. Tiedot relaatiotietokantaan on liittyneet yhteen useista taulukoista tuottaa, että tarvitset. Tiedot NoSQL tietokantaan tallennetaan asiakirjan sisältää hierarkkinen rakenne. Kaikki tiedot, jotka yleensä liittyneet yhteen tuottamaan että näkymä tallennetaan yhteen asiakirjaan. Ja me puhumme hieman siitä miten se toimii pari kaavioita. 

Mutta ajatus tässä on, että säilytät tietosi kuin nämä instantiated näkemyksiä. OK? Skaalaat vaakatasossa. Oikea? Jos minun täytyy lisätä koko minun NoSQL klusterin, En tarvitse saada isompi laatikko. Saan toiseen ruutuun. Ja minä klusterin ne yhteen, ja voin Shard että tiedot. Puhumme vähän siitä mitä sharding on, olla voivat lisätä tietokantaan useiden fyysiset laitteet ja poistaa este, joka vaatii minua mittakaavassa pystysuunnassa. 

Joten se on todella rakennettu verkossa tapahtumien käsittelyn ja mittakaavassa. Siinä on suuri ero täällä välillä raportointi, eikö? Raportointi, en tiedä kysymyksiä Aion kysyä. Oikea? Reporting-- jos joku minun markkinointiosasto haluaa just-- kuinka monet minun asiakkaat on tämä erityispiirre, joka ostivat tämän day-- En tiedä mitä kyselyn he aikovat kysyä. Joten minun täytyy olla agnostikko. 

Nyt online- kaupallisen sovelluksen, Tiedän mitä kysymyksiä pyydän. Rakensin hakemuksen hyvin erityinen työnkulkua. OK? Joten jos voin optimoida tiedot tallentaa tukea että työnkulun, se tulee olemaan nopeampi. Ja siksi NoSQL voi todella nopeuttamaan Näiden tyyppisiä palveluja. Selvä. 

Joten aiomme päästä hieman teoriaa täällä. Ja jotkut teistä, silmäsi voi perua hieman. Mutta yritän pitää sen korkean tason kuin pystyn. Joten jos olet hankkeessa hallinta, siellä rakenteelle kolmio rajoitteet. OK. Kolmio rajoitteiden sanelee et voi olla kaikkea kaiken aikaa. Ei voi olla sinun kakku ja syödä sitä. Joten projektinhallintaan, että kolmio rajoitteet on voit olla se halpa, voit olla se nopeasti, tai voit olla se hyvä. Valitse kaksi. Koska et voi olla kaikki kolme. Oikea? OK. 

Joten kuulet tästä paljon. Se on kolminkertainen rajoitus, kolmio kolminkertainen rajoitus, tai rauta kolmio on oftentimes-- kun puhut projektipäälliköille, he puhua tästä. Nyt tietokantojen oma rauta kolmio. Ja rauta kolmio tietojen me kutsumme YMP lause. OK? 

YMP lause sanelee miten tietokannat toimivat alle hyvin erityinen ehto. Ja me puhumme mitä tämä edellytys. Mutta kolme pistettä kolmio, niin sanoakseni, ovat C, johdonmukaisuus. OK? Joten maatalouspolitiikan johdonmukaisuus tarkoittaa sitä, että kaikki asiakkaita, jotka voivat käyttää tietokantaa on aina hyvin johdonmukainen näkemys tietojen. Kukaan ei nähdä kaksi eri asiaa. OK? Jos näen tietokanta, Näen samaa mieltä minun kumppani, joka näkee samaan tietokantaan. Se on johdonmukaisuus. 

Saatavuus tarkoittaa, että jos tietokanta verkossa, jos se pääsee, että kaikki asiakkaat aina osaa lukea ja kirjoittaa. OK? Joten jokainen asiakas, joka voi lukea tietokanta aina voi lukea tiedot ja kirjoittaa tietoa. Ja jos näin on, se saatavilla järjestelmä. 

Ja kolmas kohta on mitä kutsumme osio suvaitsevaisuutta. OK? Partition toleranssi välineet että järjestelmä toimii hyvin vaikka fyysinen verkko väliseinät solmujen välillä. OK? Joten solmut klusterin voi puhua toisilleen, mitä tapahtuu? Selvä. 

Joten relaatiotietokantojen choose-- voit valita kaksi näistä. OK. Joten relaatiotietokantojen valita oltava johdonmukaisia ​​ja käytettävissä. Jos osio välillä tapahtuu DataNodes vuonna tietovaraston, tietokanta kaatuu. Oikea? Se vain menee alas. OK. 

Ja siksi ne ovat kasvaa isompi laatikot. Oikea? Koska siellä on no-- yleensä, klusteri tietokanta, siellä ei ole kovin monet niistä jotka toimivat tällä tavoin. Mutta useimmat tietokannat mittakaavassa pystysuunnassa yksi laatikko. Koska niiden on oltava johdonmukainen ja käytettävissä. Jos osio oli tarkoitus injektoida, niin sinun täytyy tehdä valinta. Sinun täytyy tehdä valita johdonmukainen ja käytettävissä. 

Ja sitähän NoSQL tietokantoihin. Selvä. Joten NoSQL tietokanta, se Makuja on kaksi. Me have-- hyvin, se tulee monissa makuja, mutta se on kaksi perus characteristics-- mitä kutsuisimme CP tietokanta, tai johdonmukainen ja osio suvaitsevaisuutta järjestelmä. Nämä kaverit tehdä valinta, että kun solmut menettävät yhteyden toisiinsa, emme aio sallia ihmisiä kirjoittamaan enempää. OK? 

Kunnes kyseinen osio on poistettu, kirjoitusoikeudet on estetty. Tämä tarkoittaa, että he eivät ole käytettävissä. He johdonmukainen. Kun näemme, että osion pistää itse, olemme nyt johdonmukaisia, koska emme aio jotta tietojen muutos kahden puolin osion itsenäisesti toisistaan. Meidän on Muodosta yhteys uudelleen ennen päivitys data on sallittu. OK? 

Seuraava maku olisi AP järjestelmä, tai saatavilla ja osioitu toleranssi järjestelmän. Nämä kaverit eivät välitä. Oikea? Mikä tahansa solmu, joka saa kirjoittaa, otamme sen. Joten olen jäljittelevän tietoni useiden solmut. Nämä solmut saada asiakas, asiakas tulee vuonna, sanoo, aion kirjoittaa joitakin tietoja. Solmu sanoo, ei ole ongelma. Solmu vieressä häntä saa Kirjoita samalla ennätys, hän aikoo sanoa mitään ongelmaa. Jossain takaisin loppupäätä, että tiedot tulee jäljitellä. Ja sitten joku tulee ymmärtää, uh-oh, he järjestelmä ymmärtävät, uh-oh, että on ollut päivityksen kaksi puolta. Mitä me teemme? Ja mitä he tekevät niin on he tekevät jotain, joka avulla ne voivat ratkaista, että tiedot valtio. Ja me puhumme että seuraavassa kaaviossa. 

Asia huomauttaa täällä. Ja en aio saada liian paljon tähän, koska tämä joutuu syvään tiedot teoria. Mutta on kaupallisen puitteet, kulkee ihmissuhteisiin, joka antaa minulle mahdollisuuden turvallisesti tehdä päivityksiä useita yhteisöjä tietokantaan. Ja päivitykset tapahtuu kaikki kerralla tai ei ollenkaan. Ja tätä kutsutaan ACID liiketoimia. OK? 

ACID antaa meille atomisuuden, johdonmukaisuus, eristäminen, ja kestävyys. OK? Tämä tarkoittaa atomi, liiketoimia, kaikki minun päivitykset joko tapahtuu tai sitten eivät. Johdonmukaisuus tarkoittaa sitä, että tietokanta aina tuoda johdonmukainen tilaan, kun päivityksen. Minä en koskaan jätä tietokanta huonossa kunnossa levittämisen jälkeen päivityksen. OK? 

Joten se on hieman erilainen kuin YMP johdonmukaisuus. YMP johdonmukaisuus kaikkia minun asiakkaat voivat aina nähdä tiedot. ACID johdonmukaisuus tarkoittaa sitä, että kun liiketoimi on tehty, tiedot on hyvä. Oma suhteet ovat kaikki hyviä. En aio poistaa vanhemman rivi ja jättää nippu orpo lasten muulla taulukossa. Se ei voi tapahtua, jos olen johdonmukaisesti happamassa liiketoimi. 

Eristäminen tarkoittaa, että liiketoimet esiintyy aina yksi toisensa jälkeen. Lopputulos tietojen on samassa tilassa ikään kuin nämä liiketoimet että annettiin samanaikaisesti teloitettiin sarjaan. Joten se samanaikaisuuden ohjaus tietokantaan. Joten periaatteessa, en voi kasvattaa sama arvo kahdesti kaksi leikkausta. 

Mutta jos sanon lisää 1 tätä arvoa, ja kaksi kauppaa tulevat ja yritän tehdä sen, yksi on menossa sinne ensin ja toinen on menossa sinne jälkeen. Joten lopulta, lisäsin kaksi. Näetkö mitä tarkoitan? OK. 

Kestävyys on melko yksinkertainen. Kun kauppa kuitataan, se on olemaan siellä jopa jos järjestelmä kaatuu. Kun että järjestelmä ottaa talteen, että tapahtuma, joka on tehty on todella olemaan siellä. Niin, että takaukset Acid liiketoimia. Ne ovat ihan kivoja takuut on tietokantaan, mutta ne tulevat nämä kustannukset. Oikea? 

Koska ongelma näiden puitteiden on jos on osion tiedot setti, minun täytyy tehdä päätös. Aion on sallittava päivitykset toisella puolella tai toisella. Ja jos näin tapahtuu, sitten En ole enää menossa pystyä säilyttämään nämä ominaisuudet. Ne eivät ole johdonmukaisia. Niitä ei eristetty. Tämä on, jos se hajoaa varten relaatiotietokantojen. Tämä on syy relaatio tietokantoja mittakaavassa pystysuunnassa. 

Toisaalta, meillä on mitä kutsutaan BASE tekniikkaa. Ja nämä ovat NoSQL Tietokannat. Selvä. Joten meillä on CP, AP tietokantoja. Ja nämä ovat mitä te kutsutte pohjimmiltaan käytettävissä, pehmeä valtio, lopulta johdonmukainen. OK? 

Periaatteessa käytettävissä, koska he osio suvaitsevainen. Ne ovat aina siellä, vaikka siellä verkon osion solmujen välillä. Jos voin puhua solmuun, olen tulee pystyä lukemaan dataa. OK? En ehkä ole aina osaa kirjoittaa tiedot, jos olen johdonmukaisesti alusta. Mutta minä voi lukea tietoja. 

Pehmeä tila ilmaisee että kun luin, että tiedot, se ei ehkä ole sama kuin muut solmut. Jos oikeus annettiin solmu jossain muualla klusterin ja se ei ole mallia koko klusterin mutta kun luin, että tiedot, että valtio ei ehkä ole johdonmukaisia. Kuitenkin, se on lopulta johdonmukainen, mikä tarkoittaa, että kun kirjoittaa on tehty järjestelmään, se monistuu poikki solmujen. Ja lopulta, että valtio saatetaan kuntoon, ja se on johdonmukainen valtio. 

Nyt CAP lause todella pelaa vain yksi ehto. Tämä edellytys on, kun tämä tapahtuu. Koska aina se toimii normaalitilassa, ei ole osio, kaikki on johdonmukainen ja käytettävissä. Olet vain huolissasi YMP kun meillä on osion. Joten ne ovat harvinaisia. Mutta miten järjestelmä reagoi, kun ne esiintyy sanella minkälainen järjestelmä olemme tekemisissä. 

Joten katsomaan mitä joka näyttää AP järjestelmiä. OK? AP järjestelmät tulevat kaksi makua. Ne tulevat maku, joka on Master Master, 100%, aina käytettävissä. Ja he tulevat muut maku, jossa sanotaan, Tiedätkö mitä, aion huolehtia tästä osiointi asia kun todellinen osio tapahtuu. Muuten, siellä tulee olemaan ensisijainen solmut kuka ottaa oikeuksia. OK? 

Joten jos me jotain Cassandra. Cassandra olisi mestari mestari, nyt minua kirjoittamaan mitään solmuun. Mitä tapahtuu? Joten minulla on esineen tietokanta, joka on olemassa kaksi solmua. Kutsukaamme että esine S. Joten meillä on valtio S. Meillä on joitakin toimintoja S, jotka ovat käynnissä. Cassandra antaa minulle kirjoittaa useita solmuja. Joten sanokaamme saan kirjoittaa s kaksi solmua. No, mitä päätyy tapahtuu on kutsumme että osioinnin tapahtuma. Siellä ei voi olla fyysinen verkko osio. Mutta koska muotoilu järjestelmän, se on todella osiointi heti kun saan kirjoittaa kaksi solmua. Se ei pakottaa minut kirjoittaa kaikki läpi yksi solmu. Olen kirjallisesti kaksi solmua. OK? 

Joten nyt minulla on kaksi valtiota. OK? Mitä tulee tapahtumaan on ennemmin tai myöhemmin, siellä tulee olemaan replikointi tapahtuma. Siellä tulee olemaan mitä me kutsutaan osio hyödyntämistä, joka on, jos nämä kaksi valtiot palata yhteen ja siellä tulee olemaan algoritmi joka kulkee sisällä tietokanta, päättää mitä tehdä. OK? Oletuksena, Viimeksi päivitetty voittaa useimmissa AP järjestelmissä. Joten siellä on yleensä Oletuksena algoritmi, mitä he kutsuvat soittopyynnön toiminto, mikä soitetaan, kun tämä ehto havaitaan suorittaa jotain logiikkaa ratkaisemiseksi että konflikti. OK? Oletuksena soittopyynnön ja oletuksena resolverin useimmissa AP tietokannoissa on, arvaa mitä, aikaleima voittaa. Tämä oli viimeinen päivitys. Aion laittaa että päivitys siellä. Saatan dump tämä ennätys että minä polkumyynnillä pois osaksi elpyminen loki niin että käyttäjä voi palata myöhemmin ja sanoa, hei, oli törmäys. Mitä tapahtui? Ja voit itse dumpata kirjaa kaikki törmäykset ja rollbacks ja katso mitä tapahtuu. 

Nyt, kun käyttäjä, voit myös sisältävät logiikan tuohon soittopyynnön. Joten voit muuttaa että soittopyynnön toiminta. Voit sanoa, hei, haluan kunnostamiseksi näitä tietoja. Ja haluan kokeilla ja yhdistää nämä kaksi kirjaa. Mutta se on sinun. Tietokanta ei osaa tehdä oletuksena. Useimmat aika, ainoa asia tietokanta osaa tehdä on sanoa, tämä oli viimeinen ennätys. Se on se, joka tulee voittaa, ja se on arvo aion laittaa. Kun että osio hyödyntämistä ja replikointi tapahtuu, meillä on valtio, joka on nyt n tärkein, mikä on yhdistämisen tilan kaikki nämä esineet. Joten AP järjestelmissä on tämä. CP järjestelmät eivät tarvitse huolestua. Sillä heti osio tulee peliin, he vain lopeta kirjoittaa. OK? Niin, että on erittäin helppo käsitellä johdonmukainen kun et hyväksy mitään päivityksiä. Se CP järjestelmien tehdä. Selvä. 

Joten puhua vähän vähän siitä pääsy kuvioita. Kun puhumme NoSQL, se on All About käyttötapa. Nyt SQL on tilapäinen, kyselyt. Se on relaatio myymälä. Meillä ei tarvitse huolehtia noin käyttötapa. Kirjoitan hyvin monimutkainen kyselyn. Se menee ja saa tiedot. Sitähän tämä näyttää kuten, normalisointi. 

Joten tässä erityinen rakenne, me tarkastelemme tuotteita luettelo. Minulla on erilaisia ​​tuotteita. Minulla on kirjoja. Minulla albumeita. Minulla on videoita. Suhde tuotteet ja jokin näistä kirjoista, albumit, ja videot taulukot on 1: 1. Selvä? Minulla tuotteen tunnus, ja että tunnus vastaa kirjaan, albumin, tai videon. OK? Se on 1: 1 suhde yli kyseiset taulukot. 

Nyt books-- kaikki ne on on juuri ominaisuuksia. Ei ongelmaa. Sepä hienoa. Yksi-yhteen suhde, saan kaikki tiedot Minun täytyy kuvata että kirja. Albums-- albumeilla on kappaleita. Tämä on mitä me kutsumme yhdeltä monelle. Jokainen albumi voi olla monia kappaleita. Joten jokaisen kappaleen albumi, voisin olla toinen ennätys tämän lapsen taulukossa. Joten luon yksi ennätys minun albumia taulukossa. Luon useita tietueita vuonna kappaleita taulukossa. Yksi-moneen. 

Tämä suhde on mitä kutsumme monia-moneen. OK? Huomaatte, että toimijat voisivat olla monissa elokuvissa, monet videoita. Joten mitä teemme on laitamme tämä kartoitus sekä kyseisiä, jotka se vain kartat näyttelijä ID videon tunnus. Nyt voin luoda kyselyn liittyy videoita kautta näyttelijä videon toimijoille, ja se antaa minulle mukava luettelo kaikki elokuvat ja kaikki toimijat jotka olivat siinä elokuvassa. 

OK. Joten tässä sitä mennään. Yksi-yhteen on huipputason suhde; yksi-moneen, albumit kappaleita; monet-moneen. Ne ovat kolme huipputason suhteet tahansa tietokantaan. Jos tiedät, miten nämä suhteet toimivat yhdessä, niin tiedät paljon noin tietokanta jo. Joten NoSQL toimii hieman eri tavalla. Ajatellaanpa toista mitä se Näyttää mennä saada kaikki minun tuotteet. 

Vuonna relational myymälä, I haluavat saada kaikki minun tuotteet on luettelo kaikista minun tuotteita. Se on paljon kyselyitä. Sain kyselyn kaikille minun kirjoja. Sain kyselyn minun albumia. Ja sain kyselyn kaikki minun videoita. Ja sain laittaa sen kaikki yhdessä luettelossa ja palvella sitä takaisin jopa sovellus, joka on sitä pyytäville. 

Saan kirjoja, liityn Tuotteet ja kirjat. Saan albumit, sain liittyä Tuotteet, Albumit, ja jälkien. Ja saan videoita, minulla on liittyä Tuotteet videot, liittyä kautta Näyttelijä Videot, ja tuo Näyttelijät. Niin, että kolme kyselyitä. Hyvin monimutkainen kyselyitä koota yksi tulosjoukko. 

Se on vähemmän kuin optimaalinen. Siksi kun puhumme noin tietorakenne, joka on rakennettu mahdollisimman agnostikko pääsy pattern-- hyvin, että on hienoa. Ja voit nähdä tämä on todella mukava miten olemme järjestetty tiedot. Ja tiedätkö mitä? Minulla on vain yksi ennätys näyttelijä. 

Hyvä juttu. Olen deduplicated kaikki minun toimijoita, ja minä säilyttäneet yhdistykset tässä mappaustaulukon. Kuitenkin saada tiedot ulos tulee kalliiksi. Lähetän CPU koko järjestelmän liittymällä nämä tietorakenteita yhdessä pystyä vetämään että tiedot takaisin. 

Joten miten saan noin, että? Vuonna NoSQL se on noin yhdistäminen, ei normalisointi. Joten haluamme sanoa haluamme tukea käyttötapa. Jos käyttötapa sovelluksiin, Minun täytyy saada kaikki minun tuotteet. Laitetaan kaikki tuotteet yhdessä taulukossa. Jos laitan kaikki tuotteita yhteen taulukossa, Voin vain valita kaikki tuotteet tästä taulukosta ja saan kaiken. No miten voin tehdä sen? No NoSQL ei ole rakenne pöytään. Puhutaan hieman siitä miten tämä toimii Dynamo DB. Mutta sinulla ei ole sama ominaisuudet ja samat ominaisuudet jokaisessa rivissä, jokaisessa erä, kuten te tehdä SQL taulukossa. Ja mitä tämä antaa minulle tehdä, on paljon asioita ja antaa minulle paljon joustavuutta. Tässä nimenomaisessa tapauksessa, I minun tuote asiakirjoja. Ja tässä nimenomaisessa Esimerkiksi kaikki on asiakirja Tuotteet taulukossa. Ja tuote kirja pitää on tyyppi tunnus, joka määrittelee kirja. Ja hakemus siirtyvänsä tästä tunnus. 

Sovellustasolla tason, aion sanoa oh, mikä tyyppi on tämä? Voi, se on kirja ennätys. Kirja Records on nämä ominaisuudet. Saanen luoda kirjan objekti. Joten aion täyttää kirja esine tämän kohteen. Esityslistalla tulee ja sanoo, mitä tämän kohteen? No tämä tuote on albumi. Voi, sain kokonaan eri käsittely rutiini, että koska se albumi. Näetkö mitä tarkoitan? 

Joten hakemus tier-- I valitse vain kaikki nämä tiedot. Ne kaikki alkavat tulossa. Ne voisivat olla kaikki erilaisia. Ja se on sovelluksen logiikka että kytkimet yli nämä tyypit ja päättää miten käsitellä niitä. 

Taas, joten olemme optimoimalla skeema käyttötapa. Teemme sen romahtamassa kyseiset taulukot. Olemme periaatteessa ottaen nämä normalisoitu rakenteet, ja me rakennamme hierarkkiset rakenteet. Sisällä jokainen näistä kirjaa Aion nähdä array ominaisuuksia. 

Inside tämä asiakirja Albumit, Näen ryhmät kappaleita. Ne kappaleet nyt become-- se pohjimmiltaan tämä lapsi taulukko että olemassa täällä tässä rakenteessa. Voit siis tehdä tämän DynamoDB. Voit tehdä tämän MongoDB. Voit tehdä tämän missä tahansa NoSQL tietokantaan. Luo nämä tyypit hierarkkinen tietorakenteita joiden avulla voit hakea tietoja hyvin nopeasti, koska nyt olen ei tarvitse noudattaa. Kun asetan rivin osaksi Kappaleet pöytä tai rivi osaksi Albumit pöytä, Minun on noudatettava, että kaava. Minun on ominaisuus tai omaisuus, joka on määritelty kyseisen taulukon. Jokainen heistä, kun asetan että rivin. Se ei tapahtunut NoSQL. 

Voin olla täysin erilainen ominaisuudet jokaisessa asiakirjassa että asetan osaksi kokoelma. Joten erittäin voimakas mekanismi. Ja se on todella miten optimoida järjestelmän. Koska nyt että kysely, sen sijaan liittyä kaikki nämä taulukot ja täytäntöönpanosta puoli tusinaa kyselyt vetäytyä tiedot minä tarvitsen, Olen täytäntöönpanosta yksi kysely. Ja olen iteroimalla poikki tulokset asetettu. se antaa käsityksen voiman NoSQL. Aion eräänlainen mennä sivuttain täällä ja puhua hieman tästä. Tämä on enemmän sellaista markkinointi tai technology-- markkinointi tekniikka tyyppinen keskustelu. Mutta on tärkeää ymmärtää koska jos katsomme alkuun täällä tällä kaavio, mitä me tarkastelemme kutsumme teknologia hype käyrä. Ja mitä tämä tarkoittaa uusia juttuja tulee pelata. Ihmiset ajattelevat, se on hienoa. Olen ratkaista kaikki minun ongelmia. 

Tämä voisi olla lopussa kaikki, on kaikki kaikkeen. Ja he alkavat käyttää sitä. Ja he sanovat, tätä tavaraa ei toimi. Tämä ei ole oikein. Vanhoja juttuja oli parempi. Ja he menevät takaisin tekemään asiat niin kuin ne olivat. Ja sitten lopulta ne menevät, tiedätkö mitä? Tämä tavaraa ei ole niin paha. Voi, että se toimii. Ja kun he selvittää, miten se teoksia, ne alkavat paranemassa. 

Ja hauska juttu siitä on, se tavallaan linjassa mitä kutsumme teknologian käyttöönotto Curve. Mitä tapahtuu on meillä jonkinlainen teknologia laukaista. Kun on kyse tietokannoista, se on tietoja paine. Puhuimme korkea vesipisteitä Tietojen paine koko ajan. Kun tietojen paine osuu tietty kohta, joka on teknologia laukaista. 

Se on tulossa liian kallis. Se kestää liian kauan käsitellä tietoja. Tarvitsemme jotain parempaa. Saat innovaattorit siellä juoksee ympäriinsä, yrittää selvittää, mitä ratkaisu. Mitä uusi idea? 

Mikä on seuraava paras tapa tehdä tämä asia? Ja he keksivät jotain. Ja ihmiset todellista tuskaa, pojat verenvuoto reuna, he hypätä kaikki yli sen, koska he tarvitsevat vastauksen. Nyt mitä väistämättä happens-- ja se tapahtuu juuri nyt NoSQL. Näen sitä koko ajan. 

Mitä väistämättä tapahtuu on ihmiset alkavat käyttää uutta työkalua samalla tavalla kuin käytetään vanha työkalu. Ja he selville sitä ei toimi niin hyvin. En muista kuka olin puhuu aiemmin tänään. Mutta se on kuin, kun jackhammer keksittiin, ihmiset eivät käännä se päätään murskata betoni. 

Mutta se on mitä tapahtuu NoSQL tänään. Jos kävelet sisään useimmat kaupat, he yrittävät olla NoSQL kauppoja. Mitä he tekevät on he käyttävät NoSQL, ja he sen lataamista täynnä relaatio kaava. Koska näin ne suunnittelevat tietokantoja. Ja he ihmettelevät, miksi on se ei toimi kovin hyvin? Poika, tämä asia haisee. Jouduin pitämään kaikki minun liittyy in-- se on kuin, ei, ei. Ylläpitää liittyy? Miksi liittyä tietoja? Sinun ei liity tietoja NoSQL. Voit yhdistää sen. 

Joten jos haluat välttää tämän, oppia miten työkalu toimii ennen kuin itse alkaa käyttää sitä. Älä yritä käyttää uusia välineitä Samoin käytit vanhoja työkaluja. Olet menossa on huonoja kokemuksia. Ja joka ikinen kerta sitähän tämä on noin. Kun me alkaa tulla tänne, se johtuu siitä, ihmiset tajunnut miten käyttää työkaluja. 

He tekivät saman asian, kun relaatiotietokantojen keksittiin, ja ne korvaavat tiedostojärjestelmää. He yrittivät rakentaa tiedostojärjestelmien relaatiotietokantojen koska se mitä ihmiset ymmärtää. Se ei toiminut. Niin ymmärtää parhaita käytäntöjä teknologian olet työskennellyt on valtava. Erittäin tärkeä. 

Joten aiomme päästä DynamoDB. DynamoDB on AWS: n täysin onnistuneet NoSQL alustalla. Mitä täysin onnistuneet tarkoittaa? Se tarkoittaa sinun ei tarvitse todella huolehtia mistään. 

Tulet, kerrot meille, Tarvitsen pöytä. Se tarvitsee näin paljon kapasiteettia. Osut painiketta, ja me säännös kaikki infrastruktuuri takana kohtauksen. Nyt on valtava. 

Koska kun puhut noin skaalaus tietokanta, NoSQL tiedot klustereita mittakaavassa, käynnissä petatavuun, käynnissä miljoonia tapahtumaa sekunnissa, nämä asiat eivät ole pieniä klustereita. Puhumme tuhansia tapauksia. Toimitusjohtaja tuhansia tapauksia, jopa virtuaalinen tapauksissa on todellinen kipu Butt. Tarkoitan, ajattele aina käyttöjärjestelmä laastari tulee ulos tai uuden version tietokannan. Mitä se tarkoittaa sinulle toiminnallisesti? Tämä tarkoittaa sait 1200 palvelimet, jotka on päivitettävä. Nyt jopa automaation, joka voi kestää kauan. Tämä voi aiheuttaa paljon operatiivinen päänsärkyä, koska olisin palvelut alas. 

Kuten olen päivittää nämä tietokannat, I voisi tehdä sininen vihreä käyttöönottoja jossa olen käyttöön ja päivittää puoli minun solmuja, ja päivittää sitten toinen puoli. Ottaa ne alas. Joten hallinnoi infrastruktuuria asteikko on erittäin kivulias. Ja AWS ottaa että kipu irti. Ja NoSQL tietokantoja voi olla erittäin kivulias sillä tavalla he mittakaavassa. 

Mittakaavassa vaakasuunnassa. Jos haluat saada isompi NoSQL tietokanta, ostat enemmän solmuja. Jokainen solmu ostat on toinen operatiivinen päänsärky. Joten anna jonkun muun tehdä sen puolestasi. AWS voi tehdä. 

Tuemme asiakirja keskeisistä arvoista. Nyt ei mene liikaa osaksi toisaalta kaavion. Siellä on paljon erilaisia makuja NoSQL. Ne ovat kaikki tavallaan saada munged yhdessä tässä vaiheessa. Voit tarkastella DynamoDB ja sanoa kyllä, olemme molemmat asiakirja ja keskeinen arvo Säilytä tässä vaiheessa. Ja voit väittää ominaisuudet ja yksi yli muiden. Minulle paljon tämä on todella kuusi Yhden puoli tusinaa muita. Jokainen näistä teknologioista on hieno tekniikka ja hieno ratkaisu. En sanoisi MongoDB on parempi tai huonompi kuin Couch, sitten Cassandra, sitten Dynamo, tai päinvastoin. Tarkoitan, nämä ovat vain vaihtoehtoja. 

Se on nopea ja se on johdonmukainen missä tahansa mittakaavassa. Joten tämä on yksi suurimmista bonuksia saat kanssa AWS. Kanssa DynamoDB on kyky saada alhainen yhden numeron millisekunnin viive milloin tahansa mittakaavassa. Se oli suunnittelu tavoite järjestelmän. Ja meillä on asiakkaita, jotka tekevät miljoonia tapahtumia sekunnissa. 

Nyt menen läpi joitakin näistä käyttää tapauksissa muutaman minuutin täällä. Integroitu pääsy control-- meillä on mitä me kutsumme Identity Access Management, tai IAM. Se leviää kaikissa järjestelmissä, jokainen palvelu, joka AWS tarjoaa. DynamoDB ei ole poikkeus. Voit valvoa pääsyä ja DynamoDB taulukoita. Across kaikki AWS-tilejä määritellään pääsy roolit ja käyttöoikeudet IAM infrastruktuuriin. 

Ja se on keskeinen ja kiinteä osa mitä me kutsumme Tapahtuma Driven Ohjelmointi. Nyt tämä on uusi paradigma. 

Yleisö: Miten korko totta positiivisia verrattuna vääriä negatiivisia teidän kulunvalvontajärjestelmä? RICK Houlihan: True positiivisia vs. vääriä negatiivisia? Yleisö: Palatakseni mitä sinun pitäisi palaamassa? Toisin kuin kerran, kun se ei palaa, kun sen pitäisi vahvistaa? 

RICK Houlihan: En voinut kertoa. Onko siellä mitään epäonnistumisia millään tavoin, että En ole henkilö kysyä että erityisesti kysymys. Mutta se on hyvä kysymys. Olisin utelias tietämään että itse, todella. 

Ja niin sitten taas, uusi paradigma on tapahtuma ajetaan ohjelmointi. Tämä on ajatus, että voit käyttöön monimutkaisia ​​sovelluksia voi toimia hyvin, hyvin suuri mittakaava ilman infrastruktuuria lainkaan. Ilman kiinteää infrastruktuuri mitään. Ja me puhua hieman mitä se tarkoittaa kun me päästä seuraavalle pari kaavioita. 

Ensimmäinen asia teemme on me puhumme taulukoita. API tietotyyppejä Dynamo. Ja ensimmäinen asia, sinun huomaat kun katsot tätä, jos olet perehtynyt tahansa tietokannan, tietokannat ovat todella kaksi sellainen API Olin kutsua sitä. Tai kaksi sarjaa API. Yksi näistä olisi hallinnollisia API. 

Mitä he huolehtivat toiminnot tietokantaan. Määrittäminen säilömoduuli, perustamalla ja lisäämällä pöytiä. luoda tietokanta luetteloita ja tapauksia. Nämä things-- vuonna DynamoDB, sinua on hyvin lyhyt, lyhyt luettelot. 

Eli toisin tietokantoihin, saatat nähdä kymmeniä komentoja, hallinnollisten komentoja, konfigurointiin näitä asetuksia. Vuonna DynamoDB et tarvitse niitä, koska et määritä järjestelmän, teemme. Joten ainoa asia mitä sinun tarvitsee tehdä, on kerro minulle, mitä koko taulukko tarvitsen. Niin saat hyvin rajoitettu sarja komentoja. 

Saat Luo Pöytä Update, taulukko, Poista taulukko, ja Kuvaile taulukossa. Ne ovat ainoat asiat tarvitset DynamoDB. Sinun ei tarvitse varastointi moottorissa. En tarvitse murehtia replikointi. En tarvitse murehtia sharding. 

Minun ei tarvitse huolehtia mitään tätä kamaa. Teemme kaiken puolestasi. Niin, että valtava määrä yläpuolella Se on vain nostaa pois lautasella. Sitten meillä on lika toimijoille. Lika on jotain mitä me soittaa tietokanta, jota on Luo, päivittää, poistaa toimijoille. Nämä ovat yhteisiä tietokannan toiminnan. Asiat kuten laittaa kohteen, saada kohta, päivitys kohteita, poistaa kohteita, erä kyselyn, skannata. Jos haluat skannata koko taulukon. Vedä kaikki pöydältä. Yksi mukavia asioita DynamoDB on se mahdollistaa rinnakkainen skannauksen. Joten voit itse haluaisin tietää, kuinka monta viestiketjut haluat ajaa että skannata. Ja voimme käyttää niitä kierteet. Voimme spin että skannata ylös poikki useita säikeitä joten voit tarkistaa koko taulukon tila hyvin, hyvin nopeasti DynamoDB. 

Muut API meillä on mitä me kutsumme Streams API. Emme aio puhua liian paljon tästä juuri nyt. Minulla jotain sisältöä myöhemmin päälle kannella tästä. Mutta Streams on todella running-- ajattele sitä aika määräsi ja osio muutos loki. Kaiken, mitä tapahtuu taulukossa esitetään ylös virta. 

Jokainen kirjoittaa pöytään näkyy stream. Voit lukea, että virta, ja voit tehdä asioita sen kanssa. Puhutaan mitä tyyppisiä asioita tehdä asioita, kuten replikointi, perustamalla toissijaisia ​​indeksejä. Kaikenlaiset todella cool asioita voit tehdä sen kanssa. 

Tietotyyppejä. Vuonna DynamoDB tuemme molemmat keskeisiä arvo ja asiakirja tietotyyppejä. Vasemmalla laidassa täällä, meillä meidän perustyyppiä. Avain arvotyypeillä. Nämä ovat jouset, numeroita, ja binäärit. 

Joten vain kolme perustyyppiä. Ja sitten voit olla sarjaa näiden. Yksi mukavia asioita NoSQL on voit olla taulukoita kuin ominaisuuksia. Ja DynamoDB voit olla taulukoita perus tyyppejä kuin viitteenä omaisuutta. 

Ja sitten on asiakirjatyyppejä. Kuinka monet ihmiset tuntevat JSON? Te perehtynyt JSON niin paljon? Se on pohjimmiltaan JavaScript, Esine, merkintätapa. Sen avulla voit pohjimmiltaan määritellä hierarkkinen rakenne. 

Voit tallentaa JSON asiakirjan DynamoDB käyttämällä yhteisiä komponentteja tai rakennuspalikoita, jotka ovat käytettävissä Useimmissa ohjelmointikielissä. Joten jos sinulla on Java, olet katsot karttoja ja luetteloita. Voin luoda objekteja alueen kartta. Kartta keskeisinä arvot tallennetaan ominaisuudet. Ja se voisi olla luettelot arvoja nämä ominaisuudet. Voit tallentaa tämän monimutkaisen hierarkkinen rakenne yhtenä ominaisuus of DynamoDB kohteen. 

Joten taulukoita DynamoDB, kuten useimmat NoSQL tietokannat, taulukot ovat kohteita. Vuonna MongoDB olisit kutsuvat näitä asiakirjoja. Ja se olisi sohvalla pohja. Myös asiakirja tietokanta. Soitat nämä asiakirjat. Asiakirjoja tai kohteita on määritteitä. Määritteitä voi olla olemassa tai ei löydy kohteen. Vuonna DynamoDB, siellä yksi pakollisena ominaisuutena. Aivan kuten relaatiotietokanta, käytössä on ensisijainen avain pöydälle. 

DynamoDB on mitä me kutsumme ruutu. Ruutunäppäintä on oltava yksilöllinen. Kun siis määritellä tiiviste, periaatteessa mitä sanon on jokainen erä on ruutu. Ja jokainen ruutu on oltava yksilöllisiä. 

Jokainen erä määritellään tämän ainutlaatuisen ruutu. Ja voi olla vain yksi. Tämä on OK, mutta Usein mitä ihmiset tarvitsevat he haluavat tämä hash avain tehdä vähän enemmän kuin vain olla yksilöllinen tunniste. Usein haluamme käyttää että ruutunäppäintä kuten huipputason yhdistäminen ämpäri. Ja tapamme tehdä se on lisäämällä mitä me kutsumme erilaisia ​​avain. 

Joten jos se on hash vain pöytä, tämä on oltava yksilöllinen. Jos se on hash ja alue pöytä, yhdistelmä hash ja alue on oltava yksilöllinen. Joten ajattele sitä tällä tavalla. Jos minulla on foorumi. Ja muoto on aiheita, se on virkaa, ja se on vastauksia. 

Joten olisin hash avain, joka on aihe tunnus. Ja voisin olla erilaisia ​​avain, joka on vastaus tunnus. Näin jos haluan saada kaikki vastauksia tiettyyn aiheeseen, Voin vain kyselyn hash. Voin vain sanoa antaa minulle kaikki kohteita, jotka ovat tämän hash. Ja aion saada jokaiseen kysymykseen tai lähettää kyseisen aiheen. Nämä huipputason aggregoinneista ovat erittäin tärkeitä. Ne tukevat ensisijainen yhteys kuvio hakemuksen. Yleisesti ottaen tämä on mitä haluamme tehdä. Haluamme, että table-- kun lataat taulukon, haluamme jäsentää tiedot taulukon sisällä siten, että että sovellus voi hyvin nopeasti hakea nämä tulokset. Ja Usein tapa tehdä se on säilyttää nämä kasaumien kuin me aseta tiedot. Periaatteessa olemme levittää tiedot osaksi kirkas ämpäri kuin se tulee. 

Range avaimet sallia me-- hash avaimet on oltava tasa-arvo. Kun minä kyselyn hash, minun on sanottava anna minulle hash, joka vastaa tätä. Kun minä kyselyn alue, I voi sanoa antaa minulle alue että käyttää mitä tahansa rikas operaattori että tuemme. Anna minulle kaikki kohteet hash. Onko se yhtä suuri, suurempi kuin, alle, se alkaa, se välillä näiden kahden arvon? Joten tämäntyyppisiä valikoima kyselyitä että olemme aina kiinnostuneita. Nyt yksi asia tietoja, kun katsot päästä tiedot, kun voit käyttää tietoja, se aina noin yhdistäminen. Kyse on aina kirjaa jotka liittyvät tähän. Anna minulle kaikki täällä that's-- kaikki liiketoimet tämän luottokortilla viimeiseltä kuukaudelta. Se yhdistäminen. 

Lähes kaikki mitä tehdä tietokanta on jonkinlainen aggregaatiota. Niin se voi pystyä määrittelemään nämä kauhat ja antaa sinulle nämä alue määritteet pystyä hakua, ne rikas kyselyt tukea monia, monet, monet sovellus pääsy malleja. 

Joten toinen asia ruutunäppäintä ei se antaa meille mekanismi pystyä laajentamaan data ympärillä. NoSQL tietokannat toimivat parhaiten kun data on tasaisesti jakautunut klusterin. Kuinka monet ihmiset tuntevat kanssa hajautusta algoritmit? Kun sanon hash ja hashing-- koska hajautinalgoritmi on tapa olla kykenevä generoimaan satunnainen arvo tahansa arvosta. Joten tässä tapauksessa, hash-algoritmia otamme on ND 5 perustuva. 

Ja jos minulla on tunnus, ja tämä on minun ruutunäppäintä, minulla on 1, 2, 3. Kun olen suorittanut hash-algoritmia, se tulee tulla takaisin ja sanoa, hyvin 1 vastaa 7B, 2 vastaa 48, 3 vastaa CD. He levisi avainavaruus. Ja miksi teet tämän? Koska se varmistaa, että voin laittaa kirjaa useiden solmut. 

Jos Teen tämän vähitellen, 1, 2, 3. Ja minulla on hash alue, joka käy tässä tapauksessa, pieni hash tilaan, se kulkee 00-FF sitten Records aikovat tulla ja he aikovat mennä 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. Mitä tapahtuu? Joka insertti on menossa samaan solmuun. Näetkö mitä tarkoitan? 

Koska kun minä jakaa tilaa, Ja minä levitin nämä tiedot kaikkialla, ja minä osio, aion sanoa osio 1 on avain tilaa 0-54. Osio 2 on 55-89. Osio 3 on AA-FF. Joten jos käytän lineaarisesti monesko Tunnukset, näet mitä tapahtuu. 1, 2, 3, 4, 5, 6, kaikki tavalla jopa 54. Niin olen mäiske Records järjestelmään, kaikki päätyy menossa yksi solmu. 

Tuo ei ole hyvä. Se antipattern. Vuonna MongoDB heillä on tämä ongelma jos et käytä ruutu. MongoDB antaa sinulle mahdollisuuden ja hajautusta avainarvon. Sinun tulisi aina tehdä, jos käytät monesko hash Näppäile MongoDB, tai voit olla naulaamalla jokainen kirjoittaa yhteen solmuun, ja sinun on rajoittaa sinun kirjoittaa läpijuoksu huonosti. 

Yleisö: Onko se A9 169 desimaalin? 

RICK Houlihan: Joo, se on jonnekin noin siellä. A9, en tiedä. Sinun täytyy saada minun binary desimaaliluvuiksi laskin. Aivoni ei toimi niin. Yleisö: Vain näkäräinen teidän Mongo kommentteja. Joten on esine tunnus, joka tulee natiivisti kanssa Mongo tehdä? RICK Houlihan: Onko se tehdä niin? Jos määrittää sen. Kanssa MongoDB, sinulla on mahdollisuus. Voit specify-- jokaisen asiakirjan MongoDB on oltava alaviiva tunnus. Se ainutlaatuista arvoa. 

Vuonna MongoDB voit määrittää onko hash sitä tai ei. He vain antaa sinulle mahdollisuuden. Jos tiedät, että se on satunnainen, ei ole ongelma. Sinun ei tarvitse tehdä sitä. Jos tiedät, että se ei ole satunnainen, että se on lisäävä, tee hash. 

Nyt asia hajautusta, kun hash value-- ja tämä on miksi hash avaimet ovat aina ainutlaatuinen kyselyitä, koska olen muuttanut arvo, nyt en voi tehdä erilaisia ​​kyselyn. En voi sanoa on tämä välillä tämän tai tuon, koska haja-arvo ei ole menossa olla samantasoinen kuin todellinen arvo. Joten kun hash että avain, se on tasa vain. Tämä on miksi DynamoDB ruutunäppäintä kyselyt ovat aina tasa vain. 

Joten nyt alueella key-- kun lisään, että alue avain, ne alue avain tallentaa kaikki tulevat ja ne saa varastoida samaan osioon. Joten he ovat hyvin nopeasti, helposti haetaan koska tämä on hash, tämä on alue. Ja näet kaiken samalla hash saa säilyttää samaan osioon tilaan. Voit käyttää tätä alue avain auttaa etsi tietosi lähellä sen emoyhtiön. Mitä minä todella tekee täällä? Tämä on yksi moneen. Suhdetta ruutunäppäintä ja alue avain on yksi monista. Voin olla useita hash avaimet. Voin vain olla useita erilaisia avaimet jokaisessa ruutu. 

Hash määrittelee vanhempi, alue määrittää lapset. Voit siis nähdä siellä analoginen täällä välillä relaatio konstrukti ja saman tyyppisiä rakentaa ja NoSQL. Ihmiset puhuvat NoSQL kuten nonrelational. Se ei ole nonrelational. Tiedot on aina suhteita. Nämä suhteet vain mallinnetaan eri tavalla. Puhutaanpa hieman vähän siitä kestävyys. Kun kirjoitat DynamoDB, kirjoittaa ovat aina kolmen tavalla jäljitellä. Eli meillä on kolme AZ: n. AZ: n ovat Saatavuus Zones. Voit ajatella Saatavuus Zone datakeskuksen tai kokoelma datakeskusten. Nämä asiat ovat maantieteellisesti eristetty toisistaan eri vika alueilla, yli eri sähköverkkoihin ja tulva. Vika yhdessä AZ ei ole vie alas toiselle. Ne ovat myös sidoksissa yhdessä pimeä kuitu. Se tukee yhtä osa 1 millisekunnin viive välillä AZS. Joten reaaliaikaista tietoa aliotosten kykenee monen AZS. 

Ja Usein multi AZ käyttöönottoja täyttää korkean käytettävyyden vaatimukset Useimpien yritysten organisaatioissa. Joten DynamoDB on levinnyt yli kolme AZS oletuksena. Olemme vain menossa tietoa kirjoittaa kun kaksi näistä kolmesta solmuja palata ja sanoa, Joo, sain sen. Miksi näin? Koska lukupuolella olemme vain annan teille tiedot takaisin, kun saamme sen kaksi solmua. 

Jos olen jäljittelevän poikki kolme, ja luen kahdesta, Olen aina taattu on ainakin yksi Näiden lukee olla uusimmat kopiota. Se tekee DynamoDB johdonmukainen. Nyt voit kääntyä ne johdonmukaisesti lukee pois. Jolloin aion sanoa, Minä vain lukea yksi solmu. Ja en voi taata se tulee olla uusimmat tiedot. 

Joten jos kirjoitus on tulossa, se ei ole toistettu vielä, aiot saada tämä jäljennös. Se lopulta johdonmukainen lukea. Ja mitä se on on puolet kustannuksista. Joten tämä on jotain ajateltavaa. Kun luet ulos DynamoDB, ja olet perustaa oman lukea kapasiteetti yksiköt, jos valitset lopulta johdonmukainen lukee, se on paljon halvempaa, se on noin puolet kustannuksista. 

Ja niin se säästää rahaa. Mutta se on sinun valintasi. Jos haluat johdonmukainen luku- tai lopulta johdonmukainen lukea. Se on jotain, että voit valita. 

Puhutaanpa indeksit. Niin me mainita, että huipputason yhdistäminen. Meillä hash avaimet, ja meillä valikoima avaimet. Sepä kiva. Ja se on ensisijaisen taulukon, I sai yhden ruutunäppäintä, sain yksi alue avain. 

Mitä se tarkoittaa? Minulla on yksi ominaisuus, että olen voi ajaa rikas kyselyitä. Se on alue avain. Muita ominaisuuksia, että item-- Voin suodattaa nämä määritteet. Mutta en voi tehdä asioita, kuten se alkaa, tai on suurempi kuin. 

Miten teen sen? Luon indeksin. On kahdenlaisia indeksit DynamoDB. Indeksi on todella Toinen näkymä pöydän. Ja paikallinen toissijainen indeksi. 

Ensimmäinen me puhumme. Joten paikalliset kyynärsulat ovat rinnakkain samaan osioon kuin tiedot. Ja sellaisenaan, ne ovat samaan fyysiseen solmuun. Ne ovat mitä me kutsumme johdonmukainen. Merkitys, ne tunnustavat Kirjoita yhdessä pöytä. Kun kirjoittaa tulee, me kirjoittaa hakemiston läpi. Me kirjoittaa ylös pöytään, ja sitten me tunnustaa. Niinpä se on johdonmukainen. Kun kirjoitus on ollut myönsi taulukosta, se on varmaa, että paikallinen toissijainen indeksi on sama näkemys tietojen. Mutta mitä niiden avulla voit tehdä on määritellä vaihtoehtoinen valikoima avaimet. 

Täytyy käyttää samaa hash avain ensisijaisena pöytä, koska ne ovat yhteistyössä sijaitsevat samaan osioon, ja ne ovat johdonmukaisia. Mutta voin luoda indeksi eri valikoima avaimet. Niinpä esimerkiksi, jos olisin valmistaja että oli raaka osia taulukko tulossa. Ja raaka osat tulevat, ja he yhdisteltynä kokoonpano. Ja ehkä siellä muistaa. 

Mitään osaa, joka tehtiin tämän valmistaja tämän päivämäärän jälkeen, Minun täytyy vetää minun linjan. Voin spin indeksi että etsisivät, kokoamiseen mennessä valmistusta kyseisen osan. Joten jos ylätason taulukko oli jo hashed valmistaja, ehkä se järjestettiin osa ID, I voi luoda indeksin pois, että taulukon kuten hajakoodataan valmistajan ja vaihteli päivämäärään valmistuksen. Ja näin voisin sanoa, mitään, on valmistettu näiden päivämäärien, Minun täytyy vetää linjan. Niin, että paikallinen toissijainen indeksi. 

Näiden vaikutuksesta rajoittamalla ruutu tilaa. Koska he yhteistyötä olemassa samalla varastointi solmu, ne rajoittavat ruutunäppäintä tilaa 10 gigatavua. DynamoDB, alle pöydät, tulee osio pöytääsi joka 10 gigatavua. Kun laitat 10 keikoilla tietojen, me mennä [PHH], ja lisäämme uuden solmun. 

Emme jakaa LSI useiden osioita. Me jakaa taulukossa. Mutta emme jakaa LSI. Niin, että jotain tärkeää ymmärtää on jos teet hyvin, erittäin, erittäin suuri koosteita, sitten aiot rajoitettava 10 gigatavua teidän LSI: t. 

Jos näin on, voimme käyttää maailmanlaajuisia secondaries. Global kyynärsulat ovat todella toinen pöytä. Ne ovat olemassa kokonaan pois puoli ensisijainen pöydän. Ja ne mahdollistavat minua löytämään täysin erilainen rakenne. Joten ajattele sitä dataa lisätään kahteen eri taulukoita, jäsennelty kahdella eri tavalla. 

Voin määritellä täysin eri ruutu. Voin määritellä täysin eri alue avain. Ja voin ajaa tätä täysin itsenäisesti. Koska itse asiassa, olen palveluntarjoajan minun lukea kapasiteetti ja kirjoittaa kapasiteetti minun maailmanlaajuinen toissijainen indeksit täysin itsenäisesti minun ensisijainen pöytä. Jos minä määritellä, että indeksi, kerron se kuinka paljon lukea ja kirjoittaa kapasiteetti se aio käyttää. 

Ja joka on erillinen minun ensisijainen taulukosta. Nyt molemmat indeksit avulla voimme ei vain määritellä hash ja alue avaimet, mutta ne auttavat meitä hankkeen lisäarvon. Joten jos haluan lukea pois indeksi, ja haluan saada joitakin joukko tietoja, Minun ei tarvitse mennä takaisin päävalikkoon taulukko saada lisämääreitä. En voi heijastaa näitä ylimääräisiä ominaisuuksia taulukkoon tukea käyttötapa. Tiedän olemme luultavasti joutumassa joitakin todella, really-- päästä rikkaruohot täällä joitakin tätä kamaa. Nyt sain ajelehtia pois tästä. 

Yleisö: [äänetön] --table avain tarkoitti oli hash? Kuvan alkuperäinen hash? Multi-säleet? 

RICK Houlihan: Kyllä. Kyllä. Selitykset pohjimmiltaan viittaa takaisin kohde. Joten indeksi on osoitin takaisin alkuperäiset pöydälle. Nyt voit rakentaa indeksi on vain pöytä avain, ja muita ominaisuuksia. Ja miksi voisin tehdä? No, ehkä minulla on hyvin suuria kohteita. 

Olen todella tarvitsee vain tietää which-- minun käyttötapa voisi sanoa, mitkä kohteet sisältävät tätä omaisuutta? Ei tarvitse palauttaa tuotteen. Minun täytyy vain tietää mitkä kohteet sisältävät sitä. Joten voit rakentaa indeksejä että vain pöydän avain. 

Mutta se lähinnä sitä, mitä indeksi tietokannassa on. Se, että pystyy nopeasti mitkä kirjaa, rivejä, joka kohteita taulukossa on ominaisuudet, Etsin. 

GSIS, joten miten ne toimivat? GSIS pohjimmiltaan ovat asynkroninen. Päivitys tulee taulukko, taulukko on sitten asynkronisesti päivitetään kaikki GSIS. Siksi GSIS ovat lopulta johdonmukainen. 

On tärkeää huomata, että kun olet rakentamassa GSIS, ja ymmärrät luot toinen ulottuvuus aggregation-- Nyt sanokaamme hyvä esimerkki tässä valmistaja. Uskoisin puhunut lääketieteellisen laitteen valmistaja. Lääketieteellisen laitteen valmistajat Usein on sarjoitettu osia. Osat, jotka menevät lonkan kaikki on vähän sarjanumero niitä. Ja ne voivat olla miljoonia ja miljoonia ja miljardeja osat kaikissa laitteissa että ne aluksen. No, ne täytyy yhdistää alle eri mitat, kaikki osat seurakunnassa, kaikki osat, jotka tehtiin tietyllä rataosuudella, kaikki osat, jotka tulivat sisään tietty valmistaja tiettynä päivänä. Ja nämä aggregoinneista joskus päästä ylös miljardeja. 

Joten Työskentelen joidenkin nämä kaverit jotka kärsivät koska he luoda nämä Valtavan aggregoinneista niiden toissijainen indeksit. He saattavat olla raaka osia taulukko, joka tulee hash vain. Jokaisella osalla on yksilöllinen sarjanumero. Käytän järjestysnumero kuin hash. Se on kaunis. Oma raaka tietojen taulukossa on levinnyt kaikkialla avainavaruus. Minun [? kirjoittaa ?] [? nieleminen?] on mahtava. Otan paljon tietoa. Sitten mitä he tekevät on ne luovat GSI. Ja minä sanon, tiedät mitä, minun täytyy nähdä kaikki osat tämän valmistajan. No, yhtäkkiä olen ottaen miljardia rivejä, ja kamaa ne päälle yksi solmu, sillä kun Olen aggregoitua valmistaja tunnus kuten hash, ja osa numero alue, sitten yhtäkkiä olen laskemisesta miljardia osat, mitä tämä valmistaja on antanut minulle. 

Tämä voi aiheuttaa paljon paineita GSI, jälleen, koska olen mäiske yksi solmu. Laitan kaikki nämä insertoituu yksi solmu. Ja se on todellinen ongelmakäyttö tapauksessa. Nyt sain hyvä suunnittelu malli miten voit välttää sen. Ja se on yksi ongelmista että olen aina työskennellä. Mutta mitä tapahtuu, on GSI saattaa ei ole tarpeeksi kirjoittaa kapasiteetti pystyä työntää kaikki rivejä yhden solmun. Ja mitä sitten tapahtuu on ensisijainen, asiakas pöytä, ensisijainen taulukko on kuristettu koska GSI ei voi pysyä. Joten insertti korko pudota ensisijainen taulukko minun GSI yrittää pysyä. 

Selvä, joten GSI: n, LSI: n, joista yksi minun pitäisi käyttää? LSI: n ovat johdonmukaisia. GSI: n on lopulta johdonmukaisia. Jos se on OK, suosittelen GSI, ne ovat paljon joustavampia. LSI: n voidaan mallintaa GSI. Ja jos tiedot koko kohti hash avaimet kokoelma on yli 10 gigatavua, sitten olet menossa haluavat käyttää tätä GSI koska se on vain kova raja. 

Selvä, joten skaalaus. Jaeltavan Dynamo DB, voit CAN säännös [äänetön] läpäisyä pöytään. Meillä on asiakkaita, jotka ovat palveluntarjoajan 60 billion-- tekevät 60000000000 pyyntöjä, säännöllisesti käynnissä yli miljoona pyyntöjä sekunnissa meidän taulukoita. Siellä oikeastaan ​​mitään teoreettinen raja, kuinka paljon ja kuinka nopeasti taulukon voi ajaa Dynamo DB. On joitakin pehmeitä rajoituksia tilisi että panemme siellä niin että et mene hullu. Jos haluat enemmän kuin että ei ole ongelma. Tulet kertoa meille. Me nosta säädintä. 

Jokainen tili on rajoitettu jollain tasolla jokaisessa palvelussa, aivan lepakko joten ihmiset eivät mene hullu saada itsensä vaikeuksiin. No limit kooltaan. Voit laittaa minkä tahansa määrän kohteita pöydälle. Koko erä on rajoitettu 400 kilotavua kullekin, että olisi kohta ei määritteitä. Joten summa kaikki määritteet rajoittuu 400 kilotavua. Ja sitten taas, meillä on että vähän LSI kysymys kanssa 10 gigatavun rajaa kohti hash. Yleisö: Pieni numero, olen puuttuu mitä sanot, että is-- Yleisö: Voi, 400 kilotavun on maksimikoko per tuote. Joten tuotteella on kaikki ominaisuudet. Joten 400 k on yhteensä koko tai esineen, 400 kilotavua. Joten kaikki ominaisuudet Yhdistetyt, kaikki tiedot siinä kaikki nämä määritteet, rullattu ylös koko yhteensä, tällä hetkellä tänään erä raja on 400 k. Joten skaalaus taas, saavutetaan väliseinien. Läpäisykyky palveluntarjoajan pöydässä tasolla. Ja siellä on todella kaksi nuppia. Olemme lukenut kapasiteetti ja kirjoittaa kapasiteetti. 

Joten nämä oikaistaan toisistaan ​​riippumatta. RCU: n toimenpide tiukasti johdonmukainen lukee. OK, joten jos sanot haluan 1000 RCU: n ne ovat tiukasti yhdenmukaisia, ne ovat johdonmukaisia ​​lukee. Jos sanot haluan lopulta johdonmukainen lukee, voit säännös 1000 RCU: n, olet menossa saada 2000 lopulta johdonmukainen lukee. Ja puoli hinta niille lopulta koostuvat lukee. 

Jälleen oikaistu toisistaan ​​riippumatta. Ja he ovat throughput-- Jos kuluttaa 100% lisää RCU, et aio vaikuttaa saatavuus oikeuksistasi. Joten ne ovat täysin toisistaan ​​riippumattomia. Selvä, joten yksi niistä asioista, jotka Mainitsin lyhyesti oli kuristamalla. Kuristus on huono. Kuristus osoittaa huono ei SQL. On asioita, joita voimme tehdä auttaaksemme voit lievittää kuristus että te kokevat. Mutta paras ratkaisu Tähän on ottakaamme katso mitä olet tekemässä, koska siellä anti-malli pelata täällä. 

Nämä asiat, asioita, kuten epätasainen työmäärät, pikanäppäimet, kuuma osioita. Olen lyömällä erityinen avainavaruus hyvin vaikeaa joillekin erityinen syy. Miksi teen tämän? Katsotaanpa sen selville. Olen sekoittamalla hot tiedot kylmällä tiedot. Olen annan taulukot saada valtava, mutta siellä oikeastaan vain osa osajoukko tietojen se on todella mielenkiintoista minulle. Joten lokitietoja, esimerkiksi paljon asiakkaita, he saavat lokitiedot joka päivä. He saivat valtavasti lokitietoja. 

Jos olet juuri polkumyyntiä kaikki, lokin tiedot yhdeksi iso pöytä, ajan että pöytä menee saada massiivinen. Mutta olen todella kiinnostunut vain viimeisten 24 tunnin, viimeisten seitsemän päivän aikana, viimeisten 30 päivän aikana. Riippumatta ikkuna aikaa että olen kiinnostunut näköinen tapahtumaa, joka häiritsee minua, tai Jos mielenkiintoista minulle, se on ainoa ikkuna kerta, tarvitsen. Joten miksi olen laskemisesta 10 vuotta arvoinen lokitietoja taulukossa? Mikä joka aiheuttaa on taulukko fragmentti. 

Se saa valtava. Se alkaa ripustus tuhansien solmujen. Ja koska teidän kapasiteetti on niin pieni, olet todella nopeutta rajoittava kullakin yksi niistä yksittäisten solmujen. Joten aloitetaan tarkastelemalla, miten Emme Roll että pöytä yli. Miten onnistumme että tiedot hieman parempi välttää näitä ongelmia. Ja mitä se näyttää? Tämä on mitä se näyttää. Tämä on mitä huono NoSQL näyttää. 

Sain kuuma tässä avainasemassa. Jos katsot puolella täällä, nämä ovat kaikki minun osioita. Sain 16 osiot täällä tästä nimenomaisesta tietokantaan. Teemme tämän kaiken aikaa. Juoksen tämä asiakkaille kaiken aikaa. Sitä kutsutaan lämmön kartalla. Lämpö kartta kertoo minulle miten olet pääsemästä käsiksi avainta. Ja mitä tämä kertoo minulle on että on olemassa yksi erityisesti hash että tämä kaveri tykkää todella paljon, koska hän on lyömällä sitä todella, todella kovaa. 

Joten sininen on mukavaa. Haluamme sininen. Emme pidä punainen. Redin jossa paine nousee 100%. 100%, nyt aiot olla kuristettu. Joten kun näet kaikki punaiset linjat kuten this-- ja se ei ole vain Dynamo DB-- jokainen NoSQL tietokanta on tämä ongelma. On anti-malleja, jotka voivat ajaa tällaisia ​​ehtoja. Mitä teen, on työtä asiakkaiden kanssa lieventämään näitä ehtoja. 

Ja mitä se näyttää? Ja tämä on saada eniten ulos Dynamo DB läpijuoksu, mutta se on todella tulossa irti NoSQL. Tämä ei rajoitu Dynamo. Tämä on definitely-- I työskenteli ravintolaan Mongo. Olen perehtynyt monet NoSQL alustoilla. Jokainen on tämäntyyppisiä pikanäppäinjoukkoja ongelmia. Saadaksesi kaiken irti mitään NoSQL tietokanta, erityisesti Dynamo DB, haluat luoda taulukoita jossa hash avaintekijä on suuri määrä eri arvoja, korkea mahtavuus. Koska se tarkoittaa Kirjoitan on paljon erilaisia ​​kauhoja. 

Enemmän kauhat olen kirjallisesti, sitä todennäköisemmin Olen levittää että kirjoittaa kuorma tai lukea ladata pois useiden solmut, todennäköisemmin olen olla suurikapasiteettisten pöydälle. Ja sitten haluan arvot pyysi melko tasaisesti ajan mittaan ja yhdenmukaisesti satunnaisesti kuin mahdollista. No, se on aika mielenkiintoista, koska en voi oikeastaan ohjaus kun käyttäjät tulevat. Joten riittää sanoa, jos me levittää asioita poikki avainavaruus, me todennäköisesti paremmassa kunnossa. 

On tietty määrä aikaisesti että et tule pystyä valvontaa. Mutta ne ovat todella kaksi ulottuvuutta, että meillä on, , pääsy tasaisesti leviäminen, aika, pyynnöt saapuvia tasaisin välein ajoissa. Ja jos nämä kaksi edellytykset täyttyvät, niin se mitä se on tulee näyttämään. Tämä on paljon mukavampi. Olemme todella onnellinen täällä. Meillä on hyvin tasainen käyttötapa. Joo, ehkä saat pieni paine aina silloin tällöin, mutta mitään todella liian laaja. Joten se on hämmästyttävää, kuinka monta kertaa, Kun työskentelen asiakkaiden kanssa, että ensin kuvaajan iso punainen baari ja kaikki että ruma keltainen se on koko paikka, me saada tehdä harjoitus jälkeen pari kuukautta uudelleen arkkitehtuuri, he käynnissä täsmälleen sama kuormitusta täsmälleen sama kuorma. Ja tämä on mitä se etsii kuin nyt. Joten mitä saat NoSQL on tiedot skeema, joka on ehdottoman sidottu käyttötapa. 

Ja voit optimoida että tiedot skeema tukea että käyttötapa. Jos et, niin olet menossa nähdä näiden tyyppisiä ongelmia näiden pikanäppäimet. 

Yleisö: No, väistämättä paikoin tulevat olemaan kuumempi kuin toiset. 

RICK Houlihan: Aina. Aina. Joo, tarkoitan on aina a-- ja uudelleen, siellä on jotkut suunnittelumalleja me selviydymme että puhumme miten käsitellä Näiden kookas koosteita. Tarkoitan, sain ne, miten me käsittelemme niitä? Sain aika hyvä käyttötapaus että me puhumme siitä. 

Selvä, joten puhutaanpa noin jotkut asiakkaat nyt. Nämä kaverit ovat AdRoll. En tiedä, jos olet perehtynyt AdRoll. Olet luultavasti nähdä ne paljon selaimen. He ad uudelleen kohdentamista, he suurin mainos uudelleen kohdistaminen liiketoiminnan siellä. Ne yleensä säännöllisesti ajaa yli 60000000000 liiketoimet päivässä. He tekevät yli miljoona tapahtumaa sekunnissa. Heillä melko yksinkertainen pöytä rakenne, vilkkain pöytä. Se on pohjimmiltaan vain ruutunäppäintä on evästeen, alue on väestörakenteen luokka, ja sitten kolmas ominaisuus on pisteet. 

Joten meillä kaikilla on evästeet meidän selaimen nämä kaverit. Ja kun menet osallistuvien kauppias, he pohjimmiltaan pisteet halki eri väestöryhmää. Kun menet verkkosivuilla ja sanot Haluan nähdä tämän ad-- tai pohjimmiltaan et sano that-- mutta kun menet verkkosivuilla he sanovat haluat nähdä tämän mainoksen. Ja he menevät saada että mainos AdRoll. AdRoll näyttää sinut heidän pöytä. Heidän mielestään evästeiden. Mainostajat kertoo heille, haluan jonkun kuka keski-ikäinen, 40-vuotias mies, urheilullinen. Ja ne pisteet sinua niissä väestötiedot ja ne päättää se on hyvä mainos sinulle. 

Nyt heillä SLA kanssa mainontaansa tarjoajat tarjota osa-10 millisekunnin vastaus jokaisesta pyynnöstä. Joten he käyttävät Dynamo DB tähän. He lyövät meitä miljoonaa pyyntöä sekunnissa. He pystyvät tekemään kaikki hakuja, triage kaikki tiedot, ja saada jotka lisäävät linkin takaisin, että mainostajan alle 10 millisekuntia. Se on oikeastaan ​​aika ilmiömäistä täytäntöönpano, että heillä on. 

Nämä kaverit actually-- nämä kaverit. En ole varma, onko se nämä kaverit. Ehkä nämä kaverit. Periaatteessa kertoi us-- ei, en usko, että se oli heille. Mielestäni se oli joku muu. Olin työskennellyt Asiakkaalle, joka kertoi että nyt, että he ovat mennyt Dynamo DB, he menoja enemmän rahaa välipaloja niiden kehitystiimi joka kuukausi kuin he käyttävät niiden tietokannassa. Joten se antaa sinulle Ajatus kustannussäästöjä että voit saada Dynamo DB on valtava. Okei, dropcam on toinen yritys. Nämä kaveri on tavallaan of-- jos luulet Internet asioita, dropcam on pohjimmiltaan internet security video. Voit laittaa kameran siellä. Kamerassa on liiketunnistin. Joku tulee pitkin, laukaisee cue kohta. Kamera alkaa tallentaa jonkin aikaa asti se ei havaitse liikettä enää. Laittaa että video jopa internetissä. 

Dropcam oli yritys, joka on pohjimmiltaan vaihtoi Dynamo DB koska he kokivat valtavia kasvukipuja. Ja mitä he kertoivat meille, yhtäkkiä petatavua dataa. Heillä ei ollut aavistustakaan niiden palvelu olisi niin menestyksekäs. Enemmän ulkomailta video kuin YouTube on mitä nämä kaverit saavat. He käyttävät DynamoDB seurata kaikkia metatiedot kaikista videon avainkohdat. 

Joten heillä on S3 kauhat ne työntää kaikki binary esineitä osaksi. Ja sitten he ovat Dynamo DB Records että kohta ihmiset kuin S3 kolme esinettä. Kun he täytyy tarkastella videon, he etsiä ennätys Dynamo DB. He klikkaa linkkiä. Ne vetää alas videon S3. Niin, että on eräänlainen mitä tämä näyttää. Ja tämä on suoraan niiden joukkue. 

Dynamo DB vähentää niiden toimitusaika video tapahtumia viidestä 10 sekuntia. Heidän vanha ihmissuhteisiin myymälä, ne käytetään täytyy mennä ja toteuttaa useita monimutkaisia ​​kyselyitä kuvan mitkä videot kaatamaan, vähemmän kuin 50 millisekuntia. Joten se on hämmästyttävää, hämmästyttävä kuinka paljon suorituskyky saat kun optimoida ja virität taustalla tietokanta tukea käyttötapa. Halfbrick, nämä kaverit, mitä on se, Fruit Ninja kai on heidän asia. Että kaikki Toimii Dynamo DB. Ja nämä kaverit, he ovat suuri kehitystiimi, suurta kehitystä myymälä. 

Ei hyvä ops joukkue. Heillä ei ollut paljon toiminnan resursseja. Ne kamppailevat yrittää pitää niiden soveltaminen infrastruktuurin ylös ja käynnissä. He tulivat meille. He katsoivat, että Dynamo DB. He sanoivat, että on meille. He rakensivat koko sovellus puitteet sitä. Joitakin todella mukavia kommentteja tiimiltä niiden kyvystä nyt keskittyä rakentamaan peli ja ei ottaa säilyttää infrastruktuuri, joka oli tulossa valtava määrä yläpuolella niiden joukkue. Joten tämä on jotain that-- hyötyä, että saat Dynamo DB. 

Selvä, päästä tietomallinnus täällä. Ja puhuimme vähän tämä yhtä, yksi monista, ja monia monia tyyppi suhteita. Ja miten säilyttää ne, Dynamo. Vuonna Dynamo DB käytämme indeksit, yleisesti ottaen, kiertää tietoja yksi maku toiseen. Hash avaimet, alue avaimet ja indeksit. 

Tässä nimenomaisessa Esimerkiksi useimmat valtiot on luvanvaraista, että vain yksi ajokortti per henkilö. Et voi mennä saada kaksi kuljettajan lisenssit osavaltiossa Boston. En voi tehdä sitä Texasissa. Sellainen tapa se on. Ja niin on DMV, olemme hakuja, me haluavat etsiä ajokortti jonka sosiaaliturvatunnus. Haluan etsiä käyttäjän tiedot kuljettajan ajokortin numero. 

Joten saatamme olla käyttäjän taulukko, on hash näppäintä sarjanumero, tai sosiaaliturvatunnus, ja eri ominaisuuksia määritellään kohteen. Nyt että taulukko I voitaisiin määritellä GSI joka kääntää että noin joka sanoo haluan ruutunäppäintä lisenssiin ja sitten kaikki muut. Nyt jos haluan kyselyn ja löytää lisenssin numero tahansa sosiaalikomitean Henkilötunnus, voin kyselyn päätaulukko. 

Jos haluan kyselyn ja haluan saada sosiaaliturva numero tai muu määritteitä lisenssin numero, voin kyselyn GSI. Tämä malli on, että yksi yhden suhde. Vain hyvin yksinkertainen GSI, flip niitä asioita ympärillä. Nyt puhutaan yhdeltä monelle. Yksi monista on pohjimmiltaan sinun hash alue avain. Jos saamme paljon tämän käyttötapaus on seurata tietoja. Monitor tiedot tulee säännöllisesti väli, kuten internet-asioita. Olemme aina kaikki nämä Records tulossa koko ajan. 

Ja haluan löytää kaikki lukemat välillä tietyn ajan kuluessa. Se on hyvin yleinen kyselyn seurannan infrastruktuuri. Tapa edetä, joka on löytää yksinkertainen taulukon rakenne, yksi pöytä. Minulla laitemittausta taulukko jossa ruutunäppäintä laitteen tunnus. Ja minulla on valikoima näppäintä aikaleiman, tai tässä tapauksessa, eeppinen. Ja joka antaa minulle suorittaa monimutkaisia kyselyitä, että alue avain ja palauttaa nämä tiedot, jotka ovat suhteessa tulosta asettaa, että etsin. Ja se rakentaa että yksi moniin suhde ensisijaiseen taulukkoon käyttäen ruutunäppäintä, alue näppäinrakenne. 

Joten on tavallaan rakennettu osaksi taulukko Dynamo DB. Kun määritän hash ja valikoima t pöytä, olen määritellään yksi moneen. Se on vanhempi-lapsi-suhde. 

Puhutaanpa monista ja monissa suhteissa. Ja tätä erityistä esimerkiksi, uudelleen, aiomme käyttää GSI: n. Ja puhutaanpa pelaamista skenaario, jossa minulla on tietty käyttäjä. Haluan selvittää kaikki pelit, jotka hän rekisteröity tai pelaavat. Ja tietyn peli, I haluavat löytää kaikille käyttäjille. Joten miten voin tehdä sen? Oma käyttäjä Pelipöytä, aion on ruutunäppäintä käyttäjän tunnus ja valikoima keskeinen pelin. 

Joten käyttäjä voi olla useita pelejä. Se on yksi monista suhdetta käyttäjä ja pelejä hän pelaa. Ja sitten GSI, Minä kääntää että noin. Minä Hash peli ja Minä vaihtelevat käyttäjän. Joten jos haluan saada kaikki pelin käyttäjän pelaavat, Minä kyselyn päätaulukko. Jos haluan saada kaikki käyttäjät että pelaavat tietyn pelin, Olen kyselyn GSI. Niin näet, miten teemme tämän? Voit rakentaa nämä GSI: n tukea use case, sovellus, pääsy kuvio, sovellus. 

Jos minun täytyy hakua tämä ulottuvuus, anna haluan luoda indeksin että ulottuvuus. Jos en, en välitä. Ja käytöstä riippuen tapauksessa I ehkä indeksi tai etten tekisi. Jos se on yksinkertainen yksi monista, ensisijainen pöytä on hieno. Jos minun täytyy tehdä nämä monet monet n, tai minun täytyy tehdä yksi niistä, niin ehkä en tarvitse toiseen indeksiin. Joten kaikki riippuu mitä yritän tehdä ja mitä yritän saada päätökseen. 

Todennäköisesti En aio viettää liian paljon aikaa puhumalla asiakirjoja. Tämä saa vähän, luultavasti, syvemmälle kuin meidän mennä. Puhutaanpa hieman noin rikas kysely ilme. Joten Dynamo DB meillä kyky luoda mitä me kutsumme projektio ilmaisuja. Projektio ilmaukset ovat yksinkertaisesti poiminta kenttiä tai arvot että haluat näyttää. OK, joten en tee valinta. Teen kyselyn vastaan ​​Dynamo DB. Ja minä sanon, tiedät mitä, näyttää minulle vain viiden tähden arvosteluja kyseisen tuotteen. Niin, että kaikki mitä haluan nähdä. En halua nähdä kaikki muita ominaisuuksia rivin, Haluan vain nähdä tämän. Se on aivan kuten SQL kun sanoa Valitse tähti tai taulukosta, saat kaiken. Kun sanon valitse nimi pöytä, minulla on vain yksi ominaisuus. Se on samanlaista asia Dynamo DB tai toisen NoSQL tietokantoja. Suodatin ilmaisuja saanen pohjimmiltaan leikata tulos vahvistetaan. Joten teen kyselyn. Kyselyn voi tulla takaisin 500 kohdetta. Mutta Haluan vain kohteita, jotka on ominaisuus, joka kertoo tämän. OK, joten katsotaanpa suodattaa pois ne asiat jotka eivät vastaa kyseisen kyselyn. Joten meillä on suodatin ilmaisuja. 

Suodatin ilmaisut voivat käyttää kaikilla määrite. He eivät pidä valikoima kyselyitä. Nosta kyselyt ovat valikoivia. Suodatin kyselyt vaativat minua menemään saada koko tulokset asetettu ja sitten raivata tietoja en halua. Miksi se on tärkeää? Koska olen lukenut kaiken. Kyselyssä, aion lukea ja se tulee olemaan jättiläinen noin tietoja. Ja sitten aion raivata mitä tarvitsen. Ja jos olen vain erotetaan pari riviä, niin se on OK. Se ei ole niin tehoton. 

Mutta jos luen koko kasa tiedot, vain raivata yhden kohteen, sitten aion olla parempi pois käyttämällä erilaisia ​​kyselyn, koska se on paljon enemmän valikoiva. Se tulee säästää minulta paljon rahaa, koska maksan että lukea. Jos tulokset tulee takaisin cross että lanka saattaa olla pienempi, mutta olen maksaa lukea. Joten ymmärtää, miten saat tiedot. Se on erittäin tärkeää Dynamo DB. 

Ehdollinen ilmaisuja, tämä on mitä voisi kutsua optimistinen lukitus. Päivitys JOS olemassa, tai jos tämä arvo vastaa mitä voin määritellä. Ja vaikka minulla olisi aikaa leima ennätys, voisin lukea tietoja. Voisin muuttaa että tiedot. Voisin mennä kirjoittaa, että tiedot takaisin tietokantaan. Jos joku on muuttanut ennätys, aikaleima saattanut muuttua. Ja sillä tavalla minun ehdollinen päivitys voisi sanoa päivitys jos aikaleima vastaa tämän. Tai päivitys epäonnistuu, koska joku päivitetty ennätys tällä välin. 

Sitähän me kutsumme optimistinen lukitus. Se tarkoittaa, että joku voi tulla ja muuttaa sitä, ja aion havaita se kun menen takaisin kirjoittaa. Ja sitten en voi itse lukea, että tiedot ja sanoa, oi, hän muutti tätä. Minun täytyy selittää, että. Ja voin vaihtaa tietoja minun tallentaa ja soveltaa toisen päivityksen. Voit siis kiinni ne vähitellen päivityksiä, jotka tapahtuvat välillä aika että luet tiedot ja aika saatat kirjoittaa tiedot. 

Yleisö: Ja suodatin ilmaus oikeastaan ​​tarkoittaa ei määrän tai not-- 

[Väliin ÄÄNTÄ] RICK Houlihan: en tahdo saada liikaa tähän. Tämä on varattu avainsana. Punta näkymä on varattu hakusana Dynamo DB. Jokainen tietokanta on oma varattu nimiä kokoelmia ei voi käyttää. Dynamo DB, jos valitset punta edessä tämän, voit määritellä ne nimiä yläpuolelle. Tämä on viitattu arvo. Se on luultavasti ole paras syntaksin on siellä tästä keskustelusta, koska se joutuu joitakin real-- Olisin puhunut lisää siitä syvemmällä tasolla. 

Mutta riittää sanoa, tämä voisi olla kysely skannata jossa he views-- eikä punta näkymät on suurempi kuin 10. Se on numeerinen arvo, kyllä. Jos haluat, voimme puhua että kun keskustelun. Selvä, joten olemme joutumassa joitakin skenaarioita parhaita käytäntöjä minne olemme menossa puhua joitakin apps täällä. Mitkä ovat käytön tapauksissa Dynamo DB. Mitä suunnittelu malleja Dynamo DB. 

Ja ensimmäinen aiomme puhua on internet asioita. Joten saamme paljon of-- luulisin, mikä on it-- yli 50% Liikenteen Internetissä näinä päivinä on todella syntyy koneiden, automatisoidut prosessit, ei ihmisten. Tarkoitan tämä asia tämä asia teillä noin taskussa, miten paljon tietoa, että asia on todella lähettävät noin ilman sinua tietäen se on aivan uskomatonta. Sijaintisi, tiedot kuinka nopeasti olet menossa. Miten luulet Google Maps teoksia kun he kertovat, mitä liikenne on. Se johtuu siitä, on miljoonia ja miljoonat ihmiset ajelemassa puhelimilla, jotka lähettävät tiedot koko paikka koko ajan. Niin yksi niistä asioista noin tämäntyyppisiä tietoja joka tulee, seurata tietojen log tiedot, aikasarjatiedot, on se yleensä vain mielenkiintoinen sillä vähän aikaa. Tuon ajan jälkeen, se on ei niin kiinnostavaa. Joten puhuimme, älä anna Mainituissa taulukoissa kasvaa ilman rajoja. Ideana on, että ehkä minulla 24 tunnin edestä tapahtumien hot taulukossa. Ja että kuuma taulukko tulee olemaan palveluntarjoajan on erittäin korkea, koska se vie paljon tietoa. Se vie paljon tietoa ja luen sitä paljon. Minulla on paljon toimintaa kyselyitä käynnissä vastaan, että tiedot. 

24 tunnin kuluttua, hei, te tiedä mitä, en välitä. Joten ehkä jokainen keskiyöllä roll minun pöytä yli uuteen pöytään ja minä deprovision tässä taulukossa. Ja otan RCU: n ja WCU n alas, koska 24 tuntia myöhemmin Minulla ei ole niin paljon kyselyitä, että tiedot. Joten aion säästää rahaa. Ja ehkä 30 päivää myöhemmin en tarvitse edes välitä siitä kaiken. Voisin ottaa WCU n kaikki alas yksi, koska tiedät mitä, se on koskaan saada kirjoitetaan. Tiedot on 30 päivää vanha. Se ei koskaan muutu. 

Ja se on melkein koskaan saada lukea, joten haluan vain ottaa että RCU alas 10. Ja olen säästää tonni rahaa tähän tiedot, ja vain maksaa hot tiedot. Niin, että tärkeä asia tarkastella klo kun tarkastellaan aikasarjan tulevia tietoja volyymin. Nämä ovat strategioita. Nyt voisin vain antaa sen kaikki mene samaan pöytään ja vain antaa kyseisen taulukon kasvaa. Lopulta, aion katso suorituskykyyn liittyviä ongelmia. Aion on aloitettava arkistoon jotkut tietojen pöydältä, mitä ei. 

Katsotaanpa paljon parempi suunnitella sovellus jotta voit käyttää tällä tavalla oikea. Joten se on vain automaattinen hakemuksessa koodi. Keskiyöllä joka yö se vierii taulukon. Ehkä mitä tarvitsen on liukuva ikkuna 24 tunnin tiedot. Sitten säännöllisesti olen jossa tiedot pöydältä. Olen leikkaus sen Ajastettu tehtävä ja Laitan sen kiinni näistä muissa taulukoissa, mitä tarvitset. Joten jos kaatuessa toimii, se on hienoa. Jos ei, leikkaa se. Mutta katsotaanpa pitää että kuuma tiedot pois kylmä tiedot. Se tulee säästää paljon rahaa ja tehdä taulukoita enemmän suorittamista. Joten seuraava asia niin jutellaan Tietoja on tuote luettelo. Tavaroiden luettelo on melko yleinen käyttötapaus. Tämä on itse asiassa hyvin yleinen malli että näemme eri asioita. Tiedäthän, Twitter Esimerkiksi kuuma visertää. Jokaisella on tulossa ja tarttumalla että titityy. Tavaroiden luettelo, sain myyntiin. Sain kuuma myynti. Sain 70000 pyyntöjä kohden toinen tulossa tuote kuvaus ulos my tuoteluettelo. Näemme tämän vähittäiskaupan toiminta melko vähän. Miten siis käsitellä että? Ei ole mitään keinoa käsitellä että. Kaikki minun käyttäjät haluavat nähdä samoja tietoja. He ovat tulossa, samanaikaisesti. Ja he kaikki tehdä pyyntöjä että samoja tietoja. Tämä antaa minulle että pikanäppäintä, että iso punainen raita minun kaavio että emme pidä. Ja niinhän se näyttää. Joten koko minun avainta Saan kädenvääntöä myyntiin kohteita. Saan mitään missään muualla. 

Miten tämän ongelman lieventämiseksi? No, me lievittää tätä välimuisti. Cache, laitat pohjimmiltaan in-muisti osio edessä tietokantaan. Olemme onnistuneet [Äänetön] välimuisti, miten voi perustaa oman välimuistin, [kuulumaton] välimuisti [? d,?] mitä haluat. Laita että jopa edessä tietokantaan. Ja näin voit tallentaa että tiedot Näistä pikanäppäimet tuohon välimuisti tilaa ja lukea läpi välimuisti. 

Ja sitten irti lukee alkaa etsiä näin. Sain kaikki nämä välimuisti osuu täällä ja sain mitään täällä tapahtuu koska tietokanta istuu takana välimuisti ja lukee koskaan tule läpi. Jos muutan tietoja tietokanta, minun täytyy päivittää välimuistia. Voimme käyttää jotain kuten höyryää tehdä niin. Ja Selitän miten se toimii. Hyvä, messaging. Sähköposti, me kaikki käytämme sähköpostia. 

Tämä on aika hyvä esimerkki. Meillä jonkinlaisen viestejä pöytä. Ja saimme Saapuneet ja Lähtevät. Tämä on mitä SQL olisi näyttävät rakentaa että postilaatikkoon. Olemme tavallaan käyttävät samanlaista Strategian käyttää GSI: n, GSI: n minun Saapuneet ja minun Lähtevät. Joten sain raaka tulevat viestit minun viestejä pöytä. Ja ensimmäinen lähestymistapa tähän voisi olla, sanoa, OK, ei ole ongelma. Minulla raaka viestejä. Tulevat viestit [kuulumaton], Viestin tunnus, se on hienoa. Se on minun ainutlaatuinen hash. Aion luoda kaksi GSI: n, yksi minun postilaatikkoon, yksi minun Lähtevät. Ja ensimmäinen asia teen on Sanon minun ruutunäppäintä on olemaan vastaanottaja ja Aion järjestää mennessä. Tämä on fantastinen. Sain mukava katsella täällä. Mutta on vähän kysymys. Ja olet joutunut tämän relaatiotietokantojen samoin. He kutsuivat pystysuoraan osioinnin. Haluat pitää big data pois vähän tietoa. 

Ja syy miksi koska minun täytyy mennä lukemaan kohteita saada määritteitä. Ja jos elimet ovat kaikki täällä, sitten lukee vain muutamia kohteita jos ruumiin pituus on keskimäärin 256 kilotavua kullekin, matematiikka saa melko ruma. Sano Haluan lukea Daavidin postilaatikkoon. David sähköpostilaatikkoon on 50 kohdetta. Keskimääräinen ja koko on 256 kilotavua. Tässä on minun tulosmuuntokertoimeen sillä RCU: n on neljä kilotavua. 

OK, mennään kanssa lopulta johdonmukainen lukee. Olen edelleen syö 1600 RCU: n vain lukea Daavidin postilaatikkoon. Auts. OK, nyt mietitäänpä miten sovellus toimii. Jos olen sähköpostia sovelluksen ja Etsin minun postilaatikkoon, ja katson ruumista jokaisen viestin, Ei, Etsin yhteenvedot. Etsin vain otsikot. Joten rakentaa taulukon rakenne joka näyttää enemmän kuin että. 

Joten tässä tiedot että minun työnkulun tarpeisiin. Se on minun postilaatikkoon GSI. Se päivämäärä, lähettäjä, aihe, ja sitten viestin tunnus, joka osoittaa takaisin viestien taulukkoon mistä saan kehon. No, nämä olisivat ennätys tunnukset. He kohta takaisin Tuote tunnukset Dynamo DB taulukossa. Jokainen indeksi aina creates-- aina on kohde ID osana of-- että mukana indeksi. 

Selvä. Yleisö: Se kertoo se, jos se on tallennettu? RICK Houlihan: Kyllä, se kertoo exactly-- se on juuri sitä mitä se tekee. Se sanoo tässä on minun uudelleen ennätys. Ja se tulee kohta takaisin minun uudelleen ennätys. Täsmälleen. OK, joten nyt minun postilaatikkoon on todella paljon pienempi. Ja tämä todella tukee työnkulun sähköpostia sovelluksen. Joten minun postilaatikkoon, painan. Menen pitkin ja klikkaan viestin, silloin minun täytyy mennä saada kehon, koska aion mennä eri mieltä. Joten jos ajattelee MVC tyyppi puitteet, malli näkymä-ohjain. 

Malli sisältää tiedot että näkymä tarpeet ja ohjaimen vuorovaikutuksessa. Kun minä muuttaa kehyksen, kun Muutan näkökulmasta, se on OK palata palvelin ja asuttaa malli, koska sitähän käyttäjä odottaa. Kun he vaihtavat näkemyksiä, silloin voimme mennä takaisin tietokantaan. Joten sähköpostia, valitse. Etsin elin. Meno-paluu matka. Mennä saada kehon. 

Luen paljon vähemmän tietoja. Olen vain käsittelyssä elinten David tarvitsee, kun hän tarvitsee niitä. Enkä polttaa 1600 RCU: n vain osoittaa hänen postilaatikkoon. Joten nyt that-- tämä on tapa että LSI tai GSI-- Olen pahoillani, GSI, järjestyisi. Meillä meidän hash vastaanottajan. Meillä alue näppäintä mennessä. Ja meillä ennustetaan määritteet että meidän täytyy vain tukevan näkemystä. 

Me kiertää että Lähtevät. Hash lähettäjä. Ja pohjimmiltaan olemme erittäin mukava, puhdas katsella. Ja se on basically-- me on tämä mukava viestejä taulukko, joka on on levinnyt mukavasti, sillä se on hash vain, hajauttamat viestin tunnus. Ja meillä on kaksi indeksit pyörivät pois kyseisen taulukon. Selvä, joten ajatus tässä ei pitää big data ja tämän pienen tiedot yhdessä. Partition pystysuoraan, osio kyseiset taulukot. Älä lue tietoja sinun ei tarvitse. Hyvä, pelaamista. Me kaikki haluamme pelejä. Ainakin Pidän pelejä sitten. Joten joitakin asioita että me käsitellä, kun ajattelemme pelaamista, eikö? Pelaamista näinä päivinä, erityisesti mobiili pelaamista, on kyse ajattelua. Ja aion kiertää täällä vähän etäämmälle DynamoDB. Aion tuoda jotkut keskustelua noin joitakin muut AWS teknologioita. 

Mutta ajatus siitä pelaaminen on ajatella noin kannalta API, API, jotka ovat, yleisesti ottaen, HTTP ja JSON. Se miten mobiilipelejä sellainen vuorovaikutuksessa niiden takaisin päät. He tekevät JSON lähettämistä. He saavat tietoa, ja se on kaikki, yleisesti ottaen, Nizzassa JSON API. 

Asiat kuten saada ystäviä, saada leaderboard, vaihtaa tietoja, käyttäjien luoman sisällön, työntää takaisin ylös järjestelmään, nämä ovat tyyppisiä asioita että aiomme tehdä. Binary omaisuuden tiedot, nämä tiedot ei ehkä istua tietokantaan. Tämä voi istua esine myymälä, eikö? Mutta tietokanta on menossa päätyvät kertoo järjestelmän, kertoo hakemus minne mennä saada se. Ja väistämättä, moninpeli palvelimet, loppupäätä infrastruktuuri, ja suunniteltu korkean saatavuus ja skaalautuvuutta. Joten nämä ovat asioita, joita me kaikki haluamme vuonna pelaamista infrastruktuuriin tänään. 

Joten katsomaan mitä se näyttää. Sai ydin loppupäätä, hyvin yksinkertainen. Meillä järjestelmä täällä useita saatavuus alueilla. Puhuimme AZS kuin being-- ajatella niistä erillisinä datakeskusten. Enemmän kuin yksi datakeskuksen per AZ, mutta se on OK, ajatelkaa niitä erilliset tiedot keskuksia, jotka ovat maantieteellisesti ja vika eristetty. 

Aiomme olla pari EC2 tapauksissa. Aiomme olla jotkut loppupäätä palvelimelle. Ehkä jos olet perintö arkkitehtuuri, olemme käyttäen mitä kutsumme RDS, relaatiotietokanta palvelut. Voisi olla MSSQL, MySQL, Tai jotain sellaista. Tämä on tapa paljon hakemuksia suunnitellaan tänään. 

No me ehkä halua mennä kanssa tämä on, kun me mittakaavassa ulos. Menemme eteenpäin ja laittaa S3 ämpäri siellä. Ja että S3 ämpäri, palvelemisen sijasta nuo esineitä meidän servers-- voisimme tehdä sen. Voit laittaa kaikki binary esineitä palvelimia ja voit käyttää niitä palvelimen tapauksissa palvelemaan että tiedot ylös. Mutta se on melko kallista. 

Parempi tapa tehdä on mennä eteenpäin ja laittaa ne esineitä S3 ämpäri. S3 on esine arkistot. Se on rakennettu erityisesti palvelevat tämäntyyppisiä asioita. Ja nuo asiakkaat pyytävät suoraan näiden esine kauhat, purkamaan palvelimet. Joten olemme alkaneet mittakaavassa täällä. 

Nyt saimme käyttäjät ympäri maailmaa. Sain käyttäjille. Minun täytyy olla sisältöä paikallisesti lähellä näille käyttäjille, eikö? Olen luonut S3 ämpäri OMA LÄHDE arkistoon. Ja minä edessä että CloudFront jakelu. 

CloudFront on CD ja sisältöä jakeluverkoston. Periaatteessa se vie tietoja, jotka olet määrittänyt ja välimuistit se kaikki Internetissä joten käyttäjät kaikkialla voivat olla erittäin nopea vastaus, kun he pyytävät nämä esineet. 

Joten saat käsityksen. Olet tavallaan hyödyntämällä kaikki näkökohtia AWS täällä saada tämä tehtävä. Ja lopulta, heitämme auto-skaalaus ryhmä. Joten meidän AC2 tapauksissa meidän peli palvelimia, kun ne alkavat saada kiireisempiä ja vilkkaampi ja vilkkaampi, he vain spin toinen Esimerkiksi spin toisessa tapauksessa, spin toisessa tapauksessa. Joten tekniikka AWS on, se avulla voit määrittää parametrit joiden ympärille palvelimet kasvaa. Joten voit olla n palvelimien määrä siellä kulloinkin. Ja jos kuorma menee pois, he kutistua, numero kutistuu. Ja jos kuormitus tulee takaisin, se tulee kasvamaan takaisin ulos, elastisesti. 

Joten tämä näyttää hyvältä. Meillä on paljon EC2 tapauksissa. Voimme laittaa välimuisti edessä tietokantojen, yrittää nopeuttaa tietokantoja. Seuraava paine kohta tyypillisesti ihmiset näkevät on ne mittakaavassa peli käyttäen relaatiotietokantajärjestelmään. Jeez, tietokanta suorituskyky on kauheaa. Miten voimme parantaa sitä? Yritetään laittaa välimuisti edessä että. 

No, välimuisti ei toimi niin suuri peleissä, eikö? Pelejä, kirjoittaminen on tuskallista. Pelit ovat hyvin kirjoittaa raskas. Välimuisti ei toimi, kun olet kirjoittaa raskas koska olet aina sai päivittää välimuistia. Päivität välimuistin, se on merkityksetön on välimuistiin. Se on oikeastaan ​​vain lisätyötä. 

Joten missä mennään täällä? Sinulla iso pullonkaula siellä tietokantaan. Ja paikka mennä ilmeisesti on osiointi. Osiointi ei ole helppo tehdä, kun olet tekemisissä relaatiotietokantojen. Relaatiotietokantojen, olet vastuussa, tehokkaasti, avainavaruus. Sanot käyttäjien välillä ja M täältä, välillä N ja Z sinne. Ja olet kytkentä koko hakemuksen. Joten olet tekemisissä Tämän osion tietolähde. Sinulla on kaupallisen rajoitukset jotka eivät kata osioita. Sinulla kaikenlaisia messiness että olet käsitellään siellä yrittää käsitellä skaalaus ulos ja rakentaa suuremman infrastruktuuri. Se on vain ole hauskaa. 

Yleisö: Joten sinä tarkoitat, että kasvava lähde pistettä nopeuttaa prosessi? RICK Houlihan: lisääminen? Yleisö: Source pistettä. RICK Houlihan: Lähde pistettä? Yleisö: Vuodesta tiedot, jos tieto on peräisin? RICK Houlihan: Ei. Sanon lisääntyy määrä osiot tietovaraston parantaa suorituskykyä. Joten mitä tapahtuu tässä käyttäjät tulossa EC2 Esimerkiksi täällä, hyvin, jos tarvitsen käyttäjä joka on M, menen tänne. N p, menen tänne. P-Z, menen tänne. 

Yleisö: OK, nämä niin ne ovat kaikki tallennetut eri solmuissa? 

RICK Houlihan: Kyllä. Ajattele näitä eri siilot tietojen. Joten sinulla on tehdä tämän. Jos yrität tehdä tämä, jos yrität mittakaavassa on ihmissuhteisiin alustalla, tämä on mitä olet tekemässä. Otatte tiedot ja olet leikkaamalla se alas. Ja olet osiointi se poikki useita esiintymiä tietokannasta. Ja sinä hallitset kaikki, klo sovellus tason. Se ei ole hauskaa. Mitä me haluamme mennä? Haluamme mennä DynamoDB, täysin onnistunut, NoSQL tietovaraston, säännös läpijuoksu. Käytämme toissijainen indeksejä. Se on pohjimmiltaan HTTP API ja dokumenttien tuki. Joten sinun ei tarvitse huolehtia tuosta mitään eristämiseen. Teemme kaiken puolestasi. Joten nyt, sen sijaan, te vain kirjoittaa pöytään. Jos taulukko on osioitu, että tapahtuu kulissien takana. Olet täysin eristetty kyseisestä kehittäjänä. Joten puhua joitakin käyttötapauksia että me törmätä pelaamista, yhteinen pelaamista skenaarioita, leaderboard. Joten sinulla käyttäjiä tulossa, BoardNames että he on, tulokset tälle käyttäjälle. Saatamme hajautusta päälle Käyttäjätunnus, ja sitten meillä on valikoima peliin. Joten jokainen käyttäjä haluaa nähdä kaikki pelissä hän on pelannut ja kaikki hänen huippupisteet kaikissa peli. Niin, että hänen henkilökohtainen leaderboard. 

Nyt haluan mennä ja haluan get-- joten saan nämä henkilökohtaista pistetaulukot. Mitä haluan tehdä on mennä saada huippupisteet kaikkien käyttäjien. Joten miten voin tehdä sen? Kun minun ennätys on hajauttaa päälle Käyttäjätunnus, vaihteli pelin, hyvin aion mennä eteenpäin ja uudelleen, luoda GSI, ja aion uudelleen, että tiedot. 

Nyt aion Hash BoardName, joka on peli. Ja aion Range huippupisteet. Ja nyt olen luonut eri kauhat. Käytän samassa pöydässä, saman kohteen tiedot. Mutta Olen luomassa ämpäri, joka antaa minulle yhdistäminen alkuun pisteet peli. 

Ja voin kyselyn että taulukon saada nämä tiedot. Joten olen asettanut että hakukaavan jopa tuettava toissijainen indeksi. Nyt he voivat järjestellä BoardName ja lajiteltu Topscore riippuen. Voit siis nähdä, nämä ovat tyypit käyttötapauksia saat pelaamista. Toinen hyvä käyttää tapauksessa saamme pelaamista on palkintoja ja kuka voitti palkintoja. Ja tämä on paljon hyötyä asiassa jossa kutsumme harvaa indeksit. Harva indeksit ovat kyky tuottaa indeksi, joka ei välttämättä sisältävät jokainen erä pöydälle. Ja miksi ei? Koska ominaisuus, joka on on indeksoitu ei löydy jokaisen kohteen. 

Joten tässä nimenomaisessa Käytä asia, sanon, Tiedätkö mitä, aion luoda määritteen nimeltä palkinnon. Ja minä aion antaa jokaiselle käyttäjälle että on palkinto, joka määrite. Käyttäjät, joilla ei ole palkinnot ovat aio olla, että ominaisuus. Joten kun luon indeksi, vain käyttäjät jotka ovat menossa näyttämään ylös indeksissä ovat ne, jotka todella ovat voittaneet palkintoja. Niin se on hyvä tapa pystyä luoda suodatettu indeksit ovat hyvin, hyvin valikoiva jotka eivät on indeksoida koko pöydän. 

Joten emme vähissä aikaa täällä. Aion mennä eteenpäin ja ohita ulos ja ohita tämä skenaario. Puhua hieman about-- 

Yleisö: Voinko kysyä nopea kysymys? Yksi on kirjoittaa raskas? RICK Houlihan: Mikä on? Yleisö: Kirjoita raskas. RICK Houlihan: Kirjoita raskas. Anna minun nähdä. 

Yleisö: Vai että ei jotain voit vain ääni muutamassa sekunnissa? RICK Houlihan: Menemme kautta äänestäminen skenaario. Se ei ole niin paha. Onko teillä muutaman minuutin? OK. 

Joten me puhumme äänestykseen. Joten reaaliaikainen äänestyksen, meillä on vaatimukset äänestää. Vaatimukset ovat, että annamme jokainen äänestää vain kerran. Haluamme kukaan pystyä muuttaa äänestää. Haluamme reaaliaikainen yhdistäminen ja Analytics väestötiedot että aiomme olla näytetään käyttäjille sivuston. 

Ajattele tätä skenaariota. Teemme paljon todellisuutta TV-ohjelmia, jos ne ovat teet näitä tarkka tyyppi asioita. Joten voit ajatella skenaario, meillä on miljoonia ja miljoonia teinityttöjen siellä niiden matkapuhelimet ja äänestäminen ja äänestäminen, ja Äänestän keitä he ovat löytää olla suosituin. Joten nämä ovat joitakin vaatimusten me loppuu. 

Ja niin ensin ottaa ratkaisemaan tämän ongelman olisi rakentaa hyvin yksinkertainen sovellus. Joten minulla on tämä app. Minulla on joitakin äänestäjiä siellä. Ne tulevat, ne osuvat äänestys sovelluksen. Minulla joidenkin raaka ääntä taulukko Otan vain dump nämä äänet osaksi. Otan joitakin yhteenlaskettu ääntä taulukko että teen analytiikan ja väestötiedot, ja me laitamme kaikki tämä siellä. 

Ja tämä on suuri. Elämä on hyvää. Elämän hyvä kunnes saamme selville, että siellä on aina vain yksi tai kaksi ihmiset, jotka ovat suosittuja vaaleissa. On vain yksi tai kaksi asiaa että ihmiset oikeasti välitä. Ja jos olet äänestyksestä mittakaavassa, yhtäkkiä olen aiotaan mäiske helvettiin kaksi ehdokasta, yksi tai kaksi ehdokasta. Hyvin rajoitettu määrä kohdetta ihmiset löytävät olla suosittu. 

Tämä ei ole hyvä suunnittelu malli. Tämä on oikeastaan erittäin huono suunnittelu malli koska se luo mitä me puhui joka oli pikanäppäimiä. Pikanäppäimet ovat jotain, josta emme pidä. 

Miten siis korjata sen? Ja todella, tapa korjata tämä on ottamalla ne ehdokas kauhat ja jokaisen ehdokkaan meillä on, aiomme liittää satunnainen arvo, jotain, että me tiedämme, satunnainen arvo välillä yksi ja 100, välillä 100 ja 1000, tai yhdestä 1000, kuitenkin monet satunnainen arvoja haluat liittää päälle päätteeksi, että ehdokas. 

Ja mitä olen todella tehnyt niin? Jos käytän ehdokastunnuksesi kuin ämpäri yhteenlaskettu ääntä, jos Olen lisännyt satunnainen numero loppuun, että Olen luonut nyt 10 kauhat, sata kauhat, tuhat kauhat että olen kokoamiseen ääntä poikki. 

Olen siis miljoonia, ja miljoonat, ja miljoonia levyjä tulossa Näiden ehdokkaiden, olen nyt leviämässä nämä äänet yli Candidate A_1 kautta Ehdokas A_100, koska joka kerta ääni tulee, Olen satunnaisjonon arvo välillä yksi ja 100. Olen tacking se kiinni loppuun ehdokkaan kyseisen henkilön äänestää. Olen polkumyyntiä sen, että ämpäri. 

Nyt takana, tiedän että sain sata kauhat. Joten kun haluan mennä eteenpäin ja yhdistää ääntä, Olen lukenut kaikilta niiltä kauhat. Joten menin eteenpäin ja lisätä. Ja sitten en hajottaa kerätä missä menen ulos ja sanoa hei, Tiedätkö mitä, tämä ehdokkaan avain tilat on yli sata kauhat. Aion koota kaikki ääntä kuin sata kauhat. Aion yhdistää niitä ja aion sanoa, Ehdokas on nyt yhteensä ääntenlaskun x. 

Nyt molemmat Kirjoita kysely ja luetun kysely ovat kauniisti jaettu koska Kirjoitan koko ja luen sadoissa avaimia. En ole kirjallisesti ja käymällä läpi yksi keskeinen nyt. Niin se on hyvä malli. 

Tämä on itse asiassa todennäköisesti yksi tärkeimmistä suunnittelu kaavoja mittakaavassa NoSQL. Näet tämän tyyppisen suunnittelumalli jokaisessa maku. MongoDB, DynamoDB, se ei asia, me kaikki täytyy tehdä tämä. Koska kun olet tekemisissä näitä valtavia koosteita, sinun täytyy keksiä tapa levittää niitä ulos koko kauhat. Joten tämä on niin teet sen. Selvä, niin mitä teet juuri nyt on olet kaupankäynnin pois Lue kustannuksia kirjoittaa skaalautuvuutta. Kustannukset minun lukea on hieman monimutkaisempi ja minun täytyy mennä lukea sata kauhat yhden sijasta. Mutta olen voinut kirjoittaa. Ja minun suoritusteho, minun kirjoittaa läpijuoksu on uskomaton. Niin se on yleensä arvokas tekniikka skaalaus DynamoDB, tai NoSQL tietokanta, että asiassa. Joten me tajunnut, miten mittakaavassa se. Ja me tajunnut, miten eliminoida pikanäppäimet. Ja tämä on fantastinen. Ja saimme tämän mukava järjestelmä. Ja se on antanut meille aivan oikea äänestäminen koska meillä on ennätys äänestys de-huiputtaa. Se on rakennettu DynamoDB. Puhuimme ehdollinen oikeuksista. 

Kun äänestäjä tulee, puts Aseta pöydälle, he lisätä niiden äänestäjien tunnus, jos he yrittävät lisätä uutta äänestystä, En ehdollinen kirjoittaa. Sano vain kirjoittaa tämä jos tämä ei ole olemassa. Niin heti kun näen, että että äänestys on osuma pöytä, kukaan muu tulee olemaan voi laittaa äänioikeuttaan. Ja se on fantastinen. Ja me monesko meidän ehdokas laskurit. Ja me teemme väestötiedot ja kaikki. Mutta mitä tapahtuu, jos sovellus kaatuu? Nyt yhtäkkiä ääniä ovat tulossa, ja minä tiedä jos he saavat jalostettu minun analytiikan ja väestötiedot enää. Ja kun sovellus tulee takaisin ylös, miten helvetti tiedän mitä ääntä on käsitelty ja missä voin aloittaa? 

Joten tämä on todellinen ongelma, kun alkaa tarkastella kuvaillut tapaukset. Ja miten me ratkaista sen? Ratkaisemme sen mitä me soittaa DynamoDB Streams. Streams on aika tilata ja osioitu muutos loki jokaisen pääsy pöytään, joka kirjoittaa pääsy taulukkoon. Tietoja, jotka on kirjoitettu taulukossa esitetään ylös virta. 

Se on pohjimmiltaan 24 tunnin jono. Kohdetta osuma virta, he elävät 24 tuntia. Ne voidaan lukea useita kertoja. Taattu toimitetaan vain kerran virta, voidaan lukea n määrän kertoja. Niin kuitenkin monet prosessit haluat kuluttaa että tiedot, voit kuluttaa sitä. Se näkyy jokaisen päivityksen. Jokainen kirjoittamasi vain näkyvät kerran virta. Joten sinun ei tarvitse huolehtia noin sen käsittelyn kahdesti samasta prosessi. 

Se on ehdottomasti tilata per tuote. Kun sanomme aika tilasi ja osioitu, näet kohden osio virta. Näet kohdat, päivitykset järjestyksessä. Emme takaa stream että olet menossa jokainen tapahtuma järjestyksessä poikki kohteita. 

Joten purot ovat idempotentti. Älä me kaikki tiedämme, mitä idempotentti tarkoittaa? Idempotentti tarkoittaa, että voit tehdä sen yli, ja yli, ja uudestaan. Tulos tulee olemaan sama. 

Purot ovat idempotentti, mutta niiden on oltava Päivämäärä lähtöpisteestä, minne haluat, loppuun, tai ne eivät aiheuta samassa arvot. 

Sama juttu MongoDB. MongoDB on konstrukti he kutsuvat oplog. Se on täsmälleen sama konstruktin. Monet NoSQL tietokannat on tämä rakenne. He käyttävät sitä tehdä asioita kuten replikointi, joka Juuri teemme puroihin. Yleisö: Ehkä harhaoppisia kysymys, mutta te puhua sovellukset tekevät alas niin edelleen. Ovat purot taatusti koskaan mahdollisesti mennä alas? RICK Houlihan: Joo, purot ovat taatusti koskaan mennä alas. Onnistumme infrastruktuuri takana. virrat automaattisesti käyttöön niiden automaattinen skaalaus ryhmä. Menemme läpi hieman vähän siitä, mitä tapahtuu. 

Minun ei pitäisi sanoa ne eivät ole taatusti koskaan mennä alas. Elementit taataan näkyvän virta. Ja virta tulee saataville. Joten mikä menee alas tai tulee takaisin ylös, että tapahtuu alla. Se covers-- se on OK. Selvä, niin saat eri näkymä tyypit pois ruudulta. Näkymä tyypit, jotka ovat tärkeitä ohjelmoija tyypillisesti ovat, mitä se oli? Saan vanhan mieltä. Kun päivitys osuu pöytään, se tulee työnnä vanha näkymä stream joten tiedot voidaan arkistoida, tai muutos ohjaus, muutos tunnistaminen, muutos hallinta. 

Uusi kuva, mitä se on nyt jälkeen päivitys, se on toinen tyyppi näkymä voit saada. Voit saada sekä vanhan ja uusia kuvia. Ehkä haluan heidät molemmat. Haluan nähdä, mitä se oli. Haluan nähdä, mitä se muuttui. 

Minulla noudattamista tyyppi prosessin, joka toimii. Sen on varmistaa, että kun nämä asiat muuttuvat, että he tietyissä rajoissa tai tiettyjen parametrien. 

Ja sitten ehkä minä vain täytyy tietää, mitä muuttunut. En välitä, mitä kohde muuttunut. En tarvitse tarvitse tietää mitä ominaisuuksia muuttuneen. Haluan vain tietää, että kohteet kosketetaan. Joten nämä ovat eri näkemyksiä että saat pois virta ja voit olla vuorovaikutuksessa. 

Sovellus kuluttaa virta, tämä on sellainen tapa, jolla tämä toimii. DynamoDB asiakas pyytää työntää dataa taulukoihin. Streams käyttöön mitä kutsumme sirpaleiksi. Sirpaleiksi skaalataan riippumatta taulukon. Ne eivät ole kohdallaan täysin seinäjakoon oman pöydän. Ja syy miksi koska ne riviin kapasiteetin, nykyinen kapasiteetti taulukon. 

Ne käyttöön niiden oma auto skaalaus ryhmä, ja he alkavat venyttää riippuen kuinka monta kirjoituksia on tulossa, kuinka monta reads-- todella se kirjoittaa. Ei ole reads-- mutta miten monet kirjoituksia ovat tulossa. 

Ja sitten takaisin Lopulta meillä on mitä me soittaa KCL, tai Kinesis Client Library. Kinesis on virta tiedot teknologiaan Amazon. Ja purot on rakennettu, että. 

Joten käytät KCL käytössä sovelluksen lukea stream. Kinesis Client Library todella hallinnoi työntekijöiden sinulle. Ja se tekee myös joitakin mielenkiintoisia asioita. Se luo joitakin taulukoita ylös teidän DynamoDB tablespace seurata, mitkä kohteet on käsitelty. Joten tällä tavalla, jos se putoaa takaisin, jos se kaatuu ja tulee ja saa nousi takaisin ylös, se voi määrittää, missä oli se käsittelystä virta. 

Se on erittäin tärkeää, kun puhut replikointi. Minun täytyy tietää, mitä Aineisto on käsitelty ja mitä tietoja on vielä käsiteltävä. Joten KCL kirjasto virtojen antaa sinulle paljon, että toiminnallisuus. Se huolehtii kaikista taloudenhoito. Se kestää työntekijä jokaiselle Shard. Se luo hallinnollinen taulukko jokaista sirpale, jokaiselle työntekijälle. Ja kun näiden työntekijöiden tulipalo, ne säilyttää nämä taulukot niin tiedät tämä ennätys luettiin ja käsitelty. Ja sitten, että tavalla, jos prosessi kuolee ja tulee takaisin verkossa, se voi jatkaa siellä missä se lähti. 

Joten käytämme tätä varten rajat alue replikointi. Paljon asiakkaita on tarve siirtää tietoja tai osissa taulukot ympäri eri alueille. On yhdeksän aluetta ympäri maailmaa. Joten saattaa olla need-- I voisi olla käyttäjien Aasiassa, käyttäjät itärannikolla Yhdysvalloissa. Niillä on eri tietoja, on paikallisesti hajautettu. Ja ehkä käyttäjän lentää Aasia yli Yhdysvaltoihin, ja haluan jäljitellä hänen tietoja hänen kanssaan. Joten kun hän saa ulos lentokoneesta, hänellä on hyvä kokemus käyttää hänen mobiilisovelluksen. 

Voit käyttää rajat alue replikointi kirjasto tehdä tämän. Periaatteessa meillä on jos kaksi teknologiaa. Yksi on konsoli sovellus voit seisomaan oman EC2 oikeusasteessa. Se toimii puhdas replikointi. Ja sitten me annoimme teille kirjasto. Kirjasto voit rakentaa oman sovelluksen, jos haluavat tehdä hulluja asioita, että data-- suodatin, jäljitellä vain osa sitä, kiertää tietoja, siirtää sen eri taulukossa, niin edelleen ja niin edelleen. Niin, että sellainen mitä se näyttää. 

DynamoDB Streams voi olla käsitellään mitä kutsumme Lambda. Mainitsimme hieman siitä tapahtumasta ajettu sovellus arkkitehtuurit. Lambda on keskeinen osa tätä. Lambda on koodi, että tulipalot kysyntään vastauksena tietyn tapahtuman. Yksi näistä tapahtumista voisi olla ennätys näkymisen virta. Jos ennätys tulee virta, me kutsumme tätä Java toiminto. No, tämä on Javascript ja Lambda tukee Node.js, Java, Python, ja pian tukea muilla kielillä. Ja riittää sanoa, se on puhdasta koodia. kirjoittaa Javassa voit määrittää luokan. Painat JAR ylös Lambda. Ja sitten voit määrittää, mihin luokkaan soittaa vastauksena missä tapauksessa. Ja sitten Lambda infrastruktuuri takana joka jatkuu että koodia. 

Tämä koodi voi käsitellä Records pois virta. Se voi tehdä mitään, se haluaa sen kanssa. Tässä nimenomaisessa esimerkissä, kaikki olemme todella tekee kirjautuu ominaisuuksia. Mutta tämä on vain koodi. Koodi voi tehdä mitään, eikö? 

Joten voit kääntää, että tiedot. Voit luoda johdannainen näkymä. Jos se on asiakirja rakenne, voit litistää rakenne. Voit luoda vaihtoehtoisia indeksejä. Kaikenlaista voit tehdä DynamoDB Streams. 

Ja todella, että mitä se näyttää. Joten saat päivitykset tulossa. He tulevat pois merkkijono. He lukea Lambda-toiminto. He pyörivät tiedot ja työntämällä sitä ylös johdannainen taulukoita, Ilmoituksen ulkoisten järjestelmien muutoksen, ja työntää dataa ElastiCache. 

Puhuimme siitä, miten laittaa välimuisti edessä tietokannan että myynti skenaario. No mitä tapahtuu, jos päivittää kohteen kuvaus? No, jos olisin Lambda toiminto käynnissä että pöytä, jos päivitän kohteen kuvaus, se tulee poimia ennätys pois virta, ja se tulee päivittää ElastiCache Esimerkiksi uusilla tiedoilla. Niin, että on paljon mitä teemme Lambda. Se on liima koodi, liittimet. Ja se itse asiassa antaa kyky käynnistää ja ajaa erittäin monimutkaisia ​​sovelluksia ilman oma palvelin infrastruktuuri, joka on todella siistiä. 

Joten mennään takaisin meidän reaaliaikainen äänestyksen arkkitehtuuri. Tämä on uusi ja parannettu kanssa purojen ja KCL käytössä sovellus. Sama kuin ennen, voimme käsitellä mitä tahansa asteikolla vaaleissa. Haluamme tätä. Teemme ulos hajottaa kerää useiden kauhat. Meillä optimistinen lukitus tapahtuu. Voimme pitää äänestäjät muuttamasta niiden ääntä. He voivat vain äänestää vain kerran. Tämä on fantastinen. Reaaliaikainen vikasietoisuus, skaalautuva yhdistäminen nyt. Jos asia kaatuu, se tietää mistä käynnistää itsensä kun se tulee takaisin ylös, koska käytämme KCL sovelluksen. Ja voimme myös käyttää sitä KCL sovellus työntää dataa ulos että punasiirtymä muita app analytics, tai käyttö Elastinen MapReduce ajaa reaaliaikainen streaming aggregoinneista pois näistä tiedoista. 

Nämä ovat siis asioita ole puhuneet paljon. Mutta ne ovat täydentäviä teknologioita, jotka tulevat kantamaan kun etsit klo tämäntyyppisiä skenaarioita. 

Selvä, niin se on noin Analyticsin ja DynamoDB Streams. Voit kerätä de-huiputtaa tietoja, tehdä kaikenlaisia on kivaa, yhteenlaskettu tiedot muisti, luoda nämä johdannainen taulukoita. Se on valtava käyttötapaus että paljon asiakkaita ovat mukana, kun sisäkkäisiä ominaisuudet, jotka JSON asiakirjojen ja luoda uusia hakemistoja. 

Olemme lopussa. Kiitos laakerin kanssani. Joten puhua viittaus arkkitehtuuri. DynamoDB istuu keskellä niin paljon AWS infrastruktuurin. Periaatteessa voit liittää sen jopa mitä haluat. Sovellusten rakennettu Dynamo kuuluvat Lambda, ElastiCache, CloudSearch, työntää tiedot ulos Elastinen MapReduce, tuonti vienti DynamoDB osaksi S3, kaikenlaisia ​​työnkulkuja. Mutta luultavasti paras asia puhua, ja tämä on mitä todella kiinnostavaa on, kun me puhua tapahtuma perustuvia sovelluksia. 

Tämä on esimerkki sisäinen projekti että meillä on missä olemme todella julkaisu kerätä kyselyn tuloksiin. Joten sähköpostilinkkiä, että lähetämme, siellä tulee olla hieman linkki sanonta klikkauksella täällä vastaamaan kyselyyn. Ja kun henkilö napsauttaa että linkki, mitä tapahtuu on ne vetää alas turvallinen HTML kyselykaavake S3. Ei ole palvelinta. Tämä on vain S3 objekti. 

Tämä lomake tulee esiin, lataa ylös selaimessa. Se sai selkäranka. Se sai monimutkainen JavaScript että se on käynnissä. Joten se on hyvin rikas sovellus käynnissä asiakkaan selaimen. He eivät tiedä, että he eivät vuorovaikutuksessa takaisin end-palvelin. Tässä vaiheessa, se on kaikki selaimen. 

Ne julkaisevat tulokset mitä kutsumme Amazonin API Gateway. API Gateway on yksinkertaisesti web API että voit määrittää ja kytkeä ja mitä haluat. Tässä nimenomaisessa tapauksessa olemme koukussa jopa Lambda toiminto. 

Joten POST toiminta on tapahtuu ilman palvelinta. Pohjimmiltaan että API Gateway istuu siellä. Se maksaa minulle mitään ennen ihmiset alkaa julkaista sitä, eikö? Lambda-toiminto vain istuu. Ja se maksaa minulle mitään ennen ihmiset alkavat lyömällä sitä. Voit siis nähdä, koska äänenvoimakkuus kasvaa, silloin maksut tulevat. Minulla ei ole palvelinta 7/24. 

Joten vedän muodossa alas ämpäri, ja olen lähettänyt API: n kautta Portti Lambda-toiminto. Ja sitten Lambda toiminto sanoo, tiedät mitä, minulla joitakin PIIs, jotkut henkilökohtaisia ​​tietoja näissä vastauksissa. Sain kommentit tulevat käyttäjät. Minulla sähköpostiosoitteita. Minulla käyttäjätunnukset. 

Saanen jakaa tämän pois. Aion tuottaa noin metatiedot pois tämä ennätys. Ja aion työntää metadatan DynamoDB. Ja voisin salata kaikki tiedot ja työnnä se DynamoDB jos haluan. Mutta se on helpompaa minulle, tässä Käytä asia, mennä eteenpäin sanoa, Aion työntää raakadatan osaksi salattu S3 ämpäri. Joten käytän rakennettu S3 palvelimen puolella salaus ja Amazonin Key Management Palvelua niin, että minulla on avain, voi pyöriä säännöllisin väliajoin, ja voin suojata että PII tiedot Osana tätä koko työnkulun. 

Joten mitä minä olen tehnyt? Olen juuri käyttöön koko sovellus, ja minulla ei ole palvelinta. Joten on mitä ylläpitäjä hakemus arkkitehtuuri tekee sinulle. 

Nyt jos ajattelee käytön tapauksessa this-- meillä on muita asiakkaita puhun noin juuri tämän arkkitehtuurin, joka ajaa ilmiömäisen suuri kampanjoita, jotka etsivät tätä ja menee, oh my. Koska nyt, he voivat pohjimmiltaan työnnä se siellä, anna että kampanja vain istua siellä kunnes se käynnistyy, eikä tarvitse huolehtia viikuna noin minkälainen infrastruktuuri tulee olemaan siellä tukea sitä. Ja sitten heti että kampanja on tehty, se on kuin infrastruktuuri vain välittömästi menee pois koska siellä todella ole infrastruktuuria. Se on vain koodi, joka istuu Lambda. Se on vain tietoja, joka istuu DynamoDB. Se on hämmästyttävä tapa rakentaa sovelluksia. 

Yleisö: Onko siis enemmän hetkellistä kuin se olisi jos se on tallennettu todellinen palvelin? 

RICK Houlihan: Ehdottomasti. Koska että Server-esiintymä pitäisi olla 7/24. Sen täytyy olla käytettävissä joku vastata. No arvaa mitä? S3 on käytettävissä 7/24. S3 aina vastaa. Ja S3 on erittäin, erittäin hyvä klo palvelevat esineitä. Nämä esineet voivat olla HTML-tiedostoja, tai JavaScript-tiedostot, tai mitä haluat. Voit ajaa hyvin rikas web-sovellusten ulos S3 kauhat, ja ihmiset tekevät. 

Ja niin se on ajatus täällä on päästä pois tieltä meillä oli tapana ajatella sitä. Me kaikki tapana ajatella vuonna ehdot palvelimia ja isäntien. Kyse ei ole siitä enää. Kyse infrastruktuuria koodi. Käyttöön koodin pilvi ja anna pilvi ajaa sen sinulle. Ja se mitä AWS yrittää tehdä. 

Yleisö: Joten kulta laatikko keskellä API Gateway ei ole palvelin kaltainen, mutta sen sijaan on just-- 

RICK Houlihan: Voit ajatella IT palvelinten julkisivu. Kaikki se on se otan HTTP pyytää ja kartta sen toiseen prosessiin. Siinä kaikki se tekee. Ja tässä tapauksessa, olemme kartoitus se Lambda toiminnon. Hyvä, että on kaikki mitä minulla. Kiitos paljon. Minä arvostan sitä. Tiedän haluamme hieman ajan mittaan. Ja toivottavasti te saanut hieman tietoa että voit ottaa pois tänään. Ja pyydän anteeksi, jos menin yli joitakin päänne, mutta siellä on hyvä paljon perusoikeuksien perustava tieto mielestäni on erittäin arvokas sinulle. Joten kiitos siitä minulle. [SUOSIONOSOITUKSET] Yleisö: [äänetön] on kun sanoitte sinun piti mennä läpi asia alusta loppuun saada oikeita arvoja tai samat arvot, miten olisi arvot muuttua, jos [kuultavissa]. 

RICK Houlihan: Ai, idempotentti? Miten arvot muuttuvat? No, koska jos en suorita se aina loppuun, sitten en tiedä, mitä muutoksia tehtiin viimeisen mailin. Se ei tule olemaan samat tiedot kuin mitä olen nähnyt. Yleisö: Voi, niin sinä vain ole saanut koko panos. RICK Houlihan: Oikea. Sinun täytyy mennä alusta loppuun, ja sitten se on olemaan johdonmukainen valtio. Viileä. 

Yleisö: Joten näytti meille DynamoDB voi tehdä asiakirjan tai keskeinen arvo. Ja vietimme paljon aikaa avain arvo hash ja tapoja käännä se ympäri. Kun katsoin noita pöytiä, että jättäen jälkeensä asiakirjan lähestymistapa? 

RICK Houlihan: en halua sanoa jättää taakse. 

Yleisö: He erotettiin the-- 

RICK Houlihan: Kun asiakirja lähestymistapa, asiakirja kirjoita DynamoDB on ajatelkaa kuin toinen määrite. Se on ominaisuus, joka sisältää hierarkkinen tietorakenne. Ja sitten kyselyt, voit käyttää ominaisuuksia Näiden esineiden Object Notation. Voin siis suodattaa sisäkkäisiä omaisuutta JSON asiakirjan. Yleisö: Joten tahansa I do asiakirja lähestymistapa, Voin tavallaan saapua tabular-- Yleisö: Ehdottomasti. Yleisö: --indexes ja asiat juuri puhui. RICK Houlihan: Joo, indeksit ja kaikki, kun haluat indeksoida ominaisuudet JSON, siten, että meillä olisi tehdä se on jos lisäät JSON esine tai asiakirja osaksi Dynamo, voit käyttää puroihin. Virrat lukisi panos. Voit saada että JSON objekti ja sanoisit OK, mitä omaisuus haluan indeksi? 

Luot johdannainen pöytä. Nyt se on, miten se toimii nyt. Emme salli indeksoida suoraan nämä ominaisuudet. 

Yleisö: Tabularizing dokumentteja. 

RICK Houlihan: Aivan, madaltuminen se, tabularizing se, tarkalleen. Se mitä sinä tekisit. 

Yleisö: Kiitos. 

RICK Houlihan: Jep, ehdottomasti, kiitos. Yleisö: Joten se on eräänlainen Mongo täyttää Redis classifers. 

RICK Houlihan: Joo, se on paljon sellaista. Se on hyvä kuvaus siitä. Viileä.