>> [MUSIC JOC]
RICK Houlihan: Bine.
Buna tuturor.
Numele meu este Rick Houlihan.
Sunt un senior principal soluții arhitect la AWS.
Ma concentrez pe NoSQL și Tehnologii DynamoDB.
Sunt astăzi aici pentru a vorbi cu ai un pic despre ele.
>> Background-ul meu este în primul rând în strat de date.
Mi-am petrecut jumătate dezvoltarea mea cariera scris de baze de date,
de acces la date, soluții pentru diverse aplicații.
Am fost în virtualizare Cloud timp de aproximativ 20 ani.
Deci, înainte de Cloud a fost nor, am folosit pentru a apela utilitate de calcul.
Și ideea a fost, e ca si cum PG & E, veți plăti pentru ceea ce folosiți.
Astăzi numim nor.
>> Dar de-a lungul anilor, am lucrat pentru un cuplu de companii
nu ati auzit niciodata, probabil, de.
Dar am compilat o listă de tehnică realizări, cred că aș spune.
Am opt patente în sistemele de Cloud virtualizare, design microprocesor,
prelucrare eveniment complex, și în alte domenii, de asemenea.
>> Deci în aceste zile, mă concentrez mai mult pe NoSQL tehnologii și generația următoare
Bază de date.
Și asta e ceea ce, în general, am de gând să fie aici să vorbesc cu tine astăzi despre.
Deci, ce vă puteți aștepta din această sesiune,
vom trece printr-o scurtă Istoria de prelucrare a datelor.
Este întotdeauna util să înțelege de unde am venit
și de ce suntem unde suntem.
Și vom vorbi un pic bit despre tehnologie NoSQL
din punct de vedere fundamental.
>> Vom intra în unele dintre cele interne ale DynamoDB.
DynamoDB este AWS nr gust.
Este un complet gestionate și găzduit soluție NoSQL.
Și vom vorbi un pic despre masă structura, API-uri, tipuri de date, indici,
și unele dintre componentele interne a acestei tehnologii DynamoDB.
Vom lua în unele dintre design modele și cele mai bune practici.
Vom vorbi despre modul în care utiliza această tehnologie pentru a putea
de aplicații de astăzi.
Și apoi vom vorbi un pic despre evoluția sau apariția
de o nouă paradigmă de programare numite aplicații determinate de un eveniment
și cum DynamoDB joacă în la fel de bine.
Și vă vom lăsa un pic de o discuție arhitectura de referință
astfel încât să putem vorbi despre o parte din modalități în care puteți utiliza DynamoDB.
>> Deci, în primul rând off-- aceasta este o întrebare Am auzit o mulțime este, ceea ce este o bază de date.
O mulțime de oameni cred că știu ce o bază de date este.
Dacă vă Google, veți vedea asta.
Este un un set structurat de date a avut loc într-un calculator, mai ales unul care
este accesibil în diverse moduri.
Cred că e un bun Definiția unei baze de date moderne.
Dar eu nu-mi place, pentru că implică o serie de lucruri.
Aceasta implică structura.
Și se presupune că este pe un computer.
Si baze de date nu a exista întotdeauna pe computere.
Baze de date a existat de fapt, în mai multe moduri.
>> Deci, o mai bună definire a unui bază de date este ceva de genul asta.
O bază de date este o organizat mecanism pentru stocarea, gestionarea,
și regăsirea informațiilor.
Acest lucru este de la About.com.
Așa că am dori acest lucru, deoarece într-adevăr discuții despre o bază de date a fi un depozit,
un depozit de informații, nu neapărat
ceva care sta pe un calculator.
Și de-a lungul istoriei, am nu au avut întotdeauna calculatoare.
>> Acum, dacă te întreb media dezvoltator astăzi ceea ce este
o bază de date, care este răspunsul primesc.
Undeva pot lipi lucruri.
Dreapta?
Și e adevărat.
Dar e regretabil.
Deoarece baza de date este într-adevăr temelia a aplicației moderne.
Este fundația de fiecare aplicație.
Și cum vă construi că baze de date, cum structura
că datele se va dicta cum sa aplicație funcționează în timp ce scara.
>> Deci, o mulțime de munca mea de azi se ocupă cu ceea ce
se întâmplă atunci când dezvoltatorii să ia această abordare
și care se ocupă cu urma de o aplicație care
este acum scalarea dincolo de original intenție și suferința de la proiectare rău.
Deci sperăm că, atunci când de mers pe jos de astăzi, veți
au o serie de instrumente în centura care va vă păstrați
de la a face aceleași greșeli aceste.
In regula.
Deci, hai sa vorbim despre un pic de calendarul de tehnologie de baze de date.
Cred că am citit-o Articolul nu mult timp în urmă
și a spus ceva pe lines-- este o declarație foarte poetic.
Acesta a spus istoricul de prelucrare a datelor este
plin de filigrane mari de abundenta de date.
BINE.
Acum, cred că e un fel de adevărat.
Dar mă uit de fapt este la fel de la istoria este, de fapt umplut
cu filigran mare de presiune date.
Deoarece rata de date a ingestie nu se duce în jos.
Merge doar până.
>> Și inovarea apare atunci când vom vedea de presiune date, care
este cantitatea de date care este acum în vine în sistem.
Și nu poate fi procesată eficient, fie în timp, fie în costul.
Și atunci vom începe să se uite la o presiune de date.
>> Deci, atunci când ne uităm la în primul rând baza de date, aceasta
este cel care a fost între urechile noastre.
Toate ne-am născut cu ea.
E o bază de date de frumos.
Ea are o disponibilitate ridicată.
E mereu pe.
Puteți să-l obține întotdeauna.
>> Dar e un singur utilizator.
Eu nu pot partaja gândurile mele cu tine.
Nu se poate obține gândurile mele atunci când le doriți.
Și abilitiy lor nu este atât de bun.
Am uitat lucrurile.
Fiecare acum și apoi, unul dintre noi frunze și se mută la un alt existență
și ne-am pierde tot care a fost în această bază de date.
Deci asta nu e tot atât de bun.
>> Și aceasta a lucrat mai bine de timp când eram pe vremuri
când tot ce ne într-adevăr nevoie să știu este unde mergem pentru a merge pe mâine
sau în cazul în care ne-am adunat cele mai bune alimente.
Dar, așa cum am început să crească ca o civilizație și de guvern a început
să vină în ființă, și întreprinderile au început să evolueze,
am început să ne dăm seama nevoie de un pic mai mult decât ceea ce
am putea pune în capul nostru.
In regula?
>> Aveam nevoie de sisteme de înregistrare.
Aveam nevoie de locuri pentru a fi capabili a stoca date.
Așa că am început documente scris, crearea de biblioteci și arhive.
Am început dezvoltarea unui sistem de contabilitate a registru.
Și că sistemul de numărare Ledger a fugit în lume pentru multe secole,
și poate chiar milenii ca am un fel de crescut până la punctul
în cazul în care că sarcina datele depasit capacitatea acestor sisteme
să fie capabil să-l conțină.
>> Și acest lucru sa întâmplat de fapt în anii 1880.
Dreapta?
În 1880 Statele Unite recensământul.
Aceasta este de fapt în cazul în care întoarcerea punctul de prelucrare a datelor moderne.
Acesta este punctul în care cantitatea de date
care a fost colectate de către Guvernul Statelor Unite a ajuns la punctul
în cazul în care a fost nevoie de opt ani pentru a procesa.
>> Acum, opt ani-- fi știți, recensământul
ruleaza la fiecare 10 ani-- asa ca e destul de evident că, prin timp am
Trebuie recensământul din 1890, cantitatea de date pe care
a fost de gând să fie prelucrate de guvern a fost
O să depășească 10 ani că ar lua pentru a lansat noul recensământ.
Aceasta a fost o problemă.
>> Deci, un tip pe nume Herman Hollerith venit
și a inventat înregistra pumn unitate cărți, cititor de carduri pumn, pumn carte
tabulator, și colaționarea de mecanismele pentru această tehnologie.
Și această societate că format la timp, împreună cu o pereche de alții,
de fapt, a devenit unul dintre pilonii unei companie mică știm astăzi numit IBM.
>> Deci, IBM a fost inițial în de afaceri de baze de date.
Și asta e într-adevăr ceea ce au făcut.
Ei au făcut de prelucrare a datelor.
>> Ca astfel proliferarea pumn cărți, o mecanisme ingenioase
de a fi în măsură să impulsioneze că Tehnologia la vot seturi de rezultate sortate.
Puteți vedea în această imagine acolo avem o little--
e un pic small-- dar puteți vedea un mecanism mecanic foarte ingenios
în cazul în care avem o punte carte pumn.
Și asumarea cuiva un pic de șurubelniță
și lipirea prin sloturi și ridicându-l
pentru a obține acel meci, că Rezultate sortate set.
>> Aceasta este o agregare.
Facem acest lucru tot timpul astăzi în calculator,
în cazul în care o faci în baza de date.
Am folosit pentru a face acest lucru manual, nu?
Oamenii pun aceste lucruri împreună.
Și a fost proliferarea din aceste cartele perforate
în ceea ce am numit tobe de date și role de date, bandă de hârtie.
>> Industria de prelucrare a datelor a avut o lecție de la piane jucător.
Jucător Piane înapoi la rândul său, a secolului
folosit pentru a utiliza role de hârtie cu fante pe ea spune care tastele pentru a juca.
Astfel încât tehnologia a fost adaptat în cele din urmă pentru a stoca date digitale,
deoarece acestea ar putea pune faptul că datele pe aceste role bandă de hârtie.
>> Acum, ca urmare, datele a fost actually-- cum
accesați aceste date a fost direct depinde de modul în care l-ați stocat.
Deci, dacă am pus datele de pe o bandă, Am avut acces la datele liniar.
A trebuit să se rostogolească întreg bandă pentru a accesa toate datele.
Dacă am pus datele din pumn cărți, am putea accesa
într-un pic mai mult la întâmplare moda, poate nu la fel de repede.
>> Dar au existat limitări în modul în care accesul la date pe baza modului fost depozitat.
Și așa mai departe acest lucru a fost o problemă a intra în anii '50.
Din nou, putem începe să vedem că așa cum am dezvoltarea de noi tehnologii pentru a procesa
datele, dreapta, se deschide usa pentru noi soluții,
pentru noi programe, noi aplicatii pentru că datele.
Și într-adevăr, de guvernare poate să fi fost motivul
de ce am dezvoltat unele dintre aceste sisteme.
Dar de afaceri a devenit rapid șoferul din spatele evolutia
a bazei de date moderne și sistemul de fișiere modern.
>> Deci urmatorul lucru pe care a venit a fost în anii '50
a fost sistemul de fișiere și dezvoltarea de stocare cu acces aleator.
Acest lucru a fost frumos.
Acum, toate de brusc, putem pune noastre fișiere de oriunde de pe aceste hard disk-uri
si putem accesa aceste date în mod aleatoriu.
Putem analiza care Informatiile din fișiere.
Si am rezolvat tot în lume anilor probleme cu prelucrarea datelor.
>> Și care a durat aproximativ 20 sau 30 ani până când degajarea
a bazei de date relaționale, care este atunci când lumea ne-am decis acum
trebuie să aibă un depozit care învinge expansiunii datelor peste fișierul
sisteme care ne-am construit. Dreapta?
Prea multe date distribuite în prea multe locuri, de-duplicarea de date,
și costul de depozitare a fost enormă.
>> În anii '70, resursa cea mai scumpe că un calculator avut a fost de stocare.
Procesorul a fost privit ca un cost fix.
Când m-am cumpăra pe centru, CPU nu ceva de lucru.
O să fie filare dacă este de fapt de lucru sau nu.
Asta e într-adevăr un cost scufundat.
>> Dar ceea ce ma costat ca de afaceri este de stocare.
Dacă am să cumpere mai multe discuri următor lună, asta e un cost real care platesc.
Și că de depozitare este scump.
>> Acum ne rapid înainte 40 ani și avem o altă problemă.
Mașinei elec este acum resursa cel mai scump.
Stocarea este ieftin.
Vreau să spun, putem merge oriunde pe nor și putem găsi de stocare ieftine.
Dar ceea ce eu nu pot găsi este de calcul ieftine.
>> Deci evoluția de astăzi tehnologie, de tehnologie de baze de date,
este cu adevărat concentrat în jurul baze de date distribuite
care nu suferă de același tip de scară
limitări ale bazelor de date relaționale.
Vom vorbi un pic despre ce înseamnă că, de fapt.
>> Dar unul dintre motivele și șoferul din spatele astea-- noi
a vorbit despre presiunea de date.
Presiune de date este ceva care conduce inovarea.
Și dacă te uiți la peste în ultimii cinci ani,
aceasta este o diagramă a ceea ce a datelor încărcare în întreaga întreprindere generală
arata ca in ultimii cinci ani.
>> Și regula generală de degetul mare aceste days-- dacă te duci Google--
este de 90% din datele pe care stocăm astăzi, și a fost
generat în ultimii doi ani.
BINE.
Acum, acest lucru nu este o tendință care este nou.
Aceasta este o tendință care a fost ieși de 100 de ani.
Inca de la Herman Hollerith a dezvoltat cardul pumn,
am fost construirea arhive de date și colectarea de date la viteze fenomenal.
>> Deci, în ultimii 100 de ani, am văzut această tendință.
Asta nu se va schimba.
Mergând mai departe, vom vedea acest lucru, în cazul în care nu o tendință accelerată.
Și puteți vedea cum arată.
>> Dacă o afacere in 2010 a avut o terabyte de date în gestiune,
astăzi că înseamnă că sunt gestionarea 6,5 ​​petabytes de date.
Asta e 6500 ori mai multe date.
Și știu acest lucru.
Lucrez cu aceste întreprinderi în fiecare zi.
Acum cinci ani, am ar vorbi cu companii
care ar vorbi cu mine despre ceea ce o durere este de a gestiona terabytes de date.
Și le-ar vorbi cu mine despre cum vom vedea
că acest lucru este, probabil, va să fie un petabyte sau două
într-un cuplu de ani.
>> Aceleași companii azi Mă întâlnesc cu,
și vorbesc cu mine despre problemă sunt acolo au de gestionare
zeci, 20 petabytes de date.
Deci explozia Date din industria
este de conducere enorme nevoie de soluții mai bune.
Și baza de date relațională este doar nu de viață de până la cererea.
>> Și deci nu este un liniar corelație între presiunea de date
și inovație tehnică.
Istoria ne-a arătat aceasta, că în timp,
ori de câte ori volumul de date care trebuie să fie procesate
depășește capacitatea sistemului să-l proceseze într-un timp rezonabil
sau la un cost rezonabil, apoi noi tehnologii
sunt inventate pentru a rezolva aceste probleme.
Aceste noi tehnologii, la rândul său, deschide ușa
la un alt set de probleme, care este colectarea de mai multe date.
>> Acum, nu vom opri acest lucru.
Dreapta?
Nu vom opri acest lucru.
Ce?
Pentru că nu poate ști totul ce trebuie să știi în univers.
Și atâta timp cât am fost în viață, de-a lungul istoriei omului,
am condus mereu să știu mai multe.
>> Deci, se pare ca fiecare inch ne mutam pe calea de descoperire stiintifica,
suntem înmulțirea valorii de date că avem nevoie pentru a procesa exponențial
cum am descoperi mai mult și mai mult și mai mult despre mecanismele interioare ale vieții,
despre modul în care funcționează universul, despre de conducere descoperire stiintifica,
și invenția care facem astăzi.
Volumul de date doar crește continuu.
Deci, fiind capabil să se ocupe de această problemă este enorm.
>> Deci, unul din lucrurile ne uităm ca de ce NoSQL?
Cum NoSQL rezolva aceasta problema?
Ei bine, baze de date relaționale, Structured Query Language,
SQL-- că e într-adevăr o de construct a relațional database-- aceste lucruri sunt
optimizat pentru depozitare.
>> Înapoi în anii '70, din nou, disc este scump.
Exercitarea de provizionare de stocare în întreprindere este nu se mai termină.
Eu stiu.
Am trăit.
I-am scris drivere de stocare pentru o companie SuperServer enterprised
înapoi în anii '90.
Și linia de jos este o altă rafturi matrice de stocare a fost doar ceva ce
sa întâmplat în fiecare zi în întreprindere.
Și nu sa oprit.
De stocare mai mare densitate, cererea pentru stocarea de înaltă densitate,
și pentru depozitare mai eficientă devices-- acestuia nu a oprit.
>> Și NoSQL este o tehnologie de mare deoarece normalizeaza datele.
Acesta de-duplicarea datelor.
Se pune datele într-o structură care este agnostic pentru orice model de acces.
Aplicații multiple pot lovi că Baze de date SQL, executați interogări ad-hoc,
și a obține date în forma pe care le Trebuie să proceseze pentru sarcini de lucru lor.
Sună fantastic.
Dar linia de jos este cu orice sistem, în cazul în care este agnostic la orice,
este optimizat pentru nimic.
OK?
>> Și asta e ceea ce vom ajunge cu baza de date relațională.
Este optimizat pentru depozitare.
E normalizat.
E relațională.
Acesta susține interogările ad-hoc.
Și ea și cântare vertical.
>> Dacă am nevoie pentru a obține o bază de date SQL mai mare sau o bază de date SQL mai puternic,
Mă duc cumpăra o bucată mai mare de fier.
OK?
Am lucrat cu o mulțime de clienți care au trecut prin upgrade-uri majore
în infrastructura SQL numai pentru a afla sase luni mai tarziu,
ei lovind din nou de perete.
Iar răspunsul de la Oracle sau MSSQL sau oricine altcineva este de a lua o cutie mai mare.
Ei bine, mai devreme sau mai târziu, nu poti cumpara un cutie mai mare, și asta e problema reala.
Avem nevoie de a schimba de fapt lucrurile.
Deci, unde face acest lucru?
Aceasta funcționează bine pentru off- Analytics, sarcini de lucru de tip OLAP.
Și asta e într-adevăr în cazul în care face parte SQL.
Acum, acesta este folosit astăzi în multe on-line tranzacțională-tip de prelucrare
aplicații.
Și funcționează foarte bine la un anumit nivel de utilizare,
dar pur si simplu nu scară modul în care NoSQL face.
Și vom vorbi un pic bit de ce, care este.
>> Acum, NoSQL, pe de altă parte, este mai optimizat pentru calcul.
OK?
Nu este agnostic a modelul de acces.
Este ceea ce noi numim de-normalizat structură sau o structură ierarhică.
Datele într-o bază de date relațională este s-au alăturat împreună de la mai multe tabele
pentru a produce de părere că aveți nevoie.
Datele din baza de date NoSQL o este stocată într-un document care
conține structura ierarhică.
Toate datele care ar fi în mod normal, s-au alăturat împreună pentru a produce acest punct de vedere
este stocată într-un singur document.
Și vom vorbi un pic despre cum funcționează într-o pereche de diagrame.
>> Dar ideea de aici este să păstrați datele ca aceste puncte de vedere. instanțiate
OK?
Tu scară orizontală.
Dreapta?
Dacă am nevoie pentru a crește mărimea clusterului meu NoSQL,
Nu am nevoie pentru a obține o cutie mai mare.
I a lua o altă cutie.
Și am grupează cele împreună, și pot ciob că datele.
Vom vorbi un pic despre ceea ce sharding este, să fie
posibilitatea de a scară care baza de date pe mai multe dispozitive fizice
și scoateți bariera care mi cere să scară verticală.
>> Deci, este într-adevăr construit pentru on-line procesarea tranzacțiilor și la scară.
Există o distincție mare aici între raportare, nu?
Raportarea, eu nu știu întrebări Mă duc să întreb.
Dreapta?
Reporting-- dacă cineva de la departamentul meu de marketing
vrea sa doar-- câți dintre clienții mei au această caracteristică special, care
cumpărate pe acest ziua-- Nu știu ce interogare au de gând să ceară.
Așa că am nevoie pentru a fi agnostic.
>> Acum, într-o on-line aplicație tranzacțională,
Știu ce întrebări îți cer.
Am construit cererea de un flux de lucru foarte specific.
OK?
Deci, dacă am optimiza datele stoca pentru a sprijini care flux de lucru,
o să fie mai rapid.
Și de aceea poate NoSQL accelera într-adevăr de livrare
acestor tipuri de servicii.
In regula.
>> Deci vom intra în un pic de teorie aici.
Iar unii dintre voi, ochii s-ar putea derula înapoi un pic.
Dar voi încerca să-l păstrați nivel la fel de mare ca pot.
Deci, dacă sunteți în proiect management, există
un construct numită triunghi de constrângeri.
BINE.
Triunghiul constrângerilor dictează nu poti avea totul tot timpul.
Nu poate avea plăcintă dvs. și mănâncă prea.
Deci, în managementul de proiect, care triunghi constrângeri este puteți să-l ieftin,
puteți să-l repede, sau puteți să-l bine.
Alege două.
Pentru că nu poți avea pe toate trei.
Dreapta?
BINE.
>> Deci ai auzit despre asta foarte mult.
Este o constrângere triplu, triunghi de triple constrângere,
sau triunghi de fier este oftentimes-- cand vorbesti cu managerii de proiect,
vor vorbi despre asta.
Acum, baze de date au propria lor triunghi de fier.
Și triunghiul de fier de date este ceea ce noi numim teorema CAP.
OK?
>> PAC dictează teorema cum baze de date funcționează
sub o stare foarte specific.
Și vom vorbi despre ceea ce este această condiție.
Dar cele trei puncte ale triunghiului, ca să spunem așa, sunt C, consistență.
OK?
Deci, în CAP, consistență înseamnă că toate clienții care pot accesa baza de date
va avea întotdeauna o foarte vedere consistent de date.
Nimeni nu vedem două lucruri diferite.
OK?
Dacă văd în baza de date, Văd același punct de vedere
ca partenerul meu care vede aceeași bază de date.
Asta e consistenta.
>> Disponibilitatea înseamnă că, dacă bază de date online, în cazul în care se poate ajunge,
că toți clienții va fi întotdeauna să poată citi și scrie.
OK?
Deci fiecare client care poate citi baza de date
va fi întotdeauna citit putea Date de date și să scrie.
Și dacă acesta este cazul, este un sistem disponibil.
>> Și al treilea punct este ceea ce numim toleranta partiție.
OK?
Mijloace de toleranță partiție că sistemul funcționează bine
în ciuda rețea fizică partiții între nodurile.
OK?
Deci, noduri din cluster nu poate vorbi unul cu celălalt, ceea ce se întâmplă?
In regula.
>> Baze de date relaționale, astfel choose-- puteți alege două dintre acestea.
BINE.
Baze de date relaționale, astfel alege să fie coerente și disponibile.
Dacă partiția se întâmplă între de DataNodes din depozitul de date,
baza de date se blochează.
Dreapta?
Pur și simplu se duce în jos.
BINE.
>> Și acest lucru este motivul pentru care au să crească cu cutii mai mari.
Dreapta?
Pentru că nu e no-- de obicei, un grup baze de date, nu este foarte mulți dintre ei
care funcționează în acest fel.
Dar cele mai multe baze de date scară vertical într-o singură cutie.
Deoarece au nevoie să fie consecvent și disponibil.
Dacă o partiție ar fi injectat, atunci va trebui să facă o alegere.
Trebuie să facă o alegere între fiind consecvent și disponibil.
>> Și asta e ceea ce fac baze de date NoSQL.
In regula.
Deci, o bază de date NoSQL ea, vine în două arome.
Noi have-- Ei bine, vine în mai multe arome,
dar vine cu două de bază characteristics-- ce
am numi de baze de date CP, sau un toleranță coerente și partiție
sistem.
Tipii ăștia a face alegerea că, atunci când nodurile pierd contactul cu celălalt,
nu vom permite oamenii să scrie orice mai mult.
OK?
>> Până la acea partiție este eliminat, acces de scriere este blocat.
Asta înseamnă că nu sunt disponibile.
Sunt consistent.
Când vom vedea că partiție sine injecta,
suntem acum coerente, pentru că nu mergem
pentru a permite schimbarea datelor de pe două laturi ale partiției independent
unul de celălalt.
Va trebui să restabili comunicare
înainte de orice actualizare a datele sunt permise.
OK?
>> Aroma următor ar fi un sistem de AP, sau un libere și porționat
Sistemul de toleranță.
Tipii ăștia nu-mi pasă.
Dreapta?
Orice nod care devine o scrie, vom lua.
Deci, eu sunt replicarea datelor meu pe mai multe noduri.
Aceste noduri obține un client, client vine în, spune, am de gând să scrie unele date.
Nod spune, nici o problema.
Nodul de lângă el devine o scriere pe aceeași înregistrare,
el va spune nici o problema.
Undeva înapoi pe partea din spate, că datele va replica.
Și apoi cineva va realiza, uh-oh, sistemul își vor da seama, uh-oh,
acolo a fost o actualizare a două părți.
Ce facem?
Și ceea ce fac ei, atunci este fac ceva care
le permite să rezolve această stare de date.
Și vom vorbi despre că în graficul următor.
>> Lucru să sublinieze aici.
Iar eu nu am de gând pentru a obține prea mult în acest lucru, deoarece aceasta
ajunge în teorie de date adânc.
Dar există o tranzacțional cadru care
ruleaza într-un sistem relațional care mi permite să facă în condiții de siguranță actualizări
la mai multe entități în baza de date.
Și aceste actualizări vor avea loc dintr-o dată sau nu la toate.
Și aceasta se numește tranzacții ACID.
OK?
>> ACID ne dă atomicitatea, consistență, izolare, și durabilitate.
OK?
Asta înseamnă că atomice, tranzacții, toate actualizările mele fie întâmpla sau nu.
Coerența înseamnă că baza de date va fi întotdeauna
fi aduse într-o consistentă de stat după o actualizare.
Eu nu va lăsa baza de date într-un stare de rău după aplicarea o actualizare.
OK?
>> Deci, este un pic diferit decât PAC consistenta.
CAP consistență înseamnă toate meu clienții pot vedea întotdeauna datele.
Consistență ACID înseamnă că, atunci când o tranzacție a făcut, de date e bine.
Relațiile mele sunt toate bune.
Eu nu am de gând să ștergeți un rând părinte și se lasă o grămadă de copii orfani
într-o altă tabelă.
Nu se poate întâmpla dacă eu sunt în concordanță într-o tranzacție de acid.
>> Izolarea înseamnă că tranzacțiile va avea loc întotdeauna una după alta.
Rezultatul final al datelor va fi aceeași stare
ca în cazul în aceste tranzacții care au fost emise simultan
au fost executați în serie.
Deci e concurenta de control în baza de date.
Deci, practic, nu pot incrementa aceeași valoare de două ori cu două operațiuni.
>> Dar dacă spun adăuga 1 la această valoare, și două tranzacții vin în
și să încerce să o facă, un e O să ajung acolo primul
și celuilalt O să ajung acolo după.
Deci, în cele din urmă, am adăugat două.
Vezi ce vreau să spun?
BINE.
>> Durabilitatea este destul de simplă.
Atunci când tranzacția este recunoscut, este
O să fie acolo, chiar în cazul în care sistemul se blochează.
Când acest sistem recupereaza, care tranzacție care a fost săvârșită
este, de fapt va fi acolo.
Așa că e garanțiile tranzacțiilor ACID.
Acestea sunt garanții destul de frumos pentru a avea o bază de date,
dar au venit la acest cost.
Dreapta?
>> Deoarece problema cu acest cadru este
dacă există o partiție în datele set, trebuie să ia o decizie.
Am de gând să trebuie să permită actualizări pe o parte sau alta.
Și dacă acest lucru se întâmplă, atunci nu mai merg sunt
să fie capabil să mențină aceste caracteristici.
Ei nu vor fi în concordanță.
Ele nu vor fi izolate.
Acest lucru este în cazul în care se strică pentru baze de date relaționale.
Aceasta este relațional motiv baze de date scară verticală.
>> Pe de altă parte, avem ceea ce se numește tehnologie de bază.
Și acestea sunt NoSQL bazele de date.
In regula.
Deci avem CP nostru, baze de date AP.
Și acestea sunt ceea ce voi numiți practic disponibil de stat, moale, în cele din urmă
consistent.
OK?
>> Practic disponibile, deoarece sunt partiție tolerant.
Ei vor fi întotdeauna acolo, chiar dacă nu există
o partiție de rețea între noduri.
Dacă aș putea vorbi cu un nod, sunt va fi capabil să citească date.
OK?
S-ar putea să nu fie întotdeauna în măsură să scrie date în cazul în care sunt o platformă consistentă.
Dar voi fi capabil să citească date.
>> Starea moale indică că, atunci când am citit că datele,
s-ar putea să nu fie la fel ca alte noduri.
În cazul în care un drept a fost emis pe un nod în altă parte în cluster
și nu a replicat pe întreg teritoriul UE grup dar atunci când am citit că datele,
acest stat ar putea să nu fie în concordanță.
Cu toate acestea, ea va fi în cele din urmă consistent,
ceea ce înseamnă că, atunci când o scriere se face în sistem,
acesta va reproduce peste nodurile.
Și în cele din urmă, această stare vor fi aduse în ordine,
și va fi o stare consistentă.
>> Acum, într-adevăr teorema CAP joaca doar într-un singur condiție.
Această condiție este atunci când se întâmplă acest lucru.
Pentru că ori de câte ori este operează în modul normal, nu exista nici o partiție,
Totul e consistentă și disponibile.
Îți faci griji cu privire la PAC numai atunci când avem acea partiție.
Deci, acestea sunt rare.
Dar modul în care sistemul reacționează atunci când cei apar dicta ce tip de sistem
avem de-a face cu.
>> Deci, haideți să aruncăm o privire la ceea ce care arata ca pentru sistemele de AP.
OK?
Sisteme de AP vin in doua arome.
Ei vin în aroma, care este o maestru maestru, 100%, întotdeauna disponibile.
Și au venit în alte aroma, care spune,
Știi ce, am de gând să vă faceți griji despre acest lucru de partiționare
atunci când are loc o partiție actuale.
În caz contrar, acolo va fi primar noduri care va lua drepturile.
OK?
>> Deci, dacă am ceva de genul Cassandra.
Cassandra ar fi un maestru master, permiteți-mi scrie la e orice nod.
Deci, ce se întâmplă?
Așa că am un obiect în baze de date care există pe două noduri.
Să numim acest obiect S. Deci avem de stat pentru S.
Avem unele operațiuni pe S, care sunt în curs de desfășurare.
Cassandra mi permite să scrie la mai multe noduri.
Deci, să spunem că am o scrie pentru de a două noduri.
Ei bine, ce se termină întâmplă este numim că un eveniment de partiționare.
Nu poate fi un partiție de rețea fizică.
Dar, din cauza de proiectare a sistemului, este
de fapt, de partiționare cât mai curând așa cum am lua o scrie pe două noduri.
Nu mă forțează să scrie toate printr-un singur nod.
Scriu pe două noduri.
OK?
>> Deci, acum am două state.
OK?
Ce se va întâmpla este devreme sau mai târziu,
acolo va fi un eveniment de replicare.
Acolo va fi ceea ce ne-am numit de recuperare partiție, care
este în cazul în care aceste două Statele întoarce împreună
și acolo va fi un algoritm care ruleaza in interiorul bazei de date,
decide ce să facă.
OK?
În mod implicit, Ultima modificare câștigă în cele mai multe sisteme AP.
Deci, există de obicei, un algoritm implicit, ceea ce
ei numesc un apel invers funcție, ceva care
va fi numit atunci când această condiție este detectată pentru a executa unele logica
pentru a rezolva acest conflict.
OK?
Callback implicit și implicit resolver în cele mai multe baze de date AP
este, ghici ce, timestamp castiga.
Aceasta a fost ultima actualizare.
Am de gând să pun că actualizarea acolo.
S-ar putea benă acest record pe care am fac obiectul unui dumping de pe într-un jurnal de recuperare
astfel încât utilizatorul poate întoarce mai târziu și spune, hei, nu a fost o coliziune.
Ce s-a întâmplat?
Și vă puteți arunca de fapt o înregistrare de toate coliziunile și rollbacks
și să vedem ce se întâmplă.
>> Acum, ca utilizator, puteți, de asemenea includ logica în care de apel invers.
Astfel încât să puteți schimba asta operațiune de apel invers.
Puteți spune, hei, vreau pentru remedierea acestei date.
Și vreau să încerc și fuziona cele două înregistrări.
Dar asta depinde de tine.
Baza de date nu știe cum să face acest lucru în mod implicit. Cele mai multe ori,
singurul lucru baza de date știe cum să facă este spus,
acesta a fost ultima înregistrare.
Asta e cea care va câștiga, și asta e valoarea am de gând să pun.
Odată ce partiție de recuperare și replicarea apare,
avem statul nostru, care este acum S prim, care este
starea îmbinare de toate aceste obiecte.
Deci, sisteme de AP au acest.
Sisteme de CP nu au nevoie de să vă faceți griji despre acest lucru.
Pentru că, de îndată ce vine o partiție în joc, doar ei nu mai luați
scrie.
OK?
Așa că e foarte ușor să a face cu a fi în concordanță
atunci când nu accepta nici actualizări.
Asta e cu sistemele CP face.
In regula.
>> Deci, hai sa vorbim un pic bit despre modelele de acces.
Când vorbim despre NoSQL, e Totul despre modelul de acces.
Acum, SQL este ad-hoc, interogări.
Este magazin relațională.
Noi nu trebuie să vă faceți griji despre modelul de acces.
Scriu o interogare foarte complex.
Se merge și devine datele.
Asta e ceea ce pare acest cum ar fi, de normalizare.
>> Deci, în această structură special, ne uitam la un catalog de produse.
Am diferite tipuri de produse.
Am cărți.
Am albume.
Am videoclipuri.
Relația dintre produse și oricare dintre aceste cărți, albume,
și video mese este de 1: 1.
In regula?
Am un ID de produs, și care corespunde ID
la o carte, un album sau un videoclip.
OK?
Asta-i un 1: 1 relație peste aceste tabele.
>> Acum, tot ce books-- au proprietăți este rădăcină.
Nici o problema.
Grozav.
One-la-unu relație, mă tot datele trebuie să descrie acea carte.
Albumele Albums-- au piese.
Aceasta este ceea ce noi numim o la mai multe.
Fiecare album poate avea mai multe piese.
Deci, pentru fiecare piesa de pe albumul, am putea avea
un alt record în acest tabel copil.
Așa că am crea o înregistrare în masa mea albume.
Am crea mai multe înregistrări în tabelul piste.
One-la-mai mulți relație.
>> Această relație este ceea ce numim mulți-la-mai-mulți.
OK?
Vezi că actorii ar putea fi în multe filme, multe videoclipuri.
Deci, ceea ce facem este să punem această cartografiere tabel între cei, care doar
Hărți ID actor la ID-ul video.
Acum pot crea o interogare îmbinările video prin video de actor la actori,
și dă-mi o listă frumos de toate filmele și toți actorii
care au fost în acel film.
>> BINE.
Deci, aici vom merge.
One-to-one este de nivel superior relaţie; unu-la-mulți,
Albumele de piste; multe-la-mai mulți.
Acestea sunt de trei nivel superior relații în orice bază de date.
Dacă știți cum cei relatii lucreze împreună,
atunci știi o mulțime despre deja de baze de date.
Deci, NoSQL funcționează un pic diferit.
Să ne gândim pentru un al doilea ceea ce Se pare că pentru a merge obține toate produsele mele.
>> Într-un magazin relațională, am doriți să obțineți toate produsele mele
pe o listă cu toate produsele mele.
Asta-i o mulțime de întrebări.
Am o interogare pentru toate cărțile mele.
Am o interogare de la albumele mele.
Și am o interogare pentru toate videoclipurile mele.
Și am ajuns să-l pună toate împreună într-o listă
și-l servi înapoi la aplicație Asta e solicitant.
>> Pentru a obține cărțile mele, mă alătur Produse și cărți.
Pentru a obține albumele mele, am ajuns să se alăture Produse, Albume, Melodii și.
Și pentru a obține videoclipurile mele, am să se alăture Produse la Videoclipuri,
se alăture prin actor Videoclipuri, și să aducă în actori.
Așa că e trei interogări.
Interogări foarte complexe la asambla un set de rezultate.
>> Asta e mai puțin optimă.
Acesta este motivul pentru atunci când vorbim despre o structură de date care este
construite pentru a fi agnostic la accesul pattern-- Și e minunat.
Și puteți vedea acest lucru este într-adevăr frumos cum am organizat datele.
Și știi ce?
Am doar o singură înregistrare pentru un actor.
>> Asta e tare.
Am deduplicated toți actorii mei, și am menținut asociații mei
în acest tabel de mapare.
Cu toate acestea, obtinerea de date out devine scump.
Eu trimit CPU peste tot sistemul aderarea la aceste structuri de date împreună
pentru a fi capabil de a trage înapoi de date.
>> Deci, cum pot obține în jurul valorii de asta?
În NoSQL este vorba despre agregare, nu de normalizare.
Deci, vrem să spunem că doriți să sprijini modelul de accesare.
În cazul în care modelul de acces cererilor,
Am nevoie pentru a obține toate produsele mele.
Să punem toate produsele într-un tabel.
Dacă am pune toate produsele într-un tabel, Pot selecta doar toate produsele
de la acea masă și am lua toate.
Ei bine, cum fac asta?
Ei bine, în NoSQL nu există Structura tabelului.
Vom vorbi un pic despre cum functioneaza la Dynamo DB.
Dar nu ai la fel atributele și aceleași proprietăți
în fiecare rând singur, în fiecare element, cum faci într-un tabel SQL.
Și ce îmi permite acest pentru a face o mulțime de lucruri
si da-mi o mulțime de flexibilitate.
În acest caz particular, am au documentele mele de produse.
Și în acest special exemplu, totul
este un document în tabelul Produse.
Și produsul pentru o carte ar putea au un ID de tip care specifică o carte.
Și cererea ar orienta pe acel ID.
>> La nivel de aplicare, am de gând să spun oh, ce tip de înregistrare este asta?
Oh, e un record carte.
Înregistrări de carte au aceste proprietăți.
Lasă-mă să creeze un obiect carte.
Deci, am de gând să umple obiect carte cu acest articol.
Articolul următor vine și spune, ce e acest articol?
Ei bine, acest articol este un album.
Oh, am o cu totul diferit rutina de prelucrare pentru că,
pentru ca este un album.
Vezi ce vreau să spun?
>> Astfel încât cererea tier-- I doar selecta toate aceste înregistrări.
Acestea toate incepe sa vina.
Ele ar putea fi toate tipurile diferite.
Și e logica aplicației care trece peste aceste tipuri de
și decide cum să le proceseze.
>> Din nou, așa că optimizarea schema pentru modelul de acces.
O facem prin colaps aceste tabele.
Suntem practic luați aceste structuri normalizate,
si ne construim structuri ierarhice.
În interiorul fiecare dintre aceste înregistrări Mă duc să văd proprietăți matrice.
>> În interiorul acestui document pentru Albume, Văd rețele de piste.
Aceste piese become-- acum e practic acest tabel copil care
există chiar aici, în această structură.
Astfel încât să puteți face acest lucru în DynamoDB.
Puteți face acest lucru în MongoDB.
Puteți face acest lucru în orice bază de date NoSQL.
Crea aceste tipuri de structuri de date ierarhice
care vă permit să preluați date foarte repede pentru că acum
nu trebuie să se conformeze.
Când inserați un rând în Tracks masă, sau un rând în tabelul Albume,
Trebuie să se conformeze că schema.
Trebuie să aibă atributul sau proprietate care este definit pe masă.
Fiecare dintre ei, atunci când am insera acel rând.
Asta nu e cazul în NoSQL.
>> Pot avea cu totul alt proprietăți în fiecare document de
că am insera în colecție.
Mecanism atât de foarte puternic.
Și este într-adevăr modul în care optimizarea sistemului.
Pentru că acum că interogare, în loc să de a se alătura toate aceste tabele
și executarea de o jumătate de duzină interogări pentru a trage înapoi datele am nevoie,
Sunt de executare o interogare.
Și mă iterarea peste rezultatele stabilite.
îți dă o idee a puterii de NoSQL.
Am de gând să fel de a merge lateral aici și vorbesc un pic despre asta.
Acest lucru este mai mult un fel de de marketing sau technology--
comercializarea de tehnologie tip de discuție.
Dar este important să înțelegem pentru că dacă ne uităm la partea de sus
aici, la această diagramă, ceea ce ne uităm la
este ceea ce noi numim Tehnologia curba hype.
Și ce înseamnă acest lucru este chestii noi intră în joc.
Oamenii cred că e minunat.
Am rezolvat toate problemele mele.
>> Acest lucru ar putea fi sfârșitul toate, să fie toate la tot.
Și ei începe să utilizați-l.
Și spun ei, chestia asta nu funcționează.
Acest lucru nu este corect.
Lucruri vechi a fost mai bine.
Și se întorc de a face lucrurile așa cum erau.
Și apoi în cele din urmă ei merg, știi ce?
Chestia asta nu este atât de rău.
Oh, asta e cum funcționează.
Și odată ce își vor da seama cum lucrări, ei încep tot mai bine.
>> Și lucrul amuzant despre ea este, un fel de linii de până la ceea ce
numim Curve Technology Adoptare.
Deci, ceea ce se întâmplă e că avem unele de declanșare tehnologie fel.
În cazul bazelor de date, e presiune date.
Am vorbit despre punctele ridicate de apă de presiune date de-a lungul timpului.
În momentul în care presiunea de date lovește un anumit punct, care este un declanșator tehnologie.
>> E prea scump.
Este nevoie de prea mult timp pentru a procesa datele.
Avem nevoie de ceva mai bun.
Ai inovatorii acolo rulează în jurul,
încercarea de a afla care este solutia.
Care este noua idee?
>> Care este cel mai bun următoare mod de a face asta?
Și au venit cu ceva.
Și persoanele cu durere reală, baietii de la marginea sângerare,
vor sări peste tot ea, pentru că au nevoie de un răspuns.
Acum, ceea ce în mod inevitabil și happens-- se întâmplă acum în NoSQL.
O văd tot timpul.
>> Ce se întâmplă în mod inevitabil este oameni începe să utilizați noul instrument
în același mod au folosit instrumentul vechi.
Și au aflat că nu funcționează atât de bine.
Nu-mi amintesc cine eram vorbesc cu mai devreme.
Dar e ca si cum, atunci când jackhammer a fost inventat,
oamenii nu l-leagăn peste capul lor pentru a sparge betonul.
>> Dar asta este ceea ce este întâmplă cu NoSQL astăzi.
Dacă te plimbi în cele mai multe magazine de, ei încearcă să fie magazine NoSQL.
Ceea ce fac este ei folosesc NoSQL,
și ei l de încărcare plin de schemă relațională.
Pentru că așa ei de design baze de date.
Și ei te intrebi, de ce este nu desfășoară foarte bine?
Băiat, acest lucru pute.
A trebuit să-mi mențin toate se alătură in-- e ca, nu, nu.
Menținerea se alătură?
De ce aderarea la date?
Tu nu se alăture de date în NoSQL.
Ai agregate.
>> Deci, dacă doriți, pentru a evita acest lucru, să învețe cum funcționează instrumentul înainte de fapt
a începe să utilizați-l.
Nu încercați și de a folosi instrumente noi același mod în care a folosit vechile instrumente.
Vei avea o experiență neplăcută.
Și de fiecare dată asta e ceea ce e vorba.
Când ne-am începe vine aici, e pentru că oamenii dat seama
modul de utilizare a instrumentelor.
>> Ei au făcut același lucru atunci când baze de date relaționale au fost inventate,
și au fost înlocuirea sistemelor de fișiere.
Au încercat să construiască sisteme de fișiere cu baze de date relaționale
pentru că asta e ceea ce a înțeles oamenii.
Ea nu a funcționat.
Deci, înțelegerea celor mai bune practici tehnologiei lucrați cu
este imens.
Foarte important.
>> Deci vom intra în DynamoDB.
DynamoDB este de AWS -a reușit pe deplin platforma NoSQL.
Ce a reușit pe deplin-înseamnă?
Aceasta înseamnă că nu trebuie să într-adevăr vă faceți griji despre nimic.
>> Ai venit în, să-ți spun ne, am nevoie de o masa.
Este nevoie de această capacitate de mult.
Te-a lovit butonul, și furnizarea noi toată infrastructura din spatele scenei.
Acum, că este enorm.
>> Pentru că atunci când vorbești despre scalarea o bază de date,
Clustere de date NoSQL la scară, petabytes de funcționare,
funcționare milioane de tranzacții pe secundă,
aceste lucruri nu sunt grupuri mici.
Vorbim de mii de cazuri.
Gestionarea mii de cazuri, chiar cazuri virtuale,
este o adevarata durere în fund.
Adică, cred că despre fiecare dată când un sistem de patch-uri de operare iese
sau o nouă versiune a bazei de date.
Ce inseamna pentru tine operațional?
Asta înseamnă că ai 1200 servere care trebuie să fie actualizate.
Acum, chiar și cu automatizare, care poate lua o lungă perioadă de timp.
Care poate provoca o mulțime de dureri de cap operaționale,
pentru că s-ar putea avea servicii în jos.
>> Așa cum am actualiza aceste baze de date, am s-ar putea face implementări albastru verde
în cazul în care am implementat și upgrade jumătate meu noduri, și apoi upgrade la cealaltă jumătate.
Ia cele jos.
Deci gestionează infrastructura scară este extrem de dureros.
Și AWS ia durerea din ea.
Si baze de date NoSQL poate extraordinar de dureros să fie
din cauza modului în care scara.
>> Scale orizontal.
Dacă doriți să obțineți un NoSQL mai mare de baze de date, de a cumpăra mai multe noduri.
Fiecare nod cumperi este un alt dureri de cap operaționale.
Așa că haideți să altcineva face asta pentru tine.
AWS poate face asta.
>> Noi sprijinim valorile cheie de documente.
Acum, noi nu a mers prea mult în pe harta altei.
Există o mulțime de diferite arome de NoSQL.
Sunt tot felul de a obține munged împreună în acest moment.
Poti sa te uiti la DynamoDB și spune da, suntem amândoi un document și o valoare cheie
stoca acest punct.
Și tu poți argumenta caracteristicile din unul peste celălalt.
Pentru mine, o mulțime de acest lucru este într-adevăr șase de o jumătate de duzină de celălalt.
Fiecare dintre aceste tehnologii este un Tehnologia FINE și o soluție amendă.
Nu aș putea spune MongoDB este mai bine sau mai rău decât Couch, atunci Cassandra,
apoi Dynamo, sau invers.
Adică, acestea sunt doar opțiuni.
>> E rapid și e consistent la orice scară.
Deci, aceasta este una dintre cele mai mari bonusuri te cu AWS.
Cu DynamoDB este abilitatea pentru a obține o singură cifră scăzută
latență milisecunde la orice scară.
Acesta a fost un obiectiv de proiectare a sistemului.
Și avem clienti care fac milioane de tranzacții pe secundă.
>> Acum mă duc prin unele dintre cele utiliza cazuri în câteva minute aici.
Control-- acces integrat avem ceea ce noi numim
Identity Access Management, sau IAM.
Acesta pătrunde fiecare sistem, fiecare serviciu care ofera AWS.
DynamoDB nu este o excepție.
Puteți controla accesul la tabelele DynamoDB.
Peste toate AWS dumneavoastră conturile de definirea rolurilor de acces și permisiuni
în infrastructura IAM.
>> Și este o componenta cheie și integrală în ceea ce noi numim Event Driven programare.
Acum, acest lucru este o nouă paradigmă.
>> Audiența: Cum e rata de adevărat pozitive față de rezultatele negative false
pe sistemul dvs. de control al accesului?
RICK Houlihan: Adevărații pozitive versus negative false?
Audiența: Returnarea ce ar trebui să fie întoarce?
Spre deosebire de o dată într-un timp nu se întoarce atunci când ar trebui să valideze?
>> RICK Houlihan: nu am putut să spun că.
Dacă există defecțiuni bazate pe faptul că,
Eu nu sunt persoana de a cere această întrebare special.
Dar asta este o întrebare bună.
Aș fi curios să știu că eu, de fapt.
>> Și astfel apoi, din nou, nouă paradigmă este de programare condus eveniment.
Aceasta este ideea pe care le puteți implementa aplicatii complexe care
poate opera o foarte, foarte mare la scară fără nici un fel de infrastructură.
Fără nici o fix Infrastructura fel.
Și vom vorbi un pic despre ceea ce înseamnă că pe măsură ce
ajunge la următoarele două diagrame.
>> Primul lucru pe care vom face este vom vorbi despre mese.
Tipuri de date API pentru Dinamo.
Și primul lucru pe care veți observă atunci când te uiți la asta,
Dacă sunteți familiarizat cu orice bază de date, baze de date într-adevăr două tipuri de API-uri
Aș numi.
Sau două seturi de API.
Unul dintre acestea ar fi API administrativă.
>> Lucrurile pe care le avea grijă de funcțiile bazei de date.
Configurarea motorului de stocare, înființarea și adăugarea mese.
crearea de baze de date cataloage și cazuri.
Acestea lucruri-- în DynamoDB, tu au liste foarte scurte, scurte.
>> Deci, în alte baze de date, s-ar putea vedea zeci
de comenzi, de administrative comenzi, pentru configurarea
aceste opțiuni suplimentare.
În DynamoDB nu aveți nevoie de cele din cauza nu configurați sistemul, facem.
Deci, singurul lucru ce trebuie sa faci este spune-mi ce tabel dimensiune am nevoie.
Astfel încât să obțineți o foarte set limitat de comenzi.
>> Ai un Creează masă actualizare, de masă, Șterge de masă, și să descrie tabelul.
Acestea sunt singurele lucruri aveți nevoie pentru DynamoDB.
Nu aveți nevoie de un depozitare configurație motor.
Nu am nevoie să vă faceți griji cu privire la replicarea.
Nu am nevoie să vă faceți griji cu privire la sharding.
>> Nu am nevoie să vă faceți griji cu privire la orice din astea.
Noi face totul pentru tine.
Deci asta este o mare cantitate de deasupra capului asta e doar decolat farfurie.
Apoi avem operatorii CRUD.
CRUD este ceva ce noi apel în baza de date care este
Crea, actualiza, Ștergere operatori.
Acestea sunt comune dvs. operațiunile de bază de date.
Lucruri ca element pune, pentru a primi obiect, actualizare articole, șterge elemente, interogare lot, scanare.
Dacă doriți să scanați întregul tabel.
Trageți totul pe masă.
Unul dintre lucrurile frumoase despre DynamoDB este permite scanarea în paralel.
Astfel încât să puteți de fapt, să-mi spuneți cât de multe fire vrei să ruleze pe acea scanare.
Și putem rula aceste fire.
Putem roti care scana până peste mai multe fire
astfel încât să puteți scana întregul tabel spațiu foarte, foarte repede în DynamoDB.
>> Celălalt API avem este ceea ce noi numim Streams API-ul nostru.
Noi nu o să vorbesc prea mult despre asta acum.
Am o parte a conținutului mai târziu pe de punte despre acest lucru.
Dar este într-adevăr un Streams running-- cred ca e timpul ordonat
și schimbare partiție jurnal.
Tot ce se întâmplă pe tabelul apare pe fluxul.
>> Fiecare scrie la masa apare pe fluxul.
Puteți citi acel flux și poti sa faci lucruri cu ea.
Vom vorbi despre ceea ce tipuri de lucruri pe care le
a face cu lucruri, cum ar fi replicare, crearea indici secundari.
Toate tipurile de foarte cool lucruri pe care le pot face cu asta.
>> Tipuri de date.
În DynamoDB, susținem atât cheie valoare și de date de documente tipuri.
Pe partea stângă a ecranului aici, avem tipuri de noastre de bază.
Tipuri de valoare cheie.
Acestea sunt siruri de caractere, numere, și binare.
>> Deci, doar trei tipuri de bază.
Și apoi puteți avea seturi de cele.
Unul dintre lucrurile frumoase despre NoSQL este vă pot conține tablouri ca proprietăți.
Și cu DynamoDB puteti conține tablouri de tipuri de bază ca o proprietate rădăcină.
>> Și apoi există tipurile de documente.
Cât de mulți oameni sunt familiarizati cu JSON?
Voi familiarizat cu JSON atât de mult?
Este practic JavaScript, Obiect, Notation.
Acesta vă permite să practic definesc o structură ierarhică.
>> Puteți stoca un document JSON pe DynamoDB folosind componente comune
sau blocuri care sunt disponibile în cele mai multe limbaje de programare.
Deci, dacă aveți Java, ești uita la hărți și liste.
Pot crea obiecte zona harta.
O hartă ca valori cheie stocate ca proprietăți.
Și ar putea avea liste de valori în acele proprietăți.
Puteți stoca acest complex structură ierarhică
ca un singur atribut de un element DynamoDB.
>> Deci, tabele în DynamoDB, la fel ca majoritatea Baze de date NoSQL, tabele au produs.
În MongoDB v-ar numesc aceste documente.
Și ar fi baza canapea.
De asemenea, o bază de date de documente.
Te sun aceste documente.
Documentele sau elementele au atribute.
Atribute pot exista sau nu exista pe elementul.
În DynamoDB, există un atribut obligatoriu.
La fel ca într-o bază de date relațională, aveți o cheie primară pe masă.
>> DynamoDB are ceea ce noi numim o cheie hash.
Tasta Diez trebuie să fie unic.
Așa că atunci când am defini un tabel hash, Practic ceea ce vreau să spun
este fiecare element va avea o cheie hash.
Și fiecare tasta Diez trebuie să fie unic.
>> Fiecare element este definit de care cheie unică hash.
Și nu poate fi decât unul.
Acest lucru este OK, dar de multe ori ceea ce oamenii au nevoie
este ce doresc este acest hash cheie pentru a face un pic mai mult
decât să fie doar un identificator unic.
Deseori am doriți să utilizați cheia hash ca partea de sus cupei nivel de agregare.
Și modul în care face acest lucru este de adăugând ceea ce noi numim o cheie gama.
>> Deci, dacă e doar un hash tabel, aceasta trebuie să fie unic.
Daca este un tabel hash și interval, combinație de hash și gama
trebuie să fie unic.
Deci, cred că despre el în acest fel.
Dacă am un forum.
Și forma are subiecte, nu are posturi, și are răspunsuri.
>> Așa că am putea avea un hash cheie, care este ID-ul subiect.
Și ar putea să am o cheie interval, care este ID răspuns.
În acest fel, dacă vreau pentru a obține toate Răspunsurile pentru anumit subiect,
Eu poate interoga doar hash.
Pot spune doar da-mi tot elementele care au acest hash.
Și am de gând pentru a obține fiecare întrebare sau posta pentru acest subiect particular.
Aceste agregate la nivel de top sunt foarte importante.
Acestea susțin accesul primar model al cererii.
În general vorbind, acest este ceea ce vrem să facem.
Dorim ca table-- în timp ce încărcați masa,
vrem să structureze datele La masa în așa fel
că cererea poate foarte prelua rapid aceste rezultate.
Și deseori modul de a face acest lucru este pentru a menține aceste agregări Așa cum am
introduce datele.
Practic, suntem răspândirea datelor în găleată luminos ca vine in.
>> Tastele Gama permite hash mine-- Tastele trebuie să fie egalitate.
Când m-am interoga un hash, trebuie să spun da-mi un hash care este egal cu acest lucru.
Când m-am interoga o gamă, am pot spune da-mi o gama
care utilizează orice tip de Operatorul bogat pe care le susține.
Dă-mi toate elementele pentru un hash.
Este egal, mai mare decât, mai puțin, nu-l începe cu,
nu mai există între aceste două valori?
Deci, aceste tipuri de interogări gama că suntem mereu interesati de.
Acum un lucru despre datele, atunci când te uiți la accesarea datelor, atunci când
ai acces la date, e mereu despre o agregare.
E mereu despre înregistrările care sunt legate de această.
Dă-mi tot ce aici that's-- toate tranzacțiile de pe acest card de credit
pentru ultima lună.
Asta e un agregare.
>> Aproape tot ceea ce face în bază de date este un fel de agregare.
Deci fiind capabil să fie în măsură să definească aceste găleți și vă va oferi aceste gama
atribute pentru a putea interoga pe, aceste interogări bogate sprijini mulți,
multe, multe modele de acces cerere.
>> Deci celălalt lucru pe tasta Diez Are este ne dă un mecanism
să fie capabil să se răspândească datele jurul.
Baze de date NoSQL funcționează cel mai bine când datele sunt uniform
distribuite pe cluster.
Cât de mulți oameni sunt familiarizati cu hashing algoritmi?
Când spun hash și o hashing-- pentru că un algoritm de hashing
este un mod de a fi în măsură să genereze o valoare aleatoare de la orice valoare dată.
Deci, în acest caz particular, algoritmul hash vom rula este ND 5 pe baza.
>> Și dacă am un ID, iar acest lucru este cheia hash, am 1, 2, 3.
Când m-am rula algoritmul hash, este de gând să se întoarcă și să spună,
bine 1 este egal cu 7B, 2 este egal cu 48, 3 este egal cu CD.
Sunt răspândit peste tot în spațiul cheie.
Și de ce faci asta?
Pentru că face sigur că pot pune înregistrările pe mai multe noduri.
>> Dacă fac asta incremental, 1, 2, 3.
Și am o gamă hash care execută în acest caz particular,
un spațiu hash mic, ruleaza de la 00 la FF,
apoi înregistrările sunt de gând să vină în și ei vor să meargă 1, 2, 3, 4, 5,
6, 7, 8, 9, 10, 11, 12.
Ce se întâmplă?
Fiecare inserție va același nod.
Vezi ce vreau să spun?
>> Pentru că atunci când am împărțit spațiul, și am răspândit aceste înregistrări peste,
și partiție I, am de gând să spun partiție 1 are spațiu cheie 0-54.
Partition 2 este 55-89.
Partition 3 este AA de FF.
Deci, dacă eu sunt, folosind liniar incrementarea ID-uri, puteți vedea ce se întâmplă.
1, 2, 3, 4, 5, 6, toate drumul până la 54.
Deci, ca eu sunt percuție înregistrări în sistem,
totul sfârșește merge la un nod.
>> Asta nu este bine.
Asta e un antipattern.
În MongoDB au această problemă dacă nu utilizați o cheie hash.
MongoDB vă oferă opțiunea de de hashing valoarea cheii.
Tu ar trebui să facă întotdeauna că, în cazul în care utilizați un hash incrementare
cheie în MongoDB, sau veți fi cuie fiecare scriere la un nod,
și veți fi limitarea tranzitată dumneavoastră scrie prost.
>> Audiența: Este A9 169 în zecimal?
>> RICK Houlihan: Da, e undeva în jurul valorii de acolo.
A9, nu știu.
Ar trebui să se binar meu la calculator zecimal.
Creierul meu nu funcționează așa.
Audiența: Doar una rapidă de comentariile tale Mongo.
Deci este ID-ul de obiect care vine nativ cu Mongo face asta?
RICK Houlihan: Are face asta?
Dacă îl specificați.
Cu MongoDB, aveți opțiunea.
Puteți specify-- fiecare document MongoDB trebuie să aibă un ID de subliniere.
Asta e valoarea unică.
>> În MongoDB puteți specifica dacă să-l hash sau nu.
Ei doar vă oferă opțiunea.
Dacă știți că este aleatoare, nici o problema.
Nu aveți nevoie să faci asta.
Dacă știți că nu este întâmplătoare, care este incrementarea, apoi face hash.
>> Acum, lucru despre hashing, odată ce hash
un value-- și aceasta este de ce chei hash sunt întotdeauna
interogări unice, pentru că m-am schimbat valoarea, acum eu nu pot face o interogare domeniu.
Nu pot să spun este aceasta între acest lucru sau că,
deoarece valoarea hash nu se va să fie echivalentă cu valoarea reală.
Deci, atunci când hash care cheie, e doar egalitatea.
De aceea, în tasta Diez DynamoDB interogări sunt întotdeauna doar egalitatea.
>> Deci, acum într-o gamă key-- când am adăuga că cheia interval,
aceste înregistrări cheie cu rază venit tot în și contră, se depozitează pe aceeași partiție.
Astfel încât acestea sunt foarte repede, usor recuperat deoarece aceasta este hash,
aceasta este gama.
Și veți vedea totul cu același hash
se stocate pe același spațiu partiție.
Puteți folosi cheia pentru a ajuta la gama localiza datele aproape de mamă.
Deci, ce caut eu de fapt aici?
Acesta este unul de foarte multe relații.
Relația dintre o cheie hash iar cheia gama este unul de multe.
Pot avea mai multe chei hash.
Eu pot avea doar gama multiple Taste în fiecare tasta Diez.
>> Hash definește părinte, intervalul definește copiilor.
Deci, puteți vedea acolo este analog aici între constructul relațional
și aceleași tipuri de construiește în NoSQL.
Oamenii vorbesc despre NoSQL ca nonrelational.
Nu e nonrelational.
Date are întotdeauna relații.
Aceste relații doar sunt modelate diferit.
Hai sa vorbim un pic bit despre durabilitate.
Când scrie DynamoDB, scrie sunt întotdeauna trei căi replicat.
Ceea ce înseamnă că avem trei de AZ.
Lui AZ sunt zone de disponibilitate.
Vă puteți gândi la o disponibilitate Zone ca un centru de date
sau o colectie de centre de date.
Aceste lucruri sunt punct de vedere geografic izolate una de alta
în diferite zone de avarie, peste diferite rețele electrice și zonele inundabile.
Un eșec într-o AZ nu este va lua în jos un alt.
Ele sunt, de asemenea, legate împreună cu fibra de întuneric.
Aceasta susține o sub 1 latență milisecunda între AZS.
Deci repetiții date în timp real capabil în AZS multe.
>> Și implementări de multe ori mai multe AZ să îndeplinească cerințele ridicate de disponibilitate
de cele mai multe organizatii Intreprindere.
Deci DynamoDB se răspândește pe trei AZS implicit.
Vom doar la cunoștințe de scriere atunci când două dintre aceste trei noduri întoarce
și spune, Da, am înțeles.
De ce este asta?
Deoarece pe partea citire suntem numai gând să vă dau datele înapoi, atunci când
am lua de la două noduri.
>> Dacă am replicarea peste trei, și am citit de la doi,
Sunt mereu garantat să aibă cel puțin unul
din cei citește să fie cele mai multe copie curentă a datelor.
Asta e ceea ce face DynamoDB consistent.
Acum puteți alege să activați cei consistent citește off.
În cazul în care pe care am de gând să spun, Voi citi doar la un nod.
Și nu pot garanta că va să fie date mai recente.
>> Deci, dacă o scriere vine în, acesta nu a replicat încă,
ai de gând pentru a obține că copie.
Asta e un citire în cele din urmă consistentă.
Și ce este este jumătate din costul.
Deci acest lucru este ceva să mă gândesc.
Când sunteți citire DynamoDB, și te configurarea capacitatea de citire
de unități, dacă alegeți în cele din urmă consistent citește, este mult mai ieftin,
este vorba despre jumătate din costul.
>> Și așa vă economisește bani.
Dar asta e alegerea ta.
Dacă doriți o citire consistent sau o citire în cele din urmă consistentă.
Asta e ceva pe care le puteți alege.
>> Să vorbim despre indici.
Așa că am menționat că agregare de nivel superior.
Avem chei hash, și avem chei gama.
Este frumos.
Și asta e pe masă primar, am Trebuie o cheie hash, am primit o cheie gama.
>> Ce inseamna?
Am un atribut pe care am poate rula interogări bogate împotriva.
Este cheia gama.
Celelalte atribute pe care item-- Pot filtra pe acele atribute.
Dar eu nu pot face lucruri cum ar fi, ea începe cu, sau este mai mare decât.
>> Cum să fac asta?
Am crea un index.
Există două tipuri de indici în DynamoDB.
Un index este într-adevăr o altă vedere a mesei.
Și indicele secundar locală.
>> Primul vom vorbi despre.
Secundare Deci locale sunt coexistat pe aceeași partiție de date.
Și ca atare, ele sunt pe același nod fizic.
Ele sunt ceea ce noi numim consistent.
Înțeles, ei vor recunoaște write împreună cu tabelul.
În cazul în care scrie vine, vom scrie prin indicele.
Vom scrie până la masa, și atunci vom recunoaște.
Deci asta e consistent.
Odată ce a fost write a recunoscut de la masă,
este garantat că index secundar locală
va avea aceeași viziune de date.
Dar ceea ce vă permite să faceți este să defini cheile gama alternative.
>> Trebuie să utilizeze același hash cheie ca masa principala,
deoarece acestea sunt co-situat pe aceeași partiție, și sunt coerente.
Dar pot crea un index cu diferite chei gama.
Deci, de exemplu, în cazul în care am avut un producător care a avut o masă piese crud vine.
Și piese de prime provin din, și acestea sunt agregate de asamblare.
Și poate e un rechemare.
>> Orice parte care a fost făcută de către aceasta Producator după această dată,
Am nevoie pentru a trage de la linia mea.
Pot roti un index care ar fi în căutarea,
agregarea la data de Fabricarea de partea particular.
Deci, dacă masa mea nivel de top a fost deja distribuit de către producătorul,
Poate a fost amenajat pe partea de identitate, am poate crea un index la tabel
cum distribuit de către producător și a variat de la data fabricației.
Și așa am putea spune, ceva care a fost fabricat intre aceste date,
Am nevoie pentru a trage de la linia.
Așa că e un index secundar local.
>> Acestea au ca efect limitarea spațiu hash cheie.
Pentru că ei co-existat pe același nod de depozitare,
limitează tasta Diez spațiu pentru a 10 gigabytes.
DynamoDB, sub tabele, va partiție
masa ta la fiecare 10 GB.
Când ai pus 10 de concerte de date în, am du-te [PHH], și vom adăuga un alt nod.
>> Nu vom împărți LSI peste partiții multiple.
Vom împărți masa.
Dar nu vom împărți LSI.
Deci asta e ceva important să se înțeleagă
este dacă faci foarte, foarte, foarte mari aglomerări,
atunci ai de gând să fie limitată la 10 gigabytes pe chipuri LSI ta.
>> Dacă e cazul, putem utilizați secundare la nivel mondial.
Secundare globale sunt într-adevăr un alt tabel.
Ele există complet de pe la partea de masa dumneavoastră primar.
Și-au permiteți-mi să găsească un complet diferit structura.
Deci, cred că de ea ca este introdus date în două tabele diferite, structurate
în două moduri diferite.
>> Pot defini o cu totul diferit tasta Diez.
Pot defini o cu totul cheie gamă diferită.
Și eu pot rula acest complet independent.
Ca o chestiune de fapt, m-am prevazut calitatea mea de citire
și scrie capacitate pentru meu indici secundari globale
complet independent de masa mea primară.
Dacă aș defini ca index, spun ea cât de mult a scrie și a citi
Capacitate se va folosi.
>> Și care este separată de la masa mea primară.
Acum atât indicilor ne permite să defini nu numai chei hash și o gamă,
dar ne permit să proiecta valorile suplimentare.
Deci, dacă vreau să citesc de pe index, și vreau să obține unele set de date,
Nu am nevoie să mă întorc la principalele tabel pentru a obține atribute suplimentare.
Pot proiect cele suplimentare atribute în tabelul
pentru a sprijini modelul de accesare.
Știu că suntem probabil asistent, în unele într-adevăr, really-- intra buruienile
aici, pe unele dintre aceste lucruri.
Acum am ajuns la deriva din aceasta.
>> Audiența: [inaudibil] cheie --table însemnat a fost un hash?
Hash originală?
Multi-lamele?
>> RICK Houlihan: Da.
Da.
Cheia de masă practic punctele înapoi la elementul.
Deci un index este un pointer înapoi la articolele originale de pe masă.
Acum puteți alege pentru a construi o index care are doar cheia de masă,
și nici alte proprietăți.
Și de ce s-ar putea să fac asta?
Ei bine, poate am un produs foarte mari.
>> Am într-adevăr nevoie doar să știu which-- modelul meu de acces s-ar putea spune,
care conțin elemente această proprietate?
Nu au nevoie să se întoarcă elementul.
Vreau doar să știu care elemente se conțin.
Astfel încât să puteți construi indici care au doar cheia de masă.
>> Dar asta e în primul rând ceea ce un index in baza de date este pentru.
Este pentru a fi în măsură să rapid să identifice care înregistrează,
care rânduri, care elemente din tabelul au
proprietățile pe care am căutați.
>> GSIS, așa cum funcționează?
GSIS practic sunt asincrone.
Actualizarea vine în tabel, tabel este apoi actualizată asincron
toate GSIS dumneavoastră.
Acesta este motivul pentru GSIS sunt în cele din urmă consistent.
>> Este important să rețineți că atunci când sunteți construirea GSIS,
și ați înțeles ce crearea o altă dimensiune a aggregation--
acum sa spunem un exemplu bun aici este un producător.
Cred că s-ar fi vorbit despre un producător de dispozitiv medical.
Producatorii de dispozitive medicale au deseori părți serializate.
Piesele care merg în o înlocuire a șoldului toate
au un pic de număr de serie pe ele.
Și ar putea avea milioane de oameni și milioane și miliarde de piese
în toate dispozitivele pe care le transferă.
Ei bine, ei au nevoie pentru a agrega în diferite dimensiuni, toate părțile
într-un ansamblu, toate Piese care au fost făcute
pe o anumită linie, toate piesele care au venit
de un anumit producător la o anumită dată.
Și aceste agregări uneori obține până în miliarde.
>> Așa că am de lucru cu unele dintre tipii ăștia care suferă
pentru că sunt crearea aceste agregate ginormous
în indexurile lor secundare.
Ei ar putea avea un piese brute tabel care vine ca doar hash.
Fiecare parte are un număr de serie unic.
Eu folosesc numărul de serie ca hash.
E frumos.
Masa mea de date brute se răspândește peste tot în spațiul cheie.
Mele [? a scrie ?] [? ingestie?] este minunat.
Iau o mulțime de date.
Atunci ceea ce fac ei este că a crea un GSI.
Și să spun, știi ce, am nevoie pentru a vedea toate piesele pentru acest producător.
Ei bine, dintr-o dată că sunt luând un miliard de rânduri,
și le-a chestii pe un nod, pentru că atunci când
Am agregate ca ID-ul producător ca hash,
și numărul de o parte ca gama, apoi dintr-o dată că sunt
punând un miliard de piese în ceea ce acest producător mi-a dat.
>> Care poate provoca o mulțime de presiune asupra GSI,
din nou, pentru că eu sunt percuție un nod.
Pun toate acestea introduce într-un singur nod.
Și că este un adevărat caz de utilizare problematic.
Acum, am un design bun model pentru modul în care evita ca.
Și asta e una din problemele că întotdeauna lucrez cu.
Dar ce se întâmplă, este GSI ar putea să nu aibă capacitatea de a scrie suficientă
să fie capabil să împingă pe toți cei rânduri într-un singur nod.
Și ce se întâmplă atunci este primar, tabelul client,
tabelul primar va fi sugrumat pentru că GSI nu poate ține pasul.
Deci, rata mea de inserție va cad pe masă primar
ca GSI mea încearcă să țină pasul.
>> Bine, deci a GSI, lui LSI, care unul ar trebui sa folosesc?
Lui LSI sunt coerente.
Lui GSI sunt în cele din urmă coerente.
Dacă e OK, am recomandăm să utilizați un GSI, sunt mult mai flexibile.
Lui LSI poate fi modelat ca un GSI.
Și dacă dimensiunea datelor pe chei hash în Colecția depășește 10 gigaocteți,
atunci ai de gând să doriți să utilizați că GSI pentru ca este doar o limită de greu.
>> Bine, așa scalare.
Tranzitată în Dynamo DB, tu dispoziție poate [Inaudibil]
throughput la o masă.
Avem clienti care au prevazute 60 billion--
fac 60 de miliarde de cereri, în mod regulat rulează la peste un milion de cereri
pe secundă la mesele noastre.
Nu e într-adevăr nici limită teoretică la cât de mult
și cât de repede la masa poate rula in Dynamo DB.
Există unele moi limite în contul dvs.
că am pus acolo, astfel care nu te duci nebun.
Dacă doriți mai mult că, nu o problemă.
Ai venit să ne spuneți.
Vom întoarce cadran.
>> Fiecare cont este limitată la un anumit nivel în fiecare serviciu, chiar de la început
astfel încât oamenii nu merg nebun se ajunge în necazuri.
Nici o limită în mărime.
Puteți pune orice număr de elemente de pe o masă.
Dimensiunea unui element este limitate la 400 kilobiți fiecare,
care ar fi nu element atributele.
Deci suma tuturor atributelor se limitează la 400 kilobytes.
Și apoi din nou, ne-am că puțin problemă LSI
cu limita de 10 gigabyte pe hash.
Audiența: numărul mic, mi-e dor ceea ce-mi spui, că este--
Audiența: Oh, 400 kilobyte este dimensiunea maximă pentru fiecare element.
Deci, un element are toate atributele.
Deci 400 k este mărimea totală de acel element, 400 kilobytes.
Deci din toate atributele combinate, toate datele
care este în toate aceste atribute, rulată într-o dimensiune totală,
în prezent astăzi limita produs este de 400 k.
Deci scalarea din nou, realizat prin partiționare.
De transfer este prevazuta la nivelul masă.
Și există într-adevăr două butoane.
Am citit capacitate și scrie capacitate.
>> Deci, acestea sunt ajustate independent unul de celălalt.
Măsură RCU lui strict citește consistent.
OK, deci, dacă vrei să spui vreau 1000 Lui RCU acestea sunt strict coerente,
acestea sunt coerente citește.
Dacă spui vreau eventual consistent citește,
puteți dispoziție 1.000 Lui RCU, te duci
pentru a obține în cele din urmă 2.000 consistent citește.
Și la jumătate de preț pentru cei în cele din urmă constau citește.
>> Din nou, ajustat independent unul de celălalt.
Și ei au throughput-- Dacă ați consuma 100% din RCU dumneavoastră,
nu vei a impactului Disponibilitatea drepturile.
Astfel încât acestea sunt complet independente una de cealaltă.
Bine, deci unul din lucrurile pe care Am menționat pe scurt a fost throttling.
Laminare este rău.
Restricție indică rău nu SQL.
Există lucruri pe care le putem face pentru a ajuta la ai atenua throttling care
se confruntă.
Dar cea mai bună soluție la acest lucru este să luăm
o privire la ceea ce faci, pentru că există un anti-model în joc aici.
>> Aceste lucruri, lucruri cum ar fi non-uniform volumul de lucru, taste, paravane încinse.
Am lovit un anumit spațiu cheie foarte greu pentru un motiv special.
De ce fac asta?
Să dai seama.
Sunt de amestecare datele mele calde cu datele reci.
Mă lăsa tabele mele Ia uriaș, dar există într-adevăr
doar unele subset al datelor care este foarte interesant pentru mine.
Deci, pentru a datelor jurnal, de exemplu, o mulțime de clienții, ei a lua jurnal de date în fiecare zi.
Au o mare cantitate de date jurnal.
>> Dacă sunteți doar dumping toate jurnal date într-un singur tabel mare, în timp
acest tabel va obține masive.
Dar eu sunt foarte interesat doar de ultimele 24 de ore, ultimele șapte zile,
ultimele 30 de zile.
Oricare ar fi fereastra de timp că eu sunt interesat de căutarea
pentru cazul în care mă deranjează, sau cazul în care este interesant pentru mine,
că este fereastra singura dată când am nevoie.
Deci, de ce sunt eu de 10 de ani a pune în valoare de date jurnal din tabel?
Ce cauzeaza este că tabelul fragmentul.
>> Ea devine imens.
Se începe întindere peste mii de noduri.
Si din moment ce capacitatea de este atât de scăzut, esti
rata de fapt, limitarea pe fiecare unul dintre aceste noduri individuale.
Așa că haideți să începem uita la cum avem rola acea masă de peste.
Cum reușim un pic ca datele mai bine pentru a evita aceste probleme.
Și ce care arata ca?
Aceasta este ceea ce pare ca la fel ca.
Aceasta este ceea ce pare rău NoSQL ca.
>> Am o cheie fierbinte aici.
Dacă te uiți în partea de aici, acestea sunt toate partițiile mele.
M-am 16 partiții aici pe această bază de date special.
Facem acest lucru tot timpul.
Eu conduc acest lucru pentru clienții toate timpurile.
Se numește harta de căldură.
Harta de căldură mi-a spus cum te accesarea spațiu cheie.
Și ce-mi spune acest lucru este este că există un anumit hash
că tipul ăsta îi place un foarte mult, pentru că el este
lovind într-adevăr, foarte greu.
>> Deci albastru este frumos.
Ne place albastru.
Noi nu le place roșu.
Roșu, unde presiunea ajunge până la 100%.
100%, acum vei fi sugrumat.
Deci de fiecare dată când vedeți linii roșii, cum ar fi astea-- și nu e doar Dynamo DB--
fiecare bază de date NoSQL are această problemă.
Există anti-modele care pot conduce aceste tipuri de condiții.
Ceea ce fac este lucrez cu clienții pentru a atenua aceste condiții.
>> Și ce care arata ca?
Și acest lucru este obtinerea cele mai multe din transfer Dynamo DB,
dar este foarte asistent mai mult de NoSQL.
Acest lucru nu se limitează la Dynamo.
Acest lucru este I definitely-- a lucrat la Mongo.
Sunt familiarizat cu mai multe platforme NoSQL.
Fiecare are aceste tipuri de probleme fierbinți cheie.
Pentru a obține cele mai multe din orice NoSQL baze de date, în special Dynamo DB,
doriți să creați tabelele în cazul în care elementul cheie hash are
un număr mare de valori distincte, un grad ridicat de cardinalitatea.
Pentru că înseamnă că scriu la o mulțime de diferite cupe.
>> Mai multe găleți Sunt scris, cu atât mai probabil
Sunt de a răspândi ca sarcină de scriere sau citeste load out pe mai multe noduri,
cu atât mai probabil sunt de a avea o capacitate mare de pe masă.
Și apoi vreau valorile să fie solicitat destul de uniform în timp
și mai uniform aleator posibil.
Ei bine, asta e un fel de interesant, pentru că nu poate într-adevăr
control, atunci când utilizatorii vin.
Deci, suficient să spun, dacă am răspândit lucrurile din spațiul cheie,
vom fi, probabil, într-o formă mai bună.
>> Există un anumit cantitate de timp de livrare
că nu te duci să fie de control putea.
Dar acestea sunt într-adevăr două dimensiuni pe care le avem,
spațiu, acces egal răspândit, timp, cererile
sosesc distanțate uniform în timp.
Și dacă cei doi condiții sunt îndeplinite,
atunci asta e ceea ce e O să arate.
Acest lucru este mult mai frumos.
Suntem foarte fericit aici.
Avem un model de acces foarte chiar.
Da, poate vei primi un pic de presiune fiecare acum și apoi,
dar nimic nu într-adevăr prea extinse.
Deci, este uimitor cât de multe ori, când lucrez cu clienți,
că primul grafic cu roșu mare bar și tot ce urât e galben
peste tot, am se face cu exercitarea
după câteva luni de re-arhitectura,
ei rulează exact același lucru volumul de muncă la aceeași sarcină exact.
Și aceasta este ceea ce se arata ca acum.
Deci, ceea ce veți obține cu NoSQL este un schema de date, care este absolut
legat de modelul de accesare.
>> Și puteți optimiza că schema de date pentru a sprijini acel model de acces.
Dacă nu, atunci te duci pentru a vedea aceste tipuri de probleme
cu aceste taste.
>> Audiența: Ei bine, inevitabil unele locuri vor fi mai fierbinte decât altele.
>> RICK Houlihan: Întotdeauna.
Mereu.
Da, vreau să spun că întotdeauna un-- și, din nou, nu e
unele modele de design vom trece prin care va vorbi despre modul în care te descurci
cu aceste agregări super-mari.
Adică, am să le aibă, cum avem de a face cu ei?
Am un caz de utilizare destul de bine că vom vorbi despre asta.
>> Bine, așa că hai să vorbim despre unii clienți acum.
Tipii ăștia sunt AdRoll.
Nu știu dacă ești familiar cu AdRoll.
Tu, probabil, le vezi mult pe browser-ul.
Sunt ad re-direcționarea, sunt cea mai mare afacere ad re-orientare
acolo.
În mod normal, ei rula în mod regulat peste 60 miliarde de tranzactii pe zi.
Ei fac de peste un milion tranzacții pe secundă.
Au o masă destul de simplu structură, cele mai aglomerate masa.
Este practic doar un cheie hash este cookie,
gama este demografice categorie, și apoi
al treilea atribut este scorul.
>> Deci, noi toți avem cookie-urile în Browser-ul nostru de la tipii ăștia.
Și când te duci la un comerciant participante,
ei practic tine scorul peste diferite categorii demografice.
Când te duci la un site web și ai spus Vreau să văd acest ad--
sau practic nu spui that-- dar atunci când te duci la site-ul web
ei spun doriți să vedeți acest anunț.
Și ei du-te că anunțul de AdRoll.
AdRoll te uită pe masa lor.
Ei au găsit cookie-ul.
Agenții de publicitate spun le, vreau pe cineva
care e de varsta mijlocie, Bărbat de 40 de ani, în sport.
Și te-au înscrie în acele demografice și ei să decidă dacă este sau nu
asta e un anunț bun pentru tine.
>> Acum, ei au un SLA cu furnizorii de publicitate
pentru a oferi sub-10 milisecunde răspuns la fiecare cerere.
Deci ei folosesc Dinamo DB pentru acest lucru.
Ne-o lovind milioane de cereri pe secundă.
Sunt în stare să facă toate lor căutări, triaj toate aceste date,
și obține Adauga link-ul înapoi la faptul că publicitate în conformitate cu 10 milisecunde.
E într-adevăr destul fenomenal de punere în aplicare pe care le au.
>> Tipii ăștia actually-- sunt acestea băieții.
Nu sunt sigur dacă e tipii ăștia.
S-ar putea să fie tipii ăștia.
Practic us-- spus nu, Nu cred că le era.
Cred că a fost altcineva.
Am fost de lucru cu un client care mi-a spus
că acum că le-am plecat la Dinamo DB, sunt
cheltui mai mulți bani pe snacks-uri pentru echipa lor de dezvoltare în fiecare lună
decât cheltui pe baza lor de date.
Deci, să-ți dau o idee economiile de costuri
pe care le puteți obține de la Dynamo DB este imens.
Bine, dropcam e altă companie.
Aceste tip cam de--, dacă credeți de internet de lucruri, dropcam
este, în principiu Internet Video de securitate.
Ai pus aparatul de fotografiat acolo.
Camera are un senzor de mișcare.
Cineva vine, declanșează un punct de tac.
Camera începe înregistrarea pentru un timp până aceasta nu mai detecta orice mișcare.
Pune că videoclipul pe internet.
>> Dropcam fost o companie care este practic a trecut la Dinamo DB
deoarece acestea au fost confrunta cu dureri de crestere enorme.
Și ce ne-au spus, brusc petabytes de date.
Ei au avut nici o idee serviciul lor ar fi atât de succes.
Mai mult de pe YouTube videoclipuri de intrare este ceea ce tipii ăștia sunt de asistent.
Ei folosesc DynamoDB pentru a urmări toate metadate cu privire la toate punctele lor cheie video.
>> Deci, ei au S3 găleți ei împinge toate artefactele binare în.
Și apoi le-au Înregistrările dinam DB care
punctul de oameni la aceste S3 trei obiecte.
Atunci când au nevoie să se uite la un film, se uita în sus înregistrarea în Dynamo DB.
Ei faceți clic pe link.
Ei trage în jos video de la S3.
Deci, asta e un fel de ceea ce arata ca aceasta.
Și acest lucru este direct de la echipa lor.
>> Dynamo DB reduce lor Termenul de livrare pentru evenimente video,
de la cinci la 10 secunde.
In magazinul lor vechi relațional, au folosit pentru a trebuie să meargă și să execute
mai multe interogări complexe pentru a descoperi din care videoclipuri a trage în jos,
la mai puțin de 50 milisecunde.
Deci e uimitor, uimitor cât de mult de performanță
puteți obține atunci când vă optimizați și vă ton de date care stau la baza
pentru a sprijini modelul de accesare.
Halfbrick, tipii ăștia, ce este, Fruit Ninja Cred este un lucru lor.
Că toate ruleaza pe Dynamo DB.
Și tipii ăștia, ele sunt o mare echipa de dezvoltare, mare dezvoltare
magazin.
>> Nu este o echipă bună op.
Ei nu au avut o mulțime resurselor de operare.
Ei au fost lupta încearcă să mențină infrastructura aplicare până
și să fie difuzate.
Ei au venit la noi.
Ei se uita la acel Dinamo DB.
Ei au spus, asta e pentru noi.
Au construit întregul lor cadru de aplicare pe ea.
Unele comentarii foarte frumos aici de la echipa de pe capacitatea lor
să se concentreze acum pe construirea jocul și nu
având Pentru a menține infrastructură, care
a devenit o cantitate enormă de deasupra pentru echipa lor.
Deci acest lucru este ceva that-- beneficiul pe care le primesc de la Dinamo DB.
>> Bine, intrând în modelarea datelor aici.
Și am vorbit un pic despre aceasta la unu, unu la multe,
și mulți să multe relatii de tip.
Și cum a face tu menține cele din Dynamo.
În Dynamo DB folosim indici, în general vorbind,
pentru a roti datele din unul aromă la alta.
Chei hash, chei gama, și indexurile.
>> În acest special exemplu, ca cele mai multe state
au o cerință de acordare a licențelor care doar permis o conducere per persoană.
Nu puteți merge pentru a obține șofer două lui licențe în stare de Boston.
Nu pot face acest lucru în Texas.
Asta e un fel de modul în care aceasta este.
Și astfel, la DMV, avem căutări, am doriți să căutați permisul de conducere
de numărul de securitate socială.
Vreau să te uiți în sus detaliile de utilizator în funcție de numărul permisul de conducere.
>> Deci, am putea avea masa de un utilizator care are o cheie hash cu privire la numărul de serie,
sau numărul de securitate socială, și diverse atribute definite pe element.
Acum, pe masa am ar putea defini un GSI care
flips că în jurul valorii de care spune vreau o cheie hash pe licență și apoi
toate celelalte elemente.
Acum, dacă vreau să interogare și de a găsi Numărul de licență pentru un anumit Social
Numărul de securitate, nu pot interogare tabelul principal.
>> Dacă vreau să interogare și vreau pentru a obține de securitate socială
numărul sau alte atribute de către un Numărul de licență, pot interoga GSI.
Acest model este faptul că unul la unul relație.
Doar un foarte simplu GSI, răsturna aceste lucruri în jurul valorii de.
Acum, vorbesc despre o la mai multe.
Unul pentru mulți este, în principiu cheia gama hash.
În cazul în care vom obține o mulțime cu acest caz de utilizare este de date de monitorizare.
Date monitor vine în mod regulat interval, cum ar fi internet de lucruri.
Noi întotdeauna obține toate acestea înregistrările venind tot timpul.
>> Și vreau să găsească toate citirile între o anumită perioadă de timp.
Este o interogare foarte frecvente în infrastructură de monitorizare.
Modul merge despre care este de a găsi o structură de tabel simplu, un tabel.
Am un tabel măsurători dispozitiv cu o cheie hash pe ID-ul dispozitivului.
Și am o cheie gamă privire la timestamp, sau în acest caz, epic.
Și care-mi permite să execute complex interogări împotriva cheia gamă
și să se întoarcă acele înregistrări care sunt raportate la rezultatul
set care caut.
Și se construiește care o de foarte multe relații
în tabelul primar folosind tasta Diez, structura cheie gama.
>> Deci, asta e un fel de construit în tabelul de la Dynamo DB.
Când m-am defini un hash și o gamă T masă, eu sunt
definirea unei una la mai multe relații.
Este o relație părinte-copil.
>> Hai sa vorbim despre multe la multe relatii.
Și pentru acest exemplu particular, din nou, vom pentru a utiliza lui GSI.
Și să vorbim despre jocuri de noroc scenariu în cazul în care am avea o anumită utilizator.
Vreau să aflu toate jocurile care el a înregistrat pentru sau juca în.
Și pentru un anumit joc, am doriți să găsiți toți utilizatorii.
Deci, cum fac asta?
My masă jocuri de utilizator, am de gând pentru a avea o cheie hash de ID utilizator
și o cheie gamă de joc.
>> Deci, un utilizator poate avea mai multe jocuri.
Este unul la multe relație între utilizator și jocurile el joacă.
Și apoi pe GSI, Voi întoarceți că în jurul valorii.
Voi hash pe joc și Voi gama asupra utilizatorului.
Deci, dacă vreau pentru a obține toate joc utilizatorului joacă în,
Voi interogare tabelul principal.
Dacă vreau să obțineți tuturor utilizatorilor care joacă un anumit joc,
Am interogare GSI.
Deci, vedeți cum facem acest lucru?
Vă construi aceste GSI a sprijini caz de utilizare, cererea, accesul
model, aplicația.
>> Dacă am nevoie pentru a interoga pe această dimensiune, să
mi crea un index pe acea dimensiune.
Dacă nu o fac, nu-mi pasă.
Și în funcție de caz de utilizare, am ar putea avea nevoie indexul sau nu s-ar putea.
Dacă e unul simplu pentru multi, tabelul primar este bine.
Dacă am nevoie pentru a face aceste mulți să multe lui sau am nevoie pentru a face o la cele,
atunci poate am nevoie a doua index.
Deci, totul depinde de ceea ce am încercat să fac
și ceea ce am încercarea de a obține realizat.
>> Probabil ca nu am de gând să-și petreacă prea mult vorbesc despre documentele timp.
Acest lucru devine un pic, probabil, mai profund decât avem nevoie pentru a merge în.
Hai sa vorbim un pic expresie de interogare despre bogat.
Deci, în Dynamo DB avem abilitatea de a crea
ceea ce noi numim expresii de proiecție.
Expresii de proiecție sunt pur și simplu cules câmpurile sau valorile
pe care doriți să o afișați.
OK, asa ca am face o selecție.
Eu fac o interogare împotriva Dinamo DB.
Și să spun, știi ce, spectacol mi numai cinci stele comentarii
pentru acest produs special.
Deci, asta e tot ce vreau să văd.
Nu vreau să Vezi toate alte atribute ale rândul,
Vreau doar să văd asta.
E la fel ca în SQL, atunci când spune selectați stele sau de la masă,
ai totul.
Când spun selectați numele din masă, am doar un singur atribut.
Este același tip de lucru în Dynamo DB sau alte baze de date NoSQL.
Expresii de filtrare mă lasă să tăiat practic rezultatul stabilit.
Așa că am face o interogare.
Interogare poate reveni cu 500 de articole.
Dar vreau doar elementele pe care au un atribut care spune acest lucru.
OK, deci haideți să filtreze aceste elemente care nu se potrivesc că interogarea special.
Deci avem expresii de filtrare.
>> Expresii filtru poate fi rulat pe orice atribut.
Ei nu sunt ca interogări gama.
Ridicați interogări sunt mai selective.
Interogări de filtrare mi cere să merg obține întreaga rezultatele stabilite și apoi
sculpta datele nu vreau.
De ce este așa de important?
Pentru că l-am citit toate.
Într-o interogare, am de gând să citească și să se va fi un gigant cu privire la date.
Și apoi am de gând să sculpta ceea ce am nevoie.
Și dacă am doar sculptură o câteva rânduri, atunci e OK.
Nu este atât de ineficient.
>> Dar dacă am citit o grămadă de date, doar pentru a sculpta un articol,
apoi m-am de gând să fie mai bine folosind o interogare domeniu,
pentru că este mult mai selectiv.
O să-mi salva o mulțime de bani, pentru că am plăti pentru asta citire.
În cazul în care rezultatele pe care se întoarce cruce ca sârmă ar putea fi mai mici,
dar eu sunt de plata pentru citit.
Deci, înțeleg cum vei primi datele.
Asta e foarte important în Dynamo DB.
>> Expresiilor condiționale, aceasta este ceea ce ai putea numi blocare optimistă.
Actualizare dacă există, sau în cazul în care această valoare este echivalent cu ceea ce am specifica.
Și dacă am o ștampilă de timp pe un înregistrare, s-ar putea citi datele.
S-ar putea schimba aceste date.
S-ar putea merge scrie că date înapoi la baza de date.
Dacă cineva a schimbat înregistrarea, amprenta de timp s-ar putea s-au schimbat.
Și în acest fel condiționată meu update putea spune actualizare
în cazul în care amprenta de timp este egal cu acest lucru.
Sau actualizarea va eșua, deoarece cineva actualizat înregistrarea între timp.
>> Asta e ceea ce noi numim de blocare optimistă.
Aceasta înseamnă că cineva poate veni în si schimba-l,
și am de gând să-l detecta atunci când mă întorc la a scrie.
Și apoi eu pot citi de fapt, că date și spune, oh, a schimbat acest lucru.
Am nevoie de a ține cont de acest lucru.
Și eu pot schimba datele din mea înregistra și se aplică un alt update.
Astfel încât să puteți prinde cele incrementale actualizări care apar între timp
că ai citit datele și timp s-ar putea scrie datele.
>> Audiența: și filtrul exprimare nu înseamnă de fapt
în numărul sau not--
>> [Interpunerea VOCI]
RICK Houlihan: nu voi a lua prea mult în asta.
Acesta este un cuvânt cheie rezervate.
Punctul de vedere este o lira rezervat cuvinte cheie în Dynamo DB.
Fiecare baza de date are propriul rezervate nume pentru colecții nu se poate folosi.
Dynamo DB, dacă specificați o lira în fața acestui fapt,
puteți defini aceste nume deasupra.
Aceasta este o valoare de referință.
Probabil nu este cel mai bun pentru a sintaxa au acolo pentru această discuție,
pentru că acesta devine în unele real-- Mi-ar fi vorbit mai mult
despre care, la un nivel mai profund.
>> Dar suficient să spun, acest lucru ar putea fi interogare scanare în cazul în care views--
nici vizionări lira este mai mare de 10.
Este o valoare numerică, da.
Dacă doriți, putem vorbi despre că, după discuția.
În regulă, așa că vei primi în unele scenarii din cele mai bune practici
în cazul în care vom vorbi despre unele aplicații aici.
Care sunt cazurile de utilizare pentru Dynamo DB.
Care sunt proiectarea modele în Dynamo DB.
>> Și primul vom vorbesc despre este internetul obiectelor.
Așa că am obține o mulțime de-- cred, ceea ce este it-- peste 50%
de trafic pe internet aceste zile este, de fapt generată de mașini,
procese automatizate, nu de oameni.
Adică acest lucru acest lucru purtați în jurul valorii în buzunar,
cât de mult date care acel lucru este de fapt, trimiterea în jurul fără tine
știind că este absolut uimitor.
Locația dvs., informatii despre cât de repede te duci.
Cum crezi că funcționează Google Maps când vă spun ceea ce este traficul.
Este pentru că există milioane de oameni și milioane de oameni în jurul valorii de conducere
cu telefoanele care trimit date peste tot loc tot timpul.
Deci, unul din lucrurile despre acest tip de date
care vine în, date de monitorizare, log date, datele seriilor de timp, este e
de obicei, doar interesant pentru un pic de timp.
După acest timp, e nu atât de interesant.
Așa că am vorbit despre, nu lasa aceste tabele creste fara limite.
Ideea este ca poate am 24 ore în valoare de evenimente din masa mea fierbinte.
Și acest tabel fierbinte va fi prevăzut, la o rată foarte mare,
pentru că este a lua o mulțime de date.
Este de a lua o mulțime de date și am citit foarte mult.
Am o mulțime de funcționare interogări care rulează împotriva date.
>> După 24 de ore, hei, tu Știi ce, nu-mi pasă.
Poate fiecare mă rostogolesc la miezul nopții masa mea pe la o masă nouă
și am deprovision acest tabel.
Și voi lua telecomandă și Jos pentru scaune cu rotile, deoarece 24 de ore mai târziu
Nu fug cât mai multe interogări împotriva că datele.
Deci, am de gând pentru a economisi bani.
Și poate de 30 de zile mai târziu, eu nu chiar trebuie să aibă grijă de toate.
Aș putea lua anii scaune cu rotile tot drumul până la un,
pentru că știi ce, e nu mergi la a lua scris.
Datele sunt vechi de 30 de zile.
Acesta nu se schimbă niciodată.
>> Și se aproape niciodată mergi la a lua citi, Să ia doar că RCU până la 10.
Iar eu de economisire o grămadă de bani pe acest date, și numai plata pentru datele mele fierbinte.
Deci, asta e cel mai important lucru pentru a căuta la atunci când te uiți la o serie cronologică
date venind în volum.
Acestea sunt strategii.
Acum, aș putea să-l pur și simplu toate merg la aceeași masă
și doar lăsa să se tabel să crească.
În cele din urmă, am de gând să vezi probleme de performanță.
Am de gând să trebuie să înceapă să arhiva unele dintre aceste date de pe masă,
fleacuri.
>> Să mult mai bine proiecta cererea dumneavoastră
astfel încât să poată funcționa în acest fel drept.
Deci e doar automat în codul de aplicare.
La miezul nopții în fiecare noapte se rostogolește masa.
Poate ceea ce am nevoie este o alunecare fereastră de 24 de ore de date.
Apoi, în mod regulat sunt de asteptare de date de pe masă.
Am o tundere cu un Cron de locuri de muncă și eu sunt o pune
pe aceste alte tabele, orice ai nevoie.
Deci, dacă un rollover funcționează, e minunat.
Dacă nu, o tăiați.
Dar să păstrați datele fierbinte departe de datele reci.
Acesta va salva o mulțime de bani și face mesele mai performant.
Deci următorul lucru vom vorbi despre este catalogul de produse.
Catalog produse este caz de utilizare destul de comun.
Aceasta este de fapt un model foarte frecvente că vom vedea într-o varietate de lucruri.
Știi, Twitter pentru exemplu, un tweet fierbinte.
Toată lumea vine și hapsân că tweet.
Catalog produse, am o vânzare.
Am o vânzare fierbinte.
Am 70.000 de cereri pe doua venire pentru un produs
Descrierea din catalog mea de produse.
Vedem acest lucru în retail operație destul de un pic.
Deci, cum avem de a face cu asta?
Nu există nici o modalitate de a face cu asta.
Toți utilizatorii mei doresc să vadă aceeași bucată de date.
Ei vin în, concomitent.
Și acestea sunt de luare toate cererile pentru aceeași bucată de date.
Acest lucru îmi dă cheia cald, că roșu mare dungă pe graficul meu pe care nu le place.
Și asta e ceea ce pare ca la fel ca.
Deci, peste spatiul meu cheie Primesc ciocanul în elementele de vânzare.
Primesc nimic în altă parte.
>> Cum pot atenua această problemă?
Ei bine, am atenua acest lucru cu cache.
Cache, ai pus practic un in-memory partiție în fața bazei de date.
Am reușit [Auzite] cache, ce
poate configura propriul cache, [neauzit] cache [? d,?] ce vrei.
Pune în fața bazei de date.
Și în acest fel se pot stoca aceste date din aceste taste în care cache
spațiu și citit prin cache-ul.
>> Și apoi de cele mai multe dvs. citește începe aratand ca aceasta.
M-am toate aceste cache hit-uri aici și m-am nimic întâmplă aici
deoarece baza de date este ședinței în spatele cache și nu citește vin prin.
Dacă aș schimba datele din baze de date, trebuie să actualizați cache-ul.
Putem folosi ceva ca aburi pentru a face asta.
Și voi explica cum funcționează.
Bine, mesaje.
E-mail, vom folosi toate e-mail.
>> Acesta este un exemplu destul de bun.
Avem un fel de masă mesaje.
Și ne-am Inbox și Outbox.
Aceasta este ceea ce ar fi SQL arata ca pentru a construi acea inbox.
Noi tip de utilizare de același tip strategiei de a utiliza lui GSI, a GSI
pentru cutia mea poștală și Outbox mea.
Așa că am primit mesajele prime provenind în masa mea mesaje.
Și prima abordare a acestei ar putea fi, spune, OK, nici o problema.
Am primit mesajele prime.
Mesaje provenind [Inaudibil], mesaj ID, e minunat.
Asta e hash meu unic.
Am de gând să creeze două de GSI, o pentru cutia mea poștală, una pentru Outbox mea.
Și primul lucru pe care voi face este Voi spune cheia mea hash este
O să fie beneficiarul și Am de gând pentru a aranja la data.
Acest lucru este fantastic.
Am punctul meu de vedere frumoasă aici.
Dar nu e un pic problemă aici.
Și aveți o acest lucru în baze de date relationale, de asemenea.
Ei au numit partiționare verticală.
Doriți să vă păstrați datele dvs. de mare departe de datele micile tale.
>> Și motivul pentru care se datorează faptului că trebuie să- du-te citește elementele pentru a obține atributele.
Și dacă organismele mele sunt toate pe aici, apoi citit doar câteva articole
dacă lungimea corpului meu este o medie de 256 kiloocteți fiecare,
matematica devine destul de urât.
Deci, spun vreau să citesc inbox lui David.
Inbox lui David are 50 de elemente.
Media și dimensiunea este de 256 kilobytes.
Iată raportul meu de conversie pentru a RCU este de patru kilobytes.
>> OK, să mergem cu în cele din urmă consistent citește.
Sunt încă mănâncă 1600 RCU lui doar pentru a citi inbox lui David.
Vai.
OK, acum sa ne gandim despre modul în care funcționează aplicația.
Dacă sunt într-o aplicație de e-mail și Mă uit la cutia mea poștală,
și mă uit la corpul de fiecare mesaj, Nu, mă uit la rezumatele.
Mă uit la numai anteturile.
Deci, haideți să construim o structură de tabel care arata mai mult ca asta.
>> Deci, aici e informația care flux de lucru meu are nevoie de.
E în cutia mea poștală GSI.
Este data, expeditorul, subiectul, iar apoi
ID-ul mesajului, ceea ce indică înapoi la masa de mesaje
în cazul în care pot obține corpul.
Ei bine, acestea ar fi ID-uri de înregistrare.
Ei ar dori înapoi la ID-uri articol de pe masa de Dynamo DB.
Fiecare index creates-- întotdeauna are întotdeauna elementul
ID ca parte de-- care vine cu indicele.
>> In regula.
Audiența: îl spune în cazul în care este stocat?
RICK Houlihan: Da, se spune exactly-- exact ceea ce face.
Se spune aici e recordul meu re.
Și-l voi laturi Inapoi la dosarul meu re.
Exact.
OK, asa ca acum inbox mea este de fapt mult mai mic.
Și acest fapt susține fluxul de lucru de o aplicație de e-mail.
Deci cutia mea poștală, am faceți clic.
Mă duc de-a lungul și dau click pe mesaj, că, atunci când am nevoie pentru a du-te corpul,
pentru că am de gând să du-te la un punct de vedere diferit.
Deci, dacă te gândești tip MVC de cadru, vedere modelul controler.
>> Modelul conține date care vezi nevoile
și controlerul interacționează cu.
Când m-am schimba cadrul, atunci când Am schimba perspectiva,
este OK pentru a reveni la Server și repopula model,
pentru că asta e ceea ce așteaptă utilizatorul.
Când se schimbă puncte de vedere, atunci ne putem întoarce la baza de date.
Deci e-mail, faceți clic pe.
Caut pentru organism.
Dus-întors.
Du-te corpul.
>> Am citit o mulțime mai puține date.
Eu doar citesc organismele care David are nevoie de când are nevoie de ele.
Și nu mă ard în 1600 De RCU doar pentru a arăta inbox lui.
Deci, acum that-- aceasta este calea că LSI sau GSI-- Îmi pare rău,
GSI, ar lucra.
Avem hash nostru beneficiarului.
Avem cheia gama la data.
Și avem atributele proiectate că avem nevoie doar de a sprijini punctul de vedere.
>> Am roti că pentru outbox.
Hash pe expeditor.
Și în esență, avem foarte frumos de vedere, curat.
Și este ne basically-- Au acest mesaje frumoase
Tabelul care fiind răspândit frumos deoarece e hash numai, ID mesaj distribuit.
Și avem doi indici care se rotesc pe a tabelului.
Bine, asa ca idee aici este nu păstra datele mari si asta mic
împreună.
Partiție pe verticală, partiție aceste tabele.
Nu citesc date nu trebuie să.
Bine, jocuri.
Tuturor ne place jocurile.
Cel puțin eu plac jocurile atunci.
Deci, unele dintre lucrurile că avem de a face cu, atunci când
ne gândim despre jocuri de noroc, nu?
Jocuri in aceste zile, mai ales mobil jocuri de noroc, este vorba de gândire.
Și am de gând să se rotească aici pic departe de DynamoDB.
Am de gând să aducă în o parte din discuția
în jurul unele dintre alte tehnologii AWS.
>> Dar ideea despre jocuri de noroc este de a gândi despre în termeni de API-uri, API-uri, care sunt,
în general vorbind, HTTP și JSON.
Este modul în care jocurile mobile fel de interacționa cu capetele lor înapoi.
Ei fac JSON postare.
Ei primesc date, și totul, în general vorbind, în API-uri JSON frumoase.
>> Lucruri cum ar fi a lua prietenii, pentru a primi datele clasament, de schimb,
utilizator conținutul generat, împinge înapoi până la sistem,
acestea sunt tipuri de lucruri că vom face.
Date activ binare, aceste date ar putea să nu stea în baza de date.
Acest lucru ar putea sta într-o magazin obiect, nu?
Dar baza de date este de gând să încheia spune sistemului,
spune cererea în cazul în care pentru a merge să-l.
Și în mod inevitabil, multiplayer servere, infrastructura end spate,
și concepute pentru înaltă disponibilitate și scalabilitate.
Deci, acestea sunt lucruri pe care noi toți doresc în infrastructura de jocuri de astăzi.
>> Deci, haideți să aruncăm o privire la ceea ce arata ca asta.
A primit un miez back end, foarte simplu.
Avem un sistem de aici cu mai multe zone de disponibilitate.
Am vorbit despre AZS ca being-- cred dintre ele ca centre de date separate.
Centru de date mai mult de un pe AZ, dar asta e OK,
gandeste-te de ele ca date separată centre care sunt punct de vedere geografic
și vina izolat.
>> Vom avea o cazuri cuplu EC2.
Vom avea un server back end.
Poate daca esti o moștenire arhitectura, suntem
folosind ceea ce numim RDS, Servicii de baze de date relaționale.
Ar putea fi MSSQL, MySQL, sau asa ceva.
Aceasta este modul în care o mulțime aplicații sunt proiectate astăzi.
>> Ei bine, am putea vrei să mergi cu acest lucru este atunci când ne scară afară.
Vom merge mai departe și a pus găleată S3 acolo.
Și că găleată S3, în loc de servire acele obiecte din servers-- nostru
am putea face asta.
Ai pus toate binar dvs. obiecte de pe serverele dvs.
și puteți folosi cele de server instanțe pentru a servi ca date de până.
Dar asta e destul de scump.
>> Modalitate mai bună de a face este merge mai departe și pune aceste obiecte într-o găleată S3.
S3 este un arhive obiect.
Este construit special pentru servind la aceste tipuri de lucruri.
Și să solicite acei clienți direct de la aceste cupe obiect,
scape serverele.
Deci suntem incepand de la scară aici.
>> Acum avem de utilizatori din întreaga lume.
Am utilizatori.
Am nevoie pentru a avea conținut local situat în apropiere de acești utilizatori, nu?
Am creat o găleată S3 ca depozit sursa mea.
Și voi față care cu distribuția CloudFront.
>> CloudFront este un CD și un Content Delivery Network.
Practic este nevoie de date pe care le specificați și tot cache pe internet
astfel încât utilizatorii de pretutindeni pot avea un răspuns foarte rapid, atunci când
ei solicită aceste obiecte.
>> Astfel încât să obțineți o idee.
Ești un fel de pârghie tot aspecte ale AWS aici pentru a obține făcut acest lucru.
Și, eventual,, ne arunca într-un grup de scalare automată.
Deci cazuri noastre AC2 de serverele noastre de joc,
deoarece acestea încep să se ocupată și mai plină și mai ocupat,
vor invarti doar un alt exemplu, de spin-un alt exemplu,
rotească un alt exemplu.
Deci tehnologia AWS are, ea permite să specificați parametrii
în jurul căreia serverele va crește.
Astfel încât să puteți avea număr n de servere acolo la un moment dat.
Și dacă sarcina dumneavoastră dispare, ei vor psihiatru, numărul se va micsora.
Și dacă sarcina se întoarce, o să crească înapoi, elastic.
>> Deci, aceasta arata grozav.
Avem o mulțime de cazuri EC2.
Putem pune în cache fata a bazelor de date,
încercați și să accelereze bazele de date.
Următorul punct de presiune de obicei oamenii se vedea
este un joc de ei scară folosind un sistem baze de date relaționale.
Doamne, baza de date performanța este teribil.
Cum putem îmbunătăți asta?
Să încercăm punerea cache în fața asta.
>> Ei bine, cache nu funcționează atât de mare în jocuri, nu?
Pentru jocuri, scrisul este dureros.
Jocurile sunt foarte grele scrie.
Cache nu funcționează atunci când sunteți scrie greu pentru că ai întotdeauna
Trebuie să actualizați cache-ul.
Vă actualizați cache-ul, e irelevante să fie cache.
Este de fapt doar o muncă suplimentară.
>> Deci, unde mergem de aici?
Ai un blocaj mare acolo în baza de date.
Și locul pentru a merge evident, este de partiționare.
Partiționarea nu este ușor să faci când ești
care se ocupă cu baze de date relaționale.
Cu baze de date relaționale, ești responsabilă pentru gestionarea, în mod eficient,
spațiul cheie.
Ești utilizatorii între A și M spune du-te aici, între N și Z acolo.
Și tu de comutare peste aplicația.
Deci ai de a face cu această sursă de date partiție.
Aveți constrângeri tranzacționale care nu acopera partiții.
Ai tot felul de messiness că ești
care se ocupă cu acolo încercând să se ocupe de scalare din
și construirea unei infrastructuri mai mare.
E doar nici un haz.
>> Audiența: Deci vrei să spui că creșterea puncte sursa accelerează
procesul?
RICK Houlihan: Creșterea?
Puncte Sursa: audienta.
RICK Houlihan: puncte Sursa?
Audiența: Din informațiile, în cazul în care informația vine de la?
RICK Houlihan: Nu.
Ce vreau să spun este creșterea Numărul de partiții în depozitul de date
îmbunătățește tranzitată.
Deci, ce se întâmplă aici este utilizatori vin în instanță EC2 aici,
Ei bine, dacă am nevoie de un utilizator care este de la A la M, voi merge aici.
De la N la p, voi merge aici.
De la P la A la Z, mă duc aici.
>> Audiența: OK, cei atât de acestea sunt toate stocate in diferite noduri?
>> RICK Houlihan: Da.
Gândiți-vă la cum ar fi diferite silozuri de date.
Deci a fi nevoie să facă acest lucru.
Dacă sunteți încercarea de a face acest lucru, dacă sunteți încercarea de
la scară pe o platformă relațională, acest lucru este ceea ce faci.
Iei date și te-l taie.
Și tu o partiționare peste mai multe instanțe ale bazei de date.
Și ești de gestionare toate la nivel de aplicare.
Nu e amuzant.
Deci, ceea ce vrem să mergem?
Vrem să mergem DynamoDB, complet gestionate, Magazin de date NoSQL, transfer dispoziție.
Noi folosim indici secundari.
Este practic HTTP API și include suport de documente.
Deci nu trebuie să vă faceți griji cu privire la orice de care partiționare.
Noi face totul pentru tine.
Deci, acum, în schimb, tu doar scrie la masa.
Dacă tabela trebuie să fie partiționat, ce se întâmplă în spatele scenei.
Ești complet izolate din care ca un dezvoltator.
Deci, haideți să vorbim despre unele cazuri de utilizare
că vom rula în în jocuri de noroc, comun scenarii de jocuri, clasament.
Deci ai de utilizatori vine, de BoardNames că sunt
pe, scorurile pentru acest utilizator.
S-ar putea să fie hashing pe UserID, și apoi ne-am gamă pe joc.
Astfel încât fiecare utilizator vrea să vadă tot jocul el a jucat
și toată scorul său top în toate joc.
Deci, asta e clasament personal.
>> Acum vreau să merg și eu vreau să get-- așa că am obține aceste clasamente personale.
Ceea ce vreau să faceți este să mergeți obține Scorul de sus a lungul tuturor utilizatorilor.
Deci, cum fac asta?
Când recordul meu este distribuit pe UserID, variat pe joc,
bine am de gând să merg mai departe și restructurarea, a crea un GSI,
și am de gând să restructureze aceste date.
>> Acum am de gând să hash cu privire la BoardName, care este jocul.
Și am de gând să gama pe punctajul sus.
Și acum am creat diferite cupe.
Sunt folosind aceeași masă, aceleași date element.
Dar eu sunt crearea unui găleată care oferă mi o agregare de scor de top de joc.
>> Și pot interogare acea masă pentru a obține aceste informații.
Deci am stabilit că modelul de interogare până la fi susținută de un indice secundar.
Acum, ei pot fi sortate dupa BoardName și clasificate în funcție de TopScore, în funcție de.
Deci, puteți vedea, acestea sunt tipurile de utilizare cazuri pe care le obține în jocuri de noroc.
Un alt caz bună utilizare ajungem la jocuri de noroc este premii și care a câștigat premii.
Și acesta este un caz de utilizare mare în cazul în care o numim indici rare.
Indici rare sunt capacitatea de a genera
un indice care nu neapărat conțin fiecare element unic pe masă.
De ce nu?
Deoarece atributul care fiind indexate nu exista pe fiecare element.
>> Deci, în acest special utiliza caz, vreau să spun,
Știi ce, am de gând să a crea un atribut numit Award.
Și am de gând să dea fiecare utilizator care are un premiu care atribut.
Utilizatorii care nu au premii sunt nu va avea acel atribut.
Așa că atunci când am crea index, numai utilizatorii
care sunt de gând să arate în indexul sunt
cei care de fapt au câștigat premii.
Deci asta e un mod minunat de a putea pentru a crea indici filtrate că
sunt foarte, foarte selectiv, care nu trebuie să indice întreaga masă.
>> Deci ne apropiem scăzut la timp aici.
Am de gând să merg mai departe și sări afară și sări peste acest scenariu.
Vorbeste un pic about--
>> Audiența: Pot să pun o întrebare rapidă?
Una este a scrie greu?
RICK Houlihan: Ce este?
Audiența: Scrieți grele.
RICK Houlihan: Scrie grele.
Staţi să văd.
>> Audiența: Sau este că nu ceva ce se poate doar
voce la o chestiune de secunde?
RICK Houlihan: Mergem prin scenariul de vot.
Nu e așa de rău.
Ai voi avea câteva minute?
BINE.
>> Deci, vom vorbi despre vot.
Deci, în timp real de vot, avem Cerințe pentru vot.
Cerințe sunt că vom permite fiecare persoană să voteze o singură dată.
Vrem nimeni să fie în măsură pentru a schimba votul lor.
Ne dorim în timp real agregare si analitica pentru demografice
că vom fi arătând utilizatorilor pe site-ul.
>> Gândește-te la acest scenariu.
Noi lucram o mulțime de realitate TV arată unde sunt
a face aceste tipul exact de lucruri.
Astfel încât să puteți gândi la scenariu, avem milioane și milioane
fete de adolescente acolo cu telefoanele lor mobile
și votarea, precum și de vot, precum și vot pentru oricine ar fi
se pare a fi cel mai popular.
Deci, acestea sunt unele dintre cele Cerințe am alerga afară.
>> Și astfel primul să ia în rezolvarea acestei probleme
ar fi de a construi o aplicație foarte simplu.
Așa că am această aplicație.
Am niște alegători acolo.
Ei vin în, au lovit aplicația de vot.
Am niște voturi de masă brută Voi arunca doar acele voturi în.
Voi avea unele agregat voturi tabel care
va face Analitica si demografice mele, și vom pune toate acestea în acolo.
>> Și acest lucru este mare.
Viata e buna.
Viața e bine până când vom afla că există întotdeauna doar una sau două
oameni care sunt populare în alegeri.
Nu e doar unul sau două lucruri că oamenii cu adevărat pasă.
Și dacă sunteți de vot la scară, dintr-o dată că sunt
va fi percuție dracu de doi candidați, unul sau doi candidați.
Un număr foarte limitat de produse oamenii găsesc a fi popular.
>> Acesta nu este un model de design bun.
Aceasta este de fapt o model de design foarte rău
deoarece creează exact ceea ce ne-am a vorbit despre ceea ce a fost taste.
Taste sunt ceva ce nu-mi place.
>> Deci, cum putem repara asta?
Și într-adevăr, modul de a rezolva această este prin luarea aceste cupe candidate
și pentru fiecare candidat, avem, vom adăuga o valoare aleatoare,
ceva ce știm, aleatoare valoare între unul și 100,
între 100 și 1000, sau între unul și 1000,
Cu toate acestea multe valori aleatoare pe care doriți să adăugați pe sfârșitul acestei candidat.
>> Și ceea ce am cu adevărat făcut atunci?
Dacă eu sunt, folosind ID-ul candidat ca galeata voturilor agregate,
dacă am adăugat o întâmplare număr la sfârșitul anului că,
Am creat acum 10 de cupe, o sute de cupe, o mie de galeti
că eu sunt cumularea de voturi peste.
>> Așa că au milioane, și milioane de oameni, și milioane de înregistrări vine
pentru acești candidați, eu sunt acum de raspandire aceste voturi din candidate A_1
prin candidate A_100, deoarece de fiecare dată când un vot vine,
Am generând o întâmplare valoare între unul și 100.
Am o capsare pe la sfârșitul candidat care persoane cu drept de vot pentru.
Am o dumping în acea găleată.
>> Acum, pe partea din spate, știu că am primit o sută de găleți.
Așa că, atunci când vreau să merg mai departe și agregate din voturi,
Am citit de la toate aceste găleți.
Așa că am merge mai departe și se adaugă.
Și apoi eu difuzată aduna în cazul în care mă duc afară și spun hei,
Știi ce, cheia acest candidat spații este peste o sută de găleți.
Am de gând să aduna toate voturi din aceste sute de găleți.
Am de gând pentru a agrega ei și am de gând să spun,
Candidat A are acum totală numărarea voturilor a X.
>> Acum atât de scriere interogare și interogarea de citire
sunt frumos distribuite pentru că eu scriu peste
și am citit peste sute de chei.
Nu scriu și lectură peste o cheie acum.
Deci asta e un model de mare.
>> Aceasta este, de fapt, probabil, unul dintre cele mai importante proiectare
modelelor de scară în NoSQL.
Veți vedea acest tip de model de design în fiecare aroma.
MongoDB, DynamoDB, aceasta nu Indiferent, noi toți trebuie să facem acest lucru.
Pentru că atunci când ai de a face cu aceste aglomerări mari,
va trebui să dau seama o modalitate de a răspândit le peste găleți.
Astfel încât acesta este modul în care face acest lucru.
Bine, deci ce ce faci chiar acum
este te de tranzacționare de pe citire Costul pentru scalabilitate scriere.
Costul de citire meu este un pic mai complex
și trebuie să mă duc citit dintr-o sute de găleți în loc de unul.
Dar eu sunt în măsură să scrie.
Și de transfer mea, scrie mea tranzitează este incredibil.
Deci, este, de obicei, un valoros Tehnica pentru scalarea DynamoDB,
sau orice bază de date NoSQL pentru care contează.
Deci, ne-am dat seama cum să-l scară.
Și ne-am gândit cum să elimina cheile noastre fierbinte.
Și acest lucru este fantastic.
Și avem acest sistem frumos.
Și este ne-a dat vot foarte corect pentru că avem de-record de vot dupe.
Este construit în DynamoDB.
Am vorbit despre drepturile condiționate.
>> Când un alegător vine, pune o inserție pe masă,
ei introduce cu ID-ul lor la vot, în cazul în care încercați să introduceți un alt vot,
Fac o scrie condiționată.
Spune doar scrie acest Dacă acest lucru nu există.
Deci, de îndată ce văd că că votul a lovit masa,
nimeni altcineva va fi capabil de a pune votul în.
Și asta e fantastic.
Si suntem incrementarea contoare noastre candidate.
Și facem nostru demografice și tot ce.
Dar ce se întâmplă dacă meu cerere cade?
Acum, toate dintr-o brusc voturi provin din, și eu
Nu știu dacă acestea sunt obtinerea prelucrate în analiză și demografice mele
mai.
Și atunci când cererea vine înapoi, cum
dracu 'știu ce au de voturi fost prelucrate și în cazul în care să încep?
>> Deci, aceasta este o problemă reală, atunci când începe să se uite la acest tip de scenariu.
Și cum vom rezolva asta?
Am rezolvat cu ceea ce am apel DynamoDB Streams.
Fluxuri este un timp și ordonat jurnal schimbare a separat de fiecare acces
la masa, fiecare scrie accesul la masa.
Orice date care este scris la Tabelul apare pe fluxul.
>> Este de fapt o coadă 24 de ore.
Articole lovit fluxul, ei trăiesc pentru 24 de ore.
Ele pot fi citite de mai multe ori.
Garantat pentru a fi livrate o singură dată la fluxul,
ar putea fi citit n numărul de ori.
Deci, cu toate acestea de multe procese pe care doriți să consuma aceste date, puteți consuma.
Acesta va apărea în fiecare actualizare.
Fiecare scrie va numai apar o dată pe fluxul de.
Deci nu trebuie să vă faceți griji despre procesarea de două ori
din același proces.
>> Este strict ordonat pe articol.
Când spunem timp ordonat și împărțit,
veți vedea pe partiția pe fluxul.
Veți vedea un produs, actualizări în ordine.
Noi nu sunt garantarea pe fluxul pe care esti
mergi la a lua fiecare tranzacție în ordinea în întreaga obiecte.
>> Deci, fluxuri sunt idempotent.
Nu știm cu toții ce înseamnă idempotent?
Idempotent înseamnă că puteți face acest lucru peste și peste și peste din nou.
Rezultatul va fi la fel.
>> Fluxuri sunt idempotent, dar acestea trebuie să fie
jucat la punctul de pornire, ori de câte ori doriți, până la sfârșit,
sau ei nu vor avea ca rezultat în aceleași valori.
>> Acelasi lucru cu MongoDB.
MongoDB are un construct ei numesc oplog.
Este același construct exact.
Baze de date NoSQL multe au acest construct.
Ei l utilizați pentru a face lucruri ca de replicare, care
este exact ceea ce facem cu fluxuri.
Audiența: Poate un întrebare eretic, dar
vorbesc despre Apps face pe un asa mai departe.
Sunt fluxuri garantat nu merge, eventual, în jos?
RICK Houlihan: Da, fluxuri sunt garantate pentru a nu merge în jos.
Noi gestionăm infrastructura din spatele. fluxuri automat
desfășoare în grupul lor de scalare Auto.
Vom merge printr-un pic bit despre ceea ce se întâmplă.
>> Nu ar trebui să spun că nu sunt garantat de a nu merge în jos.
Elementele sunt garantate să apară în fluxul.
Și fluxul va fi accesibil.
Deci, ceea ce duce în jos sau se întoarce up, ce se întâmplă dedesubt.
Este covers-- e OK.
În regulă, astfel încât să obțineți diferite Tipuri de vedere în afara ecranului.
Tipurile de părere că sunt importante pentru o programator de obicei sunt, ceea ce a fost?
I a lua punctul de vedere vechi.
Atunci când o actualizare lovește masa, va împinge vederea vechi pentru fluxul
astfel de date pot arhiva, sau schimbare controlul, identificarea schimbare, schimbare
management.
>> Noua imagine, ceea ce este acum, după actualizarea, asta e un alt tip de vedere
poți obține.
Puteți obține atât imagini vechi și noi.
Poate că amândoi doresc.
Vreau să văd ce era.
Vreau să văd ce sa schimbat la.
>> Am un tip de conformitate de proces care ruleaza.
Acesta trebuie să verifice că atunci când aceste lucruri se schimbă,
că sunt în anumite limite sau în anumiți parametri.
>> Și apoi doar poate că Trebuie să știu ce sa schimbat.
Nu-mi pasă ce articol sa schimbat.
Nu am nevoie sa trebuie să știe ce atribute schimbat.
Vreau doar să știu că produsele sunt atinse.
Deci, acestea sunt tipurile de vizualizări pe care le obține de pe fluxul
și puteți interacționa cu.
>> Cererea că consumă fluxul,
Aceasta este un fel de modul în care aceasta funcționează.
Client DynamoDB cere să împinge date pentru tabele.
Fluxuri implementa pe ceea ce noi numim cioburi.
Cioburi sunt scalate independent de masă.
Ei nu sunt aliniate complet la partițiile de masa ta.
Și motivul pentru care este pentru că linia de sus
la capacitatea, curentul Capacitatea de tabel.
>> Ei implementa în lor propriul grup scalare Auto,
și încep să se rotească în funcție cu privire la modul de multe scrieri vin în,
cât de multe reads-- într-adevăr e scrie.
Nu e nici o reads-- dar cum multe scrieri vin în.
>> Și apoi pe spate scop, avem ceea ce ne
apela un KCL sau Kinesis Client Library.
Kinesis este o date flux tehnologia de procesare de la Amazon.
Și fluxuri este construit pe asta.
>> Astfel încât să utilizați o KCL activat aplicații să citească fluxul.
Kinesis Client Biblioteca de fapt gestionează muncitorii pentru tine.
Și-l face, de asemenea, unele lucruri interesante.
Se va crea unele tabele până în tablespace dumneavoastră DynamoDB
pentru a urmări care un produs au fost procesate.
Deci, în acest fel, dacă se cade înapoi, în cazul în care cade peste și vine și devine
stătea înapoi, se poate determina în cazul în care era în procesarea fluxul.
>> Asta e foarte important atunci când vorbești despre replicarea.
Trebuie să știu ce datele au fost procesate
și ce date a fost încă să fie prelucrate.
Deci biblioteca KCL pentru fluxurile va vă dau o mulțime de funcționalități care.
Este nevoie de grijă de toate menaj.
Acesta se ridică un lucrător pentru fiecare ciob.
Se creează un tabel administrativ pentru fiecare ciob, pentru fiecare lucrător.
Și, după cum cei lucrători foc, mențin aceste tabele
astfel încât să știi această înregistrare a fost citit și prelucrate.
Și apoi în acest fel, dacă procesul de moare și vine din nou online,
se poate relua chiar în cazul în care acesta a plecat.
>> Deci, vom folosi acest lucru pentru eco-regiune replicare.
O mulțime de clienți au nevoie de a muta de date sau părți de tabele de date
în jurul valorii de la diferite regiuni.
Există nouă regiuni in toata lumea.
Deci, ar putea fi o am need-- ar putea avea utilizatorii în Asia, utilizatorii
în Coasta de Est a Statelor Unite.
Ei au date diferite care trebuie să fie distribuite la nivel local.
Și poate un utilizator zboară de la Asia pe la Statele Unite ale Americii,
și vreau să reproducă datele sale cu el.
Deci, atunci când el devine din avion, el are o experiență bună, folosind aplicația său mobil.
>> Puteți utiliza eco-regiunea Biblioteca de replicare pentru a face acest lucru.
Practic ne-am prevăzute două tehnologii.
Unul o aplicație consolă puteți se ridice în picioare pe cont propriu instanță EC2.
Se ruleaza replicare pur.
Și apoi v-am oferit biblioteca.
Biblioteca puteți utiliza pentru a construi propria aplicație dacă
vrei sa faci lucruri nebunești cu care data-- filtru, reproduce doar o parte din ea,
roti de date, mutați-l într-un tabel diferit, așa mai departe și așa mai departe.
Deci, asta e un fel de ceea ce arata ca la fel ca.
>> DynamoDB Streams poate fi prelucrate de ceea ce noi numim Lambda.
Am menționat un pic despre eveniment arhitecturi de aplicare condus.
Lambda este o componentă cheie a acestei.
Lambda este cod care trage la cerere ca răspuns la un anumit eveniment.
Unul dintre aceste evenimente ar putea fi un înregistrare care apare pe fluxul.
Dacă apare o înregistrare pe fluxul, vom numi acest funcție Java.
Ei bine, acest lucru este JavaScript, și Lambda sprijină Node.js, Java, Python,
și va sprijini în curând alte limbi, de asemenea.
Și suficient să spun, că e cod pur.
scrie în Java, definiți o clasă.
Tu împingeți JAR sus în Lambda.
Și apoi să specificați care clasa pentru a apela, ca răspuns la care eveniment.
Și apoi infrastructurii Lambda în spatele că va rula acel cod.
>> Acest cod poate procesa înregistrările de pe fluxul.
Se poate face orice vrea cu el.
În acest exemplu particular, toate suntem într-adevăr a face este de logare atributele.
Dar aceasta este doar cod.
Cod pot face nimic, nu?
>> Astfel încât să puteți roti că datele.
Puteți crea o imagine derivat.
Daca este o structură de document, puteți aplatiza structura.
Puteți crea indici alternative.
Tot felul de lucruri pe care le puteți face cu Izvoare DynamoDB.
>> Și într-adevăr, asta e ceea ce pare ca la fel ca.
Astfel încât să obțineți cele actualizări vine.
Vin de pe șirul.
Sunt citit de funcția Lambda.
Ei rotirea datelor și împingându-l în tabele derivate,
notificarea sisteme externe de schimbare, și împingând de date în ElastiCache.
>> Am vorbit despre cum să pună cache în fața bazei de date pentru că vânzările
scenariu.
Ei bine, ce se întâmplă dacă am actualiza descrierea articolului?
Ei bine, dacă am avut o Lambda Funcția rulează pe masa,
dacă am actualiza descrierea element, acesta va ridica înregistrarea de pe fluxul,
și-l vom actualiza ElastiCache exemplu cu noile date.
Așa că o mulțime de ceea ce facem cu Lambda.
E cod lipici, conectori.
Și oferă de fapt abilitatea de a lansa
și de a rula aplicații foarte complexe fără un server dedicat
infrastructurii, care este foarte misto.
>> Deci, să ne întoarcem la nostru în timp real arhitectura vot.
Acest lucru este nou si imbunatatit cu nostru cursuri de apă și KCL activat aplicație.
Fel ca înainte, putem se ocupe de orice scară de la alegeri.
Ne place asta.
Facem din adună scatter pe mai multe găleți.
Avem de blocare optimistă întâmplă.
Putem păstra alegătorii noștri la schimbarea voturile lor.
Ei pot vota doar o singură dată.
Acest lucru este fantastic.
În timp real toleranței la erori, agregare scalabil acum.
În cazul în care lucrul cade, aceasta știe unde să se reporni
atunci când vine vorba înapoi, deoarece suntem folosind aplicația KCL.
Și apoi putem folosi, de asemenea, că Cerere KCL pentru a împinge afară de date
a Redshift pentru alte Analytics app, sau utilizare
de MapReduce elastice pentru a rula în timp real de streaming de pe agregate
de faptul că datele.
>> Deci, acestea sunt lucruri pe care le nu s-au vorbit despre mult.
Dar sunt suplimentare tehnologii care vin
să suporte atunci când sunteți în căutarea La aceste tipuri de scenarii.
>> Bine, pentru ca este vorba despre analytics cu DynamoDB Streams.
Puteți colecta de-dupe date, face tot felul
de lucruri frumos, date agregate în memorie, crea aceste tabele derivate.
Asta e un caz de utilizare imens că o mulțime de clienți
sunt implicate cu, luând imbricate proprietăți ale acestor documente JSON
și crearea de indici suplimentare.
>> Suntem la sfârșitul anului.
Vă mulțumim pentru poartă cu mine.
Deci, haideți să vorbim despre arhitectura de referință.
DynamoDB stă în mijlocul atât de mare parte din infrastructura AWS.
Practic puteti cârlig până la tot ce vrei.
Aplicații construit folosind Dynamo includ Lambda, ElastiCache, CloudSearch,
împinge datele în afară Elastic MapReduce, import export din DynamoDB
în S3, tot felul de fluxuri de lucru.
Dar, probabil, cel mai bun lucru pentru a vorbi despre,
și acest lucru este într-adevăr ceea ce este interesant este atunci când ne
vorbesc despre aplicații bazate pe eveniment.
>> Acesta este un exemplu de un proiect intern
pe care o avem atunci când suntem de fapt publicare pentru a aduna rezultatele sondajului.
Deci, într-un link de e-mail care am trimite, acolo va
fi un pic click link spunând aici pentru a răspunde la sondaj.
Și atunci când o persoană clicuri care se leagă, ceea ce se întâmplă
este că trage în jos o sigură Formular de sondaj HTML de la S3.
Nu e nici un server.
Acesta este doar un obiect S3.
>> Această formă vine, încarcă în browser-ul.
Are Backbone.
Are complex JavaScript că este pornit.
Deci, este foarte bogat aplicație rulează în browser-ul clientului.
Ei nu știu că nu sunt interacționând cu un server back end.
În acest moment, totul browser.
>> Ei publica rezultatele la ceea ce numim Amazon API Gateway.
API Gateway este pur și simplu un API web pe care le puteți defini și cârlig până
pentru ce vrei tu.
În acest caz particular, suntem conectat la o funcție Lambda.
>> Deci operațiune meu post este întâmplă cu nici un server.
Practic că API Gateway sta acolo.
Ea mă costă nimic până când oamenii începe să postați la ea, nu?
Funcția Lambda doar sta acolo.
Și mă costă nimic până oamenii încep să-l lovi.
Deci, puteți vedea, ca volumul crește, atunci vin taxele.
Nu am rulează un server 7/24.
>> Așa că am trage formularul jos din găleată,
și am posta, prin API Gateway în funcția Lambda.
Și apoi Lambda Funcția spune, știi
ceea ce, am niște PIIs, unele informații de identificare personală
în aceste raspunsuri.
Am comentariile provenind din utilizatori.
Am adrese de email.
Am nume de utilizator.
>> Lasă-mă să împartă acest off.
Am de gând să genereze unele metadate de pe acest record.
Și am de gând pentru a împinge metadate în DynamoDB.
Și am putut cripta toate datele și-l împinge în DynamoDB dacă vreau.
Dar este mai ușor pentru mine, în acest utiliza caz, pentru a merge mai departe un cuvânt de spus,
Am de gând să împingă datele brute într-o găleată S3 criptat.
Asa ca am folosi construit în partea de server S3 criptare și Key Management Amazon
Serviciu, astfel că am o cheie care se poate roti pe un interval regulat,
și pot proteja că datele PII ca parte a fluxului de lucru întregi acest.
>> Deci, ce am făcut?
Tocmai am desfășurat o întreagă cerere, și nu am nici un server.
Deci, este ceea ce evenimente de aplicație condus Arhitectura nu pentru tine.
>> Acum, dacă te gândești la în cazul utilizării pentru astea--
avem alți clienți să vorbesc la aproximativ această arhitectură exacta care
campanii fenomenal mari, care se uita la acest lucru și merge, oh meu.
Pentru că acum, ei pot Practic împinge acolo,
lăsa să se campanie sta acolo până când se lansează, și nu
trebuie să vă faceți o smochin despre Ce fel de infrastructură
va fi acolo să o susțină.
Și apoi, de îndată ce campania se face,
e ca si cum infrastructura doar imediat dispare
într-adevăr, deoarece nu nu este infrastructură.
E cod doar că stă pe Lambda.
E doar datele care stă în DynamoDB.
Acesta este un mod uimitor pentru a construi aplicații.
>> Audiența: Deci este mai mult efemer decât ar fi
în cazul în care a fost stocat pe un server real?
>> RICK Houlihan: Absolut.
Pentru că serverul exemplu ar trebui să fie un 7/24.
Trebuie să fie disponibile pentru cineva pentru a răspunde la.
Ei bine, ghici ce?
S3 este disponibil 7/24.
S3 răspunde întotdeauna.
Și S3 este foarte, foarte bun la servire obiecte.
Aceste obiecte pot fi fișiere HTML, sau Fișiere JavaScript, sau ce vrei tu.
Puteți rula aplicații web foarte bogate din S3 găleți, și oamenii.
>> Și așa că e ideea aici este de a obtine departe de drum
am folosit să mă gândesc.
Cu toții să ne gândim la folosit termeni de servere și gazde.
Nu e vorba de asta mai.
Este vorba despre infrastructură drept cod.
Implementați codul de nor și lasa norul rula pentru tine.
Și asta e ceea ce AWS încearcă să facă.
>> Audiența: Deci, cutia de aur în mijloc de API Gateway nu este-server cum ar fi,
ci este doar--
>> RICK Houlihan: Puteți să vă gândiți va ca fațadă de server.
Tot ce este este că va lua o HTTP solicite și harta-l la un alt proces.
Asta e tot ce face.
Și în acest caz, ne cartografiere l la o funcție Lambda.
Bine, asta-i tot ce am.
Mulțumesc foarte mult.
Apreciez asta.
Știu că ne dorim un pic în timp.
Și, sperăm, voi primit un pic de informații
pe care le poate lua astăzi.
Și îmi cer scuze dacă m-am dus peste unele dintre capetele voastre,
dar există o mulțime de bun cunoștințe fundamentale fundamentale
care cred că este foarte valoros pentru tine.
Deci, vă mulțumesc pentru că m-.
[APLAUZE]
Audiența: [inaudibil] este atunci când spuneai
trebuia să treacă prin lucru de la început până la sfârșit
pentru a obține valorile corecte sau aceleași valori,
cum ar fi valorile schimba dacă [neauzit].
>> RICK Houlihan: Oh, idempotent?
Cum s-ar schimba valorile?
Ei bine, pentru că dacă nu am alerga tot drumul până la sfârșit,
atunci nu știu ce schimbări au fost făcute în ultima milă.
Nu va să fie aceleași date ca ceea ce am vazut.
Audiența: Oh, astfel încât să doar nu au ajuns întreaga intrare.
RICK Houlihan: dreapta.
Trebuie să mergi la început la final, iar apoi este
Va fi o stare consistentă.
Misto.
>> Audiența: Deci ne-a arătat DynamoDB poate face document sau valoarea cheii.
Și am petrecut o mulțime de timp pe valoare-cheie cu un hash și modalitățile
a flip în jurul.
Când te-ai uitat la aceste tabele, este că lăsând în urmă abordarea de documente?
>> RICK Houlihan: I nu ar fi lăsându-l în urmă spun.
>> Audiența: Ei s-au separat de the--
>> RICK Houlihan: Cu documentul abordare, tipul documentului în DynamoDB
este doar cred că de ca un alt atribut.
Este un atribut care conține o structură de date ierarhică.
Și apoi în interogări, puteți utiliza proprietățile
dintre aceste obiecte folosind Object Notation.
Deci, eu pot filtra pe un imbricate proprietate a documentului JSON.
Audiența: Deci, orice moment am face o abordare de document,
Pot fel ajunge la tabular--
Audiența: Absolut.
Audiența: --indexes și lucruri pe care tocmai ați vorbit.
RICK Houlihan: da, indici și tot ce,
atunci când doriți să indexeze proprietăți ale JSON,
modul în care vom avea de a face asta este dacă introduceți un obiect JSON sau un document
în Dynamo, ar trebui să utilizați fluxuri.
Fluxuri ar citi de intrare.
Te-ai obține că JSON opoziție și ai spune OK,
ceea ce este proprietatea vreau să indice?
>> Puteți crea un tabel derivat.
Acum, că e modul în care funcționează acum.
Noi nu vă permit să indice direct acele proprietăți.
>> Audiența: Tabularizing documente.
>> RICK Houlihan: Exact, aplatizare ea, tabularizing, exact.
Asta e ceea ce faci cu ea.
>> Audiența: Mulțumesc.
>> RICK Houlihan: Da, absolut, vă mulțumesc.
Audiența: Deci e un fel de Mongo întâlnește classifers Redis.
>> RICK Houlihan: Da, e mult de genul asta.
Asta-i o descriere bună pentru el.
Misto.