[TÓNLIST spila] RICK Houlihan: Allt í lagi. Hæ allir. Mitt nafn er Rick Houlihan. Ég er eldri skólastjóri lausnir arkitekt á AWS. Ég leggja áherslu á NoSQL og DynamoDB tækni. Ég er hér í dag til að tala við þú svolítið um þá. 

Bakgrunnur minn er fyrst og fremst í gögnum lag. Ég eyddi hálfri þróun mína Ferill skrifa gagnagrunn, gögn aðgangur, lausnir fyrir ýmsum forritum. Ég hef verið í Cloud virtualization fyrir um 20 árum. Svo áður en Cloud var Cloud, við notuðum til að kalla það gagnsemi computing. Og hugmyndin var, það er eins og PG & E, greiðir þú fyrir það sem þú notar. Í dag við köllum það skýið. 

En í gegnum árin hef ég unnið fyrir a par af fyrirtækjum þú hefur sennilega aldrei heyrt um. En ég hef tekið saman lista yfir tæknilega Afrekum, held ég að þú myndir segja. Ég hef átta einkaleyfi í Cloud kerfi virtualization, örgjörvi hönnun, flókið atburður vinnslu, og á öðrum sviðum eins og heilbrigður. 

Svo þessa dagana, einbeita ég aðallega á NoSQL tækni og næsta kynslóð gagnagrunnur. Og það er yfirleitt það sem ég ætla að vera hér að tala við þig í dag um. Svo það sem þú getur búist við frá þessum fundi, við munum fara í gegnum stutta Saga gagnavinnslu. Það er alltaf gagnlegt að skilja hvaðan við komum og hvers vegna við erum þar sem við erum. Og við munum tala svolítið hluti um NoSQL tækni frá grundvallar sjónarmiði. 

Við munum fá inn í sumir af að DynamoDB innri. DynamoDB er ekkert bragð AWS er. Það er fullkomlega tekist og hýst NoSQL lausn. Og við munum tala svolítið um borð uppbyggingu, API, gögn tegundir, vísitölur, og sumir af the innri þeirrar DynamoDB tækni. Við munum fá inn í sumir af the hönnun mynstur og bestu starfsvenjur. Við munum tala um hvernig þú nota þessa tækni fyrir nokkrum umsókna dag. Og þá munum við tala svolítið um þróun eða tilkomu af nýrri hugmyndafræði í forritun kallast atburður-ekin forrit og hvernig DynamoDB spilar í það eins vel. Og við munum láta þér smá tilvísun arkitektúr umræða svo við getum talað um tiltekin leiðir sem þú getur notað DynamoDB. 

Svo fyrst off-- þetta er spurning Ég heyri mikið er, hvað er gagnagrunnur. A einhver fjöldi af fólk hugsa þeir vita hvað gagnagrunnurinn er. Ef þú Google, munt þú sjá þetta. Það er a skipulögð sett af gögnum haldið í tölvu, sérstaklega einn sem er aðgengileg á ýmsa vegu. Ég geri ráð fyrir það er gott Skilgreining á nútíma gagnagrunninum. En ég er ekki eins og það, vegna þess að það felur í sér nokkra hluti. Það felur í sér uppbyggingu. Og það felur í sér að það er á tölvunni. Og gagnagrunna ekki alltaf vera til á tölvum. Gagnagrunnar í raun verið á margan hátt. 

Svo betri skilgreining á a Gagnagrunnurinn er eitthvað eins og þetta. A gagnagrunnur er skipulögð vélbúnaður til að geyma, stjórna, og sækja upplýsingar. Þetta er frá About.com. Svo ég svona vegna þess að það er í raun viðræður um gagnagrunn vera geymsla, geymsla upplýsingar, ekki endilega eitthvað sem situr á tölvunni. Og í gegnum söguna, við hafa ekki alltaf haft tölvur. 

Nú, ef ég spyrja meðaltali verktaki í dag hvað er gagnagrunnur, það er svarið sem ég fá. Einhvers staðar ég get standa efni. Ekki satt? Og það er satt. En það er óheppilegt. Þar sem gagnagrunnurinn er mjög grundvöllur nútíma app. Það er grunnurinn af hverjum umsókn. Og hvernig þú byggja það gagnagrunnur, hvernig þið byggið þessi gögn er að fara að fyrirmæli hvernig það umsókn framkvæma eins og þú mælikvarði. 

Svo mikið af starfi mínu í dag er að takast á við það sem gerist þegar verktaki að taka þessa nálgun og takast á við eftirmála umsóknar sem er nú stigstærð utan upprunalega ásetningur og þjást af slæmur hönnun. Svo vonandi þegar þér ganga í burtu í dag, munt þú hafa a par af verkfærum í Beltið sem mun halda þér frá því að gera sömu mistök. Allt í lagi. Svo skulum við tala um smá Tímalína á tækni gagnasafn. Ég held að ég las grein ekki fyrir löngu og það sagði eitthvað á lines-- það er mjög ljóðræn yfirlýsingu. Það sagði sögu gagna vinnsla er fullt af hár vatnsmerki gagna gnægð. OK. Nú held ég að sé eins konar satt. En ég lít reyndar á er eins og Saga er í raun fyllt með hár vatnsmerki gagna þrýstingi. Vegna þess að gögn hlutfall af inntaka fer aldrei niður. Það fer bara allt. 

Og nýsköpun á sér stað þegar sjáum gögn þrýstingi, sem er því gagnamagni sem er nú í að koma inn í kerfið. Og það er ekki hægt að vinna duglegur annaðhvort í tíma eða í kostnaði. Og það er þegar við byrjum að líta á gögn þrýstingi. 

Svo þegar við skoðum Fyrsta gagnasafn þetta er sá sem var á milli eyrnanna á okkur. Við erum öll fædd með það. Það er gott gagnasafn. Það hefur mikið framboð. Það er alltaf á. Þú getur alltaf fengið það. 

En það er einn notandi. Ég get ekki að deila hugsunum mínum með þér. Þú getur ekki fá hugsanir mínar þegar þú vilt þá. Og abilitiy þeirra er ekki svo gott. Við gleyma hlutum. Sérhver nú og þá, einn af okkur leyfi og færist á annan tilvist og við missa allt sem var í því gagnagrunninum. Svo er það ekki allt sem gott. 

Og þetta virkaði vel með tímanum þegar við vorum aftur í dag þegar allt við þurftum virkilega að vita er þar erum við að fara að fara á morgun eða þar sem við safna bestu mat. En eins og við byrjuðum að vaxa eins og a menningu og ríkisstjórnin byrjaði að koma inn að vera, og fyrirtæki byrjuðu að þróast, við byrjuðum að við gerum við þurfa aðeins meira en það sem við gætum sett í höfði okkar. Allt í lagi? 

Við þurftum kerfi skrá. Við þurftum staði til að vera fær gögn geyma. Svo við byrjuðum að skrifa skjöl, búa bóka- og skjalasafna. Við byrjuðum að þróa kerfi a höfuðbók bókhald. Og það kerfi höfuðbók telja hljóp heim fyrir mörgum öldum, og kannski jafnvel árþúsundir og við ólumst konar að benda þar sem gögn hlaða bera getu þessara kerfa að vera fær um að innihalda það. 

Og þetta raunverulega gerðist í 1880s. Ekki satt? Í 1880 US Census. Þetta er í raun þar sem beygja benda nútíma gagnavinnslu. Þetta er punkturinn þar sem magn gagna sem var verið innheimt af US ríkisstjórnin fékk til að benda þar sem það tók átta ár að vinna úr. 

Nú, átta years-- sem þú veist, manntal keyrir á 10 years-- svo það er nokkuð augljóst að með tímanum við fékk 1890 manntal, magn af gögnum sem var að fara til að vinna af stjórnvöldum var að fara að vera hærri en 10 ár sem það myndi taka að stokkunum nýju manntal. Þetta var vandamál. 

Svo strákur sem heitir Herman Hollerith kom með og hann fann eining met bolla spil, kýla lesandi, kýla kort tabulator og samanburði á Fyrirkomulag þessa tækni. Og að fyrirtæki sem hann myndast á tími, ásamt nokkrum öðrum, raun varð einn af grunnstoðum a lítil fyrirtæki við þekkjum í dag sem heitir IBM. 

Svo IBM var upphaflega í gagnagrunnurinn fyrirtæki. Og það er í raun það sem þeir gerðu. Þeir gerðu gagnavinnslu. 

Eins og svo útbreiðslu kýla spil, snjallt kerfi af því að vera fær um að nýta sem tækni að kosning flokkuð útkoma setur. Þú getur séð á þessari mynd þar sem við höfum little-- það er lítið small-- en þú getur séð mjög snjallt vélrænni kerfi þar sem við höfum kýla kort þilfari. Og taka einhver er smá skrúfjárn og stafur í gegnum rifa og lyfta henni upp að fá að passa, sem flokkuð niðurstöður sett. 

Þetta er samansafn. Við gerum þetta allan tímann í dag í tölvunni, þar sem þú gerir það í dag. Við notuðum til að gera það handvirkt, ekki satt? Fólk setti þetta saman. Og það var útbreiðsla þessara gatakortum í það sem við kölluð gögn trommur og gögn hjóla, pappír borði. 

The gagnavinnslu iðnaður tók lexía frá the leikmaður píanó. Player Pianos aftur á að aldamótin er notað til að nota pappír hjóla með afgreiðslutíma á að segja það sem takkana til að spila. Þannig að tæknin var aðlöguð loksins að geyma stafræn gögn, vegna þess að þeir gætu sett þessi gögn á þeim pappír borði hjóla. 

Nú, eins og a afleiðing, gögn var actually-- hvernig þér aðgang að þessum gögnum var beint háð því hvernig þú geyma það. Þannig að ef ég setti gögn á borði, Ég hafði aðgang að gögnum línulega. Ég þurfti að rúlla allri borði til að fá aðgang að öllum gögnum. Ef ég setti gögnin í bolla spil, gæti ég nálgast það í aðeins meira handahófi tíska, kannski ekki eins fljótt. 

En það voru takmarkanir á því hvernig við aðgang að gögnum á grundvelli hvernig var geymt. Og svo þetta var vandamál að fara í '50s. Aftur getum við byrjað að sjá að eins og við þróa nýja tækni til að vinna gögn, hægri, opnast það upp dyrnar að nýjum lausnum, fyrir nýjum verkefnum, nýjum umsóknir um þessi gögn. Og í raun, stjórnun kann að hafa verið ástæðan hvers vegna við þróað sumir af þessum kerfum. En fyrirtækið hratt varð ökumaður á bak við þróun nútíma gagnagrunn og nútíma skráarkerfi. 

Svo the næstur hlutur sem kom upp var í '50s var skrá kerfi og þróun handahófi aðgangur geymslu. Þetta var falleg. Nú, allt í einu, við getum sett okkar skrár hvar sem er á þessum harða diska og við getum nálgast þessi gögn af handahófi. Við getum flokka sem upplýsingar úr skrám. Og við leyst öll heimsins vandamál með gagnavinnslu. 

Og það stóð um 20 eða 30 ára þar til þróun af Venslagagnagrunnur, sem er þegar heimurinn ákváðum við nú þurfa að hafa geymsla sem tekst sem borganna gagna yfir skrá kerfi sem við höfum byggt. Ekki satt? Of mikið af gögnum sem dreift er of margir stöðum, de-fjölföldun gagna, og kostnaður við geymslu var gríðarlegur. 

Í '70s, dýrasta auðlind sem tölvan hafði var geymsla. The gjörvi var litið á sem föstum kostnaði. Þegar ég kaupa kassa, CPU er sumir vinna. Það er að fara að snúast um hvort það er í raun að vinna eða ekki. Það er í raun sökkt kostnaður. 

En hvað kosta mig sem fyrirtæki er geymsla. Ef ég þarf að kaupa fleiri diska næsta mánuði, sem er raunverulegur kostnaður sem ég borga. Og að geymsla er dýrt. 

Nú erum við hratt áfram 40 ár og við höfum mismunandi vandamál. The reikna er nú Dýrasta auðlind. Geymsla er ódýr. Ég meina, við getum farið hvert sem er á ský og við getum fundið ódýr geymslu. En það sem ég get ekki fundið er ódýr reikna. 

Svo þróun í dag er tækni, gagnasafn tækni, er í raun snýst um Úthluta Gagnasafn sem ekki þjást af samskonar mælikvarða takmarkanir Vensla gagnagrunna. Við munum tala svolítið um hvað það þýðir í raun. 

En ein af ástæðunum og ökumaður á bak this-- vér talaði um gögn þrýstingi. Gögn þrýstingur er eitthvað sem rekur nýsköpun. Og ef þú horfir á yfir á síðustu fimm árum, þetta er graf af hvaða gögnum hlaða yfir almenna framtak lítur út eins og á síðustu fimm árum. 

Og Almenna þumalputtaregla þessi days-- ef þú ferð Google-- er 90% af gögnum sem geymum í dag, og það var mynda á síðustu tveimur árum. OK. Nú, þetta er ekki stefna sem er nýtt. Þetta er stefna sem hefur verið fara út fyrir 100 árum. Allt frá því að Herman Hollerith þróað kýla kort, við höfum verið að byggja upp gögn geymsla og safna gögnum á stórkostlegum afslætti. 

Svo á síðustu 100 árum, við höfum séð þessa þróun. Það er ekki að fara að breytast. Fara fram, við erum að fara að sjá þetta, ef ekki að flýta þróun. Og þú getur séð hvað það lítur út. 

Ef fyrirtæki árið 2010 hafði einn terabæti af gögnum í stýringu, í dag sem þýðir að þeir eru stjórna 6,5 ​​petabytes gagna. Það er 6.500 sinnum fleiri gögn. Og ég veit þetta. Ég vinn með þessum fyrirtækjum á hverjum degi. Fimm árum síðan, ég myndi tala við fyrirtæki hver myndi tala við mig um hvað sársauki það er að stjórna terabytes gagna. Og þeir myndu tala við mig um hvernig við sjáum að þetta er líklega að fara til að vera petabyte eða tveir innan fárra ára. 

Þessi sömu fyrirtæki í dag ætla ég að hitta, og þeir eru að tala við mig um Vandamálið er það að hafa stjórna tugir, 20 petabytes gagna. Svo sprengingu af gögn í greininni er að aka gífurleg þörf fyrir betri lausnir. Og Venslagagnagrunnur er bara ekki lifandi upp til eftirspurn. 

Og svo er það línulegt fylgni milli gögnum þrýstingi og tæknilega nýsköpun. Sagan hefur sýnt okkur þetta, að með tímanum, Í hvert skipti sem magn gagna sem þarf til að vinna meiri en afkastagetu þess að vinna það innan hæfilegs tíma eða á sanngjörnu verði, þá ný tækni eru fundin til að leysa þau vandamál. Þeir ný tækni, aftur á móti, opna hurðina að annað sett af vandamálum, sem er að safna saman jafnvel fleiri gögn. 

Nú erum við ekki að fara að hætta þessu. Ekki satt? Við erum ekki að fara að hætta þessu. Hvers vegna? Þar sem þú getur ekki vita allt það er að vita í alheiminum. Og svo lengi sem við höfum verið á lífi, um sögu mannsins, við höfum alltaf ekið að vita meira. 

Svo það virðist eins og hvert tomma við flytja niður leið vísindalegum uppgötvun, við erum að margfalda magn gagna að við þurfum að vinna veldishraða eins og við afhjúpa meira og meira og meira um innri starfsemi lífsins, um hvernig alheimurinn virkar, um akstur vísindalegar uppgötvun, og uppfinningin, sem við erum að gera í dag. Það gagnamagn bara stöðugt eykst. Svo að vera fær um að takast á við þetta vandamál er gríðarlegur. 

Svo einn af þeim hlutum við lítum eins hverju NoSQL? Hvernig virkar NoSQL leysa þetta vandamál? Jæja, Vensla gagnagrunna, Structured Query Language, SQL-- það er í raun hugsmíð af Vensla database-- þetta eru bjartsýni fyrir geymslu. 

Aftur í '70s, aftur, diskur er dýr. The úthlutun æfing geymslu í fyrirtækinu er aldrei-endir. Ég veit. Ég bjó hana. Ég skrifaði geymslu ökumenn fyrir að enterprised superserver fyrirtæki aftur í '90s. Og botn lína er rekki annar geymsla fylking var bara eitthvað sem gerðist á hverjum degi í fyrirtækinu. Og það stoppaði aldrei. Meiri þéttleika geymslu, eftirspurn fyrir hár þéttleiki geymslu, og skilvirkari geymslu devices-- það er aldrei hætt. 

Og NoSQL er frábær tækni því það normalizes gögn. Það de-afrit gagna. Það setur gögnin í uppbyggingu sem er efasemdarmaður öllum aðgang mynstur. Mörg forrit geta högg að SQL gagnagrunn, hlaupa tilfallandi fyrirspurnir, og fá gögn í laginu sem þeir þurfa að vinna fyrir vinnuálag þeirra. Það hljómar frábærlega. En botn lína er með eitthvað kerfi, ef það er efasemdarmaður að öllu, það er bjartsýni fyrir ekki neitt. OK? 

Og það er það sem við fáum með sem Venslagagnagrunnur. Það er bjartsýni fyrir geymslu. Það er eðlileg. Það er Vensla. Það styður tilfallandi fyrirspurnir. Og það og það vog lóðrétt. 

Ef ég þarf að fá stærri SQL gagnagrunn eða öflugri SQL gagnagrunn, Ég fara kaupa stærri stykki af járni. OK? Ég hef unnið með fullt af viðskiptavinum sem hafa verið í gegnum helstu uppfærslu í SQL innviði þeirra aðeins til að finna út sex mánuðum síðar, þeir fara á vegginn aftur. Og svarið frá Oracle eða MSSQL eða einhver annar er að fá stærri kassa. Jæja fyrr eða síðar, þú getur ekki keypt a stærri kassi, og það er raunverulegt vandamál. Þurfum við að breyta hlutum. Svo hvar er þetta? Það virkar vel fyrir offline greinandi OLAP-gerð vinnuálag. Og það er í raun þar sem SQL tilheyrir. Nú, það er notað í dag í mörgum netinu viðskiptalegs vinnslu-gerð forrit. Og það virkar bara fínt í sumir láréttur flötur af nýtingu, en það bara virkar ekki mælikvarði á þann hátt að NoSQL gerir. Og við munum tala svolítið hluti um hvers vegna það er. 

