1
00:00:00,000 --> 00:00:04,969
>> [MUZYKI]

2
00:00:04,969 --> 00:00:06,010
RICK HOULIHAN: Wszystko w porządku.

3
00:00:06,010 --> 00:00:06,600
Cześć wszystkim.

4
00:00:06,600 --> 00:00:07,670
Nazywam się Rick Houlihan.

5
00:00:07,670 --> 00:00:10,330
Jestem starszy główny
Rozwiązania architekt AWS.

6
00:00:10,330 --> 00:00:14,070
I skupić się na NoSQL i
Technologie DynamoDB.

7
00:00:14,070 --> 00:00:16,930
Jestem tu dzisiaj, aby porozmawiać
Ci trochę o tym.

8
00:00:16,930 --> 00:00:18,970
>> Moja przeszłość jest
głównie w warstwie danych.

9
00:00:18,970 --> 00:00:21,390
Spędziłem pół mojego rozwoju
kariera pisanie bazy danych,

10
00:00:21,390 --> 00:00:25,930
dostępu do danych, rozwiązania
dla różnych zastosowań.

11
00:00:25,930 --> 00:00:30,000
Byłem w Cloud wirtualizacji
do około 20 lat.

12
00:00:30,000 --> 00:00:33,460
Więc zanim Chmura był Chmura,
zwykliśmy nazywać narzędzie obliczeniowe.

13
00:00:33,460 --> 00:00:37,170
A pomysł był, to jak
PG & E, płacisz za to, czego używasz.

14
00:00:37,170 --> 00:00:38,800
Dziś nazywamy to chmura.

15
00:00:38,800 --> 00:00:41,239
>> Jednak z biegiem lat, pracowałem
przez kilka spółek

16
00:00:41,239 --> 00:00:42,530
prawdopodobnie nigdy nie słyszał.

17
00:00:42,530 --> 00:00:47,470
Ale mam przygotował listę techniczne
osiągnięcia, myślę, że to powiesz.

18
00:00:47,470 --> 00:00:51,620
Mam osiem patentów w systemach chmurze
wirtualizacji, mikroprocesor projekt,

19
00:00:51,620 --> 00:00:54,440
Kompleks przetwarzania zdarzeń,
oraz w innych obszarach, jak również.

20
00:00:54,440 --> 00:00:58,290
>> Tak więc te dni, skupiam się głównie na NoSQL
technologie i następne pokolenie

21
00:00:58,290 --> 00:00:59,450
Baza danych.

22
00:00:59,450 --> 00:01:03,370
I to na ogół co zamierzam
być tutaj z tobą rozmawiać dziś o.

23
00:01:03,370 --> 00:01:06,030
Więc czego można oczekiwać
z tej sesji,

24
00:01:06,030 --> 00:01:08,254
pojedziemy przez skrócie
Historia przetwarzania danych.

25
00:01:08,254 --> 00:01:10,420
To zawsze pomocny
rozumiem, skąd jesteśmy

26
00:01:10,420 --> 00:01:12,400
i dlaczego jesteśmy, gdzie jesteśmy.

27
00:01:12,400 --> 00:01:15,600
I porozmawiamy trochę
nieco o technologii NoSQL

28
00:01:15,600 --> 00:01:17,500
z fundamentalnego punktu widzenia.

29
00:01:17,500 --> 00:01:19,870
>> Będziemy się do niektórych
elementy wewnętrzne DynamoDB.

30
00:01:19,870 --> 00:01:24,350
DynamoDB jest AWS bez smaku.

31
00:01:24,350 --> 00:01:27,340
To w pełni zarządzany i
hostowane rozwiązanie NoSQL.

32
00:01:27,340 --> 00:01:32,420
I porozmawiamy trochę o tabeli
struktura, API, typy danych, indeksów,

33
00:01:32,420 --> 00:01:35,177
a niektóre z wewnętrznych
tej technologii DynamoDB.

34
00:01:35,177 --> 00:01:37,760
Zajmiemy się część projektu
wzory i najlepsze praktyki.

35
00:01:37,760 --> 00:01:39,968
Porozmawiamy o tym, jak
korzystać z tej technologii dla niektórych

36
00:01:39,968 --> 00:01:41,430
dzisiejszych aplikacjach.

37
00:01:41,430 --> 00:01:44,820
A potem porozmawiamy trochę
o ewolucji lub powstania

38
00:01:44,820 --> 00:01:48,980
nowego paradygmatu w programowaniu
zwane aplikacje sterowane zdarzeniami

39
00:01:48,980 --> 00:01:51,580
i jak DynamoDB odgrywa w tym również.

40
00:01:51,580 --> 00:01:54,690
I zostawimy Cię trochę
architektura referencyjna dyskusja

41
00:01:54,690 --> 00:01:59,540
więc możemy mówić o niektórych
sposoby można użyć DynamoDB.

42
00:01:59,540 --> 00:02:04,116
>> Więc najpierw off-- jest to pytanie
Słyszałem wiele o to, co jest w bazie.

43
00:02:04,116 --> 00:02:06,240
Wiele osób myśli, że
wiesz co to jest baza danych jest.

44
00:02:06,240 --> 00:02:08,360
Jeśli Google, musisz to zobaczyć.

45
00:02:08,360 --> 00:02:11,675
Jest to zorganizowanego zestawu danych odbywa
w komputerze, zwłaszcza taki, który

46
00:02:11,675 --> 00:02:13,600
jest przystosowany na różne sposoby.

47
00:02:13,600 --> 00:02:16,992
Przypuszczam, że to dobry
Definicja nowoczesnych danych.

48
00:02:16,992 --> 00:02:19,450
Ale nie podoba mi się to, bo
oznacza to kilka rzeczy.

49
00:02:19,450 --> 00:02:20,935
To oznacza strukturę.

50
00:02:20,935 --> 00:02:23,120
I oznacza to, że jest na komputerze.

51
00:02:23,120 --> 00:02:25,750
I bazy danych nie
Zawsze istnieje na komputerach.

52
00:02:25,750 --> 00:02:28,020
Bazy danych rzeczywiście istniał na wiele sposobów.

53
00:02:28,020 --> 00:02:32,000
>> Więc lepiej definicji
Baza danych jest coś takiego.

54
00:02:32,000 --> 00:02:34,786
Baza danych jest zorganizowana
mechanizm przechowywania, zarządzania,

55
00:02:34,786 --> 00:02:35,910
i pobierania informacji.

56
00:02:35,910 --> 00:02:36,868
To jest z About.com.

57
00:02:36,868 --> 00:02:42,080
Tak mi się to podoba, bo to naprawdę rozmowy
o baza danych jest repozytorium,

58
00:02:42,080 --> 00:02:44,800
repozytorium
informacji, niekoniecznie

59
00:02:44,800 --> 00:02:46,780
coś znajduje się na komputerze.

60
00:02:46,780 --> 00:02:49,290
I w całej historii,
nie zawsze było komputerów.

61
00:02:49,290 --> 00:02:52,110
>> Teraz, gdy pytam średnią
deweloper dziś, co jest

62
00:02:52,110 --> 00:02:54,770
baza danych, to jest odpowiedź uzyskać.

63
00:02:54,770 --> 00:02:56,070
Gdzieś mogę trzymać rzeczy.

64
00:02:56,070 --> 00:02:56,670
Dobrze?

65
00:02:56,670 --> 00:02:58,725
I to prawda.

66
00:02:58,725 --> 00:02:59,600
Ale to niefortunne.

67
00:02:59,600 --> 00:03:02,700
Ponieważ baza danych jest naprawdę
podstawą nowoczesnej aplikacji.

68
00:03:02,700 --> 00:03:04,810
Jest to fundacja
z każdej aplikacji.

69
00:03:04,810 --> 00:03:07,240
I jak budować, że
bazy danych, jak zorganizować

70
00:03:07,240 --> 00:03:11,750
że dane będzie dyktować, jak to
Aplikacja wykonuje, jak skalować.

71
00:03:11,750 --> 00:03:14,640
>> Tak dużo mojej dzisiejszej pracy
ma do czynienia z tym, co

72
00:03:14,640 --> 00:03:17,180
dzieje się, gdy deweloperzy
takie podejście

73
00:03:17,180 --> 00:03:19,510
i radzenia sobie z następstwami
wniosku, że

74
00:03:19,510 --> 00:03:24,966
jest teraz skalowania poza oryginalny
intencji i cierpienie z powodu złej konstrukcji.

75
00:03:24,966 --> 00:03:26,840
Więc mam nadzieję, że kiedy
odejść dzisiaj, będziesz

76
00:03:26,840 --> 00:03:29,010
mają kilka narzędzi w
twój pas, który będzie utrzymywać was

77
00:03:29,010 --> 00:03:32,566
od podejmowania tych samych błędów.

78
00:03:32,566 --> 00:03:33,066
W porządku.

79
00:03:33,066 --> 00:03:36,360
Więc porozmawiajmy o odrobinie
oś czasu z technologii baz danych.

80
00:03:36,360 --> 00:03:38,830
Myślę, że czytałem
Artykuł nie tak dawno temu

81
00:03:38,830 --> 00:03:43,020
i powiedział coś na lines--
jest to bardzo poetyckie zestawienie.

82
00:03:43,020 --> 00:03:46,590
Mówi się, że historia
przetwarzania danych jest

83
00:03:46,590 --> 00:03:49,350
pełne wysokich znaków wodnych
obfitości danych.

84
00:03:49,350 --> 00:03:49,920
OK.

85
00:03:49,920 --> 00:03:52,532
Teraz myślę, że to trochę prawda.

86
00:03:52,532 --> 00:03:54,990
Ale tak naprawdę patrzeć na to, jak
historia jest rzeczywiście pełne

87
00:03:54,990 --> 00:03:56,820
z wysokim ciśnieniem znaku wodnego danych.

88
00:03:56,820 --> 00:04:00,040
Ponieważ przepływności
Spożycie nigdy nie idzie w dół.

89
00:04:00,040 --> 00:04:01,360
To idzie w górę tylko.

90
00:04:01,360 --> 00:04:03,670
>> I innowacji pojawia się, gdy
Widzimy presję danych, które

91
00:04:03,670 --> 00:04:07,825
Jest to ilość danych jest
teraz czekać do systemu.

92
00:04:07,825 --> 00:04:12,027
I nie może być przetwarzany
wydajnie zarówno w czasie lub kosztów.

93
00:04:12,027 --> 00:04:14,110
I wtedy zaczniemy
patrzeć pod ciśnieniem danych.

94
00:04:14,110 --> 00:04:15,920
>> Tak więc, gdy spojrzymy na
Pierwsza baza danych, w tym

95
00:04:15,920 --> 00:04:17,180
to ten, który był między naszymi uszami.

96
00:04:17,180 --> 00:04:18,310
Wszyscy rodzimy się z nim.

97
00:04:18,310 --> 00:04:19,194
Jest to miły bazy danych.

98
00:04:19,194 --> 00:04:21,110
Posiada wysoką dostępność.

99
00:04:21,110 --> 00:04:21,959
To zawsze.

100
00:04:21,959 --> 00:04:23,930
Zawsze można je dostać.

101
00:04:23,930 --> 00:04:24,890
>> Ale jest jeden użytkownik.

102
00:04:24,890 --> 00:04:26,348
Nie mogę podzielić się moimi myślami z Tobą.

103
00:04:26,348 --> 00:04:28,370
Nie można dostać moje myśli
jeśli chcesz je.

104
00:04:28,370 --> 00:04:30,320
A ich abilitiy nie jest tak dobry.

105
00:04:30,320 --> 00:04:32,510
Zapominamy rzeczy.

106
00:04:32,510 --> 00:04:36,540
Co jakiś czas, jeden z nas liście
i przenosi na inną istnienia

107
00:04:36,540 --> 00:04:39,110
i stracić wszystko
że był w tej bazie danych.

108
00:04:39,110 --> 00:04:40,640
Więc to nie jest wszystko, co dobre.

109
00:04:40,640 --> 00:04:43,189
>> I to działa dobrze w czasie
kiedy byliśmy z powrotem w dzień

110
00:04:43,189 --> 00:04:46,230
kiedy wszystko tak naprawdę potrzebne, aby wiedzieć,
gdzie idziemy, aby przejść na jutro

111
00:04:46,230 --> 00:04:49,630
lub gdy zbieramy najlepsze jedzenie.

112
00:04:49,630 --> 00:04:52,820
Ale jak zaczęliśmy się rozwijać jako
Cywilizacja i rząd rozpoczął

113
00:04:52,820 --> 00:04:55,152
aby wejść w życie, oraz
firm zaczęło się rozwijać,

114
00:04:55,152 --> 00:04:57,360
zaczęliśmy zdawać sobie sprawę, my
potrzebujemy trochę więcej niż to, co

115
00:04:57,360 --> 00:04:58,210
możemy umieścić w naszej głowie.

116
00:04:58,210 --> 00:04:58,870
W porządku?

117
00:04:58,870 --> 00:05:00,410
>> Potrzebowaliśmy systemy zapisu.

118
00:05:00,410 --> 00:05:02,220
Potrzebowaliśmy miejsca, aby być w stanie przechowywać dane.

119
00:05:02,220 --> 00:05:05,450
Zaczęliśmy więc pisanie dokumentów,
tworzenie biblioteki i archiwa.

120
00:05:05,450 --> 00:05:08,000
Zaczęliśmy rozwijający się
System A rachunkowości księgi głównej.

121
00:05:08,000 --> 00:05:12,200
I że system liczenia księgi
prowadził świat przez wiele wieków,

122
00:05:12,200 --> 00:05:15,580
a może nawet tysiące lat, jak
my niby wzrosła do tego stopnia,

123
00:05:15,580 --> 00:05:18,420
w przypadku, gdy obciążenie danych przekroczyła
zdolność tych systemów

124
00:05:18,420 --> 00:05:19,870
aby móc go zawierają.

125
00:05:19,870 --> 00:05:22,070
>> I to właściwie się stało w 1880 roku.

126
00:05:22,070 --> 00:05:22,570
Dobrze?

127
00:05:22,570 --> 00:05:24,390
W 1880 roku US Census.

128
00:05:24,390 --> 00:05:26,976
To jest naprawdę gdzie zwrotnym
wskazują nowoczesnego przetwarzania danych.

129
00:05:26,976 --> 00:05:28,850
Jest to punkt, w
których ilość danych

130
00:05:28,850 --> 00:05:32,060
który był zbierany przez
Rząd USA dostał się do punktu

131
00:05:32,060 --> 00:05:34,005
gdzie zajęło osiem lat do przetworzenia.

132
00:05:34,005 --> 00:05:36,350
>> Teraz, osiem years-- jak
wiesz, spisu

133
00:05:36,350 --> 00:05:39,180
kursuje co 10 years-- więc jest
dość oczywiste, że do czasu

134
00:05:39,180 --> 00:05:41,419
dostał 1890 spis ludności,
ilość danych

135
00:05:41,419 --> 00:05:43,210
miał być przetwarzane
przez rząd było

136
00:05:43,210 --> 00:05:46,335
będzie przekraczać 10 lat, że to
odbędzie się premiera nowej spisu.

137
00:05:46,335 --> 00:05:47,250
To był problem.

138
00:05:47,250 --> 00:05:49,000
>> Więc facet o imieniu Herman
Hollerith przyszedł

139
00:05:49,000 --> 00:05:52,640
jednostki i wymyślił rekordowy cios
kart, czytnik kart cios, karta cios

140
00:05:52,640 --> 00:05:58,420
tabulacji, a sortowanie
mechanizmy dla tej technologii.

141
00:05:58,420 --> 00:06:01,860
A to, że spółka utworzona na
razem, wraz z kilkoma innymi,

142
00:06:01,860 --> 00:06:05,450
w rzeczywistości stał się jednym z filarami
mała firma wiemy dzisiaj o nazwie IBM.

143
00:06:05,450 --> 00:06:08,417
>> Więc początkowo był IBM w
firma w bazie.

144
00:06:08,417 --> 00:06:09,750
I to jest naprawdę to, co zrobili.

145
00:06:09,750 --> 00:06:11,110
Zrobili przetwarzania danych.

146
00:06:11,110 --> 00:06:15,400
>> Jak więc rozprzestrzeniania stempla
karty, pomysłowe mechanizmy

147
00:06:15,400 --> 00:06:18,560
jest w stanie wykorzystać, że
Technologia do sondowania posortowanych zestawów wyników.

148
00:06:18,560 --> 00:06:20,726
Możesz zobaczyć na tym zdjęciu
nie mamy little--

149
00:06:20,726 --> 00:06:23,970
to trochę small-- ale widać
bardzo pomysłowy mechanizm mechaniczna

150
00:06:23,970 --> 00:06:26,970
gdzie mamy talię kart cios.

151
00:06:26,970 --> 00:06:28,720
I przy czyimś
mały śrubokręt

152
00:06:28,720 --> 00:06:31,400
i trzymać poprzez
Gniazda i unosząc ją w górę

153
00:06:31,400 --> 00:06:34,820
aby ten mecz, który
ustawić posortowane wyniki.

154
00:06:34,820 --> 00:06:36,270
>> To jest agregacja.

155
00:06:36,270 --> 00:06:38,690
Robimy to cały czas
dzisiaj w komputerze

156
00:06:38,690 --> 00:06:40,100
gdzie można zrobić to w bazie danych.

157
00:06:40,100 --> 00:06:41,620
Kiedyś to zrobić ręcznie, prawda?

158
00:06:41,620 --> 00:06:42,994
Ludzie umieścić te rzeczy razem.

159
00:06:42,994 --> 00:06:45,440
I to było rozprzestrzenianie
tych kart perforowanych

160
00:06:45,440 --> 00:06:50,070
do tego, co nazwaliśmy bębnów danych
i szpule danych, taśmy papieru.

161
00:06:50,070 --> 00:06:55,980
>> Przemysł przetwarzanie danych trwało
lekcja z fortepiany graczy.

162
00:06:55,980 --> 00:06:57,855
Pianina gracz z powrotem w
Przełom XIX i XX wieku

163
00:06:57,855 --> 00:07:02,100
używałem zwojów z gniazd
na to powiedzieć, które klawisze do odegrania.

164
00:07:02,100 --> 00:07:05,380
Tak, że technologia została przystosowana
ostatecznie do przechowywania danych cyfrowych

165
00:07:05,380 --> 00:07:08,070
ponieważ mogą umieścić te dane
na tych bębnach taśmie papierowej.

166
00:07:08,070 --> 00:07:10,870
>> Obecnie, w rezultacie, dane
został actually-- jak

167
00:07:10,870 --> 00:07:14,960
uzyskać dostęp do tych danych był bezpośrednio
zależne od tego, jak go przechowywać.

168
00:07:14,960 --> 00:07:17,825
Więc jeśli mogę umieścić dane na taśmie,
Miałem dostęp do danych liniowo.

169
00:07:17,825 --> 00:07:20,475
Musiałem toczyć całość
Taśma na dostęp do wszystkich danych.

170
00:07:20,475 --> 00:07:22,600
Jeśli mogę umieścić dane w ponczu
Karty, mogę do niego dostęp

171
00:07:22,600 --> 00:07:26,270
w trochę bardziej losowy
moda, może nie tak szybko.

172
00:07:26,270 --> 00:07:30,770
>> Ale były ograniczenia w jak
dostęp do danych w oparciu o jaki został zapisany.

173
00:07:30,770 --> 00:07:32,890
A więc to był problem
wchodząc w latach 50-tych.

174
00:07:32,890 --> 00:07:37,890
Znowu możemy zacząć, aby zobaczyć, że jak my
rozwój nowych technologii do przetwarzania

175
00:07:37,890 --> 00:07:41,670
dane, w prawo, otwiera
drzwi do nowych rozwiązań,

176
00:07:41,670 --> 00:07:45,852
dla nowych programów, nowe
aplikacje dla tych danych.

177
00:07:45,852 --> 00:07:47,810
I naprawdę, zarządzanie
może być powodem

178
00:07:47,810 --> 00:07:49,435
Dlatego opracowano niektóre z tych systemów.

179
00:07:49,435 --> 00:07:52,290
Ale firma szybko stała
kierowca za ewolucją

180
00:07:52,290 --> 00:07:54,720
nowoczesnej bazy danych i
nowoczesny system plików.

181
00:07:54,720 --> 00:07:56,870
>> Więc następną rzeczą, że
przyszedł był w latach 50-tych

182
00:07:56,870 --> 00:08:00,780
był system plików i
rozwój losowej przechowywania dostępu.

183
00:08:00,780 --> 00:08:02,050
To było piękne.

184
00:08:02,050 --> 00:08:06,230
Teraz, wszystko nagle, możemy umieścić nasze
pliki w dowolnym miejscu na tych dyskach twardych

185
00:08:06,230 --> 00:08:09,760
i możemy uzyskać dostęp do tych danych w sposób losowy.

186
00:08:09,760 --> 00:08:11,950
Możemy analizować że
Informacje z plików.

187
00:08:11,950 --> 00:08:14,920
A my rozwiązany na świecie
problemy z przetwarzaniem danych.

188
00:08:14,920 --> 00:08:17,550
>> I to trwało około 20 lub
30 lat, aż do ewolucji

189
00:08:17,550 --> 00:08:22,100
z relacyjnej bazy danych, która
jest, kiedy świat postanowił teraz

190
00:08:22,100 --> 00:08:27,940
trzeba mieć repozytorium, które pokonuje
sprawl danych w całym pliku

191
00:08:27,940 --> 00:08:29,540
systemy, które zbudowaliśmy. Dobrze?

192
00:08:29,540 --> 00:08:34,270
Zbyt dużo danych rozproszonych w zbyt wiele
miejscach, deduplikacji danych,

193
00:08:34,270 --> 00:08:37,120
a koszt magazynowania był ogromny.

194
00:08:37,120 --> 00:08:43,760
>> W latach 70., najdroższe zasób
że komputer miał był przechowywania.

195
00:08:43,760 --> 00:08:46,200
Procesor był
uważana za stałą kosztów.

196
00:08:46,200 --> 00:08:49,030
Kiedy kupić pole,
CPU wykonuje pracę.

197
00:08:49,030 --> 00:08:51,960
Zapowiada się kręci, czy
to faktycznie działa, czy nie.

198
00:08:51,960 --> 00:08:53,350
To naprawdę zatopiony kosztów.

199
00:08:53,350 --> 00:08:56,030
>> Ale to, co kosztowało mnie jako
biznes jest składowanie.

200
00:08:56,030 --> 00:09:00,020
Jeśli mam kupić więcej dysków następna
miesięcznie, to jest realne koszty, które płacę.

201
00:09:00,020 --> 00:09:01,620
I że przechowywanie jest kosztowne.

202
00:09:01,620 --> 00:09:05,020
>> Teraz musimy szybko do przodu 40 rok
a my mamy inny problem.

203
00:09:05,020 --> 00:09:10,020
Wylicz jest teraz
Najdroższe zasobów.

204
00:09:10,020 --> 00:09:11,470
Składowanie jest tanie.

205
00:09:11,470 --> 00:09:14,570
To znaczy, można przejść w dowolnym miejscu na
chmury i możemy znaleźć taniego miejsca.

206
00:09:14,570 --> 00:09:17,190
Ale co, nie mogę znaleźć jest tanie obliczeniowej.

207
00:09:17,190 --> 00:09:20,700
>> Więc ewolucji dzisiejszy
technologii, technologii baz danych,

208
00:09:20,700 --> 00:09:23,050
jest naprawdę koncentruje się wokół
rozproszonych baz danych

209
00:09:23,050 --> 00:09:26,960
które nie cierpią z powodu
tego samego typu skali

210
00:09:26,960 --> 00:09:29,240
Ograniczenia relacyjnych baz danych.

211
00:09:29,240 --> 00:09:32,080
Porozmawiamy trochę o
co to właściwie oznacza.

212
00:09:32,080 --> 00:09:34,760
>> Ale jeden z powodów, i
kierowca za this-- my

213
00:09:34,760 --> 00:09:38,290
mówił o ciśnieniu danych.

214
00:09:38,290 --> 00:09:41,920
Ciśnienie dane jest coś
który napędza innowacje.

215
00:09:41,920 --> 00:09:44,610
A jeśli spojrzeć na ponad
ostatnie pięć lat,

216
00:09:44,610 --> 00:09:48,180
Jest to wykres jaki dane
obciążenia całej ogólnej przedsiębiorstwa

217
00:09:48,180 --> 00:09:49,640
Wygląda na to, w ciągu ostatnich pięciu lat.

218
00:09:49,640 --> 00:09:52,570
>> A ogólna zasada
te days-- jeśli go Google--

219
00:09:52,570 --> 00:09:55,290
90% danych, które
przechowujemy dzisiaj, i to

220
00:09:55,290 --> 00:09:57,330
wygenerowany w ciągu ostatnich dwóch lat.

221
00:09:57,330 --> 00:09:57,911
OK.

222
00:09:57,911 --> 00:09:59,410
Otóż, nie jest to tendencja to nowe.

223
00:09:59,410 --> 00:10:01,230
Jest to trend, który był
udaniem się na 100 lat.

224
00:10:01,230 --> 00:10:03,438
Odkąd Herman Hollerith
opracowała kartę dziurkowania,

225
00:10:03,438 --> 00:10:08,040
byliśmy budowy repozytoriów danych
i gromadzenie danych w fenomenalnym tempie.

226
00:10:08,040 --> 00:10:10,570
>> Tak więc w ciągu ostatnich 100 lat,
widzieliśmy ten trend.

227
00:10:10,570 --> 00:10:11,940
To nie zmieni.

228
00:10:11,940 --> 00:10:14,789
W przyszłości mamy zamiar zobaczyć
tego, jeśli nie przyspieszonego trendu.

229
00:10:14,789 --> 00:10:16,330
I można zobaczyć co to wygląda.

230
00:10:16,330 --> 00:10:23,510
>> Jeżeli firma w 2010 roku był jednym
terabajt danych w zarządzaniu,

231
00:10:23,510 --> 00:10:27,080
dziś to oznacza, że ​​są
zarządzanie 6,5 petabajtów danych.

232
00:10:27,080 --> 00:10:30,380
To 6500 razy więcej danych.

233
00:10:30,380 --> 00:10:31,200
I wiem, że to.

234
00:10:31,200 --> 00:10:33,292
Pracuję z tych firm na co dzień.

235
00:10:33,292 --> 00:10:35,000
Pięć lat temu,
by rozmawiać z firmami

236
00:10:35,000 --> 00:10:38,260
kto by ze mną porozmawiać o tym, co ból
jest zarządzanie terabajtów danych.

237
00:10:38,260 --> 00:10:39,700
A oni mówią
mi o tym, jak widzimy,

238
00:10:39,700 --> 00:10:41,825
że jest to prawdopodobnie będzie
być petabajtów lub dwa

239
00:10:41,825 --> 00:10:43,030
w ciągu kilku lat.

240
00:10:43,030 --> 00:10:45,170
>> Te same firmy
Dzisiaj mam spotkanie z,

241
00:10:45,170 --> 00:10:48,100
i mówią mi o
Problemem są nie o zarządzanie

242
00:10:48,100 --> 00:10:51,440
dziesiątki, 20 petabajtów danych.

243
00:10:51,440 --> 00:10:53,590
Więc wybuchu
Dane w przemyśle

244
00:10:53,590 --> 00:10:56,670
jedzie ogromne
potrzebują lepszych rozwiązań.

245
00:10:56,670 --> 00:11:00,980
I relacyjna baza danych jest
po prostu nie mieszka się do popytu.

246
00:11:00,980 --> 00:11:03,490
>> A więc istnieje liniowa
Korelacja pomiędzy ciśnieniem danych

247
00:11:03,490 --> 00:11:05,210
i innowacje techniczne.

248
00:11:05,210 --> 00:11:07,780
Historia pokazało nam
to, że w miarę upływu czasu,

249
00:11:07,780 --> 00:11:11,090
gdy ilość danych
które muszą być przetwarzane

250
00:11:11,090 --> 00:11:15,490
przekracza wydajności systemu
przetworzyć go w odpowiednim czasie

251
00:11:15,490 --> 00:11:18,870
i przy rozsądnych kosztach,
to nowe technologie

252
00:11:18,870 --> 00:11:21,080
są wymyślone, aby rozwiązać te problemy.

253
00:11:21,080 --> 00:11:24,090
Te nowe technologie,
z kolei otworzyć drzwi

254
00:11:24,090 --> 00:11:27,840
na inny zestaw problemów, które
nabiera jeszcze więcej danych.

255
00:11:27,840 --> 00:11:29,520
>> Teraz, nie będziemy się powstrzymać.

256
00:11:29,520 --> 00:11:30,020
Dobrze?

257
00:11:30,020 --> 00:11:31,228
Nie zamierzamy zatrzymać to.

258
00:11:31,228 --> 00:11:31,830
Czemu?

259
00:11:31,830 --> 00:11:35,520
Ponieważ nie można wiedzieć wszystkiego
ma wiedzieć we wszechświecie.

260
00:11:35,520 --> 00:11:40,510
I tak długo, jak byliśmy przy życiu,
w całej historii człowieka,

261
00:11:40,510 --> 00:11:43,440
mamy zawsze napędzane wiedzieć więcej.

262
00:11:43,440 --> 00:11:49,840
>> Tak więc wydaje się, że każdy cal ruszamy
ścieżką odkryć naukowych,

263
00:11:49,840 --> 00:11:54,620
jesteśmy pomnożenie ilości danych
że musimy przetwarzać wykładniczo

264
00:11:54,620 --> 00:11:59,920
jak odkrywamy coraz więcej i więcej
na temat wewnętrznych mechanizmów życia,

265
00:11:59,920 --> 00:12:04,530
o tym, jak działa wszechświat, o
jazdy odkrycie naukowe,

266
00:12:04,530 --> 00:12:06,440
i wynalazku, które
robimy dzisiaj.

267
00:12:06,440 --> 00:12:09,570
Objętość danych tylko
stale wzrasta.

268
00:12:09,570 --> 00:12:12,120
Tak jest w stanie poradzić sobie z
Ten problem jest ogromny.

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

270
00:12:14,790 --> 00:12:17,410
>> Tak więc jedną z rzeczy,
Patrząc, jak, dlaczego NoSQL?

271
00:12:17,410 --> 00:12:19,200
Jak NoSQL rozwiązać ten problem?

272
00:12:19,200 --> 00:12:24,980
Cóż, relacyjnych baz danych,
Structured Query Language,

273
00:12:24,980 --> 00:12:28,600
SQL-- to naprawdę konstrukt
relacyjna database-- te rzeczy są

274
00:12:28,600 --> 00:12:30,770
zoptymalizowany do przechowywania.

275
00:12:30,770 --> 00:12:33,180
>> Jeszcze w latach 70-tych, znowu,
Dysk jest kosztowne.

276
00:12:33,180 --> 00:12:36,990
Ćwiczenie zaopatrzenia przechowywania
w przedsiębiorstwie nigdy się nie kończy.

277
00:12:36,990 --> 00:12:37,490
Wiem.

278
00:12:37,490 --> 00:12:38,020
I żył.

279
00:12:38,020 --> 00:12:41,250
Napisałem sterowniki pamięci dla
enterprised firma SuperServer

280
00:12:41,250 --> 00:12:42,470
jeszcze w latach 90-tych.

281
00:12:42,470 --> 00:12:45,920
A wiersz jest rozlewanie innym
macierz pamięci masowej po prostu coś, co

282
00:12:45,920 --> 00:12:47,600
się na co dzień w przedsiębiorstwie.

283
00:12:47,600 --> 00:12:49,030
I nigdy się nie zatrzymał.

284
00:12:49,030 --> 00:12:52,690
Wyższa przechowywania gęstość, popyt
dla wysokiego składowania gęstości,

285
00:12:52,690 --> 00:12:56,340
i bardziej efektywne przechowywanie
devices-- to nigdy nie przestał.

286
00:12:56,340 --> 00:13:00,160
>> I NoSQL jest doskonałą technologią
ponieważ normalizuje danych.

287
00:13:00,160 --> 00:13:02,210
To de-duplikuje dane.

288
00:13:02,210 --> 00:13:07,180
Stawia dane w strukturze,
jest agnostykiem do każdego wzoru dostępu.

289
00:13:07,180 --> 00:13:11,600
Wiele aplikacji może trafić, że
Baza danych SQL, uruchamiania kwerend ad hoc,

290
00:13:11,600 --> 00:13:15,950
i uzyskać dane w formie, że
trzeba przetworzyć ich obciążeń.

291
00:13:15,950 --> 00:13:17,570
To brzmi fantastycznie.

292
00:13:17,570 --> 00:13:21,350
Ale w dolnej linii jest z każdym
System, jeśli jest agnostykiem do wszystkiego,

293
00:13:21,350 --> 00:13:23,500
jest zoptymalizowany do niczego.

294
00:13:23,500 --> 00:13:24,050
OK?

295
00:13:24,050 --> 00:13:26,386
>> I to jest to, co się z
relacyjna baza danych.

296
00:13:26,386 --> 00:13:27,510
Jest zoptymalizowany do przechowywania.

297
00:13:27,510 --> 00:13:28,280
To znormalizowane.

298
00:13:28,280 --> 00:13:29,370
Jest to relacyjna.

299
00:13:29,370 --> 00:13:31,660
Obsługuje zapytań ad hoc.

300
00:13:31,660 --> 00:13:34,000
I to i to skaluje pionowo.

301
00:13:34,000 --> 00:13:39,030
>> Jeśli trzeba uzyskać większą bazę danych SQL
lub bardziej wydajne bazy danych SQL,

302
00:13:39,030 --> 00:13:41,090
Idę kupić większy kawałek żelaza.

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

304
00:13:41,600 --> 00:13:44,940
Pracowałem już z wieloma klientami
które zostały przez głównych ulepszeń

305
00:13:44,940 --> 00:13:48,340
w infrastrukturę SQL tylko
aby dowiedzieć się sześć miesięcy później,

306
00:13:48,340 --> 00:13:49,750
oni znowu uderza w ścianę.

307
00:13:49,750 --> 00:13:55,457
A odpowiedź od Oracle lub MSSQL
lub ktokolwiek inny, to dostać większe pole.

308
00:13:55,457 --> 00:13:58,540
Cóż, prędzej czy później, nie można kupić
większe okno, a to prawdziwy problem.

309
00:13:58,540 --> 00:14:00,080
Musimy rzeczywiście coś zmienić.

310
00:14:00,080 --> 00:14:01,080
Więc gdzie to działa?

311
00:14:01,080 --> 00:14:06,560
To działa również w trybie offline
analizy, typu OLAP obciążenia.

312
00:14:06,560 --> 00:14:08,670
I to jest naprawdę, gdzie należy SQL.

313
00:14:08,670 --> 00:14:12,540
Teraz, jest używany do dziś w wielu Online
transakcyjnego przetwarzania typu

314
00:14:12,540 --> 00:14:13,330
aplikacje.

315
00:14:13,330 --> 00:14:16,460
I to działa dobrze na
niektóre poziom wykorzystania,

316
00:14:16,460 --> 00:14:18,670
ale to po prostu nie skaluje
sposób, że NoSQL robi.

