[Přehrávání hudby] RICK Houlihan: Dobře. Ahoj všichni. Jmenuji se Rick Houlihan. Jsem senior ředitel Řešení architekt společnosti AWS. Zaměřuji se na NoSQL a Technologie DynamoDB. Jsem tu dnes mluvit jste trochu o nich. 

Moje pozadí je především v datové vrstvy. Strávil jsem půlku rozvoj kariéra psaní databázi, přístup k datům, řešení pro různé aplikace. Byl jsem v oblasti virtualizace Cloud asi 20 let. Takže před tím, než Cloud Cloud, jsme byli zvyklí říkat utility computing. A nápad byl, je to jako PG & E, budete platit za to, co používáte. Dnes ji nazýváme mrak. 

Ale v průběhu let jsem pracoval pro pár firem jste pravděpodobně nikdy neslyšeli. Ale já jsem sestavil seznam technických úspěchy, myslím, že bych. Mám osm patentů v Cloud systémy virtualizace, mikroprocesor design, komplexní zpracování událostí, a jiných oblastech. 

Takže v těchto dnech, jsem se zaměřují především na NoSQL technologie a příští generace databáze. A to je to obecně, co budu tu být s tebou mluvit dnes o. Takže to, co můžete očekávat z tohoto zasedání, půjdeme přes krátké Historie zpracování dat. Je vždy užitečné pochopit, odkud jsme přišli a důvod, proč jsme tam, kde jsme. A budeme mluvit trochu bit o technologii NoSQL od základní hlediska. 

Dostaneme se do některé z vnitřní vybavení DynamoDB. DynamoDB je AWS to není chuť. Je plně organizovaná a Hostované řešení NoSQL. A budeme mluvit trochu o stůl struktura, API, datové typy, indexy, a některé z niternosti tohoto DynamoDB technologie. Dostaneme se do některé z designu vzory a osvědčených postupů. Budeme mluvit o tom, jak použití této technologie pro některé dnešních aplikací. A pak budeme mluvit trochu o vývoji či vzniku nového paradigmatu programování tzv aplikace událostmi řízené a jak DynamoDB hraje v, že stejně. A my vám necháme trochu referenční architektury diskuse takže můžeme hovořit o některých způsoby, jak můžete použít DynamoDB. 

Takže nejprve off-- je to otázka Slyšel jsem, že hodně, je to, co je databáze. Mnoho lidí si myslí, že víte, co je databáze. Pokud jste Google, uvidíte to. Je to strukturovaný soubor údajů konalo v počítači, zejména ten, který je k dispozici ve různými způsoby. Myslím, že je to dobrý Definice moderní databáze. Ale nelíbí se mi to, protože to znamená několik věcí. To znamená strukturu. A to znamená, že je to v počítači. A databáze ne vždy existovat na počítačích. Databáze vlastně existoval v mnoha ohledech. 

Takže lepší definice Databáze je něco takového. Databáze je organizovaná mechanismus pro ukládání, správu, a získávání informací. To je od About.com. Tak jsem to rád, protože je to opravdu mluví o databázi, že je úložiště, studnicí informace, ne nutně něco, co sedí na počítači. A celé historii, my ne vždy měli počítačů. 

A teď, když jsem se zeptat průměr developer dnes to, co je databázi, že je odpověď jsem si. Někde jsem si držet věci. Právo? A je to pravda. Ale je to nešťastné. Vzhledem k tomu, databáze je opravdu základem moderní aplikace. To je základ z každé aplikace. A jak si vybudovat, že databáze, jak strukturovat že data se bude diktovat, jak, že Aplikace vystupuje jako měřítka. 

Takže mnoho mé práce dnes se zabývá, co se stane, když vývojáři tento přístup a řešit následky aplikace, která Nyní je škálování nad rámec původní záměr a utrpení ze špatného návrhu. Takže doufejme, že když vás odejít dnes, budete mají několik nástrojů v tvůj pás, který tě držet od dělat ty stejné chyby. Dobře. Tak pojďme mluvit o trochou časová osa databázových technologií. Myslím, že jsem četl článek Není to tak dávno a řekl něco na lines-- je to velmi poetické prohlášení. To řekl, že historie dat zpracování je plná vysokých vodoznaků hojnosti dat. DOBŘE. A teď, myslím, že je docela pravda. Ale já jsem vlastně podívat, je, jak historie byla skutečně naplněna s vysokým vodoznakem tlaku dat. Vzhledem k tomu, rychlost přenosu dat z Požití nikdy klesá. Je to jen jde nahoru. 

A inovace nastane, když vidíme tlak dat, což je množství dat, které je nyní v přichází do systému. A to nelze zpracovat účinně buď v čase, nebo z hlediska nákladů. A to je, když začneme se podívat na tlaku dat. 

Takže když jsme se podívat na první databází, toto je ten, který byl mezi naše uši. Jsme všichni s tím narodil. Je to pěkná databáze. To má vysokou dostupnost. Je to vždy. Vždy se můžete dostat. 

Ale je to pro jednoho uživatele. Nelze sdílet své myšlenky s vámi. Nemůžete dostat své myšlenky když je chcete mít. A jejich abilitiy není tak dobrá. Zapomínáme věci. Tu a tam, jeden z nás listy a přesune na jiný existenci a ztratíme všechno která byla v této databázi. Takže to není tak dobré. 

A to fungovalo dobře v průběhu času když jsme byli zpět v den když všechno, co jsme opravdu potřebovali vědět, je, kde budeme pokračovat zítra nebo tam, kde jsme se shromáždit nejlepší jídlo. Ale když jsme začali pěstovat jako civilizace a vláda začala vstoupit do bytí, a podniky začaly vyvíjet, jsme začali si uvědomíme, Potřebujeme trochu víc, než to, co jsme mohli dát do naší hlavě. Dobře? 

Potřebovali jsme systémy záznamu. Potřebovali jsme místa, aby ukládání dat schopné. Tak jsme začali psát dokumenty, vytváření knihoven a archivů. Začali jsme vyvíjet Systém Ledger účetnictví. A že systém počítání saldokontní běžel svět pro mnoho století, A možná i tisíciletí as jsme trochu rostla k věci pokud tento náklad údaje předčil schopnost těchto systémů aby bylo možné jej obsahovat. 

A to se skutečně stalo v 1880s. Právo? V 1880 amerického sčítání lidu. To je opravdu, kde soustružení bod moderní zpracování dat. To je bod, ve což je množství dat který byl shromážděné Vláda USA se dostal do bodu, kde to trvalo osm let zpracovat. 

Teď, osm years-- as víte, sčítání lidu jezdí každých 10 years--, takže je to docela zřejmé, že když jsme dostal 1890 sčítání lidu, Množství dat, které šel být zpracovány vládou byl bude překračují 10 let to tak by se do zahájila nové sčítání lidu. To byl problém. 

Takže chlápek jménem Herman Hollerith přišel a on vynalezl přístroj nahraje punč karty, punč čtečka karet, děrný štítek tabulátor, a kolace mechanismy pro tuto technologii. A že společnost, která se tvořil u čas, spolu s několika ostatními, ve skutečnosti se stal jedním z pilíři malá firma známe dnes vyzvala IBM. 

Takže IBM původně byl v obchodní databáze. A to je opravdu to, co udělali. Udělali zpracování dat. 

Jak tak šíření punč karty, geniální mechanismy že budou moci využít, že Technologie na hlasování setříděné sady výsledků. Můžete vidět v tomto snímku K dispozici máme little-- je to trochu small-- ale můžete vidět velmi důmyslný mechanický mechanismus kde máme punč balíček karet. A brát něčí trochu šroubovák a lepení prostřednictvím sloty a zvednutím nahoru se dostat, že zápas, který seřazené výsledky set. 

Toto je agregace. Děláme to po celou dobu dnes v počítači, kde to děláte v databázi. Použili jsme to udělat ručně, je to tak? Lidé dát tyto věci dohromady. A bylo to šíření těchto děrných štítků do toho, co jsme nazvali datových bubnů a datové kotouče, papírové pásky. 

Zpracování dat průmysl vzal poučení z klavírů hráče. Piana zpátky na přelomu století používali papírové kotouče s drážkami na to říct, které klíče hrát. Tak, že technologie byla upravena nakonec pro ukládání digitálních dat, protože oni mohli dát, že data na těchto papírovou pásku rolích. 

Nyní, jako výsledek, údaje byl actually-- jak máte přístup tato data byla přímo v závislosti na tom, jak jste je uložili. Takže když jsem dal data na pásku, Měl jsem lineárně přístup k datům. Musel jsem se vrátit celou Páska přístup ke všem datům. Mám-li vložit data do punč karty, mohl jsem to přístup v trochu více náhodný móda, možná ne tak rychle. 

Ale tam bylo omezení v tom, jak přístup k datům na základě toho, jak byl uložen. A tak to byl problém, jít do 50. let. Opět platí, že můžeme začít vidět, že jako my vyvíjet nové technologie pro zpracování data, vpravo, otevírá dveře pro nová řešení, pro nové programy, nové Žádosti o těchto dat. A opravdu, správa věcí veřejných mohl být důvodem Proto jsme vyvinuli některé z těchto systémů. Ale firma se rychle stal se Řidič za evoluci moderní databáze a moderní systém souborů. 

Takže další věc, která se přišel byl v 50. letech byl systém souborů a Vývoj náhodného skladování přístupu. To byla krásná. Nyní jsou všechny náhlé, můžeme dát naše soubory kdekoli na těchto pevných discích a můžeme přístup k těmto datům náhodně. Můžeme analyzovat, že Informace ze souborů. A jsme vyřešili všech světových problémy s zpracování dat. 

A to trvalo asi 20 nebo 30 let až do evoluce relační databáze, která je, když se svět rozhodli jsme se teď musí mít úložiště, které překazí rozléhat dat napříč souboru systémy, které jsme vytvořili. Právo? Příliš mnoho dat distribuovaných v příliš mnoho místa, de-duplikace dat, a náklady na skladování byl obrovský. 

V 70. letech, nejdražší zdroj že počítač měl byl skladování. Procesor byl vnímána jako fixní náklady. Když jsem se koupit box, CPU dělá nějakou práci. Bude to být předení, zda je to vlastně pracuje, nebo ne. To je opravdu fixních nákladů. 

Ale to, co mě stálo jako podnikání je skladování. Mám-li koupit více disků další měsíc, to je skutečné náklady, které jsem zaplatit. A že skladování je drahé. 

Nyní jsme rychle dopředu 40 roků a máme jiný problém. Compute je nyní nejdražší zdroj. Úložiště je levné. Myslím, že jsme může jít kamkoliv na cloud a můžeme najít levné skladování. Ale to, co nemohu najít je levná výpočetní. 

Takže evoluce dnešní Technologie, databázové technologie, je opravdu zaměřeny na distribuované databáze že netrpí stejný typ stupnice omezení relačních databází. Budeme mluvit trochu o co to vlastně znamená. 

Ale jeden z důvodů, proč a Řidič za tohle-- my mluvil o tlaku dat. Tlak dat je něco, že podporuje inovaci. A když se podíváte na více než posledních pět let, toto je tabulka k čemu se údaje zatížení v rámci obecného podniku vypadá v posledních pěti letech. 

A obecné pravidlo Tyto days-- pokud jdete Google-- 90% z údajů, které ukládáme dnes, a to bylo vytvořených v posledních dvou letech. DOBŘE. Nyní, se nejedná o trend, který je nový. To je trend, který byl chodit na 100 let. Od té doby, Herman Hollerith vyvinul děrný štítek, jsme byli budování datových úložišť a shromažďování údajů na fenomenální sazby. 

Takže v průběhu posledních 100 let, jsme viděli tento trend. To nebude měnit. Do budoucna budeme vidět to, ne-li zrychlené trend. A můžete vidět, jak to vypadá. 

Pokud se firma v roce 2010 měl jeden terabyte dat v rámci řízení, Dnes to znamená, že jsou správu 6,5 petabajtů dat. To je 6500 krát více dat. A vím, že tohle. Každý den jsem se pracovat s těmito podniky. Před pěti lety jsem by se mluvit na společnosti kdo by se mnou mluvit o tom, co bolesti to je řídit terabajtů dat. A oni by se mluvit se mnou o tom, jak vidíme že je to pravděpodobně bude být petabyte nebo dva během několika let. 

Tyto stejné společnosti Dnes mám schůzku s, a oni se mnou mluvit o Problémem jsou zde mají řídící desítky, 20 petabajtů dat. Takže Exploze Data v průmyslu pohání obrovský Potřebujete pro lepší řešení. A relační databáze je prostě žít až do poptávky. 

A tak je tu lineární korelace mezi tlakem dat a technické inovace. Historie nám ukázala, to, že v průběhu doby, vždy, když se objem dat které musí být zpracovány přesahuje kapacitu systému zpracovat ji v rozumném čase nebo za rozumnou cenu, pak nové technologie jsou vynalezeny na řešení těchto problémů. Tyto nové technologie, naopak, otevřete dvířka na jinou sadu problémů, které sbírá i další data. 

Nyní, nebudeme to zastavit. Právo? Nebudeme to zastavit. Proč? Vzhledem k tomu, nemůžete vědět všechno tam je znát ve vesmíru. A tak dlouho, jak jsme byli naživu, v celé historii člověka, jsme vždy řízený vědět víc. 

Takže to vypadá, že každý palec se pohybujeme po cestě vědeckého objevu, jsme se množí množství dat že musíme zpracovat exponenciálně jak odhalit víc a víc a víc o vnitřním fungování života, o tom, jak vesmír funguje, o řídil vědecký objev, a vynález, který děláme dnes. Objem dat jen neustále zvyšuje. Takže je schopen vypořádat se s Tento problém je obrovský. 

Takže jedna z věcí se podíváme, jak, proč NoSQL? Jak NoSQL tento problém vyřešit? No, relační databáze, Structured Query Language, SQL--, že je opravdu konstrukt relační database-- tyto věci jsou optimalizovaný pro skladování. 

Zpátky v 70. letech, se znovu, disk je drahé. Dotační Výkon skladování V podniku je nikdy nekončící. Já vím. Žil jsem to. Napsal jsem ovladače úložiště pro enterprised SuperServer firmy zpátky v 90. letech. A faktem je stáčení další diskové pole bylo jen něco, každý den v podniku stalo. A to nikdy nepřestalo. Vyšší hustota skladování, poptávka pro vysokou hustotou skladování, a pro efektivnější ukládání devices-- to nikdy nepřestalo. 

A NoSQL je špičkovou technologií proto, že normalizuje data. Je to de-kopíruje data. Klade data ve struktuře, která je agnostik na každý vzorek přístup. Více aplikací, které může zasáhnout SQL databáze, spouštět dotazy ad hoc, a získat data ve tvaru, který se je třeba zpracovat pro své pracovní zátěže. To zní fantasticky. Ale faktem je, s jakýmkoliv systém, pokud je to agnostik ke všemu, je optimalizován pro nic za nic. DOBŘE? 

A to je to, co jsme si s relační databáze. Je optimalizovaný pro skladování. To je normalizovaná. Je to relační. Podporuje dotazy ad hoc. A to je a to váhy svisle. 

Pokud je potřeba získat větší SQL databázi nebo silnější SQL databáze, Jdu si koupit větší kus železa. DOBŘE? Pracoval jsem s mnoha zákazníků které byly prostřednictvím významné modernizace pouze v jejich SQL infrastruktury zjistit, o šest měsíců později, oni bít do zdi znovu. A odpověď z Oracle nebo MSSQL nebo někdo jiný, je dostat větší krabici. Tak dříve nebo později, nemůžete koupit větší box, a to je skutečný problém. Musíme skutečně něco změnit. Takže tam, kde to funguje? Funguje to dobře pro offline analytika, OLAP typu zatížení. A to je opravdu, kde SQL patří. Nyní, to je dnes používán v mnoha online transakční zpracování typu aplikace. A funguje to v pohodě na určitá úroveň využití, ale to prostě není měřítko tak, že NoSQL dělá. A budeme mluvit trochu bit o tom, proč to je. 

