[Muzika] RICK Houlihan: Në rregull. Çkemi të gjithë. Emri im është Rick Houlihan. Unë jam një drejtor i lartë Zgjidhjet arkitekt në AWS. Unë të përqëndrohet në NoSQL dhe Teknologjive DynamoDB. Jam këtu sot për të folur për ju pak për ata. 

Prejardhja ime është kryesisht në shtresën e të dhënave. Kam kaluar gjysmën zhvillimin tim Karriera e shkruar bazës së të dhënave, qasje të dhënat, zgjidhje për aplikacione të ndryshme. Unë kam qenë në Cloud Virtualization për rreth 20 vjet. Pra, para se Cloud ishte Cloud, kemi përdorur për të thirrur atë të shërbimeve informatikë. Dhe ideja ishte, është si PG & E, ju paguani për atë që ju përdorni. Sot ne e quajmë atë cloud. 

Por me kalimin e viteve, unë kam punuar për një çift të kompanive ju ndoshta keni dëgjuar kurrë të. Por unë kam përpiluar një listë të teknik arritjet, I guess ju do të thonë. Unë kam tetë patentave në sistemin Cloud Virtualization, dizajn mikroprocesor, përpunimi kompleks ngjarje, dhe fusha të tjera si edhe. 

Pra, këto ditë, unë të përqëndrohet kryesisht në NoSQL teknologjive dhe gjenerata e ardhshme bazës së të dhënave. Dhe kjo është në përgjithësi ajo që unë jam duke shkuar të jem këtu duke folur për ju sot rreth. Pra, çfarë ju mund të presin nga kjo seancë, ne do të kalojnë nëpër një të shkurtër Historia e përpunimit të të dhënave. Është gjithmonë e dobishme për kuptuar se ku kemi ardhur nga dhe pse ne jemi këtu ku jemi. Dhe ne do të flasim pak bit rreth teknologjisë NoSQL nga pikëpamja themelore. 

Ne do të merrni në disa prej internals DynamoDB. DynamoDB është AWS nr shije. Kjo është një menaxhuar plotësisht dhe priti zgjidhje NoSQL. Dhe ne do të flasim pak për tryezë Struktura, TV, tipet e te dhenave, indekseve, dhe disa internals e këtë teknologji DynamoDB. Ne do të merrni në disa nga dizajnit modelet dhe praktikat më të mira. Ne do të flasim si ju përdorin këtë teknologji për disa e aplikacioneve sotme. Dhe pastaj ne do të flasim pak për evoluimin ose shfaqjen i një paradigmë të re në programimin quajtur aplikacionet ngjarje të shtyrë dhe si luan DynamoDB në se si. Dhe ne do të ju lënë një grimë të vogël e një diskutim arkitekturë referencë kështu që ne mund të flasim për disa nga mënyrat që ju mund të përdorni DynamoDB. 

Pra, së pari off-- kjo është një pyetje Kam dëgjuar shumë është, çfarë është një bazë të dhënash. Shumë njerëz mendojnë se ata e di se çfarë është një bazë të dhënash. Nëse ju Google, ju do të shihni këtë. Kjo është një një grup të strukturuar e të dhënave të mbajtur në një kompjuter, veçanërisht një që është në dispozicion në mënyra të ndryshme. Unë mendoj se është një e mirë Përkufizimi i një bazë të dhënash moderne. Por unë nuk e pëlqen atë, sepse kjo nënkupton disa gjëra. Kjo nënkupton strukturën. Dhe kjo nënkupton se ajo është në një kompjuter. Dhe bazat e të dhënave nuk e bëri gjithmonë ekzistojnë në kompjuter. Bazat e të dhënave në fakt ka ekzistuar në shumë mënyra. 

Pra, një përkufizim më i mirë i një bazës së të dhënave është diçka si kjo. Një databazë është një i organizuar mekanizëm për ruajtjen, menaxhimin, dhe retrieving informacion. Kjo është nga About.com. Kështu që unë doja këtë, sepse me të vërtetë bisedimet në lidhje me një bazë të dhënash të qenë një depo, një depo e informacion, jo domosdoshmërisht diçka që ulet në një kompjuter. Dhe gjatë gjithë historisë, ne nuk kanë pasur gjithmonë kompjutera. 

Tani, në qoftë se unë kërkoj mesatare zhvilluesi sot çfarë është një bazë të dhënash, kjo është përgjigja unë shkoj. Diku unë mund të rrinë gjëra. E drejtë? Dhe kjo është e vërtetë. Por kjo është për të ardhur keq. Sepse baza e të dhënave është me të vërtetë themeli i app moderne. Është themeli e çdo kërkesë. Dhe si ju të ndërtuar atë bazës së të dhënave, si ju strukturojnë që të dhënat do të diktojë se si Aplikimi kryen si ju shkallë. 

Pra, një shumë e punës time sot merret me atë ndodh kur zhvilluesit marrë këtë qasje dhe që kanë të bëjnë me pasojat e një kërkesë që tani është shkallë përtej origjinale Qëllimi dhe vuajtje nga dizajni i keq. Kështu që shpresojmë se, kur ju ecin tutje sot, ju do të kanë një çift të mjeteve në rrip tuaj që do të ju mbajë nga bërja ato gabime të njëjta. Në rregull. Pra, le të flasim për një grimë të vogël të afati kohor i teknologjisë bazës së të dhënave. Unë mendoj se kam lexuar një artikull jo se shumë kohë më parë dhe ai tha diçka në lines-- kjo është një deklaratë shumë e poetik. Ai tha se historia e të dhënave të përpunimit është plot filigranë të lartë e të dhënave bollëk. NE RREGULL. Tani, unë mendoj se është lloj i vërtetë. Por, unë në fakt shohim është si historia është e mbushur në fakt me ujëra të lartë të presionit të dhënave. Për shkak se shkalla e të dhënave të gëlltitje kurrë nuk shkon poshtë. Ajo vetëm shkon deri. 

Dhe risi ndodh kur ne shohim presionin e të dhënave, e cila është sasia e dhëna që është tani në vijnë në sistem. Dhe kjo nuk mund të jenë të përpunuara efikase ose në kohë ose në kosto. Dhe kjo është kur ne fillojmë për të parë presionin e të dhënave. 

Pra, kur ne shikojmë në Baza e të dhënave të parë, kjo është ai që ishte në mes veshët tona. Ne jemi të gjithë të lindur me të. Kjo është një bazë të dhënash e bukur. Ajo ka një disponueshmërinë e lartë. Është gjithmonë në. Ju gjithmonë mund të merrni atë. 

Por kjo është përdorues të vetëm. Unë nuk mund të ndajnë mendimet e mia me ju. Ju nuk mund të merrni mendimet e mia kur ju doni ta. Dhe abilitiy i tyre nuk është aq i mirë. Ne harrojmë gjërat. Çdo tani dhe pastaj, njëri prej nesh lë dhe shkon në një tjetër ekzistencë dhe kemi humbur çdo gjë që ishte në atë bazë të dhënash. Pra, kjo nuk është e gjitha se e mirë. 

Dhe kjo ka funksionuar mirë me kalimin e kohës kur ishim mbrapa në ditë kur të gjithë ne me të vërtetë e nevojshme për të dini është ku do të shkojmë për të shkuar në nesër ose ku mblidhen ushqimin më të mirë. Por si kemi filluar të rritet si një Qytetërimi dhe qeveria ka filluar për të ardhur në ekzistencë, dhe Bizneset filluan të zhvillohet, kemi filluar për të realizuar ne nevojë për pak më shumë se çfarë ne mund të vënë në kokën tonë. Në rregull? 

Ne kishim nevojë për sistemet e rekord. Ne kishim nevojë për vende të jetë në gjendje të dhënave dyqan. Pra, kemi filluar dokumente me shkrim, krijuar bibliotekat dhe arkivat. Ne kemi filluar zhvillimin e një sistemi i kontabilitetit një libër i llogarive. Dhe se sistemi i librit numërimit vrapoi botën për shumë shekuj, dhe ndoshta edhe mijëvjeçarë si ne lloj i rrit deri në pikën ku se ngarkesa të dhënat tejkaluar aftësia e atyre sistemeve të jetë në gjendje për të kontrolluar atë. 

Dhe kjo në fakt ndodhi në 1880. E drejtë? Në SHBA Census 1880. Kjo është me të vërtetë ku kthese pikë përpunimin e të dhënave moderne. Kjo është pika në që shuma e të dhënave që ishte duke u mbledhur nga Qeveria e SHBA mori në pikën ku ai mori tetë vjet për të procesit. 

Tani, tetë years-- si ju e dini, regjistrimin shkon çdo 10 years-- kështu kjo është shumë e qartë se nga koha ne mori e regjistrimit 1890, shuma e dhëna që do të jenë të përpunuara nga qeveria ishte do të tejkalojnë 10 vjet që ajo do të marrë për të nisur regjistrimin e ri. Ky ishte një problem. 

Pra, një djalë i quajtur Herman Hollerith erdhi së bashku dhe ai shpiku njësi rekord grusht kartat, kartë shënoj lexues, kartë shënoj që hedh në tabelë, dhe krahasimin e mekanizmat për këtë teknologji. Dhe se kompania që ai formuar në kohë, së bashku me disa të tjerë, në fakt u bë një nga shtyllat e një kompani e vogël ne e dimë sot quhet IBM. 

Pra, IBM fillimisht ishte në biznesi bazës së të dhënave. Dhe kjo është me të vërtetë atë që ata vepruan. Ata e bënë përpunimin e të dhënave. 

Si kështu përhapjen e shënoj Kartat, një mekanizmat zgjuar të qenë në gjendje të levave që teknologji të sondazhit grupe renditura rezultat. Ju mund të shihni në këtë foto nuk kemi një little-- kjo është pak small--, por ju mund të shihni një mekanizëm shumë i zgjuar mekanike ku ne kemi një kuvertë kartë shënoj. Dhe marrja e dikujt një kaçavidë e vogël dhe fërkimit përmes lojëra elektronike dhe heqjen atë për të marrë atë ndeshje, që Rezultatet e renditura vendosur. 

Kjo është një grumbullimi. Ne e bëjmë këtë gjatë gjithë kohës sot në kompjuter, ku ju bëni atë në bazën e të dhënave. Ne kemi përdorur për të bërë atë me dorë, e drejtë? Njerëzit vënë këto gjëra së bashku. Dhe kjo ishte përhapja nga këto karta shënoj në atë që quhet bateri të dhënave dhe lëkundet dhënave, kasetë letër. 

Industria e përpunimit të të dhënave mori një mësim nga pianos lojtar. Player pianos mbrapa në radha e shekullit përdorur për të përdorur lëkundet letër me lojëra elektronike për të treguar atë që çelësat për të luajtur. Kështu që teknologjia ishte përshtatur përfundimisht për të ruajtur të dhënat digjitale, për shkak se ata mund të vënë ato të dhëna mbi këto makinë kasetë letër. 

Tani, si rezultat i kësaj, të dhënat e u actually-- si ju hyni në këto të dhëna ishte drejtpërdrejt varet nga ajo se ju ruajtur atë. Pra, nëse unë vendos të dhënat në një kasetë, Unë kisha hyrë në të dhënat linear. Unë kisha për të rrokulliset të gjithë kasetë për të hyrë në të gjitha të dhënat. Në qoftë se kam vënë të dhënat në grusht Kartat, unë mund të hyni në atë në pak më shumë të rastit modës, ndoshta jo aq shpejt. 

Por ka pasur kufizime në mënyrën se si ne qasje në të dhënat në bazë të se si është ruajtur. Dhe kështu që ky ishte një problem shkon në '50. Përsëri, ne mund të fillojmë të shohim se si ne zhvillimin e teknologjive të reja të procesit të dhënat, e drejtë, ajo hap dera për zgjidhje të reja, për programet e reja, të reja aplikimet për këto të dhëna. Dhe me të vërtetë, qeverisja mund të ketë qenë arsyeja pse ne kemi zhvilluar disa nga këto sisteme. Por biznesi shpejt u bë shoferi prapa evolucionit bazës së të dhënave modern dhe sistemi modern skedar. 

Pra, gjëja tjetër që doli ishte në '50 ishte sistemi skedar dhe zhvillimi i magazinimit Random Access. Kjo ishte e bukur. Tani, të gjithë e papritur, ne mund të vënë tonë fotografi kudo në këto hard drives dhe ne mund të hyni në këto të dhëna rastësisht. Ne mund të kuptoj se informacion nga e dosjeve. Dhe ne zgjidhur të gjithë në botë problemet me përpunimin e të dhënave. 

Dhe kjo zgjati rreth 20 ose 30 vjet deri në evolucionin bazës së të dhënave relacionale, e cila është kur bota ka vendosur ne tani duhet të ketë një depo që mposht plandosem e të dhënave në të gjithë file sisteme që ne kemi ndërtuar. E drejtë? Të dhënave shumë të shpërndara në shumë shumë vende, de-dyfishimin e të dhënave, dhe kostoja e magazinimit ishte shumë i madh. 

Në vitet '70, burimi më i shtrenjtë se një kompjuter ka qenë e magazinimit. Procesor ishte shihet si një kosto fikse. Kur unë blej kuti, CPU bën disa punë. Ajo do të jetë tjerrje nëse kjo është në fakt duke punuar apo jo. Kjo është me të vërtetë një kosto zhytur. 

Por çfarë kosto mua si një biznesit është ruajtje. Nëse unë kam për të blerë më shumë disqe të ardhshëm muaj, kjo është një e vërtetë që unë kosto të paguajnë. Dhe kjo magazinimit është e shtrenjtë. 

Tani ne shpejt përpara 40 vjet dhe ne kemi një problem tjetër. Të llogaritin tani është Burimi më i shtrenjtë. Magazinimit është i lirë. Unë do të thotë, ne mund të shkojnë kudo në cloud dhe ne mund të gjeni magazinimit të lirë. Por ajo që unë nuk mund të gjeni është llogaritje lirë. 

Pra, evoluimin e sotme teknologji, i teknologjisë së bazës së të dhënave, është e përqendruar me të vërtetë rreth Bazat e të dhënave të shpërndara që nuk vuajnë nga të njëjtin lloj të shkallës kufizimet e bazave të të dhënave relacionale. Ne do të flasim pak për çka do të thotë që në fakt. 

Por një nga arsyet dhe shoferi pas this-- ne foli për presionin e të dhënave. Presioni dhënave është diçka që drejton risi. Dhe në qoftë se ju shikoni në mbi pesë vitet e fundit, kjo është një tabelë e asaj të dhënave ngarkesës nëpër ndërmarrje e përgjithshme duket si në pesë vitet e fundit. 

Dhe rregulli i përgjithshëm i gishtit këto days-- qoftë se ju shkoni Google-- është 90% e të dhënave që ne dyqan sot, dhe kjo ishte gjeneruara brenda dy viteve të fundit. NE RREGULL. Tani, kjo nuk është një prirje që është e re. Kjo është një prirje që ka qenë shkojnë jashtë për 100 vjet. Që nga Herman Hollerith zhvilluar kartë shënoj, ne kemi qenë ndërtuar depo të dhënave dhe mbledhjes së të dhënave me ritme fenomenale. 

Pra, gjatë 100 viteve të fundit, ne kemi parë këtë trend. Kjo nuk do të ndryshojë. Duke shkuar përpara, ne jemi duke shkuar për të parë kjo, nëse nuk është një prirje të përshpejtuar. Dhe ju mund të shihni se si duket kjo. 

Nëse një biznes në vitin 2010 ka pasur një të tillë Terabyte e të dhënave nën menaxhim, sot kjo do të thotë se ata janë menaxhimin 6.5 petabytes të të dhënave. Kjo është 6.500 herë më shumë të dhënave. Dhe unë e di këtë. Unë punoj me këto biznese çdo ditë. Pesë vjet më parë, unë do të flasim për kompanitë të cilët do të bisedoni me mua në lidhje me atë që një dhimbje kjo është për të menaxhuar terabajt të dhëna. Dhe ata do të flasin për mua për mënyrën se si ne e shohim se kjo është ndoshta do të jetë një Petabyte ose dy brenda nja dy vjet. 

Këto kompani të njëjta sot unë jam takuar me, dhe ata janë duke folur për mua në lidhje me Problemi janë atje të pasur menaxhimin dhjetëra, 20 petabajtë e të dhënave. Pra, shpërthimin e të dhënat në industrinë e është leja e madhe nevojë për zgjidhje më të mira. Dhe baza e të dhënave relacionale është jo vetëm të jetojnë deri në kërkesën. 

Dhe kështu që nuk ka një linear korrelacion në mes të presionit të dhënave dhe risi teknike. Historia na ka treguar ky, që me kalimin e kohës, kur vëllimi i të dhënave që duhet të jenë të përpunuara e tejkalon kapacitetin e sistemit të përpunojë atë në një kohë të arsyeshme ose me një kosto të arsyeshme, teknologjitë e pastaj reja janë shpikur për të zgjidhur këto probleme. Këto teknologjive të reja, nga ana tjetër, të hapur derën për një tjetër grup të problemeve, të cilat është mbledhur edhe më shumë të dhëna. 

Tani, ne nuk jemi duke shkuar për të ndaluar këtë. E drejtë? Ne nuk jemi duke shkuar për të ndaluar këtë. Përse? Sepse ju nuk mund të di çdo gjë ka të dini në univers. Dhe për aq kohë sa ne kemi qenë gjallë, gjatë gjithë historisë së njeriut, ne kemi shtyrë gjithmonë të dini më shumë. 

Pra, duket si çdo pëllëmbë të lëvizur poshtë në rrugën e zbulimit shkencor, ne jemi shumëzuar sasinë e të dhënave se ne kemi nevojë të procesit në mënyrë eksponenciale si ne zbulojë gjithnjë e më shumë e më shumë për punët e brendshme të jetës, për mënyrën se si funksionon universi, në lidhje me ngarje zbulimin shkencor, dhe shpikje që ne jemi duke bërë sot. Vëllimi i të dhënave të vetëm vazhdimisht rritet. Pra, duke qenë në gjendje të merren me ky problem është i madh. 

Pra, një nga gjërat ne shikojmë si pse NoSQL? Si funksionon NoSQL zgjidhur këtë problem? E pra, databaza relacionale, Structured Query Language, SQL-- kjo është me të vërtetë një konstrukt i relacionale database-- këto gjëra janë optimizuar për ruajtje. 

Kthehu në vitet '70, përsëri, disk është e shtrenjtë. Ushtrimi sigurimin e ruajtjes në ndërmarrje është i pafund. E di. Kam jetuar atë. Kam shkruar Shoferët e magazinimit për një Kompania enterprised Superserveri prapa në vitet '90. Dhe në fund është tortues tjetër Grup magazinimit ishte vetëm diçka që ndodhi çdo ditë në ndërmarrje. Dhe ajo kurrë nuk ndalet. Magazinimit të Lartë dendësia, kërkesa për ruajtjen densitet të lartë, dhe për ruajtjen më efikas devices-- ajo kurrë nuk ndalet. 

Dhe NoSQL është një teknologji e madhe sepse ajo normalizes të dhënat. Ajo de-dyfishon të dhënat. Ajo vë të dhënat në një strukturë që është agnostik për çdo model të qasjes. Aplikacionet e shumta mund të goditur atë SQL databazë, të drejtuar pyetje ad hoc, dhe për të marrë të dhënat në formën që ata nevojë për të procesit për Ngarkesat e punës tyre. Kjo tingëllon fantastike. Por në fund është me ndonjë sistem, në qoftë se është agnostik për çdo gjë, ajo është e optimizuar për asgjë. NE RREGULL? 

Dhe kjo është ajo që ne të merrni me baza e të dhënave relacionale. Është e optimizuar për ruajtje. Është normalizuar. Është relacionale. Ajo mbështet pyetje ad hoc. Dhe kjo dhe kjo peshore vertikalisht. 

Nëse unë duhet të merrni një bazë të dhënash të madhe SQL ose një bazë të dhënash më të fuqishëm SQL, Unë shkoj të blej një copë të madhe të hekurit. NE RREGULL? Unë kam punuar me një shumë të konsumatorëve që kanë qenë përmes përmirësimeve të mëdha në infrastrukturën e tyre SQL vetëm për të gjetur se gjashtë muaj më vonë, ata janë goditur murin përsëri. Dhe përgjigja nga Oracle apo MSSQL ose dikush tjetër është për të marrë një kuti të madhe. E pra shpejt ose më vonë, ju nuk mund të blejnë një më e madhe kuti, dhe ky është problemi i vërtetë. Ne kemi nevojë që në fakt ndryshojnë gjërat. Pra, ku e bën këtë punë? Ajo punon mirë për offline analytics, Ngarkesat e punës OLAP tipit. Dhe kjo është me të vërtetë ku SQL takon. Tani, ajo është përdorur sot në shumë Online transaksional përpunimit të tipit aplikimet. Dhe ajo punon vetëm gjobë në një nivel të shfrytëzimit, por ai thjesht nuk shkallë mënyra se si NoSQL bën. Dhe ne do të flasim pak bit se pse kjo është. 

