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
這就是6500倍的數據。

233
00:10:30,380 --> 00:10:31,200
我知道這一點。

234
00:10:31,200 --> 00:10:33,292
我每天都在與這些企業的合作。

235
00:10:33,292 --> 00:10:35,000
五年前，我
會跟公司

236
00:10:35,000 --> 00:10:38,260
誰也和我談什麼是痛苦
它是管理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，
或者一個與1​​000之間，

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