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.

1. Modelowanie danych w DynamoDB
Single Table Design, efektywnie skalowalna warstwa persystencji

2. $ whoami
Senior Node.js Developer
Serverless & DynamoDB = ❤

3. Czym jest DynamoDB?

4. Baza danych która powstała z miłości

5. Miłości do pieniędzy

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/

10. Dlaczego potrzebujemy DynamoDB?

11. Co się dzieje z RDSem przy pewnej skali...

13. Dlaczego?

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.

15. Dlaczego DynamoDB oferuje większą wydajność
niż baza relacyjna?

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.

18. Co gdybyśmy mogli trzymać wszystkie
encje w jednej tabeli?

19. Co więcej, dostać się do niezbędnych encji
przy użyciu jednego zapytania?

21. Odpowiedzią na powyższe pytania jest Single
Table Design!

22. Przydatne narzędzia

23. 1. Kartka i papier (lub dowolny soft do tworzenia
diagramów).

24. 1. Kartka i papier (lub dowolny soft do tworzenia
diagramów).
2. NoSQL WorkBench

25. 1. Kartka i papier (lub dowolny soft do tworzenia
diagramów).
2. NoSQL WorkBench
3. Konto AWS

26. Rozpoczęcie budowania modelu

28. Nah, jeszcze nie to!

29. 1. Zrozumienie potrzeb aplikacji

30. 1. Zrozumienie potrzeb aplikacji
2. Stworzenie uproszczonego ERD

31. 1. Zrozumienie potrzeb aplikacji
2. Stworzenie uproszczonego ERD
3. Stworzenie access patternów

32. 1. Zrozumienie potrzeb aplikacji
2. Stworzenie uproszczonego ERD
3. Stworzenie access patternów
4. <tajny składnik nr 1>

33. 1. Zrozumienie potrzeb aplikacji
2. Stworzenie uproszczonego ERD
3. Stworzenie access patternów
4. <tajny składnik nr 1>
5. <tajny składnik nr 2>

34. Przykład aplikacji do
śledzenia przesyłek

35. 1. Zrozumienie potrzeb aplikacji

36. Przykłady funkcjonalności

37. Główną wartością dostarczaną przez aplikację jest
możliwość śledzenia zamówionych przesyłek.

38. Jako użytkownik, chcę mieć możliwość
poznać status mojej przesyłki.

39. Jako użytkownik chcę móc nadać przyjazną nazwę
przesyłki

40. Jako użytkownik chcę wiedzieć kiedy archiwalna
przesyłka została dostarczona

41. Jako użytkownik chcę móc zmienić swoje dane w
profilu (dark-mode, email do powiadomień, itp.)

42. 1. Zrozumienie potrzeb aplikacji
2. Stworzenie uproszczonego ERD

44. 1. Zrozumienie potrzeb aplikacji
2. Stworzenie uproszczonego ERD
3. Stworzenie access patternów

45. 1. Zrozumienie potrzeb aplikacji
2. Stworzenie uproszczonego ERD
3. Stworzenie access patternów
4. Stworzenie access patternów

46. 1. Zrozumienie potrzeb aplikacji
2. Stworzenie uproszczonego ERD
3. Stworzenie access patternów
4. Stworzenie access patternów
5. Stworzenie access patternów

48. 1. Pobranie meta-danych użytkownika (zdjęcie profilowe, imię, itp)

49. 1. Pobranie meta-danych użytkownika (zdjęcie profilowe, imię, itp)
2. Pobranie przypisanych adresów użytkownika

50. 1. Pobranie meta-danych użytkownika (zdjęcie profilowe, imię, itp)
2. Pobranie przypisanych adresów użytkownika
3. Pobranie wszystkich przesyłek

51. 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 zawartości dla przesyłki

52. 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 zawartości dla przesyłki
5. Pobranie zdarzeń dla przesyłki

53. 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 zawartości dla przesyłki
5. Pobranie zdarzeń dla przesyłki
6. Pobranie zdarzeń oraz zawartości danej przesyłki

54. 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 zawartości dla przesyłki
5. Pobranie zdarzeń dla przesyłki
6. Pobranie zdarzeń oraz zawartości danej przesyłki
7. Pobranie zarchiwizowanych przesyłek

55. Najważniejszym krokiem przy modelowaniu jest wybór
odpowiedniego PK oraz SK!

56. Rozpoczynamy modelowanie od “korzenia”

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>

59. Kształt tabeli po zdefiniowaniu PK
PK SK
USER#<USER_ID>

60. Użytkownik oraz jego meta dane

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

65. Relacja jeden do wielu pomiędzy użytkownikiem a jego
adresami

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”}}

69. Świetnie!
Dzięki wykorzystaniu strategii pola złożonego, możemy
pobrać adresy dzięki wykorzystaniu zapytania GetItem.

70. 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

71. Relacja jeden do wielu pomiędzy użytkownikiem a przesyłkami

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.

73. Propozycja uwzględniająca encję Shipment
PK SK <attrybuty>
USER#<US
ER_ID>
METADATA
SHIPMENT#<SHIPMENT_ID>

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

76. Relacja jeden do wielu pomiędzy przesyłką, a jej zawartością

77. Relacja jeden do wielu pomiędzy przesyłką, a jej zdarzeniami

78. Propozycja uwzględniająca encję Shipment
PK SK <attrybuty>
USER#<US
ER_ID>
METADATA
SHIPMENT#<SHIPMENT_ID>
SHIPMENT#<SHIPMENT_ID>SHIP_ITEM#<ITEM_ID>
SHIPMENT#<SHIPMENT_ID>EVENT#<EVENT_ID>

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>

83. Global Secondary Index

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>

88. Przykładowy widok GSI
PK SK Atrybuty
USER#1 TYPE#SHIPMENT#STATUS#ARCHIVED

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.

92. Warto poczytać:
1. https://www.dynamodbguide.com/
2. https://www.alexdebrie.com/
3. https://github.com/alexdebrie/awesome-dynamodb/
4. https://dynobase.dev/dynamodb-tutorials/

93. Dzięki!
LinkedIn: marcinmazurowski
Mail: marcin.mazurowski@tsh.io