[Гуляе музыка] РВК Хулихэном: Добра. Прывітанне, усім. Мяне клічуць Рык Houlihan. Я старэйшы асноўнай Рашэнні архітэктар AWS. Я засяроджваюся на NoSQL і Тэхналогіі DynamoDB. Я сёння тут, каб пагаварыць з Вы крыху пра іх. 

Мой фон у першую чаргу ў пласце дадзеных. Я правёў палову сваёй распрацоўкі Кар'ера пісаць базу дадзеных, доступу да дадзеных, рашэнні для розных ужыванняў. Я быў у Cloud віртуалізацыі на працягу прыкладна 20 гадоў. Таму, перш чым воблака Воблака, мы прывыклі называць яго карыснасць вылічэнняў. А ідэя была, гэта як PG & E, вы плаціце за тое, што вы выкарыстоўваеце. Сёння мы называем гэта воблака. 

Але на працягу многіх гадоў, я працаваў на пару кампаній Вы верагодна ніколі не чулі. Але я склаў спіс тэхнічных дасягнення, я думаю, вы б сказаць. У мяне восем патэнтаў у сістэмах Cloud Віртуалізацыя, мікрапрацэсар дызайн, Комплекс апрацоўкі падзей, і іншых галінах, а таксама. 

Так у гэтыя дні, я спынюся ў асноўным на NoSQL тэхналогіі і новае пакаленне базы дадзеных. І гэта, як правіла тое, што я збіраюся каб быць тут і размаўляю з вамі сёння а. Так што вы можаце чакаць ад гэтай сесіі, мы пойдзем праз сцісла Гісторыя апрацоўкі дадзеных. Гэта заўсёды карысна зразумець, адкуль мы прыйшлі і чаму мы, дзе мы знаходзімся. І мы будзем казаць трохі Крыху пра тэхналогіі NoSQL з фундаментальнай пункту гледжання. 

Мы трапім у некаторых вантробы DynamoDB. DynamoDB ня AWS ў ня водар. Гэта цалкам кіраваны і сервернае рашэнне NoSQL. І мы будзем казаць крыху пра табліцы структура, API, тыпы дадзеных, індэксы, і некаторыя з унутраных гэтай DynamoDB тэхналогіі. Мы ўвойдзем у некаторыя канструкцыі шаблоны і лепшыя практыкі. Мы пагаворым аб тым, як выкарыстоўваць гэтую тэхналогію для некаторых сучасных прыкладанняў. І тады мы будзем казаць трохі аб эвалюцыі або з'яўленне новай парадыгмы ў праграмаванні званыя прыкладання кіраваныя падзеямі і як DynamoDB гуляе ў тым, што, як добра. І мы выйдзем вам крыху абмеркаванне Эталонная архітэктура такім чынам, мы можам казаць аб некаторых спосабы можна выкарыстоўваць DynamoDB. 

Такім чынам, спачатку off-- гэта пытанне Я чуў шмат ёсць, што база дадзеных. Шмат людзей думаюць, што яны ведаю, што база дадзеных. Калі вы Google, вы ўбачыце, што гэта. Гэта структураваны набор дадзеных, якія захоўваюцца ў кампутары, асабліва той, які даступны ў розных напрамках. Я мяркую, што гэта добры вызначэнне сучаснай базы дадзеных. Але я не люблю яго, таму што гэта мае на ўвазе некалькі рэчаў. Гэта азначае, структуру. І гэта азначае, што ён знаходзіцца на кампутары. І не зрабіў базы дадзеных заўсёды існуе на кампутарах. Базы дадзеных сапраўды існаваў у многіх адносінах. 

Такім чынам, лепшае вызначэнне База дадзеных нешта накшталт гэтага. База дадзеных арганізаваны механізм захоўвання, кіравання, і здабывання інфармацыі. Гэта з About.com. Так што я хацеў гэтага, таму што гэта сапраўды перамовы аб базе даных быўшы сховішча, сховішча Інфармацыя, не абавязкова тое, што сядзіць на кампутары. І на працягу ўсёй гісторыі, мы не заўсёды кампутараў. 

Цяпер, калі я прашу сярэднім Распрацоўшчык сёння тое, што база дадзеных, вось і адказ я атрымліваю. Дзесьці я магу прытрымлівацца рэчаў. Дакладна? І гэта праўда. Але гэта сумна. Паколькі база дадзеных сапраўды аснова сучаснага прыкладання. Гэта аснова з кожнага прыкладання. І, як вы будуеце, што базы дадзеных, як структураваць што дадзеныя будзе дыктаваць, як гэта Дадатак выконвае, як вы маштабе. 

Так шмат маёй працы сёння мае справу з тым, што адбываецца, калі распрацоўшчыкі гэты падыход і справу з наступствамі прыкладання, якое Цяпер маштабавання за арыгінал Мэта і пакуты ад дрэннага дызайну. Так, мы спадзяемся, калі вам хады сёння, вы будзеце ёсць некалькі інструментаў, у Ваш пояс, які будзе трымаць вас ад прыняцця тых жа памылак. Добра. Такім чынам, давайце пагаворым аб трохі тэрміны тэхналогіі баз дадзеных. Я думаю, што я прачытаў артыкул не так даўно і ён сказаў, што-то на lines-- гэта вельмі паэтычна заяве. Гэта сказаў, што гісторыя дадзеных апрацоўка поўны высокіх вадзяных знакаў багацця дадзеных. ДОБРА. Зараз, я думаю, што гэта свайго роду праўда. Але я на самой справе глядзець на гэта, як Гісторыя на самай справе запоўненыя з высокай вадзяной знак ціску дадзеных. Паколькі хуткасць перадачы дадзеных праглынанне не ідзе ўніз. Гэта толькі ідзе ўверх. 

І інавацыі адбываецца, калі мы бачым ціск дадзеных, які гэта колькасць дадзеных, якія у цяперашні час у паступае ў сістэму. І гэта не можа быць апрацаваны эфектыўна ні ў часе, або ў кошту. І вось, калі мы пачынаем паглядзець на ціск дадзеных. 

Таму, калі мы глядзім на Першая база дадзеных, гэта гэта той, які быў паміж нашымі вушамі. Мы ўсе народжаныя з ім. Гэта добрая база. Ён мае высокую даступнасць. Гэта заўсёды. Вы заўсёды можаце атрымаць яго. 

Але гэта адзін карыстальнік. Я не магу падзяліцца сваімі думкамі з вамі. Вы не можаце сабрацца з думкамі калі вы хочаце іх. І іх abilitiy не так добра. Мы забываемся рэчы. Раз-пораз, адзін з нас лісце і пераходзіць да іншага існавання і мы страцім усё што было ў гэтай базе дадзеных. Так што не ўсё так добра. 

І гэта працавала добра на працягу доўгага часу калі мы былі яшчэ ў дзень калі ўсе мы сапраўды трэба ведаць гэта куды мы ідзем, каб пайсці на заўтра ці там, дзе мы збіраем лепшую ежу. Але, як мы пачалі расці як цывілізацыя і ўрад пачатак прыйсці ў быццё, і бізнэс пачаў развівацца, мы пачалі разумець, мы трэба крыху больш, чым мы маглі б у нашай галаве. Усё ў парадку? 

Нам патрэбна сістэм запісу. Нам трэба месцы, каб быць у стане захоўваць дадзеныя. Такім чынам, мы пачалі пісаць дакументы, стварэння бібліятэк і архіваў. Мы пачалі распрацоўвае Сістэма бухгалтарскіх кніга. І, што сістэма падліку бухгалтарскай кнігі пабег свет на працягу многіх стагоддзяў, і, магчыма, нават тысячагоддзяў, як мы накшталт выраслі да пункту дзе, што загрузка дадзеных пераўзышлі здольнасць гэтых сістэм каб мець магчымасць утрымліваць яго. 

І гэта на самай справе адбылося ў 1880 годзе. Дакладна? У 1880 перапісу насельніцтва ЗША. Гэта сапраўды, дзе паварот паказваюць сучаснай апрацоўцы дадзеных. Гэта кропка, у якіх аб'ём дадзеных што ў цяперашні час, сабраных Урад ЗША патрапіў у кропку, дзе спатрэбілася восем гадоў, каб апрацаваць. 

Цяпер, восем years-- як Вы ведаеце, перапісу працуе кожныя 10 years-- так што гэта Цалкам відавочна, што па часе мы атрымаў перапісу 1890, колькасць дадзеных, якія збіраўся быць апрацаваны урадам было збіраецца перавышаць 10 гадоў, што гэта спатрэбіцца, каб запусціў новую перапісу. Гэта было праблемай. 

Такім чынам, хлопец па імі Герман Холлерит прыйшлі разам і ён вынайшаў блок запісу ўдар карты, чытач перфакарты, перфакарты табулятара, і супастаўленне механізмы для гэтай тэхналогіі. І, што кампанія, якая ён сфармаваў на Час, разам з парай іншых, фактычна стаў адным з слупоў невялікая кампанія, мы ведаем сёння называецца IBM. 

Так IBM першапачаткова была ў бізнес базы дадзеных. І гэта сапраўды тое, што яны зрабілі. Яны зрабілі апрацоўку дадзеных. 

Як жа так распаўсюджваннем ўдар карты, геніяльны механізмы быць у стане выкарыстаць што Тэхналогія апытання адсартаваныя выніковых набораў. Вы можаце ўбачыць у гэтай карціне ёсць у нас ёсць little-- гэта крыху small-- але вы можаце бачыць вельмі дасціпны механізм механічны дзе ў нас ёсць ўдар картачнай калоды. І хто-то бярэ трохі адвёртка і прытрымлівацца праз Слоты і падняўшы яе каб атрымаць, што матч, што Сартаваць набор вынікаў. 

Гэта аб'яднанне. Мы робім гэта ўвесь час сёння ў кампутары, дзе вы яго ў базу дадзеных. Мы выкарыстоўвалі, каб зрабіць гэта ўручную, праўда? Людзі ставяць гэтыя рэчы разам. І гэта было распаўсюджванне з гэтых перфакарт у тое, што мы назвалі барабанаў дадзеных і барабаны дадзеных, папяровыя стужкі. 

Апрацоўка дадзеных прамысловасці прынялі ўрок ад гульцоў фартэпіяна. Гулец піяніна таму на паварот стагоддзя выкарыстоўваць выкарыстоўваць папяровыя барабаны з пазамі распавядаць ягоныя, якія клавішы, каб гуляць. Так што тэхналогіі быў адаптаваны у канчатковым выніку, каб захаваць лічбавыя дадзеныя, таму што яны маглі б паставіць гэтыя дадзеныя на тыя паперы істужачных барабанаў. 

Цяпер, у выніку чаго дадзеныя быў actually-- як доступ гэтыя дадзеныя непасрэдна быў залежыць ад таго, як вы захавалі яго. Так што, калі я паклаў дадзеныя на стужцы, Я меў доступ да дадзеных, лінейна. Я павінен быў згарнуць ўвесь Стужка для доступу да ўсіх дадзеных. Калі я стаўлю дадзеныя ў ўдар карты, я мог бы атрымаць доступ да яго ў трохі больш выпадковым мода, можа быць, не так хутка. 

Але былі абмежаванні ў тым, як мы Доступ да дадзеных на аснове, як было захавана. І так гэта было праблемай ўдаючыся ў 50-х. Зноў жа, мы можам пачаць бачыць, што, як мы распрацоўка новых тэхналогій для апрацоўкі дадзеныя, правільна, гэта адкрывае дзверы для новых рашэнняў, для новых праграм, новая прыкладання для гэтых дадзеных. І на самай справе, кіраванне можа быць прычынай Таму мы распрацавалі некаторыя з гэтых сістэм. Але справа хутка стаў кіроўца за эвалюцыі сучаснага базе дадзеных і сучасная файлавая сістэма. 

Такім чынам, наступная рэч, што падышоў было ў 50-х быў файлавая сістэма і Развіццё выпадковай захоўвання доступу. Гэта было прыгожа. Цяпер, усе раптам, мы можам паставіць нашу файлы ў любым месцы на гэтых жорсткіх дыскаў і мы можам атрымаць доступ да гэтай інфармацыі ў выпадковым парадку. Мы можам разабраць, што Інфармацыя з файлаў. І мы вырашылі ўсё ў свеце Праблемы з апрацоўкай дадзеных. 

І доўжылася каля 20 ці 30 гадоў да эвалюцыі рэляцыйнай базы дадзеных, якая калі свет вырашыў, што мы ў цяперашні час трэба мець сховішча, перамагае разрастанне дадзеных па файле Сістэмы, якія мы пабудавалі. Дакладна? Занадта шмат дадзеных, размеркаваных ў занадта шмат месца, дэ-дубліраванне дадзеных, і кошт захоўвання быў велізарны. 

У 70-х, самы дарагі рэсурс што кампутар быў быў захоўвання. Працэсар быў разглядаць як фіксаваную кошт. Калі я купляю скрынку, працэсар робіць некаторую працу. Гэта збіраецца быць спінінг Ці гэта на самай справе ці не. Гэта сапраўды панесеных расходаў. 

Але тое, што варта было мне як бізнес захоўвання. Калі ў мяне ёсць, каб купіць больш дыскаў у наступным месяц, што гэта рэальны кошт, што я плаціць. І захоўвання каштуе дорага. 

Цяпер мы хутка наперад 40 гадоў і ў нас ёсць іншая праблема. Вылічальных цяпер самы дарагі рэсурс. Захоўванне танна. Я маю на ўвазе, мы можам пайсці куды-небудзь на воблака, і мы можам знайсці таннае захоўванне. Але тое, што я не магу знайсці танны вылічальны. 

Так эвалюцыі сёння тэхналогіі, тэхналогіі баз дадзеных, сапраўды сканцэнтраваны вакол размеркаваныя базы дадзеных якія не пакутуюць ад і той жа тып шкалы Абмежаванні рэляцыйных баз дадзеных. Мы пагаворым крыху пра што гэта на самай справе азначае. 

Але адна з прычын, і кіроўца за this-- мы казалі пра ціск дадзеных. Ціск дадзеных з'яўляецца тое, які прыводзіць інавацый. І калі вы паглядзіце на больш за апошнія пяць гадоў, гэта схема, якія менавіта дадзеныя нагрузка па агульнай прадпрыемствы Падобна на тое, у апошнія пяць гадоў. 

І агульнае правіла гэтыя days-- калі вы ідзяце Google-- 90% ад дадзеных, якія мы захоўваем сёння, і гэта было генеруецца на працягу апошніх двух гадоў. ДОБРА. Цяпер, гэта не тэндэнцыя, што новага. Гэта тэндэнцыя, якая была выходзячы за 100 гадоў. З тых часоў, Холлерит распрацавала перфакарты, мы будавалі сховішчы дадзеных і збор дадзеных на фенаменальныя тэмпы. 

Так, за апошнія 100 гадоў, мы бачылі гэтую тэндэнцыю. Гэта не збіраецца мяняць. Прасоўваючыся наперад, мы будзем бачыць гэта, калі не паскараецца тэндэнцыя. І вы можаце бачыць, як гэта выглядае. 

Калі бізнэс у 2010 годзе быў адзін тэрабайт дадзеных пад кіраваннем, сёння гэта азначае, што яны кіраванне 6,5 петабайт дадзеных. Гэта 6500 разоў больш дадзеных. І я ведаю, што гэта. Я працую з гэтымі прадпрыемствамі кожны дзень. Пяць гадоў таму я будзе гаварыць з кампаніямі хто б пагаварыць са мной пра што боль гэта кіраваць тэрабайтамі дадзеных. І яны будуць гаварыць мне пра тое, як мы бачым, што гэта, верагодна, будзе быць петабайт ці два на працягу некалькіх гадоў. 

Гэтыя ж кампаніі сёння я сустракаюся з, і яны кажуць мне пра Праблема ці ёсць які мае кіраванне дзясяткі, 20 петабайт дадзеных. Так выбух Дадзеныя ў прамысловасці вядзе велізарная патрэба ў больш дасканалых рашэнняў. І рэляцыйная база дадзеных з'яўляецца проста не жыць да попыту. 

І так ёсць лінейны Карэляцыя паміж ціскам дадзеных і тэхнічныя інавацыі. Гісторыя паказвае нам, гэта, што з цягам часу, кожны раз, калі аб'ём дадзеных які павінен быць апрацаваны перавышае прапускную здольнасць сістэмы апрацаваць яго ў разумныя тэрміны або па разумнай цане, то новыя тэхналогіі вынайдзены, каб вырашыць гэтыя праблемы. Гэтыя новыя тэхналогіі, у сваю чаргу, адкрыць дзверы на іншы набор праблем, які збірае яшчэ больш дадзеных. 

Зараз, мы не збіраемся спыняцца на гэтым. Дакладна? Мы не збіраемся спыняцца на гэтым. Чаму? Таму што вы не можаце ведаць усё што трэба ведаць ва Сусвету. І да таго часу, як мы былі жывыя, на працягу ўсёй гісторыі чалавека, мы заўсёды вымушаныя ведаць больш. 

Так здаецца, што кожны цаля мы рухаемся па шляху навуковага адкрыцця, мы множання колькасці дадзеных што мы павінны апрацаваць па экспаненце як мы раскрыць больш і больш і больш аб унутраных жыцця, пра тое, як працуе Сусвет, пра кіраванне навуковае адкрыццё, і вынаходніцтва, што мы робім сёння. Аб'ём дадзеных, проста пастаянна павялічваецца. Так будучы ў стане мець справу з Гэтая праблема велізарная. 

Так адна з рэчаў, мы глядзім, як, чаму NoSQL? Як NoSQL вырашыць гэтую праблему? Ну, рэляцыйныя базы дадзеных, Structured Query Language, SQL--, што гэта сапраўды канструкцыя з рэляцыйная database-- гэтыя рэчы аптымізавана для захоўвання. 

Таму ў 70-я гады, зноў жа, Дыск каштуе дорага. Аб падрыхтоўцы практыкаванні захоўвання на прадпрыемстве ніколі не сканчаецца. Я ведаю. Я жыў яго. Я напісаў драйвер сховішчы для enterprised суперсервера кампанія таму ў 90-ых. І ніжняя лінія стэлажы іншы Масіў захоўвання дадзеных была толькі тое, што адбылося кожны дзень на прадпрыемстве. І гэта ніколі не спыніўся. Вышэйшую захоўвання шчыльнасць, попыт за вялікай шчыльнасці захоўвання, і для больш эфектыўнага захоўвання devices-- гэта ніколі не спыніўся. 

І NoSQL гэта выдатны тэхналогія таму што ён нармалізуе дадзеныя. Гэта дэ-дублюе дадзеныя. Гэта змяшчае дадзеныя ў структуру, якая агностыку кожнаму мадэль доступу. Некалькі прыкладанняў могуць ударыць, што Базы дадзеных SQL, запусціць спецыяльныя запыты, і атрымаць дадзеныя ў форме, што яны трэба апрацаваць для іх працоўных нагрузак. Гэта гучыць фантастычна. Але сутнасць у тым, з якой-небудзь Сістэма, калі гэта агностыку, каб усе, ён аптымізаваны для нічога. ДОБРА? 

І гэта тое, што мы атрымліваем з рэляцыйная база дадзеных. Ён аптымізаваны для захоўвання. Гэта нармалізуецца. Гэта рэляцыйная. Ён падтрымлівае спецыяльныя запыты. І яго і маштабуецца яго па вертыкалі. 

Калі мне трэба, каб атрымаць вялікую базу дадзеных SQL або больш магутны SQL базы дадзеных, Я іду купіць большы кавалак жалеза. ДОБРА? Я працаваў з многімі кліентаў што прайшлі праз буйныя абнаўлення у іх SQL інфраструктуры толькі каб высветліць, шэсць месяцаў праз, яны зноў вы ўдару ў сцяну. І адказ ад Oracle або MSSQL ці хто-небудзь яшчэ, гэта атрымаць больш акно. Ну, рана ці позна, вы не можаце купіць больш акно, і гэта рэальная праблема. Мы павінны на самай справе нешта змяніць. Дык дзе ж гэта працуе? Ён добра працуе ў аўтаномным аналітыка, нагрузкі OLAP-тыпу. І гэта сапраўды, дзе SQL належыць. Цяпер, ён выкарыстоўваецца сёння ў многіх онлайн апрацоўку транзакцый тыпу прыкладання. І гэта выдатна працуе на пэўны ўзровень ўтылізацыі, але гэта проста не маштабаваць так, што NoSQL робіць. І мы будзем казаць трохі крыху аб тым, чаму, што ёсць. 

