[MUSIC nagpe-play] RICK Houlihan: Lahat ng karapatan. Hi, lahat. Ang pangalan ko ay Rick Houlihan. Ako ay isang senior principal solusyon arkitekto sa AWS. I-focus sa NoSQL at DynamoDB teknolohiya. Naririto ako ngayon upang makipag-usap sa sa iyo ng kaunti tungkol sa mga. 

Aking background ay lalo na sa layer data. Ako na ginugol ang kalahati ng aking pag-unlad karera pagsulat database, access ng data, mga solusyon para sa iba't ibang mga application. Ako sa Cloud virtualization para sa mga tungkol sa 20 taon. Kaya bago ang Cloud ay ang Cloud, ginamit namin upang tumawag ito utility computing. At ang mga ideya ay, ito ay tulad PG & E, magbabayad ka para sa kung ano ang iyong gamitin. Ngayon tinatawag naming ito sa cloud. 

Ngunit sa paglipas ng mga taon, ako ay nagtrabaho para sa isang pares ng mga kumpanya marahil mo na hindi kailanman narinig ng. Ngunit ko na naipon ng isang listahan ng mga teknikal na kabutihan, Hulaan ko gusto mong sabihin. Mayroon akong walong mga patente sa sistema Cloud virtualization, microprocessor disenyo, complex pagpoproseso ng kaganapan, at iba pang mga lugar na rin. 

Kaya sa panahon ngayon, ang focus ko karamihan sa NoSQL teknolohiya at ang susunod na henerasyon database. At na sa pangkalahatan ay kung ano ako pagpunta na dito ang pakikipag-usap sa iyo ngayon tungkol sa. Kaya kung ano ang maaari mong asahan mula sa session na ito, kami ay pumunta sa pamamagitan ng isang maikling kasaysayan ng data processing. Ito ay palaging kapaki-pakinabang sa maunawaan kung saan kami ay dumating mula sa at kung bakit hindi namin kung saan kami. At kami ay makipag-usap sa isang maliit na kaunti tungkol NoSQL technology mula sa isang pangunahing kinatatayuan. 

Makikipag-ugnay kami sa ilan sa mga ang DynamoDB internals. DynamoDB ay AWS ni walang lasa. Ito ay isang ganap na pinamamahalaang at naka-host NoSQL solusyon. At kami na makipag-usap nang kaunti tungkol sa talahanayan istraktura, mga API, mga uri ng data, index, at ang ilan sa mga internals ng na teknolohiya DynamoDB. Babalikan ka namin sa ilan sa mga disenyo pattern at pinakamahusay na kasanayan. Susubukan naming makipag-usap tungkol sa kung paano mo gamitin ang teknolohiyang ito para sa ilang ng application ngayon. At pagkatapos ay namin makipag-usap nang kaunti tungkol sa paglaki o ang paglitaw ng isang bagong tularan sa programming tinatawag na mga aplikasyon kaganapang hinihimok ng at kung paano gumaganap DynamoDB sa na rin. At kami ay umalis sa iyo ng isang maliit na piraso ng isang architecture reference talakayan upang maaari naming makipag-usap tungkol sa ilan sa ang mga paraan na maaari mong gamitin DynamoDB. 

Kaya unang off-- ito ay isang tanong Marinig ko ng maraming ay, kung ano ang isang database. Ang isang pulutong ng mga tao sa tingin nila alam kung ano ang isang database ay. Kung ikaw Google, makikita mo na ito. Ito ay isang isang naka-balangkas na hanay ng mga data na hawak sa isang computer, lalo na ang isa na ay naa-access sa iba't-ibang mga paraan. Ipagpalagay ko na ang isang magandang kahulugan ng isang modernong database. Ngunit hindi ko gusto ito, dahil ay nagpapahiwatig ng isang pares ng mga bagay-bagay. Ito ay nagpapahiwatig ng istraktura. At ito ay nagpapahiwatig na ito ay sa isang computer. At database ay hindi palaging umiiral sa mga computer. Mga Database talagang umiiral sa maraming paraan. 

Kaya ang isang mas mahusay na kahulugan ng isang database ay isang bagay na tulad nito. Ang database ay isang organisado mekanismo para sa pagtatago, pamamahala, at pagkuha ng impormasyon. Ito ay mula sa About.com. Kaya gusto ko ito dahil ito ay talagang pag-uusap tungkol sa isang database sa pagiging isang repository, isang lalagyan ng impormasyon, hindi kinakailangan isang bagay na nakapatong sa isang computer. At sa buong kasaysayan, kami ay hindi laging may mga computer. 

Ngayon, kung tatanungin ko ang average developer ngayon kung ano ang isang database, na ang sagot na nakukuha ko. Sa isang lugar ang maaari kong stick stuff. Right? At ito ay totoo. Ngunit ito ay kapus-palad. Dahil ang mga database ay talagang ang pundasyon ng modernong app. Ito ay ang pundasyon ng bawat application. At kung paano mo magtayo na database, kung paano mo istraktura ang data na iyon ay pagpunta sa utos kung paano na gumaganap application bilang masukat mo. 

Kaya ng maraming ng aking trabaho ngayon ay ang pagharap sa kung ano ang ang mangyayari kapag ang mga developer kumuha ito diskarte at pakikitungo sa mga resulta ng isang application na ay scaling ngayon lampas sa orihinal na layunin at paghihirap mula sa masamang disenyo. Kaya sana kapag ikaw lakarin ang layo sa araw, makikita mo magkaroon ng isang pares ng mga kasangkapan sa iyong sinturon na kailangan panatilihin mo mula sa paggawa ng mga parehong mga pagkakamali. Lahat tama. Kaya sabihin makipag-usap tungkol sa isang maliit na piraso ng ang timeline ng teknolohiya database. Sa tingin ko ko basahin ang isang hindi na matagal na article ago at sinabi ng isang bagay sa lines-- ito ay isang napaka mala-tula statement. Ito ang sinabi ng history ng data processing ay puno ng mataas watermark ng kasaganaan data. SIGE. Ngayon, hulaan ko na ang uri ng tunay. Ngunit ang tunay na ako ay tumingin sa ay bilang ang kasaysayan ay aktwal na napuno na may mataas na antas ng tubig ng presyon data. Dahil ang mga rate ng data ng paglunok hindi napupunta down. Napupunta up lamang ito. 

At pagbabago ay nangyayari kapag nakikita namin na presyon ng data, na kung saan ay ang halaga ng data na ngayon sa darating na sa system. At ito ay hindi maasikaso mahusay sa alinman sa panahon o sa gastos. At na kapag nagsimula kami upang tumingin sa presyon ng data. 

Kaya kapag tinitingnan namin ang mga unang database, ito ay ang isa na ay sa pagitan ng aming mga tainga. Lahat ng Kami ay ipinanganak sa mga ito. Ang ganda ng database. Ito ay may isang mataas na availability. Ito ay palaging on. Maaari mong palaging makakuha ng ito. 

Ngunit ito ay single user. Hindi ko ibahagi ang aking mga saloobin sa iyo. Hindi ka maaaring makakuha ng aking mga saloobin kapag gusto mo ito. At ang kanilang abilitiy ay hindi mabuti. Nakalimutan namin mga bagay-bagay. Tuwing ngayon at pagkatapos, isa sa amin dahon at gumagalaw sa sa isa pang pag-iral at mawala ang namin ang lahat na nasa na database. Kaya na hindi lahat na mabuti. 

At ito ay nagtrabaho rin sa paglipas ng panahon kapag kami ay bumalik sa araw kapag ang lahat ng tunay na kailangan naming malaman ay saan tayo pupunta upang pumunta sa bukas o kung saan kami lumikom ng pinakamahusay na pagkain. Ngunit bilang namin na nagsimula sa paglaki bilang isang kabihasnan at pamahalaan na nagsimula na dumating sa pagiging, at nagsimula sa mga negosyo na nagbabago, namin na nagsimula sa Napagtanto namin kailangan ng kaunti pa kaysa sa kung ano maaari naming ilagay sa aming mga ulo. Lahat tama? 

Kailangan naming ang mga sistema ng mga record. Kailangan naming ang mga lugar upang ma-imbak ng data. Kaya't nagsimula kaming mga dokumento ng pagsulat, paglikha ng mga aklatan at mga archive. Sinimulan namin ang pagbuo ng isang sistema ng isang ledger accounting. At sistemang iyon ng ledger pagbilang bumangga sa mundo para sa maraming siglo, at marahil kahit na millennia bilang namin uri ng lumago hanggang sa punto kung saan daig na load data sa kakayahan ng mga sistema ng para ma-naglalaman ito. 

At ito ang tunay na nangyari sa 1880s. Right? Sa 1880 US Census. Ito ay talagang kung saan ang pagpalit point modernong data processing. Ito ang punto kung na kung saan ang halaga ng data na na nakolekta sa pamamagitan ng Nakakuha gobyerno ng Estados Unidos sa punto kung saan ito kinuha walong taon upang maproseso. 

Ngayon, walong years-- bilang alam mo, ang census Nagpapatakbo bawat 10 years-- kaya medyo maliwanag na sa pamamagitan ng oras namin Nakakuha ang 1890 census, ang dami ng data na ay pagpunta upang ma-process sa pamamagitan ng pamahalaan ay pagpunta sa lampasan ang 10 taon na ito nais kumuha sa inilunsad ang bagong census. Ito ay isang problema. 

Kaya ang isang tao na may pangalang Herman Hollerith ay dumating kasama at siya imbento unit record suntok cards, dating ng card reader, suntok card tabiyuleitor, at ang paghahambing ng ang mga mekanismo para sa teknolohiyang ito. At na kumpanya na siya nabuo sa panahon, kasama ang isang pares ng mga iba, tunay na naging isa sa mga haligi ng isang maliit na kumpanya alam natin ngayon na tinatawag na IBM. 

Kaya IBM orihinal ay sa ang database ng negosyo. At na talaga kung ano ang kanilang ginawa. Ginawa nila pagpoproseso ng data. 

Bilang kaya ang paglaganap ng suntok cards, isang mapanlikha mekanismo ng pagiging able sa pagkilos na technology sa poll pinagsunod-sunod na mga hanay ng mga resulta. Maaari mong makita sa larawan na ito doon kami ay may isang little-- ito ay isang maliit small-- ngunit maaari mong makita isang napaka mapanlikha mekanismo ng makina kung saan mayroon kaming isang suntok card deck. At pagkuha ng isang tao isang maliit na birador at nananatili sa pamamagitan ng slot at pag-aangat up ito upang makakuha ng na tumutugma, na itakda pinagsunod-sunod ng mga resulta. 

Ito ay isang pagsasama-sama. Ginagawa namin ito sa lahat ng oras ngayon sa mga computer, kung saan mo ito sa database. Ginamit namin upang gawin ito nang manu-mano, di ba? Mga tao na ilagay ang mga bagay na sama-sama. At ito ay ang paglaganap sa mga dating ng mga card sa kung ano ang tinatawag naming drums data at reels data, paper tape. 

Kinuha ang industriya ng pagpoproseso ng data isang aralin mula sa mga piano player. Piano pabalik Player sa ang turn ng siglo ginagamit upang gamitin ang papel reels na may mga puwang sa upang sabihin dito kung aling mga key upang i-play. Kaya na teknolohiya ay iniangkop huli sa tindahan ng mga digital na data, dahil maaari nilang ilagay ang data na iyon papunta sa mga paper tape reels. 

Ngayon, bilang isang resulta, ang data ay actually-- paano na-access mo ang data na ito nang direkta ay nakasalalay sa kung paano mo na naka-imbak sa mga ito. Kaya kung ko bang ilagay ang data sa isang tape, Ako ay ma-access ang data nang linear. Ako ay upang pagulungin ang buong tape upang ma-access ang lahat ng mga data. Kung ko bang ilagay ang data sa suntok cards, maaari ko ma-access ito sa isang maliit na mas random fashion, marahil hindi bilang mabilis. 

Ngunit may mga limitasyon sa kung paano namin pag-access sa data batay sa kung paano ay naka-imbak. At kaya ito ay isang problema pagpunta sa '50s. Muli, maaari naming simulan upang makita na bilang namin bumuo ng mga bagong teknolohiya upang i-proseso ang data, kanan, ito ay bubukas up ang pinto para sa mga bagong solusyon, para sa mga bagong programa, ang mga bagong aplikasyon para sa data na iyon. At talagang, pamamahala maaaring ang dahilan kung bakit namin binuo ang ilan sa mga sistema. Ngunit mabilis na naging negosyo ang driver sa likod ng ebolusyon ng modernong database at modernong file system. 

Kaya ang susunod na bagay na dumating up ay sa '50s ay ang file system at ang pag-unlad ng random storage access. Ito ay maganda. Ngayon, ang lahat ng mga biglaang, maaari naming ilagay ang aming file sa kahit saan sa mga hard drive at maaari naming ma-access nang sapalaran ang data na ito. Maaari naming i-parse na impormasyon sa labas ng mga file. At nalutas namin ang lahat ng mundo ni problema sa pagpoproseso ng data. 

At na tumagal tungkol sa 20 o 30 taon hanggang sa paglaki ng pamanggit database, na kung saan ay kapag nagpasya kami ngayon sa mundo kailangang magkaroon ng isang lalagyan na pagkatalo mga paligid ng lungsod ng data sa kabuuan ng file sistema na nakagawa kami. Right? Masyadong maraming data na ibinahagi sa masyadong maraming lugar, ang mga de-pagkopya ng data, at ang gastos ng imbakan ay napakalubha. 

Sa '70s, ang pinakamahal na mapagkukunan na ang isang computer ay ay ang storage. Ang processor ay tiningnan bilang isang takdang halaga. Kapag bumili ako ng kahon, ang CPU ay ang ilang mga trabaho. Ito ay pagpunta sa umiikot kung tunay na ito ay gumagana o hindi. Iyan ay tunay na isang mas mababa gastos. 

Ngunit kung ano ang halaga sa akin bilang negosyo ay storage. Kung kailangan kong bumili ng higit pang mga disk susunod buwan, na ang isang tunay na gastos na babayaran ko. At imbakan na mahal. 

Ngayon fast forward 40 taon namin at kami ay may isang iba't ibang mga problema. Compute Ang ngayon ay ang pinaka mahal na mapagkukunan. Storage ay mura. Ibig kong sabihin, maaari naming pumunta sa kahit saan sa ulap at maaari naming mahanap ang cheap storage. Ngunit kung ano ang hindi ko mahanap ang murang compute. 

Kaya ang paglaki ng ngayong araw teknolohiya, ng teknolohiya database, ay talagang nakatuon sa paligid ipinamamahagi database na hindi magtiis sa ang parehong uri ng scale limitasyon ng pamanggit database. Susubukan naming makipag-usap nang kaunti tungkol sa kung ano na ang tunay na ibig sabihin. 

Ngunit isa sa mga dahilan at ang driver sa likod this-- namin usapan tungkol sa presyon ng data. Presyon ng Data ay isang bagay na na nag-mamaneho sa pagbabago. At kung titingnan mo sa paglipas ng sa huling limang taon, ito ay isang tsart ng kung ano ang data load sa buong pangkalahatang enterprise Mukhang sa huling limang taon. 

At ang mga pangkalahatang patakaran ng hinlalaki mga days-- kung pumunta ka Google-- ay 90% ng data na tindahan namin ngayon, at ito ay nabuo sa loob ng nakaraang dalawang taon. SIGE. Ngayon, ito ay hindi isang trend na ang bago. Ito ay isang trend na ang nangyaring pagpunta sa labas para sa 100 taon. Mula pa nang Herman Hollerith binuo ang dating ng card, Na-pagbuo namin repositoryo data at pagtitipon ng data sa mga kahanga-hanga rate. 

Kaya sa nakaraang 100 taon, nakakita kami ng lakad na ito. Iyan ay hindi pagpunta sa pagbabago. Pasulong, kami ay pagpunta upang makita ang ito, kung hindi isang pinabilis na trend. At maaari mong makita kung ano na kamukha. 

Kung ang isang negosyo noong 2010 ay nagkaroon ng isa terabyte ng data sa ilalim ng pamamahala, sa araw na iyon ay nangangahulugan na ang mga ito pamamahala 6.5 petabytes ng data. Iyan ay 6,500 beses na mas maraming data. At alam ko na ito. Ako ng trabaho sa mga negosyo sa bawat araw. Limang taon ang nakaraan, ako ay makipag-usap sa mga kumpanya na nais makipag-usap sa akin tungkol sa kung ano ang isang sakit ito ay upang pamahalaan terabytes ng data. At ang mga ito ay makipag-usap sa akin tungkol sa kung paano namin makita na ito ay marahil pagpunta upang maging isang petabyte o dalawang sa loob ng ilang taon. 

Ang mga kompanya ng ngayon ako pagtugon sa, at sila ay pakikipag-usap sa akin tungkol sa mga Ang problema ay may pagkakaroon ng pamamahala sampu, 20 petabytes ng data. Kaya ang pagsabog ng data sa industriya ang nagtutulak sa mga napakalaking kailangan para sa mas mahusay na solusyon. At ang pamanggit database ay hindi lamang ang buhay hanggang sa ang demand. 

At kaya may isang linear ugnayan sa pagitan ng presyon ng data at teknikal na pagbabago. Kasaysayan ay ipinapakita sa amin na ito, na sa paglipas ng panahon, kapag ang dami ng data na na mga pangangailangan upang ma-process lumampas sa kapasidad ng sistema upang i-proseso ang mga ito sa isang makatwirang panahon o sa isang makatwirang gastos, pagkatapos ay ang mga bagong teknolohiya ay imbento upang malutas ang mga problema. Ang mga bagong teknolohiya, naman, buksan ang pinto sa isa pang hanay ng mga problema, na kung saan ay pagtitipon ng mas maraming data. 

Ngayon, hindi namin pagpunta upang ihinto ito. Right? Hindi namin pagpunta upang ihinto ito. Bakit? Dahil hindi ka maaaring malaman ang lahat doon ay upang malaman sa uniberso. At hangga't kami ay buhay, sa buong kasaysayan ng tao, palagi naming hinihimok na malaman pa. 

Kaya ito ay tila sa bawat inch ilipat namin down ang landas ng pagkatuklas sa agham, ay multiply namin ang dami ng data na kailangan namin upang i-proseso exponentially bilang alisan ng takip kami ng higit pa at sa mga tungkol sa loob workings ng buhay, tungkol sa kung paano gumagana ang daigdig, tungkol sa na nagtutulak ng mga pagkatuklas sa agham, at ang mga likha na ang aming ginagawa ngayon. Ang dami ng data lamang patuloy na tataas. Kaya ang pagiging able sa pakikitungo sa ang problemang ito ay napakalubha. 

Kaya isa sa mga bagay-bagay inaabangan namin ang bilang kung bakit NoSQL? Paano gumagana NoSQL malutas ang problemang ito? Well, pamanggit database, Nakabalangkas na Query Wika, SQL-- na talagang isang bumuo ng database-- pamanggit mga bagay na ito optimize para sa imbakan. 

Bumalik sa '70s, muli, disk ay magastos. Ang provisioning exercise ng imbakan sa enterprise ay walang katapusan. Alam ko. Ako ay nakatira dito. Sinulat ko ang driver na imbakan para sa isang Enterprised superserver kumpanya bumalik sa '90s. At ang bottom line ay napakasakit isa pang imbakan array ay lamang ng isang bagay na ang nangyari sa bawat araw sa enterprise. At ito ay hindi kailanman tumigil. Mas mataas na density ng imbakan, demand para sa mataas na storage density, at para sa mas mahusay na imbakan devices-- ito ay hindi kailanman tumigil. 

At NoSQL ay isang mahusay na teknolohiya dahil ito normalizes ang data. Ito de-duplicate ang data. Inilalagay nito ang data sa isang istraktura na ay agnostic sa bawat pattern access. Maaaring hit Maramihang mga application na SQL database, patakbuhin ad hoc query, at makakuha ng data sa hugis na sila kailangan sa proseso para sa kanilang mga workloads. Na tunog hindi kapani-paniwala. Ngunit sa ilalim na linya ay may anumang system, kung ito ay agnostiko sa lahat ng bagay, ito ay na-optimize para sa wala. SIGE? 

At iyon ang makuha namin sa ang pamanggit database. Ito ay na-optimize para sa imbakan. Ito ay naging normal. Ito ay pamanggit. Ito ay sumusuporta sa mga query sa pangyayaring ito. At ito at ito kaliskis patayo. 

Kung kailangan ko upang makakuha ng isang mas malaking database SQL o ng isang mas malakas na database SQL, Pumunta ako bumili ng mas malaking piraso ng bakal. SIGE? Nagtrabaho ako sa isang pulutong ng mga customer na sa pamamagitan ng malaking upgrade sa kanilang imprastraktura SQL lamang upang malaman ang anim na buwan, sila ay pagpindot muli sa pader. At ang sagot mula sa Oracle o MSSQL o kahit sinong tao ay makakuha ng isang mas malaking box. Well maaga o huli, hindi ka maaaring bumili ng isang mas malaking box, at iyon ang tunay na problema. Kailangan namin na talagang baguhin ang mga bagay. Kaya kung saan ito gumagana? Ito ay mahusay na gumagana para sa offline analytics, OLAP-type workloads. At iyan ay talagang kung saan nabibilang SQL. Ngayon, ito ay ginagamit ngayon sa maraming online transactional processing-type aplikasyon. At ito ay gumagana lamang multa sa ilang mga antas ng paggamit, ngunit ito lamang ay hindi scale ang paraan na gumagana ang NoSQL. At kami ay makipag-usap sa isang maliit na kaunti tungkol sa kung bakit na. 

