[Музички] RICK Houlihan: Во ред. Здраво на сите. Моето име е Рик Houlihan. Јас сум висок главница решенија архитект во AWS. Се фокусираат на NoSQL и DynamoDB технологии. Јас сум тука денес да се зборува за ви малку за нив. 

Моето потекло е првенствено во податоците слој. Поминав половина мојот развој кариера пишување база на податоци, пристап до податоци, решенија за различни апликации. Сум бил во Облак виртуелизација за околу 20 години. Па пред Облак беше Облак, ние се користат да го наречеме Нови компјутери. А идејата е, тоа е како ПГ & Е, да плаќаат за она што го користите. Денес ние ја нарекуваме, облакот. 

Но, со текот на годините, јас сум работел за неколку компании сте веројатно никогаш не слушнале. Но јас сум составил листа на технички достигнувања, претпоставувам дека би рекол. Имам осум патенти во Облак системи виртуелизација, микропроцесор дизајн, комплекс настан обработка, и во други области, како и. 

Така овие денови, јас се фокусираат главно на NoSQL технологии и на следната генерација база на податоци. И тоа е обично она што јас ќе одам за да бидам тука денес да разговараат со вас за. Така што можете да очекувате од оваа сесија, ние ќе одиме преку една кратка историја на обработка на податоци. Тоа секогаш е корисно да се разбере од каде сме дошле и зошто сме таму каде што сме. И ние ќе зборуваме малку малку за NoSQL технологија од фундаментален аспект. 

Ние ќе влезе во некои од на internals DynamoDB. DynamoDB постои вкус AWS е. Тоа е целосно управувана и хостирано решение NoSQL. И ние ќе зборуваме малку за на маса структура, s, типови на податоци, индекси, а некои од internals DynamoDB на таа технологија. Ние ќе дојдеме во некои од дизајн модели и најдобри практики. Ние ќе зборуваме за тоа како можете користат оваа технологија за некои на апликации денес. И потоа ќе зборуваме малку за еволуцијата или појава на нова парадигма во програмирање наречен апликации настан-управувано и како DynamoDB игра во која, како и. И ние ќе ви остави малку референца архитектура дискусија за да можеме да зборуваме за некои од на кои начини можете да го користите DynamoDB. 

Значи прво off-- ова е прашање Слушам многу е, што е базата на податоци. Многу луѓе мислат дека знаеш што е базата на податоци е. Ако на Google, ќе видите ова. Тоа е структуиран сет на податоци кои се чуваат во компјутер, особено оној кој е достапен во различни начини. Претпоставувам дека тоа е добра дефиниција за модерен базата на податоци. Но не ми се допаѓа, бидејќи тоа значи неколку работи. Тоа подразбира структура. А тоа значи дека тоа е на компјутер. И бази на податоци не секогаш постои на компјутери. Бази на податоци, всушност, постои во многу начини. 

Толку подобра дефиниција на база на податоци е нешто како ова. Базата на податоци е организирана механизам за чување, управување, и преземање на информацијата. Ова е од About.com. Па ми се допаѓа ова, бидејќи тоа навистина разговорите база на податоци за да се биде складиштето складиште на информации, не мора нешто што седи на компјутер. И во текот на историјата, ние не секогаш имале компјутери. 

Сега, ако јас побара од просечната инвеститорот денес што е база на податоци, тоа е одговорот да се добие. Некаде може да се држи работи. Нели? И тоа е вистина. Но, тоа е жално. Бидејќи базата на податоци е навистина основањето на модерна стан. Тоа е основа на секоја апликација. И како да се изгради дека база на податоци, како да ги организирате дека податоците нема да диктира како што примена врши како што можете да скала. 

Па многу од мојата работа денес се занимава со она што се случува кога програмерите земе овој пристап и справувањето со последиците на апликација која сега скалирање подалеку од оригиналот намера и страдање од лош дизајн. Па се надевам дека кога ќе се пешки Денес, ќе има неколку алатки во појас, кој ќе ве заштити од правење на истите грешки. Во ред. Па ајде да зборуваме за малку временската линија на технологијата на база. Мислам дека прочитав една член не дека одамна и тоа го рече нешто на lines-- тоа е многу поетски изјава. Таа рече дека историјата на податоци за обработка на е полн со високо водени жигови на изобилство податоци. ВО РЕД. Сега, претпоставувам дека тоа е вид на вистина. Но јас навистина се погледне е како историјата е всушност исполнета со висок жиг на притисок на податоците. Бидејќи податоците стапка на голтање никогаш не оди надолу. Тоа само оди нагоре. 

И иновации се случува кога гледаме притисок на податоци, која е износот на податоци кои се сега во кои доаѓаат во системот. И тоа не може да се обработи ефикасно или во време или во трошоците. И тоа е кога ќе почнеме да се погледне на притисок на податоците. 

Значи, кога ќе погледнеме во прва база на податоци, овој е онаа која беше меѓу нашите уши. Сите ние сме родени со неа. Тоа е убаво, база на податоци. Таа има висока достапност. Тоа е секогаш на. Секогаш може да го добие. 

Но, тоа е еден корисник. Не можам да споделам моите мисли со вас. Вие не може да се добие моите мисли кога ви се потребни. И нивните abilitiy не е толку добар. Нештата ги забораваме. Секоја сега и тогаш, еден од нас лисја и се движи кон друга постоење и ние ја изгуби сè што беше во таа база на податоци. Па тоа не е се толку добри. 

И ова работено и со текот на времето кога бевме назад во текот на денот кога сите ние навистина треба да знаете е Каде ќе одат на утре или каде што се собираат најдобрите храна. Но, како што почна да расте како цивилизацијата и Владата започна да дојде во битие, и бизниси почна да се развива, почнавме да сфаќаме треба малку повеќе од она што ние би можеле да се стави во нашата глава. Во ред? 

Ние потребни системи на евиденција. Ние потребни места за да се биде во можност за сместување податоци. Па почнавме пишување документи, создавање библиотеки и архиви. Почнавме заработка систем за сметководство надгробна плоча. И дека системот на броење Леџер движеа низ светот за многу векови, а можеби дури и милениуми како ние вид на се зголеми до точка каде што товарот податоци надмина способноста на оние системи за да може да го содржат. 

И ова всушност се случило во 1880 година. Нели? Во 1880 попис. Ова е навистина каде пресвртна укажуваат модерна обработка на податоци. Ова е точката во кој износот на податоци беше собрани од Владата на САД стигнав до точка каде биле потребни осум години да се процесира. 

Сега, осум years-- како што знаете, на пописот работи на секои 10 years-- така што е доста очигледно дека од страна на време ние добив пописот 1890 година, на износот на податоци кои требаше да бидат обработени од страна на Владата е ќе надмине 10 години дека тоа ќе биде потребно да го лансираше новиот попис. Ова беше проблем. 

Па еден човек со име Херман Hollerith дојдоа заедно и тој измислил единица рекорд удар картички, читач перфокарта, перфокарта tabulator, и споредување на механизмите за оваа технологија. И дека компанијата за која е формиран на време, заедно со неколку други, всушност стана еден од столбовите на мала компанија што го знаеме денес повика на IBM. 

Па IBM, првично беше во на бизнис база на податоци. И тоа е навистина она што го направија. Тие го направија обработка на податоци. 

Како така зголемувањето на бројот на удар картички, генијален механизми да се биде во можност да потпора дека технологијата да анкета сортирани групи резултат. Може да се види во оваа слика таму имаме little-- тоа е малку small-- но може да се види многу генијален механички механизам каде што имаме палуба перфокарта. И преземање нечиј малку шрафцигер и држејќи се преку слотови и го подига да се добие тој натпревар, дека постави подредени резултати. 

Ова е агрегација. Ние го правиме ова цело време денес во компјутерот, каде што ќе го направи тоа во нашата база. Ние се користат да се направи рачно, нели? Луѓе се стави овие работи заедно. И тоа е зголемувањето на бројот од овие удар картички во она што се нарекува тапани податоци и ленти податоци, хартија лента. 

Индустријата за обработка на податоците се лекција од пијана плеер. Играчот пијана назад на крајот на векот се користи за да се користи хартија ленти со слотови за да го каже кои копчиња да се игра. Така што технологијата е адаптирана на крајот за чување на дигитални податоци, бидејќи тие може да се стави тоа на податоци врз оние хартија лента ленти. 

Сега, како резултат на тоа, податоците беше actually-- како ви пристап до овие податоци е директно зависи од тоа како ќе го чуваат. Значи, ако јас се стави на податоци на лента, Морав да пристапите до податоците линеарно. Морав да се тркалаат на целиот лента за пристап до сите податоци. Ако го ставам на податоците во удар картички, би можел да го пристап во малку повеќе случајни мода, можеби не толку брзо. 

Но имаше ограничувања во тоа како ние пристап до податоци врз основа на тоа како се чуваат. Па така ова е проблем случува во 50-тите години. Повторно, може да почне да се види дека како што се развој на нови технологии за обработка на податоците, во право, тоа што се отвора вратата за нови решенија, за нови програми, нови апликации за податоците. И навистина, владеење може да е причината Затоа ние развивме некои од овие системи. Но брзо стана бизнис возачот зад еволуцијата на модерниот база на податоци и современиот датотечен систем. 

Затоа, следниот нешто што излезе беше во 50-тите беше на фајл системот и развој на случаен складирање пристап. Ова беше убава. Сега, сите одеднаш, ние може да се стави на нашите додадени фајлови: секаде на овие хард дискови а ние може да пристап до овие податоци по случаен избор. Ние може да се интерпретира дека информации од датотеки. И ние реши сите светски проблеми со обработка на податоци. 

И тоа траеше околу 20 или 30 години до еволуцијата на релациона база на податоци, која е кога светот решивме сега треба да имаат складиштето порази за ширење на податоци во датотека системи кои ние сме изградени. Нели? Премногу податоци дистрибуира во премногу места, де-дуплирање на податоци, како и трошоците за складирање беше огромна. 

Во 70-тите, најскапиот ресурс дека секој компјутер имавме беше за складирање. Процесорот е гледа како на фиксна цена. Кога ќе купи од кутијата, процесорот прави некоја работа. Тоа се случува да се врти дали тоа е всушност работат или не. Тоа е навистина потонат трошоци. 

Но, она што ме чини како бизнис е за чување. Ако треба да се купи повеќе дискови следната месец, тоа е вистински цена што се плати. И дека за складирање е скапо. 

Сега ние брзо напред 40 години и ние имаме друг проблем. Пресмета сега е најскапиот ресурс. Складирање е евтин. Мислам, можеме да одиме никаде на облак и ние може да се најдат евтини складирање. Но, она што не може да се најде е евтин пресмета. 

Така еволуцијата на денешниот технологија, технологијата на база на, е навистина фокусирана околу дистрибуирани бази на податоци кои не страдаат од на истиот тип на скала ограничувањата на релациони бази на податоци. Ние ќе зборуваме малку за она што тој всушност значи. 

Но, една од причините за тоа и возачот зад this-- ние зборуваше за притисок на податоците. Притисок на податоци е нешто кој вози иновации. И ако се погледне во текот на во последните пет години, ова е шема на она што на податоци оптоварување низ општата претпријатие изгледа како во последните пет години. 

И општо правило на палецот овие days-- ако одите Google-- е 90% од податоците кои ние продавница денес, и тоа беше добиени во последните две години. ВО РЕД. Сега, ова не е тренд што има ново. Ова е тренд и тоа е се Излегувам за 100 години. Уште од Herman Hollerith разви перфокарта, ние сме биле градење складишта на податоци и собирање на податоци во феноменален стапки. 

Па во текот на последните 100 години, видовме овој тренд. Тоа не се случува да се промени. Оди напред, ние ќе треба да се види ова, ако не забрзан тренд. И може да се види она што изгледа како тоа. 

Ако некој бизнис во 2010 година имаше еден Terabyte на податоци во рамките на управување, денес тоа значи дека тие се управување со 6,5 петабајти на податоците. Тоа е 6.500 пати повеќе податоци. И знам дека ова. Јас работам со овие бизниси секој ден. Пред пет години, јас ќе разговара со компании кој ќе разговара со мене за што е болка тоа е за управување terabytes на податоци. И тие ќе зборуваат за мене за тоа како ние гледаме дека ова веројатно се случува да биде petabyte или две во рок од неколку години. 

Истите тие компании денес јас средба со, и тие се зборува со мене за Проблемот се таму има управување десетици, 20 петабајти на податоците. Така експлозијата на податоци во индустријата е возење на огромни потребни за подобри решенија. И релациона база на податоци е само не живее со побарувачката. 

И така има линеарна корелација помеѓу притисокот на податоци и технички иновации. Историјата ни покажа ова, дека со текот на времето, кога обемот на податоци што треба да се обработи надминува капацитетот на системот да го обработи во разумен рок или по разумна цена, потоа новите технологии се измислени за да ги реши овие проблеми. Оние кои се нови технологии, пак, ја отвори вратата на друг сет на проблеми, кои собира дури и повеќе податоци. 

Сега, ние нема да го сопре. Нели? Ние нема да го сопре. Зошто? Затоа што не можат да знаат сè таму е да се знае во универзумот. И додека ние сме биле живи, во текот на историјата на човекот ние секогаш сме принудени да се дознае нешто повеќе. 

Така ми се чини дека секоја педа се движиме по патот на научно откритие, ние сме множење на износот на податоци дека ние треба да се процесира експоненцијално како што ние најдеш, се повеќе и повеќе и повеќе во врска со внатрешниот работата на животот, за тоа како универзумот функционира, околу возење на научно откритие, и пронајдокот што што го правиме денес. На обемот на податоците само постојано се зголемува. Така да биде во можност да се справи со овој проблем е огромен. 

Значи, една од работите гледаме како зошто NoSQL? Како го прави NoSQL реши овој проблем? Па, релациони бази на податоци, Структурно јазик за пребарување, SQL-- тоа е навистина конструкт на релациона database-- овие работи се оптимизиран за складирање. 

Назад во 70-тите години, повторно, диск е скапо. Вежба обезбедувањето на складирање во претпријатието е никогаш не завршува. Знам. Јас го живееле. Напишав возачи за складирање enterprised superserver компанијата назад во 90-тите. И во крајна линија е тешкиот друг складирање низа е само нешто што се се случи секој ден во претпријатието. И никогаш не престана. Високото складирање густина, побарувачката за висока густина на чување, и за поефикасно складирање devices-- тоа никогаш не престана. 

И NoSQL е одлична технологија бидејќи тоа нормализира податоци. Тоа де-дупликати на податоци. Таа го става на податоците во една структура која е агностик на секој модел пристап. Повеќе апликации може да се погоди дека SQL базата на податоци, работи на ад хок прашања, и да добијат податоци во облик што тие треба да процесот за нивните работни задачи. Тоа звучи фантастично. Но во крајна линија е со било кој систем, ако тоа е агностик на сè, тој е оптимизиран за ништо. ВО РЕД? 

И тоа е она што го добиваме со релациона база на податоци. Тоа е оптимизиран за складирање. Тоа е нормализиран. Тоа е релациона. Таа го поддржува ад хок пребарувања. И тоа и тоа скали вертикално. 

Ако треба да добие поголема SQL базата на податоци или повеќе моќни SQL база на податоци, Одам да се купи поголем дел од железо. ВО РЕД? Сум работел со голем број на клиенти кои минале низ големи надградби само во нивниот SQL инфраструктура за да дознаете шест месеци подоцна, тие се притискање на ѕид повторно. А одговорот од Oracle или MSSQL или било кој друг се добие поголема кутија. И порано или подоцна, не може да се купи поголема кутија, и тоа е вистински проблем. Ние треба да се, всушност, се променат работите. Значи, каде што го прави ова дело? Добро работи за офлајн анализатор на OLAP-тип на работни задачи. И тоа е навистина каде SQL припаѓа. Сега, тоа е се користи и денес во многу онлајн трансакциски обработка-тип апликации. И работи само парична казна во одредено ниво на користење, но тоа едноставно не скала начинот на кој NoSQL прави. И ние ќе зборуваме малку малку за тоа зошто е тоа така. 

Сега, NoSQL, од друга страна, е повеќе оптимизиран за пресметување. ВО РЕД? Тоа не е да се агностик шемата за пристап. Е она што ние го нарекуваме де-нормализира структура или хиерархиска структура. На податоци во релациона база на податоци е здружија од повеќе табели за производство на ставот дека ви се потребни. Податоците во базата на податоци NoSQL се чуваат во документ кој содржи хиерархиска структура. Сите податоци кои би требало да биде здружија за да се произведе тој став се чуваат во еден документ. И ние ќе зборуваме малку за како тоа функционира во неколку листи. 

