1
00:00:00,000 --> 00:00:04,969
>> [音楽再生]

2
00:00:04,969 --> 00:00:06,010
RICKフーリハン：すべての権利。

3
00:00:06,010 --> 00:00:06,600
皆さん、こんにちは。

4
00:00:06,600 --> 00:00:07,670
私の名前はリックフーリハンです。

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
私は、クラウドシステムでは8特許を持っています
仮想化、マイクロプロセッサ設計、

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
Googleのあなたの場合は、これを参照してくださいよ。

45
00:02:08,360 --> 00:02:11,675
これは、保持されているデータの構造化されたセットです
特に一台のコンピュータで

46
00:02:11,675 --> 00:02:13,600
さまざまな方法でアクセス可能です。

47
00:02:13,600 --> 00:02:16,992
私はそれが良いことだと仮定します
現代のデータベースの定義。

48
00:02:16,992 --> 00:02:19,450
しかし、私はので、それを好きではありません
それは物事のカップルを意味します。

49
00:02:19,450 --> 00:02:20,935
それは以下の構造を意味しています。

50
00:02:20,935 --> 00:02:23,120
そしてそれは、コンピュータ上にあることを意味します。

51
00:02:23,120 --> 00:02:25,750
そして、データベースはしませんでした
常にコンピュータ上に存在します。

52
00:02:25,750 --> 00:02:28,020
データベースは、実際には多くの方法で存在していました。

53
00:02:28,020 --> 00:02:32,000
>> のだから、より良い定義
データベースには、このようなものです。

54
00:02:32,000 --> 00:02:34,786
データベースが構成されています
管理、保存するためのメカニズム、

55
00:02:34,786 --> 00:02:35,910
そして、の情報を取得します。

56
00:02:35,910 --> 00:02:36,868
これはAbout.comからです。

57
00:02:36,868 --> 00:02:42,080
だから私は本当にため、交渉をこれが好き
リポジトリ中のデータベースについて、

58
00:02:42,080 --> 00:02:44,800
のリポジトリ
情報、必ずしも

59
00:02:44,800 --> 00:02:46,780
コンピュータに座って何か。

60
00:02:46,780 --> 00:02:49,290
そして歴史を通して、我々
常にコンピューターを持っていませんでした。

61
00:02:49,290 --> 00:02:52,110
>> 今、私は平均を求めるなら
開発者は、今日は何です

62
00:02:52,110 --> 00:02:54,770
データベースには、それは私が得る答えです。

63
00:02:54,770 --> 00:02:56,070
どこか私はものを固執することができます。

64
00:02:56,070 --> 00:02:56,670
右？

65
00:02:56,670 --> 00:02:58,725
そして、それは本当です。

66
00:02:58,725 --> 00:02:59,600
しかし、それは残念です。

67
00:02:59,600 --> 00:03:02,700
データベースが本当にあるので
現代のアプリの基盤。

68
00:03:02,700 --> 00:03:04,810
これは、財団の
すべてのアプリケーションの。

69
00:03:04,810 --> 00:03:07,240
そして、あなたはそれを構築する方法
データベース、あなたはどのように構造化

70
00:03:07,240 --> 00:03:11,750
そのデータがどのようにを決定しようとしています
あなたがスケールとしてアプリケーションが実行されます。

71
00:03:11,750 --> 00:03:14,640
>> だから、私の仕事、今日の多く
何を扱っています

72
00:03:14,640 --> 00:03:17,180
ときに、開発者が起こります
このアプローチを取ります

73
00:03:17,180 --> 00:03:19,510
そして余波を扱います
その出願の

74
00:03:19,510 --> 00:03:24,966
今元を超えてスケ​​ーリングされます
悪いデザインの意図と苦しみ。

75
00:03:24,966 --> 00:03:26,840
だから、うまくいけば、ときに
今日歩いて、あなたはよ

76
00:03:26,840 --> 00:03:29,010
のツールのカップルを持っています
あなたをしておこうあなたのベルト

77
00:03:29,010 --> 00:03:32,566
それらの同じ間違いを犯すから。

78
00:03:32,566 --> 00:03:33,066
大丈夫。

79
00:03:33,066 --> 00:03:36,360
それでは、少し説明しましょう
データベース技術のタイムライン。

80
00:03:36,360 --> 00:03:38,830
私は私が読んだと思います
記事ではないことずっと前に

81
00:03:38,830 --> 00:03:43,020
それはlines--に何かを言いました
それは非常に詩的な声明です。

82
00:03:43,020 --> 00:03:46,590
それは言っ歴史
データの処理であります

83
00:03:46,590 --> 00:03:49,350
ハイウォーターマークの完全な
データ豊富なの。

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

85
00:03:49,920 --> 00:03:52,532
今、私はそれが一種の真のだと思います。

86
00:03:52,532 --> 00:03:54,990
しかし、私は実際にされているように見えます
履歴は実際に満たされています

87
00:03:54,990 --> 00:03:56,820
データ圧の高い透かしを持ちます。

88
00:03:56,820 --> 00:04:00,040
のデータ・レートため
摂取がダウンすることはありません。

89
00:04:00,040 --> 00:04:01,360
それだけ上がります。

90
00:04:01,360 --> 00:04:03,670
>> そして、革新は場合に発生します
我々は、データの圧力を参照してくださいします

91
00:04:03,670 --> 00:04:07,825
あるデータ量であります
今のシステムに入ってくるインチ

92
00:04:07,825 --> 00:04:12,027
そして、それを処理することはできません
効率的に時間やコストのいずれかで。

93
00:04:12,027 --> 00:04:14,110
我々が開始するとき、それはです
データ圧力を見て。

94
00:04:14,110 --> 00:04:15,920
>> だから私たちが見る時
最初のデータベース、この

95
00:04:15,920 --> 00:04:17,180
私たちの耳の間であったものです。

96
00:04:17,180 --> 00:04:18,310
私たちはすべてのそれを持って生まれています。

97
00:04:18,310 --> 00:04:19,194
それは素敵なデータベースです。

98
00:04:19,194 --> 00:04:21,110
これは、高可用性を持っています。

99
00:04:21,110 --> 00:04:21,959
それは常にオンです。

100
00:04:21,959 --> 00:04:23,930
あなたはいつもそれを得ることができます。

101
00:04:23,930 --> 00:04:24,890
>> しかし、それは、単一のユーザーです。

102
00:04:24,890 --> 00:04:26,348
私はあなたと私の考えを共有することはできません。

103
00:04:26,348 --> 00:04:28,370
あなたは私の考えを得ることができません
あなたがそれらをしたいとき。

104
00:04:28,370 --> 00:04:30,320
そして、彼らの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
どこに処理するために8年かかりました。

132
00:05:34,005 --> 00:05:36,350
>> さて、8 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
>> 今、その結果として、データ
どのactually--ました

167
00:07:10,870 --> 00:07:14,960
あなたは、このデータを直接アクセスしました
あなたがそれを保存された方法に依存。

168
00:07:14,960 --> 00:07:17,825
だから私はテープにデータを置く場合、
私は直線的にデータにアクセスしていました。

169
00:07:17,825 --> 00:07:20,475
私は、全体のロールしなければなりませんでした
テープは、すべてのデータにアクセスします。

170
00:07:20,475 --> 00:07:22,600
私はパンチのデータを置く場合
カードは、私はそれをアクセスすることができました

171
00:07:22,600 --> 00:07:26,270
もう少しランダムで
ファッション、そうでないかもしれないとしてすぐに。

172
00:07:26,270 --> 00:07:30,770
>> しかし、どのように、私たちには限界がありました
保存した方法に基づいてデータへのアクセス。

173
00:07:30,770 --> 00:07:32,890
そして、これが問題でした
50年代に入ります。

174
00:07:32,890 --> 00:07:37,890
繰り返しますが、私たちのようにそれを見始めることができます
処理するための新技術を開発

175
00:07:37,890 --> 00:07:41,670
右側には、データを開きます
新たなソリューションのためにドア、

176
00:07:41,670 --> 00:07:45,852
新しいプログラムのために、新しいです
そのデータのためのアプリケーション。

177
00:07:45,852 --> 00:07:47,810
そして実際に、ガバナンス
その理由であったかもしれません

178
00:07:47,810 --> 00:07:49,435
なぜ我々は、これらのシステムの一部を開発しました。

179
00:07:49,435 --> 00:07:52,290
しかし、ビジネスは急速になりました
進化の背後にあるドライバ

180
00:07:52,290 --> 00:07:54,720
現代のデータベースのと
近代的なファイルシステム。

181
00:07:54,720 --> 00:07:56,870
>> 次の事だから
50年代に思い付きました

182
00:07:56,870 --> 00:08:00,780
ファイルシステムであり、
ランダム・アクセス・ストレージの開発。

183
00:08:00,780 --> 00:08:02,050
これはきれいでした。

184
00:08:02,050 --> 00:08:06,230
さて、突然、我々は我々を置くことができます
どこでもこれらのハードドライブ上のファイル

185
00:08:06,230 --> 00:08:09,760
我々は、ランダムにこのデータにアクセスすることができます。

186
00:08:09,760 --> 00:08:11,950
我々はそれを解析することができます
ファイルのうち情報。

187
00:08:11,950 --> 00:08:14,920
そして、私たちは、世界のすべての解決しました
データ処理に問題。

188
00:08:14,920 --> 00:08:17,550
>> そして、それが続いた約20か
進化するまで30年

189
00:08:17,550 --> 00:08:22,100
リレーショナルデータベースの、どの
世界は今、私たちを決めたときであります

190
00:08:22,100 --> 00:08:27,940
敗北のリポジトリを持っている必要があります
ファイル間でのデータのスプロール

191
00:08:27,940 --> 00:08:29,540
我々が構築したシステム。右？

192
00:08:29,540 --> 00:08:34,270
あまりにも多くで配布データが多すぎ
場所、データの重複排除、

193
00:08:34,270 --> 00:08:37,120
およびストレージのコストは膨大でした。

194
00:08:37,120 --> 00:08:43,760
>> 70年代では、最も高価なリソース
コンピュータが持っていたストレージがありました。

195
00:08:43,760 --> 00:08:46,200
プロセッサがありました
固定費とみなします。

196
00:08:46,200 --> 00:08:49,030
私はボックスを購入すると、
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
>> しかし、理由の一つと
this--私たちの背後にあるドライバ

213
00:09:34,760 --> 00:09:38,290
データ圧力について話しました。

214
00:09:38,290 --> 00:09:41,920
データ圧力は何かであります
それは技術革新を駆動します。

215
00:09:41,920 --> 00:09:44,610
そして、あなたはオーバー見れば
過去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
OK。

222
00:09:57,911 --> 00:09:59,410
さて、これは新傾向ではありません。

223
00:09:59,410 --> 00:10:01,230
これはされてい傾向であります
100年のため外出。

224
00:10:01,230 --> 00:10:03,438
これまでハーマン・ホレリスので、
パンチカードを開発し、

225
00:10:03,438 --> 00:10:08,040
我々は、データリポジトリを構築してきました
そして驚異的な速度でデータを収集します。

226
00:10:08,040 --> 00:10:10,570
>> だから、最後の100年間で、
私たちはこの傾向を見てきました。

227
00:10:10,570 --> 00:10:11,940
それは変更するつもりはありません。

228
00:10:11,940 --> 00:10:14,789
今後は、参照しようとしています
この、そうでない場合は加速傾向。

229
00:10:14,789 --> 00:10:16,330
そして、あなたはそれがどのように見えるかを見ることができます。

230
00:10:16,330 --> 00:10:23,510
>> 2010年の事業は、いずれかを持っていた場合
管理下のデータのテラバイト、

231
00:10:23,510 --> 00:10:27,080
彼らがしていることを意味今日
データの6.5ペタバイトを管理します。

232
00:10:27,080 --> 00:10:30,380
それが6500倍以上のデータです。

233
00:10:30,380 --> 00:10:31,200
そして、私はこれを知っています。

234
00:10:31,200 --> 00:10:33,292
私は毎日これらの事業で動作します。

235
00:10:33,292 --> 00:10:35,000
五年前、私
企業に話だろう

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
これはおそらく起こっていること
ペタバイトまたは2であることを

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
>> 物事の1だから、
私たちはなぜNo​​SQLのように見えますか？

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

295
00:13:24,050 --> 00:13:26,386
>> そして、それは我々が何を得るのです
リレーショナルデータベース。

296
00:13:26,386 --> 00:13:27,510
これは、ストレージ用に最適化されています。

297
00:13:27,510 --> 00:13:28,280
これは、正規化されたのです。

298
00:13:28,280 --> 00:13:29,370
これは、リレーショナルです。

299
00:13:29,370 --> 00:13:31,660
これは、アドホッククエリをサポートしています。

