SQL vs. NoSQL – mit használjon a következő projektnél?

Az egyik leggyakrabban feltett kérdés – milyen adatbázist kell használni?


Az SQL a strukturált lekérdezési nyelv. Elsőként az 1970-es években fejlesztették ki egy IBM kutatócsoport. A NoSQL adatbázisokat viszont 1998-ban először Carlo Strozzi használta.

A két adatbázis (DB) rendszer közötti leggyakoribb különbség az, hogy az SQL relációs és a NoSQL nem relációs.

Mélyítsük el ezt a két adatbázist, hogy jobban tájékoztassuk a döntésedről, amikor a következő alkalommal fontolja meg a projekt adatbázisát.

Az adatbázis felépítése

Beszéljünk a strukturálásáról.

SQL

SQL Az adatbázisnak egy meghatározott séma felépítése van.

A séma táblázatokat tartalmaz, és minden táblázat határozott számú oszlopot tartalmaz. Ez azt jelenti, hogy a felhasználó nem frissítheti a táblát a táblázatban megadott oszlopok számán túl. Ez különösen akkor hasznos, ha meg kell őriznie az adatok integritását, és ellenőriznie kell az adatbázisba mentett adatok fajtáját is.

Az SQL adatbázis minden táblája összekapcsolható. vagyis kapcsolatok lehetnek a táblák között. Ezek a kapcsolatok lehetnek egymáshoz sok, sok a sokhoz vagy egy az egyhez. Az alkalmazott kapcsolat típusa attól függ, mire van szüksége.

Vegyük például a hipotetikus helyzetet; Van egy cégünk a felhasználókkal, és a felhasználók megrendeléseket tehetnek a termékekre. Ezután eldönthetjük, hogy a felhasználók több megrendelést is létrehozhatnak, de minden egyes megrendelést csak egy felhasználó hozhat létre. Ez egy a sokhoz viszony, azaz egy felhasználó a sok megrendeléshez. Ezért mindkét táblázat táblázata felépítéséhez hasonlóan fog kinézni.

A DB-ben rendelkezhetünk felhasználói táblával, az alábbiak szerint,

USERS_TABLE
—————————————————-
azonosító | név | email
—————————————————–
1 Idris [Email protected]

Lehet, hogy megrendelési táblázata is van

orders_table
———————————————————————————
azonosító | user_id | Rendelésszám
———————————————————————————
1 1 20000001

A user_id a megrendelések táblájában megkönnyíti a megrendelések tábláin belüli egyes rendelések hozzárendelését annak a felhasználónak, amelyhez tartozik. Egy egy-egy kapcsolat esetén a order_id a felhasználói_táblán is szerepelhet, ha úgy döntünk, hogy a felhasználót a hozzá tartozó rendelési azonosító alapján kapjuk meg..

Sok-sok helyzethez általában egy extra táblázatot hívnak, amelyet Pivot táblának hívnak. Ez lehetővé teszi több rekord egymáshoz való hozzárendelését. A fenti példát használva. Mi volna,

USERS_TABLE
————————————————————————————-
azonosító | név | email
————————————————————————————-
1 Idris [Email protected]

és a megrendelési táblázat lesz

orders_table
———————————————————
azonosító | Rendelésszám
———————————————————
1 2000001

majd a Pivot táblázat mindkét azonosítót idegen kulcsként fogja tárolni.

users_orders_table
——————————————————————————
azonosító | order_id | Felhasználói azonosító
——————————————————————————
1 1 1

Az SQL által biztosított ezen struktúra alapján kényelmesen írhatja a Csatlakozásokat a táblák között, amelyek különböző lekérdezésekkel összekapcsolt táblázatok adatait szolgáltatják.

NoSQL

NoSQL Az adatbázisokat rugalmasabbá tették, mint az SQL DB-k, és nagyobb adatmennyiségeket is tartalmaznak.

