w02_NoSQL-RPerliński

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

rperlinski@icis.pcz.pl
Politechnika Częstochowska
Instytut Informatyki Teoretycznej i Stosowanej
23 października 2019
Plan wykładu
1 Bazy NoSQL
Ranking baz NoSQL, podział na modele danych
Termin NoSQL
Przyczyny powstania baz NoSQL
Spójność, teoria CAP
Modele dystrybucyjne
2 Porównanie do baz relacyjnych
3 Model danych
NoSQL a model relacyjny
Model danych zorientowany na agregacje
4 Inne modele danych
Bazy grafowe
Bazy danych bez schematu
5 Źródła
Wprowadzenie do baz NoSQL 2/75

Najpopularniejsze bazy NoSQL

Najnowszy ranking systemów baz danych
http://db-engines.com/en/ranking
40 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.
Różne modele baz danych
Liczba systemów w każdej kategorii:
http://db-engines.com/en/ranking_categories - październik 2019

Różne modele baz danych - rok 2016
Popularność różnych modeli daz danych:




Różne modele baz danych
Zmany popularności od stycznia 2013 roku:
http://db-engines.com/en/ranking_categories

Bazy komercyjne i na licencji opensource
Zmany popularności od stycznia 2013 roku:
https://db-engines.com/en/ranking_osvsc

Poliglotyczne przechowywanie danych
Poliglotyczne przechowywanie danych:
nie wykorzystujemy jednej bazy do wszystkiego,
różne bazy danych są wykorzystywane do różnych celów.
Przykład dla aplikacji e-commerce:

koszyk zakupów i sesja użytkownika - baza klucz-wartość,
rekomendacja produktów kupionych przez znajomych - baza grafowa,
stan magazynu, lista towarów, ceny - baza relacyjna,
informacje o zakończonym zamówieniu - baza dokumentów.
Usługi (REST API) czy bezpośrednie przechowywanie danych?

Wiele produktów NoSQL udostępnia wbudowane REST API.
Trend:
pojedyncza baza transakcyjna pozwalająca na przechowywanie wielu modeli →
bazy wspierające natywną implementację rozwiązań.
Pojawienie się terminu NoSQL
Prawdziwy początek
Johan Oskarsson chciał zorganizować spotkanie o „nowych” bazach -
czerwiec 2009.
Potrzebne było dobre hasło do Twittera, chwytliwe, mające mało
wynikow w Google.
Po sugestiach z kanału IRC #cassandra wybrał NoSQL.
Nazwa była negatywna i nie do końca pasowała do opisywanych
systemów - przyjeła się jednak. Przyjęła się nie tylko na to jedno
spotkanie ale na cały trend projektowania baz danych innego typu.
Spotkanie organizowane pod tym hasłem dotyczyło otwartych,
rozproszonych, nierelacyjnych baz danych.

Termin NoSQL
Dwa znacznia:
nie SQL - średnio dobry termin - bazy NoSQL mobłyby z powodzeniem
używać SQLa; niektore posiadają języki zapytań, np. CQL z Cassandry,
nie tylko SQL - oznaczałoby też bazy relacyjne, takie do NoSQL nie należą.
Termin NoSQL:
przyjął się, ale wprowadza w błąd,
nic konkretnego nie definiuje, jest taką nie-definicją,
odnosi się do niedawno powstałych baz nierelacyjnych.

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.

Dwa rodzaje skalowania
Ciągle zwiększające się zapotrzebowanie na dane i zasoby
(np. poprzez portale społecznościowe).
skalowanie w górę (pionowe) - większa wydajność i pojemność serwera, dużo
większa cena,
skalowanie w bok (poziome) - wykorzystanie wielu słabszych maszyn w
klastrze, mniejsza cena.

Przyczyny powstania baz NoSQL
(Bardzo) duża liczba użytkowników - trudność w wykorzystaniu baz relacyjnych.
Właściwości SZBD ważne przy wykonywaniu zadań na dużą skalę:

skalowalność - zdolność do efektywnego radzenia sobie ze zmiennym
obciążeniem; skalowanie w poziomie bardziej elastyczne niż skalowanie
pionowe (w górę), bazy NoSQL lepiej przystosowane do skalowania
poziomego, nie potrzeba wymieniać serwera,
koszt - wysokie koszty i trudności w określeniu potrzebnej licencji; darmowe
i otwarte oprogramowanie NoSQL zachęca do użycia go,
elastyczność odpowiednie bazy do odpowiednich potrzeb, bazy NoSQL są
dobre dla danych niehomogenicznych (zróżnicowanych), np. różne atrybuty
produktów w aplikacji e-commerce,
dostępność - wysokie oczekiwania w stosunku do dostępności aplikacji;
wiele serwerów działających w klastrze pozwala na dostępność, nawet przy
awarii któregoś z tych serwerów.
Zapotrzebowanie na systemy skalowalne, tanie, elastyczne, o wysokiej dostępności.
Bazy NoSQL - open source i do pracy w klastrach
Bazy relacyjne nie są zaprojektowane do pracy w klastrach.
Podział bazy relacyjnej na klastry jest możliwy ale bardzo dużo się
traci, są to „nienaturalne działania”.
Google Bigtable i Amazon Dynamo - pierwsze udane na masową skalę

wdrożenia innego sposobu przechowywania danych. Ogromny wpływ
na powstanie NoSQL.
NoSQL mocno zakorzeniony w ruchu open source.

Bazy NoSQL
Pozwalają na przechowywanie danych bez schematu.
Zwiększają produktywność tworzenia aplikacji - udostępniają model

danych lepiej pasujący do potrzeb aplikacji, nie potrzeba
poświęcać czasu na mapowanie danych.
Zamiast tradycyjnej spójności udostępniają szereg innych

wartościowych właściwości.
Są łatwiejsze w skalowaniu i programowaniu.

Wymagania wobec systemu baz danych, spójność
Wymagania:
przechowywanie danych w sposób trwały,
utrzymywanie spójności danych,
zapewnianie dostępności danych.
Wymagania wobec spójności (dwa jej rodzaje):
pełna spójność,
dotyczy transakcji bazodanowych w bazach relacyjnych,
utrzymanie jednego, logicznie spójnego widoku danych,
np. przelewy na kontach bankowych,
możliwa chwilowa niespójność, ostatecznie wszystkie dane będą takie same,
dotyczy stanu kopii danych w systemach rozproszonych,
serwery są spójne, jeśli zgromadzone na nich dane są takie same,
implementowana przez bazy NoSQL,
np. towary w koszyku sklepowym
(jest mało prawdopodobne, że ktoś inny będzie patrzył na nasz koszyk).
ACID i BASE
ACID - akronim czterech właściwości baz relacyjnych:

atomowość (ang. atomicity ), niepodzielność transakcji,
spójność (ang. consistency ), rygorystyczna spójność, po transakcji
wszystkie dane są integralne,
izolacja (ang. isolation), transakcje są izolowane, nie są widoczne dla
innych,
trwałość (ang. durability ), zakończona transakcja oznacza utrwalenie
danych na dysku.
Bazy NoSQL nie wspierają własności ACID, co najwyżej niektóre z nich.

Wspierają natomiast właściwości BASE.

ACID i BASE
Właśności BASE baz NoSQL:

zasadnicza dostępność (ang. basically available) - w pewnych
częściach systemu mogą występować awarie, ale reszta systemu
kontynuuje działanie,
mięki stan (ang. soft state) - stan systemu może się zmieniać w
czasie nawet bez zmiany danych, które mogą zostać nadpisane
nowszymi danymi, ma to związek z ostateczną spójnością,
ostateczna spójność (ang. eventually consistent) - wkońcu wszystkie

dane w klastrze będą spójne, ale będą chwile, że dane nie będą spójne.

