1
00:00:00,000 --> 00:00:04,969
>> [เล่นเพลง]

2
00:00:04,969 --> 00:00:06,010
RICK Houlihan: สิทธิทั้งหมด

3
00:00:06,010 --> 00:00:06,600
สวัสดีทุกคน.

4
00:00:06,600 --> 00:00:07,670
ชื่อของฉันคือริก Houlihan

5
00:00:07,670 --> 00:00:10,330
ฉันเป็นหลักอาวุโส
การแก้ปัญหาที่สถาปนิก AWS

6
00:00:10,330 --> 00:00:14,070
ผมเน้น NoSQL และ
เทคโนโลยี DynamoDB

7
00:00:14,070 --> 00:00:16,930
ฉันมาที่นี่ในวันนี้จะพูดคุยกับ
คุณเล็กน้อยเกี่ยวกับผู้

8
00:00:16,930 --> 00:00:18,970
>> พื้นหลังของฉันคือ
ส่วนใหญ่ในชั้นข้อมูล

9
00:00:18,970 --> 00:00:21,390
ผมใช้เวลาครึ่งหนึ่งของการพัฒนาของฉัน
ฐานข้อมูลการเขียนอาชีพ

10
00:00:21,390 --> 00:00:25,930
การเข้าถึงข้อมูลการแก้ปัญหา
สำหรับการใช้งานต่างๆ

11
00:00:25,930 --> 00:00:30,000
ฉันได้รับในการทำงานแบบเสมือนเมฆ
ประมาณ 20 ปี

12
00:00:30,000 --> 00:00:33,460
ดังนั้นก่อนที่จะมีเมฆเป็นเมฆ
เราเคยเรียกว่าคอมพิวเตอร์ยูทิลิตี้

13
00:00:33,460 --> 00:00:37,170
และความคิดที่ถูกมันก็เหมือน
PG & E, คุณจ่ายสำหรับสิ่งที่คุณใช้

14
00:00:37,170 --> 00:00:38,800
วันนี้เราเรียกว่าระบบคลาวด์

15
00:00:38,800 --> 00:00:41,239
>> แต่ในช่วงปีที่ผ่านมาฉันได้ทำงาน
สำหรับคู่ของ บริษัท

16
00:00:41,239 --> 00:00:42,530
คุณอาจไม่เคยได้ยิน

17
00:00:42,530 --> 00:00:47,470
แต่ผมได้รวบรวมรายชื่อของทางเทคนิค
ความสำเร็จผมคิดว่าคุณจะบอกว่า

18
00:00:47,470 --> 00:00:51,620
ฉันมีแปดสิทธิบัตรในระบบคลาวด์
การทำงานแบบเสมือนการออกแบบไมโครโพรเซสเซอร์

19
00:00:51,620 --> 00:00:54,440
การประมวลผลเหตุการณ์ที่ซับซ้อน
และพื้นที่อื่น ๆ ได้เป็นอย่างดี

20
00:00:54,440 --> 00:00:58,290
>> ดังนั้นวันนี้ผมเน้นส่วนใหญ่ใน NoSQL
เทคโนโลยีและคนรุ่นต่อไป

21
00:00:58,290 --> 00:00:59,450
ฐานข้อมูล

22
00:00:59,450 --> 00:01:03,370
และนั่นคือโดยทั่วไปสิ่งที่ฉันจะ
ที่นี่ที่จะพูดคุยกับคุณวันนี้เกี่ยวกับ

23
00:01:03,370 --> 00:01:06,030
ดังนั้นสิ่งที่คุณสามารถคาดหวัง
จากเซสชั่นนี้

24
00:01:06,030 --> 00:01:08,254
เราจะผ่านไปสั้น ๆ
ประวัติศาสตร์ของการประมวลผลข้อมูล

25
00:01:08,254 --> 00:01:10,420
มันเป็นประโยชน์เสมอ
เราเข้าใจที่มาจาก

26
00:01:10,420 --> 00:01:12,400
และทำไมเราที่เรามี

27
00:01:12,400 --> 00:01:15,600
และเราจะพูดคุยเล็ก ๆ น้อย ๆ
บิตเกี่ยวกับเทคโนโลยี NoSQL

28
00:01:15,600 --> 00:01:17,500
จากมุมมองพื้นฐาน

29
00:01:17,500 --> 00:01:19,870
>> เราจะได้รับในบางส่วนของ
DynamoDB internals

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
และบางส่วนของ internals
ของเทคโนโลยีที่ 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
เนื่องจากฐานข้อมูลที่เป็นจริง
รากฐานของ app ที่ทันสมัย

68
00:03:02,700 --> 00:03:04,810
มันเป็นรากฐาน
ของทุกโปรแกรม

69
00:03:04,810 --> 00:03:07,240
และวิธีการที่คุณสร้าง
ฐานข้อมูลวิธีที่คุณโครงสร้าง

70
00:03:07,240 --> 00:03:11,750
ว่าข้อมูลเป็นไปเพื่อกำหนดวิธีการที่
แอพลิเคชันที่คุณดำเนินการปรับขนาด

71
00:03:11,750 --> 00:03:14,640
>> ดังนั้นจำนวนมากของงานของฉันในวันนี้
คือการจัดการกับสิ่งที่

72
00:03:14,640 --> 00:03:17,180
ที่เกิดขึ้นเมื่อนักพัฒนา
ใช้วิธีการนี​​้

73
00:03:17,180 --> 00:03:19,510
และการจัดการกับผลพวง
ของโปรแกรมที่

74
00:03:19,510 --> 00:03:24,966
คือตอนนี้ปรับเกินกว่าเดิม
ความตั้งใจและความทุกข์ทรมานจากการออกแบบที่ไม่ดี

75
00:03:24,966 --> 00:03:26,840
เพื่อหวังว่าเมื่อคุณ
เดินออกไปในวันนี้คุณจะ

76
00:03:26,840 --> 00:03:29,010
มีคู่ของเครื่องมือใน
เข็มขัดของคุณที่จะให้คุณ

77
00:03:29,010 --> 00:03:32,566
จากการทำผิดพลาดเดียวกันนั้น

78
00:03:32,566 --> 00:03:33,066
ทั้งหมดขวา

79
00:03:33,066 --> 00:03:36,360
ดังนั้นเรามาพูดคุยเกี่ยวกับนิด ๆ หน่อย ๆ
ระยะเวลาของเทคโนโลยีฐานข้อมูล

80
00:03:36,360 --> 00:03:38,830
ฉันคิดว่าฉันอ่าน
บทความไม่ได้ว่านานมาแล้ว

81
00:03:38,830 --> 00:03:43,020
และจะพูดอะไรบางอย่างเกี่ยวกับ lines--
มันเป็นคำสั่งของกวีมาก

82
00:03:43,020 --> 00:03:46,590
มันบอกว่าประวัติศาสตร์
ของการประมวลผลข้อมูล

83
00:03:46,590 --> 00:03:49,350
เต็มรูปแบบของลายน้ำสูง
ความอุดมสมบูรณ์ของข้อมูล

84
00:03:49,350 --> 00:03:49,920
ตกลง.

85
00:03:49,920 --> 00:03:52,532
ตอนนี้ผมเดาว่าเป็นชนิดของความจริง

86
00:03:52,532 --> 00:03:54,990
แต่ที่จริงผมมองไปที่มีที่เป็น
ประวัติศาสตร์ที่เต็มไปจริง

87
00:03:54,990 --> 00:03:56,820
มีลายน้ำของความดันสูงข้อมูล

88
00:03:56,820 --> 00:04:00,040
เพราะอัตราการส่งข้อมูลของ
การบริโภคที่ไม่เคยไปลง

89
00:04:00,040 --> 00:04:01,360
มันจะไปถึง

90
00:04:01,360 --> 00:04:03,670
>> และนวัตกรรมที่เกิดขึ้นเมื่อ
เราจะเห็นความดันข้อมูลซึ่ง

91
00:04:03,670 --> 00:04:07,825
คือปริมาณของข้อมูลที่เป็น
ในตอนนี้ที่เข้ามาในระบบ

92
00:04:07,825 --> 00:04:12,027
และมันก็ไม่สามารถดำเนินการ
ได้อย่างมีประสิทธิภาพทั้งในเวลาหรือค่าใช้จ่ายใน

93
00:04:12,027 --> 00:04:14,110
และที่ว่าเมื่อเราเริ่มต้น
จะมองที่ความดันข้อมูล

94
00:04:14,110 --> 00:04:15,920
>> ดังนั้นเมื่อเรามองไปที่
ฐานข้อมูลครั้งแรกนี้

95
00:04:15,920 --> 00:04:17,180
เป็นสิ่งหนึ่งที่อยู่ระหว่างหูของเรา

96
00:04:17,180 --> 00:04:18,310
เราทุกคนเกิดมาพร้อมกับมัน

97
00:04:18,310 --> 00:04:19,194
มันเป็นฐานข้อมูลที่ดี

98
00:04:19,194 --> 00:04:21,110
แต่ก็มีความพร้อมสูง

99
00:04:21,110 --> 00:04:21,959
มันเสมอ

100
00:04:21,959 --> 00:04:23,930
คุณจะได้รับมัน

101
00:04:23,930 --> 00:04:24,890
>> แต่มันเป็นผู้ใช้คนเดียว

102
00:04:24,890 --> 00:04:26,348
ฉันไม่สามารถแบ่งปันความคิดของฉันกับคุณ

103
00:04:26,348 --> 00:04:28,370
คุณไม่สามารถได้รับความคิดของฉัน
เมื่อคุณต้องการให้พวกเขา

104
00:04:28,370 --> 00:04:30,320
และ abilitiy ของพวกเขาจะไม่ดีดังนั้น

105
00:04:30,320 --> 00:04:32,510
เราลืมสิ่ง

106
00:04:32,510 --> 00:04:36,540
ทุกขณะนี้แล้วหนึ่งของเราใบ
และย้ายไปดำรงอยู่อีก

107
00:04:36,540 --> 00:04:39,110
และเราสูญเสียทุกอย่าง
ที่อยู่ในฐานข้อมูลนั้น

108
00:04:39,110 --> 00:04:40,640
ดังนั้นนั่นไม่ใช่ทั้งหมดที่ดีที่

109
00:04:40,640 --> 00:04:43,189
>> และนี้ทำงานได้ดีในช่วงเวลา
เมื่อเรากลับในวันที่

110
00:04:43,189 --> 00:04:46,230
เมื่อทุกสิ่งที่เราจำเป็นจริงๆต้องรู้คือ
ที่เราจะไปในวันพรุ่งนี้

111
00:04:46,230 --> 00:04:49,630
หรือที่เรารวบรวมอาหารที่ดีที่สุด

112
00:04:49,630 --> 00:04:52,820
แต่ในขณะที่เราเริ่มที่จะเติบโตเป็น
อารยธรรมและรัฐบาลตั้งขึ้น

113
00:04:52,820 --> 00:04:55,152
ที่จะเข้ามาเป็นอยู่และ
ธุรกิจเริ่มต้นที่จะพัฒนาขึ้น

114
00:04:55,152 --> 00:04:57,360
เราเริ่มที่จะตระหนักถึงเรา
ต้องน้อยกว่าสิ่งที่

115
00:04:57,360 --> 00:04:58,210
ที่เราสามารถนำมาใส่ในหัวของเรา

116
00:04:58,210 --> 00:04:58,870
ทั้งหมดใช่มั้ย?

117
00:04:58,870 --> 00:05:00,410
>> เราจำเป็นต้องมีระบบของการบันทึก

118
00:05:00,410 --> 00:05:02,220
เราจำเป็นต้องเป็นสถานที่ที่จะสามารถจัดเก็บข้อมูล

119
00:05:02,220 --> 00:05:05,450
ดังนั้นเราจึงเริ่มเขียนเอกสาร
สร้างห้องสมุดและเก็บ

120
00:05:05,450 --> 00:05:08,000
เราเริ่มต้นการพัฒนา
ระบบบัญชีแยกประเภท

121
00:05:08,000 --> 00:05:12,200
และระบบการนับแยกประเภทที่
วิ่งโลกมานานหลายศตวรรษ

122
00:05:12,200 --> 00:05:15,580
และอาจจะนับพันปีแม้ในขณะที่
เราชนิดของการขยายตัวไปยังจุดที่

123
00:05:15,580 --> 00:05:18,420
ที่โหลดข้อมูลที่ค้นพบ
ความสามารถของระบบเหล่านั้น

124
00:05:18,420 --> 00:05:19,870
เพื่อให้สามารถมีมัน

125
00:05:19,870 --> 00:05:22,070
>> และสิ่งนี้เกิดขึ้นจริงในยุค 1880

126
00:05:22,070 --> 00:05:22,570
ขวา?

127
00:05:22,570 --> 00:05:24,390
ใน 1880 สำรวจสำมะโนประชากรของสหรัฐ

128
00:05:24,390 --> 00:05:26,976
นี้เป็นจริงที่เปลี่ยน
จุดการประมวลผลข้อมูลที่ทันสมัย

129
00:05:26,976 --> 00:05:28,850
ตรงนี้คือจุดที่
ซึ่งจำนวนของข้อมูล

130
00:05:28,850 --> 00:05:32,060
ที่ถูกเก็บรวบรวมโดย
รัฐบาลสหรัฐก็มาถึงจุด

131
00:05:32,060 --> 00:05:34,005
ที่มันต้องใช้เวลาแปดปีในการประมวลผล

132
00:05:34,005 --> 00:05:36,350
>> ตอนนี้แปด years-- เป็น
คุณรู้ว่าการสำรวจสำมะโนประชากร

133
00:05:36,350 --> 00:05:39,180
วิ่งทุก 10 years-- จึงเป็น
ที่เห็นได้ชัดสวยตามเวลาที่เรา

134
00:05:39,180 --> 00:05:41,419
มี 1890 การสำรวจสำมะโนประชากร
จำนวนข้อมูลที่

135
00:05:41,419 --> 00:05:43,210
จะได้รับการประมวลผล
โดยรัฐบาล

136
00:05:43,210 --> 00:05:46,335
จะเกิน 10 ปีว่า
จะใช้เวลาในการสำรวจสำมะโนประชากรเปิดตัวใหม่

137
00:05:46,335 --> 00:05:47,250
นี่เป็นปัญหา

138
00:05:47,250 --> 00:05:49,000
>> ดังนั้นผู้ชายที่ชื่อเฮอร์แมน
Hollerith มาพร้อม

139
00:05:49,000 --> 00:05:52,640
และเขาคิดค้นหมัดบันทึกหน่วย
บัตร, เครื่องอ่านบัตรเจาะบัตรหมัด

140
00:05:52,640 --> 00:05:58,420
ตีตารางและการเปรียบเทียบของ
กลไกสำหรับเทคโนโลยีนี้

141
00:05:58,420 --> 00:06:01,860
และ บริษัท ที่ว่าเขาเกิดขึ้นที่
เวลาพร้อมกับคู่ของคนอื่น ๆ

142
00:06:01,860 --> 00:06:05,450
จริงกลายเป็นหนึ่งในเสาหลักของที่
บริษัท ขนาดเล็กที่เรารู้ว่าวันนี้เรียกว่าไอบีเอ็ม

143
00:06:05,450 --> 00:06:08,417
>> ดังนั้นไอบีเอ็ม แต่เดิมอยู่ใน
ธุรกิจฐานข้อมูล

144
00:06:08,417 --> 00:06:09,750
และที่จริงสิ่งที่พวกเขา

145
00:06:09,750 --> 00:06:11,110
พวกเขาทำการประมวลผลข้อมูล

146
00:06:11,110 --> 00:06:15,400
>> ในฐานะที่เป็นเพื่อให้การขยายตัวของหมัด
บัตรซึ่งเป็นกลไกที่มีความคิดสร้างสรรค์

147
00:06:15,400 --> 00:06:18,560
ความสามารถในการใช้ประโยชน์จากการที่
เทคโนโลยีในการสำรวจชุดผลลัพธ์ที่เรียงลำดับ

148
00:06:18,560 --> 00:06:20,726
คุณสามารถเห็นในภาพนี้
มีเรามี 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
ข้อมูลที่มากเกินไปกระจายในมากเกินไป
สถานที่ de ซ้ำซ้อนของข้อมูล

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
และถ้าคุณดูมากกว่า
ในช่วงห้าปีที่ผ่านมา

216
00:09:44,610 --> 00:09:48,180
นี้เป็นแผนภูมิว่าข้อมูลที่
โหลดทั่วทั้งองค์กรทั่วไป

217
00:09:48,180 --> 00:09:49,640
ดูเหมือนว่าในช่วงห้าปีที่ผ่านมา

218
00:09:49,640 --> 00:09:52,570
>> และกฎทั่วไปของหัวแม่มือ
days-- เหล่านี้ถ้าคุณไป Google--

219
00:09:52,570 --> 00:09:55,290
เป็น 90% ของข้อมูลที่
เราเก็บวันนี้และมันก็เป็น

220
00:09:55,290 --> 00:09:57,330
ที่สร้างขึ้นภายในสองปี

221
00:09:57,330 --> 00:09:57,911
ตกลง.

222
00:09:57,911 --> 00:09:59,410
ตอนนี้ไม่ได้เป็นแนวโน้มที่ใหม่

223
00:09:59,410 --> 00:10:01,230
ซึ่งเป็นเทรนด์ที่ได้รับ
ออกไป 100 ปี

224
00:10:01,230 --> 00:10:03,438
นับตั้งแต่เฮอร์แมน Hollerith
การพัฒนาบัตรเจาะที่

225
00:10:03,438 --> 00:10:08,040
เราได้รับการสร้างที่เก็บข้อมูล
และรวบรวมข้อมูลในอัตราที่เป็นปรากฎการณ์

226
00:10:08,040 --> 00:10:10,570
>> ดังนั้นในช่วง 100 ปีที่ผ่านมา
เราได้เห็นแนวโน้มนี้

227
00:10:10,570 --> 00:10:11,940
ที่ไม่ได้ไปเปลี่ยน

228
00:10:11,940 --> 00:10:14,789
ก้าวไปข้างหน้าเรากำลังจะไปดู
นี้ถ้าไม่ได้เป็นแนวโน้มเร่ง

229
00:10:14,789 --> 00:10:16,330
และคุณสามารถมองเห็นสิ่งที่ดูเหมือนว่า

230
00:10:16,330 --> 00:10:23,510
>> หากธุรกิจในปี 2010 มีหนึ่ง
เทราไบต์ของข้อมูลภายใต้การบริหาร

231
00:10:23,510 --> 00:10:27,080
วันนี้นั่นหมายความว่าพวกเขากำลัง
การจัดการ 6.5 เพตาไบต์ของข้อมูล

232
00:10:27,080 --> 00:10:30,380
นั่นคือ 6,500 ครั้งข้อมูลได้มากขึ้น

233
00:10:30,380 --> 00:10:31,200
และฉันรู้ว่านี้

234
00:10:31,200 --> 00:10:33,292
ผมทำงานกับธุรกิจเหล่านี้ทุกวัน

235
00:10:33,292 --> 00:10:35,000
ห้าปีที่ผ่านมาผม
จะพูดคุยกับ บริษัท

236
00:10:35,000 --> 00:10:38,260
ที่จะพูดคุยกับผมเกี่ยวกับสิ่งที่เจ็บปวด
มันคือการจัดการเทราไบต์ของข้อมูล

237
00:10:38,260 --> 00:10:39,700
และพวกเขาจะพูดคุย
กับฉันเกี่ยวกับวิธีการที่เราเห็น

238
00:10:39,700 --> 00:10:41,825
ว่าเรื่องนี้อาจจะ
จะเป็น petabyte หรือสอง

239
00:10:41,825 --> 00:10:43,030
ภายในสองสามปีที่ผ่านมา

240
00:10:43,030 --> 00:10:45,170
>> บริษัท เหล่านี้เหมือนกัน
วันนี้ผมกำลังประชุมกับ

241
00:10:45,170 --> 00:10:48,100
และพวกเขากำลังพูดกับผมเกี่ยวกับ
ปัญหาที่เกิดขึ้นจะต้องมีการจัดการ

242
00:10:48,100 --> 00:10:51,440
นับ 20 เพตาไบต์ของข้อมูล

243
00:10:51,440 --> 00:10:53,590
ดังนั้นการระเบิดของ
ข้อมูลในอุตสาหกรรม

244
00:10:53,590 --> 00:10:56,670
คือการขับรถอย่างมาก
ความจำเป็นในการแก้ปัญหาที่ดีกว่า

245
00:10:56,670 --> 00:11:00,980
และเป็นฐานข้อมูลเชิงสัมพันธ์
เพียงแค่ไม่ได้อยู่ถึงความต้องการ

246
00:11:00,980 --> 00:11:03,490
>> และเพื่อให้มีเส้น
ความสัมพันธ์ระหว่างความดันข้อมูล

247
00:11:03,490 --> 00:11:05,210
และนวัตกรรมทางเทคนิค

248
00:11:05,210 --> 00:11:07,780
ประวัติศาสตร์ได้แสดงให้เราเห็น
นี้ว่าเมื่อเวลาผ่านไป

249
00:11:07,780 --> 00:11:11,090
เมื่อใดก็ตามที่ปริมาณของข้อมูลที่
ที่จะต้องมีการประมวลผล

250
00:11:11,090 --> 00:11:15,490
เกินกว่าความจุของระบบ
ที่จะดำเนินการในเวลาที่เหมาะสม

251
00:11:15,490 --> 00:11:18,870
หรือในราคาที่เหมาะสม
แล้วเทคโนโลยีใหม่

252
00:11:18,870 --> 00:11:21,080
มีการคิดค้นขึ้นมาเพื่อแก้ปัญหาเหล​​่านั้น

253
00:11:21,080 --> 00:11:24,090
ผู้เทคโนโลยีใหม่
ในที่สุดก็เปิดประตู

254
00:11:24,090 --> 00:11:27,840
ถึงชุดของปัญหาอื่นซึ่ง
คือการรวบรวมข้อมูลมากยิ่งขึ้น

255
00:11:27,840 --> 00:11:29,520
>> ตอนนี้เราจะไม่หยุดนี้

256
00:11:29,520 --> 00:11:30,020
ขวา?

257
00:11:30,020 --> 00:11:31,228
เราจะไม่หยุดนี้

258
00:11:31,228 --> 00:11:31,830
ทำไม?

259
00:11:31,830 --> 00:11:35,520
เพราะคุณไม่สามารถรู้ทุกอย่าง
มีความรู้ในจักรวาล

260
00:11:35,520 --> 00:11:40,510
และตราบใดที่เราเคยมีชีวิตอยู่
ตลอดประวัติศาสตร์ของมนุษย์

261
00:11:40,510 --> 00:11:43,440
เราได้รับแรงผลักดันเสมอที่จะทราบข้อมูลเพิ่มเติม

262
00:11:43,440 --> 00:11:49,840
>> ดังนั้นจึงดูเหมือนว่านิ้วที่เราย้ายทุก
ลงเส้นทางของการค้นพบทางวิทยาศาสตร์

263
00:11:49,840 --> 00:11:54,620
เรามีการคูณจำนวนของข้อมูล
ที่เราจำเป็นต้องดำเนินการชี้แจง

264
00:11:54,620 --> 00:11:59,920
ในขณะที่เราค้นพบมากขึ้นและมากขึ้น
การทำงานเกี่ยวกับด้านในของชีวิต

265
00:11:59,920 --> 00:12:04,530
เกี่ยวกับวิธีการทำงานของจักรวาลประมาณ
การขับรถการค้นพบทางวิทยาศาสตร์

266
00:12:04,530 --> 00:12:06,440
และสิ่งประดิษฐ์ที่
ที่เรากำลังทำในวันนี้

267
00:12:06,440 --> 00:12:09,570
ปริมาณของข้อมูลเพียง
เพิ่มอย่างต่อเนื่อง

268
00:12:09,570 --> 00:12:12,120
ดังนั้นความสามารถในการจัดการกับ
ปัญหานี้เป็นอย่างมาก

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

270
00:12:14,790 --> 00:12:17,410
>> ดังนั้นหนึ่งในสิ่งที่
เรามองว่าเป็นเหตุผลที่ NoSQL?

271
00:12:17,410 --> 00:12:19,200
NoSQL วิธีแก้ปัญหานี้หรือไม่

272
00:12:19,200 --> 00:12:24,980
ดีฐานข้อมูลเชิงสัมพันธ์
โครงสร้างภาษาแบบสอบถาม

273
00:12:24,980 --> 00:12:28,600
SQL-- ที่จริงโครงสร้างของที่
สัมพันธ์ database-- สิ่งเหล่านี้

274
00:12:28,600 --> 00:12:30,770
การเพิ่มประสิทธิภาพในการจัดเก็บ

275
00:12:30,770 --> 00:12:33,180
>> ย้อนกลับไปในยุค 70 อีกครั้ง
ดิสก์ที่มีราคาแพง

276
00:12:33,180 --> 00:12:36,990
การออกกำลังกายการจัดเตรียมการจัดเก็บข้อมูล
ในองค์กรเป็นที่ไม่มีที่สิ้นสุด

277
00:12:36,990 --> 00:12:37,490
ฉันรู้.

278
00:12:37,490 --> 00:12:38,020
ฉันอาศัยอยู่มัน

279
00:12:38,020 --> 00:12:41,250
ผมเขียนโปรแกรมควบคุมการจัดเก็บข้อมูลสำหรับ
บริษัท SuperServer 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 เป็นเทคโนโลยีที่ดี
เพราะมัน normalizes ข้อมูล

287
00:13:00,160 --> 00:13:02,210
มัน de-ซ้ำข้อมูล

288
00:13:02,210 --> 00:13:07,180
มันทำให้ข้อมูลในโครงสร้างที่
คือไม่เชื่อเรื่องพระเจ้ากับรูปแบบการเข้าถึงทุก

289
00:13:07,180 --> 00:13:11,600
การใช้งานหลายสามารถตีว่า
ฐานข้อมูล SQL เรียกเฉพาะกิจแบบสอบถาม

290
00:13:11,600 --> 00:13:15,950
และได้รับข้อมูลในรูปทรงที่ว่าพวกเขา
ต้องดำเนินการสำหรับงานของพวกเขา

291
00:13:15,950 --> 00:13:17,570
ที่เสียงที่ยอดเยี่ยม

292
00:13:17,570 --> 00:13:21,350
แต่บรรทัดล่างเป็นกับใด ๆ
ระบบถ้ามันไม่เชื่อเรื่องพระเจ้าทุกอย่าง

293
00:13:21,350 --> 00:13:23,500
มันเป็นอะไรที่ดีที่สุดสำหรับ

294
00:13:23,500 --> 00:13:24,050
ตกลง?

295
00:13:24,050 --> 00:13:26,386
>> และนั่นคือสิ่งที่เราได้รับด้วย
ฐานข้อมูลเชิงสัมพันธ์

296
00:13:26,386 --> 00:13:27,510
มันเหมาะสำหรับการจัดเก็บข้อมูล

297
00:13:27,510 --> 00:13:28,280
มันเป็นเรื่องปกติ

298
00:13:28,280 --> 00:13:29,370
มันเป็นความสัมพันธ์

299
00:13:29,370 --> 00:13:31,660
สนับสนุนคำสั่งเฉพาะกิจ

300
00:13:31,660 --> 00:13:34,000
และมันและเครื่องชั่งน้ำหนักในแนวตั้ง

301
00:13:34,000 --> 00:13:39,030
>> ถ้าฉันจะต้องได้รับฐานข้อมูล SQL ที่ใหญ่กว่า
หรือฐานข้อมูล SQL มีประสิทธิภาพมากขึ้น

302
00:13:39,030 --> 00:13:41,090
ผมไปซื้อชิ้นส่วนที่ใหญ่กว่าเหล็ก

303
00:13:41,090 --> 00:13:41,600
ตกลง?

304
00:13:41,600 --> 00:13:44,940
ผมเคยทำงานกับลูกค้าจำนวนมาก
ที่ได้รับการผ่านการอัพเกรดที่สำคัญ

305
00:13:44,940 --> 00:13:48,340
ในโครงสร้างพื้นฐาน SQL ของพวกเขาเท่านั้น
เพื่อหาหกเดือนต่อมา

306
00:13:48,340 --> 00:13:49,750
พวกเขากำลังตีผนังอีกครั้ง

307
00:13:49,750 --> 00:13:55,457
และคำตอบจาก Oracle หรือ MSSQL
หรือใครอื่นจะได้รับกล่องที่ใหญ่กว่า

308
00:13:55,457 --> 00:13:58,540
ดีไม่ช้าก็เร็วคุณจะไม่สามารถซื้อ
กล่องที่ใหญ่กว่าและที่ปัญหาที่แท้จริง

309
00:13:58,540 --> 00:14:00,080
เราจำเป็นต้องเปลี่ยนแปลงสิ่งที่จริง

310
00:14:00,080 --> 00:14:01,080
เพื่อที่จะทำงานนี้หรือไม่?

311
00:14:01,080 --> 00:14:06,560
มันทำงานได้ดีครับ
การวิเคราะห์ปริมาณงาน OLAP ชนิด

312
00:14:06,560 --> 00:14:08,670
และที่จริงที่เป็น SQL

313
00:14:08,670 --> 00:14:12,540
ตอนนี้ก็ใช้ในวันนี้ออนไลน์จำนวนมาก
การประมวลผลการทำธุรกรรมประเภท

314
00:14:12,540 --> 00:14:13,330
การใช้งาน

315
00:14:13,330 --> 00:14:16,460
และมันก็ทำงานได้ดีที่
ระดับของการใช้ประโยชน์บางอย่าง

316
00:14:16,460 --> 00:14:18,670
แต่มันก็ไม่ได้ขนาด
วิธีการที่ NoSQL ไม่

317
00:14:18,670 --> 00:14:20,660
และเราจะพูดคุยเล็ก ๆ น้อย ๆ
บิตเกี่ยวกับสาเหตุที่เป็น

318
00:14:20,660 --> 00:14:23,590
>> ตอนนี้ NoSQL ในมืออื่น ๆ
มีการเพิ่มประสิทธิภาพมากขึ้นสำหรับการคำนวณ

319
00:14:23,590 --> 00:14:24,540
ตกลง?

320
00:14:24,540 --> 00:14:26,830
มันไม่ได้เป็นไปไม่เชื่อเรื่องพระเจ้า
รูปแบบการเข้าถึง

321
00:14:26,830 --> 00:14:31,620
คือสิ่งที่เราเรียก de-ปกติ
โครงสร้างหรือโครงสร้างแบบลำดับชั้น

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
>> แต่ความคิดที่นี่คือที่ที่คุณเก็บ
ข้อมูลของคุณในขณะที่มุมมอง instantiated เหล่านี้

330
00:14:55,320 --> 00:14:56,410
ตกลง?

331
00:14:56,410 --> 00:14:58,610
คุณขนาดในแนวนอน

332
00:14:58,610 --> 00:14:59,556
ขวา?

333
00:14:59,556 --> 00:15:02,100
ถ้าผมต้องการที่จะเพิ่ม
ขนาดของกลุ่ม NoSQL ของฉัน

334
00:15:02,100 --> 00:15:03,700
ฉันไม่ต้องการที่จะได้รับกล่องที่ใหญ่กว่า

335
00:15:03,700 --> 00:15:05,200
ฉันจะได้รับกล่องอื่น

336
00:15:05,200 --> 00:15:07,700
และฉันกลุ่มเหล่านั้นเข้าด้วยกัน
และฉันสามารถ Shard ข้อมูลว่า

337
00:15:07,700 --> 00:15:10,780
เราจะพูดเล็กน้อยเกี่ยวกับ
สิ่งที่ sharding คือการเป็น

338
00:15:10,780 --> 00:15:14,270
สามารถที่จะปรับขนาดของฐานข้อมูลที่
ในอุปกรณ์ทางกายภาพหลาย

339
00:15:14,270 --> 00:15:18,370
และลบอุปสรรคที่
ต้องการให้ฉันขนาดในแนวตั้ง

340
00:15:18,370 --> 00:15:22,080
>> ดังนั้นจึงสร้างจริงๆสำหรับออนไลน์
การประมวลผลธุรกรรมและขนาด

341
00:15:22,080 --> 00:15:25,480
มีความแตกต่างที่ยิ่งใหญ่คือ
นี่ระหว่างการรายงานใช่มั้ย?

342
00:15:25,480 --> 00:15:27,810
รายงานผมไม่ทราบ
คำถามที่ผมจะถาม

343
00:15:27,810 --> 00:15:28,310
ขวา?

