SQL vs NoSQL – kurį turėtumėte naudoti savo kitame projekte?

Vienas iš dažniausiai užduodamų klausimų – kokią duomenų bazę turėčiau naudoti …


SQL reiškia Struktūrizuota užklausų kalba. Pirmą kartą ją sukūrė aštuntajame dešimtmetyje IBM tyrinėtojų komanda. NoSQL duomenų bazės, priešingai, 1998 m. Pirmą kartą buvo panaudotos Carlo Strozzi.

Labiausiai paplitęs skirtumas tarp šių dviejų duomenų bazių (DB) sistemų yra tas, kad SQL yra reliacinis, o NoSQL – nesusijęs.

Gilinkimės į šias dvi duomenų bazes, kad geriau praneštume apie savo sprendimą, kai kitą kartą svarstysite savo projekto duomenų bazę.

Duomenų bazės struktūra

Pakalbėkime apie struktūrizavimą.

SQL

SQL duomenų bazė turi apibrėžtą schemos struktūrą.

Schemoje yra lentelės, o kiekvienoje lentelėje yra nurodytas stulpelių skaičius. Tai reiškia, kad vartotojas negali atnaujinti lentelės, jei joje nėra stulpelių. Tai ypač naudinga, kai reikia išlaikyti duomenų vientisumą ir įsitikinti, kokie duomenys yra išsaugomi jūsų duomenų bazėje.

Kiekviena SQL duomenų bazės lentelė gali būti susijusi. y., galite turėti ryšių tarp lentelių. Šie santykiai gali būti vienas su daugeliu, daug su daugeliu arba vienas su vienu. Ryšių tipas, kurį įgyvendinate, priklauso nuo to, ko jums reikia.

Pavyzdžiui, panagrinėkime hipotetinę situaciją; turime įmonę su vartotojais, o vartotojai gali užsisakyti produktus. Tada galėtume nuspręsti, kad vartotojai gali sukurti kelis užsakymus, tačiau kiekvieną užsakymą gali sukurti tik vienas vartotojas. Tai būtų vienas prieš daugelį santykių, t. Y. Vienas vartotojas daugeliui užsakymų. Taigi abiejų lentelių lentelės struktūra atrodys panaši į žemiau pateiktas.

Savo DB mes galėtume turėti vartotojų lentelę, kurios struktūra būtų tokia, kaip nurodyta toliau,

vartotojų lentelė
—————————————————-
id | vardas | el
—————————————————–
1 Idris [apsaugotas el. paštu]

Taip pat galėtume turėti užsakymų lentelę

užsakymų lentelė
———————————————————————————
id | user_id | užsakymo numeris
———————————————————————————
1 1 20000001

„User_id“ užsakymų lentelėje leidžia lengvai susieti kiekvieną užsakymų lentelės užsakymą su vartotoju, kuriam jis priklauso. Jei santykiai „vienas su vienu“, užsakymo_ ID taip pat galėtume turėti „vartotojų_ lentelėje“, jei nuspręstume vartotoją gauti pagal susijusį užsakymo ID.

Daugeliui situacijų paprastai naudojama papildoma lentelė, vadinama „Pivot“ lentele. Tai leidžia susieti kelis įrašus vienas su kitu. Naudojant aukščiau pateiktą pavyzdį. Mes turėtume,

vartotojų lentelė
————————————————————————————-
id | vardas | el
————————————————————————————-
1 Idris [apsaugotas el. paštu]

o užsakymų lentelė bus

užsakymų lentelė
———————————————————
id | užsakymo numeris
———————————————————
1 2000001

tada „Pivot“ lentelėje abu ID bus laikomi kaip svetimi raktai.

vartotojų užsakymai_ lentelė
——————————————————————————
id | order_id | Vartotojo ID
——————————————————————————
1 1 1

Remdamiesi šia SQL pateikta struktūra, galite patogiai rašyti sujungimus tarp lentelių, kurie pateiks duomenis iš skirtingų lentelių, sujungtų į vieną užklausą..

„NoSQL“

