1
00:00:00,000 --> 00:00:04,969
>> [Музички]

2
00:00:04,969 --> 00:00:06,010
RICK Houlihan: Во ред.

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
Сум бил во Облак виртуелизација
за околу 20 години.

12
00:00:30,000 --> 00:00:33,460
Па пред Облак беше Облак,
ние се користат да го наречеме Нови компјутери.

13
00:00:33,460 --> 00:00:37,170
А идејата е, тоа е како
ПГ & Е, да плаќаат за она што го користите.

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
Имам осум патенти во Облак системи
виртуелизација, микропроцесор дизајн,

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
>> Ние ќе влезе во некои од
на internals 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
И ние ќе зборуваме малку за на маса
структура, s, типови на податоци, индекси,

33
00:01:32,420 --> 00:01:35,177
а некои од internals
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
>> Па еден човек со име Херман
Hollerith дојдоа заедно

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

140
00:05:52,640 --> 00:05:58,420
tabulator, и споредување на
механизмите за оваа технологија.

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
Уште од Herman Hollerith
разви перфокарта,

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 година имаше еден
Terabyte на податоци во рамките на управување,

231
00:10:23,510 --> 00:10:27,080
денес тоа значи дека тие се
управување со 6,5 петабајти на податоците.

232
00:10:27,080 --> 00:10:30,380
Тоа е 6.500 пати повеќе податоци.

233
00:10:30,380 --> 00:10:31,200
И знам дека ова.

234
00:10:31,200 --> 00:10:33,292
Јас работам со овие бизниси секој ден.

235
00:10:33,292 --> 00:10:35,000
Пред пет години, јас
ќе разговара со компании

236
00:10:35,000 --> 00:10:38,260
кој ќе разговара со мене за што е болка
тоа е за управување terabytes на податоци.

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

238
00:10:39,700 --> 00:10:41,825
дека ова веројатно се случува
да биде petabyte или две

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
Па, релациони бази на податоци,
Структурно јазик за пребарување,

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 superserver компанијата

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
>> Но, идејата е дека ќе ги чувате
податоците како овие instantiated пати.

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
сака да just-- колку од моите клиенти
имаат оваа одредена карактеристика кој

346
00:15:34,520 --> 00:15:37,850
купен на овој day-- Не знам
она што се пребарува тие се случува да се праша.

347
00:15:37,850 --> 00:15:39,160
Значи ми треба да биде агностик.

348
00:15:39,160 --> 00:15:41,810
>> Сега, во онлајн
трансакциска апликација,

349
00:15:41,810 --> 00:15:43,820
Знам дека она што прашања што барам.

350
00:15:43,820 --> 00:15:46,581
Јас ја направив на пријавата за
многу специфичен тек на работа.

351
00:15:46,581 --> 00:15:47,080
ВО РЕД?

352
00:15:47,080 --> 00:15:50,540
Значи, ако јас се оптимизира на податоци
чувате за поддршка дека работното,

353
00:15:50,540 --> 00:15:52,020
тоа се случува да биде побрзо.

354
00:15:52,020 --> 00:15:55,190
И затоа може NoSQL
Навистина се забрза испорака

355
00:15:55,190 --> 00:15:57,710
од оние типови на услуги.

356
00:15:57,710 --> 00:15:58,210
Во ред.

357
00:15:58,210 --> 00:16:00,501
>> Па ние ќе треба да се влезе во
малку теорија тука.

358
00:16:00,501 --> 00:16:03,330
А некои од вас, вашите очи
Може да се тркалаат назад малку.

359
00:16:03,330 --> 00:16:06,936
Но јас ќе се обиде да го задржи
како високо ниво што можам.

360
00:16:06,936 --> 00:16:08,880
Значи, ако сте во проектот
управување, има

361
00:16:08,880 --> 00:16:12,280
конструкт наречен
триаголникот на ограничувања.

362
00:16:12,280 --> 00:16:12,936
ВО РЕД.

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

364
00:16:16,060 --> 00:16:17,750
Не може да има вашиот пита и го јадат премногу.

365
00:16:17,750 --> 00:16:22,310
Така што во управување со проекти, кои триаголник
ограничувања е можете да го евтини,

366
00:16:22,310 --> 00:16:24,710
ќе може да има брзо,
или може да имаат добро.

367
00:16:24,710 --> 00:16:25,716
Земам две.

368
00:16:25,716 --> 00:16:27,090
Бидејќи не можете да ги имаат сите три.

369
00:16:27,090 --> 00:16:27,460
Нели?

370
00:16:27,460 --> 00:16:27,820
ВО РЕД.

371
00:16:27,820 --> 00:16:28,920
>> Па да се слушне за оваа многу.

372
00:16:28,920 --> 00:16:31,253
Тоа е троен ограничување,
триаголник на тројна ограничување,

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

374
00:16:34,420 --> 00:16:35,420
тие ќе зборуваат за ова.

375
00:16:35,420 --> 00:16:37,640
Сега, бази на податоци
свои железо триаголник.

376
00:16:37,640 --> 00:16:40,350
И железо триаголник на податоци
е она што ние го нарекуваме теорема ЗЗП.

377
00:16:40,350 --> 00:16:41,580
ВО РЕД?

378
00:16:41,580 --> 00:16:43,770
>> ЗЗП теорема диктатот
бази на податоци како работат

379
00:16:43,770 --> 00:16:45,627
под многу специфична состојба.

380
00:16:45,627 --> 00:16:47,460
И ние ќе зборуваме за
што таа состојба се.

381
00:16:47,460 --> 00:16:52,221
Но, три точки на триаголник,
така да се каже, се C, конзистентност.

382
00:16:52,221 --> 00:16:52,720
ВО РЕД?

383
00:16:52,720 --> 00:16:56,760
Па во ЗЗП, конзистентност значи дека сите
клиенти, кои може да пристапите до базата на податоци

384
00:16:56,760 --> 00:16:59,084
секогаш ќе има многу
конзистентен поглед на податоци.

385
00:16:59,084 --> 00:17:00,750
Никој не е ќе видиме две различни нешта.

386
00:17:00,750 --> 00:17:01,480
ВО РЕД?

387
00:17:01,480 --> 00:17:04,020
Ако видам базата на податоци,
Јас гледам на истиот став

388
00:17:04,020 --> 00:17:06,130
како што мојот партнер кој го гледа
истата база на податоци.

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

390
00:17:07,470 --> 00:17:12,099
>> Достапноста значи дека ако
база на податоци на интернет, ако тоа може да се постигне,

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

392
00:17:14,760 --> 00:17:15,260
ВО РЕД?

393
00:17:15,260 --> 00:17:17,010
Така што секој клиент што
да прочитате на база на податоци

394
00:17:17,010 --> 00:17:18,955
секогаш ќе биде во можност за читање
податоци на податоци и да пишува.

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

396
00:17:21,819 --> 00:17:24,230
>> И третата точка е она што
ние го нарекуваме партиција толеранција.

397
00:17:24,230 --> 00:17:24,730
ВО РЕД?

398
00:17:24,730 --> 00:17:28,160
Толеранција партиција средства
дека системот работи добро

399
00:17:28,160 --> 00:17:32,000
покрај физичката мрежа
партиции помеѓу јазли.

400
00:17:32,000 --> 00:17:32,760
ВО РЕД?

401
00:17:32,760 --> 00:17:36,270
Па јазли во кластерот не може
да разговараат со едни со други, што се случува?

402
00:17:36,270 --> 00:17:36,880
Во ред.

403
00:17:36,880 --> 00:17:39,545
>> Па релациони бази на податоци choose--
можете да ги собереш две од овие.

404
00:17:39,545 --> 00:17:40,045
ВО РЕД.

405
00:17:40,045 --> 00:17:43,680
Релациони бази на податоци, па изберете
да бидат доследни и на располагање.

406
00:17:43,680 --> 00:17:47,510
Ако партиција се случува помеѓу
на DataNodes во продавница на податоци,

407
00:17:47,510 --> 00:17:48,831
базата на податоци се урна.

408
00:17:48,831 --> 00:17:49,330
Нели?

409
00:17:49,330 --> 00:17:50,900
Тоа само оди надолу.

410
00:17:50,900 --> 00:17:51,450
ВО РЕД.

411
00:17:51,450 --> 00:17:54,230
>> А тоа е зошто тие имаат
да расте со поголема кутии.

412
00:17:54,230 --> 00:17:54,730
Нели?

413
00:17:54,730 --> 00:17:58,021
Бидејќи има no-- обично, кластер
база на податоци, таму не е многу голем дел од нив

414
00:17:58,021 --> 00:17:59,590
кои работат на тој начин.

415
00:17:59,590 --> 00:18:03,019
Но повеќето бази скала
вертикално во една кутија.

416
00:18:03,019 --> 00:18:05,060
Бидејќи тие треба да бидат
доследни и на располагање.

417
00:18:05,060 --> 00:18:10,320
Ако партиција требаше да се инјектира,
тогаш вие ќе треба да се направи избор.

418
00:18:10,320 --> 00:18:13,720
Што треба да се направи избор меѓу
да се биде доследен и достапни.

419
00:18:13,720 --> 00:18:16,080
>> И тоа е она што го направи NoSQL бази на податоци.

420
00:18:16,080 --> 00:18:16,580
Во ред.

421
00:18:16,580 --> 00:18:20,950
Значи, за базата на податоци NoSQL тоа,
доаѓа во две варијанти.

422
00:18:20,950 --> 00:18:22,990
Ние have-- добро, тоа
доаѓа во многу вкусови,

423
00:18:22,990 --> 00:18:26,140
но тоа доаѓа со два основни
characteristics-- што

424
00:18:26,140 --> 00:18:30,050
ние би го нарекол КП база на податоци, или
доследни и партиција толеранција

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
Ние ќе мора да
reestablish комуникација

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
И ова се нарекува трансакции киселина.

464
00:20:00,500 --> 00:20:01,000
ВО РЕД?

465
00:20:01,000 --> 00:20:06,570
>> КИСЕЛИНА ни дава atomicity, конзистентност,
изолација, и издржливост.

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
>> Така, тоа е малку различен
од конзистентност ЗЗП.

473
00:20:26,720 --> 00:20:29,760
Конзистентност ЗЗП значи сите мои
клиенти секогаш може да се види на податоците.

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
Значи ние треба нашите КП, АП бази на податоци.

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
>> Сега, теорема ЗЗП навистина
игра само во еден услов.

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
Се грижите само за земјоделска политика
кога имаме таа партиција.

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
АП системи доаѓаат во две варијанти.

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
Ајде да се јавите на тој објект С.
Па ние имаме држава за С.

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
По дифолт, во последно ажурирање
победи во повеќето системи за АП.

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
Повратен повик и стандардно стандардно
преведување во повеќето АП бази на податоци

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
И всушност можете да шутнат евиденција за
сите судири и rollbacks

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
Па АП системи имаат ова.

604
00:25:49,700 --> 00:25:51,615
Системи ЦП не треба
да се грижите за тоа.

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
Тоа е со системи ЦП се направи.

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
Јас имам проект на производот,
и на тој проект е еднаква

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
мапи проект на актерот да видеото проект.

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
Сум deduplicated сите мои актери,
и јас се одржува мојата здруженија

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
е документ во табелата на производи.

705
00:29:51,930 --> 00:29:56,510
И производот за една книга може да
имаат проект тип кој одредува книга.

706
00:29:56,510 --> 00:29:59,180
И апликација
ќе се преориентираат на тој проект.

707
00:29:59,180 --> 00:30:02,570
>> На ниво на пријавата, јас ќе одам
да се каже О, што запис е ова?

708
00:30:02,570 --> 00:30:04,100
Ох, тоа е книга рекорд.

709
00:30:04,100 --> 00:30:05,990
Евиденција книга имаат овие својства.

710
00:30:05,990 --> 00:30:08,100
Дозволете ми да се направи книга објект.

711
00:30:08,100 --> 00:30:11,289
Па јас ќе одам да се пополни
книга објект со оваа точка.

712
00:30:11,289 --> 00:30:13,080
Следната точка доаѓа и
вели, што е овој предмет?

