[Glazbom] RICK Houlihan: U redu. Bok svima. Moje ime je Rick Houlihan. Ja sam viši ravnatelj Rješenja arhitekt na AWS. Ja se fokusirati na NoSQL i DynamoDB tehnologije. Ja sam danas ovdje razgovarati vi malo o onima. 

Moja pozadina prvenstveno u sloju podataka. Proveo sam pola mog razvoj karijeru pisanja podataka, pristupne podatke, rješenja za različite primjene. Ja sam bio u Cloud virtualizacije za oko 20 godina. Dakle, prije nego što je oblak bio oblak, koristili smo pozvati ga program računalstvo. A ideja je, to je kao PG & E, plaćate za ono što koristite. Danas mi to zovemo oblak. 

No, tijekom godina, ja sam radio za par tvrtki vjerojatno ste nikada nije čuo. Ali ja sam sastavio popis tehničkih postignuća, mislim da bih. Imam osam patenata u cloud sustavima virtualizacije, mikroprocesor dizajn, Kompleks obrada događaja, i drugim područjima, kao dobro. 

Tako ovih dana, sam se fokusirati uglavnom na NoSQL tehnologije i sljedeće generacije baza podataka. I to je uglavnom ono što ću biti ovdje razgovarati s vama danas o tome. Dakle, što možete očekivati iz ove sjednice, ćemo proći kroz kratko Povijest obrade podataka. To je uvijek korisno razumijem odakle smo došli i zašto smo gdje smo. A mi ćemo govoriti malo malo o NoSQL tehnologije od temeljnog stajališta. 

Mi ćemo se u neki od su DynamoDB unutarnji. DynamoDB je AWS-a nema okus. To je u potpunosti uspio i domaćin NoSQL rješenje. A mi ćemo govoriti malo o stol struktura, API, vrste podataka, indekse, i neke unutarnji te DynamoDB tehnologije. Mi ćemo ući u neke od dizajna obrasce i najbolje prakse. Razgovarat ćemo o tome kako koristiti ovu tehnologiju za neke današnjih aplikacija. A onda ćemo razgovarati malo o evoluciji ili pojave nove paradigme u programiranju zovu aplikacije događaj-driven i kako DynamoDB igra u tome što je dobro. A mi ćemo vam ostaviti malo rasprava referentna arhitektura tako da možemo govoriti o nekim od načina na koje možete koristiti DynamoDB. 

Dakle, prvi off-- to je pitanje Čujem puno je, što je baza podataka. Puno ljudi misli da znate što je baza podataka. Ako Google, vidjet ćete to. To je a a strukturiran skup podataka održan u računalu, posebno onaj koji je dostupan na različite načine. Pretpostavljam da je to dobra definicija modernog baze podataka. Ali ja to ne sviđa, jer ona podrazumijeva nekoliko stvari. To podrazumijeva strukturu. I to znači da je na računalu. I baze podataka nije Uvijek postoje na računalima. Baze zapravo postojala na mnogo načina. 

Dakle bolji definicija Baza je nešto ovako. Baza podataka je organizirana Mehanizam za pohranu, upravljanje, i dohvaćanje informacija. Ovo je iz About.com. Tako sam to želio, jer stvarno razgovori O baze podataka kao spremište, repozitorij informacije, ne nužno nešto što sjedi na računalu. I kroz povijest, mi nisu uvijek imali računala. 

Sada, ako sam pitati prosjek razvijen je danas ono što je baza podataka, to je odgovor koji sam mogao. Negdje sam može držati stvari. Pravo? I to je istina. Ali to je nesretna. Budući da je baza stvarno temelj moderne aplikacije. To je temelj svakog aplikacija. A kako ste izgraditi da baze podataka, kako se struktura da su podaci će diktirati kako da Zahtjev obavlja kao što skala. 

Dakle, puno posla danas moj se bavi s onim što se događa kada programeri se ovaj pristup i koji se bave posljedicama od zahtjeva da sada skaliranje izvan izvornik Namjera i pate od lošeg dizajna. Dakle, nadamo se, kada vas hoda danas, vi ćete ima par alata u pojasa koji će vas držati od izrade te iste pogreške. U redu. Tako ćemo razgovarati o malo vremenski okvir za baze podataka tehnologije. Mislim pročitao sam članak ne tako davno i to je nešto na lines-- to je vrlo poetski iskaz. On je rekao povijest podataka obrada pun visokih vodeni žig obilje podataka. U REDU. Sada, mislim da je vrsta istina. Ali zapravo sam pogledati je kao povijest je zapravo ispunjen s visokim vodenim žigom pritiska podataka. Zbog brzine podataka Gutanje nikada ne ide dolje. To ide do samo. 

A inovacija događa kada vidimo pritisak podataka, koji je količina podataka koje je sada u dolaze u sustav. I to ne može biti obrađen učinkovito bilo u vremenu ili u troškovima. I to je kad smo započeli pogledati pritiskom podataka. 

Dakle, kada gledamo Prva baza podataka, to je onaj koji je između naših ušiju. Svi smo rođeni s njim. To je lijepo podataka. Ima visoku dostupnost. To je uvijek na. Uvijek možete ga dobiti. 

No, to je jedan korisnik. Ne mogu podijeliti svoje misli s vama. Ne možete dobiti moje misli kada ih želite. I njihova abilitiy nije tako dobar. Zaboravljamo stvari. Svaki sada i onda, jedan od nas ostavlja i prelazi na drugu postojanja i gubimo sve koji je bio u toj bazi podataka. Dakle, to nije sve što je dobro. 

I to je radio dobro s vremenom kad smo bili natrag u dan kada sve mi stvarno treba znati je gdje ćemo ići na sutra ili gdje smo okupiti najbolju hranu. No, kao što smo počeli rasti kao civilizacija i vlada je počela doći u biće, a poduzeća počela razvijati, počeli smo shvaćamo potrebno je malo više od onoga što bismo mogli staviti u našoj glavi. U redu? 

Trebali smo sustave evidencije. Trebali smo mjesta da bi mogli spremanje podataka. Tako smo započeli pisanje dokumenata, stvaranje knjižnice i arhiva. Počeli smo razvijanjem sustav A knjiga računovodstveni. I to sustav knjige brojanja ran svijet za mnoga stoljeća, i možda čak i tisućljeća kao smo vrsta rasla do točke gdje je taj teret podaci nadmašili Sposobnost ovih sustava biti u mogućnosti da ga sadrže. 

A to zapravo dogodilo u 1880. Pravo? U SAD-u Popisu 1880. Ovo je stvarno, gdje okretanje istaknuti modernu obradu podataka. Ovo je točka na koja količina podataka da je se uzima Američka vlada je dobio do točke gdje je osam godina obraditi. 

Sada, osam years-- što znate, popis stanovništva prometuje svakih 10 years-- tako da je prilično očito da je vrijeme smo dobio popis stanovništva 1890, količina podataka koja će biti obrađen vlada je će prelaziti 10 godina da se njega bi se pokrenuo novi popis stanovništva. To je bio problem. 

Dakle, čovjek po imenu Herman Hollerith došle i on je izumio jedinica rekord bušiti kartice, čitač kartica punch, punch kartice tabulator, te uspoređivanje mehanizmi za ovu tehnologiju. A to tvrtka koja je formirana na Vrijeme, zajedno s nekoliko drugih, zapravo postao jedan od stupova mala tvrtka danas znamo pod nazivom IBM. 

Dakle, IBM je izvorno bio u poslovna baza podataka. I to je zapravo ono što su učinili. Oni su učinili obradu podataka. 

Kao da proliferacija bušenja kartice, genijalan mehanizmi da bude u mogućnosti utjecati da Tehnologija anketirati razvrstanih rezultat postavlja. Možete vidjeti na ovoj slici Postoji imamo little-- to je malo small-- ali možete vidjeti vrlo domišljat mehanički mehanizam gdje imamo bušiti kartice palube. A netko uzimanje malo odvijač i pridržavaju kroz utora i to podizanje dobiti tu utakmicu, da Rezultati sortirani postaviti. 

To je gomilanje. Mi to sve vrijeme danas u računalu, gdje ste to učiniti u bazi podataka. Znali smo to učiniti ručno, zar ne? Ljudi staviti te stvari zajedno. I to je proliferacija tih bušenih kartica u ono što smo nazvali podataka bubnjevima i podatkovne role, papir trake. 

Obrada podataka industrija je pouka od igrača klavira. Igrač klavira natrag prijelazu stoljeća koriste koristiti papirnate valjke s utorima na to reći koje tipke za igranje. Tako da je tehnologija je prilagođena na kraju za pohranu digitalnih podataka, jer su mogli staviti te podatke na one papirne vrpce bubnju. 

Sada, kao rezultat toga, podaci je actually-- kako pristup ove podatke bio izravno ovisi o tome kako ste ga pohranjuju. Dakle, ako sam stavio podatke na kasetu, Imao sam pristup podacima linearno. Morao sam roll cjelinu Traka za pristup sve podatke. Ako sam stavio podatke u bušiti kartice, mogao sam joj pristupiti u nešto više slučajni moda, možda ne tako brzo. 

No, tu su ograničenja u tome što pristup podacima na temelju koliko je pohranjena. I tako je to bilo problem ide u 50-ih. Opet, možemo početi vidjeti da nismo razvoj novih tehnologija za obradu podataka, pravo, to otvara vrata za nova rješenja, za nove programe, novi aplikacije za te podatke. I doista, upravljanje možda je razlog Zato smo razvili neke od tih sustava. No, brzo je postao poslovni vozač iza evolucije moderne baze podataka i moderni datotečni sustav. 

Dakle, sljedeća stvar koja došao je u 50-ih je datotečni sustav i Razvoj slučajnim skladištenja pristupa. To je lijepo. Sada, sve odjednom, možemo staviti naše datoteka bilo gdje na ovim tvrde diskove i možemo pristupiti te podatke nasumično. Možemo analizirati kako Podaci iz datoteke. I riješili smo svi na svijetu problemi s obradom podataka. 

I to je trajalo oko 20 ili 30 godina do evolucije od relacijske baze podataka, koji kada je svijet odlučio Sada moraju imati repozitorij koji poraza širenje podataka preko datoteku Sustavi koje smo izgradili. Pravo? Previše podataka raspoređenih u previše mjesta, de-dupliciranje podataka, a troškovi skladištenja bio je ogroman. 

U 70-ih, najskuplji resurs da računalo imalo je za pohranu. Procesor je promatrati kao fiksni trošak. Kad sam kupiti kutiju, CPU radi neki posao. To će biti vrti li to je zapravo raditi ili ne. To je stvarno potonuo trošak. 

No, ono što me koštati kao posao je za pohranu. Ako moram kupiti više diskova sljedeći mjesec, to je pravi trošak koji sam platiti. I to je skupo za pohranu. 

Sada smo brzo naprijed 40 godina i imamo drugačiji problem. Računalnu je sada najskuplji resurs. Skladište je jeftin. Mislim, možemo ići bilo gdje na Oblak i možemo pronaći jeftini pohranu. Ali ono što ne mogu naći je jeftin izračunali. 

Dakle evoluciji današnjih tehnologija, baze podataka tehnologije, stvarno fokusiran oko distribuirane baze podataka koji ne pate od isti tip razmjera Ograničenja relacijskim bazama podataka. Razgovarat ćemo malo o što to zapravo znači. 

No, jedan od razloga i vozač iza this-- mi govorio o pritisku podataka. Tlak podataka je nešto koji vozi inovacije. A ako pogledate iznad posljednjih pet godina, ovo je shema što je podataka opterećenje po općim poduzeća Izgleda da je u posljednjih pet godina. 

A opće pravilo ove days-- ako idete Google-- je 90% podataka koji pohranjujemo danas, a to je ostvarila u posljednje dvije godine. U REDU. Sada, to nije trend koji je novo. To je trend koji je bio izlazak za 100 godina. Otkako Hermann Hollerith razvio bušena kartica, smo izgradnju spremišta podataka i prikupljanje podataka na fenomenalan stopa. 

Dakle, u posljednjih 100 godina, vidjeli smo taj trend. To neće promijeniti. U budućnosti ćemo vidjeti to, ako ne i ubrzani trend. A možete vidjeti kako to izgleda. 

Ako poslovanje u 2010. godini imala jednu terabajt podataka pod upravljanjem, Danas to znači da su upravljanje 6,5 petabajta podataka. To je 6.500 puta više podataka. I znam to. Radim s tim tvrtkama svaki dan. Prije pet godina, sam će razgovarati s tvrtkama tko bi sa mnom razgovarati o tome što boli je upravljati terabajta podataka. I oni će govoriti mi o tome kako vidimo da je to vjerojatno ide biti petabajt ili dva u roku od nekoliko godina. 

Te iste tvrtke Danas sam sastanak s, i oni pričaju mi ​​o Problem su tamo ima upravljanje desetine, 20 petabajta podataka. Dakle eksplozije Podaci u industriji vozi ogromni potreba za boljim rješenjima. A relacijske baze podataka jednostavno ne žive do potražnje. 

I tako postoji linearna korelacija između tlaka podataka i tehničke inovacije. Povijest nam je pokazala to, da je tijekom vremena, kad god volumen podataka koje treba obraditi prelazi kapacitet sustava obraditi u razumnom vremenu ili po razumnoj cijeni, tada novih tehnologija su izmislili riješiti te probleme. Oni nove tehnologije, pak, otvoriti vrata na drugi set problema, koji prikuplja još više podataka. 

Sada, nećemo se zaustaviti. Pravo? Nećemo se zaustaviti. Zašto? Budući da ne može znati sve što se može znati u svemiru. I dok smo bili živi, tijekom povijesti čovječanstva, uvijek smo odvezao znati više. 

Dakle, čini se kao i svaki inch se krećemo stazom znanstvenih otkrića, mi smo množenjem količine podataka da moramo obraditi eksponencijalno kao što smo otkriti više i više i više o unutrašnjem djelovanju života, o tome kako je svemir funkcionira, o vožnje znanstveno otkriće, i da je izum radimo danas. Volumen podataka jednostavno neprestano povećava. Tako se moći nositi s ovaj problem je ogroman. 

Dakle, jedna od stvari gledamo kao zašto NoSQL? Kako NoSQL riješiti ovaj problem? Pa, relacijske baze podataka, Structured Query Language, SQL-- da je stvarno konstrukt relacijske database-- te stvari optimiziran za skladištenje. 

Povratak u 70-ih, opet, disk je skuplji. Osiguravanje vježbe pohrane u poduzeću je neprestan. Znam. Ja živio. Napisao sam drivere za pohranu ima li enterprised superserver tvrtke natrag u 90-ih. I dno crta je stalci drugi skladištenje niz je samo nešto što dogodilo svaki dan u poduzeću. I nikad nije prestala. Veća gustoća pohranu, potražnja za visoke gustoće pohranu, a za učinkovitiju pohranu devices-- to nikada nije prestala. 

I NoSQL je veliki tehnologije jer normalizira podatke. To de-duplicira podatke. Ona stavlja podatke u strukturu koja je agnostik svakom pristupnom obrascu. Više aplikacije mogu pogoditi da SQL baza podataka, pokrenite ad hoc upite, i dobiti podatke u obliku koji se trebaju obraditi za svoje opterećenja. To zvuči fantastično. No, dno crta je s bilo sustava, ako je agnostik na sve, to je optimiziran za ništa. U REDU? 

I to je ono što smo dobili s relacijske baze. To je optimiziran za pohranu. To je normalizirana. To je relacijska. Ona podržava ad hoc upite. I to i mjerila okomito. 

Ako trebam dobiti veću SQL baza podataka ili snažnije SQL baza podataka, Idem kupiti veći komad željeza. U REDU? Ja sam radio s puno kupaca koji su kroz velike nadogradnje samo u SQL infrastrukture saznati šest mjeseci kasnije, oni opet ste udaranje u zid. A odgovor iz Oracle MSSQL ili ili bilo tko drugi dobiti veću kutiju. Pa, prije ili kasnije, ne možete kupiti veća kutija, i to je pravi problem. Moramo se zapravo promijeniti stvari. Pa gdje to radi? To dobro radi za offline analitika, OLAP tipa opterećenja. I to je stvarno, gdje SQL pripada. Sada, se koristi i danas u mnogim online transakcijskih obrada tipa aplikacije. I to radi sasvim u redu na određena razina iskorištenosti, ali to jednostavno ne razmjera način na koji NoSQL radi. A mi ćemo govoriti malo malo o tome zašto je to tako. 

