1
00:00:00,000 --> 00:00:04,969
>> [음악 재생]

2
00:00:04,969 --> 00:00:06,010
릭 리한 (Houlihan) : 좋아.

3
00:00:06,010 --> 00:00:06,600
안녕하세요, 여러분.

4
00:00:06,600 --> 00:00:07,670
내 이름은 릭 리한 (Houlihan)입니다.

5
00:00:07,670 --> 00:00:10,330
나는 수석 교장 해요
AWS에서 솔루션 설계자.

6
00:00:10,330 --> 00:00:14,070
내가 NoSQL에에 초점
DynamoDB의 기술.

7
00:00:14,070 --> 00:00:16,930
나는 얘기를 오늘 여기있어
당신이 이들에 대해 조금.

8
00:00:16,930 --> 00:00:18,970
>> 내 배경은
주로 데이터 층.

9
00:00:18,970 --> 00:00:21,390
나는 반 내 개발을 보냈다
경력, 데이터베이스를 작성

10
00:00:21,390 --> 00:00:25,930
데이터 액세스 솔루션
다양한 응용 프로그램.

11
00:00:25,930 --> 00:00:30,000
나는 클라우드 가상화에 있었어요
약 20 년 동안.

12
00:00:30,000 --> 00:00:33,460
클라우드는 클라우드 전에 그래서,
우리는 유틸리티 컴퓨팅을 호출하는 데 사용.

13
00:00:33,460 --> 00:00:37,170
그리고 생각, 그것은처럼되었다
PG & E는, 당신은 당신이 무엇을 사용 비용을 지불합니다.

14
00:00:37,170 --> 00:00:38,800
오늘 우리는 클라우드를 호출합니다.

15
00:00:38,800 --> 00:00:41,239
>> 그러나 지난 몇 년 동안, 나는 일했다
회사의 커플

16
00:00:41,239 --> 00:00:42,530
당신은 아마 들어 본 적이없는.

17
00:00:42,530 --> 00:00:47,470
하지만 기술의 목록을 뽑아 봤어요
업적, 나는 당신이 말하는 것 같아요.

18
00:00:47,470 --> 00:00:51,620
나는 클라우드 시스템에 여덟 개의 특허를 가지고
가상화, 마이크로 프로세서 설계,

19
00:00:51,620 --> 00:00:54,440
복합 이벤트 처리,
다른 지역뿐만 아니라.

20
00:00:54,440 --> 00:00:58,290
>> 요즘 그래서, NoSQL에에 주로 초점
기술 및 차세대

21
00:00:58,290 --> 00:00:59,450
데이터 베이스.

22
00:00:59,450 --> 00:01:03,370
그리고 내가 갈거야 무엇 일반적이다
에 대해 오늘 이야기를 여기에.

23
00:01:03,370 --> 00:01:06,030
그래서 당신은 무엇을 기대할 수
이 세션에서,

24
00:01:06,030 --> 00:01:08,254
우리는 간단한 통과합니다
데이터 처리의 이력.

25
00:01:08,254 --> 00:01:10,420
그것은 항상 도움
우리가 어디에서 왔는지 이해

26
00:01:10,420 --> 00:01:12,400
우린 왜 우리가있는 곳.

27
00:01:12,400 --> 00:01:15,600
그리고 우리는 조금 얘기하자
NoSQL에 기술에 대한 비트

28
00:01:15,600 --> 00:01:17,500
기본적인 관점에서.

29
00:01:17,500 --> 00:01:19,870
>> 우리는 몇 가지로 얻을 것이다
DynamoDB의 내부.

30
00:01:19,870 --> 00:01:24,350
DynamoDB의는 AWS의 더 맛이 없다.

31
00:01:24,350 --> 00:01:27,340
그것은 완벽하게 관리 그리고
호스팅 NoSQL에 솔루션을 제공합니다.

32
00:01:27,340 --> 00:01:32,420
그리고 우리는 테이블에 대해 조금 얘기하자
구조의 API, 데이터 형식, 인덱스

33
00:01:32,420 --> 00:01:35,177
그리고 내부의 일부
그 DynamoDB의 기술.

34
00:01:35,177 --> 00:01:37,760
우리는 디자인의 일부에 얻을 것이다
패턴 및 모범 사례.

35
00:01:37,760 --> 00:01:39,968
우리는 방법에 대해 얘기하자
일부 이러한 기술을 사용하여

36
00:01:39,968 --> 00:01:41,430
오늘의 응용 프로그램.

37
00:01:41,430 --> 00:01:44,820
그리고 우리는 조금 얘기하자
진화 또는 출현에 대한

38
00:01:44,820 --> 00:01:48,980
프로그래밍의 새로운 패러다임
라는 이벤트 기반 응용 프로그램

39
00:01:48,980 --> 00:01:51,580
및 DynamoDB의뿐만 아니라 그에서 재생하는 방법.

40
00:01:51,580 --> 00:01:54,690
그리고 우리는 당신에게 약간을 떠날거야
참조 아키텍처 토론

41
00:01:54,690 --> 00:01:59,540
그래서 우리는 몇 가지에 대해 이야기 할 수 있습니다
방법 당신은 DynamoDB의를 사용할 수 있습니다.

42
00:01:59,540 --> 00:02:04,116
>> 그래서 먼저이 질문은 off--
나는 많은 데이터베이스 무엇이다 듣는다.

43
00:02:04,116 --> 00:02:06,240
많은 사람들은 생각
데이터베이스가 무엇인지 알고있다.

44
00:02:06,240 --> 00:02:08,360
구글 당신, 당신은이를 볼 수 있습니다.

45
00:02:08,360 --> 00:02:11,675
그것은 보유 데이터의 구조화 된 집합이다
컴퓨터, 특히 하나의 그

46
00:02:11,675 --> 00:02:13,600
다양한 방법으로 액세스 할 수 있습니다.

47
00:02:13,600 --> 00:02:16,992
그게 좋은 생각
현대 데이터베이스의 정의.

48
00:02:16,992 --> 00:02:19,450
그러나 나는 때문에 그것을 좋아하지 않아
그것은 몇 가지를 의미한다.

49
00:02:19,450 --> 00:02:20,935
이 구조를 의미한다.

50
00:02:20,935 --> 00:02:23,120
그리고 그것이 컴퓨터에 있다는 것을 의미한다.

51
00:02:23,120 --> 00:02:25,750
그리고 데이터베이스는하지 않았다
컴퓨터에 항상 존재한다.

52
00:02:25,750 --> 00:02:28,020
데이터베이스는 실제로 다양한 방식으로 존재하고 있었다.

53
00:02:28,020 --> 00:02:32,000
>> 그렇게 더 나은 정의
데이터베이스는이 같은 것입니다.

54
00:02:32,000 --> 00:02:34,786
데이터베이스는 구성되어 있습니다
저장, 관리하기위한 메커니즘,

55
00:02:34,786 --> 00:02:35,910
및 정보를 검색.

56
00:02:35,910 --> 00:02:36,868
이 About.com에서입니다.

57
00:02:36,868 --> 00:02:42,080
그래서 난 정말 회담 그것 때문이 좋아
대한 데이터베이스 저장소되고,

58
00:02:42,080 --> 00:02:44,800
의 저장소
정보, 반드시

59
00:02:44,800 --> 00:02:46,780
컴퓨터에 앉아 뭔가.

60
00:02:46,780 --> 00:02:49,290
그리고 역사를 통해, 우리
항상 컴퓨터를 없었어요.

61
00:02:49,290 --> 00:02:52,110
>> 지금, 나는 평균을 요구하는 경우
무엇 개발자 오늘

62
00:02:52,110 --> 00:02:54,770
데이터베이스, 그건 내가 할 대답.

63
00:02:54,770 --> 00:02:56,070
어딘가에 나는 물건을 부착 할 수 있습니다.

64
00:02:56,070 --> 00:02:56,670
권리?

65
00:02:56,670 --> 00:02:58,725
그리고 그것은 사실입니다.

66
00:02:58,725 --> 00:02:59,600
그러나 그것은 불행한 일.

67
00:02:59,600 --> 00:03:02,700
데이터베이스가 정말 때문에
현대 응용 프로그램의 기초.

68
00:03:02,700 --> 00:03:04,810
이 재단의
모든 응용 프로그램입니다.

69
00:03:04,810 --> 00:03:07,240
그리고 당신은 그 구축 방법
데이터베이스, 어떻게 구조

70
00:03:07,240 --> 00:03:11,750
데이터는 어떻게을 지시 할 것입니다
당신이 확장으로 응용 프로그램을 수행한다.

71
00:03:11,750 --> 00:03:14,640
>> 그래서 내 일 오늘의 많은
다루는 무엇

72
00:03:14,640 --> 00:03:17,180
때 개발자 발생
이 접근 방식을

73
00:03:17,180 --> 00:03:19,510
과 여파 처리
응용 프로그램의

74
00:03:19,510 --> 00:03:24,966
이제 원래의 이상으로 확장된다
나쁜 디자인의 의도와 고통.

75
00:03:24,966 --> 00:03:26,840
그래서 희망이 때를
오늘 도보 거리에, 당신은거야

76
00:03:26,840 --> 00:03:29,010
도구의 몇가
당신하겠습니다 벨트

77
00:03:29,010 --> 00:03:32,566
그 같은 실수에서.

78
00:03:32,566 --> 00:03:33,066
괜찮아.

79
00:03:33,066 --> 00:03:36,360
그럼 약간에 대해 이야기하자
데이터베이스 기술의 타임 라인.

80
00:03:36,360 --> 00:03:38,830
내가 읽기 생각
기사없는 그 오래 전

81
00:03:38,830 --> 00:03:43,020
그것은 lines--에 뭔가를 말했다
그것은 매우 시적인 문장이다.

82
00:03:43,020 --> 00:03:46,590
그것은 말했다 역사
데이터의 처리는

83
00:03:46,590 --> 00:03:49,350
하이 워터 마크의 전체
데이터의 풍요 로움.

84
00:03:49,350 --> 00:03:49,920
그래.

85
00:03:49,920 --> 00:03:52,532
지금, 나는 그 종류의 사실 것 같아요.

86
00:03:52,532 --> 00:03:54,990
하지만 실제로에서있는 그대로 봐
역사는 실제로 가득

87
00:03:54,990 --> 00:03:56,820
데이터 압력 높은 워터 마크.

88
00:03:56,820 --> 00:04:00,040
의 데이터 레이트 때문에
섭취 다운되지 않습니다.

89
00:04:00,040 --> 00:04:01,360
그것은 단지 올라갑니다.

90
00:04:01,360 --> 00:04:03,670
>> 그리고 혁신은 때 발생
우리는 데이터를 압력을 참조한다

91
00:04:03,670 --> 00:04:07,825
데이터의 양은
지금 시스템으로 오는.

92
00:04:07,825 --> 00:04:12,027
그리고 처리 할 수​​ 없습니다
효율적으로 시간이나 비용 중 하나.

93
00:04:12,027 --> 00:04:14,110
우리가 시작할 때 그리고 그건
데이터 압력에서 볼 수 있습니다.

94
00:04:14,110 --> 00:04:15,920
>> 그래서 우리는 볼 때
첫 번째 데이터베이스,이

95
00:04:15,920 --> 00:04:17,180
우리의 귀 사이에 있었던 것입니다.

96
00:04:17,180 --> 00:04:18,310
우리는 모든 그것으로 태어난 것입니다.

97
00:04:18,310 --> 00:04:19,194
그것은 좋은 데이터베이스입니다.

98
00:04:19,194 --> 00:04:21,110
그것은 높은 가용성을 가지고있다.

99
00:04:21,110 --> 00:04:21,959
그것은 항상이다.

100
00:04:21,959 --> 00:04:23,930
당신은 항상 그것을 얻을 수 있습니다.

101
00:04:23,930 --> 00:04:24,890
>> 그러나 단일 사용자입니다.

102
00:04:24,890 --> 00:04:26,348
당신과 함께 내 생각을 공유 할 수 없습니다.

103
00:04:26,348 --> 00:04:28,370
당신은 내 생각을 얻을 수 없다
당신이 그들을 원하는 경우.

104
00:04:28,370 --> 00:04:30,320
그리고 그들의 abilitiy 그렇게 좋지 않다.

105
00:04:30,320 --> 00:04:32,510
우리는 일을 잊어 버려.

106
00:04:32,510 --> 00:04:36,540
모든 이제 다음, 우리 중 하나 잎
다른 존재로 이동

107
00:04:36,540 --> 00:04:39,110
우리는 모든 것을 잃을
즉, 해당 데이터베이스에 있었다.

108
00:04:39,110 --> 00:04:40,640
그래서 모두 좋지 않다.

109
00:04:40,640 --> 00:04:43,189
>> 그리고이 시간이 지남에 잘 작동
우리는 하루에 다시있을 때

110
00:04:43,189 --> 00:04:46,230
때 우리가 정말 알고하는 데 필요한 모든가
여기서 우리는 내일 갈거야

111
00:04:46,230 --> 00:04:49,630
또는 우리는 최고의 음식을 수집한다.

112
00:04:49,630 --> 00:04:52,820
그러나 우리는 시작으로로 성장하기
문명과 정부가 시작

113
00:04:52,820 --> 00:04:55,152
존재에 와서하기
기업은 진화하기 시작했다

114
00:04:55,152 --> 00:04:57,360
우리는 우리를 실현하기 시작
보다 조금 더 필요

115
00:04:57,360 --> 00:04:58,210
우리는 우리의 머리에 넣어 수 있습니다.

116
00:04:58,210 --> 00:04:58,870
괜찮아?

117
00:04:58,870 --> 00:05:00,410
>> 우리는 기록의 시스템을 필요로했다.

118
00:05:00,410 --> 00:05:02,220
우리는 수 데이터를 저장 할 곳이 필요했다.

119
00:05:02,220 --> 00:05:05,450
그래서 우리는 서면으로 문서를 시작
도서관과 아카이브를 생성.

120
00:05:05,450 --> 00:05:08,000
우리는 개발을 시작
시스템 원장 회계.

121
00:05:08,000 --> 00:05:12,200
그리고 원장 계수의 시스템
여러 세기 동안 세계를 실행

122
00:05:12,200 --> 00:05:15,580
어쩌면 천년으로
우리는 종류의 점에 성장

123
00:05:15,580 --> 00:05:18,420
여기서, 그 데이터로드 능가
이러한 시스템의 능력

124
00:05:18,420 --> 00:05:19,870
를 포함 할 수 있습니다.

125
00:05:19,870 --> 00:05:22,070
>> 그리고이 사실은 1880 년대에 일어났다.

126
00:05:22,070 --> 00:05:22,570
권리?

127
00:05:22,570 --> 00:05:24,390
1880 미국 인구 조사에서.

128
00:05:24,390 --> 00:05:26,976
이 곳 터닝 정말
현대의 데이터 처리를 가리.

129
00:05:26,976 --> 00:05:28,850
이 지점에서이다
데이터의하는 양

130
00:05:28,850 --> 00:05:32,060
그가에 의해 수집되고 있었다
미국 정부는 지점에 도착

131
00:05:32,060 --> 00:05:34,005
그것은 어디에서 처리 할 팔년했다.

132
00:05:34,005 --> 00:05:36,350
>> 이제 여덟 years--으로
당신은 인구 조사를 알고

133
00:05:36,350 --> 00:05:39,180
실행 매 10 years--을가 그래서
꽤 분명 그 시간에 의해 우리

134
00:05:39,180 --> 00:05:41,419
, 1890 년 인구 조사를 얻었다
데이터의 양은 그

135
00:05:41,419 --> 00:05:43,210
처리 할 거라고
정부이었다

136
00:05:43,210 --> 00:05:46,335
10 년을 초과하는 것 그것이 그
발사 된 새로운 인구 조사에 걸릴 것이다.

137
00:05:46,335 --> 00:05:47,250
이 문제였다.

138
00:05:47,250 --> 00:05:49,000
>> 그래서 사람은 허먼 이름
홀러리스는 따라왔다

139
00:05:49,000 --> 00:05:52,640
그는 단위 기록 펀치를 발명
카드, 펀치 카드 판독기, 펀치 카드

140
00:05:52,640 --> 00:05:58,420
도표 작성 및 데이터 정렬
이 기술에 대한 메커니즘.

141
00:05:58,420 --> 00:06:01,860
그리고 그는 형성 그 회사
시간, 다른 사람의 부부와 함께,

142
00:06:01,860 --> 00:06:05,450
실제로되었다의 기둥 중 하나
오늘날 우리가 알고있는 작은 회사는 IBM이라고합니다.

143
00:06:05,450 --> 00:06:08,417
>> 그래서 IBM은 원래 있었다
데이터베이스 사업.

144
00:06:08,417 --> 00:06:09,750
그리고 그들이 무슨 짓을했는지 정말.

145
00:06:09,750 --> 00:06:11,110
이들은 데이터 처리를했다.

146
00:06:11,110 --> 00:06:15,400
>> 펀치의 확산 않도록
카드, 독창적 인 메커니즘

147
00:06:15,400 --> 00:06:18,560
의를 활용할 수있는
기술은 정렬 된 결과 세트를 폴링합니다.

148
00:06:18,560 --> 00:06:20,726
이 그림에서 볼 수 있습니다
거기에서 우리는 little--이

149
00:06:20,726 --> 00:06:23,970
그것은 조금 small--입니다하지만 당신은 볼 수 있습니다
매우 정교한 기계기구

150
00:06:23,970 --> 00:06:26,970
우리는 펀치 카드 덱을한다.

151
00:06:26,970 --> 00:06:28,720
그리고 누군가의 촬영
작은 드라이버

152
00:06:28,720 --> 00:06:31,400
그리고 통해 나와
슬롯을 들어 올려

153
00:06:31,400 --> 00:06:34,820
그 경기를 얻을 것과
분류 결과를 설정합니다.

154
00:06:34,820 --> 00:06:36,270
>> 이는 집합이다.

155
00:06:36,270 --> 00:06:38,690
우리는 모든 시간을
컴퓨터의 오늘,

156
00:06:38,690 --> 00:06:40,100
데이터베이스에서이를 수행한다.

157
00:06:40,100 --> 00:06:41,620
우리는 바로 수동으로 수행하는 데 사용?

158
00:06:41,620 --> 00:06:42,994
사람들은 함께이 일을 시작했습니다.

159
00:06:42,994 --> 00:06:45,440
그리고 그것은 확산했다
이 펀치 카드의

160
00:06:45,440 --> 00:06:50,070
우리가 이른바 데이터 드럼에
데이터 릴, 종이 테이프.

161
00:06:50,070 --> 00:06:55,980
>> 데이터 프로세싱 업계했다
플레이어 피아노에서 교훈.

162
00:06:55,980 --> 00:06:57,855
플레이어는 다시 피아노
세기의 전환기

163
00:06:57,855 --> 00:07:02,100
슬롯에 용지 릴을 사용하는 데 사용
에 그것을 재생하려면 어떤 키를 알 수 있습니다.

164
00:07:02,100 --> 00:07:05,380
이 기술은 적응했다 그래서
결국, 디지털 데이터를 저장할

165
00:07:05,380 --> 00:07:08,070
그들은 데이터를 넣을 수 있기 때문에
그 종이 테이프 릴 위에.

166
00:07:08,070 --> 00:07:10,870
>> 이제, 그 결과, 데이터
어떻게 ... 사실상되었다

167
00:07:10,870 --> 00:07:14,960
이 데이터는 직접했다 액세스
당신이 그것을 저장 방법에 따라 다릅니다.

168
00:07:14,960 --> 00:07:17,825
그래서 테이프에 데이터를 배치하는 경우,
I는 선형 데이터를 액세스 하였다.

169
00:07:17,825 --> 00:07:20,475
나는 전체를 출시했다
테이프는 모든 데이터에 액세스 할 수 있습니다.

170
00:07:20,475 --> 00:07:22,600
나는 펀치에 데이터를 배치하는 경우
카드, 나는 그것을 액세스 할 수

171
00:07:22,600 --> 00:07:26,270
좀 더 임의의
패션, 아마 빨리.

172
00:07:26,270 --> 00:07:30,770
>> 그러나 방법에 한계가 있었다 우리
저장된 방법에 따라 데이터에 액세스 할 수 있습니다.

173
00:07:30,770 --> 00:07:32,890
그래서이 문제였다
50 년대에 가고.

174
00:07:32,890 --> 00:07:37,890
다시 말하지만, 우리는 같은 것을 볼 시작할 수 있습니다
처리 할 수​​있는 새로운 기술을 개발

175
00:07:37,890 --> 00:07:41,670
데이터는, 바로 그것이 연다
새로운 솔루션에 대한 문,

176
00:07:41,670 --> 00:07:45,852
새로운 프로그램, 새로운
해당 데이터에 대한 응용 프로그램.

177
00:07:45,852 --> 00:07:47,810
그리고 정말, 지배
이유일지도 모른다

178
00:07:47,810 --> 00:07:49,435
왜 우리는이 시스템의 일부를 개발했다.

179
00:07:49,435 --> 00:07:52,290
그러나 사업은 급속하게되었다
진화 뒤에 드라이버

180
00:07:52,290 --> 00:07:54,720
현대 데이터베이스 및
현대 파일 시스템.

181
00:07:54,720 --> 00:07:56,870
>> 다음 일은 있도록
50 년대에 등장했다

182
00:07:56,870 --> 00:08:00,780
파일 시스템이었다
랜덤 액세스 저장 장치의 개발.

183
00:08:00,780 --> 00:08:02,050
이 아름다웠다.

184
00:08:02,050 --> 00:08:06,230
이제, 갑자기, 우리는 넣을 수 있습니다 우리의
이 하드 드라이브의 어느 곳에서나 파일

185
00:08:06,230 --> 00:08:09,760
우리는 무작위로이 데이터에 액세스 할 수 있습니다.

186
00:08:09,760 --> 00:08:11,950
우리는 그것을 분석 할 수
파일 중 정보.

187
00:08:11,950 --> 00:08:14,920
그리고 우리는 세계의 모든 해결
데이터 처리 문제.

188
00:08:14,920 --> 00:08:17,550
>> 그리고 그 지속에 대한 20
진화 될 때까지 삼십년

189
00:08:17,550 --> 00:08:22,100
관계형 데이터베이스, 어떤
세계는 지금​​ 우리를 결정했을 때입니다

190
00:08:22,100 --> 00:08:27,940
패배 저장소가 필요합니다
파일에서 데이터의 무분별한 확산

191
00:08:27,940 --> 00:08:29,540
우리가 구축 한 시스템. 권리?

192
00:08:29,540 --> 00:08:34,270
너무 많은 분포 너무 많은 데이터
장소, 데이터의 중복,

193
00:08:34,270 --> 00:08:37,120
스토리지의 비용은 엄청난이었다.

194
00:08:37,120 --> 00:08:43,760
>> 70 년대에, 가장 비싼 자원
컴퓨터가 가진 것을 기억했다.

195
00:08:43,760 --> 00:08:46,200
프로세서이었다
고정 비용으로 간주.

196
00:08:46,200 --> 00:08:49,030
나는 상자를 구입하면,
CPU는 몇 가지 작업을 수행합니다.

197
00:08:49,030 --> 00:08:51,960
그것은 여부를 회전 할 것
실제로 작동 여부입니다.

198
00:08:51,960 --> 00:08:53,350
그건 정말 고정 비용이다.

199
00:08:53,350 --> 00:08:56,030
>> 그러나 나를 비용
비즈니스 스토리지입니다.

200
00:08:56,030 --> 00:09:00,020
나는 옆에 더 디스크를 구입해야하는 경우
월, 그게 내가 지불하는 실제 비용입니다.

201
00:09:00,020 --> 00:09:01,620
그리고 그 기억은 비싸다.

202
00:09:01,620 --> 00:09:05,020
>> 이제 우리는 빨리 감기 40년
그리고 우리는 다른 문제가있다.

203
00:09:05,020 --> 00:09:10,020
계산은 지금이다
가장 비싼 자원.

204
00:09:10,020 --> 00:09:11,470
스토리지는 저렴합니다.

205
00:09:11,470 --> 00:09:14,570
나는 우리가 아무 곳이나 갈 수있는, 의미
구름과 우리는 저렴한 스토리지를 찾을 수 있습니다.

206
00:09:14,570 --> 00:09:17,190
하지만 내가 무엇을 찾을 수없는 것은 싼 계산이다.

207
00:09:17,190 --> 00:09:20,700
>> 오늘날의 진화 그래서
기술, 데이터베이스 기술,

208
00:09:20,700 --> 00:09:23,050
정말 주위에 초점을 맞추고 있습니다
분산 데이터베이스

209
00:09:23,050 --> 00:09:26,960
그 고생하지 않는다
규모의 동일한 유형

210
00:09:26,960 --> 00:09:29,240
관계형 데이터베이스의 한계.

211
00:09:29,240 --> 00:09:32,080
우리에 대해 조금 얘기하자
그 사실은 무엇을 의미하는지.

212
00:09:32,080 --> 00:09:34,760
>> 그러나 이유 중 하나는
이 항아리 우리 뒤에 드라이버

213
00:09:34,760 --> 00:09:38,290
데이터 압력에 대해 이야기했다.

214
00:09:38,290 --> 00:09:41,920
데이터 압력은 뭔가
그 혁신을 주도합니다.

215
00:09:41,920 --> 00:09:44,610
그리고 당신은에서를 통해 보면
지난 5 년 동안,

216
00:09:44,610 --> 00:09:48,180
이것은 무엇 데이터의 차트
일반 기업에서 부하

217
00:09:48,180 --> 00:09:49,640
지난 5 년처럼 보인다.

218
00:09:49,640 --> 00:09:52,570
>> 그리고 엄지 손가락의 일반적인 규칙
이 days-- 당신은 Google-- 가면

219
00:09:52,570 --> 00:09:55,290
데이터의 90 %는 그
우리는 현재 저장하고 있었다

220
00:09:55,290 --> 00:09:57,330
지난 2 년 이내에 발생.

221
00:09:57,330 --> 00:09:57,911
그래.

222
00:09:57,911 --> 00:09:59,410
지금,이 새로운 추세는 아니다.

223
00:09:59,410 --> 00:10:01,230
이되었습니다 추​​세
100 년 외출.

224
00:10:01,230 --> 00:10:03,438
적 허먼 홀러리스 이후
펀치 카드를 개발

225
00:10:03,438 --> 00:10:08,040
우리는 데이터 저장소를 구축했습니다
그리고 놀라운 속도로 데이터를 수집.

226
00:10:08,040 --> 00:10:10,570
>> 그래서 지난 100 년 동안,
우리는이 추세를 보았다.

227
00:10:10,570 --> 00:10:11,940
즉, 변경 않을거야.

228
00:10:11,940 --> 00:10:14,789
앞으로 우리가 보게 될 것입니다
이 아니더라도 가속 추세.

229
00:10:14,789 --> 00:10:16,330
그리고 당신은 그 모습을 볼 수 있습니다.

230
00:10:16,330 --> 00:10:23,510
>> 2010 년 사업은 하나를 가지고 있다면
관리에서 데이터의 테라 바이트,

231
00:10:23,510 --> 00:10:27,080
그들이있어 의미 오늘
데이터의 6.5 페타 바이트를 관리.

232
00:10:27,080 --> 00:10:30,380
즉 6,500 배 더 많은 데이터를합니다.

233
00:10:30,380 --> 00:10:31,200
그리고 나는 이것을 알고있다.

234
00:10:31,200 --> 00:10:33,292
나는 매일이 기업과 함께 작동합니다.

235
00:10:33,292 --> 00:10:35,000
5 년 전,
회사 이야기 것

236
00:10:35,000 --> 00:10:38,260
어떤 고통에 대해 나에게 사람을 이야기 할
이 테라 바이트의 데이터를 관리하는 것입니다.

237
00:10:38,260 --> 00:10:39,700
그리고 그들은 말할 것이다
우리가 보는 방법에 대해 나에게

238
00:10:39,700 --> 00:10:41,825
이 것이 아마 것입니다
페타 바이트 또는이 될

239
00:10:41,825 --> 00:10:43,030
몇 년 이내.

240
00:10:43,030 --> 00:10:45,170
>> 이 같은 회사
내가 만나고있어 오늘,

241
00:10:45,170 --> 00:10:48,100
그들은 대해 나에게 얘기
문제는 관리가 데

242
00:10:48,100 --> 00:10:51,440
수십, 데이터의 20 페타 바이트.

243
00:10:51,440 --> 00:10:53,590
의 폭발 그래서
산업 데이터

244
00:10:53,590 --> 00:10:56,670
거대한를 운전
더 나은 솔루션이 필요합니다.

245
00:10:56,670 --> 00:11:00,980
그리고 관계형 데이터베이스입니다
단지 수요에 부응하지.

246
00:11:00,980 --> 00:11:03,490
>> 그래서 선형있다
데이터 압력 사이의 상관 관계

247
00:11:03,490 --> 00:11:05,210
기술 혁신.

248
00:11:05,210 --> 00:11:07,780
역사는 우리에게 보여 주었다
이, 그 시간에,

249
00:11:07,780 --> 00:11:11,090
마다 데이터의 양
즉, 처리해야

250
00:11:11,090 --> 00:11:15,490
시스템의 용량을 초과
적당한 시간에 그것을 처리하는

251
00:11:15,490 --> 00:11:18,870
또는 합리적인 비용,
다음 새로운 기술

252
00:11:18,870 --> 00:11:21,080
이러한 문제점을 해결하기 위하여 창안된다.

253
00:11:21,080 --> 00:11:24,090
이러한 새로운 기술,
차례로 문을 열어

254
00:11:24,090 --> 00:11:27,840
문제의 또 다른 세트에있는
더 많은 데이터를 수집한다.

255
00:11:27,840 --> 00:11:29,520
>> 이제, 우리는이 중지하지 않을거야.

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

257
00:11:30,020 --> 00:11:31,228
우리는이 중지하지 않을거야.

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

259
00:11:31,830 --> 00:11:35,520
당신은 모든 것을 알 수 있기 때문에
우주에서 알 수있다.

260
00:11:35,520 --> 00:11:40,510
그리고 한 우리는 살아 봤는데으로
인간의 역사를 통해,

261
00:11:40,510 --> 00:11:43,440
우리는 항상 더 많은 것을 알고 주도했다.

262
00:11:43,440 --> 00:11:49,840
>> 그래서 우리가 이동 구석 구석 것 같아
과학적 발견의 경로 아래로,

263
00:11:49,840 --> 00:11:54,620
우리는 데이터의 양을 승산되고
우리는 기하 급수적으로 처리 할 필요가 있음

264
00:11:54,620 --> 00:11:59,920
우리는 점점 더 많은을 밝히기로
생명의 내부 동작에 대한,

265
00:11:59,920 --> 00:12:04,530
우주의 작동 방식에 대한 약
과학적 발견을 운전,

266
00:12:04,530 --> 00:12:06,440
본 발명 그
우리는 오늘 일을하고 있습니다.

267
00:12:06,440 --> 00:12:09,570
데이터 볼륨 단지
지속적으로 증가한다.

268
00:12:09,570 --> 00:12:12,120
그래서 다룰 수 있다는
이 문제는 거대하다.

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

270
00:12:14,790 --> 00:12:17,410
>> 것들 중 하나 그래서
우리는 NoSQL에 왜으로 보면?

271
00:12:17,410 --> 00:12:19,200
어떻게 NoSQL에이 문제 해결에 도움이 되었습니까?

272
00:12:19,200 --> 00:12:24,980
음, 관계형 데이터베이스,
구조적 쿼리 언어,

273
00:12:24,980 --> 00:12:28,600
SQL-- 그건 정말의 구조이다
관계는 이런 일이 database--

274
00:12:28,600 --> 00:12:30,770
스토리지에 최적화.

275
00:12:30,770 --> 00:12:33,180
>> 위로 70 년대에, 다시,
디스크가 비싸다.

276
00:12:33,180 --> 00:12:36,990
스토리지 프로비저닝 운동
기업의 끝없는입니다.

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

278
00:12:37,490 --> 00:12:38,020
나는 그것을 살았다.

279
00:12:38,020 --> 00:12:41,250
나는에 대한 스토리지 드라이버를 썼다
enterprised 슈퍼 회사

280
00:12:41,250 --> 00:12:42,470
다시 90 년대.

281
00:12:42,470 --> 00:12:45,920
그리고 결론은 서로를 건 드리는됩니다
스토리지 배열은 그냥 뭔가였습니다

282
00:12:45,920 --> 00:12:47,600
기업에서 매일 일어났다.

283
00:12:47,600 --> 00:12:49,030
그리고 그것은 결코 멈추지 않았다.

284
00:12:49,030 --> 00:12:52,690
고밀도 저장 수요
고밀도 저장을 위해,

285
00:12:52,690 --> 00:12:56,340
보다 효율적인 저장을위한
이 중지 결코 devices--.

286
00:12:56,340 --> 00:13:00,160
>> 그리고 NoSQL에 좋은 기술입니다
이는 데이터를 정규화하기 때문이다.

287
00:13:00,160 --> 00:13:02,210
이는 데이터를 디 - 복제.

288
00:13:02,210 --> 00:13:07,180
그것은 구조에 그 데이터를 둔다
모든 액세스 패턴에 얽매이다.

289
00:13:07,180 --> 00:13:11,600
여러 응용 프로그램이 충돌 할 수 있습니다
SQL 데이터베이스, 임시 쿼리를 실행,

290
00:13:11,600 --> 00:13:15,950
과 모양 데이터를 얻을 그들이
자신의 워크로드 처리해야합니다.

291
00:13:15,950 --> 00:13:17,570
즉, 환상적인 소리.

292
00:13:17,570 --> 00:13:21,350
그러나 결론은 함께
시스템은 모든 것에 얽매의 경우,

293
00:13:21,350 --> 00:13:23,500
그것은 아무것도에 최적화되어 있습니다.

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

295
00:13:24,050 --> 00:13:26,386
>> 그리고 그것은 우리가 무엇을 얻을
관계형 데이터베이스.

296
00:13:26,386 --> 00:13:27,510
그것은 스토리지에 최적화 된.

297
00:13:27,510 --> 00:13:28,280
그것은 정규화입니다.

298
00:13:28,280 --> 00:13:29,370
그것은 관계입니다.

299
00:13:29,370 --> 00:13:31,660
그것은 임시 쿼리를 지원합니다.

300
00:13:31,660 --> 00:13:34,000
그리고 그것은 수직으로 확장 할 수 있습니다.

301
00:13:34,000 --> 00:13:39,030
>> 나는 더 큰 SQL 데이터베이스를 얻을 필요가있는 경우
또는보다 강력한 SQL 데이터베이스,

302
00:13:39,030 --> 00:13:41,090
나는 철의 더 큰 조각을 구입 이동합니다.

303
00:13:41,090 --> 00:13:41,600
그래?

304
00:13:41,600 --> 00:13:44,940
나는 많은 고객과 함께 일했다
주요 업그레이드를 통해되었는지

305
00:13:44,940 --> 00:13:48,340
자신의 SQL 인프라 만
6 개월 후 확인하려면,

306
00:13:48,340 --> 00:13:49,750
그들은 다시 벽을 치는 것입니다.

307
00:13:49,750 --> 00:13:55,457
그리고 Oracle 또는 MSSQL에서 대답
또는 다른 사람은 더 큰 상자를 얻을 수있다.

308
00:13:55,457 --> 00:13:58,540
그럼 조만간, 당신은 살 수 없습니다
상자 더 큰, 그리고 진짜 문제입니다.

309
00:13:58,540 --> 00:14:00,080
우리는 실제로 물건을 변경해야합니다.

310
00:14:00,080 --> 00:14:01,080
어디이 일을합니까?

311
00:14:01,080 --> 00:14:06,560
그것은 오프라인 잘 작동
분석, OLAP 형 워크로드.

312
00:14:06,560 --> 00:14:08,670
SQL이 속한 곳 그리고 정말입니다.

313
00:14:08,670 --> 00:14:12,540
지금, 그것은 많은 온라인 오늘날 사용되는
트랜잭션 처리 형

314
00:14:12,540 --> 00:14:13,330
응용 프로그램.

315
00:14:13,330 --> 00:14:16,460
그리고 그것은에서 잘 작동합니다
이용 일정 수준의,

316
00:14:16,460 --> 00:14:18,670
하지만 그것은 단지 확장되지 않습니다
NoSQL에가하는 방법.

317
00:14:18,670 --> 00:14:20,660
그리고 우리는 조금 얘기하자
그 이유에 대한 비트.

318
00:14:20,660 --> 00:14:23,590
>> 이제 NoSQL에, 다른 한편으로는,
더 많은 컴퓨팅에 최적화되어 있습니다.

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

320
00:14:24,540 --> 00:14:26,830
그것은에 무관하지 않다
액세스 패턴.