344
00:15:28,310 --> 00:15:30,570
Reporting-- ถ้าใครบางคนจาก
ฝ่ายการตลาดของฉัน

345
00:15:30,570 --> 00:15:34,520
ต้องการที่จะ just-- จำนวนของลูกค้าของฉัน
มีลักษณะนี้โดยเฉพาะที่

346
00:15:34,520 --> 00:15:37,850
ซื้อใน day-- นี้ผมไม่ทราบ
สิ่งที่พวกเขากำลังแบบสอบถามจะถาม

347
00:15:37,850 --> 00:15:39,160
ดังนั้นผมจึงจำเป็นต้องมีความเชื่อเรื่องพระเจ้า

348
00:15:39,160 --> 00:15:41,810
>> ขณะนี้ในออนไลน์
แอพลิเคชันการทำธุรกรรม

349
00:15:41,810 --> 00:15:43,820
ฉันรู้ว่าสิ่งที่คำถามที่ฉันขอ

350
00:15:43,820 --> 00:15:46,581
ฉันสร้างพลิเคชันสำหรับ
ขั้นตอนการทำงานที่เฉพาะเจาะจงมาก

351
00:15:46,581 --> 00:15:47,080
ตกลง?

352
00:15:47,080 --> 00:15:50,540
ดังนั้นถ้าผมเพิ่มประสิทธิภาพข้อมูล
การจัดเก็บที่จะสนับสนุนกระบวนการทำงานนั้น

353
00:15:50,540 --> 00:15:52,020
มันเป็นไปได้เร็วขึ้น

354
00:15:52,020 --> 00:15:55,190
และที่ว่าทำไม NoSQL สามารถ
จริงๆเร่งส่งมอบ

355
00:15:55,190 --> 00:15:57,710
ประเภทของบริการเหล่านั้น

356
00:15:57,710 --> 00:15:58,210
ทั้งหมดขวา

357
00:15:58,210 --> 00:16:00,501
>> ดังนั้นเรากำลังจะได้รับใน
นิด ๆ หน่อย ๆ ของทฤษฎีที่นี่

358
00:16:00,501 --> 00:16:03,330
และบางส่วนของคุณตาของคุณ
อาจย้อนกลับไปนิด ๆ หน่อย ๆ

359
00:16:03,330 --> 00:16:06,936
แต่ฉันจะพยายามที่จะให้มัน
ระดับสูงที่สุดเท่าที่จะทำได้

360
00:16:06,936 --> 00:16:08,880
ดังนั้นถ้าคุณอยู่ในโครงการ
การจัดการที่มี

361
00:16:08,880 --> 00:16:12,280
สร้างที่เรียกว่า
สามเหลี่ยม จำกัด

362
00:16:12,280 --> 00:16:12,936
ตกลง.

363
00:16:12,936 --> 00:16:16,060
สามเหลี่ยมของคำสั่ง constrains
คุณไม่สามารถมีทุกอย่างตลอดเวลา

364
00:16:16,060 --> 00:16:17,750
ไม่สามารถมีพายและกินมันเกินไป

365
00:16:17,750 --> 00:16:22,310
ดังนั้นในการบริหารจัดการโครงการที่สามเหลี่ยม
ข้อ จำกัด คือคุณสามารถมีได้ในราคาถูก

366
00:16:22,310 --> 00:16:24,710
คุณสามารถมีได้อย่างรวดเร็ว
หรือคุณสามารถมีได้ดี

367
00:16:24,710 --> 00:16:25,716
เลือกสอง

368
00:16:25,716 --> 00:16:27,090
เพราะคุณไม่สามารถมีทั้งสาม

369
00:16:27,090 --> 00:16:27,460
ขวา?

370
00:16:27,460 --> 00:16:27,820
ตกลง.

371
00:16:27,820 --> 00:16:28,920
>> ดังนั้นคุณได้ยินเกี่ยวกับเรื่องนี้มาก

372
00:16:28,920 --> 00:16:31,253
มันเป็นข้อ จำกัด ที่สาม
สามเหลี่ยม จำกัด สาม

373
00:16:31,253 --> 00:16:34,420
หรือสามเหลี่ยมเหล็ก oftentimes--
เมื่อคุณพูดคุยกับผู้จัดการโครงการ,

374
00:16:34,420 --> 00:16:35,420
พวกเขาจะพูดคุยเกี่ยวกับเรื่องนี้

375
00:16:35,420 --> 00:16:37,640
ตอนนี้มีฐานข้อมูล
สามเหลี่ยมเหล็กของตัวเอง

376
00:16:37,640 --> 00:16:40,350
และสามเหลี่ยมเหล็กของข้อมูล
คือสิ่งที่เราเรียกว่าทฤษฎีบท CAP

377
00:16:40,350 --> 00:16:41,580
ตกลง?

378
00:16:41,580 --> 00:16:43,770
>> CAP สั่งทฤษฎีบท
วิธีการใช้งานฐานข้อมูล

379
00:16:43,770 --> 00:16:45,627
ภายใต้เงื่อนไขที่เฉพาะเจาะจงมาก

380
00:16:45,627 --> 00:16:47,460
และเราจะพูดคุยเกี่ยวกับ
สิ่งที่เป็นเงื่อนไขที่ว่า

381
00:16:47,460 --> 00:16:52,221
แต่สามจุดของรูปสามเหลี่ยม
เพื่อที่จะพูดเป็น C สม่ำเสมอ

382
00:16:52,221 --> 00:16:52,720
ตกลง?

383
00:16:52,720 --> 00:16:56,760
ดังนั้นใน 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
ตกลง?

387
00:17:01,480 --> 00:17:04,020
ถ้าผมเห็นฐานข้อมูล
ฉันเห็นมุมมองเดียวกัน

388
00:17:04,020 --> 00:17:06,130
เป็นพันธมิตรของฉันที่เห็น
ฐานข้อมูลเดียวกัน

389
00:17:06,130 --> 00:17:07,470
นั่นคือความมั่นคง

390
00:17:07,470 --> 00:17:12,099
>> มีจำหน่ายหมายความว่าถ้า
ฐานข้อมูลออนไลน์ถ้ามันสามารถเข้าถึงได้,

391
00:17:12,099 --> 00:17:14,760
ว่าลูกค้าทุกคนจะเสมอ
สามารถอ่านและเขียน

392
00:17:14,760 --> 00:17:15,260
ตกลง?

393
00:17:15,260 --> 00:17:17,010
เพื่อให้ลูกค้าทุก
สามารถอ่านฐานข้อมูล

394
00:17:17,010 --> 00:17:18,955
ก็จะสามารถอ่าน
ข้อมูลและเขียนข้อมูล

395
00:17:18,955 --> 00:17:21,819
และถ้าเป็นกรณีที่
มันเป็นระบบที่มีอยู่

396
00:17:21,819 --> 00:17:24,230
>> และจุดที่สามเป็นสิ่งที่
เราเรียกความอดทนพาร์ทิชัน

397
00:17:24,230 --> 00:17:24,730
ตกลง?

398
00:17:24,730 --> 00:17:28,160
หมายถึงความอดทนพาร์ทิชัน
ว่าระบบทำงานได้ดี

399
00:17:28,160 --> 00:17:32,000
แม้จะมีเครือข่ายทางกายภาพ
พาร์ทิชันระหว่างโหนด

400
00:17:32,000 --> 00:17:32,760
ตกลง?

401
00:17:32,760 --> 00:17:36,270
ดังนั้นโหนดในคลัสเตอร์ไม่สามารถ
พูดคุยกับแต่ละอื่น ๆ สิ่งที่เกิดขึ้น?

402
00:17:36,270 --> 00:17:36,880
ทั้งหมดขวา

403
00:17:36,880 --> 00:17:39,545
>> ฐานข้อมูลเชิงสัมพันธ์ดังนั้น choose--
คุณสามารถเลือกสองเหล่านี้

404
00:17:39,545 --> 00:17:40,045
ตกลง.

405
00:17:40,045 --> 00:17:43,680
ฐานข้อมูลเชิงสัมพันธ์เพื่อให้เลือก
เพื่อให้สอดคล้องและสามารถใช้ได้

406
00:17:43,680 --> 00:17:47,510
ถ้าพาร์ทิชันที่เกิดขึ้นระหว่าง
DataNodes ในการจัดเก็บข้อมูล

407
00:17:47,510 --> 00:17:48,831
เกิดปัญหาฐานข้อมูล

408
00:17:48,831 --> 00:17:49,330
ขวา?

409
00:17:49,330 --> 00:17:50,900
มันก็จะไปลง

410
00:17:50,900 --> 00:17:51,450
ตกลง.

411
00:17:51,450 --> 00:17:54,230
>> และนี่คือเหตุผลที่พวกเขามี
เติบโตไปพร้อมกับกล่องที่ใหญ่กว่า

412
00:17:54,230 --> 00:17:54,730
ขวา?

413
00:17:54,730 --> 00:17:58,021
เพราะมี no-- ปกติกลุ่ม
ฐานข้อมูลมีไม่มากมากของพวกเขา

414
00:17:58,021 --> 00:17:59,590
ที่ทำงานแบบนั้น

415
00:17:59,590 --> 00:18:03,019
แต่ฐานข้อมูลส่วนใหญ่ขนาด
แนวตั้งภายในกล่องเดียว

416
00:18:03,019 --> 00:18:05,060
เพราะพวกเขาจะต้อง
สอดคล้องและสามารถใช้ได้

417
00:18:05,060 --> 00:18:10,320
ถ้าพาร์ทิชันจะถูกฉีด
แล้วคุณจะต้องให้ทางเลือก

418
00:18:10,320 --> 00:18:13,720
คุณต้องให้เลือกระหว่าง
เป็นที่สอดคล้องกันและสามารถใช้ได้

419
00:18:13,720 --> 00:18:16,080
>> และนั่นคือสิ่งที่ทำฐานข้อมูล NoSQL

420
00:18:16,080 --> 00:18:16,580
ทั้งหมดขวา

421
00:18:16,580 --> 00:18:20,950
ดังนั้นฐานข้อมูล NoSQL มัน
มาในสองรสชาติ

422
00:18:20,950 --> 00:18:22,990
เรา have-- ดีก็
มาในรสชาติหลาย

423
00:18:22,990 --> 00:18:26,140
แต่มันก็มาพร้อมกับสองขั้นพื้นฐาน
characteristics-- สิ่งที่

424
00:18:26,140 --> 00:18:30,050
เราจะเรียกฐานข้อมูล CP หรือ
สอดคล้องและความอดทนพาร์ทิชัน

425
00:18:30,050 --> 00:18:31,040
ระบบ.

426
00:18:31,040 --> 00:18:34,930
พวกเหล่านี้ให้ทางเลือกที่ว่าเมื่อ
โหนดสูญเสียการติดต่อกับแต่ละอื่น ๆ

427
00:18:34,930 --> 00:18:37,091
เราไม่ได้ไปเพื่อให้
คนที่จะเขียนใด ๆ เพิ่มเติม

428
00:18:37,091 --> 00:18:37,590
ตกลง?

429
00:18:37,590 --> 00:18:41,855
>> จนกระทั่งพาร์ติชันที่ถูกลบออก
เขียนเข้าถึงถูกบล็อก

430
00:18:41,855 --> 00:18:43,230
นั่นหมายความว่าพวกเขาจะไม่สามารถใช้ได้

431
00:18:43,230 --> 00:18:44,510
พวกเขากำลังที่สอดคล้องกัน

432
00:18:44,510 --> 00:18:46,554
เมื่อเราเห็นว่า
พาร์ทิชันฉีดเอง

433
00:18:46,554 --> 00:18:48,470
ตอนนี้เรามีความสอดคล้องกัน
เพราะเราไม่ได้ไป

434
00:18:48,470 --> 00:18:51,517
เพื่อให้การเปลี่ยนแปลงข้อมูลในสอง
ด้านข้างของพาร์ทิชันอิสระ

435
00:18:51,517 --> 00:18:52,100
ของกันและกัน.

436
00:18:52,100 --> 00:18:54,130
เราจะต้อง
กอบกู้การสื่อสาร

437
00:18:54,130 --> 00:18:56,930
ก่อนการปรับปรุงใด ๆ
ข้อมูลที่ได้รับอนุญาต

438
00:18:56,930 --> 00:18:58,120
ตกลง?

439
00:18:58,120 --> 00:19:02,650
>> รสชาติที่ต่อไปจะมีระบบ AP,
หรือที่มีอยู่และแบ่งพาร์ติชัน

440
00:19:02,650 --> 00:19:03,640
ระบบความอดทน

441
00:19:03,640 --> 00:19:05,320
คนพวกนี้ไม่สนใจ

442
00:19:05,320 --> 00:19:06,020
ขวา?

443
00:19:06,020 --> 00:19:08,960
โหนดใด ๆ ที่ได้รับ
เขียนเราจะใช้มัน

444
00:19:08,960 --> 00:19:11,480
ดังนั้นฉันจำลองข้อมูลของฉัน
ข้ามโหนดหลาย

445
00:19:11,480 --> 00:19:14,730
โหนดเหล่านี้จะได้รับลูกค้าลูกค้ามา
ในกล่าวว่าฉันจะเขียนข้อมูลบางส่วน

446
00:19:14,730 --> 00:19:16,300
โหนดกล่าวว่าไม่มีปัญหา

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-Oh, ระบบพวกเขาจะตระหนักถึง UH​​-โอ้

451
00:19:27,360 --> 00:19:28,870
มีการการปรับปรุงไปยังทั้งสองฝ่าย

452
00:19:28,870 --> 00:19:30,370
พวกเราทำอะไร?

453
00:19:30,370 --> 00:19:33,210
และสิ่งที่พวกเขาทำแล้ว
ที่พวกเขาทำสิ่งที่

454
00:19:33,210 --> 00:19:36,080
ช่วยให้พวกเขาในการแก้ไขข้อมูลที่รัฐ

455
00:19:36,080 --> 00:19:39,000
และเราจะพูดคุยเกี่ยวกับ
ว่าในแผนภูมิต่อไป

456
00:19:39,000 --> 00:19:40,000
>> สิ่งที่จะชี้ให้เห็นที่นี่

457
00:19:40,000 --> 00:19:42,374
และฉันจะไม่ได้รับมากเกินไป
มากเป็นแบบนี้เพราะนี้

458
00:19:42,374 --> 00:19:43,510
ได้รับในทฤษฎีข้อมูลลึก

459
00:19:43,510 --> 00:19:46,670
แต่มีการทำธุรกรรม
กรอบที่

460
00:19:46,670 --> 00:19:50,680
วิ่งในระบบความสัมพันธ์ที่
ช่วยให้ผมที่จะทำให้การปรับปรุงได้อย่างปลอดภัย

461
00:19:50,680 --> 00:19:53,760
ไปยังหน่วยงานหลายแห่งในฐานข้อมูล

462
00:19:53,760 --> 00:19:58,320
และการปรับปรุงเหล่านั้นจะเกิดขึ้นได้
ทั้งหมดในครั้งเดียวหรือไม่ทั้งหมด

463
00:19:58,320 --> 00:20:00,500
และนี่คือที่เรียกว่าการทำธุรกรรมกรด

464
00:20:00,500 --> 00:20:01,000
ตกลง?

465
00:20:01,000 --> 00:20:06,570
>> กรดจะช่วยให้เรา atomicity สม่ำเสมอ
การแยกและความทนทาน

466
00:20:06,570 --> 00:20:07,070
ตกลง?

467
00:20:07,070 --> 00:20:13,550
นั่นหมายความว่าอะตอมการทำธุรกรรมทั้งหมด
การปรับปรุงของฉันเกิดขึ้นอย่างใดอย่างหนึ่งหรือพวกเขาไม่ได้

468
00:20:13,550 --> 00:20:16,570
สอดคล้องหมายความว่า
ฐานข้อมูลจะเสมอ

469
00:20:16,570 --> 00:20:19,780
จะนำเข้ามาที่สอดคล้องกัน
รัฐหลังจากการปรับปรุง

470
00:20:19,780 --> 00:20:23,900
ฉันไม่เคยจะออกจากฐานข้อมูลในที่
รัฐที่ไม่ดีหลังจากใช้การปรับปรุง

471
00:20:23,900 --> 00:20:24,400
ตกลง?

472
00:20:24,400 --> 00:20:26,720
>> ดังนั้นจึงเป็นที่แตกต่างกันเล็ก ๆ น้อย ๆ
กว่าสอดคล้อง CAP

473
00:20:26,720 --> 00:20:29,760
สอดคล้อง CAP หมายถึงทั้งหมดของฉัน
ลูกค้าสามารถดูข้อมูล

474
00:20:29,760 --> 00:20:34,450
สอดคล้องกรดหมายความว่าเมื่อ
การทำธุรกรรมที่ทำข้อมูลที่ดี

475
00:20:34,450 --> 00:20:35,709
ความสัมพันธ์ของฉันเป็นสิ่งที่ดีทั้งหมด

476
00:20:35,709 --> 00:20:38,750
ฉันจะไม่ลบแถวผู้ปกครอง
และออกจากพวงของเด็กเด็กกำพร้า

477
00:20:38,750 --> 00:20:40,970
ในบางตารางอื่น ๆ

478
00:20:40,970 --> 00:20:44,320
มันไม่สามารถเกิดขึ้นได้หากฉันที่สอดคล้องกัน
ในการทำธุรกรรมกรด

479
00:20:44,320 --> 00:20:49,120
>> แยกหมายความว่าการทำธุรกรรม
มักจะเกิดขึ้นหนึ่งหลังจากที่อื่น

480
00:20:49,120 --> 00:20:51,920
ผลลัพธ์ที่ได้จากข้อมูล
จะมีสภาพเดียวกัน

481
00:20:51,920 --> 00:20:54,770
ราวกับว่ารายการดังกล่าว
ที่ถูกออกพร้อมกัน

482
00:20:54,770 --> 00:20:57,340
กำลังดำเนินการเป็นลำดับ

483
00:20:57,340 --> 00:21:00,030
ดังนั้นจึงเป็นที่เห็นพ้องด้วย
การควบคุมในฐานข้อมูล

484
00:21:00,030 --> 00:21:04,130
ดังนั้นโดยทั่วไปผมไม่สามารถที่เพิ่มขึ้น
ค่าเดียวกันสองครั้งสองการดำเนินงาน

485
00:21:04,130 --> 00:21:08,580
>> แต่ถ้าผมบอกว่าจะเพิ่ม 1 ค่านี้
และสองรายการมาใน

486
00:21:08,580 --> 00:21:10,665
และพยายามที่จะทำมันเป็นอย่างใดอย่างหนึ่ง
จะได้รับมีครั้งแรก

487
00:21:10,665 --> 00:21:12,540
และอีกคนหนึ่งของ
จะได้รับหลังจากที่มี

488
00:21:12,540 --> 00:21:15,210
ดังนั้นในท้ายที่สุดผมเพิ่มอีกสอง

489
00:21:15,210 --> 00:21:16,170
คุณจะเห็นสิ่งที่ฉันหมายความว่าอย่างไร

490
00:21:16,170 --> 00:21:16,670
ตกลง.

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

492
00:21:19,220 --> 00:21:21,250
>> ความคงทนตรงไปตรงสวย

493
00:21:21,250 --> 00:21:23,460
เมื่อการทำธุรกรรม
เป็นที่ยอมรับมัน

494
00:21:23,460 --> 00:21:26,100
จะต้องมีแม้กระทั่ง
ถ้าระบบล่ม

495
00:21:26,100 --> 00:21:29,230
เมื่อระบบที่กู้ที่
การทำธุรกรรมที่มีความมุ่งมั่น

496
00:21:29,230 --> 00:21:30,480
เป็นจริงจะต้องมี

497
00:21:30,480 --> 00:21:33,130
เพื่อให้การค้ำประกัน
ของการทำธุรกรรมกรด

498
00:21:33,130 --> 00:21:35,470
ผู้ที่มีการค้ำประกันที่ดีงาม
ที่จะมีในฐานข้อมูล

499
00:21:35,470 --> 00:21:36,870
แต่พวกเขามาที่ค่าใช้จ่ายที่

500
00:21:36,870 --> 00:21:37,640
ขวา?

501
00:21:37,640 --> 00:21:40,520
>> เพราะปัญหาที่เกิดขึ้น
กรอบนี้

502
00:21:40,520 --> 00:21:44,540
ถ้ามีพาร์ทิชันในข้อมูลที่
ชุดผมต้องตัดสินใจ

503
00:21:44,540 --> 00:21:48,000
ฉันจะต้องอนุญาตให้
การปรับปรุงในด้านใดด้านหนึ่งหรืออื่น ๆ

504
00:21:48,000 --> 00:21:50,310
และถ้าเกิดว่า
แล้วฉันไม่ไป

505
00:21:50,310 --> 00:21:52,630
เพื่อให้สามารถที่จะรักษา
ลักษณะเหล่านั้น

506
00:21:52,630 --> 00:21:53,960
พวกเขาจะไม่สอดคล้องกัน

507
00:21:53,960 --> 00:21:55,841
พวกเขาจะไม่ถูกแยกออก

508
00:21:55,841 --> 00:21:58,090
ซึ่งเป็นที่ที่หยุดพักลง
สำหรับฐานข้อมูลเชิงสัมพันธ์

509
00:21:58,090 --> 00:22:01,360
นี่คือเหตุผลที่เชิงสัมพันธ์
ฐานข้อมูลขนาดในแนวตั้ง

510
00:22:01,360 --> 00:22:05,530
>> ในทางกลับกันเรามี
สิ่งที่เรียกว่าเทคโนโลยีฐาน

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
ดังนั้นเราจึงมีซีพีของเราฐานข้อมูล AP

514
00:22:10,180 --> 00:22:14,720
และเหล่านี้คือสิ่งที่คุณเรียกโดยทั่วไป
สามารถใช้ได้รัฐอ่อนที่สุด

515
00:22:14,720 --> 00:22:15,740
ที่สอดคล้องกัน

516
00:22:15,740 --> 00:22:16,420
ตกลง?

517
00:22:16,420 --> 00:22:19,690
>> ที่มีอยู่โดยทั่วไปเพราะ
พวกเขากำลังใจกว้างพาร์ทิชัน

518
00:22:19,690 --> 00:22:21,470
พวกเขามักจะเป็น
มีแม้ถ้ามี

519
00:22:21,470 --> 00:22:23,053
พาร์ทิชันเครือข่ายระหว่างโหนด

520
00:22:23,053 --> 00:22:25,900
ถ้าฉันสามารถพูดคุยกับโหนดผม
จะสามารถอ่านข้อมูล

521
00:22:25,900 --> 00:22:26,460
ตกลง?

522
00:22:26,460 --> 00:22:30,810
ผมอาจจะไม่เสมอสามารถที่จะเขียน
ข้อมูลหากฉันเป็นแพลตฟอร์มที่สอดคล้องกัน

523
00:22:30,810 --> 00:22:32,130
แต่ฉันจะสามารถอ่านข้อมูล

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

525
00:22:34,960 --> 00:22:38,010
>> รัฐอ่อนบ่งชี้
ว่าเมื่อผมอ่านข้อมูลที่

526
00:22:38,010 --> 00:22:40,790
มันอาจจะไม่เป็นเช่นเดียวกับโหนดอื่น ๆ

527
00:22:40,790 --> 00:22:43,390
หากสิทธิที่ออกในโหนด
ที่อื่นในคลัสเตอร์

528
00:22:43,390 --> 00:22:46,650
และมันก็ยังไม่ได้จำลองแบบข้าม
กลุ่ม แต่เมื่อผมอ่านที่ข้อมูล

529
00:22:46,650 --> 00:22:48,680
รัฐที่อาจจะไม่สอดคล้อง

530
00:22:48,680 --> 00:22:51,650
แต่มันจะเป็น
ที่สอดคล้องกันในที่สุด

531
00:22:51,650 --> 00:22:53,870
หมายความว่าเมื่อมีการเขียน
จะทำให้ระบบ

532
00:22:53,870 --> 00:22:56,480
มันจะทำซ้ำทั่วโหนด

533
00:22:56,480 --> 00:22:59,095
และในที่สุดรัฐ
จะถูกนำเข้ามาในการสั่งซื้อ

534
00:22:59,095 --> 00:23:00,890
และมันจะเป็นสถานะที่สอดคล้องกัน

535
00:23:00,890 --> 00:23:05,000
>> ตอนนี้ทฤษฎีบท CAP จริงๆ
เล่นเพียงหนึ่งในเงื่อนไข

536
00:23:05,000 --> 00:23:08,700
เงื่อนไขนั่นคือเมื่อเกิดเหตุการณ์นี้

537
00:23:08,700 --> 00:23:13,710
เพราะเมื่อใดก็ตามที่มันดำเนินงานใน
โหมดปกติมีพาร์ทิชันไม่

538
00:23:13,710 --> 00:23:16,370
ทุกอย่างสอดคล้องและสามารถใช้ได้

539
00:23:16,370 --> 00:23:19,990
คุณจะต้องกังวลเกี่ยวกับ CAP
เมื่อเรามีพาร์ติชันที่

540
00:23:19,990 --> 00:23:21,260
ดังนั้นผู้ที่เป็นของหายาก

541
00:23:21,260 --> 00:23:25,360
แต่วิธีการที่ระบบตอบสนองเมื่อบรรดา
สิ่งที่เกิดขึ้นกำหนดประเภทของระบบ

542
00:23:25,360 --> 00:23:26,750
เราจัดการกับ

543
00:23:26,750 --> 00:23:31,110
>> ดังนั้นลองมาดูสิ่งที่
ที่ดูเหมือนว่าสำหรับระบบ AP

544
00:23:31,110 --> 00:23:32,621
ตกลง?

545
00:23:32,621 --> 00:23:34,830
ระบบ AP มาในสองรสชาติ

546
00:23:34,830 --> 00:23:38,514
พวกเขามาในรสชาติที่มี
ต้นแบบต้นแบบ 100% สามารถใช้ได้ตลอดเวลา

547
00:23:38,514 --> 00:23:40,430
และพวกเขามาใน
รสชาติอื่น ๆ ซึ่งกล่าวว่า

548
00:23:40,430 --> 00:23:43,330
คุณรู้ว่าฉันจะต้องกังวล
เกี่ยวกับสิ่งที่แบ่งพาร์ทิชันนี้

549
00:23:43,330 --> 00:23:44,724
เมื่อพาร์ทิชันที่เกิดขึ้นจริงที่เกิดขึ้น

550
00:23:44,724 --> 00:23:47,890
มิฉะนั้นมีจะเป็นหลัก
โหนดที่จะใช้สิทธิ

551
00:23:47,890 --> 00:23:48,500
ตกลง?

552
00:23:48,500 --> 00:23:50,040
>> ดังนั้นหากเราสิ่งที่ต้องการคาสซานดรา

553
00:23:50,040 --> 00:23:54,440
คาสซานดราจะเป็นหลัก
ต้นแบบให้ฉันเขียนไปยังโหนดใด ๆ

554
00:23:54,440 --> 00:23:55,540
ดังนั้นสิ่งที่เกิดขึ้น?

555
00:23:55,540 --> 00:23:58,270
ดังนั้นผมจึงมีวัตถุที่อยู่ในที่
ฐานข้อมูลที่มีอยู่ในสองโหนด

556
00:23:58,270 --> 00:24:01,705
ขอเรียกวัตถ​​ุเอสว่า
ดังนั้นเราจึงมีรัฐเอส

557
00:24:01,705 --> 00:24:04,312
เรามีการดำเนินการบางอย่าง
ใน S ที่มีอย่างต่อเนื่อง

558
00:24:04,312 --> 00:24:06,270
คาสซานดราช่วยให้ฉันไป
เขียนถึงโหนดหลาย

559
00:24:06,270 --> 00:24:08,550
ดังนั้นสมมติว่าฉันจะได้รับ
เขียนเพื่อสองโหนด

560
00:24:08,550 --> 00:24:12,274
ดีสิ่งที่จบลงด้วยการเกิดขึ้นคือ
ที่เราเรียกว่าเหตุการณ์แบ่ง

561
00:24:12,274 --> 00:24:14,190
อาจไม่เป็น
พาร์ทิชันเครือข่ายทางกายภาพ

562
00:24:14,190 --> 00:24:15,950
แต่เพราะการออกแบบ
ของระบบก็

563
00:24:15,950 --> 00:24:18,449
จริงแบ่งเป็นเร็ว ๆ นี้
ที่ฉันได้รับการเขียนเกี่ยวกับสองโหนด

564
00:24:18,449 --> 00:24:20,830
มันไม่ได้บังคับให้ฉัน
เขียนทั้งหมดผ่านทางหนึ่งโหนด

565
00:24:20,830 --> 00:24:22,340
ผมเขียนในสองโหนด

566
00:24:22,340 --> 00:24:23,330
ตกลง?

567
00:24:23,330 --> 00:24:25,740
>> ดังนั้นตอนนี้ฉันมีสองรัฐ

568
00:24:25,740 --> 00:24:26,360
ตกลง?

569
00:24:26,360 --> 00:24:28,110
สิ่งที่จะเกิดขึ้น
คือไม่ช้าก็เร็ว

570
00:24:28,110 --> 00:24:29,960
มีจะเป็นเหตุการณ์จำลองแบบ

571
00:24:29,960 --> 00:24:33,300
มีจะเป็นสิ่งที่เรา
เรียกว่ากู้พาร์ทิชันที่

572
00:24:33,300 --> 00:24:35,200
เป็นที่ที่ทั้งสอง
รัฐกลับมาอยู่ด้วยกัน

573
00:24:35,200 --> 00:24:37,310
และมีจะเป็นอัลกอริทึม
ที่ทำงานอยู่ภายในฐานข้อมูล

574
00:24:37,310 --> 00:24:38,540
ตัดสินใจว่าจะทำอย่างไร

575
00:24:38,540 --> 00:24:39,110
ตกลง?

576
00:24:39,110 --> 00:24:43,057
โดยค่าเริ่มต้นการปรับปรุงครั้งล่าสุด
ชนะในที่สุดระบบ AP

577
00:24:43,057 --> 00:24:44,890
จึงมีมักจะเป็น
ขั้นตอนวิธีการเริ่มต้นสิ่งที่

578
00:24:44,890 --> 00:24:47,400
ที่พวกเขาเรียกโทรกลับ
ฟังก์ชั่นบางอย่างที่

579
00:24:47,400 --> 00:24:51,000
จะถูกเรียกว่าเมื่อสภาพนี้
มีการตรวจพบจะดำเนินการตรรกะบาง

580
00:24:51,000 --> 00:24:52,900
ที่จะแก้ปัญหาความขัดแย้งที่

581
00:24:52,900 --> 00:24:53,850
ตกลง?

582
00:24:53,850 --> 00:24:58,770
การเรียกกลับเริ่มต้นและการเริ่มต้น
จำแนกในส่วนฐานข้อมูล AP

583
00:24:58,770 --> 00:25:01,130
มีการคาดเดาสิ่งที่ประทับชนะ

584
00:25:01,130 --> 00:25:02,380
นี่คือการปรับปรุงครั้งล่าสุด

585
00:25:02,380 --> 00:25:04,320
ฉันจะใส่ในการปรับปรุงที่มี

586
00:25:04,320 --> 00:25:08,440
ผมอาจจะถ่ายโอนข้อมูลบันทึกนี้ที่ฉัน
ทิ้งออกไปบันทึกการกู้คืน

587
00:25:08,440 --> 00:25:11,670
เพื่อให้ผู้ใช้สามารถกลับมาในภายหลัง
และพูดว่าเดี๋ยวก่อนมีการปะทะกัน

588
00:25:11,670 --> 00:25:12,320
เกิดอะไรขึ้น?

589
00:25:12,320 --> 00:25:16,370
จริงและคุณสามารถถ่ายโอนข้อมูลบันทึกของ
การชนกันทั้งหมดและ rollbacks

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
คุณสามารถพูดได้เดี๋ยวก่อนฉันต้องการ
เพื่อ remediate ข้อมูลนี้

594
00:25:26,730 --> 00:25:28,880
และฉันต้องการที่จะลองและ
รวมทั้งสองบันทึก

595
00:25:28,880 --> 00:25:30,050
แต่นั่นขึ้นอยู่กับคุณ

596
00:25:30,050 --> 00:25:32,880
ฐานข้อมูลไม่ทราบวิธีการ
ทำได้โดยการเริ่มต้น ส่วนใหญ่เวลาที่

597
00:25:32,880 --> 00:25:34,850
สิ่งเดียวที่ฐานข้อมูล
รู้วิธีการที่จะทำคือการพูดว่า

