1
00:00:00,000 --> 00:00:04,969
>> [Играет музыка]

2
00:00:04,969 --> 00:00:06,010
РИК Хулихэном: Ладно.

3
00:00:06,010 --> 00:00:06,600
Всем привет.

4
00:00:06,600 --> 00:00:07,670
Меня зовут Рик Houlihan.

5
00:00:07,670 --> 00:00:10,330
Я старший основной
Решения архитектор AWS.

6
00:00:10,330 --> 00:00:14,070
Я сосредотачиваюсь на NoSQL и
Технологии DynamoDB.

7
00:00:14,070 --> 00:00:16,930
Я сегодня здесь, чтобы поговорить с
Вы немного о них.

8
00:00:16,930 --> 00:00:18,970
>> Мой фон
в первую очередь в слое данных.

9
00:00:18,970 --> 00:00:21,390
Я провел половину своей разработки
Карьера писать базу данных,

10
00:00:21,390 --> 00:00:25,930
доступа к данным, решения
для различных применений.

11
00:00:25,930 --> 00:00:30,000
Я был в Cloud виртуализации
в течение примерно 20 лет.

12
00:00:30,000 --> 00:00:33,460
Поэтому, прежде чем облако Облако,
мы привыкли называть его полезность вычислений.

13
00:00:33,460 --> 00:00:37,170
А идея была, это как
PG & E, вы платите за то, что вы используете.

14
00:00:37,170 --> 00:00:38,800
Сегодня мы называем это облако.

15
00:00:38,800 --> 00:00:41,239
>> Но на протяжении многих лет, я работал
на пару компаний

16
00:00:41,239 --> 00:00:42,530
Вы вероятно никогда не слышали.

17
00:00:42,530 --> 00:00:47,470
Но я составил список технических
достижения, я думаю, вы бы сказать.

18
00:00:47,470 --> 00:00:51,620
У меня восемь патентов в системах Cloud
Виртуализация, микропроцессор дизайн,

19
00:00:51,620 --> 00:00:54,440
Комплекс обработки событий,
и других областях, а также.

20
00:00:54,440 --> 00:00:58,290
>> Так в эти дни, я остановлюсь в основном на NoSQL
технологии и новое поколение

21
00:00:58,290 --> 00:00:59,450
база данных.

22
00:00:59,450 --> 00:01:03,370
И это, как правило то, что я собираюсь
чтобы быть здесь и разговариваю с вами сегодня о.

23
00:01:03,370 --> 00:01:06,030
Так что вы можете ожидать
от этой сессии,

24
00:01:06,030 --> 00:01:08,254
мы пойдем через вкратце
История обработки данных.

25
00:01:08,254 --> 00:01:10,420
Это всегда полезно
понять, откуда мы пришли

26
00:01:10,420 --> 00:01:12,400
и почему мы, где мы находимся.

27
00:01:12,400 --> 00:01:15,600
И мы будем говорить немного
Немного о технологии NoSQL

28
00:01:15,600 --> 00:01:17,500
с фундаментальной точки зрения.

29
00:01:17,500 --> 00:01:19,870
>> Мы попадем в некоторых
внутренности DynamoDB.

30
00:01:19,870 --> 00:01:24,350
DynamoDB не AWS в не аромат.

31
00:01:24,350 --> 00:01:27,340
Это полностью управляемый и
серверное решение NoSQL.

32
00:01:27,340 --> 00:01:32,420
И мы будем говорить немного о таблице
структура, API, типы данных, индексы,

33
00:01:32,420 --> 00:01:35,177
и некоторые из внутренних
этой DynamoDB технологии.

34
00:01:35,177 --> 00:01:37,760
Мы войдем в некоторые конструкции
шаблоны и лучшие практики.

35
00:01:37,760 --> 00:01:39,968
Мы поговорим о том, как
использовать эту технологию для некоторых

36
00:01:39,968 --> 00:01:41,430
современных приложений.

37
00:01:41,430 --> 00:01:44,820
И тогда мы будем говорить немного
об эволюции или появление

38
00:01:44,820 --> 00:01:48,980
новой парадигмы в программировании
называемые приложения управляемые событиями

39
00:01:48,980 --> 00:01:51,580
и как DynamoDB играет в том, что, как хорошо.

40
00:01:51,580 --> 00:01:54,690
И мы выйдем вам немного
обсуждение Эталонная архитектура

41
00:01:54,690 --> 00:01:59,540
таким образом, мы можем говорить о некоторых
способы можно использовать DynamoDB.

42
00:01:59,540 --> 00:02:04,116
>> Итак, сначала off-- это вопрос
Я слышал много есть, что база данных.

43
00:02:04,116 --> 00:02:06,240
Много людей думают, что они
знаю, что база данных.

44
00:02:06,240 --> 00:02:08,360
Если вы Google, вы увидите, что это.

45
00:02:08,360 --> 00:02:11,675
Это структурированный набор данных, хранящихся
в компьютере, особенно тот, который

46
00:02:11,675 --> 00:02:13,600
доступен в различных направлениях.

47
00:02:13,600 --> 00:02:16,992
Я полагаю, что это хороший
определение современной базы данных.

48
00:02:16,992 --> 00:02:19,450
Но я не люблю его, потому что
это подразумевает несколько вещей.

49
00:02:19,450 --> 00:02:20,935
Это означает, структуру.

50
00:02:20,935 --> 00:02:23,120
И это означает, что он находится на компьютере.

51
00:02:23,120 --> 00:02:25,750
И не сделал базы данных
всегда существует на компьютерах.

52
00:02:25,750 --> 00:02:28,020
Базы данных действительно существовал во многих отношениях.

53
00:02:28,020 --> 00:02:32,000
>> Таким образом, лучшее определение
База данных что-то вроде этого.

54
00:02:32,000 --> 00:02:34,786
База данных организованный
механизм хранения, управления,

55
00:02:34,786 --> 00:02:35,910
и извлечения информации.

56
00:02:35,910 --> 00:02:36,868
Это из About.com.

57
00:02:36,868 --> 00:02:42,080
Так что я хотел этого, потому что это действительно переговоры
о базе данных будучи хранилище,

58
00:02:42,080 --> 00:02:44,800
хранилище
Информация, не обязательно

59
00:02:44,800 --> 00:02:46,780
то, что сидит на компьютере.

60
00:02:46,780 --> 00:02:49,290
И на протяжении всей истории, мы
не всегда компьютеров.

61
00:02:49,290 --> 00:02:52,110
>> Теперь, если я прошу среднем
Разработчик сегодня то, что

62
00:02:52,110 --> 00:02:54,770
база данных, вот и ответ я получаю.

63
00:02:54,770 --> 00:02:56,070
Где-то я могу придерживаться вещей.

64
00:02:56,070 --> 00:02:56,670
Правильно?

65
00:02:56,670 --> 00:02:58,725
И это правда.

66
00:02:58,725 --> 00:02:59,600
Но это прискорбно.

67
00:02:59,600 --> 00:03:02,700
Поскольку база данных действительно
основа современного приложения.

68
00:03:02,700 --> 00:03:04,810
Это основа
из каждого приложения.

69
00:03:04,810 --> 00:03:07,240
И, как вы строите, что
базы данных, как структурировать

70
00:03:07,240 --> 00:03:11,750
что данные будет диктовать, как это
Приложение выполняет, как вы масштабе.

71
00:03:11,750 --> 00:03:14,640
>> Так много моей работы сегодня
имеет дело с тем, что

72
00:03:14,640 --> 00:03:17,180
происходит, когда разработчики
этот подход

73
00:03:17,180 --> 00:03:19,510
и дело с последствиями
приложения, которое

74
00:03:19,510 --> 00:03:24,966
Теперь масштабирования за оригинал
Цель и страдания от плохого дизайна.

75
00:03:24,966 --> 00:03:26,840
Так, мы надеемся, когда вам
ходьбы сегодня, вы будете

76
00:03:26,840 --> 00:03:29,010
есть несколько инструментов, в
Ваш пояс, который будет держать вас

77
00:03:29,010 --> 00:03:32,566
от принятия тех же ошибок.

78
00:03:32,566 --> 00:03:33,066
Отлично.

79
00:03:33,066 --> 00:03:36,360
Итак, давайте поговорим о немного
сроки технологии баз данных.

80
00:03:36,360 --> 00:03:38,830
Я думаю, что я прочитал
статья не так давно

81
00:03:38,830 --> 00:03:43,020
и он сказал, что-то на lines--
это очень поэтично заявлении.

82
00:03:43,020 --> 00:03:46,590
Это сказал, что история
данных обработка

83
00:03:46,590 --> 00:03:49,350
полный высоких водяных знаков
изобилия данных.

84
00:03:49,350 --> 00:03:49,920
ОК.

85
00:03:49,920 --> 00:03:52,532
Теперь, я думаю, что это своего рода правда.

86
00:03:52,532 --> 00:03:54,990
Но я на самом деле смотреть на это, как
История на самом деле заполнены

87
00:03:54,990 --> 00:03:56,820
с высокой водяной знак давления данных.

88
00:03:56,820 --> 00:04:00,040
Поскольку скорость передачи данных
проглатывание не идет вниз.

89
00:04:00,040 --> 00:04:01,360
Это только идет вверх.

90
00:04:01,360 --> 00:04:03,670
>> И инновации происходит, когда
мы видим давление данных, который

91
00:04:03,670 --> 00:04:07,825
это количество данных, которые
в настоящее время в поступающей в систему.

92
00:04:07,825 --> 00:04:12,027
И это не может быть обработан
эффективно ни во времени, или в стоимости.

93
00:04:12,027 --> 00:04:14,110
И вот, когда мы начинаем
посмотреть на давление данных.

94
00:04:14,110 --> 00:04:15,920
>> Поэтому, когда мы смотрим на
Первая база данных, это

95
00:04:15,920 --> 00:04:17,180
это тот, который был между нашими ушами.

96
00:04:17,180 --> 00:04:18,310
Мы все рождены с ним.

97
00:04:18,310 --> 00:04:19,194
Это хорошая база.

98
00:04:19,194 --> 00:04:21,110
Он имеет высокую доступность.

99
00:04:21,110 --> 00:04:21,959
Это всегда.

100
00:04:21,959 --> 00:04:23,930
Вы всегда можете получить его.

101
00:04:23,930 --> 00:04:24,890
>> Но это один пользователь.

102
00:04:24,890 --> 00:04:26,348
Я не могу поделиться своими мыслями с вами.

103
00:04:26,348 --> 00:04:28,370
Вы не можете собраться с мыслями
когда вы хотите их.

104
00:04:28,370 --> 00:04:30,320
И их abilitiy не так хорошо.

105
00:04:30,320 --> 00:04:32,510
Мы забываем вещи.

106
00:04:32,510 --> 00:04:36,540
То и дело, один из нас листья
и переходит к другому существования

107
00:04:36,540 --> 00:04:39,110
и мы потеряем все
что было в этой базе данных.

108
00:04:39,110 --> 00:04:40,640
Так что не все так хорошо.

109
00:04:40,640 --> 00:04:43,189
>> И это работало хорошо в течение долгого времени
когда мы были еще в день

110
00:04:43,189 --> 00:04:46,230
когда все мы действительно нужно знать это
куда мы идем, чтобы пойти на завтра

111
00:04:46,230 --> 00:04:49,630
или там, где мы собираем лучшую еду.

112
00:04:49,630 --> 00:04:52,820
Но, как мы начали расти как
цивилизация и правительство начало

113
00:04:52,820 --> 00:04:55,152
прийти в бытие, и
бизнес начал развиваться,

114
00:04:55,152 --> 00:04:57,360
мы начали понимать, мы
нужно немного больше, чем

115
00:04:57,360 --> 00:04:58,210
мы могли бы в нашей голове.

116
00:04:58,210 --> 00:04:58,870
Отлично?

117
00:04:58,870 --> 00:05:00,410
>> Нам нужна систем записи.

118
00:05:00,410 --> 00:05:02,220
Нам нужно места, чтобы быть в состоянии хранить данные.

119
00:05:02,220 --> 00:05:05,450
Таким образом, мы начали писать документы,
создания библиотек и архивов.

120
00:05:05,450 --> 00:05:08,000
Мы начали разрабатывает
Система бухгалтерских книга.

121
00:05:08,000 --> 00:05:12,200
И, что система подсчета бухгалтерской книги
побежал мир в течение многих веков,

122
00:05:12,200 --> 00:05:15,580
и, возможно, даже тысячелетий, как
мы вроде выросли до точки

123
00:05:15,580 --> 00:05:18,420
где, что загрузка данных превзошли
способность этих систем

124
00:05:18,420 --> 00:05:19,870
чтобы иметь возможность содержать его.

125
00:05:19,870 --> 00:05:22,070
>> И это на самом деле произошло в 1880 году.

126
00:05:22,070 --> 00:05:22,570
Правильно?

127
00:05:22,570 --> 00:05:24,390
В 1880 переписи населения США.

128
00:05:24,390 --> 00:05:26,976
Это действительно, где поворот
указывают современной обработке данных.

129
00:05:26,976 --> 00:05:28,850
Это точка, в
которых объем данных

130
00:05:28,850 --> 00:05:32,060
что в настоящее время, собранных
Правительство США попал в точку,

131
00:05:32,060 --> 00:05:34,005
где потребовалось восемь лет, чтобы обработать.

132
00:05:34,005 --> 00:05:36,350
>> Теперь, восемь years-- как
Вы знаете, переписи

133
00:05:36,350 --> 00:05:39,180
работает каждые 10 years-- так что это
Совершенно очевидно, что по времени мы

134
00:05:39,180 --> 00:05:41,419
получил переписи 1890,
количество данных, которые

135
00:05:41,419 --> 00:05:43,210
собирался быть обработаны
правительством было

136
00:05:43,210 --> 00:05:46,335
собирается превышать 10 лет, что это
потребуется, чтобы запустил новую переписи.

137
00:05:46,335 --> 00:05:47,250
Это было проблемой.

138
00:05:47,250 --> 00:05:49,000
>> Таким образом, парень по имени Герман
Холлерит пришли вместе

139
00:05:49,000 --> 00:05:52,640
и он изобрел блок записи удар
карты, читатель перфокарты, перфокарты

140
00:05:52,640 --> 00:05:58,420
табулятор, и сопоставление
механизмы для этой технологии.

141
00:05:58,420 --> 00:06:01,860
И, что компания, которая он сформировал на
Время, вместе с парой других,

142
00:06:01,860 --> 00:06:05,450
фактически стал одним из столпов
небольшая компания, мы знаем сегодня называется IBM.

143
00:06:05,450 --> 00:06:08,417
>> Так IBM изначально была в
бизнес базы данных.

144
00:06:08,417 --> 00:06:09,750
И это действительно то, что они сделали.

145
00:06:09,750 --> 00:06:11,110
Они сделали обработку данных.

146
00:06:11,110 --> 00:06:15,400
>> Как же так распространением удар
карты, гениальный механизмы

147
00:06:15,400 --> 00:06:18,560
быть в состоянии использовать что
Технология опроса отсортированные результирующих наборов.

148
00:06:18,560 --> 00:06:20,726
Вы можете увидеть в этой картине
есть у нас есть little--

149
00:06:20,726 --> 00:06:23,970
это немного small-- но вы можете видеть
очень остроумный механизм механический

150
00:06:23,970 --> 00:06:26,970
где у нас есть удар карточной колоды.

151
00:06:26,970 --> 00:06:28,720
И кто-то берет
немного отвертка

152
00:06:28,720 --> 00:06:31,400
и придерживаться через
Слоты и подняв ее

153
00:06:31,400 --> 00:06:34,820
чтобы получить, что матч, что
отсортировано набор результатов.

154
00:06:34,820 --> 00:06:36,270
>> Это объединение.

155
00:06:36,270 --> 00:06:38,690
Мы делаем это все время
сегодня в компьютере,

156
00:06:38,690 --> 00:06:40,100
где вы его в базу данных.

157
00:06:40,100 --> 00:06:41,620
Мы использовали, чтобы сделать это вручную, верно?

158
00:06:41,620 --> 00:06:42,994
Люди ставят эти вещи вместе.

159
00:06:42,994 --> 00:06:45,440
И это было распространение
из этих перфокарт

160
00:06:45,440 --> 00:06:50,070
в то, что мы назвали барабанов данных
и барабаны данных, бумажные ленты.

161
00:06:50,070 --> 00:06:55,980
>> Обработка данных промышленности приняли
урок от игроков фортепиано.

162
00:06:55,980 --> 00:06:57,855
Игрок пианино назад на
поворот века

163
00:06:57,855 --> 00:07:02,100
использовать использовать бумажные барабаны с пазами
рассказывать его, какие клавиши, чтобы играть.

164
00:07:02,100 --> 00:07:05,380
Так что технологии был адаптирован
в конечном итоге, чтобы сохранить цифровые данные,

165
00:07:05,380 --> 00:07:08,070
потому что они могли бы поставить эти данные
на те бумаги ленточных барабанов.

166
00:07:08,070 --> 00:07:10,870
>> Теперь, в результате чего данные
был actually-- как

167
00:07:10,870 --> 00:07:14,960
доступ эти данные непосредственно был
зависит от того, как вы сохранили его.

168
00:07:14,960 --> 00:07:17,825
Так что, если я положил данные на ленте,
Я имел доступ к данным, линейно.

169
00:07:17,825 --> 00:07:20,475
Я должен был свернуть весь
Лента для доступа ко всем данным.

170
00:07:20,475 --> 00:07:22,600
Если я ставлю данные в удар
карты, я мог бы получить доступ к его

171
00:07:22,600 --> 00:07:26,270
в немного более случайным
мода, может быть, не так быстро.

172
00:07:26,270 --> 00:07:30,770
>> Но были ограничения в том, как мы
Доступ к данным на основе, как было сохранено.

173
00:07:30,770 --> 00:07:32,890
И так это было проблемой
вдаваясь в 50-х.

174
00:07:32,890 --> 00:07:37,890
Опять же, мы можем начать видеть, что, как мы
разработка новых технологий для обработки

175
00:07:37,890 --> 00:07:41,670
данные, правильно, это открывает
дверь для новых решений,

176
00:07:41,670 --> 00:07:45,852
для новых программ, новая
приложения для этих данных.

177
00:07:45,852 --> 00:07:47,810
И в самом деле, управление
может быть причиной

178
00:07:47,810 --> 00:07:49,435
Поэтому мы разработали некоторые из этих систем.

179
00:07:49,435 --> 00:07:52,290
Но дело быстро стал
водитель за эволюции

180
00:07:52,290 --> 00:07:54,720
современного базе данных и
современная файловая система.

181
00:07:54,720 --> 00:07:56,870
>> Таким образом, следующая вещь, что
подошел было в 50-х

182
00:07:56,870 --> 00:08:00,780
был файловая система и
Развитие случайной хранения доступа.

183
00:08:00,780 --> 00:08:02,050
Это было красиво.

184
00:08:02,050 --> 00:08:06,230
Теперь, все внезапно, мы можем поставить нашу
файлы в любом месте на этих жестких дисков

185
00:08:06,230 --> 00:08:09,760
и мы можем получить доступ к этой информации в случайном порядке.

186
00:08:09,760 --> 00:08:11,950
Мы можем разобрать, что
Информация из файлов.

187
00:08:11,950 --> 00:08:14,920
И мы решили все в мире
Проблемы с обработкой данных.

188
00:08:14,920 --> 00:08:17,550
>> И длилось около 20 или
30 лет до эволюции

189
00:08:17,550 --> 00:08:22,100
реляционной базы данных, которая
когда мир решил, что мы в настоящее время

190
00:08:22,100 --> 00:08:27,940
нужно иметь хранилище, побеждает
разрастание данных по файлу

191
00:08:27,940 --> 00:08:29,540
Системы, которые мы построили. Правильно?

192
00:08:29,540 --> 00:08:34,270
Слишком много данных, распределенных в слишком много
места, де-дублирование данных,

193
00:08:34,270 --> 00:08:37,120
и стоимость хранения был огромен.

194
00:08:37,120 --> 00:08:43,760
>> В 70-х, самый дорогой ресурс
что компьютер был был хранения.

195
00:08:43,760 --> 00:08:46,200
Процессор был
рассматривать как фиксированную стоимость.

196
00:08:46,200 --> 00:08:49,030
Когда я покупаю коробку,
процессор делает некоторую работу.

197
00:08:49,030 --> 00:08:51,960
Это собирается быть спиннинг ли
это на самом деле или нет.

198
00:08:51,960 --> 00:08:53,350
Это действительно понесенных расходов.

199
00:08:53,350 --> 00:08:56,030
>> Но то, что стоило мне как
бизнес хранения.

200
00:08:56,030 --> 00:09:00,020
Если у меня есть, чтобы купить больше дисков в следующем
месяц, что это реальная стоимость, что я платить.

201
00:09:00,020 --> 00:09:01,620
И хранения стоит дорого.

202
00:09:01,620 --> 00:09:05,020
>> Теперь мы быстро вперед 40 лет
и у нас есть другая проблема.

203
00:09:05,020 --> 00:09:10,020
Вычислительных теперь
самый дорогой ресурс.

204
00:09:10,020 --> 00:09:11,470
Хранение дешево.

205
00:09:11,470 --> 00:09:14,570
Я имею в виду, мы можем пойти куда-нибудь на
облако, и мы можем найти дешевое хранение.

206
00:09:14,570 --> 00:09:17,190
Но то, что я не могу найти дешевый вычислительный.

207
00:09:17,190 --> 00:09:20,700
>> Так эволюции сегодня
технологии, технологии баз данных,

208
00:09:20,700 --> 00:09:23,050
действительно сосредоточены вокруг
распределенные базы данных

209
00:09:23,050 --> 00:09:26,960
которые не страдают от
и тот же тип шкалы

210
00:09:26,960 --> 00:09:29,240
Ограничения реляционных баз данных.

211
00:09:29,240 --> 00:09:32,080
Мы поговорим немного о
что это на самом деле означает.

212
00:09:32,080 --> 00:09:34,760
>> Но одна из причин, и
водитель за this-- мы

213
00:09:34,760 --> 00:09:38,290
говорили о давлении данных.

214
00:09:38,290 --> 00:09:41,920
Давление данных является то,
который приводит инноваций.

215
00:09:41,920 --> 00:09:44,610
И если вы посмотрите на более
за последние пять лет,

216
00:09:44,610 --> 00:09:48,180
это схема, какие именно данные
нагрузка по общей предприятия

217
00:09:48,180 --> 00:09:49,640
Похоже, в последние пять лет.

218
00:09:49,640 --> 00:09:52,570
>> И общее правило
эти days-- если вы идете Google--

219
00:09:52,570 --> 00:09:55,290
90% от данных, которые
мы храним сегодня, и это было

220
00:09:55,290 --> 00:09:57,330
генерируется в течение последних двух лет.

221
00:09:57,330 --> 00:09:57,911
ОК.

222
00:09:57,911 --> 00:09:59,410
Теперь, это не тенденция, что нового.

223
00:09:59,410 --> 00:10:01,230
Это тенденция, которая была
выходя за 100 лет.

224
00:10:01,230 --> 00:10:03,438
С тех пор, Холлерит
разработала перфокарты,

225
00:10:03,438 --> 00:10:08,040
мы строили хранилища данных
и сбор данных на феноменальные темпы.

226
00:10:08,040 --> 00:10:10,570
>> Так, за последние 100 лет,
мы видели эту тенденцию.

227
00:10:10,570 --> 00:10:11,940
Это не собирается менять.

228
00:10:11,940 --> 00:10:14,789
Продвигаясь вперед, мы будем видеть
это, если не ускоряется тенденция.

229
00:10:14,789 --> 00:10:16,330
И вы можете видеть, как это выглядит.

230
00:10:16,330 --> 00:10:23,510
>> Если бизнес в 2010 году был один
терабайт данных под управлением,

231
00:10:23,510 --> 00:10:27,080
сегодня это означает, что они
управление 6,5 петабайт данных.

232
00:10:27,080 --> 00:10:30,380
Это 6500 раз больше данных.

233
00:10:30,380 --> 00:10:31,200
И я знаю, что это.

234
00:10:31,200 --> 00:10:33,292
Я работаю с этими предприятиями каждый день.

235
00:10:33,292 --> 00:10:35,000
Пять лет назад я
будет говорить с компаниями

236
00:10:35,000 --> 00:10:38,260
кто бы поговорить со мной о чем боль
это управлять терабайтами данных.

237
00:10:38,260 --> 00:10:39,700
И они будут говорить
мне о том, как мы видим,

238
00:10:39,700 --> 00:10:41,825
что это, вероятно, будет
быть петабайт или два

239
00:10:41,825 --> 00:10:43,030
в течение нескольких лет.

240
00:10:43,030 --> 00:10:45,170
>> Эти же компании
сегодня я встречаюсь с,

241
00:10:45,170 --> 00:10:48,100
и они говорят мне о
Проблема есть ли имеющий управление

242
00:10:48,100 --> 00:10:51,440
десятки, 20 петабайт данных.

243
00:10:51,440 --> 00:10:53,590
Так взрыв
Данные в промышленности

244
00:10:53,590 --> 00:10:56,670
ведет огромная
потребность в более совершенных решений.

245
00:10:56,670 --> 00:11:00,980
И реляционная база данных является
просто не жить до спроса.

246
00:11:00,980 --> 00:11:03,490
>> И так есть линейный
Корреляция между давлением данных

247
00:11:03,490 --> 00:11:05,210
и технические инновации.

248
00:11:05,210 --> 00:11:07,780
История показывает нам,
это, что с течением времени,

249
00:11:07,780 --> 00:11:11,090
всякий раз, когда объем данных
который должен быть обработан

250
00:11:11,090 --> 00:11:15,490
превышает пропускную способность системы
обработать его в разумные сроки

251
00:11:15,490 --> 00:11:18,870
или по разумной цене,
то новые технологии

252
00:11:18,870 --> 00:11:21,080
изобретены, чтобы решить эти проблемы.

253
00:11:21,080 --> 00:11:24,090
Эти новые технологии,
в свою очередь, открыть дверь

254
00:11:24,090 --> 00:11:27,840
на другой набор проблем, который
собирает еще больше данных.

255
00:11:27,840 --> 00:11:29,520
>> Теперь, мы не собираемся останавливаться на этом.

256
00:11:29,520 --> 00:11:30,020
Правильно?

257
00:11:30,020 --> 00:11:31,228
Мы не собираемся останавливаться на этом.

258
00:11:31,228 --> 00:11:31,830
Зачем?

259
00:11:31,830 --> 00:11:35,520
Потому что вы не можете знать все
что нужно знать во Вселенной.

260
00:11:35,520 --> 00:11:40,510
И до тех пор, как мы были живы,
на протяжении всей истории человека,

261
00:11:40,510 --> 00:11:43,440
мы всегда вынуждены знать больше.

262
00:11:43,440 --> 00:11:49,840
>> Так кажется, что каждый дюйм мы движемся
по пути научного открытия,

263
00:11:49,840 --> 00:11:54,620
мы умножения количества данных
что мы должны обработать по экспоненте

264
00:11:54,620 --> 00:11:59,920
как мы раскрыть больше и больше и больше
о внутренних жизни,

265
00:11:59,920 --> 00:12:04,530
о том, как работает Вселенная, о
вождение научное открытие,

266
00:12:04,530 --> 00:12:06,440
и изобретение, что
мы делаем сегодня.

267
00:12:06,440 --> 00:12:09,570
Объем данных, просто
постоянно увеличивается.

268
00:12:09,570 --> 00:12:12,120
Так будучи в состоянии иметь дело с
Эта проблема огромна.

269
00:12:12,120 --> 00:12:14,790

270
00:12:14,790 --> 00:12:17,410
>> Так одна из вещей,
мы смотрим, как, почему NoSQL?

271
00:12:17,410 --> 00:12:19,200
Как NoSQL решить эту проблему?

272
00:12:19,200 --> 00:12:24,980
Ну, реляционные базы данных,
Structured Query Language,

273
00:12:24,980 --> 00:12:28,600
SQL--, что это действительно конструкция из
реляционная database-- эти вещи

274
00:12:28,600 --> 00:12:30,770
оптимизирована для хранения.

275
00:12:30,770 --> 00:12:33,180
>> Назад в 70-е годы, опять же,
Диск стоит дорого.

276
00:12:33,180 --> 00:12:36,990
О подготовке упражнения хранения
на предприятии никогда не заканчивается.

277
00:12:36,990 --> 00:12:37,490
Я знаю.

278
00:12:37,490 --> 00:12:38,020
Я жил его.

279
00:12:38,020 --> 00:12:41,250
Я написал драйвер хранилища для
enterprised суперсервера компания

280
00:12:41,250 --> 00:12:42,470
назад в 90-ых.

281
00:12:42,470 --> 00:12:45,920
И нижняя линия стеллажи другой
Массив хранения данных была только то, что

282
00:12:45,920 --> 00:12:47,600
произошло каждый день на предприятии.

283
00:12:47,600 --> 00:12:49,030
И это никогда не остановился.

284
00:12:49,030 --> 00:12:52,690
Высшее хранения плотность, спрос
за большой плотности хранения,

285
00:12:52,690 --> 00:12:56,340
и для более эффективного хранения
devices-- это никогда не остановился.

286
00:12:56,340 --> 00:13:00,160
>> И NoSQL это отличный технология
потому что он нормализует данные.

287
00:13:00,160 --> 00:13:02,210
Это де-дублирует данные.

288
00:13:02,210 --> 00:13:07,180
Это помещает данные в структуру, которая
агностик каждому модель доступа.

289
00:13:07,180 --> 00:13:11,600
Несколько приложений могут ударить, что
Базы данных SQL, запустить специальные запросы,

290
00:13:11,600 --> 00:13:15,950
и получить данные в форме, что они
нужно обработать для их рабочих нагрузок.

291
00:13:15,950 --> 00:13:17,570
Это звучит фантастически.

292
00:13:17,570 --> 00:13:21,350
Но суть в том, с какой-либо
Система, если это агностик, чтобы все,

293
00:13:21,350 --> 00:13:23,500
он оптимизирован для ничего.

294
00:13:23,500 --> 00:13:24,050
ОК?

295
00:13:24,050 --> 00:13:26,386
>> И это то, что мы получаем с
реляционная база данных.

296
00:13:26,386 --> 00:13:27,510
Он оптимизирован для хранения.

297
00:13:27,510 --> 00:13:28,280
Это нормализуется.

298
00:13:28,280 --> 00:13:29,370
Это реляционная.

299
00:13:29,370 --> 00:13:31,660
Он поддерживает специальные запросы.

300
00:13:31,660 --> 00:13:34,000
И его и масштабирует его по вертикали.

301
00:13:34,000 --> 00:13:39,030
>> Если мне нужно, чтобы получить большую базу данных SQL
или более мощный SQL базы данных,

302
00:13:39,030 --> 00:13:41,090
Я иду купить больший кусок железа.

303
00:13:41,090 --> 00:13:41,600
ОК?

304
00:13:41,600 --> 00:13:44,940
Я работал со многими клиентов
что прошли через крупные обновления

305
00:13:44,940 --> 00:13:48,340
в их SQL инфраструктуры только
чтобы выяснить, шесть месяцев спустя,

306
00:13:48,340 --> 00:13:49,750
они опять вы удара в стену.

307
00:13:49,750 --> 00:13:55,457
И ответ от Oracle или MSSQL
или кто-нибудь еще, это получить больше окно.

308
00:13:55,457 --> 00:13:58,540
Ну, рано или поздно, вы не можете купить
больше окно, и это реальная проблема.

309
00:13:58,540 --> 00:14:00,080
Мы должны на самом деле что-то изменить.

310
00:14:00,080 --> 00:14:01,080
Так где же это работает?

311
00:14:01,080 --> 00:14:06,560
Он хорошо работает в автономном
аналитика, нагрузки OLAP-типа.

312
00:14:06,560 --> 00:14:08,670
И это действительно, где SQL принадлежит.

313
00:14:08,670 --> 00:14:12,540
Теперь, он используется сегодня во многих онлайн
обработку транзакций типа

314
00:14:12,540 --> 00:14:13,330
Приложения.

315
00:14:13,330 --> 00:14:16,460
И это прекрасно работает на
определенный уровень утилизации,

316
00:14:16,460 --> 00:14:18,670
но это просто не масштабировать
так, что NoSQL делает.

317
00:14:18,670 --> 00:14:20,660
И мы будем говорить немного
немного о том, почему, что есть.

318
00:14:20,660 --> 00:14:23,590
>> Теперь, NoSQL, с другой стороны,
более оптимизирован для вычислений.

319
00:14:23,590 --> 00:14:24,540
ОК?

320
00:14:24,540 --> 00:14:26,830
Это не независимым от
шаблон доступа.

321
00:14:26,830 --> 00:14:31,620
Это то, что мы называем де-нормализуется
структура или иерархическую структуру.

