NoSQL oktatóanyag: Mi az, NoSQL-adatbázisok típusai és példa

Mi az a NoSQL?

NoSQL Az adatbázis egy nem relációs adatkezelő rendszer, amely nem igényel fix sémát. Kerüli az összeillesztéseket, és könnyen méretezhető. A NoSQL-adatbázis használatának fő célja a hatalmas adattárolási igényű elosztott adattárak kezelése. A NoSQL-t nagy adatokhoz és valós idejű webalkalmazásokhoz használják. Például az olyan cégek, mint a Twitter, a Facebook és a Google, minden nap terabájtnyi felhasználói adatot gyűjtenek.

NoSQL adatbázis a „Nem csak SQL” vagy a „Nem SQL” rövidítése. Bár jobb kifejezés lenne a „NoREL”, a NoSQL megfogott. Carl Strozz 1998-ban vezette be a NoSQL koncepciót.

A hagyományos RDBMS SQL szintaxist használ az adatok tárolására és lekérésére a további betekintés érdekében. Ehelyett a NoSQL adatbázisrendszer az adatbázis-technológiák széles skáláját öleli fel, amelyek képesek strukturált, félig strukturált, strukturálatlan és polimorf adatokat tárolni. Ismerjük meg a NoSQL-t egy diagrammal ebben a NoSQL-adatbázis oktatóanyagban:

Miért a NoSQL?

A NoSQL adatbázisok koncepciója népszerűvé vált olyan internetes óriások körében, mint a Google, a Facebook, Amazonstb., akik hatalmas mennyiségű adattal foglalkoznak. A rendszer válaszideje lelassul, ha RDBMS-t használ nagy mennyiségű adathoz.

A probléma megoldása érdekében meglévő hardverünk frissítésével „bővíthetjük” rendszereinket. Ez a folyamat drága.

A probléma alternatívája az adatbázis-terhelés elosztása több gazdagépen, amikor a terhelés növekszik. Ezt a módszert „kiskálázásnak” nevezik.

A NoSQL adatbázis nem relációs, ezért jobban méretezhető, mint a relációs adatbázisok, mivel webalkalmazásokat szem előtt tartva tervezték őket.

A NoSQL adatbázisok rövid története

• 1998 – Carlo Strozzi a NoSQL kifejezést használja könnyű, nyílt forráskódú relációs adatbázisára
• 2000- Grafikus adatbázis Neo4j elindul
• 2004 – Elindul a Google BigTable
• 2005- CouchDB elindul
• 2007- A kutatási cikk a Amazon Kiszabadul a Dinamo
• 2008- Facebook nyílt forráskódú a Cassandra program
• 2009 – Újra bevezetésre került a NoSQL kifejezés

A NoSQL jellemzői

Nem relációs

• A NoSQL adatbázisok soha nem követik a relációs modell
• Soha ne biztosítson táblákat lapos fix oszlopos rekordokkal
• Dolgozzon önálló aggregátumokkal vagy BLOB-okkal
• Nem igényel objektum-relációs leképezést és adatnormalizálást
• Nincsenek olyan összetett szolgáltatások, mint a lekérdezési nyelvek, lekérdezéstervezők, hivatkozási integritási csatlakozások, ACID

Sémamentes

• A NoSQL-adatbázisok vagy sémamentesek, vagy laza sémákkal rendelkeznek
• Ne írja elő az adatok sémájának semmiféle meghatározását
• Heterogén adatstruktúrákat kínál ugyanabban a tartományban

Egyszerű API

• Könnyen használható felületeket kínál a megadott adatok tárolására és lekérdezésére
• Az API-k alacsony szintű adatkezelést és -kiválasztási módszereket tesznek lehetővé
• Szövegalapú protokollok, amelyeket többnyire a HTTP REST-tel és JSON-nal használnak
• Többnyire nem használt szabványos NoSQL lekérdezési nyelvet
• Web-kompatibilis adatbázisok, amelyek internetes szolgáltatásként futnak

Megosztott

• Több NoSQL adatbázis is végrehajtható elosztott módon
• Automatikus méretezési és feladatátvételi képességeket kínál
• Az ACID koncepciót gyakran fel lehet áldozni a méretezhetőség és az áteresztőképesség érdekében
• Többnyire nincs szinkron replikáció az elosztott csomópontok között Aszinkron több mesterreplikáció, peer-to-peer, HDFS replikáció
• Csak a végső következetesség biztosítása
• Megosztott semmi Architectúra. Ez kevesebb koordinációt és nagyobb elosztást tesz lehetővé.

A NoSQL adatbázisok típusai

NoSQL adatbázisok főként négy típusba sorolhatók: kulcs-értékpár, oszlop-orientált, grafikon alapú és dokumentum-orientált. Minden kategóriának megvannak a maga sajátosságai és korlátai. A fent megadott adatbázisok egyike sem alkalmas az összes probléma megoldására. A felhasználóknak termékigényeik alapján kell kiválasztaniuk az adatbázist.

A NoSQL adatbázisok típusai:

• Kulcs-érték pár alapú
• Oszloporientált grafikon
• Grafikon alapú
• Dokumentum orientált

Kulcsérték pár alapú

Az adatok kulcs/érték párokban tárolódnak. Úgy tervezték, hogy sok adatot és nagy terhelést kezeljen.

A kulcs-érték pár tárolási adatbázisok hash-táblaként tárolják az adatokat, ahol minden kulcs egyedi, és az érték lehet JSON, BLOB (bináris nagy objektumok), karakterlánc stb.

Például egy kulcs-érték pár tartalmazhat olyan kulcsot, mint a „Webhely”, amely olyan értékhez van társítva, mint a „Guru99”.

Ez az egyik legalapvetőbb NoSQL-adatbázis példa. Ez a fajta NoSQL adatbázis gyűjteményként, szótárként, asszociatív tömbként stb. használatos. A kulcsértéktárolók segítenek a fejlesztőnek abban, hogy sémamentes adatokat tároljon. A bevásárlókosár tartalmához működnek a legjobban.

A Redis, a Dynamo, a Riak néhány NoSQL-példa a kulcsérték-tároló adatbázisokra. Ezek mind azon alapulnak Amazon's Dynamo papír.

Oszlop alapú

Az oszloporientált adatbázisok oszlopokon működnek, és a Google BigTable papírján alapulnak. Minden oszlopot külön kezelünk. Az egyoszlopos adatbázisok értékei egymás mellett vannak tárolva.

Nagy teljesítményt nyújtanak az olyan összesítő lekérdezéseknél, mint a SUM, COUNT, AVG, MIN stb., mivel az adatok egy oszlopban könnyen elérhetők.

Az oszlop alapú NoSQL adatbázisokat széles körben használják adattárházak kezelésére, üzleti intelligencia, CRM, könyvtári kártya katalógusok,

HBase, Cassandra, HBase, Hypertable az oszlopalapú adatbázis NoSQL lekérdezési példái.

Dokumentum-orientált

A dokumentum-orientált NoSQL DB kulcsértékpárként tárolja és kéri le az adatokat, de az érték részt dokumentumként tárolja. A dokumentum JSON vagy XML formátumban van tárolva. Az értéket a DB megérti, és lekérdezhető.

A bal oldali diagramon láthatja, hogy soraink és oszlopaink vannak, a jobb oldalon pedig egy dokumentumadatbázisunk van, amely a JSON-hoz hasonló szerkezettel rendelkezik. Most a relációs adatbázishoz tudnod kell, hogy milyen oszlopok vannak és így tovább. Egy dokumentumadatbázishoz azonban rendelkezik adattárral, például JSON objektummal. Nem kell meghatároznia, hogy melyik teszi rugalmassá.

A dokumentumtípust többnyire CMS-rendszerekhez, blogolási platformokhoz, valós idejű analitikai és e-kereskedelmi alkalmazásokhoz használják. Nem használható összetett tranzakciókhoz, amelyek több műveletet vagy lekérdezést igényelnek a különböző összesített struktúrák ellen.

Amazon SimpleDB, CouchDB, MongoDB, Riak, Lotus Notes, MongoDB, népszerűek Dokumentum eredetű DBMS rendszerek.

Grafikon alapú

A gráf típusú adatbázis entitásokat, valamint az entitások közötti kapcsolatokat tárolja. Az entitás csomópontként kerül tárolásra, a kapcsolat élekként. Az él a csomópontok közötti kapcsolatot adja meg. Minden csomópontnak és élnek egyedi azonosítója van.

Egy relációs adatbázishoz képest, ahol a táblák lazán kapcsolódnak egymáshoz, a Graph adatbázis több relációs jellegű. A bejárási kapcsolatok gyorsak, mivel már bekerültek a DB-be, és nem kell kiszámítani őket.

Leginkább közösségi hálózatokhoz, logisztikához, térbeli adatokhoz használt gráfbázis adatbázis.

Neo4J, végtelen gráf, OrientDB, A FlockDB néhány népszerű gráf alapú adatbázis.

Lekérdezési mechanizmus eszközök a NoSQL-hez

A leggyakoribb adatlekérési mechanizmus egy érték REST-alapú lekérése a kulcsa/azonosítója alapján a GET erőforrással.

A dokumentumtár adatbázisa bonyolultabb lekérdezéseket kínál, mivel megértik a kulcs-érték párban lévő értéket. Például, CouchDB lehetővé teszi nézetek meghatározását a MapReduce segítségével

Mi a CAP-tétel?

A CAP-tételt Brewer-tételnek is nevezik. Kimondja, hogy lehetetlen, hogy egy elosztott adattár háromból kettőnél többet biztosítson

1. Következetesség
2. Elérhetőség
3. Partíciótűrés

Következetesség:

Az adatoknak konzisztensnek kell maradniuk a művelet végrehajtása után is. Ez azt jelenti, hogy az adatok írását követően minden jövőbeli olvasási kérésnek tartalmaznia kell ezeket az adatokat. Például a rendelés állapotának frissítése után minden ügyfélnek ugyanazokat az adatokat kell látnia.