598
00:25:34,850 --> 00:25:36,100
อันนี้เป็นบันทึกที่ผ่านมา

599
00:25:36,100 --> 00:25:39,183
นั่นเป็นหนึ่งที่จะชนะ
และนั่นคือค่าฉันจะใส่

600
00:25:39,183 --> 00:25:41,490
เมื่อกู้พาร์ทิชันที่
และการจำลองแบบเกิดขึ้น

601
00:25:41,490 --> 00:25:43,930
เรามีรัฐของเราที่
คือตอนนี้ S ที่สำคัญซึ่งเป็น

602
00:25:43,930 --> 00:25:46,890
รัฐผสานของวัตถุเหล่านั้นทั้งหมด

603
00:25:46,890 --> 00:25:49,700
ดังนั้นระบบ AP มีนี้

604
00:25:49,700 --> 00:25:51,615
ระบบ CP ไม่จำเป็นต้อง
ที่จะต้องกังวลเกี่ยวกับเรื่องนี้

605
00:25:51,615 --> 00:25:54,490
เพราะทันทีที่พาร์ทิชันมา
ลงเล่นพวกเขาเพียงแค่หยุดการ

606
00:25:54,490 --> 00:25:55,530
เขียน

607
00:25:55,530 --> 00:25:56,180
ตกลง?

608
00:25:56,180 --> 00:25:58,670
เพื่อให้ง่ายมากที่จะ
จัดการกับการที่สอดคล้องกัน

609
00:25:58,670 --> 00:26:01,330
เมื่อคุณไม่ได้รับการปรับปรุงใด ๆ

610
00:26:01,330 --> 00:26:04,620
นั่นคือกับระบบ CP ทำ

611
00:26:04,620 --> 00:26:05,120
ทั้งหมดขวา

612
00:26:05,120 --> 00:26:07,590
>> ดังนั้นขอพูดคุยเล็ก ๆ น้อย ๆ
รูปแบบเล็กน้อยเกี่ยวกับการเข้าถึง

613
00:26:07,590 --> 00:26:11,580
เมื่อเราพูดถึง NoSQL มัน
ทั้งหมดเกี่ยวกับรูปแบบการเข้าถึง

614
00:26:11,580 --> 00:26:13,550
ตอนนี้ SQL เป็นเฉพาะกิจแบบสอบถาม

615
00:26:13,550 --> 00:26:14,481
มันเป็นร้านค้าสัมพันธ์

616
00:26:14,481 --> 00:26:16,480
เราไม่ต้องกังวล
เกี่ยวกับรูปแบบการเข้าถึง

617
00:26:16,480 --> 00:26:17,688
ผมเขียนแบบสอบถามที่ซับซ้อนมาก

618
00:26:17,688 --> 00:26:19,250
มันจะไปและได้รับข้อมูล

619
00:26:19,250 --> 00:26:21,210
นั่นคือสิ่งที่มีลักษณะนี้
เช่นการฟื้นฟู

620
00:26:21,210 --> 00:26:24,890
>> ดังนั้นในโครงสร้างนี้โดยเฉพาะอย่างยิ่ง
เรากำลังมองหาที่แคตตาล็อกผลิตภัณฑ์

621
00:26:24,890 --> 00:26:26,640
ฉันมีความแตกต่างของผลิตภัณฑ์

622
00:26:26,640 --> 00:26:27,217
ผมมีหนังสือ

623
00:26:27,217 --> 00:26:27,800
ฉันมีอัลบั้ม

624
00:26:27,800 --> 00:26:30,090
ฉันมีวิดีโอ

625
00:26:30,090 --> 00:26:33,370
ความสัมพันธ์ระหว่างผลิตภัณฑ์
และคนใดคนหนึ่งของหนังสือเหล่านี้, อัลบั้ม,

626
00:26:33,370 --> 00:26:34,860
และตารางวิดีโอเป็น 1: 1

627
00:26:34,860 --> 00:26:35,800
ทั้งหมดใช่มั้ย?

628
00:26:35,800 --> 00:26:38,860
ฉันมีรหัสผลิตภัณฑ์
และสอดคล้อง ID

629
00:26:38,860 --> 00:26:41,080
หนังสือเล่ม, อัลบั้มหรือวิดีโอ

630
00:26:41,080 --> 00:26:41,580
ตกลง?

631
00:26:41,580 --> 00:26:44,350
นั่นเป็น 1: 1 ความสัมพันธ์
ข้ามตารางเหล่านั้น

632
00:26:44,350 --> 00:26:46,970
>> ตอนนี้สิ่งที่พวกเขา books--
มีคุณสมบัติเป็นราก

633
00:26:46,970 --> 00:26:47,550
ไม่มีปัญหา.

634
00:26:47,550 --> 00:26:48,230
นั่นวิเศษมาก

635
00:26:48,230 --> 00:26:52,130
หนึ่งต่อหนึ่งความสัมพันธ์ของฉันได้รับทั้งหมด
ข้อมูลที่ฉันต้องการที่จะอธิบายหนังสือที่

636
00:26:52,130 --> 00:26:54,770
อัลบั้ม Albums-- มีแทร็ค

637
00:26:54,770 --> 00:26:56,470
นี่คือสิ่งที่เราเรียกว่าหนึ่งไปยังหลาย ๆ

638
00:26:56,470 --> 00:26:58,905
ทุกอัลบั้มอาจมีหลายแทร็ค

639
00:26:58,905 --> 00:27:00,780
ดังนั้นสำหรับการติดตามทุก
อัลบั้มที่ผมจะได้มี

640
00:27:00,780 --> 00:27:02,570
บันทึกในตารางเด็กคนนี้อีก

641
00:27:02,570 --> 00:27:04,680
ดังนั้นผมจึงสร้างระเบียนหนึ่ง
ในตารางอัลบั้มของฉัน

642
00:27:04,680 --> 00:27:06,700
ฉันจะสร้างหลายระเบียน
ในตารางแทร็ค

643
00:27:06,700 --> 00:27:08,850
ความสัมพันธ์แบบหนึ่งต่อหลาย

644
00:27:08,850 --> 00:27:11,220
>> ความสัมพันธ์นี้คือสิ่งที่
ที่เราเรียกว่าหลายต่อหลายคน

645
00:27:11,220 --> 00:27:11,750
ตกลง?

646
00:27:11,750 --> 00:27:17,000
คุณจะเห็นว่านักแสดงอาจจะ
ในภาพยนตร์หลายวิดีโอจำนวนมาก

647
00:27:17,000 --> 00:27:21,450
ดังนั้นสิ่งที่เราทำคือเราใส่การทำแผนที่นี้
ตารางระหว่างเหล่านั้นซึ่งมันก็

648
00:27:21,450 --> 00:27:24,040
แผนที่ ID นักแสดงกับวิดีโอประจำตัวประชาชน

649
00:27:24,040 --> 00:27:28,464
ตอนนี้ฉันสามารถสร้างแบบสอบถามร่วม
วิดีโอผ่านวิดีโอกับนักแสดงนักแสดง,

650
00:27:28,464 --> 00:27:31,130
และมันทำให้ผมมีรายการที่ดีของ
ภาพยนตร์ทั้งหมดและนักแสดงทั้งหมด

651
00:27:31,130 --> 00:27:32,420
ที่อยู่ในหนังเรื่องนี้ว่า

652
00:27:32,420 --> 00:27:33,290
>> ตกลง.

653
00:27:33,290 --> 00:27:33,880
ดังนั้นที่นี่เราไป

654
00:27:33,880 --> 00:27:38,040
One-to-One เป็นระดับบนสุด
ความสัมพันธ์; แบบหนึ่งต่อหลาย

655
00:27:38,040 --> 00:27:40,240
อัลบั้มเพลง; หลายต่อหลายคน

656
00:27:40,240 --> 00:27:44,990
เหล่านี้เป็นสามระดับบนสุด
ความสัมพันธ์ในฐานข้อมูลใด ๆ

657
00:27:44,990 --> 00:27:48,050
ถ้าคุณรู้ว่าวิธีการเหล่านั้น
ความสัมพันธ์การทำงานร่วมกัน

658
00:27:48,050 --> 00:27:51,490
แล้วคุณจะรู้มาก
เกี่ยวกับฐานข้อมูลแล้ว

659
00:27:51,490 --> 00:27:55,660
ดังนั้น NoSQL ทำงานแตกต่างกันเล็กน้อย

660
00:27:55,660 --> 00:27:58,930
ลองคิดเกี่ยวกับการที่สองสิ่งที่มัน
ดูเหมือนว่าจะไปรับสินค้าทั้งหมดของฉัน

661
00:27:58,930 --> 00:28:01,096
>> ในร้านค้าสัมพันธ์ฉัน
ต้องการที่จะได้รับผลิตภัณฑ์ของฉัน

662
00:28:01,096 --> 00:28:02,970
อยู่ในรายชื่อของผลิตภัณฑ์ทั้งหมดของฉัน

663
00:28:02,970 --> 00:28:04,910
นั่นเป็นจำนวนมากของแบบสอบถาม

664
00:28:04,910 --> 00:28:07,030
ผมได้รับการสอบถามสำหรับหนังสือทุกเล่มของฉัน

665
00:28:07,030 --> 00:28:08,470
ผมได้รับการสอบถามจากอัลบั้มของฉัน

666
00:28:08,470 --> 00:28:09,970
และผมได้รับการสอบถามสำหรับวิดีโอทั้งหมดของฉัน

667
00:28:09,970 --> 00:28:11,719
และฉันได้ที่จะนำมัน
ทั้งหมดเข้าด้วยกันในรายการ

668
00:28:11,719 --> 00:28:15,250
และให้บริการได้กลับขึ้นไป
แอพลิเคชันที่ร้องขอ

669
00:28:15,250 --> 00:28:18,000
>> ที่จะได้รับหนังสือของฉันฉันเข้าร่วม
ผลิตภัณฑ์และหนังสือ

670
00:28:18,000 --> 00:28:21,680
ที่จะได้รับอัลบั้มของฉันฉันได้รับที่จะเข้าร่วม
ผลิตภัณฑ์อัลบั้มและเพลง

671
00:28:21,680 --> 00:28:25,330
และเพื่อให้ได้วิดีโอของฉันฉันมี
ผลิตภัณฑ์ที่จะเข้าร่วมในการวิดีโอ,

672
00:28:25,330 --> 00:28:28,890
เข้าร่วมผ่านวิดีโอดารา
และนำมาในนักแสดง

673
00:28:28,890 --> 00:28:31,020
เพื่อให้เป็นสามคำสั่ง

674
00:28:31,020 --> 00:28:34,560
คำสั่งที่ซับซ้อนมาก
ประกอบชุดผลอย่างใดอย่างหนึ่ง

675
00:28:34,560 --> 00:28:36,540
>> ที่น้อยกว่าที่ดีที่สุด

676
00:28:36,540 --> 00:28:39,200
นี่คือเหตุผลที่เมื่อเราพูด
เกี่ยวกับโครงสร้างข้อมูลที่

677
00:28:39,200 --> 00:28:42,900
สร้างขึ้นเพื่อเป็นที่จะไม่เชื่อเรื่องพระเจ้าเข้าถึง
pattern-- กันดีว่าเป็นเรื่องใหญ่

678
00:28:42,900 --> 00:28:45,730
และคุณสามารถเห็นนี้เป็นจริง
วิธีที่ดีที่เราได้จัดข้อมูล

679
00:28:45,730 --> 00:28:46,550
และคุณรู้ว่าสิ่งที่?

680
00:28:46,550 --> 00:28:49,750
ฉันมีเพียงหนึ่งระเบียนสำหรับนักแสดง

681
00:28:49,750 --> 00:28:50,440
>> ที่เย็น

682
00:28:50,440 --> 00:28:53,750
ฉันได้ deduplicated นักแสดงทั้งหมดของฉัน
และฉันเก็บรักษาความสัมพันธ์ของฉัน

683
00:28:53,750 --> 00:28:55,200
ในตารางการทำแผนที่นี้

684
00:28:55,200 --> 00:29:00,620
แต่ได้รับข้อมูล
ออกมีราคาแพง

685
00:29:00,620 --> 00:29:04,500
ฉันส่งซีพียูทั่วระบบ
ร่วมงานกับโครงสร้างข้อมูลเหล่านี้ร่วมกัน

686
00:29:04,500 --> 00:29:05,950
เพื่อให้สามารถที่จะดึงข้อมูลที่กลับมา

687
00:29:05,950 --> 00:29:07,310
>> ดังนั้นฉันจะได้รับรอบที่?

688
00:29:07,310 --> 00:29:11,200
ใน NoSQL มันเป็นเรื่องของ
รวมไม่ฟื้นฟู

689
00:29:11,200 --> 00:29:13,534
ดังนั้นเราจึงอยากจะบอกว่าเราต้องการที่จะ
สนับสนุนรูปแบบการเข้าถึง

690
00:29:13,534 --> 00:29:15,283
หากรูปแบบการเข้าถึง
เพื่อการใช้งานที่

691
00:29:15,283 --> 00:29:16,770
ฉันต้องการที่จะได้รับผลิตภัณฑ์ทั้งหมดของฉัน

692
00:29:16,770 --> 00:29:19,027
ขอนำผลิตภัณฑ์ทั้งหมดในหนึ่งตาราง

693
00:29:19,027 --> 00:29:22,110
ถ้าผมจะนำผลิตภัณฑ์ทั้งหมดในหนึ่งตาราง
ฉันสามารถเลือกผลิตภัณฑ์ทั้งหมด

694
00:29:22,110 --> 00:29:23,850
จากตารางที่ผมได้รับมันทั้งหมด

695
00:29:23,850 --> 00:29:25,240
ดีฉันจะทำเช่นนั้น?

696
00:29:25,240 --> 00:29:28,124
ดีใน NoSQL ไม่มี
โครงสร้างตาราง

697
00:29:28,124 --> 00:29:30,540
เราจะพูดเล็กน้อยเกี่ยวกับ
วิธีการทำงานนี้ในไดนาโม DB

698
00:29:30,540 --> 00:29:33,570
แต่คุณไม่ได้เหมือนกัน
คุณลักษณะและคุณสมบัติเดียวกัน

699
00:29:33,570 --> 00:29:37,751
ในทุกแถวเดียวในทุกๆ
รายการเช่นที่คุณทำในตาราง SQL

700
00:29:37,751 --> 00:29:39,750
และสิ่งนี้จะช่วยให้ฉัน
ที่จะทำคือสิ่งต่างๆมากมาย

701
00:29:39,750 --> 00:29:41,124
และให้ฉันมีความยืดหยุ่นมาก

702
00:29:41,124 --> 00:29:45,360
โดยเฉพาะในกรณีนี้ผม
มีเอกสารผลิตภัณฑ์ของฉัน

703
00:29:45,360 --> 00:29:49,090
และในการนี​​้โดยเฉพาะ
ตัวอย่างเช่นทุกอย่าง

704
00:29:49,090 --> 00:29:51,930
เป็นเอกสารในตารางผลิตภัณฑ์

705
00:29:51,930 --> 00:29:56,510
และผลิตภัณฑ์สำหรับหนังสืออาจจะ
มีบัตรประจำตัวที่ระบุประเภทหนังสือ

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
ผมดำเนินการอย่างใดอย่างหนึ่งแบบสอบถาม

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
คือสิ่งที่เราเรียกว่า
โค้ง hype เทคโนโลยี

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
Boy, สิ่งนี้มีกลิ่นเหม็น

801
00:33:45,230 --> 00:33:49,900
ผมต้องรักษาทั้งหมดของฉัน
ร่วม in-- ก็เหมือนไม่มี

802
00:33:49,900 --> 00:33:50,800
รักษาร่วม?

803
00:33:50,800 --> 00:33:52,430
คุณจะมาร่วมงานกับข้อมูลทำไม?

804
00:33:52,430 --> 00:33:54,350
คุณไม่ได้เข้าร่วมในข้อมูล NoSQL

805
00:33:54,350 --> 00:33:55,850
คุณรวมมัน

806
00:33:55,850 --> 00:34:00,690
>> ดังนั้นหากคุณต้องการที่จะหลีกเลี่ยงปัญหานี้ได้เรียนรู้
ว่าเครื่องมือการทำงานก่อนที่จะ

807
00:34:00,690 --> 00:34:02,010
เริ่มใช้มัน

808
00:34:02,010 --> 00:34:04,860
อย่าพยายามและใช้เครื่องมือใหม่
แบบเดียวกับที่คุณใช้เครื่องมือเก่า

809
00:34:04,860 --> 00:34:06,500
คุณกำลังจะมีประสบการณ์ที่ไม่ดี

810
00:34:06,500 --> 00:34:08,848
และทุกครั้งเดียว
นั่นคือสิ่งนี้เป็นเรื่องเกี่ยว

811
00:34:08,848 --> 00:34:11,389
เมื่อเราเริ่มต้นขึ้นมาที่นี่
มันเป็นเพราะคนที่คิดออก

812
00:34:11,389 --> 00:34:13,449
วิธีการใช้เครื่องมือ

813
00:34:13,449 --> 00:34:16,250
>> พวกเขาทำในสิ่งเดียวกันเมื่อ
ฐานข้อมูลเชิงสัมพันธ์ที่ถูกคิดค้น

814
00:34:16,250 --> 00:34:17,969
และพวกเขาก็เปลี่ยนระบบไฟล์

815
00:34:17,969 --> 00:34:20,420
พวกเขาพยายามที่จะสร้างระบบไฟล์
กับฐานข้อมูลเชิงสัมพันธ์

816
00:34:20,420 --> 00:34:22,159
เพราะนั่นคือสิ่งที่ผู้คนเข้าใจ

817
00:34:22,159 --> 00:34:23,049
มันไม่ได้ทำงาน

818
00:34:23,049 --> 00:34:26,090
ดังนั้นการทำความเข้าใจปฏิบัติที่ดีที่สุด
ของเทคโนโลยีที่คุณกำลังทำงานกับ

819
00:34:26,090 --> 00:34:26,730
มีขนาดใหญ่มาก

820
00:34:26,730 --> 00:34:29,870
สำคัญมาก.

821
00:34:29,870 --> 00:34:32,440
>> ดังนั้นเรากำลังจะได้รับใน DynamoDB

822
00:34:32,440 --> 00:34:36,480
DynamoDB เป็นของ AWS
อย่างเต็มที่ที่มีการจัดการแพลตฟอร์ม NoSQL

823
00:34:36,480 --> 00:34:37,719
อะไรที่มีการจัดการอย่างเต็มที่หมายความว่าอย่างไร

824
00:34:37,719 --> 00:34:40,010
มันหมายความว่าคุณไม่จำเป็นต้อง
จริงๆกังวลเกี่ยวกับอะไร

825
00:34:40,010 --> 00:34:42,060
>> คุณมาที่คุณบอก
เราผมต้องตาราง

826
00:34:42,060 --> 00:34:43,409
มันต้องมีความจุมากขนาดนี้

827
00:34:43,409 --> 00:34:47,300
คุณกดปุ่มและการให้เรา
โครงสร้างพื้นฐานที่อยู่เบื้องหลังฉาก

828
00:34:47,300 --> 00:34:48,310
ตอนนี้เป็นอย่างมาก

829
00:34:48,310 --> 00:34:51,310
>> เพราะเมื่อคุณพูดคุย
เกี่ยวกับการปรับฐานข้อมูล

830
00:34:51,310 --> 00:34:53,917
NoSQL กลุ่มข้อมูล
ขนาดทำงานเพตาไบต์,

831
00:34:53,917 --> 00:34:55,750
ทำงานนับล้าน
การทำธุรกรรมต่อวินาที

832
00:34:55,750 --> 00:34:58,180
สิ่งเหล่านี้เป็นกลุ่มเล็ก ๆ ไม่ได้

833
00:34:58,180 --> 00:35:00,830
เรากำลังพูดถึงหลายพันกรณี

834
00:35:00,830 --> 00:35:04,480
ผู้จัดการพันกรณี
แม้กระทั่งกรณีเสมือน

835
00:35:04,480 --> 00:35:06,350
เป็นความเจ็บปวดจริงในก้น

836
00:35:06,350 --> 00:35:09,110
ผมหมายถึงคิดเกี่ยวกับเวลาทุก
แพทช์ระบบปฏิบัติการออกมา

837
00:35:09,110 --> 00:35:11,552
หรือรุ่นใหม่ของฐานข้อมูล

838
00:35:11,552 --> 00:35:13,260
นั่นหมายความว่าอย่างไร
ในการดำเนินงานให้กับคุณ?

839
00:35:13,260 --> 00:35:16,330
ซึ่งหมายความว่าคุณได้ 1,200
เซิร์ฟเวอร์ที่ต้องมีการปรับปรุง

840
00:35:16,330 --> 00:35:18,960
ตอนนี้แม้จะมีระบบอัตโนมัติ
ที่สามารถใช้เวลานาน

841
00:35:18,960 --> 00:35:21,480
ที่สามารถทำให้เกิดจำนวนมาก
อาการปวดหัวในการดำเนินงาน

842
00:35:21,480 --> 00:35:23,090
เพราะผมอาจจะมีการให้บริการลง

843
00:35:23,090 --> 00:35:26,070
>> ขณะที่ผมปรับปรุงฐานข้อมูลเหล่านี้ผม
อาจจะใช้งานสีเขียวสีฟ้า

844
00:35:26,070 --> 00:35:29,420
ที่ฉันปรับใช้และอัพเกรดครึ่งหนึ่งของฉัน
โหนดแล้วอัพเกรดอีกครึ่งหนึ่ง

845
00:35:29,420 --> 00:35:30,490
ใช้เวลาเหล่านั้นลง

846
00:35:30,490 --> 00:35:33,410
ดังนั้นการจัดการโครงสร้างพื้นฐาน
ขนาดเป็นความเจ็บปวดอย่างมาก

847
00:35:33,410 --> 00:35:36,210
และ AWS เอาความเจ็บปวดที่ออกมาจากมัน

848
00:35:36,210 --> 00:35:39,210
และฐานข้อมูล NoSQL สามารถ
จะเจ็บปวดเป็นพิเศษ

849
00:35:39,210 --> 00:35:41,780
เพราะวิธีที่พวกเขาขนาด

850
00:35:41,780 --> 00:35:42,926
>> ขนาดในแนวนอน

851
00:35:42,926 --> 00:35:45,550
ถ้าคุณต้องการที่จะได้รับใหญ่ NoSQL
ฐานข้อมูลที่คุณจะซื้อโหนดเพิ่มเติม

852
00:35:45,550 --> 00:35:48,660
โหนดที่คุณจะซื้อทุกคนเป็น
อีกปวดหัวในการดำเนินงาน

853
00:35:48,660 --> 00:35:50,830
ดังนั้นขอให้คนอื่นทำเพื่อคุณ

854
00:35:50,830 --> 00:35:52,000
AWS สามารถทำเช่นนั้น

855
00:35:52,000 --> 00:35:54,587
>> เราสนับสนุนค่าคีย์เอกสาร

856
00:35:54,587 --> 00:35:56,670
ตอนนี้เราไม่ได้ไปมากเกินไป
เข้ามาในชาร์ตอื่น ๆ

857
00:35:56,670 --> 00:35:58,750
มีจำนวนมากที่แตกต่างกันคือ
รสชาติของ NoSQL

858
00:35:58,750 --> 00:36:02,670
พวกเขากำลังชนิดของการได้รับทั้งหมด
munged ร่วมกันที่จุดนี้

859
00:36:02,670 --> 00:36:06,260
คุณสามารถดู DynamoDB และบอกว่าใช่
เราทั้งสองเอกสารและค่าคีย์

860
00:36:06,260 --> 00:36:08,412
เก็บจุดนี้

861
00:36:08,412 --> 00:36:10,620
และคุณสามารถยืนยันคุณสมบัติ
หนึ่งในช่วงอื่น ๆ

862
00:36:10,620 --> 00:36:13,950
ให้ฉันจำนวนมากนี้เป็นจริงหก
หนึ่งครึ่งโหลของอื่น ๆ

863
00:36:13,950 --> 00:36:18,710
ทุกคนของเทคโนโลยีเหล่านี้เป็น
เทคโนโลยีที่ดีและเป็นทางออกที่ดี

864
00:36:18,710 --> 00:36:23,390
ฉันจะไม่พูด MongoDB จะดีกว่าหรือ
เลวร้ายยิ่งกว่าที่นอนแล้วคาสซานดรา

865
00:36:23,390 --> 00:36:25,994
แล้วไดนาโมหรือในทางกลับกัน

866
00:36:25,994 --> 00:36:27,285
ผมหมายถึงเหล่านี้เป็นเพียงตัวเลือก

867
00:36:27,285 --> 00:36:29,850

868
00:36:29,850 --> 00:36:32,700
>> มันรวดเร็วและก็
ที่สอดคล้องกันในระดับใด

869
00:36:32,700 --> 00:36:36,210
ดังนั้นนี้เป็นหนึ่งในที่ใหญ่ที่สุด
คุณจะได้รับโบนัสกับ AWS

870
00:36:36,210 --> 00:36:40,850
ด้วย DynamoDB คือความสามารถใน
ที่จะได้รับหลักเดียวต่ำ

871
00:36:40,850 --> 00:36:44,040
มิลลิวินาทีแฝงในระดับใด

872
00:36:44,040 --> 00:36:45,720
นั่นคือเป้าหมายการออกแบบของระบบ

873
00:36:45,720 --> 00:36:49,130
และเรามีลูกค้าที่มีการทำ
ล้านรายการต่อวินาที

874
00:36:49,130 --> 00:36:52,670
>> ตอนนี้ฉันจะไปถึงบางส่วนของผู้
กรณีการใช้งานในไม่กี่นาทีที่นี่

875
00:36:52,670 --> 00:36:55,660
การเข้าถึงแบบบูรณาการ control--
เรามีสิ่งที่เราเรียกว่า

876
00:36:55,660 --> 00:36:57,920
รหัสประจำตัวการจัดการการเข้าถึงหรือ IAM

877
00:36:57,920 --> 00:37:01,980
มันแทรกซึมระบบทุก
บริการ AWS ทุกคนที่เสนอ

878
00:37:01,980 --> 00:37:03,630
DynamoDB จะไม่มีข้อยกเว้น

879
00:37:03,630 --> 00:37:06,020
คุณสามารถควบคุมการเข้าถึง
กับตาราง DynamoDB

880
00:37:06,020 --> 00:37:09,960
ในทุกบัญชีของคุณโดย AWS
การกำหนดบทบาทและสิทธิ์การเข้าถึง

881
00:37:09,960 --> 00:37:12,140
ในโครงสร้างพื้นฐาน IAM

882
00:37:12,140 --> 00:37:16,630
>> และมันก็เป็นองค์ประกอบที่สำคัญและสำคัญในการ
สิ่งที่เราเรียกเหตุการณ์การเขียนโปรแกรมขับเคลื่อน

883
00:37:16,630 --> 00:37:19,056
ตอนนี้เป็นกระบวนทัศน์ใหม่

884
00:37:19,056 --> 00:37:22,080
>> ผู้ชม: วิธีอัตราที่แท้จริงของคุณ
บวกกับเชิงลบเท็จ

885
00:37:22,080 --> 00:37:24,052
ในระบบการควบคุมการเข้าถึงของคุณ?

886
00:37:24,052 --> 00:37:26,260
RICK Houlihan: บวกทรู
เมื่อเทียบกับเชิงลบเท็จ?

887
00:37:26,260 --> 00:37:28,785
ผู้ชม: สิ่งที่กลับมา
คุณควรจะกลับมา?

888
00:37:28,785 --> 00:37:33,720
เมื่อเทียบกับครั้งในขณะที่มัน
ไม่ได้กลับมาเมื่อมันควรจะตรวจสอบ?

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

890
00:37:36,260 --> 00:37:38,050
>> RICK Houlihan: ผมไม่สามารถบอกคุณได้ว่า

891
00:37:38,050 --> 00:37:40,140
หากมีความล้มเหลวใด ๆ
ใด ๆ ในนั้น

892
00:37:40,140 --> 00:37:42,726
ฉันไม่ได้เป็นคนที่จะถาม
คำถามที่โดยเฉพาะอย่างยิ่ง

893
00:37:42,726 --> 00:37:43,850
แต่นั่นเป็นคำถามที่ดี

894
00:37:43,850 --> 00:37:45,905
ผมจะมีความอยากรู้อยากเห็นที่จะรู้ว่า
ที่ตัวเองจริง

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

896
00:37:48,810 --> 00:37:51,320
>> และอื่น ๆ แล้วอีกครั้งกระบวนทัศน์ใหม่
คือการเขียนโปรแกรมขับเคลื่อนเหตุการณ์

897
00:37:51,320 --> 00:37:55,160
นี่คือความคิดที่คุณสามารถ
ปรับใช้งานที่ซับซ้อนที่

898
00:37:55,160 --> 00:37:59,720
สามารถทำงานได้มากขนาดที่สูงมาก
โดยไม่ต้องมีโครงสร้างพื้นฐานใด ๆ

899
00:37:59,720 --> 00:38:02,120
โดยไม่ต้องได้รับการแก้ไขใด ๆ
โครงสร้างพื้นฐานใด ๆ

900
00:38:02,120 --> 00:38:04,720
และเราจะพูดคุยนิด ๆ หน่อย ๆ
เกี่ยวกับสิ่งที่หมายถึงการที่เรา

901
00:38:04,720 --> 00:38:06,550
ที่จะได้รับในคู่ต่อไปของชาร์ต

902
00:38:06,550 --> 00:38:08,716
>> สิ่งแรกที่เราจะทำ
คือเราจะพูดคุยเกี่ยวกับตาราง

903
00:38:08,716 --> 00:38:10,857
ชนิดข้อมูล API สำหรับการไดนาโม

904
00:38:10,857 --> 00:38:13,190
และสิ่งแรกที่คุณจะ
แจ้งให้ทราบเมื่อคุณมองไปที่นี้

905
00:38:13,190 --> 00:38:17,930
ถ้าคุณคุ้นเคยกับฐานข้อมูลใด ๆ
ฐานข้อมูลจริงๆมีสองชนิดของ API

906
00:38:17,930 --> 00:38:18,430
ฉันเรียกมันว่า

907
00:38:18,430 --> 00:38:21,570
หรือสองชุดของ API

908
00:38:21,570 --> 00:38:23,840
หนึ่งในนั้นจะเป็น
การบริหาร API

909
00:38:23,840 --> 00:38:26,710
>> สิ่งที่พวกเขาดูแล
ฟังก์ชั่นของฐานข้อมูล

910
00:38:26,710 --> 00:38:31,340
การกำหนดค่าของเครื่องมือการจัดเก็บ
การตั้งค่าและเพิ่มตาราง

911
00:38:31,340 --> 00:38:35,180
การสร้างฐานข้อมูล
แคตตาล็อกและกรณี

912
00:38:35,180 --> 00:38:40,450
เหล่านี้ things-- ใน DynamoDB คุณ
มีสั้นมากรายการสั้น

913
00:38:40,450 --> 00:38:43,120
>> ดังนั้นในฐานข้อมูลอื่น ๆ
คุณอาจเห็นหลายสิบ

914
00:38:43,120 --> 00:38:45,680
คำสั่งของผู้ดูแลระบบ
คำสั่งสำหรับการกำหนดค่า

915
00:38:45,680 --> 00:38:47,290
เหล่านี้ตัวเลือกเพิ่มเติม

916
00:38:47,290 --> 00:38:51,234
ใน DynamoDB คุณไม่จำเป็นต้องเหล่านั้นเพราะ
คุณไม่ได้กำหนดค่าระบบที่เราทำ

917
00:38:51,234 --> 00:38:54,150
ดังนั้นสิ่งเดียวที่คุณต้องทำคือ
บอกฉันว่าตารางขนาดฉันจะต้อง

918
00:38:54,150 --> 00:38:55,660
ดังนั้นคุณจะได้รับมาก
ชุด จำกัด ของคำสั่ง

919
00:38:55,660 --> 00:38:58,618
>> คุณจะได้รับการปรับปรุงสร้างตาราง, ตาราง
ลบ Table และอธิบายตาราง

920
00:38:58,618 --> 00:39:01,150
เหล่านี้คือสิ่งเดียว
ที่คุณต้องการสำหรับ DynamoDB

921
00:39:01,150 --> 00:39:03,294
คุณไม่จำเป็นต้องจัดเก็บข้อมูล
การตั้งค่าเครื่องมือ

922
00:39:03,294 --> 00:39:04,960
ฉันไม่จำเป็นต้องกังวลเกี่ยวกับการจำลองแบบ

