[За възпроизвеждане на музика] Рик Houlihan: Добре. Здравейте на всички. Моето име е Rick Houlihan. Аз съм старши главницата решения архитект на AWS. Аз се съсредоточи върху NoSQL и DynamoDB технологии. Днес съм тук, за да говоря с ти малко за тях. 

Моето образование е предимно в слой данни. Прекарах половината ми развитие кариера написването на база данни, достъп до данни, разтвори за различни приложения. Аз съм бил в Cloud виртуализация за около 20 години. Така че, преди Облака беше Облака, сме свикнали да го наричаме полезност компютинг. И идеята е, това е като PG & E, която плащате за това, което използвате. Днес ние го наричаме облака. 

Но през годините, съм работил за няколко фирми вероятно сте никога не е чувал. Но аз съм съставила списък на техническа постижения, предполагам, че ще каже. Имам осем патенти в облачни системи виртуализация, микропроцесор дизайн, сложна обработка събитие, и други области, както добре. 

Така че тези дни, аз се съсредоточи най-вече върху NoSQL технологии и следващото поколение база данни. И това е, общо взето това, което аз ще съм да бъда тук говоря с вас днес за. И така, какво можете да очаквате от тази сесия, ние ще мине през един кратък историята на обработка на данните. Винаги е полезно да разберем от къде сме дошли и защо сме там, където сме. И ние ще поговорим малко малко за NoSQL технологии от основен гледна точка. 

Ние ще се получи в някои от вътрешността DynamoDB. DynamoDB не е аромат на AWS. Той е напълно управлявани и Решение, NoSQL. И ние ще поговорим малко за маса Структурата, APIs, типове данни, показатели и някои от вътрешността на тази DynamoDB технология. Ще получите в някои от дизайна модели и добри практики. Ще говорим за това как се използвате тази технология за някои от днешните приложения. И тогава ние ще говорим малко по- за развитието или появата на една нова парадигма в програмирането наречени приложения възникнали от събития и как DynamoDB играе в това, както добре. И ние ще ви оставя малко позоваване архитектура дискусия така че можем да поговорим за някои от начините, по които могат да използват DynamoDB. 

Така че първата off-- това е въпрос Чувам много е, какво е база данни. Много хора си мислят, знам какво е база данни. Ако Google, ще видите това. Това е структуриран набор от данни, държани в компютър, особено тази, която е достъпен по различни начини. Предполагам, че това е добра определение на модерна база данни. Но аз не го харесват, защото той предполага няколко неща. Това предполага структура. И това означава, че тя е на компютър. И бази данни не Винаги съществува в компютрите. Базите действително са съществували в много отношения. 

Така че по-добро определение на база данни, е нещо като това. Базата данни е организирана механизъм за съхранение, управление, и извличане на информация. Това е от About.com. Така че това ми харесва, защото той наистина говори за база данни в хранилище, хранилище на информация, не е задължително нещо, което седи на компютър. И в цялата история, ние не винаги са имали компютри. 

Сега, ако мога да попитам средното разработчик днес това, което е база данни, това е отговорът, който получи. Somewhere I могат да се придържаме неща. Нали така? И това е вярно. Но това е жалко. Тъй като базата данни е наистина основите на съвременната ап. Това е в основата на всяко приложение. И как да изградите, че база данни, как ще се структурира че данните няма да диктува как това заявление изпълнява колкото мащаб. 

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

И иновациите се появява, когато виждаме налягане данни, които е количеството данни, което е Сега в които влизат в системата. И това не могат да се обработват ефективно по време или в разходи. И това е, когато започнем да погледнете налягане данни. 

Така че, когато се вгледаме в първата база данни, тази е този, който е между ушите ни. Всички ние сме родени с него. Това е хубаво база данни. Тя е с висока надеждност. Той винаги е на. Вие винаги може да го получи. 

Но това е един потребител. Не мога да споделя мислите си с вас. Вие не можете да получите моите мисли когато ги искат. И тяхната abilitiy не е толкова добра. Ние забравяме неща. От време на време, един от нас листа и ще се отправи към друга съществуване и ние губим всичко който беше в тази база данни. Така че това не е всичко, което заслужава. 

И това работи добре с течение на времето когато бяхме през деня когато всички ние наистина необходимо да се знае е, къде отиваме, за да отидат на утрешния ден или когато се събираме най-добрата храна. Но тъй като сме започнали да растат като цивилизация и правителството започна да влезе в сила, и предприятията са започнали да се развиват, ние започнахме да осъзнаваме се нуждаят от малко повече от това, което бихме могли да поставите в главата ни. Всичко е наред? 

Имахме нужда от системи за запис. Имахме нужда от места, за да бъде в състояние съхранение на данни. Така че ние започнахме писане на документи, създаване на библиотеки и архиви. Ние започнахме разработването на система за счетоводна книга. И тази система на книга броене завтече свят в продължение на много векове, и може би дори хилядолетия като ние вид нарасна до такава степен, когато това натоварване на данни надмина способността на тези системи да бъде в състояние да го съдържа. 

И това всъщност се е случило през 1880-те. Нали така? В 1880 US преброяване. Това е наистина, когато обръщането посоча модерна обработка на данни. Това е точката, в които размерът на данни които се събират от Правителството на САЩ, стигнал до етапа, къде го взе осем години, за да обработи. 

Сега, осем years-- като знаете ли, преброяването писти всеки 10 years-- така че е доста очевидно, че от време ние имам преброяването 1890 г., количеството данни, че щеше да бъде обработена от правителството беше ще надхвърли 10-те години, че тя ще предприеме, за да постави началото на новия преброяването. Това беше проблем. 

Така че един човек на име Херман Холерит дойде и той е изобретил устройство рекорд удар карти, четец перфокарта, перфокарта табулатор и сортиране на механизмите за тази технология. И че компания, която той формира в време, заедно с няколко на другите, всъщност се превръща в един от стълбовете на една малка фирма какъвто го познаваме днес, наречена IBM. 

Така че IBM първоначално е бил в бизнеса база данни. И това е наистина това, което са направили. Те направиха за обработка на данни. 

Що така разпространението на удар карти, удачно механизми да бъде в състояние да се наберат, че технология, за да сондира сортирани резултатни набори. Можете да видите на тази снимка там имаме little-- това е малко small-- но можете да видите много гениални механичен механизъм където имаме тесте от перфокарта. И предприемане на нечия малко отвертка и залепване през анализатора слотове и го повдигнете нагоре за да получите този мач, че сортирани определени резултати. 

Това е съвкупност. Ние правим това през цялото време днес в компютъра, , където можете да го направите в базата данни. Свикнали сме да го направите ръчно, нали? Хората поставят тези неща заедно. И това е разпространението от тези перфокарти в това, което нарича барабани данни и макари данни, хартиена лента. 

Индустрията за обработка на данни се поука от пианата играч. Player пиана назад към на края на века използва, за да използвате хартиени ролки с прорези за да го каже кои клавиши, за да играят. Така че технологията е адаптирана в крайна сметка за съхранение на цифрови данни, защото те биха могли да се сложи това на данни върху тези хартиени ленти макари. 

Сега, като резултат, данните бе actually-- как възможност за достъп до тези данни е пряко зависи от това как го съхранява. Така че ако сложа данните на лента, Имах достъп до данните линейно. Аз трябваше да се търкаля като цяло лента, за да получите достъп до всички данни. Ако сложите данните в пунш карти, бих могъл да го достъп в малко по-случайно мода, може би не толкова бързо. 

Но е имало ограничения в начина, по който достъп до данните, въз основа на това как се съхранява. И така, това е проблем навлиза в 50-те. Отново можем да започнем да се види, че както ние разработване на нови технологии за обработка на данните, нали, тя разкрива вратата за нови решения, за нови програми, ново заявленията за тези данни. И наистина, управление може да е причината Затова ние разработихме някои от тези системи. Но бизнесът бързо се превръща на водача зад еволюцията на модерната база данни и модерната файловата система. 

Така че следващото нещо, което изскочи беше през 50-те е файловата система и развитие на случаен принцип за съхранение на достъпа. Това беше красиво. Сега, всички внезапно, можем да сложим нашето файлове навсякъде на тези твърди дискове и ние можем да получите достъп до тази информация на случаен принцип. Ние може да анализира, че информация от файлове. И ние решени всички в света проблеми с обработката на данни. 

И това продължило около 20 или 30 години до еволюцията на релационна база данни, която е, когато светът решихме сега Трябва да има хранилище, което побеждава на разрастването на данни в рамките на файла системи, които сме построили. Нали така? Твърде много данни, разпространени в твърде много места, за де-дублиране на данни, и разходите за съхранение е огромен. 

През 70-те години, най-скъпият ресурс че компютърът е за съхранение. Процесорът е разгледана като фиксирана стойност. Когато купувам на наказателното поле, процесора върши някаква работа. Това ще се върти независимо дали тя всъщност работи или не. Това е наистина един потънал цена. 

Но това, което ми струва като бизнес е за съхранение. Ако аз трябва да си купите повече диска следващия месец, че е истинска цена, която плащам. И това съхранение е скъпо. 

Сега ние бързо напред 40 година и ние имаме различен проблем. В изчислителната сега и е Най-скъпият ресурс. Съхранението е евтино. Искам да кажа, ние можем да отидем някъде на облак и ние може да намерите евтини съхранение. Но това, което не мога да намеря е евтин изчисли. 

Така че еволюцията на днешната технология, на база данни, технология, наистина е съсредоточена около разпределени бази данни които не страдат от същия тип скала ограничения на релационни бази данни. Ще поговорим малко за какво всъщност означава. 

Но една от причините и на водача зад this-- ние Говорихме за налягането на данни. Налягане Data е нещо който движи иновациите. И ако се вгледате в над през последните пет години, това е диаграма на това, данните натоварване в целия цяло предприятие Как изглежда в последните пет години. 

А общото правило на палеца тези days-- ако отидат Google-- е 90% от данните, които ние съхраняваме днес, и това беше генерирани в рамките на последните две години. ДОБРЕ. Сега, това не е тенденция, която е нова. Това е тенденция, която е била излиза в продължение на 100 години. Откакто Херман Холерит разработена на перфокарта, ние сме били изграждането на хранилища на данни и събиране на данни при феноменални темпове. 

Така че през последните 100 години, сме виждали тази тенденция. Това няма да се промени. В бъдеще ние ще видим това, ако не ускорен тенденция. И можете да видите това, което изглежда по този начин. 

Ако бизнес през 2010 г. имаше един терабайт данни под управление, Днес това означава, че те са управлението 6,5 петабайта данни. Това е 6500 пъти повече информация. И аз знам това. Аз работя с тези фирми всеки ден. Преди пет години, I ще говоря с фирми кой ще ми говори за това, което е трън тя е да управлява терабайта данни. И те ще се говори с мен за това как виждаме че това най-вероятно ще да бъде петабайта или два в рамките на няколко години. 

Същите тези фирми Днес имам среща с, и те да ми говори за проблем са там като управляващ десетки, 20 петабайта данни. Така че експлозията на данни в индустрията е шофиране огромното нужда от по-добри решения. И релационна база данни е просто не живеят до търсенето. 

И така, има линейна корелация между налягането на данни и техническите иновации. Историята ни показва, това, че с течение на времето, когато обемът на данните който трябва да бъде обработен надхвърля капацитета на системата да я обработва в разумен срок или на разумна цена, След това новите технологии са измислени, за да реши тези проблеми. Тези нови технологии, от своя страна, отвори вратата към друг набор от проблеми, които набира дори повече данни. 

Сега, ние няма да спрем това. Нали така? Ние няма да спрем това. Защо? Защото не можеш да знаеш всичко има да се знае във Вселената. И докато сме били живи, в цялата история на човека, ние винаги сме принудени да знам повече. 

Така изглежда, че всеки инч се движим по пътя на научно откритие, ние се умножи размерът на данни че ние трябва да се обработи експоненциално както разкрие повече и повече и по- за вътрешната изработки на живот, за това как работи Вселената, за задвижване на научно откритие, и че изобретението което правим днес. Обемът на данни само непрекъснато се увеличава. Така че е в състояние да се справят с този проблем е огромен. 

Така че едно от нещата, ние с нетърпение и защо NoSQL? Как NoSQL реши този проблем? Е, релационни бази данни, Език за структурирани заявки, SQL-- това е наистина конструкт на релационна database-- тези неща са оптимизирана за съхранение. 

Обратно през 70-те, отново, диск е скъпо. Упражняването на провизиране на съхранение в предприятието е безкраен. Аз знам. Аз го живели. Написах драйвери за съхранение за enterprised superserver фирма обратно през 90-те. И най-долния ред е претакане друг масив за съхранение е просто нещо, което случило всеки ден в предприятието. И никога не го спря. Висше съхранение плътност, търсене за съхранение висока плътност, и за по-ефективно съхранение devices-- че никога не е спрял. 

И NoSQL е чудесна технология защото нормализира данните. Тя де-дубликати на данните. Това поставя данните в структура, е агностик към всеки модел достъп. Множество приложения могат да изпаднат, че SQL база данни, тичам специални заявки, и да получите данните във формата, че те Трябва да обработва за своите работни натоварвания. Това звучи фантастично. Но най-долния ред е с всеки система, ако това е агностик на всичко, е оптимизиран за нищо. ДОБРЕ? 

И това е, което ние получаваме с релационната база данни. Той е оптимизиран за съхранение. Това е нормализирана. Това е релационна. Той поддържа специални заявки. И него и го везни вертикално. 

Ако трябва да съм по-голяма база данни SQL или по-мощна SQL база данни, Аз отида да купя по-голямо парче желязо. ДОБРЕ? Аз съм работил с много клиенти , които са минали през големи ъпгрейди само в тяхната SQL инфраструктура да разберете шест месеца по-късно, те удря в стената отново. И отговорът от Oracle или MSSQL или някой друг е по-голяма кутия получите. Е, рано или късно, не можете да си купите голяма кутия, и това е реален проблем. Трябва действително да се променят нещата. Е, къде става това? Тя работи добре за офлайн Анализ, OLAP тип натоварвания. И това е наистина, когато SQL принадлежи. Сега, той се използва и днес в много онлайн транзакционен обработка тип приложения. И това работи добре при някакво ниво на усвояване, но просто не се мащабира начинът, по който NoSQL прави. И ние ще поговорим малко битов за това, защо е това. 

Сега, NoSQL, от друга страна, е по-оптимизирана за изчислителна. ДОБРЕ? Не е агностична схемата за достъп. Дали това, което наричаме дьо нормализирано структура или йерархична структура. Данните в релационна база данни е съчетал от множество таблици за производство на мнение, че трябва. Данните в база данни NoSQL се съхранява в документ, съдържа йерархичната структура. Всички данни, които нормално ще бъде съчетал да произвежда това мнение се съхранява в един документ. И ние ще поговорим малко за как това работи в няколко класации. 