322
00:14:31,620 --> 00:14:35,000
Данные в реляционной базе данных
объединились с несколькими столами

323
00:14:35,000 --> 00:14:36,850
производить вид, что вам нужно.

324
00:14:36,850 --> 00:14:40,090
Данные в базе данных NoSQL в
хранится в документе, который

325
00:14:40,090 --> 00:14:42,100
содержит иерархическую структуру.

326
00:14:42,100 --> 00:14:45,670
Все данные, которые обычно
объединились, чтобы произвести эту точку зрения

327
00:14:45,670 --> 00:14:47,160
хранятся в одном документе.

328
00:14:47,160 --> 00:14:50,990
И мы будем говорить немного о
как это работает в паре графиков.

329
00:14:50,990 --> 00:14:55,320
>> Но идея здесь в том, что вы храните
Ваши данные как эти экземпляры видом.

330
00:14:55,320 --> 00:14:56,410
ОК?

331
00:14:56,410 --> 00:14:58,610
Вы масштабировать по горизонтали.

332
00:14:58,610 --> 00:14:59,556
Правильно?

333
00:14:59,556 --> 00:15:02,100
Если мне нужно увеличить
Размер моего NoSQL кластера,

334
00:15:02,100 --> 00:15:03,700
Мне не нужно, чтобы получить большую коробку.

335
00:15:03,700 --> 00:15:05,200
Я получаю еще одну коробку.

336
00:15:05,200 --> 00:15:07,700
И я их вместе кластер,
и я могу шарда эти данные.

337
00:15:07,700 --> 00:15:10,780
Мы поговорим немного о
то, что Sharding есть, быть

338
00:15:10,780 --> 00:15:14,270
возможность масштабирования эту базу данных
по нескольким физическим устройствам

339
00:15:14,270 --> 00:15:18,370
и удалить барьер,
требует, чтобы я масштабирования по вертикали.

340
00:15:18,370 --> 00:15:22,080
>> Так что на самом деле построен для онлайн
обработки транзакций и масштаб.

341
00:15:22,080 --> 00:15:25,480
Там большая разница
здесь между отчетности, верно?

342
00:15:25,480 --> 00:15:27,810
Отчетность, я не знаю,
вопросы, которые я собираюсь задать.

343
00:15:27,810 --> 00:15:28,310
Правильно?

344
00:15:28,310 --> 00:15:30,570
Reporting-- если кто-то из
мой отдел маркетинга

345
00:15:30,570 --> 00:15:34,520
хочет просто-- сколько из моих клиентов
есть эта конкретная характеристика, кто

346
00:15:34,520 --> 00:15:37,850
купил в этом day-- я не знаю
то, что запрос они собираются спросить.

347
00:15:37,850 --> 00:15:39,160
Поэтому мне нужно, чтобы быть агностиком.

348
00:15:39,160 --> 00:15:41,810
>> Теперь, в режиме онлайн
транзакционных приложений,

349
00:15:41,810 --> 00:15:43,820
Я знаю, какие вопросы я спрашиваю.

350
00:15:43,820 --> 00:15:46,581
Я построил приложение для
очень специфический рабочий процесс.

351
00:15:46,581 --> 00:15:47,080
ОК?

352
00:15:47,080 --> 00:15:50,540
Так что, если оптимизировать данные
хранить в поддержку этого рабочего процесса,

353
00:15:50,540 --> 00:15:52,020
это будет быстрее.

354
00:15:52,020 --> 00:15:55,190
И вот почему NoSQL может
действительно ускорить доставку

355
00:15:55,190 --> 00:15:57,710
из этих видов услуг.

356
00:15:57,710 --> 00:15:58,210
Отлично.

357
00:15:58,210 --> 00:16:00,501
>> Итак, мы собираемся, чтобы попасть в
немного теории здесь.

358
00:16:00,501 --> 00:16:03,330
И некоторые из вас, ваши глаза
может вернуться немного.

359
00:16:03,330 --> 00:16:06,936
Но я постараюсь, чтобы сохранить его
также высокий уровень, как я могу.

360
00:16:06,936 --> 00:16:08,880
Так что, если вы находитесь в проекте
Управление, есть

361
00:16:08,880 --> 00:16:12,280
конструкция называется
треугольник ограничений.

362
00:16:12,280 --> 00:16:12,936
ОК.

363
00:16:12,936 --> 00:16:16,060
Треугольник ограничивает диктата
Вы не можете иметь все все время.

364
00:16:16,060 --> 00:16:17,750
Не можете иметь свой пирог и съесть его слишком.

365
00:16:17,750 --> 00:16:22,310
Таким образом, в управлении проектами, что треугольник
ограничения, что вы можете иметь это дешево,

366
00:16:22,310 --> 00:16:24,710
Вы можете иметь это быстро,
или вы можете иметь его хорошо.

367
00:16:24,710 --> 00:16:25,716
Выбери два.

368
00:16:25,716 --> 00:16:27,090
Потому что вы не можете иметь все три.

369
00:16:27,090 --> 00:16:27,460
Правильно?

370
00:16:27,460 --> 00:16:27,820
ОК.

371
00:16:27,820 --> 00:16:28,920
>> Таким образом, вы слышите об этом много.

372
00:16:28,920 --> 00:16:31,253
Это тройной ограничение,
треугольник тройной ограничения,

373
00:16:31,253 --> 00:16:34,420
или железный треугольник является oftentimes--
когда вы говорите с менеджерами проекта,

374
00:16:34,420 --> 00:16:35,420
они будут говорить об этом.

375
00:16:35,420 --> 00:16:37,640
Теперь, базы данных имеют
самостоятельно железный треугольник.

376
00:16:37,640 --> 00:16:40,350
И железный треугольник данных
это то, что мы называем Теорема CAP.

377
00:16:40,350 --> 00:16:41,580
ОК?

378
00:16:41,580 --> 00:16:43,770
>> Теорема CAP диктует
как базы данных работают

379
00:16:43,770 --> 00:16:45,627
под очень специфических условиях.

380
00:16:45,627 --> 00:16:47,460
И мы будем говорить о
что это условие.

381
00:16:47,460 --> 00:16:52,221
Но три точки треугольника,
так сказать, являются С, консистенция.

382
00:16:52,221 --> 00:16:52,720
ОК?

383
00:16:52,720 --> 00:16:56,760
Таким образом, в САР, согласованность означает, что все
клиенты, которые могут получить доступ к базе данных

384
00:16:56,760 --> 00:16:59,084
всегда будет иметь очень
соответствует представление данных.

385
00:16:59,084 --> 00:17:00,750
Никто не собирается увидеть две разные вещи.

386
00:17:00,750 --> 00:17:01,480
ОК?

387
00:17:01,480 --> 00:17:04,020
Если я вижу, базы данных,
Я вижу то же самое представление

388
00:17:04,020 --> 00:17:06,130
как мой партнер, который видит
ту же базу данных.

389
00:17:06,130 --> 00:17:07,470
Вот последовательность.

390
00:17:07,470 --> 00:17:12,099
>> Наличие означает, что если
онлайн базы данных, если это может быть достигнуто,

391
00:17:12,099 --> 00:17:14,760
что все клиенты будут всегда
уметь читать и писать.

392
00:17:14,760 --> 00:17:15,260
ОК?

393
00:17:15,260 --> 00:17:17,010
Так каждый клиент, который
может читать базу данных

394
00:17:17,010 --> 00:17:18,955
всегда смогут чтения
Данные данных и писать.

395
00:17:18,955 --> 00:17:21,819
И если это так,
это доступный система.

396
00:17:21,819 --> 00:17:24,230
>> И третий пункт, что
мы называем терпимости разделов.

397
00:17:24,230 --> 00:17:24,730
ОК?

398
00:17:24,730 --> 00:17:28,160
Означает терпимость раздел
что система работает хорошо

399
00:17:28,160 --> 00:17:32,000
несмотря физической сети
Перегородки между узлами.

400
00:17:32,000 --> 00:17:32,760
ОК?

401
00:17:32,760 --> 00:17:36,270
Так узлы в кластере не может
говорить друг с другом, что происходит?

402
00:17:36,270 --> 00:17:36,880
Отлично.

403
00:17:36,880 --> 00:17:39,545
>> Так реляционные базы данных, выберите--
Вы можете выбрать два из них.

404
00:17:39,545 --> 00:17:40,045
ОК.

405
00:17:40,045 --> 00:17:43,680
Так реляционные базы данных выберите
быть последовательным и доступны.

406
00:17:43,680 --> 00:17:47,510
Если раздел происходит между
в узлы DataNode в хранилище данных,

407
00:17:47,510 --> 00:17:48,831
сбой базы данных.

408
00:17:48,831 --> 00:17:49,330
Правильно?

409
00:17:49,330 --> 00:17:50,900
Это просто идет вниз.

410
00:17:50,900 --> 00:17:51,450
ОК.

411
00:17:51,450 --> 00:17:54,230
>> И вот почему они имеют
расти с большими ящиками.

412
00:17:54,230 --> 00:17:54,730
Правильно?

413
00:17:54,730 --> 00:17:58,021
Потому что, как правило, no--, кластер
базы данных, есть не очень многие из них

414
00:17:58,021 --> 00:17:59,590
которые работают таким образом.

415
00:17:59,590 --> 00:18:03,019
Но большинство баз данных масштаба
по вертикали в одном окне.

416
00:18:03,019 --> 00:18:05,060
Потому что они должны быть
последовательной и доступен.

417
00:18:05,060 --> 00:18:10,320
Если раздел были быть введен,
то вам придется сделать выбор.

418
00:18:10,320 --> 00:18:13,720
Вы должны сделать выбор между
быть последовательным и доступны.

419
00:18:13,720 --> 00:18:16,080
>> И это то, что делают базы данных NoSQL.

420
00:18:16,080 --> 00:18:16,580
Отлично.

421
00:18:16,580 --> 00:18:20,950
Таким образом, база данных NoSQL, его
поставляется в двух вариантах.

422
00:18:20,950 --> 00:18:22,990
Мы have-- хорошо, это
приходит во многих разновидностях,

423
00:18:22,990 --> 00:18:26,140
но он приходит с двумя основными
characteristics-- что

424
00:18:26,140 --> 00:18:30,050
мы называем CP базы данных или
последовательной и раздел толерантности

425
00:18:30,050 --> 00:18:31,040
Система.

426
00:18:31,040 --> 00:18:34,930
Эти ребята делают выбор, что, когда
узлы теряют контакт друг с другом,

427
00:18:34,930 --> 00:18:37,091
мы не собираемся, чтобы позволить
люди больше писать.

428
00:18:37,091 --> 00:18:37,590
ОК?

429
00:18:37,590 --> 00:18:41,855
>> До этого раздела не будут удалены,
записи доступ заблокирован.

430
00:18:41,855 --> 00:18:43,230
Это означает, что они не доступны.

431
00:18:43,230 --> 00:18:44,510
Они последовательны.

432
00:18:44,510 --> 00:18:46,554
Когда мы видим, что
раздел придать себе,

433
00:18:46,554 --> 00:18:48,470
мы теперь соответствует,
потому что мы не собираемся

434
00:18:48,470 --> 00:18:51,517
чтобы изменения данных на два
стороны перегородки самостоятельно

435
00:18:51,517 --> 00:18:52,100
друг от друга.

436
00:18:52,100 --> 00:18:54,130
Мы должны будем
восстановить связь

437
00:18:54,130 --> 00:18:56,930
перед любым обновлением
данные позволили.

438
00:18:56,930 --> 00:18:58,120
ОК?

439
00:18:58,120 --> 00:19:02,650
>> На следующий аромат будет система А.П.,
или доступный и распределяют

440
00:19:02,650 --> 00:19:03,640
Система допуска.

441
00:19:03,640 --> 00:19:05,320
Эти ребята не волнует.

442
00:19:05,320 --> 00:19:06,020
Правильно?

443
00:19:06,020 --> 00:19:08,960
Любой узел, который получает
писать, мы возьмем его.

444
00:19:08,960 --> 00:19:11,480
Так что я тиражирование мои данные
по нескольким узлам.

445
00:19:11,480 --> 00:19:14,730
Эти узлы получить клиент, клиент приходит
в, говорит, что я собираюсь написать некоторые данные.

446
00:19:14,730 --> 00:19:16,300
Узел не говорит, не проблема.

447
00:19:16,300 --> 00:19:18,580
Узел рядом с ним получает
от записи на той же записи,

448
00:19:18,580 --> 00:19:20,405
он собирается сказать не проблема.

449
00:19:20,405 --> 00:19:23,030
Где-то на заднем конце,
что данные собирается повторить.

450
00:19:23,030 --> 00:19:27,360
А потом кто-то собирается реализовать,
э-э-о, они поймут, система, э-э-о,

451
00:19:27,360 --> 00:19:28,870
там было обновление до двух сторон.

452
00:19:28,870 --> 00:19:30,370
Что мы делаем?

453
00:19:30,370 --> 00:19:33,210
И то, что они сделать, это
они делают то, что

454
00:19:33,210 --> 00:19:36,080
позволяет им решить эту состояние данных.

455
00:19:36,080 --> 00:19:39,000
И мы будем говорить о
что в следующем графике.

456
00:19:39,000 --> 00:19:40,000
>> Вещь, чтобы отметить здесь.

457
00:19:40,000 --> 00:19:42,374
И я не собираюсь слишком
много в этом, потому что это

458
00:19:42,374 --> 00:19:43,510
попадает в глубокой теории данных.

459
00:19:43,510 --> 00:19:46,670
Но есть транзакций
рамки,

460
00:19:46,670 --> 00:19:50,680
работает в реляционной системе,
позволяет мне смело сделать обновления

461
00:19:50,680 --> 00:19:53,760
нескольким субъектам в базе данных.

462
00:19:53,760 --> 00:19:58,320
И эти обновления будут происходить
все сразу или не на всех.

463
00:19:58,320 --> 00:20:00,500
И это называется ACID транзакций.

464
00:20:00,500 --> 00:20:01,000
ОК?

465
00:20:01,000 --> 00:20:06,570
>> КИСЛОТА дает нам атомарность, согласованность,
изоляция и долговечность.

466
00:20:06,570 --> 00:20:07,070
ОК?

467
00:20:07,070 --> 00:20:13,550
Это означает, что атомные, сделки, все
мои обновления либо случится, либо нет.

468
00:20:13,550 --> 00:20:16,570
Согласованность означает, что
База данных будет всегда

469
00:20:16,570 --> 00:20:19,780
быть приведены в последовательной
состояние после обновления.

470
00:20:19,780 --> 00:20:23,900
Я никогда не оставит базу данных в
плохое состояние после применения обновления.

471
00:20:23,900 --> 00:20:24,400
ОК?

472
00:20:24,400 --> 00:20:26,720
>> Так что это немного отличается
чем консистенции CAP.

473
00:20:26,720 --> 00:20:29,760
Консистенция CAP означает, что все мои
клиенты всегда могут видеть данные.

474
00:20:29,760 --> 00:20:34,450
КИСЛОТА согласованность означает, что, когда
сделка будет сделано, данные хорошо.

475
00:20:34,450 --> 00:20:35,709
Мои отношения все хорошо.

476
00:20:35,709 --> 00:20:38,750
Я не собираюсь, чтобы удалить родительскую строку
и оставить кучу детей-сирот

477
00:20:38,750 --> 00:20:40,970
В какой-то другой таблицы.

478
00:20:40,970 --> 00:20:44,320
Это не может произойти, если я согласуются
в кислой операции.

479
00:20:44,320 --> 00:20:49,120
>> Изоляция означает, что сделки
всегда будет происходить один за другим.

480
00:20:49,120 --> 00:20:51,920
Конечным результатом данных
будет то же самое состояние

481
00:20:51,920 --> 00:20:54,770
а если этих сделок
которые были выпущены одновременно

482
00:20:54,770 --> 00:20:57,340
были выполнены последовательно.

483
00:20:57,340 --> 00:21:00,030
Так что это параллелизм
контроль в базу данных.

484
00:21:00,030 --> 00:21:04,130
Так в принципе, я не могу увеличить
то же самое значение в два раза с двумя операциями.

485
00:21:04,130 --> 00:21:08,580
>> Но если я говорю добавить 1 к этому значению,
и две сделки приходят в

486
00:21:08,580 --> 00:21:10,665
и попытаться сделать это, один это
собирается получить там первым

487
00:21:10,665 --> 00:21:12,540
а другой-х
собирается попасть после.

488
00:21:12,540 --> 00:21:15,210
Таким образом, в конце концов, я добавил два.

489
00:21:15,210 --> 00:21:16,170
Вы видите, что я имею в виду?

490
00:21:16,170 --> 00:21:16,670
ОК.

491
00:21:16,670 --> 00:21:19,220

492
00:21:19,220 --> 00:21:21,250
>> Прочность довольно проста.

493
00:21:21,250 --> 00:21:23,460
Когда сделка
признается, что это

494
00:21:23,460 --> 00:21:26,100
будет там, даже
если сбой системы.

495
00:21:26,100 --> 00:21:29,230
При том, что система восстанавливается, что
сделка, было совершено

496
00:21:29,230 --> 00:21:30,480
на самом деле происходит, чтобы быть там.

497
00:21:30,480 --> 00:21:33,130
Так вот гарантии
кислоты сделок.

498
00:21:33,130 --> 00:21:35,470
Те, довольно хорошие гарантии
иметь в базе данных,

499
00:21:35,470 --> 00:21:36,870
но они приходят на той стоимости.

500
00:21:36,870 --> 00:21:37,640
Правильно?

501
00:21:37,640 --> 00:21:40,520
>> Потому что проблемы
с этим база

502
00:21:40,520 --> 00:21:44,540
если существует разбиение данных в
набор, я должен принять решение.

503
00:21:44,540 --> 00:21:48,000
Я собираюсь иметь, чтобы
Обновления на одной или другой стороны.

504
00:21:48,000 --> 00:21:50,310
И если это произойдет,
не то я не собираюсь больше

505
00:21:50,310 --> 00:21:52,630
чтобы быть в состоянии поддерживать
эти характеристики.

506
00:21:52,630 --> 00:21:53,960
Они не будут соответствовать.

507
00:21:53,960 --> 00:21:55,841
Они не будут изолированы.

508
00:21:55,841 --> 00:21:58,090
Это где это ломает
для реляционных баз данных.

509
00:21:58,090 --> 00:22:01,360
Это причина, реляционная
Базы данных масштабирования по вертикали.

510
00:22:01,360 --> 00:22:05,530
>> С другой стороны, мы имеем
то, что называется технологическая база.

511
00:22:05,530 --> 00:22:07,291
И это ваши NoSQL баз данных.

512
00:22:07,291 --> 00:22:07,790
Отлично.

513
00:22:07,790 --> 00:22:10,180
Таким образом, мы имеем CP, базы данных AP.

514
00:22:10,180 --> 00:22:14,720
И это то, что вы называете основном
доступны, мягкий государство, в конечном счете,

515
00:22:14,720 --> 00:22:15,740
последовательным.

516
00:22:15,740 --> 00:22:16,420
ОК?

517
00:22:16,420 --> 00:22:19,690
>> В основном доступны, потому что
они раздел терпимо.

518
00:22:19,690 --> 00:22:21,470
Они всегда будут
там, даже если есть

519
00:22:21,470 --> 00:22:23,053
разделения сети между узлами.

520
00:22:23,053 --> 00:22:25,900
Если я могу поговорить с узлом, я
будет в состоянии прочитать данные.

521
00:22:25,900 --> 00:22:26,460
ОК?

522
00:22:26,460 --> 00:22:30,810
Я не всегда может быть в состоянии написать
данных, если я единой платформы.

523
00:22:30,810 --> 00:22:32,130
Но я буду в состоянии прочитать данные.

524
00:22:32,130 --> 00:22:34,960

525
00:22:34,960 --> 00:22:38,010
>> Мягкая состояние указывает
что, когда я прочитал, что данные,

526
00:22:38,010 --> 00:22:40,790
она не может быть такой же, как другие узлы.

527
00:22:40,790 --> 00:22:43,390
Если право было выдано на узле
где-то в кластере

528
00:22:43,390 --> 00:22:46,650
и это не реплицируются поперек
Кластер же, когда я прочитал, что данные,

529
00:22:46,650 --> 00:22:48,680
что государство не может быть последовательным.

530
00:22:48,680 --> 00:22:51,650
Тем не менее, он будет
в конце концов последовательным,

531
00:22:51,650 --> 00:22:53,870
Это означает, что, когда записи
сделан к системе,

532
00:22:53,870 --> 00:22:56,480
он будет реплицировать узлов.

533
00:22:56,480 --> 00:22:59,095
И в конце концов, что государство
будут приведены в порядок,

534
00:22:59,095 --> 00:23:00,890
и это будет соответствовать состояние.

535
00:23:00,890 --> 00:23:05,000
>> Теперь, теорема CAP действительно
играет только в одном состоянии.

536
00:23:05,000 --> 00:23:08,700
Это условие, когда это произойдет.

537
00:23:08,700 --> 00:23:13,710
Потому что всякий раз, когда он работает в
нормальный режим, нет раздела,

538
00:23:13,710 --> 00:23:16,370
все в последовательной и доступны.

539
00:23:16,370 --> 00:23:19,990
Вы только беспокоиться о CAP
когда у нас есть этот раздел.

540
00:23:19,990 --> 00:23:21,260
Так что те, редки.

541
00:23:21,260 --> 00:23:25,360
Но, как система реагирует, когда те
происходят диктовать, какой тип системы

542
00:23:25,360 --> 00:23:26,750
мы имеем дело с.

543
00:23:26,750 --> 00:23:31,110
>> Итак, давайте взглянем на то, что
который выглядит как для АТ систем.

544
00:23:31,110 --> 00:23:32,621
ОК?

545
00:23:32,621 --> 00:23:34,830
Системы AP бывают двух видов.

546
00:23:34,830 --> 00:23:38,514
Они приходят в аромате, который является
Мастер, 100%, всегда доступны.

547
00:23:38,514 --> 00:23:40,430
И они приходят в
другой аромат, который говорит

548
00:23:40,430 --> 00:23:43,330
Вы знаете, что я собираюсь беспокоиться
об этом разделов вещи

549
00:23:43,330 --> 00:23:44,724
когда фактический раздел происходит.

550
00:23:44,724 --> 00:23:47,890
В противном случае, там будет основным
узлы, которые собирается предпринять прав.

551
00:23:47,890 --> 00:23:48,500
ОК?

552
00:23:48,500 --> 00:23:50,040
>> Так что, если мы что-то вроде Кассандры.

553
00:23:50,040 --> 00:23:54,440
Кассандра бы быть мастером
мастер, давайте мне написать к любому узлу.

554
00:23:54,440 --> 00:23:55,540
Так что же происходит?

555
00:23:55,540 --> 00:23:58,270
Так у меня есть объект в
База данных, существует на двух узлов.

556
00:23:58,270 --> 00:24:01,705
Назовем этот объект S.
Итак, мы имеем состояние для S.

557
00:24:01,705 --> 00:24:04,312
У нас есть некоторые операции
на S, что продолжаются.

558
00:24:04,312 --> 00:24:06,270
Кассандра позволяет мне
написать нескольким узлам.

559
00:24:06,270 --> 00:24:08,550
Так что давайте говорить, что я получаю
писать для с двумя узлами.

560
00:24:08,550 --> 00:24:12,274
Ну, то, что в конечном итоге происходит это
мы называем это событие разделов.

561
00:24:12,274 --> 00:24:14,190
Там не может быть
физическая сеть разделов.

562
00:24:14,190 --> 00:24:15,950
Но из-за дизайна
системы, это

563
00:24:15,950 --> 00:24:18,449
на самом деле, как только разбиения
как я получить запись на двух узлах.

564
00:24:18,449 --> 00:24:20,830
Это не заставляет меня
написать все через один узел.

565
00:24:20,830 --> 00:24:22,340
Я пишу на двух узлах.

566
00:24:22,340 --> 00:24:23,330
ОК?

567
00:24:23,330 --> 00:24:25,740
>> Так что теперь у меня есть два состояния.

568
00:24:25,740 --> 00:24:26,360
ОК?

569
00:24:26,360 --> 00:24:28,110
Что должно случиться
рано или поздно,

570
00:24:28,110 --> 00:24:29,960
там будет событие репликации.

571
00:24:29,960 --> 00:24:33,300
Там будет то, что мы
называется раздел восстановления, который

572
00:24:33,300 --> 00:24:35,200
где эти два
государства вернуться вместе

573
00:24:35,200 --> 00:24:37,310
и там будет алгоритм
который работает в базе данных,

574
00:24:37,310 --> 00:24:38,540
решает, что делать.

575
00:24:38,540 --> 00:24:39,110
ОК?

576
00:24:39,110 --> 00:24:43,057
По умолчанию, последнее обновление
выигрывает в большинстве систем AP.

577
00:24:43,057 --> 00:24:44,890
Так что, как правило,
Алгоритм по умолчанию, то, что

578
00:24:44,890 --> 00:24:47,400
они называют функцию обратного вызова
Функция, то, что

579
00:24:47,400 --> 00:24:51,000
будет вызываться, когда это условие
обнаружено выполнить некоторую логику

580
00:24:51,000 --> 00:24:52,900
решить, что конфликта.

581
00:24:52,900 --> 00:24:53,850
ОК?

582
00:24:53,850 --> 00:24:58,770
Обратный вызов по умолчанию и по умолчанию
распознаватель в большинстве баз данных AP

583
00:24:58,770 --> 00:25:01,130
это, думаю, что, метка выигрывает.

584
00:25:01,130 --> 00:25:02,380
Это было последнее обновление.

585
00:25:02,380 --> 00:25:04,320
Я собираюсь поставить это обновление там.

586
00:25:04,320 --> 00:25:08,440
Я могу сбросить эту запись, что я
сбрасывали прочь в журнале восстановления

587
00:25:08,440 --> 00:25:11,670
так что пользователь может вернуться позже
и сказать, эй, произошло столкновение.

588
00:25:11,670 --> 00:25:12,320
Что случилось?

589
00:25:12,320 --> 00:25:16,370
И вы можете сбросить запись
все столкновения и откаты

590
00:25:16,370 --> 00:25:17,550
и посмотреть, что происходит.

591
00:25:17,550 --> 00:25:21,580
>> Теперь, как пользователь, вы можете также
включать в себя логику в этой обратного вызова.

592
00:25:21,580 --> 00:25:24,290
Таким образом, вы можете изменить
обратного вызова операции.

593
00:25:24,290 --> 00:25:26,730
Вы можете сказать: эй, я хочу
для устранения этой информации.

594
00:25:26,730 --> 00:25:28,880
И я хочу, чтобы попытаться
объединить эти две записи.

595
00:25:28,880 --> 00:25:30,050
Но это до вас.

596
00:25:30,050 --> 00:25:32,880
База данных не знаю, как
сделать, что по умолчанию. Большинство времени,

597
00:25:32,880 --> 00:25:34,850
единственное, что базы данных
знает, как сделать, это сказать,

598
00:25:34,850 --> 00:25:36,100
этот был последний альбом.

599
00:25:36,100 --> 00:25:39,183
Это тот, который собирается выиграть,
и это значение я собираюсь ставить.

600
00:25:39,183 --> 00:25:41,490
После этого восстановления разделов
и репликации,

601
00:25:41,490 --> 00:25:43,930
у нас есть государство, которое
Теперь S премьер, который является

602
00:25:43,930 --> 00:25:46,890
слияние состояние всех этих объектов.

603
00:25:46,890 --> 00:25:49,700
Так системы AP есть это.

604
00:25:49,700 --> 00:25:51,615
Системы CP не нужно
чтобы беспокоиться об этом.

605
00:25:51,615 --> 00:25:54,490
Потому что как только приходит раздел
в игру, они просто перестать принимать

606
00:25:54,490 --> 00:25:55,530
пишет.

607
00:25:55,530 --> 00:25:56,180
ОК?

608
00:25:56,180 --> 00:25:58,670
Так что это очень легко
дело с быть последовательным

609
00:25:58,670 --> 00:26:01,330
когда вы не принимать какие-либо обновления.

610
00:26:01,330 --> 00:26:04,620
Вот с системами CP сделать.

611
00:26:04,620 --> 00:26:05,120
Отлично.

612
00:26:05,120 --> 00:26:07,590
>> Итак, давайте немного поговорим
немного о моделях доступа.

613
00:26:07,590 --> 00:26:11,580
Когда мы говорим о NoSQL, это
все о модели доступа.

614
00:26:11,580 --> 00:26:13,550
Теперь, в SQL есть специальная запросы.

615
00:26:13,550 --> 00:26:14,481
Это реляционное хранилище.

616
00:26:14,481 --> 00:26:16,480
Мы не должны волноваться
о модели доступа.

617
00:26:16,480 --> 00:26:17,688
Я пишу очень сложный запрос.

618
00:26:17,688 --> 00:26:19,250
Это идет и получает данные.

619
00:26:19,250 --> 00:26:21,210
Это то, что это выглядит
как нормализация.

620
00:26:21,210 --> 00:26:24,890
>> Таким образом, в данном конкретном структуры,
мы смотрим на каталог продукции.

621
00:26:24,890 --> 00:26:26,640
У меня есть различные виды продукции.

622
00:26:26,640 --> 00:26:27,217
У меня есть книги.

623
00:26:27,217 --> 00:26:27,800
Я есть альбомы.

624
00:26:27,800 --> 00:26:30,090
У меня есть видео.

625
00:26:30,090 --> 00:26:33,370
Отношения между продуктами
и любой из этих книг, альбомов,

626
00:26:33,370 --> 00:26:34,860
и видео столы 1: 1.

627
00:26:34,860 --> 00:26:35,800
Отлично?

628
00:26:35,800 --> 00:26:38,860
Я получил код продукта,
и что соответствует ID

629
00:26:38,860 --> 00:26:41,080
в книге, альбом или видео.

630
00:26:41,080 --> 00:26:41,580
ОК?

631
00:26:41,580 --> 00:26:44,350
Это отношение 1: 1
по этим таблицам.

632
00:26:44,350 --> 00:26:46,970
>> Теперь, все они books--
есть, корень свойства.

633
00:26:46,970 --> 00:26:47,550
Нет проблем.

634
00:26:47,550 --> 00:26:48,230
Замечательно.

635
00:26:48,230 --> 00:26:52,130
Один-к-одному отношения, я все
данные мне нужно, чтобы описать эту книгу.

636
00:26:52,130 --> 00:26:54,770
Albums-- альбомы треки.

637
00:26:54,770 --> 00:26:56,470
Это то, что мы называем один ко многим.

638
00:26:56,470 --> 00:26:58,905
Каждый альбом может иметь много дорожек.

639
00:26:58,905 --> 00:27:00,780
Таким образом, для каждого трека на
альбом, я мог бы

640
00:27:00,780 --> 00:27:02,570
еще один рекорд в этой дочерней таблицы.

641
00:27:02,570 --> 00:27:04,680
Так что я создать одну запись
в мои альбомы таблице.

642
00:27:04,680 --> 00:27:06,700
Я создаю несколько записей
в таблице треков.

643
00:27:06,700 --> 00:27:08,850
Один-ко-многим.

644
00:27:08,850 --> 00:27:11,220
>> Это соотношение является то, что
мы называем многие-ко-многим.

645
00:27:11,220 --> 00:27:11,750
ОК?

646
00:27:11,750 --> 00:27:17,000
Вы видите, что актеры могли быть
во многих фильмах, много видео.

647
00:27:17,000 --> 00:27:21,450
Так что мы делаем, мы ставим это отображение
Таблица между теми, которые он просто

648
00:27:21,450 --> 00:27:24,040
отображает актер идентификатор видео ID.

649
00:27:24,040 --> 00:27:28,464
Теперь я могу создать запрос к соединяет
видео через актера видео на актеров,

650
00:27:28,464 --> 00:27:31,130
и это дает мне хороший список
все фильмы и все актеры

651
00:27:31,130 --> 00:27:32,420
которые были в этом фильме.

652
00:27:32,420 --> 00:27:33,290
>> ОК.

653
00:27:33,290 --> 00:27:33,880
Так вот мы идем.

654
00:27:33,880 --> 00:27:38,040
Один-к-одному это топ-уровень
отношения; один ко многим,

655
00:27:38,040 --> 00:27:40,240
альбомы для дорожек; многие-ко-многим.

656
00:27:40,240 --> 00:27:44,990
Таковы три верхнего уровня
отношения в любой базе данных.

657
00:27:44,990 --> 00:27:48,050
Если вы знаете, как те,
отношения работать вместе,

658
00:27:48,050 --> 00:27:51,490
то вы знаете, много
о базе данных уже.

659
00:27:51,490 --> 00:27:55,660
Так NoSQL работает немного по-другому.

660
00:27:55,660 --> 00:27:58,930
Давайте думать о на секунду, что это
Похоже, пойти получить все мои продукты.

