1
00:00:00,000 --> 00:00:04,969
>> [Гуляе музыка]

2
00:00:04,969 --> 00:00:06,010
РВК Хулихэном: Добра.

3
00:00:06,010 --> 00:00:06,600
Прывітанне, усім.

4
00:00:06,600 --> 00:00:07,670
Мяне клічуць Рык Houlihan.

5
00:00:07,670 --> 00:00:10,330
Я старэйшы асноўнай
Рашэнні архітэктар AWS.

6
00:00:10,330 --> 00:00:14,070
Я засяроджваюся на NoSQL і
Тэхналогіі DynamoDB.

7
00:00:14,070 --> 00:00:16,930
Я сёння тут, каб пагаварыць з
Вы крыху пра іх.

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

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

10
00:00:21,390 --> 00:00:25,930
доступу да дадзеных, рашэнні
для розных ужыванняў.

11
00:00:25,930 --> 00:00:30,000
Я быў у Cloud віртуалізацыі
на працягу прыкладна 20 гадоў.

12
00:00:30,000 --> 00:00:33,460
Таму, перш чым воблака Воблака,
мы прывыклі называць яго карыснасць вылічэнняў.

13
00:00:33,460 --> 00:00:37,170
А ідэя была, гэта як
PG & E, вы плаціце за тое, што вы выкарыстоўваеце.

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

15
00:00:38,800 --> 00:00:41,239
>> Але на працягу многіх гадоў, я працаваў
на пару кампаній

16
00:00:41,239 --> 00:00:42,530
Вы верагодна ніколі не чулі.

17
00:00:42,530 --> 00:00:47,470
Але я склаў спіс тэхнічных
дасягнення, я думаю, вы б сказаць.

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

19
00:00:51,620 --> 00:00:54,440
Комплекс апрацоўкі падзей,
і іншых галінах, а таксама.

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

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

22
00:00:59,450 --> 00:01:03,370
І гэта, як правіла тое, што я збіраюся
каб быць тут і размаўляю з вамі сёння а.

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

24
00:01:06,030 --> 00:01:08,254
мы пойдзем праз сцісла
Гісторыя апрацоўкі дадзеных.

25
00:01:08,254 --> 00:01:10,420
Гэта заўсёды карысна
зразумець, адкуль мы прыйшлі

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

27
00:01:12,400 --> 00:01:15,600
І мы будзем казаць трохі
Крыху пра тэхналогіі NoSQL

28
00:01:15,600 --> 00:01:17,500
з фундаментальнай пункту гледжання.

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

30
00:01:19,870 --> 00:01:24,350
DynamoDB ня AWS ў ня водар.

31
00:01:24,350 --> 00:01:27,340
Гэта цалкам кіраваны і
сервернае рашэнне NoSQL.

32
00:01:27,340 --> 00:01:32,420
І мы будзем казаць крыху пра табліцы
структура, API, тыпы дадзеных, індэксы,

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

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

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

36
00:01:39,968 --> 00:01:41,430
сучасных прыкладанняў.

37
00:01:41,430 --> 00:01:44,820
І тады мы будзем казаць трохі
аб эвалюцыі або з'яўленне

38
00:01:44,820 --> 00:01:48,980
новай парадыгмы ў праграмаванні
званыя прыкладання кіраваныя падзеямі

39
00:01:48,980 --> 00:01:51,580
і як DynamoDB гуляе ў тым, што, як добра.

40
00:01:51,580 --> 00:01:54,690
І мы выйдзем вам крыху
абмеркаванне Эталонная архітэктура

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

42
00:01:59,540 --> 00:02:04,116
>> Такім чынам, спачатку off-- гэта пытанне
Я чуў шмат ёсць, што база дадзеных.

43
00:02:04,116 --> 00:02:06,240
Шмат людзей думаюць, што яны
ведаю, што база дадзеных.

44
00:02:06,240 --> 00:02:08,360
Калі вы Google, вы ўбачыце, што гэта.

45
00:02:08,360 --> 00:02:11,675
Гэта структураваны набор дадзеных, якія захоўваюцца
ў кампутары, асабліва той, які

46
00:02:11,675 --> 00:02:13,600
даступны ў розных напрамках.

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

48
00:02:16,992 --> 00:02:19,450
Але я не люблю яго, таму што
гэта мае на ўвазе некалькі рэчаў.

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

50
00:02:20,935 --> 00:02:23,120
І гэта азначае, што ён знаходзіцца на кампутары.

51
00:02:23,120 --> 00:02:25,750
І не зрабіў базы дадзеных
заўсёды існуе на кампутарах.

52
00:02:25,750 --> 00:02:28,020
Базы дадзеных сапраўды існаваў у многіх адносінах.

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

54
00:02:32,000 --> 00:02:34,786
База дадзеных арганізаваны
механізм захоўвання, кіравання,

55
00:02:34,786 --> 00:02:35,910
і здабывання інфармацыі.

56
00:02:35,910 --> 00:02:36,868
Гэта з About.com.

57
00:02:36,868 --> 00:02:42,080
Так што я хацеў гэтага, таму што гэта сапраўды перамовы
аб базе даных быўшы сховішча,

58
00:02:42,080 --> 00:02:44,800
сховішча
Інфармацыя, не абавязкова

59
00:02:44,800 --> 00:02:46,780
тое, што сядзіць на кампутары.

60
00:02:46,780 --> 00:02:49,290
І на працягу ўсёй гісторыі, мы
не заўсёды кампутараў.

61
00:02:49,290 --> 00:02:52,110
>> Цяпер, калі я прашу сярэднім
Распрацоўшчык сёння тое, што

62
00:02:52,110 --> 00:02:54,770
база дадзеных, вось і адказ я атрымліваю.

63
00:02:54,770 --> 00:02:56,070
Дзесьці я магу прытрымлівацца рэчаў.

64
00:02:56,070 --> 00:02:56,670
Дакладна?

65
00:02:56,670 --> 00:02:58,725
І гэта праўда.

66
00:02:58,725 --> 00:02:59,600
Але гэта сумна.

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

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

69
00:03:04,810 --> 00:03:07,240
І, як вы будуеце, што
базы дадзеных, як структураваць

70
00:03:07,240 --> 00:03:11,750
што дадзеныя будзе дыктаваць, як гэта
Дадатак выконвае, як вы маштабе.

71
00:03:11,750 --> 00:03:14,640
>> Так шмат маёй працы сёння
мае справу з тым, што

72
00:03:14,640 --> 00:03:17,180
адбываецца, калі распрацоўшчыкі
гэты падыход

73
00:03:17,180 --> 00:03:19,510
і справу з наступствамі
прыкладання, якое

74
00:03:19,510 --> 00:03:24,966
Цяпер маштабавання за арыгінал
Мэта і пакуты ад дрэннага дызайну.

75
00:03:24,966 --> 00:03:26,840
Так, мы спадзяемся, калі вам
хады сёння, вы будзеце

76
00:03:26,840 --> 00:03:29,010
ёсць некалькі інструментаў, у
Ваш пояс, які будзе трымаць вас

77
00:03:29,010 --> 00:03:32,566
ад прыняцця тых жа памылак.

78
00:03:32,566 --> 00:03:33,066
Добра.

79
00:03:33,066 --> 00:03:36,360
Такім чынам, давайце пагаворым аб трохі
тэрміны тэхналогіі баз дадзеных.

80
00:03:36,360 --> 00:03:38,830
Я думаю, што я прачытаў
артыкул не так даўно

81
00:03:38,830 --> 00:03:43,020
і ён сказаў, што-то на lines--
гэта вельмі паэтычна заяве.

82
00:03:43,020 --> 00:03:46,590
Гэта сказаў, што гісторыя
дадзеных апрацоўка

83
00:03:46,590 --> 00:03:49,350
поўны высокіх вадзяных знакаў
багацця дадзеных.

84
00:03:49,350 --> 00:03:49,920
ДОБРА.

85
00:03:49,920 --> 00:03:52,532
Зараз, я думаю, што гэта свайго роду праўда.

86
00:03:52,532 --> 00:03:54,990
Але я на самой справе глядзець на гэта, як
Гісторыя на самай справе запоўненыя

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

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

89
00:04:00,040 --> 00:04:01,360
Гэта толькі ідзе ўверх.

90
00:04:01,360 --> 00:04:03,670
>> І інавацыі адбываецца, калі
мы бачым ціск дадзеных, які

91
00:04:03,670 --> 00:04:07,825
гэта колькасць дадзеных, якія
у цяперашні час у паступае ў сістэму.

92
00:04:07,825 --> 00:04:12,027
І гэта не можа быць апрацаваны
эфектыўна ні ў часе, або ў кошту.

93
00:04:12,027 --> 00:04:14,110
І вось, калі мы пачынаем
паглядзець на ціск дадзеных.

94
00:04:14,110 --> 00:04:15,920
>> Таму, калі мы глядзім на
Першая база дадзеных, гэта

95
00:04:15,920 --> 00:04:17,180
гэта той, які быў паміж нашымі вушамі.

96
00:04:17,180 --> 00:04:18,310
Мы ўсе народжаныя з ім.

97
00:04:18,310 --> 00:04:19,194
Гэта добрая база.

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

99
00:04:21,110 --> 00:04:21,959
Гэта заўсёды.

100
00:04:21,959 --> 00:04:23,930
Вы заўсёды можаце атрымаць яго.

101
00:04:23,930 --> 00:04:24,890
>> Але гэта адзін карыстальнік.

102
00:04:24,890 --> 00:04:26,348
Я не магу падзяліцца сваімі думкамі з вамі.

103
00:04:26,348 --> 00:04:28,370
Вы не можаце сабрацца з думкамі
калі вы хочаце іх.

104
00:04:28,370 --> 00:04:30,320
І іх abilitiy не так добра.

105
00:04:30,320 --> 00:04:32,510
Мы забываемся рэчы.

106
00:04:32,510 --> 00:04:36,540
Раз-пораз, адзін з нас лісце
і пераходзіць да іншага існавання

107
00:04:36,540 --> 00:04:39,110
і мы страцім усё
што было ў гэтай базе дадзеных.

108
00:04:39,110 --> 00:04:40,640
Так што не ўсё так добра.

109
00:04:40,640 --> 00:04:43,189
>> І гэта працавала добра на працягу доўгага часу
калі мы былі яшчэ ў дзень

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

111
00:04:46,230 --> 00:04:49,630
ці там, дзе мы збіраем лепшую ежу.

112
00:04:49,630 --> 00:04:52,820
Але, як мы пачалі расці як
цывілізацыя і ўрад пачатак

113
00:04:52,820 --> 00:04:55,152
прыйсці ў быццё, і
бізнэс пачаў развівацца,

114
00:04:55,152 --> 00:04:57,360
мы пачалі разумець, мы
трэба крыху больш, чым

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

116
00:04:58,210 --> 00:04:58,870
Усё ў парадку?

117
00:04:58,870 --> 00:05:00,410
>> Нам патрэбна сістэм запісу.

118
00:05:00,410 --> 00:05:02,220
Нам трэба месцы, каб быць у стане захоўваць дадзеныя.

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

120
00:05:05,450 --> 00:05:08,000
Мы пачалі распрацоўвае
Сістэма бухгалтарскіх кніга.

121
00:05:08,000 --> 00:05:12,200
І, што сістэма падліку бухгалтарскай кнігі
пабег свет на працягу многіх стагоддзяў,

122
00:05:12,200 --> 00:05:15,580
і, магчыма, нават тысячагоддзяў, як
мы накшталт выраслі да пункту

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

124
00:05:18,420 --> 00:05:19,870
каб мець магчымасць утрымліваць яго.

125
00:05:19,870 --> 00:05:22,070
>> І гэта на самай справе адбылося ў 1880 годзе.

126
00:05:22,070 --> 00:05:22,570
Дакладна?

127
00:05:22,570 --> 00:05:24,390
У 1880 перапісу насельніцтва ЗША.

128
00:05:24,390 --> 00:05:26,976
Гэта сапраўды, дзе паварот
паказваюць сучаснай апрацоўцы дадзеных.

129
00:05:26,976 --> 00:05:28,850
Гэта кропка, у
якіх аб'ём дадзеных

130
00:05:28,850 --> 00:05:32,060
што ў цяперашні час, сабраных
Урад ЗША патрапіў у кропку,

131
00:05:32,060 --> 00:05:34,005
дзе спатрэбілася восем гадоў, каб апрацаваць.

132
00:05:34,005 --> 00:05:36,350
>> Цяпер, восем years-- як
Вы ведаеце, перапісу

133
00:05:36,350 --> 00:05:39,180
працуе кожныя 10 years-- так што гэта
Цалкам відавочна, што па часе мы

134
00:05:39,180 --> 00:05:41,419
атрымаў перапісу 1890,
колькасць дадзеных, якія

135
00:05:41,419 --> 00:05:43,210
збіраўся быць апрацаваны
урадам было

136
00:05:43,210 --> 00:05:46,335
збіраецца перавышаць 10 гадоў, што гэта
спатрэбіцца, каб запусціў новую перапісу.

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

138
00:05:47,250 --> 00:05:49,000
>> Такім чынам, хлопец па імі Герман
Холлерит прыйшлі разам

139
00:05:49,000 --> 00:05:52,640
і ён вынайшаў блок запісу ўдар
карты, чытач перфакарты, перфакарты

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

141
00:05:58,420 --> 00:06:01,860
І, што кампанія, якая ён сфармаваў на
Час, разам з парай іншых,

142
00:06:01,860 --> 00:06:05,450
фактычна стаў адным з слупоў
невялікая кампанія, мы ведаем сёння называецца IBM.

143
00:06:05,450 --> 00:06:08,417
>> Так IBM першапачаткова была ў
бізнес базы дадзеных.

144
00:06:08,417 --> 00:06:09,750
І гэта сапраўды тое, што яны зрабілі.

145
00:06:09,750 --> 00:06:11,110
Яны зрабілі апрацоўку дадзеных.

146
00:06:11,110 --> 00:06:15,400
>> Як жа так распаўсюджваннем ўдар
карты, геніяльны механізмы

147
00:06:15,400 --> 00:06:18,560
быць у стане выкарыстаць што
Тэхналогія апытання адсартаваныя выніковых набораў.

148
00:06:18,560 --> 00:06:20,726
Вы можаце ўбачыць у гэтай карціне
ёсць у нас ёсць little--

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

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

151
00:06:26,970 --> 00:06:28,720
І хто-то бярэ
трохі адвёртка

152
00:06:28,720 --> 00:06:31,400
і прытрымлівацца праз
Слоты і падняўшы яе

153
00:06:31,400 --> 00:06:34,820
каб атрымаць, што матч, што
Сартаваць набор вынікаў.

154
00:06:34,820 --> 00:06:36,270
>> Гэта аб'яднанне.

155
00:06:36,270 --> 00:06:38,690
Мы робім гэта ўвесь час
сёння ў кампутары,

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

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

158
00:06:41,620 --> 00:06:42,994
Людзі ставяць гэтыя рэчы разам.

159
00:06:42,994 --> 00:06:45,440
І гэта было распаўсюджванне
з гэтых перфакарт

160
00:06:45,440 --> 00:06:50,070
у тое, што мы назвалі барабанаў дадзеных
і барабаны дадзеных, папяровыя стужкі.

161
00:06:50,070 --> 00:06:55,980
>> Апрацоўка дадзеных прамысловасці прынялі
ўрок ад гульцоў фартэпіяна.

162
00:06:55,980 --> 00:06:57,855
Гулец піяніна таму на
паварот стагоддзя

163
00:06:57,855 --> 00:07:02,100
выкарыстоўваць выкарыстоўваць папяровыя барабаны з пазамі
распавядаць ягоныя, якія клавішы, каб гуляць.

164
00:07:02,100 --> 00:07:05,380
Так што тэхналогіі быў адаптаваны
у канчатковым выніку, каб захаваць лічбавыя дадзеныя,

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

166
00:07:08,070 --> 00:07:10,870
>> Цяпер, у выніку чаго дадзеныя
быў actually-- як

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

168
00:07:14,960 --> 00:07:17,825
Так што, калі я паклаў дадзеныя на стужцы,
Я меў доступ да дадзеных, лінейна.

169
00:07:17,825 --> 00:07:20,475
Я павінен быў згарнуць ўвесь
Стужка для доступу да ўсіх дадзеных.

170
00:07:20,475 --> 00:07:22,600
Калі я стаўлю дадзеныя ў ўдар
карты, я мог бы атрымаць доступ да яго

171
00:07:22,600 --> 00:07:26,270
ў трохі больш выпадковым
мода, можа быць, не так хутка.

172
00:07:26,270 --> 00:07:30,770
>> Але былі абмежаванні ў тым, як мы
Доступ да дадзеных на аснове, як было захавана.

173
00:07:30,770 --> 00:07:32,890
І так гэта было праблемай
ўдаючыся ў 50-х.

174
00:07:32,890 --> 00:07:37,890
Зноў жа, мы можам пачаць бачыць, што, як мы
распрацоўка новых тэхналогій для апрацоўкі

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

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

177
00:07:45,852 --> 00:07:47,810
І на самай справе, кіраванне
можа быць прычынай

178
00:07:47,810 --> 00:07:49,435
Таму мы распрацавалі некаторыя з гэтых сістэм.

179
00:07:49,435 --> 00:07:52,290
Але справа хутка стаў
кіроўца за эвалюцыі

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

181
00:07:54,720 --> 00:07:56,870
>> Такім чынам, наступная рэч, што
падышоў было ў 50-х

182
00:07:56,870 --> 00:08:00,780
быў файлавая сістэма і
Развіццё выпадковай захоўвання доступу.

183
00:08:00,780 --> 00:08:02,050
Гэта было прыгожа.

184
00:08:02,050 --> 00:08:06,230
Цяпер, усе раптам, мы можам паставіць нашу
файлы ў любым месцы на гэтых жорсткіх дыскаў

185
00:08:06,230 --> 00:08:09,760
і мы можам атрымаць доступ да гэтай інфармацыі ў выпадковым парадку.

186
00:08:09,760 --> 00:08:11,950
Мы можам разабраць, што
Інфармацыя з файлаў.

187
00:08:11,950 --> 00:08:14,920
І мы вырашылі ўсё ў свеце
Праблемы з апрацоўкай дадзеных.

188
00:08:14,920 --> 00:08:17,550
>> І доўжылася каля 20 ці
30 гадоў да эвалюцыі

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

190
00:08:22,100 --> 00:08:27,940
трэба мець сховішча, перамагае
разрастанне дадзеных па файле

191
00:08:27,940 --> 00:08:29,540
Сістэмы, якія мы пабудавалі. Дакладна?

192
00:08:29,540 --> 00:08:34,270
Занадта шмат дадзеных, размеркаваных ў занадта шмат
месца, дэ-дубліраванне дадзеных,

193
00:08:34,270 --> 00:08:37,120
і кошт захоўвання быў велізарны.

194
00:08:37,120 --> 00:08:43,760
>> У 70-х, самы дарагі рэсурс
што кампутар быў быў захоўвання.

195
00:08:43,760 --> 00:08:46,200
Працэсар быў
разглядаць як фіксаваную кошт.

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

197
00:08:49,030 --> 00:08:51,960
Гэта збіраецца быць спінінг Ці
гэта на самай справе ці не.

198
00:08:51,960 --> 00:08:53,350
Гэта сапраўды панесеных расходаў.

199
00:08:53,350 --> 00:08:56,030
>> Але тое, што варта было мне як
бізнес захоўвання.

200
00:08:56,030 --> 00:09:00,020
Калі ў мяне ёсць, каб купіць больш дыскаў у наступным
месяц, што гэта рэальны кошт, што я плаціць.

201
00:09:00,020 --> 00:09:01,620
І захоўвання каштуе дорага.

202
00:09:01,620 --> 00:09:05,020
>> Цяпер мы хутка наперад 40 гадоў
і ў нас ёсць іншая праблема.

203
00:09:05,020 --> 00:09:10,020
Вылічальных цяпер
самы дарагі рэсурс.

204
00:09:10,020 --> 00:09:11,470
Захоўванне танна.

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

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

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

208
00:09:20,700 --> 00:09:23,050
сапраўды сканцэнтраваны вакол
размеркаваныя базы дадзеных

209
00:09:23,050 --> 00:09:26,960
якія не пакутуюць ад
і той жа тып шкалы

210
00:09:26,960 --> 00:09:29,240
Абмежаванні рэляцыйных баз дадзеных.

211
00:09:29,240 --> 00:09:32,080
Мы пагаворым крыху пра
што гэта на самай справе азначае.

212
00:09:32,080 --> 00:09:34,760
>> Але адна з прычын, і
кіроўца за this-- мы

213
00:09:34,760 --> 00:09:38,290
казалі пра ціск дадзеных.

214
00:09:38,290 --> 00:09:41,920
Ціск дадзеных з'яўляецца тое,
які прыводзіць інавацый.

215
00:09:41,920 --> 00:09:44,610
І калі вы паглядзіце на больш
за апошнія пяць гадоў,

216
00:09:44,610 --> 00:09:48,180
гэта схема, якія менавіта дадзеныя
нагрузка па агульнай прадпрыемствы

217
00:09:48,180 --> 00:09:49,640
Падобна на тое, у апошнія пяць гадоў.

218
00:09:49,640 --> 00:09:52,570
>> І агульнае правіла
гэтыя days-- калі вы ідзяце Google--

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

220
00:09:55,290 --> 00:09:57,330
генеруецца на працягу апошніх двух гадоў.

221
00:09:57,330 --> 00:09:57,911
ДОБРА.

222
00:09:57,911 --> 00:09:59,410
Цяпер, гэта не тэндэнцыя, што новага.

223
00:09:59,410 --> 00:10:01,230
Гэта тэндэнцыя, якая была
выходзячы за 100 гадоў.

224
00:10:01,230 --> 00:10:03,438
З тых часоў, Холлерит
распрацавала перфакарты,

225
00:10:03,438 --> 00:10:08,040
мы будавалі сховішчы дадзеных
і збор дадзеных на фенаменальныя тэмпы.

226
00:10:08,040 --> 00:10:10,570
>> Так, за апошнія 100 гадоў,
мы бачылі гэтую тэндэнцыю.

227
00:10:10,570 --> 00:10:11,940
Гэта не збіраецца мяняць.

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

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

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

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

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

233
00:10:30,380 --> 00:10:31,200
І я ведаю, што гэта.

234
00:10:31,200 --> 00:10:33,292
Я працую з гэтымі прадпрыемствамі кожны дзень.

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

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

237
00:10:38,260 --> 00:10:39,700
І яны будуць гаварыць
мне пра тое, як мы бачым,

238
00:10:39,700 --> 00:10:41,825
што гэта, верагодна, будзе
быць петабайт ці два

239
00:10:41,825 --> 00:10:43,030
на працягу некалькіх гадоў.

240
00:10:43,030 --> 00:10:45,170
>> Гэтыя ж кампаніі
сёння я сустракаюся з,

241
00:10:45,170 --> 00:10:48,100
і яны кажуць мне пра
Праблема ці ёсць які мае кіраванне

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

243
00:10:51,440 --> 00:10:53,590
Так выбух
Дадзеныя ў прамысловасці

244
00:10:53,590 --> 00:10:56,670
вядзе велізарная
патрэба ў больш дасканалых рашэнняў.

245
00:10:56,670 --> 00:11:00,980
І рэляцыйная база дадзеных з'яўляецца
проста не жыць да попыту.

246
00:11:00,980 --> 00:11:03,490
>> І так ёсць лінейны
Карэляцыя паміж ціскам дадзеных

247
00:11:03,490 --> 00:11:05,210
і тэхнічныя інавацыі.

248
00:11:05,210 --> 00:11:07,780
Гісторыя паказвае нам,
гэта, што з цягам часу,

249
00:11:07,780 --> 00:11:11,090
кожны раз, калі аб'ём дадзеных
які павінен быць апрацаваны

250
00:11:11,090 --> 00:11:15,490
перавышае прапускную здольнасць сістэмы
апрацаваць яго ў разумныя тэрміны

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

252
00:11:18,870 --> 00:11:21,080
вынайдзены, каб вырашыць гэтыя праблемы.

253
00:11:21,080 --> 00:11:24,090
Гэтыя новыя тэхналогіі,
у сваю чаргу, адкрыць дзверы

254
00:11:24,090 --> 00:11:27,840
на іншы набор праблем, які
збірае яшчэ больш дадзеных.

255
00:11:27,840 --> 00:11:29,520
>> Зараз, мы не збіраемся спыняцца на гэтым.

256
00:11:29,520 --> 00:11:30,020
Дакладна?

257
00:11:30,020 --> 00:11:31,228
Мы не збіраемся спыняцца на гэтым.

258
00:11:31,228 --> 00:11:31,830
Чаму?

259
00:11:31,830 --> 00:11:35,520
Таму што вы не можаце ведаць усё
што трэба ведаць ва Сусвету.

260
00:11:35,520 --> 00:11:40,510
І да таго часу, як мы былі жывыя,
на працягу ўсёй гісторыі чалавека,

261
00:11:40,510 --> 00:11:43,440
мы заўсёды вымушаныя ведаць больш.

262
00:11:43,440 --> 00:11:49,840
>> Так здаецца, што кожны цаля мы рухаемся
па шляху навуковага адкрыцця,

263
00:11:49,840 --> 00:11:54,620
мы множання колькасці дадзеных
што мы павінны апрацаваць па экспаненце

264
00:11:54,620 --> 00:11:59,920
як мы раскрыць больш і больш і больш
аб унутраных жыцця,

265
00:11:59,920 --> 00:12:04,530
пра тое, як працуе Сусвет, пра
кіраванне навуковае адкрыццё,

266
00:12:04,530 --> 00:12:06,440
і вынаходніцтва, што
мы робім сёння.

267
00:12:06,440 --> 00:12:09,570
Аб'ём дадзеных, проста
пастаянна павялічваецца.

268
00:12:09,570 --> 00:12:12,120
Так будучы ў стане мець справу з
Гэтая праблема велізарная.

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

270
00:12:14,790 --> 00:12:17,410
>> Так адна з рэчаў,
мы глядзім, як, чаму NoSQL?

271
00:12:17,410 --> 00:12:19,200
Як NoSQL вырашыць гэтую праблему?

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

273
00:12:24,980 --> 00:12:28,600
SQL--, што гэта сапраўды канструкцыя з
рэляцыйная database-- гэтыя рэчы

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

275
00:12:30,770 --> 00:12:33,180
>> Таму ў 70-я гады, зноў жа,
Дыск каштуе дорага.

276
00:12:33,180 --> 00:12:36,990
Аб падрыхтоўцы практыкаванні захоўвання
на прадпрыемстве ніколі не сканчаецца.

277
00:12:36,990 --> 00:12:37,490
Я ведаю.

278
00:12:37,490 --> 00:12:38,020
Я жыў яго.

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

280
00:12:41,250 --> 00:12:42,470
таму ў 90-ых.

281
00:12:42,470 --> 00:12:45,920
І ніжняя лінія стэлажы іншы
Масіў захоўвання дадзеных была толькі тое, што

282
00:12:45,920 --> 00:12:47,600
адбылося кожны дзень на прадпрыемстве.

283
00:12:47,600 --> 00:12:49,030
І гэта ніколі не спыніўся.

284
00:12:49,030 --> 00:12:52,690
Вышэйшую захоўвання шчыльнасць, попыт
за вялікай шчыльнасці захоўвання,

285
00:12:52,690 --> 00:12:56,340
і для больш эфектыўнага захоўвання
devices-- гэта ніколі не спыніўся.

286
00:12:56,340 --> 00:13:00,160
>> І NoSQL гэта выдатны тэхналогія
таму што ён нармалізуе дадзеныя.

287
00:13:00,160 --> 00:13:02,210
Гэта дэ-дублюе дадзеныя.

288
00:13:02,210 --> 00:13:07,180
Гэта змяшчае дадзеныя ў структуру, якая
агностыку кожнаму мадэль доступу.

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

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

291
00:13:15,950 --> 00:13:17,570
Гэта гучыць фантастычна.

292
00:13:17,570 --> 00:13:21,350
Але сутнасць у тым, з якой-небудзь
Сістэма, калі гэта агностыку, каб усе,

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

294
00:13:23,500 --> 00:13:24,050
ДОБРА?

295
00:13:24,050 --> 00:13:26,386
>> І гэта тое, што мы атрымліваем з
рэляцыйная база дадзеных.

296
00:13:26,386 --> 00:13:27,510
Ён аптымізаваны для захоўвання.

297
00:13:27,510 --> 00:13:28,280
Гэта нармалізуецца.

298
00:13:28,280 --> 00:13:29,370
Гэта рэляцыйная.

299
00:13:29,370 --> 00:13:31,660
Ён падтрымлівае спецыяльныя запыты.

300
00:13:31,660 --> 00:13:34,000
І яго і маштабуецца яго па вертыкалі.

301
00:13:34,000 --> 00:13:39,030
>> Калі мне трэба, каб атрымаць вялікую базу дадзеных SQL
або больш магутны SQL базы дадзеных,

302
00:13:39,030 --> 00:13:41,090
Я іду купіць большы кавалак жалеза.

303
00:13:41,090 --> 00:13:41,600
ДОБРА?

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

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

306
00:13:48,340 --> 00:13:49,750
яны зноў вы ўдару ў сцяну.

307
00:13:49,750 --> 00:13:55,457
І адказ ад Oracle або MSSQL
ці хто-небудзь яшчэ, гэта атрымаць больш акно.

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

309
00:13:58,540 --> 00:14:00,080
Мы павінны на самай справе нешта змяніць.

310
00:14:00,080 --> 00:14:01,080
Дык дзе ж гэта працуе?

311
00:14:01,080 --> 00:14:06,560
Ён добра працуе ў аўтаномным
аналітыка, нагрузкі OLAP-тыпу.

312
00:14:06,560 --> 00:14:08,670
І гэта сапраўды, дзе SQL належыць.

313
00:14:08,670 --> 00:14:12,540
Цяпер, ён выкарыстоўваецца сёння ў многіх онлайн
апрацоўку транзакцый тыпу

314
00:14:12,540 --> 00:14:13,330
прыкладання.

315
00:14:13,330 --> 00:14:16,460
І гэта выдатна працуе на
пэўны ўзровень ўтылізацыі,

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

317
00:14:18,670 --> 00:14:20,660
І мы будзем казаць трохі
крыху аб тым, чаму, што ёсць.

318
00:14:20,660 --> 00:14:23,590
>> Цяпер, NoSQL, з другога боку,
больш аптымізаваны для вылічэнняў.

319
00:14:23,590 --> 00:14:24,540
ДОБРА?

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

321
00:14:26,830 --> 00:14:31,620
Гэта тое, што мы называем дэ-нармалізуецца
структура або іерархічную структуру.

322
00:14:31,620 --> 00:14:35,000
Дадзеныя ў рэляцыйнай базе дадзеных
аб'ядналіся з некалькімі сталамі

323
00:14:35,000 --> 00:14:36,850
вырабляць выгляд, што вам трэба.

324
00:14:36,850 --> 00:14:40,090
Дадзеныя ў базе дадзеных NoSQL ў
захоўваецца ў дакуменце, які

325
00:14:40,090 --> 00:14:42,100
змяшчае іерархічную структуру.

326
00:14:42,100 --> 00:14:45,670
Усе дадзеныя, якія звычайна
аб'ядналіся, каб вырабіць гэтую пункт гледжання

327
00:14:45,670 --> 00:14:47,160
захоўваюцца ў адным дакуменце.

328
00:14:47,160 --> 00:14:50,990
І мы будзем казаць крыху пра
як гэта працуе ў пары графікаў.

329
00:14:50,990 --> 00:14:55,320
>> Але ідэя тут у тым, што вы захоўваеце
Вашы дадзеныя як гэтыя асобнікі выглядам.

330
00:14:55,320 --> 00:14:56,410
ДОБРА?

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

332
00:14:58,610 --> 00:14:59,556
Дакладна?

333
00:14:59,556 --> 00:15:02,100
Калі мне трэба павялічыць
Памер майго NoSQL кластара,

334
00:15:02,100 --> 00:15:03,700
Мне не трэба, каб атрымаць вялікую скрынку.

335
00:15:03,700 --> 00:15:05,200
Я атрымліваю яшчэ адну скрынку.

336
00:15:05,200 --> 00:15:07,700
І я іх разам кластар,
і я магу Шардэн гэтыя дадзеныя.

337
00:15:07,700 --> 00:15:10,780
Мы пагаворым крыху пра
тое, што Sharding ёсць, быць

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

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

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

341
00:15:22,080 --> 00:15:25,480
Там вялікая розніца
тут паміж справаздачнасці, праўда?

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

343
00:15:27,810 --> 00:15:28,310
Дакладна?

344
00:15:28,310 --> 00:15:30,570
Reporting-- калі хтосьці з
мой аддзел маркетынгу

345
00:15:30,570 --> 00:15:34,520
хоча просто-- колькі з маіх кліентаў
ёсць гэтая канкрэтная характарыстыка, хто

346
00:15:34,520 --> 00:15:37,850
купіў у гэтым day-- я не ведаю
тое, што запыт яны збіраюцца спытаць.

347
00:15:37,850 --> 00:15:39,160
Таму мне трэба, каб быць агностыкам.

348
00:15:39,160 --> 00:15:41,810
>> Цяпер, у рэжыме онлайн
транзакцыйных прыкладанняў,

349
00:15:41,810 --> 00:15:43,820
Я ведаю, якія пытанні я пытаюся.

350
00:15:43,820 --> 00:15:46,581
Я пабудаваў прыкладанне для
вельмі спецыфічны працоўны працэс.

351
00:15:46,581 --> 00:15:47,080
ДОБРА?

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

353
00:15:50,540 --> 00:15:52,020
гэта будзе хутчэй.

354
00:15:52,020 --> 00:15:55,190
І вось чаму NoSQL можа
сапраўды паскорыць дастаўку

355
00:15:55,190 --> 00:15:57,710
з гэтых відаў паслуг.

356
00:15:57,710 --> 00:15:58,210
Добра.

357
00:15:58,210 --> 00:16:00,501
>> Такім чынам, мы збіраемся, каб патрапіць у
трохі тэорыі тут.

358
00:16:00,501 --> 00:16:03,330
І некаторыя з вас, вашы вочы
можа вярнуцца няшмат.

359
00:16:03,330 --> 00:16:06,936
Але я паспрабую, каб захаваць яго
таксама высокі ўзровень, як я магу.

360
00:16:06,936 --> 00:16:08,880
Так што, калі вы знаходзіцеся ў праекце
Кіраванне, ёсць

361
00:16:08,880 --> 00:16:12,280
канструкцыя называецца
трохкутнік абмежаванняў.

362
00:16:12,280 --> 00:16:12,936
ДОБРА.

363
00:16:12,936 --> 00:16:16,060
Трохкутнік абмяжоўвае дыктату
Вы не можаце мець усе ўвесь час.

364
00:16:16,060 --> 00:16:17,750
Не можаце мець свой пірог і з'есці яго занадта.

365
00:16:17,750 --> 00:16:22,310
Такім чынам, у кіраванні праектамі, што трохкутнік
абмежаванні, што вы можаце мець гэта танна,

