[MUZYKI] RICK HOULIHAN: Wszystko w porządku. Cześć wszystkim. Nazywam się Rick Houlihan. Jestem starszy główny Rozwiązania architekt AWS. I skupić się na NoSQL i Technologie DynamoDB. Jestem tu dzisiaj, aby porozmawiać Ci trochę o tym. 

Moja przeszłość jest głównie w warstwie danych. Spędziłem pół mojego rozwoju kariera pisanie bazy danych, dostępu do danych, rozwiązania dla różnych zastosowań. Byłem w Cloud wirtualizacji do około 20 lat. Więc zanim Chmura był Chmura, zwykliśmy nazywać narzędzie obliczeniowe. A pomysł był, to jak PG & E, płacisz za to, czego używasz. Dziś nazywamy to chmura. 

Jednak z biegiem lat, pracowałem przez kilka spółek prawdopodobnie nigdy nie słyszał. Ale mam przygotował listę techniczne osiągnięcia, myślę, że to powiesz. Mam osiem patentów w systemach chmurze wirtualizacji, mikroprocesor projekt, Kompleks przetwarzania zdarzeń, oraz w innych obszarach, jak również. 

Tak więc te dni, skupiam się głównie na NoSQL technologie i następne pokolenie Baza danych. I to na ogół co zamierzam być tutaj z tobą rozmawiać dziś o. Więc czego można oczekiwać z tej sesji, pojedziemy przez skrócie Historia przetwarzania danych. To zawsze pomocny rozumiem, skąd jesteśmy i dlaczego jesteśmy, gdzie jesteśmy. I porozmawiamy trochę nieco o technologii NoSQL z fundamentalnego punktu widzenia. 

Będziemy się do niektórych elementy wewnętrzne DynamoDB. DynamoDB jest AWS bez smaku. To w pełni zarządzany i hostowane rozwiązanie NoSQL. I porozmawiamy trochę o tabeli struktura, API, typy danych, indeksów, a niektóre z wewnętrznych tej technologii DynamoDB. Zajmiemy się część projektu wzory i najlepsze praktyki. Porozmawiamy o tym, jak korzystać z tej technologii dla niektórych dzisiejszych aplikacjach. A potem porozmawiamy trochę o ewolucji lub powstania nowego paradygmatu w programowaniu zwane aplikacje sterowane zdarzeniami i jak DynamoDB odgrywa w tym również. I zostawimy Cię trochę architektura referencyjna dyskusja więc możemy mówić o niektórych sposoby można użyć DynamoDB. 

Więc najpierw off-- jest to pytanie Słyszałem wiele o to, co jest w bazie. Wiele osób myśli, że wiesz co to jest baza danych jest. Jeśli Google, musisz to zobaczyć. Jest to zorganizowanego zestawu danych odbywa w komputerze, zwłaszcza taki, który jest przystosowany na różne sposoby. Przypuszczam, że to dobry Definicja nowoczesnych danych. Ale nie podoba mi się to, bo oznacza to kilka rzeczy. To oznacza strukturę. I oznacza to, że jest na komputerze. I bazy danych nie Zawsze istnieje na komputerach. Bazy danych rzeczywiście istniał na wiele sposobów. 

Więc lepiej definicji Baza danych jest coś takiego. Baza danych jest zorganizowana mechanizm przechowywania, zarządzania, i pobierania informacji. To jest z About.com. Tak mi się to podoba, bo to naprawdę rozmowy o baza danych jest repozytorium, repozytorium informacji, niekoniecznie coś znajduje się na komputerze. I w całej historii, nie zawsze było komputerów. 

Teraz, gdy pytam średnią deweloper dziś, co jest baza danych, to jest odpowiedź uzyskać. Gdzieś mogę trzymać rzeczy. Dobrze? I to prawda. Ale to niefortunne. Ponieważ baza danych jest naprawdę podstawą nowoczesnej aplikacji. Jest to fundacja z każdej aplikacji. I jak budować, że bazy danych, jak zorganizować że dane będzie dyktować, jak to Aplikacja wykonuje, jak skalować. 

Tak dużo mojej dzisiejszej pracy ma do czynienia z tym, co dzieje się, gdy deweloperzy takie podejście i radzenia sobie z następstwami wniosku, że jest teraz skalowania poza oryginalny intencji i cierpienie z powodu złej konstrukcji. Więc mam nadzieję, że kiedy odejść dzisiaj, będziesz mają kilka narzędzi w twój pas, który będzie utrzymywać was od podejmowania tych samych błędów. W porządku. Więc porozmawiajmy o odrobinie oś czasu z technologii baz danych. Myślę, że czytałem Artykuł nie tak dawno temu i powiedział coś na lines-- jest to bardzo poetyckie zestawienie. Mówi się, że historia przetwarzania danych jest pełne wysokich znaków wodnych obfitości danych. OK. Teraz myślę, że to trochę prawda. Ale tak naprawdę patrzeć na to, jak historia jest rzeczywiście pełne z wysokim ciśnieniem znaku wodnego danych. Ponieważ przepływności Spożycie nigdy nie idzie w dół. To idzie w górę tylko. 

I innowacji pojawia się, gdy Widzimy presję danych, które Jest to ilość danych jest teraz czekać do systemu. I nie może być przetwarzany wydajnie zarówno w czasie lub kosztów. I wtedy zaczniemy patrzeć pod ciśnieniem danych. 

Tak więc, gdy spojrzymy na Pierwsza baza danych, w tym to ten, który był między naszymi uszami. Wszyscy rodzimy się z nim. Jest to miły bazy danych. Posiada wysoką dostępność. To zawsze. Zawsze można je dostać. 

Ale jest jeden użytkownik. Nie mogę podzielić się moimi myślami z Tobą. Nie można dostać moje myśli jeśli chcesz je. A ich abilitiy nie jest tak dobry. Zapominamy rzeczy. Co jakiś czas, jeden z nas liście i przenosi na inną istnienia i stracić wszystko że był w tej bazie danych. Więc to nie jest wszystko, co dobre. 

I to działa dobrze w czasie kiedy byliśmy z powrotem w dzień kiedy wszystko tak naprawdę potrzebne, aby wiedzieć, gdzie idziemy, aby przejść na jutro lub gdy zbieramy najlepsze jedzenie. Ale jak zaczęliśmy się rozwijać jako Cywilizacja i rząd rozpoczął aby wejść w życie, oraz firm zaczęło się rozwijać, zaczęliśmy zdawać sobie sprawę, my potrzebujemy trochę więcej niż to, co możemy umieścić w naszej głowie. W porządku? 

Potrzebowaliśmy systemy zapisu. Potrzebowaliśmy miejsca, aby być w stanie przechowywać dane. Zaczęliśmy więc pisanie dokumentów, tworzenie biblioteki i archiwa. Zaczęliśmy rozwijający się System A rachunkowości księgi głównej. I że system liczenia księgi prowadził świat przez wiele wieków, a może nawet tysiące lat, jak my niby wzrosła do tego stopnia, w przypadku, gdy obciążenie danych przekroczyła zdolność tych systemów aby móc go zawierają. 

I to właściwie się stało w 1880 roku. Dobrze? W 1880 roku US Census. To jest naprawdę gdzie zwrotnym wskazują nowoczesnego przetwarzania danych. Jest to punkt, w których ilość danych który był zbierany przez Rząd USA dostał się do punktu gdzie zajęło osiem lat do przetworzenia. 

Teraz, osiem years-- jak wiesz, spisu kursuje co 10 years-- więc jest dość oczywiste, że do czasu dostał 1890 spis ludności, ilość danych miał być przetwarzane przez rząd było będzie przekraczać 10 lat, że to odbędzie się premiera nowej spisu. To był problem. 

Więc facet o imieniu Herman Hollerith przyszedł jednostki i wymyślił rekordowy cios kart, czytnik kart cios, karta cios tabulacji, a sortowanie mechanizmy dla tej technologii. A to, że spółka utworzona na razem, wraz z kilkoma innymi, w rzeczywistości stał się jednym z filarami mała firma wiemy dzisiaj o nazwie IBM. 

Więc początkowo był IBM w firma w bazie. I to jest naprawdę to, co zrobili. Zrobili przetwarzania danych. 

Jak więc rozprzestrzeniania stempla karty, pomysłowe mechanizmy jest w stanie wykorzystać, że Technologia do sondowania posortowanych zestawów wyników. Możesz zobaczyć na tym zdjęciu nie mamy little-- to trochę small-- ale widać bardzo pomysłowy mechanizm mechaniczna gdzie mamy talię kart cios. I przy czyimś mały śrubokręt i trzymać poprzez Gniazda i unosząc ją w górę aby ten mecz, który ustawić posortowane wyniki. 

To jest agregacja. Robimy to cały czas dzisiaj w komputerze gdzie można zrobić to w bazie danych. Kiedyś to zrobić ręcznie, prawda? Ludzie umieścić te rzeczy razem. I to było rozprzestrzenianie tych kart perforowanych do tego, co nazwaliśmy bębnów danych i szpule danych, taśmy papieru. 

Przemysł przetwarzanie danych trwało lekcja z fortepiany graczy. Pianina gracz z powrotem w Przełom XIX i XX wieku używałem zwojów z gniazd na to powiedzieć, które klawisze do odegrania. Tak, że technologia została przystosowana ostatecznie do przechowywania danych cyfrowych ponieważ mogą umieścić te dane na tych bębnach taśmie papierowej. 

Obecnie, w rezultacie, dane został actually-- jak uzyskać dostęp do tych danych był bezpośrednio zależne od tego, jak go przechowywać. Więc jeśli mogę umieścić dane na taśmie, Miałem dostęp do danych liniowo. Musiałem toczyć całość Taśma na dostęp do wszystkich danych. Jeśli mogę umieścić dane w ponczu Karty, mogę do niego dostęp w trochę bardziej losowy moda, może nie tak szybko. 

Ale były ograniczenia w jak dostęp do danych w oparciu o jaki został zapisany. A więc to był problem wchodząc w latach 50-tych. Znowu możemy zacząć, aby zobaczyć, że jak my rozwój nowych technologii do przetwarzania dane, w prawo, otwiera drzwi do nowych rozwiązań, dla nowych programów, nowe aplikacje dla tych danych. I naprawdę, zarządzanie może być powodem Dlatego opracowano niektóre z tych systemów. Ale firma szybko stała kierowca za ewolucją nowoczesnej bazy danych i nowoczesny system plików. 

Więc następną rzeczą, że przyszedł był w latach 50-tych był system plików i rozwój losowej przechowywania dostępu. To było piękne. Teraz, wszystko nagle, możemy umieścić nasze pliki w dowolnym miejscu na tych dyskach twardych i możemy uzyskać dostęp do tych danych w sposób losowy. Możemy analizować że Informacje z plików. A my rozwiązany na świecie problemy z przetwarzaniem danych. 

I to trwało około 20 lub 30 lat, aż do ewolucji z relacyjnej bazy danych, która jest, kiedy świat postanowił teraz trzeba mieć repozytorium, które pokonuje sprawl danych w całym pliku systemy, które zbudowaliśmy. Dobrze? Zbyt dużo danych rozproszonych w zbyt wiele miejscach, deduplikacji danych, a koszt magazynowania był ogromny. 

W latach 70., najdroższe zasób że komputer miał był przechowywania. Procesor był uważana za stałą kosztów. Kiedy kupić pole, CPU wykonuje pracę. Zapowiada się kręci, czy to faktycznie działa, czy nie. To naprawdę zatopiony kosztów. 

Ale to, co kosztowało mnie jako biznes jest składowanie. Jeśli mam kupić więcej dysków następna miesięcznie, to jest realne koszty, które płacę. I że przechowywanie jest kosztowne. 

Teraz musimy szybko do przodu 40 rok a my mamy inny problem. Wylicz jest teraz Najdroższe zasobów. Składowanie jest tanie. To znaczy, można przejść w dowolnym miejscu na chmury i możemy znaleźć taniego miejsca. Ale co, nie mogę znaleźć jest tanie obliczeniowej. 

Więc ewolucji dzisiejszy technologii, technologii baz danych, jest naprawdę koncentruje się wokół rozproszonych baz danych które nie cierpią z powodu tego samego typu skali Ograniczenia relacyjnych baz danych. Porozmawiamy trochę o co to właściwie oznacza. 

Ale jeden z powodów, i kierowca za this-- my mówił o ciśnieniu danych. Ciśnienie dane jest coś który napędza innowacje. A jeśli spojrzeć na ponad ostatnie pięć lat, Jest to wykres jaki dane obciążenia całej ogólnej przedsiębiorstwa Wygląda na to, w ciągu ostatnich pięciu lat. 

A ogólna zasada te days-- jeśli go Google-- 90% danych, które przechowujemy dzisiaj, i to wygenerowany w ciągu ostatnich dwóch lat. OK. Otóż, nie jest to tendencja to nowe. Jest to trend, który był udaniem się na 100 lat. Odkąd Herman Hollerith opracowała kartę dziurkowania, byliśmy budowy repozytoriów danych i gromadzenie danych w fenomenalnym tempie. 

Tak więc w ciągu ostatnich 100 lat, widzieliśmy ten trend. To nie zmieni. W przyszłości mamy zamiar zobaczyć tego, jeśli nie przyspieszonego trendu. I można zobaczyć co to wygląda. 

Jeżeli firma w 2010 roku był jednym terabajt danych w zarządzaniu, dziś to oznacza, że ​​są zarządzanie 6,5 petabajtów danych. To 6500 razy więcej danych. I wiem, że to. Pracuję z tych firm na co dzień. Pięć lat temu, by rozmawiać z firmami kto by ze mną porozmawiać o tym, co ból jest zarządzanie terabajtów danych. A oni mówią mi o tym, jak widzimy, że jest to prawdopodobnie będzie być petabajtów lub dwa w ciągu kilku lat. 

Te same firmy Dzisiaj mam spotkanie z, i mówią mi o Problemem są nie o zarządzanie dziesiątki, 20 petabajtów danych. Więc wybuchu Dane w przemyśle jedzie ogromne potrzebują lepszych rozwiązań. I relacyjna baza danych jest po prostu nie mieszka się do popytu. 

A więc istnieje liniowa Korelacja pomiędzy ciśnieniem danych i innowacje techniczne. Historia pokazało nam to, że w miarę upływu czasu, gdy ilość danych które muszą być przetwarzane przekracza wydajności systemu przetworzyć go w odpowiednim czasie i przy rozsądnych kosztach, to nowe technologie są wymyślone, aby rozwiązać te problemy. Te nowe technologie, z kolei otworzyć drzwi na inny zestaw problemów, które nabiera jeszcze więcej danych. 

Teraz, nie będziemy się powstrzymać. Dobrze? Nie zamierzamy zatrzymać to. Czemu? Ponieważ nie można wiedzieć wszystkiego ma wiedzieć we wszechświecie. I tak długo, jak byliśmy przy życiu, w całej historii człowieka, mamy zawsze napędzane wiedzieć więcej. 

Tak więc wydaje się, że każdy cal ruszamy ścieżką odkryć naukowych, jesteśmy pomnożenie ilości danych że musimy przetwarzać wykładniczo jak odkrywamy coraz więcej i więcej na temat wewnętrznych mechanizmów życia, o tym, jak działa wszechświat, o jazdy odkrycie naukowe, i wynalazku, które robimy dzisiaj. Objętość danych tylko stale wzrasta. Tak jest w stanie poradzić sobie z Ten problem jest ogromny. 

Tak więc jedną z rzeczy, Patrząc, jak, dlaczego NoSQL? Jak NoSQL rozwiązać ten problem? Cóż, relacyjnych baz danych, Structured Query Language, SQL-- to naprawdę konstrukt relacyjna database-- te rzeczy są zoptymalizowany do przechowywania. 

Jeszcze w latach 70-tych, znowu, Dysk jest kosztowne. Ćwiczenie zaopatrzenia przechowywania w przedsiębiorstwie nigdy się nie kończy. Wiem. I żył. Napisałem sterowniki pamięci dla enterprised firma SuperServer jeszcze w latach 90-tych. A wiersz jest rozlewanie innym macierz pamięci masowej po prostu coś, co się na co dzień w przedsiębiorstwie. I nigdy się nie zatrzymał. Wyższa przechowywania gęstość, popyt dla wysokiego składowania gęstości, i bardziej efektywne przechowywanie devices-- to nigdy nie przestał. 

I NoSQL jest doskonałą technologią ponieważ normalizuje danych. To de-duplikuje dane. Stawia dane w strukturze, jest agnostykiem do każdego wzoru dostępu. Wiele aplikacji może trafić, że Baza danych SQL, uruchamiania kwerend ad hoc, i uzyskać dane w formie, że trzeba przetworzyć ich obciążeń. To brzmi fantastycznie. Ale w dolnej linii jest z każdym System, jeśli jest agnostykiem do wszystkiego, jest zoptymalizowany do niczego. OK? 

I to jest to, co się z relacyjna baza danych. Jest zoptymalizowany do przechowywania. To znormalizowane. Jest to relacyjna. Obsługuje zapytań ad hoc. I to i to skaluje pionowo. 

Jeśli trzeba uzyskać większą bazę danych SQL lub bardziej wydajne bazy danych SQL, Idę kupić większy kawałek żelaza. OK? Pracowałem już z wieloma klientami które zostały przez głównych ulepszeń w infrastrukturę SQL tylko aby dowiedzieć się sześć miesięcy później, oni znowu uderza w ścianę. A odpowiedź od Oracle lub MSSQL lub ktokolwiek inny, to dostać większe pole. Cóż, prędzej czy później, nie można kupić większe okno, a to prawdziwy problem. Musimy rzeczywiście coś zmienić. Więc gdzie to działa? To działa również w trybie offline analizy, typu OLAP obciążenia. I to jest naprawdę, gdzie należy SQL. Teraz, jest używany do dziś w wielu Online transakcyjnego przetwarzania typu aplikacje. I to działa dobrze na niektóre poziom wykorzystania, ale to po prostu nie skaluje sposób, że NoSQL robi. I porozmawiamy trochę trochę o tym, dlaczego to jest. 