Ngayon, NoSQL, sa kabilang banda, ay mas na-optimize para compute. SIGE? Ito ay hindi agnostic sa ang access pattern. Ay kung ano ang tawag namin sa de-normalize istraktura o ng isang hierarchical istraktura. Ang data sa isang pamanggit database ay nagsama-sama mula sa maramihang mga talahanayan upang makabuo ng mga pananaw na kailangan mo. Ang data sa isang NoSQL database ay naka-imbak sa isang dokumento na naglalaman ng mga hierarchical istraktura. Ang lahat ng mga data na normal na nagsama-sama upang makabuo ng pananaw na ay naka-imbak sa isang solong dokumento. At kami na makipag-usap nang kaunti tungkol sa paano na gumagana sa loob ng ilang mga chart. 

Ngunit ang ideya dito ay na-imbak mo ang iyong data bilang mga instantiated views. SIGE? Masukat mo horizontally. Right? Kung kailangan ko upang dagdagan ang laki ng aking NoSQL kumpol, Hindi ko na kailangan upang makakuha ng isang mas malaking box. Makakuha ako ng isa pang box. At kumpol ko ang mga sama-sama, at maaari ba akong Shard na data. Susubukan naming makipag-usap ng kaunti tungkol sa ano sharding ay, upang maging ma-scale na database sa kabuuan ng maramihang mga pisikal na device at alisin ang mga hadlang na nangangailangan ako sa scale patayo. 

Kaya ito ay tunay na binuo para sa mga online pagproseso ng transaksyon at scale. May isang malaking pagkakaiba dito sa pagitan ng pag-uulat, right? Pag-uulat, hindi ko alam ang tanong ako ng pagpunta sa magtanong. Right? Reporting-- kung ang isang tao mula aking marketing department gustong just-- kung ilan sa aking mga customer na ito ay may mga partikular na katangian na bumili sa mga ito day-- Hindi ko alam kung ano ang query ang kanilang pagpunta sa magtanong. Kaya kailangan kong maging agnostiko. 

Ngayon, sa isang online transactional application, Alam ko kung ano mga tanong ako nagtatanong. Ako na binuo ng application para sa isang napaka-tukoy na workflow. SIGE? Kaya kung io-optimize ang data imbak sa suporta na workflow, ito ay magiging mas mabilis. At iyon ang dahilan kung bakit NoSQL Maaari talagang mapabilis ang paghahatid sa mga uri ng mga serbisyo. Lahat tama. 

Kaya kami ay pagpunta upang makakuha ng sa isang maliit na piraso ng theory dito. At ang ilan sa inyo, ang inyong mga mata maaaring ibalik ang isang maliit na bit. Ngunit kukunin ko na subukan upang panatilihin ito bilang ng mataas na antas ng aking makakaya. Kaya't kung ikaw ay nasa mga proyekto pamamahala, may isang tayuan tinatawag na ang tatsulok ng limitasyon. SIGE. Ang tatsulok ng constrains atas Hindi ka maaaring magkaroon ng lahat ng oras sa lahat ng bagay. Hindi maaaring magkaroon ng iyong pie at kumain ito masyadong. Kaya sa pamamahala ng proyekto, na tatsulok limitasyon ay maaari mong makuha ito murang, maaari kang magkaroon ng mga ito nang mabilis, o maaari mong makuha ito ng mabuti. Pumili ng dalawang. Dahil hindi ka maaaring magkaroon ng lahat ng tatlong. Right? SIGE. 

Kaya maririnig mo tungkol sa mga ito ng isang pulutong. Ito ay isang triple sapilitan, tatsulok ng triple sapilitan, o ang bakal tatsulok ay oftentimes-- kapag kinakausap mo ang mga tagapamahala ng proyekto, ang mga ito ay makipag-usap tungkol sa mga ito. Ngayon, database ay may kanilang sariling mga bakal na tatsulok. At ang mga bakal tatsulok ng data ay kung ano ang tawag namin sa Cap teorama. SIGE? 

Cap theorem atas paano database gumana sa ilalim ng isang tiyak na takdang kalagayan. At kami ay makipag-usap tungkol kung ano ang kalagayan ay. Ngunit ang tatlong punto ng tatsulok, wika nga, ay C, pabago-bago. SIGE? Kaya sa Cap, pare-pareho ay nangangahulugan na ang lahat kliyente na maaaring ma-access ang database ay laging magkaroon ng isang napaka pare-pareho na view ng data. Gonna ninuman makita ang dalawang magkaibang mga bagay. SIGE? Kung nakikita ko ang mga database, Nakakakita ako ng parehong view bilang aking partner kung sino ang nakakakita ang parehong database. Iyan ay pare-pareho. 

Availability nangangahulugan na kung ang database online, kung maaari itong mapupuntahan, na ang lahat ng mga kliyente ay palaging maaaring magbasa at magsulat. SIGE? Kaya ang bawat client na maaaring basahin ang mga database ay palaging ma read data at isulat ang data. At kung iyon ang kaso, ito ay isang magagamit na system. 

At ang ikatlong punto ay kung ano ang ang tawag namin sa partition tolerance. SIGE? Tolerance Partition paraan na ang sistema ay gumagana ng mabuti sa kabila ng pisikal na network partisyon sa pagitan ng nodes. SIGE? Kaya nodes sa kumpol ay maaaring hindi makipag-usap sa bawat isa, ano ang mangyayari? Lahat tama. 

Database So pamanggit choose-- maaari kang pumili ng dalawang ng mga ito. SIGE. Database So pamanggit piliin upang maging pare-pareho at available. Kung nangyari ang pagkahati sa pagitan ng ang DataNodes sa tindahan ng data, ang database nag-crash. Right? Napupunta down Ito lamang. SIGE. 

At ito ang dahilan kung bakit sila ay may na lalaki sa mas malaking box. Right? Dahil mayroong no-- kadalasan, isang kumpol database, may hindi masyadong marami sa kanila na gumana na paraan. Subalit ang karamihan sa mga database masukat patayo sa loob ng iisang kahon. Dahil kailangan nila upang maging pare-pareho at available. Kung ang isang partition ay na iturok, pagkatapos ay kailangan mong gumawa ng isang pagpipilian. Kailangan ninyong gumawa ng isang pagpipilian sa pagitan pagiging pare-pareho at magagamit. 

At na kung ano NoSQL database gawin. Lahat tama. Kaya ang isang NoSQL database, ito lumapit sa dalawang flavors. Have-- Kami rin, ito ay dumating sa maraming flavors, ngunit ito ay may dalawang pangunahing characteristics-- ano gusto naming tumawag database CP, o isang pare-pareho at partition tolerance system. Ang mga guys gawin ang mga pagpipilian na kapag ang nodes mawalan ng contact sa bawat isa, hindi namin pagpunta upang payagan mga tao na magsulat sa anumang iba pa. SIGE? 

Hanggang sa na partition ay tinanggal, write access ay hinarangan. Iyon ay nangangahulugang ang mga ito ay hindi magagamit. Ang mga ito ay pare-pareho. Kapag nakita namin na pagkahati-iniksyon mismo, na kami ngayon pare-pareho, dahil hindi namin pagpunta upang payagan ang mga pagbabago sa data sa dalawang panig ng partition malaya ng bawat isa. Kami ay may sa muling ibalik ang komunikasyon bago ng anumang mga update sa ang data ay pinapayagan. SIGE? 

Ang susunod na lasa ay magiging isang AP system, o ang magagamit at partitioned tolerance system. Ang mga guys ay hindi na mahalaga. Right? Anumang node na nakukuha ng isang magsulat, kami ay kumuha ng mga ito. Kaya ako Kinokopya ang aking data sa kabuuan ng maramihang nodes. Makakuha ng mga nodes sa isang client, dumating client in, sabi, ako pagpunta sa sumulat ng ilang data. Node sabi, walang problema. Node Ang susunod sa kanya ay makakakuha ng isang sumulat sa parehong record, siya ay pagpunta sa sabihin walang problema. Sa isang lugar sa likod sa likod ng pagtatapos, ang data na iyon ay pagpunta sa magtiklop. At pagkatapos ay isang tao ay pagpunta sa mapagtanto, uh-oh, ikaw ay mapagtanto nila system, uh-oh, mayroong nangyaring isang update sa dalawang gilid. Ano ang gagawin namin? At ano pagkatapos ng ginagawa nila ay gawin nila ang isang bagay na ay nagbibigay-daan sa kanila upang malutas na ang estado ng data. At kami ay makipag-usap tungkol na sa susunod na chart. 

Bagay na ituro dito. At hindi ako pagpunta upang makakuha ng masyadong marami sa mga ito, dahil ito makakakuha ng sa malalim na teorya data. Subalit mayroong isang transactional framework na ay tumatakbo sa isang sistema ng pamanggit na ay nagbibigay-daan sa akin na ligtas na gumawa ng mga update sa maramihang mga nilalang sa database. At ang mga update ay magaganap nang sabay-sabay o hindi sa lahat. At ito ay tinatawag na acid transaksyon. SIGE? 

Acid ay nagbibigay sa amin atomicity, pagbabago, paghihiwalay, at tibay. SIGE? Iyon ay nangangahulugang ang atomic, transaksyon, ang lahat ng ang aking mga update ng alinman mangyari o hindi sila. Pare-pareho ay nangangahulugan na ang database ay palaging nagdala sa isang pare-pareho estado pagkatapos ng isang update. Hindi kita iiwan sa database sa isang masamang kalagayan pagkatapos ng paglalapat ng isang update. SIGE? 

Kaya ito ay isang maliit na naiiba kaysa sa Cap-pareho. Cap-pareho ang ibig sabihin ng lahat ng aking kliyente ay maaaring palaging makita ang data. Acid-pareho ay nangangahulugan na kapag isang transaksyon ay tapos na, ang data ng mabuti. Aking relasyon ay ang lahat ng mabuti. Hindi ako pupunta upang tanggalin ang isang magulang row at mag-iwan ng isang bungkos ng mga ulila anak sa ibang table. Hindi ito maaaring mangyari kung hindi ako pare-pareho sa isang asido transaksyon. 

Paghihiwalay ay nangangahulugan na ang mga transaksyon ay palaging nangyari ang isa pagkatapos ng isa. Ang huling resulta ng data ay ang parehong estado bilang kung ang mga transaksyon na inisyu concurrently ay pinaandar tinatanggap. Kaya ito ay concurrency control sa database. Kaya talaga, Hindi ko ma-dagdagan ang parehong halaga ng dalawang beses sa dalawang operasyon. 

Ngunit kung sabihin ko magdagdag ng 1 sa halaga na ito, at dumating sa dalawang mga transaksyon at subukan na gawin ito, ang isa ay pagpunta sa makarating doon muna at ang iba pang isa pagpunta sa makarating doon matapos. Kaya sa katapusan, nagdagdag ako ng dalawa. Makikita mo kung ano ang ibig sabihin ko? SIGE. 

Tibay ay medyo direkta. Kapag ang transaksyon ay kinikilala, ito ay pagpunta sa maging kahit doon kung nag-crash ang system. Kapag recovers system na, na transaksyon na ipinamahala ay tunay na pagpunta sa maging doon. Kaya na ang mga garantiya ng acid transaksyon. Ang mga ay pretty nice garantiya upang magkaroon sa isang database, ngunit sila ay dumating sa na gastos. Right? 

Dahil ang problema sa balangkas na ito ay kung mayroong isang pagkahati sa data set, kailangan kong gumawa ng isang desisyon. Pupunta ako sa may upang payagan update sa isang bahagi o sa iba. At kung nangyari iyon, pagkatapos ay hindi na pagpunta ako upang ma-maintain mga katangian. Hindi sila ay pare-pareho. Hindi sila ay ihiwalay. Ito ay kung saan ito Pinaghihiwa-hiwalay para sa pamanggit database. Ito ang dahilan kung pamanggit database masukat patayo. 

Sa kabilang banda, mayroon kaming ano ang tinatawag na teknolohiya BASE. At ito ay ang iyong NoSQL Database. Lahat tama. Kaya na namin ang aming CP, AP database. At ang mga ito ay kung ano ang tawag mo talaga magagamit, soft estado, sa huli pare-pareho. SIGE? 

Karaniwang magagamit, dahil ang mga ito ay partition mapagparaya. Sila ay palaging magiging doon, kahit na may isang partition network sa pagitan ng nodes. Kung ang maaari kong makipag-usap sa isang node, ako pagpunta sa magagawang upang basahin ang data. SIGE? Baka ako hindi palaging ma-isulat data kung ako ay isang pare-pareho platform. Ngunit kailangan ma-basahin ang data ko. 

Ipinahihiwatig ng soft estado na kapag ako basahin na data, maaaring hindi ito katulad ng iba pang mga node. Kung ang isang karapatan ay inisyu sa isang node sa ibang lugar sa cluster at ito ay hindi kinokopya sa buong cluster pa kapag ako basahin na data, Maaaring hindi maging pare-pareho na estado. Gayunman, ito ay huli pare-pareho, ibig sabihin na kapag ang isang write ay ginawa sa sistema, ito ay magtiklop buong nodes. At sa huli, na ang estado ay nagdala sa order, at ito ay isang pare-pareho ng estado. 

Ngayon, Cap theorem talagang gumaganap lamang sa isang kundisyon. Kondisyon na ito ay kapag nangyari ito. Dahil kapag ito ay operating sa normal mode, walang partisyon, lahat ng bagay ay pare-pareho at available. Mag-alala ka lamang tungkol sa Cap kapag kami ay may na partition. Kaya ang mga ay bukod-tangi. Ngunit kung ano ang reaksiyon sistema kapag ang mga mangyari utos kung ano ang uri ng sistema kami ay pagharap sa. 

Kaya sabihin kumuha ng isang pagtingin sa kung ano na ganito ang hitsura para sa AP systems. SIGE? Systems AP dumating sa dalawang flavors. Sila ay dumating sa lasa na ay isang master master, 100%, palaging magagamit. At sila ay dumating sa iba pang mga lasa, na nagsasabing, alam mo kung ano, ako pagpunta sa mag-alala tungkol sa partitioning bagay kapag naganap ang isang aktwal na partition. Kung hindi man, may pagpunta sa maging pangunahing nodes sino ang pagpunta sa gawin ang mga karapatan. SIGE? 

Kaya kung namin ang isang bagay tulad ng Cassandra. Cassandra ay isang master master, sabihin ay sa akin magsulat sa anumang node. Kaya kung ano ang mangyayari? Kaya ko ng isang bagay sa database na umiiral sa dalawang nodes. Sabihin tumawag na object S. Kaya kami ng estado para sa S. Mayroon kaming ilang mga operasyon sa S na ay patuloy. Ay nagbibigay-daan sa akin Cassandra sa sumulat sa maramihang nodes. Kaya sabihin nating kumuha ako ng isang isulat para s dalawang nodes. Well, kung ano ang nagtatapos up nangyayari ay ang tawag namin na ang isang kaganapan partitioning. May hindi maaaring maging isang pisikal na pagkahati network. Ngunit dahil sa ang disenyo ng sistema, ito ay talagang partisyon sa lalong madaling makakuha ako ng isang write sa dalawang nodes. Ito ay hindi sapilitan kong isulat ang lahat sa pamamagitan ng isang node. Sumulat ako sa dalawang nodes. SIGE? 

Kaya ngayon mayroon akong dalawang mga katayuan. SIGE? Ano kaya ang mangyari ay maaga o huli, may pagpunta sa maging isang kaganapan pagtitiklop. May pupuntahan maging kung ano tayo tinatawag na isang partition recovery, na kung saan ay kung saan ang dalawang states bumalik magkasama at doon ay magiging isang algorithm na tumatakbo sa loob ng database, nagpapasya kung ano ang gagawin. SIGE? Sa pamamagitan ng default, huling update nanalo sa karamihan ng mga sistema ng AP. Kaya mayroong karaniwang isang default algorithm, kung ano sila tumawag ng callback function, isang bagay na ay tinatawag na kapag ang kundisyong ito ay nakita upang magsagawa ng ilang lohika upang malutas na conflict. SIGE? Ang default na callback at default resolver sa karamihan ng mga database AP ay, hulaan kung ano, timestamp na panalo. Ito ay ang huling update. Pupunta ako upang ilagay ang update na sa doon. Maaari ko tambakan ng basura ang ulat na ito na aking itinapon off sa isang log sa pagbawi kaya na maaaring bumalik sa paggamit sa ibang pagkakataon at sabihin, hey, nagkaroon ng isang banggaan. Anong nangyari? At maaari mong aktwal na tambakan ng isang talaan ng mga lahat ng mga banggaan at ang rollbacks at makita kung ano ang mangyayari. 

Ngayon, bilang isang user, maaari mo ring isama ang logic sa na callback. Kaya maaari mong baguhin na callback operasyon. Maaari mong sabihin, hey, gusto kong muling mamamagitan ang data na ito. At gusto kong subukan at pagsamahin ang dalawang mga tala sa mga iyon. Ngunit iyon lamang ang nasa sa iyo. Ang database ay hindi alam kung paano gawin na sa pamamagitan ng default. Karamihan sa mga oras, ang tanging bagay na ang mga database nakakaalam kung paano gawin ay sabihin, ang isang ito ay ang huling record. Iyon ang isa na ang pagpunta sa manalo, at na ang halaga Pupunta ako sa ilagay. Kapag na partition recovery at pagtitiklop nangyayari, na namin ang aming estado, na ay ang S ngayon prime, na kung saan ay ang estado merge ng lahat ng mga bagay. Kaya systems AP mayroon ito. CP sistema ay hindi kailangan mag-alala tungkol sa mga ito. Dahil sa lalong madaling isang partition ay dumating sa pag-play, stop lang nila ang pagkuha nagsusulat. SIGE? Kaya na ay napakadaling pakikitungo sa pagiging pare-pareho kapag hindi mo tatanggapin ang anumang mga update. Iyan ay may gawin CP systems. Lahat tama. 

Kaya sabihin makipag-usap sa isang maliit na bit tungkol sa mga pattern access. Kapag ang usapan namin tungkol NoSQL, ito ay lahat ng tungkol sa pag-access pattern. Ngayon, SQL ay ad hoc, queries. Ito ay pamanggit store. Hindi namin kailangang mag-alala tungkol sa pag-access pattern. Sumulat ako ng isang napaka-komplikadong query. Ito napupunta at makakakuha ng data. Iyon ay kung ano ang mukhang tulad ng, normalization. 

Kaya sa partikular na istraktura, kami ay naghahanap sa isang catalog ng mga produkto. Mayroon akong iba't ibang uri ng produkto. Mayroon akong mga libro. Mayroon akong mga album. Mayroon akong mga video. Ang relasyon sa pagitan ng mga produkto at ang anumang isa sa mga libro, album, at mga video talahanayan ay 1: 1. Lahat tama? Mayroon akong isang ID ng produkto, at na tumutugma ID sa isang libro, isang album, o isang video. SIGE? Iyan ay isang 1: 1 na relasyon sa kabuuan ng mga tables. 

Ngayon, books-- lahat sila Mayroon ay root properties. Walang problema. Mabuti iyan. One-sa-isang relasyon, nakukuha ko lahat ng ang data na kailangan ko upang ilarawan ang librong iyon. Albums-- album ay may mga track. Ito ay kung ano ang tawag namin sa isa sa maraming. Bawat album ay maaaring magkaroon ng maraming mga track. Kaya para sa bawat track sa ang album, maaari ba akong magkaroon isa pang record sa batang ito table. Kaya ako gumawa ng isang tala sa aking mga talahanayan album. Gumawa ako ng maraming mga talaan sa talahanayan ng mga track. One-sa-maraming relasyon. 

Relasyon na ito ay kung ano ang ang tawag namin sa many-to-maraming. SIGE? Ang makikita mo na aktor ay maaaring sa maraming mga pelikula, maraming mga video. Kaya kung ano ang ginagawa namin ay namin ilagay ito mapping mesa sa pagitan ng mga, na kung saan ito lamang mga mapa ang mga artista ID sa video ID. Ngayon ay maaari kong lumikha ng isang query sa pagsali mga video sa pamamagitan ng aktor video na aktor, at ito ay nagbibigay sa akin ng isang magandang listahan ng mga ang lahat ng mga pelikula at lahat ng mga aktor na nasa na movie. 

SIGE. Kaya dito namin pumunta. One-to-one ay ang top-level relasyon; isa-sa-marami, mga album sa mga track; maraming-sa-marami. Ang mga ay ang tatlong nangungunang antas relasyon sa anumang database. Kung alam mo kung paano ang mga relasyon magtulungan, pagkatapos ay alam mo ng maraming tungkol sa database na. Kaya NoSQL gumagana ng kaunti naiiba. Isipin ang tungkol para sa isang segundo kung ano ito hitsura tulad ng upang pumunta makakuha ng lahat ng aking mga produkto. 

Sa isang pamanggit store, ako nais na makakuha ng lahat ng aking mga produkto sa isang listahan ng lahat ng aking mga produkto. Iyan ay isang pulutong ng mga query. Nakakuha ako ng isang query para sa lahat ng aking mga libro. Nakakuha ako ng isang query mula sa aking mga album. At Nakakuha ako ng isang query para sa lahat ng aking mga video. At nakuha ko upang ilagay ito lahat ng sama-sama sa isang listahan at maglingkod ito back up sa application na humihiling ito. 

Upang makakuha ng mga libro ko, sumali ako Mga Produkto at Books. Upang makakuha ng aking mga album, ang nakuha ko upang sumali Products, Albums, at Tracks. At upang makakuha ng aking mga video, mayroon akong upang sumali mga Produkto sa video, sumali sa pamamagitan ng artista Videos, at dalhin sa aktor. Kaya na ang tatlong tanong. Napaka kumplikadong mga query na magtipon ng isang set na resulta. 

Iyon ay mas mababa kaysa optimal. Ito ay kung bakit kapag ang usapan namin tungkol sa isang istraktura ng data na itinayo upang maging agnostic sa access pattern-- rin na malaki. At maaari mong makita na ito ay talagang maganda kung paano namin inayos na ang data. At alam mo kung ano? Isa lang ang aking record para sa isang artista. 

Iyan ay cool. Deduplicated ko na ang lahat ng aking mga aktor, at pinananatili ko ang aking mga asosasyon sa talahanayan ng pagmamapa. Gayunman, ang pagkuha ng data out nagiging mahal. Ako ipadala ang CPU sa buong sistema pagsali sa mga istruktura ng data nang sama-sama para ma-pull na bumalik data. 

Kaya paano ako makakakuha ng paligid na? Sa NoSQL ito ay tungkol sa pagsasama-sama, hindi normalization. Kaya gusto naming sabihin na gusto naming suportahan ang access pattern. Kung ang access pattern sa mga application, Kailangan ko upang makakuha ng lahat ng aking mga produkto. Maglagay ng lahat ng mga produkto sa isang mesa. Kung ko bang ilagay ang lahat ng mga produkto sa isang table, Maaari ko lang piliin ang lahat ng mga produkto mula sa mesa at kumuha ako ng lahat ng ito. Well paano ko gawin iyon? Well in NoSQL walang istraktura sa mga table. Susubukan naming makipag-usap nang kaunti tungkol sa paano ito gumagana sa Dynamo DB. Ngunit hindi mo na magkaroon ng parehong mga katangian at ng parehong mga katangian sa bawat isang hilera, sa bawat solong item, tulad ng gagawin mo sa isang SQL table. At kung ano ang nagbibigay-daan sa akin gawin ay isang pulutong ng mga bagay-bagay at magbigay sa akin ng isang pulutong ng flexibility. Sa partikular na kasong, ako ang aking mga dokumento produkto. At sa mga partikular na Halimbawa, ang lahat ng bagay ay isang dokumento sa talahanayan ng Mga Produkto. At ang produkto para sa isang libro baka magkaroon ng isang uri ng ID na tumutukoy ng isang libro. At ang mga application ay lumipat sa ID na. 

Sa tier application, pupuntahan ko sabihin o, anong uri ng talaan ito? Oh, ito ay isang record book. Talaan Book ay may mga ari-arian. Hayaan akong lumikha ng isang bagay na libro. Kaya ako pagpunta upang punan ang book object sa item na ito. Susunod na item ay dumating at sabi, kung ano ang item na ito? Well item na ito ay isang album. Oh, Nakatanggap ako ng isang buong iba't ibang processing routine para sa na, dahil sa ito ay isang album. Makikita mo kung ano ang ibig sabihin ko? 

Kaya ang application tier-- ko piliin lamang ang lahat ng mga talaan. Lahat sila ay simulan ang pagdating sa. Sila ay maaaring maging lahat ng iba't ibang mga uri. At ito ay logic ng application na switch sa kabuuan ng mga uri at nagpapasya kung paano i-proseso ang mga ito. 

Muli, kaya kami ay pag-optimize ang schema para sa access pattern. Ginagawa namin ito sa pamamagitan ng collapsing mga tables. Kami talaga ay pagkuha mga naging normal na kaayusan, at kami ay gusali hierarchical na kaayusan. Sa loob ng bawat isa sa mga talang ito Pupunta ako upang makita ang mga ari-arian array. 

Inside ang dokumentong ito para sa Albums, Nakakakita ako ng mga array ng mga track. Ang mga track sa ngayon become-- ito ay talaga ito bata table na umiiral dito mismo sa structure na ito. Kaya maaari mong gawin ito sa DynamoDB. Maaari mo itong gawin sa MongoDB. Maaari mong gawin ito sa anumang NoSQL database. Lumikha ng ganitong mga uri ng hierarchical istruktura ng data na nagpapahintulot sa iyo na makuha ang data masyadong mabilis dahil ngayon ko Hindi mo na kailangang tumalima. Kapag ako magpasok ng isang hilera sa mga Tracks mesa, o ng isang hilera sa talahanayan Albums, Kailangan ko bang sumunod sa panukala. Mayroon akong magkaroon ang katangian o ang ari-arian na tinukoy sa table na. Bawat isa sa kanila, kapag ipasok ko na hilera. Iyan ay hindi ang kaso sa NoSQL. 

Maaari ba akong magkaroon ganap na kakaiba mga katangian sa bawat dokumento na ako ipasok sa koleksyon. Kaya napaka malakas na mekanismo. At ito ay talagang kung paano mo i-optimize ang sistema. Dahil ngayon na query, sa halip ng pagsali sa lahat ng mga talahanayan at Isinasagawa ng isang kalahating dosenang mga query upang hilahin pabalik ang data na kailangan ko, Ako Isinasagawa isa query. At ako iterating sa kabila ng mga resulta set. ito ay nagbibigay sa iyo ng isang ideya ng kapangyarihan ng NoSQL. Pupunta ako sa uri ng pumunta patagilid dito at makipag-usap nang kaunti tungkol sa mga ito. Ito ay higit pang uri ng marketing o technology-- ang marketing ng teknolohiya uri ng talakayan. Ngunit ito ay mahalaga na maunawaan dahil kung titingnan natin sa tuktok dito sa tsart na ito, kung ano ang namin ang pagtingin sa ay kung ano ang tawag namin sa technology hype curve. At kung ano ang ibig sabihin nito ay bagong bagay-bagay ay dumating sa play. Akala ng mga tao ito ay mahusay. Ko na lutasin ang lahat ng aking mga problema. 

Maaaring ito ay ang end lahat, maging lahat sa lahat. At simulan nila ang paggamit nito. At sinasabi nila, ang bagay na ito ay hindi gumagana. Hindi ito tama. Ang lumang bagay-bagay ay mas mahusay. At sila ay bumalik sa paggawa mga bagay sa paraan sila ay. At pagkatapos ay sa wakas pumunta sila, alam mo kung ano? Ang bagay na ito ay hindi masama. Oh, na kung paano ito gumagana. At sa sandaling malaman nila kung paano ito gawa, sila ay mas mahusay na magsimula sa pagkuha. 

At ang nakakatawa bagay tungkol dito ay, ito uri ng mga linya ng hanggang sa kung ano ang ang tawag namin sa Adoption Technology Curve. Kaya kung ano ang mangyayari ay mayroon kaming ilang trigger teknolohiya sort. Sa kaso ng mga database, ito ay ang presyon ng data. Usapan natin ang tungkol sa mga mataas na tubig puntos ng presyon data sa buong panahon. Kapag na presyon ng data umabot sa isang tiyak point, na ang isang trigger teknolohiya. 

Ito ay pagkuha ng masyadong mahal. Ito ay tumatagal ng masyadong mahaba upang i-proseso ang data. Kailangan natin ng isang bagay na mas mahusay. Makukuha mo ang mga innovators out there tumatakbo sa paligid, sinusubukan na alamin kung ano ang solusyon. Ano ang mga bagong ideya? 

Ano ang susunod na pinakamahusay na paraan upang gawin ang bagay na ito? At dumating sila sa isang bagay. At ang mga tao sa tunay na sakit, ang guys sa dumudugo gilid, ang mga ito ay tumalon ang lahat ng higit sa mga ito, dahil kailangan nila ng isang sagot. Ngayon kung ano ang hindi maaaring hindi happens-- at ito ay nangyayari sa NoSQL ngayon. Makita ko ito sa lahat ng oras. 

Anong hindi maaaring hindi mangyayari ay mga tao simulan ang paggamit ng bagong tool sa parehong paraan na ginamit nila ang mga lumang kasangkapan. At makikita nila ang mga ito ay hindi gumagana nang maayos. Hindi ko matandaan kung sino ako pakikipag-usap sa mas maaga sa araw. Ngunit ito ay tulad ng, kapag ang jackhammer ay imbento, ay hindi ugoy ito tao sa paglipas ng ang kanilang mga ulo sa bagsak ang kongkreto. 

Ngunit iyon ay kung ano ang nangyayari sa NoSQL ngayon. Kung ituturo sa iyo sa karamihan sa mga tindahan, sila ay nagsisikap na maging NoSQL tindahan. Ano ang kanilang ginagawa ay sila ay gumagamit NoSQL, at sila ay loading ito puno ng schema pamanggit. Dahil na kung paano sila disenyo database. At sila ay nagtataka, kung bakit hindi ito gumaganap nang mahusay? Boy, ang bagay na ito ay bulok. Ako ay upang mapanatili ang lahat ng aking Sinamahan in-- ito ay tulad ng, hindi, hindi. Panatilihin pagsali? Bakit mo siya sumali sa data? Hindi mo na sumali sa data sa NoSQL. Pinagsasama-sama mo ito. 

Kaya kung nais mong maiwasan ito, alamin kung paano gumagana ang tool bago mo talaga simulan ang paggamit nito. Huwag subukan at gamitin ang bagong tool na ito ang parehong paraan na ginamit mo ang mga lumang kasangkapan. Ikaw ay pagpunta sa may isang masamang karanasan. At sa bawat isang oras na kung ano ito ay tungkol sa. Kapag simulan pagdating namin dito, ito ay dahil ang mga tao korte kung kung paano gamitin ang tool. 

Sila ay ang mga parehong bagay kapag pamanggit database ay imbento, at sila ay pinapalitan file system. Sinubukan nila upang bumuo ng mga sistema ng file sa pamanggit database dahil iyon ang naunawaan ng mga tao. Hindi ito gumana. Kaya pag-unawa sa mga pinakamahusay na kasanayan ng teknolohiya ikaw ay nagtatrabaho sa ay malaking. Napaka importante. 

Kaya kami ay pagpunta upang makakuha ng sa DynamoDB. DynamoDB ay AWS ni fully-pinamamahalaang NoSQL platform. Ano ang fully-pinamamahalaang ibig sabihin nito? Ang ibig sabihin nito ay hindi mo na kailangan na talagang mag-alala tungkol sa anumang bagay. 

Dumating ka sa, sabihin sa iyo , Kailangan ko sa amin ng isang table. Kailangan itong ganito karami kapasidad. Pindutin mo ang pindutan, at pagkakaloob namin lahat ng mga imprastraktura sa likod ng mga eksena. Ngayon na ay napakalubha. 

Dahil kapag makipag-usap sa iyo tungkol sa scaling ng isang database, Tumpok data NoSQL sa scale, na tumatakbo petabytes, tumatakbo milyon-milyong mga mga transaksyon sa bawat segundo, mga bagay na ito ay hindi maliit na kumpol. Pinag-uusapan natin ang libu-libong pagkakataon. Pamamahala ng libo-libo ng mga pagkakataon, kahit virtual pagkakataon, ay isang tunay na sakit sa puwit. Ang ibig kong sabihin, mag-isip tungkol sa bawat oras na ang isang patch sistema operating ay out o ng isang bagong bersyon ng database. Ano ang kahulugan nito sa iyo operationally? Iyon ay nangangahulugang ang iyong nakuha 1,200 server na kailangan upang ma-update. Ngayon kahit sa automation, na maaaring tumagal ng isang mahabang panahon. Iyon ay maaaring maging sanhi ng maraming sakit ng ulo na pagpapatakbo, dahil maaaring mayroon ako ng mga serbisyo down. 

Bilang update ko ang mga database, ako maaaring gawin ng blue green deployments kung saan ako lumawak at i-upgrade ang kalahati ng aking nodes, at pagkatapos ay mag-upgrade ang iba pang kalahati. Dalhin ang mga down. Kaya pamamahala ng infrastructure scale ay sobrang sobra masakit. At AWS kumuha ng sakit na lumitaw ng ito. At NoSQL database Maaari maging extraordinarily masakit dahil sa mga paraan masukat nila. 

Scale horizontally. Kung nais mong makakuha ng isang mas malaking NoSQL database, bumili ka ng higit pang mga nodes. Bawat node bumili ay isa pang operational sakit ng ulo. Kaya ipaalam sa ibang tao gawin iyon para sa iyo. AWS maaaring gawin na. 

Sinusuportahan namin ang mga halaga ng key dokumento. Ngayon hindi namin ay pumunta masyadong maraming sa sa iba pang mga chart. May isang pulutong ng mga iba't-ibang flavors ng NoSQL. Ang mga ito ang lahat ng uri ng pagkuha ng munged magkasama sa puntong ito. Maaari mong tingnan ang DynamoDB at sabihin ninyo ang oo, kami ay parehong isang dokumento at isang susi halaga tindahan ng puntong ito. At maaari mong magtaltalan ang mga tampok ng isa sa mga iba. Para sa akin, ang isang pulutong ng mga ito ay talagang anim ng isa sa kalahati ng isang dosenang ng iba. Ang bawat isa sa mga teknolohiyang ito ay isang mainam na teknolohiya at ng masarap na solusyon. Hindi ko sasabihin MongoDB ay mas mahusay o mas masahol pa kaysa Couch, pagkatapos Cassandra, pagkatapos Dynamo, o vice versa. Ibig kong sabihin, ito ay lamang na pagpipilian. 

Ito ay mabilis at ito ay pare-pareho sa anumang scale. Kaya ito ay isa sa mga pinakamalaking bonus kang makakuha ng may AWS. Sa DynamoDB ay ang kakayahan upang makakuha ng isang mababang solong digit millisecond latency sa anumang scale. Iyon ay isang disenyo ng layunin ng sistema. At kami ay may mga customer na ang ginagawa milyon-milyong mga transaksyon sa bawat segundo. 

Ngayon kukunin ko na pumunta sa pamamagitan ng ilan sa mga gamitin ang mga kaso sa loob ng ilang minuto dito. Integrated access control-- mayroon kaming kung ano ang tawag namin Identity Pamamahala ng Access, o IAM. Ito'y nakikita sa bawat system, bawat serbisyo na nag-aalok ng AWS. DynamoDB ay walang exception. Maaari mong kontrolin ang pag-access sa DynamoDB tables. Sa lahat ng iyong AWS account sa pamamagitan ng pagtukoy ginagampanan access at mga pahintulot sa IAM infrastructure. 

At ito ay isang susi at mahalagang bahagi sa ano ang tawag namin Kaganapan hinihimok Programming. Ngayon, ito ay isang bagong tularan. 

Madla: Paano kung ang iyong rate ng tunay na positibo kumpara maling negatibo sa iyong pag-access control system? RICK Houlihan: True positibo kumpara sa maling negatibo? Madla: Bumabalik kung ano dapat ay bumabalik? Bilang laban sa isang beses sa isang habang ito hindi nagbabalik kapag ito ay dapat patunayan? 

RICK Houlihan: hindi ko maaaring sabihin sa iyo na. Kung may anumang mga pagkabigo kahit ano pa man sa mga iyon, Hindi ako ang tao na magtanong na ang partikular na tanong. Ngunit iyon lamang ang isang magandang katanungan. Gusto ko maging mausisa malaman na ang aking sarili, talaga. 

At kaya pagkatapos muli, bagong tularan ay programming driven na kaganapan. Ito ay ang ideya na maaari mong lumawak kumplikadong mga aplikasyon na maaaring patakbuhin ang isang tunay, mataas na proporsyon nang walang anumang infrastructure ano pa man. Nang walang anumang mga nakapirming infrastructure ano pa man. At kami na makipag-usap nang kaunti tungkol sa kung ano ang ibig sabihin na ang bilang namin makakuha ng sa sa susunod na pares ng mga chart. 

Ang unang bagay na gagawin namin ay namin makipag-usap tungkol sa mga talahanayan. Uri ng data API para sa Dynamo. At ang unang bagay bibigyan mo paunawa kapag tiningnan mo ang mga ito, kung hindi ka pamilyar sa anumang database, database ay may talagang dalawang mga uri ng mga API Gusto kong tumawag ito. O dalawang set ng mga API. Isa sa mga nais maging administrative API. 

Ang mga bagay na sila ay kumuha ng pag-aalaga ng ang mga function ng database. Pag-configure ng imbakan engine, set up at pagdaragdag ng mga talahanayan. paglikha database katalogo at pagkakataon. Ang mga bagay- sa DynamoDB, ikaw Mayroon masyadong maikli, maikling listahan. 

Kaya sa iba pang mga database, maaari kang makakita ng mga dose-dosenang ng mga utos, ng administrative command, para sa pagsasaayos ang mga karagdagang mga pagpipilian. Sa DynamoDB hindi mo kailangan ng mga dahil hindi mo na i-configure ang sistema, ginagawa namin. Kaya ang tanging bagay na kailangan mong gawin ay ang sabihin sa akin kung ano ang laki ng talahanayan ang kailangan ko. Kaya mo makakuha ng isang napaka limitadong hanay ng mga utos. 

Makakakuha ka ng isang Lumikha Update Table, Table, Tanggalin ang Table, at Ilarawan Table. Ang mga ay ang tanging bagay kailangan mo para DynamoDB. Hindi mo kailangan ng isang storage configuration engine. Hindi ko kailangan mag-alala tungkol sa pagtitiklop. Hindi ko kailangan mag-alala tungkol sharding. 

Hindi ko kailangan mag-alala tungkol sa alinman sa mga bagay-bagay na ito. Ginagawa namin ang lahat ng ito para sa iyo. Kaya na ang isang malaking halaga ng overhead na lang ang itinaas-off ang iyong mga plate. Pagkatapos kami ay may CRUD operator. CRUD ay isang bagay na kung ano ang aming tumawag sa database na Gumawa, I-update, Tanggalin operator. Ang mga ito ay ang iyong karaniwang operasyon ng database. Mga bagay na tulad ilagay item, kumuha ng item, i-update item, tanggalin ang mga item, batch query, i-scan. Kung nais mong i-scan ang buong table. Hilahin off ng talahanayan ang lahat. Isa sa mga magagandang bagay tungkol sa DynamoDB ay nagbibigay-daan ito parallel na pag-scan. Kaya maaari mong aktwal na ipaalam sa akin kung gaano karaming thread na gusto mong patakbuhin sa na scan. At maaari naming patakbuhin ang mga thread. Maaari naming iikot na scan up sa kabuuan ng maramihang mga thread sa gayon maaari mong i-scan ang buong table space tunay, tunay mabilis sa DynamoDB. 

Ang iba pang mga API na mayroon kami ay kung ano ang tawag namin sa aming Streams API. Hindi namin pagpunta sa makipag-usap ng masyadong marami tungkol sa mga ito ngayon. Mayroon akong ilang mga nilalaman sa ibang pagkakataon on sa deck tungkol dito. Ngunit Streams ay talagang isang running-- tingin ng mga ito bilang ng oras order at baguhin ang partition log. Lahat ng bagay na nangyayari sa ang talahanayan ay nagpapakita ng hanggang sa stream. 

Bawat sumulat sa talahanayan nagpapakita up sa stream. Maaari mong basahin na stream, at maaari mong gawin ang mga bagay sa mga ito. Susubukan naming makipag-usap tungkol sa kung ano mga uri ng mga bagay-bagay sa iyo kinalaman sa mga bagay na tulad ng pagtitiklop, paglikha pangalawang index. Lahat ng uri ng mga talagang cool na mga bagay na maaari mong gawin sa mga iyon. 

Uri ng data. Sa DynamoDB, sinusuportahan namin ang parehong mga key halaga at data na dokumento uri. Sa kaliwang bahagi ng screen dito, namin nakuha ang aming pangunahing mga uri. Key mga uri ng halaga. Ang mga ito ay mga string, numero, at binaries. 

Kaya lang tatlong pangunahing mga uri. At pagkatapos ay maaari kang magkaroon ng mga hanay ng mga iyon. Isa sa mga magagandang bagay tungkol sa NoSQL ay maaari mong maglaman array bilang properties. At sa pamamagitan DynamoDB maaari mong maglaman array ng mga pangunahing uri gaya ng ugat sa ari-arian. 

At pagkatapos ay may mga uri ng dokumento. Gaano karaming mga tao ay pamilyar sa JSON? Ikaw guys pamilyar sa gayon JSON? Ito ay isa lamang JavaScript, Bagay, pagtatanda. Ito ay nagbibigay-daan sa iyo upang talaga tukuyin ang isang hierarchical istraktura. 

Maaari mong i-imbak ang isang JSON dokumento sa DynamoDB gamit ang karaniwang mga sangkap o mga bloke ng gusali na magagamit sa karamihan ng mga wika programming. Kaya kung mayroon kang Java, ikaw ay naghahanap sa mapa at mga listahan. Maaari ba akong lumikha ng mga bagay na lugar ng mapa. Ang isang mapa bilang susi halaga naka-imbak na mga katangian. At ito ay maaaring magkaroon ng mga listahan ng mga mga halaga sa loob ng mga katangian. Maaari mong itabi ang complex na ito hierarchical istraktura bilang isang solong attribute ng isang DynamoDB item. 

Kaya talahanayan sa DynamoDB, tulad ng karamihan NoSQL mga database, mga talahanayan ay may mga item. Sa MongoDB gagawin mo tumawag sa mga dokumento. At magiging sopa base. Gayundin isang database dokumento. Tawagan mo ang mga dokumentong ito. Magkaroon ng mga katangian ng mga dokumento o mga bagay. Maaaring umiiral Katangian o Hindi umiiral ang item. Sa DynamoDB, may isa sapilitan attribute. Katulad ng sa isang pamanggit database, ikaw ay may isang pangunahing susi sa mesa. 

DynamoDB may kung ano ang tawag namin sa isang hash key. Ay dapat na natatangi hash key. Kaya kapag ko tutukuyin ang isang hash table, talaga kung ano ako sinasabi ay ang bawat item ay magkakaroon ng isang hash key. At bawat hash key ay dapat na kakaiba. 

Ang bawat item ay tinukoy sa pamamagitan ng na natatanging hash key. At doon ay maaari lamang maging isa. Ito ay OK, ngunit malimit kung ano ang kailangan ng mga tao ay ang nais nila ay ang hash key upang makagawa ng higit pa sa isang maliit na piraso kaysa sa maging lamang ng isang natatanging identifier. Madalas gusto naming gamitin na hash key bilang sa itaas ng pagsasama-sama antas bucket. At ang paraan namin na sa pamamagitan ng pagdagdag ng kung ano ang tawag namin sa isang hanay key. 

Kaya kung ito ay isang hash lamang table, ito ay dapat na kakaiba. Kung ito ay isang hash at hanay ng talahanayan, ang mga kumbinasyon ng hash at ang hanay dapat na kakaiba. Kaya mag-isip tungkol sa mga ito sa ganitong paraan. Kung mayroon akong isang forum. At ang mga form ay may mga paksa, ito ay may nag-post, at ito ay may mga sagot. 

Kaya maaari ba akong magkaroon ng isang hash key, na kung saan ay ang ID topic. At maaari ba akong magkaroon ng isang hanay key, kung saan ay ang ID na tugon. Sa ganoong paraan kung gusto kong makuha ang lahat ng mga tugon para sa partikular na paksa, Maaari ko lang i-query ang hash. Maaari ko bang sabihin lamang magbigay sa akin ang lahat ang mga item na may ganitong hash. At ako pagpunta upang makakuha ng lahat ng tanong o mag-post para sa partikular na paksa. Ang mga top level aggregations ay lubhang mahalaga. Sinusuportahan nila ang mga pangunahing access pattern ng application. Sa pangkalahatan, ito ay kung ano ang gusto naming gawin. Nais namin na ang table-- load ka sa table, gusto naming buuin ang data sa loob ng talahanayan sa paraan na ang application ay maaaring tunay mabilis na makuha ang mga resulta. At madalas ang mga paraan upang gawin iyon ay upang mapanatili ang mga pagsasama-sama bilang namin ipasok ang data. Talaga, kami ay nagkakalat ang data sa maliwanag na bucket na ito ay dumating sa. 

Saklaw keys payagan me-- hash keys kailangang maging pagkakapantay-pantay. Kapag query ako ng hash, kailangan kong sabihin bigyan ako ng isang hash na katumbas na ito. Kapag query ko ang isang hanay, ako masasabi ninyo ako ng hanay na gumagamit ng anumang uri ng mayaman operator na sinusuportahan namin. Bigyan mo ako ng lahat ng mga item para sa isang hash. Ito ba ay pantay-pantay, mas malaki kaysa sa, mas mababa sa, nag-uumpisa ito sa, ang umiiral sa pagitan ng dalawang mga halaga? Kaya ang mga uri ng mga query na hanay na kami ay laging interesado sa. Ngayon ang isang bagay tungkol sa data, kapag tumingin ka sa pag-access ng data, kapag access mo ang data, ito ay palaging tungkol sa isang pagsasama-sama. Ito ay palaging tungkol sa mga talaan na may kaugnayan sa mga ito. Bigyan mo ako ng lahat ng bagay dito that's-- lahat ang mga transaksyon na ito sa credit card para sa nakaraang buwan. Iyan ay isang pagsasama-sama. 

Halos lahat ng ginagawa mo sa database ay ilang mga uri ng pagsasama-sama. Kaya ng kakayahang ma-define mga bucket at magbibigay sa iyo ng mga hanay katangian para ma-i-query sa, sumusuporta sa mga mayaman na mga query sa marami, maraming, maraming mga pattern access application. 

Kaya ang iba pang mga bagay ang hash key ay ito ay nagbibigay sa amin ng isang mekanismo para ma-kumalat ang data sa paligid. Pinakamahusay NoSQL database gumagana kapag ang data ay pantay-pantay ipinamamahagi sa buong kumpol. Gaano karaming mga tao ay pamilyar may hashing algorithms? Kapag sinasabi ko hash at isang hashing-- dahil ang isang hashing algorithm ay isang paraan ng pagiging magagawang upang bumuo ng isang random na halaga mula sa anumang ibinigay na halaga. Kaya sa ganitong kaso, ang hash algorithm tumakbo kami ay nd 5 based. 

At kung mayroon akong isang ID, at ito ay ang aking hash key, Mayroon akong 1, 2, 3. Kapag tumakbo ang hash algorithm, ito ay pagpunta sa bumalik at sabihin, well 1 ay katumbas ng 7B, 2 ay katumbas ng 48, 3 ay katumbas ng CD. Ang mga ito ay kumalat sa buong key space. At bakit mo gawin ito? Dahil na tinitiyak na makakaya ko ilagay ang mga tala sa maramihang nodes. 

Kung ako gawin ito paunti-unti, 1, 2, 3. At ako ay may isang hanay hash na tumatakbo sa partikular na kasong, isang maliit na espasyo hash, ito ay tumatakbo mula sa 00 na FF, pagkatapos ay ang mga talaan ay pagpunta sa dumating sa at sila ay pagpunta sa pumunta sa 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. Ano ang mangyayari? Bawat insert ay pagpunta sa parehong node. Makikita mo kung ano ang ibig sabihin ko? 

Dahil kapag ako split ang space, at ikakalat ko ang mga talaang kabuuan, at ako partition, pupuntahan ko sabihin partition 1 ay may key space 0-54. Partition 2 ay 55-89. Partition 3 ay AA sa FF. Kaya kung gumagamit ako ng linearly incrementing ID, maaari mong makita kung ano ang nangyayari. 1, 2, 3, 4, 5, 6, ang lahat ng mga paraan ng hanggang sa 54. Kaya bilang ako pagmamartilyo ang records sa system, nagtatapos up sa lahat ng pagpunta sa isa node. 

Iyan ay hindi mabuti. Iyan ay isang antipattern. Sa MongoDB nila ang problemang ito kung hindi ka gumagamit ng isang hash key. Binibigyan ka MongoDB ang pagpipilian ng hashing ang key na halaga. Ikaw ay dapat palaging gawin iyon, kung gumagamit ka ng isang incrementing hash key sa MongoDB, o kayo ay ipinapako bawat write sa isa node, at ikaw ay takda iyong write throughput masama. 

Madla: Ay na A9 169 in decimal? 

RICK Houlihan: Oo, ito ay isang lugar sa paligid doon. A9, hindi ko alam. Gusto mo na makuha ang aking binary sa calculator decimal. Ang aking utak ay hindi gumagana tulad na. Madla: lamang ng isang mabilis na isa ng iyong Mongo komento. Kaya ay ang object ID na nanggagaling natively sa Mongo gawin iyon? RICK Houlihan: gawin ba ito na? Kung tinukoy mo ito. Sa MongoDB, mayroon kang pagpipilian. Maaari mong specify-- bawat dokumento MongoDB ay upang magkaroon ng isang underscore ID. Iyan ang mga natatanging halaga. 

Sa MongoDB maaari mong tukuyin ang kung mag-hash ito o hindi. Sila lang bigyan ka ng opsyon. Kung alam mo na ito ay random, walang problema. Hindi mo na kailangan na gawin iyon. Kung alam mo na ito ay hindi random, na ito ay incrementing, pagkatapos ay gawin ang hash. 

Ngayon ang mga bagay tungkol sa hashing, sa sandaling sumira sa iyo isang value-- at ito ay bakit hash key ay palaging natatanging mga tanong, dahil ko na nagbago ang halaga, ngayon ay hindi ko gawin ang isang query range. Hindi ko masabi ito pagitan ng mga ito o na, dahil ang halaga ng hash ay hindi pagpunta upang maging katumbas sa aktwal na halaga. Kaya kapag hash mo na key, ito ay ang pagkakapantay-pantay lamang. Ito ang dahilan kung bakit sa DynamoDB hash key mga tanong ay palaging ang pagkakapantay-pantay lamang. 

Kaya ngayon sa isang hanay key-- kapag nagdagdag ako na hanay key, lahat ng dumating sa mga talaang hanay key at sila makakuha ng mga naka-imbak sa parehong partition. Kaya ikaw ay masyadong mabilis ang mga ito, madaling nabawi dahil ito ay ang hash, ito ay ang saklaw. At nakita mo ang lahat ng bagay na may parehong hash makakakuha ng naka-imbak sa parehong puwang partition. Maaari mong gamitin na hanay key upang makatulong hanapin ang iyong data ng malapit sa kanyang magulang. Kaya kung ano ay talagang ginagawa ko dito? Ito ang isa sa maraming relasyon. Ang relasyon sa pagitan ng isang hash key at ang hanay key ay isa sa maraming. Maaari ba akong magkaroon ng maramihang mga hash key. Maaari ko lamang magkaroon ng maramihang mga hanay susi sa loob ng bawat hash key. 

Hash tumutukoy sa mga magulang, ang hanay na tumutukoy sa mga bata. Kaya maaari mong makita doon ang analog dito sa pagitan ng mga pamanggit tayuan at ang parehong mga uri ng constructs sa NoSQL. Nagsasalita ang mga tao tungkol sa NoSQL bilang nonrelational. Ito ay hindi nonrelational. Laging may relasyon Data. Ang mga relasyon lamang ay imo-modelo na naiiba. Makipag-usap sa isang maliit Ipaalam kaunti tungkol sa tibay. Kapag nagsulat ka sa DynamoDB, nagsusulat ay laging may tatlong paraan Ginagaya. Ibig sabihin na may tatlong AZ ni namin. AZ ni ay Availability Zones. Maaari mong isipin na ang isang Availability Zone bilang isang data center o isang koleksyon ng data centers. Ang mga bagay ay heograpiya nakahiwalay mula sa bawat isa sa iba't ibang mga fault zone, sa kabuuan iba't-ibang kapangyarihan grids at floodplains. Ang isang kabiguan sa isa sa AZ ay hindi pagpunta sa kumuha ng down-isa. Ang mga ito ay naka-link din kasama ang madilim na hibla. Ito ay sumusuporta sa isang sub 1 millisecond latency sa pagitan Azs. Kaya real time replications data may kaya sa multi Azs. 

At malimit multi AZ deployments matugunan ang mga mataas na mga kinakailangan availability ng karamihan sa mga organisasyon enterprise. Kaya DynamoDB ay kumakalat sa kabuuan ng tatlong Azs pamamagitan ng default. Tanging Kami ay pagpunta sa kaalaman ang write kapag ang dalawang sa mga tatlong nodes ay bumalik at sabihin, Oo, nakuha ko ito. Bakit na? Dahil sa nabasa na side hindi namin lamang pagpunta sa iyo ang data sa likod kapag makuha namin ito mula sa dalawang nodes. 

Kung ako Kinokopya kabuuan tatlo, at ako sa pagbabasa mula sa dalawa, Lagi akong garantisadong na magkaroon ng hindi bababa sa isang sa mga bumabasa na ang pinaka-kasalukuyang kopya ng data. Iyon ay kung bakit pare-pareho DynamoDB. Ngayon ay maaari mong piliin upang i-on pare-pareho sa mga nagbabasa ng off. Sa anong kaso ako pagpunta sa sabihin, Kukunin ko lamang basahin mula sa isang node. At hindi ko masisiguro na ito ay pagpunta na ang pinaka-kasalukuyang data. 

Kaya kung ang isang write ay dumarating, ito ay hindi pa kinokopya, ikaw ay pagpunta upang makakuha ng kopya. Iyan ay isang pare-pareho sa huli read. At ano na ang kalahati ng gastos. Kaya ito ay isang bagay na isipin ang tungkol. Kapag ikaw ay pagbabasa out DynamoDB, at naka-set up ang iyong kapasidad read units, kung pinili mo sa huli pare-pareho bumabasa, ito ay isang pulutong mas mura, ito ay tungkol sa kalahati ng gastos. 

At kaya ito makakatipid ka ng pera. Ngunit iyon lamang ang iyong mga pagpipilian. Kung nais mo ang isang pare-pareho read o isang pare-pareho sa huli read. Iyan ay isang bagay na maaari mong piliin. 

Makipag-usap tungkol index Hayaan. Kaya nabanggit namin na tuktok na antas ng pagsasama-sama. Mayroon kami ng hash key, at Nakakuha kami ng hanay keys. Maganda yan. At na sa pangunahing table, ako got isa hash key, Nakatanggap ako ng isa hanay key. 

Ano ang ibig sabihin nito? Mayroon akong isang katangian na ako maaaring tumakbo mayaman tanong laban. Ito ay ang hanay key. Ang iba pang mga katangian sa na item-- Maaari ko bang i-filter sa mga katangiang iyon. Ngunit hindi ko maaaring gumawa ng mga bagay tulad ng, ito nagsisimula sa, o ay mas malaki sa. 

Paano ko gagawin yan? Gumawa ako ng isang index. Mayroong dalawang uri ng mga index sa DynamoDB. Ang isang index ay talagang isa pang view ng talahanayan. At ang mga lokal na sekundaryong index. 

Ang unang isa namin makipag-usap tungkol sa. Kaya lokal secondaries ay coexisted sa parehong partition bilang ang data. At dahil dito, ang mga ito sa parehong pisikal na node. Ang mga ito ay kung ano ang tawag namin pare-pareho. Ibig sabihin, sila ay kinikilala ang sumulat kasama ng table. Kapag dumarating sa write, makikita namin magsulat sa pamamagitan ng index. Makikita isulat namin up sa table, at pagkatapos ay namin kinikilala. Kaya na pare-pareho. Kapag ang mga write ay kinikilala mula sa talahanayan, ito ay garantisadong na ang lokal na sekundaryong index ay magkakaroon ng parehong paningin ng data. Ngunit kung ano ang pinapayagan nila ang gagawin mo ay tukuyin ang kahaliling hanay keys. 

Magkaroon upang gamitin ang parehong hash key bilang pangunahing table, dahil sila ay co-matatagpuan sa parehong partition, at ang mga ito ay pare-pareho. Ngunit maaari kong lumikha ng isang index may iba't ibang hanay keys. Kaya halimbawa, kung ako ay isang tagagawa na nagkaroon ng isang raw talahanayan bahagi pagdating sa. At raw bahagi dumating sa, at sila ay pinagsama-sama sa pamamagitan ng pagpupulong. At siguro mayroong isang pagpapabalik. 

Anumang bahagi na ginawa sa pamamagitan na ito tagagawa pagkatapos ng petsang ito, Kailangan ko upang hilahin mula sa aking linya. Maaari ko bang iikot ng isang index na ay naghahanap, pinagsasama-sama sa petsa ng paggawa ng mga partikular na bahagi. Kaya kung ang aking table top level ay nai-hash pamamagitan ng tagagawa, marahil ito ay nakaayos sa bahagi ID, ako ay maaaring lumikha ng isang index off table na bilang hash pamamagitan ng tagagawa at ranged sa petsa ng paggawa. At ang paraan na kaya kong sabihin, anumang bagay na ay gawa sa pagitan ng mga petsang ito, Kailangan ko upang hilahin mula sa linya. Kaya na ang isang lokal na sekundaryong index. 

Ang mga ito ay ang epekto ng takda sa inyong space hash key. Dahil ang mga ito co-umiiral sa parehong node storage, limitasyon nila ang hash key space sa 10 gigabytes. DynamoDB, sa ilalim ng mga talahanayan, ay pagkahati iyong talahanayan bawat 10 gigabytes. Kapag inilagay mo ang 10 gig ng data sa, kami pumunta [PHH], at magdagdag ng isa pang node. 

Hindi namin ay nahati ang LSI sa kabuuan ng maramihang mga partisyon. Susubukan naming hatiin ang table. Ngunit hindi pa namin ay nahati ang LSI. Kaya na ang isang bagay Mahalaga na maunawaan ay kung ikaw ay gumagawa ng tunay, napaka, napakalaking aggregations, pagkatapos ikaw ay pagpunta sa magiging limitado hanggang 10 gigabytes sa iyong LSIs. 

Kung iyon ang kaso, maaari naming gamitin ang global secondaries. Global secondaries ay talagang ibang table. Sila ay umiiral ganap off sa sa gilid ng iyong pangunahing table. At payagan sila sa akin upang makahanap ng isang ganap na naiibang mga istraktura. Kaya sa tingin ng mga ito bilang ang data ay nakapasok sa dalawang iba't ibang mga talahanayan, nakabalangkas sa dalawang magkaibang paraan. 

Maaari ko bang tukuyin ang isang ganap na iba't ibang hash key. Maaari ko bang tukuyin ang isang ganap na iba't-ibang mga hanay key. At maaari kong patakbuhin ang ganap na malaya. Bilang isang bagay ng katotohanan, na ako provision aking read kapasidad at isulat ang kapasidad para sa aking global pangalawang index ganap na malaya ng aking pangunahing table. Kung ako tukuyin index na, sinasabi ko ito kung magkano ang basahin at isulat kapasidad na ito ay pagpunta sa gumagamit. 

At iyon ay hiwalay na mula sa aking pangunahing table. Ngayon ang parehong mga ini-index ng daan sa amin upang tukuyin hindi lamang hash at hanay key, ngunit pinapayagan nila sa amin upang proyekto ng karagdagang halaga. Kaya kung gusto kong basahin off ang index, at gusto kong makakuha ng ilang mga hanay ng data, Hindi ko na kailangan upang bumalik sa pangunahing talahanayan upang makuha ang mga karagdagang katangian. Maaari ko bang project ang mga karagdagang katangian sa talahanayan upang suportahan ang access pattern. Alam ko marahil kami ay pagkuha sa ilang talaga, really-- pagkuha sa mga damo dito sa ilan sa mga bagay-bagay na ito. Ngayon Nakatanggap ako sa naaanod na out ng mga ito. 

Madla: [hindi marinig] --table key sinadya ay isang hash? Ang orihinal na hash? Multi-slats? 

RICK Houlihan Oo. Oo. Ang mga pangunahing talahanayan talaga puntos pabalik sa mga item. Kaya isang index ay isang pointer pabalik sa mga orihinal na item sa talahanayan. Ngayon ay maaari kang pumili upang bumuo ng isang index na may table na key lamang, at walang iba pang mga katangian. At bakit maaari ko na? Well, siguro mayroon akong napakalaking item. 

Ko talagang lamang ang kailangan upang malaman which-- Maaaring sabihin ng aking mga pattern access, kung aling mga item na naglalaman ng mga ari-arian na ito? Huwag kailangan upang bumalik ang mga item. Kailangan ko lang malaman kung aling mga item na naglalaman ng mga ito. Kaya maaari kang bumuo ng index na mayroon lamang sa talahanayan key. 

Ngunit iyon lamang ang una kung ano isang index sa database ay para sa. Ito ay para sa pagiging magagawang upang mabilis na makilala na talaan, na mga hilera, kung saan item sa talahanayan ay may ang mga katangian na ako na naghahanap para sa. 

GSIS, kaya kung paano gumagana ang mga ito? GSIS talaga ay asynchronous. Update lumapit sa table, mesa ay pagkatapos asynchronously update ang lahat ng iyong GSIS. Ito ay kung bakit GSIS ay huli pare-pareho. 

Ito ay mahalaga na tandaan na ang kapag ikaw ay gusali GSIS, at nauunawaan mo ikaw ay lumilikha ng isa pang dimensyon ng aggregation-- ngayon sabihin natin ng magandang halimbawa dito ay isang tagagawa. Sa tingin ko ay maaaring magkaroon ng usapan ko ang tungkol isang tagagawa ng medikal na aparato. Tagagawa Medikal na aparato malimit may serialized bahagi. Ang mga bahagi na pumunta sa isang hip kapalit lahat magkaroon ng isang maliit na serial number sa mga ito. At maaari silang magkaroon ng milyun-milyon at milyon-milyong at bilyon-bilyong mga bahagi sa lahat ng mga lalang na kanilang barko. Well, kailangan nila upang pagsama-samahin sa ilalim iba't-ibang mga sukat, ang lahat ng mga bahagi sa isang pagpupulong, ang lahat ng mga bahagi na ang ginawa sa isang tiyak na linya, ang lahat ang mga bahagi na dumating in mula sa isang tiyak na tagagawa sa isang tiyak na petsa. At ang mga ito aggregations minsan makakuha ng hanggang sa bilyon-bilyong. 

Kaya ako ng trabaho sa ilan sa mga mga guys na paghihirap dahil ang mga ito ay ang paglikha ng mga Ginormous aggregations sa kanilang pangalawang index. Sila ay maaaring magkaroon ng isang raw na bahagi mesa na dumating bilang hash lamang. Ang bawat bahagi ay may isang natatanging serial number. Gamitin ko ang mga serial number ng mga hash. Ang ganda. Mesa My raw data ay kumalat lahat sa buong key space. Aking [? isulat?] [? paglunok?] ay kahanga-hangang. Kumuha ako ng maraming data. Pagkatapos ay kung ano ang ginagawa nila ay silang lumikha ng isang GSI. At sinasabi ko, alam mo kung ano, kailangan ko na makita lahat ng mga bahagi para sa tagagawa. Well, ang lahat ng isang biglaang ako pagkuha ng isang bilyong mga hilera, at bagay-bagay ang mga ito papunta isa node, dahil kapag Pinagsasama-sama ko na rin ang ID tagagawa bilang ang hash, at part number bilang ng hanay, at pagkatapos ang lahat ng mga biglaang ako paglalagay ng isang bilyong mga bahagi sa kung ano ang tagagawa na ito ay inihatid sa akin. 

Iyon ay maaaring maging sanhi ng maraming ng presyon sa GSI, muli, dahil ako pagmamartilyo isa node. Ako ng paglalagay ng lahat ng mga pagsingit sa isang node. At iyon ay isang tunay na problema na gamitin ang kaso. Ngayon, nakakuha ako ng magandang disenyo pattern para sa kung paano mo maiwasan na. At iyon ang isa sa mga problema na ako palaging gumagana sa. Ngunit ano ang mangyayari, ay ang GSI maaaring walang sapat na kapasidad write para ma-itulak ang lahat ng mga mga hilera sa isang solong node. At ano ang mangyayari pagkatapos ay ang primary, ang mga talahanayan client, ang pangunahing talahanayan ay throttled dahil ang GSI ay hindi maaaring panatilihin up. Kaya ang aking insert rate ay tumama ang pangunahing talahanayan bilang aking GSI sumusubok na panatilihin up. 

Lahat ng karapatan, kaya GSI ni, LSI, ang kung saan ang isa ay dapat kong gamitin? LSI ni ay pare-pareho. GSI ni ay pare-pareho sa huli. Kung iyon ang OK, inirerekumenda ko ang paggamit ng isang GSI, ang mga ito ay mas may kakayahang umangkop. LSI ay maaaring ma-imo-modelo bilang GSI. At kung ang laki ng data sa bawat hash key in lumampas ang iyong koleksyon ng 10 gigabytes, pagkatapos ikaw ay pagpunta sa nais na gumamit na GSI dahil ito lamang ay isang mahirap na limitasyon. 

Lahat ng karapatan, kaya scaling. Throughput sa Dynamo DB, ikaw lata pagkakaloob [hindi marinig] throughput sa isang table. Mayroon kaming mga customer na magkaroon ng provision 60 billion-- ginagawa 60 bilyon na mga kahilingan, regular tumatakbo sa loob ng isang milyong mga kahilingan bawat segundo sa aming mga talahanayan. Mayroon talagang hindi panteorya limitasyon sa kung magkano at kung gaano kabilis ang mga talahanayan maaaring tumakbo sa Dynamo DB. May ilang mga soft mga limitasyon sa iyong account na inilalagay namin sa may kaya na hindi mo na mabaliw. Kung nais mo ng higit sa na iyon, hindi isang problema. Dumating ka sabihin sa amin. Makikita i-up kami ng dial. 

Ang bawat account ay limitado sa ilang mga antas sa bawat serbisyo, i-off ang bat kaya ang mga tao ay hindi mabaliw makakuha ng kanilang sarili sa problema. Walang limitasyon sa laki. Maaari mong ilagay ang anumang bilang ng mga bagay sa isang table. Ang laki ng isang item ay limitado sa 400 kilobytes bawat isa, na magiging item hindi ang mga katangian. Kaya ang kabuuan ng lahat ng mga katangian ay limitado sa 400 kilobytes. At pagkatapos ay muli, kami ay na maliit LSI isyu may limit 10 gigabyte per hash. Madla: Small number, ako nawawala kung ano ang sinasabi mo sa akin, na is-- Madla: Oh, 400 kilobyte ay ang pinakamataas na sukat ng bawat item. Kaya ito ay may lahat ng mga katangian ng isang item. Kaya 400 k ay ang kabuuang sukat ng bagay na iyon, 400 kilobytes. Kaya sa lahat ng katangian pinagsama, ang lahat ng mga data na sa lahat ng mga katangian, pinagsama sa isang kabuuang sukat, kasalukuyang ngayon ang limitasyon item ay 400 k. Kaya pagsusukat muli, nakakamit sa pamamagitan ng pag-partisyon. Throughput napaglaanan sa antas ng table. At mayroon talagang dalawang knobs. Kami ay basahin ang kapasidad at isulat ang kapasidad. 

Kaya ang mga ito ay naaakma malaya ng bawat isa. Ang panukalang-batas RCU ni mahigpit na pare-pareho na nagbabasa. OK, kaya kung ikaw ay sinasabi na gusto ko 1,000 RCU ni ang mga ito ay mahigpit na pare-pareho, ang mga ito ay pare-pareho na nagbabasa. Kung sinasabi mo na gusto ko wakas pare-pareho nagbabasa, Maaari mong pagkakaloob 1,000 RCU ni, ikaw ay pagpunta upang makakuha ng 2,000 huli pare-pareho bumabasa. At kalahati ang presyo para sa mga kalaunan ay binubuo sa nagbabasa. 

Muli, nababagay malaya ng bawat isa. At sila ay may mga throughput-- Kung ubusin mo ang 100% ng iyong RCU, hindi ka pagpunta sa epekto sa availability ng iyong mga karapatan. Kaya ang mga ito ay ganap na independiyenteng ng bawat isa. Lahat ng karapatan, kaya isa sa mga bagay na Nabanggit ko sa madaling sabi ay Throttling. Throttling ay masama. Throttling nagpapahiwatig masamang walang SQL. May mga bagay na maaari naming gawin upang matulungan mong magpakalma ang Throttling na kayo nararanasan. Ngunit ang pinakamahusay na solusyon na ito ay ipaalam sa tumagal ng isang pagtingin sa kung ano ang iyong ginagawa, dahil mayroong isang anti-pattern sa pag-play dito. 

Ang mga bagay, ang mga bagay tulad ng mga di-unipormeng workloads, hot keys, hot partisyon. Ako pagpindot sa isang partikular na space key napakahirap para sa ilang partikular na dahilan. Bakit ako ginagawa ito? Sabihin malaman na natin. Ako paghahalo aking mainit na data na may malamig na data. Ako pagpapaalam sa aking mga talahanayan makakakuha napakalaking, ngunit may tunay lamang ng ilang mga subset ng data iyan ay talagang kawili-wili sa akin. Kaya para sa data ng log, halimbawa, ng maraming mga customer, sila ay kumuha ng data mag-log sa bawat araw. Nakuha nila ang isang malaking halaga ng data ng log. 

Kung naka-paglalaglag lamang ang lahat ng log na data sa isang malaking table, sa paglipas ng panahon mesa na pagpunta upang makakuha ng malaki at mabigat. Ngunit ako ay talagang lamang na interesado sa huling 24 na oras, sa nakaraang pitong araw, sa huling 30 araw. Anuman ang window ng oras na ako interesado sa mga naghahanap para sa kaganapan na bothers sa akin, o ang kaganapan na kawili-wili sa akin, na ang tanging oras window na kailangan ko. Kaya bakit ako ng paglagay ng 10 taon nagkakahalaga ng data ng log sa talahanayan? Ano na nagiging sanhi ay talahanayan ng mga fragment. 

Malaking Ito ay makakakuha. Ito ay nagsisimula sa pagkalat out kabuuan libu-libong mga nodes. At dahil ang iyong kapasidad ay kaya mababa, ikaw ay talagang rate takda sa bawat isa sa mga indibidwal na nodes. Kaya natin simulan ang pagtingin sa kung paano ipaalam gawin namin gumulong table na over. Paano namin pamahalaan ang data na iyon sa isang maliit na mas mahusay na upang maiwasan ang mga problemang ito. At kung ano na ang hitsura? Ito ay kung ano na kamukha. Ito ay kung ano ang hitsura masamang NoSQL gusto. 

Nakakuha ako ng isang hot key dito. Kung tumingin ka sa gilid dito, ang mga ito ay ang lahat ng aking mga partisyon. Nakakuha ako ng 16 partisyon up dito sa partikular na database. Ginagawa namin ito sa lahat ng oras. Tumakbo ko ito para sa mga customer sa lahat ng oras. Ito ay tinatawag na ang heat map. Sinasabi sa akin Heat mapa kung paano ikaw ay pag-access ng iyong mga susi space. At kung ano ito ay nagsasabi sa akin ay na mayroong isang partikular na hash na ang tao ang may gusto ng isang kakila-kilabot maraming, dahil siya ang pagpindot ito talaga, talagang mahirap. 

Kaya ang asul ay nice. Gusto naming asul. Hindi namin gusto ang red. Red kung saan ang presyon ay makakakuha ng hanggang sa 100%. 100%, na ngayon ang iyong pagpunta sa throttled. Kaya kapag nakita mo ang anumang mga pulang linya tulad ng this-- at ito ay hindi lamang Dynamo DB-- bawat NoSQL database ay may problemang ito. May mga anti-pattern na maaari himukin ang mga uri ng mga kondisyon. Ano ang gagawin ko ay ako ng trabaho sa mga customer upang magpakalma ang mga kondisyon. 

At kung ano na ang hitsura? At ito ay ang pagkuha ng pinaka out of Dynamo DB throughput, ngunit ang talagang nakakakuha ito ng ang pinaka-out ng NoSQL. Ito ay hindi limitado sa Dynamo. Ito ang definitely-- ko ginagamit sa trabaho sa Mongo. Ako ay pamilyar sa maraming mga NoSQL platform. Bawat isa ay may ganitong mga uri ng hot key problema. Upang makuha ang pinaka-out ng anumang NoSQL database, partikular Dynamo DB, na nais mong lumikha ng mga talahanayan kung saan ang mga elemento hash key ay isang malaking bilang ng natatanging mga halaga, isang mataas na antas ng cardinality. Dahil nangangahulugan na ako ng sulat sa maraming iba't-ibang mga bucket. 

Ang mas maraming mga bucket Ako pagsulat sa, mas malamang na Ako na kumalat na ang load write o basahin load out sa maramihang nodes, mas malamang na ako na magkaroon ng isang mataas na throughput sa mesa. At pagkatapos ay gusto ko ang mga halaga na maging hiniling na medyo pantay-pantay sa paglipas ng panahon at pantay na random na panahon. Well, na ang uri ng kawili-wili, dahil hindi ko makakaya talaga control kapag dumating ang mga gumagamit. Kaya makasapat upang sabihin, kung ikakalat namin out ng mga bagay sa kabuuan ng key na espasyo, kami ay malamang na maging mas mahusay na hugis. 

May isang tiyak na halaga ng oras na paghahatid na hindi ka pagpunta para ma control. Ngunit ang mga ay talagang ang dalawang sukat na mayroon kami, space, access pantay-pantay spread, oras, mga kahilingan ang pagdating pantay-pantay spaced sa oras. At kung ang mga dalawang kondisyon ay natutugunan, pagkatapos na kung ano ito ay pagpunta sa hitsura. Ito ay marami nicer. Kami ay talagang masaya dito. Nakakuha kami ng isang napaka-kahit na pattern access. Oo, siguro makakakuha ka ng isang maliit na presyon bawat ngayon at pagkatapos, ngunit wala talagang masyadong malawak. Kaya ito ay amazing kung gaano karaming beses, kapag ako ng trabaho sa mga customer, na ang unang graph na may malaking red bar at ang lahat na pangit yellow ito ay lahat ng dako ng lugar, tayo makakuha ng tapos na may mga exercise pagkatapos ng isang pares ng mga buwan ng re-architecture, sila ay nagpapatakbo ng parehong workload sa eksaktong parehong load. At ito ay kung ano ito ay naghahanap tulad ngayon. Kaya kung ano ang makukuha mo sa NoSQL ay isang schema data na ay ganap na nakatali sa access pattern. 

At maaari mong i-optimize na schema data upang suportahan ang ganoong access pattern. Kung hindi mo nagawa, pagkatapos ikaw ay pagpunta upang makita ang mga uri ng mga problema may mga hot keys. 

Madla: Well, hindi maaaring hindi ilang mga lugar ay magiging mas mainit kaysa sa iba. 

RICK Houlihan: Laging. Laging. Oo, ang ibig sabihin ko may laging a-- at muli, may ang ilang mga pattern na disenyo babalikan ka namin sa pamamagitan ng na makipag-usap tungkol sa kung paano makitungo sa iyo sa mga sobrang malalaking pagsasama-sama. Ibig sabihin ko, nakuha ko na magkaroon ng mga ito, paano namin pakikitungo sa kanila? Nakakuha ako ng isang magandang magandang pagkakataon ng paggamit na makikita usapan namin para doon. 

Lahat ng karapatan, kaya sabihin talk tungkol sa ilang mga customer ngayon. Ang mga guys ay AdRoll. Hindi ko alam kung ikaw ay pamilyar sa AdRoll. Ikaw ay malamang na makita ang mga ito isang pulutong sa browser. Sila ad muling pagta-target, ang mga ito ang pinakamalaking business ad re-targeting doon. Sila ay karaniwang regular na magpatakbo ng higit sa 60 bilyong mga transaksyon sa bawat araw. Sila ay gumagawa ng higit sa isang milyong mga transaksyon sa bawat segundo. Sila na nakuha ng isang medyo simpleng mesa istraktura, ang pinaka-abalang table. Ito ay karaniwang lamang ng isang hash key ay ang cookie, ang hanay ay ang demographic kategorya, at pagkatapos ay ang ikatlong katangian ay ang marka. 

Kaya namin ang lahat ng mga cookies sa ang aming browser mula sa mga guys. At kapag ikaw ay pupunta sa isang kalahok na merchant, sila talaga ang puntos mo sa kabuuan iba't-ibang mga demographic na mga kategorya. Kapag pumunta ka sa isang website at sinasabi mo na gusto kong makita ang ad-- o talaga hindi mo sasabihin na- ngunit kapag ikaw ay pumunta sa website sinasabi nila na gusto mong makita ang ad na ito. At pumunta sila makakuha na ad mula AdRoll. Mukhang mong AdRoll up sa kanilang mga mesa. Sila mahanap ang iyong mga cookie. Ang mga advertiser na nagsasabi , gusto ko ang mga ito ng isang tao sino ang nasa katanghaliang-gulang, 40-taon gulang na tao, sa sports. At ang puntos mo sila sa mga demographics at magpasya kung o hindi sila iyan ay isang magandang ad para sa iyo. 

Ngayon ay mayroon sila ng isang SLA sa kanilang mga nagbibigay ng advertising upang magbigay ng sub-10 millisecond Bilang tugon sa bawat solong kahilingan. Kaya sila ay gumagamit ng Dynamo DB para sa mga ito. Sila ay pagpindot sa amin ng isang milyong mga kahilingan sa bawat segundo. Ang mga ito ay maaaring gawin ang lahat ng kanilang mga lookups, triage ang lahat ng data na iyon, at kumuha na link add bumalik sa na advertiser sa ilalim ng 10 milliseconds. Ito ay talagang pretty kahanga-hanga pagpapatupad na mayroon sila. 

Ang mga guys actually-- ay ang mga ito sa mga guys. Hindi ako sigurado kung ito ay ang mga guys. Maaaring maging ang mga guys. Talaga sinabi us-- no, ako hindi nag-iisip na ito ay ang mga ito. Sa tingin ko ito ay may ibang tao. Ako ay nagtatrabaho sa isang customer na sinabi sa akin na ngayon na sila na wala na sa Dynamo DB, ang mga ito ay higit pa sa paggastos ng pera sa mga meryenda para sa ang kanilang mga koponan sa pag-unlad ng bawat buwan kaysa sa gastusin nila sa kanilang database. Kaya ito ay magbibigay sa iyo ng isang ideya ng mga pagtitipid ng gastos na maaari mong makuha sa Dynamo DB ay malaking. Lahat ng karapatan, dropcam ang isa pang kumpanya. Ang mga tao ay uri of-- kung sa tingin mo ng internet ng mga bagay, dropcam ay talaga internet security video. Mong ilagay ang iyong camera out doon. Camera ay may motion detector. May isang tao ay kasama, trigger ng isang cue point. Nagsisimula Camera record para sa isang habang hanggang ito ay hindi nakakita ng anumang paggalaw anymore. Naglalagay ng video na hanggang sa internet. 

Dropcam ay isang kumpanya na ay talaga inililipat sa Dynamo DB dahil sila ay nakakaranas napakalaking lumalaki ng panganganak. At kung ano ang sinabi nila sa amin, biglang petabytes ng data. Sila ay walang mga ideya sa kanilang serbisyo ay magiging matagumpay. Iba pa dumarating video sa YouTube ay kung ano ang mga guys ay pagkuha. Ginagamit nila DynamoDB upang subaybayan ang lahat ng mga metadata sa lahat ng kanilang mga video key points. 

Kaya sila S3 buckets sila itulak lahat ng mga binary artifacts sa. At pagkatapos ay mayroon sila Dynamo DB talaan na punto ng mga tao sa mga S3 tatlong bagay. Kapag kailangan nila upang tumingin sa isang video, maghanap sila ng record sa Dynamo DB. Sila-click ang link. Sila pull down ang video mula sa S3. Kaya na uri ng kung ano ito ay ganito ang hitsura. At ito ay tuwid mula sa kanilang team. 

Dynamo DB binabawasan ang kanilang paghahatid ng oras para sa mga kaganapan na video mula sa lima hanggang 10 segundo. Sa kanilang lumang store relational, ginagamit ang mga ito upang magkaroon ng upang pumunta at isakatuparan maramihang mga kumplikadong mga query sa figure kung aling mga video sa pull down, sa mas mababa sa 50 milliseconds. Kaya ito ay amazing, amazing kung magkano ang pagganap maaari kang makakuha ng kapag na-optimize at sa iyo na ibagay ang kalakip na database upang suportahan ang access pattern. Halfbrick, ang mga guys, kung ano ang mga ito, Fruit Ninja Hulaan ko ay ang kanilang mga bagay. Na ang lahat ay tumatakbo sa Dynamo DB. At ang mga lalaki, ang mga ito ay isang mahusay na unlad ng koponan, mahusay na pag-unlad shop. 

Hindi isang magandang team ops. Hindi nila ay may isang pulutong ng mga mapagkukunan ng operasyon. Sila ay nahihirapan sinusubukan na panatilihin kanilang imprastraktura up application at tumatakbo. Sila ay dumating sa amin. Sila ay tumingin sa na Dynamo DB. Sinabi nila, na para sa amin. Binuo nila ang kanilang buong application framework sa mga ito. Ang ilang mga talagang maganda ang mga komento dito mula sa koponan sa kanilang kakayahan sa ngayon focus sa gusali ang laro at hindi pagkakaroon upang mapanatili ang imprastraktura, na ay nagiging isang malaking halaga ng sa itaas para sa kanilang koponan. Kaya ito ay isang bagay na na- ang makinabang na nakukuha mo mula sa Dynamo DB. 

Lahat ng mga karapatan, sa pagkuha sa modeling dito data. At pinag-usapan namin ng kaunti tungkol sa ito ang isa sa isa, isa sa maraming, at marami sa maraming mga relasyon type. At paano mo mapanatili ang mga nasa Dynamo. Sa Dynamo DB ginagamit namin ini-index, karaniwang pagsasalita, upang i-rotate ang mga data mula sa isa lasa sa iba. Hash key, hanay key, at ini-index. 

Sa partikular na Halimbawa, tulad ng karamihan ng mga estado magkaroon ng isang pangangailangan sa paglilisensya na lamang ng lisensya sa isa sa pagmamaneho bawat tao. Hindi ka maaaring pumunta upang makakuha ng dalawang pagmamaneho lisensya sa estado ng Boston. Hindi ko kayang gawin ito sa Texas. Iyon uri ng mga paraan na ito ay. At kaya sa DMV, mayroon kaming lookup, namin gusto mong maghanap ng lisensya sa pagmamaneho sa pamamagitan ng mga social security number. Gusto kong tumingin up ang mga detalye ng gumagamit sa pamamagitan ng numero ng lisensya sa pagmamaneho. 

Kaya maaari naming magkaroon ng talahanayan ng isang gumagamit na may hash key sa serial number, o ang numero ng social security, at iba't-ibang mga katangian na tinukoy sa item. Now on na mesa ko maaaring tukuyin ang isang GSI na flips na sa paligid na nagsasabing gusto ko sumira ng isang key sa lisensya at pagkatapos ay lahat ng iba pang mga item. Ngayon kung gusto ko para sa mga tanong at hanapin ang numero ng lisensya para sa anumang naibigay Social Number Security, maaari ko query sa pangunahing table. 

Kung gusto ko para sa mga tanong at gusto ko upang makuha ang social security numero o iba pang mga katangian sa pamamagitan ng isang numero ng lisensya, ang maaari kong i-query ang GSI. Modelo na ito ay isa na sa isang relasyon. Lamang ng isang napaka-simpleng GSI, flip ang mga bagay sa paligid. Ngayon, makipag-usap tungkol sa isa sa maraming. Isa sa maraming ay isa lamang iyong saklaw ng hash key. Saan kami makakuha ng isang pulutong na may ganitong gamitin kaso ay data monitor. Monitor data lumapit sa regular pagitan, tulad ng internet ng mga bagay. Kami ay palaging makakuha ng lahat ng mga talaan darating sa lahat ng oras. 

At gusto ko upang mahanap ang lahat ng mga pagbasa sa pagitan ng isang partikular na tagal ng panahon. Ito ay isang napaka-pangkaraniwan query sa monitoring infrastructure. Ang paraan go tungkol sa na ay upang mahanap ang isang simpleng istraktura ng talahanayan, isa table. Mayroon akong isang sukat device talahanayan may isang hash key sa ID ng aparato. At ako ay may isang hanay na key sa timestamp, o sa kasong ito, ang epic. At na nagbibigay-daan sa akin isakatuparan kumplikadong tanong laban na hanay key at bumalik sa mga talaan na mga kamag-anak sa mga resulta set na ako naghahanap. At ito ay gagawa ng isa na sa maraming mga relasyon sa pangunahing talahanayan gamit ang hash key, range key istraktura. 

