[მუსიკის დაკვრა] RICK Houlihan ყველა უფლება. გამარჯობა ყველას. ჩემი სახელი არის Rick Houlihan. მე ვარ უფროსი ძირითადი გადაწყვეტილებები არქიტექტორი AWS. მე ფოკუსირება NoSQL და DynamoDB ტექნოლოგიები. მე დღეს აქ გაიგო, რომ თქვენ ცოტა იმ. 

ჩემი ფონზე პირველ რიგში მონაცემების ფენა. მე ნახევარი ჩემი განვითარების კარიერა წერილობით მონაცემთა ბაზა, მონაცემთა ხელმისაწვდომობის, გადაწყვეტილებების სხვადასხვა პროგრამები. მე უკვე Cloud ვირტუალიზაციის დაახლოებით 20 წლის განმავლობაში. ასე რომ სანამ Cloud იყო Cloud, ჩვენ მოვუწოდებთ მას კომუნალური computing. და იდეა იყო, ეს როგორც PG & E, იხდით რასაც თქვენ იყენებთ. დღეს ჩვენ მას ღრუბელი. 

მაგრამ წლების განმავლობაში ვმუშაობდი რამდენიმე კომპანიების თქვენ ალბათ არასოდეს მსმენია. მაგრამ მე შედგენილი სია ტექნიკური მიღწევების, ვფიქრობ, თქვენ მინდა ვთქვა. მაქვს რვა პატენტების Cloud სისტემები ვირტუალიზაციის, მიკროპროცესორული დიზაინი, კომპლექსური ღონისძიება დამუშავება, და სხვა სფეროებში, ასევე. 

ასე რომ, ამ დღეებში, მე ფოკუსირება ძირითადად NoSQL ტექნოლოგიები და მომავალ თაობას მონაცემთა ბაზაში. და რომ ზოგადად, რაც მე ვაპირებ უნდა იყოს აქ საუბარი თქვენ დღეს. ასე რომ, რას შეიძლება ველოდოთ ამ სხდომაზე, ჩვენ გაიაროს მოკლე ისტორია მონაცემთა დამუშავება. ის ყოველთვის სასარგებლოა მესმის, სადაც ჩვენ მოვიდა და რატომ ვართ აქ ვართ. და ჩვენ ვსაუბრობთ პატარა ცოტა შესახებ NoSQL ტექნიკა საწყისი ფუნდამენტური თვალსაზრისით. 

ჩვენ შეღწევას ზოგიერთი DynamoDB შინაგანი. DynamoDB არის AWS ის გემოს. ეს სრულად მოახერხა და უმასპინძლა NoSQL გადაწყვეტა. და ჩვენ გაიგო ცოტა შესახებ მაგიდა სტრუქტურა, APIs, მონაცემთა ტიპები, ინდექსები, და ზოგიერთი შინაგანი რომ DynamoDB ტექნოლოგია. ჩვენ შეღწევას ზოგიერთი დიზაინი ნიმუშების და საუკეთესო პრაქტიკის. ჩვენ ვსაუბრობთ, თუ როგორ გამოიყენოს ეს ტექნოლოგია რამდენიმე დღევანდელი პროგრამა. და მაშინ ჩვენ გაიგო ცოტა ევოლუციის ან წარმოქმნას ახალი პარადიგმის პროგრამირებაში მოუწოდა ღონისძიება ორიენტირებული პროგრამები და როგორ DynamoDB უკრავს, რომ ისევე. და ჩვენ დავტოვებთ თქვენ ცოტა მინიშნება არქიტექტურა დისკუსია ასე რომ ჩვენ შეგვიძლია ვისაუბროთ ზოგიერთ გზები შეგიძლიათ გამოიყენოთ DynamoDB. 

ასე რომ, პირველი off-- ეს არის საკითხი, მე მესმის ბევრი არის, რა არის მონაცემთა ბაზაში. ბევრი ადამიანი ფიქრობს, რომ ისინი იცით, რა მონაცემთა ბაზა. თუ თქვენ Google, დაინახავთ, ეს. ეს არის სტრუქტურირებული კომპლექტი მონაცემები გაიმართა კომპიუტერი, განსაკუთრებით ერთი, რომ არის ხელმისაწვდომი სხვადასხვა გზები. მე ვფიქრობ, რომ კარგი განმარტება თანამედროვე მონაცემთა ბაზაში. მაგრამ მე არ მომწონს, რადგან ეს იმას ნიშნავს, რამდენიმე რამ. ეს იმას ნიშნავს, სტრუქტურა. და ეს იმას ნიშნავს, რომ ის კომპიუტერი. და მონაცემთა ბაზების არ ყოველთვის არსებობს კომპიუტერი. მონაცემთა ბაზა რეალურად არსებობდა მრავალი გზა. 

ასე რომ, უკეთესი განსაზღვრება მონაცემთა ბაზა რაღაც მსგავსი. მონაცემთა ბაზა არის ორგანიზებული მექანიზმი შენახვის, მართვისა, და ძებნისათვის ინფორმაცია. ეს არის საწყისი About.com. ასე რომ, მე მიყვარს ეს, რადგან ეს მართლაც მოლაპარაკებები შესახებ მონაცემთა ბაზაში მყოფი საცავი, საცავი ინფორმაცია, არ არის აუცილებელი რაღაც რომ ზის კომპიუტერი. და მთელი ისტორიის მანძილზე, ჩვენ ყოველთვის არ ჰქონდა კომპიუტერი. 

ახლა კი, თუ მე ვთხოვ საშუალო დეველოპერი დღეს რა არის მონაცემთა ბაზა, რომ პასუხი მივიღო. სადღაც შეგიძლიათ გამყარებაში პერსონალი. მარჯვენა? და ეს სიმართლეა. მაგრამ ეს ძალიან სამწუხაროა. იმის გამო, რომ მონაცემთა ბაზაში მართლაც საფუძველი თანამედროვე app. ეს არის საფუძველი ყველა განცხადება. და როგორ ავაშენოთ, რომ მონაცემთა ბაზა, თუ როგორ სტრუქტურირებაზე რომ მონაცემები აპირებს უკარნახოს, თუ როგორ, რომ განაცხადის ასრულებს, როგორც თქვენ მასშტაბით. 

ასე რომ ბევრი ჩემი სამუშაო დღეს საქმე რა ხდება, როდესაც დეველოპერები ასეთი მიდგომა და საქმე შემდგომ განაცხადის რომელიც ახლა სკალირების მიღმა ორიგინალური განზრახვა და ტანჯვის ცუდი დიზაინი. ასე რომ, იმედია, როცა ფეხით დაშორებით დღეს, თქვენ აქვს რამდენიმე ინსტრუმენტები თქვენი ქამარი, რომ გავაგრძელებთ თქვენ მიღების იმ იგივე შეცდომები. კარგი. ასე რომ, მოდით ვისაუბროთ ცოტა ვადები მონაცემთა ბაზის ტექნოლოგია. მე ვფიქრობ, რომ წავიკითხე სტატია არ არის, რომ დიდი ხნის წინ და განაცხადა, რაღაც ხაზები ეს არის ძალიან პოეტური განცხადებაში. მისი თქმით, ეს ისტორია მონაცემთა დამუშავება სრული მაღალი watermarks მონაცემთა სიუხვით. კარგი. ახლა, ვფიქრობ, რომ ეს ერთგვარი ნამდვილი. მაგრამ მე რეალურად შევხედოთ არის, როგორც ისტორიაში რეალურად შევსებული მაღალი watermark მონაცემების ზეწოლა. იმის გამო, რომ მონაცემები განაკვეთი შიგნით მიღებისას არასოდეს მიდის ქვემოთ. ეს მხოლოდ მიდის. 

და ინოვაციების ხდება, როდესაც ჩვენ ვხედავთ მონაცემების ზეწოლა, რომელიც არის ოდენობით მონაცემები, რომ ახლა შემოდის სისტემა. და ეს არ შეიძლება დამუშავებული ეფექტურად არც დრო და ღირებულება. და ეს მაშინ, როდესაც ჩვენ დავიწყებთ შევხედოთ მონაცემები ზეწოლა. 

ასე რომ, როდესაც ჩვენ შევხედავთ პირველი ბაზაში, ეს არის ერთი, რომ იყო შორის ჩვენი ყურები. ჩვენ ყველა ერთად დაიბადა იგი. კარგია, მონაცემთა ბაზაში. მას აქვს მაღალი ხელმისაწვდომობა. ეს ყოველთვის. თქვენ ყოველთვის შეგიძლიათ მიიღოთ იგი. 

მაგრამ ეს ერთი შესახებ. მე ვერ გაიზიარებს ჩემს აზრებს თქვენთან ერთად. თქვენ არ შეგიძლიათ მიიღოთ ჩემი აზრები როდესაც გსურთ მათ. მათი abilitiy ასე არ არის კარგი. ჩვენ დაგვავიწყდეს რამ. ყველა ახლა და შემდეგ, ერთი ჩვენგანი ფოთლები და მოძრაობს სხვა არსებობა და ჩვენ ყველაფერს დაკარგავს რომ იყო იმ მონაცემთა ბაზაში. ასე რომ, ეს არ არის ყველა, რომ კარგი. 

და ეს კარგად მუშაობდა, დროთა განმავლობაში როდესაც ჩვენ უკან დღეს როცა ყველა ჩვენ ნამდვილად საჭიროა იცოდეთ არის ის, სად მივდივართ წასვლა ხვალ ან სადაც ვიკრიბებით საუკეთესო საკვები. მაგრამ, როგორც ჩვენ დავიწყეთ იზრდება ცივილიზაციის და ხელისუფლებამ დაიწყო მოვიდეს ყოფნა და ბიზნესის დაიწყო განვითარება, ჩვენ დავიწყეთ გააცნობიეროს, რომ ჩვენ უნდა ცოტა მეტი, ვიდრე ჩვენ ვერ დააყენა ჩვენი უფროსი. კარგი? 

ჩვენ საჭირო სისტემების ჩანაწერი. ჩვენ საჭირო ადგილებში შეძლებს მაღაზია მონაცემები. ასე რომ, ჩვენ დავიწყეთ წერა დოკუმენტები, შექმნა ბიბლიოთეკებისა და არქივების. ჩვენ დავიწყეთ განვითარებადი სისტემის ledger საბუღალტრო. და რომ სისტემა ledger დათვლა გაიქცა სამყარო საუკუნეების განმავლობაში, და შესაძლოა კიდევ ათასწლეულების როგორც ჩვენ სახის გაიზარდა, რათა წერტილი სადაც, რომ მონაცემები დატვირთვის აჯობა უნარი იმ სისტემები შეძლებს შეიცავდეს იგი. 

და ეს მოხდა სინამდვილეში 1880. მარჯვენა? In 1880 აშშ აღწერის. ეს მართლაც, სადაც გადამწყვეტი მეტიც, თანამედროვე მონაცემების დამუშავება. ეს არის წერტილი რომელიც თანხის მონაცემები რომელიც მიმდინარეობს მიერ შეგროვებული აშშ-ის მთავრობამ მიიღო, რათა წერტილი სადაც მას რვა წლის დამუშავებას. 

ახლა, რვა years-- როგორც თქვენ იცით, აღწერის გადის ყოველ 10 years-- ასე რომ, ეს საკმაოდ აშკარაა, რომ ჩვენ მიიღო 1890 წლის აღწერის მონაცემებით, თანხის მონაცემები, რომ მიდიოდა დამუშავებული ხელისუფლების მიერ იყო აპირებს აღემატებოდეს 10 წლის, რომ ეს დასჭირდება დაიწყო ახალი აღწერის მონაცემებით. ეს იყო პრობლემა. 

ასე რომ, ბიჭი სახელად ჰერმან Hollerith მოვიდა გასწვრივ და მან გამოიგონა ერთეული ჩანაწერი punch ბარათები, Punch ბარათის წამკითხველი, Punch ბარათის tabulator და შედარებაზე მექანიზმები ამ ტექნოლოგიის. და რომ კომპანია, რომ იქმნება დრო, ერთად რამდენიმე სხვები, გახდა ერთ-ერთი საყრდენი ერთი მცირე კომპანია ვიცით, დღეს მოუწოდა IBM. 

ასე რომ, IBM თავდაპირველად იყო მონაცემთა ბაზის ბიზნესი. და ეს მართლაც, რა გააკეთეს. მათ გააკეთეს მონაცემების დამუშავება. 

როგორც ასე გავრცელებით punch ბარათები, გენიალურად მექანიზმები მიმდინარეობს შეუძლია ბერკეტები, რომ ტექნიკა გამოკითხვა დახარისხებული შედეგი კომპლექტი. თქვენ შეგიძლიათ ნახოთ ამ სურათს არ გვაქვს little-- ეს არის პატარა small-- მაგრამ თქვენ ხედავთ ძალიან ეშმაკურ მექანიკური მექანიზმი სადაც ჩვენ გვაქვს Punch ბარათის deck. და ვინმეს აყვანა პატარა screwdriver და sticking მეშვეობით სლოტი და მოხსნას ეს მდე უნდა, რომ მატჩი, რომ დალაგებულია შედეგების მითითებული. 

ეს არის აგრეგაციას. ჩვენ ამას ვაკეთებთ, ყველა დროის დღეს კომპიუტერი, სადაც თქვენ ამის გაკეთება მონაცემთა ბაზაში. ჩვენ უნდა გავაკეთოთ ხელით, არა? ხალხი დააყენა ეს ყველაფერი ერთად. და ეს იყო გავრცელების ამ punch ბარათები შევიდა, რაც ჩვენ მოუწოდა მონაცემების დასარტყამი და მონაცემთა რგოლების, ქაღალდის ლენტი. 

მონაცემები გადამამუშავებელი მრეწველობის მიიღო გაკვეთილი მოთამაშე როიალები. Player როიალები უკან თავის მხრივ, საუკუნის უნდა გამოვიყენოთ ქაღალდი რგოლების ერთად slots ვუთხრა ის, რომელიც ღილაკები ითამაშოს. ასე რომ, ტექნიკა ადაპტირებული საბოლოოდ შესანახად ციფრული მონაცემები, იმიტომ, რომ ისინი ვერ დააყენა, რომ მონაცემები გადატანა იმ ქაღალდის ლენტი რგოლების. 

ახლა, როგორც შედეგი, მონაცემთა იყო რეალურად როგორ თქვენ ამ მონაცემებს პირდაპირ დამოკიდებული, თუ როგორ ინახება ეს. ასე რომ, თუ დააყენა მონაცემები ლენტი, მე მქონდა წვდომა მონაცემების ხაზოვანი. მე უნდა გააფართოვოს მთელი ფირზე ყველა მონაცემების. თუ მე ზუსტად მონაცემების punch ბარათები, მე შეიძლება თქვათ ეს ცოტა მეტი შემთხვევითი მოდის, შესაძლოა, არა, როგორც სწრაფად. 

მაგრამ არ იყო შეზღუდვები, თუ როგორ მონაცემთა საფუძველზე, თუ როგორ ინახება. ასე რომ, ეს იყო პრობლემა შესვლის 50-იან წლებში. ისევ და ისევ, ჩვენ შეგვიძლია დავიწყოთ ვხედავთ, რომ, როგორც ჩვენ ახალი ტექნოლოგიების დამუშავებას მონაცემები, უფლება, იგი ხსნის კარი ახალი გადაწყვეტილებები, ახალი პროგრამები, ახალი განაცხადების რომ მონაცემები. და მართლაც, მმართველობის შეიძლება ყოფილიყო მიზეზი ამიტომ, ჩვენ განვითარებული ზოგიერთი სისტემები. მაგრამ ბიზნესის სწრაფად გახდა მძღოლი უკან ევოლუცია თანამედროვე და მონაცემთა ბაზის თანამედროვე ფაილური სისტემა. 

ასე რომ, შემდეგი რამ, რომ გამოვიდა იყო 50-იან წლებში იყო ფაილური სისტემა და განვითარების წვდომის შენახვა. ეს იყო ლამაზი. ახლა, მოულოდნელად, ჩვენ შეგვიძლია ვთქვათ, ჩვენი ფაილი სადმე ამ მყარი დისკები და ჩვენ შეუძლია ამ მონაცემთა შემთხვევით. ჩვენ შეგვიძლია გარჩევის, რომ ინფორმაცია გარეთ ფაილი. ჩვენ მოგვარდება ყველა მსოფლიოს პრობლემა მონაცემების დამუშავება. 

და რომ დაახლოებით 20 ან 30 წლის განმავლობაში, სანამ ევოლუცია რელატიური მონაცემთა ბაზა, რომელიც არის, როდესაც მსოფლიოში გადავწყვიტეთ, რომ ჩვენ ახლა უნდა საცავი, რომ დაამარცხა sprawl მონაცემები მასშტაბით ფაილი სისტემა, რომელიც ჩვენ ავაშენეთ. მარჯვენა? ძალიან ბევრი მონაცემები ნაწილდება ძალიან ბევრი ადგილებში, დე-დუბლირებას მონაცემები, და ღირებულება შენახვის იყო უზარმაზარი. 

იმ 70 ყველაზე ძვირადღირებული რესურსი რომ კომპიუტერი იყო, შენახვა. პროცესორი იყო განიხილება, როგორც ფიქსირებული ღირებულება. როცა ყიდვა ყუთი, პროცესორის აკეთებს გარკვეული სამუშაო. ის აპირებს დაწნული თუ არა ეს რეალურად მუშაობს თუ არა. ეს მართლაც ჩაიძირა ღირებულება. 

მაგრამ რა ეღირება ჩემთვის, როგორც ბიზნესი შენახვა. თუ მე უნდა შეიძინოთ უფრო დისკები შემდეგი თვის, რომელიც არის რეალური ღირებულება, რომ გადავიხადო. და რომ შენახვის ძვირია. 

ახლა ჩვენ სწრაფი წინ 40 წლის და ჩვენ გვაქვს განსხვავებული პრობლემა. გამოთვლაც არის ყველაზე ძვირადღირებული რესურსია. შენახვის არის იაფი. ვგულისხმობ, ჩვენ შეგვიძლია წავიდეთ სადმე ღრუბელი და ჩვენ შეგვიძლია მოვძებნოთ იაფი შესანახი. მაგრამ რა მე ვერ პოულობენ იაფი compute. 

ასე რომ, ევოლუცია დღეს ტექნოლოგია, მონაცემთა ბაზის ტექნოლოგია, მართლაც ორიენტირებული გარშემო მონაცემთა ბაზების განაწილებას რომ არ განიცდიან იგივე ტიპის მასშტაბის შეზღუდვები რელაციური მონაცემთა ბაზები. ჩვენ გაიგო ცოტა შესახებ რა, რომ ფაქტიურად ნიშნავს. 

მაგრამ ერთ-ერთი მიზეზი და მძღოლი უკან ამას ჩვენ ისაუბრა მონაცემები ზეწოლა. მონაცემთა ზეწოლა არის რაღაც რომელიც მართავს ინოვაცია. და თუ დავაკვირდებით ბოლო ხუთი წლის განმავლობაში, ეს არის სქემა, რა მონაცემები დატვირთვის მასშტაბით ზოგადი საწარმო ჰგავს, რომ ბოლო ხუთი წლის განმავლობაში. 

და ზოგადი წესი thumb ამ დღეებში თუ თქვენ წავიდეთ Google-- 90% მონაცემები, ჩვენ ვინახავთ დღეს, და ეს იყო გამომუშავებული ფარგლებში ბოლო ორი წლის განმავლობაში. კარგი. ახლა, ეს არ არის ტენდენცია, რომ ახალი. ეს არის ტენდენცია, რომ უკვე აპირებს გარეთ 100 წლის განმავლობაში. მას შემდეგ, რაც ჰერმან Hollerith განვითარებული Punch ბარათის, ჩვენ ვაშენებდით მონაცემთა საცავებში და შეგროვება მონაცემები ფენომენალური განაკვეთები. 

ასე რომ, ბოლო 100 წლის განმავლობაში, ჩვენ ვნახეთ ეს ტენდენცია. ეს არ შეიცვლება. წინსვლის, ჩვენ ვაპირებთ, რომ ნახოთ ეს, თუ არა დაჩქარებული ტენდენცია. და თქვენ შეგიძლიათ ნახოთ რა, რომ ჰგავს. 

თუ ბიზნეს 2010 წელს ერთ-ერთი terabyte მონაცემების მართვის, დღეს ეს ნიშნავს, რომ ისინი მართვის 6.5 petabytes მონაცემები. სწორედ 6500-ჯერ მეტი მონაცემები. და მე ეს ვიცი. ვმუშაობ ამ ბიზნესის ყოველდღე. ხუთი წლის წინ, მე გაიგო, რომ კომპანიები ვინც გაიგო, რომ ჩემთვის, რა ტკივილი ის არის, რომ მართოთ ტერაბყტეს მონაცემები. და ისინი გაიგო ჩემთვის, თუ როგორ ვხედავთ რომ ეს არის ალბათ აპირებს იყოს petabyte ან ორი ფარგლებში რამდენიმე წლის განმავლობაში. 

ეს იგივე კომპანიები დღეს მე შეხვედრა, და ისინი ესაუბრებიან ჩემს შესახებ პრობლემა არსებობს, რომელსაც მმართველი ათობით, 20 petabytes მონაცემები. ასე რომ, აფეთქების მონაცემთა ინდუსტრიაში მართვის უზარმაზარი უნდა უკეთესი გადაწყვეტილებები. და რელატიური მონაცემთა ბაზა უბრალოდ არ ცხოვრობს მდე მოთხოვნა. 

და ასე რომ, ხაზოვანი კორელაცია მონაცემების ზეწოლა და ტექნიკური ინოვაცია. ისტორია გვაჩვენა ეს, რომ დროთა განმავლობაში, როდესაც მოცულობის მონაცემები , რომელიც უნდა დამუშავებული აღემატება რანგში სისტემა პროცესის გონივრულ ვადაში ან გონივრულ ფასად, მაშინ ახალი ტექნოლოგიები გამოიგონა იმ პრობლემების მოგვარებას,. ისინი, ახალი ტექნოლოგიები, თავის მხრივ, კარი სხვა კომპლექტი პრობლემა, რომელიც შეგროვება კიდევ უფრო მონაცემები. 

ახლა, ჩვენ არ შევწყვეტთ ამ. მარჯვენა? ჩვენ არ შევწყვეტთ ამ. რატომ? იმის გამო, რომ არ ვიცი ყველაფერი არსებობს იცოდეს სამყაროს. და რადგან ჩვენ უკვე ცოცხალია, მთელი ისტორიის მანძილზე ადამიანი, ჩვენ ყოველთვის ორიენტირებული უნდა იცოდეს მეტი. 

ასე რომ, როგორც ჩანს, ყოველ inch ჩვენ გადაადგილება გზას სამეცნიერო აღმოჩენების, ჩვენ ვამრავლებთ თანხის მონაცემები რომ ჩვენ უნდა დავამუშავოთ exponentially როგორც ჩვენ uncover უფრო და უფრო და უფრო შესახებ შიდა დამუშავებული ცხოვრების, იმაზე, თუ როგორ მუშაობს სამყარო, დაახლოებით მართვის სამეცნიერო აღმოჩენების, და გამოგონებას, ვაკეთებთ დღეს. მოცულობა მონაცემების მხოლოდ მუდმივად იზრდება. ასე რომ, შეუძლია გაუმკლავდეს ამ პრობლემის არის უზარმაზარი. 

ასე რომ, ერთი რამ ჩვენ ვეძებთ რატომ NoSQL? როგორ ამჯამად NoSQL ამ პრობლემის მოგვარებას? ისე, რელატიური მონაცემთა ბაზები, სტრუქტურირებული შეკითხვის ენა, SQL-- რომ მართლაც მშენებლობა საქართველოს რელატიური მონაცემთა ბაზა ეს ყველაფერი ოპტიმიზირებულია შენახვის. 

უკან '70s, კიდევ ერთხელ, დისკზე არის ძვირი. უზრუნველყოფის exercise შენახვის საწარმოში არის დაუსრულებელი. ვიცი. მე ცხოვრობდა. მე დავწერე შენახვის მძღოლებს ერთი Enterprised superserver კომპანია უკან '90s. და ქვედა ხაზი არის ჯოუნსი სხვა შენახვის მასივში იყო მხოლოდ ის, რომ მოხდა ყოველდღე საწარმო. და ეს არ შეუწყვეტია. მაღალი სიმკვრივის შენახვის, მოთხოვნა მაღალი სიმკვრივის შენახვის, და უფრო ეფექტური შენახვის devices-- ის არ შეუწყვეტია. 

და NoSQL დიდი ტექნოლოგია იმიტომ, რომ ეს ნორმალიზებას მონაცემები. ეს დე-ეგზ მონაცემები. იგი აყენებს მონაცემები სტრუქტურა, რომელიც აგნოსტიკოსია ყველა ხელმისაწვდომობის ნიმუში. მრავალჯერადი განაცხადების შეიძლება მოხვდა, რომ SQL მონაცემთა ბაზაში, აწარმოებს ad hoc შეკითხვებს, და მიიღონ მონაცემები ფორმის, რომ ისინი უნდა დამუშავებას მათი workloads. ეს ხმები ფანტასტიური. მაგრამ ქვედა ხაზი არის ნებისმიერი სისტემა, თუ ის აგნოსტიკი, რომ ყველაფერი, ის ოპტიმიზირებულია არაფერი. კარგი? 

და ეს რა მივიღებთ რელაციური მონაცემთა ბაზაში. ის ოპტიმიზირებულია შენახვის. ეს ნორმალიზება. ეს რელატიური. იგი მხარს უჭერს ad hoc შეკითხვებს. ეს და ეს სასწორები ვერტიკალურად. 

თუ მე უნდა მიიღოს უფრო დიდი SQL მონაცემთა ბაზაში ან უფრო ძლიერი SQL მონაცემთა ბაზაში, მე წასვლა ყიდვა უფრო დიდი ნაჭერი რკინის. კარგი? მე მუშაობდა ბევრი მომხმარებელს რომ არ ყოფილიყო მეშვეობით ძირითადი განახლებანი მათი SQL მხოლოდ ინფრასტრუქტურის იმის გასარკვევად, ექვსი თვის შემდეგ, ისინი hitting კედლის ერთხელ. და პასუხი Oracle და MSSQL ან ვინმე სხვა არის კიდევ უფრო დიდი ყუთი. ისე, ადრე თუ გვიან, თქვენ შეგიძლიათ შეიძინოთ უფრო დიდი ყუთი, და რომ რეალური პრობლემა. ჩვენ უნდა რეალურად შეცვალოს. ასე რომ, სადაც ჯერ ეს სამუშაო? იგი მუშაობს გასულია ანალიტიკა, OLAP ტიპის დატვირთვის. და ეს მართლაც, სადაც SQL ეკუთვნის. ახლა, ის გამოიყენება დღეს ბევრი ონლაინ ოპერაციული დამუშავება ტიპის პროგრამები. და მუშაობს მხოლოდ ჯარიმა გარკვეული დონის გამოყენება, მაგრამ ეს უბრალოდ არ გავაფართოვოთ ისე, რომ NoSQL აკეთებს. და ჩვენ ვსაუბრობთ პატარა ცოტა შესახებ, თუ რატომ არის. 