Tani, NoSQL, nga ana tjetër, është më shumë e optimizuar për llogaritjen. NE RREGULL? Kjo nuk është agnostik për model qasje. Është ajo që ne e quajmë de-normalizuar struktura ose një strukturë hierarkike. Të dhënat në një bazë të dhënash relacionale është bashkuar nga tavolina të shumta për të prodhuar pamje që ju duhet. Të dhënat në bazën e të dhënave NoSQL është ruajtur në një dokument që përmban strukturën hierarkike. Të gjitha të dhënave që normalisht do të jetë u bashkuan së bashku për të prodhuar këtë pikëpamje është ruajtur në një dokument të vetëm. Dhe ne do të flasim pak për si që punon në një çift të Listat. 

Por ideja këtu është se ju dyqan të dhënat tuaja si këto pikëpamje instantiated. NE RREGULL? Ju shkallë horizontalisht. E drejtë? Nëse kam nevojë për të rritur Madhësia e NoSQL grup tim, Unë nuk kam nevojë për të marrë një kuti të madhe. Kam marrë një tjetër kuti. Dhe unë grumbull ato së bashku, dhe unë mund të copë e thyer ato të dhëna. Ne do të flasim pak për çfarë sharding është, që të jetë në gjendje për të shkallë që bazën e të dhënave gjithë pajisjeve të shumta fizike dhe për të hequr pengesën që kërkon që më në shkallë vertikalisht. 

Pra, është e ndërtuar me të vërtetë për internet përpunimi transaksion dhe shkallë. Ka një dallim i madh këtu në mes të raportimit, e drejtë? Raportimi, unë nuk e di Pyetje Unë jam duke shkuar për të pyetur. E drejtë? Reporting-- nëse dikush nga departamenti im i marketingut dëshiron të just-- Sa nga klientët e mi kanë këtë karakteristikë të veçantë që blerë në këtë day-- unë nuk e di çfarë pyetje ata do të pyes. Kështu që unë duhet të jenë agnostik. 

Tani, në një Online Aplikimi transaksional, Unë e di se çfarë pyetje unë jam duke kërkuar. I ndërtuar aplikimin për një workflow shumë specifik. NE RREGULL? Pra, nëse unë zgjedh të dhënave dyqan për të mbështetur këtë punës, ajo do të jetë më i shpejtë. Dhe kjo është arsyeja pse NoSQL mund me të vërtetë të përshpejtojë shpërndarjen e këtyre llojeve të shërbimeve. Në rregull. 

Pra, ne jemi duke shkuar për të marrë në pak e teorisë këtu. Dhe disa prej jush, sytë tuaj mund të rrokulliset përsëri pak. Por unë do të përpiqemi për ta mbajtur atë nivel të lartë si unë mund. Pra, nëse ju jeni në projekt menaxhimit, ka një konstrukt quajtur trekëndësh i kufizimeve. NE RREGULL. Trekëndëshi i kufizon diktatit ju nuk mund të keni gjithçka gjatë gjithë kohës. Nuk mund të ketë byrek tuaj dhe të hani atë shumë. Pra, në menaxhimin e projekteve, që trekëndësh Kufizimet është që ju mund të keni atë të lirë, ju mund të keni atë të shpejtë, ose ju mund të keni atë mirë. Pick dy. Sepse ju nuk mund të ketë të gjitha tre. E drejtë? NE RREGULL. 

Pra, keni dëgjuar për këtë shumë. Është një detyrim trefishtë, trekëndësh i kufizimit të trefishtë, ose trekëndësh hekuri është oftentimes-- kur ju bisedoni me menaxherët e projektit, ata do të flasin për këtë. Tani, Bazat e të dhënave kanë vetë trekëndësh tyre hekuri. Dhe trekëndësh hekurt e të dhënave është ajo që ne e quajmë CAP teorema. NE RREGULL? 

CAP dikton teorema si bazave të të dhënave të veprojë nën një gjendje shumë të veçantë. Dhe ne do të flasim për se çfarë gjendje është. Por tre pikat e trekëndëshit, kështu që të flasin, janë C, qëndrueshmëri. NE RREGULL? Pra në CAP, qëndrueshmëri do të thotë se të gjithë Klientët të cilët mund të hyni bazën e të dhënave gjithmonë do të ketë një shumë të pamje konsistente e të dhënave. Gonna të askujt të shihni dy gjëra të ndryshme. NE RREGULL? Nëse unë shoh bazën e të dhënave, Unë jam duke parë të njëjtin mendim si partnerin tim që sheh e njëjta bazës së të dhënave. Kjo është e qëndrueshmëri. 

Disponueshmëria do të thotë se në qoftë se bazës së të dhënave në internet, në qoftë se ajo mund të arrihet, që të gjithë klientët do të gjithmonë të jenë në gjendje të lexojnë dhe shkruajnë. NE RREGULL? Pra, çdo klient që mund të lexoni bazën e të dhënave do të jetë gjithmonë në gjendje lexuar të dhënave dhe shkruar të dhëna. Dhe në qoftë se është e rastit, është një sistem në dispozicion. 

Dhe pika e tretë është se çfarë ne e quajmë tolerancë ndarje. NE RREGULL? Mjetet tolerancës Ndarja se sistemi punon mirë pavarësisht rrjetit fizik ndarëse midis nyjet. NE RREGULL? Pra, nyjet në grup nuk mund bisedoni me njëri-tjetrin, çfarë ndodh? Në rregull. 

Bazave të të dhënave relacionale Pra choose-- ju mund të vini dy nga këto. NE RREGULL. Bazave të të dhënave relacionale Pra zgjidhni të jenë në përputhje dhe në dispozicion. Nëse ndarja ndodh në mes të DataNodes në dyqan e të dhënave, baza e të dhënave crashes. E drejtë? Ajo thjesht shkon poshtë. NE RREGULL. 

Dhe kjo është arsyeja pse ata kanë të rritet me kuti të mëdha. E drejtë? Sepse nuk ka no-- zakonisht, një grup bazës së të dhënave, nuk është shumë e shumë prej tyre që veprojnë në këtë mënyrë. Por shumica e bazave të të dhënave në shkallë vertikalisht në një kuti vetme. Sepse ata duhet të jenë të në përputhje dhe në dispozicion. Në qoftë se një ndarje duhej të injektuar, atëherë ju do të keni për të bërë një zgjedhje. Ju duhet të bëni një zgjedhje në mes të qenë në përputhje dhe në dispozicion. 

Dhe kjo është ajo që bëjnë bazat e të dhënave NoSQL. Në rregull. Pra, një bazë të dhënash NoSQL, atë vjen në dy flavors. Ne have-- mirë, atë vjen në shumë lloje, por ajo vjen me dy themelore characteristics-- çfarë ne do të thërrasë bazë të dhënash CP, apo një tolerancë të qëndrueshme dhe ndarje sistem. Këta njerëz të bëjë zgjedhjen që kur nyjet humb kontakt me njëri-tjetrin, ne nuk jemi duke shkuar për të lejuar njerëzit për të shkruar ndonjë më shumë. NE RREGULL? 

Deri në se ndarja është hequr, Qasje shkruaj është bllokuar. Kjo do të thotë se ata nuk janë në dispozicion. Ata janë në përputhje. Kur ne shohim se ndarje injektuar veten, ne tani janë në përputhje, sepse ne nuk jemi duke shkuar për të lejuar ndryshimin e të dhënave në dy anët e ndarjes në mënyrë të pavarur nga njëra-tjetra. Ne do të duhet të rivendosur komunikimin para çdo update të dhënave është e lejuar. NE RREGULL? 

Shije i ardhshëm do të jetë një sistem AP, ose një në dispozicion dhe e ndarë sistem toleranca. Këta njerëz nuk e kujdesit. E drejtë? Çdo nyje që merr një shkruaj, ne do të marrë atë. Kështu që unë jam përsëritur të dhënat e mia nëpër nyje të shumta. Këto nyje të merrni një klient, klient vjen në, thotë, unë jam duke shkuar për të shkruar disa të dhëna. Nyja thotë, nuk ka problem. Nyja pranë tij merr një Shkruani në të njëjtën rekord, ai do të thotë nuk ka problem. Diku prapa në anën e pasme, që të dhënat do të replikuar. Dhe pastaj dikush do të realizojë, uh-oh, sistem ata do të kuptojnë, uh-oh, ka pasur një update për të dy palëve. Çfarë bëjmë ne? Dhe çfarë bëjnë ata atëherë është ata bëjnë diçka që u lejon atyre për të zgjidhur atë shtet të dhënave. Dhe ne do të flasim për që në tabelë ardhshëm. 

Gjë për të nxjerr në pah këtu. Dhe unë nuk jam duke shkuar për të marrë shumë shumë në këtë, sepse ky merr në teorinë e të dhënave të thellë. Por ka një transaksional kornizë që shkon në një sistem relacionale që lejon mua për të në mënyrë të sigurtë të rejat të subjekteve të shumta në bazën e të dhënave. Dhe ato më të reja do të ndodhë të gjitha në të njëjtën kohë ose aspak. Dhe kjo quhet transaksioneve acid. NE RREGULL? 

ACID na jep atomicity, qëndrueshmëri, izolimi, dhe qëndrueshmëri. NE RREGULL? Kjo do të thotë atomike, transaksionet, të gjithë Përditësimet e mia ose të ndodhë, ose ata nuk e bëjnë. Konsistenca do të thotë se baza e të dhënave do të gjithmonë të sillen në një të qëndrueshme shteti pas një update. Unë kurrë nuk do të largohet bazën e të dhënave në një gjendja e keqe pas aplikimit një update. NE RREGULL? 

Pra, kjo është pak më ndryshe se konsistencës CAP. Qëndrueshmëri CAP do të thotë të gjithë e mia Klientët mund gjithmonë të shohin të dhënat. Konsistencë ACID do të thotë se kur një transaksion është bërë, të dhënat e të mirë. Marrëdhëniet e mia janë të gjithë të mirë. Unë nuk jam duke shkuar për të fshirë një rresht prind dhe të lënë një bandë e fëmijëve jetimë në ndonjë tryezë tjetër. Kjo nuk mund të ndodhë në qoftë se unë jam në përputhje në një transaksion acid. 

Izolimi do të thotë se transaksionet gjithmonë do të ndodhë njëri pas tjetrit. Rezultati përfundimtar i të dhënave do të jetë e njëjtë shteti sikur ato transaksione që janë lëshuar njëkohësisht u ekzekutuan në seri. Pra, kjo është concurrency kontrolli në bazën e të dhënave. Pra, në thelb, unë nuk mund të rrisim njëjtën vlerë dy herë me dy operacione. 

Por në qoftë se unë them shtoni 1 për këtë vlerë, dhe dy transaksione të vijë në dhe të përpiqet të bëjë atë, një është do të merrni atje në fillim dhe tjetra e do të merrni atje pas. Pra, në fund, kam shtuar dy. Ju shihni se çfarë dua të them? NE RREGULL. 

Qëndrueshmëri është shumë i thjeshtë. Kur transaksioni është pranuar, është do të jetë aty edhe nëse sistemi crashes. Kur se sistemi rimëkëmbet, që transaksion që është kryer është në të vërtetë do të jetë atje. Pra, kjo është garanton e transaksioneve acid. Ata janë garanci pretty nice që të ketë në një bazë të dhënash, por ata vijnë në atë kosto. E drejtë? 

Për shkak të problemit me këtë kornizë është nëse ka një ndarje në të dhënat vendosur, unë kam për të marrë një vendim. Unë do të ketë për të lejuar Përditësimet në njërën anë apo tjetrën. Dhe nëse kjo ndodh, atëherë unë nuk jam duke shkuar të jetë në gjendje për të ruajtur këto karakteristika. Ata nuk do të jenë në përputhje. Ata nuk do të jenë të izoluara. Kjo është ajo ku ajo prishet për bazat e të dhënave relacionale. Kjo është arsyeja relacionale Bazat e të dhënave shkallë vertikalisht. 

Në anën tjetër, ne kemi atë që quhet teknologji BASE. Dhe këto janë Bazat e të dhënave tuaja NoSQL. Në rregull. Pra, ne kemi CP tonë, bazave të AP. Dhe këto janë ato që ju e quani në thelb në dispozicion, shteti të butë, përfundimisht në përputhje. NE RREGULL? 

Në thelb në dispozicion, sepse ata janë ndarja tolerant. Ata gjithmonë do të jetë atje, edhe në qoftë se ka një ndarje rrjet në mes të nyjeve. Në qoftë se unë mund të flas me një nyje, unë jam do të jetë në gjendje për të lexuar të dhënat. NE RREGULL? Unë nuk mund të jetë gjithmonë në gjendje për të shkruar të dhëna në qoftë se unë jam një platformë të qëndrueshme. Por unë do të jetë në gjendje për të lexuar të dhënat. 

Shteti butë tregon që kur kam lexuar se të dhënat, kjo mund të mos jetë e njëjtë si nyjet e tjera. Në qoftë se një e drejtë është lëshuar në një nyje diku tjetër në grup dhe kjo nuk ka përsëriten Përtej Grumbulli por kur lexova se të dhënat, se shteti mund të mos jenë në përputhje. Megjithatë, ajo do të jetë përfundimisht në përputhje, do të thotë se kur një shkruaj është bërë për të sistemit, ajo do të përsëris të gjithë nyjet. Dhe përfundimisht, ai shtet do të sillet në mënyrë, dhe kjo do të jetë një shtet i qëndrueshëm. 

Tani, CAP teorema vërtetë luan vetëm në një kusht. Se gjendja është kur kjo ndodh. Sepse sa herë që e veprojnë në Mënyra normale, nuk ka ndarje, çdo gjë është në përputhje dhe në dispozicion. Ju shqetësohen vetëm për CAP kur ne kemi këtë ndarje. Kështu që ata janë të rralla. Por se si sistemi reagon kur ata ndodhë diktojnë se çfarë lloji i sistemit ne jemi që kanë të bëjnë me të. 

Pra, le të marrin një vështrim në atë që që duket si për sistemet AP. NE RREGULL? Sistemet AP vijnë në dy flavors. Ata vijnë në shije që është një mjeshtër mjeshtër, 100%, gjithmonë në dispozicion. Dhe ata vijnë në shije të tjera, që thotë: ju e dini se çfarë, unë jam duke shkuar për t'u shqetësuar në lidhje me këtë gjë ndarjes kur një ndarje aktuale ndodh. Përndryshe, nuk do të jetë primar nyjet që do të marrë të drejtat. NE RREGULL? 

Pra, nëse ne diçka si Cassandra. Cassandra do të jetë një mjeshtër mjeshtër, le të më shkruajë për çdo nyje. Pra, çfarë ndodh? Kështu që unë kam një objekt në bazës së të dhënave që ekziston në dy nyjeve. Le të thërrasë atë objekt S. Pra, ne kemi shtetin për S. Ne kemi disa operacione në S që janë në vazhdim. Cassandra lejon mua që të shkruani në nyje të shumta. Pra, le të thonë se unë të marrë një shkruaj për s për të dy nyjeve. E pra, ajo që përfundon deri ndodh është ne e quajmë atë një ngjarje të ndarjes. Nuk mund të jetë një ndarje fizike të rrjetit. Por për shkak të dizajnit e sistemit, është e në fakt ndarjes sa më shpejt si unë të marrë një të shkruaj mbi dy nyjeve. Kjo nuk është e detyruar mua për të shkruaj gjatë gjithë një nyje. Unë jam me shkrim në dy nyje. NE RREGULL? 

Deri tani unë kam dy shtete. NE RREGULL? Çfarë do të ndodhë është herët a vonë, atje do të jetë një ngjarje e përsëritje. Nuk do të jetë ajo që ne quhet një shërim ndarje, e cila është vendi ku këto dy shtetet të vijnë përsëri së bashku dhe atje do të jetë një algoritmi që shkon brenda bazën e të dhënave, vendos se çfarë të bëjmë. NE RREGULL? By default, përditësimi i fundit fiton në shumicën e sistemeve AP. Pra, ka zakonisht një parazgjedhur algorithm, çfarë ata e quajnë një callback funksion, diçka që do të quhet kur ky kusht është zbuluar për të ekzekutuar disa logjikën për të zgjidhur këtë konflikt. NE RREGULL? Callback parazgjedhur dhe parazgjedhur zgjidhës në shumicën e bazave të të dhënave AP është, guess what, timestamp fiton. Kjo ishte përditësimi i fundit. Unë jam duke shkuar për të vënë atë përditësim në atje. Unë mund të hale këtë rekord që unë hedhur jashtë në një regjistër të rimëkëmbjes në mënyrë që përdoruesi mund të kthehen më vonë dhe thonë, hej, ka pasur një përplasje. Cfare ndodhi? Dhe ju në fakt mund të hale një rekord të të gjitha goditjet dhe rollbacks dhe shikoni se çfarë ndodh. 

Tani, si një përdorues, ju gjithashtu mund të përfshijnë logjikën në atë callback. Kështu që ju mund të ndryshojë atë operacion callback. Ju mund të thoni, hej, unë dua për të ndrequr këto të dhëna. Dhe unë dua të provoni dhe bashkojë këto dy shënime. Por kjo është deri te ju. Baza e të dhënave nuk e di se si për të bëjnë që nga default. Shumica e kohës, e vetmja gjë që baza e të dhënave e di se si të bëni është të themi, ky ishte rekord fundit. Kjo është ajo që do të fitojë, dhe kjo është vlera që unë jam duke shkuar për të vënë. Pasi atij shërim ndarje dhe përsëritje ndodh, ne kemi shtetin tonë, i cili tani është S kryesor, i cili është gjendja bashkojë të gjitha ato objekte. Pra sistemet AP të ketë këtë. Sistemet CP nuk kanë nevojë për t'u shqetësuar për këtë. Sepse sa më shpejt që vjen një ndarje në lojë, ata vetëm të ndaluar marrjen shkruan. NE RREGULL? Pra, kjo është shumë e lehtë për të merren me të qenit në përputhje kur ju nuk e pranoni ndonjë më të reja. Kjo është me sistemet CP bëjë. Në rregull. 

Pra, le të flasim pak bit për modelet e aksesit. Kur ne flasim për NoSQL, është të gjitha në lidhje me modelin e qasjes. Tani, SQL është ad hoc, pyetje. Është dyqan relacionale. Ne nuk duhet të shqetësohen në lidhje me modelin e qasjes. Unë shkruaj një pyetje shumë komplekse. Ajo shkon dhe merr të dhënat. Kjo është ajo që kjo duket si, normalizimi. 

Pra, në këtë strukturë të veçantë, ne jemi duke kërkuar në një katalog produkteve. Unë kam lloje të ndryshme të produkteve. Kam libra. Unë kam albume. Kam video. Marrëdhënia në mes të produkteve dhe çdo një nga këto libra, albume, dhe video tavolina është 1: 1. Në rregull? Unë kam marrë një ID të produktit, dhe që i përgjigjet ID në një libër, një album, ose një video. NE RREGULL? Kjo është një 1: 1 marrëdhënie nëpër ato tavolina. 

Tani, të gjithë ata books-- kanë është prona rrënjë. Nuk ka problem. Kjo është e madhe. Një-për-një marrëdhënie, Unë të marrë të gjitha të dhënat Unë kam nevojë për të përshkruar atë libër. Albume Albums-- kanë gjurmët. Kjo është ajo që ne e quajmë njëri shumë. Çdo album do të ketë shumë këngë. Pra, për çdo udhë në album, unë mund të ketë një tjetër rekord në këtë tabelë fëmijëve. Kështu që unë krijoj një rekord në tryezën albumet e mia. I krijuar regjistrime të shumëfishta në tabelën gjurmët. Marrëdhënie një-me-shumë. 

Kjo marrëdhënie është çfarë ne e quajmë shumë-me-shumë. NE RREGULL? Ju shihni se aktorët mund të jetë në shumë filma, shume video. Pra, ajo që ne bëjmë është ne kemi vënë këtë hartë tavolinë mes atyre, që ai vetëm harta ID aktorit në ID videove. Tani unë mund të krijojë një query bashkohet video përmes aktorit video për aktorët, dhe kjo më jep një listë e bukur e të gjitha filmat dhe të gjithë aktorët që ishin në atë film. 

NE RREGULL. Pra, këtu ne do të shkojmë. Një-për-një është e nivelit të lartë marrëdhënie; një-për-shumë, Albumet më gjurmët; shumë-me-shumë. Ata janë tre të nivelit të lartë marrëdhëniet në çdo bazë të dhënash. Nëse ju e dini se si ata marrëdhëniet punojnë së bashku, atëherë ju e dini shumë në lidhje me bazën e të dhënave tashmë. Pra NoSQL punon pak ndryshe. Le të mendojmë për një të dytë për atë që Duket si për të shkuar të marrë të gjitha produktet e mia. 

