3.1. Gyenge ACID tulajdonságok
Az adatkonzisztencia hosszú ideje szent tehén volt az építészek és a fejlesztők számára. Valamennyi relációs adatbázis biztosított bizonyos szintű elkülönítést, akár frissítési zárolások és blokkoló olvasások, akár visszavonási naplók révén. A hatalmas mennyiségű információ és az elosztott rendszerek megjelenésével világossá vált, hogy lehetetlen számukra egyrészt tranzakciós műveletsort biztosítani, másrészt magas rendelkezésre állást és gyors válaszidőt elérni.
Sőt, még egy rekord frissítése sem garantálja, hogy bármely más felhasználó azonnali változásokat észlel a rendszerben, mert a változás történhet például a fő csomópontban, és a replika aszinkron módon átmásolódik a szolga csomópontba, amellyel egy másik felhasználó művek. Ebben az esetben egy bizonyos idő elteltével látni fogja az eredményt. Ezt nevezik végső konzisztenciának, és erre készül most a világ összes legnagyobb internetes cége, beleértve a Facebookot és az Amazont is. Utóbbiak büszkén kijelentik, hogy a maximális időtartam, amely alatt a felhasználó ellentmondásos adatokat láthat, legfeljebb egy másodperc. Az ábrán látható egy példa egy ilyen helyzetre:
Felmerül egy ilyen helyzetben logikus kérdés, hogy mit kezdjünk azokkal a rendszerekkel, amelyek klasszikusan magas követelményeket támasztanak a műveletek atomitása-konzisztenciájával szemben, és egyben gyors elosztott klasztereket igényelnek - pénzügyi, webáruházak stb. A gyakorlat azt mutatja, hogy ezek a követelmények már nem relevánsak: a pénzügyi bankrendszer egyik tervezője ezt mondta: „Ha valóban megvárnánk minden egyes tranzakció befejezését az ATM-ek globális hálózatában (ATM-ek), a tranzakciók olyan sokáig tartanának, hogy az ügyfelek dühében elszaladna. Mi történik, ha Ön és partnere egyszerre vesz fel pénzt, és túllépi a limitet? – Mindketten megkapjátok a pénzt, és később kijavítjuk.
Egy másik példa a képen látható szállodafoglalás. Azok az online áruházak, amelyek adatpolitikája az esetleges következetességet feltételezi, kötelesek ilyen helyzetekben intézkedni (automatikus konfliktusfeloldás, működés visszaállítása, frissítés más adatokkal). A gyakorlatban a szállodák vészhelyzet esetén mindig igyekeznek egy „medencét” tartani a szabad szobákból, ez pedig megoldást jelenthet egy vitás helyzetre.
Valójában a gyenge ACID tulajdonságok nem jelentik azt, hogy egyáltalán nem léteznek. A legtöbb esetben egy relációs adatbázissal dolgozó alkalmazás egy tranzakciót használ a logikailag kapcsolódó objektumok (rendelés - rendelési tételek) megváltoztatására, ami szükséges, mivel ezek különböző táblák. Az adatmodell megfelelő kialakításával egy NoSQL-adatbázisban (az aggregátum egy rendelés a rendelési tételek listájával együtt), ugyanazt az elszigeteltségi szintet érheti el egyetlen rekord megváltoztatásakor, mint egy relációs adatbázisban.
3.2. Elosztott rendszerek, nincsenek megosztott erőforrások (semmi megosztása)
Ez ismét nem vonatkozik az adatbázisgráfokra, amelyek szerkezete definíció szerint nem terjed jól a távoli csomópontok között.
Talán ez a fő vezérmotívuma a NoSQL adatbázisok fejlesztésének. A világban az információ lavina növekedésével és az ésszerű időn belüli feldolgozás szükségességével a vertikális skálázhatóság problémája merült fel - a processzor sebességének növekedése 3,5 GHz-en megállt, a lemezről történő olvasás sebessége is növekszik. lassú ütemben, ráadásul egy nagy teljesítményű szerver ára mindig több, mint több egyszerű szerver teljes ára. Ebben a helyzetben a hagyományos relációs adatbázisok még lemeztömbökön sem képesek megoldani a sebesség, a méretezhetőség és az átviteli sebesség problémáját.
A helyzetből az egyetlen kiút a vízszintes skálázás, amikor több független szerver csatlakozik egy gyors hálózathoz, és mindegyik csak az adatok egy részét és/vagy az olvasási frissítési kérések egy részét birtokolja/feldolgozza. Ebben az architektúrában a tárolókapacitás (kapacitás, válaszidő, áteresztőképesség) növeléséhez csak egy új szervert kell hozzáadni a fürthöz – és ennyi. Sharding, replikáció, hibatűrés (az eredmény akkor is meglesz, ha egy vagy több szerver nem válaszol), az adatok újraelosztását csomópont hozzáadása esetén maga a NoSQL adatbázis kezeli.
Röviden bemutatom az elosztott NoSQL adatbázisok főbb tulajdonságait:
Replikáció - adatok másolása más csomópontokra frissítéskor. Lehetővé teszi mind a nagyobb skálázhatóság elérését, mind az adatok elérhetőségének és biztonságának növelését. Szokásos két típusra osztani:
master-slave :
és peer-to-peer : 
Az első típus jó skálázhatóságot feltételez az olvasáshoz (bármely csomópontról történhet), de nem méretezhető írást (csak a fő csomópontra). Vannak finomságok is az állandó rendelkezésre állás biztosításával kapcsolatban (főösszeomlás esetén manuálisan vagy automatikusan a fennmaradó csomópontok egyike kerül a helyére). A replikáció második típusa azt feltételezi, hogy minden csomópont egyenlő, és olvasási és írási kéréseket is kiszolgálhat.
A megosztás az adatok csomópontok szerinti felosztása:
A megosztást gyakran használták a relációs adatbázisok „mankójaként” a sebesség és az átviteli sebesség növelése érdekében: a felhasználói alkalmazás több független adatbázis között particionálta az adatokat, és amikor a felhasználó kérte a megfelelő adatokat, hozzáfért egy adott adatbázishoz. A NoSQL-adatbázisokban a felosztást, akárcsak a replikációt, maga az adatbázis végzi automatikusan, és a felhasználói alkalmazás elkülönül ezektől az összetett mechanizmusoktól.
3.3. A NoSQL adatbázisok többnyire nyílt forráskódúak, és a 21. században jöttek létre
A második indok, hogy Sadalaj és Fowler nem sorolta be az objektumadatbázisokat a NoSQL-be (bár a http://nosql-database.org/ tartalmazza őket az általános listán), mivel a 90-es években hozták létre, és soha nem szereztek nagy népszerűséget. .
A NoSQL mozgalom gigantikus ütemben kezd egyre népszerűbb lenni. Ez azonban nem jelenti azt, hogy a relációs adatbázisok maradandóvá vagy archaikussá válnának. Valószínűleg aktívan fogják használni és használni, mint korábban, de egyre több NoSQL adatbázis lép majd szimbiózisban velük. A többnyelvűség korszakába lépünk, egy olyan korszakba, ahol különböző adattárakat használnak különböző igényekhez. Ma már nincs monopóliuma a relációs adatbázisoknak, mint vitathatatlan adatforrásoknak. Az építészek egyre gyakrabban választják a tárolást maguknak az adatoknak a természete és az alapján, hogy miként szeretnénk azokat manipulálni, milyen mennyiségű információ várható. És így minden egyre érdekesebb lesz.
Az alábbiakban megpróbáljuk megérteni egy elosztott adatbázis működését, példaként a NoSQL Cassandra DBMS segítségével ...