1
00:00:00,000 --> 00:00:04,969
>> [За възпроизвеждане на музика]

2
00:00:04,969 --> 00:00:06,010
Рик Houlihan: Добре.

3
00:00:06,010 --> 00:00:06,600
Здравейте на всички.

4
00:00:06,600 --> 00:00:07,670
Моето име е Rick Houlihan.

5
00:00:07,670 --> 00:00:10,330
Аз съм старши главницата
решения архитект на AWS.

6
00:00:10,330 --> 00:00:14,070
Аз се съсредоточи върху NoSQL и
DynamoDB технологии.

7
00:00:14,070 --> 00:00:16,930
Днес съм тук, за да говоря с
ти малко за тях.

8
00:00:16,930 --> 00:00:18,970
>> Моето образование е
предимно в слой данни.

9
00:00:18,970 --> 00:00:21,390
Прекарах половината ми развитие
кариера написването на база данни,

10
00:00:21,390 --> 00:00:25,930
достъп до данни, разтвори
за различни приложения.

11
00:00:25,930 --> 00:00:30,000
Аз съм бил в Cloud виртуализация
за около 20 години.

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

13
00:00:33,460 --> 00:00:37,170
И идеята е, това е като
PG & E, която плащате за това, което използвате.

14
00:00:37,170 --> 00:00:38,800
Днес ние го наричаме облака.

15
00:00:38,800 --> 00:00:41,239
>> Но през годините, съм работил
за няколко фирми

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

17
00:00:42,530 --> 00:00:47,470
Но аз съм съставила списък на техническа
постижения, предполагам, че ще каже.

18
00:00:47,470 --> 00:00:51,620
Имам осем патенти в облачни системи
виртуализация, микропроцесор дизайн,

19
00:00:51,620 --> 00:00:54,440
сложна обработка събитие,
и други области, както добре.

20
00:00:54,440 --> 00:00:58,290
>> Така че тези дни, аз се съсредоточи най-вече върху NoSQL
технологии и следващото поколение

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

22
00:00:59,450 --> 00:01:03,370
И това е, общо взето това, което аз ще съм
да бъда тук говоря с вас днес за.

23
00:01:03,370 --> 00:01:06,030
И така, какво можете да очаквате
от тази сесия,

24
00:01:06,030 --> 00:01:08,254
ние ще мине през един кратък
историята на обработка на данните.

25
00:01:08,254 --> 00:01:10,420
Винаги е полезно да
разберем от къде сме дошли

26
00:01:10,420 --> 00:01:12,400
и защо сме там, където сме.

27
00:01:12,400 --> 00:01:15,600
И ние ще поговорим малко
малко за NoSQL технологии

28
00:01:15,600 --> 00:01:17,500
от основен гледна точка.

29
00:01:17,500 --> 00:01:19,870
>> Ние ще се получи в някои от
вътрешността DynamoDB.

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

31
00:01:24,350 --> 00:01:27,340
Той е напълно управлявани и
Решение, NoSQL.

32
00:01:27,340 --> 00:01:32,420
И ние ще поговорим малко за маса
Структурата, APIs, типове данни, показатели

33
00:01:32,420 --> 00:01:35,177
и някои от вътрешността
на тази DynamoDB технология.

34
00:01:35,177 --> 00:01:37,760
Ще получите в някои от дизайна
модели и добри практики.

35
00:01:37,760 --> 00:01:39,968
Ще говорим за това как се
използвате тази технология за някои

36
00:01:39,968 --> 00:01:41,430
от днешните приложения.

37
00:01:41,430 --> 00:01:44,820
И тогава ние ще говорим малко по-
за развитието или появата

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

39
00:01:48,980 --> 00:01:51,580
и как DynamoDB играе в това, както добре.

40
00:01:51,580 --> 00:01:54,690
И ние ще ви оставя малко
позоваване архитектура дискусия

41
00:01:54,690 --> 00:01:59,540
така че можем да поговорим за някои от
начините, по които могат да използват DynamoDB.

42
00:01:59,540 --> 00:02:04,116
>> Така че първата off-- това е въпрос
Чувам много е, какво е база данни.

43
00:02:04,116 --> 00:02:06,240
Много хора си мислят,
знам какво е база данни.

44
00:02:06,240 --> 00:02:08,360
Ако Google, ще видите това.

45
00:02:08,360 --> 00:02:11,675
Това е структуриран набор от данни, държани
в компютър, особено тази, която

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

47
00:02:13,600 --> 00:02:16,992
Предполагам, че това е добра
определение на модерна база данни.

48
00:02:16,992 --> 00:02:19,450
Но аз не го харесват, защото
той предполага няколко неща.

49
00:02:19,450 --> 00:02:20,935
Това предполага структура.

50
00:02:20,935 --> 00:02:23,120
И това означава, че тя е на компютър.

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

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

53
00:02:28,020 --> 00:02:32,000
>> Така че по-добро определение на
база данни, е нещо като това.

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

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

56
00:02:35,910 --> 00:02:36,868
Това е от About.com.

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

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

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

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

61
00:02:49,290 --> 00:02:52,110
>> Сега, ако мога да попитам средното
разработчик днес това, което е

62
00:02:52,110 --> 00:02:54,770
база данни, това е отговорът, който получи.

63
00:02:54,770 --> 00:02:56,070
Somewhere I могат да се придържаме неща.

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 US преброяване.

128
00:05:24,390 --> 00:05:26,976
Това е наистина, когато обръщането
посоча модерна обработка на данни.

129
00:05:26,976 --> 00:05:28,850
Това е точката, в
които размерът на данни

130
00:05:28,850 --> 00:05:32,060
които се събират от
Правителството на САЩ, стигнал до етапа,

131
00:05:32,060 --> 00:05:34,005
къде го взе осем години, за да обработи.

132
00:05:34,005 --> 00:05:36,350
>> Сега, осем years-- като
знаете ли, преброяването

133
00:05:36,350 --> 00:05:39,180
писти всеки 10 years-- така че е
доста очевидно, че от време ние

134
00:05:39,180 --> 00:05:41,419
имам преброяването 1890 г.,
количеството данни, че

135
00:05:41,419 --> 00:05:43,210
щеше да бъде обработена
от правителството беше

136
00:05:43,210 --> 00:05:46,335
ще надхвърли 10-те години, че тя
ще предприеме, за да постави началото на новия преброяването.

137
00:05:46,335 --> 00:05:47,250
Това беше проблем.

138
00:05:47,250 --> 00:05:49,000
>> Така че един човек на име Херман
Холерит дойде

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

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

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

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

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

144
00:06:08,417 --> 00:06:09,750
И това е наистина това, което са направили.

145
00:06:09,750 --> 00:06:11,110
Те направиха за обработка на данни.

146
00:06:11,110 --> 00:06:15,400
>> Що така разпространението на удар
карти, удачно механизми

147
00:06:15,400 --> 00:06:18,560
да бъде в състояние да се наберат, че
технология, за да сондира сортирани резултатни набори.

148
00:06:18,560 --> 00:06:20,726
Можете да видите на тази снимка
там имаме little--

149
00:06:20,726 --> 00:06:23,970
това е малко small-- но можете да видите
много гениални механичен механизъм

150
00:06:23,970 --> 00:06:26,970
където имаме тесте от перфокарта.

151
00:06:26,970 --> 00:06:28,720
И предприемане на нечия
малко отвертка

152
00:06:28,720 --> 00:06:31,400
и залепване през анализатора
слотове и го повдигнете нагоре

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

154
00:06:34,820 --> 00:06:36,270
>> Това е съвкупност.

155
00:06:36,270 --> 00:06:38,690
Ние правим това през цялото време
днес в компютъра,

156
00:06:38,690 --> 00:06:40,100
, където можете да го направите в базата данни.

157
00:06:40,100 --> 00:06:41,620
Свикнали сме да го направите ръчно, нали?

158
00:06:41,620 --> 00:06:42,994
Хората поставят тези неща заедно.

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

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

161
00:06:50,070 --> 00:06:55,980
>> Индустрията за обработка на данни се
поука от пианата играч.

162
00:06:55,980 --> 00:06:57,855
Player пиана назад към
на края на века

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
Налягане Data е нещо
който движи иновациите.

215
00:09:41,920 --> 00:09:44,610
И ако се вгледате в над
през последните пет години,

216
00:09:44,610 --> 00:09:48,180
това е диаграма на това, данните
натоварване в целия цяло предприятие

217
00:09:48,180 --> 00:09:49,640
Как изглежда в последните пет години.

218
00:09:49,640 --> 00:09:52,570
>> А общото правило на палеца
тези days-- ако отидат Google--

219
00:09:52,570 --> 00:09:55,290
е 90% от данните, които
ние съхраняваме днес, и това беше

220
00:09:55,290 --> 00:09:57,330
генерирани в рамките на последните две години.

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

222
00:09:57,911 --> 00:09:59,410
Сега, това не е тенденция, която е нова.

223
00:09:59,410 --> 00:10:01,230
Това е тенденция, която е била
излиза в продължение на 100 години.

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

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

226
00:10:08,040 --> 00:10:10,570
>> Така че през последните 100 години,
сме виждали тази тенденция.

227
00:10:10,570 --> 00:10:11,940
Това няма да се промени.

228
00:10:11,940 --> 00:10:14,789
В бъдеще ние ще видим
това, ако не ускорен тенденция.

229
00:10:14,789 --> 00:10:16,330
И можете да видите това, което изглежда по този начин.

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

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

232
00:10:27,080 --> 00:10:30,380
Това е 6500 пъти повече информация.

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

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

235
00:10:33,292 --> 00:10:35,000
Преди пет години, I
ще говоря с фирми

236
00:10:35,000 --> 00:10:38,260
кой ще ми говори за това, което е трън
тя е да управлява терабайта данни.

237
00:10:38,260 --> 00:10:39,700
И те ще се говори
с мен за това как виждаме

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

239
00:10:41,825 --> 00:10:43,030
в рамките на няколко години.

240
00:10:43,030 --> 00:10:45,170
>> Същите тези фирми
Днес имам среща с,

241
00:10:45,170 --> 00:10:48,100
и те да ми говори за
проблем са там като управляващ

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

243
00:10:51,440 --> 00:10:53,590
Така че експлозията на
данни в индустрията

244
00:10:53,590 --> 00:10:56,670
е шофиране огромното
нужда от по-добри решения.

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

246
00:11:00,980 --> 00:11:03,490
>> И така, има линейна
корелация между налягането на данни

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

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

249
00:11:07,780 --> 00:11:11,090
когато обемът на данните
който трябва да бъде обработен

250
00:11:11,090 --> 00:11:15,490
надхвърля капацитета на системата
да я обработва в разумен срок

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

252
00:11:18,870 --> 00:11:21,080
са измислени, за да реши тези проблеми.

253
00:11:21,080 --> 00:11:24,090
Тези нови технологии,
от своя страна, отвори вратата

254
00:11:24,090 --> 00:11:27,840
към друг набор от проблеми, които
набира дори повече данни.

255
00:11:27,840 --> 00:11:29,520
>> Сега, ние няма да спрем това.

256
00:11:29,520 --> 00:11:30,020
Нали така?

257
00:11:30,020 --> 00:11:31,228
Ние няма да спрем това.

258
00:11:31,228 --> 00:11:31,830
Защо?

259
00:11:31,830 --> 00:11:35,520
Защото не можеш да знаеш всичко
има да се знае във Вселената.

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

261
00:11:40,510 --> 00:11:43,440
ние винаги сме принудени да знам повече.

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

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

264
00:11:54,620 --> 00:11:59,920
както разкрие повече и повече и по-
за вътрешната изработки на живот,

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

266
00:12:04,530 --> 00:12:06,440
и че изобретението
което правим днес.

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

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

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

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

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

272
00:12:19,200 --> 00:12:24,980
Е, релационни бази данни,
Език за структурирани заявки,

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
>> Но идеята тук е, че вие ​​съхранявате
Вашите данни като тези инстанция гледка.

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
И аз клъстер тези, заедно,
и мога да Shard, че данните.

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
И железния триъгълник на данни
е това, което ние наричаме теоремата CAP.

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
Толерантност Partition средства
че системата работи добре

399
00:17:28,160 --> 00:17:32,000
въпреки физическата мрежа
разделителните стени между възлите.

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

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

402
00:17:36,270 --> 00:17:36,880
Всичко е наред.

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

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

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

406
00:17:43,680 --> 00:17:47,510
Ако дялът случва между
на DataNodes в хранилището на данни,

407
00:17:47,510 --> 00:17:48,831
базата данни катастрофи.

408
00:17:48,831 --> 00:17:49,330
Нали така?

409
00:17:49,330 --> 00:17:50,900
Той просто отива надолу.

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

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

412
00:17:54,230 --> 00:17:54,730
Нали така?

413
00:17:54,730 --> 00:17:58,021
Защото има no-- обикновено, клъстер
база данни, там не е много голяма част от тях

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

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

416
00:18:03,019 --> 00:18:05,060
Тъй като те трябва да бъдат
последователна и достъпно.

417
00:18:05,060 --> 00:18:10,320
Ако дял са да се инжектира,
След това ще трябва да направи избор.

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

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

420
00:18:16,080 --> 00:18:16,580
Всичко е наред.

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

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

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

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

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

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

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

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

429
00:18:37,590 --> 00:18:41,855
>> До този дял е отстранена,
достъп за писане е блокиран.

430
00:18:41,855 --> 00:18:43,230
Това означава, че те не са на разположение.

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

432
00:18:44,510 --> 00:18:46,554
Когато виждаме, че
дял се инжектира,

433
00:18:46,554 --> 00:18:48,470
Сега ние сме последователни,
защото ние не отиваме

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

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

436
00:18:52,100 --> 00:18:54,130
Ние ще трябва да
установите връзка

437
00:18:54,130 --> 00:18:56,930
преди някоя актуализация
данните се допуска.

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

439
00:18:58,120 --> 00:19:02,650
>> Следващата вкус ще бъде система AP,
или на разположение и се разпределя

440
00:19:02,650 --> 00:19:03,640
система за толерантност.

441
00:19:03,640 --> 00:19:05,320
Тези момчета не им пука.

442
00:19:05,320 --> 00:19:06,020
Нали така?

443
00:19:06,020 --> 00:19:08,960
Всеки възел, който получава
напиша, ще го взема.

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

445
00:19:11,480 --> 00:19:14,730
Тези възли получават клиент, клиент идва
в, казва, аз отивам да пиша някои данни.

446
00:19:14,730 --> 00:19:16,300
Node казва, няма проблем.

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
>> Thing да посоча тук.

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
>> ACID ни дава валентност, последователност,
изолация и дълготрайност.

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

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

468
00:20:13,550 --> 00:20:16,570
Съвместимост означава, че
Базата данни ще винаги

469
00:20:16,570 --> 00:20:19,780
да бъдат приведени в последователен
състояние след актуализация.

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

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

472
00:20:24,400 --> 00:20:26,720
>> Така че това е малко по-различна
от съгласуваността на ОСП.

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
>> От друга страна, трябва
което се нарича BASE технология.

511
00:22:05,530 --> 00:22:07,291
А това са вашите NoSQL Базите.

512
00:22:07,291 --> 00:22:07,790
Всичко е наред.

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

514
00:22:10,180 --> 00:22:14,720
И ето какво ти се обадя по същество
достъпно, меко състояние, в крайна сметка

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

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

517
00:22:16,420 --> 00:22:19,690
>> По принцип на разположение, тъй
те са делба толерантни.

518
00:22:19,690 --> 00:22:21,470
Те винаги ще бъдат
там, дори ако има

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

520
00:22:23,053 --> 00:22:25,900
Ако мога да говоря с един възел, аз съм
ще бъде в състояние да чете данни.

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

522
00:22:26,460 --> 00:22:30,810
Аз не винаги може да бъде в състояние да напише
данни, ако аз съм последователен платформа.

523
00:22:30,810 --> 00:22:32,130
Но аз ще бъда в състояние да чете данни.

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

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

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

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

