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

Мій фон в першу чергу в шарі даних. Я провів половину своєї розробки Кар'єра писати базу даних, доступу до даних, рішення для різних застосувань. Я був у Cloud віртуалізації протягом приблизно 20 років. Тому, перш ніж хмара Хмара, ми звикли називати його корисність обчислень. А ідея була, це як PG & E, ви платите за те, що ви використовуєте. Сьогодні ми називаємо це хмара. 

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

Так в ці дні, я зупинюся в основному на NoSQL технології і нове покоління бази даних. І це, як правило те, що я збираюся щоб бути тут і розмовляю з вами сьогодні о. Так що ви можете очікувати від цієї сесії, ми підемо через коротенько Історія обробки даних. Це завжди корисно зрозуміти, звідки ми прийшли і чому ми, де ми знаходимося. І ми будемо говорити трохи Трохи про технології NoSQL з фундаментальної точки зору. 

Ми потрапимо в деяких нутрощі DynamoDB. DynamoDB НЕ AWS В не аромат. Це повністю керований і серверне рішення NoSQL. І ми будемо говорити трохи про таблиці структура, API, типи даних, індекси, і деякі з внутрішніх цієї DynamoDB технології. Ми увійдемо до деякі конструкції шаблони і кращі практики. Ми поговоримо про те, як використовувати цю технологію для деяких сучасних додатків. І тоді ми будемо говорити трохи про еволюцію або поява нової парадигми в програмуванні звані додатки керовані подіями і як DynamoDB грає в тому, що, як добре. І ми вийдемо вам трохи обговорення Еталонна архітектура таким чином, ми можемо говорити про деякі способи можна використовувати DynamoDB. 

Отже, спочатку off-- це питання Я чув багато є, що база даних. Багато людей думають, що вони знаю, що база даних. Якщо ви Google, ви побачите, що це. Це структурований набір даних, що зберігаються в комп'ютері, особливо той, який доступний в різних напрямках. Я вважаю, що це хороший визначення сучасної бази даних. Але я не люблю його, тому що це має на увазі кілька речей. Це означає, структуру. І це означає, що він перебуває на комп'ютері. І не зробив бази даних завжди існує на комп'ютерах. Бази даних дійсно існував у багатьох відношеннях. 

Таким чином, краще визначення База даних щось на зразок цього. База даних організований механізм зберігання, управління, та вилучення інформації. Це з About.com. Так що я хотів цього, тому що це дійсно переговори про базу даних будучи сховище, сховище Інформація, не обов'язково те, що сидить на комп'ютері. І протягом всієї історії, ми не завжди комп'ютерів. 

Тепер, якщо я прошу середньому Розробник сьогодні те, що база даних, ось і відповідь я отримую. Десь я можу дотримуватися речей. Вірно? І це правда. Але це сумно. Оскільки база даних дійсно основа сучасного додатки. Це основа з кожної програми. І, як ви будуєте, що бази даних, як структурувати що дані буде диктувати, як це Додаток виконує, як ви масштабі. 

Так багато моєї роботи сьогодні має справу з тим, що відбувається, коли розробники цей підхід і справу з наслідками додатку, який Тепер масштабування за оригінал Мета і страждання від поганого дизайну. Так, ми сподіваємося, коли вам ходьби сьогодні, ви будете є кілька інструментів, у Ваш пояс, який буде тримати вас від прийняття тих же помилок. Добре. Отже, давайте поговоримо про трохи терміни технології баз даних. Я думаю, що я прочитав стаття не так давно і він сказав, щось на lines-- це дуже поетично заяві. Це сказав, що історія даних обробка повний високих водяних знаків достатку даних. ДОБРЕ. Тепер, я думаю, що це свого роду правда. Але я насправді дивитися на це, як Історія насправді заповнені з високою водяний знак тиску даних. Оскільки швидкість передачі даних проковтування не йде вниз. Це тільки йде вгору. 

І інновації відбувається, коли ми бачимо тиск даних, який це кількість даних, які в даний час в надходить в систему. І це не може бути оброблений ефективно ні в часі, або у вартості. І ось, коли ми починаємо подивитися на тиск даних. 

Тому, коли ми дивимося на Перша база даних, це це той, який був між нашими вухами. Ми всі народжені з ним. Це хороша база. Він має високу доступність. Це завжди. Ви завжди можете отримати його. 

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

І це працювало добре протягом довгого часу коли ми були ще в день коли всі ми дійсно потрібно знати це куди ми йдемо, щоб піти на завтра або там, де ми збираємо кращу їжу. Але, як ми почали рости як цивілізація і уряд почав прийти в буття, і бізнес почав розвиватися, ми почали розуміти, ми потрібно трохи більше, ніж ми могли б в нашій голові. Все в порядку? 

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

І це насправді сталося в 1880 році. Вірно? У 1880 перепису населення США. Це дійсно, де поворот вказують сучасній обробці даних. Це точка, в яких обсяг даних що в даний час, зібраних Уряд США потрапив в точку, де потурбувалися вісім років, щоб обробити. 

Тепер, вісім years-- як Ви знаєте, перепису працює кожні 10 years-- так що це Цілком очевидно, що за часом ми отримав перепису 1890, кількість даних, які збирався бути оброблені урядом було збирається перевищувати 10 років, що це буде потрібно, щоб запустив нову перепису. Це було проблемою. 

Таким чином, хлопець на ім'я Герман Холлерит прийшли разом і він винайшов блок записи удар карти, читач перфокарти, перфокарти табулятор, і зіставлення механізми для цієї технології. І, що компанія, яка він сформував на Час, разом з парою інших, фактично став одним із стовпів невелика компанія, ми знаємо сьогодні називається IBM. 

Так IBM спочатку була в бізнес бази даних. І це дійсно те, що вони зробили. Вони зробили обробку даних. 

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

Це об'єднання. Ми робимо це все час сьогодні в комп'ютері, де ви його в базу даних. Ми використовували, щоб зробити це вручну, вірно? Люди ставлять ці речі разом. І це було поширення з цих перфокарт в те, що ми назвали барабанів даних і барабани даних, паперові стрічки. 

Обробка даних промисловості прийняли урок від гравців фортепіано. Гравець піаніно назад на поворот століття використовувати використовувати паперові барабани з пазами розповідати його, які клавіші, щоб грати. Так що технології був адаптований в кінцевому підсумку, щоб зберегти цифрові дані, тому що вони могли б поставити ці дані на ті папери стрічкових барабанів. 

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

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

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

І тривало близько 20 або 30 років до еволюції реляційної бази даних, яка коли світ вирішив, що ми в даний час потрібно мати сховище, перемагає розростання даних по файлу Системи, які ми побудували. Вірно? Занадто багато даних, розподілених в занадто багато місця, де-дублювання даних, і вартість зберігання був величезний. 

У 70-х, найдорожчий ресурс що комп'ютер був був зберігання. Процесор був розглядати як фіксовану вартість. Коли я купую коробку, процесор робить деяку роботу. Це збирається бути спінінг чи це насправді чи ні. Це дійсно понесених витрат. 

Але те, що коштувало мені як бізнес зберігання. Якщо у мене є, щоб купити більше дисків в наступному місяць, що це реальна вартість, що я платити. І зберігання коштує дорого. 

Тепер ми швидко вперед 40 років і у нас є інша проблема. Обчислювальних тепер найдорожчий ресурс. Зберігання дешево. Я маю на увазі, ми можемо піти куди-небудь на хмара, і ми можемо знайти найдешевший зберігання. Але те, що я не можу знайти дешевий обчислювальний. 

Так еволюції сьогодні технології, технології баз даних, дійсно зосереджені навколо розподілені бази даних які не страждають від і той же тип шкали Обмеження реляційних баз даних. Ми поговоримо трохи про що це насправді означає. 

Але одна з причин, і водій за this-- ми говорили про тиск даних. Тиск даних є те, який призводить інновацій. І якщо ви подивитеся на більш за останні п'ять років, це схема, які саме дані навантаження по загальній підприємства Схоже, в останні п'ять років. 

І загальне правило ці days-- якщо ви йдете Google-- 90% від даних, які ми зберігаємо сьогодні, і це було генерується протягом останніх двох років. ДОБРЕ. Тепер, це не тенденція, що нового. Це тенденція, яка була виходячи за 100 років. З тих пір, Холлерит розробила перфокарти, ми будували сховища даних і збір даних на феноменальні темпи. 

Так, за останні 100 років, ми бачили цю тенденцію. Це не збирається змінювати. Просуваючись вперед, ми будемо бачити це, якщо не прискорюється тенденція. І ви можете бачити, як це виглядає. 

Якщо бізнес в 2010 році був один терабайт даних під керуванням, сьогодні це означає, що вони управління 6,5 петабайт даних. Це +6500 разів більше даних. І я знаю, що це. Я працюю з цими підприємствами щодня. П'ять років тому я буде говорити з компаніями хто б поговорити зі мною про що біль це управляти терабайтами даних. І вони будуть говорити мені про те, як ми бачимо, що це, ймовірно, буде бути петабайт або два протягом декількох років. 

Ці ж компанії сьогодні я зустрічаюся з, і вони кажуть мені про Проблема чи є що має управління десятки, 20 петабайт даних. Так вибух Дані в промисловості веде величезна потреба в більш досконалих рішень. І реляційна база даних є просто не жити до попиту. 

І так є лінійний Кореляція між тиском даних і технічні інновації. Історія показує нам, це, що з плином часу, всякий раз, коли обсяг даних який повинен бути оброблений перевищує пропускну здатність системи обробити його в розумні терміни або за розумною ціною, то нові технології винайдені, щоб вирішити ці проблеми. Ці нові технології, у свою чергу, відкрити двері на інший набір проблем, який збирає ще більше даних. 

Тепер, ми не збираємося зупинятися на цьому. Вірно? Ми не збираємося зупинятися на цьому. Чому? Тому що ви не можете знати все що потрібно знати у Всесвіті. І до тих пір, як ми були живі, протягом всієї історії людини, ми завжди змушені знати більше. 

Так здається, що кожен дюйм ми рухаємося по шляху наукового відкриття, ми множення кількості даних що ми повинні опрацювати по експоненті як ми розкрити більше і більше і більше про внутрішні життя, про те, як працює Всесвіт, про водіння наукове відкриття, і винахід, що ми робимо сьогодні. Обсяг даних, просто постійно збільшується. Так будучи в змозі мати справу з Ця проблема величезна. 

Так одна з речей, ми дивимося, як, чому NoSQL? Як NoSQL вирішити цю проблему? Ну, реляційні бази даних, Мова Структурованих Запитів, SQL--, що це дійсно конструкція з реляційна database-- ці речі оптимізована для зберігання. 

Назад в 70-і роки, знову ж таки, Диск коштує дорого. Про підготовку вправи зберігання на підприємстві ніколи не закінчується. Я знаю. Я жив його. Я написав драйвер сховища для enterprised суперсервера компанія назад в дев'яностих. І нижня лінія стелажі інший Масив зберігання даних була тільки те, що відбулося кожен день на підприємстві. І це ніколи не зупинився. Вища зберігання щільність, попит за великої щільності зберігання, і для більш ефективного зберігання devices-- це ніколи не зупинився. 