ახლა, NoSQL, მეორეს მხრივ, უფრო ოპტიმიზირებულია compute. კარგი? ეს არ არის აგნოსტიკი, რომ მისასვლელი ნიმუში. არის ის, რაც ჩვენ მოვუწოდებთ de-ნორმალიზება სტრუქტურა და იერარქიული სტრუქტურა. მონაცემები რელატიური მონაცემთა ბაზა შეუერთდა ერთად მრავალჯერადი მაგიდები წარმოების იმ თვალსაზრისით, რომ თქვენ გჭირდებათ. მონაცემები NoSQL მონაცემთა ბაზის ინახება დოკუმენტი, რომელიც შეიცავს იერარქიული სტრუქტურა. ყველა მონაცემები, რომ ჩვეულებრივ შეუერთდა ერთად აწარმოოს, რომ კალენდარი ინახება ერთ დოკუმენტს. და ჩვენ გაიგო ცოტა შესახებ როგორ მუშაობს, რამდენიმე ჩარტებში. 

მაგრამ იდეა აქ არის ის, რომ თქვენ შესანახად თქვენი მონაცემები, როგორც ამ ობიექტის რაოდენობა. კარგი? თქვენ მასშტაბის ჰორიზონტალურად. მარჯვენა? თუ მე უნდა გაიზარდოს ზომა ჩემი NoSQL კასეტური მე არ უნდა მიიღოს დიდი ყუთი. მივიღებ სხვა ყუთში. და მე კასეტური იმ ერთად, და შემიძლია shard რომ მონაცემები. ჩვენ გაიგო ცოტა შესახებ რა sharding არის, უნდა იყოს შეუძლია მასშტაბის, რომ მონაცემთა ბაზაში მასშტაბით სხვადასხვა ფიზიკური მოწყობილობები და ამოიღონ ბარიერი, რომ მოითხოვს, რომ მე მასშტაბის ვერტიკალურად. 

ასე რომ, ეს მართლაც აშენდა ონლაინ ტრანზაქციების დამუშავება და მასშტაბით. აქ არის დიდი განსხვავება აქ შორის ანგარიშგების, არა? ანგარიშის, მე არ ვიცი კითხვები მე ვაპირებ ვკითხო. მარჯვენა? Reporting-- თუ ვინმე ჩემი მარკეტინგის დეპარტამენტის სურს just-- რამდენი ჩემი მომხმარებელს გვაქვს ეს განსაკუთრებით დამახასიათებელი, რომელიც შეიძინა ამ day-- მე არ ვიცი რა შეკითხვის ისინი აპირებენ ითხოვენ. ასე რომ, მე უნდა აგნოსტიკი. 

ახლა კი, ონლაინ ოპერაციული განცხადება, მე ვიცი, რა კითხვებს მე გეკითხებით. მე აგებული განაცხადის ძალიან კონკრეტული სამუშაოს. კარგი? ასე რომ, თუ ოპტიმიზაცია მონაცემები შესანახად მხარდასაჭერად, რომ workflow, ეს იქნება უფრო სწრაფად. და ამიტომაც NoSQL შეუძლია მართლაც დააჩქაროს მიწოდების იმ სახის მომსახურება. კარგი. 

ამიტომ, ჩვენ ვაპირებთ შეღწევას ცოტა თეორია აქ. და ზოგიერთ თქვენგანს, თქვენი თვალები შეიძლება გააფართოვოს უკან ცოტა. მაგრამ ვეცდები, რომ შევინარჩუნოთ ის მაღალი დონე, როგორც შემიძლია. ასე რომ, თუ თქვენ პროექტი მართვის, არსებობს მშენებლობა მოუწოდა სამკუთხედის შეზღუდვები. კარგი. სამკუთხედის constrains კარნახით თქვენ არ გაქვთ ყველაფერი ყველა დროის. არ შეიძლება თქვენი ტორტი და ჭამა ეს ძალიან. ასე რომ, პროექტის მართვის, რომ სამკუთხედის შეზღუდვები არის, თქვენ შეგიძლიათ ეს იაფი, თქვენ შეგიძლიათ სწრაფად, ან შეგიძლიათ აქვს კარგი. Pick ორი. იმის გამო, რომ თქვენ არ აქვს სამივე. მარჯვენა? კარგი. 

ასე, რომ თქვენ ისმენს ამ ბევრი. ეს სამმაგი შეზღუდვა, სამკუთხედის სამჯერ შეზღუდვა, ან რკინის სამკუთხედის oftentimes-- როცა გაიგო, რომ პროექტის მენეჯერები, ისინი ვსაუბრობთ ამ. ახლა, მონაცემთა ბაზები აქვს საკუთარი რკინის სამკუთხედის. და რკინის სამკუთხედის მონაცემები არის ის, რაც ჩვენ მოვუწოდებთ CAP თეორემა. კარგი? 

CAP თეორემა კარნახით როგორ მონაცემთა ბაზები ფუნქციონირებს ქვეშ ძალიან კონკრეტული მდგომარეობა. და ჩვენ ვსაუბრობთ რა, რომ მდგომარეობა. მაგრამ სამი ქულა სამკუთხედის ასე ვთქვათ, არის C, თანმიმდევრულობა. კარგი? ასე რომ, CAP, მდგრადობა ნიშნავს, რომ ყველა კლიენტებს, რომლებიც შეუძლია მონაცემთა ბაზაში ყოველთვის აქვს ძალიან თანმიმდევრული მონაცემთა ხედი. არავის კარგად ვხედავთ, ორი სხვადასხვა რამ არის. კარგი? თუ მე ვერ ვხედავ მონაცემთა ბაზა, მე ხედავს იმავე კალენდარი როგორც ჩემი პარტნიორი, რომელიც ხედავს იგივე მონაცემთა ბაზაში. ეს არის თანმიმდევრულობა. 

არსებობა ნიშნავს, რომ თუ მონაცემთა ბაზა ამჟამად, თუ ეს მიიღწევა, რომ ყველა კლიენტებს ყოველთვის შეძლებთ წაიკითხოთ და დაწეროთ. კარგი? ასე რომ, ყოველ კლიენტს, რომ შეგიძლიათ წაიკითხოთ მონაცემთა ბაზა ყოველთვის შეძლებს წაკითხული მონაცემები და დაწეროთ მონაცემები. და თუ ეს საქმე, ეს არის ხელმისაწვდომი სისტემა. 

და მესამე არის ის, რაც ჩვენ მოვუწოდებთ დანაყოფი შემწყნარებლობა. კარგი? Partition ტოლერანტობის საშუალებით რომ სისტემა კარგად მუშაობს მიუხედავად იმისა, რომ ფიზიკური ქსელის ტიხრები შორის კვანძების. კარგი? ასე რომ, კვანძების კასეტური ვერ ესაუბრონ ერთმანეთს, რა ხდება? კარგი. 

ასე რომ, რელატიური მონაცემთა ბაზის choose-- თქვენ შეგიძლიათ აირჩიოთ ორი. კარგი. ასე რომ, რელატიური მონაცემთა ბაზის აირჩიეთ უნდა იყოს თანმიმდევრული და ხელმისაწვდომი. იმ შემთხვევაში, თუ დანაყოფი ხდება შორის DataNodes მონაცემები მაღაზიაში, მონაცემთა ბაზის ავარია. მარჯვენა? ეს მხოლოდ მიდის ქვემოთ. კარგი. 

და სწორედ ამიტომ მათ აქვთ იზრდება უფრო დიდი ყუთები. მარჯვენა? იმის გამო, რომ no-- როგორც წესი, კასეტური მონაცემთა ბაზა, რომ იქ არ არის ძალიან ბევრი მათგანი რომ მოქმედებს, რომ გზა. მაგრამ ყველაზე მონაცემთა ბაზის მასშტაბის ვერტიკალურად ერთ ყუთში. იმის გამო, რომ ისინი უნდა იყოს თანმიმდევრული და ხელმისაწვდომი. თუ დანაყოფი იყო გაუკეთეს, მაშინ თქვენ უნდა გააკეთოს არჩევანი. თქვენ უნდა გააკეთოს არჩევანი თანმიმდევრული და ხელმისაწვდომი. 

და ეს რა NoSQL მონაცემთა ბაზის გაკეთება. კარგი. ასე რომ, NoSQL მონაცემთა ბაზა, მოდის ორი გემოს. ჩვენ ჰქონდეს კარგად, ის მოდის ბევრი არომატს, მაგრამ მას გააჩნია ორი ძირითადი characteristics-- რა ჩვენ მოვუწოდებთ CP მონაცემთა ბაზა, ან თანმიმდევრული და დანაყოფი ტოლერანტობის სისტემა. ეს ბიჭები გააკეთოს არჩევანი, რომ როდესაც კვანძების დაკარგავს კონტაქტის ერთმანეთს, ჩვენ არ ვაპირებთ დაუშვას ადამიანი უნდა დაწეროთ რაიმე სხვა. კარგი? 

მანამდე კი დანაყოფი არის აღებული, ჩაწერის არის ბლოკირებული. ეს ნიშნავს, რომ ისინი არ არის შესაძლებელი. ისინი შეესაბამება. როდესაც ჩვენ ვხედავთ, რომ დანაყოფი მიეცეს თავად, ჩვენ ახლა თანმიმდევრული, იმიტომ, რომ ჩვენ არ ვაპირებთ დაუშვას მონაცემების ცვლილება ორი მხარეებმა დანაყოფი დამოუკიდებლად ერთმანეთს. ჩვენ უნდა დაამკვიდროს ურთიერთობა ადრე ნებისმიერი განახლება მონაცემები დაშვებული. კარგი? 

შემდეგი არომატი იქნება AP სისტემა, ან ხელმისაწვდომი და დანაწევრებული ტოლერანტობის სისტემა. ეს ბიჭები არ მაინტერესებს. მარჯვენა? ნებისმიერი კვანძის, რომელიც იღებს წერენ, ჩვენ მას. ასე რომ, მე რეპლიკაციური ჩემი მონაცემები მასშტაბით სხვადასხვა კვანძების. ამ კვანძების კიდევ კლიენტს, კლიენტი მოდის წელს, ამბობს, მე ვაპირებ წერენ ზოგიერთი მონაცემები. Node ამბობს, არ არის პრობლემა. კვანძის მომდევნო მას იღებს წერენ იგივე ჩანაწერი, ის აპირებს ამბობენ, პრობლემა არ არის. სადღაც უკან უკან ბოლოს, რომ მონაცემები აპირებს იმეორებს. და მაშინ ვინმე აპირებს გააცნობიეროს, uh-oh, ისინი სისტემა გააცნობიეროს, uh-oh, იქ უკვე განახლება ორ მხარეს. რას ვაკეთებთ? და რას აკეთებს მაშინ არის ისინი რაღაც, რომელიც მათ საშუალებას აძლევს მოგვარებას, რომ მონაცემები სახელმწიფო. და ჩვენ ვსაუბრობთ რომ მომდევნო სქემა. 

რამ აღვნიშნო აქ. და მე არ ვაპირებ მისაღებად ძალიან ბევრი შევიდა, რადგან ეს იღებს შევიდა ღრმა მონაცემების თეორია. მაგრამ არსებობს ოპერაციული ფარგლებში, რომელიც ეშვება რელატიური სისტემა, რომელიც საშუალებას იძლევა ჩემთვის უსაფრთხოდ მიიღოს განახლებები სხვადასხვა პირების მონაცემთა ბაზაში. და იმ სიახლეებზე მოხდება ერთდროულად ან არ. ეს ეწოდება ACID ოპერაციების. კარგი? 

ACID გვაძლევს Atomicity, თანმიმდევრულობა, იზოლაცია, და გამძლეობა. კარგი? ეს იმას ნიშნავს, ატომური, ოპერაციების, ყველა ჩემი განახლებები ან მოხდება ან არ. მდგრადობა ნიშნავს იმას, რომ მონაცემთა ბაზის ყოველთვის შემოტანილი თანმიმდევრული სახელმწიფო შემდეგ განახლება. მე არასდროს დატოვებს მონაცემთა ბაზის ცუდი სახელმწიფო გამოყენების შემდეგ განახლება. კარგი? 

ასე რომ, ეს ცოტა განსხვავებული ვიდრე CAP თანმიმდევრულობა. CAP მდგრადობა ნიშნავს, რომ ყველა ჩემი კლიენტებს ყოველთვის შეგიძლიათ ნახოთ მონაცემები. ACID მდგრადობა ნიშნავს, რომ როდესაც გარიგების კეთდება, მონაცემები კარგი. ჩემი ურთიერთობები ყველა კარგი. მე არ ვაპირებ წაშლა მშობელი row და დატოვონ bunch of ობოლი ბავშვები ზოგიერთ სხვა მაგიდასთან. ეს ვერ მოხდება, თუ მე შეესაბამება in მჟავა გარიგება. 

იზოლაცია იმას ნიშნავს, რომ ოპერაციები ყოველთვის მოხდეს ერთ შემდეგ სხვა. საბოლოო ჯამში მონაცემები იგივე იქნება სახელმწიფო თითქოს იმ გარიგებების რომ გაიცა ერთდროულად დახვრიტეს სერიულად. ასე რომ, ეს concurrency კონტროლის მონაცემთა ბაზაში. ასე რომ, ძირითადად, მე ვერ ნამატი იგივე ღირებულება ორჯერ ორი ოპერაცია. 

მაგრამ თუ მე ვიტყვი დაამატოთ 1 ეს ღირებულება, და ორი ოპერაციების მოდის და ცდილობენ ამის გაკეთება, ერთი, აპირებს იქ პირველი და მეორე ის აპირებს თუ არა შემდეგ. და ბოლოს, მე კიდევ ორი. ხედავთ რას ვგულისხმობ? კარგი. 

გამძლეობა საკმაოდ მარტივია. როდესაც გარიგება აღიარებულია, რომ ეს იქნება იქ კი თუ სისტემა crashes. როდესაც ეს სისტემა აღდგება, რომელიც გარიგების რომელიც ჩადენილია რეალურად აპირებს იყოს იქ. ასე რომ, ეს გარანტიები საქართველოს ACID ოპერაციების. ეს არის საკმაოდ ლამაზი გარანტიები აქვს მონაცემთა ბაზა, მაგრამ ისინი, რომ ღირებულება. მარჯვენა? 

იმის გამო, რომ პრობლემა ეს ჩარჩო არის თუ არ არის დანაყოფი მონაცემები კომპლექტი, მე უნდა მიიღოს გადაწყვეტილება. მე ვაპირებ უნდა დაუშვას განახლებები ერთ მხარეს ან მეორე. და თუ ეს მოხდება, მაშინ მე აღარ აპირებს შეძლებს შეინარჩუნოს ის მახასიათებლები. ისინი არ იქნება თანმიმდევრული. ისინი არ იქნება იზოლირებული. ეს არის სადაც ეს თანხიდან ამისთვის რელატიური მონაცემთა ბაზა. ეს არის მიზეზი, რელატიური მონაცემთა ბაზის მასშტაბის ვერტიკალურად. 

მეორეს მხრივ, ჩვენ გვაქვს რასაც BASE ტექნოლოგია. და ეს არის თქვენი NoSQL მონაცემთა ბაზა. კარგი. ასე რომ, ჩვენ გვაქვს ჩვენი CP, AP ბაზაში. და ეს არის ის, რაც თქვენ მოვუწოდებთ ძირითადად შესაძლებელია, რბილი სახელმწიფო, საბოლოოდ თანმიმდევრული. კარგი? 

ძირითადად არსებობს, რადგან ისინი დანაყოფი ტოლერანტული. ისინი ყოველთვის იქნება იქ, მაშინაც კი, თუ არსებობს ქსელის დანაყოფი შორის კვანძების. თუ მე ვერ გაიგო, რომ კვანძის, მე აპირებს შეძლებს წაიკითხა მონაცემები. კარგი? მე შეიძლება ყოველთვის არ იყოს შეუძლია დაწეროს მონაცემები, თუ მე ვარ თანმიმდევრული პლატფორმა. მაგრამ მე შეძლებთ წაიკითხოთ მონაცემები. 

რბილი სახელმწიფო მიუთითებს რომ როდესაც წავიკითხე, რომ მონაცემები, ეს არ უნდა იყოს იგივე, რაც სხვა კვანძების. თუ უფლება გაიცა კვანძის სხვაგან კასეტური და ეს არ გაიმეორა მთელს კასეტური ჯერ, როცა წავიკითხე, რომ მონაცემები, რომ სახელმწიფო არ უნდა იყოს თანმიმდევრული. თუმცა, ეს იქნება საბოლოოდ თანმიმდევრული, რაც იმას ნიშნავს, რომ როდესაც ჩაწერის დამზადებულია სისტემა, იგი იმეორებს მასშტაბით კვანძების. და საბოლოოდ, რომ სახელმწიფო იქნება შემოტანილი მიზნით, და ეს იქნება თანმიმდევრული სახელმწიფო. 

ახლა, CAP თეორემა ნამდვილად თამაშობს მხოლოდ ერთი პირობით. ეს მდგომარეობა არის როცა ეს მოხდება. იმის გამო, რომ როდესაც ის მოქმედი ნორმალურ რეჟიმში, არ არსებობს დანაყოფი, ყველაფერი თანმიმდევრული და ხელმისაწვდომი. თქვენ მხოლოდ ფიქრი CAP როდესაც ჩვენ გვაქვს, რომ ეს დანაყოფი. ასე რომ, ეს ძალიან იშვიათია. მაგრამ, თუ როგორ სისტემა რეაგირებს, როდესაც ის მოხდეს უკარნახოს რა ტიპის სისტემა ჩვენ საქმე გვაქვს. 

მოდით შევხედოთ რა რომ ჰგავს for AP სისტემები. კარგი? AP სისტემები მოდის ორი გემოს. ისინი არომატი, რომელიც არის ოსტატი ოსტატი, 100%, ყოველთვის არ არის შესაძლებელი. და ისინი მოდის სხვა არომატი, რომელიც ამბობს, იცით რა, მე ვაპირებ ფიქრი ამ დაყოფის რამ როდესაც ფაქტობრივი დანაყოფი ხდება. წინააღმდეგ შემთხვევაში, არ იქნება პირველადი კვანძების, ვინც აპირებს, რომ მიიღოს უფლებები. კარგი? 

ასე რომ, თუ ჩვენ რაღაც Cassandra. Cassandra იქნება სამაგისტრო სამაგისტრო, მოდით დავწერ ნებისმიერი კვანძის. ასე რომ, რა ხდება? ასე რომ, მე ობიექტი მონაცემთა ბაზა, რომელიც არსებობს ორ კვანძების. მოდით მოვუწოდებთ, რომ ობიექტი S. ასე რომ, ჩვენ გვაქვს სახელმწიფო S. ჩვენ გვაქვს გარკვეული ოპერაციების on S რომ მიმდინარეობს. Cassandra საშუალებას ჩემთვის წერენ სხვადასხვა კვანძების. ასე ვთქვათ, მივიღებ წერენ s ორ კვანძების. ისე, რა მთავრდება ხდება არის ჩვენ მოვუწოდებთ, რომ დაყოფის ღონისძიება. არსებობს არ შეიძლება იყოს ფიზიკური ქსელის დანაყოფი. მაგრამ იმის გამო, დიზაინი სისტემა, ის რეალურად დაყოფა, როგორც კი როგორც მე წერენ ორ კვანძების. ეს არ მაიძულებდნენ წერენ მთელი ერთი კვანძის. მე წერა ორ კვანძების. კარგი? 

ასე რომ, ახლა მე მაქვს ორ ქვეყანას. კარგი? რა მოხდება არის, ადრე თუ გვიან, იქ უნდა იყოს რეპლიკაცია ღონისძიება. არ იქნება, რასაც ჩვენ მოუწოდა დანაყოფი აღდგენა, რომელიც არის, სადაც ეს ორი ქვეყნების დავბრუნდებით ერთად და არ იქნება ალგორითმი რომელიც ეშვება შიგნით მონაცემთა ბაზა, გადაწყვეტს, თუ რა უნდა გააკეთოს. კარგი? ჩვეულებრივ, ბოლო განახლება იგებს ყველაზე AP სისტემები. ასე რომ, როგორც წესი, ძირითადად ალგორითმი, რა ისინი უწოდებენ გადმორეკე ფუნქცია, რომ რაღაც დაერქმევა როდესაც ეს პირობა გამოვლინდა, რომ შეასრულოს გარკვეული ლოგიკა კონფლიქტის მოგვარების. კარგი? ნაგულისხმები უკუგამოძახება და ეგ resolver უმეტეს AP მონაცემთა ბაზები არის, რას, დროის ნიშნულს რიცხვი. ეს იყო ბოლო განახლება. მე ვაპირებ დააყენა, რომ განახლება არ არსებობს. მე შეიძლება ნაგავსაყრელი ეს ჩანაწერი, რომ მე ჩაყარეს off შევიდა აღდგენის შესვლა ისე, რომ მომხმარებელს შეუძლია დაუბრუნდეს შემდეგ და აცხადებენ, hey, იყო შეჯახება. რა მოხდა? და თქვენ შეგიძლიათ რეალურად ნაგავსაყრელი ჩანაწერი ყველა შეჯახება და rollbacks და ვნახოთ, რა მოხდება. 

ახლა, როგორც მომხმარებლის, ასევე შეგიძლიათ მოიცავს ლოგიკა, რომ გადმორეკე. ასე, რომ თქვენ შეიძლება შეიცვალოს, რომ გადმორეკე ოპერაცია. შეიძლება ითქვას, hey, მინდა უნდა გამოასწოროს ეს მონაცემები. და მე შევეცდები და შერწყმა ამ ორი ჩანაწერი. მაგრამ ეს თქვენზეა. მონაცემთა ბაზა არ იცის, თუ როგორ უნდა გავაკეთოთ, რომ იყოს. ყველაზე დროის, ერთადერთი, რაც მონაცემთა ბაზა იცის როგორ გააკეთოს ამბობენ, ეს იყო ბოლო ჩანაწერი. ეს არის ერთი, რომ აპირებს გაიმარჯვებს, და ეს ღირებულება მე ვაპირებ დააყენა. მას შემდეგ, რაც დაყოფის აღდგენა და რეპლიკაცია ხდება, ჩვენ გვაქვს ჩვენი სახელმწიფო, რომელიც არის პრემიერ, რომელიც შერწყმა სახელმწიფო ყველა იმ ობიექტების. ასე რომ, AP სისტემები ამ. CP სისტემები არ გვჭირდება ფიქრი. იმის გამო, რომ, როგორც კი დანაყოფი გააჩნია პიესა, ისინი უბრალოდ შეწყვიტოს აღების წერს. კარგი? ასე რომ, ძალიან ადვილია გაუმკლავდეთ თანმიმდევრული როდესაც თქვენ არ მიიღოს ნებისმიერი განახლებები. სწორედ ერთად CP სისტემები გააკეთოს. კარგი. 

მოდით ვისაუბროთ ცოტა ცოტა ხელმისაწვდომობის ნიმუშები. როდესაც ვსაუბრობთ NoSQL, ეს ყველაფერი ხელმისაწვდომობის ნიმუში. ახლა, SQL არის დროებითი, შეკითხვებს. ეს რელატიური მაღაზია. ჩვენ არ უნდა ფიქრი შესახებ ხელმისაწვდომობის ნიმუში. ვწერ ძალიან რთული შეკითხვა. იგი მიდის და იღებს მონაცემებს. სწორედ ამ გამოიყურება როგორიცაა, ნორმალიზაცია. 

ასე რომ, ამ კონკრეტულ სტრუქტურას, ჩვენ შევხედავთ პროდუქციის კატალოგი. მაქვს სხვადასხვა სახის პროდუქცია. მე მაქვს წიგნი. მაქვს დათვალიერება. მე მაქვს ვიდეო. შორის ურთიერთობა პროდუქცია და ერთი ასეთი წიგნები, ალბომები, და ვიდეო მაგიდები არის 1: 1. კარგი? მაქვს პროდუქტის ID, და რომ ID შეესაბამება წიგნი, ალბომი, ან ვიდეო. კარგი? ეს არის 1: 1 ურთიერთობა მთელი ამ მაგიდები. 

ახლა, books-- ყველა მათ აქვს არის root თვისებები. არაა პრობლემა. დიდებულია. ერთ-ერთი ურთიერთობისათვის, მივიღებ ყველა მონაცემები მე უნდა აღწერდეს წიგნი. Albums-- ფოტოალბომი აქვს სიმღერები. ეს არის ის, რაც ჩვენ მოვუწოდებთ ერთი ბევრი. ყველა ალბომი შეიძლება ბევრი სიმღერები. ასე რომ, ყველა სიმღერა ალბომი, მე შეიძლება კიდევ ერთი რეკორდი ამ ბავშვის მაგიდა. ასე, რომ შევქმნათ ერთი ჩანაწერი ჩემი ალბომების მაგიდასთან. მე შექმნათ მრავალი ჩანაწერები საჩვენებელი მაგიდასთან. ერთი მრავალთან კავშირი. 

ეს ურთიერთობა არის ის, რაც ჩვენ მოვუწოდებთ ბევრი მრავალთან. კარგი? თქვენ ხედავთ, რომ მსახიობები შეიძლება იყოს ბევრი ფილმები, ბევრი ვიდეო. ასე რომ, თუ რას ვაკეთებთ ჩვენ ამ რუკების მაგიდა შორის იმ, რომელიც უბრალოდ რუკები მსახიობი ID ვიდეო ID. ახლა შემიძლია შექმნა შეკითხვის უერთდება ვიდეოები მეშვეობით მსახიობი ვიდეო მსახიობები, და ეს მაძლევს ლამაზი სია ყველა ფილმები და მსახიობები ვინც იყო, რომ ფილმი. 

კარგი. ასე რომ, აქ ჩვენ მივდივართ. ერთ-ერთი ყველაზე მაღალი დონის ურთიერთობა; ერთ-მრავალი, ფოტოალბომი საჩვენებელი; ბევრი მრავალთან. ეს არის სამი უმაღლესი დონის ურთიერთობები ნებისმიერი მონაცემთა ბაზაში. თუ თქვენ იცით, თუ როგორ იმ ურთიერთობები ვიმუშაოთ, მაშინ თქვენ იცით, ბევრი მონაცემთა ბაზაში უკვე. ასე რომ, NoSQL მუშაობს ცოტა განსხვავებულად. მოდით ვიფიქროთ, რომ მეორე ის, რაც ჰგავს წავიდეთ მისაღებად ყველა ჩემს პროდუქცია. 