923
00:39:04,960 --> 00:39:06,490
ฉันไม่จำเป็นต้องกังวลเกี่ยวกับ sharding

924
00:39:06,490 --> 00:39:07,800
>> ผมไม่จำเป็นต้องกังวล
ใด ๆ เกี่ยวกับเรื่องนี้

925
00:39:07,800 --> 00:39:08,740
เราทำทุกอย่างให้คุณ

926
00:39:08,740 --> 00:39:11,867
เพื่อให้เป็นจำนวนมากของค่าใช้จ่าย
ที่ยกห่างจากจานของคุณ

927
00:39:11,867 --> 00:39:13,200
แล้วเรามีผู้ประกอบการ CRUD

928
00:39:13,200 --> 00:39:17,740
CRUD เป็นสิ่งที่สิ่งที่เรา
โทรในฐานข้อมูลที่

929
00:39:17,740 --> 00:39:19,860
สร้างปรับปรุงลบผู้ประกอบการ

930
00:39:19,860 --> 00:39:24,180
เหล่านี้เป็นเรื่องปกติของคุณ
ดำเนินงานฐานข้อมูล

931
00:39:24,180 --> 00:39:31,299
สิ่งที่ต้องการวางรายการที่ได้รับรายการการปรับปรุง
รายการลบรายการแบบสอบถามชุดสแกน

932
00:39:31,299 --> 00:39:32,840
หากคุณต้องการที่จะสแกนทั้งตาราง

933
00:39:32,840 --> 00:39:34,220
ดึงทุกอย่างออกจากตาราง

934
00:39:34,220 --> 00:39:37,130
หนึ่งในสิ่งที่ดีเกี่ยวกับ DynamoDB
มันช่วยให้การสแกนแบบคู่ขนาน

935
00:39:37,130 --> 00:39:40,602
ดังนั้นคุณสามารถแจ้งให้เราทราบว่าหลาย
หัวข้อที่คุณต้องการที่จะทำงานในการสแกนที่

936
00:39:40,602 --> 00:39:41,810
และเราสามารถเรียกใช้กระทู้เหล่านั้น

937
00:39:41,810 --> 00:39:43,985
เราสามารถหมุนที่สแกนขึ้น
ข้ามหลายหัวข้อ

938
00:39:43,985 --> 00:39:49,060
เพื่อให้คุณสามารถสแกนทั้งตาราง
พื้นที่มากอย่างรวดเร็วใน DynamoDB

939
00:39:49,060 --> 00:39:51,490
>> API ที่เราได้เป็นอื่น ๆ
สิ่งที่เราเรียกกระแส API ของเรา

940
00:39:51,490 --> 00:39:52,940
เราจะไม่มากเกินไปที่จะพูดคุย
เกี่ยวกับเรื่องนี้มากในขณะนี้

941
00:39:52,940 --> 00:39:55,189
ฉันมีเนื้อหาบางส่วนในภายหลัง
ในสำรับเกี่ยวกับเรื่องนี้

942
00:39:55,189 --> 00:39:59,910
แต่กระแสจริงๆ running--
คิดว่ามันเป็นเวลาที่สั่งซื้อ

943
00:39:59,910 --> 00:40:01,274
และบันทึกการเปลี่ยนแปลงพาร์ทิชัน

944
00:40:01,274 --> 00:40:03,940
ทุกอย่างที่เกิดขึ้นใน
ตารางแสดงบนกระแส

945
00:40:03,940 --> 00:40:05,940
>> ทุกคนเขียนถึงโต๊ะ
ปรากฏขึ้นบนกระแส

946
00:40:05,940 --> 00:40:08,370
คุณสามารถอ่านกระแสนั้นและ
คุณสามารถทำสิ่งกับมัน

947
00:40:08,370 --> 00:40:10,150
เราจะพูดคุยเกี่ยวกับสิ่งที่
ชนิดของสิ่งที่คุณ

948
00:40:10,150 --> 00:40:13,680
จะทำอย่างไรกับสิ่งที่ต้องการการจำลองแบบ
การสร้างดัชนีรอง

949
00:40:13,680 --> 00:40:17,620
ทุกชนิดของเย็นจริงๆ
สิ่งที่คุณสามารถทำกับที่

950
00:40:17,620 --> 00:40:19,150
>> ข้อมูลประเภท

951
00:40:19,150 --> 00:40:23,320
ใน DynamoDB เราสนับสนุนที่สำคัญทั้ง
มูลค่าและเอกสารชนิดข้อมูล

952
00:40:23,320 --> 00:40:26,350
ที่ด้านซ้ายมือของหน้าจอ
ที่นี่เรามีประเภทพื้นฐานของเรา

953
00:40:26,350 --> 00:40:27,230
ประเภทค่าที่สำคัญ

954
00:40:27,230 --> 00:40:30,040
เหล่านี้เป็นเงื่อนไข
ตัวเลขและไบนารี

955
00:40:30,040 --> 00:40:31,640
>> ดังนั้นเพียงแค่สามประเภทพื้นฐาน

956
00:40:31,640 --> 00:40:33,700
และจากนั้นคุณสามารถมีชุดของคนเหล่านั้น

957
00:40:33,700 --> 00:40:37,650
หนึ่งในสิ่งที่ดีเกี่ยวกับ NoSQL คือ
คุณสามารถมีอาร์เรย์คุณสมบัติ

958
00:40:37,650 --> 00:40:42,050
และด้วย DynamoDB คุณสามารถมีอาร์เรย์
ของประเภทพื้นฐานเป็นทรัพย์สินราก

959
00:40:42,050 --> 00:40:43,885
>> แล้วมีประเภทเอกสาร

960
00:40:43,885 --> 00:40:45,510
วิธีการหลายคนมีความคุ้นเคยกับ JSON?

961
00:40:45,510 --> 00:40:47,130
พวกคุณคุ้นเคยกับ JSON มาก?

962
00:40:47,130 --> 00:40:49,380
มันเป็นพื้น 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 มี
หนึ่งคุณลักษณะที่จำเป็น

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
และผมอาจจะมีความสำคัญช่วง
ซึ่งเป็นรหัสการตอบสนอง

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
ที่ไม่ได้อยู่ระหว่างทั้งสองค่า?

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
วิธีการหลายคนคุ้นเคย
มีขั้นตอนวิธีการ hashing?

1040
00:44:47,050 --> 00:44:49,860
เมื่อฉันพูดว่ากัญชาและ hashing--
เพราะขั้นตอนวิธี hashing

1041
00:44:49,860 --> 00:44:54,140
เป็นวิธีการของความสามารถในการสร้าง
ค่าสุ่มจากมูลค่าใดก็ตาม

1042
00:44:54,140 --> 00:44:59,300
ดังนั้นในกรณีนี้โดยเฉพาะที่
ขั้นตอนวิธีการที่เราใช้กัญชาเป็น ND 5 based

1043
00:44:59,300 --> 00:45:04,765
>> และถ้าฉันมีประชาชนและนี้
เป็นกุญแจสำคัญในกัญชาของฉันฉันมี 1, 2, 3

1044
00:45:04,765 --> 00:45:07,390
เมื่อผมใช้วิธีกัญชา,
มันจะกลับมาและพูดว่า

1045
00:45:07,390 --> 00:45:10,800
ดี 1 เท่ากับ 7B 2
เท่ากับ 48, 3 เท่ากับซีดี

1046
00:45:10,800 --> 00:45:13,092
พวกเขากำลังกระจายไปทั่วพื้นที่ที่สำคัญ

1047
00:45:13,092 --> 00:45:14,050
และทำไมคุณทำเช่นนี้?

1048
00:45:14,050 --> 00:45:17,120
เพราะนั่นทำให้แน่ใจว่าฉันสามารถ
ใส่ระเบียนทั่วโหนดหลาย

1049
00:45:17,120 --> 00:45:19,574
>> ถ้าผมทำเช่นนี้
เพิ่มขึ้น, 1, 2, 3

1050
00:45:19,574 --> 00:45:21,990
และผมก็มีช่วงกัญชาที่
วิ่งในกรณีนี้โดยเฉพาะ

1051
00:45:21,990 --> 00:45:24,785
พื้นที่กัญชาขนาดเล็ก
มันเริ่มต้นตั้งแต่ 00 ถึง FF,

1052
00:45:24,785 --> 00:45:27,951
แล้วบันทึกกำลังจะมาใน
และพวกเขากำลังจะไปที่ 1, 2, 3, 4, 5,

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

1054
00:45:30,390 --> 00:45:31,800
เกิดอะไรขึ้น?

1055
00:45:31,800 --> 00:45:34,860
แทรกทุกคนเป็นไปโหนดเดียวกัน

1056
00:45:34,860 --> 00:45:36,070
คุณจะเห็นสิ่งที่ฉันหมายความว่าอย่างไร

1057
00:45:36,070 --> 00:45:40,910
>> เพราะเมื่อฉันแบ่งพื้นที่
เราก็ขยายระเบียนเหล่านี้ข้าม

1058
00:45:40,910 --> 00:45:45,950
และพาร์ทิชันฉันฉันจะบอกว่า
พาร์ทิชันที่ 1 มีพื้นที่สำคัญที่ 0-54

1059
00:45:45,950 --> 00:45:47,720
พาร์ทิชัน 2 เป็น 55-89

1060
00:45:47,720 --> 00:45:49,780
พาร์ทิชัน 3 เป็น AA ถึง FF

1061
00:45:49,780 --> 00:45:53,740
ดังนั้นถ้าผมใช้เส้นตรงการเพิ่ม
รหัสคุณจะเห็นสิ่งที่เกิดขึ้น

1062
00:45:53,740 --> 00:45:57,410
1, 2, 3, 4, 5, 6, ตลอดทางถึง 54

1063
00:45:57,410 --> 00:46:00,030
ดังนั้นในขณะที่ผมกำลังตอก
บันทึกลงในระบบ

1064
00:46:00,030 --> 00:46:02,030
ทุกอย่างจบลงไปหนึ่งโหนด

1065
00:46:02,030 --> 00:46:03,160
>> ที่ไม่ดี

1066
00:46:03,160 --> 00:46:04,820
นั่นคือ antipattern

1067
00:46:04,820 --> 00:46:08,760
ใน MongoDB พวกเขามีปัญหานี้
ถ้าคุณไม่ได้ใช้คีย์กัญชา

1068
00:46:08,760 --> 00:46:11,325
MongoDB ให้คุณเลือก
ของ hashing ค่าคีย์

1069
00:46:11,325 --> 00:46:13,950
คุณควรทำเช่นนั้นถ้า
คุณกำลังใช้กัญชา incrementing

1070
00:46:13,950 --> 00:46:17,380
ที่สำคัญใน MongoDB, หรือคุณจะเป็น
เขียนเก่งทุกหนึ่งโหนด

1071
00:46:17,380 --> 00:46:21,290
และคุณจะถูก จำกัด
ผ่านการเขียนของคุณไม่ดี

1072
00:46:21,290 --> 00:46:24,896
>> ผู้ชม: คือ A9 169 ในทศนิยม?

1073
00:46:24,896 --> 00:46:28,450
>> RICK Houlihan: ใช่มัน
บางรอบมี

1074
00:46:28,450 --> 00:46:29,950
A9, ผมไม่ทราบว่า

1075
00:46:29,950 --> 00:46:32,200
คุณจะต้องได้รับไบนารีของฉัน
เครื่องคิดเลขทศนิยม

1076
00:46:32,200 --> 00:46:34,237
สมองของฉันไม่ทำงานเช่นนั้น

1077
00:46:34,237 --> 00:46:36,320
ผู้ชม: เพ​​ียงหนึ่งอย่างรวดเร็ว
ความคิดเห็น Mongo ของคุณ

1078
00:46:36,320 --> 00:46:39,530
ดังนั้นวัตถุ ID ที่มา
กำเนิดกับ Mongo ทำเช่นนั้น?

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

1080
00:46:40,179 --> 00:46:41,470
RICK Houlihan: มันทำเช่นนั้น?

1081
00:46:41,470 --> 00:46:42,970
ถ้าคุณระบุว่า

1082
00:46:42,970 --> 00:46:45,030
ด้วย MongoDB, คุณมีตัวเลือก

1083
00:46:45,030 --> 00:46:48,930
คุณสามารถ specify-- เอกสารทุกคนใน
MongoDB จะต้องมีขีด ID

1084
00:46:48,930 --> 00:46:50,300
นั่นคือค่าไม่ซ้ำกัน

1085
00:46:50,300 --> 00:46:55,240
>> ใน MongoDB คุณสามารถระบุ
ว่าจะสับหรือไม่

1086
00:46:55,240 --> 00:46:56,490
พวกเขาเพียงแค่ให้คุณเลือก

1087
00:46:56,490 --> 00:46:58,198
ถ้าคุณรู้ว่ามันเป็น
สุ่มไม่มีปัญหา

1088
00:46:58,198 --> 00:46:59,640
คุณไม่จำเป็นต้องที่จะทำ

1089
00:46:59,640 --> 00:47:04,260
ถ้าคุณรู้ว่ามันไม่ได้เป็นแบบสุ่มที่
มัน incrementing แล้วทำแฮช

1090
00:47:04,260 --> 00:47:06,880
>> ตอนนี้สิ่งที่เกี่ยวกับ
hashing เมื่อคุณสับ

1091
00:47:06,880 --> 00:47:08,800
value-- และนี่คือ
ทำไมคีย์กัญชาอยู่เสมอ

1092
00:47:08,800 --> 00:47:13,740
คำสั่งที่ไม่ซ้ำกันเพราะผมได้เปลี่ยน
ค่าตอนนี้ฉันไม่สามารถทำแบบสอบถามช่วง

1093
00:47:13,740 --> 00:47:15,640
ฉันไม่สามารถพูดนี้
ระหว่างนี้หรือว่า

1094
00:47:15,640 --> 00:47:20,800
เพราะค่าแฮชไม่ได้ไป
จะเทียบเท่ากับมูลค่าที่เกิดขึ้นจริง

1095
00:47:20,800 --> 00:47:24,570
ดังนั้นเมื่อคุณสับที่
ที่สำคัญเท่าเทียมกันก็เพียง

1096
00:47:24,570 --> 00:47:28,700
นี่คือเหตุผลที่ในคีย์กัญชา DynamoDB
คำสั่งอยู่เสมอเท่าเทียมกันเท่านั้น

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

1098
00:47:32,090 --> 00:47:34,700
>> ดังนั้นตอนนี้อยู่ในช่วง key--
เมื่อฉันเพิ่มคีย์ช่วงนั้น

1099
00:47:34,700 --> 00:47:38,180
บันทึกช่วงที่สำคัญเหล่านั้นทั้งหมดมาและ
พวกเขาได้รับการจัดเก็บไว้ในพาร์ทิชันเดียวกัน

1100
00:47:38,180 --> 00:47:42,430
ดังนั้นพวกเขาจึงมีความได้อย่างรวดเร็วง่ายดาย
เรียกคืนเพราะเป็นกัญชา,

1101
00:47:42,430 --> 00:47:43,220
นี้เป็นช่วง

1102
00:47:43,220 --> 00:47:44,928
และคุณจะเห็นทุกอย่าง
กับกัญชาเดียวกัน

1103
00:47:44,928 --> 00:47:48,550
ได้รับการจัดเก็บไว้ในพื้นที่พาร์ติชันเดียวกัน

1104
00:47:48,550 --> 00:47:53,889
คุณสามารถใช้คีย์ช่วงที่จะช่วยให้
ค้นหาข้อมูลของคุณใกล้กับแม่ของมัน

1105
00:47:53,889 --> 00:47:55,180
ดังนั้นสิ่งที่ฉันทำจริงๆที่นี่?

1106
00:47:55,180 --> 00:47:57,320
นี้เป็นหนึ่งถึงความสัมพันธ์มาก

1107
00:47:57,320 --> 00:48:01,490
ความสัมพันธ์ระหว่างสำคัญกัญชา
และที่สำคัญช่วงหนึ่งที่หลาย ๆ

1108
00:48:01,490 --> 00:48:03,490
ฉันจะมีปุ่มกัญชาหลาย

1109
00:48:03,490 --> 00:48:07,610
ฉันสามารถมีช่วงหลาย
กุญแจสำคัญภายในกัญชาทุก

1110
00:48:07,610 --> 00:48:11,910
>> กัญชากำหนดผู้ปกครอง
กำหนดช่วงเด็ก

1111
00:48:11,910 --> 00:48:15,240
ดังนั้นคุณจะเห็นมีอะนาล็อกที่นี่
ระหว่างการสร้างความสัมพันธ์

1112
00:48:15,240 --> 00:48:18,840
และประเภทเดียวกันของ
สร้างใน NoSQL

1113
00:48:18,840 --> 00:48:20,760
คนที่พูดคุยเกี่ยวกับ
NoSQL เป็น nonrelational

1114
00:48:20,760 --> 00:48:22,200
มันไม่ได้ nonrelational

1115
00:48:22,200 --> 00:48:24,680
ข้อมูลมักจะมีความสัมพันธ์

1116
00:48:24,680 --> 00:48:28,172
ความสัมพันธ์เหล่านั้นเพียง
รูปแบบที่แตกต่างกันมีการ

1117
00:48:28,172 --> 00:48:29,880
พูดคุยเล็ก ๆ น้อย ๆ
บิตเกี่ยวกับความทนทาน

1118
00:48:29,880 --> 00:48:34,860
เมื่อคุณเขียนถึง DynamoDB เขียน
มักจะสามทางจำลองแบบ

1119
00:48:34,860 --> 00:48:37,550
หมายความว่าเรามีสามของอาริโซน่า

1120
00:48:37,550 --> 00:48:39,160
อาริโซน่าเป็นโซนมีจำหน่าย

1121
00:48:39,160 --> 00:48:43,430
คุณสามารถคิดว่าความพร้อม
โซนเป็นศูนย์ข้อมูล

1122
00:48:43,430 --> 00:48:45,447
หรือคอลเลกชันของศูนย์ข้อมูล

1123
00:48:45,447 --> 00:48:47,780
สิ่งเหล่านี้ทางภูมิศาสตร์
ที่แยกจากกัน

1124
00:48:47,780 --> 00:48:51,610
ข้ามโซนความผิดที่แตกต่างกันทั่ว
สายส่งไฟฟ้​​าที่แตกต่างกันและที่ราบน้ำท่วมถึง

1125
00:48:51,610 --> 00:48:54,510
ความล้มเหลวในอาริโซน่าไม่ได้
จะใช้เวลาลงอีก

1126
00:48:54,510 --> 00:48:56,890
พวกเขาจะเชื่อมโยงไปยัง
ร่วมกับเส้นใยสีดำ

1127
00:48:56,890 --> 00:49:01,240
มันสนับสนุนหนึ่งย่อย 1
มิลลิวินาทีแฝงระหว่าง AZS

1128
00:49:01,240 --> 00:49:05,390
ดังนั้นข้อมูลเวลาจริงซ้ำ
มีความสามารถในหลาย AZS

1129
00:49:05,390 --> 00:49:09,990
>> และอาจเกิดการใช้งานหลายอาริโซน่า
ตอบสนองความต้องการใช้งานสูง

1130
00:49:09,990 --> 00:49:12,930
มากที่สุดขององค์กร

1131
00:49:12,930 --> 00:49:16,139
ดังนั้น DynamoDB จะถูกกระจายไป
ทั่วทั้งสาม AZS โดยค่าเริ่มต้น

1132
00:49:16,139 --> 00:49:19,430
เราเพียงจะความรู้ในการเขียน
เมื่อสองสามโหนดกลับมา

1133
00:49:19,430 --> 00:49:21,470
และพูดว่าใช่ผมได้รับมัน

1134
00:49:21,470 --> 00:49:22,050
ว่าเป็นเพราะเหตุใด

1135
00:49:22,050 --> 00:49:25,950
เพราะในด้านการอ่านเราเท่านั้น
จะให้ข้อมูลกลับเมื่อ

1136
00:49:25,950 --> 00:49:27,570
ที่เราได้รับจากสองโหนด

1137
00:49:27,570 --> 00:49:30,490
>> ถ้าฉันจำลองทั่ว
สามและฉันอ่านจากสอง

1138
00:49:30,490 --> 00:49:32,840
ผมรับประกันเสมอ
ที่จะมีอย่างน้อยหนึ่ง

1139
00:49:32,840 --> 00:49:35,720
ของผู้ที่อ่านจะเป็น
สำเนาปัจจุบันมากที่สุดของข้อมูล

1140
00:49:35,720 --> 00:49:38,340
นั่นคือสิ่งที่ทำให้ DynamoDB ที่สอดคล้องกัน

1141
00:49:38,340 --> 00:49:42,450
ตอนนี้คุณสามารถเลือกที่จะเปิด
สอดคล้องผู้อ่านออก

1142
00:49:42,450 --> 00:49:45,070
ซึ่งในกรณีนี้ผมจะพูดว่า
ผมจะอ่านจากหนึ่งโหนด

1143
00:49:45,070 --> 00:49:47,430
และผมก็ไม่สามารถรับประกันได้ว่ามันจะ
จะเป็นข้อมูลที่เป็นปัจจุบันมากที่สุด

1144
00:49:47,430 --> 00:49:49,450
>> ดังนั้นหากจะมาเขียนใน
มันไม่ได้จำลองแบบยัง

1145
00:49:49,450 --> 00:49:50,360
คุณกำลังจะได้รับสำเนาที่

1146
00:49:50,360 --> 00:49:52,220
นั่นคือการอ่านที่สอดคล้องกันในที่สุด

1147
00:49:52,220 --> 00:49:54,640
และสิ่งที่เป็นครึ่งหนึ่งของค่าใช้จ่าย

1148
00:49:54,640 --> 00:49:56,140
ดังนั้นนี่คือสิ่งที่จะคิดเกี่ยวกับ

1149
00:49:56,140 --> 00:50:00,160
เมื่อคุณกำลังอ่านออก DynamoDB และ
คุณกำลังตั้งค่าความจุอ่านของคุณ

1150
00:50:00,160 --> 00:50:04,430
หน่วยถ้าคุณเลือกในที่สุด
สอดคล้องอ่านก็มากราคาถูก,

1151
00:50:04,430 --> 00:50:06,010
มันเป็นเรื่องของครึ่งค่าใช้จ่าย

1152
00:50:06,010 --> 00:50:09,342
>> และดังนั้นจึงช่วยคุณประหยัดเงิน

1153
00:50:09,342 --> 00:50:10,300
แต่นั่นเป็นทางเลือกของคุณ

1154
00:50:10,300 --> 00:50:12,925
ถ้าคุณต้องการที่สอดคล้องอ่านหรือ
การอ่านที่สอดคล้องกันในที่สุด

1155
00:50:12,925 --> 00:50:15,720
นั่นคือสิ่งที่คุณสามารถเลือก

1156
00:50:15,720 --> 00:50:17,659
>> พูดคุยเกี่ยวกับการจัดทำดัชนี

1157
00:50:17,659 --> 00:50:19,450
ดังนั้นเราจึงบอกว่า
รวมระดับบนสุด

1158
00:50:19,450 --> 00:50:23,720
เรามีคีย์กัญชาและ
เรามีช่วงที่ปุ่ม

1159
00:50:23,720 --> 00:50:24,320
นั่นเป็นเรื่องดี

1160
00:50:24,320 --> 00:50:26,950
และที่อยู่ในตารางหลักที่ฉัน
ที่สำคัญมีกัญชาหนึ่งผมได้ที่สำคัญช่วงหนึ่ง

1161
00:50:26,950 --> 00:50:27,783
>> นั่นหมายความว่าอย่างไร?

1162
00:50:27,783 --> 00:50:30,410
ฉันมีหนึ่งแอตทริบิวต์ที่ฉัน
สามารถเรียกใช้คำสั่งที่อุดมไปด้วยกับ

1163
00:50:30,410 --> 00:50:31,800
มันเป็นช่วงที่สำคัญ

1164
00:50:31,800 --> 00:50:35,530
คุณลักษณะอื่น ๆ ใน item-- ว่า
ฉันสามารถกรองคุณลักษณะเหล่านั้น

1165
00:50:35,530 --> 00:50:40,050
แต่ฉันไม่สามารถทำสิ่งที่ต้องการมัน
เริ่มต้นด้วยการหรือมีค่ามากกว่า

1166
00:50:40,050 --> 00:50:40,820
>> ฉันจะทำอย่างไร

1167
00:50:40,820 --> 00:50:42,860
ฉันจะสร้างดัชนี

1168
00:50:42,860 --> 00:50:45,340
มีสองประเภทคือ
ดัชนีใน DynamoDB

1169
00:50:45,340 --> 00:50:49,002
ดัชนีเป็นจริง
มุมมองของตารางอีก

1170
00:50:49,002 --> 00:50:50,490
และดัชนีรองท้องถิ่น

1171
00:50:50,490 --> 00:50:51,781
>> คนแรกที่เราจะพูดคุยเกี่ยวกับ

1172
00:50:51,781 --> 00:50:57,740
ดังนั้น secondaries ท้องถิ่นพึ่ง
บนพาร์ติชันเดียวกับข้อมูล

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
แล้วคุณจะถูก จำกัด
ถึง 10 กิกะไบต์ใน LSIs ของคุณ

1212
00:52:53,860 --> 00:52:56,640
>> หากเป็นกรณีที่เราสามารถ
ใช้ secondaries ทั่วโลก

1213
00:52:56,640 --> 00:52:58,630
secondaries ทั่วโลก
จริงๆตารางอื่น

1214
00:52:58,630 --> 00:53:01,720
พวกเขามีอยู่อย่างสมบูรณ์ออกไป
ด้านของตารางหลักของคุณ

1215
00:53:01,720 --> 00:53:04,680
และพวกเขาให้ฉันไปหา
โครงสร้างที่แตกต่างกันอย่างสิ้นเชิง

1216
00:53:04,680 --> 00:53:08,010
ดังนั้นคิดว่ามันเป็นข้อมูลที่จะถูกแทรก
เป็นสองตารางที่แตกต่างโครงสร้าง

1217
00:53:08,010 --> 00:53:09,220
ในสองวิธีที่แตกต่างกัน

1218
00:53:09,220 --> 00:53:11,360
>> ฉันสามารถกำหนดทั้งหมด
กัญชาที่สำคัญที่แตกต่างกัน

1219
00:53:11,360 --> 00:53:13,490
ฉันสามารถกำหนดทั้งหมด
ที่สำคัญช่วงที่แตกต่างกัน

1220
00:53:13,490 --> 00:53:15,941
และผมสามารถทำงานนี้
เป็นอิสระอย่างสมบูรณ์

1221
00:53:15,941 --> 00:53:18,190
เป็นเรื่องของความเป็นจริงที่ฉันได้
การจัดเตรียมความสามารถในการอ่านของฉัน

1222
00:53:18,190 --> 00:53:21,090
และความสามารถในการเขียนของฉัน
ดัชนีรองทั่วโลก

1223
00:53:21,090 --> 00:53:24,240
เป็นอิสระอย่างสมบูรณ์
ของตารางหลักของฉัน

1224
00:53:24,240 --> 00:53:26,640
ถ้าผมกำหนดดัชนีที่ผมบอก
มันเท่าไหร่ที่อ่านและเขียน

1225
00:53:26,640 --> 00:53:28,610
กำลังการผลิตก็จะต้องใช้

1226
00:53:28,610 --> 00:53:31,490
>> และนั่นคือที่แยกต่างหาก
จากตารางหลักของฉัน

1227
00:53:31,490 --> 00:53:35,240
ตอนนี้ทั้งสองดัชนีช่วยให้เราสามารถ
ไม่เพียง แต่กำหนดคีย์กัญชาและช่วง

1228
00:53:35,240 --> 00:53:38,610
แต่พวกเขาช่วยให้เราสามารถ
ค่าเพิ่มเติมโครงการ

1229
00:53:38,610 --> 00:53:44,950
ดังนั้นถ้าผมต้องการที่จะอ่านออกดัชนี
และฉันต้องการที่จะได้รับชุดของข้อมูลบางส่วน

1230
00:53:44,950 --> 00:53:48,327
ฉันไม่ต้องการที่จะกลับไปหลัก
ตารางที่จะได้รับคุณลักษณะเพิ่มเติม

1231
00:53:48,327 --> 00:53:50,660
ฉันสามารถฉายภาพเหล่านั้นเพิ่มเติม
แอตทริบิวต์ลงในตาราง

1232
00:53:50,660 --> 00:53:53,440
เพื่อสนับสนุนรูปแบบการเข้าถึง

1233
00:53:53,440 --> 00:53:57,700
ฉันรู้ว่าเราอาจจะได้รับกำลังเป็นบางส่วน
จริงๆ really-- ได้รับเป็นวัชพืช

1234
00:53:57,700 --> 00:53:58,910
ที่นี่ในบางส่วนของสิ่งนี้

1235
00:53:58,910 --> 00:54:02,725
ตอนนี้ผมได้รับที่จะลอยออกจากนี้

1236
00:54:02,725 --> 00:54:07,320
>> ผู้ชม: [ไม่ได้ยิน]
ที่สำคัญ --table หมายเป็นกัญชาหรือไม่?

1237
00:54:07,320 --> 00:54:08,840
กัญชาเดิม?

1238
00:54:08,840 --> 00:54:09,340
แผ่นหลาย?

1239
00:54:09,340 --> 00:54:10,200
>> RICK Houlihan: ใช่

1240
00:54:10,200 --> 00:54:11,070
ใช่.

1241
00:54:11,070 --> 00:54:15,260
กุญแจสำคัญในตารางโดยทั่วไป
ชี้กลับไปที่รายการ

1242
00:54:15,260 --> 00:54:19,280
ดังนั้นดัชนีเป็นตัวชี้กลับไปที่
รายการที่เดิมบนโต๊ะ

1243
00:54:19,280 --> 00:54:22,910
ตอนนี้คุณสามารถเลือกที่จะสร้าง
ดัชนีที่สำคัญมีเพียงโต๊ะ

1244
00:54:22,910 --> 00:54:24,840
และไม่มีคุณสมบัติอื่น ๆ

1245
00:54:24,840 --> 00:54:26,570
และทำไมผมอาจจะทำเช่นนั้น?

1246
00:54:26,570 --> 00:54:28,570
ดีบางทีฉันอาจจะมีรายการที่มีขนาดใหญ่มาก

1247
00:54:28,570 --> 00:54:31,660
>> ผมจะต้องรู้ which--
รูปแบบการเข้าถึงของฉันอาจจะบอกว่า

1248
00:54:31,660 --> 00:54:33,760
รายการที่มีสถานที่ให้บริการนี​​้หรือไม่?

1249
00:54:33,760 --> 00:54:35,780
ไม่จำเป็นต้องกลับไปที่รายการ

1250
00:54:35,780 --> 00:54:37,800
ฉันเพียงแค่ต้องรู้
รายการที่มีมัน

1251
00:54:37,800 --> 00:54:40,700
เพื่อให้คุณสามารถสร้างดัชนี
ที่สำคัญมีเพียงโต๊ะ

1252
00:54:40,700 --> 00:54:43,360
>> แต่นั่นคือสิ่งที่เป็นหลัก
ดัชนีในฐานข้อมูลสำหรับ

1253
00:54:43,360 --> 00:54:46,280
มันสำหรับความสามารถในการได้อย่างรวดเร็ว
ระบุที่บันทึก,

1254
00:54:46,280 --> 00:54:49,470
แถวที่
รายการในตารางมี

1255
00:54:49,470 --> 00:54:51,080
คุณสมบัติที่ฉันค้นหา

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

1257
00:54:53,610 --> 00:54:54,860
>> จีซิสดังนั้นวิธีการที่พวกเขาทำงานอย่างไร

1258
00:54:54,860 --> 00:54:58,340
จีซิสพื้นไม่ตรงกัน

1259
00:54:58,340 --> 00:55:02,570
การปรับปรุงที่เข้ามาในตาราง
ตารางถ่ายทอดสดการปรับปรุงแล้ว

1260
00:55:02,570 --> 00:55:03,720
ทั้งหมดของจีซิสของคุณ

1261
00:55:03,720 --> 00:55:06,680
นี่คือเหตุผลที่จีซิสมี
ที่สอดคล้องกันในที่สุด

1262
00:55:06,680 --> 00:55:09,440
>> มันเป็นสิ่งสำคัญที่จะทราบว่า
เมื่อคุณกำลังสร้างจีซิส,

1263
00:55:09,440 --> 00:55:13,110
และคุณเข้าใจว่าคุณกำลังสร้าง
ขนาดของ aggregation-- อื่น