Nú, NoSQL, á hinn bóginn, er meira bjartsýni fyrir óendanlegur. OK? Það er ekki efasemdarmaður að aðgangur mynstur. Er það sem við köllum de-eðlileg uppbygging eða valdakerfi. Gögnin í Venslagagnagrunnur er byrjuðu að dansa frá mörgum borðum til að framleiða þá skoðun sem þú þarft. Gögnin í NoSQL gagnagrunni er geymt í skjali sem inniheldur valdakerfi. Öll gögn sem myndi venjulega vera sameinaðir til að framleiða þessi sýn er geymt í einu skjali. Og við munum tala svolítið um hvernig það virkar í nokkra töflur. 

En hugmyndin hér er að þú geymir gögn sem þessi smíða útsýni. OK? Þú mælikvarði lárétt. Ekki satt? Ef ég þarf að auka Stærð NoSQL þyrping minn, Ég þarf ekki að fá stærri kassa. Ég fæ annað box. Og ég þyrping þeim saman, og ég get Shard þessi gögn. Við munum tala svolítið um hvað sharding er, að vera fær til mælikvarði sem gagnagrunn á mörgum líkamlegt tæki og fjarlægja hindrun sem krefst mig til að skala lóðrétt. 

Svo það er í raun byggt á netinu viðskipti vinnslu og umfang. Það er stór munur hér á milli skýrslugerð, ekki satt? Skýrslur, ég veit ekki spurningar sem ég ætla að spyrja. Ekki satt? Reporting-- ef einhver frá markaðssetning deild minn vill just-- hversu margir af mínum viðskiptavinum hafa þessa tilteknu eiginleika sem keypti á þessum day-- ég veit ekki hvað fyrirspurn hann ætlar að biðja. Þannig að ég þarf að vera efahyggjumaður. 

Nú, í netinu viðskiptalegs umsókn, Ég veit hvaða spurningar ég er að spyrja. Ég byggði umsókn um mjög sérstakur workflow. OK? Þannig að ef ég hámarkað gögn geyma að styðja að workflow, það er að fara að vera hraðari. Og þess vegna NoSQL getur virkilega flýta afhendingu af þeim tegundum þjónustu. Allt í lagi. 

Þannig að við erum að fara að fá inn smá kenningu hér. Og sumir af þú, augun gæti snúið til baka smá. En ég ætla að reyna að halda því eins mikil og ég get. Svo ef þú ert í verkefni stjórnun, það er hugsmíð heitir þríhyrningur þvingun. OK. Þríhyrningur af þrengir ræður þú getur ekki hafa allt allan tímann. Get ekki baka og borða hana líka. Svo í verkefnastjórnun, sem þríhyrningur þvingun er hægt að hafa það ódýrt, þú getur haft það hratt, eða þú getur haft það gott. Pick tvö. Þar sem þú getur ekki hafa öll þrjú. Ekki satt? OK. 

Svo þú heyrir um þetta mikið. Það er þrefalt þvingun, þríhyrningur þrefaldur þvingun, eða járn þríhyrningur er oftentimes-- þegar þú talar við verkefnastjóra þeir tala um þetta. Nú hafa gagnagrunna eigin járn þríhyrningur þeirra. Og járn þríhyrningur gagna er það sem við köllum CAP setning. OK? 

CAP theorem ræður hvernig gagnagrunnar starfa undir mjög tilteknu ástandi. Og við munum tala um hvað það ástand er. En þrjú stig í þríhyrningi, svo að segja, eru C, samkvæmni. OK? Svo í CAP, samkvæmni þýðir að allir viðskiptavinir sem geta fengið aðgang að gagnagrunninum verður alltaf að hafa mjög í samræmi sýn á gögn. Ađ enginn er að sjá tvo mismunandi hluti. OK? Ef ég sé gagnagrunninn, Ég ætla að sjá sama útsýni sem félagi minn sem sér sama gagnasafn. Það er samræmi. 

Aðgengi þýðir að ef gagnagrunnur á netinu, ef það er hægt að ná, að allir viðskiptavinir munu alltaf vera fær um að lesa og skrifa. OK? Svo hvert viðskiptavinur sem getur lesið gagnagrunn verður alltaf að vera fær um að lesa gögn og skrifa gögn. Og ef það er málið, það er í boði kerfi. 

Og þriðja lið er hvað við köllum skipting umburðarlyndi. OK? Skipting umburðarlyndi leið að kerfið virkar vel þrátt líkamlegri net skipting milli hnúður. OK? Svo hnúður í klasanum geta ekki tala við hvert annað, hvað gerist? Allt í lagi. 

Svo Vensla gagnagrunna choose-- þú getur tekið tvær þeirra. OK. Svo Vensla gagnagrunna velja að vera í samræmi og í boði. Ef skipting gerist milli að DataNodes í gögn geyma, gagnagrunnurinn hrun. Ekki satt? Það fer bara niður. OK. 

Og þetta er hvers vegna þeir hafa að vaxa með stærri kassa. Ekki satt? Vegna þess að það er no-- yfirleitt, þyrping gagnagrunnur, það er ekki mjög margir af þeim sem starfa þannig. En flestir gagnagrunnar skala í lóðréttri stöðu innan einum kassa. Vegna þess að þeir þurfa að vera samræmi og í boði. Ef skipting væri á að sprauta, þá myndi þurfa að gera val. Þú þarft að gera val á milli vera í samræmi og í boði. 

Og það er það sem NoSQL gagnagrunna gera. Allt í lagi. Svo NoSQL gagnasafn, það kemur í tveimur bragði. Við have-- vel, það kemur í mörgum bragði, en það kemur með tveimur undirstöðu characteristics-- hvað við viljum kalla CP gagnagrunn eða samræmi og skipting umburðarlyndi kerfi. Þessir krakkar gera val sem þegar hnútar tapa samband við hvert annað, við erum ekki að fara að leyfa fólk að skrifa eitthvað meira. OK? 

Fram að þeim skipting er fjarlægt, skrifa aðgangur er læst. Það þýðir að þeir eru ekki í boði. Þeir eru stöðug. Þegar við sjáum að skipting sprauta sig, við erum nú í samræmi, vegna þess að við erum ekki að fara til að leyfa gögn breytingu á tveimur hliðar á þilinu óháð öðru af hvort öðru. Við verðum að endurreisa samskipti áður en uppfærslu gögn er leyfð. OK? 

Næsta bragðefni væri AP kerfi, eða í boði sem og skipt upp á umburðarlyndi kerfi. Þessir krakkar ekki sama. Ekki satt? Allir hnút sem fær skrifa, við munum taka það. Þannig að ég ætla afrit gagna minn á mörgum hnúður. Þessir hnútar fá viðskiptavinur, viðskiptavinur kemur í, segir, ég ætla að skrifa nokkur gögn. Hnútur segir, ekkert vandamál. Hnúturinn hliðina á honum fær skrifað á sömu skrá, hann er að fara að segja ekkert vandamál. Einhvers staðar aftur á bak endir, þessi gögn er að fara að endurtaka. Og þá einhver er að fara að átta sig á, uh-ó, kerfi sem þeir vilja ná, uh-ó, það er verið að uppfæra að tveimur hliðum. Hvað gerum við? Og hvað þeir gera þá er þeir gera eitthvað sem gerir þeim kleift að leysa þessi gögn ástand. Og við munum tala um að á næstu töflu. 

Hlutur að benda á hér. Og ég ætla ekki að fá of mikið inn í þetta, vegna þess að þetta fær í djúpum gögn kenningu. En það er viðskiptalegs ramma sem keyrir í Vensla kerfi sem leyfa mér að örugglega gera uppfærslur til margra aðila í gagnagrunninum. Og þeim uppfærslum gerist allt í einu eða ekki. Og þetta er kallað acid viðskipti. OK? 

ACID gefur okkur atomicity, samræmi, einangrun og endingu. OK? Það þýðir lotukerfinu, viðskipti, öll uppfærslur mínir annaðhvort gerst eða þeir gera ekki. Samræmi þýðir að Gagnagrunnurinn mun alltaf að flytja inn í samræmi Ríkið eftir uppfærslu. Ég mun aldrei yfirgefa gagnagrunninum í slæmt ástand eftir að sækja uppfærslu. OK? 

Svo það er svolítið öðruvísi en CAP samkvæmni. CAP samkvæmni þýðir allt mitt viðskiptavinir geta alltaf séð gögnin. ACID samkvæmni þýðir að þegar a viðskipti er gert, gögn er gott. Sambönd mín eru öll góð. Ég ætla ekki að eyða foreldri röð og láta fullt af munaðarlausum börnum í sumum öðrum töflunni. Það getur ekki gerst ef ég er í samræmi í súrum færslu. 

Einangrun þýðir að viðskipti mun alltaf eiga sér stað á eftir öðru. The endir afleiðing af gögnum verður sama ástand eins og ef þeim viðskiptum sem voru gefin út samtímis voru teknir af lífi í framhaldsþáttum. Svo það er concurrency stjórna í gagnagrunninum. Svo í rauninni, ég get ekki hækka að Sama gildi tvisvar með tveimur aðgerðum. 

En ef ég segi að bæta 1 til þetta gildi, og tvær færslur koma í og reyna að gera það, einn er fara að komast þangað fyrst og hinn er fara að komast þangað eftir. Svo í lok, ég bætti tveimur. Þú sérð hvað ég meina? OK. 

Ending er nokkuð augljóst. Þegar viðskipti er getið, það er fara að vera þar enn ef kerfið hrynur. Þegar það kerfi batna, sem viðskipti sem var framið er í raun að fara að vera þar. Svo er að ábyrgðum á sýru viðskiptum. Þeir eru nokkuð ágætur ábyrgðir að hafa á gagnagrunni, en þeir koma á þann kostnað. Ekki satt? 

Vegna þess að vandamálið með þetta ramma er Ef það er þil í gögnum sett, ég verð að taka ákvörðun. Ég ætla að hafa til að leyfa uppfærslur á annarri hlið eða hinni. Og ef það gerist, þá er ég ekki lengur að fara til að vera fær um að halda þessir eiginleikar. Þeir munu ekki vera í samræmi. Þeir munu ekki vera einangruð. Þetta er þar sem það brýtur niður fyrir Vensla gagnagrunna. Þetta er ástæðan Vensla gagnagrunna mælikvarða lóðrétt. 

Á hinn bóginn, höfum við hvað heitir BASE tækni. Og þetta eru NoSQL gagnagrunnum. Allt í lagi. Þannig að við höfum CP okkar, AP gagnagrunna. Og þetta eru það sem þú kallar í rauninni í boði, mjúkur ástand, loksins stöðug. OK? 

Í grundvallaratriðum boði, því þeir eru skipting umburðarlyndur. Þeir munu alltaf vera það, jafnvel ef það er net skipting milli hnúta. Ef ég get talað við hnút, ég að fara að vera fær um að lesa gögn. OK? Ég var kannski ekki alltaf fær um að skrifa gögn ef ég er í samræmi vettvang. En ég ætla að vera fær um að lesa gögn. 

The mjúkur ástandinu gefur til kynna að þegar ég las þessi gögn, það gæti ekki verið það sama og annarra hnúta. Ef rétt var gefin út á hnút annars staðar í þyrping og það hefur ekki endurtaka þvert yfir þyrping enn þegar ég las þessi gögn, sem ríkið gæti ekki verið í samræmi. Hins vegar mun það vera lokum í samræmi, sem þýðir að þegar skrifað er gerð á kerfinu, það mun endurtaka yfir hnúta. Og að lokum, að ástand verður fært í röð, og það verður í samræmi ríkisins. 

Nú, CAP setningin raunverulega spilar aðeins í einu skilyrði. Það ástand er þegar þetta gerist. Vegna þegar það er starfrækt í normal mode, það er engin skipting, allt er í samræmi og í boði. Þú áhyggjur aðeins um CAP þegar við höfum þessi skipting. Þannig að þeir eru mjög sjaldgæf. En hvernig kerfið bregst þegar þeir koma fram fyrirmæli hvaða tegund af kerfi við erum að fást við. 

Svo skulum taka a líta á það sem lítur út eins fyrir AP kerfi. OK? AP kerfi koma í tveimur bragði. Þeir koma í bragði sem er Meistari Meistari, 100%, alltaf til staðar. Og þeir koma í annað bragð, sem segir, þú veist hvað, ég er að fara að hafa áhyggjur um þetta skipting hlutur þegar raunveruleg skipting á sér stað. Annars, það er að fara að vera aðal hnúður sem er að fara að taka rétt. OK? 

Þannig að ef við eitthvað eins og Cassandra. Cassandra væri snillingur herra, við skulum mér að skrifa að allir hnút. Svo gerist það? Þannig að ég hef á hlut í gagnagrunnur sem til er á tveimur hnúður. Við skulum kalla að mótmæla S. Þannig að við höfum ástand fyrir S. Við höfum nokkrar aðgerðir á S sem eru í gangi. Cassandra leyfir mér að skrifa til margra hnúður. Svo skulum segja að ég fá skrifa fyrir s tveimur hnúður. Jæja, hvað endar gerast er við köllum það í skipting atburð. Það má ekki vera líkamlegur net skipting. En vegna þess að hönnun kerfisins, það er reyndar sneiða eins fljótt eins og ég fá að skrifa á tveimur hnúður. Það er ekki að neyða mig til að skrifa allt í gegnum einn hnút. Ég ætla að skrifa á tveimur hnúður. OK? 

Svo nú hef ég tvö ríki. OK? Hvað er að fara að gerast er fyrr eða síðar, það er að fara til vera a afritunar atburður. Það er að fara að vera það sem við kallað skipting bati, sem er þar sem þessi tvö ríki koma aftur saman og það er að fara að vera reiknirit sem keyrir inni í gagnagrunninum, ákveður hvað á að gera. OK? Sjálfgefið, Síðast uppfært vinnur í flestum AP kerfum. Svo er það yfirleitt Sjálfgefið reiknirit, það þeir kalla svarhringingu virka, eitthvað sem verður kallað þegar þetta ástand greinist að framkvæma nokkur rökfræði til að leysa það átök. OK? Sjálfgefna svarhringingu og vanræksla resolver í flestum AP gagnagrunna er, giska á hvað, timestamp vinnur. Þetta var síðasta uppfærsla. Ég ætla að setja þessi uppfærslu í það. Ég kann að afrita þessa skrá sem ég varpað burt í bata log þannig að notandi getur komið aftur seinna og segja, hey, það var árekstur. Hvað gerðist? Og þú getur raunverulega afrita skrá yfir allir árekstrar og bakfærslur og sjá hvað gerist. 

Nú, sem notandi, getur þú einnig fela rökfræði í þann svarhringingu. Svo þú getur breytt því svarhringingu aðgerð. Þú getur sagt, hey, ég vil að remediate þessi gögn. Og ég vil reyna að sameina þessar tvær færslur. En það er komið að þér. Gagnagrunnurinn veit ekki hvernig á að gera það sjálfkrafa. Flestir tími, það eina sem gagnagrunnur veit hvernig á að gera er að segja, þetta var síðasta platan. Það er eitt sem er að fara að vinna, og það er gildi sem ég ætla að setja. Þegar þessi skipting bati og fjölgun er, við höfum okkar ástand, sem er nú s Prime, sem er sameiningu stöðu allra þessara hluta. Svo AP kerfi hafa þetta. CP kerfi þurfa ekki að hafa áhyggjur af þessu. Því um leið og a skipting kemur í leik, hætta þeir bara að taka skrifar. OK? Svo er það mjög auðvelt að takast á við að vera í samræmi þegar þú samþykkir engar uppfærslur. Það er með CP kerfi gera. Allt í lagi. 

Svo skulum við tala svolítið hluti um aðgang mynstrum. Þegar við tölum um NoSQL, það er allt um aðgang mynstur. Nú, SQL er tilfallandi, fyrirspurnir. Það er Vensla verslun. Við þurfum ekki að hafa áhyggjur um aðgang mynstur. Ég skrifa mjög flókið fyrirspurn. Það fer og fær gögnin. Það er það sem þetta lítur eins eðlileg. 

Þannig að í þessu tiltekna uppbyggingu, við erum að horfa á vörur verslun. Ég hef mismunandi tegundir af vörum. Ég hef bækur. Ég hef plötur. Ég hef myndbönd. Sambandið á milli vara og einhver af þessum bókum, albúm, og myndbönd töflur er 1: 1. Allt í lagi? Ég hef fengið Vörunúmer, og finnst þetta samsvarar við bók, plötu, eða myndskeið. OK? Það er 1: 1 samband yfir þeim töflum. 

Nú books-- allir þeir hafa er rót eignir. Ekkert mál. Það er frábært. Einn-á-einn samband, fá ég allt gögn sem ég þarf að lýsa þá bók. Albums-- plötur hafa lög. Þetta er það sem við köllum einu að mörgum. Sérhver plata gæti hafa mörg lög. Svo fyrir hvert lag á platan, gæti ég annað met í þessum barna töflu. Svo ég búa til eina færslu í albúm mitt borð. Ég búið til margar færslur í lögin töflunni. Einn-á-marga tengsl. 

Þetta samband er það við köllum margir-til-margir. OK? Þú sérð að aðilar gætu verið í mörgum kvikmyndum, mörgum myndböndum. Svo það sem við gerum er að við setja þetta kortlagning borð á milli þeirra, sem það bara kortin leikari ID til the vídeó ID. Nú get ég búið fyrirspurn á tengir myndbönd í gegnum leikarann ​​vídeó til leikara, og það gefur mér ágætur listi af allar kvikmyndir og alla leikarar sem voru í þeirri mynd. 

OK. Svo hér við fara. Einn-á-mann er efsta sambandið; einn-til-margir, plöturnar lögin; margir til margra. Þeir eru þrír efstu sambönd í öllum gagnagrunninum. Ef þú veist hvernig þeir sambönd vinna saman, þá þú veist mikið um gagnagrunn þegar. Svo NoSQL virkar svolítið öðruvísi. Við skulum hugsa um fyrir annað það það Útlit eins og að fara að fá allar vörur mínar. 

Á samræmdum verslun, ég langar að fá allar vörur mínar á lista yfir allar vörur mínar. Það er mikið af fyrirspurnum. Ég fékk fyrirspurn fyrir allar bækurnar mínar. Ég fékk fyrirspurn frá albúmum mínum. Og ég fékk fyrirspurn fyrir allar hreyfimyndir mínum. Og ég fékk að setja það allt saman á lista og þjóna því aftur upp til forrit sem er að biðja hana. 