In რელატიური მაღაზიაში, მე გვინდა ყველა ჩემს პროდუქცია on სიაში ყველა ჩემს პროდუქცია. ეს არის ის, ბევრი შეკითხვებს. მე მივიღე შეკითხვაზე ყველა ჩემი წიგნი. მე მივიღე შეკითხვაზე ჩემი ალბომები. და მე მივიღე შეკითხვაზე ყველა ჩემი ვიდეოები. და მე მივიღე, რომ ეს ყველა ერთად სიაში და ემსახურება მას უკან მდე პროგრამა, რომელიც არის თხოვნის იგი. 

იმისათვის რომ ჩემი წიგნი, მე ვუერთდები პროდუქტები და წიგნები. მიიღოს ჩემი ალბომები, მე მივიღე შეუერთდეს პროდუქტები, ალბომი, და სიმღერების. და კიდევ ჩემი ვიდეო, მაქვს შეუერთდეს პროდუქტები ვიდეოები, შეუერთდეს მეშვეობით მსახიობი ვიდეოები, და მოიტანს მსახიობები. ასე რომ, სამი შეკითხვებს. ძალიან რთული შეკითხვებს შეიკრიბება ერთი შედეგი ნაკრები. 

ეს არის ის, ნაკლები ოპტიმალური. ამიტომ, როდესაც ვსაუბრობთ შესახებ მონაცემები სტრუქტურა, რომელიც არის აგებული უნდა იყოს აგნოსტიკი ხელმისაწვდომობის pattern-- კარგად რომ არის დიდი. და თქვენ შეგიძლიათ ნახოთ ეს მართლაც ლამაზი როგორ ჩვენ ორგანიზებული მონაცემები. და იცით რა? მე მხოლოდ ერთი რეკორდი მსახიობი. 

მაგარია. მე deduplicated ყველა ჩემი მსახიობები, და მე ინახება ჩემს ასოციაციები ამ რუკების მაგიდა. თუმცა, მიღების მონაცემები გარეთ ხდება ძვირი. მე გაგზავნის CPU მთელი სისტემა გაწევრიანების ამ მონაცემების სტრუქტურები ერთად შეძლებს გაიყვანოს, რომ მონაცემები უკან. 

ასე რომ, მე მისაღებად გარშემო, რომ? In NoSQL ის შესახებ აგრეგაციას, არ ნორმალიზაცია. ასე რომ, ჩვენ გვინდა, რომ ვთქვათ, ჩვენ გვინდა მხარდასაჭერად ხელმისაწვდომობის ნიმუში. თუ წვდომის ნიმუში განაცხადების, მე უნდა მიიღოს ყველა ჩემი პროდუქტები. მოდით დააყენა ყველა პროდუქციის ერთ მაგიდასთან. თუ მე დააყენოს ყველა პროდუქციის ერთ მაგიდასთან, შემიძლია უბრალოდ აირჩიეთ ყველა პროდუქცია რომ მაგიდასთან და მე ეს ყველაფერი. ისე როგორ გავაკეთო რომ? კარგად NoSQL არ არსებობს სტრუქტურა მაგიდასთან. ჩვენ გაიგო ცოტა შესახებ როგორ მუშაობს ეს დინამოში DB. მაგრამ თქვენ არ გაქვთ იგივე ატრიბუტები და იგივე თვისებები თითოეული ზედიზედ, თითოეული ნივთი, როგორც თქვენ ამ SQL მაგიდასთან. და რა ამ საშუალებას ჩემთვის უნდა გავაკეთოთ, არის ბევრი რამ და მომეცი ბევრი მოქნილობა. ამ კონკრეტულ შემთხვევაში, მე მაქვს ჩემი პროდუქტი დოკუმენტები. და ამ კონკრეტულ მაგალითად, ყველაფერი, არის დოკუმენტი პროდუქტები მაგიდაზე. და პროდუქტის წიგნი შეიძლება აქვს ტიპის ID, რომ განსაზღვრავს წიგნი. და გამოყენების გადართოთ, რომ ID. 

განაცხადის იარუსი, მე ვაპირებ უნდა ვთქვა, მე, რა ჩანაწერი ტიპის არის ეს? ოჰ, ეს წიგნი ჩანაწერი. წიგნი ჩანაწერები აქვს ეს თვისებები. ნება მომეცით შექმნა წიგნაკი ობიექტი. ამიტომ, მე ვაპირებ, რომ შეავსოთ წიგნი ობიექტი ამ ერთეულზე. შემდეგი საქონლის მოდის და ამბობს, რა არის ეს ნივთი? ისე ეს საქონელი ალბომი. ოჰ, მე მივიღე მთელი სხვადასხვა დამუშავება სიტუაციიდან, რომ იმიტომ, რომ ეს ალბომი. ხედავთ რას ვგულისხმობ? 

ასე რომ, განაცხადი tier-- მე უბრალოდ აირჩიეთ ყველა ეს ჩანაწერი. ისინი ყველა დაიწყებს მოდის. ისინი შეიძლება ყველა ტიპის. და ეს განცხადება ლოგიკა რომ ცვლის მთელი იმ ტიპის და გადაწყვეტს როგორ გადაამუშავებს მათ. 

ერთხელ, ასე რომ, ჩვენ ოპტიმიზაციის სქემა ხელმისაწვდომობის ნიმუში. ჩვენ ვაკეთებთ მიერ იშლება იმ მაგიდები. ჩვენ ძირითადად იღებენ ამ ნორმალიზება სტრუქტურები, და ჩვენ ვაშენებთ იერარქიული სტრუქტურები. Inside ყოველი ეს ჩანაწერები მე ვაპირებ, რომ ნახოთ მასივი თვისებები. 

Inside ეს დოკუმენტი ალბომი, მე ხედავს მასივების სიმღერები. იმ კვალის ახლა become-- ეს ძირითადად ეს ბავშვი მაგიდა, რომელიც არსებობს უფლება აქ ამ სტრუქტურაში. ასე, რომ თქვენ შეგიძლიათ ამის გაკეთება DynamoDB. თქვენ შეგიძლიათ ამის გაკეთება MongoDB. თქვენ შეგიძლიათ ამის გაკეთება ნებისმიერ NoSQL მონაცემთა ბაზაში. შექმნა ამ ტიპის იერარქიული მონაცემთა სტრუქტურები რომელიც საშუალებას გაძლევთ მიიღოთ მონაცემები ძალიან სწრაფად, რადგან ახლა მე არ უნდა შეესაბამებოდეს. როდესაც მე ჩადეთ row შევიდა Tracks მაგიდა, ან ზედიზედ შევიდა ალბომი მაგიდა, მე უნდა შეესაბამებოდეს რომ schema. უნდა ჰქონდეს ატრიბუტი ან ქონება, რომელიც განსაზღვრულია, რომ მაგიდასთან. ყოველი მათგანი, როდესაც მე ჩადეთ რომ ზედიზედ. ეს არ არის იმ შემთხვევაში, NoSQL. 

მე შეიძლება ჰქონდეს სრულიად განსხვავებული თვისებები ყველა დოკუმენტი რომ მე ჩადეთ კოლექცია. ასე რომ, ძალიან ძლიერი მექანიზმი. და ეს მართლაც, თუ როგორ ოპტიმიზაციის სისტემა. იმის გამო, რომ ახლა, რომ შეკითხვაზე, ნაცვლად გაწევრიანების ყველა ამ მაგიდები და შესრულებაში ნახევარი ათეული შეკითხვებს უკან დახევის მონაცემები მჭირდება, მე შესრულებაში ერთი შეკითხვა. და მე iterating მთელს შედეგები მითითებული. ეს გაძლევთ იდეა ძალა NoSQL. მე ვაპირებ სახის წასვლა sideways აქ და გაიგო ცოტა შესახებ. ეს უფრო სახის მარკეტინგის ან technology-- მარკეტინგის ტექნიკა დისკუსია. მაგრამ ეს მნიშვნელოვანია იმის გაგება, იმიტომ, რომ თუ ჩვენ გადავხედავთ ყველაზე აქ, ამ სქემა, ის, რასაც ჩვენ ვუყურებთ არის ის, რაც ჩვენ მოვუწოდებთ ტექნიკა ვარდების რევოლუციის მრუდი. და რას ნიშნავს, ახალი პერსონალის ძალაში პიესა. ხალხი ფიქრობს, რომ ეს არის დიდი. მე მოგვარდება ყველა პრობლემა. 

ეს შეიძლება იყოს ბოლომდე ყველა, იქნება ყველა ყველაფერს. და ისინი დაიწყოს გამოყენებით. და ამბობენ, ამ პერსონალის არ მუშაობს. ეს არ არის სწორი. ძველი პერსონალის უკეთესი იყო. და მათ დაბრუნდეს აკეთებს რამ გზა ისინი. და მაშინ საბოლოოდ დადიან, იცით რა? ეს პერსონალის ასე არ არის ცუდი. ოჰ, რომ, თუ როგორ მუშაობს. და კიდევ ისინი გაერკვნენ, თუ როგორ სამუშაოები, დაიწყება უკეთესობისაკენ. 

და სასაცილო რამ შესახებ ეს ის არის, რომ სახის ხაზები მდე რა ჩვენ მოვუწოდებთ ტექნიკა მიღება Curve. ასე რომ, რა ხდება, ჩვენ გვაქვს გარკვეული ტექნოლოგია გამოიწვევს. იმ შემთხვევაში, მონაცემთა ბაზები, ეს მონაცემები ზეწოლა. ჩვენ ვისაუბრეთ მაღალი წყლის რაოდენობა მონაცემთა ზეწოლა მთელი დრო. როცა ეს მონაცემები ზეწოლის ჰიტები გარკვეული წერტილი, რომელიც არის ტექნოლოგია გამოიწვევს. 

ის მიღების ძალიან ძვირი. იგი იღებს ძალიან ხანგრძლივი გადაამუშავებს მონაცემები. ჩვენ გვჭირდება რაღაც უკეთესი. თქვენ მიიღებთ ნოვატორებისა იქ გაშვებული გარშემო, ვცდილობთ გავარკვიოთ, რა არის გამოსავალი. რა არის ახალი იდეა? 

რა არის შემდეგი საუკეთესო გზა ამის გაკეთება რამ? და ისინი ამუშავება რაღაც. და იმ ადამიანებს, რეალურ ტკივილი, ბიჭები სისხლდენა პირას, ისინი ხტომა მეტი, იმიტომ, რომ ისინი უნდა პასუხს. ახლა რა აუცილებლად უნდა მოხდეს და ეს ხდება ახლა NoSQL. მე ვხედავ, რომ ყველა დროის. 

რა აუცილებლად მოხდება, ადამიანი დაიწყოს გამოყენებით ახალი ინსტრუმენტი ანალოგიურად, ისინი გამოიყენა ძველი ინსტრუმენტი. და ისინი, რომ ეს არ მუშაობს ისე კარგად. მე არ მახსოვს, ვინ ვიყავი საუბარი დღეს. მაგრამ ეს იგივეა, როცა jackhammer გამოიგონეს, ადამიანი არ Swing მას მეტი მათი ხელმძღვანელი smash კონკრეტული. 

მაგრამ ეს არის ის, რაც ხდება NoSQL დღეს. თუ თქვენ ფეხით, საუკეთესო მაღაზიები, ისინი ცდილობენ, რომ NoSQL მაღაზიები. რა ისინი აკეთებს ისინი გამოყენებით NoSQL, და ისინი ჩატვირთვის ის სრული რელაციური მონაცემთა schema. იმის გამო, რომ ის, თუ როგორ მათ შეიმუშავონ ბაზაში. და ისინი მაინტერესებს, რატომ არის ეს არ ასრულებენ ძალიან კარგად? ბიჭი, ეს ის სუნი ასდის. მე უნდა შევინარჩუნოთ ყველა ჩემი უერთდება შიგნით ეს იგივეა, არა, არა. შენარჩუნება უერთდება? რატომ გაწევრიანების მონაცემები? თქვენ არ შეუერთდება მონაცემების NoSQL. თქვენ საერთო იგი. 

ასე რომ, თუ გსურთ, რათა თავიდან ავიცილოთ ეს, სწავლობენ როგორ ინსტრუმენტი მუშაობს, სანამ რეალურად დაიწყოს გამოყენებით. ნუ ეცდებით და გამოიყენოს ახალი ინსტრუმენტები იგივე გზა გამოიყენა ძველი იარაღები. თქვენ აპირებს აქვს ცუდი გამოცდილება. და თითოეული ის, რაც ამ არის. როდესაც ჩვენ ვიწყებთ მალე აქ, ეს იმიტომ, რომ ადამიანი figured როგორ გამოვიყენოთ ინსტრუმენტები. 

ისინი გააკეთა იგივე, როდესაც რელაციური მონაცემთა ბაზის გამოიგონეს, და ისინი შეცვალა ფაილური სისტემა. ისინი ცდილობდნენ აშენება ფაილის სისტემები ერთად რელატიური მონაცემთა ბაზები იმიტომ, რომ ის, რაც ხალხს ესმოდა. ეს არ იმუშავებს. ასე რომ, იმ აზრს, საუკეთესო პრაქტიკის ტექნოლოგია ვმუშაობთ დიდია. ძალიან მნიშვნელოვანი. 

ამიტომ, ჩვენ ვაპირებთ შეღწევას DynamoDB. DynamoDB არის AWS ს სრულად მოახერხა NoSQL პლატფორმა. რას სრულად მართული ნიშნავს? ეს იმას ნიშნავს, რომ თქვენ არ უნდა ნამდვილად აღელვებს არაფერი. 

თქვენ მოვიდა, თქვენ გითხრათ ჩვენთვის, მე უნდა მაგიდასთან. მას სჭირდება ეს ბევრად მოცულობა. თქვენ მოხვდა ღილაკს და ჩვენ დებულება ყველა ინფრასტრუქტურის კულუარებში. ახლა არის უზარმაზარი. 

იმის გამო, რომ, როდესაც თქვენ საუბრობთ შესახებ სკალირების მონაცემთა ბაზა, NoSQL მონაცემების მტევანი მასშტაბის, გაშვებული petabytes, გაშვებული მილიონობით ოპერაციები წამში, ეს ყველაფერი არ არის პატარა მტევანი. ჩვენ ვსაუბრობთ ათასობით შემთხვევები. მმართველი ათასობით შემთხვევაში, მაშინაც კი, ვირტუალური შემთხვევაში, არის ნამდვილი ტკივილი კონდახით. მე ვგულისხმობ, ვფიქრობ იმაზე, ყოველ ჯერზე ოპერაციული სისტემა პატჩი გამოდის ან ახალი ვერსია მონაცემთა ბაზაში. ეს რას ნიშნავს თქვენ ოპერატიულად? ეს იმას ნიშნავს, რომ თქვენ გაქვთ 1,200 სერვერები, რომ უნდა მფლობელის მხრიდან. ახლა კი, ავტომატიკა, რომ შეუძლია დიდი ხნის განმავლობაში. ეს შეიძლება გამოიწვიოს ბევრი ოპერატიული თავის ტკივილი, იმიტომ, რომ მე შეიძლება მომსახურება ქვემოთ. 

როგორც მე ეს მონაცემთა ბაზების, მე შეიძლება გავაკეთოთ ლურჯი მწვანე განლაგდებიან სადაც მე განათავსოს და განახლება ნახევარი ჩემი კვანძების, და მერე გადახვიდეთ მეორე ნახევარში. მიიღეთ იმ ქვემოთ. ასე რომ, მართვის ინფრასტრუქტურა მასშტაბი არის უზომოდ მტკივნეული. და AWS მიიღოს, რომ ტკივილი გარეთ. და NoSQL მონაცემთა ბაზები შეუძლია არაჩვეულებრივად მტკივნეული იმიტომ, რომ გზა ისინი გავაფართოვოთ. 

გავაფართოვოთ ჰორიზონტალურად. თუ გსურთ უფრო დიდი NoSQL მონაცემთა ბაზა, რომ თქვენ შეიძინოთ მეტი კვანძების. ყველა კვანძის ყიდვა არის სხვა ოპერატიული თავის ტკივილი. ასე რომ, მოდით სხვისი გააკეთებს, რომ თქვენ. AWS ამის გაკეთება. 

ჩვენ მხარს ვუჭერთ დოკუმენტი გასაღები ღირებულებებს. ახლა ჩვენ არ წავიდეთ ძალიან ბევრი შევიდა მეორე სქემა. არსებობს ბევრი სხვადასხვა გემოს NoSQL. ისინი ყველა სახის მიღების munged ერთად ამ ეტაპზე. თქვენ შეგიძლიათ შეხედოთ DynamoDB და ვთქვა, დიახ, ჩვენ ორივე დოკუმენტი და ძირითადი მნიშვნელობა შესანახად ამ ეტაპზე. და თქვენ შეგიძლიათ ამტკიცებენ თვისებები ერთი სხვა. ჩემთვის, ბევრი ეს მართლაც ექვსი ერთი ნახევარი ათეული სხვა. ყოველი ამ ტექნოლოგიების არის ჯარიმა ტექნიკა და ჯარიმა გადაწყვეტა. მე ვერ ვიტყოდი, MongoDB უკეთესია ან უარესი Couch, მაშინ Cassandra, მაშინ დინამო, ან პირიქით. ვგულისხმობ, რომ ეს არის მხოლოდ პარამეტრები. 

ეს არის სწრაფი და ეს შეესაბამება ნებისმიერ მასშტაბში. ასე რომ, ეს არის ერთ ერთი ყველაზე დიდი პრემიების თქვენ მიიღებთ AWS. ერთად DynamoDB არის უნარი მისაღებად დაბალი ერთნიშნა millisecond შეყოვნება ნებისმიერ მასშტაბში. ეს იყო დიზაინი მიზანი სისტემა. და ჩვენ კლიენტებს, რომ ვაკეთებთ მილიონობით ოპერაციები წამში. 

ახლა მე გაიაროს ზოგიერთი იმ გამოყენების შემთხვევაში რამდენიმე წუთში აქ. ინტეგრირებული ხელმისაწვდომობის control-- ჩვენ, რაც ჩვენ მოვუწოდებთ პირადობის ძებნა მენეჯმენტი, ან უკვე. ეს permeates ყველა სისტემას, ყველა მომსახურება, რომელიც AWS სთავაზობს. DynamoDB არ არის გამონაკლისი. თქვენ შეგიძლიათ აკონტროლოთ დაშვება რომ DynamoDB მაგიდები. მთელი თქვენი AWS ანგარიშები მიერ ხელმისაწვდომობის განმსაზღვრელი როლი და ნებართვების ამ IAM ინფრასტრუქტურა. 

და ეს არის გასაღები და განუყოფელი კომპონენტი რაც ჩვენ მოვუწოდებთ ღონისძიება ორიენტირებული პროგრამირება. ახლა ეს არის ახალი პარადიგმა. 

აუდიტორია: როგორ არის თქვენი განაკვეთი ჭეშმარიტი დადებითი წინააღმდეგ ცრუ უარყოფით თქვენი დაშვების კონტროლის სისტემა? RICK Houlihan: True დადებითი წინააღმდეგ ცრუ უარყოფით შედეგებს? აუდიტორია: დავბრუნდეთ რა თქვენ უნდა დაბრუნების? როგორც ეწინააღმდეგებოდა ერთხელ, ხოლო ეს არ დაბრუნდება, როცა ის უნდა შეამოწმოს? 

RICK Houlihan: მე ვერ გეტყვით, რომ. თუ არსებობს რაიმე წარუმატებლობის განაწილებაზე, რომ, მე არ ვარ ის ადამიანი, ვთხოვო რომ კონკრეტული საკითხი. მაგრამ ეს კარგი კითხვაა. მე იქნება ის აინტერესებს, რომ თავს, რეალურად. 

და ასე შემდეგ, კიდევ ერთხელ, ახალი პარადიგმა არის ღონისძიება ორიენტირებული პროგრამირების. ეს არის იდეა, რომ თქვენ შეუძლია განათავსოს კომპლექსური პროგრამები, რომელიც შეიძლება მოქმედებენ ძალიან, ძალიან მაღალი მასშტაბის ყოველგვარი ინფრასტრუქტურის გარეშე. ყოველგვარი ფიქსირებული ინფრასტრუქტურის განაწილებაზე. და ჩვენ გაიგო ცოტა რას ნიშნავს ეს, როგორც ჩვენ მისაღებად მომდევნო რამდენიმე ჩარტებში. 

პირველი, რაც ჩვენ ყველაფერს გავაკეთებთ, არის ჩვენ ვსაუბრობთ მაგიდები. API მონაცემები ტიპის დინამო. და პირველი, რაც თქვენ შეამჩნია, როდესაც თქვენ შეხედეთ ამ, თუ თქვენ იცნობს ნებისმიერი მონაცემთა ბაზა, მონაცემთა ბაზები აქვს მართლაც ორი სახის APIs მინდა მოვუწოდო მას. ან ორი კომპლექტი API. ერთ-ერთი ასეთი იქნება ადმინისტრაციული API. 

რამ მათ იზრუნოს ფუნქციები მონაცემთა ბაზაში. კონფიგურაცია შენახვის სისტემა, შექმნის და დასძინა, მაგიდები. მონაცემთა ბაზის კატალოგები და შემთხვევები. ეს ყველაფერი ამ DynamoDB, თქვენ აქვს ძალიან მოკლე, მოკლე სიები. 

ასე რომ, სხვა მონაცემთა ბაზები, თქვენ შეიძლება ნახოთ ათეულობით ბრძანებები, ადმინისტრაციული ბრძანებები, კონფიგურაციის დამატებითი პარამეტრები. In DynamoDB თქვენ არ უნდა იმ იმიტომ, თქვენ არ კონფიგურაცია სისტემა, რასაც ჩვენ ვაკეთებთ. ასე რომ, ერთადერთი, რაც თქვენ უნდა გავაკეთოთ არის მითხარით, რა ზომის მაგიდა მჭირდება. ასე რომ, თქვენ ძალიან შეზღუდული კომპლექტი ბრძანებები. 

თქვენ შექმენით მაგიდა განახლება, მაგიდა, წაშალე მაგიდა, და აღწერეთ მაგიდა. ეს არის ერთადერთი რამ, თქვენ უნდა DynamoDB. თქვენ არ გჭირდებათ შენახვის ძრავის კონფიგურაცია. მე არ უნდა ფიქრი, რეპლიკაცია. მე არ უნდა ფიქრი sharding. 

მე არ უნდა ფიქრი რაიმე ამ პერსონალი. ჩვენ ამას ყველა თქვენთვის. ასე რომ, დიდი ოდენობით ოვერჰედის რომ უბრალოდ გააუქმა off თქვენი ფირფიტაზე. შემდეგ ჩვენ გვაქვს ნაგვის ოპერატორები. ნაგვის არის რაღაც, რაც ჩვენ მოვუწოდებთ მონაცემთა ბაზა, რომელიც არის შექმნა, განახლება, წაშლა ოპერატორები. ეს არის თქვენი საერთო მონაცემთა ბაზის ოპერაციებში. რამ, როგორიცაა put პუნქტის, მიიღოს საქონელი, განახლება ნივთები, წაშლა ნივთები, სურათების შეკითხვაზე, ეძებოს. თუ გსურთ სკანირების მთელი მაგიდა. გაიგეთ ყველაფერი გაჩნდება. ერთ-ერთი ლამაზი რამ DynamoDB არის ის საშუალებას პარალელურად სკანირება. ასე რომ თქვენ შეგიძლიათ რეალურად მიადევნე თვალი რამდენი თემა გსურთ აწარმოებს, რომ სკანირების. და ჩვენ შეგვიძლია მას მოვთხოვოთ იმ თემა. ჩვენ შეგვიძლია დაიძაბება, რომ სკანირების მდე მთელს მრავალჯერადი თემა ასე რომ თქვენ შეგიძლიათ სკანირების მთელი მაგიდა სივრცეში, ძალიან სწრაფად DynamoDB. 

სხვა API გვაქვს არის რაც ჩვენ მოვუწოდებთ ჩვენი ნაკადს API. ჩვენ არ ვაპირებთ, რომ გაიგო ძალიან ბევრი ამ ახლავე. მაქვს გარკვეული შინაარსის შემდეგ on გემბანზე შესახებ. მაგრამ ნაკადს მართლაც running-- ვფიქრობ, რომ ეს იმ დროს, მიღებული და დანაყოფი ცვლილება ჟურნალი. ყველაფერი, რაც ხდება მაგიდა გვიჩვენებს up ნაკადი. 

ყოველ ვწერ მაგიდა გვიჩვენებს up ნაკადი. შეგიძლიათ წაიკითხოთ, რომ ნაკადი, და შეგიძლიათ გააკეთოთ რამ არის. ჩვენ ვსაუბრობთ რა სახის რამ, გააკეთოს რამ, როგორიცაა ტირაჟირებას, ქმნის საშუალო ინდექსები. ყველა სახის მართლაც მაგარი რამ რისი გაკეთებაც შეგიძლიათ, რომ. 

მონაცემთა ტიპები. In DynamoDB, ჩვენ მხარს ვუჭერთ ორივე გასაღები მნიშვნელობა და დოკუმენტის ტიპის მონაცემები. მარცხენა მხარეს ეკრანზე აქ, ჩვენ მივიღეთ ჩვენი ძირითადი ტიპები. ძირითადი მნიშვნელობა ტიპის. ეს არის სიმები, ნომრები და binaries. 

ასე რომ, მხოლოდ სამი ძირითადი ტიპის. და მაშინ აქვს კომპლექტი იმ. ერთ-ერთი ლამაზი რამ NoSQL არის თქვენ შეიძლება შეიცავდეს მასივების თვისებები. და DynamoDB თქვენ შეიძლება შეიცავდეს კოლექტორები ძირითადი სახის, როგორც root ქონება. 

და მაშინ იქ დოკუმენტის ტიპის. რამდენი ადამიანი იცნობს JSON? თქვენ ბიჭები იცნობს JSON ამდენი? ეს, ძირითადად, JavaScript, ობიექტი, ნოტაცია. ეს გაძლევთ საშუალებას, ძირითადად, განსაზღვრავს იერარქიული სტრუქტურა. 

თქვენ შეგიძლიათ ჩაწეროთ JSON დოკუმენტი DynamoDB გამოყენებით საერთო კომპონენტები ან სამშენებლო ბლოკები, რომლებიც ხელმისაწვდომი ყველაზე პროგრამირების ენები. ასე რომ, თუ თქვენ გაქვთ Java, თქვენ ეძებს რუკები და სიები. მე შეგიძლიათ შექმნათ ობიექტები, რომ ფართობი რუკა. რუკისა ძირითად ღირებულებებზე შენახული თვისებები. და ალბათ, ეს სიები ღირებულებების იმ თვისებებს. თქვენ შეგიძლიათ შეინახოთ ეს კომპლექსი იერარქიული სტრუქტურა როგორც ერთი ატრიბუტი ერთი DynamoDB ერთეულზე. 