Teraz NoSQL, z drugiej strony, jest bardziej zoptymalizowany dla obliczeniowych. OK? Nie jest agnostyczne wzór dostępu. Czy to, co nazywamy de znormalizowane Struktura lub strukturze hierarchicznej. Dane w relacyjnej bazie danych jest połączone z wielu tabel do produkcji, że trzeba. Dane z bazy NoSQL przechowywany jest w dokumencie zawiera strukturę hierarchiczną. Wszystkie dane, które normalnie byłoby połączone razem do produkcji tego widoku jest przechowywany w jednym dokumencie. I porozmawiamy trochę o jak to działa w kilka wykresów. 

Ale idea jest taka, że ​​można przechowywać Twoje dane jak tych instancji poglądów. OK? Skalowanie w poziomie. Dobrze? Jeśli trzeba zwiększyć wielkość mojej klastra NoSQL, Nie potrzebuję, aby uzyskać większe pole. Mam kolejne pudło. A ja ci klastra razem i mogę shard tych danych. Porozmawiamy trochę o co sharding jest, aby możliwość skalowania do bazy danych na wielu urządzeniach fizycznych i usunąć bariery, które wymaga mnie do skalowania w pionie. 

Więc to naprawdę zbudowany w Internecie przetwarzania transakcji i skala. Jest duża rozróżnienie tutaj między sprawozdawczości, prawda? Raportowanie, ja nie wiem pytania mam zamiar zapytać. Dobrze? Reporting-- jeśli ktoś z mój dział marketingu chce just-- jak wielu z moich klientów mają tę szczególną cechę, która kupił na tej day-- nie wiem co zapytać się was prosić. Więc muszę być agnostykiem. 

Teraz, w Online aplikacji transakcyjnej, Wiem, jakie pytania pytam. Zbudowałem wniosek o bardzo specyficzny przepływ pracy. OK? Więc jeśli zoptymalizować dane przechowywać na poparcie tego przepływu pracy, to będzie szybciej. I dlatego NoSQL możliwe naprawdę przyspieszyć dostawę z tych rodzajów usług. W porządku. 

Tak więc mamy zamiar dostać się do trochę teorii tutaj. I niektórzy z was, wasze oczy może cofnąć się trochę. Ale postaram się go zatrzymać jak wysoki poziom, jak mogę. Więc jeśli jesteś w projekcie zarządzanie, tam konstrukt zwany trójkąt ograniczeń. OK. Trójkąt ogranicza dyktatowi nie można mieć wszystkiego cały czas. Nie może mieć ciasto i je zjeść. Więc w zarządzaniu projektami, że trójkąt Ograniczenia to możesz mieć tanie, możesz mieć to szybko, lub możesz mieć to dobrze. Wybierz dwa. Ponieważ nie można mieć wszystkie trzy. Dobrze? OK. 

Więc dowiedziałeś się o tym dużo. Jest to potrójne ograniczenie, Trójkąt potrójnego ograniczenia, lub trójkąt żelaza jest oftentimes-- kiedy mówisz do kierowników projektów, oni mówią o tym. Teraz, bazy danych mają własne trójkąt żelaza. I trójkąt żelaza danych jest to, co nazywamy twierdzeniem WPR. OK? 

WPR dyktuje twierdzenie jak bazy danych działają pod bardzo konkretnych warunkach. I będziemy rozmawiać o co to warunek jest. Ale trzy punkty trójkąta, że tak powiem, to C, konsystencja. OK? Tak więc w WPR, spójność oznacza, że ​​wszystkie Klienci, którzy mogą uzyskać dostęp do bazy danych zawsze będzie mieć bardzo spójny widok danych. Nikt nie będzie zobaczyć dwie różne rzeczy. OK? Jeśli widzę, bazy danych, Widzę ten sam widok jako mojego partnera, który widzi tej samej bazy danych. To konsekwencja. 

Dostępność oznacza, że ​​jeżeli baza danych, jeżeli może być osiągnięty, że wszyscy klienci będą zawsze być w stanie czytać i pisać. OK? Więc każdy klient, który można odczytać z bazy danych zawsze będzie w stanie przeczytać Dane danych i pisać. A jeśli tak jest, to jest dostępne systemu. 

I trzeci punkt jest co nazywamy tolerancją partycji. OK? Środki tolerancji podziału że system działa dobrze pomimo fizycznej sieci przegrody pomiędzy węzłami. OK? Więc węzłach klastra nie może się ze sobą, co się dzieje? W porządku. 

Więc relacyjnych baz danych choose-- można wybrać dwa z nich. OK. Więc relacyjne bazy danych wybrać być spójne i dostępne. Jeśli partycja dzieje się między z DataNodes w magazynie danych, baza danych wywala. Dobrze? To po prostu idzie w dół. OK. 

A to dlatego, że mają rośnie z większych polach. Dobrze? Ponieważ nie no-- zwykle, klaster bazy danych, nie ma bardzo wielu z nich które działają w ten sposób. Ale większość baz danych skalować pionowo w jednej obudowie. Ponieważ muszą one być spójne i dostępne. Jeśli partycja miał być wstrzykiwany to trzeba dokonać wyboru. Musisz dokonać wyboru pomiędzy jest spójna i dostępna. 

I to, co zrobić, baz danych NoSQL. W porządku. Tak więc baza danych NoSQL, to jest w dwóch smakach. Mamy have-- dobrze, to jest w wielu smakach, ale chodzi o dwa podstawowe characteristics-- co nazwalibyśmy bazy CP lub spójne i partycja tolerancji system. Ci faceci dokonać wyboru, że gdy węzły tracą kontakt ze sobą, nie będziemy, aby umożliwić ludzie napisać więcej. OK? 

Do czasu, że partycja jest usunięta, dostęp zapisu jest zablokowany. Oznacza to, że nie są one dostępne. Są one spójne. Kiedy widzimy, że Partycja wstrzyknąć sobie, teraz jesteśmy zgodne, bo nie będziemy aby umożliwić zmianę danych na dwóch Boki partycji niezależnie od siebie. Będziemy musieli przywrócić komunikację przed każdą aktualizacją Dane są dozwolone. OK? 

Kolejny smak byłby system AP, lub dostępne i dzieli System tolerancji. Ci faceci nie dbają. Dobrze? Każdy węzeł, który dostaje Napisać, my ją podjąć. Więc jestem replikowania moich danych na wielu węzłach. Węzły te się klient, klient przychodzi w, mówi, mam zamiar napisać kilka danych. Węzeł mówi, nie ma problemu. Węzeł obok niego dostaje write na tej samej płycie, ma zamiar powiedzieć, nie ma problemu. Gdzieś z powrotem na koniec z powrotem, że dane będzie powtórzyć. A potem ktoś będzie sobie sprawę, Oho, to system będzie sobie sprawę, uh-oh, nastąpiła aktualizacja do dwóch stron. Co robimy? A co oni robią to jest robią coś, co pozwala im rozwiązać ten stan danych. I będziemy rozmawiać o że w następnej tabeli. 

Rzecz podkreślić tutaj. A ja nie zamierzam się zbyt wiele do tego, ponieważ dostaje się do głębokiej teorii danych. Ale jest transakcyjny ramy, które przebiega w systemie relacyjnym, że Pozwala mi to bezpiecznie dokonać aktualizacji do wielu jednostek w bazie danych. A wystąpią te aktualizacje wszystkie na raz albo w ogóle nie. I to się nazywa transakcje ACID. OK? 

ACID daje nam niepodzielność, spójność, izolacja i trwałość. OK? Oznacza to, że atomowe, transakcji, wszystkie moje aktualizacje albo zdarzy, albo nie. Spójność oznacza, że Baza danych będzie zawsze być doprowadzone do konsekwentnego Stan po aktualizacji. Nigdy nie opuszczają bazy danych w zły stan po zastosowaniu aktualizacji. OK? 

Tak więc jest to trochę inaczej niż spójności WPR. Spójności WPR oznacza wszystkie moje Klienci zawsze mogą zobaczyć dane. ACID konsystencji oznacza, że ​​po transakcja zrobił, dane jest dobre. Moje relacje są dobre. I nie zamierzam usunąć wiersz nadrzędny i pozostawić kilka dzieci osieroconych w innej tabeli. To nie może się zdarzyć, jeśli jestem konsekwentny w transakcji kwasu. 

Izolacja oznacza, że ​​transakcje zawsze będzie występować jeden po drugim. Wynik końcowy danych będzie taki sam stan jakby tych transakcji które zostały wydane jednocześnie były wykonywane seryjnie. Więc to jest współbieżności Kontrola w bazie danych. Więc w zasadzie, nie mogę zwiększamy sama wartość dwukrotnie z dwoma operacjami. 

Ale jeśli powiem, dodać 1 do tej wartości, i dwie transakcje są w i staram się robić to, jeden jest będzie się tam pierwszy a drugi na będzie się tam po. Więc w końcu dodałem dwa. Widzisz, co mam na myśli? OK. 

Trwałość jest całkiem proste. Gdy transakcja uznaje się, że to tam będzie nawet jeśli system zawiesza się. Gdy ten system odzyskuje, że transakcji, które zostało popełnione faktycznie się tam być. Więc to gwarancje transakcji ACID. To są całkiem ładne gwarancji mieć na bazie ale są w tym kosztów. Dobrze? 

Ponieważ problem z ramy jest Jeśli partycja jest w danej zestaw, muszę podjąć decyzję. Będę musiał pozwolić aktualizacje na jedną lub drugą stronę. A jeśli tak się stanie, to ja już nie będzie mi aby móc utrzymać te cechy. Oni nie będą zgodne. Nie będą one izolowane. To jest, gdy się zepsuje dla relacyjnych baz danych. To jest powód, relacyjna Bazy danych skalować w pionie. 

Z drugiej strony, mają co nazywa technologii BASE. I to są twoje NoSQL Bazy danych. W porządku. Więc mamy CP, bazy danych AP. I to jest to co nazywasz zasadzie dostępne, miękkie państwo, w końcu zgodny. OK? 

Zasadniczo dostępne, ponieważ Partycja są tolerancyjni. Zawsze będą tam, nawet jeśli nie jest partycja sieci między węzłami. Jeśli mogę mówić do węzła, jestem będzie w stanie odczytać dane. OK? Nie zawsze może być w stanie napisać Dane jeśli jestem spójna platforma. Ale będę w stanie odczytać dane. 

Stan miękkie wskazuje że kiedy czytam, że dane, to może być takie samo, jak inne węzły. Jeżeli prawo zostało wydane na węźle gdzieś indziej w klastrze i nie replikowane w poprzek jeszcze klaster, gdy czytam, że dane, że państwo może nie być zgodne. Niemniej jednak, będzie to ostatecznie spójne, co oznacza, że ​​kiedy zapis jest wykonany w systemie to replikacji poprzek węzłów. I w końcu, że państwo zostaną doprowadzone do porządku, i będzie to zgodne państwa. 

Teraz, twierdzenie WPR naprawdę odgrywa tylko w jednym stanie. Ten warunek jest, kiedy to nastąpi. Bo gdy to działa w tryb normalny, nie ma partycji, wszystko jest spójne i dostępne. Tylko martwić o WPR gdy mamy tę strefę. To są rzadkie. Ale w jaki sposób system reaguje, gdy te występują dyktować, jaki rodzaj systemu mamy do czynienia. 

Warto więc spojrzeć na to, co wygląda na to, że w przypadku systemów AP. OK? Systemy AP są w dwóch smakach. Pochodzą one w smaku, który jest Mistrz Mistrz, 100%, zawsze dostępna. I pochodzą one w inny smak, który mówi, wiesz co, będę się martwić o tym partycjonowania rzeczy gdy rzeczywisty podział występuje. W przeciwnym razie nie będzie głównym węzły, który zajmie prawa. OK? 

Jeśli więc coś takiego jak Cassandra. Cassandra będzie mistrzem master, pozwala mi napisać do dowolnego węzła. Więc co się dzieje? Więc mam obiektu w baza danych, która istnieje na dwóch węzłach. Nazwijmy ten obiekt S. Mamy więc stan dla S. Mamy kilka operacji na S, które są w toku. Cassandra pozwala mi Napisać do wielu węzłów. Więc powiedzmy, że mogę dostać Napisać do s do dwóch węzłów. No, co kończy się dzieje nazywamy to wydarzenie partycjonowania. Nie może być fizycznego podziału sieci. Jednak ze względu na projekt układu, to jest faktycznie partycjonowanie zaraz jak mogę dostać zapisu na dwóch węzłach. To nie zmusza mnie do Napisać wszystko przez jednego węzła. Piszę na dwóch węzłach. OK? 

Więc teraz mam dwa stany. OK? Co się stanie to prędzej czy później, nie będzie wydarzeniem replikacji. Nie będzie to, co nazywany odzyskiwania partycji, które gdzie te dwa stany wrócić razem i nie będzie algorytm które pracuje w bazie danych, zdecyduje, co zrobić. OK? Domyślnie Ostatnia zmiana wygrywa w większości systemów AP. Więc jest zwykle domyślny algorytm, co nazywają wywołania zwrotnego Funkcja, coś, zostanie wywołana, gdy warunek ten wykryciu wykonać pewną logikę w celu rozwiązania tego konfliktu. OK? Domyślnym zwrotna i domyślne rozpoznawania nazw w większości baz danych AP jest, wiecie co, datownik wygrywa. To była ostatnia aktualizacja. Mam zamiar umieścić tę aktualizację tam. Może zrzucić ten zapis, że rzucił się w dzienniku odzysku tak, że użytkownik może wrócić później i powiedzieć, hej, nie było kolizji. Co się stało? I rzeczywiście można zrzucić rejestr wszystkie kolizje i cofanie i zobaczyć, co się dzieje. 

Teraz, jako użytkownik, można również obejmują logikę do tego zwrotnego. Więc można zmienić zwrotna operacji. Można powiedzieć, hej, chcę naprawiać te dane. I chcę, aby spróbować połączyć te dwa rekordy. Ale to zależy od Ciebie. Baza danych nie wiem jak zrobić domyślnie. Większość czasu, jedyną rzeczą, baza danych wie, jak zrobić, to powiedzieć, ten był ostatni rekord. To ten, który wygra, i to jest wartość Zamierzam umieścić. Po tym odzyskiwania partycji i replikacja zachodzi, mamy państwo, które Obecnie S premier, który jest stan scalenie wszystkich tych obiektów. Więc ma to systemy AP. Systemy CP nie trzeba się o to martwić. Bo jak tylko partycja jest do gry, po prostu przerwać przyjmowanie pisze. OK? Więc to jest bardzo łatwe do czynienia z konsekwentni jeśli nie akceptują żadnych nowości. To z systemów CP zrobić. W porządku. 

Więc pomówmy trochę Trochę o wzorcach dostępu. Kiedy mówimy o NoSQL, to wszystko o wzór dostępu. Teraz, SQL jest ad hoc, zapytań. Jest to relacyjna sklepu. Nie musimy się martwić o strukturze dostępu. Piszę bardzo złożone zapytania. To idzie i pobiera dane. To właśnie to wygląda jak, normalizacja. 

Zatem w tej konkretnej struktury szukamy w katalogu produktów. Mam różne rodzaje produktów. Mam książki. Mam albumów. Mam filmów. Związek między produktami i jeden z tych książek, albumów, i filmy tabele jest 1: 1. W porządku? Mam identyfikator produktu, i odpowiadający ID do książki, albumu lub filmu. OK? To jest 1: 1 związek poprzek tych tabelach. 

Teraz books-- wszyscy mają właściwości jest korzeń. Nie ma problemu. To wspaniale. Jeden-do-jeden związek, mam wszystko dane muszę opisać tę książkę. Albums-- albumy mają utworów. To jest to, co nazywamy jeden do wielu. Każdy album może mieć wiele utworów. Więc dla każdego toru na album, mógłbym kolejny rekord w tabeli podrzędnej. Więc utworzyć jeden rekord w moim stole albumy. Tworzyć wiele rekordów w tabeli utworów. Jeden-do-wielu. 

Ten związek jest co nazywamy wiele-do-wielu. OK? Widać, że aktorzy mogą być w wielu filmach, wiele filmów. Więc co możemy zrobić, to stawiamy to odwzorowanie Stół między tymi, które po prostu odwzorowuje ID aktora do ID wideo. Teraz mogę utworzyć kwerendę sprzężeń filmy przez aktora wideo do aktorów, i to daje mi piękny listę wszystkie filmy i wszyscy aktorzy którzy byli w tym filmie. 

OK. Więc zaczynamy. Jeden-na-jeden jest na najwyższym poziomie związek; jeden-do-wielu, albumy na torach; wiele-do-wielu. To są na najwyższym poziomie trzech relacje w żadnej bazie danych. Jeśli wiesz, jak te, relacje ze sobą współpracować, wtedy dużo wiedzieć o bazie danych już. Więc NoSQL działa trochę inaczej. Zastanówmy się przez chwilę, co go Wygląda na to, aby udać się na wszystkie moje produkty. 

W relacyjnej sklepie, chcą, aby wszystkie moje produkty w sprawie wykazu wszystkich moich produktów. To bardzo dużo zapytań. Mam zapytanie do wszystkich moich książek. Mam zapytanie z moich albumów. I mam zapytanie do wszystkich moich filmów. I mam to ująć razem z listy i podawać go z powrotem do Aplikacja, która się o nią poproszą. 

