1
00:00:00,000 --> 00:00:04,969
>> [Мусиц плаиинг]

2
00:00:04,969 --> 00:00:06,010
Рицк Хоулихан: У реду.

3
00:00:06,010 --> 00:00:06,600
Zdravo svima.

4
00:00:06,600 --> 00:00:07,670
Моје име је Рик Хоулихан.

5
00:00:07,670 --> 00:00:10,330
Ја сам старији главни
Солутионс Арцхитецт на АВС.

6
00:00:10,330 --> 00:00:14,070
Ја се фокусирати на носкл и
ДинамоДБ технологије.

7
00:00:14,070 --> 00:00:16,930
Овде сам данас да разговарам са
ви мало о томе.

8
00:00:16,930 --> 00:00:18,970
>> Моја позадина је
пре свега у слоју података.

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

10
00:00:21,390 --> 00:00:25,930
приступа подацима, решења
за различите апликације.

11
00:00:25,930 --> 00:00:30,000
Ја сам био у Цлоуд виртуелизација
око 20 година.

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

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

14
00:00:37,170 --> 00:00:38,800
Данас ми то зовемо облак.

15
00:00:38,800 --> 00:00:41,239
>> Али током година, радио сам
за пар предузећа

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

17
00:00:42,530 --> 00:00:47,470
Али ја сам саставио листу техничких
достигнућа, претпостављам да ћеш рећи.

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

19
00:00:51,620 --> 00:00:54,440
комплекс за прераду догађај,
и другим областима као добро.

20
00:00:54,440 --> 00:00:58,290
>> Тако ових дана, углавном фокусирају на носкл
технологија и следећа генерација

21
00:00:58,290 --> 00:00:59,450
baza podataka.

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
И причаћемо мало
мало о носкл технологије

28
00:01:15,600 --> 00:01:17,500
од фундаменталног становишта.

29
00:01:17,500 --> 00:01:19,870
>> Ми ћемо ући у неке од
су ДинамоДБ интерналс.

30
00:01:19,870 --> 00:01:24,350
ДинамоДБ је АВС немају укуса.

31
00:01:24,350 --> 00:01:27,340
То је потпуно управља и
домаћин НоСКЛ решење.

32
00:01:27,340 --> 00:01:32,420
И причаћемо мало о табеле
структура, Апис, типови података, индекси,

33
00:01:32,420 --> 00:01:35,177
и неких интерних
те ДинамоДБ технологије.

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
и како ДинамоДБ игра у исто тако добро.

40
00:01:51,580 --> 00:01:54,690
И ми ћемо вам оставити мало
референтна архитектура дискусија

41
00:01:54,690 --> 00:01:59,540
тако да можемо говорити о неким
начине на које можете користити ДинамоДБ.

42
00:01:59,540 --> 00:02:04,116
>> Дакле, прво медјувремену- је ово питање
Чујем доста је, шта је база података.

43
00:02:04,116 --> 00:02:06,240
Много људи мисле они
знају шта је база података.

44
00:02:06,240 --> 00:02:08,360
Ако вам Гоогле видећете ово.

45
00:02:08,360 --> 00:02:11,675
То је Структуриран скуп података одржана
у компјутеру, посебно оног који

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

47
00:02:13,600 --> 00:02:16,992
Претпостављам да је то добра
дефиниција модерне базе података.

48
00:02:16,992 --> 00:02:19,450
Али ја се не свиђа, јер
то подразумева неколико ствари.

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

50
00:02:20,935 --> 00:02:23,120
А то значи да је на рачунару.

51
00:02:23,120 --> 00:02:25,750
И база података није
Увек постоје на рачунарима.

52
00:02:25,750 --> 00:02:28,020
Базе података у ствари постојала на много начина.

53
00:02:28,020 --> 00:02:32,000
>> Дакле, боље дефиниција
База је нешто овако.

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

55
00:02:34,786 --> 00:02:35,910
и проналажење информација.

56
00:02:35,910 --> 00:02:36,868
Ово је од Абоут.цом.

57
00:02:36,868 --> 00:02:42,080
Дакле, ја волим ово јер је стварно разговори
о База података као спремиште,

58
00:02:42,080 --> 00:02:44,800
спремиште
информације, не нужно

59
00:02:44,800 --> 00:02:46,780
нешто што седи на рачунару.

60
00:02:46,780 --> 00:02:49,290
И кроз историју, ми
нису увек имали компјутере.

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

62
00:02:52,110 --> 00:02:54,770
база података, то је одговор да добијем.

63
00:02:54,770 --> 00:02:56,070
Негде сам да држимо ствари.

64
00:02:56,070 --> 00:02:56,670
Jel tako?

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
U redu.

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
и то је нешто на линес--
То је веома поетски исказ.

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
OK.

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
И њихова абилитии није тако добро.

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
U redu?

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
Jel tako?

127
00:05:22,570 --> 00:05:24,390
У САД пописа 1880.

128
00:05:24,390 --> 00:05:26,976
Ово је заиста где је преломна
указују модерну обраду података.

129
00:05:26,976 --> 00:05:28,850
Ово је тачка на
која количина података

130
00:05:28,850 --> 00:05:32,060
који је прикупљају од стране
Америчка влада је до тога

131
00:05:32,060 --> 00:05:34,005
где је требало осам година да процесуирају.

132
00:05:34,005 --> 00:05:36,350
>> Сада, осам година-- као
знате, попис

133
00:05:36,350 --> 00:05:39,180
вози сваких 10 година- тако да је
очигледно да је време да

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
заправо постао један од стубова
мала фирма ми данас знамо под називом ИБМ.

143
00:06:05,450 --> 00:06:08,417
>> Дакле, ИБМ-првобитно био у
пословна база података.

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
Можете видети на овој слици
ту имамо мали--

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

150
00:06:23,970 --> 00:06:26,970
где имамо палубу ударац картице.

151
00:06:26,970 --> 00:06:28,720
И нечији узимање
мало шрафцигер

152
00:06:28,720 --> 00:06:31,400
и лепљење кроз
слота и подизање ит уп

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

154
00:06:34,820 --> 00:06:36,270
>> Ово је агрегације.

155
00:06:36,270 --> 00:06:38,690
Све време смо ово
данас у рачунару,

156
00:06:38,690 --> 00:06:40,100
где си то урадила у бази података.

157
00:06:40,100 --> 00:06:41,620
Користили смо то учинити ручно, зар не?

158
00:06:41,620 --> 00:06:42,994
Људи ставиш ове ствари заједно.

159
00:06:42,994 --> 00:06:45,440
И то је био ширење
ових удараца картица

160
00:06:45,440 --> 00:06:50,070
у оно што смо звали бубњевима података
и калемови података, папирне траке.

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

162
00:06:55,980 --> 00:06:57,855
Играч клавира натраг у
ред века

163
00:06:57,855 --> 00:07:02,100
користио папир колона са отворима
на то рећи који тастери да игра.

164
00:07:02,100 --> 00:07:05,380
Тако да је технологија је прилагођен
на крају за складиштење дигиталних података,

165
00:07:05,380 --> 00:07:08,070
јер су могли ставити те податке
на оне папирне траке бубњевима.

166
00:07:08,070 --> 00:07:10,870
>> Сада, као резултат, података
је стварно-- како

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
системи које смо изградили. Jel tako?

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
>> Али један од разлога и
возач иза ово-ве

213
00:09:34,760 --> 00:09:38,290
говорио о притиску података.

214
00:09:38,290 --> 00:09:41,920
Притисак података је нешто
који покреће иновације.

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

216
00:09:44,610 --> 00:09:48,180
ово је графикон Вхат Тхе података
оптерећење преко опште предузећу

217
00:09:48,180 --> 00:09:49,640
Изгледа да у последњих пет година.

218
00:09:49,640 --> 00:09:52,570
>> А опште правило
ови даис-- ако идете Гоогле--

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
OK.

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
То је 6.500 пута више података.

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

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

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

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

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
Jel tako?

257
00:11:30,020 --> 00:11:31,228
Нећемо зауставити ово.

258
00:11:31,228 --> 00:11:31,830
Zašto?

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
>> Дакле, једна од ствари
гледамо и зашто НоСКЛ?

271
00:12:17,410 --> 00:12:19,200
Како НоСКЛ решити овај проблем?

272
00:12:19,200 --> 00:12:24,980
Па, релационе базе података,
Струцтуред Куери Лангуаге,

273
00:12:24,980 --> 00:12:28,600
СКЛ-- то је стварно конструкт од
релациона датабасе-- ове ствари

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
Znam.

278
00:12:37,490 --> 00:12:38,020
Ја га живео.

279
00:12:38,020 --> 00:12:41,250
Писао сам драјвере за складиштење
Ентерприсед Суперсервер компанија

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
и за ефикасније складиштење
девицес-- то никад није престао.

286
00:12:56,340 --> 00:13:00,160
>> И НоСКЛ је велики технологија
јер нормализује податке.

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
Више апликација може да погоди да
СКЛ база података, ради ад хоц упите,

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
OK?

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
>> Ако је потребно да бисте добили већи СКЛ базу података
или моћнији СКЛ база,

302
00:13:39,030 --> 00:13:41,090
Идем купити већи део гвожђа.

303
00:13:41,090 --> 00:13:41,600
OK?

304
00:13:41,600 --> 00:13:44,940
Радила сам са много купаца
који су прошли кроз главне надоградње

305
00:13:44,940 --> 00:13:48,340
у свом СКЛ инфраструктуру само
сазнати шест месеци касније,

306
00:13:48,340 --> 00:13:49,750
они ударају у зид опет.

307
00:13:49,750 --> 00:13:55,457
А одговор из Орацле или МССКЛ
или неко други је добити већи кутију.

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
То добро ради за офлајн
аналитика, ОЛАП типа оптерећења.

312
00:14:06,560 --> 00:14:08,670
И то је стварно где СКЛ припада.

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
али то једноставно не сцале
начин на који НоСКЛ ради.

317
00:14:18,670 --> 00:14:20,660
И причаћемо мало
мало о томе зашто је то.

318
00:14:20,660 --> 00:14:23,590
>> Дакле, НоСКЛ, с друге стране,
је више оптимизован за програму.

319
00:14:23,590 --> 00:14:24,540
OK?

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

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
OK?

331
00:14:56,410 --> 00:14:58,610
Ви сцале хоризонтално.

332
00:14:58,610 --> 00:14:59,556
Jel tako?

333
00:14:59,556 --> 00:15:02,100
Ако треба да се повећа
Величина мог носкл кластера,

334
00:15:02,100 --> 00:15:03,700
Не треба да добију већу кутију.

335
00:15:03,700 --> 00:15:05,200
Имам још једну кутију.

336
00:15:05,200 --> 00:15:07,700
И оне групишу заједно,
и ја могу да Схард те податке.

337
00:15:07,700 --> 00:15:10,780
Причаћемо мало о
шта схардинг је, да будемо

338
00:15:10,780 --> 00:15:14,270
у стању да смањи ту базу података
на више физичких уређаја

339
00:15:14,270 --> 00:15:18,370
и уклоните баријеру која
тражи ме да вертикално размери.

340
00:15:18,370 --> 00:15:22,080
>> Дакле, то је заиста направљен за онлајн
обрада трансакција и обима.

341
00:15:22,080 --> 00:15:25,480
Постоји велика разлика
Овде између извештавања, зар не?

342
00:15:25,480 --> 00:15:27,810
Извештавање, ја не знам да је
Питања ћу да питам.

343
00:15:27,810 --> 00:15:28,310
Jel tako?

344
00:15:28,310 --> 00:15:30,570
Репортинг-- ако неко из
мој маркетиншко одељење

345
00:15:30,570 --> 00:15:34,520
жели да само- колико од мојих клијената
има ту особину која посебну

346
00:15:34,520 --> 00:15:37,850
Купио на овом даи-- не знам
оно упита они ће питати.

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
OK?

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
И зато НоСКЛ могу
стварно убрзати испоруку

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

356
00:15:57,710 --> 00:15:58,210
U redu.

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
OK.

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
Jel tako?

370
00:16:27,460 --> 00:16:27,820
OK.

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
или гвожђе троугао офтентимес--
Када разговарате са пројектним менаџерима,

374
00:16:34,420 --> 00:16:35,420
они ће разговарати о томе.

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

376
00:16:37,640 --> 00:16:40,350
И гвожђе троугао података
је оно што зовемо ЦАП теорема.

377
00:16:40,350 --> 00:16:41,580
OK?

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
Али три тачке троугла,
да тако кажем, су Ц, доследност.

382
00:16:52,221 --> 00:16:52,720
OK?

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
OK?

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
OK?

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
OK?

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

399
00:17:28,160 --> 00:17:32,000
упркос физичке мреже
преграде између чворова.

400
00:17:32,000 --> 00:17:32,760
OK?

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

402
00:17:36,270 --> 00:17:36,880
U redu.

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

404
00:17:39,545 --> 00:17:40,045
OK.

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

406
00:17:43,680 --> 00:17:47,510
Ако је партиција се догађа између
су ДатаНодес у складишту података,

407
00:17:47,510 --> 00:17:48,831
база сруши.

408
00:17:48,831 --> 00:17:49,330
Jel tako?

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

410
00:17:50,900 --> 00:17:51,450
OK.

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

412
00:17:54,230 --> 00:17:54,730
Jel tako?

413
00:17:54,730 --> 00:17:58,021
Зато што је не-- обично, кластер
база података, нема баш много од њих

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
>> И то је оно што НоСКЛ базе података ради.

420
00:18:16,080 --> 00:18:16,580
U redu.

421
00:18:16,580 --> 00:18:20,950
Дакле, НоСКЛ база података је,
долази у две варијанте.

422
00:18:20,950 --> 00:18:22,990
Ми добро бих--, то
долази у многим укуса,

423
00:18:22,990 --> 00:18:26,140
али долази са два основна
цхарацтеристицс-- шта

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

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

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

427
00:18:34,930 --> 00:18:37,091
нећемо дозволити
људи пишу више.

428
00:18:37,091 --> 00:18:37,590
OK?

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
OK?

439
00:18:58,120 --> 00:19:02,650
>> Следећа укус би бити АП систем,
или на располагању и расподељена

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

441
00:19:03,640 --> 00:19:05,320
Ови момци не занима.

442
00:19:05,320 --> 00:19:06,020
Jel tako?

443
00:19:06,020 --> 00:19:08,960
Било чвор који постаје
врите, ми ћемо га узети.

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

445
00:19:11,480 --> 00:19:14,730
Те тачке се клијент, клијент долази
у, каже, ја ћу написати неке податке.

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

447
00:19:16,300 --> 00:19:18,580
Чвор поред њега добија
отписа на истом запису,

448
00:19:18,580 --> 00:19:20,405
он ће рећи никакав проблем.

449
00:19:20,405 --> 00:19:23,030
Негде назад на крају леђа,
да су подаци ће да понове.

450
00:19:23,030 --> 00:19:27,360
И онда це неко да схвати,
Ух-ох, они систем ће схватити, ух-ох,

451
00:19:27,360 --> 00:19:28,870
дошло је до упдате за обе стране.

452
00:19:28,870 --> 00:19:30,370
Šta da radimo?

453
00:19:30,370 --> 00:19:33,210
И шта онда они раде је
они раде нешто што

454
00:19:33,210 --> 00:19:36,080
им омогућава да реше ту државу података.

455
00:19:36,080 --> 00:19:39,000
И причаћемо о
да ће у наредном графикону.

456
00:19:39,000 --> 00:19:40,000
>> Ствар да истакнем овде.

457
00:19:40,000 --> 00:19:42,374
И нећу превише добити
много у ово, јер ово

458
00:19:42,374 --> 00:19:43,510
улази у дубоку теорију података.

459
00:19:43,510 --> 00:19:46,670
Али постоји трансакцијски
оквир који

460
00:19:46,670 --> 00:19:50,680
Ради у релационом систему који
омогућава да безбедно направи ажурирања

461
00:19:50,680 --> 00:19:53,760
на више лица у бази.

462
00:19:53,760 --> 00:19:58,320
И да ли ће доћи до те исправке
одједном или се уопште не.

463
00:19:58,320 --> 00:20:00,500
И ово се зове АЦИД трансакције.

464
00:20:00,500 --> 00:20:01,000
OK?

465
00:20:01,000 --> 00:20:06,570
>> Ацид нам даје атомски, доследност,
изолација, и трајност.

466
00:20:06,570 --> 00:20:07,070
OK?

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
OK?

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
OK.

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
Jel tako?

501
00:21:37,640 --> 00:21:40,520
>> Због проблема
са овим оквир

502
00:21:40,520 --> 00:21:44,540
ако постоји партиција у подацима
скуп, морам да донесем одлуку.