Цяпер, NoSQL, з другога боку, больш аптымізаваны для вылічэнняў. ДОБРА? Гэта не незалежным ад шаблон доступу. Гэта тое, што мы называем дэ-нармалізуецца структура або іерархічную структуру. Дадзеныя ў рэляцыйнай базе дадзеных аб'ядналіся з некалькімі сталамі вырабляць выгляд, што вам трэба. Дадзеныя ў базе дадзеных NoSQL ў захоўваецца ў дакуменце, які змяшчае іерархічную структуру. Усе дадзеныя, якія звычайна аб'ядналіся, каб вырабіць гэтую пункт гледжання захоўваюцца ў адным дакуменце. І мы будзем казаць крыху пра як гэта працуе ў пары графікаў. 

Але ідэя тут у тым, што вы захоўваеце Вашы дадзеныя як гэтыя асобнікі выглядам. ДОБРА? Вы маштабаваць па гарызанталі. Дакладна? Калі мне трэба павялічыць Памер майго NoSQL кластара, Мне не трэба, каб атрымаць вялікую скрынку. Я атрымліваю яшчэ адну скрынку. І я іх разам кластар, і я магу Шардэн гэтыя дадзеныя. Мы пагаворым крыху пра тое, што Sharding ёсць, быць магчымасць маштабавання гэтую базу дадзеных па некалькіх фізічным прыладам і выдаліць бар'ер, патрабуе, каб я маштабавання па вертыкалі. 

Так што на самай справе пабудаваны для онлайн апрацоўкі транзакцый і маштаб. Там вялікая розніца тут паміж справаздачнасці, праўда? Справаздачнасць, я не ведаю, пытанні, якія я збіраюся задаць. Дакладна? Reporting-- калі хтосьці з мой аддзел маркетынгу хоча просто-- колькі з маіх кліентаў ёсць гэтая канкрэтная характарыстыка, хто купіў у гэтым day-- я не ведаю тое, што запыт яны збіраюцца спытаць. Таму мне трэба, каб быць агностыкам. 

Цяпер, у рэжыме онлайн транзакцыйных прыкладанняў, Я ведаю, якія пытанні я пытаюся. Я пабудаваў прыкладанне для вельмі спецыфічны працоўны працэс. ДОБРА? Так што, калі аптымізаваць дадзеныя захоўваць у падтрымку гэтага працоўнага працэсу, гэта будзе хутчэй. І вось чаму NoSQL можа сапраўды паскорыць дастаўку з гэтых відаў паслуг. Добра. 

Такім чынам, мы збіраемся, каб патрапіць у трохі тэорыі тут. І некаторыя з вас, вашы вочы можа вярнуцца няшмат. Але я паспрабую, каб захаваць яго таксама высокі ўзровень, як я магу. Так што, калі вы знаходзіцеся ў праекце Кіраванне, ёсць канструкцыя называецца трохкутнік абмежаванняў. ДОБРА. Трохкутнік абмяжоўвае дыктату Вы не можаце мець усе ўвесь час. Не можаце мець свой пірог і з'есці яго занадта. Такім чынам, у кіраванні праектамі, што трохкутнік абмежаванні, што вы можаце мець гэта танна, Вы можаце мець гэта хутка, ці вы можаце мець яго добра. Выберыце два. Таму што вы не можаце мець усе тры. Дакладна? ДОБРА. 

Такім чынам, вы чуеце пра гэта шмат. Гэта патройны абмежаванне, трохкутнік патройны абмежаванні, або жалезны трыкутнік з'яўляецца oftentimes-- калі вы кажаце з мэнэджэрамі праекта, яны будуць гаварыць пра гэта. Цяпер, базы дадзеных маюць самастойна жалезны трыкутнік. І жалезны трыкутнік дадзеных гэта тое, што мы называем Тэарэма CAP. ДОБРА? 

Тэарэма CAP дыктуе як базы дадзеных працуюць пад вельмі спецыфічных умовах. І мы будзем казаць аб што гэта ўмова. Але тры пункту трыкутніка, так бы мовіць, з'яўляюцца З, кансістэнцыя. ДОБРА? Такім чынам, у САР, ўзгодненасць азначае, што ўсе кліенты, якія могуць атрымаць доступ да базы дадзеных заўсёды будзе мець вельмі адпавядае прадстаўленне даных. Ніхто не збіраецца ўбачыць дзве розныя рэчы. ДОБРА? Калі я бачу, базы дадзеных, Я бачу тое ж самае прадстаўленне як мой партнёр, які бачыць тую ж базу дадзеных. Вось паслядоўнасць. 

Наяўнасць азначае, што калі онлайн базы дадзеных, калі гэта можа быць дасягнута, што ўсе кліенты будуць заўсёды умець чытаць і пісаць. ДОБРА? Так кожны кліент, які можа чытаць базу дадзеных заўсёды змогуць чытання Дадзеныя дадзеных і пісаць. І калі гэта так, гэта даступны сістэма. 

І трэці пункт, што мы называем памяркоўнасці раздзелаў. ДОБРА? Азначае памяркоўнасць раздзел што сістэма працуе добра нягледзячы фізічнай сеткі Перагародкі паміж вузламі. ДОБРА? Так вузлы ў кластары не можа казаць адзін з адным, што адбываецца? Добра. 

Так рэляцыйныя базы дадзеных, выберите-- Вы можаце выбраць два з іх. ДОБРА. Так рэляцыйныя базы дадзеных абярыце быць паслядоўным і даступныя. Калі падзел адбываецца паміж ў вузлы DataNode ў сховішча дадзеных, збой базы дадзеных. Дакладна? Гэта проста ідзе ўніз. ДОБРА. 

І вось чаму яны маюць расці з вялікімі скрынямі. Дакладна? Таму што, як правіла, no--, кластар базы дадзеных, ёсць не вельмі многія з іх якія працуюць такім чынам. Але большасць баз дадзеных маштабу па вертыкалі ў адным акне. Таму што яны павінны быць паслядоўнай і даступны. Калі раздзел былі быць уведзены, то вам давядзецца зрабіць выбар. Вы павінны зрабіць выбар паміж быць паслядоўным і даступныя. 

І гэта тое, што робяць базы дадзеных NoSQL. Добра. Такім чынам, база дадзеных NoSQL, яго пастаўляецца ў двух варыянтах. Мы have-- добра, гэта прыходзіць у шматлікіх разнавіднасцях, але ён прыходзіць з двума асноўнымі characteristics-- што мы называем CP базы дадзеных або паслядоўнай і падзел талерантнасці Сістэма. Гэтыя хлопцы робяць выбар, што, калі вузлы губляюць кантакт адзін з адным, мы не збіраемся, каб дазволіць людзі больш пісаць. ДОБРА? 

Да гэтага раздзелу не будуць выдаленыя, запісы доступ заблякаваны. Гэта азначае, што яны не даступныя. Яны паслядоўныя. Калі мы бачым, што раздзел надаць сабе, мы зараз адпавядае, таму што мы не збіраемся каб змены дадзеных на два боку перагародкі самастойна адзін ад аднаго. Мы павінны аднавіць сувязь перад любым абнаўленнем дадзеныя дазволілі. ДОБРА? 

На наступны водар будзе сістэма А.П., ці даступны і размяркоўваюць Сістэма допуску. Гэтыя хлопцы не хвалюе. Дакладна? Любы вузел, які атрымлівае пісаць, мы возьмем яго. Так што я тыражаванне мае дадзеныя па некалькіх вузлах. Гэтыя вузлы атрымаць кліент, кліент прыходзіць у, кажа, што я збіраюся напісаць некаторыя дадзеныя. Вузел не гаворыць, не праблема. Вузел побач з ім атрымлівае ад запісу на той жа запісу, ён збіраецца сказаць не праблема. Дзесьці на заднім канцы, што дадзеныя збіраецца паўтарыць. А потым хто-то збіраецца рэалізаваць, э-э-о, яны зразумеюць, сістэма, э-э-о, там было абнаўленне да двух бакоў. Што мы робім? І тое, што яны зрабіць, гэта яны робяць тое, што дазваляе ім вырашыць гэтую стан дадзеных. І мы будзем казаць аб што ў наступным графіку. 

Рэч, каб адзначыць тут. І я не збіраюся занадта шмат у гэтым, таму што гэта трапляе ў глыбокай тэорыі дадзеных. Але ёсць транзакцый рамкі, працуе ў рэляцыйнай сістэме, дазваляе мне смела зрабіць абнаўлення некалькім суб'ектам ў базе дадзеных. І гэтыя абнаўлення будуць адбывацца ўсё адразу ці не на ўсіх. І гэта называецца ACID транзакцый. ДОБРА? 

Кіслата дае нам атамарнага, ўзгодненасць, ізаляцыя і даўгавечнасць. ДОБРА? Гэта азначае, што атамныя, здзелкі, усё мае абнаўлення альбо здарыцца, альбо няма. Ўзгодненасць азначае, што База дадзеных будзе заўсёды быць прыведзены ў паслядоўнай стан пасля абнаўлення. Я ніколі не пакіне базу дадзеных у дрэнны стан пасля прымянення абнаўлення. ДОБРА? 

Так што гэта крыху адрозніваецца чым кансістэнцыі CAP. Кансістэнцыя CAP азначае, што ўсе мае кліенты заўсёды могуць бачыць дадзеныя. Кіслата ўзгодненасць азначае, што, калі здзелка будзе зроблена, дадзеныя добра. Мае адносіны ўсё добра. Я не збіраюся, каб выдаліць бацькоўскую радок і пакінуць кучу дзяцей-сірот У нейкай іншай табліцы. Гэта не можа адбыцца, калі я стасуюцца у кіслай аперацыі. 

Ізаляцыя азначае, што здзелкі заўсёды будзе адбывацца адзін за адным. Канчатковым вынікам дадзеных будзе тое ж самае стан а калі гэтых здзелак якія былі выпушчаныя адначасова былі выкананы паслядоўна. Так што гэта паралелізм кантроль у базу дадзеных. Так у прынцыпе, я не магу павялічыць тое ж самае значэнне ў два разы з двума аперацыямі. 

Але калі я кажу дадаць 1 да гэтага значэння, і дзве здзелкі прыходзяць у і паспрабаваць зрабіць гэта, адзін гэта збіраецца атрымаць там першым а другі-х збіраецца патрапіць пасля. Такім чынам, у рэшце рэшт, я дадаў два. Вы бачыце, што я маю на ўвазе? ДОБРА. 

Трываласць даволі простая. Калі здзелка прызнаецца, што гэта будзе там, нават калі збой сістэмы. Пры тым, што сістэма аднаўляецца, што здзелка, было здзейснена на самай справе адбываецца, каб быць там. Дык вось гарантыі кіслаты здзелак. Тыя, даволі добрыя гарантыі мець у базе даных, але яны прыходзяць на той кошту. Дакладна? 

Таму што праблемы з гэтым база калі існуе разбіццё дадзеных у набор, я павінен прыняць рашэнне. Я збіраюся мець, каб Абнаўлення на адной або іншага боку. І калі гэта адбудзецца, а то я не збіраюся больш каб быць у стане падтрымліваць гэтыя характарыстыкі. Яны не будуць адпавядаць. Яны не будуць ізаляваныя. Гэта дзе гэта ламае для рэляцыйных баз дадзеных. Гэта прычына, рэляцыйная Базы дадзеных маштабавання па вертыкалі. 

З іншага боку, мы маем тое, што называецца тэхналагічная база. І гэта вашы NoSQL баз дадзеных. Добра. Такім чынам, мы маем CP, базы дадзеных AP. І гэта тое, што вы называеце асноўным даступныя, мяккі дзяржава, у канчатковым рахунку, паслядоўным. ДОБРА? 

У асноўным даступныя, таму што яны раздзел памяркоўна. Яны заўсёды будуць там, нават калі ёсць падзелу сеткі паміж вузламі. Калі я магу пагаварыць з вузлом, я будзе ў стане прачытаць дадзеныя. ДОБРА? Я не заўсёды можа быць у стане напісаць дадзеных, калі я адзінай платформы. Але я буду ў стане прачытаць дадзеныя. 

Мяккая стан паказвае што, калі я прачытаў, што дадзеныя, яна не можа быць такі ж, як іншыя вузлы. Калі права было выдадзена на вузле дзесьці ў кластары і гэта не реплицируются папярок Кластар жа, калі я прачытаў, што дадзеныя, што дзяржава не можа быць паслядоўным. Тым не менш, ён будзе у рэшце рэшт паслядоўным, Гэта азначае, што, калі запісу зроблены да сістэмы, ён будзе реплицировать вузлоў. І ў рэшце рэшт, што дзяржава будуць прыведзены ў парадак, і гэта будзе адпавядаць стан. 

Цяпер, тэарэма CAP сапраўды гуляе толькі ў адным стане. Гэта ўмова, калі гэта адбудзецца. Таму што кожны раз, калі ён працуе ў нармальны рэжым, няма падзелу, усё ў паслядоўнай і даступныя. Вы толькі турбавацца аб CAP калі ў нас ёсць гэты раздзел. Так што тыя, рэдкія. Але, як сістэма рэагуе, калі тыя адбываюцца дыктаваць, які тып сістэмы мы маем справу з. 

Такім чынам, давайце зірнем на тое, што які выглядае як для АТ сістэм. ДОБРА? Сістэмы AP бываюць двух відаў. Яны прыходзяць ў водары, які з'яўляецца Майстар, 100%, заўсёды даступныя. І яны прыходзяць у іншы водар, які кажа Вы ведаеце, што я збіраюся турбавацца пра гэта раздзелаў рэчы калі фактычны падзел адбываецца. У адваротным выпадку, там будзе асноўным вузлы, якія збіраецца распачаць правоў. ДОБРА? 

Так што, калі мы нешта накшталт Касандры. Касандра б быць майстрам майстар, давайце мне напісаць да любога вузла. Дык што ж адбываецца? Так у мяне ёсць аб'ект у База дадзеных, існуе на двух вузлоў. Назавем гэты аб'ект S. Такім чынам, мы маем стан для S. У нас ёсць некаторыя аперацыі на S, што працягваюцца. Касандра дазваляе мне напісаць некалькім вузлах. Так што давайце казаць, што я атрымліваю пісаць для з двума вузламі. Ну, тое, што ў канчатковым выніку адбываецца гэта мы называем гэта падзея раздзелаў. Там не можа быць фізічная сетку раздзелаў. Але з-за дызайну сістэмы, гэта на самай справе, як толькі разбіцця як я атрымаць запіс на двух вузлах. Гэта не прымушае мяне напісаць усё праз адзін вузел. Я пішу на двух вузлах. ДОБРА? 

Так што цяпер у мяне ёсць два стану. ДОБРА? Што адбудзецца рана ці позна, там будзе падзея рэплікацыі. Там будзе тое, што мы называецца раздзел аднаўлення, які дзе гэтыя два дзяржавы вярнуцца разам і там будзе алгарытм які працуе ў базе дадзеных, вырашае, што рабіць. ДОБРА? Па змаўчанні, апошняе абнаўленне выйграе ў большасці сістэм AP. Так што, як правіла, Алгарытм па змаўчанні, тое, што яны называюць функцыю зваротнага выкліку Функцыя, тое, што будзе выклікацца, калі гэта ўмова выяўлена выканаць некаторую логіку вырашыць, што канфлікту. ДОБРА? Зваротны выклік па змаўчанні і па змаўчанні распознаватель ў большасці баз дадзеных AP гэта, думаю, што, пазнака выйграе. Гэта было апошняе абнаўленне. Я збіраюся паставіць гэта абнаўленне там. Я магу скінуць гэты запіс, што я скідалі прэч ў часопісе аднаўлення так што карыстальнік можа вярнуцца пазней і сказаць, эй, адбылося сутыкненне. Што здарылася? І вы можаце скінуць запіс усе сутыкнення і адкаты і паглядзець, што адбываецца. 

Цяпер, як карыстальнік, вы можаце таксама ўключаць у сябе логіку ў гэтай зваротнага выкліку. Такім чынам, вы можаце змяніць зваротнага выкліку аперацыі. Вы можаце сказаць: эй, я хачу для ліквідацыі гэтай інфармацыі. І я хачу, каб паспрабаваць аб'яднаць гэтыя два запісы. Але гэта да вас. База дадзеных не ведаю, як зрабіць, што па змаўчанні. Большасць часу, адзінае, што базы дадзеных ведае, як зрабіць, гэта сказаць, гэты быў апошні альбом. Гэта той, які збіраецца выйграць, і гэта значэнне я збіраюся ставіць. Пасля гэтага аднаўлення раздзелаў і рэплікацыі, у нас ёсць дзяржава, якое Цяпер S прэм'ер, які з'яўляецца зліццё стан усіх гэтых аб'ектаў. Так сістэмы AP ёсць гэта. Сістэмы CP ня трэба каб турбавацца пра гэта. Таму што як толькі прыходзіць раздзел у гульню, яны проста перастаць прымаць піша. ДОБРА? Так што гэта вельмі лёгка справу з быць паслядоўным калі вы не прымаць якія-небудзь абнаўлення. Вось з сістэмамі CP зрабіць. Добра. 

Такім чынам, давайце трохі пагаворым трохі пра мадэлі доступу. Калі мы гаворым пра NoSQL, гэта ўсё аб мадэлі доступу. Цяпер, у SQL ёсць спецыяльная запыты. Гэта рэляцыйнае сховішча. Мы не павінны хвалявацца аб мадэлі доступу. Я пішу вельмі складаны запыт. Гэта ідзе і атрымлівае дадзеныя. Гэта тое, што гэта выглядае як нармалізацыя. 

Такім чынам, у дадзеным канкрэтным структуры, мы глядзім на каталог прадукцыі. У мяне ёсць розныя віды прадукцыі. У мяне ёсць кнігі. Я ёсць альбомы. У мяне ёсць відэа. Адносіны паміж прадуктамі і любы з гэтых кніг, альбомаў, і відэа сталы 1: 1. Усё ў парадку? Я атрымаў код прадукту, і што адпавядае ID у кнізе, альбом або відэа. ДОБРА? Гэта стаўленне 1: 1 па гэтых табліцах. 

Цяпер, усе яны books-- ёсць, корань ўласцівасці. Няма праблем. Гэта цудоўна. Адзін-да-аднаму адносіны, я ўсё дадзеныя мне трэба, каб апісаць гэтую кнігу. Albums-- альбомы трэкі. Гэта тое, што мы называем адзін да многіх. Кожны альбом можа мець шмат дарожак. Такім чынам, для кожнага трэка на альбом, я мог бы яшчэ адзін рэкорд у гэтай даччынай табліцы. Так што я стварыць адну запіс у мае альбомы табліцы. Я ствараю некалькі запісаў у табліцы трэкаў. Адзін-да-шматлікім. 

Гэта суадносіны з'яўляецца тое, што мы называем многія-да-шматлікім. ДОБРА? Вы бачыце, што акцёры маглі быць ў многіх фільмах, шмат відэа. Так што мы робім, мы ставім гэта адлюстраванне Табліца паміж тымі, якія ён проста адлюстроўвае акцёр ідэнтыфікатар відэа ID. Цяпер я магу стварыць запыт да злучае відэа праз акцёра відэа на акцёраў, і гэта дае мне добры спіс усе фільмы і ўсе акцёры якія былі ў гэтым фільме. 

ДОБРА. Дык вось мы ідзем. Адзін-да-аднаму гэта топ-ўзровень адносіны; адзін-да-шматлікім, альбомы для дарожак; многія-да-шматлікім. Такія тры верхняга ўзроўню адносіны ў любы базе дадзеных. Калі вы ведаеце, як тыя, адносіны працаваць разам, то вы ведаеце, шмат аб базе даных ўжо. Так NoSQL працуе крыху па-іншаму. Давайце думаць аб на секунду, што гэта Падобна на тое, пайсці атрымаць усе мае прадукты. 

