1
00:00:00,000 --> 00:00:04,969
>> [音乐播放]

2
00:00:04,969 --> 00:00:06,010
RICK霍利汉：好吧。

3
00:00:06,010 --> 00:00:06,600
嗨，大家好。

4
00:00:06,600 --> 00:00:07,670
我的名字是里克霍利汉。

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
我一直在云计算的虚拟化
了约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
我有8项专利中的云系统
虚拟化，微处理器设计，

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
我们将谈论表一点点
结构，应用程序接口，数据类型，索引

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
如果谷歌，你会看到这一点。

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
>> 而这实际上是发生在19世纪80年代。

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
当我买了盒，
该CPU做一些工作。

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年的业务有一个
在管理数据的TB级，

231
00:10:23,510 --> 00:10:27,080
今天，这意味着他们
管理数据的6.5千兆字节。

232
00:10:27,080 --> 00:10:30,380
这就是6​​500倍的数据。

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
谁也和我谈什么是痛苦
它是管理TB的数据。

237
00:10:38,260 --> 00:10:39,700
他们会聊
给我介绍我们如何看待

238
00:10:39,700 --> 00:10:41,825
这很可能会
是一个PB的两

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 PB的数据。

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
好了，关系型数据库，
结构化查询语言，

273
00:12:24,980 --> 00:12:28,600
SQL--这是真正的一个结构
关系型数据库 - 这些东西都是

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
早在20世纪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基础设施只
找到了6个月后，

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
我们要谈点
分片是什么，是

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
要just--有多少我的客户
有这种特殊的特性谁

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
但是这三个点的三角形，
可以这么说，是C，一致性。

382
00:16:52,221 --> 00:16:52,720
好不好？

383
00:16:52,720 --> 00:16:56,760
因此，在CAP，一致性意味着所有
谁可以访问数据库客户端

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
>> 因此，关系数据库choose--
你可以选择其中的两个。

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
如果从分区情况
所述的DataNodes在数据存储，

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
>> 接下来味将是一个AP系统，
或可用，分区

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
>> ACID给了我们原子性，一致性，
隔离性和持久性。

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
所以这是保证
的ACID事务。

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
>> 因此，让我们来看看什么
这看起来像AP系统。

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
所以我们可以说我得到一个
写为s到两个节点。

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
我们有我们的状态，
现在的黄金，这是

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，
该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到视频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
一对一的是顶层
关系; 1对多，

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
我送了CPU遍布系统
加入这些数据结构一起

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
我们将谈论一点点
这是如何工作的迪纳摩DB。

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
在产品表的文档。

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
当我插入一行到曲目
表或一行到相册表，

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
这是比较厚道的
营销或技术 - 

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的数据群集在
规模，运行PB级，

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
对我来说，有很多这真的是6
二分之一的其他的一打。

863
00:36:13,950 --> 00:36:18,710
这些技术的每一个是一个
FINE技术和罚款的解决方案。

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
>> 它是在一个关键和不可或缺的组成部分
我们所说的事件驱动编程。

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
RICK霍利汉：真阳性
与假阴性？

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
>> RICK霍利汉：我不能告诉你。

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
如果你熟悉的任何数据库，
数据库有真正两种的API

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
>> 你得到一个创建表更新，表，
删除表，并说明表。

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可以包含数组
基本类型为root属性。

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
我可能有一个范围的关键，
这是响应标识。

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
>> 范围键允许我 - 哈希
密钥必须平等。

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
因此，在这种特定的情况下，该
我们运行的hash算法是ND 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等于7B，2
等于48，3等于CD。

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是AA到FF。

1061
00:45:49,780 --> 00:45:53,740
所以，如果我使用线性递增
的ID，你可以看到发生了什么。

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
>> RICK霍利亨：是的，这
周围某处有。

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
听众：只需一个快速
你蒙戈的意见。

1078
00:46:36,320 --> 00:46:39,530
那么，自带的对象ID
与本地蒙戈做到这一点？

1079
00:46:39,530 --> 00:46:40,179

1080
00:46:40,179 --> 00:46:41,470
RICK霍利汉：是否做到这一点？

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中必须有一个下划线标识。

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
AZ的是可用性区域。

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
AZS之间毫秒的延迟。

1128
00:49:01,240 --> 00:49:05,390
因此，实时数据复制
能够在多AZS。

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分布
跨越三个AZS默认。

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演唱会的数据中，我们
去[PHH]，我们添加另一个节点。

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千兆字节您的LSI。

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
多缝？

1239
00:54:09,340 --> 00:54:10,200
>> RICK霍利汉：是的。

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
>> GSIS，所以它们如何工作？