300
00:13:31,660 --> 00:13:34,000
そして、それが垂直方向に拡大または縮小されます。

301
00:13:34,000 --> 00:13:39,030
>> 私は、大きなSQLデータベースを取得する必要がある場合
以上の強力なSQLデータベース、

302
00:13:39,030 --> 00:13:41,090
私は鉄の大きな作品を買いに行きます。

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

304
00:13:41,600 --> 00:13:44,940
私は多くの顧客と働いてきました
メジャーアップグレードをしてきたこと

305
00:13:44,940 --> 00:13:48,340
そのSQLインフラストラクチャ内のみ
半年後に見つけるために、

306
00:13:48,340 --> 00:13:49,750
彼らは再び壁に当たっています。

307
00:13:49,750 --> 00:13:55,457
また、OracleまたはMSSQLからの回答
または他の誰には大きなボックスを取得することです。

308
00:13:55,457 --> 00:13:58,540
まあ遅かれ早かれ、あなたが購入することはできません
大きな箱、それが本当の問題です。

309
00:13:58,540 --> 00:14:00,080
私たちは、実際に物事を変更する必要があります。

310
00:14:00,080 --> 00:14:01,080
だからここで、これは動作しますか？

311
00:14:01,080 --> 00:14:06,560
これは、オフラインに適しています
分析、OLAP型のワークロード。

312
00:14:06,560 --> 00:14:08,670
SQLが属するところそしてそれは本当にです。

313
00:14:08,670 --> 00:14:12,540
今、それは多くのオンラインで現在使用されています
トランザクション処理型

314
00:14:12,540 --> 00:14:13,330
アプリケーション。

315
00:14:13,330 --> 00:14:16,460
そして、それは、単に正常に動作します
利用のいくつかのレベル、

316
00:14:16,460 --> 00:14:18,670
しかし、それだけでスケールしません
NoSQLのはない方法。

317
00:14:18,670 --> 00:14:20,660
そして、私たちは少し話しましょう
それがある理由について少し。

318
00:14:20,660 --> 00:14:23,590
>> さて、NoSQLの、他方では、
複数の計算用に最適化されています。

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

320
00:14:24,540 --> 00:14:26,830
それはにとらわれないではありません
アクセスパターン。

321
00:14:26,830 --> 00:14:31,620
我々は、デ正規化と呼んで
構造や階層構造。

322
00:14:31,620 --> 00:14:35,000
リレーショナルデータベース内のデータがあります
複数のテーブルから一緒に参加しました

323
00:14:35,000 --> 00:14:36,850
必要なビューを生成します。

324
00:14:36,850 --> 00:14:40,090
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
OK？

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
私の顧客の何をjust--したいです
この特定の特性を持っている人

346
00:15:34,520 --> 00:15:37,850
このday--に買った私にはわかりません
彼らが聞いてどのようなクエリつもりです。

347
00:15:37,850 --> 00:15:39,160
だから私はとらわれないようにする必要があります。

348
00:15:39,160 --> 00:15:41,810
>> 今、オンラインで
トランザクション・アプリケーション、

349
00:15:41,810 --> 00:15:43,820
私が求めているものな質問を知っています。

350
00:15:43,820 --> 00:15:46,581
私はのためのアプリケーションを構築しました
非常に特定のワークフロー。

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

352
00:15:47,080 --> 00:15:50,540
だから私は、データを最適化する場合
そのワークフローをサポートするために格納します、

353
00:15:50,540 --> 00:15:52,020
それは速くなるだろう。

354
00:15:52,020 --> 00:15:55,190
そして、それはなぜな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
OK。

363
00:16:12,936 --> 00:16:16,060
制約のおもむくままの三角形
あなたはすべてのすべての時間を持つことはできません。

364
00:16:16,060 --> 00:16:17,750
あなたのパイを持って、あまりにもそれを食べることはできません。

365
00:16:17,750 --> 00:16:22,310
だから、プロジェクト管理で、その三角形
制約は、あなたはそれが安いことができますです

366
00:16:22,310 --> 00:16:24,710
あなたはそれが速いことができ、
またはあなたはそれが良いことができます。

367
00:16:24,710 --> 00:16:25,716
2を選択してください。

368
00:16:25,716 --> 00:16:27,090
あなたはすべての3つを持つことができませんので。

369
00:16:27,090 --> 00:16:27,460
右？

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

371
00:16:27,820 --> 00:16:28,920
>> だから、このことについて多くのことを聞きます。

372
00:16:28,920 --> 00:16:31,253
これは、トリプル制約です
トリプル制約の三角形、

373
00:16:31,253 --> 00:16:34,420
または鉄の三角形があります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
OK？

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

383
00:16:52,720 --> 00:16:56,760
だからCAPで、一貫性がすべてのことを意味し
データベースにアクセスできるクライアント

384
00:16:56,760 --> 00:16:59,084
常に非常になります
データの一貫性のあるビュー。

385
00:16:59,084 --> 00:17:00,750
誰のつもりは二つの異なるものを参照してください。

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

387
00:17:01,480 --> 00:17:04,020
私は、データベースを参照してください場合は、
私は同じビューを見ています

388
00:17:04,020 --> 00:17:06,130
見ている私のパートナーとして
同じデータベース。

389
00:17:06,130 --> 00:17:07,470
それは一貫性です。

390
00:17:07,470 --> 00:17:12,099
>> 可用性があればということ
オンラインデータベース、それに到達することができれば、

391
00:17:12,099 --> 00:17:14,760
すべてのクライアントは常にその意志
読み書きができるように。

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

393
00:17:15,260 --> 00:17:17,010
だから、すべてのクライアントは、
データベースを読み取ることができます

394
00:17:17,010 --> 00:17:18,955
常にことが読み込まれます
データとデータを書き込みます。

395
00:17:18,955 --> 00:17:21,819
そして、その場合は、
それは、利用可能なシステムです。

396
00:17:21,819 --> 00:17:24,230
>> そして、第三のポイントは何ですか
我々は分割耐性を呼び出します。

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

398
00:17:24,730 --> 00:17:28,160
パーティション許容手段
システムがうまく機能しています

399
00:17:28,160 --> 00:17:32,000
物理的なネットワークにもかかわらず、
ノード間のパーティション。

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

401
00:17:32,760 --> 00:17:36,270
だから、クラスタ内のノードはできません
お互いに話、何が起こりますか？

402
00:17:36,270 --> 00:17:36,880
大丈夫。

403
00:17:36,880 --> 00:17:39,545
>> だから、リレーショナルデータベースchoose--
あなたは、これらのうちの2つを選ぶことができます。

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

405
00:17:40,045 --> 00:17:43,680
だから、リレーショナルデータベースは、選択しました
一貫して利用できるようにします。

406
00:17:43,680 --> 00:17:47,510
パーティションは、間に発生した場合
データストア内のDataNodes、

407
00:17:47,510 --> 00:17:48,831
データベースがクラッシュします。

408
00:17:48,831 --> 00:17:49,330
右？

409
00:17:49,330 --> 00:17:50,900
それはちょうどダウン。

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

411
00:17:51,450 --> 00:17:54,230
>> そして、これは彼らが持っている理由であります
大きな箱と一緒に成長します。

412
00:17:54,230 --> 00:17:54,730
右？

413
00:17:54,730 --> 00:17:58,021
no--通常、クラスタがありますので
データベースには、それらの非常に多くありません

414
00:17:58,021 --> 00:17:59,590
それはそのように動作します。

415
00:17:59,590 --> 00:18:03,019
しかし、ほとんどのデータベースの規模
垂直方向に単一のボックス内。

416
00:18:03,019 --> 00:18:05,060
彼らがする必要があるため
一貫して利用できます。

417
00:18:05,060 --> 00:18:10,320
パーティションが注入された場合、
あなたが選択をする必要があります。

418
00:18:10,320 --> 00:18:13,720
あなたは間の選択をしなければなりません
一貫して利用可能です。

419
00:18:13,720 --> 00:18:16,080
>> そして、それはのNoSQLデータベースは何をすべきかです。

420
00:18:16,080 --> 00:18:16,580
大丈夫。

421
00:18:16,580 --> 00:18:20,950
だからのNoSQLデータベースは、それを
2種類があります。

422
00:18:20,950 --> 00:18:22,990
私たちは、それをよくhave--
多くの種類があります、

423
00:18:22,990 --> 00:18:26,140
しかし、それは、2つの基本的な付属しています
何をcharacteristics--

424
00:18:26,140 --> 00:18:30,050
我々は、CPデータベース、またはAを呼び出します
一貫してパーティション公差

425
00:18:30,050 --> 00:18:31,040
システム。

426
00:18:31,040 --> 00:18:34,930
これらの人は選択をするときに
ノードは、互いとの接触を失います

427
00:18:34,930 --> 00:18:37,091
我々はできるようにするつもりはありません
人々はそれ以上を書き込みます。

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

429
00:18:37,590 --> 00:18:41,855
>> そのパーティションが削除されるまで、
書き込みアクセスがブロックされます。

430
00:18:41,855 --> 00:18:43,230
それは、彼らが利用できないことを意味しています。

431
00:18:43,230 --> 00:18:44,510
彼らは一貫しています。

432
00:18:44,510 --> 00:18:46,554
我々はそれを見るとき
パーティションは、それ自身を注入し、

433
00:18:46,554 --> 00:18:48,470
我々は、今一致しています
我々はつもりはないので、

434
00:18:48,470 --> 00:18:51,517
二つのデータの変更を可能にします
独立したパーティションの側面

435
00:18:51,517 --> 00:18:52,100
お互い。

436
00:18:52,100 --> 00:18:54,130
我々はする必要があります
通信を再確立

437
00:18:54,130 --> 00:18:56,930
への更新前
データが許可されます。

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

439
00:18:58,120 --> 00:19:02,650
>> 次の味わいは、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
そして、誰かが実現するために起こっています、
おっと、彼らのシステムは、UH-ああ、理解するであろう、

451
00:19:27,360 --> 00:19:28,870
2つの側部に更新があったです。

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

465
00:20:01,000 --> 00:20:06,570
>> ACIDは私たちに原子性、一貫性を与え、
分離、および耐久性。

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

467
00:20:07,070 --> 00:20:13,550
それはすべて、アトミック、トランザクションの意味します
私の更新が発生するいずれか、またはそうではありません。

468
00:20:13,550 --> 00:20:16,570
一貫性があることを意味
データベースは、常に意志

469
00:20:16,570 --> 00:20:19,780
一貫させること
更新後の状態。

470
00:20:19,780 --> 00:20:23,900
私は、データベースを残すことはありません
アップデートを適用した後に悪い状態。

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

472
00:20:24,400 --> 00:20:26,720
>> だから、それは少し違います
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
したがって、基本的に、私はインクリメントすることはできません
二つの操作と同じ値を2回

485
00:21:04,130 --> 00:21:08,580
>> しかし、私はこの値に1を加えると言えば、
そして、2つのトランザクションが来ます

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
そこで最後に、私は2つを追加しました。

489
00:21:15,210 --> 00:21:16,170
あなたは私が何を意味するか参照してください？

490
00:21:16,170 --> 00:21:16,670
OK。

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

492
00:21:19,220 --> 00:21:21,250
>> 耐久性は非常に簡単です。

493
00:21:21,250 --> 00:21:23,460
ときトランザクション
それはだ、認められています

494
00:21:23,460 --> 00:21:26,100
でもそこに行きます
システムがクラッシュした場合。

495
00:21:26,100 --> 00:21:29,230
そのシステムが復旧すると、その
コミットされたトランザクション

496
00:21:29,230 --> 00:21:30,480
実際にそこになるだろう。

497
00:21:30,480 --> 00:21:33,130
だから、保証です
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
OK？

517
00:22:16,420 --> 00:22:19,690
>> 基本的に利用できる、なぜなら
彼らは、パーティション寛容です。

518
00:22:19,690 --> 00:22:21,470
彼らはいつもになります
そこに、あります場合でも、

519
00:22:21,470 --> 00:22:23,053
ノード間のネットワークパーティション。

520
00:22:23,053 --> 00:22:25,900
私はノードに話すことができるなら、私はよ
データを読み取ることができるようになるだろう。

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

522
00:22:26,460 --> 00:22:30,810
私はいつも書き込むことができない場合があります
データ私は一貫性のあるプラットフォームだ場合。

523
00:22:30,810 --> 00:22:32,130
しかし、私はデータを読み取ることができるようになります。

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

525
00:22:34,960 --> 00:22:38,010
>> ソフトの状態を示し
私は、そのデータを読み取るときに、

526
00:22:38,010 --> 00:22:40,790
それは、他のノードと同じではないかもしれません。

527
00:22:40,790 --> 00:22:43,390
右側は、ノード上で発行された場合
クラスタ内の他のどこかに

