Udostępnij za pośrednictwem

  • Artykuł

          

Platforma Windows Azure - Azure Storage cz. 2

Udostępnij na: Facebook

Autor: Grzegorz Glonek

Opublikowano: 2011-05-23

Pobierz i uruchom

Wprowadzenie

Artykuł ten jest kontynuacją poprzedniego artykułu dotyczącego Azure Storage. Dla przypomnienia, usługa ta oferuje nam do wyboru trzy struktury danych, w których możemy przechowywać nasze informacje:

  • Blobs (binary large objects) – przechowują pliki binarne oraz tekstowe, często dużych rozmiarów. Dane umieszczone w ten sposób mogą zawierać dodatkowe metadane w postaci tagów reprezentujących np. opisy zdjęć,
  • Tables – tabele wykorzystywane do przechowywania danych o określonej strukturze. Nie należy ich mylić z tabelami relacyjnymi, które udostępniane są za pośrednictwem SQL Azure,
  • Queues – struktury będące kolejkami wykorzystywanymi do komunikacji asynchronicznej pomiędzy instancjami typu Web Role i Worker Role.

W poprzednim artykule znajduje się też szczegółowy opis struktury Blobs, natomiast w tym znajdują się informacje na temat dwóch pozostałych struktur.

Tables

Windows Azure Tables jest kolejną strukturą danych udostępnianą w ramach Windows Azure Storage. W porównaniu ze strukturą Blobs, jest ona bardziej złożona, co dobrze ilustruje rysunek 1.

Rys.1. Elementy składowe AzureTables.

Każda tabela zawiera przynajmniej jedną encję, która może posiadać swoje właściwości. Każda właściwość opisana jest przez trójkę Nazwa,Typ Danych,Wartość , gdzie poprzez Typ Danych rozumiemy takie typy, jak Bool, String, Double, Int itp. Nie istnieje żadne ograniczenie co do ilości wykorzystywanych właściwości, jednak istnieje ograniczenie wielkości pojedynczej encji ustalone na 1MB. Encja jest najmniejszą porcją danych, jaką możemy odczytać z tabeli i jest ona reprezentowana w aplikacji jako kolekcja właściwości. Taka ziarnistość danych sprawia, że chcąc dokonać aktualizacji wartości jednej właściwości, musimy przesłać i nadpisać całą kolekcję, nawet jeśli pozostałe właściwości się nie zmieniły. Oczywiście istnieje możliwość modyfikacji grupy właściwości w ramach pojedynczej transakcji. Dzięki temu, jeżeli aktualizacja wartości choćby jednej właściwości się nie powiedzie, żadna ze zmian w takiej grupie nie zostanie zapisana.

Tabele użyte w Azure Storage bywają czasami mylone przez programistów z tabelami relacyjnej bazy danych. Są one jednak znacząco od nich różne. Przede wszystkim nie mają wsparcia dla języka SQL, nie posiadają między sobą relacji, nie są oparte na żadnym silniku bazodanowym, a także nie posiadają z góry przypisanego schematu danych. Struktura oraz typy danych zastosowane w encjach mogą się zmieniać w trakcie działania aplikacji. Tabele Azure Storage należy w związku z tym traktować bardziej jako pewnego rodzaju pojemnik, ,,worek'' na dane posiadające jakieś właściwości, niż jako tradycyjną tabelę. Ponieważ pierwszym skojarzeniem z tabelami w Azure Storage są tabele z relacyjnych baz danych, można zastanawiać się, dlaczego są one od siebie tak różne. Powodem jest łatwość i szybkość skalowania kontenera danych wraz ze wzrostem zapotrzebowania na dane, a także filozofia działania całej platformy Windows Azure (również większości innych platform cloud computingowych). Aby móc korzystać z bazy danych, musi ona być uruchomiona za pomocą systemu zarządzania bazą danych zainstalowanego w systemie danej maszyny. Obsługa zwiększonej liczby użytkowników generujących zapytania do bazy danych wiąże się z ciągłym zwiększaniem mocy obliczeniowej komputera, na którym jest uruchomiona taka baza. Jest to oczywiście strategia skalowania scalling up, natomiast filozofia skalowania aplikacji na platformie Windows Azure to scalling out. Uproszczenie budowy tabel pozwala na łatwe zarządzanie nimi w obrębie wielu maszyn wirtualnych, a to przekłada się na wydajność w dostępie do danych przez wielu użytkowników równocześnie. Całością zarządza platforma Windows Azure, co zdejmuje z programisty obowiązek odpowiedniego rozmieszczenia tabel w trakcie ich tworzenia oraz zapewnienia mechanizmu dostępu do rozproszonych danych.

