NoSQL

Mer av detta

5_Eloadas

av Boti Végh

Kényszerek

av Petra Páncsity

Index, nézet, trigger

av Erdélyi Dániel

Adatbázis-kezelő rendszer választása

av Farkas Norbert

Adatbázis rendszerek és jellemzőik

A gondolattérkép a 14. heti előadás diáiból, valamint az órán elhangzottakból készült. Ahol nincs forrás megjelölve, ott ezek az információk kerültek felhasználásra.

Cap tétel

A tételt először Eric Brewer fogalmazta meg, miután több skálázhatósági problémával találkozott különböző rendszereken.

A tétel kimondja, hogy egy elosztott rendszer nem képes egyszerre teljesíteni a

• konzisztencia(consistency),
• hozzáférhetőség (availability)
• partíció tolerancia(partition tolerance)

által támasztott követelmények.

A valós életben használt rendszereknél igyekeznek úgy kialakítani az architektúrát, hogy a három alap képesség mindegyikével, ha korlátozottan is, de rendelkezzen a rendszer. Ezt úgy érik el, hogy az egyes képességekből engedményeket tesznek egy másik képesség javára. Egy rendszer csak kettő tulajdonságot valósíthat meg a háromból.

Forrás:http://weblabor.hu/cikkek/nosql-bevezeto

CP

(Consistency + Partition tolarence): Konzisztens működés várható el ezektől a rendszerektől, és a hálózat elválása esetén is működnek, de cserébe romlik a hozzáférhetőség. A következő rendszereket lehet ide sorolni: Bigtable, HBase, MongoDB, Redis, Scalaris

AP

 (Availability + Partition tolerance): Ezek a rendszerek a lehetőségekhez képest mindig elérhetőek, és jól működnek a hálózat szétesése esetén is, cserébe feladják a konzisztens működést. Ilyenek például: Cassandra, SimpleDB, CouchDB, Riak, Tokio Cabinet

CA

(Consistency + Availability): A konzisztenciát és a hozzáférhetőséget tartják szem előtt ezek a rendszerek, a hálózat szétesése esetén működésképtelenné válnak. Eszerint működő rendszerek: Oracle, MySQL, PostgreSQL, Vertica

Két értelmezése van

• Not Only SQL (az SQL-től teljesen eltérő nyelven és interfészen elérhető adattárolókat takart)

• NoSchema + NoTransactions + NoLanguage + NoStandards (Azok az adatbázisok ahol nincs séma, nincs tranzakció, nincs kivételes nyelv, nincsenek szabványok. Attól még adatbázis, mivel az adatok halmazát tárolja)

Fontos tudni, hogy a NoSQL nem egy konkrét termék, hanem egy termékcsalád.

Olyan elosztott adattárolókhoz készült, ahol nagy mennyiségű adattárolás szükséges (Facebook, Google, Amazon..)

A NoSQL adatbázisok elsősorban nem táblákban tárolják az adatokat, és általában nem használnak SQL nyelvet lekérdezésre.

A link egy videóra mutat, ahol nagy vonalakban bemutatják mi is az a NoSQL.

BASE

A BASE típusú rendszer elfogadja a CAP tételt, feladja a konzisztenciát és marad a hozzáférhetőség és a perfomancia.

A Base nagyon fontos koncepciója a NoSQL adatbázisok jelentős részének.

Forrás: http://www.w3resource.com/mongodb/nosql.php

Eventual consistency

Nincs minden pillanatban konzisztencia,de az egy idővel beáll.

Soft-state

A rendszerben az adatok módosulhatnak újabb inputok nélkül is.

(Tegyük fel, hogy "belájkoltam" valamit ezt nem látja mindenki, egyesek már igen, de egy idő után mások is fogják látni.)

Basically Available

A rendszer garantálja a rendelkezésre állást.

(Tehát bízom benne, hogy mindig működik a Facebook.)

Típusai

Jelenleg 4 főbb csoportját lehet elkülöníteni a NoSQL adatbázisoknak.

Forrás:http://weblabor.hu/cikkek/nosql-bevezeto

https://hu.wikipedia.org/wiki/NoSQL

Dokumentumtárak

A dokumentumtárolók központi koncepciója a dokumentum. A dokumentum valamilyen formátumban tárolt információ.A dokumentumok a relációs adatbázisok tábláinak rekordjaitól abban térnek el, hogy minden rekordnak ugyanazok a mezői vannak egy táblában, míg a dokumentumok teljesen eltérő struktúrával rendelkezhetnek.