528
00:22:43,390 --> 00:22:46,650
и то не е повторен от другата страна на
клъстер, все още, когато прочетох, че данните,

529
00:22:46,650 --> 00:22:48,680
това състояние, може да не бъдат последователни.

530
00:22:48,680 --> 00:22:51,650
Въпреки това, ще бъде
в крайна сметка последователна,

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

532
00:22:53,870 --> 00:22:56,480
ще се възпроизведе в лимфните.

533
00:22:56,480 --> 00:22:59,095
И в крайна сметка, това състояние
ще бъдат приведени в ред,

534
00:22:59,095 --> 00:23:00,890
и това ще бъде последователна държавна.

535
00:23:00,890 --> 00:23:05,000
>> Сега, теоремата CAP наистина
играе само в едно състояние.

536
00:23:05,000 --> 00:23:08,700
Това условие е, когато това се случи.

537
00:23:08,700 --> 00:23:13,710
Защото всеки път, когато това е работеща в
нормален режим, няма дял,

538
00:23:13,710 --> 00:23:16,370
всичко е последователно и достъпно.

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

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

541
00:23:21,260 --> 00:23:25,360
Но как системата реагира, когато тези,
възникнат диктува какъв тип система

542
00:23:25,360 --> 00:23:26,750
имаме работа.

543
00:23:26,750 --> 00:23:31,110
>> Така че нека да погледнем на това, което
който изглежда като за AP системи.

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

545
00:23:32,621 --> 00:23:34,830
AP системи се предлагат в два вкуса.

546
00:23:34,830 --> 00:23:38,514
Те се предлагат в аромата, че е
майстор майстор, 100%, винаги на разположение.

547
00:23:38,514 --> 00:23:40,430
И те влизат в
друг аромат, в която се казва,

548
00:23:40,430 --> 00:23:43,330
Знаете ли какво, аз отивам да се притеснявате
за това нещо разделяне

549
00:23:43,330 --> 00:23:44,724
когато действително дял настъпва.

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

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

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

553
00:23:50,040 --> 00:23:54,440
Cassandra ще бъде майстор
майстор, нека ми пише на всеки възел.

554
00:23:54,440 --> 00:23:55,540
Така че какво ще се случи?

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

556
00:23:58,270 --> 00:24:01,705
Нека да наречем този обект S.
Така че ние имаме държава за S.

557
00:24:01,705 --> 00:24:04,312
Ние имаме някои операции
на S, които са в ход.

558
00:24:04,312 --> 00:24:06,270
Cassandra ми позволява да
пишете на множество възли.

559
00:24:06,270 --> 00:24:08,550
Така че нека да кажа, че се получи
пиша за лидер на два възела.

560
00:24:08,550 --> 00:24:12,274
Е, това, което в крайна сметка се случва е,
ние наричаме, че разделянето събитие.

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

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

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

564
00:24:18,449 --> 00:24:20,830
Това не ме принуждава да
напиши всичко през един възел.

565
00:24:20,830 --> 00:24:22,340
Пиша на две възли.

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

567
00:24:23,330 --> 00:24:25,740
>> Така че сега имам две държави.

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

569
00:24:26,360 --> 00:24:28,110
Какво ще се случи
е рано или късно,

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

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

572
00:24:33,300 --> 00:24:35,200
е мястото, където тези две
държави идват отново заедно

573
00:24:35,200 --> 00:24:37,310
и там ще бъде един алгоритъм
която работи вътре в базата данни,

574
00:24:37,310 --> 00:24:38,540
реши какво да прави.

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

576
00:24:39,110 --> 00:24:43,057
По подразбиране, последна промяна
печели в повечето системи AP.

577
00:24:43,057 --> 00:24:44,890
Така че обикновено има
алгоритъм подразбиране, това, което

578
00:24:44,890 --> 00:24:47,400
те наричат ​​обаждане
функция, нещо, което

579
00:24:47,400 --> 00:24:51,000
ще се нарича, когато това условие
се открива за да изпълни някои логика

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

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

582
00:24:53,850 --> 00:24:58,770
Обратно повикване и по подразбиране по подразбиране
Резолвер в повечето AP бази данни

583
00:24:58,770 --> 00:25:01,130
е, познайте какво, клеймото печели.

584
00:25:01,130 --> 00:25:02,380
Това беше последната актуализация.

585
00:25:02,380 --> 00:25:04,320
Отивам да се сложи това актуализация там.

586
00:25:04,320 --> 00:25:08,440
Аз може да зареже този запис, че аз
дъмпингови разстояние в дневник за възстановяване

587
00:25:08,440 --> 00:25:11,670
така че потребителят да може да се върне по-късно
и да кажа, хей, имаше сблъсък.

588
00:25:11,670 --> 00:25:12,320
Какво се случи?

589
00:25:12,320 --> 00:25:16,370
И всъщност можете да зареже запис на
всички сблъсъци и ролбек

590
00:25:16,370 --> 00:25:17,550
и да видим какво ще стане.

591
00:25:17,550 --> 00:25:21,580
>> Сега, като потребител, можете също
включва логика в това обаждане.

592
00:25:21,580 --> 00:25:24,290
Така че можете да промените това
обаждане операция.

593
00:25:24,290 --> 00:25:26,730
Може да се каже, хей, аз искам
за решаване на тези данни.

594
00:25:26,730 --> 00:25:28,880
И аз искам да се опитам
слеят тези две досиета.

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

596
00:25:30,050 --> 00:25:32,880
Базата данни не знае как да
направя това по подразбиране. Повечето от времето,

597
00:25:32,880 --> 00:25:34,850
единственото нещо, което на базата данни
Знае как да направите е да се каже,

598
00:25:34,850 --> 00:25:36,100
това е последният запис.

599
00:25:36,100 --> 00:25:39,183
Това е този, който ще спечели,
и това е стойността Отивам да се сложи.

600
00:25:39,183 --> 00:25:41,490
След като това възстановяване деление
и репликация се случи,

601
00:25:41,490 --> 00:25:43,930
ние имаме нашата държава, която
сега е S-председател, който е

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

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

604
00:25:49,700 --> 00:25:51,615
Системи ХФ не се нуждаят от
да се тревожи за това.

605
00:25:51,615 --> 00:25:54,490
Защото веднага след като дял идва
в игра, те просто спрете да приемате

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

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

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

609
00:25:58,670 --> 00:26:01,330
когато не сте съгласни с всички актуализации.

610
00:26:01,330 --> 00:26:04,620
Това е със системи CP направя.

611
00:26:04,620 --> 00:26:05,120
Всичко е наред.

612
00:26:05,120 --> 00:26:07,590
>> Така че нека да поговорим малко
малко за модели за достъп.

613
00:26:07,590 --> 00:26:11,580
Когато говорим за NoSQL, това е
всичко за модела за достъп.

614
00:26:11,580 --> 00:26:13,550
Сега, SQL е специална, запитвания.

615
00:26:13,550 --> 00:26:14,481
Това е релационна магазин.

616
00:26:14,481 --> 00:26:16,480
Ние не трябва да се притеснявате
за модел за достъп.

617
00:26:16,480 --> 00:26:17,688
Аз пиша много сложен въпрос.

618
00:26:17,688 --> 00:26:19,250
От само себе си и получава данните.

619
00:26:19,250 --> 00:26:21,210
Това е, което това изглежда
харесват, нормализиране.

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

621
00:26:24,890 --> 00:26:26,640
Имам различни видове продукти.

622
00:26:26,640 --> 00:26:27,217
Имам книги.

623
00:26:27,217 --> 00:26:27,800
Имам албуми.

624
00:26:27,800 --> 00:26:30,090
Имам клипове.

625
00:26:30,090 --> 00:26:33,370
Връзката между продуктите
и всяка една от тези книги, албуми,

626
00:26:33,370 --> 00:26:34,860
и клипове маси е 1: 1.

627
00:26:34,860 --> 00:26:35,800
Всичко е наред?

628
00:26:35,800 --> 00:26:38,860
Имам ID продукт,
и че отговаря за самоличност

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

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

631
00:26:41,580 --> 00:26:44,350
Това е 1: 1 отношения
през тези таблици.

632
00:26:44,350 --> 00:26:46,970
>> Сега, books-- всички те
имам е корен свойства.

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

634
00:26:47,550 --> 00:26:48,230
Това е прекрасно.

635
00:26:48,230 --> 00:26:52,130
Едно към едно отношения, да получа всички
данните, което трябва да се опише тази книга.

636
00:26:52,130 --> 00:26:54,770
Albums-- албуми имат песни.

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

638
00:26:56,470 --> 00:26:58,905
Всеки албум може да има много песни.

639
00:26:58,905 --> 00:27:00,780
Така че за всеки трак
албума, мога да имам

640
00:27:00,780 --> 00:27:02,570
нов рекорд в тази детска маса.

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

642
00:27:04,680 --> 00:27:06,700
I създавате множество записи
в таблицата за писти.

643
00:27:06,700 --> 00:27:08,850
One-към-много.

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

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
И да получите моите клипове, имам
да се присъединят към Продукти Videos,

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

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
Ще поговорим малко за
как това работи в Динамо DB.

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

699
00:29:33,570 --> 00:29:37,751
във всеки един ред, във всеки един
т, както правите в SQL таблица.

700
00:29:37,751 --> 00:29:39,750
И какво ми позволява
да направите, е много неща

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

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

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

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

705
00:29:51,930 --> 00:29:56,510
А продукта за книга мощ
Трябва ID вид, който определя една книга.

706
00:29:56,510 --> 00:29:59,180
И заявлението
ще се включи, че ID.

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

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

709
00:30:04,100 --> 00:30:05,990
Записи на книги имат тези свойства.

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

711
00:30:08,100 --> 00:30:11,289
Така че аз отивам да запълни
Книга за обект с тази позиция.

712
00:30:11,289 --> 00:30:13,080
Следваща точка идва и
казва, какъв е този елемент?

713
00:30:13,080 --> 00:30:14,560
Ами този елемент е албум.

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

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

716
00:30:18,487 --> 00:30:19,320
Виждате ли какво имам предвид?

717
00:30:19,320 --> 00:30:21,950
>> Така че прилагането tier-- I
Просто изберете всички тези записи.

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
The стари неща е по-добре.

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
ние наричаме Technology Приемане крива.

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

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

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

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

775
00:32:46,310 --> 00:32:47,830
>> Става все по твърде скъпо.

776
00:32:47,830 --> 00:32:49,790
Това отнема прекалено дълго време за обработка на данни.

777
00:32:49,790 --> 00:32:50,890
Ние трябва нещо по-добро.

778
00:32:50,890 --> 00:32:52,890
Можете да получите новаторите
там вървят около,

779
00:32:52,890 --> 00:32:55,050
Опитвам се да разбера какво е решението.

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

781
00:32:56,050 --> 00:32:58,170
>> Каква е следващата най-
начин да се направи това нещо?

782
00:32:58,170 --> 00:32:59,530
И те измисли нещо.

783
00:32:59,530 --> 00:33:03,140
И хората с реалната болка,
момчетата от ръба на кървене,

784
00:33:03,140 --> 00:33:06,390
те ще скочи над всичко,
защото те се нуждаят от отговор.

785
00:33:06,390 --> 00:33:09,690
Сега това, което неминуемо happens-- и
това се случва сега в NoSQL.

786
00:33:09,690 --> 00:33:11,090
Виждам го през цялото време.

787
00:33:11,090 --> 00:33:13,610
>> Какво се случва, е неизбежно
хората започват да използват новия инструмент

788
00:33:13,610 --> 00:33:15,490
По същия начин те са използвали стария инструмент.

789
00:33:15,490 --> 00:33:17,854
И те разбери го
не работи толкова добре.

790
00:33:17,854 --> 00:33:20,020
Аз не мога да си спомня кой съм
говорим за по-рано днес.

791
00:33:20,020 --> 00:33:22,080
Но това е като, когато
пневматичен е измислена,

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

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

794
00:33:27,360 --> 00:33:30,610
>> Но това е, което е
случва с NoSQL днес.

795
00:33:30,610 --> 00:33:33,900
Ако ходите в повечето магазини,
те се опитват да се NoSQL магазини.

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

797
00:33:36,510 --> 00:33:39,900
и те са го зарежда
пълен с релационна схема.

798
00:33:39,900 --> 00:33:41,630
Защото това е начина,
те дизайн на бази данни.

799
00:33:41,630 --> 00:33:44,046
И те се чудите, защо е
тя не се извършва много добре?

800
00:33:44,046 --> 00:33:45,230
Момче, това нещо смърди.

801
00:33:45,230 --> 00:33:49,900
Аз трябваше да се поддържа през целия ми
присъединява in-- това е като, не, не.

802
00:33:49,900 --> 00:33:50,800
Поддържа се присъедини?

803
00:33:50,800 --> 00:33:52,430
Защо се присъедини данни?

804
00:33:52,430 --> 00:33:54,350
Не се присъединят данни в NoSQL.

805
00:33:54,350 --> 00:33:55,850
Можете да го сумира.

806
00:33:55,850 --> 00:34:00,690
>> Така че, ако искате да избегнете това, да научат
как работи функцията преди да се

807
00:34:00,690 --> 00:34:02,010
започнете да го използвате.

808
00:34:02,010 --> 00:34:04,860
Не се опитвайте да използвате новите инструменти на
същия начин, който сте използвали старите инструменти.

809
00:34:04,860 --> 00:34:06,500
Вие ще имате лош опит.

810
00:34:06,500 --> 00:34:08,848
И всеки път,
това е за какво става въпрос.

811
00:34:08,848 --> 00:34:11,389
Когато започнем да идва тук,
това е, защото хората измислили

812
00:34:11,389 --> 00:34:13,449
как да използват инструментите.

813
00:34:13,449 --> 00:34:16,250
>> Те направиха същото, когато
релационни бази данни са били измислени,

814
00:34:16,250 --> 00:34:17,969
и те бяха замяна файлови системи.

815
00:34:17,969 --> 00:34:20,420
Те се опитаха да изградят файлови системи
с релационни бази данни

816
00:34:20,420 --> 00:34:22,159
защото това е, което хората разбират.

817
00:34:22,159 --> 00:34:23,049
То не е работа.

818
00:34:23,049 --> 00:34:26,090
Така че разбирането на най-добрите практики
на технологията с който се работи

819
00:34:26,090 --> 00:34:26,730
е огромна.

820
00:34:26,730 --> 00:34:29,870
Много важно.

821
00:34:29,870 --> 00:34:32,440
>> Така че ние ще се получи в DynamoDB.

822
00:34:32,440 --> 00:34:36,480
DynamoDB е AWS е
напълно успя NoSQL платформа.

823
00:34:36,480 --> 00:34:37,719
Какво означава напълно успя да кажа?

824
00:34:37,719 --> 00:34:40,010
Това означава, че не е нужно да
наистина се притеснявате за нищо.

825
00:34:40,010 --> 00:34:42,060
>> Ти дойде в, да ви кажа
нас, имам нужда от една маса.

826
00:34:42,060 --> 00:34:43,409
Тя се нуждае от толкова много капацитет.

827
00:34:43,409 --> 00:34:47,300
Можете натисна бутона, а ние разпоредба
всички инфраструктура зад сцената.

828
00:34:47,300 --> 00:34:48,310
Сега е огромна.

829
00:34:48,310 --> 00:34:51,310
>> Защото, когато говорим
за мащабиране на база данни,

830
00:34:51,310 --> 00:34:53,917
NoSQL клъстери данни в
мащаба, работа петабайта,

831
00:34:53,917 --> 00:34:55,750
използвате милиони
транзакции в секунда,

832
00:34:55,750 --> 00:34:58,180
тези неща не са малки клъстери.

833
00:34:58,180 --> 00:35:00,830
Ние говорим хиляди копия.

834
00:35:00,830 --> 00:35:04,480
Управление на хиляди случаи,
дори виртуални копия,

835
00:35:04,480 --> 00:35:06,350
е истинска болка в задника.

836
00:35:06,350 --> 00:35:09,110
Искам да кажа, мисля, за всеки път,
операционна система кръпка излиза