Në një dyqan relacionale, unë doni të merrni të gjitha produktet e mia në një listë të të gjitha produktet e mia. Kjo është një shumë e pyetje. Unë kam një pyetje për të gjithë librat e mi. Unë kam një pyetje nga albumet e mia. Dhe unë kam një pyetje për të gjithë videot e mia. Dhe kam marrë për ta vënë atë të gjithë së bashku në një listë dhe për të shërbyer atë deri në të kërkesë që e kërkon atë. 

Për të marrë librat e mi, unë bashkohem Produktet dhe libra. Për të marrë albumet e mia, kam marrë për t'u bashkuar Produkte, Albume, dhe gjurmët. Dhe për të marrë videot e mia, unë kam për t'u bashkuar Produkte të Videos, bashkohen përmes aktor Videos, dhe për të sjellë në Aktorët. Pra, kjo është tre pyetje. Pyetje shumë komplekse për të mblidhen një grup rezultat. 

Kjo është më pak se optimale. Kjo është arsyeja pse kur flasim në lidhje me një strukturë të dhënave që është ndërtuar që të jetë agnostik për qasje pattern-- mirë që është e madhe. Dhe ju mund të shihni këtë është me të vërtetë mirë se si ne kemi organizuar e të dhënave. Dhe ju e dini se çfarë? Kam vetëm një rekord për një aktor. 

Kjo është e ftohtë. Unë e kam deduplicated gjithë aktorët e mia, dhe unë mbajtur shoqatat e mia në këtë tabelë hartës. Megjithatë, duke marrë të dhënat e jashtë bëhet i shtrenjtë. Unë jam i dërguar CPU në të gjithë sistemin e bashkimin e këtyre strukturave të dhënave së bashku të jetë në gjendje për të tërhequr këto të dhëna mbrapa. 

Pra, si mund unë të marrë rreth se? Në NoSQL është në lidhje grumbullimi, jo normalizimi. Pra, ne duam të themi se duam të mbështesin modelin qasje. Nëse modelin e qasjes të aplikimeve, Unë kam nevojë për të marrë të gjitha produktet e mia. Le të vënë të gjitha produktet në një tryezë. Nëse unë vënë të gjitha produktet në një tryezë, Unë vetëm mund të zgjidhni të gjitha produktet nga ajo tryezë dhe unë të marrë të gjitha. Pra si mund ta bëni këtë? Edhe në NoSQL nuk ka asnjë Struktura në tryezë. Ne do të flasim pak për se si kjo punon në Dynamo DB. Por ju nuk keni të njëjtin atributet dhe të njëjtat pronat në çdo rresht të vetëm, në çdo të vetme pika, si ju bëni në një tryezë SQL. Dhe çfarë kjo lejon mua të bëni është një shumë gjëra dhe jepni një shumë fleksibilitet. Në këtë rast të veçantë, unë kanë dokumentet e mia të produktit. Dhe në këtë të veçantë shembull, çdo gjë është një dokument në tabelën e produkteve. Dhe produkt për një libër të fuqisë kanë një ID tip që përcakton një libër. Dhe aplikimi do të kaloni në këtë ID. 

Në grupin e aplikimit, unë jam duke shkuar për të thënë oh, çfarë lloji rekord është kjo? Oh, kjo është një rekord libër. Librin kanë këto prona. Më lejoni të krijoni një objekt libër. Kështu që unë jam duke shkuar për të mbushur objekt libër me këtë artikull. Pika tjetër vjen dhe thotë, çfarë është kjo artikull? E pra ky artikull është një album. Oh, kam marrë një të tërë të ndryshme përpunimit rutinë për atë, sepse kjo është një album. Ju shihni se çfarë dua të them? 

Pra, kërkesa tier-- unë thjesht zgjidhni të gjitha këto shënime. Ata të gjithë të fillojnë të vijnë në. Ato mund të jenë të gjitha llojet e ndryshme. Dhe kjo është logjika e aplikimit që kalon nëpër ato lloje dhe vendos se si të përpunojë ato. 

Përsëri, kështu që ne jemi optimizimin e skema për modelin qasje. Ne jemi duke bërë atë me kolaps ato tavolina. Ne jemi në thelb duke marrë këto struktura normalizuar, dhe ne jemi duke ndërtuar struktura hierarkike. Brenda secilit prej këtyre të dhënave Unë jam duke shkuar për të parë pronat e array. 

Brenda këtij dokumenti për albume, Unë jam duke parë vargjeve të pista. Këto këngë tani become-- është Në thelb kjo tabelë fëmijë që ekziston e drejtë këtu në këtë strukturë. Kështu që ju mund ta bëni këtë në DynamoDB. Ju mund ta bëni këtë në MongoDB. Ju mund ta bëni këtë në çdo bazë të dhënash NoSQL. Krijo këto lloje të strukturat e të dhënave hierarkike që ju lejon të rifitoj të dhënave shumë shpejt, sepse tani unë nuk duhet të jenë në përputhje. Kur kam futur një rresht në gjurmët tavolinë, ose një rresht në tabelën e albume, Unë duhet të jenë në përputhje me këtë skemë. Unë duhet të ketë atribut ose Prona që është përcaktuar në këtë tryezë. Çdo njëri prej tyre, kur kam futur atë rresht. Kjo nuk është rasti në NoSQL. 

Unë mund të ketë krejtësisht të ndryshme Pronat në çdo dokument që kam futur në koleksion. Mekanizëm aq shumë i fuqishëm. Dhe kjo është me të vërtetë si ju zgjedh sistemin. Sepse tani këtë pyetje, në vend i bashkuar të gjitha këto tabelat dhe ekzekutimin e një një duzinë e gjysmë pyetje për të tërhequr mbrapsht të dhënat kam nevojë, Unë jam ekzekutimin e një pyetje. Dhe unë jam iterating të gjithë rezultatet e përcaktuara. kjo ju jep një ide e fuqisë së NoSQL. Unë jam duke shkuar për të shkuar lloj anash këtu dhe flasim pak për këtë. Kjo është më shumë lloj i marketingu apo technology-- marketingu i teknologjisë lloji i diskutimit. Por është e rëndësishme për të kuptuar sepse nëse ne shikojmë në krye këtu në këtë tabelë, ajo që ne jemi duke kërkuar në është ajo që ne e quajmë teknologji hype kurbë. Dhe çfarë kjo do të thotë është gjëra të reja vjen në lojë. Njerëzit mendojnë se është e madhe. Unë e kam zgjidhur të gjitha problemet e mia. 

Kjo mund të jetë fundi të gjithë, të jenë të gjitha për çdo gjë. Dhe ata të fillojnë duke e përdorur atë. Dhe ata thonë, kjo stuff nuk funksionon. Kjo nuk është e drejtë. Stuff vjetër ishte më i mirë. Dhe ata të shkojnë përsëri për të bërë të gjëra mënyra se si ata ishin. Dhe pastaj në fund ata të shkojnë, ju e dini se çfarë? Kjo stuff nuk është aq e keqe. Oh, kjo është se si funksionon. Dhe një herë ata të kuptoj se si ajo Punimet, ata fillojnë të shkojnë më mirë. 

Dhe gjëja qesharake në lidhje me të është, ai lloj i linjave deri në çfarë ne e quajmë Curve Teknologji birësimin. Pra, çfarë ndodh është që ne kemi disa shkaktojë teknologji lloj. Në rastin e bazave të të dhënave, kjo është presion dhënave. Ne biseduam në lidhje me pikat e larta të ujit e presionit të dhënave gjatë gjithë kohës. Kur se presioni dhënat e godet një të caktuar pikë, kjo është shkas teknologji. 

Është duke u shumë të shtrenjta. Ajo merr shumë kohë për të përpunuar të dhënat. Ne kemi nevojë për diçka më të mirë. Ju merrni risimtarët atje endet, duke u përpjekur për të gjetur se çfarë është zgjidhja. Çfarë është ideja e re? 

Çfarë është më e mirë mënyrë për të bërë këtë gjë? Ata vijnë me diçka. Dhe njerëzit me dhimbje e vërtetë, djemtë në buzë gjakderdhje, ata do të hidhen mbi të gjitha, sepse ata kanë nevojë për një përgjigje. Tani ajo që në mënyrë të pashmangshme happens-- dhe kjo po ndodh tani në NoSQL. Unë shoh atë gjatë gjithë kohës. 

Çfarë ndodh në mënyrë të pashmangshme është njerëzit fillojnë duke përdorur mjet të ri në të njëjtën mënyrë ata kanë përdorur mjet vjetër. Dhe ata e gjejnë atë jashtë nuk punon aq mirë. Unë nuk mund të mbani mend kush isha duke folur për të më parë sot. Por kjo është si, kur Jackhammer u shpik, njerëzit nuk e lëkundur atë mbi kreu i tyre për të goditur konkrete. 

Por kjo është ajo që është ndodh me NoSQL sot. Në qoftë se ju ecni në të shumicën e dyqaneve, ata janë duke u përpjekur të jenë dyqane NoSQL. Çfarë ata po bëjnë është ata janë duke përdorur NoSQL, dhe ata janë të ngarkimit atë plot me skemen relacionale. Sepse kjo është se si ata të hartuar bazat e të dhënave. Dhe ata jeni të pyesin, pse është ajo nuk kryen shumë mirë? Boy, kjo gjë stinks. Unë kisha për të ruajtur të gjithë e mia bashkohet in-- është si, jo, jo. Ruajtja e bashkohet? Pse jeni bashkuar të dhënat? Ju nuk mund të bashkohet me të dhënat në NoSQL. Ju agregate atë. 

Pra, nëse ju doni të shmangur këtë, të mësojnë si mjet punon para se të vërtetë filloni duke e përdorur atë. Nuk do të përpiqet dhe të përdorin mjete të reja njëjtën mënyrë keni përdorur mjetet e vjetra. Ju jeni do të ketë një përvojë të keqe. Dhe çdo herë të vetme kjo është ajo që kjo është rreth. Kur ne fillojmë të ardhur deri këtu, kjo është për shkak se njerëzit me motive nga se si të përdorin mjetet. 

Ata e bënë të njëjtën gjë kur databaza relacionale ishin shpikur, dhe ata ishin zëvendësuar file sistemeve. Ata u përpoqën të ndërtojnë file sistemeve me bazat e të dhënave relacionale sepse kjo është ajo që njerëzit e kuptuan. Ajo nuk ka punë. Pra, të kuptuarit e praktikave më të mira e teknologjisë ju jeni duke punuar me është i madh. Shume e rendesishme. 

Pra, ne jemi duke shkuar për të marrë në DynamoDB. DynamoDB është AWS-së plotësisht të menaxhuar platformë NoSQL. Çfarë do të plotësisht të menaxhuar të thotë? Kjo do të thotë që ju nuk keni nevojë për të me të vërtetë të shqetësuar për ndonjë gjë. 

Ju vijnë në, ju thoni SHBA, kam nevojë për një tryezë. Ajo ka nevojë për këtë kapacitet shumë. Ju goditi butonin, dhe sigurimi ne gjithë infrastrukturën e prapa skenës. Tani që është shumë e madhe. 

Sepse kur ju flisni në lidhje me shkallë një bazë të dhënash, Dhënave NoSQL grupimeve në shkallë, petabajtë drejtimin, drejtimin e miliona transaksionet për sekondë, këto gjëra nuk janë grupe të vogla. Ne jemi duke folur me mijëra raste. Menaxhimi mijëra raste, edhe raste virtuale, është një dhimbje e vërtetë në prapanicë. Unë do të thotë, mendoj për çdo kohë një Sistemi operativ patch vjen nga ose një version i ri i bazën e të dhënave. Cfare do te thote ajo për ju operative? Kjo do të thotë ju mori 1.200 serverat që duhet të përditësohen. Tani edhe me automatizimin, që mund të marrë një kohë të gjatë. Kjo mund të shkaktojë shumë dhimbje koke operacionale, sepse unë mund të ketë shërbime poshtë. 

Siç kam rinovuar këto baza të dhënash, unë mund të bëjë vendosjen e trupave Blue Green ku kam vendosur dhe për të përmirësuar gjysmë tim nyjet, dhe pastaj të përmirësuar gjysmën tjetër. Marrë ato poshtë. Pra, menaxhimin e infrastrukturës shkallë është jashtëzakonisht e dhimbshme. Dhe AWS marrë atë dhimbje nga ajo. Dhe bazave të të dhënave NoSQL mund të jetë jashtëzakonisht e dhimbshme për shkak të mënyrë ata shkallë. 

Scale horizontalisht. Nëse ju doni të merrni një NoSQL madhe bazës së të dhënave, ju blini më shumë nyje. Çdo nyje keni blerë është një tjetër dhimbje koke operacional. Pra, le dikush tjetër të bëjë atë për ju. AWS mund ta bëjë këtë. 

Ne mbështesim vlerat dokument kyçe. Tani ne nuk ka shkuar shumë në në tabelë tjetër. Ka shumë të ndryshme shijet e NoSQL. Ata janë të gjitha llojet e gjetjes munged së bashku në këtë pikë. Ju mund të shikoni në DynamoDB dhe të thonë po, ne jemi si një dokument dhe një vlerë kyçe ruajtur këtë pikë. Dhe ju mund të argumentojnë tiparet e njëri mbi tjetrin. Për mua, një shumë kjo është me të vërtetë gjashtë e një gjysmë duzinë të tjera. Secili prej këtyre teknologjive eshte nje teknologji gjobë dhe një zgjidhje gjobë. Unë nuk do të thonë se është më e mirë apo MongoDB më keq se shtrat, pastaj Cassandra, pastaj Dynamo, ose anasjelltas. Unë do të thotë, këto janë vetëm options. 

Është i shpejtë dhe kjo është konsistente në çdo shkallë. Pra, kjo është një nga më të madh shpërblimet që ju të merrni me AWS. Me DynamoDB është aftësia për të marrë një shifër të ulët të vetme latente milisekonda në çdo shkallë. Ky ishte një gol Dizajni i sistemit. Dhe ne kemi klientët që janë duke bërë miliona transaksione për sekondë. 

Tani unë do të shkoj nëpër disa nga ato përdorin raste në disa minuta këtu. Control-- Integruar qasje ne kemi atë që ne e quajmë Identiteti Menaxhimi Access, ose IAM. Ajo përshkon çdo sistem, çdo shërbim që ofron AWS. DynamoDB nuk është përjashtim. Ju mund të kontrollojë aksesin në tabelat DynamoDB. Nëpër të gjitha AWS tuaj llogaritë nga definimin e roleve qasje dhe lejet në infrastrukturën IAM. 

Dhe kjo është një komponent kyç dhe integral në ajo që ne e quajmë ngjarje Programim shtyrë. Tani kjo është një paradigmë e re. 

Audienca: Si është Shkalla juaj e vërtetë pozitive kundrejt negative të rreme në sistemin tuaj të kontrollit të qasjes? RICK Houlihan: pozitive True kundrejt negative të rreme? Audienca: Kthimi çfarë ju duhet të kthehen? Në krahasim me një herë në një kohë të nuk e kthen, kur ajo duhet të provoj? 

RICK Houlihan: Unë nuk mund t'ju them se. Nëse ka ndonjë dështimet çfarëdo qoftë në këtë, Unë nuk jam personi për të kërkuar kjo pyetje të veçantë. Por kjo është një pyetje e mirë. Unë do të jetë kurioz të di se veten time, në të vërtetë. 

Dhe kështu pastaj përsëri, paradigmë e re është ngjarja shtyrë programimit. Kjo është ideja që ju mund të vendosur aplikacionet komplekse që mund të veprojë një shkallë shumë të lartë, shumë pa asnjë infrastrukturë whatsoever. Pa asnjë fikse Infrastruktura whatsoever. Dhe ne do të flasim pak për çka do të thotë si ne të marrë në për nja dy Listat. 

Gjëja e parë që ne do të bëjmë është që ne do të flasim për tavolina. Llojet e të dhënave API për Dynamo. Dhe gjëja e parë që ju do të vini re kur ju shikoni në këtë, në qoftë se ju jeni të njohur me çdo bazë të dhënash, Bazat e të dhënave duhet të vërtetë dy lloj TV Unë do të thërrasë atë. Ose dy grupe të API. Njëri nga ata do të jetë API administrative. 

Gjërat ata të kujdeset për funksionet e bazën e të dhënave. Configuring motor magazinimit, ngritjen dhe duke shtuar tavolina. krijimit të bazës së të dhënave katalogë dhe raste. Këto things-- në DynamoDB, ju kanë, listat shumë të shkurtër të shkurtër. 

Pra, në bazat e të dhënave të tjera, ju mund të shihni dhjetra i urdhëron, e administrative komandat, për të konfiguruar këto opsione shtesë. Në DynamoDB ju nuk keni nevojë ata, sepse ju nuk e konfiguroni sistemin, ne bëjmë. Pra, e vetmja gjë që ju duhet të bëni është të më tregoni se çfarë tavolinë madhësia nuk kam nevojë. Pra, ju merrni një shumë të grup i kufizuar i komandave. 

Ju merrni një Krijo Tabela Update, Tabela, Fshij Tabela, dhe Përshkruani Tabela. Ata janë të vetmet gjëra ju keni nevojë për DynamoDB. Ju nuk keni nevojë për një ruajtje konfigurimit motor. Unë nuk duhet të shqetësohen për përsëritje. Unë nuk duhet të shqetësohen për sharding. 

Unë nuk kam nevojë për t'u shqetësuar në lidhje me ndonjë të këtij stuff. Ne bëjmë të gjitha për ju. Pra, kjo është një sasi të madhe të sipërm që është ngritur vetëm jashtë pjatë tuaj. Pastaj kemi operatorët Crud. Crud është diçka që ne të telefononi në bazën e të dhënave që është Krijo, update, Delete operatorët. Këto janë të zakonshme tuaj operacionet e bazës së të dhënave. Gjëra të tilla si pika të shitur, të marrë pika, përditësim artikuj, fshirë objekte, grumbull query, scan. Nëse ju doni të scan të gjithë tabelën. Tërhiqe gjithçka jashtë tryezë. Një nga gjërat e bukur për DynamoDB është ajo lejon skanim paralele. Kështu që ju mund të vërtetë të më lejoni të dinë se sa temat ju doni të drejtuar në atë scan. Dhe ne mund të kandidojë ato temat. Ne mund të tjerr se të skanoni deri nëpër temat e shumta kështu që ju mund të skanoni të gjithë tabelën hapësirë ​​shumë, shumë shpejt në DynamoDB. 

API tjetër që kemi është ajo që ne e quajmë Streams API ynë. Ne nuk do të flasim shumë shumë për këtë tani. Unë kam marrë disa përmbajtje më vonë në në kuvertë në lidhje me këtë. Por Streams është me të vërtetë një running-- të mendojnë për atë si koha e urdhëroi dhe log ndryshim ndarje. Çdo gjë që po ndodh në tabela tregon deri në lumë. 

Çdo shkruani në tryezë tregon deri në lumë. Ju mund të lexoni këtë lumë, dhe ju mund të bëni gjëra me të. Ne do të flasim për atë që llojet e gjërave që ju të bëjë me gjëra të tilla si përsëritje, krijuar indekseve dytësore. Të gjitha llojet e vërtetë cool gjëra që ju mund të bëni me atë. 

Llojet e të dhënave. Në DynamoDB, ne mbështesim si çelës Vlera e dhe të dhënat dokument lloje. Në anën e majtë të ekranit këtu, ne kemi marrë lloje tona themelore. Llojet kryesore vlerë. Këto janë vargjet, numra, dhe binareve. 

Pra, vetëm tre lloje themelore. Dhe pastaj ju mund të ketë grupe të atyre. Një nga gjërat e bukur rreth NoSQL është ju mund të përmbajë vargjeve si pronat. Dhe me DynamoDB ju mund të përmbajë vargjeve e llojeve themelore, si një pronë rrënjë. 

Dhe pastaj nuk ka llojet dokument. Sa njerëz janë të njohur me JSON? Ju djema njohur me JSON kaq shumë? Kjo është në thelb JavaScript, Objekt, simbol. Kjo ju lejon për të në thelb të përcaktojë një strukturë hierarkike. 

Ju mund të ruajë një dokument JSON në DynamoDB duke përdorur komponente të përbashkëta ose blloqe ndërtimi që janë në dispozicion në gjuhë programuese. Pra, nëse ju keni Java, ju jeni duke kërkuar në hartat dhe listat. Unë mund të krijojë objekte që hartë zonë. Një hartë si vlera kryesore ruhet si pronat. Dhe kjo mund të ketë listat e Vlerat brenda ato prona. Ju mund të ruajë këtë kompleks Struktura hierarkike si një atribut të vetme e një artikull DynamoDB. 

