2.1 A NoSQL kifejezés megjelenése
A közelmúltban a "NoSQL" kifejezés nagyon divatos és népszerűvé vált, mindenféle szoftvermegoldást aktívan fejlesztenek és népszerűsítenek e jel alatt. A NoSQL a hatalmas adatmennyiség, a lineáris skálázhatóság, a fürtök, a hibatűrés, a nem-relationitás szinonimája lett. Azonban kevesen értik világosan, mi az a NoSQL-tároló, hogyan jelent meg a kifejezés, és milyen közös jellemzőik vannak. Próbáljuk meg pótolni ezt a hiányt.
A kifejezésben az a legérdekesebb, hogy annak ellenére, hogy először a 90-es évek végén használták, a mai formában csak 2009 közepén nyert valódi jelentést. -forrás adatbázis, amelyet Carlo Strozzi hozott létre, amely minden adatot ASCII-fájlként tárolt, és SQL helyett shell-szkripteket használt az adatok eléréséhez. Semmi köze nem volt a "NoSQL"-hez a jelenlegi formájában.
2009 júniusában Johan Oskarsson találkozót szervezett San Franciscóban, hogy megvitassák az IT tárolási és feldolgozási piacának új trendjeit. A találkozó fő lendületét az új nyílt forráskódú termékek, például a BigTable és a Dynamo jelentették. A találkozó fényes jeléhez találni kellett egy tágas és tömör kifejezést, amely tökéletesen illeszkedik a Twitter hashtagba. Az egyik ilyen kifejezést Eric Evans javasolta a RackSpace-től – "NoSQL". A kifejezést csak egy találkozóra tervezték, és nem volt mély szemantikai terhelése, de úgy történt, hogy vírusreklámként terjedt el a globális hálózaton, és egy teljes IT-szakma irányzatának de facto neve lett. A konferencián egyébként felszólalt Voldemort (Amazon Dynamo klón), Cassandra, Hbase (a Google BigTable analógjai), Hypertable, CouchDB, MongoDB.
Érdemes még egyszer hangsúlyozni, hogy a "NoSQL" kifejezés teljesen spontán eredetű, és nem áll mögötte általánosan elfogadott definíció vagy tudományos intézmény. Ez az elnevezés inkább az informatikai fejlesztés vektorát jellemzi a relációs adatbázisoktól távol. A nem csak SQL rövidítése, bár vannak támogatói a No SQL közvetlen meghatározásának. Pramod Sadalaj és Martin Fowler nemrégiben megjelent „NoSQL Distilled” című könyvében igyekezett csoportosítani és rendszerezni a NoSQL világával kapcsolatos ismereteket.
2.2 A NoSQL adatbázisok alapvető jellemzői
Az összes NoSQL-hez kevés közös jellemző van, mivel sok heterogén rendszer most a NoSQL címke alatt rejtőzik (talán a legteljesebb lista a http://nosql-database.org/ címen található). Sok jellemző csak bizonyos NoSQL adatbázisokra jellemző, ezt mindenképpen megemlítem a felsorolásnál.
1. Nem használ SQL-t
Az ANSI SQL DML-re gondolok, mivel sok adatbázis megpróbál a jól ismert kedvenc szintaxishoz hasonló lekérdezési nyelveket használni, de senkinek sem sikerült teljesen megvalósítania, és nem valószínű, hogy sikerül. Bár vannak olyan pletykák, amelyek megpróbálják megvalósítani az SQL-t, például a hadupban ( http://www.drawntoscalehq.com/ és http://www.hadapt.com/ ).
2. Strukturálatlan (séma nélküli)
A jelentés az, hogy a NoSQL adatbázisokban a relációs adatbázisokkal ellentétben az adatstruktúra nincs szabályozva (vagy gyengén tipizált, ha analógiákat vonunk le a programozási nyelvekkel) - tetszőleges mezőt adhatunk külön sorban vagy dokumentumban anélkül, hogy a struktúrát deklaratívan megváltoztatnánk. az egész asztalról. Így, ha szükség van az adatmodell megváltoztatására, akkor az egyetlen elegendő intézkedés az alkalmazás kódjában bekövetkezett változás tükrözése.
Például egy mező átnevezésekor a MongoDB-ben:
BasicDBObject order = new BasicDBObject();
order.put("date", orderDate); // this field was a long time ago
order.put("totalSum", total); // before we just used "sum"Ha megváltoztatjuk az alkalmazási logikát, akkor olvasáskor is új mezőt várunk. De az adatséma hiánya miatt a totalSum mező hiányzik a többi már meglévő Rendelés objektumból. Ebben a helyzetben két lehetőség van a további lépésekre.
Az első az összes dokumentum feltérképezése, és a mező frissítése az összes létező dokumentumban. Az adatmennyiség miatt ez a folyamat zárolás nélkül megy végbe (összehasonlítható az alter table rename column paranccsal), így a frissítés során a már meglévő adatokat más folyamatok is beolvashatják. Ezért a második lehetőség - az alkalmazás kódjának ellenőrzése - elkerülhetetlen:
BasicDBObject order = new BasicDBObject();
Double totalSum = order.getDouble("sum"); // This is the old model
if (totalSum == null)
totalSum = order.getDouble("totalSum"); // This is the updated modelÉs már amikor újra rögzítjük, ezt a mezőt új formátumban írjuk az adatbázisba.
A séma hiányának kellemes következménye a ritka adatokkal való munka hatékonysága. Ha az egyik dokumentumban van közzétételi dátum mező, a másikban pedig nincs, akkor a másodikhoz nem jön létre üres dátum_közzététel mező. Ez elvileg logikus, de kevésbé nyilvánvaló példa az oszlopcsaládos NoSQL-adatbázisok, amelyek a táblák / oszlopok ismert fogalmait használják. A séma hiánya miatt azonban az oszlopok nem deklaratív módon kerülnek deklarálásra, és a felhasználó adatbázis-munkamenete során módosíthatók/adhatók hozzá. Ez különösen lehetővé teszi a dinamikus oszlopok használatát a listák megvalósításához.
A strukturálatlan sémának megvannak a maga hátrányai - az adatmodell megváltoztatásakor az alkalmazáskódban fent említett többletterhelésen kívül - mindenféle korlátozás hiánya az alapból (nem null, egyedi, ellenőrzési kényszer stb.), plusz további nehézségeket okoz a szerkezeti adatok megértése és ellenőrzése, ha párhuzamosan dolgozunk különböző projektek adatbázisával (nincs szótár az adatbázis oldalán). A gyorsan változó modern világban azonban ez a rugalmasság még mindig előnyt jelent. Példa erre a Twitter, amely öt évvel ezelőtt a tweettel együtt még csak kevés plusz információt tárolt (időt, Twitter-leírót és még néhány bájt metainformációt), most viszont magán az üzeneten kívül még néhányat. kilobájt metaadat tárolódik az adatbázisban.
(A továbbiakban főként kulcsérték, dokumentum és oszlopcsalád adatbázisokról beszélünk, előfordulhat, hogy a gráf adatbázisok nem rendelkeznek ezekkel a tulajdonságokkal)
2.3. Adatok megjelenítése aggregátumok (aggregátumok) formájában
A relációs modelltől eltérően, amely az alkalmazás logikai üzleti entitásait különféle fizikai táblákban tárolja normalizálási célból, a NoSQL-tárolók holisztikus objektumokként működnek ezeken az entitásokon:
Ez a példa egy szabványos e-kereskedelmi koncepcionális relációs modell összesítését mutatja be: „Megrendelés – Rendelési tételek – Fizetés – Termék”. Mindkét esetben a rendelés pozíciókkal kombinálva egyetlen logikai objektumban történik, miközben minden pozíció egy hivatkozást tárol a termékre és annak egyes attribútumaira, például a névre (ilyen denormalizálás azért szükséges, hogy ne kérjen termékobjektumot a lekérésekor egy sorrend - az elosztott rendszerek fő szabálya az objektumok közötti "csatlakozás"). Az egyik aggregátumban a fizetések a megbízással kombinálódnak, és az objektum szerves részét képezik, a másikban pedig külön objektumban kerülnek elhelyezésre. Ez szemlélteti a NoSQL-adatbázisok adatszerkezetének tervezésének fő szabályát – meg kell felelnie az alkalmazás követelményeinek, és a lehető legjobban optimalizálni kell a leggyakoribb kérésekre.
Sokan tiltakoznak, és megjegyzik, hogy a nagy, gyakran denormalizált objektumokkal végzett munka számos problémával jár, amikor tetszőleges lekérdezéseket próbálnak ki az adatokra, amikor a lekérdezések nem illeszkednek az aggregátumok szerkezetébe. Mi van akkor, ha a rendeléseket a rendelési sorokkal és a fizetésekkel együtt használjuk (az alkalmazás így működik), de a vállalkozás megkér bennünket, hogy számoljuk meg, hány darabot adtak el egy adott termékből a múlt hónapban? Ebben az esetben a OrderItem tábla szkennelése helyett (relációs modell esetén) a teljes rendelést a NoSQL tárhelyen kell lekérnünk, bár ezekből az információkból nem sokra lesz szükségünk. Sajnos ez egy kompromisszum, amit egy elosztott rendszerben meg kell kötni: nem tudjuk normalizálni az adatokat, mint egy hagyományos egykiszolgálós rendszerben,
Megpróbáltam egy táblázatban csoportosítani mindkét megközelítés előnyeit és hátrányait:
