Wzorce projektowe Azure Table Storage z przykładami, oraz co powinniśmy wiedzieć – część 3

Każda aplikacja niezależnie czy działa w chmurze czy lokalnie potrzebuje Po długiej nieobecności jest to kolejny artykuł o wzorcach projektowych Azure Table Storage (ATS), które są rekomendowane przez Microsoft.

A więc przejdźmy do konkretów.

Table storage automatycznie indeksuje kolumny PartitionKey i RowKey dzięki temu wyszukiwanie po nich jest szybkie i efektywne. Co w sytuacji gdy nasze dane stają się bardziej skomplikowane? Tutaj z pomocą przychodzą nam wzorce projektowe dla Table Storage.

Przejdźmy przez kilka z nich i zobaczmy jakie mają cechy, kiedy je stosować, oraz jakie mają wady.

Jako nasz przykład wykorzystamy Contoso Movies Library ;). Jest to aplikacja do przechowywania bazy filmów umożliwiająca wyszukiwanie z wykorzystaniem różnych filtrów, oraz kupowanie bądź wypożyczanie filmów on-demand.

Log tail pattern

Problem do rozwiązania

Zapewne znacie takie „podejście” w programowaniu jak Event Sourcing. W moim odczuciu doskonale tutaj odnajdzie się Log tail pattern. W skrócie chcemy prześledzić w naszej aplikacji/systemie wszystkie stany pośrednie danego obiektu.

W naszym konkretnym przypadku będą to stany związane z danym filmem.  Nasz system ma możliwość wypożyczenia bądź zakupu filmu i chcielibyśmy się dowiedzieć jakie kroki wykonuje użytkownik, oraz w którym kroku opuszcza proces zakupu/wypożyczenia.

Rozwiązaniem naszego problemu jest zapisywanie danych w tabeli z RowKey, który naturalnie posortuje dane w odpowiedniej kolejności od najnowszego do najstarszego „stanu”.

Przykład

Użytkownik decyduje się na zakup lub wypożyczenie filmu. W tej sytuacji akcja podjęta przez użytkownika uruchamia serie zdarzeń które znajdują odzwierciedlenie w „stanie” encji w systemie.

log-tail-pattern-example

Jakie mogą pojawić się problemy

Należy zwrócić szczególną uwagę na:

  • limity skalowalności tabeli w ramach pojedynczej partycji
  • usuwać z RowKey zera poprzedzające wartość

High volume delete pattern

Problem do rozwiązania

Wiele aplikacji ma wymaganie usuwania lub archiwizacji „starych” danych w systemie.

Tego typu wymagania mogą się pojawić w sytuacji tworzenia różnego rodzaju logów. Przychodzi tutaj z pomocą tytułowy wzorzec High volume delete pattern. W ramach wykorzystania tego wzorca chcemy mieć możliwość szybkiego usunięcia całej tabeli gdy jej dane nie są już nam dłużej potrzebne.

Rozwiązaniem tego problemu jest przechowywanie danych w oddzielnych tabelach per dzień (zależnie od szczegółowego wymagania). Dzięki takiemu podejściu jesteśmy w stanie wykonać usunięcie jednej tabeli wraz ze wszystkimi danymi które nie są już nam potrzebne.

Przykład

W ramach naszego systemu chcemy zbierać informacje jakie filmy są dodawane każdego dnia do systemu. W tym celu tworzymy tabelę z filmami per dzień z podziałem na kategorie filmów.

Jakie mogą pojawić się problemy

Musimy zwrócić szczególną uwagę na:

  • czas potrzebny na utworzenie tabeli
  • może pojawić się opóźnienie gdy próbujemy wykorzystać ponownie tą samą nazwę tabeli
  • problemem może być również wyszukiwanie danych w takiej strukturze

Data series pattern

Problem do rozwiązania

Typowym problemem w aplikacjach jest kwestia zbierania dużej ilości danych, które chcemy później pobrać jednym prostym zapytanie.