Pra, tavolina në DynamoDB, si shumica Bazat e të dhënave NoSQL, tavolina keni artikuj. Në MongoDB ju do quajmë këto dokumente. Dhe kjo do të jetë bazë shtrat. Gjithashtu një bazë të dhënash dokument. Ju e quani këto dokumente. Dokumente ose sende të ketë atributet. Atributet mund të ekzistojnë ose nuk ekzistojnë në pika. Në DynamoDB, nuk ka një atribut i detyrueshëm. Ashtu si në një bazë të dhënash relacionale, ju keni një kyç primar në tryezë. 

DynamoDB ka atë që ne e quajmë një çelës hash. Kyç Hash duhet të jetë unike. Kështu që, kur unë të përcaktojë një tabelë hash, në thelb ajo që unë jam duke thënë është çdo send do të ketë një çelës hash. Dhe çdo kyç hash duhet të jetë unike. 

Çdo artikull është përcaktuar deri në atë çelës unik hash. Dhe nuk mund të jetë vetëm një. Kjo është në rregull, por shpesh çfarë njerëzit kanë nevojë është se ata duan është kjo hash Çelësi për të bërë një pak më shumë se vetëm të jetë një identifikues unik. Shpesh ne duam të përdorin këtë çelës hash si të lartë kovë nivel grumbullimi. Dhe mënyra e bëjmë këtë është duke duke shtuar se ajo që ne e quajmë një çelës varg. 

Pra, nëse kjo është vetëm një hash tavolinë, kjo duhet të jetë unike. Në qoftë se kjo është një hash dhe varg tryezën, me Kombinimi i hash dhe varg duhet të jetë unike. Pra, mendoj se në këtë mënyrë. Nëse unë kam një forum. Dhe forma e ka tema, ajo ka postimet, dhe ajo ka përgjigje. 

Kështu që unë mund të ketë një hash kryesor, i cili është ID topic. Dhe unë mund të ketë një çelës varg, që është ID përgjigje. Në këtë mënyrë në qoftë se unë dua të merrni të gjitha Përgjigjet për temë të caktuar, Unë vetëm mund të query hash. Unë vetëm mund të them më jepni të gjitha sendet që kanë këtë hash. Dhe unë jam duke shkuar për të marrë çdo pyetje ose postoni për këtë temë të veçantë. Këto aggregations nivelit të lartë janë shumë të rëndësishme. Ata mbështesin qasje primare model i aplikimit. Në përgjithësi, kjo është ajo që ne duam të bëjmë. Ne duam që table-- si ju ngarkesës në tryezë, ne duam për të strukturuar e të dhënave brenda tavolinë në një mënyrë të tillë se aplikimi mund shumë shpejt të marrim këto rezultate. Dhe shpesh mënyra për të bërë këtë është për të ruajtur këto bashkimet si ne futur të dhënat. Në thelb, ne jemi përhapjen e të dhënave në kovë ndritshme si ajo vjen në. 

Çelësat varg të lejojë hash me-- Çelësat duhet të ketë barazi. Kur unë të query një hash, unë duhet të them më jepni një hash që është e barabartë kjo. Kur unë të query një varg, unë mund të them më jepni një gamë të se është duke përdorur çdo lloj Operatori i pasur se ne e mbështesim. Më jep të gjitha sendet për një hash. A është i barabartë, më e madhe se, më pak se, e bën atë të filluar me të, a ekziston në mes të këtyre dy vlerave? Pra, këto lloje të pyetjeve varg se ne jemi gjithmonë të interesuar në. Tani një gjë në lidhje me të dhëna, kur ju shikoni në qasjen e të dhënave, kur ju qasje në të dhënat, është e gjithmonë rreth një grumbullimi. Është gjithmonë lidhje me të dhënat që janë të lidhura me këtë. Më jep gjithçka këtu that's-- gjithë transaksionet në këtë karte krediti për muajin e kaluar. Kjo është një grumbullimi. 

Pothuajse çdo gjë që ju bëni në bazës së të dhënave është një lloj i grumbullimit. Pra, duke qenë në gjendje të jetë në gjendje për të përcaktuar këto kova dhe ju jap këto gamë atributet të jetë në gjendje për të query mbi, këto pyetje pasur mbështetjen e shumë, shumë, shumë modele qasje aplikimit. 

Pra, tjetër gjë çelësi hash nuk është ajo na jep një mekanizëm të jetë në gjendje për të përhapur të dhëna rreth. Bazat e të dhënave NoSQL të punojnë më mirë kur të dhënave është në mënyrë të barabartë të shpërndara në të gjithë grup. Sa njerëz janë të njohur me hashing algoritme? Kur them hash dhe një hashing-- sepse një algoritmi hashing është një mënyrë për të qenë në gjendje të gjenerojnë një vlerë të rastit nga ndonjë vlerë të caktuar. Pra, në këtë rast të veçantë, hash algorithm kemi drejtuar është ND 5 i bazuar. 

Dhe në qoftë se unë kam një ID, dhe kjo është çelësi im hash, unë kam 1, 2, 3. Kur kam drejtuar hash algorithm, ajo do të kthehen dhe do të thonë: edhe 1 barabartë 7B, 2 është e barabartë me 48, 3 e barabartë me CD. Ata janë përhapur në të gjithë hapësirën kryesore. Dhe pse do të bëni këtë? Sepse kjo e bën të sigurt që unë mund të vënë të dhënat në të gjithë nyje të shumta. 

Në qoftë se unë jam duke bërë këtë incrementally, 1, 2, 3. Dhe unë kam një gamë hash që shkon në këtë rast të veçantë, një hapësirë ​​të vogël hash, ajo shkon nga 00 deri FF, atëherë të dhënat do të vijë në dhe ata do të shkojnë 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. Cfare ndodh? Çdo insert është duke shkuar në të njëjtën nyje. Ju shihni se çfarë dua të them? 

Sepse kur kam ndarë hapësirë, dhe unë u përhap në të gjithë këtyre të dhënave, dhe unë ndarje, unë jam duke shkuar për të thënë ndarje 1 ka hapësirë ​​kyç 0 në 54. Ndarja 2 është 55 deri 89. Ndarja 3 është AA për FF. Pra, nëse unë jam duke përdorur linear bën rritjen ID, ju mund të shihni se çfarë po ndodh. 1, 2, 3, 4, 5, 6, të gjithë mënyrë deri ne 54. Pra, si unë jam me çekan të dhënat në sistem, gjithçka përfundon duke shkuar për një nyje. 

Kjo nuk është e mirë. Kjo është një antipattern. Në MongoDB ata kanë këtë problem në qoftë se ju nuk e përdorni një çelës hash. MongoDB ju jep mundësi i hashing vlerën kyç. Ju gjithmonë duhet të bëni që, në qoftë se ju jeni duke përdorur një hash bën rritjen kyç në MongoDB, ose ju do të jetë ngulje çdo shkruani në një nyje, dhe ju do të jetë i kufizuar Shkruaj xhiros tuaj keq. 

Audienca: A është kjo A9 169 në decimal? 

RICK Houlihan: Po, kjo është diku rreth atje. A9, unë nuk e di. Ju do të keni për të marrë binar mia në kalkulator dhjetore. Truri im nuk punon si kjo. Audienca: Vetëm një njeri i shpejtë e Mongo komentet tuaja. Pra, është ID objekt që vjen vetvetiu me Mongo bëjë këtë? RICK Houlihan: A do të bëjë këtë? Nëse ju specifikoni atë. Me MongoDB, ju keni mundësi. Ju mund të specify-- çdo dokument në MongoDB duhet të ketë një ID nënvizë. Kjo është vlera unike. 

Në MongoDB ju mund të specifikoni nëse do të hash atë apo jo. Ata vetëm të ju jap mundësi. Nëse ju e dini se kjo është rastit, nuk ka problem. Ju nuk keni nevojë për të bërë këtë. Nëse ju e dini se kjo nuk është e rastit, që ajo bën rritjen, pastaj të bëjë hash. 

Tani gjë rreth hashing, sapo ju të hash një value-- dhe kjo është pse çelësat hash janë gjithmonë pyetje unike, sepse unë kam ndryshuar vlera, tani unë nuk mund të bëj një pyetje varg. Unë nuk mund të them është kjo në mes këtë apo atë, sepse vlera hash nuk është duke shkuar të jenë të barabartë me vlerën aktuale. Pra, kur ju të hash se kyç, kjo është vetëm barazia. Kjo është arsyeja pse në DynamoDB hash kyçe pyetje janë gjithmonë barazia vetëm. 

Deri tani në një gamë të key-- kur unë shtoj se varg kyç, këto të dhënat kryesore varg të gjithë të vijnë në dhe ata marrin ruajtur në të njëjtën ndarje. Pra, ata janë shumë të shpejt, lehtë marrë sepse kjo është hash, kjo është varg. Dhe ju shihni gjithçka me të njëjtin hash merr ruajtur në të njëjtën hapësirë ​​ndarje. Ju mund të përdorni atë varg kyç për të ndihmuar gjetur të dhënat tuaja të afërt me prindërit e saj. Pra, çfarë jam unë me të vërtetë duke bërë këtu? Kjo është një e për marrëdhënie shumë. Marrëdhënia ndërmjet një çelës hash dhe çelësi varg është një shumë për të. Unë mund të ketë çelësat shumta hash. Unë mund të ketë vetëm gamë të shumta çelësat brenda çdo çelës hash. 

Hash përcakton prind, varg definon fëmijët. Kështu që ju mund të shihni se ka analog këtu midis ndërtimin relacionale dhe njëjtat lloje të ndërton në NoSQL. Njerëzit flasin për NoSQL si nonrelational. Kjo nuk është nonrelational. Të dhënat gjithmonë ka marrëdhënie. Këto marrëdhënie vetëm janë modeluar ndryshe. Le të flasim pak bit për qëndrueshmëri. Kur ju shkruani për të DynamoDB, shkruan janë gjithmonë tre-palësh përsëriten. Që do të thotë se ne kemi tre AZ-së. AZ-së janë Zonat Disponueshmëria. Ju mund të mendoj për një Disponueshmëria Zona si një qendër të dhënave ose një koleksion i qendrave të të dhënave. Këto gjëra janë gjeografikisht izoluar nga njëri-tjetri nëpër zona të ndryshme faj, të gjithë rrjetet e energjisë dhe floodplains ndryshme. Një dështim në një AZ nuk është do të marrë poshtë një tjetër. Ato janë të lidhura edhe së bashku me fibër të errët. Ajo mbështet një nën 1 latente milisekonda mes të AZS. Kështu që të dhënat në kohë reale replications aftë në AZS multi. 

Dhe shumë herë multi dislokimet AZ përmbushur kërkesat e Lartë Disponueshmëria e organizatave më të madhe të ndërmarrjeve. Pra, DynamoDB është e përhapur nëpër tri AZS by default. Ne jemi vetëm duke shkuar për të njohurive shkruaj kur dy prej këtyre tre nyje kthehen dhe thonë: Po, kam marrë atë. Pse eshte ajo? Sepse në anën read ne jemi vetëm do të ju japin të dhënat e mbrapa kur ne të merrni atë nga dy nyjeve. 

Në qoftë se unë jam duke përsëritur të gjithë tre, dhe unë jam duke lexuar nga dy, Unë jam gjithmonë i garantuar të ketë së paku një e atyre që lexon të jetë Kopja më aktuale e të dhënave. Kjo është ajo që e bën DynamoDB qëndrueshme. Tani ju mund të zgjidhni për të kthyer ato në përputhje lexon off. Në të cilin rast unë jam duke shkuar për të thënë, Unë do të lexoni vetëm nga një nyje. Dhe unë nuk mund të garantojë se do të jenë të dhënat më aktuale. 

Pra, nëse një shkruani po vjen në, ajo nuk ka përsëriten ende, ju jeni do të merrni atë kopje. Kjo është një lexuar përfundimisht në përputhje. Dhe çfarë është kjo është gjysma e kostos. Pra, kjo është diçka për të menduar. Kur ju jeni duke lexuar jashtë DynamoDB, dhe ju jeni ngritjen e kapaciteteve të lexuar Njësitë, në qoftë se ju zgjidhni përfundimisht në përputhje lexon, kjo është një shumë më të lirë, është rreth gjysma e kostos. 

Dhe kështu që ajo ju kursen para. Por kjo është zgjedhja juaj. Nëse doni një lexuar qëndrueshme ose një lexuar përfundimisht në përputhje. Kjo është diçka që ju mund të zgjidhni. 

Le të flasim për indekseve. Pra, kemi përmendur se grumbullimi nivelit të lartë. Ne kemi marrë çelësat hash, dhe ne kemi marrë çelësat varg. Kjo është e bukur. Dhe kjo është në tryezë primar, unë mori një kyç hash, kam marrë një kyç varg. 

Cfare do te thote ajo? Unë kam marrë një atribut që unë mund të kandidojë pyetje pasur kundër. Është çelësi varg. Atributet e tjera në atë item-- Unë mund të filtruar në ato atribute. Por unë nuk mund të bëjë gjëra të tilla si, atë fillon me, ose është më i madh se. 

Si ta bëj këtë? Kam krijuar një indeks. Ka dy lloje të Indekset në DynamoDB. Një indeks është me të vërtetë një tjetër pamje e tabelës. Dhe indeksi i mesëm lokale. 

I pari ne do të flasim për. Pra dytësore e lokale janë të bashkëjetuar në të njëjtën ndarje si të dhënave. Dhe si të tilla, ato janë në e njëjta nyje fizike. Ata janë ato që ne e quajmë në përputhje. Kuptimi, ata do të pranojnë shkruaj së bashku me tryezë. Kur shkruani vjen në, ne do të shkruaj me anë të indeksit. Ne do të shkruaj deri në tryezë, dhe pastaj ne do të pranojmë. Pra, kjo është në përputhje. Pasi shkruaj ka qenë pranuar nga tabela, është e garantuar që Indeksi i mesëm lokale do të kenë të njëjtin vizion të të dhënave. Por ajo që ata ju lejojnë të bëni është përcaktojë çelësat varg alternative. 

Duhet të përdorin të njëjtin hash kyç si tryezë primar, për shkak se ata janë të bashkë-të vendosura në njëjta ndarje, dhe ata janë të qëndrueshme. Por unë mund të krijojë një indeks me çelësat e ndryshme varg. Kështu për shembull, në qoftë se kam pasur një prodhues që kishte një pjesë tavolinë papërpunuara vijnë. Dhe pjesë e papërpunuara të vijnë në, dhe ata janë të grumbulluara nga kuvendi. Dhe ndoshta ka një kujtojnë. 

Çdo pjesë që është bërë nga kjo prodhues pas kësaj date, Unë kam nevojë për të tërhequr nga linjë tim. Unë mund të tjerr një indeks që do të jetë në kërkim, përmbledhë në datën e prodhimin e asaj pjese të veçantë. Pra, nëse tryezën time të nivelit të lartë ishte tashmë sheshuar nga prodhuesi, ndoshta ajo ishte e rregulluar në pjesë ID, unë mund të krijojë një indeks off atë tavolinë si sheshuar nga prodhuesi dhe shkonin në datën e prodhimit. Dhe në këtë mënyrë unë mund të them, çdo gjë që ishte prodhuar në mes të këtyre datave, Unë kam nevojë për të tërhequr nga vija. Pra, kjo është një indeks mesme lokale. 

Këto kanë efektin e kufizimin hash hapësirën tuaj kryesor. Për shkak se ata bashkë-ekzistuar në të njëjtën nyjen e magazinimit, ata kufizojnë çelësin hash hapësirë ​​në 10 gigabajt. DynamoDB, nën tavolina, do ndarje tavolina juaj çdo 10 gigabajt. Kur ju vënë 10 koncerte e të dhënave në, ne shkoni [PHH], dhe ne të shtoni një tjetër nyje. 

Ne nuk do të ndahet me LSI nëpër ndarëse të shumta. Ne do të ndahet në tryezë. Por ne nuk do të ndahet LSI. Pra, kjo është diçka e rëndësishme për të kuptuar është në qoftë se ju jeni duke bërë shumë, shumë, grumbullimit shumë të mëdha, atëherë ju jeni do të jetë i kufizuar 10 gigabajt në LSIs tuaj. 

Në qoftë se është rasti, ne mund përdorni secondaries globale. Dytësore e globale janë me të vërtetë një tjetër tryezë. Ato ekzistojnë plotësisht jashtë për anën e tryezën tuaj primar. Dhe ata më lejoni të gjetur një Struktura krejtësisht të ndryshme. Pra, mendoni për atë si të dhënave është duke u futur në dy tavolina të ndryshme, të strukturuara në dy mënyra të ndryshme. 

Unë mund të përcaktojë një krejtësisht të Çelësi i ndryshëm hash. Unë mund të përcaktojë një krejtësisht të Çelësi varg të ndryshme. Dhe unë mund të kandidojë këtë plotësisht të pavarur. Si një çështje të vërtetë, unë kam parashikuar kapacitetin tim lexuar dhe shkruaj e kapaciteteve për tim indekseve global të mesëm plotësisht në mënyrë të pavarur e tryezën time primar. Nëse unë të përcaktojë se indeksi, unë them ajo se sa lexojnë dhe shkruajnë Kapaciteti ajo do të jetë duke përdorur. 

Dhe kjo është e ndarë nga tryezën time primar. Tani të dy indekseve të na lejojë të jo vetëm të përcaktojë hash dhe varg çelësat, por ata na lejojnë të projektojnë vlera shtesë. Pra, nëse unë dua të lexoj nga indeksi, dhe unë dua të të marrë disa grup të dhënash, Unë nuk kam nevojë për të shkuar përsëri në kryesore tryezë të marrë atributet shtesë. Unë mund të projektit ato shtesë atributet në tryezë për të mbështetur modelin qasje. Unë e di se ne jemi ndoshta duke marrë në disa me të vërtetë, really-- hyrë në barërat e këqija këtu në disa të kësaj stuff. Tani unë kam për të domethënie nga kjo. 

Audienca: [padëgjueshme] Çelësi --table do të thoshte ishte një hash? Hash origjinal? Multi-slats? 

RICK Houlihan: Po. Po. Tabela Çelësi thelb vë përsëri në artikull. Pra, një indeks është një tregues prapa në sendet origjinale në tryezë. Tani ju mund të zgjidhni për të ndërtuar një Indeksi që ka vetëm tryezë kyç, dhe ka prona të tjera. Dhe pse mund ta bëj këtë? Epo, ndoshta unë kam objekte shumë të mëdha. 

Unë me të vërtetë vetëm duhet të dini which-- model im qasje mund të thonë, sende të cilat përmbajnë këtë pronë? Mos duhet të kthehen pika. Unë vetëm duhet të dini sende të cilat përmbajnë atë. Kështu që ju mund të ndërtojë indekseve se vetëm kanë tryezë çelësin. 

Por kjo është kryesisht ajo që një indeks në bazën e të dhënave është për. Është për të qenë në gjendje të shpejt të identifikuar të cilat të dhënat, të cilat rreshtave, të cilat artikuj në tryezë kanë pronat që unë jam në kërkim për. 

GSIs, kështu që si mund ata punojnë? GSIs thelb janë asinkron. Përditësimi vjen në tryezë, Tabela është pastaj përditësuar asynchronously të gjithë GSIs tuaj. Kjo është arsyeja pse GSIs janë përfundimisht në përputhje. 

Është e rëndësishme të theksohet se kur ju jeni ndërtimin GSIs, dhe ju e kuptoni se ju jeni duke krijuar një tjetër dimension i aggregation-- tani le të thonë se një shembull të mirë këtu është një prodhues. Unë mendoj se unë mund të ketë biseduar rreth një prodhues mjekësore pajisje. Prodhuesit pajisje mjekësore shpesh kanë pjesë serialized. Pjesët që shkojnë në një zëvendësim hip gjithë të ketë një numër serik të vogël mbi to. Dhe ata mund të kenë miliona dhe miliona dhe miliarda pjesëve në të gjitha pajisjet që ato anije. E pra, ata duhet të mbledhë nën dimensione të ndryshme, të gjitha pjesët në një asamble, të gjithë Pjesët që janë bërë në një linjë të caktuar, të gjithë pjesët që kanë ardhur në nga një prodhues të caktuar në një datë të caktuar. Dhe këto aggregations ndonjëherë merrni deri në miliarda. 

