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
ჩემი სახელი არის Rick 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
მე უკვე Cloud ვირტუალიზაციის
დაახლოებით 20 წლის განმავლობაში.

12
00:00:30,000 --> 00:00:33,460
ასე რომ სანამ Cloud იყო Cloud,
ჩვენ მოვუწოდებთ მას კომუნალური computing.

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
მაქვს რვა პატენტების Cloud სისტემები
ვირტუალიზაციის, მიკროპროცესორული დიზაინი,

19
00:00:51,620 --> 00:00:54,440
კომპლექსური ღონისძიება დამუშავება,
და სხვა სფეროებში, ასევე.

20
00:00:54,440 --> 00:00:58,290
>> ასე რომ, ამ დღეებში, მე ფოკუსირება ძირითადად NoSQL
ტექნოლოგიები და მომავალ თაობას

21
00:00:58,290 --> 00:00:59,450
მონაცემთა ბაზაში.

22
00:00:59,450 --> 00:01:03,370
და რომ ზოგადად, რაც მე ვაპირებ
უნდა იყოს აქ საუბარი თქვენ დღეს.

23
00:01:03,370 --> 00:01:06,030
ასე რომ, რას შეიძლება ველოდოთ
ამ სხდომაზე,

24
00:01:06,030 --> 00:01:08,254
ჩვენ გაიაროს მოკლე
ისტორია მონაცემთა დამუშავება.

25
00:01:08,254 --> 00:01:10,420
ის ყოველთვის სასარგებლოა
მესმის, სადაც ჩვენ მოვიდა

26
00:01:10,420 --> 00:01:12,400
და რატომ ვართ აქ ვართ.

27
00:01:12,400 --> 00:01:15,600
და ჩვენ ვსაუბრობთ პატარა
ცოტა შესახებ NoSQL ტექნიკა

28
00:01:15,600 --> 00:01:17,500
საწყისი ფუნდამენტური თვალსაზრისით.

29
00:01:17,500 --> 00:01:19,870
>> ჩვენ შეღწევას ზოგიერთი
DynamoDB შინაგანი.

30
00:01:19,870 --> 00:01:24,350
DynamoDB არის AWS ის გემოს.

31
00:01:24,350 --> 00:01:27,340
ეს სრულად მოახერხა და
უმასპინძლა NoSQL გადაწყვეტა.

32
00:01:27,340 --> 00:01:32,420
და ჩვენ გაიგო ცოტა შესახებ მაგიდა
სტრუქტურა, APIs, მონაცემთა ტიპები, ინდექსები,

33
00:01:32,420 --> 00:01:35,177
და ზოგიერთი შინაგანი
რომ DynamoDB ტექნოლოგია.

34
00:01:35,177 --> 00:01:37,760
ჩვენ შეღწევას ზოგიერთი დიზაინი
ნიმუშების და საუკეთესო პრაქტიკის.

35
00:01:37,760 --> 00:01:39,968
ჩვენ ვსაუბრობთ, თუ როგორ
გამოიყენოს ეს ტექნოლოგია რამდენიმე

36
00:01:39,968 --> 00:01:41,430
დღევანდელი პროგრამა.

37
00:01:41,430 --> 00:01:44,820
და მაშინ ჩვენ გაიგო ცოტა
ევოლუციის ან წარმოქმნას

38
00:01:44,820 --> 00:01:48,980
ახალი პარადიგმის პროგრამირებაში
მოუწოდა ღონისძიება ორიენტირებული პროგრამები

39
00:01:48,980 --> 00:01:51,580
და როგორ DynamoDB უკრავს, რომ ისევე.

40
00:01:51,580 --> 00:01:54,690
და ჩვენ დავტოვებთ თქვენ ცოტა
მინიშნება არქიტექტურა დისკუსია

41
00:01:54,690 --> 00:01:59,540
ასე რომ ჩვენ შეგვიძლია ვისაუბროთ ზოგიერთ
გზები შეგიძლიათ გამოიყენოთ DynamoDB.

42
00:01:59,540 --> 00:02:04,116
>> ასე რომ, პირველი off-- ეს არის საკითხი,
მე მესმის ბევრი არის, რა არის მონაცემთა ბაზაში.

43
00:02:04,116 --> 00:02:06,240
ბევრი ადამიანი ფიქრობს, რომ ისინი
იცით, რა მონაცემთა ბაზა.

44
00:02:06,240 --> 00:02:08,360
თუ თქვენ Google, დაინახავთ, ეს.

45
00:02:08,360 --> 00:02:11,675
ეს არის სტრუქტურირებული კომპლექტი მონაცემები გაიმართა
კომპიუტერი, განსაკუთრებით ერთი, რომ

46
00:02:11,675 --> 00:02:13,600
არის ხელმისაწვდომი სხვადასხვა გზები.

47
00:02:13,600 --> 00:02:16,992
მე ვფიქრობ, რომ კარგი
განმარტება თანამედროვე მონაცემთა ბაზაში.

48
00:02:16,992 --> 00:02:19,450
მაგრამ მე არ მომწონს, რადგან
ეს იმას ნიშნავს, რამდენიმე რამ.

49
00:02:19,450 --> 00:02:20,935
ეს იმას ნიშნავს, სტრუქტურა.

50
00:02:20,935 --> 00:02:23,120
და ეს იმას ნიშნავს, რომ ის კომპიუტერი.

51
00:02:23,120 --> 00:02:25,750
და მონაცემთა ბაზების არ
ყოველთვის არსებობს კომპიუტერი.

52
00:02:25,750 --> 00:02:28,020
მონაცემთა ბაზა რეალურად არსებობდა მრავალი გზა.

53
00:02:28,020 --> 00:02:32,000
>> ასე რომ, უკეთესი განსაზღვრება
მონაცემთა ბაზა რაღაც მსგავსი.

54
00:02:32,000 --> 00:02:34,786
მონაცემთა ბაზა არის ორგანიზებული
მექანიზმი შენახვის, მართვისა,

55
00:02:34,786 --> 00:02:35,910
და ძებნისათვის ინფორმაცია.

56
00:02:35,910 --> 00:02:36,868
ეს არის საწყისი About.com.

57
00:02:36,868 --> 00:02:42,080
ასე რომ, მე მიყვარს ეს, რადგან ეს მართლაც მოლაპარაკებები
შესახებ მონაცემთა ბაზაში მყოფი საცავი,

58
00:02:42,080 --> 00:02:44,800
საცავი
ინფორმაცია, არ არის აუცილებელი

59
00:02:44,800 --> 00:02:46,780
რაღაც რომ ზის კომპიუტერი.

60
00:02:46,780 --> 00:02:49,290
და მთელი ისტორიის მანძილზე, ჩვენ
ყოველთვის არ ჰქონდა კომპიუტერი.

61
00:02:49,290 --> 00:02:52,110
>> ახლა კი, თუ მე ვთხოვ საშუალო
დეველოპერი დღეს რა არის

62
00:02:52,110 --> 00:02:54,770
მონაცემთა ბაზა, რომ პასუხი მივიღო.

63
00:02:54,770 --> 00:02:56,070
სადღაც შეგიძლიათ გამყარებაში პერსონალი.

64
00:02:56,070 --> 00:02:56,670
მარჯვენა?

65
00:02:56,670 --> 00:02:58,725
და ეს სიმართლეა.

66
00:02:58,725 --> 00:02:59,600
მაგრამ ეს ძალიან სამწუხაროა.

67
00:02:59,600 --> 00:03:02,700
იმის გამო, რომ მონაცემთა ბაზაში მართლაც
საფუძველი თანამედროვე 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
და განაცხადა, რაღაც ხაზები
ეს არის ძალიან პოეტური განცხადებაში.

82
00:03:43,020 --> 00:03:46,590
მისი თქმით, ეს ისტორია
მონაცემთა დამუშავება

83
00:03:46,590 --> 00:03:49,350
სრული მაღალი watermarks
მონაცემთა სიუხვით.

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
მაღალი watermark მონაცემების ზეწოლა.

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
ჩვენ დავიწყეთ განვითარებადი
სისტემის ledger საბუღალტრო.

121
00:05:08,000 --> 00:05:12,200
და რომ სისტემა ledger დათვლა
გაიქცა სამყარო საუკუნეების განმავლობაში,

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
In 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
და მან გამოიგონა ერთეული ჩანაწერი punch
ბარათები, Punch ბარათის წამკითხველი, Punch ბარათის

140
00:05:52,640 --> 00:05:58,420
tabulator და შედარებაზე
მექანიზმები ამ ტექნოლოგიის.

141
00:05:58,420 --> 00:06:01,860
და რომ კომპანია, რომ იქმნება
დრო, ერთად რამდენიმე სხვები,

142
00:06:01,860 --> 00:06:05,450
გახდა ერთ-ერთი საყრდენი ერთი
მცირე კომპანია ვიცით, დღეს მოუწოდა IBM.

143
00:06:05,450 --> 00:06:08,417
>> ასე რომ, IBM თავდაპირველად იყო
მონაცემთა ბაზის ბიზნესი.

144
00:06:08,417 --> 00:06:09,750
და ეს მართლაც, რა გააკეთეს.

145
00:06:09,750 --> 00:06:11,110
მათ გააკეთეს მონაცემების დამუშავება.

146
00:06:11,110 --> 00:06:15,400
>> როგორც ასე გავრცელებით punch
ბარათები, გენიალურად მექანიზმები

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
სადაც ჩვენ გვაქვს Punch ბარათის deck.

151
00:06:26,970 --> 00:06:28,720
და ვინმეს აყვანა
პატარა screwdriver

152
00:06:28,720 --> 00:06:31,400
და sticking მეშვეობით
სლოტი და მოხსნას ეს მდე

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
და ეს იყო გავრცელების
ამ punch ბარათები

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
Player როიალები უკან
თავის მხრივ, საუკუნის

163
00:06:57,855 --> 00:07:02,100
უნდა გამოვიყენოთ ქაღალდი რგოლების ერთად slots
ვუთხრა ის, რომელიც ღილაკები ითამაშოს.

164
00:07:02,100 --> 00:07:05,380
ასე რომ, ტექნიკა ადაპტირებული
საბოლოოდ შესანახად ციფრული მონაცემები,

165
00:07:05,380 --> 00:07:08,070
იმიტომ, რომ ისინი ვერ დააყენა, რომ მონაცემები
გადატანა იმ ქაღალდის ლენტი რგოლების.

166
00:07:08,070 --> 00:07:10,870
>> ახლა, როგორც შედეგი, მონაცემთა
იყო რეალურად როგორ

167
00:07:10,870 --> 00:07:14,960
თქვენ ამ მონაცემებს პირდაპირ
დამოკიდებული, თუ როგორ ინახება ეს.

168
00:07:14,960 --> 00:07:17,825
ასე რომ, თუ დააყენა მონაცემები ლენტი,
მე მქონდა წვდომა მონაცემების ხაზოვანი.

169
00:07:17,825 --> 00:07:20,475
მე უნდა გააფართოვოს მთელი
ფირზე ყველა მონაცემების.

170
00:07:20,475 --> 00:07:22,600
თუ მე ზუსტად მონაცემების punch
ბარათები, მე შეიძლება თქვათ ეს

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
უნდა საცავი, რომ დაამარცხა
sprawl მონაცემები მასშტაბით ფაილი

191
00:08:27,940 --> 00:08:29,540
სისტემა, რომელიც ჩვენ ავაშენეთ. მარჯვენა?

192
00:08:29,540 --> 00:08:34,270
ძალიან ბევრი მონაცემები ნაწილდება ძალიან ბევრი
ადგილებში, დე-დუბლირებას მონაცემები,

193
00:08:34,270 --> 00:08:37,120
და ღირებულება შენახვის იყო უზარმაზარი.

194
00:08:37,120 --> 00:08:43,760
>> იმ 70 ყველაზე ძვირადღირებული რესურსი
რომ კომპიუტერი იყო, შენახვა.

195
00:08:43,760 --> 00:08:46,200
პროცესორი იყო
განიხილება, როგორც ფიქსირებული ღირებულება.

196
00:08:46,200 --> 00:08:49,030
როცა ყიდვა ყუთი,
პროცესორის აკეთებს გარკვეული სამუშაო.

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
მაგრამ რა მე ვერ პოულობენ იაფი compute.

207
00:09:17,190 --> 00:09:20,700
>> ასე რომ, ევოლუცია დღეს
ტექნოლოგია, მონაცემთა ბაზის ტექნოლოგია,

208
00:09:20,700 --> 00:09:23,050
მართლაც ორიენტირებული გარშემო
მონაცემთა ბაზების განაწილებას

209
00:09:23,050 --> 00:09:26,960
რომ არ განიცდიან
იგივე ტიპის მასშტაბის

210
00:09:26,960 --> 00:09:29,240
შეზღუდვები რელაციური მონაცემთა ბაზები.

211
00:09:29,240 --> 00:09:32,080
ჩვენ გაიგო ცოტა შესახებ
რა, რომ ფაქტიურად ნიშნავს.

212
00:09:32,080 --> 00:09:34,760
>> მაგრამ ერთ-ერთი მიზეზი და
მძღოლი უკან ამას ჩვენ

213
00:09:34,760 --> 00:09:38,290
ისაუბრა მონაცემები ზეწოლა.

214
00:09:38,290 --> 00:09:41,920
მონაცემთა ზეწოლა არის რაღაც
რომელიც მართავს ინოვაცია.

215
00:09:41,920 --> 00:09:44,610
და თუ დავაკვირდებით
ბოლო ხუთი წლის განმავლობაში,

216
00:09:44,610 --> 00:09:48,180
ეს არის სქემა, რა მონაცემები
დატვირთვის მასშტაბით ზოგადი საწარმო

217
00:09:48,180 --> 00:09:49,640
ჰგავს, რომ ბოლო ხუთი წლის განმავლობაში.

218
00:09:49,640 --> 00:09:52,570
>> და ზოგადი წესი thumb
ამ დღეებში თუ თქვენ წავიდეთ 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
განვითარებული Punch ბარათის,

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 წელს ერთ-ერთი
terabyte მონაცემების მართვის,

231
00:10:23,510 --> 00:10:27,080
დღეს ეს ნიშნავს, რომ ისინი
მართვის 6.5 petabytes მონაცემები.

232
00:10:27,080 --> 00:10:30,380
სწორედ 6500-ჯერ მეტი მონაცემები.

233
00:10:30,380 --> 00:10:31,200
და მე ეს ვიცი.

234
00:10:31,200 --> 00:10:33,292
ვმუშაობ ამ ბიზნესის ყოველდღე.

235
00:10:33,292 --> 00:10:35,000
ხუთი წლის წინ, მე
გაიგო, რომ კომპანიები

236
00:10:35,000 --> 00:10:38,260
ვინც გაიგო, რომ ჩემთვის, რა ტკივილი
ის არის, რომ მართოთ ტერაბყტეს მონაცემები.

237
00:10:38,260 --> 00:10:39,700
და ისინი გაიგო
ჩემთვის, თუ როგორ ვხედავთ

238
00:10:39,700 --> 00:10:41,825
რომ ეს არის ალბათ აპირებს
იყოს 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 petabytes მონაცემები.

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
>> ასე რომ, როგორც ჩანს, ყოველ inch ჩვენ გადაადგილება
გზას სამეცნიერო აღმოჩენების,

263
00:11:49,840 --> 00:11:54,620
ჩვენ ვამრავლებთ თანხის მონაცემები
რომ ჩვენ უნდა დავამუშავოთ exponentially

264
00:11:54,620 --> 00:11:59,920
როგორც ჩვენ uncover უფრო და უფრო და უფრო
შესახებ შიდა დამუშავებული ცხოვრების,

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-- რომ მართლაც მშენებლობა საქართველოს
რელატიური მონაცემთა ბაზა ეს ყველაფერი

274
00:12:28,600 --> 00:12:30,770
ოპტიმიზირებულია შენახვის.

275
00:12:30,770 --> 00:12:33,180
>> უკან '70s, კიდევ ერთხელ,
დისკზე არის ძვირი.

276
00:12:33,180 --> 00:12:36,990
უზრუნველყოფის exercise შენახვის
საწარმოში არის დაუსრულებელი.

277
00:12:36,990 --> 00:12:37,490
ვიცი.

278
00:12:37,490 --> 00:12:38,020
მე ცხოვრობდა.

279
00:12:38,020 --> 00:12:41,250
მე დავწერე შენახვის მძღოლებს ერთი
Enterprised superserver კომპანია

280
00:12:41,250 --> 00:12:42,470
უკან '90s.