„NoSQL“ duomenų bazės buvo sukurtos lankstesnės nei SQL duomenų bazės, taip pat turinčios didesnį duomenų kiekį.

„NoSQL DB“ nėra iš anksto apibrėžtų schemų ar lentelių. Yra kolekcijos, o kiekvienoje kolekcijoje yra dokumentai. Tai leidžia išsaugoti įvairius pavidalus duomenis. Galite pasirinkti, kad vienoje kolekcijoje būtų keli skirtingi dokumentai su skirtingais laukais. Taip pat galima rankiniu būdu užmegzti ryšius tarp kolekcijų. Tačiau jie nėra tinkami tokiam tikslui. Vietoje to, galite išsaugoti visa tai, ko reikia vienai užklausai, toje pačioje kolekcijoje.

Jei esate SQL asmuo, galite galvoti apie Kolekcijas kaip lenteles ir Dokumentus kaip eilutes su lentelėmis. Tačiau duomenų stulpeliams, kuriuos galite pridėti kartu su lentele, nėra jokių apribojimų.

Grįžtame prie mūsų anksčiau apibrėžto hipotetinio įmonės pavyzdžio su vartotojais ir užsakymais.

Vartotojų kolekcija gali būti apibrėžta kaip,

{id: 1, vardas: ‘idris’, el. paštas: ‘[apsaugotas el. paštu]‘}

O Užsakymų kolekciją būtų galima apibrėžti kaip,

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

Tačiau šiuo atveju norime išvengti rankinio prisijungimo prie abiejų kolekcijų (kurių šiuo atveju neturėtume). Įrašus galime išsaugoti kolekcijoje, kuri yra labiausiai skaitoma. Aš nusprendžiau (šiuo pavyzdžiu), kad tai bus užsakymų kolekcija.

{id: 1, order_number: 200001, user {id: 1, name: ‘idris’, email: ‘[apsaugotas el. paštu]‘}}

Tokiu atveju mums nebereikia skaityti iš Vartotojų kolekcijos ir skaityti tik iš Užsakymų kolekcijos, kurioje dabar yra visi mums reikalingi duomenys.

Svarbiausias dalykas, į kurį reikia atkreipti dėmesį: Jei kuriate programą, kuri daug skaito, o ne rašo, greičiausiai jums labiau tinka „NoSQL“ parinktis. Nes visus duomenis galėjote išsaugoti toje pačioje kolekcijoje, o iš to šaltinio galėtumėte patogiai skaityti, kad gautumėte visus reikiamus duomenis.

Tačiau tokiai programai, kuriai reikia daug rašymo (maždaug 10 000 rašo per sekundę) tokiu mastu, nėra gera idėja turėti „NoSQL“ parinktį, kai reikia tuos pačius duomenis rašyti keliose vietose. Šioje situacijoje labiau tikėtina SQL parinktis, kai turite ryšių su visomis lentelėmis, o tų pačių duomenų nereikia pakartotinai rašyti keliose vietose, atnaujinti duomenis vienoje vietoje kitoms lentelėms gali būti prieinama per išeinantį puslapį. santykiai. Tai, žinoma, nereiškia, kad kiekviena iš šių duomenų bazių negali valdyti mastelio.

Mastelio keitimas

Panagrinėkime, kaip veikia mastelio keitimas.

SQL

SQL duomenų bazės negali būti keičiamos horizontaliai, o tik vertikaliai. Ką tai net reiškia?

Horizontalus masto keitimas reiškia duomenų padalijimą iš vienos DB į kelias duomenų bazes, kad būtų lengviau įkelti duomenis. Tačiau dėl griežto SQL duomenų SQL negalima skaidyti į atskiras DB. Tinkamas SQL DB mastelio padidinimas yra esamo DB serverio procesoriaus, atminties ir disko vietos padidinimas, ir tai reiškia, kad reikia jį vertikaliai padidinti..

horizontalus mastelio keitimas

vertikalus mastelis


„NoSQL“

„NoSQL“ duomenų bazės gali būti keičiamos horizontaliai ir vertikaliai. Taip yra dėl duomenų saugojimo lankstumo. Todėl tai leidžia padalyti duomenis keliose duomenų bazėse, kaip tai daroma horizontaliojo mastelio atveju. Prireikus jis taip pat gali būti keičiamas vertikaliai.