1264
00:55:13,110 --> 00:55:16,594
ตอนนี้ขอบอกว่าเป็นตัวอย่างที่ดี
ที่นี่เป็นผู้ผลิต

1265
00:55:16,594 --> 00:55:19,260
ผมคิดว่าผมอาจจะมีการพูดคุยเกี่ยวกับ
ผู้ผลิตอุปกรณ์ทางการแพทย์

1266
00:55:19,260 --> 00:55:23,870
ผลิตอุปกรณ์ทางการแพทย์
อาจเกิดการมีส่วนต่อเนื่อง

1267
00:55:23,870 --> 00:55:28,070
ส่วนที่เข้าไป
เปลี่ยนสะโพกทั้งหมด

1268
00:55:28,070 --> 00:55:30,200
มีหมายเลขเล็ก ๆ น้อย ๆ เกี่ยวกับพวกเขา

1269
00:55:30,200 --> 00:55:33,584
และพวกเขาจะมีล้านและ
ล้านและพันล้านส่วน

1270
00:55:33,584 --> 00:55:35,000
ในอุปกรณ์ทั้งหมดที่พวกเขาเรือ

1271
00:55:35,000 --> 00:55:37,440
ดีที่พวกเขาต้องการที่จะรวมอยู่ภายใต้
ขนาดที่แตกต่างกันทุกส่วน

1272
00:55:37,440 --> 00:55:39,520
ในการชุมนุมทั้งหมด
ชิ้นส่วนที่ทำ

1273
00:55:39,520 --> 00:55:41,670
บนเส้นบางทั้งหมด
ส่วนที่มา

1274
00:55:41,670 --> 00:55:44,620
จากผู้ผลิตบางอย่าง
ในวันที่กำหนด

1275
00:55:44,620 --> 00:55:47,940
และรวมตัวเหล่านี้บางครั้ง
ได้รับการขึ้นเป็นพันล้าน

1276
00:55:47,940 --> 00:55:50,550
>> ดังนั้นผมจึงทำงานร่วมกับบางส่วนของ
คนเหล่านี้ที่กำลังทุกข์ทรมาน

1277
00:55:50,550 --> 00:55:53,156
เพราะพวกเขากำลังสร้าง
เหล่านี้รวม ginormous

1278
00:55:53,156 --> 00:55:54,280
ดัชนีรองของพวกเขา

1279
00:55:54,280 --> 00:55:57,070
พวกเขาอาจจะมีส่วนดิบ
ตารางที่มาเป็นกัญชาเท่านั้น

1280
00:55:57,070 --> 00:55:59,090
ส่วนทุกคนมีหมายเลขที่ไม่ซ้ำ

1281
00:55:59,090 --> 00:56:00,975
ผมใช้หมายเลขเป็นกัญชา

1282
00:56:00,975 --> 00:56:01,600
มันสวย.

1283
00:56:01,600 --> 00:56:04,160
ตารางข้อมูลดิบของฉันคือการแพร่กระจาย
ทั่วทั้งพื้นที่ที่สำคัญ

1284
00:56:04,160 --> 00:56:05,930
ของฉัน [? เขียน ?]
[? การบริโภค?] เป็นที่น่ากลัว

1285
00:56:05,930 --> 00:56:07,876
ผมใช้ข้อมูลจำนวนมาก

1286
00:56:07,876 --> 00:56:09,500
แล้วสิ่งที่พวกเขาทำคือพวกเขาสร้าง GSI

1287
00:56:09,500 --> 00:56:12,666
และผมบอกว่าคุณรู้ว่าสิ่งที่ฉันต้องการที่จะเห็น
ทุกส่วนของผู้ผลิตนี้

1288
00:56:12,666 --> 00:56:15,060
ดีทั้งหมดในทันทีที่ฉัน
การพันล้านแถว

1289
00:56:15,060 --> 00:56:17,550
และสิ่งที่พวกเขาลง
โหนดหนึ่งเพราะเมื่อ

1290
00:56:17,550 --> 00:56:21,170
ผมรวมเป็น
ID เป็นผู้ผลิตกัญชา,

1291
00:56:21,170 --> 00:56:25,410
และเป็นส่วนหนึ่งจำนวนเป็นช่วง
แล้วทั้งหมดในทันทีฉัน

1292
00:56:25,410 --> 00:56:30,530
วางล้านชิ้นส่วนเป็นสิ่งที่
ผู้ผลิตนี้ได้ส่งมอบให้ฉัน

1293
00:56:30,530 --> 00:56:34,447
>> ที่สามารถทำให้เกิดเป็นจำนวนมาก
ของความดันใน GSI,

1294
00:56:34,447 --> 00:56:36,030
อีกครั้งเพราะฉันตอกหนึ่งโหนด

1295
00:56:36,030 --> 00:56:38,350
ฉันวางเหล่านี้ทั้งหมด
แทรกเป็นหนึ่งโหนด

1296
00:56:38,350 --> 00:56:40,940
และนั่นเป็นกรณีที่มีปัญหาการใช้งานจริง

1297
00:56:40,940 --> 00:56:43,479
ตอนนี้ผมได้รับการออกแบบที่ดี
รูปแบบสำหรับวิธีที่คุณหลีกเลี่ยงการที่

1298
00:56:43,479 --> 00:56:45,770
และนั่นคือหนึ่งในปัญหาที่เกิดขึ้น
ที่ผมเคยทำงานด้วย

1299
00:56:45,770 --> 00:56:49,590
แต่สิ่งที่เกิดขึ้นเป็น GSI อาจ
ได้มีความสามารถในการเขียนพอ

1300
00:56:49,590 --> 00:56:52,330
เพื่อให้สามารถที่จะผลักดันให้ทุกคน
แถวเป็นโหนดเดียว

1301
00:56:52,330 --> 00:56:55,390
และสิ่งที่เกิดขึ้นแล้วคือ
หลักตารางลูกค้า

1302
00:56:55,390 --> 00:57:00,180
ตารางหลักจะได้รับการผ่อนคันเร่ง
เพราะ GSI ไม่สามารถให้ทัน

1303
00:57:00,180 --> 00:57:02,980
ดังนั้นอัตราการแทรกของฉันจะ
ตกอยู่ในตารางหลัก

1304
00:57:02,980 --> 00:57:06,230
เป็น GSI ของฉันพยายามที่จะให้ทัน

1305
00:57:06,230 --> 00:57:08,850
>> สิทธิทั้งหมดเพื่อ GSI ของ LSI ของ
ที่หนึ่งที่ฉันควรใช้?

1306
00:57:08,850 --> 00:57:12,290
ของ LSI มีความสอดคล้องกัน

1307
00:57:12,290 --> 00:57:13,750
GSI ของมีความสอดคล้องกันในที่สุด

1308
00:57:13,750 --> 00:57:17,490
ถ้าที่ตกลงผมขอแนะนำให้ใช้
GSI ที่พวกเขากำลังมีความยืดหยุ่นมาก

1309
00:57:17,490 --> 00:57:20,270
LSI สามารถสร้างแบบจำลองเป็น GSI

1310
00:57:20,270 --> 00:57:27,040
และถ้าขนาดของข้อมูลต่อคีย์กัญชาใน
คอลเลกชันของคุณเกิน 10 กิกะไบต์

1311
00:57:27,040 --> 00:57:31,050
แล้วคุณจะต้องการที่จะใช้
GSI เพราะมันเป็นเพียงวงเงินยาก

1312
00:57:31,050 --> 00:57:32,035
>> ทั้งหมดขวาเพื่อปรับ

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

1314
00:57:35,210 --> 00:57:37,460
กำลังการผลิตไฟฟ้าใน DB คุณ
สามารถจัดหา [ไม่ได้ยิน]

1315
00:57:37,460 --> 00:57:38,680
ทางเข้าในตาราง

1316
00:57:38,680 --> 00:57:42,740
เรามีลูกค้าที่มี
เตรียม 60 billion--

1317
00:57:42,740 --> 00:57:45,970
กำลังทำ 60000000000 ร้องขออย่างสม่ำเสมอ
ทำงานที่กว่าล้านร้องขอ

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
และมีจริงๆสองลูกบิด

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
ตกลงดังนั้นถ้าคุณกำลังจะบอกว่าฉันต้องการ 1,000
RCU ของผู้ที่มีความสอดคล้องกันอย่างเคร่งครัด

1350
00:59:13,005 --> 00:59:14,130
ผู้ที่มีความสอดคล้องกันอ่าน

1351
00:59:14,130 --> 00:59:17,130
ถ้าคุณบอกว่าฉันต้องการ
ในที่สุดสอดคล้องอ่าน

1352
00:59:17,130 --> 00:59:19,402
คุณสามารถจัดหา 1000
RCU ของคุณจะ

1353
00:59:19,402 --> 00:59:21,840
ที่จะได้รับ 2000 ในที่สุด
สอดคล้องอ่าน

1354
00:59:21,840 --> 00:59:25,940
และครึ่งราคาสำหรับผู้ที่
ในที่สุดประกอบด้วยในการอ่าน

1355
00:59:25,940 --> 00:59:28,520
>> อีกครั้งปรับ
เป็นอิสระจากกัน

1356
00:59:28,520 --> 00:59:32,900
และพวกเขามี throughput--
ถ้าคุณกิน 100% ของ RCU ของคุณ

1357
00:59:32,900 --> 00:59:35,960
คุณจะไม่ส่งผลกระทบต่อ
ความพร้อมของสิทธิของคุณ

1358
00:59:35,960 --> 00:59:40,161
ดังนั้นพวกเขาจึงจะสมบูรณ์
เป็นอิสระจากกัน

1359
00:59:40,161 --> 00:59:43,160
สิ่งที่ถูกต้องดังนั้นหนึ่งในสิ่งที่
ที่ผมกล่าวถึงการควบคุมปริมาณได้ในเวลาสั้น ๆ

1360
00:59:43,160 --> 00:59:44,320
การควบคุมปริมาณไม่ดี

1361
00:59:44,320 --> 00:59:47,311
การควบคุมปริมาณบ่งชี้ที่ไม่ดีไม่มี SQL

1362
00:59:47,311 --> 00:59:50,310
มีสิ่งที่เราสามารถทำได้เพื่อช่วย
คุณบรรเทาการควบคุมปริมาณที่คุณ

1363
00:59:50,310 --> 00:59:51,040
กำลังประสบ

1364
00:59:51,040 --> 00:59:53,240
แต่ทางออกที่ดีที่สุด
นี้คือลอง

1365
00:59:53,240 --> 00:59:58,000
ดูในสิ่งที่คุณกำลังทำเพราะ
มีการป้องกันในรูปแบบการเล่นที่นี่

1366
00:59:58,000 --> 01:00:02,140
>> สิ่งเหล่านี้สิ่งที่ต้องการไม่เหมือนกัน
ปริมาณงาน, คีย์ร้อนพาร์ทิชันร้อน

1367
01:00:02,140 --> 01:00:06,210
ฉันตีพื้นที่ที่สำคัญโดยเฉพาะอย่างยิ่ง
ยากมากด้วยเหตุผลบางอย่างโดยเฉพาะอย่างยิ่ง

1368
01:00:06,210 --> 01:00:07,080
ฉันกำลังทำเช่นนี้ทำไม

1369
01:00:07,080 --> 01:00:08,710
ลองคิดออกว่า

1370
01:00:08,710 --> 01:00:10,427
ฉันผสมข้อมูลของฉันร้อนกับข้อมูลที่หนาวเย็น

1371
01:00:10,427 --> 01:00:12,510
ผมปล่อยให้โต๊ะของฉันได้รับ
มาก แต่มีจริงๆ

1372
01:00:12,510 --> 01:00:15,970
เฉพาะชุดย่อยของข้อมูลบางส่วน
ที่น่าสนใจจริงๆกับผม

1373
01:00:15,970 --> 01:00:20,290
ดังนั้นสำหรับข้อมูลเข้าสู่ระบบตัวอย่างเช่นจำนวนมาก
ลูกค้าที่พวกเขาได้รับข้อมูลเข้าสู่ระบบทุกวัน

1374
01:00:20,290 --> 01:00:22,490
พวกเขาได้เป็นจำนวนมากของข้อมูลเข้าสู่ระบบ

1375
01:00:22,490 --> 01:00:25,940
>> หากคุณเพียงแค่ทิ้งทุกสิ่งที่เข้าสู่ระบบ
ข้อมูลลงในตารางขนาดใหญ่เมื่อเวลาผ่านไป

1376
01:00:25,940 --> 01:00:28,070
ตารางที่จะได้รับใหญ่

1377
01:00:28,070 --> 01:00:30,950
แต่ฉันจริงๆสนใจเฉพาะใน
ที่ผ่านมา 24 ชั่วโมงเจ็ดวันที่ผ่านมา

1378
01:00:30,950 --> 01:00:31,659
30 วันที่ผ่าน

1379
01:00:31,659 --> 01:00:34,074
สิ่งที่หน้าต่างของเวลา
ที่ฉันสนใจในการมองหา

1380
01:00:34,074 --> 01:00:37,010
สำหรับเหตุการณ์ที่รบกวนจิตใจผมหรือ
กรณีที่น่าสนใจที่จะฉัน

1381
01:00:37,010 --> 01:00:39,540
ว่าถึงเวลาที่หน้าต่างเดียวที่ฉันต้องการ

1382
01:00:39,540 --> 01:00:42,470
ดังนั้นทำไมฉันวาง 10 ปี
มูลค่าของข้อมูลเข้าสู่ระบบในตารางหรือไม่

1383
01:00:42,470 --> 01:00:45,030
อะไรที่ทำให้เกิดเป็น
ตารางชิ้น

1384
01:00:45,030 --> 01:00:45,880
>> จะได้รับมาก

1385
01:00:45,880 --> 01:00:48,340
มันเริ่มแพร่กระจายออกไป
หลายพันโหนด

1386
01:00:48,340 --> 01:00:51,380
และเนื่องจากกำลังการผลิตของคุณ
อยู่ในระดับต่ำเพื่อให้คุณ

1387
01:00:51,380 --> 01:00:54,090
ประเมินจริง จำกัด ในแต่ละ
หนึ่งในผู้ที่แต่ละโหนด

1388
01:00:54,090 --> 01:00:57,120
เพื่อขอเริ่มต้นมองหาวิธีการ
เราไม่ม้วนตารางมากกว่า

1389
01:00:57,120 --> 01:01:01,502
เราจะจัดการให้ข้อมูลเล็ก ๆ น้อย ๆ ได้อย่างไร
ดีกว่าที่จะหลีกเลี่ยงปัญหาเหล​​่านี้

1390
01:01:01,502 --> 01:01:02,710
และสิ่งที่จะมีลักษณะอย่างไร

1391
01:01:02,710 --> 01:01:04,370
นี่คือสิ่งที่ดูเหมือนว่า

1392
01:01:04,370 --> 01:01:06,790
นี่คือสิ่งที่ไม่ดี NoSQL ดูเหมือนว่า

1393
01:01:06,790 --> 01:01:07,830
>> ผมได้รับที่สำคัญร้อนที่นี่

1394
01:01:07,830 --> 01:01:10,246
ถ้าคุณมองไปที่ด้านข้างที่นี่
เหล่านี้เป็นพาร์ทิชันทั้งหมดของฉัน

1395
01:01:10,246 --> 01:01:12,630
ผมได้ 16 พาร์ทิชันที่นี่
ในฐานข้อมูลนี้โดยเฉพาะ

1396
01:01:12,630 --> 01:01:13,630
เราทำเช่นนี้ตลอดเวลา

1397
01:01:13,630 --> 01:01:15,046
ผมทำงานนี้ให้กับลูกค้าตลอดเวลา

1398
01:01:15,046 --> 01:01:16,550
มันเรียกว่าแผนที่ความร้อน

1399
01:01:16,550 --> 01:01:20,590
แผนที่ความร้อนบอกฉันว่าคุณ
การเข้าถึงพื้นที่ที่สำคัญของคุณ

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-- ฉัน
ที่ใช้ในการทำงานที่ Mongo

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
เป็นจำนวนมากของค่าที่แตกต่างกัน
ระดับสูงของ cardinality

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
นี้เป็นมาก nicer

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 Houlihan: เสมอ

1457
01:03:51,450 --> 01:03:51,960
เสมอ.

1458
01:03:51,960 --> 01:03:54,620
ใช่ผมหมายถึงมีเสมอ
a-- และอีกครั้งมี

1459
01:03:54,620 --> 01:03:56,980
รูปแบบการออกแบบบางอย่างที่เราจะได้รับผ่าน
ที่จะพูดคุยเกี่ยวกับวิธีการที่คุณจัดการ

1460
01:03:56,980 --> 01:03:58,480
ที่มีขนาดใหญ่รวมสุดเหล่านี้

1461
01:03:58,480 --> 01:04:01,260
ฉันหมายความว่าฉันจะต้องมีพวกเขา
ทำอย่างไรเราจะจัดการกับพวกเขา?

1462
01:04:01,260 --> 01:04:03,760
ผมได้ใช้กรณีที่ดีงาม
ว่าเราจะพูดคุยเกี่ยวกับการที่

1463
01:04:03,760 --> 01:04:05,940
>> สิทธิทั้งหมดเพื่อให้การพูดคุยของ
ลูกค้าเกี่ยวกับบางส่วนในขณะนี้

1464
01:04:05,940 --> 01:04:06,950
พวกเหล่านี้เป็น AdRoll

1465
01:04:06,950 --> 01:04:08,990
ผมไม่ทราบว่าถ้าคุณอยู่
คุ้นเคยกับ AdRoll

1466
01:04:08,990 --> 01:04:10,781
คุณอาจจะเห็นพวกเขา
มากในเบราว์เซอร์

1467
01:04:10,781 --> 01:04:14,230
พวกเขากำลังกำหนดเป้​​าหมายใหม่โฆษณาที่พวกเขากำลัง
โฆษณาธุรกิจใหม่การกำหนดเป้​​าหมายที่ใหญ่ที่สุด

1468
01:04:14,230 --> 01:04:14,940
ข้างนอกนั้น.

1469
01:04:14,940 --> 01:04:17,792
พวกเขามักเป็นประจำทำงานมากกว่า
60000000000 รายการต่อวัน

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
พวกเขาสามารถที่จะทำของพวกเขาทั้งหมด
การค้นหา, triage ทั้งหมดที่มีข้อมูล

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
ที่คุณจะได้รับในไดนาโมฐานข้อมูลมีขนาดใหญ่มาก

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 สามวัตถุ

1523
01:06:44,070 --> 01:06:47,070
เมื่อพวกเขาต้องมองไปที่วิดีโอ
พวกเขามองขึ้นเป็นประวัติการณ์ในไดนาโมดีบี

1524
01:06:47,070 --> 01:06:47,903
พวกเขาคลิกที่ลิงค์

1525
01:06:47,903 --> 01:06:49,770
พวกเขาดึงวิดีโอจาก 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
จากห้าถึง 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
ที่วิ่งทั้งหมดในฐานข้อมูลไดนาโม

1538
01:07:22,590 --> 01:07:26,810
และคนเหล่านี้พวกเขาจะดี
ทีมพัฒนา, การพัฒนาที่ดี

1539
01:07:26,810 --> 01:07:27,670
ร้านขายของ

1540
01:07:27,670 --> 01:07:29,364
>> ไม่ได้เป็นทีมงานมือดี

1541
01:07:29,364 --> 01:07:31,280
พวกเขาไม่ได้มีจำนวนมาก
ทรัพยากรการดำเนินงาน

1542
01:07:31,280 --> 01:07:33,940
พวกเขากำลังพยายามที่จะให้
โครงสร้างพื้นฐานของแอพลิเคชันของพวกเขาขึ้น

1543
01:07:33,940 --> 01:07:34,290
และทำงาน

1544
01:07:34,290 --> 01:07:35,000
พวกเขามาให้เรา

1545
01:07:35,000 --> 01:07:36,251
พวกเขามองที่ว่าไดนาโม DB

1546
01:07:36,251 --> 01:07:37,291
พวกเขากล่าวว่าสำหรับเรา

1547
01:07:37,291 --> 01:07:39,470
พวกเขาสร้างของพวกเขาทั้ง
กรอบใบสมัครกับมัน

1548
01:07:39,470 --> 01:07:43,640
บางความคิดเห็นที่ดีจริงๆที่นี่
จากทีมงานเกี่ยวกับความสามารถของพวกเขา

1549
01:07:43,640 --> 01:07:46,800
ตอนนี้มุ่งเน้นการสร้าง
เกมและไม่

1550
01:07:46,800 --> 01:07:49,010
ไม่ต้องรักษา
โครงสร้างพื้นฐานที่

1551
01:07:49,010 --> 01:07:51,910
ได้กลายเป็นจำนวนมหาศาล
ค่าใช้จ่ายสำหรับทีมของพวกเขา

1552
01:07:51,910 --> 01:07:56,170
ดังนั้นนี่คือสิ่งที่ that--
ประโยชน์ที่คุณได้รับจากเครื่องปั่นไฟ DB

1553
01:07:56,170 --> 01:08:00,930
>> สิทธิทั้งหมดที่ได้รับใน
การสร้างแบบจำลองข้อมูลที่นี่

1554
01:08:00,930 --> 01:08:03,440
และเราได้พูดคุยเพียงเล็กน้อยเกี่ยวกับ
หนึ่งในนี้หนึ่งหนึ่งไปยังหลาย ๆ

1555
01:08:03,440 --> 01:08:05,060
และอีกหลายความสัมพันธ์หลายชนิด

1556
01:08:05,060 --> 01:08:07,630
และวิธีการที่คุณรักษาผู้ที่อยู่ในไดนาโม

1557
01:08:07,630 --> 01:08:10,500
ไดนาโมในฐานข้อมูลที่เราใช้
ดัชนีทั่วไปพูด

1558
01:08:10,500 --> 01:08:12,910
เพื่อหมุนข้อมูลจาก
หนึ่งรสชาติที่อื่น ๆ

1559
01:08:12,910 --> 01:08:15,210
แฮปุ่มคีย์ช่วงและดัชนี

1560
01:08:15,210 --> 01:08:18,540
>> โดยเฉพาะอย่างยิ่งนี้
ตัวอย่างเช่นรัฐส่วนใหญ่

1561
01:08:18,540 --> 01:08:23,802
มีความต้องการการออกใบอนุญาตที่
เพียงหนึ่งใบอนุญาตขับรถต่อคน

1562
01:08:23,802 --> 01:08:26,510
คุณไม่สามารถไปจะได้รับสองขับรถ
ใบอนุญาตในรัฐบอสตัน

1563
01:08:26,510 --> 01:08:27,500
ฉันไม่สามารถทำมันในเท็กซัส

1564
01:08:27,500 --> 01:08:28,708
นั่นคือชนิดของวิธีที่มันเป็น

1565
01:08:28,708 --> 01:08:32,779
และเพื่อที่ 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
รูปแบบที่เป็นที่หนึ่ง
ให้เป็นหนึ่งในความสัมพันธ์

1578
01:09:08,689 --> 01:09:12,460
เพียงง่ายมาก GSI,
พลิกสิ่งที่คนรอบข้าง

1579
01:09:12,460 --> 01:09:13,979
ตอนนี้พูดคุยเกี่ยวกับอย่างใดอย่างหนึ่งที่หลาย ๆ

1580
01:09:13,979 --> 01:09:16,450
หนึ่งไปยังหลายเป็นพื้น
ช่วงที่สำคัญของกัญชา

1581
01:09:16,450 --> 01:09:20,510
ที่เราได้รับเป็นจำนวนมากกับเรื่องนี้
กรณีใช้ข้อมูลการตรวจสอบ

1582
01:09:20,510 --> 01:09:23,880
การตรวจสอบข้อมูลที่มาในปกติ
ช่วงเวลาเช่นอิน​​เทอร์เน็ตของสิ่งที่

1583
01:09:23,880 --> 01:09:26,890
เรามักจะได้รับทั้งหมดเหล่านี้
บันทึกเข้ามาตลอดเวลา

1584
01:09:26,890 --> 01:09:31,420
>> และผมต้องการที่จะหาอ่านทั้งหมด
ระหว่างช่วงเวลาหนึ่ง

1585
01:09:31,420 --> 01:09:34,220
มันเป็นแบบสอบถามที่พบบ่อยมากใน
โครงสร้างพื้นฐานการตรวจสอบ

1586
01:09:34,220 --> 01:09:38,430
วิธีการเกี่ยวกับที่ไปคือการหา
โครงสร้างตารางที่เรียบง่ายตารางหนึ่ง

1587
01:09:38,430 --> 01:09:42,250
ฉันมีอุปกรณ์ตารางการวัด
ด้วยคีย์กัญชาใน ID ของอุปกรณ์

1588
01:09:42,250 --> 01:09:47,340
และฉันมีความสำคัญในช่วงที่
การประทับเวลาหรือในกรณีนี้มหากาพย์

1589
01:09:47,340 --> 01:09:50,350
และที่ช่วยให้ผมดำเนินการที่ซับซ้อน
สอบถามกับกุญแจสำคัญในช่วงนั้น

1590
01:09:50,350 --> 01:09:54,950
และกลับระเบียนที่
เป็นญาติกับผลที่ตามมา

1591
01:09:54,950 --> 01:09:56,310
ชุดที่ฉันกำลังมองหา

1592
01:09:56,310 --> 01:09:58,360
และมันก็สร้างที่หนึ่ง
เพื่อความสัมพันธ์มาก

1593
01:09:58,360 --> 01:10:02,340
ลงในตารางหลักโดยใช้
ที่สำคัญกัญชาช่วงโครงสร้างที่สำคัญ

1594
01:10:02,340 --> 01:10:04,600
>> ดังนั้นชนิดที่สร้างขึ้นจาก
ลงในตารางในไดนาโมดีบี

1595
01:10:04,600 --> 01:10:07,290
เมื่อฉันกำหนดกัญชา
และโต๊ะทีช่วงผม

1596
01:10:07,290 --> 01:10:09,240
การกำหนดความสัมพันธ์ที่หนึ่งไปยังหลาย ๆ

1597
01:10:09,240 --> 01:10:12,770
มันเป็นความสัมพันธ์พ่อแม่และลูก

1598
01:10:12,770 --> 01:10:14,620
>> พูดคุยเกี่ยวกับหลาย ๆ
ความสัมพันธ์หลาย

1599
01:10:14,620 --> 01:10:19,170
และสำหรับตัวอย่างนี้โดยเฉพาะอย่างยิ่ง
อีกครั้งที่เรากำลังจะใช้ GSI ของ

1600
01:10:19,170 --> 01:10:23,500
และขอพูดคุยเกี่ยวกับการเล่นเกม
สถานการณ์ที่ฉันมีผู้ใช้ที่กำหนด

1601
01:10:23,500 --> 01:10:26,500
ฉันต้องการที่จะหาเกมทั้งหมดที่
เขาหรือลงทะเบียนสำหรับการเล่นใน

1602
01:10:26,500 --> 01:10:29,600
และสำหรับเกมรับผม
ต้องการที่จะหาผู้ใช้ทั้งหมด

1603
01:10:29,600 --> 01:10:31,010
ดังนั้นฉันจะทำเช่นนั้น?

1604
01:10:31,010 --> 01:10:34,330
ตารางเกมผู้ใช้ของฉันฉันจะ
ที่จะมีความสำคัญกัญชาของ ID ผู้ใช้

1605
01:10:34,330 --> 01:10:35,810
และที่สำคัญช่วงของเกม

1606
01:10:35,810 --> 01:10:37,810
>> ดังนั้นผู้ใช้สามารถมีหลายเกม

1607
01:10:37,810 --> 01:10:41,380
มันเป็นหนึ่งในความสัมพันธ์มากระหว่าง
ผู้ใช้และเกมที่เขาเล่น

1608
01:10:41,380 --> 01:10:43,410
และจากนั้นใน GSI,
ฉันจะพลิกว่าประมาณ

1609
01:10:43,410 --> 01:10:46,679
ฉันจะสับกับเกมและ
ฉันจะช่วงกับผู้ใช้

1610
01:10:46,679 --> 01:10:48,970
ดังนั้นถ้าผมต้องการที่จะได้รับทั้งหมด
เกมของผู้ใช้เล่นใน

1611
01:10:48,970 --> 01:10:49,950
ฉันจะสอบถามตารางหลัก

1612
01:10:49,950 --> 01:10:52,699
ถ้าผมต้องการที่จะได้รับผู้ใช้ทั้งหมด
ที่มีการเล่นเกมโดยเฉพาะอย่างยิ่ง

1613
01:10:52,699 --> 01:10:53,887
ผมสอบถาม GSI

1614
01:10:53,887 --> 01:10:54,970
ดังนั้นคุณจะเห็นวิธีการที่เราทำเช่นนี้?

1615
01:10:54,970 --> 01:10:58,369
คุณสร้าง GSI เหล่านี้ให้การสนับสนุน
กรณีที่ใช้แอพลิเคชันการเข้าถึง

1616
01:10:58,369 --> 01:10:59,410
รูปแบบแอพลิเคชัน

1617
01:10:59,410 --> 01:11:01,440
>> หากฉันต้องการที่จะสอบถามเกี่ยวกับ
มิตินี้ให้

1618
01:11:01,440 --> 01:11:03,500
ฉันสร้างดัชนีในมิติที่ว่า

1619
01:11:03,500 --> 01:11:05,850
ถ้าฉันไม่ได้ฉันไม่สนใจ

1620
01:11:05,850 --> 01:11:09,060
และขึ้นอยู่กับกรณีที่ใช้ผม
อาจต้องดัชนีหรือผมอาจจะไม่

1621
01:11:09,060 --> 01:11:12,390
ถ้ามันเป็นเรื่องง่ายที่จะเป็นหนึ่งในหลาย ๆ
ตารางหลักเป็นเรื่องปกติ

1622
01:11:12,390 --> 01:11:15,860
ถ้าผมต้องทำเหล่านี้จำนวนมากที่จะ
ของจำนวนมากหรือที่ฉันต้องทำอย่างใดอย่างหนึ่งเพื่อให้คนที่

1623
01:11:15,860 --> 01:11:18,390
แล้วบางทีฉันอาจจะต้อง
ที่สองดัชนี

1624
01:11:18,390 --> 01:11:20,840
ดังนั้นจึงขึ้นอยู่กับ
สิ่งที่ฉันพยายามที่จะทำ

1625
01:11:20,840 --> 01:11:24,550
และสิ่งที่ฉันพยายามที่จะประสบความสำเร็จ

1626
01:11:24,550 --> 01:11:28,000
>> น่าจะเป็นผมไม่ได้จะใช้จ่ายมากเกินไป
เวลามากพูดคุยเกี่ยวกับเอกสาร

1627
01:11:28,000 --> 01:11:31,460
นี้ได้รับนิด ๆ หน่อย ๆ อาจจะ
ลึกกว่าที่เราต้องไปเป็น

1628
01:11:31,460 --> 01:11:33,710
พูดคุยนิด ๆ หน่อย ๆ
นิพจน์แบบสอบถามเกี่ยวกับที่อุดมไปด้วย

1629
01:11:33,710 --> 01:11:37,831
ดังนั้นในไดนาโมฐานข้อมูลที่เรามี
ความสามารถในการสร้าง

1630
01:11:37,831 --> 01:11:39,330
สิ่งที่เราเรียกการแสดงออกฉาย

1631
01:11:39,330 --> 01:11:42,660
การแสดงออกเป็นเพียงการประมาณการ
เลือกสาขาหรือค่าที่

1632
01:11:42,660 --> 01:11:44,290
ที่คุณต้องการแสดง

1633
01:11:44,290 --> 01:11:46,000
ตกลงดังนั้นฉันจะทำให้การเลือก

1634
01:11:46,000 --> 01:11:48,010
ผมทำแบบสอบถามกับไดนาโม DB

1635
01:11:48,010 --> 01:11:51,730
และผมบอกว่าคุณรู้ว่าสิ่งที่แสดง
ฉันเพียงห้าดาวคิดเห็น

1636
01:11:51,730 --> 01:11:54,544
สำหรับสินค้านี้โดยเฉพาะอย่างยิ่ง

1637
01:11:54,544 --> 01:11:55,710
นั่นคือทั้งหมดที่ฉันต้องการที่จะเห็น

1638
01:11:55,710 --> 01:11:57,320
ฉันไม่ต้องการที่จะเห็นทั้งหมด
คุณลักษณะอื่น ๆ ของแถว

1639
01:11:57,320 --> 01:11:58,319
ผมแค่อยากจะเห็นนี้

1640
01:11:58,319 --> 01:12:01,209
ก็เช่นเดียวกับใน SQL เมื่อคุณ
บอกว่าดาวหรือเลือกจากตาราง