713
00:30:13,080 --> 00:30:14,560
И оваа точка е албум.

714
00:30:14,560 --> 00:30:17,340
О, јас влегов во целина различни
обработка рутина за тоа,

715
00:30:17,340 --> 00:30:18,487
затоа што тоа е еден албум.

716
00:30:18,487 --> 00:30:19,320
Гледаш што мислам?

717
00:30:19,320 --> 00:30:21,950
>> Па примената tier-- јас
само изберете сите овие записи.

718
00:30:21,950 --> 00:30:23,200
Сите тие почнат да доаѓаат во.

719
00:30:23,200 --> 00:30:24,680
Тие можат да бидат сите различни видови.

720
00:30:24,680 --> 00:30:27,590
И тоа е логиката на апликацијата
кои водат низ овие видови

721
00:30:27,590 --> 00:30:29,530
и одлучува како да ги процесира.

722
00:30:29,530 --> 00:30:33,640
>> Повторно, па ние сме оптимизирање на
шема за модел за пристап.

723
00:30:33,640 --> 00:30:36,390
Ние сме го прави тоа од страна на
уривање оние маси.

724
00:30:36,390 --> 00:30:39,670
Ние сме во основа преземање
овие нормализиран структури,

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

726
00:30:42,000 --> 00:30:45,130
Во секој од овие записи
Одам да се види низа својства.

727
00:30:45,130 --> 00:30:49,400
>> Во внатрешноста на овој документ за албуми,
Јас гледам низи на песни.

728
00:30:49,400 --> 00:30:53,900
Оние песни сега become-- тоа е
во основа тоа дете маса што

729
00:30:53,900 --> 00:30:56,520
постои право овде, во оваа структура.

730
00:30:56,520 --> 00:30:57,975
За да можете да го направите тоа во DynamoDB.

731
00:30:57,975 --> 00:30:59,810
Можете да го направите тоа во MongoDB.

732
00:30:59,810 --> 00:31:01,437
Можете да го направите во било која база на податоци NoSQL.

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

734
00:31:03,520 --> 00:31:07,120
кои ви дозволуваат да се приберат податоци
многу брзо, бидејќи сега јас

735
00:31:07,120 --> 00:31:08,537
не мора да се приспособат.

736
00:31:08,537 --> 00:31:11,620
Кога ќе внесете ред во песни
маса, или ред во табелата на албуми,

737
00:31:11,620 --> 00:31:13,110
Морам да се прилагодат на таа шема.

738
00:31:13,110 --> 00:31:18,060
Јас мора да имаат својство или
имотот што е дефинирано на таа табела.

739
00:31:18,060 --> 00:31:20,480
Секој еден од нив,
кога ќе го пуштите истиот ред.

740
00:31:20,480 --> 00:31:21,910
Тоа не е случај и во NoSQL.

741
00:31:21,910 --> 00:31:24,440
>> Јас може да имаат сосема различни
својства во секој документ

742
00:31:24,440 --> 00:31:26,100
дека јас вметнете во колекцијата.

743
00:31:26,100 --> 00:31:30,480
Толку многу моќен механизам.

744
00:31:30,480 --> 00:31:32,852
И тоа е начинот на кој
оптимизираат системот.

745
00:31:32,852 --> 00:31:35,310
Бидејќи сега кога пребарување, наместо
за приклучување на сите овие табели

746
00:31:35,310 --> 00:31:39,160
и извршување на половина дузина прашања
да се повлечат на податоци што ми треба,

747
00:31:39,160 --> 00:31:40,890
Јас сум извршување едно пребарување.

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

749
00:31:43,010 --> 00:31:46,512
тоа ви дава една идеја
на моќта на NoSQL.

750
00:31:46,512 --> 00:31:49,470
Одам да се вид на одат накосо тука
и зборува малку за ова.

751
00:31:49,470 --> 00:31:53,240
Ова е повеќе вид на
маркетинг или 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
Но тоа е како, кога
jackhammer бил измислен,

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
Тоа значи дека сте ја добиле 1.200
сервери, кои треба да бидат ажурирани.

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
Сите тие се вид на добивање на
munged заедно во овој момент.

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
Идентитет за управување со пристап, или ИВЗ.

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
во ИВЗ инфраструктура.

882
00:37:12,140 --> 00:37:16,630
>> И тоа е клучен и интегрална компонента во
она што го нарекуваме Настан управувано програмирање.

883
00:37:16,630 --> 00:37:19,056
Сега ова е нова парадигма.

884
00:37:19,056 --> 00:37:22,080
>> ПУБЛИКАТА: Како е вашиот стапка на вистински
позитивни наспроти лажно негативни

885
00:37:22,080 --> 00:37:24,052
на вашиот систем за контрола на пристап?

886
00:37:24,052 --> 00:37:26,260
RICK Houlihan: вистински позитивни
наспроти лажно негативни?

887
00:37:26,260 --> 00:37:28,785
ПУБЛИКАТА: Враќање што
ќе треба да се враќаат?

888
00:37:28,785 --> 00:37:33,720
За разлика од време на време тоа
не се врати кога тоа треба да се провери?

889
00:37:33,720 --> 00:37:36,260

890
00:37:36,260 --> 00:37:38,050
>> RICK Houlihan: Не можев да ти кажам дека.

891
00:37:38,050 --> 00:37:40,140
Ако има било неуспеси
она што на тоа,

892
00:37:40,140 --> 00:37:42,726
Јас не сум човек да прашам
дека одредено прашање.

893
00:37:42,726 --> 00:37:43,850
Но, тоа е добро прашање.

894
00:37:43,850 --> 00:37:45,905
Јас би бил љубопитен да знаете
дека јас, всушност.

895
00:37:45,905 --> 00:37:48,810

896
00:37:48,810 --> 00:37:51,320
>> И така, тогаш повторно, нова парадигма
е настан управувано програмирање.

897
00:37:51,320 --> 00:37:55,160
Ова е идејата дека може да се
распореди сложени апликации кои

898
00:37:55,160 --> 00:37:59,720
може да работи на многу, многу високо ниво
без инфраструктура она.

899
00:37:59,720 --> 00:38:02,120
Без било кој фиксен
инфраструктура она.

900
00:38:02,120 --> 00:38:04,720
И ние ќе зборуваме малку
за тоа што значи дека како што ние

901
00:38:04,720 --> 00:38:06,550
добие на следните неколку листи.

902
00:38:06,550 --> 00:38:08,716
>> Првото нешто што ние ќе го направиме
е ние ќе зборуваме за маси.

903
00:38:08,716 --> 00:38:10,857
Типови на податоци API за Динамо.

904
00:38:10,857 --> 00:38:13,190
И првото нешто што ќе
забележите кога ќе се погледне на овој,

905
00:38:13,190 --> 00:38:17,930
ако сте запознаени со било која база на податоци,
бази на податоци имаат навистина две вид на API-јата

906
00:38:17,930 --> 00:38:18,430
Би го нарекуваат.

907
00:38:18,430 --> 00:38:21,570
Или две групи на API.

908
00:38:21,570 --> 00:38:23,840
Еден од тие ќе бидат
административни API.

909
00:38:23,840 --> 00:38:26,710
>> Работите што се грижи за
функциите на базата на податоци.

910
00:38:26,710 --> 00:38:31,340
Конфигурирање на моторот за чување,
поставување и додавање табели.

911
00:38:31,340 --> 00:38:35,180
создавањето на базата
каталози и инстанци.

912
00:38:35,180 --> 00:38:40,450
Овие things-- во DynamoDB, можете
имаат многу краток, кратки листи.

913
00:38:40,450 --> 00:38:43,120
>> Значи со други бази на податоци,
можеби ќе видите десетици

914
00:38:43,120 --> 00:38:45,680
на команди, на административните
команди, за конфигурирање

915
00:38:45,680 --> 00:38:47,290
овие дополнителни опции.

916
00:38:47,290 --> 00:38:51,234
Во DynamoDB што не треба, бидејќи тие
не го конфигурирате системот, тоа го правиме.

917
00:38:51,234 --> 00:38:54,150
Па единственото нешто што треба да направите е да се
да ми кажете што на маса големина ми е потребно.

918
00:38:54,150 --> 00:38:55,660
Така да се добие многу
ограничен сет на команди.

919
00:38:55,660 --> 00:38:58,618
>> Добивате создаде маса ажурирање, масичка,
Бришење на маса, и се опише табела.

920
00:38:58,618 --> 00:39:01,150
Тие се единствените нешта
ви треба за DynamoDB.

921
00:39:01,150 --> 00:39:03,294
Не ви е потребен за складирање
конфигурација.

922
00:39:03,294 --> 00:39:04,960
Јас не треба да се грижите за репликација.

923
00:39:04,960 --> 00:39:06,490
Јас не треба да се грижите за sharding.

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
Значи, ако имате Јава, ти си
гледање на карти и листи.

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
>> Па јас би можеле да имаат хаш
клуч, кој е проект на темата.

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
>> И ако имам лична карта, а тоа
е мојот клуч хаш, имам 1, 2, 3.

1044
00:45:04,765 --> 00:45:07,390
Кога јас се кандидира на хаш алгоритам,
тоа се случува да се врати и да каже,

1045
00:45:07,390 --> 00:45:10,800
и 1 еднаква 7B, 2
еднакво на 48, 3 дава ЦД.

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
Тоа е antipattern.

1067
00:46:04,820 --> 00:46:08,760
Во MongoDB тие имаат овој проблем
ако не го користите клучниот хаш.

1068
00:46:08,760 --> 00:46:11,325
MongoDB ви дава опција
на hashing вредноста на клучот.

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
>> ПУБЛИКАТА: Дали е тоа А9 169 во децимални?

1073
00:46:24,896 --> 00:46:28,450
>> RICK Houlihan: Да, тоа е
некаде таму.

1074
00:46:28,450 --> 00:46:29,950
А9, јас не знам.

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
Така е проект на објектот кој доаѓа
природно со Mongo го направите тоа?

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

1080
00:46:40,179 --> 00:46:41,470
RICK Houlihan: Дали тоа го правите тоа?

1081
00:46:41,470 --> 00:46:42,970
Ако го определи.

1082
00:46:42,970 --> 00:46:45,030
Со MongoDB, имаш опција.

1083
00:46:45,030 --> 00:46:48,930
Можете да specify-- секој документ во
MongoDB мора да има проект друг знак.

1084
00:46:48,930 --> 00:46:50,300
Тоа е уникатна вредност.

1085
00:46:50,300 --> 00:46:55,240
>> Во MongoDB можете да наведете
дали да го хаш или не.

1086
00:46:55,240 --> 00:46:56,490
Тие само ви даде опција.

1087
00:46:56,490 --> 00:46:58,198
Ако знаете дека тоа е
случајни, нема проблем.

1088
00:46:58,198 --> 00:46:59,640
Вие не треба да го направат тоа.

1089
00:46:59,640 --> 00:47:04,260
Ако знаете дека тоа не е случајно, дека
тоа ја зголемува, тогаш направете го хаш.

1090
00:47:04,260 --> 00:47:06,880
>> Сега на работа во врска со
hashing, но откако ќе хаш

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
бидејќи hash вредност не се случува
да бидат еднакви на реалната вредност.

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 како nonrelational.

1114
00:48:20,760 --> 00:48:22,200
Тоа не е nonrelational.

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
Што значи дека имаме три АЗ е.

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
А неуспех во еден АЗ не е
нема да ги симнат на друг.

1126
00:48:54,510 --> 00:48:56,890
Тие, исто така се поврзани
заедно со темни влакна.

1127
00:48:56,890 --> 00:49:01,240
Таа поддржува еден под 1
милисекунда латентност помеѓу AZS.

1128
00:49:01,240 --> 00:49:05,390
Толку реално време имитации податоци
способен во мулти AZS.

1129
00:49:05,390 --> 00:49:09,990
>> И честопати мулти распоредувања АЗ
ги задоволи високите барања достапност

1130
00:49:09,990 --> 00:49:12,930
на повеќето организации претпријатие.