837
00:35:09,110 --> 00:35:11,552
или нова версия на базата данни.

838
00:35:11,552 --> 00:35:13,260
Какво означава това
да ви оперативно?

839
00:35:13,260 --> 00:35:16,330
Това означава, че имаш 1200
сървъри, които трябва да бъдат актуализирани.

840
00:35:16,330 --> 00:35:18,960
Сега дори и с автоматизация,
който може да отнеме дълго време.

841
00:35:18,960 --> 00:35:21,480
Това може да доведе до много
оперативни главоболие,

842
00:35:21,480 --> 00:35:23,090
защото може да се наложи услуги надолу.

843
00:35:23,090 --> 00:35:26,070
>> Както актуализира тези бази данни, I
може да направи сини зелени внедрявания

844
00:35:26,070 --> 00:35:29,420
където I разположи и надграждане половината ми
възли, а след това ъпгрейд другата половина.

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
>> Scale хоризонтално.

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
Identity Management Access, или IAM.

877
00:36:57,920 --> 00:37:01,980
Тя прониква всяка система,
всяка услуга, която AWS предлага.

878
00:37:01,980 --> 00:37:03,630
DynamoDB не е изключение.

879
00:37:03,630 --> 00:37:06,020
Можете да контролирате достъпа
до таблиците за DynamoDB.

880
00:37:06,020 --> 00:37:09,960
Across всичките си сметки чрез AWS
определяща роля за достъп и разрешения

881
00:37:09,960 --> 00:37:12,140
в IAM инфраструктура.

882
00:37:12,140 --> 00:37:16,630
>> И това е ключова и неделима компонент в
това, което наричаме Event Driven програмиране.

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

884
00:37:19,056 --> 00:37:22,080
>> АУДИТОРИЯ: Как си лихвен процент на истинската
позитиви срещу фалшиво отрицателни

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

886
00:37:24,052 --> 00:37:26,260
Рик 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
>> Рик 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
ако сте запознати с всяка база данни,
бази данни имат наистина два вида APIs

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

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 имаме, е
това, което ние наричаме нашия Streams 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
Но Streams е наистина 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,
Object, нотация.

963
00:40:49,380 --> 00:40:52,510
Тя ви позволява да основно
дефинира йерархична структура.

964
00:40:52,510 --> 00:40:58,107
>> Можете да съхраните документ JSON на
DynamoDB използват общи компоненти

965
00:40:58,107 --> 00:41:00,940
или строителни блокове, които са налични
в повечето езици за програмиране.

966
00:41:00,940 --> 00:41:03,602
Така че, ако имате Java, вие сте
разглеждате карти и списъци.

967
00:41:03,602 --> 00:41:05,060
Мога да създавате обекти тази зона картата.

968
00:41:05,060 --> 00:41:08,030
А картата като ключови ценности
съхранява като свойства.

969
00:41:08,030 --> 00:41:10,890
И това може да има списъци на
стойности в рамките на тези свойства.

970
00:41:10,890 --> 00:41:13,490
Можете да съхраните този комплекс
йерархична структура

971
00:41:13,490 --> 00:41:16,320
като един атрибут
на т DynamoDB.

972
00:41:16,320 --> 00:41:19,010

973
00:41:19,010 --> 00:41:24,460
>> Така маси в DynamoDB, като най-
NoSQL бази данни, таблици имат позиции.

974
00:41:24,460 --> 00:41:26,469
В MongoDB бихте
наричаме тези документи.

975
00:41:26,469 --> 00:41:27,760
И това ще бъде най-диван база.

976
00:41:27,760 --> 00:41:28,900
Също база данни документ.

977
00:41:28,900 --> 00:41:29,941
Наричаш тези документи.

978
00:41:29,941 --> 00:41:32,930
Документи или предмети имат атрибути.

979
00:41:32,930 --> 00:41:35,850
Могат да съществуват или атрибути
не съществува в елемента.

980
00:41:35,850 --> 00:41:38,520
В DynamoDB, има
едно задължително атрибут.

981
00:41:38,520 --> 00:41:43,880
Точно като в релационна база данни,
имате първичен ключ на масата.

982
00:41:43,880 --> 00:41:46,010
>> DynamoDB има това, което наричаме ключова хашиш.

983
00:41:46,010 --> 00:41:48,280
Hash ключ трябва да е уникално.

984
00:41:48,280 --> 00:41:52,580
Така че, когато се определи хеш таблица,
основно това, което искам да кажа,

985
00:41:52,580 --> 00:41:54,110
е всеки елемент ще има ключова хашиш.

986
00:41:54,110 --> 00:41:58,520
И всеки хеш бутона трябва да бъде уникален.

987
00:41:58,520 --> 00:42:01,200
>> Всеки елемент е дефиниран
от тази уникална хеш бутона.

988
00:42:01,200 --> 00:42:02,940
И може да има само един.

989
00:42:02,940 --> 00:42:05,820
Това е ОК, но много пъти
това, което хората се нуждаят от

990
00:42:05,820 --> 00:42:08,170
е те искат, е този хеш
ключ да се направи малко по-

991
00:42:08,170 --> 00:42:11,010
от това просто да бъде уникален идентификатор.

992
00:42:11,010 --> 00:42:15,240
Много пъти ние искаме да използваме този ключ хеш
като най-агрегация ниво кофата.

993
00:42:15,240 --> 00:42:19,160
И начина, по който направи това е чрез
добавяне на това, което наричаме ключова диапазон.

994
00:42:19,160 --> 00:42:22,460
>> Така че, ако това е само хеш
маса, това трябва да е уникално.

995
00:42:22,460 --> 00:42:27,040
Ако това е хашиш и обхват на маса, на
комбинация на хеш и обхвата

996
00:42:27,040 --> 00:42:28,640
трябва да бъде уникален.

997
00:42:28,640 --> 00:42:30,110
Така че мисля за него по този начин.

998
00:42:30,110 --> 00:42:32,140
Ако имам форум.

999
00:42:32,140 --> 00:42:39,010
И формата има теми, той има
длъжности, и тя има отговори.

1000
00:42:39,010 --> 00:42:42,630
>> Така че аз може да има хеш
ключ, който е ID на темата.

1001
00:42:42,630 --> 00:42:46,650
И аз може да има ключова гама,
който е ID на отговор.

1002
00:42:46,650 --> 00:42:49,650
По този начин, ако искам да получите всички
отговори за определена тема,

1003
00:42:49,650 --> 00:42:52,370
Мога само да задава въпроси към хеш.

1004
00:42:52,370 --> 00:42:55,190
Мога да кажа, просто ми даде всичко
елементите, които имат този хеш.

1005
00:42:55,190 --> 00:43:01,910
И аз отивам да получите всеки въпрос
или да пусне тази конкретна тема.

1006
00:43:01,910 --> 00:43:03,910
Тези топ струпвания ниво
са много важни.

1007
00:43:03,910 --> 00:43:07,370
Те подкрепят първичния достъп
образец на заявлението.

1008
00:43:07,370 --> 00:43:09,420
Най-общо казано, този
е това, което искаме да направим.

1009
00:43:09,420 --> 00:43:11,780
Искаме че table--
като заредите масата,

1010
00:43:11,780 --> 00:43:16,640
ние искаме да се структурира данните
в таблицата по такъв начин,

1011
00:43:16,640 --> 00:43:20,140
че заявлението може много
бързо извличане на тези резултати.

1012
00:43:20,140 --> 00:43:24,510
И много пъти на начин да направите това е
да запази тези съвкупности като ние

1013
00:43:24,510 --> 00:43:25,650
въведете данните.

1014
00:43:25,650 --> 00:43:31,110
По принцип, ние сме разпространение на данни
в светлата кофата, тъй като идва инча

1015
00:43:31,110 --> 00:43:35,210
>> Range ключове позволяват me-- хеш
ключове трябва да бъдат равни.

1016
00:43:35,210 --> 00:43:39,490
Когато се задава въпроси хеш, аз трябва да кажа,
дайте ми хеш това се равнява на това.

1017
00:43:39,490 --> 00:43:41,950
Когато се задава въпроси диапазон, I
Може да се каже, дайте ми кръг

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
Така че в този конкретен случай,
хеш алгоритъм бягаме е ND 5 въз.

1043
00:44:59,300 --> 00:45:04,765
>> И ако имам ID, и това
е моя хеш бутона, имам 1, 2, 3.

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

1045
00:45:07,390 --> 00:45:10,800
и 1 е равно на 7В, 2
се равнява на 48, 3 равнява CD.

1046
00:45:10,800 --> 00:45:13,092
Те са пръснати по целия ключ пространство.

1047
00:45:13,092 --> 00:45:14,050
И защо правиш това?

1048
00:45:14,050 --> 00:45:17,120
Защото това прави сигурен, че мога
изведе записите в множество възли.

1049
00:45:17,120 --> 00:45:19,574
>> Ако Правя това
Постепенно, 1, 2, 3.

1050
00:45:19,574 --> 00:45:21,990
И аз имам един хеш диапазон, който
писти в този конкретен случай,

1051
00:45:21,990 --> 00:45:24,785
малка хеш пространство,
той работи от 00 до FF,

1052
00:45:24,785 --> 00:45:27,951
След това записите ще дойде по-
и те ще отидат 1, 2, 3, 4, 5,

1053
00:45:27,951 --> 00:45:30,390
6, 7, 8, 9, 10, 11, 12.

1054
00:45:30,390 --> 00:45:31,800
Какво става?

1055
00:45:31,800 --> 00:45:34,860
Всяка вложка ще същия възел.

1056
00:45:34,860 --> 00:45:36,070
Виждате ли какво имам предвид?

1057
00:45:36,070 --> 00:45:40,910
>> Защото, когато аз се раздели пространството,
и аз се разпространи тези записи цяла,

1058
00:45:40,910 --> 00:45:45,950
и аз дял, аз отивам да се каже,
дял 1 има ключово пространство 0-54.

1059
00:45:45,950 --> 00:45:47,720
Partition 2 е 55-89.

1060
00:45:47,720 --> 00:45:49,780
Partition 3 е AA до FF.

1061
00:45:49,780 --> 00:45:53,740
Така че, ако аз съм с линейно увеличаване
IDs, можете да видите какво се случва.

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 ви дава възможност
на хеширане стойността на ключа.

1069
00:46:11,325 --> 00:46:13,950
Винаги трябва да се направи, че ако
сте с помощта на увеличаване хеш

1070
00:46:13,950 --> 00:46:17,380
ключ в MongoDB, или ще бъде
заковаване всеки запис на един възел,

1071
00:46:17,380 --> 00:46:21,290
и ще се ограничава
Вашата пиши пропускателна зле.

1072
00:46:21,290 --> 00:46:24,896
>> АУДИТОРИЯ: Е, че A9 169 в десетична?

1073
00:46:24,896 --> 00:46:28,450
>> Рик Houlihan: Да, това е
някъде около там.

1074
00:46:28,450 --> 00:46:29,950
A9, аз не знам.

1075
00:46:29,950 --> 00:46:32,200
Ще трябва да си взема двоичен
да десетичната калкулатор.

1076
00:46:32,200 --> 00:46:34,237
Мозъкът ми не работи по този начин.

1077
00:46:34,237 --> 00:46:36,320
АУДИТОРИЯ: Само един бърз една
от вашите Монго коментари.

1078
00:46:36,320 --> 00:46:39,530
Така е ID на обект, който идва
роден с Монго направи това?

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

1080
00:46:40,179 --> 00:46:41,470
Рик 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
>> Сега нещо за
хеширане, след като хеш

1091
00:47:06,880 --> 00:47:08,800
а value-- и това е
защо хеш ключовете са винаги

1092
00:47:08,800 --> 00:47:13,740
уникални заявки, защото съм се променили
стойността, сега не мога да направя заявка диапазон.

1093
00:47:13,740 --> 00:47:15,640
Не мога да кажа е това
между това или онова,

1094
00:47:15,640 --> 00:47:20,800
защото хеш стойност не върви
да бъде еквивалентно на действителната стойност.

1095
00:47:20,800 --> 00:47:24,570
Така че, когато хеш, че
ключ, това е само между половете.

1096
00:47:24,570 --> 00:47:28,700
Ето защо в DynamoDB хеш бутона
заявки са винаги само между половете.

1097
00:47:28,700 --> 00:47:32,090

1098
00:47:32,090 --> 00:47:34,700
>> Така че сега в диапазон key--
когато аз да добавя, че ключовата гама,

1099
00:47:34,700 --> 00:47:38,180
тези ключови записи обсег на всички влизащи в и
те се съхраняват на едно и също разпределение.

1100
00:47:38,180 --> 00:47:42,430
Така че те са много бързо, лесно
изтеглено, защото това е хашиш,

1101
00:47:42,430 --> 00:47:43,220
това е диапазон.

1102
00:47:43,220 --> 00:47:44,928
И вие виждате всичко
със същата хеш

1103
00:47:44,928 --> 00:47:48,550
получава съхраняват на същия дял пространство.

1104
00:47:48,550 --> 00:47:53,889
Можете да използвате този ключ гама да помогне
намерете вашите данни близо до своята майка.

1105
00:47:53,889 --> 00:47:55,180
Така че това, което съм аз наистина правиш тук?

1106
00:47:55,180 --> 00:47:57,320
Това е един към много отношения.

1107
00:47:57,320 --> 00:48:01,490
Връзката между ключова хеш
и клавиша за интервал е един за мнозина.

1108
00:48:01,490 --> 00:48:03,490
Аз може да има множество ключове хеш.

1109
00:48:03,490 --> 00:48:07,610
Аз може да има само множествена гама
ключове в рамките на всеки хеш бутона.

1110
00:48:07,610 --> 00:48:11,910
>> Хеш определя на родителя,
определя обхвата на децата.

1111
00:48:11,910 --> 00:48:15,240
Така че можете да видите има аналогов тук
между релационния конструкт

1112
00:48:15,240 --> 00:48:18,840
и едни и същи видове
изгражда в NoSQL.

1113
00:48:18,840 --> 00:48:20,760
Хората говорят за
NoSQL като нерелационни.

1114
00:48:20,760 --> 00:48:22,200
Това не е нерелационни.

1115
00:48:22,200 --> 00:48:24,680
Data винаги има взаимоотношения.

1116
00:48:24,680 --> 00:48:28,172
Тези взаимоотношения просто
са моделирани по различен начин.

1117
00:48:28,172 --> 00:48:29,880
Нека поговорим малко
малко за издръжливост.

1118
00:48:29,880 --> 00:48:34,860
Когато пишете, за да DynamoDB, пише
винаги са трипътен повторен.

1119
00:48:34,860 --> 00:48:37,550
Това означава, че ние имаме три AZ му.

1120
00:48:37,550 --> 00:48:39,160
AZ са Наличност зони.

1121
00:48:39,160 --> 00:48:43,430
Можете да мислите за един Наличност
Zone като център за данни

1122
00:48:43,430 --> 00:48:45,447
или колекция от центрове за данни.

1123
00:48:45,447 --> 00:48:47,780
Тези неща са географски
изолирани един от друг

1124
00:48:47,780 --> 00:48:51,610
в различните разломни зони, през
различни електрически мрежи и заливните равнини.

1125
00:48:51,610 --> 00:48:54,510
А отказът на една от AZ не е
ще вземе за определяне на друг.

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

1127
00:48:56,890 --> 00:49:01,240
Той поддържа една под 1
милисекунда латентност между АЗС.

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

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

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

1131
00:49:12,930 --> 00:49:16,139
Така DynamoDB се разпространява
в рамките на три АЗС по подразбиране.

1132
00:49:16,139 --> 00:49:19,430
Ние само ще знанието на обезценката
когато две от тези три възли се върне

1133
00:49:19,430 --> 00:49:21,470
и да кажа, Да, аз го имам.

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

1135
00:49:22,050 --> 00:49:25,950
Защото от гледна точка на четене ние сме само
ще ви дам данните назад, когато

1136
00:49:25,950 --> 00:49:27,570
ние го получите от два възела.

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

1138
00:49:30,490 --> 00:49:32,840
Аз съм винаги гарантирано
да има най-малко един