У рэляцыйнай краме, я хачу, каб атрымаць усе мае прадукты у спісе ўсіх маіх прадуктах. Гэта шмат запытаў. Я атрымаў запыт для ўсіх маіх кніг. Я атрымаў запыт ад маіх альбомаў. І я атрымаў запыт для ўсіх маіх відэа. І я атрымаў паставіць яго ўсе разам у спісе і служыць яго назад да прыкладання, якое запытвае яго. 

Каб атрымаць мае кнігі, я далучаюся Прадукты і кніг. Каб атрымаць мае альбомы, мяне далучыцца Прадукты, Альбомы, і трэкі. І каб мае відэа, у мяне ёсць далучыцца да відэа прадукты, далучыцца праз Акцёр відэа, і прынесці ў Акцёры. Дык вось тры запыту. Вельмі складаныя запыты да сабраць адзін выніковы набор. 

Гэта менш, чым аптымальная. Вось чаму, калі мы гаворым аб структуры дадзеных, што гэта пабудаваны, каб быць незалежным ад доступу pattern-- добра, што гэта выдатна. І вы можаце бачыць гэта на самай справе прыемна, як мы арганізавалі дадзеныя. І вы ведаеце, што? У мяне ёсць толькі адзін запіс для акцёра. 

Гэта крута. Я дедуплицированы ўсе мае акцёры, і я падтрымліваў мае асацыяцыі У гэтай табліцы адлюстравання. Аднак, атрыманне дадзеных па-за становіцца даражэй. Я пасылаю працэсар ўсёй сістэме які злучае гэтыя структуры дадзеных разам каб быць у стане ажыццявіць гэта назад дадзеных. 

Так як я магу атрымаць вакол гэтага? У NoSQL гэта пра агрэгацыі, ня нармалізацыя. Такім чынам, мы хочам сказаць, што мы хочам падтрымкі доступу да файла. Калі мадэль доступу да прыкладанняў, Мне трэба, каб атрымаць усе мае прадукты. Давайце пакласці ўсе прадукты ў адной табліцы. Калі я стаўлю ўсе прадукты ў адной табліцы, Я магу проста выбраць усе прадукты з гэтай табліцы, і я атрымліваю ўсё гэта. Ну, як я магу гэта зрабіць? Ну ў NoSQL няма ніякага Структура да стала. Мы пагаворым крыху пра як гэта працуе ў Дынама БД. Але вы не павінны тое ж самае атрыбуты і тыя ж ўласцівасці у кожнага радка, у кожны Пункт, як вы робіце ў табліцы SQL. І тое, што гэта дазваляе мне зрабіць шмат рэчаў, і даць мне шмат гнуткасці. У дадзеным канкрэтным выпадку, я мае дакументы прадукту. І ў гэтым канкрэтным Напрыклад, усе гэта дакумент, у табліцы Products. І прадукт для кнігі можа ёсць тып ID, які вызначае кнігу. І прымяненне хацеў бы перайсці на той ID. 

У ўзроўні прыкладанняў, я збіраюся сказаць ах, які тып запісу гэта? О, гэта кніжка. Забранірую запісу маюць гэтыя ўласцівасці. Дазвольце мне стварыць аб'ект кнігі. Так што я збіраюся, каб запоўніць Кніга аб'ект з гэтым пунктам. Наступны тавар прыходзіць і кажа, што гэты пункт? Ну гэты элемент з'яўляецца альбом. О, я атрымаў зусім іншы працэдуры апрацоўкі для таго, таму што гэта альбом. Вы бачыце, што я маю на ўвазе? 

Такім чынам, прымяненне tier-- я проста вылучыце ўсе гэтыя запісы. Яны ўсе пачынаюць прыходзіць у. Яны могуць быць усе розныя тыпы. І гэта логіка прыкладання які перамыкаецца паміж гэтымі тыпамі і вырашае, як іх апрацаваць. 

Зноў жа, так што мы аптымізуючы Схема для шаблону доступу. Мы робім гэта з дапамогай бурыцца гэтыя табліцы. Мы ў асноўным прыняцця гэтыя нармаваныя структуры, і мы будуем іерархічныя структуры. Унутры кожнага з гэтых запісаў Я збіраюся праглядзець ўласцівасці масіва. 

Унутры гэтага дакумента Альбомы, Я бачу масівы трэкаў. Гэтыя трэкі Цяпер become-- гэта у асноўным гэта дзіця табліца, існуе прама тут, у гэтай структуры. Такім чынам, вы можаце зрабіць гэта ў DynamoDB. Вы можаце зрабіць гэта ў MongoDB. Вы можаце зрабіць гэта ў любы базе дадзеных NoSQL. Стварыць гэтыя тыпы іерархічныя структуры дадзеных якія дазваляюць вам атрымаць дадзеныя вельмі хутка, таму што цяпер я не павінны адпавядаць. Калі я ўставіць радок у Tracks стол, або шэраг ў табліцы Альбомы, Я павінен адпавядаць гэтай схеме. Я павінен мець атрыбут ці таму маёмасць, аб якой гаварылася ў дадзенай табліцы. Кожны з іх, калі я ўстаўляю гэты радок. Гэта не той выпадак у NoSQL. 

Я магу мець зусім розныя ўласцівасці ў кожным дакуменце што я ўставіць у калекцыі. Такім чынам, вельмі магутны механізм. І гэта сапраўды, як вы аптымізацыі сістэмы. Таму што цяпер замест запыту, далучэння ўсе гэтыя табліцы і выкананне паўтузіна запытаў адступіць дадзеныя мне трэба, Я выкананні аднаго запыту. І я ітэрацыі па выніках устаноўленых. гэта дае вам прадстаўленне пра сілу NoSQL. Я збіраюся роду выйсці бокам тут і трохі пагаворым пра гэта. Гэта больш, выгляд з маркетынг або technology-- маркетынг тэхналогіі тып дыскусіі. Але важна разумець, таму што, калі мы паглядзім на вяршыні тут, на гэтым графіку, тое, што мы глядзім на гэта тое, што мы называем Тэхналогія падману крывой. І тое, што гэта азначае, Новы матэрыял уступае ў гульню. Людзі думаюць, што гэта выдатна. Я вырашыў ўсе мае праблемы. 

Гэта можа быць канец усё, усё будзе ўсё. І яны пачынаюць выкарыстоўваць яго. І кажуць яны, гэты матэрыял не працуе. Гэта не правільна. Старая матэрыял быў лепш. І яны вяртаюцца да выканання рэчы, як яны былі. І тады ў канчатковым рахунку яны ідуць, вы ведаеце, што? Гэты матэрыял не так ужо дрэнна. О, як гэта працуе. І як толькі яны высветліць, як гэта Працы, яны пачынаюць усё лепш. 

І самае смешнае аб гэтым ёсць, выгляд ліній да таго, што мы называем крывой прыняцця тэхналогіі. Дык што ж адбываецца ў нас ёсць свайго роду тэхналогія запуску. У выпадку баз дадзеных, гэта ціск дадзеных. Мы гаварылі аб высокіх кропак вады ціску дадзеных на працягу часу. Пры тым, што ціск дадзеныя парад пэўная справа, што гэта тэхналогія запуску. 

Гэта становіцца занадта дорага. Гэта займае занадта шмат часу, каб апрацаваць дадзеныя. Мы павінны нешта лепш. Вы наватараў там бегаюць, спрабуючы высветліць, што гэтае рашэнне. Што новая ідэя? 

Што наступная лепшая спосаб зрабіць гэта? І яны прыходзяць з нечым. І людзі з рэальнай болю, хлопцы на пярэднім краі, яны буду скакаць над ім, таму што яны павінны адказаць. Цяпер тое, што непазбежна і happens-- гэта адбываецца цяпер у NoSQL. Я бачу ўвесь гэты час. 

Што непазбежна адбываецца людзі пачынаюць выкарыстоўваць новы інструмент гэтак жа, як яны выкарыстоўвалі стары інструмент. І яны гэта высветліць не працуе так добра. Я не магу ўспомніць, хто я гаварыць з раней сёння. Але гэта, як, калі адбойны малаток быў вынайдзены, людзі не пампаваць яго на іх галовы, каб разбіць бетон. 

Але гэта тое, што адбываецца з NoSQL сёння. Калі вы хадзіць у большасці крамаў, яны спрабуюць быць NoSQL крамы. Тое, што яны робяць, з'яўляецца яны выкарыстоўваюць NoSQL, і яны загрузкай поўны рэляцыйнай схеме. Таму што, як яны праектаваць базы дадзеных. І яны цікава, чаму не выконваючы вельмі добра? Хлопчык, гэтая рэч пахне. Я павінен быў падтрымліваць усе мае далучаецца in-- гэта як, няма, няма. Падтрыманне далучаецца? Чаму вы далучэння дадзеных? Вы не аб'ядноўваць дадзеныя ў NoSQL. Вы агрэгаваць яго. 

Так што, калі вы хочаце, каб пазбегнуць гэтага, даведацца як інструмент працуе перш чым вы сапраўды пачаць выкарыстоўваць яго. Не спрабуйце выкарыстоўваць новыя Інструменты гэтак жа, як вы выкарыстоўвалі старыя інструменты. Вы будзеце мець дрэнны досвед. І кожны раз, гэта тое, што гэта пра. Калі мы пачынаем прыдумляць тут, гэта таму, што людзі высветлілі, як выкарыстоўваць інструменты. 

Яны зрабілі тое ж самае, калі рэляцыйныя базы дадзеных былі вынайдзены, і яны былі замены файлавых сістэм. Яны спрабавалі пабудаваць файлавых сістэм з рэляцыйнымі базамі дадзеных таму што гэта тое, што людзі зразумелі. Гэта не працуе. Такім чынам, разуменне лепшыя практыкі тэхналогіі вы працуеце з велізарны. Вельмі важна. 

Такім чынам, мы збіраемся, каб патрапіць у DynamoDB. DynamoDB з'яўляецца AWS-х цалкам кіраванага платформу NoSQL. Што цалкам кіраванага на ўвазе? Гэта азначае, што вы не павінны сапраўды ні пра што турбавацца. 

Вы прыходзіце, вы скажыце нам, мне трэба табліцу. Гэта мае патрэбу ў гэтым больш магутнасці. Вы націснеце кнопку, і мы прадастаўленне уся інфраструктура за сцэнай. Цяпер, велізарны. 

Таму што, калі вы кажаце аб маштабаванне базы дадзеных, Кластары дадзеных NoSQL ў маштаб, хадавыя петабайт, працуе мільёны транзакцый у секунду, гэтыя рэчы не малыя кластары. Мы кажам тысячы асобнікаў. Кіраванне тысячы асобнікаў, нават віртуальныя асобнікі, гэта рэальная боль у задніцы. Я маю на ўвазе, думаць пра кожны раз Аперацыйная сістэма выходзіць патч ці новай версіі базы дадзеных. Што гэта азначае Вам аператыўна? Гэта азначае, што вы атрымалі 1200 серверы, якія павінны быць абноўлены. Цяпер нават з аўтаматызацыяй, што можа заняць працяглы час. Гэта можа выклікаць шмат аператыўныя галаўныя болі, таму што я, магчыма, паслугі ўніз. 

Як мне абнавіць гэтыя базы дадзеных, я можа зрабіць блакітныя зялёныя разгортвання дзе я разгортвання і абнаўлення паловы майго вузлы, а затым абнавіць іншую палову. Вазьміце тыя ўніз. Так кіравання інфраструктурай Шкала з'яўляецца надзвычай балючым. І AWS прыняць гэты боль з яго. І базы дадзеных NoSQL можа надзвычай балючым будзе з-за, як яны маштабавання. 

Маштаб па гарызанталі. Калі вы хочаце, каб атрымаць вялікую NoSQL базы дадзеных, вы купляеце больш вузлоў. Кожны вузел вы купляеце іншы аперацыйны галаўны боль. Такім чынам, давайце хтосьці зробіць гэта за вас. AWS можа гэта зрабіць. 

Мы падтрымліваем значэння ключавых дакументаў. Цяпер мы не пайшлі занадта шмат у іншай дыяграме. Там шмат розных водары NoSQL. Яны ўсе віды атрымліваць згубяцца разам у гэтай кропцы. Вы можаце паглядзець на DynamoDB і сказаць так, мы абодва дакумента і значэнне ключа захоўваць гэтую кропку. І вы можаце сцвярджаць, асаблівасці аднаго над іншым. Для мяне, шмат гэта сапраўды шэсць аднаго паўтузіна іншага. Кожны з гэтых тэхналогій з'яўляецца дакладная тэхналогія і штраф рашэнне. Я б не сказаў, што MongoDB лепш ці горш, чым канапе, то Касандры, то Дынама, ці наадварот. Я маю на ўвазе, гэта ўсяго толькі варыянты. 

Гэта хутка, і гэта адпавядае ў любым маштабе. Такім чынам, гэта з'яўляецца адным з найбуйнейшых бонусы вы атрымліваеце з AWS. З DynamoDB з'яўляецца здольнасць каб атрымаць нізкую адну лічбу Затрымка мілісекунду ў любым маштабе. Гэта было мэтай дызайну сістэмы. І ў нас ёсць кліенты, якія робяць мільёны транзакцый у секунду. 

Цяпер я пайду праз некаторыя з тых, выпадкі выкарыстання на працягу некалькіх хвілін тут. Убудаваны control-- доступ мы маем тое, што мы называем Ідэнтычнасць Упраўленне доступам, або IAM. Яна пранізвае ўсе сістэмы, кожны сэрвіс, які прапануе AWS. DynamoDB не з'яўляецца выключэннем. Вы можаце кантраляваць доступ да табліцах DynamoDB. Праз усе вашы AWS складае ад вызначэнне ролі і дазволу доступу у IAM інфраструктуры. 

І гэта ключавы і неад'емнай складнікам што мы называем Event Driven праграмавання. Зараз гэта новая парадыгма. 

АЎДЫТОРЫЯ: Як ваша хуткасць дакладна Станоўчых супраць ілжывых негатываў на сістэмы кантролю доступу? РВК Хулихэном: True спрацоўванняў у параўнанні з ложноотріцательные? АЎДЫТОРЫЯ: Вяртаючыся што Вы павінны вяртацца? У адрозненне ад раз у той час ён не вярнуцца, калі ён павінен праверыць? 

РВК Хулихэном: Я не мог сказаць вам, што. Калі ёсць якія-небудзь збоі б там ні было, што, Я не той чалавек, каб спытаць што канкрэтны пытанне. Але гэта добрае пытанне. Я б цікава даведацца, што я, на самай справе. 

І так, зноў жа, новая парадыгма гэта падзейную праграмавання. Гэта ідэя, што вы можаце разгарнуць складаных прыкладанняў, якія можа працаваць вельмі, вельмі высокі маштаб без інфраструктуры б там ні было. Без цвёрдага Інфраструктура б там ні было. І мы будзем казаць трохі аб тым, што гэта азначае, што, як мы атрымаць на наступным пары карт. 

Першае, што мы зробім што мы будзем казаць аб табліцах. Тыпы дадзеных API для Дынама. І першае, што вы будзеце заўважыў, калі вы глядзіце на гэта, калі вы знаёмыя з любой базай дадзеных, Базы дадзеных сапраўды два віды інтэрфейсаў Я б назваў гэта. Ці два камплекты API. Адзін з тых, будзе API кіравання. 

Рэчы, якія яны прымаюць на сябе функцыі базы дадзеных. Налада механізму захоўвання, стварэнне і даданне табліц. стварэнне базы дадзеных каталогі і прыклады. Яны things-- ў DynamoDB, вы маюць вельмі кароткія, кароткія спісы. 

Такім чынам, у іншых базах дадзеных, Вы маглі б бачыць дзясяткі з каманды, адміністрацыйна Каманды, для канфігуравання гэтыя дадатковыя опцыі. У DynamoDB вам не трэба, таму што тыя, Вы не наладжваць сістэму, мы робім. Так што адзінае, што вам трэба зрабіць, гэта скажы мне, што памер табліцы мне трэба. Такім чынам, вы атрымліваеце вельмі абмежаваны набор каманд. 

Вы атрымліваеце Create Table Update, Настольны, Выдаліць табліцу і апісаць табліцу. Гэта адзіныя рэчы, што трэба для DynamoDB. Вам не трэба сховішча канфігурацыя рухавіка. Мне не трэба турбавацца аб рэплікацыі. Мне не трэба турбавацца аб шардинге. 

Я не трэба турбавацца аб любым з гэтага матэрыялу. Мы робім усё гэта для вас. Так што гэта велізарная колькасць накладных расходаў што проста падняў свой пласціну. Тады ў нас ёсць аператары CRUD. CRUD-тое, што мы патэлефануйце ў базе дадзеных, што гэта Стварэнне, абнаўленне, выдаленне аператараў. Гэта ваш агульны аперацыі з базамі дадзеных. Такія рэчы, як пакласці дэталь, атрымліваеце дэталь, абнаўленне прадметы, выдаляць элементы, партыя запытаў, сканаванне. Калі вы хочаце, каб сканаваць ўсю табліцу. Пацягніце ўсё са стала. Адна з прыемных рэчаў аб DynamoDB гэта дазваляе паралельнае сканаванне. Так што вы можаце на самой справе, дайце мне ведаць, колькі тэмы вы хочаце, каб працаваць на гэтай сканавання. І мы можам запусціць гэтыя тэмы. Мы можам спіна, што сканаваць да па некалькіх патокаў так што вы можаце сканаваць ўсю табліцу прастору вельмі, вельмі хутка ў DynamoDB. 

Іншы API мы маем тое, што мы называем нашым Патокі API. Мы не збіраемся казаць занадта шмат пра гэта прама цяпер. Я атрымаў некаторы ўтрыманне пазней на палубе ў пра гэта. Але Патокі сапраўды running-- думаю пра яго, як загадаў раз і змяненне раздзелаў часопіса. Усё, што адбываецца на табліца паказвае ўверх у струмені. 

Кожны напісаць у табліцы Выставы на паток. Вы можаце прачытаць, што струмень, і Вы можаце рабіць рэчы, з ім. Мы будзем казаць аб тым, што тыпы рэчаў, якія вы рабіць з рэчамі, як рэплікацыя, стварэнне другасных індэксаў. Усе віды сапраўды выдатна рэчы, якія вы можаце зрабіць з гэтым. 

Тыпы дадзеных. У DynamoDB, мы падтрымліваем абодва ключа значэнне і дакумент тыпы дадзеных. На левай баку экрана тут, мы атрымалі нашы асноўныя тыпы. Асноўныя тыпы значэнняў. Гэтыя радкі, лічбы і выкананыя файлы. 

Так усяго за тры асноўных тыпу. І тады вы можаце мець наборы з іх. Адна з прыемных рэчаў аб NoSQL гэта Вы можаце ўтрымліваць масівы ў якасці уласцівасцяў. І з DynamoDB можна ўтрымліваць масівы асноўных тыпаў, як каранёвай уласнасці. 

А тут яшчэ тыпы дакументаў. Колькі людзей знаёмыя з JSON? Вы, хлопцы, знаёмыя з JSON так шмат? Гэта ў асноўным JavaScript, Аб'ект, Абазначэнні. Гэта дазваляе ў асноўным вызначаюць іерархічную структуру. 

Вы можаце захоўваць дакумент у фармаце JSON на DynamoDB выкарыстаннем агульных кампанентаў або блокаў, якія даступныя у большасці моў праграмавання. Так што, калі ў вас ёсць Java, вы гледзячы на ​​карты і спісы. Я магу стварыць аб'екты, якія Карта зоны. Карта, як ключавых каштоўнасцяў захоўваюцца ў якасці уласцівасцяў. І гэта, магчыма, ёсць спісы значэння ў межах гэтых уласцівасцяў. Вы можаце захоўваць гэты комплекс іерархічная структура як аднаго атрыбуту з пункта DynamoDB. 

Так табліц у DynamoDB, як і большасць Базы дадзеных NoSQL, сталы ёсць пункты. У MongoDB вы б называць гэтыя дакументы. І гэта будзе канапа базы. Таксама база дадзеных дакументаў. Вы называеце гэтыя дакументы. Дакументы або дэталі маюць атрыбуты. Атрыбуты могуць існаваць або не існуе па гэтым пункце. У DynamoDB, ёсць адзін абавязковы атрыбут. Гэтак жа, як у рэляцыйнай базе дадзеных, ў вас ёсць першасны ключ на стале. 

