[Мусиц плаиинг] Рицк Хоулихан: У реду. Zdravo svima. Моје име је Рик Хоулихан. Ја сам старији главни Солутионс Арцхитецт на АВС. Ја се фокусирати на носкл и ДинамоДБ технологије. Овде сам данас да разговарам са ви мало о томе. 

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

Али током година, радио сам за пар предузећа сте вероватно никад чули. Али ја сам саставио листу техничких достигнућа, претпостављам да ћеш рећи. Имам осам патената у Цлоуд системе виртуелизација, микропроцесор дизајн, комплекс за прераду догађај, и другим областима као добро. 

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

Ми ћемо ући у неке од су ДинамоДБ интерналс. ДинамоДБ је АВС немају укуса. То је потпуно управља и домаћин НоСКЛ решење. И причаћемо мало о табеле структура, Апис, типови података, индекси, и неких интерних те ДинамоДБ технологије. Ми ћемо ући у неки од дизајна обрасци и најбоље праксе. Причаћемо о томе како си користе ову технологију за неке данашњих апликација. А онда ћемо разговарати мало о еволуцији или појаве нове парадигме у програмирању тзв евент-дривен апликације и како ДинамоДБ игра у исто тако добро. И ми ћемо вам оставити мало референтна архитектура дискусија тако да можемо говорити о неким начине на које можете користити ДинамоДБ. 

Дакле, прво медјувремену- је ово питање Чујем доста је, шта је база података. Много људи мисле они знају шта је база података. Ако вам Гоогле видећете ово. То је Структуриран скуп података одржана у компјутеру, посебно оног који је доступан на различите начине. Претпостављам да је то добра дефиниција модерне базе података. Али ја се не свиђа, јер то подразумева неколико ствари. То подразумева структуру. А то значи да је на рачунару. И база података није Увек постоје на рачунарима. Базе података у ствари постојала на много начина. 

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

Сада, ако питам просек програмер шта је данас база података, то је одговор да добијем. Негде сам да држимо ствари. Jel tako? И то је истина. Али то је жалосно. Зато што је база података је заиста темељ модерне апликације. То је темељ сваког апликација. А како сте изградити да база података, како се структуира да се подаци ће диктирати како је Апликација обавља као што скала. 

Дакле, много мог посла данас се бави оним што Када се деси програмере Користим ову приступ и суочавања са последицама једне апликације која сада скалирање изван оригинал намера и патња од лошег дизајна. Дакле, надамо се, када вас отићи данас, ти ћеш има неколико алата у Ваш појас која ће вас држати од доношења те исте грешке. U redu. Дакле, хајде да причамо о мало временски рок за базе података технологије. Мислим Прочитао сам чланак не тако давно и то је нешто на линес-- То је веома поетски исказ. Писало је историја Обрада података је пуно високих ватермаркс података изобиљу. OK. Сада, претпостављам да је то нека врста истина. Али ја заиста погледамо је као историја заправо испуњен са водени жиг притиска података. Због стопе података гутање никада не иде доле. То само иде горе. 

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

Дакле, када погледамо Први база података, ова је онај који је између наших ушију. Сви смо рођени са њим. То је лепо база података. Има високу доступност. То је увек. Увек можете га добити. 

Али то је један корисник. Не могу да поделим своје мисли са вама. Не могу да моје мисли када их желите. И њихова абилитии није тако добро. Заборављамо ствари. С времена на време, један од нас лишће и помера на другу постојања и губимо све који је био у тој бази података. Дакле, то није све то добро. 

И ово је добро током времена када смо се вратили у дан кад смо заиста потребно да знам је где ћемо да идемо сутра или где смо се окупили најбољу храну. Али, као што смо почели да расту као цивилизација и влада је почела да дође у постојање, и предузећа почела да се развија, смо почели да увиђамо треба мало више од онога што могли бисмо да ставимо у нашој глави. U redu? 

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

И то заправо догодило у 1880. Jel tako? У САД пописа 1880. Ово је заиста где је преломна указују модерну обраду података. Ово је тачка на која количина података који је прикупљају од стране Америчка влада је до тога где је требало осам година да процесуирају. 

Сада, осам година-- као знате, попис вози сваких 10 година- тако да је очигледно да је време да Имам попис из 1890, количина података које је требало да се обрађују влада је ће да прелази 10 година то је то би се да лансирао нову пописа. То је био проблем. 

Дакле, момак по имену Херман Холлеритх је дошао и он је измислио јединица рекордну пунцх картица, читач картица ударац, ударац картица табулатор, а уређена група механизми за ову технологију. И то компанија која је формирана на време, заједно са неколико других, заправо постао један од стубова мала фирма ми данас знамо под називом ИБМ. 

Дакле, ИБМ-првобитно био у пословна база података. И то је оно што су урадили. Јесу обраду података. 

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

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

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

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

Али постоје ограничења у томе како смо приступ подацима на основу тога колико је сачувана. И то је био проблем улазећи у '50 -их. Опет, можемо почети да видимо да као и ми развијају нове технологије за обраду подаци, зар не, то отвара врата за нова решења, за нове програме, ново апликације за тих података. И заиста, управљање можда био разлог тога смо развили неки од ових система. Али убрзо постала бизнис возач иза еволуције модерне базе података и модерни систем датотека. 

Дакле, следећа ствар која дошао је током '50 -их је систем датотека и Развој Рандом Аццесс складиштења. То је било дивно. Сада, све одједном, можемо ставити наше филес било где на овим хард дискова и можемо приступити ове податке насумично. Можемо анализирати да информације из досијеа. И решио да сви на свету Проблеми са обрадом података. 

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

У '70 -их, најскупљи ресурс да је компјутер имао је складиште. Процесор је посматрати као фиксни трошак. Када сам купио кутију, ЦПУ ради неки посао. То ће бити окреће ли то је заправо ради или не. То је заиста потонуо трошкова. 

Али оно што ме је коштало као посао је за складиштење. Ако морам да купим још дискове следећу мјесец, то је реална цена коју сам платио. И то складиште је скупо. 

Сада смо Фаст Форвард 40 година а имамо други проблем. Цомпуте сада најскупљи ресурс. Складиште је јефтино. Мислим, можемо ићи било где на Облак и можемо пронаћи јефтини складиштење. Али оно што ја не могу наћи јефтин рачунарство. 

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

Али један од разлога и возач иза ово-ве говорио о притиску података. Притисак података је нешто који покреће иновације. И ако погледате изнад у последњих пет година, ово је графикон Вхат Тхе података оптерећење преко опште предузећу Изгледа да у последњих пет година. 

А опште правило ови даис-- ако идете Гоогле-- је 90% података који ми данас складишти, а то је остварене у последње две године. OK. Дакле, ово није тренд који је ново. То је тренд који је био Излазим за 100 година. Откако Херман Холлеритх развио пунцх картицу, смо изградњу складишта података и прикупљање података у феноменалним стопама. 

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

Ако посао у 2010. години имао терабајт података под управљањем, Данас то значи да су управљање 6,5 петабајта података. То је 6.500 пута више података. И знам то. Ја радим са овим бизниса сваки дан. Пре пет година, хтео да разговара са компанијама ко би разговарати са мном о томе шта је бол је да управља терабајта података. И они би причали са мном о томе како видимо да је ово вероватно ће да буде петабајт или два у року од неколико година. 

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

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

Сада, нећемо зауставити ово. Jel tako? Нећемо зауставити ово. Zašto? Зато што не можете знати све постоји знати у универзуму. И док смо били живи, кроз историју човека, ми смо увек возио знати више. 

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

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

Повратак у '70 -тих, опет, Диск је скупо. За доделу вежба за складиштење у предузећу је бескрајна. Znam. Ја га живео. Писао сам драјвере за складиштење Ентерприсед Суперсервер компанија назад у '90 -их. И на крају крајева је регали други низ складиште је нешто што десило сваки дан у предузећу. И то никада није престала. Виши складиштење густина, потражња за складиштење високе густине, и за ефикасније складиштење девицес-- то никад није престао. 

И НоСКЛ је велики технологија јер нормализује податке. То де дуплира податке. То ставља податке у структури која је агностик за сваког приступа обрасцу. Више апликација може да погоди да СКЛ база података, ради ад хоц упите, и добити податке у облику који су треба да обрадимо за своје оптерећења. То звучи фантастично. Али суштина је са било којом систем, ако је агностик у свему, то је оптимизован за ништа. OK? 

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

Ако је потребно да бисте добили већи СКЛ базу података или моћнији СКЛ база, Идем купити већи део гвожђа. OK? Радила сам са много купаца који су прошли кроз главне надоградње у свом СКЛ инфраструктуру само сазнати шест месеци касније, они ударају у зид опет. А одговор из Орацле или МССКЛ или неко други је добити већи кутију. Па пре или касније, не можете купити већи кутија, и то је прави проблем. Морамо да се заиста променити ствари. Па где то функционише? То добро ради за офлајн аналитика, ОЛАП типа оптерећења. И то је стварно где СКЛ припада. Сада, користи се и данас у многим онлајн трансакциони обрада тип апликације. И то ради сасвим добро у неки ниво искоришћености, али то једноставно не сцале начин на који НоСКЛ ради. И причаћемо мало мало о томе зашто је то. 

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

Али идеја је у томе да чувате Ваши подаци као ових инстантиатед ставовима. OK? Ви сцале хоризонтално. Jel tako? Ако треба да се повећа Величина мог носкл кластера, Не треба да добију већу кутију. Имам још једну кутију. И оне групишу заједно, и ја могу да Схард те податке. Причаћемо мало о шта схардинг је, да будемо у стању да смањи ту базу података на више физичких уређаја и уклоните баријеру која тражи ме да вертикално размери. 

Дакле, то је заиста направљен за онлајн обрада трансакција и обима. Постоји велика разлика Овде између извештавања, зар не? Извештавање, ја не знам да је Питања ћу да питам. Jel tako? Репортинг-- ако неко из мој маркетиншко одељење жели да само- колико од мојих клијената има ту особину која посебну Купио на овом даи-- не знам оно упита они ће питати. Зато морам да будем агностик. 

Сада, у онлајн трансакциони апликација, Знам шта питања питам. Сам направио апликацију за врло специфична ток рада. OK? Дакле, ако сам оптимизира податке похранити да подрже ту процес рада, то ће бити бржи. И зато НоСКЛ могу стварно убрзати испоруку од ових типова услуга. U redu. 

Тако ћемо да уђемо у мало теорије овде. И неки од вас, ваше очи Можда вратите мало. Али ја ћу покушати да остане као висок ниво колико могу. Дакле, ако сте у пројекту менаџмент, ту је конструкт назива троугао ограничења. OK. Троуглу ограничава диктату не можете имати све у време. Не можете имати своју питу и појести га превише. Дакле, у управљању пројектима, који троугао ограничења је можете имати јефтино, можете имати брзо, или можете имати је добро. Пицк два. Зато што не можете имати све три. Jel tako? OK. 

Тако сте чули за ово је много. То је троструко ограничење, троугао троструког ограничења, или гвожђе троугао офтентимес-- Када разговарате са пројектним менаџерима, они ће разговарати о томе. Сада, базе података има своје гвожђе троугао. И гвожђе троугао података је оно што зовемо ЦАП теорема. OK? 