321
00:14:26,830 --> 00:14:31,620
우리가 탈 정규화라고 부릅니다
구조 또는 계층 적 구조.

322
00:14:31,620 --> 00:14:35,000
관계형 데이터베이스의 데이터는
여러 테이블에서 함께 결합

323
00:14:35,000 --> 00:14:36,850
당신이 필요로하는 뷰를 생성한다.

324
00:14:36,850 --> 00:14:40,090
NoSQL에 데이터베이스의 데이터
문서에 저장되는 것을

325
00:14:40,090 --> 00:14:42,100
계층 구조가 포함되어 있습니다.

326
00:14:42,100 --> 00:14:45,670
일반적으로 될 것이라고 모든 데이터
그 뷰를 생성하기 위해 서로 결합

327
00:14:45,670 --> 00:14:47,160
단일 문서 내에 저장된다.

328
00:14:47,160 --> 00:14:50,990
그리고 우리에 대해 조금 얘기하자
어떻게 차트의 몇 작품을.

329
00:14:50,990 --> 00:14:55,320
>> 그러나 여기에서 아이디어는 당신이 저장하는 것이있다
이러한 인스턴스 뷰와 같은 데이터.

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

331
00:14:56,410 --> 00:14:58,610
당신은 수평으로 확장 할 수 있습니다.

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

333
00:14:59,556 --> 00:15:02,100
나는이 증가해야하는 경우
내 NoSQL에 클러스터의 크기,

334
00:15:02,100 --> 00:15:03,700
나는 더 큰 상자를 얻을 필요가 없습니다.

335
00:15:03,700 --> 00:15:05,200
나는 또 다른 상자를 얻을.

336
00:15:05,200 --> 00:15:07,700
그리고, 함께 그 클러스터
나는 그 데이터를 샤딩 할 수 있습니다.

337
00:15:07,700 --> 00:15:10,780
우리에 대해 조금 얘기하자
샤딩이 무엇인지, 할 수

338
00:15:10,780 --> 00:15:14,270
해당 데이터베이스를 확장 할 수
여러 물리적 장치에 걸쳐

339
00:15:14,270 --> 00:15:18,370
과 장벽을 제거하는
수직으로 확장 할 날이 필요합니다.

340
00:15:18,370 --> 00:15:22,080
>> 그래서 정말 온라인을 위해 만들어진 것
트랜잭션 처리 및 규모.

341
00:15:22,080 --> 00:15:25,480
큰 차이가있다
여기에보고 사이에, 오른쪽?

342
00:15:25,480 --> 00:15:27,810
보고, 나는 몰라
질문은 물어거야.

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

344
00:15:28,310 --> 00:15:30,570
Reporting-- 사람의 경우
내 마케팅 부서

345
00:15:30,570 --> 00:15:34,520
내 고객의 얼마나 많은 그냥 ...하고자
이 특정 특성이있는 사람

346
00:15:34,520 --> 00:15:37,850
나도 몰라이 day--에 구입
어떻게 그들이 물어거야 쿼리합니다.

347
00:15:37,850 --> 00:15:39,160
그래서 나는 불가지론 할 필요가있다.

348
00:15:39,160 --> 00:15:41,810
>> 이제 온라인에서
트랜잭션 응용 프로그램,

349
00:15:41,810 --> 00:15:43,820
내가 부탁 해요 어떤 질문을 알고있다.

350
00:15:43,820 --> 00:15:46,581
나는에 대한 응용 프로그램을 구축
매우 구체적인 워크 플로우.

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

352
00:15:47,080 --> 00:15:50,540
I는 데이터를 최적화한다면
그 워크 플로우를 지원하기 위해 저장,

353
00:15:50,540 --> 00:15:52,020
더 빨리 될 것.

354
00:15:52,020 --> 00:15:55,190
그리고 그 이유는 NoSQL에 할 수 있어요
실제로 전달을 가속화

355
00:15:55,190 --> 00:15:57,710
서비스의 이러한 종류의.

356
00:15:57,710 --> 00:15:58,210
괜찮아.

357
00:15:58,210 --> 00:16:00,501
>> 그래서 우리는에받을거야
여기에 이​​론의 약간.

358
00:16:00,501 --> 00:16:03,330
그리고 당신의 일부, 눈
조금 롤백 할 수 있습니다.

359
00:16:03,330 --> 00:16:06,936
그러나 나는 그것을 유지하려고합니다
내가 할 수있는만큼 높은 수준.

360
00:16:06,936 --> 00:16:08,880
당신이 프로젝트에있어 경우에 따라서
관리는있다

361
00:16:08,880 --> 00:16:12,280
구조는 전화
제약 조건의 삼각형.

362
00:16:12,280 --> 00:16:12,936
그래.

363
00:16:12,936 --> 00:16:16,060
구속의 지시의 삼각형
당신은 모든 것을 모든 시간을 가질 수 없습니다.

364
00:16:16,060 --> 00:16:17,750
당신의 파이가 너무 먹을 수 없습니다.

365
00:16:17,750 --> 00:16:22,310
그래서 프로젝트 관리, 그 삼각형
제약, 당신이 싼 가질 수있다

366
00:16:22,310 --> 00:16:24,710
당신은 그것을 빨리 할 수​​ 있습니다
또는 당신은 잘 할 수 있습니다.

367
00:16:24,710 --> 00:16:25,716
두 가지를 선택합니다.

368
00:16:25,716 --> 00:16:27,090
당신은 세 가지를 모두 가질 수 없습니다 때문입니다.

369
00:16:27,090 --> 00:16:27,460
권리?

370
00:16:27,460 --> 00:16:27,820
그래.

371
00:16:27,820 --> 00:16:28,920
>> 그래서이 많이 듣고.

372
00:16:28,920 --> 00:16:31,253
그것은, 트리플 제약의
트리플 제약의 삼각형,

373
00:16:31,253 --> 00:16:34,420
또는 철의 삼각형 oftentimes--입니다
당신은 프로젝트 관리자에 이야기 할 때,

374
00:16:34,420 --> 00:16:35,420
그들은 이것에 대해 얘기하자.

375
00:16:35,420 --> 00:16:37,640
이제 데이터베이스가
자신의 철의 삼각형.

376
00:16:37,640 --> 00:16:40,350
및 데이터의 철 삼각형
우리는 CAP 정리라고 부릅니다.

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

378
00:16:41,580 --> 00:16:43,770
>> CAP 정리의 지시
어떻게 데이터베이스 운영

379
00:16:43,770 --> 00:16:45,627
매우 구체적인 조건.

380
00:16:45,627 --> 00:16:47,460
그리고 우리는 얘기하자
그 조건은 무엇인지.

381
00:16:47,460 --> 00:16:52,221
그러나 삼각형의 세 점,
그래서, C는, 일관성 말을합니다.

382
00:16:52,221 --> 00:16:52,720
그래?

383
00:16:52,720 --> 00:16:56,760
그래서 모자, 일관성은 모든 것을 의미합니다
데이터베이스에 액세스 할 수있는 클라이언트

384
00:16:56,760 --> 00:16:59,084
항상 매우있을 것이다
데이터의 일관성을 볼 수 있습니다.

385
00:16:59,084 --> 00:17:00,750
아무도거야 다른 두 가지를 참조하십시오.

386
00:17:00,750 --> 00:17:01,480
그래?

387
00:17:01,480 --> 00:17:04,020
나는 데이터베이스를 참조하는 경우,
나도 같은보기를보고 있어요

388
00:17:04,020 --> 00:17:06,130
내 파트너로 누가보고
동일한 데이터베이스.

389
00:17:06,130 --> 00:17:07,470
즉 일관성이다.

390
00:17:07,470 --> 00:17:12,099
>> 가용성을 의미하는 경우
데이터베이스, 온라인이 도달 할 수있는 경우,

391
00:17:12,099 --> 00:17:14,760
모든 클라이언트가 항상 것
읽고 쓸 수 있습니다.

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

393
00:17:15,260 --> 00:17:17,010
그래서 모든 클라이언트가
데이터베이스를 읽을 수 있습니다

394
00:17:17,010 --> 00:17:18,955
항상있게 읽을 수 있습니다
데이터 쓰기 데이터.

395
00:17:18,955 --> 00:17:21,819
그리고 그런 경우,
그것은 사용할 수있는 시스템이다.

396
00:17:21,819 --> 00:17:24,230
>> 그리고 세 번째 점은 무엇입니까
우리는 파티션 허용 오차를 호출합니다.

397
00:17:24,230 --> 00:17:24,730
그래?

398
00:17:24,730 --> 00:17:28,160
파티션 허용 수단
시스템이 잘 작동하는

399
00:17:28,160 --> 00:17:32,000
실제 네트워크에도 불구하고
노드들 사이의 파티션.

400
00:17:32,000 --> 00:17:32,760
그래?

401
00:17:32,760 --> 00:17:36,270
따라서 클러스터의 노드 수 없습니다
서로 대화, 어떻게됩니까?

402
00:17:36,270 --> 00:17:36,880
괜찮아.

403
00:17:36,880 --> 00:17:39,545
>> 그래서 관계형 데이터베이스는 choose--
당신은이 두 가지를 선택할 수 있습니다.

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

405
00:17:40,045 --> 00:17:43,680
그래서 관계형 데이터베이스 선택
일관되고 사용할 수 있습니다.

406
00:17:43,680 --> 00:17:47,510
파티션 사이에 발생하는 경우
데이터 저장소의 데이타 노드,

407
00:17:47,510 --> 00:17:48,831
데이터베이스가 충돌합니다.

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

409
00:17:49,330 --> 00:17:50,900
그냥 내려갑니다.

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

411
00:17:51,450 --> 00:17:54,230
>> 그리고 이것은 그들이 가지고있는 이유
큰 상자와 함께 성장합니다.

412
00:17:54,230 --> 00:17:54,730
권리?

413
00:17:54,730 --> 00:17:58,021
말아요 - 일반적으로, 클러스터가 존재하기 때문에
데이터베이스는, 그들 중 매우 많은이 아니다

414
00:17:58,021 --> 00:17:59,590
그것은 그런 식으로 작동합니다.

415
00:17:59,590 --> 00:18:03,019
그러나 대부분의 데이터베이스 확장
수직으로 하나의 상자 내.

416
00:18:03,019 --> 00:18:05,060
그들은 할 필요가 있기 때문에
일관성 있고 사용할 수 있습니다.

417
00:18:05,060 --> 00:18:10,320
파티션을 주입했다,
당신은 선택을해야 할 것입니다.

418
00:18:10,320 --> 00:18:13,720
당신은 사이에서 선택을해야
일관성 있고 사용할 수있는.

419
00:18:13,720 --> 00:18:16,080
>> 그리고 그 NoSQL에 데이터베이스가하는 일입니다.

420
00:18:16,080 --> 00:18:16,580
괜찮아.

421
00:18:16,580 --> 00:18:20,950
그래서 NoSQL에 데이터베이스를
두 가지 유형이있다.

422
00:18:20,950 --> 00:18:22,990
우리는 잘 잔 마셔요
여러 가지 유형이있다,

423
00:18:22,990 --> 00:18:26,140
하지만 두 가지 기본 제공됩니다
무엇을 특징 만

424
00:18:26,140 --> 00:18:30,050
우리는 CP 데이터베이스 또는를 호출
일관성 및 파티션 허용

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

426
00:18:31,040 --> 00:18:34,930
이 사람들은 선택을 할 때
노드들은 서로 접촉을 상실

427
00:18:34,930 --> 00:18:37,091
우리는 허용하지 않을거야
사람들은 더 이상 쓸 수 있습니다.

428
00:18:37,091 --> 00:18:37,590
그래?

429
00:18:37,590 --> 00:18:41,855
>> 해당 파티션이 제거 될 때까지,
쓰기 액세스가 차단됩니다.

430
00:18:41,855 --> 00:18:43,230
즉이 사용 가능하지 않은 것을 의미한다.

431
00:18:43,230 --> 00:18:44,510
그들은 일관성입니다.

432
00:18:44,510 --> 00:18:46,554
우리가 볼 때
파티션 자체를 주입,

433
00:18:46,554 --> 00:18:48,470
우리는 지금 일치
우리는하지 않을거야 때문에

434
00:18:48,470 --> 00:18:51,517
두 데이터에 대한 변경을 허용하도록
독립적으로 파티션의 측면

435
00:18:51,517 --> 00:18:52,100
서로.

436
00:18:52,100 --> 00:18:54,130
우리는해야합니다
통신을 다시

437
00:18:54,130 --> 00:18:56,930
어떤 갱신 전에
데이터가 허용됩니다.

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

439
00:18:58,120 --> 00:19:02,650
>> 다음 맛, AP 시스템이 될 것입니다
또는 사용할 수 있으며 분할

440
00:19:02,650 --> 00:19:03,640
허용 오차 시스템.

441
00:19:03,640 --> 00:19:05,320
이 사람은 걱정하지 않는다.

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

443
00:19:06,020 --> 00:19:08,960
를 얻을 모든 노드
우리가 할게요, 쓰기.

444
00:19:08,960 --> 00:19:11,480
그래서 난 내 데이터를 복제하고있어
여러 노드에서.

445
00:19:11,480 --> 00:19:14,730
이러한 노드는 클라이언트, 클라이언트 제공받을
, 말씀에, 나는 몇 가지 데이터를 쓸거야.

446
00:19:14,730 --> 00:19:16,300
노드는 아무 문제 말한다.

447
00:19:16,300 --> 00:19:18,580
노드 그를 가져 옆에
동일한 레코드에 대한 쓰기,

448
00:19:18,580 --> 00:19:20,405
그는 문제를 말할거야.

449
00:19:20,405 --> 00:19:23,030
어딘가에 다시 백 엔드에,
그 데이터를 복제하는 것입니다.

450
00:19:23,030 --> 00:19:27,360
그리고 누군가가 실현거야
어 - 오, 깨달을 것이다 그들은 시스템, 어 - 오,

451
00:19:27,360 --> 00:19:28,870
양측에 업데이트가되었습니다.

452
00:19:28,870 --> 00:19:30,370
우리는 무엇을해야합니까?

453
00:19:30,370 --> 00:19:33,210
그리고 그들이 다음 할 것은
그들은 무언가를하는

454
00:19:33,210 --> 00:19:36,080
그들이 그 데이터 상태를 해결 할 수 있습니다.

455
00:19:36,080 --> 00:19:39,000
그리고 우리는 얘기하자
다음 차트에서 해당.

456
00:19:39,000 --> 00:19:40,000
>> 일이 여기에 지적한다.

457
00:19:40,000 --> 00:19:42,374
그리고 너무 얻을 않을거야
많은이에,이 때문에

458
00:19:42,374 --> 00:19:43,510
깊은 데이터 이론으로 가져옵니다.

459
00:19:43,510 --> 00:19:46,670
그러나 트랜잭션있다
프레임 워크가

460
00:19:46,670 --> 00:19:50,680
관계형 시스템에서 실행
나를 안전하게 업데이트 할 수 있습니다

461
00:19:50,680 --> 00:19:53,760
데이터베이스 내의 여러 엔티티.

462
00:19:53,760 --> 00:19:58,320
그리고 이러한 업데이트가 발생합니다
한 번에 또는 전혀.

463
00:19:58,320 --> 00:20:00,500
그리고이는 ACID 트랜잭션이라고합니다.

464
00:20:00,500 --> 00:20:01,000
그래?

465
00:20:01,000 --> 00:20:06,570
>> 산은 우리에게 일관성을 원 자성을 제공,
격리 및 내구성.

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

467
00:20:07,070 --> 00:20:13,550
즉 모든 원자, 트랜잭션을 의미
내 업데이트 발생하거나 또는하지 않습니다.

468
00:20:13,550 --> 00:20:16,570
일관성이 있음을 의미합니다
데이터베이스 항상 것

469
00:20:16,570 --> 00:20:19,780
일관하게 될
업데이트 후 상태.

470
00:20:19,780 --> 00:20:23,900
나는에서 데이터베이스를 떠나지 않을 것이다
업데이트를 적용한 후 나쁜 상태.

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

472
00:20:24,400 --> 00:20:26,720
>> 그래서 조금 다르다
CAP의 일관성보다.

473
00:20:26,720 --> 00:20:29,760
CAP의 일관성을 의미 내 모든
클라이언트는 항상 데이터를 볼 수있다.

474
00:20:29,760 --> 00:20:34,450
ACID 일관성을 의미 때
트랜잭션 데이터의 좋은 이루어집니다.

475
00:20:34,450 --> 00:20:35,709
나의 관계는 모두 좋다.

476
00:20:35,709 --> 00:20:38,750
나는 부모 행을 삭제하지 않을거야
고아 아이들의 무리를 떠나

477
00:20:38,750 --> 00:20:40,970
다른 테이블.

478
00:20:40,970 --> 00:20:44,320
내가 일치 해요 경우가 발생할 수 없습니다
산 거래.

479
00:20:44,320 --> 00:20:49,120
>> 격리 거래 있음을 의미한다
항상 하나씩 발생한다.

480
00:20:49,120 --> 00:20:51,920
데이터의 최종 결과
같은 상태가 될 것입니다

481
00:20:51,920 --> 00:20:54,770
이러한 트랜잭션 마치
그 동시에 발행 된

482
00:20:54,770 --> 00:20:57,340
순차적으로 실행되었다.

483
00:20:57,340 --> 00:21:00,030
그래서 동시성이다
데이터베이스에 제어 할 수 있습니다.

484
00:21:00,030 --> 00:21:04,130
그러니까 기본적으로, 나는를 증가 할 수
두 번 두 가지 작업과 같은 값.

485
00:21:04,130 --> 00:21:08,580
>> 하지만이 값에 1을 추가 말한다면,
두 개의 트랜잭션이 와서

486
00:21:08,580 --> 00:21:10,665
하나는, 그것은을하려고
먼저 거기에 도착 예정

487
00:21:10,665 --> 00:21:12,540
다른 하나의
후 거기에 도착하는 것.

488
00:21:12,540 --> 00:21:15,210
그래서 결국, 나는 두 가지를 추가했다.

489
00:21:15,210 --> 00:21:16,170
당신은 내가 무슨 뜻인지 볼?

490
00:21:16,170 --> 00:21:16,670
그래.

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

492
00:21:19,220 --> 00:21:21,250
>> 내구성은 매우 간단합니다.

493
00:21:21,250 --> 00:21:23,460
때 트랜잭션
인정, 그건

494
00:21:23,460 --> 00:21:26,100
심지어이 될 것
시스템이 충돌하는 경우.

495
00:21:26,100 --> 00:21:29,230
해당 시스템이 복구되면, 그
커밋 트랜잭션

496
00:21:29,230 --> 00:21:30,480
실제로이 될 것입니다.

497
00:21:30,480 --> 00:21:33,130
그래서 보장의
ACID 트랜잭션의.

498
00:21:33,130 --> 00:21:35,470
사람들은 꽤 좋은 보장입니다
데이터베이스에 미칠합니다,

499
00:21:35,470 --> 00:21:36,870
그러나 그들은 그 비용으로 제공됩니다.

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

501
00:21:37,640 --> 00:21:40,520
>> 문제 때문에
이 프레임 워크가와

502
00:21:40,520 --> 00:21:44,540
데이터 파티션이있는 경우
세트, 나는 결정을해야합니다.

503
00:21:44,540 --> 00:21:48,000
나는 수 있도록해야 할거야
한 쪽 또는 다른에 업데이트됩니다.

504
00:21:48,000 --> 00:21:50,310
그리고 그 일이 생기면,
나는 더 이상 진행 해요

505
00:21:50,310 --> 00:21:52,630
유지할 수 있어야합니다
그 특성.

506
00:21:52,630 --> 00:21:53,960
그들은 일치하지 않습니다.

507
00:21:53,960 --> 00:21:55,841
그들은 고립되지 않습니다.

508
00:21:55,841 --> 00:21:58,090
이 고장 곳이다
관계형 데이터베이스.

509
00:21:58,090 --> 00:22:01,360
이 이유이다 관계형
데이터베이스는 수직으로 확장 할 수 있습니다.

510
00:22:01,360 --> 00:22:05,530
>> 반면에, 우리가
무슨 일이 기반 기술을 불렀다.

511
00:22:05,530 --> 00:22:07,291
그리고이는 NoSQL에 데이터베이스입니다.

512
00:22:07,291 --> 00:22:07,790
괜찮아.

513
00:22:07,790 --> 00:22:10,180
그래서 우리는 우리의 CP, AP 데이터베이스를 가지고있다.

514
00:22:10,180 --> 00:22:14,720
그리고 이들은 당신이 기본적으로 부르는 있습니다
가능한, 부드러운 상태, 결국

515
00:22:14,720 --> 00:22:15,740
일관된.

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

517
00:22:16,420 --> 00:22:19,690
>> 기본적으로 사용할 수 있기 때문에
그들은 파티션 허용입니다.

518
00:22:19,690 --> 00:22:21,470
그들은 항상있을 것입니다
이,이 경우에도

519
00:22:21,470 --> 00:22:23,053
노드 간의 네트워크 파티션.

520
00:22:23,053 --> 00:22:25,900
내가 노드로 이야기 할 수 있다면, 나는 해요
데이터를 읽을 수있을 것.

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

522
00:22:26,460 --> 00:22:30,810
난 항상 기록하지 못할 수 있습니다
데이터 나는 일관성있는 플랫폼이야합니다.

523
00:22:30,810 --> 00:22:32,130
하지만 데이터를 읽을 수 있습니다.

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

525
00:22:34,960 --> 00:22:38,010
>> 부드러운 상태를 나타냅니다
내가 그 데이터를 읽을 때,

526
00:22:38,010 --> 00:22:40,790
그것은 다른 노드와 동일하지 않을 수 있습니다.

527
00:22:40,790 --> 00:22:43,390
권리는 노드에서 발급 된 경우
클러스터의 다른 곳

528
00:22:43,390 --> 00:22:46,650
그것은을 통해 복제되지 않은
클러스터는 아직 난, 그 데이터를 읽을 때

529
00:22:46,650 --> 00:22:48,680
그 상태가 일치하지 않을 수 있습니다.

530
00:22:48,680 --> 00:22:51,650
그러나 것
결국 일관성,

531
00:22:51,650 --> 00:22:53,870
의미 할 때 작성하는 것이
시스템에 구성되어,

532
00:22:53,870 --> 00:22:56,480
이 노드에 복제합니다.

533
00:22:56,480 --> 00:22:59,095
그리고 결국, 그 상태
주문하게 될 것입니다,

534
00:22:59,095 --> 00:23:00,890
그리고 일관성있는 상태 일 것이다.

535
00:23:00,890 --> 00:23:05,000
>> 이제, CAP 정리 정말
하나의 조건 만 재생됩니다.

536
00:23:05,000 --> 00:23:08,700
이러한 상황이 발생하면 해당 조건이다.

537
00:23:08,700 --> 00:23:13,710
때마다 자신의 운영 때문에
일반 모드, 어떤 파티션이 없다,

538
00:23:13,710 --> 00:23:16,370
모두의 일관성 및 사용할 수 있습니다.

539
00:23:16,370 --> 00:23:19,990
당신은 CAP 걱정
우리는 그 파티션이있는 경우.

540
00:23:19,990 --> 00:23:21,260
그래서 사람들은 드물다.

541
00:23:21,260 --> 00:23:25,360
그러나 시스템이 때 사람들을 어떻게 반응
시스템의 유형을 지시 발생

542
00:23:25,360 --> 00:23:26,750
우리가 상대하고.

543
00:23:26,750 --> 00:23:31,110
>> 그럼 살펴 보자 무엇
즉, AP 시스템처럼 보인다.

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

545
00:23:32,621 --> 00:23:34,830
AP 시스템은 두 가지 종류로 왔습니다.

546
00:23:34,830 --> 00:23:38,514
그들은 인 맛에 와서
마스터 마스터, 항상 사용할 수 100 %.

547
00:23:38,514 --> 00:23:40,430
그리고 그들은 올
라고 다른 맛,

548
00:23:40,430 --> 00:23:43,330
당신은, 내가 걱정하는거야 알고
이 파티션 일에 대한

549
00:23:43,330 --> 00:23:44,724
때 실제 파티션이 발생합니다.

550
00:23:44,724 --> 00:23:47,890
그렇지 않으면, 차있을거야
권리를 걸릴 거예요 노드.

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

552
00:23:48,500 --> 00:23:50,040
>> 카산드라 같은 우리가 어떤 경우에 따라서.

553
00:23:50,040 --> 00:23:54,440
카산드라는 마스터 것
마스터, 내가 모든 노드에 기록하자.

554
00:23:54,440 --> 00:23:55,540
그래서 무슨 일이?

555
00:23:55,540 --> 00:23:58,270
그래서에서 개체가
두 개의 노드에 존재하는 데이터베이스.

556
00:23:58,270 --> 00:24:01,705
의 해당 개체 (S)를 부르 자
그래서 우리는 (S)에 대한 상태를

557
00:24:01,705 --> 00:24:04,312
우리는 일부 작업을
S에 진행됩니다.

558
00:24:04,312 --> 00:24:06,270
카산드라에 날 수 있습니다
여러 노드에 쓰기.

559
00:24:06,270 --> 00:24:08,550
그래서 내가 얻을 가정 해 봅시다
두 개의 노드로 초 동안 물품.

560
00:24:08,550 --> 00:24:12,274
글쎄, 무슨 일이 일어나고있는 것입니다 끝
우리는 분할 이벤트 있음을 호출합니다.

561
00:24:12,274 --> 00:24:14,190
가되지 않을 수 있습니다
물리적 네트워크 파티션.

562
00:24:14,190 --> 00:24:15,950
그러나 때문에 디자인의
시스템, 그것은이다

563
00:24:15,950 --> 00:24:18,449
실제로 즉시 분할
나는 두 개의 노드에 쓰기를 얻을 수있다.

564
00:24:18,449 --> 00:24:20,830
그것은 저를 강요 아니에요
하나의 노드를 통해 모든 물품.

565
00:24:20,830 --> 00:24:22,340
나는 두 개의 노드에 쓰고 있어요.

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

567
00:24:23,330 --> 00:24:25,740
>> 그래서 지금은 두 가지 상태가있다.

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

569
00:24:26,360 --> 00:24:28,110
무슨 일이 일어날
조만간입니다

570
00:24:28,110 --> 00:24:29,960
복제 이벤트가있을 것입니다.

571
00:24:29,960 --> 00:24:33,300
있을 무슨 일이 일어나고 있는지 우리
파티션 복구,라고하는

572
00:24:33,300 --> 00:24:35,200
여기서이 두 가지입니다
상태는 함께 돌아와

573
00:24:35,200 --> 00:24:37,310
및 알고리즘이있을거야
즉, 데이터베이스 내에서 실행

574
00:24:37,310 --> 00:24:38,540
무엇을 결정한다.

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

576
00:24:39,110 --> 00:24:43,057
기본적으로, 마지막 업데이트
대부분의 AP 시스템에서 이긴다.

577
00:24:43,057 --> 00:24:44,890
그래서 일반적으로있다
기본 알고리즘 어떤

578
00:24:44,890 --> 00:24:47,400
그들은 콜백을 호출
기능, 뭔가 그

579
00:24:47,400 --> 00:24:51,000
때이 조건이 호출됩니다
일부 로직을 실행하기 위해 검출되고

580
00:24:51,000 --> 00:24:52,900
그 충돌을 해결합니다.

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

582
00:24:53,850 --> 00:24:58,770
기본 콜백 및 기본
대부분의 AP 데이터베이스에 해결

583
00:24:58,770 --> 00:25:01,130
이며, 타임 스탬프 승리 어떻게 됐을까.

584
00:25:01,130 --> 00:25:02,380
이 마지막 업데이트했다.

585
00:25:02,380 --> 00:25:04,320
나는 거기에 해당 업데이트를 넣어거야.

586
00:25:04,320 --> 00:25:08,440
나는이 레코드를 덤프 수 나는
복구 로그에 떨어져 버려

587
00:25:08,440 --> 00:25:11,670
사용자가 나중에 다시 올 수 있도록
말하기, 헤이, 충돌이 있었다.

588
00:25:11,670 --> 00:25:12,320
어떻게 된 거예요?

589
00:25:12,320 --> 00:25:16,370
그리고 당신은 실제로 기록을 덤프 할 수
모든 충돌과 롤백

590
00:25:16,370 --> 00:25:17,550
그리고 무슨 일이 일어 나는지.

591
00:25:17,550 --> 00:25:21,580
>> 이제, 사용자로, 당신은 또한 수
그 콜백에 로직을 포함한다.

592
00:25:21,580 --> 00:25:24,290
그래서 당신은을 변경할 수 있습니다
콜백 작업.

593
00:25:24,290 --> 00:25:26,730
당신은 이봐, 내가 원하는 말할 수
이 데이터를 교정합니다.

594
00:25:26,730 --> 00:25:28,880
내가 시도하려는 및
두 레코드를 병합.

595
00:25:28,880 --> 00:25:30,050
그러나 그것은 당신에게 달려 있습니다.

596
00:25:30,050 --> 00:25:32,880
데이터베이스는 모르는 방법
기본적으로 그렇게. 대부분의 시간,

597
00:25:32,880 --> 00:25:34,850
유일한 데이터베이스
어떻게 말을 할 일은 알고

598
00:25:34,850 --> 00:25:36,100
이 사람은 마지막 기록했다.

599
00:25:36,100 --> 00:25:39,183
즉, 이길 것 하나
그리고 내가 넣어거야 값입니다.

600
00:25:39,183 --> 00:25:41,490
파티션 복구되면
복제가 발생

601
00:25:41,490 --> 00:25:43,930
우리는 우리의 상태를 가지고있는
지금 인 프라임 S

602
00:25:43,930 --> 00:25:46,890
모든 개체의 병합 상태.

603
00:25:46,890 --> 00:25:49,700
그래서 AP 시스템이 있습니다.

604
00:25:49,700 --> 00:25:51,615
CP 시스템은 필요하지 않습니다
이것에 대해 걱정합니다.

605
00:25:51,615 --> 00:25:54,490
즉시 파티션이 온다 때문에
놀이로, 그들은 단지 복용을 중단

606
00:25:54,490 --> 00:25:55,530
기록합니다.

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

608
00:25:56,180 --> 00:25:58,670
그래서 아주 쉽게
일관성있는 처리

609
00:25:58,670 --> 00:26:01,330
때 업데이트를 허용하지 않습니다.

610
00:26:01,330 --> 00:26:04,620
CP 시스템은 수행과 함께 때문이다.

611
00:26:04,620 --> 00:26:05,120
괜찮아.

612
00:26:05,120 --> 00:26:07,590
>> 그래서 조금 이야기하자
액세스 패턴에 대한 비트.

613
00:26:07,590 --> 00:26:11,580
우리는 NoSQL에 대해 이야기 할 때이다
모든 액세스 패턴에 대한.

614
00:26:11,580 --> 00:26:13,550
이제, SQL은 임시 쿼리입니다.

615
00:26:13,550 --> 00:26:14,481
그것은 관계를 저장합니다.

616
00:26:14,481 --> 00:26:16,480
우리는 걱정할 필요가 없습니다
액세스 패턴에 대한.

617
00:26:16,480 --> 00:26:17,688
나는 매우 복잡한 쿼리를 작성.

618
00:26:17,688 --> 00:26:19,250
이는 이동하고 데이터를 얻는다.

619
00:26:19,250 --> 00:26:21,210
즉,이 보이는거야
같은 정규화.

620
00:26:21,210 --> 00:26:24,890
>> 이 특정 구조에 따라서
우리는 제품 카탈로그에서 찾고 있습니다.

621
00:26:24,890 --> 00:26:26,640
I는 서로 다른 종류의 제품이있다.

622
00:26:26,640 --> 00:26:27,217
나는 책이있다.

623
00:26:27,217 --> 00:26:27,800
나는 앨범을 가지고있다.

624
00:26:27,800 --> 00:26:30,090
나는 동영상이.

625
00:26:30,090 --> 00:26:33,370
제품 간의 관계
그리고이 책, 앨범 중 하나,

626
00:26:33,370 --> 00:26:34,860
및 비디오 테이블은 1 : 1입니다.

627
00:26:34,860 --> 00:26:35,800
괜찮아?

628
00:26:35,800 --> 00:26:38,860
나는 제품 ID를 가지고있어,
그 ID의 대응

629
00:26:38,860 --> 00:26:41,080
책, 앨범, 또는 비디오.

630
00:26:41,080 --> 00:26:41,580
그래?

631
00:26:41,580 --> 00:26:44,350
1 관계 : 즉 1의
그 테이블에서.

632
00:26:44,350 --> 00:26:46,970
>> 이제, 모든 사람들을 books--
이 루트의 숙박 시설이다.

633
00:26:46,970 --> 00:26:47,550
문제 없어.

634
00:26:47,550 --> 00:26:48,230
잘 됐네요.

635
00:26:48,230 --> 00:26:52,130
일대일 관계, I는 모두 얻을
데이터가 그 책을 설명 할 필요가있다.

636
00:26:52,130 --> 00:26:54,770
Albums-- 앨범 트랙이있다.

637
00:26:54,770 --> 00:26:56,470
이것은 우리가 많은 하나를 호출 할 것입니다.

638
00:26:56,470 --> 00:26:58,905
모든 앨범은 많은 트랙을 가질 수있다.

639
00:26:58,905 --> 00:27:00,780
의 모든 트랙에 대한 그래서
앨범은, 내가 할 수

640
00:27:00,780 --> 00:27:02,570
이 자식 테이블에서 다른 레코드.

641
00:27:02,570 --> 00:27:04,680
그래서 하나의 레코드를 생성
내 앨범 테이블.

642
00:27:04,680 --> 00:27:06,700
여러 개의 레코드를 만들
트랙 테이블.

643
00:27:06,700 --> 00:27:08,850
일대 다 관계.

644
00:27:08,850 --> 00:27:11,220
>> 이 관계는 무엇입니까
우리는 다 대다를 호출합니다.

645
00:27:11,220 --> 00:27:11,750
그래?

646
00:27:11,750 --> 00:27:17,000
당신은 배우가 될 수 있다고 볼 수
많은 영화, 많은 비디오에서.

647
00:27:17,000 --> 00:27:21,450
그래서 우리가 우리가이 매핑을 넣어
그 사이에 테이블, 어떤 이는 단지

648
00:27:21,450 --> 00:27:24,040
비디오 ID로 배우 ID를 매핑합니다.

649
00:27:24,040 --> 00:27:28,464
지금은 조인 쿼리를 만들 수 있습니다
배우로 배우 비디오를 통해 동영상,

650
00:27:28,464 --> 00:27:31,130
그것은 나에게의 좋은 목록을 제공
모든 영화와 모든 배우

651
00:27:31,130 --> 00:27:32,420
누가 그 영화에 있었다.

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

653
00:27:33,290 --> 00:27:33,880
그래서 여기에 우리가 간다.

654
00:27:33,880 --> 00:27:38,040
일대일 최상위이며
관계; 일대

655
00:27:38,040 --> 00:27:40,240
트랙 앨범; 대다.

656
00:27:40,240 --> 00:27:44,990
사람들은 세 가지 최상위 있습니다
데이터베이스의 관계.

657
00:27:44,990 --> 00:27:48,050
당신은 어떻게 사람들을 알고있는 경우
관계는 협력​​,

658
00:27:48,050 --> 00:27:51,490
당신은 많이 알고
이미 데이터베이스에 대한.

659
00:27:51,490 --> 00:27:55,660
그래서 NoSQL에는 약간 다르게 작동합니다.

660
00:27:55,660 --> 00:27:58,930
의는 잠시 생각하자 무엇을
외모는 내 모든 제품을 얻을 가고 싶어.

661
00:27:58,930 --> 00:28:01,096
>> 관계형 상점에서, 나는
내 모든 제품을 얻으려면

662
00:28:01,096 --> 00:28:02,970
내 모든 제품의 목록.

663
00:28:02,970 --> 00:28:04,910
즉, 쿼리가 많이 있습니다.

664
00:28:04,910 --> 00:28:07,030
내 모든 책에 대한 쿼리를 얻었다.

665
00:28:07,030 --> 00:28:08,470
내 앨범에서 쿼리를 얻었다.

666
00:28:08,470 --> 00:28:09,970
그리고 나는 내 모든 동영상에 대한 쿼리를 얻었다.

667
00:28:09,970 --> 00:28:11,719
그리고 나는 그것을 넣어 가지고
모두 함께 목록에서

668
00:28:11,719 --> 00:28:15,250
그리고까지 다시 봉사
그것을 요​​구하고있는 응용 프로그램입니다.

669
00:28:15,250 --> 00:28:18,000
>> 내 책을 얻으려면, 내가 가입
제품 및 책.

670
00:28:18,000 --> 00:28:21,680
내 앨범을 얻으려면, 내가 가입있어
제품, 앨범, 트랙.