Teoria CAP
Każdy klient może zawsze
Bazy relacyjne
odczytywać i zapisywać dane.
Klucz-wartość
Rodzina kolumn Availability (dostępność)
Dokumentów
RDBMS Cassandra
(Oracle, Dynamo
MySQL, Voldemort
Postgre, ...) SimpleDB
CouchDB
Riak
Consistency (spójność) BigTable, HBase, Partition tolerance

Hypertable
Wszyscy klienci mają zawsze ten sam MemcacheDB, (odporność na partycjonowanie)
obraz danych (dane są zawsze spójne). Redis, BerkeleyDB System działa bezbłędnie niezależnie od
MongoDB, Terrastore fizycznego podziału sieci (brak łączności
między węzłami klastra).
Teoria CAP - bazy danych nie mogą jednocześnie zapewniać spójności (ang. consistency ),
dostępności (ang. availability ) i ochrony przed partycjonowaniem (ang. partition tolerance).
Modele dystrybucyjne

Replikacja i współdzielenie
Tło:
działanie baz NoSQL w dużych klastrach,
agregacje są idealnymi jednostkami do dystrybucji,
różne modele dystrybucyjne - różne opcje:
obsługa większych ilości danych,
możliwość przetworzenia większego ruchu odczytu i zapisu,
większa niezawodność w dostępnie do danych.
Dwie główne ścieżki dystrybucji:

replikacja - te same dane kopiowane są na wiele serwerów,
współdzielenie - umieszczanie różnych części danych na różnych
serwerach.
Replikacja i współdzielenie są do siebie ortogonalne - można je stosować

jednocześnie. Dwie formy replikacji: master-slave, peer-to-peer.
Replikacja i współdzielenie
Replikacja Współdzielenie

Modele dystrybucyjne I
Najważniejsze modele dystrybucyjne:
pojedynczy serwer - baza działa na jednej maszynie obsługującej wszystkie
odczyty i zapisy,
współdzielenie (ang. sharding )
różne części danych na różnych serwerach; 10 serwerów, każdy
obsługuje 10% zapytań (np. podział na kraje, dni tygodnia...),
zwiększa szybkość zapisu i odczytu,
nie poprawia niezawodności i bezpieczeństwa danych,
replikacja master-slave - kopie danych na wielu serwerach,
replikacja synchronizuje podległe serwery z tym nadrzędnym,
dobrze się nadaje do systemów gdzie głównie odczytuje się dane,
zapis tylko na serwer główny,
zapewnia niezawodność odczytu,
serwery podrzędne mogą służyć też tylko jako kopia zapasowa,
różne połączenia z bazą (różne ścieżki) do zapisu i odczytu,
brak spójności.
Modele dystrybucyjne II
Najważniejsze modele dystrybucyjne:
replikacja peer-to-peer
brak serwera głównego (nie ma serwera podatnego na awarię),
wszystkie repliki mają równe prawa, wszystkie wykonują zapis,
jest problem ze spójnością
chwilowa niespójność przy odczycie,
konflikt zapis-zapis w różnych miejscach - trwała niespójność,
dwa sposoby reagowania przy zapisie:
pilnowanie spójności i mniejsza dostępność,
większa dostępność ale zgoda na niespójność,
łączenie współdzielenia i replikacji
replikacja master-slave i współdzielenie
wiele serwerów głównych (każda część ma jeden serwer główny),
serwer może być głównym dla jednych danych i podrzędnym dla innych,
replikacja peer-to-peer i współdzielenie
częste dla baz rodziny kolumn - dziesiątki lub setki serwerów w klastrze,
współczynnik przetworzenia równy np. 3 - każda część danych jest na 3
serwerach.
Zarządzanie danymi w systemach rozproszonych
Bazy NoSQL to zazwyczaj bazy rozproszone - prowadzi to do pewnych
problemów z zarządzaniem danymi.
Jeden serwer - łatwo o przerwy w dostępności.

