NoSQL. Technologie zarządzania treścią. dr inż. Robert Perliński

Transkrypt

1 NoSQL Technologie zarządzania treścią dr inż. Robert Perliński Politechnika Częstochowska Instytut Informatyki Teoretycznej i Stosowanej

2 NoSQL 2/36 Plan wykładu 1 NoSQL 2 Model danych zorientowanie na agregacje bazy grafowe 3 Bazy danych bez schematu 4 Źródła

3 Najpopularniejsze bazy NoSQL NoSQL 3/36

4 NoSQL 4/36 Najnowszy ranking systemów baz danych 34 spośród 100 najważniejszych SZBD obecnych na rynku, to bazy NoSQL. Bardzo dynamiczna branża przemysłu informatycznego: nowe bazy NoSQL powstają co roku, powstają też nowe funkcjonalności.

5 NoSQL 5/36 Termin NoSQL Termin NoSQL odnosi się: do niezidentyfikowanego zestawu baz danych, przeważnie typu open source, przeważnie stworzonych w XXI wieku, przeważnie nie wykorzystujących języka SQL. Bazy NoSQL - bazy relacyjne nie są jedynym wyborem - poliglotyczne przechowywanie danych. Bazy NoSQL najlepiej nadają się jako bazy aplikacji - enkapsulacja baz danych w usługi.

6 NoSQL 6/36 Model danych Model danych: model za pomocą którego przeglądamy dane i manipulujemy nimi, konkretny model danych aplikacji, np. konkretny diagram encji, przede wszystkim model, zgodnie z którym baza organizuje dane - metamodel. Model przechowywania opisuje, w jaki sposób dane są przechowywane i manipulowane wewnętrznie.

7 Podział baz NoSQL ze względu na model danych Model danych Przykładowe bazy Model danych Przykładowe bazy Klucz - wartość BerkeleyDB Rodzina kolumn Amazon SimpleDB Memcached Cassandra Project Voldemort HBase Redis Hypertable Riak Dokument CouchDB Bazy grafowe FlockDB MongoDB HyperGraphDB OrientDB Infinite Graph RavenDB Neo4J Terrastore OrientDB Niektóre bazy danych pasują do więcej niż jednej kategorii. Inne są na granicy kategorii. Pełana lista baz NoSQL (i nie tylko) na stronach: NoSQL 7/36

8 NoSQL 8/36 Dane w modelu zorientowanym na agregacje Model zorientowany na agregacje: operujemy na na złożonych strukturach, takie złożone struktury nazwiemy agregacją. Agregacje: można myśleć jako o rekordach, które zawierają inne rekordy czy listy, kolekcja obiektów traktowana jako jednostka, taką jednostkę, agregację przechowujemy, przesyłamy i poprzez nią manipulujemy na danych, ułatwiają pracę w klastrach - są naturalną jednostką do replikacji i współdzielenia.

9 NoSQL 9/36 Relacyjny model danych Przykład ze sprzedażą towarów użytkownikowi:

10 NoSQL 10/36 Relacyjny model danych Dane w bazie relacyjnej po normalizacji: Żadne dane się nie powtarzają, jest integralność referencyjna.

11 NoSQL 11/36 Model danych zorientowany na agregacje Przykład ze sprzedażą towarów użytkownikowi:

12 NoSQL 12/36 Model danych zorientowany na agregacje w klientach { } "id":28, "nazwa":"jan Kowalski", "adresplatnika": [{"miejscowosc":"częstochowa"}] w zamówieniach { } "id":99, "klientid":28, "pozycjezamowienia": [ { "produktid":25, "cena": 32.45, "produktnazwa": "NoSQL Databases" } ], "adreswysylki": [{"miejscowosc":"częstochowa"}], "zamowienieplatnosc": [ { "numerkarty":" ", "NIP": " ", "adresplatnika": {"miejscowosc":"częstochowa"} } ]