Теорема ЦАП диктира како раде базе података под веома специфичном стању. И причаћемо о шта је услов. Али три тачке троугла, да тако кажем, су Ц, доследност. OK? Дакле, у ЦАП, конзистентност значи да су сви клијенти који може приступити бази података ће увек имати веома у складу поглед података. Нико неће видети две различите ствари. OK? Ако видим базу података, Видим исто мишљење као мој партнер који види иста база података. То је доследност. 

Доступност значи да ако је база података на мрежи, ако може да се постигне, да сви клијенти ће увек бити у стању да читају и пишу. OK? Дакле, сваки клијент који може прочитати базу података ће увек бити у могућности читања података и писање података. А ако је то случај, то је доступан систем. 

И трећа ствар је шта зовемо толеранцију партицију. OK? Толеранције Подела средстава да систем функционише добро упркос физичке мреже преграде између чворова. OK? Дакле, чворови у кластеру не могу разговарају једни с другима, шта се дешава? U redu. 

Дакле, релационе базе података цхоосе-- можете одабрати два од ових. OK. Дакле, релационе базе података одаберите да буде у складу и на располагању. Ако је партиција се догађа између су ДатаНодес у складишту података, база сруши. Jel tako? То само иде доле. OK. 

И то је разлог зашто они имају да расте са већим кутијама. Jel tako? Зато што је не-- обично, кластер база података, нема баш много од њих да раде на тај начин. Али већина базе података сцале вертикално унутар једне кутији. Јер, они треба да буду доследан и доступни. Да подела требало да се убризгава, онда би морао да направи избор. Морате да направи избор између бити доследан и доступни. 

И то је оно што НоСКЛ базе података ради. U redu. Дакле, НоСКЛ база података је, долази у две варијанте. Ми добро бих--, то долази у многим укуса, али долази са два основна цхарацтеристицс-- шта што бисмо назвали ЦП базу података, или доследан и подела толеранција систем. Ови момци направити избор када чворови губе контакт једни са другима, нећемо дозволити људи пишу више. OK? 

Док се то подела је уклоњена, приступ писања је блокиран. То значи да они нису доступне. Они су доследни. Када видимо да партиција се убризгати, сада смо доследни, јер нећемо да дозволи промену података о два стране поделе самостално један од другога. Мораћемо да поново успостави комуникацију пре него што било који упдате се подаци дозвољено. OK? 

Следећа укус би бити АП систем, или на располагању и расподељена толеранција систем. Ови момци не занима. Jel tako? Било чвор који постаје врите, ми ћемо га узети. Тако сам реплицира своју податке на више чворова. Те тачке се клијент, клијент долази у, каже, ја ћу написати неке податке. Чвор каже, нема проблема. Чвор поред њега добија отписа на истом запису, он ће рећи никакав проблем. Негде назад на крају леђа, да су подаци ће да понове. И онда це неко да схвати, Ух-ох, они систем ће схватити, ух-ох, дошло је до упдате за обе стране. Šta da radimo? И шта онда они раде је они раде нешто што им омогућава да реше ту државу података. И причаћемо о да ће у наредном графикону. 

Ствар да истакнем овде. И нећу превише добити много у ово, јер ово улази у дубоку теорију података. Али постоји трансакцијски оквир који Ради у релационом систему који омогућава да безбедно направи ажурирања на више лица у бази. И да ли ће доћи до те исправке одједном или се уопште не. И ово се зове АЦИД трансакције. OK? 

Ацид нам даје атомски, доследност, изолација, и трајност. OK? То значи Атомиц, трансакције, све моје исправке или деси или не. Доследност значи да База података ће увек бити доведен у доследан држава након ажурирања. Никада нећу напустити базе података у лоше стање након примене ан упдате. OK? 

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

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

Али ако кажем додати 1 на ту вредност, и два трансакције долазе у и покушати да то уради, једна је тамо да стигнемо први а други је ће добити тамо после. Дакле, на крају, додао сам два. Видиш шта мислим? OK. 

Трајност је прилично једноставно. Када је трансакција Признаје, то је Биће ту још ако је систем сруши. Када се систем опорави, да трансакција која је починила заправо ће бити тамо. Дакле, то је гаранције киселине трансакција. То су лепо гаранције да на бази података, али они долазе на тој цени. Jel tako? 

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

Са друге стране имамо оно што се зове БАСЕ технологију. А ово су твоји НоСКЛ базе података. U redu. Дакле, имамо ЦП, АП базама података. А ово су оно што у суштини зову доступно, мека држава, коначно доследан. OK? 

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

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

Сада, ЦАП теорема стварно игра само у једном стању. Тај услов је када се то деси. Зато, кад год је то ради у нормал, нема поделе, Све је доследан и доступни. Само бринути о ЦАП када имамо ту партицију. Дакле, то су ретки. Али како систем реагује када они се јављају диктирају шта тип система бавимо. 

Дакле, хајде да погледамо шта која личи на АП системе. OK? АП системи долазе у две верзије. Они долазе у укуса која је Мастер Мастер, 100%, увек на располагању. И они долазе у друга укуса, који каже: знате шта, ја ћу се бринути о овом партиција ствари када се стварна подела јавља. У супротном, постоји ће бити примарни чворови који ће трајати права. OK? 

Дакле, ако тако нешто Касандри. Касандра ће бити господар господар, да сам ја пишем на било који чвор. Дакле, шта се дешава? Дакле, имам објекат у граду база података која постоји на два чвора. Назовимо тај објекат С. Дакле, имамо државу за С. Имамо неке операције о С који су у току. Касандра ме омогућава пишите више чворова. Рецимо ја добијем писати за с на два чвора. Па, шта завршава се догађа је ми то зовемо дељење догађаја. Ту не може бити физичка мрежа партиција. Али због дизајна система, то је заправо подели чим што добијем писати по два чвора. То ме не тера да напиши све преко једног чвора. Ја пишем на два чвора. OK? 

Тако да сада имам две државе. OK? Шта ће се десити је пре или касније, ту ће бити репликација догађај. Ту ће бити оно што смо назива партиција за опоравак, који је место где ова два државе врати заједно и ту ће бити алгоритам који ради унутар базе података, одлучује шта да ради. OK? По дефаулту, Последња обнова победи у већини АП система. Дакле, обично постоји Дефаулт алгоритам, шта зову цаллбацк функција, нешто што ће се звати када се ово стање се открије да изврши неку логику да реши тај конфликт. OK? Уобичајени повратни позив и затезна Ресолвер у већини АП базама података је, знаш шта, тиместамп победи. То је био последњи ажурирање. Ја ћу ставити ту исправку тамо. Ја могу да бацим ово рекорд који сам бачено са у лог опоравак тако да корисник може вратити касније и рећи, хеј, дошло је до судара. Šta se desilo? И заиста можете бацити евиденцију сви судари и роллбацкс и види шта се дешава. 

Сада, као корисник, можете такође укључује логику у том цаллбацк. Дакле, можете да промените који повратни операција. Можете рећи, хеј, ја желим да побољшају ове податке. И желим да покушам да спајање та два записа. Али то је на вама. База података не зна како да то по дефаулту. Већина време, Једина ствар база података зна како да то урадите је рећи, ово је био последњи рекорд. То је онај који ће победити, и то је вредност ћу ставити. Након тог партитион рецовери и репликација се јавља, имамо своју државу, која је сада главни С, који је стапања држава свих тих објеката. Дакле АП системи имају ово. ЦП системи не треба да бринете о томе. Јер, чим дође партиција у игру, они су само престати са узимањем пише. OK? Тако да је врло лако се баве бити у складу када не прихватају било какве исправке. То је са ЦП системи раде. U redu. 

Дакле, хајде да разговарамо мало мало о обрасцима приступ. Када говоримо о носкл, то је све о приступном обрасцу. Сада, СКЛ је ад хоц упита. То је релациона продавница. Ми не морамо да бринемо о приступном обрасцу. Пишем веома комплексан упит. То иде и добија податке. То је оно што ово изгледа као, нормализација. 

Дакле, у овом конкретном структури, гледамо каталог са производима. Имам друге врсте производа. Имам књиге. Имам албуме. Имам видео. Однос између производа и било који од ових књига, албума, и видео табеле је 1: 1. U redu? Имам ИД производа, и да одговара ИД у књизи, албум, или видео. OK? То је 1: 1 однос преко оних столова. 

Сада, све што су боокс-- имам је корен својства. Nema problema. Odlično. Један-на-један однос, имам све подаци Морам да опишем ту књигу. Албумс-- албума имају трагове. То је оно што ми зовемо једни многе. Сваки албум може да има много песама. Дакле, за сваку песму на албум, могао сам још један рекорд у овој табели деце. Тако да сам створи један рекорд у своје албуме табели. Ја стварам вишеструке записе у табели трацкс. Један-на-многи однос. 

Овај однос је шта зовемо многи до многих. OK? Видиш да актери буду у многим филмовима, много видео. Дакле, оно што ми радимо јесте да овај пут мапирање сто између оних који се само мапс глумац ИД на видео ИД. Сада могу створити упита јоинс Видео кроз глумац видео то актера, и то ми даје леп списак све филмове и сви актери који су били у том филму. 

OK. Дакле, идемо. Један-на-један је највишег нивоа odnos; један-на-многе, албума на стазе; многи до многих. То су три највишег нивоа односи у једној бази података. Ако знате како су односи раде заједно, онда знате много о већ бази података. Тако НоСКЛ ради мало другачије. Размислимо о томе за тренутак шта је Изгледа да да одем све моје производе. 

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

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

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

To je kul. Ја сам дедуплицатед све моје глумце, и ја одржава своје асоцијације У овом мапирања табели. Међутим, добијање података престане да буде скупо. Шаљем ЦПУ целом систему спајања ових података заједно структуре да би могли да повуку те податке назад. 

Па како да се око тога? У носкл се ради о агрегацију, не нормализација. Дакле, желимо да кажемо желимо да подржава приступни образац. Ако приступног обрасца на апликације, Морам да се све моје производе. Ставимо све производе у једној табели. Ако сам ставио све производе у једној табели, Само да одаберете све производе од тог стола и ја сам га све. Па како то да урадим? Па у носкл нема Структура на табели. Причаћемо мало о како то функционише у Динамо ДБ. Али ви немате исти атрибути и исте особине у сваком реду, у сваком појединачном ставка, као што се ради у СКЛ табели. И шта ме ово омогућава да урадите је да много тога и дај ми велику флексибилност. У овом конкретном случају, има мој производ документацију. И у овом конкретном Пример, све је документ у табели Производи. А производ за књигу мигхт имају тип ИД, која обухвата књигу. И апликација би пребацили на тај ИД. 

На примене Тиер, идем да кажем Ох, шта тип рекорд је ово? Ох, то је књига рекорд. Књига евиденције имају ове особине. Дозволите ми да направите књигу објекат. Зато ћу да испуните Књига објекат са овом тачком. Следећа тачка долази и каже, шта је ово предмет? Па ова ставка је албум. Ох, имам потпуно другачија обрада рутина за то, јер је албум. Видиш шта мислим? 

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

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