661
00:27:58,930 --> 00:28:01,096
>> В реляционной магазине, я
хочу, чтобы получить все мои продукты

662
00:28:01,096 --> 00:28:02,970
в списке всех моих продуктах.

663
00:28:02,970 --> 00:28:04,910
Это много запросов.

664
00:28:04,910 --> 00:28:07,030
Я получил запрос для всех моих книг.

665
00:28:07,030 --> 00:28:08,470
Я получил запрос от моих альбомов.

666
00:28:08,470 --> 00:28:09,970
И я получил запрос для всех моих видео.

667
00:28:09,970 --> 00:28:11,719
И я получил поставить его
все вместе в списке

668
00:28:11,719 --> 00:28:15,250
и служить его обратно к
приложения, которое запрашивает его.

669
00:28:15,250 --> 00:28:18,000
>> Чтобы получить мои книги, я присоединяюсь
Продукты и книг.

670
00:28:18,000 --> 00:28:21,680
Чтобы получить мои альбомы, меня присоединиться
Продукты, Альбомы, и треки.

671
00:28:21,680 --> 00:28:25,330
И чтобы мои видео, у меня есть
присоединиться к видео продукты,

672
00:28:25,330 --> 00:28:28,890
присоединиться через Актер видео,
и принести в Актеры.

673
00:28:28,890 --> 00:28:31,020
Так вот три запроса.

674
00:28:31,020 --> 00:28:34,560
Очень сложные запросы к
собрать один результирующий набор.

675
00:28:34,560 --> 00:28:36,540
>> Это меньше, чем оптимальна.

676
00:28:36,540 --> 00:28:39,200
Вот почему, когда мы говорим
о структуре данных, что это

677
00:28:39,200 --> 00:28:42,900
построен, чтобы быть независимым от доступа
pattern-- хорошо, что это здорово.

678
00:28:42,900 --> 00:28:45,730
И вы можете видеть это на самом деле
приятно, как мы организовали данные.

679
00:28:45,730 --> 00:28:46,550
И вы знаете, что?

680
00:28:46,550 --> 00:28:49,750
У меня есть только одна запись для актера.

681
00:28:49,750 --> 00:28:50,440
>> Это круто.

682
00:28:50,440 --> 00:28:53,750
Я дедуплицированы все мои актеры,
и я поддерживал мои ассоциации

683
00:28:53,750 --> 00:28:55,200
В этой таблице отображения.

684
00:28:55,200 --> 00:29:00,620
Однако, получение данных
вне становится дороже.

685
00:29:00,620 --> 00:29:04,500
Я посылаю процессор всей системе
соединяющий эти структуры данных вместе

686
00:29:04,500 --> 00:29:05,950
чтобы быть в состоянии осуществить это обратно данных.

687
00:29:05,950 --> 00:29:07,310
>> Так как я могу получить вокруг этого?

688
00:29:07,310 --> 00:29:11,200
В NoSQL это о
агрегации, не нормализация.

689
00:29:11,200 --> 00:29:13,534
Таким образом, мы хотим сказать, что мы хотим
поддержки доступа к файлу.

690
00:29:13,534 --> 00:29:15,283
Если модель доступа
к приложениям,

691
00:29:15,283 --> 00:29:16,770
Мне нужно, чтобы получить все мои продукты.

692
00:29:16,770 --> 00:29:19,027
Давайте положить все продукты в одной таблице.

693
00:29:19,027 --> 00:29:22,110
Если я ставлю все продукты в одной таблице,
Я могу просто выбрать все продукты

694
00:29:22,110 --> 00:29:23,850
из этой таблицы, и я получаю все это.

695
00:29:23,850 --> 00:29:25,240
Ну, как я могу это сделать?

696
00:29:25,240 --> 00:29:28,124
Ну в NoSQL нет никакого
Структура к столу.

697
00:29:28,124 --> 00:29:30,540
Мы поговорим немного о
как это работает в Динамо БД.

698
00:29:30,540 --> 00:29:33,570
Но вы не должны то же самое
атрибуты и те же свойства

699
00:29:33,570 --> 00:29:37,751
в каждой строки, в каждый
Пункт, как вы делаете в таблице SQL.

700
00:29:37,751 --> 00:29:39,750
И то, что это позволяет мне
сделать много вещей,

701
00:29:39,750 --> 00:29:41,124
и дать мне много гибкости.

702
00:29:41,124 --> 00:29:45,360
В данном конкретном случае, я
мои документы продукта.

703
00:29:45,360 --> 00:29:49,090
И в этом конкретном
Например, все

704
00:29:49,090 --> 00:29:51,930
это документ, в таблице Products.

705
00:29:51,930 --> 00:29:56,510
И продукт для книги может
есть тип ID, который определяет книгу.

706
00:29:56,510 --> 00:29:59,180
И применение
хотел бы перейти на тот ID.

707
00:29:59,180 --> 00:30:02,570
>> В уровне приложений, я собираюсь
сказать ах, какой тип записи это?

708
00:30:02,570 --> 00:30:04,100
О, это книжка.

709
00:30:04,100 --> 00:30:05,990
Забронируйте записи имеют эти свойства.

710
00:30:05,990 --> 00:30:08,100
Позвольте мне создать объект книги.

711
00:30:08,100 --> 00:30:11,289
Так что я собираюсь, чтобы заполнить
Книга объект с этим пунктом.

712
00:30:11,289 --> 00:30:13,080
Следующий товар приходит и
говорит, что этот пункт?

713
00:30:13,080 --> 00:30:14,560
Ну этот элемент является альбом.

714
00:30:14,560 --> 00:30:17,340
О, я получил совершенно другой
процедуры обработки для того,

715
00:30:17,340 --> 00:30:18,487
потому что это альбом.

716
00:30:18,487 --> 00:30:19,320
Вы видите, что я имею в виду?

717
00:30:19,320 --> 00:30:21,950
>> Таким образом, применение tier-- я
просто выделите все эти записи.

718
00:30:21,950 --> 00:30:23,200
Они все начинают приходить в.

719
00:30:23,200 --> 00:30:24,680
Они могут быть все различные типы.

720
00:30:24,680 --> 00:30:27,590
И это логика приложения
который переключается между этими типами

721
00:30:27,590 --> 00:30:29,530
и решает, как их обработать.

722
00:30:29,530 --> 00:30:33,640
>> Опять же, так что мы оптимизируя
Схема для шаблона доступа.

723
00:30:33,640 --> 00:30:36,390
Мы делаем это с помощью
рушится эти таблицы.

724
00:30:36,390 --> 00:30:39,670
Мы в основном принятия
эти нормированные структуры,

725
00:30:39,670 --> 00:30:42,000
и мы строим
иерархические структуры.

726
00:30:42,000 --> 00:30:45,130
Внутри каждого из этих записей
Я собираюсь просмотреть свойства массива.

727
00:30:45,130 --> 00:30:49,400
>> Внутри этого документа Альбомы,
Я вижу массивы треков.

728
00:30:49,400 --> 00:30:53,900
Эти треки Теперь become-- это
в основном это ребенок таблица,

729
00:30:53,900 --> 00:30:56,520
существует прямо здесь, в этой структуре.

730
00:30:56,520 --> 00:30:57,975
Таким образом, вы можете сделать это в DynamoDB.

731
00:30:57,975 --> 00:30:59,810
Вы можете сделать это в MongoDB.

732
00:30:59,810 --> 00:31:01,437
Вы можете сделать это в любой базе данных NoSQL.

733
00:31:01,437 --> 00:31:03,520
Создать эти типы
иерархические структуры данных

734
00:31:03,520 --> 00:31:07,120
которые позволяют вам получить данные
очень быстро, потому что теперь я

735
00:31:07,120 --> 00:31:08,537
не должны соответствовать.

736
00:31:08,537 --> 00:31:11,620
Когда я вставить строку в Tracks
стол, или ряд в таблице Альбомы,

737
00:31:11,620 --> 00:31:13,110
Я должен соответствовать этой схеме.

738
00:31:13,110 --> 00:31:18,060
Я должен иметь атрибут или тому
имущество, определенного в данной таблице.

739
00:31:18,060 --> 00:31:20,480
Каждый из них,
когда я вставляю эту строку.

740
00:31:20,480 --> 00:31:21,910
Это не тот случай в NoSQL.

741
00:31:21,910 --> 00:31:24,440
>> Я могу иметь совершенно разные
свойства в каждом документе

742
00:31:24,440 --> 00:31:26,100
что я вставить в коллекции.

743
00:31:26,100 --> 00:31:30,480
Итак, очень мощный механизм.

744
00:31:30,480 --> 00:31:32,852
И это действительно, как вы
оптимизации системы.

745
00:31:32,852 --> 00:31:35,310
Потому что теперь вместо запроса,
присоединения все эти таблицы

746
00:31:35,310 --> 00:31:39,160
и выполнение полдюжины запросов
отступить данные мне нужно,

747
00:31:39,160 --> 00:31:40,890
Я выполнении одного запроса.

748
00:31:40,890 --> 00:31:43,010
И я итерации
по результатам установленных.

749
00:31:43,010 --> 00:31:46,512
это дает вам представление
о силе NoSQL.

750
00:31:46,512 --> 00:31:49,470
Я собираюсь рода выйти боком здесь
и немного поговорим об этом.

751
00:31:49,470 --> 00:31:53,240
Это больше, вид из
маркетинг или technology--

752
00:31:53,240 --> 00:31:55,660
маркетинг технологии
тип дискуссии.

753
00:31:55,660 --> 00:31:58,672
Но важно понимать,
потому что, если мы посмотрим на вершине

754
00:31:58,672 --> 00:32:00,380
здесь, на этом графике,
то, что мы смотрим на

755
00:32:00,380 --> 00:32:04,030
это то, что мы называем
Технология обмана кривой.

756
00:32:04,030 --> 00:32:06,121
И то, что это означает,
Новый материал вступает в игру.

757
00:32:06,121 --> 00:32:07,120
Люди думают, что это здорово.

758
00:32:07,120 --> 00:32:09,200
Я решил все мои проблемы.

759
00:32:09,200 --> 00:32:11,630
>> Это может быть конец
все, все будет все.

760
00:32:11,630 --> 00:32:12,790
И они начинают использовать его.

761
00:32:12,790 --> 00:32:14,720
И говорят они, этот материал не работает.

762
00:32:14,720 --> 00:32:17,600
Это неправильно.

763
00:32:17,600 --> 00:32:19,105
Старая материал был лучше.

764
00:32:19,105 --> 00:32:21,230
И они возвращаются к выполнению
вещи, как они были.

765
00:32:21,230 --> 00:32:22,730
И тогда в конечном счете
они идут, вы знаете, что?

766
00:32:22,730 --> 00:32:24,040
Этот материал не так уж плохо.

767
00:32:24,040 --> 00:32:26,192
О, как это работает.

768
00:32:26,192 --> 00:32:28,900
И как только они выяснить, как это
Работы, они начинают все лучше.

769
00:32:28,900 --> 00:32:32,050
>> И самое смешное об этом
есть, вид линий до того, что

770
00:32:32,050 --> 00:32:34,300
мы называем кривой принятия технологии.

771
00:32:34,300 --> 00:32:36,910
Так что же происходит у нас есть
своего рода технология запуска.

772
00:32:36,910 --> 00:32:39,100
В случае баз данных,
это давление данных.

773
00:32:39,100 --> 00:32:42,200
Мы говорили о высоких точек воды
давления данных в течение времени.

774
00:32:42,200 --> 00:32:46,310
При том, что давление данные парад определенная
дело, что это технология запуска.

775
00:32:46,310 --> 00:32:47,830
>> Это становится слишком дорого.

776
00:32:47,830 --> 00:32:49,790
Это занимает слишком много времени, чтобы обработать данные.

777
00:32:49,790 --> 00:32:50,890
Мы должны что-то лучше.

778
00:32:50,890 --> 00:32:52,890
Вы новаторов
там бегают,

779
00:32:52,890 --> 00:32:55,050
пытаясь выяснить, что это решение.

780
00:32:55,050 --> 00:32:56,050
Что новая идея?

781
00:32:56,050 --> 00:32:58,170
>> Что следующая лучшая
способ сделать это?

782
00:32:58,170 --> 00:32:59,530
И они приходят с чем-то.

783
00:32:59,530 --> 00:33:03,140
И люди с реальной боли,
ребята на переднем крае,

784
00:33:03,140 --> 00:33:06,390
они буду прыгать над ним,
потому что они должны ответить.

785
00:33:06,390 --> 00:33:09,690
Теперь то, что неизбежно и happens--
это происходит сейчас в NoSQL.

786
00:33:09,690 --> 00:33:11,090
Я вижу все это время.

787
00:33:11,090 --> 00:33:13,610
>> Что неизбежно происходит
люди начинают использовать новый инструмент

788
00:33:13,610 --> 00:33:15,490
так же, как они использовали старый инструмент.

789
00:33:15,490 --> 00:33:17,854
И они это выяснить
не работает так хорошо.

790
00:33:17,854 --> 00:33:20,020
Я не могу вспомнить, кто я
говорить с ранее сегодня.

791
00:33:20,020 --> 00:33:22,080
Но это, как, когда
отбойный молоток был изобретен,

792
00:33:22,080 --> 00:33:24,621
люди не качать его на
их головы, чтобы разбить бетон.

793
00:33:24,621 --> 00:33:27,360

794
00:33:27,360 --> 00:33:30,610
>> Но это то, что
происходит с NoSQL сегодня.

795
00:33:30,610 --> 00:33:33,900
Если вы ходить в большинстве магазинов,
они пытаются быть NoSQL магазины.

796
00:33:33,900 --> 00:33:36,510
То, что они делают, является
они используют NoSQL,

797
00:33:36,510 --> 00:33:39,900
и они загрузкой
полный реляционной схеме.

798
00:33:39,900 --> 00:33:41,630
Потому что, как
они проектировать базы данных.

799
00:33:41,630 --> 00:33:44,046
И они интересно, почему
не выполняя очень хорошо?

800
00:33:44,046 --> 00:33:45,230
Мальчик, эта вещь пахнет.

801
00:33:45,230 --> 00:33:49,900
Я должен был поддерживать все мои
присоединяется in-- это как, нет, нет.

802
00:33:49,900 --> 00:33:50,800
Поддержание присоединяется?

803
00:33:50,800 --> 00:33:52,430
Почему вы присоединения данных?

804
00:33:52,430 --> 00:33:54,350
Вы не объединять данные в NoSQL.

805
00:33:54,350 --> 00:33:55,850
Вы агрегировать его.

806
00:33:55,850 --> 00:34:00,690
>> Так что, если вы хотите, чтобы избежать этого, узнать
как инструмент работает прежде чем вы действительно

807
00:34:00,690 --> 00:34:02,010
начать использовать его.

808
00:34:02,010 --> 00:34:04,860
Не пытайтесь использовать новые Инструменты
так же, как вы использовали старые инструменты.

809
00:34:04,860 --> 00:34:06,500
Вы будете иметь плохой опыт.

810
00:34:06,500 --> 00:34:08,848
И каждый раз,
это то, что это о.

811
00:34:08,848 --> 00:34:11,389
Когда мы начинаем придумывать здесь,
это потому, что люди выяснили,

812
00:34:11,389 --> 00:34:13,449
как использовать инструменты.

813
00:34:13,449 --> 00:34:16,250
>> Они сделали то же самое, когда
реляционные базы данных были изобретены,

814
00:34:16,250 --> 00:34:17,969
и они были замены файловых систем.

815
00:34:17,969 --> 00:34:20,420
Они пытались построить файловых систем
с реляционными базами данных

816
00:34:20,420 --> 00:34:22,159
потому что это то, что люди поняли.

817
00:34:22,159 --> 00:34:23,049
Это не работает.

818
00:34:23,049 --> 00:34:26,090
Таким образом, понимание лучшие практики
технологии вы работаете с

819
00:34:26,090 --> 00:34:26,730
огромный.

820
00:34:26,730 --> 00:34:29,870
Очень важно.

821
00:34:29,870 --> 00:34:32,440
>> Итак, мы собираемся, чтобы попасть в DynamoDB.

822
00:34:32,440 --> 00:34:36,480
DynamoDB является AWS-х
полностью управляемого платформу NoSQL.

823
00:34:36,480 --> 00:34:37,719
Что полностью управляемого в виду?

824
00:34:37,719 --> 00:34:40,010
Это означает, что вы не должны
действительно ни о чем беспокоиться.

825
00:34:40,010 --> 00:34:42,060
>> Вы приходите, вы скажите
нам, мне нужно таблицу.

826
00:34:42,060 --> 00:34:43,409
Это нуждается в этом больше мощности.

827
00:34:43,409 --> 00:34:47,300
Вы нажмете кнопку, и мы предоставление
вся инфраструктура за сценой.

828
00:34:47,300 --> 00:34:48,310
Теперь, огромен.

829
00:34:48,310 --> 00:34:51,310
>> Потому что, когда вы говорите
о масштабировании базы данных,

830
00:34:51,310 --> 00:34:53,917
Кластеры данных NoSQL в
масштаб, ходовые петабайт,

831
00:34:53,917 --> 00:34:55,750
работает миллионы
транзакций в секунду,

832
00:34:55,750 --> 00:34:58,180
эти вещи не малые кластеры.

833
00:34:58,180 --> 00:35:00,830
Мы говорим тысячи экземпляров.

834
00:35:00,830 --> 00:35:04,480
Управление тысячи экземпляров,
даже виртуальные экземпляры,

835
00:35:04,480 --> 00:35:06,350
это реальная боль в заднице.

836
00:35:06,350 --> 00:35:09,110
Я имею в виду, думать о каждый раз
Операционная система выходит патч

837
00:35:09,110 --> 00:35:11,552
или новой версии базы данных.

838
00:35:11,552 --> 00:35:13,260
Что это значит
Вам оперативно?

839
00:35:13,260 --> 00:35:16,330
Это означает, что вы получили 1200
серверы, которые должны быть обновлены.

840
00:35:16,330 --> 00:35:18,960
Теперь даже с автоматизацией,
что может занять длительное время.

841
00:35:18,960 --> 00:35:21,480
Это может вызвать много
оперативные головные боли,

842
00:35:21,480 --> 00:35:23,090
потому что я, возможно, услуги вниз.

843
00:35:23,090 --> 00:35:26,070
>> Как мне обновить эти базы данных, я
может сделать голубые зеленые развертывания

844
00:35:26,070 --> 00:35:29,420
где я развертывания и обновления половины моего
узлы, а затем обновить другую половину.

845
00:35:29,420 --> 00:35:30,490
Возьмите те вниз.

846
00:35:30,490 --> 00:35:33,410
Так управления инфраструктурой
Шкала является чрезвычайно болезненным.

847
00:35:33,410 --> 00:35:36,210
И AWS принять эту боль из него.

848
00:35:36,210 --> 00:35:39,210
И базы данных NoSQL может
чрезвычайно болезненным будет

849
00:35:39,210 --> 00:35:41,780
из-за, как они масштабирования.

850
00:35:41,780 --> 00:35:42,926
>> Масштаб по горизонтали.

851
00:35:42,926 --> 00:35:45,550
Если вы хотите, чтобы получить большую NoSQL
базы данных, вы покупаете больше узлов.

852
00:35:45,550 --> 00:35:48,660
Каждый узел вы покупаете
другой операционный головная боль.

853
00:35:48,660 --> 00:35:50,830
Итак, давайте кто-то сделает это за вас.

854
00:35:50,830 --> 00:35:52,000
AWS может это сделать.

855
00:35:52,000 --> 00:35:54,587
>> Мы поддерживаем значения ключевых документов.

856
00:35:54,587 --> 00:35:56,670
Теперь мы не пошли слишком много
в другой диаграмме.

857
00:35:56,670 --> 00:35:58,750
Там много разных
ароматы NoSQL.

858
00:35:58,750 --> 00:36:02,670
Они все виды получать
потеряются вместе в этой точке.

859
00:36:02,670 --> 00:36:06,260
Вы можете посмотреть на DynamoDB и сказать да,
мы оба документа и значение ключа

860
00:36:06,260 --> 00:36:08,412
хранить эту точку.

861
00:36:08,412 --> 00:36:10,620
И вы можете утверждать, особенности
одного над другим.

862
00:36:10,620 --> 00:36:13,950
Для меня, много это действительно шесть
одного полдюжины другого.

863
00:36:13,950 --> 00:36:18,710
Каждый из этих технологий является
точная технология и штраф решение.

864
00:36:18,710 --> 00:36:23,390
Я бы не сказал, что MongoDB лучше или
хуже, чем диване, то Кассандры,

865
00:36:23,390 --> 00:36:25,994
то Динамо, или наоборот.

866
00:36:25,994 --> 00:36:27,285
Я имею в виду, это всего лишь варианты.

867
00:36:27,285 --> 00:36:29,850

868
00:36:29,850 --> 00:36:32,700
>> Это быстро, и это
соответствует в любом масштабе.

869
00:36:32,700 --> 00:36:36,210
Таким образом, это является одним из крупнейших
бонусы вы получаете с AWS.

870
00:36:36,210 --> 00:36:40,850
С DynamoDB является способность
чтобы получить низкую одну цифру

871
00:36:40,850 --> 00:36:44,040
Задержка миллисекунду в любом масштабе.

872
00:36:44,040 --> 00:36:45,720
Это было целью дизайна системы.

873
00:36:45,720 --> 00:36:49,130
И у нас есть клиенты, которые делают
миллионы транзакций в секунду.

874
00:36:49,130 --> 00:36:52,670
>> Теперь я пойду через некоторые из тех,
случаи использования в течение нескольких минут здесь.

875
00:36:52,670 --> 00:36:55,660
Встроенный control-- доступ
мы имеем то, что мы называем

876
00:36:55,660 --> 00:36:57,920
Идентичность Управление доступом, или IAM.

877
00:36:57,920 --> 00:37:01,980
Она пронизывает все системы,
каждый сервис, который предлагает AWS.

878
00:37:01,980 --> 00:37:03,630
DynamoDB не является исключением.

879
00:37:03,630 --> 00:37:06,020
Вы можете контролировать доступ
к таблицам DynamoDB.

880
00:37:06,020 --> 00:37:09,960
Через все ваши AWS составляет от
определение роли и разрешения доступа

881
00:37:09,960 --> 00:37:12,140
в IAM инфраструктуры.

882
00:37:12,140 --> 00:37:16,630
>> И это ключевой и неотъемлемой составляющей
что мы называем Event Driven программирования.

883
00:37:16,630 --> 00:37:19,056
Теперь это новая парадигма.

884
00:37:19,056 --> 00:37:22,080
>> АУДИТОРИЯ: Как ваша скорость верно
Положительных против ложных негативов

885
00:37:22,080 --> 00:37:24,052
на системы контроля доступа?

886
00:37:24,052 --> 00:37:26,260
РИК Хулихэном: True срабатываний
по сравнению с ложноотрицательных?

887
00:37:26,260 --> 00:37:28,785
АУДИТОРИЯ: Возвращаясь что
Вы должны возвращаться?

888
00:37:28,785 --> 00:37:33,720
В отличие от раз в то время он
не вернуться, когда он должен проверить?

889
00:37:33,720 --> 00:37:36,260

890
00:37:36,260 --> 00:37:38,050
>> РИК Хулихэном: Я не мог сказать вам, что.

891
00:37:38,050 --> 00:37:40,140
Если есть какие-либо сбои
бы то ни было, что,

892
00:37:40,140 --> 00:37:42,726
Я не тот человек, чтобы спросить
что конкретный вопрос.

893
00:37:42,726 --> 00:37:43,850
Но это хороший вопрос.

894
00:37:43,850 --> 00:37:45,905
Я бы любопытно узнать,
что я, на самом деле.

895
00:37:45,905 --> 00:37:48,810

896
00:37:48,810 --> 00:37:51,320
>> И так, опять же, новая парадигма
это событийная программирования.

897
00:37:51,320 --> 00:37:55,160
Это идея, что вы можете
развернуть сложных приложений, которые

898
00:37:55,160 --> 00:37:59,720
может работать очень, очень высокий масштаб
без инфраструктуры бы то ни было.

899
00:37:59,720 --> 00:38:02,120
Без жесткого
Инфраструктура бы то ни было.

900
00:38:02,120 --> 00:38:04,720
И мы будем говорить немного
о том, что это означает, что, как мы

901
00:38:04,720 --> 00:38:06,550
получить на следующей пары карт.

902
00:38:06,550 --> 00:38:08,716
>> Первое, что мы сделаем
что мы будем говорить о таблицах.

903
00:38:08,716 --> 00:38:10,857
Типы данных API для Динамо.

904
00:38:10,857 --> 00:38:13,190
И первое, что вы будете
заметил, когда вы смотрите на это,

905
00:38:13,190 --> 00:38:17,930
если вы знакомы с любой базой данных,
Базы данных действительно два вида интерфейсов

906
00:38:17,930 --> 00:38:18,430
Я бы назвал это.

907
00:38:18,430 --> 00:38:21,570
Или два комплекта API.

908
00:38:21,570 --> 00:38:23,840
Один из тех, будет
API управления.

909
00:38:23,840 --> 00:38:26,710
>> Вещи, которые они принимают на себя
функции базы данных.

910
00:38:26,710 --> 00:38:31,340
Настройка механизма хранения,
создание и добавление таблиц.

911
00:38:31,340 --> 00:38:35,180
создание базы данных
каталоги и примеры.

912
00:38:35,180 --> 00:38:40,450
Они things-- в DynamoDB, вы
имеют очень короткие, короткие списки.

913
00:38:40,450 --> 00:38:43,120
>> Таким образом, в других базах данных,
Вы могли бы видеть десятки

914
00:38:43,120 --> 00:38:45,680
из команды, административно
Команды, для конфигурирования

915
00:38:45,680 --> 00:38:47,290
эти дополнительные опции.

916
00:38:47,290 --> 00:38:51,234
В DynamoDB вам не нужно, потому что те,
Вы не настраивать систему, мы делаем.

917
00:38:51,234 --> 00:38:54,150
Так что единственное, что вам нужно сделать, это
скажи мне, что размер таблицы мне нужно.

918
00:38:54,150 --> 00:38:55,660
Таким образом, вы получаете очень
ограниченный набор команд.

919
00:38:55,660 --> 00:38:58,618
>> Вы получаете Create Table Update, Настольный,
Удалить таблицу и описать таблицу.

920
00:38:58,618 --> 00:39:01,150
Это единственные вещи,
что нужно для DynamoDB.

921
00:39:01,150 --> 00:39:03,294
Вам не нужно хранилище
конфигурация двигателя.

922
00:39:03,294 --> 00:39:04,960
Мне не нужно беспокоиться о репликации.

923
00:39:04,960 --> 00:39:06,490
Мне не нужно беспокоиться о шардинге.

924
00:39:06,490 --> 00:39:07,800
>> Я не нужно беспокоиться
о любом из этого материала.

925
00:39:07,800 --> 00:39:08,740
Мы делаем все это для вас.

926
00:39:08,740 --> 00:39:11,867
Так что это огромное количество накладных расходов
что просто поднял свой пластину.

927
00:39:11,867 --> 00:39:13,200
Тогда у нас есть операторы CRUD.

928
00:39:13,200 --> 00:39:17,740
CRUD-то, что мы
позвоните в базе данных, что это

929
00:39:17,740 --> 00:39:19,860
Создание, обновление, удаление операторов.

930
00:39:19,860 --> 00:39:24,180
Это ваш общий
операции с базами данных.

931
00:39:24,180 --> 00:39:31,299
Такие вещи, как положить деталь, получаете деталь, обновление
предметы, удалять элементы, партия запросов, сканирование.

932
00:39:31,299 --> 00:39:32,840
Если вы хотите, чтобы сканировать всю таблицу.

933
00:39:32,840 --> 00:39:34,220
Потяните все со стола.

934
00:39:34,220 --> 00:39:37,130
Одна из приятных вещей о DynamoDB
это позволяет параллельное сканирование.

935
00:39:37,130 --> 00:39:40,602
Так что вы можете на самом деле, дайте мне знать, сколько
темы вы хотите, чтобы работать на этой сканирования.

936
00:39:40,602 --> 00:39:41,810
И мы можем запустить эти темы.

937
00:39:41,810 --> 00:39:43,985
Мы можем спина, что сканировать до
по нескольким потокам

938
00:39:43,985 --> 00:39:49,060
так что вы можете сканировать всю таблицу
пространство очень, очень быстро в DynamoDB.

939
00:39:49,060 --> 00:39:51,490
>> Другой API мы имеем
то, что мы называем нашим Потоки API.

940
00:39:51,490 --> 00:39:52,940
Мы не собираемся говорить слишком
много об этом прямо сейчас.

941
00:39:52,940 --> 00:39:55,189
Я получил некоторое содержание позже
на палубе в об этом.

942
00:39:55,189 --> 00:39:59,910
Но Потоки действительно running--
думаю о нем, как приказал раз

943
00:39:59,910 --> 00:40:01,274
и изменение разделов журнала.

944
00:40:01,274 --> 00:40:03,940
Все, что происходит на
таблица показывает вверх в потоке.

945
00:40:03,940 --> 00:40:05,940
>> Каждый написать в таблице
Выставки на поток.

946
00:40:05,940 --> 00:40:08,370
Вы можете прочитать, что поток, и
Вы можете делать вещи, с ним.

947
00:40:08,370 --> 00:40:10,150
Мы будем говорить о том, что
типы вещей, которые вы

948
00:40:10,150 --> 00:40:13,680
делать с вещами, как репликация,
создание вторичных индексов.

949
00:40:13,680 --> 00:40:17,620
Все виды действительно здорово
вещи, которые вы можете сделать с этим.

950
00:40:17,620 --> 00:40:19,150
>> Типы данных.

951
00:40:19,150 --> 00:40:23,320
В DynamoDB, мы поддерживаем оба ключа
значение и документ типы данных.

952
00:40:23,320 --> 00:40:26,350
На левой стороне экрана
здесь, мы получили наши основные типы.

953
00:40:26,350 --> 00:40:27,230
Основные типы значений.

954
00:40:27,230 --> 00:40:30,040
Эти строки,
цифры и исполняемые файлы.

955
00:40:30,040 --> 00:40:31,640
>> Так всего за три основных типа.

956
00:40:31,640 --> 00:40:33,700
И тогда вы можете иметь наборы из них.

957
00:40:33,700 --> 00:40:37,650
Одна из приятных вещей о NoSQL это
Вы можете содержать массивы в качестве свойств.

958
00:40:37,650 --> 00:40:42,050
И с DynamoDB можно содержать массивы
основных типов, как корневой собственности.

959
00:40:42,050 --> 00:40:43,885
>> А тут еще типы документов.

960
00:40:43,885 --> 00:40:45,510
Сколько людей знакомы с JSON?

961
00:40:45,510 --> 00:40:47,130
Вы, ребята, знакомые с JSON так много?

962
00:40:47,130 --> 00:40:49,380
Это в основном JavaScript,
Объект, Обозначения.

963
00:40:49,380 --> 00:40:52,510
Это позволяет в основном
определяют иерархическую структуру.

964
00:40:52,510 --> 00:40:58,107
>> Вы можете хранить документ в формате JSON на
DynamoDB использованием общих компонентов

965
00:40:58,107 --> 00:41:00,940
или блоков, которые доступны
в большинстве языков программирования.

966
00:41:00,940 --> 00:41:03,602
Так что, если у вас есть Java, вы
глядя на карты и списки.

967
00:41:03,602 --> 00:41:05,060
Я могу создать объекты, которые Карта зоны.

968
00:41:05,060 --> 00:41:08,030
Карта, как ключевых ценностей
хранятся в качестве свойств.

969
00:41:08,030 --> 00:41:10,890
И это, возможно, есть списки
значения в пределах этих свойств.

970
00:41:10,890 --> 00:41:13,490
Вы можете хранить этот комплекс
иерархическая структура

971
00:41:13,490 --> 00:41:16,320
как одного атрибута
из пункта DynamoDB.

972
00:41:16,320 --> 00:41:19,010

973
00:41:19,010 --> 00:41:24,460
>> Так таблиц в DynamoDB, как и большинство
Базы данных NoSQL, столы есть пункты.

974
00:41:24,460 --> 00:41:26,469
В MongoDB вы бы
называть эти документы.

975
00:41:26,469 --> 00:41:27,760
И это будет диван базы.

976
00:41:27,760 --> 00:41:28,900
Также база данных документов.

977
00:41:28,900 --> 00:41:29,941
Вы называете эти документы.

978
00:41:29,941 --> 00:41:32,930
Документы или детали имеют атрибуты.

979
00:41:32,930 --> 00:41:35,850
Атрибуты могут существовать или
не существует по этому пункту.

980
00:41:35,850 --> 00:41:38,520
В DynamoDB, есть
один обязательный атрибут.

981
00:41:38,520 --> 00:41:43,880
Так же, как в реляционной базе данных,
у вас есть первичный ключ на столе.