Aby uzyskać moje książki, mogę dołączyć Produkty i książek. Aby moje albumy, mam dołączyć Produkty, Albumy, i szlaki. I aby moje filmy, mam dołączyć Produkty do Filmy, Filmy przyłączając się przez aktorów, i wprowadzają w Actors. Więc to trzy pytania. Bardzo złożone zapytania do montujemy jeden zestaw wyników. 

To mniej niż optymalne. To dlatego, gdy mówimy o strukturze danych, który jest zbudowany być agnostykiem do dostępu pattern-- dobrze to świetnie. I można zobaczyć, to jest naprawdę miłe, jak my zorganizowane dane. I wiesz co? Mam tylko jeden rekord dla aktora. 

To jest fajne. Mam deduplikacji wszystkich moich aktorów, i utrzymuje moje skojarzenia w tej tabeli mapowania. Jednak uzyskanie danych się, staje się drogie. Wysyłam CPU całego systemu Przystępując do tych struktur danych wraz aby być w stanie pociągnąć że dane z powrotem. 

Więc jak mam się poruszać, że? W NoSQL to o agregacji, a nie normalizacja. Dlatego chcemy, aby powiedzieć, że chcą wsparcie dla dostępu. Jeśli dla dostępu do do zastosowań Muszę dostać wszystkie moje produkty. Postawmy wszystkie produkty w jednej tabeli. Jeśli mogę umieścić wszystkie produkty w jednej tabeli, Mogę tylko wybrać wszystkie produkty z tej tabeli i mam to wszystko. Cóż, jak to zrobić? Cóż w NoSQL nie ma Struktura w tabeli. Porozmawiamy trochę o jak to działa w Dynamo DB. Ale nie masz to samo atrybuty i te same właściwości w każdym wierszu, w każdej poz, jak ty w tabeli SQL. A co to pozwala mi do zrobienia jest wiele rzeczy, i dał mi dużą swobodę. W tym konkretnym przypadku, mają moje dokumenty produktów. I w tym konkretnym Przykładem wszystko jest dokumentem w tabeli Produkty. A produkt na książki może mieć identyfikator typu, który określa książkę. A aplikacja by przełączyć na ten ID. 

W warstwie aplikacji, zamierzam powiedzieć, och, jaki typ rekordu jest? Och, to rekord książka. Zapisy Zarezerwuj mają te właściwości. Pozwól mi utworzyć obiekt książki. Więc mam zamiar wypełnić Książka obiektu z tej pozycji. Kolejnym punktem przychodzi i mówi, co to za przedmiot? Cóż ta pozycja będzie album. Och, mam zupełnie inna Przetwarzanie, że rutynowe, dlatego, że jest to album. Widzisz, co mam na myśli? 

Tak więc stosowanie tier-- I po prostu wybierz te wszystkie rekordy. Wszyscy zaczynają najbliższych. Mogą one być wszystkie typy. I to jest logika aplikacji który przełącza poprzek tych typów i decyduje, jak je przetwarzać. 

Ponownie więc mamy optymalizację Schemat dla wzorca dostępu. Robimy to poprzez zawaleniem tych tabel. Jesteśmy w zasadzie biorąc te znormalizowane struktury, i budujemy struktury hierarchiczne. Wewnątrz każdego z tych zapisów Idę zobaczyć właściwości tablicy. 

Wewnątrz tego dokumentu Albums Widzę tablice utworów. Utwory te become-- teraz jest w zasadzie ta tabela dziecko, które istnieje tutaj, w tej strukturze. Więc można to zrobić w DynamoDB. Możesz to zrobić w MongoDB. Możesz to zrobić w dowolnej bazy danych NoSQL. Tworzenie tego typu hierarchiczne struktury danych które pozwalają pobierać dane bardzo szybko, bo teraz nie muszą być zgodne. Kiedy wstawić wiersz do torze tabeli lub wiersz do tabeli Albumy Muszę odpowiadać tym schemacie. Muszę mieć atrybut lub tym Obiekt, który definiuje na tym stole. Każdy z nich, kiedy wstawić ten wiersz. To nie jest przypadek, w NoSQL. 

Mogę mieć zupełnie inny właściwości w każdym dokumencie że wstawić do kolekcji. Tak bardzo potężny mechanizm. I to jest naprawdę, jak ci zoptymalizowanie systemu. Bo teraz tego zapytania, zamiast łączącej wszystkie te tabele i realizacji pół tuzina zapytań wycofać dane, czego potrzebuję, Jestem wykonanie jednego zapytania. A ja iteracji całej wyników przedstawionych. to daje wyobrażenie potęgi NoSQL. Mam zamiar trochę przejść bokiem tutaj i porozmawiać trochę o tym. Jest to bardziej rodzaj z obrotu lub technology-- marketing technologii rodzaj dyskusji. Ale ważne jest, aby zrozumieć, bo jeśli spojrzymy na górze tutaj, na tym wykresie, czego szukamy w jest to, co nazywamy Technologia hiper krzywa. A oznacza to, nowych rzeczy wchodzi w grę. Ludzie myślą, że to nic wielkiego. Mam rozwiązać wszystkie moje problemy. 

To może być koniec wszystko, być wszystkim do wszystkiego. I zacząć go używać. A mówią, że tych rzeczy nie działa. To nie w porządku. Stare rzeczy było lepiej. I wrócić do robienia rzeczy takie, jakie były. A potem w końcu iść, wiesz co? Ten materiał nie jest tak źle. Oh, jak to działa. A kiedy oni dowiedzieć się, jak to Prace, zaczynają coraz lepiej. 

A najśmieszniejsze o tym Jest to rodzaj linii do jakiego nazywamy krzywą Przyjęcie technologii. Więc co się dzieje, to mamy niektóre spust technologii sortowania. W przypadku baz to ciśnienie danych. Rozmawialiśmy o wysokich punktów wodnych ciśnienia danych w całym czasie. Kiedy to ciśnienie Dane uderza pewna punkt, to wyzwalacz technologii. 

Robi się zbyt drogie. To trwa zbyt długo, aby przetwarzać dane. Musimy coś lepszego. Otrzymasz innowatorów tam biegają, próbuje dowiedzieć się, co to jest rozwiązanie. Co to za pomysł? 

Co znajduje się obok najlepszych sposób, aby zrobić to? I coś wymyślić. A ludzie z prawdziwego bólu, człowiek na krawędzi krwawienia, oni skakać nad nim, ponieważ potrzebują odpowiedzi. Teraz to, co nieuchronnie happens-- i to się teraz dzieje w NoSQL. Widzę go cały czas. 

Co nieuchronnie dzieje ludzie rozpocząć korzystanie z nowego narzędzia tak samo kiedyś stare narzędzie. I dowiedzieć się go ma tak dobrze nie działa. Nie mogę sobie przypomnieć, kim jestem rozmowy z wcześniejszym dzisiaj. Ale jak to jest, gdy młot pneumatyczny został wynaleziony, ludzie nie kołysz się ich głowy, aby rozbić beton. 

Ale to, co jest dzieje z NoSQL dziś. Jeśli idziesz w większości sklepów, starają się być sklepy NoSQL. Co robią jest oni używają NoSQL, a oni załadowaniem pełne schematu relacyjnego. Bo tak ich projektowania baz danych. I zastanawiasz się, dlaczego nie wykonując bardzo dobrze? Chłopiec, ta sprawa śmierdzi. Musiałem zachować wszystkie moje dołącza in-- to jest jak, nie, nie. Utrzymanie łączy? Czemu łączenia danych? Nie dołączyć dane w NoSQL. Ty agregować go. 

Więc jeśli chcesz tego uniknąć, nauczyć w jaki sposób narzędzie działa, zanim rzeczywiście zacząć go używać. Nie próbuj korzystać z nowych narzędzi, jakie sam sposób wykorzystywane starych narzędzi. Będziesz mieć złe doświadczenia. I za każdym razem że to, o co chodzi. Kiedy zaczynamy zbliża się tu, to dlatego, że ludzie zorientowali się, jak korzystać z narzędzi. 

Zrobili to samo, gdy relacyjne bazy danych zostały wymyślone, i zostali zastąpienie systemów plików. Starali się budować systemy plików z relacyjnymi bazami danych ponieważ to, co ludzie zrozumieli. To nie działa. Więc zrozumienie najlepszych praktyk technologii pracujesz z jest ogromna. Bardzo ważne. 

Tak więc mamy zamiar dostać się do DynamoDB. DynamoDB jest AWS pełni zarządzane platformy NoSQL. Co jest w pełni zarządzane na myśli? Oznacza to, że nie trzeba Naprawdę się o nic martwić. 

Możesz przyjść, powiedzieć nam, potrzebuję tabelę. Musi to dużo możliwości. Naciskasz przycisk, a postanowienie to cała infrastruktura za sceną. Teraz to jest ogromne. 

Bo kiedy mówisz o skalowanie bazy danych, Klastry danych NoSQL w Skala, bieganie petabajtów, działa miliony transakcji na sekundę, te rzeczy nie są małe klastry. Mówimy tysiące przykładów. Zarządzanie tysiące przypadków, nawet wirtualne instancje to prawdziwy wrzód na tyłku. Mam na myśli, myśleć o każdym razem poprawki systemu operacyjnego wychodzi lub nowej wersji bazy danych. Co to znaczy ci operacyjnie? Oznacza to, że masz 1200 serwery, które muszą być aktualizowane. Teraz nawet z automatyzacji, że może zająć dużo czasu. To może spowodować wiele bóle głowy operacyjne, bo mógłbym usług dół. 

Jak zaktualizować te bazy danych, I może zrobić, niebieski, zielony wdrożeń gdzie wdrożenia i aktualizacji połowa mojego węzły, a następnie uaktualnić drugą połowę. Weź te dół. Więc zarządzania infrastrukturą Skala jest niezwykle bolesne. I ten ból AWS się z niego. I baz danych NoSQL możliwe być niezwykle bolesne ze względu na sposób ich skalę. 

Skalowanie w poziomie. Jeśli chcesz uzyskać większy NoSQL bazy danych, można kupić więcej węzłów. Każdy węzeł kupisz jest kolejny ból głowy operacyjne. Więc niech ktoś inny zrobić to za Ciebie. AWS może to zrobić. 

Wspieramy wartości kluczowych dokumentów. Teraz nie byliśmy zbyt wiele w drugiej tabeli. Istnieje wiele różnych smaki NoSQL. Są wszelkiego rodzaju coraz munged razem w tym punkcie. Możesz zajrzeć na DynamoDB i powiedzieć: tak, oboje jesteśmy dokument i wartość klucza zapisać ten punkt. I można argumentować, funkcje jednego nad drugim. Dla mnie dużo to jest naprawdę sześć jednego pół tuzina innych. Każdy z tych technologii jest grzywny technologii i grzywny rozwiązanie. Nie powiedziałbym, MongoDB jest lepsze lub gorzej niż kanapie, następnie Cassandra, następnie Dynamo, lub odwrotnie. Mam na myśli, to są tylko opcje. 

Jest szybki i to spójne w każdej skali. Więc jest to jeden z największych premie Ci z AWS. Z DynamoDB jest możliwość aby uzyskać niską cyfrę ms opóźnienia w każdej skali. To było celem projektu systemu. I mamy klientów, że robią miliony operacji na sekundę. 

Teraz będę przechodzić przez niektóre z tych, przypadków użycia w tym miejscu kilka minut. Zintegrowany control-- dostępu mamy to, co nazywamy Tożsamość Zarządzanie dostępem lub IAM. Przenika każdy system, każda usługa, która AWS oferuje. DynamoDB nie jest wyjątkiem. Możesz kontrolować dostęp do tabel DynamoDB. We wszystkich rachunków twój AWS przez definiowania ról i uprawnień dostępu w infrastrukturze IAM. 

I to jest klucz i integralnym elementem w co nazywamy zdarzeniami programowania. Teraz jest to nowy paradygmat. 

PUBLICZNOŚCI: Jak twoja stopa prawda pozytywy porównaniu fałszywie ujemnych w systemie kontroli dostępu? RICK HOULIHAN: Prawdziwe pozytywy w porównaniu do wyników fałszywie ujemnych? PUBLICZNOŚCI: Wracając co powinien być powrót? W przeciwieństwie do raz na jakiś czas, to nie wrócić, kiedy powinien potwierdzić? 

RICK HOULIHAN: nie mogłem powiedzieć. Jeśli nie ma żadnych uszkodzeń w żaden sposób, że, Nie jestem osoba zapytać że konkretne pytanie. Ale to jest dobre pytanie. Byłbym ciekaw, że ja, rzeczywiście. 

I tak znowu, nowy paradygmat jest programowanie sterowane zdarzeniami. To jest pomysł, że można wdrażanie złożonych aplikacji, które może pracować bardzo, bardzo dużą skalę bez jakiejkolwiek infrastruktury w ogóle. Bez stałego infrastruktury w ogóle. I porozmawiamy trochę o tym, co to znaczy, jak my dostać się na następne kilka wykresów. 

Pierwszą rzeczą, którą zrobimy to będziemy rozmawiać o tabelach. Typy danych API dla Dynamo. I pierwszą rzeczą, będziesz zauważyć, jeśli spojrzeć na to, jeśli jesteś zaznajomiony z dowolnej bazy danych, bazy danych mają naprawdę dwa rodzaje interfejsów API Chciałbym to nazwać. Albo dwa zestawy API. Jednym z nich byłoby API administracyjne. 

Rzeczy, które dbają o Zadania w bazie danych. Konfiguracja silnika przechowywania, tworzenie i dodawanie tabel. stworzenie bazy danych katalogi i instancje. Te things-- w DynamoDB, ty mają bardzo krótki, krótki list. 

Więc w innych bazach danych, można zobaczyć dziesiątki z poleceń administracyjnych Komendy, do konfigurowania te dodatkowe opcje. W DynamoDB nie trzeba tych, ponieważ nie skonfigurować system, co robimy. Więc jedyne, co musisz zrobić, to powiedz mi, co wielkość stołu muszę. Więc masz bardzo ograniczony zestaw poleceń. 

Dostajesz Create Table Update, Tabela, Usuń tabelę i opisać tabela. To są tylko rzeczy, czego potrzebujesz do DynamoDB. Nie trzeba do przechowywania Konfiguracja silnika. I nie trzeba się martwić o replikacji. I nie trzeba się martwić o sharding. 

I nie trzeba się martwić o żadnej z tych rzeczy. Robimy to wszystko dla Ciebie. Więc to jest ogromna ilość napowietrznych że po prostu unieść swój talerz. Następnie mamy operatorów CRUD. CRUD jest coś, co my zadzwonić w bazie danych, która jest Create, Update, Delete operatorów. Są to twój wspólne operacje na bazie danych. Rzeczy takie jak pozycja put się element, aktualizacji elementy, usuwać elementy, kwerendy partii, skanowanie. Jeśli chcesz zeskanować całą tabelę. Wyciągnąć wszystko ze stołu. Jedną z miłych rzeczy DynamoDB Umożliwia skanowanie jest równoległy. Więc rzeczywiście można dać mi znać, jak wiele wątki chcesz uruchomić na tym skanie. I możemy uruchomić te wątki. Możemy kręcić, że skanowanie w wielu wątków więc można skanować całą tabelę miejsca bardzo, bardzo szybko, w DynamoDB. 

Drugi API mamy jest co nazywamy naszym Strumienie API. Nie będziemy mówić za dużo teraz o tym. Mam pewne treści później w talii na ten temat. Ale Strumienie jest naprawdę running-- myśleć o tym, jak czas zamawiać i dziennik zmian partycji. Wszystko, co dzieje się na Tabela pokazuje się na strumień. 

Każdy Napisać do stołu pojawia się w strumieniu. Można przeczytać, że strumień, a możesz robić rzeczy z nim. Porozmawiamy o tym, co rodzaje rzeczy zrobić z rzeczy, takich jak replikacja, indeksy średnich. Wszystkie rodzaje naprawdę fajne rzeczy, które możesz zrobić z tym. 

Typy danych. W DynamoDB, wspieramy zarówno klucz Dokument wartości i typy danych. Z lewej strony ekranu tutaj mamy nasze podstawowe typy. Typy wartości klucza. Są to łańcuchy, cyfry i pliki binarne. 

Więc tylko trzy podstawowe typy. A potem możesz mieć zestawy tych. Jedną z miłych rzeczy o NoSQL jest można zawierać tablice jak właściwości. I z DynamoDB można zawierać tablice podstawowych typów jak właściwości korzenia. 

A jeszcze typy dokumentów. Jak wielu ludzi zna JSON? Wy znane z JSON tak dużo? Jest to w zasadzie JavaScript, Obiekt, Notation. Pozwala na zasadzie określenie hierarchicznej struktury. 

Możesz zapisać dokument JSON na DynamoDB za pomocą wspólnych elementów lub cegiełki, które są dostępne w większości języków programowania. Więc jeśli masz Javy, jesteś patrząc na mapy i list. Mogę tworzyć obiekty, które obszarze mapy. Mapa jako kluczowych wartości przechowywane jako właściwości. A może to mieć listy Wartości w tych właściwości. Możesz zapisać ten kompleks hierarchiczna struktura jako jednego atrybutu z pozycji DynamoDB. 

Więc tabel w DynamoDB, jak większość Baz danych NoSQL, tabele mają elementy. W MongoDB byś zadzwoń do tych dokumentów. I byłoby podstawą kanapa. Ponadto baza danych dokumentów. Dzwonisz do tych dokumentów. Dokumenty lub przedmioty posiadają atrybuty. Atrybuty mogą istnieć lub nie istnieje na tej pozycji. W DynamoDB, nie jeden obowiązkowy atrybut. Podobnie jak w relacyjnej bazie danych, masz klucza podstawowego w tabeli. 

DynamoDB ma co nazywamy klawisza skrótu. Klawisz skrótu musi być unikalny. Kiedy więc zdefiniować tabeli mieszania, w zasadzie to, co mówię jest każdy przedmiot będzie miał klawisz krzyżyka. I każdy klawisz krzyżyka musi być unikalny. 