Унутар овог документа за албуме, Видим низове нумера. Ове стазе сада бецоме-- је у суштини ово дете сто је постоји овде у овој структури. Дакле, можете да урадите ово ДинамоДБ. То можете да урадите у МонгоДБ. То можете урадити у било ком носкл бази података. Креирајте ове врсте хијерархијске структуре података које вам омогућавају да преузимате податке врло брзо, јер сада не морају да одговарају. Када сам убаците ред у Трацкс сто, или ред у табелу Албумс, Морам да се прилагоди тој шеми. Морам да има атрибут или имовина која је дефинисана на том столу. Сваки од њих, када сам убаците тај ред. То није случај у носкл. 

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

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

А смешно ствар о томе је, некако линија до које зовемо Технологија Усвајање Цурве. Дакле, оно што се дешава је да имамо нека технологија окидач. У случају база података, то је притисак података. Разговарали смо о Хигх Ватер тачке притиска података током времена. Када се притисак подаци погоди одређена поента, то је технологија окидач. 

Постаје превише скупо. Потребно је предуго за обраду података. Треба нам нешто боље. Добијате иноваторе тамо ради око, покушава да сазна шта је решење. Шта је нова идеја? 

Који је следећи најбољи начин да се ово? И они долазе са нечим. А људи са правим болом, момци у крвавом ивици, они ће скочити на себи, јер им је потребан одговор. Сада оно неизбежно и хаппенс-- то се дешава управо сада у носкл. Видим то све време. 

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

Али то је оно што је дешава са носкл данас. Ако сте ходати у већини продавница, они покушавају да буду НоСКЛ продавнице. Оно што они раде је они користе носкл, и они га учитава пуно релациону шеме. Јер то је како они дизајн базе података. И они се питају, зашто је не обавља добро? Човече, ово смрди. Морао сам да се одржи све моје придружује у-- то је као, не, не. Одржавајте придружује? Зашто се придружити податке? Не придружити податке у носкл. Ви га агрегата. 

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

Они урадио исту ствар када је релационе базе података су измислили, и они су замене система датотека. Они су покушали да изграде системе датотека са релационим базама података јер то је оно што људи разумели. Није успело. Дакле, разумевање најбоље праксе технологије радите са је огромна. Veoma važna. 

Тако да ћемо ући у ДинамоДБ. ДинамоДБ је АВС је потпуно успео носкл платформу. Шта потпуно управља значи? То значи да не треба да Заиста бринете. 

Дођеш у, реци нас, ми треба сто. Потребно је оволико капацитета. Ви притиснете дугме, а ми одредба сва инфраструктура иза сцене. Сада када је огроман. 

Јер, кад причаш о скалирање базу података, НоСКЛ података кластера на скала, текући петабајта, руннинг милионе трансакције у секунди, те ствари нису мале кластера. Говоримо хиљаде случајева. Управљање хиљаде случајева, чак виртуелни инстанце, је прави бол у задњици. Мислим, размишљам о сваки пут када Оперативни систем патцх излази или нова верзија базе података. Šta to znači теби оперативно? То значи да имаш 1.200 сервери који треба да буде ажуриран. Сада чак и са аутоматизације, који може трајати дуго. То може изазвати много оперативне главобоље, јер ја можда има услуге доле. 

Као што сам упдате ове базе података, ја могао да уради блуе греен распоређивање где сам распореди и надоградњу пола моје чворови, а затим надоградите другу половину. Узми ове доле. Дакле, управљање инфраструктуром скала је изузетно болно. И АВС се тај бол од тога. И НоСКЛ базе података могу бити изузетно болно због начина на који су скале. 

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

Ми подржавамо кључни документ вредности. Сада нисмо ишли превише чипа на другом графикону. Има доста другачији укуси носкл. Они су све врсте добијања мунгед заједно на овом тренутку. Можете погледати ДинамоДБ и рећи да, обоје смо документ и кључна вредност похранити ову тачку. И ви можете тврдити функције једног преко другог. За мене, доста тога је заиста шест једног пола туцета од другог. Сваки од ових технологија је фино технологија и фино решење. Не бих рекао да је боље или МонгоДБ горе него Цоуцх, затим Цассандра, онда Динамо, или обрнуто. Мислим, то су само опције. 

То је брз и то је у складу у сваком нивоу. Дакле, ово је једна од највећих бонуси сте добили са АВС. Са ДинамоДБ је способност да бисте добили ниску једну цифру милисекунди кашњења у било ком обиму. То је био циљ дизајна система. И ми имамо клијенте који раде милиони трансакција у секунди. 

Сада ћу проћи кроз неке од њих користе предмете за пар минута овде. Интегрисани приступ цонтрол-- имамо оно што зовемо Идентитет Приступ за управљање, или ИАМ. Она прожима сваки систем, сваки сервис који АВС нуди. ДинамоДБ није изузетак. Можете контролисати приступ на ДинамоДБ табеле. Широм све своје рачуне од АВС дефинисање улоге и дозволе приступа у ИАМ инфраструктуру. 

И то је кључни и саставни у оно што ми зовемо догађај Дривен програмирање. Ово је нова парадигма. 

ПУБЛИКА: Како је твоја стопа истина Позитивни версус лажно негативних на вашем систему контроле приступа? Рицк Хоулихан: Труе позитиви у односу на лажно негативних? ПУБЛИКА: враћа оно што треба се вратити? За разлику од времена на време она не врати кад је требало да потврди? 

Рицк Хоулихан: Нисам могао да вам кажем. Ако постоји било пропуста све што о томе, Ја нисам особа да питам да конкретно питање. Али то је добро питање. Ја бих био радознао да знам да сам, у ствари. 

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

Прва ствар урадићемо је причаћемо о табелама. Типови АПИ података за Динамо. И прва ствар коју ћете приметити када погледате ово, Ако сте упознати са било којим базу података, базе података су заиста две врсте АПИ Ја бих то назвао. Или два сета АПИ. Један од оних који ће бити административни АПИ. 

Оно што они брину о функције базе података. Подешавање мотор за складиштење, успостављање и додаје табеле. креирање базе података каталози и случајеви. Ово ствари-- у ДинамоДБ, ви имају веома кратке, кратке листе. 

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

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

Не треба да бринете о било ком од ових ствари. Ми све радимо за вас. Дакле, то је огромна количина над главом то је само скинут тањир. Затим имамо Цруд оператера. ЦРУД је нешто што смо позовите у бази која је Направити, допунити, Делете оператера. То су ти уобичајени датабасе операције. Ствари као пут ставке, Гет итем, упдате ставке, брисање ставки, серија упит, скенирање. Ако желите да скенира целу табелу. Повуците све са стола. Једна од добрих ствари о ДинамоДБ је омогућава паралелно скенирање. Тако да заиста могу да дозволим да ме колико теме желите да покренете на том скенирања. И можемо покренути те теме. Можемо окреће да скенира до на више тема тако да можете скенирати цијелу табелу простор веома, веома брзо у ДинамоДБ. 

Други АПИ за који имамо је оно што зовемо наш потоци АПИ. Нећемо да разговарамо много о томе сада. Имам неки садржај касније на палуби у вези с тим. Али Потоци је заиста руннинг-- мислите о томе како време наредио и подела цханге лог. Све што се дешава на табела показује се на потока. 

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

Типови података. У ДинамоДБ, ми подржавамо оба кључа вредност и података документ врсте. Са леве стране екрана овде, имамо наше основне врсте. Кључне врсте вредности. Ово су жице, бројеви, и бинарне. 

Дакле, само три основне врсте. А онда можете имати комплета оних. Једна од лепих ствари о НоСКЛ је можете садрже низове као особина. И са ДинамоДБ можете садрже низове основних типова као роот имовине. 

А онда је врста докумената. Колико људи су упознати са ЈСОН? Ви упознати са ЈСОН толико? То је у основи ЈаваСцрипт Објекат, нотација. То вам омогућава да у основи дефинисати хијерархијску структуру. 

Можете похранити ЈСОН документ о ДинамоДБ користећи заједничке компоненте или блокови који су на располагању у већини програмским језицима. Дакле, ако имате Јаву, ти си гледајући мапе и листе. Ја могу креирати објекте који простор карту. Мапу као кључне вредности складишти као особина. И то можда има спискове Вредности унутар тих својстава. Можете сместити овај комплекс хијерархијска структура као јединствени атрибут од ДинамоДБ ставке. 

Тако столова у ДинамоДБ, као и већина НоСКЛ базе података, столови имају ставке. У МонгоДБ ти би зовем те документе. И то ће бити кауч база. Такође база документ. Ви називате ове документе. Документа или артикли имају атрибуте. Атрибути могу постојати или не постоји на ставку. У ДинамоДБ, ту је један обавезан атрибут. Баш као у релационој бази података, имате примарни кључ на столу. 

ДинамоДБ има оно што називамо тастер тараба. Хасх кључ мора бити јединствена. Дакле, када сам дефинисати хасх табелу, у основи оно што ја говорим је свака ставка ће имати тастер тараба. И сваки тастер тараба мора бити јединствена. 

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

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

Тако да можда има хасх кључ, што је тема личну карту. И можда има кључ опсег, што је ИД одговор. На тај начин, ако желим да се све одговори за одређену тему, Могу само да упита хасх. Могу само да кажем да ми све Ставке које имају овај хасх. И ја ћу да се свако питање или писати на тој теми. Ови топ агрегације нивоу су веома важни. Они подржавају примарни приступ Образац пријаве. Уопштено говорећи, ова је оно што желимо да радимо. Желимо да табле-- као што стављате на сто, желимо да се структурира податке у оквиру столу у такав начин да је апликација може врло брзо преузели те резултате. И често начин да се то уради је за одржавање ове агрегације као што смо убаците податке. У суштини, ми смо ширење податке у светлим канту јер долази у. 

Ранге тастери омогућавају ме-- хасх Тастери морају бити једнакости. Када сам куери хасх, морам да кажем дај ми хасх која се своди на то. Када сам куери низ, ја могу да кажем да ми низ да се користи било какву богата оператер који ми подржавамо. Дај ми све ставке за хасх. Да ли је једнак, већи од, мање него, то почиње, то постоји између ове две вредности? Дакле ове врсте опсега упита да смо увијек интересују. Сада једна ствар о подацима, када погледате приступ подацима, када можете приступити подацима, то је Увек се ради о једном груписања. Увек се ради о евиденцији који се односе на ово. Дај ми све овде је-- све трансакције на овом кредитне картице за последњих месец дана. То је агрегације. 

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

Дакле, оно друго тастер тараба Да ли је то нам даје механизам да би могли да шире податке около. НоСКЛ базе података ради најбоље када су подаци равномерно дистрибуирани преко кластера. Колико људи су упознати са хасхинг алгоритме? Када кажем хасх и хасхинг-- јер је хасхинг алгоритам је начин да буде у стању да генерише насумичним вредностима од било ког датог вредности. Дакле, у овом конкретном случају, хасх алгоритам трчимо је НД 5 басед. 