Но, идејата е дека ќе ги чувате податоците како овие instantiated пати. ВО РЕД? Можете да скала хоризонтално. Нели? Ако треба да се зголеми големина на мојата NoSQL кластер, Јас не треба да добие поголема кутија. Јас добие уште една кутија. И јас се групираат овие заедно, и можам да срча тие податоци. Ние ќе зборуваме малку за што sharding е, да биде можност да скала таа база на податоци низ повеќе физички уреди и отстранување на бариерата што мене бара да скала вертикално. 

Па тоа е навистина изграден за онлајн трансакција обработка и обем. Има голема разлика овде помеѓу известување, нели? Известување, не знам на прашања, ќе одам да прашам. Нели? Reporting-- ако некој од мојот одделот за маркетинг сака да just-- колку од моите клиенти имаат оваа одредена карактеристика кој купен на овој day-- Не знам она што се пребарува тие се случува да се праша. Значи ми треба да биде агностик. 

Сега, во онлајн трансакциска апликација, Знам дека она што прашања што барам. Јас ја направив на пријавата за многу специфичен тек на работа. ВО РЕД? Значи, ако јас се оптимизира на податоци чувате за поддршка дека работното, тоа се случува да биде побрзо. И затоа може NoSQL Навистина се забрза испорака од оние типови на услуги. Во ред. 

Па ние ќе треба да се влезе во малку теорија тука. А некои од вас, вашите очи Може да се тркалаат назад малку. Но јас ќе се обиде да го задржи како високо ниво што можам. Значи, ако сте во проектот управување, има конструкт наречен триаголникот на ограничувања. ВО РЕД. Триаголникот на ограничувања диктатот не можеш да имаш се што цело време. Не може да има вашиот пита и го јадат премногу. Така што во управување со проекти, кои триаголник ограничувања е можете да го евтини, ќе може да има брзо, или може да имаат добро. Земам две. Бидејќи не можете да ги имаат сите три. Нели? ВО РЕД. 

Па да се слушне за оваа многу. Тоа е троен ограничување, триаголник на тројна ограничување, или железо триаголник е oftentimes-- кога се зборува за проект менаџери, тие ќе зборуваат за ова. Сега, бази на податоци свои железо триаголник. И железо триаголник на податоци е она што ние го нарекуваме теорема ЗЗП. ВО РЕД? 

ЗЗП теорема диктатот бази на податоци како работат под многу специфична состојба. И ние ќе зборуваме за што таа состојба се. Но, три точки на триаголник, така да се каже, се C, конзистентност. ВО РЕД? Па во ЗЗП, конзистентност значи дека сите клиенти, кои може да пристапите до базата на податоци секогаш ќе има многу конзистентен поглед на податоци. Никој не е ќе видиме две различни нешта. ВО РЕД? Ако видам базата на податоци, Јас гледам на истиот став како што мојот партнер кој го гледа истата база на податоци. Тоа е доследност. 

Достапноста значи дека ако база на податоци на интернет, ако тоа може да се постигне, дека сите клиенти ќе секогаш да можат да читаат и пишуваат. ВО РЕД? Така што секој клиент што да прочитате на база на податоци секогаш ќе биде во можност за читање податоци на податоци и да пишува. И ако тоа е случај, тоа е достапна на системот. 

И третата точка е она што ние го нарекуваме партиција толеранција. ВО РЕД? Толеранција партиција средства дека системот работи добро покрај физичката мрежа партиции помеѓу јазли. ВО РЕД? Па јазли во кластерот не може да разговараат со едни со други, што се случува? Во ред. 

Па релациони бази на податоци choose-- можете да ги собереш две од овие. ВО РЕД. Релациони бази на податоци, па изберете да бидат доследни и на располагање. Ако партиција се случува помеѓу на DataNodes во продавница на податоци, базата на податоци се урна. Нели? Тоа само оди надолу. ВО РЕД. 

А тоа е зошто тие имаат да расте со поголема кутии. Нели? Бидејќи има no-- обично, кластер база на податоци, таму не е многу голем дел од нив кои работат на тој начин. Но повеќето бази скала вертикално во една кутија. Бидејќи тие треба да бидат доследни и на располагање. Ако партиција требаше да се инјектира, тогаш вие ќе треба да се направи избор. Што треба да се направи избор меѓу да се биде доследен и достапни. 

И тоа е она што го направи NoSQL бази на податоци. Во ред. Значи, за базата на податоци NoSQL тоа, доаѓа во две варијанти. Ние have-- добро, тоа доаѓа во многу вкусови, но тоа доаѓа со два основни characteristics-- што ние би го нарекол КП база на податоци, или доследни и партиција толеранција систем. Овие момци се направи избор што кога јазли се изгуби контакт со едни со други, ние нема да се овозможи луѓето да пишуваат повеќе. ВО РЕД? 

Додека таа партиција е отстранета, запишување пристап е блокиран. Тоа значи дека тие не се достапни. Тие се доследни. Кога ќе видиме дека партиција се инјектираат, сега сме во согласност, затоа што не си оди за да се овозможи промена на податоците за две страни на партиција независно на едни со други. Ние ќе мора да reestablish комуникација пред било надградба податоците се дозволени. ВО РЕД? 

Следниот вкус ќе биде систем АП, или достапни и се подели систем толеранција. Овие момци не се грижат. Нели? Било кој јазол, која добива пишувам, ние ќе го земам. Па јас сум реплицира моите податоци преку повеќе јазли. Овие јазли се добие клиент, клиент доаѓа во, вели, јас ќе одам да пишувам некои податоци. Јазол, вели, нема проблем. Јазол до него добива пишуваат на истиот рекорд, тој се случува да се каже, нема проблем. Некаде назад на крајот на грбот, дека податоците што се случува да се реплицираат. А потоа некој се случува да се реализира, Ух-ах, тие систем ќе се реализира, Ух-ах, има е надградба на двете страни. Што ќе правиме? И она што го прават, тогаш е тие се направи нешто што им овозможува да се реши таа состојба на податоци. И ние ќе зборуваме за дека во следниот графикон. 

Нешто да се истакне тука. И јас не одам да се добие премногу многу во тоа, затоа што овој добива во длабока теорија податоци. Но, има една трансакциска рамка која работи во релациона систем кој ми дозволува да се безбедно да се направи ажурирање на повеќе лица во базата на податоци. И ќе се случи тие надградби сите одеднаш или не на сите. И ова се нарекува трансакции киселина. ВО РЕД? 

КИСЕЛИНА ни дава atomicity, конзистентност, изолација, и издржливост. ВО РЕД? Тоа значи дека атомските, трансакции, сите моите ажурирања или да се случи или не. Конзистентност значи дека Базата на податоци ќе секогаш да се донесе во конзистентна состојба после надградбата. Никогаш нема да ја напушти базата на податоци во лоша состојба по примена на ажурирање. ВО РЕД? 

Така, тоа е малку различен од конзистентност ЗЗП. Конзистентност ЗЗП значи сите мои клиенти секогаш може да се види на податоците. КИСЕЛИНА конзистентност значи дека кога трансакцијата е направено, податоци е добро. Моето односи сите се добри. Јас не одам за да го избришете ред родител и да ја напуштат еден куп на деца без родители во некоја друга маса. Тоа не може да се случи ако јас сум конзистентен во кисела трансакцијата. 

Изолација значи дека трансакции секогаш ќе се случи еден по друг. Крајниот резултат на податоците од ќе бидат во иста држава како оние трансакции кои се издадени истовремено биле егзекутирани сериски. Така што е на конкурентноста контрола во базата на податоци. Значи, во основа, не можам да прираст иста вредност на два пати со две операции. 

Но ако кажам додадете 1 на оваа вредност, и две трансакции доаѓаат во и да се обиде да го направи тоа, еден е случува да одам таму прва а другиот е случува да одам таму после. Така, на крајот, се додаваат две. Гледаш што мислам? ВО РЕД. 

Трајност е прилично јасна. Кога трансакцијата да се наведе, тоа е ќе биде таму, дури и ако системот падне. Кога тој систем заздравува, дека трансакција која е сторено е, всушност, ќе биде таму. Значи тоа е гаранции на трансакции киселина. Тие се прилично убаво гаранции за да имате на базата на податоци, но тие доаѓаат во таа цена. Нели? 

Затоа што проблемот со оваа рамка е ако постои поделба во податоците во собата, јас треба да се донесе одлука. Одам да се има за да се овозможи ажурирања на една страна или друга. А ако тоа се случи, тогаш јас повеќе не ќе сум за да може да се одржи тие карактеристики. Тие нема да бидат доследни. Тие нема да бидат изолирани. Ова е местото каде што се распаѓа за релациони бази на податоци. Ова е причината релациона бази на податоци скала вертикално. 

Од друга страна, имаме она што се нарекува базна технологија. И овие се вашите NoSQL бази на податоци. Во ред. Значи ние треба нашите КП, АП бази на податоци. И тие се она што го нарекуваме во основа достапни, мека државата, на крајот конзистентна. ВО РЕД? 

Основа на располагање, бидејќи тие се партиција толерантни. Тие секогаш ќе бидат таму, дури и ако има партиција мрежа помеѓу јазли. Ако можам да разговара со еден јазол, јас сум ќе биде во можност да го прочитате на податоци. ВО РЕД? Јас не мора секогаш да биде во можност да се напише податоци и ако сум конзистентен платформа. Но, јас ќе биде во можност да го прочитате на податоци. 

Меките државата укажува дека кога ќе читаме податоците, тоа не може да биде иста како и други јазли. Ако право е издадено на еден јазол некаде на друго место во групата и тоа не е среќаваат низ целата кластер уште кога го читаме податоците, дека државата не може да биде конзистентна. Сепак, тоа ќе биде на крајот во согласност, што значи дека кога пишуваат се врши на системот, тоа ќе се реплицираат во склопот на јазли. И на крајот, таа држава ќе биде доведена во ред, и тоа ќе биде конзистентна држава. 

Сега, теорема ЗЗП навистина игра само во еден услов. Таа состојба е кога тоа се случи. Бидејќи секогаш кога тоа е што работат во нормален режим, нема поделба, се што е во согласност и на располагање. Се грижите само за земјоделска политика кога имаме таа партиција. Па оние кои се ретки. Но, како системот реагира кога тие јавуваат диктираат кој тип на систем си имаме работа. 

Па ајде да ги разгледаме во она што што личи на АП системи. ВО РЕД? АП системи доаѓаат во две варијанти. Тие доаѓаат во вкус кој е господар господар, 100%, секогаш на располагање. И тие доаѓаат во други вкус, кој вели: знаеш што, јас ќе одам да се грижите поради ова, партиционирање кога вистински партиција случува. Инаку, не се случува да биде примарна јазли кои се случува да се земе правата. ВО РЕД? 

Значи, ако ние нешто како Касандра. Касандра ќе биде господар господар, ајде да ми пишете на било кој јазол. Значи она што се случува? Па имам објект во база на податоци што постои на два јазли. Ајде да се јавите на тој објект С. Па ние имаме држава за С. Имаме некои операции на S кои се во тек. Касандра ми дозволува да пишуваат на повеќе јазли. Па да речеме да се добие пишувам за и до два јазли. Па, она што завршува се случува е ние го нарекуваме дека партиционирање настан. Таму не може да биде партиција физичка мрежа. Туку затоа што на дизајнот на системот, тоа е всушност поделба штом како можам да добијам за запишување на два јазли. Тоа не е принудувајќи ме да запишување на сите преку еден јазол. Го пишувам на два јазли. ВО РЕД? 

Па сега имам две држави. ВО РЕД? Што ќе се случи е, порано или подоцна, таму се случува да биде една репликација настан. Таму се случува да биде она што го нарекува партиција за обновување, кој е местото каде што овие две членки се врати заедно и таму се случува да биде еден алгоритам кој работи во внатрешноста на базата на податоци, одлучи што да прави. ВО РЕД? По дифолт, во последно ажурирање победи во повеќето системи за АП. Па има обично алгоритам стандардно, што тие го нарекуваат за повратен повик функцијата, нешто што ќе се вика кога оваа состојба е откриена да се изврши некоја логика да го реши конфликтот. ВО РЕД? Повратен повик и стандардно стандардно преведување во повеќето АП бази на податоци е, погоди што, временската ознака ќе победи. Ова беше последен ажурирање. Одам да се стави дека ажурирање во таму. Јас може да шутнат овој запис дека јас фрлена надвор во дневник за обновување така што корисникот може да се врати подоцна и да каже, еј, имаше судир. Што се случи? И всушност можете да шутнат евиденција за сите судири и rollbacks и да видиме што се случува. 

Сега, како корисник, можете исто така да вклучуваат логиката во тоа повратен повик. За да можете да го смени тоа повратен повик функција. Може да се каже, еј, јас сакам за санација на овие податоци. И јас сакам да се обиде и да се спојат овие две евиденции. Но, тоа е до вас. Базата на податоци не знае како да се направат тоа по дифолт. Повеќето од времето, единствената работа на базата на податоци знае како да направите е да се каже, ова е последна плоча. Тој е оној кој ќе победи, и тоа е вредност, ќе одам да се стави. Откако таа партиција за обновување и репликација се случува, имаме своја држава, која сега е S-премиер, кој е спојување држава на сите тие предмети. Па АП системи имаат ова. Системи ЦП не треба да се грижите за тоа. Затоа што веднаш штом партиција доаѓа во игра, тие само престанат со земање пишува. ВО РЕД? Значи, тоа е многу лесно да се се справи со се во согласност кога ќе не прифаќаме никакви надградби. Тоа е со системи ЦП се направи. Во ред. 

Значи, да се зборува малку малку за шеми пристап. Кога зборуваме за NoSQL, тоа е сите за модел за пристап. Сега, SQL е ад хок, пребарувања. Тоа е релациона продавница. Ние не треба да се грижите во врска со шемата за пристап. Јас пишувам многу комплексна пребарување. Тоа оди и добива на податоците. Тоа е она што ова изгледа како, нормализација. 

Значи во овој конкретен структура, ние сме во потрага на еден каталог производи. Имам различни типови на производи. Имам книги. Имам албуми. Имам видео клипови. Односот помеѓу производите и ниту една од овие книги, албуми, и видео маси е 1: 1. Во ред? Јас имам проект на производот, и на тој проект е еднаква со книга, албум, или видео. ВО РЕД? Тоа е 1: 1 однос во овие табели. 

Сега, сите тие books-- имаме е корен својства. Нема проблем. Тоа е супер. Еден-на-еден однос, да се добие сите податоци што се потребни за да се опише таа книга. Albums-- албуми имаат песни. Тоа е она што ние го нарекуваме еден на многу. Секој албум може да има многу песни. Значи за секој колосек албумот, би можел да има уште еден рекорд во ова дете маса. Па јас се создаде еден рекорд во мојата маса албуми. Јас создаде повеќе рекорди во табелата на песни. Еден на многу односи. 

Овој однос е она што ние го нарекуваме многу-на-многу. ВО РЕД? Гледаш дека актерите можат да бидат во многу филмови, многу видео клипови. Значи она што го правиме е ние се стави ова мапирање маса меѓу оние, кои тоа само мапи проект на актерот да видеото проект. Сега можам да се создаде побарување приклучува видеа преку актер видео на актери, и тоа ми дава добро листа сите филмови и сите актери кои беа во тој филм. 

ВО РЕД. Па тука ќе одиме. Еден-на-еден е на највисоко ниво однос; еден-на-многу, албуми за напојување; многу-на-многу. Тоа се трите топ-ниво односи во секоја база на податоци. Ако знаете како оние односи работат заедно, тогаш знаеш многу база на податоци за веќе. Па NoSQL работи малку поинаку. Ајде да размислиме за за втор што е тоа Изгледа како да одам да купам сите моите производи. 

Во релациона продавница, сакаат да ги добијат сите мои производи на листа на сите моите производи. Тоа е многу пребарувања. Добив на барањето за сите мои книги. Добив побарување од моите албуми. И јас влегов на барањето за сите мои видеа. И јас влегов да го стави сите заедно во листа и служат е назад до апликација која е барателот. 