1641
01:12:01,209 --> 01:12:02,000
คุณจะได้รับทุกอย่าง

1642
01:12:02,000 --> 01:12:05,450
เมื่อฉันพูดว่าเลือกชื่อจาก
ตารางที่ผมจะได้รับหนึ่งแอตทริบิวต์

1643
01:12:05,450 --> 01:12:09,070
มันเป็นชนิดเดียวกันของสิ่งที่อยู่ใน
ไดนาโม DB หรืออีกฐานข้อมูล NoSQL

1644
01:12:09,070 --> 01:12:14,510
การแสดงออกกรองให้ฉันไป
พื้นตัดผลการตั้งค่าลง

1645
01:12:14,510 --> 01:12:15,540
ดังนั้นผมจึงทำแบบสอบถาม

1646
01:12:15,540 --> 01:12:17,260
แบบสอบถามอาจกลับมาพร้อมกับ 500 รายการ

1647
01:12:17,260 --> 01:12:20,255
แต่ผมเพียงต้องการรายการที่
มีคุณลักษณะที่ว่านี้

1648
01:12:20,255 --> 01:12:23,380
ตกลงจึงขอกรองรายการเหล่านั้น
ที่ไม่ตรงกับที่แบบสอบถามโดยเฉพาะอย่างยิ่ง

1649
01:12:23,380 --> 01:12:25,540
ดังนั้นเราจึงมีการแสดงออกกรอง

1650
01:12:25,540 --> 01:12:28,310
>> การแสดงออกที่สามารถกรอง
จะทำงานในแอตทริบิวต์ใด ๆ

1651
01:12:28,310 --> 01:12:30,260
พวกเขาไม่ชอบคำสั่งช่วง

1652
01:12:30,260 --> 01:12:32,690
คำสั่งยกมีเลือกมากขึ้น

1653
01:12:32,690 --> 01:12:36,470
คำสั่งกรองต้องให้ฉันไป
ได้รับผลการทั้งหมดที่ตั้งไว้แล้ว

1654
01:12:36,470 --> 01:12:39,170
แกะสลักออกข้อมูลที่ฉันไม่ต้องการ

1655
01:12:39,170 --> 01:12:40,660
นั่นคือเหตุผลที่สำคัญหรือไม่

1656
01:12:40,660 --> 01:12:42,770
เพราะผมอ่านมันทั้งหมด

1657
01:12:42,770 --> 01:12:46,597
ในแบบสอบถามที่ฉันจะอ่านและ
มันจะเป็นยักษ์ใหญ่เกี่ยวกับข้อมูลที่

1658
01:12:46,597 --> 01:12:48,430
แล้วฉันกำลังจะไป
แกะสลักออกสิ่งที่ฉันต้องการ

1659
01:12:48,430 --> 01:12:52,080
และถ้าฉันก็แค่แกะสลักออก
คู่ของแถวนั้นที่ตกลง

1660
01:12:52,080 --> 01:12:53,620
มันไม่ได้ไม่มีประสิทธิภาพดังนั้น

1661
01:12:53,620 --> 01:12:57,800
>> แต่ถ้าฉันอ่านกองทั้ง
ข้อมูลเพียงที่จะตัดออกหนึ่งรายการ

1662
01:12:57,800 --> 01:13:01,490
แล้วฉันจะไปจะดีกว่า
ออกโดยใช้แบบสอบถามช่วง

1663
01:13:01,490 --> 01:13:03,030
เพราะมันมากเลือกมากขึ้น

1664
01:13:03,030 --> 01:13:06,330
มันจะช่วยฉันมาก
เงินเพราะฉันต้องจ่ายเงินสำหรับการอ่านที่

1665
01:13:06,330 --> 01:13:10,430
ที่ไหนผลลัพธ์ที่กลับมา
ข้ามสายที่อาจจะมีขนาดเล็กลง

1666
01:13:10,430 --> 01:13:11,890
แต่ฉันจ่ายเงินสำหรับการอ่าน

1667
01:13:11,890 --> 01:13:14,340
ดังนั้นเข้าใจว่า
คุณจะได้รับข้อมูล

1668
01:13:14,340 --> 01:13:16,420
นั่นเป็นสิ่งที่สำคัญมากในไดนาโม DB

1669
01:13:16,420 --> 01:13:19,710
>> การแสดงออกตามเงื่อนไขนี้เป็นสิ่งที่
ที่คุณอาจเรียกล็อคในแง่ดี

1670
01:13:19,710 --> 01:13:28,470
ปรับปรุง IF EXISTS หรือถ้าค่านี้
เทียบเท่ากับสิ่งที่ฉันระบุ

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
>> [interposing VOICES]

1689
01:14:14,316 --> 01:14:16,232
RICK Houlihan: ฉันจะไม่
ได้รับมากเกินไปในนี้

1690
01:14:16,232 --> 01:14:17,700
นี้เป็นคำหลักที่สงวนไว้

1691
01:14:17,700 --> 01:14:20,130
มุมมองปอนด์เป็นลิขสิทธิ์
คำหลักในไดนาโม DB

1692
01:14:20,130 --> 01:14:24,500
ทุกคนมีฐานข้อมูลของตัวเองลิขสิทธิ์
ชื่อคอลเลกชันคุณไม่สามารถใช้

1693
01:14:24,500 --> 01:14:27,240
ไดนาโม DB ถ้าคุณระบุ
ปอนด์อยู่หน้านี้

1694
01:14:27,240 --> 01:14:29,310
คุณสามารถกำหนดชื่อเหล่านั้นขึ้นไปข้างบน

1695
01:14:29,310 --> 01:14:31,840
นี้เป็นค่าอ้างอิง

1696
01:14:31,840 --> 01:14:34,880
มันอาจจะไม่ได้เป็นไวยากรณ์ที่ดีที่สุดเพื่อ
มีขึ้นมีการอภิปรายนี้

1697
01:14:34,880 --> 01:14:38,090
เพราะมันได้รับในบาง real--
ฉันจะได้รับการพูดถึงมากขึ้น

1698
01:14:38,090 --> 01:14:41,360
เกี่ยวกับที่อยู่ในระดับลึก

1699
01:14:41,360 --> 01:14:46,130
>> แต่พอที่จะกล่าวนี้สามารถทำได้
เป็นแบบสอบถามสแกนที่พวกเขา views--

1700
01:14:46,130 --> 01:14:50,190
หรือมุมมองปอนด์มีค่ามากกว่า 10

1701
01:14:50,190 --> 01:14:54,660
มันเป็นค่าตัวเลขที่ใช่

1702
01:14:54,660 --> 01:14:57,322
ถ้าคุณต้องการที่เราสามารถพูดคุยเกี่ยวกับ
ว่าหลังจากการอภิปราย

1703
01:14:57,322 --> 01:15:00,030
สิทธิทั้งหมดเพื่อให้เราได้รับใน
สถานการณ์บางอย่างในการปฏิบัติที่ดีที่สุด

1704
01:15:00,030 --> 01:15:02,000
ที่เรากำลังจะพูดคุย
เกี่ยวกับปพลิเคชันบางอย่างที่นี่

1705
01:15:02,000 --> 01:15:03,810
อะไรคือกรณีการใช้งานสำหรับไดนาโม DB

1706
01:15:03,810 --> 01:15:06,120
อะไรคือการออกแบบ
ในรูปแบบฐานข้อมูลไดนาโม

1707
01:15:06,120 --> 01:15:09,110
>> และเป็นคนแรกที่เรากำลังจะไป
พูดคุยเกี่ยวกับอินเทอร์เน็ตในสิ่งที่

1708
01:15:09,110 --> 01:15:15,010
ดังนั้นเราจึงได้รับมาก of-- ฉันเดา
สิ่งที่เป็น it-- มากกว่า 50%

1709
01:15:15,010 --> 01:15:19,370
ของการจราจรบนอินเทอร์เน็ตวันนี้
ถูกสร้างขึ้นจริงโดยเครื่อง

1710
01:15:19,370 --> 01:15:21,930
กระบวนการอัตโนมัติได้โดยมนุษย์

1711
01:15:21,930 --> 01:15:25,140
ผมหมายถึงสิ่งนี้สิ่งนี้ว่า
คุณพกพาในกระเป๋าของคุณ

1712
01:15:25,140 --> 01:15:28,840
เท่าใดข้อมูลว่าสิ่งที่เป็น
จริงส่งไปรอบ ๆ โดยที่คุณไม่

1713
01:15:28,840 --> 01:15:30,550
รู้ว่ามันเป็นที่น่าตื่นตาตื่นใจอย่างแน่นอน

1714
01:15:30,550 --> 01:15:34,970
สถานที่ของคุณข้อมูล
เกี่ยวกับวิธีการที่รวดเร็วที่คุณกำลังจะ

1715
01:15:34,970 --> 01:15:38,400
วิธีที่คุณคิดว่างานของ Google Maps
เมื่อพวกเขาบอกคุณว่าการจราจร

1716
01:15:38,400 --> 01:15:41,275
ก็เพราะมีคนนับล้านและ
ผู้คนนับล้านขับรถรอบ

1717
01:15:41,275 --> 01:15:44,667
กับโทรศัพท์ที่มีการส่ง
ข้อมูลทั่วทุกสถานที่ทุกเวลา

1718
01:15:44,667 --> 01:15:46,500
ดังนั้นหนึ่งในสิ่งที่
เกี่ยวกับประเภทของข้อมูลนี้

1719
01:15:46,500 --> 01:15:50,980
ที่มาในการตรวจสอบข้อมูลเข้าสู่ระบบ
ข้อมูลข้อมูลอนุกรมเวลามันเป็นเรื่อง

1720
01:15:50,980 --> 01:15:53,540
มักจะมีเพียงที่น่าสนใจ
นิด ๆ หน่อย ๆ ของเวลา

1721
01:15:53,540 --> 01:15:55,580
หลังจากนั้นก็
จึงไม่น่าสนใจ

1722
01:15:55,580 --> 01:15:58,390
ดังนั้นเราได้พูดคุยเกี่ยวกับการไม่ให้
ตารางเหล่านั้นเติบโตโดยไม่มีขอบเขต

1723
01:15:58,390 --> 01:16:03,410
ความคิดที่นี่คือว่าบางทีฉันมี 24
ชั่วโมงมูลค่าของเหตุการณ์ในตารางของฉันร้อน

1724
01:16:03,410 --> 01:16:06,160
และตารางร้อนเป็นไปได้
การจัดเตรียมในอัตราที่สูงมาก

1725
01:16:06,160 --> 01:16:07,950
เพราะมันก็นำข้อมูลจำนวนมาก

1726
01:16:07,950 --> 01:16:10,920
มันก็นำข้อมูลจำนวนมาก
และฉันอ่านมันมาก

1727
01:16:10,920 --> 01:16:14,560
ฉันมีจำนวนมากของการดำเนินงาน
คำสั่งทำงานกับข้อมูลที่ว่า

1728
01:16:14,560 --> 01:16:18,120
>> หลังจาก 24 ชั่วโมงเดี๋ยวก่อนคุณ
รู้ว่าสิ่งที่ฉันไม่สนใจ

1729
01:16:18,120 --> 01:16:21,150
ดังนั้นบางทีทุกเที่ยงคืนผมม้วน
โต๊ะของเราไปยังตารางใหม่

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 ของ
ทั้งหมดทางลงไปหนึ่ง

1736
01:16:35,020 --> 01:16:36,990
เพราะคุณรู้ว่าสิ่งที่มันเป็น
ไม่เคยจะได้รับการเขียนไปยัง

1737
01:16:36,990 --> 01:16:38,300
ข้อมูลที่อายุ 30 วัน

1738
01:16:38,300 --> 01:16:40,000
มันไม่เคยเปลี่ยนแปลง

1739
01:16:40,000 --> 01:16:44,200
>> และก็เกือบจะไม่เคยไปได้อ่าน
เพื่อให้เพียงใช้เวลาที่ RCU ลงไป 10

1740
01:16:44,200 --> 01:16:49,372
และฉันประหยัดตันเงินเกี่ยวกับเรื่องนี้
ข้อมูลและมีเพียงการจ่ายเงินสำหรับข้อมูลของฉันร้อน

1741
01:16:49,372 --> 01:16:52,330
นั่นคือสิ่งที่สำคัญที่จะมอง
ที่เมื่อคุณมองไปที่ชุดเวลา

1742
01:16:52,330 --> 01:16:54,716
ข้อมูลที่มาในปริมาณ

1743
01:16:54,716 --> 01:16:55,590
เหล่านี้เป็นกลยุทธ์

1744
01:16:55,590 --> 01:16:58,010
ตอนนี้ผมก็สามารถปล่อยให้มัน
ทั้งหมดไปที่โต๊ะเดียวกัน

1745
01:16:58,010 --> 01:16:59,461
และเพียงแค่ให้ตารางที่เติบโต

1746
01:16:59,461 --> 01:17:01,460
ในที่สุดฉันจะ
เห็นปัญหาประสิทธิภาพการทำงาน

1747
01:17:01,460 --> 01:17:04,060
ฉันจะต้องเริ่มต้นในการเก็บ
ข้อมูลบางส่วนออกจากตารางที่

1748
01:17:04,060 --> 01:17:04,720
สิ่งที่ไม่

1749
01:17:04,720 --> 01:17:07,010
>> ลองดีมาก
การออกแบบโปรแกรมประยุกต์ของคุณ

1750
01:17:07,010 --> 01:17:08,900
เพื่อให้คุณสามารถทำงานได้ด้วยวิธีนี้ได้

1751
01:17:08,900 --> 01:17:11,460
ดังนั้นจึงเป็นโดยอัตโนมัติเพียง
ในรหัสโปรแกรม

1752
01:17:11,460 --> 01:17:13,580
ตอนเที่ยงคืนทุกคืน
มันม้วนตาราง

1753
01:17:13,580 --> 01:17:17,170
บางทีสิ่งที่ฉันต้องเป็นบานเลื่อน
หน้าต่าง 24 ชั่วโมงของข้อมูล

1754
01:17:17,170 --> 01:17:20,277
จากนั้นเป็นประจำฉัน
เรียกข้อมูลออกจากตาราง

1755
01:17:20,277 --> 01:17:22,360
การตัดแต่งผมด้วย
งาน cron และฉันวางไว้

1756
01:17:22,360 --> 01:17:24,160
บนตารางอื่น ๆ เหล่านี้
สิ่งที่คุณต้องการ

1757
01:17:24,160 --> 01:17:25,940
ดังนั้นถ้าทำงานแบบโรลโอเวอร์ที่ดี

1758
01:17:25,940 --> 01:17:27,080
ถ้าไม่ตัดมัน

1759
01:17:27,080 --> 01:17:29,640
แต่ขอให้ข้อมูลที่ร้อน
ห่างจากข้อมูลของคุณเย็น

1760
01:17:29,640 --> 01:17:32,535
มันจะช่วยให้คุณประหยัดเงินจำนวนมากและ
ทำให้ตารางของคุณมีประสิทธิภาพมากขึ้น

1761
01:17:32,535 --> 01:17:35,960

1762
01:17:35,960 --> 01:17:38,210
ดังนั้นสิ่งต่อไปที่เราจะพูดคุย
เกี่ยวกับการเป็นแคตตาล็อกสินค้า

1763
01:17:38,210 --> 01:17:42,000
แคตตาล็อกสินค้า
กรณีที่ใช้ร่วมกันสวย

1764
01:17:42,000 --> 01:17:46,600
นี้เป็นจริงรูปแบบที่พบบ่อยมาก
ว่าเราจะเห็นในความหลากหลายของสิ่ง

1765
01:17:46,600 --> 01:17:48,870
คุณจะรู้ว่าทวิตเตอร์สำหรับ
ตัวอย่างเช่นการทวีตร้อน

1766
01:17:48,870 --> 01:17:51,280
ทุกคนที่มาและ
โลภทวีตว่า

1767
01:17:51,280 --> 01:17:52,680
แคตตาล็อกสินค้าผมได้ขาย

1768
01:17:52,680 --> 01:17:54,120
ผมได้ขายร้อน

1769
01:17:54,120 --> 01:17:57,277
ผมได้ 70,000 หน้าต่อ
สองมาสำหรับผลิตภัณฑ์

1770
01:17:57,277 --> 01:17:58,860
คำอธิบายออกมาจากแคตตาล็อกสินค้าของฉัน

1771
01:17:58,860 --> 01:18:02,384
เราเห็นนี้ในการค้าปลีก
การดำเนินการไม่น้อย

1772
01:18:02,384 --> 01:18:03,550
ดังนั้นวิธีที่เราจัดการกับที่?

1773
01:18:03,550 --> 01:18:04,924
ไม่มีทางที่จะจัดการกับที่ไม่ได้

1774
01:18:04,924 --> 01:18:07,110
ผู้ใช้ทุกคนของฉันต้องการที่จะเห็น
ชิ้นเดียวกันของข้อมูล

1775
01:18:07,110 --> 01:18:09,410
พวกเขากำลังจะเข้ามาพร้อมกัน

1776
01:18:09,410 --> 01:18:11,920
และพวกเขากำลังทั้งหมดทำให้การร้องขอ
สำหรับชิ้นเดียวกันของข้อมูล

1777
01:18:11,920 --> 01:18:16,240
นี้จะช่วยให้ผมว่าที่สำคัญร้อนที่สีแดงขนาดใหญ่
แถบบนแผนที่ของฉันที่เราไม่ชอบ

1778
01:18:16,240 --> 01:18:17,720
และนั่นคือสิ่งที่ดูเหมือนว่า

1779
01:18:17,720 --> 01:18:22,290
ดังนั้นในแต่ละพื้นที่ที่สำคัญของฉันฉันได้รับ
ใช้ค้อนทุบในรายการขาย

1780
01:18:22,290 --> 01:18:24,070
ฉันได้รับอะไรที่ใด

1781
01:18:24,070 --> 01:18:26,050
>> ฉันจะบรรเทาปัญหานี้ได้อย่างไร?

1782
01:18:26,050 --> 01:18:28,410
ดีเราบรรเทานี้กับแคช

1783
01:18:28,410 --> 01:18:33,630
แคชคุณใส่พื้นในหน่วยความจำ
พาร์ทิชันในด้านหน้าของฐานข้อมูล

1784
01:18:33,630 --> 01:18:37,260
เรามีการจัดการ
[ไม่ได้ยิน] แคชวิธีการที่คุณ

1785
01:18:37,260 --> 01:18:40,260
สามารถตั้งค่าแคชของคุณเอง [ไม่ได้ยิน]
แคช [? d?] สิ่งที่คุณต้องการ

1786
01:18:40,260 --> 01:18:42,220
ที่ใส่ขึ้นในด้านหน้าของฐานข้อมูล

1787
01:18:42,220 --> 01:18:47,250
และวิธีการที่คุณสามารถเก็บข้อมูลได้ที่
จากคีย์ร้อนขึ้นในแคชที่

1788
01:18:47,250 --> 01:18:49,390
พื้นที่และอ่านผ่านแคช

1789
01:18:49,390 --> 01:18:51,962
>> และจากนั้นส่วนใหญ่อ่านของคุณ
เริ่มมองเช่นนี้

1790
01:18:51,962 --> 01:18:54,920
ผมได้ทุกแคชเหล่านี้ฮิตที่นี่
และผมไม่มีอะไรเกิดขึ้นที่นี่

1791
01:18:54,920 --> 01:18:59,330
เนื่องจากฐานข้อมูลจะนั่งอยู่ด้านหลัง
แคชและอ่านไม่เคยผ่านเข้ามา

1792
01:18:59,330 --> 01:19:02,520
หากฉันเปลี่ยนข้อมูลใน
ฐานข้อมูลที่ผมต้องปรับปรุงแคช

1793
01:19:02,520 --> 01:19:04,360
เราสามารถใช้บางสิ่งบางอย่าง
เช่นไอจะทำอย่างนั้น

1794
01:19:04,360 --> 01:19:07,360
และฉันจะอธิบายวิธีการทำงาน

1795
01:19:07,360 --> 01:19:09,060
สิทธิทั้งหมดส่งข้อความ

1796
01:19:09,060 --> 01:19:11,180
อีเมล์ที่เราใช้อีเมล

1797
01:19:11,180 --> 01:19:12,540
>> นี่คือตัวอย่างที่ดีงาม

1798
01:19:12,540 --> 01:19:14,950
เราได้มีการจัดเรียงของตารางบางข้อความ

1799
01:19:14,950 --> 01:19:17,040
และเราได้กล่องจดหมายและขาออก

1800
01:19:17,040 --> 01:19:19,760
นี่คือสิ่งที่ SQL ก็จะ
ดูต้องการสร้างกล่องจดหมายที่

1801
01:19:19,760 --> 01:19:23,350
เราใช้ชนิดของชนิดเดียวกัน
ของกลยุทธ์ที่จะใช้ GSI ของ GSI ของ

1802
01:19:23,350 --> 01:19:25,320
สำหรับกล่องจดหมายและขาออกของฉัน

1803
01:19:25,320 --> 01:19:27,600
ดังนั้นผมจึงมีข้อความดิบมา
ลงในตารางข้อความของฉัน

1804
01:19:27,600 --> 01:19:30,194
และวิธีแรกนี้
อาจจะบอกว่าโอเคไม่มีปัญหา

1805
01:19:30,194 --> 01:19:31,110
ฉันมีข้อความดิบ

1806
01:19:31,110 --> 01:19:33,710
ข้อความมา [ไม่ได้ยิน]
หมายเลขข้อความที่ดี

1807
01:19:33,710 --> 01:19:35,070
นั่นคือกัญชาที่ไม่ซ้ำกันของฉัน

1808
01:19:35,070 --> 01:19:38,280
ฉันจะสร้างสอง GSI คนหนึ่ง
สำหรับกล่องจดหมายของฉันหนึ่งสำหรับขาออกของฉัน

1809
01:19:38,280 --> 01:19:40,530
และสิ่งแรกที่ฉันจะทำ
คือผมจะบอกว่ากัญชาที่สำคัญของฉันคือ

1810
01:19:40,530 --> 01:19:43,310
จะเป็นผู้รับและ
ฉันจะจัดในวันที่

1811
01:19:43,310 --> 01:19:44,220
นี้เป็นที่ยอดเยี่ยม

1812
01:19:44,220 --> 01:19:45,890
ผมได้รับมุมมองที่ดีของฉันที่นี่

1813
01:19:45,890 --> 01:19:47,780
แต่มีปัญหาเล็ก ๆ น้อย ๆ ที่นี่

1814
01:19:47,780 --> 01:19:50,891
และคุณวิ่งเข้ามาในนี้
ฐานข้อมูลเชิงสัมพันธ์ได้เป็นอย่างดี

1815
01:19:50,891 --> 01:19:52,390
พวกเขาเรียกว่าแบ่งพาร์ทิชันในแนวตั้ง

1816
01:19:52,390 --> 01:19:55,840
คุณต้องการที่จะเก็บข้อมูลขนาดใหญ่ของคุณ
ห่างจากข้อมูลที่น้อยของคุณ

1817
01:19:55,840 --> 01:20:00,470
>> และเหตุผลเป็นเพราะฉันต้อง
ไปอ่านรายการที่จะได้รับคุณสมบัติ

1818
01:20:00,470 --> 01:20:05,570
และถ้าร่างกายของฉันทุกคนที่นี่
แล้วอ่านเพียงไม่กี่รายการ

1819
01:20:05,570 --> 01:20:08,560
ถ้าความยาวร่างกายของฉันคือ
เฉลี่ย 25​​6 กิโลไบต์แต่ละ

1820
01:20:08,560 --> 01:20:10,991
คณิตศาสตร์ที่ได้รับน่าเกลียดสวย

1821
01:20:10,991 --> 01:20:12,490
ดังนั้นจะบอกว่าผมต้องการที่จะอ่านในกล่องจดหมายของเดวิด

1822
01:20:12,490 --> 01:20:14,520
กล่องจดหมายของดาวิดมี 50 รายการ

1823
01:20:14,520 --> 01:20:17,880
ค่าเฉลี่ยและขนาด 256 กิโลไบต์คือ

1824
01:20:17,880 --> 01:20:21,730
นี่คืออัตราการแปลงของฉัน
สำหรับ RCU เป็นสี่กิโลไบต์

1825
01:20:21,730 --> 01:20:24,450
>> ตกลงให้ไปกับ
ที่สอดคล้องกันในที่สุดก็อ่าน

1826
01:20:24,450 --> 01:20:28,640
ฉันยังคงรับประทานอาหาร 1600 RCU ของ
เพียงเพื่ออ่านกล่องจดหมายของเดวิด

1827
01:20:28,640 --> 01:20:29,950
อุ๊ยตาย

1828
01:20:29,950 --> 01:20:31,980
ตกลงตอนนี้ขอคิด
เกี่ยวกับวิธีการทำงานของแอพพลิเค

1829
01:20:31,980 --> 01:20:35,340
ถ้าผมอยู่ในแอปพลิเคอีเมลและ
ฉันกำลังมองหาที่กล่องจดหมายของฉัน

1830
01:20:35,340 --> 01:20:39,680
และฉันมองไปที่ร่างกายของทุกข้อความ
ไม่ฉันกำลังมองหาที่สรุป

1831
01:20:39,680 --> 01:20:41,850
ฉันกำลังมองหาที่ส่วนหัวเท่านั้น

1832
01:20:41,850 --> 01:20:46,310
ดังนั้นเรามาสร้างโครงสร้างตาราง
ที่มีลักษณะเช่นเดียวกับที่อื่น ๆ

1833
01:20:46,310 --> 01:20:49,470
>> ดังนั้นนี่คือข้อมูลที่
ขั้นตอนการทำงานที่ความต้องการของฉัน

1834
01:20:49,470 --> 01:20:50,890
มันอยู่ในกล่องจดหมายของฉัน GSI

1835
01:20:50,890 --> 01:20:53,800
มันเป็นวันที่ผู้ส่ง
เรื่องที่แล้ว

1836
01:20:53,800 --> 01:20:56,790
หมายเลขข้อความซึ่งชี้
กลับไปที่โต๊ะข้อความ

1837
01:20:56,790 --> 01:20:57,850
ที่ฉันจะได้รับร่างกาย

1838
01:20:57,850 --> 01:21:01,260

1839
01:21:01,260 --> 01:21:04,420
ดีเหล่านี้จะเป็นรหัสบันทึก

1840
01:21:04,420 --> 01:21:09,850
พวกเขาจะชี้กลับไปที่
รหัสรายการในตารางฐานข้อมูลไดนาโม

1841
01:21:09,850 --> 01:21:12,220
ดัชนีทุกคนเสมอ creates--
มักจะมีรายการ

1842
01:21:12,220 --> 01:21:15,750
ID เป็นส่วนหนึ่งที่ of--
มาพร้อมกับดัชนี

1843
01:21:15,750 --> 01:21:17,414
>> ทั้งหมดขวา

1844
01:21:17,414 --> 01:21:19,080
ผู้ชม: มันบอกว่าที่มันถูกเก็บไว้?

1845
01:21:19,080 --> 01:21:21,420
RICK Houlihan: ใช่มันบอก
exactly-- ที่ว่าสิ่งที่มันไม่

1846
01:21:21,420 --> 01:21:22,644
มันบอกว่านี่คือบันทึกของฉันอีกครั้ง

1847
01:21:22,644 --> 01:21:24,310
และมันจะชี้กลับไปบันทึกใหม่ของฉัน

1848
01:21:24,310 --> 01:21:26,460
ที่แน่นอน

1849
01:21:26,460 --> 01:21:29,490
ตกลงดังนั้นตอนนี้กล่องจดหมายของฉันคือ
จริงมีขนาดเล็กมาก

1850
01:21:29,490 --> 01:21:32,210
และนี่จริงสนับสนุน
กระบวนการทำงานของ app อีเมล

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
มันตกลงที่จะกลับไปที่
เซิร์ฟเวอร์และ repopulate รูปแบบ

1859
01:21:55,080 --> 01:21:56,860
เพราะนั่นคือสิ่งที่ผู้ใช้คาดหวัง

1860
01:21:56,860 --> 01:22:00,530
เมื่อพวกเขาได้เปลี่ยนมุมมองที่เมื่อ
เราสามารถกลับไปยังฐานข้อมูล

1861
01:22:00,530 --> 01:22:02,480
อีเมลเพื่อคลิก

1862
01:22:02,480 --> 01:22:03,710
ฉันกำลังมองหาร่างกาย

1863
01:22:03,710 --> 01:22:04,330
ไป - กลับ.

1864
01:22:04,330 --> 01:22:05,680
ไปรับร่างกาย

1865
01:22:05,680 --> 01:22:06,950
>> ผมอ่านมากข้อมูลน้อย

1866
01:22:06,950 --> 01:22:09,960
ฉันก็แค่อ่านร่างกายที่
เดวิดต้องการเมื่อเขาต้องการพวกเขา

1867
01:22:09,960 --> 01:22:14,230
และฉันไม่ได้เผาใน 1600
RCU เป็นเพียงการแสดงของเขาในกล่องจดหมาย

1868
01:22:14,230 --> 01:22:17,670
ดังนั้นตอนนี้ that-- นี้เป็นวิธีที่
ที่ LSI หรือ GSI-- ฉันขอโทษ

1869
01:22:17,670 --> 01:22:19,900
GSI จะทำงานออก

1870
01:22:19,900 --> 01:22:25,450
เรามีกัญชาของเราเกี่ยวกับผู้รับ

1871
01:22:25,450 --> 01:22:27,030
เรามีช่วงที่สำคัญในวันที่

1872
01:22:27,030 --> 01:22:31,380
และเราได้มีคุณลักษณะที่คาดการณ์ไว้
ที่เราต้องการเพียงที่จะสนับสนุนมุมมอง

1873
01:22:31,380 --> 01:22:34,300
>> เราหมุนที่กล่องขาออก

1874
01:22:34,300 --> 01:22:35,770
แฮเกี่ยวกับผู้ส่ง

1875
01:22:35,770 --> 01:22:39,612
และในสาระสำคัญที่เรามี
ดีมากมุมมองที่สะอาด

1876
01:22:39,612 --> 01:22:41,570
และมันก็เป็น basically-- เรา
มีข้อความนี้ดี

1877
01:22:41,570 --> 01:22:45,870
ตารางที่ถูกแพร่กระจายอย่างเพราะ
มันเป็นกัญชาเพียงหมายเลขข้อความถก

1878
01:22:45,870 --> 01:22:51,750
และเรามีสองดัชนีที่
จะหมุนออกจากตารางที่

1879
01:22:51,750 --> 01:22:57,411
สิทธิทั้งหมดคิดดังนั้นนี่คือทำไม่ได้
เก็บข้อมูลขนาดใหญ่และข้อมูลเล็ก ๆ นี้

1880
01:22:57,411 --> 01:22:57,910
ด้วยกัน.

1881
01:22:57,910 --> 01:23:00,700
พาร์ทิชันในแนวตั้ง
พาร์ทิชันตารางเหล่านั้น

1882
01:23:00,700 --> 01:23:03,150
ไม่ได้อ่านข้อมูลที่คุณจะได้ไม่ต้อง

1883
01:23:03,150 --> 01:23:04,850
สิทธิทั้งหมดในการเล่นเกม

1884
01:23:04,850 --> 01:23:06,990
เราทุกคนชอบเกม

1885
01:23:06,990 --> 01:23:10,902
อย่างน้อยผมชอบเกมแล้ว

1886
01:23:10,902 --> 01:23:12,735
ดังนั้นบางสิ่งที่
ที่เราจัดการกับเมื่อ

1887
01:23:12,735 --> 01:23:14,193
เรากำลังคิดเกี่ยวกับการเล่นเกมใช่มั้ย?

1888
01:23:14,193 --> 01:23:16,999
เล่นเกมวันนี้โดยเฉพาะอย่างยิ่งโทรศัพท์มือถือ
การเล่นเกมคือทั้งหมดที่เกี่ยวกับการคิด

1889
01:23:16,999 --> 01:23:19,540
และฉันจะหมุนที่นี่
นิด ๆ หน่อย ๆ ออกไปจาก DynamoDB

1890
01:23:19,540 --> 01:23:21,373
ผมจะนำมาใน
บางส่วนของการสนทนา

1891
01:23:21,373 --> 01:23:24,240
รอบบางส่วนของ
เทคโนโลยี AWS อื่น ๆ

1892
01:23:24,240 --> 01:23:28,930
>> แต่ความคิดเกี่ยวกับการเล่นเกมคือการคิด
เกี่ยวกับในแง่ของ API, APIs ที่มี

