Kezdő útmutató a NoSQL világához
Az adatok rendezése nagyon nehéz feladat. Amikor azt mondjuk, hogy szervezzen, akkor tulajdonképpen kategorizáljuk a dolgokat annak típusától és funkciójától függően.
Az egyik lehetőség, hogy az RDBMS olyan, mint egy Excel lap - az adatokat táblák formájában kategorizálja. Kapcsolatokat alakíthat ki a táblák között.
Egy lekérdezés megkérdőjelezi az adatbázist, amely cserébe megfelelő választ ad. Ez a lekérdező nyelv SQL vagy strukturált lekérdezési nyelv.
Például,
select * from Employee_Data;kiválasztja az összes alkalmazott adatot az Employee_Data táblából.
A relációs adatbázisok egy sémát követnek , a táblázatok működésének részletes tervét.
Használja az Amazon, a Facebook és a sok hálózati alkalmazást. Kiadják a frissítéseket, új funkciókat és még extra modulokat adnak hozzá. Tehát hogyan változtatja meg valaki a sémát minden alkalommal? Nem időigényes egy ilyen hatalmas vállalat számára, hogy idejét és munkáját a séma megváltoztatására fordítsa?
Itt nem tudott működni az SQL .
Az RDBMS hátrányai
A relációs adatbázisok nem olyan rosszak, mint manapság az emberek. Még mindig rengeteg szervezet használja őket. A NoSQL bevezetése a képbe az a hely kitöltése, ahol az RDBMS már nem használható.
Példákat fogok mutatni nektek, hogy világos megértésetek legyen.
1. Az RDBMS nem tudja kezelni az „Adat Változatot”.
A strukturálatlan adatok mennyisége folyamatosan növekszik évente, és kezelése nehéz. Az RDBMS nem kényszeríthet minden típusú adatot a táblák egységes sémája alá.
Az adat silók a fejlesztők számára is problémát jelentenek.
Szerint a Tech Target, a adatok siló tárháza adatok maradványai ellenőrzése alatt egy osztály. Elszigetelt a szervezet többi részétől.
Ez azt jelenti, hogy ha több siló létezik ugyanazon adatokhoz, akkor azok tartalma valószínűleg eltér. Zavart kelt, hogy melyik tár jelenti a legfrissebb verziót.
Az adatok 2013 és 2020 közötti növekedése az alábbi képen látható.
Körülbelül 44 Zeta bájt adat keletkezik 2020-ban.Az ilyen sokféle, egymással nem összefüggő adat kezelése sokkal nehezebb lehet az RDBMS-ben.
Példa: Nehéz elraktározni egy olyan beteg adatait, akinek a test állapota változó. Az RDBMS-ben ilyen sokféle adat kategorizálása nehéz.
2. Nehéz megváltoztatni a táblázatokat és a kapcsolatokat.
A táblák közötti kapcsolatok megváltoztatása vagy egy új tábla hozzáadása befolyásolhatja a meglévő kapcsolatokat. Ez a séma megváltoztatását jelenti.
A séma megváltoztatása olyan lenne, mint a meglévő megszüntetése és egy új séma kidolgozása.
Egy új funkció hozzáadásához minden elemre szükség lesz az új struktúra támogatásához. A változás elkerülhetetlen.
Példa: Minden extra oszlopnak meg kell adnia az összes előző sort, hogy rendelkezzenek értékekkel az oszlophoz. Míg a Cassandra-ban (NoSQL adatbázis) oszlopot adhat hozzá a sorok partícióihoz.
3. Az RDBMS követi az adatbázis ACID tulajdonságait.
Az adatbázis ACID tulajdonságai az atomosság, a konzisztencia, az izolálás és a tartósság.
Atomicitás - „minden vagy semmi” megközelítés. Ha a tranzakcióban bármelyik utasítás meghiúsul, akkor a teljes tranzakció visszaáll.
Következetesség - A tranzakciónak meg kell felelnie a rendszer által meghatározott összes protokollnak. Nincs félig befejezett tranzakció.
Elkülönítés - egyetlen tranzakció sem férhet hozzá olyan egyéb tranzakciókhoz, amelyek köztes vagy befejezetlen állapotban vannak. Minden tranzakció független.
Tartósság - Biztosítja, hogy amint egy tranzakció elkötelezi magát az adatbázis mellett, a biztonsági másolatok és a tranzakciós naplók használatával megőrzi azt.
Az ACID tulajdonságok nem rugalmasak.
Például az RDBMS a normalizálást vagy az igazság egyetlen pontjának koncepcióját követi . Minden módosításhoz szigorú ACID tulajdonságokat kell biztosítani. Az entitás integritásának és a referenciális integritásának szabályai is érvényesek.
A KAP-tétel
A Wikipedia szerint a CAP-tétel (Brewer-tétel) kimondja, hogy lehetetlen, hogy az elosztott adattár egyidejűleg a következő három garancia közül kettőnél többet biztosítson:
Összhang: Mint a C az ACID-ban.
Elérhetőség : A forrásoknak mindig rendelkezésre kell állniuk. Nem hibaüzenetet kell adni.
Partíciótűrés : Nincs egyetlen meghibásodási pont (vagy csomópont).
Nehéz mindhárom feltételt teljesíteni. Kompromisszumot kell kötni a három között.
ALAP a mentéshez!
A NoSQL egy lágyabb modellre támaszkodik, amelyet BASE modellnek hívnak. ALAP ( B asically A vaable , S oftate state, E ventual összhang).
Alapvetően elérhető: Garantálja az adatok elérhetőségét. Bármely kérésre válasz érkezik (lehet kudarc is).
Lágy állapot : A rendszer állapota idővel változhat.
Végső konzisztencia: A rendszer végül konzisztenssé válik, amint abbahagyja a bemenetek fogadását.
A NoSQL adatbázisok feladják az A, C és / vagy D követelményeket, cserébe javítják a skálázhatóságot.
NoSQL
Ekkor jött a NoSQL segítségére. “A„ Nem csak SQL ” vagy a„ Nem relációs ”adatbázisokról van szó.
A NoSQL jellemzői:
- Séma mentes
- Végül következetes (mint a BASE tulajdonságban)
- Adattárolók replikálása az egyetlen pont meghibásodásának elkerülése érdekében.
- Kezeli az adatok változatosságát és hatalmas mennyiségű adatot.
A NoSQL adatbázis típusai
A NoSQL adatbázisok négy fő kategóriába sorolhatók:
Kulcsértékű üzletek - Riak, Voldemort és Redis
Széles oszlopok - Cassandra és HBase.
Dokumentum adatbázisok - MongoDB
Grafikon adatbázisok - Neo4J és HyperGraphDB.
A jobb oldali szavak példák a NoSQL adatbázis-típusokra.
1. Kulcsérték-tárolók
A kulcsérték-tároló hash-táblázatot használ , amelyben létezik egyedi kulcs és egy mutató egy adott adatelemre.
Képzelje el, hogy a kulcsérték-tárolók olyanok, mint egy telefonkönyv, ahol az egyén neve és száma össze van térképezve.
A kulcsérték-tárolóknak nincs alapértelmezett lekérdezési nyelve. Az adatok lekérése a get, put és delete parancsokkal történik. Ez az oka annak, hogy nagy teljesítményű.
Alkalmazások : Hasznos a megjegyzések és a munkamenet információk tárolásához. Pinterest a Redis segítségével tárolja a felhasználók, követők, követők, táblák listáját.
2. Széles oszloptárolók
Egy oszloptároló adatbázisban az egyes sorok oszlopai az adott sorban találhatók.
Minden oszlopcsalád egy sor tároló egy RDBMS táblában. A kulcs azonosítja a több oszlopból álló sort.
A soroknak nem kell ugyanannyi oszlopuk lenni . Oszlopok bármikor hozzáadhatók bármelyik sorhoz anélkül, hogy hozzá kellene adni más sorokhoz. Ez egy particionált sortár.
Hogyan tárol egy oszlopos adatbázis adatokat?
Alkalmazások : A Spotify a Cassandra segítségével tárolja a felhasználói profil attribútumait és metaadatait.
3. Dokumentum adatbázisok
A dokumentumtárolók JSON, XML vagy BSON (JSON bináris kódolása) dokumentumokat használnak az adatok tárolásához.
Olyan, mint egy kulcsérték-adatbázis, de a dokumentumtár félig strukturált adatokból áll .
Egyetlen dokumentum a nyilvántartások és azok adatainak tárolása.
Ez nem támogatja a kapcsolatokat vagy csatlakozik.
Ha el akarjuk tárolni az ügyfél adatait és megrendeléseiket, használhatunk erre dokumentumtárakat.
Alkalmazások: SEGAA MongoDB-t 11 millió, a MongoDB-re épített játékon belüli fiók kezelésére használja.
4. Grafikon adatbázisok
A csomópontok és kapcsolatok a gráf adatbázisok alapvető elemei. A csomópont egy entitást képvisel. A kapcsolat azt jelzi, hogy két csomópont hogyan kapcsolódik egymáshoz.
RD Az RDBMS-ben egy másik reláció hozzáadása sok sémaváltozást eredményez.
A grafikon-adatbázis csak egyszer tárolja az adatokat (csomópontok). A különböző típusú kapcsolatok (élek) meg vannak adva a tárolt adatokhoz.
A csomópontok közötti kapcsolatok előre meghatározottak, vagyis nem a lekérdezés időpontjában vannak meghatározva.
A folyamatos kapcsolatok gyorsabbak.
Két csomópont közötti viszonyt nehéz megváltoztatni. Regresszív változásokat eredményezne az adatbázisban.
Példa : Ezzel a képpel működik a MySQL, ahol sok műveletet kell végrehajtania ahhoz, hogy helyes eredményt találjon Alice számára.
A grafikon-adatbázis , amely előre meghatározza a kapcsolatokat.
Ez néhány alapvető információ, amire szüksége lesz a NoSQL felfedezéséhez. Új felhasználási célokra új adatbázisokat találnak ki.
Ismerje meg az alkalmazás által generált adatok típusát, és akkor könnyű kiválasztani a megfelelő adatbázist.