Kështu që unë punoj me disa prej këta njerëz të cilët janë duke vuajtur sepse ata janë krijuar këto aggregations ginormous në indekset e tyre të mesme. Ata mund të kenë një pjesë të papërpunuara tabela që vjen vetëm si hash. Çdo pjesë ka një numër serik unik. I use numrin serik si hash. Eshte e bukur. Tryezën time papërpunuara të dhënave është e përhapur gjitha në të gjithë hapësirën kryesore. [E mia? shkruaj?] [? gëlltitje?] është awesome. Kam marrë një shumë të të dhënave. Atëherë çfarë ata bëjnë është se ata të krijojnë një GSI. Dhe unë them, ju e dini se çfarë, unë duhet të shoh të gjitha pjesët për këtë prodhuesi. E pra, të gjithë një e papritur unë jam Duke marrë një miliard rreshtave, dhe sende tyre mbi një nyje, sepse kur Unë agregate si ID prodhues si hash, dhe numri pjesë si varg, pastaj të gjithë e papritur unë jam vënë një miliard pjesë në çfarë ky prodhues ka më shpëtoi. 

Kjo mund të shkaktojë shumë e presionit mbi GSI, përsëri, sepse unë jam goditje me çekan një nyje. Unë jam vënë të gjitha këto fut në një nyje. Dhe kjo është një rast i vërtetë problematik përdorimi. Tani, unë kam një dizajn të mirë model për mënyrën se si ju shmangur atë. Dhe kjo është një nga problemet që unë gjithmonë punojnë me. Por çfarë ndodh, është GSI mund të nuk kanë kapacitet të mjaftueshëm shkruar të jetë në gjendje për të nxitur të gjithë ata rreshtave në një nyje të vetme. Dhe çfarë ndodh atëherë është primar, tabela klienti, tabela primar do të jetë mbytur sepse GSI nuk mund të mbaj lart. Pra, insert kursi im do të bien në tryezë primar si GSI im përpiqet për të mbajtur lart. 

Të gjithë të drejtë, kështu GSI-së, LSI-së, të cilat duhet të përdor? LSI-së janë në përputhje. GSI-së janë përfundimisht të qëndrueshme. Në qoftë se kjo është në rregull, unë rekomandoj duke përdorur një GSI, ata janë shumë më elastike. LSI-së mund të jetë modeluar si një GSI. Dhe në qoftë se madhësia e të dhënave për çelësat hash në koleksionin tuaj kalon 10 gigabajt, atëherë ju jeni do të dëshironi të përdorni atë GSI sepse kjo është vetëm një kufi i vështirë. 

Të gjithë të drejtë, kështu shkallë. Xhiroja në Dinamo DB, ju dispozitë mund të [padëgjueshme] xhiros në një tryezë. Ne kemi klientët që kanë provizionuar 60 billion-- janë duke bërë 60 miliardë kërkesa, rregullisht drejtimin në mbi një milion kërkesa për sekondë në tryezat tona. Ka të vërtetë nuk Kufiri teorik për sa dhe sa shpejt tabela mund të kandidojë në Dynamo DB. Ka disa të buta kufizime në llogarinë tuaj që ne kemi vënë në atje kështu që ju nuk shkoni çmendur. Në qoftë se ju doni më shumë se se, nuk është një problem. Ju vijnë na tregoni. Ne do të kthehet deri dial. 

Çdo llogari është e kufizuar në një nivel në çdo shërbim, vetëm të fjalës kështu që njerëzit nuk shkojnë çmendur merrni veten në telashe. Nuk ka limit në madhësi. Ju mund të vënë ndonjë numër e artikujve në një tryezë. Madhësia e një elementi është kufizuar në 400 kilobytes secili, që do të jetë jo pika atributet. Pra, shuma e të gjitha atributeve është e kufizuar në 400 kilobytes. Dhe pastaj përsëri, ne kemi se pak çështje LSI me limitin 10 Gigabyte per hash. Audienca: Numri i vogël, unë jam i humbur atë që ju po më thoni mua, që is-- Audienca: Oh, 400 kilobyte është madhësia maksimale për artikull. Pra, një artikull i ka të gjitha atributet. Pra, 400 k është madhësia e përgjithshme e atij sendit, 400 kilobytes. Pra, të gjitha atributet kombinuara, të gjitha të dhënat kjo është në të gjitha ato atributet, mbështjellë deri në një madhësi të plotë, aktualisht sot kufiri artikull është 400 k. Pra shkallë përsëri, ka arritur përmes ndarjes. Xhiroja është parashikuar në nivel tabela. Dhe nuk ka të vërtetë dy pullat. Ne kemi lexuar kapacitet dhe shkruaj kapacitetit. 

Pra, këto janë të rregulluara në mënyrë të pavarur nga njëra-tjetra. Masa RCU-së në mënyrë rigoroze në përputhje lexon. OK, kështu që nëse ju jeni duke thënë se unë dua 1000 RCU-së ata janë rreptësisht të qëndrueshme, ato janë në përputhje lexon. Në qoftë se ju thonë se unë dua eventuale në përputhje lexon, ju mund të dispozitë 1000 RCU-së, ju do të jeni për të marrë 2,000 përfundimisht në përputhje lexon. Dhe gjysma e çmimit për ata përfundimisht konsistojnë në lexon. 

Përsëri, rregulluar në mënyrë të pavarur nga njëra-tjetra. Dhe ata kanë throughput-- Nëse ju konsumoni 100% të RCU tuaj, ju nuk do të ndikojë në Disponueshmëria e të drejtat tuaja. Pra, ata janë krejtësisht të pavarur nga njëri-tjetri. Të gjithë të drejtë, kështu që një nga gjërat që Përmenda shkurtimisht u throttling. Throttling është e keqe. Throttling tregon keq nuk SQL. Ka gjëra që mund të bëjmë për të ndihmuar ju lehtësuar throttling që ju janë duke përjetuar. Por zgjidhja më e mirë për të kjo është le të marrin një vështrim në atë që ju jeni duke bërë, sepse ka një anti-model në lojë këtu. 

Këto gjëra, gjëra të tilla si jo-uniforme Ngarkesat e punës, çelësat e nxehtë, ndarëse nxehtë. Unë jam goditur një hapësirë ​​të veçantë kyç shumë e vështirë për disa arsye të veçantë. Pse jam duke e bërë këtë? Le të kuptoj se nga. Unë jam përzierjen dhënat e mia të nxehta me të dhënat e të ftohtë. Unë jam duke i lënë tavolina e mia të marrë i madh, por nuk ka të vërtetë vetëm disa mesin e të dhënave kjo është me të vërtetë interesante për mua. Pra, për të dhënat log, për shembull, një shumë e konsumatorët, ata marrin log dhënat e çdo ditë. Ata morën një sasi të madhe të të dhënave log. 

Nëse jeni vetëm hedhja gjithë atë log të dhëna në një tavolinë të madhe, me kalimin e kohës kjo tryezë do të merrni masiv. Por unë jam me të vërtetë i interesuar vetëm në 24 orët e fundit, shtatë ditëve të fundit, 30 ditët e fundit. Çfarëdo dritarja e kohës se unë jam i interesuar në kërkim për ngjarjen që pengon mua, ose Ngjarja që është interesante për mua, kjo është e vetmja kohë dritare që kam nevojë. Pra, pse jam unë duke vënë 10 vjet vlerë e të dhënave log në tryezë? Çfarë është që shkakton tabela fragmenti. 

Ajo merr e madhe. Ajo fillon përhapur nga nëpër mijëra nyjave. Dhe që kapacitetin tuaj është aq i ulët, ju jeni në fakt Vlerësoni kufizuar në çdo një nga ato nyje individuale. Pra, le të fillojmë të shikojmë se si nuk kemi rrokulliset atë tryezë gjatë. Si nuk kemi menaxhuar që të dhënat pak më mirë për të shmangur këto probleme. Dhe çfarë bën që të duken si? Kjo është ajo që duket si. Kjo është ajo që NoSQL e keqe duket si. 

Unë kam një çelës të nxehtë këtu. Nëse ju shikoni në anën e këtu, këto janë të gjitha ndarëse e mia. I kam 16 ndarëse këtu mbi këtë bazë të dhënash të veçantë. Ne e bëjmë këtë gjatë gjithë kohës. I drejtuar këtë për konsumatorët gjatë gjithë kohës. Ajo që quhet hartë ngrohjes. Harta ngrohjes tregon mua se si ju jeni hyrë në hapësirën tuaj kryesor. Dhe çfarë kjo është thënë mua është se ka një hash veçantë se ky djalë i pëlqen një shumë e tmerrshme, sepse ai është goditur atë me të vërtetë, të vërtetë e vështirë. 

Pra blu është e bukur. Ne si blu. Ne nuk e pëlqen e kuqe. Red ku presioni merr deri në 100%. 100%, tani ju do të jeni të mbytur. Pra, sa herë që ju shihni ndonjë vijat e kuqe si this-- dhe kjo nuk është vetëm Dynamo DB-- çdo bazës së të dhënave NoSQL e ka këtë problem. Nuk janë anti-modele që mund të përzënë këto lloje të kushteve. Çfarë të bëj është që unë të punojë me klientët për të lehtësuar këto kushte. 

Dhe çfarë bën që të duken si? Dhe kjo po bëhet më e nga Dynamo DB xhiros, por kjo është me të vërtetë duke u maksimumin e NoSQL. Kjo nuk është e kufizuar për Dinamo. Kjo është që unë definitely-- përdoret për të punuar në Mongo. Unë jam njohur me shumë platforma NoSQL. Çdo njëri ka këto lloje e problemeve të nxehtë kryesore. Për të marrë maksimumin e çdo NoSQL bazës së të dhënave, në veçanti Dynamo DB, ju doni të krijoni tabela ku elementi kyç hash ka një numër i madh i vlerave të dallueshme, një shkallë të lartë të cardinality. Sepse kjo do të thotë që unë jam shkrim në shumë kova të ndryshme. 

Sa më shumë kova Jam shkrim, më shumë të ngjarë Unë jam për të përhapur atë peshë shkruani ose lexuar ngarkesës në të gjithë nyje të shumta, më shumë të ngjarë unë jam që të ketë një xhiros të lartë në tryezë. Dhe atëherë unë dua vlerat të jenë ka kërkuar në mënyrë të drejtë në mënyrë të barabartë me kalimin e kohës dhe të njëtrajtshme si rastësisht të jetë e mundur. E pra, kjo është lloj i interesante, sepse unë nuk mund të vërtetë kontrollit kur përdoruesit do të vijnë. Pra, mjaftonte për të thënë, në qoftë se ne të përhapet gjëra në të gjithë hapësirën kyçe, ne ndoshta do të jetë në formë të mirë. 

Ka një farë Shuma e ofrimit me kohë se ju nuk jeni duke shkuar të kontrollit gjendje. Por, ata janë me të vërtetë dy dimensione që ne kemi, hapësirë, qasje në mënyrë të barabartë përhapur, kohë, kërkesa Duke arritur Spaced në mënyrë të barabartë në kohë. Dhe në qoftë se ata të dy Kushtet janë duke u përmbushur, atëherë kjo është ajo që është do të duken si. Kjo është shumë nicer. Ne jemi shumë të lumtur këtu. Ne kemi marrë një model shumë edhe qasje. Po, ndoshta ju jeni duke marrë një pak presion çdo tani dhe pastaj, por asgjë të vërtetë shumë të gjerë. Pra, është e mahnitshme sa herë, kur kam punuar me klientët, që grafiku i parë me të kuqe e madhe bar dhe të gjitha që është e shëmtuar verdhë të gjithë vendin, ne merrni bërë me ushtrimin pas disa muaj e ri-arkitekturës, ata janë duke e njëjtë e saktë Ngarkesa e punës në të njëjtën ngarkesë e saktë. Dhe kjo është ajo që është në kërkim si tani. Pra, ajo që ju merrni me NoSQL është një skemë të dhëna që është absolutisht lidhur me modelin e qasjes. 

Dhe ju mund të zgjedh që të dhënat skemë për të mbështetur këtë model qasje. Nëse ju nuk bëni, atëherë ju do të jeni për të parë ato lloje të problemeve me ato çelësat e nxehtë. 

Audienca: E pra, në mënyrë të pashmangshme disa vende do të jetë hotter se të tjerët. 

RICK Houlihan: Gjithmonë. Gjithmonë. Po, Unë do të thotë ka gjithmonë a-- dhe përsëri, nuk ka disa modelet e projektimit ne do të merrni me anë të që do të flasim rreth asaj se si të merren me këto agregime super të mëdha. Unë do të thotë, kam marrë që të ketë ato, si mund të merremi me to? Unë kam një rast mjaft të mirë përdorimi që ne do të flasim për për atë. 

Të gjithë të drejtë, kështu që le të flasim rreth disa konsumatorë tani. Këta njerëz janë AdRoll. Unë nuk e di nëse ju jeni njohur me AdRoll. Ju ndoshta shihni ato shumë në shfletuesin. Ata janë ad ri-shënjestrimi, ata janë më e madhe ad ri-i synimeve të dhënësit të biznesit atje jashte. Ata zakonisht rregullisht drejtuar mbi 60 miliard transaksione në ditë. Ata po bëjnë më shumë se një milion Transaksionet për sekondë. Ata kanë marrë një tabelë shumë e thjeshtë Struktura, tabela ngarkuar. Kjo është në thelb vetëm një kyç Hash është cookie, varg është demografike kategori, dhe pastaj atributi i tretë është rezultati. 

Pra, ne të gjithë kemi cookies në shfletuesi ynë nga këta njerëz. Dhe kur ju shkoni në një tregtar pjesëmarrëse, ata në thelb të shënuar të gjithë kategoritë e ndryshme demografike. Kur ju shkoni në një faqe interneti dhe ju thonë se unë dua të shoh këtë ad-- apo në thelb ju nuk e thoni that-- por kur ju shkoni në faqen e internetit ata thonë se ju doni të shihni këtë shpallje. Dhe ata të shkojnë merrni atë shpallje nga AdRoll. AdRoll ju duket deri në tryezën e tyre. Ata gjejnë cookie tuaj. Reklamuesit duke u thënë ata, unë dua dikë i cili është i moshës së mesme, Burrë 40-vjeçar, në sport. Dhe ata të ju të shënuar në ato demografike dhe ata të vendosin nëse janë apo jo kjo është një reklamë e mirë për ju. 

Tani ata kanë një SLA me ofruesit e tyre reklamat për të siguruar nën-10 Millisekonda Përgjigja në çdo kërkesë të vetme. Pra, ata janë duke përdorur Dynamo DB për këtë. Ata po na goditur një milionë kërkesa për sekondë. Ata janë në gjendje të bëjë të gjitha e tyre lookups, përzgjedhje të gjithë që të dhënat, dhe për të marrë atë lidhje shtoni mbrapa në atë reklamues në nën 10 milisekonda. Është me të vërtetë mjaft fenomenal Zbatimi se ata kanë. 

Këta actually-- janë këto guys. Unë nuk jam i sigurt nëse kjo është këta njerëz. Mund të jetë këta njerëz. Në thelb tha us-- jo, unë nuk mendoj se ishte e tyre. Mendoj se ishte dikush tjetër. Unë kam qenë duke punuar me një konsumatorëve që më tha se tani që ata kanë shkuar në Dinamo DB, ata janë shpenzojnë më shumë para për snacks për ekipi i tyre të zhvillimit çdo muaj se ata shpenzojnë në database e tyre. Pra, kjo do të ju jap një Ideja e kursimet e kostos që ju mund të merrni në Dinamo DB është i madh. Të gjithë të drejtë, Dropcam është një tjetër kompani. Këto djalë është lloj of-- në qoftë se ju mendoni se e internetit të gjërave, Dropcam është në thelb në internet video të sigurisë. Ju vënë aparatin tuaj atje. Kamera ka një detektor lëvizje. Dikush vjen së bashku, shkakton një pikë sugjerim. Kamera fillon regjistrimi për një kohë deri ajo nuk ka zbuluar ndonjë lëvizje më. Vë se video deri në internet. 

Dropcam ishte një kompani që është e në thelb kaloi në Dinamo DB sepse ata ishin duke përjetuar mëdha dhimbjet në rritje. Dhe çfarë na thanë, papritmas petabajtë e të dhënave. Ata nuk kishte asnjë ide shërbimin e tyre do të jetë aq i suksesshëm. Video Më shumë se përbrenda YouTube është ajo që këta njerëz janë duke marrë. Ata përdorin DynamoDB për të gjetur të gjitha metadata në të gjitha pikat e tyre video-kyçe. 

Pra, ata kanë kova S3 ata të shtyjë Të gjitha Artefaktet binar në. Dhe pastaj ata kanë Të dhënat dinamo DB se pikë njerëzit me ato S3 tre objekte. Kur ata duhet të shikoni në një video, ata shikojnë deri rekord në Dynamo DB. Ata klikoni lidhjen. Ata shemb video nga S3. Pra, kjo është lloj i asaj që kjo duket si. Dhe kjo është e drejtë nga ekipi i tyre. 

Dynamo DB redukton tyre kohën e dorëzimit për ngjarjet video të nga pesë deri në 10 sekonda. Në dyqan e tyre të vjetër relacionale, ata kanë përdorur për të shkuar dhe të ekzekutojë pyetje të shumta komplekse të kuptoj se cilat video për të tërhequr poshtë, në më pak se 50 milisekonda. Pra, kjo është e mahnitshme, e mahnitshme sa performanca ju mund të merrni kur ju zgjedh dhe sintonizoheni baza e të dhënave themelor për të mbështetur modelin qasje. Halfbrick, këta njerëz, çfarë është ajo, Fruit Ninja I guess është gjë e tyre. Se të gjitha shkon në Dynamo DB. Dhe këta njerëz, ata janë një e madhe Ekipi i zhvillimit, zhvillimi i madh dyqan. 

Nuk është një ekip i mirë OPS. Ata nuk kanë shumë e burimeve operative. Ata ishin duke luftuar duke u përpjekur për të mbajtur infrastruktura e tyre e aplikimit deri dhe drejtimin. Ata erdhën tek ne. Ata dukeshin në atë Dynamo DB. Ata thanë, kjo është për ne. Ata ndërtuan gjithë e tyre Korniza aplikimi mbi të. Disa komente me të vërtetë e bukur këtu nga ekipi në aftësinë e tyre tani fokusohet në ndërtimin e loja dhe jo duke pasur për të ruajtur infrastrukturës, e cila ishte duke u bërë një sasi e madhe i sipërm për ekipin e tyre. Pra, kjo është diçka that-- dobi që ju të merrni nga Dynamo DB. 

Të gjithë të drejtë, duke marrë në modelimit të dhëna këtu. Dhe kemi biseduar pak për ky një me një, një për të shumë, dhe shumë shumë marrëdhëniet tipit. Dhe si mund të mbajë ato në Dinamo. Në Dinamo DB ne përdorim indekseve, në përgjithësi, të rrotullohen të dhënat nga një aromë në tjetrën. Çelësat hash, çelësat varg, dhe indekseve. 

Në këtë të veçantë shembull, si shumicën e shteteve të ketë një kërkesë të licencimit që vetëm patentë e një shoferi për person. Ju nuk mund të shkojnë për të marrë dy shoferit licencat në shtetin e Bostonit. Unë nuk mund ta bëjë këtë në Teksas. Kjo është lloj i mënyrës se si është. Dhe kështu në DMV, kemi Lookups, ne doni të shikoni patentë shoferin nga numri i sigurimit social. Unë dua të shikoni detajet e përdoruesit nga numri i licencës e shoferit. 

Pra, ne mund të kemi tabelën e përdoruesit që ka një kyç hash në numrin serial, ose numrin e sigurimit social, dhe atributet e ndryshme të përcaktuara në pika. Tani në atë tryezë I mund të përcaktojë një GSI që flips se rreth që thotë se unë dua një kyç hash në licencë dhe pastaj të gjitha sendet e tjera. Tani në qoftë se unë dua të pyetjes dhe për të gjetur numrin e licencës për çdo Sociale dhënë Numrin e sigurimit, unë mund të query tryezë kryesore. 

Nëse unë dua të query dhe unë dua për të marrë sigurimet shoqërore Numri i apo atributet e tjera nga një numrin e licencës, unë mund të query GSI. Se modeli është se një në një marrëdhënie. Vetëm një GSI shumë të thjeshtë, rrokullisje ato gjëra përreth. Tani, të flasim për një të shumë. Një për shumë është në thelb juaj kyç varg hash. Ku kemi marrë një shumë me këtë Përdorimi rast të dhëna të monitoruar. Monitor dhëna vjen në të rregullt interval, si Internet të gjërave. Ne gjithmonë merrni të gjitha këto Të dhënat që vijnë në gjithë kohës. 

Dhe unë dua të gjeni të gjitha leximet në mes të një periudhe të caktuar kohore. Kjo është një pyetje shumë e zakonshme në Infrastruktura e monitorimit. Mënyra lëvizje në lidhje me atë është për të gjetur një strukturë e thjeshtë tryezë, një tryezë. Unë kam marrë një tavolinë matjeve pajisje me një kyç hash në ID pajisjes. Dhe unë kam një çelës varg në timestamp, apo në këtë rast, epike. Dhe që lejon mua të ekzekutuar kompleks pyetje kundër kësaj varg kyç dhe kthehen ato shënime që janë relative të rezultatit vendosur që unë jam duke kërkuar për. Dhe ajo ndërton se një në marrëdhënie shumë në tryezë primar duke përdorur kyç hash, struktura kryesore varg. 

