
Repozytorium w chmurze – NoSQL
Wprowadzenie
Coraz częściej czytamy o środowiskach „chmurowych” (nadal nie mogę się przekonać do pisania tego bez cudzysłowu). Nawet tak zaawansowane jak Amazon WS czy AZURE, są nadal bardzo często wykorzystywane tylko jako hosting aplikacji. Oba te serwisy można wykorzystywać jako sieciowy dysk, środowisko systemowe (Windows, Linux), bazę danych SQL, ale także jako bazy NoSQL.
Jednym z najistotniejszych elementów systemów informacyjnych (patrz: information science) jest utrwalanie danych (pamiętajmy, że dane to zapisy, a informacja to to, co rozumie człowiek, który je czyta). Niedawno nawiązywałem do problemu utrwalania danych.

Poprawna obiektowa architektura i kompletny projekt techniczny aplikacji (model PIM) opisuje precyzyjnie jak wykonać implementacje i nie zawiera projektu żadnej bazy danych, ani tym bardziej zapytań SQL. Implementacja utrwalania nie może mieć wpływu na logikę biznesową systemu ani nawet zawierać jej! (źr.: Dokument a kumulacja faktów: OOAD i model dziedziny systemu) Prosty diagram po lewej stronie pokazuje problem opisany przez Smith’a jako „Computers, Models, and the Embedding World, The Limits of Correctness.”
Komputer (rozumiany jako procesor, pamięć i program) stanowi dla człowieka narzędzie pracy.
Cechą komputera jest w ogromnej większości przypadków odwzorowywanie tego co zastępujemy komputerem, a tak zwane systemy biznesowe, zastępują papierowe formy przetwarzania i przechowywania informacji. Systemy ERP, CRM, Workflow, Sklepy internetowe, Archiwa, i wiele innych to tak na prawdę dokumenty i ich treść.
Istota problemu polega na tym, że określone, dostępne technologie same z siebie często stwarzają ograniczenia tego co mogą (potrafią) odwzorować, i mimo upływu czasu i postępu technologii, analiza i projektowanie zarządzania informacją nadal jest jednym z największych problemów wdrożeń systemów.
SQL vs. NoSQL
SQL
Skrót NoSQL jest intepretowany jako „nie SQL” lub „nie tylko SQL” (Not only SQL). SQL (Structured Query Language) to język zapytań do baz danych o relacyjnym modelu danych (ang. RDBMS: Relational Data Base Management System). Cechą tego modelu danych jest usuwanie redundancji i podział danych na tabele i słowniki pól tych tabel, oraz związki między nimi (relacje). W efekcie otrzymujemy schematy tabel i relacji między nimi np. takie:

A nawet takie:

Odtworzenie dokumentu (formularza) będącego np. fakturą lub deklaracją podatkową, wymaga wykonania szeregu bardzo skomplikowanych operacji łączenia danych z tych tabel i odwzorowania ich pierwotnej postaci np. faktury. W tego typu bazach danych fizycznie nie ma żadnych dokumentów.
Drugim problemem jaki stwarza model relacyjny, jest konieczność jego przebudowy praktycznie zawsze, gdy zmieni się struktura przechowywanych w nim dokumentów (opracowanie nowego modelu, migracja danych do nowego modelu – bywa że niemożliwa w 100%, aktualizacja zapytań SQL do nowej struktury bazy danych).
Biorąc pod uwagę fakt, że realny świat to ciągłe zmiany, model relacyjny jest w tym przypadku po prostu nieadekwatny.
Koszty utrzymania i rozwoju systemów zarzadzania danymi (i aplikacjami, które je wykorzystują) w modelu relacyjnym, są wielokrotnie wyższe niż pierwotne ich wdrożenie .
Po co więc wymyślono te relacyjne bazy? To były czasy gdy pamięć była najkosztowniejszym zasobem komputera zaś dane między systemami w zasadzie nie były wymieniane! Było kilka zalet, np. brak błędów nazewnictwa itp. więcej o nich w sieci można poczytać, jednak moim zdaniem baza danych będąca implementacją tak zwanych związków pojęciowych (tym są relacyjne modele danych) nie sprawdza się bo nie modeluje obiektów świata rzeczywistego a jedynie ich nazwy i powiązania między nimi a to ogromna różnica. (źr.: SQL albo NoSQL, oto jest pytanie – 2011 r.)
NoSQL
Jednym z typowych przykładów bazy danych typu NoSQL są bazy typu key-value i ich odmiany . Z uwagi na ich cechy i powszechność skupię się na tego typu bazach.
Wśród tego typu baz są tak zwane bazy dokumentowe. Idea tego typu baz danych realizuje jedno podstawowych założeń obiektowego paradygmatu (role obiektów): repozytorium nie służy do przetwarzania treści a jedynie do jej utrwalania i szybkiego przywoływania (dostępu). Przetwarzaniem danych (treści) zajmują komponenty odpowiedzialne wyłącznie za realizację logiki aplikacji. Skoro repozytorium nie przetwarza treści, jest ono – przechowywana treść i jej struktura – neutralnym elementem. Dlatego operujemy tu często pojęciem plik, którym zależnie od typu bazy, może być np. ciąg znaków XML lub JSON albo po prostu ciąg binarny (czyli „cokolwiek”). Taka baza to hipotetyczne dwie kolumny: pierwsza zawiera identyfikatory wierszy a druga przechowywaną treść. I teraz zależnie od typu bazy i logiki aplikacji, która ją wykorzystuje, tą treścią może by ciąg znaków (np. XML, JSON) lub dowolny ciąg znaków binarny (czyli XML także, ale także np. zdjęcie lub plik edytora tekstów).
Przykładem bazy dokumentowej jest Amazon DynamoDB. Poniższy diagram pokazuje w uproszczeniu idee tej bazy i porównanie z typową modelem relacyjnym: odtworzenie dokumentu z bazy relacyjnej (po lewej) wymaga skomplikowanych operacji łączenia tabel, po prawej stronie mamy zaś zestaw ciągów znaków, każdy stanowi sobą kompletny już dokument, mogą one mieć różną strukturę. Pobranie dokumentu z bazy po prawej odbywa się zawsze prostym zapytaniem, takim samym„ bez względu na strukturę tych danych.