Sada, NoSQL, s druge strane, je više optimiziran za računanje. U REDU? Nije agnostik se obrazac pristupa. Je li ono što mi zovemo de-normalizirana Struktura ili hijerarhijska struktura. Podaci u relacijsku bazu podataka je udružili s više stolova proizvesti mišljenje da vam je potrebno. Podaci u bazi podataka NoSQL pohranjuju se u dokumentu koji sadrži hijerarhijsku strukturu. Sve od podataka koji će biti normalno udružili proizvoditi taj pogled je pohranjena u jednom dokumentu. A mi ćemo govoriti malo o kako se to radi u nekoliko karata. 

No, ovdje je ideja da se pohraniti Vaši podaci su tim instanciraju pogledima. U REDU? Vi skala vodoravno. Pravo? Ako trebam povećati Veličina mog NoSQL klastera, Ne trebate dobiti veću kutiju. JA dobiti još jednu kutiju. I klastera one zajedno, i ja mogu Shard te podatke. Razgovarat ćemo malo o što sharding je, da se moći brojčano tu bazu podataka na više fizičkih uređaja i ukloniti prepreke koje traži me na ljestvici vertikalno. 

Dakle, to je stvarno izgrađena za online obradu transakcija i razmjera. Postoji razlika velika ovdje između izvješćivanja, zar ne? Izvješćivanje, ja ne znam Pitanja ću pitati. Pravo? Reporting-- ako netko od moj odjel marketinga želi just-- koliko mojih klijenata imaju ovu posebnu karakteristiku koja kupio na ovom day-- ne znam ono upita oni će pitati. Dakle, trebam biti agnostik. 

Sada, u online transakcijske primjene, Znam što pitanja pitam. Sam sagradio zahtjev za vrlo specifičan tijek rada. U REDU? Dakle, ako sam optimizirati podatke pohraniti podržati taj tijek rada, to će biti brže. I to je razlog zašto NoSQL mogu stvarno ubrzati isporuku tih vrsta usluga. U redu. 

Tako ćemo dobiti u malo teorije ovdje. A neki od vas, vaše oči može vratiti natrag malo. Ali ja ću pokušati zadržati kao visok stupanj mogu. Dakle, ako ste u projektu upravljanje, postoji konstrukt naziva trokut ograničenja. U REDU. Trokut od ograničava diktatu ne možete imati sve cijelo vrijeme. Ne mogu imati svoju pitu i jesti previše. Tako je u upravljanju projektima, koji trokut Ograničenja se možete ga jeftino, možete ga brzo, ili možete imati je dobro. Izaberite dva. Budući da ne mogu imati sve tri. Pravo? U REDU. 

Tako da čuju o tome mnogo. To je trostruko ograničenje, Trokut trostrukog ograničenja, ili željezo trokut oftentimes-- kada razgovarati s voditeljima projekata, oni će razgovarati o tome. Sada, baze podataka ima vlastitu željezo trokut. A željezo trokut podataka je ono što mi zovemo teorem CAP. U REDU? 

CAP teorem diktira Kako baze podataka rade pod vrlo specifičnim uvjetima. A mi ćemo govoriti o što je uvjet. No, tri točke trokuta, da se tako izrazim, su C, dosljednost. U REDU? Tako je u ZPP, dosljednost znači da su svi klijenti koji mogu pristupiti bazi podataka uvijek će imati vrlo dosljedan prikaz podataka. Nitko neće vidjeti dvije različite stvari. U REDU? Ako vidim baze podataka, Vidim isti pogled kao moj partner, koji vidi ista baza podataka. To je dosljednost. 

Dostupnost znači da ako baze podataka on-line, ako se može doći, da svi klijenti će uvijek moći čitati i pisati. U REDU? Tako svaki klijent koji možete pročitati podataka uvijek će biti u mogućnosti za čitanje podataka i pisanje podataka. A ako je to slučaj, to je dostupan sustav. 

I treća stvar je što zovemo particiju toleranciju. U REDU? Dijeljenje tolerancije da sustav dobro radi unatoč fizičkoj mreži pregrade između čvorova. U REDU? Tako čvorovi u klasteru ne može međusobno razgovarati, što se događa? U redu. 

Dakle, relacijske baze podataka choose-- možete odabrati dva od njih. U REDU. Dakle, relacijske baze podataka odaberite biti dosljedan i dostupni. Ako je particija dogodi između su DataNodes u spremištu podataka, baza podataka ruši. Pravo? To samo ide dolje. U REDU. 

I to je razlog zašto oni moraju rasti s većim kutijama. Pravo? Budući da je no-- obično, klaster baze podataka, tu nije baš mnogi od njih da rade na taj način. No, većina baza podataka ljestvici vertikalno unutar jednog okvira. Jer oni moraju biti dosljedan i dostupni. Ako pregrada su se ubrizgava, onda će morati napraviti izbor. Morate napraviti izbor između biti dosljedan i dostupni. 

I to je ono NoSQL baze učiniti. U redu. Tako NoSQL baze ga, dolazi u dva okusa. Mi have-- dobro, to dolazi u mnogim okusa, ali to dolazi s dva osnovna characteristics-- što bismo nazvali CP baze podataka, ili dosljedan i particija toleranciju Sustav. Ovi momci bi izbor da kada čvorovi gube kontakt jedan s drugim, nećemo dopustiti ljudi pisati više. U REDU? 

Dok se to particija je uklonjena, pisati pristup blokiran. To znači da oni nisu dostupni. Oni su dosljedni. Kad vidimo da particija se uvelo, mi smo sada u skladu, jer mi ne ide dopustiti promjenu podataka na dva strane pregrade samostalno jedan od drugoga. Mi ćemo morati uspostaviti komunikaciju Prije bilo ažuriranja podaci se smiju. U REDU? 

Sljedeći okus će biti AP sustav, ili dostupni i podijeli Tolerancija sustava. Ovi dečki ne briga. Pravo? Svaki čvor koji dobiva pisanje, mi ćemo ga uzeti. Tako sam replicira moj podatke na više čvorova. Ovi čvorovi dobili klijent, klijent dolazi u, kaže, ja ću napisati neke podatke. Čvor kaže, nema problema. Čvor pored njega dobiva Write na istom albumu, on će reći nema problema. Negdje natrag na leđa kraj, da su podaci će ponoviti. I onda netko će shvatiti, Uh, oni sustav će shvatiti, uh-oh, tu je bio ažuriranje dvije strane. Što nam je činiti? A što rade onda je oni nešto što im omogućuje da riješi to stanje podataka. A mi ćemo govoriti o da se u sljedećem grafikonu. 

Stvar istaknuti ovdje. I neću dobiti previše puno u to, jer je to dobiva u duboku teoriju podataka. No, tu je transakcijske okvir koji radi u relacijsku sustav koji mi omogućuje da sigurno bi ažuriranja na više osoba u bazi podataka. I doći će ti ažuriranja odjednom ili uopće ne. I to se zove ACID transakcije. U REDU? 

KISELINA nam daje valentnost, dosljednost, izolacija i trajnost. U REDU? To znači atomsku transakcije, sve moja ažuriranja ili dogoditi ili ne. Dosljednost znači da Baza podataka će uvijek biti dovedeni u dosljedan stanje nakon ažuriranja. Nikada neću napustiti bazu podataka u loše stanje nakon primjene ažuriranja. U REDU? 

Dakle, to je malo drugačije nego dosljednost CAP. Dosljednost ZPP znači sve moje klijenti uvijek mogu vidjeti podatke. KISELINA dosljednost znači da kada transakcija je učinio, podaci je dobar. Moji su odnosi sve dobro. Neću izbrisati redak roditelja i ostaviti hrpu siročadi djece na drugi stol. To se ne može dogoditi ako sam dosljedna u kiselom transakciju. 

Izolacija znači da su transakcije uvijek pojavljuju jedan za drugim. Krajnji rezultat je podataka će biti isto stanje kao da je ta transakcija koje su izdane istodobno pogubljeno serijski. Tako da je konkurentnost Kontrola u bazi podataka. Tako je u osnovi, ne mogu povećajte istu vrijednost dva puta s dvije operacije. 

Ali ako kažem dodati 1 do te vrijednosti, i dvije transakcije dolaze u i pokušajte to učiniti, jedan je će doći prvi a drugi je će doći poslije. Tako je na kraju, dodao sam dva. Vidite što mislim? U REDU. 

Trajnost je prilično jednostavan. Kada je transakcija je priznao, to je će biti tamo još ako sustav ruši. Kada taj sustav oporavi, da Transakcija koja je počinio zapravo će biti tamo. Tako da je jamstva kiselih transakcija. Oni su prilično lijepe jamstva da su na bazi podataka, ali oni dolaze na toj cijeni. Pravo? 

Zbog problema s ovim okvir ako postoji particija u podacima Skup, moram donijeti odluku. Ja ću morati dopustiti ažuriranja na jednu ili drugu stranu. A ako se to dogodi, onda više nisam događa da bi mogli održavati tih obilježja. Oni neće biti dosljedna. Neće biti izoliran. Ovo je mjesto gdje se razgrađuje za relacijskim bazama podataka. To je razlog relacijska baze podataka ljestvica vertikalno. 

S druge strane, mi smo ono što se naziva BASE tehnologiju. A ovo su tvoji NoSQL baze podataka. U redu. Dakle, mi imamo CP, AP baze podataka. A to su ono što nazivamo osnovi dostupni, mekana država, na kraju dosljedan. U REDU? 

Uglavnom na raspolaganju, jer je oni particija tolerantni. Oni će uvijek biti tamo, čak i ako postoji mreža particiju između čvorova. Ako ja mogu razgovarati s čvora, ja sam će biti u mogućnosti za čitanje podataka. U REDU? Ja ne mogu uvijek biti u stanju napisati Podaci ako sam dosljedan platformi. Ali ja ću biti u mogućnosti za čitanje podataka. 

Mekani stanje ukazuje da kad sam pročitao da su podaci, to možda neće biti isti kao i drugih čvorova. Ako je pravo izdana na čvoru negdje drugdje u skupini i to ne replicirati diljem Klaster ali kad sam pročitao da su podaci, da država ne može biti dosljedni. Međutim, bit će na kraju dosljedan, što znači da kada pišu se kako sustav, to će replicirati preko čvorova. I na kraju, da je država će biti dovedeni u red, i to će biti dosljedan stanje. 

Sada, teorem CAP stvarno igra samo u jednom stanju. To je stanje kada se to dogodi. Zato, kad god je to djeluju u normalnom načinu rada, nema particiju, sve u skladu i na raspolaganju. Vi samo brinuti o CAP kada imamo tu particiju. Dakle, oni su rijetki. No, kako sustav reagira kada se one javljaju diktirati kakvu vrstu sustava imamo posla. 

Tako ćemo se pogled na ono što koji izgleda kao za upravni sustavi. U REDU? AP sustavi dolaze u dva okusa. Oni dolaze u okus koji je majstor majstor, 100%, uvijek na raspolaganju. I oni dolaze u drugi okus, koji je, kaže, znate što, ja ću se brinuti o ovom particioniranje stvar kada stvarna podjela događa. Inače, tu će biti primarna čvorovi tko će preuzeti prava. U REDU? 

Dakle, ako smo nešto poput Cassandre. Cassandra bi biti majstor majstor, neka sam ja pisati na bilo koji čvor. Dakle, što se događa? Dakle, imam objekt u baza podataka koja postoji na dva čvora. Nazovimo tu objekt S. Dakle, imamo državu za S. Imamo neke operacije na S da su u tijeku. Cassandra mi omogućuje da pisati na više čvorova. Pa recimo ja dobiti pisati s dva čvora. Pa, što se završi događa je smo poziv da particioniranje događaja. Tu ne može biti fizičko dijeljenje mreže. No, zbog dizajna sustava, to je zapravo particioniranje čim kao što sam dobiti napisati na dva čvora. To me ne tjera na pisati sve kroz jedan čvor. Pišem na dva čvora. U REDU? 

Tako sada imam dvije države. U REDU? Što će se dogoditi je, prije ili kasnije, tu će biti odgovor događaj. Tu će biti ono što smo naziva Partition Recovery, koji gdje ove dvije navodi se vratiti zajedno a tu će biti algoritam koji se izvodi unutar baze podataka, odluči što će učiniti. U REDU? Po defaultu, zadnje ažuriranje pobjeda u većini AP sustava. Dakle, tu je obično zadani algoritam, što zovu povratni funkcija, nešto što zvat će se kada se ovaj uvjet se otkrije da izvrši neke logike riješiti taj sukob. U REDU? Zadana povratni poziv i zatezne rezolver u većini AP bazama podataka je, pogodite što, timestamp pobjeđuje. To je bio posljednji ažuriranje. Idem staviti da ažuriranje tamo. Ja mogu izbaciti ovaj rekord koji sam bačena off u zapisnik oporavka tako da korisnik može vratiti kasnije i reći, hej, došlo je do sudara. Što se dogodilo? A zapravo možete izvatkom evidenciju svi sudari i rollbacks i vidjeti što se događa. 

Sada, kao korisnik, možete također Uključi logiku u toj povratni poziv. Tako možete promijeniti kako povratni poziv operacija. Možete reći, hej, ja želim sanirati ove podatke. I ja želim probati i spojiti ta dva zapisa. Ali to je do vas. Baza podataka ne zna kako to po defaultu. Većina vremena, jedino što je baza podataka zna kako to učiniti je reći, ovo je bio posljednji rekord. To je onaj koji će pobijediti, te da je vrijednost ću staviti. Nakon toga particije i replikacija događa, mi imamo državu koja Sada je S premijera, što je Spojiti stanje svih tih objekata. Dakle, AP sustavi imaju to. CP sustavi ne trebaju brinuti o tome. Jer čim particija dolazi u igri, oni samo prestati uzimati piše. U REDU? Tako da je vrlo lako bave se dosljedno kada ne prihvaćaju ažuriranja. To je s CP sustavi učiniti. U redu. 

Dakle, pričajmo malo malo o pristupnim uzoraka. Kada govorimo o NoSQL, to je sve o pristupnom obrascu. Sada, SQL je ad hoc upite. To je relacijska trgovine. Ne morate brinuti o pristupnom obrascu. Pišem vrlo kompleksan upit. To ide i dobiva podatke. To je ono što ovo izgleda kao, normalizacija. 

Dakle, u ovom konkretnom strukture, gledamo katalog proizvoda. Imam različite vrste proizvoda. Imam knjige. Imam albuma. Imam videa. Odnos proizvoda i bilo koji od tih knjiga, albuma, i videa tablice je 1: 1. U redu? Imam ID proizvoda, i da ID odgovara na knjigu, album ili video. U REDU? To je 1: 1 odnos preko tih tablica. 

Sada, sve što books-- imam je korijen svojstva. Nema problema. To je odlično. Jedan-na-jedan odnos, dobivam sve podatke trebam opisati tu knjigu. Albums-- albumi pjesama. To je ono što mi zovemo jednog do mnogih. Svaki album mogao imati mnogo pjesama. Dakle, za svaku stazu na album, mogao sam jedan rekord u ovoj tablici djeteta. Tako sam stvoriti jedan rekord u moje albume tablici. Ja stvoriti višestruke zapise u tablici staze. Jedan-na-mnogi odnos. 

Ovaj odnos je ono što zovemo više-prema-više. U REDU? Vidiš da glumci mogu biti u mnogim filmovima, mnogo videa. Dakle, ono što mi radimo je da stavite ovu mapiranje stol između onih koji to jednostavno mapira glumac ID za video ID. Sada mogu stvoriti upit spaja video kroz glumca video na glumcima, i to mi daje lijep popis svi filmovi i svi glumci koji su bili u tom filmu. 

U REDU. Dakle, ovdje mi ići. Jedan-na-jedan je najviše razine odnos; jedan-na-mnogi, albumi na stazama; više-prema-više. To su tri najviše razine odnosi u bilo koju bazu podataka. Ako znate kako one odnosi rade zajedno, onda znate puno o bazi podataka već. Dakle NoSQL radi malo drugačije. Razmislimo o za drugi što ga Izgleda kao da ići dobiti sve moje proizvode. 

U relacijskoj trgovini, sam želite dobiti sve svoje proizvode na popisu svih mojih proizvoda. To je puno upita. Dobio sam upit za sve moje knjige. Dobio sam upit od mojih albuma. I ja sam dobio upit za sve moje videa. I dobio sam ga staviti sve zajedno u popis i dostaviti ga natrag do program koji je to traži. 