Kështu që është ndërtuar lloj i në tryezë në Dinamo DB. Kur unë të përcaktuar një hash dhe tabela varg t, unë jam përcaktimin e një një për marrëdhënie shumë. Kjo është një marrëdhënie prind-fëmijë. 

Le të flasim për shumë për shumë marrëdhënie. Dhe për këtë shembull të veçantë, përsëri, ne jemi duke shkuar për të përdorur GSI-së. Dhe le të flasim rreth lojrave skenar ku unë kam një përdorues të caktuar. Unë dua të gjeni të gjitha lojrat që ai është i regjistruar për ose duke luajtur në. Dhe për një lojë të caktuar, unë doni të gjeni të gjithë përdoruesit. Pra, si mund ta bëni këtë? My tavolinë Games User, unë jam duke shkuar të ketë një çelës hash prej përdoruesit ID dhe një varg kyç të lojës. 

Kështu që një përdorues mund të ketë lojëra të shumta. Kjo është një njeri për marrëdhënie ndërmjet shumë përdoruesi dhe lojërat që ai luan. Dhe pastaj në GSI, Unë do të rrokullisje se rreth. Unë do të hash në lojë dhe Unë do të shkojnë në të përdoruesit. Pra, nëse unë dua të të marrë të gjitha lojë përdoruesi është duke luajtur në, Unë do të query tryezë kryesore. Nëse unë dua të të marrë të gjithë përdoruesit se janë duke luajtur një lojë të veçantë, Unë query GSI. Kështu që ju shihni se si ta bëjmë këtë? Ju ndërtuar këto GSI-së për të mbështetur rast përdorimi, aplikimi, qasja model, aplikimi. 

Nëse unë duhet të query në ky dimension, le të Më të krijuar një indeks në atë dimension. Nëse unë nuk bëj, unë nuk e kujdesit. Dhe sipas rastit të përdorimit, unë mund të kenë nevojë indeksi ose unë nuk mund të. Në qoftë se kjo është një e thjeshtë për shumë njerëz, tabela kryesor është e mirë. Nëse unë duhet të bëni këto shumë të shumë së, ose unë duhet të bëjë një për ato, atëherë ndoshta unë kam nevojë të dytë indeksi. Pra, të gjitha varet nga ajo që unë jam duke u përpjekur për të bërë dhe atë që unë jam duke u përpjekur për të marrë kryer. 

Ndoshta unë nuk jam duke shkuar për të shpenzuar shumë shumë kohë duke folur për dokumente. Kjo merr pak, ndoshta, thellë se ne kemi nevojë për të shkuar në. Le të flasim pak shprehje për të pasur query. Pra, në Dinamo DB ne kemi aftësia për të krijuar ajo që ne e quajmë shprehje projektimit. Shprehjet Projektim janë thjesht picking fushat ose vlerat që ju doni të shfaqur. OK, kështu që unë të bëjë një përzgjedhje. Unë bëj një pyetje kundër Dynamo DB. Dhe unë them, ju e dini se çfarë, shfaqje Me vetëm pesë komente të yll për këtë produkt të veçantë. Pra, kjo është e gjitha unë dua të shoh. Unë nuk dua të shoh të gjitha atributet e tjera të radhës, Unë vetëm dua të shoh këtë. Është vetëm si në SQL, kur ju thonë zgjidhni yll ose nga tabela, ju merrni gjithçka. Kur them zgjidhni emrin nga tavolinë, unë vetëm të marrë një atribut. Është e njëjta lloj gjë në Dynamo DB ose një tjetër bazat e të dhënave NoSQL. Filtro shprehjet më lejoni të në thelb të shkurtojë rezultatin vendosur poshtë. Kështu që unë bëj një pyetje. Query mund të vijë përsëri me 500 artikuj. Por, unë dua vetëm artikujt që kanë një atribut që thotë kjo. OK, kështu që le të filtruar nga ato artikuj që nuk përputhen me këtë pyetje të veçantë. Pra, ne kemi shprehje filtër. 

Filter shprehje mund të kandidojë në çdo atribut. Ata nuk janë si pyetje varg. Ngrenë pyetje janë më selektive. Filtro pyetje kërkon mua për të shkuar merrni rezultatet gjithë të vendosur dhe më pas ndërtoj të dhënat Unë nuk dua. Pse është kjo e rëndësishme? Sepse kam lexuar të gjitha. Në një pyetje, unë jam duke shkuar për të lexuar dhe ajo do të jetë një gjigant për të dhënat. Dhe atëherë unë jam duke shkuar për ndërtoj atë që kam nevojë. Dhe në qoftë se unë jam vetëm gdhendje një çift ​​i rreshtave, atëherë kjo është në rregull. Kjo nuk është aq i paefektshëm. 

Por në qoftë se unë jam duke lexuar një grumbull të tërë të të dhëna, vetëm të ndërtoj një artikull, atëherë unë jam do të jetë më mirë duke përdorur një pyetje varg, sepse kjo është shumë më selektive. Ajo do të shpëtojë më shumë para, sepse unë të paguajnë për atë lexuar. Ku rezultatet që vjen prapa kalojnë atë tela mund të jenë më të vogla, por unë jam duke paguar për të lexuar. Pra, të kuptojnë se si ju jeni marrë të dhënat. Kjo është shumë e rëndësishme në Dynamo DB. 

Shprehjet e kushtëzuara, kjo është ajo që ju mund të telefononi mbyllje optimiste. Update nëse ekziston, ose në qoftë se kjo vlerë është e barabartë me atë që unë të specifikojë. Dhe në qoftë se unë kam një vulë kohë në një rekord, unë mund të lexoni të dhënat. Unë mund të ndryshojë këto të dhëna. Unë mund të shkoj shkruaj se të dhënat përsëri në bazën e të dhënave. Në qoftë se dikush ka ndryshuar rekord, timestamp mund të ketë ndryshuar. Dhe në këtë mënyrë i kushtëzuar im Përditësimi mund të them përditësim nëse timestamp barabartë kjo. Ose update do të dështojë për shkak dikë updated rekordin në ndërkohë. 

Kjo është ajo që ne e quajmë mbyllje optimiste. Kjo do të thotë se dikush mund të vijnë në dhe për të ndryshuar atë, dhe unë jam duke shkuar për të zbuluar atë kur të shkoj përsëri për të shkruar. Dhe pastaj unë në fakt mund të lexoni se të dhënave dhe të thonë, oh, ai e ndryshoi këtë. Unë kam nevojë për të llogari për atë. Dhe unë mund të ndryshojë të dhënat në tim rekord dhe aplikoni një përditësim. Kështu që ju mund të kapur ata në rritje përditësime që ndodhin në mes të kohës që ju lexoni të dhënat dhe herë ju mund të shkruani të dhënat. 

Audienca: Dhe filtër shprehje në fakt nuk do të thotë në numrin ose not-- 

[Ndërhynte ZËRA] RICK Houlihan: Unë nuk do të marrë shumë në këtë. Kjo është një fjalen e rezervuar. Pamje Pound është një rezervuar fjalen në Dynamo DB. Çdo bazës së të dhënave ka vet e rezervuara emra për koleksionet ju nuk mund të përdorni. Dinamo DB, nëse ju specifikoni një kile në frontin e kësaj, ju mund të përcaktojë ato emra lart. Kjo është një vlerë të cekura. Kjo ndoshta nuk është sintaksa e mirë për të kanë atje për këtë diskutim, për shkak se ajo merr në disa real-- Unë do të kishte qenë duke folur më shumë në lidhje me atë në një nivel më të thellë. 

Por mjafton të them, kjo mund të jetë query scan ku ata views-- as paund views është më i madh se 10. Kjo është një vlerë numerike, po. Nëse dëshironi, mund të flasim për se pas diskutimit. Të gjithë të drejtë, kështu që ne jemi duke marrë në disa skenarë në praktikat më të mira ku ne jemi duke shkuar për të folur për disa aplikacione këtu. Cilat janë rastet e përdorimit për Dynamo DB. Cilat janë të projektimit modelet në Dynamo DB. 

Dhe i pari që ne jemi duke shkuar për flasim për është e internetit të gjërave. Pra, ne të merrni një shumë of-- unë mendoj, ajo që është it-- më shumë se 50% e trafikut në internet këto ditë është e gjeneruar të vërtetë nga makinat, proceset e automatizuar, jo nga njerëzit. Unë do të thotë këtë gjë kjo që keni kryer rreth në xhepin tuaj, se si të dhënat shumë sa që kjo gjë është në fakt duke dërguar rreth pa ty duke e ditur se është absolutisht e mrekullueshme. Vendndodhjen tuaj, informacioni rreth asaj se si shpejt ju jeni duke shkuar. Si mendoni Google Maps vepra kur ata të ju tregojnë se çfarë trafiku është. Kjo është për shkak se ka me miliona dhe miliona njerëz të makinës rreth me telefona që janë dërguar të dhëna në të gjithë vendin gjatë gjithë kohës. Pra, një nga gjërat në lidhje me këtë lloj të të dhënave që vjen në, të dhënat Monitor, log të dhënave, të dhënat e kohë seri, është ajo e zakonisht vetëm interesante për pak kohë. Pas asaj kohe, është e jo aq interesante. Pra, kemi biseduar rreth, nuk e le këto tavolina të rriten pa të mëdhenj. Ideja këtu është se ndoshta unë kam marrë 24 orë vlerë e ngjarjeve në tryezën time të nxehtë. Dhe kjo tryezë e nxehtë do të jetë parashikuar në një shkallë shumë të lartë, për shkak se ajo është duke marrë një shumë të të dhënave. Ajo është duke marrë një shumë të të dhënave në dhe unë jam duke lexuar atë shumë. Unë kam marrë një shumë të operimit pyetje running kundër atij të dhëna. 

Pas 24 orësh, hej, ju e di se çfarë, unë nuk e kujdesit. Kështu që ndoshta çdo mesnatë unë roll tryezën time mbi një tavolinë të re dhe unë deprovision këtë tabelë. Dhe unë do të marrë RCU-së dhe Poshtë NJKL sepse 24 orë më vonë Unë nuk jam kandidon si shumë pyetje kundër kësaj të dhënave. Kështu që unë jam duke shkuar për të kursyer para. Dhe ndoshta 30 ditë më vonë, unë nuk e bëj edhe duhet të kujdesen për të gjitha. Unë mund të marrë NJKL-së të gjithë rrugën poshtë për një, sepse ju e dini se çfarë, është kurrë nuk do të merrni me shkrim. Të dhënat është 30 ditë të vjetra. Ajo nuk ndryshon kurrë. 

Dhe kjo është pothuajse kurrë nuk do të merrni të lexuar, kështu që le të marrë vetëm atë RCU deri në 10. Dhe unë jam duke kursyer një ton të parave për këtë të dhënave, dhe vetëm duke paguar për të dhënat e mia të nxehtë. Pra, kjo është gjë e rëndësishme për të parë në kur ju shikoni në një seri kohore të dhënat që vijnë në në vëllim. Këto janë strategji. Tani, unë mund vetëm le atë të gjithë shkojnë në të njëjtën tryezë dhe vetëm le atë tryezë të rriten. Përfundimisht, unë jam duke shkuar për shih çështjet e performancës. Unë do të duhet të fillojë për të arkivit disa prej se të dhënat off tryezë, çfarë jo. 

Le të shumë më mirë hartuar aplikimin tuaj kështu që ju mund të veprojë në këtë mënyrë të drejtë. Pra, kjo është vetëm automatike në kodin e aplikimit. Në mesnatë çdo natë ajo e rrotullon tryezë. Ndoshta atë që kam nevojë është një rrëshqitje Dritarja e 24 orëve të dhënave. Pastaj mbi një bazë të rregullt unë jam duke e quajtur të dhënat off tryezë. Unë jam zvogëlimin atë me një Punë cron dhe unë jam vënë atë në këto tabela të tjera, çdo gjë që ju nevojitet. Pra, nëse një rollover punon, kjo është e madhe. Nëse jo, të shkurtojë atë. Por le të mbajtur ato të dhëna të nxehtë larg nga të dhënat tuaja të ftohtë. Kjo do të ju kursejnë një shumë të holla dhe bëjnë tavolinat tuaja më shumë probleme. Pra, gjëja tjetër ne do të flasim lidhje është katalog produkt. Katalogu i produkteve është Rasti shumë e zakonshme përdorimi. Kjo është në fakt një model shumë i zakonshëm se ne do të shohim në një shumëllojshmëri të gjëra. Ju e dini, Twitter për shembull, një cicërimë të nxehtë. Çdo njeri vjen dhe grabbing atë cicërimë. Katalogu i produkteve, kam marrë një shitje. Kam marrë një shitje të nxehtë. I kam 70,000 kërkesa për ardhjen e dytë për një produkt përshkrim nga katalogu ime produktit. Ne e shohim këtë në pakicë operacion mjaft pak. Pra, si mund të merremi me atë? Nuk ka asnjë mënyrë për t'u marrë me atë. Të gjithë përdoruesit e mia duan të shohin e njëjta pjesë e të dhënave. Ata po vijnë në, njëkohësisht. Dhe ata janë të gjithë duke bërë kërkesa për të njëjtën pjesë të të dhënave. Kjo i jep mua se çelësi i nxehtë, ajo e kuqe e madhe shirit në kartelën time se ne nuk na pëlqen. Dhe kjo është ajo që duket si. Pra, të gjithë hapësirën time kyçe unë jam marrë hartuar në pikat e shitjes. Unë jam marrë asgjë kudo tjetër. 

Si mund ta lehtësuar këtë problem? E pra, ne të lehtësuar këtë me cache. Cache, ju vënë në thelb një në kujtesën ndarje në frontin bazën e të dhënave. Ne kemi arritur [Padëgjueshme] cache, si ju mund të ngritur vetë cache tuaj, [e padëgjueshme] cache [? d,?] çdo gjë që ju dëshironi. Vënë atë në frontin e bazën e të dhënave. Dhe në këtë mënyrë ju mund të ruajë ato të dhëna nga ato çelësat e nxehtë deri në atë cache hapësirë ​​dhe lexuar nëpër cache. 

Dhe pastaj shumica e lexon tuaj fillojmë të shikojmë si kjo. I kam të gjitha këto cache godet këtu dhe kam marrë asgjë ndodh këtu poshtë sepse baza e të dhënave është e ulur prapa cache dhe nuk lexon vijnë përmes. Nëse unë të ndryshojë të dhënat në bazës së të dhënave, unë kam për të rinovuar cache. Ne mund të përdorim diçka si avuj për të bërë këtë. Dhe unë do të shpjegojë se si punon kjo. Të gjithë të drejtë, mesazheve. Email, ne të gjithë e përdorin e-mail. 

Ky është një shembull mjaft të mirë. Ne kemi marrë disa lloj të mesazheve tabelës. Dhe kemi marrë postë dhe Dalje. Kjo është ajo që do SQL duken si për të ndërtuar atë në postë. Ne lloj i përdorin të njëjtin lloj i strategjisë për të përdorur GSI-së, GSI-së për kutinë time dhe Dalje tim. Kështu që unë kam mesazhe të para që vijnë në mesazhe tryezën time. Dhe qasja e parë për këtë mund të jetë, të themi, OK, nuk ka problem. Unë kam marrë mesazhe të papërpunuara. Mesazhet që vijnë [e padëgjueshme], Mesazhi ID, kjo është e madhe. Kjo është hash ime unik. Unë jam duke shkuar për të krijuar dy GSI-së, një për kutinë time, një për Dalje tim. Dhe gjëja e parë që unë do të bëj po unë do të them kyç im hash është do të jetë marrësi dhe Unë jam duke shkuar për të rregulluar në datën. Kjo është fantastike. Unë kam mendimin tim të bukur këtu. Por ka një problem të vogël këtu. Dhe ju drejtuar në këtë në databaza relacionale si. Ata i bënë thirrje ndarjen vertikalisht. Ju dëshironi të mbani të dhënat tuaja të madhe larg nga të dhënat tuaja të vogla. 

Dhe arsyeja pse është për shkak se unë Gotta shkoni lexoni artikujt për të marrë atributet. Dhe në qoftë se organet e mi janë të gjithë këtu, pastaj duke lexuar vetëm disa artikuj nëse gjatësia trupi im është mesatarisht 256 kilobytes secila, matematikë merr goxha e shëmtuar. Pra, thonë se unë dua të lexoj postë Davidit. Inbox Davidit ka 50 objekte. Mesatarja e madhësisë është 256 kilobytes. Këtu është raporti im konvertimit për RCU-së është katër kilobytes. 

OK, le të shkojë me përfundimisht në përputhje lexon. Unë jam ende duke ngrënë 1600 RCU-së vetëm për të lexuar postë Davidit. Ouch. OK, tani le të mendojmë për mënyrën se si funksionon aplikacioni. Në qoftë se unë jam në një app email dhe Unë jam duke kërkuar në kutinë time, dhe unë shoh në trupin e çdo mesazhi, jo, unë jam duke kërkuar në përmbledhjet. Unë jam duke kërkuar në vetëm headers. Pra, le të ndërtojmë një strukturë tryezë që duket më shumë si kjo. 

Kështu që këtu është informacioni që ka nevojë për workflow im. Është në kutinë time GSI. Kjo është data, dërguesi, subjekt, dhe pastaj ID mesazhi, i cili tregon përsëri në mesazhet tryezë ku unë mund të merrni trupin. E pra, këto do të jenë ID rekord. Ata do të pikë prapa në ID pika në tryezë Dynamo DB. Çdo indeksi gjithmonë creates-- gjithmonë ka pika ID si pjesë of-- se vjen me indeksin. 

Në rregull. Audienca: Ajo tregon se ku është e ruajtur? RICK Houlihan: Po, ai tregon exactly-- kjo është pikërisht ajo që e bën. Ajo thotë se këtu është rekord RE. Dhe kjo do të pikë atë përsëri në rekordin tim të ri. Pikërisht. OK, kështu që tani inbox im është në fakt shumë më të vogla. Dhe kjo në fakt mbështet workflow i një app email. Pra kutinë time, unë klikoni. I shkojnë së bashku dhe unë klikoni mbi mesazhin, kjo është kur kam nevojë për të shkuar të marrë trupin, sepse unë jam duke shkuar për shkoni në një pikëpamje të ndryshme. Pra, nëse ju mendoni për llojin e MVC kornizë, Model Shiko kontrollues. 

Modeli përmban të dhënat që nevojat view dhe kontrolluesi ndërvepron me. Kur unë të ndryshojë kornizë, kur Unë të ndryshojë perspektivën, është në rregull për të shkuar përsëri në server dhe ripopulluar modelin, sepse kjo është ajo që pret përdoruesi. Kur ata të ndryshojnë pikëpamje, kjo është kur ne mund të shkoni përsëri në bazën e të dhënave. Pra email, klikoni. Unë jam duke kërkuar për trupin. Udhëtim. Shkoni merrni trupin. 

Kam lexuar shumë më pak të dhëna. Unë jam vetëm duke lexuar organet që David ka nevojë, kur ai ka nevojë për ta. Dhe unë nuk jam djeg në 1600 RCU të vetëm për të treguar postë tij. Deri tani that-- kjo është mënyra se LSI apo GSI-- unë jam i keq, GSI, do të punojnë jashtë. Ne kemi marrë hashin tonë në marrësit. Ne kemi marrë çelësin varg në datën. Dhe ne kemi marrë atributet projektuara se ne kemi nevojë vetëm për të mbështetur pikëpamjen. 

Ne rrotullohen se për Dalje. Hash në dërguesit. Dhe në thelb, ne kemi , pamje shumë e bukur të pastër. Dhe kjo është që ne basically-- kemi këtë porosi bukur tabela që është duke u përhapur bukur sepse kjo është vetëm hash, sheshuar mesazh ID. Dhe ne kemi dy indekseve që janë të rradhës off e atë tryezë. Të gjithë të drejtë, kështu që ideja këtu është të mos ruajnë të dhënat mëdha dhe këto të dhëna të vogël së bashku. Ndarje vertikalisht, ndarjen ato tavolina. A nuk e lexoni të dhënat që ju nuk keni për të. Të gjithë të drejtë, lojrave. Ne të gjithë si lojra. Së paku unë pëlqen lojra atëherë. Pra, disa nga gjërat që të merremi me të, kur ne jemi duke menduar për të lojrave, e drejtë? Lojrave këtyre ditëve, veçanërisht celular lojrave, është mbi të gjitha të menduarit. Dhe unë jam duke shkuar për të rrotullohen këtu një pak larg nga DynamoDB. Unë jam duke shkuar për të sjellë në disa diskutime rreth disa nga teknologjive të tjera AWS. 