Problemem, jaki może powstać przy takim modelu, jest zapisywanie zaktualizowanych danych przez wielu użytkowników równocześnie. W takiej sytuacji możliwe są dwa scenariusze. Pierwszy opiera się na polu wersji encji i zakłada, że powiedzie się jedynie ta operacja zapisu danych, która zostanie wykonana jako pierwsza, kolejne zaś zwrócą błąd. Pole wersji zapewniane jest automatycznie przez Azure Storage. Takie podejście znane jest z systemów baz danych i nosi nazwę optimistic concurrency control (OCC). Drugim dozwolonym scenariuszem jest bezwarunkowe zapisywanie danych do tabeli. Wiąże się to z każdorazowym powodzeniem operacji zapisu danych, jednak kosztem nadpisania wcześniejszych danych przez nowsze.

Queues

Ostatnią strukturą danych dostępną w ramach Azure Storage są kolejki (queues). Przeznaczenie tej struktury jest odmienne od dwóch poprzednio opisanych, ponieważ nie jest ona przeznaczona do przechowywania danych w chmurze, lecz do realizowania wymiany danych pomiędzy instancjami typu Web Role i Worker Role. Analizując rysunek 2 możemy zobaczyć przykładowy scenariusz wykorzystania kolejek. Instancja Web Role, będąca np. usługą WCF, odbiera od użytkownika zlecenie wykonania czasochłonnej pracy (1), która powinna zostać wykonana w ramach Worker Role. Aby przekazać niezbędne dane pomiędzy usługami, są one umieszczane w kolejce (2), a następnie z niej odczytywane (3). Gdy instancja Worker Role odczyta komplet danych z kolejki, rozpoczyna pracę (4) oraz usuwa odczytane już dane z kolejki po zakończeniu obliczeń (5).

Rys.2.Przykładowe wykorzystanie kolejek Windows Azure.

Na podstawie tego scenariusza działania można zauważyć, że odczyt danych nie wiąże się z ich usunięciem z kolejki. Zamiast tego dane stają się niewidoczne na określony czas. Pozwala to zagwarantować wykonanie zleconej przez użytkownika pracy. Gdyby usunięcie danych nastąpiło wraz z ich odczytem, to w przypadku przerwania przetwarzania danych przez instancję Worker Role zlecona praca nie zostałaby nigdy wykonana, a użytkownik nie dostałby żadnego rezultatu. Ukrycie danych zapewnia, że jedno zlecenie nie będzie przetwarzane przez kilka instancji równocześnie, ale gdy upłynie wyznaczony czas, staną się one na nowo widoczne, co spowoduje, że nowa instancja będzie mogła wykonać tę zleconą pracę. Schemat taki będzie się powtarzał tak długo, aż jakaś instancja zakończy poprawnie swoje działanie, zwróci rezultat i wówczas będzie mogła definitywnie usunąć wykorzystane dane z kolejki. Do poprawnego działania komunikacji pomiędzy różnymi typami instancji kluczowe jest poprawne określenie limitu czasu, jaki może zająć przetwarzanie, tak aby jego przekroczenie jednoznacznie oznaczało błędne przerwanie przetwarzania przez Worker Role. Dodatkową cechą kolejek Azure Storage jest brak gwarancji kolejności przetwarzania danych.

Zarówno kolejki, jak i tabele Azure Storage są strukturami, które w pierwszym momencie mogą nieco mylić korzystających z nich programistów. Dzieje się tak dlatego, że z nazwy posiadają one odpowiedniki niedostosowane do pracy w chmurze, np. tabele w relacyjnych bazach danych lub kolejki w kolejkach wiadomości takich jak MSMQ, jednak ich działanie jest zdecydowanie odmienne. Dzięki temu dostępne są nowe struktury podobne do tych już istniejących, ale zapewniające łatwą i szybką skalowalność w realiach aplikacji przygotowanych dla chmur oraz gwarancję, że zlecona przez użytkownika praca zostanie wykonana.

Podsumowanie

W tym artykule poznaliśmy szczegółowo dwie struktury danych dostępnych w usłudze Azure Storage – Tables i Queues.

W kolejnym artykule znajdą się informacje o ostatnim module wchodzącym w skład komponentu Windows Azure, czyli o AzureFabric.

          

Grzegorz Glonek (MCP, MCTS)

Absolwent Wydziału Fizyki Technicznej, Informatyki i Matematyki Stosowanej Politechniki Łódzkiej. Uczestnik konkursu ImagineCup. Wraz z drużyną fteams zdobył w 2009 roku drugie miejsce na finałach światowych tego konkursu w kategorii Software Design : InteroperabilityAward oraz pierwsze miejsce w finałach krajowych kategorii Software Design w 2010 roku. Obecnie zatrudniony w polskim oddziale firmy Microsoft na stanowisku Software Development Engineer in Test.