И ако имам личну карту, и то је мој тастер тараба, Имам 1, 2, 3. Када сам покренути хасх алгоритам, да ће се вратити и рећи, и износи 1 7Б, 2 једнако 48, 3 једнака ЦД. Они шире по целом кључног простору. А зашто то радиш? Зато што осигурава да могу пут записе на више чворова. 

Ако ово радим постепено, 1, 2, 3. И имам хасх опсег који Ради у овом конкретном случају, мали хасх простор, она траје од 00 до ФФ, онда су записи ће доћи у и они ће да иду 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. Šta se dešava? Сваки уметак иде на исти чвор. Видиш шта мислим? 

Јер кад сам поделити простор, и ја проширила ове записе преко, и ја партиција, ја ћу рећи партиција 1 има кључну простор 0 до 54. Подела 2 је 55 до 89. Подела 3 је А. у ФФ. Дакле, ако сам користећи линеарно увецава Личне карте, можете видети шта се дешава. 1, 2, 3, 4, 5, 6, све тако редом до 54. Дакле, као што сам чекићем евиденције у систем, све завршава ће једног чвора. 

To nije dobro. То је антипаттерн. У МонгоДБ имају овај проблем ако не користите тастер тараба. МонгоДБ вам даје опцију од хасхинг кључну вредност. Увек треба урадити, ако ви користите инцрементинг хасх кључ у МонгоДБ, или ћете бити ексерима сваки Пишите једног чвора, а ви ћете бити ограничавајући Ваш писања проток лоше. 

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

Рицк Хоулихан: Да, то је ту негде. А9, ја не знам. Мораш да узмем бинарни да децимални калкулатора. Мој мозак не функционише тако. ПУБЛИКА: Само на брзака ваше монго коментара. Тако је ИД објекта који долази изворно са Монго то? Рицк Хоулихан: Да ли је то? Ако га наведете. Са МонгоДБ, имате опцију. Можете специфи-- сваки документ у МонгоДБ мора да има доњу ИД. То је јединствена вредност. 

У МонгоДБ можете одредити да ли да га хасх или не. Они само вам дати опцију. Ако знате да је насумице, нема проблема. Не треба да урадите то. Ако знате да то није случајно, да то се увецава, а затим урадите хасх. 

Сада ствар у вези хасхинг, када хасх валуе-- а ово је зашто хасх тастери су увек јединствени упити, јер сам променила вредност, сад не могу да урадим упит домета. Ја не могу да кажем је ово између ово или оно, јер хасх вредност не иде да буде еквивалент са стварне вредности. Дакле, када сте хасх који кључ, то је само равноправност. То је разлог зашто у ДинамоДБ тастер тараба упити су увек само једнакост. 

Тако сада у распону кеи-- кад додам тај кључ опсег, они кључни записи опсег сви доћи и они се чувају на исту партицију. Дакле, они су веома брзо, лако преузето јер ово је тараба, ово је распон. И видиш све са истим хасх се складишти на истој партицији простору. Можете користити тај кључ опсег да помогне пронађите своје податке близу његовог родитеља. Па шта ја стварно радим овде? Ово је један до многих односа. Однос између тастер тараба а кључни распон је један многима. Ја могу имати више хасх кључеве. Ја само могу имати вишеструку опсег Тастери у оквиру сваке тастер тараба. 

Хасх дефинише родитеља, распон дефинише децу. Дакле, можете видети да је аналогни овде између релационом конструкт и исте врсте гради у носкл. Људи причају о НоСКЛ као нонрелатионал. Није нонрелатионал. Подаци увек има везе. Ти односи само различито моделира. Хајде да причамо мало мало о трајности. Када пишете да ДинамоДБ, пише су увек три начина реплицирати. То значи да имамо три АЗ-а. АЗ је су доступност зоне. Можете мислити на доступност Зона као дата центар или скуп дата центара. Ове ствари су географски изоловани једни од других у различитим зонама грешке, преко различите снаге решетке и плавна подручја. Неуспех у једном АЗ није це да скину други. Они су такође повезани заједно са тамном влакнима. Она подржава један суб 1 милисекунди кашњења између АЗС. Дакле у реалном времену понављања података способна за мулти АЗС. 

И често мулти АЗ размештања испуњавају високе захтјеве доступности већине предузећа организација. Дакле, ДинамоДБ се шири преко три АЗС по дефаулту. Идемо само на знање Тхе Врите када две од те три чвора врати и кажу, Да, имам га. Zašto je to? Зато што на читање страни смо само ће вам дати податке кад смо га добили од два чвора. 

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

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

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

Хајде да причамо о индексима. Тако смо споменули да највиши ниво агрегације. Имамо хасх кључеве, и имамо кључеве домета. To je lepo. И то је на примарној табели, ја Имам један тастер тараба, имам један кључ домета. 

Šta to znači? Имам један атрибут који сам може покренути богате упите против. То је кључ опсег. Остали атрибути на том итем-- Ја могу филтрирати по тим атрибутима. Али ја не могу да радим ствари као, да почиње са, или је већа од. 

Kako da uradim to? Ја стварам индекс. Постоје две врсте индекси у ДинамоДБ. Индекс је стварно још један поглед на столу. И локална секундарна индекса. 

Први ћемо разговарати о томе. Дакле, локални секундарни су коегзистирају на истој партицији као подацима. И као такви, су на исти физички чвор. Они су оно што зовемо доследни. Значи, они ће признати Тхе Врите заједно са столом. Када писања долази у, ћемо писати преко индекса. Ми ћемо писати до стола, а онда ћемо признати. Дакле, то је доследно. Када је писање је признао из табеле, то је гарантовано да локалне средње индекса ће имати исту визију података. Али оно што дозвољавају урадите је дефинишу алтернативне кључеве домета. 

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

Сваки део који је направио ово произвођач након овог датума, Морам да повуче из мог линије. Могу спин индекс да ће бити у потрази, агрегирања на дан производство на том делу. Дакле, ако мој сто највиши ниво био Већ хеширану од стране произвођача, можда је договорено на делу ИД, ја може створити индекс са тог стола као хеширану од стране произвођача и кретала о датуму производње. И на тај начин могу да кажем, нешто што је произведен између тих датума, Морам да извући из линије. Тако да је локални секундарни индекса. 

Оне имају ефекат ограничавајући свој тастер тараба простор. Зато што су цо-постојало на истој складиштења чвора, они ограничавају тастер тараба простор за 10 гигабајта. ДинамоДБ, под столови, партиције ваш сто на сваких 10 гигабајта. Када сте ставили 10 концерата података у, смо го [ПХХ], а ми додати још чвор. 

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

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

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

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

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

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

Ја стварно треба само знати вхицх-- мој приступ образац може рећи, које ставке садржи овај објекат? Не треба да се врати ставку. Само морам да знам које ставке га садрже. Дакле, можете изградити индексе да само имам кључ табеле. 

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

ГСИС, па како они раде? ГСИС основи су асинхрони. Упдате долази у табели, сто се онда асинхроно ажурира сву своју ГСИС. То је разлог зашто су ГСИС на крају доследан. 

Важно је напоменути да када правите ГСИС, а ви разумете да правите Друга димензија аггрегатион-- Сада рецимо добар пример овде је произвођач. Мислим да сам можда причали о медицински произвођач уређаја. Произвођачи медицал девице често имају серијализоване делове. Делови који иду у замена кука све имају мало серијски број на њих. И они могу имати милионе и милиони и милијарде делова у свим уређајима који су брод. Па, они треба да формира под различите димензије, сви делови у скупштини, све делови које су направљене на одређеној линији, све делови који су дошли из одређеног произвођача одређеног датума. И ове агрегације понекад устати у милијардама. 

Тако радим са неким ови момци који пате јер они стварају ови Гинормоус агрегације у својим средњим индекса. Они можда има сиров делова Табела која долази само као хасх. Сваки део има јединствени серијски број. Ја користим серијски број као хасх. Prelepo je. Мој сирови подаци сто се шири широм кључног простору. Мој [? писати?] [? гутање?] ис авесоме. Узимам много података. Онда је оно што раде они стварају ГСИ. И ја кажем, знаш шта, морам да видим сви делови за овог произвођача. Па, одједном сам узимајући милијарду редове, и напуните их на један чвор, јер када Ја агрегата као Мануфацтурер ИД као хасх, а парт нумбер као опсег, онда одједном сам Стављање милијарду делова у оно овај произвођач ме је достављена. 

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

У реду, тако ГСИ-а, ЛСИ је, која треба да користим? ЛСИ је у складу. ГСИ-а су на крају доследни. Ако је то у реду, ја препоручујем користећи ГСИ, они су много флексибилнији сте. ЛСИ је да се моделира као ГСИ. И ако је величина подаци по хасх тастера у Ваш колекција премашује 10 гигабајта, онда ћеш да желите да користите да ГСИ јер то је само тешко граница. 

У реду, тако скалирање. Проток у Динамо ДБ, ви Цан одредба [неразумљиво] пропусну моћ на табели. Имамо купце који имају снабдевени 60 биллион-- раде 60 милијарди захтеве, редовно ради на преко милион захтева секунди на нашим столовима. Заиста нема теоријска граница за колико и колико брзо сто може покренути у Динамо ДБ. Постоје неки меки ограничења на ваш рачун да смо у тамо ставио тако да не полудиш. Ако желите више да, није проблем. Дошао си реци нам. Ми ћемо се појавити бројчаник. 

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

Дакле, ово су прилагођени независно једна од друге. РЦУ је мера строго у складу чита. У реду, тако да ако кажем да желим 1,000 РЦУ је да су то строго у складу, они су у складу чита. Ако кажем да желим евентуално у складу чита, можете одредба 1,000 РЦУ је, идеш да се на крају 2,000 у складу чита. И пола цене за оне на крају се састоје у саопштењу. 

Опет, прилагођена независно једна од друге. И они имају тхроугхпут-- Ако конзумирате 100% свог РЦУ, нећеш да утицати на доступност ваших права. Дакле, потпуно су независне једна од друге. У реду, тако да једна од ствари које Поменуо сам кратко је гушење. Пропорционално је лоше. Пропорционално указује на лоше не СКЛ. Постоје ствари које можемо да урадимо да помогнемо можете ублажити тхроттлинг која вас доживљавају. Али најбоље решење да је ово узмимо Погледајте шта радиш, јер има анти-образац у игри овде. 

Ове ствари, ствари као што су не-униформе оптерећења, хот кеис, хот партиције. Ја ударање одређену кључну простор врло тешко за неког посебног разлога. Зашто ја ово радим? Хајде да схватим. Ја мешање моје вруће податке са хладним подацима. Пуштам моје табеле се огроман, али стварно нема само су неки подскуп података то је стварно интересантно за мене. Дакле, за податке дневника, на пример, много купци добијају податке дневника сваки дан. Имају огромну количину података лог. 

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

Постаје огромна. Она почиње ширење се широм хиљада чворова. А пошто својству је тако ниско, ти си заправо оцените ограничава на сваком један од тих појединачних чворова. Почнимо гледајући како морамо ролл тај сто преко. Како управљати те податке мало боље да се избегне ове проблеме. А шта то личи? Ово је како то изгледа. То је оно што лоше НоСКЛ изгледа. 

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