A NoSQL DB-kben nincs előre meghatározott séma vagy táblázat. Vannak gyűjtemények, és minden gyűjteményben vannak dokumentumok. Ez lehetővé teszi az adatok elmentését különböző formákban, ahogy azok megjelennek. Választhat, hogy egy gyűjteményben több változó dokumentum van-e különböző mezőkkel. A gyűjtemények közötti kapcsolatok manuális létrehozására is lehetőség van. Ezek azonban nem alkalmasak erre a célra. Ehelyett mindazt, amely egyetlen lekérdezéshez szükséges, elmentheti ugyanabba a gyűjteménybe.

Ha SQL személy, akkor a Gyűjtemények táblázatokként és a Dokumentumok sorokként gondolkodhat a táblázatokkal együtt. A táblával felvehető adat oszlopokra azonban nincsenek korlátozások.

Visszatérve egy korábban definiált hipotetikus példánkhoz, amelyben egy cég működik felhasználói és megrendelések alapján.

A felhasználói gyűjtemény meghatározható úgy, mint,

{id: 1, név: ‘idris’, e-mail: ‘[Email protected]„}

És a Megrendelések Gyűjteményét úgy lehetne definiálni, mint:,

{id: 1, order_umber: 2000001, user_id: 1}

Ebben az esetben azonban el akarjuk kerülni, hogy manuálisan csatlakoztassuk mindkét Gyűjteményt (ami ebben az esetben nem kellene). A bejegyzéseket elmenthetjük a legolvasottabb gyűjteménybe. Úgy döntöttem (ebben a példában), hogy ez lesz a Megrendelések gyűjteménye.

{id: 1, rendelési szám: 200001, felhasználó {id: 1, név: ‘idris’, e-mail: ‘[Email protected]„}}

Ebben az esetben nem kell többé olvasnunk a Felhasználói Gyűjteményből, és csak a Megrendelések Gyűjteményéből kell olvasnunk, amely most az összes szükséges adatot tartalmazza.

Kulcsfontosságú dolog, amelyet itt érdemes megjegyezni: Ha olyan alkalmazást készít, amely sokkal olvassa, mint ír, a NoSQL opció valószínűleg sokkal megfelelőbb az Ön számára. Mivel az összes adatot ugyanabba a gyűjteménybe mentheti, és kényelmesen elolvastat ebből a forrásból az összes szükséges adat megszerzéséhez.

Azonban egy olyan alkalmazás számára, amely ilyen skálán sok írást igényel (kb. 10 000 írást másodpercenként), nem jó ötlet olyan NoSQL opció, ahol ugyanazokat az adatokat több helyre kell írni. Ebben a helyzetben az SQL opció valószínűleg megfelelőbb, ha az összes táblához létező kapcsolatok vannak, és ugyanazokat az adatokat nem kell több helyre többször írni, az adatok frissítésével az egyik helyen a többi táblázat elérhető a kilépésen keresztül. kapcsolat. Ez természetesen nem azt jelenti, hogy ezen adatbázisok mindegyike nem képes kezelni a méretarányt.

skálázás

Fedezzük fel, hogyan működik a méretezés.

SQL

Az SQL DB-k nem vízszintesen, hanem csak függőlegesen méretezhetők. Mit is jelent ez??

A vízszintes méretezés azt jelenti, hogy az adatokat egy DB-ből több adatbázisba osztják, hogy megkönnyítsék a betöltést. Az SQL-adatok szigorú jellege miatt azonban nem bonthatók külön DB-ken. Az SQL DB méretarányának növelése a meglévő DB szerver CPU, memória és lemezterület növelését jelenti, és ez azt jelenti, hogy függőlegesen skálázni kell..

vízszintes méretezés

függőleges méretezés


NoSQL

A NoSQL DB-k vízszintesen és függőlegesen is méretezhetők. Ennek oka az adattárolás rugalmassága. Ez lehetővé teszi adatainak felosztását több adatbázisban, mint a vízszintes méretezés esetén. Szükség esetén függőlegesen is méretezhető.

