Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

NoSQL

No description
by

Piotr Salata

on 13 June 2017

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of NoSQL

Podstawy NoSQL
NoSQL
Co to jest NoSQL?

Problemy baz relacyjnych

Cechy baz NoSQL

Rodzaje baz NoSQL

Paradygmaty i mechanizmy

Co to jest NoSQL?
NoSQL = Not only SQL

Ruch, idea - NIE określona, specyficzna technologia

Rezygnacja z relacyjnego modelu danych i mechanizmów zaawansowanych systemów baz danych
Problemy baz relacyjnych
"One Size Fits All"
nie działa!

Wysoka złożoność i komplikacja nie zawsze potrzebnych mechanizmów

Trudność skalowania i problem w działaniu na tanim sprzęcie

Niekompatybilność modeli aplikacji i bazy danych,
rozwój nowoczesnych środowisk programistycznych
Cechy baz NoSQL
Elastyczne skalowanie poziome

Elastyczny model danych (ew. brak modelu)

Specyficzny język danych

Big Data

Uproszczona administracja

Uproszczone mechanizmy, wydajność

Ekonomia, tani sprzęt
Rodzaje baz NoSQL
Klucz-wartość

Dokumentowe, XML

Kolumnowe/tablicowe

Obiektowe

Grafowe

Wielomodelowe
Struktury dyskowe (wszystkie dane i indeksy)

Dostęp do danych zależny od optymalizatora

Transakcyjność

Synchronizacja oparta na blokadach

Trwałość danych oparta na dziennikach

Wieloprocesowość, wielowątkowość
Mit o użyteczności jednego modelu danych do wszystkich zastosowań (relikt czasów systemów OLTP)

Statyczność, niezmienność modelu, kontrola danych

Obligatoryjność mechanizmów RDBMS

Mit o bezproblemowym i
transparentnym
rozpraszaniu danych

Cloud Computing
?
Obiektowe języki - baza relacyjna

ORM - komplikacja i dodatkowy narzut

Różnica koncepcyjna metod dostępu

Zamkniętość mechanizmów RDBMS
Architektura z czasów komputerów mainframe - centralizacja
(shared memory)

Wymóg dużej mocy obliczeniowej serwera

Skomplikowana i niewydajna architektura baz rozproszonych
Baza bez schematu

Zastosowanie: szybkie przetwarzanie prostych danych, zarządzanie zawartością

Przykłady: Amazon Dynamo, Aerospike, ArrangoDB, Cassandra, Redis, Riak, Oracle NoSQL

Zalety: szybki dostęp do danych, wysoka dostępność
Baza zorientowana na przechowywanie dokumentów

Zastosowanie: zarządzanie dokumentami, aplikacje www

Przykłady: CouchDB, DocumentDB, MongoDB, MarkLogic, IBM Domino (Lotus Notes), OrientDB

Zalety: łatwe operowanie na dokumentach, dynamiczny model danych (XML)
Baza z obiektowym modelem danych

Zastosowanie: aplikacje ze złożonym modelem danych

Przykłady: Versant OD, Objectivity, ObjectStore, DB4O, ZopeDB

Zalety: efektywne przetwarzanie danych (łatwe powiązanie baza-aplikacja)
Baza o kolumnowej reprezentacji danych

Zastosowanie: zbieranie i przetwarzanie dużej ilości prostych danych

Przykłady: Apache Cassandra, Google Bigtable, HBase, Hypertable, SAP HANA, Vertica

Zalety: szybki zapis danych, wysoka dostępność, bardzo duża skalowalność
Baza dedykowana do reprezentacji danych grafowych

Zastosowanie: przetwarzanie powiązanych danych, sieci społecznościowe i inne (transport, telekom, ...)

Przykłady: ArangoDB, InfiniteGraph, Neo4J, Apache Giraph. OrientDB

Zalety: efektywne wykonywanie algorytmów grafowych
Paradygmaty NoSQL
BASE:
B
asically
A
vailable
S
oft-state
E
ventually consistent

CAP:
C
onsistency
A
vailability
P
artition-tolerance


Consistency
Availability
Partition-tolerance
(ACID)
Partition-intolerance
(BASE)
Inconsistency
Unavailability
2 z 3
AP:
Dynamo, Voldemort, Cassandra, SimpleDB, CouchDB, Tokyo Cabinet
CP:
BigTable, MongoDB, Hypertable, HBase, Terrastore, BerkeleyDB, MemcacheDB, Cassandra
CA:
Vertica, MarkLogic
Podstawowe
mechanizmy