Til að fá bækurnar mínar, taka þátt I Vörur og bækur. Til að fá plötur mínar, fékk ég að taka þátt Vörur, Albums, og lög. Og til að fá minn vídeó, ég hef til að taka þátt vörur til myndbönd, ganga í gegnum leikari myndbönd, og koma í Actors. Svo er það þrjár fyrirspurnir. Mjög flókin fyrirspurnir til saman einn vegna sett. 

Það er minna en ákjósanlegur. Þetta er ástæðan þegar við tölum um gögn uppbygging sem er byggt til að vera efahyggjumaður til aðgang pattern-- vel sem er frábært. Og þú getur séð þetta er í raun gott hvernig við höfum skipulagt gögnin. Og þú veist hvað? Ég hef bara eina met leikari. 

Það er flott. Ég hef deduplicated öll leikarar mín, og ég haldið samtök mín í slíkri kortlagningu töflu. Hins vegar að fá gögnin út verður dýr. Ég ætla að senda CPU allan kerfinu tengja þessar gögn uppbygging saman að vera fær um að draga að gögn aftur. 

Svo hvernig fæ ég í kringum það? Í NoSQL það er um samansafn, ekki eðlileg. Þannig að við viljum segja að við viljum styðja aðgang mynstur. Ef aðgang mynstur til forrit, Ég þarf að fá allar vörur mínar. Við skulum setja allar vörur í einu borði. Ef ég setti allar vörur í einu borði, Ég get bara valið allar vörur frá þeirri töflu og ég fæ það allt. Jæja hvernig geri ég það? Jæja í NoSQL það er engin uppbyggingu að borðinu. Við munum tala svolítið um hvernig þetta virkar í Dynamo DB. En þú ert ekki með sama eiginleika og sömu eiginleika í hvert einasta röð, í hverjum einasta atriði, eins og þú gerir í SQL töflunni. Og hvað þetta gerir mér að gera er að margt og gefa mér mikið af sveigjanleika. Í þessu tiltekna tilviki, ég hafa vöru skjöl mín. Og í þessu tiltekna dæmi, allt er skjal í Products töflunni. Og vara fyrir bók gæti hafa auðkennisgerð sem skilgreinir bók. Og umsókn myndi skipta á þeim ID. 

Á notkunarstað flokkaupplýsingar, ég ætla að segja ó, hvað met tegund er þetta? Oh, það er bók met. Bók færslur hafa þessa eiginleika. Leyfðu mér að búa til bók mótmæla. Þannig að ég ætla að fylla bók mótmæla með þessu verki. Næsta atriði kemur og segir, hvað er þetta atriði? Jæja þetta atriði er plata. Oh, ég fékk allt annað vinnslu venja fyrir það, vegna þess að það er plata. Þú sérð hvað ég meina? 

Svo forritið tier-- I bara velja allar þessar færslur. Þeir allir byrja að koma í. Þeir gætu verið allt mismunandi gerðir. Og það er rökfræði forritsins sem skiptir yfir þær tegundir og ákveður hvernig á að vinna úr þeim. 

Aftur, þannig að við erum að hagræða í stefið fyrir aðgang mynstur. Við erum að gera það með því að hrynja þeim töflum. Við erum í rauninni að taka þessi eðlileg mannvirki, og við erum að byggja Innbyrðis mannvirki. Inni hvert og eitt þessara gagna Ég ætla að sjá array eiginleika. 

Inni þessu skjali fyrir albúm, Ég ætla að sjá fylki af lögum. Þeir slóðir become-- nú er það grundvallaratriðum þetta barn borð sem er til hérna í þessari uppbyggingu. Svo er hægt að gera þetta í DynamoDB. Þú getur gert þetta í MongoDB. Þú getur gert þetta í hvaða NoSQL gagnagrunninum. Búa til þessar tegundir af Innbyrðis gögn uppbygging að leyfa þér að sækja gögn mjög fljótt því nú er ég þurfa ekki að vera í samræmi. Þegar ég setja röð í lögin borð, eða röð í Albums borð, Ég verð að vera í samræmi við þá stefið. Ég verð að hafa eigindi eða á eign sem er skilgreint á þeirri töflu. Hver og einn þeirra, þegar ég setja röðinni. Það er ekki raunin í NoSQL. 

Ég get haft allt öðruvísi eignir í hvert skjal sem ég setja í safn. Svo mjög öflugt kerfi. Og það er í raun hvernig þú hagræða í kerfinu. Vegna þess að nú þeirri fyrirspurn, í stað um að taka þátt alla þessar töflur og framkvæmd a hálfa tylft fyrirspurnir að draga til baka gögn sem ég þarf, Ég er að keyra eitt fyrirspurn. Og ég er iterating yfir niðurstöður settar. það gefur þér hugmynd af krafti NoSQL. Ég ætla að eins konar fara til hliðar hér og tala svolítið um þetta. Þetta er meira svona að markaðssetningu eða technology-- markaðssetningu tækni tegund af umræðu. En það er mikilvægt að skilja því ef við líta á the toppur hér á þessari töflu, það sem við erum að horfa á er það sem við köllum tækni efla bugða. Og hvað þýðir þetta er nýtt efni kemur inn í leik. Fólk heldur að það er frábært. Ég hef leyst öll vandamál mín. 

Þetta gæti verið í lok allt, vera allt að öllu. Og þeir byrja að nota það. Og þeir segja, þetta dót virkar ekki. Þetta er ekki rétt. Gamla efni var betri. Og þeir fara aftur til að gera hlutina eins og þeir voru. Og þá loksins þeir fara, þú veist hvað? Þetta efni er ekki svo slæmt. Oh, það er hvernig það virkar. Og þegar þeir reikna út hvernig það verk, þeir byrja að fá betra. 

Og fyndna um það er það eins konar línur upp á það við köllum Technology Ættleiðing Bugða. Svo er það sem gerist við höfum einhvers konar tækni gikkur. Þegar um er að ræða gagnagrunna, það er gögn þrýstingur. Við töluðum um hátt stig vatn gagna þrýstingi allan tíma. Þegar þessi gögn þrýstingur hits ákveðin lið, það er tækni gikkur. 

Það er að fá of dýrt. Það tekur of langan tíma að vinna úr gögnum. Við þurfum eitthvað betra. Þú færð frumkvöðla þarna hlaupandi um, að reyna að finna út hvað er lausnin. Hvað er nýtt hugmynd? 

Hvað er næsta besti Leiðin til að gera þetta? Og þeir koma upp með eitthvað. Og fólk með alvöru sársauka, krakkar á fjandans brún, þeir stökkva um allt það, vegna þess að þeir þurfa að svara. Nú hvað óhjákvæmilega happens-- og það er að gerast núna í NoSQL. Ég sé það allan tímann. 

Hvað óhjákvæmilega gerist er fólk byrja að nota nýja tól á sama hátt og þeir nota gamla tól. Og þeir finna út það virkar ekki svo vel. Ég man ekki hver ég var að tala við fyrr í dag. En það er eins og þegar jackhammer var fundið upp, fólk ekki sveifla henni yfir höfuð þeirra til að mölva steypu. 

En það er það sem er gerast með NoSQL dag. Ef þú gengur í flestum verslunum, þeir eru að reyna að vera NoSQL verslanir. Hvað þeir eru að gera er þeir eru að nota NoSQL, og þeir eru að hlaða það fullt af Vensla stefið. Því það er hvernig þeir hanna gagnagrunna. Og þeir eru að spá, af hverju er ekki gengur vel? Boy, þetta stinks. Ég þurfti að halda öllum mínum tengir in-- það er, nei, nei. Halda tengir? Hvers vegna ert þú að ganga gögnum? Þú ganga ekki gögn í NoSQL. Þú samanlagður það. 

Svo ef þú vilt að forðast þetta, læra hvernig tól virkar áður en þú raunverulega byrja að nota það. Ekki reyna að nota ný tæki sem sama hátt og þú notaðir gamla verkfæri. Þú ert að fara að hafa slæma reynslu. Og í hvert einasta skipti það er það sem þetta snýst um. Þegar við byrjum að koma upp hér, það er vegna þess að fólk mynstrağur út hvernig á að nota verkfæri. 

Þeir gerðu það sama þegar Vensla gagnagrunna voru fundin, og þeir voru að skipta kerfi skrá. Þeir reyndu að byggja kerfi skrá með Vensla gagnagrunna því það er það fólk skilið. Það virkaði ekki. Svo skilja bestu starfsvenjur af tækni sem þú ert að vinna með er mikil. Mjög mikilvægt. 

Þannig að við erum að fara að fá inn DynamoDB. DynamoDB er AWS er fullkomlega tekist NoSQL vettvang. Hvað gerir fullkomlega tekist meina? Það þýðir að þú þarft ekki að virkilega hafa áhyggjur af neinu. 

Þú kemur í, þú segir okkur, ég þarf borð. Það þarf svona mikla getu. Þú högg the hnappur og við ákvæði allt innviði bak við the vettvangur. Nú er þessi gríðarlegur. 

Vegna þess að þegar þú talar um stigstærð gagnagrunn, NoSQL gögn klösum á mælikvarða, gangi petabytes, gangi milljónir viðskipti á sekúndu, þetta eru ekki lítil þyrping. Við erum að tala þúsundir tilvikum. Annast þúsundir tilfella, jafnvel raunverulegur tilvikum, er a raunverulegur sársauki í rassinn. Ég meina, hugsa um í hvert sinn sem stýrikerfi plástur kemur út eða ný útgáfa af gagnagrunninum. Hvað þýðir það þér rekstrarlega? Það þýðir að þú got 1.200 netþjónum sem þarf að vera uppfærð. Nú jafnvel með sjálfvirkni, sem getur tekið langan tíma. Það getur valdið miklum rekstrar höfuðverk, vegna þess að ég gæti hafa þjónustu niður. 

Eins og ég uppfæra þessa gagnagrunna, ég gæti gert Blue Green dreifing þar sem ég senda á vettvang og uppfærsla helmingur minn hnúður, og síðan uppfæra hinn helminginn. Taktu þá niður. Svo stjórna innviði mælikvarði er gríðarlega sársaukafullt. Og AWS taka þessi sársauka út af því. Og NoSQL gagnagrunna getur verið ótrúlega sársaukafullt vegna þess hvernig þeir mælikvarða. 

Scale lárétt. Ef þú vilt til að fá stærri NoSQL gagnagrunnur, þú kaupir fleiri hnútar. Hver hnútur sem þú kaupir er annar rekstur höfuðverkur. Svo láta einhvern annan gera það fyrir þig. AWS getur gert það. 

Við styðjum skjal helstu gildi. Nú erum við ekki að fara of mikið í hinum töfluna. There 'a einhver fjöldi af mismunandi keim af NoSQL. Þeir eru alls konar fá munged saman á þessum tímapunkti. Þú getur litið á DynamoDB og segja já, við erum bæði skjal og lykill gildi geyma þetta atriði. Og þú getur rökrætt aðgerðir af einn yfir annan. Til mín, mikið af þessu er í raun sex einn helmingur a tylft af öðrum. Hver og einn af þessum tækni er fínn tækni og fínn lausn. Ég myndi ekki segja MongoDB er betri eða verra en sófanum, þá Cassandra, þá Dynamo, eða öfugt. Ég meina, þetta eru bara möguleikar. 

Það er fljótur og það er samræmi við hvaða mælikvarða. Svo er þetta eitt af stærstu bónus sem þú færð með AWS. Með DynamoDB er hæfni að fá lágt einn tölustafur millísekúnda leynd á hvaða mælikvarða. Það var hönnun markmið kerfisins. Og við höfum viðskiptavini sem eru að gera milljónir færslna á sekúndu. 

Nú ég fara í gegnum sumir af þeim nota tilvikum í nokkrar mínútur hér. Innbyggt aðgang control-- við höfum það sem við köllum Identity Access Management, eða IAM. Það síast hvert kerfi, alla þjónustu sem AWS býður. DynamoDB er engin undantekning. Þú getur stjórnað aðgangi til DynamoDB borðum. Yfir allt AWS reikningana með skilgreina hlutverk aðgang og heimildir í Iam innviði. 

Og það er lykillinn og óaðskiljanlegur hluti í það sem við köllum atburður ekið Forritun. Nú er þetta nýja hugmyndafræði. 

Áhorfendur: Hvernig er hlutfall af satt Jákvæður móti falskur neikvæður á aðgang eftirlitskerfi þinn? RICK Houlihan: True jákvæður móti falskur neikvæður? Áhorfendur: Reglulegur hvað þú ættir að vera að koma aftur? Öfugt við einu sinni í a á meðan það ekki aftur þegar það ætti að staðfesta? 

RICK Houlihan: Ég gat ekki sagt þér það. Ef það er einhver bilun hvað á að Ég er ekki manneskja til að spyrja sem einkum spurning. En það er góð spurning. Ég væri forvitinn að vita það sjálfur, í raun. 

Og svo þá aftur, nýja hugmyndafræði er atburður ekið forritun. Þetta er hugmynd sem þú getur senda flókin forrit sem geta starfað mjög, mjög hár mælikvarða án innviði neinu tagi. Án fastra innviði alls. Og við munum tala svolítið um hvað það þýðir eins og við fá á næstu töflur. 

The fyrstur hlutur sem við munum gera er að við munum tala um borðum. API gagnatög fyrir Dynamo. Og það fyrsta sem þú munt taka eftir þegar þú horfir á þetta, ef þú ert kunnuglegur með öllum gagnagrunninum, gagnasöfn hafa raunverulega tvennskonar API Ég myndi kalla það. Eða tvö sett af API. Einn af þeim væri stjórnsýslu API. 

Það sem þeir gæta störf gagnagrunninum. Stilla geymsla vél, setja upp og bæta töflur. búa gagnasafn bæklingum og dæmi. Þetta things-- í DynamoDB, þú hafa mjög stutta, stutta listum. 

Svo í öðrum gagnagrunnum, þú gætir séð heilmikið af skipunum, af stjórn skipanir, til að stilla þessi viðbótar valkostur. Í DynamoDB þú þarft ekki þá vegna þess að þú stilla ekki kerfið, gera við. Svo það eina sem þú þarft að gera er að segðu mér hvað stærð borð þarf ég. Þannig að þú færð mjög takmarkað sett af skipunum. 

Þú færð Búa Table Update, Table, Eyða töflu, og lýsa töflu. Þeir eru einungis hluti þú þarft að DynamoDB. Þú þarft ekki geymslu vél stillingar. Ég þarf ekki að hafa áhyggjur af afritunar. Ég þarf ekki að hafa áhyggjur af sharding. 

Ég þarf ekki að hafa áhyggjur um eitthvað af þessu efni. Við gerum það fyrir þig. Svo það er a gríðarstór magn af kostnaður það er bara lyft af diskinn þinn. Þá höfum við crud rekstraraðila. CRUD er eitthvað sem við kalla hjá sem er Búa til, uppfæra Eyða rekstraraðila. Þetta eru algeng þitt gagnasafn aðgerðir. Hluti eins og sölurétti lið, fá atriði, uppfæra atriði, eyða hlutum, hópur fyrirspurn, skanna. Ef þú vilt að skanna allt borðið. Draga allt út af borðinu. Einn af the ágætur hluti um DynamoDB er það gerir samhliða skönnun. Svo þú getur raunverulega að láta mig vita hversu margir þræðir þú vilt keyra á þeim grannskoða. Og við getum keyrt þá þræði. Við getum snúast að skanna allt á mörgum þráðum svo þú getur skanna allt borðið rúm mjög, mjög fljótt í DynamoDB. 

Hin API sem við höfum er það sem við köllum Straumar API okkar. Við erum ekki að fara að tala of mikið um þetta núna. Ég hef fengið nokkrar efni síðar á í þilfari um þetta. En Straumar er í raun running-- hugsa um það sem tíminn bauð og skipting Change Log. Allt sem er að gerast á sýnir taflan upp á straumi. 

Sérhver skrifa að borðinu sýnir sig á straumi. Þú getur lesið það á, og þú getur gert hluti með það. Við munum tala um það tegundir af hlutum sem þú gera með það eins og afritunar, búa efri stuðla. Alls konar virkilega flott hlutir sem þú getur gert við það. 

Gagnatög. Í DynamoDB, styðja við bæði lykil gildi og skjal gagnatög. Á vinstri hönd hlið af the skjár hér höfum við fengið helstu tegundir okkar. Helstu gerðir gildi. Þetta eru strengir, tölur og tvöfaldur. 

Svo bara þrjú helstu tegundir. Og þá er hægt að hafa sett af þeim. Einn af the ágætur hluti um NoSQL er þú getur innihaldið fylki sem eignir. Og með DynamoDB þú getur innihaldið fylki af helstu tegundir sem rót eign. 

Og þá er það skjalið tegundir. Hversu margir eru kunnugir JSON? Þið kannast við JSON svo mikið? Það er í grundvallaratriðum JavaScript, Object, Ritháttur. Það gerir þér kleift að í grundvallaratriðum skilgreina valdakerfi. 

Þú getur geymt JSON skjal á DynamoDB nota algeng hluti eða byggja blokkir sem eru í boði í flestum forritunarmál. Svo ef þú ert með Java, þú ert horfa á kort og listum. Ég get búið til hluti sem svæði kort. A Kort sem helstu gildi geymt sem eignir. Og það gæti hafa lista yfir gildi innan þessara eiginleika. Þú getur geymt þetta flókið valdakerfi sem einn eiginleiki af DynamoDB hlut. 

Svo borðum í DynamoDB, eins og flest NoSQL gagnagrunna, hafa töflur atriði. Í MongoDB þú myndir kalla þessi skjöl. Og það væri í sófanum stöð. Einnig skjal gagnasafn. Þér kallið þessi skjöl. Skjöl eða hlutir hafa eiginleika. Eiginleiki getur til eða ekki til á hlutnum. Í DynamoDB, það er einn nauðsynlegur eiginleiki. Rétt eins og í Venslagagnagrunnur, þú hafa grunn takka á borðinu. 

DynamoDB hefur það sem við köllum kjötkássa takkann. Hash lykillinn verður að vera einstakt. Svo þegar ég skilgreina kjötkássa borð, grundvallaratriðum það sem ég er að segja er hvert atriði mun hafa kjötkássa takkann. Og sérhver kjötkássa lykill verður að vera einstakt. 