281
00:12:42,470 --> 00:12:45,920
და ქვედა ხაზი არის ჯოუნსი სხვა
შენახვის მასივში იყო მხოლოდ ის, რომ

282
00:12:45,920 --> 00:12:47,600
მოხდა ყოველდღე საწარმო.

283
00:12:47,600 --> 00:12:49,030
და ეს არ შეუწყვეტია.

284
00:12:49,030 --> 00:12:52,690
მაღალი სიმკვრივის შენახვის, მოთხოვნა
მაღალი სიმკვრივის შენახვის,

285
00:12:52,690 --> 00:12:56,340
და უფრო ეფექტური შენახვის
devices-- ის არ შეუწყვეტია.

286
00:12:56,340 --> 00:13:00,160
>> და NoSQL დიდი ტექნოლოგია
იმიტომ, რომ ეს ნორმალიზებას მონაცემები.

287
00:13:00,160 --> 00:13:02,210
ეს დე-ეგზ მონაცემები.

288
00:13:02,210 --> 00:13:07,180
იგი აყენებს მონაცემები სტრუქტურა, რომელიც
აგნოსტიკოსია ყველა ხელმისაწვდომობის ნიმუში.

289
00:13:07,180 --> 00:13:11,600
მრავალჯერადი განაცხადების შეიძლება მოხვდა, რომ
SQL მონაცემთა ბაზაში, აწარმოებს ad hoc შეკითხვებს,

290
00:13:11,600 --> 00:13:15,950
და მიიღონ მონაცემები ფორმის, რომ ისინი
უნდა დამუშავებას მათი workloads.

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
იგი მხარს უჭერს ad hoc შეკითხვებს.

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
ისინი hitting კედლის ერთხელ.

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, მეორეს მხრივ,
უფრო ოპტიმიზირებულია compute.

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
>> მაგრამ იდეა აქ არის ის, რომ თქვენ შესანახად
თქვენი მონაცემები, როგორც ამ ობიექტის რაოდენობა.

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
ასე რომ, თუ ოპტიმიზაცია მონაცემები
შესანახად მხარდასაჭერად, რომ workflow,

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
Pick ორი.

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
Partition ტოლერანტობის საშუალებით
რომ სისტემა კარგად მუშაობს

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
ჩვენ ჰქონდეს კარგად, ის
მოდის ბევრი არომატს,

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
Node ამბობს, არ არის პრობლემა.

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-oh,

451
00:19:27,360 --> 00:19:28,870
იქ უკვე განახლება ორ მხარეს.

452
00:19:28,870 --> 00:19:30,370
რას ვაკეთებთ?

453
00:19:30,370 --> 00:19:33,210
და რას აკეთებს მაშინ არის
ისინი რაღაც, რომელიც

454
00:19:33,210 --> 00:19:36,080
მათ საშუალებას აძლევს მოგვარებას, რომ მონაცემები სახელმწიფო.

455
00:19:36,080 --> 00:19:39,000
და ჩვენ ვსაუბრობთ
რომ მომდევნო სქემა.

456
00:19:39,000 --> 00:19:40,000
>> რამ აღვნიშნო აქ.

457
00:19:40,000 --> 00:19:42,374
და მე არ ვაპირებ მისაღებად ძალიან
ბევრი შევიდა, რადგან ეს

458
00:19:42,374 --> 00:19:43,510
იღებს შევიდა ღრმა მონაცემების თეორია.

459
00:19:43,510 --> 00:19:46,670
მაგრამ არსებობს ოპერაციული
ფარგლებში, რომელიც

460
00:19:46,670 --> 00:19:50,680
ეშვება რელატიური სისტემა, რომელიც
საშუალებას იძლევა ჩემთვის უსაფრთხოდ მიიღოს განახლებები

461
00:19:50,680 --> 00:19:53,760
სხვადასხვა პირების მონაცემთა ბაზაში.

462
00:19:53,760 --> 00:19:58,320
და იმ სიახლეებზე მოხდება
ერთდროულად ან არ.

463
00:19:58,320 --> 00:20:00,500
ეს ეწოდება ACID ოპერაციების.

464
00:20:00,500 --> 00:20:01,000
კარგი?

465
00:20:01,000 --> 00:20:06,570
>> ACID გვაძლევს 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
ACID მდგრადობა ნიშნავს, რომ როდესაც
გარიგების კეთდება, მონაცემები კარგი.

475
00:20:34,450 --> 00:20:35,709
ჩემი ურთიერთობები ყველა კარგი.

476
00:20:35,709 --> 00:20:38,750
მე არ ვაპირებ წაშლა მშობელი row
და დატოვონ bunch of ობოლი ბავშვები

477
00:20:38,750 --> 00:20:40,970
ზოგიერთ სხვა მაგიდასთან.

478
00:20:40,970 --> 00:20:44,320
ეს ვერ მოხდება, თუ მე შეესაბამება
in მჟავა გარიგება.

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
ასე რომ, ეს concurrency
კონტროლის მონაცემთა ბაზაში.

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
იქნება იქ კი
თუ სისტემა crashes.

495
00:21:26,100 --> 00:21:29,230
როდესაც ეს სისტემა აღდგება, რომელიც
გარიგების რომელიც ჩადენილია

496
00:21:29,230 --> 00:21:30,480
რეალურად აპირებს იყოს იქ.

497
00:21:30,480 --> 00:21:33,130
ასე რომ, ეს გარანტიები
საქართველოს ACID ოპერაციების.

498
00:21:33,130 --> 00:21:35,470
ეს არის საკმაოდ ლამაზი გარანტიები
აქვს მონაცემთა ბაზა,

499
00:21:35,470 --> 00:21:36,870
მაგრამ ისინი, რომ ღირებულება.

500
00:21:36,870 --> 00:21:37,640
მარჯვენა?

501
00:21:37,640 --> 00:21:40,520
>> იმის გამო, რომ პრობლემა
ეს ჩარჩო არის

502
00:21:40,520 --> 00:21:44,540
თუ არ არის დანაყოფი მონაცემები
კომპლექტი, მე უნდა მიიღოს გადაწყვეტილება.

503
00:21:44,540 --> 00:21:48,000
მე ვაპირებ უნდა დაუშვას
განახლებები ერთ მხარეს ან მეორე.

504
00:21:48,000 --> 00:21:50,310
და თუ ეს მოხდება,
მაშინ მე აღარ აპირებს

505
00:21:50,310 --> 00:21:52,630
შეძლებს შეინარჩუნოს
ის მახასიათებლები.

506
00:21:52,630 --> 00:21:53,960
ისინი არ იქნება თანმიმდევრული.

507
00:21:53,960 --> 00:21:55,841
ისინი არ იქნება იზოლირებული.

508
00:21:55,841 --> 00:21:58,090
ეს არის სადაც ეს თანხიდან
ამისთვის რელატიური მონაცემთა ბაზა.

509
00:21:58,090 --> 00:22:01,360
ეს არის მიზეზი, რელატიური
მონაცემთა ბაზის მასშტაბის ვერტიკალურად.

510
00:22:01,360 --> 00:22:05,530
>> მეორეს მხრივ, ჩვენ გვაქვს
რასაც BASE ტექნოლოგია.

511
00:22:05,530 --> 00:22:07,291
და ეს არის თქვენი NoSQL მონაცემთა ბაზა.

512
00:22:07,291 --> 00:22:07,790
კარგი.

513
00:22:07,790 --> 00:22:10,180
ასე რომ, ჩვენ გვაქვს ჩვენი CP, AP ბაზაში.

514
00:22:10,180 --> 00:22:14,720
და ეს არის ის, რაც თქვენ მოვუწოდებთ ძირითადად
შესაძლებელია, რბილი სახელმწიფო, საბოლოოდ

515
00:22:14,720 --> 00:22:15,740
თანმიმდევრული.

516
00:22:15,740 --> 00:22:16,420
კარგი?

517
00:22:16,420 --> 00:22:19,690
>> ძირითადად არსებობს, რადგან
ისინი დანაყოფი ტოლერანტული.

518
00:22:19,690 --> 00:22:21,470
ისინი ყოველთვის იქნება
იქ, მაშინაც კი, თუ არსებობს

519
00:22:21,470 --> 00:22:23,053
ქსელის დანაყოფი შორის კვანძების.

520
00:22:23,053 --> 00:22:25,900
თუ მე ვერ გაიგო, რომ კვანძის, მე
აპირებს შეძლებს წაიკითხა მონაცემები.

521
00:22:25,900 --> 00:22:26,460
კარგი?

522
00:22:26,460 --> 00:22:30,810
მე შეიძლება ყოველთვის არ იყოს შეუძლია დაწეროს
მონაცემები, თუ მე ვარ თანმიმდევრული პლატფორმა.

523
00:22:30,810 --> 00:22:32,130
მაგრამ მე შეძლებთ წაიკითხოთ მონაცემები.

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

525
00:22:34,960 --> 00:22:38,010
>> რბილი სახელმწიფო მიუთითებს
რომ როდესაც წავიკითხე, რომ მონაცემები,

526
00:22:38,010 --> 00:22:40,790
ეს არ უნდა იყოს იგივე, რაც სხვა კვანძების.

527
00:22:40,790 --> 00:22:43,390
თუ უფლება გაიცა კვანძის
სხვაგან კასეტური

528
00:22:43,390 --> 00:22:46,650
და ეს არ გაიმეორა მთელს
კასეტური ჯერ, როცა წავიკითხე, რომ მონაცემები,

529
00:22:46,650 --> 00:22:48,680
რომ სახელმწიფო არ უნდა იყოს თანმიმდევრული.

530
00:22:48,680 --> 00:22:51,650
თუმცა, ეს იქნება
საბოლოოდ თანმიმდევრული,

531
00:22:51,650 --> 00:22:53,870
რაც იმას ნიშნავს, რომ როდესაც ჩაწერის
დამზადებულია სისტემა,

532
00:22:53,870 --> 00:22:56,480
იგი იმეორებს მასშტაბით კვანძების.

533
00:22:56,480 --> 00:22:59,095
და საბოლოოდ, რომ სახელმწიფო
იქნება შემოტანილი მიზნით,

534
00:22:59,095 --> 00:23:00,890
და ეს იქნება თანმიმდევრული სახელმწიფო.

535
00:23:00,890 --> 00:23:05,000
>> ახლა, CAP თეორემა ნამდვილად
თამაშობს მხოლოდ ერთი პირობით.

536
00:23:05,000 --> 00:23:08,700
ეს მდგომარეობა არის როცა ეს მოხდება.

537
00:23:08,700 --> 00:23:13,710
იმის გამო, რომ როდესაც ის მოქმედი
ნორმალურ რეჟიმში, არ არსებობს დანაყოფი,

538
00:23:13,710 --> 00:23:16,370
ყველაფერი თანმიმდევრული და ხელმისაწვდომი.

539
00:23:16,370 --> 00:23:19,990
თქვენ მხოლოდ ფიქრი CAP
როდესაც ჩვენ გვაქვს, რომ ეს დანაყოფი.

540
00:23:19,990 --> 00:23:21,260
ასე რომ, ეს ძალიან იშვიათია.

541
00:23:21,260 --> 00:23:25,360
მაგრამ, თუ როგორ სისტემა რეაგირებს, როდესაც ის
მოხდეს უკარნახოს რა ტიპის სისტემა

542
00:23:25,360 --> 00:23:26,750
ჩვენ საქმე გვაქვს.

543
00:23:26,750 --> 00:23:31,110
>> მოდით შევხედოთ რა
რომ ჰგავს for 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
>> ასე რომ, თუ ჩვენ რაღაც Cassandra.

553
00:23:50,040 --> 00:23:54,440
Cassandra იქნება სამაგისტრო
სამაგისტრო, მოდით დავწერ ნებისმიერი კვანძის.

554
00:23:54,440 --> 00:23:55,540
ასე რომ, რა ხდება?

555
00:23:55,540 --> 00:23:58,270
ასე რომ, მე ობიექტი
მონაცემთა ბაზა, რომელიც არსებობს ორ კვანძების.

556
00:23:58,270 --> 00:24:01,705
მოდით მოვუწოდებთ, რომ ობიექტი S.
ასე რომ, ჩვენ გვაქვს სახელმწიფო S.

557
00:24:01,705 --> 00:24:04,312
ჩვენ გვაქვს გარკვეული ოპერაციების
on S რომ მიმდინარეობს.

558
00:24:04,312 --> 00:24:06,270
Cassandra საშუალებას ჩემთვის
წერენ სხვადასხვა კვანძების.

559
00:24:06,270 --> 00:24:08,550
ასე ვთქვათ, მივიღებ
წერენ s ორ კვანძების.

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
ნაგულისხმები უკუგამოძახება და ეგ
resolver უმეტეს 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
მე შეიძლება ნაგავსაყრელი ეს ჩანაწერი, რომ მე
ჩაყარეს off შევიდა აღდგენის შესვლა

587
00:25:08,440 --> 00:25:11,670
ისე, რომ მომხმარებელს შეუძლია დაუბრუნდეს შემდეგ
და აცხადებენ, hey, იყო შეჯახება.

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
შეიძლება ითქვას, hey, მინდა
უნდა გამოასწოროს ეს მონაცემები.

594
00:25:26,730 --> 00:25:28,880
და მე შევეცდები და
შერწყმა ამ ორი ჩანაწერი.

595
00:25:28,880 --> 00:25:30,050
მაგრამ ეს თქვენზეა.

596
00:25:30,050 --> 00:25:32,880
მონაცემთა ბაზა არ იცის, თუ როგორ უნდა
გავაკეთოთ, რომ იყოს. ყველაზე დროის,

597
00:25:32,880 --> 00:25:34,850
ერთადერთი, რაც მონაცემთა ბაზა
იცის როგორ გააკეთოს ამბობენ,

598
00:25:34,850 --> 00:25:36,100
ეს იყო ბოლო ჩანაწერი.

599
00:25:36,100 --> 00:25:39,183
ეს არის ერთი, რომ აპირებს გაიმარჯვებს,
და ეს ღირებულება მე ვაპირებ დააყენა.

600
00:25:39,183 --> 00:25:41,490
მას შემდეგ, რაც დაყოფის აღდგენა
და რეპლიკაცია ხდება,

601
00:25:41,490 --> 00:25:43,930
ჩვენ გვაქვს ჩვენი სახელმწიფო, რომელიც
არის პრემიერ, რომელიც

602
00:25:43,930 --> 00:25:46,890
შერწყმა სახელმწიფო ყველა იმ ობიექტების.

603
00:25:46,890 --> 00:25:49,700
ასე რომ, 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,
და რომ 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-- ყველა მათ
აქვს არის root თვისებები.

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 ვიდეო ID.

649
00:27:24,040 --> 00:27:28,464
ახლა შემიძლია შექმნა შეკითხვის უერთდება
ვიდეოები მეშვეობით მსახიობი ვიდეო მსახიობები,

650
00:27:28,464 --> 00:27:31,130
და ეს მაძლევს ლამაზი სია
ყველა ფილმები და მსახიობები

651
00:27:31,130 --> 00:27:32,420
ვინც იყო, რომ ფილმი.

652
00:27:32,420 --> 00:27:33,290
>> კარგი.

653
00:27:33,290 --> 00:27:33,880
ასე რომ, აქ ჩვენ მივდივართ.

654
00:27:33,880 --> 00:27:38,040
ერთ-ერთი ყველაზე მაღალი დონის
ურთიერთობა; ერთ-მრავალი,

655
00:27:38,040 --> 00:27:40,240
ფოტოალბომი საჩვენებელი; ბევრი მრავალთან.

656
00:27:40,240 --> 00:27:44,990
ეს არის სამი უმაღლესი დონის
ურთიერთობები ნებისმიერი მონაცემთა ბაზაში.

657
00:27:44,990 --> 00:27:48,050
თუ თქვენ იცით, თუ როგორ იმ
ურთიერთობები ვიმუშაოთ,

658
00:27:48,050 --> 00:27:51,490
მაშინ თქვენ იცით, ბევრი
მონაცემთა ბაზაში უკვე.

659
00:27:51,490 --> 00:27:55,660
ასე რომ, NoSQL მუშაობს ცოტა განსხვავებულად.

660
00:27:55,660 --> 00:27:58,930
მოდით ვიფიქროთ, რომ მეორე ის, რაც
ჰგავს წავიდეთ მისაღებად ყველა ჩემს პროდუქცია.

661
00:27:58,930 --> 00:28:01,096
>> In რელატიური მაღაზიაში, მე
გვინდა ყველა ჩემს პროდუქცია