Но идеята тук е, че вие ​​съхранявате Вашите данни като тези инстанция гледка. ДОБРЕ? Можете мащаб хоризонтално. Нали така? Ако аз трябва да се увеличи Размер на моя NoSQL клъстер, Аз не се нуждаят, за да получите по-голяма кутия. Получавам друга кутия. И аз клъстер тези, заедно, и мога да Shard, че данните. Ние ще поговорим малко за какво sharding е, да бъде в състояние да мащабирате, че базата данни в множество физически устройства и премахване на бариерата, че изисква от мен да мащабирате вертикално. 

Така че това е наистина построен за онлайн обработка на транзакции и мащаб. Има голяма разлика тук между отчитането, нали? Докладване, аз не знам на въпроси аз ще попитам. Нали така? Reporting-- ако някой от моя отдел маркетинг иска да just-- колко от моите клиенти имат тази особена характеристика, които Купих по този day-- аз не знам какво заявка, че ще попитам. Така че трябва да съм агностик. 

Сега, в онлайн транзакционен заявление, Знам какви въпроси Питам. Аз построих заявлението за много специфичен работен процес. ДОБРЕ? Така че, ако се оптимизира данните съхранява в подкрепа на това работния процес, това ще бъде по-бързо. И затова може NoSQL наистина ускори доставката на тези видове услуги. Всичко е наред. 

Така че ние ще се получи в малко теория тук. И някои от вас, вашите очи може да се връщам малко. Но аз ще се опитам да я пази като високо ниво, колкото мога. Така че, ако сте в проекта управление, има конструкт, наречен триъгълник на ограничения. ДОБРЕ. Триъгълникът на ограничения диктат не може да има всичко, което през цялото време. Не може да имате свой пай и го ядат също. Така че в управлението на проекти, които триъгълник ограничения е че може да има евтино, можете да имате то бързо, или можете да го заслужава. Вземете две. Тъй като не може да има и трите. Нали така? ДОБРЕ. 

Така ще чуете за това много. Това е една тройна ограничение, триъгълник на тройната ограничение, или железния триъгълник е oftentimes-- когато говорите за проекта мениджъри, те ще говорим за това. Сега, бази данни имат собствената си железен триъгълник. И железния триъгълник на данни е това, което ние наричаме теоремата CAP. ДОБРЕ? 

ОСП теорема диктат как работят бази данни по един много специфичен състояние. И ние ще говорим за какво е това условие. Но трите точки на триъгълника, така да се каже, са C, последователност. ДОБРЕ? Така че в ОСП, последователност означава, че всички клиентите, които имат достъп до базата данни Винаги ще има много последователен изглед на данни. Никой не ще видите две различни неща. ДОБРЕ? Ако видя базата данни, Аз виждам същото мнение като мой партньор, който вижда същата база данни. Това е последователност. 

Наличност означава, че ако база данни онлайн, ако може да бъде постигнато, че всички клиенти винаги ще да могат да четат и пишат. ДОБРЕ? Така всеки клиент, който може да прочетете в базата данни винаги ще бъде в състояние за четене данни за данни и пишат. И ако това е така, това е една съществуваща система. 

И третата точка е това, което ние наричаме дял толерантност. ДОБРЕ? Толерантност Partition средства че системата работи добре въпреки физическата мрежа разделителните стени между възлите. ДОБРЕ? Така възли в клъстера не може да разговарят помежду си, какво се случва? Всичко е наред. 

Така релационни бази данни choose-- можете да вземете две от тях. ДОБРЕ. Така релационни бази данни избират да бъде последователно и достъпно. Ако дялът случва между на DataNodes в хранилището на данни, базата данни катастрофи. Нали така? Той просто отива надолу. ДОБРЕ. 

И това е защо те имат да растат с по-големи кутии. Нали така? Защото има no-- обикновено, клъстер база данни, там не е много голяма част от тях които работят по този начин. Но повечето бази данни мащабират вертикално в рамките на едно поле. Тъй като те трябва да бъдат последователна и достъпно. Ако дял са да се инжектира, След това ще трябва да направи избор. Трябва да се направи избор между последователността и достъпно. 

И това е, което правят NoSQL бази данни. Всичко е наред. Така че една база данни NoSQL него, се предлага в две версии. Ние have-- добре, идва в много аромати, но той идва с два основния characteristics-- какво бихме нарекли CP база данни, или последователна и делба толерантност система. Тези момчета правят избора, че когато възли губят контакт един с друг, ние няма да позволи хората да пишат повече. ДОБРЕ? 

До този дял е отстранена, достъп за писане е блокиран. Това означава, че те не са на разположение. Те са последователни. Когато виждаме, че дял се инжектира, Сега ние сме последователни, защото ние не отиваме за да се позволи смяната на данни на две страни на преградата независимо един от друг. Ние ще трябва да установите връзка преди някоя актуализация данните се допуска. ДОБРЕ? 

Следващата вкус ще бъде система AP, или на разположение и се разпределя система за толерантност. Тези момчета не им пука. Нали така? Всеки възел, който получава напиша, ще го взема. Така че аз съм репликира ми данни в множество възли. Тези възли получават клиент, клиент идва в, казва, аз отивам да пиша някои данни. Node казва, няма проблем. Възелът до него получава преоценка на същия запис, той ще каже, няма проблем. Някъде назад към края на гърба, че данните ще се възпроизведе. И тогава някой ще ходи да осъзнае, ъ-ъ-о, те ще осъзнаят система, ъ-ъ-о, е имало актуализация на двете страни. И какво ще правим? И това, което правят след това е те правят нещо, което им позволява да решим, че държавната данни. И ние ще говорим за че в следващата диаграмата. 

Thing да посоча тук. И аз няма да стане твърде много в това, тъй като тази попадне в дълбока теория данни. Но има сделка рамка, която писти в релационна система, която ми позволява да безопасно да актуализации до множество лица в базата данни. И ще се появят тези актуализации наведнъж или не на всички. И това се нарича сделки киселина. ДОБРЕ? 

ACID ни дава валентност, последователност, изолация и дълготрайност. ДОБРЕ? Това означава, че атомните, сделки, всички моите актуализации или се случват или не. Съвместимост означава, че Базата данни ще винаги да бъдат приведени в последователен състояние след актуализация. Аз никога няма да напусне базата данни в лошо състояние след прилагане на актуализация. ДОБРЕ? 

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

Изолиране означава, че сделките винаги ще се случи един след друг. Крайният резултат от данните на ще бъде една и съща държава както ако тези транзакции които са издадени едновременно са били екзекутирани серийно. Така че това е едновременност контрол в базата данни. Така че основно, аз не мога да увеличаваме същата стойност два пъти с две операции. 

Но ако кажа, добавете 1 до тази стойност, и две сделки идват в и се опитайте да го направя, един е Ще отида там първа а другият е Ще отида там след това. Така че в края на краищата, аз добавих две. Виждате ли какво имам предвид? ДОБРЕ. 

Дълготрайност е доста ясен. Когато сделката се признава, че е ще бъде там, дори ако системата се срива. Когато тази система се възстановява, че сделка, която е извършено всъщност ще бъде там. Така че това е гаранциите на сделките киселина. Това са доста приятен гаранции да има на база данни, но те идват при тази цена. Нали така? 

Тъй проблема с тази рамка е ако има дял в данните набор, аз трябва да се вземе решение. Отивам да се наложи да се даде възможност актуализации на една или друга страна. И ако това се случи, тогава аз вече не става съм да бъде в състояние да поддържа тези характеристики. Те няма да бъдат последователни. Те не се изолира. Това е мястото, където тя се разпада за релационни бази данни. Това е причина релационни бази данни мащабират вертикално. 

От друга страна, трябва което се нарича BASE технология. А това са вашите NoSQL Базите. Всичко е наред. Така че ние имаме нашата CP, AP бази данни. И ето какво ти се обадя по същество достъпно, меко състояние, в крайна сметка последователна. ДОБРЕ? 

По принцип на разположение, тъй те са делба толерантни. Те винаги ще бъдат там, дори ако има дял мрежа между възлите. Ако мога да говоря с един възел, аз съм ще бъде в състояние да чете данни. ДОБРЕ? Аз не винаги може да бъде в състояние да напише данни, ако аз съм последователен платформа. Но аз ще бъда в състояние да чете данни. 

Меката състояние показва, че когато прочетох, че данните, може да не бъде същото като други възли. Ако полето е издадено на възел някъде другаде в клъстера и то не е повторен от другата страна на клъстер, все още, когато прочетох, че данните, това състояние, може да не бъдат последователни. Въпреки това, ще бъде в крайна сметка последователна, което означава, че когато един запис е направена към системата, ще се възпроизведе в лимфните. И в крайна сметка, това състояние ще бъдат приведени в ред, и това ще бъде последователна държавна. 

Сега, теоремата CAP наистина играе само в едно състояние. Това условие е, когато това се случи. Защото всеки път, когато това е работеща в нормален режим, няма дял, всичко е последователно и достъпно. Вие се притеснявате само около CAP когато имаме този дял. Така че тези, които са редки. Но как системата реагира, когато тези, възникнат диктува какъв тип система имаме работа. 

Така че нека да погледнем на това, което който изглежда като за AP системи. ДОБРЕ? AP системи се предлагат в два вкуса. Те се предлагат в аромата, че е майстор майстор, 100%, винаги на разположение. И те влизат в друг аромат, в която се казва, Знаете ли какво, аз отивам да се притеснявате за това нещо разделяне когато действително дял настъпва. В противен случай съществува ще бъде първична възли, които ще отнеме правата. ДОБРЕ? 

Така че, ако ние нещо като Касандра. Cassandra ще бъде майстор майстор, нека ми пише на всеки възел. Така че какво ще се случи? Така че аз имам един обект в база данни, която съществува на две възли. Нека да наречем този обект S. Така че ние имаме държава за S. Ние имаме някои операции на S, които са в ход. Cassandra ми позволява да пишете на множество възли. Така че нека да кажа, че се получи пиша за лидер на два възела. Е, това, което в крайна сметка се случва е, ние наричаме, че разделянето събитие. Там не може да бъде дял физическа мрежа. Но поради дизайна на системата, това е действително разделяне, веднага като получа запис на два възела. Това не ме принуждава да напиши всичко през един възел. Пиша на две възли. ДОБРЕ? 

Така че сега имам две държави. ДОБРЕ? Какво ще се случи е рано или късно, там ще бъде репликация събитие. Там ще бъде това, което ние нарича дял за възстановяване, които е мястото, където тези две държави идват отново заедно и там ще бъде един алгоритъм която работи вътре в базата данни, реши какво да прави. ДОБРЕ? По подразбиране, последна промяна печели в повечето системи AP. Така че обикновено има алгоритъм подразбиране, това, което те наричат ​​обаждане функция, нещо, което ще се нарича, когато това условие се открива за да изпълни някои логика за решаване на този конфликт. ДОБРЕ? Обратно повикване и по подразбиране по подразбиране Резолвер в повечето AP бази данни е, познайте какво, клеймото печели. Това беше последната актуализация. Отивам да се сложи това актуализация там. Аз може да зареже този запис, че аз дъмпингови разстояние в дневник за възстановяване така че потребителят да може да се върне по-късно и да кажа, хей, имаше сблъсък. Какво се случи? И всъщност можете да зареже запис на всички сблъсъци и ролбек и да видим какво ще стане. 

Сега, като потребител, можете също включва логика в това обаждане. Така че можете да промените това обаждане операция. Може да се каже, хей, аз искам за решаване на тези данни. И аз искам да се опитам слеят тези две досиета. Но това е до вас. Базата данни не знае как да направя това по подразбиране. Повечето от времето, единственото нещо, което на базата данни Знае как да направите е да се каже, това е последният запис. Това е този, който ще спечели, и това е стойността Отивам да се сложи. След като това възстановяване деление и репликация се случи, ние имаме нашата държава, която сега е S-председател, който е на сливане състоянието на всички тези обекти. Така че AP системи имат това. Системи ХФ не се нуждаят от да се тревожи за това. Защото веднага след като дял идва в игра, те просто спрете да приемате пише. ДОБРЕ? Така че това е много лесно да се справят с последователността когато не сте съгласни с всички актуализации. Това е със системи CP направя. Всичко е наред. 

Така че нека да поговорим малко малко за модели за достъп. Когато говорим за NoSQL, това е всичко за модела за достъп. Сега, SQL е специална, запитвания. Това е релационна магазин. Ние не трябва да се притеснявате за модел за достъп. Аз пиша много сложен въпрос. От само себе си и получава данните. Това е, което това изглежда харесват, нормализиране. 

Така в тази структура, ние не търсим най-каталог продукти. Имам различни видове продукти. Имам книги. Имам албуми. Имам клипове. Връзката между продуктите и всяка една от тези книги, албуми, и клипове маси е 1: 1. Всичко е наред? Имам ID продукт, и че отговаря за самоличност до една книга, албум или видеоклип. ДОБРЕ? Това е 1: 1 отношения през тези таблици. 

Сега, books-- всички те имам е корен свойства. Няма проблем. Това е прекрасно. Едно към едно отношения, да получа всички данните, което трябва да се опише тази книга. Albums-- албуми имат песни. Това е, което ние наричаме един за мнозина. Всеки албум може да има много песни. Така че за всеки трак албума, мога да имам нов рекорд в тази детска маса. Така че аз се създаде един запис в моята маса албуми. I създавате множество записи в таблицата за писти. One-към-много. 

Тази връзка е това, което ние наричаме много-към-много. ДОБРЕ? Вие виждате, че участниците могат да бъдат в много филми, много видеоклипове. Така че това, което правим, е ние поставяме този картографиране маса между тези, които просто карта на ИД за актьор на идентификатора на видеоклипа. Сега мога да се създаде заявка за присъединява видеоклипове чрез актьор видео към актьори, и това ми дава хубав списък всички филми и всички участници, които бяха в този филм. 

ДОБРЕ. Така че тук и да отидем. Едно към едно е най-високо ниво правоотношение; един-към-много, албумите на песни; много-към-много. Това са трите най-високо ниво взаимоотношенията в която и бази данни. Ако знаете как тези, взаимоотношения работят заедно, тогава вие знаете много за база данни вече. Така NoSQL работи малко по-различно. Нека да помислим за за втори какво прилича да отида да всичките си продукти. 

В релационна магазин, I искате да получите всички мои продукти в списък на всички мои продукти. Това е много запитвания. Имам въпрос за всичките ми книги. Имам въпрос от албумите ми. И аз имам въпрос за всички мои клипове. И аз трябва да го сложи всички заедно в един списък и го обслужва обратно в приложение, които не го е поискал. 

За да получите книгите ми, аз се присъединявам Продукти и книги. За да получите албумите ми, аз трябва да се присъединят Продукти, Албуми и следи. И да получите моите клипове, имам да се присъединят към Продукти Videos, присъединят през Актьор Videos, и се въвеждат в актьорите. Така че това е три запитвания. Много сложни заявки за съберат един резултат набор. 

