>> [MUZIKO Ludante]
RICK Houlihan: Bone.
Saluton, ĉiuj.
Mia nomo estas Rick Houlihan.
Mi estas altranga rektoro solvoj arkitekto ĉe AWS.
Mi enfokusigi NoSQL kaj DynamoDB teknologioj.
Mi estas ĉi tie hodiaŭ por paroli al vi iomete pri tiuj.
>> Mia fono estas unuavice en datumoj tavolo.
Mi pasigis duonon mia disvolviĝo kariero skribanta datumbazo,
datumoj aliro, solvoj por diversaj aplikoj.
Mi estis en Cloud virtualización por proksimume 20 jaroj.
Do antaŭ la Nubo estis la Nubo, ni nomis ŝin utileco komputado.
Kaj la ideo, estas kiel PG & E, vi pagos por kio vi uzas.
Hodiaŭ ni nomas ĝin la nubo.
>> Sed tra la jaroj, mi laboris por paro de firmaoj
vi probable neniam aŭdis.
Sed Mi kompilis liston de teknika plenumoj, mi supozas ke vi volas diri.
Mi havas ok patentojn en Cloud sistemoj virtualización, mikroprocesoro dezajno,
kompleksa okazaĵo prilaborado, kaj aliaj areoj ankaŭ.
>> Do tiuj tagoj, Mi enfokusigi plejparte sur NoSQL teknologioj kaj la sekva generacio
datumbazo.
Kaj tio estas ĝenerale kion mi tuj esti tie parolante al vi hodiaŭ pri.
Do kion vi povas atendi de tiu kunsido,
ni iros tra mallonga historio de datumtraktado.
Ĉiam helpema por kompreni de kie ni venis
kaj kial ni estas, kie ni estas.
Kaj ni parolos iom bita pri NoSQL teknologio
de fundamenta starpunkto.
>> Ni akiros en kelkaj la DynamoDB internals.
DynamoDB estas AWS estas neniu gusto.
Ĝi estas plene sukcesis kaj gastigita NoSQL solvo.
Kaj ni parolos iomete pri tablo strukturo, APIs, datumtipoj, indeksoj,
kaj iu el la internals de tiu DynamoDB teknologio.
Ni enir iuj de la dezajno ŝablonoj kaj bonaj praktikoj.
Ni parolos pri kiel vi uzi tiun teknologion por kelkaj
de hodiaŭa aplikoj.
Kaj tiam ni parolos iomete pri la evoluado aŭ la apero
de nova paradigmo en programado nomita okazaĵo tirataj aplikoj
kaj kiel DynamoDB ludas en tiu tiel.
Kaj ni lasos vin iomete de referenco arkitekturo diskuto
tiel ni povos paroli pri kelkaj el la manieroj vi povas uzi DynamoDB.
>> Do unue off-- tiu estas demando Mi aŭdas multon estas, kio estas datumbazo.
Multaj homoj kredas, ke ili scias kion datumbazo estas.
Se vi Google, vi vidos tion.
Ĝi estas strukturita aro de datumoj tenis en komputilo, speciale unu kiu
estas alirebla en diversaj manieroj.
Mi supozas ke estas bona difino de moderna datumbazo.
Sed mi ne ŝatas ŝin, ĉar ĝi implicas kelkajn aferojn.
Ĝi implicas strukturo.
Kaj ĝi implicas ke ĝi estas en komputilo.
Kaj datumbazoj ne Ĉiam ekzistas sur komputiloj.
Datumbazoj reale ekzistis en multaj manieroj.
>> Do pli bona difino de datumbazo estas io tiamaniere.
Al datumbazo estas organizita mekanismo por stoki, administri,
kaj prenado informojn.
Tiu estas de About.com.
Do mi ŝatas tiun ĉar ĝi vere prelegoj pri datumbazo estanta dosieraro,
deponejo de informoj, ne nepre
io kiu sidas sur komputilo.
Kaj dum historio, ni ne ĉiam havis komputilojn.
>> Nun, se mi petos la mezumo desarrollador hodiaŭ kio estas
datumbazo, jen la respondo mi akiras.
Ie mi povas meti aĵojn.
Dekstra?
Kaj estas vera.
Sed estas malfeliĉa.
Ĉar la datumbazo estas vere la fondo de la moderna app.
Estas la fundamento de ĉiu apliko.
Kaj kiel vi konstruu ke datenbazo, kiom vi strukturi
ke datumoj tuj diktas ke apliko rezultas kiel vi grimpi.
>> Do multe da mia laboro hodiaŭ pritraktas kio
okazas kiam programistoj prenu ĉi alproksimiĝo
kaj traktanta la sekvo de apliko kiu
nun grimpante preter la originala intenco kaj suferado de malbona dezajno.
Do espereble kiam vi marŝi for hodiaŭ, vi
havas paron de iloj en via zono kiu tenos vin
el farante tiujn samajn erarojn.
Bone.
Do ni parolu pri iomete da la timeline de datumbazo teknologio.
Mi kredas ke mi legis artikolo ne ke antaŭlonge
kaj ĝi diris iun ĉi lines-- ĝi estas tre poezia komunikaĵo.
Ĝi diris la historio de datumtraktado estas
plena de alta filigranoj de datumoj abundo.
BONE.
Nun, mi supozas ke estas speco de vera.
Sed mi vere rigardi kiel la historio estas vere plenigis
kun alta filigrano de datumoj premo.
Ĉar la datumoj imposto de ingestión neniam iras malsupren.
Ĝi nur iras supren.
>> Kaj novigado okazas kiam ni vidas datumoj premo, kio
estas la kvanto de datumoj kiuj estas nun en venanta en la sistemo.
Kaj ĝi ne povas procesi kompetente ĉu en tempo aŭ en kosto.
Kaj tio estas kiam ni komencas rigardi datumoj premo.
>> Do kiam ni rigardas la unua datumbazon, ĉi
Estas kiu estis inter niaj oreloj.
Ni ĉiuj naskiĝis kun ĝi.
Ĝi estas bela datumbazo.
Ĝi havas altan haveblecon.
Ĝi estas ĉiam sur.
Vi povas ĉiam atingi ĝin.
>> Sed estas sola uzanto.
Mi ne povas dividi miajn pensojn kun vi.
Vi ne povas akiri mian pensoj kiam vi volas ilin.
Iliaj abilitiy estas ne tiel bona.
Ni forgesas aĵojn.
Ĉiu nun kaj tiam, unu el ni folioj kaj pluiras al alia ekzisto
kaj ni perdas ĉiun kiu estis en tiu datumbazo.
Do tio ne estas ĉiu tiu bono.
>> Kaj ĉi funkciis bone super tempo kiam ni estis reen en la tago
kiam ĉiuj ni vere bezonis scii estas kie ni tuj iru morgaŭ
aŭ kie ni kolektos la plej bonan manĝon.
Sed kiel ni komencis kreski kiel civilizacio kaj registaro komenciĝis
veni en estaĵo, kaj komercoj komencis evolui,
ni komencis rimarki nin bezonas iom pli ol kio
Ni povus meti en nia kapo.
Bone?
>> Ni bezonis sistemoj de rekordo.
Ni bezonis lokojn por povi stoki datumojn.
Do ni komencis verki dokumentojn, kreanta bibliotekoj kaj arkivoj.
Ni komencis evoluiganta sistemo libro librotenisto librotenado.
Kaj ke sistemo de Ledger kalkula kuris la mondo dum multaj jarcentoj,
kaj eble eĉ jarmiloj kiel ni ia kreskis al la punkto
kie tiu datumo ŝarĝo superis la kapablo de tiuj sistemoj
povi enhavi ĝin.
>> Kaj tio fakte okazis en la 1880s.
Dekstra?
En la 1880 Censo.
Tiu estas vere kie la turniĝo atentigi moderna datumtraktado.
Tio estas la punkto je kiu la kvanto de datumoj
kiu estis kolektita de la Usona registaro alvenis al la punkto
kie prenis ok jaroj procesi.
>> Nun, ok years-- kiel vi scias, la censo
kuroj ĉiun 10 years-- tiel ĝi estas sufiĉe preterlasas ke de tempo ni
ekhavis la 1890 kontado, la kvanton de datumoj kiuj
tuj estos procesitaj per registaro estis
tuj superos la 10 jaroj kiujn ĝi prenus al ĵetis la nova censo.
Tiu estis problemo.
>> Do ulo nomis Herman Hollerith venis kune
kaj li inventis unuo rekordo stampilon kartoj, stampilon karto leganto, stampilon karto
tabulador kaj la colación de la mekanismoj por ĉi tiu teknologio.
Kaj ke firmao kiu formis en la tempo, kune kun paro de aliaj,
fakte iĝis unu el la kolonoj de Malgranda entrepreno ni scias hodiaŭ nomita IBM.
>> Do IBM origine estis en datumbazaj negoco.
Kaj tio estas vere kion ili faris.
Ili faris datumtraktado.
>> Kiel do la proliferación de punĉo kartoj, sprita meĥanismoj
de povi utiligi ke teknologio por razu ordo rezulto aroj.
Vi povas vidi en ĉi tiu bildo tie ni havas little--
ĝi estas iom small-- sed vi povas vidi tre sprita mekanika mekanismo
kie ni havas stampilon karto ferdeko.
Kaj ies preno iom destornillador
kaj batante per la fendoj kaj levante ĝin
bonstata turniro, kiu ordo rezultoj starigis.
>> Tiu estas agregaĵo.
Ni faru tion tutan tempon hodiaŭ en la komputilo,
kie vi faras ĝin en la datumbazo.
Ni kutimis fari ĝin manualmente, dekstra?
Homoj metis tion kune.
Kaj estis la proliferado de tiuj kartoj boritaj
en kion ni vokis datumoj tamburojn kaj datumo bobenoj, papero bendo.
>> La datumtraktado industrio prenis lecionon de la ludanto pianoj.
Ludanto pianoj reen ĉe la jarcentŝanĝo
kutimis uzi paperon bobenoj kun fendoj sur sciigi kio klavoj ludi.
Por ke teknologio estis adaptita eventuale enteni ciferecaj datumoj,
ĉar ili povus enkalkulu datumoj sur tiuj papero bendo bobenoj.
>> Nun, kiel rezulto, datumoj estis actually-- kiom
vi aliri ĉi datumoj estis rekte dependa sur kiel vi stokas ĝin.
Do se mi metas la datumojn sur bendo, Mi devis aliri la datumojn lineare.
Mi devas ruli la tuta bendo aliri ĉiujn datumojn.
Se mi metas la datumojn en stampilon kartojn, mi povis aliri ĝin
en iom pli hazarda modo, eble ne tiel rapide.
>> Sed estis limigoj en kiel ni aliro al datumoj bazita sur kiel estis stokita.
Kaj tiel tio estis problemo iro en la '50s.
Denove, ni povas komenci al vidi ke ni disvolvi novajn teknologiojn procesi
la datumoj, dekstra, tio malfermas la pordo por novaj solvoj,
por novaj programoj, nova aplikoj por kiuj datumoj.
Kaj vere, gobernanza eble estis la kialo
kial ni disvolvis kelkajn el tiuj sistemoj.
Sed negocon rapide iĝis la ŝoforo malantaŭ la evoluado
de la moderna datumbazo kaj la moderna sistemo de arkivoj.
>> Do la sekvanta afero ke venis estis en la 50'oj
estis la dosiersistemo kaj la disvolviĝo de aliro aleatorio stokado.
Tio estis bela.
Nun, ĉiuj de subita, ni povas meti niajn fajlilo ie sur tiuj malmolaj diskoj
kaj ni povas aliri ĉi datumoj hazarde.
Ni povas analizi ke informo el dosierojn.
Kaj ni solvis ĉiujn mondo problemoj kun datumtraktado.
>> Kaj kiu daŭris ĉirkaŭ 20 aŭ 30 jarojn ĝis la evoluado
de la rilata datumbazo, kiu Estas kiam la mondo decidis nin nun
bezonas havi dosieraro kiu malvenko la aglomeración de datumoj trans la dosiero
sistemoj kiuj ni konstruis. Dekstra?
Tro multe datumoj distribuita en tro multaj lokoj, la de-duobligo de datumoj,
kaj la koston de stokado estis enorma.
>> En la 70'oj, la plej multekosta rimedo ke komputilo havis estis la stokado.
La procesoro estis rigardita kiel fiksa kosto.
Kiam mi aĉetas la skatolo, la CPU faras iun laboron.
Ĝi tuj estos turnadanta ĉu ĝi estas vere laboranta aŭ ne.
Tio estas vere enprofundigita kosto.
>> Sed kion kostis min kiel negoco estas stokado.
Se mi devos aĉeti pli diskoj apud monato, tio estas vera kosto kiu mi pagis.
Kaj ke stokado estas multekosta.
>> Nun ni rapide antaŭen 40 jaroj kaj ni havas alian problemon.
La komputi estas nun la plej altekosta rimedo.
La stokado estas malmultekosta.
Mi volas diri, ni povas iri ie ajn sur la nubo kaj ni povos trovi malmultekostan stokado.
Sed kion mi povas ne trovi estas malmultekosta komputi.
>> Do la evoluo de la hodiaŭa teknologio, de datumbazo teknologio,
Estas vere koncentrita ĉirkaŭ distribuita datumbazoj
ke ne suferas de la sama tipo de skalo
limigoj de interrilataj datumaroj.
Ni parolos iomete pri kion tio vere signifas.
>> Sed unu el la kialoj kaj la ŝoforo malantaŭ this-- ni
parolis pri la datumoj premo.
Datumoj premo estas io kiu pelas la novigon.
Kaj se vi rigardas super la lastaj kvin jaroj,
tiu estas abako de kio la datumoj ŝarĝo trans la ĝenerala entrepreno
aspektas kiel en la lastaj kvin jaroj.
>> Kaj la ĝenerala regulo de dikfingro tiuj days-- se vi iros Google--
estas 90% de la datumoj kiuj ni stoki hodiaŭ, kaj ĝi estis
generita ene de la lastaj du jaroj.
BONE.
Nun, ĉi tio ne estas tendenco kiu novas.
Tio estas tendenco kiu estas estita eliros por 100 jaroj.
Ekde Herman Hollerith evoluigis la stampilon karto,
ni estis konstruado datumoj deponejoj kaj kolektanta datumon ĉe fenomena impostoj.
>> Do dum la lastaj 100 jaroj, ni vidis ĉi tiun tendencon.
Tio ne tuj ŝanĝos.
Irante antaŭen, ni tuj vidos tiu, se ne akcelita tendenco.
Kaj vi povas vidi kion tio aspektas.
>> Se negoco en 2010 havis unu terabajto de datumoj sub direktado,
hodiaŭ tiu signifas ke ili estas administri 6.5 petabytes de datumoj.
Tio 6.500 fojoj pli datumoj.
Kaj mi scias tion.
Mi laboras kun tiuj komercoj ĉiutage.
Antaŭ kvin jaroj, mi parolus al entreprenoj
kiu parolus al mi pri kia doloro ĝi estas gestionar terabajtoj de datumoj.
Kaj ili parolus al mi pri kiamaniere ni vidas
ke tiu estas probable tuj esti petabyte aŭ du
ene de paro de jaroj.
>> Tiuj samaj entreprenoj hodiaŭ mi renkontis kun,
kaj ili parolas al mi pri la problemo estas ne havi perantino
dekoj, 20 petabytes de datumoj.
Do la eksplodo de la datumoj en la industrio
forpelas la enorma bezonas por bona solvoj.
Kaj la rilata datumbazo estas nur ne vivas ĝis la peto.
>> Kaj do tie estas lineara korelacion inter datumoj premo
kaj teknika novigo.
Historio montris al ni tiu, kiu super tempo,
kiam la volumo de datumoj kiu devas esti procesitaj
superas la kapaciton de la sistemo procesi ĝin en akceptebla tempo
aŭ ĉe akceptebla kosto, tiam novaj teknologioj
estas elpensita por solvi tiujn problemojn.
Tiuj novaj teknologioj, siavice, malfermu la pordon
al alia aro de problemoj, kiujn kolektas eĉ pli datumoj.
>> Nun, ni ne tuj halti ĉi.
Dekstra?
Ni ne tuj halti ĉi.
Kial?
Ĉar vi ne povas scii ĉion oni devas scii en la universo.
Kaj kiel longe kiel ni vivus, tra la homa historio,
ni ĉiam pelataj scii pli.
>> Do ŝajnas kiel ĉiu colo ni movas malsupren la vojo de scienca malkovro,
ni multiplikante la kvanto de datumoj ke ni devas prilabori eksponente
kiel ni malkovros pli kaj pli kaj pli pri la interna funkciado de vivo,
pri kiel la universo funkcias, pri manipulante la scienca malkovro,
kaj la inventado kiu ni faras hodiaŭ.
La volumo de datumoj nur senĉese pliigas.
Do povante trakti tiu problemo estas enorma.
>> Do unu el la aĵoj ni rigardas kiel kial NoSQL?
Kiel NoSQL solvi tiun problemon?
Nu, rilata datumbazoj, Strukturita Query Language,
SQL-- ke estas vere konstrukcio de la interrilata database-- tiuj aferoj estas
optimumigita por stokado.
>> Reen en la 70'oj, denove, disko estas multekosta.
La provizoj ekzerco de stokado en la entrepreno estas senfina.
Mi scias.
Mi vivis ĝin.
Mi skribis stokado ŝoforoj por enterprised superserver entrepreno
reen en la '90aj jaroj.
Kaj la malsupra linio estas trasercxante alian stokado tabelo estis nur iu kiu
okazis ĉiutage en la entrepreno.
Kaj neniam haltis.
Granda denseco de stokado, peto por alta denseca stokado,
kaj por pli efika stokado devices-- ĝi neniam ĉesis.
>> Kaj NoSQL estas granda teknologio ĉar ĝi normaligas la datumoj.
Ĝi de-duobligas la datumoj.
Ĝi metas la datumoj en strukturo kiu estas agnostikulo al ĉiu aliro ŝablono.
Multoblaj aplikoj povas kolizii ke SQL datumbazo, kuras ad hoc pridemandojn,
kaj akiri datumojn en la formo ke ili devas prilabori por sia laborŝarĝoj.
Tio sonas fantazia.
Sed la malsupra linio estas kun ajna sistemo, se ĝi estas agnostikulo al ĉio,
ĝi estas optimumigita por nenio.
BONE?
>> Kaj tio estas kion ni ricevas per la rilata datumbazo.
Ĝi estas optimumigita por stokado.
Ĝi estas ununormigita.
Ĝi estas rilata.
Ĝi apogas la ad hoc demandoj.
Kaj ĝi kaj ĝi grimpas vertikale.
>> Se mi devas akiri pli grandan SQL datumbazo aŭ pli potenca SQL datumbazo,
Mi iros aĉeti pli grandan pecon de fero.
BONE?
Mi laboris kun multaj klientoj ke estis tra gravaj ĝisdatigaĵoj
en ilia SQLa infrastrukturo nur por ekscii ses monatojn poste,
ili estas frapanta la muron denove.
Kaj la respondo de Oracle aŭ MSSQL aŭ iu alia estas akiri pli grandan skatolon.
Nu malpli frue, vi ne povas aĉeti grandan skatolon, kaj tio estas vera problemo.
Ni devas vere ŝanĝi tion.
Do kie tio funkcias?
Ĝi laboras bone por eksterreta analytics, OLAP-tipo laborŝarĝoj.
Kaj tio estas vere kie SQLa apartenas.
Nun, ĝi estas uzata hodiaŭ en multaj rete transaccionales prilaborado-tipo
aplikoj.
Kaj ĝi funkcias nur fajna ĉe iu nivelo de utiligo,
sed simple ne skali la vojo ke NoSQL faras.
Kaj ni parolos iom bita pri kial tio estas.
>> Nun, NoSQL, aliflanke, estas pli optimizado por komputi.
BONE?
Ne estas agnostikulo al la aliro ŝablono.
Estas kion ni nomas de-ununormigita strukturo aŭ hierarkia strukturo.
La datumoj en rilata datumbazo estas kunvenis de multoblaj tabloj
produkti la vido ke vi bezonas.
La datumoj en NoSQL datumbazo estas stokita en dokumento kiu
enhavas la hierarkia strukturo.
Ĉiuj de la datumoj kiuj normale estus kunvenis por produkti tiun vidpunkton
estas stokita en ununura dokumento.
Kaj ni parolos iomete pri kiel tio funkcias en kelkaj mapoj.
>> Sed la ideo estas, ke vi stoki viajn datumojn kiel tiuj instantiated vidpunktojn.
BONE?
Vi grimpi horizontale.
Dekstra?
Se mi bezonas pliigi la grandecon de mia NoSQL stelamaso
Mi ne bezonas akiri pli grandan skatolon.
Mi alvenas alia skatolo.
Kaj mi kolekti tiujn kune, kaj mi povas Shard ke datumoj.
Ni parolos iom pri kio sharding estas, esti
povis grimpi ke datenbazo trans multoblaj fizikaj aparatoj
kaj forigi la baron kiu postulas min grimpi vertikale.
>> Do ĝi estas vere konstruita por retaj transakcia prilaborado kaj skalo.
Estas granda distingo tie inter raportado, dekstra?
Raportado, mi ne scias la demandoj mi tuj demandas.
Dekstra?
Reporting-- se iu el miaj marketing fako
volas just-- kiom da de miaj klientoj havi ĉi apartan karakterizaĵon kiu
aĉetita sur ĉi day-- Mi ne scias kio konsulti ili tuj demandas.
Do mi devas esti agnostikulo.
>> Nun, en rete transaccionales apliko,
Mi scias kion demandoj mi demandas.
Mi konstruis la apliko por tre specifa laborfluo.
BONE?
Do se mi optimizar la datumoj stoki apogi ke laborfluo,
ĝi tuj estos pli rapida.
Kaj jen kial NoSQL povas vere akceli la transdono
de tiuj tipoj de servoj.
Bone.
>> Do ni tuj eniri iomete de teorio tie.
Kaj iu el vi, viaj okuloj povus ruliĝi reen iomete.
Sed mi provos konservi ĝin tiel alta nivelo kiel mi povas.
Do se vi estas en projekto demarŝo, estas
al konstrukcio nomis la triangulo de devigoj.
BONE.
La triangulo de premas diktaĵoj vi ne povas havi ĉion ĉiuj la tempo.
Ne havas vian kukaĵon kaj manĝi ĝin ankaŭ.
Do en projekto demarŝo, ke triangulo devigoj estas vi povas havi ĝin malmultekosta,
Vi povas havi ĝin rapida, aŭ vi povas havi ĝin bona.
Pick du.
Ĉar vi ne povas havi ĉiujn tri.
Dekstra?
BONE.
>> Do vi aŭdas pri tio tre.
Ĝi estas triobla devige, triangulo de triobla devige,
aŭ la fera triangulo estas oftentimes-- kiam vi parolos projekti perantoj,
ili parolos pri tio.
Nun, datumbazoj havas ilia propra fera triangulo.
Kaj la fero Triangulo de datumoj estas kion ni nomas CAP teoremo.
BONE?
>> CAP teoremo diktaĵoj kiom datumbazoj funkcii
sub tre specifaj kondiĉoj.
Kaj ni parolos pri kion tio kondiĉo estas.
Sed la tri punktoj de la triangulo, tiel diri, estas C, consistencia.
BONE?
Do en Cap, konsistenco signifas ke ĉiuj klientoj kiuj povas aliri la datumbazon
havos ĉiam tre konsekvenca vido de datumoj.
Nenies gonna vidi du malsamajn aferojn.
BONE?
Se mi vidas la datumbazo, Mi vidas la saman vidon
kiel mia partnero, kiu vidas la sama datumbazo.
Tio consistencia.
>> Havebleco signifas ke se la datumbazo rete, se ĝi povas esti atingita,
ke ĉiuj klientoj ĉiam povi legi kaj skribi.
BONE?
Do ĉiu kliento kiu povas legi la datumbazo
ĉiam povos legado datumoj kaj skribi datumojn.
Kaj se tio estas la kazo, ĝi estas havebla sistemo.
>> Kaj la tria punkto estas kio ni nomas dispartigo toleremo.
BONE?
Dispartigo toleremo rimedoj ke la sistemo bone funkcias
malgraŭ fizika reto dispartigas inter la nodoj.
BONE?
Do nodoj en la areto ne povas konversaciadis, kio okazas?
Bone.
>> Do interrilataj datumbazoj choose-- vi povas elekti du el tiuj.
BONE.
Do interrilataj datumbazoj elekti esti konsekvenca kaj havebla.
Se la subdisko okazas inter la DataNodes en la magazeno de datumoj,
datumbazaj kraŝas.
Dekstra?
Ĝi simple iras malsupren.
BONE.
>> Kaj tio estas kial ili havas kreski kun pli grandaj skatoloj.
Dekstra?
Ĉar estas no-- kutime, grapolo datumbazo, ne estas tre multaj el ili
kiuj operacias tiel.
Sed plej datumbazoj skali vertikale ene ununura skatolo.
Ĉar ili bezonas esti konsekvenca kaj havebla.
Se subdisko estis esti injektita, tiam vi devus fari elekton.
Vi devos fari elekton inter esti konsekvenca kaj havebla.
>> Kaj tion NoSQL datumbazoj fari.
Bone.
Do NoSQL datumbazo, ĝi venas en du gustoj.
Ni have-- nu, venas en multaj gustoj,
sed ĝi venas kun du bazaj characteristics-- kio
nomus CP datumbazo, aŭ konsekvenca kaj dispartigo toleremo
sistemo.
Tiuj uloj faras la elekton ke kiam la nodoj perdi kontakton kun unu la alian,
ni ne tuj permesos al personoj skribi plu.
BONE?
>> Ĝis tiu dispartigo estas forigita, registran rajton estas blokita.
Tio signifas ke ili estas ne havebla.
Ili estas konsekvenca.
Kiam ni vidas ke dispartigo injekti sin,
ni estas nun kohera, ĉar ni ne tuj
permesi la datumoj ŝanĝo sur du flankoj de la vando sendepende
de ĉiu alia.
Ni devos restarigi komunikado
antaŭ ajna ĝisdatigo la datumoj estas permesita.
BONE?
>> La sekva gusto estus AP sistemo, aŭ disponeblaj kaj dispartigis
toleremo sistemo.
Tiuj uloj ne zorgas.
Dekstra?
Ajna nodo kiu ricevas skribi, ni prenos ĝin.
Do mi repliki miaj datumoj trans multoblaj nodoj.
Tiuj nodoj akiri kliento, kliento venas en, diras, mi tuj skribos iuj datumoj.
Nodo diras, neniu problemo.
La nodo apud li ricevas skribo sur la sama disko,
li tuj diros neniu problemo.
Ie reen sur la dorso fino, ke datumoj tuj repliki.
Kaj tiam iu tuj rimarkas, uh-oh, ili sistemon konstatos, uh-oh,
tie jam ĝisdatigon al du flankoj.
Kion ni faru?
Kaj kion ili faros estas ili faras ion, kio
permesas al ili decidu, ke datumoj stato.
Kaj ni parolos pri ke en la sekva diagramo.
>> Aĵo atentigi ĉi tie.
Kaj mi ne ricevos tro multe en tiun, ĉar tiu
ekhavas profundan datumoj teorio.
Sed estas transaccional kadro kiu
kuroj en interrilata sistemo kiu permesas min sekure fari ĝisdatigojn
al multoblaj unuoj en la datumbazo.
Kaj tiuj ĝisdatigoj okazos ĉiuj samtempe aŭ ne.
Kaj tio nomiĝas ACID transakcioj.
BONE?
>> ACID donas nin atomicidad, consistencia, izolado, kaj fortikeco.
BONE?
Tio signifas atoma, transakcioj, ĉiuj miaj ĝisdatigoj aŭ okazi aŭ ne.
Konsistenco signifas ke la datumaron ĉiam
enkondukota en konsekvenca stato post ĝisdatigo.
Mi ne foriros de la datumbazo per malbona stato post apliki ĝisdatigon.
BONE?
>> Do ĝi estas iom malsama ol CAP consistencia.
CAP konsistenco signifas mia tuta klientoj ĉiam povas vidi la datumojn.
ACID konsistenco signifas ke kiam transakcio estas farita, datumoj estas bonaj.
Miaj interrilatoj estas tute bona.
Mi ne tuj forviŝi gepatro vico kaj lasos faskon de orfo infanoj
en iu alia tablo.
Ĝi ne povas okazi se mi estas konsekvenca en acida transakcio.
>> Izolado signifas ke transakcioj ĉiam okazas unu post la alia.
La fina rezulto de la datumoj estos la sama stato
kvazaŭ tiuj transakcioj kiuj emisiis samtempe
estis ekzekutitaj serially.
Do estas samtempeco kontrolo en la datumbazo.
Do resume, mi ne povas pliigo la sama valoro dufoje kun du operacioj.
>> Sed se mi diras aldoni 1 al tiu valoro, kaj du transakcioj enveni
kaj provu fari ĝin, oni estas tuj akiri tie unue
kaj la aliaj onian tuj ricevas tie post.
Do en la fino, mi aldonis du.
Vi vidas kion mi volas diri?
BONE.
>> Fortikeco estas bela simpla.
Kiam la transakcio estas agnoskita, ĝi estas
tuj estos tie eĉ se la sistemo kraŝas.
Kiam tiu sistemo rekuperas, ke transakcio kiu estis farita
fakte tuj estos tie.
Do jen la garantiojn de ACID transakcioj.
Tiuj estas sufiĉe bela garantiojn havi sur datumbazo,
sed ili venas en tiu kosto.
Dekstra?
>> Ĉar la problemo kun tiu kadro estas
se estas subdisko en la datumoj aro, mi devas fari decidon.
Mi tuj devas permesi ĝisdatigoj sur unu flanko aŭ la alia.
Kaj se tio okazas, tiam mi ne plu iras
povi subteni tiuj karakterizaĵoj.
Ili ne estos kohera.
Ili ne estos izolita.
Jen kie rompiĝas por rilata datumbazoj.
Tiu estas la kialo interrilata datumbazoj grimpi vertikale.
>> Aliflanke, ni havas kio nomiĝas BAZO teknologio.
Jen estas via NoSQL Databases.
Bone.
Do ni havas nian CP, AP datumbazoj.
Kaj jen estas, kion vi nomas esence disponebla, mola stato, eventuale
konsekvenca.
BONE?
>> Esence disponebla, ĉar ili estas subdisko tolerema.
Ili ĉiam estos tie, eĉ se estas
reto subdisko inter la nodoj.
Se mi povas paroli al nodo, mi estas tuj povos legi datumoj.
BONE?
Mi eble ne ĉiam povos skribi datumo se mi estas konsekvenca platformo.
Sed mi povos legi datumoj.
>> La mola stato indikas ke kiam mi legis ke datumoj,
ĝi povus ne esti la sama kiel aliaj nodoj.
Se dekstra estis emisiita sur nodo aliloken en la areto
kaj ne reproduktita trans la grapolo tamen kiam mi legas ke datumoj,
tiu stato ne povus esti konsekvenca.
Tamen, estos eventuale kohera,
signifante ke kiam registran estas farita al la sistemo,
ĝi repliki trans la nodoj.
Kaj fine, tiu stato estos alportita en ordo,
kaj ĝi estos kohera stato.
>> Nun, cap teoremo vere ludas nur en unu kondiĉo.
Ke kondiĉo estas kiam tiu okazas.
Ĉar kiam ajn ĝi estas operaciis en normala reĝimo, ne dispartigo,
ĉio estas konsekvenca kaj havebla.
Vi nur maltrankviligi CAP kiam ni havas tiun dispartigo.
Do tiuj estas maloftaj.
Sed kiel la sistemo reagas kiam tiuj okazas dikti kion tipo de sistemo
ni pritraktas.
>> Do ni rigardu kio kiu similas por AP sistemoj.
BONE?
AP sistemoj venas en du gustoj.
Ili venas en la gusto kiu estas mastro mastro, 100%, ĉiam disponebla.
Kaj ili venis en la alia gusto, kiu diras:
vi scias kion, mi tuj zorgi pri tiu dispartiganta afero
kiam reala subdisko okazas.
Alie, ekzistas okazas esti primara nodoj kiuj tuj prenos la rajtoj.
BONE?
>> Do se ni ion kiel Cassandra.
Cassandra estus majstra sinjoro: Ni min skribi al ajna nodo.
Do kio okazas?
Do mi havas celon en la datumbazo kiu ekzistas sur du nodoj.
Ni nomas ke objekto S. Do ni havas ŝtaton por S.
Ni havas iuj operacioj sur S kiu estas daŭranta.
Cassandra min permesas skribi al multoblaj nodoj.
Do diru min akiras skribi por s al du nodoj.
Nu, kio finas pasante estas ni nomas tion a dispartiganta okazaĵo.
Tie eble ne estas fizika reto dispartigo.
Sed pro la dezajno de la sistemo, ĝi estas
fakte dispartiganta tuj kiel mi ricevas registran sur du nodoj.
Tio ne devigante min skribu ĉiuj tra unu nodo.
Mi skribas sur du nodoj.
BONE?
>> Do nun mi havas du statojn.
BONE?
Kio okazos estas pli aŭ malpli frue,
Tie tuj estos replicación okazaĵo.
Tie tuj estos kio ni nomata subdisko reakiro, kiu
estas kie ĉi tiuj du ŝtatoj revenu kune
kaj tie tuj estos algoritmo kiu kuras ene la datumbazo,
decidas kion fari.
BONE?
Defaŭlte, la lasta ĝisdatigo venkas en plej AP sistemoj.
Do ekzistas kutime defaŭlta algoritmo, kio
ili nomas callback funkcio, iu kiu
estos nomita kiam kondicxo estas detektita ekzekuti iuj logiko
solvi tiu konflikto.
BONE?
La defaŭlta callback kaj defaŭlte Resolver en plej AP datumbazoj
estas, divenu kion, timestamp gajnas.
Tio estis la lasta ĝisdatigo.
Mi tuj metis tiun ĝisdatigon en tie.
Mi povas forĵeti tiun rekordon kiu mi faligis for en reakiro log
tiel ke la uzanto povas reveni poste kaj diri, hej, ekzistis kolizio.
Kio okazis?
Kaj vi povas reale dump priskribu ĉiuj kolizioj kaj la rollbacks
kaj vidu kio okazas.
>> Nun, kiel uzanto, vi povas ankaŭ inkluzivas logiko en tiun callback.
Do vi povas ŝanĝi tion callback operacio.
Vi povas diri, hej, mi volas al remediate tiu datumo.
Kaj mi volas provi kaj kunfandi tiujn du registroj.
Sed tio estas ĝis vi.
La datumbazo ne scipovas fari tion defaŭlte. Plej la tempo,
La nura afero la datumbazo scias fari estas diri,
ĉi tiu estis la lasta rekordo.
Tio estas la unu kiu estas iranta gajni, kaj tio estas la valoro mi tuj metis.
Unufoje ke dispartigo reakiro kaj replicación okazas,
ni havos niajn stato, kiun nun S primo, kiu estas
la merge stato de ĉiuj tiuj objektoj.
Do AP sistemoj havas tiun.
CP sistemoj ne bezonas zorgi pri tio.
Ĉar kiam subdisko venas en ludon, ili nur ĉesas preni
skribas.
BONE?
Do jen tre facila trakti esti konsekvenca
kiam vi ne akceptas ajnan ĝisdatigojn.
Jen kun CP sistemoj fari.
Bone.
>> Do ni parolu iom bita pri aliro ŝablonoj.
Kiam ni parolas pri NoSQL, estas ĉion pri la aliro ŝablono.
Nun, SQL estas ad hoc, mendoj.
Ĝi estas rilata vendejo.
Ni ne devas maltrankviligi pri la aliro ŝablono.
Mi skribas tre kompleksa demando.
Ĝi iras kaj alprenas la datumoj.
Tion ĉi aspektas kiel, normaligo.
>> Do en tiu speciala strukturo, ni rigardas produktoj katalogo.
Mi havas malsamajn tipojn de produktoj.
Mi havas librojn.
Mi havas albumoj.
Mi havas filmetoj.
La interrilato inter produktoj kaj iu el tiuj libroj, diskoj,
kaj filmetoj tabloj estas 1: 1.
Bone?
Mi havas produkton ID, kaj ke ID respondas
al libro, albumo, aŭ video.
BONE?
Tio estas 1: 1 rilato trans tiuj tabloj.
>> Nun, books-- ĉiuj ili havas estas radiko propraĵoj.
Nedankinde.
Tio estas granda.
Unu-al-unu rilato, mi akiras ĉiuj la datumo mi bezonas priskribi tiun libron.
Albums-- albumoj havas trakojn.
Jen kion ni nomas unu al multaj.
Ĉiu albumo povus esti multaj trakoj.
Do por ĉiu trako sur la albumo, mi povus havi
alia rekordo en tiu infano tablo.
Do mi kreas unu rekordo en mia albumoj tablo.
Mi kreas multoblajn rekordojn en la aŭtoveturejoj tablo.
Unu-al-multaj rilato.
>> Tiu rilato estas kio ni nomas multaj-al-multaj.
BONE?
Komprenu ke aktoroj povus esti en multaj filmoj, multaj videoj.
Do kion ni faras estas ni metu ĉi surĵeto tablo inter tiuj, kiuj nur
mapoj la aktoro ID al la video ID.
Nun mi povas krei query la krampoj videos tra aktoro video por aktoroj,
kaj donu al mi belan Listo ĉiuj filmoj kaj ĉiuj aktoroj
kiuj estis en tiu filmo.
>> BONE.
Do jen ni iras.
Unu-al-unu estas la pintnivela interrilato; unu-al-multaj,
albumojn al trakojn; multaj-al-multaj.
Tiuj estas la tri pintnivela interrilatoj en ajna datumbazo.
Se vi scias kiel tiuj interrilatoj labori kune,
tiam vi scios multon pri datumbazo jam.
Do NoSQL laboras iom alimaniere.
Ni pensu pri dum sekundo kio rigardojn ŝatas iri akiri ĉiujn miajn produktojn.
>> En rilata vendejo, mi volas akiri ĉiujn miajn produktojn
sur listo de ĉiuj miaj produktoj.
Tio estas multe de demandoj.
Mi akiris query por ĉiuj miaj libroj.
Mi akiris query el miaj albumoj.
Kaj mi ricevis query por ĉiuj miaj filmetoj.
Kaj mi alvenis al meti ŝin ĉiuj kune en lerta
kaj servi lin reen ĝis la apliko kiu estas petanta ĝin.
>> Akiri miajn librojn, mi aliĝi Produktoj kaj Libroj.
Akiri miajn albumojn, mi alvenis al kunigi Produktoj, Albumoj kaj Trakoj.
Kaj akiro miaj filmetoj, mi havas aliĝi Produktoj al Videoj,
aliĝi tra Aktoro Videoj, kaj enportu la Aktoroj.
Do jen tri demandoj.
Tre kompleksa pridemandojn kunvenigi unu rezulto aro.
>> Tio estas malpli ol optimuma.
Jen kial kiam ni parolas pri datumstrukturo tio
konstruita esti agnostikulo al la aliro pattern-- bone ke estas granda.
Kaj vi povas vidi ĉi estas vere bela kiom ni organizas la datumojn.
Kaj vi scias kion?
Mi nur havas unu rekordo por aktoro.
>> Tio estas mojosa.
Mi deduplicated ĉiuj miaj aktoroj, kaj mi subtenis mian asocioj
en tiu mapado tablo.
Tamen, Akiranta la datumoj eksteren iĝas multekosta.
Mi sendas la CPU tuta sistemo aliĝanta tiuj datumstrukturoj kune
povi tiri ke datumoj dorso.
>> Do kiel mi elturniĝi?
En NoSQL temas pri agregación, ne normaligo.
Do ni volas diri ni volas apogi la aliro ŝablono.
Se la aliro mastron al la aplikoj,
Mi bezonos akiri ĉiujn miajn produktojn.
Ni metu ĉiujn produktojn en la sama tablo.
Se mi metis ĉiujn produktojn en la sama tablo, Mi povas nur elekti ĉiuj produktoj
de tiu tablo kaj mi akiras ĉion.
Nu kiel mi faru tion?
Nu en NoSQL estas nenia strukturon al la tablo.
Ni parolos iomete pri kiel tio funkcias en Dinamo DB.
Sed vi ne havas la saman atributoj kaj la samaj propraĵoj
en ĉiu unuopa vico, en ĉiu unuopa ero, kiel vi faras en SQL tablo.
Kaj kion tio permesas min fari estas multaj aferoj
kaj donu al mi multan flekseblecon.
En ĉi tiu aparta kazo, mi havas mian produkton dokumentoj.
Kaj en ĉi tiu aparta Ekzemple, ĉiu
estas dokumento en la Produktoj tablo.
Kaj la produkto por libro eble havi tipon ID kiu specifas libron.
Kaj la aplikaĵo estus enŝaltu ke ID.
>> Ĉe la apliko tier, mi tuj diri ho, kia rekordo tipo estas tio?
Ho, ĝi estas libro rekordo.
Libro rekordoj havas tiujn trajtojn.
Lasu min krei libron objekto.
Do mi tuj plenigos la libro objekton kun tiu ero.
Sekva ero venas kaj diras, kio estas tio eron?
Nu ĉi artikolo estas albumo.
Ho, mi ricevis tutajn malsamajn prilaborado rutinon por ke,
ĉar ĝi estas albumo.
Vi vidas kion mi volas diri?
>> Do la apliko tier-- mi simple elektu cxiujn tiujn rekordojn.
Ili ĉiuj komenci venon.
Ili povus esti ĉiuj malsamaj tipoj.
Kaj ĝi estas la apliko de logiko ke ŝanĝas trans tiuj tipoj
kaj decidas kiel prilabori ilin.
>> Denove, tiel ni optimizando la skemo por la aliro ŝablono.
Ni faras tion per kolapsado tiuj tabloj.
Ni esence prenante tiuj ununormigita strukturoj,
kaj ni konstruas hierarkia strukturo.
Ene de ĉiu el ĉi tiuj rekordoj Mi tuj vidu tabelo propraĵoj.
>> Ene de tiu dokumento por Albumoj, Mi vidas arrays de aŭtoveturejoj.
Tiuj temoj nun become-- estas esence tiu infano tablo ke
ekzistas ĉi tie en ĉi tiu strukturo.
Do vi povas fari tion en DynamoDB.
Vi povas fari tion en MongoDB.
Vi povas fari tion en ajna NoSQL datumbazo.
Krei tiuj tipoj de hierarkia datumstrukturoj
kiuj permesas al vi elsxuti datumoj tre rapide ĉar nun mi
ne devas konformiĝi.
Kiam mi enmeti vico en la Trakoj tablo, aŭ vico en la Albumoj tablo
Mi devas konformiĝi al tiu skemo.
Mi devas havi la atributon aŭ la proprieto kiu estas difinita sur tiu tablo.
Cxiu de ili, kiam mi enmeti tiu vico.
Tio ne estas la kazo en NoSQL.
>> Mi povas havi plene malsama propraĵoj en ĉiu dokumenton
ke mi enmeti en la kolekto.
Do tre potenca mekanismo.
Kaj estas vere kiel vi optimizar la sistemo.
Ĉar nun ke query, anstataŭ de aliĝado ĉiuj tiuj tabloj
kaj ekzekutante duono dekduo demandoj tiri reen la datumojn mi bezonas,
Mi efektiviganta unu mendo.
Kaj mi ripetanta trans la rezultoj starigis.
ĝi donas al vi ideon de la potenco de NoSQL.
Mi tuj speco de iri flanken tie kaj paroli iomete pri tio.
Ĉi tio estas pli afabla el la marketing aŭ technology--
la merkatiko de teknologio tipo de diskuto.
Sed estas grave kompreni ĉar se ni rigardas la pinto
tie ĉe tiu diagramo, kion ni rigardis
estas kion ni nomas la teknologio tamburego kurbo.
Kaj kion tio signifas estas novaj aĵoj venas en ludon.
Homoj kredas ke estas granda.
Mi jam solvis ĉiujn miajn problemojn.
>> Tio povus esti la fino ĉiuj, estu ĉiuj al ĉio.
Kaj ili ekuzi ĝin.
Kaj ili diras, ĉi stuff ne funkcias.
Tio ne pravas.
La ruzaĵojn estis bona.
Kaj superas al faras aferojn la vojo ili estis.
Kaj tiam poste ili iras, vi scias kion?
Ĉi tiujn aferojn estas ne tiom malbona.
Ho, jen kiel ĝi funkcias.
Kaj unufoje ili elkompreni kiel verkoj, ili komencas akiranta pli bonan.
>> Kaj la amuza afero pri ĝi estas, speco de regiono al kio
ni nomas la Teknologio Adopto Kurbo.
Do kio okazas estas ni havas ia teknologio ellasilon.
En la kazo de datumbazoj, ĝi estas datumoj premo.
Ni parolis pri la alta akvo punktoj de datumoj premo tra tempo.
Kiam ke datumoj premo trafas certaj punkto, tio estas teknologio ellasilon.
>> Ĝi Fariĝas tro multekostaj.
Ĝi prenas tro longa por procesi la datumojn.
Ni bezonas ion pli bonan.
Vi ricevas la pioniraj tie ekstere kurante ĉirkaŭe,
provante elŝeligi kio estas la solvo.
Kio estas nova ideo?
>> Kio estas la sekva plej bona maniero agi tiel?
Kaj ili venas supre kun io.
Kaj la popolo kun la reala doloro, la infanoj de la sanganta rando,
ili devos salti ĉiuj super ĝi, ĉar ili bezonas respondon.
Nun kio neeviteble happens-- kaj ĝi okazas nun en NoSQL.
Mi vidas la tutan tempon.
>> Kio neeviteble okazas estas personoj ekuzi la nova ilo
sammaniere oni uzis la malnovan ilon.
Kaj ili trovis inter ĝi ne funkcias tiel bone.
Mi ne memoras kiu mi estis parolante al antaŭe hodiaŭ.
Sed estas kiel, kiam la Jackhammer estis inventita,
personoj ne svingi ĝin super ilia kapo frakasi la betono.
>> Sed tio kio estas okazanta kun NoSQL hodiaŭ.
Se vi iras por plej butikoj, ili klopodas esti NoSQL butikoj.
Kion ili faras estas ili estas uzanta NoSQL,
kaj ili estas tio ŝargado plena de interrilata schema.
Ĉar tio estas kiel ili desegni datumbazoj.
Kaj ili scivolas, kial estas ĝi ne elfaranta tre bone?
Knabo, tiu afero fetoras.
Mi devis subteni ĉiujn miajn kunigas in-- estas kvazaŭ, ne, ne.
Subteni kunigas?
Kial vi aliĝado datumoj?
Vi ne aliĝi datumoj en NoSQL.
Vi aldonas ĝin.
>> Do se vi volas eviti tion, lerni kiom la ilo laboras antaŭ vi reale
ekuzi ĝin.
Ne provu kaj uzi la novajn ilojn la sama maniero vi uzis la malnovajn ilojn.
Vi tuj havas malbonan sperton.
Kaj ĉiu ununura tempo Tion ĉi estas proksimume.
Kiam ni komencas venanta supre ĉi tie, ĝi estas ĉar homoj eltrovis
kiel uzi la ilojn.
>> Ili faris la saman aĵon kiam interrilata datumbazoj estis inventita,
kaj ili anstataŭante dosiersistemojn.
Ili provis konstrui dosiersistemojn kun rilata datumbazoj
ĉar tio estas kion homoj komprenas.
Ĝi ne funkciis.
Do komprenanta la bonaj praktikoj de la teknologio vi laboras kun
estas grandega.
Tre grava.
>> Do ni tuj eniri DynamoDB.
DynamoDB estas AWS La plene sukcesis NoSQL platformo.
Kion plene sukcesis signifas?
Ĝi signifas ke vi ne bezonas vere maltrankvili pri io ajn.
>> Vi eniras, vi diru ni, mi bezonas tablon.
Ĝi bezonas multe ĉi kapablo.
Vi trafis la butonon, kaj ni provizo tuta infrastrukturo malantaŭ la sceno.
Nun ke estas enorma.
>> Ĉar kiam vi parolas pri krustanta datumbazon,
NoSQL datumoj aretoj ĉe skalo, kurado petabytes,
kurante milionojn da transakcioj je sekundo,
tiuj aferoj ne estas malgrandaj amasoj.
Ni parolas miloj da petskriboj.
Administranta miloj da kazoj, eĉ virtuala petskribojn,
estas reela doloro en la pugo.
Mi volas diri, pensi pri ĉiufoje oni operaciumo diakilo eliras
aŭ nova versio de la datumbazo.
Kion tio signifas al vi funkcie?
Tio signifas ke vi akiris 1,200 serviloj kiuj bezonas esti ĝisdatigita.
Nun eĉ kun aŭtomatigo, kiu povas preni longan tempon.
Tio povas kaŭzi multajn operacia kapdoloroj,
ĉar mi havu servoj suben.
>> Kiel mi ĝisdatigos tiuj datumbazoj, mi plenumadu blua verda deplojoj
Kie mi deploji kaj altgradigi duono mia nodoj, kaj tiam ĝisdatigi la alian duonon.
Prenu tiujn malsupren.
Do administranta la infrastrukturon skalo estas ege doloraj.
Kaj AWS preni tiun doloron el ĝi.
Kaj NoSQL datumbazoj povas eksterordinare dolora
pro la maniero ili grimpi.
>> Grimpi horizontale.
Se vi deziras akiri pli grandan NoSQL datenbazo, vi aĉetas pli nodoj.
Ĉiu nodo vi aĉetas estas alia operacia kapdoloron.
Do iu alia faros tion por vi.
AWS povas fari tion.
>> Ni apogas dokumenton ŝlosilo valoroj.
Nun ni ne iru tro multe en aliflanke diagramo.
Ekzistas multe da malsamaj gustoj de NoSQL.
Ili estas ĉiaj atingi munged kune ĉe tiu punkto.
Vi povas rigardi DynamoDB kaj diri jes, ni ambaŭ dokumenton kaj ŝlosila valoro
stoki tiu punkto.
Kaj vi povas argumenti la trajtoj de unu super la alia.
Al mi, multe da tio vere ses de unu duono dekduo de la alia.
Ĉiu el tiuj teknologioj estas delikatan teknologion kaj monpuno solvo.
Mi ne dirus MongoDB estas bona aŭ malbona ol Couch, tiam Cassandra,
tiam Dinamo, aŭ inverse.
Mi volas diri, jen nur ebloj.
>> Ĝi estas rapida kaj ĝi estas konsekvenca en ajna skalo.
Do ĉi tiu estas unu el la plej grandaj gratifikoj vi akiras kun AWS.
Kun DynamoDB estas la kapablo akiri malaltan sola cifero
milisegundo latencia en ajna skalo.
Ke estis dezajno celo de la sistemo.
Kaj ni havas klientoj kiuj faras milionoj da transakcioj je sekundo.
>> Nun mi iros tra kelkaj el tiuj Uzkazoj post kelkaj minutoj tie.
Integrita aliro control-- ni havas, kion ni nomas
Identeco Aliro Management, aŭ IAM.
Ĝi trapenetras ĉiun sistemon, ĉiu servo kiu proponas AWS.
DynamoDB estas neniu escepto.
Vi povas kontroli la aliron al la DynamoDB tabloj.
Tra ĉiuj viaj kontoj AWS per difinanta aliro rolojn kaj permesoj
en la IAM infrastrukturo.
>> Kaj ĝi estas kerna kaj integra komponanto en kion ni nomas Event Driven Programado.
Nun tiu estas nova paradigmo.
>> Publiko: Kiel fartas via imposto de veraj pozitivaj kontre falsaj negativoj
sur via aliro kontrolo sistemo?
RICK Houlihan: Vera pozitivaĵoj kontre falsaj negativaj?
Publiko: Revenante kio vi devas reveni?
Kontraste al tempaltempe ĝi ne redonas kiam devus validigi?
>> RICK Houlihan: Mi ne povus diri al vi ke.
Se estas neniu fiaskoj whatsoever sur tio,
Mi ne estas la persono por demandi tiu aparta demando.
Sed tio estas bona demando.
Mi estus scivola scii ke mi mem, reale.
>> Kaj tiel do denove, nova paradigmo estas okazaĵo movita programado.
Tio estas la ideo ke vi povas deploji kompleksaj aplikoj kiuj
povas funkcii tre, tre alta skalo sen infrastrukturo whatsoever.
Sen ajna fiksa infrastrukturo whatsoever.
Kaj ni parolos iomete pri kio tio signifas, kiel ni
eniri la sekva paro de mapoj.
>> La unua afero ni faros Estas ni parolos pri tabloj.
API datumtipoj por Dinamo.
Kaj la unua afero vi instruos vin rimarkos kiam vi rigardas tiun,
se vi estas familiara kun ajna datumbazo, datumbazoj havas vere du speco de APIs
Mi nomus ĝin.
Aŭ du aroj de API.
Unu el tiuj estus administra API.
>> La aferoj ili prizorgi la funkcioj de la datumbazo.
Agordi la stokado motoron, alĝustigo kaj aldonante tabloj.
kreo de datumbazo katalogoj kaj petskriboj.
Tiuj things-- en DynamoDB, vi havas tre mallongajn, triopoj.
>> Do en aliaj datumbazoj, vi eble vidos dekojn
de komandas, de administra komandojn, por agordi
tiuj pliaj ebloj.
En DynamoDB vi ne bezonas tiujn ĉar vi ne agordi la sistemon, ni faros.
Do la nura afero vi devas fari estas diru al mi kio grandeco tablo mi bezonas.
Do vi ricevas tre limigita aro da ordonoj.
>> Vi ricevas Krei Tablo Ĝisdatigo, Tablo, Forigi Tablo kaj priskribu Tablo.
Tiuj estas la nuraj aĵoj vi bezonas por DynamoDB.
Vi ne bezonas stokadon motoro konfiguro.
Mi ne bezonas zorgi pri replicación.
Mi ne bezonas zorgi pri sharding.
>> Mi ne bezonas zorgi pri iu ajn el ĉi aĵoj.
Ni faros ĉion por vi.
Do tio estas grandega kvanto de superkape Tio simple levis vian teleron.
Sekvas la stranga materio operatoroj.
Stranga materio estas io kion ni voki en datumbazo tio
Krei, Ĝisdatigo, Delete operatoroj.
Tiuj estas viaj komunaj operacion.
Aĵoj kiel metita ero, akiri eron, ĝisdatigo erojn, forigi elementojn, batch query, skani.
Se vi volas skani la tuta tablo.
Tiri ĉiu de la tablo.
Unu de la belaj aferoj pri DynamoDB estas ĝi permesas paralela escanear.
Do vi efektive povas sciigi min kiom da fadenoj vi volas kuri en tiu skanado.
Kaj ni povas kuri tiuj fadenoj.
Ni povas ŝpini ke scan supren trans multoblaj fadenoj
tiel vi povas skani la tuta tablo spaco tre, tre rapide en DynamoDB.
>> La aliaj API ni havas estas kion ni nomas nia Rojoj API.
Ni ne tuj paroli tro multe pri ĉi tiu momento.
Mi havas iun enhavon poste sur la ferdeko pri tio.
Sed Rojoj estas vere running-- rigardante ĝin kiel la tempo ordigitaj
kaj dispartigo ŝanĝo log.
Ĉio okazas sur la tablo aperas sur la rivereto.
>> Ĉiu skribu al la tablo Aperas sur la rivereto.
Vi povas legi tiun rivereton, kaj vi povas fari aferojn kun ĝi.
Ni parolos pri kia tipoj de aferoj vi
fari kun la aĵoj kiel replicación, kreanta malĉefa indeksoj.
Ĉiaj vere malvarmeta aĵoj vi povas fari kun tio.
>> Datumtipoj.
En DynamoDB ni subtenas ambaŭ ŝlosilo valoro kaj dokumenti datumtipoj.
Sur la maldekstra flanko de la ekrano tie, ni havas niajn bazajn tipojn.
Ŝlosilo valoro tipoj.
Tiuj estas ŝnuroj, nombroj, kaj binaroj.
>> Do nur tri bazaj tipoj.
Kaj tiam vi povas havi arojn de tiuj.
Unu de la belaj aferoj pri NoSQL estas vi povas enhavi arrays kiel propraĵoj.
Kaj kun DynamoDB povas enhavi tabeloj de bazaj tipoj kiel radiko proprieto.
>> Kaj tiam ekzistas la dokumenton tipoj.
Kiom da homoj estas familiara kun JSON?
Vi uloj familiara kun JSON tiel?
Ĝi estas esence Ĝavoskripto, Objekto, Skribmaniero.
Ĝi permesas esence difini hierarkia strukturo.
>> Vi povas stoki JSON dokumenton sur DynamoDB uzante komunaj komponantoj
aŭ konstruelementoj kiuj haveblas en plej programlingvoj.
Do se vi havas Java, vi estas rigardante mapoj kaj lertaj.
Mi povas krei objektojn kiuj areon mapo.
A mapo kiel kernaj valoroj stokitaj kiel propraĵoj.
Kaj ĝi povus havi listoj de valoroj ene de tiuj posedaĵoj.
Vi povas stoki ĉi komplekso hierarkia strukturo
kiel ununura atributo de DynamoDB eron.
>> Do tabloj en DynamoDB, kiel plej NoSQL datumbazoj, tabloj havas erojn.
En MongoDB vi farus nomas tiujn dokumentojn.
Kaj estus la kanapo bazo.
Ankaŭ dokumenton datumbazo.
Vi nomas tiujn dokumentojn.
Dokumentoj aŭ erojn havas atributojn.
Atributoj povas ekzisti aŭ ne ekzistas sur la eron.
En DynamoDB, ekzistas unu deviga atributo.
Nur ŝatas en rilata datumbazo, vi havas primara ŝlosilo sur la tablo.
>> DynamoDB havas, kion ni nomas hash ŝlosilo.
Hash ŝlosilo devas esti unika.
Do kiam mi difini hash tablo, esence kion mi diras
estas cxiu menuero devos hash ŝlosilo.
CXia hash ŝlosilo devas esti unika.
>> Ĉiu ero estas difinita per tiu sola hash ŝlosilo.
Kaj tie povas esti nur unu.
Tio estas okej, sed ofte kion homoj bezonas
Estas ili volas estas tiu hash ŝlosilo por fari iomete pli
ol nur esti unika identigilo.
Ofte ni volas uzi tiun hash ŝlosilo kiel la pinta nivelo agregación sitelo.
Kaj la vojo ni fari tion estas per aldonante kion ni nomas vicon ŝlosilo.
>> Do se ĝi estas hash nur tablo, tiu devas esti unika.
Se ĝi estas hash kaj gamo tablo, la kombino de la hash kaj la gamo
devas esti unika.
Do pensu pri tio ĉi vojo.
Se mi havas forumon.
Kaj la formo havas temojn, ĝi havas afiŝoj, kaj ĝi havas respondojn.
>> Do mi havu hash ŝlosilo, kiu estas la temo ID.
Kaj mi povus havi gamon ŝlosilo, kiu estas la respondo ID.
KE vojo se mi volas ricevi ĉiujn respondojn por aparta temo,
Mi povas nur konsulti la hash.
Mi povas nur diri al mi ĉion la erojn, kiuj havas tiun hash.
Kaj mi tuj instigi cxiun demandon aŭ afiŝi por tiu aparta temo.
Tiuj supro nivelo agregaciones estas tre gravaj.
Ili apogas la primara aliro desegnon de la apliko.
Ĝenerale parolante, tiu kion ni volas fari.
Ni volas ke table-- kiel vi ŝarĝi la tablo,
ni volas strukturi la datumoj ene la tablo tiel
ke la apliko povas tre rapide elsxuti tiujn rezultojn.
Kaj ofte la maniero fari tion estas subteni tiujn agregaciones kiel ni
enmeti la datumojn.
Esence, ni diskonigi la datumoj en la helan sitelo kiel ĝi envenas.
>> Gamo klavoj permesas kunulinon hash klavoj devas esti egaleco.
Kiam mi konsulti hash, mi devas diri donu al mi hash kiu egalas ĉi.
Kiam mi konsulti gamo, Mi povas diri al mi vicon
kiu uzas ian riĉa operatoro kiun ni apogas.
Donu ĉiujn erojn por hash.
Ĉu egala, pli granda ol, malpli ol, faras ĝi komenci,
Ĉu ĝi ekzistas inter tiuj du valoroj?
Tiuj tipoj de gamo demandoj ke ni estas ĉiam interesita en.
Nun unu afero pri datumoj, kiam vi rigardas aliranta datumon, kiam
vi aliri la datumojn, ĝi estas ĉiam pri kungregigxinte.
Ĉiam pri la rekordojn ke estas rilatigitaj kun ĉi tiu.
Donu al mi ĉion tie that's-- ĉiuj la transakcioj sur ĉi kreditkarto
por la lasta monato.
Tio kungregigxinte.
>> Preskaŭ ĉio vi faras en la datumbazo estas ia agregaĵo.
Do povante povi difini tiuj rubujoj kaj doni al vi tiujn gamo
ecoj por povi konsulti sur, tiuj riĉaj demandoj subteni multajn,
multaj, multaj apliko aliro ŝablonoj.
>> Do la alia afero la hash ŝlosilo faras estas ĝi donas al ni meĥanismo
por povi disvastigi la datumoj ĉirkaŭ.
NoSQL datumbazoj funkcias plej kiam la datumoj estas egale
distribuis trans la areto.
Kiom da homoj estas familiara kun hashing algoritmoj?
Kiam mi diras hash kaj hashing-- ĉar Regionoj algoritmo
Estas maniero de povi generi hazarda valoro de iu antaŭfiksita valoro.
Do en ĉi tiu aparta kazo, la hash algoritmo ni kuras estas ND 5 bazita.
>> Kaj se mi havas ID kaj ĉi Estas mia hash ŝlosilon, mi havas 1, 2, 3.
Kiam mi kuras la hash algoritmo, ĝi tuj revenos kaj diros:
bone 1 egalas 7B, 2 egalas 48, 3 egalas KD.
Ili disvastiĝis tra la tuta ŝlosilo spaco.
Kaj kial vi faru tion?
Ĉar kiu certigas ke mi povas metis la rekordojn trans multoblaj nodoj.
>> Se mi faras tiun incrementally, 1, 2, 3.
Kaj mi havas hash gamo kiu kuroj en ĉi tiu aparta kazo,
malgranda krada spaco, ĝi kuras de 00 al FF,
tiam la rekordojn tuj enveni kaj ili tuj iru 1, 2, 3, 4, 5,
6, 7, 8, 9, 10, 11, 12.
Kio okazas?
Ĉiu insert tuj la sama nodo.
Vi vidas kion mi volas diri?
>> Ĉar kiam mi disiĝis la spaco, kaj Mi etendis tiujn rekordojn trans,
kaj mi vandon, mi tuj diros dispartigo 1 havas ŝlosilon spaco 0 al 54.
Dispartigo 2 estas 55 al 89.
Dispartigo 3 estas AA al ff.
Do se mi uzas lineare pliigante IDs, vi povas vidi kio okazas.
1, 2, 3, 4, 5, 6, ĉiuj vojo ĝis 54.
Do kiel mi martelante la rekordojn en la sistemo,
ĉiu finas tuj unu nodo.
>> Tio ne bona.
Tio estas antipattern.
En MongoDB ili havas tiun problemon se vi ne uzas hash ŝlosilo.
MongoDB donas al vi la eblon de hashing la ŝlosilo valoro.
Vi devas ĉiam fari tion, se vi uzas pliigante hash
ŝlosilo en MongoDB, aŭ vi estos najlante ĉiu skribu al unu nodon,
kaj vi estos limitante via skribi traigivo malbone.
>> Spektantaro: Ĉu Al9 169 en dekuma?
>> RICK Houlihan: Jes, ĝi estas ie ĉirkaŭe.
Al9, mi ne scias.
Vi devus ricevi mia duuma al dekuma kalkulilo.
Mia cerbo ne funkcias tiel.
Spektantaro: Nur rapida unu de via Mongo komentoj.
Tia estas la objekto ID kiu venas denaske kun Mongo fari tion?
RICK Houlihan: Ĉu ĝi farus tion?
Se vi specifas ĝin.
Kun MongoDB, vi havas la eblon.
Vi povas specify-- ĉiu dokumento en MongoDB devas havi substreko ID.
Tio estas la unika valoro.
>> En MongoDB vi povas entajpi ĉu hash aŭ ne.
Ili simple donis al vi la eblon.
Se vi scias ke ĝi estas hazarda, neniu problemo.
Vi ne bezonas fari tion.
Se vi scias, ke ĝi ne estas hazardo, ke ĝi estas pliigante, tiam faru la hash.
>> Nun la afero pri hashing, iam vi hash
a value-- kaj tiu estas kial hash ŝlosiloj estas ĉiam
solaj demandoj, ĉar mi ŝanĝis la valoro, nun mi ne povas fari vicon mendo.
Mi ne povas diri estas ĉi inter tio aux,
ĉar la hash valoro ne tuj esti ekvivalenta al la reala valoro.
Do kiam vi hash ke ŝlosilo, ĝi estas egaleco nur.
Jen kial en DynamoDB hash ŝlosilo demandoj estas ĉiam egaleco nur.
>> Do nun en gamo key-- kiam mi aldonas ke gamo ŝlosilo,
tiuj gamo klavo rekordojn ĉiuj enveni kaj ili akiras entenita sur la sama dispartigo.
Do, ili estas tre rapide, facile retrieved ĉar tiu estas la hash,
tio estas la gamo.
Kaj vi vidas ĉion kun la sama hash
gets stokitaj en la sama subdisko spaco.
Vi povas uzi tiun gamon ŝlosilo por helpi lokalizi viajn datumojn proksime al lia patro.
Do kion mi vere faras ĉi tie?
Jen unu al multaj rilato.
La interrilato inter hash ŝlosilo kaj la gamo-klavo unu al multaj.
Mi povas havi multoblajn hash klavoj.
Mi povas nur havi multoblajn gamo ŝlosilojn ene ĉiu krada ŝlosilo.
>> La hash difinas la gepatro, la gamo difinas la infanoj.
Do vi povas vidi ke estas analoga tie inter la rilata konstrukcio
kaj la samajn tipojn de konstruas en NoSQL.
Homoj parolas pri NoSQL kiel nonrelational.
Ne nonrelational.
Datumoj ĉiam havas interrilatojn.
Tiuj rilatoj ĵus modelan malsame.
Ni parolu iomete bita pri fortikeco.
Kiam vi skribas al DynamoDB, skribas ĉiam triopa multobliĝas.
Signifanta ke ni havas tri AZ a.
AZ informojn estas Havebleco Zonoj.
Vi povas pensi pri Havebleco Zono kiel datumoj centro
aŭ kolekton de datumoj centroj.
Tiuj aferoj estas geografie izolitaj unuj de aliaj
trans malsamaj kulpo zonoj, trans malsamaj potenco kradoj kaj inundebenaĵoj.
Misfunkciado en unu AZ ne tuj prenonta alian.
Ili estas ankaŭ ligita kune kun malhela fibro.
Ĝi apogas unu sub- 1 milisegundo latencia inter AZS.
Do reala tempo datumoj replications hábil en mult AZS.
>> Kaj ofte multi AZ deplojoj renkonti la alta disponibilidad postuloj
de plej dungistaj organizoj.
Do DynamoDB sternigxos trans tri AZS defaŭlte.
Ni nur tuj scio la registran kiam du el tiuj tri nodoj revenos
kaj diru: Jes, mi havas ĝin.
Kial estas tio?
Ĉar sur la legado flanko ni estas nur tuj donos al vi la datumojn reen kiam
ni akiru ĝin el du nodoj.
>> Se mi repliki trans tri, kaj mi legas el du,
Mi ĉiam garantiita havi almenaŭ unu
de tiuj legas esti la plej aktualan kopion de datumoj.
Tion faras DynamoDB konsekvenca.
Nun vi povas elekti turni tiuj konsekvenca legas for.
Tiuokaze mi tuj diru, Mi nur legis de unu nodo.
Kaj mi ne povas garantii ĝi tuj esti la plej aktualaj datumoj.
>> Do se skribi estas eniranta, ĝi ne multoblighas tamen,
vi tuj akiri tiun kopion.
Tio estas eventuale konsekvenca legita.
Kaj kion tio estas estas duono la kosto.
Do tiu estas multon pripensindan.
Kiam vi legas el DynamoDB, kaj vi starigi vian legita kapablo
ekzemplerojn, se vi elektas finfine konsekvenca legas, ĝi estas multe pli malmultekosta,
ĝi estas proksimume duono de la kosto.
>> Kaj tiel ĝi savas vin monon.
Sed tio estas via elekto.
Se vi volas konsekvencan legado aŭ oni eventuale konsekvenca legita.
Tio estas io kion vi povas elekti.
>> Ni parolu pri indeksojn.
Do ni menciis ke pinta nivelo agregaĵo.
Ni havas hash klavoj, kaj ni havas gamon klavoj.
Tio bonas.
Kaj tio estas la ĉefa tablo, mi akiris unu hash ŝlosilon, mi akiris unu gamo ŝlosilo.
>> Kion tio signifas?
Mi havas unu atributo kiu mi povas kuri riĉa sercxoj kontraŭ.
Ĝi estas la intervalo ŝlosilo.
La aliaj atributoj sur tiu item-- Mi povas filtri tiujn atributojn.
Sed mi ne povas fari tion kiel, ĝi komencas kun, aŭ superas.
>> Kiel mi faru tion?
Mi kreos indekson.
Ekzistas du tipoj de indeksoj en DynamoDB.
Indico estas vere alia vido de la tablo.
Kaj la loka sekundara indekso.
>> La unua unu ni parolos pri.
Do loka duarangaj estas kunvivis sur la sama dispartigo kiel la datumoj.
Kaj kiel tia, ili estas sur la sama fizika nodo.
Ili estas kion ni nomas konsekvenca.
Signifo, ili konfesos la registran kune kun la tablo.
Kiam la registran envenas, ni skribas per la indekso.
Ni skribu al la tablo, kaj tiam ni agnoskos.
Do jen konsekvencaj.
Iam la registran estis agnoskita de la tablo,
ĝi estas garantiita ke la loka sekundara indekso
havos la saman vizion de datumoj.
Sed kion ili permesas fari estas difini alternativan gamo klavoj.
>> Devas uzi la saman kradon ŝlosilo kiel la primara tablo
ĉar ili ko-lokalizitaj sur la sama vando, kaj ili estas konsekvenca.
Sed mi povas krei indekson kun malsamaj gamo klavoj.
Do ekzemple, se mi havus fabrikanto kiu havis krudan partoj tablo venon.
Kaj krudaj partoj enveni, kaj ili estas agregita per asembleo.
Kaj eble tie estas revokon.
>> Ajna parto kiu estis farita de tiu Fabrikejo de post tiu dato,
Mi bezonas tiri de mia linio.
Mi povas ŝpini indekso ke serĉus,
agregi sur la dato de fabrikado de tiu aparta parto.
Do se mia pinta nivelo tablo estis Jam hashed por fabrikanto,
Eble estis aranĝita sur parto ID, mi povas krei indekson off ke tablo
kiel hashed por fabrikanto kaj gamis sur dato de fabrikado.
Kaj aliflanken mi povus diri, ke io estis fabrikitaj inter tiuj datoj,
Mi bezonas tiri el la linio.
Do jen loka sekundara indekso.
>> Tiuj havas la efekton de limigi viajn hash ŝlosilo spaco.
Ĉar ili kunekzistis sur la sama stokado nodo,
Ili limigi la hash ŝlosilo spaco por 10 gigabajtoj.
DynamoDB, sub la tabloj, estos dispartigo
via tablo ĉiu 10 gigabajtoj.
Kiam vi metos 10 koncertoj de datumoj en ni iri [PHH], kaj ni aldonas alia nodo.
>> Ni ne fendi la LSI trans multaj vandoj.
Ni disiĝis la tablo.
Sed ni ne fendi la LSI.
Do jen io Gravas kompreni
estas se vi faras tre, tre, tre grandaj aldonitaj,
tiam vi tuj estos limigita 10 gigabajtoj sur via LSIs.
>> Se tio estas la kazo, ni povas uzi tutmonda duarangaj.
Tutmondaj duarangaj estas vere alia tablo.
Ekzistas tute ekstere al flanke de via primara tablo.
Kaj ili permesos min trovi tute malsama strukturo.
Do pensu pri ĝi kiel datumo estas estanta insertita en du malsamaj tabloj, strukturita
en du malsamaj manieroj.
>> Mi povas difini tutece malsama hash ŝlosilo.
Mi povas difini tutece malsamaj gamo ŝlosilo.
Kaj mi povas kuri ĉi tute sendepende.
Kiel Efektive, mi havas provizis mia legado kapablo
kaj skribu kapablo por mia tutmonda malĉefa indeksoj
tute sendepende de mia primara tablo.
Se mi difinus ke indekso, mi diras ĝi kiom legi kaj skribi
kapacito ĝi tuj uzos.
>> Kaj ke estas aparta de mia primara tablo.
Nun ambaŭ de la indeksoj permesas nin ne nur difini hash kaj gamo ŝlosilojn,
sed ili permesos nin projekti aldonaj valoroj.
Do se mi volas legi for la indekso, kaj mi volas ricevi iun aron de datumoj,
Mi ne bezonas reiri al la ĉefa tablo akiri la aldonan atributoj.
Mi povas projekti tiuj aldonaj atribuas al la tablo
por apogi la aliro ŝablono.
Mi scias ni probable akiranta en kelkaj vere, really-- akiranta en la trudherboj
tie sur kelkaj de ĉi aĵoj.
Nun mi atingis drivus el tiu.
>> Spektantaro: [inaudible] --table ŝlosilo signifis estis hash?
La originala hash?
Mult-latoj?
>> RICK Houlihan: Jes.
Jes.
La tablo ŝlosilo esence markas reen al la artikolo.
Do indekso estas puntero al la originalo erojn sur la tablon.
Nun vi povas elekti konstrui indekso kiu nur havas la tablo ŝlosilo,
kaj neniu aliaj propraĵoj.
Kaj kial povus mi fari tion?
Nu, eble mi havas tre grandajn erojn.
>> Mi vere nur bezonas scii which-- mia aliro padrono povus diri,
kiu erojn enhavas tiun proprieton?
Ne bezonas resendi la eron.
Mi nur bezonas scii kiu erojn enhavi ĝin.
Do vi povas konstrui indeksojn ke nur havos la tablo ŝlosilo.
>> Sed tio estas unuavice kio indekso en datumbazo estas por.
Ĝi estas por povi rapide identigi kiu registras,
kiuj vicoj, kiuj erojn en la tablo havas
la propraĵoj kiujn mi sercxas.
>> GSIs, do kiel ili laboras?
GSIs esence estas nesinkrona.
La ĝisdatigo venas en la tablon, tablo estas poste nesamtempe ĝisdatigita
ĉiuj viajn GSIs.
Jen kial GSIs estas eventuale konsekvenca.
>> Estas grave noti, ke kiam vi konstruado GSIs,
kaj komprenu vi kreas alia dimensio de aggregation--
nun diru bona ekzemplo tie estas fabrikanto.
Mi kredas ke mi povus esti parolita pri medicina aparato fabrikanto.
Medicina aparato fabrikantoj ofte havas serializada partoj.
La partoj kiuj iras en kokso anstataŭas ĉiuj
havi iom serian numeron sur ilin.
Ili povus havi milionojn kaj milionoj kaj miliardoj da partoj
en ĉiuj mekanismoj kiuj ili sxipo.
Nu, ili bezonas por aldoni sub malsamaj dimensioj, ĉiuj partoj
en asembleo, ĉiuj partoj, faritajn
je certa linio, ĉiuj la partoj kiuj venis
en el certa Fabrikejo je certa dato.
Kaj tiuj aldonitaj kelkfoje leviĝi en la miliardoj.
>> Do mi laboras kun kelkaj el tiuj uloj, kiuj suferas
ĉar ili kreas tiuj ginormous agregaciones
en siaj duarangaj indeksoj.
Ili povus havi krudan partoj tablo, kiu venas kiel hash nur.
Ĉiu parto havas unikan serian numeron.
Mi uzas la seria numero kiel la hash.
Ĝi estas bela.
Mia krudaj datumoj tablo sternigxos ĉiuj trans la ŝlosilo spaco.
Mia [? skribi?] [? ingestión?] estas timinda.
Mi prenas multajn datumojn.
Tiam kion ili faras estas ili krei GSI.
Kaj mi diras, vi scias kion mi bezonas vidi ĉiuj partoj por ĉi tiu fabrikanto.
Nu, subite mi prenante miliardo vicoj,
kaj plenigos ilin sur unu nodon, ĉar kiam
Mi aldonas kiel la Fabrikejo de ID kiel la hash,
kaj parto nombro kiel la gamo, tiam ĉiuj el la subita mi estas
metante miliardo partoj en kio tiu fabrikanto savis min.
>> Tio povas kaŭzi multajn de premo sur la GSI,
denove, ĉar mi martelante unu nodo.
Mi estas metanta ĉiuj tiuj enmetas en unu nodo.
Kaj tio estas vera problema uzo kazo.
Nun, mi havas bonan dezajnon mastron por kiom vi evitas tion.
Kaj tio estas unu el la problemoj ke mi ĉiam laboros kun.
Sed kio okazas, estas la GSI povus ne havas sufiĉan kapablon registran
povi puŝi ĉiuj tiuj vicoj en ununuran nodon.
Kaj kio okazas tiam estas la primaria, la kliento tablo
la primara tablo estos throttled ĉar la GSI ne povas teni supre.
Do mia insert imposto fali sur la primara tablo
kiel mia GSI provas teni supre.
>> Bone, do GSI a, LSI-a, kiu mi uzu?
LSI informojn estas konsekvenca.
GSI informojn estas eventuale konsekvenca.
Se tio estas bone, mi rekomendus uzi GSI, ili estas multe pli fleksebla.
LSI-a povas esti modelita kiel GSI.
Kaj se la datumoj grandeco po hash klavoj en via kolekto superas 10 gigabajtoj,
tiam vi tuj volas uzi tiun GSI ĉar ĝi estas nur malfacila limo.
>> Bone, do grimpita.
Traigivo en Dinamo DB, vi ladskatolon provizo [inaudible]
Throughput al tablo.
Ni havas klientojn kiuj havas provizis 60 billion--
faras 60 miliardoj petoj, regule kurante al super miliono petoj
sekunde sur niaj tabloj.
Tie estas vere neniu teoria limo por kiom
kaj kiom rapide la tablo povas kuri en Dinamo DB.
Estas iuj molaj limoj en via konto
ke ni metu tien por ke vi ne freneziĝos.
Se vi volas pli ol ke, ne estas problemo.
Vi venas informi nin.
Ni turnas supren la ciferplaton.
>> Ĉiu konto estas limigita al iu nivelo en ĉiu servo, nur la batilon
do la homoj ne freneziĝos akiri sin en problemo.
Neniu limo en grandeco.
Vi povas meti ajna nombro da eroj sur tablo.
La grandeco de ero estas limigita al 400 kilobajtoj ĉiu,
ke estus elemento ne la atributoj.
Do la sumo de ĉiuj atributoj estas limigita al 400 kilobajtoj.
Kaj cetere, ni havas ke iom LSI temo
kun la 10 gigabajto limo po hash.
Publiko: Malgrandaj numeron, mi mankas kion vi estas diranta al mi, ke is--
Publiko: Oh, 400 kilobajto Estas la maksimuma grandeco por ero.
Do ero havas ĉiujn atributojn.
Do 400 k estas la totala grandeco de tiu ero, 400 kilobajtoj.
Do de ĉiuj atributoj kombinita, ĉiuj datumoj
jen en ĉiujn tiujn atributojn, envolvita en tuta grandeco,
aktuale hodiaŭ la eron limo estas 400 k.
Do grimpante denove, atingita tra dispartiganta.
Traigivo estas provizis ĉe la tablo nivelo.
Kaj estas vere du kapetoj.
Ni legis kapablo kaj skribu kapablo.
>> Do tiuj estas ĝustigitaj sendepende.
RCU la mezuron strikte konsekvenca legas.
Bone, do se vi diras mi volas 1,000 RCU La tiuj estas strikte kohera,
tiuj estas konsekvenca legas.
Se vi diras ke mi volas eventuala konsekvenca legas,
vi povas provizo 1,000 RCU a, vi tuj
akiri 2.000 eventuale konsekvenca legas.
Kaj duono de la prezo por tiuj eventuale konsisti en legas.
>> Denove, alĝustiĝi sendepende.
Kaj ili havas la throughput-- Se vi konsumas 100% de via RCU,
vi ne tuj efikon la havebleco de viaj rajtoj.
Do, ili estas tute sendependa de unu la alian.
Bone, do unu el la aĵoj kiuj Mi menciis brevemente estis sxancelan.
Sxancelan estas malbona.
Sxancelan indikas malbonan neniu SQL.
Ekzistas aferoj ni povas fari helpi vi malpezigi la sxancelan ke vi
spertas.
Sed la plej bona solvo al tio ni prenu
Rigardu, kion vi faras, ĉar Tie estas anti-ŝablono en teatraĵo tie.
>> Tion, aĵoj kiel ne-uniforma laborŝarĝoj, varmaj klavoj, varma vandoj.
Mi batas apartan klavon spaco tre malfacile por iu aparta kialo.
Kial mi faras tion?
Ni kalkuli ke ekstere.
Mi miksante mia varma datumojn malvarma datumoj.
Mi liberigas miajn tabloj akiri grandegaj, sed estas vere
nur iu subaro de la datumoj tio estas vere interesa por mi.
Do por log datumoj, ekzemple, multajn klientoj, Ili akiras log datumoj ĉiutage.
Ili akiris grandegan kvanton de log datumoj.
>> Se vi ĝuste dumpingo ĉiuj ke log datumojn en unu granda tablo, super tempo
ke tablo tuj akiri amasajn.
Sed mi vere nur interesiĝis lastaj 24 horoj, la lastaj sep tagoj,
la lastaj 30 tagoj.
Whatever la fenestro de tempo ke mi estas interesita en rigardanta
por la okazaĵo kiu min tedas, aŭ la okazaĵo kiu estas interesa por mi,
tio estas la sola fenestro tempo ke mi bezonas.
Do kial mi metante 10 jaroj valoras de log datumoj en la tabelo?
Kio kiu kaŭzas estas la tablo la fragmento.
>> Ĝi ricevas grandegan.
Ĝi komencas disvastiĝas trans miloj da nodoj.
Kaj ĉar via kapablo estas tiel malalta, ke vi estas
reale taksas limiganta sur ĉiu unu el tiuj individuaj nodoj.
Do ni komencu rigardi kiel do ni ruliĝi ke tablo super.
Kiel ni sukcesos ke datumoj iom pli bone eviti tiujn problemojn.
Kaj kion tio aspektas?
Jen kion tio aspektas.
Jen kion malbonan NoSQL aspektas.
>> Mi ricevis varman klavon tie.
Se vi rigardos la flanko ĉi tie, tiuj estas mia tuta vandoj.
Mi alvenis 16 vandoj tien sur tiu aparta datumbazo.
Ni faru tion tutan tempon.
Mi kuras ĉi por klientoj ĉiuj tempoj.
Ĝi nomiĝas la varmego mapo.
Varmo mapo diras mi kiel vi estas aliranta via ŝlosilo spaco.
Kaj kion tio estas diranta min estas ke estas unu aparta hash
ke tiu ulo ŝatas an amasego, ĉar li estas
batante ĝin vere, vere malmola.
>> Do la blua estas bela.
Ni ŝatas blua.
Ni ne ŝatas ruĝa.
Ruĝa estas kie la premo ricevas ĝis 100%.
100%, nun vi tuj estos limigita.
Do kiam ajn vi vidas ian ruĝaj linioj kiel this-- kaj ĝi estas ne nur Dinamo DB--
ĉiun NoSQL datumbazo havas tiun problemon.
Ekzistas kontraŭ-padronoj kiuj povas forpelos tiujn tipojn de kondiĉoj.
Kion mi faros estas mi laboras kun klientoj mildigi tiujn kondiĉojn.
>> Kaj kion tio aspektas?
Kaj tiu estas akiranta la plej el Dinamo DB traigivo,
Sed estas vere atingi la plej ekstere de NoSQL.
Tiu ne estas restriktita al Dinamo.
Jen definitely-- mi kutimis labori ĉe Mongo.
Mi estas konata kun multaj NoSQL platformoj.
Ĉiu unu havas tiujn tipojn de varma klavo problemojn.
Por ricevi la plej el ajna NoSQL datenbazo, specife Dinamo DB,
vi volas krei la tabloj kie la hash ŝlosila elemento havas
granda nombro da apartaj valoroj, altgradan kardinalo.
Ĉar tiu signifas Mi estas skribanta al multaj malsamaj siteloj.
>> La pli siteloj mi skribi al, la pli verŝajna
Mi estas disvastigi, kiuj skribas ŝarĝo aŭ legi ŝargi trans multoblaj nodoj,
La pli probable mi estas havi alta traigivo sur la tablo.
Kaj tiam mi volas ke la valoroj por esti petis sufiĉe egale super tempo
kaj unuforme kiel hazarde kiel ebla.
Nu, jen speco de interesaj, ĉar mi ne povas vere
kontrolo kiam la uzantoj venas.
Do sufiĉas nomi, se ni disvastigus aferojn ekstere trans la ŝlosilo spaco,
ni probable esti en pli bona formo.
>> Ekzistas certa kvanto de tempo transdono
ke vi ne tuj povi kontrolon.
Sed tiuj estas vere la du dimensioj ke ni havas,
spaco, aliro egale disvastiĝo, tempo, petoj
alveni egale interspacigitaj en la tempo.
Kaj se tiuj du kondiĉoj estas estanta renkontita,
tiam tio estas kio ĝi estas tuj aspekti.
Tiu estas multe pli bela.
Ni estas vere feliĉa tie.
Ni havas tre eĉ aliro ŝablono.
Jes, eble vi fariĝas iom premo ĉiu nun kaj tiam,
sed nenio vere tro vasta.
Do estas nekredebla kiel multaj tempoj, kiam mi laboras kun klientoj,
ke unua grafeo kun la granda ruĝa bari kaj cxio malbela flava estas
ĉie, ni get farita per la ekzerco
post paro de monatoj de re-arkitekturo,
ili estas kurante la ĝusta sama laborŝarĝo ĉe la ĝusta sama ŝarĝo.
Kaj tiu estas kio ĝi estas rigardanta kiel nun.
Do kion vi ricevas kun NoSQL estas datumoj skemo kiu estas absolute
ligitaj al la aliro ŝablono.
>> Kaj vi povas optimizar ke datumoj schema subteni ke aliro ŝablono.
Se ne, tiam vi tuj vidi tiujn tipojn de problemoj
kun tiuj varmaj klavoj.
>> Publiko: Nu, neeviteble iuj lokoj tuj estos pli varmega ol aliaj.
>> RICK Houlihan: Ĉiam.
Ĉiam.
Jes, mi signifas ĉiam a-- kaj denove, ekzistas
iuj dezajno ŝablonoj ni akiros tra kiu parolas pri kiel vi trakti
kun tiuj super grandaj aldonitaj.
Mi volas diri, mi alvenis al havi ilin, kiel ni traktu ilin?
Mi akiris sufiĉe bonan uzon kazo ke ni parolos pri tion.
>> Bone, do ni parolu pri iuj klientoj nun.
Tiuj infanoj estas AdRoll.
Mi ne scias ĉu vi estas konanta AdRoll.
Vi probable vidos ilin tre sur la retumilo.
Ili estas ad re-celado, ili estas la plej granda ad re-celado negoco
tie.
Ili kutime regule alveturi 60 miliardoj transakcioj je tago.
Ili faras super miliono transakcioj je sekundo.
Ili havas belan simpla tablo strukturo, la plej okupataj tablo.
Ĝi estas esence nur hash ŝlosilo estas la kuketon,
la gamo estas la demografia kategorio, kaj poste
la tria atributo estas la poentaro.
>> Do ni ĉiuj kuketojn en nia retumilo el tiuj infanoj.
Kaj kiam vi iros al partoprenantaj komercisto,
Ili esence trafi vin trans diversaj demografiaj kategorioj.
Kiam vi iras al retejo kaj via parolo mi volas vidi ĉi ad--
aŭ esence vi ne diras that-- sed kiam vi iras al la paĝaro
ili diras vi volas vidi ĉi tiun anoncon.
Kaj ili iris akiri ke ad el AdRoll.
AdRoll aspektas vin sur ilian tablon.
Ili trovas vian kuketon.
La reklamantoj rakontanta ilin, mi volas iun
Kiu estas mezaĝa, 40-jaro-malnova viro, en sportoj.
Kaj ili trafi vin en tiuj demografio kaj ili decidos ĉu aŭ ne
tio estas bona reklamo por vi.
>> Nun ili havas SLA kun ilia publikeco provizantoj
provizi sub- 10 milisegundo respondo sur ĉiu ununura peto.
Do ili estas uzanta Dinamo DB ĉi.
Ili batas al ni milionoj petoj por dua.
Ili estas kapablaj fari cxiujn siajn serĉoj, postenoj de klasifiko ĉiuj kiuj datumojn,
kaj kunprenu tiun aldonu ligon reen al tiu Advertiser en sub 10 milisekundoj.
Estas vere bela fenomena efektivigo, kiun ili havas.
>> Tiuj uloj actually-- Estas tiuj la uloj.
Mi ne certas se ĝi estas tiuj uloj.
Povus esti tiuj uloj.
Esence rakontis us-- ne, mi ne kredu, ke estis ili.
Mi kredas ke estis iu alia.
Mi laboris kun kliento kiu rakontis min
ke nun ke ili jam iris al Dinamo DB, ili estas
elspezi pli mono en manĝetoj por ilia evoluo teamo ĉiumonate
ol ili elspezas en lia datumbazo.
Do ĝi donos al vi ideon de la kosto ŝparadoj
ke vi povas akiri en Dinamo DB estas grandega.
Bone, dropcam estas alia kompanio.
Tiuj ulo estas afabla of-- se vi opinias de interreto de aferoj, dropcam
estas esence interreto sekureco video.
Vi metu vian fotilon tie.
Fotilo havas moviĝo detektilo.
Iu venas kune, deĉenigas cue punkto.
Fotilo startas registrado por tempeto ĝis ĝi ne detektas ajnan movadon anymore.
Metas ke video sur la interreto.
>> Dropcam estis entrepreno kiu estas esence ŝanĝis al Dinamo DB
ĉar ili spertas enorma kreskanta dolorojn.
Kaj kion ili diris al ni, subite petabytes de datumoj.
Ili tute ne sciis ilian servon estus tiel sukcesa.
Pli inbound vídeo ol YouTube estas kio tiuj infanoj plialtigas.
Ili uzas DynamoDB spuri ĉiujn metadatenojn en ĉiuj liaj video ŝlosilaj punktoj.
>> Do ili havas S3 siteloj ili puŝi ĉiuj binarajn artefaktojn en.
Kaj tiam ili havas Dinamo DB rekordojn ke
atentigi homojn al tiuj S3 tri celojn.
Kiam ili bezonas rigardi video, Ili fikse rigardis la rekordon en Dinamo DB.
Ili klaku la ligilon.
Ili disbatos la video de S3.
Do jen speco de kion ĉi aspektas.
Kaj tio estas rekte el ilia teamo.
>> Dinamo DB reduktas sian transdono tempo por video okazaĵoj
de kvin al 10 sekundoj.
En sia malnova interrilata vendejo, kutimis devi iri kaj ekzekuti
multoblaj kompleksaj pridemandojn figuro el kiuj videos disfrapos,
ĝis malpli ol 50 milisekundoj.
Do estas mirinda, Miranta kiom agado
vi povas akiri kiam vin optimizar kaj vi agordi la subkuŝantaj datumbazo
por apogi la aliro ŝablono.
Halfbrick, tiuj uloj, kio estas ĝi, Frukto Ninja mi supozas estas ilia afero.
Ke ĉiuj kuras sur Dinamo DB.
Kaj tiuj uloj, ili estas granda evoluigteamo, granda disvolviĝo
butiko.
>> Ne bona ops teamo.
Ili ne havis multe de operacio rimedoj.
Ili baraktis provas konservi ilia apliko infrastrukturo supren
kaj kurante.
Ili venis al ni.
Ili rigardis ke Dinamo DB.
Ili diris, tio estas por ni.
Ili konstruis siajn tutajn apliko kadro sur ĝi.
Kelkaj vere bela komentoj tie de la teamo sur ilia kapablo
nun enfokusigi konstruaĵo la ludo kaj ne
devi subteni la infrastrukturo, kiu
iĝis enorma kvanto de superkape por ilia teamo.
Do ĉi tio estas iu that-- la profitigi kiujn vi ricevas el Dinamo DB.
>> Bone, reenirinte modelo de datumoj ĉi tie.
Kaj ni parolis iom pri ĉi tiu al oni, oni al multaj,
kaj multaj multaj tipo interrilatoj.
Kaj kiel vi subteni tiujn en Dinamo.
En Dinamo DB ni uzas indeksoj, ĝenerale parolante,
rotacii la datenoj de unu guston al la aliaj.
Hash klavoj, gamo klavoj kaj indeksoj.
>> En ĉi tiu aparta Ekzemple, kiel la plej multaj ŝtatoj
havi permesila postulo ke nur unu kondukpermesilon por persono.
Vi povas iri por akiri du ŝoforo licencojn en la stato de Boston.
Mi ne povas fari ĝin en Teksaso.
Tio estas speco de la vojo ĝi estas.
Kaj tial ĉe la DMV, ni havas serĉoj, ni deziras rigardi supre la kondukpermesilon
per la socia sekureco nombro.
Mi volas rigardi la uzanto detaloj per la kondukpermesilon nombro.
>> Do ni povus havi uzanto tablo, kiu havas hash ŝlosilo sur la seria numero,
aŭ la socia sekureco nombro, kaj diversaj atributoj difinita sur la eron.
Nun sur tiu tablo mi povus difini GSI ke
flips ke ĉirkaŭ kiu diras mi volas hash ŝlosilo sur la licenco kaj tiam
ĉiuj aliaj eroj.
Sed se mi volas demandi kaj trovi la licenco nombro por iu antaŭfiksita Socia
Sekureco nombro, mi povas konsulti la ĉefa tablo.
>> Se mi volas konsulti kaj mi volas akiri la socian sekurecon
numeron aŭ aliaj atributoj de licenco numeron, mi povas konsulti la GSI.
Tiu modelo estas tiu al unu interrilato.
Nur tre simpla GSI, flip tiuj aĵoj ĉirkaŭ.
Nun, parolu pri unu al multaj.
Unu por multaj estas esence via hash gamo ŝlosilo.
Kie ni ricevas multe kun ĉi uzokazo estas monitoro datumoj.
Monitoro datumoj venas en regula intervalo, kiel interreto de aferoj.
Ni ĉiam akiri ĉiujn tiujn rekordojn venon tutan tempon.
>> Kaj mi volas trovi ĉiujn legaĵoj inter specifa tempoperiodo.
Ĝi estas tre komuna en query monitorado infrastrukturo.
La vojo iras pri kiuj estas trovi simpla tablo strukturo, unu tablon.
Mi havas aparaton mezuradojn tablo kun hash ŝlosilo sur la aparato ID.
Kaj mi havas gamon ŝlosilon sur la tempstampo aŭ en ĉi tiu kazo, la epopeo.
Kaj kiu min permesas ekzekuti kompleksajn sercxoj kontraŭ tiu gamo ŝlosilo
kaj redoni tiuj rekordoj ke estas relativa al la rezulto
fiksita ke mi serĉas.
Kaj verko ke unu al multaj interrilato
en la primara tablo uzante la hash ŝlosilo, gamo ŝlosilo strukturo.
>> Do jen speco de konstruita en la tablon en Dinamo DB.
Kiam mi difini hash kaj gamo t tablon, mi
difinanta unu al multaj rilato.
Ĝi estas gepatro-infano rilato.
>> Ni parolu pri multaj multaj rilatoj.
Kaj por ĉi tiu aparta ekzemplo, denove, ni tuj uzos la GSI.
Kaj ni parolu pri ludoj scenaro kie mi havas donita uzanto.
Mi volas eltrovi ĉiujn ludojn kiuj li registris por aŭ ludante en.
Kaj por antaŭfiksita ludo, mi volas trovi ĉiujn uzantojn.
Do kiel mi faru tion?
Mia uzanto ludoj tablo, mi tuj havi hash ŝlosilon de uzanto ID
kaj gamo ŝlosilo de la ludo.
>> Do uzanto povas havi multoblajn ludojn.
Estas unu al multaj rilato inter la uzanto kaj la ludoj li ludas.
Kaj poste sur la GSI, Mi flip ke ĉirkaŭ.
Mi hash sur la ludo kaj Mi oscili sur la uzanto.
Do se mi volas ricevi ĉiujn ludo la uzanto ludi en,
Mi konsulti la ĉefa tablo.
Se mi volas ricevi ĉiujn uzantojn ke ludas apartan ludo,
Mi konsulti la GSI.
Do vi vidas, kiel ni faru tion?
Vi konstruas tiujn GSI la subteni la uzo kazo, la apliko, la aliro
mastro, la apliko.
>> Se mi bezonas konsulti sur tiu dimensio, lasu
mi krei indekson en tiu dimensio.
Se ne, mi ne zorgas.
Kaj laŭ la uzo kazo, mi eble bezonas la indekso aŭ mi ne.
Se ĝi estas simpla por multaj; la ĉefa tablo estas fajna.
Se mi bezonas fari multaj al tiuj multaj informoj, aŭ mi bezonas fari unu al ones,
tiam eble mi bezonas al dua la indekso.
Do ĉiu dependas kion mi klopodas fari
kaj kion mi provas akiri plenumita.
>> Probable mi ne tuj elspezi tro da tempo parolante pri dokumentoj.
Ĉi ricevas iomete, probable, profunda ol ni bezonas iri en.
Ni parolu iomete pri riĉaj query esprimo.
Do en Dinamo DB ni havas la eblecon krei
kion ni nomas projekcio esprimoj.
Projekcio esprimoj estas simple pluki la kampoj aŭ la valoroj
ke vi volas montri.
Bone, do mi fari elekton.
Mi kreskigos query kontraŭ Dinamo DB.
Kaj mi diras, vi scias kio, spektaklo min nur la kvin stelo recenzoj
por ĉi tiu aparta produkto.
Do jen ĉio mi volas vidi.
Mi ne volas vidi ĉiujn aliaj atributoj de la vico,
Mi nur volas vidi tion.
Estas ĝuste kiel en SQLa kiam vi diru unuaranga stelo aŭ de tablo,
vi ricevas ĉion.
Kiam mi diras unuaranga nomon de tablo, mi nur akiri unu atributo.
Ĝi estas la sama speco de aĵo en Dinamo DB aŭ alia NoSQL datumbazoj.
Filtrilo esprimoj permesos min esence tranĉis la rezulto metita malsupren.
Do mi faru konsulto.
Query revenu kun 500 eroj.
Sed mi nur volas la erojn kiuj havas atributon kiu diras tion.
Okej, do ni elfiltri tiujn erojn kiuj ne kongruas tiu aparta demando.
Do ni havas filtrilon esprimoj.
>> Filtrilo esprimoj povas kuri sur iu atributo.
Ili ne estas kiel gamo mendoj.
Raise demandoj estas pli selektema.
Filtrilo demandoj postulas min iri akiri la tutan rezultoj starigis kaj tiam
skulpti el la datumoj ne volas.
Kial estas tio gravas?
Ĉar mi legis ĉion.
En konsulto, mi tuj legi kaj ĝi tuj estos gigante pri datenoj.
Kaj tiam mi tuj skulpti el kio mi bezonas.
Kaj se mi nur cxizi eksteren kelkaj vicoj, tiam tio estas bone.
Ĝi ne estas tiom malefikaj.
>> Sed se mi legas tutan amason de datumo, nur por skulpti el unu ero,
tiam mi tuj estos pli bona off uzante gamon query,
ĉar ĝi estas multe pli elektemaj.
Ĝi tuj savi min multan monon, ĉar mi pagas por tiu legado.
Kie la rezultoj kiuj venas reen transiri tiun drato povus esti pli malgranda,
sed mi pagas pro la legado.
Do komprenu kiom vi fariĝas la datumoj.
Tio estas tre grava en Dinamo DB.
>> Kondiĉa esprimoj, tiu estas kio vi eble nomu optimisma ŝlosado.
Ĝisdatigu se ekzistas, aŭ se tiu valoro estas ekvivalenta al kio mi specifas.
Kaj se mi havas tempon poŝtmarko iun rekordo, mi povus legi la datumojn.
Mi povus ŝanĝi tion datumoj.
Mi povus iri registran ke datumojn reen al la datumbazo.
Se iu ŝanĝis la rekordo, la tempstampo eble ŝanĝiĝis.
Kaj aliflanken mian kondiĉa ĝisdatigo povus diri ĝisdatigo
se la tempstampo egalas ĉi.
Aŭ la ĝisdatigo malsukcesos ĉar iu ĝisdatigis la rekordon dume.
>> Tion ni nomas optimisma ŝlosado.
Ĝi signifas ke iu povas enveni kaj ŝanĝi ĝin,
kaj mi tuj detekti ŝin kiam mi reiras al skribi.
Kaj tiam mi povas vere legi ke datumoj kaj diru, ho, li ŝanĝis tion.
Mi bezonas klarigi ke.
Kaj mi povas ŝanĝi la datumojn en mia registri kaj apliki alian ĝisdatigon.
Do vi povas kapti tiujn dumtajpa ĝisdatigoj kiuj okazas inter la tempo
ke vi legas la datumojn kaj la tempo vi povus skribi la datumojn.
>> Publiko: Kaj la filtrilo esprimo fakte signifas ne
en la nombro aŭ not--
>> [Intermetante VOĈOJ]
RICK Houlihan: Mi ne volas ricevas tro multe en tiu.
Tio Estas rezervita ŝlosilvorto.
La funto vido estas rezervita ŝlosilvorto en Dinamo DB.
Ĉiu datumbazo havas propran rezervita nomoj por kolektoj vi ne povas uzi.
Dinamo DB, se vi specifas funton antaŭ tiu,
vi povas difini tiujn nomojn super.
Jen referencita valoro.
Ĝi estas probable ne la plej bona sintakso por havas tie supre por ĉi tiu diskuto,
ĉar ĝi metas en iu real-- Mi estus estinta parolante pli
pri kiuj ĉe pli profunda nivelo.
>> Sed sufiĉas diri, tiu povis esti query skani kie views--
nek funto opinioj estas pli granda ol 10.
Ĝi estas nombra valoro, jes.
Se vi volas, ni povas paroli pri ke post la diskuto.
Bone, do ni ricevas en iuj scenejoj en bonaj praktikoj
kie ni tuj paroli pri iuj apps tie.
Kio estas la uzo kazoj por Dinamo DB.
Kio estas la dezajno ŝablonoj en Dinamo DB.
>> Kaj la unua unu ni tuj diskuto pri tio estas la interreto de aferoj.
Do ni ricevas amason of-- mi supozas, kio estas it-- pli ol 50%
de trafiko sur la interreto ĉi tiuj tagoj fakte generita per maŝinoj,
aŭtomatigita procezoj, ne de homoj.
Mi volas diri tion ĉi afero vi portas ĉirkaŭ via poŝo,
kiom datumo ke tio afero estas fakte sendado ĉirkaŭ sen vi
scii ĝin estas absolute mirinda.
Via situo, informoj pri kiom rapide vi iras.
Kiel vi pensas Google Maps verkoj kiam oni diras al vi kion la trafiko estas.
Estas ĉar ekzistas milionoj kaj milionoj da homoj veturanta ĉirkaŭ
kun telefonoj kiuj sendas datumoj ĉie loko tutan tempon.
Do unu el la aĵoj pri tiu tipo de datumoj
kiu venas en, monitoro datumoj, log datumoj, tempo serio datumojn, estas ĝi
kutime nur interesa por iomete da tempo.
Post tiu tempo, ĝi estas ne tiel interesa.
Do ni raportis, ne lasu tiujn tablojn kreski sen limoj.
La ideo ĉi tie estas ke eble mi havas 24 horoj valoras de eventoj en mia varma tablo.
Kaj ke varma tablo tuj estos provizis al tre alta rapideco,
ĉar ĝi estas prenante multajn datumojn.
Ĝi prenas multajn datumojn en kaj mi legas ĝin multe.
Mi havas multajn operacio sercxoj kurante kontraŭ tiu datumo.
>> Post 24 horoj, hej, vi scias kion, mi ne zorgas.
Do eble ĉiu noktomezo mi rulo Mia tablo super al nova tablo
kaj mi deprovision ĉi tablo.
Kaj Mi prenos la RCU aj kaj WCU la malsupren ĉar 24 horojn poste
Mi ne kuras tiom da sercxoj kontraŭ tiu datumo.
Do mi iros por savi monon.
Kaj eble 30 tagoj mi ne eĉ bezonas zorgi pri ĉio.
Mi povus porti la WCU La tuta vojo malsupren al unu,
ĉar vi scias kion, ĝi estas neniam tuj get skribita al.
La datumoj estas 30 tagojn malnova.
Ĝi neniam ŝanĝas.
>> Kaj ĝi estas preskaŭ neniam ricevos legi, do ni nur prenu ke RCU malsupren al 10.
Kaj Mi ŝparas barelon da mono sur tiu datumoj, kaj nur pagi por mia varma datumoj.
Do jen la grava afero rigardi ĉe kiam vi rigardas tempo serio
datumoj eniranta en volumo.
Tiuj estas strategioj.
Nun, mi povis nur lasi ĝin ĉiuj iras al la sama tablo
kaj simple lasu ke tablo kreski.
Eventuale, mi tuj vidu agado temoj.
Mi tuj devas komenci al arĥivo iuj de kiuj datiĝas de la tablo,
kio ne.
>> Ni multe pli bone desegni vian kandidatiĝon
por ke vi povas funkcii tiel dekstra.
Do estas nur aŭtomata en la apliko kodo.
Noktomeze ĉiunokte ĝi ruliĝas la tablo.
Eble kion mi bezonas estas glitante fenestro de 24 horoj de datumoj.
Tiam sur regula bazo mi nomante datumojn de la tablo.
Mi borderas ĝin per Cron laborposteno kaj mi metas ĝin
sur tiuj aliaj tabloj, kiom vi bezonas.
Do se seguidilla funkcias, tio estas granda.
Se ne, eltondi ĝin.
Sed ni tenas tiun varman datumoj for de via malvarma datumoj.
Ĝi ŝparos vin multa mono kaj Fari vian tabloj pli elfaranta.
Do la sekvanta afero ni parolos pri estas produkto katalogo.
Produkto katalogo estas bela komuna uzo kazo.
Tiu estas fakte tre komuna padrono ke ni vidos en vario de aferoj.
Vi scias, Twitter por Ekzemple, varma tweet.
Ĉiuj venas kaj grabbing tiu tweet.
Produkto katalogo, Mi akiris vendon.
Mi ricevis varman vendo.
Mi ricevis 70.000 petoj por dua alveno por produkto
priskribo de mia produkto katalogo.
Ni vidas tion en la detalisto operacion sufiĉe iomete.
Do kiel ni trakti tion?
Ne estas maniero pritrakti tion.
Ĉiuj miaj uzantoj volas vidi la sama peco de datumo.
Ili venas en, samtempe.
Kaj ili ĉiuj farante petoj por la sama peco de datumo.
Tio donas min ke varma klavo, ke granda ruĝa kontuzon sur mia mapo kiu ni ne ŝatas.
Kaj tio estas kion tio aspektas.
Do trans mian ŝlosilon spaco mi ricevas martelita en la vendo erojn.
Mi ricevas nenion aliloke.
>> Kiel mi malpezigi tiun problemon?
Nu, ni malpezigi tiun kun caché.
Kaŝmemoro, vi metas esence en-memoro dispartigo antaŭ la datumbazo.
Ni sukcesis [Inaudible] kaŝmemoro, kiom vi
povas agordi vian propran kaŝmemoro, [inaudible] kaŝmemoro [? d,?] kiom vi volas.
Metu ke ĝis antaŭ la datumbazo.
Kaj Tiel vi povos stoki ke datumoj el tiuj varmaj klavoj en tiu kaŝmemoro
spaco kaj tralegu la kaŝmemoro.
>> Kaj tiam plimultaj viaj legas komenci rigardante kiel ĉi.
I got ĉiuj tiuj kaŝmemoron trafas tien kaj mi ja nenion okazas cxi tie
ĉar datumbazo sidas malantaŭ la kaŝmemoro kaj legas neniam veni tra.
Se mi ŝanĝas la datumojn en la datenbazo, mi devas ĝisdatigi la kaŝmemoro.
Ni povas uzi iun kiel steams fari tion.
Kaj mi klarigos, kiel tio funkcias.
Bone, mesaĝado.
Retpoŝto, ni ĉiuj uzas retpoŝto.
>> Jen sufiĉe bona ekzemplo.
Ni havas ian mesaĝojn tablo.
Kaj ni akiris enirkesto kaj sendotaj.
Jen kion la SQL volus aspekti konstrui ke enirkesto.
Ni ia uzas samspecan de strategio uzi GSI a, GSI La
por mia enirkesto kaj mia sendotaj.
Do mi akiris krudan reagoj en miajn mesaĝojn tablo.
Kaj la unua alproksimiĝo al tiu povus esti, diri, OK, neniu problemo.
Mi havas krudan mesaĝojn.
Mesaĝoj venanta [inaudible], mesaĝo ID, jen granda.
Tio estas mia unika hash.
Mi tuj kreos du GSI-a, unu por mia inbox, unu por mia sendotaj.
Kaj la unua afero Mi faros estas mi diros mian hash ŝlosilo
tuj estos la ricevonto kaj Mi tuj aranĝi sur la dato.
Tio estas mirinda.
Mi akiris mian belan vidon tie.
Sed estas iom afero tie.
Kaj vi kuros en ĉi en interrilata datumbazoj tiel.
Ili vokis vertikale dispartiganta.
Vi volas gardi viajn grandaj datumoj for de via malgranda datumo.
>> Kaj la kialo kial estas ĉar mi gotta iri legi la erojn akiri la atributojn.
Kaj se mia korpoj estas ĉiuj en ĉi tie, tiam legas nur kelkaj erojn
se mia korpo longo estas averaĝanta 256 kilobajtoj ĉiu,
la math ricevas belajn malbela.
Do diras mi volas legi David enirkesto.
David enirkesto havas 50 erojn.
La mezumo kaj grandeco estas 256 kilobajtoj.
Jen mia konvertiĝo rilatumo por RCU La estas kvar kilobajtoj.
>> OK, ni iru kun eventuale konsekvenca legas.
Mi ankoraŭ manĝas 1600 RCU La nur legi David enirkesto.
Ouch.
OK, nun ni pensas pri kiel la app laboroj.
Se mi estas en retpoŝto app kaj Mi rigardas mian leterkeston,
kaj mi rigardas la korpon de ĉiu mesaĝo, ne, mi rigardas la resumoj.
Mi rigardis nur la titolaj.
Do ni konstruu tablo strukturo kiu aspektas pli kiel tiu.
>> Do jen la informo ke mia laborfluo bezonas.
Ĝi estas en mia enirkesto GSI.
Ĝi estas la dato, la sendinto, la temo, kaj poste
la mesaĝo ID, kiuj punktoj reen al la mesaĝoj tablo
kie mi povas ricevi la korpon.
Nu, tiuj estus rekordo IDs.
Ili notus reen al la listero IDs sur la Dinamo DB tablo.
Ĉiu indekso ĉiam creates-- ĉiam havas la eron
ID kadre of-- ke venas kun la indico.
>> Bone.
Spektantaro: Ĝi rakontas ĝin kie ĝi estas stokita?
RICK Houlihan: Jes, ĝi diras exactly-- jen ĝuste kion ĝi faras.
Ĝi diras jen mia re rekordo.
Kaj ĝi malebligos montri ĝin al mia re rekordo.
Ekzakte.
Bone, do nun mia inbox estas fakte multe pli malgranda.
Kaj tio vere subtenas la laborfluo de email app.
Do mia inbox, mi klakas.
Mi iros kune kaj mi alklakas la mesaĝo, tio estas kiam mi devas iri ricevi la korpon,
ĉar mi tuj iri al malsama vido.
Do se vi opinias pri MVC tipo de kadro, modelo view adaptilo.
>> La modelo enhavas la datumo kiu la vido bezonoj
kaj la regilo interagas kun.
Kiam mi ŝanĝas la kadro, kiam Mi ŝanĝas la perspektivon,
ĝi estas BONE reiri al la servilo kaj repoblar la modelon,
ĉar tio estas kion la uzanto atendas.
Kiam ili ŝanĝas opiniojn, tio estas kiam ni povas reiri al la datumbazo.
Do retpoŝton, klaki.
Mi serĉas la korpo.
Ronda vojaĝo.
Iri preni la korpon.
>> Mi legis multe malpli datumojn.
Mi nur legis la korpoj kiuj David bezonas kiam li bezonas ilin.
Kaj mi ne brulos en 1600 RCU simple montri sian leterkeston.
Do nun that-- tiamaniere ke LSI aŭ GSI-- Mi bedaŭras,
GSI, laborus el.
Ni havas niajn hash sur la ricevanto.
Ni havas la gamo ŝlosilo sur la dato.
Kaj ni havas la projektita atributoj ke ni bezonas nur por apogi la vidon.
>> Ni rotacias ke por la sendotaj.
Hash pri sendinto.
Kaj en esenco, ni havas la tre bona, pura rigardo.
Kaj estas basically-- ni havas tiun belan mesaĝojn
tablo ke tio esti disvastigi bele ĉar ĝi estas hash nur, hashed mesaĝon ID.
Kaj ni havas du indeksoj ke estas turnanta for de tiu tablo.
Bone, do ideo tie estas ne teni la granda datumo kaj tiu malgranda datumo
kune.
Partition vertikale, dispartigi tiuj tabloj.
Ne legu datumojn vi ne devas.
Bone, videoludado.
Ni ĉiuj ŝatas ludojn.
Almenaŭ mi ŝatas ludojn tiam.
Do iuj de la aĵoj ke ni trakti kiam
ni pensas videoludado, dekstra?
Gaming tiujn tagojn, speciale moveblaj videoludado, estas ĉiuj pri pensado.
Kaj mi tuj turni tie iomete for de DynamoDB.
Mi tuj alportos en iuj de la diskuto
chirkau la aliaj AWS teknologioj.
>> Sed la ideo pri videoludado estas pensi proksimume en terminoj de APIs, API kiu estas,
Ĝenerale parolante, HTTP kaj JSON.
Ĝi estas kiel moveblaj ludoj ia interagi kun siaj reen randoj.
Ili faras JSON afisxo.
Ili ricevas datumojn, kaj ĝi estas ĉio, Ĝenerale parolante, en bela JSON APIs.
>> Aĵoj kiel akiri amikoj, akiru la leaderboard, interŝanĝi datumojn,
uzanto generita enhavo, puŝi reen ĝis la sistemo,
tiuj estas specoj de aferoj ke ni tuj faros.
Duuma valoraĵo datumoj, ĉi datumoj eble ne sidas en la datumbazo.
Tio povas sidi en objekto vendejo, dekstra?
Sed la datumbazo tuj finas dirante la sistemo,
rakontanta la aplikaĵo kien iri akiri ĝin.
Kaj neeviteble, multijugador serviloj, dorso fino infrastrukturo,
kaj desegnita por alta disponeblo kaj escalabilidad.
Tiuj estas aferoj kiujn ni ĉiuj deziras en la videoludado infrastrukturo hodiaŭ.
>> Do ni rigardu kion tio aspektas.
Got kernan malantauxo, tre simpla.
Ni havas sistemon ĉi tie kun multoblaj disponeblo zonoj.
Ni parolis pri AZS kiel being-- opinias de ili kiel apartaj datumoj centroj.
Pli ol unu datumejo po AZ, sed tio estas bone,
nur pensas pri ili kiel apartaj datumoj centroj kiuj estas geografie
kaj kulpo izolita.
>> Ni tuj havi paro EC2 petskriboj.
Ni tuj devas iuj malantauxo servilo.
Eble se vi estas legaco arkitekturo, ni estas
uzante kion ni nomas RDS, rilata datumbazo servoj.
Povus esti MSSQL, MySQL, aŭ io simila.
Tiu estas maniero multe aplikoj estas desegnitaj hodiaŭ.
>> Nu ni eble volas iri kun tio estas kiam ni grimpi eksteren.
Ni iru antaŭen kaj metis la S3 sitelo tie supre.
Kaj ke S3 sitelo anstataŭ servanta tiujn celojn de nia servers--
ni povus fari tion.
Vi metis ĉiujn viajn duuma objektojn sur via serviloj
kaj vi povas uzi tiujn servilo petskribojn por servi tiun datumojn supren.
Sed tio estas sufiĉe multekosta.
>> Pli bona maniero por fari estas iri antaŭen kaj metis tiujn objektojn en S3 sitelo.
S3 estas objekto repositorios.
Ĝi estas konstruita specife por utilante tiujn tipojn de aferoj.
Kaj forkuru Viaj klientoj peti rekte de tiuj objekto siteloj,
offload la serviloj.
Do ni komencas grimpi tie.
>> Nun ni alvenis uzantoj ĉiuj super la mondo.
Mi alvenis uzantoj.
Mi bezonas havi enhavon loke situas proksime al ĉi tiuj uzantoj, dekstra?
Mi kreis S3 sitelo kiel mia fonto dosierujo.
Kaj mi frente kiu kun la CloudFront dissendo.
>> CloudFront estas KD kaj enhavo transdono reto.
Esence ĝi prenas datumoj kiuj vi specifas kaj cachés ŝin ĉiuj super la interreto
tiel uzantoj ĉie povas havi tre rapida respondo kiam
ili petas tiujn celojn.
>> Do vi fari ideon.
Vi estas speco de ekspluatanta ĉiuj aspektoj de AWS tie akiri tiun faris.
Kaj fine, ni ĵetu en aŭtomatan grimpita grupo.
Do nia AC2 petskribojn de nia ludo serviloj,
kiel ili komencas akiri pli okupata kaj pli okupataj kaj pli okupata,
Ili simple ŝpini alian Ekzemple, ŝpini alia petskribo,
ŝpini alia petskribo.
Do la teknologio AWS havas, ĝi permesas specifi parametrojn
ĉirkaŭ kiu via serviloj kreskos.
Do vi povas havi n nombro de serviloj tie ekstere ĉe ajna donita tempon.
Kaj se via ŝarĝo foriras, ili timige ŝrumpi, la nombro estos ŝrumpi.
Kaj se la ŝarĝo revenas, gxi devos kreski reen eksteren, elaste.
>> Do tiu aspektas granda.
Ni havas multajn EC2 petskriboj.
Ni povas meti en kaŝmemoron antaŭ la datumbazoj,
klopodi akceli la datumbazoj.
La sekva punkto de premo tipe personoj vidos
Estas ili grimpi ludo uzanta interrilata datumbaza sistemo.
Jeez, la datumbazo agado estas terura.
Kiel ni plibonigi tiun?
Ni provu meti kaŝmemoro antaŭ tiu.
>> Nu, cache ne funkcias tiel granda en ludoj, bone?
Por ludoj, skribo estas dolora.
Ludoj estas tre skribi peza.
Cache ne funkcias kiam vi estas skribi pezaj ĉar vi ĉiam
akiris ĝisdatigi la kaŝmemoro.
Vi aktualigi la kaŝmemoron, estas senrilataj esti caching.
Ĝi estas fakte ĵus ekstra laboro.
>> Do kie ni iras tien?
Vi havas grandan botelkolo tie malsupre en la datumbazo.
Kaj la loko iri evidente estas dispartiganta.
Dispartiganta ne facile fari kiam vi estas
kontraktanta kun rilata datumbazoj.
Kun interrilata datumbazoj, vi estas respondeca por administrado, efike,
la ŝlosilo spaco.
Vi diras ke uzantoj inter A kaj M iri tien, inter N kaj Z iri tien.
Kaj vi ŝaltanta trans la apliko.
Do vi pritraktas tiu dispartigo datumfonto.
Vi havas transaccionales devigoj kiuj ne ampleksas vandoj.
Vi havas ĉiajn messiness ke vi estas
kontraktanta kun malsupre provas trakti grimpante eksteren
kaj konstruante pli grandan infrastrukturon.
Estas nur neniu amuzo.
>> Publiko: Do ​​vi diras, ke kreskanta fonto punktoj akcelas
la procezo?
RICK Houlihan: Kreskanta?
Publiko: Fonto punktoj.
RICK Houlihan: Fonto punktoj?
Publiko: El la informon, kie la informo estas venanta de?
RICK Houlihan: No.
Kion mi diras estas pliigante la numeron de vandoj en la magazeno de datumoj
plibonigas traigivo.
Do kio okazas ĉi tie estas uzantoj venanta en la EC2 ekzemple tien,
bone, se mi bezonas uzanto jen A al M, mi iros tien.
El N al p, mi iros tien.
De P al Z, mi iros tien.
>> Publiko: OK, tiuj tiel tiuj estas ĉiuj stokitaj en malsamaj nodoj?
>> RICK Houlihan: Jes.
Konsideru tiajxojn malsamaj siloj de datumoj.
Do vi devi fari tion.
Se vi provas fari tiu, se vi provas
grimpi sur rilata platformo, jen kion vi faras.
Vi prenas datumojn kaj vi tranĉante ĝin malsupren.
Kaj vi dispartiganta ĝin trans multnombraj petskriboj de la datumbazo.
Kaj vi administri ĉiuj kiuj ĉe la apliko parto.
Ĝi estas neniu amuzo.
Do kion ni volas iri?
Ni volas iri DynamoDB, plene sukcesis, NoSQL datumoj vendejo, provizo traigivo.
Ni uzas malĉefa indeksoj.
Ĝi estas esence HTTP API kaj inkluzivas dokumenton subteno.
Do vi ne devas maltrankvili pri ajna el kiuj dispartiganta.
Ni faros ĉion por vi.
Do nun, anstataŭ, vi simple skribu al la tablo.
Se la tablo devas esti dispartigita, kio okazas malantaŭ la scenoj.
Vi tute izolita de tiu kiel desarrollador.
Do ni parolu pri iuj de la uzo kazoj
ke ni trafos en videoludado, komuna videoludado scenaroj, leaderboard.
Do vi hvas uzantoj enirantan la BoardNames ke ili estas
sur la partituroj por tiu uzanto.
Ni povus hashing sur la komputila uzantnomo, kaj tiam ni havas gamon sur la ludo.
Do ĉiu uzanto volas vidi la tuta ludo estas ludis li
kaj lia tuta supro partituro trans tuta ludo.
Do jen lia persona leaderboard.
>> Nun mi volas iri en kaj mi volas get-- do mi ricevas tiujn personajn leaderboards.
Kion mi volas fari estas iri preni la supro partituro tra ĉiuj uzantoj.
Do kiel mi faru tion?
Kiam mia konanto estas hashed sur la komputila uzantnomo, intervalis sur la ludo,
bone mi tuj iros antaŭen kaj restrukturi, krei GSI,
kaj mi tuj restrukturi ke datumoj.
>> Nun mi tuj hash sur la BoardName, kiu estas la ludo.
Kaj mi tuj oscili sur la supro partituro.
Kaj nun mi kreis malsamajn siteloj.
Mi uzas la saman tablon, la sama elemento datumoj.
Sed mi kreante sitelo kiu donas mi agregación de supro partituro por ludo.
>> Kaj mi povas konsulti ke tablo ricevi tiun informon.
Do, mi metis ke query desegnon ĝis esti apogita per sekundara indekso.
Nun ili povas ordo laŭ BoardName kaj ordo laŭ TopScore, depende.
Do vi povas vidi, ĉi tiuj estas tipoj de uzkazoj vi ricevas en videoludado.
Alia bona uzo kazo ni preni en videoludado estas premioj kaj kiuj estas gajnis la premiojn.
Kaj tiu estas granda uzo kazo kie ni nomas maldensa indeksoj.
Maldensa indeksoj estas la kapablecon produkti
indico kiu ne nepre enhavi ĉiun objekton sur la tablo.
Kaj kial ne?
Pro la atributo kiu estas estanta indeksita ne ekzistas sur ĉiu ero.
>> Do en ĉi tiu aparta uzi kazo, mi diras,
Vi scias kion, Mi tuj krei atributo nomata Award.
Kaj mi tuj doni ĉiun uzanton kiu havas premion kiuj atribuas.
Uzantoj kiuj ne havas premiojn estas ne tuj havas tiun atributon.
Do kiam mi krei la indekso, la nuraj uzantoj
kiuj tuj montros supren en la indekso estas
tiuj kiuj vere gajnis premiojn.
Do tio estas granda vojo esti kapabla krei filtrita indeksoj ke
Estas tre, tre selectiva kiu ne devas indeksi la tuta tablo.
>> Do ni estas duumaj malalta ĝustatempe tie.
Mi tuj iros antaŭen kaj salti eksteren kaj transsaltu tiun scenaron.
Paroli iomete about--
>> Publiko: Povas min demandas rapidan demandon?
Unu estas skribi peza?
RICK Houlihan: Kio estas?
Publiko: Skribu peza.
RICK Houlihan: Skribu peza.
Mi vidu.
>> Publiko: Aŭ estas kiu ne io vi povas simple
voĉon al en demando de duaj?
RICK Houlihan: Ni iru tra la balotado scenaro.
Ĝi ne estas tiel malbona.
Ĉu vi infanoj havas kelkajn minutojn?
BONE.
>> Do ni parolos pri balotado.
Do reala tempo balotado, ni havas postulojn por balotado.
Postuloj estas ke ni permesos ĉiu persono voĉdoni nur unufoje.
Ni volas neniu povi ŝanĝi sian voĉdonon.
Ni volas realtempan agregación kaj analytics por demografio
ke ni tuj estos montrante al uzantoj en la retejo.
>> Pensu pri tiu scenaro.
Ni laboras multajn realo TV montras kie ili estas
fari tiujn ĝusta tipo de aĵoj.
Do vi povas pensi pri la scenaro, ni havas milionojn kaj milionoj
de adoleskaj knabinoj tie kun liaj poŝtelefonoj
kaj voĉdonas kaj voĉdonado, kaj voĉdoni por ĉiuj kiu estas
trovas esti la plej populara.
Tiuj estas iuj de la postulojn ni elĉerpas.
>> Kaj tiel la unua preni solvi tiun problemon
estus konstrui tre simpla apliko.
Do mi havas ĉi tiu app.
Mi havas kelkajn balotantojn tie.
Ili envenis, ili batis la balotado app.
Mi havas iom da krudaj voĉoj tablo Mi nur renversi tiujn voĉdonojn en.
Mi havas iom aldonita voĉdonoj tablo ke
faros mian Analytics kaj demografion, kaj ni metos ĉiuj ĉi tien.
>> Kaj tiu estas granda.
Vivo estas bona.
Vivo bona ĝis ni trovos ke ĉiam nur unu aŭ du
popolo, kiu estas populara en elekto.
Ekzistas nur unu aŭ du aferojn ke homoj vere zorgas pri.
Kaj se vi voĉdoni ĉe skalo, subite mi
tuj estos martelante la infero el du kandidatoj, unu aux du kandidatoj.
Tre limigita nombro da eroj personoj trovas esti populara.
>> Tiu ne estas bona dezajno ŝablono.
Tiu estas fakte tre maltaŭga modelo
ĉar ĝi kreas precize kion ni parolis pri kio estis varma klavoj.
Varmaj ŝlosiloj estas io ni ne ŝatas.
>> Nu do kiel ni ripari tiun?
Kaj vere, la maniero por korekti tiun estas per prenante tiujn kandidato siteloj
kaj por ĉiu kandidato ni havas, ni tuj append hazarda valoro,
iu kiun ni scias, hazarda valoro inter unu kaj 100,
inter 100 kaj 1,000, aŭ inter unu kaj 1.000,
tamen multaj hazarda valoroj vi volas append sur la fino de tiu kandidato.
>> Kaj kion mi vere faris tiam?
Se mi uzas la kandidato ID kiel la sitelon al entuta voĉdonoj,
se mi aldonis hazarda numeron al la fino de tiu,
Mi kreis nun 10 siteloj, a cent sitelojn, mil siteloj
ke mi agregi voĉdonoj laŭlarĝe.
>> Do mi havas milionojn kaj milionoj, kaj milionoj de registroj venon
por tiuj kandidatoj, mi elĵetas tiuj voĉdonoj trans Kandidato a_1
tra Kandidato A_100, ĉar ĉiufoje voĉdono envenas,
Mi generante hazarda valoro inter unu kaj 100.
Mi tacking ĝin sur la fino de la kandidato tiu persono voĉdonis por.
Mi dumpingo gxin en tiun rubujon.
>> Nun malantauxe, mi scias ke mi havas cent sitelojn.
Do kiam mi deziras antaŭeniri kaj aldonita la voĉdonoj,
Mi legis el ĉiuj tiuj siteloj.
Do mi iru antaŭen kaj aldoni.
Kaj tiam mi la disjxetu kolektu kie mi eliras kaj diru hey,
Vi scias kio, tiu kandidato ŝlosilo spacoj estas super cent sitelojn.
Mi tuj kunvenigu cxiujn voĉdonu el tiuj cent sitelojn.
Mi tuj aldonas ili kaj mi tuj diros,
Kandidato A nun havas totala voĉdono grafo de x.
>> Nun ambaŭ la registran query kaj la legado query
estas bele distribuita ĉar mi skribas trans
kaj mi legas trans centoj de klavoj.
Mi ne skribas kaj legante trans unu klavo nun.
Do jen granda ŝablono.
>> Tiu estas fakte probable unu de la plej grava dezajno
ŝablonoj por skalo en NoSQL.
Vi vidos ĉi tipo de dezajno ŝablono en ĉiu gusto.
MongoDB, DynamoDB, ĝi ne afero, ni ĉiuj devas fari tion.
Ĉar kiam vi pritraktas kun tiuj grandegaj agregaciones,
vi devas diveni manieron disvastigi ilin trans siteloj.
Do jen kiel vi faros tion.
Bone, do kion vi faras nun
Estas vi komercanta ekstere legado kosto por registran escalabilidad.
La kosto de mia legado estas iom pli kompleksa
kaj mi devas iri legita de cent sitelojn anstataŭ unu.
Sed mi povas skribi.
Kaj mia traigivo, mia registran traigivo estas nekredebla.
Do estas kutime valora tekniko por krustanta DynamoDB,
aŭ ajna NoSQL datumbazo tiurilate.
Do ni eltrovis kiel grimpi gxin.
Kaj ni kalkulis kiel forigi nia varma klavoj.
Kaj tiu estas fantazia.
Kaj ni akiris ĉi belan sistemon.
Kaj ĝin donis al ni tre ĝentila balotado ĉar ni havas rekordon voĉdono de-dupe.
Ĝi estas konstruita en DynamoDB.
Ni parolis pri kondicionalo rajtoj.
>> Kiam balotanto envenas, metas insert sur la tablo,
ili enmeti kun siaj votante ID, se ili provas enmeti alian voĉdonon,
Mi do kondiĉa registran.
Diru nur skribi ĉi se tiu ne ekzistas.
Tuj, kiam mi vidas ke ke voĉdono la trafis la tablon,
neniu alia tuj estos kapabla meti lian voĉdonon en.
Kaj tio estas mirinda.
Kaj ni pliigante nia kandidato nombriloj.
Kaj ni faras nia demografio kaj cxio.
Sed kio okazas se mia apliko falas super?
Nun subite voĉdonoj estas enirantan kaj mi
ne scias se ili estas duumaj procesis en mia analytics kaj demografio
anymore.
Kaj kiam la apliko venas reen supren, kiom
diable mi scias kion voĉdonoj havas estis traktitaj kaj kie mi komencu?
>> Do tio estas vera problemo kiam vin komenci rigardi ĉi tipo de scenaro.
Kaj kiel ni solvi tiun?
Ni solvos ĝin kun kion ni voki DynamoDB Rojoj.
Rojoj estas tempo ordigis kaj dispartigita ŝanĝo Protokolo de ĉiu aliro
al la tablo, ĉiu skribos aliro al la tablo.
Ajna datumoj kiu estas skribita al la tablo montras supren en la rivereto.
>> Ĝi estas resume 24 horo atendovico.
Eroj batis la rivereto, ili povas vivi 24 horoj.
Ili povas legi plurfoje.
Garantiita esti liverita nur unufoje al la rivereto,
povis legi n plurfoje.
Do tamen multaj procezoj vi volas konsumi ke datumoj, vi povas konsumi ĝin.
Ĝi aperos ĉiun ĝisdatigon.
Ĉiu registran volas nur aperas unufoje sur la rivereto.
Do vi ne devas maltrankvili pri procesante ŝin dufoje
de la sama procezo.
>> Ĝi estas strikte ordigita por ero.
Kiam ni diras tempo ordigita kaj dispartigita,
vi vidos po dispartigo sur la rivereto.
Vi vidos erojn, ĝisdatigoj en ordo.
Ni ne garantias sur la rivereto ke vi estas
ricevos ĉiu transakcio en la ordo trans erojn.
>> Do rojoj estas kvadrategala.
Ĉu ni ĉiuj scias kion kvadrategala signifas?
Kvadrategala signifas vin povas fari ĝin super kaj super kaj super denove.
La rezulto estas tuj estos la sama.
>> Rojoj estas kvadrategala, sed ili devas esti
luditaj de la deirpunkto, Wherever vi elektas, al la fino,
aŭ ili ne rezulti en la samaj valoroj.
>> Sama afero kun MongoDB.
MongoDB havas konstrukcio ili nomas la oplog.
Estas la ĝusta sama konstrukcio.
Multaj NoSQL datumbazoj havas ĉi konstrukcio.
Ili uzas ĝin por fari aferojn kiel replicación, kiu
Estas ĝuste kion ni faras kun riveretoj.
Publiko: Eble hereza demando, sed vi
paroli pri apps fari malsupren tiel antaŭen.
Ĉu riveretoj garantiita neniam eble iros malsupren?
RICK Houlihan: Yeah, riveretoj estas guaranteed neniam penetras.
Ni manipuli la infrastrukturo malantaŭe. riveretoj aŭtomate
deploji en ilia auto grimpita grupo.
Ni iros tra iom bita pri kio okazas.
>> Mi ne devus diri ili estas ne guaranteed neniam penetras.
La elementoj estas garantiita aperi en la rivereto.
Kaj la rivereto estos alirebla.
Do kio iras malsupren aŭ revenas supren, ke okazas sube.
Ĝi covers-- ĝi estas okej.
Bone, do vi ricevas malsaman vido tipoj de sur la ekrano.
La vido tipoj kiuj estas gravaj al programisto tipe estas, kio ĝi estis?
Mi alvenas la malnova vido.
Kiam ĝisdatigo frapas la tablon, ĝi devos puŝi la malnova vido al la rivereto
tiom datumoj povas enarkivigi, aŭ ŝanĝo kontrolo, ŝanĝo identigo, ŝanĝo
demarŝo.
>> La nova bildo, kio estas nun post la ĝisdatigo, tio estas alia tipo de vido
vi povas akiri.
Vi povas akiri ambaŭ la malnovaj kaj novaj bildoj.
Eble mi volas ilin ambaŭ.
Mi volas vidi, kio estis.
Mi volas vidi kio ŝanĝis.
>> Mi havas observon tipo de procezo kiu kuras.
Ĝi bezonas por kontroli ke kiam tio ŝanĝi,
ke ili estas ene de certaj limoj aŭ ene de certaj parametroj.
>> Kaj tiam eble mi nur bezonas scii kion ŝanĝis.
Ne gravas kion item ŝanĝis.
Mi ne bezonas bezonas scii kio ecoj ŝanĝiĝis.
Mi nur bezonas scii ke La aĵoj estas estanta tuŝita.
Tiuj estas la tipoj de opinioj ke vi akiri de la rivereto
kaj vi povas interagi kun.
>> La apliko kiu konsumas la rivereto,
tio estas speco de vojo tio funkcias.
DynamoDB kliento demandas al puŝi datumojn al la tabloj.
Riveretoj deploji sur kion ni nomas breĉetoj.
Breĉetoj estas skalita sendepende de la tablo.
Ili ne laŭliniigi tute al la vandoj de via tablo.
Kaj la kialo kial estas ĉar ili laŭliniigi
al la kapablo, la nuna kapablo de la tablo.
>> Ili deploji en ilia propra auto grimpita grupo,
kaj ili komencas ŝpini el dependanta sur kiom multaj skribas venintoj,
kiom reads-- vere estas skribas.
Mankas reads-- sed kiom multaj skribas estas eniranta.
>> Kaj tiam sur la dorso Fine, ni havas kion ni
voki KCL, aŭ Kinesis Kliento Biblioteko.
Kinesis estas rivereto datumoj prilaborado teknologio de Amazon.
Kaj riveretoj estas konstruita sur tio.
>> Do vi uzas KCL enŝaltita apliko por legi la rivereton.
La Kinesis Kliento Biblioteko reale administras la laboristoj por vi.
Kaj ĝi ankaŭ faras iuj interesajn aferojn.
Ĝi kreos iuj tabloj supren en via DynamoDB tablespace
spuri kiujn erojn estis traktitaj.
Do tiu vojo se ĝi falas reen, se ĝi falas super kaj venas kaj ricevas
staris reen supren, ĝi povas determini kie cxu en procesante la rivereto.
>> Tio estas tre grava kiam vi parolas replicación.
Mi bezonas scii kion datumoj procesis
kaj kio datumoj havas ankoraŭ esti procesitaj.
Do la KCL biblioteko por riveroj doni al vi multe de tiu funcionalidad.
Atentas tutan mastrumadon.
Ĝi ekstaras laboriston por ĉiu Shard.
Ĝi kreas administra tablo por ĉiu Shard, por ĉiu laboristo.
Kaj tiuj laboristoj fajro, subtenas tiujn tablojn
do vi scias ĉi rekordo estis legita kaj procesis.
Kaj tiam tiu modo se la procezo mortas kaj revenas enretan,
ĝi povas rekomenci ĝuste kie ekis.
>> Do ni uzu tiun por kruco-regiono replicación.
Multaj klientoj havas la bezonon movi datumon aŭ partoj de liaj datumoj tabloj
ĉirkaŭe al malsamaj regionoj.
Estas naŭ regionoj ĉie en la mondo.
Do eble estas need-- mi havu uzantoj en Azio, uzantoj
en la Orienta marbordo de Usono.
Ili havas malsamajn datumojn kiuj bezonoj esti loke distribuita.
Kaj eble uzanto flugas el Azio inte al Usono,
kaj mi volas repliki lia datumoj kun li.
Do kiam li ricevas for la aviadilon, li havas bona sperto uzante lia telefono app.
>> Vi povas uzi la kruco-regiono replicación biblioteko fari tion.
Esence ni havas havigis du teknologioj.
Unu estas konzolo apliko vi povas ekstari sur via propra EC2 okazo.
Ĝi kuras pura replicación.
Kaj tiam ni donis al vi la biblioteko.
La biblioteko povas uzi konstrui via propra apliko se vi
volas fari freneza aĵojn kun kiuj data-- filtrilo, repliki nur parto de ĝi,
turni la datumoj, kopii ĝin en malsamaj tablo, tiel plu kaj tiel antaŭen.
Do jen speco de kion tio aspektas.
>> DynamoDB Riveretoj povas esti pretigita de kion ni nomas Lambda.
Ni menciis iomete pri okazaĵo veturita apliko arkitekturoj.
Lambda estas ŝlosila komponanto de tiu.
Lambda estas kodo kiu maldungas laŭpete en respondo al aparta okazaĵo.
Unu el tiuj eventoj eblis rekordo aperante sur la rivereto.
Se rekordon aperas sur la rivereton, ni nomas ĉi Java funkcio.
Nu, tio estas JavaScript, kaj Lambda Elportas Node.js, Java, Python,
kaj baldaŭ apogi aliajn lingvojn ankaŭ.
Kaj sufiĉas nomi, estas pura kodo.
skribi En Java, vi difinas klason.
Vi puŝi la JAR supren en Lambda.
Kaj tiam oni indikas kiun klaso voki en respondo al kiu okazaĵo.
Kaj tiam la Lambda infrastrukturo malantaŭ kiu kuros tiu kodo.
>> Ke kodo povas procesi rekordojn super la rivereto.
Ĝi povas fari ion ajn kun ĝi.
En ĉi tiu aparta ekzemplo, ĉiuj ni estas vere faras estas elsaluti la atributoj.
Sed tio estas nur kodo.
Kodo povas fari ion, ĉu ne?
>> Do vi povas rotacii ke datumoj.
Vi povas krei devenaĵojn vido.
Se ĝi estas dokumenta strukturo, vi povas platigi la strukturo.
Vi povas krei alternajn indeksoj.
Ĉiuj specoj de aferoj vi povas fari kun la DynamoDB Rojoj.
>> Kaj vere, tion ke aspektas.
Do vi ricevas tiujn ĝisdatigojn venon.
Ili venas for la ĉenon.
Ili legita de la Lambda funkcio.
Ili turnanta la datumojn kaj puŝante ĝin supren en derivaĵa tabloj,
sciigante eksteraj sistemoj de ŝanĝo, kaj puŝas datumojn en ElastiCache.
>> Ni parolis pri kiel meti la kaŝmemoron antaŭ la datumbazo por vendoj
scenaro.
Nu kio okazas, se mi ĝisdatigi la eron priskribo?
Nu, se mi havus Lambda funkcio kurante sur tiu tablo,
se mi ĝisdatigos la eron priskribo, ĝi devos repreni la rekordon de la rivereto,
kaj gxi devos ĝisdatigi la ElastiCache Ekzemple kun la novaj datumoj.
Do jen multa kion ni faras kun Lambda.
Estas gluo kodo, konektiloj.
Kaj ĝi efektive donas la kapablo lanĉi
kaj kuri tre kompleksaj aplikoj sen diligenta servilo
infrastrukturo, kio estas vere malvarmeta.
>> Do ni revenu al nia realtempan balotado arkitekturo.
Tiu estas nova kaj plibonigita kun nia riveretoj kaj KCL ebligis apliko.
Sama kiel antaŭe, ni povas manipuli ajna skalo de elekto.
Ni ŝatas ĉi.
Ni faras el disjxetu reprenas trans multaj siteloj.
Ni havas optimisma ŝlosado okazas.
Ni povas teni niajn balotantoj de ŝanĝanta iliajn voĉdonojn.
Ili povas nur voĉdoni nur unufoje.
Tio estas mirinda.
Realtempaj kulpo toleremo, skalebla agregación nun.
Se la afero falas super, ĝi scias kie rekomenci mem
kiam venas reen supren ĉar ni uzas la KCL app.
Kaj tiam ni povas ankaŭ uzi tiu KCL apliko puŝi datumojn ekstere
al ruĝenŝoviĝo por aliaj app analytics, aŭ uzo
la Elasta MapReduce kuri realtempan streaming agregaciones off
de tiu datumo.
>> Tiuj estas aferoj ni ne parolis pri multo.
Sed ili estas aldona teknologioj kiuj venis
toleri kiam vi serĉas ĉe tiuj tipoj de scenejoj.
>> Bone, do jen pri analytics kun DynamoDB Rojoj.
Vi povas kolekti de-dupe datumoj, fari ĉiajn
bongustajxoj stuff, entutaj datumoj en memoro, krei tiujn derivaĵo tabloj.
Tio estas grandega uzo kazo ke multajn klientojn
estas implikitaj kun, prenante la nestitaj propraĵoj de tiuj JSON dokumentoj
kaj kreante aldonan indeksoj.
>> Ni estas je la fino.
Dankon por portanta kun mi.
Do ni parolu pri referenco arkitekturo.
DynamoDB sidas en la mezo de tiel multe de la AWS infrastrukturo.
Esence vi povas enganchar ĝi ĝis ajn vi volas.
Aplikoj konstruita uzante Dinamo inkluzivi Lambda, ElastiCache, CloudSearch,
puŝi la datumoj eksteren en Elasta MapReduce, importado eksportado de DynamoDB
en S3, ĉiajn fluoj de laboro.
Sed probable la plej bona afero paroli,
kaj tiu estas kio estas vere interesa estas kiam ni
paroli pri okazaĵo movita aplikoj.
>> Tiu estas ekzemplo de interna projekto
ke ni havas kie ni reale eldonado kolekti enketo rezultoj.
Do en retpoŝto ligilon ni sendu, tie denove
esti iom ligilon dirante klako tie respondi al la enketo.
Kaj kiam persono klakoj ligantaj, kio okazas
Estas ili disbatos sekuran HTML enketo formo de S3.
Mankas servilo.
Tiu estas nur S3 objekto.
>> Tiu formo venas supren, ŝarĝas supren en la retumilo.
Oni alvenis Backbone.
Oni alvenis kompleksa Ĝavoskripto ke ĝi estas kurante.
Do estas tre riĉa apliko kurante en la kliento retumilo.
Ili ne scias ke ili ne estas interagante kun malantaŭa fino servilo.
Ĉe tiu punkto, ĉio retumilo.
>> Ili publikigas la rezultojn al kio ni nomas la Amazon API Gateway.
API Gateway estas simple TTT API ke vi povas difini kaj conectarse
al kiom vi volas.
En ĉi tiu aparta kazo, ni estas hokita supren al Lambda funkcio.
>> Do mia POST operacio estas okazanta sen servilo.
Esence tiu API Gateway sidas tie.
Ĝi kostas al mi nenion, ĝis homoj komenci eldoni ĝin, ĉu ne?
La Lambda funkcio nur sidas tie.
Kaj ĝi kostas min nenio ĝis personoj komencos bati lin.
Do vi povas vidi, kiel la volumeno kreskoj, tio estas kiam la ŝargoj venis.
Mi ne kurante servilon 7/24.
>> Do mi tiras la formo malsuprenvenas de la sitelo,
kaj mi afiŝas per la API Enirejo en la Lambda funkcio.
Kaj tiam la Lambda funkcio diras, vi scias
kion mi havas kelkajn PIIs, iuj propre perceptebla informo
en tiuj respondoj.
Mi ricevis komentojn devenante uzantoj.
Mi havas retadresoj.
Mi havas salutnomoj.
>> Lasu min fendi ĉi ekstere.
Mi tuj generos iun metadatuma sur tiu rekordo.
Kaj mi tuj puŝi la metadatumon en DynamoDB.
Kaj mi povus ĉifri ĉiujn datumojn kaj puŝi ĝin en DynamoDB se mi volas.
Sed estas pli facile por mi, en ĉi uzi kazo, por antaŭeniri al ni diru,
Mi tuj puŝas la krudaj datumoj en ĉifrita S3 sitelo.
Do mi uzas konstruita en S3 servilo flanko ĉifrado kaj Amazon Ŝlosilo Management
Servo por ke mi havas klavon, kiu povas turni sur regula intervalo,
kaj mi povas protekti ke PII datumoj kiel parto de tiu aro laborfluo.
>> Do kion mi faris?
Mi ĵus deplojiĝis tuto apliko, kaj mi ne havas servilon.
Do kion okazaĵo movita apliko arkitekturo faras por vi.
>> Nun, se vi pensas pri la uzo kazo por this--
ni havos aliajn klientojn mi parolas proksimume precize tiu arkitekturo kiu
kuri fenomene granda kampanjoj, kiuj rigardas tion kaj irantaj, oh mia.
Ĉar nun, ili povas esence puŝi ĝin tie,
lasu ke kampanjo nur sidi tie ĝis ĝi ĵetas, kaj ne
devas zorgi figon pri kia infrastrukturo
tuj estos tie por apogi ŝin.
Kaj tiam tuj kiam tiu kampanjo estas farita,
ĝi estas kiel la infrastrukturo nur tuj foriras
ĉar tie vere neniu infrastrukturo.
Estas nur kodo kiu subigas Lambda.
Estas nur datumoj kiuj sidas en DynamoDB.
Ĝi estas mirinda vojo konstrui aplikojn.
>> Publiko: Do ​​ĝi estas pli efemeran ol ĝi estus
se ĝi estis stokita sur reala servilo?
>> RICK Houlihan: Absolute.
Pro tiu servilo ekzemple devus esti 7/24.
Ĝi devas esti havebla por iu respondi al.
Nu divenu kion?
S3 estas disponebla 7/24.
S3 ĉiam respondas.
Kaj S3 estas tre, tre bona ĉe servanta celojn.
Tiuj objektoj povas esti HTML- dosieroj, aŭ JavaScript dosierojn, aŭ kion ajn vi volas.
Vi povas kuri tre riĉa aplikoj retejo el S3 siteloj, kaj homoj faras.
>> Kaj do jen la ideo tie estas foriri de la vojo
ni kutimis pensi pri ĝi.
Ni ĉiuj uzis pensi en Kondiĉoj de serviloj kaj gastigantoj.
Ĝi ne estas pri tio plu.
Temas pri infrastrukturo kiel kodo.
Deploji la kodo al la nubo kaj lasu la nubo ruli ĝin por vi.
Kaj tion AWS provas fari.
>> Publiko: Do ​​via oro skatolo en la mezo de la API Gateway ne servilo-simila,
sed anstataŭe estas just--
>> RICK Houlihan: Vi povas pensi de ĝi kiel servilo fasado.
Ĉiuj estas estas ĝi prenos HTTP peti kaj mapi ĝin al alia procezo.
Tio estas ĉio faras.
Kaj en ĉi tiu kazo, ni surĵeto ĝin al Lambda funkcio.
Bone, do jen ĉio mi ricevis.
Dankegon.
Mi dankos.
Mi scias ni volas iomete super tempo.
Kaj espereble vi uloj atingis iomete da informo
ke vi povas forpreni hodiaŭ.
Mi pardonpetas se mi irus super iu el viaj kapoj,
sed tie estas bona multajn fundamentaj fundamenta scio
ke mi pensas estas tre valoraj por vi.
Do dankon por havi min.
[Aplaŭdo]
Spektantaro: [inaudible] Estas kiam vi diras
vi devis iri tra la afero de la komenco ĝis la fino
akiri la rajton valoroj aŭ la samajn valorojn,
Kiel volus la valoroj ŝanĝi se [inaudible].
>> RICK Houlihan: Ho, kvadrategala?
Kiel volus la valoroj ŝanĝas?
Nu, ĉar se mi ne kuris ĝi la tutan vojon al la fino,
tiam mi ne scias kion ŝanĝas estis faritaj en la lasta mejlo.
Oni ne tuj estos la samajn datumojn kiel kion mi vidis.
Publiko: Ho, do vi simple ne alvenis la tuta enigo.
RICK Houlihan: Dekstra.
Vi devos iri de komenco al fino, kaj tiam estas
tuj esti kohera stato.
Malvarmeta.
>> Publiko: Do ​​vi montris nin DynamoDB povas fari dokumento aŭ la klavo valoro.
Kaj ni pasigis multan tempon en la ŝlosilo valoro kun hash kaj la manieroj
klaki ĝin ĉirkaŭ.
Kiam vi rigardis tiujn tablojn: estas ke lasante malantaŭ la dokumenton alproksimiĝo?
>> RICK Houlihan: mi ne diru lasante malantaŭe.
>> Publiko: Ili estis apartigitaj de the--
>> RICK Houlihan: Kun la dokumenton alproksimiĝo, la dokumento tipo en DynamoDB
estas nur pensi kiel alia atributo.
Ĝi estas atributo kiu enhavas hierarkia datumstrukturo.
Kaj poste en la demandoj, vi povas uzi la propraĵoj
de tiuj objektoj uzante Objekto Skribmaniero.
Do mi povas filtri iun nestitaj proprieto de la JSON dokumenton.
Publiko: Do ​​iam mi fari dokumenton alproksimiĝo,
Mi povas ordigi de alveni al la tabular--
Publiko: Absolute.
Publiko: --indexes kaj aferoj vi simple parolis.
RICK Houlihan: Yeah, la indeksoj kaj ĉiu tio,
kiam vi volas indekso la propraĵoj de la JSON,
la vojo, ke ni devus fari tion estas se enigata JSON objekto aŭ dokumenton
en Dinamo, vi uzus torentojn.
Riveretoj legus la enigo.
Vi akirus ke JSON kontesti kaj vi dirus OK,
kio estas la propraĵo Mi volas indekso?
>> Vi kreas devenaĵon tablo.
Nun tio estas tiel funkcias nun.
Ni ne permesas indekso rekte tiuj propraĵoj.
>> Publiko: Tabularizing viaj dokumentoj.
>> RICK Houlihan: Precize, ebenigo ĝin tabularizing Precize.
Tion vi faras per ĝi.
>> Publiko: Dankon.
>> RICK Houlihan: Yep, absolute, dankon.
Publiko: Do ​​ĝi estas speco de Mongo renkontas Redis classifers.
>> RICK Houlihan: Yeah, ĝi estas multe simila.
Tio estas bona priskribo por ĝi.
Malvarmeta.