528
00:22:43,390 --> 00:22:46,650
それが全体にレプリケートされていません
まだクラスタ私はそのデータを読み込み、

529
00:22:46,650 --> 00:22:48,680
その状態が一致しない場合があります。

530
00:22:48,680 --> 00:22:51,650
しかし、それは次のようになります
最終的には一貫性のあります、

531
00:22:51,650 --> 00:22:53,870
そのときの書き込みの意味
システムに対して行われ、

532
00:22:53,870 --> 00:22:56,480
それは、ノード間で複製されます。

533
00:22:56,480 --> 00:22:59,095
そして最終的には、その状態
順序にもたらされるだろう、

534
00:22:59,095 --> 00:23:00,890
それは一貫性のある状態になります。

535
00:23:00,890 --> 00:23:05,000
>> さて、CAP定理本当に
1つの条件のみで再生されます。

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

545
00:23:32,621 --> 00:23:34,830
APシステムは、2つの種類があります。

546
00:23:34,830 --> 00:23:38,514
彼らはある味わいに来ます
マスターマスター、100％、常に利用可能。

547
00:23:38,514 --> 00:23:40,430
そして、彼らは来ます
他の味、と言います、

548
00:23:40,430 --> 00:23:43,330
あなたは、私が心配するつもりだ知っています
このパーティショニングの事について

549
00:23:43,330 --> 00:23:44,724
実際のパーティションが発生したとき。

550
00:23:44,724 --> 00:23:47,890
それ以外の場合は、一次があるように起こっています
権利を取るために起こっているノード。

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

552
00:23:48,500 --> 00:23:50,040
>> カサンドラのようなもの、私たちはそうであれば。

553
00:23:50,040 --> 00:23:54,440
カサンドラは、マスターになります
マスター、私は任意のノードに書き込みをしてみましょう。

554
00:23:54,440 --> 00:23:55,540
だから何が起こりますか？

555
00:23:55,540 --> 00:23:58,270
だから私は、内のオブジェクトを持っています
2つのノードで存在するデータベース。

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
それでは、私が手にしましょう
2つのノードに複数のために書きます。

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
実際にはすぐに分割します
私は2つのノードに書込みを得るよう。

564
00:24:18,449 --> 00:24:20,830
それは私を強制しないことです
1ノードを介してすべてを記述します。

565
00:24:20,830 --> 00:24:22,340
私は2つのノードで書いています。

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

567
00:24:23,330 --> 00:24:25,740
>> だから今、私は2つの状態を持っています。

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

569
00:24:26,360 --> 00:24:28,110
何が起こるだろう
遅かれ早かれあり、

570
00:24:28,110 --> 00:24:29,960
複製イベントがあるように起こっています。

571
00:24:29,960 --> 00:24:33,300
私たちがあるように起こっています
これは、パーティションの回復と呼ばれます

572
00:24:33,300 --> 00:24:35,200
ここで、これらの二つであります
状態が一緒に戻ってきます

573
00:24:35,200 --> 00:24:37,310
アルゴリズムがあるように起こっています
それは、データベース内で実行されます

574
00:24:37,310 --> 00:24:38,540
何をするかを決定します。

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

576
00:24:39,110 --> 00:24:43,057
デフォルトでは、最後の更新
ほとんどの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
OK？

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
そして、私は試してみたいと
これらの2つのレコードをマージします。

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

608
00:25:56,180 --> 00:25:58,670
だから、と非常に簡単です
一致しているに対処します

609
00:25:58,670 --> 00:26:01,330
ときに、更新を受け付けておりません。

610
00:26:01,330 --> 00:26:04,620
CPシステムが行うとのことです。

611
00:26:04,620 --> 00:26:05,120
大丈夫。

612
00:26:05,120 --> 00:26:07,590
>> それでは、少し話をしましょう
アクセス・パターンについて少し。

613
00:26:07,590 --> 00:26:11,580
私たちはNoSQLのについて話すとき、それはです
すべてのアクセスパターンについて。

614
00:26:11,580 --> 00:26:13,550
さて、SQLは、アドホッククエリです。

615
00:26:13,550 --> 00:26:14,481
これは、リレーショナル店です。

616
00:26:14,481 --> 00:26:16,480
私たちは心配する必要はありません
アクセスパターンについて。

617
00:26:16,480 --> 00:26:17,688
私は非常に複雑なクエリを記述します。

618
00:26:17,688 --> 00:26:19,250
これは、データを移行し、取得します。

619
00:26:19,250 --> 00:26:21,210
それが、これは見えるものです
以下のように、正規化。

620
00:26:21,210 --> 00:26:24,890
>> したがって、この特定の構造で、
我々は、製品カタログを見ています。

621
00:26:24,890 --> 00:26:26,640
私は、製品の種類を持っています。

622
00:26:26,640 --> 00:26:27,217
私は本を​​持っています。

623
00:26:27,217 --> 00:26:27,800
私はアルバムを持っています。

624
00:26:27,800 --> 00:26:30,090
私はビデオを持っています。

625
00:26:30,090 --> 00:26:33,370
製品間の関係
これらの書籍のいずれか1つの、アルバム、

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

631
00:26:41,580 --> 00:26:44,350
1の関係：それは1です
これらの表の間で。

632
00:26:44,350 --> 00:26:46,970
>> 今、すべての彼らをbooks--
持っているルートのプロパティです。

633
00:26:46,970 --> 00:26:47,550
問題ない。

634
00:26:47,550 --> 00:26:48,230
それは素晴らしいことです。

635
00:26:48,230 --> 00:26:52,130
一対一の関係、私はすべてを取得します
私はその本を記述するために必要なデータ。

636
00:26:52,130 --> 00:26:54,770
Albums--アルバムは、曲を持っています。

637
00:26:54,770 --> 00:26:56,470
これは、我々は多くのものを呼んでいます。

638
00:26:56,470 --> 00:26:58,905
すべてのアルバムは多くのトラックを持つことができます。

639
00:26:58,905 --> 00:27:00,780
上のすべてのトラックにそう
アルバムは、私が持っている可能性が

640
00:27:00,780 --> 00:27:02,570
この子テーブルの別のレコード。

641
00:27:02,570 --> 00:27:04,680
だから、私は1つのレコードを作成します
私のアルバムテーブルインチ

642
00:27:04,680 --> 00:27:06,700
私は複数のレコードを作成します
トラックテーブルです。

643
00:27:06,700 --> 00:27:08,850
一対多のリレーションシップ。

644
00:27:08,850 --> 00:27:11,220
>> この関係は何ですか
我々は、多対多を呼び出します。

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

646
00:27:11,750 --> 00:27:17,000
あなたは、俳優があり得ることを参照してください。
多くの映画の中で、多くのビデオ。

647
00:27:17,000 --> 00:27:21,450
だから我々は何をすべきか、我々は、このマッピングを入れています
それらの間のテーブル、それだけ

648
00:27:21,450 --> 00:27:24,040
動画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
>> OK。

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
それらは3トップレベルです
任意のデータベース内の関係。

657
00:27:44,990 --> 00:27:48,050
あなたはどのようにそれらを知っている場合
関係は一緒に働きます、

658
00:27:48,050 --> 00:27:51,490
あなたは多くのことを知っています
すでにデータベースに関する。

659
00:27:51,490 --> 00:27:55,660
だから、NoSQLのは少し異なる動作します。

660
00:27:55,660 --> 00:27:58,930
それでは、何それ秒間について考えてみましょう
すべての私のプロダクトを取りに行くためにのように見えます。

661
00:27:58,930 --> 00:28:01,096
>> リレーショナルストアでは、I
すべての私の製品を取得したいです

662
00:28:01,096 --> 00:28:02,970
すべての私のプロダクトのリストに。

663
00:28:02,970 --> 00:28:04,910
これは、クエリの多くのです。

664
00:28:04,910 --> 00:28:07,030
私はすべての私の本のためのクエリを得ました。

665
00:28:07,030 --> 00:28:08,470
私はアルバムからの照会を得ました。

666
00:28:08,470 --> 00:28:09,970
そして、私はすべての私の動画のクエリを得ました。

667
00:28:09,970 --> 00:28:11,719
そして、私はそれを置くようになりました
すべて一緒に、リスト内の

668
00:28:11,719 --> 00:28:15,250
そして、まで戻ってそれを提供します
それを要求しているアプリケーション。

669
00:28:15,250 --> 00:28:18,000
>> 私の本を取得するには、私が参加します
製品および電子書籍。

670
00:28:18,000 --> 00:28:21,680
私のアルバムを取得するには、私が参加するようになりました
製品、アルバム、およびトラック。

671
00:28:21,680 --> 00:28:25,330
そして、私が持っている、自分の動画を取得します
ビデオに製品に参加するには、

672
00:28:25,330 --> 00:28:28,890
俳優ビデオを通じて参加、
そして、俳優をもたらします。

673
00:28:28,890 --> 00:28:31,020
だから、3つのクエリです。

674
00:28:31,020 --> 00:28:34,560
非常に複雑なクエリへ
1つの結果セットを組み立てます。

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
私は俳優のための1つのレコードを持っています。

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
1つの表内のすべての製品を入れてみましょう。

693
00:29:19,027 --> 00:29:22,110
私は1つのテーブルにすべての製品を置く場合、
私はすべての製品を選択することができます

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
Productsテーブル内の文書があります。

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
私は属性または持っている必要があります
その表に定義されているプロパティ。

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
私は1つのクエリを実行しています。

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
私が意味する、毎回のANを考えます
オペレーティング・システムのパッチが出てきます

837
00:35:09,110 --> 00:35:11,552
またはデータベースの新バージョン。

838
00:35:11,552 --> 00:35:13,260
どういう意味ですか
あなたに動作？

839
00:35:13,260 --> 00:35:16,330
それはあなたが1200を得た意味します
更新する必要があるサーバー。

840
00:35:16,330 --> 00:35:18,960
今でも自動化と、
それは長い時間がかかることがあります。

841
00:35:18,960 --> 00:35:21,480
それは、多くのを引き起こす可能性があります
運用頭痛、

842
00:35:21,480 --> 00:35:23,090
私は、サービスのダウン持っている可能性があるため。

843
00:35:23,090 --> 00:35:26,070
>> 私は、これらのデータベースを更新するように、私
青緑色の展開を行う可能性があります

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
そして、あなたは機能を主張することができます
他の上の1つの。

862
00:36:10,620 --> 00:36:13,950
私には、これの多くは実際に6であります
半分他のダースの。

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
RICKフーリハン：真陽性
偽陰性対？

887
00:37:26,260 --> 00:37:28,785
聴衆：何を返します
あなたが戻っすべきですか？

888
00:37:28,785 --> 00:37:33,720
たまには対照的に、それ
それが検証する必要がありますときには戻りませんか？

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

890
00:37:36,260 --> 00:37:38,050
>> RICKフーリハン：私はあなたにそれを伝えることができませんでした。

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の実際には2つの種類があります

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
>> だから3つの基本タイプ。

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ので、あなたは配列を含めることができます
rootプロパティとしての基本的なタイプの。

959
00:40:42,050 --> 00:40:43,885
>> そして、ドキュメントの種類があります。

960
00:40:43,885 --> 00:40:45,510
どのように多くの人々JSONに精通していますか？

961
00:40:45,510 --> 00:40:47,130
そんなにJSONに精通君たち？

962
00:40:47,130 --> 00:40:49,380
これは、基本的にはJavaScriptのです
オブジェクト、表記。

963
00:40:49,380 --> 00:40:52,510
それはあなたが基本的にすることができます
階層構造を定義します。

964
00:40:52,510 --> 00:40:58,107
>> あなたは上のJSON文書を保存することができます
共通のコンポーネントを使用してDynamoDBの

965
00:40:58,107 --> 00:41:00,940
入手可能であるか、またはビルディングブロック
ほとんどのプログラミング言語です。

966
00:41:00,940 --> 00:41:03,602
あなたは、Javaを持っているのであれば、あなたがしています
マップやリストを見ています。

967
00:41:03,602 --> 00:41:05,060
私は、その領域のマップオブジェクトを作成することができます。

968
00:41:05,060 --> 00:41:08,030
キーの値としてマップ
プロパティとして格納されています。

969
00:41:08,030 --> 00:41:10,890
そしてそれは、のリストを持っている可能性があります
これらのプロパティ内の値。

970
00:41:10,890 --> 00:41:13,490
あなたは、この複合体を保存することができます
階層構造

971
00:41:13,490 --> 00:41:16,320
単一の属性として
DynamoDBのアイテムの。

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

973
00:41:19,010 --> 00:41:24,460
>> DynamoDBの内のテーブルだから、ほとんどのような
NoSQLデータベース、テーブルは、アイテムを持っています。

974
00:41:24,460 --> 00:41:26,469
MongoDBのではだろう
これらの文書を呼び出します。