982
00:41:43,880 --> 00:41:46,010
>> DynamoDB имеет то, что мы называем хэш-ключ.

983
00:41:46,010 --> 00:41:48,280
Хэш ключ должен быть уникальным.

984
00:41:48,280 --> 00:41:52,580
Поэтому, когда я определить хэш-таблицу,
в основном то, что я говорю,

985
00:41:52,580 --> 00:41:54,110
является каждый элемент будет иметь хэш-ключ.

986
00:41:54,110 --> 00:41:58,520
И каждый хэш-ключ должен быть уникальным.

987
00:41:58,520 --> 00:42:01,200
>> Каждый элемент определяется
этой уникальной хеш-ключа.

988
00:42:01,200 --> 00:42:02,940
А может быть только один.

989
00:42:02,940 --> 00:42:05,820
Это нормально, но часто
что нужно людям

990
00:42:05,820 --> 00:42:08,170
они хотят это хэш
Ключ к делать немного больше

991
00:42:08,170 --> 00:42:11,010
чем просто быть уникальным идентификатором.

992
00:42:11,010 --> 00:42:15,240
Часто мы хотим, чтобы использовать эту хэш-ключ
в качестве верхнего уровня агрегации ведро.

993
00:42:15,240 --> 00:42:19,160
И то, как мы делаем, что является
добавив, что мы называем ключ диапазона.

994
00:42:19,160 --> 00:42:22,460
>> Так что, если это только хеш-
стол, это должно быть уникальным.

995
00:42:22,460 --> 00:42:27,040
Если это хэш и диапазон стол,
Сочетание хэша и диапазона

996
00:42:27,040 --> 00:42:28,640
Должно быть уникальным.

997
00:42:28,640 --> 00:42:30,110
Так что подумайте об этом таким образом.

998
00:42:30,110 --> 00:42:32,140
Если у меня есть форум.

999
00:42:32,140 --> 00:42:39,010
И форма имеет темы, он имеет
должности, и она имеет ответов.

1000
00:42:39,010 --> 00:42:42,630
>> Так что я, возможно, хэш
ключ, который является темой ID.

1001
00:42:42,630 --> 00:42:46,650
И я мог бы иметь ключ диапазон,
который является ответом ID.

1002
00:42:46,650 --> 00:42:49,650
Таким образом, если я хочу, чтобы все
ответы для конкретной теме,

1003
00:42:49,650 --> 00:42:52,370
Я могу только запрос хэш.

1004
00:42:52,370 --> 00:42:55,190
Я могу только сказать, мне все дают
предметы, имеющие этот хэш.

1005
00:42:55,190 --> 00:43:01,910
И я иду, чтобы получить каждый вопрос
или разместить на этой конкретной теме.

1006
00:43:01,910 --> 00:43:03,910
Эти главные скопления уровня
очень важны.

1007
00:43:03,910 --> 00:43:07,370
Они поддерживают основной доступ
Характер применения.

1008
00:43:07,370 --> 00:43:09,420
Вообще говоря, это
это то, что мы хотим сделать.

1009
00:43:09,420 --> 00:43:11,780
Мы хотим, чтобы table--
как вы загрузить таблицу,

1010
00:43:11,780 --> 00:43:16,640
мы хотим, чтобы структурировать данные
в таблице таким образом,

1011
00:43:16,640 --> 00:43:20,140
что приложение может очень
быстро получить эти результаты.

1012
00:43:20,140 --> 00:43:24,510
И часто способ сделать это
для поддержания этих агрегатов, как мы

1013
00:43:24,510 --> 00:43:25,650
вставить данные.

1014
00:43:25,650 --> 00:43:31,110
В принципе, мы распространения данных
в светлое ведро, как это происходит в.

1015
00:43:31,110 --> 00:43:35,210
>> Ключи с длинными позволяют me-- хэш
ключи должны быть равенство.

1016
00:43:35,210 --> 00:43:39,490
Когда я запрос хэш, я должен сказать,
дать мне хэш, равную этого.

1017
00:43:39,490 --> 00:43:41,950
Когда я запросить диапазон, я
можно сказать, дайте мне диапазон

1018
00:43:41,950 --> 00:43:47,040
который использует любую
богатые оператор, что мы поддерживаем.

1019
00:43:47,040 --> 00:43:49,200
Дайте мне все детали для хэш.

1020
00:43:49,200 --> 00:43:52,520
Это равно, больше, чем,
меньше, чем, она начинается с того,

1021
00:43:52,520 --> 00:43:54,145
оно существует между этими двумя значениями?

1022
00:43:54,145 --> 00:43:56,811
Таким образом, эти типы запросов дальности
что мы всегда заинтересованы в.

1023
00:43:56,811 --> 00:43:59,650
Теперь одна вещь, о данных, когда
вы посмотрите на доступ к данным, когда

1024
00:43:59,650 --> 00:44:02,360
Вы получить доступ к данным, это
всегда о агрегации.

1025
00:44:02,360 --> 00:44:05,770
Это всегда о записях
которые связаны с этим.

1026
00:44:05,770 --> 00:44:10,390
Дайте мне все здесь that's-- все
сделки по этой кредитной карты

1027
00:44:10,390 --> 00:44:12,500
за последний месяц.

1028
00:44:12,500 --> 00:44:13,960
Это агрегации.

1029
00:44:13,960 --> 00:44:17,490
>> Почти все, что вы делаете в
База данных какой-агрегации.

1030
00:44:17,490 --> 00:44:21,530
Так будучи в состоянии быть в состоянии определить
эти ведра и дать вам эти ассортимент

1031
00:44:21,530 --> 00:44:24,950
атрибуты, чтобы иметь возможность запрашивать на,
эти богатые запросы поддержки многих

1032
00:44:24,950 --> 00:44:27,165
много, много моделей доступа к приложению.

1033
00:44:27,165 --> 00:44:30,990

1034
00:44:30,990 --> 00:44:35,000
>> Так другой предмет Хэш ключа
делает это дает нам механизм

1035
00:44:35,000 --> 00:44:37,740
чтобы иметь возможность расширить данные вокруг.

1036
00:44:37,740 --> 00:44:40,390
Базы данных NoSQL работать лучше
когда данные равномерно

1037
00:44:40,390 --> 00:44:41,740
распределены в кластере.

1038
00:44:41,740 --> 00:44:44,530

1039
00:44:44,530 --> 00:44:47,050
Сколько людей знакомы
с алгоритмов хеширования?

1040
00:44:47,050 --> 00:44:49,860
Когда я говорю, хэш и hashing--
потому алгоритма хеширования

1041
00:44:49,860 --> 00:44:54,140
это способ быть в состоянии генерировать
случайное значение от любого заданного значения.

1042
00:44:54,140 --> 00:44:59,300
Таким образом, в данном конкретном случае,
хэш алгоритм бежим является Н.Д. 5 на основе.

1043
00:44:59,300 --> 00:45:04,765
>> И если у меня есть ID, и это
мой хэш-ключ, у меня есть 1, 2, 3.

1044
00:45:04,765 --> 00:45:07,390
Когда я запускаю алгоритм хэширования,
он собирается вернуться и сказать,

1045
00:45:07,390 --> 00:45:10,800
а 1 равен 7В, 2
равна 48, 3 равна компакт-диска.

1046
00:45:10,800 --> 00:45:13,092
Они разбросаны по всему ключевого пространства.

1047
00:45:13,092 --> 00:45:14,050
И почему вы это делаете?

1048
00:45:14,050 --> 00:45:17,120
Потому что гарантирует, что я могу
положить записи на нескольких узлах.

1049
00:45:17,120 --> 00:45:19,574
>> Если я делаю это
постепенно, 1, 2, 3.

1050
00:45:19,574 --> 00:45:21,990
И у меня есть выбор, что хэш-
работает в данном конкретном случае,

1051
00:45:21,990 --> 00:45:24,785
небольшое пространство хэш,
он работает от 00 до FF,

1052
00:45:24,785 --> 00:45:27,951
то записи будут приходить в
и они собираются идти 1, 2, 3, 4, 5,

1053
00:45:27,951 --> 00:45:30,390
6, 7, 8, 9, 10, 11, 12.

1054
00:45:30,390 --> 00:45:31,800
Что происходит?

1055
00:45:31,800 --> 00:45:34,860
Каждый вкладыш идет в том же узле.

1056
00:45:34,860 --> 00:45:36,070
Вы видите, что я имею в виду?

1057
00:45:36,070 --> 00:45:40,910
>> Потому что, когда я разделить пространство,
и я распространять эти записи через,

1058
00:45:40,910 --> 00:45:45,950
и я раздел, я собираюсь сказать,
раздел 1 имеет ключевое пространство от 0 до 54.

1059
00:45:45,950 --> 00:45:47,720
Раздел 2 55 до 89.

1060
00:45:47,720 --> 00:45:49,780
Раздел 3 АА FF.

1061
00:45:49,780 --> 00:45:53,740
Так что, если я использую линейно увеличивая
Идентификаторы, вы можете видеть, что происходит.

1062
00:45:53,740 --> 00:45:57,410
1, 2, 3, 4, 5, 6, весь путь до 54.

1063
00:45:57,410 --> 00:46:00,030
Так, как я молотком
записи в системе,

1064
00:46:00,030 --> 00:46:02,030
все заканчивается тем, что шли к одному узлу.

1065
00:46:02,030 --> 00:46:03,160
>> Это не хорошо.

1066
00:46:03,160 --> 00:46:04,820
Это антипаттерн.

1067
00:46:04,820 --> 00:46:08,760
В MongoDB они имеют эту проблему
если вы не используете хэш-ключ.

1068
00:46:08,760 --> 00:46:11,325
MongoDB дает вам возможность
хэширования значение ключа.

1069
00:46:11,325 --> 00:46:13,950
Вы всегда должны делать, если
Вы используете приращения хеш

1070
00:46:13,950 --> 00:46:17,380
Ключ в MongoDB, или вы будете
гвоздей каждой записи в одном узле,

1071
00:46:17,380 --> 00:46:21,290
и вы будете ограничивая
Вы пишете пропускная плохо.

1072
00:46:21,290 --> 00:46:24,896
>> АУДИТОРИЯ: Это A9 169 в десятичной?

1073
00:46:24,896 --> 00:46:28,450
>> РИК Хулихэном: Да, это
где-то около там.

1074
00:46:28,450 --> 00:46:29,950
A9, я не знаю.

1075
00:46:29,950 --> 00:46:32,200
Вы должны были бы получить мой двоичный
в десятичную калькулятор.

1076
00:46:32,200 --> 00:46:34,237
Мой мозг не работает так.

1077
00:46:34,237 --> 00:46:36,320
АУДИТОРИЯ: Просто быстро одним
Ваши комментарии Mongo.

1078
00:46:36,320 --> 00:46:39,530
Так идентификатор объекта, который поставляется
изначально с Монго сделать?

1079
00:46:39,530 --> 00:46:40,179

1080
00:46:40,179 --> 00:46:41,470
РИК Хулихэном: она это делает?

1081
00:46:41,470 --> 00:46:42,970
Если вы укажите его.

1082
00:46:42,970 --> 00:46:45,030
В MongoDB, у вас есть возможность.

1083
00:46:45,030 --> 00:46:48,930
Вы можете specify-- каждый документ в
MongoDB должен иметь подчеркивания ID.

1084
00:46:48,930 --> 00:46:50,300
Это уникальное значение.

1085
00:46:50,300 --> 00:46:55,240
>> В MongoDB вы можете указать
ли хэш его или нет.

1086
00:46:55,240 --> 00:46:56,490
Они просто дают вам возможность.

1087
00:46:56,490 --> 00:46:58,198
Если вы знаете, что это
не случайный, не проблема.

1088
00:46:58,198 --> 00:46:59,640
Вам не нужно этого делать.

1089
00:46:59,640 --> 00:47:04,260
Если вы знаете, что это не случайно, что
это приращение, а затем сделать хэш.

1090
00:47:04,260 --> 00:47:06,880
>> Теперь дело о
хэширования, когда вы хэш

1091
00:47:06,880 --> 00:47:08,800
value-- и это
почему хэш-ключи всегда

1092
00:47:08,800 --> 00:47:13,740
уникальные запросы, потому что я изменилась
значение, в настоящее время я не могу сделать диапазон запросов.

1093
00:47:13,740 --> 00:47:15,640
Я не могу сказать, это
между тем или иным,

1094
00:47:15,640 --> 00:47:20,800
потому что хэш-значение не будет
быть эквивалентна реальной стоимости.

1095
00:47:20,800 --> 00:47:24,570
Итак, когда вы хэш, что
Ключ, это только равенство.

1096
00:47:24,570 --> 00:47:28,700
Вот почему в DynamoDB хеш-ключа
запросы всегда только равенство.

1097
00:47:28,700 --> 00:47:32,090

1098
00:47:32,090 --> 00:47:34,700
>> Так что теперь в диапазоне key--
когда я добавить, что ключевой диапазон,

1099
00:47:34,700 --> 00:47:38,180
те ключевые записи диапазон все приходят и
они получают хранится в том же разделе.

1100
00:47:38,180 --> 00:47:42,430
Таким образом, они очень быстро, легко
извлекается, потому что это хэш,

1101
00:47:42,430 --> 00:47:43,220
это диапазон.

1102
00:47:43,220 --> 00:47:44,928
И вы видите, все
с той же хэш

1103
00:47:44,928 --> 00:47:48,550
получает хранится на том же пространстве разделов.

1104
00:47:48,550 --> 00:47:53,889
Вы можете использовать этот ключ, чтобы помочь диапазон
найти ваши данные близки к своему родителю.

1105
00:47:53,889 --> 00:47:55,180
Так что я на самом деле здесь делаешь?

1106
00:47:55,180 --> 00:47:57,320
Это один ко многим отношений.

1107
00:47:57,320 --> 00:48:01,490
Отношения между ключом хэш-
и ключ диапазон один ко многим.

1108
00:48:01,490 --> 00:48:03,490
Я могу иметь несколько ключей хеш.

1109
00:48:03,490 --> 00:48:07,610
Я могу только иметь несколько выбор
ключи внутри каждого ключа хэша.

1110
00:48:07,610 --> 00:48:11,910
>> Хэш определяет родителя,
диапазон определяет детей.

1111
00:48:11,910 --> 00:48:15,240
Таким образом, вы можете видеть, что это аналог здесь
между реляционной конструкции

1112
00:48:15,240 --> 00:48:18,840
и те же типы
строит в NoSQL.

1113
00:48:18,840 --> 00:48:20,760
Люди говорят о
NoSQL, как нереляционная.

1114
00:48:20,760 --> 00:48:22,200
Это не нереляционная.

1115
00:48:22,200 --> 00:48:24,680
Данные всегда отношения.

1116
00:48:24,680 --> 00:48:28,172
Эти отношения просто
моделируются по-разному.

1117
00:48:28,172 --> 00:48:29,880
Давайте немного поговорим
Немного о долговечности.

1118
00:48:29,880 --> 00:48:34,860
Когда вы пишите в DynamoDB, пишет
всегда трехсторонняя воспроизведены.

1119
00:48:34,860 --> 00:48:37,550
Это означает, что у нас есть три AZ годов.

1120
00:48:37,550 --> 00:48:39,160
Я являются доступность зон.

1121
00:48:39,160 --> 00:48:43,430
Вы можете думать о доступности
Зона в центре обработки данных

1122
00:48:43,430 --> 00:48:45,447
или совокупность центров обработки данных.

1123
00:48:45,447 --> 00:48:47,780
Эти вещи географически
изолированы друг от друга

1124
00:48:47,780 --> 00:48:51,610
разных зон разломов, по
отличается электрические сети и поймы.

1125
00:48:51,610 --> 00:48:54,510
Отказ в одном AZ не
собирается снять еще один.

1126
00:48:54,510 --> 00:48:56,890
Они также связаны
вместе с темно-волокна.

1127
00:48:56,890 --> 00:49:01,240
Он поддерживает один суб 1
Задержка миллисекунду между АЗС.

1128
00:49:01,240 --> 00:49:05,390
Так репликаций данных в режиме реального времени
способны в нескольких АЗС.

1129
00:49:05,390 --> 00:49:09,990
>> И часто мульти развертывание AZ
соответствовать высоким требованиям доступности

1130
00:49:09,990 --> 00:49:12,930
большинства предпринимательских организаций.

1131
00:49:12,930 --> 00:49:16,139
Так DynamoDB распространяется
через три АЗС по умолчанию.

1132
00:49:16,139 --> 00:49:19,430
Мы только собираемся познания записи
когда два из этих трех узлов вернуться

1133
00:49:19,430 --> 00:49:21,470
и сказать, Да, я получил его.

1134
00:49:21,470 --> 00:49:22,050
Почему это?

1135
00:49:22,050 --> 00:49:25,950
Потому что на стороне чтения мы только
собираюсь дать вам данные назад, когда

1136
00:49:25,950 --> 00:49:27,570
мы получаем его из двух узлов.

1137
00:49:27,570 --> 00:49:30,490
>> Если я тиражирование по
три, и я читаю из двух,

1138
00:49:30,490 --> 00:49:32,840
Я всегда гарантируется
иметь по крайней мере один

1139
00:49:32,840 --> 00:49:35,720
тех считывает быть
Актуальная копия данных.

1140
00:49:35,720 --> 00:49:38,340
Это то, что делает DynamoDB последовательным.

1141
00:49:38,340 --> 00:49:42,450
Теперь вы можете включить
тех, которые согласуются считывает.

1142
00:49:42,450 --> 00:49:45,070
В этом случае я собираюсь сказать,
Я буду читать только с одного узла.

1143
00:49:45,070 --> 00:49:47,430
И я не могу гарантировать, что это происходит
чтобы быть наиболее актуальные данные.

1144
00:49:47,430 --> 00:49:49,450
>> Так что, если записи в ближайшие,
это еще не реплицируются,

1145
00:49:49,450 --> 00:49:50,360
Вы собираетесь получить эту копию.

1146
00:49:50,360 --> 00:49:52,220
Это в конечном итоге непротиворечивое чтение.

1147
00:49:52,220 --> 00:49:54,640
И что это такое это половина стоимости.

1148
00:49:54,640 --> 00:49:56,140
Так что это что-то думать.

1149
00:49:56,140 --> 00:50:00,160
Когда вы читаете из DynamoDB, и
вы настраиваете вашу способность чтения

1150
00:50:00,160 --> 00:50:04,430
единиц, если вы выбираете в конечном итоге
соответствует читает, это намного дешевле,,

1151
00:50:04,430 --> 00:50:06,010
это около половины стоимости.

1152
00:50:06,010 --> 00:50:09,342
>> И так экономит ваши деньги.

1153
00:50:09,342 --> 00:50:10,300
Но это ваш выбор.

1154
00:50:10,300 --> 00:50:12,925
Если вы хотите непротиворечивое чтение или
в конечном итоге непротиворечивое чтение.

1155
00:50:12,925 --> 00:50:15,720
Это то, что вы можете выбрать.

1156
00:50:15,720 --> 00:50:17,659
>> Давайте поговорим об индексах.

1157
00:50:17,659 --> 00:50:19,450
Таким образом, мы упомянули, что
топ агрегации уровня.

1158
00:50:19,450 --> 00:50:23,720
У нас есть хэш ключи, и
мы получили ключи дальности.

1159
00:50:23,720 --> 00:50:24,320
Это мило.

1160
00:50:24,320 --> 00:50:26,950
И это на основной таблице, я
есть один хэш-ключ, я получил один ключ диапазона.

1161
00:50:26,950 --> 00:50:27,783
>> Что это значит?

1162
00:50:27,783 --> 00:50:30,410
Я получил один атрибут, что я
может работать богатых запросов к.

1163
00:50:30,410 --> 00:50:31,800
Это ключ диапазона.

1164
00:50:31,800 --> 00:50:35,530
Другие атрибуты на этом item--
Я могу фильтровать этих атрибутов.

1165
00:50:35,530 --> 00:50:40,050
Но я не могу делать вещи, как, это
начинается с или больше.

1166
00:50:40,050 --> 00:50:40,820
>> Как мне это сделать?

1167
00:50:40,820 --> 00:50:42,860
Я создать индекс.

1168
00:50:42,860 --> 00:50:45,340
Там две типы
Индексы в DynamoDB.

1169
00:50:45,340 --> 00:50:49,002
Индекс действительно
Еще один вид таблицы.

1170
00:50:49,002 --> 00:50:50,490
И местный вторичный индекс.

1171
00:50:50,490 --> 00:50:51,781
>> Первый мы поговорим о.

1172
00:50:51,781 --> 00:50:57,740
Так местные вторичные которые сосуществовали
в том же разделе, что и данные.

1173
00:50:57,740 --> 00:51:00,240
И как таковые, они находятся на
и тот же физический узел.

1174
00:51:00,240 --> 00:51:01,780
Они, что мы называем последовательной.

1175
00:51:01,780 --> 00:51:04,599
Значение, они признают,
от записи вместе с таблицей.

1176
00:51:04,599 --> 00:51:06,890
Когда записи приходит,
мы напишем через индекс.

1177
00:51:06,890 --> 00:51:09,306
Мы напишем к столу,
и тогда мы будем иметь в виду.

1178
00:51:09,306 --> 00:51:10,490
Так вот последовательным.

1179
00:51:10,490 --> 00:51:13,174
После того, как записи были
признал из таблицы,

1180
00:51:13,174 --> 00:51:15,090
это гарантирует, что
местный вторичный индекс

1181
00:51:15,090 --> 00:51:18,380
будет иметь то же самое видение данных.

1182
00:51:18,380 --> 00:51:22,390
Но то, что они позволяют вам делать это
определить ключи альтернативные дальности.

1183
00:51:22,390 --> 00:51:25,260
>> Придется использовать одинаковые хеш
Ключ в качестве основного стола,

1184
00:51:25,260 --> 00:51:29,050
потому что они расположены совместно на
тот же раздел, и они соответствуют.

1185
00:51:29,050 --> 00:51:33,110
Но я могу создать индекс
с разными ключами дальности.

1186
00:51:33,110 --> 00:51:41,590
Так, например, если бы я имел производителю
что было сырым стол части входит.

1187
00:51:41,590 --> 00:51:44,590
И сырье части приходят в и
они агрегируются сборки.

1188
00:51:44,590 --> 00:51:46,840
И, может быть, есть отзыв.

1189
00:51:46,840 --> 00:51:50,240
>> Любая часть, которая была сделана эта
производитель после этой даты,

1190
00:51:50,240 --> 00:51:52,840
Мне нужно, чтобы вытащить из моей линии.

1191
00:51:52,840 --> 00:51:55,950
Я могу вращаться индекс
что будут искать,

1192
00:51:55,950 --> 00:52:00,760
агрегирования на дату
производство этой конкретной части.

1193
00:52:00,760 --> 00:52:03,930
Так что, если мой стол был верхний уровень
уже хэшируется производителя,

1194
00:52:03,930 --> 00:52:07,655
может быть, это было устроено на часть ID, я
может создать индекс выключения этой таблицы

1195
00:52:07,655 --> 00:52:11,140
а хэш производителем и
колебалась от даты изготовления.

1196
00:52:11,140 --> 00:52:14,490
И таким образом я мог бы сказать, все, что
был изготовлен между этими датами,

1197
00:52:14,490 --> 00:52:16,804
Мне нужно, чтобы вытащить из линии.

1198
00:52:16,804 --> 00:52:18,220
Так что это местный вторичный индекс.

1199
00:52:18,220 --> 00:52:22,280
>> Они имеют эффект
ограничивая хэш пространство ключей.

1200
00:52:22,280 --> 00:52:24,360
Потому что они сосуществовали
на том же узле хранения,

1201
00:52:24,360 --> 00:52:26,860
они ограничивают хэш-ключ
пространство 10 гигабайт.

1202
00:52:26,860 --> 00:52:28,950
DynamoDB, под
столы, будет разделить

1203
00:52:28,950 --> 00:52:31,380
Ваш стол каждые 10 гигабайт.

1204
00:52:31,380 --> 00:52:34,760
Когда вы кладете 10 концертов данных в, мы
перейти [ФН], и мы добавляем еще один узел.

1205
00:52:34,760 --> 00:52:38,120

1206
00:52:38,120 --> 00:52:42,070
>> Мы не будем разделить LSI
по нескольким разделам.

1207
00:52:42,070 --> 00:52:43,200
Мы разбить таблицу.

1208
00:52:43,200 --> 00:52:44,679
Но мы не будем разделять LSI.

1209
00:52:44,679 --> 00:52:46,470
Так это то, что
Важно понимать,

1210
00:52:46,470 --> 00:52:50,070
если вы делаете очень,
очень, очень большие скопления,

1211
00:52:50,070 --> 00:52:53,860
то вы будете ограничиваться
10 гигабайт на вашем БИС.

1212
00:52:53,860 --> 00:52:56,640
>> Если это так, то мы можем
использовать глобальные вторичные.

1213
00:52:56,640 --> 00:52:58,630
Глобальные вторичные являются
действительно другая таблица.

1214
00:52:58,630 --> 00:53:01,720
Они существуют, чтобы полностью от
сторона из вашей первичной таблицы.

1215
00:53:01,720 --> 00:53:04,680
И они позволяют мне найти
совершенно разные структуры.

1216
00:53:04,680 --> 00:53:08,010
Так что думайте о нем, как данные вставляются
в двух разных таблиц, структурированный

1217
00:53:08,010 --> 00:53:09,220
двумя различными способами.

1218
00:53:09,220 --> 00:53:11,360
>> Я могу определить совершенно
отличается хэш-ключ.

1219
00:53:11,360 --> 00:53:13,490
Я могу определить совершенно
другая клавиша диапазона.

1220
00:53:13,490 --> 00:53:15,941
И я могу запустить этот
совершенно независимо.

1221
00:53:15,941 --> 00:53:18,190
В самом деле, у меня
подготовлено мою способность чтения

1222
00:53:18,190 --> 00:53:21,090
и написать емкость для моего
глобальные вторичные индексы

1223
00:53:21,090 --> 00:53:24,240
совершенно независимо
моей основной таблице.

1224
00:53:24,240 --> 00:53:26,640
Если я определяю, что индекс, я говорю
это сколько читать и писать

1225
00:53:26,640 --> 00:53:28,610
Объем он собирается использовать.

1226
00:53:28,610 --> 00:53:31,490
>> И это отдельная
от моей основной таблицы.

1227
00:53:31,490 --> 00:53:35,240
Теперь оба индекса позволит нам
не только определить хэш и дальности ключи,

1228
00:53:35,240 --> 00:53:38,610
но они позволяют нам
проекта дополнительных значений.

1229
00:53:38,610 --> 00:53:44,950
Так что, если я хочу, чтобы считывать индекс,
и я хочу, чтобы получить набор данных,

1230
00:53:44,950 --> 00:53:48,327
Мне не нужно, чтобы вернуться к главному
Таблица, чтобы получить дополнительные атрибуты.

1231
00:53:48,327 --> 00:53:50,660
Я могу спроектировать эти дополнительные
атрибутов в таблице

1232
00:53:50,660 --> 00:53:53,440
поддержать доступа к файлу.

1233
00:53:53,440 --> 00:53:57,700
Я знаю, что мы, вероятно, получить в некоторые
действительно, really-- попадание в сорняков

1234
00:53:57,700 --> 00:53:58,910
здесь, на некоторые из этих вещей.

1235
00:53:58,910 --> 00:54:02,725
Теперь я получил дрейфовать из этого.

1236
00:54:02,725 --> 00:54:07,320
>> АУДИТОРИЯ: [неразборчиво]
--table ключ имел в виду, хэш?

1237
00:54:07,320 --> 00:54:08,840
Оригинальный хэш?

1238
00:54:08,840 --> 00:54:09,340
Multi-рейки?

1239
00:54:09,340 --> 00:54:10,200
>> РИК Хулихэном: Да.

1240
00:54:10,200 --> 00:54:11,070
Да.

1241
00:54:11,070 --> 00:54:15,260
Ключ таблицы в основном
указывает обратно к пункту.

1242
00:54:15,260 --> 00:54:19,280
Так индекс является указателем обратно
оригинальные предметы на столе.

1243
00:54:19,280 --> 00:54:22,910
Теперь вы можете выбрать, чтобы построить
индекс, который имеет только ключ таблицы,

1244
00:54:22,910 --> 00:54:24,840
и никаких других свойств.

1245
00:54:24,840 --> 00:54:26,570
И почему я мог бы сделать это?

1246
00:54:26,570 --> 00:54:28,570
Ну, может быть, у меня очень большие предметы.

1247
00:54:28,570 --> 00:54:31,660
>> Я действительно только нужно знать which--
мой образец доступа можно сказать,

1248
00:54:31,660 --> 00:54:33,760
которые содержат элементы этого отеля?

1249
00:54:33,760 --> 00:54:35,780
Не нужно возвратить деталь.

1250
00:54:35,780 --> 00:54:37,800
Мне просто нужно знать,
какие элементы содержат его.

1251
00:54:37,800 --> 00:54:40,700
Таким образом, вы можете построить индексы
что только есть ключ таблицы.

1252
00:54:40,700 --> 00:54:43,360
>> Но это, прежде всего, то, что
индекс в базе данных для.

1253
00:54:43,360 --> 00:54:46,280
Это за то, что в состоянии быстро
определить, какие записи,

1254
00:54:46,280 --> 00:54:49,470
какие строки, которые
элементы таблицы имеют

1255
00:54:49,470 --> 00:54:51,080
свойства, которые я искал.

1256
00:54:51,080 --> 00:54:53,610

1257
00:54:53,610 --> 00:54:54,860
>> СБИС, так как они работают?

1258
00:54:54,860 --> 00:54:58,340
СБИС в основном являются асинхронными.

1259
00:54:58,340 --> 00:55:02,570
Обновление вступает в таблице,
Таблица затем асинхронно обновляется

1260
00:55:02,570 --> 00:55:03,720
все ваши СБИС.

1261
00:55:03,720 --> 00:55:06,680
Вот почему СБИС являются
в конечном итоге согласуются.

1262
00:55:06,680 --> 00:55:09,440
>> Важно отметить, что
когда вы строите СБИС,

1263
00:55:09,440 --> 00:55:13,110
и вы понимаете, вы создаете
другое измерение aggregation--

1264
00:55:13,110 --> 00:55:16,594
Теперь давайте говорить хороший пример
здесь производитель.

1265
00:55:16,594 --> 00:55:19,260
Я думаю, что я, возможно, говорили о
производитель медицинского устройства.

1266
00:55:19,260 --> 00:55:23,870
Производители медицинских изделий
часто имеют серийные номера части.

1267
00:55:23,870 --> 00:55:28,070
Части, которые входят в
замена тазобедренного все

1268
00:55:28,070 --> 00:55:30,200
есть немного серийный номер на них.

1269
00:55:30,200 --> 00:55:33,584
И они могли бы миллионы и
миллионы и миллиарды частей

1270
00:55:33,584 --> 00:55:35,000
во всех устройствах, которые они поставляются.

1271
00:55:35,000 --> 00:55:37,440
Ну, они должны объединять под
различные размеры, все части

1272
00:55:37,440 --> 00:55:39,520
в сборке, все
части, которые были сделаны

1273
00:55:39,520 --> 00:55:41,670
на некоторой линии, все
части, которые пришли

1274
00:55:41,670 --> 00:55:44,620
в с определенной производителя
на определенную дату.

1275
00:55:44,620 --> 00:55:47,940
И эти скопления иногда
встать в миллиарды.

1276
00:55:47,940 --> 00:55:50,550
>> Так что я работать с некоторыми из
эти ребята, которые страдают

1277
00:55:50,550 --> 00:55:53,156
потому что они создают
эти скопления GINORMOUS

1278
00:55:53,156 --> 00:55:54,280
в их вторичных индексов.

1279
00:55:54,280 --> 00:55:57,070
Они могут иметь сырые части
таблица, приходит как только хэш.

1280
00:55:57,070 --> 00:55:59,090
Каждая часть имеет уникальный серийный номер.

1281
00:55:59,090 --> 00:56:00,975
Я использую серийный номер, как хэш.

1282
00:56:00,975 --> 00:56:01,600
Оно прекрасно.

1283
00:56:01,600 --> 00:56:04,160
Мой сырье таблица данных распространяется
по всей ключевого пространства.

1284
00:56:04,160 --> 00:56:05,930
Мой [? записывать ?]
[? проглатывание?] является удивительным.

1285
00:56:05,930 --> 00:56:07,876
Я беру много данных.

1286
00:56:07,876 --> 00:56:09,500
Тогда то, что они делают, они создают GSI.

1287
00:56:09,500 --> 00:56:12,666
И я говорю, вы знаете, что, мне нужно, чтобы увидеть
все части данного производителя.

1288
00:56:12,666 --> 00:56:15,060
Ну, вдруг я
принимая миллиарда строк,