671
00:28:21,680 --> 00:28:25,330
그리고 내가 가지고, 내 동영상을 얻을 수
동영상에 제품을 결합하고,

672
00:28:25,330 --> 00:28:28,890
배우 동영상을 통해 가입,
그리고 배우에 가져.

673
00:28:28,890 --> 00:28:31,020
그래서 세 가지 질의를합니다.

674
00:28:31,020 --> 00:28:34,560
매우 복잡한 쿼리
하나의 결과 세트를 조립한다.

675
00:28:34,560 --> 00:28:36,540
>> 즉 최적 미만이다.

676
00:28:36,540 --> 00:28:39,200
이것은 우리가 얘기를 왜 때입니다
데이터의 구조에 대한

677
00:28:39,200 --> 00:28:42,900
액세스 불가지론로 내장
pattern-- 잘 그게 좋아요.

678
00:28:42,900 --> 00:28:45,730
그리고 당신이 정말 볼 수 있습니다
우리가 데이터를 조직 한 방법 좋은.

679
00:28:45,730 --> 00:28:46,550
그리고 당신은 무엇을 알아?

680
00:28:46,550 --> 00:28:49,750
난 단지 배우에 대해 하나의 기록을 가지고있다.

681
00:28:49,750 --> 00:28:50,440
>> 그건 괜찮아요.

682
00:28:50,440 --> 00:28:53,750
내 모든 배우 중복 제거했습니다,
그리고 나는 나의 연결을 유지

683
00:28:53,750 --> 00:28:55,200
이 매핑 테이블.

684
00:28:55,200 --> 00:29:00,620
그러나, 데이터를 받고
밖으로 비싼된다.

685
00:29:00,620 --> 00:29:04,500
나는 모든 시스템을 통해 CPU를 보낸다
함께 이러한 데이터 구조를 합류

686
00:29:04,500 --> 00:29:05,950
해당 데이터를 다시 끌어 할 수 있습니다.

687
00:29:05,950 --> 00:29:07,310
>> 그래서 내가 어떻게 그 주위에받을 수 있나요?

688
00:29:07,310 --> 00:29:11,200
NoSQL에 그것은에 관하여
집계하지 정상화.

689
00:29:11,200 --> 00:29:13,534
그래서 우리는 우리가 원하는하고 싶은 말
액세스 패턴을 지원합니다.

690
00:29:13,534 --> 00:29:15,283
액세스 패턴이면
응용 프로그램,

691
00:29:15,283 --> 00:29:16,770
내 모든 제품을 얻을 필요가있다.

692
00:29:16,770 --> 00:29:19,027
의 한 표에 모든 제품을 넣어 보자.

693
00:29:19,027 --> 00:29:22,110
나는 하나의 테이블에 모든 제품을 두는 경우에,
난 그냥 모든 제품을 선택할 수 있습니다

694
00:29:22,110 --> 00:29:23,850
그 테이블에서 나는 모든 것을 얻을.

695
00:29:23,850 --> 00:29:25,240
그럼 난 어떻게해야합니까?

696
00:29:25,240 --> 00:29:28,124
그럼 NoSQL에에 더 없다
테이블 구조.

697
00:29:28,124 --> 00:29:30,540
우리에 대해 조금 얘기하자
방법이 디나모 DB에서 작동합니다.

698
00:29:30,540 --> 00:29:33,570
하지만 당신은 같은이 없습니다
속성과 같은 속성

699
00:29:33,570 --> 00:29:37,751
하나 하나의 모든 단일 행에
항목, 당신은 SQL 테이블에서처럼.

700
00:29:37,751 --> 00:29:39,750
그리고 무엇이 날 수 있습니다
할 것은 많은 것들을입니다

701
00:29:39,750 --> 00:29:41,124
나에게 많은 유연성을 제공합니다.

702
00:29:41,124 --> 00:29:45,360
특히이 경우, I
내 제품 문서가 있습니다.

703
00:29:45,360 --> 00:29:49,090
그리고이 특히
예를 들어, 모든

704
00:29:49,090 --> 00:29:51,930
제품 테이블의 문서이다.

705
00:29:51,930 --> 00:29:56,510
그리고 책의 제품은 수도
책을 지정하는 유형 ID를 가지고 있습니다.

706
00:29:56,510 --> 00:29:59,180
그리고 응용 프로그램
그 ID를 전환 할 것입니다.

707
00:29:59,180 --> 00:30:02,570
>> 응용 프로그램 계층에서, 나는거야
아,이 무슨 레코드 유형 대답?

708
00:30:02,570 --> 00:30:04,100
아,이 책의 기록이다.

709
00:30:04,100 --> 00:30:05,990
예약 기록은 이러한 속성을 가지고있다.

710
00:30:05,990 --> 00:30:08,100
내가 책 객체를 생성 할 수 있습니다.

711
00:30:08,100 --> 00:30:11,289
그래서 난을 채울거야
이 항목을 가지고있는 책 객체입니다.

712
00:30:11,289 --> 00:30:13,080
다음 항목이 온다
이 항목은 무엇입니까,라고?

713
00:30:13,080 --> 00:30:14,560
그럼이 항목은 앨범이다.

714
00:30:14,560 --> 00:30:17,340
아, 나는 완전히 다른있어
그에 대한 처리 루틴,

715
00:30:17,340 --> 00:30:18,487
이 앨범이기 때문에.

716
00:30:18,487 --> 00:30:19,320
당신은 내가 무슨 뜻인지 볼?

717
00:30:19,320 --> 00:30:21,950
>> 그래서 응용 프로그램 tier-- 내가
다만이 모든 기록을 선택합니다.

718
00:30:21,950 --> 00:30:23,200
그들은 모두에 오는 시작합니다.

719
00:30:23,200 --> 00:30:24,680
그들은 모두 서로 다른 종류의 수 있습니다.

720
00:30:24,680 --> 00:30:27,590
그리고 응용 프로그램의 로직의
그는 그 유형에 걸쳐 전환

721
00:30:27,590 --> 00:30:29,530
및 이들의 처리 방법을 결정한다.

722
00:30:29,530 --> 00:30:33,640
>> 다시 말하지만, 우리가 최적화하고
액세스 패턴에 대한 스키마.

723
00:30:33,640 --> 00:30:36,390
우리가 그 일을하고
그 테이블을 축소.

724
00:30:36,390 --> 00:30:39,670
우리는 기본적으로 취하고있어
이러한 표준화 된 구조,

725
00:30:39,670 --> 00:30:42,000
우리가 만들고 있어요
계층 구조.

726
00:30:42,000 --> 00:30:45,130
이러한 기록의 각 내부
나는 배열 속성을 볼거야.

727
00:30:45,130 --> 00:30:49,400
>> 앨범이 문서 내부,
나는 트랙의 배열을보고 있어요.

728
00:30:49,400 --> 00:30:53,900
그 트랙은 지금 그것의 become--
기본적으로이 자식 테이블이

729
00:30:53,900 --> 00:30:56,520
바로 여기에이 구조에 존재한다.

730
00:30:56,520 --> 00:30:57,975
그래서 당신은 DynamoDB의에서이 작업을 수행 할 수 있습니다.

731
00:30:57,975 --> 00:30:59,810
당신은 MongoDB가이 작업을 수행 할 수 있습니다.

732
00:30:59,810 --> 00:31:01,437
당신은 어떤 NoSQL에 데이터베이스에서이 작업을 수행 할 수 있습니다.

733
00:31:01,437 --> 00:31:03,520
이러한 유형의 작성
계층 적 데이터 구조

734
00:31:03,520 --> 00:31:07,120
당신은 데이터를 검색 허용하는지
매우 빠르게 해주기 때문에

735
00:31:07,120 --> 00:31:08,537
준수 할 필요가 없습니다.

736
00:31:08,537 --> 00:31:11,620
나는 트랙에 행을 삽입 할 때
테이블, 또는 앨범 테이블에 행,

737
00:31:11,620 --> 00:31:13,110
그 스키마를 준수해야합니다.

738
00:31:13,110 --> 00:31:18,060
I는 속성 또는 있어야
해당 테이블에 정의 된 속성입니다.

739
00:31:18,060 --> 00:31:20,480
그들 모두,
그 행을 삽입 할 때.

740
00:31:20,480 --> 00:31:21,910
즉, NoSQL에의 경우이 아니다.

741
00:31:21,910 --> 00:31:24,440
>> 나는 완전히 다른 수 있습니다
모든 문서의 속성

742
00:31:24,440 --> 00:31:26,100
나는 컬렉션에 삽입있다.

743
00:31:26,100 --> 00:31:30,480
그래서 매우 강력한 메커니즘.

744
00:31:30,480 --> 00:31:32,852
그리고 정말 방법을이다
시스템을 최적화한다.

745
00:31:32,852 --> 00:31:35,310
대신 지금 쿼리 때문에
모든 테이블을 조인의

746
00:31:35,310 --> 00:31:39,160
반 다스 쿼리를 실행
내가 필요한 데이터를 철수하고,

747
00:31:39,160 --> 00:31:40,890
나는 하나의 쿼리를 실행하고 있습니다.

748
00:31:40,890 --> 00:31:43,010
그리고 반복 해요
결과 집합에서.

749
00:31:43,010 --> 00:31:46,512
그것은 당신에게 아이디어를 제공합니다
NoSQL에의 힘.

750
00:31:46,512 --> 00:31:49,470
나는 종류의 옆으로 여기거야
그리고 이것에 대해 조금 이야기.

751
00:31:49,470 --> 00:31:53,240
이 종류의 더욱
마케팅이나 technology--

752
00:31:53,240 --> 00:31:55,660
기술 마케팅
토론의 유형입니다.

753
00:31:55,660 --> 00:31:58,672
그러나 이해하는 것이 중요합니다
우리가 상단에 보면 때문에

754
00:31:58,672 --> 00:32:00,380
여기에이 차트에서,
우리가보고있는

755
00:32:00,380 --> 00:32:04,030
우리가 부르는 것이다
기술 과대 광고 곡선.

756
00:32:04,030 --> 00:32:06,121
그리고 이것이 의미하는 것은
새로운 물건이 활동하기 시작한다.

757
00:32:06,121 --> 00:32:07,120
사람들은 좋은 것 같아요.

758
00:32:07,120 --> 00:32:09,200
내 모든 문제를 해결했습니다.

759
00:32:09,200 --> 00:32:11,630
>> 이 마지막이 될 수
모든 모든 모든을합니다.

760
00:32:11,630 --> 00:32:12,790
그리고 그들은 그것을 사용하기 시작.

761
00:32:12,790 --> 00:32:14,720
그리고 그들은이 물건이 작동하지 않습니다 말한다.

762
00:32:14,720 --> 00:32:17,600
이것은 옳지 않다.

763
00:32:17,600 --> 00:32:19,105
오래된 물건은 더 좋았다.

764
00:32:19,105 --> 00:32:21,230
그리고 그들은 일에 돌아가
가지가 있었다 방법.

765
00:32:21,230 --> 00:32:22,730
그리고 결국
그들은 당신이 무엇을 알고, 이동?

766
00:32:22,730 --> 00:32:24,040
이 물건은 그렇게 나쁘지 않다.

767
00:32:24,040 --> 00:32:26,192
아, 그것이 작동하는 방법.

768
00:32:26,192 --> 00:32:28,900
그리고 그들은 어떻게 알아낼 번
작품, 그들은 좋아지고 시작합니다.

769
00:32:28,900 --> 00:32:32,050
>> 그리고 그것에 대해 재미있는 것은
그것까지, 선 종류 무엇

770
00:32:32,050 --> 00:32:34,300
우리는 기술 채용 곡선을 호출합니다.

771
00:32:34,300 --> 00:32:36,910
그래서 우리가 무슨 일입니다
어떤 종류의 기술 트리거.

772
00:32:36,910 --> 00:32:39,100
베이스의 경우,
이 데이터 압력이다.

773
00:32:39,100 --> 00:32:42,200
우리는 높은 물 점에 대해 이야기
시간에 걸쳐 데이터의 압력.

774
00:32:42,200 --> 00:32:46,310
그 데이터는 소정의 압력을 안타
점, 즉 기술 트리거입니다.

775
00:32:46,310 --> 00:32:47,830
>> 그것은 너무 비싸지고있다.

776
00:32:47,830 --> 00:32:49,790
데이터를 처리하는 데 너무 오래 걸린다.

777
00:32:49,790 --> 00:32:50,890
우리는 더 나은 뭔가를해야합니다.

778
00:32:50,890 --> 00:32:52,890
당신은 혁신을 얻을
거기에 주위를 실행,

779
00:32:52,890 --> 00:32:55,050
솔루션의 무엇을 찾기 위해 노력.

780
00:32:55,050 --> 00:32:56,050
새로운 아이디어는 무엇입니까?

781
00:32:56,050 --> 00:32:58,170
>> 가장 다음은 뭐지
이 일을 할 수있는 방법은?

782
00:32:58,170 --> 00:32:59,530
그리고 그들은 무엇인가 생각해.

783
00:32:59,530 --> 00:33:03,140
그리고 진짜 고통과 사람들,
출혈 가장자리에 사람,

784
00:33:03,140 --> 00:33:06,390
그들은 그 위에 모든 점프 것이다,
그들은 대답을해야하기 때문이다.

785
00:33:06,390 --> 00:33:09,690
이제 필연적으로 happens-- 무엇을
그것은 NoSQL에에서 지금 무슨 일이 일어나고.

786
00:33:09,690 --> 00:33:11,090
나는 모든 시간을 참조하십시오.

787
00:33:11,090 --> 00:33:13,610
>> 어떤 필연적으로 발생하는 것은
사람들은 새로운 도구를 사용하여 시작

788
00:33:13,610 --> 00:33:15,490
동일한 방법은 이전 도구를 사용했다.

789
00:33:15,490 --> 00:33:17,854
그리고 그들은 그것을 알아
잘 작동하지 않습니다.

790
00:33:17,854 --> 00:33:20,020
나는 내가 누군지 기억이 안나요
오늘 아침에 얘기합니다.

791
00:33:20,020 --> 00:33:22,080
하지만, 때 등이다
착암기가 발명되었다,

792
00:33:22,080 --> 00:33:24,621
사람들은 그것을 통해 스윙을하지 않았다
그들의 머리는 콘크리트를 분쇄합니다.

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

794
00:33:27,360 --> 00:33:30,610
>> 하지만 그 무엇이다
오늘 NoSQL에 일어나고.

795
00:33:30,610 --> 00:33:33,900
당신은 대부분의 상점에 걸 으면,
그들은 NoSQL에 상점으로 노력하고 있습니다.

796
00:33:33,900 --> 00:33:36,510
그들이하고있는 것은
그들은, NoSQL에를 사용하는

797
00:33:36,510 --> 00:33:39,900
그리고 그들은 그것을로드하는
관계형 스키마의 전체.

798
00:33:39,900 --> 00:33:41,630
그 방법이기 때문에
그들은 데이터베이스를 설계합니다.

799
00:33:41,630 --> 00:33:44,046
그리고 그들은 왜, 궁금해
아주 잘 수행하지?

800
00:33:44,046 --> 00:33:45,230
소년이 일이 냄새.

801
00:33:45,230 --> 00:33:49,900
나는 모든을 유지했다 나의
그것은 아니, 아니, 같은입니다 in-- 합류했다.

802
00:33:49,900 --> 00:33:50,800
조인 유지?

803
00:33:50,800 --> 00:33:52,430
왜 당신은 데이터에 합류?

804
00:33:52,430 --> 00:33:54,350
당신은 NoSQL에 데이터를 조인하지 않습니다.

805
00:33:54,350 --> 00:33:55,850
당신은 그것을 집계.

806
00:33:55,850 --> 00:34:00,690
>> 당신이이 문제를 방지하려면, 배울 그래서
이 도구는 실제로 전에 작동하는 방법

807
00:34:00,690 --> 00:34:02,010
그것을 사용하기 시작.

808
00:34:02,010 --> 00:34:04,860
시도하고 새로운 도구를 사용하지 마십시오
같은 방법으로 당신은 기존의 툴을 사용했다.

809
00:34:04,860 --> 00:34:06,500
당신은 나쁜 경험이 될 것입니다.

810
00:34:06,500 --> 00:34:08,848
그리고 매번
즉,이에 대해 무엇이다.

811
00:34:08,848 --> 00:34:11,389
우리가 여기에 오는 시작할 때,
사람들이 알아 낸 때문입니다

812
00:34:11,389 --> 00:34:13,449
어떻게 도구를 사용합니다.

813
00:34:13,449 --> 00:34:16,250
>> 그들은 때 같은 일을했다
관계형 데이터베이스가 발명되었다,

814
00:34:16,250 --> 00:34:17,969
그들이 파일 시스템을 대체 하였다.

815
00:34:17,969 --> 00:34:20,420
이들 파일 시스템을 구축하려고
관계형 데이터베이스와

816
00:34:20,420 --> 00:34:22,159
그 사람들이 이해 무엇 때문입니다.

817
00:34:22,159 --> 00:34:23,049
그것은 작동하지 않았다.

818
00:34:23,049 --> 00:34:26,090
모범 사례를 이해 그래서
기술을 사용하면 작업중인

819
00:34:26,090 --> 00:34:26,730
거대하다​​.

820
00:34:26,730 --> 00:34:29,870
매우 중요.

821
00:34:29,870 --> 00:34:32,440
>> 그래서 우리는 DynamoDB의에 들어갈 것입니다.

822
00:34:32,440 --> 00:34:36,480
DynamoDB의는 AWS의의입니다
NoSQL에 플랫폼을 완벽하게 처리했다.

823
00:34:36,480 --> 00:34:37,719
무엇을 의미를 완벽하게 관리 하는가?

824
00:34:37,719 --> 00:34:40,010
그것은 당신이 할 필요가 없습니다 의미
정말 아무것도 걱정.

825
00:34:40,010 --> 00:34:42,060
>> 당신은 와서, 당신이 말해
우리는, 나는 테이블이 필요합니다.

826
00:34:42,060 --> 00:34:43,409
그것은이 많은 용량을 필요로한다.

827
00:34:43,409 --> 00:34:47,300
당신은 버튼을 누르면, 우리 제공
장면 뒤에 모든 인프라를 제공합니다.

828
00:34:47,300 --> 00:34:48,310
지금은 거대하다.

829
00:34:48,310 --> 00:34:51,310
>> 당신이 말할 때 때문에
데이터베이스에 대한 스케일링,

830
00:34:51,310 --> 00:34:53,917
NoSQL에 데이터 클러스터에
규모, 실행 페타 바이트,

831
00:34:53,917 --> 00:34:55,750
수백만을 실행
초당 트랜잭션,

832
00:34:55,750 --> 00:34:58,180
이런 일들은 작은 클러스터되지 않습니다.

833
00:34:58,180 --> 00:35:00,830
우리는 인스턴스의 수천을 얘기.

834
00:35:00,830 --> 00:35:04,480
인스턴스의 수천을 관리,
심지어 가상 인스턴스

835
00:35:04,480 --> 00:35:06,350
엉덩이에 진짜 고통이다.

836
00:35:06,350 --> 00:35:09,110
나는 모든 시간에 대해 생각 의미
운영체제 패치 나온다

837
00:35:09,110 --> 00:35:11,552
또는 데이터베이스의 새로운 버전.

838
00:35:11,552 --> 00:35:13,260
그게 무슨 뜻 이죠
당신에게 운영 체제는?

839
00:35:13,260 --> 00:35:16,330
즉, 1,200있어 의미
필요가 서버를 업데이트 할 수 있습니다.

840
00:35:16,330 --> 00:35:18,960
지금도 자동화,
즉, 시간이 오래 걸릴 수있다.

841
00:35:18,960 --> 00:35:21,480
즉 많이 발생할 수
운영 두통,

842
00:35:21,480 --> 00:35:23,090
나는 서비스를해야 할 수도 있기 때문이다.

843
00:35:23,090 --> 00:35:26,070
>> 나는 이러한 데이터베이스를 업데이트 할 때, 나는
푸른 녹색 배포 할 수 있습니다

844
00:35:26,070 --> 00:35:29,420
어디 배포 및 업그레이드 반 내
노드는 다음 나머지 절반을 업그레이드.

845
00:35:29,420 --> 00:35:30,490
그 아래로 가라.

846
00:35:30,490 --> 00:35:33,410
그래서 인프라 관리
규모는 엄청난 고통이다.

847
00:35:33,410 --> 00:35:36,210
그리고 AWS는 그것의 고통을.

848
00:35:36,210 --> 00:35:39,210
그리고 NoSQL에 데이터베이스를 수
매우 고통

849
00:35:39,210 --> 00:35:41,780
그들이 확장 방식 때문이다.

850
00:35:41,780 --> 00:35:42,926
>> 수평으로 확장 할 수 있습니다.

851
00:35:42,926 --> 00:35:45,550
당신은 더 큰 NoSQL에를 얻고 싶다면
데이터베이스는, 당신은 더 많은 노드를 구입할 수 있습니다.

852
00:35:45,550 --> 00:35:48,660
당신이 살 모든 노드는
다른 운영 두통.

853
00:35:48,660 --> 00:35:50,830
그래서 다른 사람이 당신을 위해 그렇게 할 수 있습니다.

854
00:35:50,830 --> 00:35:52,000
AWS는 그 작업을 수행 할 수 있습니다.

855
00:35:52,000 --> 00:35:54,587
>> 우리는 문서의 키 값을 지원합니다.

856
00:35:54,587 --> 00:35:56,670
이제 우리는 너무 많이 가지 않았다
다른 차트에.

857
00:35:56,670 --> 00:35:58,750
다른 많은있다
NoSQL에의 맛.

858
00:35:58,750 --> 00:36:02,670
그들은 점점 모든 종류의 것
이 시점에서 함께 munged.

859
00:36:02,670 --> 00:36:06,260
당신은 DynamoDB의보고 예라고 할 수 있습니다
우리는 문서와 키 값 모두에있어

860
00:36:06,260 --> 00:36:08,412
이 점을 저장합니다.

861
00:36:08,412 --> 00:36:10,620
그리고 당신은 기능을 주장 할 수 있습니다
다른 통해 하나.

862
00:36:10,620 --> 00:36:13,950
나에게,이 많은 정말 여섯입니다
반 다른 다스의.

863
00:36:13,950 --> 00:36:18,710
이 기술 하나 하나가
좋은 기술과 좋은 솔루션입니다.

864
00:36:18,710 --> 00:36:23,390
나는 MongoDB를 더 나은 또는이다 언급하지 않았다
다음 소파, 카산드라보다 더,

865
00:36:23,390 --> 00:36:25,994
다음 디나모, 또는 그 반대.

866
00:36:25,994 --> 00:36:27,285
나는이 그냥 옵션입니다, 의미한다.

867
00:36:27,285 --> 00:36:29,850

868
00:36:29,850 --> 00:36:32,700
>> 그것은 빠르고 그리고 그것은이다
어떤 규모의 일관.

869
00:36:32,700 --> 00:36:36,210
그래서이 가장 큰 중 하나입니다
보너스 당신은 AWS로 얻을.

870
00:36:36,210 --> 00:36:40,850
DynamoDB의와 능력이다
낮은 한 자리를 얻을 수 있습니다

871
00:36:40,850 --> 00:36:44,040
어떤 규모의 밀리 초 대기 시간.

872
00:36:44,040 --> 00:36:45,720
즉, 시스템의 설계 목표였다.

873
00:36:45,720 --> 00:36:49,130
그리고 우리가하고있는 고객이
초당 트랜잭션의 수백만.

874
00:36:49,130 --> 00:36:52,670
>> 지금은 그 중 몇 가지를 통해 갈거야
여기에 몇 분의 경우를 사용합니다.

875
00:36:52,670 --> 00:36:55,660
통합 액세스 control--
우리는 우리가 부르는이

876
00:36:55,660 --> 00:36:57,920
신원 접근 관리, 또는 IAM.

877
00:36:57,920 --> 00:37:01,980
그것은 모든 시스템을 침투,
AWS가 제공하는 모든 서비스를 제공합니다.

878
00:37:01,980 --> 00:37:03,630
DynamoDB의 예외는 아니다.

879
00:37:03,630 --> 00:37:06,020
당신은 액세스를 제어 할 수 있습니다
DynamoDB의 테이블에.

880
00:37:06,020 --> 00:37:09,960
당신의 AWS에 의해 계정 모두에 걸쳐
액세스 역할 및 권한을 정의

881
00:37:09,960 --> 00:37:12,140
IAM 인프라.

882
00:37:12,140 --> 00:37:16,630
>> 그리고 그것은의 키와 필수 구성 요소이다
우리는 기반 프로그래밍 이벤트를 부르는 것.

883
00:37:16,630 --> 00:37:19,056
지금 이것은 새로운 패러다임이다.

884
00:37:19,056 --> 00:37:22,080
>> 청중 : 어떻게 진정한 당신의 속도입니다
위음성 대 양성

885
00:37:22,080 --> 00:37:24,052
액세스 제어 시스템?

886
00:37:24,052 --> 00:37:26,260
릭 리한 (Houlihan) : 참 긍정적
위음성 대?

887
00:37:26,260 --> 00:37:28,785
청중 : 무엇을 반환
당신은 반환되어야 하는가?

888
00:37:28,785 --> 00:37:33,720
한 번에 한 동안 반대로로
이 확인해야 할 때 반환하지 않습니다?

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

890
00:37:36,260 --> 00:37:38,050
>> 릭 리한 (Houlihan) : 나는 당신에게 그렇게 말할 수 없습니다.

891
00:37:38,050 --> 00:37:40,140
어떤 실패가 있다면
무엇이든지 그에,

892
00:37:40,140 --> 00:37:42,726
내가 요청하는 사람이 아니에요
특정 질문입니다.

893
00:37:42,726 --> 00:37:43,850
그러나 그것은 좋은 질문이다.

894
00:37:43,850 --> 00:37:45,905
알고 궁금 할 것이다
나 자신이, 실제로.

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

896
00:37:48,810 --> 00:37:51,320
>> 그리고 다시, 새로운 패러다임
이벤트 기반의 프로그램이다.

897
00:37:51,320 --> 00:37:55,160
이것은 당신이 할 수있는 생각이다
복잡한 응용 프로그램을 배포하는

898
00:37:55,160 --> 00:37:59,720
매우, 매우 높은 규모를 조작 할 수 있습니다
어떠한 인프라없이.

899
00:37:59,720 --> 00:38:02,120
어떤 고정하지 않고
어떠한 인프라입니다.

900
00:38:02,120 --> 00:38:04,720
그리고 우리는 조금 얘기하자
즉 우리로 무엇을 의미하는지에 대한

901
00:38:04,720 --> 00:38:06,550
차트의 다음 커플에 도착.

902
00:38:06,550 --> 00:38:08,716
>> 우리가 할 것 먼저
우리는 테이블에 대해 이야기 할 것입니다.

903
00:38:08,716 --> 00:38:10,857
디나모에 대한 API 데이터 유형.

904
00:38:10,857 --> 00:38:13,190
먼저 당신은거야
당신이 볼 때 알,

905
00:38:13,190 --> 00:38:17,930
당신이 데이터베이스에 익숙하다면,
데이터베이스 API를 정말 두 종류가

906
00:38:17,930 --> 00:38:18,430
나는 그것을 호출 할 것입니다.

907
00:38:18,430 --> 00:38:21,570
또는 API의 두 세트.

908
00:38:21,570 --> 00:38:23,840
그 중 하나가 될 것이다
관리 API.

909
00:38:23,840 --> 00:38:26,710
>> 그들이 알아서 일
데이터베이스 기능한다.

910
00:38:26,710 --> 00:38:31,340
스토리지 엔진을 구성,
설정 및 테이블을 추가.

911
00:38:31,340 --> 00:38:35,180
만드는 데이터베이스
카탈로그 및 인스턴스.

912
00:38:35,180 --> 00:38:40,450
DynamoDB의에서이 things--, 당신
매우 짧은, 짧은 목록을 가지고있다.

913
00:38:40,450 --> 00:38:43,120
>> 그래서 다른 데이터베이스에서,
당신은 수십 볼 수 있습니다

914
00:38:43,120 --> 00:38:45,680
행정의 명령,
명령, 구성

915
00:38:45,680 --> 00:38:47,290
이러한 추가 옵션.

916
00:38:47,290 --> 00:38:51,234
DynamoDB의 당신 때문에 그 필요하지 않습니다
시스템을 구성하지, 우리가 할.

917
00:38:51,234 --> 00:38:54,150
그래서 당신이해야 할 유일한 일이다
내가 필요로 하는가의 사이즈 표 말해.

918
00:38:54,150 --> 00:38:55,660
그래서 당신은 매우를 얻을 수
명령의 제한을 설정합니다.

919
00:38:55,660 --> 00:38:58,618
>> 당신은 표 업데이트를 작성 얻을, 표,
테이블을 삭제하고 테이블을 설명하십시오.

920
00:38:58,618 --> 00:39:01,150
사람들은 유일한 것들
당신은 DynamoDB의를 위해 필요합니다.

921
00:39:01,150 --> 00:39:03,294
당신은 저장이 필요하지 않습니다
엔진 구성.

922
00:39:03,294 --> 00:39:04,960
나는 복제에 대해 걱정할 필요가 없습니다.

923
00:39:04,960 --> 00:39:06,490
나는 샤딩에 대해 걱정할 필요가 없습니다.

924
00:39:06,490 --> 00:39:07,800
>> 나는 걱정할 필요가 없습니다
이 물건의 약.

925
00:39:07,800 --> 00:39:08,740
우리는 당신을 위해 모든 작업을 수행 할 수 있습니다.

926
00:39:08,740 --> 00:39:11,867
그래서 오버 헤드의 엄청난 금액이다
그것은 단지 당신의 접시를 해제합니다.

927
00:39:11,867 --> 00:39:13,200
그 다음 우리는 CRUD 사업자가 있습니다.

928
00:39:13,200 --> 00:39:17,740
CRUD 뭔가 우리입니다
데이터베이스의 전화

929
00:39:17,740 --> 00:39:19,860
, 업데이트, 연산자를 삭제 만듭니다.

930
00:39:19,860 --> 00:39:24,180
다음은 일반적인
데이터베이스 작업.

931
00:39:24,180 --> 00:39:31,299
풋 항목 같은 것들, 항목, 업데이 트를 얻을
항목, 항목을 삭제, 일괄 조회, 검사.

932
00:39:31,299 --> 00:39:32,840
당신은 전체 테이블을 스캔합니다.

933
00:39:32,840 --> 00:39:34,220
테이블 오프 모두를 당깁니다.

934
00:39:34,220 --> 00:39:37,130
DynamoDB의 좋은 점 중 하나
이 병렬 검색을 할 수 있습니다.

935
00:39:37,130 --> 00:39:40,602
그래서 당신은 실제로 얼마나 많은 알려 수 있습니다
스레드는 해당 검사에서 실행합니다.

936
00:39:40,602 --> 00:39:41,810
그리고 우리는 그 스레드를 실행할 수 있습니다.

937
00:39:41,810 --> 00:39:43,985
우리는 최대 스캔 회전 수
여러 스레드에서

938
00:39:43,985 --> 00:39:49,060
그래서 당신은 전체 테이블을 스캔 할 수 있습니다
매우, 매우 빠르게 DynamoDB의 공간.

939
00:39:49,060 --> 00:39:51,490
>> 우리가 다른 API입니다
우리는 우리의 스트림 API를 부르는 것.

940
00:39:51,490 --> 00:39:52,940
우리는 너무 얘기하지 않을거야
지금 이것에 대해 많은.

941
00:39:52,940 --> 00:39:55,189
나는 일부 콘텐츠 나중에있어
이 약 갑판에.

942
00:39:55,189 --> 00:39:59,910
그러나 스트림 정말 running--입니다
시간 순서로 생각

943
00:39:59,910 --> 00:40:01,274
및 파티션 변경 로그.

944
00:40:01,274 --> 00:40:03,940
에 일어나는 모든
테이블이 스트림에 표시됩니다.

945
00:40:03,940 --> 00:40:05,940
>> 모든 테이블에 기록
스트림에 표시됩니다.

946
00:40:05,940 --> 00:40:08,370
당신은 그 흐름을 읽고, 수
당신은 그것으로 일을 할 수있다.

947
00:40:08,370 --> 00:40:10,150
우리는 얘기하자 무슨
가지 타입의

948
00:40:10,150 --> 00:40:13,680
복제 같은 것들과는,
보조 인덱스를 생성.

949
00:40:13,680 --> 00:40:17,620
정말 멋진 모든 종류의
이것은 당신이 그와 함께 할 수 있습니다.

950
00:40:17,620 --> 00:40:19,150
>> 데이터 유형.

951
00:40:19,150 --> 00:40:23,320
DynamoDB의, 우리는 모두 키를 지원
가치와 문서 데이터 유형.

952
00:40:23,320 --> 00:40:26,350
화면 왼쪽
여기에, 우리는 우리의 기본 유형을 가지고있다.

953
00:40:26,350 --> 00:40:27,230
키 값 유형.

954
00:40:27,230 --> 00:40:30,040
다음은 문자열,
숫자, 바이너리.

955
00:40:30,040 --> 00:40:31,640
>> 그러니 세 가지 기본 유형.

956
00:40:31,640 --> 00:40:33,700
그리고 당신은 그 세트를 가질 수 있습니다.

957
00:40:33,700 --> 00:40:37,650
좋은 것들 중 하나 NoSQL에이 약
당신은 속성으로 배열을 포함 할 수 있습니다.

958
00:40:37,650 --> 00:40:42,050
그리고 DynamoDB의 당신은 배열을 포함 할 수 있습니다
루트 속성으로 기본 유형의.

959
00:40:42,050 --> 00:40:43,885
>> 그리고 문서 유형이있다.

960
00:40:43,885 --> 00:40:45,510
얼마나 많은 사람들이 JSON을 잘 알고있는?

961
00:40:45,510 --> 00:40:47,130
너무 많은 JSON을 잘 알고 너희들?

962
00:40:47,130 --> 00:40:49,380
그것은 기본적으로 자바 스크립트의
개체 표기법.

963
00:40:49,380 --> 00:40:52,510
그것은 당신이 기본적으로 할 수 있습니다
계층 구조를 정의한다.

964
00:40:52,510 --> 00:40:58,107
>> 당신은에 JSON 문서를 저장할 수 있습니다
DynamoDB의 공통 부품을 사용하여

965
00:40:58,107 --> 00:41:00,940
또는 빌딩 블록을 사용할 수 있습니다
대부분의 프로그래밍 언어이다.

966
00:41:00,940 --> 00:41:03,602
당신이 자바를 가지고 있다면, 당신은있어
지도와 목록을보고.

967
00:41:03,602 --> 00:41:05,060
그 지역지도 개체를 만들 수 있습니다.

968
00:41:05,060 --> 00:41:08,030
키 값으로지도
속성으로 저장.

969
00:41:08,030 --> 00:41:10,890
그리고 목록이있을 수 있습니다
이러한 속성 내에서 값.

970
00:41:10,890 --> 00:41:13,490
이 복잡​​한 저장할 수 있습니다
계층 구조

971
00:41:13,490 --> 00:41:16,320
하나의 특성으로
DynamoDB의 항목.

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

973
00:41:19,010 --> 00:41:24,460
>> DynamoDB의의 테이블 그래서, 가장 좋아하는
NoSQL에 데이터베이스는 테이블 항목이있다.

974
00:41:24,460 --> 00:41:26,469
MongoDB를 당신은 것
이러한 문서를 호출합니다.

975
00:41:26,469 --> 00:41:27,760
그리고 소파의 기본이 될 것이다.

976
00:41:27,760 --> 00:41:28,900
또한 문서 데이터베이스.

977
00:41:28,900 --> 00:41:29,941
당신은이 문서를 호출합니다.

978
00:41:29,941 --> 00:41:32,930
문서 또는 항목 속성이 있습니다.

979
00:41:32,930 --> 00:41:35,850
속성이 존재하거나
항목에 존재하지.

980
00:41:35,850 --> 00:41:38,520
DynamoDB의에서, 거기에
하나의 필수 특성입니다.

981
00:41:38,520 --> 00:41:43,880
그냥 관계형 데이터베이스처럼,
당신은 테이블에 기본 키를 가지고있다.

982
00:41:43,880 --> 00:41:46,010
>> DynamoDB의 우리가 해시 키를 부르는 있습니다.

983
00:41:46,010 --> 00:41:48,280
해시 키는 고유해야합니다.

984
00:41:48,280 --> 00:41:52,580
그래서 해시 테이블을 정의 할 때,
기본적으로 무슨 말인지

985
00:41:52,580 --> 00:41:54,110
모든 항목들이 해시 키를 가질 것이다.

986
00:41:54,110 --> 00:41:58,520
그리고 모든 해시 키는 고유해야합니다.