DynamoDB мае тое, што мы называем хэш-ключ. Хэш ключ павінен быць унікальным. Таму, калі я вызначыць хэш-табліцу, у асноўным тое, што я кажу, з'яўляецца кожны элемент будзе мець хэш-ключ. І кожны хэш-ключ павінен быць унікальным. 

Кожны элемент вызначаецца гэтай унікальнай Хэш-ключа. А можа быць толькі адзін. Гэта нармальна, але часта што трэба людзям яны хочуць гэта хэш Ключ да рабіць трохі больш чым проста быць унікальным ідэнтыфікатарам. Часта мы хочам, каб выкарыстоўваць гэтую хэш-ключ ў якасці верхняга ўзроўню агрэгацыі вядро. І тое, як мы робім, што з'яўляецца дадаўшы, што мы называем ключ дыяпазону. 

Так што, калі гэта толькі хеш- стол, гэта павінна быць унікальным. Калі гэта хэш і дыяпазон стол, Спалучэнне хэша і дыяпазону павінна быць унікальным. Так што падумайце пра гэта такім чынам. Калі ў мяне ёсць форум. І форма мае тэмы, ён мае пасады, і яна мае адказаў. 

Так што я, магчыма, хэш ключ, які з'яўляецца тэмай ID. І я мог бы мець ключ дыяпазон, які з'яўляецца адказам ID. Такім чынам, калі я хачу, каб усе адказы для канкрэтнай тэме, Я магу толькі запыт хэш. Я магу толькі сказаць, мне ўсё даюць прадметы, якія маюць гэты хэш. І я іду, каб атрымаць кожнае пытанне або размясціць на гэтай канкрэтнай тэме. Гэтыя галоўныя навалы ўзроўню вельмі важныя. Яны падтрымліваюць асноўны доступ Характар ​​прымянення. Наогул кажучы, гэта гэта тое, што мы хочам зрабіць. Мы хочам, каб table-- як вы загрузіць табліцу, мы хочам, каб структураваць дадзеныя у табліцы такім чынам, што прыкладанне можа вельмі хутка атрымаць гэтыя вынікі. І часта спосаб зрабіць гэта для падтрымання гэтых агрэгатаў, як мы ўставіць дадзеныя. У прынцыпе, мы распаўсюджвання даных у светлую вядро, як гэта адбываецца ў. 

Ключы з доўгімі дазваляюць me-- хэш ключы павінны быць роўнасць. Калі я запыт хэш, я павінен сказаць, даць мне хэш, роўную гэтага. Калі я запытаць дыяпазон, я можна сказаць, дайце мне дыяпазон які выкарыстоўвае любую багатыя аператар, што мы падтрымліваем. Дайце мне ўсё дэталі для хэш. Гэта роўна, больш, чым, менш, чым, яна пачынаецца з таго, яно існуе паміж гэтымі двума значэннямі? Такім чынам, гэтыя тыпы запытаў далёкасці што мы заўсёды зацікаўлены ў. Цяпер адна рэч, пра дадзеныя, калі вы паглядзіце на доступ да дадзеных, калі Вы атрымаць доступ да дадзеных, гэта заўсёды аб агрэгацыі. Гэта заўсёды аб запісах якія звязаны з гэтым. Дайце мне ўсё тут that's-- ўсе здзелкі па гэтай крэдытнай карты за апошні месяц. Гэта агрэгацыі. 

Амаль усё, што вы робіце ў База дадзеных якой-агрэгацыі. Так будучы ў стане быць у стане вызначыць гэтыя вёдры і даць вам гэтыя асартымент атрыбуты, каб мець магчымасць запытваць на, гэтыя багатыя запыты падтрымкі многіх шмат, шмат мадэляў доступу да дадатку. 

Так іншы прадмет Хэш ключа робіць гэта дае нам механізм каб мець магчымасць пашырыць дадзеныя вакол. Базы дадзеных NoSQL працаваць лепш калі дадзеныя раўнамерна размеркаваны ў кластары. Колькі людзей знаёмыя з алгарытмаў хэшавання? Калі я кажу, хэш і hashing-- таму алгарытму хэшавання гэта спосаб быць у стане генераваць выпадковае значэнне ад любога зададзенага значэння. Такім чынам, у дадзеным канкрэтным выпадку, хэш алгарытм бяжым з'яўляецца Н.Д. 5 на аснове. 

І калі ў мяне ёсць ID, і гэта мой хэш-ключ, у мяне ёсць 1, 2, 3. Калі я запускаю алгарытм хэшавання, ён збіраецца вярнуцца і сказаць, а 1 роўны 7В, 2 роўная 48, 3 роўная кампакт-дыска. Яны раскіданыя па ўсім ключавога прасторы. І чаму вы гэта робіце? Таму што гарантуе, што я магу пакласці запісу на некалькіх вузлах. 

Калі я раблю гэта паступова, 1, 2, 3. І ў мяне ёсць выбар, што хэш- працуе ў дадзеным канкрэтным выпадку, невялікая прастора хэш, ён працуе ад 00 да FF, то запісу будуць прыходзіць у і яны збіраюцца ісці 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. Што здарылася? Кожны ўкладыш ідзе ў тым жа вузле. Вы бачыце, што я маю на ўвазе? 

Таму што, калі я падзяліць прастору, і я распаўсюджваць гэтыя запісы праз, і я раздзел, я збіраюся сказаць, раздзел 1 мае ключавое прастору ад 0 да 54. Раздзел 2 55 да 89. Раздзел 3 АА FF. Так што, калі я выкарыстоўваю лінейна павялічваючы Ідэнтыфікатары, вы можаце бачыць, што адбываецца. 1, 2, 3, 4, 5, 6, ўвесь шлях да 54. Так, як я малатком запісы ў сістэме, усе заканчваецца тым, што ішлі да аднаго вузлу. 

Гэта не добра. Гэта антипаттерн. У MongoDB яны маюць гэтую праблему калі вы не выкарыстоўваеце хэш-ключ. MongoDB дае вам магчымасць хэшавання значэнне ключа. Вы заўсёды павінны рабіць, калі Вы карыстаецеся прырашчэння Хэш Ключ у MongoDB, ці вы будзеце цвікоў кожнай запісу ў адным вузле, і вы будзеце абмяжоўваючы Вы пішаце прапускная дрэнна. 

АЎДЫТОРЫЯ: Гэта A9 169 у дзесятковай? 

РВК Хулихэном: Так, гэта дзесьці каля там. A9, я не ведаю. Вы павінны былі б атрымаць мой двайковы у дзесятковую калькулятар. Мой мозг не працуе так. АЎДЫТОРЫЯ: Проста хутка адным Вашы каментары Mongo. Так ідэнтыфікатар аб'екта, які пастаўляецца першапачаткова з Монго зрабіць? РВК Хулихэном: яна гэта робіць? Калі вы пакажыце яго. У MongoDB, у вас ёсць магчымасць. Вы можаце specify-- кожны дакумент у MongoDB павінен мець падкрэслення ID. Гэта унікальнае значэнне. 

У MongoDB вы можаце паказаць Ці хэш яго ці не. Яны проста даюць вам магчымасць. Калі вы ведаеце, што гэта ня выпадковы, не праблема. Вам не трэба гэтага рабіць. Калі вы ведаеце, што гэта не выпадкова, што гэта прырашчэнне, а затым зрабіць хэш. 

Цяпер справа аб хэшавання, калі вы хэш value-- і гэта чаму хэш-ключы заўсёды унікальныя запыты, таму што я змянілася значэнне, у цяперашні час я не магу зрабіць дыяпазон запытаў. Я не магу сказаць, гэта між тым ці іншым, таму што хэш-значэнне не будзе быць эквівалентная рэальнай кошту. Такім чынам, калі вы хэш, што Ключ, гэта толькі роўнасць. Вось чаму ў DynamoDB Хэш-ключа запыты заўсёды толькі роўнасць. 

Так што цяпер у дыяпазоне key-- калі я дадаць, што ключавы дыяпазон, тыя ключавыя запісу дыяпазон ўсе прыходзяць і яны атрымліваюць захоўваецца ў тым жа раздзеле. Такім чынам, яны вельмі хутка, лёгка здабываецца, таму што гэта хэш, гэта дыяпазон. І вы бачыце, усё з той жа хэш атрымлівае захоўваецца на тым жа прасторы раздзелаў. Вы можаце выкарыстоўваць гэты ключ, каб дапамагчы дыяпазон знайсці вашы дадзеныя блізкія да свайго бацьку. Так што я на самой справе тут робіш? Гэта адзін да многіх адносін. Адносіны паміж ключом хэш- і ключ дыяпазон адзін да многіх. Я магу мець некалькі ключоў хэш. Я магу толькі мець некалькі выбар ключы ўнутры кожнага ключа хэша. 

Хэш вызначае з бацькоў, дыяпазон вызначае дзяцей. Такім чынам, вы можаце бачыць, што гэта аналаг тут паміж рэляцыйнай канструкцыі і тыя ж тыпы будуе ў NoSQL. Людзі кажуць пра NoSQL, як нереляционная. Гэта не нереляционная. Дадзеныя заўсёды адносіны. Гэтыя адносіны проста мадэлююцца па-рознаму. Давайце трохі пагаворым Крыху пра даўгавечнасці. Калі вы пішыце ў DynamoDB, піша заўсёды трохбаковая прайграныя. Гэта азначае, што ў нас ёсць тры AZ гадоў. Я з'яўляюцца даступнасць зон. Вы можаце думаць аб даступнасці Зона ў цэнтры апрацоўкі дадзеных або сукупнасць цэнтраў апрацоўкі дадзеных. Гэтыя рэчы геаграфічна ізаляваны адзін ад аднаго розных зон разломаў, па адрозніваецца электрычныя сеткі і поймы. Адмова ў адным AZ ня збіраецца зняць яшчэ адзін. Яны таксама звязаны разам з цёмна-валакна. Ён падтрымлівае адзін суб 1 Затрымка мілісекунду паміж АЗС. Так рэплікацыі дадзеных у рэжыме рэальнага часу здольныя ў некалькіх АЗС. 

І часта мульты разгортванне AZ адпавядаць высокім патрабаванням даступнасці большасці прадпрымальніцкіх арганізацый. Так DynamoDB распаўсюджваецца праз тры АЗС па змаўчанні. Мы толькі збіраемся пазнання запісу калі два з гэтых трох вузлоў вярнуцца і сказаць, Так, я атрымаў яго. Чаму гэта? Таму што на баку чытання мы толькі збіраюся даць вам дадзеныя таму, калі мы атрымліваем яго з двух вузлоў. 

Калі я тыражаванне па тры, і я чытаю з двух, Я заўсёды гарантуецца мець па крайняй меры адзін тых счытвае быць Актуальная копія дадзеных. Гэта тое, што робіць DynamoDB паслядоўным. Цяпер вы можаце ўключыць тых, якія адпавядаюць счытвае. У гэтым выпадку я збіраюся сказаць, Я буду чытаць толькі з аднаго вузла. І я не магу гарантаваць, што гэта адбываецца каб быць найбольш актуальныя дадзеныя. 

Так што, калі запісы ў бліжэйшыя, гэта яшчэ не реплицируются, Вы збіраецеся атрымаць гэтую копію. Гэта ў канчатковым выніку несупярэчны чытанне. І што гэта такое гэта палова кошту. Так што гэта нешта думаць. Калі вы чытаеце з DynamoDB, і вы наладжваеце вашу здольнасць чытання адзінак, калі вы выбіраеце ў канчатковым выніку адпавядае чытае, гэта нашмат танней ,, гэта каля паловы кошту. 

І так эканоміць вашыя грошы. Але гэта ваш выбар. Калі вы хочаце несупярэчны чытанне або у канчатковым выніку несупярэчны чытанне. Гэта тое, што вы можаце выбраць. 

Давайце пагаворым пра індэксы. Такім чынам, мы згадалі, што топ агрэгацыі ўзроўню. У нас ёсць хэш ключы, і мы атрымалі ключы далёкасці. Гэта прыемна. І гэта на асноўнай табліцы, я ёсць адзін хэш-ключ, я атрымаў адзін ключ дыяпазону. 

Што гэта азначае? Я атрымаў адзін атрыбут, што я можа працаваць багатых запытаў да. Гэта ключ дыяпазону. Іншыя атрыбуты на гэтым item-- Я магу фільтраваць гэтых атрыбутаў. Але я не магу рабіць рэчы, як, гэта пачынаецца з або больш. 

Як мне гэта зрабіць? Я стварыць індэкс. Там дзве тыпы Індэксы ў DynamoDB. Індэкс сапраўды Яшчэ адзін від табліцы. І мясцовы другасны індэкс. 

Першы мы пагаворым аб. Так мясцовыя другасныя якія суіснавалі у тым жа раздзеле, што і дадзеныя. І як такія, яны знаходзяцца на і той жа фізічны вузел. Яны, што мы называем паслядоўнай. Значэнне, яны прызнаюць, ад запісу разам з табліцай. Калі запісу прыходзіць, мы напішам праз індэкс. Мы напішам да стала, і тады мы будзем мець на ўвазе. Дык вось паслядоўным. Пасля таго, як запісы былі прызнаў з табліцы, гэта гарантуе, што мясцовы другасны індэкс будзе мець тое ж самае бачанне дадзеных. Але тое, што яны дазваляюць вам рабіць гэта вызначыць ключы альтэрнатыўныя далёкасці. 

Давядзецца выкарыстоўваць аднолькавыя хэш Ключ, як у асноўны табліцы, таму што яны размешчаны сумесна на той жа падзел, і яны адпавядаюць. Але я магу стварыць індэкс з рознымі ключамі далёкасці. Так, напрыклад, калі б я меў вытворцу што было сырым стол часткі ўваходзіць. І сыравіну часткі прыходзяць у і яны агрэгуе зборкі. І, можа быць, ёсць водгук. 

Любая частка, якая была зроблена гэтая вытворца пасля гэтай даты, Мне трэба, каб выцягнуць з маёй лініі. Я магу круціцца індэкс што будуць шукаць, агрэгавання на дату вытворчасць гэтай канкрэтнай часткі. Так што, калі мой стол быў верхні ўзровень ўжо хэшируется вытворцы, можа быць, гэта было ўладкована на частку ID, я можа стварыць індэкс выключэння гэтай табліцы а хэш вытворцам і вагалася ад даты вырабу. І такім чынам я мог бы сказаць, усё, што быў выраблены паміж гэтымі датамі, Мне трэба, каб выцягнуць з лініі. Так што гэта мясцовы другасны індэкс. 

Яны маюць эфект абмяжоўваючы хэш прастору ключоў. Таму што яны суіснавалі на тым жа вузле захоўвання, яны абмяжоўваюць хэш-ключ прастору 10 гігабайт. DynamoDB, пад сталы, будзе падзяліць Ваш стол кожныя 10 гігабайт. Калі вы кладзе 10 канцэртаў дадзеных у, мы перайсці [ФН], і мы дадаем яшчэ адзін вузел. 

Мы не будзем падзяліць LSI па некалькіх раздзелах. Мы разбіць табліцу. Але мы не будзем падзяляць LSI. Так гэта тое, што Важна разумець, калі вы робіце вельмі, вельмі, вельмі вялікія навалы, то вы будзеце абмяжоўвацца 10 гігабайт на вашым ВІС. 

Калі гэта так, то мы можам выкарыстоўваць глабальныя другасныя. Глабальныя другасныя з'яўляюцца сапраўды іншая табліца. Яны існуюць, каб цалкам ад бок з вашай першаснай табліцы. І яны дазваляюць мне знайсці зусім розныя структуры. Так што думайце пра яго, як дадзеныя ўстаўляюцца у двух розных табліц, структураваны двума рознымі спосабамі. 

Я магу вызначыць зусім адрозніваецца хэш-ключ. Я магу вызначыць зусім іншая клавіша дыяпазону. І я магу запусціць гэты цалкам незалежна. На самай справе, у мяне падрыхтавана маю здольнасць чытання і напісаць ёмістасць для майго глабальныя другасныя індэксы зусім незалежна маёй асноўнай табліцы. Калі я вызначаю, што індэкс, я кажу гэта колькі чытаць і пісаць Аб'ём ён збіраецца выкарыстоўваць. 

І гэта асобная ад маёй асноўнай табліцы. Цяпер абодва індэкса дазволіць нам не толькі вызначыць хэш і далёкасці ключы, але яны дазваляюць нам праекта дадатковых значэнняў. Так што, калі я хачу, каб счытваць індэкс, і я хачу, каб атрымаць набор дадзеных, Мне не трэба, каб вярнуцца да галоўнага Табліца, каб атрымаць дадатковыя атрыбуты. Я магу спраектаваць гэтыя дадатковыя атрыбутаў ў табліцы падтрымаць доступу да файла. Я ведаю, што мы, верагодна, атрымаць у некаторыя сапраўды, really-- трапленне ў пустазелля тут, на некаторыя з гэтых рэчаў. Цяпер я атрымаў дрэйфаваць з гэтага. 

АЎДЫТОРЫЯ: [неразборліва] --table ключ меў на ўвазе, хэш? Арыгінальны хэш? Multi-рэйкі? 

РВК Хулихэном: Так. Так. Ключ табліцы ў асноўным паказвае назад да пункта. Так індэкс з'яўляецца паказальнікам назад арыгінальныя прадметы на стале. Цяпер вы можаце выбраць, каб пабудаваць індэкс, які мае толькі ключ табліцы, і ніякіх іншых уласцівасцяў. І чаму я мог бы зрабіць гэта? Ну, можа быць, у мяне вельмі вялікія прадметы. 

Я сапраўды толькі трэба ведаць which-- мой ўзор доступу можна сказаць, якія ўтрымліваюць элементы гэтага гатэля? Ня трэба вярнуць дэталь. Мне проста трэба ведаць, якія элементы ўтрымліваюць яго. Такім чынам, вы можаце пабудаваць індэксы што толькі ёсць ключ табліцы. 

Але гэта, перш за ўсё, тое, што індэкс ў базе даных для. Гэта за тое, што ў стане хутка вызначыць, якія запісы, якія радкі, якія элементы табліцы маюць ўласцівасці, якія я шукаў. 

СБИС, так як яны працуюць? СБИС ў асноўным з'яўляюцца асінхроннымі. Абнаўленне ўступае ў табліцы, Табліца затым асінхронна абнаўляецца усе вашы СБИС. Вось чаму СБИС з'яўляюцца у канчатковым выніку стасуюцца. 

Важна адзначыць, што калі вы будуеце СБИС, і вы разумееце, вы ствараеце іншае вымярэнне aggregation-- Зараз давайце казаць добры прыклад тут вытворца. Я думаю, што я, магчыма, казалі пра вытворца медыцынскага прылады. Вытворцы медыцынскіх вырабаў часта маюць серыйныя нумары часткі. Часткі, якія ўваходзяць у замена тазасцегнавага ўсе ёсць трохі серыйны нумар на іх. І яны маглі б мільёны і мільёны і мільярды частак ва ўсіх прыладах, якія яны пастаўляюцца. Ну, яны павінны аб'ядноўваць пад розныя памеры, усе часткі ў зборцы, усё часткі, якія былі зробленыя на некаторай лініі, усё часткі, якія прыйшлі у з пэўнай вытворцы на пэўную дату. І гэтыя навалы часам ўстаць у мільярды. 

Так што я працаваць з некаторымі з гэтыя хлопцы, якія пакутуюць таму што яны ствараюць гэтыя навалы GINORMOUS у іх другасных індэксаў. Яны могуць мець сырыя часткі табліца, прыходзіць як толькі хэш. Кожная частка мае унікальны серыйны нумар. Я выкарыстоўваю серыйны нумар, як хэш. Гэта прыгожа. Мой сыравіну табліца дадзеных распаўсюджваецца па ўсёй ключавога прасторы. Мой [? напісаць?] [? праглынанне?] з'яўляецца дзіўным. Я бяру шмат дадзеных. Тады тое, што яны робяць, яны ствараюць GSI. І я кажу, вы ведаеце, што, мне трэба, каб убачыць усе часткі дадзенага вытворцы. Ну, раптам я прымаючы мільярда радкоў, і запіхваць іх на адзін вузел, таму што, калі Я, як агрэгаваць вытворца ID, як хэш, і нумар у дыяпазоне, затым усё раптам я паставіўшы млрд часткі ў тое, што гэты вытворца вызваліў мяне. 