503
00:21:44,540 --> 00:21:48,000
Ја ћу морати да омогући
исправке на једној или другој страни.

504
00:21:48,000 --> 00:21:50,310
А ако се то деси,
онда сам више не иде

505
00:21:50,310 --> 00:21:52,630
бити у стању да одржи
те карактеристике.

506
00:21:52,630 --> 00:21:53,960
Неће бити доследни.

507
00:21:53,960 --> 00:21:55,841
Неће бити изоловани.

508
00:21:55,841 --> 00:21:58,090
Ово је место где се ломи доле
за релационим базама података.

509
00:21:58,090 --> 00:22:01,360
То је разлог релациона
базе података сцале вертикално.

510
00:22:01,360 --> 00:22:05,530
>> Са друге стране имамо
оно што се зове БАСЕ технологију.

511
00:22:05,530 --> 00:22:07,291
А ово су твоји НоСКЛ базе података.

512
00:22:07,291 --> 00:22:07,790
U redu.

513
00:22:07,790 --> 00:22:10,180
Дакле, имамо ЦП, АП базама података.

514
00:22:10,180 --> 00:22:14,720
А ово су оно што у суштини зову
доступно, мека држава, коначно

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

516
00:22:15,740 --> 00:22:16,420
OK?

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
OK?

522
00:22:26,460 --> 00:22:30,810
Ја не могу увек бити у стању да напише
Подаци ако сам доследан платформа.

523
00:22:30,810 --> 00:22:32,130
Али ја ћу моћи да прочита податке.

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

525
00:22:34,960 --> 00:22:38,010
>> Мека стање индицира
када сам прочитао тај податке,

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

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

528
00:22:43,390 --> 00:22:46,650
и то није копирана сиром
кластер још када сам прочитао тај податке,

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

530
00:22:48,680 --> 00:22:51,650
Међутим, то ће бити
на крају доследни,

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

532
00:22:53,870 --> 00:22:56,480
то ће понове преко чворова.

533
00:22:56,480 --> 00:22:59,095
И на крају, та држава
ће бити доведени у ред,

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

535
00:23:00,890 --> 00:23:05,000
>> Сада, ЦАП теорема стварно
игра само у једном стању.

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

537
00:23:08,700 --> 00:23:13,710
Зато, кад год је то ради у
нормал, нема поделе,

538
00:23:13,710 --> 00:23:16,370
Све је доследан и доступни.

539
00:23:16,370 --> 00:23:19,990
Само бринути о ЦАП
када имамо ту партицију.

540
00:23:19,990 --> 00:23:21,260
Дакле, то су ретки.

541
00:23:21,260 --> 00:23:25,360
Али како систем реагује када они
се јављају диктирају шта тип система

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

543
00:23:26,750 --> 00:23:31,110
>> Дакле, хајде да погледамо шта
која личи на АП системе.

544
00:23:31,110 --> 00:23:32,621
OK?

545
00:23:32,621 --> 00:23:34,830
АП системи долазе у две верзије.

546
00:23:34,830 --> 00:23:38,514
Они долазе у укуса која је
Мастер Мастер, 100%, увек на располагању.

547
00:23:38,514 --> 00:23:40,430
И они долазе у
друга укуса, који каже:

548
00:23:40,430 --> 00:23:43,330
знате шта, ја ћу се бринути
о овом партиција ствари

549
00:23:43,330 --> 00:23:44,724
када се стварна подела јавља.

550
00:23:44,724 --> 00:23:47,890
У супротном, постоји ће бити примарни
чворови који ће трајати права.

551
00:23:47,890 --> 00:23:48,500
OK?

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

553
00:23:50,040 --> 00:23:54,440
Касандра ће бити господар
господар, да сам ја пишем на било који чвор.

554
00:23:54,440 --> 00:23:55,540
Дакле, шта се дешава?

555
00:23:55,540 --> 00:23:58,270
Дакле, имам објекат у граду
база података која постоји на два чвора.

556
00:23:58,270 --> 00:24:01,705
Назовимо тај објекат С.
Дакле, имамо државу за С.

557
00:24:01,705 --> 00:24:04,312
Имамо неке операције
о С који су у току.

558
00:24:04,312 --> 00:24:06,270
Касандра ме омогућава
пишите више чворова.

559
00:24:06,270 --> 00:24:08,550
Рецимо ја добијем
писати за с на два чвора.

560
00:24:08,550 --> 00:24:12,274
Па, шта завршава се догађа је
ми то зовемо дељење догађаја.

561
00:24:12,274 --> 00:24:14,190
Ту не може бити
физичка мрежа партиција.

562
00:24:14,190 --> 00:24:15,950
Али због дизајна
система, то је

563
00:24:15,950 --> 00:24:18,449
заправо подели чим
што добијем писати по два чвора.

564
00:24:18,449 --> 00:24:20,830
То ме не тера да
напиши све преко једног чвора.

565
00:24:20,830 --> 00:24:22,340
Ја пишем на два чвора.

566
00:24:22,340 --> 00:24:23,330
OK?

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

568
00:24:25,740 --> 00:24:26,360
OK?

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
OK?

576
00:24:39,110 --> 00:24:43,057
По дефаулту, Последња обнова
победи у већини АП система.

577
00:24:43,057 --> 00:24:44,890
Дакле, обично постоји
Дефаулт алгоритам, шта

578
00:24:44,890 --> 00:24:47,400
зову цаллбацк
функција, нешто што

579
00:24:47,400 --> 00:24:51,000
ће се звати када се ово стање
се открије да изврши неку логику

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

581
00:24:52,900 --> 00:24:53,850
OK?

582
00:24:53,850 --> 00:24:58,770
Уобичајени повратни позив и затезна
Ресолвер у већини АП базама података

583
00:24:58,770 --> 00:25:01,130
је, знаш шта, тиместамп победи.

584
00:25:01,130 --> 00:25:02,380
То је био последњи ажурирање.

585
00:25:02,380 --> 00:25:04,320
Ја ћу ставити ту исправку тамо.

586
00:25:04,320 --> 00:25:08,440
Ја могу да бацим ово рекорд који сам
бачено са у лог опоравак

587
00:25:08,440 --> 00:25:11,670
тако да корисник може вратити касније
и рећи, хеј, дошло је до судара.

588
00:25:11,670 --> 00:25:12,320
Šta se desilo?

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

590
00:25:16,370 --> 00:25:17,550
и види шта се дешава.

591
00:25:17,550 --> 00:25:21,580
>> Сада, као корисник, можете такође
укључује логику у том цаллбацк.

592
00:25:21,580 --> 00:25:24,290
Дакле, можете да промените који
повратни операција.

593
00:25:24,290 --> 00:25:26,730
Можете рећи, хеј, ја желим
да побољшају ове податке.

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

595
00:25:28,880 --> 00:25:30,050
Али то је на вама.

596
00:25:30,050 --> 00:25:32,880
База података не зна како да
то по дефаулту. Већина време,

597
00:25:32,880 --> 00:25:34,850
Једина ствар база података
зна како да то урадите је рећи,

598
00:25:34,850 --> 00:25:36,100
ово је био последњи рекорд.

599
00:25:36,100 --> 00:25:39,183
То је онај који ће победити,
и то је вредност ћу ставити.

600
00:25:39,183 --> 00:25:41,490
Након тог партитион рецовери
и репликација се јавља,

601
00:25:41,490 --> 00:25:43,930
имамо своју државу, која
је сада главни С, који је

602
00:25:43,930 --> 00:25:46,890
стапања држава свих тих објеката.

603
00:25:46,890 --> 00:25:49,700
Дакле АП системи имају ово.

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
OK?

608
00:25:56,180 --> 00:25:58,670
Тако да је врло лако
се баве бити у складу

609
00:25:58,670 --> 00:26:01,330
када не прихватају било какве исправке.

610
00:26:01,330 --> 00:26:04,620
То је са ЦП системи раде.

611
00:26:04,620 --> 00:26:05,120
U redu.

612
00:26:05,120 --> 00:26:07,590
>> Дакле, хајде да разговарамо мало
мало о обрасцима приступ.

613
00:26:07,590 --> 00:26:11,580
Када говоримо о носкл, то је
све о приступном обрасцу.

614
00:26:11,580 --> 00:26:13,550
Сада, СКЛ је ад хоц упита.

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
U redu?

628
00:26:35,800 --> 00:26:38,860
Имам ИД производа,
и да одговара ИД

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

630
00:26:41,080 --> 00:26:41,580
OK?

631
00:26:41,580 --> 00:26:44,350
То је 1: 1 однос
преко оних столова.

632
00:26:44,350 --> 00:26:46,970
>> Сада, све што су боокс--
имам је корен својства.

633
00:26:46,970 --> 00:26:47,550
Nema problema.

634
00:26:47,550 --> 00:26:48,230
Odlično.

635
00:26:48,230 --> 00:26:52,130
Један-на-један однос, имам све
подаци Морам да опишем ту књигу.

636
00:26:52,130 --> 00:26:54,770
Албумс-- албума имају трагове.

637
00:26:54,770 --> 00:26:56,470
То је оно што ми зовемо једни многе.

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

639
00:26:58,905 --> 00:27:00,780
Дакле, за сваку песму на
албум, могао сам

640
00:27:00,780 --> 00:27:02,570
још један рекорд у овој табели деце.

641
00:27:02,570 --> 00:27:04,680
Тако да сам створи један рекорд
у своје албуме табели.

642
00:27:04,680 --> 00:27:06,700
Ја стварам вишеструке записе
у табели трацкс.

643
00:27:06,700 --> 00:27:08,850
Један-на-многи однос.

644
00:27:08,850 --> 00:27:11,220
>> Овај однос је шта
зовемо многи до многих.

645
00:27:11,220 --> 00:27:11,750
OK?

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
>> OK.

653
00:27:33,290 --> 00:27:33,880
Дакле, идемо.

654
00:27:33,880 --> 00:27:38,040
Један-на-један је највишег нивоа
odnos; један-на-многе,

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
Тако НоСКЛ ради мало другачије.

660
00:27:55,660 --> 00:27:58,930
Размислимо о томе за тренутак шта је
Изгледа да да одем све моје производе.

661
00:27:58,930 --> 00:28:01,096
>> У релациону продавници, ја
Желим да све своје производе

662
00:28:01,096 --> 00:28:02,970
на листи свих мојих производа.

663
00:28:02,970 --> 00:28:04,910
То је много упита.

664
00:28:04,910 --> 00:28:07,030
Имам питање за све моје књиге.

665
00:28:07,030 --> 00:28:08,470
Имам питање од мојих албума.

666
00:28:08,470 --> 00:28:09,970
И имам питање за све моје видео снимке.

667
00:28:09,970 --> 00:28:11,719
И морам да га ставим
све заједно на листи

668
00:28:11,719 --> 00:28:15,250
и служе га натраг до
апликација која је то тражи.

669
00:28:15,250 --> 00:28:18,000
>> Да бисте добили своје књиге, да се придружим
Производи и књиге.

670
00:28:18,000 --> 00:28:21,680
Да бисте добили своје албуме, морам да се придруже
Производи, Албуми, и Трацкс.

671
00:28:21,680 --> 00:28:25,330
И да моје видео снимке, имам
да се придруже Производи за Видеос,

672
00:28:25,330 --> 00:28:28,890
придружи кроз Ацтор Видеос,
и доносе тхе Ацторс.

673
00:28:28,890 --> 00:28:31,020
Дакле, то је три питања.

674
00:28:31,020 --> 00:28:34,560
Врло сложена упита до
саставите један сет резултат.

675
00:28:34,560 --> 00:28:36,540
>> То је мање од оптималног.

676
00:28:36,540 --> 00:28:39,200
То је разлог зашто када говоримо
о структури података који је

677
00:28:39,200 --> 00:28:42,900
направљена да буде агностици за приступ
паттерн-- и то је сјајно.

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
>> To je kul.

682
00:28:50,440 --> 00:28:53,750
Ја сам дедуплицатед све моје глумце,
и ја одржава своје асоцијације

683
00:28:53,750 --> 00:28:55,200
У овом мапирања табели.

684
00:28:55,200 --> 00:29:00,620
Међутим, добијање података
престане да буде скупо.

685
00:29:00,620 --> 00:29:04,500
Шаљем ЦПУ целом систему
спајања ових података заједно структуре

686
00:29:04,500 --> 00:29:05,950
да би могли да повуку те податке назад.

687
00:29:05,950 --> 00:29:07,310
>> Па како да се око тога?

688
00:29:07,310 --> 00:29:11,200
У носкл се ради о
агрегацију, не нормализација.

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
Па у носкл нема
Структура на табели.

697
00:29:28,124 --> 00:29:30,540
Причаћемо мало о
како то функционише у Динамо ДБ.

698
00:29:30,540 --> 00:29:33,570
Али ви немате исти
атрибути и исте особине

699
00:29:33,570 --> 00:29:37,751
у сваком реду, у сваком појединачном
ставка, као што се ради у СКЛ табели.

700
00:29:37,751 --> 00:29:39,750
И шта ме ово омогућава
да урадите је да много тога

701
00:29:39,750 --> 00:29:41,124
и дај ми велику флексибилност.

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

703
00:29:45,360 --> 00:29:49,090
И у овом конкретном
Пример, све

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

705
00:29:51,930 --> 00:29:56,510
А производ за књигу мигхт
имају тип ИД, која обухвата књигу.

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

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

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

709
00:30:04,100 --> 00:30:05,990
Књига евиденције имају ове особине.

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

711
00:30:08,100 --> 00:30:11,289
Зато ћу да испуните
Књига објекат са овом тачком.

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

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

714
00:30:14,560 --> 00:30:17,340
Ох, имам потпуно другачија
обрада рутина за то,

715
00:30:17,340 --> 00:30:18,487
јер је албум.

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

717
00:30:19,320 --> 00:30:21,950
>> Дакле, апликација тиер-- сам
само изаберите све ове рекорде.

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
Ове стазе сада бецоме-- је
у суштини ово дете сто је

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

730
00:30:56,520 --> 00:30:57,975
Дакле, можете да урадите ово ДинамоДБ.

731
00:30:57,975 --> 00:30:59,810
То можете да урадите у МонгоДБ.

732
00:30:59,810 --> 00:31:01,437
То можете урадити у било ком носкл бази података.

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
То није случај у носкл.

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

750
00:31:46,512 --> 00:31:49,470
Идем да мало оде у страну овде
и причамо мало о томе.

751
00:31:49,470 --> 00:31:53,240
То је више врста од
маркетинг или тецхнологи--

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

753
00:31:55,660 --> 00:31:58,672
Али важно је да схватимо
јер ако погледамо врх

754
00:31:58,672 --> 00:32:00,380
овде у овој табели,
оно што гледамо

755
00:32:00,380 --> 00:32:04,030
је оно што називамо
Технологија хипе крива.

756
00:32:04,030 --> 00:32:06,121
А шта то значи
нова ствар долази до изражаја.

757
00:32:06,121 --> 00:32:07,120
Људи мисле да је то сјајно.

758
00:32:07,120 --> 00:32:09,200
Ја сам решио све моје проблеме.

759
00:32:09,200 --> 00:32:11,630
>> Ово може бити крај
све, бити на све.

760
00:32:11,630 --> 00:32:12,790
И они почну да га користите.

761
00:32:12,790 --> 00:32:14,720
И они кажу, ова ствар не ради.

762
00:32:14,720 --> 00:32:17,600
Ово није у реду.

763
00:32:17,600 --> 00:32:19,105
Стари ствар била боља.

764
00:32:19,105 --> 00:32:21,230
И они вратити да радим
ствари начин на који су били.

765
00:32:21,230 --> 00:32:22,730
И онда на крају
они иду, знаш шта?

766
00:32:22,730 --> 00:32:24,040
Ова ствар није тако лоше.

767
00:32:24,040 --> 00:32:26,192
Ох, то је како то ради.

768
00:32:26,192 --> 00:32:28,900
А кад схвате како је
радови, почну да се боље.

769
00:32:28,900 --> 00:32:32,050
>> А смешно ствар о томе
је, некако линија до које

770
00:32:32,050 --> 00:32:34,300
зовемо Технологија Усвајање Цурве.

771
00:32:34,300 --> 00:32:36,910
Дакле, оно што се дешава је да имамо
нека технологија окидач.

772
00:32:36,910 --> 00:32:39,100
У случају база података,
то је притисак података.

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

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

775
00:32:46,310 --> 00:32:47,830
>> Постаје превише скупо.

776
00:32:47,830 --> 00:32:49,790
Потребно је предуго за обраду података.

777
00:32:49,790 --> 00:32:50,890
Треба нам нешто боље.

778
00:32:50,890 --> 00:32:52,890
Добијате иноваторе
тамо ради око,