1258
00:54:54,860 --> 00:54:58,340
GSIS基本上是异步的。

1259
00:54:58,340 --> 00:55:02,570
更新进入表，
表然后异步更新

1260
00:55:02,570 --> 00:55:03,720
所有的GSIS的。

1261
00:55:03,720 --> 00:55:06,680
这就是为什么GSIS是
最终一致。

1262
00:55:06,680 --> 00:55:09,440
>> 重要的是要注意的是
当你建立GSIS，

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
因为他们正在创建
这些极大的相聚合

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的，LSI的，
我应该使用哪一个？

1306
00:57:08,850 --> 00:57:12,290
LSI公司是一致的。

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
LSI的可以模拟为一个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
吞吐量迪纳摩DB，你
可以提供[听不清]

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
以及如何快速表
可以迪纳摩DB运行。

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
再然后，我们有
那个小LSI问题

1334
00:58:27,300 --> 00:58:30,405
每个哈希的10 GB的限制。

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 k是总大小
该项目，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
RCU的措施，严格一致的读取。

1349
00:59:08,640 --> 00:59:13,005
好了，如果你说我要1000
RCU的那些都是严格一致，

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
RCU的，你要去

1353
00:59:19,402 --> 00:59:21,840
得到2000最终
持续读。

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--
如果你消耗你的RCU的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
数据库，特别是迪纳摩DB，

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
>> RICK霍利汉：始终。

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
他们发现你的cookie。

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
现在，他们已经
去迪纳摩DB，他们

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
您可以在迪纳摩DB获得巨大。

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是一个公司，是
基本切换到发电机DB

1515
01:06:19,800 --> 01:06:22,200
因为他们遇到
巨大的成长的烦恼。

1516
01:06:22,200 --> 01:06:25,820
而他们告诉我们，
突然PB的数据。

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
当他们需要看视频，
他们期待在迪纳摩DB中的记录。

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
>> 迪纳摩DB降低其
交货期为视频事件

1529
01:06:56,010 --> 01:06:57,590
从5到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，这些家伙，它是什么，
水果忍者我想是他们的事。

1537
01:07:20,500 --> 01:07:22,590
这对迪纳摩DB所有运行。

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
他们看着那个迪纳摩DB。

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--的
受益您从迪纳摩DB得到。

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
现在，该表上的我
可以定义一个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
>> 所以这是一种建
到表中迪纳摩DB。

1595
01:10:04,600 --> 01:10:07,290
当我定义一个哈希
和范围T台，我

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
因此，在迪纳摩DB，我们有
创造能力

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
它在同样的事情
迪纳摩DB或其他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
这是在迪纳摩DB非常重要的。

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
>> [插入VOICES]

1689
01:14:14,316 --> 01:14:16,232
RICK霍利汉：我不会
得到太多到这一点。

1690
01:14:16,232 --> 01:14:17,700
这是一个保留关​​键字。

1691
01:14:17,700 --> 01:14:20,130
英镑观点是保留
关键字迪纳摩DB。

1692
01:14:20,130 --> 01:14:24,500
每个数据库都有自己的保留
名称的集合不能使用。

1693
01:14:24,500 --> 01:14:27,240
迪纳摩DB，如果您指定
一斤在这方面，

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
什么是用例迪纳摩DB。

1706
01:15:03,810 --> 01:15:06,120
什么是设计
模式在迪纳摩DB。

1707
01:15:06,120 --> 01:15:09,110
>> 而第一个我们要
谈的是物联网。

1708
01:15:09,110 --> 01:15:15,010
因此，我们得到了很多of--我猜，
什么是它 -  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
您如何看待谷歌地图工程
当他们告诉你的业务是什么。

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
我会采取RCU年代和
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
我可以采取WCU的
下一个所有的方式，

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
我有一个修整它
cron作业，我把它

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
电子邮件，大家都用电子邮件。

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
消息来了[听不清]
消息ID，这是伟大的。

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
这是我的转化率
对于RCU的为四字节。

1825
01:20:21,730 --> 01:20:24,450
>> 好吧，让我们一起去
最终一致性读取。

1826
01:20:24,450 --> 01:20:28,640
我还在吃1600 RCU的
只是看大卫的收件箱。

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
消息ID，它指向
回邮件表

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
那么，这些将是记录ID。