Da biste dobili svoje knjige, ja pridružiti Proizvodi i knjige. Da biste dobili moje albume, dobio sam da se pridruže Proizvodi, albumi, i trase. I da se moje videozapise, imam pridružiti Proizvodi za Video, pridružite kroz Glumac Video, i dovesti u Actors. Dakle, to je tri pitanja. Vrlo složeni upiti na sastaviti jedan skup rezultata. 

To je manje od optimalnog. To je razlog zašto, kada govorimo o strukturi podataka koji je izgrađen da bude agnostik s pristupom pattern-- i to je super. A možete vidjeti stvarno lijepo kako smo organizirali podatke. I znate što? Imam samo jedan rekord za glumca. 

To je super. Ja sam deduplicated sve moje glumci, i ja zadržala svoje udruge u ovoj mapiranje tablice. Međutim, uzimajući podatke kako postaje skuplji. Šaljem CPU cijelog sustava pridružio ove strukture podataka zajedno da bi mogli povući da podatke natrag. 

Pa kako sam dobiti oko toga? U NoSQL je o agregacije, nije normalizacija. Dakle, želimo reći da želimo podršku pristupnu uzorak. Ako pristupnu uzorak na aplikacije, Trebam dobiti sve moje proizvode. Stavimo sve proizvode u jednoj tablici. Ako sam staviti sve proizvode u jednoj tablici, Ja samo mogu odabrati sve proizvode od tog stola, a ja sve to dobiti. Pa kako ću to učiniti? Pa u NoSQL nema Struktura na stol. Razgovarat ćemo malo o kako se to radi u Dynamo DB. Ali nemate isti atributi i ista svojstva u svakom retku, u svakom predmet, kao što to u SQL tablice. A što to mi omogućuje učiniti mnogo stvari i daj mi puno fleksibilnosti. U konkretnom slučaju, ja imam svoje proizvode dokumente. I u ovaj Primjer, sve je dokument u tablici proizvoda. A proizvod za knjigu možda imaju tip ID koji određuje knjigu. I program će se prebaciti na taj ID. 

U prijavi stupu, idem reći oh, što je rekord tip je ovo? Oh, to je knjiga rekord. Knjiga evidencije imaju ta svojstva. Dopustite mi stvoriti knjigu objekt. Tako ću popuniti Knjiga objekt s ove točke. Sljedeći predmet dolazi i kaže, što je ovaj predmet? Pa ova stavka je album. Oh, dobio sam cijeli različite Obrada rutinu za to, jer je album. Vidite što mislim? 

Dakle, primjena tier-- sam samo odaberite sve ove zapise. Svi oni početi dolaze u. Oni mogu biti sve različite vrste. I to je aplikacijski logika da prebacuje preko onih tipova i odluči kako ih obraditi. 

Opet, tako da smo optimizaciji shema za pristupnu uzorak. Mi smo to radili po urušavanja te tablice. Mi zapravo uzimaš ove strukture, normalizirani i gradimo hijerarhijske strukture. Unutar svakog od tih zapisa Idem vidjeti svojstva polja. 

Unutar ovog dokumenta za albume, Vidim polja pjesama. Ti zapisi sada become-- je zapravo ovo dijete tablica koja postoji upravo ovdje u ovoj strukturi. Dakle, možete to učiniti u DynamoDB. To možete učiniti u MongoDB. To možete učiniti u bilo NoSQL bazi podataka. Izrada ove vrste hijerarhijske strukture podataka koji omogućuju dohvaćanje podataka vrlo brzo, jer sad sam ne moraju odgovarati. Kad sam umetnuti redak u Tracks stol, ili redak u tablici albuma, Moram biti u skladu s tom shemom. Moram imati atribut ovaj ili imovine koja se definira na tom stolu. Svaki od njih, kad ubacite taj red. To nije slučaj u NoSQL. 

Ja mogu imati potpuno drugačiji svojstva u svakom dokumentu da ubacite u zbirci. Dakle, vrlo snažan mehanizam. I to je stvarno kako vas optimizirati sustav. Jer sada taj upit, umjesto pridruživanja sve ove tablice i izvršavanju pola tuceta upite povući podatke trebam, Ja izvršavanju jedan upit. I ja sam iterating po rezultatima postavili. to vam daje ideju snage NoSQL. Idem vrsta ići postrance ovdje i razgovarati malo o tome. To je više vrsta od marketing ili technology-- marketing tehnologija tip rasprave. No, to je važno razumjeti jer ako ćemo gledati na vrhu ovdje na ovom grafikonu, ono što gledamo je ono što mi zovemo Tehnologija krivulja hype. A što to znači nove stvari dolazi u igru. Ljudi misle da je super. Ja sam riješio sve moje probleme. 

To bi mogao biti kraj sve, biti sve u svemu. I oni početi koristiti. A oni kažu, ove stvari ne rade. To nije u redu. Stara stvar bila bolja. I oni se vratiti radi stvari način na koji su. I onda na kraju odu, znate što? Ova stvar nije tako loše. Oh, to je kako se to radi. I nakon što shvatiti kako to Radovi se počinju sve bolje. 

A smiješno što o tome je, to vrsta linije do onoga što zovemo usvajanje tehnologije krivulje. Dakle, što se događa je imamo neka vrsta tehnologije okidač. U slučaju baza podataka, to je pritisak podataka. Razgovarali smo o visokim vode bodova tlaka podataka tijekom vremena. Kada se to pritisak podaci pogodi određena točka, to je tehnologija okidač. 

To je sve preskupo. To traje predugo za obradu podataka. Moramo nešto bolje. Možete dobiti inovatore vani trčanje okolo, pokušava saznati što je rješenje. Što je nova ideja? 

Koji je sljedeći najbolji način učiniti nešto takvo? A oni se s nešto. A ljudi s stvarnom boli, dečki na rubu krvarenja, oni će skočiti sve preko njega, jer oni trebaju odgovor. Sada ono neizbježno happens-- i to se događa upravo sada u NoSQL. Ja vidim cijelo vrijeme. 

Što se neminovno događa je ljudi početi koristiti novi alat isti način na koji su koristili stari alat. I oni saznali da ne radi tako dobro. Ne mogu se sjetiti tko sam u razgovoru s ranije danas. No, to je kao, kad jackhammer je izumio, ljudi nisu to ljuljačka iznad njihove glave razbiti beton. 

Ali to je ono što je događa s NoSQL danas. Ako ste hodati u većini trgovina, oni pokušavaju biti NoSQL trgovine. Ono što oni rade je oni koriste NoSQL, a oni ga učitava puna relacijske sheme. Jer to je kako oni dizajn baze podataka. I oni su pitali, zašto je ne obavlja dobro? Čovječe, ova stvar smrdi. Morao sam se zadržati sve moje pridružuje in-- to je kao, ne, ne. Održavati pridružuje? Zašto se pridružio podatke? Ne pridružiti podatke u NoSQL. Možete ga sakupiti. 

Dakle, ako želite izbjeći ovaj, saznajte kako alat radi prije nego što zapravo početi koristiti. Nemojte probati i koristiti nove instrumente isti način na koji se koristi stare alate. Ti si idući u imati loše iskustvo. I svaki put to je ono što se radi. Kad počnemo dolaze ovdje, to je zato što ljudi shvatili kako koristiti alate. 

Oni su učinili istu stvar kada relacijske baze podataka su izmislili, i oni su bili zamjene datotečne sustave. Oni su pokušali izgraditi sustave datoteka s relacijskim bazama podataka jer to je ono što ljudi razumjeli. To nije uspjelo. Dakle, razumijevanje najbolje prakse tehnologije radite s je ogroman. Jako važno. 

Tako ćemo dobiti u DynamoDB. DynamoDB je AWS-a potpuno uspio NoSQL platformu. Što potpuno uspio znači? To znači da ne morate stvarno brinuti o bilo čemu. 

Dođeš u, reći nas, trebam stol. To treba toliko kapaciteta. Vi pritisnite gumb, a mi odredba sva infrastruktura iza scene. Sada kada je ogromna. 

Jer kada govorimo O skaliranje baze podataka, NoSQL podataka klastera u razmjera, trčanje petabajta, trčanje milijune transakcija u sekundi, te stvari nisu male skupine. Govorimo tisuće slučajeva. Upravljanje tisuća primjeraka, čak i virtualne instance, je pravi bol u kundak. Mislim, razmišljam o svaki put Operativni sustav patch izlazi ili nova verzija baze podataka. Što to znači vama operativno? To znači da je dobio 1.200 poslužitelja koji trebaju biti ažurirani. Sada čak i automatizacije, koji može potrajati dugo vremena. To može izazvati mnogo operativne glavobolje, jer sam možda usluge prema dolje. 

Kao što sam ažurirati ove baze podataka, sam mogli učiniti plave zelene implementacije gdje sam implementaciju i nadogradnju pola moje čvorovi, a zatim nadograditi na drugu polovicu. Uzmi one dolje. Dakle, upravljanje infrastrukturom Ljestvica je nevjerojatno bolno. I AWS se taj bol iz nje. I NoSQL baze podataka može biti izuzetno bolno zbog načina na koji oni razmjera. 

Scale vodoravno. Ako želite dobiti veći NoSQL baze podataka, možete kupiti više čvorova. Svaki čvor kupite je drugi operativni glavobolje. Pa neka netko drugi to učiniti za vas. AWS može učiniti. 

Podržavamo ključni dokument vrijednosti. Sada nismo išli previše u na drugoj karti. Postoji mnogo različitih okusa NoSQL. Oni su sve vrste dobivanja munged zajedno u ovom trenutku. Možete pogledati na DynamoDB i reći da, smo i dokument i ključna vrijednost spremiti ovu točku. I vi možete tvrditi značajke jedan iznad drugoga. Za mene, puno je to stvarno šest jednog pola tuceta od drugih. Svaki od tih tehnologija je fino tehnologije i fino rješenje. Ne bih rekao MongoDB bolje ili gore nego kauč, zatim Cassandra, onda Dinamo, ili obrnuto. Mislim, to su samo opcija. 

To je brzo i to je dosljedni u bilo kojem mjerilu. Dakle, ovo je jedan od najvećih bonuse ste dobili s AWS. S DynamoDB je sposobnost dobiti nisku jednu znamenku milisekundu kašnjenje u bilo kojem mjerilu. To je bio cilj dizajna sustava. I imamo klijente koji su se time bavili milijuni transakcija u sekundi. 

Sad ću proći kroz neke od tih koristiti slučajeve u nekoliko minuta ovdje. Integrirani pristup control-- imamo ono što mi zovemo Identitet Pristup upravljanje ili IAM. Ona prožima svaki sustav, svaki servis koji AWS nudi. DynamoDB nije iznimka. Možete kontrolirati pristup na DynamoDB stolovima. Na svim svojim AWS računa od strane definiranje pristupne uloge i ovlasti u IAM infrastrukturu. 

I to je ključ i sastavni je u ono što nazivamo Event Driven Programiranje. A ovo je nova paradigma. 

PUBLIKA: Kako ti je stopa istina pozitivci naspram lažnih negativa na vašem sustavu kontrole pristupa? RICK Houlihan: True pozitivci naspram lažnih negativa? PUBLIKA: Vraćanje što trebate se vratiti? Za razliku od jednom u neko vrijeme da ne vrati kad je trebalo provjeriti? 

RICK Houlihan: Nisam mogao reći da je. Ako postoji bilo propusta god na to, Nisam osoba pitati da određeni pitanje. Ali to je dobro pitanje. Ja bih bio znatiželjan to znati da ja, zapravo. 

I tako opet, nova paradigma je događaj potaknut programiranje. To je ideja da možete implementaciju složenih aplikacija koje može raditi vrlo, vrlo visoku ljestvicu bez infrastrukture god. Bez bilo fiksna infrastruktura god. A mi ćemo govoriti malo o tome što to znači kao mi doći na sljedeći par karata. 

Prva stvar koju ćemo napraviti je ćemo razgovarati o stolovima. Vrste API podataka za Dinamo. I prva stvar koju ćete obavijest kada pogledate ovaj, Ako ste upoznati s bilo baze podataka, baze podataka ima stvarno dvije vrste API Ja bih to nazvao. Ili dva seta API. Jedan od onih koji će biti upravna API. 

Stvari brinu o funkcije baze. Konfiguriranje pohranu motor, postavljanje i dodavanje tablice. stvaranje baze podataka katalozi i primjeri. To things-- u DynamoDB, što imaju vrlo kratke, kratke liste. 

Tako je u drugim bazama podataka, možete vidjeti na desetke naredbi, upravnih naredbe za konfiguriranje ove dodatne opcije. U DynamoDB ne trebate onima zbog ne konfiguriranje sustava, mi radimo. Dakle, jedino što trebate učiniti je recite mi što veličina tablice trebam. Tako ćete dobiti vrlo ograničen skup naredbi. 

Dobivate stvoriti tablicu Update, stol, Izbriši tablicu i opisati tablicu. To su samo stvari što je potrebno za DynamoDB. Ne trebate skladište konfiguracija motora. Ne morate se brinuti o replikacije. Ne morate se brinuti o sharding. 

Ne morate se brinuti o bilo ove stvari. Mi sve to učiniti za vas. Dakle, to je ogroman pretek to je samo podigne svoj tanjur. Onda imamo crud operatora. CRUD je nešto što smo poziv u bazi podataka koja je Stvaranje, ažuriranje, brisanje operatora. To su vaše uobičajene operacija baze podataka. Stvari kao što su stavili stavke, dobiti stavke, ažuriranje predmeti, brisanje stavki, serije upit, skeniranje. Ako želite skenirati cijeli stol. Povucite sve sa stola. Jedna od lijepih stvari o DynamoDB je li vam paralelno skeniranje. Dakle, zapravo možete pustiti mene znati koliko niti želite pokrenuti na toj skeniranja. I mi možemo pokrenuti te teme. Možemo vrtjeti da skenirate na više niti tako da možete skenirati cijeli stol Prostor je vrlo, vrlo brzo u DynamoDB. 

Drugi API imamo je ono što mi zovemo naš žanrovi API. Nećemo previše govoriti više o tome sada. Imam neki sadržaj kasnije na u palubi o tome. Ali Potoci je stvarno running-- mislim da je to vrijeme naredili i particija dnevnika promjena. Sve što se događa na tablica prikazuje se na potoku. 

Svako pisanje na stolu prikazuje se na potoku. Možete pročitati da je potok i možete učiniti stvari s njim. Mi ćemo razgovarati o tome što vrste stvari koje učiniti sa stvarima kao što su replikacija, stvaranje sekundarnih indekse. Sve vrste stvarno cool stvari koje možete učiniti s tim. 

Vrste podataka. U DynamoDB podržavamo oba ključa vrijednost i podatkovne dokument vrste. Na lijevoj strani zaslona ovdje imamo naše osnovne vrste. Ključne vrste vrijednosti. To su žice, brojevi i binarne datoteke. 

Dakle, samo tri osnovne vrste. A onda možete imati kompleta tih. Jedna od lijepih stvari o NoSQL je možete sadržavati polja su svojstva. A s DynamoDB možete sadrže nizove osnovnih tipova kao imovinu korijena. 

A tu je i vrste dokumenata. Koliko ljudi su upoznati s JSON? Vi upoznate s JSON toliko? To je u osnovi JavaScript, Objekt, notacija. To vam omogućuje da u osnovi definirati hijerarhijsku strukturu. 

Možete pohraniti JSON dokument o DynamoDB pomoću zajedničke komponente ili blokova koji su dostupni u većini programskih jezika. Dakle, ako imate Java, ti si gleda na kartama i popisima. Ja mogu kreirati objekte koji Karta područja. Karta kao ključne vrijednosti pohranjena kao svojstva. A to bi moglo imati popise vrijednosti unutar tih svojstava. Možete pohraniti kompleks hijerarhijska struktura kao jedan atribut od točke DynamoDB. 

Dakle stolovima DynamoDB, kao i većina NoSQL baze podataka, tablice su stavke. U MongoDB što bi pozvati te dokumente. I to će biti kauč baze. Također baza podataka dokument. Možete nazvati ove dokumente. Dokumenti ili predmeti imaju atribute. Značajke mogu postojati ili ne postoji na stavku. U DynamoDB, postoji jedan obavezno atribut. Baš kao u relacijskoj bazi podataka, imate primarni ključ na stolu. 

DynamoDB ima ono što mi zovemo hash ključ. Hash ključ mora biti jedinstven. Dakle, kada sam definirati hash tablicu, u osnovi ono što govorim je svaki predmet će imati hash ključ. I svaki ljestve tipku moraju biti jedinstveni. 