662
00:28:01,096 --> 00:28:02,970
on სიაში ყველა ჩემს პროდუქცია.

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
მე გაგზავნის CPU მთელი სისტემა
გაწევრიანების ამ მონაცემების სტრუქტურები ერთად

686
00:29:04,500 --> 00:29:05,950
შეძლებს გაიყვანოს, რომ მონაცემები უკან.

687
00:29:05,950 --> 00:29:07,310
>> ასე რომ, მე მისაღებად გარშემო, რომ?

688
00:29:07,310 --> 00:29:11,200
In 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
და პროდუქტის წიგნი შეიძლება
აქვს ტიპის ID, რომ განსაზღვრავს წიგნი.

706
00:29:56,510 --> 00:29:59,180
და გამოყენების
გადართოთ, რომ ID.

707
00:29:59,180 --> 00:30:02,570
>> განაცხადის იარუსი, მე ვაპირებ
უნდა ვთქვა, მე, რა ჩანაწერი ტიპის არის ეს?

708
00:30:02,570 --> 00:30:04,100
ოჰ, ეს წიგნი ჩანაწერი.

709
00:30:04,100 --> 00:30:05,990
წიგნი ჩანაწერები აქვს ეს თვისებები.

710
00:30:05,990 --> 00:30:08,100
ნება მომეცით შექმნა წიგნაკი ობიექტი.

711
00:30:08,100 --> 00:30:11,289
ამიტომ, მე ვაპირებ, რომ შეავსოთ
წიგნი ობიექტი ამ ერთეულზე.

712
00:30:11,289 --> 00:30:13,080
შემდეგი საქონლის მოდის და
ამბობს, რა არის ეს ნივთი?

713
00:30:13,080 --> 00:30:14,560
ისე ეს საქონელი ალბომი.

714
00:30:14,560 --> 00:30:17,340
ოჰ, მე მივიღე მთელი სხვადასხვა
დამუშავება სიტუაციიდან, რომ

715
00:30:17,340 --> 00:30:18,487
იმიტომ, რომ ეს ალბომი.

716
00:30:18,487 --> 00:30:19,320
ხედავთ რას ვგულისხმობ?

717
00:30:19,320 --> 00:30:21,950
>> ასე რომ, განაცხადი tier-- მე
უბრალოდ აირჩიეთ ყველა ეს ჩანაწერი.

718
00:30:21,950 --> 00:30:23,200
ისინი ყველა დაიწყებს მოდის.

719
00:30:23,200 --> 00:30:24,680
ისინი შეიძლება ყველა ტიპის.

720
00:30:24,680 --> 00:30:27,590
და ეს განცხადება ლოგიკა
რომ ცვლის მთელი იმ ტიპის

721
00:30:27,590 --> 00:30:29,530
და გადაწყვეტს როგორ გადაამუშავებს მათ.

722
00:30:29,530 --> 00:30:33,640
>> ერთხელ, ასე რომ, ჩვენ ოპტიმიზაციის
სქემა ხელმისაწვდომობის ნიმუში.

723
00:30:33,640 --> 00:30:36,390
ჩვენ ვაკეთებთ მიერ
იშლება იმ მაგიდები.

724
00:30:36,390 --> 00:30:39,670
ჩვენ ძირითადად იღებენ
ამ ნორმალიზება სტრუქტურები,

725
00:30:39,670 --> 00:30:42,000
და ჩვენ ვაშენებთ
იერარქიული სტრუქტურები.

726
00:30:42,000 --> 00:30:45,130
Inside ყოველი ეს ჩანაწერები
მე ვაპირებ, რომ ნახოთ მასივი თვისებები.

727
00:30:45,130 --> 00:30:49,400
>> Inside ეს დოკუმენტი ალბომი,
მე ხედავს მასივების სიმღერები.

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
როდესაც მე ჩადეთ row შევიდა Tracks
მაგიდა, ან ზედიზედ შევიდა ალბომი მაგიდა,

737
00:31:11,620 --> 00:31:13,110
მე უნდა შეესაბამებოდეს რომ schema.

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
და მე iterating
მთელს შედეგები მითითებული.

749
00:31:43,010 --> 00:31:46,512
ეს გაძლევთ იდეა
ძალა NoSQL.

750
00:31:46,512 --> 00:31:49,470
მე ვაპირებ სახის წასვლა sideways აქ
და გაიგო ცოტა შესახებ.

751
00:31:49,470 --> 00:31:53,240
ეს უფრო სახის
მარკეტინგის ან technology--

752
00:31:53,240 --> 00:31:55,660
მარკეტინგის ტექნიკა
დისკუსია.

753
00:31:55,660 --> 00:31:58,672
მაგრამ ეს მნიშვნელოვანია იმის გაგება,
იმიტომ, რომ თუ ჩვენ გადავხედავთ ყველაზე

754
00:31:58,672 --> 00:32:00,380
აქ, ამ სქემა,
ის, რასაც ჩვენ ვუყურებთ

755
00:32:00,380 --> 00:32:04,030
არის ის, რაც ჩვენ მოვუწოდებთ
ტექნიკა ვარდების რევოლუციის მრუდი.

756
00:32:04,030 --> 00:32:06,121
და რას ნიშნავს,
ახალი პერსონალის ძალაში პიესა.

757
00:32:06,121 --> 00:32:07,120
ხალხი ფიქრობს, რომ ეს არის დიდი.

758
00:32:07,120 --> 00:32:09,200
მე მოგვარდება ყველა პრობლემა.

759
00:32:09,200 --> 00:32:11,630
>> ეს შეიძლება იყოს ბოლომდე
ყველა, იქნება ყველა ყველაფერს.

760
00:32:11,630 --> 00:32:12,790
და ისინი დაიწყოს გამოყენებით.

761
00:32:12,790 --> 00:32:14,720
და ამბობენ, ამ პერსონალის არ მუშაობს.

762
00:32:14,720 --> 00:32:17,600
ეს არ არის სწორი.

763
00:32:17,600 --> 00:32:19,105
ძველი პერსონალის უკეთესი იყო.

764
00:32:19,105 --> 00:32:21,230
და მათ დაბრუნდეს აკეთებს
რამ გზა ისინი.

765
00:32:21,230 --> 00:32:22,730
და მაშინ საბოლოოდ
დადიან, იცით რა?

766
00:32:22,730 --> 00:32:24,040
ეს პერსონალის ასე არ არის ცუდი.

767
00:32:24,040 --> 00:32:26,192
ოჰ, რომ, თუ როგორ მუშაობს.

768
00:32:26,192 --> 00:32:28,900
და კიდევ ისინი გაერკვნენ, თუ როგორ
სამუშაოები, დაიწყება უკეთესობისაკენ.

769
00:32:28,900 --> 00:32:32,050
>> და სასაცილო რამ შესახებ ეს
ის არის, რომ სახის ხაზები მდე რა

770
00:32:32,050 --> 00:32:34,300
ჩვენ მოვუწოდებთ ტექნიკა მიღება Curve.

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
ახლა რა აუცილებლად უნდა მოხდეს და
ეს ხდება ახლა 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
მაგრამ ეს იგივეა, როცა
jackhammer გამოიგონეს,

792
00:33:22,080 --> 00:33:24,621
ადამიანი არ Swing მას მეტი
მათი ხელმძღვანელი smash კონკრეტული.

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
და ისინი ჩატვირთვის ის
სრული რელაციური მონაცემთა schema.

798
00:33:39,900 --> 00:33:41,630
იმის გამო, რომ ის, თუ როგორ
მათ შეიმუშავონ ბაზაში.

799
00:33:41,630 --> 00:33:44,046
და ისინი მაინტერესებს, რატომ არის
ეს არ ასრულებენ ძალიან კარგად?

800
00:33:44,046 --> 00:33:45,230
ბიჭი, ეს ის სუნი ასდის.

801
00:33:45,230 --> 00:33:49,900
მე უნდა შევინარჩუნოთ ყველა ჩემი
უერთდება შიგნით ეს იგივეა, არა, არა.

802
00:33:49,900 --> 00:33:50,800
შენარჩუნება უერთდება?

803
00:33:50,800 --> 00:33:52,430
რატომ გაწევრიანების მონაცემები?

804
00:33:52,430 --> 00:33:54,350
თქვენ არ შეუერთდება მონაცემების 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
როდესაც ჩვენ ვიწყებთ მალე აქ,
ეს იმიტომ, რომ ადამიანი figured

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 მონაცემების მტევანი
მასშტაბის, გაშვებული petabytes,

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 უკეთესია ან
უარესი Couch, მაშინ Cassandra,

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
millisecond შეყოვნება ნებისმიერ მასშტაბში.

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
პირადობის ძებნა მენეჯმენტი, ან უკვე.

877
00:36:57,920 --> 00:37:01,980
ეს permeates ყველა სისტემას,
ყველა მომსახურება, რომელიც 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: True დადებითი
წინააღმდეგ ცრუ უარყოფით შედეგებს?

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
თუ თქვენ იცნობს ნებისმიერი მონაცემთა ბაზა,
მონაცემთა ბაზები აქვს მართლაც ორი სახის APIs

906
00:38:17,930 --> 00:38:18,430
მინდა მოვუწოდო მას.

907
00:38:18,430 --> 00:38:21,570
ან ორი კომპლექტი API.

908
00:38:21,570 --> 00:38:23,840
ერთ-ერთი ასეთი იქნება
ადმინისტრაციული API.

909
00:38:23,840 --> 00:38:26,710
>> რამ მათ იზრუნოს
ფუნქციები მონაცემთა ბაზაში.

910
00:38:26,710 --> 00:38:31,340
კონფიგურაცია შენახვის სისტემა,
შექმნის და დასძინა, მაგიდები.

911
00:38:31,340 --> 00:38:35,180
მონაცემთა ბაზის
კატალოგები და შემთხვევები.

912
00:38:35,180 --> 00:38:40,450
ეს ყველაფერი ამ DynamoDB, თქვენ
აქვს ძალიან მოკლე, მოკლე სიები.

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
In DynamoDB თქვენ არ უნდა იმ იმიტომ,
თქვენ არ კონფიგურაცია სისტემა, რასაც ჩვენ ვაკეთებთ.

917
00:38:51,234 --> 00:38:54,150
ასე რომ, ერთადერთი, რაც თქვენ უნდა გავაკეთოთ არის
მითხარით, რა ზომის მაგიდა მჭირდება.

918
00:38:54,150 --> 00:38:55,660
ასე რომ, თქვენ ძალიან
შეზღუდული კომპლექტი ბრძანებები.

919
00:38:55,660 --> 00:38:58,618
>> თქვენ შექმენით მაგიდა განახლება, მაგიდა,
წაშალე მაგიდა, და აღწერეთ მაგიდა.

920
00:38:58,618 --> 00:39:01,150
ეს არის ერთადერთი რამ,
თქვენ უნდა DynamoDB.

921
00:39:01,150 --> 00:39:03,294
თქვენ არ გჭირდებათ შენახვის
ძრავის კონფიგურაცია.

922
00:39:03,294 --> 00:39:04,960
მე არ უნდა ფიქრი, რეპლიკაცია.

923
00:39:04,960 --> 00:39:06,490
მე არ უნდა ფიქრი 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
ასე რომ, დიდი ოდენობით ოვერჰედის
რომ უბრალოდ გააუქმა off თქვენი ფირფიტაზე.

927
00:39:11,867 --> 00:39:13,200
შემდეგ ჩვენ გვაქვს ნაგვის ოპერატორები.

928
00:39:13,200 --> 00:39:17,740
ნაგვის არის რაღაც, რაც ჩვენ
მოვუწოდებთ მონაცემთა ბაზა, რომელიც არის

929
00:39:17,740 --> 00:39:19,860
შექმნა, განახლება, წაშლა ოპერატორები.

930
00:39:19,860 --> 00:39:24,180
ეს არის თქვენი საერთო
მონაცემთა ბაზის ოპერაციებში.

931
00:39:24,180 --> 00:39:31,299
რამ, როგორიცაა put პუნქტის, მიიღოს საქონელი, განახლება
ნივთები, წაშლა ნივთები, სურათების შეკითხვაზე, ეძებოს.

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
მაქვს გარკვეული შინაარსის შემდეგ
on გემბანზე შესახებ.

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
ყველაფერი, რაც ხდება
მაგიდა გვიჩვენებს up ნაკადი.

945
00:40:03,940 --> 00:40:05,940
>> ყოველ ვწერ მაგიდა
გვიჩვენებს up ნაკადი.

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
In 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
ეს არის სიმები,
ნომრები და binaries.

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 თქვენ შეიძლება შეიცავდეს კოლექტორები
ძირითადი სახის, როგორც root ქონება.

959
00:40:42,050 --> 00:40:43,885
>> და მაშინ იქ დოკუმენტის ტიპის.

960
00:40:43,885 --> 00:40:45,510
რამდენი ადამიანი იცნობს JSON?

961
00:40:45,510 --> 00:40:47,130
თქვენ ბიჭები იცნობს JSON ამდენი?

962
00:40:47,130 --> 00:40:49,380
ეს, ძირითადად, JavaScript,
ობიექტი, ნოტაცია.

963
00:40:49,380 --> 00:40:52,510
ეს გაძლევთ საშუალებას, ძირითადად,
განსაზღვრავს იერარქიული სტრუქტურა.

964
00:40:52,510 --> 00:40:58,107
>> თქვენ შეგიძლიათ ჩაწეროთ JSON დოკუმენტი
DynamoDB გამოყენებით საერთო კომპონენტები

965
00:40:58,107 --> 00:41:00,940
ან სამშენებლო ბლოკები, რომლებიც ხელმისაწვდომი
ყველაზე პროგრამირების ენები.

966
00:41:00,940 --> 00:41:03,602
ასე რომ, თუ თქვენ გაქვთ Java, თქვენ
ეძებს რუკები და სიები.

967
00:41:03,602 --> 00:41:05,060
მე შეგიძლიათ შექმნათ ობიექტები, რომ ფართობი რუკა.

968
00:41:05,060 --> 00:41:08,030
რუკისა ძირითად ღირებულებებზე
შენახული თვისებები.

969
00:41:08,030 --> 00:41:10,890
და ალბათ, ეს სიები
ღირებულებების იმ თვისებებს.

970
00:41:10,890 --> 00:41:13,490
თქვენ შეგიძლიათ შეინახოთ ეს კომპლექსი
იერარქიული სტრუქტურა

971
00:41:13,490 --> 00:41:16,320
როგორც ერთი ატრიბუტი
ერთი DynamoDB ერთეულზე.

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

973
00:41:19,010 --> 00:41:24,460
>> ასე რომ, მაგიდები DynamoDB, როგორც ყველაზე
NoSQL მონაცემთა ბაზა, მაგიდები საკითხი.

974
00:41:24,460 --> 00:41:26,469
In 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
In DynamoDB, არსებობს
ერთ-ერთი სავალდებულო ატრიბუტი.

981
00:41:38,520 --> 00:41:43,880
ისევე, რელატიური მონაცემთა ბაზა,
თქვენ გაქვთ პირველადი გასაღები მაგიდაზე.

982
00:41:43,880 --> 00:41:46,010
>> DynamoDB აქვს, რაც ჩვენ მოვუწოდებთ hash გასაღები.

983
00:41:46,010 --> 00:41:48,280
Hash გასაღები უნდა იყოს უნიკალური.

984
00:41:48,280 --> 00:41:52,580
ასე რომ, როდესაც მე განსაზღვრა hash მაგიდა,
ძირითადად რა მე ვამბობ,

985
00:41:52,580 --> 00:41:54,110
არის ყველა ნივთი გექნებათ hash გასაღები.

986
00:41:54,110 --> 00:41:58,520
და ყოველ hash გასაღები უნდა იყოს უნიკალური.

987
00:41:58,520 --> 00:42:01,200
>> ყველა ნივთი არის განსაზღვრული
მიერ, რომელიც უნიკალური hash გასაღები.

988
00:42:01,200 --> 00:42:02,940
და არ შეიძლება იყოს მხოლოდ ერთი.

989
00:42:02,940 --> 00:42:05,820
ეს კარგია, მაგრამ ხშირად
რა სჭირდება ხალხს

990
00:42:05,820 --> 00:42:08,170
არის უნდათ ამ hash
გასაღები უნდა გავაკეთოთ ცოტა მეტი

991
00:42:08,170 --> 00:42:11,010
მეტი, ვიდრე უბრალოდ უნდა უნიკალური იდენტიფიკატორი.