317
00:14:18,670 --> 00:14:20,660
I porozmawiamy trochę
trochę o tym, dlaczego to jest.

318
00:14:20,660 --> 00:14:23,590
>> Teraz NoSQL, z drugiej strony,
jest bardziej zoptymalizowany dla obliczeniowych.

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

320
00:14:24,540 --> 00:14:26,830
Nie jest agnostyczne
wzór dostępu.

321
00:14:26,830 --> 00:14:31,620
Czy to, co nazywamy de znormalizowane
Struktura lub strukturze hierarchicznej.

322
00:14:31,620 --> 00:14:35,000
Dane w relacyjnej bazie danych jest
połączone z wielu tabel

323
00:14:35,000 --> 00:14:36,850
do produkcji, że trzeba.

324
00:14:36,850 --> 00:14:40,090
Dane z bazy NoSQL
przechowywany jest w dokumencie

325
00:14:40,090 --> 00:14:42,100
zawiera strukturę hierarchiczną.

326
00:14:42,100 --> 00:14:45,670
Wszystkie dane, które normalnie byłoby
połączone razem do produkcji tego widoku

327
00:14:45,670 --> 00:14:47,160
jest przechowywany w jednym dokumencie.

328
00:14:47,160 --> 00:14:50,990
I porozmawiamy trochę o
jak to działa w kilka wykresów.

329
00:14:50,990 --> 00:14:55,320
>> Ale idea jest taka, że ​​można przechowywać
Twoje dane jak tych instancji poglądów.

330
00:14:55,320 --> 00:14:56,410
OK?

331
00:14:56,410 --> 00:14:58,610
Skalowanie w poziomie.

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

333
00:14:59,556 --> 00:15:02,100
Jeśli trzeba zwiększyć
wielkość mojej klastra NoSQL,

334
00:15:02,100 --> 00:15:03,700
Nie potrzebuję, aby uzyskać większe pole.

335
00:15:03,700 --> 00:15:05,200
Mam kolejne pudło.

336
00:15:05,200 --> 00:15:07,700
A ja ci klastra razem
i mogę shard tych danych.

337
00:15:07,700 --> 00:15:10,780
Porozmawiamy trochę o
co sharding jest, aby

338
00:15:10,780 --> 00:15:14,270
możliwość skalowania do bazy danych
na wielu urządzeniach fizycznych

339
00:15:14,270 --> 00:15:18,370
i usunąć bariery, które
wymaga mnie do skalowania w pionie.

340
00:15:18,370 --> 00:15:22,080
>> Więc to naprawdę zbudowany w Internecie
przetwarzania transakcji i skala.

341
00:15:22,080 --> 00:15:25,480
Jest duża rozróżnienie
tutaj między sprawozdawczości, prawda?

342
00:15:25,480 --> 00:15:27,810
Raportowanie, ja nie wiem
pytania mam zamiar zapytać.

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

344
00:15:28,310 --> 00:15:30,570
Reporting-- jeśli ktoś z
mój dział marketingu

345
00:15:30,570 --> 00:15:34,520
chce just-- jak wielu z moich klientów
mają tę szczególną cechę, która

346
00:15:34,520 --> 00:15:37,850
kupił na tej day-- nie wiem
co zapytać się was prosić.

347
00:15:37,850 --> 00:15:39,160
Więc muszę być agnostykiem.

348
00:15:39,160 --> 00:15:41,810
>> Teraz, w Online
aplikacji transakcyjnej,

349
00:15:41,810 --> 00:15:43,820
Wiem, jakie pytania pytam.

350
00:15:43,820 --> 00:15:46,581
Zbudowałem wniosek o
bardzo specyficzny przepływ pracy.

351
00:15:46,581 --> 00:15:47,080
OK?

352
00:15:47,080 --> 00:15:50,540
Więc jeśli zoptymalizować dane
przechowywać na poparcie tego przepływu pracy,

353
00:15:50,540 --> 00:15:52,020
to będzie szybciej.

354
00:15:52,020 --> 00:15:55,190
I dlatego NoSQL możliwe
naprawdę przyspieszyć dostawę

355
00:15:55,190 --> 00:15:57,710
z tych rodzajów usług.

356
00:15:57,710 --> 00:15:58,210
W porządku.

357
00:15:58,210 --> 00:16:00,501
>> Tak więc mamy zamiar dostać się do
trochę teorii tutaj.

358
00:16:00,501 --> 00:16:03,330
I niektórzy z was, wasze oczy
może cofnąć się trochę.

359
00:16:03,330 --> 00:16:06,936
Ale postaram się go zatrzymać
jak wysoki poziom, jak mogę.

360
00:16:06,936 --> 00:16:08,880
Więc jeśli jesteś w projekcie
zarządzanie, tam

361
00:16:08,880 --> 00:16:12,280
konstrukt zwany
trójkąt ograniczeń.

362
00:16:12,280 --> 00:16:12,936
OK.

363
00:16:12,936 --> 00:16:16,060
Trójkąt ogranicza dyktatowi
nie można mieć wszystkiego cały czas.

364
00:16:16,060 --> 00:16:17,750
Nie może mieć ciasto i je zjeść.

365
00:16:17,750 --> 00:16:22,310
Więc w zarządzaniu projektami, że trójkąt
Ograniczenia to możesz mieć tanie,

366
00:16:22,310 --> 00:16:24,710
możesz mieć to szybko,
lub możesz mieć to dobrze.

367
00:16:24,710 --> 00:16:25,716
Wybierz dwa.

368
00:16:25,716 --> 00:16:27,090
Ponieważ nie można mieć wszystkie trzy.

369
00:16:27,090 --> 00:16:27,460
Dobrze?

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

371
00:16:27,820 --> 00:16:28,920
>> Więc dowiedziałeś się o tym dużo.

372
00:16:28,920 --> 00:16:31,253
Jest to potrójne ograniczenie,
Trójkąt potrójnego ograniczenia,

373
00:16:31,253 --> 00:16:34,420
lub trójkąt żelaza jest oftentimes--
kiedy mówisz do kierowników projektów,

374
00:16:34,420 --> 00:16:35,420
oni mówią o tym.

375
00:16:35,420 --> 00:16:37,640
Teraz, bazy danych mają
własne trójkąt żelaza.

376
00:16:37,640 --> 00:16:40,350
I trójkąt żelaza danych
jest to, co nazywamy twierdzeniem WPR.

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

378
00:16:41,580 --> 00:16:43,770
>> WPR dyktuje twierdzenie
jak bazy danych działają

379
00:16:43,770 --> 00:16:45,627
pod bardzo konkretnych warunkach.

380
00:16:45,627 --> 00:16:47,460
I będziemy rozmawiać o
co to warunek jest.

381
00:16:47,460 --> 00:16:52,221
Ale trzy punkty trójkąta,
że tak powiem, to C, konsystencja.

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

383
00:16:52,720 --> 00:16:56,760
Tak więc w WPR, spójność oznacza, że ​​wszystkie
Klienci, którzy mogą uzyskać dostęp do bazy danych

384
00:16:56,760 --> 00:16:59,084
zawsze będzie mieć bardzo
spójny widok danych.

385
00:16:59,084 --> 00:17:00,750
Nikt nie będzie zobaczyć dwie różne rzeczy.

386
00:17:00,750 --> 00:17:01,480
OK?

387
00:17:01,480 --> 00:17:04,020
Jeśli widzę, bazy danych,
Widzę ten sam widok

388
00:17:04,020 --> 00:17:06,130
jako mojego partnera, który widzi
tej samej bazy danych.

389
00:17:06,130 --> 00:17:07,470
To konsekwencja.

390
00:17:07,470 --> 00:17:12,099
>> Dostępność oznacza, że ​​jeżeli
baza danych, jeżeli może być osiągnięty,

391
00:17:12,099 --> 00:17:14,760
że wszyscy klienci będą zawsze
być w stanie czytać i pisać.

392
00:17:14,760 --> 00:17:15,260
OK?

393
00:17:15,260 --> 00:17:17,010
Więc każdy klient, który
można odczytać z bazy danych

394
00:17:17,010 --> 00:17:18,955
zawsze będzie w stanie przeczytać
Dane danych i pisać.

395
00:17:18,955 --> 00:17:21,819
A jeśli tak jest,
to jest dostępne systemu.

396
00:17:21,819 --> 00:17:24,230
>> I trzeci punkt jest co
nazywamy tolerancją partycji.

397
00:17:24,230 --> 00:17:24,730
OK?

398
00:17:24,730 --> 00:17:28,160
Środki tolerancji podziału
że system działa dobrze

399
00:17:28,160 --> 00:17:32,000
pomimo fizycznej sieci
przegrody pomiędzy węzłami.

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

401
00:17:32,760 --> 00:17:36,270
Więc węzłach klastra nie może
się ze sobą, co się dzieje?

402
00:17:36,270 --> 00:17:36,880
W porządku.

403
00:17:36,880 --> 00:17:39,545
>> Więc relacyjnych baz danych choose--
można wybrać dwa z nich.

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

405
00:17:40,045 --> 00:17:43,680
Więc relacyjne bazy danych wybrać
być spójne i dostępne.

406
00:17:43,680 --> 00:17:47,510
Jeśli partycja dzieje się między
z DataNodes w magazynie danych,

407
00:17:47,510 --> 00:17:48,831
baza danych wywala.

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

409
00:17:49,330 --> 00:17:50,900
To po prostu idzie w dół.

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

411
00:17:51,450 --> 00:17:54,230
>> A to dlatego, że mają
rośnie z większych polach.

412
00:17:54,230 --> 00:17:54,730
Dobrze?

413
00:17:54,730 --> 00:17:58,021
Ponieważ nie no-- zwykle, klaster
bazy danych, nie ma bardzo wielu z nich

414
00:17:58,021 --> 00:17:59,590
które działają w ten sposób.

415
00:17:59,590 --> 00:18:03,019
Ale większość baz danych skalować
pionowo w jednej obudowie.

416
00:18:03,019 --> 00:18:05,060
Ponieważ muszą one być
spójne i dostępne.

417
00:18:05,060 --> 00:18:10,320
Jeśli partycja miał być wstrzykiwany
to trzeba dokonać wyboru.

418
00:18:10,320 --> 00:18:13,720
Musisz dokonać wyboru pomiędzy
jest spójna i dostępna.

419
00:18:13,720 --> 00:18:16,080
>> I to, co zrobić, baz danych NoSQL.

420
00:18:16,080 --> 00:18:16,580
W porządku.

421
00:18:16,580 --> 00:18:20,950
Tak więc baza danych NoSQL, to
jest w dwóch smakach.

422
00:18:20,950 --> 00:18:22,990
Mamy have-- dobrze, to
jest w wielu smakach,

423
00:18:22,990 --> 00:18:26,140
ale chodzi o dwa podstawowe
characteristics-- co

424
00:18:26,140 --> 00:18:30,050
nazwalibyśmy bazy CP lub
spójne i partycja tolerancji

425
00:18:30,050 --> 00:18:31,040
system.

426
00:18:31,040 --> 00:18:34,930
Ci faceci dokonać wyboru, że gdy
węzły tracą kontakt ze sobą,

427
00:18:34,930 --> 00:18:37,091
nie będziemy, aby umożliwić
ludzie napisać więcej.

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

429
00:18:37,590 --> 00:18:41,855
>> Do czasu, że partycja jest usunięta,
dostęp zapisu jest zablokowany.

430
00:18:41,855 --> 00:18:43,230
Oznacza to, że nie są one dostępne.

431
00:18:43,230 --> 00:18:44,510
Są one spójne.

432
00:18:44,510 --> 00:18:46,554
Kiedy widzimy, że
Partycja wstrzyknąć sobie,

433
00:18:46,554 --> 00:18:48,470
teraz jesteśmy zgodne,
bo nie będziemy

434
00:18:48,470 --> 00:18:51,517
aby umożliwić zmianę danych na dwóch
Boki partycji niezależnie

435
00:18:51,517 --> 00:18:52,100
od siebie.

436
00:18:52,100 --> 00:18:54,130
Będziemy musieli
przywrócić komunikację

437
00:18:54,130 --> 00:18:56,930
przed każdą aktualizacją
Dane są dozwolone.

438
00:18:56,930 --> 00:18:58,120
OK?

439
00:18:58,120 --> 00:19:02,650
>> Kolejny smak byłby system AP,
lub dostępne i dzieli

440
00:19:02,650 --> 00:19:03,640
System tolerancji.

441
00:19:03,640 --> 00:19:05,320
Ci faceci nie dbają.

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

443
00:19:06,020 --> 00:19:08,960
Każdy węzeł, który dostaje
Napisać, my ją podjąć.

444
00:19:08,960 --> 00:19:11,480
Więc jestem replikowania moich danych
na wielu węzłach.

445
00:19:11,480 --> 00:19:14,730
Węzły te się klient, klient przychodzi
w, mówi, mam zamiar napisać kilka danych.

446
00:19:14,730 --> 00:19:16,300
Węzeł mówi, nie ma problemu.

447
00:19:16,300 --> 00:19:18,580
Węzeł obok niego dostaje
write na tej samej płycie,

448
00:19:18,580 --> 00:19:20,405
ma zamiar powiedzieć, nie ma problemu.

449
00:19:20,405 --> 00:19:23,030
Gdzieś z powrotem na koniec z powrotem,
że dane będzie powtórzyć.

450
00:19:23,030 --> 00:19:27,360
A potem ktoś będzie sobie sprawę,
Oho, to system będzie sobie sprawę, uh-oh,

451
00:19:27,360 --> 00:19:28,870
nastąpiła aktualizacja do dwóch stron.

452
00:19:28,870 --> 00:19:30,370
Co robimy?

453
00:19:30,370 --> 00:19:33,210
A co oni robią to jest
robią coś, co

454
00:19:33,210 --> 00:19:36,080
pozwala im rozwiązać ten stan danych.

455
00:19:36,080 --> 00:19:39,000
I będziemy rozmawiać o
że w następnej tabeli.

456
00:19:39,000 --> 00:19:40,000
>> Rzecz podkreślić tutaj.

457
00:19:40,000 --> 00:19:42,374
A ja nie zamierzam się zbyt
wiele do tego, ponieważ

458
00:19:42,374 --> 00:19:43,510
dostaje się do głębokiej teorii danych.

459
00:19:43,510 --> 00:19:46,670
Ale jest transakcyjny
ramy, które

460
00:19:46,670 --> 00:19:50,680
przebiega w systemie relacyjnym, że
Pozwala mi to bezpiecznie dokonać aktualizacji

461
00:19:50,680 --> 00:19:53,760
do wielu jednostek w bazie danych.

462
00:19:53,760 --> 00:19:58,320
A wystąpią te aktualizacje
wszystkie na raz albo w ogóle nie.

463
00:19:58,320 --> 00:20:00,500
I to się nazywa transakcje ACID.

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

465
00:20:01,000 --> 00:20:06,570
>> ACID daje nam niepodzielność, spójność,
izolacja i trwałość.

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

467
00:20:07,070 --> 00:20:13,550
Oznacza to, że atomowe, transakcji, wszystkie
moje aktualizacje albo zdarzy, albo nie.

468
00:20:13,550 --> 00:20:16,570
Spójność oznacza, że
Baza danych będzie zawsze

469
00:20:16,570 --> 00:20:19,780
być doprowadzone do konsekwentnego
Stan po aktualizacji.

470
00:20:19,780 --> 00:20:23,900
Nigdy nie opuszczają bazy danych w
zły stan po zastosowaniu aktualizacji.

471
00:20:23,900 --> 00:20:24,400
OK?

472
00:20:24,400 --> 00:20:26,720
>> Tak więc jest to trochę inaczej
niż spójności WPR.

473
00:20:26,720 --> 00:20:29,760
Spójności WPR oznacza wszystkie moje
Klienci zawsze mogą zobaczyć dane.

474
00:20:29,760 --> 00:20:34,450
ACID konsystencji oznacza, że ​​po
transakcja zrobił, dane jest dobre.

475
00:20:34,450 --> 00:20:35,709
Moje relacje są dobre.

476
00:20:35,709 --> 00:20:38,750
I nie zamierzam usunąć wiersz nadrzędny
i pozostawić kilka dzieci osieroconych

477
00:20:38,750 --> 00:20:40,970
w innej tabeli.

478
00:20:40,970 --> 00:20:44,320
To nie może się zdarzyć, jeśli jestem konsekwentny
w transakcji kwasu.

479
00:20:44,320 --> 00:20:49,120
>> Izolacja oznacza, że ​​transakcje
zawsze będzie występować jeden po drugim.

480
00:20:49,120 --> 00:20:51,920
Wynik końcowy danych
będzie taki sam stan

481
00:20:51,920 --> 00:20:54,770
jakby tych transakcji
które zostały wydane jednocześnie

482
00:20:54,770 --> 00:20:57,340
były wykonywane seryjnie.

483
00:20:57,340 --> 00:21:00,030
Więc to jest współbieżności
Kontrola w bazie danych.

484
00:21:00,030 --> 00:21:04,130
Więc w zasadzie, nie mogę zwiększamy
sama wartość dwukrotnie z dwoma operacjami.

485
00:21:04,130 --> 00:21:08,580
>> Ale jeśli powiem, dodać 1 do tej wartości,
i dwie transakcje są w

486
00:21:08,580 --> 00:21:10,665
i staram się robić to, jeden jest
będzie się tam pierwszy

487
00:21:10,665 --> 00:21:12,540
a drugi na
będzie się tam po.

488
00:21:12,540 --> 00:21:15,210
Więc w końcu dodałem dwa.

489
00:21:15,210 --> 00:21:16,170
Widzisz, co mam na myśli?

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
>> Trwałość jest całkiem proste.

493
00:21:21,250 --> 00:21:23,460
Gdy transakcja
uznaje się, że to

494
00:21:23,460 --> 00:21:26,100
tam będzie nawet
jeśli system zawiesza się.

495
00:21:26,100 --> 00:21:29,230
Gdy ten system odzyskuje, że
transakcji, które zostało popełnione

496
00:21:29,230 --> 00:21:30,480
faktycznie się tam być.

497
00:21:30,480 --> 00:21:33,130
Więc to gwarancje
transakcji ACID.

498
00:21:33,130 --> 00:21:35,470
To są całkiem ładne gwarancji
mieć na bazie

499
00:21:35,470 --> 00:21:36,870
ale są w tym kosztów.

500
00:21:36,870 --> 00:21:37,640
Dobrze?

501
00:21:37,640 --> 00:21:40,520
>> Ponieważ problem
z ramy jest

502
00:21:40,520 --> 00:21:44,540
Jeśli partycja jest w danej
zestaw, muszę podjąć decyzję.

503
00:21:44,540 --> 00:21:48,000
Będę musiał pozwolić
aktualizacje na jedną lub drugą stronę.

504
00:21:48,000 --> 00:21:50,310
A jeśli tak się stanie,
to ja już nie będzie mi

505
00:21:50,310 --> 00:21:52,630
aby móc utrzymać
te cechy.

506
00:21:52,630 --> 00:21:53,960
Oni nie będą zgodne.

507
00:21:53,960 --> 00:21:55,841
Nie będą one izolowane.

508
00:21:55,841 --> 00:21:58,090
To jest, gdy się zepsuje
dla relacyjnych baz danych.

509
00:21:58,090 --> 00:22:01,360
To jest powód, relacyjna
Bazy danych skalować w pionie.

510
00:22:01,360 --> 00:22:05,530
>> Z drugiej strony, mają
co nazywa technologii BASE.

511
00:22:05,530 --> 00:22:07,291
I to są twoje NoSQL Bazy danych.

512
00:22:07,291 --> 00:22:07,790
W porządku.

513
00:22:07,790 --> 00:22:10,180
Więc mamy CP, bazy danych AP.

514
00:22:10,180 --> 00:22:14,720
I to jest to co nazywasz zasadzie
dostępne, miękkie państwo, w końcu

515
00:22:14,720 --> 00:22:15,740
zgodny.

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

517
00:22:16,420 --> 00:22:19,690
>> Zasadniczo dostępne, ponieważ
Partycja są tolerancyjni.

518
00:22:19,690 --> 00:22:21,470
Zawsze będą
tam, nawet jeśli nie jest

519
00:22:21,470 --> 00:22:23,053
partycja sieci między węzłami.

520
00:22:23,053 --> 00:22:25,900
Jeśli mogę mówić do węzła, jestem
będzie w stanie odczytać dane.

521
00:22:25,900 --> 00:22:26,460
OK?

522
00:22:26,460 --> 00:22:30,810
Nie zawsze może być w stanie napisać
Dane jeśli jestem spójna platforma.

523
00:22:30,810 --> 00:22:32,130
Ale będę w stanie odczytać dane.

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

525
00:22:34,960 --> 00:22:38,010
>> Stan miękkie wskazuje
że kiedy czytam, że dane,

526
00:22:38,010 --> 00:22:40,790
to może być takie samo, jak inne węzły.

527
00:22:40,790 --> 00:22:43,390
Jeżeli prawo zostało wydane na węźle
gdzieś indziej w klastrze

528
00:22:43,390 --> 00:22:46,650
i nie replikowane w poprzek
jeszcze klaster, gdy czytam, że dane,

529
00:22:46,650 --> 00:22:48,680
że państwo może nie być zgodne.

530
00:22:48,680 --> 00:22:51,650
Niemniej jednak, będzie to
ostatecznie spójne,

531
00:22:51,650 --> 00:22:53,870
co oznacza, że ​​kiedy zapis
jest wykonany w systemie

532
00:22:53,870 --> 00:22:56,480
to replikacji poprzek węzłów.

533
00:22:56,480 --> 00:22:59,095
I w końcu, że państwo
zostaną doprowadzone do porządku,

534
00:22:59,095 --> 00:23:00,890
i będzie to zgodne państwa.

535
00:23:00,890 --> 00:23:05,000
>> Teraz, twierdzenie WPR naprawdę
odgrywa tylko w jednym stanie.

536
00:23:05,000 --> 00:23:08,700
Ten warunek jest, kiedy to nastąpi.

537
00:23:08,700 --> 00:23:13,710
Bo gdy to działa w
tryb normalny, nie ma partycji,

538
00:23:13,710 --> 00:23:16,370
wszystko jest spójne i dostępne.

539
00:23:16,370 --> 00:23:19,990
Tylko martwić o WPR
gdy mamy tę strefę.

540
00:23:19,990 --> 00:23:21,260
To są rzadkie.

541
00:23:21,260 --> 00:23:25,360
Ale w jaki sposób system reaguje, gdy te
występują dyktować, jaki rodzaj systemu

542
00:23:25,360 --> 00:23:26,750
mamy do czynienia.

543
00:23:26,750 --> 00:23:31,110
>> Warto więc spojrzeć na to, co
wygląda na to, że w przypadku systemów AP.

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

545
00:23:32,621 --> 00:23:34,830
Systemy AP są w dwóch smakach.

546
00:23:34,830 --> 00:23:38,514
Pochodzą one w smaku, który jest
Mistrz Mistrz, 100%, zawsze dostępna.

547
00:23:38,514 --> 00:23:40,430
I pochodzą one w
inny smak, który mówi,

548
00:23:40,430 --> 00:23:43,330
wiesz co, będę się martwić
o tym partycjonowania rzeczy

549
00:23:43,330 --> 00:23:44,724
gdy rzeczywisty podział występuje.

550
00:23:44,724 --> 00:23:47,890
W przeciwnym razie nie będzie głównym
węzły, który zajmie prawa.

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

552
00:23:48,500 --> 00:23:50,040
>> Jeśli więc coś takiego jak Cassandra.

553
00:23:50,040 --> 00:23:54,440
Cassandra będzie mistrzem
master, pozwala mi napisać do dowolnego węzła.

554
00:23:54,440 --> 00:23:55,540
Więc co się dzieje?

555
00:23:55,540 --> 00:23:58,270
Więc mam obiektu w
baza danych, która istnieje na dwóch węzłach.

556
00:23:58,270 --> 00:24:01,705
Nazwijmy ten obiekt S.
Mamy więc stan dla S.

557
00:24:01,705 --> 00:24:04,312
Mamy kilka operacji
na S, które są w toku.

558
00:24:04,312 --> 00:24:06,270
Cassandra pozwala mi
Napisać do wielu węzłów.

559
00:24:06,270 --> 00:24:08,550
Więc powiedzmy, że mogę dostać
Napisać do s do dwóch węzłów.

560
00:24:08,550 --> 00:24:12,274
No, co kończy się dzieje
nazywamy to wydarzenie partycjonowania.

561
00:24:12,274 --> 00:24:14,190
Nie może być
fizycznego podziału sieci.

562
00:24:14,190 --> 00:24:15,950
Jednak ze względu na projekt
układu, to jest

563
00:24:15,950 --> 00:24:18,449
faktycznie partycjonowanie zaraz
jak mogę dostać zapisu na dwóch węzłach.

564
00:24:18,449 --> 00:24:20,830
To nie zmusza mnie do
Napisać wszystko przez jednego węzła.

565
00:24:20,830 --> 00:24:22,340
Piszę na dwóch węzłach.

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

567
00:24:23,330 --> 00:24:25,740
>> Więc teraz mam dwa stany.

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

569
00:24:26,360 --> 00:24:28,110
Co się stanie
to prędzej czy później,

570
00:24:28,110 --> 00:24:29,960
nie będzie wydarzeniem replikacji.

571
00:24:29,960 --> 00:24:33,300
Nie będzie to, co
nazywany odzyskiwania partycji, które

572
00:24:33,300 --> 00:24:35,200
gdzie te dwa
stany wrócić razem

573
00:24:35,200 --> 00:24:37,310
i nie będzie algorytm
które pracuje w bazie danych,

574
00:24:37,310 --> 00:24:38,540
zdecyduje, co zrobić.

575
00:24:38,540 --> 00:24:39,110
OK?

576
00:24:39,110 --> 00:24:43,057
Domyślnie Ostatnia zmiana
wygrywa w większości systemów AP.

577
00:24:43,057 --> 00:24:44,890
Więc jest zwykle
domyślny algorytm, co

578
00:24:44,890 --> 00:24:47,400
nazywają wywołania zwrotnego
Funkcja, coś,

579
00:24:47,400 --> 00:24:51,000
zostanie wywołana, gdy warunek ten
wykryciu wykonać pewną logikę

580
00:24:51,000 --> 00:24:52,900
w celu rozwiązania tego konfliktu.

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

582
00:24:53,850 --> 00:24:58,770
Domyślnym zwrotna i domyślne
rozpoznawania nazw w większości baz danych AP

583
00:24:58,770 --> 00:25:01,130
jest, wiecie co, datownik wygrywa.

584
00:25:01,130 --> 00:25:02,380
To była ostatnia aktualizacja.

585
00:25:02,380 --> 00:25:04,320
Mam zamiar umieścić tę aktualizację tam.

586
00:25:04,320 --> 00:25:08,440
Może zrzucić ten zapis, że
rzucił się w dzienniku odzysku

587
00:25:08,440 --> 00:25:11,670
tak, że użytkownik może wrócić później
i powiedzieć, hej, nie było kolizji.

588
00:25:11,670 --> 00:25:12,320
Co się stało?

589
00:25:12,320 --> 00:25:16,370
I rzeczywiście można zrzucić rejestr
wszystkie kolizje i cofanie

590
00:25:16,370 --> 00:25:17,550
i zobaczyć, co się dzieje.

591
00:25:17,550 --> 00:25:21,580
>> Teraz, jako użytkownik, można również
obejmują logikę do tego zwrotnego.

592
00:25:21,580 --> 00:25:24,290
Więc można zmienić
zwrotna operacji.

593
00:25:24,290 --> 00:25:26,730
Można powiedzieć, hej, chcę
naprawiać te dane.

594
00:25:26,730 --> 00:25:28,880
I chcę, aby spróbować
połączyć te dwa rekordy.

595
00:25:28,880 --> 00:25:30,050
Ale to zależy od Ciebie.

596
00:25:30,050 --> 00:25:32,880
Baza danych nie wiem jak
zrobić domyślnie. Większość czasu,

597
00:25:32,880 --> 00:25:34,850
jedyną rzeczą, baza danych
wie, jak zrobić, to powiedzieć,

598
00:25:34,850 --> 00:25:36,100
ten był ostatni rekord.

599
00:25:36,100 --> 00:25:39,183
To ten, który wygra,
i to jest wartość Zamierzam umieścić.

600
00:25:39,183 --> 00:25:41,490
Po tym odzyskiwania partycji
i replikacja zachodzi,

601
00:25:41,490 --> 00:25:43,930
mamy państwo, które
Obecnie S premier, który jest

602
00:25:43,930 --> 00:25:46,890
stan scalenie wszystkich tych obiektów.

603
00:25:46,890 --> 00:25:49,700
Więc ma to systemy AP.

604
00:25:49,700 --> 00:25:51,615
Systemy CP nie trzeba
się o to martwić.

605
00:25:51,615 --> 00:25:54,490
Bo jak tylko partycja jest
do gry, po prostu przerwać przyjmowanie

606
00:25:54,490 --> 00:25:55,530
pisze.

607
00:25:55,530 --> 00:25:56,180
OK?

608
00:25:56,180 --> 00:25:58,670
Więc to jest bardzo łatwe do
czynienia z konsekwentni

609
00:25:58,670 --> 00:26:01,330
jeśli nie akceptują żadnych nowości.

610
00:26:01,330 --> 00:26:04,620
To z systemów CP zrobić.

611
00:26:04,620 --> 00:26:05,120
W porządku.

612
00:26:05,120 --> 00:26:07,590
>> Więc pomówmy trochę
Trochę o wzorcach dostępu.

613
00:26:07,590 --> 00:26:11,580
Kiedy mówimy o NoSQL, to
wszystko o wzór dostępu.

614
00:26:11,580 --> 00:26:13,550
Teraz, SQL jest ad hoc, zapytań.

615
00:26:13,550 --> 00:26:14,481
Jest to relacyjna sklepu.

616
00:26:14,481 --> 00:26:16,480
Nie musimy się martwić
o strukturze dostępu.

617
00:26:16,480 --> 00:26:17,688
Piszę bardzo złożone zapytania.

618
00:26:17,688 --> 00:26:19,250
To idzie i pobiera dane.

619
00:26:19,250 --> 00:26:21,210
To właśnie to wygląda
jak, normalizacja.

620
00:26:21,210 --> 00:26:24,890
>> Zatem w tej konkretnej struktury
szukamy w katalogu produktów.

621
00:26:24,890 --> 00:26:26,640
Mam różne rodzaje produktów.

622
00:26:26,640 --> 00:26:27,217
Mam książki.

623
00:26:27,217 --> 00:26:27,800
Mam albumów.

624
00:26:27,800 --> 00:26:30,090
Mam filmów.

625
00:26:30,090 --> 00:26:33,370
Związek między produktami
i jeden z tych książek, albumów,

626
00:26:33,370 --> 00:26:34,860
i filmy tabele jest 1: 1.

627
00:26:34,860 --> 00:26:35,800
W porządku?

628
00:26:35,800 --> 00:26:38,860
Mam identyfikator produktu,
i odpowiadający ID

629
00:26:38,860 --> 00:26:41,080
do książki, albumu lub filmu.

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

631
00:26:41,580 --> 00:26:44,350
To jest 1: 1 związek
poprzek tych tabelach.

632
00:26:44,350 --> 00:26:46,970
>> Teraz books-- wszyscy
mają właściwości jest korzeń.

633
00:26:46,970 --> 00:26:47,550
Nie ma problemu.

634
00:26:47,550 --> 00:26:48,230
To wspaniale.

635
00:26:48,230 --> 00:26:52,130
Jeden-do-jeden związek, mam wszystko
dane muszę opisać tę książkę.

636
00:26:52,130 --> 00:26:54,770
Albums-- albumy mają utworów.

637
00:26:54,770 --> 00:26:56,470
To jest to, co nazywamy jeden do wielu.

638
00:26:56,470 --> 00:26:58,905
Każdy album może mieć wiele utworów.

639
00:26:58,905 --> 00:27:00,780
Więc dla każdego toru na
album, mógłbym

640
00:27:00,780 --> 00:27:02,570
kolejny rekord w tabeli podrzędnej.

641
00:27:02,570 --> 00:27:04,680
Więc utworzyć jeden rekord
w moim stole albumy.

642
00:27:04,680 --> 00:27:06,700
Tworzyć wiele rekordów
w tabeli utworów.

643
00:27:06,700 --> 00:27:08,850
Jeden-do-wielu.

644
00:27:08,850 --> 00:27:11,220
>> Ten związek jest co
nazywamy wiele-do-wielu.

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

646
00:27:11,750 --> 00:27:17,000
Widać, że aktorzy mogą być
w wielu filmach, wiele filmów.

647
00:27:17,000 --> 00:27:21,450
Więc co możemy zrobić, to stawiamy to odwzorowanie
Stół między tymi, które po prostu

648
00:27:21,450 --> 00:27:24,040
odwzorowuje ID aktora do ID wideo.

649
00:27:24,040 --> 00:27:28,464
Teraz mogę utworzyć kwerendę sprzężeń
filmy przez aktora wideo do aktorów,

650
00:27:28,464 --> 00:27:31,130
i to daje mi piękny listę
wszystkie filmy i wszyscy aktorzy

651
00:27:31,130 --> 00:27:32,420
którzy byli w tym filmie.

652
00:27:32,420 --> 00:27:33,290
>> OK.

653
00:27:33,290 --> 00:27:33,880
Więc zaczynamy.

654
00:27:33,880 --> 00:27:38,040
Jeden-na-jeden jest na najwyższym poziomie
związek; jeden-do-wielu,

655
00:27:38,040 --> 00:27:40,240
albumy na torach; wiele-do-wielu.

656
00:27:40,240 --> 00:27:44,990
To są na najwyższym poziomie trzech
relacje w żadnej bazie danych.

657
00:27:44,990 --> 00:27:48,050
Jeśli wiesz, jak te,
relacje ze sobą współpracować,

658
00:27:48,050 --> 00:27:51,490
wtedy dużo wiedzieć
o bazie danych już.

659
00:27:51,490 --> 00:27:55,660
Więc NoSQL działa trochę inaczej.

660
00:27:55,660 --> 00:27:58,930
Zastanówmy się przez chwilę, co go
Wygląda na to, aby udać się na wszystkie moje produkty.

661
00:27:58,930 --> 00:28:01,096
>> W relacyjnej sklepie,
chcą, aby wszystkie moje produkty

662
00:28:01,096 --> 00:28:02,970
w sprawie wykazu wszystkich moich produktów.

663
00:28:02,970 --> 00:28:04,910
To bardzo dużo zapytań.

664
00:28:04,910 --> 00:28:07,030
Mam zapytanie do wszystkich moich książek.

665
00:28:07,030 --> 00:28:08,470
Mam zapytanie z moich albumów.

666
00:28:08,470 --> 00:28:09,970
I mam zapytanie do wszystkich moich filmów.

667
00:28:09,970 --> 00:28:11,719
I mam to ująć
razem z listy