Możliwa większa dostępność dzięki zapasowemu serwerowi.
Wykorzystanie zapasowego serwera zwiększa czas zapisu ale zwiększa
dostępność.

Odczyt i zapis - kworum
Kworum - liczba serwerów, które muszą odpowiedzieć na operację
odczytu czy zapisu, aby operacja została uznana za zakończoną.
Wymaganą liczbę serwerów określa próg.
Przykład:
z 5 serwerów 2 mają chwilowo niespójne dane, próg odczytu wynosi 3,
baza odpytuje wszystkie 5 serwerów i zlicza ile razy pojawiły się
poszczególne wartości,
zwracana jest ta wartość, której liczba wystąpień wyniesie lub
przekroczy 3.
Równoważenie czasów reakcji i spójności
Różnie określając wartość progu odczytu można równoważyć czas reakcji i

spójność:
próg ustawiony na 1 - minimalny czas reakcji, najszybsza odpowiedź, większe
ryzyko niespójności,
próg ustawiony na 5 - gwarancja spójnego odczytu, wyniki zwracane dopiero
po zaktualizowaniu wszystkich replik, możliwy długi czas odczytu.

Równoważenie czasów reakcji i trwałości
Trwałość oznacza zdolność zachowania danych przez dłuższy czas.
Operacja zapisywania jest zakończona, kiedy dane zostaną zapisane w minimalnej

liczbie replik.
Różnie określając wartość progu zapisu można równoważyć czas odpowiedzi i

trwałość:
próg ustawiony na 1 - zapis uznany za komplenty przy zapisaniu danych już
na jednym serwerze (szybka odpowiedź ale łatwiej o utratę takich danych),
próg ustawiony na 5 - maksymalna trwałość ale długi czas reakcji.
W praktyce próg zapisu równy przynajmniej 2 zapewnia trwałość i nie wydłuża

czasu zapisu. Liczba replik powinna być większa niż próg.

Bazy relacyjne a bazy NoSQL

Bazy relacyjne a NoSQL
Niezmienne królowanie baz relacyjnych przez ostatnie 20 lat.

Lata 90 - chwilowa moda na bazy obiektowe.
Czy bazy NoSQL zajmą stałe miejsce w środowisku?
Plusy na korzyść baz relacyjnych:

dane w organizacji mają znacznie dłuższy czas niż same aplikacje,
stabilny magazyn danych, który jest zrozumiały i dostępny z poziomu
wielu platform programistycznych.

Zalety i wartość baz relacyjnych
Zalety i wartość baz relacyjnych:

trwałe przechowywanie dużych ilości danych,
SZBD zawiera dużo narzędzi wspierających dostęp, manipulowanie i
wyszukiwanie danych,
współbieżność - jednoczesna praca wielu użytkowników, czasem nawet
na tym samym fragmencie danych - transakcje,
integracja - współpraca różnych aplikacji i zespołów pracowników
przez współdzieloną bazę danych,
ustandaryzowany model - każdy specjalista może z łatwością
pracować na różnych bazach relacyjnych,
ustandaryzowany język SQL.

Wady baz relacyjnych
Wady baz relacyjnych:

dane przechowywane w tabelach i wierszach (relacje i krotki),
krotki zawierają tylko proste dane, żadnych zagnieżdżonych struktur,
dane przechowywane w sposób znormalizowany (wada ale i zaleta),
niezgodność impedancji - inny model danych w bazie, a inne dane w
programie czy w ogóle w strukturze pamięci.
Wady baz relacyjnych
Niezgodność impedancji złagodzona dzięki mapowaniu obiektowo

relacyjnemu. Nie jest to rozwiązanie doskonałe...
Po roku 2000 bazy relacyjne nadal królują ... ale zaczęły się pojawiąc nowe
technologie - NoSQL.

Bazy integracji i aplikacji
Relacyjne bazy danych jako bazy integracji:

integracja różnych aplikacji i zespołu pracowników,
jedna baza - dane przetwarzane przez wiele aplikacji,
zapewnienie spójnego zestawu trwałych danych,
skomplikowana struktura bazy, wymaga koordynacji większości zmian.
Baza danych jako baza aplikacji:

dostęp tylko jednej aplikacji, zarządzanej przez specjalny zespół,
tylko zespół zna strukturę bazy - łatwość i bezpieczeństwo zmian,
odpowiedzialność za integralność danych w kodzie aplikacji,
współpraca między aplikacjami - Web Services,
komunikacja za pośrednictwem http,
dane agregacyjne w formacie XML czy JSON.

Bazy integracji i aplikacji
Baza aplikacji:
może działać z dowolnym silnikiem bazy danych (baza NoSQL albo
relacyjna),
na zewnątrz udostępnia tylko usługi, interfejs,
nie jest bezpośrednio dostępna na zewnątrz - większe bezpieczeństwo.
Mimo takiej swobody większoś baz aplikacyjnych działa na bazach

relacyjnych.

Termin NoSQL a rzeczywistość
Od pojawienia się baz NoSQL bazy relacyjne są jedną z opcji do wyboru,

nie są jedynym wyborem.
Bazy NoSQL najlepiej nadają się jako bazy aplikacji - enkapsulacja baz
danych w usługi.
Transakcje ACID z baz relacyjnych przeszkadzają w działaniu na
klastrze.
Bazy NoSQL nie zapewniają transakcji, udostępniają inne sposoby
zachowania spójności i dystrybucji.
Bazy grafowe nie są projektowane do działania na klastrach, są
zbliżone do baz relacynych, mają jednak zupełnie inny model danych.
Działają bez schematu danych, można dowolnie dodawać pola do
rekordów w bazie. Nie wymaga to zmiany struktury bazy.

Skutki upowszechnienia baz NoSQL
Zmiany na rynku baz danych:

Bazy relacyjne nadal będą najważniejsze ale nie będą już jedynymi.
Początek poliglotycznego przechowywania danych, dane
przechowywane w różnych modelach
Przedsiębiorcy i pojedyncze aplikacje korzystający z wielu technologii
przechowywania danych.
Projektanci i programiści baz danych:

musza znać bazy post-relacyjne ale też bazy NoSQL,
potrafić ocenić, który model jest bardziej odpowiedni do danego
zadania.
Podjęcie właściwej decyzji wymaga dostatecznego poziomu wiedzy o obu

modelach danych.

Model danych

Model danych
Model danych to model za pomocą którego przeglądamy dane i

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

Model danych NoSQL a model relacyjny
Dominujący model relacyjny:

zestaw tabel (relacji),
wiersze odpowiadają encji,
encja to zestaw kolumn, każda ma wartość i określony typ,
związki między tabelami (klucze główne i obce) - relacje
NoSQL:
wprowadza odejście do modelu relacyjnego,
każdy model NoSQL jest inny, wyróżniamy cztery kategorie,
3 podobne modele (zorientowane na agregacje): klucz-wartość,
dokument i rodzina kolumn.

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:
http://nosql-database.org/
http://nosql.mypopescu.com/kb/nosql
Dane w modelu zorientowanym na agregacje
Ograniczenia krotek w modelu relacyjnym:

są tylko prostym zestawem wartości, nie można ich zagnieżdżać.
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.
Relacyjny model danych
Przykład ze sprzedażą towarów użytkownikowi:

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

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":"1500-1200",
"NIP": "2345678901",
"adresPlatnika": {"miejscowosc":"Częstochowa"}
}
]
}

Model danych oparty o agregacje

Model danych oparty o 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.

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": "1500-1200",
"NIP": "2345678901",
"adresPlatnika": {"miejscowosc": "Częstochowa"}
}
]
}
]
}

Inne wyznaczenie granic agregacji

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.

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.

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.

Modele agregacyjne:
klucz-wartość
dokumentów
rodziny kolumn

Modele klucz-wartość i dokumentów - cechy wspólne
Bazy klucz-wartość i dokumentów:

w głównej mierze oparte na agregacjach, zawierają dużą ich liczbę,
dostęp do każdej agregacji odbywa się za pomocą
klucza/identyfikatora, który ją wskazuje.

Modele klucz-wartość i dokumentów - różnice
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.
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.

Modele klucz-wartość i dokumentów
W paktycye różnice między bazami klucz-wartość i dokumentów częściowo

się zacierają:
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ń.
W bazach danych klucz-wartość spodziewamy się pobierania danych

przede wszystkim za pomocą klucza.
W bazach dokumentów wykonujemy najczęściej pewnego rodzaju

zapytanie na bazie wewnętrznej struktury dokumentu.

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.

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’)
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.

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.

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.

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 rodziny 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.

Bazy grafowe

Inne aspekty modelowania danych
Dane w bazie połączone relacjami

W wielu przypadkach dobrze jest, żeby baza danych wiedziała o
połączeniach między danymi.
W bazach klucz-wartość są mechanizmy, które pozwalają na
definiowanie takich relacji.
Przy dużej liczbie połączeń wybieramy zazwyczaj model relacyjny, ale
on też nie jest tutaj dostatecznie dobry.
Bazy grafowe są wyspecjalizowane w dużej liczbie relacji.
Bazy grafowe to też NoSQL.

Bazy grafowe

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).

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.

Bazy bez schematu - plusy
Plusy baz danych bez schematu

Bazy relacyjne muszą mieć schemat żeby działać (tabele, kolumny, typy
danych ...). Bazy NoSQL najcześciej nie.
W każdym z modeli baz NoSQL można przechowywać dowolne dane
w dowolnym miejscu. Jest duża elastyczność i wolność.
Zmiana schematu w bazie relacyjnej przy istniejących danych nie jest
taka prosta.
Baza może się zmieniać w miarę rozwoju aplikacji czy działania usługi.
W każdej chwili można łatwo dodać nowe pola, kolumny, czy też
usuną już nie potrzebne. Nie ma schematu...
Łatwiej przechowywać też dane niestandardowe, np. różne liczby
kolumn w różnych rekordach.
Nie trzeba tworzyć na zapas pustych fikcyjnych kolumn, np.
dodatkowa1.

Bazy bez schematu - minusy
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...?
Wniosek: prawie zawsze korzystamy z jakiegoś domniemanego schematu choć
może on być tylko w aplikacji.
Posiadanie domniemanego schematu w kodzie aplikajci - trzeba przeglądać
kod żeby poznać strukturę bazy.
Bardzo dużo zależy od jakości kodu - czasem może być ciężko coś odczytać.
Baza danych nie uznaje schematu - nie da się walidować danych.
Dla kilku różnych aplikacji ta sama baza może zupełnie inaczej
funkcjonować.
Brak schematu nie pozwala określić jak lepiej przechowywać i pobierać dane.
Bazy bez schematu
Schematy są wartościowe.
Odrzucenie schematów przez NoSQL jest dużą nowością.
Jeśli mamy dane nieposiadające jasno określonego schematu - warto
wykorzystać NoSQL.
Jeśli z bazy NoSQL korzysta kilka aplikacji każda z nich może mieć w
kodzie inny domnienamy schemat. Rozwiązania:
Bazę NoSQL możana „opakować” (enkapsulacja) przez jedną
aplikację, która udostepni dane wszystkim innym - usługi sieciowe.
Różne wydzielone obszary bazy/agragacji dla różnych aplikacji z niej
korzystających.
Brak schematu w NoSQL występuje tylko w granicy agregacji. Zmiana

granic agregacji jest tak skomplikowana jak zmiana schematu w bazach
relacyjnych.
Źródła
W wykładzie wykorzystano materiały:

Pramod J. Sadlage, Martin Folwer, NoSQL Kompendium wiedzy,
Helion, 2015
Dan Sulivan, NoSQL Przyjazny przewodnik, Helion 2016
https://db-engines.com
https://dzone.com/articles/better-explaining-cap-theorem