І NoSQL це відмінний технологія тому що він нормалізує дані. Це де-дублює дані. Це поміщає дані в структуру, яка агностик кожному модель доступу. Кілька додатків можуть вдарити, що Бази даних SQL, запустити спеціальні запити, і отримати дані у формі, що вони потрібно обробити для їх робочих навантажень. Це звучить фантастично. Але суть в тому, з якою-небудь Система, якщо це агностик, щоб усі, він оптимізований для нічого. ДОБРЕ? 

І це те, що ми отримуємо з реляційна база даних. Він оптимізований для зберігання. Це нормалізується. Це реляційна. Він підтримує спеціальні запити. І його і масштабує його по вертикалі. 

Якщо мені потрібно, щоб отримати велику базу даних SQL або більш потужний SQL бази даних, Я йду купити більший шматок заліза. ДОБРЕ? Я працював з багатьма клієнтів що пройшли через великі поновлення в їх SQL інфраструктури тільки щоб з'ясувати, шість місяців потому, вони знову ви удару в стіну. І відповідь від Oracle або MSSQL або хто-небудь ще, це отримати більше вікно. Ну, рано чи пізно, ви не можете купити більше вікно, і це реальна проблема. Ми повинні насправді щось змінити. То де ж це працює? Він добре працює в автономному аналітика, навантаження OLAP-типу. І це дійсно, де SQL належить. Тепер, він використовується сьогодні в багатьох онлайн обробку транзакцій типу додатки. І це прекрасно працює на певний рівень утилізації, але це просто не масштабувати так, що NoSQL робить. І ми будемо говорити трохи трохи про те, чому, що є. 

Тепер, NoSQL, з іншого боку, більш оптимізований для обчислень. ДОБРЕ? Це не незалежним від шаблон доступу. Це те, що ми називаємо де-нормалізується структура або ієрархічну структуру. Дані в реляційній базі даних об'єдналися з декількома столами виробляти вигляд, що вам потрібно. Дані в базі даних NoSQL в зберігається в документі, який містить ієрархічну структуру. Всі дані, які зазвичай об'єдналися, щоб зробити цю точку зору зберігаються в одному документі. І ми будемо говорити трохи про як це працює в парі графіків. 

Але ідея тут в тому, що ви зберігаєте Ваші дані як ці екземпляри виглядом. ДОБРЕ? Ви масштабувати по горизонталі. Вірно? Якщо мені потрібно збільшити Розмір мого NoSQL кластера, Мені не потрібно, щоб отримати велику коробку. Я отримую ще одну коробку. І я їх разом кластер, і я можу Шарда ці дані. Ми поговоримо трохи про те, що Sharding є, бути можливість масштабування цю базу даних по кільком фізичним пристроям і видалити бар'єр, вимагає, щоб я масштабування по вертикалі. 

Так що насправді побудований для онлайн обробки транзакцій і масштаб. Там велика різниця тут між звітності, вірно? Звітність, я не знаю, питання, які я збираюся поставити. Вірно? Reporting-- якщо хтось із мій відділ маркетингу хоче просто-- скільки з моїх клієнтів Тобто ця конкретна характеристика, хто купив в цьому day-- я не знаю те, що запит вони збираються запитати. Тому мені потрібно, щоб бути агностиком. 

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

Отже, ми збираємося, щоб потрапити в трохи теорії тут. І деякі з вас, ваші очі може повернутися небагато. Але я постараюся, щоб зберегти його також високий рівень, як я можу. Так що, якщо ви перебуваєте в проекті Управління, є конструкція називається трикутник обмежень. ДОБРЕ. Трикутник обмежує диктату Ви не можете мати все весь час. Не можете мати свій пиріг і з'їсти його занадто. Таким чином, в управлінні проектами, що трикутник обмеження, що ви можете мати це дешево, Ви можете мати це швидко, або ви можете мати його добре. Виберіть два. Тому що ви не можете мати всі три. Вірно? ДОБРЕ. 

Таким чином, ви чуєте про це багато. Це потрійний обмеження, трикутник потрійний обмеження, або залізний трикутник є oftentimes-- коли ви говорите з менеджерами проекту, вони будуть говорити про це. Тепер, бази даних мають самостійно залізний трикутник. І залізний трикутник даних це те, що ми називаємо Теорема CAP. ДОБРЕ? 

Теорема CAP диктує як бази даних працюють під дуже специфічних умовах. І ми будемо говорити про що ця умова. Але три точки трикутника, так би мовити, є С, консистенція. ДОБРЕ? Таким чином, в САР, узгодженість означає, що всі клієнти, які можуть отримати доступ до бази даних завжди буде мати дуже відповідає уявлення даних. Ніхто не збирається побачити дві різні речі. ДОБРЕ? Якщо я бачу, бази даних, Я бачу те ж саме уявлення як мій партнер, який бачить ту ж базу даних. Ось послідовність. 

Наявність означає, що якщо онлайн бази даних, якщо це може бути досягнуто, що всі клієнти будуть завжди вміти читати і писати. ДОБРЕ? Так кожен клієнт, який може читати базу даних завжди зможуть читання Дані даних і писати. І якщо це так, це доступний система. 

І третій пункт, що ми називаємо терпимості розділів. ДОБРЕ? Означає терпимість розділ що система працює добре незважаючи фізичної мережі Перегородки між вузлами. ДОБРЕ? Так вузли в кластері не може говорити один з одним, що відбувається? Добре. 

Так реляційні бази даних, виберіте-- Ви можете вибрати два з них. ДОБРЕ. Так реляційні бази даних виберіть бути послідовним і доступні. Якщо розділ відбувається між у вузли DataNode в сховище даних, збій бази даних. Вірно? Це просто йде вниз. ДОБРЕ. 

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

І це те, що роблять бази даних NoSQL. Добре. Таким чином, база даних NoSQL, його поставляється в двох варіантах. Ми have-- добре, це приходить в багатьох різновидах, але він приходить з двома основними characteristics-- що ми називаємо CP бази даних або послідовною і розділ толерантності Система. Ці хлопці роблять вибір, що, коли вузли втрачають контакт один з одним, ми не збираємося, щоб дозволити люди більше писати. ДОБРЕ? 

До цього розділу не будуть видалені, записи доступ заблокований. Це означає, що вони не доступні. Вони послідовні. Коли ми бачимо, що розділ додати собі, ми тепер відповідає, тому що ми не збираємося щоб зміни даних на два боку перегородок самостійно один від одного. Ми повинні відновити зв'язок перед будь-яким оновленням дані дозволили. ДОБРЕ? 

Наступного аромат буде система А.П., або доступний і розподіляють Система допуску. Ці хлопці не хвилює. Вірно? Будь вузол, який отримує писати, ми візьмемо його. Так що я тиражування мої дані по декільком вузлам. Ці вузли отримати клієнт, клієнт приходить в, каже, що я збираюся написати деякі дані. Вузол не говорить, не проблема. Вузол поруч з ним отримує від запису на тій же записи, він збирається сказати не проблема. Десь на задньому кінці, що дані збирається повторити. А потім хтось збирається реалізувати, е-е-о, вони зрозуміють, система, е-е-о, там було оновлення до двох сторін. Що ми робимо? І те, що вони зробити, це вони роблять те, що дозволяє їм вирішити цю стан даних. І ми будемо говорити про що наступного графіку. 

Річ, щоб відзначити тут. І я не збираюся занадто багато в цьому, тому що це потрапляє в глибокій теорії даних. Але є транзакцій рамки, працює в реляційної системі, дозволяє мені сміливо зробити поновлення кільком суб'єктам в базі даних. І ці оновлення будуть відбуватися все відразу або не на всіх. І це називається ACID транзакцій. ДОБРЕ? 

КИСЛОТА дає нам атомарность, узгодженість, ізоляція і довговічність. ДОБРЕ? Це означає, що атомні, угоди, все мої поновлення небудь трапиться, або ні. Узгодженість означає, що База даних буде завжди бути приведені в послідовній стан після оновлення. Я ніколи не залишить базу даних в поганий стан після застосування оновлення. ДОБРЕ? 

Так що це трохи відрізняється ніж консистенції CAP. Консистенція CAP означає, що всі мої клієнти завжди можуть бачити дані. КИСЛОТА узгодженість означає, що, коли угода буде зроблено, дані добре. Мої стосунки все добре. Я не збираюся, щоб видалити батьківську рядок і залишити купу дітей-сиріт У якийсь іншої таблиці. Це не може статися, якщо я узгоджуються в кислому операції. 

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

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

Міцність досить проста. Коли угода зізнається, що це буде там, навіть якщо збій системи. При тому, що система відновлюється, що угода, було скоєно насправді відбувається, щоб бути там. Так от гарантії кислоти угод. Ті, досить хороші гарантії мати в базі даних, але вони приходять на тій вартості. Вірно? 

Тому що проблеми з цим база якщо існує розбиття даних в набір, я повинен прийняти рішення. Я збираюся мати, щоб Оновлення на однієї чи іншої сторони. І якщо це станеться, не те я не збираюся більше щоб бути в змозі підтримувати ці характеристики. Вони не будуть відповідати. Вони не будуть ізольовані. Це де це ламає для реляційних баз даних. Це причина, реляційна Бази даних масштабування по вертикалі. 

З іншого боку, ми маємо те, що називається технологічна база. І це ваші NoSQL баз даних. Добре. Таким чином, ми маємо CP, бази даних AP. І це те, що ви називаєте основному доступні, м'який держава, в кінцевому рахунку, послідовним. ДОБРЕ? 

В основному доступні, тому що вони розділ терпимо. Вони завжди будуть там, навіть якщо є поділу мережі між вузлами. Якщо я можу поговорити з вузлом, я буде в змозі прочитати дані. ДОБРЕ? Я не завжди може бути в змозі написати даних, якщо я єдиної платформи. Але я буду в змозі прочитати дані. 

М'яка стан вказує що, коли я прочитав, що дані, вона не може бути такою ж, як інші вузли. Якщо право було видано на вузлі десь в кластері і це не реплицируются поперек Кластер же, коли я прочитав, що дані, що держава не може бути послідовним. Тим не менш, він буде зрештою послідовним, Це означає, що, коли записи зроблений до системи, він буде реплікувати вузлів. І врешті-решт, що держава будуть приведені в порядок, і це буде відповідати стан. 

Тепер, теорема CAP дійсно грає тільки в одному стані. Ця умова, коли це станеться. Тому що кожного разу, коли він працює в нормальний режим, немає розділу, все в послідовній і доступні. Ви тільки турбуватися про CAP коли у нас є цей розділ. Так що ті, рідкісні. Але, як система реагує, коли ті відбуваються диктувати, який тип системи ми маємо справу з. 

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

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

Так що тепер у мене є два стани. ДОБРЕ? Що станеться рано чи пізно, там буде подія реплікації. Там буде те, що ми називається розділ відновлення, який де ці два держави повернутися разом і там буде алгоритм який працює в базі даних, вирішує, що робити. ДОБРЕ? За замовчуванням, останнє оновлення виграє в більшості систем AP. Так що, як правило, Алгоритм за замовчуванням, те, що вони називають функцію зворотного виклику Функція, те, що буде викликатися, коли ця умова виявлено виконати деяку логіку вирішити, що конфлікту. ДОБРЕ? Зворотний виклик за замовчуванням і за замовчуванням распознаватель в більшості баз даних AP це, думаю, що, мітка виграє. Це було останнє оновлення. Я збираюся поставити це оновлення там. Я можу скинути цей запис, що я скидали геть в журналі відновлення так що користувач може повернутися пізніше і сказати, агов, сталося зіткнення. Що сталося? І ви можете скинути запис всі зіткнення і відкати і подивитися, що відбувається. 

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