Każdy element jest zdefiniowany przez tego unikalnego klucza hash. I nie może być tylko jeden. To jest OK, ale często czego ludzie potrzebują jest to, że chcą to hash Kluczem do zrobić trochę więcej niż tylko być unikalny identyfikator. Często chcemy użyć tego klawisza skrótu jak najwyższym poziomie agregacji wiadra. A sposób, w jaki to, że jest dodając to, co nazywamy klucz zasięgu. 

Więc jeśli to tylko hash Stół musi to być unikalny. Jeśli jest to skrót i zakres tabeli w Połączenie mieszania i zakresie musi być unikalny. Więc pomyśl o tym w ten sposób. Jeśli mam forum. A forma ma tematów, ma stanowisk i ma odpowiedzi. 

Więc może mam hash Klucz, który jest tematem ID. A może mam klucza zasięgu, która jest identyfikatorem odpowiedzi. W ten sposób, jeśli chcę uzyskać wszystkie odpowiedzi na dany temat, Mogę tylko zapytać hash. Mogę tylko powiedzieć, daj mi wszystko elementy, które mają ten skrót. I mam zamiar dostać się na każde pytanie lub pisać na tym konkretnym temacie. Te najlepsze skupiska poziomu są bardzo ważne. Wspierają one podstawowy dostęp Wzór zastosowania. Ogólnie mówiąc, jest to, co chcemy zrobić. Chcemy tego table-- jak załadować do stołu, chcemy uporządkować dane w tabeli, w taki sposób, że wniosek może bardzo szybko odzyskać te wyniki. I często sposobem na to jest utrzymać te skupiska jak my wstawić dane. Zasadniczo jesteśmy rozprzestrzeniania się danych w jasnym wiadra, jak to jest w. 

Zakres pozwalają me-- klawisze skrótu Klawisze mają być równość. Kiedy zapytać hash, muszę powiedzieć, daj mi hash, że równa się to. Kiedy zapytać zakres, ja Można powiedzieć, dać mi wybór że stosuje jakiegokolwiek bogate operatora, że ​​popieramy. Daj mi wszystkie rzeczy na hash. Jest równa, większa niż mniej niż, to początek, to istnieje między tymi dwoma wartościami? Więc te typy zapytań zasięgu że zawsze jesteśmy zainteresowani. Teraz jedną rzeczą danych, gdy spojrzeć na dostęp do danych, gdy można uzyskać dostęp do danych, to Zawsze o agregacji. Zawsze chodzi o rekordy które są z tym związane. Daj mi wszystko tutaj that's-- wszystkie transakcje na tej karcie kredytowej w poprzednim miesiącu. To agregacja. 

Prawie wszystko, co robisz w Baza danych jest jakiś agregacji. Tak, że mogą być w stanie określić te wiadra i daje te zakres atrybutów, aby móc zapytania o, Zapytania te bogate wsparcie wielu, wiele, wiele wzorów dostępu aplikacji. 

Więc z drugiej rzeczy klawisz skrótu Czy to daje nam mechanizm być w stanie rozprzestrzeniać się dane się. Baz danych NoSQL najlepiej gdy dane są równomiernie rozłożone klastra. Jak wielu ludzi zna z mieszania algorytmów? Kiedy mówię, że hash i hashing-- ze względu na algorytm mieszający Jest to sposób jest w stanie generować losową wartość z danej wartości. Zatem w tym szczególnym przypadku, Algorytm mieszania prowadzimy jest ND 5 opiera. 

A jeśli mam identyfikator, a to jest mój klawisz krzyżyka, mam 1, 2, 3. Kiedy uruchomić algorytm mieszania, to będzie wrócić i powiedzieć, oraz 1 równa 7B, 2 wynosi 48, 3 równa CD. Są one rozsiane po całej przestrzeni kluczy. I dlaczego to robisz? Bo to daje pewność, że mogę umieścić zapisy na wielu węzłach. 

Jeśli to robię przyrostowo, 1, 2, 3. I mam szereg hash, że przebiega w tym konkretnym przypadku, mała przestrzeń mieszania, biegnie od 00 do FF następnie zapisy zamiar przyjść i że będziemy jechać 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. Co się dzieje? Każda wkładka ma ten sam węzeł. Widzisz, co mam na myśli? 

Bo kiedy podzielić przestrzeń, i szerzyć te rekordy całej, i partycja ja, ja powiem Partycja 1 ma kluczową miejsca 0 do 54. Partycja 2 jest 55 do 89. Partycja 3 AA do FF. Więc jeśli używam liniowo zwiększany Identyfikatory można zobaczyć co się dzieje. 1, 2, 3, 4, 5, 6, wszystkie aż do 54. Tak jak ja młotkiem Zapisy do systemu, Wszystko kończy się dzieje do jednego węzła. 

To niedobrze. To antipattern. W MongoDB mają ten problem jeśli nie używać klawisza skrótu. MongoDB daje możliwość od mieszania wartość klucza. Zawsze należy zrobić, jeśli używasz wzrastających hash Kluczem w MongoDB, lub będziesz przybijając każdy zapis do jednego węzła, i będzie ograniczenie Twoja wydajność zapisu źle. 

PUBLICZNOŚCI: Czy to A9 169 w po przecinku? 

RICK HOULIHAN: Tak, to jest gdzieś tam. A9, nie wiem. Trzeba, aby mój plik binarny do kalkulatora po przecinku. Mój mózg nie działa w ten sposób. PUBLICZNOŚCI: Tylko szybki jeden waszych komentarzy Mongo. Więc jest identyfikator obiektu, który pochodzi natywnie z Mongo zrobić? RICK HOULIHAN: Czy to zrobić? Jeśli podasz go. Z MongoDB, masz możliwość. Możesz specify-- każdy dokument MongoDB musi mieć identyfikator podkreślenia. To wyjątkowa wartość. 

W MongoDB można określić czy do mieszania lub nie. Oni po prostu daje możliwość. Jeśli wiesz, że jest to losowo, nie ma problemu. Nie musisz tego robić. Jeśli wiesz, że to nie jest przypadkowe, że to jest zwiększany, a następnie zrobić hash. 

Teraz rzeczą mieszania, po hash value-- i to jest dlaczego klawisze skrótu są zawsze unikalnych zapytań, ponieważ zmieniłem wartość, teraz nie mogę zrobić kwerendę zasięgu. Nie mogę powiedzieć, czy to od tego czy tamtego, ponieważ wartość skrótu nie będzie za równoważne z wartością rzeczywistą. Więc kiedy hash, że klucz, to tylko równość. To dlatego w DynamoDB klawisza skrótu Zapytania są zawsze tylko równość. 

Teraz w zakresie key-- kiedy dodać ten klucz zasięgu, Kluczowe zapisy te są w zasięgu wszystkich i one przechowywane na tej samej partycji. Tak więc są one bardzo szybko, łatwo odzyskane, ponieważ jest to skrót, Jest to zakres. I widzisz wszystko z tym samym hash zostanie zapisane na tej samej przestrzeni partycji. Możesz użyć tego klucza zakres pomóc zlokalizować swoje dane blisko rodzica. Więc co ja naprawdę tu robisz? Jest to jeden do wielu związku. Zależność pomiędzy klawisza skrótu oraz kluczowy zakres jest jeden do wielu. Mogę mieć kilka klawiszy skrótu. Mogę mieć tylko wielokrotny wybór Klawisze w każdym krzyżyka. 

Hash określa rodzica, zakres określa dzieci. Więc widać, nie ma tu analogowe pomiędzy relacyjną konstruktem i te same typy konstruuje się w NoSQL. Ludzie mówią o NoSQL jak nierelacyjne. To nie nierelacyjne. Dane zawsze ma relacji. Relacje te właśnie wzorowane są inaczej. Porozmawiajmy trochę Trochę o trwałości. Kiedy piszesz do DynamoDB, pisze są zawsze trójdrożny replikowane. Co oznacza, że ​​mamy trzy AZ. AZ są Dostępność Strefy. Możesz myśleć o dostępność Strefa w centrum danych lub zbiór danych ośrodkach. Te rzeczy są geograficznie od siebie odizolowane w różnych strefach błędów, przez różne sieci energetyczne i obszarów zalewowych. Awaria w jednej AZ nie jest zajmie się inna. Są one również połączone wraz z ciemnych włókien światłowodowych. Obsługuje jeden sub 1 milisekund opóźnienia pomiędzy AZS. Więc replikacji danych w czasie rzeczywistym w stanie w wielu AZS. 

Wdrożenia i często Multi AZ spełniają wysokie wymagania dostępności większości organizacji przedsiębiorstw. Więc DynamoDB rozprzestrzenia w trzech AZS domyślnie. Jedziemy tylko wiedzy zapisu kiedy dwóch z tych trzech węzłów wrócić i powiedzieć: Tak, rozumiem. Dlaczego? Ponieważ na stronie odczytu jesteśmy tylko będzie Ci dane z powrotem, gdy mamy go z dwoma węzłami. 

Jeśli mam replikacji całej trzy, i czytam od dwóch, Ja zawsze gwarantowane aby co najmniej jeden Spośród tych odczytuje się za Najbardziej aktualna kopia danych. To sprawia, że ​​DynamoDB spójne. Teraz możesz wybrać, aby włączyć te zgodne czyta się. W tym przypadku mam zamiar powiedzieć, Będę czytać tylko z jednego węzła. I nie może zagwarantować, że będzie za najbardziej aktualne dane. 

Tak więc, jeśli zapis jest w najbliższych, jeszcze nie replikowane, masz zamiar uzyskać tę kopię. To ostatecznie zgodne odczytu. A co to jest to połowa kosztów. Tak więc jest to coś do myślenia. Kiedy czyta się DynamoDB i jesteś konfigurowania możliwości odczytu jednostki, jeśli zdecydujemy ostatecznie zgodne czyta, to o wiele tańsze, to o połowę kosztów. 

I tak to oszczędność pieniędzy. Ale to twój wybór. Jeśli chcesz poczytać lub spójnego ostatecznie zgodne odczytu. To jest coś, co możesz wybrać. 

Porozmawiajmy o indeksach. Tak więc wspomnieć, że top agregacji poziom. Mamy klawiszy skrótu, a mamy klucze zasięgu. To miłe. I to jest na głównym stole, ja jeszcze jeden klawisz krzyżyka, mam jeden klucz zasięgu. 

Co to znaczy? Mam jedną cechę, że można uruchomić bogate kwerendy. To jest klucz zakres. Pozostałe atrybuty dotyczące tego item-- Może filtrować na tych atrybutów. Ale nie mogę robić takie rzeczy jak, to rozpoczyna się od, albo jest większy niż. 

Jak mogę to zrobić? Utworzyć indeks. Są dwa rodzaje indeksy w DynamoDB. Indeks jest naprawdę inny widok tabeli. A lokalny wskaźnik średniej. 

Pierwszy z nich porozmawiamy. Więc lokalne wtórne są współistniały na tej samej partycji co danych. I jako takie, są one w tym samym węzłem fizycznych. Są to, co nazywamy spójne. Znaczenie, będą one potwierdzić zapisu wraz ze stołem. Gdy przychodzi do zapisu, będziemy pisać przez indeks. Będziemy pisać do stołu, a następnie będziemy potwierdzić. Więc to jest spójne. Gdy zapis został przyznał z tabeli, to gwarantuje, że lokalnego indeksu wtórnego będzie miał taką samą wizji danych. Ale to, co pozwala zrobić to określenie alternatywnych klawiszy zasięgu. 

Muszą używać tego samego skrótu Kluczem w tabeli podstawowej, ponieważ są kolokowane na sama partycja, i są one spójne. Ale mogę utworzyć indeks z różnych kluczy zasięgu. Tak na przykład, gdybym miał producenta że miał stół części surowego najbliższych. I surowców są w części, a są one sumowane przez zespół. A może jest wycofanie. 

Każda część, która została wykonana przez tego Producent po tej dacie, Muszę wyciągnąć z mojej linii. Mogę kręcić indeks które byłyby wygląd, agregowania w dniu producenci z danej części. Więc jeśli mój blat poziom był już zakodowane przez producenta, może to był umieszczony na części ID, I może utworzyć indeks poza tym stole jako zakodowane przez producenta i wahała się od daty produkcji. I w ten sposób mogę powiedzieć, cokolwiek, został wyprodukowany pomiędzy tymi datami, Muszę wyciągnąć z linii. Więc to lokalny wskaźnik średniej. 

Mają one efekt ograniczając przestrzeń klawisz krzyżyka. Ponieważ współistniały w tym samym węźle składowania ograniczają klawisz skrótu Przestrzeń do 10 gigabajtów. DynamoDB, pod tabele, będzie podzielić tabela co 10 gigabajtów. Kiedy można umieścić 10 koncertów danych w, my go [PhH], a dodamy kolejny węzeł. 

Nie będziemy dzielić LSI na wielu partycjach. Będziemy dzielić stół. Ale nie podzieli LSI. Więc to jest coś ważne, aby zrozumieć to jeśli robisz bardzo, bardzo, bardzo duże skupiska, to masz zamiar być ograniczone do 10 gigabajtów na swojej LSI. 

Jeśli tak jest, możemy używać globalnych wtórnymi. Globalne wtórne są naprawdę inna tabela. Istnieją one całkowicie wyłączony z z boku tabeli podstawowej. A oni pozwalają mi znaleźć zupełnie inna konstrukcja. Więc pomyśl o tym, jak dane są wstawiane w dwóch różnych tabel, zorganizowany na dwa różne sposoby. 

Można zdefiniować zupełnie inna klawisz krzyżyka. Można zdefiniować zupełnie Zakres inny klucz. A może to uruchomić całkowicie niezależnie. W rzeczywistości, mam zabezpieczony moje zdolności odczytu i pisać zdolności dla mojego globalne indeksy wtórne zupełnie niezależnie mojej tabeli podstawowej. Gdybym zdefiniowania tego indeksu, mówię to jak dużo czytać i pisać Pojemność to zamiar używać. 

I to jest oddzielna z mojego pierwotnego tabeli. Teraz oba indeksy pozwalają nam zdefiniować nie tylko klawisze skrótu i ​​zasięgu, ale oni pozwalają nam rzutować dodatkowe wartości. Więc jeśli chcę odczytać indeks, i chcę trochę zestaw danych, Nie muszę wrócić do głównego Stół, aby uzyskać dodatkowe atrybuty. Mogę projekcji tych dodatkowych atrybutów w tabeli wspierać wzór dostępu. Wiem, że pewnie się do niektórych Naprawdę, really-- wsiada do chwastów tu, na niektóre z tych rzeczy. Teraz mam dryfować z tego. 

PUBLICZNOŚCI: [niesłyszalne] Kluczem --table oznaczało był hash? Oryginalny hash? Multi-listwy? 

RICK HOULIHAN: Tak. Tak. Kluczem Stół zasadzie wskazuje z powrotem do pozycji. Tak więc indeks jest wskaźnikiem powrotem oryginalne elementy na stole. Teraz możesz zbudować Strona, która ma tylko klucz tabeli, a nie inne właściwości. I dlaczego może to zrobić? No, może mam bardzo dużych przedmiotów. 

I naprawdę tylko trzeba wiedzieć which-- mój wzór dostępu może powiedzieć, elementy, które zawierają tę nieruchomość? Nie trzeba zwrócić przedmiot. Po prostu trzeba wiedzieć elementy, które zawierają go. Więc można budować indeksy że tylko klucz tabeli. 

Ale to przede wszystkim to, co indeks w bazie danych jest. To z możliwości szybkiego określić, które rejestruje, wiersze, które pozycje w tabeli mają właściwości, których szukam. 

GSIS, tak jak one działają? GSIS zasadzie są asynchroniczne. Aktualizacja wchodzi stół Stół jest następnie asynchronicznie zaktualizowane wszystkie swoje GSIS. To dlatego GSIS są ostatecznie spójne. 

Ważne jest, aby zauważyć, że gdy budujesz GSIS, i zrozumieć, że tworzysz inny wymiar aggregation-- Teraz powiedzmy, że dobry przykład tutaj jest producentem. Myślę, że mógłbym mówił o producentem urządzenia medycznego. Producenci urządzeń medycznych często mają części odcinkach. Części, które go do stawu biodrowego wszystkich mieć trochę numer seryjny na nich. A może oni mają miliony, a miliony i miliardy części we wszystkich urządzeniach, że statek. Cóż, muszą agregować pod różne wymiary, wszystkie części w zespole, wszystkie części, które zostały wprowadzone na danej linii, wszystkie części, które weszły z pewnym producenta w określonym terminie. I te skupiska czasem wstać w miliardach. 

Więc pracuję z niektórych ci faceci, którzy cierpią bo tworzysz te GINORMOUS agregacji w ich indeksy średnich. Mogą mieć surowy części Stół, który przychodzi, jak tylko hash. Każda część posiada unikalny numer seryjny. Używam numer seryjny jako hash. Jest piękne. Moja surowe tabela danych jest rozłożona całej przestrzeni kluczy. Mój [? napisać ?] [? Spożycie?] jest niesamowite. Biorę dużo danych. Wtedy to, co robią jest tworzą GSI. A ja mówię, wiesz co, muszę zobaczyć wszystkie części tego producenta. Cóż, tak nagle, że jestem biorąc miliard wierszy, i nadziać je na jeden węzeł, ponieważ kiedy I agregacji jako ID producenta jako hash, oraz numer części jako zakres, następnie wszystkie nagły jestem wprowadzenie miliard części w co Ten producent wydał mi. 