Nyní, NoSQL, na druhé straně, je více optimalizován pro výpočetně. DOBŘE? Není k agnostik přístup vzor. Je to, co nazýváme de-normalizoval struktura nebo hierarchická struktura. Data v relační databázi spojeny dohromady z více tabulek produkovat názor, že potřebujete. Data v databázi NoSQL je uložen v dokumentu, který obsahuje hierarchickou strukturu. Veškerá data, která by normálně spojily produkovat tento názor je uložen v jediném dokumentu. A budeme mluvit trochu o jak to funguje v několika grafů. 

Ale myšlenka je, že budete ukládat Vaše data jsou tyto konkretizovaná výhledem. DOBŘE? Ty vodorovně škálovat. Právo? Pokud je potřeba zvýšit velikost mého clusteru NoSQL, Nepotřebuji, aby si větší krabici. Mám další krabici. A já clusteru ty dohromady, a já si střep, že data. Promluvíme si něco o co sharding je, že schopny škálovat této databáze přes více fyzických zařízení a odstranit bariéru, která vyžaduje, abych měřítku svisle. 

Takže je to opravdu postavené pro on-line zpracování transakcí a měřítko. Je tu velký rozdíl tady mezi hlášení, že jo? Reporting, já neznáte Otázky Jdu se zeptat. Právo? Reporting-- pokud někdo z můj marketingové oddělení chce jen--, kolik z mých zákazníků mít tuto zvláštní vlastnost, která koupil na této day-- nevím co dotaz jdou zeptat. Tak jsem třeba být agnostik. 

Nyní, v on-line transakční aplikace, Vím, jaké otázky se ptám. Postavil jsem žádost o velmi specifický workflow. DOBŘE? Takže když jsem optimalizovat údaje ukládat na podporu tohoto pracovního postupu, že to bude rychlejší. A to je důvod, proč může NoSQL Opravdu urychlit dodávku z těchto typů služeb. Dobře. 

Takže jsme se dostat do trochu teorie zde. A někteří z vás, vaše oči může vrátit zpět trochu. Ale budu se snažit, aby to jak vysoké úrovni jako já. Takže pokud jste v projektu management, je tu konstrukt nazvaný trojúhelník omezení. DOBŘE. Trojúhelník omezuje diktátu nemůžete mít všechno čas. Nemůžete mít svůj koláč a jíst to příliš. Takže v oblasti projektového řízení, že trojúhelník omezení je můžete mít levné, můžete mít to rychle, nebo můžete mít to dobré. Vyberte si dva. Vzhledem k tomu, nemůžete mít všechny tři. Právo? DOBŘE. 

Takže jste slyšel o tom hodně. Je to trojitý omezení, trojúhelník trojité omezení, nebo železo trojúhelník je oftentimes-- Když mluvíte s projektovým manažerům, oni Promluvíme si o tom. Nyní, databáze mají jejich vlastní železo trojúhelník. A železo trojúhelník údajů je to, co nazýváme věta CAP. DOBŘE? 

CAP teorém diktuje jak fungují databáze za velmi specifických podmínek. A budeme mluvit o tom, co je tato podmínka. Ale tři body trojúhelníku, tak říkajíc, jsou C, konzistence. DOBŘE? Takže v CAP, konzistence znamená, že všechny Klienti, kteří mají přístup k databázi bude mít vždy velmi konzistentní pohled na data. Nikdo se bude vidět dvě různé věci. DOBŘE? Když vidím databázi, Vidím stejný pohled jako můj partner, který vidí stejné databáze. To je konzistence. 

Dostupnost znamená, že v případě, že databáze on-line, v případě, že může být dosaženo, že všichni klienti budou vždy být schopen číst a psát. DOBŘE? Takže každý klient, který můžete přečíst databáze budou vždy schopni čtení Údaje údaje a psát. A pokud je tomu tak, je to k dispozici systém. 

A třetí bod je to, co nazýváme tolerance oddílu. DOBŘE? Tolerance Partition prostředky že systém funguje dobře i přes fyzické sítě příčky mezi uzly. DOBŘE? Takže uzly v clusteru nemůže mluvit k sobě navzájem, co se stane? Dobře. 

Takže relační databáze vyberte-- si můžete vybrat dva z nich. DOBŘE. Takže relační databáze vyberte být konzistentní a jsou k dispozici. Pokud oddíl se děje mezi že DataNodes v úložišti dat, databáze havaruje. Právo? Je to jen jde dolů. DOBŘE. 

A to je důvod, proč mají růst s většími boxy. Právo? Protože tam je no-- obvykle, cluster Databáze, že to není moc mnoho z nich že fungují tímto způsobem. Ale většina databází měřítko ve svislém směru v rámci jediného pole. Vzhledem k tomu, že musí být konzistentní a jsou k dispozici. Pokud oddíl měl být aplikován, pak budete muset učinit volbu. Musíte si vybrat mezi je v souladu a jsou k dispozici. 

A to je to, co databáze NoSQL dělat. Dobře. Takže databáze NoSQL to, přichází ve dvou příchutích. My have-- dobře, to přichází v mnoha příchutích, ale přichází se dvěma základními characteristics-- co bychom nazvali CP databáze, nebo konzistentní a oddíl tolerance systém. Tihle chlapi zda se rozhodne, že když uzly ztrátě kontaktu spolu navzájem, nebudeme dovolit lidé psát víc. DOBŘE? 

Do té doby bude oddíl odstraněn, Přístup pro zápis je blokován. To znamená, že to není k dispozici. Jsou konzistentní. Když vidíme, že partition injekci sám, jsme nyní konzistentní, protože my nejdeme aby změnu dat na dva strany přepážky samostatně na sobě. Budeme se muset obnovit komunikaci před jakýmkoli aktualizaci data je povoleno. DOBŘE? 

Další varianta by byl systém AP, nebo k dispozici a rozdělí tolerance systém. Tihle kluci to jedno. Právo? Jakýkoliv uzel, který dostane psát, budeme si to. Takže jsem svou replikaci dat přes více uzlů. Tyto uzly se klient, klient přijde V říká, budu zapisovat některé údaje. Node říká, žádný problém. Uzel Vedle něj dostane Zápis na stejném záznamu, že to bude říkat žádný problém. Někde zpátky na konci zadní, že data to bude replikovat. A pak někdo to bude realizovat, uh-oh, ale systém bude realizovat, uh-oh, Stala se aktualizace dvou stran. Co děláme? A to, co dělají, je pak dělají něco, co jim umožňuje řešit tento stav dat. A budeme mluvit o tom, že v následujícím grafu. 

Thing poukázat zde. A já nebudu mít moc mnohem do toho, protože to dostane do hluboké teorie dat. Ale je tu transakční rámec, který probíhá v relační systému, který mi umožňuje bezpečně provádět aktualizace na více subjektů v databázi. A tyto aktualizace budou vyskytovat najednou, nebo vůbec ne. A to se nazývá ACID transakce. DOBŘE? 

ACID nám dává atomicity, konzistence, izolace, a trvanlivost. DOBŘE? To znamená, že atomové, transakce, vše moje aktualizace buď stát, nebo ne. Konzistence znamená, že Databáze bude vždy být uvedena do konzistentní stav po aktualizaci. Já se nikdy opustit databáze v po použití aktualizace špatný stav. DOBŘE? 

Takže je to trochu jinak než konzistence CAP. Konzistence CAP znamená, že všechny moje klienti mohou vždy zobrazit data. ACID konzistence znamená, že když transakce se stalo, údaje je dobré. Mé vztahy jsou dobré. Nebudu odstranit nadřazený řádek a zanechat spoustu osiřelých dětí v jiné tabulce. To se nemůže stát, jestli jsem v souladu v kyselém transakce. 

Izolace znamená, že transakce dojde vždy po sobě. Konečný výsledek dat bude stejný stav jako kdyby tyto transakce které byly vydány souběžně byli popraveni sériově. Takže je to souběžnost kontrola v databázi. Takže v podstatě, nemohu zvýšit Stejná hodnota dvakrát se dvěma operacemi. 

Ale když řeknu přidat 1 k této hodnotě, a dvě transakce přijít a pokusit se udělat to, něčí tam dostane jako první a druhý je bude se tam dostat po. Takže nakonec, jsem přidal dva. Víš, co tím myslím? DOBŘE. 

Trvanlivost je velice jednoduché. Když je transakce Uznává se, že je to Bude tam i v případě, že systém se zhroutí. Když se tento systém využívá, že Transakce, která byla spáchána je ve skutečnosti tam bude. Tak to je záruky kyseliny transakcí. To jsou docela pěkné záruky mít na databázi, ale přijdou na těchto nákladů. Právo? 

Vzhledem k tomu, problém s tento rámec v případě, že je oddíl v datech set, musím učinit rozhodnutí. Budu muset umožnit Aktualizace na jedné nebo druhé straně. A pokud se tak stane, pak jsem už jít aby bylo možné zachovat tyto vlastnosti. Nebudou konzistentní. Nebudou být izolovány. To je místo, kde se rozkládá pro relační databáze. To je důvod, relační databází měřítko vertikálně. 

Na druhé straně, máme co se nazývá BASE technologie. A to jsou vaše NoSQL databáze. Dobře. Takže máme CP, databáze AP. A to jsou v podstatě to, co říkáte k dispozici, měkký stav, případně konzistentní. DOBŘE? 

V podstatě k dispozici, protože jsou to oddíl tolerantní. Budou vždy tam, a to i v případě, že je dělicí síť mezi uzly. Mohu-li mluvit k uzlu, já jsem bude schopen číst data. DOBŘE? I nemusí být vždy schopen napsat Údaje, jestli jsem konzistentní platformu. Ale budu moci číst data. 

Měkká stav označuje že když jsem si přečetl, že data, to nemusí být stejné jako ostatních uzlů. Jestliže právo bylo vydáno v uzlu někde jinde v clusteru a nebyla replikována napříč klastr ale když jsem četl, že údaje, že stát nemusí být konzistentní. Nicméně, to bude nakonec konzistentní, což znamená, že když je pro zápis se provádí v systému, se bude replikovat přes uzly. A nakonec, že ​​státní budou uvedena do pořádku, a to bude konzistentním stavu. 

Nyní, teorém CAP opravdu hraje jen v jednom stavu. Tato podmínka je, když se to stane. Vzhledem k tomu, kdykoli je to pracovat v normální režim, neexistuje žádný oddíl, všechno je konzistentní a jsou k dispozici. Stačí pouze starat o SZP když máme tento oddíl. Takže ty jsou vzácné. Ale jak systém reaguje, když ti, dochází diktovat, jaký typ systému máme co do činění s. 

Takže pojďme se podívat na to, co že vypadá jako na AP systémy. DOBŘE? Systémy AP přicházejí ve dvou příchutích. Přicházejí v chuti, která je master master, 100%, vždy k dispozici. A přicházejí v jiná varianta, která říká, Víš co, já budu dělat starosti o Toto rozdělení věci v případě, že skutečná partition dojde. Jinak to bude primární uzly, kdo bude mít práva. DOBŘE? 

Pokud tedy něco jako Cassandra. Cassandra by být mistr master, dovolte mi, abych to zapsat do kteréhokoliv uzlu. Takže co se stane? Takže mám objekt v databáze, která existuje na dvou uzlů. Říkejme tento objekt S. Takže máme stát pro S. Máme některé operace na S, které probíhají. Cassandra mi dovoluje pište na více uzlů. Takže řekněme, že jsem se dostat psát pro s dvěma uzly. No, co skončí děje, je říkáme, že rozdělovacím události. Tam nemusí být oddíl fyzická síť. Avšak z důvodu konstrukce systému, to je ve skutečnosti rozdělení jakmile jak jsem si psát na dvou uzlů. Není to mě nutí napsat celý jeden uzel. Píšu na dvou uzlů. DOBŘE? 

Takže teď mám dva stavy. DOBŘE? Co se bude dít je dříve nebo později, tam to bude událost replikace. Tam to bude to, co jsme volal zotavení oddíl, který je místo, kde tyto dva státy vrátit spolu a tam to bude algoritmus který běží uvnitř databáze, se rozhodne, co má dělat. DOBŘE? Ve výchozím nastavení, poslední aktualizace vítězí ve většině systémů AP. Takže tam je obvykle výchozí algoritmus, co říkají zpětné volání funkce, něco, bude volána, když tato podmínka je detekován provádět nějakou logiku k vyřešení tohoto konfliktu. DOBŘE? Výchozí zpětné volání a výchozí resolver ve většině AP databázích je, víš co, timestamp vyhrává. To byla poslední aktualizace. Chystám se dát tuto aktualizaci tam. Možná jsem výpis tento záznam, který jsem dumpingové off do protokolu obnovy takže uživatel může přijít později a říct, hej, došlo ke kolizi. Co se stalo? A můžete skutečně výpis záznam všechny kolize a vrácení provedených změn a uvidíme, co se stane. 

Nyní, jako uživatel, můžete také obsahovat logiku do tohoto zpětného volání. Takže si můžete změnit zpětné volání operace. Můžete říct, hej, já chci k nápravě tohoto data. A já chci, aby se pokusila sloučit tyto dva záznamy. Ale to je jen na vás. Databáze neví, jak se tomu, že ve výchozím nastavení. Nejvíce času, jediné, co je databáze Ví, jak udělat, je říci, tenhle byl poslední záznam. To je ten, který vyhraje, a to je hodnota jdu dát. Jakmile to oddíl zotavení a dojde k replikaci, máme stát, který Nyní je S prvočíslo, což je sloučení stav všech těchto objektů. Takže systémy AP tohle. CP systémy nepotřebují se starat o to. Vzhledem k tomu, jakmile oddíl přichází do hry, prostě přestat užívat píše. DOBŘE? Takže je to velmi snadné vypořádat s tím, že v souladu pokud nechcete přijímat žádné aktualizace. To je s CP systémy dělají. Dobře. 

Takže pojďme mluvit trochu něco o přístupových vzory. Když mluvíme o NoSQL, je to vše o vzorek přístup. Nyní, SQL je ad hoc dotazy. Je to relační obchod. Nemusíme se bát o vzorek přístup. Píšu velmi složitý dotaz. Jde to a získává data. To je to, co to vypadá jako, normalizace. 

Takže v tomto konkrétní strukturu, díváme na katalog produktů. Mám různé druhy výrobků. Mám knihy. Mám alba. Mám videa. Vztah mezi výrobky a některý z těchto knih, alb, a videa tabulek je 1: 1. Dobře? Mám ID produktu, a že ID odpovídá na knihu, album, nebo video. DOBŘE? To je vztah 1: 1 po těchto tabulkách. 

Teď, books-- všechno, co mají vlastnosti je root. Žádný problém. To je skvělé. One-to-one vztah, jsem si všechny údaje musím popsat tu knihu. Albums-- alba mají stopy. To je to, co nazýváme jeden k mnoho. Každé album může mít mnoho stop. Takže pro každé dráze na album, mohl bych mít další rekord v tomto podřízené tabulce. Tak jsem vytvořit jeden záznam v mém alba tabulce. Vytvořit více záznamů v tabulce stop. One-to-many vztah. 

Tento vztah je to, co nazýváme many-to-many. DOBŘE? Vidíte, že herci by mohla být v mnoha filmech, mnoho videí. Takže to, co děláme, je, že jsme dát toto mapování tabulku mezi těmi, které se právě mapuje herce ID do ID videa. Nyní mohu vytvořit dotaz spoje videa přes herec videa do herců, a to mi dává pěkný seznam všechny filmy a všichni herci kteří byli v tom filmu. 

DOBŘE. Tak jdeme na to. One-to-one je nejvyšší úrovně vztah; one-to-many, alba skladeb; many-to-many. To jsou tři nejvyšší úrovně vztahy v žádné databázi. Pokud víte, jak ti, vztahy pracovat společně, pak víte hodně o již databáze. Takže NoSQL trochu funguje jinak. Pojďme se zamyslet nad za druhé to, co to Vypadá to, jít pro všechny své produkty. 

V relační obchodě, já se chtějí dostat všechny své produkty na seznamu všech mých výrobků. To je hodně dotazů. Mám dotaz pro všechny moje knihy. Mám dotaz od svých alb. A já mám dotaz pro všechny mých videí. A já musím dát vše dohromady v seznamu a slouží to zpět až do výše aplikace, která je o to požádá. 