Svaka točka je definirana tom jedinstvenom hash ključa. I tu može biti samo jedan. To je u redu, ali često ono što ljudi trebaju je žele to mljeveno meso Ključ za napraviti malo više nego samo biti jedinstveni identifikator. Često želimo koristiti taj hash ključ kao najvišoj razini agregacije kantu. A način na koji smo to jest dodajući ono što mi zovemo ključ raspona. 

Dakle, ako je samo mljeveno meso stol, to mora biti jedinstven. Ako je mljeveno meso i niz stol, Kombinacija hash i raspon mora biti jedinstven. Dakle, razmišljam o tome na taj način. Ako imam forum. I oblik ima tema, ima postova, i to je odgovor. 

Tako sam mogao imati hash ključ, što je tema ID. I možda ključ raspon, što je ID odgovora. Na taj način, ako želim dobiti sve odgovori za određenu temu, Ja samo mogu upita mljeveno meso. Ja samo mogu reći dajte mi sve stavke koje imaju ovu mljeveno meso. I ja ću doći na svako pitanje ili post za tu temu. Ove top level agregacije su vrlo važni. Oni podržavaju primarni pristup obrazac zahtjeva. Općenito govoreći, to je ono što želite učiniti. Želimo da table-- kao što ste učitati tablicu, želimo strukturirati podatke u tablici na način da je zahtjev mogu vrlo brzo dohvaćanje tih rezultata. I često način za to je za održavanje ove agregacije kao što smo umetnuti podatke. Uglavnom, mi smo širenje podataka u svijetlu kantu jer dolazi u. 

Tipke Umjereni omogućuju me-- hash ključevi moraju biti jednakost. Kad sam upit mljeveno meso, moram reći daj mi hash koji je jednak ovome. Kad sam upit niz, ja mogu reći dajte mi ponudu da koristi bilo koje vrste Bogata operatera da mi podržavamo. Daj mi sve stavke za mljeveno meso. Je li to jednako, veće od, manje nego, to početak, to postoji između ove dvije vrijednosti? Tako ove vrste raspona upita da smo uvijek zainteresirani. Sada jedna stvar o podacima kada pogledate pristup podacima, kada pristup podacima, to je uvijek o agregaciji. To je uvijek o evidenciji koji se odnose na to. Daj mi sve ovdje that's-- sve poslovi na ovom kreditnom karticom za prošli mjesec. To je gomilanje. 

Gotovo sve što vam je činiti u Baza je neka vrsta agregacije. Dakle, biti u mogućnosti da bi mogli definirati Ove žlice i dati vam ove raspon pripisuje moći upit na, oni bogati upiti podržavaju mnogi, mnogo, mnogo pristupa aplikacija uzoraka. 

Dakle druga stvar ljestve tipku Da li je to nam daje mehanizam da bi mogli širiti podatke okolo. NoSQL baze raditi najbolje kada su podaci ravnomjerno distribuira preko klastera. Koliko ljudi su upoznati s raspršivanja algoritme? Kad kažem mljeveno meso i hashing-- zbog algoritma raspršivanja je način da ste u mogućnosti generirati slučajni vrijednost od bilo koje vrijednosti. Dakle, u ovom konkretnom slučaju, algoritam trčimo je ND 5 based. 

I ako imam ID, i to moja ljestve tipku, imam 1, 2, 3. Kad sam pokrenuti hash algoritam, to će se vratiti i reći: dobro 1 jednak 7B, 2 jednako 48, 3 jednaka CD. Oni proširila diljem razmaknicu. A zašto ste to učinili? Budući da se osigurava da mogu stavi zapise na više čvorova. 

Ako ovo radim postupno, 1, 2, 3. I imam hash raspon koji radi u konkretnom slučaju, mali hash prostor, to traje od 00 do FF, onda zapisi će doći u a oni će ići 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. Što se događa? Svaki umetak ide na isti čvor. Vidite što mislim? 

Jer kad sam podijeliti prostor, i ja proširila te zapise preko, i ja particije, ja ću reći particija 1 ima ključnu prostor 0 do 54. Partition 2 je od 55 do 89 godina. Dijeljenje 3 AA na FF. Dakle, ako sam koristeći linearno povećavati ID, možete vidjeti što se događa. 1, 2, 3, 4, 5, 6, sve do 54 put. Dakle, kao što sam zakucavanje evidencije u sustav, sve završi ide na jedan čvor. 

To nije dobro. To je antipattern. U MongoDB imaju ovaj problem ako ne koristite hash ključ. MongoDB vam daje mogućnost raspršivanja ključnu vrijednost. Uvijek biste trebali učiniti, ako koju koristite povećavati hash ključ u MongoDB, ili ćete biti čavlima svaki pisati na jedan čvor, i bit će vam ograničava Vaša pisati propusnost loše. 

PUBLIKA: Je li to A9 169 u decimalnog? 

RICK Houlihan: Da, to je negdje oko tamo. A9, ne znam. Morao bi dobili svoj binarni da decimalnog kalkulator. Moj mozak ne radi tako. PUBLIKA: Just a quick jedan Vaše Mongo komentarima. Tako je ID objekt koji dolazi nativno sa Mongo učiniti? RICK Houlihan: Da li to učiniti? Ako ga odrediti. Uz MongoDB, imate opciju. Možete specify-- svaki dokument u MongoDB mora imati donju ID. To je jedinstvena vrijednost. 

U MongoDB možete odrediti je li to hash ili ne. Oni samo vam dati mogućnost. Ako znate da je slučajna, nema problema. Ne morate to učiniti. Ako znate da to nije slučajno, da je to je povećavati, onda mljeveno meso. 

Sada je stvar o raspršivanja, nakon što hash value-- a to je zašto hash ključeva uvijek jedinstveni upiti, jer sam promijenila vrijednost, sada ne mogu napraviti upit raspona. Ne mogu reći je to između ovog ili onog, jer hash vrijednost ne ide se ekvivalentna stvarne vrijednosti. Dakle, kada ste razmotrili da ključ, to je samo jednakost. To je razlog zašto u DynamoDB hash ključa Upiti su uvijek samo jednakost. 

Tako sada u rasponu key-- kad sam dodati da je raspon ključ, one ključne zapisi raspon svi doći i oni se pohranjuju na istoj particiji. Dakle, oni su vrlo brzo, jednostavno dohvatiti jer je to mljeveno meso, ovo je raspon. I vidiš sve s istim hash dobiva pohranjene na istoj particiji prostoru. Možete koristiti taj raspon ključ za pomoć pronađite svoje podatke u neposrednoj blizini svojih roditelja. Pa što ja zapravo radim ovdje? Ovo je jedan za mnoge odnos. Odnos između hash ključa a ključ raspon je jedna mnogima. Ja mogu imati više hash ključeva. Ja mogu imati samo višestruki izbor Tipke unutar svakog hash ključa. 

Hash definira roditelja, Raspon definira djecu. Tako možete vidjeti da postoji analogni ovdje između relacijske konstrukt i iste vrste gradi u NoSQL. Ljudi govore o NoSQL kao nonrelational. Nije nonrelational. Podaci uvijek ima odnose. Ti odnosi samo su po uzoru na drugačiji način. Razgovarajmo malo malo o trajnosti. Kada pišete na DynamoDB, piše uvijek tri puta replicirati. Znači da imamo tri AZ-a. AZ-a su dostupnost zone. Možete misliti o raspoloživosti Zona kao podatkovnom centru ili skup podatkovnih centara. Ove stvari su geografski izolirane jedna od druge u različitim zonama rasjeda, preko različite energetske mreže i poplavna područja. Neuspjeh u jednom AZ nije će srušiti drugu. Oni su također povezani zajedno s tamnim vlakana. Ona podržava jednu podmornicu 1 milisekundu latencije između AZS. Tako stvarnom vremenu podatke ponavljanja stanju u multi AZS. 

I često za više AZ implementacija zadovoljiti visoke zahtjeve dostupnosti većine poduzeća organizacija. Dakle DynamoDB se širi preko tri AZS po defaultu. Mi samo će znanja pisati kada su dva od ta tri čvorova vratiti i reći: Da, ja sam ga dobio. Zašto je to? Budući da na strani čitanje smo samo će vam dati podatke natrag kada smo ga dobili od dva čvora. 

Ako sam replicira preko tri, a čitam od dva, Ja sam uvijek zajamčena da ima barem jednu onih čita biti Najnovija kopija podataka. To je ono što čini DynamoDB dosljedan. Sada možete odabrati okrenuti oni dosljedni čita off. U tom slučaju ću reći, Samo ću pročitati iz jednog čvora. A ja ne mogu jamčiti da će da su najnovije podatke. 

Dakle, ako je pisati dolazi u, to još nije replicirati, ti si idući u dobiti taj primjerak. To je u konačnici u skladu pročitati. A što je to je pola cijene. Dakle, to je nešto razmišljati o tome. Kada čitate iz DynamoDB i ti si postavljate svoju sposobnost čitanja jedinica, ako se odlučite na kraju dosljedni čita, to je puno jeftinije, to je oko pola cijene. 

I tako štedi vaš novac. Ali to je tvoj izbor. Ako želite dosljedan čitanje ili eventualnim skladu pročitati. To je nešto što se može birati. 

Razgovarajmo o indeksima. Tako smo spomenuli da najviša razina agregacije. Imamo hash ključeva, i imamo raspon tipki. To je lijepo. I to je na glavnoj tablici, sam dobio jedan hash ključ, dobio sam jednu tipku raspona. 

Što to znači? Imam jedan atribut koji sam možete pokrenuti bogate upite protiv. To je ključ raspona. Ostali atributi na tom item-- Ja mogu filtrirati na tim atributima. Ali ja ne mogu raditi stvari kao što su, to počinje ili je veća od. 

Kako ću to učiniti? Ja stvoriti indeks. Postoje dvije vrste indeksi u DynamoDB. Indeks stvarno još jedan pogled na stol. A lokalni sekundarne indeksa. 

Prvi ćemo razgovarati o tome. Dakle, lokalni sekundarne su koegzistirale na istoj particiji kao i podataka. I kao takvi, oni su na isti fizički čvor. Oni su ono što nazivamo dosljedan. Značenje, oni će priznati umanjenje uz stol. Kada je pisati dolazi u, ćemo pisati po indeksu. Mi ćemo pisati do stola, a onda ćemo priznati. Tako da je dosljedan. Nakon što je pisanje bio priznao iz tablice, to je zajamčeno da Lokalni sekundarne indeksa će imati istu viziju podataka. No, ono što vam omogućiti učiniti je definirati alternativni raspon tipki. 

Moraju koristiti isti hash Ključ kao primarni stola, jer su zajedno nalazi se na Isto particiju, a oni su dosljedni. Ali mogu stvoriti indeks s različitim ključevima dometa. Tako na primjer, ako sam imao proizvođaču koji je imao sirovi stol dijelovi dolaze u. I sirovo dijelovi dolaze u, a oni su agregirani Skupština. A možda postoji i opoziv. 

Svaki dio koji je izradio ovu Proizvođač nakon tog datuma, Moram se povući iz moje linije. Ja mogu vrtjeti indeks da će biti u potrazi, agregiranja na dan proizvodnja od tog dijela. Dakle, ako je moj top level stol bio već raspršen po proizvođaču, možda je to bio raspoređeni na dijelu ID, sam može stvoriti indeks izvan tog stola kao raspršen proizvođač i kretao se na datum proizvodnje. I to način na koji sam mogao reći, sve što je proizveden između tih datuma, Moram se povući iz linije. Dakle, to je lokalna sekundarne indeksa. 

Oni imaju učinak ograničavati vašu hash ključ prostor. Jer su koegzistirale Na isti čvor za pohranu, ograničavaju hash ključ Prostor do 10 gigabajta. DynamoDB, pod tablice, bit particije Vaš stol svakih 10 gigabajta. Kada ste stavili 10 nastupa podataka u, mi go [PhH], a mi dodati još čvor. 

Nećemo podijeliti LSI na više particija. Mi ćemo podijeliti stol. Ali nećemo podijeliti LSI. Dakle, to je nešto važno razumjeti je ako radite vrlo, vrlo, vrlo velike agregacije, onda ćeš biti ograničen 10 gigabajta na vašem LSIs. 

Ako je to slučaj, možemo koristiti globalne Sekundarne. Globalni sekundarne su zapravo još jedan stol. Oni postoje potpuno off strana vaše primarne tablice. I dopustite mi da pronaći potpuno drugačije strukture. Dakle, mislim da je to podaci se umeće u dvije različite tablice, strukturirana na dva različita načina. 

Mogu definirati potpuno različite ljestve tipku. Mogu definirati potpuno različiti raspon ključ. I ja mogu pokrenuti ovo potpuno samostalno. Kao Zapravo, imam opremiti svoje sposobnosti čitanja i napisati kapacitet za moje globalne sekundarne indeksa potpuno samostalno moje primarne tablice. Ako sam definirati taj indeks, kažem to koliko je čitati i pisati Kapacitet će to biti koristeći. 

I to je zasebna iz moje primarne stola. Sada oba indeksa nam omogućiti da ne samo definirati hash i raspon tipki, ali oni nam omogućiti da projekt dodatne vrijednosti. Dakle, ako želim očitati indeks, a ja želim da se neki skup podataka, Ne treba se vratiti na glavni Tablica dobiti dodatne atribute. Ja mogu projicirati one dodatne atributa u tablici podržati pristup uzorak. Znam da vjerojatno uzimajući u neke zapravo, really-- uzimajući u korov ovdje na neke od ovih stvari. Sada sam dobio da nestanu iz ovoga. 

PUBLIKA: [nečujan] --table ključ značilo je mljeveno meso? Izvorni mljeveno meso? Multi-letvice? 

RICK Houlihan: Da. Da. Tablica Ključ osnovi ukazuje natrag stavke. Dakle, indeks je pokazivač natrag izvorne su stavke na stolu. Sada možete odabrati izgraditi Indeks koji ima samo ključ stol, i nema drugih nekretnina. I zašto bih mogao učiniti? Pa, možda imam jako velike stvari. 

Ja stvarno samo trebate znati which-- moj pristup obrazac moglo bi se reći, koje stavke sadrže ovu nekretninu? Ne morate vratiti stavke. Samo trebam znati koje stavke ga sadrže. Dakle, možete izgraditi indekse da samo imaju ključ stol. 

No, to je prije svega što indeks u bazi podataka je za. To je za bitak u mogućnosti da brzo utvrditi koji bilježi, koji redaka, koji stavke u tablici imaju svojstva da sam u potrazi za. 

GSIS, pa kako oni rade? GSIS osnovi su asinkroni. Ažuriranje dolazi u tablici, Tablica zatim asinkrono ažurira sve svoje GSIS. To je razlog zašto su GSIS na kraju dosljedan. 

Važno je napomenuti da kada ste izgradnju GSIS, i shvatite da ste stvaranje druga dimenzija aggregation-- Sada recimo dobar primjer Ovdje je proizvođač. Mislim da sam možda govorio o medicinski proizvođač uređaja. Proizvođača medicinskih proizvoda često imaju serijaliziranom dijelove. Dijelovi koji idu u zamjena hip sve imati malo serijski broj na njih. I oni mogli imati milijune i milijuni i milijarde dijelova u svim uređajima koji su brod. Pa, što im je potrebno sakupiti pod različite dimenzije, svi dijelovi u skupštini, sve dijelovi koji su izrađeni na određenu liniju, sve dijelovi koji su došli iz određenog proizvođača na određeni datum. I ove agregate ponekad ustajati u milijardama. 

Tako sam raditi s nekim od ti dečki koji pate jer oni stvaraju ove ginormous agregacije u svojim srednjim indeksa. Oni bi mogli imati sirovih dijelova tablicu koja dolazi kao jedini mljeveno meso. Svaki dio ima jedinstveni serijski broj. Koristim serijski broj kao mljeveno meso. Lijepo je. Moj sirove tablice podataka se širi diljem razmaknicu. Moj [? pisati ?] [? Gutanje?] je strašan. Ja se puno podataka. Onda ono što rade je oni stvorili GSI. A ja kažem, znate što, moram vidjeti svi dijelovi za ovog proizvođača. Pa, odjednom sam uzimajući milijardu redaka, i stvari ih na jedan čvor, jer kada Ja agregat kao Proizvođač ID kao mljeveno meso, i dio broj kao raspon, onda odjednom sam stavljajući milijardu dijelova u ono što ovaj proizvođač mi je isporučio. 