366
00:16:22,310 --> 00:16:24,710
Вы можаце мець гэта хутка,
ці вы можаце мець яго добра.

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

368
00:16:25,716 --> 00:16:27,090
Таму што вы не можаце мець усе тры.

369
00:16:27,090 --> 00:16:27,460
Дакладна?

370
00:16:27,460 --> 00:16:27,820
ДОБРА.

371
00:16:27,820 --> 00:16:28,920
>> Такім чынам, вы чуеце пра гэта шмат.

372
00:16:28,920 --> 00:16:31,253
Гэта патройны абмежаванне,
трохкутнік патройны абмежаванні,

373
00:16:31,253 --> 00:16:34,420
або жалезны трыкутнік з'яўляецца oftentimes--
калі вы кажаце з мэнэджэрамі праекта,

374
00:16:34,420 --> 00:16:35,420
яны будуць гаварыць пра гэта.

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

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

377
00:16:40,350 --> 00:16:41,580
ДОБРА?

378
00:16:41,580 --> 00:16:43,770
>> Тэарэма CAP дыктуе
як базы дадзеных працуюць

379
00:16:43,770 --> 00:16:45,627
пад вельмі спецыфічных умовах.

380
00:16:45,627 --> 00:16:47,460
І мы будзем казаць аб
што гэта ўмова.

381
00:16:47,460 --> 00:16:52,221
Але тры пункту трыкутніка,
так бы мовіць, з'яўляюцца З, кансістэнцыя.

382
00:16:52,221 --> 00:16:52,720
ДОБРА?

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

384
00:16:56,760 --> 00:16:59,084
заўсёды будзе мець вельмі
адпавядае прадстаўленне даных.

385
00:16:59,084 --> 00:17:00,750
Ніхто не збіраецца ўбачыць дзве розныя рэчы.

386
00:17:00,750 --> 00:17:01,480
ДОБРА?

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

388
00:17:04,020 --> 00:17:06,130
як мой партнёр, які бачыць
тую ж базу дадзеных.

389
00:17:06,130 --> 00:17:07,470
Вось паслядоўнасць.

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

391
00:17:12,099 --> 00:17:14,760
што ўсе кліенты будуць заўсёды
умець чытаць і пісаць.

392
00:17:14,760 --> 00:17:15,260
ДОБРА?

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

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

395
00:17:18,955 --> 00:17:21,819
І калі гэта так,
гэта даступны сістэма.

396
00:17:21,819 --> 00:17:24,230
>> І трэці пункт, што
мы называем памяркоўнасці раздзелаў.

397
00:17:24,230 --> 00:17:24,730
ДОБРА?

398
00:17:24,730 --> 00:17:28,160
Азначае памяркоўнасць раздзел
што сістэма працуе добра

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

400
00:17:32,000 --> 00:17:32,760
ДОБРА?

401
00:17:32,760 --> 00:17:36,270
Так вузлы ў кластары не можа
казаць адзін з адным, што адбываецца?

402
00:17:36,270 --> 00:17:36,880
Добра.

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

404
00:17:39,545 --> 00:17:40,045
ДОБРА.

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

406
00:17:43,680 --> 00:17:47,510
Калі падзел адбываецца паміж
ў вузлы DataNode ў сховішча дадзеных,

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

408
00:17:48,831 --> 00:17:49,330
Дакладна?

409
00:17:49,330 --> 00:17:50,900
Гэта проста ідзе ўніз.

410
00:17:50,900 --> 00:17:51,450
ДОБРА.

411
00:17:51,450 --> 00:17:54,230
>> І вось чаму яны маюць
расці з вялікімі скрынямі.

412
00:17:54,230 --> 00:17:54,730
Дакладна?

413
00:17:54,730 --> 00:17:58,021
Таму што, як правіла, no--, кластар
базы дадзеных, ёсць не вельмі многія з іх

414
00:17:58,021 --> 00:17:59,590
якія працуюць такім чынам.

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

416
00:18:03,019 --> 00:18:05,060
Таму што яны павінны быць
паслядоўнай і даступны.

417
00:18:05,060 --> 00:18:10,320
Калі раздзел былі быць уведзены,
то вам давядзецца зрабіць выбар.

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

419
00:18:13,720 --> 00:18:16,080
>> І гэта тое, што робяць базы дадзеных NoSQL.

420
00:18:16,080 --> 00:18:16,580
Добра.

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

422
00:18:20,950 --> 00:18:22,990
Мы have-- добра, гэта
прыходзіць у шматлікіх разнавіднасцях,

423
00:18:22,990 --> 00:18:26,140
але ён прыходзіць з двума асноўнымі
characteristics-- што

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

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

426
00:18:31,040 --> 00:18:34,930
Гэтыя хлопцы робяць выбар, што, калі
вузлы губляюць кантакт адзін з адным,

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

428
00:18:37,091 --> 00:18:37,590
ДОБРА?

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

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

431
00:18:43,230 --> 00:18:44,510
Яны паслядоўныя.

432
00:18:44,510 --> 00:18:46,554
Калі мы бачым, што
раздзел надаць сабе,

433
00:18:46,554 --> 00:18:48,470
мы зараз адпавядае,
таму што мы не збіраемся

434
00:18:48,470 --> 00:18:51,517
каб змены дадзеных на два
боку перагародкі самастойна

435
00:18:51,517 --> 00:18:52,100
адзін ад аднаго.

436
00:18:52,100 --> 00:18:54,130
Мы павінны
аднавіць сувязь

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

438
00:18:56,930 --> 00:18:58,120
ДОБРА?

439
00:18:58,120 --> 00:19:02,650
>> На наступны водар будзе сістэма А.П.,
ці даступны і размяркоўваюць

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

441
00:19:03,640 --> 00:19:05,320
Гэтыя хлопцы не хвалюе.

442
00:19:05,320 --> 00:19:06,020
Дакладна?

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

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

445
00:19:11,480 --> 00:19:14,730
Гэтыя вузлы атрымаць кліент, кліент прыходзіць
у, кажа, што я збіраюся напісаць некаторыя дадзеныя.

446
00:19:14,730 --> 00:19:16,300
Вузел не гаворыць, не праблема.

447
00:19:16,300 --> 00:19:18,580
Вузел побач з ім атрымлівае
ад запісу на той жа запісу,

448
00:19:18,580 --> 00:19:20,405
ён збіраецца сказаць не праблема.

449
00:19:20,405 --> 00:19:23,030
Дзесьці на заднім канцы,
што дадзеныя збіраецца паўтарыць.

450
00:19:23,030 --> 00:19:27,360
А потым хто-то збіраецца рэалізаваць,
э-э-о, яны зразумеюць, сістэма, э-э-о,

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

452
00:19:28,870 --> 00:19:30,370
Што мы робім?

453
00:19:30,370 --> 00:19:33,210
І тое, што яны зрабіць, гэта
яны робяць тое, што

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

455
00:19:36,080 --> 00:19:39,000
І мы будзем казаць аб
што ў наступным графіку.

456
00:19:39,000 --> 00:19:40,000
>> Рэч, каб адзначыць тут.

457
00:19:40,000 --> 00:19:42,374
І я не збіраюся занадта
шмат у гэтым, таму што гэта

458
00:19:42,374 --> 00:19:43,510
трапляе ў глыбокай тэорыі дадзеных.

459
00:19:43,510 --> 00:19:46,670
Але ёсць транзакцый
рамкі,

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

461
00:19:50,680 --> 00:19:53,760
некалькім суб'ектам ў базе дадзеных.

462
00:19:53,760 --> 00:19:58,320
І гэтыя абнаўлення будуць адбывацца
ўсё адразу ці не на ўсіх.

463
00:19:58,320 --> 00:20:00,500
І гэта называецца ACID транзакцый.

464
00:20:00,500 --> 00:20:01,000
ДОБРА?

465
00:20:01,000 --> 00:20:06,570
>> Кіслата дае нам атамарнага, ўзгодненасць,
ізаляцыя і даўгавечнасць.

466
00:20:06,570 --> 00:20:07,070
ДОБРА?

467
00:20:07,070 --> 00:20:13,550
Гэта азначае, што атамныя, здзелкі, усё
мае абнаўлення альбо здарыцца, альбо няма.

468
00:20:13,550 --> 00:20:16,570
Ўзгодненасць азначае, што
База дадзеных будзе заўсёды

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

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

471
00:20:23,900 --> 00:20:24,400
ДОБРА?

472
00:20:24,400 --> 00:20:26,720
>> Так што гэта крыху адрозніваецца
чым кансістэнцыі CAP.

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

474
00:20:29,760 --> 00:20:34,450
Кіслата ўзгодненасць азначае, што, калі
здзелка будзе зроблена, дадзеныя добра.

475
00:20:34,450 --> 00:20:35,709
Мае адносіны ўсё добра.

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

477
00:20:38,750 --> 00:20:40,970
У нейкай іншай табліцы.

478
00:20:40,970 --> 00:20:44,320
Гэта не можа адбыцца, калі я стасуюцца
у кіслай аперацыі.

479
00:20:44,320 --> 00:20:49,120
>> Ізаляцыя азначае, што здзелкі
заўсёды будзе адбывацца адзін за адным.

480
00:20:49,120 --> 00:20:51,920
Канчатковым вынікам дадзеных
будзе тое ж самае стан

481
00:20:51,920 --> 00:20:54,770
а калі гэтых здзелак
якія былі выпушчаныя адначасова

482
00:20:54,770 --> 00:20:57,340
былі выкананы паслядоўна.

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

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

485
00:21:04,130 --> 00:21:08,580
>> Але калі я кажу дадаць 1 да гэтага значэння,
і дзве здзелкі прыходзяць у

486
00:21:08,580 --> 00:21:10,665
і паспрабаваць зрабіць гэта, адзін гэта
збіраецца атрымаць там першым

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

488
00:21:12,540 --> 00:21:15,210
Такім чынам, у рэшце рэшт, я дадаў два.

489
00:21:15,210 --> 00:21:16,170
Вы бачыце, што я маю на ўвазе?

490
00:21:16,170 --> 00:21:16,670
ДОБРА.

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

492
00:21:19,220 --> 00:21:21,250
>> Трываласць даволі простая.

493
00:21:21,250 --> 00:21:23,460
Калі здзелка
прызнаецца, што гэта

494
00:21:23,460 --> 00:21:26,100
будзе там, нават
калі збой сістэмы.

495
00:21:26,100 --> 00:21:29,230
Пры тым, што сістэма аднаўляецца, што
здзелка, было здзейснена

496
00:21:29,230 --> 00:21:30,480
на самай справе адбываецца, каб быць там.

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

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

499
00:21:35,470 --> 00:21:36,870
але яны прыходзяць на той кошту.

500
00:21:36,870 --> 00:21:37,640
Дакладна?

501
00:21:37,640 --> 00:21:40,520
>> Таму што праблемы
з гэтым база

502
00:21:40,520 --> 00:21:44,540
калі існуе разбіццё дадзеных у
набор, я павінен прыняць рашэнне.

503
00:21:44,540 --> 00:21:48,000
Я збіраюся мець, каб
Абнаўлення на адной або іншага боку.

504
00:21:48,000 --> 00:21:50,310
І калі гэта адбудзецца,
а то я не збіраюся больш

505
00:21:50,310 --> 00:21:52,630
каб быць у стане падтрымліваць
гэтыя характарыстыкі.

506
00:21:52,630 --> 00:21:53,960
Яны не будуць адпавядаць.

507
00:21:53,960 --> 00:21:55,841
Яны не будуць ізаляваныя.

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

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

510
00:22:01,360 --> 00:22:05,530
>> З іншага боку, мы маем
тое, што называецца тэхналагічная база.

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

512
00:22:07,291 --> 00:22:07,790
Добра.

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

514
00:22:10,180 --> 00:22:14,720
І гэта тое, што вы называеце асноўным
даступныя, мяккі дзяржава, у канчатковым рахунку,

515
00:22:14,720 --> 00:22:15,740
паслядоўным.

516
00:22:15,740 --> 00:22:16,420
ДОБРА?

517
00:22:16,420 --> 00:22:19,690
>> У асноўным даступныя, таму што
яны раздзел памяркоўна.

518
00:22:19,690 --> 00:22:21,470
Яны заўсёды будуць
там, нават калі ёсць

519
00:22:21,470 --> 00:22:23,053
падзелу сеткі паміж вузламі.

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

521
00:22:25,900 --> 00:22:26,460
ДОБРА?

522
00:22:26,460 --> 00:22:30,810
Я не заўсёды можа быць у стане напісаць
дадзеных, калі я адзінай платформы.

523
00:22:30,810 --> 00:22:32,130
Але я буду ў стане прачытаць дадзеныя.

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

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

526
00:22:38,010 --> 00:22:40,790
яна не можа быць такі ж, як іншыя вузлы.

527
00:22:40,790 --> 00:22:43,390
Калі права было выдадзена на вузле
дзесьці ў кластары

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

529
00:22:46,650 --> 00:22:48,680
што дзяржава не можа быць паслядоўным.

530
00:22:48,680 --> 00:22:51,650
Тым не менш, ён будзе
у рэшце рэшт паслядоўным,

531
00:22:51,650 --> 00:22:53,870
Гэта азначае, што, калі запісу
зроблены да сістэмы,

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

533
00:22:56,480 --> 00:22:59,095
І ў рэшце рэшт, што дзяржава
будуць прыведзены ў парадак,

534
00:22:59,095 --> 00:23:00,890
і гэта будзе адпавядаць стан.

535
00:23:00,890 --> 00:23:05,000
>> Цяпер, тэарэма CAP сапраўды
гуляе толькі ў адным стане.

536
00:23:05,000 --> 00:23:08,700
Гэта ўмова, калі гэта адбудзецца.

537
00:23:08,700 --> 00:23:13,710
Таму што кожны раз, калі ён працуе ў
нармальны рэжым, няма падзелу,

538
00:23:13,710 --> 00:23:16,370
усё ў паслядоўнай і даступныя.

539
00:23:16,370 --> 00:23:19,990
Вы толькі турбавацца аб CAP
калі ў нас ёсць гэты раздзел.

540
00:23:19,990 --> 00:23:21,260
Так што тыя, рэдкія.

541
00:23:21,260 --> 00:23:25,360
Але, як сістэма рэагуе, калі тыя
адбываюцца дыктаваць, які тып сістэмы

542
00:23:25,360 --> 00:23:26,750
мы маем справу з.

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

544
00:23:31,110 --> 00:23:32,621
ДОБРА?

545
00:23:32,621 --> 00:23:34,830
Сістэмы AP бываюць двух відаў.

546
00:23:34,830 --> 00:23:38,514
Яны прыходзяць ў водары, які з'яўляецца
Майстар, 100%, заўсёды даступныя.

547
00:23:38,514 --> 00:23:40,430
І яны прыходзяць у
іншы водар, які кажа

548
00:23:40,430 --> 00:23:43,330
Вы ведаеце, што я збіраюся турбавацца
пра гэта раздзелаў рэчы

549
00:23:43,330 --> 00:23:44,724
калі фактычны падзел адбываецца.

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

551
00:23:47,890 --> 00:23:48,500
ДОБРА?

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

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

554
00:23:54,440 --> 00:23:55,540
Дык што ж адбываецца?

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

556
00:23:58,270 --> 00:24:01,705
Назавем гэты аб'ект S.
Такім чынам, мы маем стан для S.

557
00:24:01,705 --> 00:24:04,312
У нас ёсць некаторыя аперацыі
на S, што працягваюцца.

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

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

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

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

562
00:24:14,190 --> 00:24:15,950
Але з-за дызайну
сістэмы, гэта

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

564
00:24:18,449 --> 00:24:20,830
Гэта не прымушае мяне
напісаць усё праз адзін вузел.

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

566
00:24:22,340 --> 00:24:23,330
ДОБРА?

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

568
00:24:25,740 --> 00:24:26,360
ДОБРА?

569
00:24:26,360 --> 00:24:28,110
Што адбудзецца
рана ці позна,

570
00:24:28,110 --> 00:24:29,960
там будзе падзея рэплікацыі.

571
00:24:29,960 --> 00:24:33,300
Там будзе тое, што мы
называецца раздзел аднаўлення, які

572
00:24:33,300 --> 00:24:35,200
дзе гэтыя два
дзяржавы вярнуцца разам

573
00:24:35,200 --> 00:24:37,310
і там будзе алгарытм
які працуе ў базе дадзеных,

574
00:24:37,310 --> 00:24:38,540
вырашае, што рабіць.

575
00:24:38,540 --> 00:24:39,110
ДОБРА?

576
00:24:39,110 --> 00:24:43,057
Па змаўчанні, апошняе абнаўленне
выйграе ў большасці сістэм AP.

577
00:24:43,057 --> 00:24:44,890
Так што, як правіла,
Алгарытм па змаўчанні, тое, што

578
00:24:44,890 --> 00:24:47,400
яны называюць функцыю зваротнага выкліку
Функцыя, тое, што

579
00:24:47,400 --> 00:24:51,000
будзе выклікацца, калі гэта ўмова
выяўлена выканаць некаторую логіку

580
00:24:51,000 --> 00:24:52,900
вырашыць, што канфлікту.

581
00:24:52,900 --> 00:24:53,850
ДОБРА?

582
00:24:53,850 --> 00:24:58,770
Зваротны выклік па змаўчанні і па змаўчанні
распознаватель ў большасці баз дадзеных AP

583
00:24:58,770 --> 00:25:01,130
гэта, думаю, што, пазнака выйграе.

584
00:25:01,130 --> 00:25:02,380
Гэта было апошняе абнаўленне.

585
00:25:02,380 --> 00:25:04,320
Я збіраюся паставіць гэта абнаўленне там.

586
00:25:04,320 --> 00:25:08,440
Я магу скінуць гэты запіс, што я
скідалі прэч ў часопісе аднаўлення

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

588
00:25:11,670 --> 00:25:12,320
Што здарылася?

589
00:25:12,320 --> 00:25:16,370
І вы можаце скінуць запіс
усе сутыкнення і адкаты

590
00:25:16,370 --> 00:25:17,550
і паглядзець, што адбываецца.

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

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

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

594
00:25:26,730 --> 00:25:28,880
І я хачу, каб паспрабаваць
аб'яднаць гэтыя два запісы.

595
00:25:28,880 --> 00:25:30,050
Але гэта да вас.

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

597
00:25:32,880 --> 00:25:34,850
адзінае, што базы дадзеных
ведае, як зрабіць, гэта сказаць,

598
00:25:34,850 --> 00:25:36,100
гэты быў апошні альбом.

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

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

601
00:25:41,490 --> 00:25:43,930
у нас ёсць дзяржава, якое
Цяпер S прэм'ер, які з'яўляецца

602
00:25:43,930 --> 00:25:46,890
зліццё стан усіх гэтых аб'ектаў.

603
00:25:46,890 --> 00:25:49,700
Так сістэмы AP ёсць гэта.

604
00:25:49,700 --> 00:25:51,615
Сістэмы CP ня трэба
каб турбавацца пра гэта.

605
00:25:51,615 --> 00:25:54,490
Таму што як толькі прыходзіць раздзел
у гульню, яны проста перастаць прымаць

606
00:25:54,490 --> 00:25:55,530
піша.

607
00:25:55,530 --> 00:25:56,180
ДОБРА?

608
00:25:56,180 --> 00:25:58,670
Так што гэта вельмі лёгка
справу з быць паслядоўным

609
00:25:58,670 --> 00:26:01,330
калі вы не прымаць якія-небудзь абнаўлення.

610
00:26:01,330 --> 00:26:04,620
Вось з сістэмамі CP зрабіць.

611
00:26:04,620 --> 00:26:05,120
Добра.

612
00:26:05,120 --> 00:26:07,590
>> Такім чынам, давайце трохі пагаворым
трохі пра мадэлі доступу.

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

614
00:26:11,580 --> 00:26:13,550
Цяпер, у SQL ёсць спецыяльная запыты.

615
00:26:13,550 --> 00:26:14,481
Гэта рэляцыйнае сховішча.

616
00:26:14,481 --> 00:26:16,480
Мы не павінны хвалявацца
аб мадэлі доступу.

617
00:26:16,480 --> 00:26:17,688
Я пішу вельмі складаны запыт.

618
00:26:17,688 --> 00:26:19,250
Гэта ідзе і атрымлівае дадзеныя.

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

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

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

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

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

624
00:26:27,800 --> 00:26:30,090
У мяне ёсць відэа.

625
00:26:30,090 --> 00:26:33,370
Адносіны паміж прадуктамі
і любы з гэтых кніг, альбомаў,

626
00:26:33,370 --> 00:26:34,860
і відэа сталы 1: 1.

627
00:26:34,860 --> 00:26:35,800
Усё ў парадку?

628
00:26:35,800 --> 00:26:38,860
Я атрымаў код прадукту,
і што адпавядае ID

629
00:26:38,860 --> 00:26:41,080
у кнізе, альбом або відэа.

630
00:26:41,080 --> 00:26:41,580
ДОБРА?

631
00:26:41,580 --> 00:26:44,350
Гэта стаўленне 1: 1
па гэтых табліцах.

632
00:26:44,350 --> 00:26:46,970
>> Цяпер, усе яны books--
ёсць, корань ўласцівасці.

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

634
00:26:47,550 --> 00:26:48,230
Гэта цудоўна.

635
00:26:48,230 --> 00:26:52,130
Адзін-да-аднаму адносіны, я ўсё
дадзеныя мне трэба, каб апісаць гэтую кнігу.

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

637
00:26:54,770 --> 00:26:56,470
Гэта тое, што мы называем адзін да многіх.

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

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

640
00:27:00,780 --> 00:27:02,570
яшчэ адзін рэкорд у гэтай даччынай табліцы.

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

642
00:27:04,680 --> 00:27:06,700
Я ствараю некалькі запісаў
у табліцы трэкаў.

643
00:27:06,700 --> 00:27:08,850
Адзін-да-шматлікім.

644
00:27:08,850 --> 00:27:11,220
>> Гэта суадносіны з'яўляецца тое, што
мы называем многія-да-шматлікім.

645
00:27:11,220 --> 00:27:11,750
ДОБРА?

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

647
00:27:17,000 --> 00:27:21,450
Так што мы робім, мы ставім гэта адлюстраванне
Табліца паміж тымі, якія ён проста

648
00:27:21,450 --> 00:27:24,040
адлюстроўвае акцёр ідэнтыфікатар відэа ID.

649
00:27:24,040 --> 00:27:28,464
Цяпер я магу стварыць запыт да злучае
відэа праз акцёра відэа на акцёраў,

650
00:27:28,464 --> 00:27:31,130
і гэта дае мне добры спіс
усе фільмы і ўсе акцёры

651
00:27:31,130 --> 00:27:32,420
якія былі ў гэтым фільме.

652
00:27:32,420 --> 00:27:33,290
>> ДОБРА.

653
00:27:33,290 --> 00:27:33,880
Дык вось мы ідзем.

654
00:27:33,880 --> 00:27:38,040
Адзін-да-аднаму гэта топ-ўзровень
адносіны; адзін-да-шматлікім,

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

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

657
00:27:44,990 --> 00:27:48,050
Калі вы ведаеце, як тыя,
адносіны працаваць разам,

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

659
00:27:51,490 --> 00:27:55,660
Так NoSQL працуе крыху па-іншаму.

660
00:27:55,660 --> 00:27:58,930
Давайце думаць аб на секунду, што гэта
Падобна на тое, пайсці атрымаць усе мае прадукты.

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

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

663
00:28:02,970 --> 00:28:04,910
Гэта шмат запытаў.

664
00:28:04,910 --> 00:28:07,030
Я атрымаў запыт для ўсіх маіх кніг.

665
00:28:07,030 --> 00:28:08,470
Я атрымаў запыт ад маіх альбомаў.

666
00:28:08,470 --> 00:28:09,970
І я атрымаў запыт для ўсіх маіх відэа.

667
00:28:09,970 --> 00:28:11,719
І я атрымаў паставіць яго
ўсе разам у спісе

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

669
00:28:15,250 --> 00:28:18,000
>> Каб атрымаць мае кнігі, я далучаюся
Прадукты і кніг.

670
00:28:18,000 --> 00:28:21,680
Каб атрымаць мае альбомы, мяне далучыцца
Прадукты, Альбомы, і трэкі.

671
00:28:21,680 --> 00:28:25,330
І каб мае відэа, у мяне ёсць
далучыцца да відэа прадукты,

672
00:28:25,330 --> 00:28:28,890
далучыцца праз Акцёр відэа,
і прынесці ў Акцёры.

673
00:28:28,890 --> 00:28:31,020
Дык вось тры запыту.

674
00:28:31,020 --> 00:28:34,560
Вельмі складаныя запыты да
сабраць адзін выніковы набор.

675
00:28:34,560 --> 00:28:36,540
>> Гэта менш, чым аптымальная.

676
00:28:36,540 --> 00:28:39,200
Вось чаму, калі мы гаворым
аб структуры дадзеных, што гэта

677
00:28:39,200 --> 00:28:42,900
пабудаваны, каб быць незалежным ад доступу
pattern-- добра, што гэта выдатна.

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

679
00:28:45,730 --> 00:28:46,550
І вы ведаеце, што?

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

681
00:28:49,750 --> 00:28:50,440
>> Гэта крута.

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

683
00:28:53,750 --> 00:28:55,200
У гэтай табліцы адлюстравання.

684
00:28:55,200 --> 00:29:00,620
Аднак, атрыманне дадзеных
па-за становіцца даражэй.

685
00:29:00,620 --> 00:29:04,500
Я пасылаю працэсар ўсёй сістэме
які злучае гэтыя структуры дадзеных разам

686
00:29:04,500 --> 00:29:05,950
каб быць у стане ажыццявіць гэта назад дадзеных.

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

688
00:29:07,310 --> 00:29:11,200
У NoSQL гэта пра
агрэгацыі, ня нармалізацыя.

689
00:29:11,200 --> 00:29:13,534
Такім чынам, мы хочам сказаць, што мы хочам
падтрымкі доступу да файла.

690
00:29:13,534 --> 00:29:15,283
Калі мадэль доступу
да прыкладанняў,

691
00:29:15,283 --> 00:29:16,770
Мне трэба, каб атрымаць усе мае прадукты.

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

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

694
00:29:22,110 --> 00:29:23,850
з гэтай табліцы, і я атрымліваю ўсё гэта.

695
00:29:23,850 --> 00:29:25,240
Ну, як я магу гэта зрабіць?

696
00:29:25,240 --> 00:29:28,124
Ну ў NoSQL няма ніякага
Структура да стала.

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

698
00:29:30,540 --> 00:29:33,570
Але вы не павінны тое ж самае
атрыбуты і тыя ж ўласцівасці

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

700
00:29:37,751 --> 00:29:39,750
І тое, што гэта дазваляе мне
зрабіць шмат рэчаў,

701
00:29:39,750 --> 00:29:41,124
і даць мне шмат гнуткасці.

702
00:29:41,124 --> 00:29:45,360
У дадзеным канкрэтным выпадку, я
мае дакументы прадукту.

703
00:29:45,360 --> 00:29:49,090
І ў гэтым канкрэтным
Напрыклад, усе

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

705
00:29:51,930 --> 00:29:56,510
І прадукт для кнігі можа
ёсць тып ID, які вызначае кнігу.

706
00:29:56,510 --> 00:29:59,180
І прымяненне
хацеў бы перайсці на той ID.

707
00:29:59,180 --> 00:30:02,570
>> У ўзроўні прыкладанняў, я збіраюся
сказаць ах, які тып запісу гэта?

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

709
00:30:04,100 --> 00:30:05,990
Забранірую запісу маюць гэтыя ўласцівасці.

710
00:30:05,990 --> 00:30:08,100
Дазвольце мне стварыць аб'ект кнігі.

711
00:30:08,100 --> 00:30:11,289
Так што я збіраюся, каб запоўніць
Кніга аб'ект з гэтым пунктам.

712
00:30:11,289 --> 00:30:13,080
Наступны тавар прыходзіць і
кажа, што гэты пункт?

713
00:30:13,080 --> 00:30:14,560
Ну гэты элемент з'яўляецца альбом.

714
00:30:14,560 --> 00:30:17,340
О, я атрымаў зусім іншы
працэдуры апрацоўкі для таго,

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

716
00:30:18,487 --> 00:30:19,320
Вы бачыце, што я маю на ўвазе?

717
00:30:19,320 --> 00:30:21,950
>> Такім чынам, прымяненне tier-- я
проста вылучыце ўсе гэтыя запісы.

718
00:30:21,950 --> 00:30:23,200
Яны ўсе пачынаюць прыходзіць у.

719
00:30:23,200 --> 00:30:24,680
Яны могуць быць усе розныя тыпы.

720
00:30:24,680 --> 00:30:27,590
І гэта логіка прыкладання
які перамыкаецца паміж гэтымі тыпамі

721
00:30:27,590 --> 00:30:29,530
і вырашае, як іх апрацаваць.

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

723
00:30:33,640 --> 00:30:36,390
Мы робім гэта з дапамогай
бурыцца гэтыя табліцы.

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

725
00:30:39,670 --> 00:30:42,000
і мы будуем
іерархічныя структуры.

726
00:30:42,000 --> 00:30:45,130
Унутры кожнага з гэтых запісаў
Я збіраюся праглядзець ўласцівасці масіва.

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

728
00:30:49,400 --> 00:30:53,900
Гэтыя трэкі Цяпер become-- гэта
у асноўным гэта дзіця табліца,

729
00:30:53,900 --> 00:30:56,520
існуе прама тут, у гэтай структуры.

730
00:30:56,520 --> 00:30:57,975
Такім чынам, вы можаце зрабіць гэта ў DynamoDB.

731
00:30:57,975 --> 00:30:59,810
Вы можаце зрабіць гэта ў MongoDB.

732
00:30:59,810 --> 00:31:01,437
Вы можаце зрабіць гэта ў любы базе дадзеных NoSQL.

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

734
00:31:03,520 --> 00:31:07,120
якія дазваляюць вам атрымаць дадзеныя
вельмі хутка, таму што цяпер я

735
00:31:07,120 --> 00:31:08,537
не павінны адпавядаць.

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

737
00:31:11,620 --> 00:31:13,110
Я павінен адпавядаць гэтай схеме.

738
00:31:13,110 --> 00:31:18,060
Я павінен мець атрыбут ці таму
маёмасць, аб якой гаварылася ў дадзенай табліцы.

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

740
00:31:20,480 --> 00:31:21,910
Гэта не той выпадак у NoSQL.

741
00:31:21,910 --> 00:31:24,440
>> Я магу мець зусім розныя
ўласцівасці ў кожным дакуменце

742
00:31:24,440 --> 00:31:26,100
што я ўставіць у калекцыі.

743
00:31:26,100 --> 00:31:30,480
Такім чынам, вельмі магутны механізм.

744
00:31:30,480 --> 00:31:32,852
І гэта сапраўды, як вы
аптымізацыі сістэмы.

745
00:31:32,852 --> 00:31:35,310
Таму што цяпер замест запыту,
далучэння ўсе гэтыя табліцы

746
00:31:35,310 --> 00:31:39,160
і выкананне паўтузіна запытаў
адступіць дадзеныя мне трэба,

747
00:31:39,160 --> 00:31:40,890
Я выкананні аднаго запыту.

748
00:31:40,890 --> 00:31:43,010
І я ітэрацыі
па выніках устаноўленых.

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

750
00:31:46,512 --> 00:31:49,470
Я збіраюся роду выйсці бокам тут
і трохі пагаворым пра гэта.

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

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

753
00:31:55,660 --> 00:31:58,672
Але важна разумець,
таму што, калі мы паглядзім на вяршыні

754
00:31:58,672 --> 00:32:00,380
тут, на гэтым графіку,
тое, што мы глядзім на

755
00:32:00,380 --> 00:32:04,030
гэта тое, што мы называем
Тэхналогія падману крывой.

756
00:32:04,030 --> 00:32:06,121
І тое, што гэта азначае,
Новы матэрыял уступае ў гульню.

757
00:32:06,121 --> 00:32:07,120
Людзі думаюць, што гэта выдатна.

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

759
00:32:09,200 --> 00:32:11,630
>> Гэта можа быць канец
усё, усё будзе ўсё.

760
00:32:11,630 --> 00:32:12,790
І яны пачынаюць выкарыстоўваць яго.

761
00:32:12,790 --> 00:32:14,720
І кажуць яны, гэты матэрыял не працуе.

762
00:32:14,720 --> 00:32:17,600
Гэта не правільна.

763
00:32:17,600 --> 00:32:19,105
Старая матэрыял быў лепш.

764
00:32:19,105 --> 00:32:21,230
І яны вяртаюцца да выканання
рэчы, як яны былі.

765
00:32:21,230 --> 00:32:22,730
І тады ў канчатковым рахунку
яны ідуць, вы ведаеце, што?

766
00:32:22,730 --> 00:32:24,040
Гэты матэрыял не так ужо дрэнна.

767
00:32:24,040 --> 00:32:26,192
О, як гэта працуе.

768
00:32:26,192 --> 00:32:28,900
І як толькі яны высветліць, як гэта
Працы, яны пачынаюць усё лепш.

769
00:32:28,900 --> 00:32:32,050
>> І самае смешнае аб гэтым
ёсць, выгляд ліній да таго, што

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

771
00:32:34,300 --> 00:32:36,910
Дык што ж адбываецца ў нас ёсць
свайго роду тэхналогія запуску.

772
00:32:36,910 --> 00:32:39,100
У выпадку баз дадзеных,
гэта ціск дадзеных.

773
00:32:39,100 --> 00:32:42,200
Мы гаварылі аб высокіх кропак вады
ціску дадзеных на працягу часу.

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

775
00:32:46,310 --> 00:32:47,830
>> Гэта становіцца занадта дорага.

776
00:32:47,830 --> 00:32:49,790
Гэта займае занадта шмат часу, каб апрацаваць дадзеныя.

777
00:32:49,790 --> 00:32:50,890
Мы павінны нешта лепш.

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

779
00:32:52,890 --> 00:32:55,050
спрабуючы высветліць, што гэтае рашэнне.

780
00:32:55,050 --> 00:32:56,050
Што новая ідэя?

781
00:32:56,050 --> 00:32:58,170
>> Што наступная лепшая
спосаб зрабіць гэта?

782
00:32:58,170 --> 00:32:59,530
І яны прыходзяць з нечым.

783
00:32:59,530 --> 00:33:03,140
І людзі з рэальнай болю,
хлопцы на пярэднім краі,

784
00:33:03,140 --> 00:33:06,390
яны буду скакаць над ім,
таму што яны павінны адказаць.

785
00:33:06,390 --> 00:33:09,690
Цяпер тое, што непазбежна і happens--
гэта адбываецца цяпер у NoSQL.

786
00:33:09,690 --> 00:33:11,090
Я бачу ўвесь гэты час.

787
00:33:11,090 --> 00:33:13,610
>> Што непазбежна адбываецца
людзі пачынаюць выкарыстоўваць новы інструмент

788
00:33:13,610 --> 00:33:15,490
гэтак жа, як яны выкарыстоўвалі стары інструмент.

789
00:33:15,490 --> 00:33:17,854
І яны гэта высветліць
не працуе так добра.

790
00:33:17,854 --> 00:33:20,020
Я не магу ўспомніць, хто я
гаварыць з раней сёння.