Hvert atriði er skilgreint af því einstaka kjötkássa lykill. Og það getur aðeins verið einn. Þetta er í lagi, en oftsinnis það sem fólk þarf er þeir vilja er þetta kjötkássa takkann til að gera smá meira en bara vera einstakt auðkenni. Oftsinnis við viljum nota þessi kjötkássa lykill sem efst stigi samansafn fötu. Og hvernig við gera sem er með bæta það sem við köllum ýmsum lykil. 

Þannig að ef það er kjötkássa aðeins borð, þetta verður að vera einstakt. Ef það er kjötkássa og svið borð, Samsetningin af tæti og á bilinu verður að vera einstakt. Svo hugsa um það með þessum hætti. Ef ég er með umræðum. Og formið hefur efni, það hefur innlegg, og það hefur svör. 

Svo ég gæti hafa kjötkássa lykill, sem er rakin ID. Og ég gæti hafa svið lykill, sem er að bregðast ID. Þannig ef ég vil fá allar Svörun tilteknu efni, Ég get bara fyrirspurn kjötkássa. Ég get bara sagt að gefa mér allt atriði sem hafa þetta kjötkássa. Og ég ætla að fá öllum spurningum eða senda fyrir viðkomandi efni. Þessar efstu stigi útfellingarnar eru mjög mikilvæg. Þeir styðja aðal aðgang Mynstur af forritinu. Almennt talað, þetta er það sem við viljum gera. Við viljum að table-- og þú hleður borð, við viljum að skipuleggja gögnin í töflunni á þann hátt að forritið getur mjög fljótt sækja þær niðurstöður. Og oftsinnis leiðin til að gera það er að viðhalda þessum heildarniðurstöðum sem vér setja gögnin. Í grundvallaratriðum erum við að dreifa gögnum í björtu fötu eins og það kemur í. 

Hóflegt lyklar leyfa me-- kjötkássa Lyklar að vera jafnrétti. Þegar ég fyrirspurn kjötkássa, ég verð að segja gefa mér kjötkássa sem jafngildir þetta. Þegar ég fyrirspurn svið, ég getur sagt gefa mér mikinn sem er að nota hvers konar ríkur rekstraraðili sem við styðjum. Gefðu mér alla atriði fyrir kjötkássa. Er það jafn, stærra en, minna en, það að byrja með, er það til á milli þessara tveggja gilda? Svo þessar tegundir af svið fyrirspurnir að við erum alltaf áhuga á. Nú eitt um gögn, þegar þú horfir á aðgang að gögnum, þegar þú aðgang að gögnum, það er alltaf um að samloðun. Það er alltaf um færslur sem eru tengdar þessu. Gefðu mér allt hér that's-- allt viðskiptin skráðir greiðslukorti í síðasta mánuði. Það er samansafn. 

Næstum allt sem þú gerir í Gagnagrunnurinn er einhvers konar samansafn. Svo að vera fær um að vera fær um að skilgreina þessir fötunum og gefa þér þessar svið eiginleika til að vera fær um að fyrirspurn á, þessir ríkur fyrirspurnir styðja margir, margir, margir umsókn aðgang mynstur. 

Svo annar hlutur kjötkássa lykill gerir er að það gefur okkur kerfi að vera fær um að dreifa gögnunum kring. NoSQL gagnagrunna virka best þegar gögnum er jafnt dreift yfir þyrping. Hversu margir eru kunnugir með hass reiknirit? Þegar ég segi kjötkássa og hashing-- vegna hökkunarkerfis reiknirit er leið til að vera fær um að búa til a handahófi gildi frá hverjum gildi. Þannig að í þessu tiltekna tilviki, kjötkássa reiknirit hlaupum er ND 5 byggist. 

Og ef ég hef kenni, og þetta er kjötkássa lykillinn minn, ég hef 1, 2, 3. Þegar ég keyra kjötkássa reiknirit, það er að fara að koma aftur og segja, vel 1 er 7B, 2 jafngildir 48, 3 er CD. Þeir eru dreift um allt lykill rúm. Og af hverju ertu að gera þetta? Vegna þess að það gerir viss um að ég get setja færslur á mörgum hnúður. 

Ef ég er að gera þetta smám saman eftir þörfum, 1, 2, 3. Og ég er með kjötkássa svið sem keyrir í þessu tiltekna tilfelli, lítið kjötkássa pláss, það liggur frá 00 til FF, þá færslur eru að fara að koma í og hann ætlar að fara 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. Hvað gerist? Sérhver innskotið er að fara á sama hnút. Þú sérð hvað ég meina? 

Vegna þess að þegar ég skipt rými, Ég breiddi þessar skrár yfir, og ég skipting, ég ætla að segja skipting 1 hefur lykil pláss 0 til 54. Skipting 2 er 55 til 89. Skipting 3 er AA til FF. Svo ef ég er að nota línulega incrementing Auðkenni, getur þú séð hvað er að gerast. 1, 2, 3, 4, 5, 6, alla leið í allt að 54. Svo eins og ég hamar færslur inn í kerfið, allt endar að fara að einum hnút. 

Það er ekki gott. Það er óákveðinn greinir í ensku antipattern. Í MongoDB þeir hafa þetta vandamál ef þú notar ekki kjötkássa takkann. MongoDB gefur þér kost af hass takkann gildi. Þú ættir alltaf að gera það, ef þú ert að nota incrementing kjötkássa Lykillinn í MongoDB, eða þú munt vera negla alla skrifa á einum hnút, og þú verður að takmarka skrifa afköst þín illa. 

Áhorfendur: Er það A9 169 í aukastaf? 

RICK Houlihan: Já, það er einhvers staðar í kringum það. A9, ég veit ekki. Þú vilt verða að fá tvöfaldur minn að aukastaf reiknivél. Heilinn minn virkar ekki eins og þessi. Áhorfendur: Just a fljótur einn af Mongo athugasemdum þínum. Svo er að mótmæla auðkenni sem kemur innfæddur með Mongo gera það? RICK Houlihan: Er það að gera það? Ef þú tilgreinir það. Með MongoDB, hefur þú möguleika á. Þú getur specify-- hvert skjal í MongoDB hefur að hafa undirstrika ID. Það er einstakt gildi. 

Í MongoDB þú getur tilgreint hvort að kjötkássa það eða ekki. Þeir gefa bara þér möguleika. Ef þú veist að það er handahófi, ekkert vandamál. Þú þarft ekki að gera það. Ef þú veist að það er ekki af handahófi, sem það er incrementing, þá gera kjötkássa. 

Nú hlutur óður hass, þegar þú kjötkássa a value-- og þetta er hvers vegna kjötkássa takkarnir eru alltaf einstakar fyrirspurnir, vegna þess að ég hef breytt gildi, nú get ég ekki gert upp á úrval fyrirspurn. Ég get ekki sagt að þetta milli þessa eða að vegna þess að kjötkássa gildi er ekki að fara jafngilda verðgildi. Svo þegar þú kjötkássa sem lykill, er það jafnrétti aðeins. Þetta er ástæðan fyrir í DynamoDB kjötkássa lykill fyrirspurnir eru alltaf jafnrétti aðeins. 

Svo nú í ýmsum key-- þegar ég bæta við að svið takkann, þessir svið helstu færslur koma inn og þeir fá geymd á sama skipting. Svo þeir eru mjög fljótt, auðveldlega sótt vegna þess að þetta er kjötkássa, þetta er svið. Og þú sérð allt með sama kjötkássa fær geymd á sama skipting pláss. Þú getur notað þessi svið takkann til að hjálpa finndu gögn nálægt foreldri sínu. Svo hvað er ég að gera í raun hér? Þetta er einn til margra samband. Sambandið milli kjötkássa lykill og svið lykillinn er að margir. Ég get verið með marga lykla kjötkássa. Ég get bara haft mörg svið lyklar innan alls kjötkássa takka. 

Kjötkássa skilgreinir foreldri, svið skilgreinir börn. Svo er hægt að sjá er það flaumi hér milli Vensla reisa og sömu tegundir býr í NoSQL. Fólk talar um NoSQL sem nonrelational. Það er ekki nonrelational. Gögn er ætíð tengdur. Þeim samböndum bara eru byggð á annan hátt. Við skulum tala svolítið hluti um endingu. Þegar þú skrifar að DynamoDB, skrifar eru alltaf þrír-vegur endurtaka. Sem þýðir að við höfum þrjá AZ er. AZ er eru framboð svæði. Þú getur hugsað um Framboð Zone sem gagna eða safn af miðstöðvum gögn. Þetta eru landfræðilega einangraðar hver um sig yfir mismunandi svæðum kenna, yfir mismunandi máttur grids og flæðiengjar. A bilun í einni AZ er ekki að fara að taka niður annan. Þeir eru einnig tengd ásamt ljósleiðari. Það styður einn undir 1 millísekúnda leynd milli AZS. Svo rauntíma gögn replications fær í multi AZS. 

Og oftsinnis multi AZ dreifing uppfylla hár framboð kröfur af flestum framtak stofnana. Svo DynamoDB er dreift í þremur AZS sjálfgefið. Við erum bara að fara að þekkingu skrifa þegar tveir af þeim þremur hnúður koma aftur og segja, já, ég fékk það. Afhverju er það? Þar á lesa hlið við erum aðeins að fara að gefa þér gögn til baka þegar við fáum það úr tveimur hnúður. 

Ef ég er afrit yfir þrír, og ég er að lesa úr tveimur, Ég er alltaf tryggt að hafa að minnsta kosti einn af þeim sem les til að vera nýjustu afrit af gögnum. Það er það sem gerir DynamoDB stöðug. Nú getur þú valið um að snúa þá sem í samræmi les burt. Í því tilviki er ég að fara að segja, Ég bara las úr einum hnút. Og ég get ekki ábyrgst það er að fara að vera sem mest núverandi gögn. 

Svo ef skrifa er að koma í, það hefur ekki endurtaka enn, þú ert að fara að fá að afrita. Það er að lokum í samræmi lesa. Og hvað það er sem er helmingur kostnaðar. Svo er þetta eitthvað til að hugsa um. Þegar þú ert að lesa út DynamoDB og þú ert að setja upp lesa getu þína einingar, ef þú velur að lokum samræmi les, það er mikið ódýrara, það er um helmingur kostnaðar. 

Og svo sparar það þér pening. En það er val þitt. Ef þú vilt samræmi lesa eða sem að lokum í samræmi lesa. Það er eitthvað sem þú getur valið. 

Við skulum tala um stuðla. Þannig að við nefna að efsta þrepi samansafn. Við höfum fengið kjötkássa lykla, og við höfum fengið svið lykla. Það er gott. Og það er á aðal borðið, ég fékk einn kjötkássa lykill, ég fékk einn svið takkann. 

Hvað þýðir það? Ég hef fengið eina eigind sem ég getur keyrt ríkur fyrirspurnir gegn. Það er á bilinu lykillinn. Önnur eigindi á þeim item-- Ég get sía á þeim eiginleika. En ég get ekki gert hlutina eins, það hefst með, eða er meiri en. 

Hvernig geri ég það? Ég að búa til yfirlit. Það er tvær tegundir af Vísitölur í DynamoDB. Vísitala er mjög Önnur mynd af borðinu. Og sveitarfélaga efri vísitölu. 

Sú fyrsta sem við munum tala um. Svo staðbundin secondaries eru coexisted á sama skipting og gögn. Og eins og svo, eru þeir á sama líkamlega hnút. Þeir eru það sem við köllum í samræmi. Merkingu, þeir vilja viðurkenna sem skrifa með töflunni. Þegar skrifa kemur í, við munum skrifa í gegnum vísitölu. Við munum skrifa upp að borðinu, og þá munum við að viðurkenna. Svo er það í samræmi. Þegar skrifa hefur verið viðurkenndi frá borðinu, það tryggt að sveitarfélaga efri vísitölu mun hafa sömu sýn á gögn. En það sem þeir leyfa þér að gera er skilgreina varamaður svið lykla. 

Verð að nota sama kjötkássa lykill sem aðal borðið, vegna þess að þeir eru sam-staðsettir á Sama skipting, og þeir eru í samræmi. En ég get búið til yfirlit með mismunandi lykla svið. Svo til dæmis, ef ég hefði framleiðanda sem hafði hrár hlutar borð koma inn. Og hrár hlutar koma í, og þeir eru lagðar saman af þinginu. Og kannski er það muna. 

Allir hlutar, sem var gerð af þessu Framleiðanda eftir þessa dagsetningu, Ég þarf að draga úr minn línu. Ég get snúast vísitölu sem væri að leita, samtals á þeim degi Framleiðsla á viðkomandi hluta. Svo ef efsta þrep mitt borð var þegar tætt eftir framleiðanda, kannski var það komið á hluta ID, ég getur búið til yfirlit burt borðið eins tætt eftir framleiðanda og bilinu á framleiðsludegi. Og þannig að ég gæti sagt, nokkuð sem var framleidd milli þessar dagsetningar, Ég þarf að draga úr línu. Svo er það staðbundin efri vísitölu. 

Þessir hafa þau áhrif að takmarka kjötkássa lykill rúm. Vegna þess að þeir sam-verið á sama geymslu hnút, þeir takmarka kjötkássa lykill rúm 10 gígabæta. DynamoDB, undir töflur, mun skipting taflan á 10 gígabæta. Þegar þú setur 10 gigs af gögnum í, við fara [PHH], og við bætum við öðrum hnút. 

Við munum ekki skipta LSI á mörgum skipting. Við munum skipta töflunni. En við munum ekki skipta LSI. Svo það er eitthvað mikilvægt að skilja er ef þú ert að gera mjög, mjög, mjög stór útfellingarnar, þá þú ert að fara að vera takmörkuð 10 gígabæta á LSIs þinn. 

Ef það er málið, við getum nota alþjóðlegum secondaries. Altækir secondaries eru virkilega annað borð. Þeir eru alveg af að hlið aðal töflunni. Og þeir leyfa mér að finna allt öðruvísi uppbyggingu. Svo hugsa um það sem verið er að sett í tvo mismunandi töflur, skipulögð á tvo mismunandi vegu. 

Ég get skilgreina algerlega öðruvísi kjötkássa lykill. Ég get skilgreina algerlega mismunandi svið lykill. Og ég get keyrt þetta alveg sjálfstætt. Eins spurning um staðreynd, ég hef skilyrtri lesa getu mína og skrifa getu til mín Alþjóðlegar efri Vísitölur alveg óháð aðal mitt borð. Ef ég skilgreina þá vísitölu, segi ég það hversu mikið lesa og skrifa getu það er að fara að vera með. 

Og það er aðskilið frá aðal mitt borð. Nú bæði af Vísitölur leyfa okkur að ekki aðeins skilgreina kjötkássa og svið lykla, en þeir leyfa okkur að verkefnið fleiri gildi. Svo ef ég vil lesa af vísitölu, og ég vil fá sett af gögnum, Ég þarf ekki að fara aftur til the aðalæð borð til að fá frekari eiginleika. Ég get verkefni þeirra viðbótar eiginleika í töflunni til að styðja við aðgang mynstur. Ég veit að við erum líklega að fá inn í sumir virkilega, really-- hafa komist illgresi hér á sumir af þessum hlutum. Nú fékk ég að reka út úr þessu. 

Áhorfendur: [inaudible] --table lykillinn ætlað var kjötkássa? Upprunalega kjötkássa? Multi-slats? 

RICK Houlihan: Já. Já. Grundvallaratriðum borðið lykillinn bendir aftur til lið. Svo er vísitala bendi aftur til sjálfgefnir hlutir á borðinu. Nú getur þú valið um að byggja upp Vísitala sem aðeins hefur töflunni takkann, og engin önnur eignir. Og hvers vegna gæti ég það? Jæja, kannski hef ég mjög stór atriði. 

Ég virkilega þarf aðeins að vita which-- Aðgangur mynstur minn gæti sagt, hvaða atriði innihalda þessa eign? Ekki þarf að skila hlut. Ég þarf bara að vita hvaða atriði innihalda það. Svo er hægt að byggja Vísitölur sem aðeins hafa borð takkann. 

En það er fyrst og fremst það vísitala hjá er fyrir. Það er fyrir að vera fær til fljótt þekkja sem skráir, hvaða raðir, sem atriði í töflunni hafa eiginleikar sem ég er að leita að. 

GSIs, svo hvernig virka þau? GSIs eru í grundvallaratriðum ósamstilltur. Uppfærslan kemur í töflunni, Taflan er þá asynchronously uppfærð öll GSIs þinn. Þetta er ástæðan fyrir GSIs eru lokum í samræmi. 

Það er mikilvægt að hafa í huga að þegar þú ert að byggja GSIs, og þú skilja að þú ert að búa annar þáttur aggregation-- nú skulum segja gott dæmi hér er framleiðandi. Ég held að ég gæti verið að tala um lækningatæki framleiðanda. Medical tæki framleiðandi oftsinnis hafa serialized hluta. Þeim hlutum sem fara í a hip skipti öllu hafa smá raðnúmer á þeim. Og þeir gætu hafa milljónir og milljónir og milljarða hlutum í öllum tækjum sem þeir skipið. Jæja, þeir þurfa að samanlagður undir mismunandi stærðum, allir hlutar í samsetningu, allt hlutum sem voru gerðar á ákveðnu línu, allt hlutar sem kom frá ákveðnum framleiðanda á ákveðnum degi. Og þessar útfellingarnar stundum fá upp í milljörðum. 

Svo ég vinna með nokkrum af þessir krakkar sem eru að þjást vegna þess að þeir búa þessi ginormous útfellingarnar í efri Vísitölur þeirra. Þeir gætu hafa hrátt hluta Taflan sem kemur kjötkássa aðeins. Sérhver hluti hefur einstakt raðnúmer. Ég nota raðnúmer sem kjötkássa. Það er fallegt. Hrár gögn mín borð er dreift allt yfir helstu rými. [Mitt? skrifa?] [? inntaka?] er ógnvekjandi. Ég tek mikið af gögnum. Þá hvað þeir gera er að þeir búa til GSI. Og ég segi, þú veist hvað, ég þarf að sjá allir hlutar fyrir þessum framleiðanda. Jæja, allt í einu er ég taka milljarð raðir, og efni þeim á einn hnút, vegna þess að þegar Ég safhast saman sem er Framleiðanda ID sem hökkun, og hluta númer the range, þá allt í einu er ég setja milljarð hluta í það Þessi framleiðandi hefur afhent mér. 

