>> [Играет музыка]
РИК Хулихэном: Ладно.
Всем привет.
Меня зовут Рик Houlihan.
Я старший основной Решения архитектор AWS.
Я сосредотачиваюсь на NoSQL и Технологии DynamoDB.
Я сегодня здесь, чтобы поговорить с Вы немного о них.
>> Мой фон в первую очередь в слое данных.
Я провел половину своей разработки Карьера писать базу данных,
доступа к данным, решения для различных применений.
Я был в Cloud виртуализации в течение примерно 20 лет.
Поэтому, прежде чем облако Облако, мы привыкли называть его полезность вычислений.
А идея была, это как PG & E, вы платите за то, что вы используете.
Сегодня мы называем это облако.
>> Но на протяжении многих лет, я работал на пару компаний
Вы вероятно никогда не слышали.
Но я составил список технических достижения, я думаю, вы бы сказать.
У меня восемь патентов в системах Cloud Виртуализация, микропроцессор дизайн,
Комплекс обработки событий, и других областях, а также.
>> Так в эти дни, я остановлюсь в основном на NoSQL технологии и новое поколение
база данных.
И это, как правило то, что я собираюсь чтобы быть здесь и разговариваю с вами сегодня о.
Так что вы можете ожидать от этой сессии,
мы пойдем через вкратце История обработки данных.
Это всегда полезно понять, откуда мы пришли
и почему мы, где мы находимся.
И мы будем говорить немного Немного о технологии NoSQL
с фундаментальной точки зрения.
>> Мы попадем в некоторых внутренности DynamoDB.
DynamoDB не AWS в не аромат.
Это полностью управляемый и серверное решение NoSQL.
И мы будем говорить немного о таблице структура, API, типы данных, индексы,
и некоторые из внутренних этой DynamoDB технологии.
Мы войдем в некоторые конструкции шаблоны и лучшие практики.
Мы поговорим о том, как использовать эту технологию для некоторых
современных приложений.
И тогда мы будем говорить немного об эволюции или появление
новой парадигмы в программировании называемые приложения управляемые событиями
и как DynamoDB играет в том, что, как хорошо.
И мы выйдем вам немного обсуждение Эталонная архитектура
таким образом, мы можем говорить о некоторых способы можно использовать DynamoDB.
>> Итак, сначала off-- это вопрос Я слышал много есть, что база данных.
Много людей думают, что они знаю, что база данных.
Если вы Google, вы увидите, что это.
Это структурированный набор данных, хранящихся в компьютере, особенно тот, который
доступен в различных направлениях.
Я полагаю, что это хороший определение современной базы данных.
Но я не люблю его, потому что это подразумевает несколько вещей.
Это означает, структуру.
И это означает, что он находится на компьютере.
И не сделал базы данных всегда существует на компьютерах.
Базы данных действительно существовал во многих отношениях.
>> Таким образом, лучшее определение База данных что-то вроде этого.
База данных организованный механизм хранения, управления,
и извлечения информации.
Это из About.com.
Так что я хотел этого, потому что это действительно переговоры о базе данных будучи хранилище,
хранилище Информация, не обязательно
то, что сидит на компьютере.
И на протяжении всей истории, мы не всегда компьютеров.
>> Теперь, если я прошу среднем Разработчик сегодня то, что
база данных, вот и ответ я получаю.
Где-то я могу придерживаться вещей.
Правильно?
И это правда.
Но это прискорбно.
Поскольку база данных действительно основа современного приложения.
Это основа из каждого приложения.
И, как вы строите, что базы данных, как структурировать
что данные будет диктовать, как это Приложение выполняет, как вы масштабе.
>> Так много моей работы сегодня имеет дело с тем, что
происходит, когда разработчики этот подход
и дело с последствиями приложения, которое
Теперь масштабирования за оригинал Цель и страдания от плохого дизайна.
Так, мы надеемся, когда вам ходьбы сегодня, вы будете
есть несколько инструментов, в Ваш пояс, который будет держать вас
от принятия тех же ошибок.
Отлично.
Итак, давайте поговорим о немного сроки технологии баз данных.
Я думаю, что я прочитал статья не так давно
и он сказал, что-то на lines-- это очень поэтично заявлении.
Это сказал, что история данных обработка
полный высоких водяных знаков изобилия данных.
ОК.
Теперь, я думаю, что это своего рода правда.
Но я на самом деле смотреть на это, как История на самом деле заполнены
с высокой водяной знак давления данных.
Поскольку скорость передачи данных проглатывание не идет вниз.
Это только идет вверх.
>> И инновации происходит, когда мы видим давление данных, который
это количество данных, которые в настоящее время в поступающей в систему.
И это не может быть обработан эффективно ни во времени, или в стоимости.
И вот, когда мы начинаем посмотреть на давление данных.
>> Поэтому, когда мы смотрим на Первая база данных, это
это тот, который был между нашими ушами.
Мы все рождены с ним.
Это хорошая база.
Он имеет высокую доступность.
Это всегда.
Вы всегда можете получить его.
>> Но это один пользователь.
Я не могу поделиться своими мыслями с вами.
Вы не можете собраться с мыслями когда вы хотите их.
И их abilitiy не так хорошо.
Мы забываем вещи.
То и дело, один из нас листья и переходит к другому существования
и мы потеряем все что было в этой базе данных.
Так что не все так хорошо.
>> И это работало хорошо в течение долгого времени когда мы были еще в день
когда все мы действительно нужно знать это куда мы идем, чтобы пойти на завтра
или там, где мы собираем лучшую еду.
Но, как мы начали расти как цивилизация и правительство начало
прийти в бытие, и бизнес начал развиваться,
мы начали понимать, мы нужно немного больше, чем
мы могли бы в нашей голове.
Отлично?
>> Нам нужна систем записи.
Нам нужно места, чтобы быть в состоянии хранить данные.
Таким образом, мы начали писать документы, создания библиотек и архивов.
Мы начали разрабатывает Система бухгалтерских книга.
И, что система подсчета бухгалтерской книги побежал мир в течение многих веков,
и, возможно, даже тысячелетий, как мы вроде выросли до точки
где, что загрузка данных превзошли способность этих систем
чтобы иметь возможность содержать его.
>> И это на самом деле произошло в 1880 году.
Правильно?
В 1880 переписи населения США.
Это действительно, где поворот указывают современной обработке данных.
Это точка, в которых объем данных
что в настоящее время, собранных Правительство США попал в точку,
где потребовалось восемь лет, чтобы обработать.
>> Теперь, восемь years-- как Вы знаете, переписи
работает каждые 10 years-- так что это Совершенно очевидно, что по времени мы
получил переписи 1890, количество данных, которые
собирался быть обработаны правительством было
собирается превышать 10 лет, что это потребуется, чтобы запустил новую переписи.
Это было проблемой.
>> Таким образом, парень по имени Герман Холлерит пришли вместе
и он изобрел блок записи удар карты, читатель перфокарты, перфокарты
табулятор, и сопоставление механизмы для этой технологии.
И, что компания, которая он сформировал на Время, вместе с парой других,
фактически стал одним из столпов небольшая компания, мы знаем сегодня называется IBM.
>> Так IBM изначально была в бизнес базы данных.
И это действительно то, что они сделали.
Они сделали обработку данных.
>> Как же так распространением удар карты, гениальный механизмы
быть в состоянии использовать что Технология опроса отсортированные результирующих наборов.
Вы можете увидеть в этой картине есть у нас есть little--
это немного small-- но вы можете видеть очень остроумный механизм механический
где у нас есть удар карточной колоды.
И кто-то берет немного отвертка
и придерживаться через Слоты и подняв ее
чтобы получить, что матч, что отсортировано набор результатов.
>> Это объединение.
Мы делаем это все время сегодня в компьютере,
где вы его в базу данных.
Мы использовали, чтобы сделать это вручную, верно?
Люди ставят эти вещи вместе.
И это было распространение из этих перфокарт
в то, что мы назвали барабанов данных и барабаны данных, бумажные ленты.
>> Обработка данных промышленности приняли урок от игроков фортепиано.
Игрок пианино назад на поворот века
использовать использовать бумажные барабаны с пазами рассказывать его, какие клавиши, чтобы играть.
Так что технологии был адаптирован в конечном итоге, чтобы сохранить цифровые данные,
потому что они могли бы поставить эти данные на те бумаги ленточных барабанов.
>> Теперь, в результате чего данные был actually-- как
доступ эти данные непосредственно был зависит от того, как вы сохранили его.
Так что, если я положил данные на ленте, Я имел доступ к данным, линейно.
Я должен был свернуть весь Лента для доступа ко всем данным.
Если я ставлю данные в удар карты, я мог бы получить доступ к его
в немного более случайным мода, может быть, не так быстро.
>> Но были ограничения в том, как мы Доступ к данным на основе, как было сохранено.
И так это было проблемой вдаваясь в 50-х.
Опять же, мы можем начать видеть, что, как мы разработка новых технологий для обработки
данные, правильно, это открывает дверь для новых решений,
для новых программ, новая приложения для этих данных.
И в самом деле, управление может быть причиной
Поэтому мы разработали некоторые из этих систем.
Но дело быстро стал водитель за эволюции
современного базе данных и современная файловая система.
>> Таким образом, следующая вещь, что подошел было в 50-х
был файловая система и Развитие случайной хранения доступа.
Это было красиво.
Теперь, все внезапно, мы можем поставить нашу файлы в любом месте на этих жестких дисков
и мы можем получить доступ к этой информации в случайном порядке.
Мы можем разобрать, что Информация из файлов.
И мы решили все в мире Проблемы с обработкой данных.
>> И длилось около 20 или 30 лет до эволюции
реляционной базы данных, которая когда мир решил, что мы в настоящее время
нужно иметь хранилище, побеждает разрастание данных по файлу
Системы, которые мы построили. Правильно?
Слишком много данных, распределенных в слишком много места, де-дублирование данных,
и стоимость хранения был огромен.
>> В 70-х, самый дорогой ресурс что компьютер был был хранения.
Процессор был рассматривать как фиксированную стоимость.
Когда я покупаю коробку, процессор делает некоторую работу.
Это собирается быть спиннинг ли это на самом деле или нет.
Это действительно понесенных расходов.
>> Но то, что стоило мне как бизнес хранения.
Если у меня есть, чтобы купить больше дисков в следующем месяц, что это реальная стоимость, что я платить.
И хранения стоит дорого.
>> Теперь мы быстро вперед 40 лет и у нас есть другая проблема.
Вычислительных теперь самый дорогой ресурс.
Хранение дешево.
Я имею в виду, мы можем пойти куда-нибудь на облако, и мы можем найти дешевое хранение.
Но то, что я не могу найти дешевый вычислительный.
>> Так эволюции сегодня технологии, технологии баз данных,
действительно сосредоточены вокруг распределенные базы данных
которые не страдают от и тот же тип шкалы
Ограничения реляционных баз данных.
Мы поговорим немного о что это на самом деле означает.
>> Но одна из причин, и водитель за this-- мы
говорили о давлении данных.
Давление данных является то, который приводит инноваций.
И если вы посмотрите на более за последние пять лет,
это схема, какие именно данные нагрузка по общей предприятия
Похоже, в последние пять лет.
>> И общее правило эти days-- если вы идете Google--
90% от данных, которые мы храним сегодня, и это было
генерируется в течение последних двух лет.
ОК.
Теперь, это не тенденция, что нового.
Это тенденция, которая была выходя за 100 лет.
С тех пор, Холлерит разработала перфокарты,
мы строили хранилища данных и сбор данных на феноменальные темпы.
>> Так, за последние 100 лет, мы видели эту тенденцию.
Это не собирается менять.
Продвигаясь вперед, мы будем видеть это, если не ускоряется тенденция.
И вы можете видеть, как это выглядит.
>> Если бизнес в 2010 году был один терабайт данных под управлением,
сегодня это означает, что они управление 6,5 петабайт данных.
Это 6500 раз больше данных.
И я знаю, что это.
Я работаю с этими предприятиями каждый день.
Пять лет назад я будет говорить с компаниями
кто бы поговорить со мной о чем боль это управлять терабайтами данных.
И они будут говорить мне о том, как мы видим,
что это, вероятно, будет быть петабайт или два
в течение нескольких лет.
>> Эти же компании сегодня я встречаюсь с,
и они говорят мне о Проблема есть ли имеющий управление
десятки, 20 петабайт данных.
Так взрыв Данные в промышленности
ведет огромная потребность в более совершенных решений.
И реляционная база данных является просто не жить до спроса.
>> И так есть линейный Корреляция между давлением данных
и технические инновации.
История показывает нам, это, что с течением времени,
всякий раз, когда объем данных который должен быть обработан
превышает пропускную способность системы обработать его в разумные сроки
или по разумной цене, то новые технологии
изобретены, чтобы решить эти проблемы.
Эти новые технологии, в свою очередь, открыть дверь
на другой набор проблем, который собирает еще больше данных.
>> Теперь, мы не собираемся останавливаться на этом.
Правильно?
Мы не собираемся останавливаться на этом.
Зачем?
Потому что вы не можете знать все что нужно знать во Вселенной.
И до тех пор, как мы были живы, на протяжении всей истории человека,
мы всегда вынуждены знать больше.
>> Так кажется, что каждый дюйм мы движемся по пути научного открытия,
мы умножения количества данных что мы должны обработать по экспоненте
как мы раскрыть больше и больше и больше о внутренних жизни,
о том, как работает Вселенная, о вождение научное открытие,
и изобретение, что мы делаем сегодня.
Объем данных, просто постоянно увеличивается.
Так будучи в состоянии иметь дело с Эта проблема огромна.
>> Так одна из вещей, мы смотрим, как, почему NoSQL?
Как NoSQL решить эту проблему?
Ну, реляционные базы данных, Structured Query Language,
SQL--, что это действительно конструкция из реляционная database-- эти вещи
оптимизирована для хранения.
>> Назад в 70-е годы, опять же, Диск стоит дорого.
О подготовке упражнения хранения на предприятии никогда не заканчивается.
Я знаю.
Я жил его.
Я написал драйвер хранилища для enterprised суперсервера компания
назад в 90-ых.
И нижняя линия стеллажи другой Массив хранения данных была только то, что
произошло каждый день на предприятии.
И это никогда не остановился.
Высшее хранения плотность, спрос за большой плотности хранения,
и для более эффективного хранения devices-- это никогда не остановился.
>> И NoSQL это отличный технология потому что он нормализует данные.
Это де-дублирует данные.
Это помещает данные в структуру, которая агностик каждому модель доступа.
Несколько приложений могут ударить, что Базы данных SQL, запустить специальные запросы,
и получить данные в форме, что они нужно обработать для их рабочих нагрузок.
Это звучит фантастически.
Но суть в том, с какой-либо Система, если это агностик, чтобы все,
он оптимизирован для ничего.
ОК?
>> И это то, что мы получаем с реляционная база данных.
Он оптимизирован для хранения.
Это нормализуется.
Это реляционная.
Он поддерживает специальные запросы.
И его и масштабирует его по вертикали.
>> Если мне нужно, чтобы получить большую базу данных SQL или более мощный SQL базы данных,
Я иду купить больший кусок железа.
ОК?
Я работал со многими клиентов что прошли через крупные обновления
в их SQL инфраструктуры только чтобы выяснить, шесть месяцев спустя,
они опять вы удара в стену.
И ответ от Oracle или MSSQL или кто-нибудь еще, это получить больше окно.
Ну, рано или поздно, вы не можете купить больше окно, и это реальная проблема.
Мы должны на самом деле что-то изменить.
Так где же это работает?
Он хорошо работает в автономном аналитика, нагрузки OLAP-типа.
И это действительно, где SQL принадлежит.
Теперь, он используется сегодня во многих онлайн обработку транзакций типа
Приложения.
И это прекрасно работает на определенный уровень утилизации,
но это просто не масштабировать так, что NoSQL делает.
И мы будем говорить немного немного о том, почему, что есть.
>> Теперь, NoSQL, с другой стороны, более оптимизирован для вычислений.
ОК?
Это не независимым от шаблон доступа.
Это то, что мы называем де-нормализуется структура или иерархическую структуру.
Данные в реляционной базе данных объединились с несколькими столами
производить вид, что вам нужно.
Данные в базе данных NoSQL в хранится в документе, который
содержит иерархическую структуру.
Все данные, которые обычно объединились, чтобы произвести эту точку зрения
хранятся в одном документе.
И мы будем говорить немного о как это работает в паре графиков.
>> Но идея здесь в том, что вы храните Ваши данные как эти экземпляры видом.
ОК?
Вы масштабировать по горизонтали.
Правильно?
Если мне нужно увеличить Размер моего NoSQL кластера,
Мне не нужно, чтобы получить большую коробку.
Я получаю еще одну коробку.
И я их вместе кластер, и я могу шарда эти данные.
Мы поговорим немного о то, что Sharding есть, быть
возможность масштабирования эту базу данных по нескольким физическим устройствам
и удалить барьер, требует, чтобы я масштабирования по вертикали.
>> Так что на самом деле построен для онлайн обработки транзакций и масштаб.
Там большая разница здесь между отчетности, верно?
Отчетность, я не знаю, вопросы, которые я собираюсь задать.
Правильно?
Reporting-- если кто-то из мой отдел маркетинга
хочет просто-- сколько из моих клиентов есть эта конкретная характеристика, кто
купил в этом day-- я не знаю то, что запрос они собираются спросить.
Поэтому мне нужно, чтобы быть агностиком.
>> Теперь, в режиме онлайн транзакционных приложений,
Я знаю, какие вопросы я спрашиваю.
Я построил приложение для очень специфический рабочий процесс.
ОК?
Так что, если оптимизировать данные хранить в поддержку этого рабочего процесса,
это будет быстрее.
И вот почему NoSQL может действительно ускорить доставку
из этих видов услуг.
Отлично.
>> Итак, мы собираемся, чтобы попасть в немного теории здесь.
И некоторые из вас, ваши глаза может вернуться немного.
Но я постараюсь, чтобы сохранить его также высокий уровень, как я могу.
Так что, если вы находитесь в проекте Управление, есть
конструкция называется треугольник ограничений.
ОК.
Треугольник ограничивает диктата Вы не можете иметь все все время.
Не можете иметь свой пирог и съесть его слишком.
Таким образом, в управлении проектами, что треугольник ограничения, что вы можете иметь это дешево,
Вы можете иметь это быстро, или вы можете иметь его хорошо.
Выбери два.
Потому что вы не можете иметь все три.
Правильно?
ОК.
>> Таким образом, вы слышите об этом много.
Это тройной ограничение, треугольник тройной ограничения,
или железный треугольник является oftentimes-- когда вы говорите с менеджерами проекта,
они будут говорить об этом.
Теперь, базы данных имеют самостоятельно железный треугольник.
И железный треугольник данных это то, что мы называем Теорема CAP.
ОК?
>> Теорема CAP диктует как базы данных работают
под очень специфических условиях.
И мы будем говорить о что это условие.
Но три точки треугольника, так сказать, являются С, консистенция.
ОК?
Таким образом, в САР, согласованность означает, что все клиенты, которые могут получить доступ к базе данных
всегда будет иметь очень соответствует представление данных.
Никто не собирается увидеть две разные вещи.
ОК?
Если я вижу, базы данных, Я вижу то же самое представление
как мой партнер, который видит ту же базу данных.
Вот последовательность.
>> Наличие означает, что если онлайн базы данных, если это может быть достигнуто,
что все клиенты будут всегда уметь читать и писать.
ОК?
Так каждый клиент, который может читать базу данных
всегда смогут чтения Данные данных и писать.
И если это так, это доступный система.
>> И третий пункт, что мы называем терпимости разделов.
ОК?
Означает терпимость раздел что система работает хорошо
несмотря физической сети Перегородки между узлами.
ОК?
Так узлы в кластере не может говорить друг с другом, что происходит?
Отлично.
>> Так реляционные базы данных, выберите-- Вы можете выбрать два из них.
ОК.
Так реляционные базы данных выберите быть последовательным и доступны.
Если раздел происходит между в узлы DataNode в хранилище данных,
сбой базы данных.
Правильно?
Это просто идет вниз.
ОК.
>> И вот почему они имеют расти с большими ящиками.
Правильно?
Потому что, как правило, no--, кластер базы данных, есть не очень многие из них
которые работают таким образом.
Но большинство баз данных масштаба по вертикали в одном окне.
Потому что они должны быть последовательной и доступен.
Если раздел были быть введен, то вам придется сделать выбор.
Вы должны сделать выбор между быть последовательным и доступны.
>> И это то, что делают базы данных NoSQL.
Отлично.
Таким образом, база данных NoSQL, его поставляется в двух вариантах.
Мы have-- хорошо, это приходит во многих разновидностях,
но он приходит с двумя основными characteristics-- что
мы называем CP базы данных или последовательной и раздел толерантности
Система.
Эти ребята делают выбор, что, когда узлы теряют контакт друг с другом,
мы не собираемся, чтобы позволить люди больше писать.
ОК?
>> До этого раздела не будут удалены, записи доступ заблокирован.
Это означает, что они не доступны.
Они последовательны.
Когда мы видим, что раздел придать себе,
мы теперь соответствует, потому что мы не собираемся
чтобы изменения данных на два стороны перегородки самостоятельно
друг от друга.
Мы должны будем восстановить связь
перед любым обновлением данные позволили.
ОК?
>> На следующий аромат будет система А.П., или доступный и распределяют
Система допуска.
Эти ребята не волнует.
Правильно?
Любой узел, который получает писать, мы возьмем его.
Так что я тиражирование мои данные по нескольким узлам.
Эти узлы получить клиент, клиент приходит в, говорит, что я собираюсь написать некоторые данные.
Узел не говорит, не проблема.
Узел рядом с ним получает от записи на той же записи,
он собирается сказать не проблема.
Где-то на заднем конце, что данные собирается повторить.
А потом кто-то собирается реализовать, э-э-о, они поймут, система, э-э-о,
там было обновление до двух сторон.
Что мы делаем?
И то, что они сделать, это они делают то, что
позволяет им решить эту состояние данных.
И мы будем говорить о что в следующем графике.
>> Вещь, чтобы отметить здесь.
И я не собираюсь слишком много в этом, потому что это
попадает в глубокой теории данных.
Но есть транзакций рамки,
работает в реляционной системе, позволяет мне смело сделать обновления
нескольким субъектам в базе данных.
И эти обновления будут происходить все сразу или не на всех.
И это называется ACID транзакций.
ОК?
>> КИСЛОТА дает нам атомарность, согласованность, изоляция и долговечность.
ОК?
Это означает, что атомные, сделки, все мои обновления либо случится, либо нет.
Согласованность означает, что База данных будет всегда
быть приведены в последовательной состояние после обновления.
Я никогда не оставит базу данных в плохое состояние после применения обновления.
ОК?
>> Так что это немного отличается чем консистенции CAP.
Консистенция CAP означает, что все мои клиенты всегда могут видеть данные.
КИСЛОТА согласованность означает, что, когда сделка будет сделано, данные хорошо.
Мои отношения все хорошо.
Я не собираюсь, чтобы удалить родительскую строку и оставить кучу детей-сирот
В какой-то другой таблицы.
Это не может произойти, если я согласуются в кислой операции.
>> Изоляция означает, что сделки всегда будет происходить один за другим.
Конечным результатом данных будет то же самое состояние
а если этих сделок которые были выпущены одновременно
были выполнены последовательно.
Так что это параллелизм контроль в базу данных.
Так в принципе, я не могу увеличить то же самое значение в два раза с двумя операциями.
>> Но если я говорю добавить 1 к этому значению, и две сделки приходят в
и попытаться сделать это, один это собирается получить там первым
а другой-х собирается попасть после.
Таким образом, в конце концов, я добавил два.
Вы видите, что я имею в виду?
ОК.
>> Прочность довольно проста.
Когда сделка признается, что это
будет там, даже если сбой системы.
При том, что система восстанавливается, что сделка, было совершено
на самом деле происходит, чтобы быть там.
Так вот гарантии кислоты сделок.
Те, довольно хорошие гарантии иметь в базе данных,
но они приходят на той стоимости.
Правильно?
>> Потому что проблемы с этим база
если существует разбиение данных в набор, я должен принять решение.
Я собираюсь иметь, чтобы Обновления на одной или другой стороны.
И если это произойдет, не то я не собираюсь больше
чтобы быть в состоянии поддерживать эти характеристики.
Они не будут соответствовать.
Они не будут изолированы.
Это где это ломает для реляционных баз данных.
Это причина, реляционная Базы данных масштабирования по вертикали.
>> С другой стороны, мы имеем то, что называется технологическая база.
И это ваши NoSQL баз данных.
Отлично.
Таким образом, мы имеем CP, базы данных AP.
И это то, что вы называете основном доступны, мягкий государство, в конечном счете,
последовательным.
ОК?
>> В основном доступны, потому что они раздел терпимо.
Они всегда будут там, даже если есть
разделения сети между узлами.
Если я могу поговорить с узлом, я будет в состоянии прочитать данные.
ОК?
Я не всегда может быть в состоянии написать данных, если я единой платформы.
Но я буду в состоянии прочитать данные.
>> Мягкая состояние указывает что, когда я прочитал, что данные,
она не может быть такой же, как другие узлы.
Если право было выдано на узле где-то в кластере
и это не реплицируются поперек Кластер же, когда я прочитал, что данные,
что государство не может быть последовательным.
Тем не менее, он будет в конце концов последовательным,
Это означает, что, когда записи сделан к системе,
он будет реплицировать узлов.
И в конце концов, что государство будут приведены в порядок,
и это будет соответствовать состояние.
>> Теперь, теорема CAP действительно играет только в одном состоянии.
Это условие, когда это произойдет.
Потому что всякий раз, когда он работает в нормальный режим, нет раздела,
все в последовательной и доступны.
Вы только беспокоиться о CAP когда у нас есть этот раздел.
Так что те, редки.
Но, как система реагирует, когда те происходят диктовать, какой тип системы
мы имеем дело с.
>> Итак, давайте взглянем на то, что который выглядит как для АТ систем.
ОК?
Системы AP бывают двух видов.
Они приходят в аромате, который является Мастер, 100%, всегда доступны.
И они приходят в другой аромат, который говорит
Вы знаете, что я собираюсь беспокоиться об этом разделов вещи
когда фактический раздел происходит.
В противном случае, там будет основным узлы, которые собирается предпринять прав.
ОК?
>> Так что, если мы что-то вроде Кассандры.
Кассандра бы быть мастером мастер, давайте мне написать к любому узлу.
Так что же происходит?
Так у меня есть объект в База данных, существует на двух узлов.
Назовем этот объект S. Итак, мы имеем состояние для S.
У нас есть некоторые операции на S, что продолжаются.
Кассандра позволяет мне написать нескольким узлам.
Так что давайте говорить, что я получаю писать для с двумя узлами.
Ну, то, что в конечном итоге происходит это мы называем это событие разделов.
Там не может быть физическая сеть разделов.
Но из-за дизайна системы, это
на самом деле, как только разбиения как я получить запись на двух узлах.
Это не заставляет меня написать все через один узел.
Я пишу на двух узлах.
ОК?
>> Так что теперь у меня есть два состояния.
ОК?
Что должно случиться рано или поздно,
там будет событие репликации.
Там будет то, что мы называется раздел восстановления, который
где эти два государства вернуться вместе
и там будет алгоритм который работает в базе данных,
решает, что делать.
ОК?
По умолчанию, последнее обновление выигрывает в большинстве систем AP.
Так что, как правило, Алгоритм по умолчанию, то, что
они называют функцию обратного вызова Функция, то, что
будет вызываться, когда это условие обнаружено выполнить некоторую логику
решить, что конфликта.
ОК?
Обратный вызов по умолчанию и по умолчанию распознаватель в большинстве баз данных AP
это, думаю, что, метка выигрывает.
Это было последнее обновление.
Я собираюсь поставить это обновление там.
Я могу сбросить эту запись, что я сбрасывали прочь в журнале восстановления
так что пользователь может вернуться позже и сказать, эй, произошло столкновение.
Что случилось?
И вы можете сбросить запись все столкновения и откаты
и посмотреть, что происходит.
>> Теперь, как пользователь, вы можете также включать в себя логику в этой обратного вызова.
Таким образом, вы можете изменить обратного вызова операции.
Вы можете сказать: эй, я хочу для устранения этой информации.
И я хочу, чтобы попытаться объединить эти две записи.
Но это до вас.
База данных не знаю, как сделать, что по умолчанию. Большинство времени,
единственное, что базы данных знает, как сделать, это сказать,
этот был последний альбом.
Это тот, который собирается выиграть, и это значение я собираюсь ставить.
После этого восстановления разделов и репликации,
у нас есть государство, которое Теперь S премьер, который является
слияние состояние всех этих объектов.
Так системы AP есть это.
Системы CP не нужно чтобы беспокоиться об этом.
Потому что как только приходит раздел в игру, они просто перестать принимать
пишет.
ОК?
Так что это очень легко дело с быть последовательным
когда вы не принимать какие-либо обновления.
Вот с системами CP сделать.
Отлично.
>> Итак, давайте немного поговорим немного о моделях доступа.
Когда мы говорим о NoSQL, это все о модели доступа.
Теперь, в SQL есть специальная запросы.
Это реляционное хранилище.
Мы не должны волноваться о модели доступа.
Я пишу очень сложный запрос.
Это идет и получает данные.
Это то, что это выглядит как нормализация.
>> Таким образом, в данном конкретном структуры, мы смотрим на каталог продукции.
У меня есть различные виды продукции.
У меня есть книги.
Я есть альбомы.
У меня есть видео.
Отношения между продуктами и любой из этих книг, альбомов,
и видео столы 1: 1.
Отлично?
Я получил код продукта, и что соответствует ID
в книге, альбом или видео.
ОК?
Это отношение 1: 1 по этим таблицам.
>> Теперь, все они books-- есть, корень свойства.
Нет проблем.
Замечательно.
Один-к-одному отношения, я все данные мне нужно, чтобы описать эту книгу.
Albums-- альбомы треки.
Это то, что мы называем один ко многим.
Каждый альбом может иметь много дорожек.
Таким образом, для каждого трека на альбом, я мог бы
еще один рекорд в этой дочерней таблицы.
Так что я создать одну запись в мои альбомы таблице.
Я создаю несколько записей в таблице треков.
Один-ко-многим.
>> Это соотношение является то, что мы называем многие-ко-многим.
ОК?
Вы видите, что актеры могли быть во многих фильмах, много видео.
Так что мы делаем, мы ставим это отображение Таблица между теми, которые он просто
отображает актер идентификатор видео ID.
Теперь я могу создать запрос к соединяет видео через актера видео на актеров,
и это дает мне хороший список все фильмы и все актеры
которые были в этом фильме.
>> ОК.
Так вот мы идем.
Один-к-одному это топ-уровень отношения; один ко многим,
альбомы для дорожек; многие-ко-многим.
Таковы три верхнего уровня отношения в любой базе данных.
Если вы знаете, как те, отношения работать вместе,
то вы знаете, много о базе данных уже.
Так NoSQL работает немного по-другому.
Давайте думать о на секунду, что это Похоже, пойти получить все мои продукты.
>> В реляционной магазине, я хочу, чтобы получить все мои продукты
в списке всех моих продуктах.
Это много запросов.
Я получил запрос для всех моих книг.
Я получил запрос от моих альбомов.
И я получил запрос для всех моих видео.
И я получил поставить его все вместе в списке
и служить его обратно к приложения, которое запрашивает его.
>> Чтобы получить мои книги, я присоединяюсь Продукты и книг.
Чтобы получить мои альбомы, меня присоединиться Продукты, Альбомы, и треки.
И чтобы мои видео, у меня есть присоединиться к видео продукты,
присоединиться через Актер видео, и принести в Актеры.
Так вот три запроса.
Очень сложные запросы к собрать один результирующий набор.
>> Это меньше, чем оптимальна.
Вот почему, когда мы говорим о структуре данных, что это
построен, чтобы быть независимым от доступа pattern-- хорошо, что это здорово.
И вы можете видеть это на самом деле приятно, как мы организовали данные.
И вы знаете, что?
У меня есть только одна запись для актера.
>> Это круто.
Я дедуплицированы все мои актеры, и я поддерживал мои ассоциации
В этой таблице отображения.
Однако, получение данных вне становится дороже.
Я посылаю процессор всей системе соединяющий эти структуры данных вместе
чтобы быть в состоянии осуществить это обратно данных.
>> Так как я могу получить вокруг этого?
В NoSQL это о агрегации, не нормализация.
Таким образом, мы хотим сказать, что мы хотим поддержки доступа к файлу.
Если модель доступа к приложениям,
Мне нужно, чтобы получить все мои продукты.
Давайте положить все продукты в одной таблице.
Если я ставлю все продукты в одной таблице, Я могу просто выбрать все продукты
из этой таблицы, и я получаю все это.
Ну, как я могу это сделать?
Ну в NoSQL нет никакого Структура к столу.
Мы поговорим немного о как это работает в Динамо БД.
Но вы не должны то же самое атрибуты и те же свойства
в каждой строки, в каждый Пункт, как вы делаете в таблице SQL.
И то, что это позволяет мне сделать много вещей,
и дать мне много гибкости.
В данном конкретном случае, я мои документы продукта.
И в этом конкретном Например, все
это документ, в таблице Products.
И продукт для книги может есть тип ID, который определяет книгу.
И применение хотел бы перейти на тот ID.
>> В уровне приложений, я собираюсь сказать ах, какой тип записи это?
О, это книжка.
Забронируйте записи имеют эти свойства.
Позвольте мне создать объект книги.
Так что я собираюсь, чтобы заполнить Книга объект с этим пунктом.
Следующий товар приходит и говорит, что этот пункт?
Ну этот элемент является альбом.
О, я получил совершенно другой процедуры обработки для того,
потому что это альбом.
Вы видите, что я имею в виду?
>> Таким образом, применение tier-- я просто выделите все эти записи.
Они все начинают приходить в.
Они могут быть все различные типы.
И это логика приложения который переключается между этими типами
и решает, как их обработать.
>> Опять же, так что мы оптимизируя Схема для шаблона доступа.
Мы делаем это с помощью рушится эти таблицы.
Мы в основном принятия эти нормированные структуры,
и мы строим иерархические структуры.
Внутри каждого из этих записей Я собираюсь просмотреть свойства массива.
>> Внутри этого документа Альбомы, Я вижу массивы треков.
Эти треки Теперь become-- это в основном это ребенок таблица,
существует прямо здесь, в этой структуре.
Таким образом, вы можете сделать это в DynamoDB.
Вы можете сделать это в MongoDB.
Вы можете сделать это в любой базе данных NoSQL.
Создать эти типы иерархические структуры данных
которые позволяют вам получить данные очень быстро, потому что теперь я
не должны соответствовать.
Когда я вставить строку в Tracks стол, или ряд в таблице Альбомы,
Я должен соответствовать этой схеме.
Я должен иметь атрибут или тому имущество, определенного в данной таблице.
Каждый из них, когда я вставляю эту строку.
Это не тот случай в NoSQL.
>> Я могу иметь совершенно разные свойства в каждом документе
что я вставить в коллекции.
Итак, очень мощный механизм.
И это действительно, как вы оптимизации системы.
Потому что теперь вместо запроса, присоединения все эти таблицы
и выполнение полдюжины запросов отступить данные мне нужно,
Я выполнении одного запроса.
И я итерации по результатам установленных.
это дает вам представление о силе NoSQL.
Я собираюсь рода выйти боком здесь и немного поговорим об этом.
Это больше, вид из маркетинг или technology--
маркетинг технологии тип дискуссии.
Но важно понимать, потому что, если мы посмотрим на вершине
здесь, на этом графике, то, что мы смотрим на
это то, что мы называем Технология обмана кривой.
И то, что это означает, Новый материал вступает в игру.
Люди думают, что это здорово.
Я решил все мои проблемы.
>> Это может быть конец все, все будет все.
И они начинают использовать его.
И говорят они, этот материал не работает.
Это неправильно.
Старая материал был лучше.
И они возвращаются к выполнению вещи, как они были.
И тогда в конечном счете они идут, вы знаете, что?
Этот материал не так уж плохо.
О, как это работает.
И как только они выяснить, как это Работы, они начинают все лучше.
>> И самое смешное об этом есть, вид линий до того, что
мы называем кривой принятия технологии.
Так что же происходит у нас есть своего рода технология запуска.
В случае баз данных, это давление данных.
Мы говорили о высоких точек воды давления данных в течение времени.
При том, что давление данные парад определенная дело, что это технология запуска.
>> Это становится слишком дорого.
Это занимает слишком много времени, чтобы обработать данные.
Мы должны что-то лучше.
Вы новаторов там бегают,
пытаясь выяснить, что это решение.
Что новая идея?
>> Что следующая лучшая способ сделать это?
И они приходят с чем-то.
И люди с реальной боли, ребята на переднем крае,
они буду прыгать над ним, потому что они должны ответить.
Теперь то, что неизбежно и happens-- это происходит сейчас в NoSQL.
Я вижу все это время.
>> Что неизбежно происходит люди начинают использовать новый инструмент
так же, как они использовали старый инструмент.
И они это выяснить не работает так хорошо.
Я не могу вспомнить, кто я говорить с ранее сегодня.
Но это, как, когда отбойный молоток был изобретен,
люди не качать его на их головы, чтобы разбить бетон.
>> Но это то, что происходит с NoSQL сегодня.
Если вы ходить в большинстве магазинов, они пытаются быть NoSQL магазины.
То, что они делают, является они используют NoSQL,
и они загрузкой полный реляционной схеме.
Потому что, как они проектировать базы данных.
И они интересно, почему не выполняя очень хорошо?
Мальчик, эта вещь пахнет.
Я должен был поддерживать все мои присоединяется in-- это как, нет, нет.
Поддержание присоединяется?
Почему вы присоединения данных?
Вы не объединять данные в NoSQL.
Вы агрегировать его.
>> Так что, если вы хотите, чтобы избежать этого, узнать как инструмент работает прежде чем вы действительно
начать использовать его.
Не пытайтесь использовать новые Инструменты так же, как вы использовали старые инструменты.
Вы будете иметь плохой опыт.
И каждый раз, это то, что это о.
Когда мы начинаем придумывать здесь, это потому, что люди выяснили,
как использовать инструменты.
>> Они сделали то же самое, когда реляционные базы данных были изобретены,
и они были замены файловых систем.
Они пытались построить файловых систем с реляционными базами данных
потому что это то, что люди поняли.
Это не работает.
Таким образом, понимание лучшие практики технологии вы работаете с
огромный.
Очень важно.
>> Итак, мы собираемся, чтобы попасть в DynamoDB.
DynamoDB является AWS-х полностью управляемого платформу NoSQL.
Что полностью управляемого в виду?
Это означает, что вы не должны действительно ни о чем беспокоиться.
>> Вы приходите, вы скажите нам, мне нужно таблицу.
Это нуждается в этом больше мощности.
Вы нажмете кнопку, и мы предоставление вся инфраструктура за сценой.
Теперь, огромен.
>> Потому что, когда вы говорите о масштабировании базы данных,
Кластеры данных NoSQL в масштаб, ходовые петабайт,
работает миллионы транзакций в секунду,
эти вещи не малые кластеры.
Мы говорим тысячи экземпляров.
Управление тысячи экземпляров, даже виртуальные экземпляры,
это реальная боль в заднице.
Я имею в виду, думать о каждый раз Операционная система выходит патч
или новой версии базы данных.
Что это значит Вам оперативно?
Это означает, что вы получили 1200 серверы, которые должны быть обновлены.
Теперь даже с автоматизацией, что может занять длительное время.
Это может вызвать много оперативные головные боли,
потому что я, возможно, услуги вниз.
>> Как мне обновить эти базы данных, я может сделать голубые зеленые развертывания
где я развертывания и обновления половины моего узлы, а затем обновить другую половину.
Возьмите те вниз.
Так управления инфраструктурой Шкала является чрезвычайно болезненным.
И AWS принять эту боль из него.
И базы данных NoSQL может чрезвычайно болезненным будет
из-за, как они масштабирования.
>> Масштаб по горизонтали.
Если вы хотите, чтобы получить большую NoSQL базы данных, вы покупаете больше узлов.
Каждый узел вы покупаете другой операционный головная боль.
Итак, давайте кто-то сделает это за вас.
AWS может это сделать.
>> Мы поддерживаем значения ключевых документов.
Теперь мы не пошли слишком много в другой диаграмме.
Там много разных ароматы NoSQL.
Они все виды получать потеряются вместе в этой точке.
Вы можете посмотреть на DynamoDB и сказать да, мы оба документа и значение ключа
хранить эту точку.
И вы можете утверждать, особенности одного над другим.
Для меня, много это действительно шесть одного полдюжины другого.
Каждый из этих технологий является точная технология и штраф решение.
Я бы не сказал, что MongoDB лучше или хуже, чем диване, то Кассандры,
то Динамо, или наоборот.
Я имею в виду, это всего лишь варианты.
>> Это быстро, и это соответствует в любом масштабе.
Таким образом, это является одним из крупнейших бонусы вы получаете с AWS.
С DynamoDB является способность чтобы получить низкую одну цифру
Задержка миллисекунду в любом масштабе.
Это было целью дизайна системы.
И у нас есть клиенты, которые делают миллионы транзакций в секунду.
>> Теперь я пойду через некоторые из тех, случаи использования в течение нескольких минут здесь.
Встроенный control-- доступ мы имеем то, что мы называем
Идентичность Управление доступом, или IAM.
Она пронизывает все системы, каждый сервис, который предлагает AWS.
DynamoDB не является исключением.
Вы можете контролировать доступ к таблицам DynamoDB.
Через все ваши AWS составляет от определение роли и разрешения доступа
в IAM инфраструктуры.
>> И это ключевой и неотъемлемой составляющей что мы называем Event Driven программирования.
Теперь это новая парадигма.
>> АУДИТОРИЯ: Как ваша скорость верно Положительных против ложных негативов
на системы контроля доступа?
РИК Хулихэном: True срабатываний по сравнению с ложноотрицательных?
АУДИТОРИЯ: Возвращаясь что Вы должны возвращаться?
В отличие от раз в то время он не вернуться, когда он должен проверить?
>> РИК Хулихэном: Я не мог сказать вам, что.
Если есть какие-либо сбои бы то ни было, что,
Я не тот человек, чтобы спросить что конкретный вопрос.
Но это хороший вопрос.
Я бы любопытно узнать, что я, на самом деле.
>> И так, опять же, новая парадигма это событийная программирования.
Это идея, что вы можете развернуть сложных приложений, которые
может работать очень, очень высокий масштаб без инфраструктуры бы то ни было.
Без жесткого Инфраструктура бы то ни было.
И мы будем говорить немного о том, что это означает, что, как мы
получить на следующей пары карт.
>> Первое, что мы сделаем что мы будем говорить о таблицах.
Типы данных API для Динамо.
И первое, что вы будете заметил, когда вы смотрите на это,
если вы знакомы с любой базой данных, Базы данных действительно два вида интерфейсов
Я бы назвал это.
Или два комплекта API.
Один из тех, будет API управления.
>> Вещи, которые они принимают на себя функции базы данных.
Настройка механизма хранения, создание и добавление таблиц.
создание базы данных каталоги и примеры.
Они things-- в DynamoDB, вы имеют очень короткие, короткие списки.
>> Таким образом, в других базах данных, Вы могли бы видеть десятки
из команды, административно Команды, для конфигурирования
эти дополнительные опции.
В DynamoDB вам не нужно, потому что те, Вы не настраивать систему, мы делаем.
Так что единственное, что вам нужно сделать, это скажи мне, что размер таблицы мне нужно.
Таким образом, вы получаете очень ограниченный набор команд.
>> Вы получаете Create Table Update, Настольный, Удалить таблицу и описать таблицу.
Это единственные вещи, что нужно для DynamoDB.
Вам не нужно хранилище конфигурация двигателя.
Мне не нужно беспокоиться о репликации.
Мне не нужно беспокоиться о шардинге.
>> Я не нужно беспокоиться о любом из этого материала.
Мы делаем все это для вас.
Так что это огромное количество накладных расходов что просто поднял свой пластину.
Тогда у нас есть операторы CRUD.
CRUD-то, что мы позвоните в базе данных, что это
Создание, обновление, удаление операторов.
Это ваш общий операции с базами данных.
Такие вещи, как положить деталь, получаете деталь, обновление предметы, удалять элементы, партия запросов, сканирование.
Если вы хотите, чтобы сканировать всю таблицу.
Потяните все со стола.
Одна из приятных вещей о DynamoDB это позволяет параллельное сканирование.
Так что вы можете на самом деле, дайте мне знать, сколько темы вы хотите, чтобы работать на этой сканирования.
И мы можем запустить эти темы.
Мы можем спина, что сканировать до по нескольким потокам
так что вы можете сканировать всю таблицу пространство очень, очень быстро в DynamoDB.
>> Другой API мы имеем то, что мы называем нашим Потоки API.
Мы не собираемся говорить слишком много об этом прямо сейчас.
Я получил некоторое содержание позже на палубе в об этом.
Но Потоки действительно running-- думаю о нем, как приказал раз
и изменение разделов журнала.
Все, что происходит на таблица показывает вверх в потоке.
>> Каждый написать в таблице Выставки на поток.
Вы можете прочитать, что поток, и Вы можете делать вещи, с ним.
Мы будем говорить о том, что типы вещей, которые вы
делать с вещами, как репликация, создание вторичных индексов.
Все виды действительно здорово вещи, которые вы можете сделать с этим.
>> Типы данных.
В DynamoDB, мы поддерживаем оба ключа значение и документ типы данных.
На левой стороне экрана здесь, мы получили наши основные типы.
Основные типы значений.
Эти строки, цифры и исполняемые файлы.
>> Так всего за три основных типа.
И тогда вы можете иметь наборы из них.
Одна из приятных вещей о NoSQL это Вы можете содержать массивы в качестве свойств.
И с DynamoDB можно содержать массивы основных типов, как корневой собственности.
>> А тут еще типы документов.
Сколько людей знакомы с JSON?
Вы, ребята, знакомые с JSON так много?
Это в основном JavaScript, Объект, Обозначения.
Это позволяет в основном определяют иерархическую структуру.
>> Вы можете хранить документ в формате JSON на DynamoDB использованием общих компонентов
или блоков, которые доступны в большинстве языков программирования.
Так что, если у вас есть Java, вы глядя на карты и списки.
Я могу создать объекты, которые Карта зоны.
Карта, как ключевых ценностей хранятся в качестве свойств.
И это, возможно, есть списки значения в пределах этих свойств.
Вы можете хранить этот комплекс иерархическая структура
как одного атрибута из пункта DynamoDB.
>> Так таблиц в DynamoDB, как и большинство Базы данных NoSQL, столы есть пункты.
В MongoDB вы бы называть эти документы.
И это будет диван базы.
Также база данных документов.
Вы называете эти документы.
Документы или детали имеют атрибуты.
Атрибуты могут существовать или не существует по этому пункту.
В DynamoDB, есть один обязательный атрибут.
Так же, как в реляционной базе данных, у вас есть первичный ключ на столе.
>> DynamoDB имеет то, что мы называем хэш-ключ.
Хэш ключ должен быть уникальным.
Поэтому, когда я определить хэш-таблицу, в основном то, что я говорю,
является каждый элемент будет иметь хэш-ключ.
И каждый хэш-ключ должен быть уникальным.
>> Каждый элемент определяется этой уникальной хеш-ключа.
А может быть только один.
Это нормально, но часто что нужно людям
они хотят это хэш Ключ к делать немного больше
чем просто быть уникальным идентификатором.
Часто мы хотим, чтобы использовать эту хэш-ключ в качестве верхнего уровня агрегации ведро.
И то, как мы делаем, что является добавив, что мы называем ключ диапазона.
>> Так что, если это только хеш- стол, это должно быть уникальным.
Если это хэш и диапазон стол, Сочетание хэша и диапазона
Должно быть уникальным.
Так что подумайте об этом таким образом.
Если у меня есть форум.
И форма имеет темы, он имеет должности, и она имеет ответов.
>> Так что я, возможно, хэш ключ, который является темой ID.
И я мог бы иметь ключ диапазон, который является ответом ID.
Таким образом, если я хочу, чтобы все ответы для конкретной теме,
Я могу только запрос хэш.
Я могу только сказать, мне все дают предметы, имеющие этот хэш.
И я иду, чтобы получить каждый вопрос или разместить на этой конкретной теме.
Эти главные скопления уровня очень важны.
Они поддерживают основной доступ Характер применения.
Вообще говоря, это это то, что мы хотим сделать.
Мы хотим, чтобы table-- как вы загрузить таблицу,
мы хотим, чтобы структурировать данные в таблице таким образом,
что приложение может очень быстро получить эти результаты.
И часто способ сделать это для поддержания этих агрегатов, как мы
вставить данные.
В принципе, мы распространения данных в светлое ведро, как это происходит в.
>> Ключи с длинными позволяют me-- хэш ключи должны быть равенство.
Когда я запрос хэш, я должен сказать, дать мне хэш, равную этого.
Когда я запросить диапазон, я можно сказать, дайте мне диапазон
который использует любую богатые оператор, что мы поддерживаем.
Дайте мне все детали для хэш.
Это равно, больше, чем, меньше, чем, она начинается с того,
оно существует между этими двумя значениями?
Таким образом, эти типы запросов дальности что мы всегда заинтересованы в.
Теперь одна вещь, о данных, когда вы посмотрите на доступ к данным, когда
Вы получить доступ к данным, это всегда о агрегации.
Это всегда о записях которые связаны с этим.
Дайте мне все здесь that's-- все сделки по этой кредитной карты
за последний месяц.
Это агрегации.
>> Почти все, что вы делаете в База данных какой-агрегации.
Так будучи в состоянии быть в состоянии определить эти ведра и дать вам эти ассортимент
атрибуты, чтобы иметь возможность запрашивать на, эти богатые запросы поддержки многих
много, много моделей доступа к приложению.
>> Так другой предмет Хэш ключа делает это дает нам механизм
чтобы иметь возможность расширить данные вокруг.
Базы данных NoSQL работать лучше когда данные равномерно
распределены в кластере.
Сколько людей знакомы с алгоритмов хеширования?
Когда я говорю, хэш и hashing-- потому алгоритма хеширования
это способ быть в состоянии генерировать случайное значение от любого заданного значения.
Таким образом, в данном конкретном случае, хэш алгоритм бежим является Н.Д. 5 на основе.
>> И если у меня есть ID, и это мой хэш-ключ, у меня есть 1, 2, 3.
Когда я запускаю алгоритм хэширования, он собирается вернуться и сказать,
а 1 равен 7В, 2 равна 48, 3 равна компакт-диска.
Они разбросаны по всему ключевого пространства.
И почему вы это делаете?
Потому что гарантирует, что я могу положить записи на нескольких узлах.
>> Если я делаю это постепенно, 1, 2, 3.
И у меня есть выбор, что хэш- работает в данном конкретном случае,
небольшое пространство хэш, он работает от 00 до FF,
то записи будут приходить в и они собираются идти 1, 2, 3, 4, 5,
6, 7, 8, 9, 10, 11, 12.
Что происходит?
Каждый вкладыш идет в том же узле.
Вы видите, что я имею в виду?
>> Потому что, когда я разделить пространство, и я распространять эти записи через,
и я раздел, я собираюсь сказать, раздел 1 имеет ключевое пространство от 0 до 54.
Раздел 2 55 до 89.
Раздел 3 АА FF.
Так что, если я использую линейно увеличивая Идентификаторы, вы можете видеть, что происходит.
1, 2, 3, 4, 5, 6, весь путь до 54.
Так, как я молотком записи в системе,
все заканчивается тем, что шли к одному узлу.
>> Это не хорошо.
Это антипаттерн.
В MongoDB они имеют эту проблему если вы не используете хэш-ключ.
MongoDB дает вам возможность хэширования значение ключа.
Вы всегда должны делать, если Вы используете приращения хеш
Ключ в MongoDB, или вы будете гвоздей каждой записи в одном узле,
и вы будете ограничивая Вы пишете пропускная плохо.
>> АУДИТОРИЯ: Это A9 169 в десятичной?
>> РИК Хулихэном: Да, это где-то около там.
A9, я не знаю.
Вы должны были бы получить мой двоичный в десятичную калькулятор.
Мой мозг не работает так.
АУДИТОРИЯ: Просто быстро одним Ваши комментарии Mongo.
Так идентификатор объекта, который поставляется изначально с Монго сделать?
РИК Хулихэном: она это делает?
Если вы укажите его.
В MongoDB, у вас есть возможность.
Вы можете specify-- каждый документ в MongoDB должен иметь подчеркивания ID.
Это уникальное значение.
>> В MongoDB вы можете указать ли хэш его или нет.
Они просто дают вам возможность.
Если вы знаете, что это не случайный, не проблема.
Вам не нужно этого делать.
Если вы знаете, что это не случайно, что это приращение, а затем сделать хэш.
>> Теперь дело о хэширования, когда вы хэш
value-- и это почему хэш-ключи всегда
уникальные запросы, потому что я изменилась значение, в настоящее время я не могу сделать диапазон запросов.
Я не могу сказать, это между тем или иным,
потому что хэш-значение не будет быть эквивалентна реальной стоимости.
Итак, когда вы хэш, что Ключ, это только равенство.
Вот почему в DynamoDB хеш-ключа запросы всегда только равенство.
>> Так что теперь в диапазоне key-- когда я добавить, что ключевой диапазон,
те ключевые записи диапазон все приходят и они получают хранится в том же разделе.
Таким образом, они очень быстро, легко извлекается, потому что это хэш,
это диапазон.
И вы видите, все с той же хэш
получает хранится на том же пространстве разделов.
Вы можете использовать этот ключ, чтобы помочь диапазон найти ваши данные близки к своему родителю.
Так что я на самом деле здесь делаешь?
Это один ко многим отношений.
Отношения между ключом хэш- и ключ диапазон один ко многим.
Я могу иметь несколько ключей хеш.
Я могу только иметь несколько выбор ключи внутри каждого ключа хэша.
>> Хэш определяет родителя, диапазон определяет детей.
Таким образом, вы можете видеть, что это аналог здесь между реляционной конструкции
и те же типы строит в NoSQL.
Люди говорят о NoSQL, как нереляционная.
Это не нереляционная.
Данные всегда отношения.
Эти отношения просто моделируются по-разному.
Давайте немного поговорим Немного о долговечности.
Когда вы пишите в DynamoDB, пишет всегда трехсторонняя воспроизведены.
Это означает, что у нас есть три AZ годов.
Я являются доступность зон.
Вы можете думать о доступности Зона в центре обработки данных
или совокупность центров обработки данных.
Эти вещи географически изолированы друг от друга
разных зон разломов, по отличается электрические сети и поймы.
Отказ в одном AZ не собирается снять еще один.
Они также связаны вместе с темно-волокна.
Он поддерживает один суб 1 Задержка миллисекунду между АЗС.
Так репликаций данных в режиме реального времени способны в нескольких АЗС.
>> И часто мульти развертывание AZ соответствовать высоким требованиям доступности
большинства предпринимательских организаций.
Так DynamoDB распространяется через три АЗС по умолчанию.
Мы только собираемся познания записи когда два из этих трех узлов вернуться
и сказать, Да, я получил его.
Почему это?
Потому что на стороне чтения мы только собираюсь дать вам данные назад, когда
мы получаем его из двух узлов.
>> Если я тиражирование по три, и я читаю из двух,
Я всегда гарантируется иметь по крайней мере один
тех считывает быть Актуальная копия данных.
Это то, что делает DynamoDB последовательным.
Теперь вы можете включить тех, которые согласуются считывает.
В этом случае я собираюсь сказать, Я буду читать только с одного узла.
И я не могу гарантировать, что это происходит чтобы быть наиболее актуальные данные.
>> Так что, если записи в ближайшие, это еще не реплицируются,
Вы собираетесь получить эту копию.
Это в конечном итоге непротиворечивое чтение.
И что это такое это половина стоимости.
Так что это что-то думать.
Когда вы читаете из DynamoDB, и вы настраиваете вашу способность чтения
единиц, если вы выбираете в конечном итоге соответствует читает, это намного дешевле,,
это около половины стоимости.
>> И так экономит ваши деньги.
Но это ваш выбор.
Если вы хотите непротиворечивое чтение или в конечном итоге непротиворечивое чтение.
Это то, что вы можете выбрать.
>> Давайте поговорим об индексах.
Таким образом, мы упомянули, что топ агрегации уровня.
У нас есть хэш ключи, и мы получили ключи дальности.
Это мило.
И это на основной таблице, я есть один хэш-ключ, я получил один ключ диапазона.
>> Что это значит?
Я получил один атрибут, что я может работать богатых запросов к.
Это ключ диапазона.
Другие атрибуты на этом item-- Я могу фильтровать этих атрибутов.
Но я не могу делать вещи, как, это начинается с или больше.
>> Как мне это сделать?
Я создать индекс.
Там две типы Индексы в DynamoDB.
Индекс действительно Еще один вид таблицы.
И местный вторичный индекс.
>> Первый мы поговорим о.
Так местные вторичные которые сосуществовали в том же разделе, что и данные.
И как таковые, они находятся на и тот же физический узел.
Они, что мы называем последовательной.
Значение, они признают, от записи вместе с таблицей.
Когда записи приходит, мы напишем через индекс.
Мы напишем к столу, и тогда мы будем иметь в виду.
Так вот последовательным.
После того, как записи были признал из таблицы,
это гарантирует, что местный вторичный индекс
будет иметь то же самое видение данных.
Но то, что они позволяют вам делать это определить ключи альтернативные дальности.
>> Придется использовать одинаковые хеш Ключ в качестве основного стола,
потому что они расположены совместно на тот же раздел, и они соответствуют.
Но я могу создать индекс с разными ключами дальности.
Так, например, если бы я имел производителю что было сырым стол части входит.
И сырье части приходят в и они агрегируются сборки.
И, может быть, есть отзыв.
>> Любая часть, которая была сделана эта производитель после этой даты,
Мне нужно, чтобы вытащить из моей линии.
Я могу вращаться индекс что будут искать,
агрегирования на дату производство этой конкретной части.
Так что, если мой стол был верхний уровень уже хэшируется производителя,
может быть, это было устроено на часть ID, я может создать индекс выключения этой таблицы
а хэш производителем и колебалась от даты изготовления.
И таким образом я мог бы сказать, все, что был изготовлен между этими датами,
Мне нужно, чтобы вытащить из линии.
Так что это местный вторичный индекс.
>> Они имеют эффект ограничивая хэш пространство ключей.
Потому что они сосуществовали на том же узле хранения,
они ограничивают хэш-ключ пространство 10 гигабайт.
DynamoDB, под столы, будет разделить
Ваш стол каждые 10 гигабайт.
Когда вы кладете 10 концертов данных в, мы перейти [ФН], и мы добавляем еще один узел.
>> Мы не будем разделить LSI по нескольким разделам.
Мы разбить таблицу.
Но мы не будем разделять LSI.
Так это то, что Важно понимать,
если вы делаете очень, очень, очень большие скопления,
то вы будете ограничиваться 10 гигабайт на вашем БИС.
>> Если это так, то мы можем использовать глобальные вторичные.
Глобальные вторичные являются действительно другая таблица.
Они существуют, чтобы полностью от сторона из вашей первичной таблицы.
И они позволяют мне найти совершенно разные структуры.
Так что думайте о нем, как данные вставляются в двух разных таблиц, структурированный
двумя различными способами.
>> Я могу определить совершенно отличается хэш-ключ.
Я могу определить совершенно другая клавиша диапазона.
И я могу запустить этот совершенно независимо.
В самом деле, у меня подготовлено мою способность чтения
и написать емкость для моего глобальные вторичные индексы
совершенно независимо моей основной таблице.
Если я определяю, что индекс, я говорю это сколько читать и писать
Объем он собирается использовать.
>> И это отдельная от моей основной таблицы.
Теперь оба индекса позволит нам не только определить хэш и дальности ключи,
но они позволяют нам проекта дополнительных значений.
Так что, если я хочу, чтобы считывать индекс, и я хочу, чтобы получить набор данных,
Мне не нужно, чтобы вернуться к главному Таблица, чтобы получить дополнительные атрибуты.
Я могу спроектировать эти дополнительные атрибутов в таблице
поддержать доступа к файлу.
Я знаю, что мы, вероятно, получить в некоторые действительно, really-- попадание в сорняков
здесь, на некоторые из этих вещей.
Теперь я получил дрейфовать из этого.
>> АУДИТОРИЯ: [неразборчиво] --table ключ имел в виду, хэш?
Оригинальный хэш?
Multi-рейки?
>> РИК Хулихэном: Да.
Да.
Ключ таблицы в основном указывает обратно к пункту.
Так индекс является указателем обратно оригинальные предметы на столе.
Теперь вы можете выбрать, чтобы построить индекс, который имеет только ключ таблицы,
и никаких других свойств.
И почему я мог бы сделать это?
Ну, может быть, у меня очень большие предметы.
>> Я действительно только нужно знать which-- мой образец доступа можно сказать,
которые содержат элементы этого отеля?
Не нужно возвратить деталь.
Мне просто нужно знать, какие элементы содержат его.
Таким образом, вы можете построить индексы что только есть ключ таблицы.
>> Но это, прежде всего, то, что индекс в базе данных для.
Это за то, что в состоянии быстро определить, какие записи,
какие строки, которые элементы таблицы имеют
свойства, которые я искал.
>> СБИС, так как они работают?
СБИС в основном являются асинхронными.
Обновление вступает в таблице, Таблица затем асинхронно обновляется
все ваши СБИС.
Вот почему СБИС являются в конечном итоге согласуются.
>> Важно отметить, что когда вы строите СБИС,
и вы понимаете, вы создаете другое измерение aggregation--
Теперь давайте говорить хороший пример здесь производитель.
Я думаю, что я, возможно, говорили о производитель медицинского устройства.
Производители медицинских изделий часто имеют серийные номера части.
Части, которые входят в замена тазобедренного все
есть немного серийный номер на них.
И они могли бы миллионы и миллионы и миллиарды частей
во всех устройствах, которые они поставляются.
Ну, они должны объединять под различные размеры, все части
в сборке, все части, которые были сделаны
на некоторой линии, все части, которые пришли
в с определенной производителя на определенную дату.
И эти скопления иногда встать в миллиарды.
>> Так что я работать с некоторыми из эти ребята, которые страдают
потому что они создают эти скопления GINORMOUS
в их вторичных индексов.
Они могут иметь сырые части таблица, приходит как только хэш.
Каждая часть имеет уникальный серийный номер.
Я использую серийный номер, как хэш.
Оно прекрасно.
Мой сырье таблица данных распространяется по всей ключевого пространства.
Мой [? записывать ?] [? проглатывание?] является удивительным.
Я беру много данных.
Тогда то, что они делают, они создают GSI.
И я говорю, вы знаете, что, мне нужно, чтобы увидеть все части данного производителя.
Ну, вдруг я принимая миллиарда строк,
и запихивать их на один узел, потому что, когда
Я, как агрегировать производитель ID, как хэш,
и номер в диапазоне, затем все вдруг я
поставив млрд части в то, что этот производитель избавил меня.
>> Это может вызвать много давления на GSI,
снова, потому что я молотком один узел.
Я ставлю все эти вставляет в одном узле.
И это реальная проблематично кейс.
Теперь, я получил хороший дизайн шаблон для, как вы избежать.
И это одна из проблем, что я всегда работать.
Но то, что происходит, является GSI может не хватает мощности записи
чтобы быть в состоянии выдвинуть все те строк в одном узле.
И то, что происходит потом это первичный, таблица Клиент,
главная таблица будет задушил потому что GSI не может угнаться.
Так что мой курс будет вставка падают на основной таблице
как мой GSI пытается не отставать.
>> Ладно, так GSI-х, БИС, какой я должен использовать?
БИС согласуются.
GSI являются в конечном счете соответствует.
Если это нормально, я рекомендую использовать GSI, они гораздо более гибким.
БИС могут быть смоделированы как GSI.
И если размер данных в хэш-ключей в Ваша коллекция превышает 10 гигабайт,
то вы будете хотеть использовать что GSI, потому что это просто жесткий лимит.
>> Ладно, так масштабирования.
Пропускная в Динамо БД, вы положение может [неразборчиво]
пропускная к столу.
У нас есть клиенты, которые имеют подготовлено 60 billion--
делают 60 млрд запросов, регулярно работает на более чем миллион запросов
за секунду на наших столах.
Там на самом деле нет Теоретический предел того, сколько
и как быстро таблица может работать в Динамо БД.
Есть некоторые мягкие лимиты на ваш счет
что мы ставим там так что вы не сходите с ума.
Если вы хотите больше, чем что не является проблемой.
Вы приходите, сообщите нам.
Мы поднимите диск.
>> Каждая учетная запись ограничена какой-то степени в каждой службе, просто с места в карьер
так что люди не сходят с ума попадают в неприятности.
Нет предела в размере.
Вы можете поместить любое количество элементов на столе.
Размер элемента является ограничивается до 400 килобайт каждый,
что бы элемент не атрибуты.
Так сумме всех атрибутов ограничивается до 400 килобайт.
И опять же, у нас есть что мало БИС вопрос
с пределом 10 гигабайт на хэш.
АУДИТОРИЯ: Небольшое количество, я пропускаю то, что вы говорили мне, что is--
АУДИТОРИЯ: Да, 400 килобайта максимальный размер по каждому пункту.
Так элемент имеет все атрибуты.
Так 400 К общий размер этого элемента, 400 килобайт.
Так всех признаков комбинированные все данные
это во всех этих атрибутов, закатал в общей численности,
В настоящее время предел пункт сегодня 400 к.
Так масштабирования снова, достигается посредством перегородок.
Пропускная способность предусмотренном на уровне таблицы.
И там действительно две ручки.
Мы читали мощность и написать емкость.
>> Таким образом, эти корректируются независимо друг от друга.
Мера РКО в строго согласованные чтения.
ОК, так что если вы говорите, я хочу 1000 РКО-х те, строго последовательным,
тех, согласуются читает.
Если вы хотите сказать, что я возможное непротиворечивое чтение,
Вы можете предоставление 1000 РКО, вы идете
чтобы получить в конечном итоге 2,000 соответствует читает.
И половина цены для тех, в конечном итоге состоят в читает.
>> Опять же, регулируется независимо друг от друга.
И у них есть throughput-- Если вы потребляете 100% от вашего РКО,
вы не собираетесь, чтобы повлиять на наличие ваших прав.
Таким образом, они полностью независимы друг от друга.
Ладно, так что один из вещей, которые Я кратко упомянуто было дросселирования.
Регулирование плохо.
Регулирование указывает плохо не SQL.
Есть вещи, которые мы можем сделать, чтобы помочь вам облегчить дросселирование, что вам
испытывают.
Но лучшее решение чтобы это давайте
Взгляд на то, что вы делаете, потому что есть анти-паттерна в игре здесь.
>> Эти вещи, вещи, как неоднородных нагрузки, горячие клавиши, горячие перегородки.
Я удара особое пространство ключей очень трудно, по определенным причинам.
Почему я это делаю?
Давайте понять.
Я смешиваю мои горячие данные с холодными данных.
Я позволяю мои таблицы получить Огромный, но там действительно
только некоторое подмножество данных это действительно интересно для меня.
Таким образом, для данных журнала, например, много клиенты, они получают данные, авторизуйтесь каждый день.
Они получили огромное количество данных журнала.
>> Если вы только что демпинг все журнал данные в одной большой таблице, со временем
эта таблица собирается получить массивное.
Но я действительно заинтересованы только в Последние 24 часов, последние семь дней,
последние 30 дней.
Как бы то ни промежуток времени что я заинтересованы в поиске
для события, беспокоит меня, или событие, которое мне интересно,
что единственный раз, когда окно, что мне нужно.
Итак, почему я положить 10 лет Стоит каротажных данных в таблице?
То, что это вызывает это таблица фрагмент.
>> Он получает огромное.
Это начинает распространяться из на тысячи узлов.
А так как ваша способность так низко, вы
на самом деле ограничения скорости на каждом один из тех отдельных узлов.
Итак, давайте начнем, глядя на том, как мы свернуть эту таблицу в течение.
Как мы можем управлять, что данные немного лучше, чтобы избежать этих проблем.
И то, что это похоже?
Это то, что, что выглядит.
Это то, что плохо NoSQL выглядит.
>> Я получил горячую клавишу здесь.
Если вы посмотрите на стороне здесь, это все мои разделы.
Я получил 16 разделов здесь на этой конкретной базы данных.
Мы делаем это все время.
Я запускаю это для клиентов все время.
Это называется тепловой карте.
Тепловая карта говорит мне, как ты доступа к вашей пространство ключей.
И то, что это говорит мне, это что есть один конкретный хеш
что этот парень любит очень много, потому что он
ударив по нему действительно, действительно трудно.
>> Таким образом, синий приятно.
Нам нравится синий.
Нам не нравится красный цвет.
Где давление Реда получает до 100%.
100%, теперь вы будете задушил.
Поэтому, когда вы видите красные линии, как this-- и это не только Динамо DB--
каждая база данных NoSQL имеет эту проблему.
Есть антишаблоны, которые могут управлять этими типами условий.
То, что я делаю, я работаю с клиентами чтобы облегчить эти условия.
>> И то, что это похоже?
И это становится наиболее из Динамо DB пропускной способности,
но это действительно становится большинство из NoSQL.
Это не ограничивается Динамо.
Это я definitely-- используется для работы в Монго.
Я знаком со многими платформами NoSQL.
Каждый человек имеет эти типы горячих ключевых проблем.
Чтобы получить максимальную отдачу от любой NoSQL базы данных, специально Динамо БД,
Вы хотите, чтобы создать таблицы где элемент хэш-ключ имеет
большое количество различных значений, высокая степень мощности.
Потому что это означает, что я пишу на множество различных ковшей.
>> Чем больше я в ведра письменной форме, тем более вероятно,
Я распространять эту нагрузку записи или прочитать загрузить из по нескольким узлам,
тем более вероятно, я должен иметь высокая пропускная способность на стол.
А потом я хочу, чтобы быть значения просил довольно равномерно в течение долгого времени
и равномерно, как случайным образом, насколько это возможно.
Ну, это довольно интересно, потому что я не могу на самом деле
контроль, когда пользователи приходят.
Так достаточно сказать, если мы распространяем вещи из всей ключевого пространства,
мы, вероятно, будет в лучшей форме.
>> Там определенная количество времени доставки
что вы не собираетесь чтобы быть в состоянии контролировать.
Но это на самом деле два аспекта, которые мы имеем,
пространство, доступ равномерно распространение, время, запросы
прибывающим равномерно во времени.
И если эти два удовлетворяются условия,
то, что то, что это будет выглядеть.
Это гораздо приятнее.
Мы действительно счастливы здесь.
Мы получили очень даже модель доступа.
Да, может быть, вы получаете небольшое давление каждый сейчас и потом,
но ничего действительно слишком обширная.
Так что это удивительно, как много раз, когда я работаю с клиентами,
что первый график с большой красный бар и все, что уродливые желтые это
повсюду, мы сделано с осуществлением
через пару месяцев повторного архитектуры,
они работают точно такой же нагрузка в то же самое нагрузки.
И это то, что он ищет, как сейчас.
Так что вы получаете с NoSQL является Схема данных, абсолютно
привязан к модели доступа.
>> И вы можете оптимизировать эту схему данных поддержать эту модель доступа.
Если вы этого не сделаете, то вы будете чтобы увидеть эти типы проблем
с тех горячих клавиш.
>> АУДИТОРИЯ: Ну, неизбежно некоторые места будут жарче, чем другие.
>> РИК Хулихэном: Всегда.
Всегда.
Да, я имею в виду всегда есть a-- и снова, есть
некоторые шаблоны проектирования, мы пройдем через что будет говорить о том, как вы имеете дело
с этих супер больших скоплений.
Я имею в виду, я должен иметь их, как мы имеем дело с ними?
Я получил очень хорошую прецедент что мы будем говорить о том, что для.
>> Ладно, так что давайте говорить о некоторых клиенты сейчас.
Эти ребята AdRoll.
Я не знаю, если вы знакомы с AdRoll.
Вы, наверное, увидеть их много в браузере.
Они объявлений перенацеливания, они крупнейший объявления перенацеливания бизнес
там.
Они, как правило, регулярно запускать более 60 млрд транзакций в день.
Они делают более миллиона транзакций в секунду.
Они получили довольно простую таблицу структура, оживленных таблицы.
Это в основном только хэш ключ куки,
диапазон демографическая Категория, а затем
третий атрибут счет.
>> Таким образом, мы все должны куки в наш браузер от этих парней.
И когда вы идете к участие купец,
они в основном оценка вас через различные демографические категории.
Когда вы идете на сайт и вы говорите, я хочу, чтобы этот ad--
или в основном не говорят that-- но когда вы идете на сайт
они говорят, что вы хотите увидеть это объявление.
И они идут получить, что объявление от AdRoll.
AdRoll выглядит вас на столе.
Они находят свой печенье.
Рекламодатели, рассказывающие им, я хочу кого-то
кто среднего возраста, 40-летний мужчина, в спорте.
И они выигрывают вас в этих демографических и они решают ли или нет
что это хорошая реклама для вас.
>> Теперь у них есть SLA с их рекламные провайдеры
чтобы обеспечить суб-10 миллисекунду Ответ на каждый запрос.
Так они используют Динамо DB для этого.
Они удара нам миллион запросов в секунду.
Они в состоянии сделать все их поиски, сортировка всего, что данные,
и получить, что добавить ссылку на что рекламодателя в возрасте до 10 миллисекунд.
Это действительно довольно феноменальный Реализация, что они имеют.
>> Эти ребята actually-- Являются ли эти ребята.
Я не уверен, если это эти ребята.
Может быть эти ребята.
В основном сказал us-- нет, я Не думаю, что это было их.
Я думаю, что это был кто-то еще.
Я работал с клиент, который сказал мне,
что теперь, когда они пошел Динамо БД, они
тратить больше денег на закусках для их команда разработчиков каждый месяц
чем они тратят на их базе данных.
Так это даст вам Идея экономии
что вы можете получить в Динамо БД огромен.
Ладно, dropcam другой компании.
Эти парень вроде of-- если вы думаете, интернет вещей, dropcam
в основном интернет-видео безопасности.
Вы ставите камеру там.
Камера имеет детектор движения.
Кто-то приходит, запускает ключевую точку.
Камера начинает запись на некоторое время до он не обнаруживает никакого движения больше.
Кладет это видео на Интернете.
>> Dropcam была компания, которая в основном перешли на Динамо БД
потому что они испытывают Огромные растущие боли.
И то, что они сказали нам вдруг петабайт данных.
Они понятия не имели, их обслуживание будет настолько успешным.
Более входящих видео YouTube, чем это то, что эти ребята получают.
Они используют DynamoDB отслеживать все метаданные всех своих видео ключевых моментов.
>> Таким образом, они имеют S3 ведра они толкают все бинарные артефакты в.
И тогда они имеют Динамо DB записи,
указать людям на этих трех объектов S3.
Когда они должны смотреть на видео, они смотрят запись в Динамо БД.
Они нажмите на ссылку.
Они тянут вниз видео с S3.
Так что вроде как это выглядит.
И это прямо из своей команды.
>> Динамо БД уменьшает их время доставки для видео событий
от пяти до 10 секунд.
В своей старой реляционной магазине, они использовали, чтобы иметь, чтобы пойти и выполнить
несколько сложных запросов к фигуре из которых видео, чтобы тянуть вниз,
до менее чем за 50 миллисекунд.
Так что это удивительно, удивительно сколько эффективность
Вы можете получить, когда вы оптимизировать и Вы настраиваете основной базе данных
поддержать доступа к файлу.
Halfbrick, эти ребята, что это, Fruit Ninja Я думаю, это их дело.
Это все работает на Динамо БД.
И эти ребята, они являются отличным Команда разработчиков, большое развитие
магазин.
>> Не хороший ОПС команда.
Они не имеют много эксплуатационных ресурсов.
Они боролись, пытаясь сохранить их инфраструктура приложений до
и работает.
Они пришли к нам.
Они смотрели на то Динамо БД.
Они сказали, что это для нас.
Они построили всю свою Структура приложения на нем.
Некоторые действительно хорошие комментарии здесь от команды на их способности
чтобы теперь сосредоточиться на строительство игра, а не
того, чтобы поддерживать инфраструктура, которая
становится огромное количество накладных расходов для своей команды.
Так что это что-то that-- преимущество, что вы получите от Динамо БД.
>> Ладно, попадая в моделирование данных здесь.
И мы говорили немного о это один к одному, один ко многим,
и многие ко многим отношений типа.
А как вы поддерживаете тех, кто в Динамо.
В Динамо БД мы используем Индексы, вообще говоря,
вращать данные один вкус к другому.
Хэш-ключи, ключи диапазон, и индексы.
>> В данном конкретном Например, как и большинство государств
есть требование лицензирования, только лицензия одного водителя на человека.
Вы не можете пойти, чтобы получить двух водителя лицензии в штате Бостон.
Я не могу сделать это в Техасе.
Это вроде того, как это.
И так в DMV, у нас есть операций поиска, мы хочу посмотреть водительское удостоверение
по количеству социального обеспечения.
Я хочу, чтобы посмотреть информацию о пользователе по количеству лицензий водителя.
>> Таким образом, мы, возможно, таблицу пользователя, что имеет хэш-ключ на серийный номер,
или номер социального страхования, и различные атрибуты определяются по этому пункту.
В настоящее время на этой таблице I может определить, что GSI
переворачивает, что вокруг, что я хочу, говорит, ключевой хэш по лицензии, а затем
все другие предметы.
Теперь, если я хочу, чтобы запрашивать и найти Номер лицензии для любой социальной
Номер безопасности, я могу запрос основную таблицу.
>> Если я хочу, чтобы запросить и я хочу чтобы получить социальное обеспечение
номер или другие атрибуты с помощью номер лицензии, я могу запросить GSI.
Эта модель, что один к одному отношения.
Просто очень простой GSI, флип эти вещи.
Теперь, поговорим об одной для многих.
Один ко многим в основном Ваш ключ Диапазон хэш.
Где мы получаем много с этим Использование случай данные монитора.
Данные мониторинга регулярно поставляется в Интервал, как Интернет вещей.
Мы всегда получаем все это записи в ближайшие все время.
>> И я хочу, чтобы найти все показания между определенный период времени.
Это очень распространенная в запрос Мониторинг инфраструктуры.
Путь идти о том, что это, чтобы найти простая структура таблицы, одна таблица.
Я получил таблицу измерений прибора с ключом хэш на устройство ID.
И у меня есть ключ диапазона на метка, или в данном случае, эпос.
И, что позволяет мне выполнить комплекс запросы к этому ключу диапазоне
и вернуться те записи, которые по сравнению с результатом
Установлено, что я ищу.
И он строит, что одна для многих отношениях
в основной таблице, используя хэш ключа, диапазон ключевой структурой.
>> Так что это своего рода встроенный в таблице в БД Динамо.
Когда я определить хэш и диапазон т стол, я
определения один ко многим отношений.
Это отношения родитель-ребенок.
>> Давайте поговорим о многих многих отношениях.
И для этого конкретного примера, опять же, мы собираемся использовать GSI-х.
И давайте говорить об играх сценарий, где у меня есть данный пользователь.
Я хочу, чтобы найти все игры, которые он зарегистрирован или играя в.
А для данной игры, я хочу найти всех пользователей.
Так как я делаю это?
Мой пользователей игры стол, я собираюсь иметь хэш-ключ ID пользователя
и ключ диапазон игре.
>> Таким образом, пользователь может иметь несколько игр.
Это один ко многим отношений между пользователь и игры он играет.
А потом на GSI, Я флип что вокруг.
Я хэш на игре и Я диапазоне от пользователя.
Так что, если я хочу, чтобы все Игра пользователь играет в,
Я запрашивать основную таблицу.
Если я хочу, чтобы получить все пользователи которые играют определенную игру,
Я запросить GSI.
Итак, вы видите, как мы это делаем?
Вы строите для поддержки этих GSI годов Прецедент, приложение, доступ
узор, приложение.
>> Если мне нужно запросить на это измерение, пусть
мне создать индекс по этому измерению.
Если я не делаю, я не волнует.
И в зависимости от случая использования, я возможно, потребуется индекс или я не мог.
Если это просто один ко многим, основной таблице в порядке.
Если мне нужно сделать это много, чтобы многие, либо мне нужно сделать один для тех,
то, возможно, мне нужно на второе индекс.
Так что все зависит от то, что я пытаюсь сделать
и то, что я пытаюсь получить опытный.
>> Вероятно, я не буду тратить слишком много времени говорить о документах.
Это становится немного, наверное, глубже, чем мы должны идти в.
Давайте немного поговорим о богатых выражение запроса.
Таким образом, в Динамо БД у нас есть способность создавать
что мы называем проекционные выражения.
Проекционные выражения просто выбирая поля или значения
что вы хотите, чтобы отобразить.
ОК, так что я могу сделать выбор.
Я делаю запрос к БД Динамо.
И я говорю, вы знаете, что, показать меня только пять отзывы звезды
для этого конкретного продукта.
Так что все, что я хочу видеть.
Я не хочу, чтобы увидеть все другие атрибуты строки,
Я просто хочу, чтобы это увидеть.
Это просто, как и в SQL, когда вы говорят выберите звезду или из таблицы,
Вы получаете все.
Когда я говорю, выберите имя из стол, я только один атрибут.
Это то же самое рода вещи в Динамо БД или еще базы данных NoSQL.
Фильтровать выражения позволяют мне в основном сократить набор результатов вниз.
Так что я сделать запрос.
Запрос может вернуться с 500 пунктов.
Но я хочу только те элементы, которые есть атрибут, который говорит, что это.
Итак, давайте отфильтровать эти элементы которые не соответствуют этой конкретной запрос.
Итак, мы имеем выражения фильтра.
>> Фильтровать выражения могут будет работать на любой атрибут.
Они не хотели интервальные запросы.
Повышение запросы более избирательным.
Фильтровать запросы требуют от меня, чтобы пойти получить весь набор результатов, а затем
вырезать данные, которые я не хочу.
Почему это так важно?
Потому что я читал все это.
В запросе, я буду читать и это будет гигантский о данных.
А потом я собираюсь вырезать то, что мне нужно.
И если я только вырезая пара строк, то это нормально.
Это не так неэффективно.
>> Но если я читаю целую кипу Данные, просто вырезать один элемент,
затем я собираюсь быть лучше от использования диапазона запроса,
потому что это гораздо более избирательно.
Это спасет меня много деньги, потому что я платить за это чтение.
Если результаты, который возвращается пересечь эту проволоку может быть меньше,
но я плачу за чтение.
Так понимаю, как Вы получаете данные.
Это очень важно в Динамо БД.
>> Условные выражения, это то, что Вы могли бы назвать оптимистической блокировки.
Обновить, если есть, или, если это значение эквивалентно тому, что я указываю.
И если у меня есть штамп времени на запись, я мог бы прочитать данные.
Я мог бы изменить эти данные.
Я мог бы пойти пишут, что назад данные в базу данных.
Если кто-то изменил запись, отметка времени может быть изменен.
И таким образом мой условно обновление можно сказать, обновление
если отметка равна этого.
Или обновление не будет выполнено, потому что кто-то обновил рекорд в то же время.
>> Это то, что мы называем оптимистическое блокирование.
Это означает, что кто-то может прийти и изменить его,
и я собираюсь обнаружить его когда я вернусь, чтобы написать.
И тогда я могу на самом деле читать, что данных и говорят, ой, он изменил это.
Мне нужно, чтобы учесть это.
И я могу изменить данные в моей записывать и применять еще одно обновление.
Таким образом, вы можете поймать тех, дополнительных Обновления, которые происходят между временем
что вы читаете данные и раз, когда вы могли бы написать данные.
>> АУДИТОРИЯ: И фильтр Выражение на самом деле означает не
номер или не--
>> [Реле ГОЛОСА]
РИК Хулихэном: Я не буду получить слишком много в этом.
Это зарезервированное слово.
Вид фунт сдержанный Ключевое слово в Динамо БД.
Каждая база данных имеет свой собственный защищены Имена для коллекций вы не можете использовать.
Динамо БД, если вы укажете фунт перед этим,
Вы можете определить эти имена наверху.
Это эталонное значение.
Это, вероятно, не самый лучший синтаксис есть там для этой дискуссии,
потому что он попадает в некоторых real-- Я был бы говорить больше
о том, что на более глубоком уровне.
>> Но достаточно сказать, что это могло бы быть запрос сканирования, где они views--
ни просмотров фунт больше, чем 10.
Это числовое значение, да.
Если вы хотите, мы можем говорить о что после обсуждения.
Ладно, так что мы входим в некоторые сценарии в лучших практик
где мы будем говорить о некоторых программах здесь.
Каковы варианты использования для Динамо БД.
Каковы дизайн узоры в Динамо БД.
>> И первый, кого мы собираемся разговоры о является Интернет вещей.
Таким образом, мы получаем много of-- Я думаю, то, что it-- более 50%
трафика в интернете в эти дни фактически генерируется машинами,
автоматизированные процессы, а не людей.
Я имею в виду эту вещь эта вещь, что Вы носить в кармане,
сколько данных, что эта вещь на самом деле отправки вокруг без тебя
зная, что это совершенно удивительное.
Ваше местоположение, информация о том, как быстро вы идете.
Как вы думаете, Google Maps работы когда они говорят вам, что трафик.
Это потому, что есть миллионы и миллионы людей по всему вождения
с телефонами, которые посылают Данные по всему месте все время.
Так одна из вещей, об этом типе данных
что приходит в данные монитора, войти Данные, данных временных рядов, является его
как правило, только интересно для немного времени.
После этого времени, это не так интересно.
Таким образом, мы говорили, не дай эти таблицы растут без границ.
Идея здесь в том, что, может быть, я получил 24 часов стоимостью событий в моей горячей таблице.
И, что горячий стол будет подготовлено на очень высокой скорости,
потому что он принимает много данных.
Это занимает много данных , и я читаю его много.
Я получил много работы запросы работает против этого данных.
>> После 24 часов, эй, вы знаете, я не волнует.
Так, может быть, каждый полночь я ролл мой стол к новой таблице
и я высвобождения неиспользуемых эту таблицу.
И я возьму РКО-х и Вниз WCU, потому что через 24 часа
Я не работает, как многие запросы к этим данным.
Так что я иду, чтобы спасти деньги.
И, может быть, через 30 дней я не даже нужно заботиться о нем все.
Я мог бы взять ВКУ-х все, вплоть до одного,
потому что вы знаете, что, это никогда не собираетесь получить запись.
Данные 30 дней.
Это никогда не меняется.
>> И это почти никогда не происходит, чтобы получить читать, так что давайте просто считать, что RCU до 10.
И я экономлю кучу денег на это данных и платить только за мои горячие данных.
Так что это важная вещь, чтобы искать на то, когда вы смотрите на временных рядов
данные, поступающие в в объеме.
Эти стратегии.
Теперь, я мог позволить его все идут в той же таблице
и пусть эта таблица расти.
В конце концов, я собираюсь см проблемы с производительностью.
Я собираюсь иметь, чтобы начать архивирование некоторые из этих данных со стола,
что нет.
>> Давайте лучше разрабатывать приложение
так что вы можете работать так хорошо.
Так что это просто автомат в коде приложения.
В полночь каждую ночь она катится по столу.
Может быть, то, что мне нужно, это скольжение Окно 24 часов данных.
Тогда на регулярной основе я Вызов данных со стола.
Я обрезки его с Крон работа, и я ставлю его
на этих других таблиц, все что тебе нужно.
Так что, если опрокидывание работает, это здорово.
Если нет, обрежьте ее.
Но давайте держать, что горячий данные от ваших холодных данных.
Это сэкономит вам много денег, и сделать ваши таблицы более совершенных.
Таким образом, следующая вещь, мы поговорим о том, каталог продукции.
Каталог товаров вне довольно часто кейс.
Это на самом деле очень общий шаблон что мы увидим в различных вещей.
Вы знаете, Twitter для Например, горячая твит.
Все идет и хватая что в твиттере.
Каталог товаров, я получил продаже.
Я получил горячую продажу.
Я получил 70000 запросов в второе пришествие для продукта
Описание из моего каталога.
Мы видим это на розницу операция совсем немного.
Так как мы имеем дело с этим?
Там нет никакого способа, чтобы справиться с этим.
Все мои пользователи хотят, чтобы увидеть та же часть данных.
Они приходят в, одновременно.
И все они делать запросы по той же части данных.
Это дает мне, что горячая клавиша, что большая красная полоса на моей карте, что нам не нравится.
И это, как это выглядит.
Так по моему ключевого пространства я получаю забил пунктов продажи.
Я не получаю ничего нигде.
>> Как решить эту проблему?
Ну, мы это с облегчить кэша.
Кэш, вы положили в основном в оперативной памяти раздел перед базе данных.
Нам удалось [Неразборчиво] кэша, как вам
может создать свой собственный кэш, [неразборчиво] Кэш [? д,?], что вы хотите.
Положим, что в передней части базы данных.
И таким образом вы можете хранить эти данные от тех горячих клавиш в этой кэш-памяти
пространство и читать через кэш.
>> И тогда большинство ваших читает начать поиск, как это.
Я получил все это кэш-парад здесь и я ничего не получил здесь происходит
потому что база данных сидя позади кэш и не читает и не прийти до конца.
Если я изменить данные в базы данных, у меня есть для обновления кэша.
Мы можем использовать что-то как пары сделать это.
И я объясню, как это работает.
Ладно, сообщениями.
E-mail, мы все используем электронную почту.
>> Это очень хороший пример.
У нас есть какой-то сообщений стола.
И мы получили почтовый ящик и исходящие.
Это то, что SQL будет Посмотрите, как строить, что почтовый ящик.
Мы вроде использовать тот же самый вид стратегии для использования GSI-х, GSI-х
для моего почтового ящика и моей исходящие.
Так что я получил сообщения, поступающие сырье в мои сообщения таблицы.
И первый подход к этому может быть, не говорят, ОК, нет проблем.
Я получил исходные сообщения.
Сообщения, поступающие [неразборчиво], идентификатор сообщения, это здорово.
Это мой единственный хэш.
Я собираюсь создать два GSI, одной для моего почтового ящика, по одному для моего исходящие.
И первое, что я сделаю , я скажу, мой ключ хэш
будет получатель и Я собираюсь устроить на сегодняшний день.
Это фантастика.
Я получил хороший вид здесь.
Но есть небольшая проблема здесь.
И вы столкнетесь это реляционные базы данных, а также.
Они называли вертикально разбиение.
Вы хотите, чтобы ваш большой данные от ваших маленьких данных.
>> И причина, почему, потому что я должен идти читать пункты, чтобы получить атрибуты.
И если мои органы все здесь, затем чтение всего несколько пунктов
если мой Длина тела в среднем 256 килобайт каждый,
математика становится довольно некрасиво.
Так что я хочу, чтобы прочитать входящие Давида.
Входящие Давида имеет 50 пунктов.
Средняя и размер 256 килобайт.
Вот мой коэффициент конверсии для РКО является четыре килобайта.
>> ОК, давайте идти с в конечном итоге, непротиворечивое чтение.
Я до сих пор есть 1600-х РКО просто читать входящие Давида.
Ой.
Хорошо, теперь давайте подумаем о том, как работает приложение.
Если я нахожусь в почтовом приложении и Я смотрю на мой почтовый ящик,
и я смотрю на теле каждого сообщения, нет, я смотрю на резюме.
Я смотрю на только заголовки.
Итак, давайте строить структуру таблицы что больше похоже, что.
>> Так вот информация что мой рабочий процесс потребностей.
Это в мой почтовый ящик GSI.
Это дата, отправитель, предметом, а затем
идентификатор сообщения, который указывает вернуться к таблице сообщений
где я могу получить тело.
Ну, это было бы записывать идентификаторы.
Они указывают назад к идентификаторы пункт на столе Динамо DB.
Каждый индекс всегда creates-- всегда имеет элемент
ID, как часть of--, что приходит с индексом.
>> Отлично.
АУДИТОРИЯ: Это говорит его там, где он хранится?
РИК Хулихэном: Да, он говорит exactly--, что именно, что она делает.
Это говорит, вот мой повторно запись.
И это будет указывать его обратно в моей повторной записи.
В точку.
ОК, так что теперь мой почтовый ящик является фактически намного меньше.
И это на самом деле поддерживает рабочий процесс электронной приложение.
Так мой почтовый ящик, я нажимаю.
Я иду вдоль и я нажимаю на сообщения, что, когда мне нужно пойти получить тело,
потому что я собираюсь перейти на другую точку зрения.
Так что, если вы думаете, о типе MVC в рамки, вид модели контроллера.
>> Модель содержит Данные о том, что потребности вид
и контроллер взаимодействует с.
Когда я изменить рамку при Изменить перспективу,
это нормально, чтобы вернуться к Сервер и населить модель,
потому что это то, что ожидает пользователь.
Когда они изменить взгляды, что, когда мы можем вернуться к базе данных.
Так электронной почты, нажмите.
Я ищу для тела.
В обе стороны.
Перейти получить тело.
>> Я читал много меньше данных.
Я только читал, что органы Дэвид должен, когда он нуждается в них.
И я не горят в 1600 году РКО просто, чтобы показать свою почтовый ящик.
Так что теперь that-- это путь что LSI или GSI-- я извиняюсь,
GSI, будет работать.
Мы получили наш хэш на получателя.
Мы получили ключ диапазон на сегодняшний день.
И у нас есть прогнозируемые атрибуты что нам нужны только для поддержки зрения.
>> Мы вращаем, что для почтового ящика.
Hash на отправителя.
А по существу, мы имеем очень хороший, чистый вид.
И это мы basically-- есть хорошие сообщения в эту
Таблица, которая распространяется красиво, потому что это хэш только хэш сообщение ID.
И у нас есть два индекса, что вращаются с той таблице.
Ладно, так идея здесь заключается не держать большие данные и этот небольшой данные
вместе.
Partition вертикально, разделить эти таблицы.
Не читайте данные, которые вы не должны.
Ладно, игровой.
Мы все хотели игр.
По крайней мере, мне нравится игры, то.
Таким образом, некоторые из вещей, что мы имеем дело с тем, когда
мы думаем об играх, не так ли?
Gaming эти дни, особенно с мобильного игры, это все о мышлении.
И я собираюсь повернуть здесь немного от DynamoDB.
Я собираюсь принести в некоторые из обсуждения
вокруг некоторых из другие технологии AWS.
>> Но идея об играх, чтобы думать о в терминах интерфейсов API интерфейсы, которые,
вообще говоря, HTTP и JSON.
Это, как мобильные игры вид взаимодействуют с их концами назад.
Они делают JSON регистрацию.
Они получают данные, и все это, вообще говоря, в хороших интерфейсов JSON.
>> Такие вещи, как завести друзей, получить данные лидеров, обмен,
контент, создаваемый пользователями, отодвинуть к системе,
эти типы вещей что мы собираемся делать.
Двоичные данные активов, эти данные не может сидеть в базе данных.
Это может сидеть в Объект магазин, правильно?
Но база данных будет в конечном итоге говорю систему,
рассказывая приложение куда идти получить его.
И неизбежно, мультиплеер серверы, на конец инфраструктуры назад,
и предназначены для высокого доступность и масштабируемость.
Таким образом, эти вещи, которые мы все хотим в игровом инфраструктуры сегодня.
>> Итак, давайте взглянем на как это выглядит.
Есть основной задний конец, очень проста.
Мы получили систему здесь с несколько зон доступности.
Мы говорили о АЗС в being-- думаю из них в виде отдельных центров обработки данных.
Центр Более данные за AZ, но это нормально,
просто думать о них как отдельные данные центры, которые географически
и выделяют вина.
>> Мы собираемся, чтобы иметь случаи пара EC2.
Мы собираемся, чтобы иметь некоторые задней части сервера.
Может быть, если вы наследие архитектура, мы
используя то, что мы называем RDS, реляционные базы данных. услуги
Может быть MSSQL, MySQL, или что-то типа того.
Это путь много приложений предназначены сегодня.
>> Ну, мы могли бы пойти с это когда мы масштабировать.
Мы пойдем вперед и положить ведро там S3.
И, что S3 ведро, а не служить до тех объектов, из нашего servers--
мы могли бы это сделать.
Вы ставите все ваши двоичный объекты на ваших серверах
и вы можете использовать эти сервера случаи, чтобы служить, что данные меры.
Но это довольно дорого.
>> Лучший способ сделать это пойти вперед и положить эти предметы в S3 ведра.
S3 является репозитории объекта.
Он построен специально для выступающей эти типы вещей.
И пусть те клиенты просят непосредственно из этих объектов ведра,
разгрузить серверы.
Таким образом, мы начинаем масштабировать здесь.
>> Теперь мы получили пользователи по всему миру.
Я получил пользователи.
Мне нужно, чтобы содержимое локально расположен недалеко от этих пользователей, правильно?
Я создал ведро S3 как мой репозитории.
И я фронт, который с распределение CloudFront.
>> CloudFront является компакт-диск и Содержание сеть доставки.
В основном это берет данные, которые вы указываете и кэширует все это через Интернет
так что пользователи во всем мире могут иметь очень быстрый ответ, когда
они просят эти объекты.
>> Таким образом, вы получите представление.
Вы вроде используя все аспекты AWS здесь, чтобы получить это сделать.
И в конце концов, мы бросаем в авто масштабирования группы.
Таким образом, наши случаях AC2 наших игровых серверов,
как они начинают получать занят и более занятыми и более занятыми,
они просто вращаются другой Экземпляр, спина еще один экземпляр,
спина еще один экземпляр.
Так технологии AWS имеет, это позволяет задать параметры
вокруг которого серверы будут расти.
Таким образом, вы можете иметь н количество серверов там в любой момент времени.
И если ваш груз уходит, они будут сократится число будет сокращаться.
И если нагрузка возвращается, это будет расти обратно, упруго.
>> Так что это выглядит здорово.
У нас есть много случаев EC2.
Мы можем кэша Передняя баз данных,
попытаться ускорить базы данных.
Следующий пункт давление как правило, люди видят
это они масштабировать игру с помощью реляционная система базы данных.
Боже, база данных производительность страшно.
Как мы можем улучшить, что?
Давайте попробуем положить кэш перед этим.
>> Ну, кэш не работает настолько велик, в играх, не так ли?
Для игр, написание является болезненным.
Игры очень тяжелый написать.
Кэш не работает, когда вы написать тяжелых, потому что вы всегда
получил обновить кэш.
Вы обновить кэш, это не имеет значения для кэширования.
Это на самом деле просто дополнительная работа.
>> Так, куда мы идем здесь?
У вас есть большой узкое там в базе данных.
И место, чтобы пойти очевидно, разделения.
Разметка не легко сделать, когда вы
дело с реляционными базами данных.
С реляционными базами данных, вы ответственность за управление, эффективно,
пространство ключей.
Вы говорите пользователей между А и М иди сюда, между N и Z туда.
И вы переходите по применению.
Таким образом, вы имеете дело с этот раздел источника данных.
Вы должны транзакционных ограничений которые не охватывают разделы.
Вы получили все виды беспорядка, что вы
дело с там пытаются иметь дело с масштабирование
и строительство большего инфраструктуры.
Это не просто не интересно.
>> АУДИТОРИЯ: Так вы говорите, что увеличение точек источника ускоряет
процесс?
РИК Хулихэном: Повышение?
АУДИТОРИЯ: Источник пунктов.
РИК Хулихэном: Source точки?
АУДИТОРИЯ: Из информации, где информация приходит от?
РИК Хулихэном: Нет
То, что я говорю, является повышение Количество разделов в хранилище данных
улучшает пропускную способность.
Так что здесь происходит, пользователи вступления в экземпляре EC2 здесь,
Ну, если мне нужно пользователю Это М, я пойду сюда.
От N р, я пойду сюда.
С Р до Я, я пойду сюда.
>> АУДИТОРИЯ: ОК, так те, те сохраняются в различных узлах?
>> РИК Хулихэном: Да.
Подумайте о них, как различные бункеры данных.
Таким образом, вы того, чтобы сделать это.
Если вы пытаетесь сделать это, если вы пытаетесь
в масштабе на реляционной платформе, это то, что вы делаете.
Вы принимаете данные и вы резки его.
И вы разделения его по несколько экземпляров базы данных.
И вы все, что управление на уровне приложений.
Это не весело.
Так что мы хотим идти?
Мы хотим, чтобы перейти DynamoDB, полностью управляемый, NoSQL хранилища данных, предоставление пропускную способность.
Мы используем вторичные индексы.
Это в основном HTTP API и включает в себя поддержку документа.
Таким образом, вы не должны беспокоиться о любом из этого разделения.
Мы делаем все это для вас.
Так что теперь, вместо этого, вы просто напишите в таблице.
Если таблица должна быть разделена, что происходит за кулисами.
Вы полностью изолированы от как разработчик.
Итак, давайте поговорим о некоторые из случаев использования
что мы бежим в в играх, общая игровые сценарии, лидеров.
Итак, вы получили пользователи в ближайшие, в BoardNames, что они
на, баллы для этого пользователя.
Мы могли бы быть хэширования на UserID, а то у нас ассортимент на игру.
Таким образом, каждый пользователь хочет видеть Все игры он играл
и все его наивысший балл по всей игры.
Так что его личная лидеров.
>> Теперь я хочу, чтобы пойти и я хочу, чтобы get-- так что я получаю эти личные лидеров.
То, что я хочу сделать, это пойти получить верхняя оценка для всех пользователей.
Так как я делаю это?
Когда мой рекорд хэшируется на Этот идентификатор, варьировались от игры,
а я собираюсь идти вперед и реструктуризации, создать GSI,
и я собираюсь провести реструктуризацию этих данных.
>> Теперь я собираюсь, чтобы прояснить на BoardName, что игра.
И я собираюсь в диапазоне от наивысший балл.
А теперь я создал различные ведра.
Я использую ту же таблицу, те же самые данные. пункт
Но я создаю ведро, что дает мне агрегация наивысший балл по игре.
>> И я могу запросить эту таблицу чтобы получить эту информацию.
Так я установил, что образец запроса до поддерживаться вторичного индекса.
Теперь они могут быть отсортированы по BoardName и сортируются по TopScore, в зависимости от.
Таким образом, вы можете видеть, это типа прецедентов вы получите в играх.
Еще один хороший вариант использования мы получаем в играх это награды и кто выиграл награды.
И это большой кейс где мы называем разреженных индексов.
Редкие индексы являются Способность генерировать
индекс, который не обязательно содержит каждый пункт на столе.
И почему бы нет?
Поскольку атрибут, который будучи индексированный не существует по каждому пункту.
>> Таким образом, в этот конкретный использовать случай, я говорю,
Вы знаете, что я собираюсь создать атрибут премии.
И я собираюсь дать каждому пользователю что имеет награды, которые приписывают.
Люди, которые не имеют награды не будет иметь этот атрибут.
Поэтому, когда я создать Индекс, только пользователи
которые собираются, чтобы показать в индексе
те, которые на самом деле выиграли награды.
Так что это отличный способ, чтобы иметь возможность создать отфильтрованные индексы,
очень, очень избирательно, что не должны индексировать всю таблицу.
>> Так мы получаем мало времени здесь.
Я собираюсь идти вперед и пропустить , и пропустить этот сценарий.
Поговорите немного about--
>> АУДИТОРИЯ: Могу ли я задать быстрый вопрос?
Одним из них является тяжелым написать?
РИК Хулихэном: Что такое?
АУДИТОРИЯ: Написать тяжелым.
РИК Хулихэном: Написать тяжелым.
Дайте-ка подумать.
>> АУДИТОРИЯ: Или это не то, что вы можете просто
Голос в считанные секунды?
РИК Хулихэном: Мы идем через сценарии голосования.
Это не так уж плохо.
Есть ли у вас, ребята, есть несколько минут?
ОК.
>> Таким образом, мы будем говорить о голосовании.
Так в режиме реального времени голосования, у нас есть Требования для голосования.
Требования, которые мы позволить каждый человек, чтобы голосовать только один раз.
Мы хотим, чтобы никто не сможет изменить свой голос.
Мы хотим, агрегацию в режиме реального времени и аналитика для демографии
что мы собираемся, чтобы быть показывая пользователей на сайте.
>> Подумайте об этом сценарии.
Мы много работаем реальности Телевизор показывает, где они
делает эти точный тип вещей.
Таким образом, вы можете думать о сценарии, у нас есть миллионы и миллионы
девушки подросткового там с их сотовых телефонов
и голосование, и голосование, и голосование для тех, кто их
найти, чтобы быть самым популярным.
Так вот некоторые из Требования у нас закончились.
>> И поэтому первый взять в решении этой проблемы
будет строить очень простое приложение.
Так что я получил это приложение.
У меня есть несколько избирателей там.
Они приходят в, они попали в приложение голосования.
У меня есть сырое голосов таблицу Я просто свалка эти голоса в.
Я есть совокупность голосов таблица,
сделает мои аналитики и демографии, и мы поставим все это там.
>> И это здорово.
Жизнь хороша.
Жизнь хорошая, пока мы не узнаем, что всегда есть только один или два
люди, которые пользуются популярностью на выборах.
Там только один или две вещи, что люди действительно заботятся о.
И если вы голосуете на масштаб, вдруг я
будет молотком ад из два кандидата, один или два кандидата.
Очень ограниченное число пунктов люди считают, чтобы быть популярным.
>> Это не хороший дизайн модели.
Это на самом деле очень плохо шаблон
потому что это создает то, что мы говорили о которой было горячие клавиши.
Горячие клавиши являются чем-то нам не нравится.
>> Итак, как мы это исправить?
И в самом деле, то, как исправить это принимая те кандидатов ведра
и для каждого кандидата мы имеем, мы собираемся добавить случайное значение,
то, что мы знаем, случайная Значение между одним и 100,
между 100 и 1000, или от одного до 1000,
Однако многие случайные величины вы хотите добавить в конец этого кандидата.
>> И что я действительно сделал то?
Если я использую идентификатор кандидата как ведро для совокупных голосов,
если я добавил случайный Количество до конца, что,
Я создал уже 10 ведер, А сто ведер, тысячи ведра
что я агрегирования голосов поперек.
>> Так что у меня миллионы и миллионы, и миллионы записей в ближайшие
для этих кандидатов, я сейчас распространяется эти голоса через кандидат A_1
через кандидат A_100, потому что каждый раз, когда голосование идет в,
Я генерации случайных Значение между одним и 100.
Я лавируя его на конце Кандидат, который человек голосующих за.
Я сброс его в этом ведре.
>> Теперь на обратной, я знаю, что я получил сто ведер.
Так что, когда я хочу, чтобы идти вперед и агрегировать голосов,
Я читал от всех этих ведрах.
Так что я идти вперед и добавить.
И тогда я разброс собрать где я выхожу и говорю эй,
Вы знаете, что, ключ этого кандидата пространств более ста ведра.
Я собираюсь собрать все голосов от тех ста ведра.
Я собираюсь объединить им, и я собираюсь сказать,
Кандидата в настоящее время Общая Подсчет голосов от х.
>> Теперь оба записи запрос и запрос чтения
красиво распределены потому что я пишу по
и я читаю на сотни ключей.
Я не пишу и читать по одному ключу в настоящее время.
Так что это большой рисунок.
>> Это на самом деле, вероятно, один из наиболее важных дизайн
шаблоны для масштаба в NoSQL.
Вы увидите этот тип шаблон в любой вкус.
MongoDB, DynamoDB, это не Дело, все мы должны сделать это.
Потому что, когда вы имеете дело с тех огромных скоплений,
Вы должны выяснить, путь к распространять их по всей ведра.
Так что это, как вы делаете это.
Ладно, так, что Вы делаете прямо сейчас
это вы будете торговать с чтения Стоимость для записи масштабируемости.
Стоимость моей чтения немного сложнее
и я должен идти читать из сто ведер вместо одного.
Но я могу написать.
И моя пропускная способность, моя записи пропускная способность невероятно.
Так что, как правило, является ценным Техника для масштабирования DynamoDB,
или любая база данных NoSQL по этому вопросу.
Таким образом, мы выяснили, как масштабировать его.
И мы поняли, как ликвидировать наши горячие клавиши.
И это фантастика.
И мы получили эту хорошую систему.
И это дает нам очень правильную голосование потому что у нас запись голосов де-простофилю.
Он построен в DynamoDB.
Мы говорили о условных прав.
>> Когда избиратель приходит, ставит вставка на столе,
они вставляют их избирателей ID, если они пытаются вставить другой голос,
Я делаю условное записи.
Скажите только написать это если это не существует.
Поэтому, как только я вижу, что что голосование в хит таблицу,
никто не будет в состоянии поставить свой голос в.
И это фантастика.
И мы увеличивая Наш кандидат счетчики.
И мы делаем все демографические и все такое.
Но что произойдет, если мой Приложение падает?
Теперь все вдруг голосов идут, и я
не знаю, если они получают обрабатываются в моих аналитики и демографии
больше.
И когда приложение возвращается вверх, как
, черт возьми, я знаю, что есть голоса были обработаны и где я могу начать?
>> Так что это реальная проблема, когда вы начинают смотреть на этого типа сценария.
И как мы решим, что?
Мы решаем ее с тем, что мы позвонить DynamoDB потоков.
Потоки заказывается время и распределяют журнал изменений каждого доступа
к столу, каждый написать Доступ к таблице.
Любые данные, которые написал в Таблица показывает вверх в потоке.
>> Это в основном очереди 24 часа.
Предметы ударил поток, они живут в течение 24 часов.
Они могут быть прочитаны несколько раз.
Гарантированно будут доставлены только один раз в поток,
может быть прочитан п число раз.
Так многие процессы, однако вы хотите потреблять эти данные, вы можете потреблять.
Он появится каждое обновление.
Каждый записи будет только появляются раз в потоке.
Таким образом, вы не должны беспокоиться об обработке его дважды
из того же процесса.
>> Это строго приказал каждому пункту.
Когда мы говорим, время заказать и распределяют,
Вы увидите в разделе на поток.
Вы увидите предметы, обновления в порядке.
Мы не гарантируя на потоке, что ты
собирается получить каждую сделку в порядке через предметы.
>> Так потоки идемпотентная.
Разве мы все знаем, что идемпотент означает?
Идемпотентный означает, что вы можете сделать это снова, и снова, и снова.
Результат будет тот же.
>> Потоки идемпотентны, но они должны быть
играл с отправной точки, где бы вы ни выбрали, до конца,
или они не будут приводить в тех же значений.
>> То же самое с MongoDB.
MongoDB имеет конструкцию они называют oplog.
Это точно такой же конструкцией.
Многие базы данных NoSQL есть эту конструкцию.
Они используют его, чтобы делать вещи, как репликация, которая
именно то, что мы делаем с потоками.
АУДИТОРИЯ: Может быть, еретическим вопрос, но вы
говорить о приложения делаешь так далее.
Ручьи гарантированно не возможно идти вниз?
РИК Хулихэном: Да, потоки гарантированно никогда не войдет.
Мы управлять инфраструктурой за. потоки автоматически
развернуть в их авто масштабирования группы.
Мы пойдем через маленький немного о том, что происходит.
>> Я не должен сказать, что они не гарантированно никогда не идут вниз.
Элементы гарантируется появляются в потоке.
И поток будет доступен.
Так что идет вниз или возвращается вверх, что происходит внизу.
Это covers-- это нормально.
Ладно, так что вы получите разные Типы вид на экране.
Типы мнение, что важны к программист, как правило, являются, что это было?
Я старый вид.
Когда обновление парад таблицу, она будет нажать прежнию к потоку
так что данные можно заархивировать, или изменение контроль, идентификация изменения, изменения
Управление.
>> Новый образ, то, что это теперь, после обновление, это другой тип зрения
вы можете получить.
Вы можете получить оба старые и новые образы.
Может быть, я хочу их обоих.
Я хочу, чтобы посмотреть, что это было.
Я хочу, чтобы посмотреть, что он изменился.
>> У меня есть тип соответствия процесса, который работает.
Он должен убедиться, что когда эти вещи меняются,
что они в определенных пределах или в течение определенных параметров.
>> И тогда, возможно, я только нужно знать, что изменилось.
Меня не волнует, какой элемент изменился.
Мне не нужно, чтобы знать какие атрибуты изменилось.
Мне просто нужно знать, что детали прикосновения.
Таким образом, эти типы видом что вы получаете от потока
и вы можете взаимодействовать с.
>> Приложение, потребляет поток,
это своего рода, как эта работает.
Клиент DynamoDB попросить передавать данные в таблицы.
Потоки развернуть на то, что мы называем осколки.
Осколки масштабируются независимо от таблицы.
Они не выстраиваются полностью к разделам вашего стола.
И причина, почему это потому что они выстраиваются
с мощностью, ток Емкость таблицы.
>> Они используют в своих собственного авто масштабирование группы,
и они начинают вращаться из зависимости на сколько записи идут в,
сколько reads-- на самом деле это пишет.
Там нет reads-- но как многие записи идут в.
>> А потом на спине конец, мы имеем то, что
вызвать KCL, или библиотека Kinesis клиента.
Кинезис является поток данных Технология обработки от Amazon.
И потоки построен на этом.
>> Таким образом, вы использовать включен то, KCL Приложение для чтения поток.
Библиотека Кинезис Клиент фактически управляет работников для вас.
И это также делает некоторые интересные вещи.
Это создаст несколько таблиц до в табличном DynamoDB
отслеживать, какие элементы были обработаны.
Так что это путь, если он падает назад, если это падает и приходит и получает
стоял обратно, он может определить, где это было в обработке потока.
>> Это очень важно, когда Вы говорите о репликации.
Мне нужно знать, что был данные были обработаны
и какие данные еще должны быть обработаны.
Таким образом, библиотека, KCL для потоков будет дать вам много этой функциональности.
Он заботится о всех хозяйством.
Он стоит на работника для каждого осколка.
Это создает административную таблицу для каждого осколка, для каждого работника.
И, как те работники огонь, они поддерживают эти таблицы
так что вы знаете эту запись был читать и обрабатываются.
А потом, что путь, если процесс умирает и возвращается в Интернете,
он может возобновить право, где он снял.
>> Поэтому мы используем это для кросс-регион репликации.
Много клиентов есть потребность в перемещать данные или части своих таблиц данных
вокруг различных регионах.
Есть девять регионов во всем мире.
Так что может быть я need-- может есть пользователи в Азии, пользователи
на восточном побережье Соединенных Штатов.
Они имеют различные данные, что Необходимо локально распределенной.
И, может быть, пользователь рейсы из Азия к США,
и я хочу, чтобы повторить его данные с ним.
Так что, когда он получает от самолета, он имеет хороший опыт, используя свой мобильный приложение.
>> Можно использовать перекрестную область Библиотека репликации для этого.
В основном у нас есть при условии, две технологии.
Один это консольное приложение вы можете встать на вашем экземпляре EC2.
Она работает чисто репликации.
А потом мы дали вам библиотеку.
Библиотека вы можете использовать, чтобы построить собственное приложение, если вам
хочу сделать сумасшедшие вещи с этим data-- фильтр, повторить только его часть,
вращать данные, переместить его в отличается стол, так далее, и так далее.
Так что вроде как это выглядит.
>> DynamoDB Потоки могут быть обрабатываются, что мы называем Lambda.
Мы уже упоминали немного о событии управляемые архитектуры приложений.
Лямбда является ключевым компонентом этого.
Лямбда-код, который стреляет по требованию в ответ на конкретное событие.
Один из этих событий может быть появляясь на потоке запись.
Если запись на потоке появляется, мы будем называть эту функцию Java.
Ну, это JavaScript, и лямбда поддерживает Node.js, Java, Python,
и скоро поддерживать другие языки, а также.
И достаточно сказать, что это чистый код.
написать в Java, вы определяете класс.
Вы нажимаете на JAR вверх в Lambda.
А потом вы задаете, какой класс называть в ответ на событие, которое.
И тогда инфраструктура Лямбда за который будет работать этот код.
>> Этот код может обрабатывать записи прочь потока.
Это может делать все, что хочет с ней.
В этом конкретном примере, все мы действительно делаете входа атрибуты.
Но это только код.
Код может сделать что-нибудь, не так ли?
>> Таким образом, вы можете вращать эти данные.
Вы можете создавать производные вид.
Если это структура документа, Вы можете сгладить структуру.
Вы можете создать альтернативные индексы.
Все виды вещей, вы можете делать с DynamoDB потоков.
>> И в самом деле, это, как это выглядит.
Таким образом, вы получаете эти обновления в ближайшие.
Они сходит строку.
Они считываются функцией Lambda.
Они вращая данные и толкая его в производных таблицах,
уведомив внешних систем изменения, и передавая данные в ElastiCache.
>> Мы говорили о том, как поставить кэш перед базе данных для этой продаж
сценарий.
Ну, что произойдет, если я обновить описание товара?
Ну, если я был Лямбда Функция работает на этом столе,
если я обновить описание товара, он будет подобрать запись с потоком,
и это обновление ElastiCache Экземпляр с новыми данными.
Так что это много Что мы делаем с Lambda.
Это клей код, разъемы.
И это на самом деле дает способность к запуску
и работать очень сложных приложений без выделенного сервера
инфраструктура, которая на самом деле здорово.
>> Итак, давайте вернемся к нашему в режиме реального времени архитектура голосования.
Это новый и улучшенный с нашим потоки и, KCL включен приложения.
То же самое, как и раньше, мы можем справиться с любой масштаб выборов.
Нам нравится это.
Мы делаем из разброса собирает по нескольким ведра.
У нас есть оптимизм замок происходит.
Мы можем держать наши избиратели от изменения их голоса.
Они могут голосовать только один раз.
Это фантастика.
В режиме реального времени отказоустойчивость, масштабируемая агрегация настоящее.
Если вещь падает, это знает, где перезапустить себя
когда он возвращается, потому что мы используем приложение KCL.
И тогда мы можем также использовать, что Приложение KCL передавать данные из
в красное смещение для других приложение аналитика, или использование
Эластичный MapReduce для запуска в режиме реального времени потоковое скопления прочь
эти данные.
>> Таким образом, эти вещи, которые мы не говорил о многом.
Но они дополнительная технологии, которые приходят
нести, когда вы ищете на этих типах сценариев.
>> Ладно, так это о аналитика с DynamoDB потоков.
Вы можете собрать де-простофилю Данные, сделать все виды
из хороших вещей, совокупные данные в памяти, создавать производные этих таблиц.
Это огромный кейс что много клиентов
участвуют с, принимая вложенный свойства этих документов JSON
и создания дополнительных индексов.
>> Мы в конце.
Спасибо за подшипник со мной.
Итак, давайте поговорим о Эталонная архитектура.
DynamoDB сидит в середине, так большая часть инфраструктуры AWS.
В общем, вы можете подключить его до всего, что вы хотите.
Приложения на платформе Динамо включают Лямбда, ElastiCache, CloudSearch,
передать данные из упругой в MapReduce, экспорт импорт из DynamoDB
в S3, всех видов технологических процессов.
Но, наверное, самый лучший что говорить,
и это то, что на самом деле Интересно, когда мы
говорить о приложений, управляемых событиями.
>> Это является примером Внутренний проект
что у нас есть, где мы на самом деле издательство, чтобы собрать результаты обследования.
Таким образом, в электронной связи, что мы пошлем вне, там будет
немного ссылку говоря нажмите здесь, чтобы ответить на обследования.
И когда человек нажимает что ссылка, что происходит
это они тянут вниз безопасный HTML-формы опроса с S3.
Там нет сервера.
Это просто объект S3.
>> Эта форма подходит, загружает в браузере.
Он получил позвоночника.
Он получил комплекс JavaScript что он работает.
Так что это очень богатый приложение работает в браузере клиента.
Они не знают, что они не взаимодействующих с задним сервере.
На данный момент, это все-браузер.
>> Они публикуют результаты к тому, что мы называем Amazon API Gateway.
Шлюз API это просто Web API что вы можете определить и подключить
все, что вы хотите.
В данном конкретном случае, мы подключили к лямбда-функции.
>> Так мой пост операция происходит без сервера.
В основном это шлюза API сидит там.
Это не стоит мне ничего, пока люди Начало публикации на него, верно?
Функция Лямбда просто сидит там.
И это не стоит мне ничего, пока люди начинают дубасить его.
Таким образом, вы можете видеть, как объем увеличивается, что, когда обвинения пришли.
Я не работает сервер 7/24.
>> Так что я тянуть форму вниз из ведра,
и я отправляю через API Шлюз в лямбда-функции.
И тогда Лямбда Функция говорит, вы знаете,
то, что я получил некоторые PIIs, некоторые персональная информация
в этих ответах.
Я получил комментарии, поступающие от пользователей.
Я получил адреса электронной почты.
Я получил имена.
>> Позвольте мне разделить это от.
Я собираюсь генерировать некоторые метаданные от этой записи.
И я собираюсь нажать метаданные в DynamoDB.
И я мог бы зашифровать все данные, и вставьте его в DynamoDB, если я хочу.
Но это легче для меня, в этом использовать случай, чтобы идти вперед и говорит:
Я собираюсь выдвинуть исходные данные в зашифрованном S3 ведра.
Так что я использую встроенный в стороне сервера S3 шифрования и управления ключами от Amazon
Обслуживание так что у меня есть ключ, который может вращаться на очередной интервал,
и я могу защитить, что PII данные как часть всей этой рабочего процесса.
>> Так что я сделал?
Я только что развернута целая приложений и у меня нет сервера.
Так что событийная приложения архитектура делает для вас.
>> Теперь, если вы думаете о прецедент для this--
у нас есть другие клиенты я говорить чтобы об этом кто точной архитектуры
запустить феноменально большие кампании, которые смотрим на это и происходит, о мой.
Потому что сейчас, они могут в основном толкать его там,
пусть эту кампанию просто сидеть там, пока не запускает, а не
придется беспокоиться о фигу Какая инфраструктура
будет там, чтобы поддержать его.
А потом, как только что кампания будет сделано,
это как инфраструктуры просто сразу уходит
потому что действительно нет инфраструктуры.
Это просто код, который сидит на Lambda.
Это просто данные, которые сидит в DynamoDB.
Это удивительный способ для создания приложений.
>> АУДИТОРИЯ: Так это больше, эфемерная, чем это было бы
если он был сохранен на сервере фактической?
>> РИК Хулихэном: Совершенно верно.
Потому что этого экземпляра сервера бы быть 7/24.
Он должен быть доступен для чтобы кто-то реагировать.
Ну думаю, что?
S3 доступен 7/24.
S3 всегда отвечает.
И S3 является очень, очень хорошо на обслуживание до объектов.
Эти объекты могут быть HTML файлы, или Файлы JavaScript, или что вы хотите.
Вы можете запустить очень богатые веб-приложений из S3 ведра, и люди.
>> И так вот идея здесь чтобы получить от пути
мы использовали, чтобы думать об этом.
Мы все привыкли думать, в Условия серверов и хостов.
Это не о том, что больше.
Это об инфраструктуре, как код.
Развертывание кода в облаке, и пусть облако запустить его для вас.
И это то, что AWS пытается сделать.
>> АУДИТОРИЯ: Так ваш золотой коробке в середине в API шлюза не сервер, как,
но вместо этого просто--
>> РИК Хулихэном: Вы можете думать о нем, как сервера фасада.
Все это он будет принимать HTTP запрашивать и сопоставить его с другим процессом.
Это все, что он делает.
И в этом случае, мы отображение это функция лямбда.
Ладно, так что это все, что я получил.
Большое спасибо.
Я ценю это.
Я знаю, мы хотим немного в течение долгого времени.
И, надеюсь, вы, ребята, есть немного информации
что вы можете забрать сегодня.
И я прошу прощения, если я пошел над некоторыми из ваших руководителей,
но есть хороший много фундаментальные базовые знания
Я думаю, что очень ценно для вас.
Так что спасибо вам за то, что мне.
[АПЛОДИСМЕНТЫ]
АУДИТОРИЯ: [неразборчиво] когда вы говорили
Вы должны были пройти через вещи от начала до конца
чтобы получить правильные значения или те же значения,
Как бы значения изменить, если [неразборчиво].
>> РИК Хулихэном: О, идемпотентным?
Как бы изменить значения?
Ну, потому что, если я не запустить все это путь до конца,
то я не знаю, какие изменения были сделаны в последней мили.
Это не собирается быть Те же данные, как то, что я увидел.
АУДИТОРИЯ: О, так ты просто не получили весь входной.
РИК Хулихэном: Верно.
Вы должны идти от начала до конца, а затем это
будет последовательной государственной.
Круто.
>> АУДИТОРИЯ: Таким образом, вы показали нам DynamoDB можно сделать документ или ключевое значение.
И мы потратили много времени на значение ключа с хэш и пути
чтобы перевернуть его вокруг.
Когда вы смотрели на этих таблицах, является то, что оставив подхода документа?
>> РИК Хулихэном: Я бы не говорят оставив его позади.
>> АУДИТОРИЯ: Они были отделены от the--
>> РИК Хулихэном: С документа подход, тип документа в DynamoDB
просто думаю, как другой атрибут.
Это атрибут, который содержит иерархическую структуру данных.
А потом в запросах, Вы можете использовать свойства
из этих объектов с использованием Object Notation.
Так что я могу фильтровать по вложенным свойство документа JSON.
АУДИТОРИЯ: Так любое время я сделать документ подход,
Я могу сортировать прибыть в tabular--
АУДИТОРИЯ: Совершенно верно.
Аудитория: --indexes и вещи, которые вы только что говорили о.
РИК Хулихэном: Да, индексы и все, что,
если вы хотите, чтобы индекс в свойства JSON,
так, что мы должны сделать это, если Вы вставляете объект JSON или документ
в Динамо, вы должны использовать потоки.
Потоки будут читать ввод.
Вы бы получить, что JSON объект, и вы бы сказать, хорошо,
что свойство Я хочу, чтобы индекс?
>> Вы можете создать производную таблицу с.
Теперь это, как он работает сейчас.
Мы не позволяем индексировать непосредственно те свойства.
>> АУДИТОРИЯ: Tabularizing документы.
>> РИК Хулихэном: Ровно, уплощение это, tabularizing его, точно.
Вот то, что вы с ним делать.
>> АУДИТОРИЯ: Спасибо.
>> РИК Хулихэном: Да, абсолютно, спасибо.
АУДИТОРИЯ: Так что это своего рода Монго отвечает Redis classifers.
>> РИК Хулихэном: Да, это много, как, что.
Это хорошее описание для этого.
Круто.