Да се ​​добие моите книги, се вклучам Производи и книги. Да се ​​моите албуми, имав можност да се приклучат Производи, албуми и песни. И да се добие мојата видеа, јас имам да се приклучат кон Производи Видео, се приклучат преку Актерот Видео, и да ја доведе во актерите. Значи тоа е три пребарувања. Многу комплексни прашања да соберат еден резултат во собата. 

Тоа е помалку од оптимално. Ова е причината зошто, кога зборуваме околу една структура која е податоци изградена за да биде агностик на пристап pattern-- и тоа е одлично. И што можете да видите, ова е навистина убаво како сме организирани податоците. И знаете што? Имам само еден запис за еден актер. 

Тоа е кул. Сум deduplicated сите мои актери, и јас се одржува мојата здруженија во овој мапирање маса. Сепак, добивање на податоци надвор станува скапо. Јас сум испраќање на процесорот целиот систем спојување овие структури на податоци заедно да бидат во можност да се повлече назад дека податоците. 

Па како можам да се добие околу тоа? Во NoSQL тоа е за агрегација не, нормализација. Затоа сакаме да кажеме што сакаме да поддршка на шемата за пристап. Ако шаблонот за пристап на апликации, Јас треба да добие сите мои производи. Ајде да се стави сите производи во една табела. Ако го ставам сите производи во една маса, Јас само може да изберете сите производи од таа маса и јас добиете сето тоа. Па, како да го направам тоа? Добро во NoSQL нема структура на табелата. Ние ќе зборуваме малку за како тоа функционира во Динамо ДБ. Но вие не го имаат истиот атрибути и истите својства во секој ред, во секоја објект, како што го правите во SQL табела. И што тоа ми овозможува да се направи уште многу нешта и да ми даде многу флексибилност. Во конкретниов случај, јас имате мојот производ документи. А во конкретниов На пример, се ' е документ во табелата на производи. И производот за една книга може да имаат проект тип кој одредува книга. И апликација ќе се преориентираат на тој проект. 

На ниво на пријавата, јас ќе одам да се каже О, што запис е ова? Ох, тоа е книга рекорд. Евиденција книга имаат овие својства. Дозволете ми да се направи книга објект. Па јас ќе одам да се пополни книга објект со оваа точка. Следната точка доаѓа и вели, што е овој предмет? И оваа точка е албум. О, јас влегов во целина различни обработка рутина за тоа, затоа што тоа е еден албум. Гледаш што мислам? 

Па примената tier-- јас само изберете сите овие записи. Сите тие почнат да доаѓаат во. Тие можат да бидат сите различни видови. И тоа е логиката на апликацијата кои водат низ овие видови и одлучува како да ги процесира. 

Повторно, па ние сме оптимизирање на шема за модел за пристап. Ние сме го прави тоа од страна на уривање оние маси. Ние сме во основа преземање овие нормализиран структури, и градиме хиерархиските структури. Во секој од овие записи Одам да се види низа својства. 

Во внатрешноста на овој документ за албуми, Јас гледам низи на песни. Оние песни сега become-- тоа е во основа тоа дете маса што постои право овде, во оваа структура. За да можете да го направите тоа во DynamoDB. Можете да го направите тоа во MongoDB. Можете да го направите во било која база на податоци NoSQL. Создаде овие видови на хиерархиските структури на податоци кои ви дозволуваат да се приберат податоци многу брзо, бидејќи сега јас не мора да се приспособат. Кога ќе внесете ред во песни маса, или ред во табелата на албуми, Морам да се прилагодат на таа шема. Јас мора да имаат својство или имотот што е дефинирано на таа табела. Секој еден од нив, кога ќе го пуштите истиот ред. Тоа не е случај и во NoSQL. 

Јас може да имаат сосема различни својства во секој документ дека јас вметнете во колекцијата. Толку многу моќен механизам. И тоа е начинот на кој оптимизираат системот. Бидејќи сега кога пребарување, наместо за приклучување на сите овие табели и извршување на половина дузина прашања да се повлечат на податоци што ми треба, Јас сум извршување едно пребарување. И јас сум со процесирањето низ резултатите во собата. тоа ви дава една идеја на моќта на NoSQL. Одам да се вид на одат накосо тука и зборува малку за ова. Ова е повеќе вид на маркетинг или technology-- маркетинг на технологијата тип на дискусија. Но, важно е да се разбере затоа што ако се погледне на врвот тука во оваа табела, она што ние сме во потрага на е она што ние го нарекуваме технологија крива возбуда. И што тоа значи е нови работи, стапува на сцена. Луѓе мислат дека тоа е одлично. Сум реши сите проблеми. 

Ова би можело да биде на крајот сите, да бидат сите за сè. И тие почнат да го користат. И тие велат, овој материјал не функционира. Ова не е во право. Старите работи беше подобро. И тие се вратиш да го прават работите онака како што беа. А потоа на крајот тие одат, знаеш што? Овој материјал не е толку лошо. Ох, тоа е како тоа функционира. И откако тие дознаам како дела, тие почнуваат да се подобрува. 

И смешно нешто во врска со тоа е, тој вид на линии до она што ние го нарекуваме технологија прием крива. Значи она што се случува е тоа што имаме некој вид технологија чкрапалото. Во случај на бази на податоци, тоа е под притисок на податоците. Зборувавме за висока вода поени за притисок на податоци во текот на времето. Кога тој притисок податоци хитови одредена точка, тоа е технологија чкрапалото. 

Тоа е добивање премногу скапо. Тоа трае премногу долго за да ги обработува податоците. Ние треба нешто подобро. Ќе го добиете иноватори таму трчаат наоколу, обидувајќи се да дознаете она што е решението. Која е новата идеја? 

Што е следниот најдобар начин да го направите ова? И тие да излезе со нешто. И луѓето со вистинска болка, момци на работ на крварење, тие ќе скокне сите над неа, бидејќи тие треба одговор. Сега што неизбежно happens-- и тоа се случува во моментов во NoSQL. Јас го гледам цело време. 

Што се случува е неизбежно луѓето да започнат со користење на новата алатка на ист начин како што се користи стариот алатка. И тие да дознаете што не работи толку добро. Јас не се сеќавам кој сум разговараат со порано и денес. Но тоа е како, кога jackhammer бил измислен, луѓе не го замав во текот глава за да се пресече на бетонот. 

Но, тоа е она што е случува со NoSQL денес. Ако одиме во со повеќето продавници, тие се обидуваат да бидат NoSQL продавници. Она што го правиш е тие се користат NoSQL, и тие си го товари полн со релациона шема. Бидејќи тоа е како тие дизајн на бази на податоци. И тие се прашувате, зошто е тоа не врши многу добро? Момче, ова нешто смрди. Морав да се задржи сите мои приклучува in-- тоа е како, не, не. Одржување приклучува? Зошто се приклучи на податоци? Не ви се придружат на податоци во NoSQL. Ти ја агрегат. 

Значи, ако сакате да се избегне ова, да научат како функционира алатка пред навистина да сте почнете да го користите. Не се обиде да ги користат новите алатки ист начин да се користи стариот алатки. Ви се случува да имаат лошо искуство. И секој пат тоа е она што ова е за тоа. Кога почнавме да доаѓа тука, тоа е затоа што луѓето сфатиле како да ги користиш овие алатки. 

Што тоа го правеа истото кога релациони бази на податоци биле измислени, и тие беа на местото на датотечни системи. Тие се обидоа да изградат датотечни системи со релациони бази на податоци затоа што тоа е она што разбрав луѓе. Тоа не работи. Така и на најдобрите практики на технологијата си работат со е огромна. Многу важно. 

Па ние ќе треба да се влезе во DynamoDB. DynamoDB е AWS е целосно успеа NoSQL платформа. Што значи целосно успеа да значи? Тоа значи дека не треба да се навистина се грижите за ништо. 

Ќе дојдат, да ви кажам нас, јас треба на маса. Тоа треба ова многу капацитет. Ќе удри на копчето, и обезбедување сите инфраструктура зад сцена. Сега дека е огромен. 

Затоа што кога ќе се зборува за изнаоѓање на базата на податоци, NoSQL кластери на податоци во скала, трчање петабајти, водење милиони трансакции во секунда, овие работи не се мали кластери. Зборуваме илјадници случаи. Управување со илјадници случаи, дури и виртуелни случаи, е вистинска болка во газот. Мислам, мислам за секој пат оперативниот систем печ излегува или нова верзија на базата на податоци. Што значи тоа да ви оперативно? Тоа значи дека сте ја добиле 1.200 сервери, кои треба да бидат ажурирани. Сега дури и со автоматизација, кои може да трае долго време. Што може да предизвика многу оперативни главоболки, затоа што јас би можеле да имаат услугите надолу. 

Како што се ажурираат овие бази на податоци, јас може да се направи сина зелена распоредувања каде што се распореди и да ги надградат половина од моето јазли, а потоа и надградба на другата половина. Земе оние долу. Така управувањето со инфраструктурата скала е енормно болно. И AWS земе дека болката од него. И NoSQL бази на податоци може да се биде исклучително болна поради начинот на кој тие скала. 

Скала хоризонтално. Ако сакате да се добие поголема NoSQL база на податоци, може да се купи повеќе јазли. Секој јазол ќе купите е друг оперативен главоболка. Па ајде некој друг да го направи тоа за вас. AWS го може тоа. 

Ние ја поддржуваме вредности клучен документ. Во овој момент ние не одиме премногу во од друга шема. Има многу различни вкусови на NoSQL. Сите тие се вид на добивање на munged заедно во овој момент. Можете да го погледнете DynamoDB и рекол да, двајцата сме документ и вредноста клуч чување на оваа точка. И може да се тврди на карактеристики на еден над друг. За мене, многу од тоа е навистина шест од една половина дузина на другиот. Секој еден од овие технологии е фино технологија и парична казна решение. Јас не би рекол MongoDB е подобра или полошо од каучот, а потоа Касандра, потоа Динамо, или обратно. Мислам, ова се само опции. 

Тоа е брзо и тоа е конзистентни во секое ниво. Па ова е еден од најголемите бонуси што добивате со AWS. Со DynamoDB е способноста да се добие ниска едноцифрена милисекунда латентност во секое ниво. Тоа беше цел при дизајнот на системот. И ние имаме клиенти кои го прават милиони трансакции во секунда. 

Сега јас ќе поминат низ некои од оние употреба случаи во неколку минути тука. Control-- интегриран пристап имаме она што го нарекуваме Идентитет за управување со пристап, или ИВЗ. Тоа се шири секој систем, секоја услуга која AWS обезбедува. DynamoDB не е исклучок. Можете да го контролирате пристапот да маси DynamoDB. Во сите вашите сметки од AWS дефинирање на улоги и дозволи за пристап во ИВЗ инфраструктура. 

И тоа е клучен и интегрална компонента во она што го нарекуваме Настан управувано програмирање. Сега ова е нова парадигма. 

ПУБЛИКАТА: Како е вашиот стапка на вистински позитивни наспроти лажно негативни на вашиот систем за контрола на пристап? RICK Houlihan: вистински позитивни наспроти лажно негативни? ПУБЛИКАТА: Враќање што ќе треба да се враќаат? За разлика од време на време тоа не се врати кога тоа треба да се провери? 

RICK Houlihan: Не можев да ти кажам дека. Ако има било неуспеси она што на тоа, Јас не сум човек да прашам дека одредено прашање. Но, тоа е добро прашање. Јас би бил љубопитен да знаете дека јас, всушност. 

И така, тогаш повторно, нова парадигма е настан управувано програмирање. Ова е идејата дека може да се распореди сложени апликации кои може да работи на многу, многу високо ниво без инфраструктура она. Без било кој фиксен инфраструктура она. И ние ќе зборуваме малку за тоа што значи дека како што ние добие на следните неколку листи. 

Првото нешто што ние ќе го направиме е ние ќе зборуваме за маси. Типови на податоци API за Динамо. И првото нешто што ќе забележите кога ќе се погледне на овој, ако сте запознаени со било која база на податоци, бази на податоци имаат навистина две вид на API-јата Би го нарекуваат. Или две групи на API. Еден од тие ќе бидат административни API. 

Работите што се грижи за функциите на базата на податоци. Конфигурирање на моторот за чување, поставување и додавање табели. создавањето на базата каталози и инстанци. Овие things-- во DynamoDB, можете имаат многу краток, кратки листи. 

Значи со други бази на податоци, можеби ќе видите десетици на команди, на административните команди, за конфигурирање овие дополнителни опции. Во DynamoDB што не треба, бидејќи тие не го конфигурирате системот, тоа го правиме. Па единственото нешто што треба да направите е да се да ми кажете што на маса големина ми е потребно. Така да се добие многу ограничен сет на команди. 

Добивате создаде маса ажурирање, масичка, Бришење на маса, и се опише табела. Тие се единствените нешта ви треба за DynamoDB. Не ви е потребен за складирање конфигурација. Јас не треба да се грижите за репликација. Јас не треба да се грижите за sharding. 

Јас не треба да се грижите за било кој од овие работи. Ние го прават тоа сите за вас. Значи, тоа е огромна сума на надземни тоа е само крена надвор вашата чинија. Тогаш имаме оператори CRUD. CRUD е нешто што ние јавите во база на податоци која е Се создаде, ажурирање, бришење оператори. Овие се вашите вообичаени база на податоци операции. Работи како стави точка, земи ги, ажурирање предмети, бришете објекти, барање серија, скенирање. Ако сакате да го скенира целиот маса. Повлечете се што се на маса. Една од убавите работи во врска DynamoDB е тоа што им овозможува паралелно скенирање. Така што всушност може да се дозволете ми да знам колку теми сакате да се кандидира на таа скенирање. И ние може да ја стартувате овие теми. Ние може да се вртат дека скенирање до низ повеќе теми за да можете да го скенира целиот маса простор за многу, многу брзо во DynamoDB. 

Од друга API, што го имаме е она што го нарекуваме нашата струи API. Ние нема да се зборува премногу многу за ова во моментов. Имам некои содржини подоцна за во палубата за ова. Но струи е навистина running-- мислам на тоа како им нареди на време и промена партиција логирате. Сето она што се случува на табелата се појавува на потокот. 

Секој пишуваат на табелата се појавува на потокот. Можете да прочитате дека поток, и можете да се прават работите со него. Ние ќе зборуваме за она што видови на работи што можете направи со нешта како репликација, создавање на средното индекси. На сите видови на навистина кул работи што можете да направите со тоа. 

Типови на податоци. Во DynamoDB, ние ги поддржуваме двете клучни вредност и документи типови на податоци. На левата страна на екранот тука, ние го добивме нашите основни типови. Клучни видови вредност. Овие се стрингови, броеви, и бинарни. 

Па само три основни видови. А потоа ќе може да има групи на оние. Една од убавите работи во врска NoSQL е можете да содржат низи како својства. И со DynamoDB можете да содржат низи на основните видови како корен на имот. 

А тука е и видови на документот. Колку луѓе се запознаени со JSON? Вие момци се запознаени со JSON толку многу? Тоа е во основа на JavaScript, Објект, нотација. Тоа ви овозможува да во основа дефинираат хиерархиска структура. 

Можете да ги чувате документ JSON на DynamoDB користење на заеднички компоненти или составни делови, кои се достапни во повеќето програмски јазици. Значи, ако имате Јава, ти си гледање на карти и листи. Јас може да се создаде објекти кои картата. Карта како клучни вредности чуваат како својства. И тоа би можело да има списоци на вредности во рамките на тие својства. Можете да ги чувате овој комплекс хиерархиска структура како единствен атрибут на ствар DynamoDB. 

Па маси во DynamoDB, како и повеќето NoSQL бази на податоци, табели има елементи. Во MongoDB што би нарекуваме овие документи. И тоа ќе биде каучот база. Исто така, на база на податоци документ. Ти се јавам на овие документи. Документи или предмети имаат атрибути. Може да постои или атрибути Не постојат на ставка. Во DynamoDB, има еден задолжителен атрибут. Исто како и во релациона база на податоци, имаш примарен клуч на табелата. 

DynamoDB има она што го нарекуваме клучен хаш. Хаш клуч мора да биде уникатен. Па кога ќе се дефинираат хаш табелата, во основа она што сакам да кажам дека е секој елемент ќе имаат клучна хаш. И секоја хаш клуч мора да биде уникатен. 