Гэта можа выклікаць шмат ціску на GSI, зноў, таму што я малатком адзін вузел. Я стаўлю усе гэтыя ўстаўляе ў адным вузле. І гэта рэальная праблематычна кейс. Зараз, я атрымаў добры дызайн шаблон для, як вы пазбегнуць. І гэта адна з праблем, што я заўсёды працаваць. Але тое, што адбываецца, з'яўляецца GSI можа не хапае магутнасці запісу каб быць у стане вылучыць ўсе тыя радкоў у адным вузле. І тое, што адбываецца потым гэта першасны, табліца Кліент, галоўная табліца будзе задушыў таму што GSI не можа угнацца. Так што мой курс будзе ўстаўка падаюць на асноўнай табліцы як мой GSI спрабуе не адставаць. 

Добра, так GSI-х, ВІС, які я павінен выкарыстоўваць? ВІС стасуюцца. GSI з'яўляюцца ў канчатковым рахунку адпавядае. Калі гэта нармальна, я рэкамендую выкарыстоўваць GSI, яны значна больш гнуткім. ВІС могуць быць змадэляваныя як GSI. І калі памер дадзеных у хэш-ключоў у Ваша калекцыя перавышае 10 гігабайт, то вы будзеце жадаць выкарыстоўваць што GSI, таму што гэта проста жорсткі ліміт. 

Добра, так маштабавання. Прапускная ў Дынама БД, вы становішча можа [неразборліва] прапускная да стала. У нас ёсць кліенты, якія маюць падрыхтавана 60 billion-- робяць 60 млрд запытаў, рэгулярна працуе на больш чым мільён запытаў за секунду на нашых сталах. Там на самай справе няма Тэарэтычны мяжа таго, колькі і як хутка табліца можа працаваць у Дынама БД. Ёсць некаторыя мяккія ліміты на ваш рахунак што мы ставім там так што вы не сыходзіце з розуму. Калі вы хочаце больш, чым што не з'яўляецца праблемай. Вы прыходзіце, паведаміце нам. Мы падніміце дыск. 

Кожная уліковы запіс абмежаваная нейкай ступені у кожнай службе, проста з месца ў кар'ер так што людзі не страчваюць розум трапляюць у непрыемнасці. Няма мяжы ў памеры. Вы можаце змясціць любую колькасць элементаў на стале. Памер элемента з'яўляецца абмяжоўваецца да 400 кілабайт кожны, што б элемент не атрыбуты. Так суме ўсіх атрыбутаў абмяжоўваецца да 400 кілабайт. І зноў жа, у нас ёсць што мала ВІС пытанне з мяжой 10 гігабайт на хэш. АЎДЫТОРЫЯ: Невялікая колькасць, я прапускаю тое, што вы казалі мне, што is-- АЎДЫТОРЫЯ: Так, 400 кілабайта максімальны памер па кожным пункце. Так элемент мае ўсе атрыбуты. Так 400 Да агульны памер гэтага элемента, 400 кілабайт. Так усіх прыкмет камбінаваныя ўсе дадзеныя гэта ва ўсіх гэтых атрыбутаў, закатаў у агульнай колькасці, У цяперашні час мяжа пункт сёння 400 к. Так маштабавання зноў, дасягаецца пасродкам перагародак. Прапускная здольнасць прадугледжаным на ўзроўні табліцы. І там сапраўды дзве ручкі. Мы чыталі магутнасць і напісаць ёмістасць. 

Такім чынам, гэтыя карэктуюцца незалежна адзін ад аднаго. Мера РКО ў строга ўзгодненыя чытання. ОК, так што калі вы кажаце, я хачу 1000 РКО-х тыя, строга паслядоўным, тых, стасуюцца чытае. Калі вы хочаце сказаць, што я магчымае несупярэчны чытанне, Вы можаце прадастаўленне 1000 РКО, вы ідзяце каб атрымаць у канчатковым выніку 2,000 адпавядае чытае. І палова цэны для тых, у канчатковым выніку складаюцца ў чытае. 

Зноў жа, рэгулюецца незалежна адзін ад аднаго. І ў іх ёсць throughput-- Калі вы спажываеце 100% ад вашага РКО, вы не збіраецеся, каб паўплываць на наяўнасць вашых правоў. Такім чынам, яны цалкам незалежныя адзін ад аднаго. Добра, так што адзін з рэчаў, якія Я коратка згадана было дросселирования. Рэгуляванне дрэнна. Рэгуляванне паказвае дрэнна не SQL. Ёсць рэчы, якія мы можам зрабіць, каб дапамагчы вам палегчыць дросселирование, што вам адчуваюць. Але лепшае рашэнне каб гэта давайце Погляд на тое, што вы робіце, таму што ёсць анты-патэрнаў ў гульні тут. 

Гэтыя рэчы, рэчы, як неаднародных нагрузкі, гарачыя клавішы, гарачыя перагародкі. Я ўдару асаблівую прастору ключоў вельмі цяжка, па пэўных прычынах. Чаму я гэта раблю? Давайце зразумець. Я змешваю мае гарачыя дадзеныя з халоднымі дадзеных. Я дазваляю мае табліцы атрымаць Велізарны, але там сапраўды толькі некаторы падмноства дадзеных гэта сапраўды цікава для мяне. Такім чынам, для дадзеных часопіса, напрыклад, шмат кліенты, яны атрымліваюць дадзеныя, аўтарызуйцеся кожны дзень. Яны атрымалі велізарную колькасць дадзеных часопіса. 

Калі вы толькі што дэмпінг ўсе часопіс дадзеныя ў адной вялікай табліцы, з часам гэтая табліца збіраецца атрымаць масіўнае. Але я сапраўды зацікаўлены толькі ў Апошнія 24 гадзін, апошнія сем дзён, апошнія 30 дзён. Як бы там ні прамежак часу што я зацікаўлены ў пошуку для падзеі, турбуе мяне, ці падзея, якая мне цікава, што адзіны раз, калі акно, што мне трэба. Такім чынам, чаму я пакласці 10 гадоў Варта каротажных дадзеных у табліцы? Тое, што гэта выклікае гэта табліца фрагмент. 

Ён атрымлівае велізарную. Гэта пачынае распаўсюджвацца з на тысячы вузлоў. А так як ваша здольнасць так нізка, вы на самай справе абмежаванні хуткасці на кожным адзін з тых асобных вузлоў. Такім чынам, давайце пачнем, гледзячы на ​​тое, як мы згарнуць гэтую табліцу на працягу. Як мы можам кіраваць, што дадзеныя трохі лепш, каб пазбегнуць гэтых праблем. І тое, што гэта падобна? Гэта тое, што, што выглядае. Гэта тое, што дрэнна NoSQL выглядае. 

Я атрымаў гарачую клавішу тут. Калі вы паглядзіце на баку тут, гэта ўсе мае раздзелы. Я атрымаў 16 раздзелаў тут на гэтай канкрэтнай базы дадзеных. Мы робім гэта ўвесь час. Я запускаю гэта для кліентаў ўвесь час. Гэта называецца цеплавой мапе. Цеплавая карта кажа мне, як ты доступу да вашай прастору ключоў. І тое, што гэта кажа мне, гэта што ёсць адзін канкрэтны Хэш што гэты хлопец любіць вельмі шмат, таму што ён ударыўшы па ім сапраўды, сапраўды цяжка. 

Такім чынам, сіні прыемна. Нам падабаецца сіні. Нам не падабаецца чырвоны колер. Дзе ціск Реда атрымлівае да 100%. 100%, цяпер вы будзеце задушыў. Таму, калі вы бачыце чырвоныя лініі, як this-- і гэта не толькі Дынама DB-- кожная база дадзеных NoSQL мае гэтую праблему. Ёсць антишаблоны, якія могуць кіраваць гэтымі тыпамі умоў. Тое, што я раблю, я працую з кліентамі каб палегчыць гэтыя ўмовы. 

І тое, што гэта падобна? І гэта становіцца найбольш з Дынама DB прапускной здольнасці, але гэта сапраўды становіцца большасць з NoSQL. Гэта не абмяжоўваецца Дынама. Гэта я definitely-- выкарыстоўваецца для працы ў Монго. Я знаёмы з многімі платформамі NoSQL. Кожны чалавек мае гэтыя тыпы гарачых ключавых праблем. Каб атрымаць максімальную аддачу ад любой NoSQL базы дадзеных, спецыяльна Дынама БД, Вы хочаце, каб стварыць табліцы дзе элемент хэш-ключ мае вялікая колькасць розных значэнняў, высокая ступень магутнасці. Таму што гэта азначае, што я пішу на мноства розных каўшоў. 

Чым больш я ў вёдры пісьмовай форме, тым больш верагодна, Я распаўсюджваць гэтую нагрузку запісы або прачытаць загрузіць з па некалькіх вузлах, тым больш верагодна, я павінен мець высокая прапускная здольнасць на стол. А потым я хачу, каб быць значэння прасіў даволі раўнамерна на працягу доўгага часу і раўнамерна, як выпадковым чынам, наколькі гэта магчыма. Ну, гэта даволі цікава, таму што я не магу на самой справе кантроль, калі карыстальнікі прыходзяць. Так дастаткова сказаць, калі мы распаўсюджваем рэчы з усёй ключавога прасторы, мы, верагодна, будзе ў лепшай форме. 

Там пэўная колькасць часу дастаўкі што вы не збіраецеся каб быць у стане кантраляваць. Але гэта на самай справе два аспекты, якія мы маем, прастору, доступ раўнамерна распаўсюджванне, час, запыты прыбываюць раўнамерна ў часе. І калі гэтыя два задавальняюцца ўмовы, тое, што тое, што гэта будзе выглядаць. Гэта значна прыемней. Мы сапраўды шчаслівыя тут. Мы атрымалі вельмі нават мадэль доступу. Так, можа быць, вы атрымліваеце невялікае ціск кожны зараз і потым, але нічога сапраўды занадта шырокая. Так што гэта дзіўна, як шмат разоў, калі я працую з кліентамі, што першы графік з вялікай чырвоны бар і ўсё, што выродлівыя жоўтыя гэта паўсюль, мы зроблена з ажыццяўленнем праз пару месяцаў паўторнага архітэктуры, яны працуюць сапраўды такі ж нагрузка ў той жа самы нагрузкі. І гэта тое, што ён шукае, як цяпер. Так што вы атрымліваеце з NoSQL з'яўляецца Схема дадзеных, абсалютна прывязаны да мадэлі доступу. 

І вы можаце аптымізаваць гэтую схему дадзеных падтрымаць гэтую мадэль доступу. Калі вы гэтага не зробіце, то вы будзеце каб убачыць гэтыя тыпы праблем з тых гарачых клавіш. 

АЎДЫТОРЫЯ: Ну, непазбежна некаторыя месцы будуць гарачэй, чым іншыя. 

РВК Хулихэном: Заўсёды. Заўсёды. Так, я маю на ўвазе заўсёды ёсць a-- і зноў, ёсць некаторыя шаблоны праектавання, мы пройдзем праз што будзе казаць пра тое, як вы маеце справу з гэтых супер вялікіх навал. Я маю на ўвазе, я павінен мець іх, як мы маем справу з імі? Я атрымаў вельмі добрую прэцэдэнт што мы будзем казаць пра тое, што для. 

Добра, так што давайце казаць аб некаторых кліенты цяпер. Гэтыя хлопцы AdRoll. Я не ведаю, калі вы знаёмыя з AdRoll. Вы, напэўна, убачыць іх шмат у браўзэры. Яны аб'яваў перанакіраванне, яны найбуйнейшы аб'явы перанакіраванне бізнес там. Яны, як правіла, рэгулярна запускаць больш 60 млрд транзакцый у дзень. Яны робяць больш за мільён транзакцый у секунду. Яны атрымалі даволі простую табліцу структура, ажыўленых табліцы. Гэта ў асноўным толькі хэш ключ печыва, дыяпазон дэмаграфічная Катэгорыя, а затым трэці атрыбут рахунак. 

Такім чынам, мы ўсе павінны печыва ў наш браўзэр ад гэтых хлопцаў. І калі вы ідзяце да ўдзел купец, яны ў асноўным адзнака вас праз розныя дэмаграфічныя катэгорыі. Калі вы ідзяце на сайт і вы кажаце, я хачу, каб гэты ad-- або ў асноўным не кажуць that-- але калі вы ідзяце на сайт яны кажуць, што вы хочаце ўбачыць гэта аб'ява. І яны ідуць атрымаць, што аб'ява ад AdRoll. AdRoll выглядае вас на стале. Яны знаходзяць свой печыва. Рэкламадаўцы, якія распавядаюць ім, я хачу кагосьці хто сярэдняга ўзросту, 40-гадовы мужчына, у спорце. І яны выйграюць вас у гэтых дэмаграфічных і яны вырашаюць, ці няма што гэта добрая рэклама для вас. 

Цяпер у іх ёсць SLA з іх рэкламныя правайдэры каб забяспечыць суб-10 мілісекунду Адказ на кожны запыт. Так яны выкарыстоўваюць Дынама DB для гэтага. Яны ўдару нам мільён запытаў у секунду. Яны ў стане зрабіць усё іх пошукі, сартаванне за ўсё, што дадзеныя, і атрымаць, што дадаць спасылку на што рэкламадаўца ва ўзросце да 10 мілісекунд. Гэта сапраўды даволі фенаменальны Рэалізацыя, што яны маюць. 

Гэтыя хлопцы actually-- Ці з'яўляюцца гэтыя хлопцы. Я не ўпэўнены, калі гэта гэтыя хлопцы. Можа быць гэтыя хлопцы. У асноўным сказаў us-- няма, я Не думаю, што гэта было іх. Я думаю, што гэта быў хто-то яшчэ. Я працаваў з кліент, які сказаў мне, што цяпер, калі яны пайшоў Дынама БД, яны марнаваць больш грошай на закусках для іх каманда распрацоўнікаў кожны месяц чым яны марнуюць на іх базе дадзеных. Так гэта дасць вам Ідэя эканоміі што вы можаце атрымаць у Дынама БД велізарны. Добра, dropcam іншай кампаніі. Гэтыя хлопец накшталт of-- калі вы думаеце, інтэрнэт рэчаў, dropcam у асноўным інтэрнэт-відэа бяспекі. Вы ставіце камеру там. Камера мае дэтэктар руху. Хто-то прыходзіць, запускае ключавую кропку. Камера пачынае запіс на некаторы час да ён не выяўляе ніякага руху больш. Кладзе гэта відэа на Інтэрнэце. 

Dropcam была кампанія, якая у асноўным перайшлі на Дынама БД таму што яны адчуваюць Вялізныя растуць болю. І тое, што яны сказалі нам раптам петабайт дадзеных. Яны паняцця не мелі, іх абслугоўванне будзе настолькі паспяховым. Больш ўваходзяць відэа YouTube, чым гэта тое, што гэтыя хлопцы атрымліваюць. Яны выкарыстоўваюць DynamoDB адсочваць усе метададзеныя ўсіх сваіх відэа ключавых момантаў. 

Такім чынам, яны маюць S3 вядра яны штурхаюць усе бінарныя артэфакты ст. І тады яны маюць Дынама DB запісу, пазначыць людзям на гэтых трох аб'ектаў S3. Калі яны павінны глядзець на відэа, яны глядзяць запіс у Дынама БД. Яны націсніце на спасылку. Яны цягнуць уніз відэа з S3. Так што накшталт як гэта выглядае. І гэта прама з сваёй каманды. 

Дынама БД памяншае іх час дастаўкі для відэа падзей ад пяці да 10 секунд. У сваёй старой рэляцыйнай краме, яны выкарыстоўвалі, каб мець, каб пайсці і выканаць некалькі складаных запытаў да постаці з якіх відэа, каб цягнуць ўніз, да менш чым за 50 мілісекунд. Так што гэта дзіўна, дзіўна колькі эфектыўнасць Вы можаце атрымаць, калі вы аптымізаваць і Вы наладжваеце асноўнай базе дадзеных падтрымаць доступу да файла. Halfbrick, гэтыя хлопцы, што гэта, Fruit Ninja Я думаю, гэта іх справа. Гэта ўсё працуе на Дынама БД. І гэтыя хлопцы, яны з'яўляюцца выдатным Каманда распрацоўнікаў, вялікае развіццё краму. 

Ня добры АСС каманда. Яны не маюць шмат эксплуатацыйных рэсурсаў. Яны змагаліся, спрабуючы захаваць іх інфраструктура прыкладанняў да і працуе. Яны прыйшлі да нас. Яны глядзелі на тое Дынама БД. Яны сказалі, што гэта для нас. Яны пабудавалі ўсю сваю Структура прыкладання на ім. Некаторыя сапраўды добрыя каментары тут ад каманды на іх здольнасці каб цяпер засяродзіцца на будаўніцтва гульня, а не таго, каб падтрымліваць інфраструктура, якая становіцца велізарная колькасць накладных расходаў для сваёй каманды. Так што гэта нешта that-- перавага, што вы атрымаеце ад Дынама БД. 

Добра, трапляючы ў мадэляванне дадзеных тут. І мы казалі трохі аб гэта адзін да аднаго, адзін да многіх, і многія да многіх адносін тыпу. А як вы падтрымліваеце тых, хто ў Дынама. У Дынама БД мы выкарыстоўваем Індэксы, наогул кажучы, круціць дадзеныя адзін густ да іншага. Хэш-ключы, ключы дыяпазон, і індэксы. 

У дадзеным канкрэтным Напрыклад, як і большасць дзяржаў ёсць патрабаванне ліцэнзавання, толькі ліцэнзія аднаго кіроўцы на чалавека. Вы не можаце пайсці, каб атрымаць двух кіроўцы ліцэнзіі ў штаце Бостан. Я не магу зрабіць гэта ў Тэхасе. Гэта накшталт таго, як гэта. І так у DMV, у нас ёсць аперацый пошуку, мы хачу паглядзець пасведчанне кіроўцы па колькасці сацыяльнага забеспячэння. Я хачу, каб паглядзець інфармацыю пра карыстальніка па колькасці ліцэнзій кіроўцы. 

Такім чынам, мы, магчыма, табліцу карыстальніка, што мае хэш-ключ на серыйны нумар, або нумар сацыяльнага страхавання, і розныя атрыбуты вызначаюцца па гэтым пункце. У цяперашні час на гэтай табліцы I можа вызначыць, што GSI пераварочвае, што вакол, што я хачу, кажа, ключавой хэш па ліцэнзіі, а затым ўсе іншыя прадметы. Цяпер, калі я хачу, каб запытваць і знайсці Нумар ліцэнзіі для любой сацыяльнай Нумар бяспекі, я магу запыт асноўную табліцу. 

Калі я хачу, каб запытаць і я хачу каб атрымаць сацыяльнае забеспячэнне нумар або іншыя атрыбуты з дапамогай нумар ліцэнзіі, я магу запытаць GSI. Гэтая мадэль, што адзін да аднаго адносіны. Проста вельмі просты GSI, фліп гэтыя рэчы. Цяпер, пагаворым аб адной для многіх. Адзін да многіх у асноўным Ваш ключ Дыяпазон хэш. Дзе мы атрымліваем шмат з гэтым Выкарыстанне выпадак дадзеныя манітора. Дадзеныя маніторынгу рэгулярна пастаўляецца ў Інтэрвал, як Інтэрнэт рэчаў. Мы заўсёды атрымліваем усё гэта запісы ў бліжэйшыя ўвесь час. 

І я хачу, каб знайсці ўсе паказанні паміж пэўны перыяд часу. Гэта вельмі распаўсюджаная ў запыт Маніторынг інфраструктуры. Шлях ісці аб тым, што гэта, каб знайсці простая структура табліцы, адна табліца. Я атрымаў табліцу вымярэнняў прыбора з ключом хэш на прыладу ID. І ў мяне ёсць ключ дыяпазону на пазнака, ці ў дадзеным выпадку, эпас. І, што дазваляе мне выканаць комплекс запыты да гэтага ключу дыяпазоне і вярнуцца тыя запісы, якія у параўнанні з вынікам Устаноўлена, што я шукаю. І ён будуе, што адна для многіх адносінах у асноўны табліцы, выкарыстоўваючы хэш ключа, дыяпазон ключавой структурай. 

Так што гэта свайго роду ўбудаваны ў табліцы ў БД Дынама. Калі я вызначыць хэш і дыяпазон т стол, я вызначэння адзін да многіх адносін. Гэта адносіны бацька-дзіця. 