1131
00:49:12,930 --> 00:49:16,139
Па DynamoDB се шири
низ три AZS од стандардните.

1132
00:49:16,139 --> 00:49:19,430
Ние сме само ќе знаење пишувам
кога две од овие три јазли се врати

1133
00:49:19,430 --> 00:49:21,470
и да каже, да, јас го зедов тоа.

1134
00:49:21,470 --> 00:49:22,050
Зошто е тоа?

1135
00:49:22,050 --> 00:49:25,950
Затоа што на страната на читање ние сме само
одам да ви даде податоците назад, кога

1136
00:49:25,950 --> 00:49:27,570
ние го добие од два јазли.

1137
00:49:27,570 --> 00:49:30,490
>> Ако сум реплицира низ
три, и го читам од две,

1138
00:49:30,490 --> 00:49:32,840
Јас сум секогаш загарантирана
да имаат најмалку еден

1139
00:49:32,840 --> 00:49:35,720
на оние кои се вели дека е
најактуелните копија на податоците.

1140
00:49:35,720 --> 00:49:38,340
Тоа е она што го прави DynamoDB доследни.

1141
00:49:38,340 --> 00:49:42,450
Сега можете да изберете да го вклучите
оние кои се во согласност стои надвор.

1142
00:49:42,450 --> 00:49:45,070
Во кој случај, јас ќе одам да се каже,
Јас ќе го прочитаат само од еден јазол.

1143
00:49:45,070 --> 00:49:47,430
И јас не може да гарантира дека тоа нема
да биде најмногу тековните податоци.

1144
00:49:47,430 --> 00:49:49,450
>> Па ако некој пишува доаѓа во,
тоа не се повтори уште,

1145
00:49:49,450 --> 00:49:50,360
си оди за да се добие таа копија.

1146
00:49:50,360 --> 00:49:52,220
Тоа е крајот доследни читање.

1147
00:49:52,220 --> 00:49:54,640
И она што е е половина од цената.

1148
00:49:54,640 --> 00:49:56,140
Па ова е нешто да се размислува за.

1149
00:49:56,140 --> 00:50:00,160
Кога ќе го читаш надвор DynamoDB, и
сте поставување на вашиот капацитет за читање

1150
00:50:00,160 --> 00:50:04,430
единици, ако решите на крајот
конзистентна чита, тоа е многу поевтино,

1151
00:50:04,430 --> 00:50:06,010
тоа е за половина од цената.

1152
00:50:06,010 --> 00:50:09,342
>> И така ви заштедува пари.

1153
00:50:09,342 --> 00:50:10,300
Но, тоа е ваш избор.

1154
00:50:10,300 --> 00:50:12,925
Ако сакате доследни читање или
на крајот се доследни читање.

1155
00:50:12,925 --> 00:50:15,720
Тоа е нешто што можете да одберете.

1156
00:50:15,720 --> 00:50:17,659
>> Ајде да зборуваме за индекси.

1157
00:50:17,659 --> 00:50:19,450
Значи ние се напомене дека
ниво агрегација врвот.

1158
00:50:19,450 --> 00:50:23,720
Имаме хаш клучеви, и
имаме клучеви опсег.

1159
00:50:23,720 --> 00:50:24,320
Тоа е фино.

1160
00:50:24,320 --> 00:50:26,950
И тоа е на основните маса, јас
доби една клучна хаш, добив една клучна опсег.

1161
00:50:26,950 --> 00:50:27,783
>> Што значи тоа?

1162
00:50:27,783 --> 00:50:30,410
Јас имам еден атрибут дека јас
може да работи богата пребарувања против.

1163
00:50:30,410 --> 00:50:31,800
Тоа е клучот на опсег.

1164
00:50:31,800 --> 00:50:35,530
Други атрибути на тој item--
Јас може да се филтрираат на овие атрибути.

1165
00:50:35,530 --> 00:50:40,050
Но не можам да ги правите нештата како тоа
почнува со, или е поголема од.

1166
00:50:40,050 --> 00:50:40,820
>> Како можам да го направите тоа?

1167
00:50:40,820 --> 00:50:42,860
Создадам индекс.

1168
00:50:42,860 --> 00:50:45,340
Има два вида на
индекси во DynamoDB.

1169
00:50:45,340 --> 00:50:49,002
Индекс е навистина
уште еден поглед на табелата.

1170
00:50:49,002 --> 00:50:50,490
И локалното средно индекс.

1171
00:50:50,490 --> 00:50:51,781
>> Првиот што ќе се зборува за.

1172
00:50:51,781 --> 00:50:57,740
Така да локалните секундарни се коегзистирале
на иста партиција, како на податоци.

1173
00:50:57,740 --> 00:51:00,240
И како такви, тие се на
истите физички јазол.

1174
00:51:00,240 --> 00:51:01,780
Тие се она што ние го нарекуваме доследни.

1175
00:51:01,780 --> 00:51:04,599
Значење, тие ќе признаат
пишува заедно со масата.

1176
00:51:04,599 --> 00:51:06,890
Кога пишувам доаѓа во,
ние ќе пишувам преку индексот.

1177
00:51:06,890 --> 00:51:09,306
Ќе пишувам до масата,
и тогаш ќе го признае.

1178
00:51:09,306 --> 00:51:10,490
Значи тоа е конзистентна.

1179
00:51:10,490 --> 00:51:13,174
Откако на запишување е
признати од табелата,

1180
00:51:13,174 --> 00:51:15,090
тоа е гарантирано дека
локално средно индекс

1181
00:51:15,090 --> 00:51:18,380
ќе имаат иста визија на податоци.

1182
00:51:18,380 --> 00:51:22,390
Но, она што ќе ви овозможи да направите е да се
дефинираат алтернативни клучеви опсег.

1183
00:51:22,390 --> 00:51:25,260
>> Мора да се користи истиот хеш
Клучот како примарен маса,

1184
00:51:25,260 --> 00:51:29,050
бидејќи тие се ко-лоцирани на
иста партиција, а тие се доследни.

1185
00:51:29,050 --> 00:51:33,110
Но, можам да креирате индекс
со различни клучеви опсег.

1186
00:51:33,110 --> 00:51:41,590
Така на пример, ако имав производителот
кој имаше маса суровини делови кои доаѓаат во.

1187
00:51:41,590 --> 00:51:44,590
И суровини делови дојдат, и
тие се собрани од страна на Собранието.

1188
00:51:44,590 --> 00:51:46,840
А можеби и таму е се потсетиме.

1189
00:51:46,840 --> 00:51:50,240
>> Било кој дел, што е направено од страна на овој
производителот по овој датум,

1190
00:51:50,240 --> 00:51:52,840
Јас треба да се повлече од мојата линија.

1191
00:51:52,840 --> 00:51:55,950
Јас може да се вртат индекс
дека ќе се бара,

1192
00:51:55,950 --> 00:52:00,760
Собирање на денот на
Производство на тој дел.

1193
00:52:00,760 --> 00:52:03,930
Значи, ако мојата маса ниво беше
веќе hashed од страна на производителот,

1194
00:52:03,930 --> 00:52:07,655
Можеби тоа беше договорено на дел проект, јас
може да креирате индекс слезе од табелата

1195
00:52:07,655 --> 00:52:11,140
како hashed од производителот и
се движи на датумот на производство.

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
>> Ова има ефект на
ограничување на вашиот хаш space копчето.

1200
00:52:22,280 --> 00:52:24,360
Бидејќи тие егзистирале
на истата складирање јазол,

1201
00:52:24,360 --> 00:52:26,860
тие се ограничи клучните хаш
простор до 10 гигабајти.

1202
00:52:26,860 --> 00:52:28,950
DynamoDB, под
маси, ќе партиција

1203
00:52:28,950 --> 00:52:31,380
вашата маса на секои 10 гигабајти.

1204
00:52:31,380 --> 00:52:34,760
Кога ќе се стави 10 свирки на податоци во, ние
одат [PHH], а ние се додаде уште еден јазол.

1205
00:52:34,760 --> 00:52:38,120

1206
00:52:38,120 --> 00:52:42,070
>> Ние не ќе се подели на ЛСИ
низ повеќе партиции.

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 гигабајти на вашиот LSIs.

1212
00:52:53,860 --> 00:52:56,640
>> Ако тоа е случај, можеме да
користат глобалните секундарни.

1213
00:52:56,640 --> 00:52:58,630
Глобалната се секундарни
навистина друга маса.

1214
00:52:58,630 --> 00:53:01,720
Тие постојат целосно исклучување на
на страната на вашиот примарен табелата.

1215
00:53:01,720 --> 00:53:04,680
И тие ми овозможи да се најде
сосема поинаква структура.

1216
00:53:04,680 --> 00:53:08,010
Значи мислам на тоа како се поставува на податоци
во две различни маси, структурирани

1217
00:53:08,010 --> 00:53:09,220
во два различни начини.

1218
00:53:09,220 --> 00:53:11,360
>> Јас може да се дефинира целосно
различни хаш клуч.

1219
00:53:11,360 --> 00:53:13,490
Јас може да се дефинира целосно
различни клучни опсег.

1220
00:53:13,490 --> 00:53:15,941
И можам да ја извршите оваа
целосно независно.

1221
00:53:15,941 --> 00:53:18,190
Како што, впрочем, јас сум
пропишана мојот капацитет за читање

1222
00:53:18,190 --> 00:53:21,090
и да пишувам за мојот капацитет
глобалната секундарни индекси

1223
00:53:21,090 --> 00:53:24,240
целосно независно
на мојата примарна табела.

1224
00:53:24,240 --> 00:53:26,640
Ако јас се дефинира тој индекс, им кажувам
тоа колку читаат и пишуваат

1225
00:53:26,640 --> 00:53:28,610
капацитет тоа се случува да биде во употреба.

1226
00:53:28,610 --> 00:53:31,490
>> И кој е одделен
од мојата примарна табела.

1227
00:53:31,490 --> 00:53:35,240
Сега двата индекси ни овозможи да се
не само што го дефинираат хаш и опсег на клучеви,

1228
00:53:35,240 --> 00:53:38,610
но тие ни овозможуваат да се
проектираат дополнителни вредности.

1229
00:53:38,610 --> 00:53:44,950
Па ако сакам да прочитам на индекс,
и сакам да се добијат некои збир на податоци,

1230
00:53:44,950 --> 00:53:48,327
Јас не треба да се вратиме на главното
табела за да го добиете дополнителни атрибути.

1231
00:53:48,327 --> 00:53:50,660
Јас може да го предвиди оние дополнителни
атрибути во табелата

1232
00:53:50,660 --> 00:53:53,440
за поддршка на шемата за пристап.

1233
00:53:53,440 --> 00:53:57,700
Знам дека си веројатно се навлегува во некои
навистина, really-- навлегува во плевел

1234
00:53:57,700 --> 00:53:58,910
тука на некои од овие работи.

1235
00:53:58,910 --> 00:54:02,725
Сега добив да лебдат надвор од ова.

1236
00:54:02,725 --> 00:54:07,320
>> ПУБЛИКАТА: [Беззвучен]
--table клучните мислеше е хаш?

1237
00:54:07,320 --> 00:54:08,840
Оригиналниот хаш?

1238
00:54:08,840 --> 00:54:09,340
Мулти-ребра?

1239
00:54:09,340 --> 00:54:10,200
>> RICK Houlihan: Да.

1240
00:54:10,200 --> 00:54:11,070
Да.

1241
00:54:11,070 --> 00:54:15,260
Клуч на табелата во основа
поени назад кон објектот.

1242
00:54:15,260 --> 00:54:19,280
Па индекс е покажувач назад до
оригинални предмети на масата.

1243
00:54:19,280 --> 00:54:22,910
Сега можете да изберете да се изгради
индекс, кој има само клуч на маса,

1244
00:54:22,910 --> 00:54:24,840
и нема други својства.

1245
00:54:24,840 --> 00:54:26,570
И зошто би можеле да го направам тоа?

1246
00:54:26,570 --> 00:54:28,570
Па, можеби и јас имам многу големи предмети.

1247
00:54:28,570 --> 00:54:31,660
>> Јас навистина само треба да знаете which--
мојот модел на пристап може да се каже,