ასე რომ, მაგიდები DynamoDB, როგორც ყველაზე NoSQL მონაცემთა ბაზა, მაგიდები საკითხი. In MongoDB თქვენ ამას დარეკეთ ამ დოკუმენტებს. და ეს იქნება მწვრთნელი ბაზა. გარდა ამისა დოკუმენტი მონაცემთა ბაზაში. თქვენ მოვუწოდებთ ამ დოკუმენტებს. დოკუმენტები და ნივთები ატრიბუტები. ატრიბუტები შეიძლება არსებობდეს ან არ არსებობს ნივთი. In DynamoDB, არსებობს ერთ-ერთი სავალდებულო ატრიბუტი. ისევე, რელატიური მონაცემთა ბაზა, თქვენ გაქვთ პირველადი გასაღები მაგიდაზე. 

DynamoDB აქვს, რაც ჩვენ მოვუწოდებთ hash გასაღები. Hash გასაღები უნდა იყოს უნიკალური. ასე რომ, როდესაც მე განსაზღვრა hash მაგიდა, ძირითადად რა მე ვამბობ, არის ყველა ნივთი გექნებათ hash გასაღები. და ყოველ hash გასაღები უნდა იყოს უნიკალური. 

ყველა ნივთი არის განსაზღვრული მიერ, რომელიც უნიკალური hash გასაღები. და არ შეიძლება იყოს მხოლოდ ერთი. ეს კარგია, მაგრამ ხშირად რა სჭირდება ხალხს არის უნდათ ამ hash გასაღები უნდა გავაკეთოთ ცოტა მეტი მეტი, ვიდრე უბრალოდ უნდა უნიკალური იდენტიფიკატორი. ხშირად ჩვენ გვინდა, რომ გამოიყენოს hash გასაღები როგორც ზედა დონის აგრეგაციას bucket. და გზა ჩვენ, რომ არის დასძინა, რაც ჩვენ მოვუწოდებთ სპექტრი გასაღები. 

ასე რომ, თუ ის hash მხოლოდ მაგიდა, ეს უნდა იყოს უნიკალური. თუ ეს hash და დიაპაზონი მაგიდა, კომბინაცია hash და სპექტრი უნდა იყოს უნიკალური. ასე რომ, ვფიქრობ, რომ ამ გზით. თუ მე მაქვს ფორუმზე. და ფორმა აქვს თემა, მას აქვს ფორუმზე, და მას აქვს რეაგირება. 

ასე რომ, მე შეიძლება hash გასაღები, რომელიც თემაზე ID. და მე ალბათ სპექტრი გასაღები, რომელიც არის პასუხი ID. ასე რომ, თუ მე მინდა, რომ მიიღოს ყველა პასუხები კონკრეტულ თემაზე, მე შემიძლია მხოლოდ შეკითხვის hash. მე შემიძლია მხოლოდ ვთქვა, მომეცი ყველა საკითხი, რომელიც აქვს ამ hash. და მე ვაპირებ მისაღებად ყველა კითხვაზე ან პოსტი, რომ კონკრეტულ თემაზე. ეს უმაღლესი დონის aggregations ძალიან მნიშვნელოვანია. ისინი მხარს უჭერენ პირველადი დაშვება ნიმუში განაცხადი. საერთოდ, ამ არის ის, რაც ჩვენ გვინდა გავაკეთოთ. ჩვენ გვინდა, რომ მაგიდასთან თქვენ ჩატვირთეთ მაგიდა, ჩვენ გვინდა, რომ სტრუქტურირებაზე მონაცემები ფარგლებში მაგიდაზე ისე, რომ განაცხადი შეიძლება ძალიან სწრაფად დაიბრუნებს იმ შედეგებს. და ხშირად ისე უნდა გავაკეთოთ, რომ შენარჩუნება ამ aggregations როგორც ჩვენ ჩადეთ მონაცემები. ძირითადად, ჩვენ გავრცელების მონაცემები შევიდა ნათელი bucket, როგორც ის მოდის. 

Range ღილაკები საშუალებას ჩემთვის hash გასაღებები უნდა იყოს თანასწორობა. როდესაც მე შეკითხვის hash, მე უნდა ვთქვა, მომეცი hash რომელიც უდრის. როდესაც მე შეკითხვის სპექტრი, მე შეიძლება ითქვას, მომეცი სპექტრი რომ არის გამოყენებით ნებისმიერი სახის მდიდარი ოპერატორი, რომელიც ჩვენ მხარს ვუჭერთ. მომეცი ყველა ელემენტი hash. ეს არის თანაბარი, მეტი, ნაკლებია, ვიდრე, იგი იწყება, ეს არ არსებობს ამ ორ ღირებულებებს? ასე რომ, ამ ტიპის სპექტრს queries რომ ჩვენ ყოველთვის დაინტერესებული. ახლა ერთი ის მონაცემები, როდესაც გადავხედავთ წვდომის მონაცემები, როდესაც თქვენ შედიხართ მონაცემები, ის ყოველთვის შესახებ აგრეგაციას. ეს ყოველთვის ჩანაწერები რომლებიც დაკავშირებულია ამ. მომეცი ყველაფერი აქ that's-- ყველა გარიგებების, ამ საკრედიტო ბარათის ბოლო ერთი თვის განმავლობაში. სწორედ აგრეგაციას. 

თითქმის ყველაფერი უნდა გააკეთოთ მონაცემთა ბაზა ერთგვარი აგრეგაციას. ასე რომ მას შეუძლია შეძლებს განსაზღვროს ამ თაიგულების და მოგაწვდით ამ სპექტრს ატრიბუტები შეძლებს შეკითხვის შესახებ, იმ მდიდარი შეკითხვებს მხარდაჭერა ბევრი, ბევრი, ბევრი განაცხადის დაშვების ნიმუშები. 

ასე რომ სხვა რამ ქეშირების გასაღები არ არის ეს გვაძლევს მექანიზმი შეძლებს გავრცელებული მონაცემების ირგვლივ. NoSQL მონაცემთა ბაზის მუშაობა საუკეთესო როდესაც მონაცემები თანაბრად ნაწილდება მთელს კასეტური. რამდენი ადამიანი იცნობს ერთად hashing ალგორითმები? როდესაც ვამბობ hash და hashing-- იმიტომ, ჰეშირება ალგორითმი არის გზა, რომ შეუძლია გენერირება შემთხვევითი მნიშვნელობა ნებისმიერ მნიშვნელობა. ასე რომ, ამ კონკრეტულ შემთხვევაში, hash ალგორითმი ჩვენ აწარმოებს არის ND 5 საფუძველზე. 

და თუ მე მაქვს ID, და ამ ჩემი hash გასაღები, მაქვს 1, 2, 3. როცა აწარმოებს hash ალგორითმი, ის აპირებს დაბრუნებას და აცხადებენ, ასევე 1 უდრის 7B, 2 უდრის 48, 3 ტოლია CD. ისინი მთელ გასაღები სივრცეში. და რატომ აკეთებთ ამას? იმის გამო, რომ რაც დარწმუნებული ვარ, რომ მე არ შემიძლია ბოლო ჩანაწერები მასშტაბით სხვადასხვა კვანძების. 

თუ მე ვაკეთებ ამ ხარჯებს, 1, 2, 3. და მაქვს hash სპექტრი, რომელიც გადის ამ კონკრეტულ შემთხვევაში, პატარა hash სივრცეში, ის გადის 00 FF, მაშინ ეს ჩანაწერები აპირებს მოდის და ისინი აპირებენ წასვლა 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. რა მოხდა? ყოველ ჩანართით აპირებს იგივე კვანძის. ხედავთ რას ვგულისხმობ? 

იმიტომ, რომ როდესაც მე გაყოფილი სივრცეში, მე და გავრცელდა ეს ჩანაწერი მასშტაბით, და მე დანაყოფი, მე ვაპირებ ვთქვა დანაყოფი 1 აქვს გასაღები სივრცეში 0 54. Partition 2 55 89. Partition 3 AA რომ FF. ასე რომ, თუ მე გამოყენებით ხაზოვანი დამატება პირადობის მოწმობა, თქვენ ხედავთ, რა ხდება. 1, 2, 3, 4, 5, 6, ყველა გზა მდე 54. ასე რომ, როგორც მე როდესმე ჩანაწერების სისტემაში, ყველაფერი მთავრდება აპირებს ერთი კვანძის. 

ეს არ არის კარგი. სწორედ antipattern. In MongoDB მათ აქვთ ეს პრობლემა თუ არ გამოიყენოთ hash გასაღები. MongoDB გაძლევთ ვარიანტი საქართველოს ჰეშირება გასაღები ღირებულება. თქვენ ყოველთვის უნდა გავაკეთოთ, რომ, თუ თქვენ იყენებთ დამატება hash გასაღები MongoDB, ან თქვენ უნდა იყოს nailing ყოველ ჩაწერის ერთი კვანძის, და თქვენ უნდა შეზღუდვის თქვენი ჩაწერის გამტარუნარიანობა ცუდად. 

აუდიტორია: რომ A9 169 წელს ათობითი? 

RICK Houlihan: ჰო, სადღაც არსებობს. A9, მე არ ვიცი. ნეტავ უნდა მიიღოს ჩემი ორობითი რომ ათობითი კალკულატორი. ჩემი ტვინი არ მუშაობს, როგორიცაა, რომ. აუდიტორია: Just სწრაფი ერთი თქვენი Mongo კომენტარი. ასე რომ, არის ობიექტი ID, რომ მოდის natively ერთად Mongo ამის გაკეთება? RICK Houlihan: არ გავაკეთოთ ეს? თუ თქვენ დააკონკრეტა ის. ერთად MongoDB, თქვენ გაქვთ შესაძლებლობა. თქვენ შეგიძლიათ specify-- ყველა დოკუმენტი MongoDB აქვს ტირეთი ID. ეს არის უნიკალური ღირებულება. 

In MongoDB შეგიძლიათ მიუთითოთ თუ არა, რომ hash თუ არა. ისინი უბრალოდ მოგაწვდით. თუ თქვენ იცით, რომ ეს შემთხვევითი არ არის პრობლემა. თქვენ არ უნდა გავაკეთოთ, რომ. თუ თქვენ იცით, რომ ეს არ არის შემთხვევითი, რომ ის დამატება, მაშინ ნუ hash. 

ახლა რამ ჰეშირება, ერთხელ თქვენ hash value-- და ეს არის რატომ hash გასაღებები ყოველთვის უნიკალური შეკითხვებს, იმიტომ, რომ მე შეიცვალა ღირებულება, ახლა მე არ შემიძლია ამის სპექტრი შეკითხვაზე. მე ვერ ვიტყვი, ეს არის შორის ამა თუ იმ, იმის გამო, რომ hash ღირებულება არ აპირებს ექვივალენტი ფაქტობრივი ღირებულების. ასე რომ, როდესაც თქვენ hash, რომ გასაღები, ეს თანასწორობა. სწორედ ამიტომ, DynamoDB hash გასაღები შეკითხვებს ყოველთვის თანასწორობა. 

ასე რომ, ახლა სპექტრი key-- როდესაც დავამატო, რომ რიგი გასაღები, იმ სპექტრს გასაღები ჩანაწერი ყველა მოდის და ისინი ინახება იგივე დანაყოფი. ასე რომ, ისინი ძალიან სწრაფად, მარტივად მოძიებული, რადგან ეს არის hash, ეს არის დიაპაზონი. თქვენ ხედავთ, ყველაფერი იგივე hash იღებს ინახება იმავე დანაყოფი სივრცეში. თქვენ შეგიძლიათ გამოიყენოთ, რომ რიგი გასაღები, რათა დაეხმაროს განთავსდება თქვენი მონაცემების ახლოს მისი მშობელი. რა ვარ მე ნამდვილად აკეთებს აქ? ეს არის ერთ-ერთი, რომ ბევრი ურთიერთობა. შორის ურთიერთობა ქეშირების გასაღები და სპექტრი გასაღები არის ერთი ბევრი. მე შეიძლება მქონდეს hash გასაღებები. მე შემიძლია მხოლოდ აქვს მრავალი სპექტრი გასაღებები ფარგლებში ყოველ hash გასაღები. 

ქეშირების განსაზღვრავს მშობელი, სპექტრი განსაზღვრავს შვილი. ასე რომ თქვენ ხედავთ, რომ არსებობს ანალოგი აქ შორის რელატიური მშენებლობა და იგივე სახის აშენებს in NoSQL. ადამიანები საუბრობენ NoSQL როგორც nonrelational. ეს არ არის nonrelational. მონაცემთა ყოველთვის ურთიერთობები. იმ ურთიერთობებს მხოლოდ მოდელირებული განსხვავებულად. მოდით ვისაუბროთ ცოტა ცოტა გამძლეობა. როცა ვწერ DynamoDB, წერს ყოველთვის სამი გზა გაიმეორა. რაც იმას ნიშნავს, რომ ჩვენ გვაქვს სამი AZ ს. AZ ს არსებობა ზონები. შეგიძლიათ წარმოიდგინოთ, რომ ხელმისაწვდომობა ზონა, როგორც მონაცემების ცენტრი ან შეგროვება მონაცემები ცენტრებში. ეს ყველაფერი არის გეოგრაფიულად იზოლირებულია ერთმანეთისგან სხვადასხვა ბრალია ზონებში, მთელს სხვადასხვა ძალა ბადეები და ფრაგმენტებს ვხვდებით. მარცხი ერთ AZ არ არის აპირებს ქვემოთ სხვა. ისინი ასევე უკავშირდება ერთად მუქი ბოჭკოვანი. იგი მხარს უჭერს ერთი ქვე 1 millisecond შეყოვნება შორის AZS. ასე რომ რეალურ დროში მონაცემთა replications შეუძლია მრავალ AZS. 

და ხშირად მრავალ AZ განლაგდებიან აკმაყოფილებს მაღალი ხელმისაწვდომობის მოთხოვნებს ყველაზე საწარმო ორგანიზაციები. ასე რომ, DynamoDB გავრცელდა მასშტაბით სამი AZS იყოს. ჩვენ მხოლოდ აპირებს ცოდნის ჩაწერის როდესაც ორი იმ სამი კვანძების დაბრუნდება და აცხადებენ, ჰო, მე მივიღე ეს. ეს რატომ? იმის გამო, რომ წაკითხული მხარეს ჩვენ მხოლოდ აპირებს მოგცემთ მონაცემების უკან, როდესაც ჩვენ ეს ორი კვანძების. 

თუ მე რეპლიკაციური მასშტაბით სამი, და მე კითხულობს ორი, მე ყოველთვის გარანტირებული აქვს მინიმუმ ერთი იმ ნათქვამია, რომ იყოს უახლესი ასლი მონაცემები. ეს არის ის რაც DynamoDB თანმიმდევრული. ახლა თქვენ შეგიძლიათ ჩართოთ იმ თანმიმდევრული ნათქვამია off. ამ შემთხვევაში მე ვაპირებ ვთქვა, მე მხოლოდ წაიკითხა ერთი კვანძის. და მე ვერ მოგცემთ იმის გარანტიას, რომ ის აპირებს იყოს ყველაზე დღევანდელი მონაცემებით. 

ასე რომ, თუ ჩაწერის მოდის, ეს არ გაიმეორა ჯერ, თქვენ აპირებს მიიღოს ასლი. სწორედ საბოლოოდ თანმიმდევრული წაკითხული. და რა, რომ არის ნახევარი ღირებულება. ასე რომ, ეს არის ის, რასაც უნდა ვიფიქროთ. როდესაც თქვენ კითხულობს DynamoDB და თქვენ შექმნით თქვენს წაკითხული მოცულობა ერთეული, თუ თქვენ საბოლოოდ თანმიმდევრული ნათქვამია, რომ ბევრი იაფია, ეს დაახლოებით ნახევარი ღირებულება. 

ასე რომ, ეს დაზოგავს თქვენს ფულს. მაგრამ ეს არის თქვენი არჩევანი. თუ გსურთ თანმიმდევრული წაკითხვის ან საბოლოოდ თანმიმდევრული წაკითხული. ეს არის ის, რომ თქვენ შეგიძლიათ აირჩიოთ. 

მოდით ვისაუბროთ ინდექსები. ასე რომ, ჩვენ აღნიშნა, რომ უმაღლესი დონის აგრეგაციას. ჩვენ მივიღეთ hash გასაღებები, და ჩვენ მივიღეთ სპექტრი გასაღებები. კარგია. და რომ პირველადი მაგიდასთან, მე გაიხარეს hash გასაღები, მე მივიღე ერთი სპექტრი გასაღები. 

ეს რას ნიშნავს? მაქვს ერთი ატრიბუტი, რომელიც მე შეიძლება აწარმოებს მდიდარი შეკითხვებს წინააღმდეგ. ეს სპექტრი გასაღები. სხვა ატრიბუტები, რომ item-- მე შეიძლება ამას იმ ატრიბუტები. მაგრამ მე არ შემიძლია ამის გაკეთება, როგორიც ის იწყება, ან მეტია. 

როგორ შემიძლია ამის გაკეთება? შევქმნა ინდექსი. არსებობს ორი სახის ინდექსები DynamoDB. ინდექსი მართლაც კიდევ ერთი ხედი მაგიდასთან. და ადგილობრივი საშუალო ინდექსი. 

პირველი, ჩვენ ვსაუბრობთ. ასე რომ, ადგილობრივი secondaries არიან თანაარსებობდა იმავე დანაყოფი მონაცემები. და როგორც ასეთი, ისინი იგივე ფიზიკური კვანძი. ისინი, რაც ჩვენ მოვუწოდებთ თანმიმდევრული. რაც იმას ნიშნავს, რომ ისინი აღიარებენ, ჩაწერის ერთად მაგიდასთან. როდესაც ჩაწერის მოდის, ჩვენ წერენ მეშვეობით ინდექსი. ჩვენ დაწერა მაგიდა, და მაშინ ჩვენ აღიარებს. ასე რომ, თანმიმდევრული. მას შემდეგ, რაც ჩაწერის უკვე აღიარა, მაგიდა, ეს არის გარანტირებული, რომ ადგილობრივი საშუალო ინდექსი ექნება იგივე ხედვა მონაცემები. მაგრამ, რაც მათ საშუალებას მისცემს თქვენ არ არის განსაზღვრავს ალტერნატიული სპექტრი გასაღებები. 

უნდა გამოვიყენოთ იგივე hash გასაღები, როგორც პირველადი მაგიდა, იმიტომ, რომ ისინი თანადაფინანსების მდებარეობს იგივე დანაყოფი, და ისინი შეესაბამება. მაგრამ მე შემიძლია შექმნა ინდექსი სხვადასხვა სპექტრის გასაღებები. ასე მაგალითად, თუ მქონდა მწარმოებელი რომ ჰქონდა ნედლეული ნაწილები მაგიდა მოდის. და ნედლეულის ნაწილები მოდის და ისინი ერთიანი მიერ ასამბლეის. და იქნებ იქ გაწვევას. 

ნებისმიერი ნაწილი, რომელიც გააკეთა ამ მწარმოებელი შემდეგ ეს თარიღი, მე უნდა გაიყვანოს ჩემი ხაზი. შემიძლია დაიძაბება ინდექსი რომ იქნება ეძებს, აგრეგაცია on თარიღი საწარმოებლად რომ კონკრეტული ნაწილი. ასე რომ, თუ ჩემი ზედა დონის მაგიდა უკვე hashed მწარმოებელი, შესაძლოა, ეს მოეწყო ნაწილი ID, მე შეგიძლიათ შექმნათ ინდექსი off მაგიდა როგორც hashed მიერ მწარმოებელი და განმეორებადი თარიღის წარმოება. და რომ გზა მე ვერ ვიტყვი, ყველაფერი, დამზადებულია შორის თარიღების, მე უნდა გაიყვანოს ხაზი. ასე რომ, ადგილობრივი საშუალო ინდექსი. 

ეს აქვს ეფექტი შეზღუდვის თქვენი hash გასაღები სივრცეში. იმის გამო, რომ ერთ-არსებობდა იმავე შენახვის კვანძის, ისინი ზღუდავს hash გასაღები ფართი 10 გბ. DynamoDB ქვეშ მაგიდები, რომელიც დანაყოფი თქვენი მაგიდა 10 გბ. როდესაც თქვენ დააყენა 10 gigs მონაცემების, ჩვენ წასვლა [PHH], და ჩვენ დაამატოთ კიდევ ერთი კვანძის. 

ჩვენ არ გაყოფილი LSI მასშტაბით სხვადასხვა დანაყოფები. ჩვენ გაყოფილი მაგიდა. მაგრამ ჩვენ არ გაყოფილი LSI. ასე რომ რაღაც მნიშვნელოვანია იმის გაგება, არის, თუ რას აკეთებს ძალიან, ძალიან, ძალიან დიდი გუნდების შეკრების, მაშინ ვაპირებთ უნდა შეიზღუდოს 10 გბ თქვენი LSIs. 

თუ ეს საქმე, ჩვენ შეგვიძლია გამოიყენოთ გლობალური secondaries. Global secondaries არიან მართლაც სხვა მაგიდასთან. ისინი არსებობენ სრულიად off to მხარეს თქვენი პირველადი მაგიდასთან. და ისინი საშუალებას ჩემთვის მოძიების სრულიად განსხვავებული სტრუქტურა. ასე რომ, ვფიქრობ, რომ ეს მონაცემები შეიყვანეს ორ სხვადასხვა მაგიდები, სტრუქტურა ორ სხვადასხვა გზები. 

მე შეუძლია განსაზღვროს სრულიად სხვადასხვა hash გასაღები. მე შეუძლია განსაზღვროს სრულიად სხვადასხვა სპექტრს გასაღები. და შემიძლია აწარმოებს ამ სრულიად დამოუკიდებლად. როგორც ფაქტობრივად, მე შესაბამისად, ჩემი წაკითხული მოცულობა და დაწეროთ მოცულობა ჩემი გლობალური საშუალო ინდექსები სრულიად დამოუკიდებლად ჩემი პირველადი მაგიდასთან. თუ მე განმარტავენ, რომ ინდექსი, მე გეტყვით ის, თუ რამდენად წაიკითხოთ და დაწეროთ სიმძლავრის ის აპირებს გამოყენებით. 

და ეს არის ცალკე ჩემი პირველადი მაგიდასთან. ახლა ორივე ინდექსები საშუალებას გვაძლევს არა მარტო განსაზღვროს hash და სპექტრი გასაღებები, მაგრამ ისინი საშუალებას მოგვცემს პროექტის დამატებითი ღირებულებები. ასე რომ, თუ მე მინდა წაიკითხონ off ინდექსი, და მე მინდა, რომ მიიღოთ გარკვეული კომპლექტი მონაცემები, მე არ უნდა დაბრუნდეს მთავარი მაგიდასთან მიიღოს დამატებითი ატრიბუტები. შემიძლია პროექტის იმ დამატებით ატრიბუტებს შევიდა მაგიდა ხელი შეუწყოს ხელმისაწვდომობის ნიმუში. მე ვიცი, რომ ჩვენ, ალბათ, მისაღებად შევიდა რაღაც მართლაც, ნამდვილად მისაღებად შევიდა სარეველა აქ ზოგიერთი ამ პერსონალის. ახლა მე მივიღე დრიფტის ამ. 

აუდიტორია: [INAUDIBLE] --table გასაღები ნიშნავდა იყო hash? ორიგინალური hash? Multi-slats? 

RICK Houlihan: დიახ. დიახ. მაგიდა გასაღები ძირითადად მიუთითებს უკან ნივთი. ასე რომ, ინდექსი არის მაჩვენებელი უკან ორიგინალური ნივთები მაგიდაზე. ახლა თქვენ შეგიძლიათ აშენება ინდექსი, რომელიც მხოლოდ მაგიდა გასაღები, და არსებობს სხვა თვისებები. და რატომ შეიძლება ამის გაკეთება? ისე, იქნებ მე მაქვს ძალიან დიდი საკითხი. 

მე ნამდვილად მხოლოდ უნდა იცოდეს which-- ჩემი ხელმისაწვდომობის ნიმუში შეიძლება ითქვას, რომელიც ელემენტი შეიცავდეს ეს ქონება? არ უნდა დაბრუნდეს ერთეულზე. მე უბრალოდ უნდა იცოდეს რომელი ელემენტი შეიცავდეს იგი. ასე რომ, თქვენ შეძლოთ ინდექსები რომ მხოლოდ მაგიდა გასაღები. 

მაგრამ ეს, პირველ რიგში, რა ინდექსი მონაცემთა ბაზაში არის. ეს არის, რომ შეუძლია სწრაფად იდენტიფიცირება, რომელიც შეაქვს, რომელიც რიგები, რომლებიც ნივთები მაგიდაზე აქვს თვისებები, მე ეძებს. 

GSIs, ასე როგორ მუშაობს? GSIs ძირითადად ასინქრონული. განახლება ძალაში მაგიდა, მაგიდა მაშინ asynchronously მხრიდან ყველა თქვენი GSIs. სწორედ ამიტომ, GSIs არიან საბოლოოდ თანმიმდევრული. 

მნიშვნელოვანია აღინიშნოს, რომ როდესაც თქვენ აშენებთ GSIs, და თქვენ იცით, თქვენ შექმნით სხვა განზომილება aggregation-- ახლა მოდით ვთქვათ, კარგი მაგალითი აქ არის მწარმოებელი. მე ვფიქრობ, რომ, შესაძლოა, ისაუბრა სამედიცინო მოწყობილობა მწარმოებელი. სამედიცინო მოწყობილობა მწარმოებლები ხშირად აქვს serialized ნაწილები. ნაწილები, რომ წასვლას ჰიპ ჩანაცვლება ყველა აქვს პატარა სერიული ნომერი მათ. და შესაძლოა მილიონობით და მილიონობით და მილიარდობით ნაწილები ყველა მოწყობილობა, რომელიც მათ დაძრულიყო. ისე, რომ ისინი უნდა გააერთიანონ ქვეშ სხვადასხვა ზომები, ყველა ნაწილები in შეკრების, ყველა ნაწილები, რომ გაკეთდა გარკვეული ხაზი, ყველა ნაწილებს, რომ მოვიდა საწყისი გარკვეული მწარმოებელი გარკვეული თარიღი. და ეს aggregations ზოგჯერ მისაღებად შევიდა მილიარდობით. 