Elérhetőség:

Az adatbázisnak mindig elérhetőnek és érzékenynek kell lennie. Nem szabad, hogy legyen leállás.

Partíciótűrés:

A partíciótűrés azt jelenti, hogy a rendszernek akkor is működnie kell, ha a szerverek közötti kommunikáció nem stabil. Például a szerverek több csoportra particionálhatók, amelyek esetleg nem kommunikálnak egymással. Itt, ha az adatbázis egy része nem elérhető, a többi része mindig nem érinti.

Végső következetesség

Az „esetleges konzisztencia” kifejezés azt jelenti, hogy több gépen kell másolatokat készíteni az adatokról a magas rendelkezésre állás és skálázhatóság érdekében. Így az egyik gép bármely adatelemén végrehajtott módosításokat át kell terjeszteni más replikákra.

Előfordulhat, hogy az adatok replikációja nem azonnali, mivel egyes másolatok azonnal frissülnek, míg mások megfelelő időben. Ezek a másolatok lehetnek kölcsönösen, de idővel konzisztenssé válnak. Innen ered az esetleges következetesség elnevezés.

BASE: Balapvetően Aelérhető, Sgyakori állapot, Eventuális következetesség

• Alapvetően az elérhető azt jelenti, hogy a DB folyamatosan elérhető a CAP-tétel szerint
• A lágy állapot azt jelenti, hogy bemenet nélkül is; a rendszer állapota változhat
• A végső konzisztencia azt jelenti, hogy a rendszer idővel konzisztenssé válik

A NoSQL előnyei

• Elsődleges vagy analitikai adatforrásként használható
• Big Data képesség
• Nincs egyetlen kudarcpont
• Könnyű replikáció
• Nincs szükség külön gyorsítótárazási rétegre
• Gyors teljesítményt és vízszintes méretezhetőséget biztosít.
• Egyforma hatással képes kezelni a strukturált, félig strukturált és strukturálatlan adatokat
• Objektum-orientált programozás, amely könnyen használható és rugalmas
• A NoSQL adatbázisokhoz nincs szükség dedikált, nagy teljesítményű szerverre
• Támogassa a kulcsfontosságú fejlesztői nyelveket és platformokat
• Egyszerűbb megvalósítani, mint az RDBMS használata
• Az online alkalmazások elsődleges adatforrásaként szolgálhat.
• Kezeli a nagy adatokat, amelyek az adatok sebességét, változatosságát, mennyiségét és összetettségét kezelik
• Kiválóan működik elosztott adatbázisokkal és több adatközponttal végzett műveleteknél
• Megszünteti az adatok tárolására szolgáló meghatározott gyorsítótárazási réteg szükségességét
• Rugalmas sémakialakítást kínál, amely könnyen módosítható állásidő vagy szolgáltatási zavar nélkül

A NoSQL hátrányai

• Nincsenek szabványosítási szabályok
• Korlátozott lekérdezési lehetőségek
• RDBMS az adatbázisok és eszközök viszonylag kiforrottak
• Nem kínál semmilyen hagyományos adatbázis-képességet, például konzisztenciát, amikor több tranzakciót hajtanak végre egyszerre.
• Amikor az adatok mennyisége növekszik, nehéz az egyedi értékeket fenntartani, mivel a kulcsok nehezebbé válnak
• Relációs adatokkal nem működik olyan jól
• A tanulási görbe merev az új fejlesztők számára
• Nyílt forráskódú lehetőségek, így nem annyira népszerűek a vállalkozások számára.

Összegzésként

• A NoSQL egy nem relációs DMS, amely nem igényel fix sémát, elkerüli az összekapcsolásokat és könnyen méretezhető
• A NoSQL adatbázisok koncepciója népszerűvé vált olyan internetes óriások körében, mint a Google, a Facebook, Amazonstb., akik hatalmas mennyiségű adattal foglalkoznak
• 1998-ban Carlo Strozzi a NoSQL kifejezést használta könnyű, nyílt forráskódú relációs adatbázisára.
• A NoSQL adatbázisok soha nem követik a relációs modellt, vagy sémamentesek, vagy laza sémákkal rendelkeznek
• A NoSQL-adatbázis négy típusa 1). Kulcs-érték pár alapú 2). Oszloporientált 3. grafikon). Grafikon alapú 4). Dokumentum orientált
• A NOSQL azonos hatással képes kezelni a strukturált, félig strukturált és strukturálatlan adatokat
• A CAP tétel három szóból áll: Konzisztencia, Elérhetőség és Partíciótűrés
• A BASE jelentése Balapvetően Aelérhető, Sgyakori állapot, Eventuális következetesség
• Az „esetleges konzisztencia” kifejezés azt jelenti, hogy több gépen kell másolatokat készíteni az adatokról a magas rendelkezésre állás és méretezhetőség érdekében
• nosql korlátozott lekérdezési lehetőségeket kínálnak