779
00:32:52,890 --> 00:32:55,050
покушава да сазна шта је решење.

780
00:32:55,050 --> 00:32:56,050
Шта је нова идеја?

781
00:32:56,050 --> 00:32:58,170
>> Који је следећи најбољи
начин да се ово?

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

783
00:32:59,530 --> 00:33:03,140
А људи са правим болом,
момци у крвавом ивици,

784
00:33:03,140 --> 00:33:06,390
они ће скочити на себи,
јер им је потребан одговор.

785
00:33:06,390 --> 00:33:09,690
Сада оно неизбежно и хаппенс--
то се дешава управо сада у носкл.

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
>> Али то је оно што је
дешава са носкл данас.

795
00:33:30,610 --> 00:33:33,900
Ако сте ходати у већини продавница,
они покушавају да буду НоСКЛ продавнице.

796
00:33:33,900 --> 00:33:36,510
Оно што они раде је
они користе носкл,

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

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
Не придружити податке у носкл.

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
Veoma važna.

821
00:34:29,870 --> 00:34:32,440
>> Тако да ћемо ући у ДинамоДБ.

822
00:34:32,440 --> 00:34:36,480
ДинамоДБ је АВС је
потпуно успео носкл платформу.

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
НоСКЛ података кластера на
скала, текући петабајта,

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
Šta to znači
теби оперативно?

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

840
00:35:16,330 --> 00:35:18,960
Сада чак и са аутоматизације,
који може трајати дуго.

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

842
00:35:21,480 --> 00:35:23,090
јер ја можда има услуге доле.

843
00:35:23,090 --> 00:35:26,070
>> Као што сам упдате ове базе података, ја
могао да уради блуе греен распоређивање

844
00:35:26,070 --> 00:35:29,420
где сам распореди и надоградњу пола моје
чворови, а затим надоградите другу половину.

845
00:35:29,420 --> 00:35:30,490
Узми ове доле.

846
00:35:30,490 --> 00:35:33,410
Дакле, управљање инфраструктуром
скала је изузетно болно.

847
00:35:33,410 --> 00:35:36,210
И АВС се тај бол од тога.

848
00:35:36,210 --> 00:35:39,210
И НоСКЛ базе података могу
бити изузетно болно

849
00:35:39,210 --> 00:35:41,780
због начина на који су скале.

850
00:35:41,780 --> 00:35:42,926
>> Сцале хоризонтално.

851
00:35:42,926 --> 00:35:45,550
Ако желите да добијете већи носкл
база података, можете купити још чворова.

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
АВС могу то да урадим.

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
Има доста другачији
укуси носкл.

858
00:35:58,750 --> 00:36:02,670
Они су све врсте добијања
мунгед заједно на овом тренутку.

859
00:36:02,670 --> 00:36:06,260
Можете погледати ДинамоДБ и рећи да,
обоје смо документ и кључна вредност

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
Не бих рекао да је боље или МонгоДБ
горе него Цоуцх, затим Цассандра,

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
Дакле, ово је једна од највећих
бонуси сте добили са АВС.

870
00:36:36,210 --> 00:36:40,850
Са ДинамоДБ је способност
да бисте добили ниску једну цифру

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
Интегрисани приступ цонтрол--
имамо оно што зовемо

876
00:36:55,660 --> 00:36:57,920
Идентитет Приступ за управљање, или ИАМ.

877
00:36:57,920 --> 00:37:01,980
Она прожима сваки систем,
сваки сервис који АВС нуди.

878
00:37:01,980 --> 00:37:03,630
ДинамоДБ није изузетак.

879
00:37:03,630 --> 00:37:06,020
Можете контролисати приступ
на ДинамоДБ табеле.

880
00:37:06,020 --> 00:37:09,960
Широм све своје рачуне од АВС
дефинисање улоге и дозволе приступа

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

882
00:37:12,140 --> 00:37:16,630
>> И то је кључни и саставни у
оно што ми зовемо догађај Дривен програмирање.

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

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

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

886
00:37:24,052 --> 00:37:26,260
Рицк Хоулихан: Труе позитиви
у односу на лажно негативних?

887
00:37:26,260 --> 00:37:28,785
ПУБЛИКА: враћа оно што
треба се вратити?

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

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

890
00:37:36,260 --> 00:37:38,050
>> Рицк Хоулихан: Нисам могао да вам кажем.

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

892
00:37:40,140 --> 00:37:42,726
Ја нисам особа да питам
да конкретно питање.

893
00:37:42,726 --> 00:37:43,850
Али то је добро питање.

894
00:37:43,850 --> 00:37:45,905
Ја бих био радознао да знам
да сам, у ствари.

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

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

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

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

899
00:37:59,720 --> 00:38:02,120
Без икаквог фиксна
инфраструктура уопште.

900
00:38:02,120 --> 00:38:04,720
И причаћемо мало
шта то значи као ми

901
00:38:04,720 --> 00:38:06,550
да на наредних неколико графикона.

902
00:38:06,550 --> 00:38:08,716
>> Прва ствар урадићемо
је причаћемо о табелама.

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

904
00:38:10,857 --> 00:38:13,190
И прва ствар коју ћете
приметити када погледате ово,

905
00:38:13,190 --> 00:38:17,930
Ако сте упознати са било којим базу података,
базе података су заиста две врсте АПИ

906
00:38:17,930 --> 00:38:18,430
Ја бих то назвао.

907
00:38:18,430 --> 00:38:21,570
Или два сета АПИ.

908
00:38:21,570 --> 00:38:23,840
Један од оних који ће бити
административни АПИ.

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
Ово ствари-- у ДинамоДБ, ви
имају веома кратке, кратке листе.

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
У ДинамоДБ не треба, јер оне
не подесите систем, радимо.

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
То су једине ствари
вам је потребно за ДинамоДБ.

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

922
00:39:03,294 --> 00:39:04,960
Не треба да бринете о репликација.

923
00:39:04,960 --> 00:39:06,490
Не треба да бринете о схардинг.

924
00:39:06,490 --> 00:39:07,800
>> Не треба да бринете
о било ком од ових ствари.

925
00:39:07,800 --> 00:39:08,740
Ми све радимо за вас.

926
00:39:08,740 --> 00:39:11,867
Дакле, то је огромна количина над главом
то је само скинут тањир.

927
00:39:11,867 --> 00:39:13,200
Затим имамо Цруд оператера.

928
00:39:13,200 --> 00:39:17,740
ЦРУД је нешто што смо
позовите у бази која је

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
Једна од добрих ствари о ДинамоДБ
је омогућава паралелно скенирање.

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

939
00:39:49,060 --> 00:39:51,490
>> Други АПИ за који имамо је
оно што зовемо наш потоци АПИ.

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
Али Потоци је заиста руннинг--
мислите о томе како време наредио

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
У ДинамоДБ, ми подржавамо оба кључа
вредност и података документ врсте.

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
Једна од лепих ствари о НоСКЛ је
можете садрже низове као особина.

958
00:40:37,650 --> 00:40:42,050
И са ДинамоДБ можете садрже низове
основних типова као роот имовине.

959
00:40:42,050 --> 00:40:43,885
>> А онда је врста докумената.

960
00:40:43,885 --> 00:40:45,510
Колико људи су упознати са ЈСОН?

961
00:40:45,510 --> 00:40:47,130
Ви упознати са ЈСОН толико?

962
00:40:47,130 --> 00:40:49,380
То је у основи ЈаваСцрипт
Објекат, нотација.

963
00:40:49,380 --> 00:40:52,510
То вам омогућава да у основи
дефинисати хијерархијску структуру.

964
00:40:52,510 --> 00:40:58,107
>> Можете похранити ЈСОН документ о
ДинамоДБ користећи заједничке компоненте

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

966
00:41:00,940 --> 00:41:03,602
Дакле, ако имате Јаву, ти си
гледајући мапе и листе.

967
00:41:03,602 --> 00:41:05,060
Ја могу креирати објекте који простор карту.

968
00:41:05,060 --> 00:41:08,030
Мапу као кључне вредности
складишти као особина.

969
00:41:08,030 --> 00:41:10,890
И то можда има спискове
Вредности унутар тих својстава.

970
00:41:10,890 --> 00:41:13,490
Можете сместити овај комплекс
хијерархијска структура

971
00:41:13,490 --> 00:41:16,320
као јединствени атрибут
од ДинамоДБ ставке.

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

973
00:41:19,010 --> 00:41:24,460
>> Тако столова у ДинамоДБ, као и већина
НоСКЛ базе података, столови имају ставке.

974
00:41:24,460 --> 00:41:26,469
У МонгоДБ ти би
зовем те документе.

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
У ДинамоДБ, ту је
један обавезан атрибут.

981
00:41:38,520 --> 00:41:43,880
Баш као у релационој бази података,
имате примарни кључ на столу.

982
00:41:43,880 --> 00:41:46,010
>> ДинамоДБ има оно што називамо тастер тараба.

983
00:41:46,010 --> 00:41:48,280
Хасх кључ мора бити јединствена.

984
00:41:48,280 --> 00:41:52,580
Дакле, када сам дефинисати хасх табелу,
у основи оно што ја говорим

985
00:41:52,580 --> 00:41:54,110
је свака ставка ће имати тастер тараба.

986
00:41:54,110 --> 00:41:58,520
И сваки тастер тараба мора бити јединствена.

987
00:41:58,520 --> 00:42:01,200
>> Свака јединица је дефинисана
до тог јединственог тастер тараба.

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

989
00:42:02,940 --> 00:42:05,820
То је у реду, али често
оно што људи требају

990
00:42:05,820 --> 00:42:08,170
је они желе је ово хасх
кључ да урадите мало више

991
00:42:08,170 --> 00:42:11,010
него само бити јединствени идентификатор.

992
00:42:11,010 --> 00:42:15,240
Често желимо да користимо тај тастер тараба
као највишем нивоу агрегације кофу.

993
00:42:15,240 --> 00:42:19,160
А начин на који ми то радимо је за
додајући оно што ми зовемо кључ домета.

994
00:42:19,160 --> 00:42:22,460
>> Дакле, ако је то само хасх
сто, то мора бити јединствена.

995
00:42:22,460 --> 00:42:27,040
Ако је хашиш и опсег столу,
комбинација хашиш и опсег

996
00:42:27,040 --> 00:42:28,640
мора бити јединствена.

997
00:42:28,640 --> 00:42:30,110
Размислите о томе на овај начин.

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

999
00:42:32,140 --> 00:42:39,010
И облик има тема, има
порука, и има одговоре.

1000
00:42:39,010 --> 00:42:42,630
>> Тако да можда има хасх
кључ, што је тема личну карту.

1001
00:42:42,630 --> 00:42:46,650
И можда има кључ опсег,
што је ИД одговор.

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
Желимо да табле--
као што стављате на сто,

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

1011
00:43:16,640 --> 00:43:20,140
да је апликација може врло
брзо преузели те резултате.

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

1013
00:43:24,510 --> 00:43:25,650
убаците податке.

1014
00:43:25,650 --> 00:43:31,110
У суштини, ми смо ширење податке
у светлим канту јер долази у.

1015
00:43:31,110 --> 00:43:35,210
>> Ранге тастери омогућавају ме-- хасх
Тастери морају бити једнакости.

1016
00:43:35,210 --> 00:43:39,490
Када сам куери хасх, морам да кажем
дај ми хасх која се своди на то.

1017
00:43:39,490 --> 00:43:41,950
Када сам куери низ, ја
могу да кажем да ми низ

1018
00:43:41,950 --> 00:43:47,040
да се користи било какву
богата оператер који ми подржавамо.

1019
00:43:47,040 --> 00:43:49,200
Дај ми све ставке за хасх.

1020
00:43:49,200 --> 00:43:52,520
Да ли је једнак, већи од,
мање него, то почиње,

1021
00:43:52,520 --> 00:43:54,145
то постоји између ове две вредности?

1022
00:43:54,145 --> 00:43:56,811
Дакле ове врсте опсега упита
да смо увијек интересују.

1023
00:43:56,811 --> 00:43:59,650
Сада једна ствар о подацима, када
погледате приступ подацима, када

1024
00:43:59,650 --> 00:44:02,360
можете приступити подацима, то је
Увек се ради о једном груписања.

1025
00:44:02,360 --> 00:44:05,770
Увек се ради о евиденцији
који се односе на ово.

1026
00:44:05,770 --> 00:44:10,390
Дај ми све овде је-- све
трансакције на овом кредитне картице

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
НоСКЛ базе података ради најбоље
када су подаци равномерно

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
Када кажем хасх и хасхинг--
јер је хасхинг алгоритам

1041
00:44:49,860 --> 00:44:54,140
је начин да буде у стању да генерише
насумичним вредностима од било ког датог вредности.

1042
00:44:54,140 --> 00:44:59,300
Дакле, у овом конкретном случају,
хасх алгоритам трчимо је НД 5 басед.

1043
00:44:59,300 --> 00:45:04,765
>> И ако имам личну карту, и то
је мој тастер тараба, Имам 1, 2, 3.

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

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

1046
00:45:10,800 --> 00:45:13,092
Они шире по целом кључног простору.

1047
00:45:13,092 --> 00:45:14,050
А зашто то радиш?

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

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

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

1051
00:45:21,990 --> 00:45:24,785
мали хасх простор,
она траје од 00 до ФФ,

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
Šta se dešava?

1055
00:45:31,800 --> 00:45:34,860
Сваки уметак иде на исти чвор.

1056
00:45:34,860 --> 00:45:36,070
Видиш шта мислим?

1057
00:45:36,070 --> 00:45:40,910
>> Јер кад сам поделити простор,
и ја проширила ове записе преко,

1058
00:45:40,910 --> 00:45:45,950
и ја партиција, ја ћу рећи
партиција 1 има кључну простор 0 до 54.

1059
00:45:45,950 --> 00:45:47,720
Подела 2 је 55 до 89.

1060
00:45:47,720 --> 00:45:49,780
Подела 3 је А. у ФФ.

1061
00:45:49,780 --> 00:45:53,740
Дакле, ако сам користећи линеарно увецава
Личне карте, можете видети шта се дешава.

1062
00:45:53,740 --> 00:45:57,410
1, 2, 3, 4, 5, 6, све тако редом до 54.

1063
00:45:57,410 --> 00:46:00,030
Дакле, као што сам чекићем
евиденције у систем,

1064
00:46:00,030 --> 00:46:02,030
све завршава ће једног чвора.

1065
00:46:02,030 --> 00:46:03,160
>> To nije dobro.

1066
00:46:03,160 --> 00:46:04,820
То је антипаттерн.

1067
00:46:04,820 --> 00:46:08,760
У МонгоДБ имају овај проблем
ако не користите тастер тараба.

1068
00:46:08,760 --> 00:46:11,325
МонгоДБ вам даје опцију
од хасхинг кључну вредност.

1069
00:46:11,325 --> 00:46:13,950
Увек треба урадити, ако
ви користите инцрементинг хасх

1070
00:46:13,950 --> 00:46:17,380
кључ у МонгоДБ, или ћете бити
ексерима сваки Пишите једног чвора,

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

1072
00:46:21,290 --> 00:46:24,896
>> ПУБЛИКА: Да ли је то А9 169 у децимале?

1073
00:46:24,896 --> 00:46:28,450
>> Рицк Хоулихан: Да, то је
ту негде.

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

1075
00:46:29,950 --> 00:46:32,200
Мораш да узмем бинарни
да децимални калкулатора.

1076
00:46:32,200 --> 00:46:34,237
Мој мозак не функционише тако.

1077
00:46:34,237 --> 00:46:36,320
ПУБЛИКА: Само на брзака
ваше монго коментара.

1078
00:46:36,320 --> 00:46:39,530
Тако је ИД објекта који долази
изворно са Монго то?

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

1080
00:46:40,179 --> 00:46:41,470
Рицк Хоулихан: Да ли је то?

1081
00:46:41,470 --> 00:46:42,970
Ако га наведете.

1082
00:46:42,970 --> 00:46:45,030
Са МонгоДБ, имате опцију.

1083
00:46:45,030 --> 00:46:48,930
Можете специфи-- сваки документ у
МонгоДБ мора да има доњу ИД.

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

1085
00:46:50,300 --> 00:46:55,240
>> У МонгоДБ можете одредити
да ли да га хасх или не.

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
валуе-- а ово је
зашто хасх тастери су увек

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
То је разлог зашто у ДинамоДБ тастер тараба
упити су увек само једнакост.

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

1098
00:47:32,090 --> 00:47:34,700
>> Тако сада у распону кеи--
кад додам тај кључ опсег,

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

1113
00:48:18,840 --> 00:48:20,760
Људи причају о
НоСКЛ као нонрелатионал.