Svarbiausias dalykas, į kurį reikia atkreipti dėmesį: Jei reikia mastelio, tiek SQL, tiek NoSQL duomenų bazės gali būti efektyviai keičiamos. Tačiau SQL DB vertikali mastelio keitimas gali būti apribojimas; viename DB serveryje bus ribojama skaičiavimo galia, kurią jis gali nešti.

Čia taip pat svarbu atkreipti dėmesį, kad daugumoje jūsų sukurtų programų galbūt nepasinaudosite serverio skaičiavimo galimybėmis, tačiau naudinga tai atsiminti. Tačiau didelėms verslo programoms, diegiančioms SQL, populiariausia galimybė įveikti šį apribojimą yra „Sharding“.

Kas yra „Sharding“??

Sharding yra didelių lentelių suskaidymas į mažus gabalus, kurie vadinami skaldomis. Šalinimas gali būti atliekamas horizontaliai padalijant duomenų bazę. Tai neturi būti painiojama su horizontaliu ir vertikaliu masteliais. Horizontalusis skaidymas reiškia lentelės eilučių saugojimo keliuose duomenų bazės mazguose procesą. Atliekant vertikalų skaidymą, reikia išsaugoti lentelės stulpelius skirtinguose mazguose. Tai leidžia duomenų bazę efektyviai išplėsti ir padidinti našumą.

Duomenų bazės pavyzdžiai

SQL

  • „MySQL“ – labai populiari atvirojo kodo duomenų bazė. Lengvai pasirinkta daugelio PHP kūrėjų duomenų bazė taip pat gali būti naudojama su Node.js, C #, C ++, Java, Perl, Ruby ir Python.
  • MSSQL – „Microsoft SQL“ teikia daug stabilumo, nes jos plėtrą tiesiogiai teikia „Microsoft“, kuri taip pat teikia tam tikrą paramą atkūrimo srityje.
  • „MariaDB“ – tai „MySQL“ sukūrė „MySQL“ kūrėjai, ketindami išlaikyti „MariaDB“ kaip nemokamą amžinąją versiją.
  • PostgresSQL – labai populiari atvirojo kodo duomenų bazė. Didžiuojasi kaip pažangiausia pasaulyje atvirojo kodo duomenų bazė
  • „Oracle“ – tai dažniausiai pritaikyta „Oracle“ verslo sprendimams, su tam tikrais nemokamos versijos apribojimais.

„NoSQL“

  • „MongoDB“ – turbūt labiausiai žinomas „NoSQL DB“, paplitęs tarp programų kūrėjų, dirbančių su MERN rietuvėmis („MongoDB“, „Express“, „React“, „Node“) arba „MEAN stack“ („MongoDB“, „Express“, „Kampinis“, „Node“)..
  • „Firebase“ – pristatyta 2011 m., O „Google“ įsigyta 2014 m., Plačiai naudojama interneto ir mobiliųjų programų kūrėjams.
  • „Apache Couch DB“ – dokumentais pagrįsta „NoSQL DB“, kurioje duomenys saugomi kaip JSON.
  • „Redis“: Tai „NoSQL DB“, tikriausiai labiausiai žinomas dėl to, kad naudojamas duomenims saugoti su pasirenkamu laiko gyventi. Jis taip pat gerai žinomas dėl savo greičio.

Išvada

Galite sukurti bet kokio tipo programas naudodami SQL arba NoSQL duomenų bazę. Tai priklauso nuo jūsų poreikių. Jei svarstote apie duomenų bazę, kurioje daugiau skaityta ir parašyta mažiau, „NoSQL“ gali būti geras pasirinkimas. Jei vis dėlto svarstote galimybę sukurti programą, kurioje būtų daugiau rašymo, o ne perskaitymo, geresnis sprendimas gali būti SQL. Dėl mastelio padidėjimo, kai jūsų programa taps labai plataus masto, galite baigti naudoti abi DB.

ŽENKLAI:

  • Duomenų bazė

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