Отже, давайте трохи поговоримо трохи про моделях доступу. Коли ми говоримо про NoSQL, це все про моделі доступу. Тепер, в SQL є спеціальна запити. Це реляционное сховище. Ми не повинні хвилюватися про модель доступу. Я пишу дуже складний запит. Це йде і отримує дані. Це те, що це виглядає як нормалізація. 

Таким чином, в даному конкретному структури, ми дивимося на каталог продукції. У мене є різні види продукції. У мене є книги. Я є альбоми. У мене є відео. Відносини між продуктами і будь-який з цих книг, альбомів, і відео столи 1: 1. Все в порядку? Я отримав код продукту, і що відповідає ID в книзі, альбом або відео. ДОБРЕ? Це відношення 1: 1 по цих таблиць. 

Тепер, всі вони books-- Тобто, корінь властивості. Без проблем. Це чудово. Один-до-одного відносини, я все дані мені потрібно, щоб описати цю книгу. Albums-- альбоми треки. Це те, що ми називаємо один до багатьох. Кожен альбом може мати багато доріжок. Таким чином, для кожного треку на альбом, я міг би ще один рекорд в цій дочірній таблиці. Так що я створити одну запис в мої альбоми таблиці. Я створюю кілька записів в таблиці треків. Один-до-багатьох. 

Це співвідношення є те, що ми називаємо багато-до-багатьох. ДОБРЕ? Ви бачите, що актори могли бути в багатьох фільмах, багато відео. Так що ми робимо, ми ставимо це відображення Таблиця між тими, які він просто відображає актор ідентифікатор відео ID. Тепер я можу створити запит до з'єднує відео через актора відео на акторів, і це дає мені хороший список всі фільми і всі актори які були в цьому фільмі. 

ДОБРЕ. Так от ми йдемо. Один-до-одного це топ-рівень відносини; один-до-багатьох, альбоми для доріжок; багато-до-багатьох. Такі три верхнього рівня відносини в будь-якій базі даних. Якщо ви знаєте, як ті, відносини працювати разом, то ви знаєте, багато про базу даних вже. Так NoSQL працює трохи по-іншому. Давайте думати про на секунду, що це Схоже, піти отримати всі мої продукти. 

У реляційній магазині, я хочу, щоб отримати всі мої продукти в списку всіх моїх продуктах. Це багато запитів. Я отримав запит для всіх моїх книг. Я отримав запит від моїх альбомів. І я отримав запит для всіх моїх відео. І я отримав поставити його всі разом в списку і служити його назад до додатку, який запитує його. 

Щоб отримати мої книги, я приєднуюся Продукти і книг. Щоб отримати мої альбоми, мене приєднатися Продукти, Альбоми, і треки. І щоб мої відео, у мене є приєднатися до відео продукти, приєднатися через Актор відео, і принести в Актори. Так ось три запиту. Дуже складні запити до зібрати один результуючий набір. 

Це менше, ніж оптимальна. Ось чому, коли ми говоримо про структуру даних, що це побудований, щоб бути незалежним від доступу pattern-- добре, що це здорово. І ви можете бачити це насправді приємно, як ми організували дані. І ви знаєте, що? У мене є тільки один запис для актора. 

Круто. Я дедупліціровани всі мої актори, і я підтримував мої асоціації У цій таблиці відображення. Однак, отримання даних поза стає дорожче. Я посилаю процесор всій системі з'єднує ці структури даних разом щоб бути в змозі здійснити це назад даних. 

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

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

Таким чином, застосування tier-- я просто виділіть всі ці записи. Вони всі починають. Вони можуть бути всі різні типи. І це логіка додатки який переключається між цими типами і вирішує, як їх обробити. 

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

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

Я можу мати зовсім різні властивості в кожному документі що я вставити в колекції. Отже, дуже потужний механізм. І це дійсно, як ви оптимізації системи. Тому що тепер замість запиту, приєднання всі ці таблиці і виконання півдюжини запитів відступити дані мені потрібно, Я виконанні одного запиту. І я ітерації за результатами встановлених. це дає вам уявлення про силу NoSQL. Я збираюся роду вийти боком тут і трохи поговоримо про це. Це більше, вид з маркетинг або technology-- маркетинг технології тип дискусії. Але важливо розуміти, тому що, якщо ми подивимося на вершині тут, на цьому графіку, те, що ми дивимося на це те, що ми називаємо Технологія обману кривої. І те, що це означає, Новий матеріал вступає в гру. Люди думають, що це здорово. Я вирішив всі мої проблеми. 

Це може бути кінець все, все буде все. І вони починають використовувати його. І кажуть вони, цей матеріал не працює. Це не правильно. Стара матеріал був краще. І вони повертаються до виконання речі, як вони були. І тоді в кінцевому рахунку вони йдуть, ви знаєте, що? Цей матеріал не так уже й погано. О, як це працює. І як тільки вони з'ясувати, як це Роботи, вони починають все краще. 

І найсмішніше про це Тобто, вид ліній до того, що ми називаємо кривої прийняття технології. Так що ж відбувається у нас є свого роду технологія запуску. У разі баз даних, цей тиск даних. Ми говорили про найвищих точок води тиску даних протягом часу. При тому, що тиск дані парад певна справа, що це технологія запуску. 

Це стає занадто дорого. Це займає надто багато часу, щоб обробити дані. Ми повинні щось краще. Ви новаторів там бігають, намагаючись з'ясувати, що це рішення. Що нова ідея? 

Що наступна краща спосіб зробити це? І вони приходять з чимось. І люди з реальною болю, хлопці на передньому краї, вони буду стрибати над ним, тому що вони повинні відповісти. Тепер те, що неминуче і happens-- це відбувається зараз в NoSQL. Я бачу весь цей час. 

Що неминуче відбувається люди починають використовувати новий інструмент так само, як вони використовували старий інструмент. І вони це з'ясувати не працює так добре. Я не можу згадати, хто я говорити з раніше сьогодні. Але це, як, коли відбійний молоток був винайдений, люди не качати його на їхні голови, щоб розбити бетон. 

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

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

Вони зробили те ж саме, коли реляційні бази даних були винайдені, і вони були заміни файлових систем. Вони намагалися побудувати файлових систем з реляційними базами даних тому що це те, що люди зрозуміли. Це не працює. Таким чином, розуміння кращі практики технології ви працюєте з величезний. Дуже важливо. 

Отже, ми збираємося, щоб потрапити в DynamoDB. DynamoDB є AWS-х повністю керованого платформу NoSQL. Що повністю керованого на увазі? Це означає, що ви не повинні дійсно ні про що турбуватися. 

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

Тому що, коли ви говорите про масштабування бази даних, Кластери даних NoSQL в масштаб, ходові петабайт, працює мільйони транзакцій в секунду, ці речі не малі кластери. Ми говоримо тисячі примірників. Управління тисячі примірників, навіть віртуальні екземпляри, це реальна біль в дупі. Я маю на увазі, думати про кожен раз Операційна система виходить патч або нової версії бази даних. Що це означає Вам оперативно? Це означає, що ви отримали 1 200 сервери, які повинні бути оновлені. Тепер навіть з автоматизацією, що може зайняти тривалий час. Це може викликати багато оперативні головні болі, тому що я, можливо, послуги вниз. 

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

Масштаб по горизонталі. Якщо ви хочете, щоб отримати більшу NoSQL бази даних, ви купуєте більше вузлів. Кожен вузол ви купуєте інший операційний головний біль. Отже, давайте хтось зробить це за вас. AWS може це зробити. 

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

Це швидко, і це відповідає в будь-якому масштабі. Таким чином, це є одним з найбільших бонуси ви отримуєте з AWS. З DynamoDB є здатність щоб отримати низьку одну цифру Затримка мілісекунду в будь-якому масштабі. Це було метою дизайну системи. І у нас є клієнти, які роблять мільйони транзакцій в секунду. 

Тепер я піду через деякі з тих, випадки використання протягом декількох хвилин тут. Вбудований control-- доступ ми маємо те, що ми називаємо Ідентичність Управління доступом, або IAM. Вона пронизує всі системи, кожен сервіс, який пропонує AWS. DynamoDB не є винятком. Ви можете контролювати доступ до таблиць DynamoDB. Через всі ваші AWS становить від визначення ролі і дозволу доступу в IAM інфраструктури. 

І це ключовий і невід'ємною складовою що ми називаємо Event Driven програмування. Тепер це нова парадигма. 

АУДИТОРІЯ: Як ваша швидкість вірно Позитивних проти помилкових негативів на системи контролю доступу? РВК Хуліхеном: True спрацьовувань в порівнянні з псевдонегативних? АУДИТОРІЯ: Повертаючись що Ви повинні повертатися? На відміну від раз в той час він чи не повернутися, коли він повинен перевірити? 

РВК Хуліхеном: Я не міг сказати вам, що. Якщо є які-небудь збої б то не було, що, Я не та людина, щоб запитати що конкретне питання. Але це хороше запитання. Я б цікаво дізнатися, що я, насправді. 

І так, знову ж таки, нова парадигма це подієва програмування. Це ідея, що ви можете розгорнути складних додатків, які може працювати дуже, дуже високий масштаб без інфраструктури б то не було. Без жорсткого Інфраструктура б то не було. І ми будемо говорити трохи про те, що це означає, що, як ми отримати на наступної пари карт. 

Перше, що ми зробимо що ми будемо говорити про таблицях. Типи даних API для Динамо. І перше, що ви будете помітив, коли ви дивитеся на це, якщо ви знайомі з будь-якою базою даних, Бази даних дійсно два види інтерфейсів Я б назвав це. Або два комплекти API. Один з тих, буде API управління. 

Речі, які вони приймають на себе функції бази даних. Налаштування механізму зберігання, створення і додавання таблиць. створення бази даних каталоги і приклади. Вони things-- в DynamoDB, ви мають дуже короткі, короткі списки. 

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

Ви отримуєте Create Table Update, Настільний, Видалити таблицю і описати таблицю. Це єдині речі, що потрібно для DynamoDB. Вам не потрібно сховище конфігурація двигуна. Мені не потрібно турбуватися про реплікації. Мені не потрібно турбуватися про шардінге. 

Я не потрібно турбуватися про будь-якому з цього матеріалу. Ми робимо все це для вас. Так що це величезна кількість накладних витрат що просто підняв свій пластину. Тоді у нас є оператори CRUD. CRUD-те, що ми зателефонуйте в базі даних, що це Створення, оновлення, видалення операторів. Це ваш загальний операції з базами даних. Такі речі, як покласти деталь, отримуєте деталь, оновлення предмети, видаляти елементи, партія запитів, сканування. Якщо ви хочете, щоб сканувати всю таблицю. Потягніть все зі столу. Одна з приємних речей про DynamoDB це дозволяє паралельне сканування. Так що ви можете насправді, дайте мені знати, скільки теми ви хочете, щоб працювати на цій сканування. І ми можемо запустити ці теми. Ми можемо спина, що сканувати до по декількох потокам так що ви можете сканувати всю таблицю простір дуже, дуже швидко в DynamoDB. 