1114
00:48:20,760 --> 00:48:22,200
Није нонрелатионал.

1115
00:48:22,200 --> 00:48:24,680
Подаци увек има везе.

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

1117
00:48:28,172 --> 00:48:29,880
Хајде да причамо мало
мало о трајности.

1118
00:48:29,880 --> 00:48:34,860
Када пишете да ДинамоДБ, пише
су увек три начина реплицирати.

1119
00:48:34,860 --> 00:48:37,550
То значи да имамо три АЗ-а.

1120
00:48:37,550 --> 00:48:39,160
АЗ је су доступност зоне.

1121
00:48:39,160 --> 00:48:43,430
Можете мислити на доступност
Зона као дата центар

1122
00:48:43,430 --> 00:48:45,447
или скуп дата центара.

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

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

1125
00:48:51,610 --> 00:48:54,510
Неуспех у једном АЗ није
це да скину други.

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

1127
00:48:56,890 --> 00:49:01,240
Она подржава један суб 1
милисекунди кашњења између АЗС.

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
Дакле, ДинамоДБ се шири
преко три АЗС по дефаулту.

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
Zašto je to?

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
То је оно што чини ДинамоДБ доследан.

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
Када читате ДинамоДБ, и
ви подешавање капацитета реад

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
To je lepo.

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

1161
00:50:26,950 --> 00:50:27,783
>> Šta to znači?

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
Остали атрибути на том итем--
Ја могу филтрирати по тим атрибутима.

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

1166
00:50:40,050 --> 00:50:40,820
>> Kako da uradim to?

1167
00:50:40,820 --> 00:50:42,860
Ја стварам индекс.

1168
00:50:42,860 --> 00:50:45,340
Постоје две врсте
индекси у ДинамоДБ.

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
можда је договорено на делу ИД, ја
може створити индекс са тог стола

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
ДинамоДБ, под
столови, партиције

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

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

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

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

1207
00:52:42,070 --> 00:52:43,200
Ми ћемо поделити сто.

1208
00:52:43,200 --> 00:52:44,679
Али нећемо подијелити ЛСИ.

1209
00:52:44,679 --> 00:52:46,470
Дакле, то је нешто
важно разумети

1210
00:52:46,470 --> 00:52:50,070
је ако радите веома,
врло, врло велике агрегације,

1211
00:52:50,070 --> 00:52:53,860
онда ћеш бити ограничена
до 10 гигабајта на вашем ЛСИс.

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

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

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

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

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

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

1218
00:53:09,220 --> 00:53:11,360
>> Ја могу да дефинишу потпуно
другачије тастер тараба.

1219
00:53:11,360 --> 00:53:13,490
Ја могу да дефинишу потпуно
другачији опсег кључ.

1220
00:53:13,490 --> 00:53:15,941
И могу покренути ово
потпуно самостално.

1221
00:53:15,941 --> 00:53:18,190
У ствари, ја сам
снабдевени моју способност читања

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

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

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

1225
00:53:26,640 --> 00:53:28,610
Капацитет ће то користити.

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

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

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

1229
00:53:38,610 --> 00:53:44,950
Дакле, ако желим да очита индекс,
и ја желим да мало скуп података,

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

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

1232
00:53:50,660 --> 00:53:53,440
да подрже приступ образац.

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

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
>> ПУБЛИКА: [неразумљиво]
--ТАБЛЕ кључни мислио хасх?

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

1238
00:54:08,840 --> 00:54:09,340
Мулти-лајсне?

1239
00:54:09,340 --> 00:54:10,200
>> Рицк Хоулихан: Да.

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
>> Ја стварно треба само знати вхицх--
мој приступ образац може рећи,

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

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

1250
00:54:35,780 --> 00:54:37,800
Само морам да знам
које ставке га садрже.

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

1252
00:54:40,700 --> 00:54:43,360
>> Али то је, пре свега, шта
индекс у бази података је за.

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

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

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

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

1257
00:54:53,610 --> 00:54:54,860
>> ГСИС, па како они раде?

1258
00:54:54,860 --> 00:54:58,340
ГСИС основи су асинхрони.

1259
00:54:58,340 --> 00:55:02,570
Упдате долази у табели,
сто се онда асинхроно ажурира

1260
00:55:02,570 --> 00:55:03,720
сву своју ГСИС.

1261
00:55:03,720 --> 00:55:06,680
То је разлог зашто су ГСИС
на крају доследан.

1262
00:55:06,680 --> 00:55:09,440
>> Важно је напоменути да
када правите ГСИС,

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

1264
00:55:13,110 --> 00:55:16,594
Сада рецимо добар пример
овде је произвођач.

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

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

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

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

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

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

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

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

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

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

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

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

1277
00:55:50,550 --> 00:55:53,156
јер они стварају
ови Гинормоус агрегације

1278
00:55:53,156 --> 00:55:54,280
у својим средњим индекса.

1279
00:55:54,280 --> 00:55:57,070
Они можда има сиров делова
Табела која долази само као хасх.

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

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

1282
00:56:00,975 --> 00:56:01,600
Prelepo je.

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

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

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

1286
00:56:07,876 --> 00:56:09,500
Онда је оно што раде они стварају ГСИ.

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

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

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

1290
00:56:17,550 --> 00:56:21,170
Ја агрегата као
Мануфацтурер ИД као хасх,

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

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

1293
00:56:30,530 --> 00:56:34,447
>> То може изазвати много
притиска на ГСИ,

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
Али шта се дешава, да ли је ГСИ може
нема довољно капацитета писања

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
примарни сто ће бити тхроттлед
јер ГСИ не може издржати.

1303
00:57:00,180 --> 00:57:02,980
Дакле, мој уметак стопа
падају на примарној табели

1304
00:57:02,980 --> 00:57:06,230
као што је мој ГСИ покушава да одржи корак.

1305
00:57:06,230 --> 00:57:08,850
>> У реду, тако ГСИ-а, ЛСИ је,
која треба да користим?

1306
00:57:08,850 --> 00:57:12,290
ЛСИ је у складу.

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

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

1309
00:57:17,490 --> 00:57:20,270
ЛСИ је да се моделира као ГСИ.

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

1311
00:57:27,040 --> 00:57:31,050
онда ћеш да желите да користите да
ГСИ јер то је само тешко граница.

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

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

1314
00:57:35,210 --> 00:57:37,460
Проток у Динамо ДБ, ви
Цан одредба [неразумљиво]

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

1316
00:57:38,680 --> 00:57:42,740
Имамо купце који имају
снабдевени 60 биллион--

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

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

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

1320
00:57:50,360 --> 00:57:53,730
и колико брзо сто
може покренути у Динамо ДБ.

1321
00:57:53,730 --> 00:57:55,920
Постоје неки меки
ограничења на ваш рачун

1322
00:57:55,920 --> 00:57:58,170
да смо у тамо ставио тако
да не полудиш.

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

1324
00:58:00,070 --> 00:58:00,820
Дошао си реци нам.

1325
00:58:00,820 --> 00:58:02,810
Ми ћемо се појавити бројчаник.

1326
00:58:02,810 --> 00:58:08,210
>> Сваки рачун је ограничена на неком нивоу
у сваком служби, само искључити шишмиш

1327
00:58:08,210 --> 00:58:11,920
тако да људи не полуде
да се у невољу.

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

1329
00:58:12,840 --> 00:58:14,940
Можете ставити било који број
ставки на столу.

1330
00:58:14,940 --> 00:58:17,620
Величина неке ставке је
ограничена на 400 килобајта сваки,

1331
00:58:17,620 --> 00:58:20,050
то би било предмет не атрибути.

1332
00:58:20,050 --> 00:58:24,200
Дакле, збир свих атрибута
је ограничен на 400 килобајта.

1333
00:58:24,200 --> 00:58:27,300
А онда опет, имамо
то мало ЛСИ питање

1334
00:58:27,300 --> 00:58:30,405
са лимитом од 10 гигабајта по хасх.

1335
00:58:30,405 --> 00:58:33,280
ПУБЛИКА: Мали број, ми недостаје
шта ми говориш, да је--

1336
00:58:33,280 --> 00:58:36,830
ПУБЛИКА: О, 400 килобајта
је максимална величина по комаду.

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

1338
00:58:39,570 --> 00:58:43,950
Дакле, 400 к је укупна величина
те ставке, 400 килобајта.

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

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

1341
00:58:49,140 --> 00:58:51,140
Тренутно је данас граница ставка 400 К.

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

1343
00:58:54,390 --> 00:58:57,046
Дакле, опет скалирање, постићи
кроз поделу.

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

1345
00:58:58,920 --> 00:59:00,160
И заиста постоје две ручке.

1346
00:59:00,160 --> 00:59:02,400
Прочитали смо капацитете
и пише капацитета.

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

1348
00:59:05,530 --> 00:59:08,640
РЦУ је мера строго у складу чита.

1349
00:59:08,640 --> 00:59:13,005
У реду, тако да ако кажем да желим 1,000
РЦУ је да су то строго у складу,

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

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

1352
00:59:17,130 --> 00:59:19,402
можете одредба 1,000
РЦУ је, идеш

1353
00:59:19,402 --> 00:59:21,840
да се на крају 2,000
у складу чита.

1354
00:59:21,840 --> 00:59:25,940
И пола цене за оне
на крају се састоје у саопштењу.

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

1356
00:59:28,520 --> 00:59:32,900
И они имају тхроугхпут--
Ако конзумирате 100% свог РЦУ,

1357
00:59:32,900 --> 00:59:35,960
нећеш да утицати на
доступност ваших права.

1358
00:59:35,960 --> 00:59:40,161
Дакле, потпуно су
независне једна од друге.

1359
00:59:40,161 --> 00:59:43,160
У реду, тако да једна од ствари које
Поменуо сам кратко је гушење.

1360
00:59:43,160 --> 00:59:44,320
Пропорционално је лоше.

1361
00:59:44,320 --> 00:59:47,311
Пропорционално указује на лоше не СКЛ.

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
То је оно што лоше НоСКЛ изгледа.

1393
01:01:06,790 --> 01:01:07,830
>> Имам топлу кључ овде.

1394
01:01:07,830 --> 01:01:10,246
Ако погледате на овој страни,
ово су све моје партиције.

1395
01:01:10,246 --> 01:01:12,630
Имам 16 партиција овде
на овој бази података.

1396
01:01:12,630 --> 01:01:13,630
Све време смо то.

1397
01:01:13,630 --> 01:01:15,046
Ја водим ово за купце све време.

1398
01:01:15,046 --> 01:01:16,550
То се зове мапа топлоте.

1399
01:01:16,550 --> 01:01:20,590
Топлотна мапа ми је рекао како си ти
приступу свој кључни простор.

1400
01:01:20,590 --> 01:01:23,700
А шта је ово ми говори је
да постоји један посебан хасх

1401
01:01:23,700 --> 01:01:26,330
да је овај момак воли
јако много, јер је

1402
01:01:26,330 --> 01:01:28,250
је забио стварно тешко.

1403
01:01:28,250 --> 01:01:29,260
>> Дакле, плава је лепо.

1404
01:01:29,260 --> 01:01:29,900
Ми волимо плаво.

1405
01:01:29,900 --> 01:01:30,720
Ми не волимо црвено.

1406
01:01:30,720 --> 01:01:33,120
Ред, где је притисак
устаје до 100%.

1407
01:01:33,120 --> 01:01:35,560
100%, сад ћеш да тхроттлед.

1408
01:01:35,560 --> 01:01:39,030
Дакле, кад год видите неке црвене линије као што су
Ово-- и то није само Динамо ДБ--

1409
01:01:39,030 --> 01:01:41,630
свака НоСКЛ база података има овај проблем.

1410
01:01:41,630 --> 01:01:44,640
Постоје анти-обрасци који може
возити ове врсте услова.

1411
01:01:44,640 --> 01:01:49,070
Оно што ја радим је да ради са клијентима
да ублажи ових услова.

1412
01:01:49,070 --> 01:01:51,840
>> А шта то личи?

1413
01:01:51,840 --> 01:01:54,260
И то је све највише
Динамо из ДБ протока,

1414
01:01:54,260 --> 01:01:56,176
али то је стварно постаје
највише од носкл.

1415
01:01:56,176 --> 01:01:58,740
Ово није ограничено на Динамом.

1416
01:01:58,740 --> 01:02:02,050
Ово је дефинители-- сам
Радила у Монго.

1417
01:02:02,050 --> 01:02:04,090
Упознат сам са многим НоСКЛ платформама.

1418
01:02:04,090 --> 01:02:06,830
Свако има ове врсте
врућих кључних проблема.

1419
01:02:06,830 --> 01:02:10,320
Да бисте добили највише од било које носкл
база података, посебно Динамо ДБ

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
Дакле, оно што добијате са носкл је
Подаци шема која је апсолутно

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

1452
01:03:38,510 --> 01:03:42,170
>> И ви можете оптимизовати те податке шему
да подржи да приступ образац.

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

1454
01:03:45,490 --> 01:03:46,710
са тим врућим тастерима.

1455
01:03:46,710 --> 01:03:50,518
>> ПУБЛИКА: Па, неминовно нека места
ће бити топлије од других.

1456
01:03:50,518 --> 01:03:51,450
>> Рицк Хоулихан: Увек.

1457
01:03:51,450 --> 01:03:51,960
Увек.

1458
01:03:51,960 --> 01:03:54,620
Да, мислим увек постоји
је-- и опет, ту је

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
Ови момци су Адролл.

1465
01:04:06,950 --> 01:04:08,990
Ја не знам да ли си
упознат са Адролл.

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

1479
01:04:42,070 --> 01:04:44,920
или у основи не кажеш то--
али када одете на сајт

1480
01:04:44,920 --> 01:04:47,550
кажу да желе да виде овај оглас.

1481
01:04:47,550 --> 01:04:49,370
И они да узмемо ту рекламу из Адролл.

1482
01:04:49,370 --> 01:04:51,130
Адролл вас гледа се на њиховом столу.

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
>> Сада имају СЛА са
њихове рекламне провајдери

1489
01:05:10,330 --> 01:05:14,510
да обезбеди Суб-10 милисекунди
одговор на сваки захтев.

1490
01:05:14,510 --> 01:05:16,090
Дакле, они користе Динамо ДБ за то.

1491
01:05:16,090 --> 01:05:18,131
Они нас је ударање
милион захтева у секунди.

1492
01:05:18,131 --> 01:05:21,120
Они су у стању да уради све њихове
лоокупс, тријажа сви подаци,

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
>> Ови момци стварно--
да ли су ово момци.

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
У основи нас-- рекао не,
не мислим да их је било.

1499
01:05:42,210 --> 01:05:43,000
Мислим да је то био неко други.

1500
01:05:43,000 --> 01:05:44,750
Ја сам радио са
купац који ми је рекао

1501
01:05:44,750 --> 01:05:47,040
да сада када имам
отишао у Динамо ДБ, они су

1502
01:05:47,040 --> 01:05:50,330
троше више новца на грицкалице за
њихов развојни тим сваког месеца

1503
01:05:50,330 --> 01:05:52,886
него они троше на њиховој бази података.

1504
01:05:52,886 --> 01:05:54,760
Тако да ћу вам дати један
Идеја о уштедама

1505
01:05:54,760 --> 01:05:57,889
да можете добити у Динамо ДБ је огромна.

1506
01:05:57,889 --> 01:05:59,430
У реду, дропцам је друга компанија.

1507
01:05:59,430 --> 01:06:02,138
Ово момак је некако од-- ако мислите
интернет ствари, дропцам

1508
01:06:02,138 --> 01:06:05,150
је у основи Интернет Сецурити Видео.

1509
01:06:05,150 --> 01:06:06,660
Ставио своју камеру тамо.

1510
01:06:06,660 --> 01:06:08,180
Камера има детектор покрета.

1511
01:06:08,180 --> 01:06:10,290
Неко дође,
изазива Цуе Поинт.

1512
01:06:10,290 --> 01:06:13,540
Камера започиње снимање неко време до
то више не детектује било какво кретање.

1513
01:06:13,540 --> 01:06:15,310
Ставља тај видео на интернету.

1514
01:06:15,310 --> 01:06:19,800
>> Дропцам је компанија која је
у основи укључен у Динамо ДБ

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
Више долазни Видео од ИоуТубе
је оно што су ови момци добити.

1519
01:06:32,310 --> 01:06:36,780
Они користе ДинамоДБ пратити све
метаподатака на свим својим видео кључним тачкама.

1520
01:06:36,780 --> 01:06:40,282
>> Дакле, они имају С3 кашике гурају
све бинарни артефакти во.

1521
01:06:40,282 --> 01:06:41,990
И онда они имају
Динамо ДБ записи који