975
00:41:26,469 --> 00:41:27,760
そして、それはカウチベースになります。

976
00:41:27,760 --> 00:41:28,900
また、文書データベース。

977
00:41:28,900 --> 00:41:29,941
あなたはこれらの文書を呼び出します。

978
00:41:29,941 --> 00:41:32,930
ドキュメントまたはアイテムが属性を持っています。

979
00:41:32,930 --> 00:41:35,850
属性が存在することができますか
アイテムには存在しません。

980
00:41:35,850 --> 00:41:38,520
DynamoDBのでは、あります
1つの必須属性。

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
これはOKですが、しばしば
人々が必要とするもの

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
>> レンジキーはme--ハッシュを許可
キーは平等でなければなりません。

1016
00:43:35,210 --> 00:43:39,490
私はハッシュを照会すると、私が言っています
私はこれを等しいハッシュを与えます。

1017
00:43:39,490 --> 00:43:41,950
私は範囲を照会すると、私
私に範囲を与えると言うことができます

1018
00:43:41,950 --> 00:43:47,040
これは、任意の種類を使用しています
私たちはサポート豊富なオペレータ。

1019
00:43:47,040 --> 00:43:49,200
私はハッシュのためのすべてのアイテムを与えます。

1020
00:43:49,200 --> 00:43:52,520
、より大きい、それは同じです
未満、それはで始まるん、

1021
00:43:52,520 --> 00:43:54,145
これら2つの値の間に存在するのか？

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（b）に等しいです
3は、CDに等しい、48に等しいです。

1046
00:45:10,800 --> 00:45:13,092
これらは、すべての鍵空間に広がっています。

1047
00:45:13,092 --> 00:45:14,050
そして、なぜあなたはこれを行うのですか？

1048
00:45:14,050 --> 00:45:17,120
それは確かに私ができることになりますので
複数のノード間でレコードを置きます。

1049
00:45:17,120 --> 00:45:19,574
>> 私はこれをやっている場合
増分、1、2、3。

1050
00:45:19,574 --> 00:45:21,990
そして、私はそのハッシュ範囲を有します
この特定のケースで実行され、

1051
00:45:21,990 --> 00:45:24,785
小さなハッシュ空間、
それは00からFFまで実行され、

1052
00:45:24,785 --> 00:45:27,951
その後、レコードが入ってくるとしています
それらは、1、2、3、4、5に行くつもり

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

1054
00:45:30,390 --> 00:45:31,800
何が起こるのですか？

1055
00:45:31,800 --> 00:45:34,860
すべてのインサートは、同じノードに起こっています。

1056
00:45:34,860 --> 00:45:36,070
あなたは私が何を意味するか参照してください？

1057
00:45:36,070 --> 00:45:40,910
>> 私はスペースを分割するときので、
私は、全体でこれらのレコードを広めます

1058
00:45:40,910 --> 00:45:45,950
私は、私が言うつもりパーティション
パーティション1は54に鍵空間0を持っています。

1059
00:45:45,950 --> 00:45:47,720
パーティション2は89から55です。

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は10進数ではありますか？

1073
00:46:24,896 --> 00:46:28,450
>> RICKフーリハン：ええ、それはです
どこかの周り。

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
聴衆：だけで簡単に1
あなたのMongoのコメントの。

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
RICKフーリハン：それはそれをするのでしょうか？

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
ハッシュキーとの関係
および範囲キーは、多くの1つです。

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
私たちは3 AZのを持っていることを意味します。

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
1アリゾナ州の故障ではありません
別のダウン取るつもり。

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のが広がっています
デフォルトでは3 AZS全体で。

1132
00:49:16,139 --> 00:49:19,430
私たちは、知識だけに書き込みを行っています
これらの3つのノードの2が戻ってきたとき

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
我々は、2つのノードからそれを取得します。

1137
00:49:27,570 --> 00:49:30,490
>> 私は全体で複製していた場合
3、私は、2から読んでいます

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
その場合、私は言うつもりです、
私は1つのノードからのみ読み込まれます。

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
そして、それは、主テーブルの上に私です
1つのハッシュキーを持って、私は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
2つのタイプがあります
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
データが挿入されているように、それを考えます
2つの異なるテーブルに、構造化

1217
00:53:08,010 --> 00:53:09,220
二つの異なる方法です。

1218
00:53:09,220 --> 00:53:11,360
>> 私は完全に定義することができます
異なるハッシュキー。

1219
00:53:11,360 --> 00:53:13,490
私は完全に定義することができます
異なる範囲のキー。

1220
00:53:13,490 --> 00:53:15,941
そして、私はこれを実行することができます
完全に独立。

1221
00:53:15,941 --> 00:53:18,190
実際のところ、私はしました
私の読み取り能力をプロビ​​ジョニング

1222
00:53:18,190 --> 00:53:21,090
私のための能力を書きます
グローバルセカンダリインデックス

1223
00:53:21,090 --> 00:53:24,240
完全に独立して
私の主テーブルの。

1224
00:53:24,240 --> 00:53:26,640
私はそのインデックスを定義すると、私が言います
それはどのくらいの読み取りおよび書き込み

1225
00:53:26,640 --> 00:53:28,610
容量は、それが使用することになるだろう。

1226
00:53:28,610 --> 00:53:31,490
>> そして、それは別のものです
私の主テーブルから。

1227
00:53:31,490 --> 00:53:35,240
今すぐインデックスの両方をするために私達を許可します
ハッシュとレンジキーを定義するだけでなく、

1228
00:53:35,240 --> 00:53:38,610
しかし、彼らは私たちができるようにします
追加の値を投影します。

1229
00:53:38,610 --> 00:53:44,950
だから私は、インデックスを読み取るしたい場合は、
私はいくつかのデータセットを取得したいです、

1230
00:53:44,950 --> 00:53:48,327
私がメインに戻る必要はありません
表には、追加の属性を取得します。

1231
00:53:48,327 --> 00:53:50,660
私はそれらの追加を投影することができます
テーブルに属性

1232
00:53:50,660 --> 00:53:53,440
アクセスパターンをサポートしています。

1233
00:53:53,440 --> 00:53:57,700
私たちは、おそらくいくつかの中に取得している知っています
本当に、雑草になっreally--

1234
00:53:57,700 --> 00:53:58,910
ここではこのようなもののいくつかの。

1235
00:53:58,910 --> 00:54:02,725
今私はこのうちドリフトするようになりました。

1236
00:54:02,725 --> 00:54:07,320
>> 聴衆：[聞こえません]
--tableキーがハッシュた意味しましたか？

1237
00:54:07,320 --> 00:54:08,840
オリジナルのハッシュ？

1238
00:54:08,840 --> 00:54:09,340
マルチスラット？

1239
00:54:09,340 --> 00:54:10,200
>> RICKフーリハン：はい。

1240
00:54:10,200 --> 00:54:11,070
はい。

1241
00:54:11,070 --> 00:54:15,260
基本的にはテーブルキー
戻ってアイテムを指しています。

1242
00:54:15,260 --> 00:54:19,280
そこでインデックスはバックへのポインタであります
テーブルの上にオリジナルアイテム。

1243
00:54:19,280 --> 00:54:22,910
今、あなたは構築することを選択できます
唯一のテーブルキーを持つインデックス、

1244
00:54:22,910 --> 00:54:24,840
なしその他のプロパティ。

1245
00:54:24,840 --> 00:54:26,570
そして、なぜ私はそれを行うのでしょうか？

1246
00:54:26,570 --> 00:54:28,570
まあ、私は非常に大規模なアイテムを持っています。

1247
00:54:28,570 --> 00:54:31,660
>> 私は実際には知っておく必要がありますwhich--
私のアクセスパターンは、言うかもしれません

1248
00:54:31,660 --> 00:54:33,760
どの項目は、このプロパティが含まれていますか？

1249
00:54:33,760 --> 00:54:35,780
アイテムを返す必要がないようにしてください。

1250
00:54:35,780 --> 00:54:37,800
私は知っている必要があります
どの項目を含んでいます。

1251
00:54:37,800 --> 00:54:40,700
ですから、インデックスを構築することができます
その唯一のテーブルキーを持っています。

1252
00:54:40,700 --> 00:54:43,360
>> しかし、それは主に何
データベース内のインデックスがためのものです。

1253
00:54:43,360 --> 00:54:46,280
それはすぐにできることのためです
、記録する特定

1254
00:54:46,280 --> 00:54:49,470
どの行、どの
表中の商品はあり

1255
00:54:49,470 --> 00:54:51,080
私が探しているプロパティ。

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

1257
00:54:53,610 --> 00:54:54,860
>> GSISので、どのように動作するのですか？

1258
00:54:54,860 --> 00:54:58,340
GSISは基本的に非同期です。

1259
00:54:58,340 --> 00:55:02,570
更新は、表に出たとき、
テーブルが非同期で更新されます

1260
00:55:02,570 --> 00:55:03,720
あなたのGSISのすべて。

1261
00:55:03,720 --> 00:55:06,680
GSISがある理由はここにあります
最終的に一致しています。

1262
00:55:06,680 --> 00:55:09,440
>> これは、ことに注意することが重要です
あなたはGSISを構築しているときに、

1263
00:55:09,440 --> 00:55:13,110
そしてあなたが作成している理解します
aggregation--の別の次元

1264
00:55:13,110 --> 00:55:16,594
今のが良い例をしましょう
ここメーカーです。

1265
00:55:16,594 --> 00:55:19,260
私は私が話をしているかもしれないと思います
医療機器メーカー。

1266
00:55:19,260 --> 00:55:23,870
医療機器メーカー
しばしばシリアル化された部分があります。

1267
00:55:23,870 --> 00:55:28,070
入るパーツ
人工股関節置換すべて

1268
00:55:28,070 --> 00:55:30,200
それらにほとんどのシリアル番号を持っています。

1269
00:55:30,200 --> 00:55:33,584
そして、彼らは何百万を持っている可能性があり、
部品の何百万と数十億

1270
00:55:33,584 --> 00:55:35,000
彼らは出荷するすべてのデバイスです。

1271
00:55:35,000 --> 00:55:37,440
まあ、それは下集約する必要があります
異なる寸法、すべての部分

1272
00:55:37,440 --> 00:55:39,520
アセンブリ内の、すべての
作られた部品

1273
00:55:39,520 --> 00:55:41,670
特定の行に、すべての
来パーツ

1274
00:55:41,670 --> 00:55:44,620
特定のメーカーからで
特定の日に。

1275
00:55:44,620 --> 00:55:47,940
そして、これらの集計時々
十億に立ち上がります。

1276
00:55:47,940 --> 00:55:50,550
>> だから私はいくつかのと協力
苦しんでいるこれらの人

1277
00:55:50,550 --> 00:55:53,156
彼らが作成しているため、
これらのとてつもなく大きい集計

1278
00:55:53,156 --> 00:55:54,280
そのセカンダリインデックスインチ

1279
00:55:54,280 --> 00:55:57,070
彼らは生の部分があるかもしれません
ハッシュだけとして来るテーブル。

1280
00:55:57,070 --> 00:55:59,090
すべての部分は、固有のシリアル番号を持っています。

1281
00:55:59,090 --> 00:56:00,975
私はハッシュとしてシリアル番号を使用しています。

1282
00:56:00,975 --> 00:56:01,600
美しい。

1283
00:56:01,600 --> 00:56:04,160
私の生データテーブルが広がっています
すべての鍵空間全体で。

1284
00:56:04,160 --> 00:56:05,930
じぶんの [？書きます ？]
[？摂取は？]素晴らしいです。

1285
00:56:05,930 --> 00:56:07,876
私は大量のデータを取ります。

1286
00:56:07,876 --> 00:56:09,500
その後、彼らは何をすべきか、彼らはGSIを作成することです。

1287
00:56:09,500 --> 00:56:12,666
そして、私は私が確認する必要があり、あなたは何を知っている、と言います
このメーカーのためのすべての部品。

1288
00:56:12,666 --> 00:56:15,060
さて、突然私はよ
億行を取って、

1289
00:56:15,060 --> 00:56:17,550
とにそれらを詰め込みます
1ノード、時のため

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
再び、私は1つのノードを打っていますので。

1295
00:56:36,030 --> 00:56:38,350
私はこれらをすべて入れています
一つのノードに挿入します。

1296
00:56:38,350 --> 00:56:40,940
そして、それは本当の問題のユースケースです。

1297
00:56:40,940 --> 00:56:43,479
今、私は良いデザインを持って
あなたはそれを避ける方法のためのパターン。

1298
00:56:43,479 --> 00:56:45,770
そして、それは問題の一つです
私はいつもと動作すること。

1299
00:56:45,770 --> 00:56:49,590
しかし、何が起こるかは、国土地理院のかもしれないです
十分な書き込み能力を持っていません

