SQL kumpara sa NoSQL – Alin ang dapat mong gamitin para sa iyong Susunod na Proyekto?

Isa sa mga madalas na itanong – anong database ang dapat kong gamitin …


Ang SQL ay nakatayo para sa Structured Query Language. Una itong binuo noong 1970s ng isang koponan ng mga mananaliksik ng IBM, ang mga database ng NoSQL, sa kabilang banda, ay unang ginamit noong 1998 ni Carlo Strozzi.

Ang pinaka-karaniwang pagkakaiba sa pagitan ng dalawang mga database (DB) system ay ang SQL ay may kaugnayan at ang NoSQL ay hindi nakakaugnay.

Malalim na sumisid sa dalawang database na ito upang mas mahusay na ipagbigay-alam ang iyong desisyon kapag susunod mong isasaalang-alang ang isang database para sa iyong proyekto.

Istraktura ng Database

Pag-usapan natin ang tungkol sa pagbubuo.

SQL

SQL ang database ay may isang tiyak na istraktura ng schema.

Ang isang schema ay naglalaman ng mga talahanayan, at ang bawat talahanayan ay naglalaman ng isang tiyak na bilang ng mga haligi. Nangangahulugan ito na hindi mai-update ng isang gumagamit ang talahanayan na lampas sa bilang ng mga haligi na tinukoy sa talahanayan. Ito ay kapaki-pakinabang lalo na kung kailangan mong mapanatili ang integridad ng data at tiyaking tiyakin din ang uri ng data na mai-save sa iyong database.

Ang bawat talahanayan sa isang database ng SQL ay maaaring nauugnay. i.e., Maaari kang magkaroon ng mga relasyon sa pagitan ng mga talahanayan. Ang mga ugnayang ito ay maaaring Isa sa Marami, Marami sa Marami o Isa sa Isa. Ang uri ng relasyon na iyong ipinatupad ay nakasalalay sa iyong hinihiling.

Halimbawa, isaalang-alang natin ang sitwasyon ng hypothetical; mayroon kaming isang kumpanya na may mga gumagamit, at ang mga gumagamit ay maaaring gumawa ng mga order para sa mga produkto. Pagkatapos, maaari naming magpasya na ang mga gumagamit ay maaaring lumikha ng maraming mga order, ngunit ang bawat order ay maaari lamang nilikha ng isang gumagamit. Ito ay magiging isa sa maraming mga relasyon, i.e., isang gumagamit sa maraming mga order. Samakatuwid, ang istraktura ng talahanayan para sa parehong mga talahanayan ay magmukhang katulad sa ibaba.

Sa aming DB maaari kaming magkaroon ng isang talahanayan ng mga gumagamit, nakabalangkas tulad ng sa ibaba,

user_table
—————————————————-
id | pangalan | email
—————————————————–
1 Idris [protektado ng email]

Gayundin, maaari kaming magkaroon ng isang talahanayan ng order

order_table
———————————————————————————
id | user_id | numero ng order
———————————————————————————
1 1 20000001

Ang user_id sa talahanayan ng mga order, ginagawang madali upang mai-map ang bawat order sa talahanayan ng mga order sa gumagamit na kinabibilangan nito. Sa kaso ng isang relasyon sa Isa hanggang Isang, maaari tayong magkaroon ng order_id din sa mga gumagamit_tayo kung magpasya kaming makuha ang gumagamit sa pamamagitan ng mga kaugnay na id ng order.

Para sa, Maraming sa Maraming mga sitwasyon, isang dagdag na talahanayan, na tinatawag na isang talahanayan ng Pivot, ay karaniwang kasangkot. Pinapayagan nito ang maraming mga tala na ma-map sa bawat isa. Gamit ang halimbawa sa itaas. Gusto namin,

user_table
————————————————————————————-
id | pangalan | email
————————————————————————————-
1 Idris [protektado ng email]

at ang order table ay

order_table
———————————————————
id | numero ng order
———————————————————
1 2000001

at pagkatapos ang talahanayan ng Pivot ay hahawakan ang parehong mga ID bilang mga dayuhang susi.

gumagamit_order_table
——————————————————————————
id | order_id | user_id
——————————————————————————
1 1 1

Batay sa istrukturang ito na ibinigay ng SQL, maaari mong komportable na isulat ang Sumali sa pagitan ng mga talahanayan na magbibigay ng data mula sa iba’t ibang mga talahanayan na sumama sa isang query.

NoSQL