1522
01:06:41,990 --> 01:06:44,070
указују на те С3 три објекта.

1523
01:06:44,070 --> 01:06:47,070
Када треба да погледате видео снимак,
изгледају горе рекорд у Динамо ДБ.

1524
01:06:47,070 --> 01:06:47,903
Они кликните на линк.

1525
01:06:47,903 --> 01:06:49,770
Они спустите видео из С3.

1526
01:06:49,770 --> 01:06:51,590
Дакле, то је некако како ово изгледа.

1527
01:06:51,590 --> 01:06:53,580
А ово је право из њиховог тима.

1528
01:06:53,580 --> 01:06:56,010
>> Динамо ДБ умањује њихову
Време испоруке за видео догађаје

1529
01:06:56,010 --> 01:06:57,590
од пет до 10 секунди.

1530
01:06:57,590 --> 01:07:00,470
У свом старом релациону продавници,
они морали да иду и извршавање

1531
01:07:00,470 --> 01:07:03,780
више сложених упита да схватим
од видео клипова који се спусти,

1532
01:07:03,780 --> 01:07:06,690
на мање од 50 милисекунди.

1533
01:07:06,690 --> 01:07:08,990
Дакле, то је невероватно, невероватно
колико перформансе

1534
01:07:08,990 --> 01:07:12,990
можете добити када оптимизацију и
подесите је основна база података

1535
01:07:12,990 --> 01:07:15,110
да подрже приступ образац.

1536
01:07:15,110 --> 01:07:20,500
Халфбрицк, ови момци, шта је то,
Фруит Ниња Претпостављам да је њихова ствар.

1537
01:07:20,500 --> 01:07:22,590
То све ради на Динамо ДБ.

1538
01:07:22,590 --> 01:07:26,810
А ови момци, они су велики
Развојни тим, велики напредак

1539
01:07:26,810 --> 01:07:27,670
продавница.

1540
01:07:27,670 --> 01:07:29,364
>> Није добра Опс тим.

1541
01:07:29,364 --> 01:07:31,280
Нису имали много
од оперативних ресурса.

1542
01:07:31,280 --> 01:07:33,940
Они су се борили покушава да задржи
њихова примена инфраструктуре до

1543
01:07:33,940 --> 01:07:34,290
и ради.

1544
01:07:34,290 --> 01:07:35,000
Они су дошли до нас.

1545
01:07:35,000 --> 01:07:36,251
Гледали су у том Динамо ДБ.

1546
01:07:36,251 --> 01:07:37,291
Рекли су да је то за нас.

1547
01:07:37,291 --> 01:07:39,470
Они су изградили своје цело
Апликација оквир за њега.

1548
01:07:39,470 --> 01:07:43,640
Неке заиста лепе коментари овде
из тима на њихову способност

1549
01:07:43,640 --> 01:07:46,800
сада фокусирати на изградњу
игра и не

1550
01:07:46,800 --> 01:07:49,010
морају да одржавати
инфраструктура, која

1551
01:07:49,010 --> 01:07:51,910
је постао огроман
надземних за свој тим.

1552
01:07:51,910 --> 01:07:56,170
Дакле, ово је нешто то--
корист да ћете добити од Динама ДБ.

1553
01:07:56,170 --> 01:08:00,930
>> У реду, узимајући у
Подаци моделирање овде.

1554
01:08:00,930 --> 01:08:03,440
Разговарали смо мало о
овај један према један, један до многе,

1555
01:08:03,440 --> 01:08:05,060
и многи многим типа односа.

1556
01:08:05,060 --> 01:08:07,630
И како да одржите оне у Динамом.

1557
01:08:07,630 --> 01:08:10,500
У Динамо ДБ користимо
индекси, уопштено говорећи,

1558
01:08:10,500 --> 01:08:12,910
ротирати податке из
човек укус на другу.

1559
01:08:12,910 --> 01:08:15,210
Хасх тастери, тастери опсег, и индекси.

1560
01:08:15,210 --> 01:08:18,540
>> У овом конкретном
Пример, као и већина држава

1561
01:08:18,540 --> 01:08:23,802
имају обавезу лиценцирања који
Само један возачка дозвола по особи.

1562
01:08:23,802 --> 01:08:26,510
Не могу да се два возача
лиценце у стању Бостону.

1563
01:08:26,510 --> 01:08:27,500
Не могу то учинити у Тексасу.

1564
01:08:27,500 --> 01:08:28,708
То је врста онако како је.

1565
01:08:28,708 --> 01:08:32,779
И тако на ДМВ, имамо лоокупс, ми
Желим да се угледају на возачку дозволу

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
Сада на тој Табела И
може да дефинише ГСИ који

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
број или други атрибути би а
број лиценце, могу упит ГСИ.

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

1578
01:09:08,689 --> 01:09:12,460
Само врло једноставна ГСИ
флип те ствари.

1579
01:09:12,460 --> 01:09:13,979
Сада, говоримо о један до многих.

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

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

1582
01:09:20,510 --> 01:09:23,880
Монитор података долази у редовно
Интервал, као интернет ствари.

1583
01:09:23,880 --> 01:09:26,890
Ми смо увек добити све ово
евиденција долази све време.

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

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

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

1587
01:09:38,430 --> 01:09:42,250
Имам мерења уређаја табелу
са тастер тараба на ИД уређаја.

1588
01:09:42,250 --> 01:09:47,340
И ја имам опсег тастер на
Време, или у овом случају, епска.

1589
01:09:47,340 --> 01:09:50,350
И то ми омогућава извршавање комплекс
упити против тог тастера ранге

1590
01:09:50,350 --> 01:09:54,950
и вратити оне записе који
су релативне до резултата

1591
01:09:54,950 --> 01:09:56,310
сет да тражим.

1592
01:09:56,310 --> 01:09:58,360
И гради да је један
многима везу

1593
01:09:58,360 --> 01:10:02,340
у примарној табели, користећи
тастер тараба, опсег кључ структура.

1594
01:10:02,340 --> 01:10:04,600
>> Тако да је некако изградио
у табели у Динамо ДБ.

1595
01:10:04,600 --> 01:10:07,290
Када сам дефинишемо хасх
и опсег Т сто, ја сам

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
А за овом конкретном примеру,
Поново ћемо користити ГСИ-а.

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

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

1602
01:10:26,500 --> 01:10:29,600
И за дату игре,
желите да пронађете све кориснике.

1603
01:10:29,600 --> 01:10:31,010
Па како то да урадим?

1604
01:10:31,010 --> 01:10:34,330
Мој усер игре сто ја идем
да има тараба кључ кориснички ИД

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
А онда на ГСИ,
Ја ћу флип да око.

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
Ја упита ГСИ.

1614
01:10:53,887 --> 01:10:54,970
Видиш како то радимо?

1615
01:10:54,970 --> 01:10:58,369
Ви градити ове ГСИ је да подржи
случај употребе, апликација, приступ

1616
01:10:58,369 --> 01:10:59,410
образац, апликација.

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

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

1619
01:11:03,500 --> 01:11:05,850
Ако не, није ме брига.

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

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

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

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

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

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

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

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

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

1629
01:11:33,710 --> 01:11:37,831
Дакле, у Динамо ДБ имамо
могућност израде

1630
01:11:37,831 --> 01:11:39,330
оно што ми зовемо пројекције изразе.

1631
01:11:39,330 --> 01:11:42,660
Пројекција изрази су једноставно
брање поља или вредности

1632
01:11:42,660 --> 01:11:44,290
који желите да прикажете.

1633
01:11:44,290 --> 01:11:46,000
У реду, тако да сам направи избор.

1634
01:11:46,000 --> 01:11:48,010
Правим упит против Динама из ДБ.

1635
01:11:48,010 --> 01:11:51,730
И ја кажем, знаш шта, представа
ми само су критике пет звездица

1636
01:11:51,730 --> 01:11:54,544
за одређени производ.

1637
01:11:54,544 --> 01:11:55,710
Дакле, то је све што желим да видим.

1638
01:11:55,710 --> 01:11:57,320
Не желим да видим све
остали атрибути реду,

1639
01:11:57,320 --> 01:11:58,319
Ја само желим да видим ово.

1640
01:11:58,319 --> 01:12:01,209
То је исто као у СКЛ када
кажу изаберите звезду или из табеле,

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
То је иста ствар у
Динамо ДБ или још НоСКЛ базе података.

1644
01:12:09,070 --> 01:12:14,510
Филтер изрази дозволите да
у основи смањи резултат спусти.

1645
01:12:14,510 --> 01:12:15,540
Зато се трудим да упит.

1646
01:12:15,540 --> 01:12:17,260
Упит могу вратити са 500 предмета.

1647
01:12:17,260 --> 01:12:20,255
Али ја само желим ставке које
има атрибут који каже ово.

1648
01:12:20,255 --> 01:12:23,380
У реду, хајде да филтрирају те ставке
који не одговара тог конкретног упит.

1649
01:12:23,380 --> 01:12:25,540
Дакле, имамо филтер изразе.

1650
01:12:25,540 --> 01:12:28,310
>> Филтер изрази могу
да се покрене на било ком атрибуту.

1651
01:12:28,310 --> 01:12:30,260
Они нису као опсег упита.

1652
01:12:30,260 --> 01:12:32,690
Побуди су селективни.

1653
01:12:32,690 --> 01:12:36,470
Филтер упита ме захтевају да одем
добијате целе резултати сет, а затим

1654
01:12:36,470 --> 01:12:39,170
пробију податке не желим.

1655
01:12:39,170 --> 01:12:40,660
Зашто је то важно?

1656
01:12:40,660 --> 01:12:42,770
Јер, све сам прочитао.

1657
01:12:42,770 --> 01:12:46,597
У упит, ја ћу да прочитам и
то ће бити огроман о подацима.

1658
01:12:46,597 --> 01:12:48,430
А онда ћу
исећи шта ми треба.

1659
01:12:48,430 --> 01:12:52,080
И ако сам само резбарење оут а
пар редова, онда је то у реду.

1660
01:12:52,080 --> 01:12:53,620
То није тако неефикасна.

1661
01:12:53,620 --> 01:12:57,800
>> Али ако читам целу гомилу
података, само да пробију један предмет,

1662
01:12:57,800 --> 01:13:01,490
онда ћу бити бољи
са употребом упит опсег,

1663
01:13:01,490 --> 01:13:03,030
јер је много селективна.

1664
01:13:03,030 --> 01:13:06,330
То ће ме спасити много
новац, јер сам платити за то реад.

1665
01:13:06,330 --> 01:13:10,430
Где су резултати које врати
цросс ту жицу може бити мањи,

1666
01:13:10,430 --> 01:13:11,890
али ја плаћам за читање.

1667
01:13:11,890 --> 01:13:14,340
Па разумем како
ви добијате податке.

1668
01:13:14,340 --> 01:13:16,420
То је веома важно у Динамо ДБ.

1669
01:13:16,420 --> 01:13:19,710
>> Условне изрази, то је оно што
можете назвати оптимистично закључавање.

1670
01:13:19,710 --> 01:13:28,470
Ажурирање ако постоји, или ако ове вредности
је еквивалент ономе што сам одредити.

1671
01:13:28,470 --> 01:13:31,494
И ако имам времена печат на
запис, можда читају податке.

1672
01:13:31,494 --> 01:13:32,535
Ја могу променити те податке.

1673
01:13:32,535 --> 01:13:35,030
Могао бих да одем напишем да
Подаци назад у базу података.

1674
01:13:35,030 --> 01:13:38,100
Ако је неко променио плочу,
су временски маркери можда променио.

1675
01:13:38,100 --> 01:13:40,370
На тај начин моја условна
ажурирање може рећи упдате

1676
01:13:40,370 --> 01:13:42,340
ако је тиместамп једнака ово.

1677
01:13:42,340 --> 01:13:46,290
Или ажурирање неће успети, јер некоме
упдатед рекорд у међувремену.

1678
01:13:46,290 --> 01:13:48,290
>> То је оно што ми зовемо оптимистично закључавање.

1679
01:13:48,290 --> 01:13:50,670
То значи да је неко
може ући и промените га,

1680
01:13:50,670 --> 01:13:53,100
и ја ћу да га открију
кад се вратим да напишем.

1681
01:13:53,100 --> 01:13:56,106
И онда се могу прочитати да
података и кажем, ох, он је променио то.

1682
01:13:56,106 --> 01:13:57,230
Морам да рачун за то.

1683
01:13:57,230 --> 01:14:00,490
И могу промијенити податке у мом
снимити и примењују други упдате.

1684
01:14:00,490 --> 01:14:04,330
Дакле, можете ухватити оне постепен
исправке које се јављају између времена

1685
01:14:04,330 --> 01:14:08,740
да читају податке и
Време можете писати податке.

1686
01:14:08,740 --> 01:14:11,520
>> ПУБЛИКА: А филтер
израз заправо не значи

1687
01:14:11,520 --> 01:14:13,020
у броју или не--

1688
01:14:13,020 --> 01:14:14,316
>> [Ставим Воицес]

1689
01:14:14,316 --> 01:14:16,232
Рицк Хоулихан: Нећу
се превише у ово.

1690
01:14:16,232 --> 01:14:17,700
Тхис Ис резервисано кључна реч.

1691
01:14:17,700 --> 01:14:20,130
Поглед Фунта је резервисан
кључна реч у Динамо ДБ.

1692
01:14:20,130 --> 01:14:24,500
Свака база има своју задржана
имена за колекција не можете да користите.

1693
01:14:24,500 --> 01:14:27,240
Динамо ДБ ако наведете
фунта испред овога,

1694
01:14:27,240 --> 01:14:29,310
можете дефинисати та имена изнад.

1695
01:14:29,310 --> 01:14:31,840
Ово је референцира вредност.

1696
01:14:31,840 --> 01:14:34,880
То је вероватно није најбоља синтакса у
има тамо за ову расправу,

1697
01:14:34,880 --> 01:14:38,090
јер уђе у неким реал--
Ја бих причао више

1698
01:14:38,090 --> 01:14:41,360
о томе на дубљем нивоу.

1699
01:14:41,360 --> 01:14:46,130
>> Али довољно је рећи, ово би могао
бе упит сцан где су виевс--

1700
01:14:46,130 --> 01:14:50,190
нити прегледа фунта је већи од 10.

1701
01:14:50,190 --> 01:14:54,660
То је нумеричка вредност, да.

1702
01:14:54,660 --> 01:14:57,322
Ако желите, можемо говорити о
да је након разговора.

1703
01:14:57,322 --> 01:15:00,030
У реду, тако да улазимо у
неки сценарији у најбољим праксама

1704
01:15:00,030 --> 01:15:02,000
где идемо да разговарамо
о неким апликацијама овде.

1705
01:15:02,000 --> 01:15:03,810
Који су коришћена случаја за Динамо ДБ.

1706
01:15:03,810 --> 01:15:06,120
Шта су дизајн
обрасци у Динамо ДБ.

1707
01:15:06,120 --> 01:15:09,110
>> И први ћемо
Разговор о је интернет ствари.

1708
01:15:09,110 --> 01:15:15,010
Тако смо добили много од-- претпостављам,
што је То-- више од 50%

1709
01:15:15,010 --> 01:15:19,370
саобраћаја на интернету ових дана
заправо генерише машинама,

1710
01:15:19,370 --> 01:15:21,930
аутоматизовани процеси, а не људи.

1711
01:15:21,930 --> 01:15:25,140
Мислим ово ово ствар која
носите око у џепу,

1712
01:15:25,140 --> 01:15:28,840
колико података да је ствар
Заправо слање око без тебе

1713
01:15:28,840 --> 01:15:30,550
знајући то је апсолутно невероватан.

1714
01:15:30,550 --> 01:15:34,970
Ваша локација, информације
о томе како брзо идете.

1715
01:15:34,970 --> 01:15:38,400
Како мислите Гоогле Мапс радова
кад вам кажу шта је саобраћај.

1716
01:15:38,400 --> 01:15:41,275
То је зато што постоје милиони и
милиони људи возе около

1717
01:15:41,275 --> 01:15:44,667
са телефонима које шаљу
Подаци широм месту све време.

1718
01:15:44,667 --> 01:15:46,500
Дакле, једна од ствари
о овој врсти података

1719
01:15:46,500 --> 01:15:50,980
који долази у, монитор података, лог
података, подаци серија време, је да је

1720
01:15:50,980 --> 01:15:53,540
обично само интересантно
за мало времена.

1721
01:15:53,540 --> 01:15:55,580
Након тог времена, то је
Не тако занимљиво.

1722
01:15:55,580 --> 01:15:58,390
Дакле, разговарали смо о, не дај
те столове расту без граница.

1723
01:15:58,390 --> 01:16:03,410
Идеја је да можда имам 24
сати у вредности од догађаја у мом врелом табели.