To może spowodować wiele ciśnienia na GSI, znowu, bo jestem młotkiem jeden węzeł. Kładę wszystko wstawia do jednego węzła. I to jest prawdziwa sprawa problematyczna wykorzystanie. Teraz, mam dobry projekt wzór, w jaki sposób uniknąć. I to jest jeden z problemów że zawsze pracować. Ale co się dzieje, jest GSI może nie ma wystarczającej pojemności zapisu aby móc przesunąć tych wszystkich wiersze w jeden węzeł. A co się dzieje, to jest Podstawowym tabela klienta pierwsza tabela będzie zdławiony ponieważ GSI nie może nadążyć. Więc moje stopy wkładka będzie spadnie na tabeli podstawowej jak mój GSI stara się nadążyć. 

W porządku, więc GSi, LSI użytkownika, który z nich wybrać? LSI są zgodne. GSi są ostatecznie zgodne. Jeśli to jest OK, polecam za pomocą GSI, są znacznie bardziej elastyczne. LSI może być modelowana jako GSI. A jeśli rozmiar danych na klawisze skrótu w Twoja kolekcja przekracza 10 GB, wtedy będziesz chciał użyć tego GSI, bo to jest po prostu trudne limitu. 

W porządku, więc skalowanie. Przepustowość w Dynamo DB, można przepis ten może [niesłyszalne] przepustowości w tabeli. Mamy klientów, które mają zabezpieczony 60 billion-- robią 60 mld żądań, regularnie działa na ponad milion wniosków na sekundę na naszych stołach. Naprawdę nie teoretyczna granica ile i jak szybko tabela można uruchomić w Dynamo DB. Istnieją pewne miękkie limity na koncie które wkładamy w nie tak że nie zwariować. Jeśli chcesz więcej niż że nie jest to problemem. Możesz przyjść nam powiedzieć. Będziemy podkręcić pokrętło. 

Każde konto jest ograniczona do pewnego poziomu w każdej usługi, tuż nietoperza więc ludzie nie zwariować dostać się w kłopoty. Brak limitu wielkości. Możesz umieścić dowolną liczbę pozycji na stole. Wielkość elementu jest ograniczona do 400 kilobajtów każdy, to byłby element nie atrybuty. Tak więc suma wszystkich atrybutów jest ograniczona do 400 kilobajtów. I znów mamy że niewiele LSI problem z limitem 10 GB na hash. PUBLICZNOŚCI: Mała liczba, mi brakuje co chcesz mi powiedzieć, że jest-- PUBLICZNOŚCI: Och, 400 kilobajtów Jest to maksymalny rozmiar za sztukę. Tak więc pozycja ma wszystkie atrybuty. Tak 400 k jest całkowitą wielkość z tej pozycji, 400 kilobajtów. Tak więc z wszystkimi atrybutami połączone, wszystkie dane to we wszystkich tych atrybutów, zwinięty w łącznej wielkości obecnie już limit rzecz jest 400 tys. Więc skalowanie ponownie osiągnąć poprzez ścianki działowe. Przepustowość jest zabezpieczony na poziomie stołu. I tam naprawdę dwa pokrętła. Zapoznaliśmy zdolności i pisać zdolności. 

Tak więc są one regulowane niezależnie od siebie. Miarą pilocie jest ściśle zgodne czyta. OK, więc jeśli mówisz, chcę 1000 Pilot na to są ściśle zgodne, te są zgodne czyta. Jeśli mówisz, że chcę Ewentualne zgodne czyta, można zastrzec 1000 Pilot użytkownika, będziesz dostać 2,000 końcu zgodne czyta. I połowę ceny dla tych, docelowo składać się czyta. 

Ponownie, zmienić niezależnie od siebie. I mają throughput-- Jeśli zużywają 100% swojej pilocie, nie idziesz do oddziaływania na dostępność swoich praw. Tak więc są one całkowicie niezależnie od siebie. W porządku, więc jedną z rzeczy, które Wspomniałem krótko został dławienia. Dławienie jest złe. Dławienie wskazuje złe nie SQL. Są rzeczy, które możemy zrobić, aby pomóc można złagodzić dławienie, że cię doświadczamy. Ale najlepszym rozwiązaniem Do tego weźmy Spójrz na to, co robisz, ponieważ jest anty-wzór w grze tutaj. 

Te rzeczy, rzeczy takie jak niejednolite obciążenia, klawisze, gorące ścianki działowe. Jestem uderzenie szczególną przestrzeń kluczy bardzo ciężko z jakiegoś konkretnego powodu. Dlaczego ja to robię? Miejmy tego dowiedzieć. Jestem mieszania moje gorące dane z zimnymi danych. Ja pozwolę moje tabele się ogromny, ale tam naprawdę tylko niektóre podzbiór danych to naprawdę interesujące dla mnie. Tak więc dla danych dziennika, na przykład, dużo Klienci, dostają codziennie dane logowania. Dostali ogromną ilość danych dziennika. 

Jeśli jesteś po prostu cały ten dziennik dumpingu dane w jednym dużym stole, w czasie że tabela będzie się ogromne. Ale jestem bardzo zainteresowany tylko ostatnie 24 godziny, siedem dni ostatnich, ostatnie 30 dni. Niezależnie od okno czasowe że jestem zainteresowany patrząc dla zdarzenia, które mnie nurtuje, lub Wydarzenie to jest dla mnie interesujące, to jedyny czas, okno, że muszę. Więc dlaczego ja wprowadzenie 10 lat Warto danych dziennika w tabeli? Co powoduje, że jest tabela fragment. 

To staje się ogromne. Zaczyna rozkładanie w tysiącach węzłów. I od twoich możliwości jest tak niska, że ​​jesteś właściwie ocenić ograniczenia na każdym jeden z tych pojedynczych węzłów. Zacznijmy więc patrząc na to, jak mamy toczyć tej tabeli powyżej. W jaki sposób zarządzać, że dane trochę lepiej, aby uniknąć tych problemów. A co to ma wyglądać? To co to wygląda. To jest to, co złe NoSQL wygląda. 

Mam również klawisz tutaj. Jeśli spojrzeć na stronie tutaj to są wszystkie moje partycje. Mam 16 partycje tutaj na tej konkretnej bazy danych. Robimy to cały czas. Uruchomić to dla klientów cały czas. To się nazywa mapa ciepła. Mapa cieplna mówi mi, jak jesteś dostępu do klucza miejsca. I co to mówi mi to że nie ma jednego konkretnego hash że ten facet lubi strasznie dużo, bo jest ukryć, że bardzo, bardzo ciężko. 

Więc niebieski jest ładny. Lubimy niebiesko. Nie podoba nam się na czerwono. Czerwień gdzie ciśnienie podnosi się do 100%. 100%, teraz masz zamiar być zdławiony. Więc kiedy widzisz jakieś czerwone linie, takie jak this-- i to nie tylko Dynamo DB-- każda baza danych NoSQL ma ten problem. Są anty-wzorce, które mogą jazdy tego rodzaju warunkach. Co mogę zrobić, to pracować z klientami złagodzić te warunki. 

A co to ma wyglądać? I to jest jak najlepiej z przepustowością Dynamo DB, ale to naprawdę się najbardziej z NoSQL. Nie jest to ograniczone do Dynamo. To definitely-- I wykorzystywane do pracy w Mongo. Znam wielu platformach NoSQL. Każdy z nich ma te typy gorących kluczowych problemów. Aby uzyskać jak najwięcej z każdego NoSQL bazy danych, specjalnie Dynamo DB, chcesz utworzyć tabele gdzie element klawisz krzyżyka ma duża liczba różnych wartościach wysoki stopień liczności. Bo to oznacza, piszę do wielu różnych wiadrach. 

Im więcej wiadra jestem formie pisemnej, tym bardziej prawdopodobne Jestem do rozprzestrzeniania się, że obciążenie zapisu lub czytaj załadować się na wielu węzłach, tym bardziej prawdopodobne Jestem mieć Duża przepustowość na stole. A potem chcę wartości za o dość równomiernie w czasie i równomiernie losowo jak to możliwe. Dobrze, że to rodzaj ciekawe, bo nie mogę kontrola, gdy użytkownicy przychodzą. Więc wystarczy powiedzieć, jeśli rozprzestrzenił rzeczy z całej przestrzeni kluczy, będziemy prawdopodobnie w lepszej formie. 

Jest pewien Kwota czas dostawy że nie będziemy za kontrolę stanie. Ale to są naprawdę dwa wymiary, które posiadamy, Przestrzeń, dostęp równomiernie spread, czas, wnioski planujący przyjazd rozmieszczone równomiernie w czasie. A jeśli te dwa warunki są spełnione, to jest to, co to jest będzie wyglądać. To jest o wiele ładniejsza. Jesteśmy tu naprawdę szczęśliwy. Mamy bardzo nawet wzór dostępu. Tak, może jesteś coraz trochę ciśnienia od czasu do czasu, ale nic naprawdę zbyt rozległe. Więc to niesamowite, jak wiele razy, kiedy pracuję z klientami, że pierwszy wykres z wielkim czerwonym bar i wszystko co brzydkie żółte to w każdym miejscu, możemy zrobienia z wykonywaniem po kilku miesiącach ponownego architektury Uciekają dokładnie to samo Nakład pracy dokładnie w tym samym obciążeniem. I to jest to, co wygląda jak teraz. Więc co się z NoSQL jest schemat danych, który jest absolutnie związane z wzorem dostępu. 

I można zoptymalizować ten schemat danych do wspierania tego wzoru dostępu. Jeśli nie, to masz zamiar aby zobaczyć te rodzaje problemów z tych klawiszy skrótu. 

PUBLICZNOŚCI: Cóż, z pewnością pewne miejsca będą cieplejsze niż inne. 

RICK HOULIHAN: Zawsze. Zawsze. Tak, mam na myśli zawsze A-- i znowu, nie niektóre wzorce projektowe dostaniemy się przez że będą rozmawiać o tym, jak radzić sobie z tych bardzo dużych skupiskach. Mam na myśli, muszę je mieć, w jaki sposób sobie z nimi radzić? Mam dość dobre przypadek użycia że będziemy rozmawiać o to. 

W porządku, więc porozmawiajmy około niektórzy klienci teraz. Oni są AdRoll. Nie wiem, czy jesteś zaznajomieni z AdRoll. Pewnie je zobaczyć dużo w przeglądarce. Są reklam ponownego kierowania, są największa ogłoszenie ponownego kierowania biznesu tam. Zazwyczaj regularnie przejechany 60 miliardów transakcji dziennie. Robią ponad milion transakcji na sekundę. Mają dość prostą tabelę Struktura, najbardziej ruchliwych tabeli. Jest to w zasadzie tylko Klawisz skrótu jest plik cookie, zakres jest demograficzna kategoria, a następnie Trzeci wymiar jest wynik. 

Tak więc wszyscy mamy cookies nasza przeglądarka z tych facetów. A kiedy idziesz do uczestnicząc kupca, w zasadzie zdobyć cię przez różne kategorie demograficzne. Kiedy idziesz na stronie internetowej oraz mówisz, że chcesz obejrzeć ten ad-- lub w zasadzie nie mówią that-- ale kiedy przejść do strony internetowej mówią, że chcą zobaczyć to ogłoszenie. I przejdź się, że reklamy z AdRoll. AdRoll wygląda cię na ich stole. Produkt plik cookie. Reklamodawcy opowiadają je, chcę kogoś kto jest w średnim wieku, 40-letni mężczyzna, w sporcie. A oni zdobyć cię w tych demografii i zdecydować, czy to dobra reklama dla Ciebie. 

Teraz mają SLA z ich dostawcy reklamowe dostarczenie sub-10 milisekund Odpowiedź na każdy wniosek. Więc oni używają Dynamo DB do tego. Oni uderzając nas na milion zapytań na sekundę. Oni są w stanie zrobić wszystko, ich podglądanie, triage wszystkie te dane, i uzyskać link dodaj z powrotem do ogłoszeniodawcy w niecałe 10 milisekund. To naprawdę dość fenomenalna wdrożenie, że mają. 

Ci faceci actually-- to są faceci. Nie jestem pewien, czy to tych facetów. Może być ci faceci. W zasadzie powiedział us-- nie, nie sądzę, że to oni. Myślę, że to ktoś inny. Pracowałem z Klient, który powiedział mi, że teraz, że już poszedł do Dynamo DB, są więcej pieniędzy na przekąski dla ich zespół rozwoju co miesiąc niż wydają na ich bazie. Więc to daje Pomysł z oszczędności że można uzyskać w Dynamo DB jest ogromna. Dobrze, dropcam inna firma. To facet, trochę of-- jeśli myślisz z Internetu rzeczy, dropcam Internet Video jest w zasadzie bezpieczeństwa. Możesz umieścić aparat tam. Aparat jest wyposażony w czujnik ruchu. Ktoś przychodzi, wyzwala punkt cue. Kamera rozpoczyna nagrywanie na chwilę aż nie wykryje żadnego ruchu już. Stawia ten film się w internecie. 

Dropcam była firma, która jest zasadniczo włączony do Dynamo DB dlatego, że doświadczali Ogromne Growing Pains. A co oni powiedzieli nam, nagle petabajtów danych. Nie mieli pojęcia, z ich usług byłby tak udany. Więcej wideo przychodzące niż YouTube jest to, co ci faceci są coraz. Używają DynamoDB śledzić wszystkie metadane wideo na wszystkich swoich kluczowych punktach. 

Więc mają S3 wiadra będą forsować wszystkie binarne artefakty język. A potem mają Zapisy Dynamo DB, że wskazać osoby do tych S3 trzech obiektów. Kiedy trzeba spojrzeć na wideo, patrzą się na zapis w Dynamo DB. Kliknięciu łącza. Są one rozwijane wideo z S3. Więc to jest trochę, jak to wygląda. I to jest prosto z ich zespołu. 

Dynamo DB zmniejsza ich czas dostawy do wydarzeń wideo od pięciu do 10 sekund. W swoim starym sklepie relacyjnej, kiedyś trzeba iść i wykonać wielu złożonych zapytań do rysunku się, które filmy do ciągnięcia w dół, do mniej niż 50 milisekund. Więc to jest niesamowite, niesamowite ile wydajność można uzyskać po optymalizacji i dostroić instrument bazowy w bazie wspierać wzór dostępu. Halfbrick, ci faceci, co to jest, Fruit Ninja Chyba jest ich sprawa. Że wszystkie działa na Dynamo DB. A ci faceci są doskonałym Zespół programistów, wielki rozwój robić zakupy. 

Nie jest to dobry zespół ops. Oni nie mają wiele zasobów pracy. Oni walczą stara się utrzymać ich infrastruktury do aplikacji i działa. Przyszli do nas. Patrzyli na tym Dynamo DB. Powiedzieli, że to dla nas. Oni zbudowali całość framework aplikacji na nim. Kilka naprawdę dobrych komentarze tutaj od zespołu na ich zdolności się teraz skupić na budynku gry i nie konieczności utrzymania infrastruktury, która stawało się ogromna ilość narzutu dla swojego zespołu. Więc to jest coś that-- korzyści, które można uzyskać z Dynamo DB. 

Dobrze, dostania się do Modelowanie tutaj dane. Rozmawialiśmy trochę o ten jeden do jednego, jeden do wielu, i wiele do wielu relacji typu. A jak utrzymać te w Dynamo. W Dynamo DB używamy indeksy, ogólnie rzecz biorąc, obracać się dane z jednego aromatu do drugiej. Hash klucze, klucze zakres i indeksów. 

W tym szczególnym Przykładem, jak w większości państw mają wymóg licencjonowania tylko jedno prawo jazdy za osobę. Nie można się tam dostać dwa kierowcy licencji w stanie Bostonie. Nie mogę tego zrobić w Teksasie. To rodzaj drogi jest. I tak w DMV, mamy wyszukiwań, że chcę patrzeć na prawo jazdy numer ubezpieczenia społecznego. Chcę spojrzeć na dane użytkownika według numeru licencji kierowcy. 

Więc możemy mieć stolik użytkownika, że ma klawisza skrótu na numer seryjny, lub numer ubezpieczenia społecznego, a różne atrybuty zdefiniowane w pkt. Teraz na tej tabeli I może zdefiniować GSI, że koziołki, że ok, że mówi, że chce klawisz skrótu na licencji, a następnie wszystkie pozostałe elementy. Teraz, jeśli chcę zapytać i znaleźć Numer licencji dla danego Społecznych Numer ubezpieczenia, mogę zapytania główną tabelę. 

Jeśli chcę zapytać i chcę aby uzyskać ubezpieczenie społeczne numer lub inne atrybuty przez Numer licencji mogę kwerendy GSI. Model ten jest, że jeden do jednego związku. Po prostu bardzo proste GSI, odwrócić te rzeczy wokół. Teraz mówimy o jednym z wielu. Jednym z wielu jest w zasadzie klucz Zakres hash. W przypadku, gdy mamy dużo z tym przypadek użycia jest dane monitora. Dane monitor jest w regularnych odstęp, jak internet rzeczy. Zawsze się to wszystko Zapisy w najbliższych cały czas. 

I chcę, aby znaleźć wszystkie odczyty między danym okresie czasu. Jest to bardzo częste pytanie w infrastruktury monitorowania. Sposób, w jaki go o to, aby znaleźć proste struktury tabeli, jeden stół. Mam tabelę pomiarów urządzeń pomocą krzyżyka na ID urządzenia. I mam klucza gama na datownik, lub w tym przypadku, epicki. A to pozwala mi wykonywać kompleks Zapytania przeciwko tym kluczem Zakres i powrócić te rekordy, które odnoszą się do wyników ustawić, że szukam. I buduje, że jeden do wielu relacji w tabeli podstawowej przy użyciu klawisz krzyżyka, struktura kluczowym zakres. 

Więc to rodzaj zbudowany do tabeli w Dynamo DB. Kiedy zdefiniować hash i zakres t stołowy, jestem definiując jeden do wielu relacji. Jest to relacja rodzic-dziecko. 