To može izazvati mnogo pritiska na GSI, opet, jer sam zakucavanje jedan čvor. Ja sam stavljajući sve to unosi u jedan čvor. I to je pravi problematična uporaba slučaj. Sad, dobio sam dobar dizajn obrazac kako biste izbjegli da. I to je jedan od problema da sam uvijek raditi. No, ono što se događa, je možda GSI nema dovoljno kapaciteta za pisanje da bi mogli gurnuti svima redaka u jedan čvor. A što se događa onda je Primarni, stol klijenta, primarni stol će se grlo jer GSI ne mogu držati korak. Dakle, moj umetak stopa će padaju na primarnoj tablici kao moj GSI pokušava pratiti. 

U redu, tako GSI-a, LSI-a, koje bih trebao koristiti? LSI-a su konzistentni. GSI-a su na kraju dosljedni. Ako je to u redu, preporučujem pomoću GSI, oni su mnogo fleksibilniji. LSI-a može se modelirati kao GSI. A ako je veličina podataka po hash ključeva u vaša zbirka prelazi 10 gigabajta, onda idete da želite koristiti da GSI, jer to je samo teško granica. 

U redu, skaliranje. Propusnost u Dinamo DB, što CAN odredba [nečujan] Propusnost na stolu. Imamo kupce koji imaju opremiti 60 billion-- rade 60 milijardi zahtjeve, redovito radi na više od milijun zahtjeva po sekundi na našim stolovima. Tu stvarno nema teoretska granica koliko i koliko brzo stol može izvoditi u Dynamo DB. Postoje neke mekane ograničenja na svoj račun da stavimo tamo, tako da ne polude. Ako želite više od da, nije problem. Dolaziš nam. Mi ćemo okrenuti kotačić. 

Svaki račun je ograničena na nekoj razini u svakom servis, jednostavno isključiti šišmiš tako da ljudi ne polude se dobiti u nevolje. Nema ograničenja u veličini. Možete staviti bilo koji broj predmeta na stolu. Veličina stavke se ograničena na 400 kilobajta svaki, da bi se predmet ne atribute. Dakle, zbroj svih atributa je ograničen do 400 kilobajta. A onda opet, imamo da malo LSI problem sa 10 gigabajta granice po mljeveno meso. PUBLIKA: Mali broj, ja sam nedostaje ono što mi govori, da is-- PUBLIKA: Oh, 400 kilobajt je maksimalna veličina po stavku. Dakle, predmet ima sve atribute. Dakle, 400 k je ukupna veličina za tu stavku, 400 kilobajta. Dakle, od svih atributa Spojeni, svi podaci to je u svim tim atributima, smotati u ukupnoj veličini, Trenutno je danas granica stavka je 400 k. Pa opet skaliranje, postignuti kroz particioniranje. Propusnost se opremiti na razini tablice. I tu je zapravo dva gumba. Čitali smo kapacitet i pisati kapaciteta. 

Dakle, to se podešavaju međusobno nezavisno. Daljinskom upravljaču je mjera strogo u skladu čita. U redu, pa ako govoriš Želim 1.000 RCU a to su strogo u skladu, one su u skladu čita. Ako kažeš želim eventualni skladu čita, možete odredba 1.000 RCU-a, idete dobiti 2.000 kraju dosljedna čita. A pola cijene za one na kraju se sastoji u čita. 

Opet, prilagođen međusobno nezavisno. I oni imaju throughput-- Ako konzumiraju 100% vašeg daljinskog upravljača, nećeš utjecali na dostupnost svojih prava. Dakle, oni su potpuno neovisno jedan od drugoga. U redu, tako da jedna od stvari koje Spomenuo sam nakratko proporcionalnost. Proporcionalnost je loše. Proporcionalnost pokazuje loše ne SQL. Postoje stvari koje možemo učiniti kako bi pomogli što razriješi proporcionalnost koja vas doživljavamo. No, najbolje rješenje da je to neka je uzme Pogled na ono što radite, jer postoji anti-uzorak u igri ovdje. 

Ove stvari, stvari poput nejednakih opterećenja, vruće tipke, vruće particije. Ja sam udarajući određenu ključnu prostor vrlo teško za nekog posebnog razloga. Zašto mi radiš to? Idemo shvatiti da se. Ja sam za miješanje moje vruće podatke s hladnim podataka. Ja sam ostavljajući moj tablice doći ogroman, ali je stvarno samo neki podskup podataka to je stvarno zanimljivo za mene. Tako je za log podataka, na primjer, puno kupci su dobili prijavu podataka svaki dan. Oni su dobili veliku količinu podataka log. 

Ako ste samo bacanje sve te zapisnik podataka u jedan veliki stol, s vremenom da stol će dobiti masivni. Ali ja sam zapravo samo zanima posljednjih 24 sata, u posljednjih sedam dana, posljednjih 30 dana. Bez obzira na prozor vremena da sam zainteresiran u potrazi za događaj koji me muči, ili događaj koji je zanimljiv za mene, to je jedini prozor put da mi treba. Pa zašto sam stavljajući 10 godina vrijednosti log podataka u tablici? Ono što uzrokuje je stol fragment. 

Ona dobiva ogroman. Ona počinje širi preko tisuću čvorova. A od vaše sposobnosti je tako niska, da ste zapravo ocijeniti ograničavajući se na svaki jedan od onih pojedinačnih čvorova. Tako ćemo početi gleda na tome mi uvaljati taj stol više. Kako smo uspjeli da se podaci malo Bolje bi izbjegli ove probleme. A što to izgledati? To je ono što to izgleda. To je ono loše NoSQL izgleda. 

Imam vruća tipka ovdje. Ako pogledate na strani ovdje, to su sve moji particije. Imam 16 particije ovdje na ovaj bazi podataka. Mi to cijelo vrijeme. Trčim ovo za kupce svih vremena. To se zove karta topline. Karta Toplina mi kaže kako ste Pristupom vaš ključ prostor. A što to mi govori je da postoji jedna posebna mljeveno meso da je ovaj tip voli strašno puno, jer je udaranje jako, jako teško. 

Dakle, plava je lijepo. Mi smo željeli plava. Mi se ne sviđa crveno. Red je gdje je tlak dobiva do 100%. 100%, sad ćeš biti ograničeni. Dakle, kad god vidim nikakve crvene linije poput this-- i to ne samo Dinamo DB-- svaki NoSQL baza podataka ima taj problem. Postoji anti-obrasce koji mogu voziti ove vrste uvjeta. Ono što ja radim je ja radim s klijentima da razriješi ove uvjete. 

A što to izgledati? I to je sve najbolje iz Dynamo DB propusnosti, ali zapravo je dobivanje najviše iz NoSQL. To nije ograničeno na Dynamo. To je definitely-- sam koristi za rad na Mongo. Ja sam upoznat s mnogim NoSQL platformama. Svatko ima ove vrste vruće ključnih problema. Da biste dobili najviše iz bilo NoSQL baze podataka, posebno Dinamo DB, želite stvoriti tablice gdje element ljestve tipku ima velik broj različitih vrijednosti, visok stupanj kardinaliteta. Jer to znači da pišem na puno različitih kante. 

Više kante sam pisanom obliku, to je vjerojatnije Ja sam širiti Pisanje je opterećenje ili pročitao učitavanje van na više čvorova, vjerojatnije sam imati visoke propusnosti na stolu. A onda želim vrijednosti se traži prilično ravnomjerno tijekom vremena i ravnomjerno kao slučajno što je više moguće. Pa, to je vrsta zanimljiv, jer ja stvarno ne mogu kontrola kada su korisnici dolaze. Dakle, dovoljno je reći da smo širiti stvari se preko ključnih prostora, ćemo vjerojatno biti u boljoj formi. 

Postoji određena Iznos vrijeme isporuke da ne ide Da bi mogli kontrolu. Ali oni su stvarno dvije dimenzije koje imamo, prostor, pristup ravnomjerno širenje, vrijeme, zahtjevi Dolazite ravnomjerno raspoređeni u vremenu. A ako ta dva su ispunjeni uvjeti, onda je to ono što je će izgledati. To je puno zgodniji. Mi smo jako sretni ovdje. Imamo vrlo čak pristupnu uzorak. Da, možda ste uzimajući malo pritisak svaki sada i onda, ali ništa stvarno previše opsežna. Dakle, to je nevjerojatno koliko puta, kad sam raditi s klijentima, taj prvi graf s velikom crvenom bar i sve to ružna žuta je sve više mjesta, mi bi učinio s vježbe nakon par mjeseci ponovnog arhitekture, oni prikazuju točno isto opterećenje na isti teret. A to je ono što se gleda kao sada. Dakle, ono što ste dobili s NoSQL je Podaci shema koja je apsolutno vezan do pristupne uzorak. 

A možete optimizirati tu podataka sheme podržati taj pristup uzorak. Ako ne, onda idete vidjeti one vrste problema s tim vruće tipke. 

PUBLIKA: Pa, neizbježno neka mjesta će biti topliji od drugih. 

RICK Houlihan: Uvijek. Uvijek. Da, mislim da uvijek postoji A- i opet, tu je neki dizajn obrazaca ćemo kroz koji će govoriti o tome kako se nositi s tim super velike agregate. Mislim, moram ih imati, kako ćemo se nositi s njima? Imam prilično dobro iskoristiti slučaj da ćemo razgovarati o za to. 

U redu, razgovarajmo oko neke stranke sada. Ovi momci su AdRoll. Ne znam ako ste upoznati s AdRoll. Možete ih vjerojatno vidjeti puno u pregledniku. Oni ad re-ciljanje, oni su Najveći oglas ponovno ciljanje poslovanje Tamo vani. Oni obično redovito pregaziti 60 milijardi transakcija dnevno. Oni rade preko milijun transakcija u sekundi. Imaju prilično jednostavan stol struktura, najprometniju tablica. To je u osnovi samo hash ključ je kolačić, Raspon je demografska kategorija, a onda treći atribut je rezultat. 

Dakle, svi smo kolačiće naš preglednik od tih dečki. A kad idete na sudjeluje trgovca, oni zapravo vas osvojiti preko različite demografske kategorije. Kada ići na web stranicu i kažeš želim vidjeti ovu ad-- ili u osnovi ne reći that-- ali kad idete na web stranicu kažu želite vidjeti ovaj oglas. I oni ići dobiti taj oglas iz AdRoll. AdRoll vas gleda na njihovom stolu. Smatraju svoj kolačić. Oglašivači govore ih, želim nekoga tko je sredovječan, 40-godišnji muškarac, u sport. I ti gol u tih demografskih i oni odlučuju hoće li ili ne to je dobra oglas za vas. 

Sada imaju SLA s njihovi oglašavanje usluga pružiti sub-10 milisekunda Odgovor na svaki zahtjev. Tako oni koriste Dynamo DB za to. Oni nam je udaranje milijuna zahtjeva u sekundi. Oni su u stanju učiniti sve svoje upiti, trijaža sve podatke, i dobiti da dodate link natrag na koji oglašivaču manje od 10 milisekundi. To je stvarno lijepa fenomenalna Provedba da imaju. 

Ovi momci actually-- su ovi momci. Nisam siguran je li to ovi momci. Možda se ti momci. Uglavnom us-- rekla ne, Ne mislim da ih je bilo. Mislim da je to bio netko drugi. Radio sam s kupac koji mi je rekao da je sada da ste otišao u Dinamo DB, oni su trošiti više novca na zalogaje za njihov razvojni tim svaki mjesec nego što troše na njihovu bazu podataka. Dakle, to će vam dati Ideja uštede koje možete dobiti u Dynamo DB je ogroman. U redu, dropcam je još jedna tvrtka. To je vrsta čovjek of-- ako mislite internet stvari, dropcam je u osnovi Internet sigurnost videa. Možete staviti kameru vani. Fotoaparat ima detektor pokreta. Netko dolazi zajedno, aktivira bijela točka. Fotoaparat se počne snimati za vrijeme dok to ne otkrije nikakav prijedlog više. Stavlja taj video na internetu. 

Dropcam je tvrtka koja je osnovi prebacio na Dinamo DB jer su suočili ogromne Growing Pains. I ono što su nam rekli, Odjednom petabajta podataka. Oni nisu imali pojma svoju službu će biti tako uspješan. Više ulazni videozapis od YouTubea je ono što ti dečki su uzimajući. Oni koriste DynamoDB pratiti sve metapodataka na svim svojim video ključnih točaka. 

Tako su S3 kante su gurnuti svi binarni predmeti u. A onda su Dinamo DB zapisi koji upućuju ljude na one S3 tri predmeta. Kad im je potrebno da pogledate video, oni izgledaju gore rekord u Dinamo DB. Oni kliknite na link. Oni srušiti video iz S3. Dakle, to je vrsta kako to izgleda. A to je ravno iz njihovog tima. 

Dinamo DB smanjuje njihovu Vrijeme isporuke za video događaje od pet do 10 sekundi. U svom starom relacijske trgovine, oni koriste da moram ići i izvršiti više složene upite na slici koji video srušiti, na manje od 50 ms. Dakle, to je nevjerojatno, nevjerojatno koliko performanse možete dobiti kada optimizirati i Vi podešavanje baze podataka temeljne podržati pristup uzorak. Halfbrick, ti ​​dečki, što je to, Voće Ninja Valjda je njihova stvar. To sve radi na Dinamo DB. A ovi momci, oni su veliki razvojni tim, veliki razvoj dućan. 

Nije dobra ops tim. Nisu imali puno operacijskih resursa. Oni su bore pokušavajući zadržati njihova primjena infrastruktura se i trčanje. Došli su k nama. Gledali su taj Dinamo DB. Kažu, to je za nas. Oni su izgradili svoju cjelinu aplikacija okvir na njega. Neki stvarno lijepo komentari ovdje iz tima na njihovu sposobnost sada usredotočiti na izgradnju igra, a ne da se održavanje infrastrukture, koji postaje ogromna količina nadzemnih za njihovu momčad. Dakle, to je nešto that-- koristi koje ste dobili od Dynamo DB. 

U redu, uzimajući u Podaci modeliranje ovdje. I razgovarali smo malo o ovaj jedan na jedan, jedan za mnoge, i mnogi mnogi tip odnosa. I kako zadržati one u Dinamo. U Dinamo DB koristimo indeksi, općenito govoreći, rotirati podatke iz jedan drugi okus. Hash ključeva, raspon ključeve i indekse. 

U ovom konkretnom Primjer, kao i većina država imaju uvjet licenciranja koji Samo jedan vozačku dozvolu po osobi. Ne možete ići dobiti dva vozača licence u državi Bostonu. Ne mogu to učiniti u Teksasu. To je vrsta na način na koji je. I tako na DMV, imamo dohvate, mi želite potražiti u vozačku dozvolu od broja socijalnog osiguranja. Želim pogledati pojedinosti o korisniku po licenci broj vozačeva. 

Tako smo mogli imati korisnički stol koji ima hash tipku na serijski broj, ili broj socijalnog osiguranja, te Različiti atributi definirani na stavku. Sada na tom tablice I. može definirati GSI da flips da oko toga govori želim hash ključ na dozvole, a zatim sve ostale stavke. Sada, ako želim da upita i pronaći licenca broj za bilo koju socijalnu Sigurnosni broj, ja mogu upita glavni stol. 

Ako želim da upita i želim dobiti socijalnu sigurnost broj ili druge osobine po broj licence, mogu upit GSI. Taj model je da jedan na jedan odnos. Samo vrlo jednostavna GSI, Flip te stvari oko sebe. Sada, govoriti o jednom mnogima. Jedan mnogima je u osnovi Vaš ljestve raspon ključ. Gdje smo dobili puno s ovim Korištenje slučaj podaci monitor. Monitor podataka dolazi u redoviti Interval poput interneta stvari. Mi uvijek dobiti sve te zapisi dolaze u sve vrijeme. 

I želim pronaći sve čitanja između određenom vremenskom razdoblju. To je vrlo čest upit u nadzor infrastrukture. Način ići oko koje se pronaći jednostavna tablica strukture, jedan stol. Imam tablicu mjerenja uređaja s hash ključa na ID uređaja. I ja imam niz tipku na timestamp, ili u ovom slučaju, ep. I to mi omogućuje izvršavanje kompleks upiti protiv tog raspona ključa i vratiti one zapise koji su u odnosu na rezultat postaviti da tražim. I to gradi da je jedan mnogima odnosa u osnovnoj tablice koristeći ljestve tipku, raspon ključna struktura. 