Kaya na uri ng built sa talahanayan sa Dynamo DB. Kapag ko tutukuyin ang isang hash at hanay t table, ako pagtukoy sa isang isa sa maraming relasyon. Ito ay isang magulang-anak relasyon. 

Makipag-usap tungkol sa maraming Ipaalam sa maraming mga relasyon. At para sa partikular na halimbawa, muli, kami ay pagpunta sa gamitin ang GSI ni. At makipag-usap tungkol gaming ipaalam sitwasyon kung saan mayroon akong isang ibinigay na user. Gusto kong malaman ang lahat ng mga laro na nakarehistro siya para sa o nagpe-play sa. At para sa isang ibinigay na laro, ako nais na mahanap ang lahat ng mga gumagamit. Kaya paano ko gawin iyon? Mesa My games user, pupuntahan ko na magkaroon ng isang hash key ng user ID at isang hanay key ng laro. 

Kaya ang isang user ay maaaring magkaroon ng maramihang mga games. Ito ay isang isa sa maraming mga relasyon sa pagitan ng mga user at ang mga laro siya ay gumaganap. At pagkatapos sa GSI, Kukunin ko i-flip na paligid. Kukunin ko hash sa laro at Kukunin ko ng saklaw sa mga gumagamit. Kaya kung nais ko upang makakuha ng lahat ng mga laro ng gumagamit sa pag-play sa, Kukunin ko i-query ang pangunahing table. Kung gusto ko upang makakuha ng lahat ng mga gumagamit na ay naglalaro ng isang partikular na laro, Query ko ang GSI. Kaya mo makita kung paano namin gawin ito? Bumuo ka ng mga GSI upang suportahan ang mga gamitin ang kaso, ang application na ito, ang pag-access pattern, ang mga application. 

Kung kailangan ko upang i-query sa sukat na ito, ipaalam sa ako gumawa ng isang index sa na dimensyon. Kung hindi ako, Wala akong pakialam. At depende sa paggamit kaso, ako maaaring kailangan ang index o huwag akong. Kung ito ay isang simpleng isa sa maraming, ang pangunahing talahanayan ay fine. Kung kailangan kong gawin ito ng maraming sa maraming, o kailangan kong gawin ang isa sa mga iyan, pagkatapos ay marahil na kailangan ko sa ikalawang ang index. Kaya lahat ng ito ay depende sa ano ang sinusubukan ko na gawin at kung ano ang sinusubukan ko upang makakuha ng tapos na. 

Marahil hindi ako pagpunta sa gastusin ng masyadong karaming oras ng pakikipag-usap tungkol sa mga dokumento. Ito ay makakakuha ng isang maliit na piraso, marahil, mas malalim kaysa sa kailangan namin upang pumunta sa. Makipag-usap nang kaunti Ipaalam tungkol sa mga rich expression query. Kaya sa Dynamo DB kami ang kakayahan na gumawa ano ang tawag namin projection expression. Projection expression ay lamang pagpili ng mga patlang o ang mga halaga na gusto mong ipakita. OK, kaya gumawa ako ng isang seleksyon. Gumawa ako ng isang query laban Dynamo DB. At sinasabi ko, alam mo kung ano, palabas sa akin lamang ang limang star na mga review para sa partikular na produkto. Kaya na ang lahat na gusto kong makita. Hindi ko nais na makita ang lahat ng iba pang mga katangian ng hilera, Gusto ko lang upang makita ito. Ito ay tulad ng sa SQL kapag ikaw sabihin piliin star o mula sa table, makakakuha ka ng lahat ng bagay. Kapag sinasabi ko piliin ang pangalan mula table, ako lamang makakuha ng isa attribute. Ito ay ang parehong uri ng bagay sa Dynamo DB o iba NoSQL database. Payagan ako Filter expression upang talaga kunin ang mga resulta set down. Kaya ako gumawa ng isang query. Query ay maaaring bumalik sa 500 na mga aytem. Ngunit tanging gusto ko ang mga bagay na ay may isang katangian na nagsasabing ito. OK, salain ang mga item na iyon upang ipaalam na hindi tumutugma sa partikular na query. Kaya kami ay may filter expression. 

Filter expression Maaari tumakbo sa anumang attribute. Hindi sila ay gusto query range. Itaas ang mga query ay mas pumipili. Nangangailangan ako Filter query upang pumunta makakuha ng set at pagkatapos ay ang buong mga resulta mag-ukit out ang data hindi ko gusto. Bakit na mahalaga? Dahil nabasa ko ang lahat ng ito. Sa isang query, ako pagpunta upang basahin at ito ay magiging isang higanteng tungkol data. At pagkatapos ay ako pagpunta sa mag-ukit out kung ano ang kailangan ko. At kung ako lamang ang larawang inukit ang isang pares ng mga hilera, pagkatapos na ang OK. Ito ay hindi kaya walang kakayahan. 

Ngunit kung ako sa pagbabasa ng isang buong tumpok ng data, upang mag-ukit lamang out ng isang item, pagkatapos ay ako pagpunta upang maging mas mahusay off ang paggamit ng isang query na hanay, dahil ito ay mas pumipili. Ito ay pagpunta upang i-save sa akin ng maraming pera, dahil babayaran ko para sa na read. Saan ang mga resulta na dumating likod cross na wire ay maaaring maging mas maliit, ngunit ako nagbabayad para sa mga nabasa na. Kaya maunawaan kung paano ikaw ay nakakakuha ng data. Iyan ay napakahalaga sa Dynamo DB. 

Kondisyong expression, ito ay kung ano maaari mong tawagan maasahin locking. Update KUNG umiiral, o kung ang halaga na ito ay katumbas ng kung ano ang aking tinukoy. At kung ako ay may time stamp sa isang rekord, maaari ako basahin ang data. Baka ako baguhin na data. Baka pumunta ako write na data pabalik sa database. Kung ang isang tao ay nagbago ang record, baka nagbago ang timestamp. At ang paraan ng aking kondisyon masasabi update update kung katumbas ito ng timestamp. O ang pag-update ay mabibigo dahil sa isang tao na-update ang mga rekord sa habang panahon. 

Iyon ay kung ano ang tawag namin maasahin locking. Ito ay nangangahulugan na ang isang tao maaaring dumating sa at baguhin ito, at ako pagpunta upang makita ito kapag pumunta ako pabalik na magsulat. At pagkatapos ay ako maaaring aktwal na basahin na data at sabihin, oh, siya ay nagbago ito. Kailangan ko na account para sa. At maaari ko bang baguhin ang data sa aking i-record at mag-aplay ng isa pang update. Kaya maaari mong abutin ang mga incremental update na nangyari sa pagitan ng oras na basahin mo ang data at ang mga oras maaari mong isulat ang data. 

Madla: At ang mga filter expression aktwal na nangangahulugan na hindi sa numero o not-- 

[INTERPOSING tinig] RICK Houlihan: Ayaw ko makakuha ng masyadong marami sa mga ito. Ito ba ang isang reserved keyword. Ang pound view ay isang reserved keyword sa Dynamo DB. Bawat database ay may sariling reserved pangalan para sa mga koleksyon na hindi mo maaaring gamitin. Dynamo DB, kung tinukoy mo ang ng kalahating kilong sa harap ng mga ito, maaari mong tukuyin ang hanggang sa mga pangalan sa itaas. Ito ay isang na-reference na halaga. Ito ay marahil hindi ang pinakamahusay na syntax na Mayroon up doon para sa talakayang ito, dahil ito ay nakakakuha sa ilang real-- Gusto ko ay pakikipag-usap ng mas maraming tungkol na sa isang mas malalim na antas. 

Ngunit makasapat upang sabihin, ito ay maaaring maging query scan kung saan sila views-- hindi rin nakakita pound ay mas malaki sa 10. Ito ay isang de-numerong halaga, yes. Kung gusto mo, maaari kaming makipag-usap tungkol sa na pagkatapos ng talakayan. Lahat ng karapatan, kaya kami ay nakakakuha sa ilang mga pangyayari sa mga pinakamahusay na kasanayan kung saan kami ay pagpunta sa makipag-usap tungkol sa ilang mga apps dito. Ano ang mga kaso ng paggamit para Dynamo DB. Ano ang mga disenyo pattern sa Dynamo DB. 

At ang unang isa namin ang pagpunta sa makipag-usap tungkol ay ang internet ng mga bagay. Kaya makakuha kami ng maraming of-- Hulaan ko, ano ang it-- higit sa 50% ng trapiko sa internet mga araw na ito ay tunay na binuo sa pamamagitan ng machine, automated na proseso, hindi sa pamamagitan ng mga kawani na tao. Ibig sabihin ko ang bagay na ito ang bagay na ito na dalhin mo sa paligid sa iyong bulsa, kung magkano ang data na bagay na aktwal na pagpapadala sa paligid nang hindi mo pag-alam ito ay ganap amazing. Ang iyong lokasyon, impormasyon tungkol sa kung paano mabilis na ikaw ay pagpunta. Paano mo tingin mga gawa Google Maps kapag sinabi mo sa mga ito kung ano ang trapiko ay. Ito ay dahil may mga milyon-milyon at milyon-milyong mga tao sa pagmamaneho sa paligid may phone na pagpapadala data sa lahat ng dako ng lugar sa lahat ng oras. Kaya isa sa mga bagay-bagay tungkol sa ganitong uri ng data na nanggagaling sa, data monitor, mag-log data, data oras serye, ay ito ay karaniwang mga kagiliw-giliw lamang para sa isang maliit na piraso ng oras. Pagkatapos ng oras na iyon, ito ay hindi kaya kawili-wili. Kaya pinag-usapan namin ang tungkol sa, huwag hayaang mga tables lumaki nang walang hangganan. Ang ideya dito ay na siguro Mayroon akong 24 oras na halaga ng mga kaganapan sa aking mainit na table. At na hot talahanayan ay magiging provision sa isang mataas na rate, dahil ito ay ang pagkuha ng isang pulutong ng data. Ito ay ang pagkuha ng isang pulutong ng data sa loob at ako pagbabasa ito ng maraming. Mayroon akong isang pulutong ng mga operasyon mga query na tumatakbo laban sa data na iyon. 

Matapos ang 24 oras, hey, ikaw malaman kung ano, Wala akong pakialam. Kaya marahil bawat hatinggabi ko roll ang aking mga talahanayan sa ibabaw sa isang bagong mesa at deprovision ko talahanayan na ito. At kukunin ko na gawin ang mga RCU at Pababa WCU dahil 24 na oras mamaya Hindi ko pinapatakbo sa bilang ng maraming mga tanong laban sa data na iyon. Kaya ako pagpunta sa i-save ang pera. At siguro 30 na araw sa paglaon hindi ako kahit na kailangan sa pag-aalaga tungkol sa lahat ng ito. Kaya kong gawin ang WCU ni lahat ng mga paraan pababa sa isa, dahil alam mo kung ano, ito ay hindi kailanman pagpunta upang makakuha ng nakasulat na. Ang data ay 30 araw na ang edad. Ito ay hindi nagbabago. 

At ito ay halos hindi kailanman pagpunta upang makakuha ng basahin, kaya lang kumuha na RCU pababa sa 10 ipaalam. At ako nagse-save ng isang tonelada ng pera sa mga ito data, at pagbabayad lamang para sa aking mainit na data. Kaya na ang mga mahahalagang bagay na sa hitsura at kapag tumingin ka sa isang serye ng oras data na nanggagaling sa sa dami. Ang mga ito ay mga estratehiya. Ngayon, maaari ko lamang ipaalam ito lahat ng pumunta sa parehong mesa at ipaalam lamang sa table na palaguin. Sa paglaon, ako pagpunta sa makita ang mga isyu sa pagganap. Pupunta ako sa may upang simulan ang pag-archive ng ang ilan sa mga data na iyon mula sa mesa, kung ano ang hindi. 

Sabihin mas mas mahusay na disenyo ng iyong application sa gayon ay maaari mong patakbuhin ang ganitong paraan ng karapatan. Kaya lamang automatic sa application code. Sa hatinggabi gabi-gabi ito listahan ng talahanayan. Siguro kung ano ang kailangan ko ay isang sliding window ng 24 na oras ng data. Pagkatapos ay sa isang regular na batayan Ako pagtawag off ang talahanayan ng data. Ako dekorasyon ito na may isang Cron trabaho at ako ng paglagay ito papunta sa mga iba pang mga talahanayan, kahit anong kailangan mo. Kaya kung gumagana ng rollover, na malaki. Kung hindi, putulin ito. Ngunit panatilihin na hot data ipaalam layo mula sa iyong malamig na data. Makikita ito i-save ka ng maraming pera at gawin ang iyong mga talahanayan ng higit na gumaganap. Kaya ang susunod na bagay na makikita namin makipag-usap tungkol ay produkto ng catalog. Produkto catalog ay pretty karaniwang pagkakataon ng paggamit. Ito ay talagang isang napaka-karaniwang pattern na makikita namin makita sa isang iba't ibang mga bagay. Alam mo yun, Twitter para sa Halimbawa, ang isang hot tweet. Ang bawat ay darating at daklot na tweet. Produkto catalog, Nakatanggap ako ng sale. Nakakuha ako ng isang hot sale. Nakakuha ako ng 70,000 mga kahilingan sa bawat ikalawang pagdating para sa isang produkto paglalarawan sa labas ng aking mga produkto catalog. Nakita namin ito sa retail operasyon pa ng kaunti. Kaya kung paano namin pakikitungo sa mga iyon? Walang paraan upang harapin ang mga iyon. Lahat ng aking mga gumagamit na nais upang makita ang ang parehong piraso ng data. Ang mga ito ay nagmumula sa, Kasabay. At lahat sila ay paggawa ng mga kahilingan para sa parehong piraso ng data. Nagbibigay sa akin ito na ang hot key, na malaki red guhit sa aking mga chart na hindi namin gusto. At na kung ano na kamukha. Kaya sa kabuuan ng aking key space ko nakukuha hammered sa mga item sale. Wala ko natatanggap kahit saan pa. 

Paano ko magpakalma ang problemang ito? Well, magpakalma namin sa cache. Cache, ilagay mo talaga ng isang in-memory pagkahati sa harap ng database. Kami ay pinamamahalaang [Hindi marinig] cache, kung paano mo maaaring i-set up ang iyong sariling mga cache, [hindi marinig] cache [? d,?] kahit anong gusto mo. Ilagay na up sa harap ng database. At ang paraan na maaari mong iimbak ang data mula sa mga hot keys up sa na cache space at basahin sa pamamagitan ng cache. 

At pagkatapos ay ang karamihan ng iyong mga nagbabasa simulan ang hinahanap tulad nito. Lahat ang nakuha ko hit up dito mga cache at ang nakuha ko walang pagpunta sa down dito dahil database ay nakaupo sa likod ng cache at ang mga nagbabasa ay hindi kailanman dumating sa pamamagitan ng. Kung babaguhin ko ang mga data sa database, kailangan kong i-update ang cache. Maaari naming gamitin ang isang bagay tulad steams upang gawin iyon. At kukunin ko na ipaliwanag kung paano na gumagana. Lahat ng karapatan, messaging. Email, namin ang lahat ng gamitin ang email. 

Ito ay isang medyo magandang halimbawa. Nakakuha kami ng ilang mga uri ng mga mensahe table. At nakuha namin inbox at outbox. Ito ay kung ano ang SQL gagawin hitsura upang bumuo ng inbox na iyon. Uri namin ng gamitin ang parehong uri ng mga diskarte upang gamitin GSI ni, GSI ni para sa aking inbox at ang aking outbox. Kaya ang nakuha ko raw mga mensahe pagdating sa aking mga mensahe table. At ang unang diskarte sa ito ay maaaring maging, sabihin, OK, walang problema. Mayroon akong raw mensahe. Mga Mensahe darating [hindi marinig], message ID, na malaki. Iyon ang aking natatanging hash. Pupunta ako upang lumikha ng dalawang GSI, isa para sa aking inbox, isa para sa aking outbox. At ang unang bagay na kailangan kong gawin ay kukunin ko na sabihin ang aking hash key ay magiging ang tatanggap at Pupunta ako upang ayusin ang petsa. Ito ay walang katotohanan. Nakatanggap ako ang aking magandang tanawin dito. Subalit mayroong isang maliit na isyu dito. At tumakbo ka sa ito sa pamanggit database pati na rin. Sila ay tinatawag na patayo partitioning. Gusto mong panatilihin ang iyong malaking data layo mula sa iyong maliit na data. 

At ang dahilan kung bakit ay dahil ako gotta pumunta basahin ang mga item upang makakuha ng mga katangian. At kung ang aking katawan ay ang lahat sa dito, pagkatapos ay pagbabasa lamang ng ilang mga item kung ang aking katawan haba ay average ng 256 kilobytes bawat isa, ang matematika ay makakakuha ng medyo mainit ang ulo. Kaya sabihin na gusto kong basahin inbox ni David. Inbox ni David ay may 50 na mga aytem. Ang average at laki ay 256 kilobytes. Ito ang aking ratio ng conversion para RCU ay apat na kilobytes. 

OK, sabihin pumunta sa pare-pareho sa huli bumabasa. Ako kumakain 1600 RCU pa rin lamang na basahin ang inbox ni David. Ouch. OK, sabihin isipin ngayon hayaan tungkol sa kung paano gumagana ang app. Kung ako sa isang email app at Naghahanap ako sa aking inbox, at ako ay tumingin sa katawan ng bawat mensahe, Wala, Naghahanap ako ng sa mga buod. Naghahanap ako sa lamang ang mga header. Kaya ipaalam sa bumuo ng isang istraktura ng talahanayan na mukhang mas tulad ng. 

Kaya dito ay ang mga impormasyon na ang mga pangangailangan ng aking workflow. Ito ay sa aking inbox GSI. Ito ay ang petsa, ang nagpadala, ang paksa, at pagkatapos ay ang ID na mensahe, na puntos bumalik sa mga mensahe ng talahanayan kung saan ako makakakuha ng katawan. Well, ang mga ito ay magiging record ID. Gusto nila point bumalik sa item IDs sa Dynamo DB table. Bawat index laging creates-- laging may item ID bilang bahagi of-- na nanggagaling sa mga index. 

Lahat tama. Madla: Ito ay nagsasabi na ito kung saan naka-imbak ito? RICK Houlihan: Oo, ito ay nagsasabi exactly-- na eksakto kung ano ang ginagawa nito. Sinasabi nito dito ang aking record re. At makikita ito ituro ito pabalik sa aking record re. Mismong. OK, ang aking inbox kaya ngayon ay talagang mas maliit. At ito ang tunay na sinusuportahan ang daloy ng trabaho ng isang email app. Kaya ang aking inbox, i-click ko. Pumunta ako kasama at i-click ako sa mensahe, na kapag kailangan ko upang pumunta makakuha ng katawan, dahil ako pagpunta sa pumunta sa isang iba't ibang mga view. Kaya kung sa tingin mo ang tungkol sa mga uri ng MVC framework, tingnan model controller. 

Naglalaman ng model ang mga data na ang mga pangangailangan na view at ang controller nakikipag-ugnayan sa. Kapag binago ko ang mga frame, kapag Baguhin ko ang pananaw, ito ay ang OK upang bumalik sa server at repopulate sa modelo, dahil na kung ano ang inaasahan sa gumagamit. Kapag binago nila ang nakakita, na kapag maaari naming bumalik sa database. Kaya email, i-click ang. Naghahanap ako ng katawan. Papunta at pabalik. Pumunta makakuha ng katawan. 

Ako basahin ang isang pulutong ng mas kaunting data. Ako ng pagbabasa lamang ang mga katawan na David pangangailangan kapag siya ay nangangailangan ng mga ito. At hindi ako sumunog sa 1600 RCU upang ipakita lamang ang kanyang inbox. Kaya ngayon na- ito ay ang paraan na LSI o GSI-- Sorry, GSI, ay gumagana out. Mayroon kami ng aming hash sa mga tatanggap. Mayroon din kaming mga hanay na key sa petsa. At nakuha namin ang mga inaasahang katangian na kailangan lamang namin upang suportahan ang mga view. 

Paikutin namin na para sa outbox. Sumira sa nagpadala. At sa kakanyahan, kami ay ang very nice, clean view. At ito ay basically-- namin na ito ay may magandang mensahe mesa na ini kumalat mabuti dahil ito ay hash lamang, na-hash ID mensahe. At kami ay may dalawang index na ay umiikot off ng talahanayan. Lahat ng karapatan, kaya ideya dito ay hindi panatilihin ang malaking data at ito maliit na data sama-sama. Partisyon patayo, pagkahati mga tables. Huwag basahin ang data na hindi mo na kailangang. Lahat ng karapatan, gaming. Namin ang lahat ng mga laro. Hindi bababa sa gusto ko pagkatapos games. Kaya ang ilan sa mga bagay-bagay na aming pakikitungo sa kapag pinag-iisipan namin ang tungkol sa gaming, di ba? Paglalaro ng mga araw, lalo na mobile gaming, ay tungkol sa lahat na pag-iisip. At ako pagpunta upang i-rotate dito ng isang maliit na piraso ang layo mula DynamoDB. Pupunta ako upang dalhin sa ang ilan sa mga talakayan sa paligid ang ilan sa mga iba pang mga teknolohiya AWS. 