1248
00:54:31,660 --> 00:54:33,760
кои предмети содржат овој имот?

1249
00:54:33,760 --> 00:54:35,780
Не треба да се врати на објектот.

1250
00:54:35,780 --> 00:54:37,800
Јас само треба да знаете
кои предмети го содржат.

1251
00:54:37,800 --> 00:54:40,700
За да може да се изгради индекси
кои имаат само еден клуч на табелата.

1252
00:54:40,700 --> 00:54:43,360
>> Но, тоа е пред се она што
индекс во базата на податоци е за.

1253
00:54:43,360 --> 00:54:46,280
Тоа е за да се биде во можност брзо да
идентификуваат која евиденција,

1254
00:54:46,280 --> 00:54:49,470
кои редови, кои
предмети во табелата имаат

1255
00:54:49,470 --> 00:54:51,080
својствата кои сум во потрага по.

1256
00:54:51,080 --> 00:54:53,610

1257
00:54:53,610 --> 00:54:54,860
>> GSIs, па како функционираат тие?

1258
00:54:54,860 --> 00:54:58,340
GSIs во основа се асинхрони.

1259
00:54:58,340 --> 00:55:02,570
Ажурирање доаѓа во табелата,
маса е тогаш асинхроно ажурирани

1260
00:55:02,570 --> 00:55:03,720
на сите ваши GSIs.

1261
00:55:03,720 --> 00:55:06,680
Ова е причината зошто GSIs се
на крај доследни.

1262
00:55:06,680 --> 00:55:09,440
>> Важно е да се напомене дека
кога ќе градиме GSIs,

1263
00:55:09,440 --> 00:55:13,110
и да се разбере сте создавање
друга димензија на aggregation--

1264
00:55:13,110 --> 00:55:16,594
Сега да речеме добар пример
тука е производител.

1265
00:55:16,594 --> 00:55:19,260
Мислам дека може да се зборува за
производителот на медицинскиот уред.

1266
00:55:19,260 --> 00:55:23,870
Производителите на медицинските помагала
Честопати имаат серијали делови.

1267
00:55:23,870 --> 00:55:28,070
Делови кои одат во
замена на колк сите

1268
00:55:28,070 --> 00:55:30,200
имаат малку серискиот број на нив.

1269
00:55:30,200 --> 00:55:33,584
И тие би можеле да имаат милиони и
милиони и милијарди делови

1270
00:55:33,584 --> 00:55:35,000
во сите уреди кои можат да брод.

1271
00:55:35,000 --> 00:55:37,440
Па, тие треба да ја собира под
со различни димензии, сите делови

1272
00:55:37,440 --> 00:55:39,520
во собранието, сите
делови кои биле направени

1273
00:55:39,520 --> 00:55:41,670
на одредена линија, сите
делови кои дојдоа

1274
00:55:41,670 --> 00:55:44,620
во од одреден производител
на одреден датум.

1275
00:55:44,620 --> 00:55:47,940
И овие агрегации понекогаш
станувам во милијарди.

1276
00:55:47,940 --> 00:55:50,550
>> Па јас работам со некои од
овие момци кои страдаат

1277
00:55:50,550 --> 00:55:53,156
бидејќи тие се создавање
овие џиновските агрегации

1278
00:55:53,156 --> 00:55:54,280
во средното индекси.

1279
00:55:54,280 --> 00:55:57,070
Тие може да имаат суровини делови
маса што доаѓа како само хаш.

1280
00:55:57,070 --> 00:55:59,090
Секој дел има уникатен сериски број.

1281
00:55:59,090 --> 00:56:00,975
Јас го користам на сериски број како хаш.

1282
00:56:00,975 --> 00:56:01,600
Убаво е.

1283
00:56:01,600 --> 00:56:04,160
Суровини мојата маса податоци се шири
целиот простор клуч.

1284
00:56:04,160 --> 00:56:05,930
Моето [? пишува?]
[? голтање?] е неверојатна.

1285
00:56:05,930 --> 00:56:07,876
И јас земам уште голем број на податоци.

1286
00:56:07,876 --> 00:56:09,500
Тогаш она што го прават е тие создаваат GSI.

1287
00:56:09,500 --> 00:56:12,666
И велам, знаеш што, јас треба да се види
сите делови за овој производител.

1288
00:56:12,666 --> 00:56:15,060
Па, одеднаш сум
земајќи милијарди редови,

1289
00:56:15,060 --> 00:56:17,550
и да ги работи со излез
еден јазол, затоа што кога

1290
00:56:17,550 --> 00:56:21,170
Јас агрегираат како
производителот проект како хаш,

1291
00:56:21,170 --> 00:56:25,410
и дел број како опсег,
потоа сите одеднаш сум

1292
00:56:25,410 --> 00:56:30,530
ставање милијарда делови во она што
овој производител ме избави.

1293
00:56:30,530 --> 00:56:34,447
>> Кој може да предизвика многу
на притисок врз GSI,

1294
00:56:34,447 --> 00:56:36,030
повторно, бидејќи јас сум ковале еден јазол.

1295
00:56:36,030 --> 00:56:38,350
Јас сум ставање на сите овие
внесува во еден јазол.

1296
00:56:38,350 --> 00:56:40,940
И тоа е вистински проблематична употреба случај.

1297
00:56:40,940 --> 00:56:43,479
Сега, добив добар дизајн
модел за тоа како да се избегне тоа.

1298
00:56:43,479 --> 00:56:45,770
И тоа е еден од проблемите
дека секогаш се работи со.

1299
00:56:45,770 --> 00:56:49,590
Но, она што се случува, е можеби GSI
нема доволно капацитет за запишување

1300
00:56:49,590 --> 00:56:52,330
да бидат во можност да им помогнам на сите оние
редови во еден јазол.

1301
00:56:52,330 --> 00:56:55,390
И што се случува тогаш е
примарна, маса на клиентот,

1302
00:56:55,390 --> 00:57:00,180
од основните маса ќе биде пригушен
GSI затоа што не можат да продолжат.

1303
00:57:00,180 --> 00:57:02,980
Значи мојот вметнете стапка ќе
падне на основните маса

1304
00:57:02,980 --> 00:57:06,230
како мојот GSI се обидува да го задржи.

1305
00:57:06,230 --> 00:57:08,850
>> Добро, па GSI е, LSI е,
кој треба да го користам?

1306
00:57:08,850 --> 00:57:12,290
LSI се конзистентни.

1307
00:57:12,290 --> 00:57:13,750
GSI се на крај доследни.

1308
00:57:13,750 --> 00:57:17,490
Ако тоа е во ред, јас препорачуваме користење на
GSI, тие се многу пофлексибилни.

1309
00:57:17,490 --> 00:57:20,270
LSI може да се моделираат како GSI.

1310
00:57:20,270 --> 00:57:27,040
И ако големината на податоците по хаш клучеви во
вашата колекција надминува 10 гигабајти,

1311
00:57:27,040 --> 00:57:31,050
тогаш ви се случува да сакаат да го користат
GSI бидејќи тоа е само еден хард рок.

1312
00:57:31,050 --> 00:57:32,035
>> Добро, така скалирање.

1313
00:57:32,035 --> 00:57:35,210

1314
00:57:35,210 --> 00:57:37,460
Автопат во Динамо ДБ, можете
обезбедување може [Беззвучен]

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 k е вкупната големина
на таа ствар, 400 килобајти.

1339
00:58:43,950 --> 00:58:46,170
Па на сите атрибути
во комбинација, на сите податоци

1340
00:58:46,170 --> 00:58:49,140
тоа е во сите оние атрибути,
навива во вкупната големина,

1341
00:58:49,140 --> 00:58:51,140
моментално денес ограничување на објектот е 400 к.

1342
00:58:51,140 --> 00:58:54,390

1343
00:58:54,390 --> 00:58:57,046
Така скалирање повторно, постигнат
преку партиционирање.

1344
00:58:57,046 --> 00:58:58,920
Автопат е предвидено
на ниво на табелата.

1345
00:58:58,920 --> 00:59:00,160
И таму е навистина две рачки.

1346
00:59:00,160 --> 00:59:02,400
Ние ги прочитале капацитет
и пишува капацитет.

1347
00:59:02,400 --> 00:59:05,530
>> Значи овие се прилагоди
независно еден од друг.

1348
00:59:05,530 --> 00:59:08,640
Мерка RCU е строго конзистентни чита.

1349
00:59:08,640 --> 00:59:13,005
Добро, па ако си ти што зборуваш Сакам 1,000
RCU е тие се строго во согласност,

1350
00:59:13,005 --> 00:59:14,130
оние кои се во согласност чита.

1351
00:59:14,130 --> 00:59:17,130
Ако ви кажам што сакам
евентуална согласност чита,

1352
00:59:17,130 --> 00:59:19,402
можеш одредба 1.000
RCU е, си оди

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% од вашите RCU,

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
И ова се добивање на најмногу
од Динамо ДБ автопат,

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-- јас
порано работела во Mongo.

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
>> RICK Houlihan: Секогаш.

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
Значи тие се користат Динамо ДБ за ова.

1491
01:05:16,090 --> 01:05:18,131
Тие ни една удирајќи
милион барања во секунда.

1492
01:05:18,131 --> 01:05:21,120
Тие се во можност да се направи сите нивни
Lookups, тријажа сите тие податоци,

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
И тогаш тие имаат
Динамо ДБ рекорди кои

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, овие момци, што е тоа,
Овошје нинџа претпоставувам дека е нивна работа.

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
И разговаравме малку за
ова 1-1, еден на многу,

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, имаме Lookups, ние
сакате да се погледне до возачката дозвола

1566
01:08:32,779 --> 01:08:35,180
по број на социјално осигурување.

1567
01:08:35,180 --> 01:08:39,990
Сакам да се погледне до детали на корисник
со регистарски број на возачот.

1568
01:08:39,990 --> 01:08:43,620
>> Така што би можеле да имаат маса на корисникот дека
има клучна хаш на серискиот број,

1569
01:08:43,620 --> 01:08:47,830
или број на социјално осигурување, и
различни атрибути, дефиниран на ставка.

1570
01:08:47,830 --> 01:08:49,859
Сега на таа табела јас
би можеле да се дефинира дека GSI

1571
01:08:49,859 --> 01:08:53,370
завртува околу кој се вели дека сакам
клучен хаш на лиценцата, а потоа

1572
01:08:53,370 --> 01:08:54,252
сите други предмети.

1573
01:08:54,252 --> 01:08:57,210
Сега ако сакам да се пребарува и да се најде на
регистарски број за секој даден социјална

1574
01:08:57,210 --> 01:08:59,609
Број на безбедноста, што можам
анализирање на главната маса.

1575
01:08:59,609 --> 01:09:02,130
>> Ако сакам да се пребарува и сакам
за да го добиете за социјално осигурување

1576
01:09:02,130 --> 01:09:05,735
број или други атрибути од страна на
регистарски број, јас може да се пребарува на GSI.

1577
01:09:05,735 --> 01:09:08,689
Тој модел е тоа што еден
на еден однос.

1578
01:09:08,689 --> 01:09:12,460
Само еден многу едноставен GSI,
флип оние работи наоколу.

1579
01:09:12,460 --> 01:09:13,979
Сега, се зборува за една многу.

1580
01:09:13,979 --> 01:09:16,450
Еден на многу во основа
вашиот клуч хаш опсег.

1581
01:09:16,450 --> 01:09:20,510
Каде што ние се добие многу со овој
употреба случај е податок монитор.

1582
01:09:20,510 --> 01:09:23,880
Податоци монитор доаѓа во редовна
интервал, како интернет на нештата.

1583
01:09:23,880 --> 01:09:26,890
Ние секогаш ги добиете сите овие
евиденција доаѓаат во секое време.

1584
01:09:26,890 --> 01:09:31,420
>> И сакам да ги најдете сите читања
помеѓу одреден временски период.

1585
01:09:31,420 --> 01:09:34,220
Тоа е многу честа појава за пребарување во
следење на инфраструктурата.