Това е по-малко от оптималното. Ето защо, когато говорим около една структура, която е на данни построен да агностично на достъпа pattern-- добре, че е страхотно. И вие можете да видите това наистина е хубаво колко сме организирани данните. И знаеш ли какво? Аз имам само един запис за един актьор. 

Това е яко. Аз бях deduplicated всичките ми актьори, и аз имаха моите асоциации в това картографиране на маса. Въпреки това, получаване на данни вън става скъпо. Аз съм изпращане на процесора цял система се присъедини към тези структури от данни заедно да бъде в състояние да тегли, че данните за минали периоди. 

И така, как мога да получа около това? В NoSQL това е за агрегация не, нормализиране. Така че ние искаме да кажем, ние искаме да поддържа схемата за достъп. Ако схемата за достъп към приложенията, Трябва да получите всички мои продукти. Нека да поставим всички продукти в една таблица. Ако сложите всички продукти в една таблица, Мога само да изберете всички продукти от тази маса и аз го получите всичко. Ами как мога да направя това? Ами в NoSQL че няма структура на масата. Ще поговорим малко за как това работи в Динамо DB. Но не е нужно същото атрибути и същите свойства във всеки един ред, във всеки един т, както правите в SQL таблица. И какво ми позволява да направите, е много неща и ми даде много на гъвкавост. В този конкретен случай, аз имам продуктови документи. И в този конкретен Например, всичко е документ, в таблицата с продукти. А продукта за книга мощ Трябва ID вид, който определя една книга. И заявлението ще се включи, че ID. 

В подреждането на кандидатстване, аз отивам да се каже, ох, какво запис тип е това? О, това е една книга рекорд. Записи на книги имат тези свойства. Позволете ми да се създаде една книга обект. Така че аз отивам да запълни Книга за обект с тази позиция. Следваща точка идва и казва, какъв е този елемент? Ами този елемент е албум. О, аз имам съвсем различно обработка на рутинна за това, защото това е албум. Виждате ли какво имам предвид? 

Така че прилагането tier-- I Просто изберете всички тези записи. Всички те започнат да се инча Те могат да бъдат всички различни видове. И това е логиката на приложението че минава през тези видове и решава как да ги обработи. 

Отново, така че ние сме се оптимизира схема за модел за достъп. Ние го правим от срутване тези таблици. Ние основно като тези нормализирани структури, и ние строим йерархични структури. Във всеки един от тези записи Отивам да видя масив свойства. 

Вътре в този документ за Албуми, Виждам масиви на песни. Тези песни сега become-- това е основно това дете таблица, която съществува точно тук, в тази структура. Така че можете да направите това в DynamoDB. Можете да направите това в MongoDB. Можете да направите това по никакъв база данни NoSQL. Създаване на тези видове йерархични структури от данни които ви позволяват да изтеглите данни много бързо, защото сега аз не е нужно да отговарят. Когато вмъкнете ред в следите маса, или един ред в таблицата с Албуми, Аз трябва да съответства на тази схема. Аз трябва да имат атрибут или имот, който се определя на същата таблица. Всеки един от тях, когато поставите този ред. Това не е случаят в NoSQL. 

Аз може да има напълно различна Имоти в всеки документ че аз вмъкнете в колекцията. Така че много мощен механизъм. И това е наистина как си оптимизиране на системата. Защото сега, че заявката, вместо присъединят всички тези таблици и изпълнение на половин дузина запитвания да изтеглят данните ми трябва, Аз съм при стартиране на една заявка. И аз съм итерации цяла резултатите установени. тя ви дава представа за силата на NoSQL. Отивам да вид отиде настрани тук и да поговорим малко за това. Това е повече вид на пускане на пазара или technology-- пускането на пазара на технологии тип дискусия. Но е важно да се разбере, защото ако погледнем отгоре тук, в тази таблица, това, което търсим в е това, което ние наричаме технология крива истерия. И какво означава това е, нови неща влезе в игра. Хората си мислят, че това е страхотно. Аз бях решила всичките си проблеми. 

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

И смешно нещо за него е, то вид линии до това, което ние наричаме Technology Приемане крива. Така че това, което се случва е, ние имаме някаква технология спусъка. В случай на бази данни, това е натиск данни. Ние говорихме за високите водни точки на налягането на данни през целия път. Когато това налягане данни удря определен точка, това е технология на спусъка. 

Става все по твърде скъпо. Това отнема прекалено дълго време за обработка на данни. Ние трябва нещо по-добро. Можете да получите новаторите там вървят около, Опитвам се да разбера какво е решението. Какво е най-новата идея? 

Каква е следващата най- начин да се направи това нещо? И те измисли нещо. И хората с реалната болка, момчетата от ръба на кървене, те ще скочи над всичко, защото те се нуждаят от отговор. Сега това, което неминуемо happens-- и това се случва сега в NoSQL. Виждам го през цялото време. 

Какво се случва, е неизбежно хората започват да използват новия инструмент По същия начин те са използвали стария инструмент. И те разбери го не работи толкова добре. Аз не мога да си спомня кой съм говорим за по-рано днес. Но това е като, когато пневматичен е измислена, хората не го преобърне главата си, за да смачка бетона. 

Но това е, което е случва с NoSQL днес. Ако ходите в повечето магазини, те се опитват да се NoSQL магазини. Това, което те правят, е да започнете те използват NoSQL, и те са го зарежда пълен с релационна схема. Защото това е начина, те дизайн на бази данни. И те се чудите, защо е тя не се извършва много добре? Момче, това нещо смърди. Аз трябваше да се поддържа през целия ми присъединява in-- това е като, не, не. Поддържа се присъедини? Защо се присъедини данни? Не се присъединят данни в NoSQL. Можете да го сумира. 

Така че, ако искате да избегнете това, да научат как работи функцията преди да се започнете да го използвате. Не се опитвайте да използвате новите инструменти на същия начин, който сте използвали старите инструменти. Вие ще имате лош опит. И всеки път, това е за какво става въпрос. Когато започнем да идва тук, това е, защото хората измислили как да използват инструментите. 

Те направиха същото, когато релационни бази данни са били измислени, и те бяха замяна файлови системи. Те се опитаха да изградят файлови системи с релационни бази данни защото това е, което хората разбират. То не е работа. Така че разбирането на най-добрите практики на технологията с който се работи е огромна. Много важно. 

Така че ние ще се получи в DynamoDB. DynamoDB е AWS е напълно успя NoSQL платформа. Какво означава напълно успя да кажа? Това означава, че не е нужно да наистина се притеснявате за нищо. 

Ти дойде в, да ви кажа нас, имам нужда от една маса. Тя се нуждае от толкова много капацитет. Можете натисна бутона, а ние разпоредба всички инфраструктура зад сцената. Сега е огромна. 

Защото, когато говорим за мащабиране на база данни, NoSQL клъстери данни в мащаба, работа петабайта, използвате милиони транзакции в секунда, тези неща не са малки клъстери. Ние говорим хиляди копия. Управление на хиляди случаи, дори виртуални копия, е истинска болка в задника. Искам да кажа, мисля, за всеки път, операционна система кръпка излиза или нова версия на базата данни. Какво означава това да ви оперативно? Това означава, че имаш 1200 сървъри, които трябва да бъдат актуализирани. Сега дори и с автоматизация, който може да отнеме дълго време. Това може да доведе до много оперативни главоболие, защото може да се наложи услуги надолу. 

Както актуализира тези бази данни, I може да направи сини зелени внедрявания където I разположи и надграждане половината ми възли, а след това ъпгрейд другата половина. Вземете тези надолу. Така че управлението на инфраструктурата мащаб е изключително болезнено. И AWS вземе, че болката от нея. И NoSQL бази данни може да да бъде изключително болезнено заради начина, по който мащаб. 

Scale хоризонтално. Ако искате да получите по-голям NoSQL база данни, вие купувате повече възли. Всеки възел купувате е друга оперативна главоболие. Така че нека някой друг направи това за вас. AWS може да направи това. 

Ние подкрепяме стойности ключови документи. Сега ние не отиде твърде много От друга в графиката. Има много различни аромати на NoSQL. Те са всички видове за получаване на munged заедно в този момент. Посетете DynamoDB и да кажа, да, и двамата сме документ и стойност ключовата съхранява тази точка. И вие може да се твърди, характеристиките от една върху друга. За мен, много от това е наистина шест от една половин дузина от другата. Всеки един от тези технологии е фина технология и глоба решение. Не бих казал, MongoDB е по-добре или по-лошо от диван, тогава Касандра, След това Динамо, или обратното. Искам да кажа, това са само възможности. 

Той е бърз и това е последователно във всеки мащаб. Така че това е един от най-големите бонусите, които получавате с AWS. С DynamoDB е способността да се получи ниска едноцифрени милисекунда латентност по всяко мащаб. Това беше гол проектиране на системата. И ние имаме клиенти, които правят милиони транзакции в секунда. 

Сега аз ще отида през някои от тези, използвате случаи в рамките на няколко минути тук. Интегрирана control-- достъп ние имаме това, което наричаме Identity Management Access, или IAM. Тя прониква всяка система, всяка услуга, която AWS предлага. DynamoDB не е изключение. Можете да контролирате достъпа до таблиците за DynamoDB. Across всичките си сметки чрез AWS определяща роля за достъп и разрешения в IAM инфраструктура. 

И това е ключова и неделима компонент в това, което наричаме Event Driven програмиране. Сега това е една нова парадигма. 

АУДИТОРИЯ: Как си лихвен процент на истинската позитиви срещу фалшиво отрицателни на вашата система за контрол на достъпа? Рик Houlihan: Истинските позитиви срещу фалшиво отрицателни резултати? АУДИТОРИЯ: Връщайки какво трябва да се върне? За разлика от време на време тя не се връща, когато тя трябва да валидира? 

Рик Houlihan: Не можех да ви кажа, че. Ако има някакви повреди каквато и че, Аз не съм човекът да попитам този конкретен въпрос. Но това е добър въпрос. Щях да съм любопитен да разбера че себе си, всъщност. 

И така, след това отново, нова парадигма е ориентирана към събития програмиране. Това е идеята, че можете да разположи сложни приложения, които може да работи много, много висок мащаб без никаква инфраструктура, каквато. Без никаква фиксирана инфраструктура, каквато. И ние ще поговорим малко за това какво означава, че както ние пуснем на следващите няколко графики. 

Първото нещо, което ние ще направим е ние ще говорим за маси. Типове данни API за Динамо. И първото нещо, което ще забележите, когато се вгледате в това, ако сте запознати с всяка база данни, бази данни имат наистина два вида APIs Бих го наричат. Или два набора от API. Един от тях ще бъде административната API. 

Нещата, които се грижат за функциите на базата данни. Конфигуриране на двигателя на съхранение, създаване и добавяне на таблици. създаване на база данни каталози и инстанции. Те things-- в DynamoDB, вие има много къси, кратки списъци. 

Така че в други бази данни, може да видите десетки на команди, на административна команди, за конфигуриране тези допълнителни опции. В DynamoDB не е нужно тези, защото не конфигурирате системата, което правим. Така че единственото нещо, което трябва да направите, е да да ми каже какво размер на таблицата са ми нужни. Така че можете да получите много ограничен набор от команди. 

Можете да получите Създай Маса, обновяване, маса, Изтриване на маса, и Опишете таблица. Това са единствените неща, което се нуждаете за DynamoDB. Не е нужно за съхранение конфигурация на двигателя. Не е нужно да се притеснявате за репликация. Не е нужно да се притеснявате за sharding. 

Не трябва да се притеснявате за някое от тези неща. Ние го направя всичко за вас. Така че това е огромна сума на надземната това е просто излетя вашата чиния. Тогава ние имаме операторите на боклук. CRUD е нещо, което ние обадите в база данни, която е Създаване, актуализиране, заличаване оператори. Това са си обща операции на базата данни. Неща като пут позиция, получават т, актуализация предмети, изтрийте елементите, заявка партида, сканират. Ако искате да сканирате цялата таблица. Издърпайте всичко от масата. Един от най-хубавите неща DynamoDB е тя позволява паралелно сканиране. Така че всъщност можете да ме уведомите, колко теми, които искате да се движат по които сканиране. И ние може да работи на тези теми. Ние може да се върти, че сканира в множество теми така че можете да сканирате цялата таблица пространство много, много бързо в DynamoDB. 

Другият API имаме, е това, което ние наричаме нашия Streams API. Ние няма да говоря твърде много за това точно сега. Имам някои съдържание по-късно на в тестето за това. Но Streams е наистина running-- мисля за него като нареди на времето и промяна дял дневник. Всичко, което се случва на таблицата показва на потока. 

Всеки пишете на масата показва на потока. Можете да прочетете този поток, и можете да правите неща с него. Ще говорим за това, което видове неща, които общо с нещата, като репликация, създаване на вторични индекси. Всички видове наистина страхотно неща, които можете да направите с това. 

Типове данни. В DynamoDB, ние подкрепяме и двата ключа стойност и документ за данни типове. От лявата страна на екрана тук, ние имаме нашите основни видове. Ключови стойностни типове. Това са струни, цифри и бинарни файлове. 

Така само за три основни типа. И тогава може да има набор от тези. Един от най-хубавите неща за NoSQL е можете да съдържа масиви като свойства. И с DynamoDB можете да съдържа масиви от основни типове като корен собственост. 

И тогава там е типовете документи. Колко хора са запознати с JSON? Вие, момчета, запознати с JSON толкова много? Това е основно JavaScript, Object, нотация. Тя ви позволява да основно дефинира йерархична структура. 

Можете да съхраните документ JSON на DynamoDB използват общи компоненти или строителни блокове, които са налични в повечето езици за програмиране. Така че, ако имате Java, вие сте разглеждате карти и списъци. Мога да създавате обекти тази зона картата. А картата като ключови ценности съхранява като свойства. И това може да има списъци на стойности в рамките на тези свойства. Можете да съхраните този комплекс йерархична структура като един атрибут на т DynamoDB. 

Така маси в DynamoDB, като най- NoSQL бази данни, таблици имат позиции. В MongoDB бихте наричаме тези документи. И това ще бъде най-диван база. Също база данни документ. Наричаш тези документи. Документи или предмети имат атрибути. Могат да съществуват или атрибути не съществува в елемента. В DynamoDB, има едно задължително атрибут. Точно като в релационна база данни, имате първичен ключ на масата. 

DynamoDB има това, което наричаме ключова хашиш. Hash ключ трябва да е уникално. Така че, когато се определи хеш таблица, основно това, което искам да кажа, е всеки елемент ще има ключова хашиш. И всеки хеш бутона трябва да бъде уникален. 