1289
00:56:15,060 --> 00:56:17,550
и запихивать их на
один узел, потому что, когда

1290
00:56:17,550 --> 00:56:21,170
Я, как агрегировать
производитель ID, как хэш,

1291
00:56:21,170 --> 00:56:25,410
и номер в диапазоне,
затем все вдруг я

1292
00:56:25,410 --> 00:56:30,530
поставив млрд части в то, что
этот производитель избавил меня.

1293
00:56:30,530 --> 00:56:34,447
>> Это может вызвать много
давления на GSI,

1294
00:56:34,447 --> 00:56:36,030
снова, потому что я молотком один узел.

1295
00:56:36,030 --> 00:56:38,350
Я ставлю все эти
вставляет в одном узле.

1296
00:56:38,350 --> 00:56:40,940
И это реальная проблематично кейс.

1297
00:56:40,940 --> 00:56:43,479
Теперь, я получил хороший дизайн
шаблон для, как вы избежать.

1298
00:56:43,479 --> 00:56:45,770
И это одна из проблем,
что я всегда работать.

1299
00:56:45,770 --> 00:56:49,590
Но то, что происходит, является GSI может
не хватает мощности записи

1300
00:56:49,590 --> 00:56:52,330
чтобы быть в состоянии выдвинуть все те
строк в одном узле.

1301
00:56:52,330 --> 00:56:55,390
И то, что происходит потом это
первичный, таблица Клиент,

1302
00:56:55,390 --> 00:57:00,180
главная таблица будет задушил
потому что GSI не может угнаться.

1303
00:57:00,180 --> 00:57:02,980
Так что мой курс будет вставка
падают на основной таблице

1304
00:57:02,980 --> 00:57:06,230
как мой GSI пытается не отставать.

1305
00:57:06,230 --> 00:57:08,850
>> Ладно, так GSI-х, БИС,
какой я должен использовать?

1306
00:57:08,850 --> 00:57:12,290
БИС согласуются.

1307
00:57:12,290 --> 00:57:13,750
GSI являются в конечном счете соответствует.

1308
00:57:13,750 --> 00:57:17,490
Если это нормально, я рекомендую использовать
GSI, они гораздо более гибким.

1309
00:57:17,490 --> 00:57:20,270
БИС могут быть смоделированы как GSI.

1310
00:57:20,270 --> 00:57:27,040
И если размер данных в хэш-ключей в
Ваша коллекция превышает 10 гигабайт,

1311
00:57:27,040 --> 00:57:31,050
то вы будете хотеть использовать что
GSI, потому что это просто жесткий лимит.

1312
00:57:31,050 --> 00:57:32,035
>> Ладно, так масштабирования.

1313
00:57:32,035 --> 00:57:35,210

1314
00:57:35,210 --> 00:57:37,460
Пропускная в Динамо БД, вы
положение может [неразборчиво]

1315
00:57:37,460 --> 00:57:38,680
пропускная к столу.

1316
00:57:38,680 --> 00:57:42,740
У нас есть клиенты, которые имеют
подготовлено 60 billion--

1317
00:57:42,740 --> 00:57:45,970
делают 60 млрд запросов, регулярно
работает на более чем миллион запросов

1318
00:57:45,970 --> 00:57:47,790
за секунду на наших столах.

1319
00:57:47,790 --> 00:57:50,360
Там на самом деле нет
Теоретический предел того, сколько

1320
00:57:50,360 --> 00:57:53,730
и как быстро таблица
может работать в Динамо БД.

1321
00:57:53,730 --> 00:57:55,920
Есть некоторые мягкие
лимиты на ваш счет

1322
00:57:55,920 --> 00:57:58,170
что мы ставим там так
что вы не сходите с ума.

1323
00:57:58,170 --> 00:58:00,070
Если вы хотите больше, чем
что не является проблемой.

1324
00:58:00,070 --> 00:58:00,820
Вы приходите, сообщите нам.

1325
00:58:00,820 --> 00:58:02,810
Мы поднимите диск.

1326
00:58:02,810 --> 00:58:08,210
>> Каждая учетная запись ограничена какой-то степени
в каждой службе, просто с места в карьер

1327
00:58:08,210 --> 00:58:11,920
так что люди не сходят с ума
попадают в неприятности.

1328
00:58:11,920 --> 00:58:12,840
Нет предела в размере.

1329
00:58:12,840 --> 00:58:14,940
Вы можете поместить любое количество
элементов на столе.

1330
00:58:14,940 --> 00:58:17,620
Размер элемента является
ограничивается до 400 килобайт каждый,

1331
00:58:17,620 --> 00:58:20,050
что бы элемент не атрибуты.

1332
00:58:20,050 --> 00:58:24,200
Так сумме всех атрибутов
ограничивается до 400 килобайт.

1333
00:58:24,200 --> 00:58:27,300
И опять же, у нас есть
что мало БИС вопрос

1334
00:58:27,300 --> 00:58:30,405
с пределом 10 гигабайт на хэш.

1335
00:58:30,405 --> 00:58:33,280
АУДИТОРИЯ: Небольшое количество, я пропускаю
то, что вы говорили мне, что is--

1336
00:58:33,280 --> 00:58:36,830
АУДИТОРИЯ: Да, 400 килобайта
максимальный размер по каждому пункту.

1337
00:58:36,830 --> 00:58:39,570
Так элемент имеет все атрибуты.

1338
00:58:39,570 --> 00:58:43,950
Так 400 К общий размер
этого элемента, 400 килобайт.

1339
00:58:43,950 --> 00:58:46,170
Так всех признаков
комбинированные все данные

1340
00:58:46,170 --> 00:58:49,140
это во всех этих атрибутов,
закатал в общей численности,

1341
00:58:49,140 --> 00:58:51,140
В настоящее время предел пункт сегодня 400 к.

1342
00:58:51,140 --> 00:58:54,390

1343
00:58:54,390 --> 00:58:57,046
Так масштабирования снова, достигается
посредством перегородок.

1344
00:58:57,046 --> 00:58:58,920
Пропускная способность предусмотренном
на уровне таблицы.

1345
00:58:58,920 --> 00:59:00,160
И там действительно две ручки.

1346
00:59:00,160 --> 00:59:02,400
Мы читали мощность
и написать емкость.

1347
00:59:02,400 --> 00:59:05,530
>> Таким образом, эти корректируются
независимо друг от друга.

1348
00:59:05,530 --> 00:59:08,640
Мера РКО в строго согласованные чтения.

1349
00:59:08,640 --> 00:59:13,005
ОК, так что если вы говорите, я хочу 1000
РКО-х те, строго последовательным,

1350
00:59:13,005 --> 00:59:14,130
тех, согласуются читает.

1351
00:59:14,130 --> 00:59:17,130
Если вы хотите сказать, что я
возможное непротиворечивое чтение,

1352
00:59:17,130 --> 00:59:19,402
Вы можете предоставление 1000
РКО, вы идете

1353
00:59:19,402 --> 00:59:21,840
чтобы получить в конечном итоге 2,000
соответствует читает.

1354
00:59:21,840 --> 00:59:25,940
И половина цены для тех,
в конечном итоге состоят в читает.

1355
00:59:25,940 --> 00:59:28,520
>> Опять же, регулируется
независимо друг от друга.

1356
00:59:28,520 --> 00:59:32,900
И у них есть throughput--
Если вы потребляете 100% от вашего РКО,

1357
00:59:32,900 --> 00:59:35,960
вы не собираетесь, чтобы повлиять на
наличие ваших прав.

1358
00:59:35,960 --> 00:59:40,161
Таким образом, они полностью
независимы друг от друга.

1359
00:59:40,161 --> 00:59:43,160
Ладно, так что один из вещей, которые
Я кратко упомянуто было дросселирования.

1360
00:59:43,160 --> 00:59:44,320
Регулирование плохо.

1361
00:59:44,320 --> 00:59:47,311
Регулирование указывает плохо не SQL.

1362
00:59:47,311 --> 00:59:50,310
Есть вещи, которые мы можем сделать, чтобы помочь
вам облегчить дросселирование, что вам

1363
00:59:50,310 --> 00:59:51,040
испытывают.

1364
00:59:51,040 --> 00:59:53,240
Но лучшее решение
чтобы это давайте

1365
00:59:53,240 --> 00:59:58,000
Взгляд на то, что вы делаете, потому что
есть анти-паттерна в игре здесь.

1366
00:59:58,000 --> 01:00:02,140
>> Эти вещи, вещи, как неоднородных
нагрузки, горячие клавиши, горячие перегородки.

1367
01:00:02,140 --> 01:00:06,210
Я удара особое пространство ключей
очень трудно, по определенным причинам.

1368
01:00:06,210 --> 01:00:07,080
Почему я это делаю?

1369
01:00:07,080 --> 01:00:08,710
Давайте понять.

1370
01:00:08,710 --> 01:00:10,427
Я смешиваю мои горячие данные с холодными данных.

1371
01:00:10,427 --> 01:00:12,510
Я позволяю мои таблицы получить
Огромный, но там действительно

1372
01:00:12,510 --> 01:00:15,970
только некоторое подмножество данных
это действительно интересно для меня.

1373
01:00:15,970 --> 01:00:20,290
Таким образом, для данных журнала, например, много
клиенты, они получают данные, авторизуйтесь каждый день.

1374
01:00:20,290 --> 01:00:22,490
Они получили огромное количество данных журнала.

1375
01:00:22,490 --> 01:00:25,940
>> Если вы только что демпинг все журнал
данные в одной большой таблице, со временем

1376
01:00:25,940 --> 01:00:28,070
эта таблица собирается получить массивное.

1377
01:00:28,070 --> 01:00:30,950
Но я действительно заинтересованы только в
Последние 24 часов, последние семь дней,

1378
01:00:30,950 --> 01:00:31,659
последние 30 дней.

1379
01:00:31,659 --> 01:00:34,074
Как бы то ни промежуток времени
что я заинтересованы в поиске

1380
01:00:34,074 --> 01:00:37,010
для события, беспокоит меня, или
событие, которое мне интересно,

1381
01:00:37,010 --> 01:00:39,540
что единственный раз, когда окно, что мне нужно.

1382
01:00:39,540 --> 01:00:42,470
Итак, почему я положить 10 лет
Стоит каротажных данных в таблице?

1383
01:00:42,470 --> 01:00:45,030
То, что это вызывает это
таблица фрагмент.

1384
01:00:45,030 --> 01:00:45,880
>> Он получает огромное.

1385
01:00:45,880 --> 01:00:48,340
Это начинает распространяться из
на тысячи узлов.

1386
01:00:48,340 --> 01:00:51,380
А так как ваша способность
так низко, вы

1387
01:00:51,380 --> 01:00:54,090
на самом деле ограничения скорости на каждом
один из тех отдельных узлов.

1388
01:00:54,090 --> 01:00:57,120
Итак, давайте начнем, глядя на том, как
мы свернуть эту таблицу в течение.

1389
01:00:57,120 --> 01:01:01,502
Как мы можем управлять, что данные немного
лучше, чтобы избежать этих проблем.

1390
01:01:01,502 --> 01:01:02,710
И то, что это похоже?

1391
01:01:02,710 --> 01:01:04,370
Это то, что, что выглядит.

1392
01:01:04,370 --> 01:01:06,790
Это то, что плохо NoSQL выглядит.

1393
01:01:06,790 --> 01:01:07,830
>> Я получил горячую клавишу здесь.

1394
01:01:07,830 --> 01:01:10,246
Если вы посмотрите на стороне здесь,
это все мои разделы.

1395
01:01:10,246 --> 01:01:12,630
Я получил 16 разделов здесь
на этой конкретной базы данных.

1396
01:01:12,630 --> 01:01:13,630
Мы делаем это все время.

1397
01:01:13,630 --> 01:01:15,046
Я запускаю это для клиентов все время.

1398
01:01:15,046 --> 01:01:16,550
Это называется тепловой карте.

1399
01:01:16,550 --> 01:01:20,590
Тепловая карта говорит мне, как ты
доступа к вашей пространство ключей.

1400
01:01:20,590 --> 01:01:23,700
И то, что это говорит мне, это
что есть один конкретный хеш

1401
01:01:23,700 --> 01:01:26,330
что этот парень любит
очень много, потому что он

1402
01:01:26,330 --> 01:01:28,250
ударив по нему действительно, действительно трудно.

1403
01:01:28,250 --> 01:01:29,260
>> Таким образом, синий приятно.

1404
01:01:29,260 --> 01:01:29,900
Нам нравится синий.

1405
01:01:29,900 --> 01:01:30,720
Нам не нравится красный цвет.

1406
01:01:30,720 --> 01:01:33,120
Где давление Реда
получает до 100%.

1407
01:01:33,120 --> 01:01:35,560
100%, теперь вы будете задушил.

1408
01:01:35,560 --> 01:01:39,030
Поэтому, когда вы видите красные линии, как
this-- и это не только Динамо DB--

1409
01:01:39,030 --> 01:01:41,630
каждая база данных NoSQL имеет эту проблему.

1410
01:01:41,630 --> 01:01:44,640
Есть антишаблоны, которые могут
управлять этими типами условий.

1411
01:01:44,640 --> 01:01:49,070
То, что я делаю, я работаю с клиентами
чтобы облегчить эти условия.

1412
01:01:49,070 --> 01:01:51,840
>> И то, что это похоже?

1413
01:01:51,840 --> 01:01:54,260
И это становится наиболее
из Динамо DB пропускной способности,

1414
01:01:54,260 --> 01:01:56,176
но это действительно становится
большинство из NoSQL.

1415
01:01:56,176 --> 01:01:58,740
Это не ограничивается Динамо.

1416
01:01:58,740 --> 01:02:02,050
Это я definitely--
используется для работы в Монго.

1417
01:02:02,050 --> 01:02:04,090
Я знаком со многими платформами NoSQL.

1418
01:02:04,090 --> 01:02:06,830
Каждый человек имеет эти типы
горячих ключевых проблем.

1419
01:02:06,830 --> 01:02:10,320
Чтобы получить максимальную отдачу от любой NoSQL
базы данных, специально Динамо БД,

1420
01:02:10,320 --> 01:02:13,320
Вы хотите, чтобы создать таблицы
где элемент хэш-ключ имеет

1421
01:02:13,320 --> 01:02:18,590
большое количество различных значений,
высокая степень мощности.

1422
01:02:18,590 --> 01:02:22,530
Потому что это означает, что я пишу
на множество различных ковшей.

1423
01:02:22,530 --> 01:02:24,870
>> Чем больше я в ведра
письменной форме, тем более вероятно,

1424
01:02:24,870 --> 01:02:29,100
Я распространять эту нагрузку записи или
прочитать загрузить из по нескольким узлам,

1425
01:02:29,100 --> 01:02:33,560
тем более вероятно, я должен иметь
высокая пропускная способность на стол.

1426
01:02:33,560 --> 01:02:37,440
А потом я хочу, чтобы быть значения
просил довольно равномерно в течение долгого времени

1427
01:02:37,440 --> 01:02:39,430
и равномерно, как случайным образом, насколько это возможно.

1428
01:02:39,430 --> 01:02:42,410
Ну, это довольно интересно,
потому что я не могу на самом деле

1429
01:02:42,410 --> 01:02:43,960
контроль, когда пользователи приходят.

1430
01:02:43,960 --> 01:02:47,645
Так достаточно сказать, если мы распространяем
вещи из всей ключевого пространства,

1431
01:02:47,645 --> 01:02:49,270
мы, вероятно, будет в лучшей форме.

1432
01:02:49,270 --> 01:02:51,522
>> Там определенная
количество времени доставки

1433
01:02:51,522 --> 01:02:53,230
что вы не собираетесь
чтобы быть в состоянии контролировать.

1434
01:02:53,230 --> 01:02:55,438
Но это на самом деле
два аспекта, которые мы имеем,

1435
01:02:55,438 --> 01:02:58,800
пространство, доступ равномерно
распространение, время, запросы

1436
01:02:58,800 --> 01:03:01,040
прибывающим равномерно во времени.

1437
01:03:01,040 --> 01:03:03,110
И если эти два
удовлетворяются условия,

1438
01:03:03,110 --> 01:03:05,610
то, что то, что это
будет выглядеть.

1439
01:03:05,610 --> 01:03:07,890
Это гораздо приятнее.

1440
01:03:07,890 --> 01:03:08,890
Мы действительно счастливы здесь.

1441
01:03:08,890 --> 01:03:10,432
Мы получили очень даже модель доступа.

1442
01:03:10,432 --> 01:03:13,098
Да, может быть, вы получаете
небольшое давление каждый сейчас и потом,

1443
01:03:13,098 --> 01:03:14,830
но ничего действительно слишком обширная.

1444
01:03:14,830 --> 01:03:17,660
Так что это удивительно, как много раз,
когда я работаю с клиентами,

1445
01:03:17,660 --> 01:03:20,670
что первый график с большой красный
бар и все, что уродливые желтые это

1446
01:03:20,670 --> 01:03:23,147
повсюду, мы
сделано с осуществлением

1447
01:03:23,147 --> 01:03:24,980
через пару месяцев
повторного архитектуры,

1448
01:03:24,980 --> 01:03:28,050
они работают точно такой же
нагрузка в то же самое нагрузки.

1449
01:03:28,050 --> 01:03:30,140
И это то, что он ищет, как сейчас.

1450
01:03:30,140 --> 01:03:36,600
Так что вы получаете с NoSQL является
Схема данных, абсолютно

1451
01:03:36,600 --> 01:03:38,510
привязан к модели доступа.

1452
01:03:38,510 --> 01:03:42,170
>> И вы можете оптимизировать эту схему данных
поддержать эту модель доступа.

1453
01:03:42,170 --> 01:03:45,490
Если вы этого не сделаете, то вы будете
чтобы увидеть эти типы проблем

1454
01:03:45,490 --> 01:03:46,710
с тех горячих клавиш.

1455
01:03:46,710 --> 01:03:50,518
>> АУДИТОРИЯ: Ну, неизбежно некоторые места
будут жарче, чем другие.

1456
01:03:50,518 --> 01:03:51,450
>> РИК Хулихэном: Всегда.

1457
01:03:51,450 --> 01:03:51,960
Всегда.

1458
01:03:51,960 --> 01:03:54,620
Да, я имею в виду всегда есть
a-- и снова, есть

1459
01:03:54,620 --> 01:03:56,980
некоторые шаблоны проектирования, мы пройдем через
что будет говорить о том, как вы имеете дело

1460
01:03:56,980 --> 01:03:58,480
с этих супер больших скоплений.

1461
01:03:58,480 --> 01:04:01,260
Я имею в виду, я должен иметь их,
как мы имеем дело с ними?

1462
01:04:01,260 --> 01:04:03,760
Я получил очень хорошую прецедент
что мы будем говорить о том, что для.

1463
01:04:03,760 --> 01:04:05,940
>> Ладно, так что давайте говорить
о некоторых клиенты сейчас.

1464
01:04:05,940 --> 01:04:06,950
Эти ребята AdRoll.

1465
01:04:06,950 --> 01:04:08,990
Я не знаю, если вы
знакомы с AdRoll.

1466
01:04:08,990 --> 01:04:10,781
Вы, наверное, увидеть их
много в браузере.

1467
01:04:10,781 --> 01:04:14,230
Они объявлений перенацеливания, они
крупнейший объявления перенацеливания бизнес

1468
01:04:14,230 --> 01:04:14,940
там.

1469
01:04:14,940 --> 01:04:17,792
Они, как правило, регулярно запускать более
60 млрд транзакций в день.

1470
01:04:17,792 --> 01:04:20,000
Они делают более миллиона
транзакций в секунду.

1471
01:04:20,000 --> 01:04:22,660
Они получили довольно простую таблицу
структура, оживленных таблицы.

1472
01:04:22,660 --> 01:04:26,450
Это в основном только
хэш ключ куки,

1473
01:04:26,450 --> 01:04:29,010
диапазон демографическая
Категория, а затем

1474
01:04:29,010 --> 01:04:31,220
третий атрибут счет.

1475
01:04:31,220 --> 01:04:33,720
>> Таким образом, мы все должны куки в
наш браузер от этих парней.

1476
01:04:33,720 --> 01:04:35,900
И когда вы идете к
участие купец,

1477
01:04:35,900 --> 01:04:39,390
они в основном оценка вас через
различные демографические категории.

1478
01:04:39,390 --> 01:04:42,070
Когда вы идете на сайт и
вы говорите, я хочу, чтобы этот ad--

1479
01:04:42,070 --> 01:04:44,920
или в основном не говорят that--
но когда вы идете на сайт

1480
01:04:44,920 --> 01:04:47,550
они говорят, что вы хотите увидеть это объявление.

1481
01:04:47,550 --> 01:04:49,370
И они идут получить, что объявление от AdRoll.

1482
01:04:49,370 --> 01:04:51,130
AdRoll выглядит вас на столе.

1483
01:04:51,130 --> 01:04:52,115
Они находят свой печенье.

1484
01:04:52,115 --> 01:04:53,990
Рекламодатели, рассказывающие
им, я хочу кого-то

1485
01:04:53,990 --> 01:04:58,632
кто среднего возраста,
40-летний мужчина, в спорте.

1486
01:04:58,632 --> 01:05:01,590
И они выигрывают вас в этих демографических
и они решают ли или нет

1487
01:05:01,590 --> 01:05:02,740
что это хорошая реклама для вас.

1488
01:05:02,740 --> 01:05:10,330
>> Теперь у них есть SLA с
их рекламные провайдеры

1489
01:05:10,330 --> 01:05:14,510
чтобы обеспечить суб-10 миллисекунду
Ответ на каждый запрос.

1490
01:05:14,510 --> 01:05:16,090
Так они используют Динамо DB для этого.

1491
01:05:16,090 --> 01:05:18,131
Они удара нам
миллион запросов в секунду.

1492
01:05:18,131 --> 01:05:21,120
Они в состоянии сделать все их
поиски, сортировка всего, что данные,

1493
01:05:21,120 --> 01:05:26,130
и получить, что добавить ссылку на что
рекламодателя в возрасте до 10 миллисекунд.

1494
01:05:26,130 --> 01:05:29,800
Это действительно довольно феноменальный
Реализация, что они имеют.

1495
01:05:29,800 --> 01:05:36,210
>> Эти ребята actually--
Являются ли эти ребята.

1496
01:05:36,210 --> 01:05:38,010
Я не уверен, если это эти ребята.

1497
01:05:38,010 --> 01:05:40,127
Может быть эти ребята.

1498
01:05:40,127 --> 01:05:42,210
В основном сказал us-- нет, я
Не думаю, что это было их.

1499
01:05:42,210 --> 01:05:43,000
Я думаю, что это был кто-то еще.

1500
01:05:43,000 --> 01:05:44,750
Я работал с
клиент, который сказал мне,

1501
01:05:44,750 --> 01:05:47,040
что теперь, когда они
пошел Динамо БД, они

1502
01:05:47,040 --> 01:05:50,330
тратить больше денег на закусках для
их команда разработчиков каждый месяц

1503
01:05:50,330 --> 01:05:52,886
чем они тратят на их базе данных.

1504
01:05:52,886 --> 01:05:54,760
Так это даст вам
Идея экономии

1505
01:05:54,760 --> 01:05:57,889
что вы можете получить в Динамо БД огромен.

1506
01:05:57,889 --> 01:05:59,430
Ладно, dropcam другой компании.

1507
01:05:59,430 --> 01:06:02,138
Эти парень вроде of-- если вы думаете,
интернет вещей, dropcam

1508
01:06:02,138 --> 01:06:05,150
в основном интернет-видео безопасности.

1509
01:06:05,150 --> 01:06:06,660
Вы ставите камеру там.

1510
01:06:06,660 --> 01:06:08,180
Камера имеет детектор движения.

1511
01:06:08,180 --> 01:06:10,290
Кто-то приходит,
запускает ключевую точку.

1512
01:06:10,290 --> 01:06:13,540
Камера начинает запись на некоторое время до
он не обнаруживает никакого движения больше.

1513
01:06:13,540 --> 01:06:15,310
Кладет это видео на Интернете.

1514
01:06:15,310 --> 01:06:19,800
>> Dropcam была компания, которая
в основном перешли на Динамо БД

1515
01:06:19,800 --> 01:06:22,200
потому что они испытывают
Огромные растущие боли.

1516
01:06:22,200 --> 01:06:25,820
И то, что они сказали нам
вдруг петабайт данных.

1517
01:06:25,820 --> 01:06:28,070
Они понятия не имели, их обслуживание
будет настолько успешным.

1518
01:06:28,070 --> 01:06:32,310
Более входящих видео YouTube, чем
это то, что эти ребята получают.

1519
01:06:32,310 --> 01:06:36,780
Они используют DynamoDB отслеживать все
метаданные всех своих видео ключевых моментов.

1520
01:06:36,780 --> 01:06:40,282
>> Таким образом, они имеют S3 ведра они толкают
все бинарные артефакты в.

1521
01:06:40,282 --> 01:06:41,990
И тогда они имеют
Динамо DB записи,

1522
01:06:41,990 --> 01:06:44,070
указать людям на этих трех объектов S3.

1523
01:06:44,070 --> 01:06:47,070
Когда они должны смотреть на видео,
они смотрят запись в Динамо БД.

1524
01:06:47,070 --> 01:06:47,903
Они нажмите на ссылку.

1525
01:06:47,903 --> 01:06:49,770
Они тянут вниз видео с S3.

1526
01:06:49,770 --> 01:06:51,590
Так что вроде как это выглядит.

1527
01:06:51,590 --> 01:06:53,580
И это прямо из своей команды.

1528
01:06:53,580 --> 01:06:56,010
>> Динамо БД уменьшает их
время доставки для видео событий

1529
01:06:56,010 --> 01:06:57,590
от пяти до 10 секунд.

1530
01:06:57,590 --> 01:07:00,470
В своей старой реляционной магазине,
они использовали, чтобы иметь, чтобы пойти и выполнить

1531
01:07:00,470 --> 01:07:03,780
несколько сложных запросов к фигуре
из которых видео, чтобы тянуть вниз,

1532
01:07:03,780 --> 01:07:06,690
до менее чем за 50 миллисекунд.

1533
01:07:06,690 --> 01:07:08,990
Так что это удивительно, удивительно
сколько эффективность

1534
01:07:08,990 --> 01:07:12,990
Вы можете получить, когда вы оптимизировать и
Вы настраиваете основной базе данных

1535
01:07:12,990 --> 01:07:15,110
поддержать доступа к файлу.

1536
01:07:15,110 --> 01:07:20,500
Halfbrick, эти ребята, что это,
Fruit Ninja Я думаю, это их дело.

1537
01:07:20,500 --> 01:07:22,590
Это все работает на Динамо БД.

1538
01:07:22,590 --> 01:07:26,810
И эти ребята, они являются отличным
Команда разработчиков, большое развитие

1539
01:07:26,810 --> 01:07:27,670
магазин.

1540
01:07:27,670 --> 01:07:29,364
>> Не хороший ОПС команда.

1541
01:07:29,364 --> 01:07:31,280
Они не имеют много
эксплуатационных ресурсов.

1542
01:07:31,280 --> 01:07:33,940
Они боролись, пытаясь сохранить
их инфраструктура приложений до

1543
01:07:33,940 --> 01:07:34,290
и работает.

1544
01:07:34,290 --> 01:07:35,000
Они пришли к нам.

1545
01:07:35,000 --> 01:07:36,251
Они смотрели на то Динамо БД.

1546
01:07:36,251 --> 01:07:37,291
Они сказали, что это для нас.

1547
01:07:37,291 --> 01:07:39,470
Они построили всю свою
Структура приложения на нем.

1548
01:07:39,470 --> 01:07:43,640
Некоторые действительно хорошие комментарии здесь
от команды на их способности

1549
01:07:43,640 --> 01:07:46,800
чтобы теперь сосредоточиться на строительство
игра, а не

1550
01:07:46,800 --> 01:07:49,010
того, чтобы поддерживать
инфраструктура, которая

1551
01:07:49,010 --> 01:07:51,910
становится огромное количество
накладных расходов для своей команды.

1552
01:07:51,910 --> 01:07:56,170
Так что это что-то that--
преимущество, что вы получите от Динамо БД.

1553
01:07:56,170 --> 01:08:00,930
>> Ладно, попадая в
моделирование данных здесь.

1554
01:08:00,930 --> 01:08:03,440
И мы говорили немного о
это один к одному, один ко многим,

1555
01:08:03,440 --> 01:08:05,060
и многие ко многим отношений типа.

1556
01:08:05,060 --> 01:08:07,630
А как вы поддерживаете тех, кто в Динамо.

1557
01:08:07,630 --> 01:08:10,500
В Динамо БД мы используем
Индексы, вообще говоря,

1558
01:08:10,500 --> 01:08:12,910
вращать данные
один вкус к другому.

1559
01:08:12,910 --> 01:08:15,210
Хэш-ключи, ключи диапазон, и индексы.

1560
01:08:15,210 --> 01:08:18,540
>> В данном конкретном
Например, как и большинство государств

1561
01:08:18,540 --> 01:08:23,802
есть требование лицензирования,
только лицензия одного водителя на человека.

1562
01:08:23,802 --> 01:08:26,510
Вы не можете пойти, чтобы получить двух водителя
лицензии в штате Бостон.

1563
01:08:26,510 --> 01:08:27,500
Я не могу сделать это в Техасе.

1564
01:08:27,500 --> 01:08:28,708
Это вроде того, как это.

1565
01:08:28,708 --> 01:08:32,779
И так в DMV, у нас есть операций поиска, мы
хочу посмотреть водительское удостоверение

1566
01:08:32,779 --> 01:08:35,180
по количеству социального обеспечения.

1567
01:08:35,180 --> 01:08:39,990
Я хочу, чтобы посмотреть информацию о пользователе
по количеству лицензий водителя.

1568
01:08:39,990 --> 01:08:43,620
>> Таким образом, мы, возможно, таблицу пользователя, что
имеет хэш-ключ на серийный номер,

1569
01:08:43,620 --> 01:08:47,830
или номер социального страхования, и
различные атрибуты определяются по этому пункту.

1570
01:08:47,830 --> 01:08:49,859
В настоящее время на этой таблице I
может определить, что GSI

1571
01:08:49,859 --> 01:08:53,370
переворачивает, что вокруг, что я хочу, говорит,
ключевой хэш по лицензии, а затем

1572
01:08:53,370 --> 01:08:54,252
все другие предметы.

1573
01:08:54,252 --> 01:08:57,210
Теперь, если я хочу, чтобы запрашивать и найти
Номер лицензии для любой социальной

1574
01:08:57,210 --> 01:08:59,609
Номер безопасности, я могу
запрос основную таблицу.

1575
01:08:59,609 --> 01:09:02,130
>> Если я хочу, чтобы запросить и я хочу
чтобы получить социальное обеспечение

1576
01:09:02,130 --> 01:09:05,735
номер или другие атрибуты с помощью
номер лицензии, я могу запросить GSI.

1577
01:09:05,735 --> 01:09:08,689
Эта модель, что один
к одному отношения.

1578
01:09:08,689 --> 01:09:12,460
Просто очень простой GSI,
флип эти вещи.

1579
01:09:12,460 --> 01:09:13,979
Теперь, поговорим об одной для многих.

1580
01:09:13,979 --> 01:09:16,450
Один ко многим в основном
Ваш ключ Диапазон хэш.

1581
01:09:16,450 --> 01:09:20,510
Где мы получаем много с этим
Использование случай данные монитора.

1582
01:09:20,510 --> 01:09:23,880
Данные мониторинга регулярно поставляется в
Интервал, как Интернет вещей.

1583
01:09:23,880 --> 01:09:26,890
Мы всегда получаем все это
записи в ближайшие все время.

1584
01:09:26,890 --> 01:09:31,420
>> И я хочу, чтобы найти все показания
между определенный период времени.

1585
01:09:31,420 --> 01:09:34,220
Это очень распространенная в запрос
Мониторинг инфраструктуры.

1586
01:09:34,220 --> 01:09:38,430
Путь идти о том, что это, чтобы найти
простая структура таблицы, одна таблица.

1587
01:09:38,430 --> 01:09:42,250
Я получил таблицу измерений прибора
с ключом хэш на устройство ID.

1588
01:09:42,250 --> 01:09:47,340
И у меня есть ключ диапазона на
метка, или в данном случае, эпос.

1589
01:09:47,340 --> 01:09:50,350
И, что позволяет мне выполнить комплекс
запросы к этому ключу диапазоне

1590
01:09:50,350 --> 01:09:54,950
и вернуться те записи, которые
по сравнению с результатом

1591
01:09:54,950 --> 01:09:56,310
Установлено, что я ищу.

1592
01:09:56,310 --> 01:09:58,360
И он строит, что одна
для многих отношениях

1593
01:09:58,360 --> 01:10:02,340
в основной таблице, используя
хэш ключа, диапазон ключевой структурой.