Dakle, to je vrsta izgrađena u tablici u Dinamo DB. Kad sam definirati hash i raspon t stol, ja sam definiranje jedan mnogima odnosa. To je odnos roditelj-dijete. 

Razgovarajmo o mnogim mnogim odnosima. I za ovaj poseban primjer, opet ćemo koristiti GSI-a. I pričajmo o igranju scenarij u kojem imam određenog korisnika. Želim saznati sve igre koje on je registriran za ili igranje u. A za određenu igru, ja želite pronaći sve korisnike. Pa kako ću to učiniti? Moj korisnički igre stol, idem imati hash ključ korisničkog ID i niz ključ igre. 

Tako korisnik može imati više igre. To je jedan za mnoge odnos korisnik i igrice igra. A onda na GSI, Ja ću okrenuti da oko. Ja ću hash na igru ​​i Ja ću se kreću na korisnika. Dakle, ako želim dobiti sve Igra korisnik je igranje u, Ja ću upita glavni stol. Ako želim da se sve korisnike koji igraju određenu igru, Ja upit GSI. Dakle vidite kako mi to radimo? Možete graditi ove GSI-a za podršku Uporaba slučaj, aplikacije, pristup uzorak, primjena. 

Ako trebam upita na ta dimenzija, neka ja stvoriti indeks na toj dimenziji. Ako ja ne, nije me briga. I ovisno o upotrebi slučaju, Možda ćete morati indeks ili ja ne mogu. Ako je jednostavan za mnoge, primarni stol je u redu. Ako trebam učiniti te mnogi mnogo je, ili ću morati učiniti nešto za sebe, onda možda ja trebam na drugi indeks. Dakle, sve ovisi o ono što pokušavam učiniti a ono što ja pokušavam dobiti ostvariti. 

Vjerojatno neću potrošiti previše koliko vremena govorimo o dokumentima. To dobiva malo, vjerojatno, dublje od moramo ići u. Razgovarajmo malo O bogat izraz upita. Tako je u Dynamo DB imamo sposobnost za stvaranje ono što nazivamo projekcija izraze. Projekcijski izrazi jednostavno branje polja ili vrijednosti koji želite prikazati. U redu, tako da napravite izbor. Ja bi upit protiv Dynamo DB. A ja kažem, znate što, emisija mene samo zvijezda recenzije pet za ovaj proizvod. Tako da je sve što želim vidjeti. Ne želim vidjeti sve ostali atributi u redu, Samo želim vidjeti. To je baš kao u SQL kada kažu odaberite zvijezdu ili od stola, dobivate sve. Kad kažem odaberite ime iz stol, samo sam dobiti jedan atribut. To je ista vrsta stvar u Dinamo DB ili još NoSQL baze podataka. Filter izrazi mi dopustiti da osnovi smanjiti rezultat postavljen prema dolje. Tako sam napraviti upit. Upit se može vratiti s 500 predmeta. Ali ja samo želim stavke koje imaju atribut koji kaže ovo. OK, neka je filtrirati one stavke koji se ne slažu da se određeni upit. Dakle, imamo filter izraze. 

Filtriranje izrazi mogu može izvoditi na bilo koji atribut. Oni ne vole raspon upita. Podići upiti su selektivniji. Filter upiti me zahtijevaju otići dobiti cijeli rezultati postavili, a zatim izboriti podatke ne želim. Zašto je to važno? Budući da je sve pročitao sam. U upitu, idem čitati i to će biti divovski o podacima. A onda ću izboriti ono što mi treba. A ako sam samo rezbarenje out par redaka, onda je to u redu. To nije tako neučinkovit. 

Ali ako čitam cijelu hrpu Podaci, samo da izgrade jednu stavku, onda ću biti bolji isključiti pomoću upita raspona, jer je mnogo selektivniji. To će mi uštedjeti puno novac, jer sam platiti za to čitanje. Gdje su rezultati koje vraća prijeći žicu može biti manji, ali ja plaćam za čitanje. Pa razumijem kako ste uzimajući podatke. To je vrlo važno u Dynamo DB. 

Uvjetne izrazi, to je ono što što bi se moglo nazvati optimističan zaključavanje. Ažuriranje ako postoji, ili ako te vrijednosti je ekvivalent za ono što sam odrediti. I ako imam vremena na rekord, ja mogu pročitati podatke. Možda ću promijeniti te podatke. Možda ću ići napisati da podatke natrag u bazu podataka. Ako je netko promijenio rekord, timestamp možda su se promijenili. I na taj način moj uvjetovana Ažuriranje mogao reći ažuriranje ako je vremenska oznaka jednaka ovo. Ili ažuriranje neće uspjeti jer je netko ažurira rekord u međuvremenu. 

To je ono što mi zovemo optimistično zaključavanje. To znači da je netko može doći i to promijeniti, i ja ću ga otkriti kad se vratite pisati. A onda sam zapravo može pročitati da Podaci i reći, oh, on je promijenio ovo. Trebam račun za to. I ja mogu mijenjati podatke u mom snimanje i primijeniti drugi ažuriranje. Tako možete uhvatiti one inkrementalni ažuriranja koje se javljaju između vremena da ste pročitali podatke i Vrijeme možete pisati podatke. 

PUBLIKA: A filter Izraz zapravo znači ne u broju ili not-- 

[Ubacivanjem GLAS] RICK Houlihan: Neću dobili previše u to. To je rezervirano za ključne riječi. Pogled funta je rezerviran ključna riječ u Dynamo DB. Svaka baza ima svoju pridržana imena za zbirke ne mogu koristiti. Dinamo DB, ako navedete funta pred tim, možete definirati ta imena iznad. Ovo je naveden vrijednost. To je vjerojatno nije najbolji sintaksa se ima tamo za ovu raspravu, jer dobiva u nekim real-- Ja bi razgovarali više o tome na dubljoj razini. 

No, dovoljno je reći, to bi moglo se upita skenirati gdje views-- , niti pregleda funta je veći od 10. To je numerička vrijednost, da. Ako želite, možemo govoriti o da je nakon rasprave. U redu, tako da smo uzimajući u neki scenariji u najbolje prakse gdje ćemo razgovarati o nekim aplikacijama ovdje. Koji su načini korištenja za Dinamo DB. Što su dizajn obrasce u Dinamo DB. 

I prvi ćemo Razgovor o je internet stvari. Tako smo dobili puno of-- pretpostavljam, što je it-- više od 50% prometa na internetu ovih dana zapravo generira strojeva, automatizirani procesi, a ne ljudi. Mislim ovo to što nosite okolo u džepu, koliko je podataka da je stvar zapravo slanje oko bez tebe znajući je apsolutno nevjerojatna. Vaš položaj, informacije o tome kako brzo idete. Kako misliš Google Maps djela kad ti reći što je promet. To je zato što postoje milijuni i milijuni ljudi vožnje oko s telefonima koji se šalju Podaci cijelom mjestu svih vremena. Dakle, jedna od stvari o ovoj vrsti podataka koji dolazi u, podaci monitor, prijavite podaci, podaci vremenskih serija, je da je obično samo zanimljivo za malo vremena. Nakon tog vremena, to je nije tako zanimljiva. Tako smo razgovarali o, ne dopustite one tablice rasti bez granica. Ideja je da možda imam 24 sati u vrijednosti od događaja u mom toplom stolu. I to vruće stol će biti opremiti na vrlo visoku stopu, jer je uzimanje puno podataka. To je uzimajući puno podataka i čitam ga puno. Imam puno rada upiti trčanje protiv te podatke. 

Nakon 24 sata, hej, što Znaš ono, nije me briga. Dakle, možda je svaki ponoći sam role moj stol na novu tablicu i ja deprovision ovaj stol. A ja ću daljinskom upravljaču-a i WCU je dolje, jer 24 sata Ja ne radi onoliko upiti protiv tih podataka. Tako ću uštedjeti novac. A možda 30 dana kasnije ja ne čak morati brinuti o svemu. Mogao sam uzeti WCU-a sve do jednog, jer znate što, to je nikada neće dobiti pisao. Podaci 30 dana. On nikada ne mijenja. 

I to je gotovo nikad ne događa da se čita, pa neka je samo uzeti taj daljinskom upravljaču do 10. I ja sam štedi tona novca na ovo podataka, a samo plaćati za moje vruće podataka. Tako da je važno da pogledate na kada pogledate vremenskoj seriji Podaci dolazi u volumenu. To su strategije. Sada, samo sam to mogao dopustiti sve ići istim stolom i samo neka to tablici raste. Na kraju, ja ću vidim problema s performansama. Ću morati početi arhivirati Neki od tih podataka sa stola, sitnica. 

Idemo puno bolje dizajn prijavu tako da može raditi na ovaj način u pravu. Dakle, to je samo automatska u aplikacijski kod. U ponoć svake noći role stol. Možda ono što mi treba je klizni prozor 24 sata podataka. Tada se redovito sam pozivajući podatke sa stola. Ja sam ga obrezivanje s Cron posao i ja sam ga stavljajući na tim drugim stolovima, sve što vam je potrebno. Dakle, ako rollover radi, to je sjajno. Ako ne, trim. Ali neka je zadržati vruće podatke daleko od svojih hladnih podataka. To će vam uštedjeti mnogo novca i Učinite svoj Stolovi više izvedbom. Dakle, sljedeća stvar ćemo razgovarati o je katalog proizvoda. Katalog proizvoda je prilično uobičajeni način korištenja. To je zapravo vrlo čest uzorak kako ćemo vidjeti u raznim stvarima. Znate, Twitter za primjer, vruće Tweet. Svatko dolazi i grabbing taj cvrkut. Katalog proizvoda, dobio sam prodaju. Imam vruće prodaju. Imam 70.000 zahtjeva po drugi dolazak za proizvod Opis iz mog kataloga proizvoda. Vidimo to na maloprodaji Operacija vrlo malo. Pa kako ćemo se nositi s tim? Ne postoji način da se nositi s time. Svi moji korisnici žele vidjeti isti podatak. Oni dolaze u, istodobno. I svi radite zahtjeve za isti dio podataka. To mi daje da vruća tipka, da veliki crveni pruga na mom grafikonu da mi se ne sviđa. I to je ono što to izgleda. Dakle, po mom razmaknicu Dobivam hammered na prodaju stavke. Dobivam ništa bilo gdje drugdje. 

Kako ublažiti ovaj problem? Pa, mi razriješi ovo s cache. Cache, stavite u osnovi u memoriji particija ispred baze podataka. Uspjeli smo [Nečujan] cache memorije, koliko vas Možete postaviti svoje vlastite cache, [nečujan] Cache [? d?] što god želite. Stavite da se ispred baze. I na taj način možete pohraniti te podatke od onih vruće tipke u toj predmemoriji Prostor i čitati kroz cache. 

A onda je većina svoje čita početi u potrazi ovako. Dobio sam sve to predmemorija hits ovdje i ja dobio ništa ne događa ovdje dolje jer baza je sjedio iza predmemorija i nikada ne čita doći. Ako sam promijeniti podatke u baze podataka, moram ažurirati cache. Možemo koristiti nešto kao i pare za to. A ja ću objasniti kako se to radi. U redu, poruka. E, svi smo koristili e-poštu. 

To je prilično dobar primjer. Imamo nekakvu tablicu poruke. I dobili smo Ulazni spremnik i Izlazni. To je ono što je SQL bi izgleda kao da izgrade taj inbox. Mi vrsta koristi istu vrstu strategije za korištenje GSI-a, GSI-a za moj inbox i outbox moje. Tako sam dobio sirovi poruke dolaze u mojim stolom poruke. I prvi pristup ova Možda, recimo, u redu, nema problema. Imam sirove poruke. Poruke dolaze [nečujan], ID poruke, to je super. To je moj jedinstveni hash. Idem napraviti dva GSI-a, jedan za moj inbox, jedan za moju outbox. I prva stvar koju ću učiniti je ću reći moje ljestve ključ će biti primatelj i Idem dogovoriti o datumu. Ovo je fantastično. Ja je dobio moj lijep pogled ovdje. No, tu je malo problem ovdje. I naiđete na ovo relacijske baze podataka, kao dobro. Zvali okomito particioniranje. Želite li zadržati svoj veliki podataka daleko od svoje malo podataka. 

A razlog zašto je zato što moram ići čitati stavke da biste dobili atribute. A ako moji organi su svi ovdje, onda čitate samo nekoliko stavki ako je moja dužina tijela je u prosjeku 256 kilobajta svaki, math dobiva prilično ružno. Tako kažu želim čitati Davida inbox. Davidov Spremnik ima 50 stavki. Prosječna veličina i je 256 kilobajta. Evo moj omjer konverzije za umetnute u daljinski traje četiri kilobajta. 

U redu, idemo s na kraju skladu čita. Ja sam još uvijek jede 1600 RCU-a samo čitati Davida inbox. Ouch. U redu, sad ćemo razmišljati o tome kako app radi. Ako sam na e-mail aplikacije i Gledam moje inbox, i sam pogled na tijelo svake poruke, Ne, ja sam gledajući sažetke. Gledam samo zaglavlja. Tako ćemo izgraditi strukturu tablice da izgleda kao da je. 

Dakle ovdje je informacija da je moj tijek rada treba. To je u mom inbox GSI. To je datum, pošiljatelj, predmet, a zatim ID poruka, što ukazuje natrag na stol poruke gdje mogu dobiti tijelo. Pa, to bi bio rekord iskaznice. Oni će ukazati natrag na Stavka ID na stolu Dinamo DB. Svaki indeks uvijek creates-- Uvijek ima stavku ID kao dio of-- da dolazi s indeksom. 

U redu. PUBLIKA: To je priča u kojoj je pohranjen? RICK Houlihan: Da, to govori exactly-- to je upravo ono što čini. Ona kaže evo moj ponovni rekord. I to će ga istaknuti u moj ponovni rekord. Točno. U redu, tako da sada moj inbox zapravo mnogo manji. I to je zapravo podržava tijek rada na e-mail aplikacije. Dakle moj inbox, ja kliknite. Sam ići zajedno, a ja kliknite na poruku, to je kad moram ići dobiti tijelo, jer ću ići na drugačiji pogled. Dakle, ako mislite o MVC vrsti okvir, prikaz modela kontroler. 

Model sadrži podaci da je pogled potrebe a kontroler interakciju s. Kad sam promijeniti okvir kada Ja promijeniti perspektivu, to je u redu da se vrati na poslužitelja i makrobentosa model, jer to je ono što korisnik očekuje. Kada su promijenili mišljenje, to je kad možemo se vratiti u bazu podataka. Tako e, kliknite. Ja sam u potrazi za tijelo. Povratna karta. Idi dobiti tijelo. 

Čitala sam puno manje podataka. Ja sam samo čitao tijela koja David treba kad ih je potrebno. I nisam spali u 1600 Umetnute u daljinski upravljač je samo pokazati svoj inbox. Tako sada that-- ovo je način da LSI ili GSI-- Žao mi je, GSI, će raditi. Imamo naš mljeveno meso na primatelja. Imamo ključ raspon na dan. I mi imamo projicirane atribute da nam je potrebna samo podržati pogled. 

Mi okretati da je za outbox. Hash o pošiljatelju. A u biti, imamo vrlo lijep, čist pogled. I to je basically-- smo imaju ovu lijepu poruku Stol koji je se proširila lijepo, jer to je samo mljeveno meso, raspršen poruka ID. I imamo dva indeksa koji su rotiranja tog stola. U redu, ovdje je ideja ne držati velike podatke i ovaj mali podatke zajedno. Partition vertikalno, particija te tablice. Nemojte čitati podatke koje ne morate. U redu, gaming. Mi svi vole igre. Barem mi se sviđa igre tada. Dakle, neke stvari da se bavimo kada mi smo razmišljati o igranju, zar ne? Gaming ovih dana, osobito mobilni igre, je sve o razmišljanju. I ja ću rotirati ovdje Malo dalje od DynamoDB. Ja ću dovesti u neke rasprave oko neke od drugi AWS tehnologije. 

No, ideja o igranju je misliti o u smislu API, API koji su, općenito govoreći, HTTP i JSON. To je kako mobilni igara vrsta komunicirati sa svojim stražnjim krajevima. Oni ne JSON postavljanje. Oni su dobili podatke, i to je sve, općenito govoreći, u lijepo JSON API. 