Дакле, плава је лепо. Ми волимо плаво. Ми не волимо црвено. Ред, где је притисак устаје до 100%. 100%, сад ћеш да тхроттлед. Дакле, кад год видите неке црвене линије као што су Ово-- и то није само Динамо ДБ-- свака НоСКЛ база података има овај проблем. Постоје анти-обрасци који може возити ове врсте услова. Оно што ја радим је да ради са клијентима да ублажи ових услова. 

А шта то личи? И то је све највише Динамо из ДБ протока, али то је стварно постаје највише од носкл. Ово није ограничено на Динамом. Ово је дефинители-- сам Радила у Монго. Упознат сам са многим НоСКЛ платформама. Свако има ове врсте врућих кључних проблема. Да бисте добили највише од било које носкл база података, посебно Динамо ДБ желите да креирате табеле где тастер тараба елемент има велики број различитих вредности, висок степен кардиналности. Зато што то значи пишем да много различитих кашике. 

Што више кашике сам писаној форми, то је већа вероватноћа Ја сам ту да се прошири рад писања или прочитајте лоад се преко више чворова, то је већа вероватноћа сам да имам Високо пропусна моћ на столу. И онда желим да будем вредности тражи прилично равномерно током времена и равномерно што насумично могуће. Па, то је интересантно, јер ја не могу стварно Контрола када корисници дођу. Дакле, довољно је рећи, ако се шири ствари се преко кључног простора, вероватно ћемо бити у бољој форми. 

Постоји одређена Износ време испоруке да не идеш Да бисте могли контролу. Али они су заиста две димензије које имамо, простор, приступ равномерно намаз, време, захтеви стигну равномерно распоређене у времену. А ако њих двоје услови су испуњени, онда је то оно што је ће изгледати. Ово је много лепше. Ми смо овде заиста срећан. Имамо веома чак приступни образац. Да, можда си Постаје мали притисак сваки сада и онда, али ништа стварно превелика. Дакле, то је невероватно колико пута, кад радим са клијентима, тај први графикон са великим црвеним бар и све то ружно жута је свуда смо се врши са вршењем након неколико месеци ре-архитектуре, трче потпуно исти обим посла у исто оптерећењем. И то је оно што гледа као сада. Дакле, оно што добијате са носкл је Подаци шема која је апсолутно везана за приступ обрасцу. 

И ви можете оптимизовати те податке шему да подржи да приступ образац. Ако то не урадите, онда идеш да видимо те врсте проблема са тим врућим тастерима. 

ПУБЛИКА: Па, неминовно нека места ће бити топлије од других. 

Рицк Хоулихан: Увек. Увек. Да, мислим увек постоји је-- и опет, ту је неки обрасци дизајна ћемо проћи који ће говорити о томе како да се бавите са овим великим Супер агрегацијама. Мислим, морам да их имају, како да се носимо са њима? Имам прилично добар Усе Цасе да ћемо разговарати о за то. 

У реду, тако да хајде да разговарамо око неке муштерије сада. Ови момци су Адролл. Ја не знам да ли си упознат са Адролл. Вероватно их видим много на претраживачу. Они су ад поновно циљање, они су највећи пословни оглас Ре-циљање тамо. Они обично редовно прегазио 60 милијарди трансакција дневно. Они раде преко милион трансакције у секунди. Имају прилично једноставан табелу структура, најпрометнија сто. То је у основи само тастер тараба је колачић, опсег је демографска категорију, затим трећи атрибут је резултат. 

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

Сада имају СЛА са њихове рекламне провајдери да обезбеди Суб-10 милисекунди одговор на сваки захтев. Дакле, они користе Динамо ДБ за то. Они нас је ударање милион захтева у секунди. Они су у стању да уради све њихове лоокупс, тријажа сви подаци, и добити тај Додај линк вратити на то оглашивач на основу 10 милисекунди. То је стварно лепа феноменално Имплементација да имају. 

Ови момци стварно-- да ли су ово момци. Нисам сигуран да ли је ове момке. Може бити ови момци. У основи нас-- рекао не, не мислим да их је било. Мислим да је то био неко други. Ја сам радио са купац који ми је рекао да сада када имам отишао у Динамо ДБ, они су троше више новца на грицкалице за њихов развојни тим сваког месеца него они троше на њиховој бази података. Тако да ћу вам дати један Идеја о уштедама да можете добити у Динамо ДБ је огромна. У реду, дропцам је друга компанија. Ово момак је некако од-- ако мислите интернет ствари, дропцам је у основи Интернет Сецурити Видео. Ставио своју камеру тамо. Камера има детектор покрета. Неко дође, изазива Цуе Поинт. Камера започиње снимање неко време до то више не детектује било какво кретање. Ставља тај видео на интернету. 

Дропцам је компанија која је у основи укључен у Динамо ДБ јер су доживљава огромни Гровинг Паинс. А шта су нам рекли, изненада петабајта података. Нису имали појма своју службу би био тако успешан. Више долазни Видео од ИоуТубе је оно што су ови момци добити. Они користе ДинамоДБ пратити све метаподатака на свим својим видео кључним тачкама. 

Дакле, они имају С3 кашике гурају све бинарни артефакти во. И онда они имају Динамо ДБ записи који указују на те С3 три објекта. Када треба да погледате видео снимак, изгледају горе рекорд у Динамо ДБ. Они кликните на линк. Они спустите видео из С3. Дакле, то је некако како ово изгледа. А ово је право из њиховог тима. 

Динамо ДБ умањује њихову Време испоруке за видео догађаје од пет до 10 секунди. У свом старом релациону продавници, они морали да иду и извршавање више сложених упита да схватим од видео клипова који се спусти, на мање од 50 милисекунди. Дакле, то је невероватно, невероватно колико перформансе можете добити када оптимизацију и подесите је основна база података да подрже приступ образац. Халфбрицк, ови момци, шта је то, Фруит Ниња Претпостављам да је њихова ствар. То све ради на Динамо ДБ. А ови момци, они су велики Развојни тим, велики напредак продавница. 

Није добра Опс тим. Нису имали много од оперативних ресурса. Они су се борили покушава да задржи њихова примена инфраструктуре до и ради. Они су дошли до нас. Гледали су у том Динамо ДБ. Рекли су да је то за нас. Они су изградили своје цело Апликација оквир за њега. Неке заиста лепе коментари овде из тима на њихову способност сада фокусирати на изградњу игра и не морају да одржавати инфраструктура, која је постао огроман надземних за свој тим. Дакле, ово је нешто то-- корист да ћете добити од Динама ДБ. 

У реду, узимајући у Подаци моделирање овде. Разговарали смо мало о овај један према један, један до многе, и многи многим типа односа. И како да одржите оне у Динамом. У Динамо ДБ користимо индекси, уопштено говорећи, ротирати податке из човек укус на другу. Хасх тастери, тастери опсег, и индекси. 

У овом конкретном Пример, као и већина држава имају обавезу лиценцирања који Само један возачка дозвола по особи. Не могу да се два возача лиценце у стању Бостону. Не могу то учинити у Тексасу. То је врста онако како је. И тако на ДМВ, имамо лоокупс, ми Желим да се угледају на возачку дозволу по броју социјалног осигурања. Желим да погледам информације о кориснику по броју дозволе возача. 

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

Ако желим да упита и желим да бисте добили социјалну сигурност број или други атрибути би а број лиценце, могу упит ГСИ. Тај модел је онај једном односа. Само врло једноставна ГСИ флип те ствари. Сада, говоримо о један до многих. Један многима је у основи Ваш кључ хеш опсег. Где смо добили доста са овим Употреба случај је монитор података. Монитор података долази у редовно Интервал, као интернет ствари. Ми смо увек добити све ово евиденција долази све време. 

И желим да пронађе све очитавања између одређеног временског периода. То је веома чест упит у Мониторинг инфраструктура. Начин иди о томе да се нађе једноставна структура сто, један сто. Имам мерења уређаја табелу са тастер тараба на ИД уређаја. И ја имам опсег тастер на Време, или у овом случају, епска. И то ми омогућава извршавање комплекс упити против тог тастера ранге и вратити оне записе који су релативне до резултата сет да тражим. И гради да је један многима везу у примарној табели, користећи тастер тараба, опсег кључ структура. 

Тако да је некако изградио у табели у Динамо ДБ. Када сам дефинишемо хасх и опсег Т сто, ја сам дефинисање једног многима односа. То је однос родитељ-дете. 

Хајде да причамо о многим многим односима. А за овом конкретном примеру, Поново ћемо користити ГСИ-а. И хајде да причамо о играма сценарио у коме имам датог корисника. Желим да сазнам све игре које Он је регистрован за играње или у. И за дату игре, желите да пронађете све кориснике. Па како то да урадим? Мој усер игре сто ја идем да има тараба кључ кориснички ИД и низ кључ игре. 

Тако корисник може имати више игара. То је један до многих однос између корисник и игре игра. А онда на ГСИ, Ја ћу флип да око. Ја ћу хасх на игру и Ја ћу се крећу на корисника. Дакле, ако желим да се све Игра корисник је играње у, Ја ћу упита главну табелу. Ако желим да добију све кориснике да играју одређену игру, Ја упита ГСИ. Видиш како то радимо? Ви градити ове ГСИ је да подржи случај употребе, апликација, приступ образац, апликација. 

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

Вероватно нећу ја да проведем много времена говори о документима. Ово постаје мало вероватно, дубље него морамо да идемо у. Хајде да причамо мало о богати упит израз. Дакле, у Динамо ДБ имамо могућност израде оно што ми зовемо пројекције изразе. Пројекција изрази су једноставно брање поља или вредности који желите да прикажете. У реду, тако да сам направи избор. Правим упит против Динама из ДБ. И ја кажем, знаш шта, представа ми само су критике пет звездица за одређени производ. Дакле, то је све што желим да видим. Не желим да видим све остали атрибути реду, Ја само желим да видим ово. То је исто као у СКЛ када кажу изаберите звезду или из табеле, добијате све. Када кажем изаберите име из сто сам се само један атрибут. То је иста ствар у Динамо ДБ или још НоСКЛ базе података. Филтер изрази дозволите да у основи смањи резултат спусти. Зато се трудим да упит. Упит могу вратити са 500 предмета. Али ја само желим ставке које има атрибут који каже ово. У реду, хајде да филтрирају те ставке који не одговара тог конкретног упит. Дакле, имамо филтер изразе. 

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

Али ако читам целу гомилу података, само да пробију један предмет, онда ћу бити бољи са употребом упит опсег, јер је много селективна. То ће ме спасити много новац, јер сам платити за то реад. Где су резултати које врати цросс ту жицу може бити мањи, али ја плаћам за читање. Па разумем како ви добијате податке. То је веома важно у Динамо ДБ. 

Условне изрази, то је оно што можете назвати оптимистично закључавање. Ажурирање ако постоји, или ако ове вредности је еквивалент ономе што сам одредити. И ако имам времена печат на запис, можда читају податке. Ја могу променити те податке. Могао бих да одем напишем да Подаци назад у базу података. Ако је неко променио плочу, су временски маркери можда променио. На тај начин моја условна ажурирање може рећи упдате ако је тиместамп једнака ово. Или ажурирање неће успети, јер некоме упдатед рекорд у међувремену. 