Það getur valdið miklum þrýstings á GSI, aftur, því ég er að hamra einum hnút. Ég er að setja allt þetta setur inn einum hnút. Og það er alvöru vandamál nota málið. Nú, ég fékk góð hönnun fyrirmynd fyrir hvernig þú forðast að. Og það er eitt af þeim vandamálum sem ég vinn alltaf með. En hvað gerist, er GSI gæti ekki nóg til að geta skrifað getu að vera fær um að ýta öllum þeim raðir í einum hnút. Og hvað gerist þá er fyrst og fremst, viðskiptavinurinn borð, aðal borð verður eldneytisgjöf vegna þess að GSI getur ekki haldið upp. Svo settu hlutfall minn heldur falla á aðal borðið eins GSI minn reynir að halda í. 

Allt í lagi, svo GSI er, LSI er, hver einn ætti ég að nota? LSI er í samræmi. GSI er eru loksins samræmi. Ef það er allt í lagi, ég mæli með GSI, þá eru þeir mun sveigjanlegri. LSI er hægt að líkja sem GSI. Og ef gögn stærð fyrir kjötkássa lykla í safn yfir 10 gígabæta, þá þú ert að fara til að vilja nota það GSI því það er bara fast hámark. 

Allt í lagi, svo stigstærð. Afköst í Dynamo DB, þú dós ákvæði [inaudible] afköstum við borð. Við höfum viðskiptavini sem hafa skilyrtri 60 billion-- eru að gera 60 milljarða beiðnir, reglulega keyra á yfir milljón beiðnir á sekúndu á borðum okkar. Það er í raun engin fræðileg takmörk á hversu mikið og hversu hratt borðið getur keyrt í Dynamo DB. Það eru sumir mjúkur takmarkanir á reikninginn þinn sem við setjum í það svo að þú ekki fara brjálaður. Ef þú vilt meira en það, ekki vandamál. Þú kemur segja okkur. Við munum snúa upp skífunni. 

Sérhver reikningur er takmörkuð að einhverju stigi í alla þjónustu, bara the kylfa svo fólk sem ekki fara brjálaður ná sér í vandræði. Engin takmörk á stærð. Þú getur sett hvaða númer atriði á borð. Stærð söluhlutar er takmörkuð við 400 kílóbæti hvor, það væri liður ekki eiginleika. Þannig að summa allra eiginleika er takmörkuð við 400 kílóbæti. Og svo aftur, höfum við að lítið LSI mál með 10 gígabæti takmörk á kjötkássa. Áhorfendur: Small númer ég vantar hvað þú ert að segja mér, að is-- Áhorfendur: Oh, 400 kílóbæti er hámarks stærð á hlut. Svo hefur hlut alla eiginleika. Svo er 400 K heildarstærð af þeim lið, 400 kílóbæti. Svo á öllum eiginleikum sameina, öll gögn það er í öllum þeim eiginleikum, vals upp í samtals stærð, nú í dag hluturinn takmörk er 400 k. Svo stigstærð aftur, náð gegnum skipting. Afköst er skilyrtri á borð stigi. Og það er í raun tveir hnúðar. Við höfum lesið getu og skrifa getu. 

Svo þetta eru leiðrétt óháð hvert öðru. Mál RCU er stranglega í samræmi les. OK, þannig að ef þú ert að segja að ég vil 1.000 RCU er þeir eru stranglega í samræmi, þeir eru í samræmi les. Ef þú segir að ég vil hugsanlega í samræmi les, þú getur ákvæði 1000 RCU er, þú ert að fara að fá 2.000 lokum samræmi les. Og helmingur the verð fyrir þá lokum felast í les. 

Aftur, leiðrétt óháð hvert öðru. Og þeir hafa throughput-- Ef þú neyta 100% af RCU þinn, þú ert ekki að fara að hafa áhrif á Upplýsingar um réttindi. Svo þeir eru alveg óháð hvert öðru. Allt í lagi, svo einn af þeim hlutum sem Ég nefndi stuttlega var eldneytisgjöf. Sogið er slæmt. Sogið bendir slæmt enga SQL. Það eru hlutir sem við getum gert til að hjálpa þú draga úr eldneytisgjöf sem þér eru að upplifa. En besta lausnin að þetta er að láta taka a líta á það sem þú ert að gera, vegna þess að það er and-mynstur í leik hér. 

Þetta, hlutir eins og non-samræmdu vinnuálag, heitum lyklana, heitt skipting. Ég er hitting ákveðna takka pláss mjög erfitt fyrir einhverjum tilteknum ástæðum. Hvers vegna er ég að þessu? Við skulum reikna það út. Ég er að blanda heitt gögnum mínum með kalt gögnum. Ég er að láta töflur mínar fá mikið, en það er í raun aðeins sumir hlutmengi af gögnum það er mjög áhugavert að mér. Svo fyrir þig inn gögn, til dæmis, a einhver fjöldi af viðskiptavini, fá þeir skrá gögn á hverjum degi. Þeir fengu mikið af gagna. 

Ef þú ert bara að undirboð allt sem þig inn gögn í eina stóra borðið, yfir tíma Borð er að fara að fá gegnheill. En ég er í raun aðeins áhuga á last 24 hours, síðustu sjö daga, síðustu 30 daga. Whatever glugga tíma sem ég hef áhuga á að leita fyrir the atburður sem þreytandi mig, eða atburður sem er áhugavert að mér, það er eina gluggi sinn sem ég þarf. Svo hvers vegna er ég að setja 10 ára virði af gagna í töflunni? Hvað sem veldur er borðið sem brotið. 

Það fær mikið. Það byrjar að breiða út yfir þúsundir hnúður. Og þar getu þína er svo lágt, að þú ert reyndar gefa takmarka á hverja einn af þeim einstaka hnúður. Svo skulum byrja að horfa á hvernig gera við rúlla þeirri töflu yfir. Hvernig eigum við að stjórna því að gögn smá betra að forðast þetta vandamál. Og hvað þýðir það líta út? Þetta er það sem lítur út eins og. Þetta er það sem slæmt NoSQL lítur út. 

Ég fékk heitt inni hér. Ef þú horfir á hlið hér, þetta eru allt skipting mín. Ég fékk 16 skipting upp hér á þessu tiltekna dag. Við gerum þetta allan tímann. Ég keyrt þetta fyrir viðskiptavini allan tímann. Það er kallað hita kort. Hitakort segir mér hvernig þú ert aðgang lykill rúm. Og hvað er þetta að segja mér að það er ein ákveðin kjötkássa að þessi strákur finnst að ansi mikið, vegna þess að hann er hitting það virkilega, virkilega erfitt. 

Svo er blár gott. Við eins og blátt. Við líkar ekki rautt. Rauða þar sem þrýstingur fær allt að 100%. 100%, nú þú ert að fara að eldneytisgjöf. Svo þegar þú sérð einhverjar rauðar línur eins this-- og það er ekki bara Dynamo DB-- hvert NoSQL gagnasafn hefur þetta vandamál. Það eru and-mynstur sem getur aka þessar tegundir af aðstæðum. Það sem ég geri er að ég að vinna með viðskiptavinum til að draga þessar aðstæður. 

Og hvað þýðir það líta út? Og þetta er að fá sem mest úr Dynamo DB afköst, en það er í raun að fá sem mest út úr NoSQL. Þetta er ekki bundin við Dynamo. Þetta er definitely-- I er notað til að vinna á Mongo. Ég þekki marga NoSQL kerfum. Hver og einn hefur þessar tegundir af heitu helstu vandamálum. Til að fá sem mest út úr öllum NoSQL gagnagrunnur, sérstaklega Dynamo DB, þú vilt að búa til töflur þar sem kjötkássa lykilatriði hefur fjölda mismunandi gildi, mikla cardinality. Því það þýðir að ég er að skrifa til fullt af mismunandi fötunum. 

Því fleiri fötunum Ég er skriflega, þeim mun líklegra Ég er að dreifa sem skrifa álag eða lesa hlaða út á mörgum hnúður, því líklegri er ég að hafa hár afkasta á borðinu. Og þá vil ég gildin að vera óskað nokkuð jafnt yfir tíma og jafnt og af handahófi og mögulegt er. Jæja, það er góður af áhugavert, því ég get ekki raunverulega stjórna þegar notendur koma. Svo nægja að segja, ef við dreifa það út yfir helstu rými, við munum líklega vera í betra form. 

Það er ákveðin Fjárhæð afhendingu tíma að þú ert ekki að fara Til að geta stjórn. En þeir eru í raun tvær víddir sem við höfum, rúm, aðgangur jafnt útbreiðslu, tími, beiðnir Koma jafnt dreift í tíma. Og ef þessir tveir skilyrði sé fullnægt, þá er það sem það er fara að líta út. Þetta er miklu betur. Við erum mjög ánægð hér. Við höfum fengið mjög jafnvel aðgang mynstur. Já, kannski þú ert að fá a lítill þrýstingur sérhver nú og þá, en ekkert í raun of mikið. Svo það er ótrúlegt hversu oft, þegar ég vinn við viðskiptavini, sem fyrst línurit með stóru rauðu bar og allt sem ljótur gulur það er um allt, sem við fá gert með æfingu eftir nokkra mánuði endurtekinna arkitektúr, þeir eru að keyra á nákvæmlega sama vinnuálag á nákvæmlega sama álag. Og þetta er það sem það er að leita eins og núna. Svo það sem þú færð með NoSQL er gögn stefið sem er algerlega bundin við aðgang mynstur. 

Og þú getur hagrætt þessi gögn stefið að styðja þessi aðgang mynstur. Ef þú ert ekki, þá þú ert að fara að sjá þær tegundir af vandamálum með þeim heitum lyklana. 

Áhorfendur: Jæja, óhjákvæmilega sumir staðir eru að fara að vera heitara en aðrir. 

RICK Houlihan: Alltaf. Alltaf. Já, ég meina það er alltaf a-- og aftur, það er sumir hönnun mynstur sem við munum komast í gegnum sem mun tala um hvernig þú takast á með þessum frábær stór útfellingarnar. Ég meina, ég fékk að hafa þá, hvernig eigum við að bregðast við þeim? Ég fékk mjög gott að nota mál sem við munum tala um fyrir það. 

Allt í lagi, þannig að við skulum tala um sumir viðskiptavinir núna. Þessir krakkar eru AdRoll. Ég veit ekki hvort þú ert þekki AdRoll. Þú sérð líklega þá mikið á vafranum. Þeir eru ad aftur miða, þeir eru stærsta auglýsing aftur miða fyrirtæki þarna úti. Þeir venjulega reglulega hlaupa yfir 60 milljarða viðskipti á dag. Þeir eru að gera yfir milljón viðskipti á sekúndu. Þeir hafa fengið mjög einföld borð uppbyggingu, the viðskipti borð. Það er í rauninni bara kjötkássa lykill er kex, svið er lýðfræðileg flokki, og þá þriðja eiginleiki er staðan. 

Þannig að við höfum öll fótspor í Vafrinn okkar frá þessum krakkar. Og þegar þú ferð til a þátt kaupmanns, þeir skora grundvallaratriðum þér yfir ýmsar lýðfræðiflokkar. Þegar þú ferð inn á vefsíðu og þú segja að ég vil sjá þessa ad-- eða í rauninni þú segir ekki that-- en þegar þú ferð á vef þeir segja að þú viljir sjá þessa auglýsingu. Og þeir fara að fá þá auglýsingu frá AdRoll. AdRoll horfir upp á borð þeirra. Þeir finna kex þinn. Auglýsendur segja þá vil ég einhvern sem er miðaldra, 40 ára gamall maður, í íþróttum. Og þeir skora á þig í þessum lýðfræði og þeir ákveða hvort eða ekki það er gott auglýsing fyrir þig. 

Nú hafa þeir SLA með auglýsingar veitendur þeirra að veita undir-10 millísekúnda Viðbrögð á hverjum einasta beiðni. Svo þeir eru að nota Dynamo DB fyrir þetta. Þeir eru hitting okkur upp milljón beiðnir á sekúndu. Þeir eru færir um að gera allt sitt leit, Triage allt sem gögn, og fá að bæta við tengil til baka til að auglýsendum á undir 10 millisekúndur. Það er í raun nokkuð stórkostlegum framkvæmd sem þeir hafa. 

Þessir krakkar actually-- þetta eru krakkar. Ég er ekki viss um að ef það er þessir gaurar. Gæti verið að þessir gaurar. Í raun sagt us-- nei, ég held ekki að það var þá. Ég held að það var einhver annar. Ég var að vinna með viðskiptavinur sem sagði mér að nú að þeir eru búnir farið til Dynamo DB, þá eru þeir eyða meiri peningum í snakk fyrir þróun lið þeirra í hverjum mánuði en þeir eyða í gagnagrunni sínum. Svo það verður að gefa þér Hugmyndin um kostnað sparnaðar sem þú getur fengið í Dynamo DB er mikil. Allt í lagi, Dropcam er annað fyrirtæki. Þetta strákur er góður of-- ef þú heldur internetið af hlutum, Dropcam er í grundvallaratriðum öryggi video. Þú setur myndavél þarna úti. Myndavélin hefur hreyfiskynjara. Einhver kemur með, kallar á hvíta lið. Camera byrjar upptöku um stund uns það sér ekki neitt hreyfingu lengur. Setur þessi vídeó upp á internetinu. 

Dropcam var fyrirtæki sem er grundvallaratriðum skipta yfir Dynamo DB vegna þess að þeir voru að upplifa gífurlegur vaxtarverkir. Og hvað þeir sögðu okkur, skyndilega petabytes gagna. Þeir höfðu ekki hugmynd um þjónustu þeirra væri svo vel. Meira heimleið video en YouTube er hvað þessir krakkar eru að fá. Þeir nota DynamoDB að fylgjast með öllum lýsigögn á öllum sínum vídeó lykilatriði. 

Svo þeir hafa S3 fötunum þeir ýta allir tvöfaldur artifacts í. Og þá hafa þeir Dynamo DB færslur sem benda fólki á að þeim S3 þremur hlutum. Þegar þeir þurfa að líta á myndband, þeir líta upp met í Dynamo DB. Þeir smella á tengilinn. Þeir rífa niður vídeó frá S3. Svo er það eins konar hvað þetta lítur út. Og þetta er beint úr liði sínu. 

Dynamo DB dregur þeirra afhendingartími fyrir vídeó viðburði frá fimm til 10 sekúndur. Í gamla Vensla verslun sinni, þeir nota til að þurfa að fara og framkvæma margar flóknar fyrirspurnir til mynd út sem vídeó til að rífa niður, minna en 50 millisekúndur. Svo það er ótrúlegt, ótrúlegt hversu mikið árangur þú getur fengið þegar þú bjartsýni og þú stillir undirliggjandi gagnagrunn til að styðja við aðgang mynstur. Halfbrick, þessir krakkar, hvað er það, Fruit Ninja Ég giska á er hlutur þeirra. Að allar keyrir á Dynamo DB. Og þessir krakkar, þau eru frábær þróun lið, mikil þróun búð. 

Ekki góð Ops lið. Þeir vildu ekki hafa a einhver fjöldi af rekstri auðlinda. Þeir voru í erfiðleikum að reyna að halda umsókn uppbygging þeirra upp og keyra. Þeir komu til okkar. Þeir litu á þessi Dynamo DB. Þeir sögðu, það er fyrir okkur. Þeir byggðu heilu þeirra umsókn ramma á það. Sumir raunverulega ágætur athugasemdir hér frá liðinu á getu þeirra að nú áherslu á að byggja leikurinn og ekki þurfa að viðhalda uppbygging, sem var að verða gríðarlegt magn af kostnaður fyrir liði sínu. Svo er þetta eitthvað that-- á gagnast sem þú færð frá Dynamo DB. 

Allt í lagi, hafa komist gögn líkan hér. Og við ræddum aðeins um þetta einn, einn til margra, og margir til margra tegund samböndum. Og hvernig halda þér þá í Dynamo. Í Dynamo DB við notum Vísitölur, almennt séð, að snúa gögn frá eitt bragð til annars. Kjötkássa lyklar, svið lykla, og stuðla. 

Í þessu tiltekna dæmi, sem flestum ríkjum hafa leyfi kröfu að aðeins leyfi einn ökumanns á mann. Þú getur ekki farið til að fá tvö ökumanns leyfi í stöðu Boston. Ég get ekki gert það í Texas. Það er góður af því hvernig það er. Og svo í DMV, höfum við leit, við vilja til að líta upp leyfi ökumanns með kennitölu. Ég vil líta upp notanda upplýsingar með leyfi númer ökumanns. 

Svo héldum borð notanda sem hefur kjötkássa takkann á raðnúmer, eða kennitala og ýmsar eiginleika skilgreind á hlutnum. Nú á þessi borð I gæti skilgreina GSI sem selbiti að um sem segir ég vil a kjötkássa lykill á skírteinið og þá allir aðrir hlutir. Nú ef ég vil fyrirspurn og finna leyfisveitandi tala fyrir hverjum Social Kennitölu, ég get fyrirspurn helstu borð. 

Ef ég vil að fyrirspurn og ég vil til að fá félagslegt öryggi númer eða aðra eiginleika eftir a leyfi númer, get ég fyrirspurn GSI. Það líkan er að einn á eina. Bara mjög einfalt GSI, Flip þá hluti í kring. Nú, tala um einn til margir. Einn til margir er í grundvallaratriðum kjötkássa range-ið þitt lykillinn. Þar sem við fáum mikið með þetta nota málið er fylgjast með gögnum. Monitor gögn kemur í reglulegum bil, eins internetið af hlutum. Við fáum alltaf allt þetta færslur koma í öllum þeim tíma. 

Og ég vil að finna allar lestur á milli ákveðnu tímabili. Það er mjög algengt fyrirspurn í eftirlit innviði. Leiðin fara um það er að finna einfalt borð uppbyggingu, eitt borð. Ég hef fengið mælingar tæki borð með kjötkássa takkann á auðkenni tækisins. Og ég er með svið takka á timestamp, eða í þessu tilfelli, Epic. Og það gerir mig framkvæma flókin fyrirspurnir gegn því lykill og aftur þær færslur sem eru miðað við niðurstöðu sett sem ég er að leita að. Og það byggir að einn til margra tengsl í aðal borðið með því að nota kjötkássa lykill, svið lykill uppbyggingu. 