1724
01:16:03,410 --> 01:16:06,160
И то топла сто це бити
привилегије на врло високом стопом,

1725
01:16:06,160 --> 01:16:07,950
јер узима доста података.

1726
01:16:07,950 --> 01:16:10,920
То је узимање доста података
а ја читам много.

1727
01:16:10,920 --> 01:16:14,560
Имам пуно рада
упити који раде против тих података.

1728
01:16:14,560 --> 01:16:18,120
>> Након 24 сата, хеј,
Знаш шта, није ме брига.

1729
01:16:18,120 --> 01:16:21,150
Дакле, можда је сваки поноћи лол
мој сто преко новом столу

1730
01:16:21,150 --> 01:16:22,430
и ја депровисион ову табелу.

1731
01:16:22,430 --> 01:16:26,440
А ја ћу узети РЦУ-а и
ВЦУ је доле, јер 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
>> И то скоро никад неће добити читати,
па узмимо ту РЦУ до 10.

1740
01:16:44,200 --> 01:16:49,372
А ја штеди гомилу новца на ово
података, а само плаћање за моје топле података.

1741
01:16:49,372 --> 01:16:52,330
Дакле, то је важно погледати
у када погледате временску серију

1742
01:16:52,330 --> 01:16:54,716
Подаци долази у обиму.

1743
01:16:54,716 --> 01:16:55,590
То су стратегије.

1744
01:16:55,590 --> 01:16:58,010
Сада, само да га пусти
сви на истим столом

1745
01:16:58,010 --> 01:16:59,461
и пусти тај сто расте.

1746
01:16:59,461 --> 01:17:01,460
На крају, ја ћу
види проблеме са перформансама.

1747
01:17:01,460 --> 01:17:04,060
Ја ћу морати да почну да архивира
неки од тих података са стола,

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

1749
01:17:04,720 --> 01:17:07,010
>> Хајде да много боље
дизајнирате пријаву

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

1751
01:17:08,900 --> 01:17:11,460
Дакле, то је само аутоматски
у коду апликације.

1752
01:17:11,460 --> 01:17:13,580
У поноћ сваке ноћи
се котрља табелу.

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

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

1755
01:17:20,277 --> 01:17:22,360
Ја то дотеривање са
Црон посао и ја га ставља

1756
01:17:22,360 --> 01:17:24,160
на овим другим столовима,
све што је потребно.

1757
01:17:24,160 --> 01:17:25,940
Дакле, ако превртања ради, то је сјајно.

1758
01:17:25,940 --> 01:17:27,080
Ако не, трим га.

1759
01:17:27,080 --> 01:17:29,640
Али хајде да задржи тај врући податке
далеко од својих хладних података.

1760
01:17:29,640 --> 01:17:32,535
То ће вам уштедети много новца и
да ваше табеле више вршење.

1761
01:17:32,535 --> 01:17:35,960

1762
01:17:35,960 --> 01:17:38,210
Дакле, следећа ствар причаћемо
о је каталог производа.

1763
01:17:38,210 --> 01:17:42,000
Каталог производа је
Прилично случај коришћења.

1764
01:17:42,000 --> 01:17:46,600
Ово је заправо веома чест образац
да ћемо видети у различитим стварима.

1765
01:17:46,600 --> 01:17:48,870
Знате, Твиттер фор
Пример, вруће твит.

1766
01:17:48,870 --> 01:17:51,280
Сви су долазили и
ухватио ту твит.

1767
01:17:51,280 --> 01:17:52,680
Каталог продуката, имам продају.

1768
01:17:52,680 --> 01:17:54,120
Имам хот продају.

1769
01:17:54,120 --> 01:17:57,277
Добио сам 70.000 захтева по
други долазак за производ

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

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

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

1773
01:18:03,550 --> 01:18:04,924
Нема шансе да се позабави тиме.

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

1775
01:18:07,110 --> 01:18:09,410
Они долазе у, истовремено.

1776
01:18:09,410 --> 01:18:11,920
И сви правите захтеве
за исту податак.

1777
01:18:11,920 --> 01:18:16,240
То ми даје да вруће кључ, да велика црвена
трака на мом графикону који не волимо.

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

1779
01:18:17,720 --> 01:18:22,290
Дакле, преко мог кључног простора Идем
кује у артикала за продају.

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

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

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

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

1784
01:18:33,630 --> 01:18:37,260
Успели смо
[Неразумљиво] кеш, ти како

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

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

1787
01:18:42,220 --> 01:18:47,250
На тај начин можете да чувате те податке
из тих топлих тастера у тој цацхе

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

1789
01:18:49,390 --> 01:18:51,962
>> А онда већина ваших читања
почни овако.

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

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

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

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

1794
01:19:04,360 --> 01:19:07,360
И ја ћу објаснити како се то ради.

1795
01:19:07,360 --> 01:19:09,060
У реду, порука.

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

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

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

1799
01:19:14,950 --> 01:19:17,040
И имамо пријем и слање.

1800
01:19:17,040 --> 01:19:19,760
То је оно што СКЛ би
личи изградимо тај пријем.

1801
01:19:19,760 --> 01:19:23,350
Ми врста користи исту врсту
стратегије за коришћење ГСИ је ГСИ је

1802
01:19:23,350 --> 01:19:25,320
фор ми инбок и моје слање.

1803
01:19:25,320 --> 01:19:27,600
Тако сам добио сирови поруке долазе
у моје поруке сто.

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

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

1806
01:19:31,110 --> 01:19:33,710
Поруке које долазе [неразумљиво],
Мессаге ИД, то је сјајно.

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

1808
01:19:35,070 --> 01:19:38,280
Ја ћу створити два ГСИ, један
фор ми инбок, један за моју слање.

1809
01:19:38,280 --> 01:19:40,530
И прва ствар коју ћу урадити
је Рећи ћу мој тастер тараба је

1810
01:19:40,530 --> 01:19:43,310
ће бити прималац и
Ја ћу договорити о датуму.

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

1812
01:19:44,220 --> 01:19:45,890
Добио сам леп поглед овде.

1813
01:19:45,890 --> 01:19:47,780
Али овде мало питање.

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

1815
01:19:50,891 --> 01:19:52,390
Звали су вертикално раздвајање.

1816
01:19:52,390 --> 01:19:55,840
Ви желите да задржите своју велику податке
далеко од твојих података.

1817
01:19:55,840 --> 01:20:00,470
>> А разлог зашто је зато што морам
да читате ставке да се атрибуте.

1818
01:20:00,470 --> 01:20:05,570
А ако моја тела су сви овде,
онда читање само неколико ставки

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

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

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

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

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

1824
01:20:17,880 --> 01:20:21,730
Ево моје Конверзија
за РЦУ је четири килобајта.

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

1826
01:20:24,450 --> 01:20:28,640
И даље једем 1600 РЦУ је
само да прочитам Давидову инбок.

1827
01:20:28,640 --> 01:20:29,950
Јао.

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

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

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

1831
01:20:39,680 --> 01:20:41,850
Гледам само заглавља.

1832
01:20:41,850 --> 01:20:46,310
Дакле, хајде да изгради структуру табеле
да изгледа више тако.

1833
01:20:46,310 --> 01:20:49,470
>> Дакле, ево информације
да је мој процес рада треба.

1834
01:20:49,470 --> 01:20:50,890
То је у мом инбоку ГСИ.

1835
01:20:50,890 --> 01:20:53,800
То је датум, пошиљалац,
предмет, а затим

1836
01:20:53,800 --> 01:20:56,790
лична порука, што указује
назад на табели мессагес

1837
01:20:56,790 --> 01:20:57,850
где могу добити тело.

1838
01:20:57,850 --> 01:21:01,260

1839
01:21:01,260 --> 01:21:04,420
Па, то би било рецорд личне карте.

1840
01:21:04,420 --> 01:21:09,850
Они би указивало назад у
итем личне карте на столу Динамо ДБ.

1841
01:21:09,850 --> 01:21:12,220
Сваки индекс увек цреатес--
увек има ставку

1842
01:21:12,220 --> 01:21:15,750
ИД као део од-- да
долази са индексом.

1843
01:21:15,750 --> 01:21:17,414
>> U redu.

1844
01:21:17,414 --> 01:21:19,080
ПУБЛИКА: То је место где се то складиште?

1845
01:21:19,080 --> 01:21:21,420
Рицк Хоулихан: Да, то говори
екацтли-- то је управо оно што ради.

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
Baš tako.

1849
01:21:26,460 --> 01:21:29,490
У реду, тако да сада мој пријем је
заправо много мањи.

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

1851
01:21:32,210 --> 01:21:34,230
Дакле мој инбок, кликнем.

1852
01:21:34,230 --> 01:21:38,160
Успут и кликните на поруци,
то је кад морам да одем тело,

1853
01:21:38,160 --> 01:21:40,180
јер ћу
идите у другу поглед.

1854
01:21:40,180 --> 01:21:43,870
Дакле, ако мислите о МВЦ врсти
оквир, Модел Виев Цонтроллер.

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
Povratno putovanje.

1864
01:22:04,330 --> 01:22:05,680
Иди тело.

1865
01:22:05,680 --> 01:22:06,950
>> Прочитао сам много мање података.

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

1867
01:22:09,960 --> 01:22:14,230
И не гори у 1600
РЦУ само да покаже своју инбок.

1868
01:22:14,230 --> 01:22:17,670
Дакле, сада то-- то је начин
да ЛСИ или ГСИ-- Жао ми је,

1869
01:22:17,670 --> 01:22:19,900
ГСИ би успело.

1870
01:22:19,900 --> 01:22:25,450
Имамо нашу хасх на примаоца.

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

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

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

1874
01:22:34,300 --> 01:22:35,770
Хасх на пошиљаоца.

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

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

1877
01:22:41,570 --> 01:22:45,870
сто да се шири, јер лепо
то је само хасх, хеширану Мессаге ИД.

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

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

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

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

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

1883
01:23:03,150 --> 01:23:04,850
У реду, играње.

1884
01:23:04,850 --> 01:23:06,990
Ми сви волимо игре.

1885
01:23:06,990 --> 01:23:10,902
Барем ја волим игрице онда.

1886
01:23:10,902 --> 01:23:12,735
Дакле, неке од ствари
да се бавимо када

1887
01:23:12,735 --> 01:23:14,193
размишљамо о игрању, зар не?

1888
01:23:14,193 --> 01:23:16,999
Гаминг ових дана, нарочито мобилни
играње, то је све о размишљању.

1889
01:23:16,999 --> 01:23:19,540
И ја ћу ротирати овде
мало даље од ДинамоДБ.

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

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

1892
01:23:24,240 --> 01:23:28,930
>> Али идеја о игрању је мислити
о у смислу АПИс Апис који су,

1893
01:23:28,930 --> 01:23:31,730
Уопштено говорећи, ХТТП и ЈСОН.

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

1895
01:23:34,550 --> 01:23:35,850
Они ЈСОН постављање.

1896
01:23:35,850 --> 01:23:40,660
Они се подаци, и то је све,
генерално гледано, у лепим ЈСОН АПИ.

1897
01:23:40,660 --> 01:23:44,950
>> Ствари као да пријатеље, да
подаци о Лидери, размена,

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

1899
01:23:47,699 --> 01:23:49,740
ово су типови ствари
да ћемо да урадимо.

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

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

1902
01:23:54,250 --> 01:23:56,541
Али база ће
завршити говори систем,

1903
01:23:56,541 --> 01:23:59,140
говори пријаву
где да одем да.

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

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

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

1907
01:24:09,400 --> 01:24:12,160
>> Дакле, хајде да погледамо
како то изгледа.

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

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

1910
01:24:19,880 --> 01:24:23,780
Разговарали смо о АЗС као беинг-- мисле
од њих као засебне дата центара.

1911
01:24:23,780 --> 01:24:26,040
Више од једног дата центар
по АЗ, али то је у реду,

1912
01:24:26,040 --> 01:24:28,831
Само мислим о њима као засебну података
центри који су географски

1913
01:24:28,831 --> 01:24:30,090
и кривица изолован.

1914
01:24:30,090 --> 01:24:32,172
>> Ми ћемо имати
Пар ЕЦ2 инстанце.

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
користећи оно што зовемо РДС,
релационалних услуге бази података.

1918
01:24:38,920 --> 01:24:42,040
Могао би бити МССКЛ, МиСКЛ,
ili nešto slično.

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
Идемо напред и стави
С3 кашика горе.

1922
01:24:51,510 --> 01:24:54,200
И то С3 кашика, уместо да служи
до тих објеката из наше серверс--

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
>> Боље начин да то урадите је ићи напријед и
стави те објекте у С3 кофу.

1928
01:25:05,107 --> 01:25:06,315
С3 је објекат складишта.

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
Ја сам створио С3 канту
као мој изворно спремиште.

1937
01:25:26,200 --> 01:25:29,370
И предњи ћу да са
ЦлоудФронт дистрибуција.

1938
01:25:29,370 --> 01:25:31,720
>> ЦлоудФронт је ЦД и
Садржај испоруке мрежу.

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
Ти си некако усклађивање свих
аспекти АВС овде да се то уради.

1944
01:25:48,230 --> 01:25:50,790
И на крају, бацамо
у саобраћајној скалирања групе.

1945
01:25:50,790 --> 01:25:52,737
Дакле, наше АЦ2 случајевима
наши сервери игре,

1946
01:25:52,737 --> 01:25:54,820
јер ће почети да се заузетија
и заузетија и заузетија,

1947
01:25:54,820 --> 01:25:57,236
они ће само да окрећу други
инстанца, спин другом случају,

1948
01:25:57,236 --> 01:25:58,210
спин другом случају.

1949
01:25:58,210 --> 01:26:02,090
Тако технологије: АВС има, то
омогућава да одредите параметре

1950
01:26:02,090 --> 01:26:04,650
око којих ће ваши сервери расти.

1951
01:26:04,650 --> 01:26:08,110
Дакле, можете имати н број сервера
тамо у било ком тренутку.

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
Имамо доста ЕЦ2 инстанцама.

1956
01:26:19,800 --> 01:26:21,671
Можемо ставити кеша у
предњи део базе података,

1957
01:26:21,671 --> 01:26:23,045
покушати да убрза базе података.

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

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

1960
01:26:28,850 --> 01:26:30,790
Исусе, база података
Представа је страшно.

1961
01:26:30,790 --> 01:26:31,932
Како да побољшамо ово?

1962
01:26:31,932 --> 01:26:33,640
Хајде да покушамо стављање
кеш испред тога.

1963
01:26:33,640 --> 01:26:36,780
>> Па, кеш не ради
тако сјајно у играма, зар не?

1964
01:26:36,780 --> 01:26:39,330
За игре, писање је болно.

1965
01:26:39,330 --> 01:26:40,930
Игре су веома тешки пишу.

1966
01:26:40,930 --> 01:26:43,610
Кеш не ради када си
напиши тешка јер сте одувек

1967
01:26:43,610 --> 01:26:44,610
Морам да ажурира кеш.

1968
01:26:44,610 --> 01:26:47,780
Ви ажурира кеш, то је
небитно да кеширање.

1969
01:26:47,780 --> 01:26:49,780
То је заправо само додатни посао.

1970
01:26:49,780 --> 01:26:51,970
>> Па где идемо одавде?

1971
01:26:51,970 --> 01:26:54,400
Имате велику уско грло
доле у ​​бази података.

1972
01:26:54,400 --> 01:26:57,661
И где да одем
Очигледно је подели.

1973
01:26:57,661 --> 01:26:59,410
Подела није
лако урадити када сте

1974
01:26:59,410 --> 01:27:01,900
које се баве релационим базама података.

1975
01:27:01,900 --> 01:27:05,080
Са релационим базама података, ти си
одговорна за управљање, ефикасно,

1976
01:27:05,080 --> 01:27:06,210
кључ простор.

1977
01:27:06,210 --> 01:27:10,527
Кажеш корисницима између А и М
идите овде, између Н и З идем тамо.

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
proces?

1987
01:27:31,430 --> 01:27:32,513
Рицк Хоулихан: Повећање?

1988
01:27:32,513 --> 01:27:33,520
ПУБЛИКА: Соурце поена.

1989
01:27:33,520 --> 01:27:34,410
Рицк Хоулихан: Соурце бодова?

1990
01:27:34,410 --> 01:27:37,500
ПУБЛИКА: Из информација,
где се информације које долазе из?

1991
01:27:37,500 --> 01:27:38,250
Рицк Хоулихан: Не

1992
01:27:38,250 --> 01:27:41,820
Оно што хоћу да кажем је повећању
број преграда у складишту података

1993
01:27:41,820 --> 01:27:44,060
побољшава проток.