1586
01:09:34,220 --> 01:09:38,430
Начинот на кој одите за тоа е да се најде
едноставна табела структура, една маса.

1587
01:09:38,430 --> 01:09:42,250
Имам маса мерења уред
со клуч хаш на проект на уредот.

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
Кога ќе се дефинира хаш
и опсег T табела, јас сум

1596
01:10:07,290 --> 01:10:09,240
дефинирање на еден на многу односи.

1597
01:10:09,240 --> 01:10:12,770
Тоа е односот родител-дете.

1598
01:10:12,770 --> 01:10:14,620
>> Ајде да зборуваме за многу
на многу врски.

1599
01:10:14,620 --> 01:10:19,170
И за овој конкретен пример,
повторно, ние ќе треба да се користи GSI е.

1600
01:10:19,170 --> 01:10:23,500
И ајде да зборуваме за игри
сценарио, каде што имам дадено корисник.

1601
01:10:23,500 --> 01:10:26,500
Сакам да дознаете сите игри кои
тој е регистриран за или играње во.

1602
01:10:26,500 --> 01:10:29,600
И за одредена игра, јас
сакате да ги најдете сите корисници.

1603
01:10:29,600 --> 01:10:31,010
Па, како да го направам тоа?

1604
01:10:31,010 --> 01:10:34,330
Мојата маса корисник игри, јас ќе одам
да имаат клучна хаш на корисничко ID

1605
01:10:34,330 --> 01:10:35,810
и клучен спектар на играта.

1606
01:10:35,810 --> 01:10:37,810
>> Така што корисникот може да имаат повеќе игри.

1607
01:10:37,810 --> 01:10:41,380
Тоа е еден на многу односи помеѓу
корисникот и игри свири.

1608
01:10:41,380 --> 01:10:43,410
А потоа на GSI,
Јас ќе флип дека околу.

1609
01:10:43,410 --> 01:10:46,679
Ќе хаш На играта и
Јас ќе се движат на корисникот.

1610
01:10:46,679 --> 01:10:48,970
Значи, ако јас сакам да ги добиете сите
игра на корисникот играат во,

1611
01:10:48,970 --> 01:10:49,950
Ќе се пребарува на главната маса.

1612
01:10:49,950 --> 01:10:52,699
Ако сакам да ги добијат сите корисници
кои се повеќе се игра одредена игра,

1613
01:10:52,699 --> 01:10:53,887
Јас се пребарува на GSI.

1614
01:10:53,887 --> 01:10:54,970
Па да видиме како можеме да го направите ова?

1615
01:10:54,970 --> 01:10:58,369
Да се ​​изгради овие GSI за поддршка на
употреба случај, пријавата, пристап

1616
01:10:58,369 --> 01:10:59,410
шема, апликацијата.

1617
01:10:59,410 --> 01:11:01,440
>> Ако треба да се пребарува на
оваа димензија, ајде

1618
01:11:01,440 --> 01:11:03,500
ме создаде индекс на таа димензија.

1619
01:11:03,500 --> 01:11:05,850
Ако не се направи, не ми е грижа.

1620
01:11:05,850 --> 01:11:09,060
И во зависност од употребата случај, јас
може да се стави на индекс или јас не би можеле да.

1621
01:11:09,060 --> 01:11:12,390
Ако тоа е едноставно еден на многу,
од основните маса е во ред.

1622
01:11:12,390 --> 01:11:15,860
Ако треба да се направи многу за овие
многу, или треба да се направи една до оние,

1623
01:11:15,860 --> 01:11:18,390
тогаш можеби и јас треба
до втората индексот.

1624
01:11:18,390 --> 01:11:20,840
Значи сето тоа зависи од
она што јас се обидувам да се направи

1625
01:11:20,840 --> 01:11:24,550
и она што јас се обидувам да се остварува.

1626
01:11:24,550 --> 01:11:28,000
>> Веројатно јас не одам да се трошат премногу
многу време зборуваме за документи.

1627
01:11:28,000 --> 01:11:31,460
Оваа добива малку, веројатно,
подлабоко отколку што треба да одат во.

1628
01:11:31,460 --> 01:11:33,710
Ајде да зборуваме малку
за богат израз пребарување.

1629
01:11:33,710 --> 01:11:37,831
Па во Динамо ДБ имаме
способноста да се создаде

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
на бројот или not--

1688
01:14:13,020 --> 01:14:14,316
>> [Interposing ГЛАСОВИ]

1689
01:14:14,316 --> 01:14:16,232
RICK Houlihan: Јас нема да
се премногу во ова.

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
и јас deprovision оваа табела.

1731
01:16:22,430 --> 01:16:26,440
И јас ќе го земе и RCU е
Надолу WCU бидејќи 24 часа подоцна

1732
01:16:26,440 --> 01:16:28,630
Јас не сум се работи толку многу
пребарувања против тие податоци.

1733
01:16:28,630 --> 01:16:30,200
Па јас ќе одам да се заштедат пари.

1734
01:16:30,200 --> 01:16:32,940
А можеби и 30 дена подоцна јас не
дури и треба да се грижи за тоа сите.

1735
01:16:32,940 --> 01:16:35,020
Јас би можеле да имаат WCU е
на целиот пат на еден,

1736
01:16:35,020 --> 01:16:36,990
бидејќи знаеш што, тоа е
никогаш не се случува да се запишано.

1737
01:16:36,990 --> 01:16:38,300
На податоци е 30 дена.

1738
01:16:38,300 --> 01:16:40,000
Тоа никогаш не се менува.

1739
01:16:40,000 --> 01:16:44,200
>> И тоа речиси никогаш не се случува да се чита,
па да се земе дека RCU до 10.

1740
01:16:44,200 --> 01:16:49,372
И јас сум заштеда на еден тон пари на овој
на податоци, и плаќаат само за мојата топла податоци.

1741
01:16:49,372 --> 01:16:52,330
Значи тоа е важна работа е да се погледне
во кога ќе се погледне на временски серии

1742
01:16:52,330 --> 01:16:54,716
податоци кои доаѓаат во во волумен.

1743
01:16:54,716 --> 01:16:55,590
Овие се стратегии.

1744
01:16:55,590 --> 01:16:58,010
Сега, јас само може да го дозволи
сите одат на иста маса

1745
01:16:58,010 --> 01:16:59,461
и само нека таа маса расте.

1746
01:16:59,461 --> 01:17:01,460
Конечно, јас ќе одам да
види перформанси прашања.

1747
01:17:01,460 --> 01:17:04,060
Одам да мора да почнете да ги архивираат
некои од тие податоци на маса,

1748
01:17:04,060 --> 01:17:04,720
она што не.

1749
01:17:04,720 --> 01:17:07,010
>> Ајде многу подобро
дизајнирате вашата апликација

1750
01:17:07,010 --> 01:17:08,900
така што ќе можат да работат на овој начин во право.

1751
01:17:08,900 --> 01:17:11,460
Па тоа е само автоматски
во примената код.

1752
01:17:11,460 --> 01:17:13,580
На полноќ, секоја вечер
се тркала на табелата.

1753
01:17:13,580 --> 01:17:17,170
Можеби она што ми треба е лизгачки
прозорец на 24 часа на податоци.

1754
01:17:17,170 --> 01:17:20,277
Потоа на редовна основа, јас сум
повикува на податоци на маса.

1755
01:17:20,277 --> 01:17:22,360
Јас сум го кастри со
Закажана задача и јас сум со тоа ставање

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
Знаете, Твитер за
пример, топла чуруликам.

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
Добив 70.000 барања по
второто доаѓање на производ

1770
01:17:57,277 --> 01:17:58,860
опис од мојот производ каталог.

1771
01:17:58,860 --> 01:18:02,384
Го гледаме ова на мало
операција доста.

1772
01:18:02,384 --> 01:18:03,550
Па, како да се справи со тоа?

1773
01:18:03,550 --> 01:18:04,924
Не постои начин да се справи со тоа.

1774
01:18:04,924 --> 01:18:07,110
Сите мои корисниците сакаат да се види
исто парче на податоци.

1775
01:18:07,110 --> 01:18:09,410
Тие доаѓаат во, истовремено.

1776
01:18:09,410 --> 01:18:11,920
И сите тие се прави барања
за истиот парче на податоци.

1777
01:18:11,920 --> 01:18:16,240
Ова ми дава дека топла клуч, дека големо црвено
лента на мојот шема што не ни се допаѓа.

1778
01:18:16,240 --> 01:18:17,720
И тоа е она што изгледа како тоа.

1779
01:18:17,720 --> 01:18:22,290
Па низ клучните мојот простор јас сум добивање на
зачукуваше во точките на продажба.

1780
01:18:22,290 --> 01:18:24,070
Јас сум добивање на ништо друго место.

1781
01:18:24,070 --> 01:18:26,050
>> Како можам да се ублажи овој проблем?

1782
01:18:26,050 --> 01:18:28,410
Па, ние го ублажи овој со кеш.

1783
01:18:28,410 --> 01:18:33,630
Кеш, се стави во основа на во-меморија
партиција во предниот дел на базата на податоци.

1784
01:18:33,630 --> 01:18:37,260
Успеавме
[Беззвучен] кеш, како може

1785
01:18:37,260 --> 01:18:40,260
може да се постави свој кеш, [Беззвучен]
кеш [? г,?] она што сакате.

1786
01:18:40,260 --> 01:18:42,220
Стави дека во предниот дел на базата на податоци.

1787
01:18:42,220 --> 01:18:47,250
И на тој начин може да се сместат тие податоци
од оние жешки копчиња во кои кешот

1788
01:18:47,250 --> 01:18:49,390
простор и се чита преку кешот.

1789
01:18:49,390 --> 01:18:51,962
>> И потоа поголемиот дел од вашето чита
почнете да барате се допаѓа ова.

1790
01:18:51,962 --> 01:18:54,920
Добив сите овие кеш хитови се тука
и јас се ништо случува овде

1791
01:18:54,920 --> 01:18:59,330
бидејќи базата на податоци се седи зад
кеш и никогаш не се чита дојде преку.

1792
01:18:59,330 --> 01:19:02,520
Ако се менува податоците во
база на податоци, треба да се ажурира на кешот.

1793
01:19:02,520 --> 01:19:04,360
Можеме да го користите нешто
пареи како да го направите тоа.

1794
01:19:04,360 --> 01:19:07,360
И јас ќе ви објасниме како тоа работи.

1795
01:19:07,360 --> 01:19:09,060
Сите права, размена на пораки.

1796
01:19:09,060 --> 01:19:11,180
Е-пошта, сите ние се користи е-мејл.

1797
01:19:11,180 --> 01:19:12,540
>> Ова е прилично добар пример.

1798
01:19:12,540 --> 01:19:14,950
Имаме некој вид на пораки табелата.

1799
01:19:14,950 --> 01:19:17,040
И добивме и излезното сандаче.

1800
01:19:17,040 --> 01:19:19,760
Тоа е она што на SQL би
изгледаат како да се изгради дека сандаче.

1801
01:19:19,760 --> 01:19:23,350
Ние вид на се користи истиот вид
на стратегија за користење на GSI е, GSI е

1802
01:19:23,350 --> 01:19:25,320
за моето сандаче и моите излезното сандаче.

1803
01:19:25,320 --> 01:19:27,600
Па добив суровини пораки што доаѓаат
во мојата маса пораки.

1804
01:19:27,600 --> 01:19:30,194
И првиот пристап кон ова
би можело да биде, да речеме, во ред, нема проблем.

1805
01:19:30,194 --> 01:19:31,110
Јас имам суровини пораки.

1806
01:19:31,110 --> 01:19:33,710
Пораки што доаѓаат [Беззвучен],
id пораката, тоа е одлично.

1807
01:19:33,710 --> 01:19:35,070
Тоа е мојата единствена хаш.

1808
01:19:35,070 --> 01:19:38,280
Одам да се создаде две GSI, еден
за моето сандаче, една за мојата излезното сандаче.

1809
01:19:38,280 --> 01:19:40,530
И првото нешто што јас ќе сторам
се ќе кажам мојот клучните хаш е