668
00:28:11,719 --> 00:28:15,250
i podawać go z powrotem do
Aplikacja, która się o nią poproszą.

669
00:28:15,250 --> 00:28:18,000
>> Aby uzyskać moje książki, mogę dołączyć
Produkty i książek.

670
00:28:18,000 --> 00:28:21,680
Aby moje albumy, mam dołączyć
Produkty, Albumy, i szlaki.

671
00:28:21,680 --> 00:28:25,330
I aby moje filmy, mam
dołączyć Produkty do Filmy,

672
00:28:25,330 --> 00:28:28,890
Filmy przyłączając się przez aktorów,
i wprowadzają w Actors.

673
00:28:28,890 --> 00:28:31,020
Więc to trzy pytania.

674
00:28:31,020 --> 00:28:34,560
Bardzo złożone zapytania do
montujemy jeden zestaw wyników.

675
00:28:34,560 --> 00:28:36,540
>> To mniej niż optymalne.

676
00:28:36,540 --> 00:28:39,200
To dlatego, gdy mówimy
o strukturze danych, który jest

677
00:28:39,200 --> 00:28:42,900
zbudowany być agnostykiem do dostępu
pattern-- dobrze to świetnie.

678
00:28:42,900 --> 00:28:45,730
I można zobaczyć, to jest naprawdę
miłe, jak my zorganizowane dane.

679
00:28:45,730 --> 00:28:46,550
I wiesz co?

680
00:28:46,550 --> 00:28:49,750
Mam tylko jeden rekord dla aktora.

681
00:28:49,750 --> 00:28:50,440
>> To jest fajne.

682
00:28:50,440 --> 00:28:53,750
Mam deduplikacji wszystkich moich aktorów,
i utrzymuje moje skojarzenia

683
00:28:53,750 --> 00:28:55,200
w tej tabeli mapowania.

684
00:28:55,200 --> 00:29:00,620
Jednak uzyskanie danych
się, staje się drogie.

685
00:29:00,620 --> 00:29:04,500
Wysyłam CPU całego systemu
Przystępując do tych struktur danych wraz

686
00:29:04,500 --> 00:29:05,950
aby być w stanie pociągnąć że dane z powrotem.

687
00:29:05,950 --> 00:29:07,310
>> Więc jak mam się poruszać, że?

688
00:29:07,310 --> 00:29:11,200
W NoSQL to o
agregacji, a nie normalizacja.

689
00:29:11,200 --> 00:29:13,534
Dlatego chcemy, aby powiedzieć, że chcą
wsparcie dla dostępu.

690
00:29:13,534 --> 00:29:15,283
Jeśli dla dostępu do
do zastosowań

691
00:29:15,283 --> 00:29:16,770
Muszę dostać wszystkie moje produkty.

692
00:29:16,770 --> 00:29:19,027
Postawmy wszystkie produkty w jednej tabeli.

693
00:29:19,027 --> 00:29:22,110
Jeśli mogę umieścić wszystkie produkty w jednej tabeli,
Mogę tylko wybrać wszystkie produkty

694
00:29:22,110 --> 00:29:23,850
z tej tabeli i mam to wszystko.

695
00:29:23,850 --> 00:29:25,240
Cóż, jak to zrobić?

696
00:29:25,240 --> 00:29:28,124
Cóż w NoSQL nie ma
Struktura w tabeli.

697
00:29:28,124 --> 00:29:30,540
Porozmawiamy trochę o
jak to działa w Dynamo DB.

698
00:29:30,540 --> 00:29:33,570
Ale nie masz to samo
atrybuty i te same właściwości

699
00:29:33,570 --> 00:29:37,751
w każdym wierszu, w każdej
poz, jak ty w tabeli SQL.

700
00:29:37,751 --> 00:29:39,750
A co to pozwala mi
do zrobienia jest wiele rzeczy,

701
00:29:39,750 --> 00:29:41,124
i dał mi dużą swobodę.

702
00:29:41,124 --> 00:29:45,360
W tym konkretnym przypadku,
mają moje dokumenty produktów.

703
00:29:45,360 --> 00:29:49,090
I w tym konkretnym
Przykładem wszystko

704
00:29:49,090 --> 00:29:51,930
jest dokumentem w tabeli Produkty.

705
00:29:51,930 --> 00:29:56,510
A produkt na książki może
mieć identyfikator typu, który określa książkę.

706
00:29:56,510 --> 00:29:59,180
A aplikacja
by przełączyć na ten ID.

707
00:29:59,180 --> 00:30:02,570
>> W warstwie aplikacji, zamierzam
powiedzieć, och, jaki typ rekordu jest?

708
00:30:02,570 --> 00:30:04,100
Och, to rekord książka.

709
00:30:04,100 --> 00:30:05,990
Zapisy Zarezerwuj mają te właściwości.

710
00:30:05,990 --> 00:30:08,100
Pozwól mi utworzyć obiekt książki.

711
00:30:08,100 --> 00:30:11,289
Więc mam zamiar wypełnić
Książka obiektu z tej pozycji.

712
00:30:11,289 --> 00:30:13,080
Kolejnym punktem przychodzi i
mówi, co to za przedmiot?

713
00:30:13,080 --> 00:30:14,560
Cóż ta pozycja będzie album.

714
00:30:14,560 --> 00:30:17,340
Och, mam zupełnie inna
Przetwarzanie, że rutynowe,

715
00:30:17,340 --> 00:30:18,487
dlatego, że jest to album.

716
00:30:18,487 --> 00:30:19,320
Widzisz, co mam na myśli?

717
00:30:19,320 --> 00:30:21,950
>> Tak więc stosowanie tier-- I
po prostu wybierz te wszystkie rekordy.

718
00:30:21,950 --> 00:30:23,200
Wszyscy zaczynają najbliższych.

719
00:30:23,200 --> 00:30:24,680
Mogą one być wszystkie typy.

720
00:30:24,680 --> 00:30:27,590
I to jest logika aplikacji
który przełącza poprzek tych typów

721
00:30:27,590 --> 00:30:29,530
i decyduje, jak je przetwarzać.

722
00:30:29,530 --> 00:30:33,640
>> Ponownie więc mamy optymalizację
Schemat dla wzorca dostępu.

723
00:30:33,640 --> 00:30:36,390
Robimy to poprzez
zawaleniem tych tabel.

724
00:30:36,390 --> 00:30:39,670
Jesteśmy w zasadzie biorąc
te znormalizowane struktury,

725
00:30:39,670 --> 00:30:42,000
i budujemy
struktury hierarchiczne.

726
00:30:42,000 --> 00:30:45,130
Wewnątrz każdego z tych zapisów
Idę zobaczyć właściwości tablicy.

727
00:30:45,130 --> 00:30:49,400
>> Wewnątrz tego dokumentu Albums
Widzę tablice utworów.

728
00:30:49,400 --> 00:30:53,900
Utwory te become-- teraz jest
w zasadzie ta tabela dziecko, które

729
00:30:53,900 --> 00:30:56,520
istnieje tutaj, w tej strukturze.

730
00:30:56,520 --> 00:30:57,975
Więc można to zrobić w DynamoDB.

731
00:30:57,975 --> 00:30:59,810
Możesz to zrobić w MongoDB.

732
00:30:59,810 --> 00:31:01,437
Możesz to zrobić w dowolnej bazy danych NoSQL.

733
00:31:01,437 --> 00:31:03,520
Tworzenie tego typu
hierarchiczne struktury danych

734
00:31:03,520 --> 00:31:07,120
które pozwalają pobierać dane
bardzo szybko, bo teraz

735
00:31:07,120 --> 00:31:08,537
nie muszą być zgodne.

736
00:31:08,537 --> 00:31:11,620
Kiedy wstawić wiersz do torze
tabeli lub wiersz do tabeli Albumy

737
00:31:11,620 --> 00:31:13,110
Muszę odpowiadać tym schemacie.

738
00:31:13,110 --> 00:31:18,060
Muszę mieć atrybut lub tym
Obiekt, który definiuje na tym stole.

739
00:31:18,060 --> 00:31:20,480
Każdy z nich,
kiedy wstawić ten wiersz.

740
00:31:20,480 --> 00:31:21,910
To nie jest przypadek, w NoSQL.

741
00:31:21,910 --> 00:31:24,440
>> Mogę mieć zupełnie inny
właściwości w każdym dokumencie

742
00:31:24,440 --> 00:31:26,100
że wstawić do kolekcji.

743
00:31:26,100 --> 00:31:30,480
Tak bardzo potężny mechanizm.

744
00:31:30,480 --> 00:31:32,852
I to jest naprawdę, jak ci
zoptymalizowanie systemu.

745
00:31:32,852 --> 00:31:35,310
Bo teraz tego zapytania, zamiast
łączącej wszystkie te tabele

746
00:31:35,310 --> 00:31:39,160
i realizacji pół tuzina zapytań
wycofać dane, czego potrzebuję,

747
00:31:39,160 --> 00:31:40,890
Jestem wykonanie jednego zapytania.

748
00:31:40,890 --> 00:31:43,010
A ja iteracji
całej wyników przedstawionych.

749
00:31:43,010 --> 00:31:46,512
to daje wyobrażenie
potęgi NoSQL.

750
00:31:46,512 --> 00:31:49,470
Mam zamiar trochę przejść bokiem tutaj
i porozmawiać trochę o tym.

751
00:31:49,470 --> 00:31:53,240
Jest to bardziej rodzaj z
obrotu lub technology--

752
00:31:53,240 --> 00:31:55,660
marketing technologii
rodzaj dyskusji.

753
00:31:55,660 --> 00:31:58,672
Ale ważne jest, aby zrozumieć,
bo jeśli spojrzymy na górze

754
00:31:58,672 --> 00:32:00,380
tutaj, na tym wykresie,
czego szukamy w

755
00:32:00,380 --> 00:32:04,030
jest to, co nazywamy
Technologia hiper krzywa.

756
00:32:04,030 --> 00:32:06,121
A oznacza to,
nowych rzeczy wchodzi w grę.

757
00:32:06,121 --> 00:32:07,120
Ludzie myślą, że to nic wielkiego.

758
00:32:07,120 --> 00:32:09,200
Mam rozwiązać wszystkie moje problemy.

759
00:32:09,200 --> 00:32:11,630
>> To może być koniec
wszystko, być wszystkim do wszystkiego.

760
00:32:11,630 --> 00:32:12,790
I zacząć go używać.

761
00:32:12,790 --> 00:32:14,720
A mówią, że tych rzeczy nie działa.

762
00:32:14,720 --> 00:32:17,600
To nie w porządku.

763
00:32:17,600 --> 00:32:19,105
Stare rzeczy było lepiej.

764
00:32:19,105 --> 00:32:21,230
I wrócić do robienia
rzeczy takie, jakie były.

765
00:32:21,230 --> 00:32:22,730
A potem w końcu
iść, wiesz co?

766
00:32:22,730 --> 00:32:24,040
Ten materiał nie jest tak źle.

767
00:32:24,040 --> 00:32:26,192
Oh, jak to działa.

768
00:32:26,192 --> 00:32:28,900
A kiedy oni dowiedzieć się, jak to
Prace, zaczynają coraz lepiej.

769
00:32:28,900 --> 00:32:32,050
>> A najśmieszniejsze o tym
Jest to rodzaj linii do jakiego

770
00:32:32,050 --> 00:32:34,300
nazywamy krzywą Przyjęcie technologii.

771
00:32:34,300 --> 00:32:36,910
Więc co się dzieje, to mamy
niektóre spust technologii sortowania.

772
00:32:36,910 --> 00:32:39,100
W przypadku baz
to ciśnienie danych.

773
00:32:39,100 --> 00:32:42,200
Rozmawialiśmy o wysokich punktów wodnych
ciśnienia danych w całym czasie.

774
00:32:42,200 --> 00:32:46,310
Kiedy to ciśnienie Dane uderza pewna
punkt, to wyzwalacz technologii.

775
00:32:46,310 --> 00:32:47,830
>> Robi się zbyt drogie.

776
00:32:47,830 --> 00:32:49,790
To trwa zbyt długo, aby przetwarzać dane.

777
00:32:49,790 --> 00:32:50,890
Musimy coś lepszego.

778
00:32:50,890 --> 00:32:52,890
Otrzymasz innowatorów
tam biegają,

779
00:32:52,890 --> 00:32:55,050
próbuje dowiedzieć się, co to jest rozwiązanie.

780
00:32:55,050 --> 00:32:56,050
Co to za pomysł?

781
00:32:56,050 --> 00:32:58,170
>> Co znajduje się obok najlepszych
sposób, aby zrobić to?

782
00:32:58,170 --> 00:32:59,530
I coś wymyślić.

783
00:32:59,530 --> 00:33:03,140
A ludzie z prawdziwego bólu,
człowiek na krawędzi krwawienia,

784
00:33:03,140 --> 00:33:06,390
oni skakać nad nim,
ponieważ potrzebują odpowiedzi.

785
00:33:06,390 --> 00:33:09,690
Teraz to, co nieuchronnie happens-- i
to się teraz dzieje w NoSQL.

786
00:33:09,690 --> 00:33:11,090
Widzę go cały czas.

787
00:33:11,090 --> 00:33:13,610
>> Co nieuchronnie dzieje
ludzie rozpocząć korzystanie z nowego narzędzia

788
00:33:13,610 --> 00:33:15,490
tak samo kiedyś stare narzędzie.

789
00:33:15,490 --> 00:33:17,854
I dowiedzieć się go
ma tak dobrze nie działa.

790
00:33:17,854 --> 00:33:20,020
Nie mogę sobie przypomnieć, kim jestem
rozmowy z wcześniejszym dzisiaj.

791
00:33:20,020 --> 00:33:22,080
Ale jak to jest, gdy
młot pneumatyczny został wynaleziony,

792
00:33:22,080 --> 00:33:24,621
ludzie nie kołysz się
ich głowy, aby rozbić beton.

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

794
00:33:27,360 --> 00:33:30,610
>> Ale to, co jest
dzieje z NoSQL dziś.

795
00:33:30,610 --> 00:33:33,900
Jeśli idziesz w większości sklepów,
starają się być sklepy NoSQL.

796
00:33:33,900 --> 00:33:36,510
Co robią jest
oni używają NoSQL,

797
00:33:36,510 --> 00:33:39,900
a oni załadowaniem
pełne schematu relacyjnego.

798
00:33:39,900 --> 00:33:41,630
Bo tak
ich projektowania baz danych.

799
00:33:41,630 --> 00:33:44,046
I zastanawiasz się, dlaczego
nie wykonując bardzo dobrze?

800
00:33:44,046 --> 00:33:45,230
Chłopiec, ta sprawa śmierdzi.

801
00:33:45,230 --> 00:33:49,900
Musiałem zachować wszystkie moje
dołącza in-- to jest jak, nie, nie.

802
00:33:49,900 --> 00:33:50,800
Utrzymanie łączy?

803
00:33:50,800 --> 00:33:52,430
Czemu łączenia danych?

804
00:33:52,430 --> 00:33:54,350
Nie dołączyć dane w NoSQL.

805
00:33:54,350 --> 00:33:55,850
Ty agregować go.

806
00:33:55,850 --> 00:34:00,690
>> Więc jeśli chcesz tego uniknąć, nauczyć
w jaki sposób narzędzie działa, zanim rzeczywiście

807
00:34:00,690 --> 00:34:02,010
zacząć go używać.

808
00:34:02,010 --> 00:34:04,860
Nie próbuj korzystać z nowych narzędzi, jakie
sam sposób wykorzystywane starych narzędzi.

809
00:34:04,860 --> 00:34:06,500
Będziesz mieć złe doświadczenia.

810
00:34:06,500 --> 00:34:08,848
I za każdym razem
że to, o co chodzi.

811
00:34:08,848 --> 00:34:11,389
Kiedy zaczynamy zbliża się tu,
to dlatego, że ludzie zorientowali się,

812
00:34:11,389 --> 00:34:13,449
jak korzystać z narzędzi.

813
00:34:13,449 --> 00:34:16,250
>> Zrobili to samo, gdy
relacyjne bazy danych zostały wymyślone,

814
00:34:16,250 --> 00:34:17,969
i zostali zastąpienie systemów plików.

815
00:34:17,969 --> 00:34:20,420
Starali się budować systemy plików
z relacyjnymi bazami danych

816
00:34:20,420 --> 00:34:22,159
ponieważ to, co ludzie zrozumieli.

817
00:34:22,159 --> 00:34:23,049
To nie działa.

818
00:34:23,049 --> 00:34:26,090
Więc zrozumienie najlepszych praktyk
technologii pracujesz z

819
00:34:26,090 --> 00:34:26,730
jest ogromna.

820
00:34:26,730 --> 00:34:29,870
Bardzo ważne.

821
00:34:29,870 --> 00:34:32,440
>> Tak więc mamy zamiar dostać się do DynamoDB.

822
00:34:32,440 --> 00:34:36,480
DynamoDB jest AWS
pełni zarządzane platformy NoSQL.

823
00:34:36,480 --> 00:34:37,719
Co jest w pełni zarządzane na myśli?

824
00:34:37,719 --> 00:34:40,010
Oznacza to, że nie trzeba
Naprawdę się o nic martwić.

825
00:34:40,010 --> 00:34:42,060
>> Możesz przyjść, powiedzieć
nam, potrzebuję tabelę.

826
00:34:42,060 --> 00:34:43,409
Musi to dużo możliwości.

827
00:34:43,409 --> 00:34:47,300
Naciskasz przycisk, a postanowienie to
cała infrastruktura za sceną.

828
00:34:47,300 --> 00:34:48,310
Teraz to jest ogromne.

829
00:34:48,310 --> 00:34:51,310
>> Bo kiedy mówisz
o skalowanie bazy danych,

830
00:34:51,310 --> 00:34:53,917
Klastry danych NoSQL w
Skala, bieganie petabajtów,

831
00:34:53,917 --> 00:34:55,750
działa miliony
transakcji na sekundę,

832
00:34:55,750 --> 00:34:58,180
te rzeczy nie są małe klastry.

833
00:34:58,180 --> 00:35:00,830
Mówimy tysiące przykładów.

834
00:35:00,830 --> 00:35:04,480
Zarządzanie tysiące przypadków,
nawet wirtualne instancje

835
00:35:04,480 --> 00:35:06,350
to prawdziwy wrzód na tyłku.

836
00:35:06,350 --> 00:35:09,110
Mam na myśli, myśleć o każdym razem
poprawki systemu operacyjnego wychodzi

837
00:35:09,110 --> 00:35:11,552
lub nowej wersji bazy danych.

838
00:35:11,552 --> 00:35:13,260
Co to znaczy
ci operacyjnie?

839
00:35:13,260 --> 00:35:16,330
Oznacza to, że masz 1200
serwery, które muszą być aktualizowane.

840
00:35:16,330 --> 00:35:18,960
Teraz nawet z automatyzacji,
że może zająć dużo czasu.

841
00:35:18,960 --> 00:35:21,480
To może spowodować wiele
bóle głowy operacyjne,

842
00:35:21,480 --> 00:35:23,090
bo mógłbym usług dół.

843
00:35:23,090 --> 00:35:26,070
>> Jak zaktualizować te bazy danych, I
może zrobić, niebieski, zielony wdrożeń

844
00:35:26,070 --> 00:35:29,420
gdzie wdrożenia i aktualizacji połowa mojego
węzły, a następnie uaktualnić drugą połowę.

845
00:35:29,420 --> 00:35:30,490
Weź te dół.

846
00:35:30,490 --> 00:35:33,410
Więc zarządzania infrastrukturą
Skala jest niezwykle bolesne.

847
00:35:33,410 --> 00:35:36,210
I ten ból AWS się z niego.

848
00:35:36,210 --> 00:35:39,210
I baz danych NoSQL możliwe
być niezwykle bolesne

849
00:35:39,210 --> 00:35:41,780
ze względu na sposób ich skalę.

850
00:35:41,780 --> 00:35:42,926
>> Skalowanie w poziomie.

851
00:35:42,926 --> 00:35:45,550
Jeśli chcesz uzyskać większy NoSQL
bazy danych, można kupić więcej węzłów.

852
00:35:45,550 --> 00:35:48,660
Każdy węzeł kupisz jest
kolejny ból głowy operacyjne.

853
00:35:48,660 --> 00:35:50,830
Więc niech ktoś inny zrobić to za Ciebie.

854
00:35:50,830 --> 00:35:52,000
AWS może to zrobić.

855
00:35:52,000 --> 00:35:54,587
>> Wspieramy wartości kluczowych dokumentów.

856
00:35:54,587 --> 00:35:56,670
Teraz nie byliśmy zbyt wiele
w drugiej tabeli.

857
00:35:56,670 --> 00:35:58,750
Istnieje wiele różnych
smaki NoSQL.

858
00:35:58,750 --> 00:36:02,670
Są wszelkiego rodzaju coraz
munged razem w tym punkcie.

859
00:36:02,670 --> 00:36:06,260
Możesz zajrzeć na DynamoDB i powiedzieć: tak,
oboje jesteśmy dokument i wartość klucza

860
00:36:06,260 --> 00:36:08,412
zapisać ten punkt.

861
00:36:08,412 --> 00:36:10,620
I można argumentować, funkcje
jednego nad drugim.

862
00:36:10,620 --> 00:36:13,950
Dla mnie dużo to jest naprawdę sześć
jednego pół tuzina innych.

863
00:36:13,950 --> 00:36:18,710
Każdy z tych technologii jest
grzywny technologii i grzywny rozwiązanie.

864
00:36:18,710 --> 00:36:23,390
Nie powiedziałbym, MongoDB jest lepsze lub
gorzej niż kanapie, następnie Cassandra,

865
00:36:23,390 --> 00:36:25,994
następnie Dynamo, lub odwrotnie.

866
00:36:25,994 --> 00:36:27,285
Mam na myśli, to są tylko opcje.

867
00:36:27,285 --> 00:36:29,850

868
00:36:29,850 --> 00:36:32,700
>> Jest szybki i to
spójne w każdej skali.

869
00:36:32,700 --> 00:36:36,210
Więc jest to jeden z największych
premie Ci z AWS.

870
00:36:36,210 --> 00:36:40,850
Z DynamoDB jest możliwość
aby uzyskać niską cyfrę

871
00:36:40,850 --> 00:36:44,040
ms opóźnienia w każdej skali.

872
00:36:44,040 --> 00:36:45,720
To było celem projektu systemu.

873
00:36:45,720 --> 00:36:49,130
I mamy klientów, że robią
miliony operacji na sekundę.

874
00:36:49,130 --> 00:36:52,670
>> Teraz będę przechodzić przez niektóre z tych,
przypadków użycia w tym miejscu kilka minut.

875
00:36:52,670 --> 00:36:55,660
Zintegrowany control-- dostępu
mamy to, co nazywamy

876
00:36:55,660 --> 00:36:57,920
Tożsamość Zarządzanie dostępem lub IAM.

877
00:36:57,920 --> 00:37:01,980
Przenika każdy system,
każda usługa, która AWS oferuje.

878
00:37:01,980 --> 00:37:03,630
DynamoDB nie jest wyjątkiem.

879
00:37:03,630 --> 00:37:06,020
Możesz kontrolować dostęp
do tabel DynamoDB.

880
00:37:06,020 --> 00:37:09,960
We wszystkich rachunków twój AWS przez
definiowania ról i uprawnień dostępu

881
00:37:09,960 --> 00:37:12,140
w infrastrukturze IAM.

882
00:37:12,140 --> 00:37:16,630
>> I to jest klucz i integralnym elementem w
co nazywamy zdarzeniami programowania.

883
00:37:16,630 --> 00:37:19,056
Teraz jest to nowy paradygmat.

884
00:37:19,056 --> 00:37:22,080
>> PUBLICZNOŚCI: Jak twoja stopa prawda
pozytywy porównaniu fałszywie ujemnych

885
00:37:22,080 --> 00:37:24,052
w systemie kontroli dostępu?

886
00:37:24,052 --> 00:37:26,260
RICK HOULIHAN: Prawdziwe pozytywy
w porównaniu do wyników fałszywie ujemnych?

887
00:37:26,260 --> 00:37:28,785
PUBLICZNOŚCI: Wracając co
powinien być powrót?

888
00:37:28,785 --> 00:37:33,720
W przeciwieństwie do raz na jakiś czas, to
nie wrócić, kiedy powinien potwierdzić?

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

890
00:37:36,260 --> 00:37:38,050
>> RICK HOULIHAN: nie mogłem powiedzieć.

891
00:37:38,050 --> 00:37:40,140
Jeśli nie ma żadnych uszkodzeń
w żaden sposób, że,

892
00:37:40,140 --> 00:37:42,726
Nie jestem osoba zapytać
że konkretne pytanie.

893
00:37:42,726 --> 00:37:43,850
Ale to jest dobre pytanie.

894
00:37:43,850 --> 00:37:45,905
Byłbym ciekaw,
że ja, rzeczywiście.

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

896
00:37:48,810 --> 00:37:51,320
>> I tak znowu, nowy paradygmat
jest programowanie sterowane zdarzeniami.

897
00:37:51,320 --> 00:37:55,160
To jest pomysł, że można
wdrażanie złożonych aplikacji, które

898
00:37:55,160 --> 00:37:59,720
może pracować bardzo, bardzo dużą skalę
bez jakiejkolwiek infrastruktury w ogóle.

899
00:37:59,720 --> 00:38:02,120
Bez stałego
infrastruktury w ogóle.

900
00:38:02,120 --> 00:38:04,720
I porozmawiamy trochę
o tym, co to znaczy, jak my

901
00:38:04,720 --> 00:38:06,550
dostać się na następne kilka wykresów.

902
00:38:06,550 --> 00:38:08,716
>> Pierwszą rzeczą, którą zrobimy
to będziemy rozmawiać o tabelach.

903
00:38:08,716 --> 00:38:10,857
Typy danych API dla Dynamo.

904
00:38:10,857 --> 00:38:13,190
I pierwszą rzeczą, będziesz
zauważyć, jeśli spojrzeć na to,

905
00:38:13,190 --> 00:38:17,930
jeśli jesteś zaznajomiony z dowolnej bazy danych,
bazy danych mają naprawdę dwa rodzaje interfejsów API

906
00:38:17,930 --> 00:38:18,430
Chciałbym to nazwać.

907
00:38:18,430 --> 00:38:21,570
Albo dwa zestawy API.

908
00:38:21,570 --> 00:38:23,840
Jednym z nich byłoby
API administracyjne.

909
00:38:23,840 --> 00:38:26,710
>> Rzeczy, które dbają o
Zadania w bazie danych.

910
00:38:26,710 --> 00:38:31,340
Konfiguracja silnika przechowywania,
tworzenie i dodawanie tabel.

911
00:38:31,340 --> 00:38:35,180
stworzenie bazy danych
katalogi i instancje.

912
00:38:35,180 --> 00:38:40,450
Te things-- w DynamoDB, ty
mają bardzo krótki, krótki list.

913
00:38:40,450 --> 00:38:43,120
>> Więc w innych bazach danych,
można zobaczyć dziesiątki

914
00:38:43,120 --> 00:38:45,680
z poleceń administracyjnych
Komendy, do konfigurowania

915
00:38:45,680 --> 00:38:47,290
te dodatkowe opcje.

916
00:38:47,290 --> 00:38:51,234
W DynamoDB nie trzeba tych, ponieważ
nie skonfigurować system, co robimy.

917
00:38:51,234 --> 00:38:54,150
Więc jedyne, co musisz zrobić, to
powiedz mi, co wielkość stołu muszę.

918
00:38:54,150 --> 00:38:55,660
Więc masz bardzo
ograniczony zestaw poleceń.

919
00:38:55,660 --> 00:38:58,618
>> Dostajesz Create Table Update, Tabela,
Usuń tabelę i opisać tabela.

920
00:38:58,618 --> 00:39:01,150
To są tylko rzeczy,
czego potrzebujesz do DynamoDB.

921
00:39:01,150 --> 00:39:03,294
Nie trzeba do przechowywania
Konfiguracja silnika.

922
00:39:03,294 --> 00:39:04,960
I nie trzeba się martwić o replikacji.

923
00:39:04,960 --> 00:39:06,490
I nie trzeba się martwić o sharding.

924
00:39:06,490 --> 00:39:07,800
>> I nie trzeba się martwić
o żadnej z tych rzeczy.

925
00:39:07,800 --> 00:39:08,740
Robimy to wszystko dla Ciebie.

926
00:39:08,740 --> 00:39:11,867
Więc to jest ogromna ilość napowietrznych
że po prostu unieść swój talerz.

927
00:39:11,867 --> 00:39:13,200
Następnie mamy operatorów CRUD.

928
00:39:13,200 --> 00:39:17,740
CRUD jest coś, co my
zadzwonić w bazie danych, która jest

929
00:39:17,740 --> 00:39:19,860
Create, Update, Delete operatorów.

930
00:39:19,860 --> 00:39:24,180
Są to twój wspólne
operacje na bazie danych.

931
00:39:24,180 --> 00:39:31,299
Rzeczy takie jak pozycja put się element, aktualizacji
elementy, usuwać elementy, kwerendy partii, skanowanie.

932
00:39:31,299 --> 00:39:32,840
Jeśli chcesz zeskanować całą tabelę.

933
00:39:32,840 --> 00:39:34,220
Wyciągnąć wszystko ze stołu.

934
00:39:34,220 --> 00:39:37,130
Jedną z miłych rzeczy DynamoDB
Umożliwia skanowanie jest równoległy.

935
00:39:37,130 --> 00:39:40,602
Więc rzeczywiście można dać mi znać, jak wiele
wątki chcesz uruchomić na tym skanie.

936
00:39:40,602 --> 00:39:41,810
I możemy uruchomić te wątki.

937
00:39:41,810 --> 00:39:43,985
Możemy kręcić, że skanowanie
w wielu wątków

938
00:39:43,985 --> 00:39:49,060
więc można skanować całą tabelę
miejsca bardzo, bardzo szybko, w DynamoDB.

939
00:39:49,060 --> 00:39:51,490
>> Drugi API mamy jest
co nazywamy naszym Strumienie API.

940
00:39:51,490 --> 00:39:52,940
Nie będziemy mówić za
dużo teraz o tym.

941
00:39:52,940 --> 00:39:55,189
Mam pewne treści później
w talii na ten temat.

942
00:39:55,189 --> 00:39:59,910
Ale Strumienie jest naprawdę running--
myśleć o tym, jak czas zamawiać

943
00:39:59,910 --> 00:40:01,274
i dziennik zmian partycji.

944
00:40:01,274 --> 00:40:03,940
Wszystko, co dzieje się na
Tabela pokazuje się na strumień.

945
00:40:03,940 --> 00:40:05,940
>> Każdy Napisać do stołu
pojawia się w strumieniu.

946
00:40:05,940 --> 00:40:08,370
Można przeczytać, że strumień, a
możesz robić rzeczy z nim.

947
00:40:08,370 --> 00:40:10,150
Porozmawiamy o tym, co
rodzaje rzeczy

948
00:40:10,150 --> 00:40:13,680
zrobić z rzeczy, takich jak replikacja,
indeksy średnich.

949
00:40:13,680 --> 00:40:17,620
Wszystkie rodzaje naprawdę fajne
rzeczy, które możesz zrobić z tym.

950
00:40:17,620 --> 00:40:19,150
>> Typy danych.

951
00:40:19,150 --> 00:40:23,320
W DynamoDB, wspieramy zarówno klucz
Dokument wartości i typy danych.

952
00:40:23,320 --> 00:40:26,350
Z lewej strony ekranu
tutaj mamy nasze podstawowe typy.

953
00:40:26,350 --> 00:40:27,230
Typy wartości klucza.

954
00:40:27,230 --> 00:40:30,040
Są to łańcuchy,
cyfry i pliki binarne.

955
00:40:30,040 --> 00:40:31,640
>> Więc tylko trzy podstawowe typy.

956
00:40:31,640 --> 00:40:33,700
A potem możesz mieć zestawy tych.

957
00:40:33,700 --> 00:40:37,650
Jedną z miłych rzeczy o NoSQL jest
można zawierać tablice jak właściwości.

958
00:40:37,650 --> 00:40:42,050
I z DynamoDB można zawierać tablice
podstawowych typów jak właściwości korzenia.

959
00:40:42,050 --> 00:40:43,885
>> A jeszcze typy dokumentów.

960
00:40:43,885 --> 00:40:45,510
Jak wielu ludzi zna JSON?

961
00:40:45,510 --> 00:40:47,130
Wy znane z JSON tak dużo?

962
00:40:47,130 --> 00:40:49,380
Jest to w zasadzie JavaScript,
Obiekt, Notation.

963
00:40:49,380 --> 00:40:52,510
Pozwala na zasadzie
określenie hierarchicznej struktury.

964
00:40:52,510 --> 00:40:58,107
>> Możesz zapisać dokument JSON na
DynamoDB za pomocą wspólnych elementów

965
00:40:58,107 --> 00:41:00,940
lub cegiełki, które są dostępne
w większości języków programowania.

966
00:41:00,940 --> 00:41:03,602
Więc jeśli masz Javy, jesteś
patrząc na mapy i list.

967
00:41:03,602 --> 00:41:05,060
Mogę tworzyć obiekty, które obszarze mapy.

968
00:41:05,060 --> 00:41:08,030
Mapa jako kluczowych wartości
przechowywane jako właściwości.

969
00:41:08,030 --> 00:41:10,890
A może to mieć listy
Wartości w tych właściwości.

970
00:41:10,890 --> 00:41:13,490
Możesz zapisać ten kompleks
hierarchiczna struktura

971
00:41:13,490 --> 00:41:16,320
jako jednego atrybutu
z pozycji DynamoDB.

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

973
00:41:19,010 --> 00:41:24,460
>> Więc tabel w DynamoDB, jak większość
Baz danych NoSQL, tabele mają elementy.

974
00:41:24,460 --> 00:41:26,469
W MongoDB byś
zadzwoń do tych dokumentów.

975
00:41:26,469 --> 00:41:27,760
I byłoby podstawą kanapa.

976
00:41:27,760 --> 00:41:28,900
Ponadto baza danych dokumentów.

977
00:41:28,900 --> 00:41:29,941
Dzwonisz do tych dokumentów.

978
00:41:29,941 --> 00:41:32,930
Dokumenty lub przedmioty posiadają atrybuty.

979
00:41:32,930 --> 00:41:35,850
Atrybuty mogą istnieć lub
nie istnieje na tej pozycji.

980
00:41:35,850 --> 00:41:38,520
W DynamoDB, nie
jeden obowiązkowy atrybut.

981
00:41:38,520 --> 00:41:43,880
Podobnie jak w relacyjnej bazie danych,
masz klucza podstawowego w tabeli.

982
00:41:43,880 --> 00:41:46,010
>> DynamoDB ma co nazywamy klawisza skrótu.

983
00:41:46,010 --> 00:41:48,280
Klawisz skrótu musi być unikalny.

984
00:41:48,280 --> 00:41:52,580
Kiedy więc zdefiniować tabeli mieszania,
w zasadzie to, co mówię

985
00:41:52,580 --> 00:41:54,110
jest każdy przedmiot będzie miał klawisz krzyżyka.

