>> [Zenelejátszási]
Rick Houlihan: Rendben.
Hello mindenki.
A nevem Rick Houlihan.
Én egy magas rangú vezető megoldások építész AWS.
Én elsősorban NoSQL és DynamoDB technológiák.
Én vagyok ma itt, hogy beszéljek Ön egy kicsit azokról.
>> Saját háttér Elsősorban adatok rétegen.
Én töltött fél fejlődésemet pályafutását írásban adatbázis,
az adatokhoz való hozzáférést, megoldások különböző alkalmazások számára.
Voltam Cloud virtualizáció körülbelül 20 év.
Szóval mielőtt a felhő a felhő, szoktuk nevezni használati számítástechnika.
És az ötlet az volt, hogy olyan, mint PG & E, akkor fizet, amit használ.
Ma hívjuk a felhő.
>> De az évek során, akivel valaha dolgoztam Egy pár cég
akkor már valószínűleg soha nem hallott.
De én már összeállított egy listát a technikai teljesítmények, azt hiszem, hogy ezt mondod.
Van nyolc szabadalom Cloud rendszerek virtualizáció, mikroprocesszor tervezés,
komplex események feldolgozása és más területeken is.
>> Így ezekben a napokban, azt leginkább az NoSQL technológiák és a következő generáció
adatbázis.
És ez általában mit fogok hogy itt beszélgetni veled ma.
Szóval mire számíthatsz ebből a munkamenet,
megyünk keresztül, egy rövid történelem adatfeldolgozás.
Ez mindig hasznos, megérteni, hogy honnan jöttünk
és miért vagyunk, ahol vagyunk.
És fogunk beszélni egy kicsit kicsit NoSQL technológia
egy alapvető szempontból.
>> Mi lesz bejutni néhány A DynamoDB belső.
DynamoDB az AWS által nem ízét.
Ez egy teljes körű irányítását és házigazdája NoSQL megoldás.
És fogunk beszélni egy kicsit a táblázatban struktúra, API-k, adattípusok, indexek,
és néhány, a belső Az, hogy DynamoDB technológia.
Majd szerzünk be néhány, a tervezési minták és a legjobb gyakorlatok.
Megbeszéljük, hogyan használja ezt a technológiát valamilyen
mai alkalmazások.
És aztán majd beszélünk egy kicsit alakulásáról vagy a megjelenése
Egy új paradigma programozási úgynevezett eseményvezérelt alkalmazások
és hogyan DynamoDB játszik, hogy is.
És elmegyünk egy kicsit A referencia architektúra vita
így tudjuk beszélni néhány A használati módja DynamoDB.
>> Tehát először off-- ez a kérdés Hallom, egy csomó van, mi egy adatbázisban.
Sokan azt hiszik, tudom, mi az adatbázis.
Ha a Google, látni fogod ezt.
Ez egy olyan strukturált adathalmazt tartott egy számítógépet, különösen az egyik, hogy
hozzáférhető különböző módokon.
Azt hiszem, ez egy jó meghatározása a modern adatbázis.
De én nem szeretem, mert ez azt jelenti, egy-két dolgot.
Ez azt jelenti, szerkezete.
És ez azt jelenti, hogy ez a számítógép.
És adatbázisok nem Mindig létezik a számítógépek.
Adatbázisok valóban létezett sok.
>> Szóval jobb meghatározása adatbázis valami ilyesmi.
Egy adatbázis szervezett mechanizmus tárolására, kezelésére,
és információt kérhet.
Ez származó About.com.
Szóval azért szeretem, mert tényleg beszél egy adatbázist, hogy egy adattár,
tárháza információ, nem feltétlenül
valamit, hogy leül a számítógép.
A történelem azt Nem mindig volt számítógépek.
>> Most, ha megkérdezem az átlagos fejlesztő ma mi
egy adatbázis, amely a válasz kapok.
Valahol tudok ragaszkodni dolgokat.
Jobbra?
És ez igaz.
De ez sajnálatos.
Mivel az adatbázist a valóban Az alapítvány a modern app.
Ez az alapítvány Minden alkalmazás.
És hogy hogyan kell kialakítani adatbázis, hogyan strukturálják
hogy az adatok fog diktálni, hogyan, hogy alkalmazás elvégzi ahogy skála.
>> Szóval sok a munkám ma foglalkozik, hogy mit
történik, ha a fejlesztők ezt a megközelítést
és következményeinek kezelésében Az olyan alkalmazás, amely
most méretezés túl az eredeti szándék és a szenvedés a rossz tervezés.
Így remélhetőleg, ha elsétálni ma, akkor
Van egy pár eszközök a biztonsági öv, hogy akkor tartsa meg
attól, hogy azok ugyanazokat a hibákat.
Minden rendben.
Szóval beszéljünk egy kicsit a Az idővonal adatbázis-technológia.
Azt hiszem, olvastam egy Cikk nem is olyan régen
és mondott valamit a lines-- ez egy nagyon költői nyilatkozatot.
Azt mondta, a történelem Az adatfeldolgozás
tele nagy vízjelek Az adatok sokasága.
OKÉ.
Most, azt hiszem, ez a fajta igaz.
De én tényleg nézd meg az AS A történelem valójában tele
Magas vízjel az adatok nyomást.
Mivel az adatok sebessége lenyelés soha nem megy le.
Csak megy fel.
>> És az innováció akkor jelentkezik, ha látjuk adatok nyomás, amely
az adatok mennyisége, amely most jön be a rendszerbe.
És ez nem lehet feldolgozni hatékonyan időben vagy a költség.
És ez az, amikor elkezdjük nézni adatok nyomás.
>> Tehát, ha megnézzük a első adatbázis, ennek
az egyik, hogy között volt a fülünkben.
Mindannyian született.
Ez egy szép adatbázisban.
Ez egy magas rendelkezésre állás.
Ez mindig az.
Mindig kapni.
>> De ez egyetlen felhasználó.
Nem tudok megosztani a gondolataimat veled.
Ha nem kap a gondolataim ha meg akarjuk őket.
És azok abilitiy nem olyan jó.
Mi elfelejt dolgokat.
Hébe-hóba, egyikünk levelek és mozog, hogy egy másik létezéséről
és mi mindent elveszít ez volt az adatbázisba.
Szóval ez nem annyira jó.
>> És ez jól működött az idő múlásával amikor mi voltunk vissza a nap
amikor minden, amit igazán szükség, hogy tudjuk, hová megyünk menni holnap
vagy ha gyűjtünk a legjobb étel.
De ahogy növekedni kezdett, mint egy civilizáció és a kormány megkezdte
hogy jöjjön létre, és vállalkozások fejlesztésébe kezdett,
kezdtünk rájönni, mi Szükségem van egy kicsit több, mint mi
tudnánk tenni a fejünkben.
Minden rendben?
>> Mi szükséges rendszerek rekordot.
Mi szükség van helyeket, hogy képes az adatok tárolására.
Így kezdődött az írás dokumentumok, létrehozása könyvtárak és levéltárak.
Elkezdtük fejlesztése rendszer a főkönyvi könyvelés.
És ez a rendszer a főkönyvi számolás futott a világ évszázadokon,
és talán még évezredek Azt a fajta nőtt arra a pontra
ahol az adatok terhelés meghaladta a képesség, e rendszerek
hogy képes legyen tartalmaznak azt.
>> És ez is történt valójában az 1880-as években.
Jobbra?
Az 1880-as US Census.
Ez valóban, ahol a fordulópont pont korszerű adatkezelés.
Ez az a pont, amely az adatok mennyisége
amit szedett be a Egyesült Államok kormánya van arra a pontra
ahol nyolc évig tartott feldolgozni.
>> Most, nyolc years-- mint Tudod, a népszámlálás
fut minden 10 years-- így Elég nyilvánvaló, hogy az idő is
Megvan a 1890-es népszámlálás, az adatok mennyiségét
volt, lesz feldolgozni a kormány
fog haladhatja meg a 10 évet, hogy lenne szükség, hogy elindította az új népszámlálás.
Ez volt a probléma.
>> Tehát egy srác nevű Herman Hollerith jött
és ő találta egység rekordot ütést kártyák, lyukkártya olvasó, lyukkártya
tabulátorral, és az egybevetés a mechanizmusok ezt a technológiát.
És ez a társaság, hogy alakult a időt, valamint egy pár mások,
valóban lett az egyik pillére a kis cég ma már tudjuk, az úgynevezett IBM.
>> Így aztán az IBM eredetileg volt Az adatbázis üzlet.
És ez igazán, amit csináltak.
Tették adatfeldolgozás.
>> Mint oly elterjedése ütést kártyák, egy ötletes mechanizmusok
hogy képes felerősítse, hogy technológia lehívni sorba rendezett eredmény határozza meg.
Láthatjuk a kép ott van egy little--
ez egy kicsit small-- de láthatjuk Nagyon ötletes mechanikus mechanizmus
ahol van egy lyukkártya fedélzeten.
És valaki vesz Egy kis csavarhúzó
és kitart a nyílások és felemelése a
kap, hogy meccs, hogy válogatni eredmény eléréséhez.
>> Ez egy aggregációt.
Tesszük ezt minden alkalommal ma a számítógépet,
ahol csinálni az adatbázisban.
Szoktuk csinálni kézzel, ugye?
Az emberek álljanak össze.
És ez volt a proliferáció Ezen lyukkártya
abba, hogy mi hívtuk adatok dobok és az adatok orsók, papírszalag.
>> Az adatok feldolgozása ipar vette a tanulságot a játékos zongorák.
Játékos zongorák vissza A századfordulón
használt papírt használ tárcsa slot A megmondani, hogy melyik kulcsot kell játszani.
Annak érdekében, hogy a technológia adaptáltuk végül digitális adatok tárolására,
mert sodorhatják az adatokat adnunk az olyan papírszalag tárcsákat.
>> Most, ennek eredményeként, az adatok volt actually-- hogyan
hozzáférést ezen adatokat közvetlenül függ, hogy hogyan tárolják azt.
Tehát ha tettem az adatokat a kazettára, Volt hozzáférni az adatokhoz lineárisan.
Meg kellett dobni az egész szalagot, hogy minden adatot.
Ha tettem az adatokat ütést kártyák, tudtam hozzáférni
egy kicsit több véletlenszerű divat, talán nem olyan gyorsan.
>> De voltak korlátai, hogyan adatokhoz való hozzáférés alapján hogyan tárolták.
És így ez volt a probléma bemegy a '50 -es években.
Ismét kezdhetjük látni, hogy ahogy új technológiák kifejlesztésére feldolgozni
Az adatok, jobb, mert nyit Az ajtó az új megoldások,
Az új programok, új alkalmazások az adatokat.
És valóban, a kormányzás Lehet, hogy az ok
Ezért fejlesztettük ki néhány ilyen rendszerek.
De az üzleti gyorsan vált a vezető evolúciója mögött
A modern adatbázis és a modern fájlrendszer.
>> Így a következő dolog, feljött volt, a 50-es évek
volt a fájlrendszer és a fejlesztését véletlen hozzáférésű tároló.
Ez szép volt.
Most, minden hirtelen, tudjuk be a fájlokat bárhol a következő merevlemezek
és mi lehet hozzáférni az adatokhoz véletlenszerűen.
Mi lehet elemezni, hogy információkat ki fájlokat.
És megoldottuk a világ összes problémák adatfeldolgozás.
>> És ez tartott kb 20 vagy 30 év, amíg a fejlődése
A relációs adatbázis, amely az, amikor a világ úgy döntött, most
szükség van egy tároló, amely legyőzi A terjeszkedés az adatok az egész fájl
rendszereket, amit felépítettünk. Jobbra?
Túl sok adatot forgalmazott túl sok helyen, a duplikáció-adatok,
és a tárolási költségeket, óriási volt.
>> A '70 -es években, a legdrágább erőforrás hogy a számítógép volt a gép tárolására.
A processzor volt tekinteni, mint egy fix költség.
Ha veszek a dobozt, A CPU munkát végez.
Ez lesz forog-e ez valóban működik-e vagy sem.
Ez tényleg egy elsüllyedt költség.
>> De milyen áron nekem, mint egy üzlet tároló.
Ha meg kell vásárolni több lemezt következő hónapban, ez egy valós költségeit, hogy én fizetni.
És, hogy a tárolás drága.
>> Most gyors előre 40 éves és van egy másik probléma.
A számítási most a legdrágább erőforrás.
A tárolási olcsó.
Úgy értem, mehetünk bárhová a felhő, és mi lehet találni olcsó tárolása.
De mi nem találok olcsó számítási.
>> Tehát az evolúció mai technológiát, az adatbázis-technológia,
valóban köré elosztott adatbázisok
amelyek nem szenvednek az azonos típusú skála
korlátai relációs adatbázisok.
Beszélni fogunk egy kicsit hogy ez mit is jelent valójában.
>> De az egyik oka, és a vezető mögött this-- vagyunk
beszélt az adatok nyomást.
Az adatok nyomás valamit ami hajtja az innovációt.
És ha megnézi felett Az elmúlt öt évben,
ez egy táblázatot, amit az adatok terhelést a az általános vállalati
úgy néz ki, mint az elmúlt öt évben.
>> És az általános ökölszabály Ezek days-- ha megy Google--
90% -a az adatok, hogy a tárolunk ma, és ez volt
generált az elmúlt két évben.
OKÉ.
Nos, ez nem egy trend, ami új.
Ez a tendencia, hogy a már kiment 100 éve.
Amióta Herman Hollerith kifejlesztette a lyukkártya,
mi már az épület adattárak és adatgyűjtés fenomenális árak.
>> Így az elmúlt 100 évben, Láttuk ezt a trendet.
Ez nem fog megváltozni.
Továbblépve fogunk látni ez, ha nem gyorsított tendenciát.
És tudod mit, hogy néz ki.
>> Ha egy vállalkozás 2010-ben volt egy terabyte adatot kezel,
ma azt jelenti, hogy ők irányító 6,5 petabájt adat.
Ez 6500-szer több adatot.
És tudom, hogy ez.
Dolgozom ezek a vállalkozások minden nap.
Öt évvel ezelőtt, hogy szóba cégek
aki velem beszélni, mi a fájdalom ez kezelni terabájt adat.
És ők beszélnek nekem arról, hogyan látjuk
hogy ez valószínűleg fog hogy egy petabyte vagy két
egy pár évig.
>> Ugyanezek a cégek ma találkozom azzal,
és ők beszélnek, hogy nekem a probléma van ott, amelynek kezelése
tíz, 20 petabájt adat.
Így a robbanás a adatok az iparban
hajtja a hatalmas szükség van jobb megoldás.
És a relációs adatbázis Csak nem éri el a kereslet.
>> És így van egy lineáris korreláció adatok nyomás
és a technikai innováció.
A történelem megmutatta nekünk ez, hogy az idő múlásával,
valahányszor az adatmennyiség hogy kell feldolgozni
meghaladja a kapacitás a rendszer feldolgozni azt ésszerű időn
vagy elfogadható áron, Ezután az új technológiák
kitalált megoldani ezeket a problémákat.
Ezeket az új technológiák, viszont nyissa ki az ajtót
a másik meg a problémákat, amelyek összegyűjtése még több adatot.
>> Most, hogy nem fogunk megállítani ezt.
Jobbra?
Mi nem fogja megállítani ezt.
Miért?
Mert nem lehet tudni, hogy mindent van tudni az univerzumban.
És amíg mi már él, az egész ember története,
mi mindig is hajtott, hogy többet.
>> Tehát úgy tűnik, mintha minden négyzetcentiméterét haladunk le az utat a tudományos felfedezés,
mi megszorozzuk az adatmennyiség hogy meg kell feldolgozni exponenciálisan
ahogy feltárni egyre több és több a belső élet működését,
arról, hogyan működik a világegyetem, mintegy vezetői a tudományos felfedezés,
és a találmány szerinti, hogy a csinálunk ma.
Az adatmennyiség csak folyamatosan növekszik.
Tehát, hogy képes kezelni ez a probléma hatalmas.
>> Tehát az egyik dolog nézzük, hogy miért NoSQL?
Hogyan NoSQL megoldani ezt a problémát?
Nos, a relációs adatbázisok, Structured Query Language,
SQL--, hogy tényleg egy konstrukciót a relációs database-- ezek a dolgok
optimalizált tároló.
>> Vissza a 70-es években, ismét, lemez drága.
A céltartalék gyakorlása tároló A vállalkozás soha véget nem érő.
Tudom.
Éltem meg.
Írtam tároló illesztőprogramok egy enterprised szuperszervert cég
vissza a '90 -es években.
És a lényeg, állványok másik tártömböt csak valami,
történt minden nap a vállalkozás.
És soha nem szűnt meg.
Nagyobb sűrűségű tároló, a kereslet A nagy sűrűségű tároló,
és a hatékonyabb tárolás devices-- ez soha nem szűnt meg.
>> És NoSQL egy nagyszerű technológia mert normalizálja az adatokat.
Ez de-megkétszerezi az adatokat.
Ez hozza az adatokat egy olyan szerkezetbe az agnosztikus minden hozzáférési mintát.
Több alkalmazás is sújtotta, hogy SQL adatbázis, fuss eseti lekérdezések
adatokat kaphat az alakja, hogy kell feldolgozni a terhelést.
Ez úgy hangzik, fantasztikus.
De a lényeg az, bármilyen rendszer, ha ez agnosztikus, hogy mindent,
van optimalizálva semmit.
OKÉ?
>> És ez az, amit kapunk a A relációs adatbázis.
Ez optimalizált tároló.
Ez normalizálódik.
Ez relációs.
Támogatja az ad hoc lekérdezéseket.
És ez és ez mérlegek függőlegesen.
>> Ha kell, hogy egy nagyobb SQL adatbázis vagy egy erősebb SQL adatbázis,
Én veszünk egy nagyobb darab vas.
OKÉ?
Dolgoztam már sok ügyfél hogy már át jelentős fejlesztése
a saját SQL csak infrastruktúra hogy megtudja, hat hónappal később,
ők üti a falat újra.
És a válasz az Oracle vagy MSSQL vagy bárki más is kap egy nagyobb dobozt.
Hát előbb vagy utóbb, ha nem lehet megvenni egy nagyobb dobozt, és ez valós probléma.
Meg kell, hogy valóban változtatni a dolgokat.
Szóval, ha ez a munka?
Jól működik az offline analitika, OLAP-típusú terhelés.
És ez igazán, amikor az SQL tartozik.
Most, ezt használják ma sok online tranzakciófeldolgozás típusú
alkalmazásokat.
És azért jól működik a Néhány kihasználtsági szintje,
de ez csak nem skála a módon, hogy NoSQL nem.
És fogunk beszélni egy kicsit kicsit, hogy ez miért.
>> Most, NoSQL, másrészt, jobban optimalizált számítási.
OKÉ?
Nem agnosztikus, hogy A hozzáférési mintát.
Hívjuk de normalizált struktúra, vagy egy hierarchikus struktúrát.
Az adatokat egy relációs adatbázis egymáshoz több táblából
termelni véli, hogy szükség van.
Az adatokat egy NoSQL adatbázisban van tárolva egy dokumentumot, hogy
tartalmazza a hierarchikus felépítés.
Minden adat, ami általában összefogtak, hogy készítsen ezt a nézetet
tárolt egyetlen dokumentumban.
És fogunk beszélni egy kicsit hogyan működik egy-két listákon.
>> De az ötlet az, hogy tárolja Az adatok, mivel ezek példányai kilátást.
OKÉ?
Léptékezni vízszintesen.
Jobbra?
Ha kell növelni a mérete a NoSQL klaszter,
Nem kell, hogy egy nagyobb dobozt.
Kapok egy dobozt.
És én klaszter ezeket együtt, és tudom, hogy Szilánk adatokat.
Majd beszéljünk egy kicsit mi sharding van, hogy
képes bővíteni, hogy az adatbázisban több fizikai eszközök
és távolítsa el az akadályt, hogy megköveteli, hogy skála függőlegesen.
>> Szóval ez tényleg beépített online tranzakció-feldolgozás és a skála.
Van egy nagy különbség Itt közötti jelentési, ugye?
Jelentést, nem tudom, a kérdéseket fogok feltenni.
Jobbra?
Reporting-- ha valaki a én marketing osztály
akar csak-- hány ügyfelem ezt különösen jellemző, akik
vásárolt ezen a day-- nem tudom mit kérdezni fognak kérni.
Szóval kell lennie agnosztikus.
>> Most, egy on-line tranzakciós alkalmazás,
Tudom, milyen kérdéseket, amit kérek.
Én építettem a kérelem Egy nagyon speciális munkafolyamat.
OKÉ?
Szóval ha optimalizálja az adatok tárolni, hogy támogassa, hogy a munkafolyamat,
ez lesz gyorsabb.
És ezért NoSQL lehet Tényleg gyorsabb eljuttatása
Az olyan típusú szolgáltatások.
Minden rendben.
>> Így fogunk bejutni Egy kis elmélet itt.
És néhányan közületek, a szemed visszagörgetheti egy kicsit.
De megpróbálom tartani olyan magas szintű, amennyire csak tudok.
Tehát ha a projekt menedzsment, van
A konstrukció az úgynevezett háromszög korlátok.
OKÉ.
A háromszög a korlátozásoknak diktálja hogy nem lehet mindent minden alkalommal.
Nem lehet a pite és enni is.
Így a projekt menedzsment, hogy háromszög korlátok akkor lehet, hogy az olcsó,
akkor lehet, hogy gyors, vagy lehet, hogy jó.
Válassz kettőt.
Mert nem lehet csak ezt a hármat.
Jobbra?
OKÉ.
>> Szóval hallani erről sokat.
Ez egy hármas korlát, háromszög hármas korlát,
vagy a vas háromszög oftentimes-- amikor beszélsz projektmenedzserek,
fognak beszélni erről.
Most, adatbázisok saját vas háromszög.
És a vas háromszög adatok hívjuk KAP tétel.
OKÉ?
>> KAP-tétel diktál hogyan működnek adatbázisok
egy igen konkrét feltétel.
És fogunk beszélni, mi ez a feltétel.
De a három pontot a háromszög, hogy úgy mondjam, a C, a következetesség.
OKÉ?
Tehát a KAP, a következetesség azt jelenti, hogy minden ügyfelek, akik hozzáférhet az adatbázishoz
mindig van egy nagyon konzisztens képet adatokat.
Senki sem fog látni két különböző dolog.
OKÉ?
Ha látom az adatbázis, Látok ugyanazt a nézetet
mint a társam, aki látja ugyanabból az adatbázisból.
Ez a következetesség.
>> Szabad azt jelenti, hogy ha a adatbázis az interneten, ha el lehet érni,
hogy minden kliens program mindig képes írni és olvasni.
OKÉ?
Így minden ügyfél, hogy Elolvashatja az adatbázisban
Mindig tudja olvasni adatok és írni az adatokat.
És ha ez a helyzet, ez egy álló rendszer.
>> És a harmadik pont az, amit hívjuk partíció tolerancia.
OKÉ?
Partíció tolerancia úton hogy a rendszer jól működik
annak ellenére, hogy a fizikai hálózat válaszfalak a csomópontok között.
OKÉ?
Tehát a fürt csomópontjai nem beszélnek egymással, mi történik?
Minden rendben.
>> Tehát a relációs adatbázisok choose-- akkor vedd két ilyen.
OKÉ.
Tehát a relációs adatbázisok választani hogy következetes és elérhető.
Ha a partíció között történik A DataNodes az adattárban,
Az adatbázis összeomlik.
Jobbra?
Csak megy le.
OKÉ.
>> És ez miért van a nő a nagyobb dobozok.
Jobbra?
Mert van no-- általában, a klaszter adatbázis, ott nem nagyon sokan
hogy működnek így.
De a legtöbb adatbázisok skála függőlegesen egyetlen dobozban.
Mert kell lennie következetes és rendelkezésre.
Ha egy partíció voltak kell beadni, akkor kellett volna, hogy a választás.
Van, hogy egy választás között következetes és elérhető.
>> És ez az, amit NoSQL adatbázisokhoz.
Minden rendben.
Tehát egy NoSQL adatbázist, akkor Két fajta.
Mi have-- jól, Jön a sok íz,
de ez benne van a két alapvető jellemzõk mi
mondanánk CP adatbázisban, vagy következetes és partíció tolerancia
rendszer.
Ezek a srácok, hogy a választás, hogy amikor a csomópontok veszít érintkezik egymással,
nem megyünk, hogy embereket, hogy írjanak többé.
OKÉ?
>> Amíg ez a partíció eltávolítása, írási hozzáférés le van tiltva.
Ez azt jelenti, hogy nem áll rendelkezésre.
Ők következetes.
Amikor azt látjuk, hogy partíció adja magát,
most következetes, mert nem megyünk
hogy lehetővé tegye a változás két oldalán a partíció függetlenül
egymást.
Mi kell helyreállítani kommunikációs
mielőtt bármilyen frissítés az adatok megengedett.
OKÉ?
>> A következő íz lenne egy AP rendszer, vagy egy szabad és megosztjuk
tolerancia rendszer.
Ezek a srácok nem érdekel.
Jobbra?
Bármilyen csomópont, amely kap egy levelet, akkor vedd el.
Úgyhogy lemásolják az adataimat több csomópontot.
Ezek a csomópontok kap az ügyfél, ügyfél jön A mondja, én fogom írni néhány adatot.
Node mondja, semmi gond.
A csomópont mellé kap írási ugyanazon a rekordot,
ő fog mondani semmi gond.
Valahol vissza a háttérben, hogy az adatok fog szaporodni.
És akkor valaki majd észre, Ajjaj, akkor a rendszer észre, uh-oh,
van már egy frissítést a két fél.
Mit csináljunk?
És mit csinálnak majd a csinálnak valamit, ami
lehetővé teszi számukra, hogy megoldja az adatok állapotban.
És fogunk beszélni, hogy a következő táblázatot.
>> Dolog, hogy pont itt.
És én nem fogok túl sokkal ebbe, mert ez a
bejut mély adatokat elmélet.
De van olyan ügyleti keretet, amely
fut egy relációs rendszer lehetővé teszi számomra, hogy biztonságosan, hogy frissítések
hogy több szervezet az adatbázisban.
És ezek a frissítések fog bekövetkezni egyszerre, vagy egyáltalán nem.
És ezt nevezik ACID tranzakciók.
OKÉ?
>> ACID ad nekünk atomicitás, következetesség, szigetelés, és a tartósság.
OKÉ?
Ez azt jelenti, atomi, tranzakciók, mind frissítéseim sem történik meg, vagy nem.
Összhang azt jelenti, hogy Az adatbázis mindig
hozni egy egységes állapotban egy frissítés után.
Soha nem fogom elhagyni az adatbázist egy Rossz állapotban alkalmazása után egy frissítést.
OKÉ?
>> Szóval ez egy kicsit más mint KAP összhang.
KAP konzisztencia azt jelenti az én ügyfelek mindig látni az adatokat.
ACID a következetesség azt jelenti, hogy ha a tranzakció megtörtént, az adatok jó.
Saját kapcsolatok mind jó.
Nem fogom törölni a szülő sorban és hagyjuk egy csomó árva gyermekek
Néhány másik asztalnál.
Ez nem történhet meg, ha én vagyok következetes savas tranzakciót.
>> Isolation jelenti, hogy az ügyletek mindig előfordulnak egyiket a másik után.
A végeredmény az adatok ugyanaz lesz állapotban
mintha ezen ügyletek ben kibocsátott egyidejűleg
kivégezték sorozatban.
Szóval ez konkurencia kontroll az adatbázisban.
Tehát alapvetően, nem tudom megnövelni a ugyanazt az értéket kétszer két művelet.
>> De ha azt mondom adjunk hozzá 1 erre az értékre, és két ügylet jönnek
és megpróbálja csinálni, az egyik az, lesz, hogy oda először
és a többi ember fog odaérni után.
Így a végén, tettem hozzá kettő.
Látod, mire gondolok?
OKÉ.
>> Tartóssága nagyon egyszerű.
Amikor az ügylet Elismert, hogy
ott lesz még ha a rendszer összeomlik.
Ha ez a rendszer visszanyeri, hogy ügylet, amely elkövetése
valóban ott lesz.
Szóval ez a garanciák Az ACID tranzakciók.
Ezek elég szép garanciák hogy egy adatbázis,
de ennek ez a költség.
Jobbra?
>> Mivel a probléma ezzel a keret
ha van egy partíció az adatokban set, azt kell dönteni.
Megyek is, hogy frissítéseket az egyik oldalon vagy a másik.
És ha ez megtörténik, Ezután már nem vagyok megy
hogy képes fenntartani ezeket a jellemzőket.
Ők nem lesz egyenletes.
Ezek nem izolálható.
Ez az, ahol lerobban A relációs adatbázisok.
Ez az oka relációs adatbázisok skála függőlegesen.
>> Másrészt, van az úgynevezett alap technológia.
És ezek a NoSQL adatbázisok.
Minden rendben.
Szóval mi van a CP, AP adatbázisok.
És ezek, amit úgy hívnak alapvetően álló, puha állapotban, végül
következetes.
OKÉ?
>> Alapvetően elérhető, mert ők partíció toleráns.
Ők mindig ott, akkor is, ha van
hálózati partíciót a csomópontok között.
Ha tudok beszélni, hogy egy csomópont, én vagyok lesz képes olvasni az adatokat.
OKÉ?
Lehet, hogy nem mindig képes írni adatokat, ha én vagyok a következetes platform.
De képes lesz olvasni az adatokat.
>> A puha állapot mutatja, hogy amikor olvastam, hogy az adatok,
lehet, hogy nem ugyanaz, mint a többi csomópont.
Ha a jobb adta ki a csomóponton valahol máshol a klaszter
és ez nem replikálta az egész klaszter mégis, amikor azt olvastam, hogy az adatok,
hogy az állami esetleg nem következetes.
Azonban, ez lesz végül következetes,
ami azt jelenti, hogy amikor egy írási történik a rendszerben,
akkor megismételni az egész csomópontot.
És végül, hogy az állami majd hozni annak érdekében,
és ez lesz konzisztens állapotban.
>> Most, a KAP-tétel valóban játszik csak egy feltétellel.
Ez a feltétel az, amikor ez megtörténik.
Mert ha ez működik normál módban, nincs partíció,
mindent következetes és elérhető.
Ön csak aggódni KAP amikor már a partíciót.
Tehát azok ritkák.
De a rendszer hogyan reagál, amikor azok merülnek diktálja, hogy milyen típusú rendszer
dolgunk.
>> Szóval vessünk egy pillantást, amit úgy néz ki, mint az AP rendszerek.
OKÉ?
AP rendszerek jön két ízeket.
Jönnek az íz, ami a master master, 100%, mindig elérhető.
És jönnek az Más ízt, amely azt mondja,
Tudod mit, fogok aggódni erről a particionálás dolog
ha a tényleges partíció fordul elő.
Ellenkező esetben nem lesz elsődleges csomópontok, ki fogja venni a jogokat.
OKÉ?
>> Tehát, ha valami ilyesmi Cassandra.
Cassandra lenne mestere mester, hadd írjam minden csomópont.
Tehát mi történik?
Szóval van egy tárgy a adatbázis, hogy létezik a két csomópont.
Nevezzük azt a tárgyat S. Tehát van állapotban S.
Van néhány művelet S hogy folyamatban vannak.
Cassandra lehetővé teszi számomra, hogy írjon több csomópont.
Tehát mondjuk azt, hogy egy írni, s két csomópontra.
Nos, mi végül az történik, hívjuk, hogy a particionálás esetén.
Ott nem lehet fizikai hálózat partíció.
De mivel a tervezés A rendszer, ez
ténylegesen particionálás amint kapok egy írás a két csomópont.
Ez nem kényszerít írok egy csomóponton keresztül.
Írok két csomópontot.
OKÉ?
>> Mostanra van két állam.
OKÉ?
Mi fog történni előbb vagy utóbb,
ott lesz a replikációs eseményt.
Ott lesz, amit mi úgynevezett partíció helyreállító, amely
az, ahol ez a két államok jönnek újra együtt
és ott lesz egy algoritmus fut az adatbázison belül történik,
eldönti, hogy mi a teendő.
OKÉ?
Alapértelmezésben Utolsó frissítés nyerte a legtöbb AP rendszerek.
Szóval ott általában egy alapértelmezett algoritmus, milyen
Hogy hívják a visszahívás funkciót, ami
fogják hívni, ha ez a feltétel érzékeli, hogy végre némi logika
megoldani, hogy a konfliktus.
OKÉ?
Az alapértelmezett visszahívási és alapértelmezett rezolverkábel a legtöbb AP adatbázisok
van, tudod mit, időbélyeg nyer.
Ez volt az utolsó frissítés.
Azt fogom tenni, hogy frissítés van.
Lehet kiírása ezt a lemezt, hogy én dömpingelt ki egy helyreállítási napló
úgy, hogy a felhasználó látogasson vissza később és azt mondják, hé, volt egy ütközés.
Ami történt?
És akkor valóban kiírása egy rekordot minden ütközések és a visszavonás
és meglátjuk, mi történik.
>> Most, mint felhasználó, akkor is közé logika, hogy visszahívás.
Szóval lehet változtatni visszahívási műveletet.
Azt lehet mondani, hé, szeretnék orvoslására az adatokat.
És azt akarom, hogy megpróbálja egyesíti a két nyilvántartás.
De ez rajtad áll.
Az adatbázis nem tudja, hogyan kell Ehhez alapértelmezés szerint. A legtöbb időt,
Az egyetlen dolog, az adatbázis Tudja, hogyan kell tennie, hogy azt mondják,
ez volt az utolsó rekordot.
Ez az egyik, hogy az fog nyerni, és ez az érték fogom tenni.
Egyszer, hogy partíció helyreállító és replikáció,
mi államunk, amely most S elsődleges, amely
Az egyesítés állam mindazon tárgyakat.
Tehát AP rendszerek ezt.
CP rendszerek nem kell aggódni emiatt.
Mert amint egy partíció jön játékba, csak hagyja abba
írja.
OKÉ?
Szóval ez nagyon könnyű foglalkozik következetes
ha nem fogadja el a frissítéseket.
Ez a CP rendszerek teszik.
Minden rendben.
>> Szóval beszéljünk egy kicsit kicsit a hozzáférési mintákat.
Amikor arról beszélünk, NoSQL, ez Minden a hozzáférést mintát.
Most, az SQL eseti lekérdezések.
Ez relációs boltban.
Nem kell aggódnia a hozzáférés mintát.
Írok egy nagyon összetett kérdés.
Magától és megkapja az adatokat.
Ez az, amit ez úgy néz ki mint, normalizálás.
>> Tehát ebben a különleges szerkezetet, keresünk egy katalógus.
Van különböző típusú termékek.
Van könyveket.
Van egy albumot.
Van videók.
A kapcsolat a termékek és ezek bármelyike ​​könyvek, albumok,
és videók táblák 1: 1.
Minden rendben?
Van egy termék azonosító, és hogy az ID felel
egy könyv, egy album, vagy egy videót.
OKÉ?
Ez egy 1: 1 kapcsolat szerte e táblázatokat.
>> Most, books-- minden tőlük Van root tulajdonságokkal.
Nem gond.
Nagyszerű.
Egy-egy kapcsolat, azt, hogy minden Az adatok azt kell leírni, hogy a könyv.
Albums-- két album zeneszámokat.
Ez az, amit mi hívja az egyik, hogy sok.
Minden album volna sok pálya.
Így minden pályán Az album tudtam volna
egy másik rekord ebben gyermek asztal.
Szóval létre egy rekordot az én album táblázatban.
Én létre több rekord A pályák asztalra.
Egy-sok kapcsolat.
>> Ez a kapcsolat az, ami hívjuk a sok-sok.
OKÉ?
Látod, hogy a szereplők lehetnek sok film, sok videót.
Szóval amit csinálunk, az tesszük ezt a leképezés táblázat között azok, amelyek csak
térképek a színész azonosítóját a videó azonosítóját.
Most is létrehozhat egy lekérdezést az illesztéseknél videók segítségével színész videót szereplők,
és ez ad nekem egy szép listát összes film és a valamennyi szereplő
akik abban a filmben.
>> OKÉ.
Tehát itt vagyunk.
Egy-egy a felső szintű kapcsolat; egy-sok,
album számai; Sok-sok.
Ez a három felső szintű kapcsolatok bármilyen adatbázisban.
Ha tudod, hogyan kell e kapcsolatok működnek együtt,
akkor tudjuk, hogy sok mintegy adatbázis már.
Tehát NoSQL egy kicsit másképpen dolgozik.
Gondoljunk csak a második, amit Úgy néz ki, hogy akkor kap az én termékek.
>> Egy relációs boltban, szeretnénk, hogy az én termékek
egy listát az összes termékeim.
Ez sok olyan lekérdezés.
Kaptam egy lekérdezést az összes könyvemet.
Kaptam egy lekérdezést az albumomat.
És kaptam egy lekérdezést az én videók.
És kaptam, hogy azt valamennyit egy listát
és tálaljuk vissza az alkalmazás, ami azt kérő.
>> Ahhoz, hogy a könyveim, csatlakozom Termékek és könyvek.
Ahhoz, hogy az albumokon kaptam, hogy csatlakozzon Termékek, albumok és számok.
És hogy megkapjam a videókat, van hogy csatlakozzon termékek a videók,
csatlakozzon a színész videók, és hogy a színészek.
Szóval ez a három lekérdezéseket.
Nagyon összetett lekérdezések össze egy eredmény meg.
>> Ez kevesebb, mint az optimális.
Ez az oka annak, amikor beszélünk körülbelül egy adatstruktúrát, ami
építették, hogy agnosztikus, hogy a hozzáférési pattern-- is ez nagyszerű.
És láthatjuk ezt a valóban Jó, hogyan szervezte az adatokat.
És tudod mit?
Nekem csak egy rekord egy színész számára.
>> Ez király.
Már duplikációmentesített az én szereplők, és én tartjuk az én egyesületek
ebben a leképezési tábla.
Azonban a szerzés adatok ki lesz drága.
Küldök a CPU az egész rendszer ezeket összekötő adatszerkezetek össze
hogy képes húzni, hogy az adatok vissza.
>> Szóval hogyan lehet megkerülni, hogy?
Ebben NoSQL ez körülbelül összesítés nem normalizálása.
Szóval azt akarom mondani akarunk támogatja a hozzáférési mintát.
Ha a hozzáférési minta Az alkalmazások,
Azt kell, hogy az én termékek.
Tegyük az összes termék egy táblázatban.
Ha tettem a termék egy asztal, Én is csak válassza ki az összes termék
ettől az asztalra, és azt, hogy mindent.
Nos, hogyan tudom ezt?
Nos NoSQL nincs szerkezete az asztalra.
Beszélni fogunk egy kicsit hogyan is működik ez a Dynamo DB.
De nem ugyanaz tulajdonságok és az azonos tulajdonságokkal
minden egyes sorban, minden egyes elemet, mint te SQL táblában.
És mi ez lehetővé teszi számomra tennie, hogy egy csomó dolgot
és adj egy nagy rugalmasságot.
Ebben a konkrét esetben, I van a termék dokumentumokat.
És ebben a konkrét Például, mindent
egy olyan dokumentum, a termékek asztalra.
És a terméket a könyv talán Van egy ID típusú, amely meghatározza egy könyvet.
És az alkalmazás váltana az ID.
>> A ás alkalmazások, megyek mondani ó, milyen rekordot típusú ez?
Ó, ez egy könyvet rekordot.
Nyilvántartást kell ezeket a tulajdonságokat.
Hadd hozzon létre egy könyvet objektumot.
Így fogok, hogy kitöltse a könyv célja ezzel az elemmel.
Következő termék jön és mondja, mi ez a tétel?
Hát ez a tétel egy albumot.
Ó, kaptam egy teljesen más feldolgozó rutin, hogy
mert ez az album.
Látod, mire gondolok?
>> Így az alkalmazás tier-- I csak válassza ki ezeket a feljegyzéseket.
Mindannyian kezdeni jön.
Ők lehetnek a különféle típusú.
És ez az alkalmazás logikáját hogy kapcsol át az ilyen típusú
és úgy dönt, hogy miként kell feldolgozni őket.
>> Ismét, szóval optimalizálása sémája a hozzáférési mintát.
Megcsináljuk azt összeomló ezeket a táblázatokat.
Mi alapvetően figyelembe ezek normalizált szerkezetek,
és mi építünk hierarchikus felépítés.
Belül minden egyes ilyen bejegyzések Megyek látni tömb tulajdonságait.
>> Belül ezt a dokumentumot albumok, Látok tömbök pályák.
Azok a dalok most become-- ez Alapvetően ez a gyermek asztal, hogy
létezik itt, ebben a struktúrában.
Tehát akkor ezt a DynamoDB.
Megteheti ezt a MongoDB.
Ezt megteheti bármely NoSQL adatbázisban.
Hozzon létre ilyen típusú hierarchikus adatszerkezetek
amelyek lehetővé teszik adatok lekérése Nagyon gyorsan, mert most
Nem kell felelniük.
Amikor egy sort akarunk beszúrni a számok asztal, vagy egy sort a albumai asztal,
Meg kell felelnie, hogy a séma.
Van, hogy a tulajdonság vagy az ingatlanokra, amelyek meghatározott annál az asztalnál.
Mindegyiküket, behelyezésekor azt a sort.
Nem ez a helyzet NoSQL.
>> Én is teljesen más ingatlan minden dokumentumban
hogy helyezze be a gyűjtemény.
Tehát nagyon erős mechanizmust.
És tényleg, hogyan optimalizálja a rendszer.
Mert most ez a lekérdezés helyett csatlakozás mindezek asztalok
és a végrehajtó fél tucat lekérdezések hogy húzza vissza az adatokat szükségem,
Én végrehajtó egy lekérdezést.
És én ismételve szerte az eredmények beállítva.
ez ad ön egy eszme A hatalom a NoSQL.
Megyek a fajta megy itt oldalt és beszélni egy kicsit erről.
Ez több fajta a marketing vagy technology--
a technológia értékesítésére típusú vita.
De fontos, hogy megértsük mert ha megnézzük a felső
itt ezt a táblázatot, mit keresünk
hívjuk a technológia hype görbe.
És ez mit jelent, új cucc jön szóba.
Az emberek azt hiszik, hogy ez jó.
Én már megoldódott minden gondom.
>> Ez lehet a végén Minden, lehet, hogy mindenki mindent.
És már használhatja is.
És azt mondják, ez a cucc nem működik.
Ez nem igaz.
A régi cucc jobb volt.
És mennek vissza csinál dolgokat, ahogy voltak.
És akkor végül mennek, tudod mit?
Ez a cucc nem is olyan rossz.
Ó, ez hogyan működik.
És ha egyszer kitalálni, hogyan munkák, elkezdenek egyre jobb.
>> És a vicces róla van, ez a fajta vonalak fel, hogy milyen
hívjuk a technológia elfogadás Curve.
Tehát mi történik, mi valamiféle technológia ravaszt.
Abban az esetben, adatbázisok, ez az adatok nyomást.
Beszéltünk a magas vízállás pont Az adatok nyomás az idők során.
Ha az adatok nyomás elér egy bizonyos pont, ez egy technológia ravaszt.
>> Egyre túl drága.
Túl sokáig tart az adatok feldolgozására.
Szükségünk van valami jobb.
Kapsz az újítók ott rohangál,
próbálják kideríteni, mi a megoldás.
Milyen az új ötlet?
>> Mi a második legjobb módja annak, hogy ezt a dolgot?
És jön valami.
És az emberek az igazi fájdalom, A srácok a vadi
fognak ugrani rajta, mert szükség van egy választ.
Most mi elkerülhetetlenül happens-- és ez történik most NoSQL.
Látom, hogy egész idő alatt.
>> Mi óhatatlanul előfordul az, az emberek kezdenek új eszközt használva
ugyanúgy használták a régi szerszámot.
És rájönnek, hogy nem működik olyan jól.
Nem emlékszem, ki vagyok beszélget korábbi ma.
De ez olyan, mint amikor a légkalapács találták,
az emberek nem swing át fejüket törni a betont.
>> De ez az, amit az történik NoSQL ma.
Ha belépsz a legtöbb üzlet, akarják, hogy NoSQL üzletek.
Mit csinálnak az ők a NoSQL,
és ők betöltés tele relációs séma.
Mert így általuk tervezett adatbázisokat.
És ők vajon miért van Nem megy túl jól?
Fiú, ez a dolog bűzlik.
Volt, hogy fenntartsák az én csatlakozik in-- ez olyan, mint, nem, nem.
Fenntartani csatlakozik?
Miért csatlakozott adatokat?
Nem csatlakozik az adatokat NoSQL.
Ön összesítik azt.
>> Tehát, ha szeretné elkerülni ezt, tanulni hogy a szerszám működik, mielőtt ténylegesen
elindíthatjuk.
Ne próbálja használni az új eszközöket a ugyanúgy használják a régi eszközöket.
Fogsz egy rossz tapasztalat.
És minden egyes alkalommal ez az, amit ez az egész.
Amikor elkezdünk jön ide, azért, mert az emberek rájöttek
hogyan kell használni az eszközöket.
>> Ők is ugyanezt tették, amikor relációs adatbázisok találták,
és ők váltották fájlrendszereket.
Igyekeztek építeni fájlrendszerek A relációs adatbázisok
mert ez az, amit az emberek megértették.
Ez nem jött be.
Így értelmezte a legjobb gyakorlatok A technológia dolgoztok
hatalmas.
Nagyon fontos.
>> Így fogunk bejutni DynamoDB.
DynamoDB az AWS által teljes mértékben irányított NoSQL platform.
Mit jelent mértékben irányított jelent?
Ez azt jelenti, hogy nem kell igazán aggódni semmit.
>> Bejössz, mondd velünk, szükségem van egy asztal.
Szüksége van ez a sok kapacitást.
Bejön a gombot, és a rendelkezés az infrastruktúrát a kulisszák mögé.
Most, hogy óriási.
>> Mert ha beszélni mintegy méretezés adatbázis,
NoSQL adatok klaszterek skála, futás petabájt,
futás millió tranzakció másodpercenként,
ezek a dolgok nem kisebb csoportokban.
Beszélünk ezer esetben.
Ügyvezető ezer esetben akár virtuális esetekben,
egy igazi fájdalom a seggét.
Úgy értem, gondolni minden alkalommal, amikor egy operációs rendszer patch jön ki
vagy egy új változata az adatbázis.
Az mit jelent Önnek működésében?
Ez azt jelenti, megvan 1200 kiszolgálók frissíteni kell.
Most még automatizálás, amely hosszú időt vesz igénybe.
Hogy okozhat egy csomó működési fejfájás,
mert talán van szolgáltatásokat le.
>> Amint azt frissíteni ezeket az adatbázisokat, én Lehet csinálni, kék, zöld telepítések
ahol telepíteni és frissíteni felét én csomópontok, majd frissíteni a másik felét.
Hogy ezeket le.
Tehát infrastruktúrájának kezelése skála rendkívül fájdalmas.
És AWS veszi, hogy a fájdalom belőle.
És NoSQL adatbázisok, pedig rendkívül fájdalmas
miatt, ahogy skála.
>> Scale vízszintesen.
Ha azt szeretnénk, hogy egy nagyobb NoSQL adatbázis, veszel több csomópontban.
Minden csomópont amit vásárolni Egy másik működési fejfájás.
Szóval valaki erre az Ön számára.
AWS képes erre.
>> Támogatjuk a dokumentum kulcsok értékeit.
Most nem mentünk túl sokat be, a másik chart.
Van egy csomó más ízek NoSQL.
Mind a fajta egyre munged együtt ezen a ponton.
Akkor nézd meg DynamoDB és igent mond, mindketten egy dokumentumot, és a legfontosabb érték
tárolni ebben a kérdésben.
És lehet azzal érvelni a funkciók az egyik a másik felett.
Számomra sok ez valóban hat Egy fél tucat más.
Minden ilyen technológiák egy finom technológia és finom megoldást.
Nem mondanám, MongoDB jobb vagy rosszabb, mint Couch, akkor Cassandra,
majd Dynamo, vagy fordítva.
Úgy értem, ezek csak lehetőségek.
>> Ez gyors és ez következetes bármilyen szinten.
Tehát ez az egyik legnagyobb bónuszokat kapsz AWS.
A DynamoDB az a képesség, hogy egy alacsony egy számjegyű
milliszekundumos késleltetést bármilyen szinten.
Ez volt a tervezés célja a rendszer.
És mi van az ügyfelek, hogy csinálnak Több millió tranzakció másodpercenként.
>> Most átnézzük néhány ilyen Használja esetben néhány perc múlva itt.
Integrált hozzáférést control-- mi hívjuk
Identity Access Management, vagy IAM.
Ez áthatja minden rendszer, Minden szolgáltatás, amely AWS kínál.
DynamoDB sem kivétel.
Akkor hozzáférés szabályozására A DynamoDB táblákat.
Szerte az összes AWS számlái meghatározó hozzáférési szerepkörök és engedélyek
az IAM infrastruktúra.
>> És ez egy alapvető és kulcsfontosságú eleme hívjuk eseményvezérelt programozás.
Most ez egy új paradigma.
>> Közönség: Hogy van a ráta igaz pozitív versus hamis negatív
a beléptető rendszer?
Rick Houlihan: valódi pozitív versus hamis negatív?
Közönség: Visszatérő mit akkor visszatér?
Szemben a hóba, hogy nem tér vissza, ha kell érvényesíteni?
>> Rick Houlihan: nem tudtam megmondani.
Ha van olyan hibák semmiképpen, hogy
Nem vagyok az a személy megkérdezni hogy az adott kérdést.
De ez egy jó kérdés.
Lennék kíváncsi hogy magam, tényleg.
>> És így aztán megint, új paradigma eseményvezérelt programozás.
Ez a gondolat, hogy tudsz telepíteni komplex alkalmazások
működhet egy nagyon, nagyon magas szintű infrastruktúrákkal nem egyáltalán.
Nélkül rögzített infrastruktúra nélkül.
És akkor beszéljünk egy kicsit arról, hogy mit jelent, mint mi
kap, hogy a következő néhány listákon.
>> Az első dolog, amit megteszek ez fogunk beszélni, asztalok.
API adattípusok Dynamo.
És az első dolog, akkor észrevenni, ha megnézi ezt,
Ha még nem ismeri, minden adatbázis, adatbázisok valóban két fajta API-k
Hívnám meg.
Vagy két API.
Az egyik ilyen lenne igazgatási API.
>> A dolog úgy vigyázni a funkciók a adatbázisban.
Konfigurálása tároló motor, felállítása és hozzá táblákat.
adatbázis létrehozása katalógusok és példányok.
Ezek things-- a DynamoDB, akkor nagyon rövid, rövid listák.
>> Tehát más adatbázisok, lehet, hogy több tucat
A parancsok, az adminisztratív parancsokat, konfigurálásához
A további lehetőségek.
Ebben DynamoDB akkor nem kell azokat, mert nem konfigurálja a rendszert, amit csinálunk.
Tehát az egyetlen dolog, amit tennie kell, hogy mondd meg, mit méretű tábla van szükségem.
Így kapsz egy nagyon korlátozott parancsokat.
>> Kapsz egy új táblázat létrehozásához Update, táblázat, Táblázat törlése, és írja táblázat.
Ezek azok a dolgok, csak szükség van DynamoDB.
Nem kell a tárolási motorkonfiguráció.
Nem kell aggódni a replikáció.
Nem kell aggódni sharding.
>> Nem kell aggódni bármilyen ez a cucc.
Tesszük mindezt az Ön számára.
Szóval ez egy hatalmas többlet ez csak emelte ki a lemezt.
Aztán ott van a szifilisz szereplők.
Szifilisz valami, amit mi hívja az adatbázisban, ez
Create, Update, Delete szereplők.
Ezek a közös adatbázis-műveletek.
Dolgok, mint eladási tétel, hogy a tétel, frissítés tételek, törölje elemek, kötegelt lekérdezést, szkennelni.
Ha azt szeretnénk, hogy átvizsgálja a teljes táblázatot.
Húzza le mindent az asztalra.
Az egyik szép dolog DynamoDB ez lehetővé teszi a párhuzamos szkennelés.
Így tulajdonképpen hadd tudja, hogy hány szálak szeretne futni, hogy a vizsgálat.
És tudjuk futtatni azokat a szálakat.
Mi lehet pörögni, hogy átvizsgálja fel több téma
így végig a teljes táblázatot hely nagyon, nagyon gyorsan DynamoDB.
>> A másik API amink van Így hívjuk a Streams API.
Nem fogunk beszélni is sokat erről most.
Van néhány tartalmi később A fedélzeti erről.
De Streams valóban running-- úgy mondanám, hogy az idő megrendelt
és partíció változtatási napló.
Minden, ami történik a A táblázat azt mutatja, akár a patak.
>> Minden levelet az asztalra felbukkan a patak.
Elolvashatja az a folyam, és meg tudod csinálni a dolgokat vele.
Megbeszéljük, mit típusú dolgokat
köze a dolgokat, mint a replikáció, megteremtése másodlagos indexek.
Mindenféle nagyon klassz dolog, amit tehetünk vele.
>> Adattípusok.
Ebben DynamoDB, támogatjuk mindkét kulcsfontosságú érték és a dokumentum adattípusok.
A bal oldalon a képernyő Itt megvan a alaptípusa.
Kulcs érték típusok.
Ezek húrok, szám, és a futtatható fájlok.
>> Tehát csak három alaptípusa.
És akkor lehet készletek e.
Az egyik jó dolog a NoSQL van akkor tartalmazhat tömböket tulajdonságait.
És DynamoDB akkor tartalmazhat tömbök Az alaptípus, mint egy gyökér ingatlan.
>> És akkor ott van a dokumentum típusokat.
Hány ember ismeri a JSON?
Srácok ismeri JSON annyira?
Ez alapvetően a JavaScript, Objektum, jelölés.
Ez lehetővé teszi, hogy alapvetően meghatározzák hierarchikus struktúrába.
>> Tárolhat JSON dokumentum DynamoDB közös összetevők használata
vagy építőelemek, amelyek rendelkezésre állnak A legtöbb programozási nyelv.
Tehát ha van a Java, akkor nézi térképek és jegyzékek.
Én is készített objektumok a területen térképet.
A térképen kulcsértékekkel tárolni tulajdonságait.
És talán van listái belüli értékek ezeket a tulajdonságokat.
Akkor tárolja a komplex hierarchikus felépítés
mint egyetlen tulajdonság Egy DynamoDB elemet.
>> Tehát táblázatok DynamoDB, mint a legtöbb NoSQL adatbázisok, táblázatok tételek.
Ebben MongoDB szeretnéd hívja ezeket a dokumentumokat.
És ez lenne a kanapén bázist.
Szintén egy dokumentumot adatbázisban.
Ezt nevezed te ezeket a dokumentumokat.
Dokumentumokat vagy attribútumokat.
Az attribútumok léteznek, vagy Nem létezik a tételt.
Ebben DynamoDB, van egy kötelező attribútum.
Pont, mint a relációs adatbázisok, van egy elsődleges kulcsot az asztalon.
>> DynamoDB van mit nevezünk kettőskereszt.
Hash kulcsnak egyedinek kell lennie.
Szóval amikor meghatározza a hash tábla, Alapvetően, amit mondok
van minden elem lesz a kettőskereszt gombot.
És minden kettőskereszt gombot egyedinek kell lennie.
>> Minden elem határozza az, hogy egyedi kettőskereszt gombot.
És ott csak az egyik.
Ez rendben van, de sokszor amit az embereknek szükségük
van, amit akarnak ezen a hash gombot, lépjen egy kicsit
mint egy egyedi azonosítót.
Gyakran szeretnénk használni, hogy a kettőskereszt gombot mint a felső szintű összesítés vödör.
És ahogy mi tesszük, hogy a hozzátéve, hogy mit nevezünk tartományban gombot.
>> Tehát ha ez egy hash csak asztal, ez egyedinek kell lennie.
Ha ez egy hash és a tartomány asztalra, a kombinációja a hash és a tartomány
egyedinek kell lennie.
Tehát gondolj, hogy ez így.
Ha van egy fórum.
És a forma téma, azt hozzászólás, és azt válaszokat.
>> Szóval lehet, hogy egy hash gombot, ami a téma azonosítója.
És talán van egy sor kulcsfontosságú, amely a válasz azonosítója.
Így ha azt akarom, hogy minden a válaszokat adott témában,
Én is csak lekérdezni a hash.
Én csak azt mondom, hogy nekem minden Az elemek, amelyek ezt a hash.
És fogok kapni minden kérdést vagy postai úton az adott témában.
Ezek a felső szintű összeállítások nagyon fontosak.
Támogatják az elsődleges hozzáférési minta a kérelmet.
Általánosságban elmondható, hogy ez az az, amit akarok.
Szeretnénk, hogy table-- ahogy betölteni az asztalra,
azt szeretné felépíteni az adatokat belül a táblázat olyan módon
hogy az alkalmazás nagyon gyorsan letölteni az eredményeket.
És sokszor a módja, hogy a fenntartani ezeket a csoportosulásai, mint mi
amibe az adatok.
Alapvetően mi terjed az adatokat a fényes vödör, mert jön.
>> Választék gombok lehetővé teszik me-- hash A kulcsok a egyenlőséget.
Amikor lekérdezés egy hash, azt kell mondanom, adj egy hash, hogy egyenlő ennek.
Amikor lekérdezni egy sor, én lehet mondani, hogy nekem egy tartományban
használó bármilyen Gazdag üzemeltető, hogy támogatjuk.
Add nekem az összes elemet egy hash.
Vajon egyenlő, nagyobb, kevesebb, mint, nem is kezdődik,
Létezik a két érték között?
Tehát az ilyen típusú tartomány lekérdezések hogy mi mindig érdekelt.
Most egy dolog adatok, ha megnézi adatokhoz való hozzáférés, ha
hozzáférést az adatokhoz, ez Mindig csak egy összesítés.
Ez mindig a rekordok hogy kapcsolódik ehhez.
Adj nekem mindent itt that's-- összes A tranzakciók ezt a hitelkártya
az elmúlt hónapban.
Ez egy összesítés.
>> Szinte mindent csinálsz a adatbázis valamilyen összesítés.
Tehát, hogy képes, hogy képes legyen meghatározni Ezek vödrök és adja meg ezeket a tartományban
tulajdonítja, hogy képes lekérdezni a, azok gazdag lekérdezések támogatására számos,
Sok-sok alkalmazás elérhető mintákat.
>> Tehát a másik dolog a kettőskereszt gombot nem az, ez ad nekünk egy mechanizmust
hogy képes terjedni az adatok körül.
NoSQL adatbázisok működnek a legjobban amikor az adatok egyenletesen
elosztva a klaszter.
Hány ember ismeri a hash algoritmusok?
Amikor azt mondom, hash és hashing-- mert egy algoritmus
egy módja, hogy képes generálni egy véletlen értéket adott értéket.
Tehát ebben az esetben a hash algoritmus futunk az ND 5 alapú.
>> És ha van egy azonosító, és ez a az én kettőskereszt gombot, van 1, 2, 3.
Amikor futtatom a hash algoritmust, ez megy, hogy jöjjön vissza, és azt mondják,
valamint 1értéke 7B, 2 egyenlő 48, 3 egyenlő CD-t.
Ők elterjedt az egész kulcsfontosságú helyet.
És miért csinálod ezt?
Mert ami biztos, hogy tudok tedd a feljegyzések több csomópontot.
>> Ha én csinálom ezt inkrementálisan, 1, 2, 3.
És van egy hash-tartományban, fut ebben a konkrét esetben,
egy kis hash helyet, fut 00-tól FF,
akkor a rekordok fognak jönni és ők fognak menni 1, 2, 3, 4, 5,
6, 7, 8, 9, 10, 11, 12.
Mi történik?
Minden betét lesz ugyanazon a csomóponton.
Látod, mire gondolok?
>> Mert amikor szét a térben, és én terjedt ezeket a feljegyzéseket az egész,
és én partíció, fogok mondani 1. partíció van kulcsa tér 0-54.
2. partíciót 55-89.
3. Partíció AA a FF.
Tehát, ha én vagyok a lineárisan növekvõ Azonosítók, akkor láthatjuk, hogy mi történik.
1, 2, 3, 4, 5, 6, minden módon akár 54.
Szóval, mint én vagyok kalapálni a feljegyzések a rendszerbe,
minden ott kötött ki fog egy csomópont.
>> Ez nem jó.
Ez egy antipattern.
Ebben MongoDB van ez a probléma Ha nem használja a kettőskereszt gombot.
MongoDB megadja a lehetőséget, A hashing a legfontosabb érték.
Mindig meg kell csinálni, ha Ön használ egy megnő hash
kulcs MongoDB, vagy ha lesz szegező minden egyes írási hogy egy csomópont,
és akkor korlátozása Ön írási teljesítményt rosszul.
>> Közönség: Ez A9 169 decimális?
>> Rick Houlihan: Igen, ez Valahol ott.
A9, nem tudom.
Te volna, hogy megkapjam a bináris a tizedes számológépet.
Az agyam nem így működik.
Közönség: Csak egy gyorsat a Mongo hozzászólás.
Tehát az a tárgy, azonosító, jön natív Mongo csinálni?
Rick Houlihan: Ez azt csinálni?
Ha megadja azt.
A MongoDB, akkor lehetőség van.
Akkor specify-- minden dokumentum MongoDB rendelkeznie kell egy aláhúzás ID.
Ez az egyedülálló értéket.
>> Ebben MongoDB megadhatja hogy a hash-e vagy sem.
Ők csak megadja a lehetőséget.
Ha tudod, hogy ez az véletlenszerű, nem probléma.
Nem kell ezt tenni.
Ha tudja, hogy ez nem véletlen, hogy a ez megnő, majd tegye a hash.
>> Most a dolog hashing, ha egyszer hash
egy value-- és ez Ezért hash kulcsok mindig
egyedi lekérdezések, mert én változtam az érték, most nem tudok csinálni egy sor kérdés.
Nem tudom megmondani, ez között ezt vagy azt,
mert a hash érték nem megy egyenértékűnek a tényleges érték.
Tehát, ha hash gombot, ez az egyenlőség csak.
Ez az oka annak, DynamoDB kettőskereszt lekérdezések mindig egyenlőség csak.
>> Tehát most egy sor key-- ha hozzáteszem, hogy a tartomány kulcs,
azok körét kulcs bejegyzések mindnyájan és kapnak tárolt ugyanazon a partíción.
Így nagyon gyorsan, egyszerűen visszakeresni, mert ez a hash,
ez az a tartomány.
És látod mindent azonos hash-
kap tárolt ugyanazon a partíción helyet.
Használhatja, hogy a tartomány legfontosabb, hogy segítsen keresse meg a közeli adatok a szülő.
Tehát mi vagyok én valójában mit keresel itt?
Ez egy sok kapcsolat.
A kapcsolat a kettőskereszt és a tartomány legfontosabb az egyik, hogy sok.
Azt lehet több hash kulcsot.
Csak azt tudom, hogy több tartomány kulcsokat minden kettőskereszt gombot.
>> A hash határozza meg a szülő, A tartomány határozza meg a gyerekek.
Tehát láthatjuk, van analóg ide között relációs konstrukció
és az azonos típusú konstrukcióból NoSQL.
Az emberek beszélnek NoSQL a relációs.
Ez nem relációs.
Az adatok mindig kapcsolatokat.
Ezeket a kapcsolatokat csak modellezzük másképp.
Beszéljünk egy kicsit kicsit a tartósság.
Amikor írsz, hogy DynamoDB, írja mindig három-utas terjeszteni.
Azt jelenti, hogy van három az AZ.
Az AZ a Szabad zóna.
Akkor gondolom az Elérhetőség Zóna, mint egy adatközpont
vagy egy gyűjtemény a adatközpontok.
Ezek a dolgok földrajzilag egymástól elszigetelt
különböző törészónákban, az egész más elektromos hálózatok és az árterek.
A kudarc egyik AZ nem megy, hogy vegye le a másik.
Ők is kapcsolódik valamint a sötét szálakat.
Támogat egy al 1 milliszekundumos késleltetést között Azs.
Így a valós idejű adatok ismétlésben Képesek a multi Azs.
>> És sokszor a multi AZ telepítések megfelelnek a magas rendelkezésre állási követelmények
A legtöbb vállalati szervezetek.
Tehát DynamoDB terjed egész három AZS alapértelmezés szerint.
Mi csak akkor fog a tudás az írási amikor két említett három csomópont jön vissza
és azt mondják, igen, megvan.
Miert van az?
Mivel az író oldalán mi csak fog adni az adatokat vissza, amikor
megkapjuk azt a két csomópont.
>> Ha én lemásolják az egész három, és olvasok két,
Én mindig garantált hogy legalább egy
e beolvassa, hogy a legfrissebb adatok másolatát.
Ez teszi DynamoDB következetes.
Most lehet választani, hogy kapcsolja azok következetes leolvassa.
Ebben az esetben fogom mondani, Én csak olvasni egy csomópont.
És nem tudom garantálni, hogy fog hogy a leginkább aktuális adatok.
>> Tehát, ha az írási jön be, ez nem replikálta még,
fogsz kapni a másolatot.
Ez egy végül következetes olvasni.
És mi ez a feléért.
Szóval ez valami gondolkodni.
Amikor olvasod ki DynamoDB, és te felállítása az olvasás képességét
egységek, ha úgy dönt, végül következetes szól, hogy ez egy sokkal olcsóbb,
ez körülbelül feléért.
>> És ez így pénzt takarít meg.
De ez a választás.
Ha szeretne egy állandó olvasási vagy Egy végül következetes olvasni.
Ez olyasmi, hogy lehet választani.
>> Beszéljünk indexek.
Így már említettük, hogy felső szintű összesítés.
Megvan hash kulcsok, és megvan tartományban kulcsokat.
Ez szép.
És ez az elsődleges tábla, I Van egy kettőskereszt gombot, kaptam egy tartományban gombot.
>> Az mit jelent?
Nekem is van egy tulajdonság, amit futhat gazdag lekérdezéseket.
Ez a tartomány gombot.
A másik attribútumokat, hogy item-- Azt lehet szűrni azokat a tulajdonságokat.
De nem tudok olyan dolgokat, mint ez kezdődik, vagy nagyobb, mint.
>> Hogyan tudom ezt megtenni?
Én létrehoz egy indexet.
Van kétféle indexek DynamoDB.
Az index valóban Egy másik nézet az asztalra.
És a helyi másodlagos index.
>> Az első fogunk beszélni.
Tehát a helyi secondaries vannak együtt éltek ugyanazon a partíción, mint az adatok.
És mint ilyen, ezek a az azonos fizikai csomóponton.
Ők mit nevezünk következetes.
Jelentése, akkor elismerik Az írási együtt az asztalra.
Ha az írási érkezik, azt írjuk át az index.
Majd írjuk fel az asztalra, és akkor majd elismerni.
Szóval ez következetes.
Miután az írás volt elismerte az asztaltól,
akkor garantált, hogy a helyi másodlagos index
ugyanaz lesz a jövőkép adatok.
De mit tesznek lehetővé, amit csinál, meghatározzák alternatív tartományban kulcsokat.
>> Van, hogy ugyanazzal a hash gombot, mint az elsődleges tábla,
mert együtt elhelyezkedik ugyanazon a partíción, és ők következetes.
De azt is létrehoz egy indexet különböző tartományban kulcsokat.
Így például, ha lenne egy gyártó hogy volt egy nyers résztáblázatig jön.
És nyers részek jönnek, és ők összesítve szerelvény.
És talán van egy visszahívás.
>> Bármilyen része volt, hogy az ebből az gyártó ezen időpontot követően,
Meg kell húzni a sort.
Tudok pörögni index hogy fognak nézni,
összesítése napján gyártását az adott részt.
Tehát, ha én legfelső szinten asztal Már hashed gyártó,
Talán ez volt elhelyezve része azonosító, én létrehozhat egy index le az asztalhoz
a kivonatolt gyártó és mozgott a gyártás időpontját.
És így azt is mondhatnám, hogy semmit gyártották különböző időpontok között,
Meg kell húzni a vonalat.
Szóval ez egy helyi másodlagos index.
>> Ezek a hatása, korlátozza a kettőskereszt gombot helyet.
Mert együtt létezett ugyanazon a tárolási csomópont,
korlátozzák a kettőskereszt gombot tér 10 gigabájt.
DynamoDB alatt asztalok, szétoszlik
A táblázat minden 10 gigabájt.
Amikor fel 10 giga adatok azt go [PHH], és mi adjuk hozzá egy másik csomópont.
>> Mi nem osztott az LSI A több partíció.
Majd szét a táblázatot.
De nem fogjuk megosztani az LSI.
Szóval ez valami Fontos, hogy megértsük
van, ha csinálsz nagyon, Nagyon, nagyon nagy összeállítások,
akkor fogsz korlátozni 10 gigabájt a LSI-k váltották.
>> Ha ez a helyzet, amit lehet használja a globális secondaries.
Globális állórészek Tényleg egy másik asztalhoz.
Léteznek teljesen kikapcsol, hogy oldalán az elsődleges tábla.
És engedjék meg, hogy talál egy merőben eltérő szerkezetű.
Így gondolok rá, mint adat kerül beillesztésre két különböző táblák, strukturált
két különböző módon.
>> Azt is meghatározhatja teljesen különböző kettőskereszt gombot.
Azt is meghatározhatja teljesen különböző tartományban gombot.
És tudom futtatni ezt Teljesen függetlenül.
Ami azt illeti, én már tartalékolni az én olvasási képességét
és írd kapacitás én globális másodlagos indexek
Teljesen függetlenül az én elsődleges tábla.
Ha én határozzák meg, hogy az indexek, elmondom ez mennyit írni és olvasni
kapacitása ez lesz használva.
>> És ez külön az én elsődleges tábla.
Most mind a mutatók lehetővé teszik számunkra, hogy Nem csak azokat hash és a tartomány kulcsok,
de engedje meg, hogy projekt további értékeket.
Tehát, ha azt akarom, hogy olvassa el az index, és azt akarom, hogy egy kis adathalmazt,
Nem kell, hogy menjen vissza a fő táblázatban, hogy a kiegészítő attribútumokat.
Azt lehet vetíteni azokat a kiegészítő attribútumok be a táblázatba
hogy támogassa a hozzáférési minta.
Tudom, hogy valószínűleg bekerülni valamilyen Tényleg, really-- bekerülni a gyomok
itt néhány dolgot.
Most kaptam sodródni ki ebből.
>> Közönség: [hallható] --table kulcsot jelent egy hash?
Az eredeti hash?
Multi-léc?
>> Rick Houlihan: Igen.
Igen.
A tábla kulcs alapvetően rámutat vissza az elemet.
Tehát egy index mutató vissza az eredeti példány az asztalra.
Most lehet választani, hogy építsenek egy index, amely csak a tábla kulcs,
és nincs más tulajdonságokkal.
És miért lehet ilyet?
Nos, lehet, hogy van nagyon nagy tételek.
>> Én tényleg csak akkor kell tudni which-- én hozzáférést mintát lehet mondani,
mely tételeket tartalmazza ezt az ingatlant?
Nem kell, hogy térjen vissza az elemet.
Én csak meg kell tudni mely tételeket tartalmazza azt.
Szóval lehet építeni indexek hogy csak a tábla kulcs.
>> De ez elsősorban mi Az index adatbázis számára.
Ez az, hogy képes gyorsan azonosítani, amely rögzíti,
mely sorok, amelyek tételek a táblázatban
A tulajdonságokat keresem.
>> GSIS, hogy hogyan működnek?
GSIS alapvetően aszinkron.
A frissítés érkezik az asztalra, asztal ezután aszinkron frissítve
az összes GSIS.
Ez az, amiért GSIS vannak végül következetes.
>> Fontos megjegyezni, hogy a ha építesz GSIS,
és megérted te létre egy másik dimenziója aggregation--
Most mondjuk egy jó példa Itt a gyártó.
Azt hiszem, már beszéltem orvosi eszköz gyártója.
Az orvostechnikai eszközök gyártói sokszor van folytatásos részek.
A részek, hogy bemegy csípőprotézis összes
Van egy kis sorozatszámot rájuk.
És akár több millió is, és millió vagy milliárd alkatrészek
minden eszközt, hogy az általuk szállított.
Nos, meg kell összesíteni alatt különféle méretek, az összes alkatrész
Egy összeállítás, minden részek készültek
egy bizonyos vonal, minden Az alkatrészeket kapott
magának egy bizonyos gyártó Egy bizonyos időpontban.
És ezek csoportosulásai néha kelj fel a milliárdokat.
>> Szóval dolgozni néhány ezek a srácok, akik szenvednek
mert ők létrehozása Ezek ginormous csoportosulásai
A másodlagos indexek.
Lehet, hogy egy nyers részek táblázatot, hogy jön a hash csak.
Minden rész egy egyedi sorszámot.
Én a sorszámot a hash.
Ez gyönyörű.
Saját nyers adatok táblázatban terjed szerte a legfontosabb helyet.
Az én [? ír ?] [? lenyelés?] félelmetes.
Veszek egy csomó adat.
Akkor mit csinálnak ők hozzon létre egy GSI.
És én azt mondom, tudod mit, azt kell látni minden alkatrész Ennek a gyártónak.
Nos, hirtelen vagyok vesz egy milliárd sorok,
és cucc őket rá egy csomópontot, mert amikor
Én összesítik a gyártó azonosítót, mint a hash,
és cikkszám, mint a tartomány, akkor minden hirtelen vagyok
amivel egy milliárd rész azzá ez a gyártó megszabadított engem.
>> Ez is okozhat sok A nyomás a GSI,
újra, mert én kalapálni egy csomópont.
Leteszem mindezeket illesztett egy csomópont.
És ez egy igazi problémás használat esetén.
Most kaptam egy jó design minta, hogyan lehet elkerülni, hogy.
És ez az egyik probléma hogy én mindig működnek.
De mi történik, az a GSI lehet nincs elég kapacitás írási
hogy képes legyen nyomja mindazoknak sorok egyetlen csomópontot.
És mi történik akkor a elsődleges, az ügyfél asztal,
Az elsődleges tábla lesz fojtva mert a GSI nem tud lépést tartani.
Szóval a betét ráta, akkor esik az elsődleges tábla
mint az én GSI próbál lépést tartani.
>> Rendben, GSI, LSI-k, melyiket érdemes használni?
LSI-k következetes.
GSI-k végül következetes.
Ha ez rendben van, még mindig ajánlott a GSI, ők sokkal rugalmasabb.
LSI által lehet modellezni, mint egy GSI.
És ha az adatok mérete per hash kulcsot a gyűjtemény meghaladja a 10 gigabájtot,
akkor fogsz szeretné használni, hogy GSI, mert ez csak egy kemény korlátot.
>> Rendben, skálázás.
Átmenő Dynamo DB, akkor Can rendelkezés [hallhatatlan]
átmenő egy asztalhoz.
Jelenleg az ügyfelek, hogy van tartalékolni 60 billion--
csinálnak 60 milliárd kéréseket, rendszeresen futó több mint egy millió kérések
másodpercenként az asztalunkra.
Már tényleg nincs elméleti határ, hogy mennyi
és milyen gyorsan az asztalra futtatható Dynamo DB.
Vannak olyan puha korlátokat fiókját
hogy mi tesz oda, így hogy nem megbolondul.
Ha többet szeretne, mint hogy, nem probléma.
Gyere mondani.
Majd kapcsolja ki a tárcsát.
>> Minden fiók korlátozódik valamilyen szinten Minden szolgáltatás, csak kapásból
így az emberek nem mennek őrült magukat bajba.
Nincs határ méretű.
Tudod, hogy bármennyi A tételek egy asztalon.
A méret egy tétel korlátozva 400 kilobájt minden,
hogy lenne tétel nem az attribútumokat.
Tehát az összeg az összes attribútumok korlátozódik 400 kilobájt.
És akkor megint, van hogy a kis LSI kérdés
A 10 GB-os korlát hash.
Közönség: Kis számú, vagyok, hiányzik mit mondasz nekem, hogy is--
Közönség: Ó, 400 kilobájt a legnagyobb méret db áron.
Tehát egy elem minden jó tulajdonsága.
Tehát 400 k a teljes mérete ezen tárgy, 400 kilobájt.
Tehát az összes attribútum egyesítjük, az összes adatot
ez mindazon tulajdonságokat, tekerni a teljes mérete,
Jelenleg ma az elem határ 400 k.
Tehát méretezés ismét elért a particionálás.
Áteresztőképesség tartalékolni a tábla szinten.
És ott tényleg két gomb.
Azt olvastam kapacitás írni és kapacitás.
>> Szóval ezek vannak beállítva egymástól függetlenül.
Távirányító intézkedése szigorúan következetes szól.
OK, így ha azt mondod akarok 1000 Távirányító által azok szigorúan következetes,
azok konzisztensek szól.
Ha azt mondod akarok esetleges következetes olvasás,
akkor a rendelkezés 1000 Távirányító által, fogsz
hogy 2000-utóbb következetes szól.
És fél áron azoknak, végül áll szól.
>> Ismét igazított egymástól függetlenül.
És van a throughput-- Ha fogyaszt 100% -a távirányító,
nem fogod befolyásolja a elérhetőségét a jogait.
Szóval ezek teljesen egymástól független.
Rendben, tehát az egyik dolog, hogy Említettem röviden volt fojtás.
Fojtás rossz.
Fojtás jelzi rossz nincs SQL.
Vannak dolgok, amit tehetünk, hogy segítsen enyhíteni a fojtás, hogy
tapasztal.
De a legjobb megoldás hogy ez vessünk
Nézd meg, mit csinálsz, mert van egy anti-minta játékban van.
>> Ezek a dolgok, dolgok, mint a nem egyenletes munkaterhelés, gyorsbillentyűk, forró partíciókat.
Én üti egy adott kulcs teret Nagyon nehéz néhány különös oka.
Miért csinálom ezt?
Nézzük kitalálni.
Én vagyok keverést én forró adatokat hideg adatokat.
Hagylak én asztalok kap Hatalmas, de tényleg
csak néhány részhalmaza az adatok ez igazán érdekes számomra.
Tehát napló adatok, például a sok ügyfelek kapnak jelentkezzen adat minden nap.
Kaptak egy hatalmas log adatok.
>> Ha most dömping minden napló adatot egy nagy asztal, idővel
E táblázat fog kapni hatalmas.
De én tényleg csak az érdekli, elmúlt 24 órában, az utolsó hét nap,
Az elmúlt 30 napban.
Bármi legyen is az idő-ablak hogy Érdekelne keres
Az esetben, ha zavar engem, vagy Amennyiben érdekes számomra,
ez az egyetlen ablak alkalom, hogy szükségem van.
Miért is vagyok üzembe 10 éves Érdemes log adatok a táblázatban?
Mi okozza a A táblázatban a fragmentumot.
>> Egyre hatalmas.
Ez kezd el terjedni ki szerte több ezer csomópont.
És mivel a kapacitás olyan alacsony, te
ténylegesen sebesség korlátozás minden az egyik ilyen egyes csomópontok.
Szóval kezdjük nézi, hogyan nem dobunk a táblázat fölött.
Hogyan kezeljük az adatokat egy kicsit jobb elkerülni ezeket a problémákat.
És ez mit néz ki?
Ez az, amit úgy néz ki, mint a.
Ez az, amit a rossz NoSQL néz ki.
>> Kaptam egy forró kulcs itt.
Ha megnézed az oldalán van, ezek mind az én partíciókat.
Kaptam 16 partíciók ide ezen a bizonyos adatbázisban.
Tesszük ezt minden alkalommal.
Én vezetem ezt az ügyfelek minden alkalommal.
Ezt hívják a hőtérkép.
Hőtérkép azt mondja nekem, hogy hogyan te hozzáférését a kulcsfontosságú helyet.
És mi ez mesélsz hogy van egy bizonyos hash
hogy ez a pasi szeret egy borzasztó sok, mert ő
üti meg nagyon, nagyon nehéz.
>> Így a kék szép.
Szeretjük kék.
Mi nem tetszik a piros.
Red, ahol a nyomás feláll, hogy 100% -os.
100%, most fogsz prioritású.
Szóval, ha lát piros vonalak, mint this-- és ez nem csak Dynamo DB--
Minden NoSQL adatbázis küzd ezzel a problémával.
Vannak anti-minták, amelyek vezetni az ilyen típusú feltételek.
Amit én csinálok, akikkel dolgozom ügyfelekkel enyhíteni ezeket a feltételeket.
>> És ez mit néz ki?
És ez kezd a legtöbb ki Dynamo DB áteresztőképességű,
de ez tényleg kezd A legtöbbet hozza ki a NoSQL.
Ez nem korlátozódik a Dynamo.
Ez definitely-- I Régebben a Mongo.
Tisztában vagyok a sok NoSQL platformokon.
Mindenkinek ilyen típusú A gyorsgomb problémákat.
Ahhoz, hogy a legtöbbet hozza ki minden NoSQL adatbázis, konkrétan Dynamo DB,
szeretne létrehozni a táblák ahol a kettőskereszt gombot elem
nagy számú különböző értékek, a magas fokú számosságú.
Mert ez azt jelenti, írok hogy sok különböző vödrök.
>> Minél több vödör vagyok írásban, annál valószínűbb,
Én vagyok az terjedt el, hogy írási terhelés vagy load ki szerte több csomópont,
annál valószínűbb vagyok, hogy egy nagy áteresztőképességű az asztalra.
És akkor azt szeretné, hogy az értékek, hogy kért meglehetősen egyenletesen idő
és egyenletesen véletlenszerűen, mint lehetséges.
Nos, ez elég érdekes, mert nem tudok igazán
vezérlés, a felhasználók jönnek.
Szóval elég mondani, ha kenjük dolgokat szerte a legfontosabb helyet,
akkor valószínűleg jobb formában.
>> Van egy bizonyos időt szállítás
hogy nem mész hogy képes ellenőrzés.
De ezek tényleg a két dimenzióban, hogy van,
hely, hozzáférés egyenletesen terjedése, az idő, kérések
érkező, egyenletesen elosztva az időben.
És ha ezt a két feltételek teljesülnek,
akkor ez az, amit ez fog kinézni.
Ez sokkal szebb.
Vagyunk igazán boldog itt.
Van egy nagyon kiegyenlített hozzáféréssel mintát.
Igen, talán kapsz egy kis nyomás hébe-hóba,
de semmi igazán túlságosan kiterjedt.
Szóval ez elképesztő, hogy sokszor, amikor dolgozom ügyfelekkel,
hogy első grafikon a nagy piros bár és minden, ami csúnya sárga ez
az egész hely, amit jusson ennek gyakorlása
után egy pár hónap A re-architektúra,
ők futó pontosan ugyanolyan munkateher pontosan ugyanazt a terhelést.
És ez az, amit keres, mint most.
Szóval mit kap a NoSQL egy adatok séma, amely teljesen
kötődik a hozzáférést mintát.
>> És ha lehet optimalizálni az adatokat séma támogatni, hogy a hozzáférés mintát.
Ha nem, akkor fogsz hogy az ilyen típusú problémák
azokkal gyorsbillentyűk.
>> Közönség: Nos, óhatatlanul néhány helyen lesznek melegebb, mint mások.
>> Rick Houlihan: Mindig.
Mindig.
Igen, úgy értem mindig van egy-- és újra, van
Néhány tervezési minták fogjuk átvészelni hogy fog beszélni, hogy hogyan kezeled
ezekkel a szuper nagy összeállítások.
Úgy értem, kaptam őket, hogyan kezeljük őket?
Kaptam egy nagyon jó hasznát esetén hogy fogunk beszélni, hogy.
>> Rendben, akkor beszéljünk néhány ügyfelek most.
Ezek a srácok AdRoll.
Nem tudom, ha ismerik AdRoll.
Valószínűleg látni őket Sok a böngészőben.
Ők ad újracélzás, ők A legnagyobb hirdetési újracélzás üzleti
kint.
Ezek általában rendszeresen elgázolta 60 milliárd tranzakció naponta.
Csinálnak több mint egy millió tranzakció másodpercenként.
Már van egy elég egyszerű táblázatot szerkezete, a legforgalmasabb asztalra.
Ez alapvetően csak egy hash kulcs a sütit,
a tartomány a demográfiai kategóriát, majd
A harmadik tulajdonság az állás.
>> Tehát mi minden van a cookie-k böngészőnk a srácoktól.
És ha elmész egy résztvevő kereskedő,
Alapvetően gólt akkor az egész különböző demográfiai kategóriák.
Amikor elmész egy honlapot, és mondasz Látni akarom ezt a ad--
vagy alapvetően nem mondod, hogy-- de ha megy a honlap
Azt mondják szeretné látni ezt a hirdetést.
És mennek kap, hogy hirdetése AdRoll.
AdRoll néz téged az asztalukon.
Megtalálják a cookie.
A hirdetők mondja őket, azt akarom, hogy valaki
aki középkorú, 40 éves férfi, a sport.
És gólt akkor azokban a demográfiai és ők döntenek arról,
ez egy jó reklám az Ön számára.
>> Most, hogy van egy SLA a a hirdetési szolgáltatók
hogy al-10 milliszekundumos válasz minden egyes kérelmet.
Tehát ők a Dynamo DB erre.
Ők elér minket egy millió kérelmek másodpercenként.
Ők tudják, hogy nem minden kereséseket, osztályozás minden adatot,
és kap, hogy add linket vissza, hogy hirdetőnek alatt 10 ms.
Ez tényleg nagyon fenomenális végrehajtása, hogy van.
>> Ezek a srácok actually-- ezek a srácok.
Nem vagyok biztos benne, hogy ezek a srácok.
Lehet, hogy ezek a srácok.
Alapvetően azt mondta us-- nem, Nem hiszem, hogy ők voltak.
Azt hiszem, valaki más volt.
Én dolgoztam egy ügyfél, hogy azt mondta,
hogy most, hogy már elment a Dynamo DB, ők
több pénzt költünk snack a fejlesztő csapat minden hónapban
mint amennyit költeni az adatbázisba.
Tehát kapsz egy elképzelést, hogy a költségmegtakarítás
hogy lehet kapni a Dynamo DB hatalmas.
Rendben, dropcam egy másik cég.
Ezek a srác kedves of-- ha úgy gondolja, A tárgyak internete, dropcam
alapvetően internetes biztonsági videó.
Ön tesz a kamerát odakint.
Fényképezőgép egy mozgásérzékelő.
Valaki jön, elindít egy cue pont.
Rögzítés indítása egy darabig, amíg nem talál semmilyen mozgást többé.
Helyezi, hogy a videó fel az interneten.
>> Dropcam volt olyan cég, amely Alapvetően váltott Dynamo DB
mert volt tapasztalható Hatalmas növekedési fájdalom.
És mi azt mondták, Hirtelen petabájt adat.
Fogalmuk sem volt, a szolgáltatás ilyen sikeres lesz.
Több bejövő videó, mint a YouTube az, amit ezek a srácok egyre.
Az általuk használt DynamoDB követni az összes metaadatokat minden videó kulcsfontosságú pontokat.
>> Tehát ezek S3 kanalak kinyomják minden bináris melléktermékeit.
És akkor már Dynamo DB rekordok
pont az emberek azokra S3 három tárgyat.
Amikor meg kell nézni egy videót, ezek a rekordot megkeresni a Dynamo DB.
Ezek a linkre kattintva.
Úgy húzza le a videót S3.
Szóval ez a fajta, amit ez úgy néz ki, mint.
És ez egyenesen a csapat.
>> Dynamo DB csökkenti szállítási idő a video események
öt és 10 másodperc.
Hogy idős relációs boltban, szoktak menni, és végre
többszörösen összetett lekérdezések figura hogy mely videókat, hogy húzza le,
kevesebb, mint 50 milliszekundum.
Tehát ez hihetetlen, elképesztő mennyit teljesítményű
akkor kap, amikor optimalizálják és hangol a mögöttes adatbázis
hogy támogassa a hozzáférési minta.
Halfbrick, ezek a srácok, mi ez, Fruit Ninja Azt hiszem, ez a dolog.
Hogy minden fut Dynamo DB.
És ezek a srácok, hogy van egy nagy fejlesztőcsapat, nagy fejlődés
üzlet.
>> Nem jó ops csapat.
Nem volt sok működési forrásokat.
Ők küzdenek próbálják tartani alkalmazásuk infrastruktúrájukat
és fut.
Jöttek hozzánk.
Úgy nézett, hogy Dynamo DB.
Azt mondták, hogy ez a számunkra.
Ők építették az egész alkalmazás-keretrendszer rajta.
Néhány igazán szép hozzászólás itt a csapat, hogy képesek
hogy ezentúl az épületben a játék, és nem
amelynek fenntartása infrastruktúra, amely
vált a hatalmas mennyiségű A rezsi a csapatnak.
Szóval ez az, amit a hogy-- hasznot, amit kap Dynamo DB.
>> Rendben, bekerülni adatmodellezés itt.
És beszélgettünk egy kicsit a ez a 1-1, az egyik, hogy sok,
és sok sok típusú kapcsolatokat.
És hogyan kezelni ezeket a Dynamo.
Ebben Dynamo DB használjuk indexek, általánosságban elmondható,
forgatni az adatokat egy ízt a többi.
Hash kulcsok, kulcsok körét, és az indexek.
>> Ebben a konkrét Például a legtöbb állam
Van egy engedélyezési kötelezettség, hogy csak egy jogosítványt fejenként.
Nem mehetsz, hogy két vezető engedélyeket az állam Boston.
Nem tehetem meg Texasban.
Ez a fajta, ahogy van.
És így a DMV, van kereséseket, mi szeretnéd nézni a jogosítvány
a társadalombiztosítási szám.
Azt akarom, hogy néz ki a felhasználói adatokat A vezetői engedély száma.
>> Tehát lehet, hogy egy felhasználó tábla van egy kettőskereszt gombot a sorozatszám,
vagy a társadalombiztosítási szám, és különféle attribútumok határozzák meg a tételt.
Most az asztalon I lehetne meghatározni a GSI, hogy
kibukik, hogy körül, hogy azt mondja, szeretnék kettőskereszt a licencet, majd
minden más elem.
Most, ha akarok kérdezni, és megtalálja a engedély száma bármely adott Szociális
Biztonsági száma, tudok lekérdezni a főtábla.
>> Ha azt szeretnénk, hogy a lekérdezés, és azt akarom, hogy a társadalombiztosítási
szám vagy más attribútumok által engedély száma, tudom kérdezni a GSI.
Ez a modell, hogy az egyik hogy egy kapcsolat.
Csak egy nagyon egyszerű GSI, fordítsa ezeket a dolgokat.
Most beszéljünk egy a sok.
Az egyik, hogy sok alapvetően A hash tartományban gombot.
Ahol kap egy csomó ezzel felhasználása esetén a monitor adatai.
Monitor adatai jön a rendszeres intervallum, mint a tárgyak internete.
Mi mindig az összes ilyen megjelenésekkel minden alkalommal.
>> És azt akarom, hogy megtalálja az összes mért között egy adott időszakban.
Ez egy nagyon gyakori lekérdezés monitoring infrastruktúra.
Az út megy róla, hogy megtaláljuk a egyszerű tábla szerkezete, egy asztalnál.
Van egy eszköz mérési asztal A kettőskereszt gombot a készüléken ID.
És van egy sor kulcsfontosságú a időbélyeg, vagy ebben az esetben, az epikus.
És ez lehetővé teszi számomra, végre komplex lekérdezéseket, hogy a tartomány kulcs
és vissza azokat a rekordokat, hogy relatív az eredmény
beállítani, hogy keresem.
És épít, hogy az egyik sok kapcsolat
a primer táblázat felhasználásával kettőskereszt gombot, tartomány kulcs szerkezete.
>> Szóval ez a fajta beépített Írja be a táblázatba a Dynamo DB.
Amikor meg egy hash és a tartomány t tábla vagyok
meghatározó egy a sok kapcsolatot.
Ez a szülő-gyermek kapcsolat.
>> Beszéljünk sok hogy sok kapcsolatot.
És ezen a konkrét példában, megint megyünk használni GSI.
És beszéljünk játék forgatókönyv, ahol van egy adott felhasználó.
Azt akarom, hogy megtudja, az összes játékot, ő regisztrált vagy játszanak.
És az adott játék, én szeretné megtalálni minden felhasználó számára.
Szóval hogyan tudom megtenni?
Saját felhasználói játékok asztalra, megyek hogy egy kettőskereszt gombot a felhasználói azonosítót
és egy sor kulcsfontosságú a játék.
>> Tehát egy felhasználó több játékot.
Ez egy egy a sok közötti kapcsolat a felhasználó és a játékok játszik.
És akkor a GSI, Majd fordítsa, hogy bárhol.
Majd Hash a játékot, és Majd terjedhet a felhasználó.
Tehát, ha azt akarom, hogy minden a játék a felhasználó játszik,
Majd kérdezni a főtábla.
Ha azt akarom, hogy minden felhasználó számára hogy játszanak egy adott játékban,
Azt kérdezni a GSI.
Így látod, hogyan tudjuk ezt megtenni?
Ön építeni ezeket a GSI, hogy támogassa a felhasználása az esetben a kérelmet, a hozzáférési
minta, az alkalmazás.
>> Ha kell kérdezni a Ebben a dimenzióban, hadd
nekem, és indexelheted ezt a dimenziót.
Ha nem teszem, nem érdekel.
És a felhasználástól függően az esetben azt szükség lehet az index, vagy talán nem.
Ha ez egy egyszerű egy a sok, Az elsődleges tábla rendben van.
Ha kell tennem ennyi az Sok-k, vagy ki kell tegye, hogy azok,
akkor talán nem kell a második az index.
Tehát minden attól függ, mit akarok csinálni
és amit én próbálok rutinos.
>> Valószínűleg nem fogom költeni túl sok időt beszélünk dokumentumokat.
Ez lesz egy kicsit, talán, mélyebb, mint azt kell menni.
Beszéljünk egy kicsit a gazdag keresett kifejezést.
Tehát a Dynamo DB van a képesség, hogy hozzon létre
hívjuk vetítés kifejezéseket.
Vetítési kifejezések egyszerűen felvette a mezei és az értékeket
hogy a megjeleníteni kívánt.
OK, szóval hogy egy választás.
Azt, hogy egy lekérdezést Dynamo DB.
És én azt mondom, tudod mit, show nekem csak az öt csillagos értékelés alapján
e konkrét termék.
Szóval ez minden, amit látni akarnak.
Nem akarom látni az összes más attribútumait a sor,
Én csak azt szeretném látni ezt.
Olyan ez, mint az SQL, ha azt mondják, válassza a csillag vagy táblázatból,
kapsz mindent.
Amikor azt mondom, válasszuk a nevét asztal, én csak kap egy attribútum.
Ez ugyanaz a fajta dolog Dynamo DB vagy más NoSQL adatbázisok.
Szűrőkifejezések engedje meg, hogy Alapvetően vágni az eredmény meg lefelé.
Szóval, hogy egy lekérdezés.
Kérdés kiújulhat 500 példány.
De én csak azt akarom, hogy a tételek más tulajdonsága van, hogy ezt mondja.
OK, úgyhogy kiszűrni azokat a témákat, amelyek nem felelnek meg az adott lekérdezés.
Tehát van szűrőkifejezések.
>> Szűrés kifejezéseket futtatható bármely attribútum.
Ők nem szeretik tartományban lekérdezéseket.
Kérdések merülnek fel szelektívebb.
Szűrés lekérdezések igényel, hogy menjek hogy a teljes eredmény eléréséhez, majd
faragni az adatok nem akarom.
Miért fontos ez?
Mert olvastam az egészet.
Egy lekérdezés, fogok olvasni és ez lesz egy óriási mintegy adatokat.
És akkor fogok faragni, amire szükségem van.
És ha én csak elhagyásával, a pár sort, akkor ez rendben van.
Ez nem olyan hatékony.
>> De ha olvasok egy egész halom adatokat, csak faragni egy tétel,
akkor én leszek a jobb off-ban, több lekérdezést,
mert az sokkal szelektívebb.
Meg fog menteni nekem egy csomó pénzt, mert azt fizetni, hogy olvasni.
Amennyiben az eredmények, hogy jön vissza határon, hogy a huzal kisebb lehet,
de én fizetem az olvasási.
Szóval értem, hogy kapsz az adatokat.
Ez nagyon fontos a Dynamo DB.
>> Feltételes kifejezések, ez az, amit nevezhetünk optimista zár.
Frissítés ha létezik, vagy ha ez az érték megegyezik azzal, amit az általam megadott.
És ha van egy időbélyeg egy rekord, talán olvassa az adatokat.
Lehet változtatni az adatokat.
Elmehetnék írási hogy adatok vissza az adatbázisba.
Ha valaki megváltoztatta a rekordot, Az időbélyeg megváltozhatott.
És így én feltételes frissítés mondhatnánk frissítés
ha a timestamp értéke ennek.
Vagy a frissítés sikertelen lesz, mert valaki frissítette a rekord időközben.
>> Ez az, amit nevezünk optimista zárolást.
Ez azt jelenti, hogy valaki jöhet, és változtassa meg,
és fogok észlelni azt mikor megy vissza kell írni.
És akkor én is olvasni, hogy adatokat, és azt mondják, ó, megváltoztatta ezt.
Meg kell elszámolnia, hogy.
És tudom változtatni az adatokat én rögzíteni és alkalmazni egy frissítést.
Szóval lehet elkapni azokat a járulékos frissítések között bekövetkezett ideje
hogy olvassa el az adatokat és a alkalommal lehet írni az adatokat.
>> Közönség: És a szűrőt véleménynyilvánítás valójában azt jelenti, nem
A szám vagy nem--
>> [Közbeiktatásával VOICES]
Rick Houlihan: nem fogok túl sok ebbe.
Ez egy tartalék kulcsszó.
A font nézet egy fenntartva kulcsszó Dynamo DB.
Minden adatbázis saját fenntartva nevek gyűjtemények nem tudod használni.
Dynamo DB, ha megadja egy font előtt ez,
megadhatjuk azokat a neveket fölé.
Ez egy hivatkozott érték.
Ez valószínűleg nem a legjobb szintaxis odafenn erre a vitára,
mert ez lesz a néhány real-- Azt már beszélt több
erről egy mélyebb szinten.
>> De elég mondani, ez lehet legyen lekérdezés beolvasni, ahol views--
sem font nézetek nagyobb, mint 10.
Ez egy numerikus érték, igen.
Ha azt szeretnénk, beszélhetünk hogy miután a vitát.
Rendben, szóval bekerülni Egyes esetekben a legjobb gyakorlatok
hová megyünk beszélni néhány apps itt.
Melyek a használati esetek Dynamo DB.
Melyek a tervezési minták Dynamo DB.
>> És az első megyünk beszélni a tárgyak internete.
Így kapunk egy csomó of-- azt hiszem, mi it-- több mint 50%
A forgalom az interneten ezekben a napokban ténylegesen által generált gépek,
automatizált folyamatok, és nem az emberek.
Úgy értem ezt a dolgot, ez a dolog, hogy Ön viselheti a zsebedben,
hogy mennyi adat, hogy ez a dolog tényleges elküldése körül nélküled
tudom, hogy ez teljesen elképesztő.
Az Ön helye, információk milyen gyorsan mész.
Mit gondolsz, a Google Maps munkák ha azt mondják nektek, amit a forgalom.
Ez azért van, mert több millió és emberek milliói vezetői körül
A telefonok küld adatok az egész hely minden alkalommal.
Tehát az egyik dolog erről a típusú adatok
hogy jön, monitor adatai, jelentkezzen adatok, idősorok, van ez
Általában csak érdekes Egy kis idő.
Ekkortól ez nem annyira érdekes.
Szóval beszélgettünk, ne hagyd, E táblázatokban korlátok nélkül bõvíthetõ.
Az elképzelés az, hogy talán kaptam 24 órányi események a meleg asztalra.
És, hogy a forró asztal lesz tartalékolni egy nagyon magas arány,
mert túl sok időt vesz egy csomó adat.
Ez eltart egy csomó adat és olvasok sokat.
Van egy csomó működése lekérdezések futás ellen, hogy az adatokat.
>> 24 óra után, hé, te Tudod mit, nem érdekel.
Így talán minden éjfél tekercs én asztalomnál át egy új táblát
és én deprovision ebben a táblázatban.
És én viszem a távirányító és a WCU lent, mert 24 órával később
Nem futok annyi lekérdezéseket, hogy az adatok.
Így fogok pénzt takarít meg.
És talán 30 nap múlva én nem is kell törődni az egészet.
Tudtam venni a WCU a egészen egy,
mert tudod mit, ez nem is fog írni.
Az adatok 30 napos.
Ez sosem változik.
>> És ez szinte nem is fog olvasni, úgyhogy csak hogy ezt a távirányító és 10.
És én megtakarítás egy csomó pénzt erre adatokat, és csak fizet a meleg adatok.
Szóval ez a lényeg, hogy nézd A ha megnézed egy idősor
érkező adatok volumene.
Ezek stratégiák.
Most tudtam csak hagyjuk, hogy minden megy ugyanannál az asztalnál
és csak hagyja, hogy a tábla nőnek.
Végül, megyek lásd teljesítménnyel kapcsolatos problémák.
Megyek kell kezdeni archiválásához bizonyos, hogy az adatok le az asztalra,
miegymás.
>> Nézzük sokkal jobb úgy az alkalmazást
így működik ez a módja a jobb.
Tehát csak az automatikus az alkalmazás kódját.
Éjfélkor minden este nem gördül az asztalra.
Talán amire szükségem van egy csúszó ablak 24 órányi adat.
Ezután rendszeresen vagyok Adatok felhívása le az asztalra.
Én levágva egy Cron job és leteszem azt
ra ezek más asztalok, amire szükségetek van.
Tehát, ha egy borulás működik, ez nagyszerű.
Ha nem, akkor vágja.
De maradjunk a forró adatok távol a hideg adatokat.
Ez fog menteni egy csomó pénzt, és hogy az asztalok szempontból hatékonyabb.
Így a következő dolog, fogunk beszélni arról van szó, termék katalógus.
Termék katalógus elég gyakori használatra esetében.
Ez valójában egy nagyon gyakori motívum hogy majd meglátjuk a különböző dolgokat.
Tudja, Twitter Például, egy forró csipog.
Mindenki jön és megragadta, hogy csipog.
Árukatalógus, kaptam egy eladó.
Kaptam egy forró eladó.
Kaptam 70.000 kérelmek száma második eljövetele egy termék
leírás az én termékkatalógusban.
Ezt látjuk a kiskereskedelmi művelet egy kicsit.
Szóval hogyan foglalkozzunk vele?
Kizárt, hogy foglalkozzanak ezzel.
Minden az én felhasználókat szeretné látni ugyanazt az adatot.
Ők jönnek, egyidejűleg.
És mind kérelmek benyújtása az azonos adatot.
Ez ad nekem, hogy a forró kulcsot, hogy nagy piros csík én chart, hogy mi nem tetszik.
És ez az, ami úgy néz ki, mint.
Szóval az egész az én kulcsfontosságú helyet kapok kalapált az értékesítés tételeket.
Kezdek semmi sehol máshol.
>> Hogyan enyhíthetik ezt a problémát?
Nos, enyhítse ezt a gyorsítótárat.
Cache, akkor tegye alapvetően egy memóriában partíció előtt a adatbázisban.
Sikerült [Hallhatatlan] cache, hogyan
beállíthatja a saját cache, [hallhatatlan] cache [? d,?], amit akarsz.
Tedd, hogy fel előtte az adatbázist.
És így tudod tárolni az adatokat azoktól gyorsbillentyűk fel, hogy cache
térben és olvassa el a gyorsítótárat.
>> És akkor a legtöbb a elolvassa kezdeni, mint ez.
Kaptam mindezek cache eltalálja itt és engem semmi sem történt itt lent
mivel az adat- mögött ül a A gyorsítótár és a olvasás soha nem jön át.
Ha tudom megváltoztatni az adatokat a adatbázis, azt kell frissíteni a cache.
Tudjuk használni valamit mint gőzök erre.
És leírom, hogy hogyan működik.
Rendben, üzenetküldés.
E-mail, mindannyian használjuk az e-mail.
>> Ez egy nagyon jó példa.
Van valamiféle üzenetet asztalra.
És mi van Bejövõ és kimenõ.
Ez az, amit az SQL lenne néznek ki, mint építeni, hogy postaládájába.
Azt a fajta használja ugyanazt a fajta A stratégia az GSI, GSI
az én postaládájába, és én kimenő üzenetek.
Szóval kaptam nyers érkező üzenetek az én üzenetek asztalra.
És az első megközelítése ennek Lehet, azt mondják, OK, semmi gond.
Megvan a nyers üzeneteket.
Üzenetek jön [hallható], Üzenet azonosító, ez nagyszerű.
Ez az én egyedi hash.
Megyek, hogy két GSI, egy az én postaládájába, egy az én kimenő üzenetek.
És az első dolog, amit megteszek A mondok én hash kulcs
lesz a címzett és Megyek, hogy gondoskodjon a napon.
Ez fantasztikus.
Kaptam szép kilátás van.
De van egy kis kérdés.
És befut ezt relációs adatbázisok is.
Ők az úgynevezett függőleges particionálás.
Meg akarja tartani a nagy adatok távol a kevés adat.
>> És az az oka, mert azt kell menj olvassa el a tételeket, hogy az attribútumokat.
És ha én szervek mind itt, Ezután olvasás csak néhány elem
ha a testem hossza átlagosan 256 kilobyte minden,
A matek lesz elég csúnya.
Tehát mondani akarok olvasni David postaládájába.
Dávid postaládájába 50 példány.
Az átlagos és a mérete 256 kilobájt.
Itt a konverziós arány A távirányító a négy kilobájt.
>> OK, menjünk együtt végül következetes szól.
Én még mindig eszik 1600 távirányító által csak olvasni David postaládájába.
Jaj.
OK, most gondolkodjunk arról, hogy a app működik.
Ha én vagyok egy e-mailt app, és Nézem én postaládájába,
és nézem a test minden üzenetet, Nem, nézem az összefoglalókat.
Én néztem csak a fejlécek.
Így építsük fel a táblázat szerkezete úgy néz ki, mint ezt.
>> Tehát itt van az információ hogy a munkafolyamat szüksége.
Ez az én postaládájába GSI.
Ez a dátum, feladó, a téma, majd
Az üzenet azonosítója, amely rámutat, vissza az üzeneteket asztal
hol lehet kapni a szervezetben.
Nos, ezek lennének rekord azonosítók.
Ők pont vissza a elem adatait a Dynamo DB asztalra.
Minden index mindig creates-- Mindig az elemet
ID részeként of--, hogy jön az index.
>> Minden rendben.
Közönség: Azt mondja, hogy hol tárolja az?
Rick Houlihan: Igen, azt mondja exactly-- hogy pontosan mit csinál.
Azt mondja, itt az én újra rekordot.
És ez lesz a pont vissza az én újra rekordot.
Pontosan.
OK, így most én postaládájába is valójában sokkal kisebb.
És ez valóban támogatja A munkafolyamat egy e-mail alkalmazás.
Szóval én postaládájába, rákattintok.
Megyek végig, és rákattintok az üzenet, ez az, amikor el kell mennem, hogy a test,
mert megyek megy egy másik nézet.
Tehát, ha jól meggondoljuk MVC típusú keretet, MVC.
>> A modell tartalmazza a adatok, hogy a néző igényeinek
és a vezérlő kölcsönhatásba lép.
Ha tudom megváltoztatni a keret, ha Én a változás szempontjából,
nem baj, hogy menjen vissza a szerver és újra benépesíteni a modell,
mert ez az, amit a felhasználó számít.
Amikor változás nézetek, ez az, amikor mehetünk vissza az adatbázisba.
Így az e-mail, kattintson.
Keresem a szervezetben.
Körutazás.
Menj a szervezetben.
>> Sokat olvasok kevesebb adatot.
Én csak olvassa a szervek David szüksége, amikor szüksége van rájuk.
És én nem égnek 1600-ban Távirányító, csak hogy megmutassa a postaládájába.
Tehát most hogy-- ez az út hogy LSI vagy GSI-- Sajnálom,
GSI, hogy dolgozzanak ki.
Megvan a hash a kedvezményezettet.
Megvan a tartományban gombot napján.
És megvan a vetített attribútumok hogy csak fel kell alátámasztják azt a nézetet.
>> Mi forgatni, hogy a kimenő üzenetek.
Hash feladónak.
És lényegében már A nagyon szép, tiszta kilátás.
És ez basically-- vagyunk Van ez a szép üzeneteket
táblázatot, amit most elterjedt szépen, mert ez hash csak, hashelt üzenet azonosítója.
És van két indexek forognak ki a táblázat.
Rendben, tehát ötlet itt nem tartani a nagy adatok és ez a kis adatok
együtt.
Partíció függőlegesen, partíció azokat a táblákat.
Ne olvass adatokat nem kell.
Rendben, játék.
Mindannyian szeretnénk játékok.
Legalább Szeretem a játékokat majd.
Így néhány dolog hogy kezelni, ha
arra gondoltunk, hogy játék, igaz?
Játék ezekben a napokban, különösen a mobil játék, szól gondolkodás.
És fogok forgatni itt kicsit távol DynamoDB.
Megyek, hogy a néhány beszélgetés
körül néhány, a Más AWS technológiák.
>> De az ötlet a játék, hogy úgy gondolja, mintegy szempontjából API, API-k, amelyek,
általánosságban elmondható, hogy a HTTP és JSON.
Ez hogyan mobil játékok fajta kölcsönhatásba a hátsó végét.
Ők JSON kiküldetés.
Kapnak adatok, és ez mind, általánosságban elmondható, hogy a szép JSON API-k.
>> Dolgok, mint hogy barátok, hogy A ranglistán, adatokat cseréljen,
felhasználó által generált tartalom, tolja vissza a rendszerbe,
Ezek típusú dolgokat hogy fogunk csinálni.
Bináris eszköz adatok, az adatok Lehet, hogy nem ülnek az adatbázisban.
Ez lehet ülni egy objektum tárolja, ugye?
De az adatbázis fog a végén azt mondja a rendszer,
mondja a kérelem hová menjen érte.
És elkerülhetetlenül, multiplayer szerverek, hát vége infrastruktúra,
és célja a magas rendelkezésre állás és a skálázhatóság.
Tehát ezek azok a dolgok, hogy mindannyian szeretnénk a szerencsejáték-infrastruktúra ma.
>> Szóval vessünk egy pillantást mi az hogy néz ki.
Van egy alapvető hátsó, nagyon egyszerű.
Van egy rendszer itt Több rendelkezésre álló zónára.
Beszéltünk Azs mint being-- hiszem ezek külön adatközpontok.
Több, mint egy adatközpont per AZ, de ez rendben van,
gondoljunk csak azokat külön adatok központok, amelyek földrajzilag
és a hiba elszigetelt.
>> Fogunk egy Pár EC2 esetekben.
Fogunk van Néhány hátsó kiszolgáló.
Talán ha egy örökölt építészet vagyunk
segítségével hívjuk RDS, relációs adatbázis-szolgáltatások.
Lehet, MSSQL, MySQL, vagy valami ilyesmi.
Ez így egy csomó alkalmazások úgy tervezték, ma.
>> Hát talán akar menni Ez az, amikor bővíthetők.
Majd megy előre, és tedd Az S3 vödör ott.
És hogy az S3 bucket szolgálata helyett azokat a tárgyakat mi servers--
tudnánk csinálni.
Akkor tedd az összes bináris tárgyakat a szerverek
és tudod használni ezeket kiszolgáló esetekben szolgálja, hogy az adatok felfelé.
De ez elég drága.
>> Jobb így, hogy, menj előre, és tedd azokat a tárgyakat egy S3 vödör.
S3 egy adattáraknál.
Az épített kifejezetten szolgálja ki az ilyen típusú dolgokat.
És hagyd, hogy azok az ügyfelek kérhetik a közvetlenül ezen objektum vödrök,
tehermentesíti a szervereket.
Szóval kezdjük a skála idekint.
>> Most kaptuk a felhasználók a világ minden tájáról.
Megvan a felhasználók.
Azt kell, hogy tartalmi helyben közel helyezkedik el ezeket a felhasználókat, ugye?
Létrehoztam egy S3 vödör mint az én repository.
És én elöl, hogy a A CloudFront forgalmazás.
>> CloudFront egy CD-t és egy tartalomszolgáltató hálózat.
Alapvetően tart adatokat Ön által megadott és a tartalmát tárolja az egész internet
így a felhasználók bárhol lehet egy nagyon gyors választ, amikor
kérik azokat az objektumokat.
>> Így kap egy ötlet.
Te milyen kihasználva minden szempontjai AWS ide hogy ez megtörtént.
És végül, dobjuk egy automatikus méretezés csoport.
Szóval mi AC2 példányok játékunk szerverek,
mivel kezdenek elfoglaltabb és elfoglaltabb és elfoglaltabb,
ők csak forgasd a másik Például, forgasd másik esetben,
pörögni egy másik példánya.
Tehát a technológia AWS, hogy lehetővé teszi azoknak a paramétereknek
amely körül a szervereket fog nőni.
Szóval lehet, hogy van n szerverek száma ott bármely adott időpontban.
És ha a terhelés elmúlik, akkor majd zsugorodik, a szám csökkenni fog.
És ha a terhelés jön vissza, ez akkor nőnek vissza, rugalmasan.
>> Tehát ez jól néz ki.
Van egy csomó EC2 esetekben.
Mi lehet tenni cache előtt az adatbázisokat,
próbálja gyorsítani az adatbázisokat.
A következő nyomáspont általában az emberek látják
Ők azok skála egy játék segítségével relációs adatbázis-rendszer.
Jesszus, az adatbázis teljesítmény borzalmas.
Hogyan javítja ezt?
Próbáljuk üzembe cache előtt, hogy.
>> Nos, cache nem működik olyan nagy a játék, igaz?
A játékok, az írás fájdalmas.
A játékok nagyon nehéz írni.
Cache nem működik, ha éppen levelet nehéz, mert te mindig
Meg kell frissíteni a cache.
Frissíti a cache, ez lényegtelen, hogy cache-t.
Ez valójában csak plusz munkát.
>> Szóval, ha mi megy itt?
Van egy nagy szűk ott az adatbázisban.
És az a hely, hogy menjen Nyilvánvalóan a particionálás.
Particionálás nem könnyű csinálni, ha éppen
foglalkozó relációs adatbázisok.
A relációs adatbázisok, te irányításáért felelős, hatékony,
a legfontosabb helyet.
Azt mondod, hogy a felhasználók az A és M megy itt, az N és Z odamenni.
És te váltás az egész alkalmazást.
Szóval van dolgunk, ez a partíció adatforrás.
Van tranzakciós megszorítások amelyek nem befogják partíciókat.
Van mindenféle messiness, hogy te
foglalkozó ott próbál foglalkozni méretezés el
és az épület egy nagyobb infrastruktúra.
Ez csak nem szórakoztató.
>> Közönség: Szóval azt mondod, hogy növekvő forrása pont felgyorsítja
a folyamat?
Rick Houlihan: növekvő?
Közönség: Forrás pont.
Rick Houlihan: Forrás pont?
Közönség: A rendelkezésre álló információk, amennyiben az információ érkezik?
Rick Houlihan: Nem
Mit mondok növelése számú partíciót az adattárban
javítja a teljesítményt.
Szóval, mi történik itt felhasználók jön be a EC2 például itt,
Nos, ha szükségem van egy felhasználói Ez egy M, megyek itt.
N p, megyek itt.
P Z-ig, megyek itt.
>> Közönség: OK, ezeket így azok Az összes tárolt különböző csomópontok?
>> Rick Houlihan: Igen.
Gondolj ezeket különböző silók adatok.
Szóval ha ezt kellene csinálnia.
Ha akarsz csinálni ez, ha akarsz
méretarányos egy relációs platformon, ez az, amit csinálsz.
Te véve adatok és akkor csökkennek le.
És te particionálás ez az egész több példányát adatbázisban.
És te irányítasz mindent, A ás alkalmazások.
Ez nem vicces.
Szóval mit is akar menni?
Azt akarom, hogy DynamoDB, teljes körű irányítását, NoSQL adattároló rendelkezni forgalom.
Az általunk használt másodlagos indexek.
Ez alapvetően HTTP API és tartalmazza a dokumentum támogatása.
Szóval nem kell aggódni mintegy bármely hogy a particionálás.
Tesszük mindezt az Ön számára.
Tehát most, ahelyett, akkor csak írni, hogy az asztalra.
Ha a táblázatot kell megosztjuk, ez történik a színfalak mögött.
Te teljesen szigetelt re, hogy a fejlesztő.
Szóval beszéljünk néhány, a használati esetek
hogy befut a játék, közös szerencsejáték-forgatókönyvek, ranglistán.
Szóval megvan a felhasználók érkezik, A BoardNames, hogy ők
a, a pontszámok a felhasználó számára.
Mi lehet tördeljük a felhasználói azonosító, és akkor mi van tartományban a játékot.
Így minden felhasználó akar látni Minden játék ő játszott
és minden rekordot állított fel az összes játék.
Szóval ez az ő személyes ranglistán.
>> Most azt akarom, hogy menjen be, és azt akarom, hogy get-- ezért kapok e személyes ranglista.
Amit én akarok, akkor kap A legtöbb pontot az összes felhasználó számára.
Szóval hogyan tudom megtenni?
Amikor a rekord hashelt a a felhasználói azonosító, mozgott a játékot,
jól fogok menni előre és átszervezése, hozzon létre egy GSI,
és megyek átalakítására, hogy az adatokat.
>> Most megyek Hash a BoardName, amely a játék.
És fogok terjedhet a legtöbb pontot.
És most létrehozott különböző vödrök.
Én a ugyanannál az asztalnál, ugyanazt a tételt adatokat.
De hozok létre egy vödör, hogy ad nekem egy összesítése rekordot állított fel a játékot.
>> És azt tudja kérdezni, hogy asztalon hogy ezt az információt.
Így állítottam, hogy keresett mintát akár alá kell támasztani egy másodlagos index.
Most már lehet válogatni a BoardName és sorolva TopScore függően.
Így láthatja, ezek típusai A használati esetek kapsz a játék.
Egy másik jó hasznát esetben felvesszük a szerencsejáték- a díjak és aki megnyerte a díjat.
És ez egy nagy használati eset ahol hívjuk ritka indexek.
Ritka indexek a képes generálni
az index, hogy nem feltétlenül tartalmaznak minden egyes tételt az asztalra.
És miért nem?
Mivel a tulajdonság, amit most indexelt nem létezik minden elemet.
>> Tehát ebben a konkrét használni az esetben, azt mondom,
Tudod mit, megyek hozzon létre egy attribútum nevű díját.
És fogok adni minden felhasználónak hogy van egy díjat, amely tulajdonítani.
Azok a felhasználók, nem kell a díjak nem megy, hogy a tulajdonsággal.
Tehát, ha tudok létrehozni a index, az egyetlen felhasználók
hogy fognak mutatni akár az index
az is, hogy ténylegesen díjat nyert.
Szóval ez egy nagyszerű lehetőség, hogy képes hogy hozzon létre szűrt indexek
Nagyon, nagyon szelektív, amelyek nem van az index a teljes táblázatot.
>> Szóval kezd megtelni időben itt.
Megyek előre, és hagyja menni ki, és hagyja ki ezt a forgatókönyvet.
Beszéljünk egy kicsit about--
>> Közönség: Megkérdezhetem egy gyors kérdés?
Az egyik levelet nehéz?
Rick Houlihan: Mi?
Közönség: Írj nehéz.
Rick Houlihan: Írj nehéz.
Hadd lássam.
>> Közönség: Vagy az, hogy nem valami, amit csak
hangját a másodpercek kérdése?
Rick Houlihan: Megyünk a szavazási forgatókönyv.
Ez nem olyan rossz.
Srácok, van egy pár percig?
OKÉ.
>> Így fogunk beszélni szavazást.
Így valós időben szavazás, van való választásra.
Követelmény az, hogy megengedjük Minden személy csak egyszer szavazhat.
Szeretnénk senki, hogy képes hogy változtassák meg a szavazást.
Szeretnénk valós idejű összesítés és elemzése demográfiai
hogy mi lesz mutatja, hogy a felhasználók az oldalon.
>> Gondolj ez a forgatókönyv.
Mi sokat dolgoznak a valóság TV-műsorok, ahol ők
csinálnak ezek pontos típusa a dolgokat.
Így gondolja a forgatókönyv, van milliónyi
A tizenéves lányok ott a mobiltelefonok
és szavazó, valamint a szavazás, és szavazok bárkik legyenek is
találni, hogy a legnépszerűbb.
Tehát ezek közül néhány a követelmények elfogy.
>> És így az első vegye e probléma megoldásában
az lenne, hogy építsenek egy Nagyon egyszerű alkalmazás.
Így kaptam ezt a kb.
Van néhány szavazók odakint.
Jönnek, hogy megüt a szavazati app.
Van néhány nyers szavazat asztal Én csak kiírása ezen szavazatok be.
Szólok néhány összesített szavazatok tábla
minden tőlem analitika és a demográfia, és mi mindezt ott.
>> És ez jó.
Az élet jó.
Az élet jó, amíg nem találunk arra, hogy mindig van csak egy vagy két
az emberek, amelyek népszerűek a választások.
Már csak egy-két dolgot hogy az emberek tényleg érdekel.
És ha szavazó skála, hirtelen vagyok
lesz kalapált a fenébe két jelölt, egy vagy két jelölt.
Egy nagyon kevés példány ember számára, hogy népszerű.
>> Ez nem egy jó tervezési minta.
Ez valójában egy Nagyon rossz tervezési minta
mert létrehoz pontosan mi beszélt ami gyorsbillentyűk.
Gyorsbillentyűk valamit mi nem tetszik.
>> Szóval hogyan lehet megjavítani ezt?
És valóban, a módja annak, hogy erősít ez azáltal, hogy azokban a tagjelölt kanalak
és minden jelölt van, fogunk hozzáfűzni egy véletlen értéket,
valamit, hogy tudjuk, véletlenszerű közötti érték egy és 100,
100 és 1000, közötti, vagy egy és 1,000,
Azonban sok véletlenszerű értékeket szeretne fűzze rá a végén, hogy a jelölt.
>> És mit értem igazán történt akkor?
Ha én vagyok a jelölt azonosítót A vödröt összesített szavazatok,
Ha Adtam egy véletlenszerű szám, hogy a végén, hogy
Már létrehozott most 10 kanalak, egy Száz vödrök, ezer vödrök
hogy én vagyok a szavazatok összegyűjtésére szerte.
>> Szóval van több millió, és milliók, és több millió lemez jön
ezeket a jelölteket, most terjed ezen szavazatok szerte vont a_1
a tagjelölt A_100, mert Minden alkalommal, amikor egy szavazást érkezik,
Én generál egy véletlen közötti érték egy és 100.
Én tacking rá a végén a jelöltet az adott személy szavazok.
Én dömping be, hogy vödörbe.
>> Most a hátoldalon, tudom hogy kaptam száz vödör.
Tehát, ha azt akarom, hogy menjen előre és összesítik a szavazatok,
Olvastam az összes többi vödrök.
Szóval megy előre, és adjunk hozzá.
És akkor én a szórás gyűjteni hová megyek, és azt mondják hé,
tudod mit, ez a jelölt gombot terek több mint száz vödör.
Megyek összegyűjteni a szavazat azoktól száz vödör.
Megyek összesíteni őket, és meg fogom mondani,
Tagjelölt Egy most Összesen szavazatszámlálás x.
>> Most mind a write lekérdezés és az olvasási lekérdezés
szépen elosztva mert én írom át
és olvasom több száz kulcsokat.
Én nem írom és olvasás-szerte az egyik legfontosabb most.
Szóval ez egy jó minta.
>> Ez tulajdonképpen talán az egyik A legfontosabb tervezési
minták skála NoSQL.
Látni fogja az ilyen típusú tervezési minta minden ízét.
MongoDB, DynamoDB, ez nem számít, mi minden kell ezt csinálni.
Mert ha éppen foglalkoznak azokkal a hatalmas csoportosulásai,
meg kell találnunk a módját, hogy osszuk ki az egész vödör.
Tehát ez az az út, ezt teszed.
Rendben, akkor mi csinálsz most
A te kereskedés off Olvasás költség írási skálázhatóság.
Az ára én beolvasás egy kicsit bonyolultabb,
és mennem kell olvasni egy Száz vödrök helyett.
De nem vagyok képes írni.
És én áteresztőképességű, én write áteresztőképességű hihetetlen.
Szóval ez általában egy értékes technika méretezés DynamoDB,
vagy bármilyen NoSQL adatbázist, hogy az ügyben.
Szóval kitaláltam, hogyan lehet skálázni.
És rájöttünk, hogyan kell megszüntesse a gyorsbillentyűk.
És ez fantasztikus.
És mi van ez a szép rendszer.
És ez adott nekünk nagyon helyes szavazati mert van eredménye szavazás de-dupe.
Építettük DynamoDB.
Beszéltünk a feltételes jogokat.
>> Ha a választópolgár jön, hozza betét az asztalra,
úgy helyezze azok a szavazók ID, ha megpróbál beilleszteni egy szavazást,
Én egy feltételes írni.
Mondja el, csak írni ezt Ha ez nem létezik.
Tehát amint látom, hogy a szavazást a verik az asztalt,
senki más lesz tudja tenni a szavazást.
És ez fantasztikus.
És mi megnő a tagjelölt számlálók.
És csinálunk mi demográfiai és ennyi.
De mi történik, ha a alkalmazás elesik?
Most hirtelen szavazat jönnek, és én
nem tudom, ha ők egyre feldolgozása az én elemző és demográfia
többé.
És ha az alkalmazás jön vissza, hogyan
A fenébe tudom, hogy milyen szavazattal rendelkezik feldolgozott és hol is kezdjem?
>> Tehát ez egy valós probléma, ha elkezdi nézni az ilyen típusú forgatókönyv.
És hogyan oldja meg ezt?
Megoldjuk azt, amit mi hívja DynamoDB Streams.
Patakok egy időben rendezett és megosztjuk változás napló minden hozzáférést
A táblázat minden levelet hozzáférést a táblázatban.
Minden olyan adatot, hogy van írva, hogy a táblázat mutatja fel a patak.
>> Ez alapvetően egy 24 órás sorban.
Tételek sújtotta a patak, élnek 24 órán át.
Ők lehet olvasni többször.
Garantált kell szállítani csak egyszer a patakhoz,
lehet olvasni N számú alkalommal.
Így azonban sok kívánt folyamatokat fogyasztanak, hogy az adatok, akkor is fogyaszthatunk.
Úgy jelenik meg minden frissítés.
Minden írási csak akkor jelennek meg egyszer a patak.
Szóval nem kell aggódni mintegy feldolgozás kétszer
ugyanabból a folyamatot.
>> Ez szigorúan elrendelte db áron.
Amikor azt mondjuk, ideje megrendelt és megosztjuk,
látni fogod per partíciót a patak.
Látni fogja tételek, frissítések érdekében.
Mi nem garantálja a patak, hogy te
lesz, hogy minden tranzakció A sorrendben az egész terméket.
>> Tehát patakok idempotens.
Ne mindannyian tudjuk, mi idempotens jelent?
Idempotens azt jelenti, hogy meg tudod csinálni újra és újra, és újra.
Az eredmény lesz ugyanaz.
>> Patakok idempotens, de meg kell lennie
játszott a kiindulási pont, bárhol is, hogy a végén,
vagy amelyek nem eredményeznek az azonos értékeket.
>> Ugyanezt MongoDB.
MongoDB egy konstrukciót hívják az oplog.
Ez pontosan ugyanaz a konstrukció.
Sok NoSQL adatbázisok Van ez a konstrukció.
Ők használják a dolgokat mint a replikáció, amely
Pontosan mit teszünk patakok.
Közönség: Talán egy eretnek kérdést, de
beszélni alkalmazások csinálsz egy így tovább.
Vannak patakok garantáltan Soha esetleg megy le?
Rick Houlihan: Igen, patakok garantáltan soha nem megy le.
Sikerül az infrastruktúra mögött. patakok automatikusan
telepíteni az automatikus méretezés csoport.
Elmegyünk egy kicsit kicsit arról, hogy mi történik.
>> Nem kellett mondanom, hogy nem Garantált, hogy menjen le.
Az elemek garantáltan megjelenni a patak.
És a közvetítés lesz elérhető.
Tehát mi megy le, vagy jön vissza fel, ami történik alatta.
Ez covers-- minden rendben.
Rendben, így kap a különböző ábrázolási mód ki a képernyőn.
A kilátás típusok, amelyek fontosak a programozó jellemzően, mi volt ez?
Azt, hogy a régi nézetet.
Amikor frissítést üt az asztalra, akkor az tolja a régi nézetet, hogy a patak
így az adatok archiválására, illetve a változás kontroll, a változás azonosítása, a változás
menedzsment.
>> Az új kép, mint amilyen most, miután A frissítés, ez egy újabb fajta nézet
lehet kapni.
Lehet kapni a régi és az új képeket.
Talán azt akarom mind a kettőt.
Azt akarom, hogy lássák, mi az.
Azt akarom, hogy megnézze, mi változott.
>> Nekem van egy megfelelési típus A folyamat fut.
Azt kell, hogy ellenőrizze, hogy ha ezek a dolgok megváltoznak,
hogy ők bizonyos határokon belül vagy bizonyos paramétereken belül.
>> És akkor talán csak kell, hogy mi változott.
Nem érdekel, hogy melyik elem változott.
Nem kell tudnod kell milyen képességei változtak.
Én csak meg kell tudni, hogy A tételek kerülnek megérintette.
Tehát ezek a különböző nézetek hogy szálljon le a patak
és kölcsönhatásba léphet.
>> Az alkalmazás fogyasztja az áramot,
Ez a fajta az, ahogy ez működik.
DynamoDB ügyfél kérheti, nyomja adatok az asztalokhoz.
Patakok telepíteni, hogy mit nevezünk szilánkok.
Szilánkok méretezése függetlenül az asztalra.
Ők nem sorakoznak teljesen A válaszfalak a táblázat.
És az az oka, mert sorakoznak
a kapacitás, a jelenlegi kapacitása a táblázatban.
>> Ők telepíteni a saját saját auto méretezés csoport,
és elkezdenek elhúz függően hány írások jönnek,
Hány reads-- igazán ez írja.
Nincs reads-- de hogyan Sok írások jönnek.
>> És akkor a hátsó végén, van, amit mi
hívja a kálium-klorid, vagy Kinesis Client Library.
Kinesis egy adatfolyamok feldolgozási technológia Amazon.
És patakok épül, hogy.
>> Szóval használja a KCL engedélyezve alkalmazás olvasni a patak.
A Kinesis Client Library ténylegesen kezeli a munkavállalók az Ön számára.
És ez is, nem valami érdekes dolgok.
Ez létre fog hozni néhány táblázatban fel a DynamoDB tablespace
követni, hogy mely elemek feldolgozásra kerültek.
Szóval így ha esik vissza, ha esik át, és jön, és lesz
állt vissza, meg tudja határozni, ahol volt feldolgozásában a patak.
>> Ez nagyon fontos, ha te beszélsz replikáció.
Tudnom kell, hogy mi adatok feldolgozása megtörtént
és milyen adatokat még ki kell dolgozni.
Tehát a KCL könyvtár patakok kapsz egy csomó ezt a funkciót.
Ez gondoskodik az összes háztartás.
Állítsa fel a munkavállalót minden darabnak.
Ez létrehoz egy adminisztratív asztal Minden darabnak, a minden munkavállalót.
És mivel ezek a munkavállalók tűz, fenntartják azokat a táblákat
így tudja ezt a rekordot felolvasták és feldolgozni.
És akkor így, ha a folyamat meghal, és újra online,
akkor folytathatja ott, ahol levette.
>> Így használjuk ezt határokon régió replikáció.
Sok ügyfél van szükség mentsük el az adatokat, vagy egyes részein adattáblák
körül, hogy különböző régiókban.
Kilenc régió a világon mindenhol.
Tehát ott lehet a need-- I Lehet, hogy a felhasználók Ázsiában, a felhasználók
A keleti parton az Egyesült Államokban.
Ők különböző adatok kell helyben osztják.
És talán egy felhasználó indít járatot Ázsia át az Egyesült Államokban,
és szeretném megismételni adatainak vele.
Tehát amikor leszáll a gép, ő Jó tapasztalat segítségével a mobil app.
>> Használhatja a határon régióban replikáció könyvtár erre.
Alapvetően van amennyiben két technológia.
Az egyik egy konzolos alkalmazás segítségével felállni a saját EC2 fokon.
Ez fut a tiszta replikáció.
És akkor mi adta meg a könyvtárban.
A könyvtár használhatja építeni Saját alkalmazásában, ha
akarok őrült dolgokat, hogy data-- szűrő, lemásolni csak részét,
forgatni az adatokat, hogy helyezze át a különböző asztal, így tovább és így tovább.
Szóval ez a fajta, amit úgy néz ki, mint a.
>> DynamoDB Streams lehet dolgozza fel, amit úgy hívunk Lambda.
Említettük egy kicsit esemény vezérelt alkalmazás architektúrák.
Lambda kulcsfontosságú eleme, hogy.
A lambda-kód, amely a tüzek igény válaszul egy adott eseményt.
Az egyik ilyen események lehet egy rekord jelenik meg a patak.
Ha egy rekord jelenik meg a patak, fogjuk hívni ezt a Java funkciót.
Nos, ez a JavaScriptet, és a Lambda támogatja node.js, Java, Python,
és hamarosan támogatni más nyelveken is.
És elég mondani, ez tiszta kódot.
levelet a Java, akkor meg egy osztályt.
Lenyomja a JAR fel Lambda.
És akkor adja meg, hogy melyik osztályba hívni amelyekre válaszul esemény.
És akkor a Lambda infrastruktúra mögött, hogy futni fog a kódot.
>> Ez a kód képes feldolgozni nyilvántartások le a patak.
Meg lehet csinálni amit akar vele.
Ebben a konkrét példában az összes vagyunk igazán tesz bejelentkezik az attribútumokat.
De ez csak kódot.
Kód tehetünk semmit, ugye?
>> Szóval lehet forgatni, hogy az adatok.
Tudod teremt egy származékos kilátás.
Ha ez egy dokumentum szerkezetét, akkor simítsa a szerkezet.
Tudod teremt alternatív indexek.
Mindenféle dolgot lehet köze a DynamoDB Streams.
>> És valóban, ez az, amit úgy néz ki, mint.
Így kap, ezeket a frissítéseket jön.
Jönnek ki a húr.
Ők olvasható a Lambda funkció.
Ők forgó adatok és nyomja fel a származékos asztalok,
bejelentő külső rendszerek változás, és nyomja adatok ElastiCache.
>> Beszéltünk arról, hogyan tegye a cache előtte az adatbázist, hogy az értékesítés
forgatókönyv.
Nos, mi történik, ha frissíti a tétel leírását?
Nos, ha volt egy Lambda funkció fut az asztalon,
ha frissítem a tétel leírását, akkor az vegye fel a rekordot le a patak,
és akkor frissíti a ElastiCache Például az új adatokkal.
Szóval ez a sok mit tegyünk Lambda.
Ez a ragasztó kódot, csatlakozók.
És ez valóban ad a képesség, hogy indítson
és futni nagyon összetett alkalmazások anélkül egy dedikált szerver
infrastruktúrát, ami nagyon klassz.
>> Szóval menjünk vissza a valós idejű szavazási építészet.
Ez az új és továbbfejlesztett változata a patakok és KCL kompatibilis alkalmazás.
Ugyanaz, mint korábban, nem tudjuk kezelni bármilyen skálán választásokon.
Szeretjük ezt.
Csinálunk szórás gyűjt több vödör.
Megvan optimista zárolás folyik.
Tudjuk tartani a választók megváltoztassák a szavazatokat.
Ők csak csak egyszer szavazhat.
Ez fantasztikus.
Valós idejű hibatűrés, skálázható összesítés most.
Ha a dolog eldől, hogy tudja, hogy hol újraindítja magát
amikor jön vissza, mert mi használ a KCL app.
És akkor mi is használjuk, hogy KCL kérelmet, hogy álljon ki az adatok
a vöröseltolódás más app analitika, vagy használatra
A rugalmas MapReduce futtatásához valós idejű streaming összeállítások le
Az, hogy az adatok.
>> Tehát ezek a dolgok is nem beszéltünk sokat.
De ők további technológiák jönnek
viseli, ha keres A ilyen típusú forgatókönyvek.
>> Rendben, ez körülbelül Analytics DynamoDB Streams.
Tudod gyűjteni de-dupe adatok, nem mindenféle
A szép dolgokat, az adatok összesítése memória, hozzon létre származékos táblákat.
Ez egy hatalmas felhasználása esetén hogy egy csomó ügyfelek
részt vesznek a, figyelembe véve a beágyazott ezek jellemzőit JSON dokumentumok
biztosítása és kiegészítő indexek.
>> Mi vagyunk a végén.
Köszönjük viselő velem.
Szóval beszéljünk referencia architektúra.
DynamoDB ül a közepén, így sok a AWS infrastruktúra.
Alapvetően akkor akassza akár bármit, amit akarsz.
Alkalmazások felhasználásával épült Dynamo közé Lambda, ElastiCache, CloudSearch,
tolja az adatokat ki Elastic MapReduce, import-export re DynamoDB
S3, mindenféle munkafolyamatokat.
De talán a legjobb dolog beszélni,
és ez az, ami igazán érdekes, amikor
beszélni eseményvezérelt alkalmazások.
>> Ez egy példa az egy belső projekt
hogy van, ahol mi vagyunk valójában kiadói összegyűjteni felmérés eredményeit.
Tehát egy e-mailt link, küldünk ki, hogy lesz-
egy kicsit linket mondván kattintással Itt válaszolni a felmérés.
És ha valaki kattintással lapra, mi történik
Ők azok, húzza le a biztonságos HTML felmérés formájában S3.
Nincs szerver.
Ez csak egy S3 objektumot.
>> Ez a forma jön létre, betölti fel a böngészőben.
Van rajta Gerinchálózat.
Van rajta komplex JavaScript hogy ez fut.
Így nagyon gazdag alkalmazás fut a kliens böngésző.
Nem tudják, hogy ők nem kölcsönhatásban áll a hátsó kiszolgáló.
Ezen a ponton, az egész böngészőt.
>> Ők hozzák nyilvánosságra az eredményeket, hogy milyen hívjuk az Amazon API Gateway.
API Gateway egyszerűen egy webes API amit meg lehet adni, és ismerkedj meg
hogy amit akarsz.
Ebben a konkrét esetben mi vagyunk akasztott fel a Lambda funkciót.
>> Szóval a POST művelet történik szerver nélkül.
Alapvetően, hogy az API Gateway ül ott.
Kerül nekem semmit, amíg az emberek íráshoz hozzá, ugye?
A Lambda funkció csak ül ott.
És kerül nekem semmit, amíg az emberek kezdenek üti meg.
Tehát láthatjuk, ahogy a hangerőt nő, ez az, amikor a díjak jönnek.
Nem futok szerveren 7/24.
>> Szóval húzza formájában le ki a vödröt,
és azt tegye az API- Kapuja a Lambda funkció.
És akkor a Lambda funkciót mondja, tudja
mit, van pár PIIs, néhány személyazonosításra alkalmas adatokat
Ezekben válaszok.
Kaptam hozzászólás érkező felhasználók.
Van e-mail címeket.
Megvan a felhasználóneveket.
>> Hadd osztott ezt le.
Megyek generálni metaadat ki ezt a rekordot.
És megyek, hogy álljon a metaadatok DynamoDB.
És tudtam titkosítja az összes adatot és tolja DynamoDB, ha akarom.
De ez könnyebb számomra, ebben a használni az esetben, hogy menjen előre az mondjuk,
Megyek, hogy álljon a nyers adatok egy titkosított S3 vödör.
Ezért használom épült S3 szerver oldalon titkosítás és az Amazon Key Management
Szerviz, hogy van egy kulcs, lehet forgatni a rendszeres időközönként,
és tudom védeni, hogy PII adatok Ennek részeként az egész munkafolyamatot.
>> Szóval mit tettem?
Épp most telepített egy egész alkalmazást, és nekem nincs szerver.
Tehát az, amit eseményvezérelt alkalmazás építészet nem az Ön számára.
>> Most, ha jól meggondoljuk A felhasználási módja this--
mi más ügyfelek beszélek hogy erről az architektúrát, akik
fuss hihetetlenül nagy kampányok, akik nézi ezt, és megy, ó.
Mert most, tudnak Alapvetően tolja odakinn,
hagyja, hogy a kampány csak ül ott, amíg elindul, és nem
nem kell aggódnia a füge mintegy milyen infrastrukturális
lesz ott, hogy támogassa azt.
Aztán, amint a kampány véget ért,
ez olyan, mint az infrastruktúra Csak azonnal elmúlik
mert tényleg nincs infrastruktúra.
Ez csak kódját, hogy ül a Lambda.
Ez csak az adatok, hogy ül DynamoDB.
Ez egy csodálatos módja alkalmazásokat építhetnek.
>> Közönség: Szóval ez több efemer, mint lenne
ha azt tárolt tényleges szerver?
>> Rick Houlihan: Abszolút.
Mert, hogy kiszolgálópéldányt kellene lennie egy 7/24.
Meg kell rendelkezésre állnia valaki válaszolni.
Hát tudod mit?
S3 elérhető 7/24.
S3 mindig reagál.
És S3 nagyon, nagyon jó szolgálata fel tárgyakat.
Azok a tárgyak lehetnek HTML fájlokat, vagy JavaScript fájlokat, vagy amit akarsz.
Akkor fuss nagyon gazdag internetes alkalmazások az S3 vödrök, és az emberek.
>> És ez az a gondolat itt van, hogy távol az út
szoktuk gondolni.
Mindannyian használt gondolkodni szempontjából szerverek és a házigazdák.
Ez nem arról szól, hogy többé.
Arról van szó, infrastruktúra kódot.
Telepítse a kódot a felhő, és hagyja, hogy a felhő el fogja indítani.
És ez az, amit AWS akar csinálni.
>> Közönség: Szóval az arany doboz közepén Az API Gateway nem szerver-szerű,
hanem az, csak--
>> Rick Houlihan: Ön szerint rá, mint szerver homlokzat.
Minden ez is el fog tartani egy HTTP kérni, és leképezni a másik folyamat.
Ez minden, hogy nem.
És ebben az esetben, mi feltérképezése azt egy Lambda funkció.
Rendben, ez minden, amit kaptam.
Nagyon szépen köszönöm.
Nagyra értékelem.
Tudom, hogy szeretnénk egy kicsit az idő múlásával.
És remélhetőleg srácok Egy kis információ
hogy lehet elvenni ma.
És elnézést kérek, ha elmentem át néhány fejeteket,
de van egy jó csomó alapvető megalapozó ismeretek
azt gondolom, hogy nagyon értékes az Ön számára.
Szóval köszönöm, hogy rám.
[TAPS]
Közönség: [hallható] az, amikor azt mondták,
meg kellett, hogy menjen át a dolog elejétől végéig
hogy a megfelelő értékek vagy ugyanazokat az értékeket,
milyen lenne az értékeket változik meg, ha [hallhatatlan].
>> Rick Houlihan: Ó, idempotens?
Hogyan értékeit változtatni?
Nos, azért, mert ha nem futottam ez egészen a végéig,
akkor nem tudom, mi változik került sor az utolsó mérföld.
Ez nem lesz a adatokkal, amit láttam.
Közönség: Ó, így csak Még nem ütött a teljes bemenet.
Rick Houlihan: Így van.
El kell menni az elejétől végét, és akkor ez
lesz konzisztens állapotban.
Hűvös.
>> Közönség: Szóval megmutatta DynamoDB tehetünk a dokumentum vagy a kulcs értékét.
És mi töltött sok időt a kulcs értéke egy hash, és milyen módon
flip azt körül.
Amikor megnézte azokat a táblákat, hogy maga mögött hagyva a dokumentumot megközelítés?
>> Rick Houlihan: Én nem tenném mondjuk hagyva maga mögött.
>> Közönség: Ők elváltak the--
>> Rick Houlihan: a dokumentumot megközelítést, a dokumentumtípus DynamoDB
csak gondoljunk, mint egy másik attribútum.
Ez egy olyan tulajdonság, amely tartalmazza hierarchikus adatszerkezet.
És akkor a lekérdezések, akkor a tulajdonságok
ezen objektumok Object jelölés.
Szóval lehet szűrni a beágyazott ingatlan a JSON dokumentum.
Közönség: Tehát minden alkalommal, amikor nem egy dokumentumot megközelítést,
Én is egyfajta megérkezik a tabular--
Közönség: Abszolút.
Közönség: --indexes és dolog, amit csak beszélgettünk.
Rick Houlihan: Igen, a indexek, meg minden,
ha azt szeretné, hogy az index tulajdonságait a JSON,
az is, hogy mi volna a teendő, hogy az, ha beszúr egy JSON vagy dokumentumot
a Dynamo, akkor használja patakok.
Patakok volna olvasni a bemenet.
Azt kap, hogy JSON objektumot, és azt mondanám, OK,
mi az ingatlan akarok index?
>> Létrehoz egy származékos asztalra.
Most, hogy ez így működik most.
Mi nem teszi lehetővé, hogy index közvetlenül azokat a tulajdonságokat.
>> Közönség: Tabularizing a dokumentumokat.
>> Rick Houlihan: Pontosan, simító ez, tabularizing meg, pontosan.
Ez az, amit teszel vele.
>> Közönség: Köszönöm.
>> Rick Houlihan: Igen, abszolút, köszönöm.
Közönség: Szóval ez a fajta Mongo találkozik Redis osztályozók.
>> Rick Houlihan: Igen, ez egy csomó ilyen.
Ez egy jó leírást érte.
Hűvös.