То је оно што ми зовемо оптимистично закључавање. То значи да је неко може ући и промените га, и ја ћу да га открију кад се вратим да напишем. И онда се могу прочитати да података и кажем, ох, он је променио то. Морам да рачун за то. И могу промијенити податке у мом снимити и примењују други упдате. Дакле, можете ухватити оне постепен исправке које се јављају између времена да читају податке и Време можете писати податке. 

ПУБЛИКА: А филтер израз заправо не значи у броју или не-- 

[Ставим Воицес] Рицк Хоулихан: Нећу се превише у ово. Тхис Ис резервисано кључна реч. Поглед Фунта је резервисан кључна реч у Динамо ДБ. Свака база има своју задржана имена за колекција не можете да користите. Динамо ДБ ако наведете фунта испред овога, можете дефинисати та имена изнад. Ово је референцира вредност. То је вероватно није најбоља синтакса у има тамо за ову расправу, јер уђе у неким реал-- Ја бих причао више о томе на дубљем нивоу. 

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

И први ћемо Разговор о је интернет ствари. Тако смо добили много од-- претпостављам, што је То-- више од 50% саобраћаја на интернету ових дана заправо генерише машинама, аутоматизовани процеси, а не људи. Мислим ово ово ствар која носите око у џепу, колико података да је ствар Заправо слање око без тебе знајући то је апсолутно невероватан. Ваша локација, информације о томе како брзо идете. Како мислите Гоогле Мапс радова кад вам кажу шта је саобраћај. То је зато што постоје милиони и милиони људи возе около са телефонима које шаљу Подаци широм месту све време. Дакле, једна од ствари о овој врсти података који долази у, монитор података, лог података, подаци серија време, је да је обично само интересантно за мало времена. Након тог времена, то је Не тако занимљиво. Дакле, разговарали смо о, не дај те столове расту без граница. Идеја је да можда имам 24 сати у вредности од догађаја у мом врелом табели. И то топла сто це бити привилегије на врло високом стопом, јер узима доста података. То је узимање доста података а ја читам много. Имам пуно рада упити који раде против тих података. 

Након 24 сата, хеј, Знаш шта, није ме брига. Дакле, можда је сваки поноћи лол мој сто преко новом столу и ја депровисион ову табелу. А ја ћу узети РЦУ-а и ВЦУ је доле, јер 24 сата касније Ја не водим колико упити против тих података. Зато ћу да уштеди новац. А можда 30 дана касније, не знам Чак треба да се брине о свему. Могао бих узмите ВЦУ је скроз на једну, јер знате шта, то је никада неће добити писао. Ови подаци су 30 дана. То никада не мења. 

И то скоро никад неће добити читати, па узмимо ту РЦУ до 10. А ја штеди гомилу новца на ово података, а само плаћање за моје топле података. Дакле, то је важно погледати у када погледате временску серију Подаци долази у обиму. То су стратегије. Сада, само да га пусти сви на истим столом и пусти тај сто расте. На крају, ја ћу види проблеме са перформансама. Ја ћу морати да почну да архивира неки од тих података са стола, шта не. 

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

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

А онда већина ваших читања почни овако. Имам све ово кеш хитс овде И ја сам се ништа не дешава доле јер база података седи иза кеш и чита никада проћи. Ако промените податке у база података, морам да ажурира кеш. Ми можемо да користимо нешто као паре за то. И ја ћу објаснити како се то ради. У реду, порука. Е-маил, сви користе емаил. 

Ово је прилично добар пример. Имамо неку врсту поруке табеле. И имамо пријем и слање. То је оно што СКЛ би личи изградимо тај пријем. Ми врста користи исту врсту стратегије за коришћење ГСИ је ГСИ је фор ми инбок и моје слање. Тако сам добио сирови поруке долазе у моје поруке сто. И први приступ овоме можда, рећи, ОК, нема проблема. Имам сирове поруке. Поруке које долазе [неразумљиво], Мессаге ИД, то је сјајно. То је мој јединствени хасх. Ја ћу створити два ГСИ, један фор ми инбок, један за моју слање. И прва ствар коју ћу урадити је Рећи ћу мој тастер тараба је ће бити прималац и Ја ћу договорити о датуму. Ово је фантастично. Добио сам леп поглед овде. Али овде мало питање. И наиђете на ово релационе базе података као добро. Звали су вертикално раздвајање. Ви желите да задржите своју велику податке далеко од твојих података. 

А разлог зашто је зато што морам да читате ставке да се атрибуте. А ако моја тела су сви овде, онда читање само неколико ставки ако моје тело је дужина у просеку 256 килобајта сваки, математика добија прилично гадно. Дакле, кажем да желим да прочитам Давидову инбок. Давид пријем има 50 ставки. Просечна величина и је 256 килобајта. Ево моје Конверзија за РЦУ је четири килобајта. 

У реду, идемо са на крају у складу чита. И даље једем 1600 РЦУ је само да прочитам Давидову инбок. Јао. У реду, хајде да размислимо о томе како апликација ради. Ако сам у апликацији емаил и Гледам мој инбок, и ја погледамо тело сваку поруку, Не, ја гледам сажетака. Гледам само заглавља. Дакле, хајде да изгради структуру табеле да изгледа више тако. 

Дакле, ево информације да је мој процес рада треба. То је у мом инбоку ГСИ. То је датум, пошиљалац, предмет, а затим лична порука, што указује назад на табели мессагес где могу добити тело. Па, то би било рецорд личне карте. Они би указивало назад у итем личне карте на столу Динамо ДБ. Сваки индекс увек цреатес-- увек има ставку ИД као део од-- да долази са индексом. 

U redu. ПУБЛИКА: То је место где се то складиште? Рицк Хоулихан: Да, то говори екацтли-- то је управо оно што ради. Овде пише моје поновно рекорд. И то ће се указати у моју поновном записник. Baš tako. У реду, тако да сада мој пријем је заправо много мањи. И то заиста подржава Процес рада једног апликације е-поште. Дакле мој инбок, кликнем. Успут и кликните на поруци, то је кад морам да одем тело, јер ћу идите у другу поглед. Дакле, ако мислите о МВЦ врсти оквир, Модел Виев Цонтроллер. 

Модел садржи подаци да је поглед потребе и контролер интеракцији са. Када сам промијенити оквир, када Ја промените перспективу, да је у реду да се вратим до сервер и насели модел, јер то је оно што корисник очекује. Када мењају ставове, тада је можемо да се вратимо у базу података. Тако е-маил, кликните на дугме. Ја сам у потрази за тело. Povratno putovanje. Иди тело. 

Прочитао сам много мање података. Само читам тела која Давид мора када су му потребни. И не гори у 1600 РЦУ само да покаже своју инбок. Дакле, сада то-- то је начин да ЛСИ или ГСИ-- Жао ми је, ГСИ би успело. Имамо нашу хасх на примаоца. Имамо кључ домета на дан. И имамо пројектованих атрибуте да само треба да подрже став. 

Ми окретати да за слање. Хасх на пошиљаоца. У суштини, имамо веома леп, чист поглед. И то је басицалли-- смо Имам ову лепе поруке сто да се шири, јер лепо то је само хасх, хеширану Мессаге ИД. И ми имамо два индекса који ротирају са тог стола. У реду, тако да идеја овде не задржи велике податке и ову малу податке заједно. Партитион вертикално, подели те табеле. Немојте читати податке не морате да. У реду, играње. Ми сви волимо игре. Барем ја волим игрице онда. Дакле, неке од ствари да се бавимо када размишљамо о игрању, зар не? Гаминг ових дана, нарочито мобилни играње, то је све о размишљању. И ја ћу ротирати овде мало даље од ДинамоДБ. Идем да доведем неки од дискусије око неких друге АВС технологије. 

Али идеја о игрању је мислити о у смислу АПИс Апис који су, Уопштено говорећи, ХТТП и ЈСОН. То је како мобилни игре врста интеракцију са леђима крајевима. Они ЈСОН постављање. Они се подаци, и то је све, генерално гледано, у лепим ЈСОН АПИ. 

Ствари као да пријатеље, да подаци о Лидери, размена, корисник генерише садржај, потисну до система, ово су типови ствари да ћемо да урадимо. Бинарни подаци средство, ови подаци не би седети у бази података. То би могло седи у објекат продавница, зар не? Али база ће завршити говори систем, говори пријаву где да одем да. И неминовно, мултиплејер сервери, задњи део инфраструктуре, и дизајниран за високо доступност и скалабилност. Дакле, то су ствари које сви желимо у играчком инфраструктури данас. 

Дакле, хајде да погледамо како то изгледа. Има језгро задњи крај, веома једноставан. Имамо систем овде са више доступност зоне. Разговарали смо о АЗС као беинг-- мисле од њих као засебне дата центара. Више од једног дата центар по АЗ, али то је у реду, Само мислим о њима као засебну података центри који су географски и кривица изолован. 

Ми ћемо имати Пар ЕЦ2 инстанце. Ми ћемо имати нека врати крај сервера. Можда ако сте наслеђе архитектура, ми смо користећи оно што зовемо РДС, релационалних услуге бази података. Могао би бити МССКЛ, МиСКЛ, ili nešto slično. Ово је начин на који лот апликације су дизајнирани данас. 

Па можемо желим да идем са ово је када смо скала напоље. Идемо напред и стави С3 кашика горе. И то С3 кашика, уместо да служи до тих објеката из наше серверс-- моземо то да урадимо. Ставио све своје бинарни објекти на вашим серверима и можете користити оне сервер случајеви да служе те податке горе. Али то је прилично скупо. 

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

Сада имамо корисницима широм света. Имам корисницима. Морам да имам садржаја локално налази у близини ових корисника, зар не? Ја сам створио С3 канту као мој изворно спремиште. И предњи ћу да са ЦлоудФронт дистрибуција. 

ЦлоудФронт је ЦД и Садржај испоруке мрежу. У основи то узима податке које сте навели и све то кешира преко интернета тако да корисници могу да имају свуда веома брз одговор када траже те објекте. 

Тако добијате идеју. Ти си некако усклађивање свих аспекти АВС овде да се то уради. И на крају, бацамо у саобраћајној скалирања групе. Дакле, наше АЦ2 случајевима наши сервери игре, јер ће почети да се заузетија и заузетија и заузетија, они ће само да окрећу други инстанца, спин другом случају, спин другом случају. Тако технологије: АВС има, то омогућава да одредите параметре око којих ће ваши сервери расти. Дакле, можете имати н број сервера тамо у било ком тренутку. А ако ваш терет оде, они ће психијатар, број ће се смањити. А ако је терет врати, то ће расти напоље, еластично. 

Дакле, ово изгледа сјајно. Имамо доста ЕЦ2 инстанцама. Можемо ставити кеша у предњи део базе података, покушати да убрза базе података. Следећа тачка притиска обично људи виде је да скала игру користећи релациона база података систем. Исусе, база података Представа је страшно. Како да побољшамо ово? Хајде да покушамо стављање кеш испред тога. 

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

