SQL vs NoSQL – Čo by ste mali použiť pre svoj ďalší projekt?

Jedna z najčastejšie kladených otázok – akú databázu by som mal použiť …


SQL je skratka pre Structured Query Language. Prvýkrát bol vyvinutý v sedemdesiatych rokoch tímom výskumníkov IBM, no databázy NoSQL na druhej strane prvýkrát použil Carlo Strozzi v roku 1998..

Najbežnejším rozdielom medzi týmito dvoma databázovými systémami (DB) je, že SQL je relačný a NoSQL nie je relačný.

Poďme sa hlboko ponoriť do týchto dvoch databáz, aby sme lepšie informovali vaše rozhodnutie, keď sa chystáte uvažovať o databáze pre svoj projekt.

Štruktúra databázy

Poďme hovoriť o štruktúrovaní.

SQL

SQL databáza má definovanú štruktúru schémy.

Schéma obsahuje tabuľky a každá tabuľka obsahuje určitý počet stĺpcov. To znamená, že užívateľ nemôže aktualizovať tabuľku nad počet stĺpcov špecifikovaných v tabuľke. Toto je užitočné najmä vtedy, keď potrebujete zachovať integritu údajov a tiež zabezpečiť, aký druh údajov sa uloží do vašej databázy.

Každá tabuľka v databáze SQL môže súvisieť. To znamená, že medzi tabuľkami môžete mať vzťahy. Tieto vzťahy môžu byť jeden k mnohým, veľa k mnohým alebo jeden ku druhému. Typ vzťahu, ktorý implementujete, závisí od toho, čo požadujete.

Pozrime sa napríklad na hypotetickú situáciu; máme spoločnosť s používateľmi a používatelia môžu robiť objednávky produktov. Potom by sme sa mohli rozhodnúť, že používatelia môžu vytvoriť viac objednávok, ale každú objednávku môže vytvoriť iba jeden používateľ. Jednalo by sa o jeden až veľa vzťahov, t. J. Jeden užívateľ pre mnoho objednávok. Štruktúra tabuľky pre obe tabuľky bude preto vyzerať podobne ako nižšie.

V našej databáze by sme mohli mať tabuľku používateľov v nasledujúcom členení,

users_table
—————————————————-
id | názov e-mail
—————————————————–
1 Idris [Email protected]

Tiež by sme mohli mať tabuľku objednávok

orders_table
———————————————————————————
id | user_id | číslo objednávky
———————————————————————————
1 1 20000001

User_id v tabuľke objednávok uľahčuje mapovanie každej objednávky v tabuľke objednávok na používateľa, do ktorého patrí. V prípade osobného vzťahu by sme mohli mať order_id aj na users_table, ak sa rozhodneme získať používateľa pomocou jeho súvisiaceho id objednávky.

V mnohých situáciách sa zvyčajne používa tabuľka navyše, ktorá sa nazýva kontingenčná tabuľka. To umožňuje mapovanie viacerých záznamov k sebe. Pomocou vyššie uvedenej inštancie. Mali by sme,

users_table
————————————————————————————-
id | názov e-mail
————————————————————————————-
1 Idris [Email protected]

a tabuľka objednávok bude

orders_table
———————————————————
id | číslo objednávky
———————————————————
1 2000001

a potom kontingenčná tabuľka bude držať obe ID ako cudzie kľúče.

users_orders_table
——————————————————————————
id | order_id | ID používateľa
——————————————————————————
1 1 1

Na základe tejto štruktúry poskytovanej SQL môžete pohodlne zapisovať spojenia medzi tabuľkami, ktoré poskytnú údaje z rôznych tabuliek spojených do jedného dotazu..

NoSQL

NoSQL databázy boli zostavené tak, aby boli flexibilnejšie ako databázy SQL, aby obsahovali aj väčšie množstvo údajov.

V databázach NoSQL neexistuje preddefinovaná schéma alebo tabuľky. Existujú zbierky av každej zbierky sú dokumenty. To vám umožní ukladať dáta v rôznych formách hneď, ako budú k dispozícii. Môžete si vybrať, či budete mať v jednej zbierke viacero rôznych dokumentov s rôznymi poliami. Je tiež možné manuálne vytvárať vzťahy medzi zbierkami. Na tento účel však nie sú vhodné. Namiesto toho by ste mohli uložiť všetko potrebné na jeden dotaz do tej istej kolekcie.

Ak ste osoba SQL, môžete považovať kolekcie ako tabuľky a dokumenty za riadky s tabuľkami. Neexistujú však žiadne obmedzenia pre stĺpce údajov, ktoré môžete pridať do tabuľky.

Vráťte sa k našej predchádzajúcej hypotetickej inštancii spoločnosti s používateľmi a objednávkami.

Zbierka používateľov sa dá definovať ako,

{id: 1, name: ‘idris’, email: ‘[Email protected],}

Zbierka objednávok by sa dala definovať ako,

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

V tomto prípade sa však chceme vyhnúť tomu, aby sme sa nemuseli manuálne pripojiť k obom zbierkam (čo by sme v tomto prípade nemali). Môžeme uložiť záznamy do zbierky, ktorá získa najviac prečítané. Rozhodol som sa (pre tento príklad) to bude Zbierka objednávok.

{id: 1, order_number: 200001, user {id: 1, name: ‘idris’, email: ‘[Email protected],}}

V tomto prípade už nemusíme čítať zo zbierky používateľov a iba zo zbierky objednávok, ktorá teraz obsahuje všetky potrebné údaje..