Svo það er góður af innbyggður í töflunni í Dynamo DB. Þegar ég skilgreina kjötkássa og svið T borð, ég er skilgreina hver við margra tengsl. Það er foreldri barns samband. 

Við skulum tala um margar til margra sambönd. Og fyrir þetta tiltekna dæmi, aftur, við erum að fara að nota GSI er. Og við skulum tala um gaming atburðarás þar sem ég hef gefið notanda. Mig langar að finna út alla leiki sem hann er skráður fyrir eða spila í. Og fyrir tiltekið leik, ég langar til að finna alla notendur. Svo hvernig á ég að gera það? Leikjanotanda minn borð, ég er að fara að hafa kjötkássa lykill af kenni og ýmsum lykillinn af leiknum. 

Svo sem notandi getur haft marga leiki. Það er ein til margra samband milli notandi og leikirnir sem hann spilar. Og síðan á GSI, Ég flettir að um. Ég kjötkássa á leiknum og Ég svið á notanda. Þannig að ef ég vil fá allar leikur notandans að spila í, Ég fyrirspurn helstu borð. Ef ég vil fá alla notendur sem eru að spila tiltekna leik, Ég fyrirspurn GSI. Þannig að þú sérð hvernig við gerum þetta? Þú byggja til að styðja þessar GSI er að nota málið, umsókn, aðgangur mynstur, umsókn. 

Ef ég þarf að fyrirspurn á þessi vídd, láta mér að búa til yfirlit um þessi vídd. Ef ég geri það ekki, ég hugsa ekki. Og eftir notkun tilfelli, ég getur þurft vísitölu eða ég gæti það ekki. Ef það er einföld að margir, aðal borðið er fínt. Ef ég þarf að gera þetta margir til margir er, eða þarf ég að gera eitt til sjálfur, þá kannski ég þarf að annað vísitalan. Svo það veltur allt á það sem ég er að reyna að gera og það sem ég er að reyna að fá leikinn. 

Sennilega ég ætla ekki að eyða of mikill tími að tala um skjöl. Þetta fær smá, líklega, dýpra en við þurfum að fara inn í. Við skulum tala svolítið um ríkur fyrirspurn tjáningu. Svo í Dynamo DB við höfum getu til að búa það sem við köllum vörpun tjáning. Vörpun orðasambönd eru einfaldlega tína reitina eða gildi sem þú vilt birta. OK, svo ég gera upp á úrval. Ég geri fyrirspurn gegn Dynamo DB. Og ég segi, þú veist hvað ég á, sýna mig aðeins fimm stjörnu umsagnir fyrir þessa tilteknu vöru. Svo er það allt sem ég vil sjá. Ég vil ekki að sjá alla aðra eiginleika í röð, Ég vil bara að sjá þetta. Það er bara eins og í SQL þegar þú segja velja stjörnu eða frá borði, þú færð allt. Þegar ég segi að velja nafn úr borð, ég fæ bara eina eigind. Það er sama tegund af hlutur í Dynamo DB eða annað NoSQL gagnagrunna. Sía orðasambönd leyfa mér að grundvallaratriðum skera úrslit sett niður. Svo ég gera fyrirspurn. Fyrirspurn komið aftur með 500 atriði. En ég vil bara þá hluti sem hafa eigindi sem segir þetta. OK, þannig að við skulum sía út þau atriði sem passa ekki þessa tilteknu fyrirspurn. Þannig að við höfum sía tjáning. 

Sía orðasambönd getur að keyra á hvaða eiginleiki. Þeir eru ekki eins svið fyrirspurnir. Hækka fyrirspurnir eru meira vali. Sía fyrirspurnir þurfa mig til að fara fá allt Niðurstöður sett og þá móta út gögn sem ég vil ekki. Hvers vegna er það mikilvægt? Því ég las það allt. Í fyrirspurn, ég ætla að lesa og það er að fara að vera risastór um gögn. Og þá er ég að fara að móta út það sem ég þarf. Og ef ég er bara að útskorið út par af línum, þá er það í lagi. Það er ekki svo óhagkvæmt. 

En ef ég er að lesa í heild stafli af gögn, bara til að móta út einn hlut, þá er ég að fara að vera betri burt með ýmsum fyrirspurn, vegna þess að það er miklu meira vali. Það er að fara að spara mér mikið af peningar, því ég borga fyrir að lesa. Ef niðurstöðurnar sem koma aftur yfir þessi vír gæti verið minni, en ég er að borga fyrir að lesa. Svo að skilja hvernig þú ert að fá gögn. Það er mjög mikilvægt í Dynamo DB. 

Skilyrtum orðasamböndum, þetta er það þú getur hringt bjartsýnn læsa. Update ef til staðar, eða ef þetta gildi jafngildir það sem ég tilgreina. Og ef ég er með tíma stimpil á a met, ég gæti lesið gögnin. Ég gæti breyst þessi gögn. Ég gæti farið að skrifa sem gögn aftur til gagnagrunn. Ef einhver hefur breytt met, timestamp gæti hafa breyst. Og þannig skilyrt mín uppfærsla gæti sagt uppfærslu ef timestamp jafngildir þetta. Eða uppfærslu mun mistakast vegna þess að einhver uppfærði met í millitíðinni. 

Það er það sem við köllum bjartsýnn læsa. Það þýðir að einhver getur komið í og ​​breyta því, og ég ætla að uppgötva það þegar ég fer aftur að skrifa. Og þá get ég í raun að lesa það gögn og segja, ó, hann breytti þessu. Ég þarf að gera grein fyrir því. Og ég get breytt upplýsingunum í mínum taka upp og beita aðra uppfærslu. Svo er hægt að ná þeim stigvaxandi uppfærslur sem eiga sér stað á milli tíma að þú lesa gögn og þess Hvenær sem þú getur skrifað gögn. 

Áhorfendur: Og sía hugtakið þýðir í raun ekki í fjölda eða not-- 

[Interposing raddir] RICK Houlihan: Ég mun ekki fá of mikið inn í þetta. Þetta er frátekið leitarorð. Pund útsýni er áskilinn leitarorð í Dynamo DB. Sérhver gagnasafn hefur eigin áskilinn nöfn og söfn sem þú getur ekki notað. Dynamo DB, ef þú tilgreinir pund fyrir framan þetta, þú getur skilgreint þau nöfn upp hér að ofan. Mögulegt er að vísað gildi. Það er líklega ekki besta setningafræði til hafa það upp fyrir þessari umræðu, vegna þess að það fær í sumum real-- Ég hefði verið að tala meira um það á dýpra stig. 

En nægja að segja, þetta gæti vera fyrirspurn skanna þar sem þeir views-- né pund skoðanir er meiri en 10. Það er tölugildi, já. Ef þú vilt, við getum talað um að eftir umræðu. Allt í lagi, þannig að við erum að fá inn sumum tilfellum í bestu starfsvenjur þar sem við erum að fara að tala um nokkur apps hér. Hvað eru nota tilvikum til Dynamo DB. Hvað eru hönnun mynstur í Dynamo DB. 

Og sá fyrsti sem við erum að fara að tala um er internetið af hlutur. Þannig að við fáum mikið of-- ég giska, hvað er it-- meira en 50% af umferð á internetinu þessa dagana er í raun mynda af vélum, sjálfvirkum ferlum, ekki af mönnum. Ég meina þetta þetta, sem þú bera í kring í vasa, hversu mikið af gögnum sem þessi hlutur er í raun að senda kringum án þín vitandi það er alveg ótrúlegt. Staðsetningu þína, upplýsingar um hversu hratt þú ert að fara. Hvernig finnst þér Google Maps verk þegar þeir segja þér hvað umferðin er. Það er vegna þess að það eru milljón og milljónir manna að aka í kring með síma sem eru að senda gögn um allan stað allan tímann. Svo einn af þeim hlutum um þessa tegund af gögnum sem kemur í, fylgjast með gögnum, skráðu þig gögn, Tímaraðir gögn, er að það er yfirleitt bara áhugavert fyrir smá tíma. Eftir þann tíma, það er ekki svo áhugavert. Þannig að við töluðum um, ekki láta töflunum vaxa án marka. Hugmyndin hér er að kannski ég hef fengið 24 klst virði af atburðum í heitu mitt borð. Og það heitt borð er að fara að vera skilyrtri á mjög hátt hlutfall, vegna þess að það tekur a einhver fjöldi af gögnum. Það tekur a einhver fjöldi af gögnum í og ég er að lesa það mikið. Ég hef fengið mikið af rekstri fyrirspurnir í gangi gegn þeim gögnum. 

Eftir 24 klukkustundir, hey, þú Veistu hvað, ég er ekki sama. Svo kannski á hverjum miðnætti I rúlla mitt borð yfir í nýja töflu og ég deprovision þessa töflu. Og ég ætla að taka RCU er og WCU er niður vegna 24 tímum síðar Ég er ekki í gangi eins og margir fyrirspurnir gegn þessum gögnum. Þannig að ég ætla að fara að spara peninga. Og kannski 30 dögum síðar var ég ekki jafnvel þurfa að hugsa um það allt. Ég gæti tekið að WCU er alla leið niður í eitt, vegna þess að þú veist hvað, það er aldrei að fara að fá skrifað á. Gögnin er 30 daga gömul. Það breytist aldrei. 

Og það er nánast aldrei að fara að fá að lesa, þannig að við skulum bara taka þessi RCU niður í 10. Og ég er að safna a tonn af peningar á þetta gögn, og aðeins að borga fyrir heita gögnum mínum. Svo er það mikilvægast að líta á þegar þú horfir á tímaröð gögn koma í í bindi. Þetta eru aðferðir. Nú, ég gat bara láta það allir til sama borð og bara láta það borð vaxa. Að lokum, ég ætla að sjá árangur málefni. Ég ætla að hafa til að byrja að geyma sumir af þessum gögnum út af borðinu, hvað ekki. 

Skulum miklu betra hanna umsókn þína þannig að þú getur starfað með þessum hætti rétt. Svo það er bara sjálfvirkt í kóða forritsins. Á miðnætti á hverju kvöldi það rúlla borðið. Kannski það sem ég þarf er að renna glugga 24 klukkustundir af gögnum. Þá reglulega ég kalla gögn út af borðinu. Ég snyrtur með Cron starf og ég er að setja það á þessum öðrum borðum, hvað þú þarft. Svo ef rollover virkar, það er frábært. Ef ekki, klippt það. En við skulum halda að heita gögn burt frá köldum gögnunum. Það mun spara þér mikið af peningum og gera töflur meira skila. Svo the næstur hlutur sem við munum tala um er vörulisti. Vörulisti er nokkuð algengt nota málið. Þetta er í raun mjög algengt mynstur sem við munum sjá í ýmsum hlutum. Þú veist, Twitter fyrir dæmi, heitt kvak. Allir er að koma og grabbing að kvak. Vörulisti, ég fékk sölu. Ég fékk heitt sölu. Ég fékk 70.000 beiðnir á endurkomu fyrir vöru lýsing úr verslun vöru mína. Við sjáum þetta á smásölu Rekstur töluvert. Svo hvernig gera við að takast á við það? Það er engin leið til að takast á við það. Allir notendur mínir vilja sjá á sama stykki af gögnum. Þeir eru eru að koma í, samtímis. Og þeir eru allir að gera beiðnir fyrir sama stykki af gögn. Þetta gefur mér að heitur lykill, sem stór rauður rönd á töfluna mína sem við gerum ekki eins. Og það er það sem það lítur út. Svo yfir helstu my space ég er að fá hammered í sölu atriði. Ég fæ ekkert annars staðar. 

Hvernig get ég draga úr þessum vanda? Jæja, draga við þetta með skyndiminni. Cache, þú setur í grundvallaratriðum í minni skipting framan gagnagrunninum. Okkur hefur tekist [Inaudible] skyndiminni, hvernig þér getur sett upp eigin skyndiminni, [inaudible] skyndiminni [? d,?] hvað sem þú vilt. Setja það upp fyrir framan gagnagrunninum. Og þannig að þú getur geymt þessi gögn frá þeim heitum lyklana upp í því skyndiminni rúm og lesa í gegnum skyndiminni. 

Og þá mest af þínum les byrja að leita svona. Ég fékk allt þetta skyndiminni hits upp hér og ég fékk ekkert að gerast hérna vegna gagnasafn situr á bak við skyndiminni og les aldrei koma í gegnum. Ef ég breyti gögnunum í gagnagrunnur, ég verð að uppfæra skyndiminni. Við getum notað eitthvað eins steams að gera það. Og ég skal útskýra hvernig það virkar. Allt í lagi, skilaboð. Email notum við öll email. 

Þetta er nokkuð gott dæmi. Við höfum fengið einhverskonar skilaboð borð. Og við fengum innhólf og úthólf. Þetta er það sem SQL myndi líta út eins og að byggja þessi pósthólfið. Við konar nota sams konar af stefnu að nota GSI er, GSI er fyrir pósthólfið mitt og úthólfinu mínu. Svo fékk ég hrátt skilaboð koma í skilaboð mitt borð. Og fyrsta nálgun að þessu gæti verið, segja, OK, ekkert vandamál. Ég hef fengið hrátt skilaboð. Skilaboðum [inaudible], Skilaboð ID, sem er frábært. Það er einstakt kjötkássa minn. Ég ætla að búa til tvær GSI, einn fyrir pósthólfið mitt, eitt fyrir úthólfinu mínu. Og það fyrsta sem ég mun gera er ég segi kjötkássa lykillinn minn er að fara að vera viðtakandi og Ég ætla að raða á þeim degi. Þetta er frábært. Ég fékk gott útsýni mitt hér. En það er smá mál hér. Og þú keyrir inn í þetta í Vensla gagnagrunna eins og heilbrigður. Þeir kölluðu lóðrétt skipting. Þú vilt halda stóra gögnum frá litlu gögnunum. 

Og ástæðan fyrir því er vegna þess að ég verð að fara lesa atriði til að fá eiginleika. Og ef aðilar mínir eru allir á hér, þá lesa bara nokkur atriði ef Lengdin minn er meðaltali 256 kílóbæti hvor, stærðfræði fær ansi ljót. Svo segi ég að lesa pósthólfið Davíðs. Innanborðs Davíðs hefur 50 atriði. Meðaltal og stærð er 256 kílóbæti. Hér er ummyndun hlutfall mitt fyrir RCU er fjögur kílóbæti. 

OK, við skulum fara með loksins samræmi les. Ég er enn að borða 1.600 RCU er bara að lesa pósthólfið Davíðs. Ouch. OK, nú skulum hugsa um hvernig app virkar. Ef ég er í email app og Ég er að horfa á pósthólfinu mínu, og ég lít á líkama hvert skeyti, nei, ég er að horfa á samantektir. Ég er að horfa á aðeins haus. Svo skulum byggja borð uppbygging sem lítur meira eins og þessi. 

Svo hér er upplýsingar að workflow minn þarf. Það er í pósthólfinu mínu GSI. Það er dagsetning, sendanda, efni, og þá ID boðskapur, sem bendir aftur til skilaboða töflu hvar ég get fengið líkamann. Jæja, þetta væri met auðkenni. Þeir myndu benda aftur til Liðurinn auðkenni á Dynamo DB borð. Sérhver Vísitala alltaf creates-- alltaf hefur hlutinn ID sem hluta of-- að kemur með vísitölu. 

Allt í lagi. Áhorfendur: Það segir það þar sem það er geymt? RICK Houlihan: Já, það segir exactly-- það er einmitt það sem það gerir. Það segir hér er aftur met mitt. Og það skal benda hana aftur hljómplata minn. Nákvæmlega. OK, svo nú er pósthólfið mitt reyndar mun minni. Og þetta í raun styður workflow af tölvupósti app. Svo pósthólfinu mínu, ég smelli. Ég fer eftir og ég smelli á skilaboðin, það er þegar ég þarf að fara að fá líkamann, vegna þess að ég ætla að fara í aðra sýn. Svo ef þér finnst um MVC tegund ramma, líkan skoða stjórnandi. 

Líkanið inniheldur gögn að skoða þarfir og stjórnandi í samskiptum við. Þegar ég breytt ramma, þegar Ég breyta sjónarhorni, það er í lagi að fara aftur til miðlara og endumema líkan, því það er það sem notandinn ætlast. Þegar þeir breytt skoðunum, það er þegar við getum farið aftur að gagnagrunninum. Svo email, smelltu. Ég er að leita fyrir líkamann. Hringferð. Go fá líkamann. 

Ég las mikið minna gögnum. Ég er bara að lesa þá aðila sem David þarf þegar hann þarf á þeim að. Og ég er ekki að brenna í 1600 RCU er bara að sýna pósthólfið hans. Svo nú that-- þetta er leiðin sem LSI eða GSI-- Fyrirgefðu, GSI, myndi vinna út. Við höfum fengið kjötkássa okkar á viðtakanda. Við höfum fengið svið takkann á þeim degi. Og við höfum fengið varpað eiginleika að við þurfum aðeins að styðja þá skoðun. 

Við snúa að fyrir úthólfinu. Hash á sendanda. Og í raun, við höfum mjög gott, hreint útsýni. Og það er basically-- við hafa þennan flotta skilaboð borð sem er verið að dreifa vel vegna það er kjötkássa aðeins tætt skilaboð ID. Og við höfum tvo vísitölur sem eru snúningur burt af þeirri töflu. Allt í lagi, svo hugmynd hér er ekki halda stór gögn og þessa litlu gögn saman. Skipting lóðrétt, skipta þeim töflum. Ekki lesa gögn sem þú þarft ekki að. Allt í lagi, gaming. Við eins og allir leikir. Að minnsta kosti ég eins leikjum þá. Svo sumir af þeim hlutum að við að takast á við þegar við erum að hugsa um gaming, ekki satt? Gaming þessa dagana, sérstaklega farsíma gaming, er allt um hugsun. Og ég ætla að snúa hér svolítið í burtu frá DynamoDB. Ég ætla að koma með í sumir af umræðu um sumir af the önnur AWS tækni. 

En hugmyndin um gaming er að hugsa um hvað varðar API, API sem eru, almennt séð, HTTP og JSON. Það er hvernig farsíma leikir konar samskipti við bak endunum. Þeir gera JSON staða. Þeir fá gögn, og það er allt, almennt séð, í fallegu API JSON. 