ასე რომ, მე მუშაობა ზოგიერთი ეს ბიჭები, რომლებიც დაავადებული იმიტომ, რომ ისინი შექმნა ამ ginormous aggregations მათი საშუალო ინდექსები. ალბათ ნედლეული ნაწილები მაგიდა, რომელიც მოდის როგორც hash მხოლოდ. ყველა ნაწილი აქვს უნიკალური სერიული ნომერი. მე სერიული ნომერი, როგორც hash. ის ლამაზია. ჩემი ნედლეული მონაცემების მაგიდა გავრცელდა მთელს გასაღები სივრცეში. ჩემი [? წერენ?] [? შიგნით მიღებისას?] გასაოცარია. მე მიიღოს ბევრი მონაცემები. მაშინ რას აკეთებს ქმნიან GSI. და მე ვიტყვი, რომ თქვენ იცით, რა, მე უნდა ნახოთ ყველა ნაწილები ამ მწარმოებელი. ისე, უეცრად მე აღების მილიარდი რიგები, და პერსონალის მათ გადატანა ერთი კვანძის, რადგან, როდესაც მე საერთო, როგორც მწარმოებელი ID როგორც hash, და ნაწილი ხმების როგორც სპექტრი, მაშინ ყველა მოულოდნელად, მე ვარ აყენებს მილიარდი ნაწილების რა ეს მწარმოებელი დამიხსნა. 

ეს შეიძლება გამოიწვიოს ბევრი ზეწოლის GSI, ერთხელ, იმიტომ, რომ მე როდესმე ერთი კვანძის. მე აყენებს ყველა ამ ჩანართები ერთი კვანძის. და ეს არის რეალური პრობლემური გამოყენების შემთხვევაში. ახლა, მე მივიღე კარგი დიზაინი ნიმუში, თუ როგორ ავიცილოთ, რომ. და ეს არის ერთ-ერთი პრობლემა რომ მე ყოველთვის მუშაობა. მაგრამ რა ხდება, არის GSI შეიძლება არ გაქვთ საკმარისი ჩაწერის მოცულობა შეძლებს დააყენებს ყველა იმ რიგები შევიდა ერთი კვანძის. და მერე რა არის პირველადი, კლიენტს მაგიდა, ძირითადი ცხრილი შეიზღუდება იმის გამო, რომ GSI ვერ შეინარჩუნოს. ასე რომ, ჩემი ჩანართით კურსი დაეცემა ძირითადი ცხრილი როგორც ჩემი GSI ცდილობს შეინარჩუნოს. 

ყველა უფლება, GSI ის, LSI ის, რომელიც ერთი უნდა გამოვიყენო? LSI ს შეესაბამება. GSI ს საბოლოოდ თანმიმდევრული. თუ ეს კარგია, მე რეკომენდაციას გამოყენებით GSI, ისინი ბევრად უფრო მოქნილი. LSI ის შეიძლება მოდელირებული როგორც GSI. და თუ მონაცემები ზომა პოსტი hash გასაღებები თქვენი კოლექცია აღემატება 10 გიგაბაიტი, მაშინ ვაპირებთ გვინდა, რომ გამოიყენოს GSI, რადგან ეს უბრალოდ მძიმე ლიმიტი. 

ყველა უფლება, სკალირების. გამტარუნარიანობა დინამოში DB, თქვენ can დებულება [INAUDIBLE] , მთელს მაგიდა. ჩვენ მომხმარებელს, რომ აქვს შესაბამისად 60 მლრდ ვაკეთებთ 60 მილიარდი მოითხოვს, რეგულარულად გაშვებული მილიონზე მეტი მოითხოვს წამში ჩვენს მაგიდები. იქ ნამდვილად არ არის თეორიული ზღვარი, თუ რამდენად და რამდენად სწრაფად მაგიდა შეგიძლიათ აწარმოებს დინამო DB. არსებობს რბილი ლიმიტები თქვენი ანგარიში რომ ჩვენ იქ, ასე რომ არ წავიდეთ გიჟები. თუ გსურთ უფრო მეტია, ვიდრე რომ, არ არის პრობლემა. თქვენ მოვიდა გვითხრათ. ჩვენ აქციოს dial. 

ყველა ანგარიში შემოიფარგლება გარკვეული დონის ყველა მომსახურება, უბრალოდ off bat ასე რომ, ადამიანი არ გიჟები თავად შევიდა უბედურება. არ ლიმიტი ზომა. თქვენ შეგიძლიათ განათავსოთ ნებისმიერი რაოდენობის ნივთები მაგიდაზე. ზომა საქონელი შემოიფარგლება 400 kilobytes ყოველი, რომ იქნება ნივთი არ ატრიბუტები. ასე რომ, თანხა ყველა ატრიბუტები შემოიფარგლება 400 kilobytes. და მერე ისევ, ჩვენ გვაქვს რომ პატარა LSI საკითხი ერთად 10 გბ ლიმიტი პოსტი hash. აუდიტორია: მცირე რაოდენობით, მე დაკარგული თუ რას მეუბნებოდა, რომ არის აუდიტორია: Oh, 400 kilobyte მაქსიმალური ზომის ერთეულზე. ასე რომ ნივთი აქვს ყველა ატრიბუტები. ასე რომ, 400 ლ არის სულ ზომა რომ პუნქტის, 400 kilobytes. ასე რომ, ყველა ატრიბუტები კომბინირებული, ყველა მონაცემები რომ არის ყველა იმ ატრიბუტები, შემოვიდა შევიდა საერთო ზომა, გაკეთებული დღეს ნივთი ლიმიტი 400 k. ასე რომ, სკალირების ერთხელ მიაღწია მეშვეობით დაყოფის. გამტარუნარიანობა მომარაგებულია მაგიდასთან დონეზე. და იქ მართლაც ორი knobs. ჩვენ წავიკითხე მოცულობა და დაწეროთ მოცულობა. 

ასე რომ, ეს არის მორგებული ერთმანეთისგან დამოუკიდებლად. RCU ის ღონისძიება მკაცრად თანმიმდევრული განცხადებაში. OK, ასე რომ, თუ თქვენ ვამბობ, მინდა 1,000 RCU ის იმ მკაცრად თანმიმდევრული, ეს არის თანმიმდევრული განცხადებაში. თუ ამბობენ, რომ მე მინდა საბოლოო თანმიმდევრული ნათქვამია, თქვენ შეგიძლიათ დებულება 1,000 RCU ის, თქვენ აპირებს მისაღებად 2,000 საბოლოოდ თანმიმდევრული განცხადებაში. და ნახევარი ფასი მათთვის, საბოლოოდ შედგება განცხადებაში. 

ისევ და ისევ, მორგებული ერთმანეთისგან დამოუკიდებლად. და მათ აქვთ throughput-- თუ თქვენ მოიხმარენ 100% თქვენი RCU, თქვენ არ აპირებს გავლენა ხელმისაწვდომობა თქვენი უფლებები. ასე რომ, ისინი სრულიად დამოუკიდებელი ერთმანეთს. ყველა უფლება, ასე რომ, ერთი რამ, რომ ვთქვი მოკლედ იყო throttling. Throttling არის ცუდი. Throttling მიუთითებს ცუდი არ SQL. არსებობს რამ შეგვიძლია გავაკეთოთ, რათა დაეხმაროს თქვენ შემსუბუქება throttling, რომ თქვენ განიცდის. მაგრამ საუკეთესო გამოსავალი რომ ეს არის ავიღოთ შევხედოთ, თუ რას აკეთებს, რადგან იქ ანტი-ნიმუში პიესა აქ. 

ეს ყველაფერი, რამ, როგორიცაა არაერთგვაროვანი სამუშაო, ცხელი კლავიშები, ცხელი დანაყოფი. მე დარტყმის კონკრეტული გასაღები სივრცეში ძალიან ძნელია რაიმე კონკრეტული მიზეზი. რატომ აკეთებს ამას? მოდით გაერკვნენ, რომ. მე შერევით ჩემი ცხელი მონაცემების ცივი მონაცემები. მე გაქირავების ჩემი მაგიდები მისაღებად დიდი, მაგრამ იქ ნამდვილად მხოლოდ რამდენიმე ქვეჯგუფი მონაცემები რომ მართლაც საინტერესო იყო ჩემთვის. ასე რომ, ჟურნალი მონაცემები, მაგალითად, ბევრი მომხმარებელს, ისინი შეხვიდეთ მონაცემების ყოველდღე. ისინი დიდი ოდენობით შესვლა მონაცემები. 

თუ თქვენ მხოლოდ გადაყრა, რომ ყველა ჟურნალი მონაცემები ერთი დიდი მაგიდა, დროთა განმავლობაში მაგიდა აპირებს მიიღოს მასიური. მაგრამ მე მართლაც მხოლოდ დაინტერესებული ბოლო 24 საათის განმავლობაში, ბოლო შვიდი დღის განმავლობაში, ბოლო 30 დღის განმავლობაში. როგორიც არ უნდა იყოს ფანჯარა დრო რომ მე ვარ დაინტერესებული ეძებს ღონისძიება, რომელიც მაწუხებს, ან იმ შემთხვევაში, ჩემთვის საინტერესოა, ეს არის ერთადერთი window დრო, რომ მე უნდა. ასე რომ, რატომ ვარ მე აყენებს 10 წლის ღირს შესვლა მონაცემები მაგიდაზე? რა, რომ იწვევს არის მაგიდა ფრაგმენტი. 

იგი იღებს დიდი. იგი იწყება გავრცელების მასშტაბით ათასობით კვანძების. მას შემდეგ, რაც თქვენი შესაძლებლობების იმდენად დაბალია, თქვენ რეალურად შეფასება შეზღუდვის ყოველ ერთ-ერთი იმ ინდივიდუალური კვანძების. მოდით დავიწყოთ შევხედავთ, როგორ ნუ ჩვენ გააფართოვოს, რომ მაგიდაზე მეტი. როგორ ჩვენ შევძლებთ, რომ მონაცემები პატარა უკეთესი, რათა თავიდან ავიცილოთ ეს პრობლემა. და რას ჰგავს? ეს არის რა, რომ ჰგავს. ეს არის ის, რაც ცუდი NoSQL ჰგავს. 

მე მივიღე ცხელი გასაღები აქ. თუ გადავხედავთ ამ მხარეს, ეს არის ყველა ჩემი დანაყოფი. მე მივიღე 16 დანაყოფები აქ ამ კონკრეტულ მონაცემთა ბაზაში. ჩვენ ამას ვაკეთებთ, ყველა დროის. მე აწარმოებს ამ მომხმარებელს ყველა დროის. ეს მოუწოდა სითბოს რუკა. სითბოს რუკა მეუბნება, როგორ თქვენ წვდომის თქვენი გასაღები სივრცეში. და რას მეუბნებოდა ის არის, რომ არსებობს ერთი კონკრეტული hash რომ ეს ბიჭი მოსწონს საშინელი ბევრი, იმიტომ, რომ ის დარტყმის რეალურად, მართლაც მძიმეა. 

ასე რომ, ლურჯი არის ლამაზი. ჩვენ გვსურს, ლურჯი. ჩვენ არ მიყვარს წითელი. წითელი სადაც ზეწოლის იღებს მდე 100%. 100%, ახლა თქვენ უნდა აღვადგინოთ. ასე რომ, როდესაც თქვენ ხედავთ რაიმე წითელი ხაზები ამას და ეს არ არის მხოლოდ დინამოს DB-- ყველა NoSQL მონაცემთა ბაზის აქვს ეს პრობლემა. არსებობს საწინააღმდეგო ნიმუშების, რომ შეუძლია მანქანა ამ ტიპის პირობებს. რა გავაკეთო არის მე მუშაობა მომხმარებელს შემსუბუქება ამ პირობებში. 

და რას ჰგავს? და ეს არის მიღების ყველაზე გარეთ დინამო DB გამტარუნარიანობა, მაგრამ ეს ნამდვილად მისაღებად ყველაზე გარეთ NoSQL. ეს არ არის შეზღუდული დინამო. ეს არის definitely-- მე გამოყენებული მუშაობა Mongo. მე ვარ იცნობს ბევრი NoSQL პლატფორმაზე მუშაობს. ყველას აქვს ამ ტიპის ცხელი ძირითადი პრობლემები. იმისათვის, რომ მიიღოთ საუკეთესო out ნებისმიერი NoSQL მონაცემთა ბაზა, კონკრეტულად დინამო DB, გსურთ შექმნათ მაგიდები სადაც hash გასაღები ელემენტს აქვს დიდი რაოდენობით განსხვავებული ღირებულებები, მაღალი ხარისხის cardinality. იმის გამო, რომ ეს ნიშნავს, რომ მე წერა უამრავი სხვადასხვა თაიგულების. 

უფრო მეტი თაიგულების ვარ წერა, უფრო სავარაუდოა, მე ვარ გავრცელდა ინფორმაცია, რომ ჩაწერის დატვირთვის ან წაკითხვის ჩატვირთვა მასშტაბით რამდენიმე კვანძების, უფრო სავარაუდოა, რომ მე ვარ, რომ აქვს მაღალი წარმადობის მაგიდაზე. და მაშინ მე მინდა, რომ ღირებულებები მოთხოვნილი საკმაოდ თანაბრად დროთა განმავლობაში და ერთნაირად, როგორც შემთხვევით, რაც შეიძლება. ისე, რომ სახის საინტერესო, იმიტომ, რომ მე ნამდვილად ვერ კონტროლის როდესაც შემოდიან მომხმარებლები. ასე რომ, საკმარისია ვთქვა, თუ ჩვენ გავრცელდა რამ მთელს გასაღები სივრცეში, ჩვენ, ალბათ, უკეთეს ფორმაში. 

არსებობს გარკვეული დროის მიწოდება რომ თქვენ არ აპირებს შეძლებს კონტროლი. მაგრამ ეს ნამდვილად ორ ზომები, რომ ჩვენ გვაქვს, სივრცეში, ხელმისაწვდომობის თანაბრად გავრცელება, დრო მოითხოვს ჩამოსვლის თანაბრად განაწილებული დრო. და თუ ამ ორ პირობები მიმდინარეობს შეხვდა, მაშინ, რომ ის, რაც ეს აპირებს გამოიყურებოდეს. ეს არის ბევრად გავალამაზოთ. ჩვენ ნამდვილად ბედნიერი აქ. ჩვენ მივიღეთ ძალიან კი ხელმისაწვდომობის ნიმუში. ჰო, იქნებ თქვენ მიღების პატარა წნევა ყველა ახლა და შემდეგ, მაგრამ ნამდვილად ძალიან ფართო. ასე რომ, ეს საოცარი რამდენჯერ როდესაც მე მუშაობა მომხმარებელს, რომ პირველ გრაფაში დიდი წითელი ბარი და ყველა, რომ მახინჯი ყვითელი ეს მთელი ადგილი, ჩვენ უნდა გაკეთდეს exercise მას შემდეგ, რაც რამდენიმე თვის ხელახალი არქიტექტურა, ისინი გაშვებული ზუსტად იგივე დატვირთვა ზუსტად იგივე დატვირთვა. და ეს არის ის, რაც ის ეძებს, როგორც ახლა. ასე რომ, რაც თქვენ მიიღებთ NoSQL არის მონაცემთა schema რომ აბსოლუტურად მიბმული ხელმისაწვდომობის ნიმუში. 

და შეგიძლიათ ოპტიმიზაცია, რომ მონაცემები სქემის ხელი შეუწყოს, რომ ხელმისაწვდომობის ნიმუში. თუ არ, მაშინ თქვენ აპირებს ვხედავ, რომ იმ სახის პრობლემები იმ ცხელი კლავიშები. 

აუდიტორია: ისე, აუცილებლად რაღაც ადგილებში ვაპირებთ იყოს ცხელი, ვიდრე სხვები. 

RICK Houlihan: ყოველთვის. ყოველთვის. ჰო, მე ვგულისხმობ, იქ ყოველთვის a-- და ისევ, ზოგიერთი დიზაინის ნიმუშები, ჩვენ მივიღებთ მეშვეობით რომელიც გაიგო, თუ როგორ გაუმკლავდეთ ამ სუპერ დიდი aggregations. მე ვგულისხმობ, მე მივიღე, რომ მათ, როგორ უნდა გავუმკლავდეთ მათ? მე მივიღე საკმაოდ კარგი გამოყენების შემთხვევაში რომ ჩვენ ვსაუბრობთ, რომ. 

ყველა უფლება, მოდით განხილვა ზოგიერთი მომხმარებელს ახლა. ეს ბიჭები არიან AdRoll. მე არ ვიცი, თუ თქვენ იცნობს AdRoll. თქვენ, ალბათ, ხედავთ მათ ბევრი ბრაუზერში. ისინი რეკლამა ხელახლა გათვლილი, ისინი უდიდესი რეკლამა ხელახალი გათვლილი ბიზნეს იქ. ისინი ჩვეულებრივ რეგულარულად აწარმოებს მეტი 60 მილიარდი ოპერაციების დღეში. ისინი აკეთებენ მილიონზე მეტი ოპერაციები წამში. მათ მოხვდით საკმაოდ მარტივია მაგიდა სტრუქტურა, დატვირთული მაგიდა. ეს, ძირითადად, მხოლოდ hash გასაღები არის ფუნთუშა, დიაპაზონი არის დემოგრაფიული მიხედვით, ხოლო შემდეგ მესამე ატრიბუტი ანგარიში. 

ასე რომ, ჩვენ გვაქვს ყველა cookies in ჩვენი ბრაუზერის ამ ბიჭებს. და როცა წასვლა მონაწილე სავაჭრო, ისინი ძირითადად ქულა მასშტაბით სხვადასხვა დემოგრაფიული კატეგორიები. როცა წასვლა საიტი და თქვენ ამბობთ, მე მინდა, რომ ეს ad-- ან ძირითადად თქვენ არ ვამბობ that-- მაგრამ როდესაც თქვენ წასვლა ნახვა ისინი აცხადებენ, რომ თუ გვინდა, რომ ეს რეკლამა. და ისინი მიიღოს, რომ რეკლამა საწყისი AdRoll. AdRoll გამოიყურება თქვენ up მათი მაგიდა. ისინი თქვენი cookie. რეკლამის ვეუბნებოდი მათ, მე მინდა ვინმემ ვინ არის შუახნის, 40 წლის მამაკაცი, სპორტის. და ისინი ანგარიშით თქვენ იმ დემოგრაფიული და ისინი გადაწყვეტენ თუ არა რომ კარგი რეკლამა თქვენთვის. 

ახლა მათ აქვთ SLA ერთად სარეკლამო პროვაიდერები გთავაზობთ sub-10 millisecond პასუხი ყოველ მოთხოვნით. ასე რომ, ისინი გამოყენებით დინამო DB ამ. ისინი დარტყმის ჩვენთვის მილიონი მოითხოვს წამში. ისინი შეძლებენ ყველა მათი lookups, ამოწმებდნენ, ყველა, რომ მონაცემები, და მიიღოს, რომ დაამატოთ ბმული უკან, რომ რეკლამის ქვეშ 10 მილიწამი. ეს მართლაც საკმაოდ ფენომენალური განხორციელება, რომელიც მათ აქვთ. 

ეს ბიჭები რეალურად არის ეს ბიჭები. მე არ ვარ დარწმუნებული, თუ ის ამ ბიჭებს. შეიძლება ამ ბიჭებს. ძირითადად განუცხადა us-- არა, მე არ ვფიქრობ, რომ ეს იყო მათ. ვფიქრობ, ეს იყო სხვისი. ვმუშაობდი ერთად მომხმარებელს, რომ მითხრა, რომ ახლა, რომ ისინი წავიდა დინამო DB, ისინი ხარჯვის მეტი ფული საჭმლის მათი განვითარების გუნდი ყოველთვიურად ვიდრე ისინი ატარებენ მათ მონაცემთა ბაზაში. ასე რომ, ეს მოგცემთ იდეა ხარჯების რომ თქვენ შეგიძლიათ მიიღოთ დინამოში DB არის უზარმაზარი. ყველა უფლება, dropcam არის კიდევ ერთი კომპანია. ეს ბიჭი არის სახის of-- თუ ფიქრობთ, ინტერნეტ რამ, dropcam ძირითადად ინტერნეტ უსაფრთხოების ვიდეო. თქვენ განათავსოთ თქვენი კამერა არსებობს. კამერა აქვს მოძრაობის დეტექტორი. ვიღაც მოდის, იწვევს cue წერტილი. კამერა იწყება ჩაწერა, ხოლო წლამდე ეს არ აღმოაჩინოს ნებისმიერი მოძრაობის მთელი მსოფლიოს მასშტაბით. აყენებს, რომ ვიდეო ინტერნეტში. 

Dropcam იყო კომპანია, რომელიც არის ძირითადად გადავიდა დინამო DB იმიტომ, რომ ისინი განიცდის უზარმაზარი მზარდი ტკივილი. და რა გვითხრეს, მოულოდნელად petabytes მონაცემები. მათ არ ჰქონდათ მათი მომსახურება იქნება იმდენად წარმატებული. სხვა შემომავალი ვიდეო, ვიდრე YouTube არის რა ეს ბიჭები იღებენ. ისინი იყენებენ DynamoDB აკონტროლოთ ყველა მეტამონაცემების ყველა მათი ვიდეო გასაღები რაოდენობა. 

ასე, რომ მათ S3 თაიგულების ისინი დააყენებს ყველა ორობითი ნივთები შევიდა. და შემდეგ მათ აქვთ დინამო DB ჩანაწერი, რომელიც მიუთითებენ ხალხს იმ S3 სამი ობიექტი. როდესაც ისინი უნდა შევხედოთ ვიდეო, ისინი ეძებოთ ჩანაწერი დინამო DB. ისინი დააწკაპუნეთ ბმულზე. ისინი გაიყვანოს ქვემოთ ვიდეო S3. ასე რომ, ერთგვარი, თუ რას ჰგავს. და ეს არის სწორი მათი გუნდი. 

დინამო DB ამცირებს მათ მიწოდების დრო ვიდეო მოვლენების ხუთიდან 10 წამი. მათი ძველი რელატიური მაღაზიაში, ისინი გამოიყენება, უნდა წავიდეს და შეასრულოს მრავალი რთული შეკითხვებს ფიგურა გაირკვეს, თუ რომელი ვიდეო გაიყვანოს ქვემოთ, ნაკლებია, ვიდრე 50 მილიწამი. ასე რომ, ეს საოცარი, საოცარი რამდენად შესრულება შეგიძლიათ მიიღოთ, როდესაც თქვენ ოპტიმიზაცია და სრულყოფილი ფუძემდებლური მონაცემთა ბაზაში ხელი შეუწყოს ხელმისაწვდომობის ნიმუში. Halfbrick, ეს ბიჭები, რა არის ეს, Fruit Ninja ვხვდები რამ. რომ ყველა ეშვება დინამო DB. ეს ბიჭები, ისინი დიდი განვითარების გუნდი, დიდი განვითარება მაღაზია. 

არ არის კარგი ops გუნდი. მათ არ უნდა ბევრი ოპერაციის რესურსები. ისინი იბრძვიან ცდილობს შეინარჩუნოს მათი გამოყენების ინფრასტრუქტურის და გაშვებული. მოვიდნენ ჩვენთან. მათ შევხედე, რომ დინამოს DB. მათი თქმით, ეს არის ის, ჩვენთვის. მათ ააშენეს თავისი მთელი განაცხადის ფარგლებში იგი. ზოგიერთი მართლაც ლამაზი კომენტარი აქ გუნდი თავის შესაძლებლობებს ახლა ფოკუსირება შენობა თამაში და არა მქონე, რომ შევინარჩუნოთ ინფრასტრუქტურა, რომელიც ხდება უზარმაზარი თანხა ოვერჰედის მათი გუნდი. ასე რომ, ეს არის ის, that-- ისარგებლოს, რომ თქვენ დინამო DB. 

ყველა უფლება, მისაღებად შევიდა მონაცემთა მოდელირება აქ. ჩვენ ვისაუბრეთ ცოტა შესახებ ეს ერთ ერთი, ერთი, რომ ბევრი, და ბევრი ბევრი ტიპის ურთიერთობები. და როგორ შეინარჩუნოს იმ დინამო. დინამოში DB ვიყენებთ ინდექსები, ზოგადად, როტაცია მონაცემები ერთი არომატი სხვა. Hash გასაღებები, სპექტრი გასაღებები და ინდექსები. 

ამ კონკრეტულ მაგალითად, ყველაზე შტატები აქვს ლიცენზირების მოთხოვნა, რომ მხოლოდ ერთი მძღოლის მოწმობა სულზე. თქვენ არ შეგიძლიათ მიიღოთ ორი მძღოლის ლიცენზიების სახელმწიფო ბოსტონის. მე არ შემიძლია ამის გაკეთება ტეხასის. სწორედ ასეთი გზა ის არის. ასე რომ, იმ DMV, ჩვენ lookups, ჩვენ გვინდა, რომ ეძებოთ მართვის მოწმობა სოციალური დაცვის ნომერი. მინდა ეძებოთ შესახებ დეტალები მძღოლის ლიცენზიის ნომერი. 

ასე რომ, ჩვენ შეიძლება ჰქონდეს მომხმარებლის მაგიდა, რომელიც აქვს hash გასაღები სერიული ნომერი, ან სოციალური დაცვის ნომერი, და სხვადასხვა ატრიბუტები განსაზღვრული ნივთი. ახლა, რომ მაგიდასთან მე შეიძლება განისაზღვროს GSI რომ შეიჭრება, რომ გარშემო, რომელიც ამბობს, მინდა ქეშირების გასაღები ლიცენზია და შემდეგ ყველა სხვა საკითხი. ახლა, თუ გვინდა, რომ შეკითხვის და იპოვოს ლიცენზიის ნომერი ნებისმიერი მოცემული სოციალური დაცვის ნომერი, შემიძლია შეკითხვის მთავარ მაგიდაზე. 

თუ მინდა შეკითხვის და მინდა მიიღოს სოციალური უსაფრთხოების ნომერი ან სხვა ატრიბუტები მიერ ლიცენზიის ნომერი, შემიძლია შეკითხვის GSI. ეს მოდელი არის, რომ ერთი ერთი ურთიერთობისათვის. უბრალოდ ძალიან მარტივი GSI, flip იმ რამ გარშემო. ახლა ვისაუბროთ ერთი ბევრი. ერთი ბევრი, ძირითადად, თქვენი hash სპექტრი გასაღები. სადაც ჩვენ კიდევ ბევრი ამ გამოყენების შემთხვევაში არის მონიტორზე მონაცემები. მონიტორი მონაცემები მოდის რეგულარული ინტერვალით, როგორიცაა ინტერნეტ რამ. ჩვენ ყოველთვის ყველა ეს ჩანაწერების მოდის ყველა დროის. 

და მე მინდა, რათა გამოინახოს კითხვას შორის დროის გარკვეულ პერიოდში. ეს არის ძალიან გავრცელებული შეკითხვაზე მონიტორინგის ინფრასტრუქტურა. გზა წავიდეთ შესახებ, რომ ის არის, მარტივი ცხრილის სტრუქტურა, ერთ მაგიდასთან. მაქვს მოწყობილობის ღონისძიებების მაგიდა ერთად hash გასაღები მოწყობილობის ID. და მე მაქვს მთელი რიგი გასაღები დროის ნიშნულს, ან ამ შემთხვევაში, ეპიკური. და რომელიც საშუალებას აძლევს ჩემთვის შეასრულოს კომპლექსური შეკითხვებს წინააღმდეგ რომ დიაპაზონი გასაღები და დაბრუნდება ის ჩანაწერი, რომ დაკავშირებულია შედეგი მითითებული, რომ მე ვეძებ. და ის აშენებს, რომ ერთი ბევრი ურთიერთობისათვის დაწყებითი მაგიდასთან გამოყენებით hash გასაღები, სპექტრი გასაღები სტრუქტურა. 