986
00:41:54,110 --> 00:41:58,520
I każdy klawisz krzyżyka musi być unikalny.

987
00:41:58,520 --> 00:42:01,200
>> Każdy element jest zdefiniowany
przez tego unikalnego klucza hash.

988
00:42:01,200 --> 00:42:02,940
I nie może być tylko jeden.

989
00:42:02,940 --> 00:42:05,820
To jest OK, ale często
czego ludzie potrzebują

990
00:42:05,820 --> 00:42:08,170
jest to, że chcą to hash
Kluczem do zrobić trochę więcej

991
00:42:08,170 --> 00:42:11,010
niż tylko być unikalny identyfikator.

992
00:42:11,010 --> 00:42:15,240
Często chcemy użyć tego klawisza skrótu
jak najwyższym poziomie agregacji wiadra.

993
00:42:15,240 --> 00:42:19,160
A sposób, w jaki to, że jest
dodając to, co nazywamy klucz zasięgu.

994
00:42:19,160 --> 00:42:22,460
>> Więc jeśli to tylko hash
Stół musi to być unikalny.

995
00:42:22,460 --> 00:42:27,040
Jeśli jest to skrót i zakres tabeli w
Połączenie mieszania i zakresie

996
00:42:27,040 --> 00:42:28,640
musi być unikalny.

997
00:42:28,640 --> 00:42:30,110
Więc pomyśl o tym w ten sposób.

998
00:42:30,110 --> 00:42:32,140
Jeśli mam forum.

999
00:42:32,140 --> 00:42:39,010
A forma ma tematów, ma
stanowisk i ma odpowiedzi.

1000
00:42:39,010 --> 00:42:42,630
>> Więc może mam hash
Klucz, który jest tematem ID.

1001
00:42:42,630 --> 00:42:46,650
A może mam klucza zasięgu,
która jest identyfikatorem odpowiedzi.

1002
00:42:46,650 --> 00:42:49,650
W ten sposób, jeśli chcę uzyskać wszystkie
odpowiedzi na dany temat,

1003
00:42:49,650 --> 00:42:52,370
Mogę tylko zapytać hash.

1004
00:42:52,370 --> 00:42:55,190
Mogę tylko powiedzieć, daj mi wszystko
elementy, które mają ten skrót.

1005
00:42:55,190 --> 00:43:01,910
I mam zamiar dostać się na każde pytanie
lub pisać na tym konkretnym temacie.

1006
00:43:01,910 --> 00:43:03,910
Te najlepsze skupiska poziomu
są bardzo ważne.

1007
00:43:03,910 --> 00:43:07,370
Wspierają one podstawowy dostęp
Wzór zastosowania.

1008
00:43:07,370 --> 00:43:09,420
Ogólnie mówiąc,
jest to, co chcemy zrobić.

1009
00:43:09,420 --> 00:43:11,780
Chcemy tego table--
jak załadować do stołu,

1010
00:43:11,780 --> 00:43:16,640
chcemy uporządkować dane
w tabeli, w taki sposób,

1011
00:43:16,640 --> 00:43:20,140
że wniosek może bardzo
szybko odzyskać te wyniki.

1012
00:43:20,140 --> 00:43:24,510
I często sposobem na to jest
utrzymać te skupiska jak my

1013
00:43:24,510 --> 00:43:25,650
wstawić dane.

1014
00:43:25,650 --> 00:43:31,110
Zasadniczo jesteśmy rozprzestrzeniania się danych
w jasnym wiadra, jak to jest w.

1015
00:43:31,110 --> 00:43:35,210
>> Zakres pozwalają me-- klawisze skrótu
Klawisze mają być równość.

1016
00:43:35,210 --> 00:43:39,490
Kiedy zapytać hash, muszę powiedzieć,
daj mi hash, że równa się to.

1017
00:43:39,490 --> 00:43:41,950
Kiedy zapytać zakres, ja
Można powiedzieć, dać mi wybór

1018
00:43:41,950 --> 00:43:47,040
że stosuje jakiegokolwiek
bogate operatora, że ​​popieramy.

1019
00:43:47,040 --> 00:43:49,200
Daj mi wszystkie rzeczy na hash.

1020
00:43:49,200 --> 00:43:52,520
Jest równa, większa niż
mniej niż, to początek,

1021
00:43:52,520 --> 00:43:54,145
to istnieje między tymi dwoma wartościami?

1022
00:43:54,145 --> 00:43:56,811
Więc te typy zapytań zasięgu
że zawsze jesteśmy zainteresowani.

1023
00:43:56,811 --> 00:43:59,650
Teraz jedną rzeczą danych, gdy
spojrzeć na dostęp do danych, gdy

1024
00:43:59,650 --> 00:44:02,360
można uzyskać dostęp do danych, to
Zawsze o agregacji.

1025
00:44:02,360 --> 00:44:05,770
Zawsze chodzi o rekordy
które są z tym związane.

1026
00:44:05,770 --> 00:44:10,390
Daj mi wszystko tutaj that's-- wszystkie
transakcje na tej karcie kredytowej

1027
00:44:10,390 --> 00:44:12,500
w poprzednim miesiącu.

1028
00:44:12,500 --> 00:44:13,960
To agregacja.

1029
00:44:13,960 --> 00:44:17,490
>> Prawie wszystko, co robisz w
Baza danych jest jakiś agregacji.

1030
00:44:17,490 --> 00:44:21,530
Tak, że mogą być w stanie określić
te wiadra i daje te zakres

1031
00:44:21,530 --> 00:44:24,950
atrybutów, aby móc zapytania o,
Zapytania te bogate wsparcie wielu,

1032
00:44:24,950 --> 00:44:27,165
wiele, wiele wzorów dostępu aplikacji.

1033
00:44:27,165 --> 00:44:30,990

1034
00:44:30,990 --> 00:44:35,000
>> Więc z drugiej rzeczy klawisz skrótu
Czy to daje nam mechanizm

1035
00:44:35,000 --> 00:44:37,740
być w stanie rozprzestrzeniać się dane się.

1036
00:44:37,740 --> 00:44:40,390
Baz danych NoSQL najlepiej
gdy dane są równomiernie

1037
00:44:40,390 --> 00:44:41,740
rozłożone klastra.

1038
00:44:41,740 --> 00:44:44,530

1039
00:44:44,530 --> 00:44:47,050
Jak wielu ludzi zna
z mieszania algorytmów?

1040
00:44:47,050 --> 00:44:49,860
Kiedy mówię, że hash i hashing--
ze względu na algorytm mieszający

1041
00:44:49,860 --> 00:44:54,140
Jest to sposób jest w stanie generować
losową wartość z danej wartości.

1042
00:44:54,140 --> 00:44:59,300
Zatem w tym szczególnym przypadku,
Algorytm mieszania prowadzimy jest ND 5 opiera.

1043
00:44:59,300 --> 00:45:04,765
>> A jeśli mam identyfikator, a to
jest mój klawisz krzyżyka, mam 1, 2, 3.

1044
00:45:04,765 --> 00:45:07,390
Kiedy uruchomić algorytm mieszania,
to będzie wrócić i powiedzieć,

1045
00:45:07,390 --> 00:45:10,800
oraz 1 równa 7B, 2
wynosi 48, 3 równa CD.

1046
00:45:10,800 --> 00:45:13,092
Są one rozsiane po całej przestrzeni kluczy.

1047
00:45:13,092 --> 00:45:14,050
I dlaczego to robisz?

1048
00:45:14,050 --> 00:45:17,120
Bo to daje pewność, że mogę
umieścić zapisy na wielu węzłach.

1049
00:45:17,120 --> 00:45:19,574
>> Jeśli to robię
przyrostowo, 1, 2, 3.

1050
00:45:19,574 --> 00:45:21,990
I mam szereg hash, że
przebiega w tym konkretnym przypadku,

1051
00:45:21,990 --> 00:45:24,785
mała przestrzeń mieszania,
biegnie od 00 do FF

1052
00:45:24,785 --> 00:45:27,951
następnie zapisy zamiar przyjść
i że będziemy jechać 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
Co się dzieje?

1055
00:45:31,800 --> 00:45:34,860
Każda wkładka ma ten sam węzeł.

1056
00:45:34,860 --> 00:45:36,070
Widzisz, co mam na myśli?

1057
00:45:36,070 --> 00:45:40,910
>> Bo kiedy podzielić przestrzeń,
i szerzyć te rekordy całej,

1058
00:45:40,910 --> 00:45:45,950
i partycja ja, ja powiem
Partycja 1 ma kluczową miejsca 0 do 54.

1059
00:45:45,950 --> 00:45:47,720
Partycja 2 jest 55 do 89.

1060
00:45:47,720 --> 00:45:49,780
Partycja 3 AA do FF.

1061
00:45:49,780 --> 00:45:53,740
Więc jeśli używam liniowo zwiększany
Identyfikatory można zobaczyć co się dzieje.

1062
00:45:53,740 --> 00:45:57,410
1, 2, 3, 4, 5, 6, wszystkie aż do 54.

1063
00:45:57,410 --> 00:46:00,030
Tak jak ja młotkiem
Zapisy do systemu,

1064
00:46:00,030 --> 00:46:02,030
Wszystko kończy się dzieje do jednego węzła.

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

1066
00:46:03,160 --> 00:46:04,820
To antipattern.

1067
00:46:04,820 --> 00:46:08,760
W MongoDB mają ten problem
jeśli nie używać klawisza skrótu.

1068
00:46:08,760 --> 00:46:11,325
MongoDB daje możliwość
od mieszania wartość klucza.

1069
00:46:11,325 --> 00:46:13,950
Zawsze należy zrobić, jeśli
używasz wzrastających hash

1070
00:46:13,950 --> 00:46:17,380
Kluczem w MongoDB, lub będziesz
przybijając każdy zapis do jednego węzła,

1071
00:46:17,380 --> 00:46:21,290
i będzie ograniczenie
Twoja wydajność zapisu źle.

1072
00:46:21,290 --> 00:46:24,896
>> PUBLICZNOŚCI: Czy to A9 169 w po przecinku?

1073
00:46:24,896 --> 00:46:28,450
>> RICK HOULIHAN: Tak, to jest
gdzieś tam.

1074
00:46:28,450 --> 00:46:29,950
A9, nie wiem.

1075
00:46:29,950 --> 00:46:32,200
Trzeba, aby mój plik binarny
do kalkulatora po przecinku.

1076
00:46:32,200 --> 00:46:34,237
Mój mózg nie działa w ten sposób.

1077
00:46:34,237 --> 00:46:36,320
PUBLICZNOŚCI: Tylko szybki jeden
waszych komentarzy Mongo.

1078
00:46:36,320 --> 00:46:39,530
Więc jest identyfikator obiektu, który pochodzi
natywnie z Mongo zrobić?

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

1080
00:46:40,179 --> 00:46:41,470
RICK HOULIHAN: Czy to zrobić?

1081
00:46:41,470 --> 00:46:42,970
Jeśli podasz go.

1082
00:46:42,970 --> 00:46:45,030
Z MongoDB, masz możliwość.

1083
00:46:45,030 --> 00:46:48,930
Możesz specify-- każdy dokument
MongoDB musi mieć identyfikator podkreślenia.

1084
00:46:48,930 --> 00:46:50,300
To wyjątkowa wartość.

1085
00:46:50,300 --> 00:46:55,240
>> W MongoDB można określić
czy do mieszania lub nie.

1086
00:46:55,240 --> 00:46:56,490
Oni po prostu daje możliwość.

1087
00:46:56,490 --> 00:46:58,198
Jeśli wiesz, że jest to
losowo, nie ma problemu.

1088
00:46:58,198 --> 00:46:59,640
Nie musisz tego robić.

1089
00:46:59,640 --> 00:47:04,260
Jeśli wiesz, że to nie jest przypadkowe, że
to jest zwiększany, a następnie zrobić hash.

1090
00:47:04,260 --> 00:47:06,880
>> Teraz rzeczą
mieszania, po hash

1091
00:47:06,880 --> 00:47:08,800
value-- i to jest
dlaczego klawisze skrótu są zawsze

1092
00:47:08,800 --> 00:47:13,740
unikalnych zapytań, ponieważ zmieniłem
wartość, teraz nie mogę zrobić kwerendę zasięgu.

1093
00:47:13,740 --> 00:47:15,640
Nie mogę powiedzieć, czy to
od tego czy tamtego,

1094
00:47:15,640 --> 00:47:20,800
ponieważ wartość skrótu nie będzie
za równoważne z wartością rzeczywistą.

1095
00:47:20,800 --> 00:47:24,570
Więc kiedy hash, że
klucz, to tylko równość.

1096
00:47:24,570 --> 00:47:28,700
To dlatego w DynamoDB klawisza skrótu
Zapytania są zawsze tylko równość.

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

1098
00:47:32,090 --> 00:47:34,700
>> Teraz w zakresie key--
kiedy dodać ten klucz zasięgu,

1099
00:47:34,700 --> 00:47:38,180
Kluczowe zapisy te są w zasięgu wszystkich i
one przechowywane na tej samej partycji.

1100
00:47:38,180 --> 00:47:42,430
Tak więc są one bardzo szybko, łatwo
odzyskane, ponieważ jest to skrót,

1101
00:47:42,430 --> 00:47:43,220
Jest to zakres.

1102
00:47:43,220 --> 00:47:44,928
I widzisz wszystko
z tym samym hash

1103
00:47:44,928 --> 00:47:48,550
zostanie zapisane na tej samej przestrzeni partycji.

1104
00:47:48,550 --> 00:47:53,889
Możesz użyć tego klucza zakres pomóc
zlokalizować swoje dane blisko rodzica.

1105
00:47:53,889 --> 00:47:55,180
Więc co ja naprawdę tu robisz?

1106
00:47:55,180 --> 00:47:57,320
Jest to jeden do wielu związku.

1107
00:47:57,320 --> 00:48:01,490
Zależność pomiędzy klawisza skrótu
oraz kluczowy zakres jest jeden do wielu.

1108
00:48:01,490 --> 00:48:03,490
Mogę mieć kilka klawiszy skrótu.

1109
00:48:03,490 --> 00:48:07,610
Mogę mieć tylko wielokrotny wybór
Klawisze w każdym krzyżyka.

1110
00:48:07,610 --> 00:48:11,910
>> Hash określa rodzica,
zakres określa dzieci.

1111
00:48:11,910 --> 00:48:15,240
Więc widać, nie ma tu analogowe
pomiędzy relacyjną konstruktem

1112
00:48:15,240 --> 00:48:18,840
i te same typy
konstruuje się w NoSQL.

1113
00:48:18,840 --> 00:48:20,760
Ludzie mówią o
NoSQL jak nierelacyjne.

1114
00:48:20,760 --> 00:48:22,200
To nie nierelacyjne.

1115
00:48:22,200 --> 00:48:24,680
Dane zawsze ma relacji.

1116
00:48:24,680 --> 00:48:28,172
Relacje te właśnie
wzorowane są inaczej.

1117
00:48:28,172 --> 00:48:29,880
Porozmawiajmy trochę
Trochę o trwałości.

1118
00:48:29,880 --> 00:48:34,860
Kiedy piszesz do DynamoDB, pisze
są zawsze trójdrożny replikowane.

1119
00:48:34,860 --> 00:48:37,550
Co oznacza, że ​​mamy trzy AZ.

1120
00:48:37,550 --> 00:48:39,160
AZ są Dostępność Strefy.

1121
00:48:39,160 --> 00:48:43,430
Możesz myśleć o dostępność
Strefa w centrum danych

1122
00:48:43,430 --> 00:48:45,447
lub zbiór danych ośrodkach.

1123
00:48:45,447 --> 00:48:47,780
Te rzeczy są geograficznie
od siebie odizolowane

1124
00:48:47,780 --> 00:48:51,610
w różnych strefach błędów, przez
różne sieci energetyczne i obszarów zalewowych.

1125
00:48:51,610 --> 00:48:54,510
Awaria w jednej AZ nie jest
zajmie się inna.

1126
00:48:54,510 --> 00:48:56,890
Są one również połączone
wraz z ciemnych włókien światłowodowych.

1127
00:48:56,890 --> 00:49:01,240
Obsługuje jeden sub 1
milisekund opóźnienia pomiędzy AZS.

1128
00:49:01,240 --> 00:49:05,390
Więc replikacji danych w czasie rzeczywistym
w stanie w wielu AZS.

1129
00:49:05,390 --> 00:49:09,990
>> Wdrożenia i często Multi AZ
spełniają wysokie wymagania dostępności

1130
00:49:09,990 --> 00:49:12,930
większości organizacji przedsiębiorstw.

1131
00:49:12,930 --> 00:49:16,139
Więc DynamoDB rozprzestrzenia
w trzech AZS domyślnie.

1132
00:49:16,139 --> 00:49:19,430
Jedziemy tylko wiedzy zapisu
kiedy dwóch z tych trzech węzłów wrócić

1133
00:49:19,430 --> 00:49:21,470
i powiedzieć: Tak, rozumiem.

1134
00:49:21,470 --> 00:49:22,050
Dlaczego?

1135
00:49:22,050 --> 00:49:25,950
Ponieważ na stronie odczytu jesteśmy tylko
będzie Ci dane z powrotem, gdy

1136
00:49:25,950 --> 00:49:27,570
mamy go z dwoma węzłami.

1137
00:49:27,570 --> 00:49:30,490
>> Jeśli mam replikacji całej
trzy, i czytam od dwóch,

1138
00:49:30,490 --> 00:49:32,840
Ja zawsze gwarantowane
aby co najmniej jeden

1139
00:49:32,840 --> 00:49:35,720
Spośród tych odczytuje się za
Najbardziej aktualna kopia danych.

1140
00:49:35,720 --> 00:49:38,340
To sprawia, że ​​DynamoDB spójne.

1141
00:49:38,340 --> 00:49:42,450
Teraz możesz wybrać, aby włączyć
te zgodne czyta się.

1142
00:49:42,450 --> 00:49:45,070
W tym przypadku mam zamiar powiedzieć,
Będę czytać tylko z jednego węzła.

1143
00:49:45,070 --> 00:49:47,430
I nie może zagwarantować, że będzie
za najbardziej aktualne dane.

1144
00:49:47,430 --> 00:49:49,450
>> Tak więc, jeśli zapis jest w najbliższych,
jeszcze nie replikowane,

1145
00:49:49,450 --> 00:49:50,360
masz zamiar uzyskać tę kopię.

1146
00:49:50,360 --> 00:49:52,220
To ostatecznie zgodne odczytu.

1147
00:49:52,220 --> 00:49:54,640
A co to jest to połowa kosztów.

1148
00:49:54,640 --> 00:49:56,140
Tak więc jest to coś do myślenia.

1149
00:49:56,140 --> 00:50:00,160
Kiedy czyta się DynamoDB i
jesteś konfigurowania możliwości odczytu

1150
00:50:00,160 --> 00:50:04,430
jednostki, jeśli zdecydujemy ostatecznie
zgodne czyta, to o wiele tańsze,

1151
00:50:04,430 --> 00:50:06,010
to o połowę kosztów.

1152
00:50:06,010 --> 00:50:09,342
>> I tak to oszczędność pieniędzy.

1153
00:50:09,342 --> 00:50:10,300
Ale to twój wybór.

1154
00:50:10,300 --> 00:50:12,925
Jeśli chcesz poczytać lub spójnego
ostatecznie zgodne odczytu.

1155
00:50:12,925 --> 00:50:15,720
To jest coś, co możesz wybrać.

1156
00:50:15,720 --> 00:50:17,659
>> Porozmawiajmy o indeksach.

1157
00:50:17,659 --> 00:50:19,450
Tak więc wspomnieć, że
top agregacji poziom.

1158
00:50:19,450 --> 00:50:23,720
Mamy klawiszy skrótu, a
mamy klucze zasięgu.

1159
00:50:23,720 --> 00:50:24,320
To miłe.

1160
00:50:24,320 --> 00:50:26,950
I to jest na głównym stole, ja
jeszcze jeden klawisz krzyżyka, mam jeden klucz zasięgu.

1161
00:50:26,950 --> 00:50:27,783
>> Co to znaczy?

1162
00:50:27,783 --> 00:50:30,410
Mam jedną cechę, że
można uruchomić bogate kwerendy.

1163
00:50:30,410 --> 00:50:31,800
To jest klucz zakres.

1164
00:50:31,800 --> 00:50:35,530
Pozostałe atrybuty dotyczące tego item--
Może filtrować na tych atrybutów.

1165
00:50:35,530 --> 00:50:40,050
Ale nie mogę robić takie rzeczy jak, to
rozpoczyna się od, albo jest większy niż.

1166
00:50:40,050 --> 00:50:40,820
>> Jak mogę to zrobić?

1167
00:50:40,820 --> 00:50:42,860
Utworzyć indeks.

1168
00:50:42,860 --> 00:50:45,340
Są dwa rodzaje
indeksy w DynamoDB.

1169
00:50:45,340 --> 00:50:49,002
Indeks jest naprawdę
inny widok tabeli.

1170
00:50:49,002 --> 00:50:50,490
A lokalny wskaźnik średniej.

1171
00:50:50,490 --> 00:50:51,781
>> Pierwszy z nich porozmawiamy.

1172
00:50:51,781 --> 00:50:57,740
Więc lokalne wtórne są współistniały
na tej samej partycji co danych.

1173
00:50:57,740 --> 00:51:00,240
I jako takie, są one w
tym samym węzłem fizycznych.

1174
00:51:00,240 --> 00:51:01,780
Są to, co nazywamy spójne.

1175
00:51:01,780 --> 00:51:04,599
Znaczenie, będą one potwierdzić
zapisu wraz ze stołem.

1176
00:51:04,599 --> 00:51:06,890
Gdy przychodzi do zapisu,
będziemy pisać przez indeks.

1177
00:51:06,890 --> 00:51:09,306
Będziemy pisać do stołu,
a następnie będziemy potwierdzić.

1178
00:51:09,306 --> 00:51:10,490
Więc to jest spójne.

1179
00:51:10,490 --> 00:51:13,174
Gdy zapis został
przyznał z tabeli,

1180
00:51:13,174 --> 00:51:15,090
to gwarantuje, że
lokalnego indeksu wtórnego

1181
00:51:15,090 --> 00:51:18,380
będzie miał taką samą wizji danych.

1182
00:51:18,380 --> 00:51:22,390
Ale to, co pozwala zrobić to
określenie alternatywnych klawiszy zasięgu.

1183
00:51:22,390 --> 00:51:25,260
>> Muszą używać tego samego skrótu
Kluczem w tabeli podstawowej,

1184
00:51:25,260 --> 00:51:29,050
ponieważ są kolokowane na
sama partycja, i są one spójne.

1185
00:51:29,050 --> 00:51:33,110
Ale mogę utworzyć indeks
z różnych kluczy zasięgu.

1186
00:51:33,110 --> 00:51:41,590
Tak na przykład, gdybym miał producenta
że miał stół części surowego najbliższych.

1187
00:51:41,590 --> 00:51:44,590
I surowców są w części, a
są one sumowane przez zespół.

1188
00:51:44,590 --> 00:51:46,840
A może jest wycofanie.

1189
00:51:46,840 --> 00:51:50,240
>> Każda część, która została wykonana przez tego
Producent po tej dacie,

1190
00:51:50,240 --> 00:51:52,840
Muszę wyciągnąć z mojej linii.

1191
00:51:52,840 --> 00:51:55,950
Mogę kręcić indeks
które byłyby wygląd,

1192
00:51:55,950 --> 00:52:00,760
agregowania w dniu
producenci z danej części.

1193
00:52:00,760 --> 00:52:03,930
Więc jeśli mój blat poziom był
już zakodowane przez producenta,

1194
00:52:03,930 --> 00:52:07,655
może to był umieszczony na części ID, I
może utworzyć indeks poza tym stole

1195
00:52:07,655 --> 00:52:11,140
jako zakodowane przez producenta i
wahała się od daty produkcji.

1196
00:52:11,140 --> 00:52:14,490
I w ten sposób mogę powiedzieć, cokolwiek,
został wyprodukowany pomiędzy tymi datami,

1197
00:52:14,490 --> 00:52:16,804
Muszę wyciągnąć z linii.

1198
00:52:16,804 --> 00:52:18,220
Więc to lokalny wskaźnik średniej.

1199
00:52:18,220 --> 00:52:22,280
>> Mają one efekt
ograniczając przestrzeń klawisz krzyżyka.

1200
00:52:22,280 --> 00:52:24,360
Ponieważ współistniały
w tym samym węźle składowania

1201
00:52:24,360 --> 00:52:26,860
ograniczają klawisz skrótu
Przestrzeń do 10 gigabajtów.

1202
00:52:26,860 --> 00:52:28,950
DynamoDB, pod
tabele, będzie podzielić

1203
00:52:28,950 --> 00:52:31,380
tabela co 10 gigabajtów.

1204
00:52:31,380 --> 00:52:34,760
Kiedy można umieścić 10 koncertów danych w, my
go [PhH], a dodamy kolejny węzeł.

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

1206
00:52:38,120 --> 00:52:42,070
>> Nie będziemy dzielić LSI
na wielu partycjach.

1207
00:52:42,070 --> 00:52:43,200
Będziemy dzielić stół.

1208
00:52:43,200 --> 00:52:44,679
Ale nie podzieli LSI.

1209
00:52:44,679 --> 00:52:46,470
Więc to jest coś
ważne, aby zrozumieć

1210
00:52:46,470 --> 00:52:50,070
to jeśli robisz bardzo,
bardzo, bardzo duże skupiska,

1211
00:52:50,070 --> 00:52:53,860
to masz zamiar być ograniczone
do 10 gigabajtów na swojej LSI.

1212
00:52:53,860 --> 00:52:56,640
>> Jeśli tak jest, możemy
używać globalnych wtórnymi.

1213
00:52:56,640 --> 00:52:58,630
Globalne wtórne są
naprawdę inna tabela.

1214
00:52:58,630 --> 00:53:01,720
Istnieją one całkowicie wyłączony z
z boku tabeli podstawowej.

1215
00:53:01,720 --> 00:53:04,680
A oni pozwalają mi znaleźć
zupełnie inna konstrukcja.

1216
00:53:04,680 --> 00:53:08,010
Więc pomyśl o tym, jak dane są wstawiane
w dwóch różnych tabel, zorganizowany

1217
00:53:08,010 --> 00:53:09,220
na dwa różne sposoby.

1218
00:53:09,220 --> 00:53:11,360
>> Można zdefiniować zupełnie
inna klawisz krzyżyka.

1219
00:53:11,360 --> 00:53:13,490
Można zdefiniować zupełnie
Zakres inny klucz.

1220
00:53:13,490 --> 00:53:15,941
A może to uruchomić
całkowicie niezależnie.

1221
00:53:15,941 --> 00:53:18,190
W rzeczywistości, mam
zabezpieczony moje zdolności odczytu

1222
00:53:18,190 --> 00:53:21,090
i pisać zdolności dla mojego
globalne indeksy wtórne

1223
00:53:21,090 --> 00:53:24,240
zupełnie niezależnie
mojej tabeli podstawowej.

1224
00:53:24,240 --> 00:53:26,640
Gdybym zdefiniowania tego indeksu, mówię
to jak dużo czytać i pisać

1225
00:53:26,640 --> 00:53:28,610
Pojemność to zamiar używać.

1226
00:53:28,610 --> 00:53:31,490
>> I to jest oddzielna
z mojego pierwotnego tabeli.

1227
00:53:31,490 --> 00:53:35,240
Teraz oba indeksy pozwalają nam
zdefiniować nie tylko klawisze skrótu i ​​zasięgu,

1228
00:53:35,240 --> 00:53:38,610
ale oni pozwalają nam
rzutować dodatkowe wartości.

1229
00:53:38,610 --> 00:53:44,950
Więc jeśli chcę odczytać indeks,
i chcę trochę zestaw danych,

1230
00:53:44,950 --> 00:53:48,327
Nie muszę wrócić do głównego
Stół, aby uzyskać dodatkowe atrybuty.

1231
00:53:48,327 --> 00:53:50,660
Mogę projekcji tych dodatkowych
atrybutów w tabeli

1232
00:53:50,660 --> 00:53:53,440
wspierać wzór dostępu.

1233
00:53:53,440 --> 00:53:57,700
Wiem, że pewnie się do niektórych
Naprawdę, really-- wsiada do chwastów

1234
00:53:57,700 --> 00:53:58,910
tu, na niektóre z tych rzeczy.

1235
00:53:58,910 --> 00:54:02,725
Teraz mam dryfować z tego.

1236
00:54:02,725 --> 00:54:07,320
>> PUBLICZNOŚCI: [niesłyszalne]
Kluczem --table oznaczało był hash?

1237
00:54:07,320 --> 00:54:08,840
Oryginalny hash?

1238
00:54:08,840 --> 00:54:09,340
Multi-listwy?

1239
00:54:09,340 --> 00:54:10,200
>> RICK HOULIHAN: Tak.

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

1241
00:54:11,070 --> 00:54:15,260
Kluczem Stół zasadzie
wskazuje z powrotem do pozycji.

1242
00:54:15,260 --> 00:54:19,280
Tak więc indeks jest wskaźnikiem powrotem
oryginalne elementy na stole.

1243
00:54:19,280 --> 00:54:22,910
Teraz możesz zbudować
Strona, która ma tylko klucz tabeli,

1244
00:54:22,910 --> 00:54:24,840
a nie inne właściwości.

1245
00:54:24,840 --> 00:54:26,570
I dlaczego może to zrobić?

1246
00:54:26,570 --> 00:54:28,570
No, może mam bardzo dużych przedmiotów.

1247
00:54:28,570 --> 00:54:31,660
>> I naprawdę tylko trzeba wiedzieć which--
mój wzór dostępu może powiedzieć,

1248
00:54:31,660 --> 00:54:33,760
elementy, które zawierają tę nieruchomość?

1249
00:54:33,760 --> 00:54:35,780
Nie trzeba zwrócić przedmiot.

1250
00:54:35,780 --> 00:54:37,800
Po prostu trzeba wiedzieć
elementy, które zawierają go.

1251
00:54:37,800 --> 00:54:40,700
Więc można budować indeksy
że tylko klucz tabeli.

1252
00:54:40,700 --> 00:54:43,360
>> Ale to przede wszystkim to, co
indeks w bazie danych jest.

1253
00:54:43,360 --> 00:54:46,280
To z możliwości szybkiego
określić, które rejestruje,

1254
00:54:46,280 --> 00:54:49,470
wiersze, które
pozycje w tabeli mają

1255
00:54:49,470 --> 00:54:51,080
właściwości, których szukam.

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

1257
00:54:53,610 --> 00:54:54,860
>> GSIS, tak jak one działają?

1258
00:54:54,860 --> 00:54:58,340
GSIS zasadzie są asynchroniczne.

1259
00:54:58,340 --> 00:55:02,570
Aktualizacja wchodzi stół
Stół jest następnie asynchronicznie zaktualizowane

1260
00:55:02,570 --> 00:55:03,720
wszystkie swoje GSIS.

1261
00:55:03,720 --> 00:55:06,680
To dlatego GSIS są
ostatecznie spójne.

1262
00:55:06,680 --> 00:55:09,440
>> Ważne jest, aby zauważyć, że
gdy budujesz GSIS,

1263
00:55:09,440 --> 00:55:13,110
i zrozumieć, że tworzysz
inny wymiar aggregation--

1264
00:55:13,110 --> 00:55:16,594
Teraz powiedzmy, że dobry przykład
tutaj jest producentem.

1265
00:55:16,594 --> 00:55:19,260
Myślę, że mógłbym mówił o
producentem urządzenia medycznego.

1266
00:55:19,260 --> 00:55:23,870
Producenci urządzeń medycznych
często mają części odcinkach.

1267
00:55:23,870 --> 00:55:28,070
Części, które go do
stawu biodrowego wszystkich

1268
00:55:28,070 --> 00:55:30,200
mieć trochę numer seryjny na nich.

1269
00:55:30,200 --> 00:55:33,584
A może oni mają miliony, a
miliony i miliardy części

1270
00:55:33,584 --> 00:55:35,000
we wszystkich urządzeniach, że statek.

1271
00:55:35,000 --> 00:55:37,440
Cóż, muszą agregować pod
różne wymiary, wszystkie części

1272
00:55:37,440 --> 00:55:39,520
w zespole, wszystkie
części, które zostały wprowadzone

1273
00:55:39,520 --> 00:55:41,670
na danej linii, wszystkie
części, które weszły

1274
00:55:41,670 --> 00:55:44,620
z pewnym producenta
w określonym terminie.

1275
00:55:44,620 --> 00:55:47,940
I te skupiska czasem
wstać w miliardach.

1276
00:55:47,940 --> 00:55:50,550
>> Więc pracuję z niektórych
ci faceci, którzy cierpią

1277
00:55:50,550 --> 00:55:53,156
bo tworzysz
te GINORMOUS agregacji

1278
00:55:53,156 --> 00:55:54,280
w ich indeksy średnich.

1279
00:55:54,280 --> 00:55:57,070
Mogą mieć surowy części
Stół, który przychodzi, jak tylko hash.

1280
00:55:57,070 --> 00:55:59,090
Każda część posiada unikalny numer seryjny.

1281
00:55:59,090 --> 00:56:00,975
Używam numer seryjny jako hash.

1282
00:56:00,975 --> 00:56:01,600
Jest piękne.

1283
00:56:01,600 --> 00:56:04,160
Moja surowe tabela danych jest rozłożona
całej przestrzeni kluczy.

1284
00:56:04,160 --> 00:56:05,930
Mój [? napisać ?]
[? Spożycie?] jest niesamowite.

1285
00:56:05,930 --> 00:56:07,876
Biorę dużo danych.

1286
00:56:07,876 --> 00:56:09,500
Wtedy to, co robią jest tworzą GSI.

1287
00:56:09,500 --> 00:56:12,666
A ja mówię, wiesz co, muszę zobaczyć
wszystkie części tego producenta.

1288
00:56:12,666 --> 00:56:15,060
Cóż, tak nagle, że jestem
biorąc miliard wierszy,

1289
00:56:15,060 --> 00:56:17,550
i nadziać je na
jeden węzeł, ponieważ kiedy

1290
00:56:17,550 --> 00:56:21,170
I agregacji jako
ID producenta jako hash,

1291
00:56:21,170 --> 00:56:25,410
oraz numer części jako zakres,
następnie wszystkie nagły jestem

1292
00:56:25,410 --> 00:56:30,530
wprowadzenie miliard części w co
Ten producent wydał mi.

1293
00:56:30,530 --> 00:56:34,447
>> To może spowodować wiele
ciśnienia na GSI,

1294
00:56:34,447 --> 00:56:36,030
znowu, bo jestem młotkiem jeden węzeł.

1295
00:56:36,030 --> 00:56:38,350
Kładę wszystko
wstawia do jednego węzła.

1296
00:56:38,350 --> 00:56:40,940
I to jest prawdziwa sprawa problematyczna wykorzystanie.

1297
00:56:40,940 --> 00:56:43,479
Teraz, mam dobry projekt
wzór, w jaki sposób uniknąć.