1810
01:19:40,530 --> 01:19:43,310
ќе биде примачот и
Одам да се организираме на денот.

1811
01:19:43,310 --> 01:19:44,220
Ова е фантастично.

1812
01:19:44,220 --> 01:19:45,890
Добив убаво моето мислење тука.

1813
01:19:45,890 --> 01:19:47,780
Но, има малку проблем тука.

1814
01:19:47,780 --> 01:19:50,891
И ќе наиде на ова во
релациони бази на податоци, како и.

1815
01:19:50,891 --> 01:19:52,390
Тие повикаа вертикално партиционирање.

1816
01:19:52,390 --> 01:19:55,840
Сакате да го задржите вашиот големи податоци
далеку од вашиот малку податоци.

1817
01:19:55,840 --> 01:20:00,470
>> И причината зошто е затоа што морам
одат прочитате на предмети за да се добие атрибути.

1818
01:20:00,470 --> 01:20:05,570
И ако ми се сите тела за тука,
потоа читање само неколку елементи

1819
01:20:05,570 --> 01:20:08,560
ако должината моето тело е
просек од 256 килобајти, секој,

1820
01:20:08,560 --> 01:20:10,991
математика добива прилично грда.

1821
01:20:10,991 --> 01:20:12,490
Така велат дека сакам да ја прочитам Давид сандаче.

1822
01:20:12,490 --> 01:20:14,520
Давид сандаче има 50 предмети.

1823
01:20:14,520 --> 01:20:17,880
Просечната и големина е 256 килобајти.

1824
01:20:17,880 --> 01:20:21,730
Еве го мојот конверзија сооднос
за RCU е четири килобајти.

1825
01:20:21,730 --> 01:20:24,450
>> Добро, ајде да одиме со
на крај доследни чита.

1826
01:20:24,450 --> 01:20:28,640
Јас сум се уште јадат 1600 RCU е
само да го прочитате на Давид сандаче.

1827
01:20:28,640 --> 01:20:29,950
Уф.

1828
01:20:29,950 --> 01:20:31,980
Добро, сега ајде да размислиме
за тоа како функционира апликацијата.

1829
01:20:31,980 --> 01:20:35,340
Ако сум во е-маил апликацијата и
Го барам во моето сандаче,

1830
01:20:35,340 --> 01:20:39,680
и гледам во телото на секоја порака,
Не, јас сум во потрага на резимеа.

1831
01:20:39,680 --> 01:20:41,850
Јас сум во потрага по само заглавија.

1832
01:20:41,850 --> 01:20:46,310
Значи, да се изгради маса структура
што повеќе наликува тоа.

1833
01:20:46,310 --> 01:20:49,470
>> Значи тука е информации
дека мојот работното потреби.

1834
01:20:49,470 --> 01:20:50,890
Тоа е во моето сандаче GSI.

1835
01:20:50,890 --> 01:20:53,800
Тоа е датумот, на испраќачот,
предмет, а потоа

1836
01:20:53,800 --> 01:20:56,790
Проект на пораката, што укажува
назад на табелата со пораки

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
Тие ќе точка назад кон
ставка лични карти на масата во Динамо ДБ.

1841
01:21:09,850 --> 01:21:12,220
Секој индекс секогаш creates--
секогаш има елемент

1842
01:21:12,220 --> 01:21:15,750
Проект, како дел of-- дека
доаѓа со индексот.

1843
01:21:15,750 --> 01:21:17,414
>> Во ред.

1844
01:21:17,414 --> 01:21:19,080
ПУБЛИКАТА: Тоа го кажува каде што се чуваат?

1845
01:21:19,080 --> 01:21:21,420
RICK Houlihan: Да, тоа кажува
exactly-- тоа е токму она што го прави.

1846
01:21:21,420 --> 01:21:22,644
Таа вели дека ова е мојата повторно рекорд.

1847
01:21:22,644 --> 01:21:24,310
И тоа ќе го истакне вратам на мојот повторно рекорд.

1848
01:21:24,310 --> 01:21:26,460
Токму така.

1849
01:21:26,460 --> 01:21:29,490
Добро, па сега е моето сандаче
всушност многу помал.

1850
01:21:29,490 --> 01:21:32,210
И ова всушност поддржува
на работното на е-маил апликација.

1851
01:21:32,210 --> 01:21:34,230
Значи моето сандаче, јас кликнете.

1852
01:21:34,230 --> 01:21:38,160
Да одам заедно и ќе кликнете на пораката,
тоа е моментот кога јас треба да одам да купам телото,

1853
01:21:38,160 --> 01:21:40,180
затоа што ќе одам да се
одат на поинаков став.

1854
01:21:40,180 --> 01:21:43,870
Значи, ако мислите дека за видот на MVC
рамка, модел погледнете контролорот.

1855
01:21:43,870 --> 01:21:46,120
>> Моделот содржи
податоци кои треба погледот

1856
01:21:46,120 --> 01:21:48,130
и контролорот се поврзува со.

1857
01:21:48,130 --> 01:21:51,670
Кога ќе се промени на рамката, кога
Сменам перспектива,

1858
01:21:51,670 --> 01:21:55,080
тоа е во ред да се вратиме на
сервер и населат на моделот,

1859
01:21:55,080 --> 01:21:56,860
затоа што тоа е она што корисникот очекува.

1860
01:21:56,860 --> 01:22:00,530
Кога го менуваат ставови, тоа е кога
ние може да се врати во базата на податоци.

1861
01:22:00,530 --> 01:22:02,480
Толку е-маил, кликнете.

1862
01:22:02,480 --> 01:22:03,710
Јас сум во потрага по телото.

1863
01:22:03,710 --> 01:22:04,330
Двупосочен.

1864
01:22:04,330 --> 01:22:05,680
Одам да купам телото.

1865
01:22:05,680 --> 01:22:06,950
>> Читам многу помалку податоци.

1866
01:22:06,950 --> 01:22:09,960
Јас сум само читање на тела кои
Давид му треба кога тој има потреба од нив.

1867
01:22:09,960 --> 01:22:14,230
И не ми изгори во 1600 година
RCU е само да ја покаже својата сандаче.

1868
01:22:14,230 --> 01:22:17,670
Па сега that-- ова е начинот на
дека LSI или GSI-- Жал ми е,

1869
01:22:17,670 --> 01:22:19,900
GSI, ќе работат надвор.

1870
01:22:19,900 --> 01:22:25,450
Добивме наша хаш на примачот.

1871
01:22:25,450 --> 01:22:27,030
Имаме клучот спектар на денот.

1872
01:22:27,030 --> 01:22:31,380
И ние го добивме проектираниот атрибути
дека ние треба само да го поддржи ставот.

1873
01:22:31,380 --> 01:22:34,300
>> Ние ротираат дека за излезното сандаче.

1874
01:22:34,300 --> 01:22:35,770
Постигнување на испраќачот.

1875
01:22:35,770 --> 01:22:39,612
И во суштина, имаме
на многу убав, чист поглед.

1876
01:22:39,612 --> 01:22:41,570
И тоа е basically-- ние
имаат оваа убава пораки

1877
01:22:41,570 --> 01:22:45,870
маса и тоа е се шири убаво бидејќи
тоа е само хаш, hashed порака проект.

1878
01:22:45,870 --> 01:22:51,750
И имаме две индекси кои
ротираат исклучување на табелата.

1879
01:22:51,750 --> 01:22:57,411
Добро, па Идејата тука е не
задржи големи податоци и овој мал податоци

1880
01:22:57,411 --> 01:22:57,910
заедно.

1881
01:22:57,910 --> 01:23:00,700
Поделба вертикално,
партиција оние маси.

1882
01:23:00,700 --> 01:23:03,150
Не читаат податоци што не мора да се.

1883
01:23:03,150 --> 01:23:04,850
Добро, играњето на игри.

1884
01:23:04,850 --> 01:23:06,990
Сите ние сакале игри.

1885
01:23:06,990 --> 01:23:10,902
Барем ми се допаѓа игри тогаш.

1886
01:23:10,902 --> 01:23:12,735
Па некои од работите
дека ние се справи со кога

1887
01:23:12,735 --> 01:23:14,193
ние сме размислување за игри, нели?

1888
01:23:14,193 --> 01:23:16,999
Игри на среќа, овие денови, особено мобилни
игри, е за размислување.

1889
01:23:16,999 --> 01:23:19,540
А јас ќе одам да ги ротира тука
малку подалеку од DynamoDB.

1890
01:23:19,540 --> 01:23:21,373
Одам да се донесе во
некои од дискусија

1891
01:23:21,373 --> 01:23:24,240
околу некои од
други технологии AWS.

1892
01:23:24,240 --> 01:23:28,930
>> Но, идејата за игри е да се мисли
за во однос на API-јата, API-јата, кои се,

1893
01:23:28,930 --> 01:23:31,730
општо земено, HTTP и JSON.

1894
01:23:31,730 --> 01:23:34,550
Тоа е начинот на мобилни игри вид на
комуницирате со нивните краеви назад.

1895
01:23:34,550 --> 01:23:35,850
Тие го прават JSON која испраќаш мислења.

1896
01:23:35,850 --> 01:23:40,660
Тие се на податоци, и тоа е за сите,
општо земено, во убаво JSON API-јата.

1897
01:23:40,660 --> 01:23:44,950
>> Работите како се пријатели, се
податоци на табла, размена,

1898
01:23:44,950 --> 01:23:47,699
кориснички генерирани содржини,
притисни назад до системот,

1899
01:23:47,699 --> 01:23:49,740
овие се видови на нештата
дека ние ќе треба да се направи.

1900
01:23:49,740 --> 01:23:52,542
Бинарни податоци со средства, овие податоци
не може да седат во базата на податоци.

1901
01:23:52,542 --> 01:23:54,250
Ова може да седат во една
објект продавница, нели?

1902
01:23:54,250 --> 01:23:56,541
Но, за базата на податоци се случува да се
завршат кажувам системот,

1903
01:23:56,541 --> 01:23:59,140
кажување на примена
каде да одам да го добие.

1904
01:23:59,140 --> 01:24:03,550
И неизбежно, мултиплеер
сервери, задниот крај на инфраструктурата,

1905
01:24:03,550 --> 01:24:06,180
и дизајниран за високо
достапност и приспособливост.

1906
01:24:06,180 --> 01:24:09,400
Значи овие се нештата што сите ние сакаме
во гејминг инфраструктура денес.

1907
01:24:09,400 --> 01:24:12,160
>> Па ајде да ги разгледаме во
што личи тоа.

1908
01:24:12,160 --> 01:24:16,070
Доби основни задниот крај,
многу јасна.

1909
01:24:16,070 --> 01:24:19,880
Имаме систем тука со
повеќе Достапност зони.

1910
01:24:19,880 --> 01:24:23,780
Ние разговаравме за тоа како AZS being-- размислуваат
од нив како посебни центри за податоци.

1911
01:24:23,780 --> 01:24:26,040
Центарот повеќе податоци
по АЗ, но тоа е во ред,

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
Ние ќе треба да имаат
некои назад end серверот.

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
како тие почнуваат да се busier
и busier и busier,

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
Па можете да имате n број на сервери
таму во било кое дадено време.

1952
01:26:08,110 --> 01:26:11,870
И ако вашиот товар оди, тие ќе
се намалува, бројот ќе се намали.

1953
01:26:11,870 --> 01:26:15,250
И кога товарот се враќа,
тоа ќе расте назад надвор, еластично.

1954
01:26:15,250 --> 01:26:17,050
>> Па ова изгледа одлично.

1955
01:26:17,050 --> 01:26:19,800
Имаме голем број на EC2 инстанци.

1956
01:26:19,800 --> 01:26:21,671
Ние може да се стави во кеш
предниот дел на бази на податоци,

1957
01:26:21,671 --> 01:26:23,045
се обиде и да се забрза со бази на податоци.

1958
01:26:23,045 --> 01:26:25,030
Следната точка на притисок
обично луѓето гледаат

1959
01:26:25,030 --> 01:26:28,850
е тие да скала на играта со помош на
релациона база на податоци систем.