Partitioning, Sharding

Hinted Handoff, Read-repair,
Anti-entropy repair

Memory Cache

Consistent Hashing

Multiversion Storage, MVCC

Vector Clock

Gossip
San Francisco 2009:

"NoSQLers came to share how they had overthrown the tyranny of slow, expensive relational databases in favor of more efficient and cheaper ways of managing data"
Motywacja
Unikanie zbędnej złożoności mechanizmów

Wysoka wydajność i przepustowość

Skalowalność horyzontalna, tani sprzęt

Pozbycie się niezgodności modeli: programistycznego i bazodanowego
Orientacja na wydajność operacji (zamiast na poprawność danych)

Proste mechanizmy dostępu do danych (zamiast skomplikowanych funkcji interpretacji SQL)

Wykorzystanie znajomości struktury i mechanizmów dostępu (zamiast niezależności fizycznej i optymalizacji zapytań)

Jednowątkowość prostych i szybkich operacji, brak potrzeby synchronizacji
ACID:

A: wystarczająca na poziomie poleceń

C: często nadmiarowa na poziomie bazy

I: często zbędna (brak konfliktów)

D: możliwa do zrealizowania w inny sposób
Ułatwienie programowania, prostsze środowisko; jednolity model, brak potrzeby ORM, brak konieczności wbudowywania zapytań SQL w kod

Zysk wydajnościowy

Łatwość obsługi niestandardowych
typów danych
Trwałość, integralność:

Zastąpienie rozwiązań (w założeniu) pewnych mechanizmami opartymi na prawdopodobieństwie:

Trwałość zapewniona przez redundancję (równoczesna awaria 3 lub więcej instancji jest bardzo mało prawdopodobna)

Izolacja przez małe prawdopodobieństwo równoczesności
Akceptacja braku możliwości zapewnienia sprzętu z góry wyskalowanego na system docelowy

Użycie dużej liczby tanich elementów dostosowywanych w miarę potrzeb

Rozproszenie geograficzne

Skalowalność jako podstawowe założenie (a nie jako specjalna, droga cecha dodatkowa)
Przykłady
Apache Cassandra

MarkLogic

Apache Cassandra
Baza postrelacyjna - połączenie 2 rozwiązań:
Amazon Dynamo (architektura rozproszona)
Google BigTable (model kolumnowy)
Architektura węzłów równorzędnych, możliwość rekonfiguracji online - wysoka skalowalność
Konfigurowalna replikacja - wysoka dostępność, odporność na awarie
Dwie opcje spójności: BASE/ACID (AP/CP)
Wsparcie dla przetwarzania rozproszonego
Model danych
Model oparty na strukturze kolumnowej:
podobny do relacyjnego, lecz elastyczniejszy (
column family
z możliwością dynamicznego dodawania kolumn)
brak odpowiednika kluczy obcych - konieczność denormalizacji
pełne możliowści indeksowania - kluczy i innych kolumn
Operacje na danych
Język bazy danych: CQL - wzorowany na składni SQL
większość poleceń znanych z SQL
brak operacji JOIN
brak możliwości wyszukiwania części klucza
Wyszukiwanie pełnotekstowe dzięki integracji z narzędziami:
Apache Solr/Lucene
DataStax Enterprise Search
API dla wielu języków: Java, C#, Ruby, Perl, Python
Wsparcie dla MapReduce
Integracja z Hadoop

Apache Pig - platforma programowania MapReduce z językiem Pig Latin

Apache Hive - platforma BI oparta na Hadoop
MarkLogic
Baza XML o mechanizmach transakcyjnych
Architektura dwuwarstwowa: D-nodes, E-nodes, możliwość rekonfiguracji online - wysoka skalowalność
Konfigurowalna replikacja - wysoka dostępność, odporność na awarie
Transakcje ACID
Wsparcie dla przetwarzania rozproszonego
Model danych
Model oparty na strukturze XML:
model dynamiczny oparty na schematach XSD i metadanych
pełne możliowści indeksowania - zawartość oraz metadane: indeksy zwykłe, XML, skalarne, odwrócone, pełnotekstowe, przestrzenne