ასე რომ სახის აშენებული ცხრილში დინამოში DB. როცა განსაზღვრავს hash და დიაპაზონი t მაგიდა, მე განსაზღვრის ერთი მრავალთან კავშირი. ეს მშობლისა და შვილის ურთიერთობა. 

მოდით ვისაუბროთ ბევრი ბევრი ურთიერთობები. და ამ კონკრეტულ მაგალითს, კიდევ ერთხელ, ჩვენ ვაპირებთ გამოვიყენოთ GSI ს. და მოდით ვისაუბროთ სათამაშო სცენარი, სადაც მე მაქვს მოცემული შესახებ. მინდა, რათა გაირკვეს ყველა თამაშები რომ ის რეგისტრირებული ან თამაშობენ. და მოცემულ თამაშში, მე უნდათ, რომ ყველა მომხმარებლებს. ასე რომ, როგორ შემიძლია ამის გაკეთება? ჩემი პროფაილი თამაშები მაგიდა, მე ვაპირებ აქვს hash გასაღები პროფაილი ID და რიგი გასაღები თამაში. 

ასე რომ, მომხმარებელს შეუძლია რამდენიმე თამაშები. ეს არის ერთი ბევრი შორის ურთიერთობა მომხმარებელი და თამაშები იგი უკრავს. და მერე GSI, მე Flip რომ გარშემო. მე hash თამაში და მე ქედით შესახებ. ასე რომ, თუ გვინდა, რომ ყველა თამაში მომხმარებლის თამაშობენ, მე შეკითხვის მთავარ მაგიდაზე. თუ მინდა, რომ მიიღოს ყველა მომხმარებლები რომ თამაშობენ კონკრეტული თამაში, მე შეკითხვის GSI. ასე რომ, ხედავთ, როგორ გავაკეთოთ ეს? თქვენ აშენება ამ GSI ის მხარდასაჭერად გამოყენების შემთხვევაში, განაცხადი, მისასვლელი ნიმუში, განაცხადი. 

თუ მე უნდა შეკითხვის on ეს განზომილება, ნება ჩემთვის შექმნა ინდექსი, რომელიც განზომილება. თუ მე არა, მე არ მაინტერესებს. და დამოკიდებულია გამოყენების შემთხვევაში, მე შეიძლება საჭირო ინდექსი ან მე შეიძლება არ. თუ ეს უბრალო ერთი ბევრი, ძირითადი ცხრილი კარგად არის. თუ მე უნდა გავაკეთოთ ეს ბევრი ბევრი ის, ან მე უნდა გავაკეთოთ ერთი პირობა, მაშინ იქნებ მე უნდა მეორე ინდექსი. ასე რომ, ეს ყველაფერი დამოკიდებულია იმაზე, რაც მე ვცდილობ და რა ვცდილობ მისაღებად დასრულებულია. 

ალბათ მე არ ვაპირებ დახარჯოს დიდ დროს საუბარი დოკუმენტები. ეს იღებს ცოტა, ალბათ, უფრო ღრმა, ვიდრე ჩვენ უნდა წავიდეთ. მოდით ვისაუბროთ ცოტა მდიდარი შეკითხვის გამოხატვის. ასე რომ, დინამოს DB ჩვენ უნარი შექმნას რაც ჩვენ მოვუწოდებთ პროექტირება გამონათქვამები. პროექტირება გამონათქვამები უბრალოდ კრეფა სფეროებში და ღირებულებების რომ გსურთ ცარიელია. OK, ასე რომ გააკეთოს არჩევანი. მე შეკითხვის წინააღმდეგ დინამო DB. და მე ვიტყვი, იცით, რა, შოუ მე მხოლოდ ხუთვარსკვლავიანი მიმოხილვები ამ კონკრეტული პროდუქტი. ასე რომ, ყველა მინდა ვხედავ. მე არ მინდა, რომ ყველა სხვა ატრიბუტები ზედიზედ, მე უბრალოდ მინდა, რომ ეს. ეს, ისევე, როგორც SQL, როდესაც თქვენ ამბობენ აირჩიეთ ვარსკვლავი ან მაგიდასთან, თქვენ ყველაფერი. როდესაც ვამბობ აირჩიეთ სახელი მაგიდა, მე მხოლოდ ერთი ატრიბუტი. ეს იგივე სახის რამ დინამო DB ან სხვა NoSQL ბაზაში. ფილტრი გამოხატვის ნება მიბოძეთ ძირითადად მოჭრილი შედეგი მითითებული ქვემოთ. ასე რომ, მე შეკითხვაზე. შეკითხვის შეიძლება დავბრუნდებით 500 საკითხი. მაგრამ მე მხოლოდ მინდა, საკითხი, რომ აქვს ატრიბუტი, რომელიც ამბობს, რომ ეს. OK, მოდით გავფილტროთ ის საკითხი, რომ არ ემთხვევა, რომ კონკრეტული შეკითხვა. ასე რომ, ჩვენ ფილტრი გამონათქვამები. 

ფილტრი გამონათქვამები შეუძლია უნდა გაუშვათ ნებისმიერი ატრიბუტი. ისინი არ მომწონს სპექტრი შეკითხვებს. ამაღლება შეკითხვებს უფრო შერჩევითი. ფილტრი შეკითხვებს მოითხოვს მე წასვლა მისაღებად მთელი შედეგები კომპლექტი და შემდეგ გაიყო მონაცემებს მე არ მინდა. რატომ არის ეს მნიშვნელოვანი? იმის გამო, რომ მე წავიკითხე ეს ყველაფერი. ამ შეკითხვაზე, მე ვაპირებ, რომ წაიკითხონ და ეს იქნება გიგანტური შესახებ მონაცემები. და მაშინ მე ვაპირებ გაიყო, თუ რა მჭირდება. და თუ მე მხოლოდ კვეთის გარეთ რამდენიმე რიგები, მაშინ, რომ OK. ეს ასე არ არის არაეფექტური. 

მაგრამ თუ მე კითხულობს მთელი წყობის მონაცემები, უბრალოდ გაიყო ერთი ნივთი, შემდეგ მე ვაპირებ, რომ უკეთესი იქნება off გამოყენებით სპექტრი შეკითხვაზე, იმიტომ, რომ ეს ბევრად უფრო შერჩევითი. ის აპირებს გადარჩენა ჩემთვის ბევრი ფული, იმიტომ, რომ მე გადაიხადოს, რომ წაკითხული. იმ შემთხვევაში, შედეგი, რომელიც ბრუნდება გადაკვეთა, რომ მავთული შეიძლება იყოს პატარა, მაგრამ მე გადამხდელი წაკითხული. ასე რომ, თუ როგორ თქვენ მიღების მონაცემები. ეს ძალიან მნიშვნელოვანია, დინამოში DB. 

პირობითი გამონათქვამები, ეს არის ის, რაც შეიძლება მოვუწოდებთ ოპტიმისტურად საკეტი. განახლების არსებობის შემთხვევაში, ან თუ ეს მნიშვნელობა უდრის, რაც მე დააკონკრეტა. და თუ მაქვს დრო ბეჭდით ჩანაწერი, მე შეიძლება წაიკითხა მონაცემები. მე შეიძლება შეიცვალოს, რომ მონაცემები. მე რომ წერენ, რომ მონაცემების უკან მონაცემთა ბაზაში. თუ ვინმეს შეიცვალა ჩანაწერი, დროის ნიშნულს შეიძლება შეიცვალა. და რომ გზა ჩემი პირობითი განახლება, შეიძლება ითქვას განახლება იმ შემთხვევაში, თუ დროის ნიშნულს უტოლდება ეს. ან განახლება ვერ იმიტომ რომ ვიღაც განახლებული ჩანაწერი ამასობაში. 

ეს არის ის, რაც ჩვენ მოვუწოდებთ ოპტიმისტურად საკეტი. ეს ნიშნავს, რომ ვიღაც შეიძლება დადგეს და შეცვლის, და მე ვაპირებ აღმოაჩინოს ის როდესაც მე დაბრუნდეს დაწერა. და მერე შეიძლება რეალურად წავიკითხე, რომ მონაცემები და თქვათ, მან შეცვალა ეს. მე უნდა ანგარიშზე, რომ. და შემიძლია შეცვლის მონაცემები ჩემი ჩაწერა და ვრცელდება კიდევ ერთი განახლება. ასე რომ თქვენ შეგიძლიათ დაჭერა იმ დამატებითი განახლებები რომ მოხდეს შორის დრო რომ წაიკითხოთ მონაცემები და დროს შეიძლება დაწეროს მონაცემები. 

აუდიტორია: ფილტრი გამოთქმაში, ფაქტობრივად, არ ნიშნავს, რაოდენობის და not-- 

[INTERPOSING ხმები] RICK Houlihan: მე არ ძალიან ბევრი ამ. ეს არის დაცულია სიტყვით. ფუნტი კალენდარი არის დაცულია სიტყვით დინამო DB. ყოველ ბაზაში აქვს საკუთარი დაცულია სახელები კოლექციები თქვენ ვერ გამოიყენებს. დინამო DB, თუ თქვენ მიერ მითითებული ფუნტი წინაშე ამ, შეგიძლიათ განსაზღვრავს იმ სახელები ზემოთ. ეს არის დამოწმებული ღირებულება. ეს, ალბათ, არ არის საუკეთესო სინტაქსი აქვს იქ ამ დისკუსიის, იმიტომ, რომ ეს იღებს შევიდა ზოგიერთი real-- მე უკვე საუბარი უფრო რომ უფრო ღრმა დონეზე. 

მაგრამ საკმარისია ვთქვა, რომ ეს იქნებოდა იყოს შეკითხვის სკანირების სადაც ისინი views-- არც ფუნტი რაოდენობა აღემატება 10. ეს არის რიცხვითი მნიშვნელობა, დიახ. თუ გსურთ, ჩვენ შეგვიძლია ვისაუბროთ მოლაპარაკების შემდეგ. ყველა უფლება, ჩვენ მისაღებად შევიდა ზოგიერთი სცენარი საუკეთესო პრაქტიკის სადაც ჩვენ ვაპირებთ, რომ გაიგო ზოგიერთი apps აქ. რა არის გამოყენების შემთხვევაში დინამო DB. რა არის დიზაინი ნიმუშების დინამო DB. 

და პირველი, ჩვენ ვაპირებთ საუბარი, არის ინტერნეტ რამ. ასე რომ, ჩვენ კიდევ ბევრი of-- ვხვდები, რა არის it-- 50% -ზე მეტი მოძრაობის ინტერნეტში ამ დღეებში რეალურად გამომუშავებული მანქანები, ავტომატიზირებული პროცესების, არა ადამიანები. ვგულისხმობ ამ რამ ამ რამ, რომ თქვენ განახორციელოს გარშემო ჯიბეში, რამდენად მონაცემები, რომ ის არის რეალურად გაგზავნის გარშემო გარეშე თქვენ იცის, რომ ეს არის აბსოლუტურად საოცარი. თქვენი ადგილმდებარეობა, ინფორმაცია რამდენად სწრაფად თქვენ აპირებს. როგორ ფიქრობთ, Google Maps სამუშაოები როცა გეუბნებიან, რა მოძრაობა. ეს იმიტომ, რომ არსებობს მილიონობით და მილიონობით ადამიანი მამოძრავებელი გარშემო ტელეფონები, რომ გაგზავნის მონაცემთა მთელი ადგილი ყველა დროის. ასე რომ, ერთი რამ ამ ტიპის მონაცემები რომ მოდის, მონიტორი მონაცემები, შესვლა მონაცემები, დრო სერია მონაცემები, არის ის, როგორც წესი, მხოლოდ საინტერესო ცოტა დრო. მას შემდეგ, რაც ამ დროს, ის ასე არ არის საინტერესო. ასე რომ, ჩვენ ვისაუბრეთ, არ დაუშვა იმ მაგიდები იზრდება გარეშე საზღვრები. იდეა აქ არის ის, რომ, შესაძლოა, მაქვს 24 საათი ღირს მოვლენები ჩემს ცხელი მაგიდასთან. და ცხელი მაგიდა იქნება შესაბამისად, ძალიან მაღალი მაჩვენებელი, იმიტომ, რომ ის აღების ბევრი მონაცემები. ეს აღების ბევრი მონაცემები და მე კითხულობს მას ბევრი. მაქვს ბევრი ოპერაცია შეკითხვებს გაშვებული წინააღმდეგ, რომ მონაცემები. 

24 საათის შემდეგ, Hey, თქვენ იცით რა, მე არ მაინტერესებს. ასე რომ, შესაძლოა ყოველ შუაღამისას მე roll ჩემი მაგიდა მეტი ახალი მაგიდა და მე deprovision ამ მაგიდასთან. და მე ავიღებ RCU და WCU ქვემოთ იმიტომ, რომ 24 საათის შემდეგ მე არ გაშვებული როგორც ბევრი შეკითხვებს წინააღმდეგ, რომ მონაცემები. ამიტომ, მე ვაპირებ გადარჩენა ფული. და, შესაძლოა, 30 დღის შემდეგ მე არ კი უნდა აინტერესებს ეს ყველაფერი. მე ვერ მიიღოს WCU ს ყველა გზა ქვემოთ ერთი, იმიტომ, რომ თქვენ იცით, რა, ის არასდროს მისაღებად ჩაიწეროს. მონაცემები არის 30 დღის. ეს არასდროს იცვლება. 

და ის თითქმის არასოდეს აპირებს მიიღოს წავიკითხე, მოდით უბრალოდ მიიღოს, რომ RCU ქვემოთ 10. და მე გადარჩენის ტონა ფული ამ მონაცემები და მხოლოდ გადამხდელი ჩემი ცხელი მონაცემები. ასე რომ, მთავარია, თვალი დროს, როდესაც თქვენ შეხედეთ დროის სერია მონაცემთა მოსვლის მოცულობა. ეს არის სტრატეგია. ახლა, მე ვერ უბრალოდ ასეც ყველა წავიდეს, იმავე მაგიდასთან და მხოლოდ ნება, რომ მაგიდაზე იზრდება. საბოლოოდ, მე ვაპირებ იხილეთ შესრულების საკითხები. მე ვაპირებ უნდა დაიწყოს არქივი ზოგიერთი, რომ მონაცემები გაჩნდება, რა არა. 

მოდით ბევრად უკეთესი დიზაინი თქვენი განცხადება ასე რომ თქვენ შეგიძლიათ მუშაობას ამ გზით უფლება. ასე რომ, ეს უბრალოდ ავტომატიკა განაცხადის კოდი. შუაღამისას ყოველ ღამე ეს რულონები მაგიდაზე. იქნებ ის, რაც მჭირდება არის მოცურების ფანჯრიდან 24 საათის მონაცემებით. შემდეგ რეგულარულად ვარ მოუწოდებს მონაცემების გაჩნდება. მე ჩასწორება იგი Cron სამუშაო და მე აყენებს ეს გადატანა ამ მეორე მაგიდები, რაც თქვენ გჭირდებათ. ასე რომ, თუ rollover მუშაობს, რომ დიდი. თუ არა, მორთვა იგი. მაგრამ მოდით შენარჩუნება, რომ ცხელი მონაცემები დაშორებით თქვენი ცივი მონაცემები. ეს გადარჩენა თქვენ ბევრი ფული და რათა თქვენი მაგიდები უფრო ასრულებენ. ასე რომ, შემდეგი რამ ჩვენ ვსაუბრობთ შესახებ არის პროდუქციის კატალოგი. პროდუქტის კატალოგი საკმაოდ გავრცელებული გამოყენების შემთხვევაში. ეს არის რეალურად ძალიან გავრცელებული ნიმუში რომ ჩვენ დავინახავთ სხვადასხვა რამ. თქვენ იცით, Twitter for მაგალითად, ცხელი tweet. ყველას მოდის და grabbing რომ tweet. პროდუქციის კატალოგი, მე მივიღე იყიდება. მე მივიღე ცხელი იყიდება. მე მივიღე 70,000 მოთხოვნები პოსტი მეორე მოდის პროდუქტი აღწერა out of my პროდუქციის კატალოგი. ჩვენ ვხედავთ, ეს საცალო ოპერაცია საკმაოდ მწირი. ასე რომ, როგორ გავუმკლავდეთ, რომ? არ არსებობს გზა უნდა მოგვარდეს, რომ. ყველა ჩემი წევრებს გვინდა, რომ იგივე ნაჭერი მონაცემები. ისინი მოდიან, ერთდროულად. და ისინი ყველა მიღების მოთხოვნები იმავე ნაჭერი მონაცემები. ეს მაძლევს, რომ ცხელი გასაღები, რომელიც დიდი წითელი ზოლიანი ჩემი გრაფიკი, რომ ჩვენ არ მოსწონთ. და ეს რა, რომ ჰგავს. ასე რომ, მთელი ჩემი გასაღები სივრცეში მე მისაღებად ჭედური იყიდება საკითხი. მე მიღების არაფერი არსად. 

როგორ შემიძლია შემსუბუქება ამ პრობლემას? ასევე, ჩვენ შემსუბუქება ამ cache. Cache, დააყენა ძირითადად-მეხსიერება დანაყოფი თვალწინ მონაცემთა ბაზაში. ჩვენ შევძელით [INAUDIBLE] cache, თუ როგორ შეგიძლიათ შექმნას საკუთარი cache, [INAUDIBLE] cache [? დ?] გაგიხარდებათ. იმისათვის, რომ თქვენს წინაშე მონაცემთა ბაზაში. და ამ გზით თქვენ შეგიძლიათ შეინახოთ, რომ მონაცემები იმ ცხელი გასაღებები, რომ cache სივრცე და წაიკითხა მეშვეობით cache. 

და მაშინ ყველაზე თქვენი ნათქვამია დაიწყოს ეძებს მოსწონს ეს. მე მივიღე ყველა ამ cache ჰიტები აქ და მე მივიღე არაფერი ხდება ქვემოთ აქ იმიტომ, რომ მონაცემთა ბაზაში ზის უკან cache და ნათქვამია არასოდეს დაასრულებს. თუ შევცვალო მონაცემები მონაცემთა ბაზა, რომ მე უნდა კეშის გასაახლებლად. ჩვენ შეგვიძლია გამოვიყენოთ რაღაც ისევე როგორც steams გაგვაჩნია. და მე ახსნას, როგორ მუშაობს. ყველა უფლება შეტყობინებები. ელ-ფოსტის გაგზავნა, ჩვენ ყველა გამოიყენოთ ელ. 

ეს არის საკმაოდ კარგი მაგალითია. ჩვენ მივიღეთ გარკვეული შეტყობინებები მაგიდასთან. და მივიღეთ inbox და outbox. ეს არის ის, რაც SQL გვინდა გამოიყურებოდეს ავაშენოთ, რომ inbox. ჩვენ სახის გამოიყენოთ იგივე სახის სტრატეგიის გამოყენება GSI ის, GSI ს ჩემი inbox და ჩემი outbox. ამიტომ მე მივიღე ნედლეული მესიჯები ჩემი შეტყობინებები მაგიდასთან. და პირველი მიდგომა ამ შეიძლება იყოს, იტყვით, არ არის პრობლემა. მაქვს ნედლეული შეტყობინებები. გზავნილებიც [INAUDIBLE], გაგზავნა ID, რომ დიდი. ეს არის ჩემი უნიკალური hash. მე ვაპირებ, რომ შეიქმნას ორი GSI ის ერთ-ერთი ჩემი inbox, ერთი ჩემი outbox. და პირველი, რასაც მე გავაკეთებ არის მე ვიტყვი, ჩემი hash გასაღები არის იქნება მიმღები და მე ვაპირებ მოწყობა თარიღი. ეს არის ფანტასტიური. მე მივიღე ჩემი ლამაზი ხედი აქ. მაგრამ არსებობს პატარა საკითხია. და თქვენ გადაეყარონ ეს რელაციური მონაცემთა ბაზების, ისევე. მათ მოუწოდეს ვერტიკალურად დაყოფის. თქვენ გსურთ, რომ თქვენი დიდი მონაცემები დაშორებით თქვენი პატარა მონაცემები. 

და კიდევ ერთი მიზეზი არის ის, რომ მე მაქვს წაიკითხავს ელემენტი მისაღებად ატრიბუტები. და თუ ჩემი ორგანოები ყველა აქ, შემდეგ კითხულობს მხოლოდ რამდენიმე ელემენტი თუ ჩემი სხეულის სიგრძე საშუალოდ 256 kilobytes ყოველი, მათემატიკის იღებს საკმაოდ მახინჯი. ასე ვთქვათ, მე მინდა წაიკითხონ დავითის inbox. დავით შემომავალი 50 საკითხი. საშუალო და ზომა არის 256 kilobytes. აი ჩემი კონვერტაციის რაციონი ამისთვის RCU ის ოთხი kilobytes. 

OK, მოდით წავიდეთ ერთად საბოლოოდ თანმიმდევრული განცხადებაში. მე მაინც ჭამა 1600 RCU ს მხოლოდ წაკითხვის დავითის inbox. ოუჩ. OK, ახლა მოდით ვიფიქროთ იმაზე, თუ როგორ app მუშაობს. თუ მე ვარ ელ app და ვეძებ ჩემი inbox, და მე შევხედოთ ორგანოს ყველა გაგზავნა, არა, მე ეძებს რეფერატების. ვეძებ მხოლოდ სათაურებში. მოდით ავაშენოთ მაგიდა სტრუქტურა რომ უფრო ჰგავს, რომ. 

ასე რომ, აქ ინფორმაციის რომ ჩემს სამუშაოს სჭირდება. ეს არის ჩემი inbox GSI. ეს თარიღი, გამგზავნი, სათაური, და შემდეგ გაგზავნა ID, რაც მიუთითებს უკან შეტყობინებები მაგიდა სადაც მე შეუძლია მიიღოს ორგანო. ისე, ეს იქნება ჩანაწერი პირადობის მოწმობა. ისინი აღვნიშნო უკან საქონლის მოწმობების დინამო DB მაგიდასთან. ყოველ ინდექსი ყოველთვის creates-- ყოველთვის საქონელი ID ნაწილი of--, რომ გააჩნია ინდექსი. 

კარგი. აუდიტორია: იგი ეუბნება მას, სადაც ის ინახება? RICK Houlihan: დიახ, იგი ეუბნება , ზუსტად ეს არის ზუსტად ის, რასაც აკეთებს. იგი აცხადებს, რომ აქ არის ჩემი ხელახლა ჩანაწერი. და ეს თქვენ აღვნიშნო, რომ ეს უკან ჩემი ხელახლა ჩანაწერი. ზუსტად. OK, ასე რომ, ახლა ჩემი inbox არის რეალურად ბევრად უფრო მცირეა. ეს ფაქტობრივად მხარს უჭერს სამუშაოს ელ app. ასე რომ, ჩემი inbox, მე დააჭირეთ. მე გასწვრივ და მე დააწკაპუნეთ გაგზავნა, ეს მაშინ, როდესაც მე უნდა წავიდეს ორგანოს, იმიტომ, რომ მე ვაპირებ წასვლა განსხვავებული აზრი. ასე რომ, თუ თქვენ ფიქრობთ MVC ტიპის ფარგლებში, მოდელი კალენდარი კონტროლერი. 

მოდელი შეიცავს მონაცემები, რომ ნახოთ საჭიროებების და კონტროლერი ურთიერთქმედებს. როდესაც მე შეცვლა გადაღების, როდესაც შევცვალო პერსპექტივა, ეს OK დაბრუნდეს სერვერზე და repopulate მოდელი, იმიტომ, რომ ის, რაც მომხმარებელს ელის. როდესაც ისინი შეცვლას, რომ როდესაც ჩვენ შეგვიძლია დავუბრუნდეთ მონაცემთა ბაზაში. ასე რომ, ელ, დააჭირეთ. ვეძებ ორგანო. ორი გზა. ტურიზმი მისაღებად ორგანო. 

წავიკითხე ბევრი ნაკლებად მონაცემები. მე მხოლოდ კითხულობს ორგანოების, რომ დავით სჭირდება, როდესაც მას სჭირდება მათ. და მე არ დაწვა 1600 RCU უბრალოდ უნდა ნახოთ მისი inbox. ასე რომ, ახლა that-- ეს არის გზა რომ LSI ან GSI-- მე ვწუხვარ, GSI, შეიმუშავებს. ჩვენ მივიღეთ ჩვენი hash მიმღები. ჩვენ მივიღეთ სპექტრი გასაღები თარიღი. და ჩვენ მივიღეთ დაგეგმილი ატრიბუტები რომ ჩვენ გვჭირდება მხოლოდ მხარს უჭერს იმ აზრს. 

ჩვენ როტაცია, რომ outbox. Hash on გამომგზავნი. და არსი, ჩვენ გვაქვს ძალიან ლამაზი, სუფთა ხედი. და ეს ძირითადად ჩვენ ამ ლამაზი შეტყობინებები მაგიდა, რომელიც ვრცელდება ლამაზად, რადგან ეს hash მხოლოდ hashed გაგზავნა ID. და ჩვენ გვაქვს ორი ინდექსები, რომ მოძრავი off, რომ მაგიდაზე. ყველა უფლება, ასე იდეა აქ არის არ შენარჩუნება დიდი მონაცემები და ამ პატარა მონაცემები ერთად. გაყოფის ვერტიკალურად, დანაყოფი იმ მაგიდები. ნუ მონაცემების თქვენ არ უნდა. ყველა უფლება, სათამაშო. ჩვენ ყველას გვსურს თამაშები. ყოველ შემთხვევაში, მე მინდა თამაშები მაშინ. ასე რომ, ზოგიერთი რამ, რომ საქმე გვაქვს, როდესაც ჩვენ ფიქრი სათამაშო, არა? Gaming ამ დღეებში, განსაკუთრებით მასალა სათამაშო, ყველაფერი არის აზროვნება. და მე ვაპირებ, რომ როტაცია აქ ცოტა მოშორებით DynamoDB. მე ვაპირებ მოყვანას ზოგიერთი დისკუსია გარშემო რამდენიმე სხვა AWS ტექნოლოგიები. 

მაგრამ იდეა სათამაშო ვფიქრობ შესახებ თვალსაზრისით APIs, APIs, რომლებიც, ზოგადად, HTTP და JSON. ეს არის, თუ როგორ მობილური თამაშები სახის ურთიერთქმედება მათი უკანა მთავრდება. მათ ამის JSON გასაკრავი. ისინი მონაცემებით, და ეს ყველაფერი, ზოგადად, ლამაზი JSON APIs. 