987
00:41:58,520 --> 00:42:01,200
>> 모든 항목이 정의된다
그 고유의 해시 키에 의해.

988
00:42:01,200 --> 00:42:02,940
하나만이있을 수있다.

989
00:42:02,940 --> 00:42:05,820
이 확인을하지만, 자주
어떤 사람들이 필요

990
00:42:05,820 --> 00:42:08,170
그들이 원하는 것은이 해시
더 조금 할 키

991
00:42:08,170 --> 00:42:11,010
보다 그냥 고유 식별자.

992
00:42:11,010 --> 00:42:15,240
때때로 우리는 해시 키를 사용할
최고 수준의 통합 버킷있다.

993
00:42:15,240 --> 00:42:19,160
그리고 우리는 그렇게 할 방법입니다
우리는 다양한 키를 부르는 덧붙였다.

994
00:42:19,160 --> 00:42:22,460
>> 그것은 단지 해시의 경우에 따라서
테이블이 고유해야합니다.

995
00:42:22,460 --> 00:42:27,040
이 해시 및 범위 테이블이 있다면,
해시 및 범위의 조합

996
00:42:27,040 --> 00:42:28,640
고유해야합니다.

997
00:42:28,640 --> 00:42:30,110
그래서 이런 식으로 그것에 대해 생각합니다.

998
00:42:30,110 --> 00:42:32,140
나는 포럼이있는 경우.

999
00:42:32,140 --> 00:42:39,010
그리고 형태는이 주제를 가지고
포스트 및 그 응답을 갖는다.

1000
00:42:39,010 --> 00:42:42,630
>> 그래서 해시가있을 수 있습니다
주제 ID입니다 키.

1001
00:42:42,630 --> 00:42:46,650
그리고 다양한 키가있을 수 있습니다,
이는 응답 ID입니다.

1002
00:42:46,650 --> 00:42:49,650
그런 식으로 나는 모든을 얻으려면
특정 주제에 대한 응답,

1003
00:42:49,650 --> 00:42:52,370
난 그냥 해시를 조회 할 수 있습니다.

1004
00:42:52,370 --> 00:42:55,190
나는 나에게 모든 것을 줄 말을 바로 할 수 있습니다
이 해시가 상품.

1005
00:42:55,190 --> 00:43:01,910
그리고 나는 모든 질문을받을거야
또는 특정 주제를 게시합니다.

1006
00:43:01,910 --> 00:43:03,910
이러한 최고 수준의 집계
매우 중요하다.

1007
00:43:03,910 --> 00:43:07,370
그들은 기본 액세스를 지원
응용 프로그램의 패턴.

1008
00:43:07,370 --> 00:43:09,420
일반적으로,이 말하기
우리가하고 싶은 것입니다.

1009
00:43:09,420 --> 00:43:11,780
우리는 table--을 원하는
사용자가 테이블을로드로서,

1010
00:43:11,780 --> 00:43:16,640
우리는 데이터를 구조화 할
이러한 방식으로 테이블 내의

1011
00:43:16,640 --> 00:43:20,140
즉, 응용 프로그램은 매우 수
빨리 그 결과를 검색 할 수 있습니다.

1012
00:43:20,140 --> 00:43:24,510
그리고 자주 그렇게 할 수있는 방법입니다
우리는 이러한 집계를 유지하기 위해

1013
00:43:24,510 --> 00:43:25,650
데이터를 삽입.

1014
00:43:25,650 --> 00:43:31,110
기본적으로, 우리는 데이터를 확산하고
밝은 양동이로는에 온다.

1015
00:43:31,110 --> 00:43:35,210
>> 범위 키는 가구 있구만 해시를 허용
키는 평등해야한다.

1016
00:43:35,210 --> 00:43:39,490
내가 해시를 조회 할 때, 나는 말을해야
나에게이 동일 해시를 제공합니다.

1017
00:43:39,490 --> 00:43:41,950
나는 범위를 조회 할 때,
나에게 범위를 제공 말할 수있다

1018
00:43:41,950 --> 00:43:47,040
그 어떤 종류의를 사용하고 있습니다
우리가 지원하는 풍부한 연산자.

1019
00:43:47,040 --> 00:43:49,200
나에게 해시에 대한 모든 항목을 지정합니다.

1020
00:43:49,200 --> 00:43:52,520
또한,보다 큰 같다
그 시작 않습니다 미만,

1021
00:43:52,520 --> 00:43:54,145
이들 두 값 사이에 존재 하는가?

1022
00:43:54,145 --> 00:43:56,811
범위 쿼리 그래서 이러한 유형의
우리는 항상 관심이있다.

1023
00:43:56,811 --> 00:43:59,650
이제 데이터에 대한 한 가지, 때
당신이 때 데이터에 액세스 보면

1024
00:43:59,650 --> 00:44:02,360
사용자가 데이터에 액세스, 그건
항상 집계에 대한.

1025
00:44:02,360 --> 00:44:05,770
이 기록에 대해 항상
즉,이 관련되어있다.

1026
00:44:05,770 --> 00:44:10,390
여기에 나에게 모든 것을주고 모든 that's--
이 신용 카드의 거래

1027
00:44:10,390 --> 00:44:12,500
지난 달.

1028
00:44:12,500 --> 00:44:13,960
즉, 집합입니다.

1029
00:44:13,960 --> 00:44:17,490
>> 거의 모든 당신은에서 할
데이터베이스는 집계의 일종이다.

1030
00:44:17,490 --> 00:44:21,530
정의 할 수있을 그래서 인 수
이 버킷 당신에게 이러한 범위를 제공

1031
00:44:21,530 --> 00:44:24,950
에 쿼리 할 수​​ 속성,
그 풍부한 쿼리는, 많은 지원

1032
00:44:24,950 --> 00:44:27,165
많은, 많은 응용 프로그램의 액세스 패턴.

1033
00:44:27,165 --> 00:44:30,990

1034
00:44:30,990 --> 00:44:35,000
>> 다른 것은 해시 키 그래서
합니까는 우리에게 메커니즘을 제공하다

1035
00:44:35,000 --> 00:44:37,740
주위에 데이터를 분산 할 수 있습니다.

1036
00:44:37,740 --> 00:44:40,390
NoSQL에 데이터베이스가 최고의 작품
언제 데이터가 균등하다

1037
00:44:40,390 --> 00:44:41,740
클러스터에 분산.

1038
00:44:41,740 --> 00:44:44,530

1039
00:44:44,530 --> 00:44:47,050
얼마나 많은 사람들이 잘 알고있는
해시 알고리즘과?

1040
00:44:47,050 --> 00:44:49,860
나는 해시 hashing--를 말할 때
해싱 알고리즘 때문에

1041
00:44:49,860 --> 00:44:54,140
생성 할 수있는 하나의 방법은
주어진 값에서 임의의 값입니다.

1042
00:44:54,140 --> 00:44:59,300
이 특정한 경우에 따라서,
우리는 실행될 해시 알고리즘 기반 ND 5이다.

1043
00:44:59,300 --> 00:45:04,765
>> 그리고 ID를 가지고 있고,이 경우
내 해시 키이며, I는 1, 2, 3을 갖는다.

1044
00:45:04,765 --> 00:45:07,390
내가 해시 알고리즘을 실행하면,
그것은, 다시 와서 말 것

1045
00:45:07,390 --> 00:45:10,800
도 1, 2와 동일 7B
48 같다 3 CD는 같습니다.

1046
00:45:10,800 --> 00:45:13,092
그들은 모든 주요 공간에 걸쳐있어.

1047
00:45:13,092 --> 00:45:14,050
그리고 왜 당신이해야합니까?

1048
00:45:14,050 --> 00:45:17,120
그 확실하게 그 때문에 내가 할 수있는
여러 노드에 기록을했습니다.

1049
00:45:17,120 --> 00:45:19,574
>> 나는이 일을 해요 경우
점진적으로, 1, 2, 3.

1050
00:45:19,574 --> 00:45:21,990
그리고 해시 범위가 그
이 특정한 경우에 실행,

1051
00:45:21,990 --> 00:45:24,785
작은 해시 공간
그것은, FF 00에서 실행

1052
00:45:24,785 --> 00:45:27,951
다음 기록은 올거야
그들이 가려고하는 1, 2, 3, 4, 5,

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

1054
00:45:30,390 --> 00:45:31,800
무슨 일이야?

1055
00:45:31,800 --> 00:45:34,860
모든 인서트는 동일한 노드로 이동된다.

1056
00:45:34,860 --> 00:45:36,070
당신은 내가 무슨 뜻인지 볼?

1057
00:45:36,070 --> 00:45:40,910
>> 내가 공간을 분할 할 때 때문에,
나는 걸쳐 이러한 레코드를 확산

1058
00:45:40,910 --> 00:45:45,950
그리고 파티션, 내가 말할거야
파티션 1은 54 키 공간 0이 있습니다.

1059
00:45:45,950 --> 00:45:47,720
파티션 2는 55-89이다.

1060
00:45:47,720 --> 00:45:49,780
파티션 3은 FF에 AA입니다.

1061
00:45:49,780 --> 00:45:53,740
내가 증가 선형 적으로 사용하고 있다면
ID는, 당신은 무슨 일이 일어나고 있는지 볼 수 있습니다.

1062
00:45:53,740 --> 00:45:57,410
1, 2, 3, 4, 5, 6, 54 행까지 모든 방법.

1063
00:45:57,410 --> 00:46:00,030
나는 망치거야 그래서
시스템에 기록,

1064
00:46:00,030 --> 00:46:02,030
모든 것이 하나의 노드에가는 끝납니다.

1065
00:46:02,030 --> 00:46:03,160
>> 그 좋지 않다.

1066
00:46:03,160 --> 00:46:04,820
즉 반 패턴입니다.

1067
00:46:04,820 --> 00:46:08,760
MongoDB를 그들은이 문제가
당신은 해시 키를 사용하지 않을 경우.

1068
00:46:08,760 --> 00:46:11,325
MongoDB를 당신에게 옵션을 제공합니다
의 키 값을 해싱​​.

1069
00:46:11,325 --> 00:46:13,950
당신은 항상 경우, 그렇게해야
당신은 증가하는 해시를 사용하고

1070
00:46:13,950 --> 00:46:17,380
MongoDB의 핵심은, 또는 당신이있을거야
하나의 노드에 모든 기록을 못 박는,

1071
00:46:17,380 --> 00:46:21,290
당신은 제한 될 것
심하게 당신의 쓰기 처리량.

1072
00:46:21,290 --> 00:46:24,896
>> 청중 : 소수에 그 A9 169인가?

1073
00:46:24,896 --> 00:46:28,450
>> 릭 리한 (Houlihan) : 그래, 그것의
어딘가에 주변.

1074
00:46:28,450 --> 00:46:29,950
A9, 나도 몰라.

1075
00:46:29,950 --> 00:46:32,200
당신은 내 바이너리를 얻을 수있는 것
소수점 계산한다.

1076
00:46:32,200 --> 00:46:34,237
나의 뇌는 그런 식으로 작동하지 않습니다.

1077
00:46:34,237 --> 00:46:36,320
청중 : 그냥 빨리 하나
당신의 몽고 코멘트.

1078
00:46:36,320 --> 00:46:39,530
그래서 제공되는 오브젝트 ID입니다
기본적으로 몽고에 해당합니까?

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

1080
00:46:40,179 --> 00:46:41,470
릭 리한 (Houlihan) : 그것은 그렇게합니까?

1081
00:46:41,470 --> 00:46:42,970
당신은 그것을 지정합니다.

1082
00:46:42,970 --> 00:46:45,030
MongoDB를 사용하면 옵션이 있습니다.

1083
00:46:45,030 --> 00:46:48,930
당신은에있는 모든 문서를 specify-- 수 있습니다
MongoDB를 밑줄 ID를 가지고 있습니다.

1084
00:46:48,930 --> 00:46:50,300
즉, 고유 한 값입니다.

1085
00:46:50,300 --> 00:46:55,240
>> MongoDB를에서 지정할 수 있습니다
그것을 해시 여부를.

1086
00:46:55,240 --> 00:46:56,490
그들은 단지 당신에게 옵션을 제공합니다.

1087
00:46:56,490 --> 00:46:58,198
당신은 그것의 알고있는 경우
랜덤, 아무 문제 없습니다.

1088
00:46:58,198 --> 00:46:59,640
당신은 그렇게 할 필요가 없습니다.

1089
00:46:59,640 --> 00:47:04,260
당신은 것으로, 임의 아니라고 알고있는 경우
이 증가있어, 다음 해시를 수행.

1090
00:47:04,260 --> 00:47:06,880
>> 이제 일에 대한
당신이 해시하면, 해시

1091
00:47:06,880 --> 00:47:08,800
value--이입니다
왜 해시 키는 항상

1092
00:47:08,800 --> 00:47:13,740
독특한 쿼리, 나는 변경했기 때문에
값은, 지금은 범위 쿼리를 수행 할 수 없습니다.

1093
00:47:13,740 --> 00:47:15,640
나는이는 말할 수 없다
이 또는 그 사이에,

1094
00:47:15,640 --> 00:47:20,800
해시 값이 진행되지 않기 때문에
실제 값에 해당합니다.

1095
00:47:20,800 --> 00:47:24,570
그래서 그 해시 때
키, 그것은 단지 평등이다.

1096
00:47:24,570 --> 00:47:28,700
이것은 왜 DynamoDB의 해시 키에
쿼리는 항상 유일한 평등이다.

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

1098
00:47:32,090 --> 00:47:34,700
>> 그래서 지금 범위 key--
그 범위 키를 추가 할 때,

1099
00:47:34,700 --> 00:47:38,180
그 범위 키 기록이 모두 와서
그들은 같은 파티션에 저장 얻을.

1100
00:47:38,180 --> 00:47:42,430
그래서 그들은 쉽게 매우 빠르게 아르
이 때문에 해시 검색된

1101
00:47:42,430 --> 00:47:43,220
이는 범위이다.

1102
00:47:43,220 --> 00:47:44,928
그리고 당신은 모든 것을 볼
같은 해시

1103
00:47:44,928 --> 00:47:48,550
같은 파티션 공간에 저장됩니다.

1104
00:47:48,550 --> 00:47:53,889
당신은 수 있도록 그 범위의 키를 사용할 수 있습니다
부모에 가까운 데이터를 찾습니다.

1105
00:47:53,889 --> 00:47:55,180
그래서 난 정말 여기서 뭐하는 거지?

1106
00:47:55,180 --> 00:47:57,320
이것은 많은 관계입니다.

1107
00:47:57,320 --> 00:48:01,490
해시 키 간의 관계
및 범위 키가 많은 하나입니다.

1108
00:48:01,490 --> 00:48:03,490
나는 여러 해시 키를 가질 수 있습니다.

1109
00:48:03,490 --> 00:48:07,610
난 단지 여러 범위를 가질 수있다
모든 해시 키 내에서 키.

1110
00:48:07,610 --> 00:48:11,910
>> 해시는 부모를 정의,
범위는 어린이를 정의합니다.

1111
00:48:11,910 --> 00:48:15,240
그래서 당신이 볼 수있는 아날로그는 여기에있다
관계형 구조 사이

1112
00:48:15,240 --> 00:48:18,840
및 동일한 유형
NoSQL에에 구성한다.

1113
00:48:18,840 --> 00:48:20,760
사람들은 이야기
비 관계형으로 NoSQL에.

1114
00:48:20,760 --> 00:48:22,200
그것은 비 관계형 아니다.

1115
00:48:22,200 --> 00:48:24,680
데이터는 항상 관계를 맺고있다.

1116
00:48:24,680 --> 00:48:28,172
그 관계 단지
다른 모델링된다.

1117
00:48:28,172 --> 00:48:29,880
의 조금 얘기하자
내구성에 대한 비트.

1118
00:48:29,880 --> 00:48:34,860
당신이 DynamoDB의에 쓸 때, 기록
항상 세 방향 복제됩니다.

1119
00:48:34,860 --> 00:48:37,550
우리는 세 개의 알파벳 순의가 있음을 의미한다.

1120
00:48:37,550 --> 00:48:39,160
AZ의 가용성 영역입니다.

1121
00:48:39,160 --> 00:48:43,430
당신은 가용성 생각할 수
데이터 센터로서 존

1122
00:48:43,430 --> 00:48:45,447
데이터 센터 또는 모음.

1123
00:48:45,447 --> 00:48:47,780
이런 일들은 지리적으로 있습니다
서로 분리

1124
00:48:47,780 --> 00:48:51,610
다른 장애 영역에 걸쳐 가로 질러
전력망과 범람원 다른.

1125
00:48:51,610 --> 00:48:54,510
하나 AZ의 실패는 아니다
다른를 걸릴 것.

1126
00:48:54,510 --> 00:48:56,890
또한 연결되어
함께 다크 파이버와.

1127
00:48:56,890 --> 00:49:01,240
그것은 하나의 서브 지원 1
AZS 사이의 밀리 초 대기 시간.

1128
00:49:01,240 --> 00:49:05,390
따라서 실시간 데이터 복제
멀티 AZS에서 할 수.

1129
00:49:05,390 --> 00:49:09,990
>> 그리고 자주 다중 AZ 배포
고 가용성 요구 사항을 충족

1130
00:49:09,990 --> 00:49:12,930
대부분의 기업 조직의.

1131
00:49:12,930 --> 00:49:16,139
그래서 DynamoDB의 확산된다
기본적으로 세 가지 AZS에서.

1132
00:49:16,139 --> 00:49:19,430
우리는 지식 쓰기에가는거야
그 세 개의 노드의 두 돌아올 때

1133
00:49:19,430 --> 00:49:21,470
내가 그것을 가지고, 그래, 말한다.

1134
00:49:21,470 --> 00:49:22,050
그 이유는 무엇입니까?

1135
00:49:22,050 --> 00:49:25,950
읽기 측에 우리가이기 때문에 단지
때 다시 당신에게 데이터를 제공하는 것

1136
00:49:25,950 --> 00:49:27,570
우리는 두 개의 노드에서 그것을 얻을.

1137
00:49:27,570 --> 00:49:30,490
>> 나는 걸쳐 복제하고있어 경우
세, 나는 두에서 읽고 있어요,

1138
00:49:30,490 --> 00:49:32,840
나는 항상 보장 해요
적어도 하나를 갖도록

1139
00:49:32,840 --> 00:49:35,720
그은을로 읽는의
데이터의 최신 사본.

1140
00:49:35,720 --> 00:49:38,340
즉 DynamoDB의 일관성을 만드는거야.

1141
00:49:38,340 --> 00:49:42,450
이제 설정을 선택할 수 있습니다
그 일관성이 꺼 읽습니다.

1142
00:49:42,450 --> 00:49:45,070
이 경우 내가 말할거야,
나는 단지 하나의 노드에서 읽을 수 있습니다.

1143
00:49:45,070 --> 00:49:47,430
그리고 나는거야 보장 할 수 없습니다
가장 최근의 데이터가 될 수 있습니다.

1144
00:49:47,430 --> 00:49:49,450
>> 쓰기에오고 있다면,
그것은 아직 복제되지 않은

1145
00:49:49,450 --> 00:49:50,360
당신은 그 사본을 얻을 것입니다.

1146
00:49:50,360 --> 00:49:52,220
즉, 결국 일관된 읽기입니다.

1147
00:49:52,220 --> 00:49:54,640
그리고 무엇 즉 것은 절반의 비용입니다.

1148
00:49:54,640 --> 00:49:56,140
그래서이 생각하는 무언가이다.

1149
00:49:56,140 --> 00:50:00,160
언제 DynamoDB의를 판독하고있어
당신은 당신의 읽기 능력을 설정하는

1150
00:50:00,160 --> 00:50:04,430
단위는, 당신은 결국 선택하는 경우
일관성, 그것은 훨씬 저렴 읽기

1151
00:50:04,430 --> 00:50:06,010
그것은 약 절반의 비용입니다.

1152
00:50:06,010 --> 00:50:09,342
>> 그리고 그것은 당신이 돈을 절약 할 수 있습니다.

1153
00:50:09,342 --> 00:50:10,300
그러나 그것은 당신의 선택이다.

1154
00:50:10,300 --> 00:50:12,925
일관된 읽기를 원하는 경우 또는
결국 일관된 읽기.

1155
00:50:12,925 --> 00:50:15,720
그것은 당신이 선택할 수있는 일입니다.

1156
00:50:15,720 --> 00:50:17,659
>> 의 인덱스에 대해 얘기하자.

1157
00:50:17,659 --> 00:50:19,450
그래서 우리는 언급
최고 수준의 통합.

1158
00:50:19,450 --> 00:50:23,720
우리는 해시 키를 얻고, 한
우리는 범위 키를 가지고있다.

1159
00:50:23,720 --> 00:50:24,320
그건 좋은 데요.

1160
00:50:24,320 --> 00:50:26,950
그리고는, 기본 테이블에의 I
하나의 해시 키를 가지고, 나는 1 범위 키를 얻었다.

1161
00:50:26,950 --> 00:50:27,783
>> 그게 무슨 뜻 이죠?

1162
00:50:27,783 --> 00:50:30,410
나는 하나의 속성을 가지고 그 나는
에 대한 풍부한 쿼리를 실행할 수 있습니다.

1163
00:50:30,410 --> 00:50:31,800
그것은 범위 키입니다.

1164
00:50:31,800 --> 00:50:35,530
그 item--에 다른 속성
나는 그 속성을 필터링 할 수 있습니다.

1165
00:50:35,530 --> 00:50:40,050
하지만, 그것을 일을 같이 할 수 없어
로 시작하거나보다 크다.

1166
00:50:40,050 --> 00:50:40,820
>> 나는 어떻게해야합니까?

1167
00:50:40,820 --> 00:50:42,860
나는 인덱스를 만들 수 있습니다.

1168
00:50:42,860 --> 00:50:45,340
두 가지 유형의
DynamoDB의에서 인덱스.

1169
00:50:45,340 --> 00:50:49,002
인덱스는 정말
테이블의 다른보기.

1170
00:50:49,002 --> 00:50:50,490
그리고 로컬 보조 인덱스.

1171
00:50:50,490 --> 00:50:51,781
>> 우리가 얘기하자 첫 번째.

1172
00:50:51,781 --> 00:50:57,740
그래서 지역의 보조가 공존
데이터와 동일한 파티션.

1173
00:50:57,740 --> 00:51:00,240
등과 같은, 그들에 아르
동일한 물리적 노드입니다.

1174
00:51:00,240 --> 00:51:01,780
그들은 우리가 일관 부르는 있습니다.

1175
00:51:01,780 --> 00:51:04,599
의미, 그들은 인정합니다
테이블과 함께 쓰기.

1176
00:51:04,599 --> 00:51:06,890
기록이 들어 오면,
우리는 색인을 통해 쓸 것이다.

1177
00:51:06,890 --> 00:51:09,306
우리는 테이블에 쓸 수 있습니다
그리고, 우리는 인정한다.

1178
00:51:09,306 --> 00:51:10,490
그래서 일관성이다.

1179
00:51:10,490 --> 00:51:13,174
쓰기되면
테이블에서 인정

1180
00:51:13,174 --> 00:51:15,090
그것은 보장이야
로컬 보조 인덱스

1181
00:51:15,090 --> 00:51:18,380
데이터의 동일한 시야를 가질 것이다.

1182
00:51:18,380 --> 00:51:22,390
하지만 그들이 할 수 당신이 할 것은
대체 범위 키를 정의합니다.

1183
00:51:22,390 --> 00:51:25,260
>> 동일한 해시를 사용해야합니다
기본 테이블로 키,

1184
00:51:25,260 --> 00:51:29,050
그들이 있기 때문에에 함께 배치
같은 파티션, 그들은 일관성입니다.

1185
00:51:29,050 --> 00:51:33,110
하지만 인덱스를 만들 수 있습니다
다른 범위 키.

1186
00:51:33,110 --> 00:51:41,590
그래서 예를 들어,에게 나는 제조업체를했다
즉 원시 부품 테이블이오고 있었다.

1187
00:51:41,590 --> 00:51:44,590
그리고 원시 부분에오고,
그들은 조립하여 집계하고 있습니다.

1188
00:51:44,590 --> 00:51:46,840
그리고 어쩌면 리콜있다.

1189
00:51:46,840 --> 00:51:50,240
>> 이에 의해 만들어진 모든 부분
이 날짜 이후 제조 업체,

1190
00:51:50,240 --> 00:51:52,840
내 선에서 당겨해야합니다.

1191
00:51:52,840 --> 00:51:55,950
나는 인덱스를 회전 할 수 있습니다
즉,보고 할 것

1192
00:51:55,950 --> 00:52:00,760
일에 집계
특정 부품의 제조.

1193
00:52:00,760 --> 00:52:03,930
내 최고 수준의 테이블이 있다면 그래서
이미 제조 업체에서 해시,

1194
00:52:03,930 --> 00:52:07,655
어쩌면 그것은 내가, 부품 ID에 배치되었다
해당 테이블 오프 인덱스를 만들 수 있습니다

1195
00:52:07,655 --> 00:52:11,140
제조업체에서 해시로 및
제조 날짜였다.

1196
00:52:11,140 --> 00:52:14,490
그리고 내가 말할 수있는 방법, 아무것도 그
이 날짜 사이에 제조 된,

1197
00:52:14,490 --> 00:52:16,804
나는 선에서 당겨해야합니다.

1198
00:52:16,804 --> 00:52:18,220
그래서 로컬 보조 인덱스입니다.

1199
00:52:18,220 --> 00:52:22,280
>> 이들의 효과를 가질
당신의 해시 키 공간을 제한.

1200
00:52:22,280 --> 00:52:24,360
그들이 있기 때문에 공존
동일한 스토리지 노드,

1201
00:52:24,360 --> 00:52:26,860
이들은 해시 키를 제한
10기가바이트에 공간.

1202
00:52:26,860 --> 00:52:28,950
DynamoDB의, 아래
테이블은 파티셔닝

1203
00:52:28,950 --> 00:52:31,380
테이블마다 10기가바이트.

1204
00:52:31,380 --> 00:52:34,760
당신은 데이터의 10 기가에 넣을 때, 우리
[PHH]을 가고, 우리는 또 다른 노드를 추가 할 수 있습니다.

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

1206
00:52:38,120 --> 00:52:42,070
>> 우리는 LSI를 분할하지 않습니다
여러 파티션에서.

1207
00:52:42,070 --> 00:52:43,200
우리는 테이블을 분할합니다.

1208
00:52:43,200 --> 00:52:44,679
그러나 우리는 LSI를 분할하지 않습니다.

1209
00:52:44,679 --> 00:52:46,470
그 뭔가 그래서
이해하는 것이 중요합니다

1210
00:52:46,470 --> 00:52:50,070
당신은 매우 일을하는 경우입니다,
매우, 매우 큰 집계,

1211
00:52:50,070 --> 00:52:53,860
당신은 제한 될거야
당신의 LSI에 10 기가 바이트.

1212
00:52:53,860 --> 00:52:56,640
>> 그 경우, 우리는 할 수
글로벌 보조를 사용합니다.

1213
00:52:56,640 --> 00:52:58,630
글로벌 보조은
정말 다른 테이블.

1214
00:52:58,630 --> 00:53:01,720
그들은에 떨어져 완전히 존재
기본 테이블의 측면.

1215
00:53:01,720 --> 00:53:04,680
그리고 그들은 저를 찾을 수
완전히 다른 구조.

1216
00:53:04,680 --> 00:53:08,010
데이터가 삽입되고 그래서 그것을 생각
두 개의 서로 다른 테이블로, 구조화

1217
00:53:08,010 --> 00:53:09,220
두 가지 방법으로.

1218
00:53:09,220 --> 00:53:11,360
>> 나는 완전히를 정의 할 수 있습니다
다른 해시 키.

1219
00:53:11,360 --> 00:53:13,490
나는 완전히를 정의 할 수 있습니다
다른 범위의 키.

1220
00:53:13,490 --> 00:53:15,941
그리고 나는 이것을 실행할 수 있습니다
완전히 독립적으로.

1221
00:53:15,941 --> 00:53:18,190
사실, 나는했습니다
내 읽기 능력을 프로비저닝

1222
00:53:18,190 --> 00:53:21,090
및 용량을 쓰기 내
글로벌 보조 인덱스

1223
00:53:21,090 --> 00:53:24,240
완전히 독립적으로
내 기본 테이블.

1224
00:53:24,240 --> 00:53:26,640
내가 그 인덱스를 정의하면, 알
그것은 얼마나 많은 읽기 및 쓰기

1225
00:53:26,640 --> 00:53:28,610
용량은 사용하는 것입니다.

1226
00:53:28,610 --> 00:53:31,490
>> 그리고는 별도입니다
내 기본 테이블에서.

1227
00:53:31,490 --> 00:53:35,240
이제 인덱스 모두에 우리를 수
뿐만 아니라, 해시 및 범위 키를 정의

1228
00:53:35,240 --> 00:53:38,610
그러나 그들은 우리를 수
값을 추가로 예상된다.

1229
00:53:38,610 --> 00:53:44,950
내가 인덱스를 읽어들이는 경우 그래서,
나는 일부 데이터 세트를 얻으려면,

1230
00:53:44,950 --> 00:53:48,327
나는 주에 다시 갈 필요가 없습니다
표는 추가 속성을 얻을 수 있습니다.

1231
00:53:48,327 --> 00:53:50,660
나는 그 추가를 투사 할 수 있습니다
테이블에 속성

1232
00:53:50,660 --> 00:53:53,440
액세스 패턴을 지원합니다.

1233
00:53:53,440 --> 00:53:57,700
나는 우리가 아마 들어갈 거 알아
정말, 잡초로 점점 really--

1234
00:53:57,700 --> 00:53:58,910
여기에이 물건의 일부에.

1235
00:53:58,910 --> 00:54:02,725
지금은이 밖으로 표류하게되었다.

1236
00:54:02,725 --> 00:54:07,320
>> 청중 : [들리지]
--table 키 해시는 것을 의미했다?

1237
00:54:07,320 --> 00:54:08,840
원래 해시?

1238
00:54:08,840 --> 00:54:09,340
멀티 칸막이?

1239
00:54:09,340 --> 00:54:10,200
>> 릭 리한 (Houlihan) : 예.

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

1241
00:54:11,070 --> 00:54:15,260
테이블 키 기본적으로
다시 항목을 가리 킵니다.

1242
00:54:15,260 --> 00:54:19,280
그래서 인덱스는 포인터로 돌아
테이블에 원래 항목.

1243
00:54:19,280 --> 00:54:22,910
지금 당신을 구축하도록 선택할 수 있습니다
단지 테이블 키가 인덱스

1244
00:54:22,910 --> 00:54:24,840
및 다른 속성.

1245
00:54:24,840 --> 00:54:26,570
그리고 나는 그 이유를 할 수 있는가?

1246
00:54:26,570 --> 00:54:28,570
글쎄, 어쩌면 내가 매우 큰 항목이 있습니다.

1247
00:54:28,570 --> 00:54:31,660
>> 정말 만 알 필요가 which--
내 액세스 패턴은 말할 수

1248
00:54:31,660 --> 00:54:33,760
어떤 항목이 속성을 포함?

1249
00:54:33,760 --> 00:54:35,780
항목을 반환 할 필요가 없습니다.

1250
00:54:35,780 --> 00:54:37,800
난 그냥 알아야
어떤 항목이 포함되어 있습니다.

1251
00:54:37,800 --> 00:54:40,700
그래서 당신은 인덱스를 구축 할 수 있습니다
만 테이블 키가 있습니다.

1252
00:54:40,700 --> 00:54:43,360
>> 하지만 주로 무엇을의
데이터베이스의 인덱스입니다.

1253
00:54:43,360 --> 00:54:46,280
그것은 신속하게 할 수있는 대한의
, 레코드를 식별

1254
00:54:46,280 --> 00:54:49,470
행을, 어떤
테이블의 항목이

1255
00:54:49,470 --> 00:54:51,080
내가 찾고 있어요 속성.

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

1257
00:54:53,610 --> 00:54:54,860
>> 국제 대학원, 그래서 그들은 어떻게 작동합니까?

1258
00:54:54,860 --> 00:54:58,340
국제 대학원은 기본적으로 비동기.

1259
00:54:58,340 --> 00:55:02,570
이 업데이트는 테이블에 온다,
테이블은 비동기 적으로 업데이트됩니다

1260
00:55:02,570 --> 00:55:03,720
당신의 국제 대학원의 모든.

1261
00:55:03,720 --> 00:55:06,680
국제 대학원은 이유입니다
결국 일관성.

1262
00:55:06,680 --> 00:55:09,440
>> 이 점에 유의하는 것이 중요하다
때 국제 대학원을 구축하고,

1263
00:55:09,440 --> 00:55:13,110
당신은 당신이 만드는 이해
aggregation--의 또 다른 차원

1264
00:55:13,110 --> 00:55:16,594
지금의 좋은 예를 가정 해 봅시다
여기에 제조 업체입니다.

1265
00:55:16,594 --> 00:55:19,260
내가 이야기 한 것 같아요
의료 기기 제조업체.

1266
00:55:19,260 --> 00:55:23,870
의료 기기 제조업체
자주 직렬화 된 부분이있다.

1267
00:55:23,870 --> 00:55:28,070
에 들어갈 부품
고관절 교체 모든

1268
00:55:28,070 --> 00:55:30,200
그들에 약간의 일련 번호를 가지고있다.

1269
00:55:30,200 --> 00:55:33,584
그리고 그들은 수백만을 가질 수 및
수백만 및 부품 수십억

1270
00:55:33,584 --> 00:55:35,000
그들이 제공하는 모든 장치에서.

1271
00:55:35,000 --> 00:55:37,440
글쎄, 그들은에서 집계 할 필요가
다른 치수, 모든 부품

1272
00:55:37,440 --> 00:55:39,520
어셈블리의 모든
만들어진 부품

1273
00:55:39,520 --> 00:55:41,670
특정 라인에, 모든
제공된 부품

1274
00:55:41,670 --> 00:55:44,620
특정 제조업체에
특정 날짜에.

1275
00:55:44,620 --> 00:55:47,940
때때로 그리고이 집계
수십억에 일어나.

1276
00:55:47,940 --> 00:55:50,550
>> 그래서 몇 가지 작업
고통이 녀석

1277
00:55:50,550 --> 00:55:53,156
그들이 만드는 때문에
이 ginormous 한 집계

1278
00:55:53,156 --> 00:55:54,280
자신의 보조 인덱스에서.

1279
00:55:54,280 --> 00:55:57,070
그들은 원시 부분이있을 수 있습니다
만 해시로 제공 테이블.

1280
00:55:57,070 --> 00:55:59,090
각 부분은 고유 한 일련 번호가 있습니다.

1281
00:55:59,090 --> 00:56:00,975
나는 해시로 일련 번호를 사용합니다.

1282
00:56:00,975 --> 00:56:01,600
그것은 아름답다.

1283
00:56:01,600 --> 00:56:04,160
내 원 데이터 테이블 퍼진다
모든 주요 공간에서.

1284
00:56:04,160 --> 00:56:05,930
나의 [? 쓰다 ?]
[? 섭취는?] 굉장합니다.

1285
00:56:05,930 --> 00:56:07,876
I는 많은 데이터를 가지고.

1286
00:56:07,876 --> 00:56:09,500
그런 다음 그들이 그들이 GSI를 만들 수 있습니다.

1287
00:56:09,500 --> 00:56:12,666
그리고 내가 볼 필요가, 당신은 무엇을 알고, 말
이 제조업체에 대한 모든 부분.

1288
00:56:12,666 --> 00:56:15,060
그런데, 갑자기 내가 해요
억 행을 복용,

1289
00:56:15,060 --> 00:56:17,550
과에 그들을 물건
하나의 노드, 때 때문에

1290
00:56:17,550 --> 00:56:21,170
나는로 집계
해시 등의 제조 업체 ID,

1291
00:56:21,170 --> 00:56:25,410
및 범위 등의 부품 번호,
그때 난 갑자기

1292
00:56:25,410 --> 00:56:30,530
에 억 부분을 넣어 무엇을
이 업체는 나에게 전달하고있다.

1293
00:56:30,530 --> 00:56:34,447
>> 즉 많이 발생할 수 있습니다
GSI에 압력,

1294
00:56:34,447 --> 00:56:36,030
다시, 나는 하나의 노드를 망치 야하기 때문이다.

1295
00:56:36,030 --> 00:56:38,350
나는 모든이를 걸었습니다
하나의 노드에 삽입합니다.

1296
00:56:38,350 --> 00:56:40,940
그리고 진짜 문제가 유스 케이스입니다.

1297
00:56:40,940 --> 00:56:43,479
지금, 나는 좋은 디자인을 가지고
당신이를 방지하는 방법에 대 한 패턴입니다.