Всеки елемент е дефиниран от тази уникална хеш бутона. И може да има само един. Това е ОК, но много пъти това, което хората се нуждаят от е те искат, е този хеш ключ да се направи малко по- от това просто да бъде уникален идентификатор. Много пъти ние искаме да използваме този ключ хеш като най-агрегация ниво кофата. И начина, по който направи това е чрез добавяне на това, което наричаме ключова диапазон. 

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

Така че аз може да има хеш ключ, който е ID на темата. И аз може да има ключова гама, който е ID на отговор. По този начин, ако искам да получите всички отговори за определена тема, Мога само да задава въпроси към хеш. Мога да кажа, просто ми даде всичко елементите, които имат този хеш. И аз отивам да получите всеки въпрос или да пусне тази конкретна тема. Тези топ струпвания ниво са много важни. Те подкрепят първичния достъп образец на заявлението. Най-общо казано, този е това, което искаме да направим. Искаме че table-- като заредите масата, ние искаме да се структурира данните в таблицата по такъв начин, че заявлението може много бързо извличане на тези резултати. И много пъти на начин да направите това е да запази тези съвкупности като ние въведете данните. По принцип, ние сме разпространение на данни в светлата кофата, тъй като идва инча 

Range ключове позволяват me-- хеш ключове трябва да бъдат равни. Когато се задава въпроси хеш, аз трябва да кажа, дайте ми хеш това се равнява на това. Когато се задава въпроси диапазон, I Може да се каже, дайте ми кръг че се използва всеки вид богата на оператор, че ние подкрепяме. Дайте ми всички предмети за хеш. Дали е равно, по-голямо от, по-малко от, пък започнем с това, е нужна тя между тези две стойности? Така че тези видове заявки обсег че ние сме винаги интересуват. Сега едно нещо за данни, когато погледнете достъп до данни, когато възможност за достъп до данните, това е Винаги около агрегация. Той винаги е около записите които са свързани с това. Дай ми всичко тук that's-- всички сделките по тази кредитна карта за последния месец. Това е съвкупност. 

Почти всичко, което правите в база данни, е някакъв вид агрегация. Така че да може да бъде в състояние да определи тези кофи и ще ви даде тези нива варират атрибути, за да може да задава въпроси относно, тези богати заявки подкрепят много, много, много модели за достъп приложение. 

Така че другото нещо хеш бутона прави, е това ни дава механизъм да бъде в състояние да се разпространява данните наоколо. NoSQL бази данни работят най-добре когато данните не са равномерно разпределени в клъстера. Колко хора са запознати с хеширане алгоритми? Когато казвам, хашиш и hashing-- защото един алгоритъм за хеширане е начин да бъде в състояние да генерира случайна стойност от дадена стойност. Така че в този конкретен случай, хеш алгоритъм бягаме е ND 5 въз. 

И ако имам ID, и това е моя хеш бутона, имам 1, 2, 3. Когато стартирам алгоритъм на хеш, то се случва да се върне и да се каже, и 1 е равно на 7В, 2 се равнява на 48, 3 равнява CD. Те са пръснати по целия ключ пространство. И защо правиш това? Защото това прави сигурен, че мога изведе записите в множество възли. 

Ако Правя това Постепенно, 1, 2, 3. И аз имам един хеш диапазон, който писти в този конкретен случай, малка хеш пространство, той работи от 00 до FF, След това записите ще дойде по- и те ще отидат 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. Какво става? Всяка вложка ще същия възел. Виждате ли какво имам предвид? 

Защото, когато аз се раздели пространството, и аз се разпространи тези записи цяла, и аз дял, аз отивам да се каже, дял 1 има ключово пространство 0-54. Partition 2 е 55-89. Partition 3 е AA до FF. Така че, ако аз съм с линейно увеличаване IDs, можете да видите какво се случва. 1, 2, 3, 4, 5, 6, всички начин до 54. Така, както аз съм чукане на записи в системата, всичко завършва ще един възел. 

Това не е добре. Това е antipattern. В MongoDB те имат този проблем ако не използвате бутона диез. MongoDB ви дава възможност на хеширане стойността на ключа. Винаги трябва да се направи, че ако сте с помощта на увеличаване хеш ключ в MongoDB, или ще бъде заковаване всеки запис на един възел, и ще се ограничава Вашата пиши пропускателна зле. 

АУДИТОРИЯ: Е, че A9 169 в десетична? 

Рик Houlihan: Да, това е някъде около там. A9, аз не знам. Ще трябва да си взема двоичен да десетичната калкулатор. Мозъкът ми не работи по този начин. АУДИТОРИЯ: Само един бърз една от вашите Монго коментари. Така е ID на обект, който идва роден с Монго направи това? Рик Houlihan: Има ли го правят? Ако го посочите. С MongoDB, имате възможност. Можете да specify-- всеки документ в MongoDB трябва да има документ за самоличност долна черта. Това е уникална стойност. 

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

Сега нещо за хеширане, след като хеш а value-- и това е защо хеш ключовете са винаги уникални заявки, защото съм се променили стойността, сега не мога да направя заявка диапазон. Не мога да кажа е това между това или онова, защото хеш стойност не върви да бъде еквивалентно на действителната стойност. Така че, когато хеш, че ключ, това е само между половете. Ето защо в DynamoDB хеш бутона заявки са винаги само между половете. 

Така че сега в диапазон key-- когато аз да добавя, че ключовата гама, тези ключови записи обсег на всички влизащи в и те се съхраняват на едно и също разпределение. Така че те са много бързо, лесно изтеглено, защото това е хашиш, това е диапазон. И вие виждате всичко със същата хеш получава съхраняват на същия дял пространство. Можете да използвате този ключ гама да помогне намерете вашите данни близо до своята майка. Така че това, което съм аз наистина правиш тук? Това е един към много отношения. Връзката между ключова хеш и клавиша за интервал е един за мнозина. Аз може да има множество ключове хеш. Аз може да има само множествена гама ключове в рамките на всеки хеш бутона. 

Хеш определя на родителя, определя обхвата на децата. Така че можете да видите има аналогов тук между релационния конструкт и едни и същи видове изгражда в NoSQL. Хората говорят за NoSQL като нерелационни. Това не е нерелационни. Data винаги има взаимоотношения. Тези взаимоотношения просто са моделирани по различен начин. Нека поговорим малко малко за издръжливост. Когато пишете, за да DynamoDB, пише винаги са трипътен повторен. Това означава, че ние имаме три AZ му. AZ са Наличност зони. Можете да мислите за един Наличност Zone като център за данни или колекция от центрове за данни. Тези неща са географски изолирани един от друг в различните разломни зони, през различни електрически мрежи и заливните равнини. А отказът на една от AZ не е ще вземе за определяне на друг. Те също така са свързани заедно с оптични нишки. Той поддържа една под 1 милисекунда латентност между АЗС. Така че реално време повторения на данни способен в мулти АЗС. 

И често мулти внедрявания от А до Я отговори на високите изисквания за наличност на повечето корпоративни организации. Така DynamoDB се разпространява в рамките на три АЗС по подразбиране. Ние само ще знанието на обезценката когато две от тези три възли се върне и да кажа, Да, аз го имам. Защо така? Защото от гледна точка на четене ние сме само ще ви дам данните назад, когато ние го получите от два възела. 

Ако аз съм репликира цяла три, а аз съм четене от две, Аз съм винаги гарантирано да има най-малко един на тези, които чете, за да бъде най- най-актуалната копие на данните. Това е, което прави DynamoDB последователна. Сега можете да изберете да включите тези, които последователно чете разстояние. В такъв случай аз ще кажа, Ще прочета само от един възел. И аз не мога да гарантирам, че ще ходи да бъде най-актуалните данни. 

Така че, ако един запис идва в, не е повторен още, започваш да се получи, че копие. Това е в крайна сметка последователно четене. И това, което е, че е половината от цената. Така че това е нещо, което да си помисля. Когато сте прочитане DynamoDB, и можете да започнете създаването на своя капацитет за четене единици, ако в крайна сметка избират последователна гласи, че е много по-евтино, това е около половината от разходите. 

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

Нека поговорим за индексите. Така че ние се споменава, че ниво агрегиране отгоре. Имаме хеш ключове, и ние имаме ключове обсег на действие. Това е хубаво. И това е на първичния масата, I имам една хеш бутона, аз имам един клавиш разстояние. 

Какво означава това? Имам един признак, че аз може да работи, богати на заявки. Това е ключът за обхват. Другите характеристики на този item-- Мога да филтрирате по тези атрибути. Но не мога да направя неща, като това започва с, или е по-голяма. 

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

Първият от тях ще говорим за. Така местните вторични са съжителствали на същия дял като данните. И като такива, те са на същата физическа възел. Те са това, което ние наричаме последователна. Значение, те ще признаят отписването заедно с масата. Когато пиша идва, ние ще пиша чрез индекса. Ние ще пиша до масата, и след това ние ще признаем. Така че това е последователна. След отписването е било признато от масата, това е гарантирано, че местно вторичния индекс ще има същата визия на данни. Но това, което те ви позволяват да направите, е да определи заместник ключове обсег на действие. 

Трябва да използвате една и съща хеш ключова като основна маса, защото те са едновременно намира на същия дял, и те са последователни. Но мога да се създаде форум с различни ключове обсег на действие. Така например, ако имах производител че имаше маса сурово части, идващи инча И сурови части идват в и те се агрегират чрез сглобяване. И може би има изземване. 

Всяка част, която е направена от тази производител след тази дата, Имам нужда да тегли от моята линия. Аз може да се върти на индекс че ще се търси, струпване на датата на производство на конкретната част. Така че, ако ми плот ниво е вече сегментира от производителя, може би това е била разположена върху част ID, I може да създаде индекс на разстояние, че на маса като сегментира по производител и варира от датата на производство. И по този начин мога да кажа, че всичко, е произведен между тези дати, Имам нужда да тегли от линията. Така че това е местен вторичния индекс. 

Това има за последица ограничаване си хеш ключ пространство. Защото те съжителствуват по същия съхранение възел, те ограничават хеш бутона пространство до 10 гигабайта. DynamoDB, под маси, ще си поделят Вашата маса на всеки 10 гигабайта. Когато поставите 10 участия на данни в, ние отидете [PhH], и ние добавяме друг възел. 

Ние няма да се раздели на LSI върху множество дялове. Ние ще се раздели масата. Но ние няма да се раздели на LSI. Така че това е нещо, важно да се разбере е, ако правиш много, много, много големи струпвания, След това започваш да бъде ограничена до 10 гигабайта на вашия LSIS. 

Ако това е така, ние можем използвате глобални вторични. Глобални вторични са Наистина друга маса. Те съществуват напълно изключен, за да от страна на основния си маса. И те ми позволи да се намери напълно различна структура. Така че мисля за него като се вмъква данни в две различни маси, структуриран по два различни начина. 

Мога да се определи напълно различни хеш ключ. Мога да се определи напълно различна ключова диапазон. И мога да изпълня този напълно независимо. В интерес на истината, аз съм провизирани моя капацитет за четене и пишат капацитет за моя глобални вторични индекси напълно независимо на основния си маса. Ако аз се определи този индекс, казвам това колко много четат и пишат капацитета, че ще използвате. 

И това е отделна от основния си маса. Сега и двете от индексите ни позволи да не само да определи хеш и обсег на ключове, но те ни позволи да проектира допълнителни стойности. Така че, ако искате да прочетете думата на индекса, и аз искам да взема малко набор от данни, Не трябва да се върнем към основната маса, за да получите допълнителни атрибути. Мога да проектира тези допълнителни атрибути в таблицата за подпомагане на схемата за достъп. Знам, че вероятно става в някаква Наистина, really-- заемайки плевелите тук на някои от тези неща. Сега аз трябва да плаващите от това. 

АУДИТОРИЯ: [недоловим] --table ключова означаваше, хеш? Оригиналният хашиш? Multi-лайстни? 

Рик Houlihan: Да. Да. Ключът за маса основно изтъква обратно към елемента. Така индексът е указател обратно оригиналните елементи на масата. Сега можете да изберете да се изгради индекс, който има само клавиша за маса, и няма други свойства. И защо бих могъл да направя това? Е, може би имам много големи предмети. 

Аз наистина само трябва да знаете which-- моя модел на достъпа може да се каже, кои елементи съдържа този имот? Не трябва да се върне на елемента. Просто трябва да знаете кои елементи да го съдържат. Така че може да се изгради индекси че има само ключ на таблицата. 

Но това е най-вече това, което индекс в база данни, е за. Това е за да може бързо идентифициране, която записва, които редове, които елементи в таблицата имат имотите, които аз съм търсят. 

GSIS, така че как работят те? GSIS основно са асинхронни. Актуализацията идва в таблицата, Масата е тогава асинхронно актуализиран всички от вашата GSIS. Ето защо са GSIS в крайна сметка последователно. 

Важно е да се отбележи, че когато сте изграждане GSIS, и да разберете дали създавате още едно измерение на aggregation-- Сега нека да кажем, един добър пример тук е производител. Мисля, че може да говори за производител медицинско устройство. Производители медицинско изделие често имат сериализирани части. Частите, които отиват в на смяна на тазобедрената става всичко има малко сериен номер върху тях. И те могат да имат милиони и милиони и милиарди части във всички устройства, които те доставят. Е, те трябва да се обединят под различни размери, всички части в устройство, всички части, които са направени по определена линия, всички частите, които дойдоха в от определен производител на определена дата. И тези струпвания понякога ставам на милиарди. 

Така че аз работя с някои от тези момчета, които страдат защото те са създаване тези ginormous струпвания в техните вторични индекси. Те може да имат сурови части таблица, която идва като само хеш. Всяка част е с уникален сериен номер. Аз използвам сериен номер като хашиш. Красиво е. Сурова My таблица данни се разпространяват всички в ключов пространство. My [? пиша?] [? поглъщане?] е страхотно. Аз отнеме много данни. След това, което те правят, е те създават GSI. И аз казвам, знаеш ли какво, аз трябва да се види всички части за тази производителя. Е, всички изведнъж съм като един милиард редове, и да ги натъпча върху един възел, защото когато Аз се обединят като производител ID като хашиш, и номера на частта, като интервала, тогава всички изведнъж съм извеждайки един милиард части в това, което този производител ме избави. 

Това може да предизвика много на натиск върху GSI, отново, защото аз съм с чук един възел. Слагам всичко това вмъква в един възел. И това е един истински случай проблемна употреба. Сега, аз имам добър дизайн модел за това как да се избегне това. И това е един от проблемите, че аз винаги работя. Но какво се случва, е GSI може не разполагат с достатъчно капацитет за запис да бъде в състояние да прокара всички онези, редове в един възел. И какво се случва след това е първична, масата на клиента, основната маса ще се намали скоростта защото GSI не може да се справи. Така че моят вложка процент ще падне върху първичната таблица като моя GSI се опитва да се справи. 