13 NoSQL 13/36 Model danych zorientowany na agregacje Przykład ze sprzedażą towarów użytkownikowi Dwie podstawowe agregacje: klient i zamówienie. Lista adresów w kliencie, adres ustalony na dzień zakupów. Zamówienie zawiera listę pozycji zamówienia, płatności oraz adres wysyłki. Płatność zawiera wykorzystany adres płatnika. Pojedynczy adres pojawia się trzy razy! Nie potrzebne jest ID adresu. Adres płatności i wysyłki nie ulegają zmianie. Połączenie między klienetem a zamówieniami poprzez ID klienta - należy odczytać z relacji między agregacjami.

14 NoSQL 14/36 Inne wyznaczenie granic agregacji Przykład ze sprzedażą towarów użytkownikowi:

15 NoSQL 15/36 Wszystkie zamówienia w agregacji klienta w klientach { } "id": 28, "nazwa": "Jan Kowalski", "adresplatnika": [{"miejscowosc": "Częstochowa"}], "zamowienia": [ { "id": 99, "klientid": 28, "pozycjezamowienia": [ { "produktid": 25, "cena": 32.45, "produktnazwa": "NoSQL Databases" } ], "adreswysylki": [ {"miejscowosc": "Częstochowa"} ], "zamowienieplatnosc": [ { "numerkarty": " ", "NIP": " ", "adresplatnika": {"miejscowosc": "Częstochowa"} } ] } ]

16 NoSQL 16/36 Wybór sposobu podziału na agregacje Podział modelu danych na agregacje: zależy od sposobu, w jaki będziemy na nich manipulowali, pierwszy model - pobieranie osobno każdego zamówienia, drugi model - pobieranie klientów ze wszystkimi ich zamówieniami.

17 NoSQL 17/36 Konsekwencje orientacji na agregacje Model relacyjny - agregacje realizowane przez klucze obce. Relacje agregacji nie różną się od pozostałych relacji. Model relacyjny ignoruje agregacje. Bazy zorientowane na agregacje: znacznie prostsza semantyka danych, semantyka zależy od sposobu wykorzystania danych przez aplikację, skupiamy się na interakcji z magazynem danych. Agregacje również są ignorowane przez bazy grafowe. Model ignorujący agregacje pozwala na łatwe przeglądanie danych w dowolny sposób.

18 NoSQL 18/36 Model agregacyjny i transakcje Bazy relacyjne: zapewniają obsługę transakcji (ACID), można manipulować dowolnymi wierszami w różnych tabelach bez obawy uzyskania niespójności. Bazy NoSQL: nie wspierają transakcji ACID obejmujących kilka agregacji, wspierają atomowe operacje w ramach jednej agregacji, jednoczesna manipulacja na wielu agregacjach wymaga zapewnienia atomowiści w kodzie aplikacji, należy tak projektować, aby utrzymać potrzeby atomowoego dostępu do danych w ramach jednej agregacji.

19 NoSQL 19/36 Model klucz-wartość Bazy klucz-wartość: dane są przezroczyste dla bazy - są nic nie znaczącym zbiorem bitów, pozwalają przechowywać co tylko się chce, jedynym ograniczeniem jest rozmiar, dostęp do danych tylko za pośrednictwem klucza.

20 Model dokumentów Bazy dokumentów: rozumieją struktury przechowywanych agregacji, ograniczają to, co można w nich przechowywać, poprzez definicję dopuszczalnych struktur i typów, większa elastyczność w dostępnie do danych: wysyłanie zapytań w oparciu o pola agregacji, pobieranie tylko części agregacji, tworzenie indeksów na podstawie zawartości agregacji. NoSQL 20/36

21 NoSQL 21/36 Modele klucz-wartość i dokumentów - porównanie Zacieranie się różnic: pole z identyfikatorem w bazie dokumentów jako dostęp typu klucz-wartość, niektóre bazy klucz-wartość pozwalają: dodawać metadane do przechowywanych wartości na potrzeby indeksowania i relacji między agregacjami (Riak), rozbijanie agregacji do poziomu list czy zestawów (Redis), dodawanie wsparcia dla wykonywania zapytań.