Porozmawiajmy o wiele do wielu relacji. I w tym konkretnym przykładzie, znowu, będziemy używać GSi. I porozmawiajmy o grach scenariusz, w którym mam danego użytkownika. Chcę dowiedzieć się, wszystkie gry, które on zarejestrowany lub grając w. I dla danej gry, ja chcą znaleźć wszystkich użytkowników. Więc jak to zrobić? Moja tabela gry użytkownika, zamierzam mieć klucz hash ID użytkownika oraz kluczowy zakres gry. 

Tak więc użytkownik może mieć wiele gier. Jest to jedna z wielu relacji między użytkownik i gry, które gra. A następnie na GSI, Będę odwrócić, że ok. Będę hash na grze i Będę wahać od użytkownika. Więc jeśli chcę uzyskać wszystkie Gra użytkownik gra w, Będę zapytania główną tabelę. Jeśli chcę uzyskać wszystkich użytkowników które odgrywają szczególną grę, I kwerendy GSI. Więc widzisz, jak to zrobić? Budujesz je GSi do wsparcia przypadek użycia, aplikacja, dostęp wzór, aplikacja. 

Jeśli muszę zapytać o ten wymiar, niech mi stworzyć indeks na tym wymiarze. Jeśli nie, mnie to nie obchodzi. I w zależności od przypadku użycia, I może potrzebować indeksu albo i nie. Jeśli jest to proste, jeden do wielu, pierwsza tabela jest w porządku. Jeśli muszę zrobić to wielu wiele, albo muszę zrobić jedną do nich, to może ja potrzebuję do drugiej indeks. Więc wszystko zależy od co próbuję zrobić i co staram się uzyskać znakomity. 

Prawdopodobnie nie będę wydawać zbyt dużo czasu rozmawiając o dokumentach. To staje się trochę, chyba, głębiej niż potrzebujemy, aby przejść do. Porozmawiajmy trochę o bogatym wyrażenie kwerendy. Tak więc w Dynamo DB mamy możliwość tworzenia co nazywamy wyrażenia projekcji. Wyrażenia projekcyjne są po prostu zbieranie pola lub wartości które chcesz wyświetlić. OK, więc dokonać wyboru. Robię zapytanie przeciwko Dynamo DB. A ja mówię, wiesz co, pokaż mnie tylko pięciogwiazdkowe recenzje dla danego wyrobu. Więc to wszystko, co chcą zobaczyć. Nie chcę, aby zobaczyć wszystkie inne atrybuty rzędu, Chcę po prostu zobaczyć. To tak jak w SQL, gdy powiedzieć, wybierz gwiazdę lub z tabeli, masz wszystko. Kiedy mówię, wybierz nazwę z Stół, mam jeden atrybut tylko. To ten sam rodzaj rzeczy w Dynamo DB lub inny bazy NoSQL. Wyrażenia filtrujące pozwalają mi w zasadzie cięcia zestaw wyników w dół. Więc robię zapytanie. Zapytanie może wrócić z 500 pozycji. Ale chcę tylko te elementy, które mieć atrybut, który mówi to. OK, więc niech to odfiltrować te pozycje które nie pasują tego konkretnego zapytania. Mamy więc wyrażeń filtrujących. 

Wyrażenia filtr może uruchomić na dowolnym atrybutem. Oni nie lubią zapytań zasięgu. Raise pytania są bardziej selektywne. Zapytania filtrujące wymagają mi iść Wyniki się cały zestaw, a następnie wykroić dane nie chcę. Dlaczego to jest ważne? Bo czytam to wszystko. W zapytaniu, będę czytać i to będzie olbrzymi temat danych. A potem mam zamiar wykroić co muszę. A jeśli jestem tylko pominięcia Kilka wierszy, to to jest OK. To nie jest tak nieskuteczny. 

Ale jeśli czytam cały stos Dane, żeby wykroić jeden przedmiot, potem mam zamiar być lepiej przy użyciu kwerendy zakresu, dlatego, że jest o wiele bardziej selektywny. To uratuje mi dużo pieniądze, bo płacić za tego odczytu. Jeżeli wyniki testów, które wraca przejdę ten przewód może być mniejsza, ale ja płacę za odczytu. Więc rozumiem, jak dostajesz dane. To bardzo ważne w Dynamo DB. 

Wyrażenia warunkowe, jest to, co można nazwać optymistycznego blokowania. Aktualizacja IF EXISTS, czy ta wartość jest odpowiednikiem tego, co mogę określić. A jeśli mam znacznik czasu na zapis, że mogę odczytać danych. Może zmienić te dane. Może pójdę napisać, że Dane z powrotem do bazy. Jeśli ktoś zmienił zapis, datownik mogła ulec zmianie. I w ten sposób moja warunkowa Aktualizacja mógł powiedzieć aktualizacji jeśli znacznik czasu wynosi w tym. Albo aktualizacja nie powiedzie się, ponieważ ktoś zaktualizowała rekord w międzyczasie. 

To, co nazywamy optymistycznego blokowania. Oznacza to, że ktoś może przyjść i go zmienić, i mam zamiar go wykryć kiedy wrócę do pisania. I wtedy rzeczywiście mogę przeczytać, że Dane i powiedzieć, oh, on zmienił to. Muszę wyjaśnić, że. I mogę zmienić dane w moim nagrywanie i zastosować kolejną aktualizację. Więc można złapać tych, przyrostowe aktualizacje, które występują pomiędzy czasem zapoznanie się dane, i Czas można zapisać dane. 

PUBLICZNOŚCI: A filtr wyraz w rzeczywistości nie oznacza numer lub not-- 

[Wstawienie GŁOSY] RICK HOULIHAN: nie powiem zbyt wiele do tego. To jest zarezerwowane słowo kluczowe. Widok funt jest zastrzeżone kluczowe w Dynamo DB. Każdy ma swoje własne bazy danych zastrzeżone Nazwy zbiorów nie można używać. Dynamo DB, jeśli podasz funta przed tym, można określić te nazwy się powyżej. Jest to odniesienie wartości. To chyba nie najlepszy składni mają tam do tej dyskusji, dlatego, że dostanie się do niektórych real-- I byłoby mówić więcej o, że na głębszym poziomie. 

Ale wystarczy powiedzieć, może to być kwerendy skanowania gdzie views-- ani poglądy funta jest większa niż 10. Jest to wartość liczbowa, tak. Jeśli chcesz, możemy mówić o które po dyskusji. W porządku, więc pakujesz Niektóre scenariusze w najlepszych praktyk gdzie będziemy rozmawiać tutaj o niektórych aplikacji. Co to są przypadki użycia dla Dynamo DB. Co to projektowanie wzory w Dynamo DB. 

I pierwszy będziemy Dyskusja na temat jest internet rzeczy. Tak więc mamy dużo of-- Chyba, co jest it-- więcej niż 50% ruchu w Internecie tych dni jest faktycznie generowany przez maszyny, zautomatyzowane procesy, nie przez ludzi. Mam na myśli to coś, co się tam nosisz w kieszeni, jak dużo danych, że jest to rzeczywistości wysyła się bez Ciebie wiedząc, że jest absolutnie niesamowite. Twoja lokalizacja, informacje o tym, jak szybko jedziesz. Jak myślisz, Google Maps działa kiedy powiedzieć, co jest ruch. To dlatego, że są miliony i miliony ludzi jazdy wokół z telefonów, które są wysyłających Dane całym miejscu przez cały czas. Tak więc jedną z rzeczy, o tego typu danych że jest w dane monitora, zalogować Dane, dane szeregów czasowych, jest to zwykle tylko interesujące na trochę czasu. Po tym czasie, to nie tak interesujące. Więc rozmawialiśmy, nie pozwól te tabele rozwijać się bez granic. Chodzi o to, że być może mam 24 Godziny warto wydarzeń w moim gorącym stole. I to gorący stół będzie zabezpieczony na bardzo wysokim poziomie, bo to zabiera dużo danych. To zabiera dużo danych i czytam to dużo. Mam dużo pracy Zapytania uruchomione przed tymi danymi. 

Po 24 godzinach, hej, wiesz co, mnie to nie obchodzi. Więc może ja codziennie o północy rolki mój stół na nowy stół a ja deprovision tej tabeli. I wezmę Pilot i Się na wózek, ponieważ po 24 godzinach Nie uciekam jak wielu Zapytania przeciwko tym danych. Więc mam zamiar zaoszczędzić pieniądze. A może 30 dni później, ja nie nawet trzeba dbać o to wszystko. Mogłem wziąć WCU na w dół do jednego, bo wiesz co, to nigdy nie dostanie zapisywane. Dane jest 30 dni. To nigdy się nie zmienia. 

I to prawie nigdy nie będzie się czytać, więc niech po prostu przyjąć, że pilocie do 10. A ja oszczędzając mnóstwo pieniędzy na ten temat Dane i tylko płacić za moich gorących danych. Więc to jest ważna rzecz, szukać co, jeśli spojrzeć na szeregu czasowego danych pochodzących w objętości. Są to strategie. Teraz mogę tylko niech go wszyscy trafiają do tej samej tabeli i po prostu pozwól, że tabela rosną. W końcu będę zobacz problemy z wydajnością. Mam zamiar zacząć archiwizować niektóre z tych danych ze stołu, etażerka. 

Miejmy znacznie lepiej projektowania aplikacji tak, że można pracować w ten sposób prawo. Więc to tylko automatyczne w kodzie aplikacji. O północy każdej nocy toczy się w tabeli. Może to, co potrzebne jest przesuwne Okno 24 godzin danych. Potem regularnie jestem dzwoniąc dane ze stołu. Jestem przycinanie go z Cron i Kładę go na tych innych tabel, co trzeba. Więc jeśli rollover działa, to świetnie. Jeśli nie, przyciąć go. Ale trzymajmy że gorące dane z dala od zimnych danych. Będzie to zaoszczędzić dużo pieniędzy i Nakręć Stoły wykonywania. Więc następną rzeczą, będziemy rozmawiać o jest w katalogu. Katalog wyrobów jest dość powszechne przypadek użycia. To jest rzeczywiście bardzo często wzór które zobaczymy w różnych rzeczy. Wiesz, Twitter dla Przykładem, gorący tweet. Wszyscy przychodzą i chwytając ten tweet. Katalog wyrobów dostałem sprzedaży. Mam gorącą sprzedaż. Mam 70.000 żądań na drugie przyjście na produkt Opis z katalogu mojego produktu. Widzimy to w handlu detalicznym Operacja trochę. Jak więc sobie z tym poradzić? Nie sposób sobie z tym poradzić. Wszyscy moi użytkownicy chcą zobaczyć tego samego kawałka danych. Oni są w najbliższych, jednocześnie. I oni wszyscy żądaniach z tego samego kawałka danych. To daje mi, że klawisz skrótu, że duża czerwona pasek na moim wykresie, że nam się nie podoba. A to, co to wygląda. Więc po mojej przestrzeni kluczy Dostaję młotkiem w sprzedaży przedmiotów. Dostaję nic nigdzie indziej. 

Jak mogę złagodzić ten problem? Cóż, możemy złagodzić to z pamięci podręcznej. Cache, można umieścić w zasadzie w pamięci partycji przed danych. Udało nam [Niesłyszalne] cache, jak ci Można założyć własną pamięć podręczną, [niesłyszalne] kryjówka [? d,?], co chcesz. Umieścić, że w przedniej części danych. I w ten sposób można przechowywać te dane z tych gorących klawiszy w górę w tej pamięci podręcznej przestrzeń i przeczytać pamięci podręcznej. 

I wtedy większość swojego czyta zacząć patrzeć w ten sposób. Mam wszystkie te cache uderza się tutaj i ja nic nie dzieje się tutaj ponieważ baza danych jest siedział za pamięci podręcznej i nigdy nie czyta przechodzą. Jeśli zmienić dane w bazy danych, mam do aktualizacji pamięci podręcznej. Możemy użyć czegoś jak paruje to zrobić. I postaram się wyjaśnić, jak to działa. Dobrze, wiadomości. E-mail, wszyscy korzystają z poczty elektronicznej. 

Jest to bardzo dobry przykład. Mamy jakieś wiadomości tabeli. I mamy skrzynki odbiorczej i nadawczej. To jest to, co SQL będzie wyglądają jak zbudować tę skrzynkę. W pewien sposób korzystać z tego samego rodzaju strategii wykorzystania GSi, GSi dla mojej skrzynce odbiorczej i mojej skrzynce nadawczej. Więc mam surowe wiadomości nadchodzi do mojego tabeli wiadomości. I pierwsze podejście do tego może być, powiedzmy, OK, nie ma problemu. Mam surowe wiadomości. Wiadomości pochodzące [niesłyszalne], Komunikat ID, to świetnie. To mój unikalny hash. Mam zamiar stworzyć dwa GSi, jeden dla mojej skrzynce odbiorczej, jeden dla mojej skrzynce nadawczej. I pierwszą rzeczą, zrobię Powiem jest mój klucz do skrótu będzie odbiorcą i Mam zamiar zorganizować w dniu. To jest fantastyczne. Dostałem ładny widok tutaj. Ale jest trochę problem tutaj. I napotkasz to w relacyjnych baz danych, jak również. Nazwali pionowo partycjonowania. Chcesz zachować swój wielki dane z dala od małych danych. 

I dlatego to, bo muszę go przeczytać przedmiotów, aby uzyskać atrybuty. A jeśli moje ciało jest tu wszystko, Następnie czyta tylko kilka elementów jeśli długość ciała jest średnio 256 kilobajtów każdy, matematyka staje się dość brzydki. Tak mówią Chcę przeczytać skrzynkę Dawida. Skrzynka Dawida ma 50 przedmiotów. Średni i wielkość to 256 kilobajtów. Oto mój współczynnik konwersji dla RCU jest cztery kilobajtów. 

OK, idziemy z w końcu zgodne czyta. Jestem nadal jeść 1600 Pilot na tylko do odczytu skrzynki Dawida. Ojej. OK, teraz pomyślmy o tym, jak działa aplikacja. Jeśli jestem w aplikacji e-mail i Patrzę na mojej skrzynce odbiorczej, i patrzę na ciele każdej wiadomości, Nie, patrzę na zestawieniach. Patrzę na tylko nagłówki. Warto więc budować struktury tabeli że wygląda bardziej tak. 

Więc oto informacje że mój workflow potrzebuje. Jest w mojej skrzynce odbiorczej GSI. Jest to data, nadawca, przedmiotem, a następnie identyfikator wiadomość, która wskazuje z powrotem do tabeli wiadomości gdzie mogę dostać się do organizmu. Cóż, to byłby rekord identyfikatory. Oni wskazują z powrotem do Identyfikatory pozycja w tabeli Dynamo DB. Każdy wskaźnik zawsze creates-- zawsze pozycję ID jako część of--, że pochodzi z indeksu. 

W porządku. PUBLICZNOŚCI: Mówi się, gdzie jest przechowywane? RICK HOULIHAN: Tak, to mówi exactly-- to jest dokładnie to, co robi. Mówi tu jest mój rekord ponownie. I to będzie skierować go z powrotem do mojego rekordu re. Dokładnie. OK, więc teraz moja skrzynka odbiorcza jest w rzeczywistości znacznie mniejsze. I to właściwie obsługuje przepływ pracy o aplikacji e-mail. Tak skrzynce odbiorczej, klikam. Idę wzdłuż i klikam na wiadomości, to kiedy muszę udać się do organizmu, bo mam zamiar przejść do innego widoku. Więc jeśli myślisz o rodzaju MVC Ramy, model widok kontroler. 

Model zawiera Dane że widok potrzeby i sterownik komunikuje się z. Kiedy zmienić ramkę, kiedy I zmienić perspektywę, to OK, aby wrócić do Serwer i zaludnić modelu, ponieważ to, co oczekuje użytkownik. Kiedy zmienić poglądy, to kiedy możemy wrócić do bazy. Tak e-mail, kliknij przycisk. Szukam ciała. Podróż w obie strony. Idź po ciało. 

Czytałem dużo mniej danych. Czytam jedynie organów, które David potrzebuje, kiedy ich potrzebuje. I nie mam nagrać w 1600 Pilot po prostu pokazać swoją skrzynkę odbiorczą. Więc teraz that-- jest to sposób że LSI lub GSI-- Przykro mi, GSI, by wypracować. Mamy nasz skrót na odbiorcę. Mamy klucz gama na bieżąco. I mamy prognozowanych atrybuty że potrzebujemy tylko potwierdzają pogląd. 

Obracamy, że do skrzynki nadawczej. Hash na nadawcy. I w istocie, mamy bardzo ładny, czysty widok. I to basically-- mamy mają ten miły wiadomości Stół, który jest rozprzestrzeniają się ładnie, bo to tylko skrót, zakodowane wiadomości ID. I mamy dwa indeksy, które obracają się w tej tabeli. W porządku, więc Chodzi o to, nie przechowywać duże ilości danych i ten mały danych razem. Partition pionowo, partycjonowanie tych tabel. Nie odczytu danych nie trzeba. Dobrze, gier. Wszyscy lubimy gry. Przynajmniej Lubię gry wtedy. Tak więc niektóre rzeczy że mamy do czynienia z przypadku myślimy o grach, prawda? Gaming tych dniach, zwłaszcza mobilne gier, jest o myśleniu. I mam zamiar obrócić się tutaj nieco z dala od DynamoDB. Zamierzam wnieść w niektóre dyskusji wokół niektórych inne technologie AWS. 

Ale pomysł o grach jest myśleć o w zakresie interfejsów API, API, które są, ogólnie rzecz biorąc, HTTP i JSON. To jak mobilne gry rodzaju interakcji z końców tylnych. Robią JSON delegowania. Oni się dane, i to wszystko, ogólnie rzecz biorąc, w miłych API JSON. 