Chcete-li získat své knihy, jsem se připojit Produkty a knihy. Chcete-li získat moje alba, jsem se připojit Produkty, alba a skladby. A aby se moje videa, mám připojit produktů na videa, připojit přes herců videa, a přinést herců. Tak to je tři dotazy. Velmi složité dotazy na shromáždit jednu sadu výsledků. 

To je méně než optimální. To je důvod, proč, když mluvíme o datové struktury, která je postavena tak, aby agnostik s přístupem pattern-- dobře, že je to skvělé. A vidíte, je to opravdu pěkné, jak jsme organizovali data. A víte co? Mám jen jeden záznam pro herce. 

To je v pohodě. Já jsem deduplikovány všechny své herce, a já udržovány své sdružení V této tabulce mapování. Nicméně, jak se data out se stává dražší. Posílám CPU celého systému spojující tyto datové struktury spolu aby bylo možné vytáhnout, že data zpět. 

Tak jak to mám dostat kolem, že? V NoSQL je to o agregace, ne normalizace. Takže chceme říci chceme podporovat přístup vzor. Pokud vzorek přístup k aplikacím, Musím se dostat všechny své výrobky. Pojďme dát všechny produkty v jedné tabulce. Když jsem dal všechny produkty v jedné tabulce, Já si jen vybrat všechny produkty Z této tabulky, a já si to všechno. Tak jak to mám udělat, že? No v NoSQL není struktura ke stolu. Budeme mluvit trochu o Jak to funguje Dynamo DB. Ale nemusíte mít stejný atributy a stejné vlastnosti v každé řadě, v každém jednotlivém položky, jako vy v tabulce SQL. A co mi to dovoluje udělat, je spousta věcí a dal mi velkou flexibilitu. V tomto konkrétním případě, I mají svůj produkt doklady. A v tomto konkrétním příklad, všechno je dokument, v tabulce Výrobky. A produkt pro knihu by mohl mají ID typu, který určuje knihu. A aplikace by se mělo přepnout na tomto ID. 

V aplikační vrstvě, jdu říkat ach, jaký typ záznamu je to? Oh, to je kniha rekord. Book záznamy mají tyto vlastnosti. Dovolte mi, abych vytvořit knihu objekt. Takže já jdu pro naplnění kniha objekt s touto položkou. Další položka přijde a říká, co je tato položka? No tato položka je album. Oh, mám úplně jiná rutina pro zpracování, které, protože je to album. Víš, co tím myslím? 

Takže aplikace tier-- I stačí vybrat všechny tyto záznamy. Všichni začnou přicházet dovnitř. Mohly by být veškeré typy. A je to logika aplikace který přepíná napříč těchto typů a rozhodne, jak je zpracovat. 

Opět, takže jsme optimalizaci schéma vzorek přístup. Děláme to tím, hroutí ty tabulky. Jsme v podstatě převzetí Tyto normalizované struktury, a stavíme hierarchické struktury. Uvnitř každé z těchto záznamů Jdu vidět vlastnosti pole. 

Uvnitř tohoto dokumentu pro alba, Vidím matice stop. Tyto stopy teď become-- je to v podstatě toto dítě tabulka existuje přímo zde v této struktuře. Takže můžete to provést v DynamoDB. Můžete to udělat v MongoDB. Můžete to udělat v jakékoliv databázi NoSQL. Vytvořte tyto typy hierarchické datové struktury které umožňují načtení dat velmi rychle, protože teď Nemusíte odpovídat. Když jsem se vložit řádek do kolejích stůl, nebo o řádek do tabulky Alba Musím odpovídat tomuto schématu. Musím mít atribut nebo majetek, který je definován na této tabulce. Každý z nich, když jsem vložte tento řádek. To není případ v NoSQL. 

Můžu mít zcela odlišné vlastnosti v každém dokumentu že jsem se vložit do sbírky. Takže velmi silný mechanismus. A je to opravdu, jak vás optimalizaci systému. Vzhledem k tomu, teď, že dotaz, namísto spojování všechny tyto tabulky a provádění půl tuctu dotazy vytáhnout zpět data, co potřebuji, Jsem vykonávající jeden dotaz. A já jsem iterace přes výsledky uvedené. to vám dává představu o síle NoSQL. Chystám se jít trochu bokem zde a mluvit trochu o tom. To je více druhů marketing nebo technology-- marketing technologie typ diskuse. Ale je důležité pochopit, protože když se podíváme na vrcholu zde na tento graf, co se díváme je to, co nazýváme Technologie humbuk křivka. A co to znamená, nové věci přichází do hry. Lidé si myslí, že je to skvělé. Já jsem vyřešil všechny mé problémy. 

To by mohlo být konec všichni, být vše, na všechno. A začnou používat. A oni říkají, tohle nefunguje. To není správné. Staré věci byly lepší. A oni se vrátit k dělání věci tak, jak byly. A pak nakonec jdou, víš co? Tohle není tak špatné. Ach, to je, jak to funguje. A jakmile se zjistit, jak to práce, začnou stále lepší. 

A legrační věc, o tom Je to trochu linek až na to, co nazýváme Technology osvojení dítěte křivky. Takže co se stane, je, že jsme se nějaká technologie spoušť. V případě databází, to je tlak dat. Mluvili jsme o vysokých vodních bodů tlaku dat po celou dobu. Když tato data tlak zasáhne určité bod, to je technologie spoušť. 

Začíná to příliš drahé. To trvá příliš dlouho, aby zpracování dat. Potřebujeme něco lepšího. Získáte inovátorů tam venku pobíhají, snaží zjistit, jaké je řešení. Co je to nová myšlenka? 

Jaký je další nejlepší způsob, jak tuto věc? A oni přijdou s něčím. A lidé s skutečnou bolest, kluci na drsně, budou skákat přes to všechno, protože potřebují odpověď. A teď, co nevyhnutelně happens-- a to se právě teď děje v NoSQL. Vidím to po celou dobu. 

Co se nevyhnutelně stane, je lidé začnou používat nový nástroj stejný způsob, jakým používá staré nástroje. A oni zjistili to nefunguje tak dobře. Nemohu si vzpomenout, kdo jsem mluvit dneska. Ale je to jako, když se sbíječka byl vynalezen, lidé neměli houpačka ji jejich hlava rozbít beton. 

Ale to je to, co je děje NoSQL dnes. Půjdete-li ve většině obchodů, se snaží být NoSQL obchodů. To, co děláte, je Používají NoSQL, a oni ho načítání plná relačního schématu. Vzhledem k tomu, že to, jak navrhují databází. A oni jsou zvědaví, proč je to nefunguje dobře? Páni, tahle věc smrdí. Musel jsem se udržet všechny mé připojí in-- je to jako, ne, ne. Udržovat se připojí? Proč se připojí data? Nemusíte připojit data v NoSQL. Agregovat to. 

Takže pokud chcete, aby se tomu zabránilo, učit se jak nástroj funguje před vámi vlastně začít používat. Nesnažte se používat nové nástroje pro Stejným způsobem jste použili staré nástroje. Budeš mít špatnou zkušenost. A pokaždé to je to, o co jde. Když jsme se začnou přicházet sem, je to proto, že lidé zjistili, jak používat nástroje. 

Udělali stejnou věc, když relační databáze byly vynalezeny, a oni byli nahrazení souborové systémy. Snažili se vybudovat souborové systémy s relačních databází protože to je to, co lidé pochopili. Nefungovalo to. Takže pochopení osvědčených postupů technologie pracujete s je obrovský. Velmi důležité. 

Takže jsme se dostat do DynamoDB. DynamoDB je AWS je Plně řízené NoSQL platformy. Co znamená plně řízené znamená? To znamená, že nemusíte opravdu o nic starat. 

Můžete přijít, řeknete us, potřebuji tabulku. Je třeba tolik kapacity. Stisknete tlačítko, a my ustanovení veškerá infrastruktura za scény. Teď, když je obrovský. 

Vzhledem k tomu, když mluvíte škálování o databáze, NoSQL datové klastry na stupnice, provozní petabajtů, běží miliony transakcí za sekundu, tyto věci nejsou malé shluky. Mluvíme tisíce instancí. Správa tisíce případů, dokonce i virtuální instance, je skutečnou bolest v zadku. Mám na mysli, přemýšlet o tom, pokaždé, když Systém náplast provozní vyjde nebo novou verzi databáze. Co to znamená vám provozně? To znamená, že máš 1200 servery, které je třeba aktualizovat. Nyní ještě s automatizací, který může trvat dlouhou dobu. To může způsobit hodně provozní bolesti hlavy, proto, že jsem mohl mít služby dolů. 

Když jsem aktualizovat tyto databáze, já mohli dělat modrá zelená nasazení kde jsem nasadit a upgrade polovina mé uzly, a potom inovovat druhou polovinu. Vezměte ty dole. Takže řízení infrastruktury Měřítko je nesmírně bolestivé. A AWS přijmout, že bolest z ní. A databáze NoSQL může být mimořádně bolestivá vzhledem ke způsobu jejich měřítko. 

Měřítko vodorovně. Chcete-li mít větší NoSQL databáze, kupujete více uzlů. Každý uzel si koupíte, je další operační bolest hlavy. Tak ať někdo jiný udělá za vás. AWS může udělat. 

Podporujeme hodnoty klíčového dokumentu. Teď jsme nešli moc do na straně grafu. Je tu mnoho různých chutí NoSQL. Jsou to všechny druhy získávání munged společně v tomto bodě. Můžete se podívat na DynamoDB a říct ano, oba jsme dokument a klíčovou hodnotou uložit tento bod. A můžete argumentovat funkce jednoho nad druhým. Pro mě, hodně je to opravdu six jedné půl tuctu druhého. Každý z těchto technologií je jemné technologie a kvalitní řešení. Neřekl bych, že je lepší nebo MongoDB horší než Couch, pak Cassandra, pak Dynamo, nebo naopak. Chci říct, že to jsou jen možnosti. 

Je to rychlé a je to konzistentní v jakémkoli měřítku. Takže to je jedna z největších bonusy získáte s AWS. S DynamoDB je schopnost získat nízké jednu číslici milisekunda zpoždění v jakémkoli měřítku. To byl cíl designu systému. A máme zákazníky, které dělají miliony transakcí za sekundu. 

Teď budu jít přes některé z těch, případů použití za několik minut zde. Integrovaný přístup control-- máme to, co nazýváme Identity Access Management, nebo IAM. To prostupuje všechny systémy, každá služba, která nabízí AWS. DynamoDB není výjimkou. Můžete řídit přístup k DynamoDB tabulek. Přes všechny vaše AWS účtů definování přístupových rolí a oprávnění v IAM infrastruktury. 

A to je klíč a nedílnou složkou to, co nazýváme událostmi řízené programování. Nyní se jedná o nové paradigma. 

Diváků: Jak je na tom vaše rychlost true pozitiva oproti falešně negativních ve vašem systému řízení přístupu? RICK Houlihan: Pravda pozitivy proti falešně negativní? Publikum: Vrácení co měli byste se vrací? Na rozdíl od jednou za čas to nevrací, kdy by měl ověřit? 

RICK Houlihan: Nemohla jsem ti to říct. Pokud existuje nějaké poruchy vůbec na to, Nejsem člověk se zeptat že zvláštní otázka. Ale to je dobrá otázka. Byl bych zvědavý že sám, ve skutečnosti. 

A tak opět, nové paradigma je událostmi řízené programování. To je myšlenka, že můžete nasadit komplexní aplikace, které může pracovat velmi, velmi vysoká měřítka bez jakékoliv infrastruktury vůbec. Bez stanovených infrastrukturu vůbec. A budeme mluvit trochu o tom, co to znamená, že jako my dostat se na další pár grafů. 

První věc, kterou uděláme je budeme mluvit o tabulkách. Datové typy API pro Dynamo. A první věc, kterou budete Všimněte si, když se podíváte na to, pokud jste obeznámeni s libovolnou databází, databáze mají opravdu dva druhy API Já bych to říkat. Nebo dvě sady API. Jednou z nich by byl administrativní API. 

Věci, které se starají o Funkce databáze. Konfigurace engine pro ukládání, zřizování a přidávání tabulek. vytvoření databáze katalogy a instance. Ty things-- v DynamoDB, budete mají velmi krátký, krátký seznamy. 

Takže v jiných databázích, můžete vidět desítky příkazů, správních příkazy, pro konfiguraci tyto další možnosti. V DynamoDB nepotřebujete, protože ti, nenakonfigurujete systém, co děláme. Takže jediná věc, kterou musíte udělat, je řekni mi, co velikost tabulky potřebuji. Tak dostanete velmi omezený soubor příkazů. 

Získáte CREATE TABLE aktualizace, tabulka, Odstranit tabulku a označení stolních. To jsou jediné věci, co potřebujete pro DynamoDB. Nemusíte úložiště konfigurace motoru. Nepotřebuju se starat o replikaci. Nepotřebuju se starat o sharding. 

Nepotřebuji se obávat o některý z těchto věcí. Děláme to vše za vás. Tak to je obrovské množství režie to je jen zvedne talíř. Pak máme operátory CRUD. CRUD je něco, co jsme volat v databázi, která je Vytvořit, aktualizovat, mazat operátorů. To jsou vaše běžné databázové operace. Věci jako put položku, dostat položku, aktualizace položky, mazat položky, šarže dotaz, skenovat. Chcete-li skenovat celou tabulku. Vytáhněte všechno ze stolu. Jedna z pěkné věci o DynamoDB Je to umožňuje paralelní skenování. Takže můžete ve skutečnosti, dejte mi vědět, kolik nitě chcete spustit na tom skenu. A můžeme spustit tyto závity. Můžeme točit, že skenovat nahoru napříč více vláken takže můžete skenovat celou tabulku space velmi, velmi rychle DynamoDB. 

Další API máme, je to, co nazýváme Streams API. Nebudeme mluvit příliš hodně o tom právě teď. Mám nějaký obsah později Na v balíčku o tom. Ale proudy je opravdu running-- myslet na to, jak čas objednat a změna oddíl log. Všechno, co se děje na V tabulce se objeví na proudu. 

Každý zapsat do tabulky se objeví na proudu. Můžete si přečíst tento proud, a můžete dělat, co s ním. Promluvíme si o tom, co typy věcí, činění s věcmi, jako jsou replikace, vznikají sekundární indexy. Všechny druhy opravdu cool věci, které můžete udělat s tím. 

Datové typy. V DynamoDB, podporujeme i klíč hodnota a datové typy dokumentů. Na levé straně obrazovky tady, máme naše základní typy. Typy hodnoty klíče. Jsou to řetězce, čísla a binární soubory. 

Takže jen tři základní typy. A pak můžete mít sady ty. Jedna z pěkné věci o NoSQL je můžete obsahovat pole jako vlastnosti. A s DynamoDB můžete obsahovat pole základních typů jako kořenová vlastnost. 

A pak je tu typy dokumentů. Kolik lidí jsou obeznámeni s JSON? Vy obeznámení s JSON tolik? Je to v podstatě JavaScript, Object, notace. To vám umožní v podstatě definují hierarchickou strukturu. 

Můžete uložit dokument o JSON DynamoDB použití běžných komponent nebo stavební bloky, které jsou k dispozici ve většině programovacích jazycích. Takže pokud máte Javu, budete při pohledu na mapách a seznamy. Mohu vytvořit objekty, které Mapa oblasti. Mapa jako klíčové hodnoty uložena jako vlastnosti. A to by mohlo mít seznamy hodnot v rámci těchto vlastností. Můžete ukládat tento komplex hierarchická struktura jako jediný atribut z položky DynamoDB. 

Takže tabulek v DynamoDB, stejně jako většina Databáze NoSQL, tabulky mají položky. V MongoDB byste volání těchto dokumentů. A to by byl gauč základna. Také dokument databáze. Zavoláte těchto dokumentů. Dokumenty nebo položky mají atributy. Atributy mohou existovat nebo neexistuje na položku. V DynamoDB, je tu jedním povinný atribut. Stejně jako v relační databázi, máte primární klíč na stole. 

DynamoDB má to, co nazýváme hash klíč. Hash klíč musí být jedinečný. Takže když jsem definovat hash tabulky, v podstatě to, co říkám je každá položka bude mít hash klíč. A každý křížkem musí být jedinečný. 