1994
01:27:44,060 --> 01:27:48,300
Дакле, шта се овде дешава је корисницима
Ступањем на ЕЦ2 пример овде,

1995
01:27:48,300 --> 01:27:50,780
Па, ако је потребно корисника
То је на М, идем овде.

1996
01:27:50,780 --> 01:27:53,560
Од Н се п, идем овде.

1997
01:27:53,560 --> 01:27:55,060
Од П до З, идем овде.

1998
01:27:55,060 --> 01:27:57,120
>> ПУБЛИКА: Добро, они тако то су
све сачуване у различитим чворовима?

1999
01:27:57,120 --> 01:27:57,911
>> Рицк Хоулихан: Да.

2000
01:27:57,911 --> 01:28:00,210
Мисли од њих као
различити силоси података.

2001
01:28:00,210 --> 01:28:01,660
Дакле, имате за то.

2002
01:28:01,660 --> 01:28:02,910
Ако покушавате да урадите
ово, ако покушаваш

2003
01:28:02,910 --> 01:28:05,730
у размери на релациону платформи,
то је оно што радите.

2004
01:28:05,730 --> 01:28:08,100
Идеш податке и
ви га сјече.

2005
01:28:08,100 --> 01:28:10,975
И ти га поделе преко
више инстанци базе података.

2006
01:28:10,975 --> 01:28:13,580
А ти све то управљања
на апликације слоју.

2007
01:28:13,580 --> 01:28:14,729
Није забавно.

2008
01:28:14,729 --> 01:28:15,770
Дакле, шта желимо да идемо?

2009
01:28:15,770 --> 01:28:20,240
Желимо да идемо ДинамоДБ, у потпуности успјела,
НоСКЛ подаци продавница, одредба проток.

2010
01:28:20,240 --> 01:28:22,680
Ми користимо секундарне индексе.

2011
01:28:22,680 --> 01:28:26,154
То је у основи ХТТП АПИ и
укључује подршку документ.

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
Дакле, имаш корисници долазе,
су БоардНамес да су они

2020
01:28:49,980 --> 01:28:52,930
на, резултати за овај корисника.

2021
01:28:52,930 --> 01:28:57,700
Могли бисмо да се хасхинг на усерид,
а онда имамо низ на игру.

2022
01:28:57,700 --> 01:28:59,960
Дакле, сваки корисник жели да види
све је игра он играо

2023
01:28:59,960 --> 01:29:01,770
и сва његова Топ резултат
кроз све игре.

2024
01:29:01,770 --> 01:29:04,000
Дакле, то је његов лични Лидери.

2025
01:29:04,000 --> 01:29:10,010
>> Сада желим да идем у и желим да добијам--
тако да се ове личне леадербоардс.

2026
01:29:10,010 --> 01:29:12,827
Оно што желим да урадим је да узмем
топ скор у свим корисницима.

2027
01:29:12,827 --> 01:29:13,660
Па како то да урадим?

2028
01:29:13,660 --> 01:29:18,070
Када је мој рекорд је хеширану на
усерид, кретао се у игру,

2029
01:29:18,070 --> 01:29:20,740
и ја ћу ићи напред
и реструктурирање, направите ГСИ,

2030
01:29:20,740 --> 01:29:22,370
и ја ћу за реструктурирање тих података.

2031
01:29:22,370 --> 01:29:27,310
>> Сада ћу хасх на
БоардНаме, која је игра.

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
Сада они могу бити сортирани по БоардНаме
сортиране по ТопСцоре, у зависности од.

2039
01:29:54,556 --> 01:29:57,180
Тако можете видети, ово су типови
од користи предмете које срећете у играма.

2040
01:29:57,180 --> 01:30:02,190
Још један добар случај коришћења смо добили у играма
је награде и ко су добитници награда.

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

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

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

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

2045
01:30:11,470 --> 01:30:14,540
Зато што је атрибут који је био
индексирани не постоји на свакој тачки.

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

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

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

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

2050
01:30:25,950 --> 01:30:27,800
Дакле, када сам створити
индекса, једини корисници

2051
01:30:27,800 --> 01:30:28,960
који ће показати
у индексу су

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

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

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

2055
01:30:40,580 --> 01:30:43,050
>> Тако смо слаби на време овде.

2056
01:30:43,050 --> 01:30:49,190
Ја идем напред и прескочите
напоље и прескочите овај сценарио.

2057
01:30:49,190 --> 01:30:52,625
Разговарајте мало о--

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

2059
01:30:54,460 --> 01:30:56,722
Један је писати тешка?

2060
01:30:56,722 --> 01:30:57,680
Рицк Хоулихан: Шта је?

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

2062
01:30:58,596 --> 01:31:01,270
Рицк Хоулихан: Напишите тешка.

2063
01:31:01,270 --> 01:31:03,460
Daj da vidim.

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

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

2066
01:31:08,809 --> 01:31:10,850
Рицк Хоулихан: Идемо
кроз гласање сценарио.

2067
01:31:10,850 --> 01:31:11,670
То није тако лоше.

2068
01:31:11,670 --> 01:31:14,580
Да ли ви имате пар минута?

2069
01:31:14,580 --> 01:31:15,860
OK.

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
Život je dobar.

2094
01:32:12,332 --> 01:32:15,040
Живот је добро док не откријемо да
Увек постоји само један или два

2095
01:32:15,040 --> 01:32:16,879
људи који су популарни у изборима.

2096
01:32:16,879 --> 01:32:19,420
Постоји само једна или две ствари
да људи заиста стало.

2097
01:32:19,420 --> 01:32:22,340
А ако гласање на
скала, одједном сам

2098
01:32:22,340 --> 01:32:26,360
ће бити чекића напоље из
два кандидата, један или два кандидата.

2099
01:32:26,360 --> 01:32:29,390
Веома мали број ставки
људи сматрају да буде популаран.

2100
01:32:29,390 --> 01:32:31,710
>> Ово није добар дизајн образац.

2101
01:32:31,710 --> 01:32:33,549
Ово је заправо
Веома лош дизајн образац

2102
01:32:33,549 --> 01:32:36,340
јер то ствара оно што смо
говорио о којој је хот кеис.

2103
01:32:36,340 --> 01:32:38,960
Хот тастери су нешто што се не допада.

2104
01:32:38,960 --> 01:32:40,470
>> Како да поправити?

2105
01:32:40,470 --> 01:32:47,640
И заиста, начин да се поправи ово је
узимајући оне канте кандидата

2106
01:32:47,640 --> 01:32:51,490
и за сваког кандидата имамо,
ћемо додати случајан вредност,

2107
01:32:51,490 --> 01:32:54,192
нешто што знамо, случајно
вредност између једног и 100,

2108
01:32:54,192 --> 01:32:56,620
између 100 и 1.000,
или између једне и 1.000,

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

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

2111
01:33:01,330 --> 01:33:05,830
Ако сам користећи кандидата ИД као
кофа да агрегата гласова,

2112
01:33:05,830 --> 01:33:08,780
ако сам додао случајни
број на крај тога,

2113
01:33:08,780 --> 01:33:12,000
Направио сам сада 10 кашике, А
сто кашике, а хиљаду кашике

2114
01:33:12,000 --> 01:33:14,160
да сам сабирањем гласова преко.

2115
01:33:14,160 --> 01:33:18,030
>> Дакле, имам милионе и милионе,
и милиони евиденција долази

2116
01:33:18,030 --> 01:33:22,050
за ове кандидате, ја сам сада шири
ти гласови широм Кандидат А_1

2117
01:33:22,050 --> 01:33:24,630
кроз кандидат А_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
обрасце за скали у носкл.

2137
01:34:10,420 --> 01:34:14,470
Видећете ову врсту
дизајн образац у сваком укусу.

2138
01:34:14,470 --> 01:34:19,100
МонгоДБ, ДинамоДБ, није тако
ма, сви ми треба да урадимо ово.

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
Дакле, то је обично вредан
техника за скалирање ДинамоДБ,

2149
01:34:49,450 --> 01:34:51,350
или било НоСКЛ база података по том питању.

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
То је уграђен у ДинамоДБ.

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

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

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

2160
01:35:11,220 --> 01:35:13,320
Ја условну писати.

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

2162
01:35:16,960 --> 01:35:19,270
Дакле, чим видим да
да глас је ударио о сто,

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

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

2165
01:35:21,634 --> 01:35:23,550
А ми инцрементинг
Наш кандидат шалтера.

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

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

2168
01:35:29,110 --> 01:35:31,350
Сада одједном гласова
долазе у, и

2169
01:35:31,350 --> 01:35:34,840
не знам да ли они узимајући обрађују
у моје аналитике и демографију

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

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

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

2173
01:35:41,420 --> 01:35:44,530
>> Дакле, ово је прави проблем када вас
почнете да погледате ову врсту сценарија.

2174
01:35:44,530 --> 01:35:45,571
А како ћемо решити то?

2175
01:35:45,571 --> 01:35:48,070
Ми га решити са оним што
позовите ДинамоДБ потока.

2176
01:35:48,070 --> 01:35:53,470
Преноси се време наредили и
подељена цханге лог сваког приступа

2177
01:35:53,470 --> 01:35:55,700
за сто, сваки писати
приступ табели.

2178
01:35:55,700 --> 01:35:58,810
Сви подаци који се уписују у
сто се појављује на потока.

2179
01:35:58,810 --> 01:36:01,815
>> То је у основи ред 24 часа.

2180
01:36:01,815 --> 01:36:03,690
Предмети хит поток,
они живе за 24 сата.

2181
01:36:03,690 --> 01:36:05,990
Они се могу прочитати више пута.

2182
01:36:05,990 --> 01:36:09,400
Гарантовано да буде испоручена
само једном потоку,

2183
01:36:09,400 --> 01:36:11,180
може прочитати н број пута.

2184
01:36:11,180 --> 01:36:14,910
Дакле, међутим, многи процеси желите да
троше те податке, можете га конзумирати.

2185
01:36:14,910 --> 01:36:16,350
Она ће се појавити сваки упдате.

2186
01:36:16,350 --> 01:36:18,455
Сваки писати ће само
појављују једном на потока.

2187
01:36:18,455 --> 01:36:20,621
Дакле, не морате да бринете
о обради два пута

2188
01:36:20,621 --> 01:36:22,500
из истог процеса.

2189
01:36:22,500 --> 01:36:25,350
>> То је строго наредио по комаду.

2190
01:36:25,350 --> 01:36:28,180
Када кажемо времена
наредио и подељена,

2191
01:36:28,180 --> 01:36:30,680
видећете по поделе на потока.

2192
01:36:30,680 --> 01:36:33,169
Видећете ставке, исправке како.

2193
01:36:33,169 --> 01:36:35,210
Ми не гарантује
на потоку да сте ви

2194
01:36:35,210 --> 01:36:40,240
ћете добити сваку трансакцију
у циљу преко ставки.

2195
01:36:40,240 --> 01:36:42,440
>> Дакле, потоци су идемпотент.

2196
01:36:42,440 --> 01:36:44,037
Да ли сви знамо шта идемпотент значи?

2197
01:36:44,037 --> 01:36:46,620
Идемпотент значи да можете то урадити
над, и изнова, и изнова.

2198
01:36:46,620 --> 01:36:48,200
Резултат ће бити исти.

2199
01:36:48,200 --> 01:36:49,991
>> Преноси су идемпотент,
али морају да буду

2200
01:36:49,991 --> 01:36:54,860
играо од полазне тачке,
где год да изаберете, до краја,

2201
01:36:54,860 --> 01:36:57,950
или они неће резултирати
у истим вредностима.

2202
01:36:57,950 --> 01:36:59,727
>> Иста ствар и са МонгоДБ.

2203
01:36:59,727 --> 01:37:01,560
МонгоДБ има конструкт
зову оплог.

2204
01:37:01,560 --> 01:37:04,140
То је потпуно исти конструкт.

2205
01:37:04,140 --> 01:37:06,500
Многи НоСКЛ базе података
имају ову конструкт.

2206
01:37:06,500 --> 01:37:08,790
Они га користе да радим ствари
попут репликације, који

2207
01:37:08,790 --> 01:37:10,475
је управо оно што радимо са потоцима.

2208
01:37:10,475 --> 01:37:12,350
ПУБЛИКА: Можда
јеретичке питање, али ти

2209
01:37:12,350 --> 01:37:13,975
говоре о апликације раде доле тако даље.

2210
01:37:13,975 --> 01:37:16,089
Да ли потоци гарантовано
Никада вероватно пасти?

2211
01:37:16,089 --> 01:37:18,630
Рицк Хоулихан: Да, потоци
гарантовано не иду доле.

2212
01:37:18,630 --> 01:37:21,040
Ми управљање инфраструктуром
иза. аутоматски потока

2213
01:37:21,040 --> 01:37:22,498
распоредити у свом аутоматско скалирања групе.

2214
01:37:22,498 --> 01:37:25,910
Ми ћемо проћи кроз мало
мало о томе шта се дешава.

2215
01:37:25,910 --> 01:37:30,060
>> Не би требало да кажу да нису
гарантовано да никада не иду доле.

2216
01:37:30,060 --> 01:37:33,110
Елементи су загарантована
да се појави у потоку.

2217
01:37:33,110 --> 01:37:36,740
А струја ће бити доступна.

2218
01:37:36,740 --> 01:37:40,580
Дакле, оно што иде доле или врати
горе, што се дешава испод.

2219
01:37:40,580 --> 01:37:43,844
То цоверс-- да је у реду.

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
možete dobiti.

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

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

2252
01:39:03,090 --> 01:39:05,820
Нема реадс-- али како
многи пише долазе у.

2253
01:39:05,820 --> 01:39:08,200
>> А онда на полеђини
крај, имамо оно што смо

2254
01:39:08,200 --> 01:39:11,390
позовите КЦл, или кинези цлиент либрари.

2255
01:39:11,390 --> 01:39:19,190
Кинези је низ података
обрада технологија из Амазона.

2256
01:39:19,190 --> 01:39:22,040
И потоци се гради на томе.

2257
01:39:22,040 --> 01:39:25,670
>> Тако да користи КЦЛ омогућен
Апликација за читање ток.

2258
01:39:25,670 --> 01:39:28,752
Кинесис клијент библиотека ствари
управља раднике за вас.

2259
01:39:28,752 --> 01:39:30,460
И такође ради неке
интересантне ствари.

2260
01:39:30,460 --> 01:39:35,630
То ће створити неке столове
у вашем ДинамоДБ таблеспаце

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
Дакле, КЦЛ библиотека за преноси ће
да ти дам доста тога функционалности.

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
Постоји девет региони
svud oko sveta.

2279
01:40:29,230 --> 01:40:32,100
Дакле, можда постоји морају-- сам
можда има кориснике у Азији, корисници

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
Један је конзола апликација можете
станд уп на свом ЕЦ2 инстанце.

2288
01:40:59,400 --> 01:41:01,240
Ради чист репликација.

2289
01:41:01,240 --> 01:41:02,720
И онда ти је дао библиотеку.

2290
01:41:02,720 --> 01:41:06,070
Библиотека можете користити за изградњу
свој апликацију ако

2291
01:41:06,070 --> 01:41:10,740
Желим да раде луде ствари са тим дата--
Филтер, копирају само део њега,

2292
01:41:10,740 --> 01:41:14,120
ротирати податке, преместите их у
посебна табела, и тако даље и тако даље.

2293
01:41:14,120 --> 01:41:18,700

2294
01:41:18,700 --> 01:41:20,520
Дакле, то је некако како то изгледа.

2295
01:41:20,520 --> 01:41:23,690
>> ДинамоДБ потоци могу бити
обрађује оно што ми зовемо Ламбда.

2296
01:41:23,690 --> 01:41:27,394
Поменули смо мало о догађају
дривен апликација архитектуре.

2297
01:41:27,394 --> 01:41:28,810
Ламбда је кључна компонента за то.

2298
01:41:28,810 --> 01:41:32,840
Ламбда је код који испаљује на захтев
у одговору на одређени догађај.

2299
01:41:32,840 --> 01:41:36,020
Један од тих догађаја може да буде
запис појављује на потока.

2300
01:41:36,020 --> 01:41:39,100
Ако рекорд појави на потоку,
ћемо назвати ову функцију Јава.

2301
01:41:39,100 --> 01:41:44,980
Па, ово је Јава-скрипта и ламбда
подржава Ноде.јс, Јава, Питхон

2302
01:41:44,980 --> 01:41:47,820
а ускоро ће подржавати
други језици као добро.

2303
01:41:47,820 --> 01:41:50,940
И довољно је рећи, то је чиста кода.

2304
01:41:50,940 --> 01:41:53,610
напиши У Јави, дефинишете класу.

2305
01:41:53,610 --> 01:41:55,690
Ви притиснете ЈАР горе у Ламбда.