1960
01:26:28,850 --> 01:26:30,790
Jeez, за базата на податоци
перформанси е страшно.

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
Имате трансакциска ограничувања
кои не span партиции.

1981
01:27:18,670 --> 01:27:20,560
Имаш сите видови на
неред дека сте

1982
01:27:20,560 --> 01:27:23,040
кои се занимаваат со, таму долу, во обид
да се справи со скалирање надвор

1983
01:27:23,040 --> 01:27:25,120
и градење на поголема инфраструктура.

1984
01:27:25,120 --> 01:27:27,284
Тоа е само не е забавно.

1985
01:27:27,284 --> 01:27:30,930
>> ПУБЛИКАТА: Значи сакаш да кажеш дека
растечки извор поени забрзува

1986
01:27:30,930 --> 01:27:31,430
процесот?

1987
01:27:31,430 --> 01:27:32,513
RICK Houlihan: Зголемување?

1988
01:27:32,513 --> 01:27:33,520
ПУБЛИКАТА: Извор поени.

1989
01:27:33,520 --> 01:27:34,410
RICK Houlihan: Извор поени?

1990
01:27:34,410 --> 01:27:37,500
ПУБЛИКАТА: Од информациите,
каде што информацијата е што доаѓаат од?

1991
01:27:37,500 --> 01:27:38,250
RICK Houlihan: Не

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
Па, ако се потребни на корисникот
Тоа е на M, јас ќе одам тука.

1996
01:27:50,780 --> 01:27:53,560
Од N во p, јас ќе одам тука.

1997
01:27:53,560 --> 01:27:55,060
Од P до Ш, јас ќе одам тука.

1998
01:27:55,060 --> 01:27:57,120
>> ПУБЛИКАТА: Во ред, така што оние се оние
сите складирани во различни јазли?

1999
01:27:57,120 --> 01:27:57,911
>> RICK Houlihan: Да.

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
Ние би можеле да се hashing на корисничка идентификација,
а потоа имаме спектар на играта.

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--
за да можам да се добијат овие лични leaderboards.

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
Кога мојот рекорд е hashed на
со userid, се движи на игра,

2029
01:29:18,070 --> 01:29:20,740
и јас ќе одам да се оди напред
и да се преструктуира, да креирате GSI,

2030
01:29:20,740 --> 01:29:22,370
а јас ќе одам да се преструктурира тие податоци.

2031
01:29:22,370 --> 01:29:27,310
>> Сега ќе одам да хаш На
BoardName, што е играта.

2032
01:29:27,310 --> 01:29:29,800
А јас ќе одам да се движат на врвот резултат.

2033
01:29:29,800 --> 01:29:31,540
И сега сум создадена различни кофи.

2034
01:29:31,540 --> 01:29:34,790
Јас сум со користење на иста маса,
истите податоци објект.

2035
01:29:34,790 --> 01:29:39,870
Но, јас сум создавање кофа која дава
ме агрегација на врвот резултат од игра.

2036
01:29:39,870 --> 01:29:43,180
>> И јас може да се пребарува таа маса
да се добие таа информација.

2037
01:29:43,180 --> 01:29:50,890
Па јас го поставите тој образец барањето до
биде поддржана од средно индекс.

2038
01:29:50,890 --> 01:29:54,556
Сега тие можат да бидат подредени по BoardName
и сортирани по TopScore зависност.

2039
01:29:54,556 --> 01:29:57,180
За да можете да видите, ова се видови
на употреба случаи ќе го добиете во игри.

2040
01:29:57,180 --> 01:30:02,190
Друга добра употреба случај ќе го добиеме во игри
е награди и кој ја освои наградата.

2041
01:30:02,190 --> 01:30:05,340
И ова е одлична употреба случај
каде што ние го нарекуваме редок индекси.

2042
01:30:05,340 --> 01:30:07,340
Редок индекси се
способност да се генерира

2043
01:30:07,340 --> 01:30:10,850
индекс, кој не мора да
содржи секоја точка на маса.

2044
01:30:10,850 --> 01:30:11,470
И зошто не?

2045
01:30:11,470 --> 01:30:14,540
Бидејќи атрибут и тоа е се
индексирани не постои на секој елемент.

2046
01:30:14,540 --> 01:30:16,460
>> Значи во овој конкретен
користете случај, сакам да кажам дека,

2047
01:30:16,460 --> 01:30:19,240
знаеш што, јас ќе одам да
создаде атрибут наречен награда.

2048
01:30:19,240 --> 01:30:22,970
А јас ќе одам да им даде на секој корисник
кој има награда која атрибут.

2049
01:30:22,970 --> 01:30:25,950
Корисниците кои немаат награди се
нема да има кој атрибут.

2050
01:30:25,950 --> 01:30:27,800
Па кога ќе се создаде
индекс, само корисници

2051
01:30:27,800 --> 01:30:28,960
кој се случува да се покаже
во индексот се

2052
01:30:28,960 --> 01:30:31,050
оние кои, всушност, имаат освоено награди.

2053
01:30:31,050 --> 01:30:34,440
Значи, тоа е одличен начин да се биде во можност
да се создаде филтрирани индекси кои

2054
01:30:34,440 --> 01:30:40,580
се многу, многу селективна кои не се
мора да индекс на целата маса.

2055
01:30:40,580 --> 01:30:43,050
>> Значи, ние сме добивање на ниско на време тука.

2056
01:30:43,050 --> 01:30:49,190
Одам да се оди напред и да го прескокнете
излезе и да го прескокнете овој случај.

2057
01:30:49,190 --> 01:30:52,625
Зборува малку about--

2058
01:30:52,625 --> 01:30:54,460
>> ПУБЛИКАТА: Може ли да прашам едно кратко прашање?

2059
01:30:54,460 --> 01:30:56,722
Една од нив е да напише тешки?

2060
01:30:56,722 --> 01:30:57,680
RICK Houlihan: Што е тоа?

2061
01:30:57,680 --> 01:30:58,596
ПУБЛИКАТА: Напиши тешки.

2062
01:30:58,596 --> 01:31:01,270
RICK Houlihan: Напиши тешки.

2063
01:31:01,270 --> 01:31:03,460
Дај да видам.

2064
01:31:03,460 --> 01:31:06,220
>> ПУБЛИКАТА: Или е тоа што не
нешто може да се само

2065
01:31:06,220 --> 01:31:08,809
глас во прашање на секунди?

2066
01:31:08,809 --> 01:31:10,850
RICK Houlihan: Ние одиме
преку сценарио на гласање.

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 и 1.000,
или меѓу еден и 1.000,

2109
01:32:56,620 --> 01:32:59,940
меѓутоа многу случајни вредности што сакате да го
додавај кон крајот на тој кандидат.

2110
01:32:59,940 --> 01:33:01,330
>> И она што сум навистина направи тогаш?

2111
01:33:01,330 --> 01:33:05,830
Ако јас сум со користење на проект како кандидат
кофата агрегат гласови,

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
Јас сум тоа tacking кон крајот на
Кандидатот на тоа лице да гласаат за.

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
Кандидат за сега има
Вкупниот пребројувањето на x.

2130
01:33:53,830 --> 01:33:55,690
>> Сега и запишување
пребарување и пребарување на читање

2131
01:33:55,690 --> 01:33:58,160
се убаво дистрибуирани
затоа што јас пишувам низ

2132
01:33:58,160 --> 01:34:00,320
и го читам на стотина клучеви.

2133
01:34:00,320 --> 01:34:03,500
Јас не пишувам и
читање преку еден клуч.

2134
01:34:03,500 --> 01:34:04,950
Па тоа е одлична шема.

2135
01:34:04,950 --> 01:34:08,090
>> Ова е, всушност, веројатно, еден
од најважните дизајн

2136
01:34:08,090 --> 01:34:10,420
шеми за обем во NoSQL.

2137
01:34:10,420 --> 01:34:14,470
Ќе го видите овој тип на
дизајн шема во секој вкус.

2138
01:34:14,470 --> 01:34:19,100
MongoDB, DynamoDB, тоа не го прави тоа
прашање, сите ние треба да го направите тоа.

2139
01:34:19,100 --> 01:34:21,840
Бидејќи кога си имаш работа
со оние огромни колонии,

2140
01:34:21,840 --> 01:34:26,650
ќе мора да дознаам начин да се
ги шират низ кофи.

2141
01:34:26,650 --> 01:34:29,512
Така што ова е начинот на кој ќе го направите тоа.

2142
01:34:29,512 --> 01:34:31,220
Добро, така што
што го прави во моментов

2143
01:34:31,220 --> 01:34:35,252
е ти си на тргување надвор прочитани
трошоците за запишување приспособливост.

2144
01:34:35,252 --> 01:34:37,085
Цената на мојот прочитате е
малку посложен

2145
01:34:37,085 --> 01:34:40,220
и морам да одам читаат од
сто корпи наместо една.

2146
01:34:40,220 --> 01:34:41,310
Но, јас сум во можност да пишувам.

2147
01:34:41,310 --> 01:34:44,860
И мојот автопат, моето пишување
пропусната моќ е неверојатна.

2148
01:34:44,860 --> 01:34:49,450
Па тоа обично е важна
техника за скалирање DynamoDB,

2149
01:34:49,450 --> 01:34:51,350
или било која база на податоци NoSQL за тоа прашање.

2150
01:34:51,350 --> 01:34:53,824

2151
01:34:53,824 --> 01:34:55,240
Па ние сфатиле како да ја скала.

2152
01:34:55,240 --> 01:34:56,930
И ние сфатиле како да се
елиминирање на нашата топла клучеви.

2153
01:34:56,930 --> 01:34:57,820
И тоа е фантастично.

2154
01:34:57,820 --> 01:34:58,960
И добивме овој убав систем.

2155
01:34:58,960 --> 01:35:02,043
И тоа е ни даде многу коректен гласање
бидејќи имаме рекорд гласање де-будала.

2156
01:35:02,043 --> 01:35:03,130
Тоа е вградено во DynamoDB.

2157
01:35:03,130 --> 01:35:05,380
Ние разговаравме за условен права.

2158
01:35:05,380 --> 01:35:08,170
>> Кога еден гласач влегува внатре, го става
додатокот на маса,

2159
01:35:08,170 --> 01:35:11,220
тие вметнете со своите гласачите проект,
ако тие се обидуваат да се вметне уште еден глас,

2160
01:35:11,220 --> 01:35:13,320
Правам условно запишување.

2161
01:35:13,320 --> 01:35:16,960
Велат дека само ја напишам оваа
ако ова не постои.

2162
01:35:16,960 --> 01:35:19,270
Па штом ќе видам дека
тоа гласање хит на маса,

2163
01:35:19,270 --> 01:35:20,460
никој друг не ќе биде
можност да се стави на гласање во.

2164
01:35:20,460 --> 01:35:21,634
И тоа е фантастично.

2165
01:35:21,634 --> 01:35:23,550
И ние ја зголемува
нашиот кандидат шалтери.

2166
01:35:23,550 --> 01:35:25,466
И ние сме прави нашето
демографијата и сето тоа.

2167
01:35:25,466 --> 01:35:29,110
Но, она што се случува ако ми
апликација паѓа во текот?

2168
01:35:29,110 --> 01:35:31,350
Сега одеднаш гласови
доаѓаат во, и јас

2169
01:35:31,350 --> 01:35:34,840
не знам дали тие се добива преработени
во мојата анализа и демографијата

2170
01:35:34,840 --> 01:35:36,040
веќе.

2171
01:35:36,040 --> 01:35:38,462
И кога апликацијата
се враќа нагоре, како

2172
01:35:38,462 --> 01:35:41,420
по ѓаволите, да знам што има гласови
обработени и каде да почнам?

2173
01:35:41,420 --> 01:35:44,530
>> Па ова е вистински проблем кога ќе се
да почне да се погледне на овој вид на сценарио.

2174
01:35:44,530 --> 01:35:45,571
И како да се реши тоа?

2175
01:35:45,571 --> 01:35:48,070
Ние тоа го реши со тоа што го
јавете DynamoDB струи.

2176
01:35:48,070 --> 01:35:53,470
Потоци е наредено време и
поделен најавите промена на секој пристап

