av Gábor Bányai för 7 årar sedan
398
NoSQL
Az elosztott rendszerek tervezésénél a NoSQL adatbázisok egyre fontosabb szerepet kapnak, különösen a CAP-tétel által meghatározott alapelvek miatt. A CAP-tétel három fő tulajdonságot foglal magában:
av Gábor Bányai för 7 årar sedan
398
Mer av detta
Kiegészítő/ajánlott olvasmány:
https://db.bme.hu/~gajdos/2012adatb2/3.%20eloadas%20NoSQL%20adatb%E1zisok%20doc.pdf
Fontos: a NoSQL nem egy konkrét termék, inkább egy mozgalom, ami alternatívát kíván nyújtani az adatbáziskezelők piacán
közös jellemzőik (nem szigorú definíció):
•nem-relációs adatmodell,
•elosztott működés,
•nyílt forráskód,
•horizontális skálázhatóság.
további gyakori tulajdonságok:
•sémamentesség vagy gyenge séma kényszerek,
•replikáció támogatása,
•egyszerű alkalmazásprogramozási interfész (application programming interface, API),
•fokozatos konzisztencia (eventual consistency).
Forrás: előadás,
https://db.bme.hu/~gajdos/2012adatb2/3.%20eloadas%20NoSQL%20adatb%E1zisok%20doc.pdf
Napjainkban a szemistrukturált adatok egyre nagyobb jelentőséggel bírnak, így például tartalomkezelő, kereső-, ajánlórendszerekben. A szemistrukturált adatok különleges tulajdonságai tették szükségessé az ún. dokumentumtároló (document store) adatbáziskezelők megalkotását. pl. CouchDB, MongoDB (különösen "forró" mostanában)
Forrás:előadás,
https://db.bme.hu/~gajdos/2012adatb2/3.%20eloadas%20NoSQL%20adatb%E1zisok%20doc.pdf
Komplex, sok összefüggést tartalmazó adathalmazokat gyakran célszerű gráffal reprezentálni. Sajnos a gráfok relációs adatbázis-kezelőkben való tárolása esetén a gráfokon végzett műveletek rendkívül költségesek lehetnek: egy gráf bejárásához például több természetes illesztésre lehet szükség, ami köztudottan költséges művelet.
pl. InfiniteGRaph, InfoGrid
Forrás: előadás,
https://db.bme.hu/~gajdos/2012adatb2/3.%20eloadas%20NoSQL%20adatb%E1zisok%20doc.pdf
pl. HBase, Cassandra, PNUT
Forrás: előadás
A kulcs-érték tárolók (key-value stores) olyan egyszerű adatbázis-kezelők, melyek kulcsokat és a hozzájuk rendelt értékeket tárolják. Ennek megfelelően a kulcs-érték tárolók attribútum–attribútumérték párokat tartalmaznak. Az egyszerű adatmodell számos alkalmazási területen hasznos, azonban a lekérdezések korlátozottak; jellemzően csak kulcs szerint valósulhatnak meg. Bár az első kulcs-érték tárolót már a ’70-es években megalkották, ezek a rendszerek is csak a többi NoSQL rendszer megjelenésének idején indultak fejlődésnek, lévén a megváltozott igényeket már nem lehetett hatékonyan kulcsérték tárolóként használt relációs adatbázis-kezelőkkel kielégíteni. A kulcs-érték tárolás ötletét az oszlopcsaládok és a gráfadatbázisok (ld. alább) is alkalmazzák.
Példák kulcs-érték tárolókra: Berkeley DB, Memcached, Project Voldemort, Redis, Riak.
Forrás:előadás,
https://db.bme.hu/~gajdos/2012adatb2/3.%20eloadas%20NoSQL%20adatb%E1zisok%20doc.pdf
Ez összefügg a felhasználói bázis szűkösségével és a NoSQL újdosnágával; egyszerűen kevés az olyan szakember, aki mélységében ismeri az ilyen rendszerek működését. Az is nehezíti a helyzetet, hogy a NoSQL termékek gyorsan váltják egymást a piacon: ami ma divatos adatbázikezelő rendszernek számít, pár év múlva már lehet már egyáltalán nem lesz használatban.
Forrás: előadás diasor,
http://www.hadoop360.com/blog/advantages-and-disadvantages-of-nosql-databases-what-you-should-k
Minden cégnek szükséges a biztosíték, hogy ha valami probléma merül fel az adatbázis működésével, akkor időben orvosolják a problémát. A relációs adatbáziskezelő gyártók teljeskörű és megbízható szolgáltatást nyújtanak ilyen tekintetben (akár 24 órás távoli adatbázisfelügyelet).
A NoSQL adatbázisokat viszont sokszor kis startupok fejlesztik, akik már csak a méretükből és erőforrásaikból szűkösségéből adódóan sem tudnak biztosítani globális supportot.
Forrás: http://www.hadoop360.com/blog/advantages-and-disadvantages-of-nosql-databases-what-you-should-k
Hiába hódít egyre nagyobb teret a nem SQL-alapú adatbázisok használata, a mai adatbázisok nagy része még mindig relációs. A relációs adatbázisokhoz az évtizedek során rengeteg tudás és tapasztalat gyűlt fel, amihez akár mi is könnyen hozzáférhetünk (gondoljunk pl a stackoverflow.com-ra) - szinte lehetetlen elképzelni olyan problémát, amibe mi futnánk bele először.
A NoSQL adatbázisok viszont még viszonylag fiatalok, vannak amik még alig kerültek ki a pre-production fázisból és több gyermekbetegséggel rendelkeznek, és nem is telt el elég idő, hogy elegendő tapasztalat alakuljon ki róluk.
Forrás: előadás diasor,
http://www.hadoop360.com/blog/advantages-and-disadvantages-of-nosql-databases-what-you-should-k
A relációs adatbázisok nagy előnye, hogy közös nyelvük az SQL (Structured Query Language). Két különböző relációs adatbáziskezelőt (pl. Oracle és DB2) többé-kevésbé ugyanúgy használhatunk az SQL-t ismerve, csak kisebb különbségek lehetnek (pl. adattípus elnevezések, függvények, stb), az "alapokban" nincs eltérés.
Előny lehet a cégeknek, akik relációs adatbázisokat használnak, hogy kevesebbet kell foglalkozniuk a betanítással.
Forrás: előadás diasor
Lényegében több adatot lehet tárolni és feldolgozni kevesebb pénzért NoSQL adatbázissal, mint RDBMS-sel.
forrás: http://www.hadoop360.com/blog/advantages-and-disadvantages-of-nosql-databases-what-you-should-k
https://www.devbridge.com/articles/benefits-of-nosql/#
Már említett növekvő adatmennyiség-->már nem lehetséges (vagy nem praktikus) egyetlen szervergéppel kiszolgálni az igényeket.Az elosztott működés fontos szempont.
Informálisan egy rendszert akkor nevezünk skálázhatónak (scalable), ha az erőforrásait növelve, a rendszer teljesítménye a hozzáadott erőforrásokkal arányosan javul.
Forrás: https://db.bme.hu/~gajdos/2012adatb2/3.%20eloadas%20NoSQL%20adatb%E1zisok%20doc.pdf
(horizontal scalability, scale out):
• a rendszert bővítjük új számítógéppel. Előnye, hogy sok, olcsó gépből nagy teljesítmény érhető el. Hátránya, hogy elosztottsága miatt többféle meghibásodás is felléphet, valamint bonyolult szoftvert igényel. Ezt támogatja a MySQL Scale-Out, az Oracle Real Application Cluster (RAC) és a legtöbb NoSQL rendszer is.
Forrás: https://db.bme.hu/~gajdos/2012adatb2/3.%20eloadas%20NoSQL%20adatb%E1zisok%20doc.pdf
(vertical scalability, scale up): A rendszer kiválasztott elemét bővítjük új erőforrással, leggyakrabban erősebb/több processzorral vagy több memóriával. A módszer előnye, hogy egyszerű megvalósítani, és a megfelelő, a rendszer szűk keresztmetszeteit okozó erőforrások bővítése esetén biztosan teljesítménynövekedéssel jár. Ezt az elvet egy- és többszerveres elosztott rendszerekben is lehet alkalmazni.
forrás: https://db.bme.hu/~gajdos/2012adatb2/3.%20eloadas%20NoSQL%20adatb%E1zisok%20doc.pdf
két http művelet:
Put (write)
Get(read)
Forrás: előadás
A változás előbb-utóbb mindenhova érjen el.
Egy banki tranzakciónak nyilván azonnal végbe kell mennie, de pl a facebookon a like célba érése nem sürgős.
Forrás: előadás
Akár az ACID (Atomicity, Consistency, Isolation, Durability) felrúgásának árán.
Forrás: előadás
Különböző szervereken tárolni a különböző objektumokat.
Forrás: előadás
Not Only SQL
NoSchema
+
NoTransactions
+
NoLanguage
+
NoStandards
Forrás: előadás
A NoSQL rendszerek tervezését befolyásoló egyik legfontosabb eredmény az ún. CAPtétel, amely az elosztott rendszerek által nyújtott garanciákra ad formális korlátot.
Eric Brewer, a Berkeley Egyetem professzora 1999-es publikációjában definiálta (informálisan) a CAP tulajdonságokat és a CAP alapelvet.
Három tulajdonság: Consistency, Availability, Partition tolerence
konzisztencia, rendelkezésre állás, partíció tolerancia
A CAP-tétel röviden úgy fogalmazható meg, hogy elosztott rendszerben a hálózat partíciója esetén a rendszer műveletei nem lesznek atomiak és/vagy az adategységei elérhetetlenek lesznek.
Forrás: https://db.bme.hu/~gajdos/2012adatb2/3.%20eloadas%20NoSQL%20adatb%E1zisok%20doc.pdf
A CAP-tétel jelentős eredmény az elosztott rendszerek elmélete terén, ugyanakkor több szempontot figyelmen kívül hagy.
Ilyenek például olyan kritikus rendszertervezési kérdések, mint a rendszer teljesítménye (áteresztőképessége) és késletetése, valamint az egyszeres hibapontok (SPOF, Single Point of Failure) jelenléte. A tétel szintén nem érvényes alkalmazáshibák, az adatbáziskezelő összeomlását okozó tranzakciók esetén (amelyek a hálózat más csomópontján futtatva is összeomlást fognak okozni).
forrás: https://db.bme.hu/~gajdos/2012adatb2/3.%20eloadas%20NoSQL%20adatb%E1zisok%20doc.pdf
A hálózat partíciója annak alapján modellezhető, hogy a hálózat egyik csomópontjából a másikba küldött üzenetekből tetszőleges számú elveszhet. Egy nem összefüggő hálózatban a hálózat egyik komponenséből a másikba küldött minden üzenet elveszik. Minden üzenetvesztési szekvencia modellezhető a hálózat ideiglenes partíciójával, majd újraegyesülésével. A partíció oka lehet a hálózat hibája, valamint a csomópontok hardveres vagy szoftveres hibái. A partíció tolerancia a másik két tulajdonság tükrében értelmezhető:
• A konzisztencia követelményhez azt kell teljesíteni, hogy a rendszer műveletei akkor is atomiak legyenek, ha az azokat megvalósító algoritmusok üzeneteiből tetszőleges számú elveszhet.
• A rendelkezésre álláshoz azt kell biztosítani, hogy a csomópontok minden, a kliensektől érkező kérésre érvényes választ adjanak, annak ellenére, hogy tetszőlegesen sok üzenet elveszhet.
forrás: https://db.bme.hu/~gajdos/2012adatb2/3.%20eloadas%20NoSQL%20adatb%E1zisok%20doc.pdf
Egy elosztott rendszer rendelkezésre áll, ha minden működő csomóponthoz érkező kérésre válaszol, tehát a csomópontokon futtatott algoritmusoknak véges idő alatt be kell fejeződniük. A formális definíció nem korlátozza a futási időt, de később látni fogjuk, hogy a gyakorlati alkalmazások során a késleltetésnek kiemelt szerepe van.
forrás: https://db.bme.hu/~gajdos/2012adatb2/3.%20eloadas%20NoSQL%20adatb%E1zisok%20doc.pdf
Egy elosztott rendszer akkor konzisztens, ha bármely időpillanatban egy adategység értékét bármely csomóponttól lekérdezve ugyanazt az értéket kapjuk.
Fontos, hogy az elosztott rendszerek konzisztenciája nem egyezik meg az tranzakciókezelésnél használt ACID (atomicity, consistency, isolation, durability) tulajdonságokban definiált konzisztenciával [16] [17]. Az ACID konzisztencia definíciója azt garantálja, hogy az egyes tranzakciók az adatbázist konzisztens állapotból konzisztens állapotba viszik át, ahol az adatbázison mindig csak a sikeresen lefutott tranzakciók eredménye látszik.
forrás: https://db.bme.hu/~gajdos/2012adatb2/3.%20eloadas%20NoSQL%20adatb%E1zisok%20doc.pdf
Az előre nem definiált ad-hoc szerkezetű adatok nem ízlenek” a relációsmodellnek és a relációs adatbáziskezelőknek.
Továbbá olyan struktúlátlan adat okozhat gondot az RDBMS-nek, mint pl. hang, videó, email, stb.
Forrás: előadás,
http://marketrealist.com/2014/07/traditional-database-systems-fail-support-big-data/
Nagyrészt visszavezethető a növekvő adatmennyiségre. Az RDBMS-eket nem ekkora adat kezelésére tervezték, elkerülhetetlen a lassulás.
Forrás: előadás diasor
Amikor a relációs adatbázisok évzizedekkel ezelőtt elterjedtek, elképzelhetetlennek tűnt, hogy petabyte méretű adatbázisokra szükség legyen. Ez mára megvalósult, és a jövőben se fog leállni a növekedés (lásd: "Big data" buzzword). A nagy adatmennyiségeket viszont már nem kezelik tökéletesen az RDBMS-ek, pl. problémás a sok adat struktúrálása vagy a gyorsan növő adatbázis.
Forrás: előadás diasor,
http://marketrealist.com/2014/07/must-know-big-data-gave-way-to-the-arrival-of-nosql-hadoop/ (--> itt bővebben el lehet mélyülni a témában)
Mikor beszélünk Big Data-ról? (IBM definíció)
Forrás: előadás