791
00:33:20,020 --> 00:33:22,080
Але гэта, як, калі
адбойны малаток быў вынайдзены,

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

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

794
00:33:27,360 --> 00:33:30,610
>> Але гэта тое, што
адбываецца з NoSQL сёння.

795
00:33:30,610 --> 00:33:33,900
Калі вы хадзіць у большасці крамаў,
яны спрабуюць быць NoSQL крамы.

796
00:33:33,900 --> 00:33:36,510
Тое, што яны робяць, з'яўляецца
яны выкарыстоўваюць NoSQL,

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

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

799
00:33:41,630 --> 00:33:44,046
І яны цікава, чаму
не выконваючы вельмі добра?

800
00:33:44,046 --> 00:33:45,230
Хлопчык, гэтая рэч пахне.

801
00:33:45,230 --> 00:33:49,900
Я павінен быў падтрымліваць усе мае
далучаецца in-- гэта як, няма, няма.

802
00:33:49,900 --> 00:33:50,800
Падтрыманне далучаецца?

803
00:33:50,800 --> 00:33:52,430
Чаму вы далучэння дадзеных?

804
00:33:52,430 --> 00:33:54,350
Вы не аб'ядноўваць дадзеныя ў NoSQL.

805
00:33:54,350 --> 00:33:55,850
Вы агрэгаваць яго.

806
00:33:55,850 --> 00:34:00,690
>> Так што, калі вы хочаце, каб пазбегнуць гэтага, даведацца
як інструмент працуе перш чым вы сапраўды

807
00:34:00,690 --> 00:34:02,010
пачаць выкарыстоўваць яго.

808
00:34:02,010 --> 00:34:04,860
Не спрабуйце выкарыстоўваць новыя Інструменты
гэтак жа, як вы выкарыстоўвалі старыя інструменты.

809
00:34:04,860 --> 00:34:06,500
Вы будзеце мець дрэнны досвед.

810
00:34:06,500 --> 00:34:08,848
І кожны раз,
гэта тое, што гэта пра.

811
00:34:08,848 --> 00:34:11,389
Калі мы пачынаем прыдумляць тут,
гэта таму, што людзі высветлілі,

812
00:34:11,389 --> 00:34:13,449
як выкарыстоўваць інструменты.

813
00:34:13,449 --> 00:34:16,250
>> Яны зрабілі тое ж самае, калі
рэляцыйныя базы дадзеных былі вынайдзены,

814
00:34:16,250 --> 00:34:17,969
і яны былі замены файлавых сістэм.

815
00:34:17,969 --> 00:34:20,420
Яны спрабавалі пабудаваць файлавых сістэм
з рэляцыйнымі базамі дадзеных

816
00:34:20,420 --> 00:34:22,159
таму што гэта тое, што людзі зразумелі.

817
00:34:22,159 --> 00:34:23,049
Гэта не працуе.

818
00:34:23,049 --> 00:34:26,090
Такім чынам, разуменне лепшыя практыкі
тэхналогіі вы працуеце з

819
00:34:26,090 --> 00:34:26,730
велізарны.

820
00:34:26,730 --> 00:34:29,870
Вельмі важна.

821
00:34:29,870 --> 00:34:32,440
>> Такім чынам, мы збіраемся, каб патрапіць у DynamoDB.

822
00:34:32,440 --> 00:34:36,480
DynamoDB з'яўляецца AWS-х
цалкам кіраванага платформу NoSQL.

823
00:34:36,480 --> 00:34:37,719
Што цалкам кіраванага на ўвазе?

824
00:34:37,719 --> 00:34:40,010
Гэта азначае, што вы не павінны
сапраўды ні пра што турбавацца.

825
00:34:40,010 --> 00:34:42,060
>> Вы прыходзіце, вы скажыце
нам, мне трэба табліцу.

826
00:34:42,060 --> 00:34:43,409
Гэта мае патрэбу ў гэтым больш магутнасці.

827
00:34:43,409 --> 00:34:47,300
Вы націснеце кнопку, і мы прадастаўленне
уся інфраструктура за сцэнай.

828
00:34:47,300 --> 00:34:48,310
Цяпер, велізарны.

829
00:34:48,310 --> 00:34:51,310
>> Таму што, калі вы кажаце
аб маштабаванне базы дадзеных,

830
00:34:51,310 --> 00:34:53,917
Кластары дадзеных NoSQL ў
маштаб, хадавыя петабайт,

831
00:34:53,917 --> 00:34:55,750
працуе мільёны
транзакцый у секунду,

832
00:34:55,750 --> 00:34:58,180
гэтыя рэчы не малыя кластары.

833
00:34:58,180 --> 00:35:00,830
Мы кажам тысячы асобнікаў.

834
00:35:00,830 --> 00:35:04,480
Кіраванне тысячы асобнікаў,
нават віртуальныя асобнікі,

835
00:35:04,480 --> 00:35:06,350
гэта рэальная боль у задніцы.

836
00:35:06,350 --> 00:35:09,110
Я маю на ўвазе, думаць пра кожны раз
Аперацыйная сістэма выходзіць патч

837
00:35:09,110 --> 00:35:11,552
ці новай версіі базы дадзеных.

838
00:35:11,552 --> 00:35:13,260
Што гэта азначае
Вам аператыўна?

839
00:35:13,260 --> 00:35:16,330
Гэта азначае, што вы атрымалі 1200
серверы, якія павінны быць абноўлены.

840
00:35:16,330 --> 00:35:18,960
Цяпер нават з аўтаматызацыяй,
што можа заняць працяглы час.

841
00:35:18,960 --> 00:35:21,480
Гэта можа выклікаць шмат
аператыўныя галаўныя болі,

842
00:35:21,480 --> 00:35:23,090
таму што я, магчыма, паслугі ўніз.

843
00:35:23,090 --> 00:35:26,070
>> Як мне абнавіць гэтыя базы дадзеных, я
можа зрабіць блакітныя зялёныя разгортвання

844
00:35:26,070 --> 00:35:29,420
дзе я разгортвання і абнаўлення паловы майго
вузлы, а затым абнавіць іншую палову.

845
00:35:29,420 --> 00:35:30,490
Вазьміце тыя ўніз.

846
00:35:30,490 --> 00:35:33,410
Так кіравання інфраструктурай
Шкала з'яўляецца надзвычай балючым.

847
00:35:33,410 --> 00:35:36,210
І AWS прыняць гэты боль з яго.

848
00:35:36,210 --> 00:35:39,210
І базы дадзеных NoSQL можа
надзвычай балючым будзе

849
00:35:39,210 --> 00:35:41,780
з-за, як яны маштабавання.

850
00:35:41,780 --> 00:35:42,926
>> Маштаб па гарызанталі.

851
00:35:42,926 --> 00:35:45,550
Калі вы хочаце, каб атрымаць вялікую NoSQL
базы дадзеных, вы купляеце больш вузлоў.

852
00:35:45,550 --> 00:35:48,660
Кожны вузел вы купляеце
іншы аперацыйны галаўны боль.

853
00:35:48,660 --> 00:35:50,830
Такім чынам, давайце хтосьці зробіць гэта за вас.

854
00:35:50,830 --> 00:35:52,000
AWS можа гэта зрабіць.

855
00:35:52,000 --> 00:35:54,587
>> Мы падтрымліваем значэння ключавых дакументаў.

856
00:35:54,587 --> 00:35:56,670
Цяпер мы не пайшлі занадта шмат
у іншай дыяграме.

857
00:35:56,670 --> 00:35:58,750
Там шмат розных
водары NoSQL.

858
00:35:58,750 --> 00:36:02,670
Яны ўсе віды атрымліваць
згубяцца разам у гэтай кропцы.

859
00:36:02,670 --> 00:36:06,260
Вы можаце паглядзець на DynamoDB і сказаць так,
мы абодва дакумента і значэнне ключа

860
00:36:06,260 --> 00:36:08,412
захоўваць гэтую кропку.

861
00:36:08,412 --> 00:36:10,620
І вы можаце сцвярджаць, асаблівасці
аднаго над іншым.

862
00:36:10,620 --> 00:36:13,950
Для мяне, шмат гэта сапраўды шэсць
аднаго паўтузіна іншага.

863
00:36:13,950 --> 00:36:18,710
Кожны з гэтых тэхналогій з'яўляецца
дакладная тэхналогія і штраф рашэнне.

864
00:36:18,710 --> 00:36:23,390
Я б не сказаў, што MongoDB лепш ці
горш, чым канапе, то Касандры,

865
00:36:23,390 --> 00:36:25,994
то Дынама, ці наадварот.

866
00:36:25,994 --> 00:36:27,285
Я маю на ўвазе, гэта ўсяго толькі варыянты.

867
00:36:27,285 --> 00:36:29,850

868
00:36:29,850 --> 00:36:32,700
>> Гэта хутка, і гэта
адпавядае ў любым маштабе.

869
00:36:32,700 --> 00:36:36,210
Такім чынам, гэта з'яўляецца адным з найбуйнейшых
бонусы вы атрымліваеце з AWS.

870
00:36:36,210 --> 00:36:40,850
З DynamoDB з'яўляецца здольнасць
каб атрымаць нізкую адну лічбу

871
00:36:40,850 --> 00:36:44,040
Затрымка мілісекунду ў любым маштабе.

872
00:36:44,040 --> 00:36:45,720
Гэта было мэтай дызайну сістэмы.

873
00:36:45,720 --> 00:36:49,130
І ў нас ёсць кліенты, якія робяць
мільёны транзакцый у секунду.

874
00:36:49,130 --> 00:36:52,670
>> Цяпер я пайду праз некаторыя з тых,
выпадкі выкарыстання на працягу некалькіх хвілін тут.

875
00:36:52,670 --> 00:36:55,660
Убудаваны control-- доступ
мы маем тое, што мы называем

876
00:36:55,660 --> 00:36:57,920
Ідэнтычнасць Упраўленне доступам, або IAM.

877
00:36:57,920 --> 00:37:01,980
Яна пранізвае ўсе сістэмы,
кожны сэрвіс, які прапануе AWS.

878
00:37:01,980 --> 00:37:03,630
DynamoDB не з'яўляецца выключэннем.

879
00:37:03,630 --> 00:37:06,020
Вы можаце кантраляваць доступ
да табліцах DynamoDB.

880
00:37:06,020 --> 00:37:09,960
Праз усе вашы AWS складае ад
вызначэнне ролі і дазволу доступу

881
00:37:09,960 --> 00:37:12,140
у IAM інфраструктуры.

882
00:37:12,140 --> 00:37:16,630
>> І гэта ключавы і неад'емнай складнікам
што мы называем Event Driven праграмавання.

883
00:37:16,630 --> 00:37:19,056
Зараз гэта новая парадыгма.

884
00:37:19,056 --> 00:37:22,080
>> АЎДЫТОРЫЯ: Як ваша хуткасць дакладна
Станоўчых супраць ілжывых негатываў

885
00:37:22,080 --> 00:37:24,052
на сістэмы кантролю доступу?

886
00:37:24,052 --> 00:37:26,260
РВК Хулихэном: True спрацоўванняў
у параўнанні з ложноотріцательные?

887
00:37:26,260 --> 00:37:28,785
АЎДЫТОРЫЯ: Вяртаючыся што
Вы павінны вяртацца?

888
00:37:28,785 --> 00:37:33,720
У адрозненне ад раз у той час ён
не вярнуцца, калі ён павінен праверыць?

889
00:37:33,720 --> 00:37:36,260

890
00:37:36,260 --> 00:37:38,050
>> РВК Хулихэном: Я не мог сказаць вам, што.

891
00:37:38,050 --> 00:37:40,140
Калі ёсць якія-небудзь збоі
б там ні было, што,

892
00:37:40,140 --> 00:37:42,726
Я не той чалавек, каб спытаць
што канкрэтны пытанне.

893
00:37:42,726 --> 00:37:43,850
Але гэта добрае пытанне.

894
00:37:43,850 --> 00:37:45,905
Я б цікава даведацца,
што я, на самай справе.

895
00:37:45,905 --> 00:37:48,810

896
00:37:48,810 --> 00:37:51,320
>> І так, зноў жа, новая парадыгма
гэта падзейную праграмавання.

897
00:37:51,320 --> 00:37:55,160
Гэта ідэя, што вы можаце
разгарнуць складаных прыкладанняў, якія

898
00:37:55,160 --> 00:37:59,720
можа працаваць вельмі, вельмі высокі маштаб
без інфраструктуры б там ні было.

899
00:37:59,720 --> 00:38:02,120
Без цвёрдага
Інфраструктура б там ні было.

900
00:38:02,120 --> 00:38:04,720
І мы будзем казаць трохі
аб тым, што гэта азначае, што, як мы

901
00:38:04,720 --> 00:38:06,550
атрымаць на наступным пары карт.

902
00:38:06,550 --> 00:38:08,716
>> Першае, што мы зробім
што мы будзем казаць аб табліцах.

903
00:38:08,716 --> 00:38:10,857
Тыпы дадзеных API для Дынама.

904
00:38:10,857 --> 00:38:13,190
І першае, што вы будзеце
заўважыў, калі вы глядзіце на гэта,

905
00:38:13,190 --> 00:38:17,930
калі вы знаёмыя з любой базай дадзеных,
Базы дадзеных сапраўды два віды інтэрфейсаў

906
00:38:17,930 --> 00:38:18,430
Я б назваў гэта.

907
00:38:18,430 --> 00:38:21,570
Ці два камплекты API.

908
00:38:21,570 --> 00:38:23,840
Адзін з тых, будзе
API кіравання.

909
00:38:23,840 --> 00:38:26,710
>> Рэчы, якія яны прымаюць на сябе
функцыі базы дадзеных.

910
00:38:26,710 --> 00:38:31,340
Налада механізму захоўвання,
стварэнне і даданне табліц.

911
00:38:31,340 --> 00:38:35,180
стварэнне базы дадзеных
каталогі і прыклады.

912
00:38:35,180 --> 00:38:40,450
Яны things-- ў DynamoDB, вы
маюць вельмі кароткія, кароткія спісы.

913
00:38:40,450 --> 00:38:43,120
>> Такім чынам, у іншых базах дадзеных,
Вы маглі б бачыць дзясяткі

914
00:38:43,120 --> 00:38:45,680
з каманды, адміністрацыйна
Каманды, для канфігуравання

915
00:38:45,680 --> 00:38:47,290
гэтыя дадатковыя опцыі.

916
00:38:47,290 --> 00:38:51,234
У DynamoDB вам не трэба, таму што тыя,
Вы не наладжваць сістэму, мы робім.

917
00:38:51,234 --> 00:38:54,150
Так што адзінае, што вам трэба зрабіць, гэта
скажы мне, што памер табліцы мне трэба.

918
00:38:54,150 --> 00:38:55,660
Такім чынам, вы атрымліваеце вельмі
абмежаваны набор каманд.

919
00:38:55,660 --> 00:38:58,618
>> Вы атрымліваеце Create Table Update, Настольны,
Выдаліць табліцу і апісаць табліцу.

920
00:38:58,618 --> 00:39:01,150
Гэта адзіныя рэчы,
што трэба для DynamoDB.

921
00:39:01,150 --> 00:39:03,294
Вам не трэба сховішча
канфігурацыя рухавіка.

922
00:39:03,294 --> 00:39:04,960
Мне не трэба турбавацца аб рэплікацыі.

923
00:39:04,960 --> 00:39:06,490
Мне не трэба турбавацца аб шардинге.

924
00:39:06,490 --> 00:39:07,800
>> Я не трэба турбавацца
аб любым з гэтага матэрыялу.

925
00:39:07,800 --> 00:39:08,740
Мы робім усё гэта для вас.

926
00:39:08,740 --> 00:39:11,867
Так што гэта велізарная колькасць накладных расходаў
што проста падняў свой пласціну.

927
00:39:11,867 --> 00:39:13,200
Тады ў нас ёсць аператары CRUD.

928
00:39:13,200 --> 00:39:17,740
CRUD-тое, што мы
патэлефануйце ў базе дадзеных, што гэта

929
00:39:17,740 --> 00:39:19,860
Стварэнне, абнаўленне, выдаленне аператараў.

930
00:39:19,860 --> 00:39:24,180
Гэта ваш агульны
аперацыі з базамі дадзеных.

931
00:39:24,180 --> 00:39:31,299
Такія рэчы, як пакласці дэталь, атрымліваеце дэталь, абнаўленне
прадметы, выдаляць элементы, партыя запытаў, сканаванне.

932
00:39:31,299 --> 00:39:32,840
Калі вы хочаце, каб сканаваць ўсю табліцу.

933
00:39:32,840 --> 00:39:34,220
Пацягніце ўсё са стала.

934
00:39:34,220 --> 00:39:37,130
Адна з прыемных рэчаў аб DynamoDB
гэта дазваляе паралельнае сканаванне.

935
00:39:37,130 --> 00:39:40,602
Так што вы можаце на самой справе, дайце мне ведаць, колькі
тэмы вы хочаце, каб працаваць на гэтай сканавання.

936
00:39:40,602 --> 00:39:41,810
І мы можам запусціць гэтыя тэмы.

937
00:39:41,810 --> 00:39:43,985
Мы можам спіна, што сканаваць да
па некалькіх патокаў

938
00:39:43,985 --> 00:39:49,060
так што вы можаце сканаваць ўсю табліцу
прастору вельмі, вельмі хутка ў DynamoDB.

939
00:39:49,060 --> 00:39:51,490
>> Іншы API мы маем
тое, што мы называем нашым Патокі API.

940
00:39:51,490 --> 00:39:52,940
Мы не збіраемся казаць занадта
шмат пра гэта прама цяпер.

941
00:39:52,940 --> 00:39:55,189
Я атрымаў некаторы ўтрыманне пазней
на палубе ў пра гэта.

942
00:39:55,189 --> 00:39:59,910
Але Патокі сапраўды running--
думаю пра яго, як загадаў раз

943
00:39:59,910 --> 00:40:01,274
і змяненне раздзелаў часопіса.

944
00:40:01,274 --> 00:40:03,940
Усё, што адбываецца на
табліца паказвае ўверх у струмені.

945
00:40:03,940 --> 00:40:05,940
>> Кожны напісаць у табліцы
Выставы на паток.

946
00:40:05,940 --> 00:40:08,370
Вы можаце прачытаць, што струмень, і
Вы можаце рабіць рэчы, з ім.

947
00:40:08,370 --> 00:40:10,150
Мы будзем казаць аб тым, што
тыпы рэчаў, якія вы

948
00:40:10,150 --> 00:40:13,680
рабіць з рэчамі, як рэплікацыя,
стварэнне другасных індэксаў.

949
00:40:13,680 --> 00:40:17,620
Усе віды сапраўды выдатна
рэчы, якія вы можаце зрабіць з гэтым.

950
00:40:17,620 --> 00:40:19,150
>> Тыпы дадзеных.

951
00:40:19,150 --> 00:40:23,320
У DynamoDB, мы падтрымліваем абодва ключа
значэнне і дакумент тыпы дадзеных.

952
00:40:23,320 --> 00:40:26,350
На левай баку экрана
тут, мы атрымалі нашы асноўныя тыпы.

953
00:40:26,350 --> 00:40:27,230
Асноўныя тыпы значэнняў.

954
00:40:27,230 --> 00:40:30,040
Гэтыя радкі,
лічбы і выкананыя файлы.

955
00:40:30,040 --> 00:40:31,640
>> Так усяго за тры асноўных тыпу.

956
00:40:31,640 --> 00:40:33,700
І тады вы можаце мець наборы з іх.

957
00:40:33,700 --> 00:40:37,650
Адна з прыемных рэчаў аб NoSQL гэта
Вы можаце ўтрымліваць масівы ў якасці уласцівасцяў.

958
00:40:37,650 --> 00:40:42,050
І з DynamoDB можна ўтрымліваць масівы
асноўных тыпаў, як каранёвай уласнасці.

959
00:40:42,050 --> 00:40:43,885
>> А тут яшчэ тыпы дакументаў.

960
00:40:43,885 --> 00:40:45,510
Колькі людзей знаёмыя з JSON?

961
00:40:45,510 --> 00:40:47,130
Вы, хлопцы, знаёмыя з JSON так шмат?

962
00:40:47,130 --> 00:40:49,380
Гэта ў асноўным JavaScript,
Аб'ект, Абазначэнні.

963
00:40:49,380 --> 00:40:52,510
Гэта дазваляе ў асноўным
вызначаюць іерархічную структуру.

964
00:40:52,510 --> 00:40:58,107
>> Вы можаце захоўваць дакумент у фармаце JSON на
DynamoDB выкарыстаннем агульных кампанентаў

965
00:40:58,107 --> 00:41:00,940
або блокаў, якія даступныя
у большасці моў праграмавання.

966
00:41:00,940 --> 00:41:03,602
Так што, калі ў вас ёсць Java, вы
гледзячы на ​​карты і спісы.

967
00:41:03,602 --> 00:41:05,060
Я магу стварыць аб'екты, якія Карта зоны.

968
00:41:05,060 --> 00:41:08,030
Карта, як ключавых каштоўнасцяў
захоўваюцца ў якасці уласцівасцяў.

969
00:41:08,030 --> 00:41:10,890
І гэта, магчыма, ёсць спісы
значэння ў межах гэтых уласцівасцяў.

970
00:41:10,890 --> 00:41:13,490
Вы можаце захоўваць гэты комплекс
іерархічная структура

971
00:41:13,490 --> 00:41:16,320
як аднаго атрыбуту
з пункта DynamoDB.

972
00:41:16,320 --> 00:41:19,010

973
00:41:19,010 --> 00:41:24,460
>> Так табліц у DynamoDB, як і большасць
Базы дадзеных NoSQL, сталы ёсць пункты.

974
00:41:24,460 --> 00:41:26,469
У MongoDB вы б
называць гэтыя дакументы.

975
00:41:26,469 --> 00:41:27,760
І гэта будзе канапа базы.

976
00:41:27,760 --> 00:41:28,900
Таксама база дадзеных дакументаў.

977
00:41:28,900 --> 00:41:29,941
Вы называеце гэтыя дакументы.

978
00:41:29,941 --> 00:41:32,930
Дакументы або дэталі маюць атрыбуты.

979
00:41:32,930 --> 00:41:35,850
Атрыбуты могуць існаваць або
не існуе па гэтым пункце.

980
00:41:35,850 --> 00:41:38,520
У DynamoDB, ёсць
адзін абавязковы атрыбут.

981
00:41:38,520 --> 00:41:43,880
Гэтак жа, як у рэляцыйнай базе дадзеных,
ў вас ёсць першасны ключ на стале.

982
00:41:43,880 --> 00:41:46,010
>> DynamoDB мае тое, што мы называем хэш-ключ.

983
00:41:46,010 --> 00:41:48,280
Хэш ключ павінен быць унікальным.

984
00:41:48,280 --> 00:41:52,580
Таму, калі я вызначыць хэш-табліцу,
у асноўным тое, што я кажу,

985
00:41:52,580 --> 00:41:54,110
з'яўляецца кожны элемент будзе мець хэш-ключ.

986
00:41:54,110 --> 00:41:58,520
І кожны хэш-ключ павінен быць унікальным.

987
00:41:58,520 --> 00:42:01,200
>> Кожны элемент вызначаецца
гэтай унікальнай Хэш-ключа.

988
00:42:01,200 --> 00:42:02,940
А можа быць толькі адзін.

989
00:42:02,940 --> 00:42:05,820
Гэта нармальна, але часта
што трэба людзям

990
00:42:05,820 --> 00:42:08,170
яны хочуць гэта хэш
Ключ да рабіць трохі больш

991
00:42:08,170 --> 00:42:11,010
чым проста быць унікальным ідэнтыфікатарам.

992
00:42:11,010 --> 00:42:15,240
Часта мы хочам, каб выкарыстоўваць гэтую хэш-ключ
ў якасці верхняга ўзроўню агрэгацыі вядро.

993
00:42:15,240 --> 00:42:19,160
І тое, як мы робім, што з'яўляецца
дадаўшы, што мы называем ключ дыяпазону.

994
00:42:19,160 --> 00:42:22,460
>> Так што, калі гэта толькі хеш-
стол, гэта павінна быць унікальным.

995
00:42:22,460 --> 00:42:27,040
Калі гэта хэш і дыяпазон стол,
Спалучэнне хэша і дыяпазону

996
00:42:27,040 --> 00:42:28,640
павінна быць унікальным.

997
00:42:28,640 --> 00:42:30,110
Так што падумайце пра гэта такім чынам.

998
00:42:30,110 --> 00:42:32,140
Калі ў мяне ёсць форум.

999
00:42:32,140 --> 00:42:39,010
І форма мае тэмы, ён мае
пасады, і яна мае адказаў.

1000
00:42:39,010 --> 00:42:42,630
>> Так што я, магчыма, хэш
ключ, які з'яўляецца тэмай ID.

1001
00:42:42,630 --> 00:42:46,650
І я мог бы мець ключ дыяпазон,
які з'яўляецца адказам ID.

1002
00:42:46,650 --> 00:42:49,650
Такім чынам, калі я хачу, каб усе
адказы для канкрэтнай тэме,

1003
00:42:49,650 --> 00:42:52,370
Я магу толькі запыт хэш.

1004
00:42:52,370 --> 00:42:55,190
Я магу толькі сказаць, мне ўсё даюць
прадметы, якія маюць гэты хэш.

1005
00:42:55,190 --> 00:43:01,910
І я іду, каб атрымаць кожнае пытанне
або размясціць на гэтай канкрэтнай тэме.

1006
00:43:01,910 --> 00:43:03,910
Гэтыя галоўныя навалы ўзроўню
вельмі важныя.

1007
00:43:03,910 --> 00:43:07,370
Яны падтрымліваюць асноўны доступ
Характар ​​прымянення.

1008
00:43:07,370 --> 00:43:09,420
Наогул кажучы, гэта
гэта тое, што мы хочам зрабіць.

1009
00:43:09,420 --> 00:43:11,780
Мы хочам, каб table--
як вы загрузіць табліцу,

1010
00:43:11,780 --> 00:43:16,640
мы хочам, каб структураваць дадзеныя
у табліцы такім чынам,

1011
00:43:16,640 --> 00:43:20,140
што прыкладанне можа вельмі
хутка атрымаць гэтыя вынікі.

1012
00:43:20,140 --> 00:43:24,510
І часта спосаб зрабіць гэта
для падтрымання гэтых агрэгатаў, як мы

1013
00:43:24,510 --> 00:43:25,650
ўставіць дадзеныя.

1014
00:43:25,650 --> 00:43:31,110
У прынцыпе, мы распаўсюджвання даных
у светлую вядро, як гэта адбываецца ў.

1015
00:43:31,110 --> 00:43:35,210
>> Ключы з доўгімі дазваляюць me-- хэш
ключы павінны быць роўнасць.

1016
00:43:35,210 --> 00:43:39,490
Калі я запыт хэш, я павінен сказаць,
даць мне хэш, роўную гэтага.

1017
00:43:39,490 --> 00:43:41,950
Калі я запытаць дыяпазон, я
можна сказаць, дайце мне дыяпазон

1018
00:43:41,950 --> 00:43:47,040
які выкарыстоўвае любую
багатыя аператар, што мы падтрымліваем.

1019
00:43:47,040 --> 00:43:49,200
Дайце мне ўсё дэталі для хэш.

1020
00:43:49,200 --> 00:43:52,520
Гэта роўна, больш, чым,
менш, чым, яна пачынаецца з таго,

1021
00:43:52,520 --> 00:43:54,145
яно існуе паміж гэтымі двума значэннямі?

1022
00:43:54,145 --> 00:43:56,811
Такім чынам, гэтыя тыпы запытаў далёкасці
што мы заўсёды зацікаўлены ў.

1023
00:43:56,811 --> 00:43:59,650
Цяпер адна рэч, пра дадзеныя, калі
вы паглядзіце на доступ да дадзеных, калі

1024
00:43:59,650 --> 00:44:02,360
Вы атрымаць доступ да дадзеных, гэта
заўсёды аб агрэгацыі.

1025
00:44:02,360 --> 00:44:05,770
Гэта заўсёды аб запісах
якія звязаны з гэтым.

1026
00:44:05,770 --> 00:44:10,390
Дайце мне ўсё тут that's-- ўсе
здзелкі па гэтай крэдытнай карты

1027
00:44:10,390 --> 00:44:12,500
за апошні месяц.

1028
00:44:12,500 --> 00:44:13,960
Гэта агрэгацыі.

1029
00:44:13,960 --> 00:44:17,490
>> Амаль усё, што вы робіце ў
База дадзеных якой-агрэгацыі.

1030
00:44:17,490 --> 00:44:21,530
Так будучы ў стане быць у стане вызначыць
гэтыя вёдры і даць вам гэтыя асартымент

1031
00:44:21,530 --> 00:44:24,950
атрыбуты, каб мець магчымасць запытваць на,
гэтыя багатыя запыты падтрымкі многіх

1032
00:44:24,950 --> 00:44:27,165
шмат, шмат мадэляў доступу да дадатку.

1033
00:44:27,165 --> 00:44:30,990

1034
00:44:30,990 --> 00:44:35,000
>> Так іншы прадмет Хэш ключа
робіць гэта дае нам механізм

1035
00:44:35,000 --> 00:44:37,740
каб мець магчымасць пашырыць дадзеныя вакол.

1036
00:44:37,740 --> 00:44:40,390
Базы дадзеных NoSQL працаваць лепш
калі дадзеныя раўнамерна

1037
00:44:40,390 --> 00:44:41,740
размеркаваны ў кластары.

1038
00:44:41,740 --> 00:44:44,530

1039
00:44:44,530 --> 00:44:47,050
Колькі людзей знаёмыя
з алгарытмаў хэшавання?

1040
00:44:47,050 --> 00:44:49,860
Калі я кажу, хэш і hashing--
таму алгарытму хэшавання

1041
00:44:49,860 --> 00:44:54,140
гэта спосаб быць у стане генераваць
выпадковае значэнне ад любога зададзенага значэння.

1042
00:44:54,140 --> 00:44:59,300
Такім чынам, у дадзеным канкрэтным выпадку,
хэш алгарытм бяжым з'яўляецца Н.Д. 5 на аснове.

1043
00:44:59,300 --> 00:45:04,765
>> І калі ў мяне ёсць ID, і гэта
мой хэш-ключ, у мяне ёсць 1, 2, 3.

1044
00:45:04,765 --> 00:45:07,390
Калі я запускаю алгарытм хэшавання,
ён збіраецца вярнуцца і сказаць,

1045
00:45:07,390 --> 00:45:10,800
а 1 роўны 7В, 2
роўная 48, 3 роўная кампакт-дыска.

1046
00:45:10,800 --> 00:45:13,092
Яны раскіданыя па ўсім ключавога прасторы.

1047
00:45:13,092 --> 00:45:14,050
І чаму вы гэта робіце?

1048
00:45:14,050 --> 00:45:17,120
Таму што гарантуе, што я магу
пакласці запісу на некалькіх вузлах.

1049
00:45:17,120 --> 00:45:19,574
>> Калі я раблю гэта
паступова, 1, 2, 3.

1050
00:45:19,574 --> 00:45:21,990
І ў мяне ёсць выбар, што хэш-
працуе ў дадзеным канкрэтным выпадку,

1051
00:45:21,990 --> 00:45:24,785
невялікая прастора хэш,
ён працуе ад 00 да FF,

1052
00:45:24,785 --> 00:45:27,951
то запісу будуць прыходзіць у
і яны збіраюцца ісці 1, 2, 3, 4, 5,

1053
00:45:27,951 --> 00:45:30,390
6, 7, 8, 9, 10, 11, 12.

1054
00:45:30,390 --> 00:45:31,800
Што здарылася?

1055
00:45:31,800 --> 00:45:34,860
Кожны ўкладыш ідзе ў тым жа вузле.

1056
00:45:34,860 --> 00:45:36,070
Вы бачыце, што я маю на ўвазе?

1057
00:45:36,070 --> 00:45:40,910
>> Таму што, калі я падзяліць прастору,
і я распаўсюджваць гэтыя запісы праз,

1058
00:45:40,910 --> 00:45:45,950
і я раздзел, я збіраюся сказаць,
раздзел 1 мае ключавое прастору ад 0 да 54.

1059
00:45:45,950 --> 00:45:47,720
Раздзел 2 55 да 89.

1060
00:45:47,720 --> 00:45:49,780
Раздзел 3 АА FF.

1061
00:45:49,780 --> 00:45:53,740
Так што, калі я выкарыстоўваю лінейна павялічваючы
Ідэнтыфікатары, вы можаце бачыць, што адбываецца.

1062
00:45:53,740 --> 00:45:57,410
1, 2, 3, 4, 5, 6, ўвесь шлях да 54.

1063
00:45:57,410 --> 00:46:00,030
Так, як я малатком
запісы ў сістэме,

1064
00:46:00,030 --> 00:46:02,030
усе заканчваецца тым, што ішлі да аднаго вузлу.

1065
00:46:02,030 --> 00:46:03,160
>> Гэта не добра.

1066
00:46:03,160 --> 00:46:04,820
Гэта антипаттерн.

1067
00:46:04,820 --> 00:46:08,760
У MongoDB яны маюць гэтую праблему
калі вы не выкарыстоўваеце хэш-ключ.

1068
00:46:08,760 --> 00:46:11,325
MongoDB дае вам магчымасць
хэшавання значэнне ключа.

1069
00:46:11,325 --> 00:46:13,950
Вы заўсёды павінны рабіць, калі
Вы карыстаецеся прырашчэння Хэш

1070
00:46:13,950 --> 00:46:17,380
Ключ у MongoDB, ці вы будзеце
цвікоў кожнай запісу ў адным вузле,

1071
00:46:17,380 --> 00:46:21,290
і вы будзеце абмяжоўваючы
Вы пішаце прапускная дрэнна.

1072
00:46:21,290 --> 00:46:24,896
>> АЎДЫТОРЫЯ: Гэта A9 169 у дзесятковай?

1073
00:46:24,896 --> 00:46:28,450
>> РВК Хулихэном: Так, гэта
дзесьці каля там.

1074
00:46:28,450 --> 00:46:29,950
A9, я не ведаю.

1075
00:46:29,950 --> 00:46:32,200
Вы павінны былі б атрымаць мой двайковы
у дзесятковую калькулятар.

1076
00:46:32,200 --> 00:46:34,237
Мой мозг не працуе так.

1077
00:46:34,237 --> 00:46:36,320
АЎДЫТОРЫЯ: Проста хутка адным
Вашы каментары Mongo.

1078
00:46:36,320 --> 00:46:39,530
Так ідэнтыфікатар аб'екта, які пастаўляецца
першапачаткова з Монго зрабіць?

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

1080
00:46:40,179 --> 00:46:41,470
РВК Хулихэном: яна гэта робіць?

1081
00:46:41,470 --> 00:46:42,970
Калі вы пакажыце яго.

1082
00:46:42,970 --> 00:46:45,030
У MongoDB, у вас ёсць магчымасць.

1083
00:46:45,030 --> 00:46:48,930
Вы можаце specify-- кожны дакумент у
MongoDB павінен мець падкрэслення ID.

1084
00:46:48,930 --> 00:46:50,300
Гэта унікальнае значэнне.