Давайце пагаворым аб многіх многіх адносінах. І для гэтага канкрэтнага прыкладу, зноў жа, мы збіраемся выкарыстоўваць GSI-х. І давайце казаць аб гульнях сцэнар, дзе ў мяне ёсць дадзены карыстальнік. Я хачу, каб знайсці ўсе гульні, якія ён зарэгістраваны або гуляючы ў. А для дадзенай гульні, я хачу знайсці ўсіх карыстальнікаў. Так як я раблю гэта? Мой карыстальнікаў гульні стол, я збіраюся мець хэш-ключ ID карыстальніка і ключ дыяпазон гульні. 

Такім чынам, карыстальнік можа мець некалькі гульняў. Гэта адзін да многіх адносін паміж карыстальнік і гульні ён гуляе. А потым на GSI, Я фліп што вакол. Я хэш на гульні і Я дыяпазоне ад карыстальніка. Так што, калі я хачу, каб усе Гульня карыстальнік гуляе ў, Я запытваць асноўную табліцу. Калі я хачу, каб атрымаць усе карыстальнікі якія гуляюць пэўную гульню, Я запытаць GSI. Такім чынам, вы бачыце, як мы гэта робім? Вы будуеце для падтрымкі гэтых GSI гадоў Прэцэдэнт, прыкладанне, доступ ўзор, прыкладанне. 

Калі мне трэба запытаць на гэта вымярэнне, хай мне стварыць індэкс па гэтым вымярэнні. Калі я не раблю, я не хвалюе. І ў залежнасці ад выпадку выкарыстання, я магчыма, спатрэбіцца індэкс ці я не мог. Калі гэта проста адзін да многіх, асноўнай табліцы ў парадку. Калі мне трэба зрабіць гэта шмат, каб многія, або мне трэба зрабіць адзін для тых, то, магчыма, мне трэба на другое горада. Так што ўсё залежыць ад тое, што я спрабую зрабіць і тое, што я спрабую атрымаць дасведчаны. 

Верагодна, я не буду марнаваць занадта шмат часу казаць пра дакументы. Гэта становіцца трохі, напэўна, глыбей, чым мы павінны ісці ў. Давайце трохі пагаворым аб багатых выраз запыту. Такім чынам, у Дынама БД ў нас ёсць здольнасць ствараць што мы называем праекцыйныя выразы. Праекцыйныя выразы проста выбіраючы поля або значэння што вы хочаце, каб адлюстраваць. ОК, так што я магу зрабіць выбар. Я раблю запыт да БД Дынама. І я кажу, вы ведаеце, што, паказаць мяне толькі пяць водгукі зоркі для гэтага канкрэтнага прадукту. Так што ўсё, што я хачу бачыць. Я не хачу, каб убачыць усе іншыя атрыбуты радкі, Я проста хачу, каб гэта ўбачыць. Гэта проста, як і ў SQL, калі вы кажуць абярыце зорку або з табліцы, Вы атрымліваеце ўсе. Калі я кажу, абярыце імя з стол, я толькі адзін атрыбут. Гэта тое ж самае роду рэчы ў Дынама БД ці яшчэ базы дадзеных NoSQL. Фільтраваць выразы дазваляюць мне у асноўным скараціць набор вынікаў ўніз. Так што я зрабіць запыт. Запыт можа вярнуцца з 500 пунктаў. Але я хачу толькі тыя элементы, якія ёсць атрыбут, які кажа, што гэта. Такім чынам, давайце адфільтраваць гэтыя элементы якія не адпавядаюць гэтай канкрэтнай запыт. Такім чынам, мы маем выразы фільтра. 

Фільтраваць выразы могуць будзе працаваць на любы атрыбут. Яны не хацелі інтэрвальныя запыты. Павышэнне запыты больш выбарчым. Фільтраваць запыты патрабуюць ад мяне, каб пайсці атрымаць увесь набор вынікаў, а затым выразаць дадзеныя, якія я не хачу. Чаму гэта так важна? Таму што я чытаў усё гэта. У запыце, я буду чытаць і гэта будзе гіганцкі аб дадзеных. А потым я збіраюся выразаць тое, што мне трэба. І калі я толькі выразаючы пара радкоў, то гэта нармальна. Гэта не так неэфектыўна. 

Але калі я чытаю цэлы стос Дадзеныя, проста выразаць адзін элемент, затым я збіраюся быць лепш ад выкарыстання дыяпазону запыту, таму што гэта значна больш выбарачна. Гэта ўратуе мяне шмат грошы, таму што я плаціць за гэта чытанне. Калі вынікі, які вяртаецца перасекчы гэтую дрот можа быць менш, але я плачу за чытанне. Так разумею, як Вы атрымліваеце дадзеныя. Гэта вельмі важна ў Дынама БД. 

Ўмоўныя выразы, гэта тое, што Вы маглі б назваць аптымістычнай блакавання. Абнавіць, калі ёсць, ці, калі гэта значэнне эквівалентна таго, што я паказваю. І калі ў мяне ёсць штамп часу на запіс, я мог бы прачытаць дадзеныя. Я мог бы змяніць гэтыя дадзеныя. Я мог бы пайсці пішуць, што таму дадзеныя ў базу дадзеных. Калі хто-то змяніў запіс, адзнака часу можа быць зменены. І такім чынам мой ўмоўна абнаўленне можна сказаць, абнаўленне калі адзнака роўная гэтага. Або абнаўленне не будзе выканана, таму што хто-то абнавіў рэкорд у той жа час. 

Гэта тое, што мы называем аптымістычнае блякаваньне. Гэта азначае, што нехта можа прыйсці і змяніць яго, і я збіраюся выявіць яго калі я вярнуся, каб напісаць. І тады я магу на самой справе чытаць, што дадзеных і кажуць, ой, ён змяніў гэта. Мне трэба, каб ўлічыць гэта. І я магу змяніць дадзеныя ў маёй запісваць і ўжываць яшчэ адно абнаўленне. Такім чынам, вы можаце злавіць тых, дадатковых Абнаўлення, якія адбываюцца паміж часам што вы чытаеце дадзеныя і раз, калі вы маглі б напісаць дадзеныя. 

АЎДЫТОРЫЯ: І фільтр Выраз на самай справе азначае не нумар ці не-- 

[Рэле ГАЛАСЫ] РВК Хулихэном: Я не буду атрымаць занадта шмат у гэтым. Гэта зарэзерваваныя слова. Выгляд фунт стрыманы Ключавое слова ў Дынама БД. Кожная база дадзеных мае свой уласны абаронены Імёны для калекцый вы не можаце выкарыстаць. Дынама БД, калі вы пакажа фунт перад гэтым, Вы можаце вызначыць гэтыя імёны наверсе. Гэта эталонны значэнне. Гэта, верагодна, не самы лепшы сінтаксіс ёсць там для гэтай дыскусіі, таму што ён трапляе ў некаторых real-- Я быў бы гаварыць больш пра тое, што на больш глыбокім узроўні. 

Але досыць сказаць, што гэта магло б быць запыт сканавання, дзе яны views-- ні праглядаў фунт больш, чым 10. Гэта лікавае значэнне, так. Калі вы хочаце, мы можам казаць пра што пасля абмеркавання. Добра, так што мы ўваходзім у некаторыя сцэнары ў лепшых практык дзе мы будзем казаць аб некаторых праграмах тут. Якія варыянты выкарыстання для Дынама БД. Якія дызайн ўзоры ў Дынама БД. 

І першы, каго мы збіраемся размовы пра з'яўляецца Інтэрнэт рэчаў. Такім чынам, мы атрымліваем шмат of-- Я думаю, тое, што it-- больш за 50% трафіку ў інтэрнэце ў гэтыя дні фактычна генеруецца машынамі, аўтаматызаваныя працэсы, а не людзей. Я маю на ўвазе гэтую рэч гэтая рэч, што Вы насіць у кішэні, колькі дадзеных, што гэтая рэч на самай справе адпраўкі вакол без цябе ведаючы, што гэта зусім дзіўнае. Ваша месцазнаходжанне, інфармацыя аб тым, як хутка вы ідзяце. Як вы думаеце, Google Maps працы калі яны кажуць вам, што трафік. Гэта таму, што ёсць мільёны і мільёны людзей па ўсім ваджэння з тэлефонамі, якія пасылаюць Дадзеныя па ўсім месцы ўвесь час. Так адна з рэчаў, аб гэтым тыпе дадзеных што прыходзіць у дадзеныя манітора, увайсці Дадзеныя, дадзеных часовых шэрагаў, з'яўляецца яго як правіла, толькі цікава для трохі часу. Пасля гэтага часу, гэта не так цікава. Такім чынам, мы гаварылі, не дай гэтыя табліцы растуць без межаў. Ідэя тут у тым, што, можа быць, я атрымаў 24 гадзін коштам падзей у маім гарачай табліцы. І, што гарачы стол будзе падрыхтавана на вельмі высокай хуткасці, таму што ён прымае шмат дадзеных. Гэта займае шмат дадзеных , І я чытаю яго шмат. Я атрымаў шмат працы запыты працуе супраць гэтага дадзеных. 

Пасля 24 гадзін, эй, вы ведаеце, я не хвалюе. Так, можа быць, кожны поўнач я рол мой стол да новай табліцы і я вызвалення невыкарыстоўваемых гэтую табліцу. І я вазьму РКО-х і Ўніз WCU, таму што праз 24 гадзіны Я не працуе, як многія запыты да гэтых дадзеных. Так што я іду, каб выратаваць грошы. І, можа быць, праз 30 дзён я не нават трэба клапаціцца пра яго ўсё. Я мог бы ўзяць ВКУ-х усё, аж да аднаго, таму што вы ведаеце, што, гэта ніколі не збіраецеся атрымаць запіс. Дадзеныя 30 дзён. Гэта ніколі не мяняецца. 

І гэта амаль ніколі не адбываецца, каб атрымаць чытаць, так што давайце проста лічыць, што RCU да 10. І я эканомлю кучу грошай на гэта дадзеных і плаціць толькі за мае гарачыя дадзеных. Так што гэта важная рэч, каб шукаць на тое, калі вы глядзіце на часовых шэрагаў дадзеныя, якія паступаюць у ў аб'ёме. Гэтыя стратэгіі. Зараз, я мог дазволіць яго усе ідуць у той жа табліцы і хай гэтая табліца расці. У рэшце рэшт, я збіраюся см праблемы з прадукцыйнасцю. Я збіраюся мець, каб пачаць архіваванне некаторыя з гэтых дадзеных са стала, што не. 

Давайце лепш распрацоўваць прыкладанне так што вы можаце працаваць так добра. Так што гэта проста аўтамат у кодзе прыкладання. Апоўначы кожную ноч яна коціцца па стале. Можа быць, тое, што мне трэба, гэта слізгаценне Акно 24 гадзін дадзеных. Тады на рэгулярнай аснове я Выклік дадзеных са стала. Я абрэзкі яго з Крон праца, і я стаўлю яго на гэтых іншых табліц, што вам трэба. Так што, калі перакульванне працуе, гэта выдатна. Калі няма, абрэжце яе. Але давайце трымаць, што гарачы дадзеныя ад вашых халодных дадзеных. Гэта зэканоміць вам шмат грошай, і зрабіць вашыя табліцы больш дасканалых. Такім чынам, наступная рэч, мы пагаворым аб тым, каталог прадукцыі. Каталог тавараў па-за даволі часта кейс. Гэта на самай справе вельмі агульны шаблон што мы ўбачым у розных рэчаў. Вы ведаеце, Twitter для Напрыклад, гарачая твіт. Усё ідзе і хапаючы што ў твітэры. Каталог тавараў, я атрымаў продажы. Я атрымаў гарачую продаж. Я атрымаў 70000 запытаў у другое прышэсце для прадукту Апісанне з майго каталога. Мы бачым гэта на розніцу аперацыя зусім няшмат. Так як мы маем справу з гэтым? Там няма ніякага спосабу, каб справіцца з гэтым. Усе мае карыстальнікі хочуць, каб убачыць тая ж частка дадзеных. Яны прыходзяць у, адначасова. І ўсе яны рабіць запыты па той жа часткі дадзеных. Гэта дае мне, што гарачая клавіша, што вялікая чырвоная паласа на маёй карце, што нам не падабаецца. І гэта, як гэта выглядае. Так па маім ключавога прасторы я атрымліваю забіў пунктаў продажу. Я не атрымліваю нічога нідзе. 

Як вырашыць гэтую праблему? Ну, мы гэта з палегчыць кэша. Кэш, вы паклалі ў асноўным у аператыўнай памяці раздзел перад базе дадзеных. Нам удалося [Неразборліва] кэша, як вам можа стварыць свой уласны кэш, [неразборліва] Кэш [? в ,?], што вы хочаце. Пакладзем, што ў пярэдняй часткі базы дадзеных. І такім чынам вы можаце захоўваць гэтыя дадзеныя ад тых гарачых клавіш у гэтай кэш-памяці прастору і чытаць праз кэш. 

І тады большасць вашых чытае пачаць пошук, як гэта. Я атрымаў усё гэта кэш-парад тут і я нічога не атрымаў тут адбываецца таму што база дадзеных седзячы ззаду кэш і не чытае і не прыйсці да канца. Калі я змяніць дадзеныя ў базы дадзеных, у мяне ёсць для абнаўлення кэша. Мы можам выкарыстоўваць нешта як пары зрабіць гэта. І я растлумачу, як гэта працуе. Добра, паведамленнямі. E-mail, мы ўсё выкарыстоўваем электронную пошту. 

Гэта вельмі добры прыклад. У нас ёсць нейкі паведамленняў стала. І мы атрымалі паштовую скрыню і выходныя. Гэта тое, што SQL будзе Паглядзіце, як будаваць, што паштовую скрыню. Мы накшталт выкарыстоўваць той жа самы выгляд стратэгіі для выкарыстання GSI-х, GSI-х для майго паштовага скрыні і маёй выходныя. Так што я атрымаў паведамленні, якія паступаюць сыравіну у мае паведамленні табліцы. І першы падыход да гэтага можа быць, не гавораць, ОК, няма праблем. Я атрымаў зыходныя паведамленні. Паведамленні, якія паступаюць [неразборліва], ідэнтыфікатар паведамлення, гэта выдатна. Гэта мой адзіны хэш. Я збіраюся стварыць два GSI, адной для майго паштовага скрыні, па адным для майго выходныя. І першае, што я зраблю , Я скажу, мой ключ хэш будзе атрымальнік і Я збіраюся ўладкаваць на сённяшні дзень. Гэта фантастыка. Я атрымаў добры выгляд тут. Але ёсць невялікая праблема тут. І вы сутыкнецеся гэта рэляцыйныя базы дадзеных, а таксама. Яны называлі вертыкальна разбіццё. Вы хочаце, каб ваш вялікі дадзеныя ад вашых маленькіх дадзеных. 

І прычына, чаму, таму што я павінен ісці чытаць пункты, каб атрымаць атрыбуты. І калі мае органы ўсё тут, затым чытанне ўсяго некалькі пунктаў калі мой Даўжыня цела у сярэднім 256 кілабайт кожны, матэматыка становіцца даволі непрыгожа. Так што я хачу, каб прачытаць ўваходныя Давіда. Якія ўваходзяць Давіда мае 50 пунктаў. Сярэдняя і памер 256 кілабайт. Вось мой каэфіцыент канверсіі для РКО з'яўляецца чатыры кілабайта. 

ОК, давайце ісці з у канчатковым выніку, несупярэчны чытанне. Я да гэтага часу ёсць 1600-х РКО проста чытаць ўваходныя Давіда. Ай. Добра, зараз давайце падумаем пра тое, як працуе прыкладанне. Калі я знаходжуся ў паштовай дадатку і Я гляджу на маю паштовую скрыню, і я гляджу на целе кожнага паведамлення, няма, я гляджу на рэзюмэ. Я гляджу на толькі загалоўкі. Такім чынам, давайце будаваць структуру табліцы што больш падобна, што. 

Дык вось інфармацыя што мой працоўны працэс патрэбаў. Гэта ў маю паштовую скрыню GSI. Гэта дата, адпраўнік, прадметам, а затым ідэнтыфікатар паведамлення, які паказвае вярнуцца да табліцы паведамленняў дзе я магу атрымаць цела. Ну, гэта было б запісваць ідэнтыфікатары. Яны паказваюць назад да ідэнтыфікатары пункт на стале Дынама DB. Кожны індэкс заўсёды creates-- заўсёды мае элемент ID, як частка of--, што прыходзіць з індэксам. 

Добра. АЎДЫТОРЫЯ: Гэта кажа яго там, дзе ён захоўваецца? РВК Хулихэном: Так, ён кажа exactly--, што менавіта, што яна робіць. Гэта кажа, вось мой паўторна запіс. І гэта будзе паказваць яго назад у маёй паўторнай запісу. Дакладна. ОК, так што зараз маю паштовую скрыню з'яўляецца фактычна нашмат менш. І гэта на самай справе падтрымлівае працоўны працэс электроннай прыкладанне. Так маю паштовую скрыню, я націскаю. Я іду ўздоўж і я націскаю на паведамленні, што, калі мне трэба пайсці атрымаць цела, таму што я збіраюся перайсці на іншую пункт гледжання. Так што, калі вы думаеце, пра тып MVC ў рамкі, выгляд мадэлі кантролера. 

Мадэль змяшчае Дадзеныя пра тое, што патрэбы выгляд і кантролер ўзаемадзейнічае з. Калі я змяніць рамку пры Змяніць перспектыву, гэта нармальна, каб вярнуцца да Сервер і засяліць мадэль, таму што гэта тое, што чакае карыстальнік. Калі яны змяніць погляды, што, калі мы можам вярнуцца да базы дадзеных. Так электроннай пошты, націсніце. Я шукаю для цела. Паездка туды і назад. Перайсці атрымаць цела. 

Я чытаў шмат менш дадзеных. Я толькі чытаў, што органы Дэвід павінен, калі ён мае патрэбу ў іх. І я не гараць у 1600 РКО проста, каб паказаць сваю паштовую скрыню. Так што цяпер that-- гэта шлях што LSI або GSI-- я прашу прабачэння, GSI, будзе працаваць. Мы атрымалі наш хэш на атрымальніка. Мы атрымалі ключ дыяпазон на сённяшні дзень. І ў нас ёсць прагназуемыя атрыбуты што нам патрэбныя толькі для падтрымкі гледжання. 

Мы круцяцца, што для паштовага скрыні. Hash на адпраўніка. А па сутнасці, мы маем вельмі добры, чысты выгляд. І гэта мы basically-- ёсць добрыя паведамленні ў гэтую Табліца, якая распаўсюджваецца прыгожа, таму што гэта хэш толькі хэш паведамленне ID. І ў нас ёсць два індэкса, што круцяцца з той табліцы. Добра, так ідэя тут заключаецца ня трымаць вялікія дадзеныя і гэты невялікі дадзеныя разам. Partition вертыкальна, падзяліць гэтыя табліцы. Не чытайце дадзеныя, якія вы не павінны. Добра, гульнявой. Мы ўсе хацелі гульняў. Прынамсі, мне падабаецца гульні, то. Такім чынам, некаторыя з рэчаў, што мы маем справу з тым, калі мы думаем аб гульнях, ці не так? Gaming гэтыя дні, асабліва з мабільнага гульні, гэта ўсё аб мысленні. І я збіраюся павярнуць тут трохі ад DynamoDB. Я збіраюся прынесці ў некаторыя з абмеркавання вакол некаторых з іншыя тэхналогіі AWS. 

Але ідэя аб гульнях, каб думаць аб у тэрмінах інтэрфейсаў API інтэрфейсы, якія, наогул кажучы, HTTP і JSON. Гэта, як мабільныя гульні выгляд ўзаемадзейнічаюць з іх канцамі таму. Яны робяць JSON рэгістрацыю. Яны атрымліваюць дадзеныя, і ўсё гэта, наогул кажучы, у добрых інтэрфейсаў JSON. 