1594
01:10:02,340 --> 01:10:04,600
>> Так что это своего рода встроенный
в таблице в БД Динамо.

1595
01:10:04,600 --> 01:10:07,290
Когда я определить хэш
и диапазон т стол, я

1596
01:10:07,290 --> 01:10:09,240
определения один ко многим отношений.

1597
01:10:09,240 --> 01:10:12,770
Это отношения родитель-ребенок.

1598
01:10:12,770 --> 01:10:14,620
>> Давайте поговорим о многих
многих отношениях.

1599
01:10:14,620 --> 01:10:19,170
И для этого конкретного примера,
опять же, мы собираемся использовать GSI-х.

1600
01:10:19,170 --> 01:10:23,500
И давайте говорить об играх
сценарий, где у меня есть данный пользователь.

1601
01:10:23,500 --> 01:10:26,500
Я хочу, чтобы найти все игры, которые
он зарегистрирован или играя в.

1602
01:10:26,500 --> 01:10:29,600
А для данной игры, я
хочу найти всех пользователей.

1603
01:10:29,600 --> 01:10:31,010
Так как я делаю это?

1604
01:10:31,010 --> 01:10:34,330
Мой пользователей игры стол, я собираюсь
иметь хэш-ключ ID пользователя

1605
01:10:34,330 --> 01:10:35,810
и ключ диапазон игре.

1606
01:10:35,810 --> 01:10:37,810
>> Таким образом, пользователь может иметь несколько игр.

1607
01:10:37,810 --> 01:10:41,380
Это один ко многим отношений между
пользователь и игры он играет.

1608
01:10:41,380 --> 01:10:43,410
А потом на GSI,
Я флип что вокруг.

1609
01:10:43,410 --> 01:10:46,679
Я хэш на игре и
Я диапазоне от пользователя.

1610
01:10:46,679 --> 01:10:48,970
Так что, если я хочу, чтобы все
Игра пользователь играет в,

1611
01:10:48,970 --> 01:10:49,950
Я запрашивать основную таблицу.

1612
01:10:49,950 --> 01:10:52,699
Если я хочу, чтобы получить все пользователи
которые играют определенную игру,

1613
01:10:52,699 --> 01:10:53,887
Я запросить GSI.

1614
01:10:53,887 --> 01:10:54,970
Итак, вы видите, как мы это делаем?

1615
01:10:54,970 --> 01:10:58,369
Вы строите для поддержки этих GSI годов
Прецедент, приложение, доступ

1616
01:10:58,369 --> 01:10:59,410
узор, приложение.

1617
01:10:59,410 --> 01:11:01,440
>> Если мне нужно запросить на
это измерение, пусть

1618
01:11:01,440 --> 01:11:03,500
мне создать индекс по этому измерению.

1619
01:11:03,500 --> 01:11:05,850
Если я не делаю, я не волнует.

1620
01:11:05,850 --> 01:11:09,060
И в зависимости от случая использования, я
возможно, потребуется индекс или я не мог.

1621
01:11:09,060 --> 01:11:12,390
Если это просто один ко многим,
основной таблице в порядке.

1622
01:11:12,390 --> 01:11:15,860
Если мне нужно сделать это много, чтобы
многие, либо мне нужно сделать один для тех,

1623
01:11:15,860 --> 01:11:18,390
то, возможно, мне нужно
на второе индекс.

1624
01:11:18,390 --> 01:11:20,840
Так что все зависит от
то, что я пытаюсь сделать

1625
01:11:20,840 --> 01:11:24,550
и то, что я пытаюсь получить опытный.

1626
01:11:24,550 --> 01:11:28,000
>> Вероятно, я не буду тратить слишком
много времени говорить о документах.

1627
01:11:28,000 --> 01:11:31,460
Это становится немного, наверное,
глубже, чем мы должны идти в.

1628
01:11:31,460 --> 01:11:33,710
Давайте немного поговорим
о богатых выражение запроса.

1629
01:11:33,710 --> 01:11:37,831
Таким образом, в Динамо БД у нас есть
способность создавать

1630
01:11:37,831 --> 01:11:39,330
что мы называем проекционные выражения.

1631
01:11:39,330 --> 01:11:42,660
Проекционные выражения просто
выбирая поля или значения

1632
01:11:42,660 --> 01:11:44,290
что вы хотите, чтобы отобразить.

1633
01:11:44,290 --> 01:11:46,000
ОК, так что я могу сделать выбор.

1634
01:11:46,000 --> 01:11:48,010
Я делаю запрос к БД Динамо.

1635
01:11:48,010 --> 01:11:51,730
И я говорю, вы знаете, что, показать
меня только пять отзывы звезды

1636
01:11:51,730 --> 01:11:54,544
для этого конкретного продукта.

1637
01:11:54,544 --> 01:11:55,710
Так что все, что я хочу видеть.

1638
01:11:55,710 --> 01:11:57,320
Я не хочу, чтобы увидеть все
другие атрибуты строки,

1639
01:11:57,320 --> 01:11:58,319
Я просто хочу, чтобы это увидеть.

1640
01:11:58,319 --> 01:12:01,209
Это просто, как и в SQL, когда вы
говорят выберите звезду или из таблицы,

1641
01:12:01,209 --> 01:12:02,000
Вы получаете все.

1642
01:12:02,000 --> 01:12:05,450
Когда я говорю, выберите имя из
стол, я только один атрибут.

1643
01:12:05,450 --> 01:12:09,070
Это то же самое рода вещи в
Динамо БД или еще базы данных NoSQL.

1644
01:12:09,070 --> 01:12:14,510
Фильтровать выражения позволяют мне
в основном сократить набор результатов вниз.

1645
01:12:14,510 --> 01:12:15,540
Так что я сделать запрос.

1646
01:12:15,540 --> 01:12:17,260
Запрос может вернуться с 500 пунктов.

1647
01:12:17,260 --> 01:12:20,255
Но я хочу только те элементы, которые
есть атрибут, который говорит, что это.

1648
01:12:20,255 --> 01:12:23,380
Итак, давайте отфильтровать эти элементы
которые не соответствуют этой конкретной запрос.

1649
01:12:23,380 --> 01:12:25,540
Итак, мы имеем выражения фильтра.

1650
01:12:25,540 --> 01:12:28,310
>> Фильтровать выражения могут
будет работать на любой атрибут.

1651
01:12:28,310 --> 01:12:30,260
Они не хотели интервальные запросы.

1652
01:12:30,260 --> 01:12:32,690
Повышение запросы более избирательным.

1653
01:12:32,690 --> 01:12:36,470
Фильтровать запросы требуют от меня, чтобы пойти
получить весь набор результатов, а затем

1654
01:12:36,470 --> 01:12:39,170
вырезать данные, которые я не хочу.

1655
01:12:39,170 --> 01:12:40,660
Почему это так важно?

1656
01:12:40,660 --> 01:12:42,770
Потому что я читал все это.

1657
01:12:42,770 --> 01:12:46,597
В запросе, я буду читать и
это будет гигантский о данных.

1658
01:12:46,597 --> 01:12:48,430
А потом я собираюсь
вырезать то, что мне нужно.

1659
01:12:48,430 --> 01:12:52,080
И если я только вырезая
пара строк, то это нормально.

1660
01:12:52,080 --> 01:12:53,620
Это не так неэффективно.

1661
01:12:53,620 --> 01:12:57,800
>> Но если я читаю целую кипу
Данные, просто вырезать один элемент,

1662
01:12:57,800 --> 01:13:01,490
затем я собираюсь быть лучше
от использования диапазона запроса,

1663
01:13:01,490 --> 01:13:03,030
потому что это гораздо более избирательно.

1664
01:13:03,030 --> 01:13:06,330
Это спасет меня много
деньги, потому что я платить за это чтение.

1665
01:13:06,330 --> 01:13:10,430
Если результаты, который возвращается
пересечь эту проволоку может быть меньше,

1666
01:13:10,430 --> 01:13:11,890
но я плачу за чтение.

1667
01:13:11,890 --> 01:13:14,340
Так понимаю, как
Вы получаете данные.

1668
01:13:14,340 --> 01:13:16,420
Это очень важно в Динамо БД.

1669
01:13:16,420 --> 01:13:19,710
>> Условные выражения, это то, что
Вы могли бы назвать оптимистической блокировки.

1670
01:13:19,710 --> 01:13:28,470
Обновить, если есть, или, если это значение
эквивалентно тому, что я указываю.

1671
01:13:28,470 --> 01:13:31,494
И если у меня есть штамп времени на
запись, я мог бы прочитать данные.

1672
01:13:31,494 --> 01:13:32,535
Я мог бы изменить эти данные.

1673
01:13:32,535 --> 01:13:35,030
Я мог бы пойти пишут, что
назад данные в базу данных.

1674
01:13:35,030 --> 01:13:38,100
Если кто-то изменил запись,
отметка времени может быть изменен.

1675
01:13:38,100 --> 01:13:40,370
И таким образом мой условно
обновление можно сказать, обновление

1676
01:13:40,370 --> 01:13:42,340
если отметка равна этого.

1677
01:13:42,340 --> 01:13:46,290
Или обновление не будет выполнено, потому что кто-то
обновил рекорд в то же время.

1678
01:13:46,290 --> 01:13:48,290
>> Это то, что мы называем оптимистическое блокирование.

1679
01:13:48,290 --> 01:13:50,670
Это означает, что кто-то
может прийти и изменить его,

1680
01:13:50,670 --> 01:13:53,100
и я собираюсь обнаружить его
когда я вернусь, чтобы написать.

1681
01:13:53,100 --> 01:13:56,106
И тогда я могу на самом деле читать, что
данных и говорят, ой, он изменил это.

1682
01:13:56,106 --> 01:13:57,230
Мне нужно, чтобы учесть это.

1683
01:13:57,230 --> 01:14:00,490
И я могу изменить данные в моей
записывать и применять еще одно обновление.

1684
01:14:00,490 --> 01:14:04,330
Таким образом, вы можете поймать тех, дополнительных
Обновления, которые происходят между временем

1685
01:14:04,330 --> 01:14:08,740
что вы читаете данные и
раз, когда вы могли бы написать данные.

1686
01:14:08,740 --> 01:14:11,520
>> АУДИТОРИЯ: И фильтр
Выражение на самом деле означает не

1687
01:14:11,520 --> 01:14:13,020
номер или не--

1688
01:14:13,020 --> 01:14:14,316
>> [Реле ГОЛОСА]

1689
01:14:14,316 --> 01:14:16,232
РИК Хулихэном: Я не буду
получить слишком много в этом.

1690
01:14:16,232 --> 01:14:17,700
Это зарезервированное слово.

1691
01:14:17,700 --> 01:14:20,130
Вид фунт сдержанный
Ключевое слово в Динамо БД.

1692
01:14:20,130 --> 01:14:24,500
Каждая база данных имеет свой собственный защищены
Имена для коллекций вы не можете использовать.

1693
01:14:24,500 --> 01:14:27,240
Динамо БД, если вы укажете
фунт перед этим,

1694
01:14:27,240 --> 01:14:29,310
Вы можете определить эти имена наверху.

1695
01:14:29,310 --> 01:14:31,840
Это эталонное значение.

1696
01:14:31,840 --> 01:14:34,880
Это, вероятно, не самый лучший синтаксис
есть там для этой дискуссии,

1697
01:14:34,880 --> 01:14:38,090
потому что он попадает в некоторых real--
Я был бы говорить больше

1698
01:14:38,090 --> 01:14:41,360
о том, что на более глубоком уровне.

1699
01:14:41,360 --> 01:14:46,130
>> Но достаточно сказать, что это могло бы
быть запрос сканирования, где они views--

1700
01:14:46,130 --> 01:14:50,190
ни просмотров фунт больше, чем 10.

1701
01:14:50,190 --> 01:14:54,660
Это числовое значение, да.

1702
01:14:54,660 --> 01:14:57,322
Если вы хотите, мы можем говорить о
что после обсуждения.

1703
01:14:57,322 --> 01:15:00,030
Ладно, так что мы входим в
некоторые сценарии в лучших практик

1704
01:15:00,030 --> 01:15:02,000
где мы будем говорить
о некоторых программах здесь.

1705
01:15:02,000 --> 01:15:03,810
Каковы варианты использования для Динамо БД.

1706
01:15:03,810 --> 01:15:06,120
Каковы дизайн
узоры в Динамо БД.

1707
01:15:06,120 --> 01:15:09,110
>> И первый, кого мы собираемся
разговоры о является Интернет вещей.

1708
01:15:09,110 --> 01:15:15,010
Таким образом, мы получаем много of-- Я думаю,
то, что it-- более 50%

1709
01:15:15,010 --> 01:15:19,370
трафика в интернете в эти дни
фактически генерируется машинами,

1710
01:15:19,370 --> 01:15:21,930
автоматизированные процессы, а не людей.

1711
01:15:21,930 --> 01:15:25,140
Я имею в виду эту вещь эта вещь, что
Вы носить в кармане,

1712
01:15:25,140 --> 01:15:28,840
сколько данных, что эта вещь
на самом деле отправки вокруг без тебя

1713
01:15:28,840 --> 01:15:30,550
зная, что это совершенно удивительное.

1714
01:15:30,550 --> 01:15:34,970
Ваше местоположение, информация
о том, как быстро вы идете.

1715
01:15:34,970 --> 01:15:38,400
Как вы думаете, Google Maps работы
когда они говорят вам, что трафик.

1716
01:15:38,400 --> 01:15:41,275
Это потому, что есть миллионы и
миллионы людей по всему вождения

1717
01:15:41,275 --> 01:15:44,667
с телефонами, которые посылают
Данные по всему месте все время.

1718
01:15:44,667 --> 01:15:46,500
Так одна из вещей,
об этом типе данных

1719
01:15:46,500 --> 01:15:50,980
что приходит в данные монитора, войти
Данные, данных временных рядов, является его

1720
01:15:50,980 --> 01:15:53,540
как правило, только интересно
для немного времени.

1721
01:15:53,540 --> 01:15:55,580
После этого времени, это
не так интересно.

1722
01:15:55,580 --> 01:15:58,390
Таким образом, мы говорили, не дай
эти таблицы растут без границ.

1723
01:15:58,390 --> 01:16:03,410
Идея здесь в том, что, может быть, я получил 24
часов стоимостью событий в моей горячей таблице.

1724
01:16:03,410 --> 01:16:06,160
И, что горячий стол будет
подготовлено на очень высокой скорости,

1725
01:16:06,160 --> 01:16:07,950
потому что он принимает много данных.

1726
01:16:07,950 --> 01:16:10,920
Это занимает много данных
, и я читаю его много.

1727
01:16:10,920 --> 01:16:14,560
Я получил много работы
запросы работает против этого данных.

1728
01:16:14,560 --> 01:16:18,120
>> После 24 часов, эй, вы
знаете, я не волнует.

1729
01:16:18,120 --> 01:16:21,150
Так, может быть, каждый полночь я ролл
мой стол к новой таблице

1730
01:16:21,150 --> 01:16:22,430
и я высвобождения неиспользуемых эту таблицу.

1731
01:16:22,430 --> 01:16:26,440
И я возьму РКО-х и
Вниз WCU, потому что через 24 часа

1732
01:16:26,440 --> 01:16:28,630
Я не работает, как многие
запросы к этим данным.

1733
01:16:28,630 --> 01:16:30,200
Так что я иду, чтобы спасти деньги.

1734
01:16:30,200 --> 01:16:32,940
И, может быть, через 30 дней я не
даже нужно заботиться о нем все.

1735
01:16:32,940 --> 01:16:35,020
Я мог бы взять ВКУ-х
все, вплоть до одного,

1736
01:16:35,020 --> 01:16:36,990
потому что вы знаете, что, это
никогда не собираетесь получить запись.

1737
01:16:36,990 --> 01:16:38,300
Данные 30 дней.

1738
01:16:38,300 --> 01:16:40,000
Это никогда не меняется.

1739
01:16:40,000 --> 01:16:44,200
>> И это почти никогда не происходит, чтобы получить читать,
так что давайте просто считать, что RCU до 10.

1740
01:16:44,200 --> 01:16:49,372
И я экономлю кучу денег на это
данных и платить только за мои горячие данных.

1741
01:16:49,372 --> 01:16:52,330
Так что это важная вещь, чтобы искать
на то, когда вы смотрите на временных рядов

1742
01:16:52,330 --> 01:16:54,716
данные, поступающие в в объеме.

1743
01:16:54,716 --> 01:16:55,590
Эти стратегии.

1744
01:16:55,590 --> 01:16:58,010
Теперь, я мог позволить его
все идут в той же таблице

1745
01:16:58,010 --> 01:16:59,461
и пусть эта таблица расти.

1746
01:16:59,461 --> 01:17:01,460
В конце концов, я собираюсь
см проблемы с производительностью.

1747
01:17:01,460 --> 01:17:04,060
Я собираюсь иметь, чтобы начать архивирование
некоторые из этих данных со стола,

1748
01:17:04,060 --> 01:17:04,720
что нет.

1749
01:17:04,720 --> 01:17:07,010
>> Давайте лучше
разрабатывать приложение

1750
01:17:07,010 --> 01:17:08,900
так что вы можете работать так хорошо.

1751
01:17:08,900 --> 01:17:11,460
Так что это просто автомат
в коде приложения.

1752
01:17:11,460 --> 01:17:13,580
В полночь каждую ночь
она катится по столу.

1753
01:17:13,580 --> 01:17:17,170
Может быть, то, что мне нужно, это скольжение
Окно 24 часов данных.

1754
01:17:17,170 --> 01:17:20,277
Тогда на регулярной основе я
Вызов данных со стола.

1755
01:17:20,277 --> 01:17:22,360
Я обрезки его с
Крон работа, и я ставлю его

1756
01:17:22,360 --> 01:17:24,160
на этих других таблиц,
все что тебе нужно.

1757
01:17:24,160 --> 01:17:25,940
Так что, если опрокидывание работает, это здорово.

1758
01:17:25,940 --> 01:17:27,080
Если нет, обрежьте ее.

1759
01:17:27,080 --> 01:17:29,640
Но давайте держать, что горячий данные
от ваших холодных данных.

1760
01:17:29,640 --> 01:17:32,535
Это сэкономит вам много денег, и
сделать ваши таблицы более совершенных.

1761
01:17:32,535 --> 01:17:35,960

1762
01:17:35,960 --> 01:17:38,210
Таким образом, следующая вещь, мы поговорим
о том, каталог продукции.

1763
01:17:38,210 --> 01:17:42,000
Каталог товаров вне
довольно часто кейс.

1764
01:17:42,000 --> 01:17:46,600
Это на самом деле очень общий шаблон
что мы увидим в различных вещей.

1765
01:17:46,600 --> 01:17:48,870
Вы знаете, Twitter для
Например, горячая твит.

1766
01:17:48,870 --> 01:17:51,280
Все идет и
хватая что в твиттере.

1767
01:17:51,280 --> 01:17:52,680
Каталог товаров, я получил продаже.

1768
01:17:52,680 --> 01:17:54,120
Я получил горячую продажу.

1769
01:17:54,120 --> 01:17:57,277
Я получил 70000 запросов в
второе пришествие для продукта

1770
01:17:57,277 --> 01:17:58,860
Описание из моего каталога.

1771
01:17:58,860 --> 01:18:02,384
Мы видим это на розницу
операция совсем немного.

1772
01:18:02,384 --> 01:18:03,550
Так как мы имеем дело с этим?

1773
01:18:03,550 --> 01:18:04,924
Там нет никакого способа, чтобы справиться с этим.

1774
01:18:04,924 --> 01:18:07,110
Все мои пользователи хотят, чтобы увидеть
та же часть данных.

1775
01:18:07,110 --> 01:18:09,410
Они приходят в, одновременно.

1776
01:18:09,410 --> 01:18:11,920
И все они делать запросы
по той же части данных.

1777
01:18:11,920 --> 01:18:16,240
Это дает мне, что горячая клавиша, что большая красная
полоса на моей карте, что нам не нравится.

1778
01:18:16,240 --> 01:18:17,720
И это, как это выглядит.

1779
01:18:17,720 --> 01:18:22,290
Так по моему ключевого пространства я получаю
забил пунктов продажи.

1780
01:18:22,290 --> 01:18:24,070
Я не получаю ничего нигде.

1781
01:18:24,070 --> 01:18:26,050
>> Как решить эту проблему?

1782
01:18:26,050 --> 01:18:28,410
Ну, мы это с облегчить кэша.

1783
01:18:28,410 --> 01:18:33,630
Кэш, вы положили в основном в оперативной памяти
раздел перед базе данных.

1784
01:18:33,630 --> 01:18:37,260
Нам удалось
[Неразборчиво] кэша, как вам

1785
01:18:37,260 --> 01:18:40,260
может создать свой собственный кэш, [неразборчиво]
Кэш [? д,?], что вы хотите.

1786
01:18:40,260 --> 01:18:42,220
Положим, что в передней части базы данных.

1787
01:18:42,220 --> 01:18:47,250
И таким образом вы можете хранить эти данные
от тех горячих клавиш в этой кэш-памяти

1788
01:18:47,250 --> 01:18:49,390
пространство и читать через кэш.

1789
01:18:49,390 --> 01:18:51,962
>> И тогда большинство ваших читает
начать поиск, как это.

1790
01:18:51,962 --> 01:18:54,920
Я получил все это кэш-парад здесь
и я ничего не получил здесь происходит

1791
01:18:54,920 --> 01:18:59,330
потому что база данных сидя позади
кэш и не читает и не прийти до конца.

1792
01:18:59,330 --> 01:19:02,520
Если я изменить данные в
базы данных, у меня есть для обновления кэша.

1793
01:19:02,520 --> 01:19:04,360
Мы можем использовать что-то
как пары сделать это.

1794
01:19:04,360 --> 01:19:07,360
И я объясню, как это работает.

1795
01:19:07,360 --> 01:19:09,060
Ладно, сообщениями.

1796
01:19:09,060 --> 01:19:11,180
E-mail, мы все используем электронную почту.

1797
01:19:11,180 --> 01:19:12,540
>> Это очень хороший пример.

1798
01:19:12,540 --> 01:19:14,950
У нас есть какой-то сообщений стола.

1799
01:19:14,950 --> 01:19:17,040
И мы получили почтовый ящик и исходящие.

1800
01:19:17,040 --> 01:19:19,760
Это то, что SQL будет
Посмотрите, как строить, что почтовый ящик.

1801
01:19:19,760 --> 01:19:23,350
Мы вроде использовать тот же самый вид
стратегии для использования GSI-х, GSI-х

1802
01:19:23,350 --> 01:19:25,320
для моего почтового ящика и моей исходящие.

1803
01:19:25,320 --> 01:19:27,600
Так что я получил сообщения, поступающие сырье
в мои сообщения таблицы.

1804
01:19:27,600 --> 01:19:30,194
И первый подход к этому
может быть, не говорят, ОК, нет проблем.

1805
01:19:30,194 --> 01:19:31,110
Я получил исходные сообщения.

1806
01:19:31,110 --> 01:19:33,710
Сообщения, поступающие [неразборчиво],
идентификатор сообщения, это здорово.

1807
01:19:33,710 --> 01:19:35,070
Это мой единственный хэш.

1808
01:19:35,070 --> 01:19:38,280
Я собираюсь создать два GSI, одной
для моего почтового ящика, по одному для моего исходящие.

1809
01:19:38,280 --> 01:19:40,530
И первое, что я сделаю
, я скажу, мой ключ хэш

1810
01:19:40,530 --> 01:19:43,310
будет получатель и
Я собираюсь устроить на сегодняшний день.

1811
01:19:43,310 --> 01:19:44,220
Это фантастика.

1812
01:19:44,220 --> 01:19:45,890
Я получил хороший вид здесь.

1813
01:19:45,890 --> 01:19:47,780
Но есть небольшая проблема здесь.

1814
01:19:47,780 --> 01:19:50,891
И вы столкнетесь это
реляционные базы данных, а также.

1815
01:19:50,891 --> 01:19:52,390
Они называли вертикально разбиение.

1816
01:19:52,390 --> 01:19:55,840
Вы хотите, чтобы ваш большой данные
от ваших маленьких данных.

1817
01:19:55,840 --> 01:20:00,470
>> И причина, почему, потому что я должен
идти читать пункты, чтобы получить атрибуты.

1818
01:20:00,470 --> 01:20:05,570
И если мои органы все здесь,
затем чтение всего несколько пунктов

1819
01:20:05,570 --> 01:20:08,560
если мой Длина тела
в среднем 256 килобайт каждый,

1820
01:20:08,560 --> 01:20:10,991
математика становится довольно некрасиво.

1821
01:20:10,991 --> 01:20:12,490
Так что я хочу, чтобы прочитать входящие Давида.

1822
01:20:12,490 --> 01:20:14,520
Входящие Давида имеет 50 пунктов.

1823
01:20:14,520 --> 01:20:17,880
Средняя и размер 256 килобайт.

1824
01:20:17,880 --> 01:20:21,730
Вот мой коэффициент конверсии
для РКО является четыре килобайта.

1825
01:20:21,730 --> 01:20:24,450
>> ОК, давайте идти с
в конечном итоге, непротиворечивое чтение.

1826
01:20:24,450 --> 01:20:28,640
Я до сих пор есть 1600-х РКО
просто читать входящие Давида.

1827
01:20:28,640 --> 01:20:29,950
Ой.

1828
01:20:29,950 --> 01:20:31,980
Хорошо, теперь давайте подумаем
о том, как работает приложение.

1829
01:20:31,980 --> 01:20:35,340
Если я нахожусь в почтовом приложении и
Я смотрю на мой почтовый ящик,

1830
01:20:35,340 --> 01:20:39,680
и я смотрю на теле каждого сообщения,
нет, я смотрю на резюме.

1831
01:20:39,680 --> 01:20:41,850
Я смотрю на только заголовки.

1832
01:20:41,850 --> 01:20:46,310
Итак, давайте строить структуру таблицы
что больше похоже, что.

1833
01:20:46,310 --> 01:20:49,470
>> Так вот информация
что мой рабочий процесс потребностей.

1834
01:20:49,470 --> 01:20:50,890
Это в мой почтовый ящик GSI.

1835
01:20:50,890 --> 01:20:53,800
Это дата, отправитель,
предметом, а затем

1836
01:20:53,800 --> 01:20:56,790
идентификатор сообщения, который указывает
вернуться к таблице сообщений

1837
01:20:56,790 --> 01:20:57,850
где я могу получить тело.

1838
01:20:57,850 --> 01:21:01,260

1839
01:21:01,260 --> 01:21:04,420
Ну, это было бы записывать идентификаторы.

1840
01:21:04,420 --> 01:21:09,850
Они указывают назад к
идентификаторы пункт на столе Динамо DB.

1841
01:21:09,850 --> 01:21:12,220
Каждый индекс всегда creates--
всегда имеет элемент

1842
01:21:12,220 --> 01:21:15,750
ID, как часть of--, что
приходит с индексом.

1843
01:21:15,750 --> 01:21:17,414
>> Отлично.

1844
01:21:17,414 --> 01:21:19,080
АУДИТОРИЯ: Это говорит его там, где он хранится?

1845
01:21:19,080 --> 01:21:21,420
РИК Хулихэном: Да, он говорит
exactly--, что именно, что она делает.

1846
01:21:21,420 --> 01:21:22,644
Это говорит, вот мой повторно запись.

1847
01:21:22,644 --> 01:21:24,310
И это будет указывать его обратно в моей повторной записи.

1848
01:21:24,310 --> 01:21:26,460
В точку.

1849
01:21:26,460 --> 01:21:29,490
ОК, так что теперь мой почтовый ящик является
фактически намного меньше.

1850
01:21:29,490 --> 01:21:32,210
И это на самом деле поддерживает
рабочий процесс электронной приложение.

1851
01:21:32,210 --> 01:21:34,230
Так мой почтовый ящик, я нажимаю.

1852
01:21:34,230 --> 01:21:38,160
Я иду вдоль и я нажимаю на сообщения,
что, когда мне нужно пойти получить тело,

1853
01:21:38,160 --> 01:21:40,180
потому что я собираюсь
перейти на другую точку зрения.

1854
01:21:40,180 --> 01:21:43,870
Так что, если вы думаете, о типе MVC в
рамки, вид модели контроллера.

1855
01:21:43,870 --> 01:21:46,120
>> Модель содержит
Данные о том, что потребности вид

1856
01:21:46,120 --> 01:21:48,130
и контроллер взаимодействует с.

1857
01:21:48,130 --> 01:21:51,670
Когда я изменить рамку при
Изменить перспективу,

1858
01:21:51,670 --> 01:21:55,080
это нормально, чтобы вернуться к
Сервер и населить модель,

1859
01:21:55,080 --> 01:21:56,860
потому что это то, что ожидает пользователь.

1860
01:21:56,860 --> 01:22:00,530
Когда они изменить взгляды, что, когда
мы можем вернуться к базе данных.

1861
01:22:00,530 --> 01:22:02,480
Так электронной почты, нажмите.

1862
01:22:02,480 --> 01:22:03,710
Я ищу для тела.

1863
01:22:03,710 --> 01:22:04,330
В обе стороны.

1864
01:22:04,330 --> 01:22:05,680
Перейти получить тело.

1865
01:22:05,680 --> 01:22:06,950
>> Я читал много меньше данных.

1866
01:22:06,950 --> 01:22:09,960
Я только читал, что органы
Дэвид должен, когда он нуждается в них.

1867
01:22:09,960 --> 01:22:14,230
И я не горят в 1600 году
РКО просто, чтобы показать свою почтовый ящик.

1868
01:22:14,230 --> 01:22:17,670
Так что теперь that-- это путь
что LSI или GSI-- я извиняюсь,

1869
01:22:17,670 --> 01:22:19,900
GSI, будет работать.

1870
01:22:19,900 --> 01:22:25,450
Мы получили наш хэш на получателя.

1871
01:22:25,450 --> 01:22:27,030
Мы получили ключ диапазон на сегодняшний день.

1872
01:22:27,030 --> 01:22:31,380
И у нас есть прогнозируемые атрибуты
что нам нужны только для поддержки зрения.

1873
01:22:31,380 --> 01:22:34,300
>> Мы вращаем, что для почтового ящика.

1874
01:22:34,300 --> 01:22:35,770
Hash на отправителя.

1875
01:22:35,770 --> 01:22:39,612
А по существу, мы имеем
очень хороший, чистый вид.

1876
01:22:39,612 --> 01:22:41,570
И это мы basically--
есть хорошие сообщения в эту

1877
01:22:41,570 --> 01:22:45,870
Таблица, которая распространяется красиво, потому что
это хэш только хэш сообщение ID.

1878
01:22:45,870 --> 01:22:51,750
И у нас есть два индекса, что
вращаются с той таблице.

1879
01:22:51,750 --> 01:22:57,411
Ладно, так идея здесь заключается не
держать большие данные и этот небольшой данные

1880
01:22:57,411 --> 01:22:57,910
вместе.

1881
01:22:57,910 --> 01:23:00,700
Partition вертикально,
разделить эти таблицы.

1882
01:23:00,700 --> 01:23:03,150
Не читайте данные, которые вы не должны.

1883
01:23:03,150 --> 01:23:04,850
Ладно, игровой.

1884
01:23:04,850 --> 01:23:06,990
Мы все хотели игр.

1885
01:23:06,990 --> 01:23:10,902
По крайней мере, мне нравится игры, то.

1886
01:23:10,902 --> 01:23:12,735
Таким образом, некоторые из вещей,
что мы имеем дело с тем, когда

1887
01:23:12,735 --> 01:23:14,193
мы думаем об играх, не так ли?

1888
01:23:14,193 --> 01:23:16,999
Gaming эти дни, особенно с мобильного
игры, это все о мышлении.

1889
01:23:16,999 --> 01:23:19,540
И я собираюсь повернуть здесь
немного от DynamoDB.

1890
01:23:19,540 --> 01:23:21,373
Я собираюсь принести в
некоторые из обсуждения

1891
01:23:21,373 --> 01:23:24,240
вокруг некоторых из
другие технологии AWS.

1892
01:23:24,240 --> 01:23:28,930
>> Но идея об играх, чтобы думать
о в терминах интерфейсов API интерфейсы, которые,

1893
01:23:28,930 --> 01:23:31,730
вообще говоря, HTTP и JSON.

1894
01:23:31,730 --> 01:23:34,550
Это, как мобильные игры вид
взаимодействуют с их концами назад.

1895
01:23:34,550 --> 01:23:35,850
Они делают JSON регистрацию.

1896
01:23:35,850 --> 01:23:40,660
Они получают данные, и все это,
вообще говоря, в хороших интерфейсов JSON.

1897
01:23:40,660 --> 01:23:44,950
>> Такие вещи, как завести друзей, получить
данные лидеров, обмен,

1898
01:23:44,950 --> 01:23:47,699
контент, создаваемый пользователями,
отодвинуть к системе,