Rzeczy takie jak dostać znajomych, uzyskać dane liderów, wymiany, Materiał generowany przez użytkowników, wcisnąć z powrotem do systemu są to rodzaje rzeczy które mamy zamiar zrobić. Dane binarne aktywów, dane nie może siedzieć w bazie danych. To może siedzieć w sposób sklep obiektu, prawda? Ale baza danych będzie kończy się informacją z systemu, mówi aplikację gdzie się udać zdobyć. I nieuchronnie, multiplayer serwery, infrastruktura koniec z powrotem, i przeznaczone do wysokiej dostępność i skalowalność. To są rzeczy, które wszyscy chcemy w infrastrukturę gier dzisiaj. 

Warto więc przyjrzeć się co to wygląda. Masz rdzenia tylny koniec, bardzo proste. Mamy system tutaj z wiele stref dostępność. Rozmawialiśmy o AZS, jak being-- myśleć z nich jako oddzielne centra danych. Więcej niż jedno centrum danych na AZ, ale to jest OK, tylko myśleć o nich jako o odrębnym danych ośrodki, które są geograficznie i wina odizolowane. 

Mamy zamiar mieć Kilka instancji EC2. My będziemy mieć niektóre z powrotem end. Może jeśli jesteś dziedzictwo architektura, jesteśmy za pomocą tego, co nazywamy RDS, relacyjne bazy danych. usługi Może być MSSQL, MySQL, czy coś takiego. To jest sposób, w jaki aplikacje dużo są już zaprojektowane. 

Cóż możemy iść z to jest, gdy skalowanie. Idziemy do przodu i umieścić wiadro tam S3. I to wiadro S3, zamiast służyć się tych obiektów ze servers-- możemy to zrobić. Możesz umieścić wszystkie swoje pliki binarne obiekty na serwerach i można korzystać z tych serwer przypadki, aby służyć, że dane w górę. Ale to jest dość drogie. 

Lepszy sposób zrobić to iść do przodu i umieścić te obiekty w wiadrze S3. S3 to obiekt repozytoriów. Jest zbudowany specjalnie dla obsługujących tego typu rzeczy. I niech zażądać tych klientów bezpośrednio z tymi wiadrami obiektów, odciążyć serwery. Więc zaczynamy skalować się tutaj. 

Teraz mamy użytkowników na całym świecie. Mam użytkowników. Muszę mieć zawartość lokalnie położony blisko tych użytkowników, prawda? Mam stworzył wiadro S3 w moim repozytorium źródłowego. A ja z przodu, że z dystrybucja CloudFront. 

CloudFront jest CD i Zawartość Delivery Network. Zasadniczo to ma danych, które można określić i buforuje to wszystko przez internet więc użytkownicy wszędzie może mieć bardzo szybka reakcja, kiedy zwracają się te obiekty. 

Więc masz pomysł. Jesteś rodzaju wykorzystując wszystkie aspekty AWS tutaj, aby to zrobić. I w końcu, rzucamy w grupie automatycznego skalowania. Więc nasze przypadkach AC2 z naszych serwerów gry, jak zacząć, aby uzyskać bardziej zajęty i bardziej zatłoczone i bardziej zajęty, oni po prostu kręcić kolejny Instancja, kręcić kolejną instancję, kręcić kolejną instancję. Więc technologii AWS ma, to pozwala określić parametry wokół którego serwery wzrośnie. Więc możesz mieć n liczba serwerów tam, w dowolnym danym czasie. A jeśli obciążenie odchodzi, będą kurczyć liczba skurczy. A jeśli obciążenie wraca, będzie rosnąć z powrotem, elastycznie. 

Tak to wygląda świetnie. Mamy wiele instancji EC2. Możemy umieścić pamięć w z przodu z bazami danych, spróbować przyspieszyć baz danych. Kolejnym punktem ciśnienia zazwyczaj ludzie widzą jest skala ich grę za pomocą relacyjnego systemu baz danych. Jezu, baza danych Wydajność jest straszna. W jaki sposób możemy poprawić, że? Spróbujmy wprowadzenie cache przed tym. 

Cóż, pamięć podręczna nie działa tak wielka, w grach, prawda? W grach, pisanie jest bolesne. Gry są bardzo Napisać ciężkie. Cache nie działa, gdy jesteś Napisać ciężkie, bo ty zawsze dostał się do aktualizacji pamięci podręcznej. Zaktualizować pamięć podręczną, to bez znaczenia jest buforowanie. To właściwie tylko dodatkowa praca. 

Więc gdzie pójdziemy tutaj? Masz duży wąskie gardło tam w bazie danych. I miejsce do pracy oczywiście jest partycjonowanie. Podział nie jest łatwe do zrobienia, gdy jesteś czynienia z relacyjnych baz danych. Z relacyjnymi bazami danych, jesteś odpowiedzialny za zarządzanie, skutecznie klawisz spacji. Mówisz użytkowników między A i M kliknij tutaj, między N i Z tam. A ty przełączania drugiej aplikacji. Więc masz do czynienia z to źródło danych partycji. Musisz ograniczeń transakcyjnych które nie rozciągać partycje. Masz wszystkie rodzaje niechlujstwo, że jesteś zajmujących się tam próbuje do czynienia z Skalowanie i budowanie większej infrastruktury. To po prostu nie ma zabawy. 

PUBLICZNOŚCI: Więc mówisz, że zwiększenie punktów źródłowych przyspiesza proces? RICK HOULIHAN: Zwiększenie? Punkty Źródło: publiczność. RICK HOULIHAN: punkty źródłowe? PUBLICZNOŚCI: Z informacji, w przypadku gdy informacja pochodzi? RICK HOULIHAN: Nie Co mówię jest zwiększenie liczba partycji w pamięci danych poprawia wydajność. Więc co się tutaj dzieje jest użytkowników wchodząc do instancji EC2 się tutaj, dobrze, jeśli potrzebuję użytkownika to A do M, pójdę tutaj. Z N p, pójdę tutaj. Od P do Z, pójdę tutaj. 

PUBLICZNOŚCI: OK, więc to są ci, przechowywane w różnych węzłach? 

RICK HOULIHAN: Tak. Pomyśl o nich jako różne silosy danych. Więc masz to zrobić. Jeśli próbujesz zrobić to, jeśli starasz skalowanie na relacyjnej platformy, to jest to, co robisz. Bierzesz dane i masz je ścinać. A ty podzielenie go przez wiele instancji bazy danych. A ty zarządzaniu wszystko w warstwie aplikacji. To nie jest zabawne. Więc co chcemy iść? Chcemy pójść DynamoDB, w pełni zagospodarowana, Magazyn danych NoSQL, przepustowość przepis. Używamy indeksy średnich. Jest to w zasadzie HTTP API i obejmuje obsługę dokumentów. Więc nie musisz się martwić o żadnej z tego podziału. Robimy to wszystko dla Ciebie. Więc teraz, zamiast tego, po prostu napisz do stołu. Jeśli tablica musi być podzielony, co dzieje się za kulisami. Jesteś całkowicie izolowane od tego, jako deweloper. Więc porozmawiajmy o niektóre z przypadków użycia które napotkasz w grach, wspólny Scenariusze gier, liderów. Więc masz użytkownicy najbliższych, z BoardNames, że są one na, wyniki dla tego użytkownika. Możemy być mieszania na ID użytkownika, a następnie mamy wybór na grę. Tak więc każdy użytkownik chce zobaczyć wszystko gra on grał i wszystkie jego najlepszy wynik we wszystkich gry. Więc to jest jego osobista liderów. 

Teraz chcę iść i chcę get-- więc mam te osobiste liderów. To, co chcę zrobić, to udać się najlepszy wynik dla wszystkich użytkowników. Więc jak to zrobić? Kiedy mój rekord jest mieszany na identyfikator użytkownika, wahały się od gry, dobrze mam zamiar iść do przodu i restrukturyzacji, stworzyć GSI, i mam zamiar do restrukturyzacji tych danych. 

Teraz idę do mieszania na BoardName, która jest gra. I będę wahać się najlepszy wynik. A teraz stworzyłem różne wiadra. Używam tej samej tabeli, te same dane pozycji. Ale tworzę wiadro, które daje mi agregacja najwyższym wynikiem od gry. 

A mogę zapytać, że tabela aby uzyskać te informacje. Więc mam ustawić ten wzór zapytania do wspierane przez indeks wtórnego. Teraz mogą być klasyfikowane według BoardName i klasyfikowane według TopScore, w zależności od. Tak więc widać, są to typy Korzystanie z przypadków masz w grach. Kolejny dobry przypadek użycia mamy w grach to nagrody i kto wygrał nagrody. I to jest wielki przypadek użycia gdzie zadzwonić rzadkie indeksów. Indeksy Nieliczne są Zdolność tworzenia indeks, że niekoniecznie zawierać każdy element na stole. Czemu nie? Ponieważ atrybut, który jest jest indeksowane nie istnieje na każdej pozycji. 

Tak więc w tym konkretnym używać sprawy, mówię, wiesz co, mam zamiar utworzyć atrybut o nazwie Award. I mam zamiar dać każdemu użytkownikowi że ma nagrodę tego atrybutu. Użytkownicy, którzy nie mają nagrody są nie będzie miał tego atrybutu. Kiedy więc stworzyć Strona, tylko użytkownicy które będą wykazywały w indeksie są te, które rzeczywiście zostały nagrodzone. Tak, że to świetny sposób, aby być w stanie stworzyć filtrowane indeksy, że są bardzo, bardzo selektywne, które nie mają indeksować całą tabelę. 

Więc mamy już mało czasu tutaj. Mam zamiar iść do przodu i pominąć się i pominąć ten scenariusz. Dyskusja trochę about-- 

PUBLICZNOŚCI: Czy mogę zadać krótkie pytanie? Jednym z nich jest Napisać ciężkie? RICK HOULIHAN: Co to jest? PUBLICZNOŚCI: Napisz ciężkie. RICK HOULIHAN: Napisz ciężkie. Daj mi zobaczyć. 

PUBLICZNOŚCI: Albo jest to, że nie coś, co można po prostu Głos w ciągu kilku sekund? RICK HOULIHAN: Idziemy przez scenariuszu głosowania. Nie jest tak źle. Czy macie kilka minut? OK. 

Więc będziemy rozmawiać o głosowaniu. Więc głosowania w czasie rzeczywistym, mamy wymagania dotyczące głosowania. Wymagania są takie, że pozwalają każda osoba głosować tylko raz. Chcemy, nikt nie być w stanie zmienić swój głos. Chcemy agregacji w czasie rzeczywistym i analiz dla demografii że będziemy mieć pokazywanie użytkowników na stronie. 

Pomyśl o tym scenariuszu. Mamy wiele rzeczywistości działa Telewizja pokazuje, gdzie są robi te dokładny typ rzeczy. Tak więc można myśleć o scenariuszu, mamy miliony wśród nastoletnich dziewcząt tam z ich telefonów komórkowych i głosowania i głosowania, głosowanie na kimkolwiek są znaleźć się najbardziej popularne. To są jedne z Wymagania zabraknie. 

I tak w pierwszej kolejności podejmuje w rozwiązaniu tego problemu będzie budować bardzo prosta aplikacja. Więc mam tę aplikację. Mam kilka wyborców tam. Pochodzą one w, trafią aplikację do głosowania. Mam trochę surowy głosów tabeli Ja po prostu zrzucić te głosy się. Muszę trochę kruszywa głosów tabela zrobi swoje analizy i demografii, a my umieścić to wszystko w środku. 

I to jest świetne. Życie jest dobre. Życie jest dobre, dopóki nie dowiemy się, że zawsze tylko jeden lub dwa osób, które są popularne w wyborach. Jest tylko jedna lub dwie rzeczy że ludzie naprawdę zależy. A jeśli głosowanie na Skala, nagle jestem będzie młotkiem piekło z dwóch kandydatów, jeden lub dwóch kandydatów. Bardzo ograniczona liczba elementów ludzie znajdują się popularne. 

To nie jest dobry wzór projektu. To jest rzeczywiście bardzo zły wzorzec projektowy ponieważ tworzy dokładnie to, czego mówił o których była klawisze. Klawisze są czymś, czego nie lubimy. 

Więc jak to naprawić? I rzeczywiście, tak aby to naprawić jest biorąc te wiadra kandydujące i dla każdego kandydata mamy, mamy zamiar dołączyć losową wartość, coś, co wiemy, losowo Wartość pomiędzy jednym i 100, od 100 do 1000, lub od jednego do 1000, jednak wiele losowych wartości chcesz dołączyć na końcu tego kandydata. 

I co ja naprawdę zrobić wtedy? Jeśli używam identyfikator kandydata jako wiadro do głosów kruszywa, jeśli dodałem losowy liczba na koniec, że, Stworzyłem już 10 wiadra, A sto wiader wiadra, tysiąc że jestem agregowania głosów w poprzek. 

Więc mam miliony i miliony, i miliony rekordów w najbliższych dla tych kandydatów, jestem teraz rozprzestrzenia te głosy całej kandydackiej A_1 przez Kandydata A_100, ponieważ Głosowanie za każdym razem przychodzi, Jestem generowania losowych wartość od jednego do 100. Jestem sklejaniu ją na koniec Kandydat, że głosowanie na osoby. Jestem dumpingu go do tego wiadra. 

Teraz z tyłu, wiem że mam sto wiader. Więc kiedy chcę iść do przodu i agregacji głosów, Czytam ze wszystkich tych wiader. Więc śmiało i dodać. A potem ja rozrzut zebrać gdzie wyjść i powiedzieć, hej, wiesz co, klucz tego kandydata miejsc jest ponad sto wiader. Mam zamiar zebrać wszystkie głosów z tych stu wiadrach. Idę do agregowania je i mam zamiar powiedzieć, Kandydat A ma teraz Łączna głos x. 

Teraz zarówno zapisu kwerendy i kwerendy odczytu są ładnie rozłożone bo piszę w całej i czytam przez setki kluczy. Nie piszę i czytanie całej jeden klucz teraz. Tak, że to świetny wzór. 

To jest rzeczywiście prawdopodobnie jednym najważniejszego projektowania wzorce dla skali w NoSQL. Widać ten typ wzornictwo w każdym smaku. MongoDB, DynamoDB, nie robi Niezależnie, wszyscy mamy to zrobić. Bo kiedy masz do czynienia z tych ogromnych skupisk, trzeba znaleźć sposób na rozłożyć całej wiadrach. Więc to jest tak, jak to zrobić. No dobrze, więc co robisz teraz jest pan handel off lektury koszt zapisu skalowalności. Koszt mojego odczytu jest nieco bardziej skomplikowane i muszę go odczytać z Sto wiadra zamiast jednego. Ale jestem w stanie napisać. A mój przepustowość, mój zapisu Przepustowość jest niesamowite. Tak to zwykle cennym technika skalowania DynamoDB, lub dowolnej bazy danych NoSQL o to chodzi. Tak więc zorientowali się, jak go przeskalować. I doszliśmy jak wyeliminować nasze klawiszy skrótu. I to jest fantastyczne. I mamy niezły system. I to daje nam bardzo poprawne głosowania bo mamy rekord głosowania de duplikatem. Jest zbudowany w DynamoDB. Rozmawialiśmy o warunkowego prawa. 

Gdy wyborca ​​przychodzi, stawia wkładkę na stole oni wstawiać ich wyborców ID, gdyby spróbować włożyć inny głos, Robię zapis warunkowy. Tylko powiedzieć, napisać to Jeśli nie istnieje. Więc jak tylko widzę, że że oceniany hitu tabeli, nikt inny nie będzie w stanie umieścić swój głos na. I to jest fantastyczne. A my zwiększając nasze liczniki kandydujących. I robimy co w naszej demografia i to wszystko. Ale co się stanie, jeśli moje Aplikacja przewraca? Teraz nagle głosów są w najbliższych, a ja nie wiem, czy są one przetwarzane coraz do moich analiz i demografii więcej. I gdy aplikacja wraca się, jak do cholery mam wiedzieć, co głosy przetwarzane i gdzie mam zacząć? 

Więc to jest prawdziwy problem, gdy zacząć patrzeć na tego typu scenariusz. A w jaki sposób rozwiązać ten? Rozwiążemy go z tym, co zadzwoń DynamoDB strumieni. Strumienie jest czas zamówione i podzielony Dziennik zmian każdego dostępu w tabeli, każdy napisać dostępu do tabeli. Wszelkie dane, które napisała do Tabela pokazuje się na strumień. 

Jest to w zasadzie Kolejka 24 godziny. Produkty uderzył strumień, żyją do 24 godzin. Mogą być odczytywane wielokrotnie. Gwarantowana być dostarczone raz w strumieniu można odczytać liczbę n razy. Więc jednak wiele procesów chcesz zużywają te dane, można go spożywać. Pojawi się on każdej aktualizacji. Każdy zapis będzie tylko pojawiają się raz na strumieniu. Więc nie musisz się martwić o przetworzeniu go dwa razy z tego samego procesu. 

Jest ściśle uporządkowane za sztukę. Kiedy mówimy, że czas uporządkowany i podzielony na partycje, zobaczysz na partycji, na strumieniu. Zobaczysz przedmiotów, aktualizacje w porządku. Nie gwarantujemy w strumieniu, że jesteś dostanie każdą transakcję W drugiej kolejności elementów. 

Więc strumienie są idempotent. Czy wszyscy wiemy, co idempotent oznacza? Idempotent oznacza, że ​​można to zrobić ponad, kółko, w kółko. Rezultatem będzie taki sam. 

Strumienie są idempotent, ale nie musi być grał od punktu początkowego, wszędzie tam, gdzie chcesz, aby do końca, lub nie spowoduje w takich samych wartości. 