1139
00:49:32,840 --> 00:49:35,720
на тези, които чете, за да бъде най-
най-актуалната копие на данните.

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

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

1142
00:49:42,450 --> 00:49:45,070
В такъв случай аз ще кажа,
Ще прочета само от един възел.

1143
00:49:45,070 --> 00:49:47,430
И аз не мога да гарантирам, че ще ходи
да бъде най-актуалните данни.

1144
00:49:47,430 --> 00:49:49,450
>> Така че, ако един запис идва в,
не е повторен още,

1145
00:49:49,450 --> 00:49:50,360
започваш да се получи, че копие.

1146
00:49:50,360 --> 00:49:52,220
Това е в крайна сметка последователно четене.

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

1148
00:49:54,640 --> 00:49:56,140
Така че това е нещо, което да си помисля.

1149
00:49:56,140 --> 00:50:00,160
Когато сте прочитане DynamoDB, и
можете да започнете създаването на своя капацитет за четене

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

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

1152
00:50:06,010 --> 00:50:09,342
>> И така ще ви спести пари.

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

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

1155
00:50:12,925 --> 00:50:15,720
Това е нещо, което можете да изберете.

1156
00:50:15,720 --> 00:50:17,659
>> Нека поговорим за индексите.

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

1158
00:50:19,450 --> 00:50:23,720
Имаме хеш ключове, и
ние имаме ключове обсег на действие.

1159
00:50:23,720 --> 00:50:24,320
Това е хубаво.

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

1161
00:50:26,950 --> 00:50:27,783
>> Какво означава това?

1162
00:50:27,783 --> 00:50:30,410
Имам един признак, че аз
може да работи, богати на заявки.

1163
00:50:30,410 --> 00:50:31,800
Това е ключът за обхват.

1164
00:50:31,800 --> 00:50:35,530
Другите характеристики на този item--
Мога да филтрирате по тези атрибути.

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

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

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

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

1169
00:50:45,340 --> 00:50:49,002
Индексът е наистина
друг изглед на таблицата.

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

1171
00:50:50,490 --> 00:50:51,781
>> Първият от тях ще говорим за.

1172
00:50:51,781 --> 00:50:57,740
Така местните вторични са съжителствали
на същия дял като данните.

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

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

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

1176
00:51:04,599 --> 00:51:06,890
Когато пиша идва,
ние ще пиша чрез индекса.

1177
00:51:06,890 --> 00:51:09,306
Ние ще пиша до масата,
и след това ние ще признаем.

1178
00:51:09,306 --> 00:51:10,490
Така че това е последователна.

1179
00:51:10,490 --> 00:51:13,174
След отписването е било
признато от масата,

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

1181
00:51:15,090 --> 00:51:18,380
ще има същата визия на данни.

1182
00:51:18,380 --> 00:51:22,390
Но това, което те ви позволяват да направите, е да
определи заместник ключове обсег на действие.

1183
00:51:22,390 --> 00:51:25,260
>> Трябва да използвате една и съща хеш
ключова като основна маса,

1184
00:51:25,260 --> 00:51:29,050
защото те са едновременно намира на
същия дял, и те са последователни.

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

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

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

1188
00:51:44,590 --> 00:51:46,840
И може би има изземване.

1189
00:51:46,840 --> 00:51:50,240
>> Всяка част, която е направена от тази
производител след тази дата,

1190
00:51:50,240 --> 00:51:52,840
Имам нужда да тегли от моята линия.

1191
00:51:52,840 --> 00:51:55,950
Аз може да се върти на индекс
че ще се търси,

1192
00:51:55,950 --> 00:52:00,760
струпване на датата на
производство на конкретната част.

1193
00:52:00,760 --> 00:52:03,930
Така че, ако ми плот ниво е
вече сегментира от производителя,

1194
00:52:03,930 --> 00:52:07,655
може би това е била разположена върху част ID, I
може да създаде индекс на разстояние, че на маса

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

1196
00:52:11,140 --> 00:52:14,490
И по този начин мога да кажа, че всичко,
е произведен между тези дати,

1197
00:52:14,490 --> 00:52:16,804
Имам нужда да тегли от линията.

1198
00:52:16,804 --> 00:52:18,220
Така че това е местен вторичния индекс.

1199
00:52:18,220 --> 00:52:22,280
>> Това има за последица
ограничаване си хеш ключ пространство.

1200
00:52:22,280 --> 00:52:24,360
Защото те съжителствуват
по същия съхранение възел,

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

1202
00:52:26,860 --> 00:52:28,950
DynamoDB, под
маси, ще си поделят

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

1204
00:52:31,380 --> 00:52:34,760
Когато поставите 10 участия на данни в, ние
отидете [PhH], и ние добавяме друг възел.

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

1206
00:52:38,120 --> 00:52:42,070
>> Ние няма да се раздели на LSI
върху множество дялове.

1207
00:52:42,070 --> 00:52:43,200
Ние ще се раздели масата.

1208
00:52:43,200 --> 00:52:44,679
Но ние няма да се раздели на LSI.

1209
00:52:44,679 --> 00:52:46,470
Така че това е нещо,
важно да се разбере

1210
00:52:46,470 --> 00:52:50,070
е, ако правиш много,
много, много големи струпвания,

1211
00:52:50,070 --> 00:52:53,860
След това започваш да бъде ограничена
до 10 гигабайта на вашия 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
Multi-лайстни?

1239
00:54:09,340 --> 00:54:10,200
>> Рик 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
защото те са създаване
тези ginormous струпвания

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

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

1280
00:55:57,070 --> 00:55:59,090
Всяка част е с уникален сериен номер.

1281
00:55:59,090 --> 00:56:00,975
Аз използвам сериен номер като хашиш.

1282
00:56:00,975 --> 00:56:01,600
Красиво е.

1283
00:56:01,600 --> 00:56:04,160
Сурова My таблица данни се разпространяват
всички в ключов пространство.

1284
00:56:04,160 --> 00:56:05,930
My [? пиша?]
[? поглъщане?] е страхотно.

1285
00:56:05,930 --> 00:56:07,876
Аз отнеме много данни.

1286
00:56:07,876 --> 00:56:09,500
След това, което те правят, е те създават GSI.

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

1288
00:56:12,666 --> 00:56:15,060
Е, всички изведнъж съм
като един милиард редове,

1289
00:56:15,060 --> 00:56:17,550
и да ги натъпча върху
един възел, защото когато

1290
00:56:17,550 --> 00:56:21,170
Аз се обединят като
производител ID като хашиш,

1291
00:56:21,170 --> 00:56:25,410
и номера на частта, като интервала,
тогава всички изведнъж съм

1292
00:56:25,410 --> 00:56:30,530
извеждайки един милиард части в това, което
този производител ме избави.

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

1294
00:56:34,447 --> 00:56:36,030
отново, защото аз съм с чук един възел.

1295
00:56:36,030 --> 00:56:38,350
Слагам всичко това
вмъква в един възел.

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

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

1298
00:56:43,479 --> 00:56:45,770
И това е един от проблемите,
че аз винаги работя.

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

1300
00:56:49,590 --> 00:56:52,330
да бъде в състояние да прокара всички онези,
редове в един възел.

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

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

1303
00:57:00,180 --> 00:57:02,980
Така че моят вложка процент ще
падне върху първичната таблица

1304
00:57:02,980 --> 00:57:06,230
като моя GSI се опитва да се справи.

1305
00:57:06,230 --> 00:57:08,850
>> Добре, така е GSI, LSI е,
кой трябва да използвам?

1306
00:57:08,850 --> 00:57:12,290
LSI са последователни.

1307
00:57:12,290 --> 00:57:13,750
GSI са в крайна сметка последователно.

1308
00:57:13,750 --> 00:57:17,490
Ако това е ОК, аз препоръчваме да използвате
GSI, те са много по-гъвкави.

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

1310
00:57:20,270 --> 00:57:27,040
И ако размерът на данни на хеш ключове в
вашата колекция надхвърля 10 гигабайта,

1311
00:57:27,040 --> 00:57:31,050
тогава вие ще искате да използвате, че
GSI, защото това е просто един твърд лимит.

1312
00:57:31,050 --> 00:57:32,035
>> Добре де, мащабиране.

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

1314
00:57:35,210 --> 00:57:37,460
Пропускателна в Динамо DB, вие
разпоредба, могат да [недоловим]

1315
00:57:37,460 --> 00:57:38,680
пропускателна способност до масата.

1316
00:57:38,680 --> 00:57:42,740
Ние имаме клиенти, които имат
провизирани 60 billion--

1317
00:57:42,740 --> 00:57:45,970
правят 60 милиарда заявки, редовно
работещ на над един милион заявки

1318
00:57:45,970 --> 00:57:47,790
в секунда на нашите маси.

1319
00:57:47,790 --> 00:57:50,360
Има наистина няма
теоретична граница колко

1320
00:57:50,360 --> 00:57:53,730
и колко бързо масата
може да работи в Динамо DB.

1321
00:57:53,730 --> 00:57:55,920
Има някои, меко
ограничения на профила си

1322
00:57:55,920 --> 00:57:58,170
че ще се постави там, така че
че да не се побърка.

1323
00:57:58,170 --> 00:58:00,070
Ако искате повече от
че не е проблем.

1324
00:58:00,070 --> 00:58:00,820
Ти дойде да ни каже.

1325
00:58:00,820 --> 00:58:02,810
Ние ще се появи на циферблата.

1326
00:58:02,810 --> 00:58:08,210
>> Всяка сметка се ограничава до известна степен
във всеки сервиз, само на разстояние бухалката

1327
00:58:08,210 --> 00:58:11,920
така че хората не полудяват
самите получите в беда.

1328
00:58:11,920 --> 00:58:12,840
Няма ограничение в размера.

1329
00:58:12,840 --> 00:58:14,940
Можете да поставите произволен брой
на елементи на една маса.

1330
00:58:14,940 --> 00:58:17,620
Размерът на даден елемент е
ограничени до 400 килобайта всеки,

1331
00:58:17,620 --> 00:58:20,050
че не би било позиция атрибути.

1332
00:58:20,050 --> 00:58:24,200
Така сумата от всички атрибути
се ограничава до 400 килобайта.

1333
00:58:24,200 --> 00:58:27,300
И след това отново, ние имаме
това малко LSI въпрос

1334
00:58:27,300 --> 00:58:30,405
с ограничението от 10 гигабайт в хеш.

1335
00:58:30,405 --> 00:58:33,280
АУДИТОРИЯ: Малък брой, аз съм липсва
това, което ми казваш, че is--

1336
00:58:33,280 --> 00:58:36,830
АУДИТОРИЯ: О, 400 килобайт
е максималният размер за всяка позиция.

1337
00:58:36,830 --> 00:58:39,570
Така че даден елемент има всички атрибути.

1338
00:58:39,570 --> 00:58:43,950
Така че 400 к е общият размер
на тази позиция, на 400 килобайта.

1339
00:58:43,950 --> 00:58:46,170
Така че на всички атрибути
Смесените, всички данни,

1340
00:58:46,170 --> 00:58:49,140
това е във всички тези атрибути,
навити в общия размер,

1341
00:58:49,140 --> 00:58:51,140
Понастоящем днес границата на т е 400 к.

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

1343
00:58:54,390 --> 00:58:57,046
Така мащабиране отново, постигната
чрез разделяне.

1344
00:58:57,046 --> 00:58:58,920
Пропускателна се провизират
на нивото на масата.

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

1346
00:59:00,160 --> 00:59:02,400
Запознати сме капацитет
и пишат капацитет.

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

1348
00:59:05,530 --> 00:59:08,640
Мярка RCU е строго последователна чете.

1349
00:59:08,640 --> 00:59:13,005
ОК, така че ако сте казвайки Искам 1000
RCU на тези, които са строго последователна,

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

1351
00:59:14,130 --> 00:59:17,130
Ако кажете, аз искам
евентуална последователна прочитания,

1352
00:59:17,130 --> 00:59:19,402
можете разпоредба 1000
RCU си, ти започваш

1353
00:59:19,402 --> 00:59:21,840
за да получите 2000 в крайна сметка
последователна чете.

1354
00:59:21,840 --> 00:59:25,940
И половината от цената за тези,
в крайна сметка се състои в чете.

1355
00:59:25,940 --> 00:59:28,520
>> Отново, коригирана
независимо един от друг.

1356
00:59:28,520 --> 00:59:32,900
И те имат throughput--
Ако консумирате 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
Heat картата ми казва как сте
достъп до вашата ключова пространство.

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-- и това не е само Dynamo 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
И това е извличане на максимума
от Dynamo DB пропускателна

1414
01:01:54,260 --> 01:01:56,176
но това е наистина се
максимума от NoSQL.

1415
01:01:56,176 --> 01:01:58,740
Това не е ограничено до Dynamo.

1416
01:01:58,740 --> 01:02:02,050
Това е definitely-- I
се използва за работа в Монго.

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
база данни, по-специално Dynamo DB,

1420
01:02:10,320 --> 01:02:13,320
Искате ли да създадете таблиците
където елементът на хеш бутона има

1421
01:02:13,320 --> 01:02:18,590
голям брой различни стойности,
висока степен на кардиналност.

1422
01:02:18,590 --> 01:02:22,530
Защото това означава, че аз пиша
да много различни кофи.

1423
01:02:22,530 --> 01:02:24,870
>> Колкото повече кофи аз съм
писмено да, толкова по-вероятно

1424
01:02:24,870 --> 01:02:29,100
Аз съм за да се разпространи, че пиша товар или
Прочети зареди изложени в множество възли,

1425
01:02:29,100 --> 01:02:33,560
толкова по-вероятно съм да има
висока производителност на масата.

1426
01:02:33,560 --> 01:02:37,440
И тогава аз искам стойностите, които се
исканата сравнително равномерно във времето

1427
01:02:37,440 --> 01:02:39,430
и равномерно, както на случаен принцип, колкото е възможно.

1428
01:02:39,430 --> 01:02:42,410
Е, това е нещо интересно,
защото аз наистина не може да

1429
01:02:42,410 --> 01:02:43,960
контрол, когато потребителите идват.

1430
01:02:43,960 --> 01:02:47,645
Така че е достатъчно да кажа, ако ние се разпространи
нещата в цялата ключова пространство,

1431
01:02:47,645 --> 01:02:49,270
ние най-вероятно ще бъде в по-добра форма.

1432
01:02:49,270 --> 01:02:51,522
>> Има известна
период от време за доставка

1433
01:02:51,522 --> 01:02:53,230
че ти няма
да бъде в състояние контрол.

1434
01:02:53,230 --> 01:02:55,438
Но тези, които са наистина най-
две измерения, които имаме,

1435
01:02:55,438 --> 01:02:58,800
пространство, достъп до равномерно
разпространението, време, искания

1436
01:02:58,800 --> 01:03:01,040
пристигащи равномерно разположени във времето.

1437
01:03:01,040 --> 01:03:03,110
И ако тези две
условия са спазени,

1438
01:03:03,110 --> 01:03:05,610
тогава това е за какво става
ще изглежда.

1439
01:03:05,610 --> 01:03:07,890
Това е много по-хубав.

1440
01:03:07,890 --> 01:03:08,890
Ние сме наистина щастливи тук.

1441
01:03:08,890 --> 01:03:10,432
Имаме много дори модел достъп.

1442
01:03:10,432 --> 01:03:13,098
Да, може би сте се
лек натиск всеки сега и тогава,

1443
01:03:13,098 --> 01:03:14,830
но нищо наистина твърде обширна.

1444
01:03:14,830 --> 01:03:17,660
Така че това е невероятно колко пъти,
когато се работи с клиенти,

1445
01:03:17,660 --> 01:03:20,670
че първата графика с големия червен
бар и всичко, което грозно жълто това е

1446
01:03:20,670 --> 01:03:23,147
по цялото място, ние
се свърши с упражняването

1447
01:03:23,147 --> 01:03:24,980
след няколко месеца
на повторно архитектура,