Інший API ми маємо те, що ми називаємо нашим Потоки API. Ми не збираємося говорити занадто багато про це прямо зараз. Я отримав деякий зміст пізніше на палубі в про це. Але Потоки дійсно running-- думаю про нього, як наказав раз і зміна розділів журналу. Все, що відбувається на таблиця показує вгору в потоці. 

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

Типи даних. У DynamoDB, ми підтримуємо обидва ключі значення і документ типи даних. На лівій стороні екрану тут, ми отримали наші основні типи. Основні типи значень. Ці рядки, цифри і виконувані файли. 

Так всього за три основні типи. І тоді ви можете мати набори з них. Одна з приємних речей про NoSQL це Ви можете містити масиви в якості властивостей. І з DynamoDB можна утримувати масиви основних типів, як кореневої власності. 

А тут ще типи документів. Скільки людей знайомі з JSON? Ви, хлопці, знайомі з JSON так багато? Це в основному JavaScript, Об'єкт, Позначення. Це дозволяє в основному визначають ієрархічну структуру. 

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

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

DynamoDB має те, що ми називаємо хеш-ключ. Хеш ключ повинен бути унікальним. Тому, коли я визначити хеш-таблицю, в основному те, що я кажу, є кожен елемент матиме хеш-ключ. І кожен хеш-ключ повинен бути унікальним. 

Кожен елемент визначається цієї унікальної хеш-ключа. А може бути тільки один. Це нормально, але часто що потрібно людям вони хочуть це хеш Ключ до робити трохи більше ніж просто бути унікальним ідентифікатором. Часто ми хочемо, щоб використовувати цю хеш-ключ в якості верхнього рівня агрегації відро. І те, як ми робимо, що є додавши, що ми називаємо ключ діапазону. 

Так що, якщо це тільки хеш- стіл, це повинно бути унікальним. Якщо це хеш і діапазон стіл, Поєднання хеша і діапазону повинно бути унікальним. Так що подумайте про це таким чином. Якщо у мене є форум. І форма має теми, він має посади, і вона має відповідей. 

Так що я, можливо, хеш ключ, який є темою ID. І я міг би мати ключ діапазон, який є відповіддю ID. Таким чином, якщо я хочу, щоб всі відповіді для конкретній темі, Я можу тільки запит хеш. Я можу тільки сказати, мені все дають предмети, що мають цей хеш. І я йду, щоб отримати кожне питання або розмістити на цій конкретній темі. Ці головні скупчення рівня дуже важливі. Вони підтримують основний доступ Характер застосування. Взагалі кажучи, це це те, що ми хочемо зробити. Ми хочемо, щоб table-- як ви завантажити таблицю, ми хочемо, щоб структурувати дані в таблиці таким чином, що додаток може дуже швидко отримати ці результати. І часто спосіб зробити це для підтримки цих агрегатів, як ми вставити дані. У принципі, ми поширення даних у світле відро, як це відбувається в. 

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

Майже все, що ви робите в База даних якийсь агрегації. Так будучи в змозі бути в змозі визначити ці відра і дати вам ці асортимент атрибути, щоб мати можливість запитувати на, ці багаті запити підтримки багатьох багато, багато моделей доступу до додатка. 

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

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

Якщо я роблю це поступово, 1, 2, 3. І в мене є вибір, що хеш працює в даному конкретному випадку, невеликий простір хеш, він працює від 00 до FF, то записи будуть приходити в і вони збираються йти 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. Що сталося? Кожен вкладиш йде в тому ж вузлі. Ви бачите, що я маю на увазі? 

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

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

АУДИТОРІЯ: Це A9 169 в десятковій? 

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

У MongoDB ви можете вказати Чи хеш його чи ні. Вони просто дають вам можливість. Якщо ви знаєте, що це не випадкова, не проблема. Вам не потрібно цього робити. Якщо ви знаєте, що це не випадково, що це прирощення, а потім зробити хеш. 

Тепер справа про хешування, коли ви хеш value-- і це чому хеш-ключі завжди унікальні запити, тому що я змінилася значення, в даний час я не можу зробити діапазон запитів. Я не можу сказати, це між тим чи іншим, бо хеш-значення НЕ БУДЕ бути еквівалентна реальної вартості. Отже, коли ви хеш, що Ключ, це тільки рівність. Ось чому в DynamoDB хеш-ключа запити завжди тільки рівність. 

Так що тепер в діапазоні key-- коли я додати, що ключовою діапазон, ті ключові записи діапазон всі приходять і вони отримують зберігається в тому ж розділі. Таким чином, вони дуже швидко, легко витягується, тому що це хеш, це діапазон. І ви бачите, все з тією ж хеш отримує зберігається на тому ж просторі розділів. Ви можете використовувати цей ключ, щоб допомогти діапазон знайти ваші дані близькі до свого батька. Так що я насправді тут робиш? Це один до багатьох відносин. Відносини між ключем хеш і ключ діапазон один до багатьох. Я можу мати кілька ключів хеш. Я можу тільки мати кілька вибір ключі всередині кожного ключа хеша. 

Хеш визначає батька, діапазон визначає дітей. Таким чином, ви можете бачити, що це аналог тут між реляційної конструкції і ті ж типи будує в NoSQL. Люди говорять про NoSQL, як нереляціоннимі. Це не нереляціоннимі. Дані завжди відносини. Ці відносини просто моделюються по-різному. Давайте трохи поговоримо Трохи про довговічність. Коли ви пишете в DynamoDB, пише завжди тристороння відтворені. Це означає, що у нас є три AZ років. Я є доступність зон. Ви можете думати про доступність Зона в центрі обробки даних або сукупність центрів обробки даних. Ці речі географічно ізольовані один від одного різних зон розломів, по відрізняється електричні мережі та заплави. Відмова в одному AZ НЕ збирається зняти ще один. Вони також пов'язані разом з темно-волокна. Він підтримує один суб 1 Затримка мілісекунду між АЗС. Так реплікацій даних в режимі реального часу здатні в декількох АЗС. 

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

Якщо я тиражування по три, і я читаю з двох, Я завжди гарантується мати принаймні один тих зчитує бути Актуальна копія даних. Це те, що робить DynamoDB послідовним. Тепер ви можете включити тих, які узгоджуються зчитує. У цьому випадку я збираюся сказати, Я буду читати тільки з одного вузла. І я не можу гарантувати, що це відбувається щоб бути найбільш актуальні дані. 

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

І так економить ваші гроші. Але це ваш вибір. Якщо ви хочете несуперечливе читання або зрештою несуперечливе читання. Це те, що ви можете вибрати. 

Давайте поговоримо про індекси. Таким чином, ми згадали, що топ агрегації рівня. У нас є хеш ключі, і ми отримали ключі дальності. Це мило. І це на основній таблиці, я є один хеш-ключ, я отримав один ключ діапазону. 

Що це означає? Я отримав один атрибут, що я може працювати багатих запитів к. Це ключ діапазону. Інші атрибути на цьому item-- Я можу фільтрувати цих атрибутів. Але я не можу робити речі, як, це починається з або більше. 

Як мені це зробити? Я створити індекс. Там дві типи Індекси в DynamoDB. Індекс дійсно Ще один вид таблиці. І місцевий вторинний індекс. 

Перший ми поговоримо про. Так місцеві вторинні які співіснували в тому ж розділі, що і дані. І як такі, вони знаходяться на і той же фізичний вузол. Вони, що ми називаємо послідовною. Значення, вони визнають, від запису разом з таблицею. Коли записи приходить, ми напишемо через індекс. Ми напишемо до столу, і тоді ми будемо мати на увазі. Так от послідовним. Після того, як записи були визнав з таблиці, це гарантує, що місцевий вторинний індекс матиме те ж саме бачення даних. Але те, що вони дозволяють вам робити це визначити ключі альтернативні дальності. 

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

Будь-яка частина, яка була зроблена ця виробник після цієї дати, Мені потрібно, щоб витягнути з моєї лінії. Я можу обертатися індекс що шукатимуть, агрегування на дату виробництво цієї конкретної частини. Так що, якщо мій стіл був верхній рівень вже хешіруется виробника, може бути, це було влаштовано на частину ID, я може створити індекс вимикання цієї таблиці а хеш виробником і коливалася від дати виготовлення. І таким чином я міг би сказати, все, що був виготовлений між цими датами, Мені потрібно, щоб витягнути з лінії. Так що це місцевий вторинний індекс. 

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

Ми не будемо розділити LSI за кількома розділами. Ми розбити таблицю. Але ми не будемо розділяти LSI. Так це те, що Важливо розуміти, якщо ви робите дуже, дуже, дуже великі скупчення, то ви будете обмежуватися 10 гігабайт на вашому БІС. 

Якщо це так, то ми можемо використовувати глобальні вторинні. Глобальні вторинні є дійсно інша таблиця. Вони існують, щоб повністю від сторона з вашої первинної таблиці. І вони дозволяють мені знайти зовсім різні структури. Так що думайте про нього, як дані вставляються у двох різних таблиць, структурований двома різними способами. 

Я можу визначити абсолютно відрізняється хеш-ключ. Я можу визначити абсолютно інша клавіша діапазону. І я можу запустити цей абсолютно незалежно. Справді, у мене підготовлено мою здатність читання і написати ємність для мого глобальні вторинні індекси абсолютно незалежно моєю основною таблиці. Якщо я визначаю, що індекс, я говорю це скільки читати і писати Обсяг він збирається використовувати. 

І це окрема від моєї основної таблиці. Тепер обидва індекси дозволить нам не тільки визначити хеш і дальності ключі, але вони дозволяють нам проекти додаткових значень. Так що, якщо я хочу, щоб зчитувати індекс, і я хочу, щоб отримати набір даних, Мені не потрібно, щоб повернутися до головного Таблиця, щоб отримати додаткові атрибути. Я можу спроектувати ці додаткові атрибутів в таблиці підтримати доступу до файлу. Я знаю, що ми, ймовірно, отримати до деяких дійсно, really-- попадання в бур'янів тут, на деякі з цих речей. Тепер я отримав дрейфувати з цього. 

АУДИТОРІЯ: [нерозбірливо] --table ключ мав на увазі, хеш? Оригінальний хеш? Multi-рейки? 

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

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

Але це, перш за все, те, що індекс у базі даних для. Це за те, що в змозі швидко визначити, які записи, які рядки, які елементи таблиці мають властивості, які я шукав. 

НВІС, так як вони працюють? НВІС в основному є асинхронними. Оновлення вступає в таблиці, Таблиця потім асинхронно оновлюється всі ваші НВІС. Ось чому НВІС є зрештою узгоджуються. 

Важливо відзначити, що коли ви будуєте НВІС, і ви розумієте, ви створюєте інший вимір aggregation-- Тепер давайте говорити хороший приклад тут виробник. Я думаю, що я, можливо, говорили про виробник медичного пристрою. Виробники медичних виробів часто мають серійні номери частини. Частини, які входять до заміна тазостегнового все є трохи серійний номер на них. І вони могли б мільйони і мільйони і мільярди частин у всіх пристроях, які вони поставляються. Ну, вони повинні об'єднувати під різні розміри, всі частини в збірці, все частини, які були зроблені на деякій лінії, всі частини, які прийшли в з певною виробника на певну дату. І ці скупчення іноді встати в мільярди. 