1298
00:56:43,479 --> 00:56:45,770
그리고 그 문제 중 하나
나는 항상 작동있다.

1299
00:56:45,770 --> 00:56:49,590
무슨 일하지만, GSI는 할 수있다
충분한 기록 용량을 가지고 있지

1300
00:56:49,590 --> 00:56:52,330
모든 사람을 밀어 수 있도록
단일 노드에 행.

1301
00:56:52,330 --> 00:56:55,390
그리고 무엇 다음 발생하는 것은
일차, 클라이언트 테이블

1302
00:56:55,390 --> 00:57:00,180
기본 테이블이 조절됩니다
GSI는 유지할 수 없기 때문에.

1303
00:57:00,180 --> 00:57:02,980
그래서 내 삽입 속도는 것
기본 테이블에가

1304
00:57:02,980 --> 00:57:06,230
내 GSI는 계속 시도로.

1305
00:57:06,230 --> 00:57:08,850
>> 좋아, LSI의, GSI의 때문에,
나는 어느 하나를 사용해야합니까?

1306
00:57:08,850 --> 00:57:12,290
LSI의는 일치한다.

1307
00:57:12,290 --> 00:57:13,750
GSI의 결국 일치한다.

1308
00:57:13,750 --> 00:57:17,490
그 괜찮아, 난을 사용하는 것이 좋습니다
GSI는 이들이 훨씬 더 유연한 것.

1309
00:57:17,490 --> 00:57:20,270
LSI의은 GSI 같이 모델링 될 수있다.

1310
00:57:20,270 --> 00:57:27,040
그리고 만약 해시 키 당 데이터 크기
컬렉션 10 기가 바이트 초과

1311
00:57:27,040 --> 00:57:31,050
당신은 것을 사용하려는거야
GSI 그냥 하드 제한 왜냐하면.

1312
00:57:31,050 --> 00:57:32,035
>> 좋아요, 스케일링.

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

1314
00:57:35,210 --> 00:57:37,460
디나모 DB에서 처리량, 당신
캔 제공 [들림]

1315
00:57:37,460 --> 00:57:38,680
테이블에 처리량.

1316
00:57:38,680 --> 00:57:42,740
우리는이 고객이
비전 60 billion--

1317
00:57:42,740 --> 00:57:45,970
정기적으로, 600 억 요청을하고있다
만 이상의 요청을 실행

1318
00:57:45,970 --> 00:57:47,790
우리의 테이블에 초.

1319
00:57:47,790 --> 00:57:50,360
아니 정말로있다
에 대한 이론적 인 한계 얼마나

1320
00:57:50,360 --> 00:57:53,730
그리고 얼마나 빨리 테이블
디나모 DB에 실행할 수 있습니다.

1321
00:57:53,730 --> 00:57:55,920
일부 부드러운 있습니다
귀하의 계정에 대한 제한

1322
00:57:55,920 --> 00:57:58,170
우리가 거​​기에 넣어 그
것을 당신은 미쳐하지 않습니다.

1323
00:57:58,170 --> 00:58:00,070
당신은 이상합니다
즉, 문제가되지 않는다.

1324
00:58:00,070 --> 00:58:00,820
당신은 우리에게 온다.

1325
00:58:00,820 --> 00:58:02,810
우리는 다이얼을 설정합니다.

1326
00:58:02,810 --> 00:58:08,210
>> 모든 계정은 일정 수준으로 제한된다
모든 서비스에 바로 박쥐

1327
00:58:08,210 --> 00:58:11,920
그래서 사람들은 미쳐하지 않습니다
곤경에 자신을 얻을.

1328
00:58:11,920 --> 00:58:12,840
크기에 제한 없음.

1329
00:58:12,840 --> 00:58:14,940
당신은 어떤 수를 넣을 수 있습니다
테이블의 항목.

1330
00:58:14,940 --> 00:58:17,620
아이템의 크기는
4백킬로바이트 각각 한정

1331
00:58:17,620 --> 00:58:20,050
그 항목이 아닌 속성이 될 것이다.

1332
00:58:20,050 --> 00:58:24,200
모든 속성의 합계 그래서
400킬로바이트로 제한됩니다.

1333
00:58:24,200 --> 00:58:27,300
그리고 다시, 우리가
그 작은 LSI 문제

1334
00:58:27,300 --> 00:58:30,405
해시 당 10 기가 바이트 한계.

1335
00:58:30,405 --> 00:58:33,280
청중 : 소수, 나는 실종 해요
무엇 당신은 나를 말하는 거 is--

1336
00:58:33,280 --> 00:58:36,830
청중 : 아, 4백킬로바이트
항목 당 최대 크기이다.

1337
00:58:36,830 --> 00:58:39,570
그래서 항목은 모든 특성을가집니다.

1338
00:58:39,570 --> 00:58:43,950
그래서 400 K는 전체 크기는
해당 항목의, 4백킬로바이트.

1339
00:58:43,950 --> 00:58:46,170
모든 속성의 그래서
결합 된 모든 데이터

1340
00:58:46,170 --> 00:58:49,140
그 모든 속성에있어,
전체 크기로 올리고,

1341
00:58:49,140 --> 00:58:51,140
오늘 현재 항목 제한은 400 K이다.

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

1343
00:58:54,390 --> 00:58:57,046
그래서 달성, 다시 확장
파티셔닝을 통해.

1344
00:58:57,046 --> 00:58:58,920
처리량 프로비저닝
테이블 수준에서.

1345
00:58:58,920 --> 00:59:00,160
정말 두 개의 손잡이가있다.

1346
00:59:00,160 --> 00:59:02,400
우리는 용량을 읽고
용량 물품.

1347
00:59:02,400 --> 00:59:05,530
>> 그래서 이러한 조정
서로 독립적.

1348
00:59:05,530 --> 00:59:08,640
RCU의 조치는 엄격하게 일관성을 읽습니다.

1349
00:59:08,640 --> 00:59:13,005
좋아, 그래서 만약 내가 1000을 원하는 말을하는지
RCU의 사람들은, 엄격하게 일치

1350
00:59:13,005 --> 00:59:14,130
사람들은 일관된 읽기입니다.

1351
00:59:14,130 --> 00:59:17,130
당신은 내가 원하는 말한다면
일관된 결국은 읽고

1352
00:59:17,130 --> 00:59:19,402
당신이 제공 할 수있는 1,000
RCU의, 당신은거야

1353
00:59:19,402 --> 00:59:21,840
결국 2,000을 얻을 수
일관성을 읽습니다.

1354
00:59:21,840 --> 00:59:25,940
그리고 그 절반 가격
결국에 읽기로 구성되어 있습니다.

1355
00:59:25,940 --> 00:59:28,520
>> 다시 말하지만, 조정
서로 독립적.

1356
00:59:28,520 --> 00:59:32,900
그리고 그들은 throughput--이
당신이 당신의 RCU의 100 %를 소비하는 경우,

1357
00:59:32,900 --> 00:59:35,960
당신은 영향을하지 않을거야
권리의 가용성.

1358
00:59:35,960 --> 00:59:40,161
그래서 그들은 완전히 있습니다
서로 독립적.

1359
00:59:40,161 --> 00:59:43,160
좋아, 그래서 것들 중 하나가
나는 간단히 조절 있다고 말했습니다.

1360
00:59:43,160 --> 00:59:44,320
스로틀은 나쁘다.

1361
00:59:44,320 --> 00:59:47,311
스로틀은 SQL을 나쁜 나타냅니다.

1362
00:59:47,311 --> 00:59:50,310
우리가 도울 수있는 일이있다
당신은 제한을 완화 당신을

1363
00:59:50,310 --> 00:59:51,040
경험하고 있습니다.

1364
00:59:51,040 --> 00:59:53,240
그러나 가장 좋은 방법
이것의가 보자입니다

1365
00:59:53,240 --> 00:59:58,000
때문에, 당신이 무슨 일을하는지 살펴
여기에 연극에서 반 패턴이있다.

1366
00:59:58,000 --> 01:00:02,140
>> 이러한 것들은, 비 균일 같은 것들
워크로드, 핫 키, 핫 파티션.

1367
01:00:02,140 --> 01:00:06,210
나는 특정 키 공간을 치는거야
열심히 어떤 특별한 이유.

1368
01:00:06,210 --> 01:00:07,080
내가 왜이 일을하고있다?

1369
01:00:07,080 --> 01:00:08,710
의 그 알아낼 수 있습니다.

1370
01:00:08,710 --> 01:00:10,427
나는 감기 데이터를 내 뜨거운 데이터를 혼합하고 있습니다.

1371
01:00:10,427 --> 01:00:12,510
나는 나의 표를 얻을시키는거야
거대한, 그러나 거기에 정말

1372
01:00:12,510 --> 01:00:15,970
데이터의 일부 서브 세트
그는 나에게 정말 흥미.

1373
01:00:15,970 --> 01:00:20,290
그래서의 로그 데이터를, 예를 들면, 많은
고객, 그들은 매일 로그 데이터를 얻을.

1374
01:00:20,290 --> 01:00:22,490
그들은 로그 데이터의 엄청난 금액을 얻었다.

1375
01:00:22,490 --> 01:00:25,940
>> 당신은 모든 로그를 덤프하는 경우
시간이 지남에 따라 하나의 큰 테이블에 데이터,

1376
01:00:25,940 --> 01:00:28,070
그 표는 대규모 얻을 것입니다.

1377
01:00:28,070 --> 01:00:30,950
하지만 난 정말에만 관심이 있어요
지난 24 시간, 지난 7 일

1378
01:00:30,950 --> 01:00:31,659
지난 30 일.

1379
01:00:31,659 --> 01:00:34,074
시간의 무엇이든간에 창
나는보고에 관심이 있음

1380
01:00:34,074 --> 01:00:37,010
날 귀찮게하거나 이벤트
나에게 흥미로운 이벤트,

1381
01:00:37,010 --> 01:00:39,540
그게 내가 필요한 유일한 창 시간이다.

1382
01:00:39,540 --> 01:00:42,470
그래서 왜 10 년을 걸었습니다
테이블에 로그 데이터의 가치?

1383
01:00:42,470 --> 01:00:45,030
무슨이 발생하는 것입니다
테이블 조각.

1384
01:00:45,030 --> 01:00:45,880
>> 그것은 거대한 가져옵니다.

1385
01:00:45,880 --> 01:00:48,340
그것은 밖으로 확산 시작
수천 개의 노드에서.

1386
01:00:48,340 --> 01:00:51,380
그리고 용량부터
당신은, 그래서 낮

1387
01:00:51,380 --> 01:00:54,090
실제로 각 제한 속도
그 각각의 노드 중 하나.

1388
01:00:54,090 --> 01:00:57,120
그럼 어떻게보고 시작하자
우리가 이상 해당 테이블을 롤백 할.

1389
01:00:57,120 --> 01:01:01,502
우리는 데이터 조금을 관리하는 방법
더 나은 이러한 문제를 방지 할 수 있습니다.

1390
01:01:01,502 --> 01:01:02,710
그리고 그 무엇처럼 보이나요?

1391
01:01:02,710 --> 01:01:04,370
이 그 모습이다.

1392
01:01:04,370 --> 01:01:06,790
이것은 나쁜 NoSQL에의 모습입니다.

1393
01:01:06,790 --> 01:01:07,830
>> 여기 핫 키를 얻었다.

1394
01:01:07,830 --> 01:01:10,246
여기 측면에 보면,
이러한 내 모든 파티션입니다.

1395
01:01:10,246 --> 01:01:12,630
여기 16 파티션을 가지고
이 특정 데이터베이스에.

1396
01:01:12,630 --> 01:01:13,630
우리는이 모든 시간을.

1397
01:01:13,630 --> 01:01:15,046
나는 고객을 위해 모든 시간을이 작업을 실행합니다.

1398
01:01:15,046 --> 01:01:16,550
그것은 열지도라고.

1399
01:01:16,550 --> 01:01:20,590
열지도 당신이있어 어떻게 나에게 말한다
키 공간에 접근.

1400
01:01:20,590 --> 01:01:23,700
그리고 이것이 나에게 말하고 것은
하나의 특정 해시가 있음

1401
01:01:23,700 --> 01:01:26,330
이 사람을 좋아하는
엄청 많이, 그 때문에

1402
01:01:26,330 --> 01:01:28,250
정말 열심히, 정말 타격.

1403
01:01:28,250 --> 01:01:29,260
>> 그래서 파란색 좋은 것입니다.

1404
01:01:29,260 --> 01:01:29,900
우리는 푸른 좋아한다.

1405
01:01:29,900 --> 01:01:30,720
우리는 붉은 좋아하지 않는다.

1406
01:01:30,720 --> 01:01:33,120
레드의 경우 압력
100 %까지 가져옵니다.

1407
01:01:33,120 --> 01:01:35,560
100 %가, 지금은 스로틀 될 것입니다.

1408
01:01:35,560 --> 01:01:39,030
그래서 당신은 같은 어떤 빨간색 선을 볼 때마다
이 항아리와 단지 디나모 DB-- 아니다

1409
01:01:39,030 --> 01:01:41,630
모든 NoSQL에 데이터베이스가이 문제를 가지고있다.

1410
01:01:41,630 --> 01:01:44,640
안티 패턴은 할 수있다
조건 이러한 유형의 드라이브.

1411
01:01:44,640 --> 01:01:49,070
내가하는 일은 내가 고객과 함께 작업입니다
이러한 조건을 완화합니다.

1412
01:01:49,070 --> 01:01:51,840
>> 그리고 그 무엇처럼 보이나요?

1413
01:01:51,840 --> 01:01:54,260
그리고 이것은 가장을 받고있다
디나모 DB 처리량 중,

1414
01:01:54,260 --> 01:01:56,176
하지만 정말 점점
NoSQL에 최대한.

1415
01:01:56,176 --> 01:01:58,740
이것은 디나모에 제한되지 않는다.

1416
01:01:58,740 --> 01:02:02,050
이 definitely-- 내가있다
몽고에서 일을하는 데 사용됩니다.

1417
01:02:02,050 --> 01:02:04,090
나는 많은 NoSQL에 플랫폼에 익숙 해요.

1418
01:02:04,090 --> 01:02:06,830
모든 사람은 이러한 유형이 있습니다
핫 키 문제.

1419
01:02:06,830 --> 01:02:10,320
어떤 NoSQL에 최대한 활용하려면
데이터베이스, 특히 디나모 DB,

1420
01:02:10,320 --> 01:02:13,320
당신은 테이블을 만들려면
여기서 해시 키 요소 갖는다

1421
01:02:13,320 --> 01:02:18,590
고유 값 다수
기수의 높은 수준.

1422
01:02:18,590 --> 01:02:22,530
그게 내가 쓰고 있어요 의미하기 때문에
다른 버킷을 많이합니다.

1423
01:02:22,530 --> 01:02:24,870
>> 난 더 버킷
, 가능성에 쓰기

1424
01:02:24,870 --> 01:02:29,100
나는 그 쓰기로드를 분산하기 위해 오전 또는
여러 노드에 걸쳐로드 읽기,

1425
01:02:29,100 --> 01:02:33,560
가능성이 난을 가지고입니다
테이블에 높은 처리량.

1426
01:02:33,560 --> 01:02:37,440
그리고 나는 값이 원하는
시간이 지남에 따라 상당히 고르게 요청

1427
01:02:37,440 --> 01:02:39,430
균일하게 무작위로 가능.

1428
01:02:39,430 --> 01:02:42,410
글쎄, 그건, 가지 흥미로운
때문에 내가 할 수없는 정말

1429
01:02:42,410 --> 01:02:43,960
제어 사용자가 올 때.

1430
01:02:43,960 --> 01:02:47,645
우리가 퍼져 있다면, 말을 충분
키 공간에서 일 밖으로,

1431
01:02:47,645 --> 01:02:49,270
우리는 아마 더 나은 모양에있을 것이다.

1432
01:02:49,270 --> 01:02:51,522
>> 어떤이있다
시간 배달의 양

1433
01:02:51,522 --> 01:02:53,230
당신은하지 않을거야 것을
수 제어 할 수 있습니다.

1434
01:02:53,230 --> 01:02:55,438
하지만 그 정말입니다
우리는이 두 가지 차원,

1435
01:02:55,438 --> 01:02:58,800
공간, 액세스 균일
확산, 시간, 요청

1436
01:02:58,800 --> 01:03:01,040
균등하게 시간 간격으로 도착.

1437
01:03:01,040 --> 01:03:03,110
그리고 그 두 가지 경우
조건이 충족되고,

1438
01:03:03,110 --> 01:03:05,610
그 다음은 무엇입니다
처럼 보이는 것.

1439
01:03:05,610 --> 01:03:07,890
이 훨씬 좋네요.

1440
01:03:07,890 --> 01:03:08,890
우리는 여기에 정말 행복합니다.

1441
01:03:08,890 --> 01:03:10,432
우리는 매우에도 액세스 패턴을 가지고있다.

1442
01:03:10,432 --> 01:03:13,098
그래, 어쩌면 당신이 있어요
작은 압력 이제 다음 각,

1443
01:03:13,098 --> 01:03:14,830
하지만 아무것도 정말 너무 광범위한.

1444
01:03:14,830 --> 01:03:17,660
그래서, 몇 번 놀라운
나는 고객과 작업 할 때,

1445
01:03:17,660 --> 01:03:20,670
큰 빨간 첫 번째 그래프
바, 모든 즉, 노란색의 추한

1446
01:03:20,670 --> 01:03:23,147
도처에, 우리
운동으로 완수

1447
01:03:23,147 --> 01:03:24,980
몇 달 후
재 건축,

1448
01:03:24,980 --> 01:03:28,050
그들은 동일한를 실행하는
동일한 부하에서 부하.

1449
01:03:28,050 --> 01:03:30,140
그리고 이것은 지금처럼 찾고 것입니다.

1450
01:03:30,140 --> 01:03:36,600
그래서 당신은 NoSQL에 함께 얻을 것은
절대적 데이터 스키마

1451
01:03:36,600 --> 01:03:38,510
액세스 패턴에 묶여.

1452
01:03:38,510 --> 01:03:42,170
>> 그리고 당신은 그 데이터 스키마를 최적화 할 수 있습니다
그 액세스 패턴을 지원합니다.

1453
01:03:42,170 --> 01:03:45,490
그렇지 않으면, 당신은거야
이런 종류의 문제를 볼 수 있습니다

1454
01:03:45,490 --> 01:03:46,710
그 뜨거운 키.

1455
01:03:46,710 --> 01:03:50,518
>> 청중 : 음, 불가피하게 일부 지역
다른 사람보다 더 뜨거운 될 것입니다.

1456
01:03:50,518 --> 01:03:51,450
>> 릭 리한 (Houlihan) : 항상.

1457
01:03:51,450 --> 01:03:51,960
항상.

1458
01:03:51,960 --> 01:03:54,620
그래, 난 항상 거기에 의미
그럼하지 머 다시, 거기에

1459
01:03:54,620 --> 01:03:56,980
어떤 디자인 패턴은 우리를 통해 얻을 것이다
즉, 처리 방법에 대해 이야기합니다

1460
01:03:56,980 --> 01:03:58,480
이러한 초대형 집계와.

1461
01:03:58,480 --> 01:04:01,260
내 말은, 나는 그들을 가지고있어
우리는 그들과 함께 어떻게 처리합니까?

1462
01:04:01,260 --> 01:04:03,760
나는 꽤 좋은 유스 케이스를 가지고
우리는 그것에 대해 이야기거야.

1463
01:04:03,760 --> 01:04:05,940
>> 좋아, 그렇게하자의 이야기
지금에 대한 일부 고객.

1464
01:04:05,940 --> 01:04:06,950
이 녀석은 AdRoll 있습니다.

1465
01:04:06,950 --> 01:04:08,990
당신이 있다면 나도 몰라
AdRoll을 잘 알고.

1466
01:04:08,990 --> 01:04:10,781
당신은 아마 그들을 볼
브라우저에 많은.

1467
01:04:10,781 --> 01:04:14,230
그들은있어, 광고 재 타겟팅
가장 큰 광고 재 대상 사업

1468
01:04:14,230 --> 01:04:14,940
저 밖에.

1469
01:04:14,940 --> 01:04:17,792
그들은 일반적으로 정기적으로 이상 실행
하루에 600 억 거래.

1470
01:04:17,792 --> 01:04:20,000
그들은 백만 이상의 일을하는지
초당 트랜잭션.

1471
01:04:20,000 --> 01:04:22,660
그들은 아주 간단한 테이블을 가지고
구조, 가장 바쁜 테이블.

1472
01:04:22,660 --> 01:04:26,450
그것은 기본적으로 그냥
해시 키, 쿠키입니다

1473
01:04:26,450 --> 01:04:29,010
범위는 인구 통계 학적이다
카테고리 다음

1474
01:04:29,010 --> 01:04:31,220
세 번째 속성은 점수입니다.

1475
01:04:31,220 --> 01:04:33,720
>> 그래서 우리 모두는 쿠키를
이 사람들로부터 우리의 브라우저.

1476
01:04:33,720 --> 01:04:35,900
그리고 당신은에 갈 때
상인 참여,

1477
01:04:35,900 --> 01:04:39,390
그들은 기본적으로 가로 질러 당신 점수
다양한 인구 통계 학적 범주.

1478
01:04:39,390 --> 01:04:42,070
당신이 웹 사이트에 갈 때와
당신은 내가이 ad--를 참조하고 싶은 말은

1479
01:04:42,070 --> 01:04:44,920
또는 기본적으로 당신은 that--을 말하지 않는다
그러나 당신은 웹 사이트를 방문 할 때

1480
01:04:44,920 --> 01:04:47,550
그들은 당신이 광고를보고 싶지 말한다.

1481
01:04:47,550 --> 01:04:49,370
그리고 그들은 AdRoll에서 해당 광고를 가서.

1482
01:04:49,370 --> 01:04:51,130
AdRoll은 테이블에 당신을 보인다.

1483
01:04:51,130 --> 01:04:52,115
그들은 당신의 쿠키를 찾을 수 있습니다.

1484
01:04:52,115 --> 01:04:53,990
이야기 광고주
그들, 나는 누군가를 원한다

1485
01:04:53,990 --> 01:04:58,632
누가, 중년의
스포츠에 40 세의 남자.

1486
01:04:58,632 --> 01:05:01,590
그리고 그들은 그 인구 통계에 당신을 점수
이들은 여부를 결정

1487
01:05:01,590 --> 01:05:02,740
그것은 당신을 위해 좋은 광고입니다.

1488
01:05:02,740 --> 01:05:10,330
>> 이제 그들은 SLA와이
자신의 광고 제공

1489
01:05:10,330 --> 01:05:14,510
서브 10 밀리 초를 제공하는
모든 단일 요청에 응답.

1490
01:05:14,510 --> 01:05:16,090
그래서 그들은이에 대한 디나모 DB를 사용하고 있습니다.

1491
01:05:16,090 --> 01:05:18,131
그들은 우리를 타격하고
초당 만 요청.

1492
01:05:18,131 --> 01:05:21,120
그들은 모든 일을 할 수있어 자신의
조회, 환자 분류 모든 데이터,

1493
01:05:21,120 --> 01:05:26,130
그리고 다시 그 추가 링크를 얻을
10 밀리 초 아래에서 광고주.

1494
01:05:26,130 --> 01:05:29,800
정말 꽤 놀라운이다
구현 자신이 갖고있다.

1495
01:05:29,800 --> 01:05:36,210
>> 이 녀석은 ... 사실상
사람이 있습니다.

1496
01:05:36,210 --> 01:05:38,010
나는이 사람들을 만약 확실하지 않다.

1497
01:05:38,010 --> 01:05:40,127
이 녀석 될 수 있습니다.

1498
01:05:40,127 --> 01:05:42,210
기본적으로 나는, 아니 us-- 말했다
그것은 그들을 생각하지 않습니다.

1499
01:05:42,210 --> 01:05:43,000
나는 다른 사람 생각.

1500
01:05:43,000 --> 01:05:44,750
나는 함께 일하는
고객이 나에게 말했다 그

1501
01:05:44,750 --> 01:05:47,040
이제 그들은했는지
디나모 DB에 갔다, 그들이있어

1502
01:05:47,040 --> 01:05:50,330
간식에 더 많은 돈을 지출
자신의 개발 팀 매월

1503
01:05:50,330 --> 01:05:52,886
그들의 데이터베이스에 대한 지출보다.

1504
01:05:52,886 --> 01:05:54,760
그래서 당신에게 줄거야
비용 절감의 아이디어

1505
01:05:54,760 --> 01:05:57,889
당신은 디나모 DB에 얻을 수있는 것은 거대하다.

1506
01:05:57,889 --> 01:05:59,430
좋아, dropcam 다른 회사입니다.

1507
01:05:59,430 --> 01:06:02,138
이 사람은 종류의 동행입니다 당신이 생각하는 경우이다
사물의 인터넷, dropcam의

1508
01:06:02,138 --> 01:06:05,150
기본적으로 인터넷 보안 비디오이다.

1509
01:06:05,150 --> 01:06:06,660
당신은 거기에 카메라를 넣어.

1510
01:06:06,660 --> 01:06:08,180
카메라는 동작 감지기가 있습니다.

1511
01:06:08,180 --> 01:06:10,290
누군가가 따라 온다
큐 포인트를 트리거합니다.

1512
01:06:10,290 --> 01:06:13,540
카메라가 잠시까지 녹음을 시작합니다
그것은 더 이상 어떤 움직임을 감지하지 않습니다.

1513
01:06:13,540 --> 01:06:15,310
인터넷에 그 동영상을 넣습니다.

1514
01:06:15,310 --> 01:06:19,800
>> Dropcam는 기업이었다
기본적으로 디나모 DB로 전환

1515
01:06:19,800 --> 01:06:22,200
그들이 경험하고 있기 때문에
엄청난 성장통.

1516
01:06:22,200 --> 01:06:25,820
그리고 그들은 우리에게 무엇을,
갑자기 페타 바이트의 데이터.

1517
01:06:25,820 --> 01:06:28,070
그들은 아무 생각이 그들의 서비스를 없었다
그렇게 성공적이 될 것이다.

1518
01:06:28,070 --> 01:06:32,310
유튜브보다 인바운드 비디오
이 사람들이 점점 것입니다.

1519
01:06:32,310 --> 01:06:36,780
그들은 모두를 DynamoDB의 추적을 사용
모든 비디오 주요 지점에 메타 데이터.

1520
01:06:36,780 --> 01:06:40,282
>> 그래서 그들은 밀어 S3 버킷을
모든 이진 유물에.

1521
01:06:40,282 --> 01:06:41,990
그리고 그들은이
디나모 DB 기록 그

1522
01:06:41,990 --> 01:06:44,070
그 S3 세 개체에 사람을 가리 킵니다.

1523
01:06:44,070 --> 01:06:47,070
그들은 비디오를보고해야하는 경우,
그들은 디나모 DB에서 레코드를 찾습니다.

1524
01:06:47,070 --> 01:06:47,903
그들은 링크를 클릭합니다.

1525
01:06:47,903 --> 01:06:49,770
그들은 S3에서 비디오를 아래로 당깁니다.

1526
01:06:49,770 --> 01:06:51,590
그래서이 어떻게 생겼는지 가지입니다.

1527
01:06:51,590 --> 01:06:53,580
그리고 이것은 자신의 팀에서 직접입니다.

1528
01:06:53,580 --> 01:06:56,010
>> 디나모 DB는 감소
비디오 이벤트에 대한 배달 시간

1529
01:06:56,010 --> 01:06:57,590
5 ~ 10 초.

1530
01:06:57,590 --> 01:07:00,470
그들의 오래된 관계 상점에서,
그들은 가서 실행해야하는 데 사용

1531
01:07:00,470 --> 01:07:03,780
그림에 여러 복잡한 쿼리
알아 비디오는, 아래로 당겨

1532
01:07:03,780 --> 01:07:06,690
미만 50 밀리 초.

1533
01:07:06,690 --> 01:07:08,990
그래서 놀라운, 놀라운
얼마나 성능

1534
01:07:08,990 --> 01:07:12,990
당신이 최적화 할 때 당신이 얻을 수 있으며,
를 조정 기본 데이터베이스

1535
01:07:12,990 --> 01:07:15,110
액세스 패턴을 지원합니다.

1536
01:07:15,110 --> 01:07:20,500
그것을 무엇 Halfbrick,이 사람,
내가 추측 과일 닌자는 것입니다.

1537
01:07:20,500 --> 01:07:22,590
디나모 DB에있는 모든 실행되는지.

1538
01:07:22,590 --> 01:07:26,810
그리고이 사람들, 그들은 좋은
개발 팀, 큰 발전

1539
01:07:26,810 --> 01:07:27,670
가게.

1540
01:07:27,670 --> 01:07:29,364
>> 아니 좋은 작전 팀.

1541
01:07:29,364 --> 01:07:31,280
그들은 많이하지 않았다
연산 리소스.

1542
01:07:31,280 --> 01:07:33,940
그들은 유지하려고 애 쓰고 있었다
자신의 애플리케이션 인프라까지

1543
01:07:33,940 --> 01:07:34,290
실행.

1544
01:07:34,290 --> 01:07:35,000
그들은 우리에게왔다.

1545
01:07:35,000 --> 01:07:36,251
그들은 그 디나모 DB를 바라 보았다.

1546
01:07:36,251 --> 01:07:37,291
그들은 그것이 우리의 고 말했다.

1547
01:07:37,291 --> 01:07:39,470
그들은 전체를 구축
그것에 응용 프로그램 프레임 워크.

1548
01:07:39,470 --> 01:07:43,640
여기에 몇 가지 정말 좋은 코멘트
자신의 능력에 팀

1549
01:07:43,640 --> 01:07:46,800
지금 건물에 초점을
게임이 아닌

1550
01:07:46,800 --> 01:07:49,010
유지하는 데
인프라, 어떤

1551
01:07:49,010 --> 01:07:51,910
엄청난 양의되고 있었다
자신의 팀에 대한 오버 헤드.

1552
01:07:51,910 --> 01:07:56,170
그래서이 뭔가 that--
당신은 디나모 DB에서 얻을 혜택을 누릴 수 있습니다.

1553
01:07:56,170 --> 01:08:00,930
>> 좋아,에 점점
여기에 데이터 모델링.

1554
01:08:00,930 --> 01:08:03,440
그리고 우리에 대해 조금 이야기
하나이 하나, 많은 하나,

1555
01:08:03,440 --> 01:08:05,060
많은 유형의 관계에 많은.

1556
01:08:05,060 --> 01:08:07,630
그리고 당신은 어떻게 디나모 사람들을 유지 않습니다.

1557
01:08:07,630 --> 01:08:10,500
디나모 DB에서 우리는 사용
인덱스는, 일반적으로,

1558
01:08:10,500 --> 01:08:12,910
로부터 데이터를 회전
다른 하나의 맛.

1559
01:08:12,910 --> 01:08:15,210
해시 키, 범위 키 및 인덱스.

1560
01:08:15,210 --> 01:08:18,540
>> 이 특히
예를 들어, 대부분의 주와 같은

1561
01:08:18,540 --> 01:08:23,802
라이선스 요구 사항이 그
사람 당 하나의 운전 면허증.

1562
01:08:23,802 --> 01:08:26,510
두 드라이버의를 얻을 갈 수 없어
보스턴의 상태에 라이센스.

1563
01:08:26,510 --> 01:08:27,500
나는 텍사스에서 그것을 할 수 없습니다.

1564
01:08:27,500 --> 01:08:28,708
즉,이 방법 가지이다.

1565
01:08:28,708 --> 01:08:32,779
그래서 운전 면허 시험장에서, 우리는 조회를, 우리
운전 면허증을보고 싶다

1566
01:08:32,779 --> 01:08:35,180
사회 보장 번호.

1567
01:08:35,180 --> 01:08:39,990
나는 사용자 정보를 조회 할
운전 면허증 번호.

1568
01:08:39,990 --> 01:08:43,620
>> 그래서 우리는 사용자의 테이블이있을 수 있습니다 그
일련 번호는 해시 키가,

1569
01:08:43,620 --> 01:08:47,830
또는 사회 보장 번호,
다양한 속성은 항목을 정의했다.

1570
01:08:47,830 --> 01:08:49,859
이제 테이블 I에
GSI를 정의 할 수있는

1571
01:08:49,859 --> 01:08:53,370
그 말한다 주위에 내가 원하는 것을 뒤집
다음 라이센스 및에 해시 키

1572
01:08:53,370 --> 01:08:54,252
다른 모든 항목.

1573
01:08:54,252 --> 01:08:57,210
지금은 쿼리를 찾으려면
주어진 사회에 대한 라이센스 번호

1574
01:08:57,210 --> 01:08:59,609
보장 번호, 내가 할 수있는
기본 테이블을 쿼리합니다.

1575
01:08:59,609 --> 01:09:02,130
>> 나는 조회 할 내가 원하는 경우
사회 보장을받을

1576
01:09:02,130 --> 01:09:05,735
숫자 나에 의해 다른 속성
라이센스 번호, 나는 GSI를 조회 할 수 있습니다.

1577
01:09:05,735 --> 01:09:08,689
이 모델은 하나입니다
한 관계.

1578
01:09:08,689 --> 01:09:12,460
그냥 아주 간단한 GSI,
주위 상황을 뒤집습니다.

1579
01:09:12,460 --> 01:09:13,979
지금, 많은 약을 말한다.

1580
01:09:13,979 --> 01:09:16,450
많은에 하나는 기본적으로
당신의 해시 범위 키.

1581
01:09:16,450 --> 01:09:20,510
우리는이와 함께 많이 얻을 경우
사용 사례는 모니터 데이터입니다.

1582
01:09:20,510 --> 01:09:23,880
모니터 데이터는 정기적으로 제공
사물의 인터넷과 같은 간격.

1583
01:09:23,880 --> 01:09:26,890
우리는 항상 모든이를 얻을 수
기록은 모든 시간에 오는.

1584
01:09:26,890 --> 01:09:31,420
>> 그리고 나는 모든 측정 값을 찾으려면
특정 시간주기 사이.

1585
01:09:31,420 --> 01:09:34,220
그것은 매우 일반적인 질문입니다
모니터링 인프라.

1586
01:09:34,220 --> 01:09:38,430
그것에 대해 방법의 이동을 찾을 수 있습니다
간단한 테이블 구조, 하나의 테이블.

1587
01:09:38,430 --> 01:09:42,250
나는 장치 측정 테이블을 가지고
장치 ID에 해시 키.

1588
01:09:42,250 --> 01:09:47,340
그리고 난의 범위 키가
타임 스탬프, 또는이 경우, 서사시.

1589
01:09:47,340 --> 01:09:50,350
그리고 그 날은 복잡한 실행 허용
그 범위 키에 대한 쿼리

1590
01:09:50,350 --> 01:09:54,950
그 레코드를 반환하는
결과를 기준으로합니다

1591
01:09:54,950 --> 01:09:56,310
내가 찾는 것을 설정합니다.

1592
01:09:56,310 --> 01:09:58,360
그리고 그것은 하나를 구축
많은 관계

1593
01:09:58,360 --> 01:10:02,340
를 사용하여 기본 테이블에
해시 키, 범위 키 구조.

1594
01:10:02,340 --> 01:10:04,600
>> 그래서 종류의 내장 것
디나모 DB의 테이블에.

1595
01:10:04,600 --> 01:10:07,290
나는 해시를 정의 할 때
및 범위 T 테이블, 내가 해요

1596
01:10:07,290 --> 01:10:09,240
많은 관계를 형성 할 수있다.

1597
01:10:09,240 --> 01:10:12,770
그것은 부모 - 자식 관계이다.

1598
01:10:12,770 --> 01:10:14,620
>> 의 많은 대해 얘기하자
많은 관계.

1599
01:10:14,620 --> 01:10:19,170
이것은 특히 예를 들어,
다시, 우리는 GSI의를 사용하는 것입니다.

1600
01:10:19,170 --> 01:10:23,500
그리고의이 게임에 대해 이야기하자
나는 주어진 사용자가 시나리오.

1601
01:10:23,500 --> 01:10:26,500
나는 모든 게임을 찾을 수 원하는
그는 또는 재생 등록합니다.

1602
01:10:26,500 --> 01:10:29,600
그리고 주어진 게임, 내가
모든 사용자를 찾고 싶어요.

1603
01:10:29,600 --> 01:10:31,010
그래서 내가 어떻게 그렇게 할 수 있습니까?

1604
01:10:31,010 --> 01:10:34,330
내 사용자의 게임 테이블, 내가 갈거야
사용자 ID의 해시 키를 갖도록

1605
01:10:34,330 --> 01:10:35,810
게임의 범위 키.

1606
01:10:35,810 --> 01:10:37,810
>> 따라서 사용자는 여러 게임을 할 수 있습니다.

