Paweł Łukasiewicz
2023-11-10
Paweł Łukasiewicz
2023-11-10
Udostępnij Udostępnij Kontakt
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.

Zalety użycia DynamoDB

  • Usługa zarządzana przez Amazon: programiści nie muszą się martwić o konfigurację klastra rozproszonej bazy danych, zarządzanie bieżącymi operacjami, etc. Amazon zajmuje się obsługą wszystkich zawiłości związanych ze skalowaniem, partycjonowaniem i ponownym dzieleniem danych na więcej zasobów, aby spełnić wymagania dotyczące wydajność zapisu i odczytu;
  • Skalowalność: brak konieczności martwienia się o predefiniowane limity ilości danych, które każda tabela może przechowywać. Każda ilość danych może być przechowywana i pobierana. DynamoDB będzie automatycznie rozszerzać się wraz z ilością danych przechowywanych w tabeli;
  • Szybkość: DynamoDB zapewnia wysoką przepustowość przy bardzo niskich opóźnieniach. W miarę wzrostu zbioru danych opóźnienia pozostają stabilne dzięki rozproszonej naturze algorytmów rozmieszczenia danych;
  • Wysoka dostępność: DynamoDB replikuje dane w co najmniej 3 różnych centrach danych. System działa i dostarcza dane nawet w warunkach różnych awarii;
  • Elastyczność: DynamoDB umożliwia tworzenie tabel dynamicznych, tj. tabela może posiadać dowolną liczbę atrybutów (w tym atrybuty wielowartościowe);
  • Ekonomiczność: płacimy za to z czego korzystamy bez żadnych minimalnych opłat. Struktura cenowa jest prosta i łatwa do obliczenia. Musimy jednak zwrócić uwagę na limity zapisu i odczytu danych, które mogą znacznie podnieść sumaryczny koszty korzystania z DynamoDB.

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.