1298
00:56:43,479 --> 00:56:45,770
I to jest jeden z problemów
że zawsze pracować.

1299
00:56:45,770 --> 00:56:49,590
Ale co się dzieje, jest GSI może
nie ma wystarczającej pojemności zapisu

1300
00:56:49,590 --> 00:56:52,330
aby móc przesunąć tych wszystkich
wiersze w jeden węzeł.

1301
00:56:52,330 --> 00:56:55,390
A co się dzieje, to jest
Podstawowym tabela klienta

1302
00:56:55,390 --> 00:57:00,180
pierwsza tabela będzie zdławiony
ponieważ GSI nie może nadążyć.

1303
00:57:00,180 --> 00:57:02,980
Więc moje stopy wkładka będzie
spadnie na tabeli podstawowej

1304
00:57:02,980 --> 00:57:06,230
jak mój GSI stara się nadążyć.

1305
00:57:06,230 --> 00:57:08,850
>> W porządku, więc GSi, LSI użytkownika,
który z nich wybrać?

1306
00:57:08,850 --> 00:57:12,290
LSI są zgodne.

1307
00:57:12,290 --> 00:57:13,750
GSi są ostatecznie zgodne.

1308
00:57:13,750 --> 00:57:17,490
Jeśli to jest OK, polecam za pomocą
GSI, są znacznie bardziej elastyczne.

1309
00:57:17,490 --> 00:57:20,270
LSI może być modelowana jako GSI.

1310
00:57:20,270 --> 00:57:27,040
A jeśli rozmiar danych na klawisze skrótu w
Twoja kolekcja przekracza 10 GB,

1311
00:57:27,040 --> 00:57:31,050
wtedy będziesz chciał użyć tego
GSI, bo to jest po prostu trudne limitu.

1312
00:57:31,050 --> 00:57:32,035
>> W porządku, więc skalowanie.

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

1314
00:57:35,210 --> 00:57:37,460
Przepustowość w Dynamo DB, można
przepis ten może [niesłyszalne]

1315
00:57:37,460 --> 00:57:38,680
przepustowości w tabeli.

1316
00:57:38,680 --> 00:57:42,740
Mamy klientów, które mają
zabezpieczony 60 billion--

1317
00:57:42,740 --> 00:57:45,970
robią 60 mld żądań, regularnie
działa na ponad milion wniosków

1318
00:57:45,970 --> 00:57:47,790
na sekundę na naszych stołach.

1319
00:57:47,790 --> 00:57:50,360
Naprawdę nie
teoretyczna granica ile

1320
00:57:50,360 --> 00:57:53,730
i jak szybko tabela
można uruchomić w Dynamo DB.

1321
00:57:53,730 --> 00:57:55,920
Istnieją pewne miękkie
limity na koncie

1322
00:57:55,920 --> 00:57:58,170
które wkładamy w nie tak
że nie zwariować.

1323
00:57:58,170 --> 00:58:00,070
Jeśli chcesz więcej niż
że nie jest to problemem.

1324
00:58:00,070 --> 00:58:00,820
Możesz przyjść nam powiedzieć.

1325
00:58:00,820 --> 00:58:02,810
Będziemy podkręcić pokrętło.

1326
00:58:02,810 --> 00:58:08,210
>> Każde konto jest ograniczona do pewnego poziomu
w każdej usługi, tuż nietoperza

1327
00:58:08,210 --> 00:58:11,920
więc ludzie nie zwariować
dostać się w kłopoty.

1328
00:58:11,920 --> 00:58:12,840
Brak limitu wielkości.

1329
00:58:12,840 --> 00:58:14,940
Możesz umieścić dowolną liczbę
pozycji na stole.

1330
00:58:14,940 --> 00:58:17,620
Wielkość elementu jest
ograniczona do 400 kilobajtów każdy,

1331
00:58:17,620 --> 00:58:20,050
to byłby element nie atrybuty.

1332
00:58:20,050 --> 00:58:24,200
Tak więc suma wszystkich atrybutów
jest ograniczona do 400 kilobajtów.

1333
00:58:24,200 --> 00:58:27,300
I znów mamy
że niewiele LSI problem

1334
00:58:27,300 --> 00:58:30,405
z limitem 10 GB na hash.

1335
00:58:30,405 --> 00:58:33,280
PUBLICZNOŚCI: Mała liczba, mi brakuje
co chcesz mi powiedzieć, że jest--

1336
00:58:33,280 --> 00:58:36,830
PUBLICZNOŚCI: Och, 400 kilobajtów
Jest to maksymalny rozmiar za sztukę.

1337
00:58:36,830 --> 00:58:39,570
Tak więc pozycja ma wszystkie atrybuty.

1338
00:58:39,570 --> 00:58:43,950
Tak 400 k jest całkowitą wielkość
z tej pozycji, 400 kilobajtów.

1339
00:58:43,950 --> 00:58:46,170
Tak więc z wszystkimi atrybutami
połączone, wszystkie dane

1340
00:58:46,170 --> 00:58:49,140
to we wszystkich tych atrybutów,
zwinięty w łącznej wielkości

1341
00:58:49,140 --> 00:58:51,140
obecnie już limit rzecz jest 400 tys.

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

1343
00:58:54,390 --> 00:58:57,046
Więc skalowanie ponownie osiągnąć
poprzez ścianki działowe.

1344
00:58:57,046 --> 00:58:58,920
Przepustowość jest zabezpieczony
na poziomie stołu.

1345
00:58:58,920 --> 00:59:00,160
I tam naprawdę dwa pokrętła.

1346
00:59:00,160 --> 00:59:02,400
Zapoznaliśmy zdolności
i pisać zdolności.

1347
00:59:02,400 --> 00:59:05,530
>> Tak więc są one regulowane
niezależnie od siebie.

1348
00:59:05,530 --> 00:59:08,640
Miarą pilocie jest ściśle zgodne czyta.

1349
00:59:08,640 --> 00:59:13,005
OK, więc jeśli mówisz, chcę 1000
Pilot na to są ściśle zgodne,

1350
00:59:13,005 --> 00:59:14,130
te są zgodne czyta.

1351
00:59:14,130 --> 00:59:17,130
Jeśli mówisz, że chcę
Ewentualne zgodne czyta,

1352
00:59:17,130 --> 00:59:19,402
można zastrzec 1000
Pilot użytkownika, będziesz

1353
00:59:19,402 --> 00:59:21,840
dostać 2,000 końcu
zgodne czyta.

1354
00:59:21,840 --> 00:59:25,940
I połowę ceny dla tych,
docelowo składać się czyta.

1355
00:59:25,940 --> 00:59:28,520
>> Ponownie, zmienić
niezależnie od siebie.

1356
00:59:28,520 --> 00:59:32,900
I mają throughput--
Jeśli zużywają 100% swojej pilocie,

1357
00:59:32,900 --> 00:59:35,960
nie idziesz do oddziaływania na
dostępność swoich praw.

1358
00:59:35,960 --> 00:59:40,161
Tak więc są one całkowicie
niezależnie od siebie.

1359
00:59:40,161 --> 00:59:43,160
W porządku, więc jedną z rzeczy, które
Wspomniałem krótko został dławienia.

1360
00:59:43,160 --> 00:59:44,320
Dławienie jest złe.

1361
00:59:44,320 --> 00:59:47,311
Dławienie wskazuje złe nie SQL.

1362
00:59:47,311 --> 00:59:50,310
Są rzeczy, które możemy zrobić, aby pomóc
można złagodzić dławienie, że cię

1363
00:59:50,310 --> 00:59:51,040
doświadczamy.

1364
00:59:51,040 --> 00:59:53,240
Ale najlepszym rozwiązaniem
Do tego weźmy

1365
00:59:53,240 --> 00:59:58,000
Spójrz na to, co robisz, ponieważ
jest anty-wzór w grze tutaj.

1366
00:59:58,000 --> 01:00:02,140
>> Te rzeczy, rzeczy takie jak niejednolite
obciążenia, klawisze, gorące ścianki działowe.

1367
01:00:02,140 --> 01:00:06,210
Jestem uderzenie szczególną przestrzeń kluczy
bardzo ciężko z jakiegoś konkretnego powodu.

1368
01:00:06,210 --> 01:00:07,080
Dlaczego ja to robię?

1369
01:00:07,080 --> 01:00:08,710
Miejmy tego dowiedzieć.

1370
01:00:08,710 --> 01:00:10,427
Jestem mieszania moje gorące dane z zimnymi danych.

1371
01:00:10,427 --> 01:00:12,510
Ja pozwolę moje tabele się
ogromny, ale tam naprawdę

1372
01:00:12,510 --> 01:00:15,970
tylko niektóre podzbiór danych
to naprawdę interesujące dla mnie.

1373
01:00:15,970 --> 01:00:20,290
Tak więc dla danych dziennika, na przykład, dużo
Klienci, dostają codziennie dane logowania.

1374
01:00:20,290 --> 01:00:22,490
Dostali ogromną ilość danych dziennika.

1375
01:00:22,490 --> 01:00:25,940
>> Jeśli jesteś po prostu cały ten dziennik dumpingu
dane w jednym dużym stole, w czasie

1376
01:00:25,940 --> 01:00:28,070
że tabela będzie się ogromne.

1377
01:00:28,070 --> 01:00:30,950
Ale jestem bardzo zainteresowany tylko
ostatnie 24 godziny, siedem dni ostatnich,

1378
01:00:30,950 --> 01:00:31,659
ostatnie 30 dni.

1379
01:00:31,659 --> 01:00:34,074
Niezależnie od okno czasowe
że jestem zainteresowany patrząc

1380
01:00:34,074 --> 01:00:37,010
dla zdarzenia, które mnie nurtuje, lub
Wydarzenie to jest dla mnie interesujące,

1381
01:00:37,010 --> 01:00:39,540
to jedyny czas, okno, że muszę.

1382
01:00:39,540 --> 01:00:42,470
Więc dlaczego ja wprowadzenie 10 lat
Warto danych dziennika w tabeli?

1383
01:00:42,470 --> 01:00:45,030
Co powoduje, że jest
tabela fragment.

1384
01:00:45,030 --> 01:00:45,880
>> To staje się ogromne.

1385
01:00:45,880 --> 01:00:48,340
Zaczyna rozkładanie
w tysiącach węzłów.

1386
01:00:48,340 --> 01:00:51,380
I od twoich możliwości
jest tak niska, że ​​jesteś

1387
01:00:51,380 --> 01:00:54,090
właściwie ocenić ograniczenia na każdym
jeden z tych pojedynczych węzłów.

1388
01:00:54,090 --> 01:00:57,120
Zacznijmy więc patrząc na to, jak
mamy toczyć tej tabeli powyżej.

1389
01:00:57,120 --> 01:01:01,502
W jaki sposób zarządzać, że dane trochę
lepiej, aby uniknąć tych problemów.

1390
01:01:01,502 --> 01:01:02,710
A co to ma wyglądać?

1391
01:01:02,710 --> 01:01:04,370
To co to wygląda.

1392
01:01:04,370 --> 01:01:06,790
To jest to, co złe NoSQL wygląda.

1393
01:01:06,790 --> 01:01:07,830
>> Mam również klawisz tutaj.

1394
01:01:07,830 --> 01:01:10,246
Jeśli spojrzeć na stronie tutaj
to są wszystkie moje partycje.

1395
01:01:10,246 --> 01:01:12,630
Mam 16 partycje tutaj
na tej konkretnej bazy danych.

1396
01:01:12,630 --> 01:01:13,630
Robimy to cały czas.

1397
01:01:13,630 --> 01:01:15,046
Uruchomić to dla klientów cały czas.

1398
01:01:15,046 --> 01:01:16,550
To się nazywa mapa ciepła.

1399
01:01:16,550 --> 01:01:20,590
Mapa cieplna mówi mi, jak jesteś
dostępu do klucza miejsca.

1400
01:01:20,590 --> 01:01:23,700
I co to mówi mi to
że nie ma jednego konkretnego hash

1401
01:01:23,700 --> 01:01:26,330
że ten facet lubi
strasznie dużo, bo jest

1402
01:01:26,330 --> 01:01:28,250
ukryć, że bardzo, bardzo ciężko.

1403
01:01:28,250 --> 01:01:29,260
>> Więc niebieski jest ładny.

1404
01:01:29,260 --> 01:01:29,900
Lubimy niebiesko.

1405
01:01:29,900 --> 01:01:30,720
Nie podoba nam się na czerwono.

1406
01:01:30,720 --> 01:01:33,120
Czerwień gdzie ciśnienie
podnosi się do 100%.

1407
01:01:33,120 --> 01:01:35,560
100%, teraz masz zamiar być zdławiony.

1408
01:01:35,560 --> 01:01:39,030
Więc kiedy widzisz jakieś czerwone linie, takie jak
this-- i to nie tylko Dynamo DB--

1409
01:01:39,030 --> 01:01:41,630
każda baza danych NoSQL ma ten problem.

1410
01:01:41,630 --> 01:01:44,640
Są anty-wzorce, które mogą
jazdy tego rodzaju warunkach.

1411
01:01:44,640 --> 01:01:49,070
Co mogę zrobić, to pracować z klientami
złagodzić te warunki.

1412
01:01:49,070 --> 01:01:51,840
>> A co to ma wyglądać?

1413
01:01:51,840 --> 01:01:54,260
I to jest jak najlepiej
z przepustowością Dynamo DB,

1414
01:01:54,260 --> 01:01:56,176
ale to naprawdę się
najbardziej z NoSQL.

1415
01:01:56,176 --> 01:01:58,740
Nie jest to ograniczone do Dynamo.

1416
01:01:58,740 --> 01:02:02,050
To definitely-- I
wykorzystywane do pracy w Mongo.

1417
01:02:02,050 --> 01:02:04,090
Znam wielu platformach NoSQL.

1418
01:02:04,090 --> 01:02:06,830
Każdy z nich ma te typy
gorących kluczowych problemów.

1419
01:02:06,830 --> 01:02:10,320
Aby uzyskać jak najwięcej z każdego NoSQL
bazy danych, specjalnie Dynamo DB,

1420
01:02:10,320 --> 01:02:13,320
chcesz utworzyć tabele
gdzie element klawisz krzyżyka ma

1421
01:02:13,320 --> 01:02:18,590
duża liczba różnych wartościach
wysoki stopień liczności.

1422
01:02:18,590 --> 01:02:22,530
Bo to oznacza, piszę
do wielu różnych wiadrach.

1423
01:02:22,530 --> 01:02:24,870
>> Im więcej wiadra jestem
formie pisemnej, tym bardziej prawdopodobne

1424
01:02:24,870 --> 01:02:29,100
Jestem do rozprzestrzeniania się, że obciążenie zapisu lub
czytaj załadować się na wielu węzłach,

1425
01:02:29,100 --> 01:02:33,560
tym bardziej prawdopodobne Jestem mieć
Duża przepustowość na stole.

1426
01:02:33,560 --> 01:02:37,440
A potem chcę wartości za
o dość równomiernie w czasie

1427
01:02:37,440 --> 01:02:39,430
i równomiernie losowo jak to możliwe.

1428
01:02:39,430 --> 01:02:42,410
Dobrze, że to rodzaj ciekawe,
bo nie mogę

1429
01:02:42,410 --> 01:02:43,960
kontrola, gdy użytkownicy przychodzą.

1430
01:02:43,960 --> 01:02:47,645
Więc wystarczy powiedzieć, jeśli rozprzestrzenił
rzeczy z całej przestrzeni kluczy,

1431
01:02:47,645 --> 01:02:49,270
będziemy prawdopodobnie w lepszej formie.

1432
01:02:49,270 --> 01:02:51,522
>> Jest pewien
Kwota czas dostawy

1433
01:02:51,522 --> 01:02:53,230
że nie będziemy
za kontrolę stanie.

1434
01:02:53,230 --> 01:02:55,438
Ale to są naprawdę
dwa wymiary, które posiadamy,

1435
01:02:55,438 --> 01:02:58,800
Przestrzeń, dostęp równomiernie
spread, czas, wnioski

1436
01:02:58,800 --> 01:03:01,040
planujący przyjazd rozmieszczone równomiernie w czasie.

1437
01:03:01,040 --> 01:03:03,110
A jeśli te dwa
warunki są spełnione,

1438
01:03:03,110 --> 01:03:05,610
to jest to, co to jest
będzie wyglądać.

1439
01:03:05,610 --> 01:03:07,890
To jest o wiele ładniejsza.

1440
01:03:07,890 --> 01:03:08,890
Jesteśmy tu naprawdę szczęśliwy.

1441
01:03:08,890 --> 01:03:10,432
Mamy bardzo nawet wzór dostępu.

1442
01:03:10,432 --> 01:03:13,098
Tak, może jesteś coraz
trochę ciśnienia od czasu do czasu,

1443
01:03:13,098 --> 01:03:14,830
ale nic naprawdę zbyt rozległe.

1444
01:03:14,830 --> 01:03:17,660
Więc to niesamowite, jak wiele razy,
kiedy pracuję z klientami,

1445
01:03:17,660 --> 01:03:20,670
że pierwszy wykres z wielkim czerwonym
bar i wszystko co brzydkie żółte to

1446
01:03:20,670 --> 01:03:23,147
w każdym miejscu, możemy
zrobienia z wykonywaniem

1447
01:03:23,147 --> 01:03:24,980
po kilku miesiącach
ponownego architektury

1448
01:03:24,980 --> 01:03:28,050
Uciekają dokładnie to samo
Nakład pracy dokładnie w tym samym obciążeniem.

1449
01:03:28,050 --> 01:03:30,140
I to jest to, co wygląda jak teraz.

1450
01:03:30,140 --> 01:03:36,600
Więc co się z NoSQL jest
schemat danych, który jest absolutnie

1451
01:03:36,600 --> 01:03:38,510
związane z wzorem dostępu.

1452
01:03:38,510 --> 01:03:42,170
>> I można zoptymalizować ten schemat danych
do wspierania tego wzoru dostępu.

1453
01:03:42,170 --> 01:03:45,490
Jeśli nie, to masz zamiar
aby zobaczyć te rodzaje problemów

1454
01:03:45,490 --> 01:03:46,710
z tych klawiszy skrótu.

1455
01:03:46,710 --> 01:03:50,518
>> PUBLICZNOŚCI: Cóż, z pewnością pewne miejsca
będą cieplejsze niż inne.

1456
01:03:50,518 --> 01:03:51,450
>> RICK HOULIHAN: Zawsze.

1457
01:03:51,450 --> 01:03:51,960
Zawsze.

1458
01:03:51,960 --> 01:03:54,620
Tak, mam na myśli zawsze
A-- i znowu, nie

1459
01:03:54,620 --> 01:03:56,980
niektóre wzorce projektowe dostaniemy się przez
że będą rozmawiać o tym, jak radzić sobie

1460
01:03:56,980 --> 01:03:58,480
z tych bardzo dużych skupiskach.

1461
01:03:58,480 --> 01:04:01,260
Mam na myśli, muszę je mieć,
w jaki sposób sobie z nimi radzić?

1462
01:04:01,260 --> 01:04:03,760
Mam dość dobre przypadek użycia
że będziemy rozmawiać o to.

1463
01:04:03,760 --> 01:04:05,940
>> W porządku, więc porozmawiajmy
około niektórzy klienci teraz.

1464
01:04:05,940 --> 01:04:06,950
Oni są AdRoll.

1465
01:04:06,950 --> 01:04:08,990
Nie wiem, czy jesteś
zaznajomieni z AdRoll.

1466
01:04:08,990 --> 01:04:10,781
Pewnie je zobaczyć
dużo w przeglądarce.

1467
01:04:10,781 --> 01:04:14,230
Są reklam ponownego kierowania, są
największa ogłoszenie ponownego kierowania biznesu

1468
01:04:14,230 --> 01:04:14,940
tam.

1469
01:04:14,940 --> 01:04:17,792
Zazwyczaj regularnie przejechany
60 miliardów transakcji dziennie.

1470
01:04:17,792 --> 01:04:20,000
Robią ponad milion
transakcji na sekundę.

1471
01:04:20,000 --> 01:04:22,660
Mają dość prostą tabelę
Struktura, najbardziej ruchliwych tabeli.

1472
01:04:22,660 --> 01:04:26,450
Jest to w zasadzie tylko
Klawisz skrótu jest plik cookie,

1473
01:04:26,450 --> 01:04:29,010
zakres jest demograficzna
kategoria, a następnie

1474
01:04:29,010 --> 01:04:31,220
Trzeci wymiar jest wynik.

1475
01:04:31,220 --> 01:04:33,720
>> Tak więc wszyscy mamy cookies
nasza przeglądarka z tych facetów.

1476
01:04:33,720 --> 01:04:35,900
A kiedy idziesz do
uczestnicząc kupca,

1477
01:04:35,900 --> 01:04:39,390
w zasadzie zdobyć cię przez
różne kategorie demograficzne.

1478
01:04:39,390 --> 01:04:42,070
Kiedy idziesz na stronie internetowej oraz
mówisz, że chcesz obejrzeć ten ad--

1479
01:04:42,070 --> 01:04:44,920
lub w zasadzie nie mówią that--
ale kiedy przejść do strony internetowej

1480
01:04:44,920 --> 01:04:47,550
mówią, że chcą zobaczyć to ogłoszenie.

1481
01:04:47,550 --> 01:04:49,370
I przejdź się, że reklamy z AdRoll.

1482
01:04:49,370 --> 01:04:51,130
AdRoll wygląda cię na ich stole.

1483
01:04:51,130 --> 01:04:52,115
Produkt plik cookie.

1484
01:04:52,115 --> 01:04:53,990
Reklamodawcy opowiadają
je, chcę kogoś

1485
01:04:53,990 --> 01:04:58,632
kto jest w średnim wieku,
40-letni mężczyzna, w sporcie.

1486
01:04:58,632 --> 01:05:01,590
A oni zdobyć cię w tych demografii
i zdecydować, czy

1487
01:05:01,590 --> 01:05:02,740
to dobra reklama dla Ciebie.

1488
01:05:02,740 --> 01:05:10,330
>> Teraz mają SLA z
ich dostawcy reklamowe

1489
01:05:10,330 --> 01:05:14,510
dostarczenie sub-10 milisekund
Odpowiedź na każdy wniosek.

1490
01:05:14,510 --> 01:05:16,090
Więc oni używają Dynamo DB do tego.

1491
01:05:16,090 --> 01:05:18,131
Oni uderzając nas na
milion zapytań na sekundę.

1492
01:05:18,131 --> 01:05:21,120
Oni są w stanie zrobić wszystko, ich
podglądanie, triage wszystkie te dane,

1493
01:05:21,120 --> 01:05:26,130
i uzyskać link dodaj z powrotem do
ogłoszeniodawcy w niecałe 10 milisekund.

1494
01:05:26,130 --> 01:05:29,800
To naprawdę dość fenomenalna
wdrożenie, że mają.

1495
01:05:29,800 --> 01:05:36,210
>> Ci faceci actually--
to są faceci.

1496
01:05:36,210 --> 01:05:38,010
Nie jestem pewien, czy to tych facetów.

1497
01:05:38,010 --> 01:05:40,127
Może być ci faceci.

1498
01:05:40,127 --> 01:05:42,210
W zasadzie powiedział us-- nie,
nie sądzę, że to oni.

1499
01:05:42,210 --> 01:05:43,000
Myślę, że to ktoś inny.

1500
01:05:43,000 --> 01:05:44,750
Pracowałem z
Klient, który powiedział mi,

1501
01:05:44,750 --> 01:05:47,040
że teraz, że już
poszedł do Dynamo DB, są

1502
01:05:47,040 --> 01:05:50,330
więcej pieniędzy na przekąski dla
ich zespół rozwoju co miesiąc

1503
01:05:50,330 --> 01:05:52,886
niż wydają na ich bazie.

1504
01:05:52,886 --> 01:05:54,760
Więc to daje
Pomysł z oszczędności

1505
01:05:54,760 --> 01:05:57,889
że można uzyskać w Dynamo DB jest ogromna.

1506
01:05:57,889 --> 01:05:59,430
Dobrze, dropcam inna firma.

1507
01:05:59,430 --> 01:06:02,138
To facet, trochę of-- jeśli myślisz
z Internetu rzeczy, dropcam

1508
01:06:02,138 --> 01:06:05,150
Internet Video jest w zasadzie bezpieczeństwa.

1509
01:06:05,150 --> 01:06:06,660
Możesz umieścić aparat tam.

1510
01:06:06,660 --> 01:06:08,180
Aparat jest wyposażony w czujnik ruchu.

1511
01:06:08,180 --> 01:06:10,290
Ktoś przychodzi,
wyzwala punkt cue.

1512
01:06:10,290 --> 01:06:13,540
Kamera rozpoczyna nagrywanie na chwilę aż
nie wykryje żadnego ruchu już.

1513
01:06:13,540 --> 01:06:15,310
Stawia ten film się w internecie.

1514
01:06:15,310 --> 01:06:19,800
>> Dropcam była firma, która jest
zasadniczo włączony do Dynamo DB

1515
01:06:19,800 --> 01:06:22,200
dlatego, że doświadczali
Ogromne Growing Pains.

1516
01:06:22,200 --> 01:06:25,820
A co oni powiedzieli nam,
nagle petabajtów danych.

1517
01:06:25,820 --> 01:06:28,070
Nie mieli pojęcia, z ich usług
byłby tak udany.

1518
01:06:28,070 --> 01:06:32,310
Więcej wideo przychodzące niż YouTube
jest to, co ci faceci są coraz.

1519
01:06:32,310 --> 01:06:36,780
Używają DynamoDB śledzić wszystkie
metadane wideo na wszystkich swoich kluczowych punktach.

1520
01:06:36,780 --> 01:06:40,282
>> Więc mają S3 wiadra będą forsować
wszystkie binarne artefakty język.

1521
01:06:40,282 --> 01:06:41,990
A potem mają
Zapisy Dynamo DB, że

1522
01:06:41,990 --> 01:06:44,070
wskazać osoby do tych S3 trzech obiektów.

1523
01:06:44,070 --> 01:06:47,070
Kiedy trzeba spojrzeć na wideo,
patrzą się na zapis w Dynamo DB.

1524
01:06:47,070 --> 01:06:47,903
Kliknięciu łącza.

1525
01:06:47,903 --> 01:06:49,770
Są one rozwijane wideo z S3.

1526
01:06:49,770 --> 01:06:51,590
Więc to jest trochę, jak to wygląda.

1527
01:06:51,590 --> 01:06:53,580
I to jest prosto z ich zespołu.

1528
01:06:53,580 --> 01:06:56,010
>> Dynamo DB zmniejsza ich
czas dostawy do wydarzeń wideo

1529
01:06:56,010 --> 01:06:57,590
od pięciu do 10 sekund.

1530
01:06:57,590 --> 01:07:00,470
W swoim starym sklepie relacyjnej,
kiedyś trzeba iść i wykonać

1531
01:07:00,470 --> 01:07:03,780
wielu złożonych zapytań do rysunku
się, które filmy do ciągnięcia w dół,

1532
01:07:03,780 --> 01:07:06,690
do mniej niż 50 milisekund.

1533
01:07:06,690 --> 01:07:08,990
Więc to jest niesamowite, niesamowite
ile wydajność

1534
01:07:08,990 --> 01:07:12,990
można uzyskać po optymalizacji i
dostroić instrument bazowy w bazie

1535
01:07:12,990 --> 01:07:15,110
wspierać wzór dostępu.

1536
01:07:15,110 --> 01:07:20,500
Halfbrick, ci faceci, co to jest,
Fruit Ninja Chyba jest ich sprawa.

1537
01:07:20,500 --> 01:07:22,590
Że wszystkie działa na Dynamo DB.

1538
01:07:22,590 --> 01:07:26,810
A ci faceci są doskonałym
Zespół programistów, wielki rozwój

1539
01:07:26,810 --> 01:07:27,670
robić zakupy.

1540
01:07:27,670 --> 01:07:29,364
>> Nie jest to dobry zespół ops.

1541
01:07:29,364 --> 01:07:31,280
Oni nie mają wiele
zasobów pracy.

1542
01:07:31,280 --> 01:07:33,940
Oni walczą stara się utrzymać
ich infrastruktury do aplikacji

1543
01:07:33,940 --> 01:07:34,290
i działa.

1544
01:07:34,290 --> 01:07:35,000
Przyszli do nas.

1545
01:07:35,000 --> 01:07:36,251
Patrzyli na tym Dynamo DB.

1546
01:07:36,251 --> 01:07:37,291
Powiedzieli, że to dla nas.

1547
01:07:37,291 --> 01:07:39,470
Oni zbudowali całość
framework aplikacji na nim.

1548
01:07:39,470 --> 01:07:43,640
Kilka naprawdę dobrych komentarze tutaj
od zespołu na ich zdolności

1549
01:07:43,640 --> 01:07:46,800
się teraz skupić na budynku
gry i nie

1550
01:07:46,800 --> 01:07:49,010
konieczności utrzymania
infrastruktury, która

1551
01:07:49,010 --> 01:07:51,910
stawało się ogromna ilość
narzutu dla swojego zespołu.

1552
01:07:51,910 --> 01:07:56,170
Więc to jest coś that--
korzyści, które można uzyskać z Dynamo DB.

1553
01:07:56,170 --> 01:08:00,930
>> Dobrze, dostania się do
Modelowanie tutaj dane.

1554
01:08:00,930 --> 01:08:03,440
Rozmawialiśmy trochę o
ten jeden do jednego, jeden do wielu,

1555
01:08:03,440 --> 01:08:05,060
i wiele do wielu relacji typu.

1556
01:08:05,060 --> 01:08:07,630
A jak utrzymać te w Dynamo.

1557
01:08:07,630 --> 01:08:10,500
W Dynamo DB używamy
indeksy, ogólnie rzecz biorąc,

1558
01:08:10,500 --> 01:08:12,910
obracać się dane z
jednego aromatu do drugiej.

1559
01:08:12,910 --> 01:08:15,210
Hash klucze, klucze zakres i indeksów.

1560
01:08:15,210 --> 01:08:18,540
>> W tym szczególnym
Przykładem, jak w większości państw

1561
01:08:18,540 --> 01:08:23,802
mają wymóg licencjonowania
tylko jedno prawo jazdy za osobę.

1562
01:08:23,802 --> 01:08:26,510
Nie można się tam dostać dwa kierowcy
licencji w stanie Bostonie.

1563
01:08:26,510 --> 01:08:27,500
Nie mogę tego zrobić w Teksasie.

1564
01:08:27,500 --> 01:08:28,708
To rodzaj drogi jest.

1565
01:08:28,708 --> 01:08:32,779
I tak w DMV, mamy wyszukiwań, że
chcę patrzeć na prawo jazdy

1566
01:08:32,779 --> 01:08:35,180
numer ubezpieczenia społecznego.

1567
01:08:35,180 --> 01:08:39,990
Chcę spojrzeć na dane użytkownika
według numeru licencji kierowcy.

1568
01:08:39,990 --> 01:08:43,620
>> Więc możemy mieć stolik użytkownika, że
ma klawisza skrótu na numer seryjny,

1569
01:08:43,620 --> 01:08:47,830
lub numer ubezpieczenia społecznego, a
różne atrybuty zdefiniowane w pkt.

1570
01:08:47,830 --> 01:08:49,859
Teraz na tej tabeli I
może zdefiniować GSI, że

1571
01:08:49,859 --> 01:08:53,370
koziołki, że ok, że mówi, że chce
klawisz skrótu na licencji, a następnie

1572
01:08:53,370 --> 01:08:54,252
wszystkie pozostałe elementy.

1573
01:08:54,252 --> 01:08:57,210
Teraz, jeśli chcę zapytać i znaleźć
Numer licencji dla danego Społecznych

1574
01:08:57,210 --> 01:08:59,609
Numer ubezpieczenia, mogę
zapytania główną tabelę.

1575
01:08:59,609 --> 01:09:02,130
>> Jeśli chcę zapytać i chcę
aby uzyskać ubezpieczenie społeczne

1576
01:09:02,130 --> 01:09:05,735
numer lub inne atrybuty przez
Numer licencji mogę kwerendy GSI.

1577
01:09:05,735 --> 01:09:08,689
Model ten jest, że jeden
do jednego związku.

1578
01:09:08,689 --> 01:09:12,460
Po prostu bardzo proste GSI,
odwrócić te rzeczy wokół.

1579
01:09:12,460 --> 01:09:13,979
Teraz mówimy o jednym z wielu.

1580
01:09:13,979 --> 01:09:16,450
Jednym z wielu jest w zasadzie
klucz Zakres hash.

1581
01:09:16,450 --> 01:09:20,510
W przypadku, gdy mamy dużo z tym
przypadek użycia jest dane monitora.

1582
01:09:20,510 --> 01:09:23,880
Dane monitor jest w regularnych
odstęp, jak internet rzeczy.

1583
01:09:23,880 --> 01:09:26,890
Zawsze się to wszystko
Zapisy w najbliższych cały czas.

1584
01:09:26,890 --> 01:09:31,420
>> I chcę, aby znaleźć wszystkie odczyty
między danym okresie czasu.

1585
01:09:31,420 --> 01:09:34,220
Jest to bardzo częste pytanie w
infrastruktury monitorowania.

1586
01:09:34,220 --> 01:09:38,430
Sposób, w jaki go o to, aby znaleźć
proste struktury tabeli, jeden stół.

1587
01:09:38,430 --> 01:09:42,250
Mam tabelę pomiarów urządzeń
pomocą krzyżyka na ID urządzenia.

1588
01:09:42,250 --> 01:09:47,340
I mam klucza gama na
datownik, lub w tym przypadku, epicki.

1589
01:09:47,340 --> 01:09:50,350
A to pozwala mi wykonywać kompleks
Zapytania przeciwko tym kluczem Zakres

1590
01:09:50,350 --> 01:09:54,950
i powrócić te rekordy, które
odnoszą się do wyników

1591
01:09:54,950 --> 01:09:56,310
ustawić, że szukam.

1592
01:09:56,310 --> 01:09:58,360
I buduje, że jeden
do wielu relacji

1593
01:09:58,360 --> 01:10:02,340
w tabeli podstawowej przy użyciu
klawisz krzyżyka, struktura kluczowym zakres.

1594
01:10:02,340 --> 01:10:04,600
>> Więc to rodzaj zbudowany
do tabeli w Dynamo DB.

1595
01:10:04,600 --> 01:10:07,290
Kiedy zdefiniować hash
i zakres t stołowy, jestem

1596
01:10:07,290 --> 01:10:09,240
definiując jeden do wielu relacji.

1597
01:10:09,240 --> 01:10:12,770
Jest to relacja rodzic-dziecko.

1598
01:10:12,770 --> 01:10:14,620
>> Porozmawiajmy o wiele
do wielu relacji.

1599
01:10:14,620 --> 01:10:19,170
I w tym konkretnym przykładzie,
znowu, będziemy używać GSi.

1600
01:10:19,170 --> 01:10:23,500
I porozmawiajmy o grach
scenariusz, w którym mam danego użytkownika.