Ngunit ang mga ideya tungkol sa gaming ay mag-isip tungkol sa mga tuntunin ng API API na,, karaniwang pagsasalita, HTTP at JSON. Ito ay kung paano mobile games uri ng makipag-ugnayan sa kanilang mga dulo ng likod. Gawin nila ang JSON-post. Makakuha ng mga ito ng data, at ito ay ang lahat, karaniwang pagsasalita, sa ganda ng JSON APIs. 

Mga bagay tulad ng makakuha ng mga kaibigan, kumuha ng ang data leaderboard, exchange, nilalamang binuo ng gumagamit, uurong up sa sistema, ang mga ito ay mga uri ng mga bagay-bagay na kami ay pagpunta sa gawin. Binary data asset, ang data na ito Maaaring hindi umupo sa database. Ito ay maaaring umupo sa isang object store, di ba? Ngunit ang mga database ay pagpunta sa end up na nagsasabi sa sistema, nagsasabi ng application kung saan pumunta makakuha ng ito. At hindi maaaring hindi, Multiplayer servers, end infrastructure back, at dinisenyo para sa mataas na availability at kakayahang sumukat. Kaya ang mga ito ay mga bagay na namin ang lahat ng gusto sa imprastraktura gaming ngayon. 

Kaya sabihin kumuha ng isang pagtingin sa kung ano na kamukha. Mayroon ka bang isang core likod ng pagtatapos, tunay tapat. Nakakuha kami ng isang sistema dito sa maramihang availability zones. Usapan natin ang tungkol Azs bilang being-- tingin ng mga ito bilang mga hiwalay na mga data center. Higit sa isang data center per AZ, ngunit iyan ay OK, lamang sa tingin ng mga ito bilang mga hiwalay na data centers na heograpiya at kasalanan ihiwalay. 

Kami ay pagpunta sa magkaroon ng isang pagkakataon pares EC2. Kami ay pagpunta sa may ilang back end server. Siguro kung ikaw ay isang legacy architecture, hindi namin gamit ang kung ano ang tawag namin sa RDS, pamanggit database ng mga serbisyo. Puwede na MSSQL, MySQL, o isang bagay tulad na. Ito ang paraan ng maraming mga application ay dinisenyo ngayon. 

Well kami maaaring gusto mong pumunta sa ito ay kapag ang scale out namin. Susubukan naming sige, at ilagay ang S3 bucket up doon. At na S3 bucket, sa halip ng paghahatid up ang mga bagay mula sa aming mga servers-- maaari naming gawin iyon. Ilagay mo ang lahat ng iyong mga binary bagay sa iyong server at maaari mong gamitin ang mga server mga pagkakataon upang maglingkod na data up. Ngunit iyon lamang ang medyo mahal. 

Mas mahusay na paraan upang gawin ay magpatuloy at maglagay ng mga bagay sa isang S3 bucket. S3 ay isang object repositoryo. Partikular na ito ay binuo para sa serving up ang mga uri ng mga bagay-bagay. At hayaang humiling sa mga kliyente direkta mula sa mga object bucket, offload ang mga server. Kaya kami ay nagsisimula upang masukat out dito. 

Ngayon namin nakuha ang mga gumagamit sa buong mundo. Nakatanggap ako ng mga gumagamit. Kailangan kong magkaroon ng nilalaman sa isang lugar lamang na matatagpuan malapit sa mga user na ito, i-right? Lumikha ako ng isang S3 bucket bilang aking pinagmulan repository. At kukunin ko na front na may ang CloudFront pamamahagi. 

CloudFront ay isang CD at isang ang paghahatid ng network ng nilalaman. Karaniwang ito ay tumatagal ng data na iyong tinukoy at mga cache lahat ng ito sa internet upang ang mga gumagamit sa lahat ng dako ay maaaring magkaroon ng isang mabilis na tugon kapag silang humiling ng mga bagay. 

Kaya mo makakuha ng isang ideya. Uri ng Ikaw ay pagdaragdag ng lahat ng mga aspeto ng AWS dito upang makakuha ng ito tapos. At sa huli, itapon namin sa isang auto scaling group. Kaya ang aming mga pagkakataon AC2 ng aming mga server ng laro, simulan nila upang makakuha ng busier at busier at busier, makikita lang nila iikot ang isa pang Halimbawa, iikot ang isa pang halimbawa, iikot ng isa pang halimbawa. Kaya ang teknolohiya AWS ay may, ito ay nagpapahintulot sa iyo na tukuyin ang mga parameter sa paligid ng kung saan ang iyong mga server ay lalaki. Kaya maaari kang magkaroon n bilang ng mga server out there sa anumang naibigay na oras. At kung ang iyong load napupunta ang layo, makikita nila pag-urong, ang bilang ay pag-urong. At kung ang load ay bumalik, Makikita ito maging likod out, elastically. 

Kaya mahusay na ito ay mukhang. Nakakuha kami ng isang pulutong ng mga pagkakataon EC2. Maaari naming ilagay ang cache in harap ng mga database, subukan at mapabilis ang mga database. Ang susunod na presyon ng point karaniwang mga tao na makita ay ang laki sila ng isang laro gamit ang isang pamanggit database system. Jeez, ang database pagganap ay napakahirap. Paano pagbutihin namin iyon? Subukan ang paglagay Ipaalam cache sa harap ng mga iyon. 

Well, cache ay hindi gumagana kaya mahusay sa games, di ba? Para sa mga laro, ang pagsusulat ay masakit. Mga Laro ay napaka isulat mabigat. Cache ay hindi gumagana kapag ikaw ay isulat mabigat dahil na sa iyo na laging Nakakuha upang i-update ang cache. I-update mo ang cache, ito ay hindi kaugnay na pag-cache. Ito ay talagang lamang dagdag na trabaho. 

Kaya kung saan tayo pupunta dito? Nakuha mo na ang isang malaking bottleneck down doon sa database. At ang lugar na dapat puntahan malinaw naman ay partisyon. Partitioning ay hindi madaling gawin kapag ikaw ay pagharap sa pamanggit database. Sa pamanggit database, ikaw ay responsable para sa pamamahala, mabisa, ang susi space. Ikaw ay sinasabi ang mga gumagamit sa pagitan ng A at M pumunta dito, sa pagitan ng N at Z pumunta doon. At lilipat ka sa kabila ng application. Kaya ikaw ay pagharap sa ito partition data source. Mayroon kang limitasyon transactional na hindi sumasaklaw sa partisyon. Nakuha mo na ang lahat ng uri ng messiness na kayo pagharap sa ibaba roon sinusubukan upang harapin ang scaling out at pagbuo ng isang mas malaking infrastructure. Ito lang ang hindi masaya. 

Madla: Kaya ikaw ay sinasabi na pagtaas ng mga puntos na source pinapabilis ang proseso? RICK Houlihan: Ang pagtaas? Madla: Source points. RICK Houlihan: Source points? Madla: Mula sa impormasyon, kung saan ang impormasyon ay nagmumula? RICK Houlihan: No. Ano ako sinasabi ay ang pagtaas ng bilang ng mga partitions sa tindahan ng data nagpapabuti throughput. Kaya kung ano ang nangyayari dito ay gumagamit ng pagdating sa EC2 halimbawa dito, well, kung kailangan ko ng isang user iyan ay isang m, kailangan ko pumunta dito. Mula N sa p, kukunin ko na pumunta dito. Mula P hanggang Z, kailangan ko pumunta dito. 

Madla: OK, mga kaya ang mga ito ay lahat ng naka-imbak sa iba't-ibang mga nodes? 

RICK Houlihan Oo. Mag-isip ng mga ito bilang iba't ibang silos ng data. Kaya ikaw ay may sa gawin ito. Kung sinusubukan na gawin ito, kung sinusubukan sa scale sa isang pamanggit platform, ito ay kung ano ang ginagawa mo. Ikaw ay ang pagkuha ng data at ikaw ay pagputol ito pababa. At ikaw ay partitioning ito sa buong maraming mga pagkakataon ng database. At namamahala ka ng lahat na sa tier application. Ito ay hindi masaya. Kaya kung ano ang gusto namin upang pumunta? Gusto naming pumunta DynamoDB, ganap na pinamamahalaang, NoSQL store data, pagkakaloob throughput. Ginagamit namin ang pangalawang index. Ito ay isa lamang HTTP API at kabilang ang suporta ng dokumento. Kaya hindi mo na kailangang mag-alala tungkol sa anumang ng na-partisyon. Ginagawa namin ang lahat ng ito para sa iyo. Kaya ngayon, sa halip, maaari mo isulat lang sa table. Kung kailangan ng talahanayan upang Hahatiin, na ang mangyayari sa likod ng mga eksena. Ganap ka insulated mula sa na bilang isang developer. Kaya sabihin makipag-usap tungkol ang ilan sa mga kaso na paggamit na tumakbo kami sa sa paglalaro, karaniwang pangyayari gaming, leaderboard. Kaya mayroon ka gumagamit na pumapasok, ang BoardNames na ang mga ito on, ang mga marka para sa gumagamit na ito. Maaari naming maging hashing sa inyong ID, at pagkatapos ay mayroon kaming hanay sa laro. Kaya ang nagnanais na makita ang bawat user lahat ng mga laro siya ay nag-play at ang lahat ng kanyang pinakamataas na iskor sa lahat ng mga laro. Kaya na ang kanyang personal na leaderboard. 

Ngayon, gusto kong pumunta sa at gusto kong get-- kaya nakukuha ko ang mga personal na mga leaderboard. Ano ang gusto kong gawin ay pumunta makakuha ng ang pinakamataas na iskor sa lahat ng mga gumagamit. Kaya paano ko gawin iyon? Kapag ang aking record ay na-hash sa ang inyong ID, ranged sa laro, well ako pagpunta sa sige at restructure, lumikha ng isang GSI, at ako pagpunta sa restructure na data. 

Ngayon ako pagpunta sa hash sa BoardName, na kung saan ay ang laro. At ako pagpunta sa hanay sa itaas na marka. At ngayon Ako ay lumikha ng iba't ibang mga bucket. Ako gamit ang parehong mesa, ang parehong data item. Ngunit Lumilikha ako ng isang bucket na nagbibigay sa sa akin ng isang pagsasama-sama ng pinakamataas na iskor sa pamamagitan ng laro. 

At maaari kong i-query table na upang makakuha ng impormasyon na iyon. Kaya ko na-set na pattern query hanggang sa suportahan ng isang pangalawang index. Ngayon ay maaari silang nakaayos ayon BoardName at nakaayos ayon sa TopScore, depende sa. Kaya maaari mong makita, ang mga ito ay mga uri ng gamitin ang mga kaso na makukuha mo sa paglalaro. Ang isa pang mahusay na gamitin ang kaso na nakukuha namin sa gaming ay parangal at kung sino ang nanalo sa awards. At ito ay isang mahusay na pagkakataon ng paggamit kung saan ang tawag namin sa kalat-kalat na ini-index. Kalat-kalat na index ay ang mga kakayahan upang makabuo ng isang index na ay hindi kinakailangang maglaman ang bawat isang item sa talahanayan. At bakit hindi? Dahil ang mga katangiang iyon ay pagiging na-index na ay hindi umiiral sa bawat item. 

Kaya sa mga partikular na gamitin ang kaso, ako sinasabi, alam mo kung ano, ako pagpunta sa lumikha ng isang katangian na tinatawag Award. At ako pagpunta upang bigyan ang bawat user na may isang award na attribute. Ang mga gumagamit na hindi magkaroon ng parangal ay hindi pagpunta sa may katangiang iyon. Kaya kapag gumawa ako ng index, ang mga gumagamit lamang na pagpunta sa ipakita up sa index ay ang mga na talagang may won awards. Kaya na ang isang mahusay na paraan upang ma upang lumikha ng mga filter sa mga index na ay tunay, tunay pumipili na hindi kung index ang buong table. 

Kaya kami ay nakakakuha ng mababa sa oras dito. Pupunta ako sa sige at laktawan out at laktawan ang sitwasyong ito. Makipag-usap nang kaunti about-- 

Madla: Maaari ko bang hilingin ang isang mabilis na tanong? Ang isa ay sumulat ng mabigat? RICK Houlihan: Ano? Madla: Magsulat mabigat. RICK Houlihan: Sumulat mabigat. Hayaan akong makita. 

Madla: O ay na hindi isang bagay na maaari mo lamang boses sa sa isang bagay ng segundo? RICK Houlihan: Pumunta kami sa pamamagitan ng mga sitwasyon sa pagboto. Ito ay hindi na masamang. Ka guys ay may ilang mga minuto? SIGE. 

Kaya makikita namin makipag-usap tungkol sa pagboto. Kaya real time sa pagboto, kami ay mga kinakailangan para sa pagboto. Kinakailangan ay na pinapayagan namin sa bawat tao na bumoto nang isang beses lamang. Gusto naming walang tao para ma upang baguhin ang kanilang boto. Gusto naming real-time ng pagsasama-sama at analytics para sa demographics na kami ay magiging nagpapakita sa mga gumagamit sa site. 

Mag-isip ng ganitong sitwasyon. Kami ay isang pulutong ng mga katotohanan TV ay nagpapakita kung saan ang mga ito ay paggawa ng mga tumpak na uri ng mga bagay-bagay. Kaya maaari mong isipin ang sitwasyon, kami ay may milyon-milyong at milyon-milyong ng mga dalagitang doon sa kanilang mga cell phone at pagboto, at pagboto, at pagboto para sa sino man sila mahanap na ang pinaka-popular. Kaya ang mga ito ay ilan sa mga kinakailangan namin tumakbo out. 

At kaya ang unang kumuha ng sa paglutas ng problemang ito ay upang bumuo ng isang napaka-simpleng application. Kaya Mayroon akong app na ito. Mayroon akong ilang mga botante out doon. Dumating sila, sila ay pindutin ang app pagboto. Mayroon akong ilang mga talahanayan raw boto Kukunin ko na lang tambakan ng mga boto sa. Kukunin ko ang ilang mga pinagsama-samang boto table na ang gagawin ng aking analytics at demograpiko, at kami ay ilagay ang lahat ng ito sa doon. 

At ito ay mahusay. Maganda ang buhay. Buhay mabuti hanggang sa nakita namin out na may laging lamang ng isa o dalawang tao na sikat sa isang halalan. Mayroon lamang ng isa o dalawang mga bagay-bagay na ang mga tao talagang nagmamalasakit tungkol sa. At kung ikaw ay boboto sa scale, ang lahat ng isang biglaang ako magiging pagmamartilyo ang impiyerno sa labas ng dalawang kandidato, ang isa o dalawang kandidato. Ang isang limitadong bilang ng mga item mga tao na mahanap na maging popular. 

Ito ay hindi isang magandang pattern disenyo. Ito ay talagang isang napakasama pattern disenyo dahil ito ay lumilikha ng eksakto kung ano ang aming usapan tungkol sa kung saan ay hot keys. Hot key ay isang bagay na hindi namin gusto. 

Kaya paano namin ayusin na? At talagang, ang mga paraan upang ayusin ito ay sa pamamagitan ng pagkuha ng mga kandidato timba at para sa bawat kandidato na namin, kami ay pagpunta upang isama ang isang random na halaga, isang bagay na alam natin, random halaga sa pagitan ng isa at 100, sa pagitan ng 100 at 1000, o sa pagitan ng isa at 1000, subalit maraming mga random na mga halaga na nais mong ikakabit papunta sa dulo ng kandidatong iyon. 

At kung ano ang ko talagang gawin pagkatapos? Kung gumagamit ako ng kandidato ID bilang mga bucket sa pinagsama-samang boto, kung nagdagdag ako ng isang random number sa dulo ng mga iyon, Na aking nilikha ngayon 10 buckets, isang daang mga bucket, ang isang libong mga bucket na ako ng pagsasama-sama ng mga boto sa kabuuan. 

Kaya ko bang milyon-milyong, at milyon-milyon, at milyon-milyong mga talaan na pumapasok para sa mga kandidato, ngayon ako nagkakalat mga boto sa buong Candidate A_1 sa pamamagitan ng Kandidato A_100, dahil sa bawat oras na ang isang boto ay dumating sa, Ako sa pagbuo ng isang random halaga sa pagitan ng isa at 100. Ako tacking ito papunta sa dulo ng kandidato ng taong iyon ang pagboto para sa. Ako paglalaglag ito sa na bucket. 

Ngayon sa likuran, alam ko na nakuha ko sa isang daang mga bucket. Kaya kapag gusto ko na sige at pinagsasama-sama ang mga boto, Nabasa ko mula sa lahat ng mga bucket. Kaya ko sige at idagdag. At pagkatapos ay ako ang scatter magtipon kung saan ako pumunta at sabihin hey, alam mo kung ano, key kandidato na ito ni puwang ay higit sa isang daang mga bucket. Pupunta ako upang tipunin ang lahat ng Binoboto mula sa mga daang bucket. Pupunta ako sa pinagsama-samang ang mga ito at ako pagpunta sa sabihin, Candidate A ay mayroon na ngayong kabuuang bilang ng boto ng mga x. 

Ngayon parehong mga write Query at ang read query ay mabuti ipinamamahagi dahil ako ng sulat sa kabuuan at ako pagbabasa sa daan-daang mga susi. Hindi ko na pagsulat at pagbabasa sa kabuuan ng isa key na ngayon. Kaya na ang isang mahusay na pattern. 

Ito ay tunay na marahil ang isa sa pinaka mahalagang mga disenyo mga pattern para sa scale sa NoSQL. Makikita mo ang ganitong uri ng design pattern sa bawat lasa. MongoDB, DynamoDB, ito ay hindi matter, namin ang lahat ng may sa gawin ito. Dahil kapag ikaw ay pakikitungo may mga malaking aggregations, ikaw ay may upang malaman ng isang paraan upang ikakalat ang mga ito sa labas sa kabila bucket. Kaya ito ay ang paraan na gawin mo iyon. Lahat ng karapatan, kaya kung ano ang ikaw ay gumagawa ngayon ay ikaw ay Trading off read gastos para sa write kakayahang sumukat. Ang gastos ng aking basahin ay isang maliit na mas kumplikadong at kailangan kong pumunta basahin mula sa isang daang mga bucket halip ng isa. Ngunit ako magagawang magsulat. At ang aking throughput, ang aking write throughput ay hindi kapani-paniwala. Kaya ito ay karaniwang isang mahalagang pamamaraan para sa pagsusukat DynamoDB, o anumang NoSQL database para sa mga bagay. Kaya naisip namin kung paano upang masukat ang mga ito. At naisip namin kung paano sa puksain ang aming hot keys. At ito ay walang katotohanan. At nakuha namin ang ganda ng system. At ito ay nagbigay sa amin napaka-tama sa pagboto dahil kami ay may record na boto de-manloko. Ito ay binuo sa DynamoDB. Usapan natin ang tungkol kondisyong karapatan. 

Kapag ang isang botante sa, naglalagay isang isingit sa table, ipasok ang mga ito sa kanilang mga botante ID, kung sila ay subukan upang magsingit ng isa pang boto, Gagawin ko ang isang kondisyon write. Sabihin lamang isulat ito kung ito ay hindi umiiral. Kaya sa lalong madaling nakikita ko na hit na boto sa table, walang ibang tao ay magiging maaaring ilagay ang kanilang mga boto sa. At iyan ay hindi kapani-paniwala. At kami ay incrementing aming mga kandidato counter. At ang aming ginagawa sa aming mga demograpiko at ang lahat na. Ngunit ano ang mangyayari kung ang aking application ay bumaba sa ibabaw? Ngayon ang lahat ng isang biglaang mga boto ay pumapasok, at ako hindi alam kung sila ay nakakakuha naproseso sa aking analytics at demograpiko anymore. At kapag ang application dumating back up, kung paano ang impiyerno ko malalaman kung ano ang mayroon boto na-proseso at kung saan ako magsisimula? 

Kaya ito ay isang tunay na problema kapag ikaw simulan upang tumingin sa ganitong uri ng sitwasyon. At paano namin malutas na? Malutas namin ito sa kung ano ang aming tumawag DynamoDB Stream. Streams ay iniutos ng isang oras at partitioned pagbabago log ng bawat access sa talahanayan, ang bawat isulat access sa mga table. Ang anumang data na nakasulat sa na talahanayan ay nagpapakita ng hanggang sa stream. 

Ito ay karaniwang isang 24 na oras na queue. Item pindutin ang stream, sila nakatira sa loob ng 24 na oras. Sila ay maaaring basahin ng maraming beses. Ginagarantiya upang maihatid lamang ng isang beses sa stream, mabasa n bilang ng beses. Kaya gayunpaman maraming mga proseso na nais mong ubusin na data, maaari mong tunawin. Ito ay lilitaw sa bawat update. Bawat write ay lamang lumitaw nang isang beses sa stream. Kaya hindi mo na kailangang mag-alala tungkol sa pagpoproseso ng ito ng dalawang beses mula sa parehong proseso. 

Mahigpit na ito ay iniutos sa bawat item. Kapag sinabi naming oras iniutos at partitioned, makikita mo ang bawat pagkahati sa stream. Makikita mo na mga aytem, ​​mga update sa order. Hindi namin ay guaranteeing sa stream na kayo pagpunta upang makakuha ng bawat transaksyon sa pagkakasunud-sunod sa kabuuan item. 

Kaya batis ay idempotent. Huwag namin ang lahat ng kung ano ang ibig sabihin idempotent? Idempotent nangangahulugan na maaari mong gawin ito loob, at higit, at sa muli. Ang resulta ay magiging pareho. 

Stream ay idempotent, ngunit mayroon sila upang maging play mula sa panimulang punto, kung saan ninyo pumili, sa dulo, o hindi sila ay magreresulta sa parehong halaga. 