Každá položka je definována touto unikátní křížek. A tam může být jen jeden. To je v pořádku, ale častokrát to, co lidé potřebují je chtějí, je to hash Klíčem k tomu trochu více než být jen jedinečný identifikátor. Často chceme použít tento hash klíč jako nejvyšší úrovně agregace kbelíku. A způsob, jak to udělat, je tím, přidávání říkáme rozsah klíč. 

Takže pokud je to jen hash stůl, musí to být jedinečná. Pokud se jedná o hash a rozsah tabulky se kombinace hash a rozsah musí být jedinečný. Takže myslíte, že o tom tímto způsobem. Mám-li fórum. A forma má témat, má sloupky, a to má odpovědi. 

Takže jsem mohl mít hash klíč, což je téma ID. A já mohla mít rozsah klíč, což je ID odpověď. Tak, když chci, aby si všechny odpovědi na určité téma, Mohu jen dotaz hash. Mohu jen říct, dej mi všechny položky, které mají tuto hash. A budu se dostat na každou otázku nebo poštou na tuto konkrétní téma. Tyto špičkové úrovně agregace jsou velmi důležité. Podporují primární přístup vzor žádosti. Obecně řečeno, toto je to, co chceme dělat. Chceme, aby table-- jak si nahrát tabulku, chceme strukturovat data v tabulce tak, že aplikace může velmi rychle získat tyto výsledky. A často způsob, jak to udělat, je udržovat tyto agregací jako my vložit data. V podstatě jsme šíření dat do jasného kbelíku, jak to přichází v. 

Rozsah tlačítka umožňují me-- hash Klávesy mají být rovnost. Když jsem dotazu hash, musím říci, dej mi hash, která se rovná toto. Když jsem dotaz rozsah, já Dá se říci, dej mi rozsah že je použití jakékoli bohatý subjekt, který podporujeme. Dej mi všechny položky pro hash. Je to stejné, větší než, méně než, to začíná, to existují mezi těmito dvěma hodnotami? Takže tyto typy rozsahu dotazů že máme vždy zajímá. A teď jedna věc, o datech, kdy se podíváte na přístup k datům, kdy máte přístup k datům, je to Vždycky jde o agregaci. Je to vždycky o záznamech které se vztahují k této. Dejte mi tady všechno that's-- všechny transakce na této kreditní karty za poslední měsíc. To je agregace. 

Téměř všechno, co děláte v Databáze je nějaký druh agregace. Tak budou moci být schopni definovat Tyto kbelíky a dá vám tyto rozsah atributy, aby bylo možné na dotaz na, ty bohaté dotazů podporuje mnoho, mnoho, mnoho přístup k aplikacím vzory. 

Takže další věc, s křížkem dělá je, že nám dává mechanismus aby bylo možné rozšířit data kolem. Databáze NoSQL fungují nejlépe když jsou data rovnoměrně distribuována po clusteru. Kolik lidí zná s algoritmy hash? Když řeknu, že hash a hashing-- protože je algoritmus hash je způsob, jak být schopen generovat náhodná hodnota z jakékoliv dané hodnoty. Takže v tomto konkrétním případě hashovací algoritmus provozujeme je ND 5 na základě. 

A pokud mám ID, a to je můj křížkem, mám 1, 2, 3. Když spustím hash algoritmu, to bude, aby se vrátil a řekl, dobře 1 rovná 7B, 2 se rovná 48, 3 se rovná CD. Jsou rozšířily do celého klíče prostoru. A proč to děláte? Vzhledem k tomu, že zajistí, že mohu dal záznamy přes více uzlů. 

Pokud bych to dělám postupně, 1, 2, 3. A mám hash rozsah, který probíhá v tomto konkrétním případě, malý hash prostor, běží od 00 do FF, pak záznamy se chystáte přijít a oni se chystáte jít 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. Co se děje? Každá vložka bude stejném uzlu. Víš, co tím myslím? 

Protože když jsem se rozdělit prostor, a já se šíří přes tyto záznamy, a oddíl já, já jsem chtěl říct, oddíl 1 má klíčový prostor, 0 až 54. Oddíl 2 je 55 až 89. Oddíl 3 AA až FF. Takže když jsem pomocí lineárně zvyšování ID, můžete vidět, co se děje. 1, 2, 3, 4, 5, 6, vše až po 54. Takže jak jsem zatloukat záznamy do systému, všechno skončí jít do jednoho uzlu. 

To není dobré. To je antipattern. V MongoDB mají tento problém pokud nechcete použít hash klíč. MongoDB vám dává možnost z hash hodnotu klíče. Vždy byste měli udělat, pokud vy používáte incrementing hash Zadejte MongoDB, nebo budete přibil každý zápis do jednoho uzlu, a budete omezující Váš zápis propustnost špatně. 

Diváků: Je to A9 169 v desítkové soustavě? 

RICK Houlihan: Jo, to je někde kolem tam. A9, já nevím. Musel byste, aby mi binární na desetinné kalkulačka. Můj mozek nefunguje takhle. Diváků: Jen rychlý jedním Vaše připomínky Mongo. Tak je objekt, ID, který je dodáván nativně s Mongo dělat, že? RICK Houlihan: Má to udělat? Pokud jej specifikovat. S MongoDB, máte možnost. Můžete specify-- každý dokument v MongoDB musí mít podtržítko ID. To je unikátní hodnota. 

V MongoDB můžete zadat zda hash, nebo ne. Prostě vám možnost. Pokud víte, že je to náhodný, žádný problém. Nemusíte to dělat. Pokud víte, že to není náhodné, že to postupně, pak to hash. 

Nyní věc, o zatřiďování, jakmile se hash value-- a to je Proč hash klíče jsou vždy unikátních dotazů, protože jsem se změnil je hodnota, teď nemůžu udělat dotaz rozsahu. Nemůžu říct, že je to mezi to či ono, protože hodnota hash nebude se rovná skutečné hodnoty. Takže když hash, že klíč, je to jen rovnost. To je důvod, proč v DynamoDB křížek dotazy jsou vždy jen rovnost. 

Takže teď v rozmezí key-- když jsem se dodat, že rozsah klíč, tyto záznamy důležité spektrum všichni přijít a oni se ukládají na stejný oddíl. Tak oni jsou velmi rychle, snadno načíst, protože to je hash, to je řada. A vidíte všechno se stejnou hash je uložena na stejném oddílu prostoru. Můžete použít tento rozsah klíč pomoci lokalizovat data v blízkosti jeho rodiče. Tak co mám vlastně tady děláš? To je jedním mnoha vztahu. Vztah mezi křížek a rozsah klíč je, kdo mnoho. Mohu mít více hash klíčů. Mohu mít jen více rozsah klíče v každé křížek. 

Hash definuje rodiče, rozsah definuje děti. Takže můžete vidět, že je analogový zde mezi relační konstruktu a stejné typy konstrukty v NoSQL. Lidé mluví o NoSQL jako Nonrelational. Není to Nonrelational. Údaje má vždy vztahy. Tyto vztahy jen jsou modelovány jinak. Pojďme mluvit trochu něco o trvanlivost. Při psaní se DynamoDB, píše jsou vždy třícestný replikovány. To znamená, že máme tři AZ je. AZ to jsou volné zóny. Můžete myslet na dostupnost Zone jako datové centrum nebo soubor datových center. Tyto věci jsou geograficky izolovány od sebe navzájem napříč různými zlomové, napříč odlišný rozvodné sítě a zátopových oblastí. Selhání v jedné AZ není bude trvat dolů další. Oni jsou také spojeny spolu s tmavým vláknem. To podporuje jeden sub 1 milisekunda zpoždění mezi AZS. Takže data replikace v reálném čase schopné v bytových AZS. 

A často multi nasazení AZ splňovaly požadavky na vysokou dostupnost většiny podnikových organizací. Takže DynamoDB se šíří ve třech AZS ve výchozím nastavení. Budeme jen k poznání Write když se dva z těchto tří uzlů vrátí a říkají, Jo, mám to. Proč tomu tak je? Vzhledem k tomu, na čtení stranu jsme jen dám vám data zpět, pokud jsme ho dostat ze dvou uzlů. 

Pokud jsem replikace napříč tři, a čtu ze dvou, Já jsem vždy zaručena mít alespoň jeden z nich čte, že je Nejaktuálnější kopie dat. To je to, co dělá DynamoDB konzistentní. Nyní si můžete vybrat otočit ty konzistentní čte off. V tom případě budu říkat, Budu číst pouze z jednoho uzlu. A nemůžu zaručit, že to bude být nejvíce aktuální data. 

Takže pokud write přichází, to nebyla replikována dosud, budete se dostat, že kopie. To je nakonec konzistentní čtení. A co to je, je polovinu nákladů. Takže to je o čem přemýšlet. Když čtete ven DynamoDB, a jste nastavování čtení kapacity jednotek, pokud se rozhodnete nakonec konzistentní čte, je to mnohem levnější, je to o polovinu nákladů. 

A tak se ušetří peníze. Ale to je vaše volba. Pokud chcete, konzistentní čtení nebo nakonec konzistentní čtení. To je něco, co si můžete vybrat. 

Pojďme se bavit o indexech. Tak jsme se zmínili, že nejvyšší úrovně agregace. Máme hash klíče, a máme rozsah klíče. To je milé. A to je na primární tabulky, já má jedno křížkem, mám jeden rozsah klíč. 

Co to znamená? Mám jeden atribut, že jsem může běžet bohaté dotazy proti. Je to rozsah klíč. Ostatní atributy na té item-- Mohu filtrovat na těch atributech. Ale nemůžu dělat věci jako, to začíná, nebo je větší než. 

Jak to dělám? I vytvořit index. Jsou dva typy indexy v DynamoDB. Index je opravdu Jiný pohled na tabulky. A místní sekundární index. 

První z nich budeme mluvit. Takže místní pobočníci se koexistovaly na stejném oddílu jako data. A jako takové, jsou na stejné fyzikální uzel. Oni jsou to, co nazýváme konzistentní. Význam, budou uznávat zápisu spolu s tabulkou. Při zápisu přijde, budeme psát přes index. Budeme psát až ke stolu, a pak budeme potvrdit. Tak to je konzistentní. Jakmile je zápis byl uznala od stolu, je zaručeno, že místní sekundární index bude mít stejnou vizi dat. Ale to, co vám umožní udělat, je definovat alternativní klíče rozsah. 

Musí používat stejný hash key jako primární tabulce, proto, že jsou umístěny na stejném místě na stejný oddíl, a jsou konzistentní. Ale můžu vytvořit index s různými klíči dosahu. Tak například, pokud jsem měl výrobce že měl části tabulky syrové přicházet. A RAW díly dodáváme v a oni jsou agregované sestavou. A možná je tu odvolání. 

Každá část, která byla vyrobena tímto Výrobce po tomto datu, Musím vytáhnout z mého linky. Dokážu točit index že bude hledat, agregaci dnem Výroba této konkrétní části. Takže pokud můj stůl nejvyšší úroveň byla již zatříděna podle výrobce, Možná to bylo uspořádáno na částečný ID, já Můžete vytvořit index off této tabulce jak hash výrobce a pohybovala na data výroby. A takhle bych mohl říci, že cokoli byl vyroben mezi těmito daty, Musím vytáhnout z linky. Tak to je místní sekundární index. 

Ty mají za následek omezit svou klíčovou prostor hash. Vzhledem k tomu, že koexistovaly na stejné úložné uzlu, omezují s křížkem prostor na 10 GB. DynamoDB, pod stoly, se rozdělí Váš stůl každých 10 gigabajtů. Když dáte 10 koncerty dat v, my go [PhH], a my jsme přidat další uzel. 

Nebudeme rozdělit LSI přes více oddílů. Budeme rozdělit tabulku. Ale nebudeme rozdělit LSI. Tak to je něco, důležité pochopit je, pokud děláte hodně, velmi, velmi velké shluky, pak jste bude omezen 10 GB na vašem LSIS. 

Pokud tomu tak je, můžeme použít globální Sekundární. Globální secondaries jsou Opravdu jiné tabulky. Existují úplně pryč strana primární tabulky. A dovolte mi, abych najít zcela odlišná struktura. Takže myslíte, že na to, jak se vkládá údaje do dvou různých tabulek, strukturované dvěma různými způsoby. 

Mohu definovat zcela jiný křížkem. Mohu definovat zcela jiný klíč rozsah. A můžu běžet to zcela nezávisle na sobě. Jako ve skutečnosti, jsem dotován mé čtení kapacity a psát kapacity pro mou globální sekundární indexy zcela nezávisle můj primární tabulky. Kdybych stanoví tento index, řeknu to, jak moc číst a psát Kapacita to bude používat. 

A to je samostatná z mého primární tabulky. Nyní oba indexy nám umožňují nejen definovat hash a rozsah kláves, ale oni nám umožňují promítat další hodnoty. Takže pokud chci odečtěte index, a chci získat nějaké sadu dat, Nepotřebuji se vrátit do hlavního Tabulka získat další atributy. I může promítat ty další atributů do tabulky podporovat přístup vzor. Vím, že jsme asi dostat do některých Opravdu, really-- dostat do plevel tady na některé z těchto věcí. Teď mám se nechat unášet z toho. 

Diváků: [Neslyšitelné] --table klíč znamenalo, hash? Původní hash? Multi-lamely? 

RICK Houlihan: Ano. Ano. Tabulka klíč v podstatě poukazuje zpět do položky. Tak že index je ukazatel zpět do původní položky na stole. Nyní si můžete vybrat vybudovat index, který má pouze tabulku klíč, a žádné jiné vlastnosti. A proč bych to dělal? No, možná mám velmi velké položky. 

Opravdu jen potřebuji vědět which-- můj přístup vzor by se říci, položky, které obsahují tuto nemovitost? Nepotřebujete vrátit položku. Prostě potřebuju vědět, položky, které obsahují to. Takže si můžete vytvořit indexy které mají pouze tabulku klíč. 

Ale to je v první řadě to, co index v databázi je pro. Je to, že jsou schopny rychle určit, které zaznamenává, které řádky, které položky v tabulce mají vlastnosti, které jsem hledali. 

GSIS, tak jak fungují? GSIS v podstatě jsou asynchronní. Aktualizace přichází do tabulky, Tabulka je pak asynchronně aktualizován všechny vaše GSIS. To je důvod, proč jsou GSIS nakonec konzistentní. 

Je důležité poznamenat, že když stavíte GSIS, a pochopíte, budete vytvářet další rozměr aggregation-- Nyní řekněme, že dobrý příklad Zde je výrobce. Myslím, že bych mohl mít mluvil o lékařské výrobce zařízení. Výrobci Lékařské zařízení častokrát mají Serializovaná části. Části, které jdou do náhradní hip vše mít trochu sériové číslo na ně. A oni mohli mít miliony a milióny a miliardy dílů ve všech zařízeních, která se loď. No, oni potřebují k agregaci v rámci různé rozměry, všechny díly v sestavě, veškeré díly, které byly provedeny na určité linie, vše části, které přišly v od určitého výrobce k určitému datu. A tyto shluky někdy dostat až do miliard. 

Tak jsem se pracovat s některými z tito lidé, kteří trpí protože jsou vytváření Tyto GINORMOUS agregace v jejich sekundárních indexů. Mohou mít syrové díly stůl, který je dodáván pouze jako hash. Každá část má unikátní sériové číslo. Já používám sériové číslo jako hash. To je krásné. Můj surová data tabulky se rozprostírá po celé klíče prostoru. Můj [? napsat ?] [? Požití?] je úžasné. Beru velké množství dat. Pak to, co dělají, je, že vytvoří GSI. A já říkám, víš co, musím vidět Všechny díly pro tohoto výrobce. No, najednou jsem si přičemž miliardy řádků, a tak je na jeden uzel, protože když I agregovat jako Výrobce ID jako hash, a číslo dílu jako oblast, pak všichni najednou, že jsem uvedení miliardy díly do čeho Tento výrobce mě doručena. 