Так що я працювати з деякими з ці хлопці, які страждають тому що вони створюють ці скупчення GINORMOUS в їх вторинних індексів. Вони можуть мати сирі частини таблиця, приходить як тільки хеш. Кожна частина має унікальний серійний номер. Я використовую серійний номер, як хеш. Це красиво. Мій сировину таблиця даних поширюється по всій ключового простору. Мій [? написати?] [? проковтування?] є дивним. Я беру багато даних. Тоді те, що вони роблять, вони створюють GSI. І я кажу, ви знаєте, що, мені потрібно, щоб побачити всі частини даного виробника. Ну, раптом я приймаючи мільярда рядків, і запихати їх на один вузол, тому що, коли Я, як агрегувати виробник ID, як хеш, і номер в діапазоні, потім все раптом я поставивши млрд частини в те, що цей виробник визволив мене. 

Це може викликати багато тиску на GSI, знову, тому що я молотком один вузол. Я ставлю всі ці вставляє в одному вузлі. І це реальна проблематично кейс. Тепер, я отримав хороший дизайн шаблон для, як ви уникнути. І це одна з проблем, що я завжди працювати. Але те, що відбувається, є GSI може не вистачає потужності записи щоб бути в змозі висунути всі ті рядків в одному вузлі. І те, що відбувається потім це первинний, таблиця Клієнт, головна таблиця буде задушив бо GSI не може наздогнати. Так що мій курс буде вставка падають на основній таблиці як мій GSI намагається не відставати. 

Гаразд, так GSI-х, БІС, який я повинен використовувати? БІС узгоджуються. GSI є в кінцевому рахунку відповідає. Якщо це нормально, я рекомендую використовувати GSI, вони набагато більш гнучким. БІС можуть бути змодельовані як GSI. І якщо розмір даних в хеш-ключів в Ваша колекція перевищує 10 гігабайт, то ви будете хотіти використовувати що GSI, тому що це просто жорсткий ліміт. 

Гаразд, так масштабування. Пропускна в Динамо БД, ви положення може [нерозбірливо] пропускна до столу. У нас є клієнти, які мають підготовлено 60 billion-- роблять 60 млрд запитів, регулярно працює на більш ніж мільйон запитів за секунду на наших столах. Там насправді немає Теоретична межа того, скільки і як швидко таблиця може працювати в Динамо БД. Є деякі м'які ліміти на ваш рахунок що ми ставимо там так що ви не сходите з розуму. Якщо ви хочете більше, ніж що не є проблемою. Ви приходите, повідомте нам. Ми підійміть диск. 

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

Таким чином, ці коригуються незалежно один від одного. Міра РКО в строго узгоджені читання. ОК, так що якщо ви говорите, я хочу 1 000 РКО-х ті, строго послідовним, тих, узгоджуються читає. Якщо ви хочете сказати, що я можливе несуперечливе читання, Ви можете надання 1 000 РКО, ви йдете щоб отримати в кінцевому підсумку 2,000 відповідає читає. І половина ціни для тих, в кінцевому підсумку складаються в читає. 

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

Ці речі, речі, як неоднорідних навантаження, гарячі клавіші, гарячі перегородки. Я удару особливий простір ключів дуже важко, з певних причин. Чому я це роблю? Давайте зрозуміти. Я змішую мої гарячі дані з холодними даних. Я дозволяю мої таблиці отримати Величезний, але там дійсно тільки деяку підмножину даних це дійсно цікаво для мене. Таким чином, для даних журналу, наприклад, багато клієнти, вони отримують дані, авторизуйтесь щодня. Вони отримали величезну кількість даних журналу. 

Якщо ви тільки що демпінг все журнал дані в одній великій таблиці, з часом ця таблиця збирається отримати масивне. Але я дійсно зацікавлені тільки в Останні 24 годин, останні сім днів, останні 30 днів. Як би там не проміжок часу що я зацікавлені в пошуку для події, турбує мене, або подія, яка мені цікаво, що єдиний разу, коли вікно, що мені потрібно. Отже, чому я покласти 10 років Варто каротажних даних в таблиці? Те, що це викликає це таблиця фрагмент. 

Він отримує величезне. Це починає поширюватися з на тисячі вузлів. А так як ваша здатність так низько, ви насправді обмеження швидкості на кожному один з тих окремих вузлів. Отже, давайте почнемо, дивлячись на те, як ми згорнути цю таблицю протягом. Як ми можемо управляти, що дані трохи краще, щоб уникнути цих проблем. І те, що це схоже? Це те, що, що виглядає. Це те, що погано NoSQL виглядає. 

Я отримав гарячу клавішу тут. Якщо ви подивитеся на стороні тут, це всі мої розділи. Я отримав 16 розділів тут на цієї конкретної бази даних. Ми робимо це весь час. Я запускаю це для клієнтів весь час. Це називається тепловою карті. Теплова карта говорить мені, як ти доступу до вашої простір ключів. І те, що це говорить мені, це що є один конкретний хеш що цей хлопець любить дуже багато, тому що він вдаривши по ньому дійсно, дійсно важко. 

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

І те, що це схоже? І це стає найбільш з Динамо DB пропускної здатності, але це дійсно стає більшість з NoSQL. Це не обмежується Динамо. Це я definitely-- використовується для роботи в Монго. Я знайомий з багатьма платформами NoSQL. Кожна людина має ці типи гарячих ключових проблем. Щоб отримати максимальну віддачу від будь NoSQL бази даних, спеціально Динамо БД, Ви хочете, щоб створити таблиці де елемент хеш-ключ має велика кількість різних значень, високий ступінь потужності. Тому що це означає, що я пишу на безліч різних ковшів. 

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

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

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

АУДИТОРІЯ: Ну, неминуче деякі місця будуть жаркіше, ніж інші. 

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

Гаразд, так що давайте говорити про деякі клієнти зараз. Ці хлопці AdRoll. Я не знаю, якщо ви знайомі з AdRoll. Ви, напевно, побачити їх багато в браузері. Вони оголошень перенацілювання, вони найбільший оголошення перенацілювання бізнес там. Вони, як правило, регулярно запускати більш 60 млрд транзакцій в день. Вони роблять більше мільйона транзакцій в секунду. Вони отримали досить просту таблицю структура, жвавих таблиці. Це в основному тільки хеш ключ куки, діапазон демографічна Категорія, а потім третій атрибут рахунок. 

Таким чином, ми всі повинні кукі у наш браузер від цих хлопців. І коли ви йдете до участь купець, вони в основному оцінка вас через різні демографічні категорії. Коли ви йдете на сайт і ви говорите, я хочу, щоб цей ad-- або в основному не говорять that-- але коли ви йдете на сайт вони кажуть, що ви хочете побачити це оголошення. І вони йдуть отримати, що оголошення від AdRoll. AdRoll виглядає вас на столі. Вони знаходять свій печиво. Рекламодавці, що розповідають їм, я хочу когось хто середнього віку, 40-річний чоловік, у спорті. І вони виграють вас в цих демографічних і вони вирішують чи ні що це хороша реклама для вас. 

Тепер у них є SLA з їхні рекламні провайдери щоб забезпечити суб-10 мілісекунду Відповідь на кожен запит. Так вони використовують Динамо DB для цього. Вони удару нам мільйон запитів в секунду. Вони в змозі зробити все їх пошуки, сортування всього, що дані, і отримати, що додати посилання на що рекламодавця у віці до 10 мілісекунд. Це дійсно досить феноменальний Реалізація, що вони мають. 

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

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

Таким чином, вони мають S3 відра вони штовхають всі бінарні артефакти в. І тоді вони мають Динамо DB записи, вказати людям на цих трьох об'єктів S3. Коли вони повинні дивитися на відео, вони дивляться запис в Динамо БД. Вони натисніть на посилання. Вони тягнуть вниз відео з S3. Так що ніби як це виглядає. І це прямо зі своєї команди. 

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

Не гарний ОПС команда. Вони не мають багато експлуатаційних ресурсів. Вони боролися, намагаючись зберегти їхня інфраструктура додатків до і працює. Вони прийшли до нас. Вони дивилися на те Динамо БД. Вони сказали, що це для нас. Вони побудували всю свою Структура програми на ньому. Деякі дійсно хороші коментарі тут від команди на їх здатності щоб тепер зосередитися на будівництво гра, а не того, щоб підтримувати інфраструктура, яка стає величезна кількість накладних витрат для своєї команди. Так що це щось that-- перевагу, що ви отримаєте від Динамо БД. 

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

У даному конкретному Наприклад, як і більшість держав є вимога ліцензування, тільки ліцензія одного водія на людину. Ви не можете піти, щоб отримати двох водія ліцензії в штаті Бостон. Я не можу зробити це в Техасі. Це зразок того, як це. І так в DMV, у нас є операцій пошуку, ми хочу подивитися водійське посвідчення за кількістю соціального забезпечення. Я хочу, щоб подивитися інформацію про користувача за кількістю ліцензій водія. 

Таким чином, ми, можливо, таблицю користувача, що має хеш-ключ на серійний номер, або номер соціального страхування, і різні атрибути визначаються по цьому пункту. В даний час на цій таблиці I може визначити, що GSI перевертає, що навколо, що я хочу, каже, ключовий хеш за ліцензією, а потім всі інші предмети. Тепер, якщо я хочу, щоб запитувати і знайти Номер ліцензії для будь-якої соціальної Номер безпеки, я можу запит основну таблицю. 

Якщо я хочу, щоб запросити і я хочу щоб отримати соціальне забезпечення номер або інші атрибути за допомогою номер ліцензії, я можу запитати GSI. Ця модель, що один до одного відносини. Просто дуже простий GSI, фліп ці речі. Тепер, поговоримо про одну для багатьох. Один до багатьох в основному Ваш ключ Діапазон хеш. Де ми отримуємо багато з цим Використання випадок дані монітора. Дані моніторингу регулярно поставляється в Інтервал, як Інтернет речей. Ми завжди отримуємо все це записи в найближчі весь час. 

І я хочу, щоб знайти всі свідчення між певний період часу. Це дуже поширена в запит Моніторинг інфраструктури. Шлях йти про те, що це, щоб знайти проста структура таблиці, одна таблиця. Я отримав таблицю вимірювань приладу з ключем хеш на пристрій ID. І в мене є ключ діапазону на мітка, або в даному випадку, епос. І, що дозволяє мені виконати комплекс запити до цього ключа діапазоні і повернутися ті записи, які в порівнянні з результатом Встановлено, що я шукаю. І він будує, що одна для багатьох відношеннях в основній таблиці, використовуючи хеш ключа, діапазон ключовою структурою. 

Так що це свого роду вбудований в таблиці в БД Динамо. Коли я визначити хеш і діапазон т стіл, я визначення один до багатьох відносин. Це відносини батько-дитина. 

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

Таким чином, користувач може мати кілька ігор. Це один до багатьох відносин між користувач та ігри він грає. А потім на GSI, Я фліп що навколо. Я хеш на грі і Я діапазоні від користувача. Так що, якщо я хочу, щоб всі Гра користувач грає в, Я запитувати основну таблицю. Якщо я хочу, щоб отримати всі користувачі які відіграють певну гру, Я запросити GSI. Отже, ви бачите, як ми це робимо? Ви будуєте для підтримки цих GSI років Прецедент, додаток, доступ візерунок, додаток. 