Parehong bagay sa MongoDB. MongoDB ay isang tayuan tinatawag nila ang oplog. Ito ay ang eksaktong parehong tayuan. Maraming mga database NoSQL magkaroon ng ganitong tayuan. Ginagamit nila ito upang gawin ang mga bagay tulad ng pagtitiklop, na ay kung ano mismo ang ginagawa namin sa batis. Madla: Maaari isang erehe tanong, ngunit ikaw makipag-usap tungkol apps ginagawa down ng isang iba pa. Sigurado garantisadong stream na hindi kailanman pumunta down marahil? RICK Houlihan: Oo, batis ay garantisadong hindi kailanman pumunta down. Pangasiwaan namin ang infrastructure sa likod. awtomatikong stream lumawak sa kanilang auto scaling group. Kami ay pumunta sa pamamagitan ng isang maliit na bit tungkol sa kung ano ang mangyayari. 

Hindi ko dapat sabihin na ang mga ito ay hindi garantisadong hindi kailanman pumunta pababa. Ang mga elemento ay garantisadong na lumitaw sa mga stream. At ang stream ay maa-access. Kaya kung ano ang napupunta down o lumapit sa likod up, na ang mangyayari sa ilalim. Ito covers-- ito ay OK. Lahat ng karapatan, kaya makakakuha ka ng iba't-ibang view ng uri ng off ang screen. Ang mga uri ng view na mahalaga sa isang karaniwang programmer ay, kung ano ang ito? Nakukuha ko ang lumang view. Kapag ang isang pag-update ay pinindot niya ang table, makikita ito itulak ang mga lumang tanawin ng stream kaya maaaring ilagay sa archive ng data, o baguhin control, baguhin ang pagkilala, pagbabago management. 

Ang bagong imahe, kung ano ito ngayon pagkatapos ng ang update, iyon ang isa pang uri ng view maaari kang makakuha. Maaari kang makakuha ng parehong luma at bagong larawan. Siguro gusto ko sa kanila pareho. Gusto kong makita kung ano iyon. Gusto kong makita kung ano ang nagbago ito sa. 

Mayroon akong isang uri ng pagsunod ng proseso na tumatakbo. Ito mga pangangailangan upang i-verify na kapag nagbago ang mga bagay-bagay, na ang mga ito sa loob ng ilang mga limitasyon o sa loob ng ilang mga parameter. 

At pagkatapos ay marahil ko lamang kailangan malaman kung ano ang nagbago. Wala akong pakialam kung ano ang item nagbago. Hindi ko kailangan sa kailangan upang malaman ano ang mga katangian nagbago. Kailangan ko lang malaman na ang mga bagay ay hinawakan. Kaya ito ang mga uri ng mga tanawin na makakuha ka off ang stream at maaari kang makipag-ugnay sa. 

Ang application na consumes ang stream, ito ay uri ng ang paraan na ito ay gumagana. DynamoDB client hilingin na itulak ang data sa mga mesa. Streams deploy sa kung ano ang tawag namin shards. Shards ay naka-scale malaya ng table. Hindi nila pumila ganap sa partisyon ng iyong talahanayan. At ang dahilan kung bakit dahil sila line up sa kakayahan, ang kasalukuyang kapasidad ng table. 

Lumawak ang mga ito sa kanilang mga sariling auto scaling group, at simulan nila upang paikutin out depende sa kung gaano karaming magsusulat ay darating sa, kung gaano karaming mga reads-- talagang ito ay nagsusulat. Walang reads-- ngunit kung paano maraming magsusulat ay darating in. 

At pagkatapos ay sa likod end, kami ay kung ano ang aming tumawag sa isang KCL, o Kinesis Client Library. Kinesis ay isang data stream processing teknolohiya mula sa Amazon. At ang mga batis ay binuo sa mga iyon. 

Kaya gamitin mo pinagana ang isang KCL application na basahin ang mga stream. Ang Kinesis Client Library talagang namamahala sa mga manggagawa para sa iyo. At ito rin ay ilang kagiliw-giliw na mga bagay-bagay. Ito ay lumikha ng ilang mga talahanayan up sa iyong DynamoDB tablespace upang subaybayan kung aling mga item ay na-proseso. Kaya sa ganitong paraan na ito ay bumaba sa likod, kung ito ay bumaba sa loob at lumapit at nakakakuha nakatayo back up, maaari itong matukoy kung saan ay ito sa pagproseso ng stream. 

Iyon ay lubhang mahalaga kapag ikaw ay pakikipag-usap tungkol sa pagtitiklop. Kailangan kong malaman kung ano ang ay na-proseso ang data at kung ano ang data ay hindi pa na-proseso. Kaya ang KCL library para sa mga daloy ay magbibigay sa iyo ng isang pulutong ng mga na pag-andar. Ito ay tumatagal ng pag-aalaga ng lahat ng mga gawaing-bahay. Ito ay nakatayo up ang isang manggagawa para sa bawat share. Ito ay lumilikha ng isang administrative talahanayan para sa bawat share, para sa bawat worker. At bilang mga fire manggagawa, mapanatili nila ang mga talahanayan upang malaman mo ang ulat na ito Binasa at naproseso. At pagkatapos na ang paraan kung ang proseso namatay at nag-online sa likod, maaari itong ipagpatuloy ang karapatan kung saan ito kinuha off. 

Kaya ito ay ginagamit namin para sa cross-rehiyon pagtitiklop. Ang isang pulutong ng mga customer ang mga pangangailangan upang ilipat ang data o mga bahagi ng kanilang mga talahanayan ng data paligid sa iba't ibang mga rehiyon. Mayroong siyam na mga rehiyon sa buong mundo. Kaya ito ay maaaring maging isang need-- ako doon Maaaring magkaroon ng mga gumagamit sa Asya, ang mga gumagamit sa East Coast ng Estados Unidos. Sila ay may iba't ibang mga data na Kailangang ma lokal na ibinahagi. At siguro ang isang user ay lilipad mula sa Asya sa ibabaw sa Estados Unidos, at gusto kong magtiklop ang kanyang mga data sa kanya. Kaya kapag siya ay makakakuha ng off ang eroplano, siya ay isang mahusay na karanasan sa paggamit ng kanyang mobile app. 

Maaari mong gamitin ang cross-rehiyon pagtitiklop library upang gawin ito. Talaga kami ibinigay ng dalawang mga teknolohiya. One ay isang console application maaari kang tumayo sa iyong sariling EC2 halimbawa. Ito ay nagpapatakbo ng purong pagtitiklop. At pagkatapos ay ibinigay namin sa inyo ang library. Ang aklatan ay maaari mong gamitin upang bumuo ng ng iyong sariling mga application kung ikaw nais na gawin nakatutuwang mga bagay na may na data-- filter, ginagaya lamang ng bahagi ng mga ito, i-rotate ang data, ilipat ito sa isang iba't-ibang mga talahanayan, kaya sa at iba pa. Kaya na uri ng kung ano na kamukha. 

DynamoDB Streams maaaring maging proseso sa pamamagitan ng kung ano ang tawag namin sa Lambda. Binanggit namin ng kaunti tungkol sa event driven architecture application. Lambda ay isang pangunahing bahagi ng mga iyon. Lambda ay code na apoy on demand bilang tugon sa isang partikular na kaganapan. Isa sa mga pangyayaring iyon ay maaaring isang record na lumalabas sa stream. Kung ang isang record ay lilitaw sa stream, kami ay tumawag ito Java function. Well, ito ay ang JavaScript, at Lambda Sinusuportahan Node.js, Java, Python, at malapit nang suportahan iba pang mga wika pati na rin. At makasapat upang sabihin, ito ay purong code. isulat Sa Java, tukuyin ang isang klase. Itulak mo ang jar up sa Lambda. At pagkatapos mong tukuyin kung aling mga klase na tumawag sa mga tugon sa na kaganapan. At pagkatapos ay ang infrastructure Lambda sa likod na tatakbo na code. 

Maaaring iproseso ang code na iyon talaan off ang stream. Maaari itong gawin anumang bagay na ito ay nais sa mga ito. Sa partikular na halimbawa kung lahat tayo talagang ginagawa ng pag-log ang mga katangian. Ngunit ito ay code lamang. Code ay maaaring gumawa ng kahit ano, tama? 

Kaya maaari mong i-rotate na data. Maaari kang lumikha ng mga hinangong view. Kung ito ay isang dokumento na istraktura, maaari mong patagin ang istraktura. Maaari kang lumikha ng kahaliling mga index. Lahat ng uri ng bagay na maaari mong gawin sa mga DynamoDB Stream. 

At talagang, na kung ano na kamukha. Kaya makakakuha ka ng mga update darating in. Sila ay darating off ang string. Ang mga ito ay basahin sa pamamagitan ng Lambda function. Sila ay umiikot ang data at pagtulak ito sa loob ng mga hinalaw na mga talahanayan, aabiso panlabas na mga sistema ng pagbabago, at pagtulak ng data sa ElastiCache. 

Usapan natin ang tungkol sa kung paano ilagay ang cache sa harap ng database para sa mga benta na sitwasyon. Well kung ano ang mangyayari kung ako i-update ang paglalarawan ng item? Well, kung ako ay isang Lambda function na tumatakbo sa table na, kung ako i-update ang paglalarawan ng item, makikita ito pick up ang mga record off ang stream, at ia-update nito ang ElastiCache halimbawa sa mga bagong data. Kaya na ang isang pulutong ng mga kung ano ang ginagawa namin sa Lambda. Ito ay pandikit code, konektor. At ito ang tunay na nagbibigay ng kakayahan upang ilunsad at upang patakbuhin ang napaka-komplikadong mga aplikasyon walang isang dedikado server infrastructure, na kung saan ay talagang cool. 

Kaya sabihin bumalik sa aming real-time architecture pagboto. Ito ang bago at pinahusay na gamit ang aming batis at KCL pinagana application. Kapareho ng mga bago, maaari naming humawak ng anumang laki ng halalan. Tulad namin ito. Kami ay gumagawa out scatter nangangalap sa kabuuan ng maramihang mga bucket. Mayroon kami ng maasahin locking nangyayari. Maaari naming panatilihin ang aming mga botante mula sa pagbabago ng kanilang mga boto. Sila ay maaari lamang bumoto nang isang beses lamang. Ito ay walang katotohanan. Real-time kasalanan pagpapaubaya, scalable pagsasama-sama ngayon. Kung ang mga bagay ay bumaba sa paglipas, ito alam kung saan upang i-restart ang sarili pagdating back up dahil kami ay gumagamit ng KCL app. At pagkatapos ay maaari naming ring gamitin na KCL application upang itulak data sa labas na redshift para sa iba pang app analytics, o paggamit ang nababanat MapReduce na tumakbo real-time streaming off aggregations ng data na iyon. 

Kaya ito ang mga bagay na aming hindi uusapang tungkol magkano. Ngunit ang mga ito ng karagdagang mga teknolohiya na dumating upang dalhin kapag naghahanap ka sa ganitong mga uri ng mga sitwasyon. 

Lahat ng karapatan, kaya na ang tungkol sa analytics na may DynamoDB Stream. Maaari mong mangolekta ng de-lokohin data, gawin ang lahat ng uri ng ganda ng mga bagay-bagay, pinagsama-samang data sa memory, lumikha ng mga hinangong mga talahanayan. Iyan ay isang malaking pagkakataon ng paggamit na ang isang pulutong ng mga customer ay kasangkot sa, pagkuha ng mga nested mga katangian ng mga JSON dokumento at paglikha ng karagdagang mga index. 

Humihingi kami sa dulo. Salamat sa iyo para sa tindig sa akin. Kaya sabihin makipag-usap tungkol architecture reference. DynamoDB nakapatong sa gitna ng kaya marami ng imprastraktura AWS. Talaga maaari mong isabit ito hanggang sa anumang nais mo. Aplikasyon binuo gamit Dynamo isama Lambda, ElastiCache, CloudSearch, itulak ang data sa nababanat MapReduce, import export mula DynamoDB sa S3, ang lahat ng mga uri ng daloy ng trabaho. Ngunit marahil ang pinakamahusay na bagay na pag-uusapan, at ito ay kung ano ang talagang kagiliw-giliw na ay kapag kami makipag-usap tungkol sa mga aplikasyon driven na kaganapan. 

Ito ay isang halimbawa ng isang panloob na proyekto na kami kung saan kami talaga publishing upang makalikom ng mga resulta ng survey. Kaya sa isang email na link na magpadala out namin, may makikita maging isang maliit na link na nagsasabi click dito upang tumugon sa mga survey. At kapag ang isang tao pag-click na link, kung ano ang mangyayari ay ang pull down sila ng isang ligtas na HTML survey form mula sa S3. Walang server. Ito ay lamang ng isang S3 object. 

Form na lumalabas, naglo-load ng hanggang sa browser. Ito ay nakuha ng gulugod. Ito ay nakuha ng complex JavaScript na ito ay tumatakbo. Kaya napaka-mayaman na application tumatakbo sa browser ng kliyente. Hindi nila alam na sila ay hindi nakikipag-ugnayan sa isang back end server. Sa puntong ito, ito ay ang lahat ng browser. 

Sila-publish ang mga resulta sa kung ano ang ang tawag namin sa Amazon API Gateway. API Gateway ay lamang ng isang web API na maaari mong tukuyin at isabit sa kung anong gusto mo. Sa partikular na kasong, hindi namin baluktot up sa isang Lambda function. 

Kaya ang aking POST operasyon ay nangyayari na walang server. Karaniwang na API Gateway nakapatong doon. Sa akin wala hanggang sa mga tao Nagkakahalaga ito simulan pag-post sa mga ito, right? Ang Lambda function na lamang nakapatong doon. At wala ito gastos sa akin hanggang simulan tao pagpindot ito. Kaya maaari mong makita, pati na ang lakas ng tunog mga pagtaas, na kapag ang mga singil darating. Hindi ko pinapatakbo sa isang server 7/24. 

Kaya makuha ko ang form down sa labas ng bucket, at i-post ko sa pamamagitan ng API Gateway sa Lambda function. At pagkatapos ay ang Lambda sabi function, alam mo ano, Mayroon akong ilang PIIs, ang ilang mga personal na makikilalang impormasyon sa mga kasagutan. Nakatanggap ako ng komento na nanggagaling mula sa mga gumagamit. Mayroon akong email address. Mayroon akong mga username. 

Hayaan akong nahati ito off. Pupunta ako upang bumuo ng ilang metadata off ang talang ito. At ako pagpunta sa itulak ang metadata sa DynamoDB. At ako ay maaaring i-encrypt ang lahat ng data at itulak ito sa DynamoDB kung gusto ko. Ngunit ito ay mas madali para sa akin, sa ganitong gamitin ang kaso, sige isang sabihin, Pupunta ako upang itulak ang raw data na ito sa isang naka-encrypt na S3 bucket. Kaya gamitin ko built in S3 server side encryption at Key Management Amazon Serbisyo upang ako ay may isang key na maaaring i-rotate sa isang regular na pagitan, at maaari kong protektahan ang data na iyon PII bilang bahagi ng mga ito ang buong daloy ng trabaho. 

Kaya kung ano ang ginawa ko? Lamang ko na ipinakalat ng isang buong application, at wala akong mga server. Kaya kung ano ang kaganapang hinihimok application architecture ay para sa iyo. 

Ngayon kung sa tingin mo ang tungkol sa ang paggamit kaso para this-- kami ay may iba pang mga customer ko pakikipag-usap na tungkol sa eksaktong architecture na tumakbo phenomenally malaking kampanya, na ay tumitingin sa mga ito at tuloy, oh aking. Dahil ngayon, maaari nilang itulak talaga ito doon, hayaan kampanya na umupo lamang doon hanggang naglulunsad ito, at hindi mag-alala ang isang fig tungkol kung anong uri ng infrastructure ay magiging doon upang suportahan ang mga ito. At pagkatapos ay sa lalong madaling kampanya na ay tapos na, ito ay tulad ng infrastructure lang agad napupunta ang layo dahil may tunay Walang infrastructure. Ito ay code lamang na nakapatong sa Lambda. Ito lang ang data na makikita sa DynamoDB. Ito ay isang kamangha-manghang paraan upang bumuo ng mga application. 

Madla: Kaya ito ay mas ephemeral sa magiging kung ito ay naka-imbak sa isang aktwal na server? 

RICK Houlihan: Ganap. Dahil na halimbawa server ay kailangang maging isang 7/24. Ito ay upang maging magagamit para sa isang tao na tumugon sa. Well hulaan kung ano? S3 ay magagamit 7/24. Laging tumugon S3. At S3 ay tunay, tunay mabuti serving up ng mga bagay. Ang mga bagay ay maaaring maging HTML file, o File ng JavaScript, o kahit anong gusto mo. Maaari kang magpatakbo ng napaka-mayaman mga web application sa labas ng S3 balde, at ang mga tao gawin. 

At kaya na ang mga ideya dito ay upang makakuha ng layo mula sa mga paraan ginamit namin upang isipin ang tungkol dito. Namin ang lahat ng ginamit upang isipin in mga tuntunin ng mga server at host. Ito ay hindi tungkol sa ngayon. Ito ay tungkol sa imprastraktura ng code. I-deploy ang code sa ulap at pabayaan ang mga ulap tumakbo ito para sa iyo. At iyan ang AWS ay sinusubukan na gawin. 

Madla: Kaya ang iyong kahon ng ginto sa gitna ng API Gateway ay hindi server-like, ngunit sa halip ay just-- 

RICK Houlihan: Maaari mong isipin ng mga ito bilang facade server. Lahat ng ito ay ay makikita itong tumagal ng isang HTTP humiling at mapa ito sa isa pang proseso. Iyan na ang lahat ng ginagawa nito. At sa kasong ito, kami ay paggawa ng mga mapa ito sa isang Lambda function. Lahat ng karapatan, kaya na ang lahat nakuha ko. Maraming salamat. Pinapahalagahan ko ito. Alam ko gusto namin ng isang maliit na piraso sa paglipas ng panahon. At sana ka guys got isang maliit na piraso ng impormasyon na maaari mong gawin ang layo sa araw na ito. At humihingi ako ng paumanhin kung ako nagpunta higit sa ilan sa inyong mga ulo, ngunit mayroong isang magandang maraming pangunahing foundational kaalaman na sa tingin ko ay lubos na mahalaga para sa iyo. Kaya salamat sa iyo para sa pagkakaroon ng akin. [Palakpakan] Madla: [hindi marinig] ay kapag ikaw ay sinasabi kayo ay pumunta sa pamamagitan ng mga bagay mula sa simula hanggang sa wakas upang makuha ang tamang mga halaga o sa parehong halaga, kung paano gagawin ang mga halaga baguhin kung [hindi marinig]. 

RICK Houlihan: Oh, idempotent? Paano baguhin ang mga halaga? Well, dahil kung ako ay hindi tatakbo ito sa lahat ng mga paraan sa dulo, pagkatapos ay hindi ko alam kung ano ang mga pagbabago ay ginawa sa huling milya. Ito ay hindi magiging ang parehong data bilang kung ano ang nakita ko. Madla: Oh, kaya mo lamang hindi tapat na paraan ang buong input. RICK Houlihan: Kanan. Mayroon kang pumunta mula sa simula sa dulo, at pagkatapos ito ay pagpunta sa isang pare-pareho ng estado. Cool. 

Madla: Kaya ka nagpakita sa amin DynamoDB maaaring gawin dokumento o ang key na halaga. At kami na ginugol ng maraming oras sa key halaga na may hash at ang mga paraan upang i-flip ito sa paligid. Kapag tumingin ka sa mga talahanayan, ay na Aalis sa likod ng mga diskarte dokumento? 

RICK Houlihan: hindi ko ibig sabihin iwan dito sa likod. 

Madla: Sila ay hiwalay mula the-- 

RICK Houlihan: Gamit ang mga dokumento diskarte, ang uri dokumento DynamoDB ay sa tingin lamang ng isa pang katangian. Ito ay isang katangian na naglalaman ng isang hierarchical istraktura ng data. At pagkatapos ay sa query, maaari mong gamitin ang mga katangian ng mga bagay gamit ang Bagay pagtatanda. Kaya ang maaari kong i-filter sa isang nested ari-arian ng JSON dokumento. Madla: Kaya anumang oras na ako gawin ang isang diskarte na dokumento, Maaari ko bang uri ng makarating sa tabular-- Madla: Ganap. Madla: --indexes at bagay uusapang mo lang ang tungkol. RICK Houlihan: Oo, ang ini-index at ang lahat na, kapag gusto mong i-index ang mga katangian ng JSON, ang paraan na gusto namin upang gawin iyon ay kung mong ipasok ang isang JSON object o isang dokumento sa Dynamo, nais mong gamitin stream. Streams ay basahin ang input. Gusto mong makakuha na JSON bagay at gusto mong sabihin OK, kung ano ang mga ari-arian na gusto kong i-index? 

Lumikha ka ng isang hinalaw na table. Ngayon na ang paraan na ito ay gumagana sa ngayon. Hindi namin pinapayagan sa iyo upang index direkta sa mga properties. 

Madla: Tabularizing iyong mga dokumento. 

RICK Houlihan: Eksakto, pagyupi ito, tabularizing ito, eksakto. Iyon ay kung ano ang gagawin mo sa mga ito. 

Madla: Salamat sa iyo. 

RICK Houlihan: Oo, ganap na, salamat. Madla: Kaya ito ay uri ng Mongo nakakatugon Redis classifers. 

RICK Houlihan: Oo, ito ay isang pulutong na tulad ng. Iyon ay isang mahusay na paglalarawan para sa mga ito. Cool.