Por ideja rreth lojrave është që të mendoj për në drejtim të TV, TV që janë, në përgjithësi, HTTP dhe JSON. Është mënyra se si lojrave celular lloj i ndërveprojnë me skajet e tyre prapa. Ata e bëjnë JSON postimi. Ata të marrë të dhëna, dhe kjo është e gjitha, në përgjithësi, në TV bukur JSON. 

Gjëra të tilla si të merrni miqtë, të merrni të dhënat Fituesit, këmbimit, user generated përmbajtje, zbyth deri në sistem, këto janë llojet e gjërave se ne jemi duke shkuar për të bërë. Dhënat binare pasuri, këto të dhëna nuk mund të ulen në bazën e të dhënave. Kjo mund të ulen në një dyqan objekt, e drejtë? Por baza e të dhënave do të përfundojnë duke u thënë të sistemit, thënë aplikacionin ku të shkoni të merrni atë. Dhe në mënyrë të pashmangshme, multiplayer serverat, infrastruktura fund mbrapa, dhe i projektuar për të lartë Disponueshmëria dhe scalability. Pra, këto janë gjëra që ne të gjithë duam në infrastrukturën e lojrave sot. 

Pra, le të marrin një vështrim në ajo që duket si. Got një fund core mbrapa, shumë të thjeshtë. Kemi një sistem me këtu Zonat e shumta disponueshmërisë. Kemi biseduar për AZS si being-- mendoj prej tyre si qendra të veçanta të të dhënave. Qendra e më shumë se një e të dhënave për AZ, por kjo është në rregull, thjesht mendoj se prej tyre si të dhëna të veçanta Qendrat që janë gjeografikisht dhe faji izoluar. 

Ne do të kemi një raste çift EC2. Ne do të kemi disa server fund mbrapa. Ndoshta, nëse ju jeni një trashëgimi Arkitektura, ne jemi duke përdorur atë që ne e quajmë RDS, Shërbimet e bazës së të dhënave relacionale. Mund të jetë MSSQL, MySQL, ose diçka të tillë. Kjo është mënyra aplikacione shumë janë projektuar sot. 

Edhe ne mund të dëshironi të shkoni me kjo është kur ne shkallë jashtë. Ne do të shkojnë përpara dhe të vënë kovë S3 deri atje. Dhe kjo kovë S3, në vend të shërbyer deri ato objekte nga servers-- tonë ne mund të bëjmë atë. Ju vënë të gjitha binare tuaj objektet në serverat tuaj dhe ju mund të përdorni ato server raste për të shërbyer që të dhënat up. Por kjo është goxha i shtrenjtë. 

Mënyra më e mirë për të bëni është të shkoni përpara dhe vënë ato objekte në një kovë S3. S3 është një objekt magazinat. Është e ndërtuar posaçërisht për duke shërbyer deri këto lloje të gjërave. Dhe le ata klientë të kërkojë direkt nga ato kova objekt, shkarkoj servers. Pra, ne jemi duke filluar të shkallës këtu. 

Tani kemi marrë përdoruesit në të gjithë botën. I kam përdoruesit. Unë duhet të ketë përmbajtje në nivel lokal vendosur në afërsi të këtyre përdoruesve, e drejtë? Unë kam krijuar një kovë S3 si depo e mia burim. Dhe unë do para se me shpërndarja CloudFront. 

CloudFront është një CD dhe a Rrjeti ofrimit përmbajtje. Në thelb ajo merr të dhënat që ju të specifikojë dhe arka të gjitha në lidhje me internet kështu që përdoruesit mund të ketë kudo një përgjigje shumë të shpejtë, kur ata kërkojnë ato objekte. 

Pra, ju merrni një ide. Ju jeni lloj i leveraging gjitha aspekte të AWS këtu për të marrë këtë bërë. Dhe në fund, hedhim në një grup shkallë auto. Pra instancat tona AC2 nga serverat tanë lojës, si ata të fillojnë për të marrë zënë dhe zënë dhe të zhurmshme, ata do të tjerr vetëm një tjetër shembull, tjerr një rast tjetër, tjerr një tjetër shembull. Pra, teknologji AWS ka, ai ju lejon të specifikoni parametrat rreth të cilit serverat tuaj do të rritet. Kështu që ju mund të keni numrin n të serverëve atje në çdo kohë të dhënë. Dhe në qoftë se ngarkesa juaj shkon larg, ata do të tkurret, numri do të tkurret. Dhe në qoftë se ngarkesa vjen mbrapa, ajo do të rritet përsëri jashtë, elastike. 

Pra, kjo duket e madhe. Ne kemi marrë një shumë raste EC2. Ne mund të vënë në cache front i bazave të të dhënave, provoni dhe përshpejtimin bazat e të dhënave. Pika tjetër presion zakonisht njerëzit të shohin është se ata shkallë një lojë duke përdorur një sistem i bazës së të dhënave relacionale. Jeez, baza e të dhënave Performanca është e tmerrshme. Si nuk kemi të përmirësuar atë? Le të provoni duke cache para se. 

E pra, cache nuk funksionon aq e madhe në lojëra, e drejtë? Për lojëra, të shkruarit është e dhimbshme. Lojërat janë shumë të shkruajnë e rëndë. Cache nuk punon kur ju jeni shkruaj rëndë për shkak se ju keni gjithmonë mori për të rinovuar cache. Ju update cache, kjo është parëndësishme të caching. Kjo është në fakt vetëm punë shtesë. 

Pra, ku të shkojmë këtu? Ju keni marrë një ngushtim i madh atje poshtë në bazën e të dhënave. Dhe vendi për të shkuar padyshim është ndarjes. Ndarje nuk është e lehtë për të bërë, kur ju jeni që kanë të bëjnë me bazat e të dhënave relacionale. Me bazat e të dhënave relacionale, ju jeni përgjegjës për menaxhimin, në mënyrë efektive, hapësirë ​​kyç. Ju jeni duke thënë përdoruesit ndërmjet A dhe M shkoni këtu, në mes N dhe Z shkojnë atje. Dhe ju jeni kalimi të gjithë aplikimit. Kështu që ju jeni që kanë të bëjnë me ky burimi i të dhënave ndarje. Ju keni kufizime transaksioneve që nuk shtrihen ndarëse. Ju keni marrë të gjitha llojet e Çrregullimi që ju jeni që kanë të bëjnë me atje poshtë duke u përpjekur për t'u marrë me shkallë jashtë dhe ndërtimin e një infrastrukture më të madhe. Është vetëm më zbavitëse. 

Audienca: Pra, jeni duke thënë se rritja pikë burim përshpejton procesi? RICK Houlihan: Rritja? Pikat Burimi: audiencë. RICK Houlihan: pikë Burimi? Audienca: Nga informacioni, ku informacioni vjen nga? RICK Houlihan: Jo. Ajo që unë jam duke thënë se është në rritje Numri i ndarëse në dyqan e të dhënave përmirëson xhiros. Pra, çfarë po ndodh këtu është përdorues që vijnë në radhë të EC2 deri këtu, mirë, në qoftë se kam nevojë për një përdorues Kjo është një për M, unë do të shkoj këtu. Nga N të p, unë do të shkoj këtu. Nga P në Z, unë do të shkoj këtu. 

Audienca: OK, kështu që ata janë ato ruajtur të gjitha në nyjet e ndryshme? 

RICK Houlihan: Po. Mendoni e tyre si kapanoneve të ndryshme të të dhënave. Pra, ju jeni ka për të bërë këtë. Nëse ju jeni duke u përpjekur për të bërë kjo, në qoftë se ju jeni duke u përpjekur në shkallë në një platformë relacionale, kjo është ajo që ju jeni duke bërë. Ju jeni duke marrë të dhënat dhe ju jeni prerja atë poshtë. Dhe ju jeni ndarjes atë në të gjithë raste të shumta të të dhënave. Dhe ju jeni menaxhimin e të gjitha që në grupin e aplikimit. Kjo është më zbavitëse. Pra, çfarë duam të shkojmë? Ne duan të shkojnë DynamoDB, menaxhuar plotësisht, NoSQL ruajtur të dhënat, xhiros dispozitë. Ne përdorim indekseve mesme. Kjo është në thelb HTTP API dhe përfshin mbështetje dokument. Pra, ju nuk keni për t'u shqetësuar në lidhje me ndonjë prej kësaj ndarje. Ne bëjmë të gjitha për ju. Deri tani, në vend të kësaj, ju vetëm shkruani në tryezë. Nëse tryezë duhet të jetë e ndarë, që ndodh në prapaskenë. Ju jeni krejtësisht e izoluar nga se si një zhvillues. Pra, le të flasim për disa raste përdorim që ne të drejtuar në në lojrave, të përbashkët Skenarët lojrave, drejtues. Pra, ju keni marrë përdoruesit që vijnë në, të BoardNames se ata janë në, rezultatet për këtë përdorues. Ne mund të hashing në userid, dhe pastaj ne kemi gamë të në lojë. Kështu që çdo përdorues dëshiron të shohë të gjitha të lojës ai ka luajtur dhe tërë rezultati i tij të lartë nëpër të gjitha lojë të. Pra, kjo është Fituesit tij personal. 

Tani unë dua të shkoj në dhe unë dua të get-- kështu që unë të marrë këto leaderboards personale. Ajo që unë dua të bëni është të shkoni të merrni rezultati më i lartë në të gjithë përdoruesit. Pra, si mund ta bëni këtë? Kur im është sheshuar në userid, shkonin në lojë, edhe unë jam duke shkuar për të shkuar përpara dhe ristrukturimin, të krijojë një GSI, dhe unë jam duke shkuar për të ristrukturuar këto të dhëna. 

Tani unë jam duke shkuar për të hash mbi BoardName, që është loja. Dhe unë jam duke shkuar për të shkojnë në rezultat të lartë. Dhe tani unë kam krijuar kova të ndryshme. Unë jam duke përdorur të njëjtën tryezë, të njëjtat të dhëna artikull. Por unë jam duke krijuar një kovë që i jep mua një grumbull rezultat të lartë nga loja. 

Dhe unë mund të query atë tryezë për të marrë këtë informacion. Pra, unë kam vendosur se model query deri në të mbështetet nga një indeks të mesme. Tani ata mund të ndahen nga BoardName dhe të renditura nga TopScore, në varësi. Kështu që ju mund të shihni, këto janë lloje të përdorin rasteve ju merrni në lojrave. Një rast tjetër i mirë përdorim ne të merrni në lojrave është çmime dhe që ka fituar çmime. Dhe ky është një rast i madh përdorim ku ne e quajmë indekseve rrallë. Indekset rrallë janë Aftësia për të gjeneruar një indeks që nuk do të përmbajnë çdo send të vetëm në tryezë. Dhe pse jo? Sepse atribut që është duke u e indeksuar nuk ekziston në çdo send. 

Pra, në këtë të veçantë përdorni rast, unë jam duke thënë: ju e dini se çfarë, unë jam duke shkuar për të krijojë një atribut të quajtur Award. Dhe unë jam duke shkuar për të dhënë çdo përdorues se ka një çmim që ia veshin. Përdoruesit që nuk kanë çmime janë nuk do të ketë këtë atribut. Kështu që, kur unë të krijuar indeksi, vetëm përdoruesit që janë duke shkuar për të treguar deri në indeks janë ato që në fakt kanë fituar çmime. Pra, kjo është një mënyrë e madhe të jetë në gjendje për të krijuar indekseve filtruar se janë shumë, shumë selektive që nuk bëjnë duhet të indeksit të gjithë tabelën. 

Pra, ne jemi duke marrë ulët në kohë këtu. Unë jam duke shkuar për të shkuar përpara dhe kaloni jashtë dhe kaloni këtë skenar. Flasim pak? Për 

Audienca: A mund të bëj një pyetje të shpejtë? Njëra është të shkruani rëndë? RICK Houlihan: Çfarë është? Audienca: Shkruani rëndë. RICK Houlihan: Shkruaj rëndë. Me lejo te shikoj. 

Audienca: Apo është se nuk diçka që ju mund të vetëm zë për të në një kohë të shkurtër? RICK Houlihan: Ne do të shkojmë nëpërmjet skenarit votimit. Kjo nuk është edhe aq keq. A ju djema keni disa minuta? NE RREGULL. 

Pra, ne do të flasim për votim. Pra, votimi në kohë reale, ne kemi Kërkesat për votim. Kërkesat janë që ne të lejojë çdo person të votojë vetëm një herë. Ne duam që askush të jenë në gjendje për të ndryshuar votën e tyre. Ne duam kohë reale agregimin dhe analitikë për demografinë se ne do të jetë duke treguar për përdoruesit në këtë faqe interneti. 

Mendoni për këtë skenar. Ne punojmë shumë realitetit TV tregon ku ata janë duke bërë këto lloj saktë të gjërave. Kështu që ju mund të mendoni për skenar, ne kemi miliona dhe miliona vajzat e adoleshente atje me telefonat e tyre celularë dhe votimi dhe votimi, dhe votimi për këdo që ata janë gjetur të jetë më popullore. Pra, këto janë disa nga Kërkesat kemi drejtuar jashtë. 

Dhe kështu i pari marrë në zgjidhjen e këtij problemi do të jetë për të ndërtuar një kërkesë shumë të thjeshtë. Kështu që unë kam marrë këtë app. Unë kam disa votues atje. Ata vijnë në, ata e goditi app votimit. Unë kam marrë disa vota të papërpunuara tryezë Unë do të hale vetëm ato vota në. Unë do të keni disa agregat vota tabelë që do të bëjë analytics mia dhe demografike, dhe ne do të vënë të gjithë këtë në atje. 

Dhe kjo është e madhe. Jeta eshte e mire. Jeta është e mirë deri sa të gjejmë se ka gjithmonë vetëm një ose dy njerëzit që janë të njohura në zgjedhje. Ka vetëm një ose dy gjëra që njerëzit të vërtetë kujdeset për. Dhe nëse ju jeni votimit në shkallë, të gjithë një e papritur unë jam do të jetë e përgatitur ferr nga Dy kandidatë, një ose dy kandidatë. Një numër shumë i kufizuar i artikujve njerëzit të gjejnë të jenë të njohura. 

Kjo nuk është një model i mirë dizajn. Kjo është në fakt një model shumë të keqe të projektimit sepse ajo krijon pikërisht ajo që ne foli për të cilin ishte çelësat e nxehtë. Hot çelësat janë diçka që ne nuk i pëlqen. 

Deri sa nuk kemi të rregullojmë se? Dhe me të vërtetë, mënyra për të rregulluar këtë është duke marrë ato kova kandidate dhe për secilin kandidat që kemi, ne jemi duke shkuar për append një vlerë të rastit, diçka që ne e dimë, të rastit Vlera ndërmjet një dhe 100, midis 100 dhe 1,000, ose ndërmjet një dhe 1.000, megjithatë shumë vlerat e rastit qe doni te append në fund të atij kandidati. 

Dhe çfarë kam bërë me të vërtetë atëherë? Nëse unë jam duke përdorur ID kandidat si kovë të votave agregate, në qoftë se unë kam shtuar një të rastit numër në fund të se Unë kam krijuar tani 10 kova, një njëqind kova, një mijë kova se unë jam përmbledhë vota në të gjithë. 

Pra, unë kam miliona, dhe miliona, dhe miliona e të dhënave që vijnë në për këta kandidatë, unë tani jam duke përhapur këto vota në të gjithë a_1 kandidatit përmes A_100 kandidat, sepse çdo herë që një votë vjen në, Unë jam duke gjeneruar një të rastit Vlera në mes një dhe 100. Unë jam tacking atë mbi fund të Kandidati që personi të votojnë për. Unë jam hedhja atë në atë kovë. 

Tani në pasme, unë e di që kam marrë njëqind kova. Pra, kur unë dua të shkoj përpara dhe mbledhë votat, Kam lexuar nga të gjitha ato kova. Kështu që unë shkoj përpara dhe të shtoni. Dhe atëherë unë do të shpërndaj mblidhen ku të shkoj jashtë dhe të thotë hej, ju e dini se çfarë, çelësi këtij kandidatit hapësira është mbi njëqind kova. Unë jam duke shkuar për të mbledhur të gjitha vota nga ato njëqind kova. Unë jam duke shkuar për të agreguar ata dhe unë jam duke shkuar për të thënë, Kandidati A tani ka Numri total vota e x. 

Tani të dy shkruaj query dhe lexoni query janë të shpërndara bukur sepse unë jam shkrim të gjithë dhe unë jam duke lexuar nëpër qindra çelësat. Unë nuk jam shkrim dhe duke lexuar nëpër një kyç tani. Kështu që është një model i madh. 

Kjo është në fakt ndoshta një e dizajnit më të rëndësishme internetit për shkallë në NoSQL. Ju do të shihni këtë lloj të model të projektimit në çdo shije. MongoDB, DynamoDB, kjo nuk ka çështje, ne të gjithë duhet të bëjmë këtë. Sepse kur ju jeni që kanë të bëjnë me ato aggregations të mëdha, ju duhet të gjej një mënyrë për të përhapjen tyre në të gjithë kova. Pra, kjo është mënyra që ju bëni atë. Të gjithë të drejtë, kështu që çfarë ju jeni duke bërë tani është që ju jeni tregtare off lexoni Kostoja për shkruani scalability. Kostoja e lexoni tim është një kompleks pak më shumë dhe unë duhet të shkoj të lexuar nga një njëqind kova në vend të një. Por unë jam në gjendje për të shkruar. Dhe xhiros im, shkruaj im xhiros është e pabesueshme. Pra, kjo është zakonisht një të vlefshme Teknika për shkallë DynamoDB, ose ndonjë bazës së të dhënave NoSQL për këtë çështje. Kështu që ne artistikisht se si të shkallës atë. Dhe ne artistikisht se si për të eliminuar çelësat e nxehtë tona. Dhe kjo është fantastike. Dhe kemi marrë këtë sistem të bukur. Dhe kjo na ka dhënë votimin shumë korrekte sepse ne kemi votës rekord de-dede. Është e ndërtuar në DynamoDB. Kemi biseduar për të drejtat e kushtëzuara. 

Kur vjen një zgjedhës në, vë një insert në tryezë, ata futur me ID e votuesve, në qoftë se ata përpiqen për të futur një tjetër votë, Unë bëj një shkruaj kushtëzuar. Thuaj vetëm shkruaj këtë në qoftë se kjo nuk ekziston. Pra, sa më shpejt që unë shoh se se vota e goditi tryezë, askush tjetër do të jetë gjendje për të vënë votën e tyre në. Dhe kjo është fantastike. Dhe ne jemi bën rritjen sportelet tona kandidat. Dhe ne jemi duke bërë tonë demografike dhe të gjitha këto. Por çfarë ndodh nëse tim Aplikimi bie mbi? Tani të gjithë një e papritur vota janë të vijnë në, dhe unë nuk e di nëse ata janë duke u përpunuar në analytics mia dhe demografisë më. Dhe kur kërkesa vjen back up, si dreqin e di se çka kanë vota janë përpunuar dhe ku mund të fillojë? 

Pra, ky është një problem i vërtetë kur ju filloni të shikoni në këtë lloj skenari. Dhe si e zgjidhim atë? Ne të zgjidhur atë me atë që ne quajmë DynamoDB Streams. Streams është një kohë urdhërohet dhe log ndarë ndryshimi i çdo qasjes në tryezë, çdo shkruani Qasje në tryezë. Çdo të dhënave që është shkruar me Tabela tregon deri në lumë. 

Kjo është në thelb një radhë 24 orë. Artikuj goditi lumë, ata jetojnë për 24 orë. Ato mund të lexohet disa herë. Garantuar që do të dërgohen vetëm një herë në lumë, mund të lexohet disa n herë. Pra, megjithatë shumë procese qe doni te konsumojnë se të dhënat, ju mund të konsumojnë atë. Ajo do të shfaqet çdo përditësim. Çdo shkruaj vetëm do shfaqet një herë në lumë. Pra, ju nuk keni për t'u shqetësuar në lidhje me përpunimin e tij dy herë nga e njëjta proces. 

Është urdhëroi rreptësisht për artikull. Kur themi kohë urdhëroi dhe e ndarë, ju do të shihni në ndarje në lumë. Ju do të shihni artikujt, përditësimet në rregull. Ne nuk jemi të garantuar në lumë që ju jeni do të merrni çdo transaksion në mënyrë që të gjithë artikujve. 

Pra streams janë idempotent. A ne të gjithë e dimë se çfarë do të thotë idempotent? Idempotent do të thotë që ju mund të bëni atë mbi dhe mbi dhe mbi përsëri. Rezultati do të jetë e njëjtë. 

Streams janë idempotent, por ata duhet të jenë të luajtur nga pika e fillimit, kudo që ju zgjidhni, deri në fund, ose ata nuk do të rezultojë në të njëjtat vlera. 