To může způsobit hodně tlaku na GSI, znovu, protože jsem příklepem jeden uzel. Dávám všechny tyto vloží do jednoho uzlu. A to je skutečný problematický případ použití. Teď jsem dostal dobrý design vzor pro to, jak se vyhnout to. A to je jeden z problémů že jsem vždycky pracovat. Ale co se stane, je GSI může Není dostatek zápisu kapacity aby bylo možné posunout všechny ty řádků do jednoho uzlu. A co se stane, pak je primární, klient tabulka, primární tabulce bude škrtil protože GSI nemůže držet krok. Takže můj vložka sazba spadnout na primární tabulky jako můj GSI snaží držet krok. 

Dobře, takže GSI je, LSI je, který z nich bych měl použít? LSI je být konzistentní. GSI to jsou nakonec konzistentní. Pokud to je v pořádku, doporučuji pomocí GSI, jsou mnohem flexibilnější. LSI může být modelována jako GSI. A v případě, že velikost dat na hash klíčů vaše sbírka překročí 10 gigabajtů, pak budete chtít použít, že GSI, protože je to jen pevný limit. 

Dobře, takže škálování. Výkon v Dynamo DB, vy ustanovení může [neslyšitelných] propustnost do tabulky. Máme zákazníky, kteří mají dotován 60 billion-- dělají 60 miliard žádostí, pravidelně běží na více než milion žádostí za sekundu na našich stolech. To fakt není teoretický limit, kolik a jak rychle se tabulka lze spustit v Dynamo DB. Tam jsou některé měkké limity na vašem účtu že jsme dali tam tak že nemusíte zbláznit. Chcete-li více než že, není problém. Přišel jsi řekněte nám. Budeme zase až voličem. 

Každý účet je omezena na určité úrovni v každé službě, jen kousek od netopýra takže lidé nemají zbláznit dostat se do potíží. Žádný limit velikosti. Můžete dát libovolný počet položek na stole. Velikost položky je omezena na 400 kB každý, které by byly položka se atributy. Takže součet všech atributů je omezena na 400 kB. A pak znovu, máme ten malý LSI otázka s 10 GB limitu na hash. Publikum: malý počet, mi chybí to, co mi říkáte, že je-- Publikum: Oh, 400kb je maximální velikost za položku. Takže položka má všechny atributy. Takže 400 k je celková velikost této položky, 400 kilobajtů. Takže ze všech atributů kombinované, všechny údaje to je ve všech těch atributech, srolované do celkové velikosti, V současné době dnes limit položka 400 k. Takže znovu měřítka, dosáhl přes rozdělení. Propustnost je dotován na úrovni tabulky. A je to opravdu dva knoflíky. Četli jsme kapacitu a psát kapacity. 

To jsou tedy upraveny nezávisle na sobě. RCU měřítkem přísně v souladu čte. OK, takže pokud jste říkal chci 1000 RCU to ty jsou přísně konzistentní, ty jsou v souladu čte. Když řeknete, chci Eventuální konzistentní čte, můžete ustanovení 1000 RCU je, budete dostat 2.000 nakonec konzistentní čte. A poloviční cenu pro ty, nakonec spočívá v čte. 

Opět platí, upraveno nezávisle na sobě. A oni mají throughput-- Pokud budete konzumovat 100% své dálkovém ovladači, vy nebudete mít dopad na dostupnost vašich práv. Takže jsou zcela nezávisle na sobě. Dobře, takže jedna z věcí, které Zmínil jsem se krátce byl škrcení. Škrcení je špatné. Škrcení označuje špatný žádné SQL. Tam jsou věci, které můžeme udělat, aby pomohla jste zmírnit škrcení, které vás zažívají. Ale nejlepším řešením je to, pojďme Podívejte se na to, co děláte, protože tam je anti-vzor ve hře zde. 

Tyto věci, věci, jako je non-uniformě zátěže, horké klávesy, horké příčky. Jsem bít konkrétní klíčový prostor velmi těžké pro nějakého konkrétního důvodu. Proč to dělám? Pojďme zjistit, že ven. Já jsem míchání mé horké data s daty za studena. Nechávám mé tabulky dostat obrovský, ale je to opravdu pouze některé podmnožinu dat to je opravdu pro mě zajímavé. Takže pro dat protokolu, například, hodně Zákazníci, dostanou data protokolu každý den. Mají obrovské množství dat protokolu. 

Pokud jste právě dumping všechny, kteří se přihlašují Data do jednoho velkého stolu, v průběhu času že tabulka se dostane masivní. Ale já jsem opravdu zajímá jen posledních 24 hodin, posledních sedm dní, během posledních 30 dnů. Bez ohledu na časové okno že mám zájem při hledání Pro případ, že mi vadí, nebo událost, která je pro mě zajímavé, to je jediná doba, okno, které potřebuji. Tak proč jsem dávat 10 let v hodnotě dat protokolu v tabulce? To, co způsobuje, že je tabulka fragment. 

To dostane obrovský. To začne se šířit ven přes tisíců uzlů. A od té doby své funkci je tak nízká, že jste ve skutečnosti omezení rychlosti na každém jeden z těchto jednotlivých uzlů. Takže pojďme začít hledat na to, jak máme vrátit tuto tabulku přes. Jak se nám podaří, aby údaje o něco lepší se vyhnout těmto problémům. A co to vypadá? To je, co to vypadá. To je to, co špatné, NoSQL vypadá. 

Mám horkou klávesu zde. Podíváte-li se na straně tady, to všechno jsou moje oddíly. Dostal jsem 16 oddílů sem na tento konkrétní databáze. Děláme to po celou dobu. Běžím to pro zákazníky všech dob. Jmenuje se teplo mapa. Teplo mapu mi říká, jak jste přístupu k klíč prostor. A co to mi říká, je že tam je jeden konkrétní hash že tento člověk má rád strašně moc, protože je bít to opravdu, opravdu těžké. 

Takže modrá je hezká. Máme rádi modrou. Nemáme rádi červené. Red, kde je tlak dostane až do výše 100%. 100%, teď jsi bude škrtil. Takže kdykoli budete vidět žádné červené čáry, jako je tohle--, a není to jen Dynamo DB-- každá databáze NoSQL má tento problém. Tam jsou anti-vzory, které mohou řídit tyto typy podmínek. Co mám dělat, je, že jsem pracovat se zákazníky pro zmírnění těchto podmínek. 

A co to vypadá? A to už je co nejvíce z Dynamo DB propustnosti, ale je to opravdu dostat nejvíce z NoSQL. To se neomezuje pouze na Dynamo. To je definitely-- I pracoval v Mongo. Jsem obeznámen s mnoha NoSQL platformách. Každý, kdo má tyto typy horké klíčových problémů. Chcete-li získat co nejvíce z jakéhokoli NoSQL databáze, konkrétně Dynamo DB, Chcete-li vytvořit tabulky kde hash klíčovým prvkem má velké množství odlišných hodnot, vysoký stupeň mohutnost. Protože to znamená, že píšu na mnoha různých kbelíky. 

Čím více jsem kbelíky písemně, tím větší je pravděpodobnost Jsem šířit tuto zátěž zápisu nebo číst zatížení se přes více uzlů, tím je pravděpodobnější, jsem mít vysoký výkon na stole. A pak chci hodnoty, aby požádala docela rovnoměrně v průběhu času a jednotně náhodně jak je to možné. No, to je docela zajímavé, protože nemůžu Ovládání když uživatelé přijdou. Takže stačí říct, pokud budeme šířit věci se přes klíče prostoru, budeme pravděpodobně v lepší formě. 

Je tu určitá Množství okamžiku dodání že nejdeš Aby bylo možné kontrolu. Ale to jsou opravdu dva rozměry, které máme, prostor, přístup rovnoměrně šíření, čas, žádosti kteří přijíždějí rovnoměrně rozloženy v čase. A pokud ti dva jsou splněny podmínky, pak je to to, co to je vypadat. To je mnohem hezčí. Jsme tady opravdu šťastný. Máme velmi rovný přístup vzor. Jo, možná jste stále malý tlak tu a tam, ale nic opravdu příliš rozsáhlé. Takže je to úžasné, kolikrát, když jsem se pracovat se zákazníky, že jako první graf s velkým červeným bar a vše, co ošklivé žluté je to všude, jsme si udělal s výkonem po několika měsících zpětného architektury, Utíkají přesně stejné pracovní zátěž na přesně stejnou zátěží. A to je to, co vypadá to jako teď. Takže to, co dostanete s NoSQL je Data schématu, který je naprosto vázána na vzorek přístup. 

A můžete optimalizovat, že data schéma na podporu tohoto přístupu vzor. Pokud ne, pak budete vidět ty druhy problémů s těmito horkých kláves. 

Diváků: No, nevyhnutelně některá místa se bude teplejší než ostatní. 

RICK Houlihan: Vždy. Vždy. Jo, myslím, že je vždy je-- a znovu, je tu některé návrhové vzory se dostaneme přes který bude mluvit o tom, jak se vypořádat s těmito extra velkými agregace. Myslím, že musím mít je, jak jsme se s nimi vypořádat? Mám docela dobrý případ použití že budeme hovořit o za to. 

V pořádku, takže pojďme mluvit asi někteří nyní zákazníci. Tihle chlapi jsou AdRoll. Já nevím, jestli jste obeznámeni s AdRoll. Pravděpodobně jste vidět hodně na prohlížeči. Jsou ad re-targeting, jsou největší obchodní ad re-cílení tam venku. Obvykle pravidelně přejet 60 miliard transakcí za den. Dělají přes milion transakcí za sekundu. Mají tam docela jednoduchou tabulku struktura, nejrušnější tabulky. Je to v podstatě jen křížkem je cookie, rozsah je demografický kategorie, a poté Třetí atribut je skóre. 

Takže máme všichni cookies náš prohlížeč od těchto kluků. A když jdete na účast obchodníka, Oni v podstatě skóre vás napříč různé demografické kategorie. Když jdete na webové stránky a Říkáte, že chcete vidět tuto ad-- nebo v podstatě nemusíte říkat that-- ale když jdete na webových stránkách říkají, že chcete vidět tuto reklamu. A oni jdou dostat, že reklama AdRoll. AdRoll vás podívá se na jejich stolu. Zjistí, že je váš cookie. Inzerenti vyprávění jim, chci někoho kdo je ve středním věku, 40-letý muž, do sportu. A oni skóre vás v těch demografii a oni se rozhodnou, zda že je to dobrý reklama pro vás. 

Nyní mají SLA s jejich poskytovatelů reklamní poskytovat sub-10 milisekund Odezva na jednotlivých vyžádání. Takže oni používáte Dynamo DB pro toto. Oni nás bít milion požadavků za sekundu. Jsou schopni dělat všechny své číselníků, třídění všechno údaje, a dostat, že doplněk odkaz zpět na který inzerenta za méně než 10 milisekund. Je to opravdu docela fenomenální implementace, která mají. 

Tihle kluci actually-- jsou ti chlapi. Nejsem si jistý, jestli je to ty chlapy. Může být tyto lidi. V podstatě řekl us-- ne, já si nemyslím, že to byli oni. Myslím, že to byl někdo jiný. Pracoval jsem s zákazník, který mi řekl, že teď, když jsem šel do Dynamo DB, jsou utrácet více peněz na občerstvení pro jejich vývojový tým každý měsíc než utratí za své databáze. Tak to ti dám Myšlenka úspor nákladů že se můžete dostat do Dynamo DB je obrovský. Dobře, dropcam je jiná společnost. Tyto chlap druh of-- pokud si myslíte, internetového věcí, dropcam je v podstatě Internet Security videa. Dáte svůj fotoaparát venku. Kamera má detektor pohybu. Někdo přijde, spouští startovací bod. Fotoaparát začne nahrávat na chvíli až do nezjistí žádný pohyb ještě. Klade, že videa se na internet. 

Dropcam byla společnost, která je v podstatě přešel na Dynamo DB protože oni prožívali obrovské rostoucí bolesti. A to, co nám řekli, Najednou petabajtů dat. Netušili, své služby by byl tak úspěšný. Více než YouTube video příchozí je to, co tito lidé dostávají. Oni používají DynamoDB sledovat všechny metadata na všech svých videa klíčových bodech. 

Takže oni mají S3 kbelíky, které posouvají Všechny binární artefakty do. A pak, že mají Dynamo DB záznamy, které poukazují na ty lidi, S3, tři objekty. Když se třeba podívat se na video, oni vyhledat záznam v Dynamo DB. Oni klikněte na odkaz. Oni strhnout na video z S3. Takže to je to trochu, jak to vypadá. A to je přímo z jejich týmu. 

Dynamo DB snižuje jejich dodací lhůta pro video události od pěti do 10 sekund. Ve svém starém relační obchodě, oni používali muset jít a vykonat více složité dotazy k obrázku out, která videa strhnout, do méně než 50 milisekund. Takže je to úžasné, úžasné, jak moc výkon můžete získat, když optimalizovat a ladíte podkladové databáze podporovat přístup vzor. Halfbrick, tihle kluci, co to je, Fruit Ninja Myslím, že je jejich věc. Že všechny běží na Dynamo DB. A tito lidé, oni jsou skvělý Vývojový tým, velký rozvoj nakupovat. 

To není dobrý ops tým. Neměli mnoho provozních prostředků. Oni byli snaží se snaží udržet jejich aplikační infrastruktury up a běží. Přišli k nám. Dívali se na tomto Dynamo DB. Říkali, že je to pro nás. Oni stavěli jejich celek aplikační framework na to. Některé opravdu pěkné komentáře zde z týmu na jejich schopnosti se nyní zaměřují na budování hra a ne nutnosti udržení infrastruktura, která stal se obrovské množství režie pro jejich tým. Takže to je něco, co that-- užitek, že dostanete od Dynamo DB. 

Dobře, jak se dostat do modelování dat zde. A mluvili jsme trochu o to jedna ku jedné, kdo mnoho, a mnoho mnoho vztahů typu. A jak si udržet ty v Dynamu. V Dynamo DB používáme indexy, obecně řečeno, k otáčení data z jednu příchuť do druhé. Hash klíče, rozsah klíče a indexy. 

V tomto konkrétním Například, jak je většině států mají požadavek licenci, která pouze jeden řidičský průkaz na osobu. Nemůžete jít do dostat řidiče dvou je licencí ve státě Bostonu. Nemohu to udělat v Texasu. Je to něco, jak to je. A tak na DMV, máme vyhledávání, my Chcete se podívat na řidiče licenci počtem sociálního zabezpečení. Chci se podívat do podrobnosti uživatele licenční číslo řidiče. 

Takže bychom mohli mít tabulku uživatele, že Má hash klíč na sériové číslo, nebo číslo sociálního zabezpečení, a různé atributy definovány na položku. Nyní na této tabulce I by mohlo definovat, který GSI vyletí, že kolem toho říká, že chci, hash klíč na licenci a pak všechny ostatní položky. A teď, když chci, aby dotaz a najít licenční číslo pro danou sociální Bezpečnostní číslo, mohu dotaz na hlavní tabulky. 

Pokud chci, aby dotaz a já chci dostat sociálního zabezpečení číslo nebo jiné atributy tavnou licenční číslo, mohu dotaz GSI. Tento model je, že jeden do jednoho vztahu. Jen velmi jednoduchý GSI, otočit ty věci kolem sebe. Nyní, mluvit o tom, kdo mnoho. Jedním z mnoha je v zásadě Váš hash rozsah klíč. Tam, kde jsme si hodně s tímto use case jsou data monitoru. Data Monitor je dodáván v pravidelné interval, jako je internet věcí. Vždycky jsme si všechny tyto Záznamy přichází po celou dobu. 

A já chci najít všechny údaje mezi konkrétní časové období. Je to velmi časté dotazu monitoring infrastruktury. Způsob, jakým jít o to je najít jednoduchá struktura tabulky, jedna tabulka. Mám tabulku měr zařízení s křížkem na ID zařízení. A mám rozsah klíč na straně timestamp, nebo v tomto případě, epos. A to mi umožňuje provádět složité dotazy vůči které sahají klíče a vrátit ty záznamy, které jsou vztaženy k výsledku nastavit, že jsem hledal. A to, že jeden buduje mnoha vztah do primární tabulky pomocí křížkem, rozsah klíčová struktura. 

Takže to trochu postavený do tabulky v Dynamo DB. Když jsem se definovat hash a rozsah t stůl, já jsem definování jednoho k mnoha vztah. Je to vztah rodič-dítě. 