1085
00:46:50,300 --> 00:46:55,240
>> У MongoDB вы можаце паказаць
Ці хэш яго ці не.

1086
00:46:55,240 --> 00:46:56,490
Яны проста даюць вам магчымасць.

1087
00:46:56,490 --> 00:46:58,198
Калі вы ведаеце, што гэта
ня выпадковы, не праблема.

1088
00:46:58,198 --> 00:46:59,640
Вам не трэба гэтага рабіць.

1089
00:46:59,640 --> 00:47:04,260
Калі вы ведаеце, што гэта не выпадкова, што
гэта прырашчэнне, а затым зрабіць хэш.

1090
00:47:04,260 --> 00:47:06,880
>> Цяпер справа аб
хэшавання, калі вы хэш

1091
00:47:06,880 --> 00:47:08,800
value-- і гэта
чаму хэш-ключы заўсёды

1092
00:47:08,800 --> 00:47:13,740
унікальныя запыты, таму што я змянілася
значэнне, у цяперашні час я не магу зрабіць дыяпазон запытаў.

1093
00:47:13,740 --> 00:47:15,640
Я не магу сказаць, гэта
між тым ці іншым,

1094
00:47:15,640 --> 00:47:20,800
таму што хэш-значэнне не будзе
быць эквівалентная рэальнай кошту.

1095
00:47:20,800 --> 00:47:24,570
Такім чынам, калі вы хэш, што
Ключ, гэта толькі роўнасць.

1096
00:47:24,570 --> 00:47:28,700
Вось чаму ў DynamoDB Хэш-ключа
запыты заўсёды толькі роўнасць.

1097
00:47:28,700 --> 00:47:32,090

1098
00:47:32,090 --> 00:47:34,700
>> Так што цяпер у дыяпазоне key--
калі я дадаць, што ключавы дыяпазон,

1099
00:47:34,700 --> 00:47:38,180
тыя ключавыя запісу дыяпазон ўсе прыходзяць і
яны атрымліваюць захоўваецца ў тым жа раздзеле.

1100
00:47:38,180 --> 00:47:42,430
Такім чынам, яны вельмі хутка, лёгка
здабываецца, таму што гэта хэш,

1101
00:47:42,430 --> 00:47:43,220
гэта дыяпазон.

1102
00:47:43,220 --> 00:47:44,928
І вы бачыце, усё
з той жа хэш

1103
00:47:44,928 --> 00:47:48,550
атрымлівае захоўваецца на тым жа прасторы раздзелаў.

1104
00:47:48,550 --> 00:47:53,889
Вы можаце выкарыстоўваць гэты ключ, каб дапамагчы дыяпазон
знайсці вашы дадзеныя блізкія да свайго бацьку.

1105
00:47:53,889 --> 00:47:55,180
Так што я на самой справе тут робіш?

1106
00:47:55,180 --> 00:47:57,320
Гэта адзін да многіх адносін.

1107
00:47:57,320 --> 00:48:01,490
Адносіны паміж ключом хэш-
і ключ дыяпазон адзін да многіх.

1108
00:48:01,490 --> 00:48:03,490
Я магу мець некалькі ключоў хэш.

1109
00:48:03,490 --> 00:48:07,610
Я магу толькі мець некалькі выбар
ключы ўнутры кожнага ключа хэша.

1110
00:48:07,610 --> 00:48:11,910
>> Хэш вызначае з бацькоў,
дыяпазон вызначае дзяцей.

1111
00:48:11,910 --> 00:48:15,240
Такім чынам, вы можаце бачыць, што гэта аналаг тут
паміж рэляцыйнай канструкцыі

1112
00:48:15,240 --> 00:48:18,840
і тыя ж тыпы
будуе ў NoSQL.

1113
00:48:18,840 --> 00:48:20,760
Людзі кажуць пра
NoSQL, як нереляционная.

1114
00:48:20,760 --> 00:48:22,200
Гэта не нереляционная.

1115
00:48:22,200 --> 00:48:24,680
Дадзеныя заўсёды адносіны.

1116
00:48:24,680 --> 00:48:28,172
Гэтыя адносіны проста
мадэлююцца па-рознаму.

1117
00:48:28,172 --> 00:48:29,880
Давайце трохі пагаворым
Крыху пра даўгавечнасці.

1118
00:48:29,880 --> 00:48:34,860
Калі вы пішыце ў DynamoDB, піша
заўсёды трохбаковая прайграныя.

1119
00:48:34,860 --> 00:48:37,550
Гэта азначае, што ў нас ёсць тры AZ гадоў.

1120
00:48:37,550 --> 00:48:39,160
Я з'яўляюцца даступнасць зон.

1121
00:48:39,160 --> 00:48:43,430
Вы можаце думаць аб даступнасці
Зона ў цэнтры апрацоўкі дадзеных

1122
00:48:43,430 --> 00:48:45,447
або сукупнасць цэнтраў апрацоўкі дадзеных.

1123
00:48:45,447 --> 00:48:47,780
Гэтыя рэчы геаграфічна
ізаляваны адзін ад аднаго

1124
00:48:47,780 --> 00:48:51,610
розных зон разломаў, па
адрозніваецца электрычныя сеткі і поймы.

1125
00:48:51,610 --> 00:48:54,510
Адмова ў адным AZ ня
збіраецца зняць яшчэ адзін.

1126
00:48:54,510 --> 00:48:56,890
Яны таксама звязаны
разам з цёмна-валакна.

1127
00:48:56,890 --> 00:49:01,240
Ён падтрымлівае адзін суб 1
Затрымка мілісекунду паміж АЗС.

1128
00:49:01,240 --> 00:49:05,390
Так рэплікацыі дадзеных у рэжыме рэальнага часу
здольныя ў некалькіх АЗС.

1129
00:49:05,390 --> 00:49:09,990
>> І часта мульты разгортванне AZ
адпавядаць высокім патрабаванням даступнасці

1130
00:49:09,990 --> 00:49:12,930
большасці прадпрымальніцкіх арганізацый.

1131
00:49:12,930 --> 00:49:16,139
Так DynamoDB распаўсюджваецца
праз тры АЗС па змаўчанні.

1132
00:49:16,139 --> 00:49:19,430
Мы толькі збіраемся пазнання запісу
калі два з гэтых трох вузлоў вярнуцца

1133
00:49:19,430 --> 00:49:21,470
і сказаць, Так, я атрымаў яго.

1134
00:49:21,470 --> 00:49:22,050
Чаму гэта?

1135
00:49:22,050 --> 00:49:25,950
Таму што на баку чытання мы толькі
збіраюся даць вам дадзеныя таму, калі

1136
00:49:25,950 --> 00:49:27,570
мы атрымліваем яго з двух вузлоў.

1137
00:49:27,570 --> 00:49:30,490
>> Калі я тыражаванне па
тры, і я чытаю з двух,

1138
00:49:30,490 --> 00:49:32,840
Я заўсёды гарантуецца
мець па крайняй меры адзін

1139
00:49:32,840 --> 00:49:35,720
тых счытвае быць
Актуальная копія дадзеных.

1140
00:49:35,720 --> 00:49:38,340
Гэта тое, што робіць DynamoDB паслядоўным.

1141
00:49:38,340 --> 00:49:42,450
Цяпер вы можаце ўключыць
тых, якія адпавядаюць счытвае.

1142
00:49:42,450 --> 00:49:45,070
У гэтым выпадку я збіраюся сказаць,
Я буду чытаць толькі з аднаго вузла.

1143
00:49:45,070 --> 00:49:47,430
І я не магу гарантаваць, што гэта адбываецца
каб быць найбольш актуальныя дадзеныя.

1144
00:49:47,430 --> 00:49:49,450
>> Так што, калі запісы ў бліжэйшыя,
гэта яшчэ не реплицируются,

1145
00:49:49,450 --> 00:49:50,360
Вы збіраецеся атрымаць гэтую копію.

1146
00:49:50,360 --> 00:49:52,220
Гэта ў канчатковым выніку несупярэчны чытанне.

1147
00:49:52,220 --> 00:49:54,640
І што гэта такое гэта палова кошту.

1148
00:49:54,640 --> 00:49:56,140
Так што гэта нешта думаць.

1149
00:49:56,140 --> 00:50:00,160
Калі вы чытаеце з DynamoDB, і
вы наладжваеце вашу здольнасць чытання

1150
00:50:00,160 --> 00:50:04,430
адзінак, калі вы выбіраеце ў канчатковым выніку
адпавядае чытае, гэта нашмат танней ,,

1151
00:50:04,430 --> 00:50:06,010
гэта каля паловы кошту.

1152
00:50:06,010 --> 00:50:09,342
>> І так эканоміць вашыя грошы.

1153
00:50:09,342 --> 00:50:10,300
Але гэта ваш выбар.

1154
00:50:10,300 --> 00:50:12,925
Калі вы хочаце несупярэчны чытанне або
у канчатковым выніку несупярэчны чытанне.

1155
00:50:12,925 --> 00:50:15,720
Гэта тое, што вы можаце выбраць.

1156
00:50:15,720 --> 00:50:17,659
>> Давайце пагаворым пра індэксы.

1157
00:50:17,659 --> 00:50:19,450
Такім чынам, мы згадалі, што
топ агрэгацыі ўзроўню.

1158
00:50:19,450 --> 00:50:23,720
У нас ёсць хэш ключы, і
мы атрымалі ключы далёкасці.

1159
00:50:23,720 --> 00:50:24,320
Гэта прыемна.

1160
00:50:24,320 --> 00:50:26,950
І гэта на асноўнай табліцы, я
ёсць адзін хэш-ключ, я атрымаў адзін ключ дыяпазону.

1161
00:50:26,950 --> 00:50:27,783
>> Што гэта азначае?

1162
00:50:27,783 --> 00:50:30,410
Я атрымаў адзін атрыбут, што я
можа працаваць багатых запытаў да.

1163
00:50:30,410 --> 00:50:31,800
Гэта ключ дыяпазону.

1164
00:50:31,800 --> 00:50:35,530
Іншыя атрыбуты на гэтым item--
Я магу фільтраваць гэтых атрыбутаў.

1165
00:50:35,530 --> 00:50:40,050
Але я не магу рабіць рэчы, як, гэта
пачынаецца з або больш.

1166
00:50:40,050 --> 00:50:40,820
>> Як мне гэта зрабіць?

1167
00:50:40,820 --> 00:50:42,860
Я стварыць індэкс.

1168
00:50:42,860 --> 00:50:45,340
Там дзве тыпы
Індэксы ў DynamoDB.

1169
00:50:45,340 --> 00:50:49,002
Індэкс сапраўды
Яшчэ адзін від табліцы.

1170
00:50:49,002 --> 00:50:50,490
І мясцовы другасны індэкс.

1171
00:50:50,490 --> 00:50:51,781
>> Першы мы пагаворым аб.

1172
00:50:51,781 --> 00:50:57,740
Так мясцовыя другасныя якія суіснавалі
у тым жа раздзеле, што і дадзеныя.

1173
00:50:57,740 --> 00:51:00,240
І як такія, яны знаходзяцца на
і той жа фізічны вузел.

1174
00:51:00,240 --> 00:51:01,780
Яны, што мы называем паслядоўнай.

1175
00:51:01,780 --> 00:51:04,599
Значэнне, яны прызнаюць,
ад запісу разам з табліцай.

1176
00:51:04,599 --> 00:51:06,890
Калі запісу прыходзіць,
мы напішам праз індэкс.

1177
00:51:06,890 --> 00:51:09,306
Мы напішам да стала,
і тады мы будзем мець на ўвазе.

1178
00:51:09,306 --> 00:51:10,490
Дык вось паслядоўным.

1179
00:51:10,490 --> 00:51:13,174
Пасля таго, як запісы былі
прызнаў з табліцы,

1180
00:51:13,174 --> 00:51:15,090
гэта гарантуе, што
мясцовы другасны індэкс

1181
00:51:15,090 --> 00:51:18,380
будзе мець тое ж самае бачанне дадзеных.

1182
00:51:18,380 --> 00:51:22,390
Але тое, што яны дазваляюць вам рабіць гэта
вызначыць ключы альтэрнатыўныя далёкасці.

1183
00:51:22,390 --> 00:51:25,260
>> Давядзецца выкарыстоўваць аднолькавыя хэш
Ключ, як у асноўны табліцы,

1184
00:51:25,260 --> 00:51:29,050
таму што яны размешчаны сумесна на
той жа падзел, і яны адпавядаюць.

1185
00:51:29,050 --> 00:51:33,110
Але я магу стварыць індэкс
з рознымі ключамі далёкасці.

1186
00:51:33,110 --> 00:51:41,590
Так, напрыклад, калі б я меў вытворцу
што было сырым стол часткі ўваходзіць.

1187
00:51:41,590 --> 00:51:44,590
І сыравіну часткі прыходзяць у і
яны агрэгуе зборкі.

1188
00:51:44,590 --> 00:51:46,840
І, можа быць, ёсць водгук.

1189
00:51:46,840 --> 00:51:50,240
>> Любая частка, якая была зроблена гэтая
вытворца пасля гэтай даты,

1190
00:51:50,240 --> 00:51:52,840
Мне трэба, каб выцягнуць з маёй лініі.

1191
00:51:52,840 --> 00:51:55,950
Я магу круціцца індэкс
што будуць шукаць,

1192
00:51:55,950 --> 00:52:00,760
агрэгавання на дату
вытворчасць гэтай канкрэтнай часткі.

1193
00:52:00,760 --> 00:52:03,930
Так што, калі мой стол быў верхні ўзровень
ўжо хэшируется вытворцы,

1194
00:52:03,930 --> 00:52:07,655
можа быць, гэта было ўладкована на частку ID, я
можа стварыць індэкс выключэння гэтай табліцы

1195
00:52:07,655 --> 00:52:11,140
а хэш вытворцам і
вагалася ад даты вырабу.

1196
00:52:11,140 --> 00:52:14,490
І такім чынам я мог бы сказаць, усё, што
быў выраблены паміж гэтымі датамі,

1197
00:52:14,490 --> 00:52:16,804
Мне трэба, каб выцягнуць з лініі.

1198
00:52:16,804 --> 00:52:18,220
Так што гэта мясцовы другасны індэкс.

1199
00:52:18,220 --> 00:52:22,280
>> Яны маюць эфект
абмяжоўваючы хэш прастору ключоў.

1200
00:52:22,280 --> 00:52:24,360
Таму што яны суіснавалі
на тым жа вузле захоўвання,

1201
00:52:24,360 --> 00:52:26,860
яны абмяжоўваюць хэш-ключ
прастору 10 гігабайт.

1202
00:52:26,860 --> 00:52:28,950
DynamoDB, пад
сталы, будзе падзяліць

1203
00:52:28,950 --> 00:52:31,380
Ваш стол кожныя 10 гігабайт.

1204
00:52:31,380 --> 00:52:34,760
Калі вы кладзе 10 канцэртаў дадзеных у, мы
перайсці [ФН], і мы дадаем яшчэ адзін вузел.

1205
00:52:34,760 --> 00:52:38,120

1206
00:52:38,120 --> 00:52:42,070
>> Мы не будзем падзяліць LSI
па некалькіх раздзелах.

1207
00:52:42,070 --> 00:52:43,200
Мы разбіць табліцу.

1208
00:52:43,200 --> 00:52:44,679
Але мы не будзем падзяляць LSI.

1209
00:52:44,679 --> 00:52:46,470
Так гэта тое, што
Важна разумець,

1210
00:52:46,470 --> 00:52:50,070
калі вы робіце вельмі,
вельмі, вельмі вялікія навалы,

1211
00:52:50,070 --> 00:52:53,860
то вы будзеце абмяжоўвацца
10 гігабайт на вашым ВІС.

1212
00:52:53,860 --> 00:52:56,640
>> Калі гэта так, то мы можам
выкарыстоўваць глабальныя другасныя.

1213
00:52:56,640 --> 00:52:58,630
Глабальныя другасныя з'яўляюцца
сапраўды іншая табліца.

1214
00:52:58,630 --> 00:53:01,720
Яны існуюць, каб цалкам ад
бок з вашай першаснай табліцы.

1215
00:53:01,720 --> 00:53:04,680
І яны дазваляюць мне знайсці
зусім розныя структуры.

1216
00:53:04,680 --> 00:53:08,010
Так што думайце пра яго, як дадзеныя ўстаўляюцца
у двух розных табліц, структураваны

1217
00:53:08,010 --> 00:53:09,220
двума рознымі спосабамі.

1218
00:53:09,220 --> 00:53:11,360
>> Я магу вызначыць зусім
адрозніваецца хэш-ключ.

1219
00:53:11,360 --> 00:53:13,490
Я магу вызначыць зусім
іншая клавіша дыяпазону.

1220
00:53:13,490 --> 00:53:15,941
І я магу запусціць гэты
цалкам незалежна.

1221
00:53:15,941 --> 00:53:18,190
На самай справе, у мяне
падрыхтавана маю здольнасць чытання

1222
00:53:18,190 --> 00:53:21,090
і напісаць ёмістасць для майго
глабальныя другасныя індэксы

1223
00:53:21,090 --> 00:53:24,240
зусім незалежна
маёй асноўнай табліцы.

1224
00:53:24,240 --> 00:53:26,640
Калі я вызначаю, што індэкс, я кажу
гэта колькі чытаць і пісаць

1225
00:53:26,640 --> 00:53:28,610
Аб'ём ён збіраецца выкарыстоўваць.

1226
00:53:28,610 --> 00:53:31,490
>> І гэта асобная
ад маёй асноўнай табліцы.

1227
00:53:31,490 --> 00:53:35,240
Цяпер абодва індэкса дазволіць нам
не толькі вызначыць хэш і далёкасці ключы,

1228
00:53:35,240 --> 00:53:38,610
але яны дазваляюць нам
праекта дадатковых значэнняў.

1229
00:53:38,610 --> 00:53:44,950
Так што, калі я хачу, каб счытваць індэкс,
і я хачу, каб атрымаць набор дадзеных,

1230
00:53:44,950 --> 00:53:48,327
Мне не трэба, каб вярнуцца да галоўнага
Табліца, каб атрымаць дадатковыя атрыбуты.

1231
00:53:48,327 --> 00:53:50,660
Я магу спраектаваць гэтыя дадатковыя
атрыбутаў ў табліцы

1232
00:53:50,660 --> 00:53:53,440
падтрымаць доступу да файла.

1233
00:53:53,440 --> 00:53:57,700
Я ведаю, што мы, верагодна, атрымаць у некаторыя
сапраўды, really-- трапленне ў пустазелля

1234
00:53:57,700 --> 00:53:58,910
тут, на некаторыя з гэтых рэчаў.

1235
00:53:58,910 --> 00:54:02,725
Цяпер я атрымаў дрэйфаваць з гэтага.

1236
00:54:02,725 --> 00:54:07,320
>> АЎДЫТОРЫЯ: [неразборліва]
--table ключ меў на ўвазе, хэш?

1237
00:54:07,320 --> 00:54:08,840
Арыгінальны хэш?

1238
00:54:08,840 --> 00:54:09,340
Multi-рэйкі?

1239
00:54:09,340 --> 00:54:10,200
>> РВК Хулихэном: Так.

1240
00:54:10,200 --> 00:54:11,070
Так.

1241
00:54:11,070 --> 00:54:15,260
Ключ табліцы ў асноўным
паказвае назад да пункта.

1242
00:54:15,260 --> 00:54:19,280
Так індэкс з'яўляецца паказальнікам назад
арыгінальныя прадметы на стале.

1243
00:54:19,280 --> 00:54:22,910
Цяпер вы можаце выбраць, каб пабудаваць
індэкс, які мае толькі ключ табліцы,

1244
00:54:22,910 --> 00:54:24,840
і ніякіх іншых уласцівасцяў.

1245
00:54:24,840 --> 00:54:26,570
І чаму я мог бы зрабіць гэта?

1246
00:54:26,570 --> 00:54:28,570
Ну, можа быць, у мяне вельмі вялікія прадметы.

1247
00:54:28,570 --> 00:54:31,660
>> Я сапраўды толькі трэба ведаць which--
мой ўзор доступу можна сказаць,

1248
00:54:31,660 --> 00:54:33,760
якія ўтрымліваюць элементы гэтага гатэля?

1249
00:54:33,760 --> 00:54:35,780
Ня трэба вярнуць дэталь.

1250
00:54:35,780 --> 00:54:37,800
Мне проста трэба ведаць,
якія элементы ўтрымліваюць яго.

1251
00:54:37,800 --> 00:54:40,700
Такім чынам, вы можаце пабудаваць індэксы
што толькі ёсць ключ табліцы.

1252
00:54:40,700 --> 00:54:43,360
>> Але гэта, перш за ўсё, тое, што
індэкс ў базе даных для.

1253
00:54:43,360 --> 00:54:46,280
Гэта за тое, што ў стане хутка
вызначыць, якія запісы,

1254
00:54:46,280 --> 00:54:49,470
якія радкі, якія
элементы табліцы маюць

1255
00:54:49,470 --> 00:54:51,080
ўласцівасці, якія я шукаў.

1256
00:54:51,080 --> 00:54:53,610

1257
00:54:53,610 --> 00:54:54,860
>> СБИС, так як яны працуюць?

1258
00:54:54,860 --> 00:54:58,340
СБИС ў асноўным з'яўляюцца асінхроннымі.

1259
00:54:58,340 --> 00:55:02,570
Абнаўленне ўступае ў табліцы,
Табліца затым асінхронна абнаўляецца

1260
00:55:02,570 --> 00:55:03,720
усе вашы СБИС.

1261
00:55:03,720 --> 00:55:06,680
Вось чаму СБИС з'яўляюцца
у канчатковым выніку стасуюцца.

1262
00:55:06,680 --> 00:55:09,440
>> Важна адзначыць, што
калі вы будуеце СБИС,

1263
00:55:09,440 --> 00:55:13,110
і вы разумееце, вы ствараеце
іншае вымярэнне aggregation--

1264
00:55:13,110 --> 00:55:16,594
Зараз давайце казаць добры прыклад
тут вытворца.

1265
00:55:16,594 --> 00:55:19,260
Я думаю, што я, магчыма, казалі пра
вытворца медыцынскага прылады.

1266
00:55:19,260 --> 00:55:23,870
Вытворцы медыцынскіх вырабаў
часта маюць серыйныя нумары часткі.

1267
00:55:23,870 --> 00:55:28,070
Часткі, якія ўваходзяць у
замена тазасцегнавага ўсе

1268
00:55:28,070 --> 00:55:30,200
ёсць трохі серыйны нумар на іх.

1269
00:55:30,200 --> 00:55:33,584
І яны маглі б мільёны і
мільёны і мільярды частак

1270
00:55:33,584 --> 00:55:35,000
ва ўсіх прыладах, якія яны пастаўляюцца.

1271
00:55:35,000 --> 00:55:37,440
Ну, яны павінны аб'ядноўваць пад
розныя памеры, усе часткі

1272
00:55:37,440 --> 00:55:39,520
ў зборцы, усё
часткі, якія былі зробленыя

1273
00:55:39,520 --> 00:55:41,670
на некаторай лініі, усё
часткі, якія прыйшлі

1274
00:55:41,670 --> 00:55:44,620
у з пэўнай вытворцы
на пэўную дату.

1275
00:55:44,620 --> 00:55:47,940
І гэтыя навалы часам
ўстаць у мільярды.

1276
00:55:47,940 --> 00:55:50,550
>> Так што я працаваць з некаторымі з
гэтыя хлопцы, якія пакутуюць

1277
00:55:50,550 --> 00:55:53,156
таму што яны ствараюць
гэтыя навалы GINORMOUS

1278
00:55:53,156 --> 00:55:54,280
у іх другасных індэксаў.

1279
00:55:54,280 --> 00:55:57,070
Яны могуць мець сырыя часткі
табліца, прыходзіць як толькі хэш.

1280
00:55:57,070 --> 00:55:59,090
Кожная частка мае унікальны серыйны нумар.

1281
00:55:59,090 --> 00:56:00,975
Я выкарыстоўваю серыйны нумар, як хэш.

1282
00:56:00,975 --> 00:56:01,600
Гэта прыгожа.

1283
00:56:01,600 --> 00:56:04,160
Мой сыравіну табліца дадзеных распаўсюджваецца
па ўсёй ключавога прасторы.

1284
00:56:04,160 --> 00:56:05,930
Мой [? напісаць?]
[? праглынанне?] з'яўляецца дзіўным.

1285
00:56:05,930 --> 00:56:07,876
Я бяру шмат дадзеных.

1286
00:56:07,876 --> 00:56:09,500
Тады тое, што яны робяць, яны ствараюць GSI.

1287
00:56:09,500 --> 00:56:12,666
І я кажу, вы ведаеце, што, мне трэба, каб убачыць
усе часткі дадзенага вытворцы.

1288
00:56:12,666 --> 00:56:15,060
Ну, раптам я
прымаючы мільярда радкоў,

1289
00:56:15,060 --> 00:56:17,550
і запіхваць іх на
адзін вузел, таму што, калі

1290
00:56:17,550 --> 00:56:21,170
Я, як агрэгаваць
вытворца ID, як хэш,

1291
00:56:21,170 --> 00:56:25,410
і нумар у дыяпазоне,
затым усё раптам я

1292
00:56:25,410 --> 00:56:30,530
паставіўшы млрд часткі ў тое, што
гэты вытворца вызваліў мяне.

1293
00:56:30,530 --> 00:56:34,447
>> Гэта можа выклікаць шмат
ціску на GSI,

1294
00:56:34,447 --> 00:56:36,030
зноў, таму што я малатком адзін вузел.

1295
00:56:36,030 --> 00:56:38,350
Я стаўлю усе гэтыя
ўстаўляе ў адным вузле.

1296
00:56:38,350 --> 00:56:40,940
І гэта рэальная праблематычна кейс.

1297
00:56:40,940 --> 00:56:43,479
Зараз, я атрымаў добры дызайн
шаблон для, як вы пазбегнуць.

1298
00:56:43,479 --> 00:56:45,770
І гэта адна з праблем,
што я заўсёды працаваць.

1299
00:56:45,770 --> 00:56:49,590
Але тое, што адбываецца, з'яўляецца GSI можа
не хапае магутнасці запісу

1300
00:56:49,590 --> 00:56:52,330
каб быць у стане вылучыць ўсе тыя
радкоў у адным вузле.

1301
00:56:52,330 --> 00:56:55,390
І тое, што адбываецца потым гэта
першасны, табліца Кліент,

1302
00:56:55,390 --> 00:57:00,180
галоўная табліца будзе задушыў
таму што GSI не можа угнацца.

1303
00:57:00,180 --> 00:57:02,980
Так што мой курс будзе ўстаўка
падаюць на асноўнай табліцы

1304
00:57:02,980 --> 00:57:06,230
як мой GSI спрабуе не адставаць.

1305
00:57:06,230 --> 00:57:08,850
>> Добра, так GSI-х, ВІС,
які я павінен выкарыстоўваць?

1306
00:57:08,850 --> 00:57:12,290
ВІС стасуюцца.

1307
00:57:12,290 --> 00:57:13,750
GSI з'яўляюцца ў канчатковым рахунку адпавядае.

1308
00:57:13,750 --> 00:57:17,490
Калі гэта нармальна, я рэкамендую выкарыстоўваць
GSI, яны значна больш гнуткім.

1309
00:57:17,490 --> 00:57:20,270
ВІС могуць быць змадэляваныя як GSI.

1310
00:57:20,270 --> 00:57:27,040
І калі памер дадзеных у хэш-ключоў у
Ваша калекцыя перавышае 10 гігабайт,

1311
00:57:27,040 --> 00:57:31,050
то вы будзеце жадаць выкарыстоўваць што
GSI, таму што гэта проста жорсткі ліміт.

1312
00:57:31,050 --> 00:57:32,035
>> Добра, так маштабавання.

1313
00:57:32,035 --> 00:57:35,210

1314
00:57:35,210 --> 00:57:37,460
Прапускная ў Дынама БД, вы
становішча можа [неразборліва]

1315
00:57:37,460 --> 00:57:38,680
прапускная да стала.

1316
00:57:38,680 --> 00:57:42,740
У нас ёсць кліенты, якія маюць
падрыхтавана 60 billion--

1317
00:57:42,740 --> 00:57:45,970
робяць 60 млрд запытаў, рэгулярна
працуе на больш чым мільён запытаў

1318
00:57:45,970 --> 00:57:47,790
за секунду на нашых сталах.

1319
00:57:47,790 --> 00:57:50,360
Там на самай справе няма
Тэарэтычны мяжа таго, колькі

1320
00:57:50,360 --> 00:57:53,730
і як хутка табліца
можа працаваць у Дынама БД.

1321
00:57:53,730 --> 00:57:55,920
Ёсць некаторыя мяккія
ліміты на ваш рахунак

1322
00:57:55,920 --> 00:57:58,170
што мы ставім там так
што вы не сыходзіце з розуму.

1323
00:57:58,170 --> 00:58:00,070
Калі вы хочаце больш, чым
што не з'яўляецца праблемай.

1324
00:58:00,070 --> 00:58:00,820
Вы прыходзіце, паведаміце нам.

1325
00:58:00,820 --> 00:58:02,810
Мы падніміце дыск.

1326
00:58:02,810 --> 00:58:08,210
>> Кожная уліковы запіс абмежаваная нейкай ступені
у кожнай службе, проста з месца ў кар'ер

1327
00:58:08,210 --> 00:58:11,920
так што людзі не страчваюць розум
трапляюць у непрыемнасці.

1328
00:58:11,920 --> 00:58:12,840
Няма мяжы ў памеры.

1329
00:58:12,840 --> 00:58:14,940
Вы можаце змясціць любую колькасць
элементаў на стале.

1330
00:58:14,940 --> 00:58:17,620
Памер элемента з'яўляецца
абмяжоўваецца да 400 кілабайт кожны,

1331
00:58:17,620 --> 00:58:20,050
што б элемент не атрыбуты.

1332
00:58:20,050 --> 00:58:24,200
Так суме ўсіх атрыбутаў
абмяжоўваецца да 400 кілабайт.

1333
00:58:24,200 --> 00:58:27,300
І зноў жа, у нас ёсць
што мала ВІС пытанне

1334
00:58:27,300 --> 00:58:30,405
з мяжой 10 гігабайт на хэш.

1335
00:58:30,405 --> 00:58:33,280
АЎДЫТОРЫЯ: Невялікая колькасць, я прапускаю
тое, што вы казалі мне, што is--

1336
00:58:33,280 --> 00:58:36,830
АЎДЫТОРЫЯ: Так, 400 кілабайта
максімальны памер па кожным пункце.

1337
00:58:36,830 --> 00:58:39,570
Так элемент мае ўсе атрыбуты.

1338
00:58:39,570 --> 00:58:43,950
Так 400 Да агульны памер
гэтага элемента, 400 кілабайт.

1339
00:58:43,950 --> 00:58:46,170
Так усіх прыкмет
камбінаваныя ўсе дадзеныя

1340
00:58:46,170 --> 00:58:49,140
гэта ва ўсіх гэтых атрыбутаў,
закатаў у агульнай колькасці,

1341
00:58:49,140 --> 00:58:51,140
У цяперашні час мяжа пункт сёння 400 к.

1342
00:58:51,140 --> 00:58:54,390

1343
00:58:54,390 --> 00:58:57,046
Так маштабавання зноў, дасягаецца
пасродкам перагародак.

1344
00:58:57,046 --> 00:58:58,920
Прапускная здольнасць прадугледжаным
на ўзроўні табліцы.

1345
00:58:58,920 --> 00:59:00,160
І там сапраўды дзве ручкі.

1346
00:59:00,160 --> 00:59:02,400
Мы чыталі магутнасць
і напісаць ёмістасць.

1347
00:59:02,400 --> 00:59:05,530
>> Такім чынам, гэтыя карэктуюцца
незалежна адзін ад аднаго.

1348
00:59:05,530 --> 00:59:08,640
Мера РКО ў строга ўзгодненыя чытання.

1349
00:59:08,640 --> 00:59:13,005
ОК, так што калі вы кажаце, я хачу 1000
РКО-х тыя, строга паслядоўным,

1350
00:59:13,005 --> 00:59:14,130
тых, стасуюцца чытае.

1351
00:59:14,130 --> 00:59:17,130
Калі вы хочаце сказаць, што я
магчымае несупярэчны чытанне,

1352
00:59:17,130 --> 00:59:19,402
Вы можаце прадастаўленне 1000
РКО, вы ідзяце

1353
00:59:19,402 --> 00:59:21,840
каб атрымаць у канчатковым выніку 2,000
адпавядае чытае.

1354
00:59:21,840 --> 00:59:25,940
І палова цэны для тых,
у канчатковым выніку складаюцца ў чытае.

1355
00:59:25,940 --> 00:59:28,520
>> Зноў жа, рэгулюецца
незалежна адзін ад аднаго.

1356
00:59:28,520 --> 00:59:32,900
І ў іх ёсць throughput--
Калі вы спажываеце 100% ад вашага РКО,

1357
00:59:32,900 --> 00:59:35,960
вы не збіраецеся, каб паўплываць на
наяўнасць вашых правоў.

1358
00:59:35,960 --> 00:59:40,161
Такім чынам, яны цалкам
незалежныя адзін ад аднаго.

1359
00:59:40,161 --> 00:59:43,160
Добра, так што адзін з рэчаў, якія
Я коратка згадана было дросселирования.

1360
00:59:43,160 --> 00:59:44,320
Рэгуляванне дрэнна.

1361
00:59:44,320 --> 00:59:47,311
Рэгуляванне паказвае дрэнна не SQL.

1362
00:59:47,311 --> 00:59:50,310
Ёсць рэчы, якія мы можам зрабіць, каб дапамагчы
вам палегчыць дросселирование, што вам

1363
00:59:50,310 --> 00:59:51,040
адчуваюць.

1364
00:59:51,040 --> 00:59:53,240
Але лепшае рашэнне
каб гэта давайце

1365
00:59:53,240 --> 00:59:58,000
Погляд на тое, што вы робіце, таму што
ёсць анты-патэрнаў ў гульні тут.

1366
00:59:58,000 --> 01:00:02,140
>> Гэтыя рэчы, рэчы, як неаднародных
нагрузкі, гарачыя клавішы, гарачыя перагародкі.

1367
01:00:02,140 --> 01:00:06,210
Я ўдару асаблівую прастору ключоў
вельмі цяжка, па пэўных прычынах.

1368
01:00:06,210 --> 01:00:07,080
Чаму я гэта раблю?

1369
01:00:07,080 --> 01:00:08,710
Давайце зразумець.

1370
01:00:08,710 --> 01:00:10,427
Я змешваю мае гарачыя дадзеныя з халоднымі дадзеных.

1371
01:00:10,427 --> 01:00:12,510
Я дазваляю мае табліцы атрымаць
Велізарны, але там сапраўды

1372
01:00:12,510 --> 01:00:15,970
толькі некаторы падмноства дадзеных
гэта сапраўды цікава для мяне.

1373
01:00:15,970 --> 01:00:20,290
Такім чынам, для дадзеных часопіса, напрыклад, шмат
кліенты, яны атрымліваюць дадзеныя, аўтарызуйцеся кожны дзень.