Секој елемент е дефинирана со тоа единствен клуч хаш. И може да има само еден. Ова е во ред, но многу пати она што луѓето треба е што тие сакаат е ова хаш клуч за да се направи малку повеќе отколку само да биде единствен идентификатор. Честопати сакаме да го користиме тој клуч хаш како најдобар агрегација ниво кофа. И начинот на кој го стори тоа е со додавање на она што го нарекуваме клучен опсег. 

Значи, ако тоа е само хаш маса, тоа мора да биде уникатен. Ако тоа е хаш и опсег на табелата, комбинација на хаш и опсегот мора да биде уникатен. Така што мислам за тоа на овој начин. Ако имам форумот. Како и формата, има теми, има мислења, и тоа има одговори. 

Па јас би можеле да имаат хаш клуч, кој е проект на темата. И јас би можеле да имаат клучна опсег, кој е ID на одговор. На тој начин, ако сакам да ги добиете сите одговори за одредена тема, Јас само може да се пребарува на хаш. Јас само може да се каже да ми даде сите елементите кои ја имаат оваа хаш. А јас ќе одам да се добие секој прашање или пост за таа одредена тема. Овие врвни агрегации ниво се многу важни. Тие ги поддржуваат основните пристап шемата на апликацијата. Општо земено, ова е она што сакаме да го стори. Ние сакаме тоа table-- како да се вчита на маса, ние сакаме да се структурата на податоците во рамките на табелата на таков начин дека жалбата може да многу брзо да се добие оние резултати. И многу пати на начин да се стори тоа е за одржување на овие колонии како што ние внес на податоци. Во суштина, ние сме проширување на податоци во нови светли кофа како што доаѓа во. 

Спектар клучеви овозможи me-- хаш клучеви треба да се биде еднаквост. Кога јас се пребарува хаш, морам да кажам дај ми хаш што е еднакво на тоа. Кога јас се пребарува низа, јас може да се каже да ми даде број кој е со користење на било каков вид на богата оператор дека ние ја поддржуваме. Дај ми ги сите предмети за хаш. Дали е еднакво, поголем од, помалку од, дали тоа ќе започне со тоа, Дали постојат помеѓу овие две вредности? Така што овие видови на пребарувања опсег дека ние сме секогаш се заинтересирани. Сега една работа за податоци, кога ќе се погледне на пристап до податоци, кога можете да пристапите до податоците, тоа е секогаш за агрегација. Тоа е секогаш за евиденција кои се поврзани со тоа. Дај ми се што тука that's-- сите трансакциите на оваа кредитна картичка за последниот месец. Тоа е агрегација. 

Речиси се што ви прават во база на податоци е некој вид на агрегација. Така да можат да бидат во можност да се дефинира овие корпи и да ви даде овие се движат атрибути за да може да се пребарува на, оние богатите пребарувања поддршка на многу, многу, многу шеми пристапот на апликацијата. 

Па на другата нешто клучните хаш не е тоа ни дава механизам за да може да се шири на податоци наоколу. NoSQL бази на податоци работи најдобро кога податоците се рамномерно дистрибуирани низ кластерот. Колку луѓе се запознаени со хаш алгоритми? Кога велам хаш и hashing-- бидејќи хаш алгоритам е начин да се биде во состојба да генерира случајна вредност од било која вредност. Така што во овој конкретен случај, хаш алгоритам трчаме е НД 5 врз основа. 

И ако имам лична карта, а тоа е мојот клуч хаш, имам 1, 2, 3. Кога јас се кандидира на хаш алгоритам, тоа се случува да се врати и да каже, и 1 еднаква 7B, 2 еднакво на 48, 3 дава ЦД. Тие се шири низ целиот простор клуч. И зошто го правиш ова? Затоа што тоа го прави сигурни дека можам се стави на евиденција преку повеќе јазли. 

Ако јас го правам ова постепено, 1, 2, 3. И имам хаш асортиман работи во конкретниов случај, мал хаш простор, тоа ќе трае од 00 до FF, тогаш податоците се случува да дојде во и тие се случува да се оди, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. Што се случува? Секој вметнете ќе истиот јазол. Гледаш што мислам? 

Затоа што кога ќе се подели на просторот, и јас се шири низ овие записи, и јас партиција, јас ќе одам да се каже партиција 1 има простор клуч 0-54. Партиција 2 е 55-89. Партиција 3 е АА до FF. Значи, ако јас сум со користење линеарно ја зголемува Лични карти, можете да видите што се случува. 1, 2, 3, 4, 5, 6, сите начин до 54. Така како што јас сум ковале евиденција во системот, сè да се заврши се случува на еден јазол. 

Тоа не е добро. Тоа е antipattern. Во MongoDB тие имаат овој проблем ако не го користите клучниот хаш. MongoDB ви дава опција на hashing вредноста на клучот. Секогаш треба да се направи тоа, ако сте со користење на хаш ја зголемува клучот во MongoDB, или ќе бидете заковаме секој пишуваат на еден јазол, и ќе ви биде ограничувачки вашиот пишуваат автопат лошо. 

ПУБЛИКАТА: Дали е тоа А9 169 во децимални? 

RICK Houlihan: Да, тоа е некаде таму. А9, јас не знам. Ќе треба да го добие мојот бинарни до децимални калкулатор. Мојот мозок не работи како што. ПУБЛИКАТА: Само брзо еден на вашиот Mongo коментари. Така е проект на објектот кој доаѓа природно со Mongo го направите тоа? RICK Houlihan: Дали тоа го правите тоа? Ако го определи. Со MongoDB, имаш опција. Можете да specify-- секој документ во MongoDB мора да има проект друг знак. Тоа е уникатна вредност. 

Во MongoDB можете да наведете дали да го хаш или не. Тие само ви даде опција. Ако знаете дека тоа е случајни, нема проблем. Вие не треба да го направат тоа. Ако знаете дека тоа не е случајно, дека тоа ја зголемува, тогаш направете го хаш. 

Сега на работа во врска со hashing, но откако ќе хаш на value-- и ова е зошто хаш клучеви се секогаш уникатни прашања, затоа што сум се променил вредноста, сега не можам да се направи за пребарување опсег. Не можам да кажам е ова помеѓу ова или она, бидејќи hash вредност не се случува да бидат еднакви на реалната вредност. Па кога ќе хаш дека клуч, тоа е само еднаквост. Ова е причината зошто во DynamoDB клучните хаш прашања се секогаш само еднаквост. 

Па сега се во голем број key-- кога ќе се додаде дека клучните опсег, оние клучни евиденција спектар сите доаѓаат во и тие се чуваат на иста партиција. Па тие се многу брзо, лесно Преземено бидејќи ова е хаш, ова е опсег. И ќе видите се што е со истиот хеш добива чуваат на иста партиција простор. Можете да го користите дека клучните опсег за да им помогне на лоцира вашите податоци блиску до неговиот родител. Значи она што сум јас навистина правиш овде? Ова е еден на многу односи. Односот меѓу клучните хаш и клучните опсег е една многу. Јас може да има повеќе клучеви хаш. Јас само може да има повеќе опсег копчиња во рамките на секоја клучна хаш. 

Хаш дефинира родител, опсег дефинира деца. Па можете да видите има аналогни тука помеѓу релациони конструкт и истите видови на конструира во NoSQL. Луѓе се зборува за NoSQL како nonrelational. Тоа не е nonrelational. Податоци секогаш има односи. Овие односи само се моделирани поинаку. Ајде да зборуваме малку малку за издржливост. Кога пишуваш да DynamoDB, пишува Секогаш три начин реплицира. Што значи дека имаме три АЗ е. АЗ се Достапност зони. Може да се мисли на достапност Зона како центар за податоци или собирање на центри за податоци. Овие нешта се географски изолирани едни од други во различни зони вина, низ различни моќ мрежи и поплавни. А неуспех во еден АЗ не е нема да ги симнат на друг. Тие, исто така се поврзани заедно со темни влакна. Таа поддржува еден под 1 милисекунда латентност помеѓу AZS. Толку реално време имитации податоци способен во мулти AZS. 

И честопати мулти распоредувања АЗ ги задоволи високите барања достапност на повеќето организации претпријатие. Па DynamoDB се шири низ три AZS од стандардните. Ние сме само ќе знаење пишувам кога две од овие три јазли се врати и да каже, да, јас го зедов тоа. Зошто е тоа? Затоа што на страната на читање ние сме само одам да ви даде податоците назад, кога ние го добие од два јазли. 

Ако сум реплицира низ три, и го читам од две, Јас сум секогаш загарантирана да имаат најмалку еден на оние кои се вели дека е најактуелните копија на податоците. Тоа е она што го прави DynamoDB доследни. Сега можете да изберете да го вклучите оние кои се во согласност стои надвор. Во кој случај, јас ќе одам да се каже, Јас ќе го прочитаат само од еден јазол. И јас не може да гарантира дека тоа нема да биде најмногу тековните податоци. 

Па ако некој пишува доаѓа во, тоа не се повтори уште, си оди за да се добие таа копија. Тоа е крајот доследни читање. И она што е е половина од цената. Па ова е нешто да се размислува за. Кога ќе го читаш надвор DynamoDB, и сте поставување на вашиот капацитет за читање единици, ако решите на крајот конзистентна чита, тоа е многу поевтино, тоа е за половина од цената. 

И така ви заштедува пари. Но, тоа е ваш избор. Ако сакате доследни читање или на крајот се доследни читање. Тоа е нешто што можете да одберете. 

Ајде да зборуваме за индекси. Значи ние се напомене дека ниво агрегација врвот. Имаме хаш клучеви, и имаме клучеви опсег. Тоа е фино. И тоа е на основните маса, јас доби една клучна хаш, добив една клучна опсег. 

Што значи тоа? Јас имам еден атрибут дека јас може да работи богата пребарувања против. Тоа е клучот на опсег. Други атрибути на тој item-- Јас може да се филтрираат на овие атрибути. Но не можам да ги правите нештата како тоа почнува со, или е поголема од. 

Како можам да го направите тоа? Создадам индекс. Има два вида на индекси во DynamoDB. Индекс е навистина уште еден поглед на табелата. И локалното средно индекс. 

Првиот што ќе се зборува за. Така да локалните секундарни се коегзистирале на иста партиција, како на податоци. И како такви, тие се на истите физички јазол. Тие се она што ние го нарекуваме доследни. Значење, тие ќе признаат пишува заедно со масата. Кога пишувам доаѓа во, ние ќе пишувам преку индексот. Ќе пишувам до масата, и тогаш ќе го признае. Значи тоа е конзистентна. Откако на запишување е признати од табелата, тоа е гарантирано дека локално средно индекс ќе имаат иста визија на податоци. Но, она што ќе ви овозможи да направите е да се дефинираат алтернативни клучеви опсег. 

Мора да се користи истиот хеш Клучот како примарен маса, бидејќи тие се ко-лоцирани на иста партиција, а тие се доследни. Но, можам да креирате индекс со различни клучеви опсег. Така на пример, ако имав производителот кој имаше маса суровини делови кои доаѓаат во. И суровини делови дојдат, и тие се собрани од страна на Собранието. А можеби и таму е се потсетиме. 

Било кој дел, што е направено од страна на овој производителот по овој датум, Јас треба да се повлече од мојата линија. Јас може да се вртат индекс дека ќе се бара, Собирање на денот на Производство на тој дел. Значи, ако мојата маса ниво беше веќе hashed од страна на производителот, Можеби тоа беше договорено на дел проект, јас може да креирате индекс слезе од табелата како hashed од производителот и се движи на датумот на производство. И на тој начин би можел да кажам, нешто што беше произведен помеѓу овие датуми, Јас треба да се повлече од линијата. Значи тоа е локално средно индекс. 

Ова има ефект на ограничување на вашиот хаш space копчето. Бидејќи тие егзистирале на истата складирање јазол, тие се ограничи клучните хаш простор до 10 гигабајти. DynamoDB, под маси, ќе партиција вашата маса на секои 10 гигабајти. Кога ќе се стави 10 свирки на податоци во, ние одат [PHH], а ние се додаде уште еден јазол. 

Ние не ќе се подели на ЛСИ низ повеќе партиции. Ние ќе се подели на табелата. Но ние нема да се подели на LSI. Па тоа е нешто важно да се разбере е ако правиш многу, многу, многу големи колонии, тогаш ви се случува да биде ограничено до 10 гигабајти на вашиот LSIs. 

Ако тоа е случај, можеме да користат глобалните секундарни. Глобалната се секундарни навистина друга маса. Тие постојат целосно исклучување на на страната на вашиот примарен табелата. И тие ми овозможи да се најде сосема поинаква структура. Значи мислам на тоа како се поставува на податоци во две различни маси, структурирани во два различни начини. 

Јас може да се дефинира целосно различни хаш клуч. Јас може да се дефинира целосно различни клучни опсег. И можам да ја извршите оваа целосно независно. Како што, впрочем, јас сум пропишана мојот капацитет за читање и да пишувам за мојот капацитет глобалната секундарни индекси целосно независно на мојата примарна табела. Ако јас се дефинира тој индекс, им кажувам тоа колку читаат и пишуваат капацитет тоа се случува да биде во употреба. 

И кој е одделен од мојата примарна табела. Сега двата индекси ни овозможи да се не само што го дефинираат хаш и опсег на клучеви, но тие ни овозможуваат да се проектираат дополнителни вредности. Па ако сакам да прочитам на индекс, и сакам да се добијат некои збир на податоци, Јас не треба да се вратиме на главното табела за да го добиете дополнителни атрибути. Јас може да го предвиди оние дополнителни атрибути во табелата за поддршка на шемата за пристап. Знам дека си веројатно се навлегува во некои навистина, really-- навлегува во плевел тука на некои од овие работи. Сега добив да лебдат надвор од ова. 

ПУБЛИКАТА: [Беззвучен] --table клучните мислеше е хаш? Оригиналниот хаш? Мулти-ребра? 

RICK Houlihan: Да. Да. Клуч на табелата во основа поени назад кон објектот. Па индекс е покажувач назад до оригинални предмети на масата. Сега можете да изберете да се изгради индекс, кој има само клуч на маса, и нема други својства. И зошто би можеле да го направам тоа? Па, можеби и јас имам многу големи предмети. 

Јас навистина само треба да знаете which-- мојот модел на пристап може да се каже, кои предмети содржат овој имот? Не треба да се врати на објектот. Јас само треба да знаете кои предмети го содржат. За да може да се изгради индекси кои имаат само еден клуч на табелата. 

Но, тоа е пред се она што индекс во базата на податоци е за. Тоа е за да се биде во можност брзо да идентификуваат која евиденција, кои редови, кои предмети во табелата имаат својствата кои сум во потрага по. 

GSIs, па како функционираат тие? GSIs во основа се асинхрони. Ажурирање доаѓа во табелата, маса е тогаш асинхроно ажурирани на сите ваши GSIs. Ова е причината зошто GSIs се на крај доследни. 

Важно е да се напомене дека кога ќе градиме GSIs, и да се разбере сте создавање друга димензија на aggregation-- Сега да речеме добар пример тука е производител. Мислам дека може да се зборува за производителот на медицинскиот уред. Производителите на медицинските помагала Честопати имаат серијали делови. Делови кои одат во замена на колк сите имаат малку серискиот број на нив. И тие би можеле да имаат милиони и милиони и милијарди делови во сите уреди кои можат да брод. Па, тие треба да ја собира под со различни димензии, сите делови во собранието, сите делови кои биле направени на одредена линија, сите делови кои дојдоа во од одреден производител на одреден датум. И овие агрегации понекогаш станувам во милијарди. 

Па јас работам со некои од овие момци кои страдаат бидејќи тие се создавање овие џиновските агрегации во средното индекси. Тие може да имаат суровини делови маса што доаѓа како само хаш. Секој дел има уникатен сериски број. Јас го користам на сериски број како хаш. Убаво е. Суровини мојата маса податоци се шири целиот простор клуч. Моето [? пишува?] [? голтање?] е неверојатна. И јас земам уште голем број на податоци. Тогаш она што го прават е тие создаваат GSI. И велам, знаеш што, јас треба да се види сите делови за овој производител. Па, одеднаш сум земајќи милијарди редови, и да ги работи со излез еден јазол, затоа што кога Јас агрегираат како производителот проект како хаш, и дел број како опсег, потоа сите одеднаш сум ставање милијарда делови во она што овој производител ме избави. 