Па где идемо одавде? Имате велику уско грло доле у ​​бази података. И где да одем Очигледно је подели. Подела није лако урадити када сте које се баве релационим базама података. Са релационим базама података, ти си одговорна за управљање, ефикасно, кључ простор. Кажеш корисницима између А и М идите овде, између Н и З идем тамо. А ти свитцхинг преко апликације. Дакле, имате посла са Ова партиција извор података. Имате трансакционе ограничења да не спан партиције. Имаш све врсте збрци да сте која се бави тамо покушавају да се баве скалирање од и изградњу инфраструктуре већи. То је само забавно. 

ПУБЛИКА: Дакле, ви кажете да повећање извора бодова убрзава proces? Рицк Хоулихан: Повећање? ПУБЛИКА: Соурце поена. Рицк Хоулихан: Соурце бодова? ПУБЛИКА: Из информација, где се информације које долазе из? Рицк Хоулихан: Не Оно што хоћу да кажем је повећању број преграда у складишту података побољшава проток. Дакле, шта се овде дешава је корисницима Ступањем на ЕЦ2 пример овде, Па, ако је потребно корисника То је на М, идем овде. Од Н се п, идем овде. Од П до З, идем овде. 

ПУБЛИКА: Добро, они тако то су све сачуване у различитим чворовима? 

Рицк Хоулихан: Да. Мисли од њих као различити силоси података. Дакле, имате за то. Ако покушавате да урадите ово, ако покушаваш у размери на релациону платформи, то је оно што радите. Идеш податке и ви га сјече. И ти га поделе преко више инстанци базе података. А ти све то управљања на апликације слоју. Није забавно. Дакле, шта желимо да идемо? Желимо да идемо ДинамоДБ, у потпуности успјела, НоСКЛ подаци продавница, одредба проток. Ми користимо секундарне индексе. То је у основи ХТТП АПИ и укључује подршку документ. Дакле, не морате да бринете о било тог поделу. Ми све радимо за вас. Дакле, сада, уместо тога, ви само пишите на табели. Ако је табела треба подељен, што се дешава иза сцене. Потпуно си изолован од тога као програмера. Дакле, хајде да разговарамо о неким предметима коришћења да налетимо у играма, заједничка гаминг сценарија, Лидери. Дакле, имаш корисници долазе, су БоардНамес да су они на, резултати за овај корисника. Могли бисмо да се хасхинг на усерид, а онда имамо низ на игру. Дакле, сваки корисник жели да види све је игра он играо и сва његова Топ резултат кроз све игре. Дакле, то је његов лични Лидери. 

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

Сада ћу хасх на БоардНаме, која је игра. И ја ћу да се креће на врху резултат. И сад сам створио различите канте. Ја користим исти сто, исти податак. Али ја стварање канту која даје ми скупа елемената топ резултатом од дивљачи. 

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

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

Тако смо слаби на време овде. Ја идем напред и прескочите напоље и прескочите овај сценарио. Разговарајте мало о-- 

ПУБЛИКА: Могу ли да поставим једно кратко питање? Један је писати тешка? Рицк Хоулихан: Шта је? ПУБЛИКА: Врите тешка. Рицк Хоулихан: Напишите тешка. Daj da vidim. 

ПУБЛИКА: Или је то није нешто што једноставно не могу глас у неколико секунди? Рицк Хоулихан: Идемо кроз гласање сценарио. То није тако лоше. Да ли ви имате пар минута? OK. 

Дакле, ми ћемо разговарати о гласању. Дакле, у реалном времену гласања, имамо Захтеви за гласање. Захтеви су да дозвољавамо свака особа да гласају само једном. Желимо нико моћи да промените свој глас. Желимо реалном времену агрегацију и аналитика за демографију да ћемо бити показује корисницима на сајту. 

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

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

И ово је сјајно. Život je dobar. Живот је добро док не откријемо да Увек постоји само један или два људи који су популарни у изборима. Постоји само једна или две ствари да људи заиста стало. А ако гласање на скала, одједном сам ће бити чекића напоље из два кандидата, један или два кандидата. Веома мали број ставки људи сматрају да буде популаран. 

Ово није добар дизајн образац. Ово је заправо Веома лош дизајн образац јер то ствара оно што смо говорио о којој је хот кеис. Хот тастери су нешто што се не допада. 

Како да поправити? И заиста, начин да се поправи ово је узимајући оне канте кандидата и за сваког кандидата имамо, ћемо додати случајан вредност, нешто што знамо, случајно вредност између једног и 100, између 100 и 1.000, или између једне и 1.000, Међутим многи рандом вредности желите да додати на крају тог кандидата. 

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

Дакле, имам милионе и милионе, и милиони евиденција долази за ове кандидате, ја сам сада шири ти гласови широм Кандидат А_1 кроз кандидат А_100, јер сваки пут глас долази у, Ја сам генерисање случајни вредност између једне и 100. Ја сам га прелијетајућег на крају овог Кандидат који особе гласање за. Ја то бацање у канту. 

Сада на полеђини, знам да имам стотину кашике. Дакле, када желим да наставим и агрегата гласова, Прочитао сам од свих тих канти. Тако да само напред и додајте. И онда ја скатера окупи где изаћи и рећи хеј, Знаш шта, кључ овог кандидата простори је преко стотину кашике. Ја ћу окупити све гласова од тих стотину канти. Идем да прикупљају их и ја ћу да кажем, Кандидат сада већ има Укупна пребројавање гласова од к. 

Сада су и писање упит и читања упит су лепо распоређени јер сам преко писања а ја читам преко стотина кључева. Ја не пишем и читање преко једним кључем сада. Дакле, то је велики узорак. 

Ово је заправо вероватно један од најважнијих дизајн обрасце за скали у носкл. Видећете ову врсту дизајн образац у сваком укусу. МонгоДБ, ДинамоДБ, није тако ма, сви ми треба да урадимо ово. Јер, када имате посла са тим огромним агрегацијама, морате да схватите начин на ширити их преко кашике. Дакле, ово је начин да то урадите. У реду, па шта радите сада је си тргује са реад трошкови за писање скалабилност. Трошкови мог реад је мало сложенији и ја морам да идем читати од А сто кашике уместо једне. Али ја сам могао да напишем. И мој пропусна, моја писања пропусна је невероватно. Дакле, то је обично вредан техника за скалирање ДинамоДБ, или било НоСКЛ база података по том питању. Па смо смислили како да га смањи. И ми схватили како елиминисати наше вруће тастере. А ово је фантастично. И имамо овај леп систем. И то нам је дало веома коректан гласање јер имамо запис гласова де-дупе. То је уграђен у ДинамоДБ. Разговарали смо о условним правима. 

Када је бирач дође у, ставља уметак на столу, они убацили са својим бирача ИД, ако покушају да убаците другу гласање, Ја условну писати. Реци само ово пишем ако то не постоји. Дакле, чим видим да да глас је ударио о сто, нико други ће бити у стању да стави свој глас у. И то је фантастично. А ми инцрементинг Наш кандидат шалтера. И ми радимо свој демографије и све то. Али шта се дешава ако моја Апликација падне? Сада одједном гласова долазе у, и не знам да ли они узимајући обрађују у моје аналитике и демографију више. А када је апликација врати се, како дођавола знам шта гласова има обрађена и где да почнем? 

Дакле, ово је прави проблем када вас почнете да погледате ову врсту сценарија. А како ћемо решити то? Ми га решити са оним што позовите ДинамоДБ потока. Преноси се време наредили и подељена цханге лог сваког приступа за сто, сваки писати приступ табели. Сви подаци који се уписују у сто се појављује на потока. 

То је у основи ред 24 часа. Предмети хит поток, они живе за 24 сата. Они се могу прочитати више пута. Гарантовано да буде испоручена само једном потоку, може прочитати н број пута. Дакле, међутим, многи процеси желите да троше те податке, можете га конзумирати. Она ће се појавити сваки упдате. Сваки писати ће само појављују једном на потока. Дакле, не морате да бринете о обради два пута из истог процеса. 

То је строго наредио по комаду. Када кажемо времена наредио и подељена, видећете по поделе на потока. Видећете ставке, исправке како. Ми не гарантује на потоку да сте ви ћете добити сваку трансакцију у циљу преко ставки. 

Дакле, потоци су идемпотент. Да ли сви знамо шта идемпотент значи? Идемпотент значи да можете то урадити над, и изнова, и изнова. Резултат ће бити исти. 

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

Иста ствар и са МонгоДБ. МонгоДБ има конструкт зову оплог. То је потпуно исти конструкт. Многи НоСКЛ базе података имају ову конструкт. Они га користе да радим ствари попут репликације, који је управо оно што радимо са потоцима. ПУБЛИКА: Можда јеретичке питање, али ти говоре о апликације раде доле тако даље. Да ли потоци гарантовано Никада вероватно пасти? Рицк Хоулихан: Да, потоци гарантовано не иду доле. Ми управљање инфраструктуром иза. аутоматски потока распоредити у свом аутоматско скалирања групе. Ми ћемо проћи кроз мало мало о томе шта се дешава. 

Не би требало да кажу да нису гарантовано да никада не иду доле. Елементи су загарантована да се појави у потоку. А струја ће бити доступна. Дакле, оно што иде доле или врати горе, што се дешава испод. То цоверс-- да је у реду. У реду, тако да добијете другачији виев врсте са екрана. Типови видети који су важно за програмер обично су, шта је то било? Имам стару поглед. Када ажурирање погоди сто, то ће пусх стари поглед на потоку тако да подаци могу архивирати, или промена контрола, промена идентификација, промена менаџмент. 

Нова слика, шта је сада, након ажурирање, то је друга врста поглед možete dobiti. Можете добити оба старе и нове слике. Можда сам их обоје желе. Желим да видим шта је то било. Хоћу да видим шта је промењено у. 

Имам тип усаглашености процеса који покреће. Потребно је да проверите да ли је када те ствари мењају, да су у оквиру одређених граница или у оквиру одређених параметара. 

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

Апликација која троши поток, ово је некако успут ово ради. ДинамоДБ клијент тражио да пусх податке у табелама. Потоци распореди на оно што ми зовемо комадиће. Крхотине су смањени независно од стола. Они не построје у потпуности на партицијама вашег стола. А разлог зашто је јер се построје у капацитета, струје Капацитет табеле. 

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

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

Тако да користи КЦЛ омогућен Апликација за читање ток. Кинесис клијент библиотека ствари управља раднике за вас. И такође ради неке интересантне ствари. То ће створити неке столове у вашем ДинамоДБ таблеспаце пратити које ставке су обрађени. Дакле, на овај начин, ако се врати падне, ако да падне и дође и добије стајао назад, може утврдити где био је у обради ток. 

То је веома важно када ви говорите понављања. Морам да знам шта Подаци су обрађени и који подаци тек треба да се обради. Дакле, КЦЛ библиотека за преноси ће да ти дам доста тога функционалности. Она брине о свим домаћинству. Она устаје радник за сваку фрагменту. То ствара управни табелу за сваки крхотином, за сваког радника. И као оне отпуштају раднике, они одржавају те табеле тако да знате овај запис прочитана је и обрађују. И онда тај начин, ако се процес умире и врати на мрежи, може да настави тамо где је отишао. 