1448
01:03:24,980 --> 01:03:28,050
те работите точно същото
натовареността на точно същото натоварване.

1449
01:03:28,050 --> 01:03:30,140
И това е, което го гледа като сега.

1450
01:03:30,140 --> 01:03:36,600
Така че това, което получавате с NoSQL е
схема данни, която е абсолютно

1451
01:03:36,600 --> 01:03:38,510
обвързани с модела за достъп.

1452
01:03:38,510 --> 01:03:42,170
>> И вие можете да оптимизирате, че схемата на данни
да подкрепя този модел достъп.

1453
01:03:42,170 --> 01:03:45,490
Ако не го направите, тогава започваш
за да видите тези видове проблеми

1454
01:03:45,490 --> 01:03:46,710
с тези горещи клавиши.

1455
01:03:46,710 --> 01:03:50,518
>> АУДИТОРИЯ: Е, неизбежно някои места
ще бъде по-горещо, отколкото други.

1456
01:03:50,518 --> 01:03:51,450
>> Рик 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
Така че те използват Dynamo DB за това.

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

1492
01:05:18,131 --> 01:05:21,120
Те са в състояние да направят цялата си
заявки, сортировка всички тези данни,

1493
01:05:21,120 --> 01:05:26,130
и се получи, че добавката линк към които
рекламодатели в рамките на 10 милисекунди.

1494
01:05:26,130 --> 01:05:29,800
Това е наистина доста феноменален
изпълнение, които те имат.

1495
01:05:29,800 --> 01:05:36,210
>> Тези момчета actually--
са тези момчета.

1496
01:05:36,210 --> 01:05:38,010
Аз не съм сигурен дали това е тези момчета.

1497
01:05:38,010 --> 01:05:40,127
Може да е тези момчета.

1498
01:05:40,127 --> 01:05:42,210
По принцип us-- казал не, аз
не мисля, че ги е бил.

1499
01:05:42,210 --> 01:05:43,000
Мисля, че беше някой друг.

1500
01:05:43,000 --> 01:05:44,750
Работех с
клиент, който ми каза,

1501
01:05:44,750 --> 01:05:47,040
че сега, че те имат
отишъл в Динамо DB, те са

1502
01:05:47,040 --> 01:05:50,330
харчат повече пари за закуски за
техния екип за развитие на всеки месец

1503
01:05:50,330 --> 01:05:52,886
отколкото те харчат за тяхната база данни.

1504
01:05:52,886 --> 01:05:54,760
Така че ще ви дам един
идея за намаляване на разходите

1505
01:05:54,760 --> 01:05:57,889
че можете да получите в Динамо DB е огромна.

1506
01:05:57,889 --> 01:05:59,430
Добре, dropcam е друга компания.

1507
01:05:59,430 --> 01:06:02,138
Това момче е вид of-- ако смятате
на интернет на нещата, dropcam

1508
01:06:02,138 --> 01:06:05,150
е основно видео охрана интернет.

1509
01:06:05,150 --> 01:06:06,660
Слагаш фотоапарата си там.

1510
01:06:06,660 --> 01:06:08,180
Camera разполага с детектор за движение.

1511
01:06:08,180 --> 01:06:10,290
Някой идва заедно,
задейства точка бияч.

1512
01:06:10,290 --> 01:06:13,540
Camera започва да записва за известно време, докато
тя не открие всяко движение вече.

1513
01:06:13,540 --> 01:06:15,310
Поставя че видео до по интернет.

1514
01:06:15,310 --> 01:06:19,800
>> Dropcam е компания, която е
основно преминах на Динамо DB

1515
01:06:19,800 --> 01:06:22,200
защото те бяха изпитват
огромни болки на растежа.

1516
01:06:22,200 --> 01:06:25,820
И това, което те ни казаха,
Изведнъж петабайта данни.

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
И тогава те имат
Dynamo DB записи, които

1522
01:06:41,990 --> 01:06:44,070
посоча хората към тези S3 три обекта.

1523
01:06:44,070 --> 01:06:47,070
Когато те трябва да погледнете на видео,
те гледам записа в Динамо DB.

1524
01:06:47,070 --> 01:06:47,903
Те кликнете върху линка.

1525
01:06:47,903 --> 01:06:49,770
Те събарят видеото от S3.

1526
01:06:49,770 --> 01:06:51,590
Така че това е вид как изглежда това.

1527
01:06:51,590 --> 01:06:53,580
И това е направо от техния отбор.

1528
01:06:53,580 --> 01:06:56,010
>> Dynamo DB намалява тяхната
време за доставка за видео събития

1529
01:06:56,010 --> 01:06:57,590
от пет до 10 секунди.

1530
01:06:57,590 --> 01:07:00,470
В напреднала релационна магазин,
те използват да трябва да отида и да се изпълни

1531
01:07:00,470 --> 01:07:03,780
множество сложни заявки, за да разбера
кои клипове да събарят,

1532
01:07:03,780 --> 01:07:06,690
до по-малко от 50 милисекунди.

1533
01:07:06,690 --> 01:07:08,990
Така че това е невероятно, невероятно
колко производителност

1534
01:07:08,990 --> 01:07:12,990
можете да получите при оптимизиране и
настроите основната база данни

1535
01:07:12,990 --> 01:07:15,110
за подпомагане на схемата за достъп.

1536
01:07:15,110 --> 01:07:20,500
Halfbrick, тези момчета, какво е това,
Fruit Ninja предполагам е тяхното нещо.

1537
01:07:20,500 --> 01:07:22,590
Това всички писти на Динамо DB.

1538
01:07:22,590 --> 01:07:26,810
И тези момчета, те са чудесен
развитие на екипа, голямо развитие

1539
01:07:26,810 --> 01:07:27,670
магазин.

1540
01:07:27,670 --> 01:07:29,364
>> Не е добър отбор операции.

1541
01:07:29,364 --> 01:07:31,280
Те не са имали много
на експлоатационните ресурси.

1542
01:07:31,280 --> 01:07:33,940
Те се бореха се опитват да поддържат
приложението им инфраструктура нагоре

1543
01:07:33,940 --> 01:07:34,290
и работи.

1544
01:07:34,290 --> 01:07:35,000
Те дойдоха при нас.

1545
01:07:35,000 --> 01:07:36,251
Гледаха, че Динамо DB.

1546
01:07:36,251 --> 01:07:37,291
Те казаха, че това е за нас.

1547
01:07:37,291 --> 01:07:39,470
Те построили целия им
прилагането рамка върху него.

1548
01:07:39,470 --> 01:07:43,640
Някои наистина хубави коментари тук
от екипа на тяхната способност

1549
01:07:43,640 --> 01:07:46,800
до сега се съсредоточи върху изграждане
играта, а не

1550
01:07:46,800 --> 01:07:49,010
се налага да се запази
инфраструктура, която

1551
01:07:49,010 --> 01:07:51,910
се превръща в огромно количество
на надземната за отбора си.

1552
01:07:51,910 --> 01:07:56,170
Така че това е нещо, на that--
полза, което получавате от Dynamo DB.

1553
01:07:56,170 --> 01:08:00,930
>> Добре, заемайки
моделиране на данни тук.

1554
01:08:00,930 --> 01:08:03,440
И ние говорихме малко за
това 12:59, един към много,

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
В Динамо DB ние използваме
индекси, най-общо казано,

1558
01:08:10,500 --> 01:08:12,910
за да завъртите данните от
един аромат на друга.

1559
01:08:12,910 --> 01:08:15,210
Hash ключове, ключове обсег, както и индексите.

1560
01:08:15,210 --> 01:08:18,540
>> В този конкретен
Например, тъй като повечето държави

1561
01:08:18,540 --> 01:08:23,802
има изискване за лицензиране, които
само един лиценз на водача на човек.

1562
01:08:23,802 --> 01:08:26,510
Вие не можете да отидете да се драйвер за двама
лицензии в състояние на Бостън.

1563
01:08:26,510 --> 01:08:27,500
Не мога да го направя в Тексас.

1564
01:08:27,500 --> 01:08:28,708
Това е вид на такъв, какъвто е.

1565
01:08:28,708 --> 01:08:32,779
И така, в DMV, имаме заявки, ние
искам да гледам шофьорската книжка

1566
01:08:32,779 --> 01:08:35,180
от номера на социалната сигурност.

1567
01:08:35,180 --> 01:08:39,990
Искам да се запознаете с подробностите на потребителите
по брой шофьорската книжка.

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

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

1570
01:08:47,830 --> 01:08:49,859
Сега на тази таблица I
може да се определи, че GSI

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

1572
01:08:53,370 --> 01:08:54,252
всички други елементи.

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

1574
01:08:57,210 --> 01:08:59,609
Номер на сигурност, което мога
задава въпроси към главната маса.

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

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

1577
01:09:05,735 --> 01:09:08,689
Този модел е, че един
една връзка.

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

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

1580
01:09:13,979 --> 01:09:16,450
One за мнозина е основно
Вашата хеш бутона обхват.

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

1582
01:09:20,510 --> 01:09:23,880
Данни Monitor предлага в редовна
интервал, като интернет на нещата.

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
>> Така че това е вид построена
в таблицата в Динамо DB.

1595
01:10:04,600 --> 01:10:07,290
Когато се определи хеш
и обхват тона маса, аз съм

1596
01:10:07,290 --> 01:10:09,240
определяща един към много отношения.

1597
01:10:09,240 --> 01:10:12,770
Това е връзката родител-дете.

1598
01:10:12,770 --> 01:10:14,620
>> Нека поговорим за мнозина
в много отношения.

1599
01:10:14,620 --> 01:10:19,170
И за този конкретен пример,
отново, ние ще използваме GSI е.

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

1601
01:10:23,500 --> 01:10:26,500
Искам да разберете, че всички игри
той е регистриран за или да играете инча

1602
01:10:26,500 --> 01:10:29,600
И за дадена игра, I
искате да намерите всички потребители.

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
I сверки с 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
И в зависимост от случая на използване, I
Може да се наложи на индекса или аз не вали.

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

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

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

1624
01:11:18,390 --> 01:11:20,840
Така че всичко зависи от това
това, което аз се опитвам да направя

1625
01:11:20,840 --> 01:11:24,550
и това, което аз се опитвам да се получи завършен.

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

1627
01:11:28,000 --> 01:11:31,460
Това става малко, вероятно,
по-дълбоко, отколкото имаме нужда, за да отидат в.

1628
01:11:31,460 --> 01:11:33,710
Нека поговорим малко
около богато изразяване заявка.

1629
01:11:33,710 --> 01:11:37,831
Така че в Динамо DB имаме
способността да се създаде

1630
01:11:37,831 --> 01:11:39,330
това, което наричаме прожекционни изрази.

1631
01:11:39,330 --> 01:11:42,660
Проекционни изрази са просто
бране на полетата или стойностите

1632
01:11:42,660 --> 01:11:44,290
който искате да покажете.

1633
01:11:44,290 --> 01:11:46,000
OK, за да мога да направите избор.

1634
01:11:46,000 --> 01:11:48,010
I направи заявка срещу Динамо DB.

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
Това е един и същи вид на нещо, което в
Dynamo DB или друг NoSQL бази данни.

1644
01:12:09,070 --> 01:12:14,510
Филтър изрази ми позволяват да
основно намали резултата остави.

1645
01:12:14,510 --> 01:12:15,540
Така че аз се направи запитване.

1646
01:12:15,540 --> 01:12:17,260
Запитване може да се върне с 500 позиции.

1647
01:12:17,260 --> 01:12:20,255
Но аз искам само елементите, които
имат атрибут, който казва това.

1648
01:12:20,255 --> 01:12:23,380
ОК, така че нека да филтрирате тези позиции
които не отговарят на този конкретен въпрос.

1649
01:12:23,380 --> 01:12:25,540
Така че ние имаме филтърни изрази.

1650
01:12:25,540 --> 01:12:28,310
>> Филтър изрази могат да
да се движат по всяко атрибут.

1651
01:12:28,310 --> 01:12:30,260
Те не са искали заявки обсег на действие.

1652
01:12:30,260 --> 01:12:32,690
Вдигнете заявки са по-селективни.

1653
01:12:32,690 --> 01:12:36,470
Филтър заявки изискват от мен да отида
се определят цели резултатите и след това

1654
01:12:36,470 --> 01:12:39,170
обособяването на данните не искам.

1655
01:12:39,170 --> 01:12:40,660
Защо е важно?

1656
01:12:40,660 --> 01:12:42,770
Защото всичко се чете.

1657
01:12:42,770 --> 01:12:46,597
В заявка, аз отивам да се чете и
това ще бъде една гигантска за данни.

1658
01:12:46,597 --> 01:12:48,430
И тогава аз ще
обособяването, което ми трябва.

1659
01:12:48,430 --> 01:12:52,080
И ако аз съм само дерогиране
Няколко реда, след това е ОК.

1660
01:12:52,080 --> 01:12:53,620
Това не е толкова неефективна.

1661
01:12:53,620 --> 01:12:57,800
>> Но ако аз съм четене цял куп
данни, само за обособяването един елемент,

1662
01:12:57,800 --> 01:13:01,490
След това аз ще бъде по-добре
на разстояние с помощта на заявка гама,

1663
01:13:01,490 --> 01:13:03,030
защото това е много по-селективни.

1664
01:13:03,030 --> 01:13:06,330
Това ще ми спести много
пари, защото аз плащам за това четиво.

1665
01:13:06,330 --> 01:13:10,430
Ако резултатите, че се връща
пресичане на тел може да бъде по-малък,

1666
01:13:10,430 --> 01:13:11,890
но аз съм плащат за четене.

1667
01:13:11,890 --> 01:13:14,340
Така че разбирам как
вие получавате данните.

1668
01:13:14,340 --> 01:13:16,420
Това е много важно в Динамо DB.

1669
01:13:16,420 --> 01:13:19,710
>> Условни изрази, това е, което
може да се нарече оптимистично заключване.

1670
01:13:19,710 --> 01:13:28,470
Актуализация, ако е налице, или ако тази стойност
е еквивалентно на това, което аз зададени.

1671
01:13:28,470 --> 01:13:31,494
И ако имам време печата на
запис, че може да прочете данните.

1672
01:13:31,494 --> 01:13:32,535
Аз може да се промени, че данните.

1673
01:13:32,535 --> 01:13:35,030
Мога да отида на запис
обратно данни към базата данни.

1674
01:13:35,030 --> 01:13:38,100
Ако някой се е променило записа,
клеймото може да са се променили.

1675
01:13:38,100 --> 01:13:40,370
И по този начин ми условно
актуализация може да се каже актуализация

1676
01:13:40,370 --> 01:13:42,340
ако клеймото равнява това.

1677
01:13:42,340 --> 01:13:46,290
Или актуализацията ще се провали, защото някого
обновява записа междувременно.

1678
01:13:46,290 --> 01:13:48,290
>> Това е, което ние наричаме оптимистично заключване.

1679
01:13:48,290 --> 01:13:50,670
Това означава, че някой
може да дойде и да я промените,

1680
01:13:50,670 --> 01:13:53,100
и аз отивам да го открие
когато се върна, за да пиша.

1681
01:13:53,100 --> 01:13:56,106
И тогава всъщност мога да чета, че
данни и да кажа, о, той се промени това.

1682
01:13:56,106 --> 01:13:57,230
Трябва да се отчете, че.

1683
01:13:57,230 --> 01:14:00,490
И мога да променя данните в моята
записва и прилага друга актуализация.

1684
01:14:00,490 --> 01:14:04,330
Така че можете да хванете тези частичното
актуализации, които се случват между времето

1685
01:14:04,330 --> 01:14:08,740
да прочетете на данни и
време може да се напише данните.

1686
01:14:08,740 --> 01:14:11,520
>> АУДИТОРИЯ: И филтъра
изразяване всъщност не означава,

1687
01:14:11,520 --> 01:14:13,020
в броя или not--

1688
01:14:13,020 --> 01:14:14,316
>> [Вмъкване VOICES]

1689
01:14:14,316 --> 01:14:16,232
Рик Houlihan: Не искам
получите твърде много в това.