Pojďme se bavit o mnoho mnoha vztahů. A pro tento konkrétní příklad, znovu, budeme používat GSI je. A pojďme mluvit o hraní scénář, kde mám daného uživatele. Chci zjistit všechny hry, které on je zapsána pro nebo hraní v. A pro danou hru, já Chcete najít všechny uživatele. Tak jak to mám udělat? Můj uživatelský hry stůl, jdu mít hash klíč ID uživatele a rozsah klíč hry. 

Uživatel tedy může mít více her. Je to, kdo mnoha vztah mezi Uživatel a hry hraje. A pak na GSI, Budu překlopit, že kolem. Budu hash na hru a Budu se pohybují na uživatele. Takže pokud chci, aby si všechny Hra uživatele hraje v, Budu dotaz hlavní tabulky. Pokud chci, aby si všechny uživatele které hrají určitou hru, Já dotaz GSI. Tak vidíte, jak to uděláme? Stavíte na podporu těchto GSI je případ použití, aplikace, přístup vzor, ​​žádost. 

Pokud je potřeba, aby na dotaz tato dimenze, nechť me vytvořit index na této dimenzi. Pokud nemám, je mi to jedno. A v závislosti na use case, já může potřebovat indexu, nebo já taky ne. Pokud je to jednoduchý pro mnohé, primární tabulky je v pořádku. Pokud je potřeba, aby se tyto mnoho Mnoho je, nebo musím udělat jeden až ty, pak možná Já potřebuji na druhé místo index. Takže to vše závisí na tom, co se snažím dělat a to, co se snažím dostat dokonalý. 

Asi nebudu trávit moc mnoho času mluví o dokumentech. To dostane trochu, pravděpodobně, hlouběji, než musíme jít do. Mluvme trochu o bohatý výraz dotazu. Takže Dynamo DB máme schopnost vytvořit to, čemu říkáme projekce výrazy. Projekční výrazy jsou jednoduše vybírání pole nebo hodnot které chcete zobrazit. OK, tak jsem udělat výběr. Dělám dotazu proti Dynamo DB. A já říkám, víš co, show jen mi pět hvězd recenze pro tento konkrétní výrobek. Tak to je vše, co chci vidět. Nechci vidět všechny další atributy řádku, Jen chci vidět. Je to jako v SQL, když jste říkají, vyberte hvězdy nebo z tabulky, dostanete vše. Když říkám, vyberte jméno ze stůl, jen jsem si jeden atribut. Je to stejný druh věci v Dynamo DB nebo jiný databází NoSQL. Filtr výrazy mi dovolte, abych se v podstatě snížit sadu výsledků dolů. Tak jsem se, aby se dotaz. Dotaz může vrátit s 500 položkami. Ale já jsem jen chtějí, aby položky, které mají atribut, který říká, že tento. OK, takže pojďme odfiltrovat ty položky, které se neshodují, že konkrétní dotaz. Takže máme výrazy filtru. 

Filtr výrazy mohou lze spustit na každém atributu. Jsou to nebude líbit rozsah dotazy. Vyvolávají otázky jsou více selektivní. Filtr dotazy vyžadují, abych šel Získejte Kompletní výsledky nastavit a poté vybojovat data nechci. Proč je to důležité? Vzhledem k tomu, Četl jsem to všechno. V dotazu, budu číst a že to bude obrovský o datech. A pak budu vybojovat co potřebuji. A když já jsem jen vybojovat pár řádků, pak je to v pořádku. Není to tak neefektivní. 

Ale když jsem četl celou hromadu Údaje, jen aby vybojovat jednu položku, Pak jsem se chystám být lepší vypnout pomocí dotazu rozsah, protože je to mnohem vybíravější. Bude to mi ušetřit spoustu peníze, protože jsem za to zaplatit čtení. V případě, že výsledky, které přichází zpět kříž, že drát může být nižší, ale já jsem platit za čtení. Tak pochopit, jak jste dostat data. To je velmi důležité v Dynamo DB. 

Podmíněné výrazy, to je to, co by se dalo nazvat optimistické zamykání. Aktualizaci, pokud existuje, nebo pokud je tato hodnota je ekvivalentní tomu, co jsem specifikovat. A když mám časové razítko na rekord, mohl bych číst data. I se může změnit, že data. Mohl bych jít psát, že data zpět do databáze. Pokud někdo změnil záznam, časové razítko mohly změnit. A takhle můj podmíněné Aktualizace by se říci aktualizace v případě, že se rovná této časové razítko. Nebo aktualizace nezdaří, protože někdo aktualizováno záznam v mezidobí. 

To je to, co nazýváme optimistické zamykání. To znamená, že někdo může přijít a změnit to, a budu detekovat když jsem se vrátit do psát. A pak jsem si skutečně četl, že dat a říkají, ach, on změnil to. Potřebuji účet za to. A mohu změnit údaje v mém nahrát a aplikovat další aktualizaci. Takže si můžete chytit ty přírůstkové Aktualizace, které se vyskytují v době mezi že budete číst data a Čas můžete zapsat data. 

Diváků: A filtr Výraz vlastně znamená ne v počtu nebo ne-- 

[Vložením hlasy] RICK Houlihan: Nebudu příliš mnoho na to. To je rezervované klíčové slovo. Pohled libra je vyhrazeno klíčové slovo v Dynamo DB. Každá databáze má své vlastní vyhrazené Jména pro vymáhání pohledávek nelze použít. Dynamo DB, pokud zadáte libru před touto, můžete definovat tyto názvy nahoře. Toto je odkazováno hodnota. Je to asi není nejlepší syntaxi mají tam pro tuto diskusi, proto, že se dostane do některých real-- Byl bych mluvil více o, že na hlubší úrovni. 

Ale stačí říct, mohlo by to být dotaz skenovat, kde views-- ani názory libra je větší než 10. Je to číselná hodnota, ano. Chcete-li, můžeme hovořit o že po diskusi. Dobře, takže se dostáváme do některé scénáře v osvědčených postupech kam jdeme mluvit o některých aplikací zde. Jaké jsou případy použití pro Dynamo DB. Jaké jsou konstrukce vzory v Dynamo DB. 

A první, kdo budeme mluvit o je internet věcí. Tak jsme si hodně of-- myslím, co je to-- více než 50% provozu na internetu v těchto dnech je skutečně vyrobené pomocí strojů, automatizované procesy, které nejsou lidmi. Mám na mysli tuto věc tuto věc, která se budete nosit v kapse, kolik dat, která je ta věc vlastně posílá kolem bez tebe s vědomím, že je naprosto úžasné. Vaše poloha, informace o tom, jak rychle se budete. Jak myslíš, že Google Maps díla když ti, co je provoz. Je to proto, že tam jsou miliony a miliony lidí jezdí po s telefony, které jsou odesílání Údaje celé místo po celou dobu. Takže jedna z věcí o údaje tohoto druhu že přijde, údaje přístroje, přihlaste údaje, časové řady, je, že je obvykle jen zajímavý na trochu času. Po uplynutí této doby, to je není tak zajímavé. Tak jsme mluvili o, nenechte tyto tabulky růst bez hranic. Myšlenka je, že možná mám 24 hodiny v hodnotě událostí v mé horké tabulce. A to horký tabulka bude opravná položka ve velmi vysoké rychlosti, protože to trvá hodně dat. Trvá to velké množství dat a já jsem to četl hodně. Mám spoustu provozu Dotazy spuštěné vůči této dat. 

Po 24 hodinách, hej, ty Víš co, je mi to jedno. Takže možná každý I role půlnoci můj stůl se k nové tabulky a já deprovision tuto tabulku. A já si vezmu RCU je a WCU je dolů, protože o 24 hodin později Nejsem běží tolik dotazy vůči těmto údajům. Takže budu spořit. A možná 30 dní později, vůbec se mi nelíbí ani potřeba se starat o to všechno. Mohl bych vzít WCU je celou cestu dolů na jeden, proto, že víte, co je to nikdy dostat zapisovat. Data jsou 30 dní stará. To se nikdy nezmění. 

A to téměř nikdy dostane číst, tak ať to prostě přijmout, že RCU až 10. A Šetřím tuny peněz na to Data, a to pouze platit za mé horké dat. Tak to je důležité se podívat u, když se podíváte na časové řady Data přicházet v objemu. Jsou to strategie. Teď jsem mohl jen nechat to všichni do jednoho stolu a nechat že tabulka růst. Nakonec budu viz problémy s výkonem. Budu muset začít do archivu některé z těchto dat mimo stůl, co ne. 

Pojďme mnohem lépe navrhněte aplikaci takže můžete ovládat tímto způsobem pravdu. Takže je to jen automatické v kódu aplikace. O půlnoci každý večer to valí tabulku. Možná, že to, co potřebujete, je posuvná Okno 24 hodin dat. Pak se pravidelně, že jsem volat data z tabulky. Jsem ořezávání to s Cronu a já jsem ho uvedení na těchto jiných tabulek, co budete potřebovat. Takže pokud převrácení funguje, to je skvělé. Pokud ne, trim to. Ale pojďme si tu horký údaje od svých chladných dat. To vám ušetří spoustu peněz a Udělej si svůj tabulek více vede. Takže další věc, kterou budeme mluvit o tom, je katalog výrobků. Katalog je docela obyčejný případ použití. To je vlastně velmi časté vzor že uvidíme v řadě věcí. Víte, pro Twitter Příkladem, horký tweet. Každý, kdo přijde a popadl ten tweet. Katalog, mám prodeje. Dostal jsem horký prodeje. Mám 70.000 žádostí za druhý příchod pro výrobek popis z mého katalogu výrobků. Vidíme to na maloobchodním Provoz docela dost. Tak jak jsme se s tím vypořádat? Neexistuje žádný způsob, jak se s tím vypořádat. Všichni moji uživatelé chtějí vidět stejný údaj. Oni přicházejí, souběžně. A oni jsou všichni dělat žádosti za stejný kus dat. To mi dává, že horké klávesy, že velké červené pruh na mém grafu, které se nám nelíbí. A to je to, co to vypadá. Takže přes můj klíčový prostor Dostávám kladivem v prodeji položky. Začínám nic nikde jinde. 

Jak mám tento problém zmírnit? No, my zmírnit to s cache. Cache, dáte v podstatě v paměti partition v přední části databáze. Podařilo se [Neslyšitelný] cache, jak vás Můžete nastavit vlastní cache, [neslyšitelných] mezipaměť [? d,?], co chcete. Dát, že se před databáze. A to způsob, jak můžete ukládat, že data z těchto horkých kláves až v této paměti cache prostor a přečtěte si cache. 

A pak s největší vašich čte začít hledat takhle. Dostal jsem všechny tyto keše sem a já nemám nic v cestě sem protože databáze je usednutí za mezipaměti a čte se nikdy projít. Když změním údaje do systému databáze, musím aktualizovat mezipaměť. Můžeme použít něco jako par to udělat. A já vám vysvětlím, jak to funguje. Dobře, zasílání zpráv. E-mail, my všichni používat e-mail. 

To je docela dobrý příklad. Máme nějaký zpráv tabulky. A my jsme dostali složky Doručená pošta a Pošta k odeslání. To je to, co by SQL vypadat jako na stavět, že e-mailové schránky. Jsme trochu používají stejný druh strategie použít GSI, GSI je pro mé e-mailové schránky a můj Pošta k odeslání. Tak jsem se dostal syrové zprávy přicházející do mé zprávy tabulky. A první přístup k této by mohlo být, řekněme, v pořádku, žádný problém. Mám syrové zprávy. Zprávy přicházející [neslyšitelných], ID zprávy, to je skvělé. To je můj unikátní hash. Chystám se vytvořit dvěma GSI je, jeden pro mé e-mailové schránky, jeden pro mou Pošta k odeslání. A první věc, kterou udělám je Řeknu můj hash klíč Bude příjemce a Jdu zařídit dnem. To je fantastické. Já tady mám pěkný výhled. Ale je to trochu problém zde. A se dostanete do toho relační databáze stejně. Říkali vertikálně dělení. Chcete, aby se vaše zpracování velkých objemů dat od svých malých dat. 

A důvod, proč je, protože musím go číst položky, které chcete získat atributy. A pokud moje těla jsou všichni tady, pak čte jen několik položek když moje tělo je délka v průměru 256 kilobajtů každý, matematický dostane docela ošklivý. Takže říct, že chcete přečíst Davidův e-mailové schránky. Davidova Doručená pošta má 50 položek. Průměrná a velikost je 256 kB. Tady je můj konverzní poměr pro RCU je je čtyři kilobajtů. 

OK, pojďme se nakonec konzistentní čte. Jsem stále jíst 1600 RCU je jen ke čtení Davidův e-mailové schránky. Ouch. OK, teď pojďme přemýšlet o tom, jak aplikace funguje. Pokud jsem v e-mailové aplikaci a Dívám se na mé e-mailové schránky, a já se na tělo každé zprávy, Ne, já jsem při pohledu na shrnutí. Dívám se na pouze hlavičky. Takže pojďme postavit strukturu tabulky že vypadá takhle. 

Tak tady je informace že moje workflow potřebuje. Je to v mé e-mailové schránky GSI. Je to datum, odesílatel, předmět, a poté ID zprávy, které body zpět ke stolu zpráv kde bych mohl dostat tělo. No, to by bylo rekordní ID. Oni by ukazovat zpět do položka ID na stole Dynamo DB. Každý index vždy creates-- má vždy položku ID jako součást of-- že přichází s indexem. 

Dobře. Diváků: Je to o tom, kde je uložen? RICK Houlihan: Ano, je to říká exactly--, že je to přesně to, co dělá. To říká, že tady je moje re rekord. A to bude ukazovat ji zpátky do svého opětovného záznamu. Přesně. OK, tak teď moje schránka ve skutečnosti mnohem menší. A to vlastně podporuje pracovního postupu z e-mailové aplikace. Takže mé e-mailové schránky, jsem klepněte na tlačítko. Jdu dál a já klikněte na zprávu, to je, když musím jít pro tělo, protože budu přejít do jiného pohledu. Takže pokud si myslíte, že o typu MVC města rámec, pohled modelu regulátoru. 

Tento model obsahuje údaje, které potřebuje pohled a regulátor interaguje s. Když jsem se změnit rám, kdy I změnit perspektivu, to je v pořádku se vrátit do Server a repopulate modelu, protože to je to, co uživatel očekává. Když se změní zobrazení, to je, když můžeme jít zpět do databáze. Tak e-mail, klepněte na tlačítko. Hledám pro tělo. Okružní výlet. Jdi tělo. 

Četl jsem hodně méně dat. Já jsem jen čtení orgánů, které David potřebuje, když je potřebuje. A já nejsem hořet v roce 1600 RCU prostě ukázat své e-mailové schránky. Takže teď that-- je to způsob, že LSI nebo GSI-- Je mi to líto, GSI, bude fungovat. Máme naši hash na příjemce. Máme rozsah klíč na datu. A máme plánované atributy že musíme jen podporují názor. 

Otočíme, že pro odchozích zpráv. Hash odesílatele. A v podstatě, máme velmi pěkný, čistý výhled. A je to basically-- jsme už tuhle příjemnou zprávy tabulka, která se šíří hezky, protože je to jen hash, hash ID zprávy. A máme dva indexy, které se otáčejí z této tabulky. Dobře, takže myšlenka tady je ne uchovávat velké data a tento malý údaje spolu. Rozdělit svisle, rozdělit ty tabulky. Nečtěte data, nemusíte. Dobře, herní. Všichni jsme rádi hry. Alespoň se mi líbí hry poté. Takže některé z věcí, že se zabýváme, když přemýšlíme o hraní, ne? Herní těchto dnech, a to zejména mobilní hraní her, je o myšlení. A budu otáčet tady trochu daleko od DynamoDB. Jdu, aby v některé z diskuse kolem některých z jiné technologie AWS. 

Ale myšlenka o hraní je myslet o co se týče API, API, které jsou, Obecně řečeno, HTTP a JSON. Je to, jak mobilní hry druh komunikovat s jejich zadními konci. Oni dělají JSON vysílání. Dostanou dat, a to je všechno, Obecně řečeno, v pěkném JSON API. 