Dzięki temu osiągamy dwie kluczowe korzyści: zmieniająca się w czasie struktura dokumentów nie wpływa na bazę danych, czas pobrania dokumentu jest bardzo krótki i nie zależy od struktury dokumentu . Różnicę efektywności pokazano poniżej:


Dokument jako struktura danych
Opisane bazy NoSQL mają szereg zalet w stosunku do baz danych w modelu relacyjnym. Jednak problem tworzenia modeli relacyjnych jest zastępowany problemem modelowania struktur dokumentów . Nie jest to jednak problem budowania znormalizowanych relacyjnych struktur danych. Jest to problem natury czysto semantycznej: rzecz w tym czym jest dokument i czym są pola, z których on się składa. Jest wiele podejść do tego zagadnienia, uważam, że kluczowe jest odkrycie i zrozumienie co opisuje dany dokument. Po drugie istotne jest umiejętne zaprojektowanie logiki aplikacji. Dlatego repozytoria NoSQL z zasady nie biorą udziału w logice biznesowej ale struktura dokumentów determinuje logikę ich przetwarzania. Rolą repozytorium jest wyłącznie utrwalanie i udostępnianie. Poniżej przykład dość typowy: faktury i opisy produktów (opis produktu jako Karta Produktu): mimo tego, że oba te typy dokumentów mają inną strukturę, mogą być przechowywane w jednej i tej samej bazie danych NoSQL.

Baza dokumentowa służy wyłącznie do przechowywania danych. Kontekstowy i semantyczny dostęp do danych zapewniają dziedzinowe rejestry: dodatkowe proste tabele umieszczone przez repozytorium, w części aplikacyjnej. Z uwagi na to, że bazy dokumentowe nie nadają się do realizacji wyrafinowanych zbiorowych obliczeń na treści dokumentów, wykorzystuje się do tego typowe hurtownie danych.
[uzupełnienie miesiąc później] Z tego względu bardzo przydatny jest tu dobrze znany wzorzec projektowy Repozytorium (Repository). Istotą tego wzorca jest separacja kolekcji obiektów (np. nośników dokumentów) od logiki aplikacji za pomocą klasy realizującej interfejs do tej kolekcji. Poniżej wersja adresowana do chmury:

Realizacja utrwalania (zapis danych) to obiekty przechowujące («Storage» Repozytorium danych) oraz dane («document» Zestaw danych) przechowywane jako dokumenty (XML, JSON) lub pliki (baza key value). Dostęp do tej kolekcji zapewnia klasa «Management» Kontrola dostępu do danych, stanowiąca zarazem interfejs do tej kolekcji. Interfejsów do jednego repozytorium może być więcej, realizują one wtedy kontekstowe udostępnianie danych z tej samej kolekcji. Tak więc Realizacja usługi to dziedzinowy kod aplikacji, zaś Realizacja utrwalania to chmurowa usługa taka jak bazy NoSQL dostępne w chmurze.
Chmury Amazon i AZURE
Ciekawym przykładem bazy dokumentowej jest DynamoDB. Jest to partycjonowana baza NoSQL mająca dwie kolumny z kluczem: jeden to standardowy dla tego typu bazy identyfikator, drugi to klucz wskazujący na strukturę definiującą format danych w trzeciej kolumnie przechowującej dane (dokumenty). Jest to baza przechowująca dane w formacie JSON, więc ich interpretacja wymaga definicji konkretnej struktury danych. dodatkowa kolumna (SortKey) pełni rolę definicji typu (identyfikator struktury). Jest to wygodne bo w systemach obiektowych łatwo definiuje się typy złożone, nadając każdemu rekordowi dodatkowy identyfikator, można intepretować pobrane dane.

Więcej informacji o repozytoriach Amazon, także Amazon S3 (bardzo szybka baza plików) znajdziecie w książce wydawnictwa Helion: Amazon Web Services . Analogiczne rozwiązanie oferuje AZURE.
Na zakończenie
Osobiście polecam rozważenie opisanych tu rozwiązań w swoich projektach. W obszarze dokumentów i zarządzania ich treścią są wręcz doskonałe. Model relacyjny, doskonały do obliczeń, niestety przegrywa z kretesem w aplikacjach biznesowych, gdzie zaczyna się liczyć przede wszystkim szybkość dostępu do ogromnej ilości danych oraz odporność na szybko zmieniające się wymagania co do struktury danych.
Problem projektowania struktur dokumentów, także w bazach dokumentowych, to osobne i trudne zagadnienie. Opisałem go w najnowszym artykule, który ukaże się za niedługo w wydawnictwie IGI Global: Emerging Challenges, Solutions, and Best Practices for Digital Enterprise Transformation.
C.d. czytaj Bazy NoSQL jako implementacje wzorców struktur informacji.
Źródła

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.