Wielowersyjna baza danych (aktualizacja = nowa wersja)
Operacje na danych
Języki danych: XQuery i XSLT, JSON
wyszukiwanie atrybutów, wartości
wyszukiwanie zakresowe
wyszukiwanie pełnotekstowe
wyszukiwanie przestrzenne
jest implemetacja operacji złączenia
zapytania odwrócone (jakie zapytania odnoszą się do określonych danych?)
Dostęp przez XDBC (wiele języków, m.in. Java, C#)
Wymiana danych przez WebDAV
Wsparcie dla MapReduce
Integracja z Hadoop:
jako źródło danych przez konektor
jako warstwa dostępu do danych nad HDFS


Wielowersyjna kontrola współbieżności (MVCC)
Sharding
partycjonowanie rozproszone na wiele węzłów
replikacja małych struktur pomiędzy węzły
Zalety
możliwość wykorzystania słabszego sprzętu przy bardzo dużej ilości danych
wzrost wydajności - przetwarzanie równoległe
wzrost dostępności (części danych - BASE)
ułatwienie administrowania - mniejsze wolumeny
Sharding
Wady
wzrost złożoności i komplikacji (system i aplikacja)
trudność realizacji pewnej klasy zapytań
dodatkowy narzut na replikację i utrzymanie spójności
wrażliwość na parametry łączności pomiędzy serwerami
obniżenie dostępności (pełnych danych - ACID)
utrudnienie administrowania - złożona struktura
Mechanizm obsługi sytuacji awaryjnej
Hinted Handoff
Zapis danych do działającego węzła zamiast do węzła uszkodzonego, aby zachować kworum

Dane są zapisywane z podpowiedzią ("hint"), aby przepisać je do węzła docelowego, gdy tylko będzie to możliwe.
Mechanizm obsługi niespójnosci
Read-repair
Podczas odczytu - zapis danych aktualnych do węzła, który zwrócił dane o nieaktualnej wersji

Odczyt jest spowolniony, ale poprawia to spójność danych

Stosowany w bazach, w których optymalizowana jest szybkość zapisu
Consistent Hashing
Mechanizm funkcji mieszającej przypisujący wartości do poszczególnych węzłów bazy w sposób pozwalający łatwo usuwać i dodawać węzły
Mechanizm obsługi niespójnosci
Anti-entropy repair
Mechanizm uzgadniania replik na podstawie analizy drzew hashujących (Merkle'a)

Szybkie porównanie wartości funkcji w drzewie - wykrycie różnic pomiedzy replikami

Synchronizacja wykrytych różnic na podstawie wersji
#4346
#2924
#6221
#1945
#3586
#5023
#7202
#1945
#2924
#3586
#4992
#7202
#6987
#5158
Vector Clock
Mechanizm oznaczania danych znacznikami zdarzeń (nie czasu) pozwalający okreslić relację częściowego porządku w zbiorze danych w systemie rozproszonym.

Dzięki temu wiadomo, czy dane są od siebie zależne, czy niezależne.

Pozwala to wykryć sytuacje, w których:
mamy do czynienia z kolejnymi wersjami danych
dane pochodzą z dwóch niezależnych źródeł i może być konieczne rozwiązanie konfliktu.
Vector Clock
Na początku wszystkie zegary mają wartość 0
Węzeł inkrementuje swój zegar przy każdym zdarzeniu (modyfikacji danych)
Z każdym komunikatem rozsyłany jest cały wektor zegarów
Przy odbiorze komunikatu węzeł inkrementuje swój zegar i aktualizuje pozostałe na wartości maksymalne (własna/otrzymana)
Vector Clock
B jest następcą A
B i C są niezależne, B i E są niezależne
E jest następcą C
F jest następcą A, B, C, D, E
A
B
C
E
D
F
Gossip
Protokół komunikacji pomiedzy węzłami bazy rozproszonej działający w tle:
cykliczna wymiana małych komunikatów pomiędzy losowymi węzłami
niska częstotliwość - pomijalny narzut
aktualizacja stanu agentów
brak gwarancji niezawodnośći komunikacji
Gossip
Wykorzystywany do:
wymiany informacji o stanie klastrów i węzłów
wykrywania awarii
uzgadniania niespójnych danych (Anti-entropy)
wyliczania i agregacji informacji
Różnorodne bazy pozwalające na mieszanie modeli danych

Zastosowanie: przetwarzanie różnorodnych danych, strukturalnych i niestrukturalnych

Przykłady: ArangoDB, Couchbase, MarkLogic, OrientDB

Zalety: możliwość przechowywania i przetwarzania różnorodnych danych, wiele mechanizmów w jednym systemie
(nawet sam Eric Brewer nie ma pewności, co to znaczy)
Full transcript