1374
01:00:20,290 --> 01:00:22,490
Яны атрымалі велізарную колькасць дадзеных часопіса.

1375
01:00:22,490 --> 01:00:25,940
>> Калі вы толькі што дэмпінг ўсе часопіс
дадзеныя ў адной вялікай табліцы, з часам

1376
01:00:25,940 --> 01:00:28,070
гэтая табліца збіраецца атрымаць масіўнае.

1377
01:00:28,070 --> 01:00:30,950
Але я сапраўды зацікаўлены толькі ў
Апошнія 24 гадзін, апошнія сем дзён,

1378
01:00:30,950 --> 01:00:31,659
апошнія 30 дзён.

1379
01:00:31,659 --> 01:00:34,074
Як бы там ні прамежак часу
што я зацікаўлены ў пошуку

1380
01:00:34,074 --> 01:00:37,010
для падзеі, турбуе мяне, ці
падзея, якая мне цікава,

1381
01:00:37,010 --> 01:00:39,540
што адзіны раз, калі акно, што мне трэба.

1382
01:00:39,540 --> 01:00:42,470
Такім чынам, чаму я пакласці 10 гадоў
Варта каротажных дадзеных у табліцы?

1383
01:00:42,470 --> 01:00:45,030
Тое, што гэта выклікае гэта
табліца фрагмент.

1384
01:00:45,030 --> 01:00:45,880
>> Ён атрымлівае велізарную.

1385
01:00:45,880 --> 01:00:48,340
Гэта пачынае распаўсюджвацца з
на тысячы вузлоў.

1386
01:00:48,340 --> 01:00:51,380
А так як ваша здольнасць
так нізка, вы

1387
01:00:51,380 --> 01:00:54,090
на самай справе абмежаванні хуткасці на кожным
адзін з тых асобных вузлоў.

1388
01:00:54,090 --> 01:00:57,120
Такім чынам, давайце пачнем, гледзячы на ​​тое, як
мы згарнуць гэтую табліцу на працягу.

1389
01:00:57,120 --> 01:01:01,502
Як мы можам кіраваць, што дадзеныя трохі
лепш, каб пазбегнуць гэтых праблем.

1390
01:01:01,502 --> 01:01:02,710
І тое, што гэта падобна?

1391
01:01:02,710 --> 01:01:04,370
Гэта тое, што, што выглядае.

1392
01:01:04,370 --> 01:01:06,790
Гэта тое, што дрэнна NoSQL выглядае.

1393
01:01:06,790 --> 01:01:07,830
>> Я атрымаў гарачую клавішу тут.

1394
01:01:07,830 --> 01:01:10,246
Калі вы паглядзіце на баку тут,
гэта ўсе мае раздзелы.

1395
01:01:10,246 --> 01:01:12,630
Я атрымаў 16 раздзелаў тут
на гэтай канкрэтнай базы дадзеных.

1396
01:01:12,630 --> 01:01:13,630
Мы робім гэта ўвесь час.

1397
01:01:13,630 --> 01:01:15,046
Я запускаю гэта для кліентаў ўвесь час.

1398
01:01:15,046 --> 01:01:16,550
Гэта называецца цеплавой мапе.

1399
01:01:16,550 --> 01:01:20,590
Цеплавая карта кажа мне, як ты
доступу да вашай прастору ключоў.

1400
01:01:20,590 --> 01:01:23,700
І тое, што гэта кажа мне, гэта
што ёсць адзін канкрэтны Хэш

1401
01:01:23,700 --> 01:01:26,330
што гэты хлопец любіць
вельмі шмат, таму што ён

1402
01:01:26,330 --> 01:01:28,250
ударыўшы па ім сапраўды, сапраўды цяжка.

1403
01:01:28,250 --> 01:01:29,260
>> Такім чынам, сіні прыемна.

1404
01:01:29,260 --> 01:01:29,900
Нам падабаецца сіні.

1405
01:01:29,900 --> 01:01:30,720
Нам не падабаецца чырвоны колер.

1406
01:01:30,720 --> 01:01:33,120
Дзе ціск Реда
атрымлівае да 100%.

1407
01:01:33,120 --> 01:01:35,560
100%, цяпер вы будзеце задушыў.

1408
01:01:35,560 --> 01:01:39,030
Таму, калі вы бачыце чырвоныя лініі, як
this-- і гэта не толькі Дынама DB--

1409
01:01:39,030 --> 01:01:41,630
кожная база дадзеных NoSQL мае гэтую праблему.

1410
01:01:41,630 --> 01:01:44,640
Ёсць антишаблоны, якія могуць
кіраваць гэтымі тыпамі умоў.

1411
01:01:44,640 --> 01:01:49,070
Тое, што я раблю, я працую з кліентамі
каб палегчыць гэтыя ўмовы.

1412
01:01:49,070 --> 01:01:51,840
>> І тое, што гэта падобна?

1413
01:01:51,840 --> 01:01:54,260
І гэта становіцца найбольш
з Дынама DB прапускной здольнасці,

1414
01:01:54,260 --> 01:01:56,176
але гэта сапраўды становіцца
большасць з NoSQL.

1415
01:01:56,176 --> 01:01:58,740
Гэта не абмяжоўваецца Дынама.

1416
01:01:58,740 --> 01:02:02,050
Гэта я definitely--
выкарыстоўваецца для працы ў Монго.

1417
01:02:02,050 --> 01:02:04,090
Я знаёмы з многімі платформамі NoSQL.

1418
01:02:04,090 --> 01:02:06,830
Кожны чалавек мае гэтыя тыпы
гарачых ключавых праблем.

1419
01:02:06,830 --> 01:02:10,320
Каб атрымаць максімальную аддачу ад любой NoSQL
базы дадзеных, спецыяльна Дынама БД,

1420
01:02:10,320 --> 01:02:13,320
Вы хочаце, каб стварыць табліцы
дзе элемент хэш-ключ мае

1421
01:02:13,320 --> 01:02:18,590
вялікая колькасць розных значэнняў,
высокая ступень магутнасці.

1422
01:02:18,590 --> 01:02:22,530
Таму што гэта азначае, што я пішу
на мноства розных каўшоў.

1423
01:02:22,530 --> 01:02:24,870
>> Чым больш я ў вёдры
пісьмовай форме, тым больш верагодна,

1424
01:02:24,870 --> 01:02:29,100
Я распаўсюджваць гэтую нагрузку запісы або
прачытаць загрузіць з па некалькіх вузлах,

1425
01:02:29,100 --> 01:02:33,560
тым больш верагодна, я павінен мець
высокая прапускная здольнасць на стол.

1426
01:02:33,560 --> 01:02:37,440
А потым я хачу, каб быць значэння
прасіў даволі раўнамерна на працягу доўгага часу

1427
01:02:37,440 --> 01:02:39,430
і раўнамерна, як выпадковым чынам, наколькі гэта магчыма.

1428
01:02:39,430 --> 01:02:42,410
Ну, гэта даволі цікава,
таму што я не магу на самой справе

1429
01:02:42,410 --> 01:02:43,960
кантроль, калі карыстальнікі прыходзяць.

1430
01:02:43,960 --> 01:02:47,645
Так дастаткова сказаць, калі мы распаўсюджваем
рэчы з усёй ключавога прасторы,

1431
01:02:47,645 --> 01:02:49,270
мы, верагодна, будзе ў лепшай форме.

1432
01:02:49,270 --> 01:02:51,522
>> Там пэўная
колькасць часу дастаўкі

1433
01:02:51,522 --> 01:02:53,230
што вы не збіраецеся
каб быць у стане кантраляваць.

1434
01:02:53,230 --> 01:02:55,438
Але гэта на самай справе
два аспекты, якія мы маем,

1435
01:02:55,438 --> 01:02:58,800
прастору, доступ раўнамерна
распаўсюджванне, час, запыты

1436
01:02:58,800 --> 01:03:01,040
прыбываюць раўнамерна ў часе.

1437
01:03:01,040 --> 01:03:03,110
І калі гэтыя два
задавальняюцца ўмовы,

1438
01:03:03,110 --> 01:03:05,610
тое, што тое, што гэта
будзе выглядаць.

1439
01:03:05,610 --> 01:03:07,890
Гэта значна прыемней.

1440
01:03:07,890 --> 01:03:08,890
Мы сапраўды шчаслівыя тут.

1441
01:03:08,890 --> 01:03:10,432
Мы атрымалі вельмі нават мадэль доступу.

1442
01:03:10,432 --> 01:03:13,098
Так, можа быць, вы атрымліваеце
невялікае ціск кожны зараз і потым,

1443
01:03:13,098 --> 01:03:14,830
але нічога сапраўды занадта шырокая.

1444
01:03:14,830 --> 01:03:17,660
Так што гэта дзіўна, як шмат разоў,
калі я працую з кліентамі,

1445
01:03:17,660 --> 01:03:20,670
што першы графік з вялікай чырвоны
бар і ўсё, што выродлівыя жоўтыя гэта

1446
01:03:20,670 --> 01:03:23,147
паўсюль, мы
зроблена з ажыццяўленнем

1447
01:03:23,147 --> 01:03:24,980
праз пару месяцаў
паўторнага архітэктуры,

1448
01:03:24,980 --> 01:03:28,050
яны працуюць сапраўды такі ж
нагрузка ў той жа самы нагрузкі.

1449
01:03:28,050 --> 01:03:30,140
І гэта тое, што ён шукае, як цяпер.

1450
01:03:30,140 --> 01:03:36,600
Так што вы атрымліваеце з NoSQL з'яўляецца
Схема дадзеных, абсалютна

1451
01:03:36,600 --> 01:03:38,510
прывязаны да мадэлі доступу.

1452
01:03:38,510 --> 01:03:42,170
>> І вы можаце аптымізаваць гэтую схему дадзеных
падтрымаць гэтую мадэль доступу.

1453
01:03:42,170 --> 01:03:45,490
Калі вы гэтага не зробіце, то вы будзеце
каб убачыць гэтыя тыпы праблем

1454
01:03:45,490 --> 01:03:46,710
з тых гарачых клавіш.

1455
01:03:46,710 --> 01:03:50,518
>> АЎДЫТОРЫЯ: Ну, непазбежна некаторыя месцы
будуць гарачэй, чым іншыя.

1456
01:03:50,518 --> 01:03:51,450
>> РВК Хулихэном: Заўсёды.

1457
01:03:51,450 --> 01:03:51,960
Заўсёды.

1458
01:03:51,960 --> 01:03:54,620
Так, я маю на ўвазе заўсёды ёсць
a-- і зноў, ёсць

1459
01:03:54,620 --> 01:03:56,980
некаторыя шаблоны праектавання, мы пройдзем праз
што будзе казаць пра тое, як вы маеце справу

1460
01:03:56,980 --> 01:03:58,480
з гэтых супер вялікіх навал.

1461
01:03:58,480 --> 01:04:01,260
Я маю на ўвазе, я павінен мець іх,
як мы маем справу з імі?

1462
01:04:01,260 --> 01:04:03,760
Я атрымаў вельмі добрую прэцэдэнт
што мы будзем казаць пра тое, што для.

1463
01:04:03,760 --> 01:04:05,940
>> Добра, так што давайце казаць
аб некаторых кліенты цяпер.

1464
01:04:05,940 --> 01:04:06,950
Гэтыя хлопцы AdRoll.

1465
01:04:06,950 --> 01:04:08,990
Я не ведаю, калі вы
знаёмыя з AdRoll.

1466
01:04:08,990 --> 01:04:10,781
Вы, напэўна, убачыць іх
шмат у браўзэры.

1467
01:04:10,781 --> 01:04:14,230
Яны аб'яваў перанакіраванне, яны
найбуйнейшы аб'явы перанакіраванне бізнес

1468
01:04:14,230 --> 01:04:14,940
там.

1469
01:04:14,940 --> 01:04:17,792
Яны, як правіла, рэгулярна запускаць больш
60 млрд транзакцый у дзень.

1470
01:04:17,792 --> 01:04:20,000
Яны робяць больш за мільён
транзакцый у секунду.

1471
01:04:20,000 --> 01:04:22,660
Яны атрымалі даволі простую табліцу
структура, ажыўленых табліцы.

1472
01:04:22,660 --> 01:04:26,450
Гэта ў асноўным толькі
хэш ключ печыва,

1473
01:04:26,450 --> 01:04:29,010
дыяпазон дэмаграфічная
Катэгорыя, а затым

1474
01:04:29,010 --> 01:04:31,220
трэці атрыбут рахунак.

1475
01:04:31,220 --> 01:04:33,720
>> Такім чынам, мы ўсе павінны печыва ў
наш браўзэр ад гэтых хлопцаў.

1476
01:04:33,720 --> 01:04:35,900
І калі вы ідзяце да
ўдзел купец,

1477
01:04:35,900 --> 01:04:39,390
яны ў асноўным адзнака вас праз
розныя дэмаграфічныя катэгорыі.

1478
01:04:39,390 --> 01:04:42,070
Калі вы ідзяце на сайт і
вы кажаце, я хачу, каб гэты ad--

1479
01:04:42,070 --> 01:04:44,920
або ў асноўным не кажуць that--
але калі вы ідзяце на сайт

1480
01:04:44,920 --> 01:04:47,550
яны кажуць, што вы хочаце ўбачыць гэта аб'ява.

1481
01:04:47,550 --> 01:04:49,370
І яны ідуць атрымаць, што аб'ява ад AdRoll.

1482
01:04:49,370 --> 01:04:51,130
AdRoll выглядае вас на стале.

1483
01:04:51,130 --> 01:04:52,115
Яны знаходзяць свой печыва.

1484
01:04:52,115 --> 01:04:53,990
Рэкламадаўцы, якія распавядаюць
ім, я хачу кагосьці

1485
01:04:53,990 --> 01:04:58,632
хто сярэдняга ўзросту,
40-гадовы мужчына, у спорце.

1486
01:04:58,632 --> 01:05:01,590
І яны выйграюць вас у гэтых дэмаграфічных
і яны вырашаюць, ці няма

1487
01:05:01,590 --> 01:05:02,740
што гэта добрая рэклама для вас.

1488
01:05:02,740 --> 01:05:10,330
>> Цяпер у іх ёсць SLA з
іх рэкламныя правайдэры

1489
01:05:10,330 --> 01:05:14,510
каб забяспечыць суб-10 мілісекунду
Адказ на кожны запыт.

1490
01:05:14,510 --> 01:05:16,090
Так яны выкарыстоўваюць Дынама DB для гэтага.

1491
01:05:16,090 --> 01:05:18,131
Яны ўдару нам
мільён запытаў у секунду.

1492
01:05:18,131 --> 01:05:21,120
Яны ў стане зрабіць усё іх
пошукі, сартаванне за ўсё, што дадзеныя,

1493
01:05:21,120 --> 01:05:26,130
і атрымаць, што дадаць спасылку на што
рэкламадаўца ва ўзросце да 10 мілісекунд.

1494
01:05:26,130 --> 01:05:29,800
Гэта сапраўды даволі фенаменальны
Рэалізацыя, што яны маюць.

1495
01:05:29,800 --> 01:05:36,210
>> Гэтыя хлопцы actually--
Ці з'яўляюцца гэтыя хлопцы.

1496
01:05:36,210 --> 01:05:38,010
Я не ўпэўнены, калі гэта гэтыя хлопцы.

1497
01:05:38,010 --> 01:05:40,127
Можа быць гэтыя хлопцы.

1498
01:05:40,127 --> 01:05:42,210
У асноўным сказаў us-- няма, я
Не думаю, што гэта было іх.

1499
01:05:42,210 --> 01:05:43,000
Я думаю, што гэта быў хто-то яшчэ.

1500
01:05:43,000 --> 01:05:44,750
Я працаваў з
кліент, які сказаў мне,

1501
01:05:44,750 --> 01:05:47,040
што цяпер, калі яны
пайшоў Дынама БД, яны

1502
01:05:47,040 --> 01:05:50,330
марнаваць больш грошай на закусках для
іх каманда распрацоўнікаў кожны месяц

1503
01:05:50,330 --> 01:05:52,886
чым яны марнуюць на іх базе дадзеных.

1504
01:05:52,886 --> 01:05:54,760
Так гэта дасць вам
Ідэя эканоміі

1505
01:05:54,760 --> 01:05:57,889
што вы можаце атрымаць у Дынама БД велізарны.

1506
01:05:57,889 --> 01:05:59,430
Добра, dropcam іншай кампаніі.

1507
01:05:59,430 --> 01:06:02,138
Гэтыя хлопец накшталт of-- калі вы думаеце,
інтэрнэт рэчаў, dropcam

1508
01:06:02,138 --> 01:06:05,150
у асноўным інтэрнэт-відэа бяспекі.

1509
01:06:05,150 --> 01:06:06,660
Вы ставіце камеру там.

1510
01:06:06,660 --> 01:06:08,180
Камера мае дэтэктар руху.

1511
01:06:08,180 --> 01:06:10,290
Хто-то прыходзіць,
запускае ключавую кропку.

1512
01:06:10,290 --> 01:06:13,540
Камера пачынае запіс на некаторы час да
ён не выяўляе ніякага руху больш.

1513
01:06:13,540 --> 01:06:15,310
Кладзе гэта відэа на Інтэрнэце.

1514
01:06:15,310 --> 01:06:19,800
>> Dropcam была кампанія, якая
у асноўным перайшлі на Дынама БД

1515
01:06:19,800 --> 01:06:22,200
таму што яны адчуваюць
Вялізныя растуць болю.

1516
01:06:22,200 --> 01:06:25,820
І тое, што яны сказалі нам
раптам петабайт дадзеных.

1517
01:06:25,820 --> 01:06:28,070
Яны паняцця не мелі, іх абслугоўванне
будзе настолькі паспяховым.

1518
01:06:28,070 --> 01:06:32,310
Больш ўваходзяць відэа YouTube, чым
гэта тое, што гэтыя хлопцы атрымліваюць.

1519
01:06:32,310 --> 01:06:36,780
Яны выкарыстоўваюць DynamoDB адсочваць усе
метададзеныя ўсіх сваіх відэа ключавых момантаў.

1520
01:06:36,780 --> 01:06:40,282
>> Такім чынам, яны маюць S3 вядра яны штурхаюць
усе бінарныя артэфакты ст.

1521
01:06:40,282 --> 01:06:41,990
І тады яны маюць
Дынама DB запісу,

1522
01:06:41,990 --> 01:06:44,070
пазначыць людзям на гэтых трох аб'ектаў S3.

1523
01:06:44,070 --> 01:06:47,070
Калі яны павінны глядзець на відэа,
яны глядзяць запіс у Дынама БД.

1524
01:06:47,070 --> 01:06:47,903
Яны націсніце на спасылку.

1525
01:06:47,903 --> 01:06:49,770
Яны цягнуць уніз відэа з S3.

1526
01:06:49,770 --> 01:06:51,590
Так што накшталт як гэта выглядае.

1527
01:06:51,590 --> 01:06:53,580
І гэта прама з сваёй каманды.

1528
01:06:53,580 --> 01:06:56,010
>> Дынама БД памяншае іх
час дастаўкі для відэа падзей

1529
01:06:56,010 --> 01:06:57,590
ад пяці да 10 секунд.

1530
01:06:57,590 --> 01:07:00,470
У сваёй старой рэляцыйнай краме,
яны выкарыстоўвалі, каб мець, каб пайсці і выканаць

1531
01:07:00,470 --> 01:07:03,780
некалькі складаных запытаў да постаці
з якіх відэа, каб цягнуць ўніз,

1532
01:07:03,780 --> 01:07:06,690
да менш чым за 50 мілісекунд.

1533
01:07:06,690 --> 01:07:08,990
Так што гэта дзіўна, дзіўна
колькі эфектыўнасць

1534
01:07:08,990 --> 01:07:12,990
Вы можаце атрымаць, калі вы аптымізаваць і
Вы наладжваеце асноўнай базе дадзеных

1535
01:07:12,990 --> 01:07:15,110
падтрымаць доступу да файла.

1536
01:07:15,110 --> 01:07:20,500
Halfbrick, гэтыя хлопцы, што гэта,
Fruit Ninja Я думаю, гэта іх справа.

1537
01:07:20,500 --> 01:07:22,590
Гэта ўсё працуе на Дынама БД.

1538
01:07:22,590 --> 01:07:26,810
І гэтыя хлопцы, яны з'яўляюцца выдатным
Каманда распрацоўнікаў, вялікае развіццё

1539
01:07:26,810 --> 01:07:27,670
краму.

1540
01:07:27,670 --> 01:07:29,364
>> Ня добры АСС каманда.

1541
01:07:29,364 --> 01:07:31,280
Яны не маюць шмат
эксплуатацыйных рэсурсаў.

1542
01:07:31,280 --> 01:07:33,940
Яны змагаліся, спрабуючы захаваць
іх інфраструктура прыкладанняў да

1543
01:07:33,940 --> 01:07:34,290
і працуе.

1544
01:07:34,290 --> 01:07:35,000
Яны прыйшлі да нас.

1545
01:07:35,000 --> 01:07:36,251
Яны глядзелі на тое Дынама БД.

1546
01:07:36,251 --> 01:07:37,291
Яны сказалі, што гэта для нас.

1547
01:07:37,291 --> 01:07:39,470
Яны пабудавалі ўсю сваю
Структура прыкладання на ім.

1548
01:07:39,470 --> 01:07:43,640
Некаторыя сапраўды добрыя каментары тут
ад каманды на іх здольнасці

1549
01:07:43,640 --> 01:07:46,800
каб цяпер засяродзіцца на будаўніцтва
гульня, а не

1550
01:07:46,800 --> 01:07:49,010
таго, каб падтрымліваць
інфраструктура, якая

1551
01:07:49,010 --> 01:07:51,910
становіцца велізарная колькасць
накладных расходаў для сваёй каманды.

1552
01:07:51,910 --> 01:07:56,170
Так што гэта нешта that--
перавага, што вы атрымаеце ад Дынама БД.

1553
01:07:56,170 --> 01:08:00,930
>> Добра, трапляючы ў
мадэляванне дадзеных тут.

1554
01:08:00,930 --> 01:08:03,440
І мы казалі трохі аб
гэта адзін да аднаго, адзін да многіх,

1555
01:08:03,440 --> 01:08:05,060
і многія да многіх адносін тыпу.

1556
01:08:05,060 --> 01:08:07,630
А як вы падтрымліваеце тых, хто ў Дынама.

1557
01:08:07,630 --> 01:08:10,500
У Дынама БД мы выкарыстоўваем
Індэксы, наогул кажучы,

1558
01:08:10,500 --> 01:08:12,910
круціць дадзеныя
адзін густ да іншага.

1559
01:08:12,910 --> 01:08:15,210
Хэш-ключы, ключы дыяпазон, і індэксы.

1560
01:08:15,210 --> 01:08:18,540
>> У дадзеным канкрэтным
Напрыклад, як і большасць дзяржаў

1561
01:08:18,540 --> 01:08:23,802
ёсць патрабаванне ліцэнзавання,
толькі ліцэнзія аднаго кіроўцы на чалавека.

1562
01:08:23,802 --> 01:08:26,510
Вы не можаце пайсці, каб атрымаць двух кіроўцы
ліцэнзіі ў штаце Бостан.

1563
01:08:26,510 --> 01:08:27,500
Я не магу зрабіць гэта ў Тэхасе.

1564
01:08:27,500 --> 01:08:28,708
Гэта накшталт таго, як гэта.

1565
01:08:28,708 --> 01:08:32,779
І так у DMV, у нас ёсць аперацый пошуку, мы
хачу паглядзець пасведчанне кіроўцы

1566
01:08:32,779 --> 01:08:35,180
па колькасці сацыяльнага забеспячэння.

1567
01:08:35,180 --> 01:08:39,990
Я хачу, каб паглядзець інфармацыю пра карыстальніка
па колькасці ліцэнзій кіроўцы.

1568
01:08:39,990 --> 01:08:43,620
>> Такім чынам, мы, магчыма, табліцу карыстальніка, што
мае хэш-ключ на серыйны нумар,

1569
01:08:43,620 --> 01:08:47,830
або нумар сацыяльнага страхавання, і
розныя атрыбуты вызначаюцца па гэтым пункце.

1570
01:08:47,830 --> 01:08:49,859
У цяперашні час на гэтай табліцы I
можа вызначыць, што GSI

1571
01:08:49,859 --> 01:08:53,370
пераварочвае, што вакол, што я хачу, кажа,
ключавой хэш па ліцэнзіі, а затым

1572
01:08:53,370 --> 01:08:54,252
ўсе іншыя прадметы.

1573
01:08:54,252 --> 01:08:57,210
Цяпер, калі я хачу, каб запытваць і знайсці
Нумар ліцэнзіі для любой сацыяльнай

1574
01:08:57,210 --> 01:08:59,609
Нумар бяспекі, я магу
запыт асноўную табліцу.

1575
01:08:59,609 --> 01:09:02,130
>> Калі я хачу, каб запытаць і я хачу
каб атрымаць сацыяльнае забеспячэнне

1576
01:09:02,130 --> 01:09:05,735
нумар або іншыя атрыбуты з дапамогай
нумар ліцэнзіі, я магу запытаць GSI.

1577
01:09:05,735 --> 01:09:08,689
Гэтая мадэль, што адзін
да аднаго адносіны.

1578
01:09:08,689 --> 01:09:12,460
Проста вельмі просты GSI,
фліп гэтыя рэчы.

1579
01:09:12,460 --> 01:09:13,979
Цяпер, пагаворым аб адной для многіх.

1580
01:09:13,979 --> 01:09:16,450
Адзін да многіх у асноўным
Ваш ключ Дыяпазон хэш.

1581
01:09:16,450 --> 01:09:20,510
Дзе мы атрымліваем шмат з гэтым
Выкарыстанне выпадак дадзеныя манітора.

1582
01:09:20,510 --> 01:09:23,880
Дадзеныя маніторынгу рэгулярна пастаўляецца ў
Інтэрвал, як Інтэрнэт рэчаў.

1583
01:09:23,880 --> 01:09:26,890
Мы заўсёды атрымліваем усё гэта
запісы ў бліжэйшыя ўвесь час.

1584
01:09:26,890 --> 01:09:31,420
>> І я хачу, каб знайсці ўсе паказанні
паміж пэўны перыяд часу.

1585
01:09:31,420 --> 01:09:34,220
Гэта вельмі распаўсюджаная ў запыт
Маніторынг інфраструктуры.

1586
01:09:34,220 --> 01:09:38,430
Шлях ісці аб тым, што гэта, каб знайсці
простая структура табліцы, адна табліца.

1587
01:09:38,430 --> 01:09:42,250
Я атрымаў табліцу вымярэнняў прыбора
з ключом хэш на прыладу ID.

1588
01:09:42,250 --> 01:09:47,340
І ў мяне ёсць ключ дыяпазону на
пазнака, ці ў дадзеным выпадку, эпас.

1589
01:09:47,340 --> 01:09:50,350
І, што дазваляе мне выканаць комплекс
запыты да гэтага ключу дыяпазоне

1590
01:09:50,350 --> 01:09:54,950
і вярнуцца тыя запісы, якія
у параўнанні з вынікам

1591
01:09:54,950 --> 01:09:56,310
Устаноўлена, што я шукаю.

1592
01:09:56,310 --> 01:09:58,360
І ён будуе, што адна
для многіх адносінах

1593
01:09:58,360 --> 01:10:02,340
у асноўны табліцы, выкарыстоўваючы
хэш ключа, дыяпазон ключавой структурай.

1594
01:10:02,340 --> 01:10:04,600
>> Так што гэта свайго роду ўбудаваны
ў табліцы ў БД Дынама.

1595
01:10:04,600 --> 01:10:07,290
Калі я вызначыць хэш
і дыяпазон т стол, я

1596
01:10:07,290 --> 01:10:09,240
вызначэння адзін да многіх адносін.

1597
01:10:09,240 --> 01:10:12,770
Гэта адносіны бацька-дзіця.

1598
01:10:12,770 --> 01:10:14,620
>> Давайце пагаворым аб многіх
многіх адносінах.

1599
01:10:14,620 --> 01:10:19,170
І для гэтага канкрэтнага прыкладу,
зноў жа, мы збіраемся выкарыстоўваць GSI-х.

1600
01:10:19,170 --> 01:10:23,500
І давайце казаць аб гульнях
сцэнар, дзе ў мяне ёсць дадзены карыстальнік.

1601
01:10:23,500 --> 01:10:26,500
Я хачу, каб знайсці ўсе гульні, якія
ён зарэгістраваны або гуляючы ў.

1602
01:10:26,500 --> 01:10:29,600
А для дадзенай гульні, я
хачу знайсці ўсіх карыстальнікаў.

1603
01:10:29,600 --> 01:10:31,010
Так як я раблю гэта?

1604
01:10:31,010 --> 01:10:34,330
Мой карыстальнікаў гульні стол, я збіраюся
мець хэш-ключ ID карыстальніка

1605
01:10:34,330 --> 01:10:35,810
і ключ дыяпазон гульні.

1606
01:10:35,810 --> 01:10:37,810
>> Такім чынам, карыстальнік можа мець некалькі гульняў.

1607
01:10:37,810 --> 01:10:41,380
Гэта адзін да многіх адносін паміж
карыстальнік і гульні ён гуляе.

1608
01:10:41,380 --> 01:10:43,410
А потым на GSI,
Я фліп што вакол.

1609
01:10:43,410 --> 01:10:46,679
Я хэш на гульні і
Я дыяпазоне ад карыстальніка.

1610
01:10:46,679 --> 01:10:48,970
Так што, калі я хачу, каб усе
Гульня карыстальнік гуляе ў,

1611
01:10:48,970 --> 01:10:49,950
Я запытваць асноўную табліцу.

1612
01:10:49,950 --> 01:10:52,699
Калі я хачу, каб атрымаць усе карыстальнікі
якія гуляюць пэўную гульню,

1613
01:10:52,699 --> 01:10:53,887
Я запытаць GSI.

1614
01:10:53,887 --> 01:10:54,970
Такім чынам, вы бачыце, як мы гэта робім?

1615
01:10:54,970 --> 01:10:58,369
Вы будуеце для падтрымкі гэтых GSI гадоў
Прэцэдэнт, прыкладанне, доступ

1616
01:10:58,369 --> 01:10:59,410
ўзор, прыкладанне.

1617
01:10:59,410 --> 01:11:01,440
>> Калі мне трэба запытаць на
гэта вымярэнне, хай

1618
01:11:01,440 --> 01:11:03,500
мне стварыць індэкс па гэтым вымярэнні.

1619
01:11:03,500 --> 01:11:05,850
Калі я не раблю, я не хвалюе.

1620
01:11:05,850 --> 01:11:09,060
І ў залежнасці ад выпадку выкарыстання, я
магчыма, спатрэбіцца індэкс ці я не мог.

1621
01:11:09,060 --> 01:11:12,390
Калі гэта проста адзін да многіх,
асноўнай табліцы ў парадку.

1622
01:11:12,390 --> 01:11:15,860
Калі мне трэба зрабіць гэта шмат, каб
многія, або мне трэба зрабіць адзін для тых,

1623
01:11:15,860 --> 01:11:18,390
то, магчыма, мне трэба
на другое горада.

1624
01:11:18,390 --> 01:11:20,840
Так што ўсё залежыць ад
тое, што я спрабую зрабіць

1625
01:11:20,840 --> 01:11:24,550
і тое, што я спрабую атрымаць дасведчаны.

1626
01:11:24,550 --> 01:11:28,000
>> Верагодна, я не буду марнаваць занадта
шмат часу казаць пра дакументы.

1627
01:11:28,000 --> 01:11:31,460
Гэта становіцца трохі, напэўна,
глыбей, чым мы павінны ісці ў.

1628
01:11:31,460 --> 01:11:33,710
Давайце трохі пагаворым
аб багатых выраз запыту.

1629
01:11:33,710 --> 01:11:37,831
Такім чынам, у Дынама БД ў нас ёсць
здольнасць ствараць

1630
01:11:37,831 --> 01:11:39,330
што мы называем праекцыйныя выразы.

1631
01:11:39,330 --> 01:11:42,660
Праекцыйныя выразы проста
выбіраючы поля або значэння

1632
01:11:42,660 --> 01:11:44,290
што вы хочаце, каб адлюстраваць.

1633
01:11:44,290 --> 01:11:46,000
ОК, так што я магу зрабіць выбар.

1634
01:11:46,000 --> 01:11:48,010
Я раблю запыт да БД Дынама.

1635
01:11:48,010 --> 01:11:51,730
І я кажу, вы ведаеце, што, паказаць
мяне толькі пяць водгукі зоркі

1636
01:11:51,730 --> 01:11:54,544
для гэтага канкрэтнага прадукту.

1637
01:11:54,544 --> 01:11:55,710
Так што ўсё, што я хачу бачыць.

1638
01:11:55,710 --> 01:11:57,320
Я не хачу, каб убачыць усе
іншыя атрыбуты радкі,

1639
01:11:57,320 --> 01:11:58,319
Я проста хачу, каб гэта ўбачыць.

1640
01:11:58,319 --> 01:12:01,209
Гэта проста, як і ў SQL, калі вы
кажуць абярыце зорку або з табліцы,

1641
01:12:01,209 --> 01:12:02,000
Вы атрымліваеце ўсе.

1642
01:12:02,000 --> 01:12:05,450
Калі я кажу, абярыце імя з
стол, я толькі адзін атрыбут.

1643
01:12:05,450 --> 01:12:09,070
Гэта тое ж самае роду рэчы ў
Дынама БД ці яшчэ базы дадзеных NoSQL.

1644
01:12:09,070 --> 01:12:14,510
Фільтраваць выразы дазваляюць мне
у асноўным скараціць набор вынікаў ўніз.

1645
01:12:14,510 --> 01:12:15,540
Так што я зрабіць запыт.

1646
01:12:15,540 --> 01:12:17,260
Запыт можа вярнуцца з 500 пунктаў.

1647
01:12:17,260 --> 01:12:20,255
Але я хачу толькі тыя элементы, якія
ёсць атрыбут, які кажа, што гэта.

1648
01:12:20,255 --> 01:12:23,380
Такім чынам, давайце адфільтраваць гэтыя элементы
якія не адпавядаюць гэтай канкрэтнай запыт.

1649
01:12:23,380 --> 01:12:25,540
Такім чынам, мы маем выразы фільтра.

1650
01:12:25,540 --> 01:12:28,310
>> Фільтраваць выразы могуць
будзе працаваць на любы атрыбут.

1651
01:12:28,310 --> 01:12:30,260
Яны не хацелі інтэрвальныя запыты.

1652
01:12:30,260 --> 01:12:32,690
Павышэнне запыты больш выбарчым.

1653
01:12:32,690 --> 01:12:36,470
Фільтраваць запыты патрабуюць ад мяне, каб пайсці
атрымаць увесь набор вынікаў, а затым

1654
01:12:36,470 --> 01:12:39,170
выразаць дадзеныя, якія я не хачу.

1655
01:12:39,170 --> 01:12:40,660
Чаму гэта так важна?

1656
01:12:40,660 --> 01:12:42,770
Таму што я чытаў усё гэта.

1657
01:12:42,770 --> 01:12:46,597
У запыце, я буду чытаць і
гэта будзе гіганцкі аб дадзеных.