NoSQL ang mga database ay itinayo upang maging mas nababaluktot kaysa sa SQL DB, na naglalaman din ng mas malaking halaga ng data.

Sa NoSQL DB, walang paunang natukoy na schema o mga talahanayan. Mayroong Mga Koleksyon, at sa bawat Koleksyon, mayroong mga Dokumento. Pinapayagan ka nitong mag-save ng data sa iba’t ibang mga form sa pagdating nila. Maaari kang pumili na magkaroon ng maraming iba’t ibang mga dokumento na may iba’t ibang mga patlang sa isang Koleksyon. Posible rin na manu-manong magtamo ng mga relasyon sa pagitan ng Mga Koleksyon. Gayunpaman, ang mga ito ay hindi angkop para sa naturang layunin. Sa halip, mai-save mo ang lahat na kinakailangan para sa isang solong query sa parehong Koleksyon.

Kung ikaw ay isang taong SQL, maaari mong isipin ang mga Koleksyon bilang mga talahanayan at Dokumento bilang mga hilera kasama ang mga talahanayan. Gayunpaman, walang mga paghihigpit sa mga haligi ng data na maaari mong idagdag sa talahanayan.

Bumalik sa aming naunang tinukoy na hypothetical na halimbawa ng isang kumpanya na may mga gumagamit at mga order.

Ang isang Koleksyon ng Mga Gumagamit ay maaaring tinukoy bilang,

{id: 1, pangalan: ‘idris’, email: ‘[protektado ng email]‘}

At ang Order Collection ay maaaring tinukoy bilang,

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

Gayunpaman, sa kasong ito, nais naming iwasan ang manu-mano na sumali sa parehong Mga Koleksyon (na hindi namin dapat, sa kasong ito). Maaari naming i-save ang mga entry sa Koleksyon na mas nakababasa. Napagpasyahan ko (para sa halimbawang ito) na magiging koleksyon ng Mga Order.

{id: 1, order_number: 200001, user {id: 1, pangalan: ‘idris’, email: ‘[protektado ng email]‘}}

Sa kasong ito, hindi na namin kailangang magbasa mula sa Koleksiyon ng Mga Gumagamit at basahin lamang mula sa Order Collection, na naglalaman ngayon ng lahat ng data na kailangan namin.

Isang mahalagang bagay na dapat tandaan dito: Kung nagtatayo ka ng isang app na maraming nabasa kaysa sumulat, ang isang opsyon sa NoSQL ay malamang na mas angkop para sa iyo. Dahil maaari mong mai-save ang lahat ng iyong data sa parehong koleksyon, at maaari mong basahin mula sa mapagkukunang iyon nang kumportable upang makuha ang lahat ng kinakailangang data.

Gayunpaman, para sa isang application na nangangailangan ng maraming magsusulat (tinatayang 10,000 nagsusulat bawat segundo), hindi magandang ideya na magkaroon ng opsyon na NoSQL kung saan kailangan mong sumulat ng parehong data sa maraming lokasyon. Sa sitwasyong ito, ang isang pagpipilian ng SQL ay malamang na mas angkop, kung saan mayroon kang mga relasyon na mayroon sa lahat ng mga talahanayan, at ang parehong data ay hindi kailangang isulat sa maraming lokasyon nang paulit-ulit, ang pag-update ng data sa isang lokasyon ay maaaring magamit sa iba pang mga talahanayan sa pamamagitan ng paglabas relasyon. Ito, siyempre, ay hindi nangangahulugan na ang bawat isa sa mga database ay hindi makayanan ang sukat.

Pag-scale

Tingnan natin kung paano gumagana ang scaling.

SQL

Ang SQL DB ay hindi maaaring mai-scale nang pahalang ngunit patayo lamang. Ano ang ibig sabihin nito?

Ang horizontally scaling ay nangangahulugan ng paghahati ng data mula sa isang DB sa maraming mga database upang mapagaan ang pagkarga. Ang data ng SQL ay maaaring, gayunpaman, ay hindi mahati sa hiwalay na mga DB dahil sa mahigpit na kalikasan. Ang wastong upang masukat ang isang SQL DB ay upang madagdagan ang CPU, Memory, at Disk space ng umiiral na DB server, at ito ang ibig sabihin upang masukat ito nang patayo.

pahalang na pag-scale

vertical scaling


NoSQL

Ang NoSQL DB ay maaaring mai-scale parehong pahalang at patayo. Ito ay dahil sa kakayahang umangkop sa pag-iimbak ng data nito. Samakatuwid, pinapayagan nito ang data nito na mahati sa maraming mga database, tulad ng kaso sa pahalang na pag-scale. Maaari rin itong mai-scale nang patayo kung kinakailangan.