1300
00:56:49,590 --> 00:56:52,330
すべてのそれらをプッシュすることができるようにします
単一のノードに行。

1301
00:56:52,330 --> 00:56:55,390
そして、何が起こるかは、その後で
一次、クライアントテーブル、

1302
00:56:55,390 --> 00:57:00,180
主テーブルが絞られます
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の、国土地理院のように、
私はどちらを使うべきでしょうか？

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
それがOKなら、私が使用することをお勧めします
国土地理院は、彼らがはるかに柔軟です。

1309
00:57:17,490 --> 00:57:20,270
本LSIのは、国土地理院のようにモデル化することができます。

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
アイテムのサイズは
400キロバイトそれぞれに制限され、

1331
00:58:17,620 --> 00:58:20,050
それは、アイテムの属性ではないだろう。

1332
00:58:20,050 --> 00:58:24,200
すべての属性の合計だから
400キロバイトに制限されています。

1333
00:58:24,200 --> 00:58:27,300
そして再び、私たちは持っています
その小さなLSIの問題

1334
00:58:27,300 --> 00:58:30,405
ハッシュあたり10ギガバイトの制限付き。

1335
00:58:30,405 --> 00:58:33,280
対象：小数は、私が欠けています
あなたは、それを私に言っていますis--

1336
00:58:33,280 --> 00:58:36,830
聴衆：ああ、400キロバイト
項目ごとの最大サイズです。

1337
00:58:36,830 --> 00:58:39,570
だからアイテムはすべての属性を持っています。

1338
00:58:39,570 --> 00:58:43,950
だから、400 kは合計サイズです
その項目の、400キロバイト。

1339
00:58:43,950 --> 00:58:46,170
すべての属性のだから、
組み合わせることで、すべてのデータ

1340
00:58:46,170 --> 00:58:49,140
それはすべてのそれらの属性にです、
合計サイズにロールアップ、

1341
00:58:49,140 --> 00:58:51,140
現在、今日のアイテムの上限は400 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
そして、実際には2つのノブがあります。

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
[OK]を、私は千をしたいと言っているので、もし
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
あなたが提供することができます千
RCUのは、あなたが行っています

1353
00:59:19,402 --> 00:59:21,840
最終的に2000を取得します
一貫した読み取り。

1354
00:59:21,840 --> 00:59:25,940
そして、それらのための半額
最終的に読み込むに構成​​されています。

1355
00:59:25,940 --> 00:59:28,520
>> ここでも、調整
互いに独立。

1356
00:59:28,520 --> 00:59:32,900
そして、彼らはthroughput--を持っています
あなたが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
だから、のような赤い線が表示されるたびに
this--、それだけでディナモDB--ではありません

1409
01:01:39,030 --> 01:01:41,630
すべてのNoSQLのデータベースは、この問題があります。

1410
01:01:41,630 --> 01:01:44,640
そのことができますアンチパターンがあります。
条件のこれらのタイプを駆動します。

1411
01:01:44,640 --> 01:01:49,070
私は何をすると私は顧客との仕事です
これらの条件を緩和します。

1412
01:01:49,070 --> 01:01:51,840
>> そして、何それは次のように見えますか？

1413
01:01:51,840 --> 01:01:54,260
そして、これはほとんどを得ています
ダイナモの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
>> RICKフーリハン：常に。

1457
01:03:51,450 --> 01:03:51,960
常に。

1458
01:03:51,960 --> 01:03:54,620
ええ、私は常にある意味します
A--して再度、あります

1459
01:03:54,620 --> 01:03:56,980
我々は介して取得しますいくつかのデザインパターン
それはあなたが対処方法についてお話します

1460
01:03:56,980 --> 01:03:58,480
これらの超大型集計しています。

1461
01:03:58,480 --> 01:04:01,260
私が意味する、私はそれらを持っているようになりました、
どのように我々はそれらに対処しますか？

1462
01:04:01,260 --> 01:04:03,760
私はかなり良いユースケースを持って
我々はそのための話だろうと。

1463
01:04:03,760 --> 01:04:05,940
>> すべての権利、それでは、話をしましょう
今いくつかの顧客に関する。

1464
01:04:05,940 --> 01:04:06,950
これらの人はAdRollです。

1465
01:04:06,950 --> 01:04:08,990
あなたがしている場合、私は知りません
AdRollに精通。

1466
01:04:08,990 --> 01:04:10,781
おそらく、それらを参照してください
ブラウザ上でたくさん。

1467
01:04:10,781 --> 01:04:14,230
彼らはしている、広告再ターゲティングしています
最大の広告再ターゲティング事業

1468
01:04:14,230 --> 01:04:14,940
そこに。

1469
01:04:14,940 --> 01:04:17,792
彼らは通常、定期的に轢か
一日あたり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
>> これらの人はactually--
人はこれらです。

1496
01:05:36,210 --> 01:05:38,010
私はそれがこれらの人だかはわかりません。

1497
01:05:38,010 --> 01:05:40,127
これらの人かもしれません。

1498
01:05:40,127 --> 01:05:42,210
基本的に私は、ノーus--語りました
それが彼らだったとは思いません。

1499
01:05:42,210 --> 01:05:43,000
私はそれが他の誰かだったと思います。

1500
01:05:43,000 --> 01:05:44,750
私が働いていました
私に言った顧客

1501
01:05:44,750 --> 01:05:47,040
その今、彼らがしたこと
ディナモDBに行って、彼らがしています

1502
01:05:47,040 --> 01:05:50,330
以下のためのスナックに多くのお金を費やし
その開発チーム毎月

1503
01:05:50,330 --> 01:05:52,886
彼らは彼らのデータベースに費やすより。

1504
01:05:52,886 --> 01:05:54,760
だから、あなたを与えるだろう
コスト削減のアイデア

1505
01:05:54,760 --> 01:05:57,889
あなたがディナモDBに得ることができることをすることは巨大です。

1506
01:05:57,889 --> 01:05:59,430
すべての権利、dropcamの別の会社。

1507
01:05:59,430 --> 01:06:02,138
この男のようなものof--あなたが考える場合
モノのインターネットの、dropcam

1508
01:06:02,138 --> 01:06:05,150
基本的にインターネットセキュリティビデオです。

1509
01:06:05,150 --> 01:06:06,660
あなたはそこにカメラを置きます。

1510
01:06:06,660 --> 01:06:08,180
カメラが動き検出器を持っています。

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
YouTubeのより詳細インバウンドビデオ
これらの人が取得しているものです。

1519
01:06:32,310 --> 01:06:36,780
彼らはすべてを追跡するためにDynamoDBのを使用
すべてのビデオのキーポイント上のメタデータ。

1520
01:06:36,780 --> 01:06:40,282
>> そこで彼らは、彼らがプッシュS3バケットを持っています
すべてのバイナリアーティファクトに。

1521
01:06:40,282 --> 01:06:41,990
そして、彼らが持っています
ダイナモDBが記録します

1522
01:06:41,990 --> 01:06:44,070
これらのS3の3つのオブジェクトに人々を指します。

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
>> 良くないOPSチーム。

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
そして、我々はについて少し話をしました
この一から一、多くの1つ、

1555
01:08:03,440 --> 01:08:05,060
そして、多くの種類の関係に多くの。

1556
01:08:05,060 --> 01:08:07,630
そして、どのようにあなたはダイナモでそれらを維持します。

1557
01:08:07,630 --> 01:08:10,500
ディナモDBでは、使用します
インデックスは、一般的に言えば、

1558
01:08:10,500 --> 01:08:12,910
データを回転させます
他の1つのフレーバー。

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
ライセンスの要件を持っています
人ごとに1つの運転免許証。

1562
01:08:23,802 --> 01:08:26,510
あなたは、2つのドライバのを取得するために行くことができません
ボストンの状態でライセンス。

1563
01:08:26,510 --> 01:08:27,500
私はテキサスでそれを行うことはできません。

1564
01:08:27,500 --> 01:08:28,708
それはそれは方法のようなものです。

1565
01:08:28,708 --> 01:08:32,779
それでDMVで、私たちは、ルックアップを持って、我々
運転免許証を見てみたいです

1566
01:08:32,779 --> 01:08:35,180
社会保障番号で。

1567
01:08:35,180 --> 01:08:39,990
私は、ユーザーの詳細を見てみたいです
運転免許証番号で。

1568
01:08:39,990 --> 01:08:43,620
>> だから我々は、そのユーザーのテーブルを持っている可能性があります
シリアル番号でハッシュキーを有し、

1569
01:08:43,620 --> 01:08:47,830
または社会保障番号、および
様々な属性は、アイテムに定義されています。

1570
01:08:47,830 --> 01:08:49,859
今ではテーブルの上に私が
その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
そのモデルは、その一つであります
1の関係に。

1578
01:09:08,689 --> 01:09:12,460
ただ、非常に単純なGSI、
周りの人のことを反転させます。

1579
01:09:12,460 --> 01:09:13,979
今、多くの約1話。

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
そしてそれはその1を構築
多くの関係

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
その後、多分私は必要なのですか
2番目のインデックスに。

1624
01:11:18,390 --> 01:11:20,840
だから、それはすべての依存します
私がやろうとしています

1625
01:11:20,840 --> 01:11:24,550
私は熟練した取得しようとしているもの。

1626
01:11:24,550 --> 01:11:28,000
>> おそらく、私も費やすつもりはありません
多くの時間のドキュメントの話。

1627
01:11:28,000 --> 01:11:31,460
これはおそらく、少しを取得し、
我々はに行く必要があるよりも深く。

1628
01:11:31,460 --> 01:11:33,710
それでは、少し話をしましょう
豊富なクエリ式について。

1629
01:11:33,710 --> 01:11:37,831
だからディナモDBに我々が持っています
創造する能力

1630
01:11:37,831 --> 01:11:39,330
我々は、投影式を呼んでいるもの。

1631
01:11:39,330 --> 01:11:42,660
投影式は単純です
フィールドや値を選びます

1632
01:11:42,660 --> 01:11:44,290
あなたが表示すること。

1633
01:11:44,290 --> 01:11:46,000
[OK]をので、私は選択を行います。

1634
01:11:46,000 --> 01:11:48,010
私はディナモ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
私は、から選択名前を言うとき
テーブルには、私は1つの属性のみを取得します。

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
OK、それでは、これらの項目を除外しましょう
それは、その特定のクエリと一致しません。

1649
01:12:23,380 --> 01:12:25,540
だから我々は、フィルター式を持っています。

1650
01:12:25,540 --> 01:12:28,310
>> フィルタ式缶
任意の属性上で実行します。

1651
01:12:28,310 --> 01:12:30,260
彼らは、範囲クエリを好きでいません。

1652
01:12:30,260 --> 01:12:32,690
レイズクエリは、より選択的です。

1653
01:12:32,690 --> 01:12:36,470
フィルタクエリは行くために私を必要とします
全体の結果は、設定および取得します

1654
01:12:36,470 --> 01:12:39,170
私はしたくないデータを切り開きます。

1655
01:12:39,170 --> 01:12:40,660
なぜそれが重要なのですか？

1656
01:12:40,660 --> 01:12:42,770
私はそれをすべて読んでからです。

1657
01:12:42,770 --> 01:12:46,597
クエリでは、私が読んでするつもりだと
それは、データについての巨人になるだろう。

1658
01:12:46,597 --> 01:12:48,430
そして私はするつもりです
私は必要なものを切り開きます。

1659
01:12:48,430 --> 01:12:52,080
そして、私は唯一切り開くだ場合
行のカップルは、それは大丈夫です。

1660
01:12:52,080 --> 01:12:53,620
それはとても非効率​​的ではありません。

1661
01:12:53,620 --> 01:12:57,800
>> しかし、私は全体の山を読んでいる場合
ただ一つのアイテムを切り開くためのデータ、

1662
01:12:57,800 --> 01:13:01,490
その後、私は良いことするつもりです
範囲クエリを使用してオフ、

1663
01:13:01,490 --> 01:13:03,030
それははるかに選択だからです。

1664
01:13:03,030 --> 01:13:06,330
それは私の多くを保存するために起こっています
お金、私はその読み取りのために支払うため。

1665
01:13:06,330 --> 01:13:10,430
どこに戻ってくる結果
少なくなることがあり、その線を横切ります、

1666
01:13:10,430 --> 01:13:11,890
しかし私は、読み取りのために払っています。

1667
01:13:11,890 --> 01:13:14,340
それでは、どのように理解
あなたは、データを取得しています。

1668
01:13:14,340 --> 01:13:16,420
それはディナモDBには非常に重要です。

1669
01:13:16,420 --> 01:13:19,710
>> 条件式、これは何ですか
あなたはオプティミスティック・ロックを呼ぶかもしれません。