1658
01:12:46,597 --> 01:12:48,430
А потым я збіраюся
выразаць тое, што мне трэба.

1659
01:12:48,430 --> 01:12:52,080
І калі я толькі выразаючы
пара радкоў, то гэта нармальна.

1660
01:12:52,080 --> 01:12:53,620
Гэта не так неэфектыўна.

1661
01:12:53,620 --> 01:12:57,800
>> Але калі я чытаю цэлы стос
Дадзеныя, проста выразаць адзін элемент,

1662
01:12:57,800 --> 01:13:01,490
затым я збіраюся быць лепш
ад выкарыстання дыяпазону запыту,

1663
01:13:01,490 --> 01:13:03,030
таму што гэта значна больш выбарачна.

1664
01:13:03,030 --> 01:13:06,330
Гэта ўратуе мяне шмат
грошы, таму што я плаціць за гэта чытанне.

1665
01:13:06,330 --> 01:13:10,430
Калі вынікі, які вяртаецца
перасекчы гэтую дрот можа быць менш,

1666
01:13:10,430 --> 01:13:11,890
але я плачу за чытанне.

1667
01:13:11,890 --> 01:13:14,340
Так разумею, як
Вы атрымліваеце дадзеныя.

1668
01:13:14,340 --> 01:13:16,420
Гэта вельмі важна ў Дынама БД.

1669
01:13:16,420 --> 01:13:19,710
>> Ўмоўныя выразы, гэта тое, што
Вы маглі б назваць аптымістычнай блакавання.

1670
01:13:19,710 --> 01:13:28,470
Абнавіць, калі ёсць, ці, калі гэта значэнне
эквівалентна таго, што я паказваю.

1671
01:13:28,470 --> 01:13:31,494
І калі ў мяне ёсць штамп часу на
запіс, я мог бы прачытаць дадзеныя.

1672
01:13:31,494 --> 01:13:32,535
Я мог бы змяніць гэтыя дадзеныя.

1673
01:13:32,535 --> 01:13:35,030
Я мог бы пайсці пішуць, што
таму дадзеныя ў базу дадзеных.

1674
01:13:35,030 --> 01:13:38,100
Калі хто-то змяніў запіс,
адзнака часу можа быць зменены.

1675
01:13:38,100 --> 01:13:40,370
І такім чынам мой ўмоўна
абнаўленне можна сказаць, абнаўленне

1676
01:13:40,370 --> 01:13:42,340
калі адзнака роўная гэтага.

1677
01:13:42,340 --> 01:13:46,290
Або абнаўленне не будзе выканана, таму што хто-то
абнавіў рэкорд у той жа час.

1678
01:13:46,290 --> 01:13:48,290
>> Гэта тое, што мы называем аптымістычнае блякаваньне.

1679
01:13:48,290 --> 01:13:50,670
Гэта азначае, што нехта
можа прыйсці і змяніць яго,

1680
01:13:50,670 --> 01:13:53,100
і я збіраюся выявіць яго
калі я вярнуся, каб напісаць.

1681
01:13:53,100 --> 01:13:56,106
І тады я магу на самой справе чытаць, што
дадзеных і кажуць, ой, ён змяніў гэта.

1682
01:13:56,106 --> 01:13:57,230
Мне трэба, каб ўлічыць гэта.

1683
01:13:57,230 --> 01:14:00,490
І я магу змяніць дадзеныя ў маёй
запісваць і ўжываць яшчэ адно абнаўленне.

1684
01:14:00,490 --> 01:14:04,330
Такім чынам, вы можаце злавіць тых, дадатковых
Абнаўлення, якія адбываюцца паміж часам

1685
01:14:04,330 --> 01:14:08,740
што вы чытаеце дадзеныя і
раз, калі вы маглі б напісаць дадзеныя.

1686
01:14:08,740 --> 01:14:11,520
>> АЎДЫТОРЫЯ: І фільтр
Выраз на самай справе азначае не

1687
01:14:11,520 --> 01:14:13,020
нумар ці не--

1688
01:14:13,020 --> 01:14:14,316
>> [Рэле ГАЛАСЫ]

1689
01:14:14,316 --> 01:14:16,232
РВК Хулихэном: Я не буду
атрымаць занадта шмат у гэтым.

1690
01:14:16,232 --> 01:14:17,700
Гэта зарэзерваваныя слова.

1691
01:14:17,700 --> 01:14:20,130
Выгляд фунт стрыманы
Ключавое слова ў Дынама БД.

1692
01:14:20,130 --> 01:14:24,500
Кожная база дадзеных мае свой уласны абаронены
Імёны для калекцый вы не можаце выкарыстаць.

1693
01:14:24,500 --> 01:14:27,240
Дынама БД, калі вы пакажа
фунт перад гэтым,

1694
01:14:27,240 --> 01:14:29,310
Вы можаце вызначыць гэтыя імёны наверсе.

1695
01:14:29,310 --> 01:14:31,840
Гэта эталонны значэнне.

1696
01:14:31,840 --> 01:14:34,880
Гэта, верагодна, не самы лепшы сінтаксіс
ёсць там для гэтай дыскусіі,

1697
01:14:34,880 --> 01:14:38,090
таму што ён трапляе ў некаторых real--
Я быў бы гаварыць больш

1698
01:14:38,090 --> 01:14:41,360
пра тое, што на больш глыбокім узроўні.

1699
01:14:41,360 --> 01:14:46,130
>> Але досыць сказаць, што гэта магло б
быць запыт сканавання, дзе яны views--

1700
01:14:46,130 --> 01:14:50,190
ні праглядаў фунт больш, чым 10.

1701
01:14:50,190 --> 01:14:54,660
Гэта лікавае значэнне, так.

1702
01:14:54,660 --> 01:14:57,322
Калі вы хочаце, мы можам казаць пра
што пасля абмеркавання.

1703
01:14:57,322 --> 01:15:00,030
Добра, так што мы ўваходзім у
некаторыя сцэнары ў лепшых практык

1704
01:15:00,030 --> 01:15:02,000
дзе мы будзем казаць
аб некаторых праграмах тут.

1705
01:15:02,000 --> 01:15:03,810
Якія варыянты выкарыстання для Дынама БД.

1706
01:15:03,810 --> 01:15:06,120
Якія дызайн
ўзоры ў Дынама БД.

1707
01:15:06,120 --> 01:15:09,110
>> І першы, каго мы збіраемся
размовы пра з'яўляецца Інтэрнэт рэчаў.

1708
01:15:09,110 --> 01:15:15,010
Такім чынам, мы атрымліваем шмат of-- Я думаю,
тое, што it-- больш за 50%

1709
01:15:15,010 --> 01:15:19,370
трафіку ў інтэрнэце ў гэтыя дні
фактычна генеруецца машынамі,

1710
01:15:19,370 --> 01:15:21,930
аўтаматызаваныя працэсы, а не людзей.

1711
01:15:21,930 --> 01:15:25,140
Я маю на ўвазе гэтую рэч гэтая рэч, што
Вы насіць у кішэні,

1712
01:15:25,140 --> 01:15:28,840
колькі дадзеных, што гэтая рэч
на самай справе адпраўкі вакол без цябе

1713
01:15:28,840 --> 01:15:30,550
ведаючы, што гэта зусім дзіўнае.

1714
01:15:30,550 --> 01:15:34,970
Ваша месцазнаходжанне, інфармацыя
аб тым, як хутка вы ідзяце.

1715
01:15:34,970 --> 01:15:38,400
Як вы думаеце, Google Maps працы
калі яны кажуць вам, што трафік.

1716
01:15:38,400 --> 01:15:41,275
Гэта таму, што ёсць мільёны і
мільёны людзей па ўсім ваджэння

1717
01:15:41,275 --> 01:15:44,667
з тэлефонамі, якія пасылаюць
Дадзеныя па ўсім месцы ўвесь час.

1718
01:15:44,667 --> 01:15:46,500
Так адна з рэчаў,
аб гэтым тыпе дадзеных

1719
01:15:46,500 --> 01:15:50,980
што прыходзіць у дадзеныя манітора, увайсці
Дадзеныя, дадзеных часовых шэрагаў, з'яўляецца яго

1720
01:15:50,980 --> 01:15:53,540
як правіла, толькі цікава
для трохі часу.

1721
01:15:53,540 --> 01:15:55,580
Пасля гэтага часу, гэта
не так цікава.

1722
01:15:55,580 --> 01:15:58,390
Такім чынам, мы гаварылі, не дай
гэтыя табліцы растуць без межаў.

1723
01:15:58,390 --> 01:16:03,410
Ідэя тут у тым, што, можа быць, я атрымаў 24
гадзін коштам падзей у маім гарачай табліцы.

1724
01:16:03,410 --> 01:16:06,160
І, што гарачы стол будзе
падрыхтавана на вельмі высокай хуткасці,

1725
01:16:06,160 --> 01:16:07,950
таму што ён прымае шмат дадзеных.

1726
01:16:07,950 --> 01:16:10,920
Гэта займае шмат дадзеных
, І я чытаю яго шмат.

1727
01:16:10,920 --> 01:16:14,560
Я атрымаў шмат працы
запыты працуе супраць гэтага дадзеных.

1728
01:16:14,560 --> 01:16:18,120
>> Пасля 24 гадзін, эй, вы
ведаеце, я не хвалюе.

1729
01:16:18,120 --> 01:16:21,150
Так, можа быць, кожны поўнач я рол
мой стол да новай табліцы

1730
01:16:21,150 --> 01:16:22,430
і я вызвалення невыкарыстоўваемых гэтую табліцу.

1731
01:16:22,430 --> 01:16:26,440
І я вазьму РКО-х і
Ўніз WCU, таму што праз 24 гадзіны

1732
01:16:26,440 --> 01:16:28,630
Я не працуе, як многія
запыты да гэтых дадзеных.

1733
01:16:28,630 --> 01:16:30,200
Так што я іду, каб выратаваць грошы.

1734
01:16:30,200 --> 01:16:32,940
І, можа быць, праз 30 дзён я не
нават трэба клапаціцца пра яго ўсё.

1735
01:16:32,940 --> 01:16:35,020
Я мог бы ўзяць ВКУ-х
усё, аж да аднаго,

1736
01:16:35,020 --> 01:16:36,990
таму што вы ведаеце, што, гэта
ніколі не збіраецеся атрымаць запіс.

1737
01:16:36,990 --> 01:16:38,300
Дадзеныя 30 дзён.

1738
01:16:38,300 --> 01:16:40,000
Гэта ніколі не мяняецца.

1739
01:16:40,000 --> 01:16:44,200
>> І гэта амаль ніколі не адбываецца, каб атрымаць чытаць,
так што давайце проста лічыць, што RCU да 10.

1740
01:16:44,200 --> 01:16:49,372
І я эканомлю кучу грошай на гэта
дадзеных і плаціць толькі за мае гарачыя дадзеных.

1741
01:16:49,372 --> 01:16:52,330
Так што гэта важная рэч, каб шукаць
на тое, калі вы глядзіце на часовых шэрагаў

1742
01:16:52,330 --> 01:16:54,716
дадзеныя, якія паступаюць у ў аб'ёме.

1743
01:16:54,716 --> 01:16:55,590
Гэтыя стратэгіі.

1744
01:16:55,590 --> 01:16:58,010
Зараз, я мог дазволіць яго
усе ідуць у той жа табліцы

1745
01:16:58,010 --> 01:16:59,461
і хай гэтая табліца расці.

1746
01:16:59,461 --> 01:17:01,460
У рэшце рэшт, я збіраюся
см праблемы з прадукцыйнасцю.

1747
01:17:01,460 --> 01:17:04,060
Я збіраюся мець, каб пачаць архіваванне
некаторыя з гэтых дадзеных са стала,

1748
01:17:04,060 --> 01:17:04,720
што не.

1749
01:17:04,720 --> 01:17:07,010
>> Давайце лепш
распрацоўваць прыкладанне

1750
01:17:07,010 --> 01:17:08,900
так што вы можаце працаваць так добра.

1751
01:17:08,900 --> 01:17:11,460
Так што гэта проста аўтамат
у кодзе прыкладання.

1752
01:17:11,460 --> 01:17:13,580
Апоўначы кожную ноч
яна коціцца па стале.

1753
01:17:13,580 --> 01:17:17,170
Можа быць, тое, што мне трэба, гэта слізгаценне
Акно 24 гадзін дадзеных.

1754
01:17:17,170 --> 01:17:20,277
Тады на рэгулярнай аснове я
Выклік дадзеных са стала.

1755
01:17:20,277 --> 01:17:22,360
Я абрэзкі яго з
Крон праца, і я стаўлю яго

1756
01:17:22,360 --> 01:17:24,160
на гэтых іншых табліц,
што вам трэба.

1757
01:17:24,160 --> 01:17:25,940
Так што, калі перакульванне працуе, гэта выдатна.

1758
01:17:25,940 --> 01:17:27,080
Калі няма, абрэжце яе.

1759
01:17:27,080 --> 01:17:29,640
Але давайце трымаць, што гарачы дадзеныя
ад вашых халодных дадзеных.

1760
01:17:29,640 --> 01:17:32,535
Гэта зэканоміць вам шмат грошай, і
зрабіць вашыя табліцы больш дасканалых.

1761
01:17:32,535 --> 01:17:35,960

1762
01:17:35,960 --> 01:17:38,210
Такім чынам, наступная рэч, мы пагаворым
аб тым, каталог прадукцыі.

1763
01:17:38,210 --> 01:17:42,000
Каталог тавараў па-за
даволі часта кейс.

1764
01:17:42,000 --> 01:17:46,600
Гэта на самай справе вельмі агульны шаблон
што мы ўбачым у розных рэчаў.

1765
01:17:46,600 --> 01:17:48,870
Вы ведаеце, Twitter для
Напрыклад, гарачая твіт.

1766
01:17:48,870 --> 01:17:51,280
Усё ідзе і
хапаючы што ў твітэры.

1767
01:17:51,280 --> 01:17:52,680
Каталог тавараў, я атрымаў продажы.

1768
01:17:52,680 --> 01:17:54,120
Я атрымаў гарачую продаж.

1769
01:17:54,120 --> 01:17:57,277
Я атрымаў 70000 запытаў у
другое прышэсце для прадукту

1770
01:17:57,277 --> 01:17:58,860
Апісанне з майго каталога.

1771
01:17:58,860 --> 01:18:02,384
Мы бачым гэта на розніцу
аперацыя зусім няшмат.

1772
01:18:02,384 --> 01:18:03,550
Так як мы маем справу з гэтым?

1773
01:18:03,550 --> 01:18:04,924
Там няма ніякага спосабу, каб справіцца з гэтым.

1774
01:18:04,924 --> 01:18:07,110
Усе мае карыстальнікі хочуць, каб убачыць
тая ж частка дадзеных.

1775
01:18:07,110 --> 01:18:09,410
Яны прыходзяць у, адначасова.

1776
01:18:09,410 --> 01:18:11,920
І ўсе яны рабіць запыты
па той жа часткі дадзеных.

1777
01:18:11,920 --> 01:18:16,240
Гэта дае мне, што гарачая клавіша, што вялікая чырвоная
паласа на маёй карце, што нам не падабаецца.

1778
01:18:16,240 --> 01:18:17,720
І гэта, як гэта выглядае.

1779
01:18:17,720 --> 01:18:22,290
Так па маім ключавога прасторы я атрымліваю
забіў пунктаў продажу.

1780
01:18:22,290 --> 01:18:24,070
Я не атрымліваю нічога нідзе.

1781
01:18:24,070 --> 01:18:26,050
>> Як вырашыць гэтую праблему?

1782
01:18:26,050 --> 01:18:28,410
Ну, мы гэта з палегчыць кэша.

1783
01:18:28,410 --> 01:18:33,630
Кэш, вы паклалі ў асноўным у аператыўнай памяці
раздзел перад базе дадзеных.

1784
01:18:33,630 --> 01:18:37,260
Нам удалося
[Неразборліва] кэша, як вам

1785
01:18:37,260 --> 01:18:40,260
можа стварыць свой уласны кэш, [неразборліва]
Кэш [? в ,?], што вы хочаце.

1786
01:18:40,260 --> 01:18:42,220
Пакладзем, што ў пярэдняй часткі базы дадзеных.

1787
01:18:42,220 --> 01:18:47,250
І такім чынам вы можаце захоўваць гэтыя дадзеныя
ад тых гарачых клавіш у гэтай кэш-памяці

1788
01:18:47,250 --> 01:18:49,390
прастору і чытаць праз кэш.

1789
01:18:49,390 --> 01:18:51,962
>> І тады большасць вашых чытае
пачаць пошук, як гэта.

1790
01:18:51,962 --> 01:18:54,920
Я атрымаў усё гэта кэш-парад тут
і я нічога не атрымаў тут адбываецца

1791
01:18:54,920 --> 01:18:59,330
таму што база дадзеных седзячы ззаду
кэш і не чытае і не прыйсці да канца.

1792
01:18:59,330 --> 01:19:02,520
Калі я змяніць дадзеныя ў
базы дадзеных, у мяне ёсць для абнаўлення кэша.

1793
01:19:02,520 --> 01:19:04,360
Мы можам выкарыстоўваць нешта
як пары зрабіць гэта.

1794
01:19:04,360 --> 01:19:07,360
І я растлумачу, як гэта працуе.

1795
01:19:07,360 --> 01:19:09,060
Добра, паведамленнямі.

1796
01:19:09,060 --> 01:19:11,180
E-mail, мы ўсё выкарыстоўваем электронную пошту.

1797
01:19:11,180 --> 01:19:12,540
>> Гэта вельмі добры прыклад.

1798
01:19:12,540 --> 01:19:14,950
У нас ёсць нейкі паведамленняў стала.

1799
01:19:14,950 --> 01:19:17,040
І мы атрымалі паштовую скрыню і выходныя.

1800
01:19:17,040 --> 01:19:19,760
Гэта тое, што SQL будзе
Паглядзіце, як будаваць, што паштовую скрыню.

1801
01:19:19,760 --> 01:19:23,350
Мы накшталт выкарыстоўваць той жа самы выгляд
стратэгіі для выкарыстання GSI-х, GSI-х

1802
01:19:23,350 --> 01:19:25,320
для майго паштовага скрыні і маёй выходныя.

1803
01:19:25,320 --> 01:19:27,600
Так што я атрымаў паведамленні, якія паступаюць сыравіну
у мае паведамленні табліцы.

1804
01:19:27,600 --> 01:19:30,194
І першы падыход да гэтага
можа быць, не гавораць, ОК, няма праблем.

1805
01:19:30,194 --> 01:19:31,110
Я атрымаў зыходныя паведамленні.

1806
01:19:31,110 --> 01:19:33,710
Паведамленні, якія паступаюць [неразборліва],
ідэнтыфікатар паведамлення, гэта выдатна.

1807
01:19:33,710 --> 01:19:35,070
Гэта мой адзіны хэш.

1808
01:19:35,070 --> 01:19:38,280
Я збіраюся стварыць два GSI, адной
для майго паштовага скрыні, па адным для майго выходныя.

1809
01:19:38,280 --> 01:19:40,530
І першае, што я зраблю
, Я скажу, мой ключ хэш

1810
01:19:40,530 --> 01:19:43,310
будзе атрымальнік і
Я збіраюся ўладкаваць на сённяшні дзень.

1811
01:19:43,310 --> 01:19:44,220
Гэта фантастыка.

1812
01:19:44,220 --> 01:19:45,890
Я атрымаў добры выгляд тут.

1813
01:19:45,890 --> 01:19:47,780
Але ёсць невялікая праблема тут.

1814
01:19:47,780 --> 01:19:50,891
І вы сутыкнецеся гэта
рэляцыйныя базы дадзеных, а таксама.

1815
01:19:50,891 --> 01:19:52,390
Яны называлі вертыкальна разбіццё.

1816
01:19:52,390 --> 01:19:55,840
Вы хочаце, каб ваш вялікі дадзеныя
ад вашых маленькіх дадзеных.

1817
01:19:55,840 --> 01:20:00,470
>> І прычына, чаму, таму што я павінен
ісці чытаць пункты, каб атрымаць атрыбуты.

1818
01:20:00,470 --> 01:20:05,570
І калі мае органы ўсё тут,
затым чытанне ўсяго некалькі пунктаў

1819
01:20:05,570 --> 01:20:08,560
калі мой Даўжыня цела
у сярэднім 256 кілабайт кожны,

1820
01:20:08,560 --> 01:20:10,991
матэматыка становіцца даволі непрыгожа.

1821
01:20:10,991 --> 01:20:12,490
Так што я хачу, каб прачытаць ўваходныя Давіда.

1822
01:20:12,490 --> 01:20:14,520
Якія ўваходзяць Давіда мае 50 пунктаў.

1823
01:20:14,520 --> 01:20:17,880
Сярэдняя і памер 256 кілабайт.

1824
01:20:17,880 --> 01:20:21,730
Вось мой каэфіцыент канверсіі
для РКО з'яўляецца чатыры кілабайта.

1825
01:20:21,730 --> 01:20:24,450
>> ОК, давайце ісці з
у канчатковым выніку, несупярэчны чытанне.

1826
01:20:24,450 --> 01:20:28,640
Я да гэтага часу ёсць 1600-х РКО
проста чытаць ўваходныя Давіда.

1827
01:20:28,640 --> 01:20:29,950
Ай.

1828
01:20:29,950 --> 01:20:31,980
Добра, зараз давайце падумаем
пра тое, як працуе прыкладанне.

1829
01:20:31,980 --> 01:20:35,340
Калі я знаходжуся ў паштовай дадатку і
Я гляджу на маю паштовую скрыню,

1830
01:20:35,340 --> 01:20:39,680
і я гляджу на целе кожнага паведамлення,
няма, я гляджу на рэзюмэ.

1831
01:20:39,680 --> 01:20:41,850
Я гляджу на толькі загалоўкі.

1832
01:20:41,850 --> 01:20:46,310
Такім чынам, давайце будаваць структуру табліцы
што больш падобна, што.

1833
01:20:46,310 --> 01:20:49,470
>> Дык вось інфармацыя
што мой працоўны працэс патрэбаў.

1834
01:20:49,470 --> 01:20:50,890
Гэта ў маю паштовую скрыню GSI.

1835
01:20:50,890 --> 01:20:53,800
Гэта дата, адпраўнік,
прадметам, а затым

1836
01:20:53,800 --> 01:20:56,790
ідэнтыфікатар паведамлення, які паказвае
вярнуцца да табліцы паведамленняў

1837
01:20:56,790 --> 01:20:57,850
дзе я магу атрымаць цела.

1838
01:20:57,850 --> 01:21:01,260

1839
01:21:01,260 --> 01:21:04,420
Ну, гэта было б запісваць ідэнтыфікатары.

1840
01:21:04,420 --> 01:21:09,850
Яны паказваюць назад да
ідэнтыфікатары пункт на стале Дынама DB.

1841
01:21:09,850 --> 01:21:12,220
Кожны індэкс заўсёды creates--
заўсёды мае элемент

1842
01:21:12,220 --> 01:21:15,750
ID, як частка of--, што
прыходзіць з індэксам.

1843
01:21:15,750 --> 01:21:17,414
>> Добра.

1844
01:21:17,414 --> 01:21:19,080
АЎДЫТОРЫЯ: Гэта кажа яго там, дзе ён захоўваецца?

1845
01:21:19,080 --> 01:21:21,420
РВК Хулихэном: Так, ён кажа
exactly--, што менавіта, што яна робіць.

1846
01:21:21,420 --> 01:21:22,644
Гэта кажа, вось мой паўторна запіс.

1847
01:21:22,644 --> 01:21:24,310
І гэта будзе паказваць яго назад у маёй паўторнай запісу.

1848
01:21:24,310 --> 01:21:26,460
Дакладна.

1849
01:21:26,460 --> 01:21:29,490
ОК, так што зараз маю паштовую скрыню з'яўляецца
фактычна нашмат менш.

1850
01:21:29,490 --> 01:21:32,210
І гэта на самай справе падтрымлівае
працоўны працэс электроннай прыкладанне.

1851
01:21:32,210 --> 01:21:34,230
Так маю паштовую скрыню, я націскаю.

1852
01:21:34,230 --> 01:21:38,160
Я іду ўздоўж і я націскаю на паведамленні,
што, калі мне трэба пайсці атрымаць цела,

1853
01:21:38,160 --> 01:21:40,180
таму што я збіраюся
перайсці на іншую пункт гледжання.

1854
01:21:40,180 --> 01:21:43,870
Так што, калі вы думаеце, пра тып MVC ў
рамкі, выгляд мадэлі кантролера.

1855
01:21:43,870 --> 01:21:46,120
>> Мадэль змяшчае
Дадзеныя пра тое, што патрэбы выгляд

1856
01:21:46,120 --> 01:21:48,130
і кантролер ўзаемадзейнічае з.

1857
01:21:48,130 --> 01:21:51,670
Калі я змяніць рамку пры
Змяніць перспектыву,

1858
01:21:51,670 --> 01:21:55,080
гэта нармальна, каб вярнуцца да
Сервер і засяліць мадэль,

1859
01:21:55,080 --> 01:21:56,860
таму што гэта тое, што чакае карыстальнік.

1860
01:21:56,860 --> 01:22:00,530
Калі яны змяніць погляды, што, калі
мы можам вярнуцца да базы дадзеных.

1861
01:22:00,530 --> 01:22:02,480
Так электроннай пошты, націсніце.

1862
01:22:02,480 --> 01:22:03,710
Я шукаю для цела.

1863
01:22:03,710 --> 01:22:04,330
Паездка туды і назад.

1864
01:22:04,330 --> 01:22:05,680
Перайсці атрымаць цела.

1865
01:22:05,680 --> 01:22:06,950
>> Я чытаў шмат менш дадзеных.

1866
01:22:06,950 --> 01:22:09,960
Я толькі чытаў, што органы
Дэвід павінен, калі ён мае патрэбу ў іх.

1867
01:22:09,960 --> 01:22:14,230
І я не гараць у 1600
РКО проста, каб паказаць сваю паштовую скрыню.

1868
01:22:14,230 --> 01:22:17,670
Так што цяпер that-- гэта шлях
што LSI або GSI-- я прашу прабачэння,

1869
01:22:17,670 --> 01:22:19,900
GSI, будзе працаваць.

1870
01:22:19,900 --> 01:22:25,450
Мы атрымалі наш хэш на атрымальніка.

1871
01:22:25,450 --> 01:22:27,030
Мы атрымалі ключ дыяпазон на сённяшні дзень.

1872
01:22:27,030 --> 01:22:31,380
І ў нас ёсць прагназуемыя атрыбуты
што нам патрэбныя толькі для падтрымкі гледжання.

1873
01:22:31,380 --> 01:22:34,300
>> Мы круцяцца, што для паштовага скрыні.

1874
01:22:34,300 --> 01:22:35,770
Hash на адпраўніка.

1875
01:22:35,770 --> 01:22:39,612
А па сутнасці, мы маем
вельмі добры, чысты выгляд.

1876
01:22:39,612 --> 01:22:41,570
І гэта мы basically--
ёсць добрыя паведамленні ў гэтую

1877
01:22:41,570 --> 01:22:45,870
Табліца, якая распаўсюджваецца прыгожа, таму што
гэта хэш толькі хэш паведамленне ID.

1878
01:22:45,870 --> 01:22:51,750
І ў нас ёсць два індэкса, што
круцяцца з той табліцы.

1879
01:22:51,750 --> 01:22:57,411
Добра, так ідэя тут заключаецца ня
трымаць вялікія дадзеныя і гэты невялікі дадзеныя

1880
01:22:57,411 --> 01:22:57,910
разам.

1881
01:22:57,910 --> 01:23:00,700
Partition вертыкальна,
падзяліць гэтыя табліцы.

1882
01:23:00,700 --> 01:23:03,150
Не чытайце дадзеныя, якія вы не павінны.

1883
01:23:03,150 --> 01:23:04,850
Добра, гульнявой.

1884
01:23:04,850 --> 01:23:06,990
Мы ўсе хацелі гульняў.

1885
01:23:06,990 --> 01:23:10,902
Прынамсі, мне падабаецца гульні, то.

1886
01:23:10,902 --> 01:23:12,735
Такім чынам, некаторыя з рэчаў,
што мы маем справу з тым, калі

1887
01:23:12,735 --> 01:23:14,193
мы думаем аб гульнях, ці не так?

1888
01:23:14,193 --> 01:23:16,999
Gaming гэтыя дні, асабліва з мабільнага
гульні, гэта ўсё аб мысленні.

1889
01:23:16,999 --> 01:23:19,540
І я збіраюся павярнуць тут
трохі ад DynamoDB.

1890
01:23:19,540 --> 01:23:21,373
Я збіраюся прынесці ў
некаторыя з абмеркавання

1891
01:23:21,373 --> 01:23:24,240
вакол некаторых з
іншыя тэхналогіі AWS.

1892
01:23:24,240 --> 01:23:28,930
>> Але ідэя аб гульнях, каб думаць
аб у тэрмінах інтэрфейсаў API інтэрфейсы, якія,

1893
01:23:28,930 --> 01:23:31,730
наогул кажучы, HTTP і JSON.

1894
01:23:31,730 --> 01:23:34,550
Гэта, як мабільныя гульні выгляд
ўзаемадзейнічаюць з іх канцамі таму.

1895
01:23:34,550 --> 01:23:35,850
Яны робяць JSON рэгістрацыю.

1896
01:23:35,850 --> 01:23:40,660
Яны атрымліваюць дадзеныя, і ўсё гэта,
наогул кажучы, у добрых інтэрфейсаў JSON.

1897
01:23:40,660 --> 01:23:44,950
>> Такія рэчы, як завесці сяброў, атрымаць
дадзеныя лідэраў, абмен,

1898
01:23:44,950 --> 01:23:47,699
карыстацкі кантэнт,
адсунуць да сістэмы,

1899
01:23:47,699 --> 01:23:49,740
гэтыя тыпы рэчаў
што мы збіраемся рабіць.

1900
01:23:49,740 --> 01:23:52,542
Двайковыя дадзеныя актываў, гэтыя дадзеныя
не можа сядзець у базе дадзеных.

1901
01:23:52,542 --> 01:23:54,250
Гэта можа сядзець у
Аб'ект магазін, правільна?

1902
01:23:54,250 --> 01:23:56,541
Але база дадзеных будзе
у канчатковым выніку кажу сістэму,

1903
01:23:56,541 --> 01:23:59,140
распавядаючы прыкладанне
куды ісці атрымаць яго.

1904
01:23:59,140 --> 01:24:03,550
І непазбежна, мультыплэер
серверы, на канец інфраструктуры таму,

1905
01:24:03,550 --> 01:24:06,180
і прызначаны для высокага
даступнасць і маштабаванасць.

1906
01:24:06,180 --> 01:24:09,400
Такім чынам, гэтыя рэчы, якія мы ўсе хочам
у гульнявым інфраструктуры сёння.

1907
01:24:09,400 --> 01:24:12,160
>> Такім чынам, давайце зірнем на
як гэта выглядае.

1908
01:24:12,160 --> 01:24:16,070
Ёсць асноўны задні канец,
вельмі простая.

1909
01:24:16,070 --> 01:24:19,880
Мы атрымалі сістэму тут з
некалькі зон даступнасці.

1910
01:24:19,880 --> 01:24:23,780
Мы гаварылі пра АЗС у being-- думаю
з іх у выглядзе асобных цэнтраў апрацоўкі дадзеных.

1911
01:24:23,780 --> 01:24:26,040
Цэнтр Больш дадзеныя
за AZ, але гэта нармальна,

1912
01:24:26,040 --> 01:24:28,831
проста думаць пра іх як асобныя дадзеныя
цэнтры, якія геаграфічна

1913
01:24:28,831 --> 01:24:30,090
і вылучаюць віна.

1914
01:24:30,090 --> 01:24:32,172
>> Мы збіраемся, каб мець
выпадкі пара EC2.

1915
01:24:32,172 --> 01:24:33,880
Мы збіраемся, каб мець
некаторыя задняй часткі сервера.

1916
01:24:33,880 --> 01:24:35,800
Можа быць, калі вы спадчына
архітэктура, мы

1917
01:24:35,800 --> 01:24:38,920
выкарыстоўваючы тое, што мы называем RDS,
рэляцыйныя базы дадзеных. паслугі

1918
01:24:38,920 --> 01:24:42,040
Можа быць MSSQL, MySQL,
ці нешта падобнае.

1919
01:24:42,040 --> 01:24:47,080
Гэта шлях шмат прыкладанняў
прызначаныя сёння.

1920
01:24:47,080 --> 01:24:49,594
>> Ну, мы маглі б пайсці з
гэта калі мы маштабаваць.

1921
01:24:49,594 --> 01:24:51,510
Мы пойдзем наперад і пакласці
вядро там S3.

1922
01:24:51,510 --> 01:24:54,200
І, што S3 вядро, а не служыць
да тых аб'ектаў, з нашага servers--

1923
01:24:54,200 --> 01:24:55,220
мы маглі б гэта зрабіць.

1924
01:24:55,220 --> 01:24:57,210
Вы ставіце ўсе вашы двайковы
аб'екты на вашых серверах

1925
01:24:57,210 --> 01:24:59,751
і вы можаце выкарыстоўваць гэтыя сервера
выпадкі, каб служыць, што дадзеныя меры.

1926
01:24:59,751 --> 01:25:01,860
Але гэта даволі дорага.

1927
01:25:01,860 --> 01:25:05,107
>> Лепшы спосаб зрабіць гэта пайсці наперад і
пакласці гэтыя прадметы ў S3 вядра.

1928
01:25:05,107 --> 01:25:06,315
S3 з'яўляецца рэпазітары аб'екта.

1929
01:25:06,315 --> 01:25:10,860
Ён пабудаваны спецыяльна для
выступае гэтыя тыпы рэчаў.

1930
01:25:10,860 --> 01:25:13,690
І хай тыя кліенты просяць
непасрэдна з гэтых аб'ектаў вядра,

1931
01:25:13,690 --> 01:25:15,390
разгрузіць серверы.

1932
01:25:15,390 --> 01:25:17,020
Такім чынам, мы пачынаем маштабаваць тут.

1933
01:25:17,020 --> 01:25:19,140
>> Зараз мы атрымалі карыстальнікі па ўсім свеце.

1934
01:25:19,140 --> 01:25:19,730
Я атрымаў карыстальнікі.

1935
01:25:19,730 --> 01:25:23,380
Мне трэба, каб змесціва лакальна
размешчаны недалёка ад гэтых карыстальнікаў, правільна?

1936
01:25:23,380 --> 01:25:26,200
Я стварыў вядро S3
як мой рэпазітары.

1937
01:25:26,200 --> 01:25:29,370
І я фронт, які з
размеркаванне CloudFront.

1938
01:25:29,370 --> 01:25:31,720
>> CloudFront з'яўляецца кампакт-дыск і
Змест сетку дастаўкі.

1939
01:25:31,720 --> 01:25:35,750
У асноўным гэта бярэ дадзеныя, якія вы паказваеце
і кэшуецца ўсё гэта праз Інтэрнэт

1940
01:25:35,750 --> 01:25:39,230
так што карыстальнікі ва ўсім свеце могуць мець
вельмі хуткі адказ, калі