Kľúčová vec, ktorú treba poznamenať: Ak vytvárate aplikáciu, ktorá dokáže čítať viac ako písať, pre vás je pravdepodobne vhodnejšia možnosť NoSQL. Pretože by ste mohli mať všetky svoje údaje uložené v tej istej kolekcii a z tohto zdroja by ste mohli pohodlne prečítať všetky potrebné údaje.

Pre aplikáciu, ktorá vyžaduje veľa zápisov (približne 10 000 zápisov za sekundu) v tomto rozsahu, však nie je dobré mať k dispozícii voľbu NoSQL, kde musíte zapisovať rovnaké údaje do viacerých umiestnení. V tejto situácii je pravdepodobne vhodnejšia voľba SQL, keď máte vzťahy ku všetkým tabuľkám a rovnaké údaje sa nemusia zapisovať opakovane do viacerých umiestnení. Aktualizácia údajov na jednom mieste môže byť k dispozícii do iných tabuliek prostredníctvom ukončenia. vzťah. To samozrejme neznamená, že každá z týchto databáz nedokáže zvládnuť meradlo.

škálovanie

Pozrime sa, ako funguje škálovanie.

SQL

SQL DB nemožno škálovať horizontálne, ale iba vertikálne. Čo to dokonca znamená?

Horizontálne škálovanie znamená rozdelenie údajov z jednej databázy do viacerých databáz na uľahčenie zaťaženia. Údaje SQL však nemôžu byť kvôli svojej prísnej povahe rozdelené do samostatných databáz. Správnym spôsobom škálovania SQL DB je zväčšenie CPU, pamäte a diskového priestoru existujúceho DB servera a to je to, čo znamená vertikálne škálovanie.

horizontálne škálovanie

vertikálne škálovanie


NoSQL

NoSQL DB možno škálovať horizontálne aj vertikálne. Je to kvôli flexibilite pri ukladaní údajov. To umožňuje rozdelenie jeho údajov na viac databáz, ako je to v prípade horizontálneho škálovania. Ak je to potrebné, môže byť tiež upravená vertikálne.

Kľúčová vec, ktorú treba poznamenať: Pokiaľ ide o škálovanie, je možné efektívne škálovať databázy SQL aj NoSQL. Pre SQL DB však môže byť vertikálne škálovanie obmedzením; jeden DB server bude mať obmedzenie množstva výpočtového výkonu, ktorý dokáže uniesť.

Je tiež dôležité si uvedomiť, že pre väčšinu aplikácií, ktoré zostavíte, nemusíte zasiahnuť maximum výpočtovej schopnosti servera, ale je potrebné mať na pamäti. Avšak pre aplikácie veľkých firiem implementujúce SQL je populárnou možnosťou prekonať toto obmedzenie Sharding.

Čo je Sharding?

Sharding je proces rozdelenia veľkých stolov na malé kúsky, ktoré sa označujú ako črepy. Sharding je možné vykonať horizontálnym rozdelením databázy. Toto sa nesmie zamieňať s horizontálnym a vertikálnym meraním. Horizontálne rozdelenie sa týka procesu ukladania riadkov tabuľky do viacerých uzlov databázy. Na druhej strane zvislé rozdelenie vyžaduje uloženie stĺpcov tabuľky na rôzne uzly. To umožňuje databáze efektívne škálovať a zvyšovať výkon.

Príklady databázy

SQL

  • MySQL – veľmi populárna open-source databáza. Databázu výberu pre mnohých vývojárov PHP však možno ľahko použiť aj s Node.js, C #, C ++, Java, Perl, Ruby a Python..
  • MSSQL – Microsoft SQL poskytuje veľa stability, pretože jeho vývoj je priamo od spoločnosti Microsoft, ktorý tiež ponúka určitú podporu v oblasti obnovy po katastrofe..
  • MariaDB – Toto bolo postavené na MySQL tvorcami MySQL so zámerom udržať MariaDB ako bezplatnú navždy verziu.
  • PostgresSQL – veľmi populárna open-source databáza. Pýcha sa stáva najvyspelejšou databázou s otvoreným zdrojovým kódom na svete
  • Oracle – Zvyčajne je prispôsobený podnikovým riešeniam Oracle s obmedzeniami jeho bezplatnej verzie.

NoSQL

  • MongoDB – pravdepodobne najznámejší NoSQL DB, bežný medzi vývojármi aplikácií, ktorí pracujú s MERN stackom (MongoDB, Express, React, Node) alebo MEAN stack (MongoDB, Express, Angular, Node).
  • Firebase – predstavený v roku 2011 a získaný spoločnosťou Google v roku 2014, je široko používaný vývojármi webových a mobilných aplikácií.
  • Apache Couch DB – dokument NoSQL DB založený na dokumente, ktorý ukladá dáta ako JSON.
  • Redis: Toto je NoSQL DB, pravdepodobne najznámejšie pre jej použitie pri ukladaní údajov s voliteľným časom pre život. Je tiež známy svojou rýchlosťou.

záver

Môžete vytvoriť akýkoľvek druh aplikácie s databázou SQL alebo NoSQL. Závisí to od vašich požiadaviek. Ak uvažujete o databáze, kde máte viac čítaní a menej zápisov, NoSQL môže byť dobrou voľbou. Ak však uvažujete o vytvorení aplikácie s väčším počtom zápisov ako čítaním, môže byť tým lepším riešením SQL. Ak sa vaša aplikácia prispôsobí veľkému rozsahu, môžete skončiť pomocou oboch databáz.

Tagy:

  • databázy

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