Кој може да предизвика многу на притисок врз GSI, повторно, бидејќи јас сум ковале еден јазол. Јас сум ставање на сите овие внесува во еден јазол. И тоа е вистински проблематична употреба случај. Сега, добив добар дизајн модел за тоа како да се избегне тоа. И тоа е еден од проблемите дека секогаш се работи со. Но, она што се случува, е можеби GSI нема доволно капацитет за запишување да бидат во можност да им помогнам на сите оние редови во еден јазол. И што се случува тогаш е примарна, маса на клиентот, од основните маса ќе биде пригушен GSI затоа што не можат да продолжат. Значи мојот вметнете стапка ќе падне на основните маса како мојот GSI се обидува да го задржи. 

Добро, па GSI е, LSI е, кој треба да го користам? LSI се конзистентни. GSI се на крај доследни. Ако тоа е во ред, јас препорачуваме користење на GSI, тие се многу пофлексибилни. LSI може да се моделираат како GSI. И ако големината на податоците по хаш клучеви во вашата колекција надминува 10 гигабајти, тогаш ви се случува да сакаат да го користат GSI бидејќи тоа е само еден хард рок. 

Добро, така скалирање. Автопат во Динамо ДБ, можете обезбедување може [Беззвучен] автопат во табела. Имаме клиенти кои имаат пропишана 60 billion-- се прави 60 милијарди барања, редовно работи со повеќе од милион барања секунда на нашите маси. Има навистина нема теоретска ограничување на тоа колку и колку брзо на табелата може да работи во Динамо ДБ. Постојат некои меки граници на вашата сметка кои ги стави таму, така дека вие не пукнам. Ако сакате повеќе од дека, не е проблем. Ќе дојдеш да ни каже. Ние ќе се претвори до бирање. 

Секоја сметка е ограничено на одредено ниво во секој сервис, само надвор од Прилеп така што луѓето не одат луд самите се во неволја. Без ограничување на големината. Може да се стави било кој број на предмети на масата. Големината на некој објект е ограничена на 400 килобајти, секој, тоа би било не ставка атрибути. Така што збирот на сите атрибути е ограничена на 400 килобајти. А потоа повторно, имаме таа мала ЛСИ прашање со лимит од 10 гигабајти на хаш. ПУБЛИКАТА: Мал број, јас сум недостасува она што ќе ми кажеш, дека is-- ПУБЛИКАТА: Ох, 400 килобајт е максималната големина на точка. Па некој објект има сите атрибути. Значи 400 k е вкупната големина на таа ствар, 400 килобајти. Па на сите атрибути во комбинација, на сите податоци тоа е во сите оние атрибути, навива во вкупната големина, моментално денес ограничување на објектот е 400 к. Така скалирање повторно, постигнат преку партиционирање. Автопат е предвидено на ниво на табелата. И таму е навистина две рачки. Ние ги прочитале капацитет и пишува капацитет. 

Значи овие се прилагоди независно еден од друг. Мерка RCU е строго конзистентни чита. Добро, па ако си ти што зборуваш Сакам 1,000 RCU е тие се строго во согласност, оние кои се во согласност чита. Ако ви кажам што сакам евентуална согласност чита, можеш одредба 1.000 RCU е, си оди да се добие 2.000 на крајот конзистентна чита. И половина од цената за оние на крајот се состои во чита. 

Повторно, прилагодени независно еден од друг. И тие имаат throughput-- Ако консумираат 100% од вашите RCU, вие нема да влијаат на достапноста на своите права. Така што тие се целосно независни една од друга. Добро, па една од работите кои Јас спомнав накратко беше Дроселиране. Дроселиране е лошо. Дроселиране покажува лошо нема SQL. Постојат работи кои можеме да направиме за да им помогне ви го олесни Дроселиране кои ви се соочуваат. Но најдобро решение на ова е да го земеме Еден поглед во она што го правиш, бидејќи има анти-модел во игра тука. 

Овие работи, работи како не-униформа оптеретеноста, топла клучеви, топла партиции. Јас сум притискање одреден простор клуч многу тешко поради некоја посебна причина. Зошто го правам ова? Ајде да дознаам дека надвор. Јас сум мешање мојата топла податоци со ладна податоци. Јас сум допуштајќи мојот маси се огромен, но има навистина само подмножество на податоците што е навистина интересно за мене. Така и за дневниците со податоци, на пример, многу клиенти, тие се логирате податоци секој ден. Тие се здобија со огромно количество на дневниците со податоци. 

Ако сте само фрлање сите дека најавите податоци во една голема маса, со текот на времето таа маса се случува да се масивни. Но јас сум навистина заинтересирани само за последните 24 часа, во последните седум дена, во последните 30 дена. Без оглед на прозорецот на време дека јас сум заинтересиран во потрага за настанот што ми пречи, или случај дека е интересно за мене, тоа е единствениот прозорец времето што ми треба. Па зошто сум ставање 10 години во вредност од дневниците со податоци во табелата? Она што предизвикува се табелата фрагмент. 

Тоа добива огромна. Тоа почна да се шири надвор низ илјадници јазли. И бидејќи вашиот капацитет е толку ниска, ти си всушност го оценувате ограничување на секоја еден од оние поединечните јазли. Значи, да почнеме гледајќи како ние да се тркалаат во текот на таа маса. Како ние да управуваат со податоци дека малку подобро да се избегнат овие проблеми. И што значи таа изгледа? Тоа е она што изгледа како тоа. Ова е тоа што лошо NoSQL изгледа. 

Добив топла клучот овде. Ако се погледне на страна тука, овие се сите мои партиции. Добив 16 партиции се тука на овој особено базата на податоци. Ние го правиме ова цело време. Трчам овој за клиентите сите времиња. Таа се вика Мапа на топлина. Топлина на сајтот ми кажува колку сте пристап до вашиот простор клуч. И што тоа ми вели е дека постои една особено хаш дека овој човек сака на страшно многу, затоа што тој е удирање тоа, навистина, навистина тешко. 

Па сината е убаво. Ние како сина. Ние не сакаме црвено. Црвена, каде што притисокот добива до 100%. 100%, сега ви се случува да се задушува. Значи секогаш кога ќе видиме како црвени линии this-- и тоа не е само Динамо DB-- секоја база на податоци NoSQL има овој проблем. Постојат анти-облици што може да вози на овие видови на услови. Тоа што го правам е јас работам со клиенти за ублажување на овие услови. 

И што значи таа изгледа? И ова се добивање на најмногу од Динамо ДБ автопат, но тоа е навистина станува најмногу од NoSQL. Ова не е ограничена на Динамо. Ова е definitely-- јас порано работела во Mongo. Јас сум запознаен со многу NoSQL платформи. Секој од нив има овие типови на топла клучните проблеми. За да го добиете најмногу од било NoSQL база на податоци, посебно Динамо ДБ, сакате да се создаде табели каде елемент клучните хаш има со голем број на различни вредности, висок степен на кардиналност. Бидејќи тоа значи дека јас пишувам до многу различни кофи. 

Повеќе кофи сум пишувате, толку е поголема веројатноста Јас сум за да се шири и дека пишува оптоварување или читај вчита надвор низ повеќе јазли, толку е поголема веројатноста сум да има висока продуктивност на масата. А потоа сакам вредности да бидат побарал прилично еднакво во времето и подеднакво како случајно што е можно. Па, тоа е вид на интересни, затоа што јас навистина не може да контрола кога корисниците се дојде. Па доволно е да се каже, ако се шири работите надвор низ клучните простор, ние најверојатно ќе биде во подобра форма. 

Има одреден износот на време испорака дека нема да одиш за да биде во можност за контрола на. Но, тие се навистина две димензии кои ги имаме, простор, пристап рамномерно ширењето, време, барања доаѓаа рамномерно распоредени во времето. И ако тие две услови се исполнети, тогаш тоа е она што е Ќе изгледа како. Ова е многу подобро. Навистина сме среќни тука. Имаме многу дури шемата пристап. Да, можеби ти си добивање на малку притисок на секои сега и тогаш, но ништо не се навистина премногу голема. Па тоа е неверојатно колку многу пати, кога се работи со клиенти, тој прв графикон со големи црвени бар и сето она што е грда, жолта сите над местото, ние да расчисти со вежбање по неколку месеци на ре-архитектура, тие се работи на исти обемот на работа на Марс исто оптоварување. И тоа е она што е во потрага како сега. Значи она што ќе го добиете со NoSQL е шема на податоци што е апсолутно врзани за модел за пристап. 

И можете да го оптимизирате дека шемата на податоци за поддршка на тој образец пристап. Ако не, тогаш сте ќе треба да се види овие типови на проблеми со оние жешки копчиња. 

ПУБЛИКАТА: Па, неизбежно некои места се ќе биде потопло од другите. 

RICK Houlihan: Секогаш. Секогаш. Да, мислам дека секогаш a-- и повторно, има некои шеми на дизајн ќе се добие преку која ќе се зборува за тоа како да се справи со овие супер големи конгломерати. Мислам, јас мора да ги имаат, како да се справите со нив? Добив доста добра употреба случај што ние ќе зборуваме за за тоа. 

Добро, па ајде да разговараме за некои клиенти сега. Овие момци се AdRoll. Не знам дали сте запознаени со AdRoll. Најверојатно ги види многу на интернет пребарувач. Тие се реклама ре-таргетирање, тие се најголемиот бизнис реклама повторно таргетирање таму. Тие нормално редовно прегазен 60 милијарди трансакции на ден. Тие се прави повеќе од милион трансакции во секунда. Тие имаат прилично едноставна табела структура, најпрометните табелата. Тоа е во основа, само хаш клучот е на колачињата, опсегот е демографската категорија, а потоа третиот атрибут е резултатот. 

Па сите ние имаме колачиња во нашите прелистувач од овие момци. И кога ќе се оди на учеснички трговец, тие во основа ќе ви резултат во склопот различни демографски категории. Кога ќе отидете на веб-страница и да се каже сакам да го видам ова ad-- или во основа не се каже that-- но кога ќе оди на веб страната тие велат дека сакате да го видите овој оглас. И тие одат добие таа реклама од AdRoll. AdRoll ви гледа нагоре на нивната маса. Ќе најдат вашиот колаче. Рекламни кажувам нив, сакам некој кој е на средна возраст, 40-годишен човек, во спортот. И тие ќе ви резултат во оние демографијата и тие ќе одлучат дали или не тоа е добра реклама за вас. 

Сега тие имаат со SLA рекламирање на нивните провајдери да им обезбеди на под-10 милисекунда одговор на секоја барање. Значи тие се користат Динамо ДБ за ова. Тие ни една удирајќи милион барања во секунда. Тие се во можност да се направи сите нивни Lookups, тријажа сите тие податоци, и да добијат дека додадете линк назад кон тоа рекламата за помалку од 10 милисекунди. Тоа е навистина прилично феноменален имплементација, кои тие го имаат. 

Овие момци actually-- се овие момци. Не сум сигурен дали тоа е овие момци. Може да биде овие момци. Во основа us-- рече не, јас не мислам дека тоа им беше. Мислам дека тоа беше некој друг. Бев на работа со клиентот дека ми кажа дека сега, кога тие го качил на Динамо ДБ, тие се трошење повеќе пари на закуски за нивниот тим за развој на секој месец отколку што трошат на нивната база на податоци. Па тоа ќе ви даде идејата за намалување на трошоците кои може да се добијат во Динамо ДБ е огромна. Добро, dropcam уште една компанија. Овие човек е вид of-- ако мислите на интернет на нештата, dropcam во основа е видео безбедноста на интернет. Ќе се стави вашата камера таму. Камерата има детектор на движење. Некој доаѓа заедно, предизвикува точка знак. Камерата започнува со снимање за некое време додека тоа не го детектира било движење веќе. Става видеото се на интернет. 

Dropcam беше компанија која е во основа се префрли на Динамо ДБ затоа што тие се соочуваат со огромни растечка болка. И она што тие ни рекоа: одеднаш петабајти на податоците. Тие немаа идеја на нивните услуги ќе биде толку успешен. Повеќе Влезни видео од YouTube е она што овие момци се добива. Тие користат DynamoDB да ги пратите сите метаподатоците за сите нивни видео клучните точки. 

Така што тие имаат S3 кофи тие им помогнам сите бинарни артефакти во. И тогаш тие имаат Динамо ДБ рекорди кои насочи луѓето на оние S3 три објекти. Кога тие треба да се погледне на видео, тие се погледне до рекорд во Динамо ДБ. Тие кликнете на линкот. Тие ги повлечат надолу на видео од S3. Значи, тоа е вид на она што ова изгледа како. И ова е директно од нивниот тим. 

Динамо ДБ намалува нивната време на испорака за видео настани од пет до 10 секунди. Во нивните стари релациона продавница, тие се користат за да се оди и да се изврши повеќе сложени пребарувања да фигура дознаете кој видеа да ги повлечат надолу, на помалку од 50 милисекунди. Така, тоа е неверојатно, неверојатно колку перформанси може да се добие кога ќе се оптимизира и ќе се вклучите на основните база на податоци за поддршка на шемата за пристап. Halfbrick, овие момци, што е тоа, Овошје нинџа претпоставувам дека е нивна работа. Дека сите работи на Динамо ДБ. И овие момци, тие се одличен тимот за развој, голем развој продавница. 

Не е добар тим опс. Тие не се многу на работа ресурси. Се бореа обидува да го задржи нивната примена инфраструктура до и трчање. Тие дојдоа кај нас. Гледаа во која Динамо ДБ. Велат тие, тоа е за нас. Тие ја создадоа нивната целина примената рамка за тоа. Некои навистина убаво коментари тука од екипата на нивната способност До сега се фокусира на градење играта, а не има да се одржи на инфраструктура, која станува огромна количина на надземни за својот тим. Па ова е нешто that-- на корист што ќе го добиете од Динамо ДБ. 

Сите во право, впуштајќи се во моделирање на податоци тука. И разговаравме малку за ова 1-1, еден на многу, и многу многу тип односи. И како да се задржи оние во Динамо. Во Динамо ДБ ние ги користиме индекси, генерално гледано, да се ротираат на податоци од еден вкус на други. Хаш копчиња, копчињата опсег, и индекси. 

Во конкретниов На пример, како што повеќето држави имаат обврска за лиценцирање што само една возачка дозвола по лице. Вие не може да оди да се добие драјвер за двајца лиценци во состојба на Бостон. Не можам да го направи тоа во Тексас. Тоа е вид на начинот на кој таа е. И така на DMV, имаме Lookups, ние сакате да се погледне до возачката дозвола по број на социјално осигурување. Сакам да се погледне до детали на корисник со регистарски број на возачот. 

Така што би можеле да имаат маса на корисникот дека има клучна хаш на серискиот број, или број на социјално осигурување, и различни атрибути, дефиниран на ставка. Сега на таа табела јас би можеле да се дефинира дека GSI завртува околу кој се вели дека сакам клучен хаш на лиценцата, а потоа сите други предмети. Сега ако сакам да се пребарува и да се најде на регистарски број за секој даден социјална Број на безбедноста, што можам анализирање на главната маса. 

Ако сакам да се пребарува и сакам за да го добиете за социјално осигурување број или други атрибути од страна на регистарски број, јас може да се пребарува на GSI. Тој модел е тоа што еден на еден однос. Само еден многу едноставен GSI, флип оние работи наоколу. Сега, се зборува за една многу. Еден на многу во основа вашиот клуч хаш опсег. Каде што ние се добие многу со овој употреба случај е податок монитор. Податоци монитор доаѓа во редовна интервал, како интернет на нештата. Ние секогаш ги добиете сите овие евиденција доаѓаат во секое време. 

И сакам да ги најдете сите читања помеѓу одреден временски период. Тоа е многу честа појава за пребарување во следење на инфраструктурата. Начинот на кој одите за тоа е да се најде едноставна табела структура, една маса. Имам маса мерења уред со клуч хаш на проект на уредот. И јас имаат клучна опсег на временска ознака, или во овој случај, еп. И која ми дозволува извршување сложени пребарувања против тој клуч опсег и да се вратат оние записи кои се во однос на резултат во собата што јас го барате. И таа го гради дека еден на многу односи во примарната табелата со користење на хаш клуч, клучот опсег структура. 

Значи, тоа е вид на гради во табелата во Динамо ДБ. Кога ќе се дефинира хаш и опсег T табела, јас сум дефинирање на еден на многу односи. Тоа е односот родител-дете. 

Ајде да зборуваме за многу на многу врски. И за овој конкретен пример, повторно, ние ќе треба да се користи GSI е. И ајде да зборуваме за игри сценарио, каде што имам дадено корисник. Сакам да дознаете сите игри кои тој е регистриран за или играње во. И за одредена игра, јас сакате да ги најдете сите корисници. Па, како да го направам тоа? Мојата маса корисник игри, јас ќе одам да имаат клучна хаш на корисничко ID и клучен спектар на играта. 