1899
01:23:47,699 --> 01:23:49,740
эти типы вещей
что мы собираемся делать.

1900
01:23:49,740 --> 01:23:52,542
Двоичные данные активов, эти данные
не может сидеть в базе данных.

1901
01:23:52,542 --> 01:23:54,250
Это может сидеть в
Объект магазин, правильно?

1902
01:23:54,250 --> 01:23:56,541
Но база данных будет
в конечном итоге говорю систему,

1903
01:23:56,541 --> 01:23:59,140
рассказывая приложение
куда идти получить его.

1904
01:23:59,140 --> 01:24:03,550
И неизбежно, мультиплеер
серверы, на конец инфраструктуры назад,

1905
01:24:03,550 --> 01:24:06,180
и предназначены для высокого
доступность и масштабируемость.

1906
01:24:06,180 --> 01:24:09,400
Таким образом, эти вещи, которые мы все хотим
в игровом инфраструктуры сегодня.

1907
01:24:09,400 --> 01:24:12,160
>> Итак, давайте взглянем на
как это выглядит.

1908
01:24:12,160 --> 01:24:16,070
Есть основной задний конец,
очень проста.

1909
01:24:16,070 --> 01:24:19,880
Мы получили систему здесь с
несколько зон доступности.

1910
01:24:19,880 --> 01:24:23,780
Мы говорили о АЗС в being-- думаю
из них в виде отдельных центров обработки данных.

1911
01:24:23,780 --> 01:24:26,040
Центр Более данные
за AZ, но это нормально,

1912
01:24:26,040 --> 01:24:28,831
просто думать о них как отдельные данные
центры, которые географически

1913
01:24:28,831 --> 01:24:30,090
и выделяют вина.

1914
01:24:30,090 --> 01:24:32,172
>> Мы собираемся, чтобы иметь
случаи пара EC2.

1915
01:24:32,172 --> 01:24:33,880
Мы собираемся, чтобы иметь
некоторые задней части сервера.

1916
01:24:33,880 --> 01:24:35,800
Может быть, если вы наследие
архитектура, мы

1917
01:24:35,800 --> 01:24:38,920
используя то, что мы называем RDS,
реляционные базы данных. услуги

1918
01:24:38,920 --> 01:24:42,040
Может быть MSSQL, MySQL,
или что-то типа того.

1919
01:24:42,040 --> 01:24:47,080
Это путь много приложений
предназначены сегодня.

1920
01:24:47,080 --> 01:24:49,594
>> Ну, мы могли бы пойти с
это когда мы масштабировать.

1921
01:24:49,594 --> 01:24:51,510
Мы пойдем вперед и положить
ведро там S3.

1922
01:24:51,510 --> 01:24:54,200
И, что S3 ведро, а не служить
до тех объектов, из нашего servers--

1923
01:24:54,200 --> 01:24:55,220
мы могли бы это сделать.

1924
01:24:55,220 --> 01:24:57,210
Вы ставите все ваши двоичный
объекты на ваших серверах

1925
01:24:57,210 --> 01:24:59,751
и вы можете использовать эти сервера
случаи, чтобы служить, что данные меры.

1926
01:24:59,751 --> 01:25:01,860
Но это довольно дорого.

1927
01:25:01,860 --> 01:25:05,107
>> Лучший способ сделать это пойти вперед и
положить эти предметы в S3 ведра.

1928
01:25:05,107 --> 01:25:06,315
S3 является репозитории объекта.

1929
01:25:06,315 --> 01:25:10,860
Он построен специально для
выступающей эти типы вещей.

1930
01:25:10,860 --> 01:25:13,690
И пусть те клиенты просят
непосредственно из этих объектов ведра,

1931
01:25:13,690 --> 01:25:15,390
разгрузить серверы.

1932
01:25:15,390 --> 01:25:17,020
Таким образом, мы начинаем масштабировать здесь.

1933
01:25:17,020 --> 01:25:19,140
>> Теперь мы получили пользователи по всему миру.

1934
01:25:19,140 --> 01:25:19,730
Я получил пользователи.

1935
01:25:19,730 --> 01:25:23,380
Мне нужно, чтобы содержимое локально
расположен недалеко от этих пользователей, правильно?

1936
01:25:23,380 --> 01:25:26,200
Я создал ведро S3
как мой репозитории.

1937
01:25:26,200 --> 01:25:29,370
И я фронт, который с
распределение CloudFront.

1938
01:25:29,370 --> 01:25:31,720
>> CloudFront является компакт-диск и
Содержание сеть доставки.

1939
01:25:31,720 --> 01:25:35,750
В основном это берет данные, которые вы указываете
и кэширует все это через Интернет

1940
01:25:35,750 --> 01:25:39,230
так что пользователи во всем мире могут иметь
очень быстрый ответ, когда

1941
01:25:39,230 --> 01:25:40,960
они просят эти объекты.

1942
01:25:40,960 --> 01:25:41,960
>> Таким образом, вы получите представление.

1943
01:25:41,960 --> 01:25:48,230
Вы вроде используя все
аспекты AWS здесь, чтобы получить это сделать.

1944
01:25:48,230 --> 01:25:50,790
И в конце концов, мы бросаем
в авто масштабирования группы.

1945
01:25:50,790 --> 01:25:52,737
Таким образом, наши случаях AC2
наших игровых серверов,

1946
01:25:52,737 --> 01:25:54,820
как они начинают получать занят
и более занятыми и более занятыми,

1947
01:25:54,820 --> 01:25:57,236
они просто вращаются другой
Экземпляр, спина еще один экземпляр,

1948
01:25:57,236 --> 01:25:58,210
спина еще один экземпляр.

1949
01:25:58,210 --> 01:26:02,090
Так технологии AWS имеет, это
позволяет задать параметры

1950
01:26:02,090 --> 01:26:04,650
вокруг которого серверы будут расти.

1951
01:26:04,650 --> 01:26:08,110
Таким образом, вы можете иметь н количество серверов
там в любой момент времени.

1952
01:26:08,110 --> 01:26:11,870
И если ваш груз уходит, они будут
сократится число будет сокращаться.

1953
01:26:11,870 --> 01:26:15,250
И если нагрузка возвращается,
это будет расти обратно, упруго.

1954
01:26:15,250 --> 01:26:17,050
>> Так что это выглядит здорово.

1955
01:26:17,050 --> 01:26:19,800
У нас есть много случаев EC2.

1956
01:26:19,800 --> 01:26:21,671
Мы можем кэша
Передняя баз данных,

1957
01:26:21,671 --> 01:26:23,045
попытаться ускорить базы данных.

1958
01:26:23,045 --> 01:26:25,030
Следующий пункт давление
как правило, люди видят

1959
01:26:25,030 --> 01:26:28,850
это они масштабировать игру с помощью
реляционная система базы данных.

1960
01:26:28,850 --> 01:26:30,790
Боже, база данных
производительность страшно.

1961
01:26:30,790 --> 01:26:31,932
Как мы можем улучшить, что?

1962
01:26:31,932 --> 01:26:33,640
Давайте попробуем положить
кэш перед этим.

1963
01:26:33,640 --> 01:26:36,780
>> Ну, кэш не работает
настолько велик, в играх, не так ли?

1964
01:26:36,780 --> 01:26:39,330
Для игр, написание является болезненным.

1965
01:26:39,330 --> 01:26:40,930
Игры очень тяжелый написать.

1966
01:26:40,930 --> 01:26:43,610
Кэш не работает, когда вы
написать тяжелых, потому что вы всегда

1967
01:26:43,610 --> 01:26:44,610
получил обновить кэш.

1968
01:26:44,610 --> 01:26:47,780
Вы обновить кэш, это
не имеет значения для кэширования.

1969
01:26:47,780 --> 01:26:49,780
Это на самом деле просто дополнительная работа.

1970
01:26:49,780 --> 01:26:51,970
>> Так, куда мы идем здесь?

1971
01:26:51,970 --> 01:26:54,400
У вас есть большой узкое
там в базе данных.

1972
01:26:54,400 --> 01:26:57,661
И место, чтобы пойти
очевидно, разделения.

1973
01:26:57,661 --> 01:26:59,410
Разметка не
легко сделать, когда вы

1974
01:26:59,410 --> 01:27:01,900
дело с реляционными базами данных.

1975
01:27:01,900 --> 01:27:05,080
С реляционными базами данных, вы
ответственность за управление, эффективно,

1976
01:27:05,080 --> 01:27:06,210
пространство ключей.

1977
01:27:06,210 --> 01:27:10,527
Вы говорите пользователей между А и М
иди сюда, между N и Z туда.

1978
01:27:10,527 --> 01:27:12,360
И вы переходите
по применению.

1979
01:27:12,360 --> 01:27:15,000
Таким образом, вы имеете дело с
этот раздел источника данных.

1980
01:27:15,000 --> 01:27:18,670
Вы должны транзакционных ограничений
которые не охватывают разделы.

1981
01:27:18,670 --> 01:27:20,560
Вы получили все виды
беспорядка, что вы

1982
01:27:20,560 --> 01:27:23,040
дело с там пытаются
иметь дело с масштабирование

1983
01:27:23,040 --> 01:27:25,120
и строительство большего инфраструктуры.

1984
01:27:25,120 --> 01:27:27,284
Это не просто не интересно.

1985
01:27:27,284 --> 01:27:30,930
>> АУДИТОРИЯ: Так вы говорите, что
увеличение точек источника ускоряет

1986
01:27:30,930 --> 01:27:31,430
процесс?

1987
01:27:31,430 --> 01:27:32,513
РИК Хулихэном: Повышение?

1988
01:27:32,513 --> 01:27:33,520
АУДИТОРИЯ: Источник пунктов.

1989
01:27:33,520 --> 01:27:34,410
РИК Хулихэном: Source точки?

1990
01:27:34,410 --> 01:27:37,500
АУДИТОРИЯ: Из информации,
где информация приходит от?

1991
01:27:37,500 --> 01:27:38,250
РИК Хулихэном: Нет

1992
01:27:38,250 --> 01:27:41,820
То, что я говорю, является повышение
Количество разделов в хранилище данных

1993
01:27:41,820 --> 01:27:44,060
улучшает пропускную способность.

1994
01:27:44,060 --> 01:27:48,300
Так что здесь происходит, пользователи
вступления в экземпляре EC2 здесь,

1995
01:27:48,300 --> 01:27:50,780
Ну, если мне нужно пользователю
Это М, я пойду сюда.

1996
01:27:50,780 --> 01:27:53,560
От N р, я пойду сюда.

1997
01:27:53,560 --> 01:27:55,060
С Р до Я, я пойду сюда.

1998
01:27:55,060 --> 01:27:57,120
>> АУДИТОРИЯ: ОК, так те, те
сохраняются в различных узлах?

1999
01:27:57,120 --> 01:27:57,911
>> РИК Хулихэном: Да.

2000
01:27:57,911 --> 01:28:00,210
Подумайте о них, как
различные бункеры данных.

2001
01:28:00,210 --> 01:28:01,660
Таким образом, вы того, чтобы сделать это.

2002
01:28:01,660 --> 01:28:02,910
Если вы пытаетесь сделать
это, если вы пытаетесь

2003
01:28:02,910 --> 01:28:05,730
в масштабе на реляционной платформе,
это то, что вы делаете.

2004
01:28:05,730 --> 01:28:08,100
Вы принимаете данные и
вы резки его.

2005
01:28:08,100 --> 01:28:10,975
И вы разделения его по
несколько экземпляров базы данных.

2006
01:28:10,975 --> 01:28:13,580
И вы все, что управление
на уровне приложений.

2007
01:28:13,580 --> 01:28:14,729
Это не весело.

2008
01:28:14,729 --> 01:28:15,770
Так что мы хотим идти?

2009
01:28:15,770 --> 01:28:20,240
Мы хотим, чтобы перейти DynamoDB, полностью управляемый,
NoSQL хранилища данных, предоставление пропускную способность.

2010
01:28:20,240 --> 01:28:22,680
Мы используем вторичные индексы.

2011
01:28:22,680 --> 01:28:26,154
Это в основном HTTP API и
включает в себя поддержку документа.

2012
01:28:26,154 --> 01:28:28,570
Таким образом, вы не должны беспокоиться
о любом из этого разделения.

2013
01:28:28,570 --> 01:28:30,740
Мы делаем все это для вас.

2014
01:28:30,740 --> 01:28:33,260
Так что теперь, вместо этого, вы
просто напишите в таблице.

2015
01:28:33,260 --> 01:28:36,490
Если таблица должна быть разделена,
что происходит за кулисами.

2016
01:28:36,490 --> 01:28:40,642
Вы полностью изолированы
от как разработчик.

2017
01:28:40,642 --> 01:28:42,350
Итак, давайте поговорим о
некоторые из случаев использования

2018
01:28:42,350 --> 01:28:47,564
что мы бежим в в играх, общая
игровые сценарии, лидеров.

2019
01:28:47,564 --> 01:28:49,980
Итак, вы получили пользователи в ближайшие,
в BoardNames, что они

2020
01:28:49,980 --> 01:28:52,930
на, баллы для этого пользователя.

2021
01:28:52,930 --> 01:28:57,700
Мы могли бы быть хэширования на UserID,
а то у нас ассортимент на игру.

2022
01:28:57,700 --> 01:28:59,960
Таким образом, каждый пользователь хочет видеть
Все игры он играл

2023
01:28:59,960 --> 01:29:01,770
и все его наивысший балл
по всей игры.

2024
01:29:01,770 --> 01:29:04,000
Так что его личная лидеров.

2025
01:29:04,000 --> 01:29:10,010
>> Теперь я хочу, чтобы пойти и я хочу, чтобы get--
так что я получаю эти личные лидеров.

2026
01:29:10,010 --> 01:29:12,827
То, что я хочу сделать, это пойти получить
верхняя оценка для всех пользователей.

2027
01:29:12,827 --> 01:29:13,660
Так как я делаю это?

2028
01:29:13,660 --> 01:29:18,070
Когда мой рекорд хэшируется на
Этот идентификатор, варьировались от игры,

2029
01:29:18,070 --> 01:29:20,740
а я собираюсь идти вперед
и реструктуризации, создать GSI,

2030
01:29:20,740 --> 01:29:22,370
и я собираюсь провести реструктуризацию этих данных.

2031
01:29:22,370 --> 01:29:27,310
>> Теперь я собираюсь, чтобы прояснить на
BoardName, что игра.

2032
01:29:27,310 --> 01:29:29,800
И я собираюсь в диапазоне от наивысший балл.

2033
01:29:29,800 --> 01:29:31,540
А теперь я создал различные ведра.

2034
01:29:31,540 --> 01:29:34,790
Я использую ту же таблицу,
те же самые данные. пункт

2035
01:29:34,790 --> 01:29:39,870
Но я создаю ведро, что дает
мне агрегация наивысший балл по игре.

2036
01:29:39,870 --> 01:29:43,180
>> И я могу запросить эту таблицу
чтобы получить эту информацию.

2037
01:29:43,180 --> 01:29:50,890
Так я установил, что образец запроса до
поддерживаться вторичного индекса.

2038
01:29:50,890 --> 01:29:54,556
Теперь они могут быть отсортированы по BoardName
и сортируются по TopScore, в зависимости от.

2039
01:29:54,556 --> 01:29:57,180
Таким образом, вы можете видеть, это типа
прецедентов вы получите в играх.

2040
01:29:57,180 --> 01:30:02,190
Еще один хороший вариант использования мы получаем в играх
это награды и кто выиграл награды.

2041
01:30:02,190 --> 01:30:05,340
И это большой кейс
где мы называем разреженных индексов.

2042
01:30:05,340 --> 01:30:07,340
Редкие индексы являются
Способность генерировать

2043
01:30:07,340 --> 01:30:10,850
индекс, который не обязательно
содержит каждый пункт на столе.

2044
01:30:10,850 --> 01:30:11,470
И почему бы нет?

2045
01:30:11,470 --> 01:30:14,540
Поскольку атрибут, который будучи
индексированный не существует по каждому пункту.

2046
01:30:14,540 --> 01:30:16,460
>> Таким образом, в этот конкретный
использовать случай, я говорю,

2047
01:30:16,460 --> 01:30:19,240
Вы знаете, что я собираюсь
создать атрибут премии.

2048
01:30:19,240 --> 01:30:22,970
И я собираюсь дать каждому пользователю
что имеет награды, которые приписывают.

2049
01:30:22,970 --> 01:30:25,950
Люди, которые не имеют награды
не будет иметь этот атрибут.

2050
01:30:25,950 --> 01:30:27,800
Поэтому, когда я создать
Индекс, только пользователи

2051
01:30:27,800 --> 01:30:28,960
которые собираются, чтобы показать
в индексе

2052
01:30:28,960 --> 01:30:31,050
те, которые на самом деле выиграли награды.

2053
01:30:31,050 --> 01:30:34,440
Так что это отличный способ, чтобы иметь возможность
создать отфильтрованные индексы,

2054
01:30:34,440 --> 01:30:40,580
очень, очень избирательно, что не
должны индексировать всю таблицу.

2055
01:30:40,580 --> 01:30:43,050
>> Так мы получаем мало времени здесь.

2056
01:30:43,050 --> 01:30:49,190
Я собираюсь идти вперед и пропустить
, и пропустить этот сценарий.

2057
01:30:49,190 --> 01:30:52,625
Поговорите немного about--

2058
01:30:52,625 --> 01:30:54,460
>> АУДИТОРИЯ: Могу ли я задать быстрый вопрос?

2059
01:30:54,460 --> 01:30:56,722
Одним из них является тяжелым написать?

2060
01:30:56,722 --> 01:30:57,680
РИК Хулихэном: Что такое?

2061
01:30:57,680 --> 01:30:58,596
АУДИТОРИЯ: Написать тяжелым.

2062
01:30:58,596 --> 01:31:01,270
РИК Хулихэном: Написать тяжелым.

2063
01:31:01,270 --> 01:31:03,460
Дайте-ка подумать.

2064
01:31:03,460 --> 01:31:06,220
>> АУДИТОРИЯ: Или это не
то, что вы можете просто

2065
01:31:06,220 --> 01:31:08,809
Голос в считанные секунды?

2066
01:31:08,809 --> 01:31:10,850
РИК Хулихэном: Мы идем
через сценарии голосования.

2067
01:31:10,850 --> 01:31:11,670
Это не так уж плохо.

2068
01:31:11,670 --> 01:31:14,580
Есть ли у вас, ребята, есть несколько минут?

2069
01:31:14,580 --> 01:31:15,860
ОК.

2070
01:31:15,860 --> 01:31:17,890
>> Таким образом, мы будем говорить о голосовании.

2071
01:31:17,890 --> 01:31:20,250
Так в режиме реального времени голосования, у нас есть
Требования для голосования.

2072
01:31:20,250 --> 01:31:25,250
Требования, которые мы позволить
каждый человек, чтобы голосовать только один раз.

2073
01:31:25,250 --> 01:31:28,060
Мы хотим, чтобы никто не сможет
изменить свой голос.

2074
01:31:28,060 --> 01:31:31,045
Мы хотим, агрегацию в режиме реального времени
и аналитика для демографии

2075
01:31:31,045 --> 01:31:34,210
что мы собираемся, чтобы быть
показывая пользователей на сайте.

2076
01:31:34,210 --> 01:31:35,200
>> Подумайте об этом сценарии.

2077
01:31:35,200 --> 01:31:37,550
Мы много работаем реальности
Телевизор показывает, где они

2078
01:31:37,550 --> 01:31:38,960
делает эти точный тип вещей.

2079
01:31:38,960 --> 01:31:41,584
Таким образом, вы можете думать о сценарии,
у нас есть миллионы и миллионы

2080
01:31:41,584 --> 01:31:43,959
девушки подросткового там
с их сотовых телефонов

2081
01:31:43,959 --> 01:31:46,250
и голосование, и голосование, и
голосование для тех, кто их

2082
01:31:46,250 --> 01:31:48,610
найти, чтобы быть самым популярным.

2083
01:31:48,610 --> 01:31:50,830
Так вот некоторые из
Требования у нас закончились.

2084
01:31:50,830 --> 01:31:52,990
>> И поэтому первый взять
в решении этой проблемы

2085
01:31:52,990 --> 01:31:55,090
будет строить
очень простое приложение.

2086
01:31:55,090 --> 01:31:56,490
Так что я получил это приложение.

2087
01:31:56,490 --> 01:31:57,950
У меня есть несколько избирателей там.

2088
01:31:57,950 --> 01:31:59,980
Они приходят в, они попали в приложение голосования.

2089
01:31:59,980 --> 01:32:03,440
У меня есть сырое голосов таблицу
Я просто свалка эти голоса в.

2090
01:32:03,440 --> 01:32:05,780
Я есть совокупность
голосов таблица,

2091
01:32:05,780 --> 01:32:09,490
сделает мои аналитики и демографии,
и мы поставим все это там.

2092
01:32:09,490 --> 01:32:11,420
>> И это здорово.

2093
01:32:11,420 --> 01:32:12,332
Жизнь хороша.

2094
01:32:12,332 --> 01:32:15,040
Жизнь хорошая, пока мы не узнаем, что
всегда есть только один или два

2095
01:32:15,040 --> 01:32:16,879
люди, которые пользуются популярностью на выборах.

2096
01:32:16,879 --> 01:32:19,420
Там только один или две вещи,
что люди действительно заботятся о.

2097
01:32:19,420 --> 01:32:22,340
И если вы голосуете на
масштаб, вдруг я

2098
01:32:22,340 --> 01:32:26,360
будет молотком ад из
два кандидата, один или два кандидата.

2099
01:32:26,360 --> 01:32:29,390
Очень ограниченное число пунктов
люди считают, чтобы быть популярным.

2100
01:32:29,390 --> 01:32:31,710
>> Это не хороший дизайн модели.

2101
01:32:31,710 --> 01:32:33,549
Это на самом деле
очень плохо шаблон

2102
01:32:33,549 --> 01:32:36,340
потому что это создает то, что мы
говорили о которой было горячие клавиши.

2103
01:32:36,340 --> 01:32:38,960
Горячие клавиши являются чем-то нам не нравится.

2104
01:32:38,960 --> 01:32:40,470
>> Итак, как мы это исправить?

2105
01:32:40,470 --> 01:32:47,640
И в самом деле, то, как исправить это
принимая те кандидатов ведра

2106
01:32:47,640 --> 01:32:51,490
и для каждого кандидата мы имеем,
мы собираемся добавить случайное значение,

2107
01:32:51,490 --> 01:32:54,192
то, что мы знаем, случайная
Значение между одним и 100,

2108
01:32:54,192 --> 01:32:56,620
между 100 и 1000,
или от одного до 1000,

2109
01:32:56,620 --> 01:32:59,940
Однако многие случайные величины вы хотите
добавить в конец этого кандидата.

2110
01:32:59,940 --> 01:33:01,330
>> И что я действительно сделал то?

2111
01:33:01,330 --> 01:33:05,830
Если я использую идентификатор кандидата как
ведро для совокупных голосов,

2112
01:33:05,830 --> 01:33:08,780
если я добавил случайный
Количество до конца, что,

2113
01:33:08,780 --> 01:33:12,000
Я создал уже 10 ведер, А
сто ведер, тысячи ведра

2114
01:33:12,000 --> 01:33:14,160
что я агрегирования голосов поперек.

2115
01:33:14,160 --> 01:33:18,030
>> Так что у меня миллионы и миллионы,
и миллионы записей в ближайшие

2116
01:33:18,030 --> 01:33:22,050
для этих кандидатов, я сейчас распространяется
эти голоса через кандидат A_1

2117
01:33:22,050 --> 01:33:24,630
через кандидат A_100, потому что
каждый раз, когда голосование идет в,

2118
01:33:24,630 --> 01:33:26,530
Я генерации случайных
Значение между одним и 100.

2119
01:33:26,530 --> 01:33:29,446
Я лавируя его на конце
Кандидат, который человек голосующих за.

2120
01:33:29,446 --> 01:33:31,120
Я сброс его в этом ведре.

2121
01:33:31,120 --> 01:33:33,910
>> Теперь на обратной, я знаю,
что я получил сто ведер.

2122
01:33:33,910 --> 01:33:36,350
Так что, когда я хочу, чтобы идти вперед
и агрегировать голосов,

2123
01:33:36,350 --> 01:33:38,244
Я читал от всех этих ведрах.

2124
01:33:38,244 --> 01:33:39,160
Так что я идти вперед и добавить.

2125
01:33:39,160 --> 01:33:42,410
И тогда я разброс собрать
где я выхожу и говорю эй,

2126
01:33:42,410 --> 01:33:45,399
Вы знаете, что, ключ этого кандидата
пространств более ста ведра.

2127
01:33:45,399 --> 01:33:47,940
Я собираюсь собрать все
голосов от тех ста ведра.

2128
01:33:47,940 --> 01:33:49,981
Я собираюсь объединить
им, и я собираюсь сказать,

2129
01:33:49,981 --> 01:33:53,830
Кандидата в настоящее время
Общая Подсчет голосов от х.

2130
01:33:53,830 --> 01:33:55,690
>> Теперь оба записи
запрос и запрос чтения

2131
01:33:55,690 --> 01:33:58,160
красиво распределены
потому что я пишу по

2132
01:33:58,160 --> 01:34:00,320
и я читаю на сотни ключей.

2133
01:34:00,320 --> 01:34:03,500
Я не пишу и
читать по одному ключу в настоящее время.

2134
01:34:03,500 --> 01:34:04,950
Так что это большой рисунок.

2135
01:34:04,950 --> 01:34:08,090
>> Это на самом деле, вероятно, один
из наиболее важных дизайн

2136
01:34:08,090 --> 01:34:10,420
шаблоны для масштаба в NoSQL.

2137
01:34:10,420 --> 01:34:14,470
Вы увидите этот тип
шаблон в любой вкус.

2138
01:34:14,470 --> 01:34:19,100
MongoDB, DynamoDB, это не
Дело, все мы должны сделать это.

2139
01:34:19,100 --> 01:34:21,840
Потому что, когда вы имеете дело
с тех огромных скоплений,

2140
01:34:21,840 --> 01:34:26,650
Вы должны выяснить, путь к
распространять их по всей ведра.

2141
01:34:26,650 --> 01:34:29,512
Так что это, как вы делаете это.

2142
01:34:29,512 --> 01:34:31,220
Ладно, так, что
Вы делаете прямо сейчас

2143
01:34:31,220 --> 01:34:35,252
это вы будете торговать с чтения
Стоимость для записи масштабируемости.

2144
01:34:35,252 --> 01:34:37,085
Стоимость моей чтения
немного сложнее

2145
01:34:37,085 --> 01:34:40,220
и я должен идти читать из
сто ведер вместо одного.

2146
01:34:40,220 --> 01:34:41,310
Но я могу написать.

2147
01:34:41,310 --> 01:34:44,860
И моя пропускная способность, моя записи
пропускная способность невероятно.

2148
01:34:44,860 --> 01:34:49,450
Так что, как правило, является ценным
Техника для масштабирования DynamoDB,

2149
01:34:49,450 --> 01:34:51,350
или любая база данных NoSQL по этому вопросу.

2150
01:34:51,350 --> 01:34:53,824

2151
01:34:53,824 --> 01:34:55,240
Таким образом, мы выяснили, как масштабировать его.

2152
01:34:55,240 --> 01:34:56,930
И мы поняли, как
ликвидировать наши горячие клавиши.

2153
01:34:56,930 --> 01:34:57,820
И это фантастика.

2154
01:34:57,820 --> 01:34:58,960
И мы получили эту хорошую систему.

2155
01:34:58,960 --> 01:35:02,043
И это дает нам очень правильную голосование
потому что у нас запись голосов де-простофилю.

2156
01:35:02,043 --> 01:35:03,130
Он построен в DynamoDB.

2157
01:35:03,130 --> 01:35:05,380
Мы говорили о условных прав.

2158
01:35:05,380 --> 01:35:08,170
>> Когда избиратель приходит, ставит
вставка на столе,

2159
01:35:08,170 --> 01:35:11,220
они вставляют их избирателей ID,
если они пытаются вставить другой голос,

2160
01:35:11,220 --> 01:35:13,320
Я делаю условное записи.

2161
01:35:13,320 --> 01:35:16,960
Скажите только написать это
если это не существует.

2162
01:35:16,960 --> 01:35:19,270
Поэтому, как только я вижу, что
что голосование в хит таблицу,

2163
01:35:19,270 --> 01:35:20,460
никто не будет
в состоянии поставить свой голос в.

2164
01:35:20,460 --> 01:35:21,634
И это фантастика.

2165
01:35:21,634 --> 01:35:23,550
И мы увеличивая
Наш кандидат счетчики.

2166
01:35:23,550 --> 01:35:25,466
И мы делаем все
демографические и все такое.

2167
01:35:25,466 --> 01:35:29,110
Но что произойдет, если мой
Приложение падает?

2168
01:35:29,110 --> 01:35:31,350
Теперь все вдруг голосов
идут, и я

2169
01:35:31,350 --> 01:35:34,840
не знаю, если они получают обрабатываются
в моих аналитики и демографии

2170
01:35:34,840 --> 01:35:36,040
больше.

2171
01:35:36,040 --> 01:35:38,462
И когда приложение
возвращается вверх, как

2172
01:35:38,462 --> 01:35:41,420
, черт возьми, я знаю, что есть голоса
были обработаны и где я могу начать?

2173
01:35:41,420 --> 01:35:44,530
>> Так что это реальная проблема, когда вы
начинают смотреть на этого типа сценария.

2174
01:35:44,530 --> 01:35:45,571
И как мы решим, что?

2175
01:35:45,571 --> 01:35:48,070
Мы решаем ее с тем, что мы
позвонить DynamoDB потоков.

2176
01:35:48,070 --> 01:35:53,470
Потоки заказывается время и
распределяют журнал изменений каждого доступа

2177
01:35:53,470 --> 01:35:55,700
к столу, каждый написать
Доступ к таблице.

2178
01:35:55,700 --> 01:35:58,810
Любые данные, которые написал в
Таблица показывает вверх в потоке.

2179
01:35:58,810 --> 01:36:01,815
>> Это в основном очереди 24 часа.

2180
01:36:01,815 --> 01:36:03,690
Предметы ударил поток,
они живут в течение 24 часов.

2181
01:36:03,690 --> 01:36:05,990
Они могут быть прочитаны несколько раз.

2182
01:36:05,990 --> 01:36:09,400
Гарантированно будут доставлены
только один раз в поток,

2183
01:36:09,400 --> 01:36:11,180
может быть прочитан п число раз.

2184
01:36:11,180 --> 01:36:14,910
Так многие процессы, однако вы хотите
потреблять эти данные, вы можете потреблять.

2185
01:36:14,910 --> 01:36:16,350
Он появится каждое обновление.

2186
01:36:16,350 --> 01:36:18,455
Каждый записи будет только
появляются раз в потоке.

2187
01:36:18,455 --> 01:36:20,621
Таким образом, вы не должны беспокоиться
об обработке его дважды

2188
01:36:20,621 --> 01:36:22,500
из того же процесса.

2189
01:36:22,500 --> 01:36:25,350
>> Это строго приказал каждому пункту.

2190
01:36:25,350 --> 01:36:28,180
Когда мы говорим, время
заказать и распределяют,

2191
01:36:28,180 --> 01:36:30,680
Вы увидите в разделе на поток.

2192
01:36:30,680 --> 01:36:33,169
Вы увидите предметы, обновления в порядке.

2193
01:36:33,169 --> 01:36:35,210
Мы не гарантируя
на потоке, что ты

2194
01:36:35,210 --> 01:36:40,240
собирается получить каждую сделку
в порядке через предметы.

2195
01:36:40,240 --> 01:36:42,440
>> Так потоки идемпотентная.

2196
01:36:42,440 --> 01:36:44,037
Разве мы все знаем, что идемпотент означает?

2197
01:36:44,037 --> 01:36:46,620
Идемпотентный означает, что вы можете сделать это
снова, и снова, и снова.

2198
01:36:46,620 --> 01:36:48,200
Результат будет тот же.

2199
01:36:48,200 --> 01:36:49,991
>> Потоки идемпотентны,
но они должны быть

2200
01:36:49,991 --> 01:36:54,860
играл с отправной точки,
где бы вы ни выбрали, до конца,

2201
01:36:54,860 --> 01:36:57,950
или они не будут приводить
в тех же значений.

2202
01:36:57,950 --> 01:36:59,727
>> То же самое с MongoDB.

2203
01:36:59,727 --> 01:37:01,560
MongoDB имеет конструкцию
они называют oplog.

2204
01:37:01,560 --> 01:37:04,140
Это точно такой же конструкцией.

2205
01:37:04,140 --> 01:37:06,500
Многие базы данных NoSQL
есть эту конструкцию.

2206
01:37:06,500 --> 01:37:08,790
Они используют его, чтобы делать вещи,
как репликация, которая

