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

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

NoSQL

No description
by

Piotr Salata

on 26 January 2014

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
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ń (model relacyjny był tworzony w czasach systemów OLTP)

Statyczność, niezmienność modelu, kontrola danych

Obligatoryjność mechani
zmó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

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, Tokyo Cabinet/Tyrant, Redis, Voldemort

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

Zastosowanie: zarządzanie dokumentami, aplikacje www

Przykłady: CouchDB, MongoDB, MarkLogic, Lotus Notes

Zalety: dynamiczny model danych
Baza z obiektowym modelem danych

Zastosowanie: aplikacje ze złożonym modelem danych

Przykłady: Versant, Objectivity, DB4O

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

Zalety: szybki zapis danych, wysoka dostępność
Baza dedykowana do reprezentacji danych grafowych

Zastosowanie: przetwarzanie powiązanych danych, sieci społecznościowe

Przykłady: Neo4J, InfoGrid

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

Memory cache

Consistent Hashing

Multiversion Storage

Vector Clock

Gossip

MapReduce
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ść

Skalowlność 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ść:

Zastapienie rozwiązań 100% 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)
Full transcript