Добре, така е GSI, LSI е, кой трябва да използвам? LSI са последователни. GSI са в крайна сметка последователно. Ако това е ОК, аз препоръчваме да използвате GSI, те са много по-гъвкави. LSI може да се моделира като GSI. И ако размерът на данни на хеш ключове в вашата колекция надхвърля 10 гигабайта, тогава вие ще искате да използвате, че GSI, защото това е просто един твърд лимит. 

Добре де, мащабиране. Пропускателна в Динамо DB, вие разпоредба, могат да [недоловим] пропускателна способност до масата. Ние имаме клиенти, които имат провизирани 60 billion-- правят 60 милиарда заявки, редовно работещ на над един милион заявки в секунда на нашите маси. Има наистина няма теоретична граница колко и колко бързо масата може да работи в Динамо DB. Има някои, меко ограничения на профила си че ще се постави там, така че че да не се побърка. Ако искате повече от че не е проблем. Ти дойде да ни каже. Ние ще се появи на циферблата. 

Всяка сметка се ограничава до известна степен във всеки сервиз, само на разстояние бухалката така че хората не полудяват самите получите в беда. Няма ограничение в размера. Можете да поставите произволен брой на елементи на една маса. Размерът на даден елемент е ограничени до 400 килобайта всеки, че не би било позиция атрибути. Така сумата от всички атрибути се ограничава до 400 килобайта. И след това отново, ние имаме това малко LSI въпрос с ограничението от 10 гигабайт в хеш. АУДИТОРИЯ: Малък брой, аз съм липсва това, което ми казваш, че is-- АУДИТОРИЯ: О, 400 килобайт е максималният размер за всяка позиция. Така че даден елемент има всички атрибути. Така че 400 к е общият размер на тази позиция, на 400 килобайта. Така че на всички атрибути Смесените, всички данни, това е във всички тези атрибути, навити в общия размер, Понастоящем днес границата на т е 400 к. Така мащабиране отново, постигната чрез разделяне. Пропускателна се провизират на нивото на масата. И там наистина две копчета. Запознати сме капацитет и пишат капацитет. 

Така че те са регулирани независимо един от друг. Мярка RCU е строго последователна чете. ОК, така че ако сте казвайки Искам 1000 RCU на тези, които са строго последователна, тези, които са в съответствие чете. Ако кажете, аз искам евентуална последователна прочитания, можете разпоредба 1000 RCU си, ти започваш за да получите 2000 в крайна сметка последователна чете. И половината от цената за тези, в крайна сметка се състои в чете. 

Отново, коригирана независимо един от друг. И те имат throughput-- Ако консумирате 100% от вашия RCU, вие няма да въздейства на наличност на вашите права. Така че те са напълно независимо един от друг. Добре, така че едно от нещата, които Споменах за кратко бе дроселиране. Дроселиране е лошо. Дроселиране показва лошо не SQL. Има неща, които можем да направим, за да помогнем ви облекчи Дроселирането че сте преживяваме. Но най-доброто решение да това е нека да Един поглед към това, което правиш, защото има анти-модел в играта тук. 

Тези неща, неща като нееднакво натоварвания, горещи клавиши, горещи прегради. Аз съм удря определена ключова пространство много трудно за някои конкретна причина. Защо правя това? Нека да разберат това. Аз съм смесване моите горещи данни със студени данни. Пускам моите маси получите огромна, но има наистина само някои подмножество на данните това е наистина интересно за мен. Така че за регистрационните данни, например, много клиентите, те ще получат влезте данни всеки ден. Хванаха огромно количество данни дневник. 

Ако сте само дъмпинг всичко, което дневник данни в една голяма маса, с течение на времето тази таблица ще получите масивна. Но аз съм наистина се интересуват само в последните 24 часа, последните седем дни, през последните 30 дни. Каквато и да е време на прозореца че аз се интересувам от начало за събитието, което ме притеснява, или случай, че това е интересно за мен, това е единственият прозорец път, че имам нужда. Така че защо съм пускането на 10 години стойност на регистрационните данни в таблицата? Какво който причинява е масата на фрагмента. 

Той получава огромна. Започва разстилане през хиляди възли. И тъй като капацитета си е толкова ниско, че си всъщност ограничаваща скоростта за всяка един от тези отделни възли. Така че нека да започнем да гледаме как ние се търкаля, че маса над. Как да успеем, че данните малко по-добре да се избегнат тези проблеми. И това, което изглежда това? Това е нещо, което прилича това. Това е, което лошо NoSQL прилича. 

Имам горещ клавиш тук. Ако погледнете на страната тук, това са всички мои дялове. Аз имам 16 прегради тук по тази определена база данни. Ние правим това през цялото време. Пускам тази за клиентите всички времена. Тя се нарича карта на топлина. Heat картата ми казва как сте достъп до вашата ключова пространство. И какво е това ми казва е че има едно специално хашиш че този човек се интересува от едно ужасно много, защото той е тя удря наистина, наистина трудно. 

Така синьото е хубаво. Ние обичаме синьо. Ние не обичаме червено. Червен, където налягането получава до 100%. 100%, сега ти започваш да се намали скоростта. Така че всеки път, когато те видя някакви червени линии като this-- и това не е само Dynamo DB-- всяка база данни NoSQL има този проблем. Има анти-модели, които могат да управлява тези типове състояния. Какво да направя, е да се работи с клиенти за облекчаване на тези условия. 

И това, което изглежда това? И това е извличане на максимума от Dynamo DB пропускателна но това е наистина се максимума от NoSQL. Това не е ограничено до Dynamo. Това е definitely-- I се използва за работа в Монго. Запознат съм с много NoSQL платформи. Всеки има тези видове на топла ключови проблеми. За да получите най-доброто от всеки NoSQL база данни, по-специално Dynamo DB, Искате ли да създадете таблиците където елементът на хеш бутона има голям брой различни стойности, висока степен на кардиналност. Защото това означава, че аз пиша да много различни кофи. 

Колкото повече кофи аз съм писмено да, толкова по-вероятно Аз съм за да се разпространи, че пиша товар или Прочети зареди изложени в множество възли, толкова по-вероятно съм да има висока производителност на масата. И тогава аз искам стойностите, които се исканата сравнително равномерно във времето и равномерно, както на случаен принцип, колкото е възможно. Е, това е нещо интересно, защото аз наистина не може да контрол, когато потребителите идват. Така че е достатъчно да кажа, ако ние се разпространи нещата в цялата ключова пространство, ние най-вероятно ще бъде в по-добра форма. 

Има известна период от време за доставка че ти няма да бъде в състояние контрол. Но тези, които са наистина най- две измерения, които имаме, пространство, достъп до равномерно разпространението, време, искания пристигащи равномерно разположени във времето. И ако тези две условия са спазени, тогава това е за какво става ще изглежда. Това е много по-хубав. Ние сме наистина щастливи тук. Имаме много дори модел достъп. Да, може би сте се лек натиск всеки сега и тогава, но нищо наистина твърде обширна. Така че това е невероятно колко пъти, когато се работи с клиенти, че първата графика с големия червен бар и всичко, което грозно жълто това е по цялото място, ние се свърши с упражняването след няколко месеца на повторно архитектура, те работите точно същото натовареността на точно същото натоварване. И това е, което го гледа като сега. Така че това, което получавате с NoSQL е схема данни, която е абсолютно обвързани с модела за достъп. 

И вие можете да оптимизирате, че схемата на данни да подкрепя този модел достъп. Ако не го направите, тогава започваш за да видите тези видове проблеми с тези горещи клавиши. 

АУДИТОРИЯ: Е, неизбежно някои места ще бъде по-горещо, отколкото други. 

Рик Houlihan: Винаги. Винаги. Да, искам да кажа, че винаги има A-- и отново, има някои модели дизайн ще получите чрез че ще говорим за това как да се справите с тези супер големи струпвания. Искам да кажа, аз трябва да ги има, как да се справим с тях? Имам доста добра съдебна ползване че ние ще говорим за за това. 

Добре, така че нека да поговорим за някои клиенти сега. Тези момчета са AdRoll. Аз не знам дали сте запознат с AdRoll. Вероятно ги видите много на браузъра. Те са рекламни повторно насочване, те са най-големият бизнес реклама повторно насочване там. Те обикновено редовно прегазен 60 милиарда транзакции на ден. Те правят над милион транзакции в секунда. Те имат доста проста маса структура, най-натовареното масата. Това е основно само една хеш ключ е бисквитка, диапазонът е демографски категория, и след това третата характеристика е резултатът. 

Така че всички ние имаме бисквитки в нашият браузър от тези момчета. И когато отидеш до участващите търговец, те на практика ви вкара в цяла различни демографски категории. Когато отидете в един сайт и ви кажа, че искам да видя този ad-- или основно да не кажа that-- но когато отидете на сайта те казват искате да видите тази реклама. И те иди се, че рекламата от AdRoll. AdRoll ви гледа отдолу нагоре на трапезата си. Смятат си бисквитка. Рекламодателите разказващи ги, искам някой Кой е на средна възраст, 40-годишният мъж в спорта. И те ви вкара в тези демографски и те решават дали или не че това е добра реклама за вас. 

Сега те имат SLA с рекламните си доставчици да предостави под-10 милисекунди отговор на всяка една заявка. Така че те използват Dynamo DB за това. Те ни удря милион заявки в секунда. Те са в състояние да направят цялата си заявки, сортировка всички тези данни, и се получи, че добавката линк към които рекламодатели в рамките на 10 милисекунди. Това е наистина доста феноменален изпълнение, които те имат. 

Тези момчета actually-- са тези момчета. Аз не съм сигурен дали това е тези момчета. Може да е тези момчета. По принцип us-- казал не, аз не мисля, че ги е бил. Мисля, че беше някой друг. Работех с клиент, който ми каза, че сега, че те имат отишъл в Динамо DB, те са харчат повече пари за закуски за техния екип за развитие на всеки месец отколкото те харчат за тяхната база данни. Така че ще ви дам един идея за намаляване на разходите че можете да получите в Динамо DB е огромна. Добре, dropcam е друга компания. Това момче е вид of-- ако смятате на интернет на нещата, dropcam е основно видео охрана интернет. Слагаш фотоапарата си там. Camera разполага с детектор за движение. Някой идва заедно, задейства точка бияч. Camera започва да записва за известно време, докато тя не открие всяко движение вече. Поставя че видео до по интернет. 

Dropcam е компания, която е основно преминах на Динамо DB защото те бяха изпитват огромни болки на растежа. И това, което те ни казаха, Изведнъж петабайта данни. Те не са имали представа тяхната услуга ще бъде толкова успешна. Повече външен видео от YouTube е това, което тези момчета стават. Те използват DynamoDB да следите всички метаданни за всички свои видео ключови точки. 

Така че те имат S3 кофи те изтласкват всички двоични артефакти в. И тогава те имат Dynamo DB записи, които посоча хората към тези S3 три обекта. Когато те трябва да погледнете на видео, те гледам записа в Динамо DB. Те кликнете върху линка. Те събарят видеото от S3. Така че това е вид как изглежда това. И това е направо от техния отбор. 

Dynamo DB намалява тяхната време за доставка за видео събития от пет до 10 секунди. В напреднала релационна магазин, те използват да трябва да отида и да се изпълни множество сложни заявки, за да разбера кои клипове да събарят, до по-малко от 50 милисекунди. Така че това е невероятно, невероятно колко производителност можете да получите при оптимизиране и настроите основната база данни за подпомагане на схемата за достъп. Halfbrick, тези момчета, какво е това, Fruit Ninja предполагам е тяхното нещо. Това всички писти на Динамо DB. И тези момчета, те са чудесен развитие на екипа, голямо развитие магазин. 

Не е добър отбор операции. Те не са имали много на експлоатационните ресурси. Те се бореха се опитват да поддържат приложението им инфраструктура нагоре и работи. Те дойдоха при нас. Гледаха, че Динамо DB. Те казаха, че това е за нас. Те построили целия им прилагането рамка върху него. Някои наистина хубави коментари тук от екипа на тяхната способност до сега се съсредоточи върху изграждане играта, а не се налага да се запази инфраструктура, която се превръща в огромно количество на надземната за отбора си. Така че това е нещо, на that-- полза, което получавате от Dynamo DB. 

Добре, заемайки моделиране на данни тук. И ние говорихме малко за това 12:59, един към много, и мнозина за много тип взаимоотношения. И как да поддържат тези в Динамо. В Динамо DB ние използваме индекси, най-общо казано, за да завъртите данните от един аромат на друга. Hash ключове, ключове обсег, както и индексите. 

В този конкретен Например, тъй като повечето държави има изискване за лицензиране, които само един лиценз на водача на човек. Вие не можете да отидете да се драйвер за двама лицензии в състояние на Бостън. Не мога да го направя в Тексас. Това е вид на такъв, какъвто е. И така, в DMV, имаме заявки, ние искам да гледам шофьорската книжка от номера на социалната сигурност. Искам да се запознаете с подробностите на потребителите по брой шофьорската книжка. 

Така че можем да имаме маса на потребителя, че има ключова хеш на серийния номер, или номера на социалната сигурност, и различни атрибути, дефинирани върху елемента. Сега на тази таблица I може да се определи, че GSI преобръща, че около която казва искам ключова хашиш в лицензията и след това всички други елементи. Сега, ако искам да задава въпроси и да намерят лиценз номер за всеки даден социален Номер на сигурност, което мога задава въпроси към главната маса. 

Ако искам да задава въпроси и аз искам за да получите от социално осигуряване номер или други атрибути от Номер на разрешителното, аз може да задава въпроси на GSI. Този модел е, че един една връзка. Само един много прост GSI, флип тези неща наоколо. Сега говорим за един за мнозина. One за мнозина е основно Вашата хеш бутона обхват. Когато ние се много с това използване случай е на данни от наблюдение. Данни Monitor предлага в редовна интервал, като интернет на нещата. Ние винаги се всички тези записи идват през цялото време. 

И аз искам да намеря всички показания между определен период от време. Това е много често срещан въпрос в мониторинг инфраструктура. Начинът, по който да отида за това е да се намери проста таблица структура, една таблица. Имам таблица с измервания на устройства с хеш бутона на ИД на устройството. И аз имам ключ гама относно клеймото, или в този случай, епоса. И това ми позволява да изпълни комплекс на заявки, че ключовата гама и да се върнете тези записи, които са по отношение на резултата определя, че аз търся. И то се натрупва, че един до много отношения в основната таблица с помощта на хеш ключ, гама ключовата структура. 

Така че това е вид построена в таблицата в Динамо DB. Когато се определи хеш и обхват тона маса, аз съм определяща един към много отношения. Това е връзката родител-дете. 

Нека поговорим за мнозина в много отношения. И за този конкретен пример, отново, ние ще използваме GSI е. И нека да говорим за игри сценарий, при който имам даден потребител. Искам да разберете, че всички игри той е регистриран за или да играете инча И за дадена игра, I искате да намерите всички потребители. Е, как да го правя? Моята маса потребителски игри, аз отивам да имат ключова хеш на потребителското ID и ключов набор от играта. 