1607
01:10:37,810 --> 01:10:41,380
이 사이에 많은 관계로 하나
사용자와 그가 연주 게임.

1608
01:10:41,380 --> 01:10:43,410
그리고 GSI에,
그 주위 플립 것이다.

1609
01:10:43,410 --> 01:10:46,679
나는 게임에 해시 테니
나는 사용자에 다양합니다.

1610
01:10:46,679 --> 01:10:48,970
나는 모든을 얻고 싶은 경우에 따라서
게임 사용자는, 재생

1611
01:10:48,970 --> 01:10:49,950
나는 기본 테이블을 조회 할 수 있습니다.

1612
01:10:49,950 --> 01:10:52,699
나는 모든 사용자를 얻고 싶다면
즉, 특정 게임을하고,

1613
01:10:52,699 --> 01:10:53,887
나는 GSI를 쿼리합니다.

1614
01:10:53,887 --> 01:10:54,970
그래서 우리는이 작업을 수행하는 방법을 참조하십시오?

1615
01:10:54,970 --> 01:10:58,369
이러한 GSI는의를 지원하기 위해 구축
사용 사례, 응용 프로그램, 액세스

1616
01:10:58,369 --> 01:10:59,410
패턴, 애플리케이션.

1617
01:10:59,410 --> 01:11:01,440
>> 나는 쿼리를해야하는 경우
이 차원은하자

1618
01:11:01,440 --> 01:11:03,500
내게는 그 차원에 인덱스를 만들 수 있습니다.

1619
01:11:03,500 --> 01:11:05,850
내가하지 않으면, 난 상관 없어.

1620
01:11:05,850 --> 01:11:09,060
그리고 사용 사례에 따라, 나는
인덱스를 필요로하거나 그럴 수도 있습니다.

1621
01:11:09,060 --> 01:11:12,390
그것은 간단한 일이 많은이라면,
기본 테이블은 괜찮습니다.

1622
01:11:12,390 --> 01:11:15,860
나는 이러한 많은 작업을 수행해야하는 경우
많은의가, 또는 나는 것들 하나를 수행해야합니다

1623
01:11:15,860 --> 01:11:18,390
어쩌면 내가 필요합니까
두 번째 인덱스.

1624
01:11:18,390 --> 01:11:20,840
그래서 모두에 따라 달라집니다
난 할 노력하고있어

1625
01:11:20,840 --> 01:11:24,550
나는 달성 얻기 위해 노력하고있어.

1626
01:11:24,550 --> 01:11:28,000
>> 아마 너무 지출하지 않을거야
많은 시간을 문서에 대해 이야기.

1627
01:11:28,000 --> 01:11:31,460
이것은, 아마, 조금 얻는다
깊은 우리에 갈 필요가보다.

1628
01:11:31,460 --> 01:11:33,710
의 조금을 얘기하자
대한 풍부한 쿼리 식.

1629
01:11:33,710 --> 01:11:37,831
그래서 디나모 DB에 우리는이
만들 수있는 능력

1630
01:11:37,831 --> 01:11:39,330
우리는 투사 식을 부르는 것.

1631
01:11:39,330 --> 01:11:42,660
프로젝션 표현은 단순히
필드 또는 값을 따기

1632
01:11:42,660 --> 01:11:44,290
당신은 표시하도록.

1633
01:11:44,290 --> 01:11:46,000
좋아, 그럼 난을 선택합니다.

1634
01:11:46,000 --> 01:11:48,010
나는 디나모 DB에 대한 쿼리를 확인합니다.

1635
01:11:48,010 --> 01:11:51,730
그리고, 쇼 당신은 무엇을 알고, 말
날에만 5 성급 리뷰

1636
01:11:51,730 --> 01:11:54,544
이 특정 제품에 대한.

1637
01:11:54,544 --> 01:11:55,710
그래서 내가보고 싶은 모든이다.

1638
01:11:55,710 --> 01:11:57,320
나는 모든을보고 싶지 않아
행의 다른 속성,

1639
01:11:57,320 --> 01:11:58,319
난 그냥이보고 싶어.

1640
01:11:58,319 --> 01:12:01,209
그것은 바로 그 때 SQL에서처럼 당신
선택 스타 또는 테이블에서 말을,

1641
01:12:01,209 --> 01:12:02,000
당신은 모든 것을 얻을.

1642
01:12:02,000 --> 01:12:05,450
나는에서 선택 이름을 말할 때
표, 나는 단지 하나의 속성을 얻을.

1643
01:12:05,450 --> 01:12:09,070
이 물건의 같은 종류의
디나모 DB 또는 다른 NoSQL에 데이터베이스.

1644
01:12:09,070 --> 01:12:14,510
필터 표현에 날 수 있습니다
기본적으로 아래로 결과 세트를 잘라.

1645
01:12:14,510 --> 01:12:15,540
그래서 쿼리를 확인합니다.

1646
01:12:15,540 --> 01:12:17,260
쿼리는 500 항목으로 돌아올 수 있습니다.

1647
01:12:17,260 --> 01:12:20,255
그러나 나는 항목 만 원하는
이라는 속성을 가지고있다.

1648
01:12:20,255 --> 01:12:23,380
좋아, 그래서 그 항목을 필터링 할 수
즉, 특정 쿼리와 일치하지 않습니다.

1649
01:12:23,380 --> 01:12:25,540
그래서 우리는 필터 식을 가지고있다.

1650
01:12:25,540 --> 01:12:28,310
>> 필터 식 수
모든 속성에서 실행.

1651
01:12:28,310 --> 01:12:30,260
그들은 범위 쿼리를 좋아하지 않을 것입니다.

1652
01:12:30,260 --> 01:12:32,690
올리 쿼리는 더 선택적입니다.

1653
01:12:32,690 --> 01:12:36,470
필터 쿼리 가라고 요구
전체 결과는 다음 설정 및 취득

1654
01:12:36,470 --> 01:12:39,170
내가 원하지 않는 데이터를 개척.

1655
01:12:39,170 --> 01:12:40,660
왜 중요한가?

1656
01:12:40,660 --> 01:12:42,770
나는 모두를 읽을 수 있기 때문에.

1657
01:12:42,770 --> 01:12:46,597
쿼리에서, 내가 읽은거야 및
이 데이터에 대한 거대한 될 것.

1658
01:12:46,597 --> 01:12:48,430
그리고 나는 갈거야
내가 필요한 개척.

1659
01:12:48,430 --> 01:12:52,080
그리고 나는 단지 밖으로 조각 해요 경우
행의 부부, 그 괜찮아요.

1660
01:12:52,080 --> 01:12:53,620
너무 비효율적이 아니다.

1661
01:12:53,620 --> 01:12:57,800
>> 하지만 난의 전체 더미를 읽고 있어요 경우
데이터는 단지 하나의 항목을 개척

1662
01:12:57,800 --> 01:13:01,490
나는 더 좋을거야
범위 쿼리를 개시,

1663
01:13:01,490 --> 01:13:03,030
훨씬 더 선택적 왜냐하면.

1664
01:13:03,030 --> 01:13:06,330
그것은 나에게 많이 저장할 것
돈, 내가 그 읽기를 지불하기 때문이다.

1665
01:13:06,330 --> 01:13:10,430
어디에서 돌아 오는 결과
작은 수 있습니다 그 선을 넘어,

1666
01:13:10,430 --> 01:13:11,890
그러나 나는 읽기를 지불하고있다.

1667
01:13:11,890 --> 01:13:14,340
그래서 방법을 이해
당신은 데이터를 가져 오는 것입니다.

1668
01:13:14,340 --> 01:13:16,420
즉 디나모 DB에 매우 중요합니다.

1669
01:13:16,420 --> 01:13:19,710
>> 조건부 표현이 무엇을이다
당신은 낙관적 잠금을 호출 할 수 있습니다.

1670
01:13:19,710 --> 01:13:28,470
업데이트하는 경우가 존재, 또는이 값의 경우
내가 지정하는 것과 동일합니다.

1671
01:13:28,470 --> 01:13:31,494
그리고 난에 타임 스탬프가있는 경우
기록, 나는 데이터를 읽을 수 있습니다.

1672
01:13:31,494 --> 01:13:32,535
그 데이터를 변경할 수 있습니다.

1673
01:13:32,535 --> 01:13:35,030
나는 쓰기를 갈 수도 그
데이터베이스에 데이터 다시.

1674
01:13:35,030 --> 01:13:38,100
누군가가 레코드를 변경하는 경우,
타임 스탬프는 변경 될 수 있습니다.

1675
01:13:38,100 --> 01:13:40,370
그리고 그런 식으로 내 조건
업데이트는 업데이트를 말할 수

1676
01:13:40,370 --> 01:13:42,340
소인이 동일한 경우.

1677
01:13:42,340 --> 01:13:46,290
또는 업데이트는 사람 때문에 실패합니다
그 동안의 기록을 갱신했습니다.

1678
01:13:46,290 --> 01:13:48,290
>> 그것은 우리가 낙관적 잠금을 부르는.

1679
01:13:48,290 --> 01:13:50,670
그것은 그 사람을 의미합니다
와서 변경할 수 있습니다,

1680
01:13:50,670 --> 01:13:53,100
나는 그것을 감지하는거야
내가 돌아 갈 때 씁니다.

1681
01:13:53,100 --> 01:13:56,106
그리고 나는 실제로 그것을 읽을 수 있습니다
데이터 및 오, 그가이 바뀌 말한다.

1682
01:13:56,106 --> 01:13:57,230
나는 그것을 설명하기 위해 필요합니다.

1683
01:13:57,230 --> 01:14:00,490
그리고 난의 데이터를 변경할 수 있습니다 내
기록과 다른 업데이트를 적용.

1684
01:14:00,490 --> 01:14:04,330
그래서 당신은 그 증가분을 잡을 수 있습니다
시간 사이에 발생하는 업데이트

1685
01:14:04,330 --> 01:14:08,740
당신은 데이터를 읽어
시간 당신은 데이터를 쓸 수 있습니다.

1686
01:14:08,740 --> 01:14:11,520
>> 청중 : 그리고 필터
표현은 실제로하지 의미

1687
01:14:11,520 --> 01:14:13,020
번호 또는 싫든에서

1688
01:14:13,020 --> 01:14:14,316
>> [목소리를 개재]

1689
01:14:14,316 --> 01:14:16,232
릭 리한 (Houlihan) : 나는하지 않습니다
이에 너무 많이 얻을.

1690
01:14:16,232 --> 01:14:17,700
이 예약 된 키워드입니다.

1691
01:14:17,700 --> 01:14:20,130
파운드보기는 예약되어 있습니다
디나모 DB의 키워드.

1692
01:14:20,130 --> 01:14:24,500
모든 데이터베이스가 자신의 소유
당신이 사용할 수없는 컬렉션의 이름.

1693
01:14:24,500 --> 01:14:27,240
디나모 DB를 지정할 경우
이 앞의 파운드,

1694
01:14:27,240 --> 01:14:29,310
당신은 위의 그 이름을 정의 할 수 있습니다.

1695
01:14:29,310 --> 01:14:31,840
이 참조 된 값입니다.

1696
01:14:31,840 --> 01:14:34,880
아마 가장 구문 아니다
이 설명은 거기있다,

1697
01:14:34,880 --> 01:14:38,090
그것은 몇 가지 real--에 도착하기 때문에
내가 얘기 한 것보다

1698
01:14:38,090 --> 01:14:41,360
더 깊은 수준에서 그것에 대해.

1699
01:14:41,360 --> 01:14:46,130
>> 그러나 말을 충분,이 수
그들이 views-- 경우 검색 쿼리 수

1700
01:14:46,130 --> 01:14:50,190
나 파운드 뷰는 10보다 크다.

1701
01:14:50,190 --> 01:14:54,660
그것은 네, 수치이다.

1702
01:14:54,660 --> 01:14:57,322
당신이 원하는 경우에, 우리는 이야기 할 수 있습니다
토론 후 그.

1703
01:14:57,322 --> 01:15:00,030
좋아, 그래서 우리는에 있어요
모범 사례에서 몇 가지 시나리오

1704
01:15:00,030 --> 01:15:02,000
여기서 우리가 이야기하는거야
여기에 몇 가지 응용 프로그램에 대한.

1705
01:15:02,000 --> 01:15:03,810
디나모 DB에 대한 사용 사례는 무엇인가.

1706
01:15:03,810 --> 01:15:06,120
디자인은 무엇입니까
디나모 DB에 패턴.

1707
01:15:06,120 --> 01:15:09,110
>> 그리고 첫 번째는 우리가 갈거야
에 대한 이야기​​는 사물의 인터넷이다.

1708
01:15:09,110 --> 01:15:15,010
내가 추측 동행입니다 그래서 우리는 많이 얻을,
그건 ... 50 % 이상 것입니다

1709
01:15:15,010 --> 01:15:19,370
요즘 인터넷에서 트래픽
실제로 기계에 의해 생성된다,

1710
01:15:19,370 --> 01:15:21,930
아니 인간이 자동화 된 프로세스.

1711
01:15:21,930 --> 01:15:25,140
나는이 일이 일을 의미하는
당신은, 당신의 주머니에 다니는

1712
01:15:25,140 --> 01:15:28,840
얼마나 많은 데이터가 그 일이라고
실제로 않고 주위에 전송

1713
01:15:28,840 --> 01:15:30,550
그것을 아는 것은 절대적으로 놀랍습니다.

1714
01:15:30,550 --> 01:15:34,970
귀하의 위치 정보
얼마나 빨리에 대해 당신은 것입니다.

1715
01:15:34,970 --> 01:15:38,400
Google지도 일을 생각하는 방법
그들이 당신을 말할 때 트래픽은 무엇인지.

1716
01:15:38,400 --> 01:15:41,275
수백만이 있기 때문에 그것은이고
주위에 운전 수백만의 사람들

1717
01:15:41,275 --> 01:15:44,667
보내는 전화와
모든 모든 시간을 여기 저기 데이터.

1718
01:15:44,667 --> 01:15:46,500
것들 중 하나 그래서
이러한 유형의 데이터에 대한

1719
01:15:46,500 --> 01:15:50,980
즉 오면, 모니터 데이터, 로그
데이터, 시계열 데이터는, 그것의 인

1720
01:15:50,980 --> 01:15:53,540
보통 재미
약간의 시간을 위해.

1721
01:15:53,540 --> 01:15:55,580
그 시간 후,이를있어
그렇게 재미 있지.

1722
01:15:55,580 --> 01:15:58,390
그래서 우리는 할 수없는, 이야기
그 테이블은 무제한으로 증가.

1723
01:15:58,390 --> 01:16:03,410
여기에 아이디어는 어쩌면 내가 24을 가지고 있다는 것입니다
내 뜨거운 테이블에서 이벤트의 가치가 시간.

1724
01:16:03,410 --> 01:16:06,160
그리고 그 뜨거운 표가 될 것입니다
매우 높은 속도로 프로비저닝,

1725
01:16:06,160 --> 01:16:07,950
이 많은 양의 데이터를 가지고 있기 때문에.

1726
01:16:07,950 --> 01:16:10,920
이것은 많은 양의 데이터를 복용
그리고 나는 그것을 많이 읽고 있어요.

1727
01:16:10,920 --> 01:16:14,560
나는 운전을 많이 가지고
데이터에 대해 실행 쿼리.

1728
01:16:14,560 --> 01:16:18,120
>> 24 시간 후 이봐, 당신
난 상관 없어 무엇을 알고있다.

1729
01:16:18,120 --> 01:16:21,150
그래서 어쩌면 모든 자정 내가 롤
새 테이블 위에 내 테이블

1730
01:16:21,150 --> 01:16:22,430
나는이 테이블을 관리 취소.

1731
01:16:22,430 --> 01:16:26,440
내가 할게요 RCU의과
WCU의 아래로 인해 24시간 이상

1732
01:16:26,440 --> 01:16:28,630
나는 많은 사람을 운영하지 않는 경우
해당 데이터에 대한 쿼리.

1733
01:16:28,630 --> 01:16:30,200
그래서 돈을 절약 할거야.

1734
01:16:30,200 --> 01:16:32,940
그리고 어쩌면 삼십일 나중에 내가하지
심지어 모든 걱정 할 필요가있다.

1735
01:16:32,940 --> 01:16:35,020
나는 WCU의 걸릴 수 있습니다
하나에 이르기까지 모든 방법,

1736
01:16:35,020 --> 01:16:36,990
당신이 알고 있기 때문에, 그것은 무엇
결코 기록 얻을 것 없다.

1737
01:16:36,990 --> 01:16:38,300
데이터 30 일 이전입니다.

1738
01:16:38,300 --> 01:16:40,000
그것은 변화하지 않았다.

1739
01:16:40,000 --> 01:16:44,200
>> 그리고, 읽어 얻기 위하여려고 거의 절대 것
그래서 그냥 10까지 그 RCU 보자.

1740
01:16:44,200 --> 01:16:49,372
그리고이 돈의 톤을 절약 해요
데이터는, 단지 내 핫 데이터 지불.

1741
01:16:49,372 --> 01:16:52,330
그래서 보는 중요한 일이
한 번 시리즈에서 볼 때의

1742
01:16:52,330 --> 01:16:54,716
데이터 볼륨에 들어오는.

1743
01:16:54,716 --> 01:16:55,590
이러한 전략이다.

1744
01:16:55,590 --> 01:16:58,010
지금, 나는 단지 그것을 할 수
모두 동일한 테이블로 이동

1745
01:16:58,010 --> 01:16:59,461
단지 그 테이블 성장 할 수 있습니다.

1746
01:16:59,461 --> 01:17:01,460
결국, 내가 갈거야
성능 문제를 참조하십시오.

1747
01:17:01,460 --> 01:17:04,060
내가 보관하기 시작해야 할거야
테이블 오프 데이터의 일부,

1748
01:17:04,060 --> 01:17:04,720
선반.

1749
01:17:04,720 --> 01:17:07,010
>> 의 훨씬 더하자
응용 프로그램을 설계

1750
01:17:07,010 --> 01:17:08,900
그래서 당신은 바로 이런 식으로 작동 할 수있다.

1751
01:17:08,900 --> 01:17:11,460
그래서 그냥 자동의
애플리케이션 코드.

1752
01:17:11,460 --> 01:17:13,580
자정 매일 밤에서
그 테이블 롤.

1753
01:17:13,580 --> 01:17:17,170
어쩌면 내가 필요한 것은 슬라이딩입니다
데이터의 24 시간 창.

1754
01:17:17,170 --> 01:17:20,277
그리고 정기적으로 나는 해요
테이블 오프 데이터를 호출.

1755
01:17:20,277 --> 01:17:22,360
나는 그것을 트리밍 해요
cron 작업과 내가 넣었 어

1756
01:17:22,360 --> 01:17:24,160
이러한 다른 테이블 위에,
당신은 무엇을해야.

1757
01:17:24,160 --> 01:17:25,940
롤오버가 작동한다면, 그것은 좋아요.

1758
01:17:25,940 --> 01:17:27,080
그렇지 않은 경우, 그것을 잘라.

1759
01:17:27,080 --> 01:17:29,640
그러나의 그 뜨거운 데이터를 유지하자
멀리 추운 데이터에서.

1760
01:17:29,640 --> 01:17:32,535
그것은 당신에게 많은 돈을 절약 할 수 및
당신의 테이블에 더 많은 공연을합니다.

1761
01:17:32,535 --> 01:17:35,960

1762
01:17:35,960 --> 01:17:38,210
그래서 다음 일은 우리가 얘기하자
에 대한 제품 카탈로그입니다.

1763
01:17:38,210 --> 01:17:42,000
제품 카탈로그입니다
꽤 일반적인 사용 사례.

1764
01:17:42,000 --> 01:17:46,600
이것은 실제로 매우 일반적인 패턴이다
우리는 사물의 다양한 볼 수있다.

1765
01:17:46,600 --> 01:17:48,870
당신을 위해, 트위터를 알고
예를 들어, 뜨거운 트윗.

1766
01:17:48,870 --> 01:17:51,280
모두가오고 및
그 트윗을 잡아.

1767
01:17:51,280 --> 01:17:52,680
제품 카탈로그, 나는 판매를 얻었다.

1768
01:17:52,680 --> 01:17:54,120
나는 뜨거운 판매를 얻었다.

1769
01:17:54,120 --> 01:17:57,277
나는 당 70,000 요청을 받았습니다
두 번째 제품에 오는

1770
01:17:57,277 --> 01:17:58,860
내 제품 카탈로그 중 설명.

1771
01:17:58,860 --> 01:18:02,384
우리는 소매에이 참조
작업 꽤.

1772
01:18:02,384 --> 01:18:03,550
그렇다면 우리는 그 처리합니까?

1773
01:18:03,550 --> 01:18:04,924
그 다루는 방법은 없습니다.

1774
01:18:04,924 --> 01:18:07,110
내 모든 사용자가보고 싶어
동일한 데이터 조각.

1775
01:18:07,110 --> 01:18:09,410
그들은 동시에에서 오는 것입니다.

1776
01:18:09,410 --> 01:18:11,920
그리고 그들은 모든 요청을 만들고있어
데이터의 동일한 부분에 대한.

1777
01:18:11,920 --> 01:18:16,240
이 날을 제공하는 핫 키가 큰 빨간
우리가 좋아하지 않는 내 차트에 스트라이프.

1778
01:18:16,240 --> 01:18:17,720
그리고 그 모습이다.

1779
01:18:17,720 --> 01:18:22,290
내 키 공간을 통해 내가 받고 있어요 그래서
판매 상품에 망치.

1780
01:18:22,290 --> 01:18:24,070
나는 다른 곳에서는 아무것도 받고 없습니다 해요.

1781
01:18:24,070 --> 01:18:26,050
>> 이 문제를 어떻게 완화 하는가?

1782
01:18:26,050 --> 01:18:28,410
음, 우리는 캐시와이를 완화.

1783
01:18:28,410 --> 01:18:33,630
캐시, 당신은 인 메모리 기본적으로 넣어
데이터베이스의 앞에 파티션.

1784
01:18:33,630 --> 01:18:37,260
우리는 관리해야
[들림] 캐시, 방법을

1785
01:18:37,260 --> 01:18:40,260
자신의 캐시를 설정할 수 있습니다, [들림]
은닉처 [? D,?] 당신이 원하는대로.

1786
01:18:40,260 --> 01:18:42,220
데이터베이스의 앞에 그 차 넣었습니다.

1787
01:18:42,220 --> 01:18:47,250
그리고 그 방법은 해당 데이터를 저장할 수 있습니다
이 캐시에 최대 사람들 핫 키에서

1788
01:18:47,250 --> 01:18:49,390
공간과 캐시를 읽어.

1789
01:18:49,390 --> 01:18:51,962
>> 그리고 다음의 대부분은 당신의 읽기
이처럼 보이는 시작합니다.

1790
01:18:51,962 --> 01:18:54,920
나는이 캐시는 여기에 모두를 명중있어
나는 아무것도 아래로 여기에 않을있어

1791
01:18:54,920 --> 01:18:59,330
데이터베이스는 뒤에 앉아 있기 때문에
캐시와는 나오지 않을 읽습니다.

1792
01:18:59,330 --> 01:19:02,520
나는의 데이터를 변경하는 경우
데이터베이스, 나는 캐시를 업데이트해야합니다.

1793
01:19:02,520 --> 01:19:04,360
우리는 뭔가를 사용할 수 있습니다
같은 그렇게 하네.

1794
01:19:04,360 --> 01:19:07,360
그리고 그 작동 방법을 설명 할 것이다.

1795
01:19:07,360 --> 01:19:09,060
좋아, 메시징.

1796
01:19:09,060 --> 01:19:11,180
이메일, 우리 모두가 이메일을 사용합니다.

1797
01:19:11,180 --> 01:19:12,540
>> 이것은 꽤 좋은 예입니다.

1798
01:19:12,540 --> 01:19:14,950
우리는 메시지 테이블의 일종을 가지고있다.

1799
01:19:14,950 --> 01:19:17,040
그리고 우리는받은 편지함과 보낸 편지함을 얻었다.

1800
01:19:17,040 --> 01:19:19,760
이것은 어떤 SQL을 것입니다
그받은 편지함을 구축하는 모습.

1801
01:19:19,760 --> 01:19:23,350
우리는 가지 같은 종류를 사용
GSI의를 GSI의를 사용하는 전략

1802
01:19:23,350 --> 01:19:25,320
받은 편지함 내 보낼 편지함에 대한.

1803
01:19:25,320 --> 01:19:27,600
그래서 원시 메시지가오고있어
내 메시지 테이블에.

1804
01:19:27,600 --> 01:19:30,194
그리고 이것에 첫 번째 방법
수도, 확인 문제, 말을하지 않습니다.

1805
01:19:30,194 --> 01:19:31,110
나는 원시 메시지를 가지고있다.

1806
01:19:31,110 --> 01:19:33,710
오는 메시지 [들림],
메시지 ID, 그건 좋아요.

1807
01:19:33,710 --> 01:19:35,070
그게 내 유일한 해시입니다.

1808
01:19:35,070 --> 01:19:38,280
나는 두 GSI의를 만드는 일을하려고 해요
받은 편지함, 내 보낼 편지함에 대한 하나.

1809
01:19:38,280 --> 01:19:40,530
그리고 제일 먼저 내가 할거야
내 해시 키는 말할 것입니다

1810
01:19:40,530 --> 01:19:43,310
받는 사람이 될 것와
나는 날짜에 배치하는거야.

1811
01:19:43,310 --> 01:19:44,220
이 환상적이다.

1812
01:19:44,220 --> 01:19:45,890
나는 여기에 내 좋은 전망을 얻었다.

1813
01:19:45,890 --> 01:19:47,780
하지만 약간의 문제가 여기에있다.

1814
01:19:47,780 --> 01:19:50,891
그리고 당신이로 실행
관계형 데이터베이스뿐만 아니라.

1815
01:19:50,891 --> 01:19:52,390
그들은 수직 분할을했다.

1816
01:19:52,390 --> 01:19:55,840
당신은 당신의 빅 데이터를 유지하려면
멀리 작은 데이터에서.

1817
01:19:55,840 --> 01:20:00,470
>> 내가 해 있기 때문에 이유는 이유
속성을 얻을 수있는 항목을 읽을 이동합니다.

1818
01:20:00,470 --> 01:20:05,570
그리고 내 몸은 여기에 모두에있는 경우,
다음 몇 가지 항목을 읽고

1819
01:20:05,570 --> 01:20:08,560
몸 길이이면
256킬로바이트 각각의 평균,

1820
01:20:08,560 --> 01:20:10,991
수학은 매우 추한 가져옵니다.

1821
01:20:10,991 --> 01:20:12,490
그래서 다윗의받은 편지함을 읽을 수 말한다.

1822
01:20:12,490 --> 01:20:14,520
다윗의받은 편지함은 50 항목이 있습니다.

1823
01:20:14,520 --> 01:20:17,880
평균 크기 256 킬로바이트.

1824
01:20:17,880 --> 01:20:21,730
여기 내 전환 비율이다
RCU의에 대한 사킬로바이트입니다.

1825
01:20:21,730 --> 01:20:24,450
>> 확인의 함께 가자
결국 일관성을 읽습니다.

1826
01:20:24,450 --> 01:20:28,640
나는 아직도 1600 RCU의 먹는거야
바로 다윗의받은 편지함을 읽을 수 있습니다.

1827
01:20:28,640 --> 01:20:29,950
아야.

1828
01:20:29,950 --> 01:20:31,980
좋아, 이제 생각해 봅시다
응용 프로그램의 작동 방식에 대한.

1829
01:20:31,980 --> 01:20:35,340
나는 이메일 응용 프로그램에있어 경우
나는 나의받은 편지함에서 찾고 있어요

1830
01:20:35,340 --> 01:20:39,680
나는 모든 메시지의 본문에 보면,
아니, 요약 찾고 있어요.

1831
01:20:39,680 --> 01:20:41,850
난 단지 헤더에서 찾고 있어요.

1832
01:20:41,850 --> 01:20:46,310
그래서 테이블 구조를 만들어 보자
그것은 더 그렇게 보인다.

1833
01:20:46,310 --> 01:20:49,470
>> 그래서 여기에 정보입니다
내 워크 플로우는 필요하다고.

1834
01:20:49,470 --> 01:20:50,890
그것은 내받은 편지함 GSI에 있어요.

1835
01:20:50,890 --> 01:20:53,800
그것은 날짜의, 보낸 사람,
주제, 다음

1836
01:20:53,800 --> 01:20:56,790
가리키는 메시지 ID,
다시 메시지 테이블에

1837
01:20:56,790 --> 01:20:57,850
어디 몸을 얻을 수 있습니다.

1838
01:20:57,850 --> 01:21:01,260

1839
01:21:01,260 --> 01:21:04,420
음,이 레코드 ID가 될 것입니다.

1840
01:21:04,420 --> 01:21:09,850
그들은 다시 가리키는 것
디나모 DB 테이블에 항목 ID.

1841
01:21:09,850 --> 01:21:12,220
모든 인덱스는 항상 creates--
항상 아이템을 보유

1842
01:21:12,220 --> 01:21:15,750
그 동행입니다 일환으로 ID
인덱스와 함께 제공됩니다.

1843
01:21:15,750 --> 01:21:17,414
>> 괜찮아.

1844
01:21:17,414 --> 01:21:19,080
청중 : 그것을 지시가 저장된?

1845
01:21:19,080 --> 01:21:21,420
릭 리한 (Houlihan) : 네, 알려줍니다
exactly-- 즉 않습니다 정확히입니다.

1846
01:21:21,420 --> 01:21:22,644
그것은 여기 말한다 내 다시 기록이다.

1847
01:21:22,644 --> 01:21:24,310
그리고 그것은 내 다시 기록에 다시 지적 할 것이다.

1848
01:21:24,310 --> 01:21:26,460
정확하게.

1849
01:21:26,460 --> 01:21:29,490
좋아, 그럼 지금 내받은 편지함입니다
실제로 훨씬 작은.

1850
01:21:29,490 --> 01:21:32,210
그리고 이것은 실제로 지원
이메일 응용 프로그램의 워크 플로우.

1851
01:21:32,210 --> 01:21:34,230
받은 편지함 그래서, 난을 클릭합니다.

1852
01:21:34,230 --> 01:21:38,160
내가 따라 가서 내가 메시지를 클릭
나는 몸을 가서 할 필요가있을 때 즉,이다

1853
01:21:38,160 --> 01:21:40,180
내가 갈거야 때문에
다른보기로 이동합니다.

1854
01:21:40,180 --> 01:21:43,870
당신의 MVC 유형에 대해 생각 그래서 경우
프레임 워크, 모델 뷰 컨트롤러.

1855
01:21:43,870 --> 01:21:46,120
>> 이 모델에 포함 된
데이터 뷰의 요구는

1856
01:21:46,120 --> 01:21:48,130
상기 제어기와 상호 작용한다.

1857
01:21:48,130 --> 01:21:51,670
나는 프레임을 변경하면 때
나는 관점을 변경,

1858
01:21:51,670 --> 01:21:55,080
그것은로 돌아갈 괜찮아요
서버 및 모델을 다시 채 웁니다,

1859
01:21:55,080 --> 01:21:56,860
즉, 사용자가 무엇을 기대하고 있기 때문에.

1860
01:21:56,860 --> 01:22:00,530
그들이보기를 변경하면, 그 때의
우리는 데이터베이스에 다시 갈 수 있습니다.

1861
01:22:00,530 --> 01:22:02,480
그래서 이메일을 클릭합니다.

1862
01:22:02,480 --> 01:22:03,710
나는 몸을 찾고 있어요.

1863
01:22:03,710 --> 01:22:04,330
왕복 여행.

1864
01:22:04,330 --> 01:22:05,680
몸을 얻을 이동합니다.

1865
01:22:05,680 --> 01:22:06,950
>> 나는 훨씬 덜 데이터를 읽을.

1866
01:22:06,950 --> 01:22:09,960
나는 단지 몸을 읽고 있어요 그
그가 그들을 필요로 할 때 다윗이 필요합니다.

1867
01:22:09,960 --> 01:22:14,230
그리고 1600 년 구울 아니에요
RCU의는 자신의받은 편지함을 표시합니다.

1868
01:22:14,230 --> 01:22:17,670
그래서 지금이 방법 that--
LSI 또는 GSI-- 미안 것을,

1869
01:22:17,670 --> 01:22:19,900
GSI는, 밖으로 작동합니다.

1870
01:22:19,900 --> 01:22:25,450
우리는받는 사람에 대한 우리의 해시를 가지고있다.

1871
01:22:25,450 --> 01:22:27,030
우리는 날짜 범위 키를 가지고있다.

1872
01:22:27,030 --> 01:22:31,380
그리고 우리는 예상 특성을 가지고있어
우리가보기를 지원하기 만하면 것을.

1873
01:22:31,380 --> 01:22:34,300
>> 우리는 보낼 편지함에 대한 그 돌립니다.

1874
01:22:34,300 --> 01:22:35,770
보낸 사람에 해시.

1875
01:22:35,770 --> 01:22:39,612
그리고 본질적으로, 우리가
아주 좋은, 깨끗한보기.

1876
01:22:39,612 --> 01:22:41,570
그리고 그것은 basically-- 우리의
이 좋은 메시지가

1877
01:22:41,570 --> 01:22:45,870
잘 때문에 확산되고있어 테이블
이 해시 만, 해시 메시지 ID입니다.

1878
01:22:45,870 --> 01:22:51,750
그리고 우리는 두 개의 인덱스가 그
해당 테이블의 떨어져 회전된다.

1879
01:22:51,750 --> 01:22:57,411
좋아, 그래서 여기에 생각은 할 수 없습니다
빅 데이터와이 작은 데이터를 유지

1880
01:22:57,411 --> 01:22:57,910
함께.

1881
01:22:57,910 --> 01:23:00,700
수직 분할,
그 테이블을 분할.

1882
01:23:00,700 --> 01:23:03,150
데이터를 읽을하지 마십시오 당신은 할 필요가 없습니다.

1883
01:23:03,150 --> 01:23:04,850
좋아, 게임.

1884
01:23:04,850 --> 01:23:06,990
우리는 모두 게임을 좋아한다.

1885
01:23:06,990 --> 01:23:10,902
적어도 나는 그 게임을 좋아한다.

1886
01:23:10,902 --> 01:23:12,735
몇 가지 그래서
우리는 때를 다루는 것을

1887
01:23:12,735 --> 01:23:14,193
우리는 바로, 게임에 대한 생각?

1888
01:23:14,193 --> 01:23:16,999
요즘 게임, 특히 모바일
게임, 모든 사고에 대해서입니다.

1889
01:23:16,999 --> 01:23:19,540
그리고 여기에 회전거야
멀리 DynamoDB의에서 조금.

1890
01:23:19,540 --> 01:23:21,373
나는에 데려 갈거야
토론의 일부

1891
01:23:21,373 --> 01:23:24,240
일부 주변
다른 AWS 기술.

1892
01:23:24,240 --> 01:23:28,930
>> 하지만 게임에 대한 아이디어가 생각하는 것입니다
API를 측면에서 약이다 API를,

1893
01:23:28,930 --> 01:23:31,730
일반적으로, HTTP 및 JSON을 말하기.

1894
01:23:31,730 --> 01:23:34,550
그것은 얼마나 모바일 게임의 종류
자신의 백 엔드와 상호 작용합니다.

1895
01:23:34,550 --> 01:23:35,850
그들은 JSON 포스팅을한다.

1896
01:23:35,850 --> 01:23:40,660
그들은 데이터를 얻을, 그것은 전부,
일반적으로 좋은 JSON API를에, 말하기.

1897
01:23:40,660 --> 01:23:44,950
>> 친구를 얻을 수 같은 것들, 수
리더, 데이터 교환,

1898
01:23:44,950 --> 01:23:47,699
사용자가 컨텐츠를 생성,
시스템에 백업을 밀어

1899
01:23:47,699 --> 01:23:49,740
이 물건의 종류
우리가 할 거라고.

1900
01:23:49,740 --> 01:23:52,542
이진 자산 데이터, 이러한 데이터
데이터베이스에 앉아하지 않을 수 있습니다.

1901
01:23:52,542 --> 01:23:54,250
이 앉아 있습니다
객체 저장소, 오른쪽?

1902
01:23:54,250 --> 01:23:56,541
그러나 데이터베이스에 가고
시스템을 말하고 결국,

1903
01:23:56,541 --> 01:23:59,140
응용 프로그램을 이야기
어디를 가서.

1904
01:23:59,140 --> 01:24:03,550
그리고 필연적으로, 멀티
서버 백엔드 인프라,

1905
01:24:03,550 --> 01:24:06,180
높은 위해 설계
가용성 및 확장 성을 제공합니다.

1906
01:24:06,180 --> 01:24:09,400
그래서 이러한 우리 모두가 원하는 일을하다
게임 인프라 오늘.