Такія рэчы, як завесці сяброў, атрымаць дадзеныя лідэраў, абмен, карыстацкі кантэнт, адсунуць да сістэмы, гэтыя тыпы рэчаў што мы збіраемся рабіць. Двайковыя дадзеныя актываў, гэтыя дадзеныя не можа сядзець у базе дадзеных. Гэта можа сядзець у Аб'ект магазін, правільна? Але база дадзеных будзе у канчатковым выніку кажу сістэму, распавядаючы прыкладанне куды ісці атрымаць яго. І непазбежна, мультыплэер серверы, на канец інфраструктуры таму, і прызначаны для высокага даступнасць і маштабаванасць. Такім чынам, гэтыя рэчы, якія мы ўсе хочам у гульнявым інфраструктуры сёння. 

Такім чынам, давайце зірнем на як гэта выглядае. Ёсць асноўны задні канец, вельмі простая. Мы атрымалі сістэму тут з некалькі зон даступнасці. Мы гаварылі пра АЗС у being-- думаю з іх у выглядзе асобных цэнтраў апрацоўкі дадзеных. Цэнтр Больш дадзеныя за AZ, але гэта нармальна, проста думаць пра іх як асобныя дадзеныя цэнтры, якія геаграфічна і вылучаюць віна. 

Мы збіраемся, каб мець выпадкі пара EC2. Мы збіраемся, каб мець некаторыя задняй часткі сервера. Можа быць, калі вы спадчына архітэктура, мы выкарыстоўваючы тое, што мы называем RDS, рэляцыйныя базы дадзеных. паслугі Можа быць MSSQL, MySQL, ці нешта падобнае. Гэта шлях шмат прыкладанняў прызначаныя сёння. 

Ну, мы маглі б пайсці з гэта калі мы маштабаваць. Мы пойдзем наперад і пакласці вядро там S3. І, што S3 вядро, а не служыць да тых аб'ектаў, з нашага servers-- мы маглі б гэта зрабіць. Вы ставіце ўсе вашы двайковы аб'екты на вашых серверах і вы можаце выкарыстоўваць гэтыя сервера выпадкі, каб служыць, што дадзеныя меры. Але гэта даволі дорага. 

Лепшы спосаб зрабіць гэта пайсці наперад і пакласці гэтыя прадметы ў S3 вядра. S3 з'яўляецца рэпазітары аб'екта. Ён пабудаваны спецыяльна для выступае гэтыя тыпы рэчаў. І хай тыя кліенты просяць непасрэдна з гэтых аб'ектаў вядра, разгрузіць серверы. Такім чынам, мы пачынаем маштабаваць тут. 

Зараз мы атрымалі карыстальнікі па ўсім свеце. Я атрымаў карыстальнікі. Мне трэба, каб змесціва лакальна размешчаны недалёка ад гэтых карыстальнікаў, правільна? Я стварыў вядро S3 як мой рэпазітары. І я фронт, які з размеркаванне CloudFront. 

CloudFront з'яўляецца кампакт-дыск і Змест сетку дастаўкі. У асноўным гэта бярэ дадзеныя, якія вы паказваеце і кэшуецца ўсё гэта праз Інтэрнэт так што карыстальнікі ва ўсім свеце могуць мець вельмі хуткі адказ, калі яны просяць гэтыя аб'екты. 

Такім чынам, вы атрымаеце ўяўленне. Вы накшталт выкарыстоўваючы ўсе аспекты AWS тут, каб атрымаць гэта зрабіць. І ў рэшце рэшт, мы кідаем у аўто маштабавання групы. Такім чынам, нашы выпадках AC2 нашых гульнявых сервераў, як яны пачынаюць атрымліваць заняты і больш занятымі і больш занятымі, яны проста круцяцца іншы Асобнік, спіна яшчэ адзін асобнік, спіна яшчэ адзін асобнік. Так тэхналогіі AWS мае, гэта дазваляе задаць параметры вакол якога серверы будуць расці. Такім чынам, вы можаце мець н колькасць сервераў там у любы момант часу. І калі ваш груз сыходзіць, яны будуць скароціцца колькасць будзе скарачацца. І калі нагрузка вяртаецца, гэта будзе расці назад, трывалае. 

Так што гэта выглядае выдатна. У нас ёсць шмат выпадкаў EC2. Мы можам кэша Пярэдняя баз дадзеных, паспрабаваць паскорыць базы дадзеных. Наступны пункт ціск як правіла, людзі бачаць гэта яны маштабаваць гульню з дапамогай рэляцыйная сістэма базы дадзеных. Божа, база дадзеных прадукцыйнасць страшна. Як мы можам палепшыць, што? Давайце паспрабуем пакласці кэш перад гэтым. 

Ну, кэш не працуе настолькі вялікі, у гульнях, ці не так? Для гульняў, напісанне з'яўляецца хваравітым. Гульні вельмі цяжкі напісаць. Кэш не працуе, калі вы напісаць цяжкіх, таму што вы заўсёды атрымаў абнавіць кэш. Вы абнавіць кэш, гэта не мае значэння для кэшавання. Гэта на самай справе проста дадатковая праца. 

Так, куды мы ідзем тут? У вас ёсць вялікі вузкае там у базе дадзеных. І месца, каб пайсці відавочна, падзелу. Разметка ня лёгка зрабіць, калі вы справу з рэляцыйнымі базамі дадзеных. З рэляцыйнымі базамі дадзеных, вы адказнасць за кіраванне, эфектыўна, прастору ключоў. Вы кажаце карыстальнікаў паміж А і М ідзі сюды, паміж N і Z туды. І вы пераходзіце па ўжыванні. Такім чынам, вы маеце справу з гэты раздзел крыніцы дадзеных. Вы павінны транзакцыйных абмежаванняў якія не ахопліваюць раздзелы. Вы атрымалі ўсе віды бязладзіцы, што вы справу з там спрабуюць мець справу з маштабаванне і будаўніцтва большага інфраструктуры. Гэта не проста не цікава. 

АЎДЫТОРЫЯ: Дык вы кажаце, што павелічэнне кропак крыніцы паскарае працэс? РВК Хулихэном: Павышэнне? АЎДЫТОРЫЯ: Крыніца пунктаў. РВК Хулихэном: Source кропкі? АЎДЫТОРЫЯ: З інфармацыі, дзе інфармацыя прыходзіць ад? РВК Хулихэном: Няма Тое, што я кажу, з'яўляецца павышэнне Колькасць раздзелаў у сховішча дадзеных паляпшае прапускную здольнасць. Так што тут адбываецца, карыстальнікі ўступлення ў экзэмпляры EC2 тут, Ну, калі мне трэба карыстачу Гэта М, я пайду сюды. Ад N р, я пайду сюды. З Р да Я, я пайду сюды. 

АЎДЫТОРЫЯ: ОК, так тыя, тыя захоўваюцца ў розных вузлах? 

РВК Хулихэном: Так. Падумайце пра іх, як розныя бункеры дадзеных. Такім чынам, вы таго, каб зрабіць гэта. Калі вы спрабуеце зрабіць гэта, калі вы спрабуеце у маштабе на рэляцыйнай платформе, гэта тое, што вы робіце. Вы прымаеце дадзеныя і вы рэзкі яго. І вы падзелу яго па некалькі асобнікаў базы дадзеных. І вы ўсё, што кіраванне на ўзроўні прыкладанняў. Гэта не весела. Так што мы хочам ісці? Мы хочам, каб перайсці DynamoDB, цалкам кіраваны, NoSQL сховішчы дадзеных, прадастаўленне прапускную здольнасць. Мы выкарыстоўваем другасныя індэксы. Гэта ў асноўным HTTP API і ўключае ў сябе падтрымку дакумента. Такім чынам, вы не павінны турбавацца аб любым з гэтага падзелу. Мы робім усё гэта для вас. Так што цяпер, замест гэтага, вы проста напішыце ў табліцы. Калі табліца павінна быць падзелена, што адбываецца за кулісамі. Вы цалкам ізаляваны ад як распрацоўшчык. Такім чынам, давайце пагаворым аб некаторыя з выпадкаў выкарыстання што мы бяжым у ў гульнях, агульная гульнявыя сцэнары, лідэраў. Такім чынам, вы атрымалі карыстальнікі ў бліжэйшыя, у BoardNames, што яны на, балы для гэтага карыстальніка. Мы маглі б быць хэшавання на UserID, а то ў нас асартымент на гульню. Такім чынам, кожны карыстальнік хоча бачыць Усе гульні ён гуляў і ўсе яго найвышэйшы бал па ўсёй гульні. Так што яго асабістая лідэраў. 

Цяпер я хачу, каб пайсці і я хачу, каб get-- так што я атрымліваю гэтыя асабістыя лідэраў. Тое, што я хачу зрабіць, гэта пайсці атрымаць верхняя адзнака для ўсіх карыстальнікаў. Так як я раблю гэта? Калі мой рэкорд хэшируется на Гэты ідэнтыфікатар, вар'іраваліся ад гульні, а я збіраюся ісці наперад і рэструктурызацыі, стварыць GSI, і я збіраюся правесці рэструктурызацыю гэтых дадзеных. 

Цяпер я збіраюся, каб праясніць на BoardName, што гульня. І я збіраюся ў дыяпазоне ад найвышэйшы бал. А цяпер я стварыў розныя вядра. Я выкарыстоўваю тую ж табліцу, тыя ж самыя дадзеныя. пункт Але я ствараю вядро, што дае мне агрэгацыя найвышэйшы бал па гульні. 

І я магу запытаць гэтую табліцу каб атрымаць гэтую інфармацыю. Так я ўсталяваў, што ўзор запыту да падтрымлівацца другаснага азначніка. Цяпер яны могуць быць адсартаваныя па BoardName і сартуюцца па TopScore, у залежнасці ад. Такім чынам, вы можаце бачыць, гэта тыпу прэцэдэнтаў вы атрымаеце ў гульнях. Яшчэ адзін добры варыянт выкарыстання мы атрымліваем у гульнях гэта ўзнагароды і хто выйграў ўзнагароды. І гэта вялікі кейс дзе мы называем разрэджаных індэксаў. Рэдкія індэксы з'яўляюцца Здольнасць генераваць індэкс, які не абавязкова ўтрымлівае кожны пункт на стале. А чаму не? Паколькі атрыбут, які быўшы індэксавацца не існуе па кожным пункце. 

Такім чынам, у гэты канкрэтны выкарыстоўваць выпадак, я кажу, Вы ведаеце, што я збіраюся стварыць атрыбут прэміі. І я збіраюся даць кожнаму карыстальніку што мае ўзнагароды, якія прыпісваюць. Людзі, якія не маюць ўзнагароды не будзе мець гэты атрыбут. Таму, калі я стварыць Індэкс, толькі карыстальнікі якія збіраюцца, каб паказаць ў індэксе тыя, якія на самай справе выйгралі ўзнагароды. Так што гэта выдатны спосаб, каб мець магчымасць стварыць адфільтраваць індэксы, вельмі, вельмі выбарча, што не павінны індэксаваць ўсю табліцу. 

Так мы атрымліваем мала часу тут. Я збіраюся ісці наперад і прапусціць , І прапусціць гэты сцэнар. Пагаворыце трохі about-- 

АЎДЫТОРЫЯ: Ці магу я задаць хуткі пытанне? Адным з іх з'яўляецца цяжкім напісаць? РВК Хулихэном: Што такое? АЎДЫТОРЫЯ: Напісаць цяжкім. РВК Хулихэном: Напісаць цяжкім. Дазвольце мне бачыць. 

АЎДЫТОРЫЯ: Ці гэта не тое, што вы можаце проста Голас у лічаныя секунды? РВК Хулихэном: Мы ідзем праз сцэнары галасавання. Гэта не так ужо дрэнна. Ці ёсць у вас, хлопцы, ёсць некалькі хвілін? ДОБРА. 

Такім чынам, мы будзем казаць аб галасаванні. Так у рэжыме рэальнага часу галасавання, у нас ёсць Патрабаванні для галасавання. Патрабаванні, якія мы дазволіць кожны чалавек, каб галасаваць толькі адзін раз. Мы хочам, каб ніхто не зможа змяніць свой голас. Мы хочам, агрэгацыю ў рэжыме рэальнага часу і аналітыка для дэмаграфіі што мы збіраемся, каб быць паказваючы карыстальнікаў на сайце. 

Падумайце пра гэта сцэнары. Мы шмат працуем рэальнасці Тэлевізар паказвае, дзе яны робіць гэтыя дакладны тып рэчаў. Такім чынам, вы можаце думаць пра сцэнар, у нас ёсць мільёны і мільёны дзяўчыны падлеткавага там з іх сотавых тэлефонаў і галасаванне, і галасаванне, і галасаванне для тых, хто іх знайсці, каб быць самым папулярным. Дык вось некаторыя з Патрабаванні ў нас скончыліся. 

І таму першы ўзяць ў вырашэнні гэтай праблемы будзе будаваць вельмі простае прыкладанне. Так што я атрымаў гэта дадатак. У мяне ёсць некалькі выбаршчыкаў там. Яны прыходзяць у, яны патрапілі ў дадатак галасавання. У мяне ёсць сырое галасоў табліцу Я проста звалка гэтыя галасы ст. Я ёсць сукупнасць галасоў табліца, зробіць мае аналітыкі і дэмаграфіі, і мы паставім усё гэта там. 

І гэта выдатна. Жыццё добрая. Жыццё добрая, пакуль мы не даведаемся, што заўсёды ёсць толькі адзін ці два людзі, якія карыстаюцца папулярнасцю на выбарах. Там толькі адзін ці дзве рэчы, што людзі сапраўды клапоцяцца аб. І калі вы галасуеце на маштаб, раптам я будзе малатком пекла з два кандыдаты, адзін ці два кандыдаты. Вельмі абмежаваную колькасць пунктаў людзі лічаць, каб быць папулярным. 

Гэта не добры дызайн мадэлі. Гэта на самай справе вельмі дрэнна шаблон таму што гэта стварае тое, што мы казалі аб якой было гарачыя клавішы. Гарачыя клавішы з'яўляюцца чымсьці нам не падабаецца. 

Такім чынам, як мы гэта выправіць? І на самай справе, то, як выправіць гэта прымаючы тыя кандыдатаў вядра і для кожнага кандыдата мы маем, мы збіраемся дадаць выпадковае значэнне, тое, што мы ведаем, выпадковая Значэнне паміж адным і 100, паміж 100 і 1000, або ад аднаго да 1000, Аднак многія выпадковыя велічыні вы хочаце дадаць у канец гэтага кандыдата. 

І што я сапраўды зрабіў тое? Калі я выкарыстоўваю ідэнтыфікатар кандыдата як вядро для сукупных галасоў, калі я дадаў выпадковы Колькасць да канца, што, Я стварыў ўжо 10 вёдраў, А сто вёдраў, тысячы вядра што я агрэгавання галасоў папярок. 

Так што ў мяне мільёны і мільёны, і мільёны запісаў у бліжэйшыя для гэтых кандыдатаў, я зараз распаўсюджваецца гэтыя галасы праз кандыдат A_1 праз кандыдат A_100, таму што кожны раз, калі галасаванне ідзе ў, Я генерацыі выпадковых Значэнне паміж адным і 100. Я лавіруючы яго на канцы Кандыдат, які чалавек, хто галасуе за. Я скід яго ў гэтым вядры. 

Цяпер на адваротным, я ведаю, што я атрымаў сто вёдраў. Так што, калі я хачу, каб ісці наперад і агрэгаваць галасоў, Я чытаў ад усіх гэтых вёдрах. Так што я ісці наперад і дадаць. І тады я роскід сабраць дзе я выходжу і кажу эй, Вы ведаеце, што, ключ гэтага кандыдата прастор больш за сто вядра. Я збіраюся сабраць усе галасоў ад тых ста вядра. Я збіраюся аб'яднаць ім, і я збіраюся сказаць, Кандыдата ў цяперашні час Агульная Падлік галасоў ад х. 

Цяпер абодва запісу запыт і запыт чытання прыгожа размеркаваны таму што я пішу па і я чытаю на сотні ключоў. Я не пішу і чытаць па адным ключу ў цяперашні час. Так што гэта вялікі малюнак. 

Гэта на самай справе, верагодна, адзін з найбольш важных дызайн шаблоны для маштабу ў NoSQL. Вы ўбачыце гэты тып шаблон ў любы густ. MongoDB, DynamoDB, гэта не Справа, усе мы павінны зрабіць гэта. Таму што, калі вы маеце справу з тых велізарных навал, Вы павінны высветліць, шлях да распаўсюджваць іх па ўсёй вядра. Так што гэта, як вы робіце гэта. Добра, так, што Вы робіце прама цяпер гэта вы будзеце гандляваць з чытання Кошт для запісу маштабаванасці. Кошт маёй чытання крыху больш складана і я павінен ісці чытаць з сто вёдраў замест аднаго. Але я магу напісаць. І мая прапускная здольнасць, мая запісу прапускная здольнасць неверагодна. Так што, як правіла, з'яўляецца каштоўным Тэхніка для маштабавання DynamoDB, або любая база дадзеных NoSQL па гэтым пытанні. Такім чынам, мы высветлілі, як маштабаваць яго. І мы зразумелі, як ліквідаваць нашы гарачыя клавішы. І гэта фантастыка. І мы атрымалі гэтую добрую сістэму. І гэта дае нам вельмі правільную галасаванне таму што ў нас запіс галасоў дэ-дурня. Ён пабудаваны ў DynamoDB. Мы гаварылі аб умоўных правоў. 

Калі выбаршчык прыходзіць, ставіць устаўка на стале, яны ўстаўляюць іх выбаршчыкаў ID, калі яны спрабуюць ўставіць іншы голас, Я раблю ўмоўнае запісу. Скажыце толькі напісаць гэта калі гэта не існуе. Таму, як толькі я бачу, што што галасаванне ў хіт табліцу, ніхто не будзе ў стане паставіць свой голас у. І гэта фантастыка. І мы павялічваючы Наш кандыдат лічыльнікі. І мы робім усё дэмаграфічныя і ўсё такое. Але што адбудзецца, калі мой Дадатак падае? Зараз усе раптам галасоў ідуць, і я не ведаю, калі яны атрымліваюць апрацоўваюцца ў маіх аналітыкі і дэмаграфіі больш. І калі прыкладанне вяртаецца ўверх, як , Чорт вазьмі, я ведаю, што ёсць галасы былі апрацаваны і дзе я магу пачаць? 

Так што гэта рэальная праблема, калі вы пачынаюць глядзець на гэтага тыпу сцэнара. І як мы вырашым, што? Мы вырашаем яе з тым, што мы патэлефанаваць DynamoDB патокаў. Патокі заказваецца час і размяркоўваюць часопіс змяненняў кожнага доступу да стала, кожны напісаць Доступ да табліцы. Любыя дадзеныя, якія напісаў у Табліца паказвае ўверх у струмені. 

Гэта ў асноўным чарзе 24 гадзіны. Прадметы ударыў паток, яны жывуць на працягу 24 гадзін. Яны могуць быць прачытаныя некалькі разоў. Гарантавана будуць дастаўлены толькі адзін раз у паток, можа быць прачытаны п колькасць разоў. Так многія працэсы, аднак вы хочаце спажываць гэтыя дадзеныя, вы можаце спажываць. Ён з'явіцца кожнае абнаўленне. Кожны запісу будзе толькі з'яўляюцца раз у струмені. Такім чынам, вы не павінны турбавацца аб апрацоўцы яго двойчы з таго ж працэсу. 

Гэта строга загадаў кожным пункце. Калі мы кажам, час замовіць і размяркоўваюць, Вы ўбачыце ў раздзеле на паток. Вы ўбачыце прадметы, абнаўлення ў парадку. Мы не гарантуючы на патоку, што ты збіраецца атрымаць кожную здзелку у парадку праз прадметы. 

Так патокі идемпотентная. Хіба мы ўсе ведаем, што идемпотент азначае? Идемпотентный азначае, што вы можаце зрабіць гэта зноў, і зноў, і зноў. Вынік будзе той жа. 

Патокі идемпотентны, але яны павінны быць гуляў з адпраўной кропкі, дзе б вы ні абралі, да канца, або яны не будуць прыводзіць ў тых жа значэнняў. 