1670
01:13:19,710 --> 01:13:28,470
更新する場合は、存在する場合、またはこの値であれば
私が指定したものと同等です。

1671
01:13:28,470 --> 01:13:31,494
そして、私は上のタイムスタンプを持っている場合
レコードは、私がデータを読み取ることがあります。

1672
01:13:31,494 --> 01:13:32,535
私は、そのデータを変更する場合があります。

1673
01:13:32,535 --> 01:13:35,030
私はそれを書く行くかもしれません
データベースへのデータバック。

1674
01:13:35,030 --> 01:13:38,100
誰かがレコードを変更した場合、
タイムスタンプが変更されている可能性があります。

1675
01:13:38,100 --> 01:13:40,370
そして、そのように私の条件付き
更新は、更新プログラムを言うことができます

1676
01:13:40,370 --> 01:13:42,340
タイムスタンプは、これを等しい場合。

1677
01:13:42,340 --> 01:13:46,290
または更新が誰かため失敗します
その間にレコードを更新しました。

1678
01:13:46,290 --> 01:13:48,290
>> それは我々が楽観的ロックと呼んでいるものです。

1679
01:13:48,290 --> 01:13:50,670
それはその人のこと
で来て、それを変更することができ、

1680
01:13:50,670 --> 01:13:53,100
私はそれを検出するつもりです
私が戻ったときに書き込みます。

1681
01:13:53,100 --> 01:13:56,106
そして私は実際にそれを読むことができます
データとは、ああ、彼はこれを変更し、言います。

1682
01:13:56,106 --> 01:13:57,230
私はそれを考慮して必要があります。

1683
01:13:57,230 --> 01:14:00,490
そして私は、私の中のデータを変更することができます
記録し、別の更新を適用します。

1684
01:14:00,490 --> 01:14:04,330
ですから、これらの増分をキャッチすることができます
時間の間に発生するアップデート

1685
01:14:04,330 --> 01:14:08,740
データを読み取り、その
時間あなたはデータを書き込むことがあります。

1686
01:14:08,740 --> 01:14:11,520
>> 聴衆：そしてフィルター
式は実際にはないことを意味

1687
01:14:11,520 --> 01:14:13,020
番号またはnot--で

1688
01:14:13,020 --> 01:14:14,316
>> 【声を挟ん]

1689
01:14:14,316 --> 01:14:16,232
RICKフーリハン：私はしません
この中にあまりにも多くを得ます。

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
私は推測of--だから我々は多くを得ます、
50％以上it--ものです

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
物事の1だから、
このタイプのデータについて

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
そしておそらく、30日後、私はしないでください
でも、それがすべてを気にする必要があります。

1735
01:16:32,940 --> 01:16:35,020
私はWCUのを取ることができます
1までのすべての方法、

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
あなたを知って、Twitterのための
たとえば、ホットつぶやき。

1766
01:17:48,870 --> 01:17:51,280
誰もが来ると
そのツイートをつかみます。

1767
01:17:51,280 --> 01:17:52,680
製品カタログには、私は販売を得ました。

1768
01:17:52,680 --> 01:17:54,120
私は熱い販売を得ました。

1769
01:17:54,120 --> 01:17:57,277
私は7万の要求を持って
第二製品のために来て

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
そして、これへの最初のアプローチ
、[OK]を、たとえば、問題はないかもしれません。

1805
01:19:30,194 --> 01:19:31,110
私は生のメッセージを持っています。

1806
01:19:31,110 --> 01:19:33,710
[聞こえない]を来るメッセージ、
メッセージIDは、それは素晴らしいことです。

1807
01:19:33,710 --> 01:19:35,070
それは私の固有のハッシュです。

1808
01:19:35,070 --> 01:19:38,280
私は2つのGSIの、いずれかを作成するつもりです
私の受信トレイのために、私の送信ボックスに1つずつ。

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のために4キロバイトです。

1825
01:20:21,730 --> 01:20:24,450
>> [OK]を、のと一緒に行きましょう
最終的には一貫性のある読み取ります。

1826
01:20:24,450 --> 01:20:28,640
私はまだ1600 RCUの食べています
ただダビデの受信トレイを読み取ります。

1827
01:20:28,640 --> 01:20:29,950
痛いです。

1828
01:20:29,950 --> 01:20:31,980
[OK]を、今のは、考えてみましょう
アプリがどのように機能するかについて。

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
そのof--一部として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
RICKフーリハン：はい、それは伝えます
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
[OK]を、今私の受信トレイは、
実際にはるかに小さいです。

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
それはに戻ってもOKです
サーバーとモデルを再作成します、

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
国土地理院は、出て動作します。

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
そして、我々は2つ​​のインデックスを持っています
そのテーブルのオフに回転しています。

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あたりが、それはOKですが、

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
うわあ、データベース
パフォーマンスはひどいです。

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
RICKフーリハン：増やしますか？

1988
01:27:32,513 --> 01:27:33,520
対象：ソースポイント。

1989
01:27:33,520 --> 01:27:34,410
RICKフーリハン：ソースポイント？

1990
01:27:34,410 --> 01:27:37,500
対象者：情報から、
どこに情報がから来ていますか？

1991
01:27:37,500 --> 01:27:38,250
RICKフーリハン：いいえ

1992
01:27:38,250 --> 01:27:41,820
私は増加している何を言っています
データストア内のパーティションの数

1993
01:27:41,820 --> 01:27:44,060
スループットを向上させることができます。

1994
01:27:44,060 --> 01:27:48,300
だから何がここで起こっているユーザであります
ここまでEC2インスタンスに入ってきます、

1995
01:27:48,300 --> 01:27:50,780
よく、私は、ユーザーが必要な場合
それはMにですが、私はここに行きますよ。

1996
01:27:50,780 --> 01:27:53,560
NからPに、私はここに行きますよ。

1997
01:27:53,560 --> 01:27:55,060
PからZまで、私はここに行きますよ。

1998
01:27:55,060 --> 01:27:57,120
>> 聴衆：OK、それらので、それらがあります
すべての異なるノードに格納されていますか？

1999
01:27:57,120 --> 01:27:57,911
>> RICKフーリハン：はい。

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
>> 今、私はで行きたいと私はget--たい
私はこれらの個人的なリーダーボードを得ます。

2026
01:29:10,010 --> 01:29:12,827
私は何をしたい取りに行くです
すべてのユーザー全体のトップスコア。

2027
01:29:12,827 --> 01:29:13,660
だから私はそれをどのように行うのですか？

2028
01:29:13,660 --> 01:29:18,070
私の記録は、上のハッシュ化されたとき
ユーザーIDは、ゲームにありました、

2029
01:29:18,070 --> 01:29:20,740
よく私は先に行くつもりです
そして、再構築は、国土地理院が作成し、

2030
01:29:20,740 --> 01:29:22,370
私はそのデータを再構築するつもりです。

2031
01:29:22,370 --> 01:29:27,310
>> 今、私は上のハッシュするつもりです
ゲームですBoardName、。

2032
01:29:27,310 --> 01:29:29,800
そして、私はトップスコアに及ぶするつもりです。

2033
01:29:29,800 --> 01:29:31,540
そして今、私は別のバケットを作成しました。

2034
01:29:31,540 --> 01:29:34,790
私は、同じテーブルを使用しています、
同じ項目のデータ。

2035
01:29:34,790 --> 01:29:39,870
しかし、私は与えバケツを作成しています
私のゲームによって、トップスコアの集計。

2036
01:29:39,870 --> 01:29:43,180
>> そして私は、そのテーブルを照会することができます
その情報を取得します。

2037
01:29:43,180 --> 01:29:50,890
だから私は、最大そのクエリパターンを設定しました
セカンダリインデックスでサポートされて。

2038
01:29:50,890 --> 01:29:54,556
今、彼らはBoardName並べ替えることができます
とに応じて、TopScoreによってソート。

2039
01:29:54,556 --> 01:29:57,180
あなたが見ることができるので、これらは種類があります
あなたがゲーム内で取得するユースケース。

2040
01:29:57,180 --> 01:30:02,190
私たちは、ゲームに入るもう一つの良いユースケース
賞を受賞し、誰が賞を受賞していますです。

2041
01:30:02,190 --> 01:30:05,340
そして、これは偉大なユースケースです
我々はまばらなインデックスを呼び出す場所。

2042
01:30:05,340 --> 01:30:07,340
スパースインデックスがあります
生成する機能

2043
01:30:07,340 --> 01:30:10,850
必ずしもないインデックス
テーブルの上のすべての単一の項目が含まれています。

2044
01:30:10,850 --> 01:30:11,470
そして、なぜありませんか？

2045
01:30:11,470 --> 01:30:14,540
ためているのアトリビュート
インデックスを作成すると、すべてのアイテムには存在しません。

2046
01:30:14,540 --> 01:30:16,460
>> この特にそう
ケースを使用して、私が言っています、

2047
01:30:16,460 --> 01:30:19,240
あなたは何を、私はするつもりだ知っています
賞という属性を作成します。

2048
01:30:19,240 --> 01:30:22,970
そして、私はすべてのユーザーを与えるつもりです
それは属性賞を持っています。

2049
01:30:22,970 --> 01:30:25,950
賞がある持っていないユーザー
その属性を持っているつもりはありません。

2050
01:30:25,950 --> 01:30:27,800
だから私は作成したとき
インデックス、ユーザーのみ

2051
01:30:27,800 --> 01:30:28,960
表示しようとしていること
インデックスにアップされています

2052
01:30:28,960 --> 01:30:31,050
実際に賞を獲得しているもの。

2053
01:30:31,050 --> 01:30:34,440
だから、できるようにする素晴らしい方法です
そのフィルタのインデックスを作成します

2054
01:30:34,440 --> 01:30:40,580
そうでない非常に、非常に選択的です
インデックスにテーブル全体を持っています。

2055
01:30:40,580 --> 01:30:43,050
>> だから我々はここで時間に少なくなっています。

2056
01:30:43,050 --> 01:30:49,190
私が先に行くと、スキップするつもりです
アウトと、このシナリオをスキップします。

2057
01:30:49,190 --> 01:30:52,625
少し話about--

2058
01:30:52,625 --> 01:30:54,460
>> 聴衆：私は、簡単な質問を求めることができますか？

2059
01:30:54,460 --> 01:30:56,722
一つは重い書くのですか？

2060
01:30:56,722 --> 01:30:57,680
RICKフーリハン：何ですか？

2061
01:30:57,680 --> 01:30:58,596
観客は：重い書きます。

2062
01:30:58,596 --> 01:31:01,270
RICKフーリハン：重い書きます。

2063
01:31:01,270 --> 01:31:03,460
そうねぇ。

2064
01:31:03,460 --> 01:31:06,220
>> 聴衆：またはそのされていません
何かすることができますだけ

2065
01:31:06,220 --> 01:31:08,809
ほんの数秒での声？

2066
01:31:08,809 --> 01:31:10,850
RICKフーリハン：私たちは行きます
投票のシナリオによる。

2067
01:31:10,850 --> 01:31:11,670
それは悪いことではありません。

2068
01:31:11,670 --> 01:31:14,580
あなたたちは数分を持っていますか？

2069
01:31:14,580 --> 01:31:15,860
OK。

2070
01:31:15,860 --> 01:31:17,890
>> だから我々は、投票について話しましょう​​。

2071
01:31:17,890 --> 01:31:20,250
だから、リアルタイム投票、我々が持っています
投票のための要件。

2072
01:31:20,250 --> 01:31:25,250
要件は、我々が許可されていることです
一人一人は一度だけ投票します。

2073
01:31:25,250 --> 01:31:28,060
私たちは誰もができることがないようにしたいです
彼らの投票を変更することができます。

2074
01:31:28,060 --> 01:31:31,045
我々は、リアルタイム集計をしたいです
そして、人口統計のための分析

2075
01:31:31,045 --> 01:31:34,210
我々はあることを行っていること
サイト上でユーザーに示します。

2076
01:31:34,210 --> 01:31:35,200
>> このシナリオを考えます。

2077
01:31:35,200 --> 01:31:37,550
私たちは現実の多くの仕事
彼らはどこだテレビ番組

2078
01:31:37,550 --> 01:31:38,960
物事のこれらの正確な型をしています。

2079
01:31:38,960 --> 01:31:41,584
だから、シナリオを考えることができ、
私たちは何百万を持っています

2080
01:31:41,584 --> 01:31:43,959
そこの十代の少女
自分の携帯電話で

2081
01:31:43,959 --> 01:31:46,250
投票し、投票し、
彼らは誰に投票

2082
01:31:46,250 --> 01:31:48,610
最も人気のあるであることがわかりました。

2083
01:31:48,610 --> 01:31:50,830
したがって、これらはのいくつかであります
我々は実行要件。

2084
01:31:50,830 --> 01:31:52,990
>> だから最初のテイク
この問題を解決します