1893
01:23:28,930 --> 01:23:31,730
โดยทั่วไปพูด HTTP และ JSON

1894
01:23:31,730 --> 01:23:34,550
มันเป็นวิธีที่มือถือเกมชนิดของ
โต้ตอบกับปลายหลังของพวกเขา

1895
01:23:34,550 --> 01:23:35,850
พวกเขาทำเช่นการโพสต์ JSON

1896
01:23:35,850 --> 01:23:40,660
พวกเขาได้รับข้อมูลและมันทั้งหมด
โดยทั่วไปการพูดใน JSON 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
เราได้พูดคุยเกี่ยวกับการเป็น AZS being-- คิด
พวกเขาเป็นศูนย์ข้อมูลที่แยกต่างหาก

1911
01:24:23,780 --> 01:24:26,040
มากกว่าหนึ่งศูนย์ข้อมูล
ต่ออาริโซน่า แต่ที่ตกลง

1912
01:24:26,040 --> 01:24:28,831
เพียงแค่คิดว่าพวกเขาเป็นข้อมูลที่แยกต่างหาก
ศูนย์ที่มีสภาพทางภูมิศาสตร์

1913
01:24:28,831 --> 01:24:30,090
และความผิดที่แยก

1914
01:24:30,090 --> 01:24:32,172
>> เรากำลังจะมี
กรณี 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
offload เซิร์ฟเวอร์

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 เป็นซีดีและ
เครือข่ายการจัดส่งเนื้อหา

1939
01:25:31,720 --> 01:25:35,750
โดยทั่วไปจะใช้เวลาข้อมูลที่คุณระบุ
และเก็บมันทั้งหมดผ่านทางอินเทอร์เน็ต

1940
01:25:35,750 --> 01:25:39,230
เพื่อให้ผู้ใช้สามารถมีทุกที่
ตอบสนองอย่างรวดเร็วมากเมื่อ

1941
01:25:39,230 --> 01:25:40,960
พวกเขาขอวัตถุเหล่านั้น

1942
01:25:40,960 --> 01:25:41,960
>> เพื่อให้คุณได้รับความคิด

1943
01:25:41,960 --> 01:25:48,230
คุณกำลังชนิดของการใช้ประโยชน์จากทุก
แง่มุมของ AWS ที่นี่เพื่อรับนี้ทำ

1944
01:25:48,230 --> 01:25:50,790
และในที่สุดเราโยน
ในกลุ่มที่ปรับอัตโนมัติ

1945
01:25:50,790 --> 01:25:52,737
ดังนั้นกรณี AC2 ของเรา
เซิร์ฟเวอร์เกมของเรา

1946
01:25:52,737 --> 01:25:54,820
ขณะที่พวกเขาเริ่มได้รับยุ่ง
และยุ่งและยุ่ง,

1947
01:25:54,820 --> 01:25:57,236
พวกเขาก็จะหมุนอีก
ตัวอย่างเช่นหมุนกรณีอื่น

1948
01:25:57,236 --> 01:25:58,210
หมุนอีกตัวอย่าง

1949
01:25:58,210 --> 01:26:02,090
ดังนั้นเทคโนโลยี AWS มีมัน
ช่วยให้คุณระบุพารามิเตอร์

1950
01:26:02,090 --> 01:26:04,650
รอบที่เซิร์ฟเวอร์ของคุณจะเติบโต

1951
01:26:04,650 --> 01:26:08,110
ดังนั้นคุณจึงสามารถมีจำนวน n ของเซิร์ฟเวอร์
ออกมีในเวลาใดก็ตาม

1952
01:26:08,110 --> 01:26:11,870
และถ้าโหลดของคุณออกไปพวกเขาจะ
หดตัวจำนวนจะหดตัวลง

1953
01:26:11,870 --> 01:26:15,250
และถ้าโหลดกลับมา
มันจะเติบโตกลับออกยืดหยุ่น

1954
01:26:15,250 --> 01:26:17,050
>> ดังนั้นนี่ดูดี

1955
01:26:17,050 --> 01:26:19,800
เรามีจำนวนมากของกรณี EC2

1956
01:26:19,800 --> 01:26:21,671
เราสามารถใส่ในแคช
ด้านหน้าของฐานข้อมูล

1957
01:26:21,671 --> 01:26:23,045
และพยายามเร่งฐานข้อมูล

1958
01:26:23,045 --> 01:26:25,030
จุดความดันต่อไป
มักจะมีคนเห็น

1959
01:26:25,030 --> 01:26:28,850
คือพวกเขาขนาดโดยใช้เก​​มเป็น
ระบบฐานข้อมูลเชิงสัมพันธ์

1960
01:26:28,850 --> 01:26:30,790
Jeez ฐานข้อมูล
ผลการดำเนินงานที่น่ากลัวคือ

1961
01:26:30,790 --> 01:26:31,932
เราจะปรับปรุงอย่างไร

1962
01:26:31,932 --> 01:26:33,640
ลองใส่
แคชในด้านหน้าของที่

1963
01:26:33,640 --> 01:26:36,780
>> ดีแคชไม่ทำงาน
เพื่อที่ดีในการเล่นเกมใช่มั้ย?

1964
01:26:36,780 --> 01:26:39,330
สำหรับเกมการเขียนเป็นความเจ็บปวด

1965
01:26:39,330 --> 01:26:40,930
เกมจะเขียนมากหนัก

1966
01:26:40,930 --> 01:26:43,610
แคชไม่ทำงานเมื่อคุณ
เขียนหนักเพราะคุณได้เสมอ

1967
01:26:43,610 --> 01:26:44,610
มีการอัปเดตแคช

1968
01:26:44,610 --> 01:26:47,780
คุณปรับปรุงแคชก็
ที่ไม่เกี่ยวข้องจะเป็นแคช

1969
01:26:47,780 --> 01:26:49,780
เป็นจริงเพียงแค่การทำงานพิเศษ

1970
01:26:49,780 --> 01:26:51,970
>> เพื่อที่เราจะไปที่นี่?

1971
01:26:51,970 --> 01:26:54,400
คุณได้มีคอขวดใหญ่
มีการลงในฐานข้อมูล

1972
01:26:54,400 --> 01:26:57,661
และสถานที่ที่จะไป
เห็นได้ชัดว่ามีการแบ่งพาร์ทิชัน

1973
01:26:57,661 --> 01:26:59,410
พาร์ทิชันไม่ได้
ง่ายที่จะทำเมื่อคุณอยู่

1974
01:26:59,410 --> 01:27:01,900
การจัดการกับฐานข้อมูลเชิงสัมพันธ์

1975
01:27:01,900 --> 01:27:05,080
ด้วยฐานข้อมูลเชิงสัมพันธ์คุณ
รับผิดชอบในการจัดการอย่างมีประสิทธิภาพ

1976
01:27:05,080 --> 01:27:06,210
พื้นที่ที่สำคัญ

1977
01:27:06,210 --> 01:27:10,527
คุณกำลังจะบอกว่าผู้ใช้ระหว่าง A และ M
ไปที่นี่ระหว่าง n และ Z ไปที่นั่น

1978
01:27:10,527 --> 01:27:12,360
และคุณเปลี่ยน
ข้ามแอพลิเคชัน

1979
01:27:12,360 --> 01:27:15,000
ดังนั้นคุณจัดการกับ
แหล่งข้อมูลพาร์ทิชันนี้

1980
01:27:15,000 --> 01:27:18,670
คุณมีข้อ จำกัด ในการทำธุรกรรม
ที่ไม่ครอบคลุมพาร์ทิชัน

1981
01:27:18,670 --> 01:27:20,560
คุณได้ทุกชนิด
สกปรกที่คุณ

1982
01:27:20,560 --> 01:27:23,040
การจัดการกับความพยายามลงไปที่นั่น
ที่จะจัดการกับการปรับออก

1983
01:27:23,040 --> 01:27:25,120
และการสร้างโครงสร้างพื้นฐานขนาดใหญ่

1984
01:27:25,120 --> 01:27:27,284
มันเป็นเพียงแค่สนุก

1985
01:27:27,284 --> 01:27:30,930
>> ผู้ชม: ดังนั้นที่คุณบอกว่า
การเพิ่มแหล่งที่มาของจุดเพิ่มความเร็วในการ

1986
01:27:30,930 --> 01:27:31,430
กระบวนการ?

1987
01:27:31,430 --> 01:27:32,513
RICK Houlihan: การเพิ่ม?

1988
01:27:32,513 --> 01:27:33,520
ผู้ชม: จุดที่มา

1989
01:27:33,520 --> 01:27:34,410
RICK Houlihan: จุดที่มา?

1990
01:27:34,410 --> 01:27:37,500
ผู้ชม: จากข้อมูล
ซึ่งข้อมูลจะมาจากไหน?

1991
01:27:37,500 --> 01:27:38,250
RICK Houlihan: เลขที่

1992
01:27:38,250 --> 01:27:41,820
สิ่งที่ฉันพูดคือการเพิ่ม
จำนวนของพาร์ทิชันในการจัดเก็บข้อมูล

1993
01:27:41,820 --> 01:27:44,060
ช่วยเพิ่มการส่งผ่าน

1994
01:27:44,060 --> 01:27:48,300
ดังนั้นสิ่งที่เกิดขึ้นที่นี่เป็นผู้ใช้
ที่เข้ามาในอินสแตนซ์ EC2 ขึ้นที่นี่

1995
01:27:48,300 --> 01:27:50,780
ดีถ้าฉันต้องการของผู้ใช้
ที่ A ถึง M ผมจะไปที่นี่

1996
01:27:50,780 --> 01:27:53,560
จาก N เพื่อหน้าผมจะไปที่นี่

1997
01:27:53,560 --> 01:27:55,060
จาก P ถึง Z ผมจะไปที่นี่

1998
01:27:55,060 --> 01:27:57,120
>> ผู้ชม: ตกลงเหล่านั้นเพื่อให้ผู้ที่มี
เก็บไว้ในโหนดที่แตกต่างกัน?

1999
01:27:57,120 --> 01:27:57,911
>> RICK Houlihan: ใช่

2000
01:27:57,911 --> 01:28:00,210
คิดว่าของเหล่านี้เป็น
ไซโลที่แตกต่างกันของข้อมูล

2001
01:28:00,210 --> 01:28:01,660
ดังนั้นคุณต้องทำเช่นนี้

2002
01:28:01,660 --> 01:28:02,910
ถ้าคุณกำลังพยายามที่จะทำ
นี้ถ้าคุณกำลังพยายามที่

2003
01:28:02,910 --> 01:28:05,730
ที่จะไต่บนแพลตฟอร์มเชิงสัมพันธ์
นี่คือสิ่งที่คุณกำลังทำ

2004
01:28:05,730 --> 01:28:08,100
คุณกำลังการข้อมูลและ
คุณกำลังตัดมันลง

2005
01:28:08,100 --> 01:28:10,975
และคุณแบ่งมันข้าม
หลายกรณีของฐานข้อมูล

2006
01:28:10,975 --> 01:28:13,580
และคุณจัดการทุกสิ่งที่
ในชั้นการประยุกต์ใช้

2007
01:28:13,580 --> 01:28:14,729
มันไม่สนุก

2008
01:28:14,729 --> 01:28:15,770
ดังนั้นสิ่งที่เราต้องการจะไป?

2009
01:28:15,770 --> 01:28:20,240
เราต้องการที่จะไป DynamoDB อย่างเต็มที่การจัดการ
NoSQL เก็บข้อมูลผ่านการให้

2010
01:28:20,240 --> 01:28:22,680
เราใช้ดัชนีรอง

2011
01:28:22,680 --> 01:28:26,154
มันเป็นพื้น HTTP API และ
รวมถึงการสนับสนุนเอกสาร

2012
01:28:26,154 --> 01:28:28,570
ดังนั้นคุณจึงไม่ต้องกังวล
ใด ๆ เกี่ยวกับการแบ่งว่า

2013
01:28:28,570 --> 01:28:30,740
เราทำทุกอย่างให้คุณ

2014
01:28:30,740 --> 01:28:33,260
ดังนั้นตอนนี้แทนคุณ
เพียงแค่เขียนลงในตาราง

2015
01:28:33,260 --> 01:28:36,490
ถ้าตารางจะต้องมีการแบ่งพาร์ติชัน
ที่เกิดขึ้นอยู่เบื้องหลัง

2016
01:28:36,490 --> 01:28:40,642
คุณกำลังฉนวนสมบูรณ์
จากการที่เป็นนักพัฒนา

2017
01:28:40,642 --> 01:28:42,350
ดังนั้นเรามาพูดคุยเกี่ยวกับ
บางส่วนของกรณีการใช้งาน

2018
01:28:42,350 --> 01:28:47,564
ที่เราใช้เป็นในการเล่นเกมร่วมกัน
สถานการณ์การเล่นเกมลีดเดอร์

2019
01:28:47,564 --> 01:28:49,980
เพื่อให้คุณได้มีผู้ใช้มาใน
BoardNames ที่พวกเขากำลัง

2020
01:28:49,980 --> 01:28:52,930
เมื่อคะแนนสำหรับผู้ใช้นี้

2021
01:28:52,930 --> 01:28:57,700
เราอาจจะมีการ hashing หมายเลขผู้ใช้ในการ
แล้วเรามีช่วงในเกม

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
เมื่อบัน​​ทึกของฉันมีการถกกันใน
หมายเลขผู้ใช้ที่อยู่ในช่วงในเกม

2029
01:29:18,070 --> 01:29:20,740
ดีฉันจะไปข้างหน้า
และการปรับโครงสร้างสร้าง GSI,

2030
01:29:20,740 --> 01:29:22,370
และฉันจะปรับโครงสร้างข้อมูลว่า

2031
01:29:22,370 --> 01:29:27,310
>> ตอนนี้ผมกำลังจะไปสับบน
BoardName ซึ่งเป็นเกม

2032
01:29:27,310 --> 01:29:29,800
และฉันกำลังจะไปช่วงที่คะแนนสูงสุด

2033
01:29:29,800 --> 01:29:31,540
และตอนนี้เราได้สร้างถังที่แตกต่างกัน

2034
01:29:31,540 --> 01:29:34,790
ฉันใช้ตารางเดียวกัน
ข้อมูลรายการเดียวกัน

2035
01:29:34,790 --> 01:29:39,870
แต่ผมกำลังสร้างถังที่ให้
ฉันรวมตัวของคะแนนสูงสุดจากเกม

2036
01:29:39,870 --> 01:29:43,180
>> และผมสามารถสอบถามตารางที่
เพื่อให้ได้ข้อมูลที่

2037
01:29:43,180 --> 01:29:50,890
ดังนั้นผมจึงได้กำหนดรูปแบบการสอบถามที่ขึ้นไป
ได้รับการสนับสนุนโดยดัชนีรอง

2038
01:29:50,890 --> 01:29:54,556
ตอนนี้พวกเขาสามารถจัดเรียงตาม BoardName
และจัดเรียงตาม topscore ขึ้นอยู่กับ

2039
01:29:54,556 --> 01:29:57,180
ดังนั้นคุณจะเห็นเหล่านี้เป็นประเภท
กรณีการใช้งานของคุณจะได้รับในการเล่นเกม

2040
01:29:57,180 --> 01:30:02,190
อีกกรณีที่ใช้งานที่ดีที่เราได้รับในการเล่นเกม
จะได้รับรางวัลและผู้ที่ได้รับรางวัลได้รับรางวัล

2041
01:30:02,190 --> 01:30:05,340
และนี่เป็นกรณีที่ใช้งานที่ดี
ที่เราเรียกว่าดัชนีเบาบาง

2042
01:30:05,340 --> 01:30:07,340
ดัชนีเบาบางเป็น
ความสามารถในการสร้าง

2043
01:30:07,340 --> 01:30:10,850
ดัชนีที่ไม่จำเป็นต้อง
มีทุกรายการเดียวบนโต๊ะ

2044
01:30:10,850 --> 01:30:11,470
และทำไมไม่?

2045
01:30:11,470 --> 01:30:14,540
เพราะแอตทริบิวต์ที่เป็น
การจัดทำดัชนีไม่ได้มีอยู่ในทุกรายการ

2046
01:30:14,540 --> 01:30:16,460
>> ดังนั้นในการนี​​้โดยเฉพาะ
ใช้กรณีที่ผมว่า

2047
01:30:16,460 --> 01:30:19,240
คุณรู้ว่าสิ่งที่ผมกำลังจะไป
สร้างแอตทริบิวต์ที่เรียกว่ารางวัล

2048
01:30:19,240 --> 01:30:22,970
และฉันจะให้ผู้ใช้ทุกคน
ที่มีรางวัลที่แอตทริบิวต์

2049
01:30:22,970 --> 01:30:25,950
ผู้ใช้ที่ไม่ได้รับรางวัลเป็น
ไม่ได้ไปมีแอตทริบิวต์ที่

2050
01:30:25,950 --> 01:30:27,800
ดังนั้นเมื่อผมสร้าง
ดัชนีผู้ใช้เท่านั้น

2051
01:30:27,800 --> 01:30:28,960
ที่จะแสดง
ขึ้นในดัชนีที่มี

2052
01:30:28,960 --> 01:30:31,050
คนที่จริงได้รับรางวัล

2053
01:30:31,050 --> 01:30:34,440
เพื่อให้เป็นวิธีที่ดีที่จะสามารถ
ในการสร้างดัชนีกรองที่

2054
01:30:34,440 --> 01:30:40,580
มีมากเลือกมากที่ทำไม่ได้
มีดัชนีทั้งตาราง

2055
01:30:40,580 --> 01:30:43,050
>> ดังนั้นเราจึงได้รับต่ำในเวลาที่นี่

2056
01:30:43,050 --> 01:30:49,190
ฉันจะไปข้างหน้าและข้าม
ออกและข้ามสถานการณ์นี้

2057
01:30:49,190 --> 01:30:52,625
พูดคุยนิด ๆ หน่อย ๆ 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 Houlihan: อะไรคืออะไร?

2061
01:30:57,680 --> 01:30:58,596
ผู้ชม: เขียนหนัก

2062
01:30:58,596 --> 01:31:01,270
RICK Houlihan: เขียนหนัก

2063
01:31:01,270 --> 01:31:03,460
ให้ฉันดู.

2064
01:31:03,460 --> 01:31:06,220
>> ผู้ชม: หรือไม่
สิ่งที่คุณสามารถเพียง

2065
01:31:06,220 --> 01:31:08,809
เสียงไปในเรื่องของการวินาที?

2066
01:31:08,809 --> 01:31:10,850
RICK Houlihan: เราไป
ผ่านสถานการณ์การออกเสียงลงคะแนน

2067
01:31:10,850 --> 01:31:11,670
มันไม่ใช่ว่าไม่ดี

2068
01:31:11,670 --> 01:31:14,580
พวกคุณมีไม่กี่นาที?

2069
01:31:14,580 --> 01:31:15,860
ตกลง.

2070
01:31:15,860 --> 01:31:17,890
>> ดังนั้นเราจะพูดคุยเกี่ยวกับการลงคะแนน

2071
01:31:17,890 --> 01:31:20,250
ดังนั้นการออกเสียงลงคะแนนเวลาจริงเรามี
ความต้องการสำหรับการลงคะแนน

2072
01:31:20,250 --> 01:31:25,250
ความต้องการที่เราอนุญาตให้
แต่ละคนที่จะลงคะแนนเพียงครั้งเดียว

2073
01:31:25,250 --> 01:31:28,060
เราต้องการที่ไม่มีใครที่จะสามารถ
ที่จะเปลี่ยนคะแนนเสียงของพวกเขา

2074
01:31:28,060 --> 01:31:31,045
เราต้องการรวมเวลาจริง
และการวิเคราะห์สำหรับประชากร

2075
01:31:31,045 --> 01:31:34,210
ที่เรากำลังจะได้รับ
แสดงให้กับผู้ใช้บนเว็บไซต์

2076
01:31:34,210 --> 01:31:35,200
>> คิดว่าสถานการณ์นี้

2077
01:31:35,200 --> 01:31:37,550
เราทำงานจำนวนมากของความเป็นจริง
รายการโทรทัศน์ที่พวกเขากำลัง

2078
01:31:37,550 --> 01:31:38,960
ทำเหล่านี้ชนิดที่แน่นอนของสิ่งที่

2079
01:31:38,960 --> 01:31:41,584
ดังนั้นคุณสามารถคิดสถานการณ์
เรามีล้านล้าน

2080
01:31:41,584 --> 01:31:43,959
ของเด็กสาววัยรุ่นที่นั่น
กับโทรศัพท์มือถือของพวกเขา

2081
01:31:43,959 --> 01:31:46,250
และออกเสียงลงคะแนนและการออกเสียงลงคะแนนและ
ใครก็ตามที่ลงคะแนนให้พวกเขามี

2082
01:31:46,250 --> 01:31:48,610
พบว่าจะมีความนิยมมากที่สุด

2083
01:31:48,610 --> 01:31:50,830
ดังนั้นเหล่านี้คือบางส่วนของ
ความต้องการที่เราวิ่งออกไป

2084
01:31:50,830 --> 01:31:52,990
>> และเพื่อให้เป็นครั้งแรกที่ใช้
ในการแก้ปัญหานี้

2085
01:31:52,990 --> 01:31:55,090
จะมีการสร้าง
โปรแกรมที่ง่ายมาก

2086
01:31:55,090 --> 01:31:56,490
ดังนั้นผมจึงได้มีการตรวจสอบนี้

2087
01:31:56,490 --> 01:31:57,950
ฉันมีผู้มีสิทธิเลือกตั้งบางส่วนออกมี

2088
01:31:57,950 --> 01:31:59,980
พวกเขามาในพวกเขาตี app ที่ลงคะแนน

2089
01:31:59,980 --> 01:32:03,440
ฉันมีบางตารางคะแนนโหวตดิบ
ฉันเพิ่งจะถ่ายโอนข้อมูลเหล่านั้นลงคะแนนเสียง

2090
01:32:03,440 --> 01:32:05,780
ฉันจะต้องรวมบางส่วน
ตารางคะแนนโหวตว่า

2091
01:32:05,780 --> 01:32:09,490
จะทำวิเคราะห์และประชากรของฉัน
และเราจะใส่ทั้งหมดนี้อยู่ในนั้น

2092
01:32:09,490 --> 01:32:11,420
>> และนี่คือที่ดี

2093
01:32:11,420 --> 01:32:12,332
ชีวิตเป็นสิ่งที่ดี.

2094
01:32:12,332 --> 01:32:15,040
ชีวิตที่ดีจนกว่าเราจะพบว่า
มีเสมอเพียงหนึ่งหรือสอง

2095
01:32:15,040 --> 01:32:16,879
คนที่เป็นที่นิยมในการเลือกตั้ง

2096
01:32:16,879 --> 01:32:19,420
มีเพียงหนึ่งหรือสองสิ่งที่เป็น
ว่าคนที่สนใจจริงๆ

2097
01:32:19,420 --> 01:32:22,340
และถ้าคุณลงคะแนนที่
ขนาดทั้งหมดในทันทีที่ฉัน

2098
01:32:22,340 --> 01:32:26,360
จะได้รับการตอกนรกออกจาก
สองผู้สมัครหนึ่งหรือสองผู้สมัคร

2099
01:32:26,360 --> 01:32:29,390
จำนวน จำกัด มากของรายการ
คนพบว่าเป็นที่นิยม

2100
01:32:29,390 --> 01:32:31,710
>> นี้ไม่ได้เป็นรูปแบบการออกแบบที่ดี

2101
01:32:31,710 --> 01:32:33,549
นี้เป็นจริง
รูปแบบการออกแบบที่ดีมาก

2102
01:32:33,549 --> 01:32:36,340
เพราะมันจะสร้างสิ่งที่เรา
พูดคุยเกี่ยวกับซึ​​่งเป็นปุ่มลัด

2103
01:32:36,340 --> 01:32:38,960
คีย์ร้อนเป็นสิ่งที่เราไม่ชอบ

2104
01:32:38,960 --> 01:32:40,470
>> ดังนั้นวิธีที่เราจะแก้ไขปัญหาที่?

2105
01:32:40,470 --> 01:32:47,640
และจริงๆวิธีการแก้ไขปัญหานี้คือ
โดยการใช้ถังผู้สมัครเหล่านั้น

2106
01:32:47,640 --> 01:32:51,490
และให้ผู้สมัครที่เรามีในแต่ละครั้ง
เรากำลังจะผนวกค่าส​​ุ่ม

2107
01:32:51,490 --> 01:32:54,192
สิ่งที่เรารู้ว่าสุ่ม
ค่าระหว่างหนึ่งและ 100

2108
01:32:54,192 --> 01:32:56,620
ระหว่าง 100 และ 1,000
หรือระหว่างหนึ่งและ 1,000

2109
01:32:56,620 --> 01:32:59,940
แต่ค่าสุ่มมากมายที่คุณต้องการ
ผนวกเข้าสู่จุดสิ้นสุดของผู้สมัครว่า

2110
01:32:59,940 --> 01:33:01,330
>> และสิ่งที่ผมได้ทำมาแล้ว?

2111
01:33:01,330 --> 01:33:05,830
หากฉันใช้รหัสผู้สมัครเป็น
ถังเสียงรวม

2112
01:33:05,830 --> 01:33:08,780
ถ้าฉันได้เพิ่มการสุ่ม
จำนวนที่ส่วนท้ายของนั้น

2113
01:33:08,780 --> 01:33:12,000
เราได้สร้างตอนนี้ 10 ถังเป็น
ร้อยถังพันถัง

2114
01:33:12,000 --> 01:33:14,160
ที่ฉันรวมคะแนนโหวตทั่ว

2115
01:33:14,160 --> 01:33:18,030
>> ดังนั้นผมจึงมีนับล้านและล้าน
และล้านระเบียนมา

2116
01:33:18,030 --> 01:33:22,050
สำหรับผู้สมัครเหล่านี้ตอนนี้ฉันการแพร่กระจาย
คะแนนโหวตผู้สมัครทั่ว A_1

2117
01:33:22,050 --> 01:33:24,630
ผ่านผู้สมัคร A_100 เพราะ
ทุกครั้งที่การลงคะแนนเสียงมาใน

2118
01:33:24,630 --> 01:33:26,530
ฉันสร้างแบบสุ่ม
ค่าระหว่างหนึ่งและ 100

2119
01:33:26,530 --> 01:33:29,446
ฉันตรึงมันลงบนปลาย
ผู้สมัครที่มีสิทธิออกเสียงของบุคคลสำหรับ

2120
01:33:29,446 --> 01:33:31,120
ฉันทิ้งมันลงในถังที่

2121
01:33:31,120 --> 01:33:33,910
>> ตอนนี้ในด้านหลังฉันรู้ว่า
ที่ผมได้ร้อยถัง

2122
01:33:33,910 --> 01:33:36,350
ดังนั้นเมื่อผมต้องการที่จะไปข้างหน้า
และรวบรวมคะแนนเสียง

2123
01:33:36,350 --> 01:33:38,244
ผมอ่านจากทั่วทุกถังเหล่านั้น

2124
01:33:38,244 --> 01:33:39,160
ดังนั้นผมจึงไปข้างหน้าและเพิ่ม

2125
01:33:39,160 --> 01:33:42,410
แล้วฉันจะกระจายรวบรวม
ที่ฉันออกไปและบอกว่าเดี๋ยวก่อน

2126
01:33:42,410 --> 01:33:45,399
คุณรู้ว่าสิ่งที่สำคัญของผู้สมัครนี้
ช่องว่างที่มีมากกว่าร้อยถัง

2127
01:33:45,399 --> 01:33:47,940
ฉันจะรวบรวมทั้งหมด
เสียงจากผู้ที่ร้อยถัง

2128
01:33:47,940 --> 01:33:49,981
ฉันจะรวม
พวกเขาและฉันจะพูดว่า

2129
01:33:49,981 --> 01:33:53,830
ผู้สมัครตอนนี้มี
นับคะแนนรวมของ x

2130
01:33:53,830 --> 01:33:55,690
>> ตอนนี้ทั้งสองเขียน
แบบสอบถามและแบบสอบถามอ่าน

2131
01:33:55,690 --> 01:33:58,160
มีการกระจายอย่าง
เพราะผมเขียนทั่ว

2132
01:33:58,160 --> 01:34:00,320
และฉันอ่านในหลายร้อยของคีย์

2133
01:34:00,320 --> 01:34:03,500
ฉันไม่ได้เขียนและการ
อ่านทั่วหนึ่งที่สำคัญในขณะนี้

2134
01:34:03,500 --> 01:34:04,950
เพื่อให้เป็นรูปแบบที่ดี

2135
01:34:04,950 --> 01:34:08,090
>> นี้เป็นจริงอาจจะเป็นหนึ่ง
ของการออกแบบที่สำคัญที่สุด

2136
01:34:08,090 --> 01:34:10,420
สำหรับรูปแบบขนาดใน NoSQL

2137
01:34:10,420 --> 01:34:14,470
คุณจะเห็นชนิดนี้
รูปแบบการออกแบบในทุกรสชาติ

2138
01:34:14,470 --> 01:34:19,100
MongoDB, 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
คุณกำลังจะปิดการซื้อขายอ่าน
ค่าใช้จ่ายสำหรับการเขียน scalability

2144
01:34:35,252 --> 01:34:37,085
ค่าใช้จ่ายในการอ่านของฉันคือ
เล็ก ๆ น้อย ๆ ที่ซับซ้อนมากขึ้น

2145
01:34:37,085 --> 01:34:40,220
และฉันต้องไปอ่านจาก
ร้อยถังแทนหนึ่ง

2146
01:34:40,220 --> 01:34:41,310
แต่ผมก็สามารถที่จะเขียน

2147
01:34:41,310 --> 01:34:44,860
และการส่งผ่านของฉันเขียนฉัน
ผ่านเป็นที่น่าทึ่ง

2148
01:34:44,860 --> 01:34:49,450
ดังนั้นจึงมักจะเป็นที่มีคุณค่า
เทคนิคในการปรับ DynamoDB,

2149
01:34:49,450 --> 01:34:51,350
หรือฐานข้อมูล NoSQL สำหรับเรื่องที่

2150
01:34:51,350 --> 01:34:53,824

2151
01:34:53,824 --> 01:34:55,240
ดังนั้นเราจึงคิดวิธีการขนาดมัน

2152
01:34:55,240 --> 01:34:56,930
และเราคิดว่าวิธีการที่จะ
ขจัดปุ่มร้อนของเรา

2153
01:34:56,930 --> 01:34:57,820
และนี่คือที่ยอดเยี่ยม

2154
01:34:57,820 --> 01:34:58,960
และเรามีระบบที่ดีนี้

2155
01:34:58,960 --> 01:35:02,043
และก็ให้เราในการออกเสียงที่ถูกต้องมาก
เพราะเรามีการบันทึกการออกเสียงลงคะแนน de-ล่อ

2156
01:35:02,043 --> 01:35:03,130
มันสร้างขึ้นใน DynamoDB

2157
01:35:03,130 --> 01:35:05,380
เราได้พูดคุยเกี่ยวกับสิทธิตามเงื่อนไข

2158
01:35:05,380 --> 01:35:08,170
>> เมื่อผู้มีสิทธิเลือกตั้งมาในทำให้
แทรกบนโต๊ะที่

2159
01:35:08,170 --> 01:35:11,220
พวกเขาใส่ที่มี ID ผู้มีสิทธิเลือกตั้งของพวกเขา
ถ้าพวกเขาพยายามที่จะแทรกลงคะแนนอีก

2160
01:35:11,220 --> 01:35:13,320
ฉันจะเขียนเงื่อนไข

2161
01:35:13,320 --> 01:35:16,960
พูดเพียงเขียนนี้
ถ้าเรื่องนี้ไม่ได้อยู่

2162
01:35:16,960 --> 01:35:19,270
ดังนั้นทันทีที่ผมเห็นว่า
การออกเสียงลงคะแนนที่ตีตาราง

2163
01:35:19,270 --> 01:35:20,460
ไม่มีใครอื่นเป็นไปได้
สามารถที่จะนำพวกเขาในการลงคะแนนเสียง

2164
01:35:20,460 --> 01:35:21,634
และที่ยอดเยี่ยม

2165
01:35:21,634 --> 01:35:23,550
และเรากำลังการเพิ่ม
ผู้สมัครที่เคาน์เตอร์ของเรา

2166
01:35:23,550 --> 01:35:25,466
และเรากำลังทำของเรา
ประชากรและสิ่งที่