Isang mahalagang bagay na dapat tandaan dito: Pagdating sa pag-scale, ang parehong SQL at NoSQL Databases ay maaaring epektibo na mai-scale. Gayunpaman, para sa SQL DBs, ang vertical scaling ay maaaring maging isang limitasyon; ang isang solong server ng DB ay magkakaroon ng limitasyon sa dami ng kapangyarihan ng computing na maaari nitong dalhin.

Mahalagang tandaan dito, na para sa karamihan ng mga application na iyong itatayo ay maaaring hindi mo matumbok ang maximum ng kakayahan ng computing ng iyong server, ngunit kapaki-pakinabang na tandaan ito. Gayunpaman, para sa malalaking aplikasyon ng negosyo na nagpapatupad ng SQL, isang tanyag na pagpipilian upang matalo ang limitasyong ito ay sa pamamagitan ng Sharding.

Ano ang Sharding?

Ang pagbabahagi ay ang proseso ng paghiwa sa malalaking mga talahanayan sa mga maliliit na chunks, na tinutukoy bilang mga shards. Ang pag-iisa ay maaaring gawin sa pamamagitan ng pahalang na pagkahati sa isang database. Hindi ito malilito sa Horizontal at Vertical Scaling. Ang horisontal na pagkahati ay tumutukoy sa proseso ng pag-iimbak ng mga hilera ng isang talahanayan sa maraming mga database node. Ang Vertical partitioning, sa kabilang banda, ay nangangailangan ng pag-save ng mga haligi ng isang talahanayan sa iba’t ibang mga node. Pinapayagan nito ang database na masukat ang epektibo at mapalakas ang pagganap.

Mga Halimbawa ng Database

SQL

  • MySQL – Isang napaka-tanyag na open-source database. Madaling ang database ng pagpipilian para sa maraming mga developer ng PHP, gayunpaman, ay maaari ring magamit sa Node.js, C #, C ++, Java, Perl, Ruby, at Python.
  • MSSQL – Nagbibigay ang Microsoft SQL ng maraming katatagan dahil ang pag-unlad nito ay direkta mula sa Microsoft, na nag-aalok din ng ilang suporta sa mga tuntunin ng pagbawi ng sakuna.
  • MariaDB – Itinayo ito sa MySQL ng mga gumagawa ng MySQL, na nagnanais na panatilihin ang MariaDB bilang isang libreng bersyon magpakailanman.
  • PostgresSQL – Isang sikat na database ng open-source. Ipinagmamalaki ang sarili bilang pinakamataas na bukas na database ng mapagkukunan ng mundo
  • Oracle – Karaniwan itong iniakma sa mga solusyon sa negosyo ng Oracle na may ilang mga limitasyon sa libreng bersyon nito.

NoSQL

  • MongoDB – Marahil ang pinaka kilalang NoSQL DB, pangkaraniwan sa mga developer ng application na nagtatrabaho sa MERN stack (MongoDB, Express, React, Node) o MEAN stack (MongoDB, Express, Angular, Node).
  • Ang Firebase – Ipinakilala noong 2011 at nakuha ng Google noong 2014, ay malawakang ginagamit ng mga developer ng web at mobile application.
  • Apache Couch DB – Isang dokumento na nakabase sa dokumento na NoSQL DB na nag-iimbak ng data bilang JSON.
  • Redis: Ito ang NoSQL DB, marahil na kilalang kilala sa paggamit nito sa pag-iimbak ng data na may opsyonal na oras upang mabuhay. Kilala rin ito sa bilis nito.

Konklusyon

Maaari kang lumikha ng anumang uri ng aplikasyon sa alinman sa isang database ng SQL o NoSQL. Ito ay depende sa iyong mga kinakailangan. Kung isinasaalang-alang mo ang isang database kung saan mayroon kang higit pang mga pagbabasa at mas kakaunti ang nagsusulat, ang isang NoSQL ay maaaring maging isang mahusay na pagpipilian. Kung ikaw ay, gayunpaman, isinasaalang-alang ang pagbuo ng isang app na may higit na magsusulat kaysa sa pagbabasa, isang SQL ay maaaring maging mas mahusay na solusyon. Sa scalability, kapag nakakakuha ang iyong app sa napakalaking sukat, maaari mong tapusin ang paggamit ng parehong mga DB.

TAGS:

  • Database

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