Hluti eins og að fá vini, fá Topplistinn, skiptast á upplýsingum, notandi mynda efni, ýta aftur upp til the kerfi, þetta eru tegundir af hlutum sem við erum að fara að gera. Tvöfaldur eign gögn, þessi gögn gæti ekki setið í dag. Þetta gæti sitja í hlut verslun, ekki satt? En gagnagrunnurinn er að fara að á endanum að segja kerfið, segja umsókn hvar á að fara að fá það. Og óhjákvæmilega, multiplayer netþjónum bak endir innviði, og hannað fyrir hár framboð og sveigjanleika. Svo þetta eru hlutir sem við viljum öll í gaming innviði dag. 

Svo skulum taka a líta á hvað það lítur út. Fékk algerlega aftur enda, mjög einfalt. Við höfum fengið kerfi hér með margar framboð svæði. Við ræddum um AZS sem being-- hugsa þeirra sem sjálfstæðar gagnaver. Fleiri en einn gagna á AZ, en það er allt í lagi, bara hugsa um þá sem aðskilin gögn miðstöðvar sem eru landfræðilega og kenna einangruð. 

Við erum að fara að hafa par EC2 tilvikum. Við erum að fara að hafa sumir aftur endir framreiðslumaður. Kannski ef þú ert a arfur arkitektúr, við erum með það sem við köllum RDS, Venslagagnagrunnur þjónustu. Gæti verið MSSQL, MySQL, eða eitthvað svoleiðis. Þetta er hátt og mikið umsóknir eru hönnuð í dag. 

Jæja við might vilja til að fara með þetta er þegar við skala út. Við munum fara á undan og setja S3 fötu þarna. Og það S3 fötu í stað þess að þjóna upp þeim hlutum frá servers-- okkar við gætum gert það. Þú setur alla tvöfaldur þitt hlutir á þjónum þínum og þú getur notað þá miðlara dæmi til að þjóna sem gögn upp. En það er frekar dýrt. 

Betri leið til að gera er að fara á undan og setja þá hluti í S3 fötu. S3 er hlutur geymsla. Það er byggt sérstaklega fyrir þjóna upp þessar tegundir af hlutum. Og láta þá viðskiptavini beiðni beint frá þeim hlut fötunum, selja netþjóna. Þannig að við erum að byrja að skala út hér. 

Nú fengum notendur um allan heim. Ég fékk notendur. Ég þarf að hafa efni á staðnum staðsett nálægt þessum notendum, ekki satt? Ég hef búið til S3 fötu sem uppspretta geymsla minn. Og ég ætla að framan að með sem CloudFront dreifingu. 

CloudFront er CD og innihald sending net. Í grundvallaratriðum tekur það gögn sem þú tilgreinir og felustaður það allt í gegnum netið svo notendur alls staðar er hægt að hafa mjög fljótur viðbrögð þegar þeir óska ​​þá hluti. 

Þannig að þú færð hugmynd. Þú ert góður af fá meira alla þætti AWS hér til að fá það gert. Og að lokum, henda okkur með sjálfvirkri stigstærð hóp. Svo AC2 tilvikum okkar af leiknum netþjónum okkar, og þeir byrja að fá uppflettingar og viðskipti og viðskipti, þeir ætla bara að snúast annað dæmi, snúast annað dæmi, snúast annað dæmi. Svo tækni AWS hefur, það gerir þér kleift að tilgreina breytur kring sem netþjónum mun vaxa. Svo er hægt að hafa n fjölda netþjóna þarna úti á hverjum tíma. Og ef álag fer í burtu, þeir ' skreppa saman, tala vilja skreppa. Og ef álag kemur aftur, það verður að vaxa aftur út, teygjanlega. 

Svo lítur þetta vel út. Við höfum fengið mikið af EC2 tilvikum. Við getum sett skyndiminni framan gagnagrunna, reyna að flýta gagnagrunna. Næsta þrýstingur benda yfirleitt fólk sjá er þeir hækka leik með Venslagagnagrunnur kerfi. Jeez, gagnasafn árangur er hræðileg. Hvernig eigum við að bæta það? Við skulum reyna að setja skyndiminni fyrir framan það. 

Jæja, skyndiminni virkar ekki svo mikill í leikjum, ekki satt? Fyrir leiki, skrifa er sársaukafullt. Leikir eru mjög skrifa þungur. Cache virkar ekki þegar þú ert skrifa þungur vegna þess að þú hefur alltaf fékk að uppfæra skyndiminni. Þú uppfæra skyndiminni, það er óviðkomandi að flýtiminni. Það er í raun bara auka vinna. 

Svo þar sem við förum hér? Þú hefur got a stór flöskuháls þarna niðri í dag. Og staður til að fara augljóslega er skipting. Skipting er ekki auðvelt að gera þegar þú ert að takast á við Vensla gagnagrunna. Með Vensla gagnagrunna, þú ert ábyrgð á að stjórna, í raun, lykillinn pláss. Þú ert að segja notendur milli A og M fara hér, milli N og Z fara þangað. Og þú ert að skipta yfir umsókn. Svo þú ert að takast á við þessi skipting gögn uppspretta. Þú ert viðskiptalegs þvingun sem ekki span skipting. Þú hefur fengið allar tegundir af messiness að þú ert að takast á við þarna niðri að reyna að takast á við stigstærð út og byggja upp stærri innviði. Það er bara ekkert gaman. 

Áhorfendur: Svo þú ert að segja að auka uppspretta stig hraða upp ferlið? RICK Houlihan: Aukin? Áhorfendur: Heimild stig. RICK Houlihan: Source stig? Áhorfendur: Frá upplýsingar þar sem upplýsingar er að koma frá? RICK Houlihan: Nei Það sem ég er að segja er að hækka Fjöldi skipting í gögn geyma bætir afköst. Svo er það sem er að gerast hér notendur koma inn í EC2 dæmis upp hér, vel, ef ég þarf notandi Það er til M, ég fer hér. Frá N til p, ég fer hér. Frá P til Z, ég fer hér. 

Áhorfendur: OK, þá þannig að þeir eru allt geymt í mismunandi hnútar? 

RICK Houlihan: Já. Hugsaðu um þetta eins og mismunandi síló af gögnum. Svo þú ert að þurfa að gera þetta. Ef þú ert að reyna að gera þetta, ef þú ert að reyna að skala á samræmdum vettvang, þetta er það sem þú ert að gera. Þú ert að taka gögn og þú ert að skera það niður. Og þú ert að sneiða það yfir margfeldi dæmi af gagnagrunninum. Og þú ert að stjórna öllu sem á umsókn flokkaupplýsingar. Það er ekki gaman. Svo hvað við viljum fara? Við viljum fara DynamoDB, fullkomlega tekist, NoSQL gögn geyma ákvæði afköst. Við notum efri stuðla. Það er í grundvallaratriðum HTTP API og felur skjal stuðning. Svo þú þarft ekki að hafa áhyggjur um neitt af þessu skipting. Við gerum það fyrir þig. Svo nú, í stað þess, þú bara skrifa að borðinu. Ef borðið þarf að vera skipt, sem gerist á bak við tjöldin. Þú ert alveg einangruð frá því sem verktaki. Svo skulum við tala um sum nota tilvikum að við að keyra inn í gaming, algengar gaming atburðarás, Topplistinn. Svo þú hefur fengið notendur koma í, að BoardNames að þeir séu á, skorar fyrir þennan notanda. Vér hass á UserId, og þá höfum við mikinn á leikinn. Svo í hvert notandinn vill sjá allt leikur hann lék og allt hans stigamet yfir öllum leiknum. Svo er það persónuleg Topplistinn hans. 

Nú vil ég að fara í og ​​ég vil get-- þannig að ég fá þessar persónulega leaderboards. Það sem ég vil gera er að fara að fá efst skora yfir alla notendur. Svo hvernig á ég að gera það? Þegar vitnisburður minn er tætt á sem UserId, var á bilinu á leiknum, jæja ég ætla að fara á undan og endurskipuleggja, búa til GSI, og ég ætla að endurskipuleggja þessi gögn. 

Nú ætla ég að kjötkássa á BoardName, sem er leikur. Og ég ætla að svið á efsta stig. Og nú hef ég búið til mismunandi hópa. Ég er að nota sama borð, sama hlut gögn. En ég er að búa til fötu sem gefur mér samansafn af stigamet eftir leik. 

Og ég get fyrirspurn borðið til að fá þær upplýsingar. Þannig að ég hef sett það fyrirspurn mynstur upp vera studd af efri vísitölu. Nú eru þeir geta vera flokkaður eftir BoardName og er flokkaður eftir TopScore eftir. Svo þú sérð, eru þessar tegundir tilvika nota færðu í gaming. Annar góður nota málið sem við fáum í gaming er verðlaun og hver er vann verðlaun. Og þetta er frábær nota málið þar sem við köllum rýr stuðla. Dreifður Vísitölur eru getu til að búa til vísitölu sem þýðir ekki endilega innihalda hvert einasta atriði á borð. Og hvers vegna ekki? Þar sem eiginleiki sem er að vera verðtryggð er ekki til á hverjum lið. 

Svo í þessu tiltekna nota málið, ég er að segja, þú veist hvað, ég ætla að búa eigindi sem heitir Award. Og ég ætla að gefa öllum notendum sem hefur verðlaun sem eigindi. Notendur sem hafa ekki verðlaun eru ekki að fara að hafa þessi eiginleiki. Svo þegar ég bý í Vísitala, aðeins notendur sem eru að fara að sýna upp á vísitölunni eru þau sem í raun hafa unnið til verðlauna. Svo er það frábær leið til að vera fær um til að búa til síaðar vísitölur sem eru mjög, mjög sértækur sem ekki að kemba allt borðið. 

Þannig að við erum að fá lágt á tíma hér. Ég ætla að fara á undan og sleppa út og sleppa þessu tilviki. Tala svolítið about-- 

Áhorfendur: Má ég spyrja fljótur spurningu? Eitt er að skrifa þungur? RICK Houlihan: Hvað er? Áhorfendur: Skrifa þungur. RICK Houlihan: Skrifa þungur. Leyfðu mér að sjá. 

Áhorfendur: Eða er það ekki eitthvað sem þú getur bara rödd í nokkrum sekúndum? RICK Houlihan: Við förum gegnum atkvæðagreiðslu atburðarás. Það er ekki svo slæmt. Gera þú krakkar hafa nokkrar mínútur? OK. 

Þannig að við munum tala um atkvæðagreiðslu. Svo rauntíma atkvæðagreiðslu, höfum við kröfur um atkvæðagreiðslu. Kröfur eru sem við leyfum hver maður að kjósa aðeins einu sinni. Við viljum enginn að vera fær um til að breyta atkvæði sínu. Við viljum rauntíma samloðun og greinandi fyrir lýðfræði sem við erum að fara að vera birtist notendum á síðuna. 

Hugsaðu um þessa atburðarás. Við vinnum mikið af veruleika TV sýnir hvar þeir eru gera þessar nákvæmlega tegund af hlutur. Svo er hægt að hugsa um aðstæður, við höfum margar milljónir unglingsstúlkna þar með klefi sími þeirra og atkvæðagreiðslu, og greiða atkvæði, og að greiða atkvæði um hver þau eru finna að vera vinsæll. Svo þetta eru nokkrar af the kröfur við hlaupum út. 

Og svo fyrst að taka í að leysa þetta vandamál væri að byggja upp mjög einfalt forrit. Svo ég hef fengið þetta forrit. Ég hef nokkrar kjósendur þarna úti. Þeir koma í, þeir högg the atkvæðagreiðslu app. Ég hef fengið nokkrar hrár atkvæði borð Ég ætla bara að afrita þau atkvæði í. Ég hef fengið samanlagt atkvæði borð sem mun gera Analytics og lýðfræði, og við munum setja allt þetta í það. 

Og þetta er frábært. Lífið er gott. Lífið er gott þar til við að finna út að það er alltaf bara einn eða tveir fólk sem eru vinsælar í kosningum. Það er aðeins einn eða tveir hlutir að fólk virkilega vænt um. Og ef þú ert að greiða atkvæði á mælikvarða, allt í einu er ég fara að hamar í helvíti út af tveir frambjóðendur, einn eða tveir frambjóðendur. A mjög takmarkaður fjöldi atriða fólk finnur til að vera vinsæll. 

Þetta er ekki góð hönnun mynstur. Þetta er í raun mjög slæmt hönnun mynstur vegna þess að það skapar nákvæmlega hvað við talaði um sem var heitum lyklana. Heitum lyklana eru eitthvað við líkar ekki. 

Svo hvernig gera við lagfærum það? Og í raun, hvernig á að laga þetta er með því að taka þá frambjóðanda fötunum og hvers frambjóðanda sem við höfum, við erum að fara að bæta handahófi gildi, eitthvað sem við vitum, af handahófi gildi milli einn og 100, milli 100 og 1.000, eða á milli eitt og 1.000, þó margir handahófi gildi sem þú vilt auka á lok þess frambjóðandi. 

Og hvað hef ég gert í raun þá? Ef ég er að nota frambjóðandi ID sem fötu til samanlagðra atkvæða, ef ég hef bætt við handahófi númer til loka að Ég hef búið nú 10 fötunum, a hundrað fötunum, þúsund fötur að ég er að leggja saman atkvæði yfir. 

Þannig að ég hef milljónir og milljónir, og milljónir af skrám koma í fyrir þessum frambjóðendum, ég er nú að breiðast út þessir atkvæði yfir Frambjóðandi a_1 gegnum Frambjóðandi A_100, því í hvert skipti sem atkvæði koma í, Ég mynda af handahófi gildi milli eitt og 100. Ég klísturvamandi það á the endir af the frambjóðandi sem maður er að greiða atkvæði um. Ég varp það inn í þessi fötu. 

Nú á rass, ég veit að ég fékk hundrað fötunum. Svo þegar ég vil fara á undan og samanlagður atkvæði, Ég las úr öllum þeim fötunum. Svo ég fara á undan og bæta. Og þá er ég ekki að dreifa safna þar sem ég fer út og segja hey, þú veist hvað, lykill þessa frambjóðanda rými er yfir hundrað fötunum. Ég ætla að safna öllum atkvæði frá þeim hundrað fötunum. Ég ætla að samanlagður þá og ég ætla að segja, Frambjóðandi A er nú alls atkvæði telja x. 

Nú bæði skrifa fyrirspurn og lesa fyrirspurn eru vel dreift vegna þess að ég er að skrifa yfir og ég er að lesa á hundruðum lykla. Ég ætla ekki að skrifa og lesa yfir einum lykli núna. Svo er það mikill mynstur. 

Þetta er í raun sennilega einn af mikilvægustu hönnun mynstur fyrir mælikvarða í NoSQL. Þú munt sjá þessa tegund af hönnun mynstur í öllum bragði. MongoDB, DynamoDB, er það ekki Sama, við verðum öll að gera þetta. Vegna þess að þegar þú ert að takast á með þeim gríðarlega útfellingarnar, þú þarft að reikna út a vegur til dreifa þeim út yfir fötunum. Svo er þetta eins og þú gerir það. Allt í lagi, svo hvað þú ert að gera núna er þú ert viðskipti burt lesa kostnaður fyrir skrifa sveigjanleika. Kostnaður við að lesa mitt er svolítið flóknari og ég verð að fara að lesa úr hundrað fötunum staðinn fyrir eitt. En ég er fær um að skrifa. Og afköst mín, skrifa minn afköst er ótrúlegt. Svo það er yfirleitt mikilvægt tækni fyrir stigstærð DynamoDB, eða NoSQL gagnagrunnur fyrir þessi mál. Þannig að við mynstrağur út hvernig á að skala það. Og við mynstrağur hvernig útrýma heitum lyklana okkar. Og þetta er frábært. Og við fengum þessa fallegu kerfi. Og það er gefið okkur mjög rétt atkvæðagreiðslu vegna þess að við höfum met atkvæði de-dupe. Það er byggt inn DynamoDB. Við ræddum um skilyrtan réttindi. 

Þegar kjósandi kemur inn, setur innskot á borðið, þeir setja með kjósandi ID þeirra, ef þeir reyna að setja annað atkvæði, Ég skilyrt skrifa. Segja aðeins skrifa þetta ef þetta er ekki til. Svo um leið og ég sé að að atkvæði er högg á borð, enginn annar er að fara að vera fær um að setja atkvæði sitt í. Og það er frábært. Og við erum incrementing umsóknarríki gegn okkar. Og við erum að gera okkar lýðfræði og allt það. En hvað gerist ef minn umsókn fellur yfir? Nú allt í einu atkvæði eru að koma í, og ég veit ekki hvort þeir eru að fá afgreidd í greinandi mínum og lýðfræði lengur. Og þegar umsóknin kemur aftur upp, hvernig helvíti veit ég hvað atkvæði hafa verið unnin og þar fæ ég að byrja? 

Svo er þetta alvöru vandamál þegar þú byrja að líta á þessa tegund af atburðarás. Og hvernig eigum við að leysa þetta? Við leysa það með það sem við kalla DynamoDB lækjum. Straumar er tími panta og skipt breyting log hverjum aðgang að borðinu, hver skrifar aðgang að borðinu. Öll gögn sem er skrifað til Taflan sýnir sig á straumi. 

Það er í grundvallaratriðum a 24 klst biðröð. Atriði högg á, að þær lifa í 24 klukkustundir. Þau er hægt að lesa mörgum sinnum. Guaranteed til afhendingar aðeins einu sinni að læknum, lesa mátti n fjölda sinnum. Svo þó margir aðferðir sem þú vilt neyta að gögn, getur þú neyta það. Það mun birtast í hvert uppfærslu. Sérhver skrifa mun aðeins birtast einu sinni á straumi. Svo þú þarft ekki að hafa áhyggjur um vinnslu það tvisvar frá sama ferli. 

Það er stranglega skipað í lið. Þegar við segjum tíma pantað og skipt, þú munt sjá á skipting á straumi. Þú munt sjá atriði, uppfærslur í röð. Við erum ekki að tryggja á straumi sem þú ert fara að fá hverja færslu í því skyni yfir atriði. 

Svo vatnsföll eru idempotent. Ekki við vitum öll hvað idempotent þýðir? Idempotent þýðir að þú getur gert það yfir, og aftur, og aftur. Niðurstaðan er að fara til vera the sami. 