Stvari kao što su dobili prijatelja, dobiti Podaci ljestvici, razmjena, Korisnički generiran sadržaj, gurnuti natrag u sustav, To su vrste stvari kako ćemo to učiniti. Binarni podaci imovine, ovi podaci ne bi mogli sjediti u bazi podataka. To može sjediti u predmet trgovine, zar ne? No, baza podataka će se završiti govoreći sustava, govori prijavu gdje ići ga dobiti. I neizbježno, multiplayer poslužitelji, leđa kraj infrastrukture, i dizajniran za visoke dostupnost i skalabilnost. Dakle, to su stvari koje smo svi žele u gaming infrastrukture danas. 

Tako ćemo pogledati kako to izgleda. Imaš jezgre leđa kraj, vrlo jednostavan. Imamo sustav ovdje više slobodnih zona. Razgovarali smo o AZS kao being-- misle ih kao zasebne podatkovnih centara. Više od jednog podatkovnog centra po AZ, ali to je u redu, samo misliti o njima kao odvojenim podataka centri koji su geografski i krivnja izoliran. 

Mi ćemo imati Par EC2 slučajevi. Mi ćemo imati Neki leđa kraj servera. Možda, ako ste ostavština arhitektura, mi smo koristeći ono što mi zovemo RDS, relacijske baze podataka. usluge Može biti MSSQL, MySQL, ili tako nešto. To je način puno aplikacija su napravljeni danas. 

Pa ćemo možda želite ići s to je kad smo skala van. Mi ćemo ići naprijed i staviti je S3 kantu tamo gore. I to S3 Kanta, umjesto služenja do tih objekata iz naše servers-- smo mogli učiniti. Možete staviti sve svoje binarni objekti na vašim poslužiteljima a možete koristiti one poslužitelj slučajevi da služi da se podaci up. No, to je prilično skupo. 

Bolji način za to je ići naprijed i staviti one predmete u S3 kantu. S3 je objekt spremišta. To je izgrađen posebno za služeći se ove vrste stvari. I neka ti zatražiti klijenti izravno iz tih objekata kante, riješiti poslužiteljima. Tako smo početkom u mjerilu ovdje. 

Sada imamo korisnicima u cijelom svijetu. Imam korisnicima. Moram imati sadržaj lokalno nalazi u neposrednoj blizini tih korisnika, zar ne? Ja sam stvorio S3 kantu kao moj izvor repozitorij. I ja ću to s prednje distribucija CloudFront. 

CloudFront je CD i Mreža sadržaja. Uglavnom je potrebno podatke koje ste naveli i sprema sve preko interneta tako da korisnici mogu imati svugdje vrlo brz odgovor kada oni tražiti te objekte. 

Tako ćete dobiti ideju. Ti vrsta utjecati sve aspekti AWS ovdje da biste dobili ovaj učinio. I na kraju, bacamo u auto skaliranja skupine. Tako naše AC2 slučajevima naših poslužitelja igre, što počnu zaposleniji i zaposleniji i zaposleniji, oni samo će zavrtiti još primjer, zavrtjeti još jedan primjer, vrtjeti nove instance. Dakle, tehnologija AWS ima, to omogućuje vam da odredite parametre oko koje Vaši poslužitelji će rasti. Tako možete imati n broj poslužitelja vani u bilo kojem trenutku. A ako je vaš teret ide dalje, oni će smanjiti broj će se smanjiti. A ako je teret vrati, to će rasti natrag, elastično. 

Dakle, ovo izgleda super. Imamo puno EC2 slučajevima. Možemo staviti u predmemoriju Prednji baza podataka, pokušati ubrzati baze podataka. Sljedeći točka tlaka obično ljudi vide je da skala igru ​​pomoću relacijskih baza podataka sustava. Isuse, baza podataka nastup je strašno. Kako poboljšati kako? Pokušajmo stavljajući predmemorija ispred toga. 

Pa, predmemorija ne radi tako velika u igrama, zar ne? Za igre, pisanje je bolno. Igre su vrlo teške pisati. Cache ne radi kada ste Napiši teška jer ste uvijek dobio ažurirati cache. Možete ažurirati cache, to je nebitno da caching. To je zapravo samo dodatni rad. 

Dakle, gdje ćemo ići ovdje? Imaš veliku usko grlo dolje u bazi podataka. A mjesto za izlazak Očito je particioniranje. Particioniranje nije jednostavno za napraviti kada ste bave relacijskim bazama podataka. S relacijskim bazama podataka, ti si odgovorna za upravljanje, djelotvorno, ključ prostor. Kažeš korisnike između A i M ići ovdje, između N i Z ići tamo. A ti prebacivanje preko aplikacije. Tako ste se bave ovaj izvor podataka particija. Imate transakcijske ograničenja koji se ne span particije. Imaš sve vrste nereda koji ste bavi dolje težak baviti skaliranje se i izgradnju većeg infrastrukture. To je samo ne zabavno. 

PUBLIKA: Znači želiš reći da je povećanje izvora bodove ubrzava postupak? RICK Houlihan: Povećanje? PUBLIKA: Izvor točke. RICK Houlihan: Izvor bodova? PUBLIKA: Od informacije, gdje se informacije dolaze iz? RICK Houlihan: Ne Ono što želim reći je povećanje broj particija u spremištu podataka poboljšava propusnost. Dakle, ono što se događa ovdje je korisnik dolaze u EC2 primjer ovdje, dobro, ako trebam korisnika To je na M, ja ću ovdje. Iz N u p, ja ću ovdje. Od P do Z, otići ću ovdje. 

PUBLIKA: OK, oni tako to su svi pohranjeni u različitim čvorovima? 

RICK Houlihan: Da. Razmislite o ovome kao različite silosi podataka. Tako da imate to učiniti. Ako pokušavate učiniti ovo, ako pokušavaš na ljestvici na relacijskoj platformi, to je ono što radite. Vi ste uzimajući podatke i ti si to smanjenje. A ti si ga particioniranje preko više instanci baze podataka. A ti upravljanju sve na aplikacijski sloj. To nije ni zabavno. Dakle, ono što mi želimo ići? Želimo ići DynamoDB, u potpunosti uspio, NoSQL podaci trgovine, odredba propusnost. Koristimo sekundarne indekse. To je u osnovi HTTP API i uključuje podršku dokument. Dakle, ne morate brinuti o bilo tog particioniranje. Mi sve to učiniti za vas. Tako sada, umjesto toga, napišite na stol. Ako tablica treba biti razdijeljena, što se događa iza kulisa. Vi ste u potpunosti izolirana od toga kao programer. Dakle, pričajmo o neki od slučajeva korištenja da naletimo na igranje, zajedničko igranje scenarija, leaderboard. Pa imaš korisnik dolazi, su BoardNames da su oni na, bodovi za tog korisnika. Možemo se raspršivanja na USERID a onda smo izbor na igru. Dakle, svaki korisnik želi vidjeti sve igra je igrao svi njegovi najbolji rezultat u svim igre. Dakle, to je njegov osobni leaderboard. 

Sada želim otići i želim get-- tako sam se ove osobne leaderboard. Ono što želim učiniti je otići dobiti Najviša ocjena u svim korisnicima. Pa kako ću to učiniti? Kad je moj rekord je raspršen na Id korisnika, kretao se na igru, dobro ću ići naprijed i restrukturiranje, stvoriti GSI, i ja ću restrukturirati te podatke. 

Sada ću hash na BoardName, što je igra. I ja ću se kreću na vrhu ocjenu. I sada sam stvorio različite kante. Ja sam koristeći isti stol, Isti podaci stavke. Ali ja sam stvara kantu koja daje ja gomilanje gornjem bodova po igri. 

I ja se upit koji stol dobiti te podatke. Tako sam postaviti taj upit uzorak do biti podržan od sekundarne indeksa. Sada oni mogu biti razvrstani po BoardName i razvrstani prema TopScore, ovisno o. Tako možete vidjeti, to su tipovi korištenja slučajeva dobivate u igrama. Još jedan dobar način korištenja smo dobili u gaming je nagrade i tko je osvojio nagrade. A to je velika uporaba slučaj gdje zovemo rijetke indekse. Rijetke indeksi su sposobnost generirati indeks koji ne mora nužno sadrže svaki predmet na stolu. A zašto ne? Budući da je atribut koji je bio indeksirana ne postoji na svakoj točki. 

Tako je u ovaj koristite slučaj, govorim, znate što, ja ću stvoriti atribut zove nagrada. I ja ću dati svakom korisniku da ima nagradu taj atribut. Korisnici koji nemaju nagrade neće imati taj atribut. Dakle, kada sam stvoriti indeks, jedini korisnik koje će pokazati u indeksu su one koje su zapravo osvojili nagrade. Dakle, to je odličan način da bi mogli stvoriti filtrirane indekse koji su vrlo, vrlo selektivni da ne moraju indeks cijelu tablicu. 

Dakle, mi smo dobivanje nisko na vrijeme ovdje. Ja ću ići naprijed i preskočiti van i preskočiti ovaj scenarij. Razgovarajte malo about-- 

PUBLIKA: Mogu li pitati brzo pitanje? Jedan od njih je pisati teška? RICK Houlihan: Što je? PUBLIKA: Napišite teška. RICK Houlihan: Napišite teška. Daj da vidim. 

PUBLIKA: Ili da ne nešto što možete jednostavno Glas se u nekoliko sekundi? RICK Houlihan: Idemo kroz scenarij glasovanja. Nije to loše. Da li vi imate nekoliko minuta? U REDU. 

Tako ćemo razgovarati o glasovanju. Dakle, u stvarnom vremenu glasanja, imamo Zahtjevi za glasovanje. Zahtjevi su da dopustimo svaka osoba glasovati samo jednom. Želimo nitko biti u mogućnosti promijeniti svoj glas. Želimo realnom vremenu agregacije i analitiku za demografiju da ćemo biti prikazuju korisnicima na licu mjesta. 

Razmislite o ovom scenariju. Radimo puno stvarnosti TV emisije u kojoj su događaj te točnu vrstu stvari. Tako se možete sjetiti scenarija, imamo milijune i milijune od djevojaka tamo sa svojim mobitelima i glasovanje, a glasovanje i glasovanje za tko su oni nalaze se najpopularnije. Dakle, to su neke od Zahtjevi mi ponestane. 

I tako prvi potrajati u rješavanju ovog problema bi se izgraditi Vrlo jednostavna aplikacija. Tako sam dobio ovu aplikaciju. Imam neke birače vani. Oni dolaze u, su hit glasovanje app. Imam sirove glasova stol Samo ću baciti one glasove u. Ja ću imati neki agregat glasova tablicu koja će učiniti svoje analitičke i demografiju, a mi ćemo staviti sve to u tamo. 

I to je super. Život je dobar. Život je dobar dok ne saznamo da je uvijek postoji samo jedan ili dva ljudi koji su popularni na izborima. Postoji samo jedna ili dvije stvari da ljudi stvarno stalo. A ako ste glasovanje na razmjera, odjednom sam će biti zakucavanje pakao iz dva kandidata, jedan ili dva kandidata. Vrlo ograničen broj predmeta ljudi smatraju da bude popularan. 

Ovo nije dobar dizajn uzorak. To je zapravo vrlo loše dizajn uzorak jer stvara upravo ono što smo govorio o kojima je vruće tipke. Vruće tipke su nešto što se ne sviđa. 

Pa kako ćemo popraviti? I doista, na način da popraviti to uzimajući one kante kandidata a za svakog kandidata imamo, ćemo dodati slučajan vrijednost, nešto što znamo, slučajni vrijednost između jednog i 100, između 100 i 1.000, ili između jednog i 1.000, No mnogi slučajni vrijednosti želite dodati na kraju tog kandidata. 

A što sam zapravo učinio onda? Ako sam pomoću ID kandidata kao posuda za sakupljanje glasova, ako sam dodao slučajni broj do kraja da, Napravio sam sada 10 kante, A sto kante, tisuću kante da sam zbroji glasove preko. 

Dakle, ja imam milijune i milijune, i milijuni zapisa dolaze u za ove kandidate, ja sam sada širi ti glasovi diljem kandidata A_1 kroz kandidata A_100, jer svaki put glas dolazi u, Ja sam generira slučajni vrijednost između jednog i 100. Ja sam ga letanja na kraju od Kandidat je osoba s pravom glasa za. Ja sam ga damping u tu kantu. 

Sada na stražnjoj strani, znam da sam dobio sto kante. Dakle, kada želim ići naprijed te objedinjavajući glasova, Čitala sam od svih tih kante. Tako sam ići naprijed i dodati. I onda ja Scatter okupljaju gdje sam izaći i reći hej, znate što, ključ ovog kandidata prostori je više od stotinu kante. Idem skupiti sve glasova od onih sto kante. Idem agregat ih i ja ću reći, Kandidat sada ima Ukupno glasova broj x. 

Sada su i pisanje upita i upita čitanje lijepo raspoređene jer pišem po i čitam preko stotine tipki. Neću pisati i čitajući po jedan ključ sada. Dakle, to je veliki uzorak. 

To je zapravo vjerojatno jedan od najvažnijih dizajn obrasce za razmjera u NoSQL. Vidjet ćete ovaj tip Dizajn uzorak u svakom okusu. MongoDB, DynamoDB, to ne ma, svi smo to učiniti. Jer kada imate posla s tim ogromnim agregate, morate shvatiti način na širiti ih preko kante. Dakle, ovo je način na koji to učiniti. Dobro, pa što radite upravo sada je da ste trgovanje off čitanje Trošak za pisanje skalabilnost. Trošak moje čitanje je malo složeniji i ja moram ići čitati iz sto kante umjesto jednog. Ali ja sam u stanju napisati. I moj propusnost, moje pisanje propusnost je nevjerojatno. Dakle, to je obično vrijedan tehnika za skaliranje DynamoDB, ili bilo NoSQL baze podataka za tu stvar. Tako smo shvatili kako ga ljestvici. I shvatio kako eliminirati naše vruće tipke. A ovo je fantastično. I dobili smo ovu lijepu sustav. I to nam daje vrlo točan glasovanje jer imamo rekord glasova de-dupe. Ona je građena u DynamoDB. Razgovarali smo o uvjetnim pravima. 

Kad birač dolazi u, stavlja umetak na stolu, oni umetnuti sa svojim birača ID, ako oni pokušati ubaciti još jedan glas, Ja uvjetnu pisati. Recimo samo ovo napisati ako to ne postoji. Dakle, čim vidim da da glasuju hit stol, nitko drugi će biti mogućnosti staviti svoj glas u. I to je fantastično. I mi smo povećavati naši brojači kandidata. I Dajemo demografija i sve to. Ali što se događa ako je moj Zahtjev pada preko? Sada odjednom glasova dolaze, a ja ne znam da li oni uzimajući obrađuju u moje analitike i demografije više. A kada je program vrati se, kako je do vraga, znam što su glasovi obrađeno i gdje ću početi? 

Dakle, ovo je pravi problem kad vas početi gledati na ovu vrstu scenarija. A kako ćemo riješiti to? Mi to riješiti s onim što smo pozvati DynamoDB struje. Potoci se vrijeme naredio i podijeli dnevnika promjena svakog pristupa na stol, svaki pisanje pristup tablici. Svaki podatak koji je napisan na Tablica prikazuje se na potoku. 

To je u osnovi 24 sata red. Stavke pogoditi potok, oni žive za 24 sata. Oni se mogu pročitati više puta. Zajamčena biti isporučena samo jednom do potoka, može se pročitati n broj puta. Pa ipak mnogi procesi želite konzumirati te podatke, možete ga konzumirati. Ona će se pojaviti svaki ažurirati. Svako pisanje će samo pojavljuju se na potoku. Dakle, ne morate brinuti o tome obradu puta od istog postupka. 

Strogo je naredio po stavku. Kada kažemo vrijeme naredio i podijeljen, vidjet ćete po particiji na potoku. Vidjet ćete stavke, ažuriranja kako. Mi ne jamči na potok da ste će dobiti svaki posao u cilju preko stavke. 

Dakle, potoci su idempotent. Zar svi znamo što idempotent znači? Idempotent znači to možete učiniti više, i više, i iznova. Rezultat će biti isti. 

Potoci su idempotent, ali oni moraju biti igrao od starta, gdje god se odlučite, na kraju, ili oni neće rezultirati u istim vrijednostima. 

Ista stvar s MongoDB. MongoDB ima konstrukt oni nazivaju oplog. To je isti konstrukt. Mnogi NoSQL baze podataka imaju ovaj konstrukt. Oni ga koristiti za napraviti stvari kao odgovor, koji je upravo ono što mi radimo s potocima. PUBLIKA: Možda heretički pitanje, ali govoriti o aplikacijama radi pokosio tako dalje. Jeste potoci zajamčeno Nikad eventualno ići dolje? RICK Houlihan: Da, potoci zajamčeno da nikada ne ide dolje. Mi upravljati infrastrukturom iza. potoci automatski rasporediti u auto skaliranja skupine. Mi ćemo proći kroz malo malo o tome što se događa. 