E njëjta gjë me MongoDB. MongoDB ka një konstrukt ata e quajnë oplog. Është e njëjta konstrukt saktë. Shumë Bazat e të dhënave NoSQL kanë këtë konstrukt. Ata e përdorin atë për të bërë gjëra të si përsëritje, e cila është pikërisht ajo që ne bëjmë me lumenj. Audienca: Ndoshta një pyetje heretike, por ju flasim për Apps bërë poshtë një kështu me radhë. Janë streams garantuara për kurrë ndoshta të shkojnë poshtë? RICK Houlihan: Po, përrenjve janë të garantuara për të nuk shkojnë poshtë. Ne menaxhuar infrastrukturën prapa. streams automatikisht vendoset në grupin e tyre shkallë auto. Ne do të kalojnë nëpër pak bit për atë që ndodh. 

Unë nuk duhet të thonë se ata nuk janë të të garantuara për të nuk shkojnë poshtë. Elementet janë të garantuara për të dalë në lumë. Dhe lumë do të jetë i mundshëm. Pra, çfarë shkon poshtë ose kthehet up, kjo ndodh nën. Është covers-- është në rregull. Të gjithë të drejtë, kështu që ju të merrni të ndryshme Llojet pamje jashtë ekranit. Llojet pikëpamje që janë të rëndësishme për një programues zakonisht janë, çfarë ishte ajo? Unë të marrë pamje të vjetër. Kur një përditësim hits tryezë, ajo do të shtytje pikëpamjen e vjetër në lumë kështu që të dhënat mund të arkivit, ose ndryshim kontrollit, identifikimi ndryshim, ndryshim menaxhimit. 

Imazhi i ri, ajo që tani është pas update, kjo është një tjetër lloj i mendimit ju mund të merrni. Ju mund të merrni të dy imazhe të vjetra dhe të reja. Ndoshta unë dua ata të dy. Unë dua të shoh se çfarë ishte. Unë dua të shoh se çfarë ndryshoi në. 

Unë kam një lloj të pajtueshmërisë e procesit që shkon. Ajo ka nevojë për të verifikuar se kur këto gjëra ndryshojnë, se ata janë brenda kufijve të caktuar ose brenda parametrave të caktuara. 

Dhe pastaj ndoshta unë vetëm duhet të dinë se çfarë ka ndryshuar. Unë nuk bëj kujdes atë artikull ndryshuar. Unë nuk kam nevojë për të duhet të dini çfarë atributet ndryshuar. Unë vetëm duhet të dini se sendet janë duke u prekur. Pra, këto janë llojet e pikëpamjeve që ju të merrni jashtë lumë dhe ju mund të ndërveprojnë me të. 

Aplikacioni që konsumon lumë, kjo është lloj i mënyrës kjo funksionon. Klienti DynamoDB kërkojë për shtytje të dhëna në tabelat. Streams vendosur në atë që ne e quajmë shards. Shards janë shkallëzuar në mënyrë të pavarur të tabelës. Ata nuk të vijë deri plotësisht në ndarëse e tryezën tuaj. Dhe arsyeja pse është e sepse ata vargoj të kapacitetit, aktuale Kapaciteti i tabelës. 

Ata vendosë në e tyre vet grupi madhesise auto, dhe ata fillojnë të tjerr jashtë në varësi për sa shkruan po vijnë në, Sa reads-- me të vërtetë është e shkruan. Nuk ka reads-- por si shumë shkruan po vijnë në. 

Dhe pastaj në anën e pasme fund, ne kemi atë që ne thërrasë një KCL, ose kinesis Klienti Library. Kinesis është një lumë të dhënave Teknologjia e përpunimit nga Amazon. Dhe lumenj është e ndërtuar mbi atë. 

Kështu që ju përdorni një KCL aktivizuar Aplikimi për të lexuar derdhet. Klienti Biblioteka kinesis fakt menaxhon punëtorët për ju. Dhe ai gjithashtu ka disa gjëra interesante. Kjo do të krijojë disa tabela lart në tablespace tuaj DynamoDB për të gjetur sende të cilat janë përpunuar. Pra, në këtë mënyrë, nëse ajo bie përsëri, në qoftë se ajo bie mbi dhe vjen dhe merr u back up, ajo mund të përcaktojë se ku ishte ajo në përpunimin lumë. 

Kjo është shumë e rëndësishme kur ju jeni duke folur për përsëritje. Unë duhet të dini se çfarë dhënave u janë përpunuar dhe çfarë të dhëna ende të përpunohen. Pra, biblioteka KCL për rrjedhat do të t'ju japë një shumë të këtij funksionalitetit. Ai kujdeset për të gjithë shtëpisë së. Ajo qëndron një punëtor për çdo copë e thyer. Ajo krijon një tryezë administrative për çdo copë e thyer, për çdo punëtor. Dhe si ata punëtorë zjarr, ata mbajnë ato tavolina kështu që ju e dini këtë rekord u lexuar dhe përpunuar. Dhe pastaj në këtë mënyrë nëse procesi vdes dhe kthehet në internet, ajo mund të rifillojë të drejtë ku ajo mori hov. 

Pra, ne i përdorim këtë për përsëritje ndër-rajon. Një shumë e konsumatorëve kanë nevojën për të lëvizin të dhënat apo pjesë të tabelave të të dhënave të tyre rreth në rajone të ndryshme. Ka nëntë rajone e gjithë bota. Pra, nuk mund të jetë një unë need-- mund të ketë përdorues në Azi, përdoruesit në Bregdetin Lindor të Shteteve të Bashkuara. Ata kanë të dhëna të ndryshme që duhet të shpërndahen në nivel lokal. Dhe ndoshta një përdorues fluturon nga Azi gjatë në Shtetet e Bashkuara, dhe unë dua të përsëris të dhënat e tij. Pra, kur ai merr nga avioni, ai ka një përvojë e mirë duke përdorur aplikacionin e tij celular. 

Ju mund të përdorni ndër-rajonin Biblioteka përsëritje për të bërë këtë. Në thelb ne kemi dhënë dy teknologjive. Një është një aplikim i konsol ju mund të të qëndrojë deri në vetë shembull tuaj EC2. Ajo shkon përsëritje të pastër. Dhe pastaj ne ju dha bibliotekën. Biblioteka ju mund të përdorni për të ndërtuar aplikimi juaj nëse ju duan të bëjnë gjëra të çmendur me që data-- filtër, përsëris vetëm një pjesë të saj, rrotullohen dhënat, lëvizin atë në një tavolinë të ndryshme, kështu me radhë e kështu me radhë. Pra, kjo është lloj i asaj që duket si. 

DynamoDB Streams mund të jetë përpunuara nga ajo që ne e quajmë lambda. Ne kemi përmendur pak për ngjarjen shtyrë arkitektura e aplikimit. Lambda është një komponent kyç i kësaj. Lambda është kodi që zjarret në kërkesën në përgjigje të një ngjarjeje të veçantë. Një nga këto ngjarje mund të jetë një rekord shfaqeshin në lumë. Nëse një rekord shfaqet në lumë, ne do të thërrasë këtë funksion Java. E pra, kjo është e JavaScript, dhe Lambda mbështet Node.js, Java, Python, dhe do të mbështesë së shpejti gjuhët e tjera si edhe. Dhe mjaftonte për të thënë, kjo është kodi i pastër. shkruaj Në Java, ju përcaktoni një klasë. Ju shtyjnë jar lart në lambda. Dhe pastaj ju specifikoni cilat klasë për të thirrur në përgjigje të cilën ngjarje. Dhe pastaj infrastruktura Lambda pas se do të kandidojë atë kod. 

Se kodi mund të procesit të dhënat off lumë. Ajo mund të bëjë asgjë ajo dëshiron me të. Në këtë shembull të veçantë, të gjithë ne jemi të vërtetë duke bërë është prerjet atributet. Por kjo është vetëm kod. Kodi mund të bëjë asgjë, e drejtë? 

Kështu që ju mund të rrotullohen ato të dhëna. Ju mund të krijoni një pamje derivat. Në qoftë se kjo është një strukturë dokument, ju mund të shkatërroj strukturën. Ju mund të krijoni indekseve alternative. Të gjitha llojet e gjërave që ju mund bëjnë me rrjedhat DynamoDB. 

Dhe me të vërtetë, kjo është ajo që duket si. Pra, ju merrni ato më të reja që vijnë në. Ata po vijnë jashtë string. Ata janë lexuar nga funksioni lambda. Ata po rradhës të dhënat dhe shtyjnë atë deri në tabelat derivative, njoftuar sistemeve të jashtëm të ndryshimit, dhe shtyn të dhënat në ElastiCache. 

Ne biseduam rreth asaj se si për të vënë në cache në frontin e bazën e të dhënave për atë shitje skenar. E pra çfarë ndodh në qoftë se unë update përshkrimin artikull? E pra, në qoftë se kam pasur një Lambda Funksioni kandidon në këtë tryezë, në qoftë se unë të rinovuar përshkrimin pika, ajo do të marr rekordin off lumë, dhe ajo do update ElastiCache shembull me të dhënat e reja. Pra, kjo është një shumë e Çfarë bëjmë ne me lambda. Kjo është kodi zam, lidhje. Dhe kjo në fakt i jep aftësia për të nisur dhe për të drejtuar kërkesat shumë komplekse pa një server të dedikuar infrastruktura, e cila është me të vërtetë cool. 

Pra, le të kthehemi në tonë kohë reale arkitekturës votimit. Kjo është e re dhe e përmirësuar me tonë lumenj dhe KCL aktivizuar aplikacionin. Njësoj si më parë, ne mund të të trajtojë çdo shkallën e zgjedhjeve. Ne si kjo. Ne jemi duke bërë jashtë grumbullon shpërndaj nëpër kova të shumta. Ne kemi marrë mbyllje optimist në vazhdim e sipër. Ne mund të mbajë votuesit tanë nga ndryshimi votat e tyre. Ata mund të votojnë vetëm vetëm një herë. Kjo është fantastike. Toleranca faji në kohë reale, grumbullimi shkallëzuar tani. Kjo gjë bie mbi, atë e di se ku për të rifilluar veten kur ajo vjen përsëri për shkak ne jemi duke përdorur app OAK. Dhe pastaj ne gjithashtu mund të përdorin atë Aplikimi KCL për të nxitur e të dhënave nga për RedShift për tjetrin analytics app, ose të përdorë të MapReduce elastik për të drejtuar në kohë reale streaming aggregations off e këto të dhëna. 

Pra, këto janë gjëra që ne nuk kanë folur për shumë. Por ata janë shtesë teknologjitë që vijnë të mbajnë kur ju jeni në kërkim në këto lloje të skenarëve. 

Të gjithë të drejtë, kështu që kjo është në lidhje analytics me DynamoDB streams. Ju mund të mbledhë de-dede të dhënat, të bëjë të gjitha llojet e gjëra të këndshme, të dhëna të përgjithshme në kujtesës, të krijojë këto tavolina të rrjedhura. Ky është një rast i madh përdorim se një shumë e konsumatorëve janë të përfshirë me të, duke marrë mbivendosur Pronat e këtyre dokumenteve JSON dhe krijimin e indekseve të tjera. 

Ne jemi në fund. Faleminderit për duke pasur me mua. Pra, le të flasim për Arkitektura referencë. DynamoDB ulet në mes të kaq shumë e infrastrukturës AWS. Në thelb ju mund të lidh atë deri në çdo gjë që ju dëshironi. Aplikime ndërtuar duke përdorur Dynamo përfshijnë Lambda, ElastiCache, CloudSearch, shtytje të dhënave jashtë në Elastike MapReduce, eksport-import nga DynamoDB në S3, të gjitha llojet e menu. Por ndoshta më e mira gjë për të folur në lidhje me, dhe kjo është ajo që është me të vërtetë interesante është kur ne flasim për ngjarje të shtyrë aplikacioneve. 

Ky është një shembull i një projekti të brendshëm që kemi se ku ne jemi në fakt botuese të mbledhur rezultatet e anketës. Pra, në një lidhje email që kemi dërguar jashtë, nuk do të të jetë një klik pak lidhje thënë këtu për t'iu përgjigjur anketës. Dhe kur një person klikime që lidhen, çfarë ndodh është se ata shemb një të sigurt Forma HTML studim nga S3. Nuk ka server. Kjo është vetëm një objekt S3. 

Kjo formë vjen deri, ngarkesa deri në shfletuesin. Atë e mori shtyllë. Atë e mori kompleks JavaScript se është e running. Pra, kjo është kërkesë shumë e pasur drejtimin në shfletuesin e klientit. Ata nuk e dinë se ata nuk janë bashkëveprojmë me një server mbrapa fund. Në këtë pikë, kjo është e gjitha shfletues. 

Ata publikojnë rezultatet në çfarë ne e quajmë Amazon API Gateway. API Gateway është thjesht një web API që ju mund të përcaktojë dhe të lidh për çdo gjë që ju dëshironi. Në këtë rast të veçantë, ne jemi përkulur deri në një funksion lambda. 

Pra, operacion ime POST është ndodh me asnjë server. Në thelb kjo API Gateway ulet atje. Ajo kushton më asgjë derisa njerëzit fillojnë postimi atë, e drejtë? Funksioni Lambda vetëm ulet atje. Dhe kjo më kushton asgjë deri njerëzit fillojnë të goditur atë. Kështu që ju mund të shihni, si vëllimit rritet, kjo është kur akuzat vijnë. Unë nuk jam drejtimin e një server 7/24. 

Kështu që unë tërheq formularin poshtë nga kovë, dhe unë postoni përmes API Portë në funksion lambda. Dhe pastaj Lambda funksion thotë, ju e dini çfarë, unë kam marrë disa PIIs, disa personalisht të identifikueshme në këto përgjigje. Kam marrë komente që vijnë nga përdoruesit. Unë kam marrë adresat e-mail. Unë kam marrë përdoruesve. 

Më lejoni të ndarë këtë off. Unë jam duke shkuar për të gjeneruar disa metadata off këtë rekord. Dhe unë jam duke shkuar për të shtyjë metadata në DynamoDB. Dhe unë mund të encrypt të gjitha të dhënat dhe të shtyjë atë në DynamoDB qoftë se unë dua. Por është më e lehtë për mua, në këtë përdorin çështjen, për të shkuar përpara një rol, Unë jam duke shkuar për të nxitur të dhënat e papërpunuara në një kovë të koduar S3. Kështu që unë përdorin ndërtuar në S3 anën e serverit encryption dhe Menaxhimi Key Amazon Shërbim kështu që unë kam një çelës që mund të rrotullohen në një interval të rregullt, dhe unë mund të mbrojë se të dhënat PII si pjesë e tërë këtij punës. 

Pra, çfarë kam bërë? Unë kam vendosur vetëm një e tërë aplikimit, dhe unë nuk kam asnjë server. Pra, është ajo ngjarje të shtyrë zbatimin Arkitektura bën për ju. 

Tani në qoftë se ju mendoni rreth rasti përdorimi për this-- ne kemi klientët e tjerë unë jam duke folur në lidhje me këtë arkitekturë saktë që drejtuar fushata phenomenally të mëdha, të cilët janë duke kërkuar në këtë dhe duke shkuar, oh my. Sepse tani, ata mund në thelb të shtyjë atë atje, le se fushatë të rrimë aty deri sa nis, dhe jo duhet të shqetësohen një fik për çfarë lloj i infrastrukturës do të jetë atje për të mbështetur atë. Dhe pastaj sa më shpejt se fushata është bërë, kjo është si të infrastrukturës vetëm menjëherë shkon larg sepse ka të vërtetë ka infrastrukturë. Është kodi vetëm që ulet në lambda. Është dhënat vetëm që ulet në DynamoDB. Kjo është një mënyrë e mrekullueshme për të ndërtuar aplikime. 

Audienca: Pra, është ajo më shumë jetëshkurtër se ajo do të jetë në qoftë se ajo është ruajtur në një server të vërtetë? 

RICK Houlihan: Absolutisht. Sepse këtë server shembull do të duhet të jetë një 7/24. Ajo duhet të jetë në dispozicion për dikush për t'iu përgjigjur. Well guess what? S3 është në dispozicion 7/24. S3 gjithmonë përgjigjet. Dhe S3 është shumë, shumë i mirë që shërbejnë up objekte. Ato objekte mund të jetë fotografi HTML, ose Fotografi JavaScript, ose çdo gjë që ju dëshironi. Ju mund të drejtuar kërkesat shumë të pasur web nga kovat S3, dhe njerëzit bëjnë. 

Dhe kështu kjo është ideja këtu është për të marrë larg nga rruga kemi përdorur për të mendoj për atë. Ne të gjithë e përdorur për të mendoj në Kushtet e servers dhe pret. Kjo nuk është për atë më. Është në lidhje me infrastrukturën si kod. Vendosë kodin në cloud dhe le të reja të kandidojë atë për ju. Dhe kjo është ajo që AWS është duke u përpjekur për të bërë. 

Audienca: Pra kutinë tuaj të artë në mes i API Gateway nuk është server-si, por në vend të kësaj është just-- 

RICK Houlihan: Ju mund të mendoni atë si server fasadë. Të gjitha ajo është është ajo do të marrë një HTTP kërkojnë dhe hartë atë në një tjetër proces. Kjo është e gjitha ajo ka. Dhe në këtë rast, ne jemi hartes ajo në një funksion lambda. Të gjithë të drejtë, kështu që kjo është e gjitha që kam marrë. Faleminderit shumë. E vleresoj. Unë e di se ne duam pak me kalimin e kohës. Dhe shpresojmë se ju djema mori pak e informacionit që ju mund të marr me vete sot. Dhe unë kërkoj falje në qoftë se unë shkova mbi disa nga kokat tuaja, por ka një shumë të mirë të Njohuri themelore themelore që unë mendoj se është shumë e vlefshme për ju. Pra, ju falënderoj për të pasur mua. [Duartrokitje] Audienca: [padëgjueshme] është kur ju ishin duke thënë keni pasur për të shkuar nëpërmjet gjë që nga fillimi deri në fund për të marrë vlerat e duhura ose të njëjtat vlera, si do vlerat të ndryshojë në qoftë se [e padëgjueshme]. 

RICK Houlihan: Oh, idempotent? Si do të ndryshojë vlerat? E pra, sepse në qoftë se unë nuk e drejtuar kjo të gjithë rrugën deri në fund, atëherë unë nuk e di se çfarë ndryshon janë bërë në milje e fundit. Kjo nuk do të jetë të dhënat e njëjtë me atë që pashë. Audienca: Oh, kështu që ju vetëm nuk kanë marrë të gjithë input. RICK Houlihan: E drejta. Ju keni për të shkuar nga fillimi deri në fund, dhe pastaj është do të jetë një shtet i qëndrueshëm. Ftohtë. 

Audienca: Pra, ju na tregoi DynamoDB mund të bëjë dokument apo vlerën kyç. Dhe kemi shpenzuar shumë kohë në Vlera e kyç me një hash dhe mënyrat për të rrokullisje atë rreth. Kur keni shikuar në ato tavolina, është se duke lënë prapa qasjen e dokumenteve? 

RICK Houlihan: Unë nuk do të thonë se e lënë atë prapa. 

Audienca: Ata ishin ndarë nga the-- 

RICK Houlihan: Me dokumentin qasja, lloji dokumenti në DynamoDB është vetëm e mendojmë si një atribut. Kjo është një atribut që përmban një strukturë hierarkike të dhënave. Dhe pastaj në pyetje, ju mund të përdorni pronat e këtyre objekteve duke përdorur simbol Object. Kështu që unë mund të filtruar në një mbivendosur pronë e dokumentit JSON. Audienca: Pra, çdo herë që unë të bëjë një qasje dokument, Unë mund të lloj të arrijnë në tabular-- Audienca: Absolutisht. Audienca: --indexes dhe gjëra që ju vetëm biseduar rreth. RICK Houlihan: Po, The indekseve dhe të gjitha që, kur ju doni të indeksit të Pronat e JSON, mënyrë që ne do të duhet për të bërë këtë është në qoftë se ju futur një objekt JSON apo një dokument në Dynamo, që ju do të përdorni streams. Streams do të lexoni dhëna. Ju do të merrni se JSON kundërshtojnë dhe ju do të them OK, çfarë është pronë që unë dua të indeksit? 

Ju krijoni një tabelë derivat. Tani që është mënyra ajo punon tani. Ne nuk do të ju lejojnë për të indeksit direkt ato prona. 

Audienca: Tabularizing dokumentet tuaja. 

RICK Houlihan: Pikërisht, rrafshim ajo, tabularizing atë, pikërisht. Kjo është ajo që ju bëni me të. 

Audienca: Ju faleminderit. 

RICK Houlihan: Po, absolutisht, faleminderit. Audienca: Pra, kjo është lloj i Mongo takohet classifers Redis. 

RICK Houlihan: Po, kjo është një shumë si kjo. Kjo është një përshkrim i mirë për të. Ftohtë.