992
00:42:11,010 --> 00:42:15,240
ხშირად ჩვენ გვინდა, რომ გამოიყენოს hash გასაღები
როგორც ზედა დონის აგრეგაციას bucket.

993
00:42:15,240 --> 00:42:19,160
და გზა ჩვენ, რომ არის
დასძინა, რაც ჩვენ მოვუწოდებთ სპექტრი გასაღები.

994
00:42:19,160 --> 00:42:22,460
>> ასე რომ, თუ ის hash მხოლოდ
მაგიდა, ეს უნდა იყოს უნიკალური.

995
00:42:22,460 --> 00:42:27,040
თუ ეს hash და დიაპაზონი მაგიდა,
კომბინაცია hash და სპექტრი

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
>> ასე რომ, მე შეიძლება hash
გასაღები, რომელიც თემაზე ID.

1001
00:42:42,630 --> 00:42:46,650
და მე ალბათ სპექტრი გასაღები,
რომელიც არის პასუხი ID.

1002
00:42:46,650 --> 00:42:49,650
ასე რომ, თუ მე მინდა, რომ მიიღოს ყველა
პასუხები კონკრეტულ თემაზე,

1003
00:42:49,650 --> 00:42:52,370
მე შემიძლია მხოლოდ შეკითხვის hash.

1004
00:42:52,370 --> 00:42:55,190
მე შემიძლია მხოლოდ ვთქვა, მომეცი ყველა
საკითხი, რომელიც აქვს ამ hash.

1005
00:42:55,190 --> 00:43:01,910
და მე ვაპირებ მისაღებად ყველა კითხვაზე
ან პოსტი, რომ კონკრეტულ თემაზე.

1006
00:43:01,910 --> 00:43:03,910
ეს უმაღლესი დონის aggregations
ძალიან მნიშვნელოვანია.

1007
00:43:03,910 --> 00:43:07,370
ისინი მხარს უჭერენ პირველადი დაშვება
ნიმუში განაცხადი.

1008
00:43:07,370 --> 00:43:09,420
საერთოდ, ამ
არის ის, რაც ჩვენ გვინდა გავაკეთოთ.

1009
00:43:09,420 --> 00:43:11,780
ჩვენ გვინდა, რომ მაგიდასთან
თქვენ ჩატვირთეთ მაგიდა,

1010
00:43:11,780 --> 00:43:16,640
ჩვენ გვინდა, რომ სტრუქტურირებაზე მონაცემები
ფარგლებში მაგიდაზე ისე,

1011
00:43:16,640 --> 00:43:20,140
რომ განაცხადი შეიძლება ძალიან
სწრაფად დაიბრუნებს იმ შედეგებს.

1012
00:43:20,140 --> 00:43:24,510
და ხშირად ისე უნდა გავაკეთოთ, რომ
შენარჩუნება ამ aggregations როგორც ჩვენ

1013
00:43:24,510 --> 00:43:25,650
ჩადეთ მონაცემები.

1014
00:43:25,650 --> 00:43:31,110
ძირითადად, ჩვენ გავრცელების მონაცემები
შევიდა ნათელი bucket, როგორც ის მოდის.

1015
00:43:31,110 --> 00:43:35,210
>> Range ღილაკები საშუალებას ჩემთვის hash
გასაღებები უნდა იყოს თანასწორობა.

1016
00:43:35,210 --> 00:43:39,490
როდესაც მე შეკითხვის hash, მე უნდა ვთქვა,
მომეცი hash რომელიც უდრის.

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
მომეცი ყველა ელემენტი hash.

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
ასე რომ, ამ ტიპის სპექტრს queries
რომ ჩვენ ყოველთვის დაინტერესებული.

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
როდესაც ვამბობ hash და hashing--
იმიტომ, ჰეშირება ალგორითმი

1041
00:44:49,860 --> 00:44:54,140
არის გზა, რომ შეუძლია გენერირება
შემთხვევითი მნიშვნელობა ნებისმიერ მნიშვნელობა.

1042
00:44:54,140 --> 00:44:59,300
ასე რომ, ამ კონკრეტულ შემთხვევაში,
hash ალგორითმი ჩვენ აწარმოებს არის ND 5 საფუძველზე.

1043
00:44:59,300 --> 00:45:04,765
>> და თუ მე მაქვს ID, და ამ
ჩემი hash გასაღები, მაქვს 1, 2, 3.

1044
00:45:04,765 --> 00:45:07,390
როცა აწარმოებს hash ალგორითმი,
ის აპირებს დაბრუნებას და აცხადებენ,

1045
00:45:07,390 --> 00:45:10,800
ასევე 1 უდრის 7B, 2
უდრის 48, 3 ტოლია CD.

1046
00:45:10,800 --> 00:45:13,092
ისინი მთელ გასაღები სივრცეში.

1047
00:45:13,092 --> 00:45:14,050
და რატომ აკეთებთ ამას?

1048
00:45:14,050 --> 00:45:17,120
იმის გამო, რომ რაც დარწმუნებული ვარ, რომ მე არ შემიძლია
ბოლო ჩანაწერები მასშტაბით სხვადასხვა კვანძების.

1049
00:45:17,120 --> 00:45:19,574
>> თუ მე ვაკეთებ ამ
ხარჯებს, 1, 2, 3.

1050
00:45:19,574 --> 00:45:21,990
და მაქვს hash სპექტრი, რომელიც
გადის ამ კონკრეტულ შემთხვევაში,

1051
00:45:21,990 --> 00:45:24,785
პატარა hash სივრცეში,
ის გადის 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
Partition 2 55 89.

1060
00:45:47,720 --> 00:45:49,780
Partition 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
In MongoDB მათ აქვთ ეს პრობლემა
თუ არ გამოიყენოთ hash გასაღები.

1068
00:46:08,760 --> 00:46:11,325
MongoDB გაძლევთ ვარიანტი
საქართველოს ჰეშირება გასაღები ღირებულება.

1069
00:46:11,325 --> 00:46:13,950
თქვენ ყოველთვის უნდა გავაკეთოთ, რომ, თუ
თქვენ იყენებთ დამატება hash

1070
00:46:13,950 --> 00:46:17,380
გასაღები MongoDB, ან თქვენ უნდა იყოს
nailing ყოველ ჩაწერის ერთი კვანძის,

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
აუდიტორია: Just სწრაფი ერთი
თქვენი Mongo კომენტარი.

1078
00:46:36,320 --> 00:46:39,530
ასე რომ, არის ობიექტი ID, რომ მოდის
natively ერთად 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
>> In MongoDB შეგიძლიათ მიუთითოთ
თუ არა, რომ hash თუ არა.

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
თუ თქვენ იცით, რომ ეს არ არის შემთხვევითი, რომ
ის დამატება, მაშინ ნუ hash.

1090
00:47:04,260 --> 00:47:06,880
>> ახლა რამ
ჰეშირება, ერთხელ თქვენ hash

1091
00:47:06,880 --> 00:47:08,800
value-- და ეს არის
რატომ hash გასაღებები ყოველთვის

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
იმის გამო, რომ hash ღირებულება არ აპირებს
ექვივალენტი ფაქტობრივი ღირებულების.

1095
00:47:20,800 --> 00:47:24,570
ასე რომ, როდესაც თქვენ hash, რომ
გასაღები, ეს თანასწორობა.

1096
00:47:24,570 --> 00:47:28,700
სწორედ ამიტომ, DynamoDB hash გასაღები
შეკითხვებს ყოველთვის თანასწორობა.

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
ასე რომ, ისინი ძალიან სწრაფად, მარტივად
მოძიებული, რადგან ეს არის hash,

1101
00:47:42,430 --> 00:47:43,220
ეს არის დიაპაზონი.

1102
00:47:43,220 --> 00:47:44,928
თქვენ ხედავთ, ყველაფერი
იგივე hash

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
მე შეიძლება მქონდეს hash გასაღებები.

1109
00:48:03,490 --> 00:48:07,610
მე შემიძლია მხოლოდ აქვს მრავალი სპექტრი
გასაღებები ფარგლებში ყოველ hash გასაღები.

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
და იგივე სახის
აშენებს in 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
რაც იმას ნიშნავს, რომ ჩვენ გვაქვს სამი AZ ს.

1120
00:48:37,550 --> 00:48:39,160
AZ ს არსებობა ზონები.

1121
00:48:39,160 --> 00:48:43,430
შეგიძლიათ წარმოიდგინოთ, რომ ხელმისაწვდომობა
ზონა, როგორც მონაცემების ცენტრი

1122
00:48:43,430 --> 00:48:45,447
ან შეგროვება მონაცემები ცენტრებში.

1123
00:48:45,447 --> 00:48:47,780
ეს ყველაფერი არის გეოგრაფიულად
იზოლირებულია ერთმანეთისგან

1124
00:48:47,780 --> 00:48:51,610
სხვადასხვა ბრალია ზონებში, მთელს
სხვადასხვა ძალა ბადეები და ფრაგმენტებს ვხვდებით.

1125
00:48:51,610 --> 00:48:54,510
მარცხი ერთ AZ არ არის
აპირებს ქვემოთ სხვა.

1126
00:48:54,510 --> 00:48:56,890
ისინი ასევე უკავშირდება
ერთად მუქი ბოჭკოვანი.

1127
00:48:56,890 --> 00:49:01,240
იგი მხარს უჭერს ერთი ქვე 1
millisecond შეყოვნება შორის AZS.

1128
00:49:01,240 --> 00:49:05,390
ასე რომ რეალურ დროში მონაცემთა replications
შეუძლია მრავალ AZS.

1129
00:49:05,390 --> 00:49:09,990
>> და ხშირად მრავალ AZ განლაგდებიან
აკმაყოფილებს მაღალი ხელმისაწვდომობის მოთხოვნებს

1130
00:49:09,990 --> 00:49:12,930
ყველაზე საწარმო ორგანიზაციები.

1131
00:49:12,930 --> 00:49:16,139
ასე რომ, DynamoDB გავრცელდა
მასშტაბით სამი AZS იყოს.

1132
00:49:16,139 --> 00:49:19,430
ჩვენ მხოლოდ აპირებს ცოდნის ჩაწერის
როდესაც ორი იმ სამი კვანძების დაბრუნდება

1133
00:49:19,430 --> 00:49:21,470
და აცხადებენ, ჰო, მე მივიღე ეს.

1134
00:49:21,470 --> 00:49:22,050
ეს რატომ?

1135
00:49:22,050 --> 00:49:25,950
იმის გამო, რომ წაკითხული მხარეს ჩვენ მხოლოდ
აპირებს მოგცემთ მონაცემების უკან, როდესაც

1136
00:49:25,950 --> 00:49:27,570
ჩვენ ეს ორი კვანძების.

1137
00:49:27,570 --> 00:49:30,490
>> თუ მე რეპლიკაციური მასშტაბით
სამი, და მე კითხულობს ორი,

1138
00:49:30,490 --> 00:49:32,840
მე ყოველთვის გარანტირებული
აქვს მინიმუმ ერთი

1139
00:49:32,840 --> 00:49:35,720
იმ ნათქვამია, რომ იყოს
უახლესი ასლი მონაცემები.

1140
00:49:35,720 --> 00:49:38,340
ეს არის ის რაც DynamoDB თანმიმდევრული.

1141
00:49:38,340 --> 00:49:42,450
ახლა თქვენ შეგიძლიათ ჩართოთ
იმ თანმიმდევრული ნათქვამია off.

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
ჩვენ მივიღეთ hash გასაღებები, და
ჩვენ მივიღეთ სპექტრი გასაღებები.

1159
00:50:23,720 --> 00:50:24,320
კარგია.

1160
00:50:24,320 --> 00:50:26,950
და რომ პირველადი მაგიდასთან, მე
გაიხარეს hash გასაღები, მე მივიღე ერთი სპექტრი გასაღები.

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
>> უნდა გამოვიყენოთ იგივე hash
გასაღები, როგორც პირველადი მაგიდა,

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
აგრეგაცია on თარიღი
საწარმოებლად რომ კონკრეტული ნაწილი.

1193
00:52:00,760 --> 00:52:03,930
ასე რომ, თუ ჩემი ზედა დონის მაგიდა
უკვე hashed მწარმოებელი,

1194
00:52:03,930 --> 00:52:07,655
შესაძლოა, ეს მოეწყო ნაწილი ID, მე
შეგიძლიათ შექმნათ ინდექსი off მაგიდა

1195
00:52:07,655 --> 00:52:11,140
როგორც hashed მიერ მწარმოებელი და
განმეორებადი თარიღის წარმოება.

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
>> ეს აქვს ეფექტი
შეზღუდვის თქვენი hash გასაღები სივრცეში.

1200
00:52:22,280 --> 00:52:24,360
იმის გამო, რომ ერთ-არსებობდა
იმავე შენახვის კვანძის,