1690
01:14:16,232 --> 01:14:17,700
Това е запазена дума.

1691
01:14:17,700 --> 01:14:20,130
Изгледът на паунд е запазено
ключова дума в Динамо DB.

1692
01:14:20,130 --> 01:14:24,500
Всяка база данни има свой запазени
имена за колекции не можете да използвате.

1693
01:14:24,500 --> 01:14:27,240
Dynamo DB, ако посочите
една лира в предната част на този,

1694
01:14:27,240 --> 01:14:29,310
можете да зададете тези имена до горе.

1695
01:14:29,310 --> 01:14:31,840
Това е посочена стойност.

1696
01:14:31,840 --> 01:14:34,880
Това вероятно не е най-добрият синтаксис за
има до там за тази дискусия,

1697
01:14:34,880 --> 01:14:38,090
тъй като попадне в някои real--
Аз щях да се говори по-

1698
01:14:38,090 --> 01:14:41,360
за това по-дълбоко ниво.

1699
01:14:41,360 --> 01:14:46,130
>> Но е достатъчно да кажа, това би могло
да сканирате заявка, където те views--

1700
01:14:46,130 --> 01:14:50,190
нито гледка паунд е по-голямо от 10.

1701
01:14:50,190 --> 01:14:54,660
Тя е цифрова стойност, да.

1702
01:14:54,660 --> 01:14:57,322
Ако искате, можем да говорим за
че след дискусията.

1703
01:14:57,322 --> 01:15:00,030
Добре, така че ние сме заемайки
някои сценарии в най-добрите практики

1704
01:15:00,030 --> 01:15:02,000
къде отиваме да говори
за някои приложения тук.

1705
01:15:02,000 --> 01:15:03,810
Какви са случаите на употреба за Dynamo DB.

1706
01:15:03,810 --> 01:15:06,120
Какви са дизайна
модели в Динамо DB.

1707
01:15:06,120 --> 01:15:09,110
>> И първият, ние ще
се говори за е интернет на нещата.

1708
01:15:09,110 --> 01:15:15,010
Така получаваме много of-- Предполагам,
това, което е 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
Така че може би всеки полунощ I ролка
моята маса над на нова маса

1730
01:16:21,150 --> 01:16:22,430
и аз deprovision тази таблица.

1731
01:16:22,430 --> 01:16:26,440
И аз ще взема и дистанционното управление на
Определяне на инвалидни колички, защото 24 часа по-късно

1732
01:16:26,440 --> 01:16:28,630
Аз не бягам толкова,
на заявки, че данните.

1733
01:16:28,630 --> 01:16:30,200
Така че аз отивам да се спестят пари.

1734
01:16:30,200 --> 01:16:32,940
И може би 30 дни по-късно аз не правя
дори трябва да се грижи за всичко това.

1735
01:16:32,940 --> 01:16:35,020
Можех да взема за инвалидни колички-те
чак до един,

1736
01:16:35,020 --> 01:16:36,990
защото вие знаете какво, това е
никога няма да се записва.

1737
01:16:36,990 --> 01:16:38,300
Данните са на 30 дни.

1738
01:16:38,300 --> 01:16:40,000
Той никога не се променя.

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

1740
01:16:44,200 --> 01:16:49,372
И аз съм спестяване на много пари за това
данни, а само да плащат за моите горещи данни.

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

1742
01:16:52,330 --> 01:16:54,716
данни, идващи в по обем.

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

1744
01:16:55,590 --> 01:16:58,010
Сега, аз може просто да го даде под наем
всички отидете на една и съща маса

1745
01:16:58,010 --> 01:16:59,461
и просто да споделите тази маса расте.

1746
01:16:59,461 --> 01:17:01,460
В крайна сметка, аз отивам да
виж проблеми с производителността.

1747
01:17:01,460 --> 01:17:04,060
Отивам да се наложи да започнете да архивирате
някои от тези данни извън масата,

1748
01:17:04,060 --> 01:17:04,720
какво не.

1749
01:17:04,720 --> 01:17:07,010
>> Нека по-добре
проектира вашата кандидатура

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

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

1752
01:17:11,460 --> 01:17:13,580
В полунощ всяка вечер
търкалянето на масата.

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

1754
01:17:17,170 --> 01:17:20,277
След това редовно съм
обадите на данни извън масата.

1755
01:17:20,277 --> 01:17:22,360
Аз съм го подстригване с
Cron работни места и аз съм го прати

1756
01:17:22,360 --> 01:17:24,160
върху тези други таблици,
каквото ви трябва.

1757
01:17:24,160 --> 01:17:25,940
Така че, ако преобръщане работи, това е страхотно.

1758
01:17:25,940 --> 01:17:27,080
Ако не, отрежете го.

1759
01:17:27,080 --> 01:17:29,640
Но нека да се запази, че горещо данни
далеч от вашите студени данни.

1760
01:17:29,640 --> 01:17:32,535
Това ще ви спести много пари и
направите своя маси по-ефективните.

1761
01:17:32,535 --> 01:17:35,960

1762
01:17:35,960 --> 01:17:38,210
Така че следващото нещо, което ние ще говорим
за е продуктов каталог.

1763
01:17:38,210 --> 01:17:42,000
Каталог на стоките е
доста често срещано при употреба.

1764
01:17:42,000 --> 01:17:46,600
Това всъщност е много общ модел
че ние ще видим в най-различни неща.

1765
01:17:46,600 --> 01:17:48,870
Знаеш ли, Twitter за
Например, една гореща туит.

1766
01:17:48,870 --> 01:17:51,280
Всеки идва и
измъкна, че туит.

1767
01:17:51,280 --> 01:17:52,680
Каталог на стоките, имам продажба.

1768
01:17:52,680 --> 01:17:54,120
Имам гореща продажба.

1769
01:17:54,120 --> 01:17:57,277
Имам 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
Cache, ще ви постави в основата на по-памет
дял в предната част на базата данни.

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
Email, всички ние използваме имейл.

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
И първия подход към този
може да е, да речем, OK, няма проблем.

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
>> OK, нека да отидем с
в крайна сметка последователно чете.

1826
01:20:24,450 --> 01:20:28,640
Аз съм все още яде 1600 RCU си
само за да прочетете Давид пощенска кутия.

1827
01:20:28,640 --> 01:20:29,950
Ох.

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

1829
01:20:31,980 --> 01:20:35,340
Ако аз съм в имейл приложение и
Търся в моята пощенска кутия,

1830
01:20:35,340 --> 01:20:39,680
и аз гледам на тялото на всяко съобщение,
не, аз съм гледам в обобщенията.

1831
01:20:39,680 --> 01:20:41,850
Търся в само заглавията.

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

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

1834
01:20:49,470 --> 01:20:50,890
Това е в моята пощенска кутия GSI.

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

1836
01:20:53,800 --> 01:20:56,790
ID на съобщението, което сочи
обратно на масата за съобщения

1837
01:20:56,790 --> 01:20:57,850
къде мога да получа тялото.

1838
01:20:57,850 --> 01:21:01,260

1839
01:21:01,260 --> 01:21:04,420
Е, това ще бъде рекордно IDs.

1840
01:21:04,420 --> 01:21:09,850
Те ще посоча обратно към
т IDs на масата за Dynamo DB.

1841
01:21:09,850 --> 01:21:12,220
Всеки индекс винаги creates--
Винаги има елемента

1842
01:21:12,220 --> 01:21:15,750
ID като част of-- че
идва с индекса.

1843
01:21:15,750 --> 01:21:17,414
>> Всичко е наред.

1844
01:21:17,414 --> 01:21:19,080
АУДИТОРИЯ: Това го казва къде се съхранява?

1845
01:21:19,080 --> 01:21:21,420
Рик 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
I отиде заедно и аз кликнете върху съобщението,
това е, когато аз трябва да отида да тялото,

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
Hash на подателя.

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

1876
01:22:39,612 --> 01:22:41,570
И това е basically-- ние
има тази хубава съобщения

1877
01:22:41,570 --> 01:22:45,870
таблица, която е се разпространява добре, защото
това е само хеш, сегментира съобщение ID.

1878
01:22:45,870 --> 01:22:51,750
И ние имаме два индекса, че
въртящ се изключва от тази таблица.

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

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

1881
01:22:57,910 --> 01:23:00,700
Разделя вертикално,
разделя тези таблици.

1882
01:23:00,700 --> 01:23:03,150
Не четете данни не е нужно да.

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

1884
01:23:04,850 --> 01:23:06,990
Ние всички искали игри.

1885
01:23:06,990 --> 01:23:10,902
Най-малко ми харесва игри след това.

1886
01:23:10,902 --> 01:23:12,735
Така че някои от нещата,
че ние се справят с, когато

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

1888
01:23:14,193 --> 01:23:16,999
Gaming тези дни, особено мобилна
игри, е всичко за мислене.

1889
01:23:16,999 --> 01:23:19,540
И аз отивам да се върти тук
малко далеч от DynamoDB.

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

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

1892
01:23:24,240 --> 01:23:28,930
>> Но идеята за игри е да се мисли,
за по отношение на APIs, APIs, които са,

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 APIs.

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
Binary данни актив, тая информация
може и да не седят в базата данни.

1901
01:23:52,542 --> 01:23:54,250
Това може да седне в
обект магазин, нали?

1902
01:23:54,250 --> 01:23:56,541
Но на базата данни ще се
в крайна сметка казва системата,

1903
01:23:56,541 --> 01:23:59,140
казвам прилагането
къде да отида да го получи.

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

1905
01:24:03,550 --> 01:24:06,180
и проектирани за висока
наличността и мащабируемост.

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

1907
01:24:09,400 --> 01:24:12,160
>> Така че нека да разгледаме най-
какво прилича това.

1908
01:24:12,160 --> 01:24:16,070
Има ядро ​​задния край,
много ясна.

1909
01:24:16,070 --> 01:24:19,880
Имаме система тук с
наличност няколко зони.

1910
01:24:19,880 --> 01:24:23,780
Ние говорихме за АЗС като being-- мисля,
от тях като отделни центрове за данни.

1911
01:24:23,780 --> 01:24:26,040
Повече от един център на данни
на AZ, но това е ОК,

1912
01:24:26,040 --> 01:24:28,831
Просто мисля за тях като отделни данни
центрове, които са географски

1913
01:24:28,831 --> 01:24:30,090
и вина, изолиран.

1914
01:24:30,090 --> 01:24:32,172
>> Отиваме да имат
Няколко EC2 случаи.

1915
01:24:32,172 --> 01:24:33,880
Отиваме да имат
някои задния край на сървъра.

1916
01:24:33,880 --> 01:24:35,800
Може би ако си наследство
архитектура, ние сме

1917
01:24:35,800 --> 01:24:38,920
използване на това, което наричаме RDS,
релационни бази данни. услуги

1918
01:24:38,920 --> 01:24:42,040
Може да MSSQL, MySQL,
Или нещо такова.

1919
01:24:42,040 --> 01:24:47,080
Това е начина, по който наяждане приложения
са предназначени днес.

1920
01:24:47,080 --> 01:24:49,594
>> Ами ние може да искате да отидете с
това е, когато сме на котлен камък.

1921
01:24:49,594 --> 01:24:51,510
Ние ще вървим напред и да сложи
кофата S3 там.

1922
01:24:51,510 --> 01:24:54,200
И това S3 кофа, вместо да служи
до тези предмети от нашето servers--

1923
01:24:54,200 --> 01:24:55,220
бихме могли да направим това.

1924
01:24:55,220 --> 01:24:57,210
Поставяте всичките си двоичен
обекти на вашите сървъри

1925
01:24:57,210 --> 01:24:59,751
и можете да използвате тези сървъра
инстанции, за да служат на тези данни до.

1926
01:24:59,751 --> 01:25:01,860
Но това е доста скъпо.

1927
01:25:01,860 --> 01:25:05,107
>> По-добър начин да направите е да отидете напред и да
постави тези обекти в S3 кофа.

1928
01:25:05,107 --> 01:25:06,315
S3 е обект на транзакции.

1929
01:25:06,315 --> 01:25:10,860
Той е построен специално за
генерирането на тези видове неща.

1930
01:25:10,860 --> 01:25:13,690
И нека тези клиенти да поискат
директно от тези обекти кофи,

1931
01:25:13,690 --> 01:25:15,390
разтоварят сървърите.

1932
01:25:15,390 --> 01:25:17,020
Така че ние започваме да мащабирате тук.

1933
01:25:17,020 --> 01:25:19,140
>> Сега имаме потребители по целия свят.

1934
01:25:19,140 --> 01:25:19,730
Имам потребители.

1935
01:25:19,730 --> 01:25:23,380
Трябва да има съдържание на местно ниво
разположен в близост до тези потребители, нали?

1936
01:25:23,380 --> 01:25:26,200
Аз създадох S3 кофа
като моя източник хранилище.

1937
01:25:26,200 --> 01:25:29,370
И аз ще отпред, че с
разпределението CloudFront.

1938
01:25:29,370 --> 01:25:31,720
>> CloudFront е CD и
съдържание доставка мрежа.

1939
01:25:31,720 --> 01:25:35,750
По принцип това отнема данни, които сте задали
и всичко това кешира по интернет

1940
01:25:35,750 --> 01:25:39,230
така че потребителите могат да имат навсякъде
много бърза реакция, когато

1941
01:25:39,230 --> 01:25:40,960
те искат тези предмети.

1942
01:25:40,960 --> 01:25:41,960
>> Така че можете да получите представа.

1943
01:25:41,960 --> 01:25:48,230
Ти си вид деблокирането всички
аспекти на AWS тук, за да постигнем това.

1944
01:25:48,230 --> 01:25:50,790
И в крайна сметка, ние изхвърляме
в автомобил мащабиране група.

1945
01:25:50,790 --> 01:25:52,737
Така че нашите AC2 случаи
от нашите играта сървъри,

1946
01:25:52,737 --> 01:25:54,820
тъй като те започват да получите по-зает
и по-богат и по-богат,

1947
01:25:54,820 --> 01:25:57,236
те просто ще се върти друг
Например, върти друг пример,

1948
01:25:57,236 --> 01:25:58,210
върти друга инстанция.

1949
01:25:58,210 --> 01:26:02,090
Така че технологията AWS има, тя
позволява да зададете параметрите

1950
01:26:02,090 --> 01:26:04,650
около което вашите сървъри ще растат.

1951
01:26:04,650 --> 01:26:08,110
Така че можете да имате п брой сървъри
там във всеки даден момент.

1952
01:26:08,110 --> 01:26:11,870
И ако вашият товар отива, те ще
свие, броят ще се свие.

1953
01:26:11,870 --> 01:26:15,250
И ако товарът се връща,
то ще расте обратно, еластично.

1954
01:26:15,250 --> 01:26:17,050
>> Така че това изглежда страхотно.

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

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

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

1958
01:26:23,045 --> 01:26:25,030
Следващата точка налягане
Обикновено хората виждат

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

1960
01:26:28,850 --> 01:26:30,790
Господи, в базата данни
изпълнението е ужасно.

1961
01:26:30,790 --> 01:26:31,932
Как можем да подобрим това?

1962
01:26:31,932 --> 01:26:33,640
Нека се опитаме извеждайки
кеш пред това.

1963
01:26:33,640 --> 01:26:36,780
>> Е, кеш не работи
толкова голяма, в игри, нали?

1964
01:26:36,780 --> 01:26:39,330
За игри, писане е болезнено.

1965
01:26:39,330 --> 01:26:40,930
Игрите са много тежки пишат.

1966
01:26:40,930 --> 01:26:43,610
Cache не работи, когато сте
напиши тежка, защото винаги сте

1967
01:26:43,610 --> 01:26:44,610
Трябва да се актуализира кеша.

1968
01:26:44,610 --> 01:26:47,780
Можете актуализира кеша, това е
без значение да се кешира.

1969
01:26:47,780 --> 01:26:49,780
Това всъщност е само допълнителна работа.

1970
01:26:49,780 --> 01:26:51,970
>> Е, къде да отидем тук?

1971
01:26:51,970 --> 01:26:54,400
Имаш голяма пречка
там долу в базата данни.

