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 ns (DDR5) (1 ns = 10 9 s) i jest wielokrotnie mniejszy od czasu dostępu do twardego dysku: dysku magnetycznego: od 100 do 14 milisekund ( 1 ms = 10 3 s ) dysku SSD do 12 mikrosekund (1 μs = 10 6 s) 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 get(klucz) put(klucz, wartość) delete(klucz) scan(klucz1, klucz2) Opis Pobranie wartości wg podanego klucza. Dodatkowym parametrem może być lista kolumn do pobrania. 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. Usuwanie wierszy wg podanego klucza. 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 kluczwartość 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-reduce70
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/.