2207
01:37:08,790 --> 01:37:10,475
именно то, что мы делаем с потоками.

2208
01:37:10,475 --> 01:37:12,350
АУДИТОРИЯ: Может быть,
еретическим вопрос, но вы

2209
01:37:12,350 --> 01:37:13,975
говорить о приложения делаешь так далее.

2210
01:37:13,975 --> 01:37:16,089
Ручьи гарантированно
не возможно идти вниз?

2211
01:37:16,089 --> 01:37:18,630
РИК Хулихэном: Да, потоки
гарантированно никогда не войдет.

2212
01:37:18,630 --> 01:37:21,040
Мы управлять инфраструктурой
за. потоки автоматически

2213
01:37:21,040 --> 01:37:22,498
развернуть в их авто масштабирования группы.

2214
01:37:22,498 --> 01:37:25,910
Мы пойдем через маленький
немного о том, что происходит.

2215
01:37:25,910 --> 01:37:30,060
>> Я не должен сказать, что они не
гарантированно никогда не идут вниз.

2216
01:37:30,060 --> 01:37:33,110
Элементы гарантируется
появляются в потоке.

2217
01:37:33,110 --> 01:37:36,740
И поток будет доступен.

2218
01:37:36,740 --> 01:37:40,580
Так что идет вниз или возвращается
вверх, что происходит внизу.

2219
01:37:40,580 --> 01:37:43,844
Это covers-- это нормально.

2220
01:37:43,844 --> 01:37:46,260
Ладно, так что вы получите разные
Типы вид на экране.

2221
01:37:46,260 --> 01:37:51,040
Типы мнение, что важны к
программист, как правило, являются, что это было?

2222
01:37:51,040 --> 01:37:52,370
Я старый вид.

2223
01:37:52,370 --> 01:37:55,630
Когда обновление парад таблицу, она будет
нажать прежнию к потоку

2224
01:37:55,630 --> 01:38:02,070
так что данные можно заархивировать, или изменение
контроль, идентификация изменения, изменения

2225
01:38:02,070 --> 01:38:03,600
Управление.

2226
01:38:03,600 --> 01:38:07,160
>> Новый образ, то, что это теперь, после
обновление, это другой тип зрения

2227
01:38:07,160 --> 01:38:07,660
вы можете получить.

2228
01:38:07,660 --> 01:38:09,660
Вы можете получить оба старые и новые образы.

2229
01:38:09,660 --> 01:38:10,660
Может быть, я хочу их обоих.

2230
01:38:10,660 --> 01:38:11,790
Я хочу, чтобы посмотреть, что это было.

2231
01:38:11,790 --> 01:38:13,290
Я хочу, чтобы посмотреть, что он изменился.

2232
01:38:13,290 --> 01:38:15,340
>> У меня есть тип соответствия
процесса, который работает.

2233
01:38:15,340 --> 01:38:17,430
Он должен убедиться, что
когда эти вещи меняются,

2234
01:38:17,430 --> 01:38:21,840
что они в определенных пределах
или в течение определенных параметров.

2235
01:38:21,840 --> 01:38:23,840
>> И тогда, возможно, я только
нужно знать, что изменилось.

2236
01:38:23,840 --> 01:38:26,240
Меня не волнует, какой элемент изменился.

2237
01:38:26,240 --> 01:38:28,580
Мне не нужно, чтобы знать
какие атрибуты изменилось.

2238
01:38:28,580 --> 01:38:30,882
Мне просто нужно знать, что
детали прикосновения.

2239
01:38:30,882 --> 01:38:33,340
Таким образом, эти типы видом
что вы получаете от потока

2240
01:38:33,340 --> 01:38:35,960
и вы можете взаимодействовать с.

2241
01:38:35,960 --> 01:38:37,840
>> Приложение,
потребляет поток,

2242
01:38:37,840 --> 01:38:39,298
это своего рода, как эта работает.

2243
01:38:39,298 --> 01:38:42,570
Клиент DynamoDB попросить
передавать данные в таблицы.

2244
01:38:42,570 --> 01:38:44,750
Потоки развернуть на то, что мы называем осколки.

2245
01:38:44,750 --> 01:38:47,380
Осколки масштабируются
независимо от таблицы.

2246
01:38:47,380 --> 01:38:50,660
Они не выстраиваются полностью
к разделам вашего стола.

2247
01:38:50,660 --> 01:38:52,540
И причина, почему это
потому что они выстраиваются

2248
01:38:52,540 --> 01:38:55,430
с мощностью, ток
Емкость таблицы.

2249
01:38:55,430 --> 01:38:57,600
>> Они используют в своих
собственного авто масштабирование группы,

2250
01:38:57,600 --> 01:39:00,800
и они начинают вращаться из зависимости
на сколько записи идут в,

2251
01:39:00,800 --> 01:39:03,090
сколько reads-- на самом деле это пишет.

2252
01:39:03,090 --> 01:39:05,820
Там нет reads-- но как
многие записи идут в.

2253
01:39:05,820 --> 01:39:08,200
>> А потом на спине
конец, мы имеем то, что

2254
01:39:08,200 --> 01:39:11,390
вызвать KCL, или библиотека Kinesis клиента.

2255
01:39:11,390 --> 01:39:19,190
Кинезис является поток данных
Технология обработки от Amazon.

2256
01:39:19,190 --> 01:39:22,040
И потоки построен на этом.

2257
01:39:22,040 --> 01:39:25,670
>> Таким образом, вы использовать включен то, KCL
Приложение для чтения поток.

2258
01:39:25,670 --> 01:39:28,752
Библиотека Кинезис Клиент фактически
управляет работников для вас.

2259
01:39:28,752 --> 01:39:30,460
И это также делает некоторые
интересные вещи.

2260
01:39:30,460 --> 01:39:35,630
Это создаст несколько таблиц до
в табличном DynamoDB

2261
01:39:35,630 --> 01:39:38,410
отслеживать, какие элементы
были обработаны.

2262
01:39:38,410 --> 01:39:41,190
Так что это путь, если он падает назад, если
это падает и приходит и получает

2263
01:39:41,190 --> 01:39:45,570
стоял обратно, он может определить, где
это было в обработке потока.

2264
01:39:45,570 --> 01:39:48,360
>> Это очень важно, когда
Вы говорите о репликации.

2265
01:39:48,360 --> 01:39:50,350
Мне нужно знать, что
был данные были обработаны

2266
01:39:50,350 --> 01:39:52,810
и какие данные еще должны быть обработаны.

2267
01:39:52,810 --> 01:39:57,380
Таким образом, библиотека, KCL для потоков будет
дать вам много этой функциональности.

2268
01:39:57,380 --> 01:39:58,990
Он заботится о всех хозяйством.

2269
01:39:58,990 --> 01:40:01,140
Он стоит на работника для каждого осколка.

2270
01:40:01,140 --> 01:40:04,620
Это создает административную таблицу
для каждого осколка, для каждого работника.

2271
01:40:04,620 --> 01:40:07,560
И, как те работники огонь,
они поддерживают эти таблицы

2272
01:40:07,560 --> 01:40:10,510
так что вы знаете эту запись
был читать и обрабатываются.

2273
01:40:10,510 --> 01:40:13,850
А потом, что путь, если процесс
умирает и возвращается в Интернете,

2274
01:40:13,850 --> 01:40:17,940
он может возобновить право, где он снял.

2275
01:40:17,940 --> 01:40:20,850
>> Поэтому мы используем это для
кросс-регион репликации.

2276
01:40:20,850 --> 01:40:24,680
Много клиентов есть потребность в
перемещать данные или части своих таблиц данных

2277
01:40:24,680 --> 01:40:25,920
вокруг различных регионах.

2278
01:40:25,920 --> 01:40:29,230
Есть девять регионов
во всем мире.

2279
01:40:29,230 --> 01:40:32,100
Так что может быть я need--
может есть пользователи в Азии, пользователи

2280
01:40:32,100 --> 01:40:34,150
на восточном побережье Соединенных Штатов.

2281
01:40:34,150 --> 01:40:38,980
Они имеют различные данные, что
Необходимо локально распределенной.

2282
01:40:38,980 --> 01:40:42,510
И, может быть, пользователь рейсы из
Азия к США,

2283
01:40:42,510 --> 01:40:45,020
и я хочу, чтобы повторить
его данные с ним.

2284
01:40:45,020 --> 01:40:49,340
Так что, когда он получает от самолета, он имеет
хороший опыт, используя свой мобильный приложение.

2285
01:40:49,340 --> 01:40:52,360
>> Можно использовать перекрестную область
Библиотека репликации для этого.

2286
01:40:52,360 --> 01:40:55,730
В основном у нас есть
при условии, две технологии.

2287
01:40:55,730 --> 01:40:59,400
Один это консольное приложение вы можете
встать на вашем экземпляре EC2.

2288
01:40:59,400 --> 01:41:01,240
Она работает чисто репликации.

2289
01:41:01,240 --> 01:41:02,720
А потом мы дали вам библиотеку.

2290
01:41:02,720 --> 01:41:06,070
Библиотека вы можете использовать, чтобы построить
собственное приложение, если вам

2291
01:41:06,070 --> 01:41:10,740
хочу сделать сумасшедшие вещи с этим data--
фильтр, повторить только его часть,

2292
01:41:10,740 --> 01:41:14,120
вращать данные, переместить его в
отличается стол, так далее, и так далее.

2293
01:41:14,120 --> 01:41:18,700

2294
01:41:18,700 --> 01:41:20,520
Так что вроде как это выглядит.

2295
01:41:20,520 --> 01:41:23,690
>> DynamoDB Потоки могут быть
обрабатываются, что мы называем Lambda.

2296
01:41:23,690 --> 01:41:27,394
Мы уже упоминали немного о событии
управляемые архитектуры приложений.

2297
01:41:27,394 --> 01:41:28,810
Лямбда является ключевым компонентом этого.

2298
01:41:28,810 --> 01:41:32,840
Лямбда-код, который стреляет по требованию
в ответ на конкретное событие.

2299
01:41:32,840 --> 01:41:36,020
Один из этих событий может быть
появляясь на потоке запись.

2300
01:41:36,020 --> 01:41:39,100
Если запись на потоке появляется,
мы будем называть эту функцию Java.

2301
01:41:39,100 --> 01:41:44,980
Ну, это JavaScript, и лямбда
поддерживает Node.js, Java, Python,

2302
01:41:44,980 --> 01:41:47,820
и скоро поддерживать
другие языки, а также.

2303
01:41:47,820 --> 01:41:50,940
И достаточно сказать, что это чистый код.

2304
01:41:50,940 --> 01:41:53,610
написать в Java, вы определяете класс.

2305
01:41:53,610 --> 01:41:55,690
Вы нажимаете на JAR вверх в Lambda.

2306
01:41:55,690 --> 01:42:00,200
А потом вы задаете, какой класс
называть в ответ на событие, которое.

2307
01:42:00,200 --> 01:42:04,770
И тогда инфраструктура Лямбда
за который будет работать этот код.

2308
01:42:04,770 --> 01:42:06,730
>> Этот код может обрабатывать
записи прочь потока.

2309
01:42:06,730 --> 01:42:08,230
Это может делать все, что хочет с ней.

2310
01:42:08,230 --> 01:42:11,650
В этом конкретном примере, все мы
действительно делаете входа атрибуты.

2311
01:42:11,650 --> 01:42:13,480
Но это только код.

2312
01:42:13,480 --> 01:42:15,260
Код может сделать что-нибудь, не так ли?

2313
01:42:15,260 --> 01:42:16,600
>> Таким образом, вы можете вращать эти данные.

2314
01:42:16,600 --> 01:42:18,160
Вы можете создавать производные вид.

2315
01:42:18,160 --> 01:42:21,160
Если это структура документа,
Вы можете сгладить структуру.

2316
01:42:21,160 --> 01:42:24,300
Вы можете создать альтернативные индексы.

2317
01:42:24,300 --> 01:42:27,100
Все виды вещей, вы можете
делать с DynamoDB потоков.

2318
01:42:27,100 --> 01:42:28,780
>> И в самом деле, это, как это выглядит.

2319
01:42:28,780 --> 01:42:29,940
Таким образом, вы получаете эти обновления в ближайшие.

2320
01:42:29,940 --> 01:42:31,190
Они сходит строку.

2321
01:42:31,190 --> 01:42:32,720
Они считываются функцией Lambda.

2322
01:42:32,720 --> 01:42:37,480
Они вращая данные и
толкая его в производных таблицах,

2323
01:42:37,480 --> 01:42:42,200
уведомив внешних систем изменения,
и передавая данные в ElastiCache.

2324
01:42:42,200 --> 01:42:45,900
>> Мы говорили о том, как поставить кэш
перед базе данных для этой продаж

2325
01:42:45,900 --> 01:42:46,450
сценарий.

2326
01:42:46,450 --> 01:42:50,049
Ну, что произойдет, если я
обновить описание товара?

2327
01:42:50,049 --> 01:42:52,340
Ну, если я был Лямбда
Функция работает на этом столе,

2328
01:42:52,340 --> 01:42:55,490
если я обновить описание товара, он будет
подобрать запись с потоком,

2329
01:42:55,490 --> 01:42:58,711
и это обновление ElastiCache
Экземпляр с новыми данными.

2330
01:42:58,711 --> 01:43:00,460
Так что это много
Что мы делаем с Lambda.

2331
01:43:00,460 --> 01:43:02,619
Это клей код, разъемы.

2332
01:43:02,619 --> 01:43:04,410
И это на самом деле дает
способность к запуску

2333
01:43:04,410 --> 01:43:07,930
и работать очень сложных приложений
без выделенного сервера

2334
01:43:07,930 --> 01:43:10,371
инфраструктура, которая на самом деле здорово.

2335
01:43:10,371 --> 01:43:13,100
>> Итак, давайте вернемся к нашему
в режиме реального времени архитектура голосования.

2336
01:43:13,100 --> 01:43:17,984
Это новый и улучшенный с нашим
потоки и, KCL включен приложения.

2337
01:43:17,984 --> 01:43:20,150
То же самое, как и раньше, мы можем
справиться с любой масштаб выборов.

2338
01:43:20,150 --> 01:43:21,100
Нам нравится это.

2339
01:43:21,100 --> 01:43:24,770
Мы делаем из разброса собирает
по нескольким ведра.

2340
01:43:24,770 --> 01:43:26,780
У нас есть оптимизм замок происходит.

2341
01:43:26,780 --> 01:43:30,192
Мы можем держать наши избиратели
от изменения их голоса.

2342
01:43:30,192 --> 01:43:31,400
Они могут голосовать только один раз.

2343
01:43:31,400 --> 01:43:32,880
Это фантастика.

2344
01:43:32,880 --> 01:43:35,895
В режиме реального времени отказоустойчивость,
масштабируемая агрегация настоящее.

2345
01:43:35,895 --> 01:43:38,270
Если вещь падает, это
знает, где перезапустить себя

2346
01:43:38,270 --> 01:43:41,300
когда он возвращается, потому что
мы используем приложение KCL.

2347
01:43:41,300 --> 01:43:45,700
И тогда мы можем также использовать, что
Приложение KCL передавать данные из

2348
01:43:45,700 --> 01:43:48,820
в красное смещение для других
приложение аналитика, или использование

2349
01:43:48,820 --> 01:43:51,990
Эластичный MapReduce для запуска
в режиме реального времени потоковое скопления прочь

2350
01:43:51,990 --> 01:43:53,180
эти данные.

2351
01:43:53,180 --> 01:43:55,480
>> Таким образом, эти вещи, которые мы
не говорил о многом.

2352
01:43:55,480 --> 01:43:57,375
Но они дополнительная
технологии, которые приходят

2353
01:43:57,375 --> 01:44:00,310
нести, когда вы ищете
на этих типах сценариев.

2354
01:44:00,310 --> 01:44:03,160
>> Ладно, так это о
аналитика с DynamoDB потоков.

2355
01:44:03,160 --> 01:44:05,340
Вы можете собрать де-простофилю
Данные, сделать все виды

2356
01:44:05,340 --> 01:44:09,490
из хороших вещей, совокупные данные в
памяти, создавать производные этих таблиц.

2357
01:44:09,490 --> 01:44:13,110
Это огромный кейс
что много клиентов

2358
01:44:13,110 --> 01:44:16,950
участвуют с, принимая вложенный
свойства этих документов JSON

2359
01:44:16,950 --> 01:44:18,946
и создания дополнительных индексов.

2360
01:44:18,946 --> 01:44:21,680

2361
01:44:21,680 --> 01:44:23,150
>> Мы в конце.

2362
01:44:23,150 --> 01:44:26,689
Спасибо за подшипник со мной.

2363
01:44:26,689 --> 01:44:28,480
Итак, давайте поговорим о
Эталонная архитектура.

2364
01:44:28,480 --> 01:44:33,440
DynamoDB сидит в середине, так
большая часть инфраструктуры AWS.

2365
01:44:33,440 --> 01:44:37,090
В общем, вы можете подключить его
до всего, что вы хотите.

2366
01:44:37,090 --> 01:44:45,600
Приложения на платформе Динамо включают
Лямбда, ElastiCache, CloudSearch,

2367
01:44:45,600 --> 01:44:49,890
передать данные из упругой в
MapReduce, экспорт импорт из DynamoDB

2368
01:44:49,890 --> 01:44:52,370
в S3, всех видов технологических процессов.

2369
01:44:52,370 --> 01:44:54,120
Но, наверное, самый лучший
что говорить,

2370
01:44:54,120 --> 01:44:56,119
и это то, что на самом деле
Интересно, когда мы

2371
01:44:56,119 --> 01:44:58,350
говорить о приложений, управляемых событиями.

2372
01:44:58,350 --> 01:45:00,300
>> Это является примером
Внутренний проект

2373
01:45:00,300 --> 01:45:04,850
что у нас есть, где мы на самом деле
издательство, чтобы собрать результаты обследования.

2374
01:45:04,850 --> 01:45:07,700
Таким образом, в электронной связи, что
мы пошлем вне, там будет

2375
01:45:07,700 --> 01:45:11,350
немного ссылку говоря нажмите
здесь, чтобы ответить на обследования.

2376
01:45:11,350 --> 01:45:14,070
И когда человек нажимает
что ссылка, что происходит

2377
01:45:14,070 --> 01:45:18,020
это они тянут вниз безопасный
HTML-формы опроса с S3.

2378
01:45:18,020 --> 01:45:18,980
Там нет сервера.

2379
01:45:18,980 --> 01:45:20,600
Это просто объект S3.

2380
01:45:20,600 --> 01:45:22,770
>> Эта форма подходит,
загружает в браузере.

2381
01:45:22,770 --> 01:45:24,240
Он получил позвоночника.

2382
01:45:24,240 --> 01:45:30,160
Он получил комплекс JavaScript
что он работает.

2383
01:45:30,160 --> 01:45:33,557
Так что это очень богатый приложение
работает в браузере клиента.

2384
01:45:33,557 --> 01:45:36,390
Они не знают, что они не
взаимодействующих с задним сервере.

2385
01:45:36,390 --> 01:45:38,220
На данный момент, это все-браузер.

2386
01:45:38,220 --> 01:45:41,780
>> Они публикуют результаты к тому, что
мы называем Amazon API Gateway.

2387
01:45:41,780 --> 01:45:46,270
Шлюз API это просто Web API
что вы можете определить и подключить

2388
01:45:46,270 --> 01:45:47,760
все, что вы хотите.

2389
01:45:47,760 --> 01:45:50,990
В данном конкретном случае, мы
подключили к лямбда-функции.

2390
01:45:50,990 --> 01:45:54,797
>> Так мой пост операция
происходит без сервера.

2391
01:45:54,797 --> 01:45:56,380
В основном это шлюза API сидит там.

2392
01:45:56,380 --> 01:45:58,770
Это не стоит мне ничего, пока люди
Начало публикации на него, верно?

2393
01:45:58,770 --> 01:46:00,269
Функция Лямбда просто сидит там.

2394
01:46:00,269 --> 01:46:03,760
И это не стоит мне ничего, пока
люди начинают дубасить его.

2395
01:46:03,760 --> 01:46:07,270
Таким образом, вы можете видеть, как объем
увеличивается, что, когда обвинения пришли.

2396
01:46:07,270 --> 01:46:09,390
Я не работает сервер 7/24.

2397
01:46:09,390 --> 01:46:12,310
>> Так что я тянуть форму
вниз из ведра,

2398
01:46:12,310 --> 01:46:15,719
и я отправляю через API
Шлюз в лямбда-функции.

2399
01:46:15,719 --> 01:46:17,510
И тогда Лямбда
Функция говорит, вы знаете,

2400
01:46:17,510 --> 01:46:20,600
то, что я получил некоторые PIIs, некоторые
персональная информация

2401
01:46:20,600 --> 01:46:21,480
в этих ответах.

2402
01:46:21,480 --> 01:46:23,020
Я получил комментарии, поступающие от пользователей.

2403
01:46:23,020 --> 01:46:24,230
Я получил адреса электронной почты.

2404
01:46:24,230 --> 01:46:26,190
Я получил имена.

2405
01:46:26,190 --> 01:46:27,810
>> Позвольте мне разделить это от.

2406
01:46:27,810 --> 01:46:30,280
Я собираюсь генерировать некоторые
метаданные от этой записи.

2407
01:46:30,280 --> 01:46:32,850
И я собираюсь нажать
метаданные в DynamoDB.

2408
01:46:32,850 --> 01:46:36,059
И я мог бы зашифровать все данные,
и вставьте его в DynamoDB, если я хочу.

2409
01:46:36,059 --> 01:46:38,600
Но это легче для меня, в этом
использовать случай, чтобы идти вперед и говорит:

2410
01:46:38,600 --> 01:46:42,800
Я собираюсь выдвинуть исходные данные
в зашифрованном S3 ведра.

2411
01:46:42,800 --> 01:46:47,240
Так что я использую встроенный в стороне сервера S3
шифрования и управления ключами от Amazon

2412
01:46:47,240 --> 01:46:51,600
Обслуживание так что у меня есть ключ, который
может вращаться на очередной интервал,

2413
01:46:51,600 --> 01:46:55,010
и я могу защитить, что PII данные
как часть всей этой рабочего процесса.

2414
01:46:55,010 --> 01:46:55,870
>> Так что я сделал?

2415
01:46:55,870 --> 01:47:00,397
Я только что развернута целая
приложений и у меня нет сервера.

2416
01:47:00,397 --> 01:47:02,980
Так что событийная приложения
архитектура делает для вас.

2417
01:47:02,980 --> 01:47:05,730
>> Теперь, если вы думаете о
прецедент для this--

2418
01:47:05,730 --> 01:47:08,730
у нас есть другие клиенты я говорить
чтобы об этом кто точной архитектуры

2419
01:47:08,730 --> 01:47:14,560
запустить феноменально большие кампании, которые
смотрим на это и происходит, о мой.

2420
01:47:14,560 --> 01:47:17,840
Потому что сейчас, они могут
в основном толкать его там,

2421
01:47:17,840 --> 01:47:21,900
пусть эту кампанию просто сидеть
там, пока не запускает, а не

2422
01:47:21,900 --> 01:47:24,400
придется беспокоиться о фигу
Какая инфраструктура

2423
01:47:24,400 --> 01:47:26,120
будет там, чтобы поддержать его.

2424
01:47:26,120 --> 01:47:28,600
А потом, как только
что кампания будет сделано,

2425
01:47:28,600 --> 01:47:31,520
это как инфраструктуры
просто сразу уходит

2426
01:47:31,520 --> 01:47:33,680
потому что действительно
нет инфраструктуры.

2427
01:47:33,680 --> 01:47:35,660
Это просто код, который сидит на Lambda.

2428
01:47:35,660 --> 01:47:38,560
Это просто данные, которые сидит в DynamoDB.

2429
01:47:38,560 --> 01:47:41,340
Это удивительный способ
для создания приложений.

2430
01:47:41,340 --> 01:47:43,970
>> АУДИТОРИЯ: Так это больше,
эфемерная, чем это было бы

2431
01:47:43,970 --> 01:47:45,740
если он был сохранен на сервере фактической?

2432
01:47:45,740 --> 01:47:46,823
>> РИК Хулихэном: Совершенно верно.

2433
01:47:46,823 --> 01:47:49,190
Потому что этого экземпляра сервера
бы быть 7/24.

2434
01:47:49,190 --> 01:47:51,954
Он должен быть доступен для
чтобы кто-то реагировать.

2435
01:47:51,954 --> 01:47:52,620
Ну думаю, что?

2436
01:47:52,620 --> 01:47:55,410
S3 доступен 7/24.

2437
01:47:55,410 --> 01:47:57,100
S3 всегда отвечает.

2438
01:47:57,100 --> 01:47:59,320
И S3 является очень, очень хорошо
на обслуживание до объектов.

2439
01:47:59,320 --> 01:48:02,590
Эти объекты могут быть HTML файлы, или
Файлы JavaScript, или что вы хотите.

2440
01:48:02,590 --> 01:48:07,430
Вы можете запустить очень богатые веб-приложений
из S3 ведра, и люди.

2441
01:48:07,430 --> 01:48:10,160
>> И так вот идея здесь
чтобы получить от пути

2442
01:48:10,160 --> 01:48:11,270
мы использовали, чтобы думать об этом.

2443
01:48:11,270 --> 01:48:14,270
Мы все привыкли думать, в
Условия серверов и хостов.

2444
01:48:14,270 --> 01:48:16,580
Это не о том, что больше.

2445
01:48:16,580 --> 01:48:19,310
Это об инфраструктуре, как код.

2446
01:48:19,310 --> 01:48:22,470
Развертывание кода в облаке, и
пусть облако запустить его для вас.

2447
01:48:22,470 --> 01:48:24,980
И это то, что AWS пытается сделать.

2448
01:48:24,980 --> 01:48:29,690
>> АУДИТОРИЯ: Так ваш золотой коробке в середине
в API шлюза не сервер, как,

2449
01:48:29,690 --> 01:48:30,576
но вместо этого просто--

2450
01:48:30,576 --> 01:48:32,850
>> РИК Хулихэном: Вы можете думать
о нем, как сервера фасада.

2451
01:48:32,850 --> 01:48:38,040
Все это он будет принимать HTTP
запрашивать и сопоставить его с другим процессом.

2452
01:48:38,040 --> 01:48:39,192
Это все, что он делает.

2453
01:48:39,192 --> 01:48:41,525
И в этом случае, мы отображение
это функция лямбда.

2454
01:48:41,525 --> 01:48:44,119

2455
01:48:44,119 --> 01:48:45,410
Ладно, так что это все, что я получил.

2456
01:48:45,410 --> 01:48:46,190
Большое спасибо.

2457
01:48:46,190 --> 01:48:46,800
Я ценю это.

2458
01:48:46,800 --> 01:48:48,100
Я знаю, мы хотим немного в течение долгого времени.

2459
01:48:48,100 --> 01:48:49,980
И, надеюсь, вы, ребята, есть
немного информации

2460
01:48:49,980 --> 01:48:51,410
что вы можете забрать сегодня.

2461
01:48:51,410 --> 01:48:53,520
И я прошу прощения, если я пошел
над некоторыми из ваших руководителей,

2462
01:48:53,520 --> 01:48:56,697
но есть хороший много
фундаментальные базовые знания

2463
01:48:56,697 --> 01:48:58,280
Я думаю, что очень ценно для вас.

2464
01:48:58,280 --> 01:48:59,825
Так что спасибо вам за то, что мне.

2465
01:48:59,825 --> 01:49:00,325
[АПЛОДИСМЕНТЫ]

2466
01:49:00,325 --> 01:49:02,619
АУДИТОРИЯ: [неразборчиво]
когда вы говорили

2467
01:49:02,619 --> 01:49:05,160
Вы должны были пройти через вещи
от начала до конца

2468
01:49:05,160 --> 01:49:07,619
чтобы получить правильные значения
или те же значения,

2469
01:49:07,619 --> 01:49:09,410
Как бы значения
изменить, если [неразборчиво].

2470
01:49:09,410 --> 01:49:10,480
>> РИК Хулихэном: О, идемпотентным?

2471
01:49:10,480 --> 01:49:11,800
Как бы изменить значения?

2472
01:49:11,800 --> 01:49:15,180
Ну, потому что, если я не запустить
все это путь до конца,

2473
01:49:15,180 --> 01:49:19,770
то я не знаю, какие изменения
были сделаны в последней мили.

2474
01:49:19,770 --> 01:49:22,144
Это не собирается быть
Те же данные, как то, что я увидел.

2475
01:49:22,144 --> 01:49:24,560
АУДИТОРИЯ: О, так ты просто
не получили весь входной.

2476
01:49:24,560 --> 01:49:24,770
РИК Хулихэном: Верно.

2477
01:49:24,770 --> 01:49:26,895
Вы должны идти от начала
до конца, а затем это

2478
01:49:26,895 --> 01:49:29,280
будет последовательной государственной.

2479
01:49:29,280 --> 01:49:31,520
Круто.

2480
01:49:31,520 --> 01:49:35,907
>> АУДИТОРИЯ: Таким образом, вы показали нам DynamoDB
можно сделать документ или ключевое значение.

2481
01:49:35,907 --> 01:49:38,740
И мы потратили много времени на
значение ключа с хэш и пути

2482
01:49:38,740 --> 01:49:40,005
чтобы перевернуть его вокруг.

2483
01:49:40,005 --> 01:49:43,255
Когда вы смотрели на этих таблицах, является то, что
оставив подхода документа?

2484
01:49:43,255 --> 01:49:44,600
>> РИК Хулихэном: Я бы не
говорят оставив его позади.

2485
01:49:44,600 --> 01:49:45,855
>> АУДИТОРИЯ: Они были отделены от the--

2486
01:49:45,855 --> 01:49:49,140
>> РИК Хулихэном: С документа
подход, тип документа в DynamoDB

2487
01:49:49,140 --> 01:49:50,880
просто думаю, как другой атрибут.

2488
01:49:50,880 --> 01:49:53,560
Это атрибут, который содержит
иерархическую структуру данных.

2489
01:49:53,560 --> 01:49:56,980
А потом в запросах,
Вы можете использовать свойства

2490
01:49:56,980 --> 01:49:59,480
из этих объектов с использованием Object Notation.

2491
01:49:59,480 --> 01:50:03,562
Так что я могу фильтровать по вложенным
свойство документа JSON.

2492
01:50:03,562 --> 01:50:05,520
АУДИТОРИЯ: Так любое время я
сделать документ подход,

2493
01:50:05,520 --> 01:50:07,906
Я могу сортировать прибыть в tabular--

2494
01:50:07,906 --> 01:50:08,780
АУДИТОРИЯ: Совершенно верно.

2495
01:50:08,780 --> 01:50:09,800
Аудитория: --indexes и
вещи, которые вы только что говорили о.

2496
01:50:09,800 --> 01:50:11,280
РИК Хулихэном: Да,
индексы и все, что,

2497
01:50:11,280 --> 01:50:13,363
если вы хотите, чтобы индекс в
свойства JSON,

2498
01:50:13,363 --> 01:50:18,230
так, что мы должны сделать это, если
Вы вставляете объект JSON или документ

2499
01:50:18,230 --> 01:50:20,780
в Динамо, вы должны использовать потоки.

2500
01:50:20,780 --> 01:50:22,400
Потоки будут читать ввод.

2501
01:50:22,400 --> 01:50:24,340
Вы бы получить, что JSON
объект, и вы бы сказать, хорошо,

2502
01:50:24,340 --> 01:50:26,030
что свойство Я хочу, чтобы индекс?

2503
01:50:26,030 --> 01:50:28,717
>> Вы можете создать производную таблицу с.

2504
01:50:28,717 --> 01:50:30,300
Теперь это, как он работает сейчас.

2505
01:50:30,300 --> 01:50:32,650
Мы не позволяем индексировать
непосредственно те свойства.

2506
01:50:32,650 --> 01:50:33,520
>> АУДИТОРИЯ: Tabularizing документы.

2507
01:50:33,520 --> 01:50:36,230
>> РИК Хулихэном: Ровно, уплощение
это, tabularizing его, точно.

2508
01:50:36,230 --> 01:50:37,415
Вот то, что вы с ним делать.

2509
01:50:37,415 --> 01:50:37,860
>> АУДИТОРИЯ: Спасибо.

2510
01:50:37,860 --> 01:50:39,609
>> РИК Хулихэном: Да,
абсолютно, спасибо.

2511
01:50:39,609 --> 01:50:42,240
АУДИТОРИЯ: Так что это своего рода
Монго отвечает Redis classifers.

2512
01:50:42,240 --> 01:50:43,990
>> РИК Хулихэном: Да,
это много, как, что.

2513
01:50:43,990 --> 01:50:45,940
Это хорошее описание для этого.

2514
01:50:45,940 --> 01:50:47,490
Круто.

2515
01:50:47,490 --> 01:50:49,102