22 NoSQL 22/36 Model rodziny kolumn Jednostka przechowywania to: wiersz - najczęstszy przypadek, grupa kolumn - kiedy rzadko występuje zapis, a często odczytujemy kilka kolumn z wielu wierszy. Najlepiej patrzeć na model rodzina kolumn jako: dwuwymiarową mapę, tabelę z luźnym schematem kolumn. Bazy przechowujące grupy kolumn (rodziny kolumn) nazywamy bazami rodziny kolumn.

23 Model rodziny kolumn - przykład Dwupoziomowa struktura agregująca Pierwszy klucz - wiersz, wybór agregacji (mapa bardziej szczegółowych wartości). Drugi klucz - kolumna. Pobieranie cały wiersz: get( 1234 ) wybrana kolumna: get( 1234, nazwa ) NoSQL 23/36

24 NoSQL 24/36 Model rodziny kolumn Myślenie o strukturze baz rodziny kolumn przez pryzmat wiersza: patrzymy na całą agregację, jeden wiersz - jedna agregacja, np. klient o id 1234, rodziny kolum w danym wierszu reprezentują użyteczne części danych wewnątrz tej agregacji, np. profil klienta, historia zamówień, Myślenie o strukturze baz rodziny kolumn przez pryzmat kolumn: każda rodzina kolumn definiuje typ rekordu, np. profil klienta, z wierszami dla każdego z rekordów, wiersz funkcjonuje jako połączenie rekordów ze wszystkich kolumn.

25 NoSQL 25/36 Model rodziny kolumn Bazy rodziny kolumn: kolumny są organizowane w rodziny, każda kolumna musi być częścią pojedynczej rodziny, rodzina kolumn funkcjonuje jako jednostka dostępu, dana rodzina kolumn jest za zwyczaj pobierana razem. Rodzina kolumn: pozwala dodawać dowolne kolumny do wierszy, wiersze mogą mieć bardzo różne zestawy kolumn, nowe kolumny można dodawać do wierszy w trybie normalnego dostępu do danych, zdefiniowanie nowej rodziny kolumn może wymagać zatrzymania bazy danych.

26 NoSQL 26/36 Model rodziny kolumn Nietypowy aspekt tego modelu danych: rodzina kolumn Zamówienia, dodwanie kolumn pozwala zamodelować listę (w jednej kolumnie!). W bazie Cassandra używa się dwóch terminów: szeroki i chudy. Chude wiersze - mają niewiele kolumn, które jednak powtarzają się w wielu wierszach. Szerokie wiersze - mają wiele kolumn (nawet tysiące), ale kolumny poszczególnych wierszy bardzo się różnią. Jest to model listy, każda kolumna to element listy. Dla szerokich wierszy można definiować porządek sortowania. Dostęp, np. do Zamówienia, za pośrednictwem kluczy porządkowych. Wiersze chude i szerokie mogą (z technicznego punktu widzenia) współistnieć nawet w ramach jednej rodziny kolumn!

27 NoSQL 27/36 Podsumowanie modeli zorientowanych na agregacje Cechy wspólne trzech modeli (klucz-wartość, dokument, rodzina kolumn): Agregacje indeksowane za pomocą klucza, pozwalającego na jej pobranie. Cała agregacja jest przechowywana na jednym serwerze - podstawa działania modeli tego typu w klastrach. Agragacja jako jednostka atomowa podczas aktualizacji danych - użyteczna choć ograniczona kontrola transakcyjna. W ramach pojęcia agregacji uwidaczniają się różnice pomiędzy omówionymi trzema typami danych.

28 NoSQL 28/36 Podsumowanie modeli zorientowanych na agregacje Najważniejsze kwestie: Agregacja jest zestawem danych, które funkcjonują w bazie jako jednostka. Bazy klucz-wartość, dokumentów i rodzyny kolumn to bazy zorientowane na agregacje. Dzięki agregacjom przechowywanie danych w klastrach jest łatwiejsze. Bazy zrorientowane na agregacje najlepiej działają, kiedy interakcje z danymi są podejmowane w ramach jednej agregacji.

