DynamoDB jest z nami od dłuższego czasu i pomimo rosnącej popularności dla części z nas logika kryjąca się za DynamoDB nie wydaje się być jasna. Wymaga od nas zmiany myślenia o strukturze danych, zmiany naszych przyzwyczajeń oraz dostosowania się do mocno wyznaczonych reguł. W swojej prezentacji Marcin postara się wytłumaczyć skąd biorą się różnice pomiędzy dobrze nam znanym światem SQL a światem NoSQL. Opowie również o tym, jak zacząć modelowanie tabel oraz czym są i do czego służą GSI.
6. “Amazon DynamoDB is a fully managed, serverless,
key-value NoSQL database designed to run high-performance
applications at any scale. DynamoDB offers built-in security,
continuous backups, automated multi-region replication,
in-memory caching, and data export tools.”
https://aws.amazon.com/dynamodb/
7. “Amazon DynamoDB is a fully managed, serverless,
key-value NoSQL database designed to run
high-performance applications at any scale. DynamoDB offers
built-in security, continuous backups, automated multi-region
replication, in-memory caching, and data export tools.”
https://aws.amazon.com/dynamodb/
8. “Amazon DynamoDB is a fully managed, serverless,
key-value NoSQL database designed to run
high-performance applications at any scale. DynamoDB
offers built-in security, continuous backups, automated
multi-region replication, in-memory caching, and data export
tools.”
https://aws.amazon.com/dynamodb/
9. “Amazon DynamoDB is a fully managed, serverless,
key-value NoSQL database designed to run high-performance
applications at any scale. DynamoDB offers built-in
security, continuous backups, automated multi-region
replication, in-memory caching, and data export tools.”
https://aws.amazon.com/dynamodb/
14. Model konsumpcji danych uległ gwałtownej zmianie. Systemy
IT przestały być domeną
wielkich korporacji, banków czy instytucji rządowych. Dostęp
do internetu, gwałtownie rosnąca ilość urządzeń oraz
ewolucja biznesu wymusza na nas o wiele większy i szybszy
przepływ danych.
16. Relacyjne bazy danych są zoptymalizowane do
przechowywania, wynika to z historycznie wysokiego kosztu
pamięci, a relatywnie niskiego kosztu CPU w czasach kiedy
bazy relacyjne powstawały.
17. DynamoDB jest zoptymalizowane do szybkiego odczytu. Ze
względu na odwrócenie trendu pomiędzy kosztem pamięci a
kosztem CPU, bardziej optymalnym podejściem jest
zmniejszenie kosztu “złożenia” danych, nawet jeśli odbywa
się to kosztem konsumowanej pamięci.
58. Z diagramu relacji encji, możemy zauważyć, że naszą główną
encją z której relacje wychodzą na zewnątrz jest User. Na
podstawie tego, rozsądnym będzie przyjąć, że Partition Key
będzie związany z użytkownikiem. W związku z tym
proponuję przyjąć następujący kształt Partition Key
USER#<USER_ID>
61. Każdy użytkownik posiada dokładnie 1 zestaw metadanych,
posiada jeden login, email, hasło, itp. Dodatkowo, jeśli uda
nam się zaproponować taką parę PK i SK którą będziemy w
stanie skonstruować przy zapytaniu będziemy mogli
pobrać danie zapytaniem GetItem
62. Tabela pozwalająca pobrać metadane
PK SK name email
USER#<USER_ID>
METADATA Marcin Mazurowski m.mazurowski@tsh.io
63. Dzięki odpowiedniej konstrukcji PK oraz SK udało nam się
zrealizować access pattern w najefektywniejszy sposób przy
użyciu zapytania GetItem. Nie spoczywajmy jednak na
laurach, mamy jeszcze kilka encji do zamodelowania!
64. Zrealizowane access patterny
1. Pobranie meta-danych użytkownika (zdjęcie
profilowe, imię, itp)
2. Pobranie przypisanych adresów użytkownika
3. Pobranie wszystkich przesyłek
4. Pobranie konkretnej przesyłki dla użytkownika
5. Pobranie zawartości dla przesyłki
6. Pobranie zdarzeń dla przesyłki
7. Pobranie zdarzeń oraz zawartości danej
przesyłki
8. Pobranie zarchiwizowanych przesyłek
66. W tego typu aplikacji, użytkownicy zazwyczaj mają
możliwość zdefiniowania więcej niż jednego adresu wysyłki
(Np. Dom oraz adres biura). W wypadku możemy skorzystać
z więcej niż jednej strategii:
1. Złożone pole przetrzymujące kilka wartości
2. Jeden element (Item) dla każdego adresu
67. Każdy element (Item) w DynamoDB jest ograniczony limitem
rozmiaru 400Kb. Limit ten jest jedną z form wymuszania na
deweloperach takiego designu tabeli aby operacje był jak
najbardziej efektywne. Jeśli przyjmiemy zasadę biznesową, że
użytkownik może mieć maksymalnie 3 adresy przypisane do
konta możemy bezpiecznie skorzystać ze strategii pola
złożonego, nie zawsze jednak można przyjąć takie założenie.
68. Tabela pozwalająca pobrać metadane oraz adresy
PK SK name email addresses
USER#<USER_ID
>
METADATA Marcin
Mazurowski
m.mazurowski@tsh.io {“Home”:{“street”:”ul.
Dolnych Wałów 8”}}
72. Ten przypadek użycia jest odrobinę ciekawszy niż poprzednie.
Po pierwsze dlatego, że każda przesyłka będzie mogła
zawierać wiele zdarzeń oraz wiele produktów. Odpowiednie
przemyślenie naszego SortKey pozwoli na efektywną
realizację access patternów.
74. Pobranie konkretnej przesyłki dla konkretnego
użytkownika
Dzięki konstrukcji SHIPMENT#<SHIPMENT_ID> będziemy w stanie otrzymać
konkretny shipment dla użytkownika przy użyciu operacji GetItem
75. Zrealizowane access patterny
1. Pobranie meta-danych użytkownika (zdjęcie profilowe, imię, itp)
2. Pobranie przypisanych adresów użytkownika
3. Pobranie wszystkich przesyłek
4. Pobranie konkretnej przesyłki dla użytkownika
5. Pobranie zawartości dla przesyłki
6. Pobranie zdarzeń dla przesyłki
7. Pobranie zdarzeń oraz zawartości danej przesyłki
8. Pobranie zarchiwizowanych przesyłek
79. Pobranie wszystkich przesyłek wraz ze zdarzeniami oraz
elementami przesyłki dla danego użytkownika
Dzięki takiej konstrukcji będziemy w stanie otrzymać konkretną przesyłkę dla
użytkownika, jej zawartość oraz wszystkie zdarzenia przypisane do przesyłki przy
użyciu operacji Query. Aby osiągnąć ten cel skorzystamy z Key Condition
Expression. A dokładnie BEGINS_WITH = SHIPMENT#<SHIPMENT_ID>
80. Pobranie wszystkich zdarzeń dla przesyłki
Dzięki konstrukcji PK = SHIPMENT#<SHIPMENT_ID> będziemy w stanie otrzymać konkretną
przesyłkę dla użytkownika oraz wszystkie zdarzenia i elementy przypisane do przesyłki przy użyciu
operacji Query.
Aby osiągnąć ten cel skorzystamy z Key Condition Expression. A dokładnie BEGINS_WITH =
SHIPMENT#<SHIPMENT_ID>EVENT#
81. Zrealizowane access patterny
1. Pobranie meta-danych użytkownika (zdjęcie profilowe, imię, itp)
2. Pobranie przypisanych adresów użytkownika
3. Pobranie wszystkich przesyłek
4. Pobranie konkretnej przesyłki dla użytkownika
5. Pobranie zawartości dla przesyłki
6. Pobranie zdarzeń dla przesyłki
7. Pobranie zdarzeń oraz zawartości danej przesyłki
8. Pobranie zarchiwizowanych przesyłek
82. Finalna propozycja głównej tabeli
PK SK <attrybuty>
USER#<US
ER_ID>
METADATA
SHIPMENT#<SHIPMENT_ID>
SHIPMENT#<SHIPMENT_ID>SHIP_ITEM#<ITEM_ID>
SHIPMENT#<SHIPMENT_ID>EVENT#<EVENT_ID>
84. W niektórych sytuacjach może zdarzyć się, że nie będziemy w
stanie zrealizować naszego access patternu bezpośrednio na
głównej tabeli. Ciekawą strategią do wydzielenia części
większego zbioru rekordów jest zastosowanie GSI oraz
dodanie atrybutu który będzie występował tylko rekordach
danego typu.
85. Stworzenie atrybutów użytych w GSI do wydzielenia encji po jej
typie
PK SK GSI1PK GSISK
USER#<
USER_I
D>
METADATA
SHIPMENT#<SHIPMENT_ID>
SHIPMENT#<SHIPMENT_ID>SHIP_ITEM#<ITE
M_ID>
USER#1 TYPE#SHIPMENT
SHIPMENT#<SHIPMENT_ID>EVENT#<EVENT_
ID>
86. Zrealizowane access patterny
1. Pobranie meta-danych użytkownika (zdjęcie profilowe, imię, itp)
2. Pobranie przypisanych adresów użytkownika
3. Pobranie wszystkich przesyłek
4. Pobranie konkretnej przesyłki dla użytkownika
5. Pobranie zawartości dla przesyłki
6. Pobranie zdarzeń dla przesyłki
7. Pobranie zdarzeń oraz zawartości danej przesyłki
8. Pobranie zarchiwizowanych przesyłek
87. Stworzenie atrybutów użytych w GSI do wydzielenia encji po jej
typie oraz statusie
PK SK GSI1PK GSISK
USER#<
USER_I
D>
METADATA
SHIPMENT#<SHIPMENT_ID>
SHIPMENT#<SHIPMENT_ID>SHIP_ITE
M#<ITEM_ID>
USER#1 TYPE#SHIPMENT#STATUS#ARCHIVED
SHIPMENT#<SHIPMENT_ID>EVENT#<
EVENT_ID>
89. Podczas tworzenia GSI będziemy mieli możliwość wybrania
atrybutów które zostaną dodane do indeksu.
Dobrą praktyką jest ograniczenie ich tylko do tych z których
rzeczywiście korzystamy. Analogicznie do unikania SELECT *
FROM table
90. Poprzez złożenie SK w naszym GSI stwarzamy sobie
możliwość do pobrania nie tylko wszystkich przesyłek, ale
również odfiltrowanie ich po ich stanie (aktywna /
zarchiwizowana)
91. Udało nam się zrealizować wszystkie access patterny! Ale czy
na tym koniec naszej pracy? Prawdopodobnie nie, model aby
w pełni realizować potrzeby biznesu musi ewoluować i z
pewnością tak też będzie się działo. Warto planować access
patterny z różnych perspektyw i dostarczyć sobie
wystarczającą ilość możliwości.