რამ, როგორიცაა მიიღოს მეგობარი, მიიღეთ ბანერის, გაცვლის მონაცემები, მომხმარებლის გენერირებული შინაარსი, დააყენებს up სისტემა, ეს არის სახის რამ ჩვენ ვაპირებთ, რომ გავაკეთოთ. ორობითი აქტივების მონაცემები, ეს მონაცემები შეიძლება არ იჯდეს მონაცემთა ბაზაში. ეს შეიძლება იჯდეს ობიექტის მაღაზია, არა? მაგრამ ბაზაში აპირებს დასრულდება მდე ვეუბნებოდი სისტემა, ვეუბნებოდი განცხადება სად უნდა წავიდეს, რომ მას. და აუცილებლად, multiplayer სერვერები, უკან ბოლომდე ინფრასტრუქტურა, და განკუთვნილია მაღალი ხელმისაწვდომობა და scalability. ასე რომ, ეს ის საკითხებია, რომელიც ჩვენ ყველას გვინდა სათამაშო ინფრასტრუქტურის დღეს. 

მოდით შევხედოთ რა, რომ ჰგავს. რა ძირითადი უკან ბოლოს, ძალიან მარტივია. ჩვენ მივიღეთ სისტემა აქ მრავალი ხელმისაწვდომობა ზონებში. ჩვენ ვისაუბრეთ AZS როგორც being-- ვფიქრობ, მათ, როგორც ცალკე მონაცემები ცენტრებში. მეტი მონაცემების ცენტრი პოსტი AZ, მაგრამ რომ კარგადაა, უბრალოდ ვფიქრობ, რომ მათ ცალკე მონაცემების ცენტრები, რომლებიც გეოგრაფიულად და ბრალი იზოლირებული. 

ჩვენ ვაპირებთ, რომ აქვს ორი EC2 შემთხვევები. ჩვენ ვაპირებთ, რომ ზოგიერთი უკან ბოლომდე სერვერზე. შესაძლოა თუ თქვენ მემკვიდრეობა არქიტექტურა, ჩვენ გამოყენებით, რაც ჩვენ მოვუწოდებთ RDS, რელაციური მონაცემთა ბაზების მომსახურებას. შეიძლება იყოს MSSQL, MySQL, ან რამე მაგდაგვარს. ეს არის გზა ბევრი პროგრამები განკუთვნილია დღეს. 

ისე ჩვენ დაგვჭირდება წასვლა ეს მაშინ, როდესაც ჩვენ მასშტაბის გარეთ. ჩვენ წავიდეთ წინ და S3 bucket იქ. და რომ S3 bucket, ნაცვლად ემსახურება up იმ ობიექტების ჩვენი სერვერები ჩვენ შეგვიძლია ამის გაკეთება. თქვენ დააყენა ყველა თქვენი ორობითი ობიექტების თქვენი სერვერები და თქვენ შეგიძლიათ გამოიყენოთ ის სერვერზე შემთხვევები ემსახურება, რომ მონაცემები up. მაგრამ ეს საკმაოდ ძვირი. 

უკეთესი გზა ამის გაკეთება არის წავიდეთ წინ და დააყენოს იმ ობიექტების S3 bucket. S3 არის ობიექტი საცავებში. ეს აშენდა სპეციალურად ემსახურება up ამ ტიპის რამ. და მოდით იმ კლიენტებს მოითხოვოს პირდაპირ იმ ობიექტის თაიგულების, offload სერვერები. ასე რომ, ჩვენ ვიწყებთ მასშტაბის აქ. 

ახლა მივიღეთ მომხმარებლებს მთელ მსოფლიოში. მე მივიღე მომხმარებლებს. მე უნდა შინაარსის ადგილობრივად ახლოს მდებარეობს ამ წევრებს, არა? მე შეიქმნა S3 bucket როგორც ჩემი წყარო საცავი. და მე წინაშე, რომ CloudFront გავრცელება. 

CloudFront არის CD და შინაარსის მიწოდების ქსელის. ძირითადად ეს იღებს მონაცემებს, რომ თქვენ დააკონკრეტა და ინახავს ბუფერში მთელ ინტერნეტ ასე რომ მომხმარებლებს ყველგან შეიძლება ჰქონდეს ძალიან სწრაფი რეაგირება ისინი ითხოვენ იმ ობიექტების. 

ასე რომ, თქვენ იდეა. თქვენ სახის ოპერაციული ყველა ასპექტები AWS აქ ამ გაკეთდეს. და ბოლოს, ჩვენ გადაყარეთ ავტო სკალირების ჯგუფი. ასე რომ, ჩვენი AC2 შემთხვევები ჩვენი თამაში სერვერები, როგორც ისინი დაიწყოს busier და ხალხმრავალი და ხალხმრავალი, ისინი უბრალოდ დაიძაბება სხვა მაგალითად, დაიძაბება სხვა, მაგალითად, დაიძაბება კიდევ ერთი მაგალითია. ასე რომ, ტექნიკა AWS აქვს, საშუალებას გაძლევთ მითითებული პარამეტრების რომლის გარშემო თქვენი სერვერების გაიზრდება. ასე რომ თქვენ შეგიძლიათ n რაოდენობის სერვერები იქ ნებისმიერ დროს. და თუ თქვენი დატვირთვა მიდის, ისინი ყველაფერს შემცირება, რაოდენობის შემცირება. და თუ დატვირთვის ბრუნდება, ის ყველაფერს იზრდება უკან, elastically. 

ასე რომ, ეს გამოიყურება დიდი. ჩვენ მივიღეთ ბევრი EC2 შემთხვევები. ჩვენ შეგვიძლია დააყენა ქეში თვალწინ მონაცემთა ბაზები, ცდილობენ და დააჩქაროს ბაზაში. შემდეგი ზეწოლის წერტილი როგორც წესი, ხალხს ვხედავ არის, რომ ისინი მასშტაბის თამაში გამოყენებით რელაციური მონაცემთა სისტემა. Jeez, მონაცემთა ბაზა შესრულება არის საშინელი. როგორ უნდა გაუმჯობესდეს, რომ? შევეცადოთ აყენებს cache წინაშე, რომ. 

ისე, ქეში არ მუშაობს იმდენად დიდი, თამაშები, უფლება? თამაშები, წერილობით არის მტკივნეული. თამაშები ძალიან დაწერა მძიმე. Cache არ მუშაობს, როდესაც თქვენ წერენ მძიმე, რადგან თქვენ ყოველთვის მივიღე კეშის გასაახლებლად. თქვენ კეშის გასაახლებლად, ეს შეუსაბამო იყოს ქეშირების. ეს, ფაქტობრივად, მხოლოდ ზედმეტი მუშაობა. 

ასე რომ, სადაც ჩვენ აქ? თქვენ მოხვდით დიდი bottleneck ქვემოთ არსებობს მონაცემთა ბაზაში. და წასასვლელი აშკარად დაყოფა. დაყოფა არ არის ადვილია ამის გაკეთება, როდესაც თქვენ საქმე რელატიური მონაცემთა ბაზა. ერთად რელატიური მონაცემთა ბაზა, თქვენ პასუხისმგებელი, პრაქტიკულად, გასაღები სივრცეში. თქვენ ამბობთ, მომხმარებლებს შორის და M აქ, შორის N და Z წასასვლელად. და თქვენ გადართვის მთელს განცხადება. ასე რომ თქვენ საქმე ამ დანაყოფის მონაცემთა წყარო. თქვენ გაქვთ ოპერაციული შეზღუდვების რომ არ span დანაყოფი. თქვენ მოხვდით ყველა სახის messiness, რომ თქვენ საქმე ქვემოთ იქ ცდილობს გაუმკლავდეთ სკალირების გარეთ და მშენებლობის დიდი ინფრასტრუქტურა. ეს უბრალოდ არ fun. 

აუდიტორია: ასე რომ თქვენ განაცხადა, რომ იზრდება წყარო რაოდენობა სიჩქარის პროცესი? RICK Houlihan გაზრდა? აუდიტორია: წყარო რაოდენობა. RICK Houlihan: Source რაოდენობა? აუდიტორია: საწყისი საინფორმაციო, სადაც ინფორმაცია მოდის? RICK Houlihan: No. რა მე ვამბობ, იზრდება ნომერი დანაყოფები მონაცემების მაღაზია აუმჯობესებს გამტარუნარიანობა. ასე რომ, რა ხდება აქ არის მომხმარებლები მოსვლის EC2 მაგალითად აქ, ასევე, თუ მე უნდა შესახებ ეს არის ის, ა M, მე წასვლა აქ. საწყისი N to p, მე წასვლა აქ. საწყისი P to Z, მე წასვლა აქ. 

აუდიტორია: OK, იმ ასე რომ, ეს არის ყველა ინახება სხვადასხვა კვანძების? 

RICK Houlihan: დიახ. ვფიქრობ, ეს როგორც სხვადასხვა silos მონაცემები. ასე რომ, თქვენ, რომელსაც ამის გაკეთება. თუ თქვენ ცდილობს გააკეთოს ეს, თუ თქვენ ცდილობთ გავაფართოვოთ on რელატიური პლატფორმა, ეს არის, თუ რას აკეთებს. თქვენ აღების მონაცემები და თქვენ ჭრის მას. და თქვენ დაყოფის ის გასწვრივ სხვადასხვა ინსტანციის მონაცემთა ბაზაში. და თქვენ მართვის ყველა, რომ განაცხადის იარუსი. ეს არ არის fun. ასე რომ, რა გვინდა წასვლა? ჩვენ გვინდა წავიდეთ DynamoDB, სრულად მოახერხა, NoSQL მონაცემების მაღაზია, დებულება გამტარუნარიანობა. ჩვენ ვიყენებთ საშუალო ინდექსები. ეს, ძირითადად, HTTP API და მოიცავს დოკუმენტის მხარდაჭერა. ასე რომ თქვენ არ უნდა ფიქრი რაიმე რომ დაყოფის. ჩვენ ამას ყველა თქვენთვის. ასე რომ, ახლა, ნაცვლად, თქვენ უბრალოდ წერენ მაგიდასთან. თუ მაგიდა საჭიროებს დაზუსტებას მფლობელის დანაწევრებული, რომ ხდება კულისებში. თქვენ მთლიანად იზოლირებული რომ როგორც დეველოპერი. ასე რომ, მოდით ვისაუბროთ ზოგიერთი გამოყენების შემთხვევაში რომ ჩვენ გადაეყარონ სათამაშო, საერთო სათამაშო სცენარი, ლიდერების. ასე, რომ თქვენ მოხვდით მომხმარებლები მოდის, BoardNames, რომ ისინი on, ქულების ამ მომხმარებლის მიერ. ჩვენ შეიძლება ჰეშირება წლის UserId, და მაშინ ჩვენ გვაქვს სპექტრი თამაში. ასე რომ, ყოველ შესახებ სურს, რომ ყველა თამაში ის ითამაშა და ყველა მისი დაბრუნება ქულა მთელი თამაში. ასე რომ, მისი პირადი leaderboard. 

ახლა მინდა, რომ წავიდეს და მე მინდა, რომ მივიღო ასე რომ მე ეს პირადი ბანერს. რა მინდა წავიდეს მისაღებად დაბრუნება ანგარიშით მთელი მომხმარებლებს. ასე რომ, როგორ შემიძლია ამის გაკეთება? როდესაც ჩემი რეკორდი hashed on UserId, განმეორებადი თამაში, ასევე მე ვაპირებ წავიდეთ წინ და რესტრუქტურიზაცია, შექმნა GSI, და მე ვაპირებ რესტრუქტურიზაცია, რომ მონაცემები. 

ახლა მე ვაპირებ hash შესახებ BoardName, რომელიც არის თამაში. და მე ვაპირებ მერყეობს ზედა ანგარიში. ახლა მე ის სხვადასხვა თაიგულების. მე იმავე მაგიდასთან, იგივე საქონელი მონაცემები. მაგრამ მე შექმნის bucket, რომელიც იძლევა მე აგრეგაციას დაბრუნება ანგარიში თამაში. 

და შემიძლია შეკითხვის მაგიდა უნდა, რომ ინფორმაცია. ასე რომ, მე მითითებული, რომ მოთხოვნის ნიმუში მდე მხარდაჭერილი იქნება საშუალო ინდექსი. ახლა ისინი შეიძლება დალაგებულია BoardName და დალაგებულია TopScore, დამოკიდებულია. ასე რომ თქვენ ხედავთ, ეს არის სხვადასხვა გამოყენების შემთხვევაში თქვენ სათამაშო. კიდევ ერთი კარგი გამოყენების შემთხვევაში მივიღებთ სათამაშო არის ჯილდო და ვინ მოიგო ჯილდო. და ეს არის დიდი გამოყენების შემთხვევაში სადაც ჩვენ მოვუწოდებთ იშვიათი ინდექსები. Sparse ინდექსები არიან უნარი გენერირება ინდექსი, რომელიც არ არის აუცილებელი შეიცავდეს თითოეული ელემენტის მაგიდაზე. და რატომ არა? იმის გამო, რომ ატრიბუტი, რომელიც მიმდინარეობს ინდექსირებული არ არსებობს ყველა ნივთი. 

ასე რომ, ამ კონკრეტულ გამოყენების შემთხვევაში, მე ვამბობ, იცით რა, მე ვაპირებ შექმნა ატრიბუტი მოუწოდა ჯილდო. და მე ვაპირებ, რათა ყველა შესახებ რომ აქვს ჯილდო, რომ მიეწერა. მომხმარებელი რომ არ აქვს ჯილდო არ ვაპირებ, რომ ატრიბუტი. ასე რომ, როდესაც მე შექმნა ინდექსი, მხოლოდ ის მომხმარებლები რომ ვაპირებთ, რომ დავანახოთ მდე ინდექსი არის პირობა, რომ რეალურად არ მოიგო ჯილდო. ასე რომ, დიდი გზა უნდა შეეძლოს უნდა შეიქმნას გაფილტრული ინდექსები, რომ ძალიან, ძალიან შერჩევითი, რომ არ უნდა ინდექსი მთელი მაგიდა. 

ასე რომ, ჩვენ ვიღებთ დაბალი დროულად აქ. მე ვაპირებ წავიდეთ წინ და გამოტოვოთ გარეთ და გამოტოვოთ ეს საქმე. ვისაუბროთ ცოტა ამაზე 

აუდიტორია: შემიძლია ვთხოვო სწრაფი კითხვა? ერთ-ერთი არის წერენ მძიმე? RICK Houlihan: რა არის? აუდიტორია: დაწერეთ მძიმე. RICK Houlihan: დაწერეთ მძიმე. მაჩვენე. 

აუდიტორია: ან ის არის, რომ რაღაც შეგიძლიათ მხოლოდ ხმა ამ საკითხზე წამში? RICK Houlihan: ჩვენ წავიდეთ ხმის მიცემის შემთხვევაში. ეს არ არის, რომ ცუდი. მიგაჩნიათ თუ არა ბიჭები რამდენიმე წუთში? კარგი. 

ასე რომ, ჩვენ ვსაუბრობთ ხმის მიცემა. ასე რომ რეალურ დროში ხმის მიცემის, ჩვენ გვაქვს მოთხოვნები ხმის მიცემა. მოთხოვნები, რომ ჩვენ არ დავუშვებთ, თითოეულ ადამიანს, ხმის მიცემა მხოლოდ ერთხელ. ჩვენ გვინდა, არავინ შეძლებს შეცვალოს მათი ხმა. ჩვენ გვინდა, რეალურ დროში აგრეგაციას და ანალიტიკა დემოგრაფიული ჩვენ ვაპირებთ, რომ იყოს ნაჩვენებია მომხმარებლებს საიტზე. 

ვფიქრობ, რომ ამ შემთხვევაში. ჩვენ ვმუშაობთ ბევრი რეალობა სატელევიზიო გადაცემებში, სადაც ისინი აკეთებს ეს ზუსტი ტიპის რამ. ასე რომ, შეგიძლიათ წარმოიდგინოთ, რომ სცენარი, ჩვენ მილიონობით თინეიჯერი გოგონების იქ მათი მობილური ტელეფონები და ხმის მიცემისა და კენჭისყრის და ხმას ვინც არიან უნდა იყოს ყველაზე პოპულარულია. ასე რომ, ეს არის რამდენიმე მოთხოვნებს, ჩვენ ამოიწურა. 

ასე რომ, პირველი მიიღოს ამ პრობლემის მოგვარებაში იქნება აშენება ძალიან მარტივი პროგრამა. ასე რომ, მე მივიღე ეს app. მე მაქვს რამდენიმე ამომრჩეველი არსებობს. ისინი, ისინი ხმის მიცემის app. მაქვს გარკვეული ნედლეულის რაოდენობა მაგიდა მე უბრალოდ ნაგავსაყრელი იმ რაოდენობა შევიდა. მე გვექნება გარკვეული საერთო რაოდენობა მაგიდა, რომელიც ყველაფერს გავაკეთებ, ანალიტიკა და დემოგრაფიას, და ჩვენ დააყენა ეს ყველაფერი არსებობს. 

და ეს არის დიდი. ცხოვრება კარგია. ცხოვრება კარგი, სანამ ჩვენ ვხედავთ, რომ იქ ყოველთვის მხოლოდ ერთი ან ორი ადამიანები, რომლებიც პოპულარულია არჩევნებში. არსებობს მხოლოდ ერთი ან ორი რამ რომ ადამიანი ნამდვილად აინტერესებს. და თუ თქვენ კენჭისყრაში მასშტაბის, უეცრად მე იქნება როდესმე ჯოჯოხეთი ორი კანდიდატი, ერთი ან ორი კანდიდატი. ძალიან შეზღუდული რაოდენობის ნივთები ადამიანი უნდა იყოს პოპულარული. 

ეს არ არის კარგი დიზაინი ნიმუში. ეს არის რეალურად ძალიან ცუდი დიზაინის ნიმუში იმიტომ, რომ ეს ქმნის ზუსტად ის, რაც ჩვენ ისაუბრა, რომელიც ცხელი კლავიშები. ცხელი კლავიშები არის რაღაც ჩვენ არ მოგვწონს. 

ასე რომ, ჩვენ დაფიქსირება, რომ? და მართლაც, გზა დაფიქსირება ამ მიერ აღების იმ კანდიდატის თაიგულების და თითოეული კანდიდატის გვაქვს, ჩვენ ვაპირებთ დამატება შემთხვევითი მნიშვნელობა, ის, რომ ჩვენ ვიცით, შემთხვევითი მნიშვნელობა ერთიდან 100, შორის 100 და 1000, შორის ან ერთი და 1000, თუმცა ბევრი შემთხვევითი ღირებულებები გსურთ დამატება გადატანა ბოლომდე, რომ კანდიდატი. 

და რა მე ნამდვილად კეთდება მაშინ? თუ მე გამოყენებით კანდიდატი ID როგორც ვედრო რომ საერთო რაოდენობა, თუ მე დასძინა შემთხვევითი ნომერი ბოლომდე, რომ მე შეიქმნა ახლა 10 თაიგულების, რომელიც ასი თაიგულების, ათასი თაიგულების რომ მე აგრეგაცია რაოდენობა მასშტაბით. 

ასე რომ, მე მილიონობით და მილიონობით, და მილიონობით ჩანაწერები მოდის ამ კანდიდატებს, მე ახლა გავრცელების იმ რაოდენობა მასშტაბით კანდიდატი A_1 მეშვეობით კანდიდატი A_100, რადგან ყოველ ჯერზე ხმა მოდის, მე გამოიმუშავებს შემთხვევითი მნიშვნელობა ერთიდან 100. მე tacking გადატანა ბოლოს კანდიდატი, რომელიც პირის ხმას. მე გადაყრა შევიდა, რომ bucket. 

ახლა უკანა მხარეს, მე ვიცი, რომ მე მივიღე ასი თაიგულების. ასე რომ, როდესაც მე მინდა წავიდეთ წინ და საერთო რაოდენობა, წავიკითხე ყველა იმ თაიგულების. ასე რომ, მე წავიდეთ წინ და დაამატოთ. და მაშინ მე გაფანტულ იკრიბებიან მე მივალ და აცხადებენ, hey, იცით, რა, ამ კანდიდატის გასაღები ფართები ასზე მეტი თაიგულების. მე ვაპირებ, რომ შევიკრიბოთ ყველა ხმას იმ ასი თაიგულების. მე ვაპირებ საერთო მათ და მე ვაპირებ ვთქვა, კანდიდატი, ახლა აქვს სულ ხმების დათვლის x. 

ახლა ორივე ჩაწერის შეკითხვის და წაკითხული შეკითხვაზე ლამაზად ნაწილდება იმიტომ, რომ მე წერა მასშტაბით და მე კითხულობს მასშტაბით ასობით გასაღებები. მე არ ვწერ და კითხულობს მასშტაბით ერთ-ერთი ძირითადი ახლა. ასე რომ, დიდი ნიმუში. 

ეს არის რეალურად ალბათ ერთ ყველაზე მნიშვნელოვანი დიზაინი ნიმუშების მასშტაბის NoSQL. თქვენ ნახავთ, რომ ამ ტიპის დიზაინი ნიმუში ყველა გემოს. MongoDB, DynamoDB, ეს არ საკითხთან დაკავშირებით, ჩვენ ყველაფერი უნდა გავაკეთოთ ეს. იმის გამო, რომ, როდესაც თქვენ საქმე იმ დიდი aggregations, თქვენ უნდა გაერკვნენ გზა გავრცელებული მათ მასშტაბით თაიგულების. ასე რომ, ეს არის გზა, თქვენ, რომ. ყველა უფლება, ასე რომ თქვენ აკეთებთ ახლა არის თქვენ სავაჭრო off წაკითხული ღირებულება ჩაწერის scalability. ღირებულება ჩემი წაკითხული ცოტა უფრო რთული და მე უნდა წავიდეს წაკითხვის ასი თაიგულების ერთის ნაცვლად. მაგრამ მე ვერ წერენ. ჩემი გამტარუნარიანობა, ჩემი ჩაწერის გამტარუნარიანობა არის წარმოუდგენელი. ასე რომ, ეს, როგორც წესი, ძვირფასი ტექნიკა სკალირების DynamoDB, ან NoSQL მონაცემთა ბაზის საქმე. ასე რომ, ჩვენ figured, თუ როგორ გავაფართოვოთ ეს. და ჩვენ გავიგეთ, თუ როგორ უნდა აღმოფხვრას ჩვენი ცხელი კლავიშები. და ეს არის ფანტასტიური. და მივიღეთ ეს ლამაზი სისტემის. და ეს მოგვცა ძალიან სწორი კენჭისყრის იმიტომ რომ ჩვენ გვაქვს ჩანაწერი ხმა de-სულელი. ეს ჩაშენებული DynamoDB. ჩვენ ვისაუბრეთ პირობითი უფლებები. 

როდესაც ამომრჩეველი მოდის, აყენებს კულტურა მაგიდაზე, ისინი ჩადეთ მათი ამომრჩევლის ID, თუ ისინი ცდილობენ ჩადეთ მეორე ხმა, მე ამის პირობითი წერენ. ამბობენ, რომ მხოლოდ წერენ ეს თუ ეს არ არსებობს. ამიტომ, როგორც კი ვხედავ, რომ რომ ხმის მიცემა მოხვდა მაგიდა, არავინ იქნება შეუძლია დააყენოს მათი ხმის მიცემა. და ეს არის ფანტასტიური. და ჩვენ დამატება ჩვენი კანდიდატი მრიცხველები. და ჩვენ ყველაფერს ვაკეთებთ დემოგრაფიული და ყველა რომ. მაგრამ რა მოხდება თუ ჩემი განაცხადის მოდის გამო? ახლა უეცრად რაოდენობა მოდის, და მე არ ვიცი, თუ ისინი მიღების დამუშავებული ჩემი ანალიტიკა და დემოგრაფიული აღარ. და როცა განაცხადის ბრუნდება, თუ როგორ ჯოჯოხეთი არ ვიცი რა რაოდენობა უნდა უკვე დამუშავებული და სად უნდა დაიწყოს? 

ასე რომ, ეს არის რეალური პრობლემა, როდესაც თქვენ დაიწყოს შევხედოთ ამ ტიპის სცენარი. და როგორ უნდა გადაწყვიტოს, რომ? ჩვენ გადაწყვიტოს ეს რაც ჩვენ დარეკეთ DynamoDB ნაკადს. ნაკადს არის დრო უბრძანა და დანაწევრებული ცვლილება შესვლა ყოველი ხელმისაწვდომობის მაგიდა, ყოველ დაწერა ხელმისაწვდომობის მაგიდასთან. ნებისმიერი მონაცემების რომ იწერება ცხრილი გვიჩვენებს up ნაკადი. 

ეს, ძირითადად, 24 საათიანი რიგი. საკითხი მოხვდა ნაკადი, ისინი ცხოვრობენ 24 საათის განმავლობაში. ისინი შეიძლება წავიკითხე რამდენჯერმე. გარანტირებული უნდა გადაეცეს მხოლოდ ერთხელ ნაკადი, შეიძლება წაიკითხონ n რაოდენობის ჯერ. ასე რომ, თუმცა ბევრი პროცესები გსურთ მოიხმარენ, რომ მონაცემები, შეგიძლიათ მოიხმარენ მას. ეს გამოჩნდება ყველა განახლება. ყოველ წერენ მხოლოდ როგორც ჩანს, კიდევ ნაკადი. ასე რომ თქვენ არ უნდა ფიქრი დამუშავებაზე ორჯერ იგივე პროცესი. 

ის მკაცრად გააფრთხილა ერთეულზე. როდესაც ჩვენ ვამბობთ დრო მიღებული და დანაწევრებული, დაინახავთ ერთ დანაყოფი ნაკადი. თქვენ ნახავთ, ნივთები, განახლებები, რათა. ჩვენ არ გარანტიას ნაკადი, რომ თქვენ აპირებს მიიღოს ყველა გარიგების იმისათვის, რომ მთელი საკითხი. 

ასე რომ, მდინარე idempotent. ნუ ყველამ ვიცით, რა idempotent ნიშნავს? Idempotent იმას ნიშნავს, თქვენ შეგიძლიათ ეს გააკეთოთ მეტი და მეტი, და კიდევ. შედეგი იქნება იგივე. 

მდინარე idempotent, მაგრამ ისინი უნდა იყოს ითამაშა ამოსავალი წერტილი, სადაც არ უნდა აირჩიოს, ბოლოს და ბოლოს, თუ ისინი არ გამოიწვევს იმავე ღირებულებებს. 