(például: CouchDB, MongoDB, SimpleDB ) Ma ezek a legnépszerűbbek.

Gráf adatbázisok

A gráf-adatbázisok olyan adatok tárolására specializálódtak, amelyek jól modellezhetőek gráfként, azaz az adatok határozatlan számú kapcsolattal vannak összekötve.

(például: Neo4J, InfoGrid )

Oszlopcsaládok

( BigTable leszármazottak: Hbase, HyperTable , Cassandra, PNUT)

Kulcs -érték párok

A kulcs-érték adatbázisok séma nélküli adattárolást tesznek lehetővé, az értékeket a kulcsok segítségével lehet elérni illetve felülírni és ezen felül általában kevés műveletet támogatnak.

(például: Voldemort , Dynamo , Dynomite )

• Horizontális skálázhatóság (scale -out )
• Sokgépes környezet
• Egyszerű hívási felületek
• Konzisztencia részleges feladása
• RAM és elosztott indexek hatékony felhasználása
• Rugalmas sémaszerkezet

Relációs adatbázis vs NoSQL

A kérdés, hogy mikor kell használni relációs adatbázist vagy NoSQL alakút?

NoSQL

1. Ha az adatokat és kapcsolataikat egy helyen tároljuk, adatfeldolgozás igényei szerint csoportosulnak.
2. Nem SQL nyelvet alkalmazunk.
3. Ha fontos a sebesség és nem számít a konzisztencia
4. Ha nincs előre definiált séma, strukturálatlan adatokat tárolok
5. Ha fontos a rendelkezésre állás

RDBMS

1. Akkor használjuk, ha az adatok strukturáltak, szervezettek.
2. Ha az adatokat és kapcsolataikat nem vagyunk kénytelenek egy helyen tárolni. Egyes adatokat külön táblában tárolunk (osztályokat , dolgozókat külön tároljuk -->kapcsolatok alapján fogjuk őket összekötni)
3. Ha előre definiálható a DCL amelyekkel jogosultságokat adok és definiálom hogy kinek milyen joga van --> DDL táblákat hozunk létre -->(Insert, Delete, Update) műveletekkel feltöltjük tartalommal--> lekérdezzük az adatokat (ha ilyen sorrend van akkor relációs adatbázist használunk, más sorrendben ez nem lesz igaz)
4. Ha SQL nyelvet használunk.
5. szigorú adatkonzisztencia (nem veszhetnek el adatok stb.)

Big Data

Mi történik akkor ha tényleg nagy adatokkal szeretnénk foglalkozni?

Például:

Az internethálózaton hatalmas adatmennyiségből a másodperc tört része alatt kell eredményeket produkálniuk az osztott adatbázisoknak

Előfordulásai

Nagyvállalati összekapcsolt rendszerekben

Internethálózaton

Jellemzői

Az IBM definiálta, hogy mi jellemzi a "Big Data"-t

• (Volume) „végtelen” nagy –-> azaz nagy méretű
• (Variety) változatos –-> struktúrában gazdag adathalmaz
• (Velocity) valósidejű –-> tehát azonnal kell
• (Veracity) valós –-> azaz a megkapott információ (elég) konzisztens
• (Verifiability) validálható –-> az eredmény ellenőrizhető

Elosztott adatbázisok

Az osztott adatbázis egy olyan logikai adatbázis, amelyik fizikailag különböző helyeken lévő, egymással adatátviteli hálózattal összekapcsolt helyi adatbázisokból épül fel. Mindegyik adatbázis adatai bármelyik adatbázisból elérhetőek, dolgozni lehet velük. A felhasználónak nem kell tudnia, hogy az egyes adatok melyik helyi adatbázisban vannak elhelyezve.

Forrás: Baksa-Haskó Gabriella, Quittner Pál: Adatbázisok, adatbáziskezelő rendszerek, Budapest, Debreceni Egyetem Agrártudományi Centrum Agrárgazdasági és Vidékfejlesztési Kar, 2007. január

1. A hibakeresés nehezebb lesz
2. Sebezhetőbb a rendszer (több helyre lehet betörni, nagyobb eséllyel találnak sérülékenységet, betörési pontot)
3. Mindig valamennyi gépnek működnie kell.
4. gyengébb a szoftver- támogatás