1907
01:24:09,400 --> 01:24:12,160
>> 그럼 살펴 보자
어떤이는 것 같습니다.

1908
01:24:12,160 --> 01:24:16,070
코어 백 엔드있어
매우 간단합니다.

1909
01:24:16,070 --> 01:24:19,880
우리는 여기있는 시스템을 가지고있어
여러 가용 영역.

1910
01:24:19,880 --> 01:24:23,780
생각 being--로 우리는 AZS에 대해 이야기
그들 중 별도의 데이터 센터와 같은.

1911
01:24:23,780 --> 01:24:26,040
하나 이상의 데이터 센터
AZ 당,하지만, 괜찮아요

1912
01:24:26,040 --> 01:24:28,831
다만 별도의 데이터로 생각
지리적으로있다 센터

1913
01:24:28,831 --> 01:24:30,090
및 장애 격리합니다.

1914
01:24:30,090 --> 01:24:32,172
>> 우리는이 겁니다
몇 EC2 인스턴스.

1915
01:24:32,172 --> 01:24:33,880
우리는 할 겁니다
몇 백 엔드 서버.

1916
01:24:33,880 --> 01:24:35,800
당신은 기존있어 어쩌면 경우
아키텍처, 우리는있어

1917
01:24:35,800 --> 01:24:38,920
우리가 RDS를 부르는 것을 사용하여,
관계형 데이터베이스 서비스를 제공합니다.

1918
01:24:38,920 --> 01:24:42,040
MSSQL, MySQL을 수 있을까,
또는 그런 일.

1919
01:24:42,040 --> 01:24:47,080
이 방법으로 많은 응용 프로그램입니다
오늘 설계되었습니다.

1920
01:24:47,080 --> 01:24:49,594
>> 그런데 우리는 함께 가야 할 수 있습니다
우리가 확장 할 때이다.

1921
01:24:49,594 --> 01:24:51,510
우리는 가서 놓을 게요
거기 S3 버킷.

1922
01:24:51,510 --> 01:24:54,200
그리고 S3 버킷 대신은 봉사
우리의 servers--에서 해당 개체까지

1923
01:24:54,200 --> 01:24:55,220
우리는 그렇게 할 수 있습니다.

1924
01:24:55,220 --> 01:24:57,210
당신은 당신의 바이너리를 넣어
서버의 개체

1925
01:24:57,210 --> 01:24:59,751
당신은 그 서버를 사용할 수 있습니다
인스턴스는 해당 데이터까지 서비스를 제공한다.

1926
01:24:59,751 --> 01:25:01,860
하지만 꽤 비싸다.

1927
01:25:01,860 --> 01:25:05,107
>> 할 수있는 더 좋은 방법이 가서입니다
S3 버킷에있는 그 물건을 올려.

1928
01:25:05,107 --> 01:25:06,315
S3는 객체 저장소입니다.

1929
01:25:06,315 --> 01:25:10,860
그것은을 위해 특별히으로 구축
사물의 이러한 유형을 제공.

1930
01:25:10,860 --> 01:25:13,690
그리고 그 클라이언트가 요청하자
직접 그 객체 버킷에서,

1931
01:25:13,690 --> 01:25:15,390
서버를 오프로드.

1932
01:25:15,390 --> 01:25:17,020
그래서 우리는 여기 확장하기 시작하고 있습니다.

1933
01:25:17,020 --> 01:25:19,140
>> 이제 우리는 전 세계의 사용자를 얻었다.

1934
01:25:19,140 --> 01:25:19,730
나는 사용자를 얻었다.

1935
01:25:19,730 --> 01:25:23,380
나는 로컬 콘텐츠를 필요
바로 이러한 사용자 가까이에있는?

1936
01:25:23,380 --> 01:25:26,200
나는 S3 버킷을 만들었습니다
내 소스 저장소로.

1937
01:25:26,200 --> 01:25:29,370
그리고 전면거야와 그
CloudFront를 배포.

1938
01:25:29,370 --> 01:25:31,720
>> CloudFront를은 CD 및 인
콘텐츠 전송 네트워크.

1939
01:25:31,720 --> 01:25:35,750
기본적으로 사용자가 지정한 데이터를한다
인터넷을 통해 모든 캐시

1940
01:25:35,750 --> 01:25:39,230
사용자는 어디서나 할 수 있도록
매우 빠른 응답 할 때

1941
01:25:39,230 --> 01:25:40,960
그들은 이러한 개체를 요청합니다.

1942
01:25:40,960 --> 01:25:41,960
>> 그래서 당신은 아이디어를 얻을.

1943
01:25:41,960 --> 01:25:48,230
당신은 가지 활용하고 모든
AWS의 측면 여기이 끝내야합니다.

1944
01:25:48,230 --> 01:25:50,790
그리고 결국, 우리는 던져
오토 스케일링 그룹.

1945
01:25:50,790 --> 01:25:52,737
우리의 AC2 인스턴스 그래서
우리의 게임 서버,

1946
01:25:52,737 --> 01:25:54,820
그들은 혼잡 얻을 시작으로
및 혼잡과 혼잡,

1947
01:25:54,820 --> 01:25:57,236
그들은 또 다른 스핀합니다
예, 다른 인스턴스를 회전

1948
01:25:57,236 --> 01:25:58,210
다른 인스턴스를 회전.

1949
01:25:58,210 --> 01:26:02,090
AWS, 그것은이 기술 그래서
당신은 매개 변수를 지정 허용

1950
01:26:02,090 --> 01:26:04,650
이는 주위에 당신의 서버는 성장할 것이다.

1951
01:26:04,650 --> 01:26:08,110
그래서 당신은 서버의 N 번호를 가질 수있다
주어진 시간에 거기.

1952
01:26:08,110 --> 01:26:11,870
당신의 부하가 사라질 경우, 그들은거야
축소, 수는 줄어들 것입니다.

1953
01:26:11,870 --> 01:26:15,250
그리고 부하가 돌아 오면,
그것은 탄성, 밖으로 다시 자랄거야.

1954
01:26:15,250 --> 01:26:17,050
>> 그래서이 멋지다.

1955
01:26:17,050 --> 01:26:19,800
우리는 EC2 인스턴스를 많이 가지고있다.

1956
01:26:19,800 --> 01:26:21,671
우리는에 캐시를 넣을 수 있습니다
데이터베이스 앞

1957
01:26:21,671 --> 01:26:23,045
시도하고 데이터베이스를 가속화 할 수 있습니다.

1958
01:26:23,045 --> 01:26:25,030
다음 압력 점
일반적으로 사람들은 참조

1959
01:26:25,030 --> 01:26:28,850
그들이를 이용 게임 스케일
관계형 데이터베이스 시스템.

1960
01:26:28,850 --> 01:26:30,790
이름 : Jeez, 데이터베이스
성능은 끔찍한입니다.

1961
01:26:30,790 --> 01:26:31,932
우리는 어떻게 개선 할 수 있습니까?

1962
01:26:31,932 --> 01:26:33,640
의 퍼팅 해보자
그 앞에 캐시.

1963
01:26:33,640 --> 01:26:36,780
>> 음, 캐시가 작동하지 않습니다
게임에 너무 큰, 오른쪽?

1964
01:26:36,780 --> 01:26:39,330
게임, 쓰기는 고통이다.

1965
01:26:39,330 --> 01:26:40,930
게임은 매우 무거운 쓰기된다.

1966
01:26:40,930 --> 01:26:43,610
당신이있을 때 캐시가 작동하지 않습니다
당신은 항상했습니다 때문에 무거운 쓰기

1967
01:26:43,610 --> 01:26:44,610
캐시를 업데이트 할 수있어.

1968
01:26:44,610 --> 01:26:47,780
사용자는 그것의 캐시를 업데이트
관련이없는 캐싱합니다.

1969
01:26:47,780 --> 01:26:49,780
실제로 단지 추가 작업입니다.

1970
01:26:49,780 --> 01:26:51,970
>> 그래서 우리는 여기 어디?

1971
01:26:51,970 --> 01:26:54,400
당신은 큰 병목있어
거기 데이터베이스에.

1972
01:26:54,400 --> 01:26:57,661
그리고 장소 이동
분명히 분할된다.

1973
01:26:57,661 --> 01:26:59,410
파티셔닝은 아니다
당신이있을 때 쉽게 할 수

1974
01:26:59,410 --> 01:27:01,900
관계형 데이터베이스를 다루는.

1975
01:27:01,900 --> 01:27:05,080
관계형 데이터베이스로, 당신은있어
관리에 대한 책임, 효과적으로,

1976
01:27:05,080 --> 01:27:06,210
키 공간.

1977
01:27:06,210 --> 01:27:10,527
당신은 A와 M 사이에 사용자가 말을하는지
N 및 Z는 거기 사이에, 여기.

1978
01:27:10,527 --> 01:27:12,360
그리고 당신은 전환하고
응용 프로그램에서.

1979
01:27:12,360 --> 01:27:15,000
그래서 당신은 상대하고
이 분할 데이터 소스.

1980
01:27:15,000 --> 01:27:18,670
당신은 트랜잭션 제약이
그 파티션에 걸쳐 없습니다.

1981
01:27:18,670 --> 01:27:20,560
당신은 모든 종류의있어
당신이있어 어지러움

1982
01:27:20,560 --> 01:27:23,040
이 아래로 노력을 다루는
스케일 아웃 처리합니다

1983
01:27:23,040 --> 01:27:25,120
더 큰 인프라를 구축.

1984
01:27:25,120 --> 01:27:27,284
그냥 재미 없다.

1985
01:27:27,284 --> 01:27:30,930
>> 청중 : 그래서 당신이 그 말을
소스 포인트를 증가시키는 속도

1986
01:27:30,930 --> 01:27:31,430
과정?

1987
01:27:31,430 --> 01:27:32,513
릭 리한 (Houlihan) : 증가?

1988
01:27:32,513 --> 01:27:33,520
청중 : 소스 점.

1989
01:27:33,520 --> 01:27:34,410
릭 리한 (Houlihan) : 소스 점?

1990
01:27:34,410 --> 01:27:37,500
청중 : 정보에서,
어디에서 정보가오고있다?

1991
01:27:37,500 --> 01:27:38,250
릭 리한 (Houlihan) : 아니오.

1992
01:27:38,250 --> 01:27:41,820
무슨 말인지를 증가
데이터 저장소의 파티션 번호

1993
01:27:41,820 --> 01:27:44,060
처리량을 향상시킨다.

1994
01:27:44,060 --> 01:27:48,300
그래서 여기에 무슨 일이 일어나고 사용자입니다
여기까지 EC2 인스턴스에오고,

1995
01:27:48,300 --> 01:27:50,780
글쎄, 난 사용자가 필요로하는 경우
즉 M에있어, 내가 여기 있습니다.

1996
01:27:50,780 --> 01:27:53,560
N에서 P로, 나는 여기 있습니다.

1997
01:27:53,560 --> 01:27:55,060
Z까지 P에서, 나는 여기 있습니다.

1998
01:27:55,060 --> 01:27:57,120
>> 청중 : OK, 그 때문에 사람들은
모든 다른 노드에 저장?

1999
01:27:57,120 --> 01:27:57,911
>> 릭 리한 (Houlihan) : 예.

2000
01:27:57,911 --> 01:28:00,210
이들의로 생각
다른 데이터 사일로.

2001
01:28:00,210 --> 01:28:01,660
그래서 당신은이 작업을 수행하는 데있어.

2002
01:28:01,660 --> 01:28:02,910
당신은 일을하려고하는 경우
이, 당신이하려고하는 경우

2003
01:28:02,910 --> 01:28:05,730
관계형 플랫폼을 확장하기 위해,
이것은 당신이 무슨 일을하는지입니다.

2004
01:28:05,730 --> 01:28:08,100
당신은 데이터를 복용하고 있고
당신은 그것을 아래로 절단하고 있습니다.

2005
01:28:08,100 --> 01:28:10,975
그리고 당신은 그것을 걸쳐 분할하고
데이터베이스의 여러 인스턴스.

2006
01:28:10,975 --> 01:28:13,580
그리고 당신은 모든 것을 관리하고 그
응용 프로그램 계층에서.

2007
01:28:13,580 --> 01:28:14,729
그것은 재미 없다.

2008
01:28:14,729 --> 01:28:15,770
그래서 우리가 가고 싶어합니까?

2009
01:28:15,770 --> 01:28:20,240
우리는 DynamoDB의, 완벽하게 관리 가고 싶어,
NoSQL에 데이터 저장, 제공 처리량.

2010
01:28:20,240 --> 01:28:22,680
우리는 보조 인덱스를 사용합니다.

2011
01:28:22,680 --> 01:28:26,154
그건 기본적으로 HTTP API와
문서 지원이 포함되어 있습니다.

2012
01:28:26,154 --> 01:28:28,570
그래서 당신은 걱정할 필요가 없습니다
그 분할의 약.

2013
01:28:28,570 --> 01:28:30,740
우리는 당신을 위해 모든 작업을 수행 할 수 있습니다.

2014
01:28:30,740 --> 01:28:33,260
그래서 지금, 대신,
그냥 테이블에 기록.

2015
01:28:33,260 --> 01:28:36,490
테이블을 분할 할 필요가있을 때에는
그 장면 뒤에 발생합니다.

2016
01:28:36,490 --> 01:28:40,642
당신은 완전히 절연하고
개발자로서 그에서.

2017
01:28:40,642 --> 01:28:42,350
그럼 대해 얘기하자
사용 사례의 일부

2018
01:28:42,350 --> 01:28:47,564
우리는 게임에서 공통으로 실행하는 것이
게임 시나리오, 리더.

2019
01:28:47,564 --> 01:28:49,980
그래서 당신은, 사용자가오고있어
그들이있어 BoardNames

2020
01:28:49,980 --> 01:28:52,930
에,이 사용자에 대한 기록했다.

2021
01:28:52,930 --> 01:28:57,700
우리는 사용자 ID에 해시 될 수 있습니다
그리고, 우리는 게임의 범위가 있습니다.

2022
01:28:57,700 --> 01:28:59,960
그래서 모든 사용자가보고 싶어
그가 연주있어 모든 게임

2023
01:28:59,960 --> 01:29:01,770
모든 자신의 최고 점수
모든 게임에서.

2024
01:29:01,770 --> 01:29:04,000
그래서 자신의 개인 리더입니다.

2025
01:29:04,000 --> 01:29:10,010
>> 지금은에 가고 싶어 나는이거나 먹어하려면
그래서 나는이 개인 순위표를 얻을.

2026
01:29:10,010 --> 01:29:12,827
내가 뭘 원하는 가서입니다
모든 사용자에 걸쳐 최고 점수.

2027
01:29:12,827 --> 01:29:13,660
그래서 내가 어떻게 그렇게 할 수 있습니까?

2028
01:29:13,660 --> 01:29:18,070
내 기록은 (는) 해시 때
사용자 ID는 게임에 원거리,

2029
01:29:18,070 --> 01:29:20,740
잘 나는 앞서 갈거야
및 구조 조정, GSI를 만들

2030
01:29:20,740 --> 01:29:22,370
나는 그 데이터를 재구성거야.

2031
01:29:22,370 --> 01:29:27,310
>> 지금은에 해시거야
게임 BoardName.

2032
01:29:27,310 --> 01:29:29,800
그리고 최고 점수에 대한 범위거야.

2033
01:29:29,800 --> 01:29:31,540
그리고 지금은 다른 버킷을 만들었습니다.

2034
01:29:31,540 --> 01:29:34,790
나는 동일한 테이블을 사용하고,
같은 항목 데이터.

2035
01:29:34,790 --> 01:29:39,870
그러나 나는주는 버킷을 만드는거야
나 게임에서 최고 점수의 집계.

2036
01:29:39,870 --> 01:29:43,180
>> 그리고 그 테이블을 조회 할 수 있습니다
그 정보를 얻을 수 있습니다.

2037
01:29:43,180 --> 01:29:50,890
그래서 나는까지 해당 쿼리 패턴을 설정 한
보조 인덱스에 의해 지원 될 수있다.

2038
01:29:50,890 --> 01:29:54,556
이제 그들은 BoardName으로 분류 할 수있다
과에 따라, TopScore으로 분류.

2039
01:29:54,556 --> 01:29:57,180
당신이 볼 수 있도록, 이러한 유형은
의 당신은 게임에 들어갈 경우에 사용합니다.

2040
01:29:57,180 --> 01:30:02,190
우리가 게임에 들어갈 또 다른 좋은 활용 사례
상 누가 상을 수상 것입니다.

2041
01:30:02,190 --> 01:30:05,340
그리고 이것은 좋은 유스 케이스입니다
우리는 스파 스 인덱스를 호출한다.

2042
01:30:05,340 --> 01:30:07,340
스파 스 인덱스는 있습니다
생성 할 수있는 능력

2043
01:30:07,340 --> 01:30:10,850
필요하지 않는 인덱스
테이블에있는 모든 단일 항목이 포함되어 있습니다.

2044
01:30:10,850 --> 01:30:11,470
그리고 왜 안돼?

2045
01:30:11,470 --> 01:30:14,540
때문에되고있는 속성
인덱스는 모든 항목에 존재하지 않습니다.

2046
01:30:14,540 --> 01:30:16,460
>> 이 특히 이렇게
케이스를 사용하여, 나는 말하고,

2047
01:30:16,460 --> 01:30:19,240
당신은 무엇을, 내가 갈거야 알고
상이라는 속성을 만듭니다.

2048
01:30:19,240 --> 01:30:22,970
그리고 모든 사용자를 줄거야
그 속성 상을 가지고있다.

2049
01:30:22,970 --> 01:30:25,950
사용자 수상은하지 않아도
그 속성을하지 않을.

2050
01:30:25,950 --> 01:30:27,800
그래서 만들 때
인덱스, 사용자 만

2051
01:30:27,800 --> 01:30:28,960
그 표시거야
인덱스에 있습니다

2052
01:30:28,960 --> 01:30:31,050
실제로 상을 수상 한 것.

2053
01:30:31,050 --> 01:30:34,440
그래서 할 수있는 좋은 방법입니다
필터링 된 인덱스를 만들려면 그

2054
01:30:34,440 --> 01:30:40,580
그렇지 않은 매우 선택적이다
인덱스에 전체 테이블을 가지고있다.

2055
01:30:40,580 --> 01:30:43,050
>> 그래서 우리는 여기에 시간이 부족 있어요.

2056
01:30:43,050 --> 01:30:49,190
내가 가서 건너 뛸거야
아웃이 시나리오를 건너 뜁니다.

2057
01:30:49,190 --> 01:30:52,625
조금 이야기 비슷해

2058
01:30:52,625 --> 01:30:54,460
>> 청중 : 나는 빠른 질문을 할 수 있습니까?

2059
01:30:54,460 --> 01:30:56,722
하나는 무거운 쓰기인가?

2060
01:30:56,722 --> 01:30:57,680
릭 리한 (Houlihan) : 무슨 일입니까?

2061
01:30:57,680 --> 01:30:58,596
청중 : 무거운 쓰기.

2062
01:30:58,596 --> 01:31:01,270
릭 리한 (Houlihan) : 무거운 쓰기.

2063
01:31:01,270 --> 01:31:03,460
어디 보자.

2064
01:31:03,460 --> 01:31:06,220
>> 청중 : 아니면은 아니다
뭔가 당신은 할 수 있습니다

2065
01:31:06,220 --> 01:31:08,809
초 만에에 음성?

2066
01:31:08,809 --> 01:31:10,850
릭 리한 (Houlihan) : 우리는 이동
투표 시나리오를 통해.

2067
01:31:10,850 --> 01:31:11,670
그것은 나쁜 아니다.

2068
01:31:11,670 --> 01:31:14,580
너희들은 몇 분 있습니까?

2069
01:31:14,580 --> 01:31:15,860
그래.

2070
01:31:15,860 --> 01:31:17,890
>> 그래서 우리는 투표에 대해 이야기 할 것입니다.

2071
01:31:17,890 --> 01:31:20,250
그래서 실시간 투표, 우리가
투표 요구 사항에 대해 설명합니다.

2072
01:31:20,250 --> 01:31:25,250
요구 사항은 우리가 허용한다는 것이다
각 사람은 한 번만 투표 할 수 있습니다.

2073
01:31:25,250 --> 01:31:28,060
우리는 아무도 할 수 없습니다 할
자신의 투표를 변경합니다.

2074
01:31:28,060 --> 01:31:31,045
우리는 실시간 집계 할
인구 통계에 대한 분석

2075
01:31:31,045 --> 01:31:34,210
우리는 될 거라고
사이트에서 사용자에게 보여.

2076
01:31:34,210 --> 01:31:35,200
>> 이 시나리오의 생각.

2077
01:31:35,200 --> 01:31:37,550
우리는 현실의 많은 작업
그들이있어 어디 TV 프로그램

2078
01:31:37,550 --> 01:31:38,960
사물의 이러한 정확한 유형을하고.

2079
01:31:38,960 --> 01:31:41,584
그래서 시나리오를 생각할 수있는,
우리는 수백만이

2080
01:31:41,584 --> 01:31:43,959
거기의 십대 소녀
자신의 휴대 전화와

2081
01:31:43,959 --> 01:31:46,250
투표, 투표, 그리고
그들이 누구를 위해 투표

2082
01:31:46,250 --> 01:31:48,610
가장 인기를 찾을 수 있습니다.

2083
01:31:48,610 --> 01:31:50,830
따라서 이들 중 일부
요구 사항은 우리이 다.

2084
01:31:50,830 --> 01:31:52,990
>> 그래서 첫 번째 걸릴
이 문제를 해결

2085
01:31:52,990 --> 01:31:55,090
를 구축하는 것입니다
매우 간단한 응용 프로그램입니다.

2086
01:31:55,090 --> 01:31:56,490
그래서 나는이 응용 프로그램을 가지고있다.

2087
01:31:56,490 --> 01:31:57,950
나는 거기에 일부 유권자을 가지고있다.

2088
01:31:57,950 --> 01:31:59,980
그들은이 투표 응용 프로그램 충돌, 올.

2089
01:31:59,980 --> 01:32:03,440
나는 일부 원시 표 테이블을 가지고
난 그냥 그 투표에 덤프합니다.

2090
01:32:03,440 --> 01:32:05,780
나는 약간의 집합이있을 것이다
표 테이블이

2091
01:32:05,780 --> 01:32:09,490
내 분석 및 인구 통계를 할 것입니다,
우리는 거기에 모든 것을 놓을 게.

2092
01:32:09,490 --> 01:32:11,420
>> 그리고 이것은 중대하다.

2093
01:32:11,420 --> 01:32:12,332
인생은 좋은 것입니다.

2094
01:32:12,332 --> 01:32:15,040
인생은 우리가 찾을 때까지 좋은
항상 하나 또는 두 개의있다

2095
01:32:15,040 --> 01:32:16,879
선거에서 인기있는 사람들.

2096
01:32:16,879 --> 01:32:19,420
하나 또는 두 가지가있다
사람들이 정말 걱정 것을.

2097
01:32:19,420 --> 01:32:22,340
그리고 당신은에 투표하는 경우
규모, 난 갑자기

2098
01:32:22,340 --> 01:32:26,360
의 지옥을 망치 될 것
두 후보, 하나 또는 두 개의 후보.

2099
01:32:26,360 --> 01:32:29,390
상품의 수가 매우 제한
사람들은 인기를 찾을 수 있습니다.

2100
01:32:29,390 --> 01:32:31,710
>> 이것은 좋은 디자인 패턴이 아니다.

2101
01:32:31,710 --> 01:32:33,549
이것은 사실입니다
아주 나쁜 디자인 패턴

2102
01:32:33,549 --> 01:32:36,340
그것은 만들기 때문에 정확히 우리
핫 키이었다에 대해 이야기했다.

2103
01:32:36,340 --> 01:32:38,960
핫 키는 우리가 좋아하지 않는 일이다.

2104
01:32:38,960 --> 01:32:40,470
>> 그렇다면 우리는 그 문제를 해결합니까?

2105
01:32:40,470 --> 01:32:47,640
정말,이 문제를 해결하는 방법은
그 후보 버킷을 취함으로써

2106
01:32:47,640 --> 01:32:51,490
그리고 우리가 가지고있는 각각의 후보,
우리는 임의의 값을 추가하는거야,

2107
01:32:51,490 --> 01:32:54,192
임의 우리가 알고있는 무엇인가,
하나에서 100 사이의 값,

2108
01:32:54,192 --> 01:32:56,620
100과 1000 사이에,
또는 1과 1,000 사이,

2109
01:32:56,620 --> 01:32:59,940
그러나 많은 임의의 값은 당신이 원하는
그 후보의 끝에 추가합니다.

2110
01:32:59,940 --> 01:33:01,330
>> 그리고 난 정말 그때 무슨 짓을 한거야?

2111
01:33:01,330 --> 01:33:05,830
나는 후보 ID로 사용하고있는 경우
총 투표에 양동이,

2112
01:33:05,830 --> 01:33:08,780
나는 임의을 추가 한 경우
그 말에 수,

2113
01:33:08,780 --> 01:33:12,000
내가 만든 지금 10 양동이,
백 양동이, 천 버킷

2114
01:33:12,000 --> 01:33:14,160
것을 나는 걸쳐 투표를 집계하고있다.

2115
01:33:14,160 --> 01:33:18,030
>> 그래서, 수백만, 수백만이
와 기록의 수백만오고

2116
01:33:18,030 --> 01:33:22,050
이 후보, 지금 확산하고
후보 A_1에서 그 투표

2117
01:33:22,050 --> 01:33:24,630
후보 A_100 통해 때문에
투표에 온다 때마다,

2118
01:33:24,630 --> 01:33:26,530
나는 무작위로 발생하고있어
하나에서 100 사이의 값입니다.

2119
01:33:26,530 --> 01:33:29,446
나는이 말에 그것을 시침 해요
사람의가 투표 후보.

2120
01:33:29,446 --> 01:33:31,120
나는 양동이로 덤핑하고있다.

2121
01:33:31,120 --> 01:33:33,910
>> 이제 뒷면에, 나는 알고있다
것을 나는 백 버킷을 얻었다.

2122
01:33:33,910 --> 01:33:36,350
그래서 나는 진행하고자 할 때
그리고 투표를 집계,

2123
01:33:36,350 --> 01:33:38,244
나는 모든 버킷에서 읽을.

2124
01:33:38,244 --> 01:33:39,160
그래서 내가 가서 추가 할 수 있습니다.

2125
01:33:39,160 --> 01:33:42,410
그리고 나는 분산은 수집 않는다
내가 나가서 헤이 말할 경우,

2126
01:33:42,410 --> 01:33:45,399
당신은 무엇을 알고,이 후보의 키
공간은 백 이상 버킷입니다.

2127
01:33:45,399 --> 01:33:47,940
나는 모든를 수집하는거야
그 백 버킷에서 투표.

2128
01:33:47,940 --> 01:33:49,981
나는 집계거야
그들과 나는 말을하려고 해요

2129
01:33:49,981 --> 01:33:53,830
후보는 지금이
X의 총 투표 수입니다.

2130
01:33:53,830 --> 01:33:55,690
>> 이제 쓰기 모두
질의 및 판독 질의

2131
01:33:55,690 --> 01:33:58,160
잘 분산되어
나는 걸쳐 쓰고 있어요 때문에

2132
01:33:58,160 --> 01:34:00,320
나는 키의 수백에 걸쳐 읽고 있어요.

2133
01:34:00,320 --> 01:34:03,500
내가 쓰는 아니에요과
지금은 하나의 키를 통해 읽기.

2134
01:34:03,500 --> 01:34:04,950
그래서 좋은 패턴입니다.

2135
01:34:04,950 --> 01:34:08,090
>> 이 사실은 아마 하나입니다
가장 중요한 설계

2136
01:34:08,090 --> 01:34:10,420
NoSQL에 규모에 대한 패턴.

2137
01:34:10,420 --> 01:34:14,470
당신은이 유형을 볼 수
모든 맛의 디자인 패턴.

2138
01:34:14,470 --> 01:34:19,100
MongoDB를, Dy​​namoDB의, 그렇지 않습니다
문제, 우리 모두가이 작업을 수행 할 수 있습니다.

2139
01:34:19,100 --> 01:34:21,840
당신이 취급 할 때 때문에
그 거대한 집계와,

2140
01:34:21,840 --> 01:34:26,650
당신은 방식을 파악해야
버킷에 걸쳐 그들을 밖으로 퍼졌다.

2141
01:34:26,650 --> 01:34:29,512
그래서 이것은 당신이 그것을 할 방법입니다.

2142
01:34:29,512 --> 01:34:31,220
좋아, 그럼
당신이 지금하고있는

2143
01:34:31,220 --> 01:34:35,252
당신은 읽기를 거래하고있다
쓰기 확장 성을위한 비용.

2144
01:34:35,252 --> 01:34:37,085
내 판독의 비용은
좀 더 복잡한

2145
01:34:37,085 --> 01:34:40,220
내가 읽어 가야
백 버킷 대신 중 하나.

2146
01:34:40,220 --> 01:34:41,310
그러나 나는 쓸 수 있어요.

2147
01:34:41,310 --> 01:34:44,860
그리고 내 처리량, 내 쓰기
처리량은 믿을 수 없다.

2148
01:34:44,860 --> 01:34:49,450
그래서 일반적으로 귀중
DynamoDB의 크기 조정을위한 기술,

2149
01:34:49,450 --> 01:34:51,350
또는 그 문제에 대한 모든 NoSQL에 데이터베이스.

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

2151
01:34:53,824 --> 01:34:55,240
그래서 우리는 그것을 확장하는 방법을 알아 냈다.

2152
01:34:55,240 --> 01:34:56,930
그리고 우리는 생각하는 방법을
우리의 핫 키를 제거 할 수 있습니다.

2153
01:34:56,930 --> 01:34:57,820
그리고 이것은 환상적이다.

2154
01:34:57,820 --> 01:34:58,960
그리고 우리는이 좋은 시스템을 얻었다.

2155
01:34:58,960 --> 01:35:02,043
그리고 그것은 우리에게 매우 올바른 투표를 주어진 것
우리는 기록적인 투표 드 속는을 가지고 있기 때문에.

2156
01:35:02,043 --> 01:35:03,130
그것은 DynamoDB의에 내장.

2157
01:35:03,130 --> 01:35:05,380
우리는 조건부 권리에 대해 이야기했다.

2158
01:35:05,380 --> 01:35:08,170
>> 유권자가 오면, 풋
테이블에 삽입,

2159
01:35:08,170 --> 01:35:11,220
그들은 그들의 유권자 ID로 삽입
그들은 또 다른 투표를 삽입 할 경우,

2160
01:35:11,220 --> 01:35:13,320
나는 조건부 쓰기 작업을 수행.

2161
01:35:13,320 --> 01:35:16,960
이 쓰기 만 말
이없는 경우.

2162
01:35:16,960 --> 01:35:19,270
그래서 최대한 빨리 볼로
그 투표의 테이블에 충돌,

2163
01:35:19,270 --> 01:35:20,460
아무도 다른 사람이 될 것 없습니다 것
자신의 투표를 둘 수.

2164
01:35:20,460 --> 01:35:21,634
그리고 그 환상적이다.

2165
01:35:21,634 --> 01:35:23,550
그리고 우리는 증가하고
우리의 후보 카운터.

2166
01:35:23,550 --> 01:35:25,466
그리고 우리는 우리의 일을하고
인구 통계와 모든 것을.

2167
01:35:25,466 --> 01:35:29,110
그러나이 경우 어떻게 내
응용 프로그램은 쓰러져서?

2168
01:35:29,110 --> 01:35:31,350
지금 갑자기 투표의 모든
오고 있으며, 나는

2169
01:35:31,350 --> 01:35:34,840
그들은 처리지고 있다면 모른다
내 분석 및 인구 통계에

2170
01:35:34,840 --> 01:35:36,040
더 이상.

2171
01:35:36,040 --> 01:35:38,462
그리고 때 응용 프로그램
최대 어떻게 다시 온다

2172
01:35:38,462 --> 01:35:41,420
도대체 내가 투표는 무엇을 알 수 있습니까
처리 어디서부터 시작 할까?

2173
01:35:41,420 --> 01:35:44,530
>> 그래서 이것은 진짜 문제 때입니다
이러한 유형의 시나리오를보고 시작합니다.

2174
01:35:44,530 --> 01:35:45,571
어떻게 우리는 그것을 해결합니까?

2175
01:35:45,571 --> 01:35:48,070
우리는 무엇으로 그것을 해결 우리
DynamoDB의 스트림을 호출합니다.

2176
01:35:48,070 --> 01:35:53,470
스트림은 한 번 주문하고,
모든 액세스의 분할 변경 로그

2177
01:35:53,470 --> 01:35:55,700
테이블에 모든 쓰기
테이블에 액세스 할 수 있습니다.

2178
01:35:55,700 --> 01:35:58,810
기록 상관 없음 데이터
표는 스트림에 표시됩니다.

2179
01:35:58,810 --> 01:36:01,815
>> 그것은 기본적으로 24 시간 대기 행렬입니다.

2180
01:36:01,815 --> 01:36:03,690
항목은 스트림을 명중,
그들은 24 시간 동안 살고 있습니다.

2181
01:36:03,690 --> 01:36:05,990
이들은 여러 번 판독 할 수있다.

2182
01:36:05,990 --> 01:36:09,400
배달 보장
단지 스트림에 한 번,

2183
01:36:09,400 --> 01:36:11,180
n 번 판독 될 수있다.

2184
01:36:11,180 --> 01:36:14,910
그래서 그러나 많은 프로세스 당신이 원하는
그 데이터를 사용, 당신은 그것을 소비 할 수 있습니다.

2185
01:36:14,910 --> 01:36:16,350
그것은 모든 업데이트가 나타납니다.

2186
01:36:16,350 --> 01:36:18,455
모든 쓸 것입니다 만
스트림에 한 번 나타납니다.

2187
01:36:18,455 --> 01:36:20,621
그래서 당신은 걱정할 필요가 없습니다
두 번 처리에 대한

2188
01:36:20,621 --> 01:36:22,500
동일한 프로세스에서.

2189
01:36:22,500 --> 01:36:25,350
>> 그것은 엄격하게 항목별로 정렬합니다.

2190
01:36:25,350 --> 01:36:28,180
우리는 시간을 말할 때
주문 및 분할,

2191
01:36:28,180 --> 01:36:30,680
당신은 스트림에 파티션별로 확인할 수 있습니다.

2192
01:36:30,680 --> 01:36:33,169
당신은 순서대로 항목 업데이트를 볼 수 있습니다.

2193
01:36:33,169 --> 01:36:35,210
우리는 보장되지 않습니다
당신이있어 스트림

2194
01:36:35,210 --> 01:36:40,240
모든 트랜잭션을 얻을 것
항목에 걸쳐 순서대로.

2195
01:36:40,240 --> 01:36:42,440
>> 그래서 스트림 나무 등이다.

2196
01:36:42,440 --> 01:36:44,037
우리 모두는 나무 등의 의미를 아십니까?

2197
01:36:44,037 --> 01:36:46,620
나무 등은 당신이 그것을 할 수 있다는 것을 의미합니다
이상, 이상, 또 다시.

2198
01:36:46,620 --> 01:36:48,200
그 결과는 동일 할 것.

2199
01:36:48,200 --> 01:36:49,991
>> 스트림, 나무 등이다
하지만 그들은해야

2200
01:36:49,991 --> 01:36:54,860
출발점에서 연주
당신이 선택하는 곳, 끝으로,

2201
01:36:54,860 --> 01:36:57,950
또는이 발생하지 않습니다
같은 값에.

2202
01:36:57,950 --> 01:36:59,727
>> MongoDB를와 같은 일.

2203
01:36:59,727 --> 01:37:01,560
MongoDB가이 구조를 가지고
그들은 oplog를 호출합니다.

2204
01:37:01,560 --> 01:37:04,140
그것은 동일한 구조이다.

2205
01:37:04,140 --> 01:37:06,500
많은 NoSQL에 데이터베이스
이 구조를 가지고있다.

2206
01:37:06,500 --> 01:37:08,790
그들은 일을하는 데 사용
같은 복제하는

2207
01:37:08,790 --> 01:37:10,475
정확히 우리가 스트림을 함께 할 것입니다.

2208
01:37:10,475 --> 01:37:12,350
청중 : 아마
이단 문제,하지만

2209
01:37:12,350 --> 01:37:13,975
앱 등을 다운 일에 대해 이야기.

2210
01:37:13,975 --> 01:37:16,089
스트림은 보장됩니다
아마도 아래로 갈 수 없다?

2211
01:37:16,089 --> 01:37:18,630
릭 리한 (Houlihan) : 네, 스트림
아래로 가지 않을 보장됩니다.