Тое ж самае з MongoDB. MongoDB мае канструкцыю яны называюць oplog. Гэта сапраўды такі ж канструкцыяй. Многія базы дадзеных NoSQL ёсць гэтую канструкцыю. Яны выкарыстоўваюць яго, каб рабіць рэчы, як рэплікацыя, якая менавіта тое, што мы робім з патокамі. АЎДЫТОРЫЯ: Можа быць, ерэтычныя пытанне, але вы казаць пра прыкладання робіш гэтак далей. Ручаі гарантавана ня магчыма ісці ўніз? РВК Хулихэном: Так, патокі гарантавана ніколі не ўвойдзе. Мы кіраваць інфраструктурай ззаду. патокі аўтаматычна разгарнуць у іх аўто маштабавання групы. Мы пойдзем праз маленькі крыху аб тым, што адбываецца. 

Я не павінен сказаць, што яны не гарантавана ніколі не ідуць ўніз. Элементы гарантуецца з'яўляюцца ў патоку. І паток будзе даступны. Так што ідзе ўніз або вяртаецца уверх, што адбываецца ўнізе. Гэта covers-- гэта нармальна. Добра, так што вы атрымаеце розныя Тыпы від на экране. Тыпы меркаванне, што важныя да праграміст, як правіла, з'яўляюцца, што гэта было? Я стары выгляд. Калі абнаўленне парад табліцу, яна будзе націснуць ранейшымі да патоку так што дадзеныя можна заархіваванага, або змяненне кантроль, ідэнтыфікацыя змены, змены Кіраванне. 

Новы вобраз, то, што гэта зараз, пасля абнаўленне, гэта іншы тып гледжання вы можаце атрымаць. Вы можаце атрымаць абодва старыя і новыя вобразы. Можа быць, я хачу іх абодвух. Я хачу, каб паглядзець, што гэта было. Я хачу, каб паглядзець, што ён змяніўся. 

У мяне ёсць тып адпаведнасці працэсу, які працуе. Ён павінен пераканацца, што калі гэтыя рэчы мяняюцца, што яны ў пэўных межах або на працягу пэўных параметраў. 

І тады, магчыма, я толькі трэба ведаць, што змянілася. Мяне не хвалюе, які элемент змяніўся. Мне не трэба, каб ведаць якія атрыбуты змянілася. Мне проста трэба ведаць, што дэталі дотыку. Такім чынам, гэтыя тыпы выглядам што вы атрымліваеце ад патоку і вы можаце ўзаемадзейнічаць з. 

Дадатак, спажывае паток, гэта свайго роду, як гэтая працуе. Кліент DynamoDB папрасіць перадаваць дадзеныя ў табліцы. Патокі разгарнуць на тое, што мы называем аскепкі. Аскепкі маштабуюцца незалежна ад табліцы. Яны не выстройваюцца цалкам да раздзелаў вашага стала. І прычына, чаму гэта таму што яны выстройваюцца з магутнасцю, ток Ёмістасць табліцы. 

Яны выкарыстоўваюць у сваіх ўласнага аўто маштабаванне групы, і яны пачынаюць круціцца з залежнасці на колькі запісу ідуць у, колькі reads-- на самай справе гэта піша. Там няма reads-- але як многія запісы ідуць у. 

А потым на спіне канец, мы маем тое, што выклікаць KCL, або бібліятэка Kinesis кліента. Кинезис з'яўляецца струмень дадзеных Тэхналогія апрацоўкі ад Amazon. І патокі пабудаваны на гэтым. 

Такім чынам, вы выкарыстоўваць уключаны тое, KCL Прыкладанне для чытання струмень. Бібліятэка Кинезис Кліент фактычна кіруе працаўнікоў для вас. І гэта таксама робіць некаторыя цікавыя рэчы. Гэта створыць некалькі табліц да у таблічным DynamoDB адсочваць, якія элементы былі апрацаваны. Так што гэта шлях, калі ён падае таму, калі гэта падае і прыходзіць і атрымлівае стаяў назад, ён можа вызначыць, дзе гэта было ў апрацоўцы патоку. 

Гэта вельмі важна, калі Вы кажаце пра рэплікацыі. Мне трэба ведаць, што быў дадзеныя былі апрацаваны і якія дадзеныя яшчэ павінны быць апрацаваны. Такім чынам, бібліятэка, KCL для патокаў будзе даць вам шмат гэтай функцыянальнасці. Ён клапоціцца пра ўсіх гаспадаркай. Ён стаіць на работніка для кожнага асколка. Гэта стварае адміністрацыйную табліцу для кожнага асколка, для кожнага работніка. І, як тыя работнікі агонь, яны падтрымліваюць гэтыя табліцы так што вы ведаеце гэтую запіс быў чытаць і апрацоўваюцца. А потым, што шлях, калі працэс памірае і вяртаецца ў Інтэрнэце, ён можа аднавіць права, дзе ён зняў. 

Таму мы выкарыстоўваем гэта для крос-рэгіён рэплікацыі. Шмат кліентаў ёсць патрэба ў перамяшчаць дадзеныя або часткі сваіх табліц дадзеных вакол розных рэгіёнах. Ёсць дзевяць рэгіёнаў ва ўсім свеце. Так што можа быць я need-- можа ёсць карыстальнікі ў Азіі, карыстальнікі на ўсходнім узбярэжжы Злучаных Штатаў. Яны маюць розныя дадзеныя, што Неабходна лакальна размеркаванай. І, можа быць, карыстальнік рэйсы з Азія да ЗША, і я хачу, каб паўтарыць яго дадзеныя з ім. Так што, калі ён атрымлівае ад самалёта, ён мае добры вопыт, выкарыстоўваючы свой мабільны дадатак. 

Можна выкарыстоўваць перакрыжаванае вобласць Бібліятэка рэплікацыі для гэтага. У асноўным у нас ёсць пры ўмове, дзве тэхналогіі. Адзін гэта кансольнае прыкладанне вы можаце ўстаць на вашым асобніку EC2. Яна працуе чыста рэплікацыі. А потым мы далі вам бібліятэку. Бібліятэка вы можаце выкарыстоўваць, каб пабудаваць ўласнае прыкладанне, калі вам хачу зрабіць вар'яты рэчы з гэтым data-- фільтр, паўтарыць толькі яго частка, круціць дадзеныя, перамясціць яго ў адрозніваецца стол, гэтак далей, і гэтак далей. Так што накшталт як гэта выглядае. 

DynamoDB Патокі могуць быць апрацоўваюцца, што мы называем Lambda. Мы ўжо згадвалі трохі пра падзею кіраваныя архітэктуры прыкладанняў. Лямбда з'яўляецца ключавым кампанентам гэтага. Лямбда-код, які страляе па патрабаванні у адказ на канкрэтнае падзея. Адзін з гэтых падзей можа быць з'яўляючыся на струмені запіс. Калі запіс на патоку з'яўляецца, мы будзем называць гэтую функцыю Java. Ну, гэта JavaScript, і лямбда падтрымлівае Node.js, Java, Python, і хутка падтрымліваць іншыя мовы, а таксама. І дастаткова сказаць, што гэта чысты код. напісаць у Java, вы вызначаеце клас. Вы націскаеце на JAR ўверх у Lambda. А потым вы задаяце, які клас называць у адказ на падзею, якое. І тады інфраструктура Лямбда за які будзе працаваць гэты код. 

Гэты код можа апрацоўваць запісы прэч патоку. Гэта можа рабіць усё, што жадае з ёй. У гэтым канкрэтным прыкладзе, усе мы сапраўды робіце ўваходу атрыбуты. Але гэта толькі код. Код можа зрабіць што-небудзь, ці не так? 

Такім чынам, вы можаце круціць гэтыя дадзеныя. Вы можаце ствараць вытворныя выгляд. Калі гэта структура дакумента, Вы можаце згладзіць структуру. Вы можаце стварыць альтэрнатыўныя індэксы. Ўсе віды рэчаў, вы можаце рабіць з DynamoDB патокаў. 

І на самай справе, гэта, як гэта выглядае. Такім чынам, вы атрымліваеце гэтыя абнаўлення ў бліжэйшыя. Яны сыходзіць радок. Яны счытваюцца функцыяй Lambda. Яны круцячы дадзеныя і штурхаючы яго ў вытворных табліцах, паведаміўшы знешніх сістэм змены, і перадаючы дадзеныя ў ElastiCache. 

Мы гаварылі пра тое, як паставіць кэш перад базе дадзеных для гэтай продажаў сцэнар. Ну, што адбудзецца, калі я абнавіць апісанне тавару? Ну, калі я быў Лямбда Функцыя працуе на гэтым стале, калі я абнавіць апісанне тавару, ён будзе падабраць запіс з патокам, і гэта абнаўленне ElastiCache Асобнік з новымі дадзенымі. Так што гэта шмат Што мы робім з Lambda. Гэта клей код, раздымы. І гэта на самай справе дае здольнасць да запуску і працаваць вельмі складаных прыкладанняў без выдзеленага сервера інфраструктура, якая на самай справе выдатна. 

Такім чынам, давайце вернемся да нашага у рэжыме рэальнага часу архітэктура галасавання. Гэта новы і палепшаны з нашым патокі і, KCL уключаны прыкладання. Тое ж самае, як і раней, мы можам справіцца з любой маштаб выбараў. Нам падабаецца гэта. Мы робім з роскіду збірае па некалькіх вядра. У нас ёсць аптымізм замак адбываецца. Мы можам трымаць нашы выбаршчыкі ад змены іх галасы. Яны могуць галасаваць толькі адзін раз. Гэта фантастыка. У рэжыме рэальнага часу адмоваўстойлівасць, маштабуецца агрэгацыя сучаснасць. Калі рэч падае, гэта ведае, дзе перазапусціць сябе калі ён вяртаецца, таму што мы выкарыстоўваем прыкладанне KCL. І тады мы можам таксама выкарыстоўваць, што Дадатак KCL перадаваць дадзеныя з у чырвонае зрушэнне для іншых дадатак аналітыка, або выкарыстанне Эластычны MapReduce для запуску у рэжыме рэальнага часу струменевае навалы прэч гэтыя дадзеныя. 

Такім чынам, гэтыя рэчы, якія мы не казаў пра многае. Але яны дадатковая тэхналогіі, якія прыходзяць несці, калі вы шукаеце на гэтых тыпах сцэнарыяў. 

Добра, так гэта пра аналітыка з DynamoDB патокаў. Вы можаце сабраць дэ-дурня Дадзеныя, зрабіць усё віды з добрых рэчаў, сукупныя дадзеныя ў памяці, ствараць вытворныя гэтых табліц. Гэта велізарны кейс што шмат кліентаў удзельнічаюць з, прымаючы укладзены ўласцівасці гэтых дакументаў JSON і стварэння дадатковых індэксаў. 

Мы ў канцы. Дзякуй за падшыпнік са мной. Такім чынам, давайце пагаворым аб Эталонная архітэктура. DynamoDB сядзіць у сярэдзіне, так вялікая частка інфраструктуры AWS. Увогуле, вы можаце падключыць яго да ўсяго, што вы хочаце. Прыкладанні на платформе Дынама ўключаюць Лямбда, ElastiCache, CloudSearch, перадаць дадзеныя з пругкай ў MapReduce, экспарт імпарт з DynamoDB у S3, усіх відаў тэхналагічных працэсаў. Але, напэўна, самы лепшы што казаць, і гэта тое, што на самой справе Цікава, калі мы казаць аб прыкладанняў, якія кіруюцца падзеямі. 

Гэта з'яўляецца прыкладам Унутраны праект што ў нас ёсць, дзе мы на самай справе выдавецтва, каб сабраць вынікі абследавання. Такім чынам, у электроннай сувязі, што мы пашлем па-за, там будзе трохі спасылку кажучы націсніце тут, каб адказаць на абследавання. І калі чалавек націскае што спасылка, што адбываецца гэта яны цягнуць уніз бяспечны HTML-формы апытання з S3. Там няма сервера. Гэта проста аб'ект S3. 

Гэтая форма падыходзіць, загружае ў браўзэры. Ён атрымаў хрыбетніка. Ён атрымаў комплекс JavaScript што ён працуе. Так што гэта вельмі багаты прыкладанне працуе ў браўзэры кліента. Яны не ведаюць, што яны не ўзаемадзейнічаюць з заднім серверы. На дадзены момант, гэта ўсё-браўзэр. 

Яны публікуюць вынікі да таго, што мы называем Amazon API Gateway. Шлюз API гэта проста Web API што вы можаце вызначыць і падключыць усё, што вы хочаце. У дадзеным канкрэтным выпадку, мы падключылі да лямбда-функцыі. 

Так мой пост аперацыя адбываецца без сервера. У асноўным гэта шлюза API сядзіць там. Гэта не варта мне нічога, пакуль людзі Пачатак публікацыі на яго, праўда? Функцыя Лямбда проста сядзіць там. І гэта не варта мне нічога, пакуль людзі пачынаюць дубасіць яго. Такім чынам, вы можаце бачыць, як аб'ём павялічваецца, што, калі абвінавачванні прыйшлі. Я не працуе сервер 7/24. 

Так што я цягнуць форму ўніз з вядра, і я адпраўляю праз API Шлюз у лямбда-функцыі. І тады Лямбда Функцыя кажа, вы ведаеце, тое, што я атрымаў некаторыя PIIs, некаторыя персанальная інфармацыя у гэтых адказах. Я атрымаў каментары, якія паступаюць ад карыстальнікаў. Я атрымаў адрасы электроннай пошты. Я атрымаў імёны. 

Дазвольце мне падзяліць гэта ад. Я збіраюся генераваць некаторыя метададзеныя ад гэтага запісу. І я збіраюся націснуць метададзеныя ў DynamoDB. І я мог бы зашыфраваць усе дадзеныя, і ўстаўце яго ў DynamoDB, калі я хачу. Але гэта лягчэй для мяне, у гэтым выкарыстоўваць выпадак, каб ісці наперад і кажа: Я збіраюся вылучыць зыходныя дадзеныя ў зашыфраваным S3 вядра. Так што я выкарыстоўваю убудаваны ў баку сервера S3 шыфравання і кіравання ключамі ад Amazon Абслугоўванне так што ў мяне ёсць ключ, які можа круціцца на чарговы інтэрвал, і я магу абараніць, што PII дадзеныя як частка ўсёй гэтай працоўнага працэсу. 

Так што я зрабіў? Я толькі што разгорнута цэлая прыкладанняў і ў мяне няма сервера. Так што падзейную прыкладання архітэктура робіць для вас. 

Цяпер, калі вы думаеце пра прэцэдэнт для this-- у нас ёсць іншыя кліенты я казаць каб пра гэта хто дакладнай архітэктуры запусціць фенаменальна вялікія кампаніі, якія глядзім на гэта і адбываецца, пра мой. Таму што цяпер, яны могуць у асноўным штурхаць яго там, хай гэтую кампанію проста сядзець там, пакуль не запускае, а не прыйдзецца турбавацца аб дулю Якая інфраструктура будзе там, каб падтрымаць яго. А потым, як толькі што кампанія будзе зроблена, гэта як інфраструктуры проста адразу сыходзіць таму што сапраўды няма інфраструктуры. Гэта проста код, які сядзіць на Lambda. Гэта проста дадзеныя, якія сядзіць у DynamoDB. Гэта дзіўны спосаб для стварэння прыкладанняў. 

АЎДЫТОРЫЯ: Так гэта больш, эфемерная, чым гэта было б калі ён быў захаваны на сэрвэры фактычнай? 

РВК Хулихэном: Вы маеце рацыю. Таму што гэтага асобніка сервера б быць 7/24. Ён павінен быць даступны для каб хтосьці рэагаваць. Ну думаю, што? S3 даступны 7/24. S3 заўсёды адказвае. І S3 з'яўляецца вельмі, вельмі добра на абслугоўванне да аб'ектаў. Гэтыя аб'екты могуць быць HTML файлы, або Файлы JavaScript, або што вы хочаце. Вы можаце запусціць вельмі багатыя вэб-прыкладанняў з S3 вядра, і людзі. 

І так вось ідэя тут каб атрымаць ад шляху мы выкарыстоўвалі, каб думаць пра гэта. Мы ўсе прывыклі думаць, у Умовы сервераў і хастоў. Гэта не пра тое, што больш. Гэта аб інфраструктуры, як код. Разгортванне кода ў воблаку, і хай воблака запусціць яго для вас. І гэта тое, што AWS спрабуе зрабіць. 

АЎДЫТОРЫЯ: Так ваш залаты скрынцы ў сярэдзіне у API шлюзу не сервер, як, але замест гэтага просто-- 

РВК Хулихэном: Вы можаце думаць пра яго, як сервера фасада. Усё гэта ён будзе прымаць HTTP запытваць і супаставіць яго з іншым працэсам. Гэта ўсё, што ён робіць. І ў гэтым выпадку, мы адлюстраванне гэта функцыя лямбда. Добра, так што гэта ўсё, што я атрымаў. Дзякуй вельмі шмат. Я цаню гэта. Я ведаю, мы хочам трохі на працягу доўгага часу. І, спадзяюся, вы, хлопцы, ёсць трохі інфармацыі што вы можаце забраць сёння. І я прашу прабачэння, калі я пайшоў над некаторымі з вашых кіраўнікоў, але ёсць добры шмат фундаментальныя базавыя веды Я думаю, што вельмі каштоўна для вас. Так што дзякуй вам за тое, што мне. [Апладысменты] АЎДЫТОРЫЯ: [неразборліва] калі вы казалі Вы павінны былі прайсці праз рэчы ад пачатку да канца каб атрымаць правільныя значэння або тыя ж значэння, Як бы значэння змяніць, калі [неразборліва]. 

РВК Хулихэном: О, идемпотентным? Як бы змяніць значэння? Ну, таму што, калі я не запусціць усё гэта шлях да канца, то я не ведаю, якія змены былі зробленыя ў апошняй мілі. Гэта не збіраецца быць Тыя ж дадзеныя, як тое, што я ўбачыў. АЎДЫТОРЫЯ: О, так ты проста не атрымалі ўвесь ўваходны. РВК Хулихэном: Дакладна. Вы павінны ісці ад пачатку да канца, а затым гэта будзе паслядоўнай дзяржаўнай. Прахладны. 

АЎДЫТОРЫЯ: Такім чынам, вы паказалі нам DynamoDB можна зрабіць дакумент або ключавое значэнне. І мы патрацілі шмат часу на значэнне ключа з хэш і шляхі каб перавярнуць яго вакол. Калі вы глядзелі на гэтых табліцах, з'яўляецца тое, што пакінуўшы падыходу дакумента? 

РВК Хулихэном: Я б не кажуць пакінуўшы яго ззаду. 

АЎДЫТОРЫЯ: Яны былі аддзеленыя ад the-- 

РВК Хулихэном: З дакумента падыход, тып дакумента ў DynamoDB проста думаю, як іншы атрыбут. Гэта атрыбут, які змяшчае іерархічную структуру дадзеных. А потым у запытах, Вы можаце выкарыстоўваць ўласцівасці з гэтых аб'ектаў з выкарыстаннем Object Notation. Так што я магу фільтраваць па укладзеным ўласцівасць дакумента JSON. АЎДЫТОРЫЯ: Так любы час я зрабіць дакумент падыход, Я магу сартаваць прыбыць у tabular-- АЎДЫТОРЫЯ: Вы маеце рацыю. Аўдыторыя: --indexes і рэчы, якія вы толькі што казалі аб. РВК Хулихэном: Так, індэксы і ўсё, што, калі вы хочаце, каб індэкс ў ўласцівасці JSON, так, што мы павінны зрабіць гэта, калі Вы ўстаўляеце аб'ект JSON ці дакумент у Дынама, вы павінны выкарыстоўваць патокі. Патокі будуць чытаць ўвод. Вы б атрымаць, што JSON аб'ект, і вы б сказаць, добра, што ўласцівасць Я хачу, каб індэкс? 

Вы можаце стварыць вытворную табліцу с. Зараз гэта, як ён працуе цяпер. Мы не дазваляем індэксаваць непасрэдна тыя ўласцівасці. 

АЎДЫТОРЫЯ: Tabularizing дакументы. 

РВК Хулихэном: Роўна, уплощение гэта, tabularizing яго, дакладна. Вось тое, што вы з ім рабіць. 

АЎДЫТОРЫЯ: Дзякуй. 

РВК Хулихэном: Так, абсалютна, дзякуй. АЎДЫТОРЫЯ: Так што гэта свайго роду Монго адказвае Redis classifers. 

РВК Хулихэном: Так, гэта шмат, як, што. Гэта добрае апісанне для гэтага. Прахладны.