Якщо мені потрібно запросити на це вимір, нехай мені створити індекс за цим виміром. Якщо я не роблю, я не хвилює. І залежно від випадку використання, я можливо, буде потрібно індекс або я не міг. Якщо це просто один до багатьох, основній таблиці в порядку. Якщо мені потрібно зробити це багато, щоб багато, або мені потрібно зробити один для тих, то, можливо, мені потрібно на друге індекс. Так що все залежить від те, що я намагаюся зробити і те, що я намагаюся отримати досвідчений. 

Ймовірно, я не буду витрачати надто багато часу говорити про документах. Це стає трохи, напевно, глибше, ніж ми повинні йти в. Давайте трохи поговоримо про багатих вираз запиту. Таким чином, в Динамо БД у нас є здатність створювати що ми називаємо проекційні вираження. Проекційні вираження просто вибираючи поля або значення що ви хочете, щоб відобразити. ОК, так що я можу зробити вибір. Я роблю запит до БД Динамо. І я кажу, ви знаєте, що, показати мене тільки п'ятьох відгуки зірки для цього конкретного продукту. Так що все, що я хочу бачити. Я не хочу, щоб побачити всі інші атрибути рядки, Я просто хочу, щоб це побачити. Це просто, як і в SQL, коли ви кажуть виберіть зірку або з таблиці, Ви отримуєте все. Коли я кажу, виберіть ім'я зі стіл, я тільки один атрибут. Це те ж саме роду речі в Динамо БД або ще бази даних NoSQL. Фільтрувати вирази дозволяють мені в основному скоротити набір результатів вниз. Так що я зробити запит. Запит може повернутися з 500 пунктів. Але я хочу тільки ті елементи, які є атрибут, який говорить, що це. Отже, давайте відфільтрувати ці елементи які не відповідають цієї конкретної запит. Отже, ми маємо вираження фільтра. 

Фільтрувати вирази можуть буде працювати на будь атрибут. Вони не хотіли інтервальні запити. Підвищення запити більш виборчим. Фільтрувати запити вимагають від мене, щоб піти отримати весь набір результатів, а потім вирізати дані, які я не хочу. Чому це так важливо? Тому що я читав все це. У запиті, я буду читати і це буде гігантський про дані. А потім я збираюся вирізати те, що мені потрібно. І якщо я тільки вирізаючи пара рядків, то це нормально. Це не так неефективно. 

Але якщо я читаю цілий стос Дані, просто вирізати один елемент, потім я збираюся бути краще від використання діапазону запиту, бо це набагато більш вибірково. Це врятує мене багато гроші, тому що я платити за це читання. Якщо результати, який повертається перетнути цей дріт може бути менше, але я плачу за читання. Так розумію, як Ви отримуєте дані. Це дуже важливо в Динамо БД. 

Умовні вирази, це те, що Ви могли б назвати оптимістичною блокування. Оновити, якщо є, або, якщо це значення еквівалентно тому, що я вказую. І якщо у мене є штамп часу на запис, я міг би прочитати дані. Я міг би змінити ці дані. Я міг би піти пишуть, що назад дані в базу даних. Якщо хтось змінив запис, відмітка часу може бути змінений. І таким чином мій умовно оновлення можна сказати, оновлення якщо відмітка дорівнює цього. Або оновлення не буде виконано, тому що хтось оновив рекорд в той же час. 

Це те, що ми називаємо оптимістичне блокування. Це означає, що хтось може прийти і змінити його, і я збираюся виявити його коли я повернуся, щоб написати. І тоді я можу насправді читати, що даних і кажуть, ой, він змінив це. Мені потрібно, щоб врахувати це. І я можу змінити дані в моїй записувати і застосовувати ще одне оновлення. Таким чином, ви можете зловити тих, додаткових Оновлення, які відбуваються між часом що ви читаєте дані і раз, коли ви могли б написати дані. 

АУДИТОРІЯ: І фільтр Вираз насправді означає не номер або не-- 

[Реле ГОЛОСИ] РВК Хуліхеном: Я не буду отримати занадто багато в цьому. Це зарезервоване слово. Вид фунт стриманий Ключове слово в Динамо БД. Кожна база даних має свій власний захищені Імена для колекцій ви не можете використовувати. Динамо БД, якщо ви вкажете фунт перед цим, Ви можете визначити ці імена нагорі. Це еталонне значення. Це, ймовірно, не найкращий синтаксис є там для цієї дискусії, тому що він потрапляє в деяких real-- Я був би говорити більше про те, що на більш глибокому рівні. 

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

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

Після 24 годин, гей, ви знаєте, я не хвилює. Так, може бути, кожен опівночі я рол мій стіл до нової таблиці і я вивільнення невикористовуваних цю таблицю. І я візьму РКО-х і Вниз WCU, бо через 24 години Я не працює, як багато запити до цих даних. Так що я йду, щоб врятувати гроші. І, може бути, через 30 днів я не навіть потрібно піклуватися про нього все. Я міг би взяти ВКУ-х все, аж до одного, тому що ви знаєте, що, це ніколи не збираєтеся отримати запис. Дані 30 днів. Це ніколи не змінюється. 

І це майже ніколи не відбувається, щоб отримати читати, так що давайте просто вважати, що RCU до 10. І я економлю купу грошей на це даних і платити тільки за мої гарячі даних. Так що це важлива річ, щоб шукати на те, коли ви дивитеся на часових рядів дані, що надходять в в об'ємі. Ці стратегії. Тепер, я міг дозволити його всі йдуть в тій же таблиці і нехай ця таблиця рости. Зрештою, я збираюся см проблеми з продуктивністю. Я збираюся мати, щоб розпочати архівацію деякі з цих даних зі столу, що ні. 

Давайте краще розробляти додаток так що ви можете працювати так добре. Так що це просто автомат в коді програми. Опівночі щоночі вона котиться по столу. Можливо, те, що мені потрібно, це ковзання Вікно 24 годин даних. Тоді на регулярній основі я Виклик даних зі столу. Я обрізки його з Крон робота, і я ставлю його на цих інших таблиць, що вам потрібно. Так що, якщо перекидання працює, це здорово. Якщо ні, обріжте її. Але давайте тримати, що гарячий дані від ваших холодних даних. Це заощадить вам багато грошей, і зробити ваші таблиці більш досконалих. Таким чином, наступна річ, ми поговоримо про те, каталог продукції. Каталог товарів поза досить часто кейс. Це насправді дуже загальний шаблон що ми побачимо в різних речей. Ви знаєте, Twitter для Наприклад, гаряча твіт. Все йде і хапаючи що в твіттері. Каталог товарів, я отримав продажу. Я отримав гарячу продаж. Я отримав 70000 запитів в друге пришестя для продукту Опис з мого каталогу. Ми бачимо це на роздріб операція зовсім небагато. Так як ми маємо справу з цим? Там немає ніякого способу, щоб впоратися з цим. Всі мої користувачі хочуть, щоб побачити та ж частина даних. Вони приходять в, одночасно. І всі вони робити запити по тій же частині даних. Це дає мені, що гаряча клавіша, що велика червона смуга на моїй карті, що нам не подобається. І це, як це виглядає. Так на мою ключового простору я отримую забив пунктів продажу. Я не отримую нічого ніде. 

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

І тоді більшість ваших читає почати пошук, як це. Я отримав все це кеш-парад тут і я нічого не отримав тут відбувається тому що база даних сидячи позаду кеш і не читає і не прийти до кінця. Якщо я змінити дані в бази даних, у мене є для оновлення кешу. Ми можемо використовувати щось як пари зробити це. І я поясню, як це працює. Гаразд, повідомленнями. E-mail, ми всі використовуємо електронну пошту. 

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

І причина, чому, тому що я повинен йти читати пункти, щоб отримати атрибути. І якщо мої органи все тут, потім читання всього кілька пунктів якщо мій Довжина тіла в середньому 256 кілобайт кожен, математика стає досить некрасиво. Так що я хочу, щоб прочитати входять Давида. Вхідні Давида має 50 пунктів. Середня і розмір 256 кілобайт. Ось мій коефіцієнт конверсії для РКО є чотирьох кілобайт. 

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

Так от інформація що мій робочий процес потреб. Це в мою поштову скриньку GSI. Це дата, відправник, предметом, а потім ідентифікатор повідомлення, який вказує повернутися до таблиці повідомлень де я можу отримати тіло. Ну, це було б записувати ідентифікатори. Вони вказують назад до ідентифікатори пункт на столі Динамо DB. Кожен індекс завжди creates-- завжди має елемент ID, як частина of--, що приходить з індексом. 

Добре. АУДИТОРІЯ: Це говорить його там, де він зберігається? РВК Хуліхеном: Так, він говорить exactly--, що саме, що вона робить. Це говорить, ось мій повторно запис. І це буде вказувати його назад в моїй повторного запису. Точно. ОК, так що тепер мою поштову скриньку є фактично набагато менше. І це насправді підтримує робочий процес електронної додаток. Так мою поштову скриньку, я натискаю. Я йду вздовж і я натискаю на повідомлення, що, коли мені потрібно піти отримати тіло, тому що я збираюся перейти на іншу точку зору. Так що, якщо ви думаєте, про тип MVC в рамки, вид моделі контролера. 

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

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

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

Але ідея про ігри, щоб думати про в термінах інтерфейсів API інтерфейси, які, взагалі кажучи, HTTP і JSON. Це, як мобільні ігри вид взаємодіють з їх кінцями назад. Вони роблять JSON реєстрацію. Вони отримують дані, і все це, взагалі кажучи, в хороших інтерфейсів JSON. 

Такі речі, як завести друзів, отримати дані лідерів, обмін, користувальницький контент, відсунути до системи, ці типи речей що ми збираємося робити. Двійкові дані активів, ці дані не може сидіти в базі даних. Це може сидіти в Об'єкт магазин, правильно? Але база даних буде в кінцевому підсумку кажу систему, розповідаючи додаток куди йти отримати його. І неминуче, мультиплеер сервери, на кінець інфраструктури назад, і призначені для високого доступність і масштабованість. Таким чином, ці речі, які ми всі хочемо в ігровому інфраструктури сьогодні. 

Отже, давайте поглянемо на як це виглядає. Є основний задній кінець, дуже проста. Ми отримали систему тут з кілька зон доступності. Ми говорили про АЗС в being-- думаю з них у вигляді окремих центрів обробки даних. Центр Більш дані за AZ, але це нормально, просто думати про них як окремі дані центри, які географічно і виділяють вина. 

Ми збираємося, щоб мати випадки пара EC2. Ми збираємося, щоб мати деякі задньої частини сервера. Може бути, якщо ви спадщина архітектура, ми використовуючи те, що ми називаємо RDS, реляційні бази даних. послуги Може бути MSSQL, MySQL, або щось подібне. Це шлях багато додатків призначені сьогодні. 

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

Кращий спосіб зробити це піти вперед і покласти ці предмети в S3 відра. S3 є репозиторії об'єкта. Він побудований спеціально для виступаючої ці типи речей. І нехай ті клієнти просять безпосередньо з цих об'єктів відра, розвантажити сервери. Таким чином, ми починаємо масштабувати тут. 

Тепер ми отримали користувачі по всьому світу. Я отримав користувачі. Мені потрібно, щоб вміст локально розташований недалеко від цих користувачів, правильно? Я створив відро S3 як мій репозиторії. І я фронт, який з розподіл CloudFront. 