1840
01:21:04,420 --> 01:21:09,850
他们将指向回
项ID在迪纳摩数据库表。

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
RICK霍利亨：是的，它告诉
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年烧毁
RCU的只是为了显示他的收件箱。

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
散列发件人。

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
垂直分区，
这些分区表。

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
游戏这些天，特别是移动
游戏，是所有关于思维。

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 API的。

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
我们谈到AZS作为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的是CD和
内容分发网络。

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
因此，该技术具有自动气象站，它
允许您指定的参数

1950
01:26:02,090 --> 01:26:04,650
围绕您的服务器将增长。

1951
01:26:04,650 --> 01:26:08,110
所以，你可以拥有服务器的n个
在那里，在任何给定的时间。

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
你说A和M之间的用户
去这里，与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
RICK霍利汉：增加？

1988
01:27:32,513 --> 01:27:33,520
听众：源点。

1989
01:27:33,520 --> 01:27:34,410
RICK霍利汉：源点？

1990
01:27:34,410 --> 01:27:37,500
听众：从信息，
其中的信息是从哪里来的？

1991
01:27:37,500 --> 01:27:38,250
RICK霍利汉：没有。

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
好吧，如果我需要一个用户
这是A至M，我会去这里。

1996
01:27:50,780 --> 01:27:53,560
从氮磷，我会去这里。

1997
01:27:53,560 --> 01:27:55,060
从P到Z，我会去这里。

1998
01:27:55,060 --> 01:27:57,120
>> 听众：好，那所以这些都是
所有存储在不同的节点？

1999
01:27:57,120 --> 01:27:57,911
>> RICK霍利汉：是的。

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
我们可能会被散列的用户名，
然后，我们有一系列的游戏。

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
当我的纪录被散列上
用户ID，排列在游戏中，

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
RICK霍利汉：是什么？

2061
01:30:57,680 --> 01:30:58,596
听众：写沉重。

2062
01:30:58,596 --> 01:31:01,270
RICK霍利汉：写沉重。

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
RICK霍利汉：我们去
通过投票的情景。

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
东西我们知道，随机
1和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
如果我使用的候选者ID为
斗到总票数，

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
我生成一个随机的
1和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
候选人A目前拥有
x的总投票数。

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
>> 这实际上可能是1
的最重要的设计

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
他们与他们的选民身份插入，
如果他们试图插入另一张选票，

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
可以读取n次。

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
RICK霍利亨：是啊，小溪
都保证不会跌的。

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，或室壁运动客户端库。

2255
01:39:11,390 --> 01:39:19,190
室壁运动是一个数据流
加工技术从亚马逊。

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
想要做疯狂的事情与数据 - 
过滤器，复制的只是其中的一部分，

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
LAMBDA是一个关键组成部分。

2298
01:41:28,810 --> 01:41:32,840
LAMBDA是触发按需代码
响应于特定的事件。

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的，和Lambda
支持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
好吧，如果我有一个LAMBDA
在该表上运行的功能，

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
使用内置的应用迪纳摩包括
LAMBDA，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
是他们拉下安全
从S3 HTML调查表。

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
>> 他们公布的结果是什么
我们所说的亚马逊API网关。

2387
01:45:41,780 --> 01:45:46,270
API网关是一个简单的网络API
你可以定义和挂钩

2388
01:45:46,270 --> 01:45:47,760
到任何你想要的。

2389
01:45:47,760 --> 01:45:50,990
在这种特殊情况下，我们
迷上了一个lambda函数。

2390
01:45:50,990 --> 01:45:54,797
>> 所以我的POST操作
发生的事情没有服务器。

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
lambda函数只是坐在那里。

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发布
网关到lambda函数。

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服务器端
加密和亚马逊的密钥管理

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
>> RICK霍利汉：当然。

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
反而是just--

2450
01:48:30,576 --> 01:48:32,850
>> RICK霍利汉：你能想到的
它作为服务器的门面。

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
在这种情况下，我们正在映射
它以一个lambda函数。

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
>> RICK霍利亨：哦，等幂？

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
RICK霍利汉：对。

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
>> RICK霍利汉：我不会
说离开它后面。

2485
01:49:44,600 --> 01:49:45,855
>> 听众：他们从the--分离

2486
01:49:45,855 --> 01:49:49,140
>> RICK霍利汉：随着文档
方法，在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
使用对象标记这些对象。

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
RICK霍利亨：是的，
索引和所有这一切，

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
对象，你会说OK，

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
>> RICK霍利亨：没错，压扁
它，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
>> RICK霍利亨：是的，
绝对的，谢谢你。

2511
01:50:39,609 --> 01:50:42,240
听众：所以它是一种
蒙戈满足Redis的分类器。

2512
01:50:42,240 --> 01:50:43,990
>> RICK霍利亨：是啊，
这是一个很多这样的。

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