იგივე MongoDB. MongoDB აქვს მშენებლობა ისინი უწოდებენ oplog. ეს არის ზუსტად იგივე შენება. ბევრი NoSQL მონაცემთა ბაზები გვაქვს ეს შენება. ისინი იყენებენ მას ამის გაკეთება რამ როგორიცაა ტირაჟირებას, რომელიც არის ზუსტად ის, რასაც ჩვენ ვაკეთებთ ნაკადს. აუდიტორია: იქნებ ერეტიკული კითხვა, მაგრამ თქვენ ვისაუბროთ apps აკეთებს წაქცევისათვის სხვ. ხართ ნაკადს გარანტირებულია არასოდეს შესაძლოა დაცემას? RICK Houlihan: ჰო, ნაკადს გარანტირებული არასდროს დაცემას. ჩვენ მოვახერხებთ ინფრასტრუქტურის უკან. ნაკადს ავტომატურად განათავსოს მათი ავტომატური სკალირების ჯგუფი. ჩვენ გავლა პატარა ცოტა იმაზე, თუ რა ხდება. 

მე არ უნდა ვთქვა, რომ ისინი არ გარანტირებულია არასდროს დაცემას. ელემენტები გარანტირებული როგორც ჩანს, ნაკადი. და ნაკადი იქნება ხელმისაწვდომი. ასე რომ, რა მიდის ქვემოთ და ბრუნდება up, რომ ხდება ქვეშ. ეს covers-- ეს OK. ყველა უფლება, ასე რომ თქვენ მიიღოთ სხვადასხვა კალენდარი სახის off ეკრანზე. ხედი ტიპები რომ არიან მნიშვნელოვანია პროგრამისტი, როგორც წესი, რა იყო ეს? მე კიდევ ძველი ხედი. როდესაც განახლება ჰიტები მაგიდა, იგი ყველაფერს დააყენებს ძველი კალენდარი ნაკადი ასე რომ, მონაცემები შეიძლება არქივში, ან იცვლება კონტროლი, ცვლილება იდენტიფიკაცია, ცვლილება მართვა. 

ახალი იმიჯი, რა არის ახლა, მას შემდეგ, განახლება, რომელიც არის სხვა ტიპის კალენდარი შენ შეგიძლია მიიღო. თქვენ შეგიძლიათ ორივე ძველი და ახალი images. იქნებ მე მინდა ორივე. მე მინდა, რომ ის, რაც იყო. მე მინდა, რომ ის, რაც შეიცვალა. 

მაქვს შესაბამისად ტიპი პროცესი, რომელიც ეშვება. ეს უნდა გადაამოწმონ, რომ როდესაც ეს ყველაფერი იცვლება, რომ ისინი გარკვეულ ფარგლებში ან გარკვეულ პარამეტრებს. 

და მაშინ იქნებ მე მხოლოდ უნდა ვიცოდეთ, რა შეიცვალა. მე არ მაინტერესებს რა ნივთი შეიცვალა. მე არ უნდა უნდა იცოდეს რა ანიჭებს შეცვლილი. მე უბრალოდ უნდა იცოდეს, რომ ელემენტი შეეხო. ასე რომ ეს არის ტიპის ნახვა რომ თქვენ მიიღოს off ნაკადი და თქვენ შეგიძლიათ ურთიერთქმედება. 

პროგრამა, რომელიც მოიხმარს ნაკადი, ეს არის ერთგვარი გზა ამ მუშაობს. DynamoDB კლიენტს ვთხოვთ, დააყენებს მონაცემები მაგიდები. ნაკადს განათავსოს, რაც ჩვენ მოვუწოდებთ shards. Shards არიან მასშტაბური დამოუკიდებლად მაგიდასთან. ისინი არ გამოდიან სრულად რომ ტიხრები თქვენი მაგიდასთან. მიზეზი თუ რატომ არის იმიტომ, რომ ისინი გამოდიან მოცულობა, მიმდინარე სიმძლავრე მაგიდასთან. 

ისინი განათავსოს მათი საკუთარი ავტო სკალირების ჯგუფი, და ისინი დაიწყოს დაიძაბება დამოკიდებულია თუ რამდენი წერს მოდის, რამდენი reads-- ნამდვილად ის წერს. არ არსებობს reads-- მაგრამ როგორ ბევრი წერს მოდის. 

და მერე უკან ბოლოს და ბოლოს, ჩვენ გვაქვს ის, რაც ჩვენ მოვუწოდებთ KCL, ან Kinesis კლიენტი ბიბლიოთეკა. Kinesis ნაკადი მონაცემები დამუშავების ტექნოლოგია Amazon. და ნაკადს აგებული, რომ. 

ასე, რომ თქვენ გამოიყენოთ KCL საშუალება განცხადება წაიკითხა ნაკადი. Kinesis კლიენტი ბიბლიოთეკა რეალურად მართავს მუშები თქვენთვის. და მას ასევე აქვს გარკვეული საინტერესო რამ. ეს შექმნის გარკვეული მაგიდები მდე თქვენს DynamoDB Tablespace მწკრივზე რომელიც ნივთები უკვე მუშავდება. ასე რომ, ამ გზით, თუ ის მოდის უკან, თუ ის მოდის დასრულდა და მოდის და იღებს დადგა უკან, მას შეუძლია განსაზღვროს, სად იყო ის დამუშავების ნაკადი. 

ეს ძალიან მნიშვნელოვანია, როდესაც თქვენ ვსაუბრობთ რეპლიკაცია. მე უნდა იცოდეს, რა მონაცემები დამუშავება და რა მონაცემები ჯერ არ არის დამუშავებული. ასე რომ, KCL ბიბლიოთეკა ნაკადს იქნება გაძლევთ ბევრი რომ ფუნქცია. იგი ზრუნავს ყველა მომსახურება. იგი დგას მდე თანამშრომელი ყოველი shard. იგი ქმნის ადმინისტრაციული მაგიდა ყველა shard, ყველა თანამშრომელი. და როგორც იმ მუშების ცეცხლი, მათ შენარჩუნებას იმ მაგიდები ასე რომ თქვენ იცით, რომ ეს ჩანაწერი წაიკითხა და დამუშავება. და შემდეგ ამ გზით, თუ ეს პროცესი კვდება და ბრუნდება ხაზზე მას შეუძლია განაახლებს უფლება, სადაც აფრინდა. 

ასე რომ, ჩვენ გამოიყენოს ეს ჯვარი რეგიონში რეპლიკაცია. ბევრი მომხმარებელს აქვს საჭიროება გადაადგილება მონაცემები ან ნაწილების მათი მონაცემების მაგიდები გარშემო სხვადასხვა რეგიონებში. არსებობს ცხრა რეგიონში მთელი მსოფლიოს გარშემო. ასე რომ, შეიძლება იყოს need-- მე შეიძლება ჰქონდეს მომხმარებლები აზიაში, მომხმარებლები აღმოსავლეთ სანაპიროზე ამერიკის შეერთებული შტატები. მათ აქვთ განსხვავებული მონაცემები, რომ საჭიროებს დაზუსტებას მფლობელის ადგილობრივად ნაწილდება. და იქნებ შესახებ ფრიალებს აზიის, ამერიკის შეერთებული შტატები, და მე მინდა, რომ იმეორებს მისი მონაცემებით, მასთან ერთად. ასე რომ, როდესაც იგი იღებს off თვითმფრინავი, მას აქვს კარგი გამოცდილება გამოყენებით მისი მობილური აპლიკაცია. 

თქვენ შეგიძლიათ გამოიყენოთ ჯვარი რეგიონში რეპლიკაცია ბიბლიოთეკა ამის გაკეთება. ძირითადად გვაქვს გათვალისწინებული ორი ტექნოლოგიები. ერთ-ერთი არის კონსოლის პროგრამა შეგიძლიათ აღუდგეს საკუთარი EC2 მაგალითად. ის მუშაობს სუფთა რეპლიკაცია. და მაშინ ჩვენ მისცა თქვენ ბიბლიოთეკაში. ბიბლიოთეკა შეგიძლიათ გამოიყენოთ აშენება საკუთარი განცხადების საფუძველზე, თუ მინდა ამის გაკეთება გიჟები რამ, რომ მონაცემები ფილტრი, იმეორებს მხოლოდ ნაწილი, როტაცია მონაცემები, გადატანა შევიდა სხვადასხვა მაგიდა, ასე შემდეგ და ასე შემდეგ. ასე რომ, ასეთი რა, რომ ჰგავს. 

DynamoDB ნაკადს შეიძლება იყოს დამუშავებული, რაც ჩვენ მოვუწოდებთ ლამბდა. ჩვენ აღვნიშნეთ, ცოტა შესახებ ღონისძიება ორიენტირებული განაცხადის არქიტექტორები. ლამბდა არის ძირითად კომპონენტს, რომ. ლამბდა არის კოდი, რომელიც ხანძრის მოთხოვნის საპასუხოდ კონკრეტული ღონისძიება. ერთ-ერთი ასეთი ღონისძიებები შეიძლება იყოს ჩანაწერი გამოჩენა ნაკადი. იმ შემთხვევაში, თუ ჩანაწერი, როგორც ჩანს, ნაკადი, ჩვენ მოვუწოდებთ ამ Java ფუნქცია. ისე, ეს არის JavaScript და ლამბდა მხარს უჭერს Node.js, Java, Python, და მალე მხარს დაუჭერს სხვა ენებზეც. და საკმარისია ითქვას, რომ ეს არის წმინდა კოდი. წერა Java, განსაზღვრავს კლასს. თქვენ დააყენებს JAR დაყოფილია ლამბდა. და მაშინ დააკონკრეტა, რომელიც კლასის მოვუწოდებთ საპასუხოდ, რომელიც ღონისძიება. და მერე ლამბდა ინფრასტრუქტურის უკან, რომელიც აწარმოებს, რომ კოდი. 

ეს კოდი შეიძლება დამუშავება ჩანაწერების off ნაკადი. მას შეუძლია გააკეთოს ყველაფერი, რაც სურს მას. ამ კონკრეტულ მაგალითს, ყველა ჩვენ ნამდვილად აკეთებს არის ხე ატრიბუტები. მაგრამ ეს მხოლოდ კოდი. კოდი შეიძლება არაფერი, არა? 

ასე, რომ თქვენ შეგიძლიათ როტაცია, რომ მონაცემები. თქვენ შეგიძლიათ შექმნათ წარმოებული ხედი. თუ ის დოკუმენტის სტრუქტურა, თქვენ შეგიძლიათ flatten სტრუქტურა. თქვენ შეგიძლიათ შექმნათ ალტერნატიული ინდექსები. ყველა სახის რამ შეგიძლიათ გავაკეთოთ ერთად DynamoDB ნაკადს. 

მართლაც, რა, რომ ჰგავს. ასე რომ, თქვენ განახლება მოდის. ისინი მოდის off სიმებიანი. ისინი წაიკითხა ლამბდა ფუნქცია. ისინი მოძრავი მონაცემები და ზრდის ის გადამუშავებულ მაგიდები, ატყობინებს გარე სისტემების ცვლილება, და ზრდის მონაცემები ElastiCache. 

ჩვენ ვისაუბრეთ თუ როგორ უნდა დააყენოს cache თვალწინ მონაცემთა ბაზა, რომ გაყიდვების სცენარი. ისე, რა მოხდება, თუ მე განახლება ნივთი აღწერა? ისე, თუ მქონდა ლამბდა ფუნქცია გაშვებული, რომ მაგიდა, თუ მე განაახლოთ ნივთი აღწერა, იგი ყველაფერს შეარჩიო ჩანაწერი off ნაკადი, და ეს თქვენ განახლება ElastiCache მაგალითად, ახალი მონაცემები. ასე რომ, ბევრი რას ვაკეთებთ ლამბდა. ეს წებო კოდი, კონექტორები. და ეს რეალურად აძლევს უნარი, რათა დაიწყოს და აწარმოებს ძალიან კომპლექსური პროგრამები გარეშე ერთგულ სერვერზე ინფრასტრუქტურა, რომელიც არის მართლაც მაგარი. 

მოდით დავუბრუნდეთ რეალურ დროში ხმის მიცემის არქიტექტურა. ეს არის ახალი და გაუმჯობესებული ჩვენი ნაკადს და KCL ჩართულია განაცხადი. ისევე, როგორც ადრე, ჩვენ შეგვიძლია გაუმკლავდეს ნებისმიერი მასშტაბის არჩევნებში. ჩვენ მოსწონს ეს. ჩვენ ვაკეთებთ out scatter აგროვებს მასშტაბით მრავალი თაიგულების. ჩვენ მივიღეთ ოპტიმისტურად საკეტი მიმდინარეობს. ჩვენ შეგვიძლია შევინარჩუნოთ ჩვენი ამომრჩევლების იცვლება მათი რაოდენობა. მათ შეუძლიათ მხოლოდ ხმას მხოლოდ ერთხელ. ეს არის ფანტასტიური. Real-time ბრალია ტოლერანტობის, scalable აგრეგაციას ახლა. იმ შემთხვევაში, თუ რამ მოდის დასრულდა, იცის, სად უნდა გადატვირთეთ თავად როდესაც ის ბრუნდება, რადგან ჩვენ გამოყენებით KCL app. და მაშინ ჩვენ ასევე შეგიძლიათ გამოიყენოთ, რომ KCL განაცხადის დააყენებს მონაცემებს რომ წითელი წანაცვლების სხვა app ანალიტიკა, ან გამოყენება ელასტიური MapReduce აწარმოებს რეალურ დროში ნაკადი aggregations off რომ მონაცემები. 

ასე რომ, ეს არის ის, რაც ჩვენ არ ისაუბრა ბევრი. მაგრამ ისინი დამატებით ტექნოლოგიების, რომ მოდის ეკისრება, როდესაც თქვენ ეძებს ამ ტიპის სცენარი. 

ყველა უფლება, ისე, რომ ამის შესახებ ანალიტიკა ერთად DynamoDB ნაკადს. თქვენ შეგიძლიათ შეაგროვოთ დე dupe მონაცემები, ყველა სახის ლამაზი ნივთები, საერთო მონაცემები მეხსიერება, შექმნა ის წარმოებული მაგიდები. ეს არის უზარმაზარი გამოყენების შემთხვევაში რომ ბევრი მომხმარებელს ჩართული, აღების წყობილი თვისებები იმ JSON დოკუმენტები და დამატებით ინდექსები. 

ჩვენ ბოლოს. მადლობა ტარების ჩემთან ერთად. ასე რომ, მოდით ვისაუბროთ მითითება არქიტექტურა. DynamoDB ზის შუა ასე ბევრი AWS ინფრასტრუქტურა. ძირითადად, თქვენ შეგიძლიათ Hook ეს მდე არაფერი გსურთ. პროგრამები აშენდა გამოყენებით დინამო მოიცავს ლამბდა, ElastiCache, CloudSearch, დააყენებს მონაცემები შევიდა ელასტიური MapReduce, იმპორტი ექსპორტი DynamoDB შევიდა S3, ყველა სახის workflows. მაგრამ, ალბათ, საუკეთესო რამ გაიგო ამის შესახებ, და ეს არის ის, რაც მართლაც საინტერესო ის არის, როდესაც ჩვენ ვისაუბროთ ღონისძიება ორიენტირებული პროგრამები. 

ეს არის მაგალითი იმისა, შიდა პროექტი რომ ჩვენ გვაქვს, სადაც ჩვენ, ფაქტობრივად, საგამომცემლო შეგროვება კვლევის შედეგები. ასე რომ, ელ ბმული, რომელიც ჩვენ გარეთ, იქ იყოს ცოტა ბმული განაცხადა, click აქ უნდა უპასუხოს კვლევის. ხოლო როდესაც ადამიანს დაწკაპუნებით რომ ბმული, რა ხდება, არის, რომ ისინი გაიყვანოს ქვემოთ უსაფრთხო HTML გამოკითხვის ფორმა S3. არ არსებობს სერვერზე. ეს არის მხოლოდ S3 ობიექტი. 

ეს ფორმა მოდის, იტვირთება up ბრაუზერში. ეს მივიღე ხერხემალი. ეს მივიღე კომპლექსი JavaScript რომ ის გაშვებული. ასე რომ, ეს არის ძალიან მდიდარი განაცხადი გაშვებული კლიენტის ბრაუზერის. მათ არ იციან, რომ ისინი არ არიან ინტერაქციაში უკან ბოლოს სერვერზე. ამ ეტაპზე, ეს ყველაფერი ბრაუზერში. 

მათ შედეგებს, რაც ჩვენ მოვუწოდებთ Amazon API Gateway. API Gateway უბრალოდ ვებ API რომ თქვენ უნდა განსაზღვროს და Hook up რაც გაგიხარდებათ. ამ კონკრეტულ შემთხვევაში, ჩვენ hooked მდე ლამბდა ფუნქცია. 

ასე რომ, ჩემი POST ოპერაცია ხდება არ სერვერზე. ფაქტობრივად, ეს არის API Gateway ზის იქ. ღირს ჩემთვის არაფერია, სანამ ხალხი დაიწყოს გაგზავნის მას, არა? ლამბდა ფუნქცია უბრალოდ ზის იქ. და ღირს ჩემთვის არაფერი, სანამ ხალხი დაიწყებს hitting იგი. ასე რომ თქვენ ხედავთ, როგორც მოცულობა იზრდება, ეს მაშინ, როცა ბრალდებები მოდის. მე არ გაშვებული სერვერზე 7/24. 

ასე რომ, მე გაიყვანოს ფორმა ქვემოთ გარეთ bucket, და მე პოსტი მეშვეობით API კარიბჭე შევიდა ლამბდა ფუნქცია. და მერე ლამბდა ფუნქცია ამბობს, რომ თქვენ იცით, რა, მე მივიღე რამდენიმე PIIs, ზოგიერთი პერსონალურად ამოცნობადი ინფორმაცია ამ რეაგირება. მე მივიღე კომენტარი მოდის მომხმარებლებს. მაქვს ელექტრონული ფოსტის მისამართები. მაქვს სახელები. 

მიადევნე თვალი გაყოფილი ამ off. მე ვაპირებ წარმოქმნის მეტამონაცემების off ამ ჩანაწერში. და მე ვაპირებ დააყენებს მეტადატის შევიდა DynamoDB. და მე ვერ გაშიფრავს ყველა მონაცემები და დააყენებს მას DynamoDB თუ მინდა. მაგრამ ეს უფრო ადვილია ჩემთვის, ამ გამოყენების შემთხვევაში, წავიდეთ და ანგარიში გახდა ვთქვათ, მე ვაპირებ დააყენებს ნედლეული მონაცემები შევიდა დაშიფრული S3 bucket. ასე რომ, მე გამოიყენოთ აგებული S3 სერვერის მხარეს კოდირების და Amazon- ის Key Management სამსახურის, ისე, რომ მე მაქვს გასაღები, რომელიც შეგიძლიათ როტაცია რეგულარულ ინტერვალის, და შემიძლია დაიცვას PII მონაცემები როგორც ნაწილი ამ მთელი workflow. 

ასე რომ, რა ჩავიდინე? მე უბრალოდ განლაგებული მთელი პროგრამა, და მე არ მაქვს სერვერზე. ასე რომ, რა ღონისძიება ორიენტირებული პროგრამა არქიტექტურა აკეთებს. 

ახლა, თუ ფიქრობთ გამოყენების შემთხვევაში ამას ჩვენ სხვა მომხმარებელს ვსაუბრობ დაახლოებით ამ ზუსტი არქიტექტურის, რომელიც აწარმოებს ფენომენალურად დიდი კამპანია, რომელიც ეძებს და აპირებს, oh my. იმის გამო, რომ ახლა მათ შეუძლიათ ძირითადად დააყენებს მას იქ, ნება, რომ კამპანია უბრალოდ იჯდეს იქ, სანამ ის იწყებს, და არა არ უნდა ფიქრი, ლეღვის შესახებ როგორი ინფრასტრუქტურა იქნება იქ მას მხარს დაუჭერს. და მაშინ, როგორც კი ამ კამპანიის კეთდება, ეს იგივეა, რომ ინფრასტრუქტურა უბრალოდ დაუყოვნებლივ მიდის იმიტომ, რომ იქ ნამდვილად არ არის ინფრასტრუქტურა. ეს უბრალოდ კოდი, რომელიც ზის ლამბდა. ეს მხოლოდ მონაცემების, რომელიც ზის DynamoDB. ეს არის საოცარი გზა აშენება პროგრამები. 

აუდიტორია: ასე რომ მეტი ეფემერული, ვიდრე ეს იქნებოდა თუ იგი ინახება ფაქტობრივი სერვერზე? 

RICK Houlihan: აბსოლუტურად. იმის გამო, რომ სერვერზე მაგალითად უნდა იყოს 7/24. ეს უნდა იყოს ხელმისაწვდომი ვინმეს უნდა უპასუხოს. ისე რა? S3 არის შესაძლებელი 7/24. S3 ყოველთვის პასუხობს. და S3 არის ძალიან, ძალიან კარგი ემსახურება up ობიექტები. იმ ობიექტების შეიძლება იყოს HTML ფაილი, ან JavaScript ფაილი, ან რაც გაგიხარდებათ. თქვენ შეგიძლიათ აწარმოებს ძალიან მდიდარი ვებ განაცხადების გარეთ S3 თაიგულების და ხალხი. 

და ისე, რომ იდეა აქ არის მიიღოს დაშორებით გზა ჩვენ გამოიყენება ვფიქრობ ამაზე. ჩვენ ყველა გამოყენებული ვფიქრობ, პირობები სერვერები და მასპინძლებს. ეს არ არის, რომ მთელი მსოფლიოს მასშტაბით. ეს დაახლოებით ინფრასტრუქტურის რადგან კოდი. განათავსოს კოდი ღრუბელი და მიადევნე ღრუბელი აწარმოებს იგი თქვენთვის. და ეს რა AWS ცდილობს. 

აუდიტორია: ასე რომ თქვენი ოქროს ყუთი შუა საქართველოს API Gateway არ არის სერვერზე მსგავსი, მაგრამ ნაცვლად just-- 

RICK Houlihan: შეგიძლიათ წარმოიდგინოთ ეს, როგორც სერვერზე ფასადი. ყველა ის არის, რომ ყველაფერს მიიღოს HTTP მოითხოვოს და MAP- ის სხვა პროცესი. რომ ყველა ის აკეთებს. და ამ შემთხვევაში, ჩვენ ვგეგმავდით მას ლამბდა ფუნქცია. ყველა უფლება, ასე რომ ყველა მე მივიღე. დიდი მადლობა. ვაფასებ. მე ვიცი, რომ ჩვენ გვინდა, ცოტა მეტი დრო. და იმედია თქვენ ბიჭები ცოტა ინფორმაცია რომ თქვენ შეიძლება წართმევას დღეს. და მე ბოდიშს თუ მივედი მეტი ზოგიერთი თქვენი ხელმძღვანელები, მაგრამ არსებობს კარგი ბევრი ძირითადი ფუნდამენტური ცოდნა რომ მე ვფიქრობ, ძალიან მნიშვნელოვანია თქვენთვის. ასე რომ მადლობა გადაგიხადოთ იმისთვის, რომ ჩემთვის. [ტაში] აუდიტორია: [INAUDIBLE] არის, როდესაც თქვენ ამბობდნენ, თქვენ უნდა გაიაროს, რაც თავიდან ბოლომდე რომ მიიღოთ სწორი ღირებულებები ან იგივე ღირებულებები, როგორ მოხდება ღირებულებების შეიცვალოს, თუ [INAUDIBLE]. 

RICK Houlihan: Oh, idempotent? როგორ ღირებულებების ცვლილება? კარგად, იმიტომ, რომ თუ მე არ აწარმოებს მას ყველა გზა ბოლომდე, მაშინ მე არ ვიცი, რა იცვლება გაკეთდა ბოლო mile. ეს არ იქნება იგივე მონაცემები, რაც ვნახე. აუდიტორია: Oh, ასე რომ თქვენ მხოლოდ არ მიღებული მთელი შეყვანა. RICK Houlihan: მარჯვენა. თქვენ უნდა გაიაროს თავიდან ბოლოს, და შემდეგ ეს იქნება თანმიმდევრული სახელმწიფო. ზემოთ. 

აუდიტორია: ასე რომ თქვენ დაგვანახა, DynamoDB შეგიძლიათ გააკეთოთ დოკუმენტი ან გასაღები ღირებულება. ჩვენ გაატარა ბევრი დრო, რომ ძირითადი ღირებულება ერთად hash და გზები Flip ეს გარშემო. როცა შევხედე იმ მაგიდები, არის ის, რომ რის გამოც უკან დოკუმენტის მიდგომა? 

RICK Houlihan: მე არ ამბობენ, რის გამოც მას უკან. 

აუდიტორია: მათ გამოეყო the-- 

RICK Houlihan: დოკუმენტით მიდგომა, დოკუმენტის ტიპის DynamoDB უბრალოდ ვფიქრობ, როგორც სხვა ატრიბუტი. ეს ატრიბუტი, რომელიც შეიცავს იერარქიული მონაცემთა სტრუქტურას. ხოლო შემდეგ ეჭვი, თქვენ შეგიძლიათ გამოიყენოთ თვისებები იმ ობიექტების გამოყენებით Object ნოტაცია. ასე რომ, შემიძლია ფილტრი წლის წყობილი ქონების JSON დოკუმენტი. აუდიტორია: ასე რომ ნებისმიერ დროს ამის დოკუმენტი მიდგომა, შემიძლია ერთგვარი მივიდეს tabular-- აუდიტორია: რა თქმა უნდა. აუდიტორია: --indexes და რამ, რაც მხოლოდ ისაუბრა. RICK Houlihan: ჰო, ინდექსები და ყველა რომ, როდესაც გსურთ ინდექსი თვისებები JSON, ისე, რომ ჩვენ გვინდა უნდა გავაკეთოთ, რომ თუ თქვენ ჩადეთ JSON ობიექტი ან დოკუმენტი შევიდა დინამო, შეგიძლიათ გამოიყენოთ ნაკადს. ნაკადს რომ წავიკითხე შეყვანა. ნეტავ კიდევ რომ JSON წინააღმდეგი და მინდა ვთქვა, OK, რა არის უძრავი ქონება მინდა ინდექსი? 

თქვენ შექმნით წარმოებული მაგიდასთან. ახლა, ისე, როგორც ეს ახლა. ჩვენ არ გაძლევთ საშუალებას ინდექსი პირდაპირ იმ თვისებებს. 

აუდიტორია: Tabularizing თქვენი დოკუმენტები. 

RICK Houlihan: კერძოდ, flattening ის, tabularizing ის, ზუსტად. ეს არის ის, რასაც თქვენ აკეთებთ ეს. 

აუდიტორია: დიდი მადლობა. 

RICK Houlihan: Yep, აბსოლუტურად, მადლობა. აუდიტორია: ასე რომ, ეს სახის Mongo შეხვდა Redis classifers. 

RICK Houlihan: ჰო, ეს არის ბევრი, როგორიცაა, რომ. ეს არის კარგი აღწერილობა იგი. ზემოთ.