2306
01:41:55,690 --> 01:42:00,200
И онда одредите које класа
да позове у одговору на којима догађај.

2307
01:42:00,200 --> 01:42:04,770
А онда Ламбда инфраструктура
иза које ће покренути ту код.

2308
01:42:04,770 --> 01:42:06,730
>> То може да обради код
евиденција офф потока.

2309
01:42:06,730 --> 01:42:08,230
То може ништа да жели са њим.

2310
01:42:08,230 --> 01:42:11,650
У овом конкретном примеру, сви смо
стварно ради се улогујете атрибуте.

2311
01:42:11,650 --> 01:42:13,480
Али ово је само код.

2312
01:42:13,480 --> 01:42:15,260
Код могу ништа да урадим, зар не?

2313
01:42:15,260 --> 01:42:16,600
>> Дакле, можете ротирати те податке.

2314
01:42:16,600 --> 01:42:18,160
Можете да креирате дериват поглед.

2315
01:42:18,160 --> 01:42:21,160
Ако је структура документ,
можете поравнајте структуру.

2316
01:42:21,160 --> 01:42:24,300
Можете направити алтернативне индексе.

2317
01:42:24,300 --> 01:42:27,100
Све врсте ствари које можете да
везе са ДинамоДБ Стреамс.

2318
01:42:27,100 --> 01:42:28,780
>> И заиста, то је оно што изгледа.

2319
01:42:28,780 --> 01:42:29,940
Тако ти та исправке долази у.

2320
01:42:29,940 --> 01:42:31,190
Они долазе са стринг.

2321
01:42:31,190 --> 01:42:32,720
Они прочитао функцији Ламбда.

2322
01:42:32,720 --> 01:42:37,480
Они окретањем податке и
гура га у изведеним табелама,

2323
01:42:37,480 --> 01:42:42,200
обавести спољне системе промена,
и гура података у ЕластиЦацхе.

2324
01:42:42,200 --> 01:42:45,900
>> Разговарали смо о томе како да стави кеш
испред базе података за ту продају

2325
01:42:45,900 --> 01:42:46,450
Сценарио.

2326
01:42:46,450 --> 01:42:50,049
Па шта се дешава ако
упдате опис предмета?

2327
01:42:50,049 --> 01:42:52,340
Па, ако сам имао Ламбда
Функција ради на том столу,

2328
01:42:52,340 --> 01:42:55,490
ако сам упдате опис артикла, то ће
покупи рекорд са потока,

2329
01:42:55,490 --> 01:42:58,711
и то ће ажурирати ЕластиЦацхе
инстанца са новим подацима.

2330
01:42:58,711 --> 01:43:00,460
Дакле, то је доста
шта радимо са Ламбда.

2331
01:43:00,460 --> 01:43:02,619
То је лепак број, конектори.

2332
01:43:02,619 --> 01:43:04,410
И то је заправо даје
способност да покрене

2333
01:43:04,410 --> 01:43:07,930
и за покретање веома сложене апликације
без дедицатед сервер

2334
01:43:07,930 --> 01:43:10,371
инфраструктура, што је стварно кул.

2335
01:43:10,371 --> 01:43:13,100
>> Дакле, хајде да се вратимо на нашу
у реалном времену гласање архитектура.

2336
01:43:13,100 --> 01:43:17,984
Ово је нова и побољшана са нашим
потоци и КЦЛ омогућити апликацију.

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
када је у питању назад, јер
да користимо КЦЛ апликацију.

2347
01:43:41,300 --> 01:43:45,700
И онда можемо да користимо да
КЦЛ апликација да гура податке од

2348
01:43:45,700 --> 01:43:48,820
да црвени помак за друге
апп аналитицс, или употреба

2349
01:43:48,820 --> 01:43:51,990
еластични МапРедуце за покретање
реал-тиме стреаминг агрегације офф

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
>> У реду, тако да се о
аналитика са ДинамоДБ потока.

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
су укључени у, узимајући Нестед
својства тих докумената ЈСОН

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
ДинамоДБ седи у средини тако
много од АВС инфраструктуре.

2365
01:44:33,440 --> 01:44:37,090
У суштини можете га повезати
до свега што желите.

2366
01:44:37,090 --> 01:44:45,600
Апликације изграђена коришћењем Динамо укључују
Ламбда, ЕластиЦацхе, ЦлоудСеарцх,

2367
01:44:45,600 --> 01:44:49,890
пусх податке напоље у Еластична
МапРедуце, ​​увоз извоз из ДинамоДБ

2368
01:44:49,890 --> 01:44:52,370
у С3, све врсте радних токова.

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
је они срушити сигурна
ХТМЛ форма истраживање из С3.

2378
01:45:18,020 --> 01:45:18,980
Нема сервера.

2379
01:45:18,980 --> 01:45:20,600
Ово је само С3 објекат.

2380
01:45:20,600 --> 01:45:22,770
>> То облик појави,
учитава у претраживачу.

2381
01:45:22,770 --> 01:45:24,240
Има кичму.

2382
01:45:24,240 --> 01:45:30,160
Има комплекс ЈаваСкрипт
да се води.

2383
01:45:30,160 --> 01:45:33,557
Зато је веома богата апликација
трчање у бровсеру клијента.

2384
01:45:33,557 --> 01:45:36,390
Они не знају да нису
интеракције са леђа енд серверу.

2385
01:45:36,390 --> 01:45:38,220
У овом тренутку, све је браузер.

2386
01:45:38,220 --> 01:45:41,780
>> Они објавити резултате на шта
зовемо Амазон АПИ Гатеваи.

2387
01:45:41,780 --> 01:45:46,270
АПИ Гатеваи је једноставно Веб АПИ
да можете дефинисати и спојити

2388
01:45:46,270 --> 01:45:47,760
да шта год хоћеш.

2389
01:45:47,760 --> 01:45:50,990
У овом конкретном случају, ми смо
закачен на функцију Ламбда.

2390
01:45:50,990 --> 01:45:54,797
>> Дакле, мој пост операција
догађа без сервером.

2391
01:45:54,797 --> 01:45:56,380
У основи је АПИ за Гатеваи седи тамо.

2392
01:45:56,380 --> 01:45:58,770
То ми ништа не кошта док људи
почети постављање на њега, зар не?

2393
01:45:58,770 --> 01:46:00,269
Функција Ламбда само сједи тамо.

2394
01:46:00,269 --> 01:46:03,760
И то ми ништа не кошта до
људи почну да је забио.

2395
01:46:03,760 --> 01:46:07,270
Тако можете видети, као запремине
повећава, то је када дођу оптужбе.

2396
01:46:07,270 --> 01:46:09,390
Ја не водим сервер 7/24.

2397
01:46:09,390 --> 01:46:12,310
>> Тако сам повући форму
доле из канте,

2398
01:46:12,310 --> 01:46:15,719
и ја пост кроз АПИ
Капија за улазак функцију Ламбда.

2399
01:46:15,719 --> 01:46:17,510
А онда Ламбда
Функција каже, знате

2400
01:46:17,510 --> 01:46:20,600
шта, имам неке ПИИс, неки
лични подаци

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
И ја ћу гурнути
метаподатака у ДинамоДБ.

2408
01:46:32,850 --> 01:46:36,059
И могао шифровање све податке
и гурните га у ДинамоДБ ако хоћу.

2409
01:46:36,059 --> 01:46:38,600
Али то је лакше за мене, у овом
користити случај, да настави се пита,

2410
01:46:38,600 --> 01:46:42,800
Идем да гура сирове податке
у шифрованом С3 кофу.

2411
01:46:42,800 --> 01:46:47,240
Тако да користим изграђен у С3 страни сервера
енкрипција и управљање кључевима Амазон

2412
01:46:47,240 --> 01:46:51,600
Сервис тако да имам кључ који
може ротирати на редовним интервалима,

2413
01:46:51,600 --> 01:46:55,010
и ја могу заштитити ту ПИИ податке
као део целог овог процеса рада.

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

2418
01:47:05,730 --> 01:47:08,730
имамо друге кориснике говорим
да о овом тачним архитектуре који

2419
01:47:08,730 --> 01:47:14,560
рун феноменално велике кампање, који
гледамо ово и дешава, ох.

2420
01:47:14,560 --> 01:47:17,840
Јер сада, могу
у основи то пусх тамо,

2421
01:47:17,840 --> 01:47:21,900
нека ту кампању само седети
тамо док га лансира, а не

2422
01:47:21,900 --> 01:47:24,400
морате да бринете о сл о
каква инфраструктуре

2423
01:47:24,400 --> 01:47:26,120
ће бити ту да га подржи.

2424
01:47:26,120 --> 01:47:28,600
А онда, чим
Та кампања је урађено,

2425
01:47:28,600 --> 01:47:31,520
то је као инфраструктуре
само одмах оде

2426
01:47:31,520 --> 01:47:33,680
јер стварно
постоји инфраструктура.

2427
01:47:33,680 --> 01:47:35,660
То је само код који стоји на Ламбда.

2428
01:47:35,660 --> 01:47:38,560
То је само податак да седи у ДинамоДБ.

2429
01:47:38,560 --> 01:47:41,340
То је невероватан начин
да изграде апликације.

2430
01:47:41,340 --> 01:47:43,970
>> ПУБЛИКА: Тако је то више
ефемерне него што би то био

2431
01:47:43,970 --> 01:47:45,740
ако је сачувана на стварној серверу?

2432
01:47:45,740 --> 01:47:46,823
>> Рицк Хоулихан: Апсолутно.

2433
01:47:46,823 --> 01:47:49,190
Због тог сервера пример
би морао да буде 7/24.

2434
01:47:49,190 --> 01:47:51,954
То мора да буде на располагању за
неко одговорити.

2435
01:47:51,954 --> 01:47:52,620
Па знате шта?

2436
01:47:52,620 --> 01:47:55,410
С3 је доступан 7/24.

2437
01:47:55,410 --> 01:47:57,100
С3 увек одговара.

2438
01:47:57,100 --> 01:47:59,320
И С3 је врло, врло добар
да служи објекте.

2439
01:47:59,320 --> 01:48:02,590
Ти објекти могу бити ХТМЛ фајл или
ЈаваСцрипт датотеке, или шта год желите.

2440
01:48:02,590 --> 01:48:07,430
Можете да покренете веома богате веб апликација
из С3 кашике, и људи.

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
И то је оно: АВС покушава да уради.

2448
01:48:24,980 --> 01:48:29,690
>> ПУБЛИКА: Дакле, твоје злато кутије у средини
АПИ-ја Гатеваи нису сервер-као,

2449
01:48:29,690 --> 01:48:30,576
већ је само--

2450
01:48:30,576 --> 01:48:32,850
>> Рицк Хоулихан: Можете мислити
о томе као сервера фасаде.

2451
01:48:32,850 --> 01:48:38,040
Све што је је да ће то трајати ХТТП
затражити и карту да другом процесу.

2452
01:48:38,040 --> 01:48:39,192
То је све што ради.

2453
01:48:39,192 --> 01:48:41,525
И у овом случају, ми мапирања
она на функцију Ламбда.

2454
01:48:41,525 --> 01:48:44,119

2455
01:48:44,119 --> 01:48:45,410
У реду, тако да је све што имам.

2456
01:48:45,410 --> 01:48:46,190
Mnogo vam hvala.

2457
01:48:46,190 --> 01:48:46,800
Cenim to.

2458
01:48:46,800 --> 01:48:48,100
Знам да желимо мало током времена.

2459
01:48:48,100 --> 01:48:49,980
И надам се да ви момци имате
мало информација

2460
01:48:49,980 --> 01:48:51,410
да можете узети данас.

2461
01:48:51,410 --> 01:48:53,520
И извињавам се ако сам отишао
неке од ваших глава,

2462
01:48:53,520 --> 01:48:56,697
али постоји много добра
основни темељ знања

2463
01:48:56,697 --> 01:48:58,280
мислим да је веома драгоцено за вас.

2464
01:48:58,280 --> 01:48:59,825
Хвала вам што сте ме позвали.

2465
01:48:59,825 --> 01:49:00,325
[АППЛАУСЕ]

2466
01:49:00,325 --> 01:49:02,619
ПУБЛИКА: [неразумљиво]
када сте говорили

2467
01:49:02,619 --> 01:49:05,160
сте морали да прођете кроз ствари
од почетка до краја

2468
01:49:05,160 --> 01:49:07,619
да се праве вредности
или исте вредности,

2469
01:49:07,619 --> 01:49:09,410
Како би вредности
промијенити ако [неразумљиво].

2470
01:49:09,410 --> 01:49:10,480
>> Рицк Хоулихан: О, идемпотент?

2471
01:49:10,480 --> 01:49:11,800
Како би се вредности промене?

2472
01:49:11,800 --> 01:49:15,180
Па, јер ако нисам покренути
то све до краја,

2473
01:49:15,180 --> 01:49:19,770
онда ја не знам шта мења
су направљене у последњем километар.

2474
01:49:19,770 --> 01:49:22,144
Неће бити
Исти подаци, као што сам видела.

2475
01:49:22,144 --> 01:49:24,560
ПУБЛИКА: Ох, па само
нисам добила цео улаз.

2476
01:49:24,560 --> 01:49:24,770
Рицк Хоулихан: Тако је.

2477
01:49:24,770 --> 01:49:26,895
Мораш да идеш из почетка
до краја, а онда је

2478
01:49:26,895 --> 01:49:29,280
ће бити доследан држава.

2479
01:49:29,280 --> 01:49:31,520
Кул.

2480
01:49:31,520 --> 01:49:35,907
>> ПУБЛИКА: Тако сте нам показали ДинамоДБ
може да уради документ или кључну вредност.

2481
01:49:35,907 --> 01:49:38,740
И ми смо доста времена провели на
Кључна вредност са хасх и начинима

2482
01:49:38,740 --> 01:49:40,005
то флип около.

2483
01:49:40,005 --> 01:49:43,255
Када сте погледали тим столовима, да
остављајући иза приступа документа?

2484
01:49:43,255 --> 01:49:44,600
>> Рицк Хоулихан: Ја не бих
кажу остављајући га иза.

2485
01:49:44,600 --> 01:49:45,855
>> ПУБЛИКА: Они су били одвојени од до--

2486
01:49:45,855 --> 01:49:49,140
>> Рицк Хоулихан: Са документом
приступ, тип документа у ДинамоДБ

2487
01:49:49,140 --> 01:49:50,880
је само мислимо као још један атрибут.

2488
01:49:50,880 --> 01:49:53,560
То је атрибут који садржи
хијерархијска структура података.

2489
01:49:53,560 --> 01:49:56,980
А онда на упите,
можете да користите својства

2490
01:49:56,980 --> 01:49:59,480
тих објеката које користе Објецт Нотатион.

2491
01:49:59,480 --> 01:50:03,562
Тако да могу филтрирати отишли ​​у
власништво ЈСОН документа.

2492
01:50:03,562 --> 01:50:05,520
ПУБЛИКА: Дакле, сваки пут сам
учинити приступ документ,

2493
01:50:05,520 --> 01:50:07,906
Могу некако стићи на табулар--

2494
01:50:07,906 --> 01:50:08,780
ПУБЛИКА: Апсолутно.

2495
01:50:08,780 --> 01:50:09,800
Публика: --индекес и
ствари само причали.

2496
01:50:09,800 --> 01:50:11,280
Рицк Хоулихан: Да,
индекси и све то,

2497
01:50:11,280 --> 01:50:13,363
када желите да индексу
својства ЈСОН,

2498
01:50:13,363 --> 01:50:18,230
начин на који ћемо морати да урадимо то је да
убаците ЈСОН предмет или документ

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
Ти би да ЈСОН
приговор и да ћеш то рећи у реду,

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
>> ПУБЛИКА: Табуларизинг своје документе.

2507
01:50:33,520 --> 01:50:36,230
>> Рицк Хоулихан: Тачно, равнање
га, табуларизинг, тачно.

2508
01:50:36,230 --> 01:50:37,415
То је оно што радите са њим.

2509
01:50:37,415 --> 01:50:37,860
>> ПУБЛИКА: Хвала.

2510
01:50:37,860 --> 01:50:39,609
>> Рицк Хоулихан: Да,
Апсолутно, хвала.

2511
01:50:39,609 --> 01:50:42,240
ПУБЛИКА: Дакле, то је нека врста
Монго састаје Редис цлассиферс.

2512
01:50:42,240 --> 01:50:43,990
>> Рицк Хоулихан: Да,
много је тако.

2513
01:50:43,990 --> 01:50:45,940
То је добар опис за то.

2514
01:50:45,940 --> 01:50:47,490
Кул.

2515
01:50:47,490 --> 01:50:49,102