Wstęp
DynamoDB to w pełni zarządzalna usługa bazodanowa NoSQL, która pozwala na tworzenie tabel bazodanowych,
które mogą przechowywać i pobierać dowolną ilość danych. Usługa ta automatycznie zarządza ruchem w tabelach na wielu serwerach i utrzymuje stałą wydajność.
Podejście takie uwalnia programistów/architektów od obciążeń związanych z obsługą i skalowaniem rozproszonej bazy danych.
Podobnie również jak w przypadku instancji EC2, Amazon dostarcza sprzęt, konfigurację,
replikację danych, automatyczne aktualizacje oprogramowania czy skalowanie klastra.
DynamoDB vs RDMBS
Z poprzedniego akapitu możemy dowiedzieć się, że DynamoDB pozwala na tworzenie baz danych zdolnych do
przechowywania i pobierania dowolnej ilości danych oraz obsługi dowolnej ilości ruchu. Automatyczne rozdzielanie danych i ruchu na serwerze pozwala na
dynamiczne zarządzanie żądaniami każdego klienta zachowując przy tym wysoką wydajność. Zanim jednak przejdziemy dalej spójrzmy jeszcze na główne różnice
pomiędzy DynamoDB (NoSQL - model nierelacyjny) do modelu dobrze znanego
każdemu z nas, tj. RDBMS:
Typowe zadanie |
DynamoDB |
RDBMS |
Połączenie ze źródłem danych |
Żądanie HTTP i operacje przy wykorzystaniu API |
Trwałe połączenie i polecenia SQL |
Tworzenie tabeli |
Wykorzystanie jedynie klucza głównego. Brak schematu podczas tworzenia tabeli. Możliwe różne źródła danych |
Tworzenie tabeli wymagana definicji zgodnie ze standardami |
Informacje o tabeli |
Dostęp jedynie do kluczy głównych |
Wszystkie informacje są dostępne |
Ładowanie danych tabeli |
Wykorzystuje elementy złożone z atrybutów |
Wykorzystuje wiersze złożone z kolumn |
Odczyt danych tabeli |
Użycie metod: GetItem, Query oraz Scan
|
Polecenie SELECT połączone z instrukcjami filtrowania
|
Zarządzanie indeksami |
Wykorzystanie indeksu wtórnego. Wymagana definicja klucza partycji (partition key) oraz
klucza sortowania (sort key)
|
Wykorzystuje standardowe indeksy tworzone za pomocą instrukcji SQL. Modyfikacje następują
automatycznie w wyniku zmian tabeli
|
Modyfikacja danych |
Operacja UpdateItem |
Instrukcja UPDATE |
Usunięcie danych |
Operacja DeleteItem |
Instrukcja DELETE |
Usunięcie tabeli |
Operacja DeleteTable |
Instrukcja DROP TABLE |
Jak doskonale widzicie mamy sporo różnic na poziomie koncepcyjnym – dlatego postanowiłem poświecić osobny cykl związany z DynamoDB.
Zalety DynamoDB poznaliśmy we wstępie do tego wpisu. Zaliczamy do nich (głównie) skalowalność oraz elastyczność,
brak wymuszenia korzystania z konkretnego źródła danych czy samej jej struktury. Warto również pamiętać o wsparciu wielu języków i prostej
integracji przez API dla C#, Javy,
PHP czy Pythona.
Zalety, zaletami, ale… musimy mieć jakieś wady i ograniczenia, prawda? Tak, jest ich całkiem sporo, ale niekonieczne generują ogromne problemy czy
utrudniają rozwój aplikacji. Owszem, jeżeli podstawowe koncepty nie będą nam znane prędzej czy później wpędzimy się w kłopoty – zwłaszcza wraz z
rosnącą liczbą klientów naszej aplikacji. Z drugiej strony problem ten dotyczy każdej technologii, z którą się spotykamy. Spójrzmy zatem na ograniczenia,
które musimy mieć zawsze na uwadze pracując z DynamoDB.
Ograniczenia
Poniższa lista zawiera szereg ograniczeń, które warto mieć na uwadze korzystając z DynamoDB:
-
rozmiary jednostek pojemności - jednostka pojemności odczytu to pojedynczy spójny odczyt na sekundę dla
elementów nie większych niż 4KB. Jednostka pojemności zapisu to pojedynczy zapis na sekundę dla elementów nie większych niż 1KB.
Analogicznie, jeżeli zajdzie potrzeba zapisaniu elementu większego niż 1KB dojdzie do zużycia dodatkowych jednostek zapisu.
Więcej o tym zagadnieniu możecie poczytać tutaj:
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html
– w
późniejszych wpisach będę oczywiście poruszał ten wątek;
-
minimalna/maksymalna przepustowość - wszystkie tabele oraz globalne indeksy wtórne mają co najmniej jedną jednostkę
przepustowości odczytu i jedną jednostkę przepustowości odczytu. Maksymalne wartości zależą od regionów. Zastanawiacie się pewnie co nas czeka jak przekroczymy (ustalone)
wartości? Porozmawiamy o tym później ale w między czasie możecie spojrzeć na zagadnienie:
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html -
narazie lecimy przez podstawy, na trudniejsze zagadnienia (oraz ich rozwiązania) przyjdzie czas w kolejnych wpisach;
-
zwiększanie i zmniejszanie przepustowości - zwiększanie przepustowości może odbywać się tak często jak to koniecznie.
Zmniejszanie z kolei do 4 razy dziennie w obrębie danej tabeli. Jest to zagadnienie niezwykle istotne z perspektywy kosztów a odpowiednia konfiguracji tabeli
zależy od sposobu zużycia zasobów. W szczegóły wejdziemy nieco później ale monitorowanie danej tabeli jest niezwykle ważne z kilku perspektyw, m.in klienta i
jego dostępu do danych oraz kosztów generowanych przez wykorzystanie danej tabeli;
-
rozmiar i ilość tabel w obrębie konta - rozmiary tabel są nieograniczone ale konta mają limit do 256 tabel – o ile nie
poprosimy o wyższy limit;
-
indeksy pomocnicze na tabelę - dozwolona liczba to 5 indeksów lokalnych oraz 20 indeksów globalnych. Każdemu z
powyższych indeksów poświęcę osobny wpis ponieważ zagadnienia te są niezwykle ważne z perspektywy szybkości dostępu do danych;
-
atrybuty indeksów pomocniczych - ograniczeniem jest 20 atrybutów. Czym są te atrybuty? Jest to koncepcja,
która pozwala na użycie alternatywnych kluczy w operacjach Query oraz Scan.
Użycie klucza podstawowego jest co prawda najskuteczniejszym sposobem pobierania danych, który pozwala uniknąć korzystania z operacji skanowania ale jego
użycie związane ograniczone jest wzorcami dostępu do tabeli – więcej o tym w kolejnych wpisach;
-
długość i wartość klucza partycji - minimalna długość to 1 bajt, maksymalna 2048 bajtów.
DynamoDB nie wprowadza jednak ograniczenia wartości. Musimy jednak pamiętać, że DynamoDB
przechowuje i pobiera każdy element na podstawie wartości klucza podstawowego, która musi być unikalna;
-
długość i wartość klucza sortowania - minimalna długość wynosi 1 bajt, maksymalna 1024 baty.
Brak limitu wartości o ile tabela nie korzysta z lokalnego indeksu wtórnego. Klucz podstawowy jednoznacznie identyfikuje każdy element w tabeli.
Klucz ten może składać się nie tylko z klucza partycji ale również klucza sortowania. Dobrze zaprojektowane klucze sortowania mają dwie kluczowe zalety:
-
gromadzą powiązane informacje w jednym miejscu, z którego możemy je efektywnie odpytywać. Dobrze przemyślane wykorzystanie klucza sortowania
pozwala pobierać często potrzebne grupy powiązanych elementów za pomocą zapytań z określonymi operatorami takimi jak:
begins_with, between, >, <, itd;
- złożone klucze sortowania pozwalają zdefiniować hierarchie (relacje jeden do wielu w danych), które możemy przeszukiwać na dowolnym poziomie hierarchii;
-
nazwy tabeli i indeksów wtórnych - nazwy muszą się składać z minimum 3 znaków a maksymalnie 255.
Dozwolone znaki to: A-Z, a-z, 0-9, "_", "-", ".";
-
nazwy atrybutów - jeden znak to absolutne minimum, z kolei maksium to 64KB. Tutaj wyjątkami są klucze i niektóre atrybuty,
ale o tym więcej w osobnych wpisach;
- zarezerwowane słowa - brak ograniczeń w użyciu słów zarezerwowanych przy tworzeniu nazw;
-
długość wyrażeń - wyrażenia mają limit określony na poziomie 4KB. Wyrażenia atrybutów to limit 255 bajtów.
Zmienne zastępcze w wyrażeniu mają limit 2MB.
Jeżeli jakieś zagadnienia nie zostały opisane wystarczająco dobrze, zachęcam do spojrzenia do oficjalnej dokumentacji AWS.
Podobnie jak w poprzednich wpisach staram się zamieszczać jedynie podstawowe informacje a wraz z kolejnymi artykułami w danym cyklu będziemy rozszerzać ich znaczenie.
Gdybyśmy chcieli się skupić na wypisaniu ograniczeń oraz opisaniu konkretnych wymagań ten wpis byłby zdecydowanie zbyt długi i trudno byłoby przez niego przebrnąć.
W kolejnym wpisie zapoznamy się z podstawowymi komponentami DynamoDB oraz samym ekosystemem w którym pracujemy z tabelami,
atrybutami oraz poszczególnymi elementami, spojrzymy nieco szerzej na pojęcie klucza głównego i indeksu wtórnego oraz spojrzymy na przepustowość tabeli.