1601
01:10:23,500 --> 01:10:26,500
Chcę dowiedzieć się, wszystkie gry, które
on zarejestrowany lub grając w.

1602
01:10:26,500 --> 01:10:29,600
I dla danej gry, ja
chcą znaleźć wszystkich użytkowników.

1603
01:10:29,600 --> 01:10:31,010
Więc jak to zrobić?

1604
01:10:31,010 --> 01:10:34,330
Moja tabela gry użytkownika, zamierzam
mieć klucz hash ID użytkownika

1605
01:10:34,330 --> 01:10:35,810
oraz kluczowy zakres gry.

1606
01:10:35,810 --> 01:10:37,810
>> Tak więc użytkownik może mieć wiele gier.

1607
01:10:37,810 --> 01:10:41,380
Jest to jedna z wielu relacji między
użytkownik i gry, które gra.

1608
01:10:41,380 --> 01:10:43,410
A następnie na GSI,
Będę odwrócić, że ok.

1609
01:10:43,410 --> 01:10:46,679
Będę hash na grze i
Będę wahać od użytkownika.

1610
01:10:46,679 --> 01:10:48,970
Więc jeśli chcę uzyskać wszystkie
Gra użytkownik gra w,

1611
01:10:48,970 --> 01:10:49,950
Będę zapytania główną tabelę.

1612
01:10:49,950 --> 01:10:52,699
Jeśli chcę uzyskać wszystkich użytkowników
które odgrywają szczególną grę,

1613
01:10:52,699 --> 01:10:53,887
I kwerendy GSI.

1614
01:10:53,887 --> 01:10:54,970
Więc widzisz, jak to zrobić?

1615
01:10:54,970 --> 01:10:58,369
Budujesz je GSi do wsparcia
przypadek użycia, aplikacja, dostęp

1616
01:10:58,369 --> 01:10:59,410
wzór, aplikacja.

1617
01:10:59,410 --> 01:11:01,440
>> Jeśli muszę zapytać o
ten wymiar, niech

1618
01:11:01,440 --> 01:11:03,500
mi stworzyć indeks na tym wymiarze.

1619
01:11:03,500 --> 01:11:05,850
Jeśli nie, mnie to nie obchodzi.

1620
01:11:05,850 --> 01:11:09,060
I w zależności od przypadku użycia, I
może potrzebować indeksu albo i nie.

1621
01:11:09,060 --> 01:11:12,390
Jeśli jest to proste, jeden do wielu,
pierwsza tabela jest w porządku.

1622
01:11:12,390 --> 01:11:15,860
Jeśli muszę zrobić to wielu
wiele, albo muszę zrobić jedną do nich,

1623
01:11:15,860 --> 01:11:18,390
to może ja potrzebuję
do drugiej indeks.

1624
01:11:18,390 --> 01:11:20,840
Więc wszystko zależy od
co próbuję zrobić

1625
01:11:20,840 --> 01:11:24,550
i co staram się uzyskać znakomity.

1626
01:11:24,550 --> 01:11:28,000
>> Prawdopodobnie nie będę wydawać zbyt
dużo czasu rozmawiając o dokumentach.

1627
01:11:28,000 --> 01:11:31,460
To staje się trochę, chyba,
głębiej niż potrzebujemy, aby przejść do.

1628
01:11:31,460 --> 01:11:33,710
Porozmawiajmy trochę
o bogatym wyrażenie kwerendy.

1629
01:11:33,710 --> 01:11:37,831
Tak więc w Dynamo DB mamy
możliwość tworzenia

1630
01:11:37,831 --> 01:11:39,330
co nazywamy wyrażenia projekcji.

1631
01:11:39,330 --> 01:11:42,660
Wyrażenia projekcyjne są po prostu
zbieranie pola lub wartości

1632
01:11:42,660 --> 01:11:44,290
które chcesz wyświetlić.

1633
01:11:44,290 --> 01:11:46,000
OK, więc dokonać wyboru.

1634
01:11:46,000 --> 01:11:48,010
Robię zapytanie przeciwko Dynamo DB.

1635
01:11:48,010 --> 01:11:51,730
A ja mówię, wiesz co, pokaż
mnie tylko pięciogwiazdkowe recenzje

1636
01:11:51,730 --> 01:11:54,544
dla danego wyrobu.

1637
01:11:54,544 --> 01:11:55,710
Więc to wszystko, co chcą zobaczyć.

1638
01:11:55,710 --> 01:11:57,320
Nie chcę, aby zobaczyć wszystkie
inne atrybuty rzędu,

1639
01:11:57,320 --> 01:11:58,319
Chcę po prostu zobaczyć.

1640
01:11:58,319 --> 01:12:01,209
To tak jak w SQL, gdy
powiedzieć, wybierz gwiazdę lub z tabeli,

1641
01:12:01,209 --> 01:12:02,000
masz wszystko.

1642
01:12:02,000 --> 01:12:05,450
Kiedy mówię, wybierz nazwę z
Stół, mam jeden atrybut tylko.

1643
01:12:05,450 --> 01:12:09,070
To ten sam rodzaj rzeczy w
Dynamo DB lub inny bazy NoSQL.

1644
01:12:09,070 --> 01:12:14,510
Wyrażenia filtrujące pozwalają mi
w zasadzie cięcia zestaw wyników w dół.

1645
01:12:14,510 --> 01:12:15,540
Więc robię zapytanie.

1646
01:12:15,540 --> 01:12:17,260
Zapytanie może wrócić z 500 pozycji.

1647
01:12:17,260 --> 01:12:20,255
Ale chcę tylko te elementy, które
mieć atrybut, który mówi to.

1648
01:12:20,255 --> 01:12:23,380
OK, więc niech to odfiltrować te pozycje
które nie pasują tego konkretnego zapytania.

1649
01:12:23,380 --> 01:12:25,540
Mamy więc wyrażeń filtrujących.

1650
01:12:25,540 --> 01:12:28,310
>> Wyrażenia filtr może
uruchomić na dowolnym atrybutem.

1651
01:12:28,310 --> 01:12:30,260
Oni nie lubią zapytań zasięgu.

1652
01:12:30,260 --> 01:12:32,690
Raise pytania są bardziej selektywne.

1653
01:12:32,690 --> 01:12:36,470
Zapytania filtrujące wymagają mi iść
Wyniki się cały zestaw, a następnie

1654
01:12:36,470 --> 01:12:39,170
wykroić dane nie chcę.

1655
01:12:39,170 --> 01:12:40,660
Dlaczego to jest ważne?

1656
01:12:40,660 --> 01:12:42,770
Bo czytam to wszystko.

1657
01:12:42,770 --> 01:12:46,597
W zapytaniu, będę czytać i
to będzie olbrzymi temat danych.

1658
01:12:46,597 --> 01:12:48,430
A potem mam zamiar
wykroić co muszę.

1659
01:12:48,430 --> 01:12:52,080
A jeśli jestem tylko pominięcia
Kilka wierszy, to to jest OK.

1660
01:12:52,080 --> 01:12:53,620
To nie jest tak nieskuteczny.

1661
01:12:53,620 --> 01:12:57,800
>> Ale jeśli czytam cały stos
Dane, żeby wykroić jeden przedmiot,

1662
01:12:57,800 --> 01:13:01,490
potem mam zamiar być lepiej
przy użyciu kwerendy zakresu,

1663
01:13:01,490 --> 01:13:03,030
dlatego, że jest o wiele bardziej selektywny.

1664
01:13:03,030 --> 01:13:06,330
To uratuje mi dużo
pieniądze, bo płacić za tego odczytu.

1665
01:13:06,330 --> 01:13:10,430
Jeżeli wyniki testów, które wraca
przejdę ten przewód może być mniejsza,

1666
01:13:10,430 --> 01:13:11,890
ale ja płacę za odczytu.

1667
01:13:11,890 --> 01:13:14,340
Więc rozumiem, jak
dostajesz dane.

1668
01:13:14,340 --> 01:13:16,420
To bardzo ważne w Dynamo DB.

1669
01:13:16,420 --> 01:13:19,710
>> Wyrażenia warunkowe, jest to, co
można nazwać optymistycznego blokowania.

1670
01:13:19,710 --> 01:13:28,470
Aktualizacja IF EXISTS, czy ta wartość
jest odpowiednikiem tego, co mogę określić.

1671
01:13:28,470 --> 01:13:31,494
A jeśli mam znacznik czasu na
zapis, że mogę odczytać danych.

1672
01:13:31,494 --> 01:13:32,535
Może zmienić te dane.

1673
01:13:32,535 --> 01:13:35,030
Może pójdę napisać, że
Dane z powrotem do bazy.

1674
01:13:35,030 --> 01:13:38,100
Jeśli ktoś zmienił zapis,
datownik mogła ulec zmianie.

1675
01:13:38,100 --> 01:13:40,370
I w ten sposób moja warunkowa
Aktualizacja mógł powiedzieć aktualizacji

1676
01:13:40,370 --> 01:13:42,340
jeśli znacznik czasu wynosi w tym.

1677
01:13:42,340 --> 01:13:46,290
Albo aktualizacja nie powiedzie się, ponieważ ktoś
zaktualizowała rekord w międzyczasie.

1678
01:13:46,290 --> 01:13:48,290
>> To, co nazywamy optymistycznego blokowania.

1679
01:13:48,290 --> 01:13:50,670
Oznacza to, że ktoś
może przyjść i go zmienić,

1680
01:13:50,670 --> 01:13:53,100
i mam zamiar go wykryć
kiedy wrócę do pisania.

1681
01:13:53,100 --> 01:13:56,106
I wtedy rzeczywiście mogę przeczytać, że
Dane i powiedzieć, oh, on zmienił to.

1682
01:13:56,106 --> 01:13:57,230
Muszę wyjaśnić, że.

1683
01:13:57,230 --> 01:14:00,490
I mogę zmienić dane w moim
nagrywanie i zastosować kolejną aktualizację.

1684
01:14:00,490 --> 01:14:04,330
Więc można złapać tych, przyrostowe
aktualizacje, które występują pomiędzy czasem

1685
01:14:04,330 --> 01:14:08,740
zapoznanie się dane, i
Czas można zapisać dane.

1686
01:14:08,740 --> 01:14:11,520
>> PUBLICZNOŚCI: A filtr
wyraz w rzeczywistości nie oznacza

1687
01:14:11,520 --> 01:14:13,020
numer lub not--

1688
01:14:13,020 --> 01:14:14,316
>> [Wstawienie GŁOSY]

1689
01:14:14,316 --> 01:14:16,232
RICK HOULIHAN: nie powiem
zbyt wiele do tego.

1690
01:14:16,232 --> 01:14:17,700
To jest zarezerwowane słowo kluczowe.

1691
01:14:17,700 --> 01:14:20,130
Widok funt jest zastrzeżone
kluczowe w Dynamo DB.

1692
01:14:20,130 --> 01:14:24,500
Każdy ma swoje własne bazy danych zastrzeżone
Nazwy zbiorów nie można używać.

1693
01:14:24,500 --> 01:14:27,240
Dynamo DB, jeśli podasz
funta przed tym,

1694
01:14:27,240 --> 01:14:29,310
można określić te nazwy się powyżej.

1695
01:14:29,310 --> 01:14:31,840
Jest to odniesienie wartości.

1696
01:14:31,840 --> 01:14:34,880
To chyba nie najlepszy składni
mają tam do tej dyskusji,

1697
01:14:34,880 --> 01:14:38,090
dlatego, że dostanie się do niektórych real--
I byłoby mówić więcej

1698
01:14:38,090 --> 01:14:41,360
o, że na głębszym poziomie.

1699
01:14:41,360 --> 01:14:46,130
>> Ale wystarczy powiedzieć, może to
być kwerendy skanowania gdzie views--

1700
01:14:46,130 --> 01:14:50,190
ani poglądy funta jest większa niż 10.

1701
01:14:50,190 --> 01:14:54,660
Jest to wartość liczbowa, tak.

1702
01:14:54,660 --> 01:14:57,322
Jeśli chcesz, możemy mówić o
które po dyskusji.

1703
01:14:57,322 --> 01:15:00,030
W porządku, więc pakujesz
Niektóre scenariusze w najlepszych praktyk

1704
01:15:00,030 --> 01:15:02,000
gdzie będziemy rozmawiać
tutaj o niektórych aplikacji.

1705
01:15:02,000 --> 01:15:03,810
Co to są przypadki użycia dla Dynamo DB.

1706
01:15:03,810 --> 01:15:06,120
Co to projektowanie
wzory w Dynamo DB.

1707
01:15:06,120 --> 01:15:09,110
>> I pierwszy będziemy
Dyskusja na temat jest internet rzeczy.

1708
01:15:09,110 --> 01:15:15,010
Tak więc mamy dużo of-- Chyba,
co jest it-- więcej niż 50%

1709
01:15:15,010 --> 01:15:19,370
ruchu w Internecie tych dni
jest faktycznie generowany przez maszyny,

1710
01:15:19,370 --> 01:15:21,930
zautomatyzowane procesy, nie przez ludzi.

1711
01:15:21,930 --> 01:15:25,140
Mam na myśli to coś, co się tam
nosisz w kieszeni,

1712
01:15:25,140 --> 01:15:28,840
jak dużo danych, że jest to
rzeczywistości wysyła się bez Ciebie

1713
01:15:28,840 --> 01:15:30,550
wiedząc, że jest absolutnie niesamowite.

1714
01:15:30,550 --> 01:15:34,970
Twoja lokalizacja, informacje
o tym, jak szybko jedziesz.

1715
01:15:34,970 --> 01:15:38,400
Jak myślisz, Google Maps działa
kiedy powiedzieć, co jest ruch.

1716
01:15:38,400 --> 01:15:41,275
To dlatego, że są miliony i
miliony ludzi jazdy wokół

1717
01:15:41,275 --> 01:15:44,667
z telefonów, które są wysyłających
Dane całym miejscu przez cały czas.

1718
01:15:44,667 --> 01:15:46,500
Tak więc jedną z rzeczy,
o tego typu danych

1719
01:15:46,500 --> 01:15:50,980
że jest w dane monitora, zalogować
Dane, dane szeregów czasowych, jest to

1720
01:15:50,980 --> 01:15:53,540
zwykle tylko interesujące
na trochę czasu.

1721
01:15:53,540 --> 01:15:55,580
Po tym czasie, to
nie tak interesujące.

1722
01:15:55,580 --> 01:15:58,390
Więc rozmawialiśmy, nie pozwól
te tabele rozwijać się bez granic.

1723
01:15:58,390 --> 01:16:03,410
Chodzi o to, że być może mam 24
Godziny warto wydarzeń w moim gorącym stole.

1724
01:16:03,410 --> 01:16:06,160
I to gorący stół będzie
zabezpieczony na bardzo wysokim poziomie,

1725
01:16:06,160 --> 01:16:07,950
bo to zabiera dużo danych.

1726
01:16:07,950 --> 01:16:10,920
To zabiera dużo danych
i czytam to dużo.

1727
01:16:10,920 --> 01:16:14,560
Mam dużo pracy
Zapytania uruchomione przed tymi danymi.

1728
01:16:14,560 --> 01:16:18,120
>> Po 24 godzinach, hej,
wiesz co, mnie to nie obchodzi.

1729
01:16:18,120 --> 01:16:21,150
Więc może ja codziennie o północy rolki
mój stół na nowy stół

1730
01:16:21,150 --> 01:16:22,430
a ja deprovision tej tabeli.

1731
01:16:22,430 --> 01:16:26,440
I wezmę Pilot i
Się na wózek, ponieważ po 24 godzinach

1732
01:16:26,440 --> 01:16:28,630
Nie uciekam jak wielu
Zapytania przeciwko tym danych.

1733
01:16:28,630 --> 01:16:30,200
Więc mam zamiar zaoszczędzić pieniądze.

1734
01:16:30,200 --> 01:16:32,940
A może 30 dni później, ja nie
nawet trzeba dbać o to wszystko.

1735
01:16:32,940 --> 01:16:35,020
Mogłem wziąć WCU na
w dół do jednego,

1736
01:16:35,020 --> 01:16:36,990
bo wiesz co, to
nigdy nie dostanie zapisywane.

1737
01:16:36,990 --> 01:16:38,300
Dane jest 30 dni.

1738
01:16:38,300 --> 01:16:40,000
To nigdy się nie zmienia.

1739
01:16:40,000 --> 01:16:44,200
>> I to prawie nigdy nie będzie się czytać,
więc niech po prostu przyjąć, że pilocie do 10.

1740
01:16:44,200 --> 01:16:49,372
A ja oszczędzając mnóstwo pieniędzy na ten temat
Dane i tylko płacić za moich gorących danych.

1741
01:16:49,372 --> 01:16:52,330
Więc to jest ważna rzecz, szukać
co, jeśli spojrzeć na szeregu czasowego

1742
01:16:52,330 --> 01:16:54,716
danych pochodzących w objętości.

1743
01:16:54,716 --> 01:16:55,590
Są to strategie.

1744
01:16:55,590 --> 01:16:58,010
Teraz mogę tylko niech go
wszyscy trafiają do tej samej tabeli

1745
01:16:58,010 --> 01:16:59,461
i po prostu pozwól, że tabela rosną.

1746
01:16:59,461 --> 01:17:01,460
W końcu będę
zobacz problemy z wydajnością.

1747
01:17:01,460 --> 01:17:04,060
Mam zamiar zacząć archiwizować
niektóre z tych danych ze stołu,

1748
01:17:04,060 --> 01:17:04,720
etażerka.

1749
01:17:04,720 --> 01:17:07,010
>> Miejmy znacznie lepiej
projektowania aplikacji

1750
01:17:07,010 --> 01:17:08,900
tak, że można pracować w ten sposób prawo.

1751
01:17:08,900 --> 01:17:11,460
Więc to tylko automatyczne
w kodzie aplikacji.

1752
01:17:11,460 --> 01:17:13,580
O północy każdej nocy
toczy się w tabeli.

1753
01:17:13,580 --> 01:17:17,170
Może to, co potrzebne jest przesuwne
Okno 24 godzin danych.

1754
01:17:17,170 --> 01:17:20,277
Potem regularnie jestem
dzwoniąc dane ze stołu.

1755
01:17:20,277 --> 01:17:22,360
Jestem przycinanie go z
Cron i Kładę go

1756
01:17:22,360 --> 01:17:24,160
na tych innych tabel,
co trzeba.

1757
01:17:24,160 --> 01:17:25,940
Więc jeśli rollover działa, to świetnie.

1758
01:17:25,940 --> 01:17:27,080
Jeśli nie, przyciąć go.

1759
01:17:27,080 --> 01:17:29,640
Ale trzymajmy że gorące dane
z dala od zimnych danych.

1760
01:17:29,640 --> 01:17:32,535
Będzie to zaoszczędzić dużo pieniędzy i
Nakręć Stoły wykonywania.

1761
01:17:32,535 --> 01:17:35,960

1762
01:17:35,960 --> 01:17:38,210
Więc następną rzeczą, będziemy rozmawiać
o jest w katalogu.

1763
01:17:38,210 --> 01:17:42,000
Katalog wyrobów jest
dość powszechne przypadek użycia.

1764
01:17:42,000 --> 01:17:46,600
To jest rzeczywiście bardzo często wzór
które zobaczymy w różnych rzeczy.

1765
01:17:46,600 --> 01:17:48,870
Wiesz, Twitter dla
Przykładem, gorący tweet.

1766
01:17:48,870 --> 01:17:51,280
Wszyscy przychodzą i
chwytając ten tweet.

1767
01:17:51,280 --> 01:17:52,680
Katalog wyrobów dostałem sprzedaży.

1768
01:17:52,680 --> 01:17:54,120
Mam gorącą sprzedaż.

1769
01:17:54,120 --> 01:17:57,277
Mam 70.000 żądań na
drugie przyjście na produkt

1770
01:17:57,277 --> 01:17:58,860
Opis z katalogu mojego produktu.

1771
01:17:58,860 --> 01:18:02,384
Widzimy to w handlu detalicznym
Operacja trochę.

1772
01:18:02,384 --> 01:18:03,550
Jak więc sobie z tym poradzić?

1773
01:18:03,550 --> 01:18:04,924
Nie sposób sobie z tym poradzić.

1774
01:18:04,924 --> 01:18:07,110
Wszyscy moi użytkownicy chcą zobaczyć
tego samego kawałka danych.

1775
01:18:07,110 --> 01:18:09,410
Oni są w najbliższych, jednocześnie.

1776
01:18:09,410 --> 01:18:11,920
I oni wszyscy żądaniach
z tego samego kawałka danych.

1777
01:18:11,920 --> 01:18:16,240
To daje mi, że klawisz skrótu, że duża czerwona
pasek na moim wykresie, że nam się nie podoba.

1778
01:18:16,240 --> 01:18:17,720
A to, co to wygląda.

1779
01:18:17,720 --> 01:18:22,290
Więc po mojej przestrzeni kluczy Dostaję
młotkiem w sprzedaży przedmiotów.

1780
01:18:22,290 --> 01:18:24,070
Dostaję nic nigdzie indziej.

1781
01:18:24,070 --> 01:18:26,050
>> Jak mogę złagodzić ten problem?

1782
01:18:26,050 --> 01:18:28,410
Cóż, możemy złagodzić to z pamięci podręcznej.

1783
01:18:28,410 --> 01:18:33,630
Cache, można umieścić w zasadzie w pamięci
partycji przed danych.

1784
01:18:33,630 --> 01:18:37,260
Udało nam
[Niesłyszalne] cache, jak ci

1785
01:18:37,260 --> 01:18:40,260
Można założyć własną pamięć podręczną, [niesłyszalne]
kryjówka [? d,?], co chcesz.

1786
01:18:40,260 --> 01:18:42,220
Umieścić, że w przedniej części danych.

1787
01:18:42,220 --> 01:18:47,250
I w ten sposób można przechowywać te dane
z tych gorących klawiszy w górę w tej pamięci podręcznej

1788
01:18:47,250 --> 01:18:49,390
przestrzeń i przeczytać pamięci podręcznej.

1789
01:18:49,390 --> 01:18:51,962
>> I wtedy większość swojego czyta
zacząć patrzeć w ten sposób.

1790
01:18:51,962 --> 01:18:54,920
Mam wszystkie te cache uderza się tutaj
i ja nic nie dzieje się tutaj

1791
01:18:54,920 --> 01:18:59,330
ponieważ baza danych jest siedział za
pamięci podręcznej i nigdy nie czyta przechodzą.

1792
01:18:59,330 --> 01:19:02,520
Jeśli zmienić dane w
bazy danych, mam do aktualizacji pamięci podręcznej.

1793
01:19:02,520 --> 01:19:04,360
Możemy użyć czegoś
jak paruje to zrobić.

1794
01:19:04,360 --> 01:19:07,360
I postaram się wyjaśnić, jak to działa.

1795
01:19:07,360 --> 01:19:09,060
Dobrze, wiadomości.

1796
01:19:09,060 --> 01:19:11,180
E-mail, wszyscy korzystają z poczty elektronicznej.

1797
01:19:11,180 --> 01:19:12,540
>> Jest to bardzo dobry przykład.

1798
01:19:12,540 --> 01:19:14,950
Mamy jakieś wiadomości tabeli.

1799
01:19:14,950 --> 01:19:17,040
I mamy skrzynki odbiorczej i nadawczej.

1800
01:19:17,040 --> 01:19:19,760
To jest to, co SQL będzie
wyglądają jak zbudować tę skrzynkę.

1801
01:19:19,760 --> 01:19:23,350
W pewien sposób korzystać z tego samego rodzaju
strategii wykorzystania GSi, GSi

1802
01:19:23,350 --> 01:19:25,320
dla mojej skrzynce odbiorczej i mojej skrzynce nadawczej.

1803
01:19:25,320 --> 01:19:27,600
Więc mam surowe wiadomości nadchodzi
do mojego tabeli wiadomości.

1804
01:19:27,600 --> 01:19:30,194
I pierwsze podejście do tego
może być, powiedzmy, OK, nie ma problemu.

1805
01:19:30,194 --> 01:19:31,110
Mam surowe wiadomości.

1806
01:19:31,110 --> 01:19:33,710
Wiadomości pochodzące [niesłyszalne],
Komunikat ID, to świetnie.

1807
01:19:33,710 --> 01:19:35,070
To mój unikalny hash.

1808
01:19:35,070 --> 01:19:38,280
Mam zamiar stworzyć dwa GSi, jeden
dla mojej skrzynce odbiorczej, jeden dla mojej skrzynce nadawczej.

1809
01:19:38,280 --> 01:19:40,530
I pierwszą rzeczą, zrobię
Powiem jest mój klucz do skrótu

1810
01:19:40,530 --> 01:19:43,310
będzie odbiorcą i
Mam zamiar zorganizować w dniu.

1811
01:19:43,310 --> 01:19:44,220
To jest fantastyczne.

1812
01:19:44,220 --> 01:19:45,890
Dostałem ładny widok tutaj.

1813
01:19:45,890 --> 01:19:47,780
Ale jest trochę problem tutaj.

1814
01:19:47,780 --> 01:19:50,891
I napotkasz to w
relacyjnych baz danych, jak również.

1815
01:19:50,891 --> 01:19:52,390
Nazwali pionowo partycjonowania.

1816
01:19:52,390 --> 01:19:55,840
Chcesz zachować swój wielki dane
z dala od małych danych.

1817
01:19:55,840 --> 01:20:00,470
>> I dlatego to, bo muszę
go przeczytać przedmiotów, aby uzyskać atrybuty.

1818
01:20:00,470 --> 01:20:05,570
A jeśli moje ciało jest tu wszystko,
Następnie czyta tylko kilka elementów

1819
01:20:05,570 --> 01:20:08,560
jeśli długość ciała jest
średnio 256 kilobajtów każdy,

1820
01:20:08,560 --> 01:20:10,991
matematyka staje się dość brzydki.

1821
01:20:10,991 --> 01:20:12,490
Tak mówią Chcę przeczytać skrzynkę Dawida.

1822
01:20:12,490 --> 01:20:14,520
Skrzynka Dawida ma 50 przedmiotów.

1823
01:20:14,520 --> 01:20:17,880
Średni i wielkość to 256 kilobajtów.

1824
01:20:17,880 --> 01:20:21,730
Oto mój współczynnik konwersji
dla RCU jest cztery kilobajtów.

1825
01:20:21,730 --> 01:20:24,450
>> OK, idziemy z
w końcu zgodne czyta.

1826
01:20:24,450 --> 01:20:28,640
Jestem nadal jeść 1600 Pilot na
tylko do odczytu skrzynki Dawida.

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

1828
01:20:29,950 --> 01:20:31,980
OK, teraz pomyślmy
o tym, jak działa aplikacja.

1829
01:20:31,980 --> 01:20:35,340
Jeśli jestem w aplikacji e-mail i
Patrzę na mojej skrzynce odbiorczej,

1830
01:20:35,340 --> 01:20:39,680
i patrzę na ciele każdej wiadomości,
Nie, patrzę na zestawieniach.

1831
01:20:39,680 --> 01:20:41,850
Patrzę na tylko nagłówki.

1832
01:20:41,850 --> 01:20:46,310
Warto więc budować struktury tabeli
że wygląda bardziej tak.

1833
01:20:46,310 --> 01:20:49,470
>> Więc oto informacje
że mój workflow potrzebuje.

1834
01:20:49,470 --> 01:20:50,890
Jest w mojej skrzynce odbiorczej GSI.

1835
01:20:50,890 --> 01:20:53,800
Jest to data, nadawca,
przedmiotem, a następnie

1836
01:20:53,800 --> 01:20:56,790
identyfikator wiadomość, która wskazuje
z powrotem do tabeli wiadomości

1837
01:20:56,790 --> 01:20:57,850
gdzie mogę dostać się do organizmu.

1838
01:20:57,850 --> 01:21:01,260

1839
01:21:01,260 --> 01:21:04,420
Cóż, to byłby rekord identyfikatory.

1840
01:21:04,420 --> 01:21:09,850
Oni wskazują z powrotem do
Identyfikatory pozycja w tabeli Dynamo DB.

1841
01:21:09,850 --> 01:21:12,220
Każdy wskaźnik zawsze creates--
zawsze pozycję

1842
01:21:12,220 --> 01:21:15,750
ID jako część of--, że
pochodzi z indeksu.

1843
01:21:15,750 --> 01:21:17,414
>> W porządku.

1844
01:21:17,414 --> 01:21:19,080
PUBLICZNOŚCI: Mówi się, gdzie jest przechowywane?

1845
01:21:19,080 --> 01:21:21,420
RICK HOULIHAN: Tak, to mówi
exactly-- to jest dokładnie to, co robi.

1846
01:21:21,420 --> 01:21:22,644
Mówi tu jest mój rekord ponownie.

1847
01:21:22,644 --> 01:21:24,310
I to będzie skierować go z powrotem do mojego rekordu re.

1848
01:21:24,310 --> 01:21:26,460
Dokładnie.

1849
01:21:26,460 --> 01:21:29,490
OK, więc teraz moja skrzynka odbiorcza jest
w rzeczywistości znacznie mniejsze.

1850
01:21:29,490 --> 01:21:32,210
I to właściwie obsługuje
przepływ pracy o aplikacji e-mail.

1851
01:21:32,210 --> 01:21:34,230
Tak skrzynce odbiorczej, klikam.

1852
01:21:34,230 --> 01:21:38,160
Idę wzdłuż i klikam na wiadomości,
to kiedy muszę udać się do organizmu,

1853
01:21:38,160 --> 01:21:40,180
bo mam zamiar
przejść do innego widoku.

1854
01:21:40,180 --> 01:21:43,870
Więc jeśli myślisz o rodzaju MVC
Ramy, model widok kontroler.

1855
01:21:43,870 --> 01:21:46,120
>> Model zawiera
Dane że widok potrzeby

1856
01:21:46,120 --> 01:21:48,130
i sterownik komunikuje się z.

1857
01:21:48,130 --> 01:21:51,670
Kiedy zmienić ramkę, kiedy
I zmienić perspektywę,

1858
01:21:51,670 --> 01:21:55,080
to OK, aby wrócić do
Serwer i zaludnić modelu,

1859
01:21:55,080 --> 01:21:56,860
ponieważ to, co oczekuje użytkownik.

1860
01:21:56,860 --> 01:22:00,530
Kiedy zmienić poglądy, to kiedy
możemy wrócić do bazy.

1861
01:22:00,530 --> 01:22:02,480
Tak e-mail, kliknij przycisk.

1862
01:22:02,480 --> 01:22:03,710
Szukam ciała.

1863
01:22:03,710 --> 01:22:04,330
Podróż w obie strony.

1864
01:22:04,330 --> 01:22:05,680
Idź po ciało.

1865
01:22:05,680 --> 01:22:06,950
>> Czytałem dużo mniej danych.

1866
01:22:06,950 --> 01:22:09,960
Czytam jedynie organów, które
David potrzebuje, kiedy ich potrzebuje.

1867
01:22:09,960 --> 01:22:14,230
I nie mam nagrać w 1600
Pilot po prostu pokazać swoją skrzynkę odbiorczą.

1868
01:22:14,230 --> 01:22:17,670
Więc teraz that-- jest to sposób
że LSI lub GSI-- Przykro mi,

1869
01:22:17,670 --> 01:22:19,900
GSI, by wypracować.

1870
01:22:19,900 --> 01:22:25,450
Mamy nasz skrót na odbiorcę.

1871
01:22:25,450 --> 01:22:27,030
Mamy klucz gama na bieżąco.

1872
01:22:27,030 --> 01:22:31,380
I mamy prognozowanych atrybuty
że potrzebujemy tylko potwierdzają pogląd.

1873
01:22:31,380 --> 01:22:34,300
>> Obracamy, że do skrzynki nadawczej.

1874
01:22:34,300 --> 01:22:35,770
Hash na nadawcy.

1875
01:22:35,770 --> 01:22:39,612
I w istocie, mamy
bardzo ładny, czysty widok.

1876
01:22:39,612 --> 01:22:41,570
I to basically-- mamy
mają ten miły wiadomości

1877
01:22:41,570 --> 01:22:45,870
Stół, który jest rozprzestrzeniają się ładnie, bo
to tylko skrót, zakodowane wiadomości ID.

1878
01:22:45,870 --> 01:22:51,750
I mamy dwa indeksy, które
obracają się w tej tabeli.

1879
01:22:51,750 --> 01:22:57,411
W porządku, więc Chodzi o to, nie
przechowywać duże ilości danych i ten mały danych

1880
01:22:57,411 --> 01:22:57,910
razem.

1881
01:22:57,910 --> 01:23:00,700
Partition pionowo,
partycjonowanie tych tabel.

1882
01:23:00,700 --> 01:23:03,150
Nie odczytu danych nie trzeba.

1883
01:23:03,150 --> 01:23:04,850
Dobrze, gier.

1884
01:23:04,850 --> 01:23:06,990
Wszyscy lubimy gry.

1885
01:23:06,990 --> 01:23:10,902
Przynajmniej Lubię gry wtedy.

1886
01:23:10,902 --> 01:23:12,735
Tak więc niektóre rzeczy
że mamy do czynienia z przypadku

1887
01:23:12,735 --> 01:23:14,193
myślimy o grach, prawda?

1888
01:23:14,193 --> 01:23:16,999
Gaming tych dniach, zwłaszcza mobilne
gier, jest o myśleniu.

1889
01:23:16,999 --> 01:23:19,540
I mam zamiar obrócić się tutaj
nieco z dala od DynamoDB.

1890
01:23:19,540 --> 01:23:21,373
Zamierzam wnieść w
niektóre dyskusji

1891
01:23:21,373 --> 01:23:24,240
wokół niektórych
inne technologie AWS.

1892
01:23:24,240 --> 01:23:28,930
>> Ale pomysł o grach jest myśleć
o w zakresie interfejsów API, API, które są,

1893
01:23:28,930 --> 01:23:31,730
ogólnie rzecz biorąc, HTTP i JSON.

1894
01:23:31,730 --> 01:23:34,550
To jak mobilne gry rodzaju
interakcji z końców tylnych.

1895
01:23:34,550 --> 01:23:35,850
Robią JSON delegowania.

1896
01:23:35,850 --> 01:23:40,660
Oni się dane, i to wszystko,
ogólnie rzecz biorąc, w miłych API JSON.

1897
01:23:40,660 --> 01:23:44,950
>> Rzeczy takie jak dostać znajomych, uzyskać
dane liderów, wymiany,

1898
01:23:44,950 --> 01:23:47,699
Materiał generowany przez użytkowników,
wcisnąć z powrotem do systemu

1899
01:23:47,699 --> 01:23:49,740
są to rodzaje rzeczy
które mamy zamiar zrobić.

1900
01:23:49,740 --> 01:23:52,542
Dane binarne aktywów, dane
nie może siedzieć w bazie danych.

1901
01:23:52,542 --> 01:23:54,250
To może siedzieć w sposób
sklep obiektu, prawda?

1902
01:23:54,250 --> 01:23:56,541
Ale baza danych będzie
kończy się informacją z systemu,