1. Elosztott adatok átlátszó kezelése
2. Elosztott tranzakciók
3. Nagyobb teljesítmény
4. Könnyű bővíthetőség (skálázhatóság)
5. Csökkennek a kommunikációs költségek
6. Rugalmasság (pl.: felhő alapú rendszerek --> annyit fizetek amennyire szükségem van, ha több kell akkor többet fogok fizetni)

Relációs adatbázisok

Mint azt már tanultuk, a relációs adatbázisokban az adatokat és a köztük lévő kapcsolatokat relációkban, szemléletesen tekintve táblázatokban, táblákban ábrázoljuk. Ezekből a feladatok megoldásához szükséges adatokat a relációs műveletek segítségével kapjuk meg.

Ilyen relációs adatbáziskezelő rendszer az Oracle is.

Napjaink adatbáziskezelő rendszerei szinte mindegyik relációs modellen alapszik. Szedjük össze e modell előnyeit illetve hátrányait.

Forrás: Baksa-Haskó Gabriella, Quittner Pál: Adatbázisok, adatbáziskezelő rendszerek, Budapest, Debreceni Egyetem Agrártudományi Centrum Agrárgazdasági és Vidékfejlesztési Kar, 2007. január

Hátrányai

1. Nehéz a változáskövetés
2. Az adatok mennyisége elképesztően növekszik --> a hardware-ek nem bírják ellensúlyozni a növekedést --> lassul a rendszer
3. A strukturált üzleti adatokat is relációsan tároljuk

Nézzünk néhány lehetséges megoldást a problémák kiküszöbölésére:

Scale out

A "Scale out" egy horizontális háttér-növekedést jelent, amikor több gépet alkalmazunk olcsóbb hardware-ek valamiféle trükközésével.

Ez tűnik alkalmasabbnak, mivel a hardware-ek alulmaradnak az adatmennyiséghez képest.

Scale up

Lehetséges megoldás a skálázhatóság.

A "Scale up" azt jelenti, hogy a növekvő adatmennyiséghez erősebb gépeket építsünk fel: több processzort, több memóriát, erősebb hardware-ket, de a gépek számát nem növeljük.

Ezzel sajnos több probléma akad.

1. Általában a 2x erősebb gépek nem 2x drágábbak hanem akár 5-10x is.
2. Ha nekem 10x több adatom van nem biztos, hogy elég nekem a 10x több processzor, 20-30x több kell.

Előnyei

1. Az adatok ábrázolása táblákban történik, ezáltal felhasználóbarát
2. Nincs szükség különleges matematikai ismeretekre
3. Szabványnyelve van, ez pedig az SQL
4. Használata könnyen megtanulható
5. Elméleti alapjai legrészletesebben, legpontosabban vannak kidolgozva, rengeteg a tapasztalat
6. Felhasználói bázisa hatalmas
7. Megbízható
8. Fizikai és a logikai adatfüggetlenség tökéletesen megvalósítható
9. ACID típusú tranzakciók

ACID

 ACID: Atomicity (atomicitás), Consistency (konzisztencia), Isolation (izoláció), és Durability (tartósság) rövidítése. Ezek az adatbázis-kezelő rendszer tranzakció feldolgozó képességeinek alapelemei. Ezek nélkül az adatbázis integritása nem garantálható.

Forrás: https://hu.wikipedia.org/wiki/ACID

Durability

A végrehajtott tranzakciók változtatásait egy tartós adattárolón kell tárolni, hogy a szoftver vagy a hardver meghibásodása, áramszünet, vagy egyéb hiba esetén is megmaradjon.

Isolation

A tranzakciók izolációja azt biztosítja, hogy az egy időben zajló tranzakciók olyan állapothoz vezetnek, mint amilyet sorban végrehajtott tranzakciók érnének el. Egy végrehajtás alatt álló tranzakció hatásai nem láthatóak a többi tranzakcióból.

Consistency

A konzisztencia biztosítja, hogy az adatok a tranzakció előtti érvényes állapotból ismét egy érvényes állapotba kerüljenek. Minden erre vonatkozó szabálynak érvényesülnie kell.

Atomicity

Az atomicitás megköveteli, hogy több műveletet oszthatatlan műveletként lehessen végrehajtani, azaz vagy az összes művelet sikeresen végrehajtódik, vagy egyik sem.