Така потребителят може да има няколко игри. Това е един от много отношения между потребителя и игрите той играе. И тогава на GSI, Ще флип, че наоколо. Аз ще разискват върху играта и Аз ще варират от потребителя. Така че, ако искам да получите всички ръководство за игра играе в, Ще задава въпроси към главната маса. Ако искате да получите всички потребители които играят определена игра, I сверки с GSI. Така че виждате как правим това? Вие се изгради тези GSI да подкрепи използване случай, заявлението, достъпът модел, приложението. 

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

Вероятно аз няма да прекарват твърде много време да говорим за документи. Това става малко, вероятно, по-дълбоко, отколкото имаме нужда, за да отидат в. Нека поговорим малко около богато изразяване заявка. Така че в Динамо DB имаме способността да се създаде това, което наричаме прожекционни изрази. Проекционни изрази са просто бране на полетата или стойностите който искате да покажете. OK, за да мога да направите избор. I направи заявка срещу Динамо DB. И аз казвам, знаеш ли какво, шоу ми само прегледите пет звездни за този конкретен продукт. Така че това е всичко, което искам да видя. Аз не искам да видя всички други атрибути на реда, Аз просто искам да видя това. Това е точно като в SQL, когато казват изберете звезда или от маса, можете да получите всичко. Когато казвам, изберете име от маса, аз само се получи един атрибут. Това е един и същи вид на нещо, което в Dynamo DB или друг NoSQL бази данни. Филтър изрази ми позволяват да основно намали резултата остави. Така че аз се направи запитване. Запитване може да се върне с 500 позиции. Но аз искам само елементите, които имат атрибут, който казва това. ОК, така че нека да филтрирате тези позиции които не отговарят на този конкретен въпрос. Така че ние имаме филтърни изрази. 

Филтър изрази могат да да се движат по всяко атрибут. Те не са искали заявки обсег на действие. Вдигнете заявки са по-селективни. Филтър заявки изискват от мен да отида се определят цели резултатите и след това обособяването на данните не искам. Защо е важно? Защото всичко се чете. В заявка, аз отивам да се чете и това ще бъде една гигантска за данни. И тогава аз ще обособяването, което ми трябва. И ако аз съм само дерогиране Няколко реда, след това е ОК. Това не е толкова неефективна. 

Но ако аз съм четене цял куп данни, само за обособяването един елемент, След това аз ще бъде по-добре на разстояние с помощта на заявка гама, защото това е много по-селективни. Това ще ми спести много пари, защото аз плащам за това четиво. Ако резултатите, че се връща пресичане на тел може да бъде по-малък, но аз съм плащат за четене. Така че разбирам как вие получавате данните. Това е много важно в Динамо DB. 

Условни изрази, това е, което може да се нарече оптимистично заключване. Актуализация, ако е налице, или ако тази стойност е еквивалентно на това, което аз зададени. И ако имам време печата на запис, че може да прочете данните. Аз може да се промени, че данните. Мога да отида на запис обратно данни към базата данни. Ако някой се е променило записа, клеймото може да са се променили. И по този начин ми условно актуализация може да се каже актуализация ако клеймото равнява това. Или актуализацията ще се провали, защото някого обновява записа междувременно. 

Това е, което ние наричаме оптимистично заключване. Това означава, че някой може да дойде и да я промените, и аз отивам да го открие когато се върна, за да пиша. И тогава всъщност мога да чета, че данни и да кажа, о, той се промени това. Трябва да се отчете, че. И мога да променя данните в моята записва и прилага друга актуализация. Така че можете да хванете тези частичното актуализации, които се случват между времето да прочетете на данни и време може да се напише данните. 

АУДИТОРИЯ: И филтъра изразяване всъщност не означава, в броя или not-- 

[Вмъкване VOICES] Рик Houlihan: Не искам получите твърде много в това. Това е запазена дума. Изгледът на паунд е запазено ключова дума в Динамо DB. Всяка база данни има свой запазени имена за колекции не можете да използвате. Dynamo DB, ако посочите една лира в предната част на този, можете да зададете тези имена до горе. Това е посочена стойност. Това вероятно не е най-добрият синтаксис за има до там за тази дискусия, тъй като попадне в някои real-- Аз щях да се говори по- за това по-дълбоко ниво. 

Но е достатъчно да кажа, това би могло да сканирате заявка, където те views-- нито гледка паунд е по-голямо от 10. Тя е цифрова стойност, да. Ако искате, можем да говорим за че след дискусията. Добре, така че ние сме заемайки някои сценарии в най-добрите практики къде отиваме да говори за някои приложения тук. Какви са случаите на употреба за Dynamo DB. Какви са дизайна модели в Динамо DB. 

И първият, ние ще се говори за е интернет на нещата. Така получаваме много of-- Предполагам, това, което е it-- повече от 50% на трафика в интернет тези дни всъщност, генерирани от машини, автоматизирани процеси, които не са от хората. Искам да кажа това нещо, че това нещо вие носите в джоба си, колко данни, че това нещо е всъщност изпращане около без теб да го знаят, е абсолютно невероятно. Вашето местоположение, информация за това как бързо започваш. Как мислите, че Google Maps работи когато те ви кажа какво е трафик. Това е така, защото има милиони и милиони хора по целия път с автомобил с телефони, които изпращат данни от цял ​​място през цялото време. Така че едно от нещата, за този тип на информация който идва в, данни от наблюдение, влезте данни, хронологични данни, е, че е обикновено само интересна за малко време. След това време, това е не толкова интересно. Така че ние говорихме за, не позволявайте тези таблици растат без граници. Идеята тук е, че може би аз имам 24 часа на стойност от събития в моя гореща маса. И това горещо маса ще бъде провизирани на много висока скорост, защото тя е като много данни. То е като много данни и аз съм го прочетете много. Имам много работа заявки, работещи срещу това данни. 

След 24 часа, хей, ти знам какво, не ми пука. Така че може би всеки полунощ I ролка моята маса над на нова маса и аз deprovision тази таблица. И аз ще взема и дистанционното управление на Определяне на инвалидни колички, защото 24 часа по-късно Аз не бягам толкова, на заявки, че данните. Така че аз отивам да се спестят пари. И може би 30 дни по-късно аз не правя дори трябва да се грижи за всичко това. Можех да взема за инвалидни колички-те чак до един, защото вие знаете какво, това е никога няма да се записва. Данните са на 30 дни. Той никога не се променя. 

И това почти никога не се случва да се чете, така че нека просто приемете, че RCU до 10. И аз съм спестяване на много пари за това данни, а само да плащат за моите горещи данни. Така че това е важното да погледнем най-, когато търсите в един времеви редове данни, идващи в по обем. Това са стратегии. Сега, аз може просто да го даде под наем всички отидете на една и съща маса и просто да споделите тази маса расте. В крайна сметка, аз отивам да виж проблеми с производителността. Отивам да се наложи да започнете да архивирате някои от тези данни извън масата, какво не. 

Нека по-добре проектира вашата кандидатура така че да може да работи по този начин право. Така че това е просто автоматично в кода на приложението. В полунощ всяка вечер търкалянето на масата. Може би това, което имам нужда е плъзгаща прозорец от 24 часа на данни. След това редовно съм обадите на данни извън масата. Аз съм го подстригване с Cron работни места и аз съм го прати върху тези други таблици, каквото ви трябва. Така че, ако преобръщане работи, това е страхотно. Ако не, отрежете го. Но нека да се запази, че горещо данни далеч от вашите студени данни. Това ще ви спести много пари и направите своя маси по-ефективните. Така че следващото нещо, което ние ще говорим за е продуктов каталог. Каталог на стоките е доста често срещано при употреба. Това всъщност е много общ модел че ние ще видим в най-различни неща. Знаеш ли, Twitter за Например, една гореща туит. Всеки идва и измъкна, че туит. Каталог на стоките, имам продажба. Имам гореща продажба. Имам 70,000 заявки в Второто пришествие на продукт описание от моя продуктов каталог. Ние виждаме това в търговията на дребно операция доста малко. Е, как да се справим с това? Няма начин да се справят с това. Всички мои потребители искат да видят същото парче данни. Те идват в, едновременно. И всички те са прави искания за същата част от данните. Това ми дава, че горещ клавиш, че голям червен лента върху графика, че не ни харесва. И това е нещо, което прилича това. Така през ключовата моето пространство аз съм се изкован в елементите на продажба. Аз съм се нищо никъде другаде. 

Как да се избегне този проблем? Е, ние се облекчи това с кеша. Cache, ще ви постави в основата на по-памет дял в предната част на базата данни. Успяхме [Недоловим] кеш, как си може да създаде свой собствен кеш, [недоловим] кеш [? г,?] каквото си искате. Сложете че в предната част на базата данни. И по този начин можете да съхранявате данните от тези горещи клавиши нагоре в тази кеш пространство и прочетете кеша. 

И тогава повечето от вашия прочитания да започнат да търсят по този начин. Аз имам всички тези кеш хитове тук и аз имам нищо случва тук защото базата данни е седнал зад кеш и никога не се чете, да дойде чрез. Ако мога да променя данните в база данни, трябва да се актуализира кеша. Ние можем да използваме нещо като струи, за да направим това. И аз ще ти обясня как става. Добре, съобщения. Email, всички ние използваме имейл. 

Това е доста добър пример. Имаме някаква съобщения маса. И ние имаме входяща и изходяща поща. Това е, което би SQL изглежда като да се изгради, че пощенската кутия. Ние вид използва същия вид на стратегия, която да се използва от GSI, GSI е за моята пощенска кутия и ми изходящи. Така че аз имам сурови съобщения, идващи в моята маса съобщения. И първия подход към този може да е, да речем, OK, няма проблем. Имам суровини съобщения. Съобщения следващите [недоловим], ID съобщение, че е страхотно. Това ми е уникална хашиш. Отивам да се създадат две GSI, човек за моята пощенска кутия, една за моя изходящи. И първото нещо, което ще направя е аз ще кажа моето хеш бутона е ще бъде на получателя и Отивам да се организира на датата. Това е фантастично. Имам хубава мое мнение тук. Но има един малък проблем тук. И се сблъскате с този в релационни бази данни, както и. Те призоваха вертикално разделяне. Вие искате да запазите вашата голяма данни далеч от децата ви данни. 

И причината е, защото аз трябва да отидете прочетете елементите, за да получите атрибутите. И ако органите са моите тук, След четене само на няколко позиции ако дължината на тялото ми е средно 256 килобайта всеки, по математика получава доста грозна. Така че да кажа, че искате да прочетете Давид пощенска кутия. Давид пощенска кутия има 50 позиции. Средната стойност и размер е 256 килобайта. Тук е моят коефициент на конверсия за RCU е четири килобайта. 

OK, нека да отидем с в крайна сметка последователно чете. Аз съм все още яде 1600 RCU си само за да прочетете Давид пощенска кутия. Ох. Добре, сега нека помислим за това как работи приложението. Ако аз съм в имейл приложение и Търся в моята пощенска кутия, и аз гледам на тялото на всяко съобщение, не, аз съм гледам в обобщенията. Търся в само заглавията. Така че нека да се изгради структура на маса че прилича повече на това. 

Така че тук е информацията че ми работен процес се нуждае. Това е в моята пощенска кутия GSI. Това е датата, на изпращача, предмет, а след това ID на съобщението, което сочи обратно на масата за съобщения къде мога да получа тялото. Е, това ще бъде рекордно IDs. Те ще посоча обратно към т IDs на масата за Dynamo DB. Всеки индекс винаги creates-- Винаги има елемента ID като част of-- че идва с индекса. 

Всичко е наред. АУДИТОРИЯ: Това го казва къде се съхранява? Рик Houlihan: Да, тя казва, exactly-- това е точно това, което прави. Той казва, че тук ми е отново рекорд. И това ще го насочите обратно към моя повторно рекорд. Точно. ОК, така че сега моята пощенска кутия е действително много по-малък. И това всъщност подкрепя работния процес на имейл ап. Така че моята пощенска кутия, аз кликнете. I отиде заедно и аз кликнете върху съобщението, това е, когато аз трябва да отида да тялото, защото аз отивам да отидете на различно мнение. Така че, ако мислите, че за тип на MVC рамка, модел оглед контролер. 

Моделът съдържа данни, че нуждите на виждане и контролера взаимодейства с. Когато се променя рамката г., когато Аз се промени перспективата, това е ОК, за да се върнете към сървър и населят модел, защото това е това, което потребителят очаква. Когато те се променят възгледи, това е, когато можем да се върнем към базата данни. Така имейл, кликнете. Търся за тялото. Отиване и връщане. Иди да вземеш тялото. 

Четох много по-малко данни. Аз съм само четене на органите, които Дейвид се нуждае, когато той се нуждае от тях. И аз не съм изгаря през 1600 г. RCU просто да покаже пощенската му кутия. Така че сега that-- това е начинът че LSI или GSI-- Съжалявам, GSI, ще се получи. Имаме нашата хеш за получателя. Имаме ключа обхват на датата. И ние имаме прогнозираните атрибути че ние трябва само да подкрепят мнението. 

Ние се върти, че за изходящи. Hash на подателя. И по същество, ние имаме на много хубаво, чисто гледката. И това е basically-- ние има тази хубава съобщения таблица, която е се разпространява добре, защото това е само хеш, сегментира съобщение ID. И ние имаме два индекса, че въртящ се изключва от тази таблица. Добре, така че идеята тук е не запази големите данни и това малко данни заедно. Разделя вертикално, разделя тези таблици. Не четете данни не е нужно да. Добре, игри. Ние всички искали игри. Най-малко ми харесва игри след това. Така че някои от нещата, че ние се справят с, когато мислим, игри, нали? Gaming тези дни, особено мобилна игри, е всичко за мислене. И аз отивам да се върти тук малко далеч от DynamoDB. Отивам да се въвеждат в някои от дискусията около някои от най- други технологии AWS. 

Но идеята за игри е да се мисли, за по отношение на APIs, APIs, които са, най-общо казано, HTTP и JSON. Това е начина, мобилни игри вид взаимодействат с техните краища обратно. Те правят JSON командироване. Те се получават данни, и това е всичко, най-общо казано, в приятни JSON APIs. 

Неща като получите приятели, да получат данните за класиране, за обмен, генерирано от потребителите съдържание, бутнете обратно в системата, това са видове неща че ние ще направим. Binary данни актив, тая информация може и да не седят в базата данни. Това може да седне в обект магазин, нали? Но на базата данни ще се в крайна сметка казва системата, казвам прилагането къде да отида да го получи. И неизбежно, мултиплейър сървъри, задния край на инфраструктурата, и проектирани за висока наличността и мащабируемост. Така че това са неща, които всички ние искаме в игралната инфраструктура днес. 