1941
01:25:39,230 --> 01:25:40,960
яны просяць гэтыя аб'екты.

1942
01:25:40,960 --> 01:25:41,960
>> Такім чынам, вы атрымаеце ўяўленне.

1943
01:25:41,960 --> 01:25:48,230
Вы накшталт выкарыстоўваючы ўсе
аспекты AWS тут, каб атрымаць гэта зрабіць.

1944
01:25:48,230 --> 01:25:50,790
І ў рэшце рэшт, мы кідаем
у аўто маштабавання групы.

1945
01:25:50,790 --> 01:25:52,737
Такім чынам, нашы выпадках AC2
нашых гульнявых сервераў,

1946
01:25:52,737 --> 01:25:54,820
як яны пачынаюць атрымліваць заняты
і больш занятымі і больш занятымі,

1947
01:25:54,820 --> 01:25:57,236
яны проста круцяцца іншы
Асобнік, спіна яшчэ адзін асобнік,

1948
01:25:57,236 --> 01:25:58,210
спіна яшчэ адзін асобнік.

1949
01:25:58,210 --> 01:26:02,090
Так тэхналогіі AWS мае, гэта
дазваляе задаць параметры

1950
01:26:02,090 --> 01:26:04,650
вакол якога серверы будуць расці.

1951
01:26:04,650 --> 01:26:08,110
Такім чынам, вы можаце мець н колькасць сервераў
там у любы момант часу.

1952
01:26:08,110 --> 01:26:11,870
І калі ваш груз сыходзіць, яны будуць
скароціцца колькасць будзе скарачацца.

1953
01:26:11,870 --> 01:26:15,250
І калі нагрузка вяртаецца,
гэта будзе расці назад, трывалае.

1954
01:26:15,250 --> 01:26:17,050
>> Так што гэта выглядае выдатна.

1955
01:26:17,050 --> 01:26:19,800
У нас ёсць шмат выпадкаў EC2.

1956
01:26:19,800 --> 01:26:21,671
Мы можам кэша
Пярэдняя баз дадзеных,

1957
01:26:21,671 --> 01:26:23,045
паспрабаваць паскорыць базы дадзеных.

1958
01:26:23,045 --> 01:26:25,030
Наступны пункт ціск
як правіла, людзі бачаць

1959
01:26:25,030 --> 01:26:28,850
гэта яны маштабаваць гульню з дапамогай
рэляцыйная сістэма базы дадзеных.

1960
01:26:28,850 --> 01:26:30,790
Божа, база дадзеных
прадукцыйнасць страшна.

1961
01:26:30,790 --> 01:26:31,932
Як мы можам палепшыць, што?

1962
01:26:31,932 --> 01:26:33,640
Давайце паспрабуем пакласці
кэш перад гэтым.

1963
01:26:33,640 --> 01:26:36,780
>> Ну, кэш не працуе
настолькі вялікі, у гульнях, ці не так?

1964
01:26:36,780 --> 01:26:39,330
Для гульняў, напісанне з'яўляецца хваравітым.

1965
01:26:39,330 --> 01:26:40,930
Гульні вельмі цяжкі напісаць.

1966
01:26:40,930 --> 01:26:43,610
Кэш не працуе, калі вы
напісаць цяжкіх, таму што вы заўсёды

1967
01:26:43,610 --> 01:26:44,610
атрымаў абнавіць кэш.

1968
01:26:44,610 --> 01:26:47,780
Вы абнавіць кэш, гэта
не мае значэння для кэшавання.

1969
01:26:47,780 --> 01:26:49,780
Гэта на самай справе проста дадатковая праца.

1970
01:26:49,780 --> 01:26:51,970
>> Так, куды мы ідзем тут?

1971
01:26:51,970 --> 01:26:54,400
У вас ёсць вялікі вузкае
там у базе дадзеных.

1972
01:26:54,400 --> 01:26:57,661
І месца, каб пайсці
відавочна, падзелу.

1973
01:26:57,661 --> 01:26:59,410
Разметка ня
лёгка зрабіць, калі вы

1974
01:26:59,410 --> 01:27:01,900
справу з рэляцыйнымі базамі дадзеных.

1975
01:27:01,900 --> 01:27:05,080
З рэляцыйнымі базамі дадзеных, вы
адказнасць за кіраванне, эфектыўна,

1976
01:27:05,080 --> 01:27:06,210
прастору ключоў.

1977
01:27:06,210 --> 01:27:10,527
Вы кажаце карыстальнікаў паміж А і М
ідзі сюды, паміж N і Z туды.

1978
01:27:10,527 --> 01:27:12,360
І вы пераходзіце
па ўжыванні.

1979
01:27:12,360 --> 01:27:15,000
Такім чынам, вы маеце справу з
гэты раздзел крыніцы дадзеных.

1980
01:27:15,000 --> 01:27:18,670
Вы павінны транзакцыйных абмежаванняў
якія не ахопліваюць раздзелы.

1981
01:27:18,670 --> 01:27:20,560
Вы атрымалі ўсе віды
бязладзіцы, што вы

1982
01:27:20,560 --> 01:27:23,040
справу з там спрабуюць
мець справу з маштабаванне

1983
01:27:23,040 --> 01:27:25,120
і будаўніцтва большага інфраструктуры.

1984
01:27:25,120 --> 01:27:27,284
Гэта не проста не цікава.

1985
01:27:27,284 --> 01:27:30,930
>> АЎДЫТОРЫЯ: Дык вы кажаце, што
павелічэнне кропак крыніцы паскарае

1986
01:27:30,930 --> 01:27:31,430
працэс?

1987
01:27:31,430 --> 01:27:32,513
РВК Хулихэном: Павышэнне?

1988
01:27:32,513 --> 01:27:33,520
АЎДЫТОРЫЯ: Крыніца пунктаў.

1989
01:27:33,520 --> 01:27:34,410
РВК Хулихэном: Source кропкі?

1990
01:27:34,410 --> 01:27:37,500
АЎДЫТОРЫЯ: З інфармацыі,
дзе інфармацыя прыходзіць ад?

1991
01:27:37,500 --> 01:27:38,250
РВК Хулихэном: Няма

1992
01:27:38,250 --> 01:27:41,820
Тое, што я кажу, з'яўляецца павышэнне
Колькасць раздзелаў у сховішча дадзеных

1993
01:27:41,820 --> 01:27:44,060
паляпшае прапускную здольнасць.

1994
01:27:44,060 --> 01:27:48,300
Так што тут адбываецца, карыстальнікі
ўступлення ў экзэмпляры EC2 тут,

1995
01:27:48,300 --> 01:27:50,780
Ну, калі мне трэба карыстачу
Гэта М, я пайду сюды.

1996
01:27:50,780 --> 01:27:53,560
Ад N р, я пайду сюды.

1997
01:27:53,560 --> 01:27:55,060
З Р да Я, я пайду сюды.

1998
01:27:55,060 --> 01:27:57,120
>> АЎДЫТОРЫЯ: ОК, так тыя, тыя
захоўваюцца ў розных вузлах?

1999
01:27:57,120 --> 01:27:57,911
>> РВК Хулихэном: Так.

2000
01:27:57,911 --> 01:28:00,210
Падумайце пра іх, як
розныя бункеры дадзеных.

2001
01:28:00,210 --> 01:28:01,660
Такім чынам, вы таго, каб зрабіць гэта.

2002
01:28:01,660 --> 01:28:02,910
Калі вы спрабуеце зрабіць
гэта, калі вы спрабуеце

2003
01:28:02,910 --> 01:28:05,730
у маштабе на рэляцыйнай платформе,
гэта тое, што вы робіце.

2004
01:28:05,730 --> 01:28:08,100
Вы прымаеце дадзеныя і
вы рэзкі яго.

2005
01:28:08,100 --> 01:28:10,975
І вы падзелу яго па
некалькі асобнікаў базы дадзеных.

2006
01:28:10,975 --> 01:28:13,580
І вы ўсё, што кіраванне
на ўзроўні прыкладанняў.

2007
01:28:13,580 --> 01:28:14,729
Гэта не весела.

2008
01:28:14,729 --> 01:28:15,770
Так што мы хочам ісці?

2009
01:28:15,770 --> 01:28:20,240
Мы хочам, каб перайсці DynamoDB, цалкам кіраваны,
NoSQL сховішчы дадзеных, прадастаўленне прапускную здольнасць.

2010
01:28:20,240 --> 01:28:22,680
Мы выкарыстоўваем другасныя індэксы.

2011
01:28:22,680 --> 01:28:26,154
Гэта ў асноўным HTTP API і
ўключае ў сябе падтрымку дакумента.

2012
01:28:26,154 --> 01:28:28,570
Такім чынам, вы не павінны турбавацца
аб любым з гэтага падзелу.

2013
01:28:28,570 --> 01:28:30,740
Мы робім усё гэта для вас.

2014
01:28:30,740 --> 01:28:33,260
Так што цяпер, замест гэтага, вы
проста напішыце ў табліцы.

2015
01:28:33,260 --> 01:28:36,490
Калі табліца павінна быць падзелена,
што адбываецца за кулісамі.

2016
01:28:36,490 --> 01:28:40,642
Вы цалкам ізаляваны
ад як распрацоўшчык.

2017
01:28:40,642 --> 01:28:42,350
Такім чынам, давайце пагаворым аб
некаторыя з выпадкаў выкарыстання

2018
01:28:42,350 --> 01:28:47,564
што мы бяжым у ў гульнях, агульная
гульнявыя сцэнары, лідэраў.

2019
01:28:47,564 --> 01:28:49,980
Такім чынам, вы атрымалі карыстальнікі ў бліжэйшыя,
у BoardNames, што яны

2020
01:28:49,980 --> 01:28:52,930
на, балы для гэтага карыстальніка.

2021
01:28:52,930 --> 01:28:57,700
Мы маглі б быць хэшавання на UserID,
а то ў нас асартымент на гульню.

2022
01:28:57,700 --> 01:28:59,960
Такім чынам, кожны карыстальнік хоча бачыць
Усе гульні ён гуляў

2023
01:28:59,960 --> 01:29:01,770
і ўсе яго найвышэйшы бал
па ўсёй гульні.

2024
01:29:01,770 --> 01:29:04,000
Так што яго асабістая лідэраў.

2025
01:29:04,000 --> 01:29:10,010
>> Цяпер я хачу, каб пайсці і я хачу, каб get--
так што я атрымліваю гэтыя асабістыя лідэраў.

2026
01:29:10,010 --> 01:29:12,827
Тое, што я хачу зрабіць, гэта пайсці атрымаць
верхняя адзнака для ўсіх карыстальнікаў.

2027
01:29:12,827 --> 01:29:13,660
Так як я раблю гэта?

2028
01:29:13,660 --> 01:29:18,070
Калі мой рэкорд хэшируется на
Гэты ідэнтыфікатар, вар'іраваліся ад гульні,

2029
01:29:18,070 --> 01:29:20,740
а я збіраюся ісці наперад
і рэструктурызацыі, стварыць GSI,

2030
01:29:20,740 --> 01:29:22,370
і я збіраюся правесці рэструктурызацыю гэтых дадзеных.

2031
01:29:22,370 --> 01:29:27,310
>> Цяпер я збіраюся, каб праясніць на
BoardName, што гульня.

2032
01:29:27,310 --> 01:29:29,800
І я збіраюся ў дыяпазоне ад найвышэйшы бал.

2033
01:29:29,800 --> 01:29:31,540
А цяпер я стварыў розныя вядра.

2034
01:29:31,540 --> 01:29:34,790
Я выкарыстоўваю тую ж табліцу,
тыя ж самыя дадзеныя. пункт

2035
01:29:34,790 --> 01:29:39,870
Але я ствараю вядро, што дае
мне агрэгацыя найвышэйшы бал па гульні.

2036
01:29:39,870 --> 01:29:43,180
>> І я магу запытаць гэтую табліцу
каб атрымаць гэтую інфармацыю.

2037
01:29:43,180 --> 01:29:50,890
Так я ўсталяваў, што ўзор запыту да
падтрымлівацца другаснага азначніка.

2038
01:29:50,890 --> 01:29:54,556
Цяпер яны могуць быць адсартаваныя па BoardName
і сартуюцца па TopScore, у залежнасці ад.

2039
01:29:54,556 --> 01:29:57,180
Такім чынам, вы можаце бачыць, гэта тыпу
прэцэдэнтаў вы атрымаеце ў гульнях.

2040
01:29:57,180 --> 01:30:02,190
Яшчэ адзін добры варыянт выкарыстання мы атрымліваем у гульнях
гэта ўзнагароды і хто выйграў ўзнагароды.

2041
01:30:02,190 --> 01:30:05,340
І гэта вялікі кейс
дзе мы называем разрэджаных індэксаў.

2042
01:30:05,340 --> 01:30:07,340
Рэдкія індэксы з'яўляюцца
Здольнасць генераваць

2043
01:30:07,340 --> 01:30:10,850
індэкс, які не абавязкова
ўтрымлівае кожны пункт на стале.

2044
01:30:10,850 --> 01:30:11,470
А чаму не?

2045
01:30:11,470 --> 01:30:14,540
Паколькі атрыбут, які быўшы
індэксавацца не існуе па кожным пункце.

2046
01:30:14,540 --> 01:30:16,460
>> Такім чынам, у гэты канкрэтны
выкарыстоўваць выпадак, я кажу,

2047
01:30:16,460 --> 01:30:19,240
Вы ведаеце, што я збіраюся
стварыць атрыбут прэміі.

2048
01:30:19,240 --> 01:30:22,970
І я збіраюся даць кожнаму карыстальніку
што мае ўзнагароды, якія прыпісваюць.

2049
01:30:22,970 --> 01:30:25,950
Людзі, якія не маюць ўзнагароды
не будзе мець гэты атрыбут.

2050
01:30:25,950 --> 01:30:27,800
Таму, калі я стварыць
Індэкс, толькі карыстальнікі

2051
01:30:27,800 --> 01:30:28,960
якія збіраюцца, каб паказаць
ў індэксе

2052
01:30:28,960 --> 01:30:31,050
тыя, якія на самай справе выйгралі ўзнагароды.

2053
01:30:31,050 --> 01:30:34,440
Так што гэта выдатны спосаб, каб мець магчымасць
стварыць адфільтраваць індэксы,

2054
01:30:34,440 --> 01:30:40,580
вельмі, вельмі выбарча, што не
павінны індэксаваць ўсю табліцу.

2055
01:30:40,580 --> 01:30:43,050
>> Так мы атрымліваем мала часу тут.

2056
01:30:43,050 --> 01:30:49,190
Я збіраюся ісці наперад і прапусціць
, І прапусціць гэты сцэнар.

2057
01:30:49,190 --> 01:30:52,625
Пагаворыце трохі about--

2058
01:30:52,625 --> 01:30:54,460
>> АЎДЫТОРЫЯ: Ці магу я задаць хуткі пытанне?

2059
01:30:54,460 --> 01:30:56,722
Адным з іх з'яўляецца цяжкім напісаць?

2060
01:30:56,722 --> 01:30:57,680
РВК Хулихэном: Што такое?

2061
01:30:57,680 --> 01:30:58,596
АЎДЫТОРЫЯ: Напісаць цяжкім.

2062
01:30:58,596 --> 01:31:01,270
РВК Хулихэном: Напісаць цяжкім.

2063
01:31:01,270 --> 01:31:03,460
Дазвольце мне бачыць.

2064
01:31:03,460 --> 01:31:06,220
>> АЎДЫТОРЫЯ: Ці гэта не
тое, што вы можаце проста

2065
01:31:06,220 --> 01:31:08,809
Голас у лічаныя секунды?

2066
01:31:08,809 --> 01:31:10,850
РВК Хулихэном: Мы ідзем
праз сцэнары галасавання.

2067
01:31:10,850 --> 01:31:11,670
Гэта не так ужо дрэнна.

2068
01:31:11,670 --> 01:31:14,580
Ці ёсць у вас, хлопцы, ёсць некалькі хвілін?

2069
01:31:14,580 --> 01:31:15,860
ДОБРА.

2070
01:31:15,860 --> 01:31:17,890
>> Такім чынам, мы будзем казаць аб галасаванні.

2071
01:31:17,890 --> 01:31:20,250
Так у рэжыме рэальнага часу галасавання, у нас ёсць
Патрабаванні для галасавання.

2072
01:31:20,250 --> 01:31:25,250
Патрабаванні, якія мы дазволіць
кожны чалавек, каб галасаваць толькі адзін раз.

2073
01:31:25,250 --> 01:31:28,060
Мы хочам, каб ніхто не зможа
змяніць свой голас.

2074
01:31:28,060 --> 01:31:31,045
Мы хочам, агрэгацыю ў рэжыме рэальнага часу
і аналітыка для дэмаграфіі

2075
01:31:31,045 --> 01:31:34,210
што мы збіраемся, каб быць
паказваючы карыстальнікаў на сайце.

2076
01:31:34,210 --> 01:31:35,200
>> Падумайце пра гэта сцэнары.

2077
01:31:35,200 --> 01:31:37,550
Мы шмат працуем рэальнасці
Тэлевізар паказвае, дзе яны

2078
01:31:37,550 --> 01:31:38,960
робіць гэтыя дакладны тып рэчаў.

2079
01:31:38,960 --> 01:31:41,584
Такім чынам, вы можаце думаць пра сцэнар,
у нас ёсць мільёны і мільёны

2080
01:31:41,584 --> 01:31:43,959
дзяўчыны падлеткавага там
з іх сотавых тэлефонаў

2081
01:31:43,959 --> 01:31:46,250
і галасаванне, і галасаванне, і
галасаванне для тых, хто іх

2082
01:31:46,250 --> 01:31:48,610
знайсці, каб быць самым папулярным.

2083
01:31:48,610 --> 01:31:50,830
Дык вось некаторыя з
Патрабаванні ў нас скончыліся.

2084
01:31:50,830 --> 01:31:52,990
>> І таму першы ўзяць
ў вырашэнні гэтай праблемы

2085
01:31:52,990 --> 01:31:55,090
будзе будаваць
вельмі простае прыкладанне.

2086
01:31:55,090 --> 01:31:56,490
Так што я атрымаў гэта дадатак.

2087
01:31:56,490 --> 01:31:57,950
У мяне ёсць некалькі выбаршчыкаў там.

2088
01:31:57,950 --> 01:31:59,980
Яны прыходзяць у, яны патрапілі ў дадатак галасавання.

2089
01:31:59,980 --> 01:32:03,440
У мяне ёсць сырое галасоў табліцу
Я проста звалка гэтыя галасы ст.

2090
01:32:03,440 --> 01:32:05,780
Я ёсць сукупнасць
галасоў табліца,

2091
01:32:05,780 --> 01:32:09,490
зробіць мае аналітыкі і дэмаграфіі,
і мы паставім усё гэта там.

2092
01:32:09,490 --> 01:32:11,420
>> І гэта выдатна.

2093
01:32:11,420 --> 01:32:12,332
Жыццё добрая.

2094
01:32:12,332 --> 01:32:15,040
Жыццё добрая, пакуль мы не даведаемся, што
заўсёды ёсць толькі адзін ці два

2095
01:32:15,040 --> 01:32:16,879
людзі, якія карыстаюцца папулярнасцю на выбарах.

2096
01:32:16,879 --> 01:32:19,420
Там толькі адзін ці дзве рэчы,
што людзі сапраўды клапоцяцца аб.

2097
01:32:19,420 --> 01:32:22,340
І калі вы галасуеце на
маштаб, раптам я

2098
01:32:22,340 --> 01:32:26,360
будзе малатком пекла з
два кандыдаты, адзін ці два кандыдаты.

2099
01:32:26,360 --> 01:32:29,390
Вельмі абмежаваную колькасць пунктаў
людзі лічаць, каб быць папулярным.

2100
01:32:29,390 --> 01:32:31,710
>> Гэта не добры дызайн мадэлі.

2101
01:32:31,710 --> 01:32:33,549
Гэта на самай справе
вельмі дрэнна шаблон

2102
01:32:33,549 --> 01:32:36,340
таму што гэта стварае тое, што мы
казалі аб якой было гарачыя клавішы.

2103
01:32:36,340 --> 01:32:38,960
Гарачыя клавішы з'яўляюцца чымсьці нам не падабаецца.

2104
01:32:38,960 --> 01:32:40,470
>> Такім чынам, як мы гэта выправіць?

2105
01:32:40,470 --> 01:32:47,640
І на самай справе, то, як выправіць гэта
прымаючы тыя кандыдатаў вядра

2106
01:32:47,640 --> 01:32:51,490
і для кожнага кандыдата мы маем,
мы збіраемся дадаць выпадковае значэнне,

2107
01:32:51,490 --> 01:32:54,192
тое, што мы ведаем, выпадковая
Значэнне паміж адным і 100,

2108
01:32:54,192 --> 01:32:56,620
паміж 100 і 1000,
або ад аднаго да 1000,

2109
01:32:56,620 --> 01:32:59,940
Аднак многія выпадковыя велічыні вы хочаце
дадаць у канец гэтага кандыдата.

2110
01:32:59,940 --> 01:33:01,330
>> І што я сапраўды зрабіў тое?

2111
01:33:01,330 --> 01:33:05,830
Калі я выкарыстоўваю ідэнтыфікатар кандыдата як
вядро для сукупных галасоў,

2112
01:33:05,830 --> 01:33:08,780
калі я дадаў выпадковы
Колькасць да канца, што,

2113
01:33:08,780 --> 01:33:12,000
Я стварыў ўжо 10 вёдраў, А
сто вёдраў, тысячы вядра

2114
01:33:12,000 --> 01:33:14,160
што я агрэгавання галасоў папярок.

2115
01:33:14,160 --> 01:33:18,030
>> Так што ў мяне мільёны і мільёны,
і мільёны запісаў у бліжэйшыя

2116
01:33:18,030 --> 01:33:22,050
для гэтых кандыдатаў, я зараз распаўсюджваецца
гэтыя галасы праз кандыдат A_1

2117
01:33:22,050 --> 01:33:24,630
праз кандыдат A_100, таму што
кожны раз, калі галасаванне ідзе ў,

2118
01:33:24,630 --> 01:33:26,530
Я генерацыі выпадковых
Значэнне паміж адным і 100.

2119
01:33:26,530 --> 01:33:29,446
Я лавіруючы яго на канцы
Кандыдат, які чалавек, хто галасуе за.

2120
01:33:29,446 --> 01:33:31,120
Я скід яго ў гэтым вядры.

2121
01:33:31,120 --> 01:33:33,910
>> Цяпер на адваротным, я ведаю,
што я атрымаў сто вёдраў.

2122
01:33:33,910 --> 01:33:36,350
Так што, калі я хачу, каб ісці наперад
і агрэгаваць галасоў,

2123
01:33:36,350 --> 01:33:38,244
Я чытаў ад усіх гэтых вёдрах.

2124
01:33:38,244 --> 01:33:39,160
Так што я ісці наперад і дадаць.

2125
01:33:39,160 --> 01:33:42,410
І тады я роскід сабраць
дзе я выходжу і кажу эй,

2126
01:33:42,410 --> 01:33:45,399
Вы ведаеце, што, ключ гэтага кандыдата
прастор больш за сто вядра.

2127
01:33:45,399 --> 01:33:47,940
Я збіраюся сабраць усе
галасоў ад тых ста вядра.

2128
01:33:47,940 --> 01:33:49,981
Я збіраюся аб'яднаць
ім, і я збіраюся сказаць,

2129
01:33:49,981 --> 01:33:53,830
Кандыдата ў цяперашні час
Агульная Падлік галасоў ад х.

2130
01:33:53,830 --> 01:33:55,690
>> Цяпер абодва запісу
запыт і запыт чытання

2131
01:33:55,690 --> 01:33:58,160
прыгожа размеркаваны
таму што я пішу па

2132
01:33:58,160 --> 01:34:00,320
і я чытаю на сотні ключоў.

2133
01:34:00,320 --> 01:34:03,500
Я не пішу і
чытаць па адным ключу ў цяперашні час.

2134
01:34:03,500 --> 01:34:04,950
Так што гэта вялікі малюнак.

2135
01:34:04,950 --> 01:34:08,090
>> Гэта на самай справе, верагодна, адзін
з найбольш важных дызайн

2136
01:34:08,090 --> 01:34:10,420
шаблоны для маштабу ў NoSQL.

2137
01:34:10,420 --> 01:34:14,470
Вы ўбачыце гэты тып
шаблон ў любы густ.

2138
01:34:14,470 --> 01:34:19,100
MongoDB, DynamoDB, гэта не
Справа, усе мы павінны зрабіць гэта.

2139
01:34:19,100 --> 01:34:21,840
Таму што, калі вы маеце справу
з тых велізарных навал,

2140
01:34:21,840 --> 01:34:26,650
Вы павінны высветліць, шлях да
распаўсюджваць іх па ўсёй вядра.

2141
01:34:26,650 --> 01:34:29,512
Так што гэта, як вы робіце гэта.

2142
01:34:29,512 --> 01:34:31,220
Добра, так, што
Вы робіце прама цяпер

2143
01:34:31,220 --> 01:34:35,252
гэта вы будзеце гандляваць з чытання
Кошт для запісу маштабаванасці.

2144
01:34:35,252 --> 01:34:37,085
Кошт маёй чытання
крыху больш складана

2145
01:34:37,085 --> 01:34:40,220
і я павінен ісці чытаць з
сто вёдраў замест аднаго.

2146
01:34:40,220 --> 01:34:41,310
Але я магу напісаць.

2147
01:34:41,310 --> 01:34:44,860
І мая прапускная здольнасць, мая запісу
прапускная здольнасць неверагодна.

2148
01:34:44,860 --> 01:34:49,450
Так што, як правіла, з'яўляецца каштоўным
Тэхніка для маштабавання DynamoDB,

2149
01:34:49,450 --> 01:34:51,350
або любая база дадзеных NoSQL па гэтым пытанні.

2150
01:34:51,350 --> 01:34:53,824

2151
01:34:53,824 --> 01:34:55,240
Такім чынам, мы высветлілі, як маштабаваць яго.

2152
01:34:55,240 --> 01:34:56,930
І мы зразумелі, як
ліквідаваць нашы гарачыя клавішы.

2153
01:34:56,930 --> 01:34:57,820
І гэта фантастыка.

2154
01:34:57,820 --> 01:34:58,960
І мы атрымалі гэтую добрую сістэму.

2155
01:34:58,960 --> 01:35:02,043
І гэта дае нам вельмі правільную галасаванне
таму што ў нас запіс галасоў дэ-дурня.

2156
01:35:02,043 --> 01:35:03,130
Ён пабудаваны ў DynamoDB.

2157
01:35:03,130 --> 01:35:05,380
Мы гаварылі аб умоўных правоў.

2158
01:35:05,380 --> 01:35:08,170
>> Калі выбаршчык прыходзіць, ставіць
устаўка на стале,

2159
01:35:08,170 --> 01:35:11,220
яны ўстаўляюць іх выбаршчыкаў ID,
калі яны спрабуюць ўставіць іншы голас,

2160
01:35:11,220 --> 01:35:13,320
Я раблю ўмоўнае запісу.

2161
01:35:13,320 --> 01:35:16,960
Скажыце толькі напісаць гэта
калі гэта не існуе.

2162
01:35:16,960 --> 01:35:19,270
Таму, як толькі я бачу, што
што галасаванне ў хіт табліцу,

2163
01:35:19,270 --> 01:35:20,460
ніхто не будзе
ў стане паставіць свой голас у.

2164
01:35:20,460 --> 01:35:21,634
І гэта фантастыка.

2165
01:35:21,634 --> 01:35:23,550
І мы павялічваючы
Наш кандыдат лічыльнікі.

2166
01:35:23,550 --> 01:35:25,466
І мы робім усё
дэмаграфічныя і ўсё такое.

2167
01:35:25,466 --> 01:35:29,110
Але што адбудзецца, калі мой
Дадатак падае?

2168
01:35:29,110 --> 01:35:31,350
Зараз усе раптам галасоў
ідуць, і я

2169
01:35:31,350 --> 01:35:34,840
не ведаю, калі яны атрымліваюць апрацоўваюцца
ў маіх аналітыкі і дэмаграфіі

2170
01:35:34,840 --> 01:35:36,040
больш.

2171
01:35:36,040 --> 01:35:38,462
І калі прыкладанне
вяртаецца ўверх, як

2172
01:35:38,462 --> 01:35:41,420
, Чорт вазьмі, я ведаю, што ёсць галасы
былі апрацаваны і дзе я магу пачаць?

2173
01:35:41,420 --> 01:35:44,530
>> Так што гэта рэальная праблема, калі вы
пачынаюць глядзець на гэтага тыпу сцэнара.

2174
01:35:44,530 --> 01:35:45,571
І як мы вырашым, што?

2175
01:35:45,571 --> 01:35:48,070
Мы вырашаем яе з тым, што мы
патэлефанаваць DynamoDB патокаў.

2176
01:35:48,070 --> 01:35:53,470
Патокі заказваецца час і
размяркоўваюць часопіс змяненняў кожнага доступу

2177
01:35:53,470 --> 01:35:55,700
да стала, кожны напісаць
Доступ да табліцы.

2178
01:35:55,700 --> 01:35:58,810
Любыя дадзеныя, якія напісаў у
Табліца паказвае ўверх у струмені.

2179
01:35:58,810 --> 01:36:01,815
>> Гэта ў асноўным чарзе 24 гадзіны.

2180
01:36:01,815 --> 01:36:03,690
Прадметы ударыў паток,
яны жывуць на працягу 24 гадзін.

2181
01:36:03,690 --> 01:36:05,990
Яны могуць быць прачытаныя некалькі разоў.

2182
01:36:05,990 --> 01:36:09,400
Гарантавана будуць дастаўлены
толькі адзін раз у паток,

2183
01:36:09,400 --> 01:36:11,180
можа быць прачытаны п колькасць разоў.

2184
01:36:11,180 --> 01:36:14,910
Так многія працэсы, аднак вы хочаце
спажываць гэтыя дадзеныя, вы можаце спажываць.

2185
01:36:14,910 --> 01:36:16,350
Ён з'явіцца кожнае абнаўленне.

2186
01:36:16,350 --> 01:36:18,455
Кожны запісу будзе толькі
з'яўляюцца раз у струмені.

2187
01:36:18,455 --> 01:36:20,621
Такім чынам, вы не павінны турбавацца
аб апрацоўцы яго двойчы

2188
01:36:20,621 --> 01:36:22,500
з таго ж працэсу.

2189
01:36:22,500 --> 01:36:25,350
>> Гэта строга загадаў кожным пункце.

2190
01:36:25,350 --> 01:36:28,180
Калі мы кажам, час
замовіць і размяркоўваюць,

2191
01:36:28,180 --> 01:36:30,680
Вы ўбачыце ў раздзеле на паток.

2192
01:36:30,680 --> 01:36:33,169
Вы ўбачыце прадметы, абнаўлення ў парадку.

2193
01:36:33,169 --> 01:36:35,210
Мы не гарантуючы
на патоку, што ты

2194
01:36:35,210 --> 01:36:40,240
збіраецца атрымаць кожную здзелку
у парадку праз прадметы.

2195
01:36:40,240 --> 01:36:42,440
>> Так патокі идемпотентная.

2196
01:36:42,440 --> 01:36:44,037
Хіба мы ўсе ведаем, што идемпотент азначае?

2197
01:36:44,037 --> 01:36:46,620
Идемпотентный азначае, што вы можаце зрабіць гэта
зноў, і зноў, і зноў.

2198
01:36:46,620 --> 01:36:48,200
Вынік будзе той жа.

2199
01:36:48,200 --> 01:36:49,991
>> Патокі идемпотентны,
але яны павінны быць

2200
01:36:49,991 --> 01:36:54,860
гуляў з адпраўной кропкі,
дзе б вы ні абралі, да канца,

2201
01:36:54,860 --> 01:36:57,950
або яны не будуць прыводзіць
ў тых жа значэнняў.

2202
01:36:57,950 --> 01:36:59,727
>> Тое ж самае з MongoDB.

2203
01:36:59,727 --> 01:37:01,560
MongoDB мае канструкцыю
яны называюць oplog.

2204
01:37:01,560 --> 01:37:04,140
Гэта сапраўды такі ж канструкцыяй.

2205
01:37:04,140 --> 01:37:06,500
Многія базы дадзеных NoSQL
ёсць гэтую канструкцыю.

2206
01:37:06,500 --> 01:37:08,790
Яны выкарыстоўваюць яго, каб рабіць рэчы,
як рэплікацыя, якая

2207
01:37:08,790 --> 01:37:10,475
менавіта тое, што мы робім з патокамі.

2208
01:37:10,475 --> 01:37:12,350
АЎДЫТОРЫЯ: Можа быць,
ерэтычныя пытанне, але вы

2209
01:37:12,350 --> 01:37:13,975
казаць пра прыкладання робіш гэтак далей.

2210
01:37:13,975 --> 01:37:16,089
Ручаі гарантавана
ня магчыма ісці ўніз?

2211
01:37:16,089 --> 01:37:18,630
РВК Хулихэном: Так, патокі
гарантавана ніколі не ўвойдзе.

2212
01:37:18,630 --> 01:37:21,040
Мы кіраваць інфраструктурай
ззаду. патокі аўтаматычна

2213
01:37:21,040 --> 01:37:22,498
разгарнуць у іх аўто маштабавання групы.

2214
01:37:22,498 --> 01:37:25,910
Мы пойдзем праз маленькі
крыху аб тым, што адбываецца.

2215
01:37:25,910 --> 01:37:30,060
>> Я не павінен сказаць, што яны не
гарантавана ніколі не ідуць ўніз.

2216
01:37:30,060 --> 01:37:33,110
Элементы гарантуецца
з'яўляюцца ў патоку.

2217
01:37:33,110 --> 01:37:36,740
І паток будзе даступны.

2218
01:37:36,740 --> 01:37:40,580
Так што ідзе ўніз або вяртаецца
уверх, што адбываецца ўнізе.

2219
01:37:40,580 --> 01:37:43,844
Гэта covers-- гэта нармальна.

2220
01:37:43,844 --> 01:37:46,260
Добра, так што вы атрымаеце розныя
Тыпы від на экране.

2221
01:37:46,260 --> 01:37:51,040
Тыпы меркаванне, што важныя да
праграміст, як правіла, з'яўляюцца, што гэта было?

2222
01:37:51,040 --> 01:37:52,370
Я стары выгляд.

2223
01:37:52,370 --> 01:37:55,630
Калі абнаўленне парад табліцу, яна будзе
націснуць ранейшымі да патоку

2224
01:37:55,630 --> 01:38:02,070
так што дадзеныя можна заархіваванага, або змяненне
кантроль, ідэнтыфікацыя змены, змены

2225
01:38:02,070 --> 01:38:03,600
Кіраванне.

2226
01:38:03,600 --> 01:38:07,160
>> Новы вобраз, то, што гэта зараз, пасля
абнаўленне, гэта іншы тып гледжання

2227
01:38:07,160 --> 01:38:07,660
вы можаце атрымаць.

2228
01:38:07,660 --> 01:38:09,660
Вы можаце атрымаць абодва старыя і новыя вобразы.