29 NoSQL 29/36 Bazy z dużą liczbą relacji Dane w bazie połączone relacjami dobrze jest, jeśli baza wie o połączeniach między danymi, duża liczba połączeń - model relacyjny ale... bazy grafowe - wyspecjalizowane w dużej liczbie relacji między danymi bazy grafowe to też NoSQL

30 Bazy grafowe NoSQL 30/36

31 NoSQL 31/36 Bazy grafowe Powstały dzięki kiepskiej obsłudze rozbudowanych relacji w modelu relacyjnym. Dane w bazie grafowej to węzły połączone krawędziami. W bazach grafowych mamy do czynienia z niewielkimi rekordami i rozbudowanymi połączeniami między nimi. Węzły zawierają mało informacji, jest bardzo rozbudowana sieć połączeń. Zbudowany graf (węzły i krawędzie) można odpytywać. Możliwe zapytania: znajdź książki z kategori bazy danych napisane przez kogoś, kogo lubi ktoś z moich znajomych. Idealna struktura do przechowywania danych zawierających skomplikowane powiązania (np. sieci społecznościowe).

32 NoSQL 32/36 Bazy grafowe Kosztowne złączenia w bazach relacyjnych - tanie w bazach grafowych (zysk trafersowania po grafie kosztem wolniejszego wstawiania danych). Nadanie indeksów niektórym węzłom pozwala na określenie miejsca początkowego (zaytanie sprawdź osoby o imionach Anna i Barbara ). Zapytania przechodzące po krawędziach, np. pokaż mi wszystkie rzeczy, które lubią Anna i Barbara. Duży nacisk na relacje powoduje dużą odmienność od baz zrorientowanych na agregacje. Częściej działają na pojedynczym serwerze niż na klastrze. Udostępniają transakcje ACID. Cechy wspólne z bazami NoSLQ: odrzucenie modelu relacyjnego, wzrost polularności w tym samym czasie co inne bazy NoSQL.

33 NoSQL 33/36 Bazy NoSQL - podsumowanie Ze strony:

34 Bazy bez schematu - wady i zalety Zalety baz danych bez schematu Można przechowywać dowolne dane w dowolnym miejscu - duża elastyczność i wolność. W bazach relacyjnych nie da się łatwo zmieniać schematu, gdy są już dane, tutaj inaczej... Rozwój bazy wraz z rozwojem aplikacji, usługi. Łatwa zmiana liczby kolumn, dodawania danych niestandardowych, usuwania niepotrzebnych,... Problemy przy bazach danych bez schematu Program korzystający z naszej bazy musi znać nazwy kolum czy kluczy. Musi znać typy danych. Pola: osobatelefon i telefonosoby to nie to samo. Trzeba wiedzieć czy po kluczem licznik znajdują się liczby czy może znaki alfabetu...? NoSQL 34/36

35 NoSQL 35/36 Bazy bez schematu - domniemany schemat Prawie zawsze korzystamy z jakiegoś domniemanego schematu. Domniemany schemat w kodzie aplikajci - trzeba przeglądać kod żeby poznać strukturę bazy. Bardzo ważna jakość kodu - czasem może być ciężko coś wyczytać. Baza nie uznaje schematu - nie da się walidować danych. Brak schematu - trudno określić jak lepiej przechowywać i pobierać dane. Różne aplikacje - inne sposoby współpracy z bazą. Brak schematu występuje tylko w granicy agregacji. Zmiana granic agregacji - proces tak skomplikowany jak w bazach relacyjnych.

36 NoSQL 36/36 Źródła W wykładzie wykorzystano materiały: Pramod J. Sadlage, Martin Folwer, NoSQL Kompendium wiedzy, Helion, nosql-data-modeling-techniques/