To samo z MongoDB. MongoDB ma konstrukcję nazywają oplog. Jest to dokładnie ten sam konstrukt. Wiele baz danych NoSQL mają tę konstrukcję. Używają go do robienia rzeczy, jak replikacja, które jest dokładnie to, co robimy z strumieni. PUBLICZNOŚCI: Może heretyckie pytanie, ale mówić o aplikacje robi w dół itd. Strumienie są gwarantowane nigdy nie może iść w dół? RICK HOULIHAN: Tak, strumieni gwarancję, aby nigdy nie zejść. Zarządzamy infrastrukturą za. strumieni automatycznie wdrożyć w swojej grupie automatycznego skalowania. Pójdziemy za mały nieco o tym, co się dzieje. 

Nie powinienem powiedzieć, że nie są na pewno nigdy nie zejść. Elementy są gwarantowane do stawienia się w strumieniu. I strumień będzie dostępna. Więc to, co idzie w dół lub wraca się, co dzieje się pod spodem. To covers-- jest OK. W porządku, więc masz różne Zobacz typy na ekranie. Rodzaje zobacz, które są ważne dla programista zazwyczaj są, co to było? Mam stary pogląd. Gdy aktualizacja uderza w stół, to będziesz wcisnąć stary widok na strumień więc dane mogą archiwizować lub zmiany Kontrola, identyfikacja zmiany, zmiany zarządzanie. 

Nowy obraz, co jest teraz po aktualizacja, to inny rodzaj widzenia możesz dostać. Możesz uzyskać zarówno stare i nowe zdjęcia. Może chcę ich obu. Chcę zobaczyć, co to było. Chcę zobaczyć, co zmieniło się. 

Mam typ zgodności procesu, który działa. Wymaga to, aby sprawdzić, gdy zmiany te rzeczy, że są one w pewnych granicach lub w pewnych parametrów. 

A to może tylko ja trzeba wiedzieć, co się zmieniło. Nie obchodzi mnie, co poz zmieniło. I nie trzeba wiedzieć jakie atrybuty zmieniony. Muszę tylko wiedzieć, że produkty są dotykane. Więc to są typy widoków że wysiąść strumień i można wchodzić w interakcje z. 

Aplikacja, która zużywa strumienia, jest to swego rodzaju sposób to działa. Klient DynamoDB poprosić zapisywać dane do tabeli. Strumienie wdrożyć na to, co nazywamy odłamki. Odłamki są skalowane niezależnie od stołu. Nie kolejce całkowicie do rozbiorów tabeli. I dlatego jest bo w kolejce do mocy, prąd Zdolność tabeli. 

Wdrożyć je w ich własne auto grupa skalowanie, i zaczynają kręcić się w zależności na ile zapisy są w najbliższych, ile reads-- naprawdę to pisze. Nie ma reads-- ale jak wiele zapisy idą w. 

A następnie do tyłu koniec, mamy to, co mamy wezwać KCI, lub Kinesis biblioteki klienta. Kinesis jest strumień danych technologia przetwarzania z Amazon. I strumieni jest zbudowany na tym. 

Więc używać włączało KCL Aplikacja do odczytu strumienia. Kinesis Client Library rzeczywistości zarządza pracowników dla Ciebie. I to też robi niektóre interesujące rzeczy. Stworzy niektóre tabele się w DynamoDB tabel śledzić, które elementy zostały przetworzone. Więc w ten sposób, jeśli spada, jeśli nie przewraca, a przychodzi i dostaje cofnął się, może określić, gdzie było to w przetwarzanie strumienia. 

To bardzo ważne, gdy mówisz replikacji. Muszę wiedzieć, co Dane zostały poddane obróbce i co dane jest jeszcze przetworzony. Więc biblioteka KCL dla strumieni będzie daje dużo tej funkcji. Dba o wszystkich pracach domowych. Wyróżnia się pracownikowi za każdy odłamek. Tworzy tabelę administracyjnej za każdy odłamek, dla każdego pracownika. I jak te ognia pracowników, utrzymują tych tabel więc wiesz, ten rekord został odczytany i przetwarzany. A następnie w ten sposób, jeśli proces umiera i wraca on-line, może wznowić prawo, gdzie wystartował. 

Więc używamy to dla replikacji cross-region. Wielu klientów mają potrzebę przenosić dane lub części swoich tabel danych wokół różnych regionach. Istnieje dziewięć regionów na całym świecie. Więc nie może być need-- I może mieć użytkowników w Azji, użytkownicy na wschodnim wybrzeżu Stanów Zjednoczonych. Mają one różne dane musi być lokalnie rozłożone. A może użytkownik prostej od Asia nad do Stanów Zjednoczonych, i chcę powtórzyć jego dane z niego. Więc kiedy wysiada z samolotu, ma dobre doświadczenie przy użyciu swojego telefonu aplikację. 

Możesz używać cross-region Biblioteka replikacji, aby to zrobić. Zasadniczo mamy pod warunkiem, dwie technologie. Jeden to aplikacja konsoli można stanąć na własnych instancji EC2. Działa czysty replikacji. A potem dał ci biblioteki. W bibliotece można użyć do budowy własnej aplikacji, jeśli Ciebie chcę robić szalone rzeczy, które data-- Filtr, replikować tylko jego część, obrócić dane, otworzyć ją w tabela, tak dalej, i tak dalej. Tak, że to trochę, co to wygląda. 

DynamoDB strumieni może być przetwarzane przez to, co nazywamy Lambda. Wspominaliśmy już trochę o imprezy napędzane architektury aplikacji. Lambda jest kluczowym elementem tego. Lambda jest kod, który odpala na żądanie w odpowiedzi na określone zdarzenie. Jednym z tych wydarzeń może być zapis pojawia się w strumieniu. Jeśli w strumieniu pojawia się zapis, nazwijmy tę funkcję Java. Cóż, to jest JavaScript i Lambda obsługuje node.js, Java, Python, i wkrótce będzie wspierać inne języki, jak również. A wystarczy powiedzieć, że to czysty kod. Napisać W Javie można zdefiniować klasę. Naciśnięciu JAR górę do Lambda. A następnie określić, która klasa zadzwonić, w odpowiedzi na które zdarzenie. A następnie infrastruktura Lambda tyle, że będzie działał ten kod. 

Ten kod może przetwarzać Zapisy off strumienia. To może zrobić wszystko, co chce z nim. W tym konkretnym przykładzie, wszystkie jesteśmy naprawdę robi się zalogowaniu atrybuty. Ale to tylko kod. Kod może nic zrobić, prawda? 

Więc można obrócić te dane. Możesz utworzyć widok pochodny. Jeśli jest to struktura dokumentu, można spłaszczyć strukturę. Można tworzyć alternatywne indeksy. Wszystkie rodzaje rzeczy zdołasz zrobić z DynamoDB strumieni. 

A tak naprawdę, to co to wygląda. Więc masz te aktualizacje w najbliższych. Zbliżają się ciąg. Są one odczytywane przez funkcję lambda. Oni obracając dane i popychając go w tabelach pochodnych, zgłaszania systemów zewnętrznych zmian, i pchania danych do ElastiCache. 

Rozmawialiśmy o tym, jak umieścić pamięć podręczną przed bazy danych dla tego sprzedaży scenariusz. Cóż, co się stanie, jeśli aktualizować opis przedmiotu? Cóż, gdybym miał Lambda Funkcja działa na tej tabeli, jeśli aktualizować opis przedmiotu, to będziesz odebrać rekord off strumienia, i będzie ona zaktualizować ElastiCache wystąpienie z nowymi danymi. Tak, że bardzo dużo Co robimy z Lambda. Jest to kod klej, złącza. I faktycznie daje możliwość uruchamiania i działają bardzo złożonych aplikacji bez dedykowanego serwera infrastruktury, co jest naprawdę fajne. 

Więc wróćmy do naszego Architektura w czasie rzeczywistym głosu. Jest to nowe i ulepszone z naszym strumieni i KCL włączona obsługa aplikacji. Takie same jak wcześniej, możemy obsługiwać dowolną skalę wyborach. Lubimy to. Robimy się gromadzi scatter w wielu wiadra. Mamy zamek optymistyczne dzieje. Możemy zachować nasze wyborców zmianę głosu. Mogą głosować tylko jeden raz. To jest fantastyczne. W czasie rzeczywistym, odporność na uszkodzenia, skalowalne agregacja teraz. Jeśli coś się przewróci, to wie, gdzie uruchomi się ponownie kiedy wraca, bo używamy aplikacji KCI. A potem możemy również używać, Aplikacja KCL do pchania danych z do przesunięcia ku czerwieni dla innych Analityka aplikacji lub korzystanie Elastyczna MapReduce uruchomić czasie rzeczywistym transmisji strumieniowej skupiska off tych danych. 

To są rzeczy, my nie mówił o dużo. Ale są dodatkowe technologie, które pochodzą ponieść, jeśli szukasz w tych różnych sytuacjach. 

W porządku, więc to o Analytics DynamoDB strumieni. Można zbierać de duplikatem danych, nie wszystkie rodzaje miłych rzeczy, zagregowane dane w pamięci, tworzenia tych tabel pochodnych. To ogromny przypadek użycia że wielu użytkowników są zaangażowani, biorąc zagnieżdżona Właściwości tych dokumentów JSON i tworzenie dodatkowych indeksów. 

Jesteśmy na końcu. Dziękuję, mając ze mną. Więc porozmawiajmy o Architektura referencyjna. DynamoDB siedzi w środku, tak większość infrastruktury AWS. W zasadzie można go podpiąć do czegokolwiek chcesz. Aplikacje zbudowane przy użyciu Dynamo to Lambda, ElastiCache, CloudSearch, wcisnąć się do danych Elastic MapReduce, eksport import z DynamoDB do S3, wszelkiego rodzaju przepływów pracy. Ale chyba najlepszy co o tym mówić, i to jest to, co naprawdę ciekawe jest to, kiedy mówić o zastosowaniach zdarzeniami. 

Jest to przykład wewnętrzny projekt że mamy gdzie jesteśmy naprawdę publikowanie wyników badań w celu zebrania. Więc w linku e-mail wysyłamy, nie będziesz być trochę Link mówiąc kliknięcie tutaj, aby odpowiedzieć na pytania. A gdy ktoś kliknie linkujące, co się dzieje, jest to ciągnąć w dół bezpieczne HTML ankieta z S3. Nie ma serwer. To jest po prostu obiektem S3. 

Ta forma pojawia się, ładuje się w przeglądarce. To nie ma kręgosłupa. Ma kompleks JavaScript że to działa. Więc jest to bardzo bogata aplikacja działa w przeglądarce klienta. Oni nie wiedzą, że nie są one interakcji z tylnym end. W tym momencie, to wszystko jest przeglądarka. 

Opublikują wyniki do tego, co nazywamy Amazon API Gateway. API Gateway to po prostu API internetowej które można zdefiniować i podłączyć do tego, co chcesz. W tym konkretnym przypadku, że jesteśmy podłączona do funkcji lambda. 

Więc moja operacja POST jest dzieje się z żadnym serwerem. Zasadniczo, że API Brama tam siedzi. To nic nie kosztuje mnie aż do ludzi rozpocząć delegowania do niego, prawda? Funkcja lambda po prostu stoi. A to kosztuje mnie nic, dopóki ludzie zaczynają się ukryć, że. Dzięki czemu można zobaczyć, jak objętość wzrasta, wtedy opłaty przyjść. Nie uciekam serwer 7/24. 

Więc wyciągnij formę dół z wiadra, i pisać za pośrednictwem interfejsu API Brama do funkcji lambda. A potem Lambda Funkcja mówi, wiesz co, mam pewne PIIs, niektóre dane osobowe W tych odpowiedzi. Mam komentarzy pochodzących od użytkowników. Mam adresy e-mail. Mam nazw użytkowników. 

Pozwól mi podzielić tę opcję. Idę do generowania niektóre metadane przy tej płycie. I mam zamiar nacisnąć metadane na DynamoDB. I mógłbym zaszyfrować wszystkie dane i wsuń go do DynamoDB jeśli chcę. Ale jest to łatwiejsze dla mnie, w tym używać sprawy, śmiało się wypowiedzieć, Mam zamiar naciskać na surowych danych do zaszyfrowanego S3 wiadra. Więc używam zbudowany w stronie serwera S3 Zarządzanie kluczami szyfrowania i Amazon Usługi tak, że mam klucz obraca się w regularnych odstępach czasu, i mogę ochrony tych danych PII w ramach tej całej procedury. 

Więc co ja zrobiłem? Właśnie wdrożyć całość aplikacji, a ja nie mam serwera. Więc to, co zdarzeniami aplikacji Architektura robi dla Ciebie. 

Teraz, jeśli myślisz o w przypadku zastosowania do this-- mamy innych klientów mówię na temat tego dokładnym architektury, którzy uruchomić fenomenalnie duże kampanie, którzy patrząc na to i będzie, o mój. Bo teraz, mogą po prostu wcisnąć go tam, pozwól, że kampanię tylko siedzieć tam, dopóki nie uruchamia, a nie musiał martwić się rys na temat jaki rodzaj infrastruktury będzie tam, aby go wesprzeć. A następnie, gdy tylko że kampania jest zrobione, to jak na infrastrukturę po prostu od razu odchodzi bo nie bardzo ma infrastruktury. To tylko kod, który siedzi na Lambda. To tylko dane, które siedzi w DynamoDB. Jest to niesamowity sposób do tworzenia aplikacji. 

PUBLICZNOŚCI: Więc jest to bardziej efemeryczne niż byłoby to jeśli został zapisany na rzeczywistym serwerze? 

RICK HOULIHAN: Absolutnie. Bo tej instancji serwera musiałby być 7/24. To musi być dostępna dla ktoś odpowiedzieć. No wiecie co? S3 jest dostępny 24/7. S3 zawsze reaguje. S3 jest bardzo, bardzo dobry w obsługujących obiekty. Obiekty te mogą być pliki HTML, lub Pliki JavaScript, albo co chcesz. Możesz uruchomić bardzo bogatych aplikacji internetowych z wiader S3, i ludzie. 

A więc to pomysł tutaj jest uciec z drogi kiedyś o tym myśleć. Wszyscy wykorzystywane do myślenia Warunki serwerów i hostów. Nie chodzi o to, że już. Chodzi o infrastrukturę jako kod. Wdrażanie kod do chmury i niech chmura uruchomić go dla Ciebie. I to właśnie AWS próbuje zrobić. 

PUBLICZNOŚCI: Tak skrzynce złota w środku API serwer bramy nie jest podobny, ale zamiast tego jest just-- 

RICK HOULIHAN: Można myśleć o tym, jak fasady serwera. Wszystko to jest to zajmie HTTP żądania i mapować go do innego procesu. To wszystko, co robi. I w tym przypadku, mamy do mapowania go do funkcji lambda. W porządku, więc to wszystko, co mam. Dziękuję Ci bardzo. Doceniam to. Wiem, że chcemy się trochę w czasie. I miejmy nadzieję, że dostaliście trochę informacji że można zabrać dziś. I przepraszam, jeśli poszedłem na niektóre z waszych głowach, ale jest to dobry dużo podstawowej wiedzy fundamentalne że myślę, że jest bardzo cenne dla Ciebie. Więc dziękuję za zaproszenie. [OKLASKI] PUBLICZNOŚCI: [niesłyszalne] jest, kiedy mówiłeś trzeba było przejść przez coś od początku do końca aby uzyskać prawo wartości lub te same wartości, W jaki sposób wartości zmienić, jeśli [niesłyszalne]. 

RICK HOULIHAN: Och, idempotent? Jak wartości zmienić? No, bo jeśli nie uruchomić to aż do końca, to ja nie wiem, co się zmienia zostały wykonane w ostatniej mili. To nie będzie to same dane, co widziałem. PUBLICZNOŚCI: Oh, więc po prostu nie dostał całą wejście. RICK HOULIHAN: Racja. Trzeba przejść od początku do końca, a następnie jest będzie spójna. Fajne. 

PUBLICZNOŚCI: Więc pokazał nam DynamoDB może zrobić dokument lub wartość klucza. I spędziliśmy dużo czasu na wartość klucza z hash i sposobów aby obrócić go wokół. Kiedy spojrzał na tych stołach, jest to, że pozostawiając podejścia dokumentu? 

RICK HOULIHAN: Nie powiedzieć, pozostawiając w tyle. 

PUBLICZNOŚCI: one były oddzielone od the-- 

RICK HOULIHAN: Z dokumentu Podejście, typ dokumentu w DynamoDB jest po prostu myśleć jako innego atrybutu. Jest to atrybut, który zawiera hierarchiczna struktura danych. A następnie w zapytaniach można użyć właściwości z tych obiektów Object Notation wykorzystujących. Więc mogę filtrować zagnieżdżone Obiekt dokumentu JSON. PUBLICZNOŚCI: Więc za każdym razem mam zrobić podejście dokumentu, Mogę rodzaju przybyć tabular-- PUBLICZNOŚCI: Absolutnie. WIDOWNI: --indexes i rzeczy po prostu rozmawialiśmy. RICK HOULIHAN: Tak, indeksy i to wszystko, jeśli chcesz indeksować właściwości JSON, sposób, w jaki my mamy na to jest, jeśli wstawieniu obiektu JSON lub dokument w Dynamo, należy użyć strumieni. Strumienie czytał wejście. Można by się, że JSON obiektu i można by powiedzieć, OK, co jest własnością Chcę indeksu? 

Tworzenia tabeli pochodnych. Teraz to tak działa teraz. Nie dopuszczamy do indeksu bezpośrednio te właściwości. 

PUBLICZNOŚCI: Tabularizing dokumentów. 

RICK HOULIHAN: Dokładnie, spłaszczenie Opisz tabularizing go dokładnie. To, co z nim zrobić. 

PUBLICZNOŚCI: Dziękuję. 

RICK HOULIHAN: Tak, absolutnie, dziękuję. PUBLICZNOŚCI: Więc jest to rodzaj Mongo spełnia classifers REDIS. 

RICK HOULIHAN: Tak, to dużo tak. To dobry opis do niego. Fajne.