2212
01:37:18,630 --> 01:37:21,040
우리는 인프라를 관리
뒤에. 자동 스트림

2213
01:37:21,040 --> 01:37:22,498
그들의 오토 스케일링 그룹에 배포합니다.

2214
01:37:22,498 --> 01:37:25,910
우리는 조금을 통해 갈거야
무슨 일에 대한 비트.

2215
01:37:25,910 --> 01:37:30,060
>> 나는 그들이하지 않은 말을 안
아래로 가지 않을 보장.

2216
01:37:30,060 --> 01:37:33,110
요소는 보장
스트림에 표시합니다.

2217
01:37:33,110 --> 01:37:36,740
그리고 스트림에 액세스 할 수 있습니다.

2218
01:37:36,740 --> 01:37:40,580
그래서 무슨 일이 다운되거나 다시 온다
위로는, 그 아래에 발생합니다.

2219
01:37:40,580 --> 01:37:43,844
그것은 괜찮아요 covers--.

2220
01:37:43,844 --> 01:37:46,260
좋아, 당신이 다른 수 있도록
화면 오프보기 유형.

2221
01:37:46,260 --> 01:37:51,040
에 중요한보기 유형
프로그래머는 일반적으로 그 무엇이었다입니까?

2222
01:37:51,040 --> 01:37:52,370
나는 이전보기를 얻을.

2223
01:37:52,370 --> 01:37:55,630
업데이트가 테이블 안타 때거야
스트림에 이전보기를 밀어

2224
01:37:55,630 --> 01:38:02,070
그래서 데이터를 보관, 또는 변경 할 수 있습니다
제어, 변경 확인, 변경

2225
01:38:02,070 --> 01:38:03,600
조치.

2226
01:38:03,600 --> 01:38:07,160
>> 그 후 지금의 새로운 이미지,
보기의 또 다른 유형의 업데이트,

2227
01:38:07,160 --> 01:38:07,660
당신은 얻을 수 있습니다.

2228
01:38:07,660 --> 01:38:09,660
당신은 과거와 이미지 모두를 얻을 수 있습니다.

2229
01:38:09,660 --> 01:38:10,660
어쩌면 둘 다 할 수 있습니다.

2230
01:38:10,660 --> 01:38:11,790
나는 그것이 무엇인지보고 싶어요.

2231
01:38:11,790 --> 01:38:13,290
나는 그것이로 변경 무엇을보고 싶어요.

2232
01:38:13,290 --> 01:38:15,340
>> 나는 준수의 유형이
프로세스의 실행됩니다.

2233
01:38:15,340 --> 01:38:17,430
그것은을 확인해야
이런 일들은 변경할 때,

2234
01:38:17,430 --> 01:38:21,840
그들은 특정 한도 내에서 걸
또는 특정 매개 변수 내에서.

2235
01:38:21,840 --> 01:38:23,840
>> 그리고 어쩌면 내가 만
변경된 것을 알 필요가있다.

2236
01:38:23,840 --> 01:38:26,240
나는 변경 어떤 항목을 걱정하지 않는다.

2237
01:38:26,240 --> 01:38:28,580
내가 알아야 할 필요가 없습니다
무슨 일이 변경된 속성.

2238
01:38:28,580 --> 01:38:30,882
난 그냥 것을 알 필요가
항목이 감동되고있다.

2239
01:38:30,882 --> 01:38:33,340
그래서 이들은 뷰의 종류
당신은 스트림을 얻을

2240
01:38:33,340 --> 01:38:35,960
당신은 상호 작용할 수 있습니다.

2241
01:38:35,960 --> 01:38:37,840
>> 응용 프로그램이
스트림을 소비

2242
01:38:37,840 --> 01:38:39,298
이것은이 작동하는 방식 가지입니다.

2243
01:38:39,298 --> 01:38:42,570
DynamoDB의 클라이언트에 요청
테이블에 데이터를 밀어 넣습니다.

2244
01:38:42,570 --> 01:38:44,750
스트림은 우리가 파편을 부르는에 배포 할 수 있습니다.

2245
01:38:44,750 --> 01:38:47,380
파편의 크기가 조절된다
독립적으로 테이블.

2246
01:38:47,380 --> 01:38:50,660
그들은 완전히 일치하지 않습니다
테이블의 파티션.

2247
01:38:50,660 --> 01:38:52,540
그리고 그 이유는 이유
그들은 줄 때문에

2248
01:38:52,540 --> 01:38:55,430
용량, 전류
테이블의 용량.

2249
01:38:55,430 --> 01:38:57,600
>> 그들은에서 배포 자신의
자신의 오토 스케일링 그룹,

2250
01:38:57,600 --> 01:39:00,800
그들은 따라 밖으로 회전하기 시작
들어오는 얼마나 많은 쓰기에,

2251
01:39:00,800 --> 01:39:03,090
얼마나 많은 re​​ads-- 정말 것은 씁니다.

2252
01:39:03,090 --> 01:39:05,820
거기에 더 reads--하지만없는 방법
많은 쓰기가오고있다.

2253
01:39:05,820 --> 01:39:08,200
>> 그리고 뒷면에
결국, 우리는 무엇을 우리

2254
01:39:08,200 --> 01:39:11,390
KCL, 또는 운동성 클라이언트 라이브러리를 호출합니다.

2255
01:39:11,390 --> 01:39:19,190
운동성은 스트림 데이터 인
아마존에서 가공 기술.

2256
01:39:19,190 --> 01:39:22,040
그리고 스트림은 그에 내장되어 있습니다.

2257
01:39:22,040 --> 01:39:25,670
>> 그래서 당신은 KCL이 활성화 사용
응용 프로그램은 스트림을 읽을 수 있습니다.

2258
01:39:25,670 --> 01:39:28,752
운동성 클라이언트 라이브러리 실제로
당신을 위해 노동자를 관리합니다.

2259
01:39:28,752 --> 01:39:30,460
그리고 그것은 또한 몇 가지를 않습니다
흥미로운 것들.

2260
01:39:30,460 --> 01:39:35,630
그것은 몇 가지 테이블을 생성합니다
당신의 DynamoDB의 테이블에

2261
01:39:35,630 --> 01:39:38,410
어느 아이템을 추적
처리되었다.

2262
01:39:38,410 --> 01:39:41,190
따라서이 방법은이 경우, 다시 떨어지는 경우
그것은 이상 떨어지고 와서 가져

2263
01:39:41,190 --> 01:39:45,570
백업을 서서 어디 확인할 수 있습니다
스트림 처리에이었다.

2264
01:39:45,570 --> 01:39:48,360
>> 그 때 매우 중요합니다
당신이 복제에 대해 얘기하고.

2265
01:39:48,360 --> 01:39:50,350
나는 무엇을 알 필요가
데이터가 처리 된

2266
01:39:50,350 --> 01:39:52,810
어떤 데이터가 아직 처리해야합니다.

2267
01:39:52,810 --> 01:39:57,380
그래서 스트림에 대한 KCL 라이브러리는 것
당신에게 그 많은 기능을 제공합니다.

2268
01:39:57,380 --> 01:39:58,990
그것은 모든 가사의 처리합니다.

2269
01:39:58,990 --> 01:40:01,140
그것은 모든 파편을위한 노동자를 의미합니다.

2270
01:40:01,140 --> 01:40:04,620
이 관리 테이블을 생성
모든 노동자에 대한 모든 파편을위한.

2271
01:40:04,620 --> 01:40:07,560
그리고 그 노동자의 화재로,
그들은 그 테이블을 유지 보수

2272
01:40:07,560 --> 01:40:10,510
그래서 당신은이 기록을 알고
읽고 처리되었습니다.

2273
01:40:10,510 --> 01:40:13,850
그리고 그런 식으로 처리하는 경우
, 죽으면 다시 온라인

2274
01:40:13,850 --> 01:40:17,940
이 이륙 곳은 권리를 재개 할 수 있습니다.

2275
01:40:17,940 --> 01:40:20,850
>> 그래서 우리는이를 사용
교차 영역 복제.

2276
01:40:20,850 --> 01:40:24,680
고객의 많은 필요성이
데이터 테이블의 데이터를 이동 또는 부품

2277
01:40:24,680 --> 01:40:25,920
주위에 다른 지역으로.

2278
01:40:25,920 --> 01:40:29,230
구 지역이 있습니다
전 세계.

2279
01:40:29,230 --> 01:40:32,100
그래서 분명히 .. 내가있을 수 있습니다
아시아에서 사용자가있을 수 있습니다, 사용자

2280
01:40:32,100 --> 01:40:34,150
미국의 동부 해안에.

2281
01:40:34,150 --> 01:40:38,980
서로 다른 데이터가 그
지역적으로 분산 될 필요가있다.

2282
01:40:38,980 --> 01:40:42,510
그리고 어쩌면 사용자는 출발 항공사
미국을 통해 아시아,

2283
01:40:42,510 --> 01:40:45,020
나는 복제 할
그와 함께 자신의 데이터.

2284
01:40:45,020 --> 01:40:49,340
그는 비행기를 얻을 때, 그는이
자신의 모바일 앱을 사용하여 좋은 경험.

2285
01:40:49,340 --> 01:40:52,360
>> 당신은 교차 영역을 사용할 수 있습니다
복제 라이브러리는이 작업을 수행합니다.

2286
01:40:52,360 --> 01:40:55,730
기본적으로 우리는이
두 가지 기술을 제공했다.

2287
01:40:55,730 --> 01:40:59,400
하나는 당신이 할 수있는 콘솔 응용 프로그램의
자신의 EC2 인스턴스에 서서.

2288
01:40:59,400 --> 01:41:01,240
그것은 순수한 복제를 실행합니다.

2289
01:41:01,240 --> 01:41:02,720
그리고 우리는 당신이 라이브러리를했다.

2290
01:41:02,720 --> 01:41:06,070
라이브러리를 구축하는 데 사용할 수있는
자신의 응용 프로그램 사용자의 경우

2291
01:41:06,070 --> 01:41:10,740
그와 함께 미친 일을 할 data--
필터는 그것의 일부만을 복제

2292
01:41:10,740 --> 01:41:14,120
데이터를 회전으로 ​​이동
다른 테이블, 등등 등등.

2293
01:41:14,120 --> 01:41:18,700

2294
01:41:18,700 --> 01:41:20,520
그래서 그 모양을 가지입니다.

2295
01:41:20,520 --> 01:41:23,690
>> DynamoDB의 스트림이 될 수 있습니다
우리는 람다를 부르는 처리.

2296
01:41:23,690 --> 01:41:27,394
우리는 이벤트에 대해 조금 언급
구동 애플리케이션 아키텍처.

2297
01:41:27,394 --> 01:41:28,810
람다는의 핵심 구성 요소입니다.

2298
01:41:28,810 --> 01:41:32,840
람다는 수요에 발생 코드
특정 이벤트에 대한 응답으로.

2299
01:41:32,840 --> 01:41:36,020
이러한 이벤트들 중 하나가 될 수있다
스트림에 나오는 기록.

2300
01:41:36,020 --> 01:41:39,100
기록 스트림에 나타나는 경우,
우리는이 자바 함수를 호출합니다.

2301
01:41:39,100 --> 01:41:44,980
음,이 자바 스크립트 및 람다입니다
Node.js, 자바, 파이썬 지원

2302
01:41:44,980 --> 01:41:47,820
곧 지원
다른 언어뿐만 아니라.

2303
01:41:47,820 --> 01:41:50,940
그리고 그것은 순수한 코드의 말에 충분하다.

2304
01:41:50,940 --> 01:41:53,610
자바에서 쓰기, 당신은 클래스를 정의합니다.

2305
01:41:53,610 --> 01:41:55,690
당신은 람다에 JAR를 위로 밀어 넣습니다.

2306
01:41:55,690 --> 01:42:00,200
그리고 당신은 어떤 클래스 지정
이벤트에 대한 응답으로 호출합니다.

2307
01:42:00,200 --> 01:42:04,770
그리고 람다 인프라
그 뒤에 그 코드를 실행합니다.

2308
01:42:04,770 --> 01:42:06,730
>> 그 코드를 처리 할 수​​ 있습니다
스트림 오프 기록.

2309
01:42:06,730 --> 01:42:08,230
그것은 그것으로 원하는 모든 작업을 수행 할 수 있습니다.

2310
01:42:08,230 --> 01:42:11,650
이 특정 예에서, 모든 우리는있어
정말 속성을 로깅하고.

2311
01:42:11,650 --> 01:42:13,480
그러나 이것은 단지 코드입니다.

2312
01:42:13,480 --> 01:42:15,260
코드는 바로, 아무것도 할 수 있습니까?

2313
01:42:15,260 --> 01:42:16,600
>> 그래서 당신은 그 데이터를 회전 할 수 있습니다.

2314
01:42:16,600 --> 01:42:18,160
당신은 파생 뷰를 생성 할 수 있습니다.

2315
01:42:18,160 --> 01:42:21,160
이 문서 구조 인 경우에,
당신은 구조를 평평하게 할 수 있습니다.

2316
01:42:21,160 --> 01:42:24,300
당신은 대체 인덱스를 생성 할 수 있습니다.

2317
01:42:24,300 --> 01:42:27,100
모든 종류의 것들을 당신이 할 수있는
DynamoDB의 스트림으로한다.

2318
01:42:27,100 --> 01:42:28,780
>> 정말, 그 그 모습이다.

2319
01:42:28,780 --> 01:42:29,940
그래서 당신은 이러한 업데이트는 오는 얻는다.

2320
01:42:29,940 --> 01:42:31,190
그들은 문자열을오고있어.

2321
01:42:31,190 --> 01:42:32,720
그들은 람다 함수에 의해 판독하고 있습니다.

2322
01:42:32,720 --> 01:42:37,480
그들은 데이터를 회전하고 있고
파생 테이블에 그것을 밀어,

2323
01:42:37,480 --> 01:42:42,200
변화의 외부 시스템에 통지,
및 ElastiCache로 데이터를 밀어.

2324
01:42:42,200 --> 01:42:45,900
>> 우리는 캐시를 넣어하는 방법에 대해 이야기
그 판매에 대한 데이터베이스의 앞에

2325
01:42:45,900 --> 01:42:46,450
대본.

2326
01:42:46,450 --> 01:42:50,049
그럼 무슨 일이 있다면
항목 설명을 업데이트?

2327
01:42:50,049 --> 01:42:52,340
글쎄, 내가 가진 경우 람다
함수는 해당 테이블에서 실행

2328
01:42:52,340 --> 01:42:55,490
내가 항목에 대한 설명을 업데이트 할 경우, 그것은거야
스트림 오프 레코드를 선택,

2329
01:42:55,490 --> 01:42:58,711
그리고 ElastiCache를 업데이트 할 것이다
새 데이터 인스턴스입니다.

2330
01:42:58,711 --> 01:43:00,460
그래서 많은입니다
우리는 람다와 함께 무엇을 할.

2331
01:43:00,460 --> 01:43:02,619
그것은, 커넥터 연결 코드입니다.

2332
01:43:02,619 --> 01:43:04,410
그리고 실제로 제공
발사 할 수있는 능력

2333
01:43:04,410 --> 01:43:07,930
매우 복잡한 응용 프로그램을 실행하는 데
전용 서버없이

2334
01:43:07,930 --> 01:43:10,371
정말 멋진 인프라.

2335
01:43:10,371 --> 01:43:13,100
>> 그럼으로 돌아 가자 우리
실시간 투표 아키텍처.

2336
01:43:13,100 --> 01:43:17,984
이 새로운 및 향상 우리의
스트림과 KCL은 응용 프로그램을 활성화.

2337
01:43:17,984 --> 01:43:20,150
같은, 우리가 할 수있는 이전과
선거의 규모를 처리 할 수​​ 있습니다.

2338
01:43:20,150 --> 01:43:21,100
우리는이를 좋아한다.

2339
01:43:21,100 --> 01:43:24,770
우리는 분산 집결을하고있는
여러 버킷에서.

2340
01:43:24,770 --> 01:43:26,780
우리는 낙관적 잠금이 일어나고 있어요.

2341
01:43:26,780 --> 01:43:30,192
우리는 우리의 유권자를 유지할 수 있습니다
그들의 표를 변경하는.

2342
01:43:30,192 --> 01:43:31,400
그들은 단지 한 번만 투표 할 수 있습니다.

2343
01:43:31,400 --> 01:43:32,880
이 환상적이다.

2344
01:43:32,880 --> 01:43:35,895
실시간 내결함성
이제 확장 가능한 통합.

2345
01:43:35,895 --> 01:43:38,270
일이 넘어지면, 그것을
그 자체를 다시 시작 위치를 알고

2346
01:43:38,270 --> 01:43:41,300
이 때문에 백업을 때
우리는 KCL 응용 프로그램을 사용하고 있습니다.

2347
01:43:41,300 --> 01:43:45,700
그리고 우리는 또한 사용할 수 있습니다
KCL 애플리케이션은 데이터를 밖으로 밀어

2348
01:43:45,700 --> 01:43:48,820
기타에 대한 적색 편이하기
응용 프로그램 분석, 또는 사용

2349
01:43:48,820 --> 01:43:51,990
탄성 MapReduce를 실행합니다
오프 실시간 스트리밍 집계

2350
01:43:51,990 --> 01:43:53,180
데이터의.

2351
01:43:53,180 --> 01:43:55,480
>> 그래서 이러한 것들을 우리는
많은 이야기하지 않았습니다.

2352
01:43:55,480 --> 01:43:57,375
그러나 그들은 추가있어
올 기술

2353
01:43:57,375 --> 01:44:00,310
당신이 찾고있는 경우에 부담하는
이러한 유형의 시나리오에서.

2354
01:44:00,310 --> 01:44:03,160
>> 좋아, 그 약 그래서
DynamoDB의 스트림을 분석.

2355
01:44:03,160 --> 01:44:05,340
당신은 드 속는를 수집 할 수 있습니다
데이터, 모든 종류의 작업을 수행

2356
01:44:05,340 --> 01:44:09,490
좋은 물건, 집계 데이터
메모리는, 그 파생 테이블을 만들 수 있습니다.

2357
01:44:09,490 --> 01:44:13,110
즉 거대한 사용 사례이다
그 많은 고객

2358
01:44:13,110 --> 01:44:16,950
중첩을 고려하여 참여
그 JSON 문서의 속성

2359
01:44:16,950 --> 01:44:18,946
추가 인덱스를 작성.

2360
01:44:18,946 --> 01:44:21,680

2361
01:44:21,680 --> 01:44:23,150
>> 우리는 끝이야.

2362
01:44:23,150 --> 01:44:26,689
나와 함께 베어링 주셔서 감사합니다.

2363
01:44:26,689 --> 01:44:28,480
그럼 대해 얘기하자
참조 아키텍처.

2364
01:44:28,480 --> 01:44:33,440
DynamoDB의 지금의 중앙에 앉아
AWS 인프라의 많은.

2365
01:44:33,440 --> 01:44:37,090
기본적으로 당신은 그것을 연결할 수 있습니다
아무것도까지 당신이 원하는.

2366
01:44:37,090 --> 01:44:45,600
응용 프로그램은 디나모 포함하여 내장
람다, ElastiCache, CloudSearch,

2367
01:44:45,600 --> 01:44:49,890
탄성 속으로 데이터를 푸시
맵리 듀스, DynamoDB의에서 수입 수출

2368
01:44:49,890 --> 01:44:52,370
(S3), 워크 플로우의 모든 종류의에.

2369
01:44:52,370 --> 01:44:54,120
그러나 아마 최고의
에 대해 이야기하는 것은,

2370
01:44:54,120 --> 01:44:56,119
이것은 정말 무엇인가
흥미로운 때입니다

2371
01:44:56,119 --> 01:44:58,350
이벤트 기반 응용 프로그램에 대해 얘기.

2372
01:44:58,350 --> 01:45:00,300
>> 이 예입니다
내부 프로젝트

2373
01:45:00,300 --> 01:45:04,850
우리는 우리가 실제로있어 어디에 있는지
출판은 설문 조사 결과를 수집합니다.

2374
01:45:04,850 --> 01:45:07,700
이메일 링크 그래서
우리는 거기거야, 보내

2375
01:45:07,700 --> 01:45:11,350
작은 링크 말하는 클릭 수
여기에 설문 조사에 응답한다.

2376
01:45:11,350 --> 01:45:14,070
그리고 때 사람이 클릭
링크는 어떻게됩니까

2377
01:45:14,070 --> 01:45:18,020
그들은 안전한 풀다운입니다
(S3)에서 HTML 설문 조사 양식.

2378
01:45:18,020 --> 01:45:18,980
어떤 서버가 없습니다.

2379
01:45:18,980 --> 01:45:20,600
이것은 단지 S3 객체입니다.

2380
01:45:20,600 --> 01:45:22,770
>> 그 형태는 온다
브라우저에서로드합니다.

2381
01:45:22,770 --> 01:45:24,240
그것은 백본 있어요.

2382
01:45:24,240 --> 01:45:30,160
그것은 복잡한 자바 스크립트있어
그것이 실행합니다.

2383
01:45:30,160 --> 01:45:33,557
그래서 그것은 매우 풍부한 응용 프로그램입니다
클라이언트의 브라우저에서 실행.

2384
01:45:33,557 --> 01:45:36,390
그들은 아니에요 모르겠어요
백 엔드 서버와 상호 작용.

2385
01:45:36,390 --> 01:45:38,220
이 시점에서, 모든 브라우저입니다.

2386
01:45:38,220 --> 01:45:41,780
>> 그들은에 결과를 게시 무엇
우리는 아마존 API 게이트웨이를 호출합니다.

2387
01:45:41,780 --> 01:45:46,270
API 게이트웨이는 단순히 웹 API입니다
당신은 정의하고 후크 할 수

2388
01:45:46,270 --> 01:45:47,760
무엇에 당신이 원하는.

2389
01:45:47,760 --> 01:45:50,990
이 특정한 경우에, 우리는있어
람다 함수에 매여.

2390
01:45:50,990 --> 01:45:54,797
>> 그래서 내 POST 동작은
아무 서버에서 일어나는.

2391
01:45:54,797 --> 01:45:56,380
기본적으로 그 API 게이트웨이가 앉아있다.

2392
01:45:56,380 --> 01:45:58,770
그것은 나에게 사람들까지 비용이 들지 않습니다
바로 여기에 올리기 시작?

2393
01:45:58,770 --> 01:46:00,269
람다 함수는 단지 거기에 앉아있다.

2394
01:46:00,269 --> 01:46:03,760
그리고 그것은 때까지 나에게 아무것도 비용이 없습니다
사람들은 타격 시작합니다.

2395
01:46:03,760 --> 01:46:07,270
그래서 당신은 볼륨으로 볼 수 있습니다
요금이 올 때 증가, 그건.

2396
01:46:07,270 --> 01:46:09,390
나는 서버 7/24을 운영하지 않는 경우.

2397
01:46:09,390 --> 01:46:12,310
>> 그래서 양식을 당겨
아래 버킷 중,

2398
01:46:12,310 --> 01:46:15,719
내가 API를 통해 게시
람다 함수에 게이트웨이.

2399
01:46:15,719 --> 01:46:17,510
그리고 람다
기능은 당신이 알고 말한다

2400
01:46:17,510 --> 01:46:20,600
무엇을, 나는 몇 가지 PIIS있어, 일부
개인 식별 정보

2401
01:46:20,600 --> 01:46:21,480
이러한 응답에.

2402
01:46:21,480 --> 01:46:23,020
나는 사용자에서 오는 의견을 얻었다.

2403
01:46:23,020 --> 01:46:24,230
나는 이메일 주소를 가지고있다.

2404
01:46:24,230 --> 01:46:26,190
나는 사용자 이름을 가지고있다.

2405
01:46:26,190 --> 01:46:27,810
>> 날이를 분할 할 수 있습니다.

2406
01:46:27,810 --> 01:46:30,280
나는 몇 가지를 생성하는거야
이 기록 오프 메타 데이터.

2407
01:46:30,280 --> 01:46:32,850
그리고 밀어거야
DynamoDB의에 메타 데이터.

2408
01:46:32,850 --> 01:46:36,059
그리고 나는 모든 데이터를 암호화 할 수
내가 원하는 경우 DynamoDB의에 밀어 넣습니다.

2409
01:46:36,059 --> 01:46:38,600
하지만이에, 나를 위해 쉽게
앞서 말을 이동, 케이스를 사용하여,

2410
01:46:38,600 --> 01:46:42,800
나는 원시 데이터를 밀어거야
암호화 된 S3 버킷에.

2411
01:46:42,800 --> 01:46:47,240
그래서 나는 S3 서버 측에 내장 사용하십시오
암호화 및 아마존의 키 관리

2412
01:46:47,240 --> 01:46:51,600
그래서 서비스 나는 키가 그
일정한 간격으로 회전 할 수 있습니다,

2413
01:46:51,600 --> 01:46:55,010
나는 그 PII 데이터를 보호 할 수 있습니다
이 모든 워크 플로우의 일환으로.

2414
01:46:55,010 --> 01:46:55,870
>> 그래서 내가 무슨 짓을 한거야?

2415
01:46:55,870 --> 01:47:00,397
난 그냥 전체를 배치했습니다
응용 프로그램, 그리고 나는 어떤 서버가 없습니다.

2416
01:47:00,397 --> 01:47:02,980
그래서 이벤트가 응용 프로그램을 구동 무엇인가
아키텍처는 당신을 위해 않습니다.

2417
01:47:02,980 --> 01:47:05,730
>> 지금 당신이 생각하는 경우
이 항아리에 대한 사용 사례

2418
01:47:05,730 --> 01:47:08,730
우리는 내가 이야기하고 다른 고객이
약이 정확한 아키텍처 사람

2419
01:47:08,730 --> 01:47:14,560
급격하게 큰 캠페인을 실행하는 사람들
이보고 오, 갈 수 있습니다.

2420
01:47:14,560 --> 01:47:17,840
지금, 그들이 할 수 있기 때문에
기본적으로 그것을 밀어,

2421
01:47:17,840 --> 01:47:21,900
그냥 앉아 그 캠페인을하자
거기 시작, 그리고까지

2422
01:47:21,900 --> 01:47:24,400
에 대한 그림을 걱정할 필요가
기반 시설의 종류

2423
01:47:24,400 --> 01:47:26,120
이를 지원하기 위해이 될 것입니다.

2424
01:47:26,120 --> 01:47:28,600
그리고 가능한 한 빨리
이 캠페인은, 이루어집니다

2425
01:47:28,600 --> 01:47:31,520
그것은 인프라처럼
다만 즉시 사라집니다

2426
01:47:31,520 --> 01:47:33,680
정말이 때문에
어떤 인프라가 없습니다.

2427
01:47:33,680 --> 01:47:35,660
그것은 람다에 앉아 그냥 코드입니다.

2428
01:47:35,660 --> 01:47:38,560
그것은 DynamoDB의에 앉아 그냥 데이터입니다.

2429
01:47:38,560 --> 01:47:41,340
그것은 놀라운 방법입니다
응용 프로그램을 구축 할 수 있습니다.

2430
01:47:41,340 --> 01:47:43,970
>> 청중 : 그래서 더 그것을이다
임시는 것보다

2431
01:47:43,970 --> 01:47:45,740
그것은 실제의 서버에 저장 되었다면?

2432
01:47:45,740 --> 01:47:46,823
>> 릭 리한 (Houlihan) : 물론입니다.

2433
01:47:46,823 --> 01:47:49,190
해당 서버 인스턴스 때문에
7/24 일해야 할 것입니다.

2434
01:47:49,190 --> 01:47:51,954
그것은 사용할 수있다
누군가에 응답 할.

2435
01:47:51,954 --> 01:47:52,620
그럼 어떻게 됐을까?

2436
01:47:52,620 --> 01:47:55,410
(S3)는 7/24 사용할 수 있습니다.

2437
01:47:55,410 --> 01:47:57,100
S3는 항상 응답합니다.

2438
01:47:57,100 --> 01:47:59,320
그리고 S3는 아주, 아주 좋은 것입니다
개체를 제공하는시.

2439
01:47:59,320 --> 01:48:02,590
그 객체는 HTML 파일, 또는 수
자바 스크립트 파일, 또는 무엇이든 당신이 원하는.

2440
01:48:02,590 --> 01:48:07,430
당신은 매우 풍부한 웹 응용 프로그램을 실행할 수 있습니다
S3 버킷에서, 사람들은 않습니다.

2441
01:48:07,430 --> 01:48:10,160
>> 그리고 그 생각은 여기
멀리 방법에서 얻을 수 있습니다

2442
01:48:10,160 --> 01:48:11,270
우리는 그것에 대해 생각하는 데 사용됩니다.

2443
01:48:11,270 --> 01:48:14,270
우리 모두가 생각하는 데 사용
서버와 호스트의 조건.

2444
01:48:14,270 --> 01:48:16,580
그것은 더 이상 그것에 대해 아니에요.

2445
01:48:16,580 --> 01:48:19,310
그것은 코드와 인프라에 관​​하여이다.

2446
01:48:19,310 --> 01:48:22,470
클라우드로 코드를 배포하고
구름이 당신을 위해 그것을 실행하자.

2447
01:48:22,470 --> 01:48:24,980
그리고 그 AWS가해야 할 노력거야.

2448
01:48:24,980 --> 01:48:29,690
>> 청중 : 중간에서 골드 박스 그래서
API의 게이트웨이, 서버와 같은 아닙니다

2449
01:48:29,690 --> 01:48:30,576
대신 그냥 ...입니다

2450
01:48:30,576 --> 01:48:32,850
>> 릭 리한 (Houlihan) : 당신은 생각할 수
서버 외관으로의.

2451
01:48:32,850 --> 01:48:38,040
이 모두는 HTTP를 취할 것입니다
요청하고 다른 프로세스에 매핑.

2452
01:48:38,040 --> 01:48:39,192
즉,이하는 모두이다.

2453
01:48:39,192 --> 01:48:41,525
이 경우, 우리는 매핑하는
그 람다 함수.

2454
01:48:41,525 --> 01:48:44,119

2455
01:48:44,119 --> 01:48:45,410
좋아, 그래서 내가 가진 전부입니다.

2456
01:48:45,410 --> 01:48:46,190
대단히 감사합니다.

2457
01:48:46,190 --> 01:48:46,800
감사합니다.

2458
01:48:46,800 --> 01:48:48,100
나는 우리가 시간이 지남에 조금 원하는 것을 알고있다.

2459
01:48:48,100 --> 01:48:49,980
그리고 희망 너희들은있어
정보의 조금

2460
01:48:49,980 --> 01:48:51,410
오늘 멀리 걸릴 수 있습니다.

2461
01:48:51,410 --> 01:48:53,520
내가 간다면 내가 사과
당신의 머리의 일부를 통해,

2462
01:48:53,520 --> 01:48:56,697
하지만 좋은 많이있다
기본적인 기초 지식

2463
01:48:56,697 --> 01:48:58,280
내가 생각하는 당신을 위해 매우 중요합니다.

2464
01:48:58,280 --> 01:48:59,825
그래서 저를 갖는 주셔서 감사합니다.

2465
01:48:59,825 --> 01:49:00,325
[박수 갈채]

2466
01:49:00,325 --> 01:49:02,619
청중 : [들리지]
당신이 말하는 때이다

2467
01:49:02,619 --> 01:49:05,160
당신은 일을 통해 가야했다
처음부터 끝까지

2468
01:49:05,160 --> 01:49:07,619
오른쪽 값을 얻을 수
또는 동일한 값,

2469
01:49:07,619 --> 01:49:09,410
방법 것 값
[들리지] 경우 변경합니다.

2470
01:49:09,410 --> 01:49:10,480
>> 릭 리한 (Houlihan) : 아, 멱등?

2471
01:49:10,480 --> 01:49:11,800
값은 어떻게 변경할 것인가?

2472
01:49:11,800 --> 01:49:15,180
음, 때문에에게 나는 실행되지 않은 경우
그 모든 길의 끝,

2473
01:49:15,180 --> 01:49:19,770
그때 나는 변화 모르겠어요
마지막 마일에 만들어졌다.

2474
01:49:19,770 --> 01:49:22,144
그것은을 할 수 없을거야
내가 본 것과 같은 데이터.

2475
01:49:22,144 --> 01:49:24,560
청중 : 아, 그래서 그냥
전체 입력을 못 했어.

2476
01:49:24,560 --> 01:49:24,770
릭 리한 (Houlihan) : 오른쪽.

2477
01:49:24,770 --> 01:49:26,895
당신은 처음부터 가야
끝으로, 다음 그건

2478
01:49:26,895 --> 01:49:29,280
일관성있는 상태가 될 것.

2479
01:49:29,280 --> 01:49:31,520
시원한.

2480
01:49:31,520 --> 01:49:35,907
>> 청중 : 당신이 우리를 보였다 그래서 DynamoDB의
문서 나 키 값을 수행 할 수 있습니다.

2481
01:49:35,907 --> 01:49:38,740
그리고 우리는 많은 시간을 보냈다
해시 및 방법과 키 값

2482
01:49:38,740 --> 01:49:40,005
그것을 주변 플립합니다.

2483
01:49:40,005 --> 01:49:43,255
당신이 그 테이블에서 보았을 때,이다
문서 접근 남기고?

2484
01:49:43,255 --> 01:49:44,600
>> 릭 리한 (Houlihan) : 나는 않을 것
를 뒤에두고 말한다.

2485
01:49:44,600 --> 01:49:45,855
>> 청중 : 그들은 짓이야에서 분리

2486
01:49:45,855 --> 01:49:49,140
>> 릭 리한 (Houlihan) : 문서로
접근, DynamoDB의에서 문서 유형

2487
01:49:49,140 --> 01:49:50,880
또 다른 속성으로 생각된다.

2488
01:49:50,880 --> 01:49:53,560
그것은 포함 된 속성의
계층 적 데이터 구조.

2489
01:49:53,560 --> 01:49:56,980
그리고 쿼리,
당신은 속성을 사용할 수 있습니다

2490
01:49:56,980 --> 01:49:59,480
객체 표기법을 사용하여 해당 개체의.

2491
01:49:59,480 --> 01:50:03,562
그래서 중첩 필터링 할 수 있습니다
JSON 문서의 속성입니다.

2492
01:50:03,562 --> 01:50:05,520
청중 : 그래서 어떤 시간 전
문서 접근을,

2493
01:50:05,520 --> 01:50:07,906
나는 종류의 tabular--에 도달 할 수 있습니다

2494
01:50:07,906 --> 01:50:08,780
청중 : 물론입니다.

2495
01:50:08,780 --> 01:50:09,800
청중 : --indexes과
당신은 단지 이야기 일.

2496
01:50:09,800 --> 01:50:11,280
릭 리한 (Houlihan) : 네,
인덱스와 모든 것을,

2497
01:50:11,280 --> 01:50:13,363
때 인덱스 원하는
JSON의 특성,

2498
01:50:13,363 --> 01:50:18,230
우리가 그렇게 할 거라고 방법은 경우입니다
당신은 JSON 객체 또는 문서를 삽입

2499
01:50:18,230 --> 01:50:20,780
디나모으로, 당신은 스트림을 사용합니다.

2500
01:50:20,780 --> 01:50:22,400
입력 스트림을 판독한다.

2501
01:50:22,400 --> 01:50:24,340
당신은 JSON 것을 얻을 것
개체 및 확인을 말하고 싶지만,

2502
01:50:24,340 --> 01:50:26,030
내가 인덱싱 할 속성은 무엇인가?

2503
01:50:26,030 --> 01:50:28,717
>> 당신은 파생 테이블을 만듭니다.

2504
01:50:28,717 --> 01:50:30,300
이제 그것이 지금 작동하는 방식이다.

2505
01:50:30,300 --> 01:50:32,650
우리는 색인을 허용하지 않습니다
직접 그 속성.

2506
01:50:32,650 --> 01:50:33,520
>> 청중 : 문서를 Tabularizing.

2507
01:50:33,520 --> 01:50:36,230
>> 릭 리한 (Houlihan) : 정확히, 평탄화
그것은 정확히 그것을 tabularizing.

2508
01:50:36,230 --> 01:50:37,415
그것은 당신이 함께 할거야.

2509
01:50:37,415 --> 01:50:37,860
>> 청중 : 감사합니다.

2510
01:50:37,860 --> 01:50:39,609
>> 릭 리한 (Houlihan) : 그래,
절대적으로, 감사합니다.

2511
01:50:39,609 --> 01:50:42,240
청중 : 그래서 가지의
몽고는 레디 스의 classifers을 준수합니다.

2512
01:50:42,240 --> 01:50:43,990
>> 릭 리한 (Houlihan) : 네,
이 같은 많은입니다.

2513
01:50:43,990 --> 01:50:45,940
즉,에 대한 좋은 설명이다.

2514
01:50:45,940 --> 01:50:47,490
시원한.

2515
01:50:47,490 --> 01:50:49,102