Bazy NoSQL

010 NOSQL
Prof. dr hab. Marek Wisła
Problem Big Data
• Przetwarzanie ogromnych ilości danych w bazie relacyjnej
może powodować powstanie problemów wynikających z
samego modelu relacyjnego, np. łączenie ogromnych
tabel jest zadaniem trudnym obliczeniowo.
• Wraz ze wzrostem obciążenia bazy relacyjnej można
implementować rozwiązania, które częściowo rozwiązują
problemy.
Denormalizacja i partycjonowanie
• Denormalizacja – zmiana schematu danych na mniej
znormalizowany pozwala uniknąć kosztownych
obliczeniowo łączeń tabel. Niesie to za sobą
prawdopodobieństwo występowania redundancji danych i
anomalii.
• Partycjonowanie (ang. partitioning) – polega na dzieleniu
tabel bazy na mniejsze części i przypisywaniu im
osobnych zasobów sprzętowych. Każda partycja tabeli
powinna być autonomiczna (częstym przykładem jest
tworzenie partycji w oparciu o zakres geograficzny, np.
dane firmy podzielone wg kontynentów). W ten sposób
uzyskuje się mniejsze „kawałki” danych, które łatwiej
przetwarzać, łączyć i indeksować.
Partycjonowanie pionowe
• Partycjonowanie
pionowe polega na
umieszczeniu całych
tabel (lub części
atrybutów tabel) na
oddzielnych
serwerach.
•
Partycjonowanie poziome (sharding)
• Zbiory danych dzielone są
na mniejsze części w ten
sposób, że na każdą
partycję trafia część danych.
Podział może następować
wg określonego klucza (np.
geograficznego, dane z
rożnych krajów na rożnych
maszynach) lub stosuje się
hashowanie (wówczas
konkretny wpis jest losowo
przydzielany do partycji
zgodnie z wynikiem pewnej
funkcji skrótu).
Partycjonowanie
• Partycjonowanie bazy danych wprowadza do systemu
dodatkową złożoność
• baza danych staje się systemem rozproszonym, rośnie
prawdopodobieństwo awarii w jednej z jej części. Wraz
ze wzrostem złożoności architektury rośnie potrzeba
stosowania serwerów zapasowych.
• w przypadku programistycznej obsługi partycjonowania
wzrasta skomplikowanie aplikacji. Dodatkowy nakład
pracy jest potrzebny na obsługę logiki związanej z
podziałem bazy.
Problem zapisu danych
• Kolejnym ograniczeniem baz relacyjnych jest zapis dużej ilości szybko
powstających danych. Stosowane są częściowe rozwiązania tego problemu:
• sharding – jeśli dane nie są ze sobą mocno powiązane można przypisać
rożne zasoby do obsługi rożnych części danych. Dane do zapisu są
wówczas dzielone na rożne maszyny.
• kolejkowanie danych do zapisania – zamiast zapisywać dane na bieżąco
dodaje się odpowiednie informacje do kolejki zadań, następnie baza
obsługuje zadania z kolejki. Rozwiązania tego nie można również
zastosować w sytuacji, w której zapisywane dane mają być od razu
dostępne do odczytu (aplikacje czasu rzeczywistego).
• Importowanie wsadowe – zamiast dodawać dane małymi porcjami
importuje się większe ich ilości w określonych odstępach czasu. Można na
czas takiego importu usunąć indeksy na danych: aktualizacja indeksów
jest dość kosztowną operacją, lepiej jest zatem obliczyć je kiedy wszystkie
dane są zaimportowane niż przeliczać wielokrotnie.
Zapis danych
• Niektóre bazy nierelacyjne radzą sobie lepiej z dużą
ilością danych do zapisania, np. w przypadku braku
ścisłego schematu danych i indeksów lub założenia, że
baza działa w klastrze serwerów (i dane mogą być
rozdzielane na rożne maszyny).
Problem odczytu danych
• Bardzo często spotykanym ograniczeniem baz relacyjnych jest
szybkość odczytu. Problemy te pojawiają się przy dużej ilości
przetwarzanych danych. Jednym z rozwiązań tego problemu
może być omówione poprzednio partycjonowanie bazy
danych.
• Aby móc udostępniać dane z bazy w sposób znacznie szybszy
stosuje się pamięć podręczną (cache). Czas dostępu do
pamięci podręcznej mierzony jest w nanosekundach: od 4 ns
(DDR-SDRAM) do 0.8 𝑛𝑠 (DDR5) (1 𝑛𝑠 = 10−9 𝑠) i jest
wielokrotnie mniejszy od czasu dostępu do twardego dysku:
• dysku magnetycznego: od 100 do 14 milisekund ( 1 𝑚𝑠 = 10−3𝑠 )
• dysku SSD do 12 mikrosekund (1 𝜇𝑠 = 10−6 𝑠)
• W przypadku, gdy dane nie są często aktualizowane, istnieje
duża szansa, że przy odczycie można będzie znaleźć szukaną
wartość w pamięci podręcznej.
Pamięć podręczna (cache)
Gry MMOG
• Pamięć podręczna nie sprawdza się jednak wtedy, gdy dane
muszą być jednocześnie bardzo szybko zapisywane i
odczytywane, na przykład w grach typu MMOG (massive
multiplayer on-line game).
• W takich grach bardzo wielu użytkowników łączy się z
pojedynczym serwerem, użytkownicy działają w tym samym
„wirtualnym świecie” gry i wchodzą w interakcje między sobą.
• Kluczowym elementem gry jest więc to, aby akcja wykonana
przez jednego gracza była natychmiast widoczna przez innych.
• Dane w takich aplikacjach produkowane są bardzo szybko (np.
w wirtualnym świecie użytkownicy mogą poruszać się po
planszy – każdy ruch generuje dane o nowej pozycji gracza na
planszy). Również odczyt musi być wtedy natychmiastowy
(każdą nową pozycję gracza trzeba przekazać innym
graczom).
Cechy systemów rozproszonych
• Trzy pożądane cechy systemów rozproszonych CAP (Eric
Brower 2000 r.):
• spojność danych (ang. Consistency) – wszystkie
węzły „widzą” te same dane w tym samym czasie,
• dostępność (ang. Availability) – wszystkie działające
węzły mogą odpowiadać na przychodzące żądania,
• tolerancja na brak komunikacji w części systemu
(ang. Partition tolerance) – system może działać mimo
utraty komunikacji między niektórymi węzłami lub awarii
części węzłów.
Twierdzenie Brewera
• Twierdzenie Brewera (lub twierdzenie CAP)
• Z trzech wymienionych cech baz rozproszonych
system może realizować tylko dwie.
Przykład
• Załóżmy, że następuje brak komunikacji między węzłami A i B.
W momencie żądania zmiany na węźle A system może przyjąć jedno
z zachowań:
• a) Zaakceptować żądanie i zmienić dane (oznacza to dostępność
systemu, ponieważ żądanie zostało obsłużone). W takiej sytuacji
jednak dane na węźle B pozostają niezmienione (z powodu braku
komunikacji między węzłami), zatem utracona zostaje spójność
danych.
• b) Odrzucić żądanie całkowicie skoro nie można zmienić danych
na dwóch węzłach lub wykonać żądanie na węźle A i jednocześnie
odrzucać wszystkie żądania do węzła B do czasu naprawienia
rozbieżności. W każdym z tych przypadków zachowana zostanie
spójność danych, jednak dostępność systemu jest ograniczona.
Spójność systemów rozproszonych
• W 2012 roku Brewer opublikował artykuł wyjaśniający
niektóre wątki z dyskusji, jaka toczyła się o jego
twierdzeniu. Spójność, czyli litera C w skrótach ACID i
CAP, odnosi się do nieco innych pojęć.
• W ACID spójność mówi o tym, że każda transakcja
zmienia stan bazy danych, na zgodny z ustalonymi
regułami tej bazy (nie narusza integralności).
• W CAP spójność oznacza, że każdy węzeł w systemie
rozproszonym „widzi” takie same dane w tym samym
czasie.
• Przykładowo, jeśli tabela jest rozproszona na wielu
węzłach, to aktualizacja jednego rekordu w tabeli odbywa
się jednocześnie na wszystkich węzłach.
Kombinacja CA nie jest istotna.
• Z trzech możliwych kombinacji cech, o których mówi
twierdzenie Brewera (CA, CP, AP), mają sens tylko dwie
ostatnie.
• Nie można zbudować systemu zakładając, że będzie
spełniał on tylko cechy CA (spójności i dostępności) –
twórcy systemów rozproszonych nie mają wpływu na
wystąpienie problemów komunikacji w sieci lub awarii
węzłów.
• Jeśli takie zdarzenie nastąpi system albo przestanie
odpowiadać (implikując brak dostępności), albo dane
przechowywane na „odciętych” węzłach przestaną być
aktualne (implikując brak spójności).
Kombinacje CP i AP
• Wybór między systemami CP (przedkładającymi spójność
danych nad dostępność systemu) a AP (przedkładającymi
dostępność nad spójność) nie jest rozłączny.
• W rzeczywistości systemy mogą „kłaść nacisk” na
wybraną cechę w zależności od konkretnej operacji lub
ustalać wybór pośredni.
• Brewer zauważa, że zarówno dostępność jak i spójność
danych może mieć wiele poziomów (w przypadku
dostępności może chodzić o dostęp do tylko części
danych lub tylko niektórych operacji).
Bazy relacyjne mają cechy CA
• Bazy relacyjne, wspierające transakcje, posiadają cechy CA
(spójność, dostępność). Zgodnie z twierdzeniem Browera nie
są zatem odporne na przerwy w komunikacji między węzłami.
• W praktyce oznacza to, że bazy takie nie najlepiej sprawdzają
się jako systemy rozproszone (przerw w komunikacji nie da się
uniknąć). Chodzi zwłaszcza o sytuacje kiedy transakcja o
cechach ACID miałaby obejmować dane na wielu serwerach.
• Aby zminimalizować ten problem, przy partycjonowaniu bazy
relacyjnej trzeba zwracać uwagę, aby części danych
umieszczane na różnych partycjach były od siebie niezależne –
transakcje będą wówczas dotyczyły danych tylko w jednej
partycji.
BAZY
SZEROKOKOLUMNOWE
Wide Column Data Store
• Bazy szerokokolumnowe (z ang. wide column data store) są
przystosowane do przechowywania ogromnych ilości danych. W
niektórych publikacjach można również spotkać określenie „bazy
kolumnowe”.
• Większość popularnych rozwiązań szerokokolumnowych została
zaimplementowana jako klony projektu BigTable, stworzonego w
Google na potrzeby przechowywania danych dla m. in. wyszukiwarki
internetowej.
• Według Google w 2009 roku aplikacje firmy przetwarzały ponad 20
petabajtow informacji dziennie. Jednym z pomysłów, aby poradzić
sobie z taką ilością danych, jest ich rozdzielenie na większą ilość
serwerów (zgodnie z rachunkiem ekonomicznym: N serwerów o
mocy/pojemności X będzie tańsze od jednego serwera o
mocy/pojemności N*X).
Problemy podziału danych
• Takie podzielenie danych rodzi jednak pewne konsekwencje:
• Łączenie danych w tabelach rozproszonych na wielu maszynach
staje się w praktyce niewykonalne w akceptowalnym czasie.
• Ponieważ każdy z serwerów ma pewne prawdopodobieństwo
niedostępności (np. spowodowanej brakiem połączenia sieciowego
lub awarią sprzętową), wzrost liczby serwerów powoduje, że
wzrasta prawdopodobieństwo niedostępności jednego z węzłów w
klastrze.
• Jednym z parametrów określających dysk twardy jest współczynnik
AFR (Annualized Failure Rate, stopień awaryjności w roku). Nawet
jeśli AFR wynosi około 0,5% (jak w przypadku dysków serwerowych
SSD), to przy dużej ilości takich dysków w klastrze można
spodziewać się, że kilka z nich ulegnie awarii.
• Na przykład, przy 200 dyskach z AFR 0,5%, jest prawdopodobne, że
jeden z nich ulegnie awarii w ciągu roku.
Rozproszony system plików
• Bazy szerokokolumnowe są zaprojektowane w oparciu o
rozproszony system plików, który minimalizuje problemy
podziału danych.
• Rozproszony system plików zapewnia, że wszelkie dane
są duplikowane i zapisywane na wielu serwerach,
włączanie i wyłączanie pojedynczych węzłów nie
przerywa pracy systemu a pojemność bazy można
rozszerzać dynamicznie w trakcie jej normalnego
działania poprzez dodanie nowych węzłów.
Klaster serwerów z replikacją danych
W rozproszonym systemie plików każdy podzbiór danych jest przechowywany
w wielu kopiach. Co ważne – pliki są dzielone na mniejsze części i losowo
przydzielane do serwerów.
Awarie serwerów
Mimo niedostępności części węzłów w klastrze (w związku z większą ilością serwerów
prawdopodobieństwo awarii jest również większe) w systemie nadal wszystkie dane
są dostępne.
Dzięki replikacji zmniejsza się prawdopodobieństwo, że część danych będzie zupełnie
niedostępna (aby część danych była zupełnie niedostępna musi zajść: albo awaria
większej ilości węzłów, albo niedostępność dokładnie tych węzłów, które przechowują
tę samą część danych).
Cechy baz szerokokolumnowych
• Każda tabela w bazie to zbiór wierszy.
• Każdy wiersz posiada klucz główny – jednoznacznie go
identyfikujący.
• W każdym wierszu może istnieć dowolna ilość kolumn (o
dowolnych unikatowych nazwach). Kolumny można
dodawać dynamicznie. W niektórych implementacjach
kolumny mogą być pogrupowane w tzw. rodziny (ang.
column families).
• Wiersze w tabeli i kolumny w wierszu są przechowywane
w uporządkowanej kolejności.
• Każdy wiersz jest zamkniętą całością – w bazie nie ma
wbudowanej możliwości łączenia tabel.
Przykład
• Pierwsza kolumna zawiera identyfikator wiersza – dane są
przechowywane w uporządkowanej kolejności.
• Druga kolumna reprezentuje wartości w wierszu, w przykładzie
pokazana jest baza danych wspierająca rodziny kolumn. W każdym
wierszu projekty i dane oznaczają właśnie rodziny kolumn, są one
stałe dla tabeli bazy.
• Lista kolumn w wierszach nie jest natomiast ustalona, może być inna
dla każdego wiersza.
Fizyczny zapis
• W fizycznej reprezentacji rożne rodziny kolumn mogą być
przechowywane jako osobne pliki (i na osobnych serwerach).
• Taki podział ma wpływ na wydajność, zatem w jednej
rodzinie powinny znaleźć się dane przetwarzanie wspólnie.
Podstawowe operacje
Operacja
Opis
get(klucz)
Pobranie wartości wg podanego klucza. Dodatkowym
parametrem może być lista kolumn do pobrania.
put(klucz, wartość)
Zapis wartości. Jeśli podany klucz już istnieje
w bazie, wartość zostanie nadpisana lub
zmodyfikowana. Jeśli klucz nie istnieje zostanie
dodany nowy wiersz.
delete(klucz)
Usuwanie wierszy wg podanego klucza.
scan(klucz1, klucz2)
Skanowanie tabeli, czyli pobieranie listy wartości
poczynając od klucz1 a kończąc na klucz2.
Uwaga: wiersze w bazie danych są uporządkowane wg
klucza.
Dodatkowym parametrem może być lista kolumn do
pobrania.
Podstawowe operacje
incr(klucz, kolumna) Operacja zwiększenie licznika atomowego. Aktualna
wartość jest zwiększana i nowa wartość zwracana jako
wynik operacji.
Atomowość polega na tym, że wszystko odbywa się
w jednym kroku – licznik gwarantuje, że żadne dwa
zapytania nie otrzymają nigdy tego samego wyniku.
Licznik może być przydatny do generowania unikalnych
kluczy.
Map-reduce
Wspierany jest model równoległego i rozproszonego
przetwarzania danych w klastrze (podobnie do obliczenia
wartości funkcji sumujących w bazach relacyjnych).
Przykłady zastosowań
• Indeksowanie i przetwarzanie danych o sieci Internet.
• Poza ogromną ilością danych do zapisania ważne są
luźne wymagania dotyczące schematu bazy – strony
internetowe nie mają wiele wspólnych elementów i trudno
wskazać stałą strukturę.
• Przykładowym kluczem może być słowo do wyszukania
danych lub adres strony internetowej.
• Indeksowanie Internetu było pierwotnym zastosowaniem
bazy BigTable w firmie Google.
Przykłady zastosowań
• Przechowywanie i przetwarzanie danych dla aplikacji
internetowych (o ogromnej ilości danych do zapisania),
gdzie ważny jest stały i szybki czas dostępu do każdego
fragmentu danych.
• Projekt HBase był wykorzystywany do indeksowania
wiadomości przesyłanych przez użytkowników aplikacji
Facebook.
• W tym przypadku kluczem dla danych może być
kombinacja identyfikatora użytkownika i słowo
wyszukiwania, natomiast wartościami w kolumnach są
teksty wiadomości użytkownika zawierające to słowo.
Przykłady zastosowań
• Przechowywanie i przetwarzanie rożnego rodzaju logów,
agregowanie danych z rożnych systemów (np. dane o transakcjach
bankowych, dane z systemów obsługujących sieci komórkowe).
• Dane takie są często gromadzone w celach przeprowadzania analiz
statystycznych. Uwaga: bazy szerokokolumnowe nie zawsze są
optymalnym rozwiązaniem dla analiz statystycznych – bardziej nadają
się one jako bazy OLTP.
• Jednak w pewnych przypadkach (np. w obszarach telekomunikacji i
bankowości), gdy pojedyncza transakcja składa się z kilku kroków
przeprowadzanych przez rożne systemy, informacje o tych krokach
mogą być umieszczone w wielu węzłach. Po wskazaniu klucza
transakcji baza szerokokolumnowa może być użyta do zagregowania
informacji z rożnych węzłów i następnie przeprowadzania analizy na
tak złączonych danych.
BigTable
• Baza stworzona w firmie Google, początkowo na potrzeby
wyszukiwarki internetowej. Baza BigTable nigdy nie
została upubliczniona, opublikowano jedynie ogólne
założenia dotyczące projektu.
• Baza BigTable jest również używana przez inne aplikacje
tej firmy, m.in. w Google App Engine. GAE jest platformą
pozwalająca hostować aplikacje internetowe.
• Przy pomocy dostępnego API aplikacje tworzone na tę
platformę mogą zapisywać i przetwarzać informacje w
udostępnionej instancji BigTable.
• https://developers.google.com/appengine/docs/java/datastore/
HBase
• Projekt utrzymywany przez Apache Software Foundation.
• Jest to (open source) klon bazy BigTable tworzony w
języku Java.
• HBase dodaje funkcjonalności bazy szerokokolumnowej
do frameworka Hadoop (platformy przechowywania i
przetwarzania dużej ilości danych w klastrze wielu
serwerów).
• http://hbase.apache.org/
Hypertable
• Podobnie jak HBase – jest to otwarta (open source)
implementacja założeń BigTable. Projekt jest tworzony w
C++.
• http://hypertable.org/
Cassandra
• Baza danych utrzymywana przez Apache Software
Foundation. Przykład projektu, który nie powstał jako klon
BigTable.
• W przeciwieństwie do innych wymienionych powyżej baz
wszystkie serwery w klastrze Cassandry są równorzędne
(w przypadku baz opartych na BigTable pojedyncze
serwery spełniają rożne role w systemie).
• http://cassandra.apache.org/
BAZY KLUCZ-WARTOŚĆ
Memcached
• Bazy klucz-wartość są bardzo prostą formą bazy danych.
Z założenia przechowują one tylko pary: klucz + wartość.
Można pobrać daną wartość tylko wtedy, gdy klucz jest znany.
• Wiele języków programowania oferuje podobne proste
struktury danych (nazywane listami, słownikami, mapami lub
tablicami asocjacyjnymi).
• Operacje na tak prostym modelu danych mogą być bardzo
wydajnie. Dodatkowy wzrost wydajności można osiągnąć
przechowując całą bazę w pamięci RAM serwera.
• Jednym z pierwszych projektów tego typu był Memcached –
prosta baza danych do wykorzystania jako bardzo szybka
pamięć podręczna dla aplikacji przetwarzających dane.
Bazy przechowywane w pamięci RAM
• Bazy przechowywane w pamięci RAM (ang. in-memory
datastores) pozwalają osiągnąć ogromną wydajność.
Bazy danych tego typu pozwalają również na trwałe
zapisywanie danych na dysku twardym, jednak zawsze
istnieje ryzyko, że w razie awarii (np. zasilania) część
danych zostanie utracona.
Bazy łatwo skalowalne
• Bazy łatwo skalowalne (ang. massively scalable
datastores) – dzięki prostemu modelowi, dane w bazie
można łatwo rozdzielać na wiele serwerów.
• Dynamiczne dodawanie i usuwanie węzłów w klastrze i
rozdzielanie zakresów kluczy do rożnych węzłów jest
prostsze niż w przypadkach bardziej skomplikowanych
struktur danych.
• Tego typu bazy niewiele różnią się od baz
szerokokolumnowych.
Operacje
• Podstawowe operacje, jakie można wykonywać na bazie klucz-
wartość nie różnią się od operacji w bazach szerokokolumnowych.
Jest to wynikiem podobieństwa modelu danych, główną różnicą jest
to, że w bazach szerokokolumnowych wartość przypisana do klucza
może mieć bardziej złożoną strukturę. Podstawowe operacje to:
• dodawanie pary klucz-wartość (jeśli klucz już istnieje to wartość
zostanie zmieniona),
• usuwanie klucza (razem z przypisaną wartością),
• pobieranie wartości wg klucza,
• skanowanie zakresu kluczy,
• liczniki atomowe,
• większość baz tego typu wspiera również przetwarzanie mapreduce.
Operacje
• Poszczególne produkty rozbudowują podstawowy zbiór
operacji o dodatkowe funkcjonalności. Np. baza Redis
zawiera wiele operacji, potrzebnych do obsługi
wspieranych struktur danych (zarządzanie wartościami w
listach, stosach i zbiorach).
Operacje
• Charakterystyczną funkcjonalnością dla niektórych baz
klucz-wartość jest możliwość zapisu danych z
określeniem jak długo mają one istnieć (parametr TTL Time to Live, czas życia). Po podanym czasie zapisane
wartości stają się niedostępne. Taka funkcjonalność jest
szczególnie przydatna przy tworzeniu pamięci
podręcznych.
• Część baz klucz-wartość – tych zaprojektowanych do
szybkiego przetwarzania w pamięci – oferuje transakcje
podobne do operacji na relacyjnych bazach danych
(spełniające warunki ACID).
Przykłady zastosowań
• Bazy łatwo skalowalne – dla aplikacji internetowych i przetwarzania
w chmurze (podobnie jak w przypadku baz szerokokolumnowych).
• Dla wielu aplikacji istnieje potrzeba tymczasowego zwiększania skali
działania. Na przykład sklep internetowy sprzedający bombki
choinkowe będzie miał niewielkie potrzeby obliczeniowe przez
większość roku i nagły ich wzrost w grudniu. Przetwarzanie w
chmurze i platformy hostingowe (platform as a service) pozwalają w
takiej sytuacji wynająć potrzebne serwery tylko na czas zwiększonego
zapotrzebowania.
• Tradycyjne bazy relacyjne nie sprawdzą się w takim przypadku
ponieważ dynamiczne dodawanie serwerów w trakcie działania
aplikacji nie jest możliwe.
• Niektóre bazy szerokokolumnowe również sprawdzają się w takich
sytuacjach (np. platformy Google App Engine oferująca dostęp do
BigTable).
Przykłady zastosowań
• Pamięć podręczna – zgodnie z nazwą do baz o prostym
modelu danych i przechowywanych w pamięci RAM.
• Nagła awaria i utrata danych z pamięci RAM nie jest dla
tych baz problemem – oznacza po prostu wyczyszczenie
pamięci podręcznej. Wartości przechowywane w bazie
mogą być następnie odtworzone.
Przykłady zastosowań
• Przetwarzanie w czasie rzeczywistym – ogromna szybkość
przetwarzania danych w pamięci RAM sprawia, że bazy tego typu
sprawdzają się w sytuacjach, gdzie zmiany na danych muszą być
natychmiast widoczne, na przykład w grach MMORPG (Massively
Multiplayer Online Role-Playing Game)
• Ogromna ilość użytkowników łączy się przez Internet z serwerem gry,
postać reprezentująca każdego użytkownika (tzw. awatar) może
poruszać się w trójwymiarowej przestrzeni. Użytkownicy widzą
nawzajem swoje awatary – informacja o ruchu pojedynczego gracza
na planszy musi być bardzo szybko przekazywana do pozostałych
uczestników gry.
• W przypadku awarii serwera niezapisane dane z pamięci RAM mogą
zostać utracone. Uczestnicy gry „wrócą” wówczas do swoich
punktów kontrolnych w grze. Wystarczy więc aby osiągnięcie przez
użytkowników punktów kontrolnych było trwale zapisane.
Przykłady zastosowań
• Web Storage – jest to część standardu HTML 5, ma ona pozwalać
stronom internetowym na zapisywanie danych na komputerze
użytkownika.
• Oferuje bogatszy interfejs, możliwość przechowywania danych wielu
sesji dla tej samej witryny, a przede wszystkim udostępnia więcej
miejsca (5-25 MB, w zależności od implementacji, w porównaniu do
około 4 KB dostępnych dla ciasteczek).
• Każda witryna, za pomocą API, może utworzyć na dysku użytkownika
własny magazyn danych, przechowywanych jako pary klucz-wartość,
w postaci łańcuchów tekstowych.
• Jednocześnie zapewniane są dobre mechanizmy bezpieczeństwa,
pozwalające na kasowanie danych po określonym przez użytkownika
czasie, tworzenie białych i czarnych list dostępu, a w połączeniu z
protokołem TLS, na ochronę przed nieuprawnionym dostępem przez
sfałszowane witryny internetowe.
Redis
• Zaawansowana baza typu klucz-wartość. Pozwala
przechowywać dane tylko w pamięci RAM oraz
opcjonalnie zapisywać je na dysk twardy w określonych
odstępach czasu.
• Wartościami mogą być złożone struktury danych (zbiory,
listy, mapy).
• Baza wprowadza prosty mechanizm kolejkowania danych
(nazywany pub/sub od publish/subscribe).
• Redis jest projektem typu open-source.
• http://redis.io
BerkeleyDB
• Baza utworzona na Uniwersytecie Berkeley, aktualnie
zarządzana przez firmę Oracle.
• Jest to biblioteka zapewniająca prostą bazę wbudowaną
typu klucz-wartość (analogicznym produktem w świecie
baz relacyjnych jest baza SQLite).
• BerkeleyDB jest używana do zapisu danych w wielu
popularnych projektach (warto wspomnieć Subversion,
RPM Package Manager), co więcej jest często
wykorzystywana jako komponent w bardziej złożonych
projektach.
• http://www.oracle.com/us/products/database/berkeleydb/overview/index.htm
DynamoDB
• Baza firmy Amazon.com udostępniana jako część Amazon Web
Services (AWS). AWS to zestaw usług sieciowych tworzących
platformę przetwarzania w chmurze.
• Użytkownicy płacą za używane zasoby komputerowe. Ważną cechą
jest łatwa skalowalność usług (zasoby są dynamicznie zwiększane
lub zmniejszane według aktualnego zapotrzebowania).
• Założenia projektowe dotyczące bazy zostały opublikowane przez
Amazon.com. Główny nacisk położono na zapewnienie łatwej
skalowalności i dostępności – dokument opisuje mechanizmy
zarządzania węzłami w klastrze, natomiast przechowywanie danych
na poszczególnych węzłach jest delegowane do prostszych baz typu
klucz-wartość (w pierwotnej implementacji była to baza BerkeleyDB).
Riak
• Implementacja założeń Amazon Dynamo w języku Erlang
stworzony przez firmę Basho Technologies typu open
source.
• Podobnie jak w przypadku innych projektów NoSQL dla
rożnych języków programowania tworzy się tzw.
sterowniki, podobne do sterowników ODBC w przypadku
baz relacyjnych.
• Riak pozwala dobierać mechanizm zapisu danych w
węzłach (obsługiwane jest kilka baz klucz-wartość).
Domyślnie używaną bazą jest Bitcask, prosty mechanizm
klucz-wartość stworzony również przez Basho
Technologies.
• http://basho.com/riak/
BAZY DOKUMENTÓW
Bazy dokumentów
• Bazy dokumentów skupiają się na przechowywaniu i
przetwarzaniu dokumentów - jednostek danych o luźno
określonej strukturze i pewnym formacie zapisu (np. XML,
YAML, JSON).
• Dokumenty w bazach nierelacyjnych mogą mieć
własności (nazywane również polami) i są identyfikowane
przez unikalny dla każdego klucz. Dodatkowo rożne
produkty będą pozwalały porządkować dokumenty na
rożne sposoby (poprzez kolekcje, tagi, hierarchie
katalogów i inne).
Przykład dokumentu w formacie JSON
{
Tytuł: "Quo vadis",
Autor: "Henryk Sienkiewicz",
Rodzaj: "powieść historyczna"
},
{
Tytuł: "Pan Tadeusz",
Autor: "Adam Mickiewicz",
Postacie: [
{Imię: ["Jacek Soplica", "ksiąd Robak"]},
{Imię: "Tadeusz Soplica"},
{Imię: "Telimena"}
]
}
Cechy dokumentów
• Dokumenty nie mają jednolitej struktury (w
przeciwieństwie do wierszy w tabeli bazy relacyjnej
dokumenty mogą mieć rożne pola),
• Nawet jeśli dokumenty mają pola o takiej samej nazwie,
to mogą one różnić się typem danych,
• Pola mogą mieć kilka wartości,
• Dokumenty mogą być zagnieżdżone (wartością pola
dokumentu może być inny dokument).
Operacje
• Podstawowe operacje udostępniane przez bazy dokumentów są
podobne jak w innych bazach danych: utworzenie, pobieranie,
aktualizacja i usuwanie dokumentu wg podanego klucza (operacje
CRUD - create, retrieve, update, delete).
• Bazy dokumentów często wewnętrznie używają zapisów, które mogą
być przetwarzane bezpośrednio w aplikacjach klienckich (np. JSON
jest bardzo łatwo przetwarzany w Javascript).
• Dodatkowe możliwości przetwarzania dokumentów:
• a) indeksowanie dokumentów wg pól,
• b) zaawansowane funkcjonalności przeszukiwania dokumentów
(język wyrażeń podobny jak w języku SQL, dodatkowo wbudowane
przetwarzanie wyrażeń regularnych),
• c) możliwości agregacji dokumentów wg wskazanych warunków,
• d) obsługa map-reduce
70
Przykłady zastosowań
• Aplikacje webowe - bazy dokumentów pozwalają
zwiększyć skalę działania znacznie niższym kosztem niż
bazy relacyjne.
• Prosty format w jakim przesyłane są dane między
serwerem bazy a klientami pozwala uprościć architekturę
aplikacji.
• Proste protokoły komunikacji umożliwiają aplikacjom
łączenie się bezpośrednio z bazą danych. W przypadku
technologii relacyjnych najczęściej na serwerze
uruchamiany jest komponent pośredniczący między
aplikacjami a bazą danych.
• Uproszczenie architektury może być przydatne w
przypadku szybkiego tworzenia prototypów aplikacji.
Architektura aplikacji
Przykłady zastosowań
• Aplikacje mobilne mogą mieć takie same wymagania
dotyczące ilości danych jak tradycyjne aplikacje z
interfejsem webowym.
• W przypadku aplikacji mobilnych duży nacisk kładziony
jest na skalowalność: skala działania może drastycznie
wzrastać w krótkim czasie (na przykład na skutek
promocji).
• Niektóre bazy dokumentów pozwalają na tymczasowe
rozłączanie klienta z serwerem, po ponownym połączeniu
następuje synchronizacja. Jest to przydatne w przypadku
aplikacji mobilnych, kiedy połączenie internetowe zostanie
utracone – aplikacja może nadal działać zapisując dane
do lokalnej wersji bazy.
Przykłady zastosowań
• Big data - duża skalowalność baz dokumentów oraz brak
ścisłych wymagań dotyczących schematu danych
sprawia, że bazy dokumentów mogą być używane do
przechowywania dużej ilości danych w celach
analitycznych.
• W tym przypadku istotne jest wsparcie przetwarzania
map-reduce.
mongoDB
• Jedna z bardziej popularnych baz NoSQL. Nazwa
(fragment angielskiego słowa humongous, olbrzymi)
wskazuje na oryginalne przeznaczenie bazy: łatwo
skalowalna baza danych udostępniana jako usługa w
chmurze.
• MongoDB przechowuje dokumenty w formacie BSON (z
ang. binary JSON), rozszerzony standard JSON.
• http://www.mongodb.org/
CouchDB
• CouchDB - Cluster of Unreliable Commodity Hardware
Data Base (klaster sprzętu, na którym nie można polegać.
• Charakterystyczne cechy CouchDB:
• przeznaczony dla Internetu:
• dokumenty przechowywane są w formacie JSON,
• obsługa bazy jest wykonywana przez protokół HTTP,
• można modyfikować dokumenty w języku Javascript.
• Projekt jest aktualnie zarządzany przez Apache Software
Foundation.
• http://couchdb.apache.org/
Couchbase
• Baza ta zainspirowana jest poprzednim produktem i w
wielu miejscach podobna (rozwijana często przez ten
samą grupę programistów).
• Ważną jej cechą jest obsługa protokołu Memcached. Co
za tym idzie baza dodaje wsparcie dla przechowywanej
tylko w RAM pamięci podręcznej.
• Podobnie jak podobnie jak w poprzednim przypadku
oprogramowanie jest udostępniane na licencji Apache
2.0.
• http://www.couchbase.com/
INNE TYPY BAZ NOSQL
Bazy grafowe
• Bazy grafowe stosują reprezentację danych jako grafy: węzły i
krawędzie. Krawędzie są powiązaniami łączącymi węzły.
• Bazy grafowe wspierają operacje na tego typu strukturach danych
oraz szybkie obliczenia własności grafów (np. najkrótszej ścieżki
między wybranymi węzłami, znajdowanie sąsiedztwa węzła).
Zarówno węzły jak i krawędzie mogą mieć przypisane własności.
• Bazy grafowe nie wymagają stosowania sztywnego schematu
danych: własności mogą być dodawane ad-hoc. Ponadto
zastosowana struktura danych sprawia, że nie jest wymagana
operacja łączenia jak w przypadku baz relacyjnych. Dzięki temu bazy
grafowe skalują się łatwiej niż bazy relacyjne na większą ilość
serwerów.
• Przykładami baz grafowych są:
• Neo4j, http://www.neo4j.org/,
• OrientDB. http://www.orientechnologies.com/orientdb/.
Bazy obiektowe
• Bazy obiektowe rozwijają się od lat 80-tych poprzedniego
wieku, razem z obiektowymi językami programowania.
• Założeniem baz obiektowych jest reprezentowanie
danych w takiej samej strukturze, jak w obiektowym
języku programowania.
• Zachowane miały być m. in. Dane o obiektach,
powiązania między nimi i informacje o dziedziczeniu.
Operacja zapisania danych do bazy obiektowej nie
wymaga konwersji czy dekompozycji.
Bazy obiektowe a grafowe
• Własności węzłów w bazie grafowej są bardziej elastyczne niż
•
•
•
•
•
własności obiektów (ustalone dla każdej klasy).
Schemat danych w bazie grafowej jest ustalany dynamicznie poprzez
przypisywanie własności, w bazach obiektowych schemat danych
odpowiada modelowi klas.
Większa elastyczność krawędzi w grafie niż relacji między obiektami.
Krawędź grafu może reprezentować dowolną relację, również
dwukierunkową, może ona mieć swoje własności. W modelu
obiektowym trudniej opisać takie powiązania.
Łatwiejsze tworzenie aplikacji operującej na bazie grafowej.
Przykłady baz obiektowych:
• Cache, http://www.intersystems.com/our-products/cache/cache-overview/,
• Db4o, http://www.db4o.com/.
Silniki wyszukiwarek
• Silniki wyszukiwarek to grupa narzędzi służąca do przechowywania
danych. Nacisk kładziony jest na przeszukiwanie zapisanych
informacji. Wyszukiwarki były tworzone z myślą o przetwarzaniu
danych tekstowych i języka naturalnego. Informacje zapisywane są
jako dokumenty, mogą one posiadać określoną strukturę (dla
dokumentów określa się własności i ich typy).
• Główne cechy silników wyszukiwarek:
• wsparcie dla złożonych kryteriów wyszukiwania, również
dynamicznego filtrowania (nawigacji fasetowej),
• zaawansowana obsługa informacji tekstowych: wyszukiwanie wg
fragmentu tekstu, szukanie przez synonimy lub brzmienie słów,
• grupowanie i ranking wyników wyszukiwania wg najlepiej
dopasowanych.
• ze względu na brak relacji między dokumentami łatwa
skalowalność na wiele serwerów.
Silniki wyszukiwarek
• Mechanizmy współczesnych silników wyszukiwarek są na
tyle elastyczne, że produkty te mogą być używane jako
baza danych dla specyficznych zastosowań (np. przy
przetwarzaniu dużej ilości logów: w danych takich można
wskazać pewne pola/własności, jednak wpisy nie mają
określonej struktury).
• Przykłady:
• Solr, http://lucene.apache.org/solr/,
• Elasticsearch, http://www.elasticsearch.org/.