>> [Prehrávanie hudby]
RICK Houlihan: Dobre.
Ahojte všetci.
Volám sa Rick Houlihan.
Som senior riaditeľ Riešenie architekt spoločnosti AWS.
Zameriavam sa na NoSQL a Technológie DynamoDB.
Som tu dnes hovoriť ste trochu o nich.
>> Moje pozadie je predovšetkým v dátovej vrstvy.
Strávil som polku rozvoj kariéra písanie databázu,
prístup k dátam, riešenie pre rôzne aplikácie.
Bol som v oblasti virtualizácie Cloud asi 20 rokov.
Takže pred tým, než Cloud Cloud, sme boli zvyknutí hovoriť utility computing.
A nápad bol, je to ako PG & E, budete platiť za to, čo používate.
Dnes ju nazývame mrak.
>> Ale v priebehu rokov som pracoval pre pár firiem
ste pravdepodobne nikdy nepočuli.
Ale ja som zostavil zoznam technických úspechy, myslím, že by som.
Mám osem patentov v Cloud systémy virtualizácie, mikroprocesor dizajn,
komplexné spracovanie udalostí, a iných oblastiach.
>> Takže v týchto dňoch, som sa zameriavajú predovšetkým na NoSQL technológie a budúcej generácie
databáz.
A to je to všeobecne, čo budem tu byť s tebou hovoriť dnes o.
Takže to, čo môžete očakávať z tohto zasadnutia,
pôjdeme cez krátke História spracovania dát.
Je vždy užitočné pochopiť, odkiaľ sme prišli
a dôvod, prečo sme tam, kde sme.
A budeme hovoriť trochu bit o technológii NoSQL
od základnej hľadiska.
>> Dostaneme sa do niektorej z vnútorné vybavenie DynamoDB.
DynamoDB je AWS to nie je chuť.
Je plne organizovaná a Hostované riešenie NoSQL.
A budeme hovoriť trochu o stôl štruktúra, API, dátové typy, indexy,
a niektoré z niternost tohto DynamoDB technológie.
Dostaneme sa do niektorej z dizajnu vzory a osvedčených postupov.
Budeme hovoriť o tom, ako použitie tejto technológie pre niektoré
dnešných aplikácií.
A potom budeme hovoriť trochu o vývoji či vzniku
novej paradigmy programovania tzv aplikácie udalosťami riadené
a ako DynamoDB hrá v, že rovnako.
A my vám necháme trochu referenčnej architektúry diskusie
takže môžeme hovoriť o niektorých spôsoby, ako môžete použiť DynamoDB.
>> Takže najprv off-- je to otázka Počul som, že veľa, je to, čo je databáza.
Mnoho ľudí si myslí, že viete, čo je databáza.
Ak ste Google, uvidíte to.
Je to štruktúrovaný súbor údajov konalo v počítači, najmä ten, ktorý
je k dispozícii vo rôznymi spôsobmi.
Myslím, že je to dobrý Definícia modernej databázy.
Ale nepáči sa mi to, pretože to znamená niekoľko vecí.
To znamená štruktúru.
A to znamená, že je to v počítači.
A databázy nie vždy existovať na počítačoch.
Databázy vlastne existoval v mnohých ohľadoch.
>> Takže lepšie definície Databáza je niečo také.
Databáza je organizovaná mechanizmus pre ukladanie, správu,
a získavanie informácií.
To je od About.com.
Tak som to rád, pretože je to naozaj hovorí o databáze, že je úložisko,
studnicou informácie, nie nevyhnutne
niečo, čo sedí na počítači.
A celej histórii, my nie vždy mali počítačov.
>> A teraz, keď som sa opýtať priemer developer dnes to, čo je
databázu, že je odpoveď som si.
Niekde som si držať veci.
Doprava?
A je to pravda.
Ale je to nešťastné.
Vzhľadom k tomu, databázy je naozaj základom modernej aplikácie.
To je základ z každej aplikácie.
A ako si vybudovať, že databázy, ako štruktúrovať
že dáta sa bude diktovať, ako, že Aplikácia vystupuje ako merítka.
>> Takže mnoho mojej práce dnes sa zaoberá, čo
sa stane, keď vývojári tento prístup
a riešiť následky aplikácie, ktorá
Teraz je škálovanie nad rámec pôvodnej zámer a utrpenie zo zlého návrhu.
Takže dúfajme, že keď vás odísť dnes, budete
majú niekoľko nástrojov v tvoj pás, ktorý ťa držať
od robiť tie isté chyby.
Dobre.
Tak poďme hovoriť o trochou časová os databázových technológií.
Myslím, že som čítal článok Nie je to tak dávno
a povedal niečo na lines-- je to veľmi poetické vyhlásení.
To povedal, že história dát spracovanie je
plná vysokých vodoznakov hojnosti dát.
OK.
A teraz, myslím, že je celkom pravda.
Ale ja som vlastne pozrieť, je, ako história bola skutočne naplnená
s vysokým vodoznakom tlaku dát.
Vzhľadom k tomu, rýchlosť prenosu dát z Požitie nikdy klesá.
Je to len ide hore.
>> A inovácie nastane, keď vidíme tlak dát, čo
je množstvo dát, ktoré je teraz v prichádza do systému.
A to nie je možné spracovať účinne buď v čase, alebo z hľadiska nákladov.
A to je, keď začneme sa pozrieť na tlaku dát.
>> Takže keď sme sa pozrieť na prvý databáz, toto
je ten, ktorý bol medzi naše uši.
Sme všetci s tým narodil.
Je to pekná databázy.
To má vysokú dostupnosť.
Je to vždy.
Vždy sa môžete dostať.
>> Ale je to pre jedného používateľa.
Nemožno zdieľať svoje myšlienky s vami.
Nemôžete dostať svoje myšlienky keď ich chcete mať.
A ich abilitie nie je tak dobrá.
Zabúdame veci.
Tu a tam, jeden z nás listy a presunie na iný existenciu
a stratíme všetko ktorá bola v tejto databáze.
Takže to nie je tak dobré.
>> A to fungovalo dobre v priebehu času keď sme boli späť v deň
keď všetko, čo sme naozaj potrebovali vedieť, je, kde budeme pokračovať zajtra
alebo tam, kde sme sa zhromaždiť najlepšie jedlo.
Ale keď sme začali pestovať ako civilizácie a vláda začala
vstúpiť do bytia, a podniky začali vyvíjať,
sme začali si uvedomíme, Potrebujeme trochu viac, než to, čo
sme mohli dať do našej hlave.
Dobre?
>> Potrebovali sme systémy záznamu.
Potrebovali sme miesta, aby ukladanie dát schopné.
Tak sme začali písať dokumenty vytváranie knižníc a archívov.
Začali sme vyvíjať Systém Ledger účtovníctva.
A že systém počítania saldokontné bežal svet pre mnoho storočí,
A možno aj tisícročia as sme trochu rástla k veci
pokiaľ tento náklad údaje predčil schopnosť týchto systémov
aby bolo možné ho obsahovať.
>> A to sa skutočne stalo v 1880s.
Doprava?
V 1880 amerického sčítania ľudu.
To je naozaj, kde sústruženie bod moderné spracovanie dát.
To je bod, v čo je množstvo dát
ktorý bol zhromaždené Vláda USA sa dostal do bodu,
kde to trvalo osem rokov spracovať.
>> Teraz, osem years-- as viete, sčítanie ľudu
premáva každých 10 years--, takže je to celkom zrejmé, že keď sme
dostal 1890 sčítanie ľudu, Množstvo dát, ktoré
išiel byť spracované vládou bol
bude prekračujú 10 rokov to tak by sa do začala nové sčítanie ľudu.
To bol problém.
>> Takže chlapík menom Herman Hollerith prišiel
a on vynašiel prístroj nahrá punč karty, punč čítačka kariet, stĺpcové dierne štítky
tabulátor, a kolace mechanizmy pre túto technológiu.
A že spoločnosť, ktorá sa tvoril u čas, spolu s niekoľkými ďalšími,
v skutočnosti sa stal jedným z piliermi malá firma poznáme dnes vyzvala IBM.
>> Takže IBM pôvodne bol v obchodné databázy.
A to je naozaj to, čo urobili.
Urobili spracovanie dát.
>> Ako tak šíreniu punč karty, geniálny mechanizmy
že budú môcť využiť, že Technológie na hlasovanie roztriedené sady výsledkov.
Môžete vidieť v tejto snímke K dispozícii máme little--
je to trochu small-- ale môžete vidieť veľmi dômyselný mechanický mechanizmus
kde máme punč balíček kariet.
A brať niečí trochu skrutkovač
a lepenie prostredníctvom sloty a zdvihnutím nahor
sa dostať, že zápas, ktorý zoradené výsledky set.
>> Toto je agregácie.
Robíme to po celú dobu dnes v počítači,
kde to robíte v databáze.
Použili sme to urobiť ručne, je to tak?
Ľudia dať tieto veci dohromady.
A bolo to šírenie týchto diernych štítkov
do toho, čo sme nazvali dátových bubnov a dátové kotúče, papierové pásky.
>> Spracovanie dát priemysel vzal poučenie z klavírov hráčov.
Piana staré na prelome storočí
používali papierové kotúče s drážkami na to povedať, ktoré kľúče hrať.
Tak, že technológia bola upravená nakoniec pre ukladanie digitálnych dát,
pretože oni mohli dať, že dáta na týchto papierovú pásku rolách.
>> Teraz, ako výsledok, údaje bol actually-- ako
máte prístup tieto dáta bola priamo v závislosti na tom, ako ste ich uložili.
Takže keď som dal dáta na pásku, Mal som lineárne prístup k dátam.
Musel som sa vrátiť celú Páska prístup ku všetkým dátam.
Mám chcete vložiť dáta do punč karty, mohol som to prístup
v trochu viac náhodný móda, možno nie tak rýchlo.
>> Ale tam bolo obmedzenie v tom, ako prístup k dátam na základe toho, ako bol uložený.
A tak to bol problém, ísť do 50. rokov.
Opäť platí, že môžeme začať vidieť, že ako my vyvíjať nové technológie pre spracovanie
dáta, vpravo, otvára dvere pre nové riešenia,
pre nové programy, nové Žiadosti o týchto dát.
A naozaj, správa vecí verejných mohol byť dôvodom
Preto sme vyvinuli niektoré z týchto systémov.
Ale firma sa rýchlo stal sa Vodič za evolúciu
moderné databázy a moderný systém súborov.
>> Takže ďalšia vec, ktorá sa prišiel bol v 50. rokoch
bol systém súborov a Vývoj náhodného skladovania prístupu.
To bola krásna.
Teraz sú všetky náhle, môžeme dať naše súbory kdekoľvek na týchto pevných diskoch
a môžeme prístup k týmto dátam náhodne.
Môžeme analyzovať, že Informácie zo súborov.
A sme vyriešili všetkých svetových problémy s spracovania dát.
>> A to trvalo asi 20 alebo 30 rokov až do evolúcie
relačné databázy, ktorá je, keď sa svet rozhodli sme sa teraz
musí mať úložisko, ktoré prekazí rozlieha dát naprieč súboru
systémy, ktoré sme vytvorili. Doprava?
Príliš veľa dát distribuovaných v príliš veľa miesta, de-duplikácia dát,
a náklady na skladovanie bol obrovský.
>> V 70. rokoch, najdrahšie zdroj že počítač mal bol skladovanie.
Procesor bol vnímaná ako fixné náklady.
Keď som sa kúpiť box, CPU robí nejakú prácu.
Bude to byť pradenia, či je to vlastne pracuje, alebo nie.
To je naozaj fixných nákladov.
>> Ale to, čo ma stálo ako podnikania je skladovanie.
Mám-li kúpiť viac diskov ďalšie mesiac, to je skutočné náklady, ktoré som zaplatiť.
A že skladovanie je drahé.
>> Teraz sme rýchlo dopredu 40 rokov a máme iný problém.
Compute je teraz najdrahšie zdroj.
Úložisko je lacné.
Myslím, že sme môže ísť kamkoľvek na cloud a môžeme nájsť lacné skladovanie.
Ale to, čo nemôžem nájsť je lacná výpočtovej.
>> Takže evolúcie dnešnej Technológie, databázové technológie,
je naozaj zamerané na distribuovanej databázy
že netrpia rovnaký typ stupnice
obmedzenia relačných databáz.
Budeme hovoriť trochu o čo to vlastne znamená.
>> Ale jeden z dôvodov, prečo a Vodič za tohle-- my
hovoril o tlaku dát.
Tlak dát je niečo, že podporuje inováciu.
A keď sa pozriete na viac ako posledných päť rokov,
toto je tabuľka na čo sa údaje zaťaženie v rámci všeobecného podniku
vyzerá v posledných piatich rokoch.
>> A všeobecné pravidlo Tieto days-- ak idete Google--
90% z údajov, ktoré ukladáme dnes, a to bolo
vytvorených v posledných dvoch rokoch.
OK.
Teraz, sa nejedná o trend, ktorý je nový.
To je trend, ktorý bol chodiť na 100 rokov.
Od tej doby, Herman Hollerith vyvinul stĺpcové dierne štítky,
sme boli budovanie dátových úložísk a zber údajov na fenomenálne sadzby.
>> Takže v priebehu posledných 100 rokov, sme videli tento trend.
To nebude meniť.
Do budúcnosti budeme vidieť to, ak nie zrýchlené trend.
A môžete vidieť, ako to vyzerá.
>> Ak sa firma v roku 2010 mal jeden terabyte dát v rámci konania,
Dnes to znamená, že sú spravovanie 6,5 petabajtov dát.
To je 6500 krát viac dát.
A viem, že toto.
Každý deň som sa pracovať s týmito podnikmi.
Pred piatimi rokmi som by sa hovoriť na spoločnosti
kto by so mnou hovoriť o tom, čo bolesti to je riadiť terabajtov dát.
A oni by sa hovoriť so mnou o tom, ako vidíme
že je to pravdepodobne bude byť petabyte alebo dva
v priebehu niekoľkých rokov.
>> Tieto rovnaké spoločnosti Dnes mám schôdzku s,
a oni so mnou hovoriť o Problémom sú tu majú riadiace
desiatky, 20 petabajtov dát.
Takže Explózia Dáta v priemysle
poháňa obrovský Potrebujete pre lepšie riešenie.
A relačnej databázy je proste žiť až do dopytu.
>> A tak je tu lineárny korelácia medzi tlakom dát
a technické inovácie.
História nám ukázala, to, že v priebehu doby,
vždy, keď sa objem dát ktoré musia byť spracované
presahuje kapacitu systému spracovať ju v rozumnom čase
alebo za rozumnú cenu, potom nové technológie
sú vynájdené na riešenie týchto problémov.
Tieto nové technológie, naopak, otvorte dvierka
na inú sadu problémov, ktoré zbiera aj ďalšie dáta.
>> Teraz, nebudeme to zastaviť.
Doprava?
Nebudeme to zastaviť.
Prečo?
Vzhľadom k tomu, nemôžete vedieť všetko tam je poznať vo vesmíre.
A tak dlho, ako sme boli nažive, v celej histórii človeka,
sme vždy riadený vedieť viac.
>> Takže to vyzerá, že každý palec sa pohybujeme po ceste vedeckého objavu,
sme sa množia množstvo dát že musíme spracovať exponenciálne
ako odhaliť viac a viac a viac o vnútornom fungovaní života,
o tom, ako vesmír funguje, o riadil vedecký objav,
a vynález, ktorý robíme dnes.
Objem dát len neustále zvyšuje.
Takže je schopný vysporiadať sa s Tento problém je obrovský.
>> Takže jedna z vecí sa pozrieme, ako, prečo NoSQL?
Ako NoSQL tento problém vyriešiť?
No, relačné databázy, Structured Query Language,
SQL--, že je naozaj konštrukt relačné database-- tieto veci sú
optimalizovaný pre skladovanie.
>> Späť v 70. rokoch, sa znova, disk je drahé.
Dotačné Výkon skladovanie V podniku je nikdy nekončiaci.
Viem.
Žil som to.
Napísal som ovládače úložisko pre enterprised SuperServer firmy
späť v 90. rokoch.
A faktom je stáčanie ďalší diskové pole bolo len niečo,
každý deň v podniku stalo.
A to nikdy neprestalo.
Vyššia hustota skladovanie, dopyt pre vysokou hustotou skladovanie,
a pre efektívnejšie ukladanie devices-- to nikdy neprestalo.
>> A NoSQL je špičkovou technológiou preto, že normalizuje dáta.
Je to de-kopíruje dáta.
Kladie dáta v štruktúre, ktorá je agnostik na každú vzorku prístup.
Viac aplikácií, ktoré môže zasiahnuť SQL databázy, spúšťať dotazy ad hoc,
a získať dáta v tvare, ktorý sa je potrebné spracovať pre svoje pracovné záťaže.
To znie fantasticky.
Ale faktom je, s akýmkoľvek systém, ak je to agnostik ku všetkému,
je optimalizovaný pre nič za nič.
OK?
>> A to je to, čo sme si s relačnej databázy.
Je optimalizovaný pre skladovanie.
To je normalizovaná.
Je to relačná.
Podporuje otázky ad hoc.
A to je a to váhy zvisle.
>> Ak je potreba získať väčší SQL databáze alebo silnejšie SQL databázy,
Idem si kúpiť väčší kus železa.
OK?
Pracoval som s mnohými zákazníkov ktoré boli prostredníctvom významnej modernizácie
iba v ich SQL infraštruktúry zistiť, o šesť mesiacov neskôr,
oni biť do steny znovu.
A odpoveď z Oracle alebo MSSQL alebo niekto iný, je dostať väčší krabici.
Tak skôr alebo neskôr, nemôžete kúpiť väčšie box, a to je skutočný problém.
Musíme skutočne niečo zmeniť.
Takže tam, kde to funguje?
Funguje to dobre pre offline analytika, OLAP typu zaťaženia.
A to je naozaj, kde SQL patrí.
Teraz, to je dnes používaný v mnohých online transakčné spracovanie typu
aplikácie.
A funguje to v pohode na určitá úroveň využitia,
ale to jednoducho nie je meradlo tak, že NoSQL robí.
A budeme hovoriť trochu bit o tom, prečo to je.
>> Teraz, NoSQL, na druhej strane, je viac optimalizovaný pre výpočtovo.
OK?
Nie je k agnostik prístup vzor.
Je to, čo nazývame de-normalizoval štruktúra alebo hierarchická štruktúra.
Dáta v relačnej databáze spojené dohromady z viacerých tabuliek
produkovať názor, že potrebujete.
Dáta v databáze NoSQL je uložený v dokumente, ktorý
obsahuje hierarchickú štruktúru.
Všetky dáta, ktoré by normálne spojili produkovať tento názor
je uložený v jedinom dokumente.
A budeme hovoriť trochu o ako to funguje v niekoľkých grafov.
>> Ale myšlienka je, že budete ukladať Vaše dáta sú tieto konkretizované výhľadom.
OK?
Tie vodorovne škálovať.
Doprava?
Ak je potreba zvýšiť veľkosť môjho klastra NoSQL,
Nepotrebujem, aby si väčšiu krabicu.
Mám ďalšie krabicu.
A ja klastra ty dohromady, a ja si črep, že dáta.
Porozprávame sa niečo o čo sharding je, že
schopné škálovať tejto databázy cez viac fyzických zariadení
a odstrániť bariéru, ktorá vyžaduje, aby som meradle zvisle.
>> Takže je to naozaj postavené pre on-line spracovanie transakcií a meradlo.
Je tu veľký rozdiel tu medzi hlásenie, že jo?
Reporting, ja nepoznáte Otázky Idem sa opýtať.
Doprava?
Reporting-- ak niekto z môj marketingové oddelenie
chce jen--, koľko z mojich zákazníkov mať túto zvláštnu vlastnosť, ktorá
kúpil na tejto day-- neviem čo dotaz idú opýtať.
Tak som treba byť agnostik.
>> Teraz, v on-line transakčné aplikácie,
Viem, aké otázky sa pýtam.
Postavil som žiadosť o veľmi špecifický workflow.
OK?
Takže keď som optimalizovať údaje ukladať na podporu tohto pracovného postupu,
že to bude rýchlejšie.
A to je dôvod, prečo môže NoSQL Naozaj urýchliť dodávku
z týchto typov služieb.
Dobre.
>> Takže sme sa dostať do trochu teórie tu.
A niektorí z vás, vaše oči môže vrátiť späť trochu.
Ale budem sa snažiť, aby to ako vysokej úrovni ako ja.
Takže ak ste v projekte management, je tu
konštrukt nazvaný trojuholník obmedzenia.
OK.
Trojuholník obmedzuje diktátu nemôžete mať všetko čas.
Nemôžete mať svoj koláč a jesť to príliš.
Takže v oblasti projektového riadenia, že trojuholník obmedzenie ich môžete mať lacné,
môžete mať to rýchlo, alebo môžete mať to dobré.
Vyberte si dva.
Vzhľadom k tomu, nemôžete mať všetky tri.
Doprava?
OK.
>> Takže ste počul o tom veľa.
Je to trojitý obmedzenia, trojuholník trojité obmedzenia,
alebo železo trojuholník je oftentimes-- Keď hovoríte s projektovým manažérom,
oni Porozprávame sa o tom.
Teraz, databázy majú ich vlastné železo trojuholník.
A železo trojuholník údajov je to, čo nazývame veta CAP.
OK?
>> CAP teorém diktuje ako fungujú databázy
za veľmi špecifických podmienok.
A budeme hovoriť o tom, čo je táto podmienka.
Ale tri body trojuholníka, tak povediac, sú C, konzistencia.
OK?
Takže v CAP, konzistencie znamená, že všetky Klienti, ktorí majú prístup k databáze
bude mať vždy veľmi konzistentné pohľad na dáta.
Nikto sa bude vidieť dve rôzne veci.
OK?
Keď vidím databázu, Vidím rovnaký pohľad
ako môj partner, ktorý vidí rovnakej databázy.
To je konzistencia.
>> Dostupnosť znamená, že v prípade, že databázy on-line, v prípade, že môže byť dosiahnutý,
že všetci klienti budú vždy byť schopný čítať a písať.
OK?
Takže každý klient, ktorý môžete prečítať databázy
budú vždy schopní čítanie Údaje údaje a písať.
A ak je to tak, je to k dispozícii systém.
>> A tretí bod je to, čo nazývame tolerancia oddielu.
OK?
Tolerancia Partition prostriedky že systém funguje dobre
aj cez fyzické siete priečky medzi uzlami.
OK?
Takže uzly v klastri nemôže hovoriť k sebe navzájom, čo sa stane?
Dobre.
>> Takže relačnej databázy vyberte-- si môžete vybrať dva z nich.
OK.
Takže relačnej databázy vyberte byť konzistentné a sú k dispozícii.
Ak oddiel sa deje medzi že DataNodes v úložisku dát,
databázy havaruje.
Doprava?
Je to len ide dole.
OK.
>> A to je dôvod, prečo majú rast s väčšími boxy.
Doprava?
Pretože tam je no-- obvykle, cluster Databázy, že to nie je moc veľa z nich
že fungujú týmto spôsobom.
Ale väčšina databáz mierka vo zvislom smere v rámci jediného poľa.
Vzhľadom k tomu, že musí byť konzistentné a sú k dispozícii.
Ak oddiel mal byť aplikovaný, potom budete musieť urobiť voľbu.
Musíte si vybrať medzi je v súlade a sú k dispozícii.
>> A to je to, čo databázy NoSQL robiť.
Dobre.
Takže databázy NoSQL to, prichádza v dvoch príchutiach.
My have-- dobre, to prichádza v mnohých príchutiach,
ale prichádza s dvoma základnými characteristics-- čo
by sme nazvali CP databázy, alebo konzistentné a oddiel tolerancie
systém.
Títo chlapi či sa rozhodne, že keď uzly strate kontaktu spolu navzájom,
nebudeme dovoliť ľudia písať viac.
OK?
>> Do tej doby bude oddiel odstránený, Prístup pre zápis je blokovaný.
To znamená, že to nie je k dispozícii.
Sú konzistentné.
Keď vidíme, že partition injekciu sám,
sme teraz konzistentné, pretože my nejdeme
aby zmenu dát na dva strany prepážky samostatne
na sebe.
Budeme sa musieť obnoviť komunikáciu
pred akýmkoľvek aktualizáciu dáta je povolené.
OK?
>> Ďalšie variant by bol systém AP, alebo k dispozícii a rozdelí
tolerancia systém.
Títo chlapci to jedno.
Doprava?
Akýkoľvek uzol, ktorý dostane písať, budeme si to.
Takže som svoju replikáciu dát cez viac uzlov.
Tieto uzly sa klient, klient príde V hovorí, budem zapisovať niektoré údaje.
Node hovorí, žiadny problém.
Uzol Vedľa neho dostane Zápis na rovnakom zázname,
že to bude hovoriť žiadny problém.
Niekde späť na konci zadnej, že dáta to bude replikovať.
A potom niekto to bude realizovať, uh-oh, ale systém bude realizovať, uh-oh,
Stala sa aktualizácie dvoch strán.
Čo budeme robiť?
A to, čo robia, je potom robia niečo, čo
im umožňuje riešiť tento stav dát.
A budeme hovoriť o tom, že v nasledujúcom grafe.
>> Thing poukázať tu.
A ja nebudem mať moc omnoho do toho, pretože to
dostane do hlbokej teórie dát.
Ale je tu transakčné rámec, ktorý
prebieha v relačnej systému, ktorý mi umožňuje bezpečne vykonávať aktualizácie
na viac subjektov v databáze.
A tieto aktualizácie budú vyskytovať naraz, alebo vôbec nie.
A to sa nazýva ACID transakcie.
OK?
>> ACID nám dáva Atomicita, konzistencia, izolácia, a trvanlivosť.
OK?
To znamená, že atómové, transakcie, všetko moje aktualizácie buď stáť, alebo nie.
Konzistencie znamená, že Databáza bude vždy
byť uvedená do konzistentné stav po aktualizácii.
Ja sa nikdy opustiť databázy v po použití aktualizácie zlý stav.
OK?
>> Takže je to trochu inak než konzistencia CAP.
Konzistencia CAP znamená, že všetky moje klienti môžu vždy zobraziť údaje.
ACID konzistencie znamená, že keď transakcie sa stalo, údaje je dobré.
Moje vzťahy sú dobré.
Nebudem odstrániť nadradený riadok a zanechať veľa osirelých detí
v inej tabuľke.
To sa nemôže stať, či som v súlade v kyslom transakcie.
>> Izolácie znamená, že transakcia dôjde vždy po sebe.
Konečný výsledok dát bude rovnaký stav
ako keby tieto transakcie ktoré boli vydané súbežne
boli popravení sériovo.
Takže je to súbežnosť kontrola v databáze.
Takže v podstate, nemôžem zvýšiť Rovnaká hodnota dvakrát s dvoma operáciami.
>> Ale keď poviem pridať 1 k tejto hodnote, a dve transakcie prísť
a pokúsiť sa urobiť to, niečí tam dostane ako prvý
a druhý je bude sa tam dostať po.
Takže nakoniec, som pridal dva.
Vieš, čo tým myslím?
OK.
>> Trvanlivosť je veľmi jednoduché.
Keď je transakcia Uznáva sa, že je to
Bude tam aj v prípade, že systém sa zrúti.
Keď sa tento systém využíva, že Transakcie, ktorá bola spáchaná
je v skutočnosti tam bude.
Tak to je záruky kyseliny transakcií.
To sú celkom pekné záruky mať na databázu,
ale prídu na týchto nákladov.
Doprava?
>> Vzhľadom k tomu, problém s tento rámec
v prípade, že je oddiel v dátach set, musím urobiť rozhodnutie.
Budem musieť umožniť Aktualizácie na jednej alebo druhej strane.
A ak sa tak stane, potom som už ísť
aby bolo možné zachovať tieto vlastnosti.
Nebudú konzistentné.
Nebudú byť izolované.
To je miesto, kde sa rozkladá pre relačnej databázy.
To je dôvod, relačná databáz mierka vertikálne.
>> Na druhej strane, máme čo sa nazýva BASE technológie.
A to sú vaše NoSQL databázy.
Dobre.
Takže máme CP, databázy AP.
A to sú v podstate to, čo hovoríte k dispozícii, mäkký stav, prípadne
konzistentné.
OK?
>> V podstate k dispozícii, pretože sú to oddiel tolerantní.
Budú vždy tam, a to aj v prípade, že je
deliaca sieť medzi uzlami.
Môžem Ak hovoriť k uzlu, ja som bude schopný čítať dáta.
OK?
Aj nemusí byť vždy schopný napísať Údaje, či som konzistentné platformu.
Ale budem môcť čítať dáta.
>> Mäkká stav označuje že keď som si prečítal, že dáta,
to nemusí byť rovnaké ako ostatných uzlov.
Ak právo bolo vydané v uzle niekde inde v klastri
a nebola replikované naprieč klaster ale keď som čítal, že údaje,
že štát nemusí byť konzistentné.
Avšak, to bude nakoniec konzistentné,
čo znamená, že keď je pre zápis sa vykonáva v systéme,
sa bude replikovať cez uzly.
A nakoniec, že ​​štátna budú uvedené do poriadku,
a to bude konzistentným stave.
>> Teraz, teorém CAP naozaj hrá len v jednom stave.
Táto podmienka je, keď sa to stane.
Vzhľadom k tomu, kedykoľvek je to pracovať v normálny režim, neexistuje žiadny oddiel,
všetko je konzistentné a sú k dispozícii.
Stačí len starať o SPP keď máme tento oddiel.
Takže tie sú zriedkavé.
Ale ako systém reaguje, keď tí, dochádza diktovať, aký typ systému
máme čo do činenia s.
>> Takže poďme sa pozrieť na to, čo že vyzerá ako na AP systémy.
OK?
Systémy AP prichádzajú v dvoch príchutiach.
Prichádzajú v chuti, ktorá je master master, 100%, vždy k dispozícii.
A prichádzajú v iná varianta, ktorá hovorí,
Vieš čo, ja budem robiť starosti o Toto rozdelenie veci
v prípade, že skutočná partition dôjde.
Inak to bude primárne uzly, kto bude mať práva.
OK?
>> Ak teda niečo ako Cassandra.
Cassandra by byť majster master, dovoľte mi, aby som to zapísať do ktoréhokoľvek uzla.
Takže čo sa stane?
Takže mám objekt v databázy, ktorá existuje na dvoch uzlov.
Hovorme tento objekt S. Takže máme stať pre S.
Máme niektoré operácie na S, ktoré prebiehajú.
Cassandra mi dovoľuje píšte na viac uzlov.
Takže povedzme, že som sa dostať písať pre s dvoma uzlami.
No, čo skončí deje, je hovoríme, že rozdeľovacom udalosti.
Tam nemusí byť oddiel fyzická sieť.
Avšak z dôvodu konštrukcie systému, to je
v skutočnosti rozdelenie akonáhle ako som si písať na dvoch uzlov.
Nie je to ma núti napísať celý jeden uzol.
Píšem na dvoch uzlov.
OK?
>> Takže teraz mám dva stavy.
OK?
Čo sa bude diať je skôr alebo neskôr,
tam to bude udalosť replikácie.
Tam to bude to, čo sme volal zotavenie oddiel, ktorý
je miesto, kde tieto dva štáty vrátiť spolu
a tam to bude algoritmus ktorý beží vnútri databázy,
sa rozhodne, čo má robiť.
OK?
V predvolenom nastavení, posledná aktualizácia víťazí vo väčšine systémov AP.
Takže tam je zvyčajne predvolený algoritmus, čo
hovoria spätné volanie funkcie, niečo,
bude volaná, keď táto podmienka je detekovaný vykonávať nejakú logiku
k vyriešeniu tohto konfliktu.
OK?
Východiskové spätné volanie a východiskové resolver vo väčšine AP databázach
je, vieš čo, timestamp vyhráva.
To bola posledná aktualizácia.
Chystám sa dať túto aktualizáciu tam.
Možno som výpis tento záznam, ktorý som dumpingové off do protokolu obnovy
takže užívateľ môže prísť neskôr a povedať, hej, došlo ku kolízii.
Čo sa stalo?
A môžete skutočne výpis záznam všetky kolízie a vrátenie vykonaných zmien
a uvidíme, čo sa stane.
>> Teraz, ako užívateľ, môžete tiež obsahovať logiku do tohto spätného volania.
Takže si môžete zmeniť spätné volanie operácie.
Môžete povedať, hej, ja chcem k náprave tohto dátumu.
A ja chcem, aby sa pokúsila zlúčiť tieto dva záznamy.
Ale to je len na vás.
Databázy nevie, ako sa tomu, že v predvolenom nastavení. Najviac času,
jediné, čo je databáza Vie, ako urobiť, je povedať,
tento bol posledný záznam.
To je ten, ktorý vyhrá, a to je hodnota idem dať.
Akonáhle to oddiel zotavenie a dôjde k replikáciu,
máme štát, ktorý Teraz je S prvočíslo, čo je
zlúčenie stav všetkých týchto objektov.
Takže systémy AP toto.
CP systémy nepotrebujú sa starať o to.
Vzhľadom k tomu, akonáhle oddiel prichádza do hry, jednoducho prestať užívať
píše.
OK?
Takže je to veľmi jednoduché vysporiadať s tým, že v súlade
ak nechcete prijímať žiadne aktualizácie.
To je s CP systémy robia.
Dobre.
>> Takže poďme hovoriť trochu niečo o prístupových vzory.
Keď hovoríme o NoSQL, je to všetko o vzorku prístup.
Teraz, SQL je ad hoc otázky.
Je to relačná obchod.
Nemusíme sa báť o vzorku prístup.
Píšem veľmi zložitý dotaz.
Ide to a získava dáta.
To je to, čo to vyzerá ako, normalizácia.
>> Takže v tomto konkrétnu štruktúru, pozeráme na katalóg produktov.
Mám rôzne druhy výrobkov.
Mám knihy.
Mám albumu.
Mám videa.
Vzťah medzi výrobkami a niektorý z týchto kníh, albumov,
a videá tabuliek je 1: 1.
Dobre?
Mám ID produktu, a že ID zodpovedá
na knihu, album, alebo video.
OK?
To je vzťah 1: 1 po týchto tabuľkách.
>> Teraz, books-- všetko, čo majú vlastnosti je root.
Žiaden problém.
To je skvelé.
One-to-one vzťah, som si všetky údaje musím opísať tú knihu.
Albums-- albumu majú stopy.
To je to, čo nazývame jeden k veľa.
Každé album môže mať mnoho stôp.
Takže pre každé dráhe na album, mohol by som mať
ďalší rekord v tomto podriadenej tabuľke.
Tak som vytvoriť jeden záznam v mojom albumu tabuľke.
Vytvoriť viac záznamov v tabuľke stop.
One-to-many vzťah.
>> Tento vzťah je to, čo nazývame many-to-many.
OK?
Vidíte, že herci by mohla byť v mnohých filmoch, mnoho videí.
Takže to, čo robíme, je, že sme dať toto mapovanie tabuľku medzi tými, ktoré sa práve
mapuje herca ID do ID videa.
Teraz môžem vytvoriť dotaz spoje videa cez herec videa do hercov,
a to mi dáva pekný zoznam všetky filmy a všetci herci
ktorí boli v tom filme.
>> OK.
Tak ideme na to.
One-to-one je najvyššej úrovne vzťah; one-to-many,
albumu skladieb; many-to-many.
To sú tri najvyššie úrovne vzťahy v žiadnej databáze.
Ak viete, ako tí, vzťahy pracovať spoločne,
potom viete veľa o už databázy.
Takže NoSQL trochu funguje inak.
Poďme sa zamyslieť nad za druhé to, čo to Vyzerá to, ísť pre všetky svoje produkty.
>> V relačné obchode, ja sa chcú dostať všetky svoje produkty
na zozname všetkých mojich výrobkov.
To je veľa otázok.
Mám otázku pre všetky moje knihy.
Mám otázku od svojich albumov.
A ja mám otázku pre všetkých mojich videí.
A ja musím dať všetko dohromady v zozname
a slúži to späť až do výšky aplikácie, ktorá je o to požiada.
>> Ak chcete získať svoje knihy, som sa pripojiť Produkty a knihy.
Ak chcete získať moje albumu, som sa pripojiť Produkty, albumu a skladby.
A aby sa moje videá, mám pripojiť produktov na videá,
pripojiť cez hercov videa, a priniesť hercov.
Tak to je tri otázky.
Veľmi zložité otázky na zhromaždiť jednu sadu výsledkov.
>> To je menej ako optimálny.
To je dôvod, prečo, keď hovoríme o dátové štruktúry, ktorá je
postavená tak, aby agnostik s prístupom pattern-- dobre, že je to skvelé.
A vidíte, je to naozaj pekné, ako sme organizovali dáta.
A viete čo?
Mám len jeden záznam pre herca.
>> To je v pohode.
Ja som deduplikované všetky svoje herca, a ja udržiavané svoje združenie
V tejto tabuľke mapovanie.
Avšak, ako sa dáta out sa stáva drahšie.
Posielam CPU celého systému spájajúcej tieto dátové štruktúry spolu
aby bolo možné vytiahnuť, že dáta späť.
>> Tak ako to mám dostať okolo, že?
V NoSQL je to o agregácie, nie normalizácie.
Takže chceme povedať chceme podporovať prístup vzor.
Ak vzorka prístup k aplikáciám,
Musím sa dostať všetky svoje výrobky.
Poďme dať všetky produkty v jednej tabuľke.
Keď som dal všetky produkty v jednej tabuľke, Ja si len vybrať všetky produkty
Z tejto tabuľky, a ja si to všetko.
Tak ako to mám urobiť, že?
No v NoSQL nie je štruktúra k stolu.
Budeme hovoriť trochu o Ako to funguje Dynamo DB.
Ale nemusíte mať rovnaký atribúty a rovnaké vlastnosti
v každom rade, v každom jednotlivom položky, ako vy v tabuľke SQL.
A čo mi to dovoľuje urobiť, je veľa vecí
a dal mi veľkú flexibilitu.
V tomto konkrétnom prípade, I majú svoj produkt doklady.
A v tomto konkrétnom príklad, všetko
je dokument, v tabuľke Výrobky.
A produkt pre knihu by mohol majú ID typu, ktorý určuje knihu.
A aplikácie by sa malo prepnúť na tomto ID.
>> V aplikačnej vrstve, idem hovoriť ach, aký typ záznamu je to?
Oh, to je kniha rekord.
Book záznamy majú tieto vlastnosti.
Dovoľte mi, aby som vytvoriť knihu objekt.
Takže ja idem pre naplnenie kniha objekt s touto položkou.
Ďalšia položka príde a hovorí, čo je táto položka?
No táto položka je album.
Oh, mám úplne iná rutina pre spracovanie, ktoré,
pretože je to album.
Vieš, čo tým myslím?
>> Takže aplikácie tier-- I stačí vybrať všetky tieto záznamy.
Všetci začnú prichádzať dovnútra.
Mohli by byť všetky typy.
A je to logika aplikácie ktorý prepína naprieč týchto typov
a rozhodne, ako ich spracovať.
>> Opäť, takže sme optimalizáciu schéma vzorka prístup.
Robíme to tým, rúca tie tabuľky.
Sme v podstate prevzatia Tieto štandardizovanej štruktúry,
a staviame hierarchickej štruktúry.
Vnútri každej z týchto záznamov Idem vidieť vlastnosti poľa.
>> Vnútri tohto dokumentu pre albumu, Vidím matice stop.
Tieto stopy teraz become-- je to v podstate toto dieťa tabuľka
existuje priamo tu v tejto štruktúre.
Takže môžete to urobiť v DynamoDB.
Môžete to urobiť v MongoDB.
Môžete to urobiť v akejkoľvek databáze NoSQL.
Vytvorte tieto typy hierarchickej dátovej štruktúry
ktoré umožňujú načítanie dát veľmi rýchlo, pretože teraz
Nemusíte odpovedať.
Keď som sa vložiť riadok do koľajniciach stôl, alebo o riadok do tabuľky Alba
Musím odpovedať tomuto schémy.
Musím mať atribút alebo majetok, ktorý je definovaný na tejto tabuľke.
Každý z nich, keď som vložte tento riadok.
To nie je prípad v NoSQL.
>> Môžem mať úplne odlišné vlastnosti v každom dokumente
že som sa vložiť do zbierky.
Takže veľmi silný mechanizmus.
A je to naozaj, ako vás optimalizáciu systému.
Vzhľadom k tomu, teraz, že otázka, namiesto spájanie všetky tieto tabuľky
a vykonávanie pol tucta otázky vytiahnuť späť dáta, čo potrebujem,
Som vykonávajúci jeden dotaz.
A ja som iterácie cez výsledky uvedené.
to vám dáva predstavu o sile NoSQL.
Chystám sa ísť trochu bokom tu a hovoriť trochu o tom.
To je viac druhov marketing alebo technology--
marketing technológie typ diskusie.
Ale je dôležité pochopiť, pretože keď sa pozrieme na vrchole
tu na tento graf, čo sa pozeráme
je to, čo nazývame Technológie humbuk krivka.
A čo to znamená, nové veci prichádza do hry.
Ľudia si myslia, že je to skvelé.
Ja som vyriešil všetky moje problémy.
>> To by mohlo byť koniec všetci, byť všetko, na všetko.
A začnú používať.
A oni hovoria, toto nefunguje.
To nie je správne.
Staré veci boli lepšie.
A oni sa vrátiť k robeniu veci tak, ako boli.
A potom nakoniec idú, vieš čo?
Toto nie je tak zlé.
Ach, to je, ako to funguje.
A akonáhle sa zistiť, ako to práce, začnú stále lepší.
>> A legrační vec, o tom Je to trochu liniek až na to, čo
nazývame Technology osvojenie dieťaťa krivky.
Takže čo sa stane, je, že sme sa nejaká technológia spúšť.
V prípade databáz, to je tlak dát.
Hovorili sme o vysokých vodných bodov tlaku dát po celú dobu.
Keď tieto dáta tlak zasiahne určité bod, to je technológia spúšť.
>> Začína to príliš drahé.
To trvá príliš dlho, aby spracovanie dát.
Potrebujeme niečo lepšie.
Získate inovátorov tam vonku pobehujú,
snaží zistiť, aké je riešenie.
Čo je to nová myšlienka?
>> Aký je ďalší najlepší spôsob, ako túto vec?
A oni prídu s niečím.
A ľudia s skutočnú bolesť, chlapci na drsne,
budú skákať cez to všetko, pretože potrebujú odpoveď.
A teraz, čo nevyhnutne happens-- a to sa práve teraz deje v NoSQL.
Vidím to po celú dobu.
>> Čo sa nevyhnutne stane, je ľudia začnú používať nový nástroj
rovnaký spôsob, akým používa staré nástroje.
A oni zistili to nefunguje tak dobre.
Nemôžem si spomenúť, kto som hovoriť dneska.
Ale je to ako, keď sa zbíjačka bol vynájdený,
ľudia nemali hojdačka ju ich hlava rozbiť betón.
>> Ale to je to, čo je deje NoSQL dnes.
Pôjdete Ak vo väčšine obchodov, sa snaží byť NoSQL obchodov.
To, čo robíte, je Používajú NoSQL,
a oni ho načítanie plná relačného schémy.
Vzhľadom k tomu, že to, ako navrhujú databáz.
A oni sú zvedaví, prečo je to nefunguje dobre?
Páni, táto vec smrdí.
Musel som sa udržať všetky moje pripojí in-- je to ako, nie, nie.
Udržiavať sa pripojí?
Prečo sa pripojí dáta?
Nemusíte pripojiť dáta v NoSQL.
Agregovať to.
>> Takže ak chcete, aby sa tomu zabránilo, učiť sa ako nástroj funguje pred vami vlastne
začať používať.
Nesnažte sa používať nové nástroje pre Rovnakým spôsobom ste použili staré nástroje.
Budeš mať zlú skúsenosť.
A zakaždým to je to, o čo ide.
Keď sme sa začnú prichádzať tu je to preto, že ľudia zistili,
ako používať nástroje.
>> Urobili rovnakú vec, keď relačnej databázy boli vynájdené,
a oni boli nahradenie súborové systémy.
Snažili sa vybudovať súborové systémy s relačných databáz
pretože to je to, čo ľudia pochopili.
Nefungovalo to.
Takže pochopenie osvedčených postupov technológia pracujete s
je obrovský.
Veľmi dôležité.
>> Takže sme sa dostať do DynamoDB.
DynamoDB je AWS je Plne riadené NoSQL platformy.
Čo znamená plne riadené znamená?
To znamená, že nemusíte naozaj o nič starať.
>> Môžete prísť, poviete us, potrebujem tabuľku.
Je potrebné toľko kapacity.
Stlačíte tlačidlo, a my ustanovenia všetka infraštruktúra za scény.
Teraz, keď je obrovský.
>> Vzhľadom k tomu, keď hovoríte škálovanie o databázy,
NoSQL dátové klastre na stupnice, prevádzkové petabajtov,
beží milióny transakcií za sekundu,
tieto veci nie sú malé zhluky.
Hovoríme tisíce inštancií.
Správa tisíce prípadov, dokonca aj virtuálne inštancie,
je skutočnou bolesť v zadku.
Mám na mysli, premýšľať o tom, zakaždým, keď Systém náplasť prevádzkové vyjde
alebo novú verziu databázy.
Čo to znamená vám prevádzkovo?
To znamená, že máš 1200 servery, ktoré je potrebné aktualizovať.
Teraz ešte s automatizáciou, ktorý môže trvať dlhý čas.
To môže spôsobiť veľa prevádzkové bolesti hlavy,
preto, že som mohol mať služby nadol.
>> Keď som aktualizovať tieto databázy, ja mohli robiť modrá zelená nasadenie
kde som nasadiť a upgrade polovica mojej uzly, a potom inovovať druhú polovicu.
Vezmite tie dole.
Takže riadenie infraštruktúry Mierka je nesmierne bolestivé.
A AWS prijať, že bolesť z nej.
A databázy NoSQL môže byť mimoriadne bolestivá
vzhľadom na spôsob ich mierku.
>> Mierka vodorovne.
Ak chcete mať väčšiu NoSQL databázy, kupujete viac uzlov.
Každý uzol si kúpite, je ďalší operačný bolesť hlavy.
Tak nech niekto iný urobí za vás.
AWS môže urobiť.
>> Podporujeme hodnoty kľúčového dokumentu.
Teraz sme nešli moc do na strane grafu.
Je tu mnoho rôznych chuťou NoSQL.
Sú to všetky druhy získavanie munged spoločne v tomto bode.
Môžete sa pozrieť na DynamoDB a povedať áno, obaja sme dokument a kľúčovou hodnotou
uložiť tento bod.
A môžete argumentovať funkcie jedného nad druhým.
Pre mňa, veľa je to naozaj six jednej pol tucta druhého.
Každý z týchto technológií je jemné technológie a kvalitné riešenie.
Nepovedal by som, že je lepší alebo MongoDB horšie ako Couch, potom Cassandra,
potom Dynamo, alebo naopak.
Chcem povedať, že to sú len možnosti.
>> Je to rýchle a je to konzistentné v akomkoľvek meradle.
Takže to je jedna z najväčších bonusy získate s AWS.
S DynamoDB je schopnosť získať nízke jednu číslicu
milisekunda oneskorenie v akomkoľvek meradle.
To bol cieľ dizajnu systému.
A máme zákazníkov, ktoré robia milióny transakcií za sekundu.
>> Teraz budem ísť cez niektoré z tých, prípadov použitia za niekoľko minút tu.
Integrovaný prístup control-- máme to, čo nazývame
Identity Access Management, alebo IAM.
To prestupuje všetky systémy, každá služba, ktorá ponúka AWS.
DynamoDB nie je výnimkou.
Môžete riadiť prístup k DynamoDB tabuliek.
Cez všetky vaše AWS účtov definovanie prístupových rolí a oprávnení
v IAM infraštruktúry.
>> A to je kľúč a neoddeliteľnou zložkou to, čo nazývame udalosťami riadené programovanie.
Teraz sa jedná o nové paradigma.
>> Divákov: Ako je na tom vaša rýchlosť true pozitíva oproti falošne negatívnych
vo vašom systéme riadenia prístupu?
RICK Houlihan: Pravda pozitívy proti falošne negatívne?
Publikum: Vrátenie čo mali by ste sa vracia?
Na rozdiel od raz za čas to nevracia, kedy by mal overiť?
>> RICK Houlihan: Nemohla som ti to povedať.
Ak existuje nejaké poruchy vôbec na to,
Nie som človek sa opýtať že osobitné otázka.
Ale to je dobrá otázka.
Bol by som zvedavý že sám, v skutočnosti.
>> A tak opäť, nové paradigma je udalosťami riadené programovanie.
To je myšlienka, že môžete nasadiť komplexné aplikácie, ktoré
môže pracovať veľmi, veľmi vysoká merítka bez akejkoľvek infraštruktúry vôbec.
Bez stanovených infraštruktúru vôbec.
A budeme hovoriť trochu o tom, čo to znamená, že ako my
dostať sa na ďalší pár grafov.
>> Prvá vec, ktorú urobíme ich budeme hovoriť o tabuľkách.
Dátové typy API pre Dynamo.
A prvá vec, ktorú budete Všimnite si, keď sa pozriete na to,
ak ste oboznámení s ľubovoľnou databázou, databázy majú naozaj dva druhy API
Ja by som to hovoriť.
Alebo dve sady API.
Jednou z nich by bol administratívne API.
>> Veci, ktoré sa starajú o Funkcie databázy.
Konfigurácia engine pre ukladanie, zriaďovanie a pridávanie tabuliek.
vytvorenie databázy katalógy a inštancie.
Tie things-- v DynamoDB, budete majú veľmi krátky, krátky zoznamy.
>> Takže v iných databázach, môžete vidieť desiatky
príkazov, správnych príkazy, pre konfiguráciu
tieto ďalšie možnosti.
V DynamoDB nepotrebujete, pretože tí, nenakonfigurujete systém, čo robíme.
Takže jediná vec, ktorú musíte urobiť, je povedz mi, čo veľkosť tabuľky potrebujem.
Tak dostanete veľmi obmedzený súbor príkazov.
>> Získate CREATE TABLE aktualizácie, tabuľka, Odstrániť tabuľku a označenie stolových.
To sú jediné veci, čo potrebujete pre DynamoDB.
Nemusíte úložisko konfigurácia motora.
Nepotrebujem sa starať o replikáciu.
Nepotrebujem sa starať o sharding.
>> Nepotrebujem sa obávať o niektorý z týchto vecí.
Robíme to všetko za vás.
Tak to je obrovské množstvo réžia to je len zdvihne tanier.
Potom máme operátormi CRUD.
CRUD je niečo, čo sme volať v databáze, ktorá je
Vytvoriť, aktualizovať, mazať operátorov.
To sú vaše bežné databázové operácie.
Veci ako put položku, dostať položku, aktualizácia položky, mazať položky, šarže dotaz, skenovať.
Ak chcete skenovať celú tabuľku.
Vytiahnite všetko zo stola.
Jedna z pekné veci o DynamoDB Je to umožňuje paralelné skenovanie.
Takže môžete v skutočnosti, dajte mi vedieť, koľko nite chcete spustiť na tom skenu.
A môžeme spustiť tieto závity.
Môžeme točiť, že skenovať hore naprieč viac vlákien
takže môžete skenovať celú tabuľku space veľmi, veľmi rýchlo DynamoDB.
>> Ďalší API máme, je to, čo nazývame Streams API.
Nebudeme hovoriť príliš veľa o tom práve teraz.
Mám nejaký obsah neskôr Na v balíčku o tom.
Ale prúdy je naozaj running-- myslieť na to, ako čas objednať
a zmena oddiel log.
Všetko, čo sa deje na V tabuľke sa objaví na prúde.
>> Každý zapísať do tabuľky sa objaví na prúde.
Môžete si prečítať tento prúd, a môžete robiť, čo s ním.
Porozprávame sa o tom, čo typy vecí,
činenia s vecami, ako sú replikácia, vznikajú sekundárne indexy.
Všetky druhy naozaj cool veci, ktoré môžete urobiť s tým.
>> Dátové typy.
V DynamoDB, podporujeme aj kľúč hodnota a dátové typy dokumentov.
Na ľavej strane obrazovky tu, máme naše základné typy.
Typy hodnoty kľúča.
Sú to reťazce, čísla a binárne súbory.
>> Takže len tri základné typy.
A potom môžete mať sady tie.
Jedna z pekné veci o NoSQL je môžete obsahovať pole ako vlastnosti.
A s DynamoDB môžete obsahovať pole základných typov ako koreňová vlastnosť.
>> A potom je tu typy dokumentov.
Koľko ľudí sú oboznámení s JSON?
Vy oboznámenie s JSON toľko?
Je to v podstate JavaScript Object, notácie.
To vám umožní v podstate definujú hierarchickú štruktúru.
>> Môžete uložiť dokument o JSON DynamoDB použitia bežných komponentov
alebo stavebné bloky, ktoré sú k dispozícii vo väčšine programovacích jazykoch.
Takže ak máte Javu, budete pri pohľade na mapách a zoznamy.
Môžem vytvoriť objekty, ktoré Mapa oblasti.
Mapa ako kľúčové hodnoty uložená ako vlastnosti.
A to by mohlo mať zoznamy hodnôt v rámci týchto vlastností.
Môžete ukladať tento komplex hierarchická štruktúra
ako jediný atribút z položky DynamoDB.
>> Takže tabuliek v DynamoDB, rovnako ako väčšina Databáza NoSQL, tabuľky majú položky.
V MongoDB by ste volanie týchto dokumentov.
A to by bol gauč základňa.
Tiež dokument databázy.
Zavoláte týchto dokumentov.
Dokumenty alebo položky majú atribúty.
Atribúty môžu existovať alebo neexistuje na položku.
V DynamoDB, je tu jedným povinný atribút.
Rovnako ako v relačnej databáze, máte primárny kľúč na stole.
>> DynamoDB má to, čo nazývame hash kľúč.
Hash kľúč musí byť jedinečný.
Takže keď som definovať hash tabuľky, v podstate to, čo hovorím
je každá položka bude mať hash kľúč.
A každý krížikom musí byť jedinečný.
>> Každá položka je definovaná touto unikátnou krížik.
A tam môže byť len jeden.
To je v poriadku, ale častokrát to, čo ľudia potrebujú
je chcú, je to hash Kľúčom k tomu trochu viac
než byť len jedinečný identifikátor.
Často chceme použiť tento hash kľúč ako najvyššej úrovne agregácie vedra.
A spôsob, ako to urobiť, je tým, pridávanie hovoríme rozsah kľúč.
>> Takže ak je to len hash stôl, musí to byť jedinečná.
Pokiaľ sa jedná o hash a rozsah tabuľky sa kombinácia hash a rozsah
musí byť jedinečný.
Takže myslíte, že o tom týmto spôsobom.
Ak mám fórum.
A forma má tém, má stĺpiky, a to má odpovede.
>> Takže som mohol mať hash kľúč, čo je téma ID.
A ja mohla mať rozsah kľúč, čo je ID odpoveď.
Tak, keď chcem, aby si všetky odpovede na určitú tému,
Môžem len dotaz hash.
Môžem len povedať, daj mi všetky položky, ktoré majú túto hash.
A budem sa dostať na každú otázku alebo poštou na túto konkrétnu tému.
Tieto špičkové úrovne agregácie sú veľmi dôležité.
Podporujú primárny prístup vzor žiadosti.
Všeobecne povedané, toto je to, čo chceme robiť.
Chceme, aby table-- ako si nahrať tabuľku,
chceme štruktúrovať dáta v tabuľke tak,
že aplikácia môže veľmi rýchlo získať tieto výsledky.
A často spôsob, ako to urobiť, je udržiavať tieto agregáciou ako my
vložiť dáta.
V podstate sme šírenia dát do jasného vedra, ako to prichádza v.
>> Rozsah tlačidlá umožňujú me-- hash Klávesy majú byť rovnosť.
Keď som dotazu hash, musím povedať, daj mi hash, ktorá sa rovná toto.
Keď som dotaz rozsah, ja Dá sa povedať, daj mi rozsah
že je použitie akejkoľvek bohatý subjekt, ktorý podporujeme.
Daj mi všetky položky pre hash.
Je to rovnaké, väčšie ako, menej ako, to začína,
to existujú medzi týmito dvoma hodnotami?
Takže tieto typy rozsahu otázok že máme vždy zaujíma.
A teraz jedna vec, o dátumoch, kedy sa pozriete na prístup k dátam, kedy
máte prístup k dátam, je to Vždy ide o agregáciu.
Je to vždy o záznamoch ktoré sa vzťahujú k tejto.
Dajte mi tu všetko that's-- všetky transakcie na tejto kreditnej karty
za posledný mesiac.
To je agregácie.
>> Takmer všetko, čo robíte v Databáza je nejaký druh agregácie.
Tak budú môcť byť schopní definovať Tieto vedierka a dá vám tieto rozsah
atribúty, aby bolo možné na dotaz na, tie bohaté otázok podporuje veľa,
mnoho, mnoho prístup k aplikáciám vzory.
>> Takže ďalšia vec, s krížikom robí je, že nám dáva mechanizmus
aby bolo možné rozšíriť dáta okolo.
Databáza NoSQL fungujú najlepšie keď sú dáta rovnomerne
distribuovaná po klastra.
Koľko ľudí pozná s algoritmy hash?
Keď poviem, že hash a hashing-- pretože je algoritmus hash
je spôsob, ako byť schopný generovať náhodná hodnota z akejkoľvek danej hodnoty.
Takže v tomto konkrétnom prípade hashovacie algoritmus prevádzkujeme je ND 5 na základe.
>> A ak mám ID, a to je môj krížikom, mám 1, 2, 3.
Keď spustím hash algoritmu, to bude, aby sa vrátil a povedal,
dobre 1 rovná 7B, 2 sa rovná 48, 3 sa rovná CD.
Sú rozšírili do celého kľúča priestoru.
A prečo to robíte?
Vzhľadom na to, že zabezpečí, že môžem dal záznamy cez viac uzlov.
>> Ak by som to robím postupne, 1, 2, 3.
A mám hash rozsah, ktorý prebieha v tomto konkrétnom prípade,
malý hash priestor, beží od 00 do FF,
potom záznamy sa chystáte prísť a oni sa chystáte ísť 1, 2, 3, 4, 5,
6, 7, 8, 9, 10, 11, 12.
Čo sa deje?
Každá vložka bude rovnakom uzla.
Vieš, čo tým myslím?
>> Pretože keď som sa rozdeliť priestor, a ja sa šíri cez tieto záznamy,
a oddiel ja, ja som chcel povedať, oddiel 1 má kľúčový priestor, 0 až 54.
Oddiel 2 je 55 až 89.
Oddiel 3 AA až FF.
Takže keď som pomocou lineárne zvyšovanie ID, môžete vidieť, čo sa deje.
1, 2, 3, 4, 5, 6, všetko až po 54.
Takže ako som zatĺkať záznamy do systému,
všetko skončí ísť do jedného uzla.
>> To nie je dobré.
To je antipattern.
V MongoDB majú tento problém ak nechcete použiť hash kľúč.
MongoDB vám dáva možnosť z hash hodnotu kľúča.
Vždy by ste mali urobiť, ak vy používate incrementing hash
Zadajte MongoDB, alebo budete pribil každý zápis do jedného uzla,
a budete obmedzujúce Váš zápis priepustnosť zle.
>> Divákov: Je to A9 169 v desiatkovej sústave?
>> RICK Houlihan: Jo, to je niekde okolo tam.
A9, ja neviem.
Musel by ste, aby mi binárne na desatinné kalkulačka.
Môj mozog nefunguje takto.
Divákov: Len rýchly jedným Vaše pripomienky Mongo.
Tak je objekt, ID, ktorý je dodávaný natívne s Mongo robiť, že?
RICK Houlihan: Má to urobiť?
Ak ho špecifikovať.
S MongoDB, máte možnosť.
Môžete specify-- každý dokument v MongoDB musí mať podčiarnik ID.
To je unikátny hodnota.
>> V MongoDB môžete zadať či hash, alebo nie.
Proste vám možnosť.
Ak viete, že je to náhodný, žiadny problém.
Nemusíte to robiť.
Ak viete, že to nie je náhodné, že to postupne, potom to hash.
>> Teraz vec, o zatrieďovanie, akonáhle sa hash
value-- a to je Prečo hash kľúče sú vždy
unikátnych otázok, pretože som sa zmenil je hodnota, teraz nemôžem urobiť dotaz rozsahu.
Nemôžem povedať, že je to medzi to či ono,
pretože hodnota hash nebude sa rovná skutočnej hodnoty.
Takže keď hash, že kľúč, je to len rovnosť.
To je dôvod, prečo v DynamoDB krížik otázky sú vždy len rovnosť.
>> Takže teraz v rozmedzí key-- keď som sa dodať, že rozsah kľúč,
tieto záznamy dôležité spektrum všetci prísť a oni sa ukladajú na rovnaký oddiel.
Tak oni sú veľmi rýchlo, ľahko načítať, pretože to je hash,
to je rad.
A vidíte všetko s rovnakou hash
je uložená na rovnakom oddielu priestoru.
Môžete použiť tento rozsah kľúč pomôcť lokalizovať dáta v blízkosti jeho rodičia.
Tak čo mám vlastne tu robíš?
To je jedným mnohých vzťahu.
Vzťah medzi krížik a rozsah kľúč je, kto veľa.
Môžem mať viac hash kľúčov.
Môžem mať len viac rozsah kľúče v každej krížik.
>> Hash definuje rodičia, rozsah definuje deti.
Takže môžete vidieť, že je analógový tu medzi relačné konštruktu
a rovnaké typy konštrukty v NoSQL.
Ľudia hovoria o NoSQL ako Nonrelational.
Nie je to Nonrelational.
Údaje má vždy vzťahy.
Tieto vzťahy len sú modelované inak.
Poďme hovoriť trochu niečo o trvanlivosť.
Pri písaní sa DynamoDB, píše sú vždy trojcestný replikované.
To znamená, že máme tri AZ je.
AZ to sú voľné zóny.
Môžete myslieť na dostupnosť Zone ako dátové centrum
alebo súbor dátových centier.
Tieto veci sú geograficky izolované od seba navzájom
naprieč rôznymi zlomové, naprieč odlišný rozvodnej siete a záplavových oblastí.
Zlyhanie v jednej AZ nie je bude trvať dole ďalšie.
Oni sú tiež spojené spolu s tmavým vláknom.
To podporuje jeden sub 1 milisekunda oneskorenie medzi AZS.
Takže dáta replikácie v reálnom čase schopné v bytových AZS.
>> A často multi nasadenie AZ spĺňali požiadavky na vysokú dostupnosť
väčšiny podnikových organizácií.
Takže DynamoDB sa šíri v troch AZS v predvolenom nastavení.
Budeme len k poznaniu Write keď sa dva z týchto troch uzlov vráti
a hovoria, Jo, mám to.
Prečo tomu tak je?
Vzhľadom k tomu, na čítanie stranu sme len dám vám dáta späť, ak
sme ho dostať z dvoch uzlov.
>> Ak som replikácie naprieč tri, a čítam z dvoch,
Ja som vždy zaručená mať aspoň jeden
z nich číta, že je Najaktuálnejšie kópie dát.
To je to, čo robí DynamoDB konzistentné.
Teraz si môžete vybrať otočiť tie konzistentné číta off.
V tom prípade budem hovoriť, Budem čítať iba z jedného uzla.
A nemôžem zaručiť, aby to bude byť najviac aktuálne dáta.
>> Takže ak write prichádza, to nebola replikované doteraz,
budete sa dostať, že kópia.
To je nakoniec konzistentné čítanie.
A čo to je, je polovicu nákladov.
Takže to je o čom premýšľať.
Keď čítate von DynamoDB, a je nastavovanie čítanie kapacity
jednotiek, ak sa rozhodnete nakoniec konzistentné číta, je to oveľa lacnejšie,
je to o polovicu nákladov.
>> A tak sa ušetrí peniaze.
Ale to je vaša voľba.
Ak chcete, konzistentné čítanie alebo nakoniec konzistentné čítanie.
To je niečo, čo si môžete vybrať.
>> Poďme sa baviť o indexoch.
Tak sme sa zmienili, že najvyššej úrovne agregácie.
Máme hash kľúče, a máme rozsah kľúče.
To je pekné.
A to je na primárnej tabuľky, ja má jedno krížikom, mám jeden rozsah kľúč.
>> Čo to znamená?
Mám jeden atribút, že som môže bežať bohaté otázky proti.
Je to rozsah kľúč.
Ostatné atribúty na tej item-- Môžem filtrovať na tých atribútoch.
Ale nemôžem robiť veci ako, to začína, alebo je väčšia ako.
>> Ako to mám urobiť?
Aj vytvoriť index.
Sú dva typy indexy v DynamoDB.
Index je naozaj Iný pohľad na tabuľky.
A miestne sekundárne index.
>> Prvý z nich budeme hovoriť.
Takže miestne pobočníci sa koexistovali na rovnakom oddielu ako dáta.
A ako také, sú na rovnaké fyzikálne uzol.
Oni sú to, čo nazývame konzistentné.
Význam, budú uznávať zápisu spolu s tabuľkou.
Pri zápise príde, budeme písať cez index.
Budeme písať až k stolu, a potom budeme potvrdiť.
Tak to je konzistentné.
Akonáhle je zápis bol uznala od stola,
je zaručené, že miestna sekundárne index
bude mať rovnakú víziu dát.
Ale to, čo vám umožní urobiť, je definovať alternatívne kľúče rozsah.
>> Musia používať rovnaký hash key ako primárny tabuľke,
preto, že sú umiestnené na rovnakom mieste na rovnaký oddiel, a sú konzistentné.
Ale môžem vytvoriť index s rôznymi kľúčmi dosahu.
Tak napríklad, ak som mal výrobca že mal časti tabuľky surové prichádzať.
A RAW diely dodávame v a oni sú agregované zostavou.
A možno je tu odvolanie.
>> Každá časť, ktorá bola vyrobená týmto Výrobca po tomto dátume,
Musím vytiahnuť z môjho linky.
Dokážem točiť index že bude hľadať,
agregáciu dňom Výroba tejto konkrétnej časti.
Takže ak môj stôl najvyššiu úroveň bola už klasifikované podľa výrobcu,
Možno to bolo usporiadané na čiastočný ID, ja Môžete vytvoriť index off tejto tabuľke
ako hash výrobcu a pohybovala na dáta výroby.
A takto by som mohol povedať, že čokoľvek bol vyrobený medzi týmito dátami,
Musím vytiahnuť z linky.
Tak to je miestna sekundárne index.
>> Tie majú za následok obmedziť svoju kľúčovú priestor hash.
Vzhľadom k tomu, že koexistovali na rovnakej úložné uzla,
obmedzujú s krížikom priestor na 10 GB.
DynamoDB, pod stoly, sa rozdelí
Váš stôl každých 10 gigabajtov.
Keď dáte 10 koncerty dát v, my go [PHH], a my sme pridať ďalšie uzol.
>> Nebudeme rozdeliť LSI cez viac oddielov.
Budeme rozdeliť tabuľku.
Ale nebudeme rozdeliť LSI.
Tak to je niečo, dôležité pochopiť
je, ak robíte veľa, veľmi, veľmi veľké zhluky,
potom ste bude obmedzený 10 GB na vašom LSIS.
>> Ak tomu tak je, môžeme použiť globálne Sekundárne.
Globálne secondaries sú Naozaj iné tabuľky.
Existujú úplne preč strana primárnej tabuľky.
A dovoľte mi, aby som nájsť úplne odlišná štruktúra.
Takže myslíte, že na to, ako sa vkladá údaje do dvoch rôznych tabuliek, štruktúrované
dvoma rôznymi spôsobmi.
>> Môžem definovať úplne iný krížikom.
Môžem definovať úplne iný kľúč rozsah.
A môžem bežať to úplne nezávisle na sebe.
Ako v skutočnosti, som dotovaný mojej čítanie kapacity
a písať kapacity pre moju globálne sekundárne indexy
úplne nezávisle môj primárny tabuľky.
Keby som ustanovujú tento index, poviem to, ako moc čítať a písať
Kapacita to bude používať.
>> A to je samostatná z môjho primárnej tabuľky.
Teraz obaja indexy nám umožňujú nielen definovať hash a rozsah kláves,
ale oni nám umožňujú premietať ďalšie hodnoty.
Takže ak chcem odpočítajte index, a chcem získať nejaké sadu dát,
Nepotrebujem sa vrátiť do hlavného Tabuľka získať ďalšie atribúty.
Aj môže premietať tie ďalšie atribútov do tabuľky
podporovať prístup vzor.
Viem, že sme asi dostať do niektorých Naozaj, really-- dostať do burinu
tu na niektoré z týchto vecí.
Teraz mám sa nechať unášať z toho.
>> Divákov: [Nepočuteľné] --table kľúč znamenalo, hash?
Pôvodný hash?
Multi-lamely?
>> RICK Houlihan: Áno.
Áno.
Tabuľka kľúč v podstate poukazuje späť do položky.
Tak že index je ukazovateľ späť do pôvodnej položky na stole.
Teraz si môžete vybrať vybudovať index, ktorý má len tabuľku kľúč,
a žiadne iné vlastnosti.
A prečo by som to robil?
No, možno mám veľmi veľké položky.
>> Naozaj len potrebujem vedieť which-- môj prístup vzor by sa povedať,
položky, ktoré obsahujú túto nehnuteľnosť?
Nepotrebujete vrátiť položku.
Proste potrebujem vedieť, položky, ktoré obsahujú to.
Takže si môžete vytvoriť indexy ktoré majú len tabuľku kľúč.
>> Ale to je v prvom rade to, čo index v databáze je pre.
Je to, že sú schopné rýchlo určiť, ktoré zaznamenáva,
ktoré riadky, ktoré položky v tabuľke majú
vlastnosti, ktoré som hľadali.
>> GSIS, tak ako fungujú?
GSIS v podstate sú asynchrónne.
Aktualizácia prichádza do tabuľky, Tabuľka je potom asynchrónne aktualizovaný
všetky vaše GSIS.
To je dôvod, prečo sú GSIS nakoniec konzistentné.
>> Je dôležité poznamenať, že keď staviate GSIS,
a pochopíte, budete vytvárať ďalší rozmer aggregation--
Teraz povedzme, že dobrý príklad Tu je výrobca.
Myslím, že by som mohol mať hovoril o lekárske výrobcu zariadenia.
Výrobcovia Lekárske zariadenia častokrát majú Serializovaná časti.
Časti, ktoré idú do náhradné hip všetko
mať trochu sériové číslo na ne.
A oni mohli mať milióny a milióny a miliardy dielov
vo všetkých zariadeniach, ktoré sa loď.
No, oni potrebujú k agregáciu v rámci rôzne rozmery, všetky diely
v zostave, akékoľvek diely, ktoré boli vykonané
na určité línie, všetko časti, ktoré prišli
v od určitého výrobcu k určitému dátumu.
A tieto zhluky niekedy dostať až do miliárd.
>> Tak som sa pracovať s niektorými z títo ľudia, ktorí trpia
pretože sú vytváranie Tieto GINORMOUS agregácie
v ich sekundárnych indexov.
Môžu mať surové diely stôl, ktorý je dodávaný iba ako hash.
Každá časť má unikátne sériové číslo.
Ja používam sériové číslo ako hash.
Je to krásne.
Môj surové dáta tabuľky sa rozprestiera po celej kľúča priestoru.
My [? napísať?] [? Požitie?] Je úžasné.
Beriem veľké množstvo dát.
Potom to, čo robia, je, že vytvorí GSI.
A ja hovorím, vieš čo, musím vidieť Všetky diely pre tohto výrobcu.
No, zrazu som si pričom miliardy riadkov,
a tak je na jeden uzol, pretože keď
Aj agregovať ako Výrobca ID ako hash,
a číslo dielu ako oblasť, potom všetci naraz, že som
uvedenie miliardy diely do čoho Tento výrobca ma doručená.
>> To môže spôsobiť veľa tlaku na GSI,
znova, pretože som príklepom jeden uzol.
Dávam všetky tieto vloží do jedného uzla.
A to je skutočný problematický prípad použitia.
Teraz som dostal dobrý dizajn vzor pre to, ako sa vyhnúť to.
A to je jeden z problémov že som vždy pracovať.
Ale čo sa stane, je GSI môže Nie je dostatok zápisu kapacity
aby bolo možné posunúť všetky tie riadkov do jedného uzla.
A čo sa stane, potom je primárne, klient tabuľka,
primárnej tabuľke bude škrtil pretože GSI nemôže držať krok.
Takže môj vložka sadzba spadnúť na primárnej tabuľky
ako môj GSI snaží držať krok.
>> Dobre, takže GSI je, LSI je, ktorý z nich by som mal použiť?
LSI je byť konzistentné.
GSI to sú nakoniec konzistentné.
Ak to je v poriadku, odporúčam pomocou GSI, sú oveľa flexibilnejšie.
LSI môže byť modelovaná ako GSI.
A v prípade, že veľkosť dát na hash kľúčov vaša zbierka prekročí 10 gigabajtov,
potom budete chcieť použiť, že GSI, pretože je to len pevný limit.
>> Dobre, takže škálovanie.
Výkon v Dynamo DB, vy ustanovenia môže [nepočuteľných]
priepustnosť do tabuľky.
Máme zákazníkov, ktorí majú dotovaný 60 billion--
robia 60 miliárd žiadostí, pravidelne beží na viac ako milión žiadostí
za sekundu na našich stoloch.
To fakt nie je teoretický limit, koľko
a ako rýchlo sa tabuľka je možné spustiť v Dynamo DB.
Tam sú niektoré mäkké limity na vašom účte
že sme dali tam tak že nemusíte zblázniť.
Ak chcete viac ako že, nie je problém.
Prišiel si povedzte nám.
Budeme zase až voličom.
>> Každý účet je obmedzená na určitej úrovni v každej službe, len kúsok od netopiera
takže ľudia nemajú zblázniť dostať sa do problémov.
Žiadny limit veľkosti.
Môžete dať ľubovoľný počet položiek na stole.
Veľkosť položky je obmedzená na 400 kB každý,
ktoré by boli položka sa atribúty.
Takže súčet všetkých atribútov je obmedzená na 400 kB.
A potom znova, máme ten malý LSI otázka
s 10 GB limitu na hash.
Publikum: malý počet, mi chýba to, čo mi hovoríte, že je--
Publikum: Oh, 400kb je maximálna veľkosť za položku.
Takže položka má všetky atribúty.
Takže 400 k je celková veľkosť tejto položky, 400 kilobajtov.
Takže zo všetkých atribútov kombinované, všetky údaje
to je vo všetkých tých atribútoch, zrolované do celkovej veľkosti,
V súčasnej dobe dnes limit položka 400 k.
Takže znovu mierky, dosiahol cez rozdelenie.
Priepustnosť je dotovaný na úrovni tabuľky.
A je to naozaj dva gombíky.
Čítali sme kapacitu a písať kapacity.
>> To sú teda upravené nezávisle na sebe.
RCU meradlom prísne v súlade číta.
OK, takže ak ste hovoril chcem 1000 RCU to tie sú prísne konzistentné,
tie sú v súlade číta.
Keď poviete, chcem Eventuálne konzistentné číta,
môžete ustanovenia 1000 RCU je, budete
dostať 2.000 nakoniec konzistentné číta.
A polovičnú cenu pre tých, nakoniec spočíva v číta.
>> Opäť platí, upravené nezávisle na sebe.
A oni majú throughput-- Ak budete konzumovať 100% svojej diaľkovom ovládači,
vy nebudete mať dopad na dostupnosť vašich práv.
Takže sú úplne nezávisle na sebe.
Dobre, takže jedna z vecí, ktoré Zmienil som sa krátko bol škrtenia.
Škrtenia je zlé.
Škrtenia označuje zlý žiadne SQL.
Tam sú veci, ktoré môžeme urobiť, aby pomohla ste zmierniť škrtenia, ktoré vás
zažívajú.
Ale najlepším riešením je to, poďme
Pozrite sa na to, čo robíte, pretože tam je anti-vzor v hre tu.
>> Tieto veci, veci, ako je non-uniforme záťaže, horúce klávesy, horúce priečky.
Som biť konkrétny kľúčový priestor veľmi ťažké pre nejakého konkrétneho dôvodu.
Prečo to robím?
Poďme zistiť, že von.
Ja som miešanie mojej horúce dáta s dátami za studena.
Nechávam mojej tabuľky dostať obrovský, ale je to naozaj
iba niektoré podmnožinu dát to je naozaj pre mňa zaujímavé.
Takže pre dát protokolu, napríklad, veľa Zákazníci, dostanú dáta protokolu každý deň.
Majú obrovské množstvo dát protokolu.
>> Ak ste práve dumping všetkých, ktorí sa prihlasujú Dáta do jedného veľkého stola, v priebehu času
že tabuľka sa dostane masívne.
Ale ja som naozaj zaujíma len posledných 24 hodín, posledných sedem dní,
počas posledných 30 dní.
Bez ohľadu na časové okno že mám záujem pri hľadaní
Pre prípad, že mi vadí, alebo udalosť, ktorá je pre mňa zaujímavé,
to je jediná doba, okno, ktoré potrebujem.
Tak prečo som dávať 10 rokov v hodnote dát protokolu v tabuľke?
To, čo spôsobuje, že je tabuľka fragment.
>> To dostane obrovský.
To začne sa šíriť von cez tisícov uzlov.
A od tej doby svojej funkcii je tak nízka, že ste
v skutočnosti obmedzenie rýchlosti na každom jeden z týchto jednotlivých uzlov.
Takže poďme začať hľadať na to, ako máme vrátiť túto tabuľku cez.
Ako sa nám podarí, aby údaje o niečo lepšie sa vyhnúť týmto problémom.
A čo to vyzerá?
To je, čo to vyzerá.
To je to, čo zlé, NoSQL vyzerá.
>> Mám horúcu kláves tu.
Ak sa pozriete na strane tu, to všetko sú moje oddiely.
Dostal som 16 oddielov sem na tento konkrétny databázy.
Robíme to po celú dobu.
Bežím to pre zákazníkov všetkých čias.
Volá sa teplo mapa.
Teplo mapu mi hovorí, ako ste prístupu k kľúč priestor.
A čo to mi hovorí, je že tam je jeden konkrétny hash
že tento človek má rád strašne moc, pretože je
biť to naozaj, naozaj ťažké.
>> Takže modrá je pekná.
Máme radi modrú.
Nemáme radi červené.
Red, kde je tlak dostane až do výšky 100%.
100%, teraz si bude škrtil.
Takže kedykoľvek budete vidieť žiadne červené čiary, ako je tohle--, a nie je to len Dynamo DB--
každá databáza NoSQL má tento problém.
Tam sú anti-vzory, ktoré môžu riadiť tieto typy podmienok.
Čo mám robiť, je, že som pracovať so zákazníkmi pre zmiernenie týchto podmienok.
>> A čo to vyzerá?
A to už je čo najviac z Dynamo DB priepustnosti,
ale je to naozaj dostať najviac z NoSQL.
To sa neobmedzuje iba na Dynamo.
To je definitely-- I pracoval v Mongo.
Som oboznámený s mnohými NoSQL platformách.
Každý, kto má tieto typy horúce kľúčových problémov.
Ak chcete získať čo najviac z akéhokoľvek NoSQL databázy, konkrétne Dynamo DB,
Ak chcete vytvoriť tabuľky kde hash kľúčovým prvkom má
veľké množstvo odlišných hodnôt, vysoký stupeň mohutnosť.
Pretože to znamená, že píšem na mnohých rôznych vedierka.
>> Čím viac som vedierka písomne, tým väčšia je pravdepodobnosť
Som šíriť túto záťaž zápisu alebo čítať zaťaženie sa cez viac uzlov,
tým je pravdepodobnejšie, som mať vysoký výkon na stole.
A potom chcem hodnoty, aby požiadala celkom rovnomerne v priebehu času
a jednotne náhodne ako je to možné.
No, to je celkom zaujímavé, pretože nemôžem
Ovládanie keď používatelia prídu.
Takže stačí povedať, ak budeme šíriť veci sa cez kľúča priestoru,
budeme pravdepodobne v lepšej forme.
>> Je tu určitá Množstvo čase dodania
že nejdeš Aby bolo možné kontrolu.
Ale to sú naozaj dva rozmery, ktoré máme,
priestor, prístup rovnomerne šírenie, čas, žiadosti
ktorí prichádzajú rovnomerne rozložené v čase.
A ak tí dvaja sú splnené podmienky,
potom je to to, čo to je vyzerať.
To je oveľa krajší.
Sme tu naozaj šťastný.
Máme veľmi rovnaký prístup vzor.
Jo, možno ste stále malý tlak tu a tam,
ale nič naozaj príliš rozsiahle.
Takže je to úžasné, koľkokrát, keď som sa pracovať so zákazníkmi,
že ako prvý graf s veľkým červeným bar a všetko, čo škaredé žltej je to
všade, sme si urobil s výkonom
po niekoľkých mesiacoch spätného architektúry,
Utekajú presne rovnaké pracovná záťaž na presne rovnakú záťažou.
A to je to, čo vyzerá to ako teraz.
Takže to, čo dostanete s NoSQL je Dáta schémy, ktorý je úplne
viazaná na vzorku prístup.
>> A môžete optimalizovať, že dáta schéma na podporu tohto prístupu vzor.
Ak nie, potom budete vidieť tie druhy problémov
s týmito horúcich kláves.
>> Divákov: No, nevyhnutne niektoré miesta sa bude teplejšie ako ostatné.
>> RICK Houlihan: Vždy.
Vždycky.
Jo, myslím, že je vždy je-- a znova, je tu
niektoré návrhové vzory sa dostaneme cez ktorý bude hovoriť o tom, ako sa vysporiadať
s týmito extra veľkými agregácie.
Myslím, že musím mať je, ako sme sa s nimi vysporiadať?
Mám celkom dobrý prípad použitia že budeme hovoriť o za to.
>> V poriadku, takže poďme hovoriť asi niektorí teraz zákazníci.
Títo chlapi sú AdRoll.
Ja neviem, či ste oboznámení s AdRoll.
Pravdepodobne ste vidieť veľa na prehliadači.
Sú ad re-targeting, sú najväčšie obchodné ad re-zacielenie
tam vonku.
Obvykle pravidelne prejsť 60 miliárd transakcií za deň.
Robia cez milión transakcií za sekundu.
Majú tam celkom jednoduchú tabuľku štruktúra, najrušnejšie tabuľky.
Je to v podstate len krížikom je cookie,
rozsah je demografický kategórie, a potom
Tretia atribút je skóre.
>> Takže máme všetci cookies náš prehliadač od týchto chalanov.
A keď idete na účasť obchodníka,
Oni v podstate skóre vás naprieč rôzne demografické kategórie.
Keď idete na webové stránky a Hovoríte, že chcete vidieť túto ad--
alebo v podstate nemusíte hovoriť that-- ale keď idete na webových stránkach
hovoria, že chcete vidieť túto reklamu.
A oni idú dostať, že reklama AdRoll.
AdRoll vás pozrie sa na ich stolu.
Zistí, že je váš cookie.
Inzerenti rozprávanie im, chcem niekoho
kto je v strednom veku, 40-ročný muž, do športu.
A oni skóre vás v tých demografii a oni sa rozhodnú, či
že je to dobrý reklama pre vás.
>> Teraz majú SLA s ich poskytovateľov reklamné
poskytovať sub-10 milisekúnd Odozva na jednotlivých vyžiadanie.
Takže oni používate Dynamo DB pre toto.
Oni nás biť milión požiadaviek za sekundu.
Sú schopní robiť všetky svoje číselníkov, triedenie všetko údaje,
a dostať, že doplnok odkaz späť na ktorý inzerenta za menej ako 10 milisekúnd.
Je to naozaj celkom fenomenálne implementácia, ktoré majú.
>> Títo chalani actually-- sú tí chlapi.
Nie som si istý, či je to tých chlapov.
Môže byť týchto ľudí.
V podstate povedal us-- nie, ja si nemyslím, že to boli oni.
Myslím, že to bol niekto iný.
Pracoval som s zákazník, ktorý mi povedal,
že teraz, keď som šiel do Dynamo DB, sú
míňať viac peňazí na občerstvenie pre ich vývojový tím každý mesiac
než minú za svoje databázy.
Tak to ti dám Myšlienka úspor nákladov
že sa môžete dostať do Dynamo DB je obrovský.
Dobre, dropcam je iná spoločnosť.
Tieto chlap druh of-- ak si myslíte, internetového vecí, dropcam
je v podstate Internet Security videa.
Dáte svoj fotoaparát vonku.
Kamera má detektor pohybu.
Niekto príde, spúšťa štartovací bod.
Fotoaparát začne nahrávať na chvíľu až do nezistí žiadny pohyb ešte.
Kladie, že videá sa na internet.
>> Dropcam bola spoločnosť, ktorá je v podstate prešiel na Dynamo DB
pretože oni prežívali obrovské rastúce bolesti.
A to, čo nám povedali, Zrazu petabajtov dát.
Netušili, svoje služby by bol tak úspešný.
Viac ako YouTube video prichádzajúce je to, čo títo ľudia dostávajú.
Oni používajú DynamoDB sledovať všetky metadáta na všetkých svojich videa kľúčových bodoch.
>> Takže oni majú S3 vedierka, ktoré posúvajú Všetky binárne artefakty do.
A potom, že majú Dynamo DB záznamy, ktoré
poukazujú na tých ľudí, S3, tri objekty.
Keď sa treba pozrieť sa na video, oni vyhľadať záznam v Dynamo DB.
Oni kliknite na odkaz.
Oni strhnúť na video z S3.
Takže to je to trochu, ako to vyzerá.
A to je priamo z ich tímu.
>> Dynamo DB znižuje ich dodacia lehota pre video udalosti
od piatich do 10 sekúnd.
Vo svojom starom relačné obchode, oni používali musieť ísť a vykonať
viac zložité otázky k obrázku out, ktorá videa strhnúť,
do menej ako 50 milisekúnd.
Takže je to úžasné, úžasné, ako moc výkon
môžete získať, keď optimalizovať a ladíte podkladové databázy
podporovať prístup vzor.
Halfbrick, títo chlapci, čo to je, Fruit Ninja Myslím, že je ich vec.
Že všetky beží na Dynamo DB.
A títo ľudia, oni sú skvelý Vývojový tím, veľký rozvoj
obchod.
>> To nie je dobrý ops tím.
Nemali veľa prevádzkových prostriedkov.
Oni boli snaží sa snaží udržať ich aplikačnej infraštruktúry up
a beží.
Prišli k nám.
Pozerali sa na tomto Dynamo DB.
Hovorili, že je to pre nás.
Oni stavali ich celok aplikačný framework na to.
Niektoré naozaj pekné komentáre tu z tímu na ich schopnosti
sa teraz zameriavajú na budovanie hra a nie
nutnosti udržanie infraštruktúra, ktorá
stal sa obrovské množstvo réžia pre ich tím.
Takže to je niečo, čo that-- úžitok, že dostanete od Dynamo DB.
>> Dobre, ako sa dostať do modelovanie dát tu.
A hovorili sme trochu o to jedna ku jednej, kto veľa,
a mnoho mnoho vzťahov typu.
A ako si udržať tie v Dynamu.
V Dynamo DB používame indexy, všeobecne povedané,
k otáčaniu dáta z jednu príchuť do druhej.
Hash kľúče, rozsah kľúče a indexy.
>> V tomto konkrétnom Napríklad, ako je väčšine štátov
majú požiadavku licenciu, ktorá iba jeden vodičský preukaz na osobu.
Nemôžete ísť do dostať vodiča dvoch je licencií v štáte Bostone.
Nemôžem to urobiť v Texase.
Je to niečo, ako to je.
A tak na DMV, máme vyhľadávanie, my Chcete sa pozrieť na vodiča licenciu
počtom sociálneho zabezpečenia.
Chcem sa pozrieť do podrobnosti užívateľa licenčné číslo vodiča.
>> Takže by sme mohli mať tabuľku užívateľa, že Má hash kľúč na sériové číslo,
alebo číslo sociálneho zabezpečenia, a rôzne atribúty definované na položku.
Teraz na tejto tabuľke I by mohlo definovať, ktorý GSI
vyletí, že okolo toho hovorí, že chcem, hash kľúč na licenciu a potom
všetky ostatné položky.
A teraz, keď chcem, aby otázka a nájsť licenčné číslo pre danú sociálnu
Bezpečnostné číslo, môžem dotaz na hlavnej tabuľky.
>> Ak chcem, aby otázka a ja chcem dostať sociálneho zabezpečenia
číslo alebo iné atribúty tavnou licenčné číslo, môžem dotaz GSI.
Tento model je, že jeden do jedného vzťahu.
Len veľmi jednoduchý GSI, otočiť tie veci okolo seba.
Teraz, hovoriť o tom, kto veľa.
Jedným z mnohých je v zásade Váš hash rozsah kľúč.
Tam, kde sme si veľa s týmto use case sú dáta monitora.
Dáta Monitor je dodávaný v pravidelnej interval, ako je internet vecí.
Vždy sme si všetky tieto Záznamy prichádza po celú dobu.
>> A ja chcem nájsť všetky údaje medzi konkrétne časové obdobie.
Je to veľmi časté dotazu monitoring infraštruktúry.
Spôsob, akým ísť o to je nájsť jednoduchá štruktúra tabuľky, jedna tabuľka.
Mám tabuľku mier zariadení s krížikom na ID zariadenia.
A mám rozsah kľúč na strane timestamp, alebo v tomto prípade, epos.
A to mi umožňuje vykonávať zložité otázky voči ktoré siahajú kľúče
a vrátiť tie záznamy, ktoré sú vztiahnuté k výsledku
nastaviť, že som hľadal.
A to, že jeden buduje mnohých vzťah
do primárnej tabuľky pomocou krížikom, rozsah kľúčová štruktúra.
>> Takže to trochu postavený do tabuľky v Dynamo DB.
Keď som sa definovať hash a rozsah t stôl, ja som
definovanie jedného na mnohé vzťah.
Je to vzťah rodič-dieťa.
>> Poďme sa baviť o mnoho mnohých vzťahov.
A pre tento konkrétny príklad, znova, budeme používať GSI je.
A poďme hovoriť o hranie scenár, kde mám daného užívateľa.
Chcem zistiť všetky hry, ktoré on je zapísaná pre alebo hranie v.
A pre danú hru, ja Chcete nájsť všetkých užívateľov.
Tak ako to mám urobiť?
Môj užívateľský hry stôl, idem mať hash kľúč ID užívateľa
a rozsah kľúč hry.
>> Užívateľ teda môže mať viac hier.
Je to, kto mnohých vzťah medzi Používateľ a hry hrá.
A potom na GSI, Budem preklopiť, že okolo.
Budem hash na hru a Budem sa pohybujú na užívateľa.
Takže ak chcem, aby si všetky Hra používateľa hrá v,
Budem dotaz hlavnej tabuľky.
Ak chcem, aby si všetky užívateľa ktoré hrajú určitú hru,
Ja dotaz GSI.
Tak vidíte, ako to urobíme?
Staviate na podporu týchto GSI je prípad použitia, aplikácie, prístup
vzor, ​​žiadosť.
>> Ak je potreba, aby na dotaz táto dimenzia, nech
me vytvoriť index na tejto dimenzii.
Ak nemám, je mi to jedno.
A v závislosti na use case, ja môže potrebovať indexu, alebo ja tiež nie.
Ak je to jednoduchý pre mnohých, primárnej tabuľky je v poriadku.
Ak je potreba, aby sa tieto mnoho Veľa je, alebo musím urobiť jeden až tých,
potom možno Ja potrebujem na druhé miesto index.
Takže to všetko závisí na tom, čo sa snažím robiť
a to, čo sa snažím dostať dokonalý.
>> Asi nebudem tráviť moc veľa času hovorí o dokumentoch.
To dostane trochu, pravdepodobne, hlbšie, než musíme ísť do.
Hovorme trochu o bohatý výraz dotazu.
Takže Dynamo DB máme schopnosť vytvoriť
to, čomu hovoríme projekcie výrazy.
Projekčné výrazy sú jednoducho vyberanie poľa alebo hodnôt
ktoré chcete zobraziť.
OK, tak som urobiť výber.
Robím dotazu proti Dynamo DB.
A ja hovorím, vieš čo, show len mi päť hviezd recenzia
pre tento konkrétny výrobok.
Tak to je všetko, čo chcem vidieť.
Nechcem vidieť všetky ďalšie atribúty riadku,
Len chcem vidieť.
Je to ako v SQL, keď ste hovoria, vyberte hviezdy alebo z tabuľky,
dostanete všetko.
Keď hovorím, vyberte meno zo stôl, len som si jeden atribút.
Je to rovnaký druh veci v Dynamo DB alebo iný databáz NoSQL.
Filter výrazy mi dovoľte, aby som sa v podstate znížiť sadu výsledkov nadol.
Tak som sa, aby sa dotaz.
Dotaz môže vrátiť s 500 položkami.
Ale ja som len chcú, aby položky, ktoré majú atribút, ktorý hovorí, že tento.
OK, takže poďme odfiltrovať tie položky, ktoré sa nezhodujú, že konkrétne dotaz.
Takže máme výrazy filtra.
>> Filter výrazy môžu je možné spustiť na každom atribútu.
Sú to nebude páčiť rozsah otázky.
Vyvolávajú otázky sú viac selektívne.
Filter otázky vyžadujú, aby som šiel Získajte Kompletné výsledky nastaviť a potom
vybojovať dáta nechcem.
Prečo je to dôležité?
Vzhľadom k tomu, Čítal som to všetko.
V dotazu, budem čítať a že to bude obrovský o dátach.
A potom budem vybojovať čo potrebujem.
A keď ja som len vybojovať pár riadkov, potom je to v poriadku.
Nie je to tak neefektívne.
>> Ale keď som čítal celú hromadu Údaje, len aby vybojovať jednu položku,
Potom som sa chystám byť lepší vypnúť pomocou dotazu rozsah,
pretože je to oveľa vyberavejšie.
Bude to mi ušetriť veľa peniaze, pretože som za to zaplatiť čítanie.
V prípade, že výsledky, ktoré prichádza späť kríž, že drôt môže byť nižšia,
ale ja som platiť za čítanie.
Tak pochopiť, ako ste dostať dáta.
To je veľmi dôležité v Dynamo DB.
>> Podmienené výrazy, to je to, čo by sa dalo nazvať optimistické uzamykanie.
Aktualizáciu, ak existuje, alebo ak je táto hodnota je ekvivalentná tomu, čo som špecifikovať.
A keď mám časovú pečiatku na rekord, mohol by som čítať dáta.
I sa môže zmeniť, že dáta.
Mohol by som ísť písať, že dáta späť do databázy.
Ak niekto zmenil záznam, časovú pečiatku mohli zmeniť.
A takto môj podmienenej Aktualizácia by sa povedať aktualizácia
v prípade, že sa rovná tejto časovú pečiatku.
Alebo aktualizácie zlyhá, pretože niekto aktualizované záznam v medziobdobí.
>> To je to, čo nazývame optimistické uzamykanie.
To znamená, že niekto môže prísť a zmeniť to,
a budem detekovať keď som sa vrátiť do písať.
A potom som si skutočne čítal, že dát a hovoria, ach, on zmenil to.
Potrebujem účet za to.
A môžem zmeniť údaje v mojom nahrať a aplikovať ďalšiu aktualizáciu.
Takže si môžete chytiť tie prírastkové Aktualizácie, ktoré sa vyskytujú v čase medzi
že budete čítať dáta a Čas môžete zapísať dáta.
>> Divákov: A filter Výraz vlastne znamená nie
v počte alebo ne--
>> [Vložením hlasy]
RICK Houlihan: Nebudem príliš veľa na to.
To je rezervované kľúčové slovo.
Pohľad libra je vyhradené kľúčové slovo v Dynamo DB.
Každá databáza má svoje vlastné vyhradené Mená pre vymáhanie pohľadávok nemožno použiť.
Dynamo DB, ak zadáte libru pred touto,
môžete definovať tieto názvy hore.
Toto je odkazované hodnota.
Je to asi nie je najlepší syntax majú tam pre túto diskusiu,
preto, že sa dostane do niektorých real-- Bol by som hovoril viac
o, že na hlbšej úrovni.
>> Ale stačí povedať, mohlo by to byť dotaz skenovať, kde views--
ani názory libra je väčší ako 10.
Je to číselná hodnota, áno.
Ak chcete, môžeme hovoriť o že po diskusii.
Dobre, takže sa dostávame do niektoré scenáre v osvedčených postupoch
kam ideme hovoriť o niektorých aplikácií tu.
Aké sú prípady použitia pre Dynamo DB.
Aké sú konštrukcie vzory v Dynamo DB.
>> A prvý, kto budeme hovoriť o je internet vecí.
Tak sme si veľa of-- myslím, čo je to-- viac ako 50%
prevádzky na internete v týchto dňoch je skutočne vyrobenej pomocou strojov,
automatizované procesy, ktoré nie sú ľuďmi.
Mám na mysli túto vec túto vec, ktorá sa budete nosiť vo vrecku,
koľko dát, ktorá je tá vec vlastne posiela okolo bez teba
s vedomím, že je úplne úžasné.
Vaša poloha, informácie o tom, ako rýchlo sa budete.
Ako myslíš, že Google Maps diela keď tí, čo je prevádzka.
Je to preto, že tam sú milióny a milióny ľudí jazdí po
s telefónmi, ktoré sú odosielanie Údaje celé miesto po celú dobu.
Takže jedna z vecí o údaje tohto druhu
že príde, údaje prístroja, prihláste údaje, časové rady, je, že je
zvyčajne len zaujímavý na trochu času.
Po uplynutí tejto doby, to je nie je tak zaujímavé.
Tak sme hovorili o, nenechajte tieto tabuľky rast bez hraníc.
Myšlienka je, že možno mám 24 hodiny v hodnote udalostí v mojej horúcej tabuľke.
A to horúci tabuľka bude opravná položka vo veľmi vysokej rýchlosti,
pretože to trvá veľa dát.
Trvá to veľké množstvo dát a ja som to čítal veľa.
Mám veľa prevádzky Otázky spustené voči tejto dát.
>> Po 24 hodinách, hej, ty Vieš čo, je mi to jedno.
Takže možno každý Aj role polnoci môj stôl sa k novej tabuľky
a ja deprovision túto tabuľku.
A ja si vezmem RCU je a WCU je dole, pretože o 24 hodín neskôr
Nie som beží toľko otázky voči týmto údajom.
Takže budem sporiť.
A možno 30 dní neskôr, vôbec sa mi nepáči ani potreba sa starať o to všetko.
Mohol by som vziať WCU je celú cestu dole na jeden,
preto, že viete, čo je to nikdy dostať zapisovať.
Dáta sú 30 dní stará.
To sa nikdy nezmení.
>> A to takmer nikdy dostane čítať, tak nech to jednoducho prijať, že RCU až 10.
A Šetrím tony peňazí na to Dáta, a to len platiť za moje horúce dát.
Tak to je dôležité sa pozrieť u, keď sa pozriete na časové rady
Dáta prichádzať v objeme.
Sú to stratégie.
Teraz som mohol len nechať to všetci do jedného stola
a nechať že tabuľka rast.
Nakoniec budem pozri problémy s výkonom.
Budem musieť začať do archívu niektoré z týchto dát mimo stôl,
čo nie.
>> Poďme oveľa lepšie navrhnite aplikácii
takže môžete ovládať týmto spôsobom pravdu.
Takže je to len automatické v kóde aplikácie.
O polnoci každý večer to valí tabuľku.
Možno, že to, čo potrebujete, je posuvná Okno 24 hodín dát.
Potom sa pravidelne, že som volať dáta z tabuľky.
Som orezávanie to s Cronu a ja som ho uvedenia
na týchto iných tabuliek, čo budete potrebovať.
Takže ak prevrátenie funguje, to je skvelé.
Ak nie, trim to.
Ale poďme si tú horúci údaje od svojich chladných dát.
To vám ušetrí veľa peňazí a Urob si svoj tabuliek viac vedie.
Takže ďalšia vec, ktorú budeme hovoriť o tom, je katalóg výrobkov.
Katalóg je celkom obyčajný prípad použitia.
To je vlastne veľmi časté vzor že uvidíme v rade vecí.
Viete, pre Twitter Príkladom, horúci tweet.
Každý, kto príde a schmatol ten tweet.
Katalóg, mám predaja.
Dostal som horúci predaja.
Mám 70.000 žiadostí za druhý príchod pre výrobok
opis z môjho katalógu výrobkov.
Vidíme to na maloobchodnom Prevádzka celkom dosť.
Tak ako sme sa s tým vysporiadať?
Neexistuje žiadny spôsob, ako sa s tým vysporiadať.
Všetci moji užívatelia chcú vidieť rovnaký údaj.
Oni prichádzajú, súbežne.
A oni sú všetci robiť žiadosti za rovnaký kus dát.
To mi dáva, že horúce klávesy, že veľké červené pruh na mojom grafe, ktoré sa nám nepáči.
A to je to, čo to vyzerá.
Takže cez môj kľúčový priestor Dostávam kladivom v predaji položky.
Začínam nič nikde inde.
>> Ako mám tento problém zmierniť?
No, my zmierniť to s cache.
Cache, dáte v podstate v pamäti partition v prednej časti databázy.
Podarilo sa [Nepočuteľný] cache, ako vás
Môžete nastaviť vlastné cache, [nepočuteľných] medzipamäť [? d ,?], čo chcete.
Dať, že sa pred databázy.
A to spôsob, ako môžete ukladať, že dáta z týchto horúcich klávesov až v tejto pamäti cache
priestor a prečítajte si cache.
>> A potom s najväčšou vašich číta začať hľadať takhle.
Dostal som všetky tieto keše sem a ja nemám nič v ceste sem
pretože databáza je usadnutí za vyrovnávacej pamäte a číta sa nikdy prejsť.
Keď zmením údaje do systému databázy, musím aktualizovať vyrovnávaciu pamäť.
Môžeme použiť niečo ako par to urobiť.
A ja vám vysvetlím, ako to funguje.
Dobre, zasielanie správ.
E-mail, my všetci používať e-mail.
>> To je celkom dobrý príklad.
Máme nejaký správ tabuľky.
A my sme dostali doručenej pošty a Pošta na odoslanie.
To je to, čo by SQL vyzerať ako na stavať, že e-mailové schránky.
Sme trochu používajú rovnaký druh stratégie použiť GSI, GSI je
pre moje e-mailové schránky a môj Pošta na odoslanie.
Tak som sa dostal surové správy prichádzajúce do mojej správy tabuľky.
A prvý prístup k tejto by mohlo byť, povedzme, v poriadku, žiadny problém.
Mám surové správy.
Správy prichádzajúce [nepočuteľných], ID správy, to je skvelé.
To je môj unikátny hash.
Chystám sa vytvoriť dvoma GSI je, jeden pre moje e-mailové schránky, jeden pre moju Pošta na odoslanie.
A prvá vec, ktorú urobím je Poviem môj hash kľúč
Bude príjemca a Idem zariadiť dňom.
To je fantastické.
Ja tu mám pekný výhľad.
Ale je to trochu problém tu.
A sa dostanete do toho relačnej databázy rovnako.
Hovorili vertikálne delenie.
Chcete, aby sa vaše spracovanie veľkých objemov dát od svojich malých dát.
>> A dôvod, prečo je, pretože musím go čítať položky, ktoré chcete získať atribúty.
A ak moje telá sú všetci tu, potom číta len niekoľko položiek
keď moje telo je dĺžka v priemere 256 kilobajtov každý,
matematický dostane docela škaredý.
Takže povedať, že chcete prečítať Dávidov e-mailovej schránky.
Dávidova Doručená pošta má 50 položiek.
Priemerná a veľkosť je 256 kB.
Tu je môj konverzný pomer pre RCU je je štyri kilobajtov.
>> OK, poďme sa nakoniec konzistentné číta.
Som stále jesť 1600 RCU je len na čítanie Dávidov e-mailovej schránky.
Ouch.
OK, teraz poďme premýšľať o tom, ako aplikácia funguje.
Ak som v e-mailovej aplikácii a Pozerám sa na mojej e-mailovej schránky,
a ja sa na telo každej správy, Nie, ja som pri pohľade na zhrnutie.
Pozerám sa na iba hlavičky.
Takže poďme postaviť štruktúru tabuľky že vyzerá takto.
>> Tak tu je informácia že moje workflow potrebuje.
Je to v mojej e-mailovej schránky GSI.
Je to dátum, odosielateľ, predmet, a potom
ID správy, ktoré body späť k stolu správ
kde by som mohol dostať telo.
No, to by bolo rekordné ID.
Oni by ukazovať späť do položka ID na stole Dynamo DB.
Každý index vždy creates-- má vždy položku
ID ako súčasť of-- že prichádza s indexom.
>> Dobre.
Divákov: Je to o tom, kde je uložený?
RICK Houlihan: Áno, je to hovorí exactly--, že je to presne to, čo robí.
To hovorí, že tu je moja re rekord.
A to bude ukazovať ju späť do svojho opätovného záznamu.
Presne tak.
OK, tak teraz moja schránka v skutočnosti oveľa menší.
A to vlastne podporuje pracovného postupu z e-mailovej aplikácie.
Takže mojej e-mailovej schránky, som kliknite na tlačidlo.
Idem ďalej a ja kliknite na správu, to je, keď musím ísť pre telo,
pretože budem prejsť do iného pohľadu.
Takže ak si myslíte, že o type MVC mesta rámec, pohľad modelu regulátora.
>> Tento model obsahuje údaje, ktoré potrebuje pohľad
a regulátor interaguje s.
Keď som sa zmeniť rám, kedy Aj zmeniť perspektívu,
to je v poriadku sa vrátiť do Server a repopulate modelu,
pretože to je to, čo používateľ očakáva.
Keď sa zmení zobrazenie, to je, keď môžeme ísť späť do databázy.
Tak e-mail, kliknite na tlačidlo.
Hľadám pre telo.
Cesta tam a späť.
Choď telo.
>> Čítal som veľa menej dát.
Ja som len čítanie orgánov, ktoré David potrebuje, keď ich potrebuje.
A ja nie som horieť v roku 1600 RCU jednoducho ukázať svoje e-mailové schránky.
Takže teraz that-- je to spôsob, že LSI alebo GSI-- Je mi to ľúto,
GSI, bude fungovať.
Máme našu hash na príjemcu.
Máme rozsah kľúč na dátume.
A máme plánované atribúty že musíme len podporujú názor.
>> Otočíme, že pre odchádzajúcich správ.
Hash odosielateľa.
A v podstate, máme veľmi pekný, čistý výhľad.
A je to basically-- sme už túto príjemnú správy
tabuľka, ktorá sa šíri pekne, pretože je to len hash, hash ID správy.
A máme dva indexy, ktoré sa otáčajú z tejto tabuľky.
Dobre, takže myšlienka tu je nie uchovávať veľké dáta a tento malý údaje
spoločne.
Rozdeliť zvisle, rozdeliť tie tabuľky.
Nečítajte dáta, nemusíte.
Dobre, herné.
Všetci sme radi hry.
Aspoň sa mi páči hry potom.
Takže niektoré z vecí, že sa zaoberáme, keď
premýšľame o hranie, nie?
Herné týchto dňoch, a to najmä mobilné hranie hier, je o myslenie.
A budem otáčať tu trochu ďaleko od DynamoDB.
Idem, aby v niektoré z diskusie
okolo niektorých z iné technológie AWS.
>> Ale myšlienka o hranie je myslieť o čo sa týka API, API, ktoré sú,
Všeobecne povedané, HTTP a JSON.
Je to, ako mobilné hry druh komunikovať s ich zadnými konci.
Oni robia JSON vysielania.
Dostanú dát, a to je všetko, Všeobecne povedané, v peknom JSON API.
>> Veci ako získať priateľov, získať leaderboard, vymieňať dáta,
užívateľmi generovaný obsah, tlačiť späť do systému,
sa jedná o typy vecí že budeme robiť.
Binárne dáta aktív, tieto dáta nemusí sedieť v databáze.
To by mohlo sedieť vo objekt obchod, nie?
Ale databáza bude skončiť hovorí systému,
hovorí aplikácie kam ísť si to.
A nevyhnutne, multiplayer servery, back end infraštruktúry,
a určené pre vysoko dostupnosť a škálovateľnosť.
To sú veci, ktoré chceme všetci v hernom infraštruktúry dnes.
>> Takže poďme sa pozrieť na ako to vyzerá.
Mám základný zadný koniec, veľmi jednoduché.
Máme systém, tu sa viacnásobné dostupnosť zón.
Hovorili sme o AZS as being-- myslíte z nich ako samostatné dátových centier.
Viac ako jedna dátové centrá per AZ, ale to je v poriadku,
len myslieť na nich ako samostatný dát strediská, ktoré sú geograficky
a porucha izolované.
>> Budeme mať inštancie pár EC2.
Budeme mať niektorí back end servera.
Možno, ak ste starší architektúra, my sme
s použitím čo nazývame RDS, relačnej databázy služby.
Mohol by to byť MSSQL, MySQL, alebo niečo také.
To je spôsob, ako veľa aplikácií sú navrhnuté tak dnes.
>> Tak by sme mohli chcieť ísť s to je, keď sme škálovanie.
Budeme pokračovať a dať vedro S3 tam hore.
A to S3 lopaty, namiesto porcie up týchto objektov z našej servers--
sme mohli urobiť.
Dáte všetky vaše binárne objekty na vašich serveroch
a môžete použiť tie servera inštancie slúžiť, že dáta hore.
Ale to je dosť drahé.
>> Lepší spôsob, ako urobiť, je ísť dopredu a dať tieto objekty v S3 vedra.
S3 je objekt úložiska.
Je postavený špeciálne pre servírujú tieto typy vecí.
A nech títo klienti vyžiadať priamo z týchto objektov vedier,
zložiť servery.
Takže začíname mierka tu.
>> Teraz sme sa dostali užívateľov po celom svete.
Mám užívateľov.
Musím mať obsah lokálne sa nachádza v blízkosti týchto užívateľov, nie?
Vytvoril som S3 vedro ako môj zdrojový úložisko.
A ja budem vpredu, že s distribúcie CloudFront.
>> CloudFront je CD a content delivery network.
V podstate to znamená dáta, ktoré ste určili a ukladá to všetko cez internet
takže užívatelia môžu mať všade veľmi rýchla odozva pri
žiadajú o tieto objekty.
>> Tak dostanete nápad.
Ste typ pákového efektu všetky aspekty AWS sem si to urobiť.
A nakoniec, vyhodíme v skupine auto škálovanie.
Takže naše prípady AC2 našich herných serverov,
ako začnú dostať rušnejšie a bohatší a rušnejšie,
oni si len točiť ďalší inštancie, točiť ďalšie inštanciu,
točiť ďalšie inštanciu.
Takže technológia AWS má, ho umožňuje zadať parametre
okolo ktoré vaše servery budú rásť.
Takže môžete mať n počet serverov tam u nejakého daného času.
A ak váš náklad zmizne, oni budú zmenšovať, číslo sa bude zmenšovať.
A v prípade, že zaťaženie vráti, to bude pestovať späť, pružne.
>> Tak to vyzerá skvele.
Máme veľa inštancií EC2.
Môžeme dať cache front z databáz,
pokúsiť sa urýchliť databáz.
Budúci tlakový bod typicky ľudia vidia
je, že meradlo hru pomocou relačný databázový systém.
Ježišu, databázy výkon je hrozné.
Ako sa môžeme zlepšiť, že?
Skúsme uvedenie vyrovnávacej pamäti pred, že.
>> No, medzipamäte nefunguje tak skvelé hry, nie?
U hier, písanie je bolestivé.
Hry sú veľmi ťažké písať.
Cache nefunguje, keď ste napísať ťažké, pretože ste vždy
dostal k aktualizácii pamäte cache.
Aktualizovať vyrovnávacej pamäti, je to irelevantné, ktoré majú byť cache.
Je to vlastne len práca navyše.
>> Takže, kde sme ísť sem?
Máš veľkú zúženie tam dole v databáze.
A miesto, kam ísť samozrejme je rozdelenie.
Rozdelenie disku nie je ľahké robiť, keď ste
rokovania s relačnej databázy.
U relačných databáz, že ste Zodpovedajú za riadenie, efektívne,
kľúč priestor.
Hovoríte, že užívateľov medzi A a M ísť sem, medzi N a Z ísť tam.
A vy spínanie po aplikácii.
Takže máte čo do činenia s tento oddiel zdroj dát.
Máte transakčné obmedzenia ktoré nemajú span oddiely.
Máte všetky druhy neporiadok, že ste
zaoberajúca sa tam snažia vysporiadať sa s škálovanie out
a budovanie väčšej infraštruktúry.
Je to len žiadna sranda.
>> Divákov: Takže vravíte, že rastúcim zdrojom body urýchľuje
proces?
RICK Houlihan: Zvýšenie?
Divákov: Zdroj bodov.
RICK Houlihan: Zdroj body?
Divákov: Z informácií, kde sa informácia prichádza?
RICK Houlihan: Nie.
To, čo hovorím, je zvyšovanie počet oddielov v úložisku dát
zvyšuje výkon.
Takže to, čo sa tu deje, je užívatelia prichádzajúce do inštancie EC2 tu,
dobre, keď potrebujem užívateľa To je na M, pôjdem sem.
Od N k p, pôjdem sem.
Od P do Z, pôjdem sem.
>> Publikum: OK, ty, tak to sú všetky uložené v rôznych uzloch?
>> RICK Houlihan: Áno.
Myslite na to, ako rôzne silá dát.
Takže máte na to urobiť.
Ak sa snažíte urobiť, to, ak sa snažíte
meradle na relačné platforme, To je to, čo robíte.
Beriete dát a ste rezanie dole.
A vy oddielov to cez viac inštancií databázy.
A vy riadenie všetko, čo v aplikačnej vrstve.
Nie je to žiadna sranda.
Takže to, čo chceme ísť?
Chceme ísť DynamoDB, plne spravované, NoSQL úložisko dát, poskytovanie priepustnosť.
Využívame sekundárne indexy.
Je to v podstate HTTP API a zahŕňa podporu dokumentu.
Takže nemusíte mať strach približne ktorákoľvek hodnota z tohto delenia.
Robíme to všetko za vás.
Takže teraz, namiesto toho, budete stačí napísať do tabuľky.
Pokiaľ je treba tabuľku byť rozdelený, že sa deje v zákulisí.
Vy ste kompletne izolované z toho ako vývojár.
Tak poďme hovoriť o niektoré z prípadov použitia
že narazíme na v hraní, obyčajný herné scenáre, rebríčka.
Takže ste dostali užívatelia prichádza, sa BoardNames, že sú
na, skóre pre tohto používateľa.
Môžeme byť hashovanie na userid, a potom máme rad na hru.
Takže každý užívateľ chce vidieť všetko hra on hral
a všetky jeho najvyššie skóre naprieč všetkými hre.
Tak to je jeho osobný rebríčku.
>> Teraz chcem ísť a ja chcem, aby get-- tak som si tieto osobné rebríčkov.
To, čo chcem urobiť, je ísť dostať najvyššie skóre naprieč všetkými užívateľmi.
Tak ako to mám urobiť?
Keď je môj rekord zatriedená na ID užívateľa, sa pohybovala na hru,
dobre Chystám sa pokračovať a reštrukturalizovať, vytvoriť GSI,
a budem o reštrukturalizácii, že dáta.
>> Teraz budem k transformácii na BoardName, čo je hra.
A budem pohybovať na najvyššie skóre.
A teraz som vytvoril rôzne vedierka.
Ja som za použitia rovnakej tabuľky, rovnaké dáta položky.
Ale ja som vytvoriť vedierko, ktorý dáva me agregáciou najvyššie skóre zverou.
>> A môžem dotaz, ktorý tabuľku túto informáciu získať.
Tak som nastaviť, aby dotazu vzor až do byť podporené sekundárne indexu.
Teraz môžu byť radené podľa BoardName a zoradené podľa TopScore, v závislosti na.
Takže môžete vidieť, sú to typy z prípadov použitia sa dostanete do hry.
Ďalšia dobrá use case sme sa dostať do hry je ocenenie a kto vyhral ocenenie.
A je to skvelý prípad použitia kde hovoríme riedke indexy.
Riedke indexy sú schopnosť vytvárať
index, ktorý nie je nevyhnutne obsahovať každú položku na stole.
A prečo nie?
Vzhľadom k tomu, že to je atribút indexovaný neexistuje na každom kuse.
>> Takže v tomto konkrétnom prípad použitia, hovorím,
viete čo, budem vytvoriť atribút nazvaný Award.
A ja dám každému užívateľovi že má cenu, ktorá atribút.
Používatelia, ktorí nemajú ocenenia sú nebude mať tento atribút.
Takže keď som sa vytvoriť index, iba užívatelia
že ukážeme up v indexe sú
tie, ktoré skutočne získali ocenenia.
Takže je to skvelý spôsob, ako byť schopní vytvoriť filtrované indexy
sú veľmi, veľmi selektívne, že nie majú indexovať celú tabuľku.
>> Takže my sme stále málo času.
Chystám sa ísť dopredu a preskočte out a preskočiť tento scenár.
Porozprávajte sa trochu about--
>> Divákov: Môžem sa opýtať na rýchly dotaz?
Jedným z nich je písať ťažké?
RICK Houlihan: Čo je to?
Divákov: Napíšte ťažký.
RICK Houlihan: Napíšte ťažký.
Dovoľ mi pozrieť sa.
>> Divákov: Alebo je, že nie niečo, čo môžete len
hlas behom niekoľkých sekúnd?
RICK Houlihan: Ideme prostredníctvom hlasovania scenára.
Nie je to tak zlé.
Myslíte si, chlapci majú pár minút?
OK.
>> Takže budeme hovoriť o hlasovaní.
Takže v reálnom čase hlasovania, máme požiadavky pre hlasovanie.
Požiadavky sú, že umožníme každá osoba, ktorá má hlasovať iba raz.
Chceme nikto byť schopní zmeniť svoj hlas.
Chceme, aby v reálnom čase agregácie a analytika pre demografie
že budeme mať ukazuje užívateľom na webe.
>> Myslite na tento scenár.
Pracujeme veľa reality TV ukazuje, kde sú
robí tieto presný typ vecí.
Takže si môžete myslieť na scenár, máme milióny a milióny
tam of dospievajúce dievčatá s ich mobilné telefóny
a hlasovanie a hlasovanie, a hlasovať pre toho, kto sú
si, že je najobľúbenejší.
Tak to sú niektoré z Požiadavky nám dôjde.
>> A tak sa ako prvý prijať pri riešení tohto problému
by bolo vybudovať Veľmi jednoduchá aplikácia.
Tak som dostal túto aplikáciu.
Mám nejaké voliča vonku.
Prichádzajú v, narazí na hlasovacie aplikácie.
Mám nejaké surové hlasov tabuľku Ja si len výpis týchto hlasov do.
Budem mať nejaké agregát hlasov tabuľka, ktorá
bude robiť Analytics a demografie, a dáme to všetko tam.
>> A to je skvelé.
Život je dobrý.
Život je dobrý, kým nezistíme, že je tu vždy len jedna alebo dve
ľudia, ktorí sú populárne vo voľbách.
Je tu len jedna alebo dve veci že ľudia naozaj záleží.
A ak ste na hlasovaní mierka, zrazu som si
bude zatĺkať sakra z dvaja kandidáti, jeden alebo dva záujemcovia.
Veľmi obmedzený počet kusov ľudia nájdu byť populárny.
>> To nie je dobrý dizajn vzor.
To je vlastne veľmi zlé návrhový vzor
pretože vytvára presne to, čo sme Hovoril o tom, ktoré bolo klávesov.
Horúce klávesy sú niečo, čo sa nám nepáči.
>> Tak ako to napraviť?
A naozaj, ako to opraviť, je tým, že sa tie kandidátske vedierka
a pre každého kandidáta máme, budeme pripojiť náhodnú hodnotu,
niečo, čo vieme, náhodné hodnota medzi jedným a 100,
medzi 100 a 1000, alebo medzi jednou a 1000,
však mnoho náhodné hodnoty, ktoré chcete pripojiť na koniec tohto kandidáta.
>> A čo som vlastne urobil potom?
Ak som pomocou číslo kandidáta ako papuče agregovať hlasovania,
či som pridal náhodný Číslo na koniec, ktorý,
Vytvoril som teraz 10 vedierka, je Stotisíc vedierka, vedierka
že som agregáciu hlasov naprieč.
>> Takže mám milióny a milióny, a milióny záznamov prichádza
pre tieto kandidátov, som teraz šíri tieto hlasy naprieč Candidate a_1
cez kandidáta A_100, pretože zakaždým, keď hlas príde,
Som generovanie náhodných Hodnota medzi jedným a 100.
Som pripínanie ho na konci Kandidát, že osoba je hlasovať pre.
Ja dumping to do tej vedra.
>> Teraz na zadnej strane, ja viem, že som sto vedierka.
Takže keď chcem ísť dopredu a agregovať hlasy,
Čítal som zo všetkých tých vedier.
Tak som sa do toho pustite a pridať.
A potom som si bodový zhromaždiť kde som ísť von a povedať hej,
viete čo, kľúč tohto uchádzača priestory je viac ako sto lopaty.
Chystám sa zhromaždiť všetky hlasy od tých sto vedier.
Idem k agregácii im a budem hovoriť,
Kandidáta má teraz Celkový počet hlasovaní o x.
>> Teraz obaja zápisu dotaz a dotaz čítanie
sú pekne distribuované pretože píšem naprieč
a ja som čítal cez stovky kľúčov.
Nie som písanie a čítanie cez jeden kľúč teraz.
Takže je to skvelý vzor.
>> Toto je v skutočnosti pravdepodobne jedným z najdôležitejších dizajnu
vzory pre mierku v NoSQL.
Uvidíte tento typ návrhový vzor v každom chuť.
MongoDB, DynamoDB, to nie je ohľadu na to, my všetci musíme to urobiť.
Pretože keď máte čo do činenia s tých obrovských agregácie,
budete musieť vymyslieť spôsob, ako na šíri von cez vedierka.
Takže toto je spôsob, ako to urobiť.
Dobre, tak čo robíte práve teraz
Je ste obchodovanie off čítanie náklady na zápis škálovateľnosť.
Náklady na mojej čítanie je trochu zložitejšie
a ja musím ísť čítať zo Sto vedierka namiesto jedného.
Ale som schopný napísať.
A má priepustnosť, môj zápis priepustnosť je neuveriteľné.
Takže je to väčšinou cenný technika pre škálovanie DynamoDB,
alebo akejkoľvek databázy NoSQL na to príde.
Tak sme sa na to, ako ho škálovať.
A sme prišli, ako sa eliminovať naše horúcich kláves.
A to je fantastické.
A my sme dostali tento pekný systém.
A to nám veľmi správne hlasovanie pretože máme záznam, hodnotené de-Dupe.
Je postavený do DynamoDB.
Hovorili sme o podmienených práv.
>> Ak volič príde, dá vložku na stole,
oni vložka s ich voličskej ID, ak sa pokúsite vložiť iný hlas,
Ja podmienené zápis.
Povedzme, že len napísať to ak táto neexistuje.
Takže akonáhle som vidieť, že že hlasovanie hit stôl,
nikto iný to bude schopný dať svoj hlas v.
A to je fantastické.
A my zvyšovanie Naši pulty kandidátskych.
A robíme otázky demografia a tak.
Ale čo sa stane, keď je moje Aplikácia padá cez?
A teraz zrazu hlasov sú prichádza, a ja
Neviem, či sú stále spracovávané do mojej analýzy a demografia
už nie.
A keď aplikácie príde späť, ako
sakra viem, čo máte hlasov bola spracovaná a kde mám začať?
>> Tak to je skutočný problém, keď vás začať sa pozerať na tento typ scenára.
A ako to riešime, že?
Riešime to s tým, čo volajte DynamoDB prúdov.
Potoky je čas objednať a rozdelí zmena protokol o každom prístupe
k stolu, každý napísať prístup k stolu.
Všetky dáta, ktoré to napísané na Tabuľka sa objaví na prúde.
>> Je to v podstate 24 hodín front.
Položky zasiahol prúd, žijú po dobu 24 hodín.
Môžu byť čítať viackrát.
Garantovaná ktoré majú byť dodané iba raz do prúdu,
by bolo možné čítať n počet opakovaní.
Takže však mnoho procesy, ktoré chcete konzumovať, že dáta, môžete konzumovať.
To sa zobrazí pri každom aktualizácii.
Každý zápis bude len sa objaví raz na potoku.
Takže nemusíte mať strach asi dvojnásobok ich spracovanie
z rovnakého procesu.
>> Je to prísne nariadil za položku.
Keď hovoríme čas objednal a rozdelia,
uvidíte za prepážkou na potoku.
Uvidíte položky, aktualizácia v poriadku.
Nie sme zaručujúce streamu, že ste
dostane každú transakciu v poradí cez položiek.
>> Takže prúdy sú idempotentních.
Máme všetci vieme, čo idempotentních znamená?
Idempotentních znamená, že môžete to urobiť cez, a znova, a znova.
Výsledok to bude rovnaká.
>> Prúdy sú idempotentních, ale musí byť
hral od východzieho bodu, tam, kde si vyberiete, až do konca,
alebo nebudú mať za následok v rovnakých hodnotách.
>> To isté sa MongoDB.
MongoDB má konštrukt oni volajú oplog.
Je to presne rovnakej konštrukcie.
Mnoho databáz NoSQL majú tento konštrukt.
Používajú ju robiť veci ako replikácie, ktorý
je presne to, čo robíme s prúdmi.
Publikum: Možno kacírsky otázka, ale vy
hovoriť o tom apps dole po tak ďalej.
Sú prúdy zaručene Nikdy možná ísť dole?
RICK Houlihan: Jo, potoky je zaručené, že sa nikdy ísť dole.
Riadime infraštruktúru za sebou. prúdy automaticky
rozmiestniť svoje auto škálovanie skupiny.
Prejdeme trochu niečo o tom, čo sa stane.
>> Nemal by som povedať, že to nie je zaručené, že sa nikdy ísť dole.
Prvky sú zaručené sa objaví v prúde.
A prúd bude prístupná.
Takže to, čo ide dole alebo sa vráti späť up, že sa deje pod ním.
Je covers--, že je to v poriadku.
Dobre, takže máte iný Typy zobrazenia mimo obrazovku.
Typy zobrazenia, ktoré sú dôležité pre programátor sú zvyčajne, čo to bolo?
Mám starý názor.
Ak aktualizácia dopadne na stôl, bude to vytlačte starý pohľad do prúdu
takže dáta môžu archivovať, alebo zmena kontrola, identifikácia zmien, zmena
Riadenie.
>> Nový list, čo to je teraz, po aktualizácie, to je iný druh pohľadu
môžete získať.
Môžete získať staré aj nové obrazy.
Možno, že chcem obaja.
Chcem vidieť, čo to bolo.
Chcem vidieť, čo to sa zmenilo na.
>> Mám typ zhody procesu, ktorý beží.
Je potrebné overiť, či ak sa zmení tieto veci,
že sú v určitých medziach alebo v rámci určitých parametrov.
>> A potom možno som len Potrebujem vedieť, čo sa zmenilo.
Nezaujíma ma, čo zmene položky.
Nepotrebujem, aby potrebujete vedieť aké atribúty zmenil.
Len potrebujem vedieť, že položky sú dotkol.
To sú teda spôsoby zobrazovania že sa dostanete z prúdu
a môžete komunikovať s.
>> Aplikácia, ktorá spotrebováva prúd,
to je tak trochu, ako to funguje.
DynamoDB klient požiadať, aby tlačiť dát do tabuliek.
Prúdy nasadiť na to, čo hovoríme črepy.
Črepy sú odstupňované nezávisle na tabuľky.
Nemajú zarovnané úplne sa rozdelí váš stôl.
A dôvod, prečo je pretože line up
kapacite, aktuálny Kapacita tabuľky.
>> Ich nasadenie v ich vlastné auto škálovanie skupina,
a začnú vymykať závislosti na tom, koľko zápisy prichádzajú,
koľko reads-- v skutočnosti je to píše.
Nie je reads-- ale ako Mnoho zápisy prichádzajú.
>> A potom na chrbte koniec, máme to, čo máme
volať KCI, alebo Kinesis klientskú knižnicu.
Kinesis je prúd dát technológia spracovania od Amazonu.
A potokov je postavená na tom.
>> Takže ste použiť KCL povolený Aplikácie pre čítanie prúdu.
Kinesis Klient knižnica vlastne spravuje robotníkov pre vás.
A to tiež robí niektoré zaujímavé veci.
To bude vytvárať nejaké tabuľky up v DynamoDB tabuľkovom
sledovať, ktoré položky boli spracované.
Takže týmto spôsobom, ak to padá späť, ak spadne a príde a dostane
postavil späť hore, to môže zistiť, kde to bolo pri spracovaní prúdu.
>> To je veľmi dôležité, keď hovoríte o replikáciu.
Musím vedieť, čo Dáta bola spracovaná
a aké údaje musia byť ešte len spracované.
Takže knižnica KCL pre prúdov bude vám veľa tejto funkcii.
To sa stará o všetku domácnosť.
To sa postaví pracovníka pre každý črep.
To vytvorí administratívne tabuľku za každý črep, pre každého pracovníka.
A ako títo pracovníci oheň, udržujú tie tabuľky
takže viete, tento záznam bola prečítaná a spracovaná.
A potom, že spôsob, ako v prípade, že proces zomrie a prejde do režimu online,
to môže pokračovať presne tam, kde je to vzlietlo.
>> Tak sme sa použiť pre cross-región replikácie.
Mnoho zákazníkov má potrebu presunúť dáta alebo časti ich dátových tabuliek
okolo rôznych oblastiach.
Existuje deväť regiónov po celom svete.
Tak by mohlo dôjsť k need-- I môže mať používateľa v Ázii, užívatelia
vo východnom pobreží Spojených štátov.
Majú rôzne údaje, ktoré musí byť na mieste rozdelenie.
A možno, že užívateľ lieta od Ázie cez do Spojených štátov,
a chcem, aby replikovať jeho dáta s ním.
Takže keď sa dostane z lietadla, má dobrá skúsenosť pomocou svojho mobilného aplikácie.
>> Môžete použiť cross-región Knižnica replikácie to urobiť.
V podstate máme poskytla dve technológie.
Jeden je aplikácia konzoly môžete postaviť na svoje vlastné EC2 inštancie.
To beží čisté replikácie.
A potom sme vám dali do knižnice.
Knižnica môžete použiť na vybudovanie vlastné aplikácie, ak vás
chcú robiť šialené veci, s tým data-- filter, kopírovať len časť z toho,
otáčať dát, presuňte ho na A iné tabuľky, a tak ďalej a tak ďalej.
Takže to je to trochu ako to vyzerá.
>> DynamoDB Streams môže byť spracovať čo nazývame Lambda.
Zmienili sme sa trochu o udalosti aplikačných architektúry.
Lambda je kľúčovým prvkom, ktorý.
Lambda je kód, ktorý vystrelí na požiadanie v reakcii na konkrétne udalosti.
Jedným z týchto prípadov by mohol byť záznam sa objaví na potoku.
Ak sa na potoku sa objaví záznam, zavoláme túto funkciu Java.
No, to je JavaScript a Lambda podporuje Node.js, Java, Python,
a čoskoro podporí ďalšie jazyky rovnako.
A stačí povedať, že je to čistý kód.
napísať V Jave, definujete triedu.
Môžete tlačiť JAR hore do lambda.
A potom sa určiť, ktorá trieda volať v reakcii na ktorom udalosť.
A potom infraštruktúra Lambda za tým pobeží ten kód.
>> Tento kód dokáže spracovať Záznamy mimo potoku.
To môže robiť čokoľvek, chce s ním.
V tomto konkrétnom príklade, všetci sme naozaj robia, je protokolovanie atribúty.
Ale to je len kód.
Kód môže robiť čokoľvek, že jo?
>> Takže môžete otáčať, že dáta.
Môžete vytvárať odvodené pohľad.
Ak je to štruktúra dokumentov, môžete vyrovnať štruktúru.
Môžete si vytvoriť alternatívne indexy.
Všetky druhy vecí, ktoré môžete činenia s DynamoDB prúdmi.
>> A naozaj, to je to, čo to vyzerá.
Takže ste si tieto aktualizácie prichádzať.
Idú mimo reťazec.
Sú čítať pomocou funkcie Lambda.
Sú otáčania údaje a tlačí to v tabuľkách finančných derivátov,
oznamovanie externých systémov zmeny, a tlačí dáta do ElastiCache.
>> Hovorili sme o tom, ako dať cache v prednej časti databázy pre tento predaja
scenár.
No, čo sa stane, keď som aktualizuje opis položky?
No, keby som mal Lambda Funkcia beží na tejto tabuľke,
keď som aktualizovať opis položky, bude to vyzdvihnúť záznam z potoka,
a to bude aktualizovať ElastiCache inštancie s novými dátami.
Tak to je veľa Čo robíme s Lambda.
Je to lepidlo kód, konektory.
A to vlastne dáva schopnosť začať
a prevádzkovať veľmi zložitých aplikácií bez dedikovaný server
infraštruktúra, ktorá je naozaj cool.
>> Takže poďme späť k našim real-time hlasovanie architektúry.
To je nová a lepšia s našimi potokov a KCL povolené žiadosť.
Rovnako ako predtým, môžeme zvládnuť akúkoľvek mierka volieb.
My takto.
Robíme z bodový zhromažďuje cez viac vedier.
Máme optimistickejší zamykanie deje.
Môžeme udržať naše voliča meniť ich hlasy.
Môžu hlasovať iba raz.
To je fantastické.
Real-time odolnosť proti chybám, Teraz škálovateľné agregácie.
V prípade, že vec spadne, ju vie, kde o reštartovanie samotného
keď sa vráti, pretože sme pomocou aplikácie KCL.
A potom môžeme použiť tiež, že KCL aplikácie, aby sa zasadila dát von
k RedShift pre iné analytika app, alebo použitie
Elastické MapReduce spustiť real-time streaming agregáciou off
týchto údajov.
>> To sú veci, ktoré by sme Nehovoril o moc.
Ale sú ďalšie technológie, ktoré prichádzajú
niesť, keď hľadáte na týchto typoch scenárov.
>> Dobre, takže to je asi analytics s DynamoDB prúdov.
Môžete vyberať de-Dupe Údaje, robiť všetky druhy
pekná vecí, súhrnné údaje v pamäť, vytvorenie týchto tabuľkách finančných derivátov.
To je obrovský prípad použitia že veľa zákazníkov
sa zaoberajú, pričom vnorená Vlastnosti týchto dokumentov JSON
a vytvorenie ďalších indexov.
>> Sme na konci.
Ďakujeme vám za ložiská so mnou.
Tak poďme hovoriť o referenčná architektúra.
DynamoDB sedí v strede tak, veľkú časť infraštruktúry AWS.
V podstate môžete pripojiť ho až na čokoľvek chcete.
Aplikácií pomocou Dynamo zahŕňajú Lambda, ElastiCache, CloudSearch,
tlačiť dáta von do Elastic MapReduce, export import z DynamoDB
do S3, všetky druhy pracovných postupov.
Ale pravdepodobne najlepšie vec hovoriť,
a to je to, čo je naozaj Zaujímavé je, keď sme
hovoriť o udalosti riadené aplikácie.
>> Toto je príklad interný projekt
že máme kde sme vlastne publikovanie zhromažďovať výsledky prieskumu.
Takže v e-maile odkaz, ktorý vyšleme, tam bude
byť trochu odkaz porekadlá click tu v reakcii na zisťovanie.
A keď sa človek kliknutie odkazujúce, čo sa stane,
je, že sa strhnúť bezpečné Formulár prieskumu HTML z S3.
Neexistuje žiadny server.
To je len objekt S3.
>> Táto forma príde, načíta do prehliadača.
Má to chrbtica.
Má to zložitý JavaScript že je to beh.
Takže je to veľmi bohatá aplikácia beží v prehliadači klienta.
Oni nevedia, že oni nie sú interakciu s back end.
V tomto bode, je to všetko prehliadač.
>> Oni zverejňovať výsledky na to, čo nazývame Amazon API Gateway.
API Gateway je jednoducho web API že môžete definovať a pripojiť
na čo chcete.
V tomto konkrétnom prípade, my sme zahnutý do funkcie Lambda.
>> Takže moje POST operácie deje žiadny server.
V podstate, že API brány sedí tam.
To mi nič nestojí, kým ľudí štart vysielania na to, že jo?
Funkcia Lambda tam jednoducho sedí.
A mňa to nič nestojí, kým ľudia začnú biť ju.
Takže môžete vidieť, ako objem sa zvyšuje, to je, keď sa obvinenia prísť.
Nie som spustený server 7/24.
>> Tak som vytiahnuť formulár dole z nádoby,
a ja som písať prostredníctvom rozhrania API Brána do funkcie Lambda.
A potom Lambda funkcie hovorí, viete,
to, čo som dostal nejaké PIIS, niektorí osobné údaje
V týchto odpovedí.
Dostal som komentáre prichádzajúce z užívateľov.
Mám e-mailové adresy.
Mám užívateľské mená.
>> Dovoľte mi, aby som rozdelil to preč.
Budem vytvárať nejaké metadáta z tohto záznamu.
A budem tlačiť metadáta do DynamoDB.
A mohol by som šifrovať všetky údaje a zatlačte ju do DynamoDB keď budem chcieť.
Ale je to pre mňa jednoduchšie, v tomto prípad použitia, pokračovať o slovo,
Budem tlačiť raw dát do šifrované S3 lopaty.
Tak som použiť postavený v S3 strane servera šifrovanie a správy kľúčov Amazon
Služba tak, že mám kľúč, ktorý sa môže otáčať v pravidelných intervaloch,
a ja môžem ochrániť, že PII dát ako súčasť celého tohto pracovného postupu.
>> Tak čo som to urobil?
Práve som nasadený celok aplikácie, a ja nemám server.
Tak je to, čo udalosť riadený aplikácii architektúra urobí za vás.
>> Teraz, ak si myslíte, že o v prípade použitia pre tohle--
Máme iné zákazníkov, ja hovorím sa o tomto presnom architektúre, ktorí
spustiť neobyčajne veľké kampane, ktorí sú pri pohľade na to a ísť, oh my.
Pretože teraz, môžu v podstate tlačiť to tam,
dovoľte, že kampaň len sedieť tam, kým sa na trh, a nie
musieť starať o obr o aký druh infraštruktúry
bude tam na jej podporu.
A potom, akonáhle že kampaň je hotovo,
je to ako na infraštruktúru Len okamžite zmizne
pretože tam naozaj žiadna infraštruktúra.
Je to len kód, ktorý sedí na Lambda.
Je to len dáta, ktoré sedí v DynamoDB.
Je to úžasný spôsob, pri tvorbe aplikácií.
>> Divákov: Tak to je viac pominuteľný, než by bolo
ak to bolo uložené na skutočné serveru?
>> RICK Houlihan: Rozhodne.
Vzhľadom k tomu, že inštancia servera by mala byť 7 dvadsať čtyřitin.
To má byť k dispozícii pre niekto reagovať.
Tak vieš čo?
S3 je k dispozícii 7 dvadsať čtyřitin.
S3 vždy odpovie.
A S3 je veľmi, veľmi dobrá pri servírujú objekty.
Tieto objekty môžu byť HTML súbory, alebo JavaScript súbory, alebo čokoľvek chcete.
Môžete spustiť veľmi bohatých webových aplikácií z S3 vedierka, a ľudia robia.
>> A tak to je myšlienka tu je dostať sa preč od cesty
sme sa o tom premýšľať.
Všetci sme si myslela, že v Podmienky serverov a hostiteľov.
Nie je to o tom ešte.
Je to o infraštruktúry ako kód.
Nasadiť kód do cloudu a nechajte oblak spustite ho za vás.
A to je to, čo AWS sa snaží robiť.
>> Divákov: Takže vaše zlaté poľa v stredu API brány nie je serverom-like,
ale namiesto toho je jen--
>> RICK Houlihan: Môžete si myslieť o tom ako fasáda servera.
Všetko, čo to je, je to bude trvať HTTP požadovať a mapovať na iný proces.
To je všetko, čo robí.
A v tomto prípade, my mapovanie to na funkciu Lambda.
Dobre, takže to je všetko, čo mám.
Ďakujem mnohokrát.
Cením si to.
Viem, že chceme trochu v čase.
A dúfajme, že vy ste dostal trochu informácií
ktoré si môžete odniesť aj dnes.
A ospravedlňujem sa, ak som išiel cez niektoré z vašich hláv,
ale je tu veľká kopa základné znalosti foundational
si myslím, že je veľmi cenné pre vás.
Takže ďakujem za to, že ma.
[APPLAUSE]
Divákov: [Nepočuteľné] je, keď ste hovoril
museli ste prejsť vec od začiatku až do konca
získať správne hodnoty alebo rovnakej hodnoty,
ako by sa hodnoty ak [nepočuteľný] zmeniť.
>> RICK Houlihan: Oh, idempotentních?
Ako by sa hodnoty zmenia?
No, pretože keby som nebol spustený to celú cestu až do konca,
potom neviem, aké zmeny boli vykonané v poslednú míľu.
Nebude to byť rovnaké údaje ako to, čo som videl.
Publikum: Oh, takže stačí nedostal celý vstup.
RICK Houlihan: Správne.
Musíte ísť od začiatku až do konca, a potom je to
Bude konzistentného stavu.
Super.
>> Divákov: Takže ste nám ukázal DynamoDB môže robiť dokument alebo hodnotu kľúča.
A my sme strávili veľa času na Hodnota kľúče s hash a spôsoby
hodiť okolo.
Keď sa pozrel na týchto tabuliek, je to, že odchádzajúci za prístupu dokumentu?
>> RICK Houlihan: Ja by som nie hovoria, opúšťať to za sebou.
>> Divákov: Oni boli oddelení od the--
>> RICK Houlihan: S dokumentom prístup, typ dokument DynamoDB
Je len myslieť ako ďalší atribút.
Je to vlastnosť, ktorá obsahuje hierarchická štruktúra dát.
A potom sa v dotazoch, môžete použiť vlastnosti
z týchto objektov pomocou Object Notation.
Tak som môžete filtrovať na vnorené vlastnosť dokumentu JSON.
Divákov: Takže kedykoľvek som sa urobiť prístup dokumentu,
Môžem nejako doraziť na tabular--
Divákov: Rozhodne.
Publikum: --indexes a veci, ktoré práve hovorili.
RICK Houlihan: Jo, ten indexy a všetko,
keď chcete indexu vlastnosti JSON,
tak, že budeme musieť urobiť, je, ak vložíte objekt JSON alebo dokumentu
do Dynamu, mali by ste použiť prúdy.
Prúdy by čítať vstup.
Vy by ste dostať, že JSON objekt a vy by ste povedal OK,
čo je to vlastnosť chcem index?
>> Môžete vytvárať odvodené tabuľky.
Teraz, keď je to tak, ako to funguje práve teraz.
Nechceme, aby vás na indexe priamo tieto vlastnosti.
>> Divákov: Tabularizing dokumentov.
>> RICK Houlihan: Presne tak, sploštenie to, tabularizing to presne.
To je to, čo s tým robiť.
>> Divákov: Ďakujem.
>> RICK Houlihan: Jo, absolútne, ďakujem.
Divákov: Takže je to trochu Mongo stretáva REDIS classifers.
>> RICK Houlihan: Jo, to je veľa ako to.
To je dobrý popis pre neho.
Super.