Věci jako získat přátele, získat leaderboard, vyměňovat data, uživateli generovaný obsah, tlačit zpět do systému, se jedná o typy věcí že budeme dělat. Binární data aktiv, tato data nemusí sedět v databázi. To by mohlo sedět ve objekt obchod, ne? Ale databáze bude skončit říká systému, říká aplikace kam jít si to. A nevyhnutelně, multiplayer servery, back end infrastruktury, a určené pro vysoce dostupnost a škálovatelnost. To jsou věci, které chceme všichni v herním infrastruktury dnes. 

Takže pojďme se podívat na jak to vypadá. Mám základní zadní konec, velmi jednoduché. Máme systém, zde se vícenásobné dostupnost zón. Mluvili jsme o AZS as being-- myslíte z nich jako samostatné datových center. Více než jedna datová centra per AZ, ale to je v pořádku, jen myslet na nich jako samostatný dat střediska, která jsou geograficky a porucha izolované. 

Budeme mít instance pár EC2. Budeme mít někteří back end serveru. Možná, pokud jste starší architektura, my jsme s použitím co nazýváme RDS, relační databáze služby. Mohl by to být MSSQL, MySQL, nebo něco takového. To je způsob, jak hodně aplikací jsou navrženy tak dnes. 

Tak bychom mohli chtít jít s to je, když jsme škálování. Budeme pokračovat a dát vědro S3 tam nahoře. A to S3 lopaty, namísto porce up těchto objektů z naší servers-- jsme mohli udělat. Dáte všechny vaše binární objekty na vašich serverech a můžete použít ty serveru instance sloužit, že data nahoru. Ale to je dost drahé. 

Lepší způsob, jak udělat, je jít dopředu a dát tyto objekty v S3 kbelíku. S3 je objekt úložiště. Je postaven speciálně pro servírují tyto typy věcí. A ať tito klienti vyžádat přímo z těchto objektů věder, složit servery. Takže začínáme měřítko tady. 

Teď jsme se dostali uživatelů po celém světě. Mám uživatelů. Musím mít obsah lokálně se nachází v blízkosti těchto uživatelů, ne? Vytvořil jsem S3 kbelík jako můj zdrojový úložiště. A já budu vpředu, že s distribuce CloudFront. 

CloudFront je CD a content delivery network. V podstatě to znamená data, která jste určili a ukládá to všechno přes internet takže uživatelé mohou mít všude velmi rychlá odezva při žádají o tyto objekty. 

Tak dostanete nápad. Jste typ pákového efektu všechny aspekty AWS sem si to udělat. A nakonec, vyhodíme ve skupině auto škálování. Takže naše případy AC2 našich herních serverů, jak začnou dostat rušnější a nabitější a rušnější, oni si jen točit další instance, točit další instanci, točit další instanci. Takže technologie AWS má, ho umožňuje zadat parametry kolem které vaše servery budou růst. Takže můžete mít n počet serverů tam u nějakého daného času. A pokud váš náklad zmizí, oni budou zmenšovat, číslo se bude zmenšovat. A v případě, že zatížení vrátí, to bude pěstovat zpět, pružně. 

Tak to vypadá skvěle. Máme spoustu instancí EC2. Můžeme dát cache front z databází, pokusit se urychlit databází. Příští tlakový bod typicky lidé vidí je, že měřítko hru pomocí relační databázový systém. Ježíši, databáze výkon je hrozné. Jak se můžeme zlepšit, že? Zkusme uvedení vyrovnávací paměti před, že. 

No, mezipaměti nefunguje tak skvělé hry, ne? U her, psaní je bolestivé. Hry jsou velmi těžké psát. Cache nefunguje, když jste napsat těžké, protože jste vždy dostal k aktualizaci mezipaměti. Aktualizovat vyrovnávací paměti, je to irelevantní, které mají být mezipaměti. Je to vlastně jen práce navíc. 

Takže, kde jsme jít sem? Máš velkou zúžení tam dole v databázi. A místo, kam jít samozřejmě je rozdělení. Rozdělení disku není snadné dělat, když jste jednání s relační databáze. U relačních databází, že jste Zodpovídají za řízení, efektivně, klíč prostor. Říkáte, že uživatelů mezi A a M jít sem, mezi N a Z jít tam. A vy spínání po aplikaci. Takže máte co do činění s tento oddíl zdroj dat. Máte transakční omezení které nemají span oddíly. Máte všechny druhy nepořádek, že jste zabývající se tam snaží vypořádat se s škálování out a budování větší infrastruktury. Je to jen žádná legrace. 

Diváků: Takže říkáte, že rostoucím zdrojem body urychluje proces? RICK Houlihan: Zvýšení? Diváků: Zdroj bodů. RICK Houlihan: Zdroj body? Diváků: Z informací, kde se informace přichází? RICK Houlihan: Ne. To, co říkám, je zvyšování počet oddílů v úložišti dat zvyšuje výkon. Takže to, co se tady děje, je uživatelé přicházející do instance EC2 tady, dobře, když potřebuji uživatele To je na M, půjdu sem. Od N k p, půjdu sem. Od P do Z, půjdu sem. 

Publikum: OK, ty, tak to jsou všechny uložené v různých uzlech? 

RICK Houlihan: Ano. Myslete na to, jak různé sila dat. Takže máte na to udělat. Pokud se snažíte udělat, to, pokud se snažíte měřítku na relační platformě, To je to, co děláte. Berete dat a jste řezání dolů. A vy oddílů to přes více instancí databáze. A vy řízení vše, co v aplikační vrstvě. Není to žádná legrace. Takže to, co chceme jít? Chceme jít DynamoDB, plně spravované, NoSQL úložiště dat, poskytování propustnost. Využíváme sekundární indexy. Je to v podstatě HTTP API a zahrnuje podporu dokumentu. Takže nemusíte mít strach přibližně kterákoli hodnota z tohoto dělení. Děláme to vše za vás. Takže teď, místo toho, budete stačí napsat do tabulky. Pokud je třeba tabulku být rozdělen, že se děje v zákulisí. Vy jste kompletně izolované z toho jako vývojář. Tak pojďme mluvit o některé z případů použití že narazíme na v hraní, obyčejný herní scénáře, žebříčku. Takže jste dostali uživatelé přichází, se BoardNames, že jsou na, skóre pro tohoto uživatele. Můžeme být hashování na UserID, a pak máme řadu na hru. Takže každý uživatel chce vidět všechno hra on hrál a všechny jeho nejvyšší skóre napříč všemi hře. Tak to je jeho osobní žebříčku. 

Teď chci jít a já chci, aby get-- tak jsem si tyto osobní žebříčků. To, co chci udělat, je jít dostat nejvyšší skóre napříč všemi uživateli. Tak jak to mám udělat? Když je můj rekord zatříděna na ID uživatele, se pohybovala na hru, dobře Chystám se pokračovat a restrukturalizovat, vytvořit GSI, a budu o restrukturalizaci, že data. 

Teď budu k transformaci na BoardName, což je hra. A budu pohybovat na nejvyšší skóre. A teď jsem vytvořil různé kbelíky. Já jsem za použití stejné tabulky, stejná data položky. Ale já jsem vytvořit kbelík, který dává me agregací nejvyšší skóre zvěří. 

A mohu dotaz, který tabulku tuto informaci získat. Tak jsem nastavit, aby dotazu vzor až do být podpořeno sekundární indexu. Nyní mohou být řazeny podle BoardName a řazeny podle TopScore, v závislosti na. Takže můžete vidět, jsou to typy z případů použití se dostanete do hry. Další dobrá use case jsme se dostat do hry je ocenění a kdo vyhrál ocenění. A je to skvělý případ použití kde říkáme řídké indexy. Řídké indexy jsou schopnost vytvářet index, který není nezbytně obsahovat každou položku na stole. A proč ne? Vzhledem k tomu, že to je atribut indexovaný neexistuje na každém kusu. 

Takže v tomto konkrétním případ použití, říkám, víte co, budu vytvořit atribut nazvaný Award. A já dám každému uživateli že má cenu, která atribut. Uživatelé, kteří nemají ocenění jsou nebude mít tento atribut. Takže když jsem se vytvořit index, pouze uživatelé že ukážeme up v indexu jsou ty, které skutečně získaly ocenění. Takže je to skvělý způsob, jak být schopni vytvořit filtrované indexy jsou velmi, velmi selektivní, že ne mají indexovat celou tabulku. 

Takže my jsme stále málo času. Chystám se jít dopředu a přeskočte out a přeskočit tento scénář. Promluvte si trochu about-- 

Diváků: Mohu se zeptat na rychlý dotaz? Jedním z nich je psát těžké? RICK Houlihan: Co je to? Diváků: Napište těžký. RICK Houlihan: Napište těžký. Podívám se. 

Diváků: Nebo je, že ne něco, co můžete jen hlas během několika vteřin? RICK Houlihan: Jdeme prostřednictvím hlasování scénáře. Není to tak špatné. Myslíte si, kluci mají pár minut? DOBŘE. 

Takže budeme hovořit o hlasování. Takže v reálném čase hlasování, máme požadavky pro hlasování. Požadavky jsou, že umožníme každá osoba, která má hlasovat pouze jednou. Chceme nikdo být schopni změnit svůj hlas. Chceme, aby v reálném čase agregace a analytika pro demografie že budeme mít ukazuje uživatelům na webu. 

Myslete na tento scénář. Pracujeme hodně reality TV ukazuje, kde jsou dělá tyto přesný typ věcí. Takže si můžete myslet na scénář, máme miliony a miliony tam of dospívající dívky s jejich mobilní telefony a hlasování a hlasování, a hlasovat pro toho, kdo jsou si, že je nejoblíbenější. Tak to jsou některé z Požadavky nám dojde. 

A tak se jako první přijmout při řešení tohoto problému by bylo vybudovat Velmi jednoduchá aplikace. Tak jsem dostal tuto aplikaci. Mám nějaké voliče venku. Přicházejí v, narazí na hlasovací aplikace. Mám nějaké syrové hlasů tabulku Já si jen výpis těchto hlasů do. Budu mít nějaké agregát hlasů tabulka, která bude dělat Analytics a demografie, a dáme to všechno tam. 

A to je skvělé. Život je krásný. Život je dobrý, dokud nezjistíme, že je tu vždy jen jedna nebo dvě lidé, kteří jsou populární ve volbách. Je tu jen jedna nebo dvě věci že lidé opravdu záleží. A pokud jste na hlasování měřítko, najednou jsem si bude zatloukat sakra z dva kandidáti, jeden nebo dva zájemci. Velmi omezený počet kusů lidé najdou být populární. 

To není dobrý design vzor. To je vlastně velmi špatné návrhový vzor protože vytváří přesně to, co jsme Mluvil o tom, které bylo kláves. Horké klávesy jsou něco, co se nám nelíbí. 

Tak jak to napravit? A opravdu, jak to opravit, je tím, že se ty kandidátské kbelíky a pro každého kandidáta máme, budeme připojit náhodnou hodnotu, něco, co víme, náhodné hodnota mezi jedním a 100, mezi 100 a 1000, nebo mezi jednou a 1000, nicméně mnoho náhodné hodnoty, které chcete připojit na konec tohoto kandidáta. 

A co jsem vlastně udělal potom? Pokud jsem pomocí číslo kandidáta jako bačkory agregovat hlasování, jestli jsem přidal náhodný Číslo na konec, který, Vytvořil jsem teď 10 kbelíky, je Sto tisíc kbelíky, kbelíky že jsem agregaci hlasů napříč. 

Takže mám miliony a miliony, a miliony záznamů přichází pro tyto kandidáty, jsem nyní šíří tyto hlasy napříč Candidate a_1 přes kandidáta A_100, protože pokaždé, když hlas přijde, Jsem generování náhodných Hodnota mezi jedním a 100. Jsem připínání ho na konci Kandidát, že osoba je hlasovat pro. Já dumping to do té kbelíku. 

Nyní na zadní straně, já vím, že jsem sto kbelíky. Takže když chci jít dopředu a agregovat hlasy, Četl jsem ze všech těch kbelíků. Tak jsem se do toho pusťte a přidat. A pak jsem si bodový shromáždit kde jsem jít ven a říct hej, víte co, klíč tohoto uchazeče prostory je více než sto lopaty. Chystám se shromáždit všechny hlasy od těch sto věder. Jdu k agregaci jim a budu říkat, Kandidáta má nyní Celkový počet hlasování o x. 

Nyní oba zápisu dotaz a dotaz čtení jsou pěkně distribuovány protože píšu napříč a já jsem četl přes stovky klíčů. Nejsem psaní a čtení přes jeden klíč nyní. Takže je to skvělý vzor. 

Toto je ve skutečnosti pravděpodobně jedním z nejdůležitějších designu vzory pro měřítko v NoSQL. Uvidíte tento typ návrhový vzor v každém chuť. MongoDB, DynamoDB, to není ohledu na to, my všichni musíme to udělat. Protože když máte co do činění s těch obrovských agregace, budete muset vymyslet způsob, jak na šíří ven přes kbelíky. Takže tohle je způsob, jak to udělat. Dobře, tak co děláte právě teď Je jste obchodování off čtení náklady na zápis škálovatelnost. Náklady na mé čtení je trochu složitější a já musím jít číst ze Sto kbelíky namísto jednoho. Ale jsem schopen napsat. A má propustnost, můj zápis propustnost je neuvěřitelné. Takže je to většinou cenný technika pro škálování DynamoDB, nebo jakékoliv databáze NoSQL na to přijde. Tak jsme se na to, jak jej škálovat. A jsme přišli, jak se eliminovat naše horkých kláves. A to je fantastické. A my jsme dostali tento pěkný systém. A to nám velmi správné hlasování protože máme záznam, hlasováno de-Dupe. Je postaven do DynamoDB. Mluvili jsme o podmíněných práv. 

Pokud volič přijde, dá vložku na stole, oni vložka s jejich voličské ID, pokud se pokusíte vložit jiný hlas, Já podmíněné zápis. Řekněme, že jen napsat to pokud tato neexistuje. Takže jakmile jsem vidět, že že hlasování hit stůl, nikdo jiný to bude schopen dát svůj hlas v. A to je fantastické. A my zvyšování Naši pulty kandidátských. A děláme dotazy demografie a tak. Ale co se stane, když je moje Aplikace padá přes? A teď najednou hlasů jsou přichází, a já Nevím, jestli jsou stále zpracovávány do mé analýzy a demografie už ne. A když aplikace přijde zpět, jak sakra vím, co máte hlasů byla zpracována a kde mám začít? 

Tak to je skutečný problém, když vás začít se dívat na tento typ scénáře. A jak to řešíme, že? Řešíme to s tím, co volejte DynamoDB proudů. Potoky je čas objednat a rozdělí změna protokol o každém přístupu ke stolu, každý napsat přístup ke stolu. Všechna data, která to napsáno na Tabulka se objeví na proudu. 

Je to v podstatě 24 hodin fronta. Položky zasáhl proud, žijí po dobu 24 hodin. Mohou být číst vícekrát. Garantovaná které mají být dodány pouze jednou do proudu, by bylo možné číst n počet opakování. Takže nicméně mnoho procesy, které chcete konzumovat, že data, můžete konzumovat. To se zobrazí při každém aktualizaci. Každý zápis bude jen se objeví jednou na potoku. Takže nemusíte mít strach asi dvojnásobek jejich zpracování ze stejného procesu. 

Je to přísně nařídil za položku. Když říkáme čas objednal a rozdělí, uvidíte za přepážkou na potoku. Uvidíte položky, aktualizace v pořádku. Nejsme zaručující streamu, že jste dostane každou transakci v pořadí přes položek. 

Takže proudy jsou idempotentních. Máme všichni víme, co idempotentních znamená? Idempotentních znamená, že můžete to udělat přes, a znovu, a znovu. Výsledek to bude stejná. 

Proudy jsou idempotentních, ale musí být hrál od výchozího bodu, tam, kde si vyberete, až do konce, nebo nebudou mít za následek ve stejných hodnotách. 

Totéž se MongoDB. MongoDB má konstrukt oni volají oplog. Je to přesně stejné konstrukce. Mnoho databází NoSQL mají tento konstrukt. Používají ji dělat věci jako replikace, který je přesně to, co děláme s proudy. Publikum: Možná kacířský otázka, ale vy mluvit o tom apps dolů po tak dále. Jsou proudy zaručeně Nikdy možná jít dolů? RICK Houlihan: Jo, potoky je zaručeno, že se nikdy jít dolů. Řídíme infrastrukturu za. proudy automaticky rozmístit své auto škálování skupiny. Projdeme trochu něco o tom, co se stane. 