CloudFront є компакт-диск і Зміст мережу доставки. В основному це бере дані, які ви вказуєте і кешируєт все це через Інтернет так що користувачі у всьому світі можуть мати дуже швидку відповідь, коли вони просять ці об'єкти. 

Таким чином, ви отримаєте уявлення. Ви начебто використовуючи всі аспекти AWS тут, щоб отримати це зробити. І врешті-решт, ми кидаємо в авто масштабування групи. Таким чином, наші випадках AC2 наших ігрових серверів, як вони починають отримувати зайнятий і більш зайнятими і більш зайнятими, вони просто обертаються інший Примірник, спина ще один екземпляр, спина ще один екземпляр. Так технології AWS має, це дозволяє задати параметри навколо якого сервери будуть рости. Таким чином, ви можете мати н кількість серверів там в будь-який момент часу. І якщо ваш вантаж йде, вони будуть скоротиться число буде скорочуватися. І якщо навантаження повертається, це буде рости назад, пружно. 

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

Ну, кеш не працює настільки великий, в іграх, чи не так? Для ігор, написання є болючим. Ігри дуже важкий написати. Кеш не працює, коли ви написати важких, тому що ви завжди отримав оновити кеш. Ви оновити кеш, це не має значення для кешування. Це насправді просто додаткова робота. 

Так, куди ми йдемо тут? У вас є великий вузьке там в базі даних. І місце, щоб піти очевидно, поділу. Розмітка НЕ легко зробити, коли ви справу з реляційними базами даних. З реляційними базами даних, ви відповідальність за управління, ефективно, простір ключів. Ви говорите користувачів між А і М йди сюди, між N і Z туди. І ви переходите по застосуванню. Таким чином, ви маєте справу з цей розділ джерела даних. Ви повинні транзакційних обмежень які не охоплюють розділи. Ви отримали всі види безладу, що ви справу з там намагаються мати справу з масштабування і будівництво більшого інфраструктури. Це не просто не цікаво. 

АУДИТОРІЯ: Так ви кажете, що збільшення точок джерела прискорює процес? РВК Хуліхеном: Підвищення? АУДИТОРІЯ: Джерело пунктів. РВК Хуліхеном: Source точки? АУДИТОРІЯ: З інформації, де інформація приходить від? РВК Хуліхеном: Ні Те, що я кажу, є підвищення Кількість розділів в сховище даних покращує пропускну здатність. Так що тут відбувається, користувачі вступу в екземплярі EC2 тут, Ну, якщо мені потрібно користувачеві Це М, я піду сюди. Від N р, я піду сюди. З Р до Я, я піду сюди. 

АУДИТОРІЯ: ОК, так ті, ті зберігаються в різних вузлах? 

РВК Хуліхеном: Так. Подумайте про них, як різні бункери даних. Таким чином, ви того, щоб зробити це. Якщо ви намагаєтеся зробити це, якщо ви намагаєтеся в масштабі на реляційної платформі, це те, що ви робите. Ви приймаєте дані і ви різання його. І ви поділу його за кілька екземплярів бази даних. І ви всі, що управління на рівні додатків. Це не весело. Так що ми хочемо йти? Ми хочемо, щоб перейти DynamoDB, повністю керований, NoSQL сховища даних, надання пропускну здатність. Ми використовуємо вторинні індекси. Це в основному HTTP API і включає в себе підтримку документа. Таким чином, ви не повинні турбуватися про будь-якому з цього поділу. Ми робимо все це для вас. Так що тепер, замість цього, ви просто напишіть в таблиці. Якщо таблиця повинна бути розділена, що відбувається за лаштунками. Ви повністю ізольовані від як розробник. Отже, давайте поговоримо про деякі з випадків використання що ми біжимо в в іграх, загальна ігрові сценарії, лідерів. Отже, ви отримали користувачі в найближчі, в BoardNames, що вони на, бали для цього користувача. Ми могли б бути хешування на UserID, а то у нас асортимент на гру. Таким чином, кожен користувач хоче бачити Всі ігри він грав і всі його найвищий бал по всієї гри. Так що його особиста лідерів. 

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

Тепер я збираюся, щоб прояснити на BoardName, що гра. І я збираюся в діапазоні від найвищий бал. А тепер я створив різні відра. Я використовую ту ж таблицю, ті ж самі дані. пункт Але я створюю відро, що дає мені агрегація найвищий бал по грі. 

І я можу запросити цю таблицю щоб отримати цю інформацію. Так я встановив, що зразок запиту до підтримуватися вторинного індексу. Тепер вони можуть бути відсортовані за BoardName і сортуються за TopScore, залежно від. Таким чином, ви можете бачити, це типу прецедентів ви отримаєте в іграх. Ще один хороший варіант використання ми отримуємо в іграх це нагороди і хто виграв нагороди. І це великий кейс де ми називаємо розріджених індексів. Рідкісні індекси є Здатність генерувати індекс, який не обов'язково містить кожен пункт на столі. А чому ні? Оскільки атрибут, який будучи індексований не існує по кожному пункту. 

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

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

АУДИТОРІЯ: Чи можу я поставити швидкий питання? Одним з них є важким написати? РВК Хуліхеном: Що таке? АУДИТОРІЯ: Написати важким. РВК Хуліхеном: Написати важким. Дозвольте мені бачити. 

АУДИТОРІЯ: Або це не те, що ви можете просто Голос в лічені секунди? РВК Хуліхеном: Ми йдемо через сценарії голосування. Це не так уже й погано. Чи є у вас, хлопці, є кілька хвилин? ДОБРЕ. 

Таким чином, ми будемо говорити про голосування. Так в режимі реального часу голосування, у нас є Вимоги для голосування. Вимоги, які ми дозволити кожна людина, щоб голосувати тільки один раз. Ми хочемо, щоб ніхто не зможе змінити свій голос. Ми хочемо, агрегацію в режимі реального часу й аналітика для демографії що ми збираємося, щоб бути показуючи користувачів на сайті. 

Подумайте про це сценарії. Ми багато працюємо реальності Телевізор показує, де вони робить ці точний тип речей. Таким чином, ви можете думати про сценарії, у нас є мільйони і мільйони дівчата підліткового там з їх стільникових телефонів і голосування, і голосування, і голосування для тих, хто їх знайти, щоб бути найпопулярнішим. Так ось деякі з Вимоги у нас закінчилися. 

І тому перший взяти у вирішенні цієї проблеми будуватиме дуже просте додаток. Так що я отримав цей додаток. У мене є кілька виборців там. Вони приходять в, вони потрапили в додаток голосування. У мене є сире голосів таблицю Я просто звалище ці голоси в. Я є сукупність голосів таблиця, зробить мої аналітики та демографії, і ми поставимо все це там. 

І це здорово. Життя чудове. Життя хороша, поки ми не дізнаємося, що завжди є тільки один або два люди, які користуються популярністю на виборах. Там тільки один або дві речі, що люди дійсно піклуються про. І якщо ви голосуєте на масштаб, раптом я буде молотком пекло з два кандидати, один або два кандидати. Дуже обмежене число пунктів люди вважають, щоб бути популярним. 

Це не хороший дизайн моделі. Це насправді дуже погано шаблон бо це створює те, що ми говорили про яку було гарячі клавіші. Гарячі клавіші є чимось нам не подобається. 

Отже, як ми це виправити? І справді, то, як виправити це приймаючи ті кандидатів відра і для кожного кандидата ми маємо, ми збираємося додати випадкове значення, те, що ми знаємо, випадкова Значення між одним і 100, між 100 і 1000, або від одного до 1000, Однак багато випадкові величини ви хочете додати в кінець цього кандидата. 

І що я дійсно зробив те? Якщо я використовую ідентифікатор кандидата як відро для сукупних голосів, якщо я додав випадковий Кількість до кінця, що, Я створив вже 10 відер, А СТО відер, тисячі відра що я агрегування голосів впоперек. 

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

Тепер на зворотній, я знаю, що я отримав сто відер. Так що, коли я хочу, щоб йти вперед і агрегувати голосів, Я читав від усіх цих відрах. Так що я йти вперед і додати. І тоді я розкид зібрати де я виходжу і кажу агов, Ви знаєте, що, ключ цього кандидата просторів більше ста відра. Я збираюся зібрати всі голосів від тих ста відра. Я збираюся об'єднати їм, і я збираюся сказати, Кандидата в даний час Загальна Підрахунок голосів від х. 

Тепер обидва записи запит і запит читання красиво розподілені тому що я пишу по і я читаю на сотні ключів. Я не пишу і читати по одному ключу в даний час. Так що це великий малюнок. 

Це насправді, ймовірно, один з найбільш важливих дизайн шаблони для масштабу в NoSQL. Ви побачите цей тип шаблон в будь-який смак. MongoDB, DynamoDB, це не Справа, всі ми повинні зробити це. Тому що, коли ви маєте справу з тих величезних скупчень, Ви повинні з'ясувати, шлях до поширювати їх по всій відра. Так що це, як ви робите це. Гаразд, так, що Ви робите прямо зараз це ви будете торгувати з читання Вартість для запису масштабованості. Вартість моєї читання трохи складніше і я повинен йти читати з СТО відер замість одного. Але я можу написати. І моя пропускна здатність, моя записи пропускна здатність неймовірно. Так що, як правило, є цінним Техніка для масштабування DynamoDB, або будь-яка база даних NoSQL з цього питання. Таким чином, ми з'ясували, як масштабувати його. І ми зрозуміли, як ліквідувати наші гарячі клавіші. І це фантастика. І ми отримали цю хорошу систему. І це дає нам дуже правильну голосування тому що у нас запис голосів де-простака. Він побудований в DynamoDB. Ми говорили про умовних прав. 

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

Так що це реальна проблема, коли ви починають дивитися на цього типу сценарію. І як ми вирішимо, що? Ми вирішуємо її з тим, що ми зателефонувати DynamoDB потоків. Потоки замовляється час і розподіляють журнал змін кожного доступу до столу, кожен написати Доступ до таблиці. Будь-які дані, які написав у Таблиця показує вгору в потоці. 

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

Це суворо наказав кожному пункту. Коли ми говоримо, час замовити і розподіляють, Ви побачите в розділі на потік. Ви побачите предмети, поновлення в порядку. Ми не гарантуючи на потоці, що ти збирається отримати кожну угоду в порядку через предмети. 

Так потоки ідемпотентна. Хіба ми всі знаємо, що ідемпотентів означає? Ідемпотентна означає, що ви можете зробити це знову, і знову, і знову. Результат буде той самий. 

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

Те ж саме з MongoDB. MongoDB має конструкцію вони називають oplog. Це точно такий же конструкцією. Багато баз даних NoSQL їсти цю конструкцію. Вони використовують його, щоб робити речі, як реплікація, яка саме те, що ми робимо з потоками. АУДИТОРІЯ: Може бути, єретичним питання, але ви говорити про додатки робиш так далі. Струмки гарантовано неможливо йти вниз? РВК Хуліхеном: Так, потоки гарантовано ніколи не ввійде. Ми управляти інфраструктурою позаду. потоки автоматично розгорнути в їх авто масштабування групи. Ми підемо через маленький трохи про те, що відбувається. 