Така што корисникот може да имаат повеќе игри. Тоа е еден на многу односи помеѓу корисникот и игри свири. А потоа на GSI, Јас ќе флип дека околу. Ќе хаш На играта и Јас ќе се движат на корисникот. Значи, ако јас сакам да ги добиете сите игра на корисникот играат во, Ќе се пребарува на главната маса. Ако сакам да ги добијат сите корисници кои се повеќе се игра одредена игра, Јас се пребарува на GSI. Па да видиме како можеме да го направите ова? Да се ​​изгради овие GSI за поддршка на употреба случај, пријавата, пристап шема, апликацијата. 

Ако треба да се пребарува на оваа димензија, ајде ме создаде индекс на таа димензија. Ако не се направи, не ми е грижа. И во зависност од употребата случај, јас може да се стави на индекс или јас не би можеле да. Ако тоа е едноставно еден на многу, од основните маса е во ред. Ако треба да се направи многу за овие многу, или треба да се направи една до оние, тогаш можеби и јас треба до втората индексот. Значи сето тоа зависи од она што јас се обидувам да се направи и она што јас се обидувам да се остварува. 

Веројатно јас не одам да се трошат премногу многу време зборуваме за документи. Оваа добива малку, веројатно, подлабоко отколку што треба да одат во. Ајде да зборуваме малку за богат израз пребарување. Па во Динамо ДБ имаме способноста да се создаде она што го нарекуваме проекција изрази. Проекција изрази се едноставно одбирање на полето или вредностите што сакате да се прикаже. Добро, па јас се направи избор. Јас се направи барање против Динамо ДБ. И велам, знаеш што, шоу мене само коментарите пет ѕвездички за овој конкретен производ. Значи, тоа е сè што сакате да ја видите. Не сакам да ги видам сите други атрибути на ред, Јас само сакам да се види тоа. Тоа е исто како во SQL кога ќе велат одберете ѕвезда или од маса, добивате сè. Кога велам изберете име од маса, добивам само еден атрибут. Тоа е истиот вид на работа во Динамо ДБ или друг NoSQL бази на податоци. Филтер изрази ми дозволите да во основа го намали резултатот во собата надолу. Па јас се направи пребарување. Барањето може да се врати со 500 предмети. Но, јас само сакам на предмети кои имаат атрибут кој вели дека ова. Добро, па ајде да ги филтрираат оние предмети што не се совпаѓаат тоа особено пребарување. Значи ние треба филтер изрази. 

Филтер изрази може се работи на секој атрибут. Тие не сакале пребарувања опсег. Поставуваат прашања се повеќе селективен. Филтер пребарувања бараат од мене да одат се постави целата резултатите, а потоа издлаби податоците не сакам. Зошто е тоа важно? Затоа што јас го прочитате сите. Во прашање, јас ќе одам да се прочита и тоа се случува да биде гигант за податоци. А потоа јас ќе одам да издлаби од она што ми треба. И ако сум само резба од неколку редови, тогаш тоа е во ред. Тоа не е толку неефикасни. 

Но, ако го читам цел куп податоци, само да издлаби од еден објект, тогаш јас ќе одам да биде подобро исклучите со користење на барањето опсег, бидејќи тоа е многу повеќе селективен. Тоа се случува да ме спаси многу пари, затоа што плаќаат за кои пишува. Кога резултатите што ќе се врати премине таа жица може да бидат помали, но јас плаќам за читање. Па да се разбере како дека сте добивање на податоци. Тоа е многу важно во Динамо ДБ. 

Условен израз, тоа е она што можете да го повикате оптимист заклучување. Ажурирање, ако постои, или, ако оваа вредност е еквивалентно на она што јас го определи. И ако имам време штембил на рекорд, би можел да ги чита податоците. Јас би можеле да го променат тоа податоците. Јас би можеле да одат пишуваат дека назад на податоци во базата на податоци. Ако некој го смени евиденција, временската ознака може да се менуваат. И на тој начин моето условно ажурирање може да се каже за ажурирање ако ова е еднакво на временската ознака. Или на ажурирање ќе пропадне, бидејќи некој ажурирани рекорд во меѓувреме. 

Тоа е она што ние го нарекуваме оптимист заклучување. Тоа значи дека некој може да дојде и да го промени, а јас ќе одам да го детектира кога ќе се вратам да пишувам. И тогаш јас всушност може да се прочита дека податоци и да каже, ох, тој го промени тоа. Ми треба да сметка за тоа. И јас може да се променат податоците во мојата снимате и да ги применуваат друг ажурирање. За да можете да го фати оние поединечни промени кои се случуваат помеѓу времето да го прочитате на податоците и време може да напише на податоците. 

ПУБЛИКАТА: И на филтерот изразување, всушност, не значи на бројот или not-- 

[Interposing ГЛАСОВИ] RICK Houlihan: Јас нема да се премногу во ова. Ова е резервиран збор. Поглед на фунтата е резервиран клучен збор во Динамо ДБ. Секоја база на податоци има свој задржани имиња за збирки не можете да го користите. Динамо ДБ, ако се определи една фунта пред тоа, можете да дефинирате тие имиња се погоре. Ова е референцирани вредност. Тоа веројатно не е најдобар синтаксата за има таму за оваа дискусија, затоа што тоа се впушта во некои real-- Јас ќе се зборува повеќе во врска со тоа на едно подлабоко ниво. 

Но, доволно е да се каже, ова може да се скенира за пребарување каде што views-- ниту ставови фунтата е поголем од 10. Тоа е нумеричка вредност, да. Ако сакате, можеме да зборуваме за дека по дискусијата. Добро, па ние сме добивање на некои сценарија во најдобрите практики каде што ние ќе треба да се зборува за некои апликации тука. Кои се употребата случаи за Динамо ДБ. Кои се дизајн шеми во Динамо ДБ. 

А првиот ние ќе треба да се зборува за е на интернет на нештата. Па ние ќе добиете многу of-- претпоставувам, она што е it-- повеќе од 50% на сообраќајот на интернет овие денови е, всушност, ги создаваат машини автоматизирани процеси, а не од страна на луѓето. Мислам ова нешто што оваа работа што ви носат околу во вашиот џеб, колку податоци дека тоа нешто е всушност испраќање наоколу без тебе да се знае тоа е апсолутно неверојатен. Вашата локација, информации за тоа колку брзо си оди. Како мислите дека Google Maps дела кога ќе ви кажам што е сообраќајот. Тоа е затоа што постојат милиони и милиони луѓе се вози наоколу со телефони кои се испраќаат податоци во целиот место цело време. Значи, една од работите во врска со овој тип на податоци кој доаѓа во, податоци монитор, влези на податоци, податоците на временски серии, е тоа е обично се само интересни за малку време. По тоа време, тоа е не е толку интересно. Па ние разговаравме за тоа, не дозволувајте оние маси расте без граници. Идејата тука е дека можеби имам 24 часа во вредност од настаните во мојата топла маса. И дека топла маса ќе биде пропишана со многу висока стапка, бидејќи тоа е преземање на голем број на податоци. Тоа е преземање на голем број на податоци и јас сум го чита многу. Имам многу работа пребарувања работи против тие податоци. 

По 24 часа, еј, ти Знаеш што, јас не се грижат. Па можеби секој полноќ ролна мојата маса во текот на нова табела и јас deprovision оваа табела. И јас ќе го земе и RCU е Надолу WCU бидејќи 24 часа подоцна Јас не сум се работи толку многу пребарувања против тие податоци. Па јас ќе одам да се заштедат пари. А можеби и 30 дена подоцна јас не дури и треба да се грижи за тоа сите. Јас би можеле да имаат WCU е на целиот пат на еден, бидејќи знаеш што, тоа е никогаш не се случува да се запишано. На податоци е 30 дена. Тоа никогаш не се менува. 

И тоа речиси никогаш не се случува да се чита, па да се земе дека RCU до 10. И јас сум заштеда на еден тон пари на овој на податоци, и плаќаат само за мојата топла податоци. Значи тоа е важна работа е да се погледне во кога ќе се погледне на временски серии податоци кои доаѓаат во во волумен. Овие се стратегии. Сега, јас само може да го дозволи сите одат на иста маса и само нека таа маса расте. Конечно, јас ќе одам да види перформанси прашања. Одам да мора да почнете да ги архивираат некои од тие податоци на маса, она што не. 

Ајде многу подобро дизајнирате вашата апликација така што ќе можат да работат на овој начин во право. Па тоа е само автоматски во примената код. На полноќ, секоја вечер се тркала на табелата. Можеби она што ми треба е лизгачки прозорец на 24 часа на податоци. Потоа на редовна основа, јас сум повикува на податоци на маса. Јас сум го кастри со Закажана задача и јас сум со тоа ставање врз овие други маси, она што ви треба. Па ако превртување функционира, тоа е одлично. Ако не е, трим него. Но, ајде да се задржи таа топла податоци далеку од твојот студ податоци. Тоа ќе ве спаси многу пари и направи вашиот маси повеќе изведувачки. Затоа, следниот нешто што ние ќе зборуваме за е производ каталог. Производ каталог е доста заеднички за употреба случај. Ова е всушност многу заеднички модел дека ќе видиме во различни нешта. Знаете, Твитер за пример, топла чуруликам. Секој што доаѓа и грабање дека чуруликам. Производ каталог, добив продажба. Добив топла продажба. Добив 70.000 барања по второто доаѓање на производ опис од мојот производ каталог. Го гледаме ова на мало операција доста. Па, како да се справи со тоа? Не постои начин да се справи со тоа. Сите мои корисниците сакаат да се види исто парче на податоци. Тие доаѓаат во, истовремено. И сите тие се прави барања за истиот парче на податоци. Ова ми дава дека топла клуч, дека големо црвено лента на мојот шема што не ни се допаѓа. И тоа е она што изгледа како тоа. Па низ клучните мојот простор јас сум добивање на зачукуваше во точките на продажба. Јас сум добивање на ништо друго место. 

Како можам да се ублажи овој проблем? Па, ние го ублажи овој со кеш. Кеш, се стави во основа на во-меморија партиција во предниот дел на базата на податоци. Успеавме [Беззвучен] кеш, како може може да се постави свој кеш, [Беззвучен] кеш [? г,?] она што сакате. Стави дека во предниот дел на базата на податоци. И на тој начин може да се сместат тие податоци од оние жешки копчиња во кои кешот простор и се чита преку кешот. 

И потоа поголемиот дел од вашето чита почнете да барате се допаѓа ова. Добив сите овие кеш хитови се тука и јас се ништо случува овде бидејќи базата на податоци се седи зад кеш и никогаш не се чита дојде преку. Ако се менува податоците во база на податоци, треба да се ажурира на кешот. Можеме да го користите нешто пареи како да го направите тоа. И јас ќе ви објасниме како тоа работи. Сите права, размена на пораки. Е-пошта, сите ние се користи е-мејл. 

Ова е прилично добар пример. Имаме некој вид на пораки табелата. И добивме и излезното сандаче. Тоа е она што на SQL би изгледаат како да се изгради дека сандаче. Ние вид на се користи истиот вид на стратегија за користење на GSI е, GSI е за моето сандаче и моите излезното сандаче. Па добив суровини пораки што доаѓаат во мојата маса пораки. И првиот пристап кон ова би можело да биде, да речеме, во ред, нема проблем. Јас имам суровини пораки. Пораки што доаѓаат [Беззвучен], id пораката, тоа е одлично. Тоа е мојата единствена хаш. Одам да се создаде две GSI, еден за моето сандаче, една за мојата излезното сандаче. И првото нешто што јас ќе сторам се ќе кажам мојот клучните хаш е ќе биде примачот и Одам да се организираме на денот. Ова е фантастично. Добив убаво моето мислење тука. Но, има малку проблем тука. И ќе наиде на ова во релациони бази на податоци, како и. Тие повикаа вертикално партиционирање. Сакате да го задржите вашиот големи податоци далеку од вашиот малку податоци. 

И причината зошто е затоа што морам одат прочитате на предмети за да се добие атрибути. И ако ми се сите тела за тука, потоа читање само неколку елементи ако должината моето тело е просек од 256 килобајти, секој, математика добива прилично грда. Така велат дека сакам да ја прочитам Давид сандаче. Давид сандаче има 50 предмети. Просечната и големина е 256 килобајти. Еве го мојот конверзија сооднос за RCU е четири килобајти. 

Добро, ајде да одиме со на крај доследни чита. Јас сум се уште јадат 1600 RCU е само да го прочитате на Давид сандаче. Уф. Добро, сега ајде да размислиме за тоа како функционира апликацијата. Ако сум во е-маил апликацијата и Го барам во моето сандаче, и гледам во телото на секоја порака, Не, јас сум во потрага на резимеа. Јас сум во потрага по само заглавија. Значи, да се изгради маса структура што повеќе наликува тоа. 

Значи тука е информации дека мојот работното потреби. Тоа е во моето сандаче GSI. Тоа е датумот, на испраќачот, предмет, а потоа Проект на пораката, што укажува назад на табелата со пораки каде можам да добијам на телото. Па, овие ќе биде рекорд лични карти. Тие ќе точка назад кон ставка лични карти на масата во Динамо ДБ. Секој индекс секогаш creates-- секогаш има елемент Проект, како дел of-- дека доаѓа со индексот. 

Во ред. ПУБЛИКАТА: Тоа го кажува каде што се чуваат? RICK Houlihan: Да, тоа кажува exactly-- тоа е токму она што го прави. Таа вели дека ова е мојата повторно рекорд. И тоа ќе го истакне вратам на мојот повторно рекорд. Токму така. Добро, па сега е моето сандаче всушност многу помал. И ова всушност поддржува на работното на е-маил апликација. Значи моето сандаче, јас кликнете. Да одам заедно и ќе кликнете на пораката, тоа е моментот кога јас треба да одам да купам телото, затоа што ќе одам да се одат на поинаков став. Значи, ако мислите дека за видот на MVC рамка, модел погледнете контролорот. 

Моделот содржи податоци кои треба погледот и контролорот се поврзува со. Кога ќе се промени на рамката, кога Сменам перспектива, тоа е во ред да се вратиме на сервер и населат на моделот, затоа што тоа е она што корисникот очекува. Кога го менуваат ставови, тоа е кога ние може да се врати во базата на податоци. Толку е-маил, кликнете. Јас сум во потрага по телото. Двупосочен. Одам да купам телото. 

Читам многу помалку податоци. Јас сум само читање на тела кои Давид му треба кога тој има потреба од нив. И не ми изгори во 1600 година RCU е само да ја покаже својата сандаче. Па сега that-- ова е начинот на дека LSI или GSI-- Жал ми е, GSI, ќе работат надвор. Добивме наша хаш на примачот. Имаме клучот спектар на денот. И ние го добивме проектираниот атрибути дека ние треба само да го поддржи ставот. 

Ние ротираат дека за излезното сандаче. Постигнување на испраќачот. И во суштина, имаме на многу убав, чист поглед. И тоа е basically-- ние имаат оваа убава пораки маса и тоа е се шири убаво бидејќи тоа е само хаш, hashed порака проект. И имаме две индекси кои ротираат исклучување на табелата. Добро, па Идејата тука е не задржи големи податоци и овој мал податоци заедно. Поделба вертикално, партиција оние маси. Не читаат податоци што не мора да се. Добро, играњето на игри. Сите ние сакале игри. Барем ми се допаѓа игри тогаш. Па некои од работите дека ние се справи со кога ние сме размислување за игри, нели? Игри на среќа, овие денови, особено мобилни игри, е за размислување. А јас ќе одам да ги ротира тука малку подалеку од DynamoDB. Одам да се донесе во некои од дискусија околу некои од други технологии AWS. 

Но, идејата за игри е да се мисли за во однос на API-јата, API-јата, кои се, општо земено, HTTP и JSON. Тоа е начинот на мобилни игри вид на комуницирате со нивните краеви назад. Тие го прават JSON која испраќаш мислења. Тие се на податоци, и тоа е за сите, општо земено, во убаво JSON API-јата. 