1201
00:52:24,360 --> 00:52:26,860
ისინი ზღუდავს hash გასაღები
ფართი 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 gigs მონაცემების, ჩვენ
წასვლა [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
Global secondaries არიან
მართლაც სხვა მაგიდასთან.

1214
00:52:58,630 --> 00:53:01,720
ისინი არსებობენ სრულიად off to
მხარეს თქვენი პირველადი მაგიდასთან.

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
>> მე შეუძლია განსაზღვროს სრულიად
სხვადასხვა hash გასაღები.

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
ახლა ორივე ინდექსები საშუალებას გვაძლევს
არა მარტო განსაზღვროს hash და სპექტრი გასაღებები,

1228
00:53:35,240 --> 00:53:38,610
მაგრამ ისინი საშუალებას მოგვცემს
პროექტის დამატებითი ღირებულებები.

1229
00:53:38,610 --> 00:53:44,950
ასე რომ, თუ მე მინდა წაიკითხონ off ინდექსი,
და მე მინდა, რომ მიიღოთ გარკვეული კომპლექტი მონაცემები,

1230
00:53:44,950 --> 00:53:48,327
მე არ უნდა დაბრუნდეს მთავარი
მაგიდასთან მიიღოს დამატებითი ატრიბუტები.

1231
00:53:48,327 --> 00:53:50,660
შემიძლია პროექტის იმ დამატებით
ატრიბუტებს შევიდა მაგიდა

1232
00:53:50,660 --> 00:53:53,440
ხელი შეუწყოს ხელმისაწვდომობის ნიმუში.

1233
00:53:53,440 --> 00:53:57,700
მე ვიცი, რომ ჩვენ, ალბათ, მისაღებად შევიდა რაღაც
მართლაც, ნამდვილად მისაღებად შევიდა სარეველა

1234
00:53:57,700 --> 00:53:58,910
აქ ზოგიერთი ამ პერსონალის.

1235
00:53:58,910 --> 00:54:02,725
ახლა მე მივიღე დრიფტის ამ.

1236
00:54:02,725 --> 00:54:07,320
>> აუდიტორია: [INAUDIBLE]
--table გასაღები ნიშნავდა იყო hash?

1237
00:54:07,320 --> 00:54:08,840
ორიგინალური hash?

1238
00:54:08,840 --> 00:54:09,340
Multi-slats?

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
>> GSIs, ასე როგორ მუშაობს?

1258
00:54:54,860 --> 00:54:58,340
GSIs ძირითადად ასინქრონული.

1259
00:54:58,340 --> 00:55:02,570
განახლება ძალაში მაგიდა,
მაგიდა მაშინ asynchronously მხრიდან

1260
00:55:02,570 --> 00:55:03,720
ყველა თქვენი GSIs.

1261
00:55:03,720 --> 00:55:06,680
სწორედ ამიტომ, GSIs არიან
საბოლოოდ თანმიმდევრული.

1262
00:55:06,680 --> 00:55:09,440
>> მნიშვნელოვანია აღინიშნოს, რომ
როდესაც თქვენ აშენებთ GSIs,

1263
00:55:09,440 --> 00:55:13,110
და თქვენ იცით, თქვენ შექმნით
სხვა განზომილება aggregation--

1264
00:55:13,110 --> 00:55:16,594
ახლა მოდით ვთქვათ, კარგი მაგალითი
აქ არის მწარმოებელი.

1265
00:55:16,594 --> 00:55:19,260
მე ვფიქრობ, რომ, შესაძლოა, ისაუბრა
სამედიცინო მოწყობილობა მწარმოებელი.

1266
00:55:19,260 --> 00:55:23,870
სამედიცინო მოწყობილობა მწარმოებლები
ხშირად აქვს serialized ნაწილები.

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
in შეკრების, ყველა
ნაწილები, რომ გაკეთდა

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
და ეს aggregations ზოგჯერ
მისაღებად შევიდა მილიარდობით.

1276
00:55:47,940 --> 00:55:50,550
>> ასე რომ, მე მუშაობა ზოგიერთი
ეს ბიჭები, რომლებიც დაავადებული

1277
00:55:50,550 --> 00:55:53,156
იმიტომ, რომ ისინი შექმნა
ამ ginormous aggregations

1278
00:55:53,156 --> 00:55:54,280
მათი საშუალო ინდექსები.

1279
00:55:54,280 --> 00:55:57,070
ალბათ ნედლეული ნაწილები
მაგიდა, რომელიც მოდის როგორც hash მხოლოდ.

1280
00:55:57,070 --> 00:55:59,090
ყველა ნაწილი აქვს უნიკალური სერიული ნომერი.

1281
00:55:59,090 --> 00:56:00,975
მე სერიული ნომერი, როგორც hash.

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 როგორც hash,

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
და თუ მონაცემები ზომა პოსტი hash გასაღებები
თქვენი კოლექცია აღემატება 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, თქვენ
can დებულება [INAUDIBLE]

1315
00:57:37,460 --> 00:57:38,680
, მთელს მაგიდა.

1316
00:57:38,680 --> 00:57:42,740
ჩვენ მომხმარებელს, რომ აქვს
შესაბამისად 60 მლრდ

1317
00:57:42,740 --> 00:57:45,970
ვაკეთებთ 60 მილიარდი მოითხოვს, რეგულარულად
გაშვებული მილიონზე მეტი მოითხოვს

1318
00:57:45,970 --> 00:57:47,790
წამში ჩვენს მაგიდები.

1319
00:57:47,790 --> 00:57:50,360
იქ ნამდვილად არ არის
თეორიული ზღვარი, თუ რამდენად

1320
00:57:50,360 --> 00:57:53,730
და რამდენად სწრაფად მაგიდა
შეგიძლიათ აწარმოებს დინამო 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
ჩვენ აქციოს dial.

1326
00:58:02,810 --> 00:58:08,210
>> ყველა ანგარიში შემოიფარგლება გარკვეული დონის
ყველა მომსახურება, უბრალოდ off bat

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 kilobytes ყოველი,

1331
00:58:17,620 --> 00:58:20,050
რომ იქნება ნივთი არ ატრიბუტები.

1332
00:58:20,050 --> 00:58:24,200
ასე რომ, თანხა ყველა ატრიბუტები
შემოიფარგლება 400 kilobytes.

1333
00:58:24,200 --> 00:58:27,300
და მერე ისევ, ჩვენ გვაქვს
რომ პატარა LSI საკითხი

1334
00:58:27,300 --> 00:58:30,405
ერთად 10 გბ ლიმიტი პოსტი hash.

1335
00:58:30,405 --> 00:58:33,280
აუდიტორია: მცირე რაოდენობით, მე დაკარგული
თუ რას მეუბნებოდა, რომ არის

1336
00:58:33,280 --> 00:58:36,830
აუდიტორია: Oh, 400 kilobyte
მაქსიმალური ზომის ერთეულზე.

1337
00:58:36,830 --> 00:58:39,570
ასე რომ ნივთი აქვს ყველა ატრიბუტები.

1338
00:58:39,570 --> 00:58:43,950
ასე რომ, 400 ლ არის სულ ზომა
რომ პუნქტის, 400 kilobytes.

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
და იქ მართლაც ორი knobs.

1346
00:59:00,160 --> 00:59:02,400
ჩვენ წავიკითხე მოცულობა
და დაწეროთ მოცულობა.

1347
00:59:02,400 --> 00:59:05,530
>> ასე რომ, ეს არის მორგებული
ერთმანეთისგან დამოუკიდებლად.

1348
00:59:05,530 --> 00:59:08,640
RCU ის ღონისძიება მკაცრად თანმიმდევრული განცხადებაში.

1349
00:59:08,640 --> 00:59:13,005
OK, ასე რომ, თუ თქვენ ვამბობ, მინდა 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
თქვენ შეგიძლიათ დებულება 1,000
RCU ის, თქვენ აპირებს

1353
00:59:19,402 --> 00:59:21,840
მისაღებად 2,000 საბოლოოდ
თანმიმდევრული განცხადებაში.

1354
00:59:21,840 --> 00:59:25,940
და ნახევარი ფასი მათთვის,
საბოლოოდ შედგება განცხადებაში.

1355
00:59:25,940 --> 00:59:28,520
>> ისევ და ისევ, მორგებული
ერთმანეთისგან დამოუკიდებლად.

1356
00:59:28,520 --> 00:59:32,900
და მათ აქვთ throughput--
თუ თქვენ მოიხმარენ 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
ყველა უფლება, ასე რომ, ერთი რამ, რომ
ვთქვი მოკლედ იყო throttling.

1360
00:59:43,160 --> 00:59:44,320
Throttling არის ცუდი.

1361
00:59:44,320 --> 00:59:47,311
Throttling მიუთითებს ცუდი არ SQL.

1362
00:59:47,311 --> 00:59:50,310
არსებობს რამ შეგვიძლია გავაკეთოთ, რათა დაეხმაროს
თქვენ შემსუბუქება throttling, რომ თქვენ

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
ეს არის ერთადერთი window დრო, რომ მე უნდა.

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
და რას მეუბნებოდა ის არის,
რომ არსებობს ერთი კონკრეტული hash

1401
01:01:23,700 --> 01:01:26,330
რომ ეს ბიჭი მოსწონს
საშინელი ბევრი, იმიტომ, რომ ის

1402
01:01:26,330 --> 01:01:28,250
დარტყმის რეალურად, მართლაც მძიმეა.

1403
01:01:28,250 --> 01:01:29,260
>> ასე რომ, ლურჯი არის ლამაზი.

1404
01:01:29,260 --> 01:01:29,900
ჩვენ გვსურს, ლურჯი.

1405
01:01:29,900 --> 01:01:30,720
ჩვენ არ მიყვარს წითელი.

1406
01:01:30,720 --> 01:01:33,120
წითელი სადაც ზეწოლის
იღებს მდე 100%.

1407
01:01:33,120 --> 01:01:35,560
100%, ახლა თქვენ უნდა აღვადგინოთ.

1408
01:01:35,560 --> 01:01:39,030
ასე რომ, როდესაც თქვენ ხედავთ რაიმე წითელი ხაზები
ამას და ეს არ არის მხოლოდ დინამოს DB--

1409
01:01:39,030 --> 01:01:41,630
ყველა NoSQL მონაცემთა ბაზის აქვს ეს პრობლემა.

1410
01:01:41,630 --> 01:01:44,640
არსებობს საწინააღმდეგო ნიმუშების, რომ შეუძლია
მანქანა ამ ტიპის პირობებს.

1411
01:01:44,640 --> 01:01:49,070
რა გავაკეთო არის მე მუშაობა მომხმარებელს
შემსუბუქება ამ პირობებში.

1412
01:01:49,070 --> 01:01:51,840
>> და რას ჰგავს?

1413
01:01:51,840 --> 01:01:54,260
და ეს არის მიღების ყველაზე
გარეთ დინამო DB გამტარუნარიანობა,

1414
01:01:54,260 --> 01:01:56,176
მაგრამ ეს ნამდვილად მისაღებად
ყველაზე გარეთ NoSQL.

1415
01:01:56,176 --> 01:01:58,740
ეს არ არის შეზღუდული დინამო.

1416
01:01:58,740 --> 01:02:02,050
ეს არის definitely-- მე
გამოყენებული მუშაობა 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
იმისათვის, რომ მიიღოთ საუკეთესო out ნებისმიერი NoSQL
მონაცემთა ბაზა, კონკრეტულად დინამო DB,

1420
01:02:10,320 --> 01:02:13,320
გსურთ შექმნათ მაგიდები
სადაც hash გასაღები ელემენტს აქვს

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
ეს არის ბევრად გავალამაზოთ.

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
მთელი ადგილი, ჩვენ
უნდა გაკეთდეს exercise

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 არის
მონაცემთა schema რომ აბსოლუტურად

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
ამ სუპერ დიდი aggregations.

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
ისინი ჩვეულებრივ რეგულარულად აწარმოებს მეტი
60 მილიარდი ოპერაციების დღეში.

1470
01:04:17,792 --> 01:04:20,000
ისინი აკეთებენ მილიონზე მეტი
ოპერაციები წამში.

1471
01:04:20,000 --> 01:04:22,660
მათ მოხვდით საკმაოდ მარტივია მაგიდა
სტრუქტურა, დატვირთული მაგიდა.

1472
01:04:22,660 --> 01:04:26,450
ეს, ძირითადად, მხოლოდ
hash გასაღები არის ფუნთუშა,

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
>> ასე რომ, ჩვენ გვაქვს ყველა cookies in
ჩვენი ბრაუზერის ამ ბიჭებს.

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 გამოიყურება თქვენ up მათი მაგიდა.

1483
01:04:51,130 --> 01:04:52,115
ისინი თქვენი cookie.

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
გთავაზობთ sub-10 millisecond
პასუხი ყოველ მოთხოვნით.

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
ისინი შეძლებენ ყველა მათი
lookups, ამოწმებდნენ, ყველა, რომ მონაცემები,

1493
01:05:21,120 --> 01:05:26,130
და მიიღოს, რომ დაამატოთ ბმული უკან, რომ
რეკლამის ქვეშ 10 მილიწამი.

1494
01:05:26,130 --> 01:05:29,800
ეს მართლაც საკმაოდ ფენომენალური
განხორციელება, რომელიც მათ აქვთ.

1495
01:05:29,800 --> 01:05:36,210
>> ეს ბიჭები რეალურად
არის ეს ბიჭები.

1496
01:05:36,210 --> 01:05:38,010
მე არ ვარ დარწმუნებული, თუ ის ამ ბიჭებს.

1497
01:05:38,010 --> 01:05:40,127
შეიძლება ამ ბიჭებს.

1498
01:05:40,127 --> 01:05:42,210
ძირითადად განუცხადა us-- არა, მე
არ ვფიქრობ, რომ ეს იყო მათ.

1499
01:05:42,210 --> 01:05:43,000
ვფიქრობ, ეს იყო სხვისი.

1500
01:05:43,000 --> 01:05:44,750
ვმუშაობდი ერთად
მომხმარებელს, რომ მითხრა,

1501
01:05:44,750 --> 01:05:47,040
რომ ახლა, რომ ისინი
წავიდა დინამო DB, ისინი

1502
01:05:47,040 --> 01:05:50,330
ხარჯვის მეტი ფული საჭმლის
მათი განვითარების გუნდი ყოველთვიურად

1503
01:05:50,330 --> 01:05:52,886
ვიდრე ისინი ატარებენ მათ მონაცემთა ბაზაში.

1504
01:05:52,886 --> 01:05:54,760
ასე რომ, ეს მოგცემთ
იდეა ხარჯების

1505
01:05:54,760 --> 01:05:57,889
რომ თქვენ შეგიძლიათ მიიღოთ დინამოში DB არის უზარმაზარი.

1506
01:05:57,889 --> 01:05:59,430
ყველა უფლება, dropcam არის კიდევ ერთი კომპანია.

1507
01:05:59,430 --> 01:06:02,138
ეს ბიჭი არის სახის 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
ვიღაც მოდის,
იწვევს cue წერტილი.

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
და რა გვითხრეს,
მოულოდნელად petabytes მონაცემები.

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
როდესაც ისინი უნდა შევხედოთ ვიდეო,
ისინი ეძებოთ ჩანაწერი დინამო DB.

1524
01:06:47,070 --> 01:06:47,903
ისინი დააწკაპუნეთ ბმულზე.

1525
01:06:47,903 --> 01:06:49,770
ისინი გაიყვანოს ქვემოთ ვიდეო S3.

1526
01:06:49,770 --> 01:06:51,590
ასე რომ, ერთგვარი, თუ რას ჰგავს.

1527
01:06:51,590 --> 01:06:53,580
და ეს არის სწორი მათი გუნდი.

1528
01:06:53,580 --> 01:06:56,010
>> დინამო DB ამცირებს მათ
მიწოდების დრო ვიდეო მოვლენების

1529
01:06:56,010 --> 01:06:57,590
ხუთიდან 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, ეს ბიჭები, რა არის ეს,
Fruit Ninja ვხვდები რამ.

1537
01:07:20,500 --> 01:07:22,590
რომ ყველა ეშვება დინამო DB.

1538
01:07:22,590 --> 01:07:26,810
ეს ბიჭები, ისინი დიდი
განვითარების გუნდი, დიდი განვითარება

1539
01:07:26,810 --> 01:07:27,670
მაღაზია.

1540
01:07:27,670 --> 01:07:29,364
>> არ არის კარგი ops გუნდი.

1541
01:07:29,364 --> 01:07:31,280
მათ არ უნდა ბევრი
ოპერაციის რესურსები.

1542
01:07:31,280 --> 01:07:33,940
ისინი იბრძვიან ცდილობს შეინარჩუნოს
მათი გამოყენების ინფრასტრუქტურის

1543
01:07:33,940 --> 01:07:34,290
და გაშვებული.

1544
01:07:34,290 --> 01:07:35,000
მოვიდნენ ჩვენთან.

1545
01:07:35,000 --> 01:07:36,251
მათ შევხედე, რომ დინამოს DB.

1546
01:07:36,251 --> 01:07:37,291
მათი თქმით, ეს არის ის, ჩვენთვის.

1547
01:07:37,291 --> 01:07:39,470
მათ ააშენეს თავისი მთელი
განაცხადის ფარგლებში იგი.

1548
01:07:39,470 --> 01:07:43,640
ზოგიერთი მართლაც ლამაზი კომენტარი აქ
გუნდი თავის შესაძლებლობებს

1549
01:07:43,640 --> 01:07:46,800
ახლა ფოკუსირება შენობა
თამაში და არა

1550
01:07:46,800 --> 01:07:49,010
მქონე, რომ შევინარჩუნოთ
ინფრასტრუქტურა, რომელიც

1551
01:07:49,010 --> 01:07:51,910
ხდება უზარმაზარი თანხა
ოვერჰედის მათი გუნდი.

1552
01:07:51,910 --> 01:07:56,170
ასე რომ, ეს არის ის, that--
ისარგებლოს, რომ თქვენ დინამო DB.

1553
01:07:56,170 --> 01:08:00,930
>> ყველა უფლება, მისაღებად შევიდა
მონაცემთა მოდელირება აქ.

1554
01:08:00,930 --> 01:08:03,440
ჩვენ ვისაუბრეთ ცოტა შესახებ
ეს ერთ ერთი, ერთი, რომ ბევრი,

1555
01:08:03,440 --> 01:08:05,060
და ბევრი ბევრი ტიპის ურთიერთობები.

1556
01:08:05,060 --> 01:08:07,630
და როგორ შეინარჩუნოს იმ დინამო.

1557
01:08:07,630 --> 01:08:10,500
დინამოში DB ვიყენებთ
ინდექსები, ზოგადად,

1558
01:08:10,500 --> 01:08:12,910
როტაცია მონაცემები
ერთი არომატი სხვა.

1559
01:08:12,910 --> 01:08:15,210
Hash გასაღებები, სპექტრი გასაღებები და ინდექსები.

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, ჩვენ lookups, ჩვენ
გვინდა, რომ ეძებოთ მართვის მოწმობა

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
>> ასე რომ, ჩვენ შეიძლება ჰქონდეს მომხმარებლის მაგიდა, რომელიც
აქვს hash გასაღები სერიული ნომერი,

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,
flip იმ რამ გარშემო.

1579
01:09:12,460 --> 01:09:13,979
ახლა ვისაუბროთ ერთი ბევრი.

1580
01:09:13,979 --> 01:09:16,450
ერთი ბევრი, ძირითადად,
თქვენი hash სპექტრი გასაღები.

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
მაქვს მოწყობილობის ღონისძიებების მაგიდა
ერთად hash გასაღები მოწყობილობის 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
დაწყებითი მაგიდასთან გამოყენებით
hash გასაღები, სპექტრი გასაღები სტრუქტურა.

1594
01:10:02,340 --> 01:10:04,600
>> ასე რომ სახის აშენებული
ცხრილში დინამოში DB.

1595
01:10:04,600 --> 01:10:07,290
როცა განსაზღვრავს hash
და დიაპაზონი t მაგიდა, მე

1596
01:10:07,290 --> 01:10:09,240
განსაზღვრის ერთი მრავალთან კავშირი.

1597
01:10:09,240 --> 01:10:12,770
ეს მშობლისა და შვილის ურთიერთობა.

1598
01:10:12,770 --> 01:10:14,620
>> მოდით ვისაუბროთ ბევრი
ბევრი ურთიერთობები.

1599
01:10:14,620 --> 01:10:19,170
და ამ კონკრეტულ მაგალითს,
კიდევ ერთხელ, ჩვენ ვაპირებთ გამოვიყენოთ GSI ს.

1600
01:10:19,170 --> 01:10:23,500
და მოდით ვისაუბროთ სათამაშო
სცენარი, სადაც მე მაქვს მოცემული შესახებ.

1601
01:10:23,500 --> 01:10:26,500
მინდა, რათა გაირკვეს ყველა თამაშები რომ
ის რეგისტრირებული ან თამაშობენ.

1602
01:10:26,500 --> 01:10:29,600
და მოცემულ თამაშში, მე
უნდათ, რომ ყველა მომხმარებლებს.

1603
01:10:29,600 --> 01:10:31,010
ასე რომ, როგორ შემიძლია ამის გაკეთება?

1604
01:10:31,010 --> 01:10:34,330
ჩემი პროფაილი თამაშები მაგიდა, მე ვაპირებ
აქვს hash გასაღები პროფაილი 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,
მე Flip რომ გარშემო.

1609
01:10:43,410 --> 01:10:46,679
მე hash თამაში და
მე ქედით შესახებ.

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
>> თუ მე უნდა შეკითხვის on
ეს განზომილება, ნება

1618
01:11:01,440 --> 01:11:03,500
ჩემთვის შექმნა ინდექსი, რომელიც განზომილება.

1619
01:11:03,500 --> 01:11:05,850
თუ მე არა, მე არ მაინტერესებს.

1620
01:11:05,850 --> 01:11:09,060
და დამოკიდებულია გამოყენების შემთხვევაში, მე
შეიძლება საჭირო ინდექსი ან მე შეიძლება არ.

1621
01:11:09,060 --> 01:11:12,390
თუ ეს უბრალო ერთი ბევრი,
ძირითადი ცხრილი კარგად არის.

1622
01:11:12,390 --> 01:11:15,860
თუ მე უნდა გავაკეთოთ ეს ბევრი
ბევრი ის, ან მე უნდა გავაკეთოთ ერთი პირობა,

1623
01:11:15,860 --> 01:11:18,390
მაშინ იქნებ მე უნდა
მეორე ინდექსი.

1624
01:11:18,390 --> 01:11:20,840
ასე რომ, ეს ყველაფერი დამოკიდებულია იმაზე,
რაც მე ვცდილობ

1625
01:11:20,840 --> 01:11:24,550
და რა ვცდილობ მისაღებად დასრულებულია.

1626
01:11:24,550 --> 01:11:28,000
>> ალბათ მე არ ვაპირებ დახარჯოს
დიდ დროს საუბარი დოკუმენტები.

1627
01:11:28,000 --> 01:11:31,460
ეს იღებს ცოტა, ალბათ,
უფრო ღრმა, ვიდრე ჩვენ უნდა წავიდეთ.

1628
01:11:31,460 --> 01:11:33,710
მოდით ვისაუბროთ ცოტა
მდიდარი შეკითხვის გამოხატვის.

1629
01:11:33,710 --> 01:11:37,831
ასე რომ, დინამოს DB ჩვენ
უნარი შექმნას

1630
01:11:37,831 --> 01:11:39,330
რაც ჩვენ მოვუწოდებთ პროექტირება გამონათქვამები.

1631
01:11:39,330 --> 01:11:42,660
პროექტირება გამონათქვამები უბრალოდ
კრეფა სფეროებში და ღირებულებების

1632
01:11:42,660 --> 01:11:44,290
რომ გსურთ ცარიელია.

1633
01:11:44,290 --> 01:11:46,000
OK, ასე რომ გააკეთოს არჩევანი.

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
OK, მოდით გავფილტროთ ის საკითხი,
რომ არ ემთხვევა, რომ კონკრეტული შეკითხვა.

1649
01:12:23,380 --> 01:12:25,540
ასე რომ, ჩვენ ფილტრი გამონათქვამები.

1650
01:12:25,540 --> 01:12:28,310
>> ფილტრი გამონათქვამები შეუძლია
უნდა გაუშვათ ნებისმიერი ატრიბუტი.

1651
01:12:28,310 --> 01:12:30,260
ისინი არ მომწონს სპექტრი შეკითხვებს.

1652
01:12:30,260 --> 01:12:32,690
ამაღლება შეკითხვებს უფრო შერჩევითი.

1653
01:12:32,690 --> 01:12:36,470
ფილტრი შეკითხვებს მოითხოვს მე წასვლა
მისაღებად მთელი შედეგები კომპლექტი და შემდეგ

1654
01:12:36,470 --> 01:12:39,170
გაიყო მონაცემებს მე არ მინდა.

1655
01:12:39,170 --> 01:12:40,660
რატომ არის ეს მნიშვნელოვანი?

1656
01:12:40,660 --> 01:12:42,770
იმის გამო, რომ მე წავიკითხე ეს ყველაფერი.

1657
01:12:42,770 --> 01:12:46,597
ამ შეკითხვაზე, მე ვაპირებ, რომ წაიკითხონ და
ეს იქნება გიგანტური შესახებ მონაცემები.

1658
01:12:46,597 --> 01:12:48,430
და მაშინ მე ვაპირებ
გაიყო, თუ რა მჭირდება.

1659
01:12:48,430 --> 01:12:52,080
და თუ მე მხოლოდ კვეთის გარეთ
რამდენიმე რიგები, მაშინ, რომ OK.

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
შემდეგ მე ვაპირებ, რომ უკეთესი იქნება
off გამოყენებით სპექტრი შეკითხვაზე,

1663
01:13:01,490 --> 01:13:03,030
იმიტომ, რომ ეს ბევრად უფრო შერჩევითი.

1664
01:13:03,030 --> 01:13:06,330
ის აპირებს გადარჩენა ჩემთვის ბევრი
ფული, იმიტომ, რომ მე გადაიხადოს, რომ წაკითხული.

1665
01:13:06,330 --> 01:13:10,430
იმ შემთხვევაში, შედეგი, რომელიც ბრუნდება
გადაკვეთა, რომ მავთული შეიძლება იყოს პატარა,

1666
01:13:10,430 --> 01:13:11,890
მაგრამ მე გადამხდელი წაკითხული.

1667
01:13:11,890 --> 01:13:14,340
ასე რომ, თუ როგორ
თქვენ მიღების მონაცემები.

1668
01:13:14,340 --> 01:13:16,420
ეს ძალიან მნიშვნელოვანია, დინამოში DB.

1669
01:13:16,420 --> 01:13:19,710
>> პირობითი გამონათქვამები, ეს არის ის, რაც
შეიძლება მოვუწოდებთ ოპტიმისტურად საკეტი.

1670
01:13:19,710 --> 01:13:28,470
განახლების არსებობის შემთხვევაში, ან თუ ეს მნიშვნელობა
უდრის, რაც მე დააკონკრეტა.

1671
01:13:28,470 --> 01:13:31,494
და თუ მაქვს დრო ბეჭდით
ჩანაწერი, მე შეიძლება წაიკითხა მონაცემები.

1672
01:13:31,494 --> 01:13:32,535
მე შეიძლება შეიცვალოს, რომ მონაცემები.

1673
01:13:32,535 --> 01:13:35,030
მე რომ წერენ, რომ
მონაცემების უკან მონაცემთა ბაზაში.

1674
01:13:35,030 --> 01:13:38,100
თუ ვინმეს შეიცვალა ჩანაწერი,
დროის ნიშნულს შეიძლება შეიცვალა.

1675
01:13:38,100 --> 01:13:40,370
და რომ გზა ჩემი პირობითი
განახლება, შეიძლება ითქვას განახლება

1676
01:13:40,370 --> 01:13:42,340
იმ შემთხვევაში, თუ დროის ნიშნულს უტოლდება ეს.

1677
01:13:42,340 --> 01:13:46,290
ან განახლება ვერ იმიტომ რომ ვიღაც
განახლებული ჩანაწერი ამასობაში.

1678
01:13:46,290 --> 01:13:48,290
>> ეს არის ის, რაც ჩვენ მოვუწოდებთ ოპტიმისტურად საკეტი.

1679
01:13:48,290 --> 01:13:50,670
ეს ნიშნავს, რომ ვიღაც
შეიძლება დადგეს და შეცვლის,

1680
01:13:50,670 --> 01:13:53,100
და მე ვაპირებ აღმოაჩინოს ის
როდესაც მე დაბრუნდეს დაწერა.

1681
01:13:53,100 --> 01:13:56,106
და მერე შეიძლება რეალურად წავიკითხე, რომ
მონაცემები და თქვათ, მან შეცვალა ეს.

1682
01:13:56,106 --> 01:13:57,230
მე უნდა ანგარიშზე, რომ.

1683
01:13:57,230 --> 01:14:00,490
და შემიძლია შეცვლის მონაცემები ჩემი
ჩაწერა და ვრცელდება კიდევ ერთი განახლება.

1684
01:14:00,490 --> 01:14:04,330
ასე რომ თქვენ შეგიძლიათ დაჭერა იმ დამატებითი
განახლებები რომ მოხდეს შორის დრო

1685
01:14:04,330 --> 01:14:08,740
რომ წაიკითხოთ მონაცემები და
დროს შეიძლება დაწეროს მონაცემები.

1686
01:14:08,740 --> 01:14:11,520
>> აუდიტორია: ფილტრი
გამოთქმაში, ფაქტობრივად, არ ნიშნავს,

1687
01:14:11,520 --> 01:14:13,020
რაოდენობის და not--

1688
01:14:13,020 --> 01:14:14,316
>> [INTERPOSING ხმები]

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
სადაც ჩვენ ვაპირებთ, რომ გაიგო
ზოგიერთი apps აქ.

1705
01:15:02,000 --> 01:15:03,810
რა არის გამოყენების შემთხვევაში დინამო DB.

1706
01:15:03,810 --> 01:15:06,120
რა არის დიზაინი
ნიმუშების დინამო DB.

1707
01:15:06,120 --> 01:15:09,110
>> და პირველი, ჩვენ ვაპირებთ
საუბარი, არის ინტერნეტ რამ.

1708
01:15:09,110 --> 01:15:15,010
ასე რომ, ჩვენ კიდევ ბევრი of-- ვხვდები,
რა არის 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 საათის შემდეგ, Hey, თქვენ
იცით რა, მე არ მაინტერესებს.

1729
01:16:18,120 --> 01:16:21,150
ასე რომ, შესაძლოა ყოველ შუაღამისას მე roll
ჩემი მაგიდა მეტი ახალი მაგიდა

1730
01:16:21,150 --> 01:16:22,430
და მე deprovision ამ მაგიდასთან.

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
ასე რომ, თუ rollover მუშაობს, რომ დიდი.

1758
01:17:25,940 --> 01:17:27,080
თუ არა, მორთვა იგი.

1759
01:17:27,080 --> 01:17:29,640
მაგრამ მოდით შენარჩუნება, რომ ცხელი მონაცემები
დაშორებით თქვენი ცივი მონაცემები.

1760
01:17:29,640 --> 01:17:32,535
ეს გადარჩენა თქვენ ბევრი ფული და
რათა თქვენი მაგიდები უფრო ასრულებენ.

1761
01:17:32,535 --> 01:17:35,960

1762
01:17:35,960 --> 01:17:38,210
ასე რომ, შემდეგი რამ ჩვენ ვსაუბრობთ
შესახებ არის პროდუქციის კატალოგი.

1763
01:17:38,210 --> 01:17:42,000
პროდუქტის კატალოგი
საკმაოდ გავრცელებული გამოყენების შემთხვევაში.

1764
01:17:42,000 --> 01:17:46,600
ეს არის რეალურად ძალიან გავრცელებული ნიმუში
რომ ჩვენ დავინახავთ სხვადასხვა რამ.

1765
01:17:46,600 --> 01:17:48,870
თქვენ იცით, Twitter for
მაგალითად, ცხელი tweet.

1766
01:17:48,870 --> 01:17:51,280
ყველას მოდის და
grabbing რომ tweet.

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
აღწერა out of my პროდუქციის კატალოგი.

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
ასევე, ჩვენ შემსუბუქება ამ cache.

1783
01:18:28,410 --> 01:18:33,630
Cache, დააყენა ძირითადად-მეხსიერება
დანაყოფი თვალწინ მონაცემთა ბაზაში.

1784
01:18:33,630 --> 01:18:37,260
ჩვენ შევძელით
[INAUDIBLE] cache, თუ როგორ

1785
01:18:37,260 --> 01:18:40,260
შეგიძლიათ შექმნას საკუთარი cache, [INAUDIBLE]
cache [? დ?] გაგიხარდებათ.

1786
01:18:40,260 --> 01:18:42,220
იმისათვის, რომ თქვენს წინაშე მონაცემთა ბაზაში.

1787
01:18:42,220 --> 01:18:47,250
და ამ გზით თქვენ შეგიძლიათ შეინახოთ, რომ მონაცემები
იმ ცხელი გასაღებები, რომ cache

1788
01:18:47,250 --> 01:18:49,390
სივრცე და წაიკითხა მეშვეობით cache.

1789
01:18:49,390 --> 01:18:51,962
>> და მაშინ ყველაზე თქვენი ნათქვამია
დაიწყოს ეძებს მოსწონს ეს.

1790
01:18:51,962 --> 01:18:54,920
მე მივიღე ყველა ამ cache ჰიტები აქ
და მე მივიღე არაფერი ხდება ქვემოთ აქ

1791
01:18:54,920 --> 01:18:59,330
იმიტომ, რომ მონაცემთა ბაზაში ზის უკან
cache და ნათქვამია არასოდეს დაასრულებს.

1792
01:18:59,330 --> 01:19:02,520
თუ შევცვალო მონაცემები
მონაცემთა ბაზა, რომ მე უნდა კეშის გასაახლებლად.

1793
01:19:02,520 --> 01:19:04,360
ჩვენ შეგვიძლია გამოვიყენოთ რაღაც
ისევე როგორც steams გაგვაჩნია.

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
და მივიღეთ inbox და outbox.

1800
01:19:17,040 --> 01:19:19,760
ეს არის ის, რაც SQL გვინდა
გამოიყურებოდეს ავაშენოთ, რომ inbox.

1801
01:19:19,760 --> 01:19:23,350
ჩვენ სახის გამოიყენოთ იგივე სახის
სტრატეგიის გამოყენება GSI ის, GSI ს

1802
01:19:23,350 --> 01:19:25,320
ჩემი inbox და ჩემი outbox.

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
გზავნილებიც [INAUDIBLE],
გაგზავნა ID, რომ დიდი.

1807
01:19:33,710 --> 01:19:35,070
ეს არის ჩემი უნიკალური hash.

1808
01:19:35,070 --> 01:19:38,280
მე ვაპირებ, რომ შეიქმნას ორი GSI ის ერთ-ერთი
ჩემი inbox, ერთი ჩემი outbox.

1809
01:19:38,280 --> 01:19:40,530
და პირველი, რასაც მე გავაკეთებ
არის მე ვიტყვი, ჩემი hash გასაღები არის

1810
01:19:40,530 --> 01:19:43,310
იქნება მიმღები და
მე ვაპირებ მოწყობა თარიღი.

1811
01:19:43,310 --> 01:19:44,220
ეს არის ფანტასტიური.

1812
01:19:44,220 --> 01:19:45,890
მე მივიღე ჩემი ლამაზი ხედი აქ.

1813
01:19:45,890 --> 01:19:47,780
მაგრამ არსებობს პატარა საკითხია.

1814
01:19:47,780 --> 01:19:50,891
და თქვენ გადაეყარონ ეს
რელაციური მონაცემთა ბაზების, ისევე.

1815
01:19:50,891 --> 01:19:52,390
მათ მოუწოდეს ვერტიკალურად დაყოფის.

1816
01:19:52,390 --> 01:19:55,840
თქვენ გსურთ, რომ თქვენი დიდი მონაცემები
დაშორებით თქვენი პატარა მონაცემები.

1817
01:19:55,840 --> 01:20:00,470
>> და კიდევ ერთი მიზეზი არის ის, რომ მე მაქვს
წაიკითხავს ელემენტი მისაღებად ატრიბუტები.

1818
01:20:00,470 --> 01:20:05,570
და თუ ჩემი ორგანოები ყველა აქ,
შემდეგ კითხულობს მხოლოდ რამდენიმე ელემენტი

1819
01:20:05,570 --> 01:20:08,560
თუ ჩემი სხეულის სიგრძე
საშუალოდ 256 kilobytes ყოველი,

1820
01:20:08,560 --> 01:20:10,991
მათემატიკის იღებს საკმაოდ მახინჯი.

1821
01:20:10,991 --> 01:20:12,490
ასე ვთქვათ, მე მინდა წაიკითხონ დავითის inbox.

1822
01:20:12,490 --> 01:20:14,520
დავით შემომავალი 50 საკითხი.

1823
01:20:14,520 --> 01:20:17,880
საშუალო და ზომა არის 256 kilobytes.

1824
01:20:17,880 --> 01:20:21,730
აი ჩემი კონვერტაციის რაციონი
ამისთვის RCU ის ოთხი kilobytes.

1825
01:20:21,730 --> 01:20:24,450
>> OK, მოდით წავიდეთ ერთად
საბოლოოდ თანმიმდევრული განცხადებაში.

1826
01:20:24,450 --> 01:20:28,640
მე მაინც ჭამა 1600 RCU ს
მხოლოდ წაკითხვის დავითის inbox.

1827
01:20:28,640 --> 01:20:29,950
ოუჩ.

1828
01:20:29,950 --> 01:20:31,980
OK, ახლა მოდით ვიფიქროთ
იმაზე, თუ როგორ app მუშაობს.

1829
01:20:31,980 --> 01:20:35,340
თუ მე ვარ ელ app და
ვეძებ ჩემი inbox,

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
ეს არის ჩემი inbox GSI.

1835
01:20:50,890 --> 01:20:53,800
ეს თარიღი, გამგზავნი,
სათაური, და შემდეგ

1836
01:20:53,800 --> 01:20:56,790
გაგზავნა ID, რაც მიუთითებს
უკან შეტყობინებები მაგიდა

1837
01:20:56,790 --> 01:20:57,850
სადაც მე შეუძლია მიიღოს ორგანო.

1838
01:20:57,850 --> 01:21:01,260

1839
01:21:01,260 --> 01:21:04,420
ისე, ეს იქნება ჩანაწერი პირადობის მოწმობა.

1840
01:21:04,420 --> 01:21:09,850
ისინი აღვნიშნო უკან
საქონლის მოწმობების დინამო DB მაგიდასთან.

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: დიახ, იგი ეუბნება
, ზუსტად ეს არის ზუსტად ის, რასაც აკეთებს.

1846
01:21:21,420 --> 01:21:22,644
იგი აცხადებს, რომ აქ არის ჩემი ხელახლა ჩანაწერი.

1847
01:21:22,644 --> 01:21:24,310
და ეს თქვენ აღვნიშნო, რომ ეს უკან ჩემი ხელახლა ჩანაწერი.

1848
01:21:24,310 --> 01:21:26,460
ზუსტად.

1849
01:21:26,460 --> 01:21:29,490
OK, ასე რომ, ახლა ჩემი inbox არის
რეალურად ბევრად უფრო მცირეა.

1850
01:21:29,490 --> 01:21:32,210
ეს ფაქტობრივად მხარს უჭერს
სამუშაოს ელ app.

1851
01:21:32,210 --> 01:21:34,230
ასე რომ, ჩემი inbox, მე დააჭირეთ.

1852
01:21:34,230 --> 01:21:38,160
მე გასწვრივ და მე დააწკაპუნეთ გაგზავნა,
ეს მაშინ, როდესაც მე უნდა წავიდეს ორგანოს,

1853
01:21:38,160 --> 01:21:40,180
იმიტომ, რომ მე ვაპირებ
წასვლა განსხვავებული აზრი.

1854
01:21:40,180 --> 01:21:43,870
ასე რომ, თუ თქვენ ფიქრობთ MVC ტიპის
ფარგლებში, მოდელი კალენდარი კონტროლერი.

1855
01:21:43,870 --> 01:21:46,120
>> მოდელი შეიცავს
მონაცემები, რომ ნახოთ საჭიროებების

1856
01:21:46,120 --> 01:21:48,130
და კონტროლერი ურთიერთქმედებს.

1857
01:21:48,130 --> 01:21:51,670
როდესაც მე შეცვლა გადაღების, როდესაც
შევცვალო პერსპექტივა,

1858
01:21:51,670 --> 01:21:55,080
ეს OK დაბრუნდეს
სერვერზე და 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 უბრალოდ უნდა ნახოთ მისი inbox.

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
ჩვენ მივიღეთ ჩვენი hash მიმღები.

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
>> ჩვენ როტაცია, რომ outbox.

1874
01:22:34,300 --> 01:22:35,770
Hash on გამომგზავნი.

1875
01:22:35,770 --> 01:22:39,612
და არსი, ჩვენ გვაქვს
ძალიან ლამაზი, სუფთა ხედი.

1876
01:22:39,612 --> 01:22:41,570
და ეს ძირითადად ჩვენ
ამ ლამაზი შეტყობინებები

1877
01:22:41,570 --> 01:22:45,870
მაგიდა, რომელიც ვრცელდება ლამაზად, რადგან
ეს hash მხოლოდ hashed გაგზავნა ID.

1878
01:22:45,870 --> 01:22:51,750
და ჩვენ გვაქვს ორი ინდექსები, რომ
მოძრავი off, რომ მაგიდაზე.

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
Gaming ამ დღეებში, განსაკუთრებით მასალა
სათამაშო, ყველაფერი არის აზროვნება.

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
>> მაგრამ იდეა სათამაშო ვფიქრობ
შესახებ თვალსაზრისით APIs, 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 APIs.

1897
01:23:40,660 --> 01:23:44,950
>> რამ, როგორიცაა მიიღოს მეგობარი, მიიღეთ
ბანერის, გაცვლის მონაცემები,

1898
01:23:44,950 --> 01:23:47,699
მომხმარებლის გენერირებული შინაარსი,
დააყენებს up სისტემა,

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
და აუცილებლად, multiplayer
სერვერები, უკან ბოლომდე ინფრასტრუქტურა,

1905
01:24:03,550 --> 01:24:06,180
და განკუთვნილია მაღალი
ხელმისაწვდომობა და scalability.

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
მეტი მონაცემების ცენტრი
პოსტი AZ, მაგრამ რომ კარგადაა,

1912
01:24:26,040 --> 01:24:28,831
უბრალოდ ვფიქრობ, რომ მათ ცალკე მონაცემების
ცენტრები, რომლებიც გეოგრაფიულად

1913
01:24:28,831 --> 01:24:30,090
და ბრალი იზოლირებული.

1914
01:24:30,090 --> 01:24:32,172
>> ჩვენ ვაპირებთ, რომ აქვს
ორი EC2 შემთხვევები.

1915
01:24:32,172 --> 01:24:33,880
ჩვენ ვაპირებთ, რომ
ზოგიერთი უკან ბოლომდე სერვერზე.

1916
01:24:33,880 --> 01:24:35,800
შესაძლოა თუ თქვენ მემკვიდრეობა
არქიტექტურა, ჩვენ

1917
01:24:35,800 --> 01:24:38,920
გამოყენებით, რაც ჩვენ მოვუწოდებთ RDS,
რელაციური მონაცემთა ბაზების მომსახურებას.

1918
01:24:38,920 --> 01:24:42,040
შეიძლება იყოს MSSQL, MySQL,
ან რამე მაგდაგვარს.

1919
01:24:42,040 --> 01:24:47,080
ეს არის გზა ბევრი პროგრამები
განკუთვნილია დღეს.

1920
01:24:47,080 --> 01:24:49,594
>> ისე ჩვენ დაგვჭირდება წასვლა
ეს მაშინ, როდესაც ჩვენ მასშტაბის გარეთ.

1921
01:24:49,594 --> 01:24:51,510
ჩვენ წავიდეთ წინ და
S3 bucket იქ.

1922
01:24:51,510 --> 01:24:54,200
და რომ S3 bucket, ნაცვლად ემსახურება
up იმ ობიექტების ჩვენი სერვერები

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
და თქვენ შეგიძლიათ გამოიყენოთ ის სერვერზე
შემთხვევები ემსახურება, რომ მონაცემები up.

1926
01:24:59,751 --> 01:25:01,860
მაგრამ ეს საკმაოდ ძვირი.

1927
01:25:01,860 --> 01:25:05,107
>> უკეთესი გზა ამის გაკეთება არის წავიდეთ წინ და
დააყენოს იმ ობიექტების S3 bucket.

1928
01:25:05,107 --> 01:25:06,315
S3 არის ობიექტი საცავებში.

1929
01:25:06,315 --> 01:25:10,860
ეს აშენდა სპეციალურად
ემსახურება up ამ ტიპის რამ.

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 bucket
როგორც ჩემი წყარო საცავი.

1937
01:25:26,200 --> 01:25:29,370
და მე წინაშე, რომ
CloudFront გავრცელება.

1938
01:25:29,370 --> 01:25:31,720
>> CloudFront არის CD და
შინაარსის მიწოდების ქსელის.

1939
01:25:31,720 --> 01:25:35,750
ძირითადად ეს იღებს მონაცემებს, რომ თქვენ დააკონკრეტა
და ინახავს ბუფერში მთელ ინტერნეტ

1940
01:25:35,750 --> 01:25:39,230
ასე რომ მომხმარებლებს ყველგან შეიძლება ჰქონდეს
ძალიან სწრაფი რეაგირება

1941
01:25:39,230 --> 01:25:40,960
ისინი ითხოვენ იმ ობიექტების.

1942
01:25:40,960 --> 01:25:41,960
>> ასე რომ, თქვენ იდეა.

1943
01:25:41,960 --> 01:25:48,230
თქვენ სახის ოპერაციული ყველა
ასპექტები AWS აქ ამ გაკეთდეს.

1944
01:25:48,230 --> 01:25:50,790
და ბოლოს, ჩვენ გადაყარეთ
ავტო სკალირების ჯგუფი.

1945
01:25:50,790 --> 01:25:52,737
ასე რომ, ჩვენი AC2 შემთხვევები
ჩვენი თამაში სერვერები,

1946
01:25:52,737 --> 01:25:54,820
როგორც ისინი დაიწყოს busier
და ხალხმრავალი და ხალხმრავალი,

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
და თუ დატვირთვის ბრუნდება,
ის ყველაფერს იზრდება უკან, elastically.

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
შევეცადოთ აყენებს
cache წინაშე, რომ.

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
Cache არ მუშაობს, როდესაც თქვენ
წერენ მძიმე, რადგან თქვენ ყოველთვის

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
თქვენ მოხვდით დიდი bottleneck
ქვემოთ არსებობს მონაცემთა ბაზაში.

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
თქვენ ამბობთ, მომხმარებლებს შორის და 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
თქვენ გაქვთ ოპერაციული შეზღუდვების
რომ არ span დანაყოფი.

1981
01:27:18,670 --> 01:27:20,560
თქვენ მოხვდით ყველა სახის
messiness, რომ თქვენ

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
ეს უბრალოდ არ fun.

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: Source რაოდენობა?

1990
01:27:34,410 --> 01:27:37,500
აუდიტორია: საწყისი საინფორმაციო,
სადაც ინფორმაცია მოდის?

1991
01:27:37,500 --> 01:27:38,250
RICK Houlihan: No.

1992
01:27:38,250 --> 01:27:41,820
რა მე ვამბობ, იზრდება
ნომერი დანაყოფები მონაცემების მაღაზია

1993
01:27:41,820 --> 01:27:44,060
აუმჯობესებს გამტარუნარიანობა.

1994
01:27:44,060 --> 01:27:48,300
ასე რომ, რა ხდება აქ არის მომხმარებლები
მოსვლის EC2 მაგალითად აქ,

1995
01:27:48,300 --> 01:27:50,780
ასევე, თუ მე უნდა შესახებ
ეს არის ის, ა M, მე წასვლა აქ.

1996
01:27:50,780 --> 01:27:53,560
საწყისი N to p, მე წასვლა აქ.

1997
01:27:53,560 --> 01:27:55,060
საწყისი P to Z, მე წასვლა აქ.

1998
01:27:55,060 --> 01:27:57,120
>> აუდიტორია: OK, იმ ასე რომ, ეს არის
ყველა ინახება სხვადასხვა კვანძების?

1999
01:27:57,120 --> 01:27:57,911
>> RICK Houlihan: დიახ.

2000
01:27:57,911 --> 01:28:00,210
ვფიქრობ, ეს როგორც
სხვადასხვა silos მონაცემები.

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
გავაფართოვოთ on რელატიური პლატფორმა,
ეს არის, თუ რას აკეთებს.

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
ეს არ არის fun.

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
on, ქულების ამ მომხმარებლის მიერ.

2021
01:28:52,930 --> 01:28:57,700
ჩვენ შეიძლება ჰეშირება წლის UserId,
და მაშინ ჩვენ გვაქვს სპექტრი თამაში.

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
ასე რომ, მისი პირადი leaderboard.

2025
01:29:04,000 --> 01:29:10,010
>> ახლა მინდა, რომ წავიდეს და მე მინდა, რომ მივიღო
ასე რომ მე ეს პირადი ბანერს.

2026
01:29:10,010 --> 01:29:12,827
რა მინდა წავიდეს მისაღებად
დაბრუნება ანგარიშით მთელი მომხმარებლებს.

2027
01:29:12,827 --> 01:29:13,660
ასე რომ, როგორ შემიძლია ამის გაკეთება?

2028
01:29:13,660 --> 01:29:18,070
როდესაც ჩემი რეკორდი hashed on
UserId, განმეორებადი თამაში,

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
>> ახლა მე ვაპირებ hash შესახებ
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
მაგრამ მე შექმნის bucket, რომელიც იძლევა
მე აგრეგაციას დაბრუნება ანგარიში თამაში.

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
Sparse ინდექსები არიან
უნარი გენერირება

2043
01:30:07,340 --> 01:30:10,850
ინდექსი, რომელიც არ არის აუცილებელი
შეიცავდეს თითოეული ელემენტის მაგიდაზე.

2044
01:30:10,850 --> 01:30:11,470
და რატომ არა?

2045
01:30:11,470 --> 01:30:14,540
იმის გამო, რომ ატრიბუტი, რომელიც მიმდინარეობს
ინდექსირებული არ არსებობს ყველა ნივთი.

2046
01:30:14,540 --> 01:30:16,460
>> ასე რომ, ამ კონკრეტულ
გამოყენების შემთხვევაში, მე ვამბობ,

2047
01:30:16,460 --> 01:30:19,240
იცით რა, მე ვაპირებ
შექმნა ატრიბუტი მოუწოდა ჯილდო.

2048
01:30:19,240 --> 01:30:22,970
და მე ვაპირებ, რათა ყველა შესახებ
რომ აქვს ჯილდო, რომ მიეწერა.

2049
01:30:22,970 --> 01:30:25,950
მომხმარებელი რომ არ აქვს ჯილდო
არ ვაპირებ, რომ ატრიბუტი.

2050
01:30:25,950 --> 01:30:27,800
ასე რომ, როდესაც მე შექმნა
ინდექსი, მხოლოდ ის მომხმარებლები

2051
01:30:27,800 --> 01:30:28,960
რომ ვაპირებთ, რომ დავანახოთ
მდე ინდექსი არის

2052
01:30:28,960 --> 01:30:31,050
პირობა, რომ რეალურად არ მოიგო ჯილდო.

2053
01:30:31,050 --> 01:30:34,440
ასე რომ, დიდი გზა უნდა შეეძლოს
უნდა შეიქმნას გაფილტრული ინდექსები, რომ

2054
01:30:34,440 --> 01:30:40,580
ძალიან, ძალიან შერჩევითი, რომ არ
უნდა ინდექსი მთელი მაგიდა.

2055
01:30:40,580 --> 01:30:43,050
>> ასე რომ, ჩვენ ვიღებთ დაბალი დროულად აქ.

2056
01:30:43,050 --> 01:30:49,190
მე ვაპირებ წავიდეთ წინ და გამოტოვოთ
გარეთ და გამოტოვოთ ეს საქმე.

2057
01:30:49,190 --> 01:30:52,625
ვისაუბროთ ცოტა ამაზე

2058
01:30:52,625 --> 01:30:54,460
>> აუდიტორია: შემიძლია ვთხოვო სწრაფი კითხვა?

2059
01:30:54,460 --> 01:30:56,722
ერთ-ერთი არის წერენ მძიმე?

2060
01:30:56,722 --> 01:30:57,680
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
ასე რომ, მე მივიღე ეს app.

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 და 1000,
შორის ან ერთი და 1000,

2109
01:32:56,620 --> 01:32:59,940
თუმცა ბევრი შემთხვევითი ღირებულებები გსურთ
დამატება გადატანა ბოლომდე, რომ კანდიდატი.

2110
01:32:59,940 --> 01:33:01,330
>> და რა მე ნამდვილად კეთდება მაშინ?

2111
01:33:01,330 --> 01:33:05,830
თუ მე გამოყენებით კანდიდატი ID როგორც
ვედრო რომ საერთო რაოდენობა,

2112
01:33:05,830 --> 01:33:08,780
თუ მე დასძინა შემთხვევითი
ნომერი ბოლომდე, რომ

2113
01:33:08,780 --> 01:33:12,000
მე შეიქმნა ახლა 10 თაიგულების, რომელიც
ასი თაიგულების, ათასი თაიგულების

2114
01:33:12,000 --> 01:33:14,160
რომ მე აგრეგაცია რაოდენობა მასშტაბით.

2115
01:33:14,160 --> 01:33:18,030
>> ასე რომ, მე მილიონობით და მილიონობით,
და მილიონობით ჩანაწერები მოდის

2116
01:33:18,030 --> 01:33:22,050
ამ კანდიდატებს, მე ახლა გავრცელების
იმ რაოდენობა მასშტაბით კანდიდატი A_1

2117
01:33:22,050 --> 01:33:24,630
მეშვეობით კანდიდატი A_100, რადგან
ყოველ ჯერზე ხმა მოდის,

2118
01:33:24,630 --> 01:33:26,530
მე გამოიმუშავებს შემთხვევითი
მნიშვნელობა ერთიდან 100.

2119
01:33:26,530 --> 01:33:29,446
მე tacking გადატანა ბოლოს
კანდიდატი, რომელიც პირის ხმას.

2120
01:33:29,446 --> 01:33:31,120
მე გადაყრა შევიდა, რომ bucket.

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
და მაშინ მე გაფანტულ იკრიბებიან
მე მივალ და აცხადებენ, hey,

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
იმის გამო, რომ, როდესაც თქვენ საქმე
იმ დიდი aggregations,

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
არის თქვენ სავაჭრო off წაკითხული
ღირებულება ჩაწერის 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
ასე რომ, ჩვენ figured, თუ როგორ გავაფართოვოთ ეს.

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
ნებისმიერი მონაცემების რომ იწერება
ცხრილი გვიჩვენებს up ნაკადი.

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
ვისაუბროთ apps აკეთებს წაქცევისათვის სხვ.

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
ასე რომ, რა მიდის ქვემოთ და ბრუნდება
up, რომ ხდება ქვეშ.

2219
01:37:40,580 --> 01:37:43,844
ეს covers-- ეს OK.

2220
01:37:43,844 --> 01:37:46,260
ყველა უფლება, ასე რომ თქვენ მიიღოთ სხვადასხვა
კალენდარი სახის off ეკრანზე.

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
თქვენ შეგიძლიათ ორივე ძველი და ახალი images.

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
ასე რომ ეს არის ტიპის ნახვა
რომ თქვენ მიიღოს off ნაკადი

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
ნაკადს განათავსოს, რაც ჩვენ მოვუწოდებთ shards.

2245
01:38:44,750 --> 01:38:47,380
Shards არიან მასშტაბური
დამოუკიდებლად მაგიდასთან.

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 Tablespace

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
იგი დგას მდე თანამშრომელი ყოველი shard.

2270
01:40:01,140 --> 01:40:04,620
იგი ქმნის ადმინისტრაციული მაგიდა
ყველა shard, ყველა თანამშრომელი.

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
ასე რომ, როდესაც იგი იღებს off თვითმფრინავი, მას აქვს
კარგი გამოცდილება გამოყენებით მისი მობილური აპლიკაცია.

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
მინდა ამის გაკეთება გიჟები რამ, რომ მონაცემები
ფილტრი, იმეორებს მხოლოდ ნაწილი,

2292
01:41:10,740 --> 01:41:14,120
როტაცია მონაცემები, გადატანა შევიდა
სხვადასხვა მაგიდა, ასე შემდეგ და ასე შემდეგ.

2293
01:41:14,120 --> 01:41:18,700

2294
01:41:18,700 --> 01:41:20,520
ასე რომ, ასეთი რა, რომ ჰგავს.

2295
01:41:20,520 --> 01:41:23,690
>> DynamoDB ნაკადს შეიძლება იყოს
დამუშავებული, რაც ჩვენ მოვუწოდებთ ლამბდა.

2296
01:41:23,690 --> 01:41:27,394
ჩვენ აღვნიშნეთ, ცოტა შესახებ ღონისძიება
ორიენტირებული განაცხადის არქიტექტორები.

2297
01:41:27,394 --> 01:41:28,810
ლამბდა არის ძირითად კომპონენტს, რომ.

2298
01:41:28,810 --> 01:41:32,840
ლამბდა არის კოდი, რომელიც ხანძრის მოთხოვნის
საპასუხოდ კონკრეტული ღონისძიება.

2299
01:41:32,840 --> 01:41:36,020
ერთ-ერთი ასეთი ღონისძიებები შეიძლება იყოს
ჩანაწერი გამოჩენა ნაკადი.

2300
01:41:36,020 --> 01:41:39,100
იმ შემთხვევაში, თუ ჩანაწერი, როგორც ჩანს, ნაკადი,
ჩვენ მოვუწოდებთ ამ Java ფუნქცია.

2301
01:41:39,100 --> 01:41:44,980
ისე, ეს არის JavaScript და ლამბდა
მხარს უჭერს Node.js, Java, Python,

2302
01:41:44,980 --> 01:41:47,820
და მალე მხარს დაუჭერს
სხვა ენებზეც.

2303
01:41:47,820 --> 01:41:50,940
და საკმარისია ითქვას, რომ ეს არის წმინდა კოდი.

2304
01:41:50,940 --> 01:41:53,610
წერა Java, განსაზღვრავს კლასს.

2305
01:41:53,610 --> 01:41:55,690
თქვენ დააყენებს JAR დაყოფილია ლამბდა.

2306
01:41:55,690 --> 01:42:00,200
და მაშინ დააკონკრეტა, რომელიც კლასის
მოვუწოდებთ საპასუხოდ, რომელიც ღონისძიება.

2307
01:42:00,200 --> 01:42:04,770
და მერე ლამბდა ინფრასტრუქტურის
უკან, რომელიც აწარმოებს, რომ კოდი.

2308
01:42:04,770 --> 01:42:06,730
>> ეს კოდი შეიძლება დამუშავება
ჩანაწერების off ნაკადი.

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
თუ ის დოკუმენტის სტრუქტურა,
თქვენ შეგიძლიათ flatten სტრუქტურა.

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
ისინი მოდის off სიმებიანი.

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
>> ჩვენ ვისაუბრეთ თუ როგორ უნდა დააყენოს cache
თვალწინ მონაცემთა ბაზა, რომ გაყიდვების

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
თუ მე განაახლოთ ნივთი აღწერა, იგი ყველაფერს
შეარჩიო ჩანაწერი off ნაკადი,

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
ჩვენ ვაკეთებთ out scatter აგროვებს
მასშტაბით მრავალი თაიგულების.

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 ბრალია ტოლერანტობის,
scalable აგრეგაციას ახლა.

2345
01:43:35,895 --> 01:43:38,270
იმ შემთხვევაში, თუ რამ მოდის დასრულდა,
იცის, სად უნდა გადატვირთეთ თავად

2346
01:43:38,270 --> 01:43:41,300
როდესაც ის ბრუნდება, რადგან
ჩვენ გამოყენებით KCL app.

2347
01:43:41,300 --> 01:43:45,700
და მაშინ ჩვენ ასევე შეგიძლიათ გამოიყენოთ, რომ
KCL განაცხადის დააყენებს მონაცემებს

2348
01:43:45,700 --> 01:43:48,820
რომ წითელი წანაცვლების სხვა
app ანალიტიკა, ან გამოყენება

2349
01:43:48,820 --> 01:43:51,990
ელასტიური MapReduce აწარმოებს
რეალურ დროში ნაკადი aggregations off

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
თქვენ შეგიძლიათ შეაგროვოთ დე dupe
მონაცემები, ყველა სახის

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
ძირითადად, თქვენ შეგიძლიათ Hook ეს
მდე არაფერი გსურთ.

2366
01:44:37,090 --> 01:44:45,600
პროგრამები აშენდა გამოყენებით დინამო მოიცავს
ლამბდა, ElastiCache, CloudSearch,

2367
01:44:45,600 --> 01:44:49,890
დააყენებს მონაცემები შევიდა ელასტიური
MapReduce, იმპორტი ექსპორტი DynamoDB

2368
01:44:49,890 --> 01:44:52,370
შევიდა S3, ყველა სახის workflows.

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
იყოს ცოტა ბმული განაცხადა, click
აქ უნდა უპასუხოს კვლევის.

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
>> ეს ფორმა მოდის,
იტვირთება up ბრაუზერში.

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

2387
01:45:41,780 --> 01:45:46,270
API Gateway უბრალოდ ვებ API
რომ თქვენ უნდა განსაზღვროს და Hook up

2388
01:45:46,270 --> 01:45:47,760
რაც გაგიხარდებათ.

2389
01:45:47,760 --> 01:45:50,990
ამ კონკრეტულ შემთხვევაში, ჩვენ
hooked მდე ლამბდა ფუნქცია.

2390
01:45:50,990 --> 01:45:54,797
>> ასე რომ, ჩემი POST ოპერაცია
ხდება არ სერვერზე.

2391
01:45:54,797 --> 01:45:56,380
ფაქტობრივად, ეს არის API Gateway ზის იქ.

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
და ღირს ჩემთვის არაფერი, სანამ
ხალხი დაიწყებს hitting იგი.

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
>> ასე რომ, მე გაიყვანოს ფორმა
ქვემოთ გარეთ bucket,

2398
01:46:12,310 --> 01:46:15,719
და მე პოსტი მეშვეობით API
კარიბჭე შევიდა ლამბდა ფუნქცია.

2399
01:46:15,719 --> 01:46:17,510
და მერე ლამბდა
ფუნქცია ამბობს, რომ თქვენ იცით,

2400
01:46:17,510 --> 01:46:20,600
რა, მე მივიღე რამდენიმე PIIs, ზოგიერთი
პერსონალურად ამოცნობადი ინფორმაცია

2401
01:46:20,600 --> 01:46:21,480
ამ რეაგირება.

2402
01:46:21,480 --> 01:46:23,020
მე მივიღე კომენტარი მოდის მომხმარებლებს.

2403
01:46:23,020 --> 01:46:24,230
მაქვს ელექტრონული ფოსტის მისამართები.

2404
01:46:24,230 --> 01:46:26,190
მაქვს სახელები.

2405
01:46:26,190 --> 01:46:27,810
>> მიადევნე თვალი გაყოფილი ამ off.

2406
01:46:27,810 --> 01:46:30,280
მე ვაპირებ წარმოქმნის
მეტამონაცემების off ამ ჩანაწერში.

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

2411
01:46:42,800 --> 01:46:47,240
ასე რომ, მე გამოიყენოთ აგებული S3 სერვერის მხარეს
კოდირების და Amazon- ის Key Management

2412
01:46:47,240 --> 01:46:51,600
სამსახურის, ისე, რომ მე მაქვს გასაღები, რომელიც
შეგიძლიათ როტაცია რეგულარულ ინტერვალის,

2413
01:46:51,600 --> 01:46:55,010
და შემიძლია დაიცვას PII მონაცემები
როგორც ნაწილი ამ მთელი workflow.

2414
01:46:55,010 --> 01:46:55,870
>> ასე რომ, რა ჩავიდინე?

2415
01:46:55,870 --> 01:47:00,397
მე უბრალოდ განლაგებული მთელი
პროგრამა, და მე არ მაქვს სერვერზე.

2416
01:47:00,397 --> 01:47:02,980
ასე რომ, რა ღონისძიება ორიენტირებული პროგრამა
არქიტექტურა აკეთებს.

2417
01:47:02,980 --> 01:47:05,730
>> ახლა, თუ ფიქრობთ
გამოყენების შემთხვევაში ამას

2418
01:47:05,730 --> 01:47:08,730
ჩვენ სხვა მომხმარებელს ვსაუბრობ
დაახლოებით ამ ზუსტი არქიტექტურის, რომელიც

2419
01:47:08,730 --> 01:47:14,560
აწარმოებს ფენომენალურად დიდი კამპანია, რომელიც
ეძებს და აპირებს, oh my.

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 არის ძალიან, ძალიან კარგი
ემსახურება up ობიექტები.

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 Gateway არ არის სერვერზე მსგავსი,

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
მოითხოვოს და MAP- ის სხვა პროცესი.

2452
01:48:38,040 --> 01:48:39,192
რომ ყველა ის აკეთებს.

2453
01:48:39,192 --> 01:48:41,525
და ამ შემთხვევაში, ჩვენ ვგეგმავდით
მას ლამბდა ფუნქცია.

2454
01:48:41,525 --> 01:48:44,119

2455
01:48:44,119 --> 01:48:45,410
ყველა უფლება, ასე რომ ყველა მე მივიღე.

2456
01:48:45,410 --> 01:48:46,190
დიდი მადლობა.

2457
01:48:46,190 --> 01:48:46,800
ვაფასებ.

2458
01:48:46,800 --> 01:48:48,100
მე ვიცი, რომ ჩვენ გვინდა, ცოტა მეტი დრო.

2459
01:48:48,100 --> 01:48:49,980
და იმედია თქვენ ბიჭები
ცოტა ინფორმაცია

2460
01:48:49,980 --> 01:48:51,410
რომ თქვენ შეიძლება წართმევას დღეს.

2461
01:48:51,410 --> 01:48:53,520
და მე ბოდიშს თუ მივედი
მეტი ზოგიერთი თქვენი ხელმძღვანელები,

2462
01:48:53,520 --> 01:48:56,697
მაგრამ არსებობს კარგი ბევრი
ძირითადი ფუნდამენტური ცოდნა

2463
01:48:56,697 --> 01:48:58,280
რომ მე ვფიქრობ, ძალიან მნიშვნელოვანია თქვენთვის.

2464
01:48:58,280 --> 01:48:59,825
ასე რომ მადლობა გადაგიხადოთ იმისთვის, რომ ჩემთვის.

2465
01:48:59,825 --> 01:49:00,325
[ტაში]

2466
01:49:00,325 --> 01:49:02,619
აუდიტორია: [INAUDIBLE]
არის, როდესაც თქვენ ამბობდნენ,

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
როგორ მოხდება ღირებულებების
შეიცვალოს, თუ [INAUDIBLE].

2470
01:49:09,410 --> 01:49:10,480
>> RICK Houlihan: Oh, 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
მაშინ მე არ ვიცი, რა იცვლება
გაკეთდა ბოლო mile.

2474
01:49:19,770 --> 01:49:22,144
ეს არ იქნება
იგივე მონაცემები, რაც ვნახე.

2475
01:49:22,144 --> 01:49:24,560
აუდიტორია: Oh, ასე რომ თქვენ მხოლოდ
არ მიღებული მთელი შეყვანა.

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
ჩვენ გაატარა ბევრი დრო, რომ
ძირითადი ღირებულება ერთად hash და გზები

2482
01:49:38,740 --> 01:49:40,005
Flip ეს გარშემო.

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
იმ ობიექტების გამოყენებით Object ნოტაცია.

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
წინააღმდეგი და მინდა ვთქვა, OK,

2502
01:50:24,340 --> 01:50:26,030
რა არის უძრავი ქონება მინდა ინდექსი?

2503
01:50:26,030 --> 01:50:28,717
>> თქვენ შექმნით წარმოებული მაგიდასთან.

2504
01:50:28,717 --> 01:50:30,300
ახლა, ისე, როგორც ეს ახლა.

2505
01:50:30,300 --> 01:50:32,650
ჩვენ არ გაძლევთ საშუალებას ინდექსი
პირდაპირ იმ თვისებებს.

2506
01:50:32,650 --> 01:50:33,520
>> აუდიტორია: Tabularizing თქვენი დოკუმენტები.

2507
01:50:33,520 --> 01:50:36,230
>> RICK Houlihan: კერძოდ, flattening
ის, 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: Yep,
აბსოლუტურად, მადლობა.

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