2177
01:35:53,470 --> 01:35:55,700
на маса, секој се пишува
пристап до табелата.

2178
01:35:55,700 --> 01:35:58,810
Сите податоци кои се напишани на
табелата се појавува на потокот.

2179
01:35:58,810 --> 01:36:01,815
>> Тоа е во основа 24 часа чекање.

2180
01:36:01,815 --> 01:36:03,690
Предмети хит на поток,
тие живеат за 24 часа.

2181
01:36:03,690 --> 01:36:05,990
Тие може да се прочита повеќе пати.

2182
01:36:05,990 --> 01:36:09,400
Гарантирано да бидат испорачани
само еднаш да се поток,

2183
01:36:09,400 --> 01:36:11,180
може да се чита n број на пати.

2184
01:36:11,180 --> 01:36:14,910
Па сепак многу процеси што сакате да го
консумираат тие податоци, можете да го консумираат.

2185
01:36:14,910 --> 01:36:16,350
Таа ќе се појави секој ажурирање.

2186
01:36:16,350 --> 01:36:18,455
Секој пишуваат само ќе
се појавуваат еднаш на потокот.

2187
01:36:18,455 --> 01:36:20,621
Значи, вие не мора да се грижите
за обработка на неа двапати

2188
01:36:20,621 --> 01:36:22,500
од истиот процес.

2189
01:36:22,500 --> 01:36:25,350
>> Тоа е строго нареди по ставка.

2190
01:36:25,350 --> 01:36:28,180
Кога велиме време
нареди и поделен,

2191
01:36:28,180 --> 01:36:30,680
ќе видите една партиција на потокот.

2192
01:36:30,680 --> 01:36:33,169
Ќе видите предмети, новости во ред.

2193
01:36:33,169 --> 01:36:35,210
Ние не се гарантираат
на реката што сте

2194
01:36:35,210 --> 01:36:40,240
случува да се добие секоја трансакција
во редот низ предмети.

2195
01:36:40,240 --> 01:36:42,440
>> Па потоци се idempotent.

2196
01:36:42,440 --> 01:36:44,037
Дали сите ние знаеме што значи idempotent?

2197
01:36:44,037 --> 01:36:46,620
Idempotent значи дека може да го направи тоа
над, и одново и одново.

2198
01:36:46,620 --> 01:36:48,200
Резултатот ќе биде ист.

2199
01:36:48,200 --> 01:36:49,991
>> Потоци се idempotent,
но тие мора да бидат

2200
01:36:49,991 --> 01:36:54,860
игра од почетна точка,
каде и да одберете, за да на крајот,

2201
01:36:54,860 --> 01:36:57,950
или пак тие не ќе резултира
во исти вредности.

2202
01:36:57,950 --> 01:36:59,727
>> Истото со MongoDB.

2203
01:36:59,727 --> 01:37:01,560
MongoDB има конструкт
тие го нарекуваат oplog.

2204
01:37:01,560 --> 01:37:04,140
Тоа е истата конструкција.

2205
01:37:04,140 --> 01:37:06,500
Многу NoSQL бази на податоци
имаат оваа конструкција.

2206
01:37:06,500 --> 01:37:08,790
Тие го користат за да се прават работите
како репликација, која

2207
01:37:08,790 --> 01:37:10,475
е токму она што го правиме со потоци.

2208
01:37:10,475 --> 01:37:12,350
ПУБЛИКАТА: Можеби
еретичкото прашање, но

2209
01:37:12,350 --> 01:37:13,975
зборува за апликации прави надолу така натаму.

2210
01:37:13,975 --> 01:37:16,089
Потоци се загарантирани за да
никогаш не можел да тргне надолу?

2211
01:37:16,089 --> 01:37:18,630
RICK Houlihan: Да, потоци
се загарантирани за да никогаш не се оди надолу.

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
Кинеза е проток на податоци,
технологија на обработка од Амазон.

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
На Kinesis клиент библиотека, всушност,
управува со работниците за вас.

2259
01:39:28,752 --> 01:39:30,460
И тоа, исто така, не некои
интересни работи.

2260
01:39:30,460 --> 01:39:35,630
Тоа ќе се создаде некои табели нагоре
во вашиот DynamoDB tablespace

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 струи може да биде
обработени од страна на она што го нарекуваме Ламбда.

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
Ако рекорд појавува на поток,
ние ќе го наречеме оваа функција Јава.

2301
01:41:39,100 --> 01:41:44,980
Па, ова е JavaScript, и Ламбда
поддржува Node.js, Јава, 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
пишуваат во Јава, можете дефинирате класата.

2305
01:41:53,610 --> 01:41:55,690
Ќе им помогнам на МК JAR до во Ламбда.

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
Тие се читаат од страна на функцијата Ламбда.

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
Па тоа е многу
она што го правиме со Ламбда.

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
Тоа е мора да вклучите комплекс
дека тоа е водење.

2383
01:45:30,160 --> 01:45:33,557
Па тоа е многу богата апликација
трчање во прелистувачот на клиентот.

2384
01:45:33,557 --> 01:45:36,390
Тие не знаат дека тие не се
интеракција со back-end серверот.

2385
01:45:36,390 --> 01:45:38,220
Во овој момент, тоа е за сите пребарувач.

2386
01:45:38,220 --> 01:45:41,780
>> Тие ги објави резултатите за тоа што
ние го нарекуваме Амазон API Портал.

2387
01:45:41,780 --> 01:45:46,270
API Портал е едноставно веб API
дека може да се дефинира и да се поврземе

2388
01:45:46,270 --> 01:45:47,760
онака како што сакате.

2389
01:45:47,760 --> 01:45:50,990
Во конкретниов случај, ние сме
закопчан до Ламбда функции.

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
енкрипција и клуч за управување на Амазон

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
Тоа е само кодот што седи на Ламбда.

2428
01:47:35,660 --> 01:47:38,560
Тоа е само податоци кој седи во DynamoDB.

2429
01:47:38,560 --> 01:47:41,340
Тоа е неверојатен начин
да се изгради апликации.

2430
01:47:41,340 --> 01:47:43,970
>> ПУБЛИКАТА: Значи тоа е повеќе
ефемерни отколку што ќе биде

2431
01:47:43,970 --> 01:47:45,740
ако тоа беше се чуваат на вистински сервер?

2432
01:47:45,740 --> 01:47:46,823
>> RICK Houlihan: Апсолутно.

2433
01:47:46,823 --> 01:47:49,190
Бидејќи тој сервер пример
ќе мора да биде 7/24.

2434
01:47:49,190 --> 01:47:51,954
Таа треба да биде на располагање за
некој да се одговори.

2435
01:47:51,954 --> 01:47:52,620
И погоди што?

2436
01:47:52,620 --> 01:47:55,410
S3 е достапен 7/24.

2437
01:47:55,410 --> 01:47:57,100
S3 секогаш одговара.

2438
01:47:57,100 --> 01:47:59,320
И S3 е многу, многу добар
во служејќи се објектите.

2439
01:47:59,320 --> 01:48:02,590
Тие предмети може да е HTML датотеки, или
Го вклучите Javascript-датотеки, или што и да сакате.

2440
01:48:02,590 --> 01:48:07,430
Можете да го извршите многу богати веб апликации
од S3 кофи, и луѓето го прават.

2441
01:48:07,430 --> 01:48:10,160
>> И така тоа е идејата тука
е да се извлечеш од патот

2442
01:48:10,160 --> 01:48:11,270
ние се користат да се размислува за тоа.

2443
01:48:11,270 --> 01:48:14,270
Сите ние се користат да се мисли во
однос на сервери и домаќините.

2444
01:48:14,270 --> 01:48:16,580
Тоа не е за тоа повеќе.

2445
01:48:16,580 --> 01:48:19,310
Се работи за инфраструктура како код.

2446
01:48:19,310 --> 01:48:22,470
Распоредување на код за да се облака и
нека облак го кандидира за вас.

2447
01:48:22,470 --> 01:48:24,980
И тоа е она AWS се обидува да го направи тоа.

2448
01:48:24,980 --> 01:48:29,690
>> ПУБЛИКАТА: Значи вашиот злато кутија во средината
на API Портал не е сервер-како,

2449
01:48:29,690 --> 01:48:30,576
но наместо тоа е just--

2450
01:48:30,576 --> 01:48:32,850
>> RICK Houlihan: Можете да мислите
тоа што на серверот фасада.

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
>> RICK Houlihan: О, idempotent?

2471
01:49:10,480 --> 01:49:11,800
Како ќе се менува на вредности?

2472
01:49:11,800 --> 01:49:15,180
Па, затоа што ако јас не се кандидира
тоа сè до крајот,

2473
01:49:15,180 --> 01:49:19,770
тогаш јас не знам што се менува
се направени во последната милја.

2474
01:49:19,770 --> 01:49:22,144
Тоа нема да биде
истите податоци како она што го видов.

2475
01:49:22,144 --> 01:49:24,560
ПУБЛИКАТА: О, па вие само
не добиле целиот влез.

2476
01:49:24,560 --> 01:49:24,770
RICK Houlihan: Добро.

2477
01:49:24,770 --> 01:49:26,895
Мора да се оди од почеток
до крајот, а потоа тоа е

2478
01:49:26,895 --> 01:49:29,280
ќе биде конзистентна држава.

2479
01:49:29,280 --> 01:49:31,520
Кул.

2480
01:49:31,520 --> 01:49:35,907
>> ПУБЛИКАТА: Па ти ни покажа DynamoDB
може да се направи документ или вредноста на клучот.

2481
01:49:35,907 --> 01:49:38,740
И си поминале многу време на
клучните вредност со хаш и начините

2482
01:49:38,740 --> 01:49:40,005
да го флип наоколу.

2483
01:49:40,005 --> 01:49:43,255
Кога ќе ги гледа тие маси, е во тоа што
оставајќи го зад себе пристап документ?

2484
01:49:43,255 --> 01:49:44,600
>> RICK Houlihan: Јас не би
велат дека тоа оставајќи го зад себе.

2485
01:49:44,600 --> 01:49:45,855
>> ПУБЛИКАТА: Тие биле одделени од the--

2486
01:49:45,855 --> 01:49:49,140
>> RICK Houlihan: Со документот
пристап, типот на документот во DynamoDB

2487
01:49:49,140 --> 01:49:50,880
е само мислам на тоа како уште еден атрибут.

2488
01:49:50,880 --> 01:49:53,560
Тоа е особина која содржи
хиерархиска структура на податоци.

2489
01:49:53,560 --> 01:49:56,980
А потоа и во прашања,
можете да го користите на својствата

2490
01:49:56,980 --> 01:49:59,480
на оние предмети за користење на објектно нотација.

2491
01:49:59,480 --> 01:50:03,562
За да можам да ги филтрираат на вгнездените
сопственост на документот JSON.

2492
01:50:03,562 --> 01:50:05,520
ПУБЛИКАТА: Значи секое време јас
направи пристап документ,

2493
01:50:05,520 --> 01:50:07,906
Јас вид на може да пристигне во tabular--

2494
01:50:07,906 --> 01:50:08,780
ПУБЛИКАТА: Апсолутно.

2495
01:50:08,780 --> 01:50:09,800
ПУБЛИКАТА: --indexes и
работи едноставно зборуваше.

2496
01:50:09,800 --> 01:50:11,280
RICK Houlihan: Да,
индекси и сето тоа,

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
>> RICK Houlihan: Точно, изедначување
тоа, тоа tabularizing, точно.

2508
01:50:36,230 --> 01:50:37,415
Тоа е она што го направи со неа.

2509
01:50:37,415 --> 01:50:37,860
>> ПУБЛИКАТА: Ви благодарам.

2510
01:50:37,860 --> 01:50:39,609
>> RICK Houlihan: Да,
апсолутно, ви благодарам.

2511
01:50:39,609 --> 01:50:42,240
ПУБЛИКАТА: Значи тоа е вид на
Mongo исполнува Redis classifers.

2512
01:50:42,240 --> 01:50:43,990
>> RICK Houlihan: Да,
тоа е многу слично.

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