1972
01:26:54,400 --> 01:26:57,661
И мястото да отида
Очевидно е разделяне.

1973
01:26:57,661 --> 01:26:59,410
Разделяне не е
лесно да се направи, когато сте

1974
01:26:59,410 --> 01:27:01,900
занимаващи се с релационни бази данни.

1975
01:27:01,900 --> 01:27:05,080
С релационни бази данни, вие сте
отговаря за управлението, ефективно,

1976
01:27:05,080 --> 01:27:06,210
ключовото пространство.

1977
01:27:06,210 --> 01:27:10,527
Искаш да кажеш, потребителите между A и M
отидете тук, между N и Z отида там.

1978
01:27:10,527 --> 01:27:12,360
И вие преминавате
в заявката.

1979
01:27:12,360 --> 01:27:15,000
Така че имаш работа с
този източник дял с данни.

1980
01:27:15,000 --> 01:27:18,670
Имате транзакционни ограничения
които не обхващат дялове.

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

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

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

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

1985
01:27:27,284 --> 01:27:30,930
>> АУДИТОРИЯ: Значи искате да кажете, че
увеличаване на изходните точки ускорява

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

1987
01:27:31,430 --> 01:27:32,513
Рик Houlihan: Повишаване?

1988
01:27:32,513 --> 01:27:33,520
АУДИТОРИЯ: Източник точки.

1989
01:27:33,520 --> 01:27:34,410
Рик Houlihan: Източник точки?

1990
01:27:34,410 --> 01:27:37,500
АУДИТОРИЯ: От информацията,
когато информацията идва от?

1991
01:27:37,500 --> 01:27:38,250
Рик Houlihan: No.

1992
01:27:38,250 --> 01:27:41,820
Това, което казвам, е увеличаване на
брой дялове в хранилището на данни

1993
01:27:41,820 --> 01:27:44,060
подобрява пропускателната способност.

1994
01:27:44,060 --> 01:27:48,300
Така че това, което се случва тук е потребителите
влизат в EC2 инстанция тук,

1995
01:27:48,300 --> 01:27:50,780
добре, ако имам нужда от един потребител
това е A да M, аз ще отида тук.

1996
01:27:50,780 --> 01:27:53,560
От N до р, аз ще отида тук.

1997
01:27:53,560 --> 01:27:55,060
От P до Z, аз ще отида тук.

1998
01:27:55,060 --> 01:27:57,120
>> АУДИТОРИЯ: OK, така че тези, които са
всички съхранявани в различни възли?

1999
01:27:57,120 --> 01:27:57,911
>> Рик 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
Ние може да се хеширане на UserID,
и след това ние имаме набор от играта.

2022
01:28:57,700 --> 01:28:59,960
Така всеки потребител иска да види
цялата игра той е играл

2023
01:28:59,960 --> 01:29:01,770
и всичките му най-добър резултат
във всички минута.

2024
01:29:01,770 --> 01:29:04,000
Така че това е неговата лична класация.

2025
01:29:04,000 --> 01:29:10,010
>> Сега искам да ида и аз искам да get--
така че да получите тези лични класации.

2026
01:29:10,010 --> 01:29:12,827
Това, което искам да направя е да отида да получите
горната оценка за всички потребители.

2027
01:29:12,827 --> 01:29:13,660
Е, как да го правя?

2028
01:29:13,660 --> 01:29:18,070
Когато моят рекорд е сегментира на
на 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
Знаете ли какво, аз отивам да
създадете атрибут наречен Award.

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
Рик Houlihan: Какво е?

2061
01:30:57,680 --> 01:30:58,596
АУДИТОРИЯ: Напишете тежък.

2062
01:30:58,596 --> 01:31:01,270
Рик 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
Рик 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
A много ограничен брой артикули
хора, които намират за да бъде популярен.

2100
01:32:29,390 --> 01:32:31,710
>> Това не е добър модел дизайн.

2101
01:32:31,710 --> 01:32:33,549
Това всъщност е
много лош дизайн модел

2102
01:32:33,549 --> 01:32:36,340
тъй като създава точно това, което ние
Говорихме за която беше горещи клавиши.

2103
01:32:36,340 --> 01:32:38,960
Горещи клавиши са нещо, което не ни харесва.

2104
01:32:38,960 --> 01:32:40,470
>> И как ще се оправя това?

2105
01:32:40,470 --> 01:32:47,640
И наистина, на начина, по който да се определи това е
като се вземат тези кандидатки кофи

2106
01:32:47,640 --> 01:32:51,490
и за всеки кандидат, които имаме,
отиваме да прикрепите случайна стойност,

2107
01:32:51,490 --> 01:32:54,192
нещо, което ние знаем, случайна
стойност между една и 100,

2108
01:32:54,192 --> 01:32:56,620
между 100 и 1000,
или между една и 1000,

2109
01:32:56,620 --> 01:32:59,940
обаче много произволни стойности, които искате да
добавете към края на този кандидат.

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

2111
01:33:01,330 --> 01:33:05,830
Ако аз съм с помощта на ID кандидат
кофата за обединяване на гласа,

2112
01:33:05,830 --> 01:33:08,780
ако съм добавя случаен
брой до края на тази,

2113
01:33:08,780 --> 01:33:12,000
Аз създадох сега 10 кофи, а
сто кофи, хиляда кофи

2114
01:33:12,000 --> 01:33:14,160
че аз съм за струпване на гласове в цяла.

2115
01:33:14,160 --> 01:33:18,030
>> Така че имам милиони, и милиони,
и милиони записи, идващи в

2116
01:33:18,030 --> 01:33:22,050
за тези кандидати, аз съм сега разпространение
тези гласове в цяла A_1 кандидат

2117
01:33:22,050 --> 01:33:24,630
чрез A_100 кандидат, защото
всеки път, когато е гласувано идва,

2118
01:33:24,630 --> 01:33:26,530
Аз съм генериране на случайни
стойност между една и 100.

2119
01:33:26,530 --> 01:33:29,446
Аз съм го лепнали върху края на
кандидат на това лице Гласувам за.

2120
01:33:29,446 --> 01:33:31,120
Аз съм го дъмпинг в тази кофа.

2121
01:33:31,120 --> 01:33:33,910
>> Сега на гърба, аз знам,
че аз имам сто кофи.

2122
01:33:33,910 --> 01:33:36,350
Така че, когато аз искам да отида напред
и агрегиране на гласовете,

2123
01:33:36,350 --> 01:33:38,244
Четох от всички тези кофи.

2124
01:33:38,244 --> 01:33:39,160
Така че аз отида напред и да добавите.

2125
01:33:39,160 --> 01:33:42,410
И тогава аз скатерния събера
където аз изляза и да кажа, хей,

2126
01:33:42,410 --> 01:33:45,399
Знаете ли какво, ключова този кандидат
пространства е над сто кофи.

2127
01:33:45,399 --> 01:33:47,940
Отивам да се съберат всички
гласува от тези стотина кофи.

2128
01:33:47,940 --> 01:33:49,981
Отивам да се обобщи
тях и аз отивам да се каже,

2129
01:33:49,981 --> 01:33:53,830
Кандидат А сега има
Общият брой на х гласуване.

2130
01:33:53,830 --> 01:33:55,690
>> Сега и двете отписването
запитване и заявка за четене

2131
01:33:55,690 --> 01:33:58,160
са разпределена
защото аз пиша цяла

2132
01:33:58,160 --> 01:34:00,320
и аз съм четене през стотици ключове.

2133
01:34:00,320 --> 01:34:03,500
Аз не пиша и
четене цяла една ключова сега.

2134
01:34:03,500 --> 01:34:04,950
Така че това е чудесен модел.

2135
01:34:04,950 --> 01:34:08,090
>> Това всъщност е може би един
от най-важните дизайн

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

2137
01:34:10,420 --> 01:34:14,470
Вие ще видите на този тип
шарка във всеки вкус.

2138
01:34:14,470 --> 01:34:19,100
MongoDB, DynamoDB, това не е така
материя, всички ние трябва да направим това.

2139
01:34:19,100 --> 01:34:21,840
Защото, когато имаш работа
с тези огромни съвкупности,

2140
01:34:21,840 --> 01:34:26,650
ще трябва да се намери начин да се
тях, разпределени по целия кофи.

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

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

2143
01:34:31,220 --> 01:34:35,252
е, което търгува на разстояние за четене
разходи за обезценка мащабируемост.

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

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

2146
01:34:40,220 --> 01:34:41,310
Но аз съм в състояние да пиша.

2147
01:34:41,310 --> 01:34:44,860
И моята производителност, ми пиши
пропускателна способност е невероятна.

2148
01:34:44,860 --> 01:34:49,450
Така че това е обикновено ценна
техника за мащабиране DynamoDB,

2149
01:34:49,450 --> 01:34:51,350
или всяка база данни NoSQL за този въпрос.

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

2151
01:34:53,824 --> 01:34:55,240
Така че сме измислили как да го мащаб.

2152
01:34:55,240 --> 01:34:56,930
И сме измислили как да
премахване на нашите горещи клавиши.

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

2154
01:34:57,820 --> 01:34:58,960
И ние имаме тази хубава система.

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

2156
01:35:02,043 --> 01:35:03,130
Той е построен в DynamoDB.

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

2158
01:35:05,380 --> 01:35:08,170
>> Когато един избирател идва, поставя
вмъкване на масата,

2159
01:35:08,170 --> 01:35:11,220
те вложка с техния избирател ID,
ако се опитат да поставите друг глас,

2160
01:35:11,220 --> 01:35:13,320
Аз правя условно запис.

2161
01:35:13,320 --> 01:35:16,960
Кажете само пиша това
ако това не съществува.

2162
01:35:16,960 --> 01:35:19,270
Така че, след като се видя, че
това гласуване падна тежко на масата,

2163
01:35:19,270 --> 01:35:20,460
никой друг не ще бъде
в състояние да сложи своя вот инча

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

2165
01:35:21,634 --> 01:35:23,550
И ние сме увеличаване
нашите кандидатки броячи.

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

2167
01:35:25,466 --> 01:35:29,110
Но какво се случва, ако ми
прилагане пада върху?

2168
01:35:29,110 --> 01:35:31,350
Сега всичко изведнъж гласа
са подадена, и аз

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

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

2171
01:35:36,040 --> 01:35:38,462
И когато заявлението
се връща, как

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

2173
01:35:41,420 --> 01:35:44,530
>> Така че това е истински проблем, когато
започнете да погледнете този вид сценарий.

2174
01:35:44,530 --> 01:35:45,571
И как можем да решим, че?

2175
01:35:45,571 --> 01:35:48,070
Ние го решим с това, което ние
обадете DynamoDB Streams.

2176
01:35:48,070 --> 01:35:53,470
Потоци се подредени по време и
разделя дневник промяна на всеки достъп

2177
01:35:53,470 --> 01:35:55,700
на масата, всеки напиши
достъп до таблицата.

2178
01:35:55,700 --> 01:35:58,810
Всяка информация, която е написана на
таблица показва на потока.

2179
01:35:58,810 --> 01:36:01,815
>> Това е в основата на 24-часов режим на изчакване.

2180
01:36:01,815 --> 01:36:03,690
Предмети хит на потока,
те живеят в продължение на 24 часа.

2181
01:36:03,690 --> 01:36:05,990
Те могат да се четат няколко пъти.

2182
01:36:05,990 --> 01:36:09,400
Гарантирано да бъдат доставени
само веднъж до потока,

2183
01:36:09,400 --> 01:36:11,180
може да бъде прочетен п брой пъти.

2184
01:36:11,180 --> 01:36:14,910
Така обаче много процеси искате да
консумират, че данните, можете да го консумират.

2185
01:36:14,910 --> 01:36:16,350
Тя ще се появи всеки ъпдейт.

2186
01:36:16,350 --> 01:36:18,455
Всеки запис само ще
се появяват веднъж на потока.

2187
01:36:18,455 --> 01:36:20,621
Така че не е нужно да се притеснявате
за това обработката на два пъти

2188
01:36:20,621 --> 01:36:22,500
от същия процес.

2189
01:36:22,500 --> 01:36:25,350
>> Това е строго осъжда всяка позиция.

2190
01:36:25,350 --> 01:36:28,180
Когато казваме време
осъжда и се разпределя,

2191
01:36:28,180 --> 01:36:30,680
вие ще видите един дял на потока.

2192
01:36:30,680 --> 01:36:33,169
Вие ще видите предмети, ъпдейти в ред.

2193
01:36:33,169 --> 01:36:35,210
Ние не гарантираме
на потока, който сте

2194
01:36:35,210 --> 01:36:40,240
ще получи всяка транзакция
в реда, в цяла предмети.

2195
01:36:40,240 --> 01:36:42,440
>> Така че потоците са 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
Рик 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 Client Library.

2255
01:39:11,390 --> 01:39:19,190
Kinesis е поток от данни
технология на обработка от Amazon.

2256
01:39:19,190 --> 01:39:22,040
И потоци е построен върху това.

2257
01:39:22,040 --> 01:39:25,670
>> Така че можете да използвате KCL активирана
приложението да чете потока.

2258
01:39:25,670 --> 01:39:28,752
The Client Kinesis библиотека всъщност
управлява работниците за вас.

2259
01:39:28,752 --> 01:39:30,460
И това също прави някои
интересни неща.

2260
01:39:30,460 --> 01:39:35,630
Той ще създаде някои таблици нагоре
във вашата DynamoDB таблици

2261
01:39:35,630 --> 01:39:38,410
да следите кои елементи
са били обработени.

2262
01:39:38,410 --> 01:39:41,190
Така че по този начин, ако тя попада обратно, ако
той попада отново и идва и получава

2263
01:39:41,190 --> 01:39:45,570
застана обратно нагоре, тя може да се определи къде
тя е в обработката на потока.

2264
01:39:45,570 --> 01:39:48,360
>> Това е много важно, когато
говориш репликация.

2265
01:39:48,360 --> 01:39:50,350
Аз трябва да знам какво
данни е било преработено

2266
01:39:50,350 --> 01:39:52,810
и какви данни са все още предстои да бъдат обработени.

2267
01:39:52,810 --> 01:39:57,380
Така библиотеката KCL за предавания
ви даде много на тази функционалност.

2268
01:39:57,380 --> 01:39:58,990
Тя се грижи за цялото домакинство.

2269
01:39:58,990 --> 01:40:01,140
Той се изправя работник за всяко парче.

2270
01:40:01,140 --> 01:40:04,620
Тя създава административен маса
за всяко парче, за всеки работник.

2271
01:40:04,620 --> 01:40:07,560
И тъй като тези работници пожар,
те поддържат тези таблици

2272
01:40:07,560 --> 01:40:10,510
така че знам този запис
се чете и обработва.

2273
01:40:10,510 --> 01:40:13,850
И след това по този начин, ако процесът
умира и се връща онлайн,

2274
01:40:13,850 --> 01:40:17,940
то може да се възобнови точно там, където го свали.

2275
01:40:17,940 --> 01:40:20,850
>> Така че ние използваме това за
напречно област репликация.

2276
01:40:20,850 --> 01:40:24,680
Много от клиентите имат нужда да
преместване на данни или части от своите таблици с данни

2277
01:40:24,680 --> 01:40:25,920
около различните региони.

2278
01:40:25,920 --> 01:40:29,230
Има девет региона
навсякъде по света.

2279
01:40:29,230 --> 01:40:32,100
Така че е възможно да има need-- I
може да има потребители в Азия, потребители

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 Streams могат да бъдат
обработват от това, което ние наричаме Lambda.

2296
01:41:23,690 --> 01:41:27,394
Ние, споменати по-малко за събитие
задвижвани архитектури на приложения.

2297
01:41:27,394 --> 01:41:28,810
Lambda е ключов компонент от тази.

2298
01:41:28,810 --> 01:41:32,840
Lambda е код, който се активира при поискване
в отговор на определено събитие.

2299
01:41:32,840 --> 01:41:36,020
Един от тези събития може да бъде
запис се появява на потока.