Я не повинен сказати, що вони не гарантовано ніколи не йдуть вниз. Елементи гарантується з'являються в потоці. І потік буде доступний. Так що йде вниз або повертається вгору, що відбувається внизу. Це covers-- це нормально. Гаразд, так що ви отримаєте різні Типи вид на екрані. Типи думка, що важливі до програміст, як правило, є, що це було? Я старий вигляд. Коли оновлення парад таблицю, вона буде натиснути колишньому до потоку так що дані можна заархівувати, або зміна контроль, ідентифікація зміни, зміни Управління. 

Новий образ, то, що це тепер, після оновлення, це інший тип зору Ви можете отримати. Ви можете отримати обидва старі і нові образи. Може бути, я хочу їх обох. Я хочу, щоб подивитися, що це було. Я хочу, щоб подивитися, що він змінився. 

У мене є тип відповідності процесу, який працює. Він повинен переконатися, що коли ці речі змінюються, що вони в певних межах або протягом певних параметрів. 

І тоді, можливо, я тільки потрібно знати, що змінилося. Мене не хвилює, який елемент змінився. Мені не потрібно, щоб знати які атрибути змінилося. Мені просто потрібно знати, що деталі дотику. Таким чином, ці типи видом що ви отримуєте від потоку і ви можете взаємодіяти з. 

Додаток, споживає потік, це свого роду, як ця працює. Клієнт DynamoDB попросити передавати дані в таблиці. Потоки розгорнути на те, що ми називаємо осколки. Осколки масштабуються незалежно від таблиці. Вони не шикуються повністю до розділів вашого столу. І причина, чому це тому що вони шикуються з потужністю, струм Ємність таблиці. 

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

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

Таким чином, ви використовувати включений те, KCL Додаток для читання потік. Бібліотека кинезисом Клієнт фактично управляє працівників для вас. І це також робить деякі цікаві речі. Це створить кілька таблиць до в табличному DynamoDB відслідковувати, які елементи були оброблені. Так що це шлях, якщо він падає назад, якщо це падає і приходить і отримує стояв назад, він може визначити, де це було в обробці потоку. 

Це дуже важливо, коли Ви говорите про реплікації. Мені потрібно знати, що був дані були оброблені і які дані ще повинні бути оброблені. Таким чином, бібліотека, KCL для потоків буде дати вам багато цієї функціональності. Він піклується про всіх господарством. Він стоїть на працівника для кожного осколка. Це створює адміністративну таблицю для кожного осколка, для кожного працівника. І, як ті працівники вогонь, вони підтримують ці таблиці так що ви знаєте цю запис був читати і обробляються. А потім, що шлях, якщо процес помирає і повертається в Інтернеті, він може відновити право, де він зняв. 

Тому ми використовуємо це для крос-регіон реплікації. Багато клієнтів є потреба в переміщати дані або частини своїх таблиць даних навколо різних регіонах. Є дев'ять регіонів по всьому світу. Так що може бути я need-- може є користувачі в Азії, користувачі на східному узбережжі Сполучених Штатів. Вони мають різні дані, що Необхідно локально розподіленою. І, може бути, користувач рейси з Азія до США, і я хочу, щоб повторити його дані з ним. Так що, коли він отримує від літака, він має хороший досвід, використовуючи свій мобільний додаток. 

Можна використовувати перехресну область Бібліотека реплікації для цього. В основному у нас є за умови, дві технології. Один це консольний додаток ви можете встати на вашому екземплярі EC2. Вона працює чисто реплікації. А потім ми дали вам бібліотеку. Бібліотека ви можете використовувати, щоб побудувати власний додаток, якщо вам хочу зробити божевільні речі з цим data-- фільтр, повторити тільки його частину, обертати дані, перемістити його в відрізняється стіл, так далі, і так далі. Так що ніби як це виглядає. 

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

Цей код може обробляти записи геть потоку. Це може робити все, що хоче з нею. У цьому конкретному прикладі, всі ми дійсно робите входу атрибути. Але це тільки код. Код може зробити що-небудь, чи не так? 

Таким чином, ви можете обертати ці дані. Ви можете створювати похідні вигляд. Якщо це структура документа, Ви можете згладити структуру. Ви можете створити альтернативні індекси. Всі види речей, ви можете робити з DynamoDB потоків. 

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

Ми говорили про те, як поставити кеш перед базі даних для цієї продажів сценарій. Ну, що станеться, якщо я оновити опис товару? Ну, якщо я був Лямбда Функція працює на цьому столі, якщо я оновити опис товару, він буде підібрати запис з потоком, і це оновлення ElastiCache Примірник з новими даними. Так що це багато Що ми робимо з Lambda. Це клей код, роз'єми. І це насправді дає здатність до запуску і працювати дуже складних додатків без виділеного сервера інфраструктура, яка насправді здорово. 

Отже, давайте повернемося до нашого в режимі реального часу архітектура голосування. Це новий і покращений з нашим потоки і, KCL включений додатки. Те ж саме, як і раніше, ми можемо впоратися з будь масштаб виборів. Нам подобається це. Ми робимо з розкиду збирає по декількох відра. У нас є оптимізм замок відбувається. Ми можемо тримати наші виборці від зміни їх голосу. Вони можуть голосувати тільки один раз. Це фантастика. У режимі реального часу відмовостійкість, масштабована агрегація справжнє. Якщо річ падає, це знає, де перезапустити себе коли він повертається, бо ми використовуємо додаток KCL. І тоді ми можемо також використовувати, що Додаток KCL передавати дані з в червоний зсув для інших додаток аналітика, або використання Еластичний MapReduce для запуску в режимі реального часу потокове скупчення геть ці дані. 

Таким чином, ці речі, які ми не говорив багато про що. Але вони додаткова технології, які приходять нести, коли ви шукаєте на цих типах сценаріїв. 

Гаразд, так це про аналітика з DynamoDB потоків. Ви можете зібрати де-простака Дані, зробити всі види з хороших речей, сукупні дані в пам'яті, створювати похідні цих таблиць. Це величезний кейс що багато клієнтів беруть участь с, приймаючи вкладений властивості цих документів JSON та створення додаткових індексів. 

Ми в кінці. Спасибі за підшипник зі мною. Отже, давайте поговоримо про Еталонна архітектура. DynamoDB сидить в середині, так більша частина інфраструктури AWS. Загалом, ви можете підключити його до всього, що ви хочете. Додатки на платформі Динамо включають Лямбда, ElastiCache, CloudSearch, передати дані з пружною в MapReduce, експорт імпорт з DynamoDB в S3, всіх видів технологічних процесів. Але, напевно, найкращий що говорити, і це те, що насправді Цікаво, коли ми говорити про додатків, керованих подіями. 

Це є прикладом Внутрішній проект що у нас є, де ми насправді видавництво, щоб зібрати результати обстеження. Таким чином, в електронного зв'язку, що ми пошлемо поза, там буде трохи посилання кажучи натисніть тут, щоб відповісти на обстеження. І коли людина натискає що посилання, що відбувається це вони тягнуть вниз безпечний HTML-форми опитування з S3. Там немає сервера. Це просто об'єкт S3. 

Ця форма підходить, завантажує в браузері. Він отримав хребта. Він отримав комплекс JavaScript що він працює. Так що це дуже багатий додаток працює в браузері клієнта. Вони не знають, що вони не взаємодіючих із заднім сервері. На даний момент, це все-браузер. 

Вони публікують результати до того, що ми називаємо Amazon API Gateway. Шлюз API це просто Web API що ви можете визначити і підключити все, що ви хочете. У даному конкретному випадку, ми підключили до лямбда-функції. 

Так мій пост операція відбувається без сервера. В основному це шлюзу API сидить там. Це не варто мені нічого, поки люди Початок публікації на нього, вірно? Функція Лямбда просто сидить там. І це не варто мені нічого, поки люди починають дубасити його. Таким чином, ви можете бачити, як обсяг збільшується, що, коли звинувачення прийшли. Я не працює сервер 7/24. 

Так що я тягнути форму вниз з відра, і я відправляю через API Шлюз в лямбда-функції. І тоді Лямбда Функція говорить, ви знаєте, те, що я отримав деякі PIIs, деякі персональна інформація в цих відповідях. Я отримав коментарі, що надходять від користувачів. Я отримав адреси електронної пошти. Я отримав імена. 

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

Так що я зробив? Я тільки що розгорнута ціла додатків і у мене немає сервера. Так що подієва додатки архітектура робить для вас. 

Тепер, якщо ви думаєте про прецедент для this-- у нас є інші клієнти я говорити щоб про це хтось точної архітектури запустити феноменально великі кампанії, які дивимося на це і відбувається, про мій. Тому що зараз, вони можуть в основному штовхати його там, нехай цю кампанію просто сидіти там, поки не запускає, а не доведеться турбуватися про фігу Яка інфраструктура буде там, щоб підтримати його. А потім, як тільки що кампанія буде зроблено, це як інфраструктури просто відразу йде тому що дійсно немає інфраструктури. Це просто код, який сидить на Lambda. Це просто дані, які сидить у DynamoDB. Це дивовижний спосіб для створення додатків. 

АУДИТОРІЯ: Так це більше, ефемерна, ніж це було б якщо він був збережений на сервері фактичної? 

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

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

АУДИТОРІЯ: Так ваш золотий коробці в середині в API шлюзу НЕ сервер, як, але замість цього просто-- 

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

РВК Хуліхеном: О, ідемпотентна? Як би змінити значення? Ну, тому що, якщо я не запустити все це шлях до кінця, то я не знаю, які зміни були зроблені в останньої милі. Це не збирається бути Ті ж дані, як те, що я побачив. АУДИТОРІЯ: О, так ти просто не отримали весь вхідний. РВК Хуліхеном: Вірно. Ви повинні йти від початку до кінця, а потім це буде послідовної державної. Прохолодний. 

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

РВК Хуліхеном: Я б не кажуть залишивши його позаду. 

АУДИТОРІЯ: Вони були відокремлені від the-- 

РВК Хуліхеном: З документа підхід, тип документа в DynamoDB просто думаю, як інший атрибут. Це атрибут, який містить ієрархічну структуру даних. А потім в запитах, Ви можете використовувати властивості з цих об'єктів з використанням Object Notation. Так що я можу фільтрувати по вкладеним властивість документа JSON. АУДИТОРІЯ: Так будь-який час я зробити документ підхід, Я можу сортувати прибути в tabular-- АУДИТОРІЯ: Абсолютно вірно. Аудиторія: --indexes і речі, які ви тільки що говорили про. РВК Хуліхеном: Так, індекси і все, що, якщо ви хочете, щоб індекс у властивості JSON, так, що ми повинні зробити це, якщо Ви вставляєте об'єкт JSON або документ в Динамо, ви повинні використовувати потоки. Потоки будуть читати ввід. Ви б отримати, що JSON об'єкт, і ви б сказати, добре, що властивість Я хочу, щоб індекс? 

Ви можете створити похідну таблицю с. Тепер це, як він працює зараз. Ми не дозволяємо індексувати безпосередньо ті властивості. 

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

РВК Хуліхеном: Рівне, сплощення це, tabularizing його, точно. Ось те, що ви з ним робити. 

АУДИТОРІЯ: Спасибо. 

РВК Хуліхеном: Так, абсолютно, спасибі. АУДИТОРІЯ: Так що це свого роду Монго відповідає Redis classifers. 

РВК Хуліхеном: Так, це багато, як, що. Це хороший опис для цього. Прохолодний.