2167
01:35:25,466 --> 01:35:29,110
แต่สิ่งที่เกิดขึ้นถ้าฉัน
แอพลิเคชันตกมากกว่า?

2168
01:35:29,110 --> 01:35:31,350
ตอนนี้สิ่งที่ของคะแนนโหวตอย่างฉับพลัน
เป็นมาและฉัน

2169
01:35:31,350 --> 01:35:34,840
ไม่ทราบว่าพวกเขากำลังได้รับการประมวลผล
เข้าสู่การวิเคราะห์และประชากรของฉัน

2170
01:35:34,840 --> 01:35:36,040
อีกต่อไป

2171
01:35:36,040 --> 01:35:38,462
และเมื่อแอพลิเคชัน
กลับมาขึ้นได้อย่างไร

2172
01:35:38,462 --> 01:35:41,420
นรกฉันรู้ว่าสิ่งที่มีคะแนนโหวต
รับการประมวลผลและการที่ฉันจะเริ่มต้นอย่างไร

2173
01:35:41,420 --> 01:35:44,530
>> ดังนั้นนี่คือปัญหาที่แท้จริงเมื่อคุณ
เริ่มที่จะมองไปที่ชนิดของสถ​​านการณ์นี้

2174
01:35:44,530 --> 01:35:45,571
และวิธีการที่เราแก้ที่?

2175
01:35:45,571 --> 01:35:48,070
เราแก้มันกับสิ่งที่เรา
เรียกกระแส DynamoDB

2176
01:35:48,070 --> 01:35:53,470
ลำธารเป็นเวลาสั่งซื้อและ
แบ่งการเปลี่ยนแปลงเข้าสู่ระบบของการเข้าถึงทุก

2177
01:35:53,470 --> 01:35:55,700
ไปที่โต๊ะทุกเขียน
การเข้าถึงตาราง

2178
01:35:55,700 --> 01:35:58,810
ข้อมูลใด ๆ ที่เขียนถึง
ตารางแสดงบนกระแส

2179
01:35:58,810 --> 01:36:01,815
>> มันเป็นพื้นคิวตลอด 24 ชั่วโมง

2180
01:36:01,815 --> 01:36:03,690
รายการตีกระแส
พวกเขาอาศัยอยู่เป็นเวลา 24 ชั่วโมง

2181
01:36:03,690 --> 01:36:05,990
พวกเขาสามารถอ่านได้หลายครั้ง

2182
01:36:05,990 --> 01:36:09,400
รับประกันที่จะส่งมอบ
เพียงครั้งเดียวเพื่อกระแส

2183
01:36:09,400 --> 01:36:11,180
สามารถอ่านจำนวน n ครั้ง

2184
01:36:11,180 --> 01:36:14,910
ดังนั้นอย่างไรก็ตามกระบวนการมากมายที่คุณต้องการ
ใช้ข้อมูลที่คุณสามารถกินมัน

2185
01:36:14,910 --> 01:36:16,350
มันจะปรากฏทุกปรับปรุง

2186
01:36:16,350 --> 01:36:18,455
เขียนทุกคนจะมีเพียง
ปรากฏครั้งเดียวในกระแส

2187
01:36:18,455 --> 01:36:20,621
ดังนั้นคุณจึงไม่ต้องกังวล
เกี่ยวกับการประมวลผลเป็นครั้งที่สอง

2188
01:36:20,621 --> 01:36:22,500
จากกระบวนการเดียวกัน

2189
01:36:22,500 --> 01:36:25,350
>> มันมีคำสั่งอย่างเคร่งครัดต่อรายการ

2190
01:36:25,350 --> 01:36:28,180
เมื่อเราพูดเวลา
สั่งซื้อและแบ่งพาร์ติชัน

2191
01:36:28,180 --> 01:36:30,680
คุณจะเห็นต่อพาร์ทิชันในกระแส

2192
01:36:30,680 --> 01:36:33,169
คุณจะเห็นรายการปรับปรุงในการสั่งซื้อ

2193
01:36:33,169 --> 01:36:35,210
เราไม่ได้รับประกัน
ในกระแสที่คุณเป็น

2194
01:36:35,210 --> 01:36:40,240
จะได้รับการทำธุรกรรมทุก
ในการสั่งซื้อผ่านรายการ

2195
01:36:40,240 --> 01:36:42,440
>> ดังนั้นลำธารเป็น idempotent

2196
01:36:42,440 --> 01:36:44,037
พวกเราทุกคนรู้ว่าสิ่งที่ idempotent หมายถึงอะไร?

2197
01:36:44,037 --> 01:36:46,620
idempotent หมายความว่าคุณสามารถทำมันได้
มากกว่าและเหนือและมากกว่าอีกครั้ง

2198
01:36:46,620 --> 01:36:48,200
ผลที่ได้จะเป็นแบบเดียวกัน

2199
01:36:48,200 --> 01:36:49,991
>> ลำธารเป็น idempotent,
แต่พวกเขาจะต้อง

2200
01:36:49,991 --> 01:36:54,860
เล่นได้จากจุดเริ่มต้น
ทุกที่ที่คุณเลือกไปยังจุดสิ้นสุด

2201
01:36:54,860 --> 01:36:57,950
หรือพวกเขาจะไม่ส่งผล
ในค่าเดียวกัน

2202
01:36:57,950 --> 01:36:59,727
>> สิ่งเดียวกันกับ MongoDB

2203
01:36:59,727 --> 01:37:01,560
MongoDB มีสร้าง
ที่พวกเขาเรียก oplog

2204
01:37:01,560 --> 01:37:04,140
มันเป็นโครงสร้างเดียวกันแน่นอน

2205
01:37:04,140 --> 01:37:06,500
ฐานข้อมูล NoSQL หลาย
มีการสร้างนี้

2206
01:37:06,500 --> 01:37:08,790
พวกเขาใช้ในการทำสิ่งที่
เช่นการจำลองแบบที่

2207
01:37:08,790 --> 01:37:10,475
เป็นสิ่งที่เราจะทำอย่างไรกับลำธาร

2208
01:37:10,475 --> 01:37:12,350
ผู้ชม: บางที
คำถามนอกคอก แต่คุณ

2209
01:37:12,350 --> 01:37:13,975
พูดคุยเกี่ยวกับการทำแอพพลิเคลงอื่น ๆ

2210
01:37:13,975 --> 01:37:16,089
มีการรับประกันว่าจะให้ลำธาร
ไม่อาจจะลงไป?

2211
01:37:16,089 --> 01:37:18,630
RICK Houlihan: ใช่ลำธาร
มีการรับประกันว่าจะไม่ลงไป

2212
01:37:18,630 --> 01:37:21,040
เราจัดการโครงสร้างพื้นฐาน
ที่อยู่เบื้องหลัง ลำธารโดยอัตโนมัติ

2213
01:37:21,040 --> 01:37:22,498
ปรับใช้ในกลุ่มรถยนต์ของพวกเขาปรับ

2214
01:37:22,498 --> 01:37:25,910
เราจะผ่านไปเพียงเล็กน้อย
เล็กน้อยเกี่ยวกับสิ่งที่เกิดขึ้น

2215
01:37:25,910 --> 01:37:30,060
>> ฉันไม่ควรจะพูดว่าพวกเขาไม่ได้
รับประกันว่าจะไม่ลงไป

2216
01:37:30,060 --> 01:37:33,110
องค์ประกอบที่มีการรับประกัน
จะปรากฏในกระแส

2217
01:37:33,110 --> 01:37:36,740
และกระแสจะสามารถเข้าถึงได้

2218
01:37:36,740 --> 01:37:40,580
ดังนั้นสิ่งที่จะไปลงหรือกลับมา
ขึ้นที่เกิดขึ้นภายใต้

2219
01:37:40,580 --> 01:37:43,844
มัน covers-- ก็ OK

2220
01:37:43,844 --> 01:37:46,260
สิทธิทั้งหมดเพื่อให้คุณได้รับที่แตกต่างกัน
ประเภทมุมมองออกมานอกจอ

2221
01:37:46,260 --> 01:37:51,040
ประเภทมุมมองที่มีความสำคัญไป
โปรแกรมเมอร์มักจะเป็นสิ่งที่มันได้หรือไม่

2222
01:37:51,040 --> 01:37:52,370
ฉันจะได้รับมุมมองเก่า

2223
01:37:52,370 --> 01:37:55,630
เมื่อการปรับปรุงฮิตโต๊ะก็จะ
ผลักดันมุมมองเก่าที่จะสตรีม

2224
01:37:55,630 --> 01:38:02,070
ข้อมูลเพื่อสามารถเก็บหรือเปลี่ยน
การควบคุมการระบุการเปลี่ยนแปลงการเปลี่ยนแปลง

2225
01:38:02,070 --> 01:38:03,600
การจัดการ

2226
01:38:03,600 --> 01:38:07,160
>> ภาพใหม่ว่ามันคืออะไรในขณะนี้หลังจาก
การปรับปรุงที่ชนิดของอีกมุมมองหนึ่ง

2227
01:38:07,160 --> 01:38:07,660
คุณสามารถได้รับ.

2228
01:38:07,660 --> 01:38:09,660
คุณจะได้รับทั้งภาพเก่าและใหม่

2229
01:38:09,660 --> 01:38:10,660
บางทีฉันอาจจะต้องการให้พวกเขาทั้งสอง

2230
01:38:10,660 --> 01:38:11,790
ฉันต้องการที่จะเห็นสิ่งที่มันเป็น

2231
01:38:11,790 --> 01:38:13,290
ฉันต้องการที่จะเห็นสิ่งที่มันเปลี่ยนไป

2232
01:38:13,290 --> 01:38:15,340
>> ฉันมีประเภทการปฏิบัติตาม
ของกระบวนการที่ทำงาน

2233
01:38:15,340 --> 01:38:17,430
จะต้องมีการตรวจสอบว่า
เมื่อสิ่งเหล่านี้มีการเปลี่ยนแปลง

2234
01:38:17,430 --> 01:38:21,840
ว่าพวกเขากำลังภายในขอบเขตที่กำหนด
หรือภายในพารามิเตอร์บางอย่าง

2235
01:38:21,840 --> 01:38:23,840
>> และแล้วบางทีฉันเท่านั้น
ต้องรู้ว่าอะไรเปลี่ยนแปลง

2236
01:38:23,840 --> 01:38:26,240
ฉันไม่สนใจสิ่งที่เปลี่ยนแปลงรายการ

2237
01:38:26,240 --> 01:38:28,580
ฉันไม่ต้องการที่จะต้องรู้ว่า
สิ่งที่เปลี่ยนแปลงคุณลักษณะ

2238
01:38:28,580 --> 01:38:30,882
ฉันเพียงต้องการที่จะรู้ว่า
รายการที่มีการสัมผัส

2239
01:38:30,882 --> 01:38:33,340
ดังนั้นเหล่านี้เป็นชนิดของมุมมอง
ที่คุณได้รับการปิดกระแส

2240
01:38:33,340 --> 01:38:35,960
และคุณสามารถโต้ตอบกับ

2241
01:38:35,960 --> 01:38:37,840
>> โปรแกรมประยุกต์ที่
กินกระแส

2242
01:38:37,840 --> 01:38:39,298
นี้เป็นชนิดของวิธีนี้ทำงาน

2243
01:38:39,298 --> 01:38:42,570
ลูกค้า DynamoDB ขอให้
ผลักดันข้อมูลไปยังตาราง

2244
01:38:42,570 --> 01:38:44,750
ลำธารปรับใช้กับสิ่งที่เราเรียกว่าเศษ

2245
01:38:44,750 --> 01:38:47,380
เศษเป็นสัดส่วน
อิสระของตาราง

2246
01:38:47,380 --> 01:38:50,660
พวกเขาไม่ได้เริ่มขึ้นอย่างสมบูรณ์
พาร์ทิชันของตารางของคุณ

2247
01:38:50,660 --> 01:38:52,540
และเหตุผลที่เป็น
เพราะพวกเขาบรรทัดขึ้น

2248
01:38:52,540 --> 01:38:55,430
ความจุในปัจจุบัน
ความจุของตาราง

2249
01:38:55,430 --> 01:38:57,600
>> พวกเขาในการปรับใช้ของพวกเขา
กลุ่มปรับตัวเองโดยอัตโนมัติ

2250
01:38:57,600 --> 01:39:00,800
และพวกเขาเริ่มที่จะหมุนออกขึ้นอยู่กับ
เกี่ยวกับวิธีการเขียนหลายคนที่กำลังจะมาใน

2251
01:39:00,800 --> 01:39:03,090
วิธีการหลาย reads-- จริงๆก็เขียน

2252
01:39:03,090 --> 01:39:05,820
ไม่มี reads-- แต่วิธีการที่เป็น
เขียนหลายคนที่มีมาใน

2253
01:39:05,820 --> 01:39:08,200
>> และจากนั้นที่ด้านหลัง
ท้ายนี้เรามีสิ่งที่เรา

2254
01:39:08,200 --> 01:39:11,390
เรียก KCL หรือ Kinesis ไคลเอ็นต์ห้องสมุด

2255
01:39:11,390 --> 01:39:19,190
kinesis ข้อมูลสตรีม
เทคโนโลยีการประมวลผลจาก Amazon

2256
01:39:19,190 --> 01:39:22,040
และลำธารถูกสร้างขึ้นบนที่

2257
01:39:22,040 --> 01:39:25,670
>> ดังนั้นคุณใช้ KCL ที่เปิดใช้งาน
การประยุกต์ใช้ในการอ่านกระแส

2258
01:39:25,670 --> 01:39:28,752
ห้องสมุดไคลเอ็นต์ Kinesis จริง
การบริหารจัดการแรงงานสำหรับคุณ

2259
01:39:28,752 --> 01:39:30,460
และก็ยังไม่บาง
สิ่งที่น่าสนใจ.

2260
01:39:30,460 --> 01:39:35,630
มันจะสร้างตารางบางขึ้น
ในตาราง DynamoDB ของคุณ

2261
01:39:35,630 --> 01:39:38,410
เพื่อติดตามรายการ
ได้รับการประมวลผล

2262
01:39:38,410 --> 01:39:41,190
ดังนั้นวิธีนี้ถ้ามันตกกลับถ้า
มันตกซ้ำมาและได้รับ

2263
01:39:41,190 --> 01:39:45,570
กลับยืนขึ้นก็สามารถตรวจสอบที่
มันเป็นในการประมวลผลสตรีม

2264
01:39:45,570 --> 01:39:48,360
>> นั่นเป็นสิ่งสำคัญมากเมื่อ
คุณกำลังพูดถึงการจำลองแบบ

2265
01:39:48,360 --> 01:39:50,350
ฉันต้องการที่จะรู้ว่าสิ่งที่
ข้อมูลที่ถูกรับการประมวลผล

2266
01:39:50,350 --> 01:39:52,810
และข้อมูลที่ยังไม่ได้รับการประมวลผล

2267
01:39:52,810 --> 01:39:57,380
ดังนั้นห้องสมุด KCL สำหรับลำธารจะ
ให้คุณมากของการทำงานว่า

2268
01:39:57,380 --> 01:39:58,990
มันต้องใช้เวลาดูแลทุกทำความสะอาด

2269
01:39:58,990 --> 01:40:01,140
มันยืนขึ้นสำหรับคนงานทุกชิ้นส่วน

2270
01:40:01,140 --> 01:40:04,620
มันจะสร้างตารางการบริหาร
สำหรับทุกชิ้นส่วนสำหรับทุกคนงาน

2271
01:40:04,620 --> 01:40:07,560
และเป็นผู้ที่ไฟไหม้คนงาน
พวกเขารักษาตารางเหล่านั้น

2272
01:40:07,560 --> 01:40:10,510
เพื่อให้คุณทราบบันทึกนี้
ได้อ่านและประมวลผล

2273
01:40:10,510 --> 01:40:13,850
และแล้ววิธีการที่ถ้ากระบวนการ
ตายและกลับมาออนไลน์

2274
01:40:13,850 --> 01:40:17,940
ก็สามารถดำเนินการที่เหมาะสมที่จะเอาออก

2275
01:40:17,940 --> 01:40:20,850
>> ดังนั้นเราจึงใช้นี้
การจำลองแบบข้ามภูมิภาค

2276
01:40:20,850 --> 01:40:24,680
จำนวนมากของลูกค้าที่มีความจำเป็นที่จะต้อง
ย้ายข้อมูลหรือบางส่วนของตารางข้อมูลของพวกเขา

2277
01:40:24,680 --> 01:40:25,920
รอบภูมิภาคท​​ี่แตกต่างกัน

2278
01:40:25,920 --> 01:40:29,230
มีเก้าภูมิภาคเป็น
ทั่วทุกมุมโลก.

2279
01:40:29,230 --> 01:40:32,100
ดังนั้นอาจจะมีผม need--
อาจจะมีผู้ใช้ในเอเชียผู้ใช้

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
ดังนั้นเมื่อเขาได้รับออกจากเครื่องบินที่เขามี
เป็นประสบการณ์ที่ดีที่จะใช้ app มือถือของเขา

2285
01:40:49,340 --> 01:40:52,360
>> คุณสามารถใช้ข้ามภูมิภาค
ห้องสมุดจำลองแบบการทำเช่นนี้

2286
01:40:52,360 --> 01:40:55,730
โดยทั่วไปเรามี
ให้สองเทคโนโลยี

2287
01:40:55,730 --> 01:40:59,400
เป็นหนึ่งในโปรแกรมประยุกต์คอนโซลที่คุณสามารถ
ลุกขึ้นยืนในกรณี EC2 ของคุณเอง

2288
01:40:59,400 --> 01:41:01,240
มันทำงานการจำลองแบบบริสุทธิ์

2289
01:41:01,240 --> 01:41:02,720
แล้วเราให้คุณห้องสมุด

2290
01:41:02,720 --> 01:41:06,070
ห้องสมุดที่คุณสามารถใช้เพื่อสร้าง
ใบสมัครของคุณเองหากคุณ

2291
01:41:06,070 --> 01:41:10,740
ต้องการที่จะทำสิ่งที่บ้ากับ data--
กรองซ้ำเพียงส่วนหนึ่งของมัน

2292
01:41:10,740 --> 01:41:14,120
หมุนข้อมูลเคลื่อนย้ายไปเป็น
ตารางที่แตกต่างกันดังนั้นและอื่น ๆ

2293
01:41:14,120 --> 01:41:18,700

2294
01:41:18,700 --> 01:41:20,520
เพื่อให้เป็นชนิดของสิ่งที่ดูเหมือนว่า

2295
01:41:20,520 --> 01:41:23,690
>> DynamoDB Streams สามารถ
การประมวลผลโดยสิ่งที่เราเรียกแลมบ์ดา

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
ยอมรับความผิดแบบ real-time
รวมที่ปรับขนาดได้ในขณะนี้

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
เพื่อ Redshift อื่น ๆ
การวิเคราะห์การตรวจสอบหรือการใช้งาน

2349
01:43:48,820 --> 01:43:51,990
MapReduce ยืดหยุ่นในการทำงาน
เวลาจริงรวมสตรีมมิ่งออก

2350
01:43:51,990 --> 01:43:53,180
ของข้อมูลที่

2351
01:43:53,180 --> 01:43:55,480
>> ดังนั้นเหล่านี้เป็นสิ่งที่เรา
ยังไม่ได้พูดคุยเกี่ยวกับมาก

2352
01:43:55,480 --> 01:43:57,375
แต่พวกเขากำลังเพิ่มเติม
เทคโนโลยีที่มา

2353
01:43:57,375 --> 01:44:00,310
ที่จะแบกรับเมื่อคุณกำลังมอง
ที่เหล่านี้ประเภทของสถ​​านการณ์

2354
01:44:00,310 --> 01:44:03,160
>> สิทธิทั้งหมดเพื่อให้เป็นเรื่องของ
การวิเคราะห์ด้วย DynamoDB ลำธาร

2355
01:44:03,160 --> 01:44:05,340
คุณสามารถเก็บ de-ล่อ
ข้อมูลทำทุกชนิด

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
การประยุกต์ใช้งานสร้างขึ้นโดยใช้ไฟฟ้ารวม
แลมบ์ดา Ela​​stiCache, 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
คือพวกเขาดึงลงการรักษาความปลอดภัย
แบบสำรวจ HTML จาก S3

2378
01:45:18,020 --> 01:45:18,980
มีเซิร์ฟเวอร์ไม่ได้

2379
01:45:18,980 --> 01:45:20,600
นี่เป็นเพียงวัตถุ S3

2380
01:45:20,600 --> 01:45:22,770
>> รูปแบบที่เกิดขึ้น
โหลดลงในเบราว์เซอร์

2381
01:45:22,770 --> 01:45:24,240
ก็มีหัวใจ

2382
01:45:24,240 --> 01:45:30,160
มันมีความซับซ้อน JavaScript
ที่จะทำงาน

2383
01:45:30,160 --> 01:45:33,557
ดังนั้นจึงเป็นแอพลิเคชันที่อุดมสมบูรณ์มาก
ที่ทำงานอยู่ในเบราว์เซอร์ของลูกค้า

2384
01:45:33,557 --> 01:45:36,390
พวกเขาไม่ได้รู้ว่าพวกเขาไม่ได้
มีปฏิสัมพันธ์กับเซิร์ฟเวอร์ปลายด้านหลัง

2385
01:45:36,390 --> 01:45:38,220
ณ จุดนี้มันเป็นเบราว์เซอร์

2386
01:45:38,220 --> 01:45:41,780
>> พวกเขาเผยแพร่ผลกับสิ่งที่
ที่เราเรียกว่าเกตเวย์ Amazon API

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
>> เพื่อให้การดำเนินการโพสต์ของฉันคือ
ที่เกิดขึ้นกับเซิร์ฟเวอร์ไม่

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
และฉันโพสต์ผ่านเอพีไอ
ประตูสู่ฟังก์ชั่นแลมบ์ดา

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 Houlihan: แน่นอน

2433
01:47:46,823 --> 01:47:49,190
เพราะเช่นเซิร์ฟเวอร์ที่
จะต้องเป็น 7/24

2434
01:47:49,190 --> 01:47:51,954
มันจะต้องมีให้บริการสำหรับ
ใครสักคนที่จะตอบสนอง

2435
01:47:51,954 --> 01:47:52,620
ดีเดาอะไร

2436
01:47:52,620 --> 01:47:55,410
S3 ใช้ได้ 7/24

2437
01:47:55,410 --> 01:47:57,100
S3 มักจะตอบสนอง

2438
01:47:57,100 --> 01:47:59,320
และ S3 เป็นอย่างดีมาก
ที่แสดงถึงวัตถุ

2439
01:47:59,320 --> 01:48:02,590
วัตถุเหล่านั้นสามารถเป็นไฟล์ HTML หรือ
ไฟล์ JavaScript หรือสิ่งที่คุณต้องการ

2440
01:48:02,590 --> 01:48:07,430
คุณสามารถเรียกใช้งานเว็บที่อุดมสมบูรณ์มาก
ออกจากถัง S3 และคนทำ

2441
01:48:07,430 --> 01:48:10,160
>> และเพื่อให้เป็นความคิดที่นี่
คือการได้รับออกไปจากทาง

2442
01:48:10,160 --> 01:48:11,270
เราใช้ในการคิดเกี่ยวกับมัน

2443
01:48:11,270 --> 01:48:14,270
เราทุกคนเคยคิดว่าใน
แง่ของเซิร์ฟเวอร์และโฮสต์

2444
01:48:14,270 --> 01:48:16,580
มันไม่เกี่ยวกับที่อีกต่อไป

2445
01:48:16,580 --> 01:48:19,310
มันเป็นเรื่องของโครงสร้างพื้นฐานที่เป็นรหัส

2446
01:48:19,310 --> 01:48:22,470
การปรับใช้รหัสไปยังเมฆและ
ให้เรียกใช้งานระบบคลาวด์สำหรับคุณ

2447
01:48:22,470 --> 01:48:24,980
และนั่นคือสิ่ง AWS พยายามที่จะทำ

2448
01:48:24,980 --> 01:48:29,690
>> ผู้ชม: ดังนั้นกล่องทองของคุณที่อยู่ตรงกลาง
ของเกตเวย์ API เป็นเซิร์ฟเวอร์ไม่เหมือน

2449
01:48:29,690 --> 01:48:30,576
แต่แทนที่จะเป็น just--

2450
01:48:30,576 --> 01:48:32,850
>> RICK Houlihan: คุณสามารถคิด
มันเป็นเซิร์ฟเวอร์ซุ้ม

2451
01:48:32,850 --> 01:48:38,040
ทั้งหมดก็คือมันจะใช้เวลาของ HTTP
และขอแผนที่ไปยังกระบวนการอื่น

2452
01:48:38,040 --> 01:48:39,192
นั่นคือทั้งหมดที่มันไม่

2453
01:48:39,192 --> 01:48:41,525
และในกรณีนี้เรากำลังทำแผนที่
ไปยังฟังก์ชั่นแลมบ์ดา

2454
01:48:41,525 --> 01:48:44,119

2455
01:48:44,119 --> 01:48:45,410
สิทธิทั้งหมดดังนั้นนั่นคือทั้งหมดที่ผมได้รับ

2456
01:48:45,410 --> 01:48:46,190
ขอบคุณมาก.

2457
01:48:46,190 --> 01:48:46,800
ฉันรู้สึกทราบซึ้ง.

2458
01:48:46,800 --> 01:48:48,100
ฉันรู้ว่าเราต้องการนิด ๆ หน่อย ๆ เมื่อเวลาผ่านไป

2459
01:48:48,100 --> 01:48:49,980
และหวังว่าพวกคุณได้
นิด ๆ หน่อย ๆ ของข้อมูล

2460
01:48:49,980 --> 01:48:51,410
ที่คุณสามารถนำมาใช้ในวันนี้

2461
01:48:51,410 --> 01:48:53,520
และฉันต้องขออภัยถ้าผมไป
มากกว่าบางส่วนของหัวของคุณ

2462
01:48:53,520 --> 01:48:56,697
แต่มีจำนวนมากที่ดีของ
ความรู้พื้นฐานขั้นพื้นฐาน

2463
01:48:56,697 --> 01:48:58,280
ที่ผมคิดว่าเป็นที่มีคุณค่ามากสำหรับคุณ

2464
01:48:58,280 --> 01:48:59,825
ดังนั้นขอขอบคุณสำหรับการมีฉัน

2465
01:48:59,825 --> 01:49:00,325
[APPLAUSE]

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 Houlihan: โอ้ idempotent?

2471
01:49:10,480 --> 01:49:11,800
วิธีค่าที่จะเปลี่ยน?

2472
01:49:11,800 --> 01:49:15,180
ดีเพราะถ้าฉันไม่ได้ทำงาน
มันไปตลอดทางจนถึงท้ายที่สุด

2473
01:49:15,180 --> 01:49:19,770
แล้วผมไม่ทราบว่าสิ่งที่เปลี่ยนแปลง
ได้ทำในไมล์สุดท้าย

2474
01:49:19,770 --> 01:49:22,144
มันไม่ได้เป็นไปได้
ข้อมูลเช่นเดียวกับสิ่งที่ฉันเห็น

2475
01:49:22,144 --> 01:49:24,560
ผู้ชม: โอ้ดังนั้นคุณก็
ไม่ได้รับการป้อนข้อมูลทั้งหมด

2476
01:49:24,560 --> 01:49:24,770
RICK Houlihan: ขวา

2477
01:49:24,770 --> 01:49:26,895
คุณต้องไปจากจุดเริ่มต้น
ถึงจุดสิ้นสุดแล้วมัน

2478
01:49:26,895 --> 01:49:29,280
จะเป็นสถานะที่สอดคล้องกัน

2479
01:49:29,280 --> 01:49:31,520
เย็น.

2480
01:49:31,520 --> 01:49:35,907
>> ผู้ชม: ดังนั้นคุณแสดงให้เราเห็น DynamoDB
สามารถทำเอกสารหรือค่าคีย์

2481
01:49:35,907 --> 01:49:38,740
และเราใช้เวลามากบน
ค่าคีย์ที่มีกัญชาและวิธีการที่

2482
01:49:38,740 --> 01:49:40,005
ที่จะพลิกไปรอบ ๆ

2483
01:49:40,005 --> 01:49:43,255
เมื่อคุณมองไปที่ตารางเหล่านั้นก็คือว่า
หลังออกจากวิธีการที่เอกสารหรือไม่

2484
01:49:43,255 --> 01:49:44,600
>> RICK Houlihan: ฉันจะไม่
บอกว่าปล่อยให้มันอยู่เบื้องหลัง

2485
01:49:44,600 --> 01:49:45,855
>> ผู้ชม: พวกเขาถูกแยกออกจาก the--

2486
01:49:45,855 --> 01:49:49,140
>> RICK Houlihan: ด้วยเอกสาร
วิธีการพิมพ์เอกสารใน DynamoDB

2487
01:49:49,140 --> 01:49:50,880
เป็นเพียงคิดว่าเป็นแอตทริบิวต์อื่น

2488
01:49:50,880 --> 01:49:53,560
มันเป็นแอตทริบิวต์ที่ประกอบด้วย
โครงสร้างข้อมูลแบบลำดับชั้น

2489
01:49:53,560 --> 01:49:56,980
และจากนั้นในคำสั่งที่
คุณสามารถใช้คุณสมบัติ

2490
01:49:56,980 --> 01:49:59,480
ของวัตถุที่ใช้สัญกรณ์วัตถุ

2491
01:49:59,480 --> 01:50:03,562
ดังนั้นผมจึงสามารถกรองซ้อนกัน
ทรัพย์สินของเอกสาร JSON

2492
01:50:03,562 --> 01:50:05,520
ผู้ชม: ดังนั้นทุกครั้งที่ผมใด ๆ
วิธีการทำเอกสาร

2493
01:50:05,520 --> 01:50:07,906
จัดเรียงของฉันสามารถมาถึงที่ tabular--

2494
01:50:07,906 --> 01:50:08,780
ผู้ชม: แน่นอน

2495
01:50:08,780 --> 01:50:09,800
ผู้ชม: --indexes และ
สิ่งที่คุณเพียงแค่พูดคุยเกี่ยวกับ

2496
01:50:09,800 --> 01:50:11,280
RICK Houlihan: ใช่ที่
ดัชนีและสิ่งที่

2497
01:50:11,280 --> 01:50:13,363
เมื่อคุณต้องการที่จะสร้างดัชนี
คุณสมบัติของ JSON ที่

2498
01:50:13,363 --> 01:50:18,230
วิธีการที่เราจะต้องทำอย่างนั้นคือถ้า
คุณใส่วัตถุ JSON หรือเอกสาร

2499
01:50:18,230 --> 01:50:20,780
เข้าไดนาโมคุณจะใช้กระแส

2500
01:50:20,780 --> 01:50:22,400
ลำธารจะอ่านอินพุต

2501
01:50:22,400 --> 01:50:24,340
คุณจะได้รับที่ JSON
วัตถุและคุณจะบอกว่าตกลง

2502
01:50:24,340 --> 01:50:26,030
สถานที่ให้บริการสิ่งที่ฉันต้องการที่จะสร้างดัชนี?

2503
01:50:26,030 --> 01:50:28,717
>> คุณสามารถสร้างตารางอนุพันธ์

2504
01:50:28,717 --> 01:50:30,300
ตอนนี้ที่วิธีการทำงานในขณะนี้

2505
01:50:30,300 --> 01:50:32,650
เราจะไม่ยอมให้คุณดัชนี
คุณสมบัติเหล่านั้นได้โดยตรง

2506
01:50:32,650 --> 01:50:33,520
>> ผู้ชม: Tabularizing เอกสารของคุณ

2507
01:50:33,520 --> 01:50:36,230
>> RICK Houlihan: ว่าแฟบ
มัน tabularizing มันว่า

2508
01:50:36,230 --> 01:50:37,415
นั่นคือสิ่งที่คุณทำกับมัน

2509
01:50:37,415 --> 01:50:37,860
>> ผู้ชม: ขอบคุณ

2510
01:50:37,860 --> 01:50:39,609
>> RICK Houlihan: ครับ
อย่างขอบคุณ

2511
01:50:39,609 --> 01:50:42,240
ผู้ชม: ดังนั้นจึงเป็นชนิดของ
Mongo ตรงตาม Redis classifers

2512
01:50:42,240 --> 01:50:43,990
>> RICK Houlihan: ใช่
มันมากเช่นนั้น

2513
01:50:43,990 --> 01:50:45,940
นั่นเป็นคำอธิบายที่ดีสำหรับมัน

2514
01:50:45,940 --> 01:50:47,490
เย็น.

2515
01:50:47,490 --> 01:50:49,102