Neměl bych říct, že to není zaručeno, že se nikdy jít dolů. Prvky jsou zaručeny se objeví v proudu. A proud bude přístupná. Takže to, co jde dolů nebo se vrátí zpět up, že se děje pod ním. Je covers--, že je to v pořádku. Dobře, takže máte jiný Typy zobrazení mimo obrazovku. Typy zobrazení, které jsou důležité pro programátor jsou obvykle, co to bylo? Mám starý názor. Pokud aktualizace dopadne na stůl, bude to vytlačte starý pohled do proudu takže data mohou archivovat, nebo změna kontrola, identifikace změn, změna řízení. 

Nový snímek, co to je nyní, po aktualizace, to je jiný druh pohledu můžeš dostat. Můžete získat staré i nové obrazy. Možná, že chci oba. Chci vidět, co to bylo. Chci vidět, co to se změnilo na. 

Mám typ shody procesu, který běží. Je třeba ověřit, zda pokud se změní tyto věci, že jsou v určitých mezích nebo v rámci určitých parametrů. 

A pak možná jsem jen Potřebuji vědět, co se změnilo. Nezajímá mě, co změně položky. Nepotřebuji, aby potřebujete vědět jaké atributy změnil. Jenom potřebuju vědět, že položky jsou dotkl. To jsou tedy způsoby zobrazování že se dostanete z proudu a můžete komunikovat s. 

Aplikace, která spotřebovává proud, to je tak trochu, jak to funguje. DynamoDB klient požádat, aby tlačit dat do tabulek. Proudy nasadit na to, co říkáme střepy. Střepy jsou odstupňovány nezávisle na tabulky. Nemají zarovnány úplně se rozdělí váš stůl. A důvod, proč je protože line up kapacitě, aktuální Kapacita tabulky. 

Jejich nasazení v jejich vlastní auto škálování skupina, a začnou vymykat závislosti na tom, kolik zápisy přicházejí, kolik reads-- ve skutečnosti je to píše. Není reads-- ale jak Mnoho zápisy přicházejí. 

A pak na zádech konec, máme to, co máme volat KCI, nebo Kinesis klientskou knihovnu. Kinesis je proud dat technologie zpracování od Amazonu. A potoků je postavena na tom. 

Takže jste použít KCL povolen Aplikace pro čtení proudu. Kinesis Klient knihovna vlastně spravuje dělníky pro vás. A to také dělá některé zajímavé věci. To bude vytvářet nějaké tabulky up v DynamoDB tabulkovém sledovat, které položky byly zpracovány. Takže tímto způsobem, pokud to padá zpět, pokud spadne a přijde a dostane postavil zpět nahoru, to může zjistit, kde to bylo při zpracování proudu. 

To je velmi důležité, když mluvíte o replikaci. Musím vědět, co Data byla zpracována a jaké údaje musí být teprve zpracovány. Takže knihovna KCL pro proudů bude vám hodně této funkci. To se stará o veškerou domácnost. To se postaví pracovníka pro každý střep. To vytvoří administrativní tabulku za každý střep, pro každého pracovníka. A jak tito pracovníci oheň, udržují ty tabulky takže víte, tento záznam byla přečtena a zpracována. A pak, že způsob, jak v případě, že proces zemře a přejde do režimu online, to může pokračovat přesně tam, kde je to vzlétlo. 

Tak jsme se použít pro cross-region replikace. Mnoho zákazníků má potřebu přesunout data nebo části jejich datových tabulek kolem různých oblastech. Existuje devět regionů kolem celého světa. Tak by mohlo dojít k need-- I může mít uživatele v Asii, uživatelé ve východním pobřeží Spojených států. Mají různé údaje, které musí být na místě rozdělení. A možná, že uživatel létá od Asie přes do Spojených států, a chci, aby replikovat jeho data s ním. Takže když se dostane z letadla, má dobrá zkušenost pomocí svého mobilního aplikace. 

Můžete použít cross-region Knihovna replikace to udělat. V podstatě máme poskytla dvě technologie. Jeden je aplikace konzoly můžete postavit na své vlastní EC2 instance. To běží čisté replikace. A pak jsme vám dali do knihovny. Knihovna můžete použít k vybudování vlastní aplikace, pokud vás chtějí dělat šílené věci, s tím data-- filtr, kopírovat jen část z toho, otáčet dat, přesuňte jej na A jiné tabulky, a tak dále a tak dále. Takže to je to trochu jak to vypadá. 

DynamoDB Streams může být zpracovány co nazýváme Lambda. Zmínili jsme se trochu o události aplikačních architektury. Lambda je klíčovým prvkem, který. Lambda je kód, který vystřelí na požádání v reakci na konkrétní události. Jedním z těchto případů by mohl být záznam se objeví na potoku. Pokud se na potoce se objeví záznam, zavoláme tuto funkci Java. No, to je JavaScript, a Lambda podporuje Node.js, Java, Python, a brzy podpoří další jazyky stejně. A stačí říct, že je to čistý kód. napsat V Javě, definujete třídu. Můžete tlačit JAR nahoru do lambda. A pak se určit, která třída volat v reakci na kterém událost. A pak infrastruktura Lambda za tím poběží ten kód. 

Tento kód dokáže zpracovat Záznamy mimo potoku. To může dělat cokoliv, chce s ním. V tomto konkrétním příkladu, všichni jsme opravdu dělají, je protokolování atributy. Ale to je jen kód. Kód může dělat cokoliv, že jo? 

Takže můžete otáčet, že data. Můžete vytvářet odvozená pohled. Pokud je to struktura dokumentů, můžete vyrovnat strukturu. Můžete si vytvořit alternativní indexy. Všechny druhy věcí, které můžete činění s DynamoDB proudy. 

A opravdu, to je to, co to vypadá. Takže jste si tyto aktualizace přicházet. Jdou mimo řetězec. Jsou číst pomocí funkce Lambda. Jsou otáčení údaje a tlačí to v tabulkách finančních derivátů, oznamování externích systémů změny, a tlačí data do ElastiCache. 

Mluvili jsme o tom, jak dát cache v přední části databáze pro tento prodeje scénář. No, co se stane, když jsem aktualizuje popis položky? No, kdybych měl Lambda Funkce běží na této tabulce, když jsem aktualizovat popis položky, bude to vyzvednout záznam z potoka, a to bude aktualizovat ElastiCache instance s novými daty. Tak to je hodně Co děláme s Lambda. Je to lepidlo kód, konektory. A to vlastně dává schopnost zahájit a provozovat velmi složitých aplikací bez dedikovaný server infrastruktura, která je opravdu cool. 

Takže pojďme zpět k našim real-time hlasování architektury. To je nová a lepší s našimi potoků a KCL povoleno žádost. Stejně jako předtím, můžeme zvládnout jakoukoliv měřítko voleb. My takhle. Děláme z bodový shromažďuje přes více kbelíků. Máme optimističtější zamykání děje. Můžeme udržet naše voliče měnit jejich hlasy. Mohou hlasovat pouze jednou. To je fantastické. Real-time odolnost proti chybám, Nyní škálovatelné agregace. V případě, že věc spadne, ji ví, kde o restartování samotného když se vrátí, protože jsme pomocí aplikace KCL. A pak můžeme použít také, že KCL aplikace, aby se zasadila dat ven k redshift pro jiné analytika app, nebo použití Elastické MapReduce spustit real-time streaming agregací off těchto údajů. 

To jsou věci, které bychom Nemluvil o moc. Ale jsou další technologie, které přicházejí nést, když hledáte na těchto typech scénářů. 

Dobře, takže to je asi analytics s DynamoDB proudů. Můžete vybírat de-Dupe Údaje, dělat všechny druhy pěkná věcí, souhrnné údaje v paměť, vytvoření těchto tabulkách finančních derivátů. To je obrovský případ použití že spousta zákazníků se zabývají, přičemž vnořená Vlastnosti těchto dokumentů JSON a vytvoření dalších indexů. 

Jsme na konci. Děkujeme vám za ložiska se mnou. Tak pojďme mluvit o referenční architektura. DynamoDB sedí ve středu tak, velkou část infrastruktury AWS. V podstatě můžete připojit jej až na cokoli chcete. Aplikací pomocí Dynamo zahrnují Lambda, ElastiCache, CloudSearch, tlačit data ven do Elastic MapReduce, export import z DynamoDB do S3, všechny druhy pracovních postupů. Ale pravděpodobně nejlepší věc mluvit, a to je to, co je opravdu Zajímavé je, když jsme mluvit o události řízené aplikace. 

Toto je příklad interní projekt že máme kde jsme vlastně publikování shromažďovat výsledky průzkumu. Takže v e-mailu odkaz, který vyšleme, tam bude být trochu odkaz rčení click zde v reakci na zjišťování. A když se člověk kliknutí odkazující, co se stane, je, že se strhnout bezpečné Formulář průzkumu HTML z S3. Neexistuje žádný server. To je jen objekt S3. 

Tato forma přijde, načte do prohlížeče. Má to páteř. Má to složitý JavaScript že je to běh. Takže je to velmi bohatá aplikace běží v prohlížeči klienta. Oni nevědí, že oni nejsou interakci s back end. V tomto bodě, je to všechno prohlížeč. 

Oni zveřejňovat výsledky na to, co nazýváme Amazon API Gateway. API Gateway je prostě web API že můžete definovat a připojit na co chcete. V tomto konkrétním případě, my jsme zahnutý do funkce Lambda. 

Takže moje POST operace děje žádný server. V podstatě, že API brány sedí tam. To mi nic nestojí, dokud lidí start vysílání na to, že jo? Funkce Lambda tam prostě sedí. A mě to nic nestojí, dokud lidé začnou bít ji. Takže můžete vidět, jak objem se zvyšuje, to je, když se obvinění přijít. Nejsem spuštěn server 7/24. 

Tak jsem vytáhnout formulář dolů z nádoby, a já jsem psát prostřednictvím rozhraní API Brána do funkce Lambda. A pak Lambda funkce říká, víte, to, co jsem dostal nějaké PIIS, někteří osobní údaje V těchto odpovědí. Dostal jsem komentáře přicházející z uživatelů. Mám e-mailové adresy. Mám uživatelská jména. 

Dovolte mi, abych rozdělil to pryč. Budu vytvářet nějaké metadata z tohoto záznamu. A budu tlačit metadata do DynamoDB. A mohl bych šifrovat všechny údaje a zatlačte ji do DynamoDB když budu chtít. Ale je to pro mě jednodušší, v tomto případ použití, pokračovat o slovo, Budu tlačit raw dat do šifrované S3 lopaty. Tak jsem použít postaven v S3 straně serveru šifrování a správy klíčů Amazon Služba tak, že mám klíč, který se může otáčet v pravidelných intervalech, a já mohu ochránit, že PII dat jako součást celého tohoto pracovního postupu. 

Tak co jsem to udělal? Právě jsem nasazen celek aplikace, a já nemám server. Tak je to, co událost řízený aplikaci architektura udělá za vás. 

Nyní, pokud si myslíte, že o v případě použití pro tohle-- Máme jiné zákazníky, já mluvím se o tomto přesném architektuře, kteří spustit neobyčejně velké kampaně, kteří jsou při pohledu na to a jít, oh my. Protože teď, mohou v podstatě tlačit to tam, dovolte, že kampaň jen sedět tam, dokud se na trh, a nikoli muset starat o obr o jaký druh infrastruktury bude tam na její podporu. A pak, jakmile že kampaň je hotovo, je to jako na infrastrukturu Jen okamžitě zmizí protože tam opravdu žádná infrastruktura. Je to jen kód, který sedí na Lambda. Je to jen data, která sedí v DynamoDB. Je to úžasný způsob, při tvorbě aplikací. 

Diváků: Tak to je více pomíjivý, než by bylo pokud to bylo uloženo na skutečné serveru? 

RICK Houlihan: Rozhodně. Vzhledem k tomu, že instance serveru by měla být 7 dvacet čtyřitin. To má být k dispozici pro někdo reagovat. Tak víš co? S3 je k dispozici 7 dvacet čtyřitiny. S3 vždy odpoví. A S3 je velmi, velmi dobrá při servírují objekty. Tyto objekty mohou být HTML soubory, nebo JavaScript soubory, nebo cokoliv chcete. Můžete spustit velmi bohatých webových aplikací z S3 kbelíky, a lidé dělají. 

A tak to je myšlenka tady je dostat se pryč od cesty jsme se o tom přemýšlet. Všichni jsme si myslela, že v Podmínky serverů a hostitelů. Není to o tom ještě. Je to o infrastruktury jako kód. Nasadit kód do cloudu a nechte oblak spusťte jej za vás. A to je to, co AWS se snaží dělat. 

Diváků: Takže vaše zlaté pole ve středu API brány není serverem-like, ale místo toho je jen-- 

RICK Houlihan: Můžete si myslet o tom jako fasáda serveru. Vše, co to je, je to bude trvat HTTP požadovat a mapovat na jiný proces. To je vše, co dělá. A v tomto případě, my mapování to na funkci Lambda. Dobře, takže to je vše, co mám. Děkuji mnohokrát. Vážím si toho. Vím, že chceme trochu v čase. A doufejme, že vy jste dostal trochu informací které si můžete odnést i dnes. A omlouvám se, pokud jsem šel přes některé z vašich hlav, ale je tu velká spousta základní znalosti foundational si myslím, že je velmi cenné pro vás. Takže děkuji za to, že mě. [POTLESK] Diváků: [Neslyšitelné] je, když jste říkal museli jste projít věc od začátku až do konce získat správné hodnoty nebo stejné hodnoty, jak by se hodnoty pokud [neslyšitelný] změnit. 

RICK Houlihan: Oh, idempotentních? Jak by se hodnoty změní? No, protože kdybych nebyl spuštěn to celou cestu až do konce, pak nevím, jaké změny byly provedeny v poslední míli. Nebude to být stejné údaje jako to, co jsem viděl. Publikum: Oh, takže stačí nedostal celý vstup. RICK Houlihan: Správně. Musíte jít od začátku až do konce, a pak je to Bude konzistentního stavu. Bezva. 

Diváků: Takže jste nám ukázal DynamoDB může dělat dokument nebo hodnotu klíče. A my jsme strávili hodně času na Hodnota klíče s hash a způsoby hodit kolem. Když se podíval na těchto tabulek, je to, že odcházející za přístupu dokumentu? 

RICK Houlihan: Já bych ne říkají, opouštět to za sebou. 

Diváků: Oni byli odděleni od the-- 

RICK Houlihan: S dokumentem přístup, typ dokument DynamoDB Je jen myslet jako další atribut. Je to vlastnost, která obsahuje hierarchická struktura dat. A pak se v dotazech, můžete použít vlastnosti z těchto objektů pomocí Object Notation. Tak jsem můžete filtrovat na vnořené vlastnost dokumentu JSON. Diváků: Takže kdykoliv jsem se udělat přístup dokumentu, Mohu nějak dorazit na tabular-- Diváků: Rozhodně. Publikum: --indexes a věci, které právě mluvili. RICK Houlihan: Jo, ten indexy a všechno, když chcete indexu vlastnosti JSON, tak, že budeme muset udělat, je, pokud vložíte objekt JSON nebo dokumentu do Dynamu, měli byste použít proudy. Proudy by číst vstup. Vy byste dostat, že JSON objekt a vy byste řekl OK, co je to vlastnost chci index? 

Můžete vytvářet odvozená tabulky. Teď, když je to tak, jak to funguje právě teď. Nechceme, aby vás na indexu přímo tyto vlastnosti. 

Diváků: Tabularizing dokumentů. 

RICK Houlihan: Přesně tak, zploštění to, tabularizing to přesně. To je to, co s tím dělat. 

Diváků: Děkuji. 

RICK Houlihan: Jo, absolutně, děkuji. Diváků: Takže je to trochu Mongo setkává REDIS classifers. 

RICK Houlihan: Jo, to je hodně jako to. To je dobrý popis pro něj. Bezva.