Така че нека да разгледаме най- какво прилича това. Има ядро ​​задния край, много ясна. Имаме система тук с наличност няколко зони. Ние говорихме за АЗС като being-- мисля, от тях като отделни центрове за данни. Повече от един център на данни на AZ, но това е ОК, Просто мисля за тях като отделни данни центрове, които са географски и вина, изолиран. 

Отиваме да имат Няколко EC2 случаи. Отиваме да имат някои задния край на сървъра. Може би ако си наследство архитектура, ние сме използване на това, което наричаме RDS, релационни бази данни. услуги Може да MSSQL, MySQL, Или нещо такова. Това е начина, по който наяждане приложения са предназначени днес. 

Ами ние може да искате да отидете с това е, когато сме на котлен камък. Ние ще вървим напред и да сложи кофата S3 там. И това S3 кофа, вместо да служи до тези предмети от нашето servers-- бихме могли да направим това. Поставяте всичките си двоичен обекти на вашите сървъри и можете да използвате тези сървъра инстанции, за да служат на тези данни до. Но това е доста скъпо. 

По-добър начин да направите е да отидете напред и да постави тези обекти в S3 кофа. S3 е обект на транзакции. Той е построен специално за генерирането на тези видове неща. И нека тези клиенти да поискат директно от тези обекти кофи, разтоварят сървърите. Така че ние започваме да мащабирате тук. 

Сега имаме потребители по целия свят. Имам потребители. Трябва да има съдържание на местно ниво разположен в близост до тези потребители, нали? Аз създадох S3 кофа като моя източник хранилище. И аз ще отпред, че с разпределението CloudFront. 

CloudFront е CD и съдържание доставка мрежа. По принцип това отнема данни, които сте задали и всичко това кешира по интернет така че потребителите могат да имат навсякъде много бърза реакция, когато те искат тези предмети. 

Така че можете да получите представа. Ти си вид деблокирането всички аспекти на AWS тук, за да постигнем това. И в крайна сметка, ние изхвърляме в автомобил мащабиране група. Така че нашите AC2 случаи от нашите играта сървъри, тъй като те започват да получите по-зает и по-богат и по-богат, те просто ще се върти друг Например, върти друг пример, върти друга инстанция. Така че технологията AWS има, тя позволява да зададете параметрите около което вашите сървъри ще растат. Така че можете да имате п брой сървъри там във всеки даден момент. И ако вашият товар отива, те ще свие, броят ще се свие. И ако товарът се връща, то ще расте обратно, еластично. 

Така че това изглежда страхотно. Имаме много EC2 инстанции. Можем да сложим в кеш Пред базите данни, опитайте и ускоряване на базите данни. Следващата точка налягане Обикновено хората виждат е те мащабирате игра с помощта на релационна система за база данни. Господи, в базата данни изпълнението е ужасно. Как можем да подобрим това? Нека се опитаме извеждайки кеш пред това. 

Е, кеш не работи толкова голяма, в игри, нали? За игри, писане е болезнено. Игрите са много тежки пишат. Cache не работи, когато сте напиши тежка, защото винаги сте Трябва да се актуализира кеша. Можете актуализира кеша, това е без значение да се кешира. Това всъщност е само допълнителна работа. 

Е, къде да отидем тук? Имаш голяма пречка там долу в базата данни. И мястото да отида Очевидно е разделяне. Разделяне не е лесно да се направи, когато сте занимаващи се с релационни бази данни. С релационни бази данни, вие сте отговаря за управлението, ефективно, ключовото пространство. Искаш да кажеш, потребителите между A и M отидете тук, между N и Z отида там. И вие преминавате в заявката. Така че имаш работа с този източник дял с данни. Имате транзакционни ограничения които не обхващат дялове. Имаш всички видове обърканост, че сте занимаващи се с определяне там се опитват да се справят с мащабиране на и за изграждане на по-голяма инфраструктура. Това е просто не е забавно. 

АУДИТОРИЯ: Значи искате да кажете, че увеличаване на изходните точки ускорява процеса? Рик Houlihan: Повишаване? АУДИТОРИЯ: Източник точки. Рик Houlihan: Източник точки? АУДИТОРИЯ: От информацията, когато информацията идва от? Рик Houlihan: No. Това, което казвам, е увеличаване на брой дялове в хранилището на данни подобрява пропускателната способност. Така че това, което се случва тук е потребителите влизат в EC2 инстанция тук, добре, ако имам нужда от един потребител това е A да M, аз ще отида тук. От N до р, аз ще отида тук. От P до Z, аз ще отида тук. 

АУДИТОРИЯ: OK, така че тези, които са всички съхранявани в различни възли? 

Рик Houlihan: Да. Мислете за тях като различни силози от данни. Така че можете да започнете да се налага да направите това. Ако се опитвате да направите, това, ако се опитвате да скалата на релационна платформа, това е това, което правите. Вие сте като данни и можете да започнете да го отрежете надолу. И ти го разделяне цяла множество копия на базата данни. И вие сте управлението на всичко, което при ниво на кандидатстване. Това не е забавно. И какво ще искате да отидете? Искаме да отидем DynamoDB, напълно управлявани, Магазин данни NoSQL, разпоредба производителност. Ние използваме вторични индекси. Това е основно HTTP API и включва поддръжка документ. Така че не е нужно да се притеснявате за всяка от които разделяне. Ние го направя всичко за вас. Така че сега, вместо това, можете Просто пишете на масата. Ако таблицата трябва да се разпределя, , което се случва зад кулисите. Вие сте напълно изолирани от които като разработчик. Така че нека да говорим за някои от случаите на употреба че ние се сблъскате в игрите, обща игрални сценарии, табло. Така че имаш потребители, идващи в, на BoardNames, че те са на, оценките за този потребител. Ние може да се хеширане на UserID, и след това ние имаме набор от играта. Така всеки потребител иска да види цялата игра той е играл и всичките му най-добър резултат във всички минута. Така че това е неговата лична класация. 

Сега искам да ида и аз искам да get-- така че да получите тези лични класации. Това, което искам да направя е да отида да получите горната оценка за всички потребители. Е, как да го правя? Когато моят рекорд е сегментира на на UserID, варира от играта, и аз ще отида напред и преструктуриране, създаване на GSI, и аз отивам да се преструктурират тези данни. 

Сега аз ще се разискват относно BoardName, който е в играта. И аз отивам да варира в горната оценка. И сега съм създал различни кофи. Аз съм с една и съща маса, същите данни позиция. Но аз съм създаване на кофа, която дава ми агрегиране на най-добър резултат от игра. 

И аз може да задава въпроси, които на маса за да получите тази информация. Така че аз съм избран този модел заявка до да бъдат подкрепени от вторичен индекс. Сега те могат да бъдат сортирани по BoardName и подредени TopScore, в зависимост от това. Така че можете да видите, това са видове от използваме случаи можете да получите в игрите. Друго добро използване случай получаваме в игрите е награди и кой печели наградите. И това е чудесен случай ползване когато ние наричаме оскъдни индекси. Разредени индекси са на способността да се генерират индекс, който не е задължително съдържа всеки един елемент на масата. И защо не? Тъй като атрибут, който се е индексирана не съществува за всяка единица. 

Така че в този конкретен използвате случай, аз казвам, Знаете ли какво, аз отивам да създадете атрибут наречен Award. И аз ще дам на всеки потребител че има награда, която приписват. Потребителите, които не разполагат с награди са няма да имат този атрибут. Така че, когато се създаде индекс, единствените потребители че ще се покаже нагоре в индекса са тези, които всъщност са спечелили награди. Така че това е един чудесен начин да бъде в състояние да се създаде филтрират индекси, които са много, много селективен, че не го правят Трябва да индексира цялата таблица. 

Така че ние получаваме ниско на време тук. Отивам да вървим напред и да пропуснете навън и да пропуснете този сценарий. Говори малко about-- 

АУДИТОРИЯ: Мога ли да задам един бърз въпрос? Едно е да напишете тежка? Рик Houlihan: Какво е? АУДИТОРИЯ: Напишете тежък. Рик Houlihan: Напишете тежък. Нека да видя. 

АУДИТОРИЯ: Или е, че не нещо, което може само Гласът в рамките на секунди? Рик Houlihan: Отиваме чрез сценария на гласуване. Това не е толкова лошо. Направете вие ​​имате няколко минути? ДОБРЕ. 

Така че ние ще говорим за гласуване. Така че реално време за гласуване, имаме изисквания за гласуване. Изискванията са, че ние позволяваме всеки човек да гласува само веднъж. Ние искаме никой да бъде в състояние да промени своя вот. Искаме агрегация в реално време и анализи за демографията че отиваме да бъде показване на потребителите на сайта. 

Помислете за този сценарий. Ние работим много реалност Телевизионни предавания, където те са прави тези точна тип неща. Така че можете да мислите за сценарий, имаме милиони и милиони на тийнейджърките там с мобилните си телефони и гласуване и гласуване, и Гласувам за този, който те са намирам за най-популярни. Така че това са едни от най- изисквания, ние се изчерпят. 

И така, първата вземе в решаването на този проблем, би било да се построи много проста молба. Така че аз имам това приложение. Имам някои гласоподаватели там. Те идват в, те удари приложението за гласуване. Имам някаква сурова гласа на маса Аз просто ще зареже тези гласове в. Ще има някои агрегат гласа таблица, която ще направя моите анализи и демографията, и ние ще сложи всичко това в там. 

И това е страхотно. Животът е добър. Животът е добра, докато не разберете, че винаги има само един или два хора, които са популярни в изборите. Има само едно или две неща, че хората наистина държите. А ако гласувам в мащаб, всички изведнъж съм Ще бъдат чукане по дяволите, от двама кандидати, един или двама кандидати. A много ограничен брой артикули хора, които намират за да бъде популярен. 

Това не е добър модел дизайн. Това всъщност е много лош дизайн модел тъй като създава точно това, което ние Говорихме за която беше горещи клавиши. Горещи клавиши са нещо, което не ни харесва. 

И как ще се оправя това? И наистина, на начина, по който да се определи това е като се вземат тези кандидатки кофи и за всеки кандидат, които имаме, отиваме да прикрепите случайна стойност, нещо, което ние знаем, случайна стойност между една и 100, между 100 и 1000, или между една и 1000, обаче много произволни стойности, които искате да добавете към края на този кандидат. 

И какво съм наистина направи тогава? Ако аз съм с помощта на ID кандидат кофата за обединяване на гласа, ако съм добавя случаен брой до края на тази, Аз създадох сега 10 кофи, а сто кофи, хиляда кофи че аз съм за струпване на гласове в цяла. 

Така че имам милиони, и милиони, и милиони записи, идващи в за тези кандидати, аз съм сега разпространение тези гласове в цяла A_1 кандидат чрез A_100 кандидат, защото всеки път, когато е гласувано идва, Аз съм генериране на случайни стойност между една и 100. Аз съм го лепнали върху края на кандидат на това лице Гласувам за. Аз съм го дъмпинг в тази кофа. 

Сега на гърба, аз знам, че аз имам сто кофи. Така че, когато аз искам да отида напред и агрегиране на гласовете, Четох от всички тези кофи. Така че аз отида напред и да добавите. И тогава аз скатерния събера където аз изляза и да кажа, хей, Знаете ли какво, ключова този кандидат пространства е над сто кофи. Отивам да се съберат всички гласува от тези стотина кофи. Отивам да се обобщи тях и аз отивам да се каже, Кандидат А сега има Общият брой на х гласуване. 

Сега и двете отписването запитване и заявка за четене са разпределена защото аз пиша цяла и аз съм четене през стотици ключове. Аз не пиша и четене цяла една ключова сега. Така че това е чудесен модел. 

Това всъщност е може би един от най-важните дизайн модели за мащаб в NoSQL. Вие ще видите на този тип шарка във всеки вкус. MongoDB, DynamoDB, това не е така материя, всички ние трябва да направим това. Защото, когато имаш работа с тези огромни съвкупности, ще трябва да се намери начин да се тях, разпределени по целия кофи. Така че това е начина, по който се прави това. Добре, и какво от това което правиш в момента е, което търгува на разстояние за четене разходи за обезценка мащабируемост. Цената на моето четене е малко по-сложна и аз трябва да отида чете от сто кофи вместо един. Но аз съм в състояние да пиша. И моята производителност, ми пиши пропускателна способност е невероятна. Така че това е обикновено ценна техника за мащабиране DynamoDB, или всяка база данни NoSQL за този въпрос. Така че сме измислили как да го мащаб. И сме измислили как да премахване на нашите горещи клавиши. И това е фантастично. И ние имаме тази хубава система. И това ни е дал много правилно гласуване защото имаме рекорден вот де-будала. Той е построен в DynamoDB. Ние говорихме за условни права. 

Когато един избирател идва, поставя вмъкване на масата, те вложка с техния избирател ID, ако се опитат да поставите друг глас, Аз правя условно запис. Кажете само пиша това ако това не съществува. Така че, след като се видя, че това гласуване падна тежко на масата, никой друг не ще бъде в състояние да сложи своя вот инча И това е фантастично. И ние сме увеличаване нашите кандидатки броячи. И ние правим всичко демография и всичко това. Но какво се случва, ако ми прилагане пада върху? Сега всичко изведнъж гласа са подадена, и аз не знам дали те сте се обработват в моите анализи и демография вече. И когато заявлението се връща, как по дяволите, да знам, че това, което имат гласове са преработени и къде да започнем? 

Така че това е истински проблем, когато започнете да погледнете този вид сценарий. И как можем да решим, че? Ние го решим с това, което ние обадете DynamoDB Streams. Потоци се подредени по време и разделя дневник промяна на всеки достъп на масата, всеки напиши достъп до таблицата. Всяка информация, която е написана на таблица показва на потока. 

Това е в основата на 24-часов режим на изчакване. Предмети хит на потока, те живеят в продължение на 24 часа. Те могат да се четат няколко пъти. Гарантирано да бъдат доставени само веднъж до потока, може да бъде прочетен п брой пъти. Така обаче много процеси искате да консумират, че данните, можете да го консумират. Тя ще се появи всеки ъпдейт. Всеки запис само ще се появяват веднъж на потока. Така че не е нужно да се притеснявате за това обработката на два пъти от същия процес. 

Това е строго осъжда всяка позиция. Когато казваме време осъжда и се разпределя, вие ще видите един дял на потока. Вие ще видите предмети, ъпдейти в ред. Ние не гарантираме на потока, който сте ще получи всяка транзакция в реда, в цяла предмети. 

Така че потоците са idempotent. Да ние всички знаем какво означава idempotent? Idempotent означава, че можете да го направите над, и отново, и отново. Резултатът ще е същият. 

Потоци са idempotent, но те трябва да бъдат играе от началната точка, където и да изберете, до края, или те няма да доведе в същите ценности. 