2085
01:31:52,990 --> 01:31:55,090
構築することであろう
非常に単純なアプリケーション。

2086
01:31:55,090 --> 01:31:56,490
だから私はこのアプリを持っています。

2087
01:31:56,490 --> 01:31:57,950
私はそこにいくつかの有権者を持っています。

2088
01:31:57,950 --> 01:31:59,980
彼らは、投票のアプリを打つ、でてきます。

2089
01:31:59,980 --> 01:32:03,440
私はいくつかの生の票テーブルを持っています
私はちょうどにそれらの票をダンプします。

2090
01:32:03,440 --> 01:32:05,780
私はいくつかの集計を持っています
票テーブルその

2091
01:32:05,780 --> 01:32:09,490
私の分析や人口統計を行います、
私たちはそこにこのすべてを入れます。

2092
01:32:09,490 --> 01:32:11,420
>> そして、これは素晴らしいです。

2093
01:32:11,420 --> 01:32:12,332
人生は素晴らしい。

2094
01:32:12,332 --> 01:32:15,040
生命の私たちがいることを知るまでは良いです
常に1つまたは2つあります

2095
01:32:15,040 --> 01:32:16,879
選挙で普及している人。

2096
01:32:16,879 --> 01:32:19,420
1つまたは2つのものがあります
人々は本当に気にしています。

2097
01:32:19,420 --> 01:32:22,340
そして、あなたはで投票している場合
スケール、私は突然のすべて

2098
01:32:22,340 --> 01:32:26,360
の地獄を打っことになるだろう
2候補者は、1つまたは2つの候補者。

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
私たちが知っている何か、ランダム
1と100の間の値、

2108
01:32:54,192 --> 01:32:56,620
100〜1,000、
または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
私はランダムに生成しています
1と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
候補Aは、今持っています
xの総投票数。

2130
01:33:53,830 --> 01:33:55,690
>> 今両方の書き込み
クエリおよび読取り問合せ

2131
01:33:55,690 --> 01:33:58,160
うまく分散されています
私は全体の書いているので、

2132
01:33:58,160 --> 01:34:00,320
私は、キーの数百を越え読んでいます。

2133
01:34:00,320 --> 01:34:03,500
私は書いていないことだし、
今つのキーを越え読書。

2134
01:34:03,500 --> 01:34:04,950
だから、偉大なパターンです。

2135
01:34:04,950 --> 01:34:08,090
>> これはおそらく実際には一つです
最も重要な設計の

2136
01:34:08,090 --> 01:34:10,420
NoSQLの中のスケールのためのパターン。

2137
01:34:10,420 --> 01:34:14,470
あなたは、このタイプのを見ることができます
すべての味のデザインパターン。

2138
01:34:14,470 --> 01:34:19,100
MongoDBは、DynamoDBの、それはしていません
問題は、我々はすべてこれをしなければなりません。

2139
01:34:19,100 --> 01:34:21,840
あなたが扱っているときので、
これらの巨大な集合体で、

2140
01:34:21,840 --> 01:34:26,650
あなたはへの道を把握する必要があり
バケットを横断して広がります。

2141
01:34:26,650 --> 01:34:29,512
これは、あなたがそれを行う方法です。

2142
01:34:29,512 --> 01:34:31,220
すべての権利なので、どのような
あなたが今やっています

2143
01:34:31,220 --> 01:34:35,252
あなたは、読み取りをトレードオフしているされています
書き込みのスケーラビリティのためのコスト。

2144
01:34:35,252 --> 01:34:37,085
私の読み取りのコストは
もう少し複雑な

2145
01:34:37,085 --> 01:34:40,220
私は読んでから行かなければなりません
百バケットの代わりに、1。

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
だから、心配する必要はありません
それを2回処理について

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
RICKフーリハン：うん、ストリーム
ダウンしたことがないことが保証されています。

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
それはOKです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
>> それは後に今あるものを新しいイメージ、
ビューの別のタイプのUpdate、

2227
01:38:07,160 --> 01:38:07,660
得られる。

2228
01:38:07,660 --> 01:38:09,660
あなたは、新旧両方の画像を得ることができます。

2229
01:38:09,660 --> 01:38:10,660
たぶん私はそれらの両方をしたいです。

2230
01:38:10,660 --> 01:38:11,790
私はそれが何だったか見てみたいです。

2231
01:38:11,790 --> 01:38:13,290
私はそれがに変更内容を確認したいと思います。

2232
01:38:13,290 --> 01:38:15,340
>> 私は、コンプライアンス・タイプを持っています
実行されるプロセスの。

2233
01:38:15,340 --> 01:38:17,430
それはそれを確認する必要があります
これらのものは変更されたとき、

2234
01:38:17,430 --> 01:38:21,840
彼らは、ある範囲内だということ
または特定のパラメータの範囲内。

2235
01:38:21,840 --> 01:38:23,840
>> そして多分私だけ
変更かを知る必要があります。

2236
01:38:23,840 --> 01:38:26,240
私が変更されどのような項目を気にしません。

2237
01:38:26,240 --> 01:38:28,580
私が知っている必要がありますする必要はありません
どの属性が変更されました。

2238
01:38:28,580 --> 01:38:30,882
私はちょうどそれを知っている必要があります
項目がタッチされています。

2239
01:38:30,882 --> 01:38:33,340
したがって、これらは、ビューのタイプです
あなたはストリームを降りること

2240
01:38:33,340 --> 01:38:35,960
あなたはと対話することができます。

2241
01:38:35,960 --> 01:38:37,840
>> アプリケーションこと
ストリームを消費し、

2242
01:38:37,840 --> 01:38:39,298
これは、これが動作する方法の一種です。

2243
01:38:39,298 --> 01:38:42,570
DynamoDBのクライアントがに尋ねます
テーブルにデータをプッシュ。

2244
01:38:42,570 --> 01:38:44,750
ストリームは、私たちが破片を呼んでいるものに展開します。

2245
01:38:44,750 --> 01:38:47,380
シャードは、スケーリングされ
独立して、テーブルの。

2246
01:38:47,380 --> 01:38:50,660
彼らは完全にラインアップはありません
あなたのテーブルのパーティションに。

2247
01:38:50,660 --> 01:38:52,540
そして理由はあります
彼らが並ぶので、

2248
01:38:52,540 --> 01:38:55,430
容量、現在の
テーブルの容量。

2249
01:38:55,430 --> 01:38:57,600
>> 彼らは彼らの中に展開します
独自のオートスケールグループ、

2250
01:38:57,600 --> 01:39:00,800
彼らは応じてスピンアウトを開始
で来ているどのように多くの書き込み時に、

2251
01:39:00,800 --> 01:39:03,090
どのように多くのreads--本当にそれだと、書いています。

2252
01:39:03,090 --> 01:39:05,820
どのreads--しかし、何もありません
多くの書き込みがでてきています。

2253
01:39:05,820 --> 01:39:08,200
>> そして背中に
最後に、我々は持っているものたち

2254
01:39:08,200 --> 01:39:11,390
KCL、またはキネシスクライアント・ライブラリを呼び出します。

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
9つの領域があります。
世界中の。

2279
01:40:29,230 --> 01:40:32,100
だから私need--があるかもしれません
アジアでは、ユーザー、ユーザーが持っているかもしれません

2280
01:40:32,100 --> 01:40:34,150
アメリカ合衆国東海岸インチ

2281
01:40:34,150 --> 01:40:38,980
彼らは、異なるデータを持っています
局所的に分散される必要があります。

2282
01:40:38,980 --> 01:40:42,510
そしておそらくユーザーがから飛びます
米国に渡ってアジア、

2283
01:40:42,510 --> 01:40:45,020
私は複製したいです
彼と彼のデータ。

2284
01:40:45,020 --> 01:40:49,340
彼は飛行機を降りるときに、彼が持っています
自分の携帯アプリを使用して良い経験。

2285
01:40:49,340 --> 01:40:52,360
>> あなたは、クロス領域を使用することができます
これを行うには、レプリケーション・ライブラリ。

2286
01:40:52,360 --> 01:40:55,730
基本的に我々が持っています
二つの技術を提供しました。

2287
01:40:55,730 --> 01:40:59,400
一つは、あなたができるコンソールアプリケーションです
独自のEC2インスタンス上に立っています。

2288
01:40:59,400 --> 01:41:01,240
それは純粋な複製を実行します。

2289
01:41:01,240 --> 01:41:02,720
そして、我々はあなたのライブラリーを与えました。

2290
01:41:02,720 --> 01:41:06,070
あなたが構築するために使用できるライブラリ
独自のアプリケーションあなたの場合

2291
01:41:06,070 --> 01:41:10,740
それに狂気の事をしたいですdata--
フィルタは、その一部のみを複製します

2292
01:41:10,740 --> 01:41:14,120
データの回転、に移動
別のテーブル、というようになど。

2293
01:41:14,120 --> 01:41:18,700

2294
01:41:18,700 --> 01:41:20,520
だから、それがどのように見えるかのようなものです。

2295
01:41:20,520 --> 01:41:23,690
>> DynamoDBのストリームであることができます
私たちはラムダと呼ぶものによって処理されます。

2296
01:41:23,690 --> 01:41:27,394
我々は、イベントについて少し言及しました
駆動型アプリケーション・アーキテクチャ。

2297
01:41:27,394 --> 01:41:28,810
ラムダは、の重要な構成要素です。

2298
01:41:28,810 --> 01:41:32,840
ラムダは、必要に応じて発生させたコードです
特定のイベントに応答しました。

2299
01:41:32,840 --> 01:41:36,020
これらのイベントの一つは、可能性があり
ストリーム上に現れたレコード。

2300
01:41:36,020 --> 01:41:39,100
レコードがストリームに表示された場合は、
我々は、このJava関数を呼び出します。

2301
01:41:39,100 --> 01:41:44,980
まあ、これはJavaScript、およびラムダです
Node.jsの、JavaやPythonは、サポートしています

2302
01:41:44,980 --> 01:41:47,820
すぐにサポートします
他の言語にも。

2303
01:41:47,820 --> 01:41:50,940
そして、それは純粋なコードですが、言えば十分。

2304
01:41:50,940 --> 01:41:53,610
Javaでは書き込みは、クラスを定義します。

2305
01:41:53,610 --> 01:41:55,690
あなたは、ラムダにJARを押し上げ。

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
実行するには、Elastic MapReduceの
リアルタイムストリーミング集計オフ

2350
01:43:51,990 --> 01:43:53,180
そのデータの。

2351
01:43:53,180 --> 01:43:55,480
>> したがって、これらは私達のものです
あまり話をしませんでした。

2352
01:43:55,480 --> 01:43:57,375
しかし、彼らは追加しています
来技術

2353
01:43:57,375 --> 01:44:00,310
あなたが探している時に負担します
これらのタイプのシナリオで。

2354
01:44:00,310 --> 01:44:03,160
>> すべての権利、それは程度ですので、
DynamoDBのStreamsを使用した分析。

2355
01:44:03,160 --> 01:44:05,340
あなたは、デデュープを収集することができます
データは、すべての種類を行います

2356
01:44:05,340 --> 01:44:09,490
すてきなものの中で、集計データ
メモリは、それらの派生テーブルを作成します。

2357
01:44:09,490 --> 01:44:13,110
それは巨大なユースケースです
その顧客の多く

2358
01:44:13,110 --> 01:44:16,950
ネストされたを取る、と関与しています
これらのJSONドキュメントのプロパティ

2359
01:44:16,950 --> 01:44:18,946
そして、追加の索引を作成します。

2360
01:44:18,946 --> 01:44:21,680

2361
01:44:21,680 --> 01:44:23,150
>> 私たちは最後にしています。

2362
01:44:23,150 --> 01:44:26,689
私と一緒にベアリングをありがとうございました。

2363
01:44:26,689 --> 01:44:28,480
それではについてお話しましょう
参照アーキテクチャ。

2364
01:44:28,480 --> 01:44:33,440
DynamoDBのはそうの真ん中に座っています
AWSインフラストラクチャの多く。

2365
01:44:33,440 --> 01:44:37,090
基本的にはそれをフックすることができます
あなたが望むものまで。

2366
01:44:37,090 --> 01:44:45,600
アプリケーションは、ディナモには、使用して構築します
ラムダ、ElastiCache、CloudSearch、

2367
01:44:45,600 --> 01:44:49,890
弾性に出てデータをプッシュ
MapReduceの、DynamoDBのからのインポート・エクスポート

2368
01:44:49,890 --> 01:44:52,370
S3では、ワークフローのすべての種類に。

2369
01:44:52,370 --> 01:44:54,120
しかし、おそらく最高
話をすること、

2370
01:44:54,120 --> 01:44:56,119
これが本当に何であります
ときに我々は興味深いです