w02_NoSQL-RPerliński

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

w02_NoSQL-RPerliński

Uploaded by

Copyright:

Available Formats

Wprowadzenie do baz NoSQL

Technologie zarządzania treścią

dr inż. Robert Perliński

Wprowadzenie do baz NoSQL 2/75

Wprowadzenie do baz NoSQL 3/75

40 spośród 100 najważniejszych SZBD obecnych na rynku, to bazy NoSQL.

http://db-engines.com/en/ranking_categories - październik 2019

Wprowadzenie do baz NoSQL 5/75

Popularność różnych modeli daz danych:

http://db-engines.com/en/ranking_categories - październik 2016

Wprowadzenie do baz NoSQL 6/75

Popularność różnych modeli daz danych:

http://db-engines.com/en/ranking_categories - październik 2017

Wprowadzenie do baz NoSQL 7/75

Popularność różnych modeli daz danych:

http://db-engines.com/en/ranking_categories - październik 2018

Wprowadzenie do baz NoSQL 8/75

Popularność różnych modeli daz danych:

http://db-engines.com/en/ranking_categories - październik 2019

Wprowadzenie do baz NoSQL 9/75

Zmany popularności od stycznia 2013 roku:

Wprowadzenie do baz NoSQL 10/75

Zmany popularności od stycznia 2013 roku:

Wprowadzenie do baz NoSQL 11/75

Przykład dla aplikacji e-commerce:

Usługi (REST API) czy bezpośrednie przechowywanie danych?

Wprowadzenie do baz NoSQL 13/75

Wprowadzenie do baz NoSQL 14/75

Termin NoSQL odnosi się:

Wprowadzenie do baz NoSQL 15/75

Wprowadzenie do baz NoSQL 16/75

Właściwości SZBD ważne przy wykonywaniu zadań na dużą skalę:

Bazy relacyjne nie są zaprojektowane do pracy w klastrach.

Google Bigtable i Amazon Dynamo - pierwsze udane na masową skalę

NoSQL mocno zakorzeniony w ruchu open source.

Wprowadzenie do baz NoSQL 18/75

Pozwalają na przechowywanie danych bez schematu.

Zwiększają produktywność tworzenia aplikacji - udostępniają model

Zamiast tradycyjnej spójności udostępniają szereg innych

Są łatwiejsze w skalowaniu i programowaniu.

Wprowadzenie do baz NoSQL 19/75

ACID - akronim czterech właściwości baz relacyjnych:

Bazy NoSQL nie wspierają własności ACID, co najwyżej niektóre z nich.

Wprowadzenie do baz NoSQL 21/75

Właśności BASE baz NoSQL:

ostateczna spójność (ang. eventually consistent) - wkońcu wszystkie

Wprowadzenie do baz NoSQL 22/75

Consistency (spójność) BigTable, HBase, Partition tolerance

Wprowadzenie do baz NoSQL 24/75

Dwie główne ścieżki dystrybucji:

Replikacja i współdzielenie są do siebie ortogonalne - można je stosować

Wprowadzenie do baz NoSQL 26/75

Jeden serwer - łatwo o przerwy w dostępności.

Wprowadzenie do baz NoSQL 29/75

Różnie określając wartość progu odczytu można równoważyć czas reakcji i

Wprowadzenie do baz NoSQL 31/75

Operacja zapisywania jest zakończona, kiedy dane zostaną zapisane w minimalnej

Różnie określając wartość progu zapisu można równoważyć czas odpowiedzi i

W praktyce próg zapisu równy przynajmniej 2 zapewnia trwałość i nie wydłuża

Wprowadzenie do baz NoSQL 32/75

Wprowadzenie do baz NoSQL 33/75

Niezmienne królowanie baz relacyjnych przez ostatnie 20 lat.

Plusy na korzyść baz relacyjnych:

Wprowadzenie do baz NoSQL 34/75