1903
01:23:56,541 --> 01:23:59,140
mówi aplikację
gdzie się udać zdobyć.

1904
01:23:59,140 --> 01:24:03,550
I nieuchronnie, multiplayer
serwery, infrastruktura koniec z powrotem,

1905
01:24:03,550 --> 01:24:06,180
i przeznaczone do wysokiej
dostępność i skalowalność.

1906
01:24:06,180 --> 01:24:09,400
To są rzeczy, które wszyscy chcemy
w infrastrukturę gier dzisiaj.

1907
01:24:09,400 --> 01:24:12,160
>> Warto więc przyjrzeć się
co to wygląda.

1908
01:24:12,160 --> 01:24:16,070
Masz rdzenia tylny koniec,
bardzo proste.

1909
01:24:16,070 --> 01:24:19,880
Mamy system tutaj z
wiele stref dostępność.

1910
01:24:19,880 --> 01:24:23,780
Rozmawialiśmy o AZS, jak being-- myśleć
z nich jako oddzielne centra danych.

1911
01:24:23,780 --> 01:24:26,040
Więcej niż jedno centrum danych
na AZ, ale to jest OK,

1912
01:24:26,040 --> 01:24:28,831
tylko myśleć o nich jako o odrębnym danych
ośrodki, które są geograficznie

1913
01:24:28,831 --> 01:24:30,090
i wina odizolowane.

1914
01:24:30,090 --> 01:24:32,172
>> Mamy zamiar mieć
Kilka instancji EC2.

1915
01:24:32,172 --> 01:24:33,880
My będziemy mieć
niektóre z powrotem end.

1916
01:24:33,880 --> 01:24:35,800
Może jeśli jesteś dziedzictwo
architektura, jesteśmy

1917
01:24:35,800 --> 01:24:38,920
za pomocą tego, co nazywamy RDS,
relacyjne bazy danych. usługi

1918
01:24:38,920 --> 01:24:42,040
Może być MSSQL, MySQL,
czy coś takiego.

1919
01:24:42,040 --> 01:24:47,080
To jest sposób, w jaki aplikacje dużo
są już zaprojektowane.

1920
01:24:47,080 --> 01:24:49,594
>> Cóż możemy iść z
to jest, gdy skalowanie.

1921
01:24:49,594 --> 01:24:51,510
Idziemy do przodu i umieścić
wiadro tam S3.

1922
01:24:51,510 --> 01:24:54,200
I to wiadro S3, zamiast służyć
się tych obiektów ze servers--

1923
01:24:54,200 --> 01:24:55,220
możemy to zrobić.

1924
01:24:55,220 --> 01:24:57,210
Możesz umieścić wszystkie swoje pliki binarne
obiekty na serwerach

1925
01:24:57,210 --> 01:24:59,751
i można korzystać z tych serwer
przypadki, aby służyć, że dane w górę.

1926
01:24:59,751 --> 01:25:01,860
Ale to jest dość drogie.

1927
01:25:01,860 --> 01:25:05,107
>> Lepszy sposób zrobić to iść do przodu i
umieścić te obiekty w wiadrze S3.

1928
01:25:05,107 --> 01:25:06,315
S3 to obiekt repozytoriów.

1929
01:25:06,315 --> 01:25:10,860
Jest zbudowany specjalnie dla
obsługujących tego typu rzeczy.

1930
01:25:10,860 --> 01:25:13,690
I niech zażądać tych klientów
bezpośrednio z tymi wiadrami obiektów,

1931
01:25:13,690 --> 01:25:15,390
odciążyć serwery.

1932
01:25:15,390 --> 01:25:17,020
Więc zaczynamy skalować się tutaj.

1933
01:25:17,020 --> 01:25:19,140
>> Teraz mamy użytkowników na całym świecie.

1934
01:25:19,140 --> 01:25:19,730
Mam użytkowników.

1935
01:25:19,730 --> 01:25:23,380
Muszę mieć zawartość lokalnie
położony blisko tych użytkowników, prawda?

1936
01:25:23,380 --> 01:25:26,200
Mam stworzył wiadro S3
w moim repozytorium źródłowego.

1937
01:25:26,200 --> 01:25:29,370
A ja z przodu, że z
dystrybucja CloudFront.

1938
01:25:29,370 --> 01:25:31,720
>> CloudFront jest CD i
Zawartość Delivery Network.

1939
01:25:31,720 --> 01:25:35,750
Zasadniczo to ma danych, które można określić
i buforuje to wszystko przez internet

1940
01:25:35,750 --> 01:25:39,230
więc użytkownicy wszędzie może mieć
bardzo szybka reakcja, kiedy

1941
01:25:39,230 --> 01:25:40,960
zwracają się te obiekty.

1942
01:25:40,960 --> 01:25:41,960
>> Więc masz pomysł.

1943
01:25:41,960 --> 01:25:48,230
Jesteś rodzaju wykorzystując wszystkie
aspekty AWS tutaj, aby to zrobić.

1944
01:25:48,230 --> 01:25:50,790
I w końcu, rzucamy
w grupie automatycznego skalowania.

1945
01:25:50,790 --> 01:25:52,737
Więc nasze przypadkach AC2
z naszych serwerów gry,

1946
01:25:52,737 --> 01:25:54,820
jak zacząć, aby uzyskać bardziej zajęty
i bardziej zatłoczone i bardziej zajęty,

1947
01:25:54,820 --> 01:25:57,236
oni po prostu kręcić kolejny
Instancja, kręcić kolejną instancję,

1948
01:25:57,236 --> 01:25:58,210
kręcić kolejną instancję.

1949
01:25:58,210 --> 01:26:02,090
Więc technologii AWS ma, to
pozwala określić parametry

1950
01:26:02,090 --> 01:26:04,650
wokół którego serwery wzrośnie.

1951
01:26:04,650 --> 01:26:08,110
Więc możesz mieć n liczba serwerów
tam, w dowolnym danym czasie.

1952
01:26:08,110 --> 01:26:11,870
A jeśli obciążenie odchodzi, będą
kurczyć liczba skurczy.

1953
01:26:11,870 --> 01:26:15,250
A jeśli obciążenie wraca,
będzie rosnąć z powrotem, elastycznie.

1954
01:26:15,250 --> 01:26:17,050
>> Tak to wygląda świetnie.

1955
01:26:17,050 --> 01:26:19,800
Mamy wiele instancji EC2.

1956
01:26:19,800 --> 01:26:21,671
Możemy umieścić pamięć w
z przodu z bazami danych,

1957
01:26:21,671 --> 01:26:23,045
spróbować przyspieszyć baz danych.

1958
01:26:23,045 --> 01:26:25,030
Kolejnym punktem ciśnienia
zazwyczaj ludzie widzą

1959
01:26:25,030 --> 01:26:28,850
jest skala ich grę za pomocą
relacyjnego systemu baz danych.

1960
01:26:28,850 --> 01:26:30,790
Jezu, baza danych
Wydajność jest straszna.

1961
01:26:30,790 --> 01:26:31,932
W jaki sposób możemy poprawić, że?

1962
01:26:31,932 --> 01:26:33,640
Spróbujmy wprowadzenie
cache przed tym.

1963
01:26:33,640 --> 01:26:36,780
>> Cóż, pamięć podręczna nie działa
tak wielka, w grach, prawda?

1964
01:26:36,780 --> 01:26:39,330
W grach, pisanie jest bolesne.

1965
01:26:39,330 --> 01:26:40,930
Gry są bardzo Napisać ciężkie.

1966
01:26:40,930 --> 01:26:43,610
Cache nie działa, gdy jesteś
Napisać ciężkie, bo ty zawsze

1967
01:26:43,610 --> 01:26:44,610
dostał się do aktualizacji pamięci podręcznej.

1968
01:26:44,610 --> 01:26:47,780
Zaktualizować pamięć podręczną, to
bez znaczenia jest buforowanie.

1969
01:26:47,780 --> 01:26:49,780
To właściwie tylko dodatkowa praca.

1970
01:26:49,780 --> 01:26:51,970
>> Więc gdzie pójdziemy tutaj?

1971
01:26:51,970 --> 01:26:54,400
Masz duży wąskie gardło
tam w bazie danych.

1972
01:26:54,400 --> 01:26:57,661
I miejsce do pracy
oczywiście jest partycjonowanie.

1973
01:26:57,661 --> 01:26:59,410
Podział nie jest
łatwe do zrobienia, gdy jesteś

1974
01:26:59,410 --> 01:27:01,900
czynienia z relacyjnych baz danych.

1975
01:27:01,900 --> 01:27:05,080
Z relacyjnymi bazami danych, jesteś
odpowiedzialny za zarządzanie, skutecznie

1976
01:27:05,080 --> 01:27:06,210
klawisz spacji.

1977
01:27:06,210 --> 01:27:10,527
Mówisz użytkowników między A i M
kliknij tutaj, między N i Z tam.

1978
01:27:10,527 --> 01:27:12,360
A ty przełączania
drugiej aplikacji.

1979
01:27:12,360 --> 01:27:15,000
Więc masz do czynienia z
to źródło danych partycji.

1980
01:27:15,000 --> 01:27:18,670
Musisz ograniczeń transakcyjnych
które nie rozciągać partycje.

1981
01:27:18,670 --> 01:27:20,560
Masz wszystkie rodzaje
niechlujstwo, że jesteś

1982
01:27:20,560 --> 01:27:23,040
zajmujących się tam próbuje
do czynienia z Skalowanie

1983
01:27:23,040 --> 01:27:25,120
i budowanie większej infrastruktury.

1984
01:27:25,120 --> 01:27:27,284
To po prostu nie ma zabawy.

1985
01:27:27,284 --> 01:27:30,930
>> PUBLICZNOŚCI: Więc mówisz, że
zwiększenie punktów źródłowych przyspiesza

1986
01:27:30,930 --> 01:27:31,430
proces?

1987
01:27:31,430 --> 01:27:32,513
RICK HOULIHAN: Zwiększenie?

1988
01:27:32,513 --> 01:27:33,520
Punkty Źródło: publiczność.

1989
01:27:33,520 --> 01:27:34,410
RICK HOULIHAN: punkty źródłowe?

1990
01:27:34,410 --> 01:27:37,500
PUBLICZNOŚCI: Z informacji,
w przypadku gdy informacja pochodzi?

1991
01:27:37,500 --> 01:27:38,250
RICK HOULIHAN: Nie

1992
01:27:38,250 --> 01:27:41,820
Co mówię jest zwiększenie
liczba partycji w pamięci danych

1993
01:27:41,820 --> 01:27:44,060
poprawia wydajność.

1994
01:27:44,060 --> 01:27:48,300
Więc co się tutaj dzieje jest użytkowników
wchodząc do instancji EC2 się tutaj,

1995
01:27:48,300 --> 01:27:50,780
dobrze, jeśli potrzebuję użytkownika
to A do M, pójdę tutaj.

1996
01:27:50,780 --> 01:27:53,560
Z N p, pójdę tutaj.

1997
01:27:53,560 --> 01:27:55,060
Od P do Z, pójdę tutaj.

1998
01:27:55,060 --> 01:27:57,120
>> PUBLICZNOŚCI: OK, więc to są ci,
przechowywane w różnych węzłach?

1999
01:27:57,120 --> 01:27:57,911
>> RICK HOULIHAN: Tak.

2000
01:27:57,911 --> 01:28:00,210
Pomyśl o nich jako
różne silosy danych.

2001
01:28:00,210 --> 01:28:01,660
Więc masz to zrobić.

2002
01:28:01,660 --> 01:28:02,910
Jeśli próbujesz zrobić
to, jeśli starasz

2003
01:28:02,910 --> 01:28:05,730
skalowanie na relacyjnej platformy,
to jest to, co robisz.

2004
01:28:05,730 --> 01:28:08,100
Bierzesz dane i
masz je ścinać.

2005
01:28:08,100 --> 01:28:10,975
A ty podzielenie go przez
wiele instancji bazy danych.

2006
01:28:10,975 --> 01:28:13,580
A ty zarządzaniu wszystko
w warstwie aplikacji.

2007
01:28:13,580 --> 01:28:14,729
To nie jest zabawne.

2008
01:28:14,729 --> 01:28:15,770
Więc co chcemy iść?

2009
01:28:15,770 --> 01:28:20,240
Chcemy pójść DynamoDB, w pełni zagospodarowana,
Magazyn danych NoSQL, przepustowość przepis.

2010
01:28:20,240 --> 01:28:22,680
Używamy indeksy średnich.

2011
01:28:22,680 --> 01:28:26,154
Jest to w zasadzie HTTP API i
obejmuje obsługę dokumentów.

2012
01:28:26,154 --> 01:28:28,570
Więc nie musisz się martwić
o żadnej z tego podziału.

2013
01:28:28,570 --> 01:28:30,740
Robimy to wszystko dla Ciebie.

2014
01:28:30,740 --> 01:28:33,260
Więc teraz, zamiast tego,
po prostu napisz do stołu.

2015
01:28:33,260 --> 01:28:36,490
Jeśli tablica musi być podzielony,
co dzieje się za kulisami.

2016
01:28:36,490 --> 01:28:40,642
Jesteś całkowicie izolowane
od tego, jako deweloper.

2017
01:28:40,642 --> 01:28:42,350
Więc porozmawiajmy o
niektóre z przypadków użycia

2018
01:28:42,350 --> 01:28:47,564
które napotkasz w grach, wspólny
Scenariusze gier, liderów.

2019
01:28:47,564 --> 01:28:49,980
Więc masz użytkownicy najbliższych,
z BoardNames, że są one

2020
01:28:49,980 --> 01:28:52,930
na, wyniki dla tego użytkownika.

2021
01:28:52,930 --> 01:28:57,700
Możemy być mieszania na ID użytkownika,
a następnie mamy wybór na grę.

2022
01:28:57,700 --> 01:28:59,960
Tak więc każdy użytkownik chce zobaczyć
wszystko gra on grał

2023
01:28:59,960 --> 01:29:01,770
i wszystkie jego najlepszy wynik
we wszystkich gry.

2024
01:29:01,770 --> 01:29:04,000
Więc to jest jego osobista liderów.

2025
01:29:04,000 --> 01:29:10,010
>> Teraz chcę iść i chcę get--
więc mam te osobiste liderów.

2026
01:29:10,010 --> 01:29:12,827
To, co chcę zrobić, to udać się
najlepszy wynik dla wszystkich użytkowników.

2027
01:29:12,827 --> 01:29:13,660
Więc jak to zrobić?

2028
01:29:13,660 --> 01:29:18,070
Kiedy mój rekord jest mieszany na
identyfikator użytkownika, wahały się od gry,

2029
01:29:18,070 --> 01:29:20,740
dobrze mam zamiar iść do przodu
i restrukturyzacji, stworzyć GSI,

2030
01:29:20,740 --> 01:29:22,370
i mam zamiar do restrukturyzacji tych danych.

2031
01:29:22,370 --> 01:29:27,310
>> Teraz idę do mieszania na
BoardName, która jest gra.

2032
01:29:27,310 --> 01:29:29,800
I będę wahać się najlepszy wynik.

2033
01:29:29,800 --> 01:29:31,540
A teraz stworzyłem różne wiadra.

2034
01:29:31,540 --> 01:29:34,790
Używam tej samej tabeli,
te same dane pozycji.

2035
01:29:34,790 --> 01:29:39,870
Ale tworzę wiadro, które daje
mi agregacja najwyższym wynikiem od gry.

2036
01:29:39,870 --> 01:29:43,180
>> A mogę zapytać, że tabela
aby uzyskać te informacje.

2037
01:29:43,180 --> 01:29:50,890
Więc mam ustawić ten wzór zapytania do
wspierane przez indeks wtórnego.

2038
01:29:50,890 --> 01:29:54,556
Teraz mogą być klasyfikowane według BoardName
i klasyfikowane według TopScore, w zależności od.

2039
01:29:54,556 --> 01:29:57,180
Tak więc widać, są to typy
Korzystanie z przypadków masz w grach.

2040
01:29:57,180 --> 01:30:02,190
Kolejny dobry przypadek użycia mamy w grach
to nagrody i kto wygrał nagrody.

2041
01:30:02,190 --> 01:30:05,340
I to jest wielki przypadek użycia
gdzie zadzwonić rzadkie indeksów.

2042
01:30:05,340 --> 01:30:07,340
Indeksy Nieliczne są
Zdolność tworzenia

2043
01:30:07,340 --> 01:30:10,850
indeks, że niekoniecznie
zawierać każdy element na stole.

2044
01:30:10,850 --> 01:30:11,470
Czemu nie?

2045
01:30:11,470 --> 01:30:14,540
Ponieważ atrybut, który jest jest
indeksowane nie istnieje na każdej pozycji.

2046
01:30:14,540 --> 01:30:16,460
>> Tak więc w tym konkretnym
używać sprawy, mówię,

2047
01:30:16,460 --> 01:30:19,240
wiesz co, mam zamiar
utworzyć atrybut o nazwie Award.

2048
01:30:19,240 --> 01:30:22,970
I mam zamiar dać każdemu użytkownikowi
że ma nagrodę tego atrybutu.

2049
01:30:22,970 --> 01:30:25,950
Użytkownicy, którzy nie mają nagrody są
nie będzie miał tego atrybutu.

2050
01:30:25,950 --> 01:30:27,800
Kiedy więc stworzyć
Strona, tylko użytkownicy

2051
01:30:27,800 --> 01:30:28,960
które będą wykazywały
w indeksie są

2052
01:30:28,960 --> 01:30:31,050
te, które rzeczywiście zostały nagrodzone.

2053
01:30:31,050 --> 01:30:34,440
Tak, że to świetny sposób, aby być w stanie
stworzyć filtrowane indeksy, że

2054
01:30:34,440 --> 01:30:40,580
są bardzo, bardzo selektywne, które nie
mają indeksować całą tabelę.

2055
01:30:40,580 --> 01:30:43,050
>> Więc mamy już mało czasu tutaj.

2056
01:30:43,050 --> 01:30:49,190
Mam zamiar iść do przodu i pominąć
się i pominąć ten scenariusz.

2057
01:30:49,190 --> 01:30:52,625
Dyskusja trochę about--

2058
01:30:52,625 --> 01:30:54,460
>> PUBLICZNOŚCI: Czy mogę zadać krótkie pytanie?

2059
01:30:54,460 --> 01:30:56,722
Jednym z nich jest Napisać ciężkie?

2060
01:30:56,722 --> 01:30:57,680
RICK HOULIHAN: Co to jest?

2061
01:30:57,680 --> 01:30:58,596
PUBLICZNOŚCI: Napisz ciężkie.

2062
01:30:58,596 --> 01:31:01,270
RICK HOULIHAN: Napisz ciężkie.

2063
01:31:01,270 --> 01:31:03,460
Daj mi zobaczyć.

2064
01:31:03,460 --> 01:31:06,220
>> PUBLICZNOŚCI: Albo jest to, że nie
coś, co można po prostu

2065
01:31:06,220 --> 01:31:08,809
Głos w ciągu kilku sekund?

2066
01:31:08,809 --> 01:31:10,850
RICK HOULIHAN: Idziemy
przez scenariuszu głosowania.

2067
01:31:10,850 --> 01:31:11,670
Nie jest tak źle.

2068
01:31:11,670 --> 01:31:14,580
Czy macie kilka minut?

2069
01:31:14,580 --> 01:31:15,860
OK.

2070
01:31:15,860 --> 01:31:17,890
>> Więc będziemy rozmawiać o głosowaniu.

2071
01:31:17,890 --> 01:31:20,250
Więc głosowania w czasie rzeczywistym, mamy
wymagania dotyczące głosowania.

2072
01:31:20,250 --> 01:31:25,250
Wymagania są takie, że pozwalają
każda osoba głosować tylko raz.

2073
01:31:25,250 --> 01:31:28,060
Chcemy, nikt nie być w stanie
zmienić swój głos.

2074
01:31:28,060 --> 01:31:31,045
Chcemy agregacji w czasie rzeczywistym
i analiz dla demografii

2075
01:31:31,045 --> 01:31:34,210
że będziemy mieć
pokazywanie użytkowników na stronie.

2076
01:31:34,210 --> 01:31:35,200
>> Pomyśl o tym scenariuszu.

2077
01:31:35,200 --> 01:31:37,550
Mamy wiele rzeczywistości działa
Telewizja pokazuje, gdzie są

2078
01:31:37,550 --> 01:31:38,960
robi te dokładny typ rzeczy.

2079
01:31:38,960 --> 01:31:41,584
Tak więc można myśleć o scenariuszu,
mamy miliony

2080
01:31:41,584 --> 01:31:43,959
wśród nastoletnich dziewcząt tam
z ich telefonów komórkowych

2081
01:31:43,959 --> 01:31:46,250
i głosowania i głosowania,
głosowanie na kimkolwiek są

2082
01:31:46,250 --> 01:31:48,610
znaleźć się najbardziej popularne.

2083
01:31:48,610 --> 01:31:50,830
To są jedne z
Wymagania zabraknie.

2084
01:31:50,830 --> 01:31:52,990
>> I tak w pierwszej kolejności podejmuje
w rozwiązaniu tego problemu

2085
01:31:52,990 --> 01:31:55,090
będzie budować
bardzo prosta aplikacja.

2086
01:31:55,090 --> 01:31:56,490
Więc mam tę aplikację.

2087
01:31:56,490 --> 01:31:57,950
Mam kilka wyborców tam.

2088
01:31:57,950 --> 01:31:59,980
Pochodzą one w, trafią aplikację do głosowania.

2089
01:31:59,980 --> 01:32:03,440
Mam trochę surowy głosów tabeli
Ja po prostu zrzucić te głosy się.

2090
01:32:03,440 --> 01:32:05,780
Muszę trochę kruszywa
głosów tabela

2091
01:32:05,780 --> 01:32:09,490
zrobi swoje analizy i demografii,
a my umieścić to wszystko w środku.

2092
01:32:09,490 --> 01:32:11,420
>> I to jest świetne.

2093
01:32:11,420 --> 01:32:12,332
Życie jest dobre.

2094
01:32:12,332 --> 01:32:15,040
Życie jest dobre, dopóki nie dowiemy się, że
zawsze tylko jeden lub dwa

2095
01:32:15,040 --> 01:32:16,879
osób, które są popularne w wyborach.

2096
01:32:16,879 --> 01:32:19,420
Jest tylko jedna lub dwie rzeczy
że ludzie naprawdę zależy.

2097
01:32:19,420 --> 01:32:22,340
A jeśli głosowanie na
Skala, nagle jestem

2098
01:32:22,340 --> 01:32:26,360
będzie młotkiem piekło z
dwóch kandydatów, jeden lub dwóch kandydatów.

2099
01:32:26,360 --> 01:32:29,390
Bardzo ograniczona liczba elementów
ludzie znajdują się popularne.

2100
01:32:29,390 --> 01:32:31,710
>> To nie jest dobry wzór projektu.

2101
01:32:31,710 --> 01:32:33,549
To jest rzeczywiście
bardzo zły wzorzec projektowy

2102
01:32:33,549 --> 01:32:36,340
ponieważ tworzy dokładnie to, czego
mówił o których była klawisze.

2103
01:32:36,340 --> 01:32:38,960
Klawisze są czymś, czego nie lubimy.

2104
01:32:38,960 --> 01:32:40,470
>> Więc jak to naprawić?

2105
01:32:40,470 --> 01:32:47,640
I rzeczywiście, tak aby to naprawić jest
biorąc te wiadra kandydujące

2106
01:32:47,640 --> 01:32:51,490
i dla każdego kandydata mamy,
mamy zamiar dołączyć losową wartość,

2107
01:32:51,490 --> 01:32:54,192
coś, co wiemy, losowo
Wartość pomiędzy jednym i 100,

2108
01:32:54,192 --> 01:32:56,620
od 100 do 1000,
lub od jednego do 1000,

2109
01:32:56,620 --> 01:32:59,940
jednak wiele losowych wartości chcesz
dołączyć na końcu tego kandydata.

2110
01:32:59,940 --> 01:33:01,330
>> I co ja naprawdę zrobić wtedy?

2111
01:33:01,330 --> 01:33:05,830
Jeśli używam identyfikator kandydata jako
wiadro do głosów kruszywa,

2112
01:33:05,830 --> 01:33:08,780
jeśli dodałem losowy
liczba na koniec, że,

2113
01:33:08,780 --> 01:33:12,000
Stworzyłem już 10 wiadra, A
sto wiader wiadra, tysiąc

2114
01:33:12,000 --> 01:33:14,160
że jestem agregowania głosów w poprzek.

2115
01:33:14,160 --> 01:33:18,030
>> Więc mam miliony i miliony,
i miliony rekordów w najbliższych

2116
01:33:18,030 --> 01:33:22,050
dla tych kandydatów, jestem teraz rozprzestrzenia
te głosy całej kandydackiej A_1

2117
01:33:22,050 --> 01:33:24,630
przez Kandydata A_100, ponieważ
Głosowanie za każdym razem przychodzi,

2118
01:33:24,630 --> 01:33:26,530
Jestem generowania losowych
wartość od jednego do 100.

2119
01:33:26,530 --> 01:33:29,446
Jestem sklejaniu ją na koniec
Kandydat, że głosowanie na osoby.

2120
01:33:29,446 --> 01:33:31,120
Jestem dumpingu go do tego wiadra.

2121
01:33:31,120 --> 01:33:33,910
>> Teraz z tyłu, wiem
że mam sto wiader.

2122
01:33:33,910 --> 01:33:36,350
Więc kiedy chcę iść do przodu
i agregacji głosów,

2123
01:33:36,350 --> 01:33:38,244
Czytam ze wszystkich tych wiader.

2124
01:33:38,244 --> 01:33:39,160
Więc śmiało i dodać.

2125
01:33:39,160 --> 01:33:42,410
A potem ja rozrzut zebrać
gdzie wyjść i powiedzieć, hej,

2126
01:33:42,410 --> 01:33:45,399
wiesz co, klucz tego kandydata
miejsc jest ponad sto wiader.

2127
01:33:45,399 --> 01:33:47,940
Mam zamiar zebrać wszystkie
głosów z tych stu wiadrach.

2128
01:33:47,940 --> 01:33:49,981
Idę do agregowania
je i mam zamiar powiedzieć,

2129
01:33:49,981 --> 01:33:53,830
Kandydat A ma teraz
Łączna głos x.

2130
01:33:53,830 --> 01:33:55,690
>> Teraz zarówno zapisu
kwerendy i kwerendy odczytu

2131
01:33:55,690 --> 01:33:58,160
są ładnie rozłożone
bo piszę w całej

2132
01:33:58,160 --> 01:34:00,320
i czytam przez setki kluczy.

2133
01:34:00,320 --> 01:34:03,500
Nie piszę i
czytanie całej jeden klucz teraz.

2134
01:34:03,500 --> 01:34:04,950
Tak, że to świetny wzór.

2135
01:34:04,950 --> 01:34:08,090
>> To jest rzeczywiście prawdopodobnie jednym
najważniejszego projektowania

2136
01:34:08,090 --> 01:34:10,420
wzorce dla skali w NoSQL.

2137
01:34:10,420 --> 01:34:14,470
Widać ten typ
wzornictwo w każdym smaku.

2138
01:34:14,470 --> 01:34:19,100
MongoDB, DynamoDB, nie robi
Niezależnie, wszyscy mamy to zrobić.

2139
01:34:19,100 --> 01:34:21,840
Bo kiedy masz do czynienia
z tych ogromnych skupisk,

2140
01:34:21,840 --> 01:34:26,650
trzeba znaleźć sposób na
rozłożyć całej wiadrach.

2141
01:34:26,650 --> 01:34:29,512
Więc to jest tak, jak to zrobić.

2142
01:34:29,512 --> 01:34:31,220
No dobrze, więc co
robisz teraz

2143
01:34:31,220 --> 01:34:35,252
jest pan handel off lektury
koszt zapisu skalowalności.

2144
01:34:35,252 --> 01:34:37,085
Koszt mojego odczytu jest
nieco bardziej skomplikowane

2145
01:34:37,085 --> 01:34:40,220
i muszę go odczytać z
Sto wiadra zamiast jednego.

2146
01:34:40,220 --> 01:34:41,310
Ale jestem w stanie napisać.

2147
01:34:41,310 --> 01:34:44,860
A mój przepustowość, mój zapisu
Przepustowość jest niesamowite.

2148
01:34:44,860 --> 01:34:49,450
Tak to zwykle cennym
technika skalowania DynamoDB,

2149
01:34:49,450 --> 01:34:51,350
lub dowolnej bazy danych NoSQL o to chodzi.

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

2151
01:34:53,824 --> 01:34:55,240
Tak więc zorientowali się, jak go przeskalować.

2152
01:34:55,240 --> 01:34:56,930
I doszliśmy jak
wyeliminować nasze klawiszy skrótu.

2153
01:34:56,930 --> 01:34:57,820
I to jest fantastyczne.

2154
01:34:57,820 --> 01:34:58,960
I mamy niezły system.

2155
01:34:58,960 --> 01:35:02,043
I to daje nam bardzo poprawne głosowania
bo mamy rekord głosowania de duplikatem.

2156
01:35:02,043 --> 01:35:03,130
Jest zbudowany w DynamoDB.

2157
01:35:03,130 --> 01:35:05,380
Rozmawialiśmy o warunkowego prawa.

2158
01:35:05,380 --> 01:35:08,170
>> Gdy wyborca ​​przychodzi, stawia
wkładkę na stole

2159
01:35:08,170 --> 01:35:11,220
oni wstawiać ich wyborców ID,
gdyby spróbować włożyć inny głos,

2160
01:35:11,220 --> 01:35:13,320
Robię zapis warunkowy.

2161
01:35:13,320 --> 01:35:16,960
Tylko powiedzieć, napisać to
Jeśli nie istnieje.

2162
01:35:16,960 --> 01:35:19,270
Więc jak tylko widzę, że
że oceniany hitu tabeli,

2163
01:35:19,270 --> 01:35:20,460
nikt inny nie będzie
w stanie umieścić swój głos na.

2164
01:35:20,460 --> 01:35:21,634
I to jest fantastyczne.

2165
01:35:21,634 --> 01:35:23,550
A my zwiększając
nasze liczniki kandydujących.

2166
01:35:23,550 --> 01:35:25,466
I robimy co w naszej
demografia i to wszystko.

2167
01:35:25,466 --> 01:35:29,110
Ale co się stanie, jeśli moje
Aplikacja przewraca?

2168
01:35:29,110 --> 01:35:31,350
Teraz nagle głosów
są w najbliższych, a ja

2169
01:35:31,350 --> 01:35:34,840
nie wiem, czy są one przetwarzane coraz
do moich analiz i demografii

2170
01:35:34,840 --> 01:35:36,040
więcej.

2171
01:35:36,040 --> 01:35:38,462
I gdy aplikacja
wraca się, jak

2172
01:35:38,462 --> 01:35:41,420
do cholery mam wiedzieć, co głosy
przetwarzane i gdzie mam zacząć?

2173
01:35:41,420 --> 01:35:44,530
>> Więc to jest prawdziwy problem, gdy
zacząć patrzeć na tego typu scenariusz.

2174
01:35:44,530 --> 01:35:45,571
A w jaki sposób rozwiązać ten?

2175
01:35:45,571 --> 01:35:48,070
Rozwiążemy go z tym, co
zadzwoń DynamoDB strumieni.

2176
01:35:48,070 --> 01:35:53,470
Strumienie jest czas zamówione i
podzielony Dziennik zmian każdego dostępu

2177
01:35:53,470 --> 01:35:55,700
w tabeli, każdy napisać
dostępu do tabeli.

2178
01:35:55,700 --> 01:35:58,810
Wszelkie dane, które napisała do
Tabela pokazuje się na strumień.

2179
01:35:58,810 --> 01:36:01,815
>> Jest to w zasadzie Kolejka 24 godziny.

2180
01:36:01,815 --> 01:36:03,690
Produkty uderzył strumień,
żyją do 24 godzin.

2181
01:36:03,690 --> 01:36:05,990
Mogą być odczytywane wielokrotnie.

2182
01:36:05,990 --> 01:36:09,400
Gwarantowana być dostarczone
raz w strumieniu

2183
01:36:09,400 --> 01:36:11,180
można odczytać liczbę n razy.

2184
01:36:11,180 --> 01:36:14,910
Więc jednak wiele procesów chcesz
zużywają te dane, można go spożywać.

2185
01:36:14,910 --> 01:36:16,350
Pojawi się on każdej aktualizacji.

2186
01:36:16,350 --> 01:36:18,455
Każdy zapis będzie tylko
pojawiają się raz na strumieniu.

2187
01:36:18,455 --> 01:36:20,621
Więc nie musisz się martwić
o przetworzeniu go dwa razy

2188
01:36:20,621 --> 01:36:22,500
z tego samego procesu.

2189
01:36:22,500 --> 01:36:25,350
>> Jest ściśle uporządkowane za sztukę.

2190
01:36:25,350 --> 01:36:28,180
Kiedy mówimy, że czas
uporządkowany i podzielony na partycje,

2191
01:36:28,180 --> 01:36:30,680
zobaczysz na partycji, na strumieniu.

2192
01:36:30,680 --> 01:36:33,169
Zobaczysz przedmiotów, aktualizacje w porządku.

2193
01:36:33,169 --> 01:36:35,210
Nie gwarantujemy
w strumieniu, że jesteś

2194
01:36:35,210 --> 01:36:40,240
dostanie każdą transakcję
W drugiej kolejności elementów.

2195
01:36:40,240 --> 01:36:42,440
>> Więc strumienie są idempotent.

2196
01:36:42,440 --> 01:36:44,037
Czy wszyscy wiemy, co idempotent oznacza?

2197
01:36:44,037 --> 01:36:46,620
Idempotent oznacza, że ​​można to zrobić
ponad, kółko, w kółko.

2198
01:36:46,620 --> 01:36:48,200
Rezultatem będzie taki sam.

2199
01:36:48,200 --> 01:36:49,991
>> Strumienie są idempotent,
ale nie musi być

2200
01:36:49,991 --> 01:36:54,860
grał od punktu początkowego,
wszędzie tam, gdzie chcesz, aby do końca,

2201
01:36:54,860 --> 01:36:57,950
lub nie spowoduje
w takich samych wartości.

2202
01:36:57,950 --> 01:36:59,727
>> To samo z MongoDB.

2203
01:36:59,727 --> 01:37:01,560
MongoDB ma konstrukcję
nazywają oplog.

2204
01:37:01,560 --> 01:37:04,140
Jest to dokładnie ten sam konstrukt.

2205
01:37:04,140 --> 01:37:06,500
Wiele baz danych NoSQL
mają tę konstrukcję.

2206
01:37:06,500 --> 01:37:08,790
Używają go do robienia rzeczy,
jak replikacja, które

2207
01:37:08,790 --> 01:37:10,475
jest dokładnie to, co robimy z strumieni.

2208
01:37:10,475 --> 01:37:12,350
PUBLICZNOŚCI: Może
heretyckie pytanie, ale

2209
01:37:12,350 --> 01:37:13,975
mówić o aplikacje robi w dół itd.