Nisam trebao reći da nisu zajamčeno da nikada ne ide dolje. Elementi su zajamčena da se pojavi u potoku. A struja će biti dostupan. Dakle, ono što ide dolje ili se vraća gore, što se događa ispod. To covers-- to je u redu. U redu, tako da ćete dobiti drugačiji Vrste pogled s ekrana. Vrste pogled da su važna za programer obično su, što je to? JA dobiti stari pogled. Kada ažuriranje udari po stolu, to će gurati stari pogled na stream tako da se podaci mogu arhivirati ili promjene Kontrola, utvrđivanje promjena, promjena upravljanje. 

Nova slika, ono što je sada, nakon ažuriranje, to je druga vrsta pogleda možeš dobiti. Možete dobiti obje stare i nove slike. Možda sam ih oboje želite. Želim vidjeti što je to. Želim vidjeti što se promijenilo se. 

Imam tip sukladnosti procesa koji se izvodi. To treba potvrditi da kad ti se stvari promijeniti, da su oni u određenim granicama ili unutar određenih parametara. 

A onda možda sam samo moraju znati što se promijenilo. Ne zanima me što se promijenilo stavke. Ne trebate trebate znati što atribute promijenio. Samo trebam znati da predmeti se dotaknu. Dakle, to su vrste pregleda da dobijete off tok i možete komunicirati s. 

Zahtjev da se troši struju, To je vrsta putu to radi. DynamoDB klijenta zatražiti da gurati podataka u tablicama. Potoci rasporediti na ono što mi zovemo krhotine. Krhotine su krljuštima neovisno tablice. Oni ne postroje potpunosti na particiju tablici. A razlog zašto je jer su se postroje kapacitetu, struja Kapacitet tablice. 

Oni implementirati u svojim vlastiti auto skaliranje skupina, i počnu vrtjeti se, ovisno o tome koliko piše dolaze, koliko reads-- stvarno to piše. Nema reads-- ali kako mnogi piše dolaze. 

A onda na leđima kraj, imamo ono što smo nazovite KCl, ili kinezi klijent knjižnica. KiNESiS je tok podataka Obrada tehnologija iz Amazon. I potoka je izgrađen na to. 

Tako da koristite KCL omogućeno Zahtjev za čitanje potok. KiNESiS Klijent Knjižnica zapravo upravlja radnike za vas. I to također radi neke zanimljivosti. To će stvoriti neke tablice se u svom DynamoDB tablespace pratiti stavke koje su obrađeni. Dakle, na taj način ako padne natrag, ako pada preko i dolazi i dobiva stajao natrag gore, to može odrediti gdje Bio je u obradi tok. 

To je vrlo važno kada pričaš replikacije. Moram znati što Podaci su obrađeni i koji su podaci još treba obraditi. Dakle KCL knjižnica za potoci će dati vam puno toga funkcionalnosti. Ona vodi brigu o svim domaćinstva. Ona ustaje radniku za svaki krhotina. To stvara upravni stol za svaki krhotina, za svakog radnika. I dok oni radnici požara, oni održavaju te tablice tako da znate ovaj zapis je pročitati i obraditi. A onda na taj način, ako se proces umire i dolazi natrag online, može nastaviti tamo gdje je skinula. 

Dakle, mi koristimo ovo za cross-regija odgovor. Puno kupci imaju potrebu za premjestiti podatke ili dijelove njihovih tablica podataka oko različitih područja. Postoji devet područja diljem svijeta. Dakle, tu bi moglo biti need-- sam možda korisnike u Aziji, korisnici u istočnoj obali Sjedinjenih Država. Oni imaju različite podatke koji treba lokalno distribuira. A možda je korisnik leti iz Azija preko SAD, i želim ponoviti njegovi podaci s njim. Dakle, kada on dobiva iz aviona, on je dobro iskustvo koristeći svoj mobilni app. 

Možete koristiti poprečni regiju repliciranje knjižnica za to. Uglavnom smo uvjetom dvije tehnologije. Jedan je konzola aplikacija možete ustati na vlastite EC2 primjer. Ona radi čistog replikaciju. A onda smo vam dali knjižnicu. Knjižnica možete koristiti za izgradnju Vaš vlastiti zahtjev, ako vas želite raditi lude stvari s tim data-- filter, ponoviti samo dio njega, rotirati podatke, premjestiti ga u različite stol, tako dalje i tako dalje. Dakle, to je vrsta kako to izgleda. 

DynamoDB žanrovi mogu biti obrađuje ono što mi zovemo lambda. Spomenuli smo malo o događaju driven program arhitekture. Lambda je ključna komponenta toga. Lambda je kod koji ispaljuje na zahtjev kao odgovor na određeni događaj. Jedan od tih događaja može biti Evidencija se pojavljuju na potoku. Ako se zapisnik o struji, ćemo nazvati ovu Java funkciju. Pa, ovo je JavaScript i Lambda podržava Node.js, Java, Python, a uskoro će podržati drugim jezicima. I dovoljno je reći, to je čista broj. pisati u Javi, što definirati klasu. Možete gurnuti JAR gore u Lambda. I onda odrediti koji razred pozvati odgovor na koji događaj. A onda Lambda infrastruktura iza koje će pokrenuti taj kod. 

To može obraditi kod zapisi off potoka. To može učiniti ništa što želi s njom. U ovom konkretnom primjeru, svi smo zapravo radi se prijavite atribute. No, to je samo broj. Kodeks se može učiniti ništa, zar ne? 

Tako možete okretati te podatke. Možete stvarati izvedena pogled. Ako je struktura dokumenta, možete poravnati strukturu. Možete stvoriti alternativni indeksi. Sve vrste stvari koje možete učiniti s DynamoDB potoci. 

I doista, to je ono što to izgleda. Tako ćete dobiti one ažuriranja dolazi. Dolaze s tetivu. Oni čitaju funkciji Lambda. Oni rotirajući podatke i pritom se u izvedenih tablicama, obavijestila vanjske sustave promjene, i pritom podatke u ElastiCache. 

Razgovarali smo o tome kako staviti cache ispred baze podataka za tu prodaju scenarij. Pa što će se dogoditi ako ažurirati opis stavke? Pa, ako sam imao Lambda Funkcija radi na tom stolu, ako sam ažurirati opis stavke, to će pokupiti rekord s potoka, i to će ažurirati ElastiCache primjer s novim podacima. Dakle, to je puno Što ćemo učiniti s Lambda. To je ljepilo broj, konektori. I to zapravo daje sposobnost za pokretanje i izvoditi vrlo složene aplikacije bez posvećena poslužitelj infrastrukture, što je stvarno cool. 

Dakle, vratimo se na naše stvarnom vremenu glasovanja arhitekture. Ovo je nova i poboljšana s našim potoci i KCL omogućen prijavu. Isto kao i prije, možemo nositi bilo mjerilo izbora. Mi smo željeli to. Radimo se raspršiti okuplja na više kante. Imamo optimistični zaključavanje događa. Možemo zadržati naše birače mijenjanje njihovih glasova. Oni samo mogu glasovati samo jednom. Ovo je fantastično. Real-time tolerancija kvarova, skalabilan agregacije sada. Ako je stvar pada preko, to zna gdje bi se ponovno pokrenuti kada je u pitanju natrag gore, jer mi smo pomoću KCl aplikaciju. A onda možemo koristiti da KCL aplikacija gurnuti podatke iz da crveni pomak za ostale App analitike, ili koristiti elastične MapReduce pokrenuti real-time streaming agregacije popusta te podatke. 

Dakle, to su stvari koje mi nisu razgovarali o puno. Ali oni su dodatno tehnologije koje dolaze nositi kada ste u potrazi na ove vrste scenarija. 

U redu, tako da je o analitika s DynamoDB potoka. Možete prikupiti de-dupe Podaci, učiniti sve vrste lijepih stvari, podatke prikuplja na memorije, stvoriti one izvedene tablice. To je ogroman uporabu slučaj da je puno kupaca su uključeni u, uzimajući uklopljenih svojstva tih JSON dokumenata i stvaranje dodatne indeksa. 

Mi smo na kraju. Hvala vam što ste nosi sa sobom. Dakle, pričajmo o referentne arhitekture. DynamoDB sjedi u sredini, tako mnogo AWS infrastrukture. Uglavnom možete spojiti do svega što želite. Prijave izgrađen korištenjem Dinamo uključuju Lambda, ElastiCache, CloudSearch, gurnuti podatke van u Elastična MapReduce, uvoz izvoz iz DynamoDB u S3, sve vrste rada. No, vjerojatno najbolji stvar govoriti o, i to je ono što je stvarno Zanimljivo je kad smo govoriti o događajima pogon aplikacija. 

Ovo je primjer interni projekt da imamo gdje smo zapravo objavljivanje okupiti rezultate ankete. Tako je u e-mail vezu koja mi poslati, bit biti malo veze govoreći klik ovdje odgovoriti na anketu. A kada osoba klikne koje vode, što se događa je da Srušit siguran HTML ankete oblik iz S3. Nema poslužitelja. Ovo je samo S3 objekt. 

To oblik dolazi, učitava se u pregledniku. To je dobio okosnicu. To je dobio kompleks JavaScript koji je pokrenut. Dakle, to je vrlo bogata aplikacija trčanje u klijenta pregledniku. Oni ne znaju da oni nisu interakciji s leđa kraj poslužitelju. U ovom trenutku, to je sve preglednik. 

Oni objaviti rezultate na ono što zovemo Amazon API Gateway. API Gateway je jednostavno web API koje možete definirati i spojiti kako god želite. U ovom konkretnom slučaju, mi smo zakačen na funkciju Lambda. 

Dakle, moj post je operacija događa bez poslužitelja. Uglavnom da API Gateway sjedi tamo. To mi ništa ne košta do ljudi počnite objavljivati ​​na to, zar ne? Lambda funkcija samo sjedi tamo. I to me košta ništa do ljudi početi ga udarajući. Tako možete vidjeti, kao volumen povećava, to je kad su optužbe dolaze. Neću trčanje poslužitelj 7/24. 

Tako sam povući obrazac dolje iz kante, i ja objaviti kroz API Gateway u funkciji Lambda. A onda Lambda Funkcija kaže, znaš ono, imam neke PIIs, neki osobne podatke u tim reakcijama. Imam komentare koji dolaze od korisnika. Imam e-mail adrese. Imam korisnička imena. 

Dopustite mi podijeliti ovo off. Idem generirati neke metapodataka s ove evidencije. I ja ću gurnuti metapodataka u DynamoDB. I ja sam mogao kriptirati sve podatke i gurnuti u DynamoDB ako želim. No, to je lakše za mene, u ovom koristite slučaj, da ide naprijed je riječ, Idem gurnuti sirove podatke u šifriranom S3 kantu. Tako sam koristiti ugrađene u S3 strani poslužitelja šifriranje i Amazon upravljanje ključevima Usluga tako da imam ključ koji može okretati na redovitim intervalima, i ja mogu zaštititi tu PII podataka kao dio cijelog tog rada. 

Pa što sam učinio? Upravo sam angažiran u cjelini program, a ja nemam poslužitelj. Tako je ono što događaj pokreće aplikaciju arhitektura radi za vas. 

Sada, ako mislite o tome korištenje slučaj this-- imamo druge kupce Govorim da o tom točnom arhitekture koji pokrenuti fenomenalno velike kampanje, koji je gleda na to i ide, oh moj. Jer sada, oni mogu zapravo ga gurati vani, pustiti da kampanju samo sjediti postoji dok se ne pokreće, a ne brinuti se o sl kakvu infrastrukturu će biti tu da ga podržavaju. A onda, čim da kampanja je učinio, to je kao infrastrukture Samo se odmah ide dalje jer tamo stvarno nema infrastrukture. To je samo broj koji sjedi na Lambda. To je samo podaci koji sjedi u DynamoDB. To je izvrstan način graditi aplikacije. 

PUBLIKA: Tako je to više prolazna nego što bi ako je pohranjena na stvarni poslužitelj? 

RICK Houlihan: Apsolutno. Zbog toga instanci poslužitelja bi trebala biti 7/24. To mora biti dostupan za netko odgovoriti. Pa pogodite što? S3 je dostupna 7/24. S3 uvijek odgovara. I S3 je vrlo, vrlo dobar na služeći se predmete. Ti objekti mogu biti HTML datoteke, ili JavaScript datoteke, ili što god želite. Možete pokrenuti vrlo bogate web aplikacije iz S3 kante, i ljudi. 

I da je ideja ovdje je da biste dobili daleko od načina smo se razmišljati o tome. Svi smo se mislim u Uvjeti poslužitelja i domaćina. Ne radi se o tome više. Radi se o infrastrukturi kao kod. Postavite šifru na oblaku i neka oblak trčanje za vas. I to je ono što AWS pokušava učiniti. 

PUBLIKA: Pa vaš zlatni okvir u sredini API Gateway nije poslužitelja kao što su, ali umjesto toga je just-- 

RICK Houlihan: Možete misliti to kao poslužitelj fasade. Sve to je to će potrajati HTTP zatražiti i mapirati ga na drugi proces. To je sve što radi. I u ovom slučaju, mi smo mapiranje je u funkciji Lambda. U redu, tako da je sve što imam. Hvala vam puno. Cijenim to. Znam želimo malo tijekom vremena. I nadamo se da dečki dobio malo informacija koje možete uzeti i danas. A ja se ispričavam ako sam otišao preko neke od svojih šefova, ali postoji dobra puno temeljna znanja temeljni mislim da je vrlo vrijedan za tebe. Dakle, hvala ti za mene ima. [PLJESAK] PUBLIKA: [nečujan] je kad si govorio ste morali proći kroz stvari od početka do kraja kako bi dobili pravo vrijednosti ili iste vrijednosti, Kako bi se vrijednosti promijeniti ako [nečujan]. 

RICK Houlihan: Oh, idempotent? Kako bi se vrijednosti mijenjati? Pa, jer ako nisam pokrenuti to sve do kraja, onda ja ne znam što se mijenja su u posljednje milje. To neće biti iste podatke kao što sam vidio. PUBLIKA: Oh, tako da samo nisu stečen cijeli ulaz. RICK Houlihan: Tako je. Morate ići od početka do kraja, a onda je će biti dosljedan stanje. Cool. 

PUBLIKA: Znači li nam pokazali DynamoDB Možete napraviti dokument ili ključnu vrijednost. I proveli smo puno vremena na Ključ vrijednost s hash i načina to lak udarac okolo. Kada je pogledao onim stolovima, da ostavljajući iza pristupu dokumentima? 

RICK Houlihan: Ja ne bih kažu ostavljajući iza sebe. 

PUBLIKA: Oni su odvojeni od the-- 

RICK Houlihan: S dokumenta pristup, tip dokumenta u DynamoDB je samo misliti što je još jedan atribut. To je osobina koja sadrži hijerarhijski struktura podataka. A onda u upite, možete koristiti svojstva tih objekata pomoću Object zapis. Dakle, ja mogu filtrirati na ugniježđenu vlasništvo JSON dokumenta. PUBLIKA: Pa bilo koje vrijeme sam učiniti pristup dokumentima, Mogu vrsta doći na tabular-- PUBLIKA: Apsolutno. Publika: --indexes i stvari koje samo govorio o tome. RICK Houlihan: Da, indekse i sve to, kada želite indeksa svojstva JSON, način na koji ćemo morati učiniti da je, ako umetnete JSON objekt ili dokument u Dinamo, te će koristiti potoci. Potoci bi pročitali ulaz. Vi bi dobili da je JSON objekt i da bih u redu, što je vlasništvo želim indeksu? 

Možete stvarati izvedena stol. Dakle, to je način na koji se to radi upravo sada. Mi ne dopuštaju da se indeks izravno ta svojstva. 

PUBLIKA: Tabularizing svoje dokumente. 

RICK Houlihan: Točno, ravnanje da, tabularizing to točno. To je ono što učiniti s njom. 

PUBLIKA: Hvala vam. 

RICK Houlihan: Aha, Apsolutno, hvala. PUBLIKA: Dakle, to je vrsta Mongo ispunjava Redis classifers. 

RICK Houlihan: Da, to je puno kao što je to. To je dobar opis za to. Cool.