W naszej aplikacji takim przykładem może być zbieranie danych statystycznych na temat typu operacji w danej godzinie.

Rozwiązaniem tego problemu będzie zapisywanie operacji gdzie nasz PartitionKey będzie typem operacji, natomiast RowKey będzie to godzina jej wykonania.

Przykład

W naszym przykładzie zapisujemy dane statystyczne na temat częstotliwości wykonywania danej operacji w każdej godzinie.

data-series-pattern-example

Jakie mogą pojawić się problemy

Musimy zwrócić szczególną uwagę na:

  • ograniczenie do 252 kolumn dla każdej encji
  • konieczność wykorzystania ETag do implementacji optimistic-concurency

Wide entities pattern

Problem do rozwiązania

Nasza encja ma więcej niż 252 kolumny lub też zajmuje więcej niż 1 MB danych.

Problem ten możemy rozwiązać poprzez „skalowanie” naszej encji na dwie oddzielne tabele lub też w ramach jednej tabeli poprzez użycie różnych Row Key np. z prefix-em.

Przykład

wide-entities-pattern-example

Jakie mogą pojawić się problemy

Należy zwrócić szczególną uwagę na fakt, że do pobrania pojedynczej encji musimy wykonać conajmiej dwie oddzielne transakcje na naszym Storage Account.

Large entities pattern

Problem do rozwiązania

Wzorzec dobry do wykorzystania gdy chcemy przechować obiekty, które zajmują więcej niż 1MB danych np. zdjęcia. Wtedy we właściwości naszego obiektu podajemy tylko URL do adresu w naszym Blob Storage.

Przykład

Nasza aplikacja powinna przechowywać okładkę lub plakat filmu.

large-entities-pattern-example

Jakie mogą pojawić się problemy

Należy zwrócić szczególną uwagę na:

  • konieczność wykonania dwóch transakcji  na naszym Storage Account wykorzystującym Table Storage, oraz Blob Storage
  • zarządzanie integralnością danych

Prepend/append anti-pattern

Problem do rozwiązania

Chcemy w naszym systemie szybko dodać dużą ilość danych. Jest to typowy scenariusz np. podczas ładowania danych z wykorzystaniem „offline batch”.

Rozwiązaniem tego problemu będzie ładowanie danych z wykorzystaniem różnych PartitionKey. Pozwoli to nam uniknąć tzw. hotspot, czyli uniemożliwienia usłudze odpowiednio skalować i dokonać ich replikacji danych pomiędzy node-ami.

Przykład

Nasz system powinien umożliwiać import za pomocą batch działających offline danych. Takie podejście może spowodować po stronie Table Storage konieczność zapisania wielu rekordów w tym samym czasie i w tej samej partycji.

prepare-append-pattern-example

Jakie mogą się pojawić problemy

Należy zwrócić szczególną uwagę na:

  • sposób implementacji PartitionKey aby nie napotkać na problemu skalowalności pojedynczej partycji
  • jak zostanie zaimplementowany PartitionKey w kontekście naszej aplikacji i wykorzystania go

Log data anti-pattern

Problem do rozwiązania

Aplikacja powinna logować swoje działanie pozwalając na jej monitorowanie na produkcji.

Azure Table Storage nie jest rozwiązaniem dedykowanym logowaniu dużej ilości danych z tego względu  rekomendowanym rozwiązaniem jest wykorzystanie Storage Analytics lub Blob Storage.

Podsumowanie

A więc dotarliśmy do końca serii o wzorach Azure Table Storage. Napisanie ostatniej część zajęło mi najwięcej czasu i było pełne wzlotów i upadków. Mam nadzieję, że ta seria będzie dla wszystkich czytających pełna wskazówek, oraz pomocna w ich codziennej pracy.

W mojej ocenie takie proste i zarazem tanie rozwiązanie jakim jest ATS jest bardzo fajnym narzędziem, które można wykorzystać w wielu projektach działający w chmurze Azure.

Share