2210
01:37:13,975 --> 01:37:16,089
Strumienie są gwarantowane
nigdy nie może iść w dół?

2211
01:37:16,089 --> 01:37:18,630
RICK HOULIHAN: Tak, strumieni
gwarancję, aby nigdy nie zejść.

2212
01:37:18,630 --> 01:37:21,040
Zarządzamy infrastrukturą
za. strumieni automatycznie

2213
01:37:21,040 --> 01:37:22,498
wdrożyć w swojej grupie automatycznego skalowania.

2214
01:37:22,498 --> 01:37:25,910
Pójdziemy za mały
nieco o tym, co się dzieje.

2215
01:37:25,910 --> 01:37:30,060
>> Nie powinienem powiedzieć, że nie są
na pewno nigdy nie zejść.

2216
01:37:30,060 --> 01:37:33,110
Elementy są gwarantowane
do stawienia się w strumieniu.

2217
01:37:33,110 --> 01:37:36,740
I strumień będzie dostępna.

2218
01:37:36,740 --> 01:37:40,580
Więc to, co idzie w dół lub wraca
się, co dzieje się pod spodem.

2219
01:37:40,580 --> 01:37:43,844
To covers-- jest OK.

2220
01:37:43,844 --> 01:37:46,260
W porządku, więc masz różne
Zobacz typy na ekranie.

2221
01:37:46,260 --> 01:37:51,040
Rodzaje zobacz, które są ważne dla
programista zazwyczaj są, co to było?

2222
01:37:51,040 --> 01:37:52,370
Mam stary pogląd.

2223
01:37:52,370 --> 01:37:55,630
Gdy aktualizacja uderza w stół, to będziesz
wcisnąć stary widok na strumień

2224
01:37:55,630 --> 01:38:02,070
więc dane mogą archiwizować lub zmiany
Kontrola, identyfikacja zmiany, zmiany

2225
01:38:02,070 --> 01:38:03,600
zarządzanie.

2226
01:38:03,600 --> 01:38:07,160
>> Nowy obraz, co jest teraz po
aktualizacja, to inny rodzaj widzenia

2227
01:38:07,160 --> 01:38:07,660
możesz dostać.

2228
01:38:07,660 --> 01:38:09,660
Możesz uzyskać zarówno stare i nowe zdjęcia.

2229
01:38:09,660 --> 01:38:10,660
Może chcę ich obu.

2230
01:38:10,660 --> 01:38:11,790
Chcę zobaczyć, co to było.

2231
01:38:11,790 --> 01:38:13,290
Chcę zobaczyć, co zmieniło się.

2232
01:38:13,290 --> 01:38:15,340
>> Mam typ zgodności
procesu, który działa.

2233
01:38:15,340 --> 01:38:17,430
Wymaga to, aby sprawdzić,
gdy zmiany te rzeczy,

2234
01:38:17,430 --> 01:38:21,840
że są one w pewnych granicach
lub w pewnych parametrów.

2235
01:38:21,840 --> 01:38:23,840
>> A to może tylko ja
trzeba wiedzieć, co się zmieniło.

2236
01:38:23,840 --> 01:38:26,240
Nie obchodzi mnie, co poz zmieniło.

2237
01:38:26,240 --> 01:38:28,580
I nie trzeba wiedzieć
jakie atrybuty zmieniony.

2238
01:38:28,580 --> 01:38:30,882
Muszę tylko wiedzieć, że
produkty są dotykane.

2239
01:38:30,882 --> 01:38:33,340
Więc to są typy widoków
że wysiąść strumień

2240
01:38:33,340 --> 01:38:35,960
i można wchodzić w interakcje z.

2241
01:38:35,960 --> 01:38:37,840
>> Aplikacja, która
zużywa strumienia,

2242
01:38:37,840 --> 01:38:39,298
jest to swego rodzaju sposób to działa.

2243
01:38:39,298 --> 01:38:42,570
Klient DynamoDB poprosić
zapisywać dane do tabeli.

2244
01:38:42,570 --> 01:38:44,750
Strumienie wdrożyć na to, co nazywamy odłamki.

2245
01:38:44,750 --> 01:38:47,380
Odłamki są skalowane
niezależnie od stołu.

2246
01:38:47,380 --> 01:38:50,660
Nie kolejce całkowicie
do rozbiorów tabeli.

2247
01:38:50,660 --> 01:38:52,540
I dlatego jest
bo w kolejce

2248
01:38:52,540 --> 01:38:55,430
do mocy, prąd
Zdolność tabeli.

2249
01:38:55,430 --> 01:38:57,600
>> Wdrożyć je w ich
własne auto grupa skalowanie,

2250
01:38:57,600 --> 01:39:00,800
i zaczynają kręcić się w zależności
na ile zapisy są w najbliższych,

2251
01:39:00,800 --> 01:39:03,090
ile reads-- naprawdę to pisze.

2252
01:39:03,090 --> 01:39:05,820
Nie ma reads-- ale jak
wiele zapisy idą w.

2253
01:39:05,820 --> 01:39:08,200
>> A następnie do tyłu
koniec, mamy to, co mamy

2254
01:39:08,200 --> 01:39:11,390
wezwać KCI, lub Kinesis biblioteki klienta.

2255
01:39:11,390 --> 01:39:19,190
Kinesis jest strumień danych
technologia przetwarzania z Amazon.

2256
01:39:19,190 --> 01:39:22,040
I strumieni jest zbudowany na tym.

2257
01:39:22,040 --> 01:39:25,670
>> Więc używać włączało KCL
Aplikacja do odczytu strumienia.

2258
01:39:25,670 --> 01:39:28,752
Kinesis Client Library rzeczywistości
zarządza pracowników dla Ciebie.

2259
01:39:28,752 --> 01:39:30,460
I to też robi niektóre
interesujące rzeczy.

2260
01:39:30,460 --> 01:39:35,630
Stworzy niektóre tabele się
w DynamoDB tabel

2261
01:39:35,630 --> 01:39:38,410
śledzić, które elementy
zostały przetworzone.

2262
01:39:38,410 --> 01:39:41,190
Więc w ten sposób, jeśli spada, jeśli
nie przewraca, a przychodzi i dostaje

2263
01:39:41,190 --> 01:39:45,570
cofnął się, może określić, gdzie
było to w przetwarzanie strumienia.

2264
01:39:45,570 --> 01:39:48,360
>> To bardzo ważne, gdy
mówisz replikacji.

2265
01:39:48,360 --> 01:39:50,350
Muszę wiedzieć, co
Dane zostały poddane obróbce

2266
01:39:50,350 --> 01:39:52,810
i co dane jest jeszcze przetworzony.

2267
01:39:52,810 --> 01:39:57,380
Więc biblioteka KCL dla strumieni będzie
daje dużo tej funkcji.

2268
01:39:57,380 --> 01:39:58,990
Dba o wszystkich pracach domowych.

2269
01:39:58,990 --> 01:40:01,140
Wyróżnia się pracownikowi za każdy odłamek.

2270
01:40:01,140 --> 01:40:04,620
Tworzy tabelę administracyjnej
za każdy odłamek, dla każdego pracownika.

2271
01:40:04,620 --> 01:40:07,560
I jak te ognia pracowników,
utrzymują tych tabel

2272
01:40:07,560 --> 01:40:10,510
więc wiesz, ten rekord
został odczytany i przetwarzany.

2273
01:40:10,510 --> 01:40:13,850
A następnie w ten sposób, jeśli proces
umiera i wraca on-line,

2274
01:40:13,850 --> 01:40:17,940
może wznowić prawo, gdzie wystartował.

2275
01:40:17,940 --> 01:40:20,850
>> Więc używamy to dla
replikacji cross-region.

2276
01:40:20,850 --> 01:40:24,680
Wielu klientów mają potrzebę
przenosić dane lub części swoich tabel danych

2277
01:40:24,680 --> 01:40:25,920
wokół różnych regionach.

2278
01:40:25,920 --> 01:40:29,230
Istnieje dziewięć regionów
na całym świecie.

2279
01:40:29,230 --> 01:40:32,100
Więc nie może być need-- I
może mieć użytkowników w Azji, użytkownicy

2280
01:40:32,100 --> 01:40:34,150
na wschodnim wybrzeżu Stanów Zjednoczonych.

2281
01:40:34,150 --> 01:40:38,980
Mają one różne dane
musi być lokalnie rozłożone.

2282
01:40:38,980 --> 01:40:42,510
A może użytkownik prostej od
Asia nad do Stanów Zjednoczonych,

2283
01:40:42,510 --> 01:40:45,020
i chcę powtórzyć
jego dane z niego.

2284
01:40:45,020 --> 01:40:49,340
Więc kiedy wysiada z samolotu, ma
dobre doświadczenie przy użyciu swojego telefonu aplikację.

2285
01:40:49,340 --> 01:40:52,360
>> Możesz używać cross-region
Biblioteka replikacji, aby to zrobić.

2286
01:40:52,360 --> 01:40:55,730
Zasadniczo mamy
pod warunkiem, dwie technologie.

2287
01:40:55,730 --> 01:40:59,400
Jeden to aplikacja konsoli można
stanąć na własnych instancji EC2.

2288
01:40:59,400 --> 01:41:01,240
Działa czysty replikacji.

2289
01:41:01,240 --> 01:41:02,720
A potem dał ci biblioteki.

2290
01:41:02,720 --> 01:41:06,070
W bibliotece można użyć do budowy
własnej aplikacji, jeśli Ciebie

2291
01:41:06,070 --> 01:41:10,740
chcę robić szalone rzeczy, które data--
Filtr, replikować tylko jego część,

2292
01:41:10,740 --> 01:41:14,120
obrócić dane, otworzyć ją w
tabela, tak dalej, i tak dalej.

2293
01:41:14,120 --> 01:41:18,700

2294
01:41:18,700 --> 01:41:20,520
Tak, że to trochę, co to wygląda.

2295
01:41:20,520 --> 01:41:23,690
>> DynamoDB strumieni może być
przetwarzane przez to, co nazywamy Lambda.

2296
01:41:23,690 --> 01:41:27,394
Wspominaliśmy już trochę o imprezy
napędzane architektury aplikacji.

2297
01:41:27,394 --> 01:41:28,810
Lambda jest kluczowym elementem tego.

2298
01:41:28,810 --> 01:41:32,840
Lambda jest kod, który odpala na żądanie
w odpowiedzi na określone zdarzenie.

2299
01:41:32,840 --> 01:41:36,020
Jednym z tych wydarzeń może być
zapis pojawia się w strumieniu.

2300
01:41:36,020 --> 01:41:39,100
Jeśli w strumieniu pojawia się zapis,
nazwijmy tę funkcję Java.

2301
01:41:39,100 --> 01:41:44,980
Cóż, to jest JavaScript i Lambda
obsługuje node.js, Java, Python,

2302
01:41:44,980 --> 01:41:47,820
i wkrótce będzie wspierać
inne języki, jak również.

2303
01:41:47,820 --> 01:41:50,940
A wystarczy powiedzieć, że to czysty kod.

2304
01:41:50,940 --> 01:41:53,610
Napisać W Javie można zdefiniować klasę.

2305
01:41:53,610 --> 01:41:55,690
Naciśnięciu JAR górę do Lambda.

2306
01:41:55,690 --> 01:42:00,200
A następnie określić, która klasa
zadzwonić, w odpowiedzi na które zdarzenie.

2307
01:42:00,200 --> 01:42:04,770
A następnie infrastruktura Lambda
tyle, że będzie działał ten kod.

2308
01:42:04,770 --> 01:42:06,730
>> Ten kod może przetwarzać
Zapisy off strumienia.

2309
01:42:06,730 --> 01:42:08,230
To może zrobić wszystko, co chce z nim.

2310
01:42:08,230 --> 01:42:11,650
W tym konkretnym przykładzie, wszystkie jesteśmy
naprawdę robi się zalogowaniu atrybuty.

2311
01:42:11,650 --> 01:42:13,480
Ale to tylko kod.

2312
01:42:13,480 --> 01:42:15,260
Kod może nic zrobić, prawda?

2313
01:42:15,260 --> 01:42:16,600
>> Więc można obrócić te dane.

2314
01:42:16,600 --> 01:42:18,160
Możesz utworzyć widok pochodny.

2315
01:42:18,160 --> 01:42:21,160
Jeśli jest to struktura dokumentu,
można spłaszczyć strukturę.

2316
01:42:21,160 --> 01:42:24,300
Można tworzyć alternatywne indeksy.

2317
01:42:24,300 --> 01:42:27,100
Wszystkie rodzaje rzeczy zdołasz
zrobić z DynamoDB strumieni.

2318
01:42:27,100 --> 01:42:28,780
>> A tak naprawdę, to co to wygląda.

2319
01:42:28,780 --> 01:42:29,940
Więc masz te aktualizacje w najbliższych.

2320
01:42:29,940 --> 01:42:31,190
Zbliżają się ciąg.

2321
01:42:31,190 --> 01:42:32,720
Są one odczytywane przez funkcję lambda.

2322
01:42:32,720 --> 01:42:37,480
Oni obracając dane i
popychając go w tabelach pochodnych,

2323
01:42:37,480 --> 01:42:42,200
zgłaszania systemów zewnętrznych zmian,
i pchania danych do ElastiCache.

2324
01:42:42,200 --> 01:42:45,900
>> Rozmawialiśmy o tym, jak umieścić pamięć podręczną
przed bazy danych dla tego sprzedaży

2325
01:42:45,900 --> 01:42:46,450
scenariusz.

2326
01:42:46,450 --> 01:42:50,049
Cóż, co się stanie, jeśli
aktualizować opis przedmiotu?

2327
01:42:50,049 --> 01:42:52,340
Cóż, gdybym miał Lambda
Funkcja działa na tej tabeli,

2328
01:42:52,340 --> 01:42:55,490
jeśli aktualizować opis przedmiotu, to będziesz
odebrać rekord off strumienia,

2329
01:42:55,490 --> 01:42:58,711
i będzie ona zaktualizować ElastiCache
wystąpienie z nowymi danymi.

2330
01:42:58,711 --> 01:43:00,460
Tak, że bardzo dużo
Co robimy z Lambda.

2331
01:43:00,460 --> 01:43:02,619
Jest to kod klej, złącza.

2332
01:43:02,619 --> 01:43:04,410
I faktycznie daje
możliwość uruchamiania

2333
01:43:04,410 --> 01:43:07,930
i działają bardzo złożonych aplikacji
bez dedykowanego serwera

2334
01:43:07,930 --> 01:43:10,371
infrastruktury, co jest naprawdę fajne.

2335
01:43:10,371 --> 01:43:13,100
>> Więc wróćmy do naszego
Architektura w czasie rzeczywistym głosu.

2336
01:43:13,100 --> 01:43:17,984
Jest to nowe i ulepszone z naszym
strumieni i KCL włączona obsługa aplikacji.

2337
01:43:17,984 --> 01:43:20,150
Takie same jak wcześniej, możemy
obsługiwać dowolną skalę wyborach.

2338
01:43:20,150 --> 01:43:21,100
Lubimy to.

2339
01:43:21,100 --> 01:43:24,770
Robimy się gromadzi scatter
w wielu wiadra.

2340
01:43:24,770 --> 01:43:26,780
Mamy zamek optymistyczne dzieje.

2341
01:43:26,780 --> 01:43:30,192
Możemy zachować nasze wyborców
zmianę głosu.

2342
01:43:30,192 --> 01:43:31,400
Mogą głosować tylko jeden raz.

2343
01:43:31,400 --> 01:43:32,880
To jest fantastyczne.

2344
01:43:32,880 --> 01:43:35,895
W czasie rzeczywistym, odporność na uszkodzenia,
skalowalne agregacja teraz.

2345
01:43:35,895 --> 01:43:38,270
Jeśli coś się przewróci, to
wie, gdzie uruchomi się ponownie

2346
01:43:38,270 --> 01:43:41,300
kiedy wraca, bo
używamy aplikacji KCI.

2347
01:43:41,300 --> 01:43:45,700
A potem możemy również używać,
Aplikacja KCL do pchania danych z

2348
01:43:45,700 --> 01:43:48,820
do przesunięcia ku czerwieni dla innych
Analityka aplikacji lub korzystanie

2349
01:43:48,820 --> 01:43:51,990
Elastyczna MapReduce uruchomić
czasie rzeczywistym transmisji strumieniowej skupiska off

2350
01:43:51,990 --> 01:43:53,180
tych danych.

2351
01:43:53,180 --> 01:43:55,480
>> To są rzeczy, my
nie mówił o dużo.

2352
01:43:55,480 --> 01:43:57,375
Ale są dodatkowe
technologie, które pochodzą

2353
01:43:57,375 --> 01:44:00,310
ponieść, jeśli szukasz
w tych różnych sytuacjach.

2354
01:44:00,310 --> 01:44:03,160
>> W porządku, więc to o
Analytics DynamoDB strumieni.

2355
01:44:03,160 --> 01:44:05,340
Można zbierać de duplikatem
danych, nie wszystkie rodzaje

2356
01:44:05,340 --> 01:44:09,490
miłych rzeczy, zagregowane dane w
pamięci, tworzenia tych tabel pochodnych.

2357
01:44:09,490 --> 01:44:13,110
To ogromny przypadek użycia
że wielu użytkowników

2358
01:44:13,110 --> 01:44:16,950
są zaangażowani, biorąc zagnieżdżona
Właściwości tych dokumentów JSON

2359
01:44:16,950 --> 01:44:18,946
i tworzenie dodatkowych indeksów.

2360
01:44:18,946 --> 01:44:21,680

2361
01:44:21,680 --> 01:44:23,150
>> Jesteśmy na końcu.

2362
01:44:23,150 --> 01:44:26,689
Dziękuję, mając ze mną.

2363
01:44:26,689 --> 01:44:28,480
Więc porozmawiajmy o
Architektura referencyjna.

2364
01:44:28,480 --> 01:44:33,440
DynamoDB siedzi w środku, tak
większość infrastruktury AWS.

2365
01:44:33,440 --> 01:44:37,090
W zasadzie można go podpiąć
do czegokolwiek chcesz.

2366
01:44:37,090 --> 01:44:45,600
Aplikacje zbudowane przy użyciu Dynamo to
Lambda, ElastiCache, CloudSearch,

2367
01:44:45,600 --> 01:44:49,890
wcisnąć się do danych Elastic
MapReduce, eksport import z DynamoDB

2368
01:44:49,890 --> 01:44:52,370
do S3, wszelkiego rodzaju przepływów pracy.

2369
01:44:52,370 --> 01:44:54,120
Ale chyba najlepszy
co o tym mówić,

2370
01:44:54,120 --> 01:44:56,119
i to jest to, co naprawdę
ciekawe jest to, kiedy

2371
01:44:56,119 --> 01:44:58,350
mówić o zastosowaniach zdarzeniami.

2372
01:44:58,350 --> 01:45:00,300
>> Jest to przykład
wewnętrzny projekt

2373
01:45:00,300 --> 01:45:04,850
że mamy gdzie jesteśmy naprawdę
publikowanie wyników badań w celu zebrania.

2374
01:45:04,850 --> 01:45:07,700
Więc w linku e-mail
wysyłamy, nie będziesz

2375
01:45:07,700 --> 01:45:11,350
być trochę Link mówiąc kliknięcie
tutaj, aby odpowiedzieć na pytania.

2376
01:45:11,350 --> 01:45:14,070
A gdy ktoś kliknie
linkujące, co się dzieje,

2377
01:45:14,070 --> 01:45:18,020
jest to ciągnąć w dół bezpieczne
HTML ankieta z S3.

2378
01:45:18,020 --> 01:45:18,980
Nie ma serwer.

2379
01:45:18,980 --> 01:45:20,600
To jest po prostu obiektem S3.

2380
01:45:20,600 --> 01:45:22,770
>> Ta forma pojawia się,
ładuje się w przeglądarce.

2381
01:45:22,770 --> 01:45:24,240
To nie ma kręgosłupa.

2382
01:45:24,240 --> 01:45:30,160
Ma kompleks JavaScript
że to działa.

2383
01:45:30,160 --> 01:45:33,557
Więc jest to bardzo bogata aplikacja
działa w przeglądarce klienta.

2384
01:45:33,557 --> 01:45:36,390
Oni nie wiedzą, że nie są one
interakcji z tylnym end.

2385
01:45:36,390 --> 01:45:38,220
W tym momencie, to wszystko jest przeglądarka.

2386
01:45:38,220 --> 01:45:41,780
>> Opublikują wyniki do tego, co
nazywamy Amazon API Gateway.

2387
01:45:41,780 --> 01:45:46,270
API Gateway to po prostu API internetowej
które można zdefiniować i podłączyć

2388
01:45:46,270 --> 01:45:47,760
do tego, co chcesz.

2389
01:45:47,760 --> 01:45:50,990
W tym konkretnym przypadku, że jesteśmy
podłączona do funkcji lambda.

2390
01:45:50,990 --> 01:45:54,797
>> Więc moja operacja POST jest
dzieje się z żadnym serwerem.

2391
01:45:54,797 --> 01:45:56,380
Zasadniczo, że API Brama tam siedzi.

2392
01:45:56,380 --> 01:45:58,770
To nic nie kosztuje mnie aż do ludzi
rozpocząć delegowania do niego, prawda?

2393
01:45:58,770 --> 01:46:00,269
Funkcja lambda po prostu stoi.

2394
01:46:00,269 --> 01:46:03,760
A to kosztuje mnie nic, dopóki
ludzie zaczynają się ukryć, że.

2395
01:46:03,760 --> 01:46:07,270
Dzięki czemu można zobaczyć, jak objętość
wzrasta, wtedy opłaty przyjść.

2396
01:46:07,270 --> 01:46:09,390
Nie uciekam serwer 7/24.

2397
01:46:09,390 --> 01:46:12,310
>> Więc wyciągnij formę
dół z wiadra,

2398
01:46:12,310 --> 01:46:15,719
i pisać za pośrednictwem interfejsu API
Brama do funkcji lambda.

2399
01:46:15,719 --> 01:46:17,510
A potem Lambda
Funkcja mówi, wiesz

2400
01:46:17,510 --> 01:46:20,600
co, mam pewne PIIs, niektóre
dane osobowe

2401
01:46:20,600 --> 01:46:21,480
W tych odpowiedzi.

2402
01:46:21,480 --> 01:46:23,020
Mam komentarzy pochodzących od użytkowników.

2403
01:46:23,020 --> 01:46:24,230
Mam adresy e-mail.

2404
01:46:24,230 --> 01:46:26,190
Mam nazw użytkowników.

2405
01:46:26,190 --> 01:46:27,810
>> Pozwól mi podzielić tę opcję.

2406
01:46:27,810 --> 01:46:30,280
Idę do generowania niektóre
metadane przy tej płycie.

2407
01:46:30,280 --> 01:46:32,850
I mam zamiar nacisnąć
metadane na DynamoDB.

2408
01:46:32,850 --> 01:46:36,059
I mógłbym zaszyfrować wszystkie dane
i wsuń go do DynamoDB jeśli chcę.

2409
01:46:36,059 --> 01:46:38,600
Ale jest to łatwiejsze dla mnie, w tym
używać sprawy, śmiało się wypowiedzieć,

2410
01:46:38,600 --> 01:46:42,800
Mam zamiar naciskać na surowych danych
do zaszyfrowanego S3 wiadra.

2411
01:46:42,800 --> 01:46:47,240
Więc używam zbudowany w stronie serwera S3
Zarządzanie kluczami szyfrowania i Amazon

2412
01:46:47,240 --> 01:46:51,600
Usługi tak, że mam klucz
obraca się w regularnych odstępach czasu,

2413
01:46:51,600 --> 01:46:55,010
i mogę ochrony tych danych PII
w ramach tej całej procedury.

2414
01:46:55,010 --> 01:46:55,870
>> Więc co ja zrobiłem?

2415
01:46:55,870 --> 01:47:00,397
Właśnie wdrożyć całość
aplikacji, a ja nie mam serwera.

2416
01:47:00,397 --> 01:47:02,980
Więc to, co zdarzeniami aplikacji
Architektura robi dla Ciebie.

2417
01:47:02,980 --> 01:47:05,730
>> Teraz, jeśli myślisz o
w przypadku zastosowania do this--

2418
01:47:05,730 --> 01:47:08,730
mamy innych klientów mówię
na temat tego dokładnym architektury, którzy

2419
01:47:08,730 --> 01:47:14,560
uruchomić fenomenalnie duże kampanie, którzy
patrząc na to i będzie, o mój.

2420
01:47:14,560 --> 01:47:17,840
Bo teraz, mogą
po prostu wcisnąć go tam,

2421
01:47:17,840 --> 01:47:21,900
pozwól, że kampanię tylko siedzieć
tam, dopóki nie uruchamia, a nie

2422
01:47:21,900 --> 01:47:24,400
musiał martwić się rys na temat
jaki rodzaj infrastruktury

2423
01:47:24,400 --> 01:47:26,120
będzie tam, aby go wesprzeć.

2424
01:47:26,120 --> 01:47:28,600
A następnie, gdy tylko
że kampania jest zrobione,

2425
01:47:28,600 --> 01:47:31,520
to jak na infrastrukturę
po prostu od razu odchodzi

2426
01:47:31,520 --> 01:47:33,680
bo nie bardzo
ma infrastruktury.

2427
01:47:33,680 --> 01:47:35,660
To tylko kod, który siedzi na Lambda.

2428
01:47:35,660 --> 01:47:38,560
To tylko dane, które siedzi w DynamoDB.

2429
01:47:38,560 --> 01:47:41,340
Jest to niesamowity sposób
do tworzenia aplikacji.

2430
01:47:41,340 --> 01:47:43,970
>> PUBLICZNOŚCI: Więc jest to bardziej
efemeryczne niż byłoby to

2431
01:47:43,970 --> 01:47:45,740
jeśli został zapisany na rzeczywistym serwerze?

2432
01:47:45,740 --> 01:47:46,823
>> RICK HOULIHAN: Absolutnie.

2433
01:47:46,823 --> 01:47:49,190
Bo tej instancji serwera
musiałby być 7/24.

2434
01:47:49,190 --> 01:47:51,954
To musi być dostępna dla
ktoś odpowiedzieć.

2435
01:47:51,954 --> 01:47:52,620
No wiecie co?

2436
01:47:52,620 --> 01:47:55,410
S3 jest dostępny 24/7.

2437
01:47:55,410 --> 01:47:57,100
S3 zawsze reaguje.

2438
01:47:57,100 --> 01:47:59,320
S3 jest bardzo, bardzo dobry
w obsługujących obiekty.

2439
01:47:59,320 --> 01:48:02,590
Obiekty te mogą być pliki HTML, lub
Pliki JavaScript, albo co chcesz.

2440
01:48:02,590 --> 01:48:07,430
Możesz uruchomić bardzo bogatych aplikacji internetowych
z wiader S3, i ludzie.

2441
01:48:07,430 --> 01:48:10,160
>> A więc to pomysł tutaj
jest uciec z drogi

2442
01:48:10,160 --> 01:48:11,270
kiedyś o tym myśleć.

2443
01:48:11,270 --> 01:48:14,270
Wszyscy wykorzystywane do myślenia
Warunki serwerów i hostów.

2444
01:48:14,270 --> 01:48:16,580
Nie chodzi o to, że już.

2445
01:48:16,580 --> 01:48:19,310
Chodzi o infrastrukturę jako kod.

2446
01:48:19,310 --> 01:48:22,470
Wdrażanie kod do chmury i
niech chmura uruchomić go dla Ciebie.

2447
01:48:22,470 --> 01:48:24,980
I to właśnie AWS próbuje zrobić.

2448
01:48:24,980 --> 01:48:29,690
>> PUBLICZNOŚCI: Tak skrzynce złota w środku
API serwer bramy nie jest podobny,

2449
01:48:29,690 --> 01:48:30,576
ale zamiast tego jest just--

2450
01:48:30,576 --> 01:48:32,850
>> RICK HOULIHAN: Można myśleć
o tym, jak fasady serwera.

2451
01:48:32,850 --> 01:48:38,040
Wszystko to jest to zajmie HTTP
żądania i mapować go do innego procesu.

2452
01:48:38,040 --> 01:48:39,192
To wszystko, co robi.

2453
01:48:39,192 --> 01:48:41,525
I w tym przypadku, mamy do mapowania
go do funkcji lambda.

2454
01:48:41,525 --> 01:48:44,119

2455
01:48:44,119 --> 01:48:45,410
W porządku, więc to wszystko, co mam.

2456
01:48:45,410 --> 01:48:46,190
Dziękuję Ci bardzo.

2457
01:48:46,190 --> 01:48:46,800
Doceniam to.

2458
01:48:46,800 --> 01:48:48,100
Wiem, że chcemy się trochę w czasie.

2459
01:48:48,100 --> 01:48:49,980
I miejmy nadzieję, że dostaliście
trochę informacji

2460
01:48:49,980 --> 01:48:51,410
że można zabrać dziś.

2461
01:48:51,410 --> 01:48:53,520
I przepraszam, jeśli poszedłem
na niektóre z waszych głowach,

2462
01:48:53,520 --> 01:48:56,697
ale jest to dobry dużo
podstawowej wiedzy fundamentalne

2463
01:48:56,697 --> 01:48:58,280
że myślę, że jest bardzo cenne dla Ciebie.

2464
01:48:58,280 --> 01:48:59,825
Więc dziękuję za zaproszenie.

2465
01:48:59,825 --> 01:49:00,325
[OKLASKI]

2466
01:49:00,325 --> 01:49:02,619
PUBLICZNOŚCI: [niesłyszalne]
jest, kiedy mówiłeś

2467
01:49:02,619 --> 01:49:05,160
trzeba było przejść przez coś
od początku do końca

2468
01:49:05,160 --> 01:49:07,619
aby uzyskać prawo wartości
lub te same wartości,

2469
01:49:07,619 --> 01:49:09,410
W jaki sposób wartości
zmienić, jeśli [niesłyszalne].

2470
01:49:09,410 --> 01:49:10,480
>> RICK HOULIHAN: Och, idempotent?

2471
01:49:10,480 --> 01:49:11,800
Jak wartości zmienić?

2472
01:49:11,800 --> 01:49:15,180
No, bo jeśli nie uruchomić
to aż do końca,

2473
01:49:15,180 --> 01:49:19,770
to ja nie wiem, co się zmienia
zostały wykonane w ostatniej mili.

2474
01:49:19,770 --> 01:49:22,144
To nie będzie to
same dane, co widziałem.

2475
01:49:22,144 --> 01:49:24,560
PUBLICZNOŚCI: Oh, więc po prostu
nie dostał całą wejście.

2476
01:49:24,560 --> 01:49:24,770
RICK HOULIHAN: Racja.

2477
01:49:24,770 --> 01:49:26,895
Trzeba przejść od początku
do końca, a następnie jest

2478
01:49:26,895 --> 01:49:29,280
będzie spójna.

2479
01:49:29,280 --> 01:49:31,520
Fajne.

2480
01:49:31,520 --> 01:49:35,907
>> PUBLICZNOŚCI: Więc pokazał nam DynamoDB
może zrobić dokument lub wartość klucza.

2481
01:49:35,907 --> 01:49:38,740
I spędziliśmy dużo czasu na
wartość klucza z hash i sposobów

2482
01:49:38,740 --> 01:49:40,005
aby obrócić go wokół.

2483
01:49:40,005 --> 01:49:43,255
Kiedy spojrzał na tych stołach, jest to, że
pozostawiając podejścia dokumentu?

2484
01:49:43,255 --> 01:49:44,600
>> RICK HOULIHAN: Nie
powiedzieć, pozostawiając w tyle.

2485
01:49:44,600 --> 01:49:45,855
>> PUBLICZNOŚCI: one były oddzielone od the--

2486
01:49:45,855 --> 01:49:49,140
>> RICK HOULIHAN: Z dokumentu
Podejście, typ dokumentu w DynamoDB

2487
01:49:49,140 --> 01:49:50,880
jest po prostu myśleć jako innego atrybutu.

2488
01:49:50,880 --> 01:49:53,560
Jest to atrybut, który zawiera
hierarchiczna struktura danych.

2489
01:49:53,560 --> 01:49:56,980
A następnie w zapytaniach
można użyć właściwości

2490
01:49:56,980 --> 01:49:59,480
z tych obiektów Object Notation wykorzystujących.

2491
01:49:59,480 --> 01:50:03,562
Więc mogę filtrować zagnieżdżone
Obiekt dokumentu JSON.

2492
01:50:03,562 --> 01:50:05,520
PUBLICZNOŚCI: Więc za każdym razem mam
zrobić podejście dokumentu,

2493
01:50:05,520 --> 01:50:07,906
Mogę rodzaju przybyć tabular--

2494
01:50:07,906 --> 01:50:08,780
PUBLICZNOŚCI: Absolutnie.

2495
01:50:08,780 --> 01:50:09,800
WIDOWNI: --indexes i
rzeczy po prostu rozmawialiśmy.

2496
01:50:09,800 --> 01:50:11,280
RICK HOULIHAN: Tak,
indeksy i to wszystko,

2497
01:50:11,280 --> 01:50:13,363
jeśli chcesz indeksować
właściwości JSON,

2498
01:50:13,363 --> 01:50:18,230
sposób, w jaki my mamy na to jest, jeśli
wstawieniu obiektu JSON lub dokument

2499
01:50:18,230 --> 01:50:20,780
w Dynamo, należy użyć strumieni.

2500
01:50:20,780 --> 01:50:22,400
Strumienie czytał wejście.

2501
01:50:22,400 --> 01:50:24,340
Można by się, że JSON
obiektu i można by powiedzieć, OK,

2502
01:50:24,340 --> 01:50:26,030
co jest własnością Chcę indeksu?

2503
01:50:26,030 --> 01:50:28,717
>> Tworzenia tabeli pochodnych.

2504
01:50:28,717 --> 01:50:30,300
Teraz to tak działa teraz.

2505
01:50:30,300 --> 01:50:32,650
Nie dopuszczamy do indeksu
bezpośrednio te właściwości.

2506
01:50:32,650 --> 01:50:33,520
>> PUBLICZNOŚCI: Tabularizing dokumentów.

2507
01:50:33,520 --> 01:50:36,230
>> RICK HOULIHAN: Dokładnie, spłaszczenie
Opisz tabularizing go dokładnie.

2508
01:50:36,230 --> 01:50:37,415
To, co z nim zrobić.

2509
01:50:37,415 --> 01:50:37,860
>> PUBLICZNOŚCI: Dziękuję.

2510
01:50:37,860 --> 01:50:39,609
>> RICK HOULIHAN: Tak,
absolutnie, dziękuję.

2511
01:50:39,609 --> 01:50:42,240
PUBLICZNOŚCI: Więc jest to rodzaj
Mongo spełnia classifers REDIS.

2512
01:50:42,240 --> 01:50:43,990
>> RICK HOULIHAN: Tak,
to dużo tak.

2513
01:50:43,990 --> 01:50:45,940
To dobry opis do niego.

2514
01:50:45,940 --> 01:50:47,490
Fajne.

2515
01:50:47,490 --> 01:50:49,102