Работите како се пријатели, се податоци на табла, размена, кориснички генерирани содржини, притисни назад до системот, овие се видови на нештата дека ние ќе треба да се направи. Бинарни податоци со средства, овие податоци не може да седат во базата на податоци. Ова може да седат во една објект продавница, нели? Но, за базата на податоци се случува да се завршат кажувам системот, кажување на примена каде да одам да го добие. И неизбежно, мултиплеер сервери, задниот крај на инфраструктурата, и дизајниран за високо достапност и приспособливост. Значи овие се нештата што сите ние сакаме во гејминг инфраструктура денес. 

Па ајде да ги разгледаме во што личи тоа. Доби основни задниот крај, многу јасна. Имаме систем тука со повеќе Достапност зони. Ние разговаравме за тоа како AZS being-- размислуваат од нив како посебни центри за податоци. Центарот повеќе податоци по АЗ, но тоа е во ред, само мислам на нив како одделни податоци центри кои се географски вина и изолирани. 

Ние ќе треба да имаат Двојката EC2 инстанци. Ние ќе треба да имаат некои назад end серверот. Можеби, ако сте во наследство архитектура, ние сме користење на она што ние го нарекуваме RDS, релациона база на податоци услуги. Би можело да биде MSSQL, MySQL, или нешто слично. Ова е начинот на кој многу апликации се дизајнирани денес. 

И ние би можеле да сакате да одите со тоа е кога ние скала надвор. Ние ќе одиме напред и да се стави кофата S3, таму горе. И дека S3 кофа, наместо да служи до тие предмети од нашите servers-- ние би можеле да го направите тоа. Ги ставите сите ваши бинарни објекти на вашите сервери и можете да го користите овие сервер случаи да им служи на тие податоци до. Но тоа е прилично скапи. 

Подобар начин да го направите е да се оди напред и да стави оние предмети во S3 кофа. S3 е објект складишта. Тоа е изграден специјално за служејќи се овие видови на нештата. И нека оние клиенти побара директно од оние објект кофи, разтоварвам серверите. Значи ние сме почнуваат да скала од тука. 

Сега стигнавме корисници од целиот свет. Добив корисници. Ми треба да имаат содржина на локално ниво наоѓа во близина на овие корисници, нели? Јас направивме една кофа S3 како мојот извор на податоци. А јас ќе фронт дека со дистрибуцијата CloudFront. 

CloudFront е ЦД и содржината на испорака мрежа. Во основа тоа се земаат податоци што ќе се определи и сето тоа кешира преку интернет така што корисниците може да има насекаде многу брз одговор кога што ќе ги побараат тие предмети. 

Па ќе го добиете идеја. Ти си вид на проширува сите аспекти на AWS тука за да се стори ова. И на крајот, ние фрли во авто скалирање група. Па нашите AC2 инстанци од нашите сервери на играта, како тие почнуваат да се busier и busier и busier, тие само ќе се вртат на друг На пример, се вртат друг пример, спин друг пример. Па технологија AWS има, тоа Ви овозможува да го одредите параметрите околу која вашите сервери ќе се зголеми. Па можете да имате n број на сервери таму во било кое дадено време. И ако вашиот товар оди, тие ќе се намалува, бројот ќе се намали. И кога товарот се враќа, тоа ќе расте назад надвор, еластично. 

Па ова изгледа одлично. Имаме голем број на EC2 инстанци. Ние може да се стави во кеш предниот дел на бази на податоци, се обиде и да се забрза со бази на податоци. Следната точка на притисок обично луѓето гледаат е тие да скала на играта со помош на релациона база на податоци систем. Jeez, за базата на податоци перформанси е страшно. Како да ја подобри тоа? Ајде да се обидеме ставање кеш пред тоа. 

Па, кеш не функционира толку голема во игри, нели? За игри, пишувањето е болна. Игри се многу тешки да пишува. Кешот не работи кога сте пишуваат тешки бидејќи секогаш си Мора да се ажурира на кешот. Ажурирање на кеш, тоа е ирелевантно да се кеширање. Тоа е всушност само дополнителна работа. 

Значи, каде ќе одиме тука? Имаш голем грло таму долу во базата на податоци. И место каде да одат очигледно е поделба. Поделбата не е лесно да се направи и кога сте кои се занимаваат со релациони бази на податоци. Со релациони бази на податоци, ти си одговорни за управување, ефикасно, простор клуч. Ти си велејќи корисници меѓу А и М оди тука, помеѓу N и Z оди таму. А ти си префрлување низ целата апликација. Па си имаш работа со овој извор на податоци партиција. Имате трансакциска ограничувања кои не span партиции. Имаш сите видови на неред дека сте кои се занимаваат со, таму долу, во обид да се справи со скалирање надвор и градење на поголема инфраструктура. Тоа е само не е забавно. 

ПУБЛИКАТА: Значи сакаш да кажеш дека растечки извор поени забрзува процесот? RICK Houlihan: Зголемување? ПУБЛИКАТА: Извор поени. RICK Houlihan: Извор поени? ПУБЛИКАТА: Од информациите, каде што информацијата е што доаѓаат од? RICK Houlihan: Не Што сакам да кажам дека се зголемува број на партиции во чување на податоци подобрува пропусната моќ. Значи она што се случува овде е на корисниците кои доаѓаат во EC2 пример тука, Па, ако се потребни на корисникот Тоа е на M, јас ќе одам тука. Од N во p, јас ќе одам тука. Од P до Ш, јас ќе одам тука. 

ПУБЛИКАТА: Во ред, така што оние се оние сите складирани во различни јазли? 

RICK Houlihan: Да. Мислам на овие што се различни силоси на податоци. Значи сте морале да го направите тоа. Ако се обидуваш да се направи ова, ако се обидуваш да скала на релациона платформа, тоа е она што го правиш. Сте преземање на податоци и ти си тоа намалување. И ти си го поделба низ повеќе примероци од базата на податоци. А ти си управување со сите кои на ниво на апликација. Тоа не е забавно. Значи она што ние сакаме да одиме? Ние сакаме да одиме DynamoDB, целосно успеа, Зачувување на податоци NoSQL, обезбедување на автопат. Ние ги користиме на средното индекси. Тоа е во основа на HTTP API и вклучува поддршка документ. Значи, вие не мора да се грижите во врска со кој било од дека партиционирање. Ние го прават тоа сите за вас. Па сега, наместо тоа, ќе само напиши на масата. Ако на масата треба да биде поделен, што се случува зад сцената. Ќе бидете потполно изолирани од тоа како инвеститор. Па ајде да зборуваме за некои на употреба случаи дека ние се кандидира во во игри, заеднички игри сценарија, табла. Значи имаш корисници кои доаѓаат во, на BoardNames дека тие се на, оценките за овој корисник. Ние би можеле да се hashing на корисничка идентификација, а потоа имаме спектар на играта. Така што секој корисник сака да го види сите играта, тој свиреше и сите негови врвот резултат низ сите на играта. Значи, тоа е негов личен табла. 

Сега сакам да се оди и да сакам да get-- за да можам да се добијат овие лични leaderboards. Она што сакам да направите е да одам да купам на врвот резултат во сите корисници. Па, како да го направам тоа? Кога мојот рекорд е hashed на со userid, се движи на игра, и јас ќе одам да се оди напред и да се преструктуира, да креирате GSI, а јас ќе одам да се преструктурира тие податоци. 

Сега ќе одам да хаш На BoardName, што е играта. А јас ќе одам да се движат на врвот резултат. И сега сум создадена различни кофи. Јас сум со користење на иста маса, истите податоци објект. Но, јас сум создавање кофа која дава ме агрегација на врвот резултат од игра. 

И јас може да се пребарува таа маса да се добие таа информација. Па јас го поставите тој образец барањето до биде поддржана од средно индекс. Сега тие можат да бидат подредени по BoardName и сортирани по TopScore зависност. За да можете да видите, ова се видови на употреба случаи ќе го добиете во игри. Друга добра употреба случај ќе го добиеме во игри е награди и кој ја освои наградата. И ова е одлична употреба случај каде што ние го нарекуваме редок индекси. Редок индекси се способност да се генерира индекс, кој не мора да содржи секоја точка на маса. И зошто не? Бидејќи атрибут и тоа е се индексирани не постои на секој елемент. 

Значи во овој конкретен користете случај, сакам да кажам дека, знаеш што, јас ќе одам да создаде атрибут наречен награда. А јас ќе одам да им даде на секој корисник кој има награда која атрибут. Корисниците кои немаат награди се нема да има кој атрибут. Па кога ќе се создаде индекс, само корисници кој се случува да се покаже во индексот се оние кои, всушност, имаат освоено награди. Значи, тоа е одличен начин да се биде во можност да се создаде филтрирани индекси кои се многу, многу селективна кои не се мора да индекс на целата маса. 

Значи, ние сме добивање на ниско на време тука. Одам да се оди напред и да го прескокнете излезе и да го прескокнете овој случај. Зборува малку about-- 

ПУБЛИКАТА: Може ли да прашам едно кратко прашање? Една од нив е да напише тешки? RICK Houlihan: Што е тоа? ПУБЛИКАТА: Напиши тешки. RICK Houlihan: Напиши тешки. Дај да видам. 

ПУБЛИКАТА: Или е тоа што не нешто може да се само глас во прашање на секунди? RICK Houlihan: Ние одиме преку сценарио на гласање. Тоа не е толку лошо. Дали ви момци имаат неколку минути? ВО РЕД. 

Па ние ќе зборуваме за гласање. Толку реално време на гласањето, имаме барања за гласање. Барања се дека ние им овозможи секој човек да се гласа само еднаш. Сакаме никој да не биде во можност да го промени својот глас. Сакаме агрегација во реално време и анализатор за демографија дека ние ќе треба да биде прикажува на корисниците на страницата. 

Мислам на ова сценарио. Ние работиме многу на реалноста ТВ емисии, каде што тие се прават овие точниот вид на работи. Па може да се мисли на сценариото, имаме милиони и милиони тинејџерки таму со нивните мобилни телефони и гласање, и гласање, и гласање за кој тие се најде дека се најмногу популарни. Значи овие се некои од барања ние снема. 

И така прв преземе во решавање на овој проблем ќе биде да се изгради многу едноставна примена. Па имам овој стан. Имам некои гласачи таму. Тие доаѓаат во, тие хит стан на гласање. Имам некои суровини гласови маса Јас само ќе шутнат тие гласови во. Ќе има некои агрегат гласови маса што Ќе дадам аналитика и демографијата, и ние ќе се стави сето тоа во таму. 

И ова е одлично. Животот е добар. Животот е добро додека не дознаеме што секогаш има само еден или два луѓе кои се популарни на избори. Има само една или две работи дека луѓето навистина се грижат. А ако се гласаат, скала, одеднаш сум ќе се ковале ѓаволите, надвор од Двајцата кандидати, еден или двајца кандидати. А многу ограничен број на предмети луѓе се најде да биде популарен. 

Ова не е добар дизајн шема. Ова е всушност многу лош дизајн шема затоа што тоа создава токму она што го зборуваше за која беше топла клучеви. Топла клучеви се нешто што не ми се допаѓа. 

Па, како да го надминете тоа? И навистина, на начин да се поправи ова е со преземање на оние кандидат кофи и за секој кандидат што го имаме, ние ќе треба да се додаде на случаен вредност, нешто што ние знаеме, случајни вредност помеѓу еден и 100, меѓу 100 и 1.000, или меѓу еден и 1.000, меѓутоа многу случајни вредности што сакате да го додавај кон крајот на тој кандидат. 

И она што сум навистина направи тогаш? Ако јас сум со користење на проект како кандидат кофата агрегат гласови, ако јас додадов случаен број на крајот на тоа, Јас направивме сега 10 корпи, од кои еден сто корпи, илјада кофи дека јас сум агрегирање гласови во пречник. 

Па имам милиони, и милиони, и милиони на рекорди кои доаѓаат во за овие кандидати, јас сум сега се шири тие гласови низ A_1 Кандидат преку A_100 кандидат, бидејќи секој пат гласање доаѓа во, Јас сум во генерирање на случајни вредност од еден до 100. Јас сум тоа tacking кон крајот на Кандидатот на тоа лице да гласаат за. Јас сум тоа фрлање во кои кофа. 

Сега на задната страна, знам што ја добив стотина кофи. Па кога ќе сакаат да одат напред и агрегат од гласовите, Јас го прочитав од сите оние кофи. Па јас одиме напред и да го додадете. И тогаш јас растера соберат каде да одам и да го каже еј, знаеш што, овој клуч кандидатот простори е над сто кофи. Одам да се соберат сите гласови од оние сто кофи. Одам да се агрегираат нив и јас ќе одам да се каже, Кандидат за сега има Вкупниот пребројувањето на x. 

Сега и запишување пребарување и пребарување на читање се убаво дистрибуирани затоа што јас пишувам низ и го читам на стотина клучеви. Јас не пишувам и читање преку еден клуч. Па тоа е одлична шема. 

Ова е, всушност, веројатно, еден од најважните дизајн шеми за обем во NoSQL. Ќе го видите овој тип на дизајн шема во секој вкус. MongoDB, DynamoDB, тоа не го прави тоа прашање, сите ние треба да го направите тоа. Бидејќи кога си имаш работа со оние огромни колонии, ќе мора да дознаам начин да се ги шират низ кофи. Така што ова е начинот на кој ќе го направите тоа. Добро, така што што го прави во моментов е ти си на тргување надвор прочитани трошоците за запишување приспособливост. Цената на мојот прочитате е малку посложен и морам да одам читаат од сто корпи наместо една. Но, јас сум во можност да пишувам. И мојот автопат, моето пишување пропусната моќ е неверојатна. Па тоа обично е важна техника за скалирање DynamoDB, или било која база на податоци NoSQL за тоа прашање. Па ние сфатиле како да ја скала. И ние сфатиле како да се елиминирање на нашата топла клучеви. И тоа е фантастично. И добивме овој убав систем. И тоа е ни даде многу коректен гласање бидејќи имаме рекорд гласање де-будала. Тоа е вградено во DynamoDB. Ние разговаравме за условен права. 

Кога еден гласач влегува внатре, го става додатокот на маса, тие вметнете со своите гласачите проект, ако тие се обидуваат да се вметне уште еден глас, Правам условно запишување. Велат дека само ја напишам оваа ако ова не постои. Па штом ќе видам дека тоа гласање хит на маса, никој друг не ќе биде можност да се стави на гласање во. И тоа е фантастично. И ние ја зголемува нашиот кандидат шалтери. И ние сме прави нашето демографијата и сето тоа. Но, она што се случува ако ми апликација паѓа во текот? Сега одеднаш гласови доаѓаат во, и јас не знам дали тие се добива преработени во мојата анализа и демографијата веќе. И кога апликацијата се враќа нагоре, како по ѓаволите, да знам што има гласови обработени и каде да почнам? 

Па ова е вистински проблем кога ќе се да почне да се погледне на овој вид на сценарио. И како да се реши тоа? Ние тоа го реши со тоа што го јавете DynamoDB струи. Потоци е наредено време и поделен најавите промена на секој пристап на маса, секој се пишува пристап до табелата. Сите податоци кои се напишани на табелата се појавува на потокот. 

Тоа е во основа 24 часа чекање. Предмети хит на поток, тие живеат за 24 часа. Тие може да се прочита повеќе пати. Гарантирано да бидат испорачани само еднаш да се поток, може да се чита n број на пати. Па сепак многу процеси што сакате да го консумираат тие податоци, можете да го консумираат. Таа ќе се појави секој ажурирање. Секој пишуваат само ќе се појавуваат еднаш на потокот. Значи, вие не мора да се грижите за обработка на неа двапати од истиот процес. 

Тоа е строго нареди по ставка. Кога велиме време нареди и поделен, ќе видите една партиција на потокот. Ќе видите предмети, новости во ред. Ние не се гарантираат на реката што сте случува да се добие секоја трансакција во редот низ предмети. 

Па потоци се idempotent. Дали сите ние знаеме што значи idempotent? Idempotent значи дека може да го направи тоа над, и одново и одново. Резултатот ќе биде ист. 

Потоци се idempotent, но тие мора да бидат игра од почетна точка, каде и да одберете, за да на крајот, или пак тие не ќе резултира во исти вредности. 

Истото со MongoDB. MongoDB има конструкт тие го нарекуваат oplog. Тоа е истата конструкција. Многу NoSQL бази на податоци имаат оваа конструкција. Тие го користат за да се прават работите како репликација, која е токму она што го правиме со потоци. ПУБЛИКАТА: Можеби еретичкото прашање, но зборува за апликации прави надолу така натаму. Потоци се загарантирани за да никогаш не можел да тргне надолу? RICK Houlihan: Да, потоци се загарантирани за да никогаш не се оди надолу. Ние ги раководиме на инфраструктурата зад себе. потоци автоматски распоредат во нивните авто скалирање група. Ќе одиме преку малку малку за она што се случува. 

