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.
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.
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
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.
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.
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.
Photo by Shahadat Rahman on Unsplash
Maciej Gos
真诚赞赏，手留余香
使用微信扫描二维码完成支付
comments powered by Disqus