Vatnsföll eru idempotent, en þeir verða að vera lék frá upphafið, hvar sem þú velur, allt til enda, eða þeir vilja ekki leiða í sömu gildi. 

Sama með MongoDB. MongoDB hefur reisa þeir kalla oplog. Það er nákvæmlega sömu byggingu. Margir NoSQL gagnagrunna hafa þetta reisa. Þeir nota það til að gera hlutina eins afritunar, sem er einmitt það sem við gerum með lækjum. Áhorfendur: Kannski heretical spurning, en þú tala um forrit gera niður svo framvegis. Eru vatnsföll tryggt að aldrei hugsanlega fara niður? RICK Houlihan: Já, læki eru tryggð að fara aldrei niður. Við stjórna innviði bak. læki sjálfkrafa dreifa í farartæki stigstærð hópi þeirra. Við munum fara í gegnum smá hluti um hvað gerist. 

Ég ætti ekki að segja að þeir eru ekki tryggt að aldrei fara niður. Þættir eru tryggð að birtast í straumi. Og straumi mun vera aðgengilegur. Svo fer það niður eða kemur aftur upp, það gerist undir. Það covers-- það er allt í lagi. Allt í lagi, þannig að þú færð annað skoða tegundir af skjánum. Útsýnið tegundir sem eru mikilvæg til að a forritari yfirleitt eru, hvað var það? Ég fæ gömlu viðhorfi. Þegar uppfærsla hits the borð, verður það ýta gömlu viðhorfi að læknum þannig að gögn geta skjalasafn, eða breyta stjórna, breyta auðkenni, breyting stjórnun. 

Nýja myndin, hvað það er nú eftir endurnýja, það er önnur tegund af ljósi þú getur fengið. Þú getur fengið bæði gamla og nýjar myndir. Kannski ég vil þá báða. Mig langar að sjá hvað það var. Mig langar að sjá hvað það breytt í. 

Ég er með farið tegund af ferli sem keyrir. Það þarf að staðfesta að þegar þessir hlutir breytast, sem þeir eru innan ákveðinna marka eða innan ákveðnum þáttum. 

Og þá kannski bara ég þarf að vita hvað breyttist. Mér er alveg sama hvaða atriði breyst. Ég þarf ekki að þurfa að vita hvað eiginleika breytt. Ég þarf bara að vita að atriði eru snert. Svo þetta eru tegundir af skoðunum sem þú færð af straum og þú getur samskipti við. 

Forritið sem eyðir á, þetta er góður af því hvernig þetta virkar. DynamoDB viðskiptavinur spyrja að ýta gögn til borðum. Straumar senda á það sem við köllum Pottbrot. Pottbrot eru minnkaðar óháð töflunni. Þeir lína ekki upp alveg að skipting á töflunni. Og ástæðan fyrir því er vegna þess að þeir stilla upp í sambandi við hæfni, núverandi getu töflunni. 

Þeir dreifa í þeirra eigin farartæki stigstærð hópur, og þeir byrja að snúast út eftir því hversu margir skrifar eru að koma í, hversu margir reads-- í raun er það skrifar. Það er engin reads-- en hvernig margir skrifar eru að koma inn. 

Og þá á bak enda höfum við það sem við kalla KCl eða Kinesis viðskiptavinur bókasafn. Kinesis er straum gögn vinnsla tækni frá Amazon. Og lækir er byggt á því. 

Svo þú notar KCL virkt forrit til að lesa straum. The Kinesis Client Library raun stýrir starfsmenn fyrir þig. Og það er einnig sumir áhugavert. Það verður að búa til nokkrar töflur upp í DynamoDB tablespace þinn að fylgjast með hvaða liði hafa verið afgreidd. Svo Þannig ef það fellur aftur, ef það fellur yfir og kemur og fær stóð aftur upp, það er hægt að ákvarða hvar var það í vinnslu strauminn. 

Það er mjög mikilvægt þegar þú ert að tala um eftirmyndun. Ég þarf að vita hvað Gögnin voru verið afgreidd og hvaða gögn enn að vinna. Svo KCL bókasafn fyrir læki mun gefa þér mikið af því virkni. Það sér um alla umgengni. Það stendur upp starfsmann fyrir hvert Shard. Það skapar stjórnsýslu borð fyrir hvert Shard, fyrir hvern starfsmann. Og eins og þeim starfsmönnum eldi, þeir halda þeim borðum svo þú veist þetta met var að lesa og vinna. Og þá þannig að ef ferlið deyr og kemur aftur á netinu, það er hægt að halda áfram rétt þar sem það tók burt. 

Þannig að við notum þetta fyrir kross-svæðinu afritunar. A einhver fjöldi af viðskiptavinum hafa þörf til færa gögn eða hluta af töflum sínum um að mismunandi svæðum. Það eru níu svæði um allan heiminn. Þannig að það gæti verið need-- I gæti hafa notendur í Asíu, notendur í austurströnd Bandaríkjanna. Þeir hafa mismunandi gögn sem þarf að vera á staðnum dreift. Og kannski notandi flýgur frá Asia yfir til Bandaríkjanna, og ég vil endurtaka gögn hans með honum. Svo þegar hann fær af flugvél, hefur hann góð reynsla að nota farsíma app hans. 

Þú getur notað kross-svæðinu afritunar bókasafn til að gera þetta. Í grundvallaratriðum erum við að hafa veitt tvær tækni. Eitt er hugga umsókn þú getur standa upp á eigin EC2 dæmi þitt. Það liggur hreint afritunar. Og þá erum við gaf þér bókasafn. Bókasafnið er hægt að nota til að byggja upp eigin umsókn þína ef þú langar að gera brjálaður hlutina með að data-- sía, endurtaka aðeins hluti af því, snúa gögn, færa það inn í a mismunandi borð, svo framvegis og svo framvegis. Svo er þannig hvað það lítur út. 

DynamoDB Straumar geta verið unnin með það sem við köllum lambda. Við umtal svolítið um atburði ekin umsókn arkitektúr. Lambda er lykilþáttur í því. Lambda er númerið sem skýtur á eftirspurn til að bregðast við ákveðnu atviki. Einn af þeim atburðum gæti verið met birtast á straumi. Ef met birtist á straumi, við munum kalla þetta Java aðgerð. Jæja, þetta er JavaScript, og Lambda styður Node.js, Java, Python, og mun brátt styðja önnur tungumál eins og heilbrigður. Og nægja að segja, að það er hreint númer. skrifa í Java, skilgreina flokk. Þú ýta JAR upp í Lambda. Og þá þú tilgreinir hvaða tegund að hringja til að bregðast við þeim tilvikum. Og þá Lambda innviði á bak við það mun keyra þessi númer. 

Það merkjamál geta afgreitt færslur burt straumnum. Það getur gert neitt það vill með það. Í þessu tiltekna dæmi, eru öll við í raun að gera er að skrá þig á eiginleika. En þetta er bara númer. Merkjamál geta gert neitt, ekki satt? 

Svo er hægt að snúa þessum gögnum. Þú getur búið til þitt eigið efni útsýni. Ef það er skjal uppbyggingu, þú getur fletja uppbyggingu. Þú getur búið til aðra stuðla. Alls konar hlutir sem þú getur gera með DynamoDB lækjum. 

Og í raun, það er það sem það lítur út. Þannig að þú færð þær uppfærslur koma í. Þeir eru að koma af streng. Þeir eru að lesa af Lambda virka. Þeir eru að snúa gögn og ýta henni upp í afleiddum borðum, tilkynna ytri kerfi breytinga, og þrýsta gögn inn ElastiCache. 

Við ræddum um hvernig á að setja skyndiminni framan gagnagrunn fyrir að sala atburðarás. Jæja hvað gerist ef ég uppfæra atriði lýsingu? Jæja, ef ég hafði Lambda virka í gangi á þeirri töflu, ef ég uppfæri hlutinn lýsingu, verður það taka upp met af straumi, og það mun uppfæra ElastiCache dæmi með nýjum gögnum. Svo er það mikið af Hvað við gerum við Lambda. Það er lím númer, tengjum. Og það gefur í raun getu til að ráðast og að keyra mjög flókin forrit án þess að hollur framreiðslumaður uppbygging, sem er mjög flott. 

Svo við skulum fara aftur til okkar rauntíma atkvæðagreiðslu arkitektúr. Þetta er ný og endurbætt með okkar lækir og KCL virkt umsókn. Sama og áður, við getum séð hvaða mælikvarða kosningum. Við eins og þetta. Við erum að gera út tvístra safnar á mörgum fötunum. Við höfum fengið bjartsýnn læsa gerast. Við getum haldið kjósendur okkar breyti atkvæði. Þeir geta aðeins kjósa einu sinni. Þetta er frábært. Real-tími kenna umburðarlyndi, stigstærð samansafn núna. Ef hlutur fellur yfir, það veit hvar á að endurræsa sig þegar það kemur aftur upp vegna við erum að nota KCl app. Og þá getum við líka notað sem KCL umsókn að ýta gögn út að rauðvik fyrir aðra app greinandi eða notkun teygju MapReduce að keyra rauntíma straumspilunartenglar útfellingarnar burt þessi gögn. 

Svo þetta eru hlutir sem við hef ekki talað um mikið. En þeir eru fleiri tækni sem koma að bera þegar þú ert að leita á þessar aðstæður. 

Allt í lagi, svo það er um greinandi með DynamoDB lækjum. Hægt er að safna de-dupe gögn, gera alls konar Nice efni, samanlagður gögn í minni, skapa þeim afleidd töflur. Það er a gríðarstór nota málið að mikið af viðskiptavinum eru í tengslum við, taka hreiður eiginleikar þeirra JSON skjölum og búa til fleiri vísitölur. 

Við erum í lokin. Þakka þér fyrir að bera með mér. Svo skulum við tala um tilvísun arkitektúr. DynamoDB situr í miðju svo mikið af AWS innviði. Í grundvallaratriðum þú getur krókur það upp til nokkuð sem þú vilt. Umsóknir byggð með Dynamo eru Lambda, ElastiCache, CloudSearch, ýta gögn út í Elastic MapReduce, útflutningur innflutningur frá DynamoDB í S3, alls konar Verkferlar. En sennilega besta hlutur til að tala um, og þetta er það sem er raunverulega áhugavert er þegar við tala um atburði ekið forrit. 

Þetta er dæmi um innri verkefni sem við höfum þar sem við erum í raun og veru útgáfu til að safna niðurstöðum könnunarinnar. Svo í netfangatengil sem við sendum út, það verður vera svolítið hlekkur segja smellur hér að bregðast við könnuninni. Og þegar maður smellir sem tengjast, hvað gerist er þeir rífa niður örugg HTML könnun form úr S3. Það er ekki framreiðslumaður. Þetta er bara S3 hlut. 

Sem form kemur upp, hleðst upp í vafranum. Það fékk burðarás. Það fékk flókið JavaScript að það er í gangi. Svo það er mjög ríkur umsókn gangi í vafranum viðskiptavinarins. Þeir vita ekki að þeir eru ekki samskipti við bak endir framreiðslumaður. Á þessum tímapunkti, það er allt vafra. 

Þeir birta niðurstöðurnar hvað við köllum Amazon API Gateway. API Gateway er einfaldlega vefur API að þú getur skilgreint og krókur upp að hvað sem þú vilt. Í þessu tiltekna tilviki, við erum boginn upp til a Lambda virka. 

Svo er gangur POST minn gerast án miðlara. Í grundvallaratriðum situr að API Gateway það. Það kostar mig ekkert fyrr en fólk byrja að senda á það, ekki satt? Lambda virka situr bara þarna. Og það kostar mig ekkert fyrr en fólk byrja hitting það. Svo er hægt að sjá, sem bindi eykst, það er þegar gjöld koma. Ég ætla ekki að keyra miðlara 7/24. 

Svo ég draga formið niður úr fötu, og ég skrifa í gegnum API Gateway í Lambda virka. Og þá Lambda virka segir, þú veist hvað, ég hef fengið nokkrar Piis, sumir persónugreinanlegar upplýsingar í þessum svörum. Ég fékk athugasemdir sem koma frá notendum. Ég hef fengið netföng. Ég hef fengið notendanöfn. 

Leyfðu mér að skipta á því. Ég ætla að búa til nokkur lýsigögn burt þessa færslu. Og ég ætla að ýta á lýsigögn í DynamoDB. Og ég gæti dulkóða öll gögn og ýta því inn DynamoDB ef ég vil. En það er auðveldara fyrir mig, í þessu nota málið, að fara á undan með að segja, Ég ætla að ýta hrár gögn í dulkóðuðu S3 fötu. Svo ég nota innbyggða í S3 miðlara megin dulkóðun og Lykill Stjórnun Amazon Þjónusta svo að ég hafa lykil að getur snúið á reglulegu millibili, og ég get að vernda þessi PII gögn sem hluta af öllu workflow. 

Svo hvað hef ég gert? Ég hef bara sent í heild umsókn, og ég hef enga framreiðslumaður. Svo er það atburður ekið umsókn arkitektúr gerir fyrir þig. 

Nú ef þér finnst um að nota málið til this-- við höfum aðra viðskiptavini ég er að tala að um þetta nákvæmlega arkitektúr sem hlaupa gríðarlega stór herferðir, sem eru að horfa á þetta og fara, ó minn. Því nú geta þeir grundvallaratriðum ýta því út þar, láta þessi herferð bara sitja þar til það opnar, og ekki að hafa áhyggjur a Fig um hvers konar uppbygging er að fara að vera þarna til að styðja það. Og þá eins fljótt og þessi herferð er gert, það er eins og innviði bara strax fer í burtu vegna þess að það í raun er engin uppbygging. Það er bara númer sem situr á lambda. Það er bara gögn sem situr í DynamoDB. Það er ótrúlega hátt að byggja forrit. 

Áhorfendur: Svo er það meira skammlífa en það væri ef það var geymt á raunverulegum miðlara? 

RICK Houlihan: Algjörlega. Vegna þess miðlara dæmis þyrfti að vera 24/07. Það þarf að vera til staðar fyrir einhver að svara. Jæja giska á hvaða? S3 er í boði 24/7. S3 bregst alltaf. Og S3 er mjög, mjög gott að þjóna upp hluti. Þeir hlutir geta verið HTML skrár, eða JavaScript skrár eða hvað sem þú vilt. Þú getur keyrt mjög ríkur vefur umsókn úr S3 fötunum, og fólk. 

Og svo er það hugmyndin hér er að komast í burtu frá því við notuðum til að hugsa um það. Við notuðum til að hugsa í Skilmálar netþjónum og vélar. Það er ekki um það lengur. Það er um innviði sem kóða. Dreifa kóðann til ský og láta skýið keyra það fyrir þig. Og það er það sem AWS er ​​að reyna að gera. 

Áhorfendur: Svo gull kassi í miðjunni af API Gateway er ekki framreiðslumaður-eins, en í staðinn er just-- 

RICK Houlihan: Hægt er að hugsa um það sem miðlara framhlið. Allt það er er það mun taka HTTP óska og landakort það í annað ferli. Það er allt það gerir. Og í þessu tilfelli erum við að kortleggja það að Lambda virka. Allt í lagi, svo það er allt sem ég fékk. Þakka þér kærlega. Ég þakka það. Ég veit að við viljum smá tímanum. Og vonandi þú krakkar fékk a lítill hluti af upplýsingum að þú getur tekið burt í dag. Og ég biðst afsökunar ef ég fór yfir sumir höfuð yðar, en það er gott mikið af grundvallaratriði foundational þekkingu sem ég held að sé mjög mikilvæg fyrir þig. Svo þakka þér fyrir að hafa mig. [Applause] Áhorfendur: [inaudible] er þegar þú varst að segja þú þurftir að fara í gegnum málið frá upphafi til enda að fá rétta gildi eða sömu gildi, hvernig væri gildin breyst ef [inaudible]. 

RICK Houlihan: Oh, idempotent? Hvernig væri gildin breytast? Jæja, vegna þess að ef ég vissi ekki að hlaupa það alla leið til enda, þá veit ég ekki hvaða breytingar voru gerðar í síðustu míla. Það er ekki að fara að vera sömu upplýsingar og það sem ég sá. Áhorfendur: Ó, svo þú bara hafa ekki fengið allt inntak. RICK Houlihan: Hægri. Þú þarft að fara frá upphafi til enda, og þá er það að fara að vera í samræmi ríkisins. Cool. 

Áhorfendur: Svo þú sýndi okkur DynamoDB getur gert skjal eða lykill gildi. Og við eyddum miklum tíma á lykill gildi með kjötkássa og leiðir að Flip það í kring. Þegar þú horfði á borðum, er að fara á bak skjal nálgun? 

RICK Houlihan: Ég myndi ekki segja þannig það á bak. 

Áhorfendur: Þeir voru aðskilin frá the-- 

RICK Houlihan: Með skjalinu nálgun, tegund skjals í DynamoDB er bara hugsa um sem annar eiginleiki. Það er eiginleiki sem inniheldur a hierarchic gögn uppbygging. Og þá í leitirnar, þú getur notað eiginleika af þeim hlutum sem nota Object Ritháttur. Svo ég geti síað á hreiður eign JSON skjalinu. Áhorfendur: Svo hvenær ég gera skjal nálgun, Ég get konar koma á tabular-- Áhorfendur: Algjörlega. Áhorfendur: --indexes og hlutir sem þú talaði bara um. RICK Houlihan: Já, Vísitölur og allt það, þegar þú vilt að kemba eiginleika JSON, á þann hátt að við myndum þurfa að gera það er ef þú setja JSON hlut eða skjal í Dynamo, myndir þú nota læki. Straumar myndi lesa inntak. Þú vilt fá að JSON mótmæla og þú vilt segja OK, hvað er eign sem ég vil vísitölu? 

Þú búa til afleitt borð. Nú það er hvernig það virkar núna. Við leyfum þér ekki að kemba beint þeim eiginleika. 

Áhorfendur: Tabularizing skjöl. 

RICK Houlihan: Einmitt, fletja það, tabularizing það nákvæmlega. Það er það sem þú gerir við það. 

Áhorfendur: Þakka þér. 

RICK Houlihan: Já, algerlega, þakka þér. Áhorfendur: Svo það er góður af Mongo uppfyllir Redis classifers. 

RICK Houlihan: Já, það er mikið eins og þessi. Það er góð lýsing á því. Cool.