Дакле, ми користимо ово крос-област репликација. Много купаца има потребу да се померите податке или делове њихових табелама око различитим регионима. Постоји девет региони svud oko sveta. Дакле, можда постоји морају-- сам можда има кориснике у Азији, корисници у источној обали Сједињених Америчких Држава. Они имају различите податке који мора бити локално дистрибуирати. И можда корисник лети из Азија над Сједињеним Државама, и желим да понове његови подаци са њим. Дакле, када дође из авиона, он има добро искуство користећи свој мобилни апликацију. 

Можете користити унакрсно регион репликација библиотека за то. У суштини имамо под условом две технологије. Један је конзола апликација можете станд уп на свом ЕЦ2 инстанце. Ради чист репликација. И онда ти је дао библиотеку. Библиотека можете користити за изградњу свој апликацију ако Желим да раде луде ствари са тим дата-- Филтер, копирају само део њега, ротирати податке, преместите их у посебна табела, и тако даље и тако даље. Дакле, то је некако како то изгледа. 

ДинамоДБ потоци могу бити обрађује оно што ми зовемо Ламбда. Поменули смо мало о догађају дривен апликација архитектуре. Ламбда је кључна компонента за то. Ламбда је код који испаљује на захтев у одговору на одређени догађај. Један од тих догађаја може да буде запис појављује на потока. Ако рекорд појави на потоку, ћемо назвати ову функцију Јава. Па, ово је Јава-скрипта и ламбда подржава Ноде.јс, Јава, Питхон а ускоро ће подржавати други језици као добро. И довољно је рећи, то је чиста кода. напиши У Јави, дефинишете класу. Ви притиснете ЈАР горе у Ламбда. И онда одредите које класа да позове у одговору на којима догађај. А онда Ламбда инфраструктура иза које ће покренути ту код. 

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

Дакле, можете ротирати те податке. Можете да креирате дериват поглед. Ако је структура документ, можете поравнајте структуру. Можете направити алтернативне индексе. Све врсте ствари које можете да везе са ДинамоДБ Стреамс. 

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

Разговарали смо о томе како да стави кеш испред базе података за ту продају Сценарио. Па шта се дешава ако упдате опис предмета? Па, ако сам имао Ламбда Функција ради на том столу, ако сам упдате опис артикла, то ће покупи рекорд са потока, и то ће ажурирати ЕластиЦацхе инстанца са новим подацима. Дакле, то је доста шта радимо са Ламбда. То је лепак број, конектори. И то је заправо даје способност да покрене и за покретање веома сложене апликације без дедицатед сервер инфраструктура, што је стварно кул. 

Дакле, хајде да се вратимо на нашу у реалном времену гласање архитектура. Ово је нова и побољшана са нашим потоци и КЦЛ омогућити апликацију. Исто као пре, можемо руковање било скале избора. Ми овако. Радимо од расејање прикупља на више корпи. Имамо оптимиста закључавање дешава. Можемо држимо гласаче мењају своје гласове. Они само могу да гласају само једном. Ово је фантастично. Толеранција грешке у реалном времену, прилагодљив агрегацију сада. Ако је ствар падне, то зна где да се поново када је у питању назад, јер да користимо КЦЛ апликацију. И онда можемо да користимо да КЦЛ апликација да гура податке од да црвени помак за друге апп аналитицс, или употреба еластични МапРедуце за покретање реал-тиме стреаминг агрегације офф тих података. 

Дакле, то су ствари које нису разговарали о много. Али они су додатно технологије које долазе да носе када гледате на ове врсте сценарија. 

У реду, тако да се о аналитика са ДинамоДБ потока. Можете прикупити де-дупе података, урадите све врсте лепо ствари, укупни подаци у меморија, стварају оне изведене табеле. То је огроман случај коришћења да много купаца су укључени у, узимајући Нестед својства тих докумената ЈСОН и стварање додатних индексе. 

Ми смо на крају. Хвала на лежај са мном. Дакле, хајде да разговарамо о Референце Арцхитецтуре. ДинамоДБ седи у средини тако много од АВС инфраструктуре. У суштини можете га повезати до свега што желите. Апликације изграђена коришћењем Динамо укључују Ламбда, ЕластиЦацхе, ЦлоудСеарцх, пусх податке напоље у Еластична МапРедуце, ​​увоз извоз из ДинамоДБ у С3, све врсте радних токова. Али вероватно најбољи ствар да разговарамо, и то је оно што је стварно Занимљиво је када смо говоре о догађајима дривен апликација. 

Ово је пример интерни пројекат да имамо где смо уствари издаваштво да окупи резултате анкете. Дакле, у емаил линк који ми послати, ту ћу бити мало веза каже клик овде да одговори на анкети. И када особа кликова које су повезане, шта се дешава је они срушити сигурна ХТМЛ форма истраживање из С3. Нема сервера. Ово је само С3 објекат. 

То облик појави, учитава у претраживачу. Има кичму. Има комплекс ЈаваСкрипт да се води. Зато је веома богата апликација трчање у бровсеру клијента. Они не знају да нису интеракције са леђа енд серверу. У овом тренутку, све је браузер. 

Они објавити резултате на шта зовемо Амазон АПИ Гатеваи. АПИ Гатеваи је једноставно Веб АПИ да можете дефинисати и спојити да шта год хоћеш. У овом конкретном случају, ми смо закачен на функцију Ламбда. 

Дакле, мој пост операција догађа без сервером. У основи је АПИ за Гатеваи седи тамо. То ми ништа не кошта док људи почети постављање на њега, зар не? Функција Ламбда само сједи тамо. И то ми ништа не кошта до људи почну да је забио. Тако можете видети, као запремине повећава, то је када дођу оптужбе. Ја не водим сервер 7/24. 

Тако сам повући форму доле из канте, и ја пост кроз АПИ Капија за улазак функцију Ламбда. А онда Ламбда Функција каже, знате шта, имам неке ПИИс, неки лични подаци у овим одговорима. Добио сам коментаре које долазе од стране корисника. Имам адресе е-поште. Имам корисничка имена. 

Дозволите ми да поделимо ово. Идем да генеришу неке метаподатака са овом записнику. И ја ћу гурнути метаподатака у ДинамоДБ. И могао шифровање све податке и гурните га у ДинамоДБ ако хоћу. Али то је лакше за мене, у овом користити случај, да настави се пита, Идем да гура сирове податке у шифрованом С3 кофу. Тако да користим изграђен у С3 страни сервера енкрипција и управљање кључевима Амазон Сервис тако да имам кључ који може ротирати на редовним интервалима, и ја могу заштитити ту ПИИ податке као део целог овог процеса рада. 

Шта сам урадио? Управо сам распоредио у целини апликација, и немам сервер. Дакле, оно што је догађај дривен пријаву архитектура ради за вас. 

Сада, ако мислите о употреба случај Ово-- имамо друге кориснике говорим да о овом тачним архитектуре који рун феноменално велике кампање, који гледамо ово и дешава, ох. Јер сада, могу у основи то пусх тамо, нека ту кампању само седети тамо док га лансира, а не морате да бринете о сл о каква инфраструктуре ће бити ту да га подржи. А онда, чим Та кампања је урађено, то је као инфраструктуре само одмах оде јер стварно постоји инфраструктура. То је само код који стоји на Ламбда. То је само податак да седи у ДинамоДБ. То је невероватан начин да изграде апликације. 

ПУБЛИКА: Тако је то више ефемерне него што би то био ако је сачувана на стварној серверу? 

Рицк Хоулихан: Апсолутно. Због тог сервера пример би морао да буде 7/24. То мора да буде на располагању за неко одговорити. Па знате шта? С3 је доступан 7/24. С3 увек одговара. И С3 је врло, врло добар да служи објекте. Ти објекти могу бити ХТМЛ фајл или ЈаваСцрипт датотеке, или шта год желите. Можете да покренете веома богате веб апликација из С3 кашике, и људи. 

И то је идеја овде је да побегне од начина смо да размишљамо о томе. Ми смо навикли да мислимо у Услови серверима и домаћина. Не ради се о то више. Ради се о инфраструктури као код. Примените код на облаку и нека облак га кандидују за вас. И то је оно: АВС покушава да уради. 

ПУБЛИКА: Дакле, твоје злато кутије у средини АПИ-ја Гатеваи нису сервер-као, већ је само-- 

Рицк Хоулихан: Можете мислити о томе као сервера фасаде. Све што је је да ће то трајати ХТТП затражити и карту да другом процесу. То је све што ради. И у овом случају, ми мапирања она на функцију Ламбда. У реду, тако да је све што имам. Mnogo vam hvala. Cenim to. Знам да желимо мало током времена. И надам се да ви момци имате мало информација да можете узети данас. И извињавам се ако сам отишао неке од ваших глава, али постоји много добра основни темељ знања мислим да је веома драгоцено за вас. Хвала вам што сте ме позвали. [АППЛАУСЕ] ПУБЛИКА: [неразумљиво] када сте говорили сте морали да прођете кроз ствари од почетка до краја да се праве вредности или исте вредности, Како би вредности промијенити ако [неразумљиво]. 

Рицк Хоулихан: О, идемпотент? Како би се вредности промене? Па, јер ако нисам покренути то све до краја, онда ја не знам шта мења су направљене у последњем километар. Неће бити Исти подаци, као што сам видела. ПУБЛИКА: Ох, па само нисам добила цео улаз. Рицк Хоулихан: Тако је. Мораш да идеш из почетка до краја, а онда је ће бити доследан држава. Кул. 

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

Рицк Хоулихан: Ја не бих кажу остављајући га иза. 

ПУБЛИКА: Они су били одвојени од до-- 

Рицк Хоулихан: Са документом приступ, тип документа у ДинамоДБ је само мислимо као још један атрибут. То је атрибут који садржи хијерархијска структура података. А онда на упите, можете да користите својства тих објеката које користе Објецт Нотатион. Тако да могу филтрирати отишли ​​у власништво ЈСОН документа. ПУБЛИКА: Дакле, сваки пут сам учинити приступ документ, Могу некако стићи на табулар-- ПУБЛИКА: Апсолутно. Публика: --индекес и ствари само причали. Рицк Хоулихан: Да, индекси и све то, када желите да индексу својства ЈСОН, начин на који ћемо морати да урадимо то је да убаците ЈСОН предмет или документ у Динамо, коју ће користити токове. Потоци би прочитали улаз. Ти би да ЈСОН приговор и да ћеш то рећи у реду, шта је имовина желим да индексу? 

Ви направите дериват табелу. Сада када је тако сада ради. Ми не вам омогућити да индексу директно те особине. 

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

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

ПУБЛИКА: Хвала. 

Рицк Хоулихан: Да, Апсолутно, хвала. ПУБЛИКА: Дакле, то је нека врста Монго састаје Редис цлассиферс. 

Рицк Хоулихан: Да, много је тако. То је добар опис за то. Кул.