Јас не треба да се каже дека тие не се гарантирано да не оди надолу. Елементите се загарантирани за да се појави во потокот. И струјата ќе бидат достапни. Значи она што се спушта или се враќа нагоре, што се случува под. Covers-- тоа е во ред. Добро, па ќе го добиете различни типови на поглед надвор од екранот. Типови на ставот дека е важно да се биде програмер обично се, што беше тоа? Јас добие стариот изглед. Кога ажурирање хитови на маса, тоа ќе им помогнам на стариот поглед на струја така што податоците може да се архивира, или промена контрола, идентификација промена, промена управување. 

Новиот имиџ, она што е сега, по ажурирање, тоа е уште еден тип на гледање може да се добијат. Може да се добијат и на старите и нови слики. Можеби и јас ги сакам и двете. Сакам да видам што е тоа. Сакам да видам што е тоа да се промени. 

Имам тип на усогласеност на процесот што тече. Тоа треба да се потврди дека А кога ќе се промени, дека тие се во рамките на одредени граници или на одредени параметри. 

А потоа можеби и јас само треба да знаат што се сменило. Не ми е гајле што објектот се промени. Јас не треба да треба да знаете она атрибути променет. Јас само треба да се знае дека предметите се допре. Значи овие се видови на погледи дека ќе се симне на струја и можете да комуницирате со. 

Апликацијата која троши струја, ова е вид на начинот на кој тоа функционира. DynamoDB клиентот побара да се им помогнам на податоци во табели. Потоци се распореди на она што го нарекуваме распарчени. Распарчени се намалени независно од табелата. Тие не се редат во целост на партиции на вашата маса. И причината зошто е бидејќи тие се редат на капацитет, сегашната капацитет на табелата. 

Тие се распоредат во нивните сопствена скалирање група авто, и тие почнуваат да излезе надвор во зависност за тоа колку пишува се доаѓа, колку reads-- навистина тоа е пишува. Нема reads-- но како многу пишува се доаѓа. 

А потоа и на задната страна крајот, имаме она што го свика KCl, или Kinesis клиент библиотека. Кинеза е проток на податоци, технологија на обработка од Амазон. И потоците се гради на тоа. 

Така да користите KCL овозможено апликација за читање на потокот. На Kinesis клиент библиотека, всушност, управува со работниците за вас. И тоа, исто така, не некои интересни работи. Тоа ќе се создаде некои табели нагоре во вашиот DynamoDB tablespace да ги пратите на кои предмети се обработени. Па на овој начин, ако тоа паѓа назад, ако тоа паѓа во текот и доаѓа и добива застана назад, тоа може да се утврди каде тоа беше во обработка на потокот. 

Тоа е многу важно кога зборуваме за репликација. Јас треба да се знае што податоците беше обработена и кои податоци се уште да се обработи. Така библиотеката KCL за потоци ќе ви даде многу на таа функција. Тоа се грижи за сите домаќинство. Тоа стои работник за секој фрагмент. Тоа создава административните маса за секој фрагмент, на секој работник. И како оние работници пожар, тие се задржи оние маси па да се разбере овој албум беше прочитана и обработени. А потоа и на тој начин, ако процесот умира и се враќа на интернет, тоа може да продолжи таму каде што соблече. 

Па ние го користите овој за крос-регионот репликација. А многу од корисниците имаат потреба да се се движи на податоци или делови од нивните податоци табели околу кон различни региони. Постојат девет региони низ целиот свет. Така може да има need-- јас би можеле да имаат корисниците во Азија, на корисниците во источниот брег на Соединетите Американски Држави. Тие имаат различни податоци кои треба да биде локално дистрибуирани. А можеби и лета од корисникот Азија во текот на САД, и сакам да се реплицираат податоци со него. Значи, кога тој добива надвор од авионот, тој има добро искуство со својот мобилен стан. 

Можете да го користите на крстот-регион репликација библиотека за да го направите тоа. Во основа имаме предвидени две технологии. Еден е конзола апликацијата можеш застане на свој EC2 пример. Таа работи чисто репликација. А потоа ние ќе ви даде на библиотеката. Библиотеката можете да го користите да се изгради вашата апликација ако сакаат да прават луди работи со кои data-- филтер, реплицираат само дел од неа, ротирање на податоци, тоа се движи во различни маса, па натаму и така натаму. Значи, тоа е вид на нешто што личи тоа. 

DynamoDB струи може да биде обработени од страна на она што го нарекуваме Ламбда. Ги споменавме малку за настан управувано архитектури апликација. Ламбда е клучна компонента на тоа. Ламбда е кодот дека пожари на побарувачката во одговор на одреден настан. Еден од оние настани би можеле да бидат рекорд појавувајќи се на потокот. Ако рекорд појавува на поток, ние ќе го наречеме оваа функција Јава. Па, ова е JavaScript, и Ламбда поддржува Node.js, Јава, python, и наскоро ќе го поддржи други јазици, како и. И доволно да се каже, тоа е чиста код. пишуваат во Јава, можете дефинирате класата. Ќе им помогнам на МК JAR до во Ламбда. А потоа ќе се определи која класа да се јавите во одговор на кој настан. А потоа и на инфраструктурата Ламбда зад себе, кои ќе работат на тој код. 

Тој код може да процесира евиденција надвор од потокот. Тоа може да се направи нешто што сака со неа. Во овој пример, сите ние сме навистина прави се најавите атрибутите. Но ова е само код. Код може да направи ништо, нели? 

За да можете да го ротирате тие податоци. Можете да креирате Адаптирано поглед. Ако тоа е документ структура, можете да ја израмните структура. Можете да се создаде алтернативна индекси. На сите видови на работи што можете да направи со DynamoDB струи. 

И навистина, тоа е она што изгледа како тоа. Така да се добие оние надградби пристигнуваат. Тие доаѓаат надвор од стрингот. Тие се читаат од страна на функцијата Ламбда. Тие се ротирање на податоци и тоа се турка во изведени маси, известување на надворешните системи на промени, и туркање податоци во ElastiCache. 

Ние разговаравме за тоа како да се стави на кеш во предниот дел на базата на податоци за таа продажба сценарио. Па она што се случува ако се обновете точка опис? Па, ако имав Ламбда функција се извршува на таа табела, ако јас се ажурира точка опис, тоа ќе земам рекорд на поток, и тоа ќе се ажурира на ElastiCache пример со нови податоци. Па тоа е многу она што го правиме со Ламбда. Тоа е лепак код, конектори. А тоа всушност дава способноста да се започне и да се работи многу комплексни апликации без посветен сервер инфраструктурата, што е навистина кул. 

Значи, да се вратиме на нашата во реално време за архитектура гласање. Ова е нова и подобрена со нашите потоци и KCL от за апликација. Исто како и порано, не можеме да се справи со било обемот на изборите. Ни се допаѓа ова. Ние сме прави надвор растера собира во неколку кофи. Ние го добивме оптимистички заклучување случува. Можеме да ги одржуваме нашите гласачи од менување на нивните гласови. Тие само може да се гласа само еднаш. Ова е фантастично. Толеранција во реално време вина, скалабилни агрегација сега. Ако нешто паѓа над, тоа знае каде да се рестартира кога таа се враќа, бидејќи ние сме со користење на KCL стан. А потоа ние исто така може да го користат KCL апликации да им помогнам на податоци од до црвено поместување за други стан анализатор, или користење на виткаат MapReduce да се кандидира во реално време стриминг агрегации исклучување на тие податоци. 

Значи ова се работи кои сме не се зборуваше за многу. Но, тие се дополнителни технологии кои доаѓаат да се носат кога сте во потрага во овие видови на ситуации. 

Добро, па тоа е за анализатор со DynamoDB струи. Може да се соберат де-будала податоци, направи на сите видови на убави нешта, агрегирани податоци во меморија, создаде оние дериват маси. Тоа е огромна употреба случај дека голем број на клиенти се вклучени со, земајќи вгнездени својства на оние JSON документи и создавање на дополнителни индекси. 

Ние сме на крајот. Ви благодариме што го носи со мене. Па ајде да зборуваме за референца архитектура. DynamoDB седи во средината на толку голем дел од инфраструктурата AWS. Во основа може да се кука до нешто што сакате. Апликации изградена со користење Динамо вклучуваат Ламбда, ElastiCache, CloudSearch, им помогнам на податоци надвор во виткаат MapReduce, увоз извоз од DynamoDB во S3, сите видови на работни процеси. Но можеби најдобриот нешто да се зборува за, и тоа е она што е навистина Интересно е кога ќе зборува за настанот управувано апликации. 

Ова е пример на интерен проект ние сме таму каде што сме, всушност, издаваштво да се соберат резултатите од анкетата. Така што во е-мејл врска дека ние испрати надвор, таму Ќе да биде малку линк велејќи клик тука за да се одговори на истражувањето. И кога едно лице кликне тој линк, што се случува е дека тие ги повлечат надолу на сигурно HTML форма анкета од S3. Не постои на серверот. Ова е само еден S3 објект. 

Таа форма доаѓа до, го товари во прелистувачот. Тоа е мора рбетот. Тоа е мора да вклучите комплекс дека тоа е водење. Па тоа е многу богата апликација трчање во прелистувачот на клиентот. Тие не знаат дека тие не се интеракција со back-end серверот. Во овој момент, тоа е за сите пребарувач. 

Тие ги објави резултатите за тоа што ние го нарекуваме Амазон API Портал. API Портал е едноставно веб API дека може да се дефинира и да се поврземе онака како што сакате. Во конкретниов случај, ние сме закопчан до Ламбда функции. 

Значи мојот пост операција е случува без сервер. Во основа тоа API Портал седи таму. Тоа ме чини ништо додека луѓето започнете да ја објавите за тоа, нели? Функцијата Ламбда само седи таму. И тоа ме чини ништо, додека не луѓето почнат да го удираат. Па можете да видите, како што обемот се зголемува, тоа е кога обвиненијата дојде. Јас не сум водење на серверот 7/24. 

Па јас се повлече форма слегува од кофата, и јас ја објавите преку API Портал во функција Ламбда. А потоа и на Ламбда функција, вели, знаеш што, Имам некои PIIs, некои лични информации во овие одговори. Добив коментари доаѓаат од корисниците. Јас имам е-мејл адреси. Јас имам кориснички имиња. 

Дозволете ми да се подели овој исклучи. Одам да се произведуваат некои метаподатоци исклучите овој запис. А јас ќе одам да им помогнам на метаподатоци во DynamoDB. И би можел да го криптирате сите податоци и да се поттикнат во DynamoDB ако сакам. Но, тоа е полесно за мене, во оваа користете случај, да се оди напред е да речеме, Одам да се поттикнат на необработени податоци во криптиран S3 кофа. Па јас го користам изградена во серверот S3 енкрипција и клуч за управување на Амазон Сервис, така што имам клучот што може да ротира на редовна интервал, и можам да го заштитат тоа PII податоци како дел од целиот овој тек на работа. 

Значи она што сум направил? Тукушто се распоредени во целина апликација, и немам серверот. Значи она што е настан управувано примена архитектура го прави тоа за вас. 

Сега, ако се размислува за употребата случај за this-- ние имаме други клиенти Зборувам да за ова точната архитектура кои работи феноменално големи кампањи, кои се се гледа во оваа и си одат, ох моја. Затоа што сега, тие можат да во основа го притисни таму, дозволиш таа кампања само да седат таму се додека не започна, а не мора да се грижите за смоква каков вид на инфраструктура ќе бидат таму за да го поддржат. А потоа веднаш штом дека кампањата е направено, тоа е како на инфраструктурата само веднаш си оди затоа што има навистина постои инфраструктура. Тоа е само кодот што седи на Ламбда. Тоа е само податоци кој седи во DynamoDB. Тоа е неверојатен начин да се изгради апликации. 

ПУБЛИКАТА: Значи тоа е повеќе ефемерни отколку што ќе биде ако тоа беше се чуваат на вистински сервер? 

RICK Houlihan: Апсолутно. Бидејќи тој сервер пример ќе мора да биде 7/24. Таа треба да биде на располагање за некој да се одговори. И погоди што? S3 е достапен 7/24. S3 секогаш одговара. И S3 е многу, многу добар во служејќи се објектите. Тие предмети може да е HTML датотеки, или Го вклучите Javascript-датотеки, или што и да сакате. Можете да го извршите многу богати веб апликации од S3 кофи, и луѓето го прават. 

И така тоа е идејата тука е да се извлечеш од патот ние се користат да се размислува за тоа. Сите ние се користат да се мисли во однос на сервери и домаќините. Тоа не е за тоа повеќе. Се работи за инфраструктура како код. Распоредување на код за да се облака и нека облак го кандидира за вас. И тоа е она AWS се обидува да го направи тоа. 

ПУБЛИКАТА: Значи вашиот злато кутија во средината на API Портал не е сервер-како, но наместо тоа е just-- 

RICK Houlihan: Можете да мислите тоа што на серверот фасада. Сето тоа е што е тоа ќе потрае некој HTTP побара и на сајтот на друг процес. Тоа е се што го прави тоа. И во овој случај, ние сме мапирање тоа до функција ламбда. Добро, па тоа е се што го добив. Ти благодарам многу. Го ценам тоа. Знам дека ние сакаме малку со текот на времето. И се надевам дека вие момци доби малку на информации дека може да се земе и денес. И јас се извинувам ако бев над некои од вашите глави, но има добар број на основните основни знаења што мислам дека е многу важна за вас. Па ви се заблагодарам за се има. [Аплауз] ПУБЛИКАТА: [Беззвучен] е кога велеа ти мораше да се оди преку работа од почеток до крај за да се добие право на вредности или истите вредности, како би вредности да се промени ако [Беззвучен]. 

RICK Houlihan: О, idempotent? Како ќе се менува на вредности? Па, затоа што ако јас не се кандидира тоа сè до крајот, тогаш јас не знам што се менува се направени во последната милја. Тоа нема да биде истите податоци како она што го видов. ПУБЛИКАТА: О, па вие само не добиле целиот влез. RICK Houlihan: Добро. Мора да се оди од почеток до крајот, а потоа тоа е ќе биде конзистентна држава. Кул. 

ПУБЛИКАТА: Па ти ни покажа DynamoDB може да се направи документ или вредноста на клучот. И си поминале многу време на клучните вредност со хаш и начините да го флип наоколу. Кога ќе ги гледа тие маси, е во тоа што оставајќи го зад себе пристап документ? 

RICK Houlihan: Јас не би велат дека тоа оставајќи го зад себе. 

ПУБЛИКАТА: Тие биле одделени од the-- 

RICK Houlihan: Со документот пристап, типот на документот во DynamoDB е само мислам на тоа како уште еден атрибут. Тоа е особина која содржи хиерархиска структура на податоци. А потоа и во прашања, можете да го користите на својствата на оние предмети за користење на објектно нотација. За да можам да ги филтрираат на вгнездените сопственост на документот JSON. ПУБЛИКАТА: Значи секое време јас направи пристап документ, Јас вид на може да пристигне во tabular-- ПУБЛИКАТА: Апсолутно. ПУБЛИКАТА: --indexes и работи едноставно зборуваше. RICK Houlihan: Да, индекси и сето тоа, кога сакате да индекс својства на JSON, на начинот на кој ние ќе мора да го направите тоа е ако внесуваш JSON објект или документ во Динамо, ќе се користи струи. Потоци ќе прочита влез. Сакате да се добие дека JSON забелешки и ќе речеш во ред, што е имотот што сакам да индексира? 

Можете да креирате Адаптирано табелата. Сега тоа е начинот на кој таа работи во моментов. Ние не ви дозволуваат да индексира директно тие имоти. 

ПУБЛИКАТА: Tabularizing вашите документи. 

RICK Houlihan: Точно, изедначување тоа, тоа tabularizing, точно. Тоа е она што го направи со неа. 

ПУБЛИКАТА: Ви благодарам. 

RICK Houlihan: Да, апсолутно, ви благодарам. ПУБЛИКАТА: Значи тоа е вид на Mongo исполнува Redis classifers. 

RICK Houlihan: Да, тоа е многу слично. Тоа е добар опис за тоа. Кул.