Sok zavart látok a sok új adatbázis-megoldás (“NoSQL-adatbázisok”) helyét és célját illetően a már évek óta létező relációs adatbázis-megoldásokkal szemben. Ezért megpróbálom elmagyarázni a különbségeket és az egyes megoldások legjobb felhasználási eseteit.
Először is tisztázzuk ezeket az adatbázis-megoldásokat két csoportra:
1) Relációs adatbázisok, amelyeket relációs adatbázis-kezelő rendszereknek (RDBMS) vagy SQL-adatbázisoknak is nevezhetünk. Ezek közül a legnépszerűbbek a Microsoft SQL Server, az Oracle Database, a MySQL és az IBM DB2. Ezeket az RDBMS-eket leginkább nagyvállalati forgatókönyvekben használják, kivéve a MySQL-t, amelyet leginkább webes alkalmazások adatainak tárolására használnak, jellemzően a népszerű LAMP stack (Linux, Apache, MySQL, PHP/ Python/ Perl) részeként.
2) Nem relációs adatbázisok, más néven NoSQL adatbázisok, amelyek közül a legnépszerűbbek a MongoDB, DocumentDB, Cassandra, Coachbase, HBase, Redis és Neo4j. Ezeket az adatbázisokat általában négy kategóriába sorolják:
Minden relációs adatbázis használható tranzakció-orientált alkalmazások (OLTP) kezelésére, és a legtöbb nem relációs adatbázis, amely a dokumentumtárak és oszloptárak kategóriájába tartozik, szintén használható OLTP-re, ami tovább növeli a zavart. Az OLTP-adatbázisokat “operatív” adatbázisoknak tekinthetjük, amelyekre a gyakori, rövid, frissítéseket is tartalmazó, kis adatmennyiséget érintő tranzakciók jellemzőek, és ahol a több ezer tranzakció párhuzamossága nagyon fontos (példaként említhetők a banki alkalmazások és az online foglalások). Az adatok integritása nagyon fontos, ezért támogatják az ACID tranzakciókat (Atomicity, Consistency, Isolation, Durability). Ez ellentétben áll az adattárházakkal, amelyek “analitikus” adatbázisoknak minősülnek, és amelyekre jellemzőek a hosszú, összetett lekérdezések, amelyek nagy mennyiségű adatot érintenek és sok erőforrást igényelnek. A frissítések ritkák. Példa erre az elmúlt év eladásainak elemzése.
A relációs adatbázisok általában strukturált adatokkal dolgoznak, míg a nem relációs adatbázisok általában félig strukturált adatokkal (pl. XML, JSON).
Nézzük meg az egyes csoportokat részletesebben:
Relációs adatbázisok
A relációs adatbázis az E.F. Codd által 1970-ben javasolt relációs adatmodell alapján szerveződik. Ez a modell az adatokat egy vagy több, sorokból és oszlopokból álló táblákba (vagy “relációkba”) szervezi, minden sorhoz egyedi kulccsal. Általában az adatbázisban leírt minden egyes entitás-típusnak saját táblája van, amelynek sorai az adott entitás-típus példányait, oszlopai pedig az adott példányhoz rendelt értékeket képviselik. Mivel egy táblázat minden sora saját egyedi kulccsal rendelkezik, egy táblázat sorai összekapcsolhatók más táblák soraival annak a sornak az egyedi kulcsának a tárolásával, amelyhez az adott sort kapcsolni kell (ahol az ilyen egyedi kulcsot “idegen kulcsnak” nevezik). Codd megmutatta, hogy tetszőleges bonyolultságú adatkapcsolatok ábrázolhatók ezen egyszerű fogalomkészlet segítségével.
Majdnem minden relációs adatbázis-rendszer az SQL-t (Structured Query Language) használja az adatbázis lekérdezésének és karbantartásának nyelveként.
A relációs adatbázisok dominanciájának okai: egyszerűség, robusztusság, rugalmasság, teljesítmény, skálázhatóság és kompatibilitás az általános adatok kezelésében.
De ahhoz, hogy mindezt kínálják, a relációs adatbázisoknak belsőleg hihetetlenül bonyolultnak kell lenniük. Például egy viszonylag egyszerű SELECT utasításnak több tucat lehetséges lekérdezési végrehajtási útvonala lehet, amelyeket a lekérdezés optimalizálója futásidőben kiértékel. Mindez a felhasználók számára rejtve marad, de a motorháztető alatt az RDBMS meghatározza a legjobb “végrehajtási tervet” a kérések megválaszolásához, például költségalapú algoritmusok segítségével.
A nagy adatbázisok, különösen a webes alkalmazásokhoz használt adatbázisok esetében a fő gondot a skálázhatóság jelenti. Mivel egyre több alkalmazás jön létre olyan környezetben, ahol hatalmas munkaterhelés van (pl. Amazon), a skálázhatósági követelmények nagyon gyorsan változhatnak és nagyon nagyra nőhetnek. A relációs adatbázisok jól skálázódnak, de általában csak akkor, ha ez a skálázás egyetlen szerveren történik (“scale-up”). Amikor az egyetlen szerver kapacitása elérte a határt, akkor “skálázni” kell, és a terhelést több szerverre kell elosztani, az úgynevezett elosztott számítástechnika felé haladva. Ez az a pont, amikor a relációs adatbázisok összetettsége elkezd problémákat okozni a skálázhatóságukkal kapcsolatban. Ha több száz vagy több ezer szerverre próbáljuk skálázni, a komplexitás túlterhelővé válik. A relációs adatbázisok vonzerejét éppen azok a tulajdonságok teszik vonzóvá, amelyek drasztikusan csökkentik életképességüket nagy elosztott rendszerek platformjaként.
Nem relációs adatbázisok
A NoSQL adatbázis olyan mechanizmust biztosít az adatok tárolására és visszakeresésére, amelyet a relációs adatbázisokban használt táblázatos kapcsolatoktól eltérő módon modelleznek.
A megközelítés motivációi a következők:
- A tervezés egyszerűsége. Nem kell foglalkozni az alkalmazások írásának objektumorientált megközelítése és a relációs adatbázisok sémaalapú táblái és sorai közötti “impedancia-eltéréssel”. Például az összes ügyfélrendelési információ tárolása egyetlen dokumentumban, szemben a sok táblázat összekapcsolásával, ami kevesebb írandó, hibakeresést és karbantartandó kódot eredményez
- Jobb “horizontális” skálázás gépfürtökre, ami megoldja azt a problémát, amikor az egyidejű felhasználók száma az interneten és mobileszközökön keresztül elérhető alkalmazások esetében az egekbe szökik. A dokumentumok használata sokkal könnyebbé teszi a skálázást, mivel az adott ügyfélrendelésre vonatkozó összes információ egy helyen található, szemben a több táblázatban való szétszóródással. A NoSQL-adatbázisok automatikusan szétosztják az adatokat a szerverek között anélkül, hogy az alkalmazás módosítását igényelnék (auto-sharding), ami azt jelenti, hogy az adatokat natívan és automatikusan tetszőleges számú szerverre osztják szét, anélkül, hogy az alkalmazásnak tudnia kellene a szerverpark összetételéről. Az adatok és a lekérdezések terhelése automatikusan kiegyenlítődik a szerverek között, és ha egy szerver leáll, gyorsan és átláthatóan, az alkalmazás megszakítása nélkül lecserélhető
- Finomabb ellenőrzés a rendelkezésre állás felett. A szerverek hozzáadhatók vagy eltávolíthatók az alkalmazás leállása nélkül. A legtöbb NoSQL adatbázis támogatja az adatreplikációt, az adatok több példányának tárolását a fürtön vagy akár adatközpontokon keresztül, a magas rendelkezésre állás és a katasztrófa utáni helyreállítás biztosítása érdekében
- Mindenféle adat egyszerű rögzítése “Big Data”, amely magában foglalja a strukturálatlan és félig strukturált adatokat. Olyan rugalmas adatbázis lehetővé tétele, amely könnyen és gyorsan képes bármilyen új típusú adat befogadására, és amelyet nem zavarnak meg a tartalmi struktúra változásai. Ennek oka, hogy a dokumentumadatbázisok séma nélküliek, lehetővé téve, hogy a JSON-dokumentumokhoz szabadon adjunk hozzá mezőket anélkül, hogy először meg kellene határozni a változásokat (schema-on-read helyett schema-on-write). Lehetnek más-más számú mezővel rendelkező dokumentumai, mint más dokumentumoknak. Például egy betegrekord, amely tartalmazhat vagy nem tartalmazhat olyan mezőket, amelyek felsorolják az allergiákat
- Sebesség. A NoSQL adatbázisok által használt adatszerkezetek (pl. JSON dokumentumok) eltérnek a relációs adatbázisokban alapértelmezetten használtaktól, így számos művelet gyorsabb a NoSQL-ben, mint a relációs adatbázisokban, mivel nem kell táblákat összekapcsolni (az adatok duplikációja miatt megnövekedett tárhely árán – de a tárhely manapság annyira olcsó, hogy ez általában nem jelent problémát). Valójában a legtöbb NoSQL adatbázis nem is támogatja az egyesítéseket
- Költség. A NoSQL adatbázisok általában olcsó árukiszolgálókból álló fürtöket használnak, míg az RDBMS-ek általában drága, szabadalmaztatott szerverekre és tárolórendszerekre támaszkodnak. Emellett az RDBMS-rendszerek licenszei meglehetősen drágák lehetnek, míg sok NoSQL adatbázis nyílt forráskódú és ezért ingyenes
Az adott NoSQL adatbázis konkrét alkalmassága attól függ, hogy milyen problémát kell megoldania
A NoSQL adatbázisokat egyre gyakrabban használják a nagy adatmennyiségű és valós idejű webes alkalmazásokban. A web bevezetésével váltak népszerűvé, amikor az adatbázisok a legfeljebb néhány száz felhasználóból egy belső vállalati alkalmazáson belül több ezer vagy millió felhasználóra nőttek egy webes alkalmazáson belül. A NoSQL rendszereket “Nem csak SQL”-nek is nevezik, hogy hangsúlyozzák, hogy támogathatják az SQL-szerű lekérdezési nyelveket is.
Néhány NoSQL tároló kompromisszumot köt a konzisztenciával (a CAP-tétel értelmében) a rendelkezésre állás és a partíciótűrés javára. A NoSQL tárolók elfogadását gátló okok közé tartozik az alacsony szintű lekérdezési nyelvek használata, a szabványosított interfészek hiánya és a meglévő SQL-be történő hatalmas beruházások. Emellett a legtöbb NoSQL tároló nem rendelkezik valódi ACID tranzakciókkal, vagy csak bizonyos körülmények között és bizonyos szinteken (pl. dokumentumszint) támogatja a tranzakciókat. Végül, az RDBMS-ek általában sokkal egyszerűbben használhatók, mivel GUI-val rendelkeznek, míg sok NoSQL megoldás parancssori felületet használ.
A kettő összehasonlítása
A relációs adatbázisok egyik legsúlyosabb korlátja, hogy minden elem csak egy attribútumot tartalmazhat. Ha egy banki példát használunk, az ügyfél és a bank közötti kapcsolat minden egyes aspektusa külön sorelemként, külön táblákban tárolódik. Tehát az ügyfél törzsadatai az egyik táblában vannak, a számlaadatok egy másik táblában, a hiteladatok egy újabb táblában, a befektetések egy másik táblában, és így tovább. Mindezek a táblák relációk, például elsődleges kulcsok és idegen kulcsok segítségével kapcsolódnak egymáshoz.
A nem relációs adatbázisok, pontosabban egy adatbázis kulcs-érték tárolói vagy kulcs-érték párosai gyökeresen eltérnek ettől a modelltől. A kulcs-érték párok lehetővé teszik, hogy több összefüggő elemet tároljunk egy “adatsorban” ugyanabban a táblában. A “sor” szót azért tesszük idézőjelbe, mert a sor itt valójában nem ugyanaz, mint egy relációs táblázat sora. Például ugyanannak a banknak egy nem relációs táblájában minden sor tartalmazná az ügyfél adatait, valamint a számla-, hitel- és befektetési adatait. Az egy ügyfélre vonatkozó összes adatot kényelmesen együtt, egyetlen rekordként tárolnánk.
Ez nyilvánvalóan jobb adattárolási módszernek tűnik, de van egy jelentős hátránya: a relációs adatbázisokkal ellentétben a kulcs-érték tárolók nem tudnak kapcsolatokat érvényesíteni az adatelemek között. Például a mi kulcsérték-adatbázisunkban az ügyfél adatai (név, társadalombiztosítás, cím, számlaszám, hitelfolyósítási szám stb.) mind egyetlen adatrekordként lennének tárolva (ahelyett, hogy több táblában lennének tárolva, mint a relációs modellben). Az ügyfél tranzakciói (számlafelvételek, számlabefizetések, hiteltörlesztések, bankköltségek stb.) szintén egyetlen adatrekordként lennének tárolva.
A relációs modellben van egy beépített és bolondbiztos módszer az üzleti logika és szabályok biztosítására és érvényesítésére az adatbázisrétegben, például arra, hogy egy pénzfelvétel a megfelelő bankszámlát terhelje, elsődleges kulcsok és idegen kulcsok segítségével. A kulcs-érték tárolókban ez a felelősség teljes mértékben az alkalmazási logikára hárul, és sokan nagyon kényelmetlenül érzik magukat, ha ezt a döntő fontosságú felelősséget csak az alkalmazásra bízzák. Ez az egyik oka annak, hogy a relációs adatbázisokat továbbra is használni fogják.
Az adatbázisokat használó webes alkalmazások esetében azonban az üzleti logika szigorú érvényesítésének szempontja gyakran nem tartozik a legfontosabb prioritások közé. A legfőbb prioritás a nagyszámú felhasználói kérés kiszolgálásának képessége, amelyek jellemzően csak olvasási célú lekérdezések. Például egy olyan webhelyen, mint az eBay, a felhasználók többsége egyszerűen csak böngészik és átnézi a közzétett tételeket (csak olvasási műveletek). Ezeknek a felhasználóknak csak egy töredéke tesz ajánlatot vagy foglal le tételeket (írási-olvasási műveletek). És ne feledjük, hogy naponta több millió, néha több milliárd oldalmegtekintésről beszélünk. Az eBay webhely adminisztrátorai inkább a gyors válaszidőben érdekeltek, hogy biztosítsák az oldal gyorsabb betöltését a webhely felhasználói számára, mint az üzleti szabályok érvényesítésének hagyományos prioritásaiban vagy az olvasás és írás közötti egyensúly biztosításában.
A relációs modellű adatbázisok az adattárházak révén nagyméretű, csak olvasásra korlátozódó műveletek futtatására hangolhatók és állíthatók be, és így potenciálisan nagyszámú, nagy mennyiségű adatot lekérdező felhasználót szolgálhatnak ki, különösen, ha olyan relációs MPP-architektúrákat használnak, mint az Analytics Platform System, a Teradata, az Oracle Exadata vagy az IBM Netezza, amelyek mind támogatják a skálázást. Mint már említettük, az adattárházak abban különböznek a tipikus adatbázisoktól, hogy az adatok összetettebb elemzésére szolgálnak. Ez eltér a tranzakciós (OLTP) adatbázistól, amelynek fő felhasználási területe az operatív rendszerek támogatása és a napi szintű, kis léptékű jelentéskészítés.
Az igazi kihívást azonban a relációs modell skálázhatóságának hiánya jelenti, amikor OLTP-alkalmazásokról van szó, vagy bármilyen olyan megoldásról, amely sok egyedi írást tartalmaz, ami a relációs SMP-architektúrák területe. Ez az a terület, ahol a nem relációs modellek igazán ragyoghatnak. Könnyen eloszthatják az adatterhelést több tucat, több száz, szélsőséges esetben (gondoljunk csak a Google keresésre) akár több ezer szerver között. Mivel minden egyes szerver a felhasználóktól érkező összes kérésnek csak kis százalékát kezeli, a válaszidő nagyon jó az egyes felhasználók számára. Bár ez az elosztott számítástechnikai modell relációs adatbázisok esetében is felépíthető, megvalósítása igen nehézkes, különösen akkor, ha sok az írás (pl. OLTP), és olyan technikákat igényel, mint a sharding, ami általában jelentős kódolást igényel az alkalmazás üzleti logikáján kívül. Ennek oka, hogy a relációs modell minden szinten ragaszkodik az adatintegritáshoz, amelyet akkor is fenn kell tartani, ha az adatokhoz több különböző szerver is hozzáfér és módosítja azokat. Ez az oka annak, hogy a nem relációs modell a webes alkalmazások, például a felhőalapú számítástechnika és a közösségi hálózatok választott architektúrája.
Az RDBMS-ek tehát összefoglalva a nagy tranzakciós terhelés (több millió olvasás-írás) esetén a horizontális skálázás hiánya miatt szenvednek, míg a NoSQL adatbázisok a nagy tranzakciós terhelést oldják meg, de az adatintegritás és az összekapcsolás rovására.
Ne feledjük, hogy sok megoldás a relációs és nem relációs adatbázisok kombinációját használja (lásd Mi a poliglott perzisztencia?).
Azt is tartsuk szem előtt, hogy lehet, hogy nincs szükségünk a nem relációs adatbázisok teljesítményére, és ehelyett elég lesz a fájlok HDFS-ben való tárolása és az Apache Hive használata (az Apache Hive a Hadoop tetejére épített adattárház-infrastruktúra, amely az adatok összegzését, lekérdezését és elemzését biztosítja egy SQL-szerű nyelven, a HiveQL-en keresztül).
És hogy egy olyan megjegyzéssel zárjuk, amely tovább növeli a zavart, van egy másik kategória, a NewSQL: A NewSQL a modern RDBMS-ek egy olyan osztálya, amely a NoSQL rendszerek skálázható teljesítményét igyekszik biztosítani az OLTP írási-olvasási munkaterhelésekhez, miközben fenntartja a hagyományos relációs adatbázisrendszerek ACID garanciáit. Hátrányuk, hogy nem alkalmasak OLAP-stílusú lekérdezésekre, és nem megfelelőek néhány terabájt feletti adatbázisokhoz. Ilyen például a VoltDB, a NuoDB, a MemSQL, az SAP HANA, a Splice Machine, a Clustrix és az Altibase.
Az Understanding NoSQL on Microsoft Azure című kiadványban található egy kiváló grafikon, amely bemutatja, hogy az összes technológia hogyan illeszkedik az Azure felhőbe:
Az Understanding NoSQL on Microsoft Azure című kiadványból:
A NoSQL-megoldás használatának lényege, ha olyan OLTP-alkalmazásunk van, amely több ezer felhasználóval rendelkezik, és nagyon nagy adatbázissal rendelkezik, amely scale-out megoldást igényel és/vagy JSON-adatokat használ, különösen, ha ez a JSON-adat különböző struktúrákkal rendelkezik. A magas rendelkezésre állás előnyét is élvezheti, mivel a NoSQL megoldások az adatok több példányát tárolják. Csak ne feledje, hogy a teljesítményért feláldozhatja az adatok konzisztenciáját, valamint az adatok összekapcsolásának, az SQL használatának és a gyors tömeges frissítéseknek a lehetőségét.
Bővebb információ:
MySQL vs MongoDB
MySQL vs. MongoDB: Looking At Relational and Non-Relational Databases
10 dolog, amit a NoSQL adatbázisokról tudni kell
Bevezetés az adatbázisokba
Difference between SQL and NoSQL : Comparision
SQL vs NoSQL Database Differences Explained with few Example DB
NoSQL, NewSQL, or RDBMS: Hogyan válasszunk
NewSQL – RDBMS on Steroids
NoSQL vs NewSQL adatbázisok Válassza ki a megfelelő eszközt a megfelelő munkához
SQL vs NoSQL: alapértelmezetten relációs tárolót szeretne
Oracle megvédi a relációs DB-ket a NoSQL versenytársakkal szemben
A NoSQL megértése a Microsoft Azure-on
Meet the Avant-Garde of New Relational Databases
To SQL or NoSQL? Ez az adatbázis-kérdés
CAP Theorem: Revisited
Mi az igazán új a NewSQL-ben?
MongoDB vs MySQL: Egy összehasonlító tanulmány az adatbázisokról
SQL és NoSQL adatbázisok jellemzői és különbségei