2371
01:44:56,119 --> 01:44:58,350
イベント駆動型アプリケーションについて話しています。

2372
01:44:58,350 --> 01:45:00,300
>> これは一例です
社内プロジェクト

2373
01:45:00,300 --> 01:45:04,850
私たちが実際にいる場所を持っていること
調査結果を収集する出版。

2374
01:45:04,850 --> 01:45:07,700
電子メールのリンクでだから、
我々はそこよ、送り出します

2375
01:45:07,700 --> 01:45:11,350
クリック言って少しリンクすること
ここでは、調査に応答します。

2376
01:45:11,350 --> 01:45:14,070
そして、ときに人がクリック
そのリンクは、何が起こります

2377
01:45:14,070 --> 01:45:18,020
彼らは安全なプルダウンであります
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
これは、複雑なJavaScriptを持っています
それが実行していること。

2383
01:45:30,160 --> 01:45:33,557
だから、非常に豊富なアプリケーションです
クライアントのブラウザで実行されています。

2384
01:45:33,557 --> 01:45:36,390
彼らはないしていることを知りません
バックエンドサーバとの対話。

2385
01:45:36,390 --> 01:45:38,220
この時点で、すべてのブラウザです。

2386
01:45:38,220 --> 01:45:41,780
>> 彼らはどのように結果を公開
我々は、Amazon APIゲートウェイを呼び出します。

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サーバ側に建てられた使用します
暗号化とAmazonのキー管理

2412
01:46:47,240 --> 01:46:51,600
サービス私はその鍵を持っているように、
定期的に回転させることができ、

2413
01:46:51,600 --> 01:46:55,010
私は、そのPIIデータを保護することができます
この全体のワークフローの一部として。

2414
01:46:55,010 --> 01:46:55,870
>> だから私は何をしましたか？

2415
01:46:55,870 --> 01:47:00,397
私はちょうど全体を展開してきました
アプリケーション、および私は、サーバーを持っていません。

2416
01:47:00,397 --> 01:47:02,980
だから何のイベントアプリケーションを駆動させます
アーキテクチャは、あなたのために行います。

2417
01:47:02,980 --> 01:47:05,730
>> 今、あなたが考える場合
this--ためのユースケース

2418
01:47:05,730 --> 01:47:08,730
私たちは、私が話している他の顧客を持っています
この正確なアーキテクチャの人に

2419
01:47:08,730 --> 01:47:14,560
驚異的に大規模なキャンペーンを実行し、誰が
私のああ、このを見ていきます。

2420
01:47:14,560 --> 01:47:17,840
今、彼らができるので、
基本的にはそこにそれを押し出します、

2421
01:47:17,840 --> 01:47:21,900
そのキャンペーンはただ座ってみましょう
それが起動し、ないまで

2422
01:47:21,900 --> 01:47:24,400
図を心配する必要はあり
インフラの種類

2423
01:47:24,400 --> 01:47:26,120
それをサポートするためにそこになるだろう。

2424
01:47:26,120 --> 01:47:28,600
そして、できるだけ早く
そのキャンペーンが行われ、

2425
01:47:28,600 --> 01:47:31,520
それは、インフラストラクチャのようなものです
ちょうどすぐに消えます

2426
01:47:31,520 --> 01:47:33,680
実際にそこにあるため
何のインフラストラクチャではありません。

2427
01:47:33,680 --> 01:47:35,660
これは、ラムダに座っているだけのコードです。

2428
01:47:35,660 --> 01:47:38,560
これは、DynamoDBのに座っているだけのデータです。

2429
01:47:38,560 --> 01:47:41,340
それは素晴らしい方法です
アプリケーションを構築することができます。

2430
01:47:41,340 --> 01:47:43,970
>> 聴衆：だから、もっとあります
それは場合よりもはかないです

2431
01:47:43,970 --> 01:47:45,740
それは、実際のサーバー上に格納された場合はどうなりますか？

2432
01:47:45,740 --> 01:47:46,823
>> RICKフーリハン：もちろんです。

2433
01:47:46,823 --> 01:47:49,190
そのサーバインスタンスので、
7/24でなければなりません。

2434
01:47:49,190 --> 01:47:51,954
それはのために利用可能である必要があります
に対応する誰か。

2435
01:47:51,954 --> 01:47:52,620
さて、どうなったと思いますか？

2436
01:47:52,620 --> 01:47:55,410
S3は7/24可能です。

2437
01:47:55,410 --> 01:47:57,100
S3は常に応答します。

2438
01:47:57,100 --> 01:47:59,320
そして、S3は非常に、非常に良いです
オブジェクトを提供しました。

2439
01:47:59,320 --> 01:48:02,590
これらのオブジェクトは、HTMLファイル、またはすることができます
JavaScriptファイル、または何でもしたいです。

2440
01:48:02,590 --> 01:48:07,430
あなたは非常にリッチなWebアプリケーションを実行することができます
S3バケットのうち、人々が行います。

2441
01:48:07,430 --> 01:48:10,160
>> そして、そのためには、ここでアイデアです
道から離れて取得することです

2442
01:48:10,160 --> 01:48:11,270
我々はそれについて考えるために使用されます。

2443
01:48:11,270 --> 01:48:14,270
我々は、すべてで考えるために使用
サーバおよびホストの観点から。

2444
01:48:14,270 --> 01:48:16,580
それはもうそのことについてではありません。

2445
01:48:16,580 --> 01:48:19,310
これは、コードとしてのインフラについてです。

2446
01:48:19,310 --> 01:48:22,470
クラウドにコードを展開し、
雲があなたのためにそれを実行してみましょう。

2447
01:48:22,470 --> 01:48:24,980
そしてそれは、AWSがやろうとしているものです。

2448
01:48:24,980 --> 01:48:29,690
>> 聴衆：真ん中にだからあなたの金の箱
APIのゲートウェイは、サーバーのようではありません

2449
01:48:29,690 --> 01:48:30,576
その代わりjust--です

2450
01:48:30,576 --> 01:48:32,850
>> RICKフーリハン：あなたが考えることができます
そのサーバファサードとして。

2451
01:48:32,850 --> 01:48:38,040
それはすべてが、それは、HTTPを取るよです
要求し、別のプロセスにマッピングします。

2452
01:48:38,040 --> 01:48:39,192
それはそれがないすべてです。

2453
01:48:39,192 --> 01:48:41,525
そして、この場合には、我々は、マッピングしています
それラムダ関数に。

2454
01:48:41,525 --> 01:48:44,119

2455
01:48:44,119 --> 01:48:45,410
すべての権利なので、それは私が得たすべてです。

2456
01:48:45,410 --> 01:48:46,190
ありがとうございます。

2457
01:48:46,190 --> 01:48:46,800
それは有り難いです。

2458
01:48:46,800 --> 01:48:48,100
私たちは時間をかけて少ししたい知っています。

2459
01:48:48,100 --> 01:48:49,980
そして、うまくいけば、あなたたちは持って
情報の少し

2460
01:48:49,980 --> 01:48:51,410
今日は離れて取ることができます。

2461
01:48:51,410 --> 01:48:53,520
私が行った場合私は謝罪します
あなたの頭の一部の上に、

2462
01:48:53,520 --> 01:48:56,697
しかしの良いたくさんあり​​ます
基本的な基礎知識

2463
01:48:56,697 --> 01:48:58,280
私はあなたのために非常に価値があると思います。

2464
01:48:58,280 --> 01:48:59,825
だから、私を持ってくれてありがとう。

2465
01:48:59,825 --> 01:49:00,325
[拍手]

2466
01:49:00,325 --> 01:49:02,619
聴衆：[聞こえません]
あなたが言っていたときであります

2467
01:49:02,619 --> 01:49:05,160
あなたが事を通過しなければなりませんでした
最初から最後まで

2468
01:49:05,160 --> 01:49:07,619
正しい値を取得します
同じ値か、

2469
01:49:07,619 --> 01:49:09,410
どのようにでしょう値
[聞こえない]場合は変更します。

2470
01:49:09,410 --> 01:49:10,480
>> RICKフーリハン：ああ、冪等？

2471
01:49:10,480 --> 01:49:11,800
値がどのように変化するでしょうか？

2472
01:49:11,800 --> 01:49:15,180
まあ、私は実行しなかった場合ので、
最後に、それはすべての方法、

2473
01:49:15,180 --> 01:49:19,770
私は変更のか分かりません
ラストマイルで行われました。

2474
01:49:19,770 --> 01:49:22,144
それはあることを行っていません
私が見たものと同じデータ。

2475
01:49:22,144 --> 01:49:24,560
聴衆：ああ、そうちょうどあなた
入力全体をもらっていません。

2476
01:49:24,560 --> 01:49:24,770
RICKフーリハン：右。

2477
01:49:24,770 --> 01:49:26,895
あなたは最初から行かなければなりません
最後に、それです

2478
01:49:26,895 --> 01:49:29,280
整合性のとれた状態になるだろう。

2479
01:49:29,280 --> 01:49:31,520
クール。

2480
01:49:31,520 --> 01:49:35,907
>> 聴衆：だから、私たちを示したDynamoDBの
ドキュメントまたはキー値を行うことができます。

2481
01:49:35,907 --> 01:49:38,740
そして、私たちは多くの時間を費やし
ハッシュと方法とキー値

2482
01:49:38,740 --> 01:49:40,005
それを周りに反転します。

2483
01:49:40,005 --> 01:49:43,255
あなたは、これらの表を見ると、ということです
文書のアプローチを残し？

2484
01:49:43,255 --> 01:49:44,600
>> RICKフーリハン：私はないでしょう
それを残すと言います。

2485
01:49:44,600 --> 01:49:45,855
>> 聴衆：彼らはthe--から分離しました

2486
01:49:45,855 --> 01:49:49,140
>> RICKフーリハン：文書に
アプローチ、DynamoDBの中のドキュメントタイプ

2487
01:49:49,140 --> 01:49:50,880
ちょうど別の属性として考えますさ。

2488
01:49:50,880 --> 01:49:53,560
これは、含まれている属性です
階層データ構造。

2489
01:49:53,560 --> 01:49:56,980
そしてクエリで、
あなたは、プロパティを使用することができます

2490
01:49:56,980 --> 01:49:59,480
オブジェクトの表記を使用して、それらのオブジェクトの。

2491
01:49:59,480 --> 01:50:03,562
だから私は、ネストされた上でフィルタリングすることができます
JSONドキュメントのプロパティ。

2492
01:50:03,562 --> 01:50:05,520
聴衆：だからいつでも私
文書のアプローチを行い、

2493
01:50:05,520 --> 01:50:07,906
私は、ソートのtabular--に到着することができます

2494
01:50:07,906 --> 01:50:08,780
聴衆：もちろんです。

2495
01:50:08,780 --> 01:50:09,800
聴衆：--indexesと
あなただけのについて話しましたもの。

2496
01:50:09,800 --> 01:50:11,280
RICKフーリハン：うん、
インデックスとすべてのこと、

2497
01:50:11,280 --> 01:50:13,363
ときにインデックスを作成します
JSONのプロパティ、

2498
01:50:13,363 --> 01:50:18,230
我々はそれを行う必要があるだろう方法がある場合
あなたはJSONオブジェクトまたは文書を挿入

2499
01:50:18,230 --> 01:50:20,780
ダイナモに、あなたは、ストリームを使用します。

2500
01:50:20,780 --> 01:50:22,400
ストリームは、入力を読んでいました。

2501
01:50:22,400 --> 01:50:24,340
あなたは、JSONを取得したいです
オブジェクトと[OK]を言うだろう、

2502
01:50:24,340 --> 01:50:26,030
私はインデックスを作成するプロパティは、何ですか？

2503
01:50:26,030 --> 01:50:28,717
>> あなたは、派生テーブルを作成します。

2504
01:50:28,717 --> 01:50:30,300
今では、それが今の仕組みです。

2505
01:50:30,300 --> 01:50:32,650
私たちはインデックスにあなたを許可しません
直接これらのプロパティ。

2506
01:50:32,650 --> 01:50:33,520
>> 聴衆：あなたの文書をTabularizing。

2507
01:50:33,520 --> 01:50:36,230
>> RICKフーリハン：その通り、平坦化
それは、まさに、それをtabularizing。

2508
01:50:36,230 --> 01:50:37,415
それはあなたがそれを行うものです。

2509
01:50:37,415 --> 01:50:37,860
>> 観客は：ありがとうございます。

2510
01:50:37,860 --> 01:50:39,609
>> RICKフーリハン：うん、
絶対に、あなたに感謝。

2511
01:50:39,609 --> 01:50:42,240
聴衆：だから、それは一種のです
モンゴはRedisのの分類器のを満たしています。

2512
01:50:42,240 --> 01:50:43,990
>> RICKフーリハン：うん、
それはそのような多くのです。

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