Същото е и с MongoDB. MongoDB има конструкция Викат oplog. Това е точно същата конструкция. Много NoSQL бази данни получите този конструкт. Те я ​​използват, за да правят неща като репликация, които е точно това, което правим с потоци. АУДИТОРИЯ: Може би еретично въпрос, но вие говорим за приложения правят определяне на така нататък. Потоци Гарантирани ли са, за да никога не е възможно да се понижат? Рик Houlihan: Да, потоци са гарантирани никога да не слизат. Ние управляваме инфраструктурата зад. потоци автоматично разположи в тяхната автоматично мащабиране група. Ще мине през малко малко за това, което се случва. 

Аз не трябва да се каже, че те не са гарантирана никога да не слизат. Елементите са гарантирани да се яви в потока. И потокът ще бъде достъпен. Така че това, което върви надолу, или се връща нагоре, което се случва отдолу. Тя covers-- това е ОК. Добре, така че да получите различен видове виждане извън екрана. Типовете виждане, които са важни за програмист обикновено са, какво е това? Получавам стария изглед. Когато актуализация хитове на масата, тя ще бутнете стария изглед към потока така че данните да архивирате или промяна контрол, идентификация на климата, промяна управление. 

Новият образ, това, което е сега, след актуализацията, това е друг тип оглед на можете да получите. Можете да получите и двете стари и нови изображения. Може би и двамата искаме. Искам да видя какво е това. Искам да видя какво е променено на. 

Имам тип спазване на процес, който тече. Необходимо е да се провери, че когато тези неща се променят, че те са в определени граници или в рамките на определени параметри. 

И тогава може би аз само Трябва да знаете какво се е променило. Не ме интересува какво позиция се промени. Аз не трябва да трябва да знаете което атрибути промени. Просто трябва да се знае, че изделията се докоснаха. Така че това са видовете видяна че слезете от потока и можете да си взаимодействат с. 

Приложението, което консумира потока, това е вид начина, по който работи. DynamoDB клиент поиска да тласък данни за таблиците. Потоци разположи върху това, което ние наричаме парчета. Късчета се мащабират независимо от масата. Те не се подредят напълно до съставните части на вашата маса. И причината, поради която е защото те се подредят на капацитета, на ток капацитет на масата. 

Те разполагане на тяхна собствена мащабиране група автоматично, и те започват да се върти в зависимост от това колко пише идват в, колко reads-- наистина това е пише. Няма по reads-- но как много пише идват инча 

И след това на гърба край, ние имаме това, което ние наричаме KCL или Kinesis Client Library. Kinesis е поток от данни технология на обработка от Amazon. И потоци е построен върху това. 

Така че можете да използвате KCL активирана приложението да чете потока. The Client Kinesis библиотека всъщност управлява работниците за вас. И това също прави някои интересни неща. Той ще създаде някои таблици нагоре във вашата DynamoDB таблици да следите кои елементи са били обработени. Така че по този начин, ако тя попада обратно, ако той попада отново и идва и получава застана обратно нагоре, тя може да се определи къде тя е в обработката на потока. 

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

Така че ние използваме това за напречно област репликация. Много от клиентите имат нужда да преместване на данни или части от своите таблици с данни около различните региони. Има девет региона навсякъде по света. Така че е възможно да има need-- I може да има потребители в Азия, потребители в източното крайбрежие на Съединените щати. Те имат различни данни, които трябва да бъде разпределена локално. И може би един потребител лети от Азия към Съединените щати, и аз искам да се възпроизвеждат данните му с него. Така че, когато той получава от самолета, той има добър опит в използването на мобилния си ап. 

Можете да използвате напречно региона репликация библиотека, за да направите това. По принцип ние имаме при условие две технологии. Едно е конзолно приложение можете изправи на собствения си EC2 инстанция. Тя работи чисто репликация. И тогава ние ви дадохме библиотеката. Библиотеката можете да използвате, за да се изгради Вашето собствено приложение, ако искам да правя луди неща с които data-- филтър, репликира само част от него, завъртите данните, той се премести в друга маса, така нататък и така нататък. Така че това е вид на това, което изглежда като че. 

DynamoDB Streams могат да бъдат обработват от това, което ние наричаме Lambda. Ние, споменати по-малко за събитие задвижвани архитектури на приложения. Lambda е ключов компонент от тази. Lambda е код, който се активира при поискване в отговор на определено събитие. Един от тези събития може да бъде запис се появява на потока. Ако рекорд появява на потока, ние ще се обадя на тази функция Java. Е, това е JavaScript, и Lambda подкрепя Node.js, Java, Python, и скоро ще подкрепи други езици, както добре. И достатъчно да се каже, че е чист код. напиши В Java, можете да зададете един клас. Можете да натиснете JAR нагоре в Lambda. И тогава ще се определи кои клас да се обадя в отговор на което събитие. И тогава инфраструктурата Lambda зад която ще тече този код. 

Това код може да обработва записи извън потока. Той може да направи нищо, че иска с него. В този конкретен пример, всички ние сме Наистина това е влезете атрибутите. Но това е само код. Code може да направи нищо, нали? 

Така че можете да се върти, че данните. Можете да създавате производни гледка. Ако това е структура, документ, можете да се изглади структурата. Можете да създадете алтернативни индекси. Всички видове неща, които могат да общо с DynamoDB потоци. 

И наистина, това е, което прилича на това. Така получавате тези актуализации, идващи инча Те идват от низа. Те се четат от функцията Lambda. Те са въртящи се на данни и натискането му в деривативни маси, уведомяване външни системи на климата, и бутане на данни в ElastiCache. 

Ние говорихме за това как да се сложи на кеш паметта в предната част на базата данни за продажби че сценарий. Ами какво ще стане, ако актуализира описанието на този артикул? Е, ако имах Lambda Функцията работи на същата таблица, ако аз актуализира описанието на позиция, тя ще вземете записа изключване на потока, и това ще актуализира ElastiCache Например с новите данни. Така че това е много какво ще правим с Lambda. Това е лепило код, съединители. И това всъщност дава способността да започне и да тичам много сложни приложения без специален сървър инфраструктура, което е наистина страхотно. 

Така че нека да се върнем към нашия в реално време архитектурата гласуване. Това е нова и подобрена с нашите потоци и KCL активирани приложения. Същото като преди, можем справи с всеки десетобалната система избори. Ние обичаме това. Ние правим от разсейване набори в няколко кофи. Имаме оптимистично заключване става. Ние можем да запазим нашите избиратели от промяна на гласа си. Те могат само да гласува само веднъж. Това е фантастично. Толерантността в реално време неизправност, мащабируема агрегация сега. Ако нещо падне, тя знае къде да се рестартира когато тя се връща, защото ние сме с помощта на KCL ап. И тогава можем да също да използват този KCL заявление да прокара данни от до червено отместване за друга ап анализи, или да използвате Еластичната MapReduce да работят в реално време стрийминг струпвания почивни на тези данни. 

Така че това са неща, които ние Не сме говорили за много. Но те са допълнително технологии, които идват да понесе, когато търсите при тези видове сценарии. 

Добре, така че става дума за анализи с DynamoDB Streams. Можете да събирате де-будала данни, направете всички видове на хубаво неща, обобщени данни в памет, създаване на тези деривативни маси. Това е един огромен ползване случай че много от клиентите са ангажирани с, като вложените свойства на тези JSON документи и създаване на допълнителни индекси. 

Ние сме в края. Благодаря ви за лагер с мен. Така че нека да говорим за референтна архитектура. DynamoDB седи в средата на така голяма част от инфраструктурата AWS. По принцип можете да го свържете до всичко, което искаш. Приложения, изградени с помощта на Dynamo включва Lambda, ElastiCache, CloudSearch, бутнете данните посочени в Elastic MapReduce, вноса и износа от DynamoDB в S3, всички видове работни потоци. Но може би най-добрия нещо, за да се говори за, и това е, което е наистина Интересно е, когато ние говорим за събития задвижва приложения. 

Това е пример на вътрешен проект че ние имаме, когато сме в действителност издателска дейност, за да се съберат резултатите от проучването. Така че в имейл линк, който ние изпращаме, ще има да е малко линк казвайки кликване тук, за да отговорят на проучването. И когато едно лице кликвания които сочат, какво се случва, е те събарят сигурна HTML форма проучване от S3. Няма по-сървър. Това е просто един S3 обект. 

В този формуляр идва, зарежда в браузъра. Тя има гръбнак. Той има сложна JavaScript че той се движи. Така че е много богат кандидатстване работи в браузъра на клиента. Те не знаят, че те не са взаимодействие с задния край на сървъра. В този момент, всичко е браузър. 

Те публикуват резултатите на това, което ние наричаме Amazon API Gateway. API Gateway е просто уеб API че можете да определите и кука до каквото си искате. В този конкретен случай, ние сме закачен към функция Lambda. 

Така че моят POST операция е случва, без сървър. По принцип, че API Gateway седи там. Това ми струва нищо, докато хората започнете да публикувате до него, нали? Функцията Lambda просто седи там. И това ми струва нищо, докато хората започват да го удря. Така че можете да видите, като обема се увеличава, това е, когато обвиненията идват. Аз не бягам сървъра 7.24. 

Така че аз извадя формата слиза от кофата, и аз публикувате чрез API Gateway в функцията Lambda. И тогава ламбда функция казва, нали знаеш какво, аз имам някои PIIs, някои лична информация в тези реакции. Имам забележки, идващи от потребители. Имам имейл адреси. Имам потребителски имена. 

Позволете ми да раздели това разстояние. Отивам да генерира някакъв метаданни извън този запис. И аз отивам да натиснете метаданни в DynamoDB. И аз може да криптира всички данни и го натиснете в DynamoDB ако искам. Но това е по-лесно за мен, в тази използвате случай, да се продължи напред с да речем, Отивам да прокара Суровите данни в криптиран S3 кофа. Така че аз ползване построена през сървъра страна S3 криптиране и Key Management на Amazon Service, така че имам ключ, който може да се върти на регулярна интервал, и мога да защитим тази PII данни като част от целия този процес. 

И така, какво съм направил? Току-що се разположи цяло приложение, и нямам сървър. Така че това, което е ориентирана към събития кандидатстване архитектура прави за вас. 

Сега, ако мислите, че за случай на използване за this-- имаме други клиенти говоря до около тази точна архитектура, които тичам феноменално големи кампании, които разглеждате тази и ще, о, боже. Защото сега, те могат По същество това бутнете там, нека тази кампания просто си седя там, докато не започва и не трябва да се притеснявате за смокиново какъв вид инфраструктура ще бъде там, за да го подкрепят. И след това, веднага след като тази кампания е направено, това е като инфраструктурата Просто веднага си отива защото там наистина е никаква инфраструктура. Това е просто код, който седи на Lambda. Това е просто информация, която седи в DynamoDB. Това е един удивителен начин за изграждане на приложения. 

АУДИТОРИЯ: Така че е по- ефимерна, отколкото би било ако тя се съхранява в условията на реален сървър? 

Рик Houlihan: Абсолютно. Защото този сървър например ще трябва да бъде 7.24. Тя трябва да бъде на разположение за някой да отговори. Е познайте какво? S3 е достъпно 24/7. S3 винаги реагира. И S3 е много, много добър при генерирането на обекти. Тези обекти могат да бъдат HTML файлове, или JavaScript файлове, или каквото си искате. Можете да пуснете много богати уеб приложения от S3 кофи, а хората правят. 

И така, това е идеята тук е да се махна от пътя сме свикнали да мислим за това. Ние всички свикнали да мислят в от гледна точка на сървъри и хостове. Това не е за това вече. Става дума за инфраструктура като код. Разполагане на кода към облака и нека облакът го изпълним за вас. И това е, което AWS се опитваме да направим. 

АУДИТОРИЯ: Значи златото си кутия в средата на API Gateway не е сървър-подобни, но вместо това е just-- 

Рик Houlihan: Можете да мислите то на сървъра като фасада. Всичко това е е, че ще вземе HTTP да поиска и да го карта на друг процес. Това е всичко, го прави. И в този случай, ние сме картографиране тя към функция Lambda. Добре, така че това е всичко, което имам. Благодаря ти много. Оценявам го. Знам, че ние искаме малко с течение на времето. И се надяваме, че вие, момчета дойдоха малко информация че можете да отнемат днес. И аз се извинявам, ако аз отидох над някои от главите си, но има добър много фундаментални знания основополагаща Мисля, че е много ценно за вас. Така че ви благодаря че ме поканихте. [Аплодисменти] АУДИТОРИЯ: [недоловим] е, когато казваха трябваше да мине през нещо от началото до края за да получите правилните стойности или едни и същи ценности, как ще стойностите промени, ако [недоловим]. 

Рик Houlihan: О, idempotent? Как ще се променят ценностите? Ами, защото, ако аз не тичам го по целия път до края, тогава аз не знам какви промени са направени в последната миля. Това няма да бъде най- същите данни, както това, което видях. АУДИТОРИЯ: О, така че просто не са придобили целия вход. Рик Houlihan: Точно така. Вие трябва да отидете от начало до края, а след това е Ще бъде последователна държавна. Готино. 

АУДИТОРИЯ: Значи ти ни показа DynamoDB може да направи документ или стойността на ключа. И ние прекарахме много време в ключова стойност с хашиш и начините да го обърнете наоколо. Когато погледна тези таблици, е, че оставяйки зад подхода на документ? 

Рик Houlihan: Не бих казват, че оставяйки след себе си. 

АУДИТОРИЯ: Те са били отделени от the-- 

Рик Houlihan: С документа подход, вида на документа в DynamoDB Просто мисля, че е на друг като атрибут. Това е атрибут, който съдържа йерархична структура на данните. И след това в заявките, можете да използвате свойствата на тези обекти, използващи Object Notation. Така че мога да филтрирате по вложено собственост на документа JSON. АУДИТОРИЯ: Така всяко време I направя подход документ, Мога да подреди на пристигат в tabular-- АУДИТОРИЯ: Абсолютно. Публика: --indexes и неща, които току-що говорихме. Рик Houlihan: Да, индекси и всичко, което, когато искате да индексът свойства на JSON, начинът, по който ние ще трябва да се направи това е, ако вмъквате JSON обект или документ в Динамо, трябва да използвате потоци. Потоци ще четат на входа. Вие ще получите, че JSON възрази и ще каже OK, това, което е собственост Искам да индекс? 

Вие създавате производни на маса. Сега това е начина, по който тя работи в момента. Ние не ви позволи да индексира пряко тези свойства. 

АУДИТОРИЯ: Tabularizing вашите документи. 

Рик Houlihan: Точно така, изправяне нея, тя tabularizing, точно. Това е това, което правите с него. 

АУДИТОРИЯ: Благодаря. 

Рик Houlihan: Да, Абсолютно, благодаря ви. АУДИТОРИЯ: Така че това е вид Монго отговаря REDIS classifers. 

Рик Houlihan: Да, това е много подобно. Това е добро описание за това. Готино.