2229
01:38:09,660 --> 01:38:10,660
Можа быць, я хачу іх абодвух.

2230
01:38:10,660 --> 01:38:11,790
Я хачу, каб паглядзець, што гэта было.

2231
01:38:11,790 --> 01:38:13,290
Я хачу, каб паглядзець, што ён змяніўся.

2232
01:38:13,290 --> 01:38:15,340
>> У мяне ёсць тып адпаведнасці
працэсу, які працуе.

2233
01:38:15,340 --> 01:38:17,430
Ён павінен пераканацца, што
калі гэтыя рэчы мяняюцца,

2234
01:38:17,430 --> 01:38:21,840
што яны ў пэўных межах
або на працягу пэўных параметраў.

2235
01:38:21,840 --> 01:38:23,840
>> І тады, магчыма, я толькі
трэба ведаць, што змянілася.

2236
01:38:23,840 --> 01:38:26,240
Мяне не хвалюе, які элемент змяніўся.

2237
01:38:26,240 --> 01:38:28,580
Мне не трэба, каб ведаць
якія атрыбуты змянілася.

2238
01:38:28,580 --> 01:38:30,882
Мне проста трэба ведаць, што
дэталі дотыку.

2239
01:38:30,882 --> 01:38:33,340
Такім чынам, гэтыя тыпы выглядам
што вы атрымліваеце ад патоку

2240
01:38:33,340 --> 01:38:35,960
і вы можаце ўзаемадзейнічаць з.

2241
01:38:35,960 --> 01:38:37,840
>> Дадатак,
спажывае паток,

2242
01:38:37,840 --> 01:38:39,298
гэта свайго роду, як гэтая працуе.

2243
01:38:39,298 --> 01:38:42,570
Кліент DynamoDB папрасіць
перадаваць дадзеныя ў табліцы.

2244
01:38:42,570 --> 01:38:44,750
Патокі разгарнуць на тое, што мы называем аскепкі.

2245
01:38:44,750 --> 01:38:47,380
Аскепкі маштабуюцца
незалежна ад табліцы.

2246
01:38:47,380 --> 01:38:50,660
Яны не выстройваюцца цалкам
да раздзелаў вашага стала.

2247
01:38:50,660 --> 01:38:52,540
І прычына, чаму гэта
таму што яны выстройваюцца

2248
01:38:52,540 --> 01:38:55,430
з магутнасцю, ток
Ёмістасць табліцы.

2249
01:38:55,430 --> 01:38:57,600
>> Яны выкарыстоўваюць у сваіх
ўласнага аўто маштабаванне групы,

2250
01:38:57,600 --> 01:39:00,800
і яны пачынаюць круціцца з залежнасці
на колькі запісу ідуць у,

2251
01:39:00,800 --> 01:39:03,090
колькі reads-- на самай справе гэта піша.

2252
01:39:03,090 --> 01:39:05,820
Там няма reads-- але як
многія запісы ідуць у.

2253
01:39:05,820 --> 01:39:08,200
>> А потым на спіне
канец, мы маем тое, што

2254
01:39:08,200 --> 01:39:11,390
выклікаць KCL, або бібліятэка Kinesis кліента.

2255
01:39:11,390 --> 01:39:19,190
Кинезис з'яўляецца струмень дадзеных
Тэхналогія апрацоўкі ад Amazon.

2256
01:39:19,190 --> 01:39:22,040
І патокі пабудаваны на гэтым.

2257
01:39:22,040 --> 01:39:25,670
>> Такім чынам, вы выкарыстоўваць уключаны тое, KCL
Прыкладанне для чытання струмень.

2258
01:39:25,670 --> 01:39:28,752
Бібліятэка Кинезис Кліент фактычна
кіруе працаўнікоў для вас.

2259
01:39:28,752 --> 01:39:30,460
І гэта таксама робіць некаторыя
цікавыя рэчы.

2260
01:39:30,460 --> 01:39:35,630
Гэта створыць некалькі табліц да
у таблічным DynamoDB

2261
01:39:35,630 --> 01:39:38,410
адсочваць, якія элементы
былі апрацаваны.

2262
01:39:38,410 --> 01:39:41,190
Так што гэта шлях, калі ён падае таму, калі
гэта падае і прыходзіць і атрымлівае

2263
01:39:41,190 --> 01:39:45,570
стаяў назад, ён можа вызначыць, дзе
гэта было ў апрацоўцы патоку.

2264
01:39:45,570 --> 01:39:48,360
>> Гэта вельмі важна, калі
Вы кажаце пра рэплікацыі.

2265
01:39:48,360 --> 01:39:50,350
Мне трэба ведаць, што
быў дадзеныя былі апрацаваны

2266
01:39:50,350 --> 01:39:52,810
і якія дадзеныя яшчэ павінны быць апрацаваны.

2267
01:39:52,810 --> 01:39:57,380
Такім чынам, бібліятэка, KCL для патокаў будзе
даць вам шмат гэтай функцыянальнасці.

2268
01:39:57,380 --> 01:39:58,990
Ён клапоціцца пра ўсіх гаспадаркай.

2269
01:39:58,990 --> 01:40:01,140
Ён стаіць на работніка для кожнага асколка.

2270
01:40:01,140 --> 01:40:04,620
Гэта стварае адміністрацыйную табліцу
для кожнага асколка, для кожнага работніка.

2271
01:40:04,620 --> 01:40:07,560
І, як тыя работнікі агонь,
яны падтрымліваюць гэтыя табліцы

2272
01:40:07,560 --> 01:40:10,510
так што вы ведаеце гэтую запіс
быў чытаць і апрацоўваюцца.

2273
01:40:10,510 --> 01:40:13,850
А потым, што шлях, калі працэс
памірае і вяртаецца ў Інтэрнэце,

2274
01:40:13,850 --> 01:40:17,940
ён можа аднавіць права, дзе ён зняў.

2275
01:40:17,940 --> 01:40:20,850
>> Таму мы выкарыстоўваем гэта для
крос-рэгіён рэплікацыі.

2276
01:40:20,850 --> 01:40:24,680
Шмат кліентаў ёсць патрэба ў
перамяшчаць дадзеныя або часткі сваіх табліц дадзеных

2277
01:40:24,680 --> 01:40:25,920
вакол розных рэгіёнах.

2278
01:40:25,920 --> 01:40:29,230
Ёсць дзевяць рэгіёнаў
ва ўсім свеце.

2279
01:40:29,230 --> 01:40:32,100
Так што можа быць я need--
можа ёсць карыстальнікі ў Азіі, карыстальнікі

2280
01:40:32,100 --> 01:40:34,150
на ўсходнім узбярэжжы Злучаных Штатаў.

2281
01:40:34,150 --> 01:40:38,980
Яны маюць розныя дадзеныя, што
Неабходна лакальна размеркаванай.

2282
01:40:38,980 --> 01:40:42,510
І, можа быць, карыстальнік рэйсы з
Азія да ЗША,

2283
01:40:42,510 --> 01:40:45,020
і я хачу, каб паўтарыць
яго дадзеныя з ім.

2284
01:40:45,020 --> 01:40:49,340
Так што, калі ён атрымлівае ад самалёта, ён мае
добры вопыт, выкарыстоўваючы свой мабільны дадатак.

2285
01:40:49,340 --> 01:40:52,360
>> Можна выкарыстоўваць перакрыжаванае вобласць
Бібліятэка рэплікацыі для гэтага.

2286
01:40:52,360 --> 01:40:55,730
У асноўным у нас ёсць
пры ўмове, дзве тэхналогіі.

2287
01:40:55,730 --> 01:40:59,400
Адзін гэта кансольнае прыкладанне вы можаце
ўстаць на вашым асобніку EC2.

2288
01:40:59,400 --> 01:41:01,240
Яна працуе чыста рэплікацыі.

2289
01:41:01,240 --> 01:41:02,720
А потым мы далі вам бібліятэку.

2290
01:41:02,720 --> 01:41:06,070
Бібліятэка вы можаце выкарыстоўваць, каб пабудаваць
ўласнае прыкладанне, калі вам

2291
01:41:06,070 --> 01:41:10,740
хачу зрабіць вар'яты рэчы з гэтым data--
фільтр, паўтарыць толькі яго частка,

2292
01:41:10,740 --> 01:41:14,120
круціць дадзеныя, перамясціць яго ў
адрозніваецца стол, гэтак далей, і гэтак далей.

2293
01:41:14,120 --> 01:41:18,700

2294
01:41:18,700 --> 01:41:20,520
Так што накшталт як гэта выглядае.

2295
01:41:20,520 --> 01:41:23,690
>> DynamoDB Патокі могуць быць
апрацоўваюцца, што мы называем Lambda.

2296
01:41:23,690 --> 01:41:27,394
Мы ўжо згадвалі трохі пра падзею
кіраваныя архітэктуры прыкладанняў.

2297
01:41:27,394 --> 01:41:28,810
Лямбда з'яўляецца ключавым кампанентам гэтага.

2298
01:41:28,810 --> 01:41:32,840
Лямбда-код, які страляе па патрабаванні
у адказ на канкрэтнае падзея.

2299
01:41:32,840 --> 01:41:36,020
Адзін з гэтых падзей можа быць
з'яўляючыся на струмені запіс.

2300
01:41:36,020 --> 01:41:39,100
Калі запіс на патоку з'яўляецца,
мы будзем называць гэтую функцыю Java.

2301
01:41:39,100 --> 01:41:44,980
Ну, гэта JavaScript, і лямбда
падтрымлівае Node.js, Java, Python,

2302
01:41:44,980 --> 01:41:47,820
і хутка падтрымліваць
іншыя мовы, а таксама.

2303
01:41:47,820 --> 01:41:50,940
І дастаткова сказаць, што гэта чысты код.

2304
01:41:50,940 --> 01:41:53,610
напісаць у Java, вы вызначаеце клас.

2305
01:41:53,610 --> 01:41:55,690
Вы націскаеце на JAR ўверх у Lambda.

2306
01:41:55,690 --> 01:42:00,200
А потым вы задаяце, які клас
называць у адказ на падзею, якое.

2307
01:42:00,200 --> 01:42:04,770
І тады інфраструктура Лямбда
за які будзе працаваць гэты код.

2308
01:42:04,770 --> 01:42:06,730
>> Гэты код можа апрацоўваць
запісы прэч патоку.

2309
01:42:06,730 --> 01:42:08,230
Гэта можа рабіць усё, што жадае з ёй.

2310
01:42:08,230 --> 01:42:11,650
У гэтым канкрэтным прыкладзе, усе мы
сапраўды робіце ўваходу атрыбуты.

2311
01:42:11,650 --> 01:42:13,480
Але гэта толькі код.

2312
01:42:13,480 --> 01:42:15,260
Код можа зрабіць што-небудзь, ці не так?

2313
01:42:15,260 --> 01:42:16,600
>> Такім чынам, вы можаце круціць гэтыя дадзеныя.

2314
01:42:16,600 --> 01:42:18,160
Вы можаце ствараць вытворныя выгляд.

2315
01:42:18,160 --> 01:42:21,160
Калі гэта структура дакумента,
Вы можаце згладзіць структуру.

2316
01:42:21,160 --> 01:42:24,300
Вы можаце стварыць альтэрнатыўныя індэксы.

2317
01:42:24,300 --> 01:42:27,100
Ўсе віды рэчаў, вы можаце
рабіць з DynamoDB патокаў.

2318
01:42:27,100 --> 01:42:28,780
>> І на самай справе, гэта, як гэта выглядае.

2319
01:42:28,780 --> 01:42:29,940
Такім чынам, вы атрымліваеце гэтыя абнаўлення ў бліжэйшыя.

2320
01:42:29,940 --> 01:42:31,190
Яны сыходзіць радок.

2321
01:42:31,190 --> 01:42:32,720
Яны счытваюцца функцыяй Lambda.

2322
01:42:32,720 --> 01:42:37,480
Яны круцячы дадзеныя і
штурхаючы яго ў вытворных табліцах,

2323
01:42:37,480 --> 01:42:42,200
паведаміўшы знешніх сістэм змены,
і перадаючы дадзеныя ў ElastiCache.

2324
01:42:42,200 --> 01:42:45,900
>> Мы гаварылі пра тое, як паставіць кэш
перад базе дадзеных для гэтай продажаў

2325
01:42:45,900 --> 01:42:46,450
сцэнар.

2326
01:42:46,450 --> 01:42:50,049
Ну, што адбудзецца, калі я
абнавіць апісанне тавару?

2327
01:42:50,049 --> 01:42:52,340
Ну, калі я быў Лямбда
Функцыя працуе на гэтым стале,

2328
01:42:52,340 --> 01:42:55,490
калі я абнавіць апісанне тавару, ён будзе
падабраць запіс з патокам,

2329
01:42:55,490 --> 01:42:58,711
і гэта абнаўленне ElastiCache
Асобнік з новымі дадзенымі.

2330
01:42:58,711 --> 01:43:00,460
Так што гэта шмат
Што мы робім з Lambda.

2331
01:43:00,460 --> 01:43:02,619
Гэта клей код, раздымы.

2332
01:43:02,619 --> 01:43:04,410
І гэта на самай справе дае
здольнасць да запуску

2333
01:43:04,410 --> 01:43:07,930
і працаваць вельмі складаных прыкладанняў
без выдзеленага сервера

2334
01:43:07,930 --> 01:43:10,371
інфраструктура, якая на самай справе выдатна.

2335
01:43:10,371 --> 01:43:13,100
>> Такім чынам, давайце вернемся да нашага
у рэжыме рэальнага часу архітэктура галасавання.

2336
01:43:13,100 --> 01:43:17,984
Гэта новы і палепшаны з нашым
патокі і, KCL уключаны прыкладання.

2337
01:43:17,984 --> 01:43:20,150
Тое ж самае, як і раней, мы можам
справіцца з любой маштаб выбараў.

2338
01:43:20,150 --> 01:43:21,100
Нам падабаецца гэта.

2339
01:43:21,100 --> 01:43:24,770
Мы робім з роскіду збірае
па некалькіх вядра.

2340
01:43:24,770 --> 01:43:26,780
У нас ёсць аптымізм замак адбываецца.

2341
01:43:26,780 --> 01:43:30,192
Мы можам трымаць нашы выбаршчыкі
ад змены іх галасы.

2342
01:43:30,192 --> 01:43:31,400
Яны могуць галасаваць толькі адзін раз.

2343
01:43:31,400 --> 01:43:32,880
Гэта фантастыка.

2344
01:43:32,880 --> 01:43:35,895
У рэжыме рэальнага часу адмоваўстойлівасць,
маштабуецца агрэгацыя сучаснасць.

2345
01:43:35,895 --> 01:43:38,270
Калі рэч падае, гэта
ведае, дзе перазапусціць сябе

2346
01:43:38,270 --> 01:43:41,300
калі ён вяртаецца, таму што
мы выкарыстоўваем прыкладанне KCL.

2347
01:43:41,300 --> 01:43:45,700
І тады мы можам таксама выкарыстоўваць, што
Дадатак KCL перадаваць дадзеныя з

2348
01:43:45,700 --> 01:43:48,820
у чырвонае зрушэнне для іншых
дадатак аналітыка, або выкарыстанне

2349
01:43:48,820 --> 01:43:51,990
Эластычны MapReduce для запуску
у рэжыме рэальнага часу струменевае навалы прэч

2350
01:43:51,990 --> 01:43:53,180
гэтыя дадзеныя.

2351
01:43:53,180 --> 01:43:55,480
>> Такім чынам, гэтыя рэчы, якія мы
не казаў пра многае.

2352
01:43:55,480 --> 01:43:57,375
Але яны дадатковая
тэхналогіі, якія прыходзяць

2353
01:43:57,375 --> 01:44:00,310
несці, калі вы шукаеце
на гэтых тыпах сцэнарыяў.

2354
01:44:00,310 --> 01:44:03,160
>> Добра, так гэта пра
аналітыка з DynamoDB патокаў.

2355
01:44:03,160 --> 01:44:05,340
Вы можаце сабраць дэ-дурня
Дадзеныя, зрабіць усё віды

2356
01:44:05,340 --> 01:44:09,490
з добрых рэчаў, сукупныя дадзеныя ў
памяці, ствараць вытворныя гэтых табліц.

2357
01:44:09,490 --> 01:44:13,110
Гэта велізарны кейс
што шмат кліентаў

2358
01:44:13,110 --> 01:44:16,950
удзельнічаюць з, прымаючы укладзены
ўласцівасці гэтых дакументаў JSON

2359
01:44:16,950 --> 01:44:18,946
і стварэння дадатковых індэксаў.

2360
01:44:18,946 --> 01:44:21,680

2361
01:44:21,680 --> 01:44:23,150
>> Мы ў канцы.

2362
01:44:23,150 --> 01:44:26,689
Дзякуй за падшыпнік са мной.

2363
01:44:26,689 --> 01:44:28,480
Такім чынам, давайце пагаворым аб
Эталонная архітэктура.

2364
01:44:28,480 --> 01:44:33,440
DynamoDB сядзіць у сярэдзіне, так
вялікая частка інфраструктуры AWS.

2365
01:44:33,440 --> 01:44:37,090
Увогуле, вы можаце падключыць яго
да ўсяго, што вы хочаце.

2366
01:44:37,090 --> 01:44:45,600
Прыкладанні на платформе Дынама ўключаюць
Лямбда, ElastiCache, CloudSearch,

2367
01:44:45,600 --> 01:44:49,890
перадаць дадзеныя з пругкай ў
MapReduce, экспарт імпарт з DynamoDB

2368
01:44:49,890 --> 01:44:52,370
у S3, усіх відаў тэхналагічных працэсаў.

2369
01:44:52,370 --> 01:44:54,120
Але, напэўна, самы лепшы
што казаць,

2370
01:44:54,120 --> 01:44:56,119
і гэта тое, што на самой справе
Цікава, калі мы

2371
01:44:56,119 --> 01:44:58,350
казаць аб прыкладанняў, якія кіруюцца падзеямі.

2372
01:44:58,350 --> 01:45:00,300
>> Гэта з'яўляецца прыкладам
Унутраны праект

2373
01:45:00,300 --> 01:45:04,850
што ў нас ёсць, дзе мы на самай справе
выдавецтва, каб сабраць вынікі абследавання.

2374
01:45:04,850 --> 01:45:07,700
Такім чынам, у электроннай сувязі, што
мы пашлем па-за, там будзе

2375
01:45:07,700 --> 01:45:11,350
трохі спасылку кажучы націсніце
тут, каб адказаць на абследавання.

2376
01:45:11,350 --> 01:45:14,070
І калі чалавек націскае
што спасылка, што адбываецца

2377
01:45:14,070 --> 01:45:18,020
гэта яны цягнуць уніз бяспечны
HTML-формы апытання з S3.

2378
01:45:18,020 --> 01:45:18,980
Там няма сервера.

2379
01:45:18,980 --> 01:45:20,600
Гэта проста аб'ект S3.

2380
01:45:20,600 --> 01:45:22,770
>> Гэтая форма падыходзіць,
загружае ў браўзэры.

2381
01:45:22,770 --> 01:45:24,240
Ён атрымаў хрыбетніка.

2382
01:45:24,240 --> 01:45:30,160
Ён атрымаў комплекс JavaScript
што ён працуе.

2383
01:45:30,160 --> 01:45:33,557
Так што гэта вельмі багаты прыкладанне
працуе ў браўзэры кліента.

2384
01:45:33,557 --> 01:45:36,390
Яны не ведаюць, што яны не
ўзаемадзейнічаюць з заднім серверы.

2385
01:45:36,390 --> 01:45:38,220
На дадзены момант, гэта ўсё-браўзэр.

2386
01:45:38,220 --> 01:45:41,780
>> Яны публікуюць вынікі да таго, што
мы называем Amazon API Gateway.

2387
01:45:41,780 --> 01:45:46,270
Шлюз API гэта проста Web API
што вы можаце вызначыць і падключыць

2388
01:45:46,270 --> 01:45:47,760
усё, што вы хочаце.

2389
01:45:47,760 --> 01:45:50,990
У дадзеным канкрэтным выпадку, мы
падключылі да лямбда-функцыі.

2390
01:45:50,990 --> 01:45:54,797
>> Так мой пост аперацыя
адбываецца без сервера.

2391
01:45:54,797 --> 01:45:56,380
У асноўным гэта шлюза API сядзіць там.

2392
01:45:56,380 --> 01:45:58,770
Гэта не варта мне нічога, пакуль людзі
Пачатак публікацыі на яго, праўда?

2393
01:45:58,770 --> 01:46:00,269
Функцыя Лямбда проста сядзіць там.

2394
01:46:00,269 --> 01:46:03,760
І гэта не варта мне нічога, пакуль
людзі пачынаюць дубасіць яго.

2395
01:46:03,760 --> 01:46:07,270
Такім чынам, вы можаце бачыць, як аб'ём
павялічваецца, што, калі абвінавачванні прыйшлі.

2396
01:46:07,270 --> 01:46:09,390
Я не працуе сервер 7/24.

2397
01:46:09,390 --> 01:46:12,310
>> Так што я цягнуць форму
ўніз з вядра,

2398
01:46:12,310 --> 01:46:15,719
і я адпраўляю праз API
Шлюз у лямбда-функцыі.

2399
01:46:15,719 --> 01:46:17,510
І тады Лямбда
Функцыя кажа, вы ведаеце,

2400
01:46:17,510 --> 01:46:20,600
тое, што я атрымаў некаторыя PIIs, некаторыя
персанальная інфармацыя

2401
01:46:20,600 --> 01:46:21,480
у гэтых адказах.

2402
01:46:21,480 --> 01:46:23,020
Я атрымаў каментары, якія паступаюць ад карыстальнікаў.

2403
01:46:23,020 --> 01:46:24,230
Я атрымаў адрасы электроннай пошты.

2404
01:46:24,230 --> 01:46:26,190
Я атрымаў імёны.

2405
01:46:26,190 --> 01:46:27,810
>> Дазвольце мне падзяліць гэта ад.

2406
01:46:27,810 --> 01:46:30,280
Я збіраюся генераваць некаторыя
метададзеныя ад гэтага запісу.

2407
01:46:30,280 --> 01:46:32,850
І я збіраюся націснуць
метададзеныя ў DynamoDB.

2408
01:46:32,850 --> 01:46:36,059
І я мог бы зашыфраваць усе дадзеныя,
і ўстаўце яго ў DynamoDB, калі я хачу.

2409
01:46:36,059 --> 01:46:38,600
Але гэта лягчэй для мяне, у гэтым
выкарыстоўваць выпадак, каб ісці наперад і кажа:

2410
01:46:38,600 --> 01:46:42,800
Я збіраюся вылучыць зыходныя дадзеныя
ў зашыфраваным S3 вядра.

2411
01:46:42,800 --> 01:46:47,240
Так што я выкарыстоўваю убудаваны ў баку сервера S3
шыфравання і кіравання ключамі ад Amazon

2412
01:46:47,240 --> 01:46:51,600
Абслугоўванне так што ў мяне ёсць ключ, які
можа круціцца на чарговы інтэрвал,

2413
01:46:51,600 --> 01:46:55,010
і я магу абараніць, што PII дадзеныя
як частка ўсёй гэтай працоўнага працэсу.

2414
01:46:55,010 --> 01:46:55,870
>> Так што я зрабіў?

2415
01:46:55,870 --> 01:47:00,397
Я толькі што разгорнута цэлая
прыкладанняў і ў мяне няма сервера.

2416
01:47:00,397 --> 01:47:02,980
Так што падзейную прыкладання
архітэктура робіць для вас.

2417
01:47:02,980 --> 01:47:05,730
>> Цяпер, калі вы думаеце пра
прэцэдэнт для this--

2418
01:47:05,730 --> 01:47:08,730
у нас ёсць іншыя кліенты я казаць
каб пра гэта хто дакладнай архітэктуры

2419
01:47:08,730 --> 01:47:14,560
запусціць фенаменальна вялікія кампаніі, якія
глядзім на гэта і адбываецца, пра мой.

2420
01:47:14,560 --> 01:47:17,840
Таму што цяпер, яны могуць
у асноўным штурхаць яго там,

2421
01:47:17,840 --> 01:47:21,900
хай гэтую кампанію проста сядзець
там, пакуль не запускае, а не

2422
01:47:21,900 --> 01:47:24,400
прыйдзецца турбавацца аб дулю
Якая інфраструктура

2423
01:47:24,400 --> 01:47:26,120
будзе там, каб падтрымаць яго.

2424
01:47:26,120 --> 01:47:28,600
А потым, як толькі
што кампанія будзе зроблена,

2425
01:47:28,600 --> 01:47:31,520
гэта як інфраструктуры
проста адразу сыходзіць

2426
01:47:31,520 --> 01:47:33,680
таму што сапраўды
няма інфраструктуры.

2427
01:47:33,680 --> 01:47:35,660
Гэта проста код, які сядзіць на Lambda.

2428
01:47:35,660 --> 01:47:38,560
Гэта проста дадзеныя, якія сядзіць у DynamoDB.

2429
01:47:38,560 --> 01:47:41,340
Гэта дзіўны спосаб
для стварэння прыкладанняў.

2430
01:47:41,340 --> 01:47:43,970
>> АЎДЫТОРЫЯ: Так гэта больш,
эфемерная, чым гэта было б

2431
01:47:43,970 --> 01:47:45,740
калі ён быў захаваны на сэрвэры фактычнай?

2432
01:47:45,740 --> 01:47:46,823
>> РВК Хулихэном: Вы маеце рацыю.

2433
01:47:46,823 --> 01:47:49,190
Таму што гэтага асобніка сервера
б быць 7/24.

2434
01:47:49,190 --> 01:47:51,954
Ён павінен быць даступны для
каб хтосьці рэагаваць.

2435
01:47:51,954 --> 01:47:52,620
Ну думаю, што?

2436
01:47:52,620 --> 01:47:55,410
S3 даступны 7/24.

2437
01:47:55,410 --> 01:47:57,100
S3 заўсёды адказвае.

2438
01:47:57,100 --> 01:47:59,320
І S3 з'яўляецца вельмі, вельмі добра
на абслугоўванне да аб'ектаў.

2439
01:47:59,320 --> 01:48:02,590
Гэтыя аб'екты могуць быць HTML файлы, або
Файлы JavaScript, або што вы хочаце.

2440
01:48:02,590 --> 01:48:07,430
Вы можаце запусціць вельмі багатыя вэб-прыкладанняў
з S3 вядра, і людзі.

2441
01:48:07,430 --> 01:48:10,160
>> І так вось ідэя тут
каб атрымаць ад шляху

2442
01:48:10,160 --> 01:48:11,270
мы выкарыстоўвалі, каб думаць пра гэта.

2443
01:48:11,270 --> 01:48:14,270
Мы ўсе прывыклі думаць, у
Умовы сервераў і хастоў.

2444
01:48:14,270 --> 01:48:16,580
Гэта не пра тое, што больш.

2445
01:48:16,580 --> 01:48:19,310
Гэта аб інфраструктуры, як код.

2446
01:48:19,310 --> 01:48:22,470
Разгортванне кода ў воблаку, і
хай воблака запусціць яго для вас.

2447
01:48:22,470 --> 01:48:24,980
І гэта тое, што AWS спрабуе зрабіць.

2448
01:48:24,980 --> 01:48:29,690
>> АЎДЫТОРЫЯ: Так ваш залаты скрынцы ў сярэдзіне
у API шлюзу не сервер, як,

2449
01:48:29,690 --> 01:48:30,576
але замест гэтага просто--

2450
01:48:30,576 --> 01:48:32,850
>> РВК Хулихэном: Вы можаце думаць
пра яго, як сервера фасада.

2451
01:48:32,850 --> 01:48:38,040
Усё гэта ён будзе прымаць HTTP
запытваць і супаставіць яго з іншым працэсам.

2452
01:48:38,040 --> 01:48:39,192
Гэта ўсё, што ён робіць.

2453
01:48:39,192 --> 01:48:41,525
І ў гэтым выпадку, мы адлюстраванне
гэта функцыя лямбда.

2454
01:48:41,525 --> 01:48:44,119

2455
01:48:44,119 --> 01:48:45,410
Добра, так што гэта ўсё, што я атрымаў.

2456
01:48:45,410 --> 01:48:46,190
Дзякуй вельмі шмат.

2457
01:48:46,190 --> 01:48:46,800
Я цаню гэта.

2458
01:48:46,800 --> 01:48:48,100
Я ведаю, мы хочам трохі на працягу доўгага часу.

2459
01:48:48,100 --> 01:48:49,980
І, спадзяюся, вы, хлопцы, ёсць
трохі інфармацыі

2460
01:48:49,980 --> 01:48:51,410
што вы можаце забраць сёння.

2461
01:48:51,410 --> 01:48:53,520
І я прашу прабачэння, калі я пайшоў
над некаторымі з вашых кіраўнікоў,

2462
01:48:53,520 --> 01:48:56,697
але ёсць добры шмат
фундаментальныя базавыя веды

2463
01:48:56,697 --> 01:48:58,280
Я думаю, што вельмі каштоўна для вас.

2464
01:48:58,280 --> 01:48:59,825
Так што дзякуй вам за тое, што мне.

2465
01:48:59,825 --> 01:49:00,325
[Апладысменты]

2466
01:49:00,325 --> 01:49:02,619
АЎДЫТОРЫЯ: [неразборліва]
калі вы казалі

2467
01:49:02,619 --> 01:49:05,160
Вы павінны былі прайсці праз рэчы
ад пачатку да канца

2468
01:49:05,160 --> 01:49:07,619
каб атрымаць правільныя значэння
або тыя ж значэння,

2469
01:49:07,619 --> 01:49:09,410
Як бы значэння
змяніць, калі [неразборліва].

2470
01:49:09,410 --> 01:49:10,480
>> РВК Хулихэном: О, идемпотентным?

2471
01:49:10,480 --> 01:49:11,800
Як бы змяніць значэння?

2472
01:49:11,800 --> 01:49:15,180
Ну, таму што, калі я не запусціць
усё гэта шлях да канца,

2473
01:49:15,180 --> 01:49:19,770
то я не ведаю, якія змены
былі зробленыя ў апошняй мілі.

2474
01:49:19,770 --> 01:49:22,144
Гэта не збіраецца быць
Тыя ж дадзеныя, як тое, што я ўбачыў.

2475
01:49:22,144 --> 01:49:24,560
АЎДЫТОРЫЯ: О, так ты проста
не атрымалі ўвесь ўваходны.

2476
01:49:24,560 --> 01:49:24,770
РВК Хулихэном: Дакладна.

2477
01:49:24,770 --> 01:49:26,895
Вы павінны ісці ад пачатку
да канца, а затым гэта

2478
01:49:26,895 --> 01:49:29,280
будзе паслядоўнай дзяржаўнай.

2479
01:49:29,280 --> 01:49:31,520
Прахладны.

2480
01:49:31,520 --> 01:49:35,907
>> АЎДЫТОРЫЯ: Такім чынам, вы паказалі нам DynamoDB
можна зрабіць дакумент або ключавое значэнне.

2481
01:49:35,907 --> 01:49:38,740
І мы патрацілі шмат часу на
значэнне ключа з хэш і шляхі

2482
01:49:38,740 --> 01:49:40,005
каб перавярнуць яго вакол.

2483
01:49:40,005 --> 01:49:43,255
Калі вы глядзелі на гэтых табліцах, з'яўляецца тое, што
пакінуўшы падыходу дакумента?

2484
01:49:43,255 --> 01:49:44,600
>> РВК Хулихэном: Я б не
кажуць пакінуўшы яго ззаду.

2485
01:49:44,600 --> 01:49:45,855
>> АЎДЫТОРЫЯ: Яны былі аддзеленыя ад the--

2486
01:49:45,855 --> 01:49:49,140
>> РВК Хулихэном: З дакумента
падыход, тып дакумента ў DynamoDB

2487
01:49:49,140 --> 01:49:50,880
проста думаю, як іншы атрыбут.

2488
01:49:50,880 --> 01:49:53,560
Гэта атрыбут, які змяшчае
іерархічную структуру дадзеных.

2489
01:49:53,560 --> 01:49:56,980
А потым у запытах,
Вы можаце выкарыстоўваць ўласцівасці

2490
01:49:56,980 --> 01:49:59,480
з гэтых аб'ектаў з выкарыстаннем Object Notation.

2491
01:49:59,480 --> 01:50:03,562
Так што я магу фільтраваць па укладзеным
ўласцівасць дакумента JSON.

2492
01:50:03,562 --> 01:50:05,520
АЎДЫТОРЫЯ: Так любы час я
зрабіць дакумент падыход,

2493
01:50:05,520 --> 01:50:07,906
Я магу сартаваць прыбыць у tabular--

2494
01:50:07,906 --> 01:50:08,780
АЎДЫТОРЫЯ: Вы маеце рацыю.

2495
01:50:08,780 --> 01:50:09,800
Аўдыторыя: --indexes і
рэчы, якія вы толькі што казалі аб.

2496
01:50:09,800 --> 01:50:11,280
РВК Хулихэном: Так,
індэксы і ўсё, што,

2497
01:50:11,280 --> 01:50:13,363
калі вы хочаце, каб індэкс ў
ўласцівасці JSON,

2498
01:50:13,363 --> 01:50:18,230
так, што мы павінны зрабіць гэта, калі
Вы ўстаўляеце аб'ект JSON ці дакумент

2499
01:50:18,230 --> 01:50:20,780
у Дынама, вы павінны выкарыстоўваць патокі.

2500
01:50:20,780 --> 01:50:22,400
Патокі будуць чытаць ўвод.

2501
01:50:22,400 --> 01:50:24,340
Вы б атрымаць, што JSON
аб'ект, і вы б сказаць, добра,

2502
01:50:24,340 --> 01:50:26,030
што ўласцівасць Я хачу, каб індэкс?

2503
01:50:26,030 --> 01:50:28,717
>> Вы можаце стварыць вытворную табліцу с.

2504
01:50:28,717 --> 01:50:30,300
Зараз гэта, як ён працуе цяпер.

2505
01:50:30,300 --> 01:50:32,650
Мы не дазваляем індэксаваць
непасрэдна тыя ўласцівасці.

2506
01:50:32,650 --> 01:50:33,520
>> АЎДЫТОРЫЯ: Tabularizing дакументы.

2507
01:50:33,520 --> 01:50:36,230
>> РВК Хулихэном: Роўна, уплощение
гэта, tabularizing яго, дакладна.

2508
01:50:36,230 --> 01:50:37,415
Вось тое, што вы з ім рабіць.

2509
01:50:37,415 --> 01:50:37,860
>> АЎДЫТОРЫЯ: Дзякуй.

2510
01:50:37,860 --> 01:50:39,609
>> РВК Хулихэном: Так,
абсалютна, дзякуй.

2511
01:50:39,609 --> 01:50:42,240
АЎДЫТОРЫЯ: Так што гэта свайго роду
Монго адказвае Redis classifers.

2512
01:50:42,240 --> 01:50:43,990
>> РВК Хулихэном: Так,
гэта шмат, як, што.

2513
01:50:43,990 --> 01:50:45,940
Гэта добрае апісанне для гэтага.

2514
01:50:45,940 --> 01:50:47,490
Прахладны.

2515
01:50:47,490 --> 01:50:49,102