2300
01:41:36,020 --> 01:41:39,100
Ако рекорд появява на потока,
ние ще се обадя на тази функция Java.

2301
01:41:39,100 --> 01:41:44,980
Е, това е JavaScript, и Lambda
подкрепя Node.js, Java, Python,

2302
01:41:44,980 --> 01:41:47,820
и скоро ще подкрепи
други езици, както добре.

2303
01:41:47,820 --> 01:41:50,940
И достатъчно да се каже, че е чист код.

2304
01:41:50,940 --> 01:41:53,610
напиши В Java, можете да зададете един клас.

2305
01:41:53,610 --> 01:41:55,690
Можете да натиснете JAR нагоре в Lambda.

2306
01:41:55,690 --> 01:42:00,200
И тогава ще се определи кои клас
да се обадя в отговор на което събитие.

2307
01:42:00,200 --> 01:42:04,770
И тогава инфраструктурата Lambda
зад която ще тече този код.

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
Code може да направи нищо, нали?

2313
01:42:15,260 --> 01:42:16,600
>> Така че можете да се върти, че данните.

2314
01:42:16,600 --> 01:42:18,160
Можете да създавате производни гледка.

2315
01:42:18,160 --> 01:42:21,160
Ако това е структура, документ,
можете да се изглади структурата.

2316
01:42:21,160 --> 01:42:24,300
Можете да създадете алтернативни индекси.

2317
01:42:24,300 --> 01:42:27,100
Всички видове неща, които могат да
общо с DynamoDB потоци.

2318
01:42:27,100 --> 01:42:28,780
>> И наистина, това е, което прилича на това.

2319
01:42:28,780 --> 01:42:29,940
Така получавате тези актуализации, идващи инча

2320
01:42:29,940 --> 01:42:31,190
Те идват от низа.

2321
01:42:31,190 --> 01:42:32,720
Те се четат от функцията Lambda.

2322
01:42:32,720 --> 01:42:37,480
Те са въртящи се на данни и
натискането му в деривативни маси,

2323
01:42:37,480 --> 01:42:42,200
уведомяване външни системи на климата,
и бутане на данни в ElastiCache.

2324
01:42:42,200 --> 01:42:45,900
>> Ние говорихме за това как да се сложи на кеш паметта
в предната част на базата данни за продажби че

2325
01:42:45,900 --> 01:42:46,450
сценарий.

2326
01:42:46,450 --> 01:42:50,049
Ами какво ще стане, ако
актуализира описанието на този артикул?

2327
01:42:50,049 --> 01:42:52,340
Е, ако имах Lambda
Функцията работи на същата таблица,

2328
01:42:52,340 --> 01:42:55,490
ако аз актуализира описанието на позиция, тя ще
вземете записа изключване на потока,

2329
01:42:55,490 --> 01:42:58,711
и това ще актуализира ElastiCache
Например с новите данни.

2330
01:42:58,711 --> 01:43:00,460
Така че това е много
какво ще правим с Lambda.

2331
01:43:00,460 --> 01:43:02,619
Това е лепило код, съединители.

2332
01:43:02,619 --> 01:43:04,410
И това всъщност дава
способността да започне

2333
01:43:04,410 --> 01:43:07,930
и да тичам много сложни приложения
без специален сървър

2334
01:43:07,930 --> 01:43:10,371
инфраструктура, което е наистина страхотно.

2335
01:43:10,371 --> 01:43:13,100
>> Така че нека да се върнем към нашия
в реално време архитектурата гласуване.

2336
01:43:13,100 --> 01:43:17,984
Това е нова и подобрена с нашите
потоци и KCL активирани приложения.

2337
01:43:17,984 --> 01:43:20,150
Същото като преди, можем
справи с всеки десетобалната система избори.

2338
01:43:20,150 --> 01:43:21,100
Ние обичаме това.

2339
01:43:21,100 --> 01:43:24,770
Ние правим от разсейване набори
в няколко кофи.

2340
01:43:24,770 --> 01:43:26,780
Имаме оптимистично заключване става.

2341
01:43:26,780 --> 01:43:30,192
Ние можем да запазим нашите избиратели
от промяна на гласа си.

2342
01:43:30,192 --> 01:43:31,400
Те могат само да гласува само веднъж.

2343
01:43:31,400 --> 01:43:32,880
Това е фантастично.

2344
01:43:32,880 --> 01:43:35,895
Толерантността в реално време неизправност,
мащабируема агрегация сега.

2345
01:43:35,895 --> 01:43:38,270
Ако нещо падне, тя
знае къде да се рестартира

2346
01:43:38,270 --> 01:43:41,300
когато тя се връща, защото
ние сме с помощта на KCL ап.

2347
01:43:41,300 --> 01:43:45,700
И тогава можем да също да използват този
KCL заявление да прокара данни от

2348
01:43:45,700 --> 01:43:48,820
до червено отместване за друга
ап анализи, или да използвате

2349
01:43:48,820 --> 01:43:51,990
Еластичната MapReduce да работят
в реално време стрийминг струпвания почивни

2350
01:43:51,990 --> 01:43:53,180
на тези данни.

2351
01:43:53,180 --> 01:43:55,480
>> Така че това са неща, които ние
Не сме говорили за много.

2352
01:43:55,480 --> 01:43:57,375
Но те са допълнително
технологии, които идват

2353
01:43:57,375 --> 01:44:00,310
да понесе, когато търсите
при тези видове сценарии.

2354
01:44:00,310 --> 01:44:03,160
>> Добре, така че става дума за
анализи с DynamoDB Streams.

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
Приложения, изградени с помощта на Dynamo включва
Lambda, ElastiCache, CloudSearch,

2367
01:44:45,600 --> 01:44:49,890
бутнете данните посочени в Elastic
MapReduce, вноса и износа от DynamoDB

2368
01:44:49,890 --> 01:44:52,370
в S3, всички видове работни потоци.

2369
01:44:52,370 --> 01:44:54,120
Но може би най-добрия
нещо, за да се говори за,

2370
01:44:54,120 --> 01:44:56,119
и това е, което е наистина
Интересно е, когато ние

2371
01:44:56,119 --> 01:44:58,350
говорим за събития задвижва приложения.

2372
01:44:58,350 --> 01:45:00,300
>> Това е пример на
вътрешен проект

2373
01:45:00,300 --> 01:45:04,850
че ние имаме, когато сме в действителност
издателска дейност, за да се съберат резултатите от проучването.

2374
01:45:04,850 --> 01:45:07,700
Така че в имейл линк, който
ние изпращаме, ще има

2375
01:45:07,700 --> 01:45:11,350
да е малко линк казвайки кликване
тук, за да отговорят на проучването.

2376
01:45:11,350 --> 01:45:14,070
И когато едно лице кликвания
които сочат, какво се случва,

2377
01:45:14,070 --> 01:45:18,020
е те събарят сигурна
HTML форма проучване от S3.

2378
01:45:18,020 --> 01:45:18,980
Няма по-сървър.

2379
01:45:18,980 --> 01:45:20,600
Това е просто един S3 обект.

2380
01:45:20,600 --> 01:45:22,770
>> В този формуляр идва,
зарежда в браузъра.

2381
01:45:22,770 --> 01:45:24,240
Тя има гръбнак.

2382
01:45:24,240 --> 01:45:30,160
Той има сложна JavaScript
че той се движи.

2383
01:45:30,160 --> 01:45:33,557
Така че е много богат кандидатстване
работи в браузъра на клиента.

2384
01:45:33,557 --> 01:45:36,390
Те не знаят, че те не са
взаимодействие с задния край на сървъра.

2385
01:45:36,390 --> 01:45:38,220
В този момент, всичко е браузър.

2386
01:45:38,220 --> 01:45:41,780
>> Те публикуват резултатите на това, което
ние наричаме Amazon API Gateway.

2387
01:45:41,780 --> 01:45:46,270
API Gateway е просто уеб API
че можете да определите и кука

2388
01:45:46,270 --> 01:45:47,760
до каквото си искате.

2389
01:45:47,760 --> 01:45:50,990
В този конкретен случай, ние сме
закачен към функция Lambda.

2390
01:45:50,990 --> 01:45:54,797
>> Така че моят POST операция е
случва, без сървър.

2391
01:45:54,797 --> 01:45:56,380
По принцип, че API Gateway седи там.

2392
01:45:56,380 --> 01:45:58,770
Това ми струва нищо, докато хората
започнете да публикувате до него, нали?

2393
01:45:58,770 --> 01:46:00,269
Функцията Lambda просто седи там.

2394
01:46:00,269 --> 01:46:03,760
И това ми струва нищо, докато
хората започват да го удря.

2395
01:46:03,760 --> 01:46:07,270
Така че можете да видите, като обема
се увеличава, това е, когато обвиненията идват.

2396
01:46:07,270 --> 01:46:09,390
Аз не бягам сървъра 7.24.

2397
01:46:09,390 --> 01:46:12,310
>> Така че аз извадя формата
слиза от кофата,

2398
01:46:12,310 --> 01:46:15,719
и аз публикувате чрез API
Gateway в функцията Lambda.

2399
01:46:15,719 --> 01:46:17,510
И тогава ламбда
функция казва, нали знаеш

2400
01:46:17,510 --> 01:46:20,600
какво, аз имам някои PIIs, някои
лична информация

2401
01:46:20,600 --> 01:46:21,480
в тези реакции.

2402
01:46:21,480 --> 01:46:23,020
Имам забележки, идващи от потребители.

2403
01:46:23,020 --> 01:46:24,230
Имам имейл адреси.

2404
01:46:24,230 --> 01:46:26,190
Имам потребителски имена.

2405
01:46:26,190 --> 01:46:27,810
>> Позволете ми да раздели това разстояние.

2406
01:46:27,810 --> 01:46:30,280
Отивам да генерира някакъв
метаданни извън този запис.

2407
01:46:30,280 --> 01:46:32,850
И аз отивам да натиснете
метаданни в DynamoDB.

2408
01:46:32,850 --> 01:46:36,059
И аз може да криптира всички данни
и го натиснете в DynamoDB ако искам.

2409
01:46:36,059 --> 01:46:38,600
Но това е по-лесно за мен, в тази
използвате случай, да се продължи напред с да речем,

2410
01:46:38,600 --> 01:46:42,800
Отивам да прокара Суровите данни
в криптиран S3 кофа.

2411
01:46:42,800 --> 01:46:47,240
Така че аз ползване построена през сървъра страна S3
криптиране и Key Management на Amazon

2412
01:46:47,240 --> 01:46:51,600
Service, така че имам ключ, който
може да се върти на регулярна интервал,

2413
01:46:51,600 --> 01:46:55,010
и мога да защитим тази PII данни
като част от целия този процес.

2414
01:46:55,010 --> 01:46:55,870
>> И така, какво съм направил?

2415
01:46:55,870 --> 01:47:00,397
Току-що се разположи цяло
приложение, и нямам сървър.

2416
01:47:00,397 --> 01:47:02,980
Така че това, което е ориентирана към събития кандидатстване
архитектура прави за вас.

2417
01:47:02,980 --> 01:47:05,730
>> Сега, ако мислите, че за
случай на използване за this--

2418
01:47:05,730 --> 01:47:08,730
имаме други клиенти говоря
до около тази точна архитектура, които

2419
01:47:08,730 --> 01:47:14,560
тичам феноменално големи кампании, които
разглеждате тази и ще, о, боже.

2420
01:47:14,560 --> 01:47:17,840
Защото сега, те могат
По същество това бутнете там,

2421
01:47:17,840 --> 01:47:21,900
нека тази кампания просто си седя
там, докато не започва и не

2422
01:47:21,900 --> 01:47:24,400
трябва да се притеснявате за смокиново
какъв вид инфраструктура

2423
01:47:24,400 --> 01:47:26,120
ще бъде там, за да го подкрепят.

2424
01:47:26,120 --> 01:47:28,600
И след това, веднага след като
тази кампания е направено,

2425
01:47:28,600 --> 01:47:31,520
това е като инфраструктурата
Просто веднага си отива

2426
01:47:31,520 --> 01:47:33,680
защото там наистина
е никаква инфраструктура.

2427
01:47:33,680 --> 01:47:35,660
Това е просто код, който седи на Lambda.

2428
01:47:35,660 --> 01:47:38,560
Това е просто информация, която седи в DynamoDB.

2429
01:47:38,560 --> 01:47:41,340
Това е един удивителен начин
за изграждане на приложения.

2430
01:47:41,340 --> 01:47:43,970
>> АУДИТОРИЯ: Така че е по-
ефимерна, отколкото би било

2431
01:47:43,970 --> 01:47:45,740
ако тя се съхранява в условията на реален сървър?

2432
01:47:45,740 --> 01:47:46,823
>> Рик 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 е достъпно 24/7.

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 Gateway не е сървър-подобни,

2449
01:48:29,690 --> 01:48:30,576
но вместо това е just--

2450
01:48:30,576 --> 01:48:32,850
>> Рик 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
И в този случай, ние сме картографиране
тя към функция Lambda.

2454
01:48:41,525 --> 01:48:44,119

2455
01:48:44,119 --> 01:48:45,410
Добре, така че това е всичко, което имам.

2456
01:48:45,410 --> 01:48:46,190
Благодаря ти много.

2457
01:48:46,190 --> 01:48:46,800
Оценявам го.

2458
01:48:46,800 --> 01:48:48,100
Знам, че ние искаме малко с течение на времето.

2459
01:48:48,100 --> 01:48:49,980
И се надяваме, че вие, момчета дойдоха
малко информация

2460
01:48:49,980 --> 01:48:51,410
че можете да отнемат днес.

2461
01:48:51,410 --> 01:48:53,520
И аз се извинявам, ако аз отидох
над някои от главите си,

2462
01:48:53,520 --> 01:48:56,697
но има добър много
фундаментални знания основополагаща

2463
01:48:56,697 --> 01:48:58,280
Мисля, че е много ценно за вас.

2464
01:48:58,280 --> 01:48:59,825
Така че ви благодаря че ме поканихте.

2465
01:48:59,825 --> 01:49:00,325
[Аплодисменти]

2466
01:49:00,325 --> 01:49:02,619
АУДИТОРИЯ: [недоловим]
е, когато казваха

2467
01:49:02,619 --> 01:49:05,160
трябваше да мине през нещо
от началото до края

2468
01:49:05,160 --> 01:49:07,619
за да получите правилните стойности
или едни и същи ценности,

2469
01:49:07,619 --> 01:49:09,410
как ще стойностите
промени, ако [недоловим].

2470
01:49:09,410 --> 01:49:10,480
>> Рик 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
Рик 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
>> Рик Houlihan: Не бих
казват, че оставяйки след себе си.

2485
01:49:44,600 --> 01:49:45,855
>> АУДИТОРИЯ: Те са били отделени от the--

2486
01:49:45,855 --> 01:49:49,140
>> Рик 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
на тези обекти, използващи Object Notation.

2491
01:49:59,480 --> 01:50:03,562
Така че мога да филтрирате по вложено
собственост на документа JSON.

2492
01:50:03,562 --> 01:50:05,520
АУДИТОРИЯ: Така всяко време I
направя подход документ,

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
Рик 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
възрази и ще каже OK,

2502
01:50:24,340 --> 01:50:26,030
това, което е собственост Искам да индекс?

2503
01:50:26,030 --> 01:50:28,717
>> Вие създавате производни на маса.

2504
01:50:28,717 --> 01:50:30,300
Сега това е начина, по който тя работи в момента.

2505
01:50:30,300 --> 01:50:32,650
Ние не ви позволи да индексира
пряко тези свойства.

2506
01:50:32,650 --> 01:50:33,520
>> АУДИТОРИЯ: Tabularizing вашите документи.

2507
01:50:33,520 --> 01:50:36,230
>> Рик 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
>> Рик Houlihan: Да,
Абсолютно, благодаря ви.

2511
01:50:39,609 --> 01:50:42,240
АУДИТОРИЯ: Така че това е вид
Монго отговаря REDIS classifers.

2512
01:50:42,240 --> 01:50:43,990
>> Рик 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