Kulcsfontosságú dolog, amelyet itt érdemes megjegyezni: Méretezés esetén az SQL és a NoSQL adatbázisok hatékonyan méretezhetők. Az SQL DB-k esetében azonban a vertikális méretezés korlátozás lehet; egyetlen DB szerver korlátozza a hordozható számítógépes teljesítmény mennyiségét.

Fontos itt megjegyezni, hogy a legtöbb alkalmazás, amelyet Ön épít, valószínűleg nem érheti el a szerver számítási képességének maximális értékét, de hasznos ezt szem előtt tartani. Az SQL-t megvalósító nagyvállalati alkalmazások esetében azonban a Sharding népszerű választási lehetőséget kínál e korlátozás legyőzésére.

Mi az a Sharding??

A szilánkolás a nagy asztalok apró darabbá történő darabolására szolgáló folyamat, amelyet szilánknak neveznek. A sharding vízszintesen particionálva végezhető el. Ezt nem szabad összekeverni a vízszintes és a függőleges méretezéssel. A vízszintes particionálás a táblázat sorainak több adatbázis-csomópontban történő tárolásának folyamatát jelenti. A vertikális particionálás viszont megköveteli a táblázat oszlopainak mentését a különféle csomópontokon. Ez lehetővé teszi az adatbázis hatékony méretezését és a teljesítmény fokozását.

Példák az adatbázisra

SQL

  • MySQL – Egy nagyon népszerű nyílt forráskódú adatbázis. Sok PHP fejlesztõ számára a választott adatbázis könnyen használható a Node.js, C #, C ++, Java, Perl, Ruby és Python segítségével..
  • MSSQL – A Microsoft SQL nagy stabilitást biztosít, mivel fejlesztése közvetlenül a Microsofttól származik, amely némi támogatást is kínál a katasztrófa utáni helyreállítás szempontjából..
  • MariaDB – Ezt a MySQL-t a MySQL készítői építették fel, azzal a szándékkal, hogy a MariaDB örökre ingyenes verziója maradjon..
  • PostgresSQL – Nagyon népszerű nyílt forráskódú adatbázis. Büszke arra, hogy a világ legfejlettebb nyílt forráskódú adatbázisa
  • Oracle – Ezt általában az Oracle vállalati megoldásaihoz igazítják, korlátozva annak ingyenes verzióját.

NoSQL

  • MongoDB – Valószínűleg a legismertebb NoSQL DB, a MERN veremmel (MongoDB, Express, React, Node) vagy a MEAN veremmel (MongoDB, Express, szög, csomópont) dolgozó alkalmazásfejlesztők körében általános..
  • Firebase – A 2011-ben bevezetett, és a Google 2014-ben megszerezte, széles körben használják az internetes és mobil alkalmazások fejlesztői.
  • Apache Couch DB – dokumentum-alapú NoSQL DB, amely JSON formátumban tárolja az adatokat.
  • Redis: Ez a NoSQL DB, valószínűleg a legismertebb az adatok tárolására való felhasználásával, opcionálisan megélhetési idővel. Ez a sebesség is jól ismert.

Következtetés

Bármilyen alkalmazást létrehozhat SQL vagy NoSQL adatbázis segítségével. Ez az Ön igényeitől függ. Ha olyan adatbázist fontolgat, ahol több olvasás és kevesebb írás van, a NoSQL jó lehet. Ha azonban fontolóra veszi egy olyan alkalmazás létrehozását, amely több írással rendelkezik, mint olvassa, az SQL lehet a jobb megoldás. A méretezhetőség szempontjából, amikor az alkalmazás nagyon hatalmas léptékre kerül, akkor előfordulhat, hogy mindkét DB-t felhasználja.

CÍMKÉK:

  • adatbázis

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map