Relasyonal vs NoSQL na mga Database: Paano Pumili ng Tamang Pundasyon para sa Iyong Sistema

Ang bawat database ay nag-iimbak ng datos. Doon nagtatapos ang pagkakatulad. Ang mga relational database at NoSQL database ay kumakatawan sa magkaibang pilosopiya tungkol sa kung paano dapat istruktura, iimbak, at tanungin ang datos — at ang mga pagkakaibang iyon ay umaapekto sa bawat antas ng mga sistemang itinayo sa ibabaw nila.

Hindi ito tanong ng luma laban sa bago, o simple laban sa sopistikado. Ang parehong kategorya ay naglalaman ng mga hinog at nasubok na sistema na ginagamit sa pambihirang saklaw. Ang tanong ay kung ito ba ay angkop sa layunin: aling modelo ang akma sa hugis ng iyong data, sa mga pattern ng pag-access ng iyong aplikasyon, at sa mga garantiya ng konsistensya na kailangan ng iyong mga gumagamit.

Ano nga ba talaga ang isang relational database

Iniaayos ng isang relational database ang datos sa mga talahanayan — mga hanay at kolum na may tahasang itinakdang ugnayan sa pagitan nila. Ang "relational" sa pangalan ay hindi tumutukoy sa katotohanang magkakaugnay ang mga talahanayan (bagaman ganoon nga), kundi sa matematikal na konsepto ng isang relasyon: isang hanay ng mga tuple na may magkakaparehong katangian. Ang teoretikal na pundasyong ito, na binuo ni Edgar Codd sa IBM noong 1970, ay napatunayang napakatibay.

Ang mga pangunahing katangian ng isang relational database ay:

Isang nakapirming iskema. Bago ka maglagay ng datos, tinutukoy mo muna ang istruktura: kung aling mga talahanayan ang umiiral, kung aling mga haligi ang mayroon sa bawat talahanayan, anong uri ng datos ang tinatanggap ng bawat haligi, at kung aling mga limitasyon ang ipinapataw (NOT NULL, UNIQUE, CHECK, at iba pa). Ang iskema ang kontrata sa pagitan ng iyong aplikasyon at ng iyong database.

Normalisation. Inaayos ang datos upang alisin ang pag-uulit. Ang pangalan ng kostumer ay lumalabas nang isang beses, sa table ng mga kostumer. Bawat order ay tinutukoy ang kostumer na iyon gamit ang ID. Kung magbabago ang pangalan, magbabago ito sa isang lugar lamang. Hindi lang ito pag-aayos — ito ay isang garantiya ng pagkakapare-pareho.

ACID na mga transaksyon. Atomicity, Consistency, Isolation, at Durability. Ang isang transaksyon ay kumukumpleto nang buo o hindi talaga. Kung maglilipat ka ng pera mula sa isang account papunta sa isa pa, sabay na nangyayari ang debit at credit o wala nang nangyayari. Pinapatupad ito ng database sa antas ng engine.

SQL. Ang Structured Query Language ang unibersal na interface para sa mga relational database. Ito ay deklaratibo — inilalarawan mo kung ano ang gusto mo, hindi kung paano ito makukuha — at napaka-ekspresibo nito. Pagsasanib, agregasyon, mga window function, subquery, CTE: ang buong saklaw ng SQL ay nagbibigay sa iyo ng mga kasangkapan upang magtanong ng mga kumplikadong katanungan sa iyong data nang hindi nagsusulat ng code ng aplikasyon para gawin ang trabaho.

Ang mga pangunahing relational database — PostgreSQL, MySQL, SQL Server, Oracle — ay mayroon silang mga katangiang ito habang nagkakaiba sa kanilang mga partikular na hanay ng tampok, katangian ng pagganap, at mga modelo ng lisensya. Ang PostgreSQL sa partikular ay naging karaniwang pagpipilian para sa mga bagong proyekto, na pinagsasama ang mahigpit na pagsunod sa pamantayan sa isang pambihirang hanay ng tampok.

Ano nga ba talaga ang isang NoSQL database

Ang "NoSQL" ay isang pangkalahatang termino na sumasaklaw sa ilang magkakaibang kategorya ng database, na pinagbubuklod pangunahin ng kung ano ang hindi nila: hindi sila relational, at hindi nila ginagamit ang SQL bilang kanilang pangunahing interface (bagaman ang ilan ay sumusuporta sa mga query language na kahawig ng SQL). Mas mainam na maunawaan ang termino bilang "hindi lamang SQL" — isang pagkilala na ang relational model ay hindi ang nag-iisang wastong pamamaraan.

Ang mga pangunahing kategorya ng NoSQL ay:

Ang mga document database ay nag-iimbak ng data bilang mga dokumento — karaniwang JSON o BSON — kung saan ang bawat dokumento ay maaaring magkaroon ng iba't ibang estruktura. Ang MongoDB ang pinakamalawak na ginagamit; ang iba ay kinabibilangan ng CouchDB at Firestore. Walang mga talahanayan at walang nakapirming schema; ang isang "collection" ng mga dokumento ay maaaring maglaman ng mga talaan na may ganap na magkakaibang mga patlang.

Ang mga key-value store ang pinakasimpleng modelo: bawat talaan ay isang halaga na naa-address gamit ang isang natatanging susi. Ang Redis ang nangungunang halimbawa, na malawakang ginagamit para sa caching, session storage, at real-time leaderboards. Ang DynamoDB ay pangunahing gumagana rin bilang key-value store, na may mga kakayahan sa dokumento na nakapatong dito.

Ang mga imbakan ng pamilya ng haligi ay inaayos ang data ayon sa haligi sa halip na sa hanay, na nagpapahintulot ng napakaepektibong pagbasa ng mga partikular na haligi sa milyun-milyong hanay. Ang Apache Cassandra at HBase ang mga pangunahing halimbawa. Ang modelong ito ay idinisenyo para sa mga mabigat sa pagsusulat, mataas na dami ng workload kung saan ang mga pattern ng query ay alam na nang maaga.

Graph databases ay nagmomodelo ng data bilang mga node at edge — mga entidad at ang mga relasyon sa pagitan nila. Ang Neo4j ang nangungunang halimbawa. Kapag ang mga relasyon sa pagitan ng mga entidad ang pangunahing paksa ng iyong mga query — mga social network, mga engine ng rekomendasyon, pagtuklas ng pandaraya — ang mga graph database ay maaaring ipahayag ang mga naturang query nang natural sa mga paraang mangangailangan ng malalim na recursive na SQL.

Ang mga database na time-series ay na-optimize para sa datos na naka-index ayon sa oras: InfluxDB, TimescaleDB, Prometheus. Mga babasahin mula sa sensor, mga paggalaw sa pananalapi, mga sukatan ng aplikasyon — datos kung saan ang timestamp ay palaging pangunahing susi at ang mga range query sa paglipas ng panahon ang nangingibabaw na pattern ng pag-access.

Ang istrukturang pagkakaiba na siyang nagtutulak sa lahat ng iba pa

Ang pinakamalalim na pagkakaiba sa pagitan ng relational at NoSQL na mga database ay hindi ang sintaksis o sukat — ito ay ang ugnayan sa pagitan ng estruktura ng datos at ng kakayahang mag-query.

Ang mga relational database ay nagbibigay sa iyo ng pinakamataas na kakayahang mag-query kapalit ng maagang disiplina sa schema. Dahil ang datos ay na-normalisa at na-type, maaari mong itanong halos anumang tanong dito sa oras ng pag-query. Maaari mong pagsamahin ang mga talahanayan sa mga paraang hindi mo inasahan nang dinisenyo mo ang schema. Maaari kang mag-aggregate sa mga dimensyon na idinagdag mo ilang buwan matapos ang paunang disenyo. Kinokontrol ng schema ang data, ngunit ang wika ng query ay nagbibigay sa iyo ng kalayaan.

Ang mga NoSQL database ay nag-aalok ng kabaligtaran na kapalit. Binibigyan ka nila ng kakayahang umangkop sa kung paano mo istruktura at isulat ang data, kapalit ng mas limitado na mga pattern ng query. Pinapayagan ka ng isang document database na mag-imbak ng anumang hugis ng data nang hindi nangangailangan ng migration. Ngunit ang mahusay na pag-query sa iba't ibang dokumento ay nangangailangan ng kaalaman sa iyong mga pattern ng pag-access nang maaga at pagdidisenyo ng iyong istruktura ng data batay rito.

Ito ang pangunahing tensyon: pagiging flexible ng schema vs. pagiging flexible ng query. Maaari mong magkaroon ng pareho, ngunit hanggang sa isang punto lamang. Ang modelong database na pipiliin mo ay sumasalamin kung aling trade-off ang mas katanggap-tanggap para sa iyong use case.

Ang Teorema ng CAP at kung bakit ito mahalaga

Ang mga distributed system ay hindi maaaring sabay na garantiyahan ang Consistency, Availability, at Partition Tolerance — makakamit nila ang dalawa sa tatlo lamang. Ito ang Teorema ng CAP, at ito ang teoretikal na pundasyon para maunawaan kung bakit magkaiba ang pag-uugali ng mga relational at NoSQL database sa ilalim ng mga kondisyon ng pagkabigo.

Tradisyonal na inuuna ng mga relational database ang Consistency at Partition Tolerance. Bawat pagbasa ay sumasalamin sa pinakabagong pagsusulat. Kung magkakaroon ng paghahati ng network at hindi matiyak ng database ang consistency, tatanggihan nitong magbigay ng luma (stale) na datos — nagiging hindi magagamit (unavailable) ito kaysa maging mali.

Maraming NoSQL database — lalo na ang mga dinisenyo para sa pahalang na distribusyon tulad ng Cassandra at DynamoDB — ay inuuna ang Availability at Partition Tolerance. Magbibigay sila ng data kahit na may network partition, at tinatanggap nilang ang ilang pagbasa ay maaaring magbalik ng lipas na halaga. Ito ang tinatawag na "eventual consistency": sa huli, magkakasundo rin ang lahat ng node sa iisang halaga, ngunit may isang yugto kung kailan hindi sila magkakasundo.

Ang praktikal na implikasyon: kung hindi kayang tiisin ng iyong aplikasyon na makakuha ng lumang datos — halimbawa, balanse sa bangko, bilang ng imbentaryo, talaang medikal — kailangan mo ng matatag na pagkakapare-pareho (strong consistency). Kung kayang tiisin ng iyong aplikasyon ang panandaliang hindi pagkakatugma kapalit ng palaging pagiging available — isang feed sa social media, isang katalogo ng produkto, isang profile ng gumagamit — katanggap-tanggap ang eventual consistency at nagbibigay ito sa iyo ng kalayaan sa arkitektura.

Mga halimbawa sa totoong buhay: kung kailan ang tamang pagpili ang naging pagkakaiba

GitHub: PostgreSQL sa sentro ng isang pandaigdigang plataporma

Pinapatakbo ng GitHub ang isa sa pinakamalalaking plataporma para sa pakikipagtulungan sa software sa buong mundo gamit ang PostgreSQL — milyun-milyong repositoryo, bilyun-bilyong kaganapan, at masalimuot na relational na query sa pagitan ng mga gumagamit, organisasyon, repositoryo, pull request, isyu, at komento. Ang modelong relasyonal ay akma sa larangan: ang mga ugnayan sa pagitan ng mga entidad na ito ang produkto. Ang isang pull request ay kabilang sa isang repository, ginawa ng isang user, nire-review ng ibang mga user, nagsasara ng mga isyu, at nagpapagana ng mga CI pipeline.

Sa loob ng maraming taon, pinatakbo ng GitHub ang isang pangunahing PostgreSQL instance na may mga read replica. Habang lumalaki ang saklaw, ipinakilala nila ang Vitess (isang MySQL sharding layer para sa ilang workloads) at ProxySQL para sa pamamahala ng koneksyon — ngunit nanatili ang relasyonal na sentro. Ang aral ay hindi na ang PostgreSQL ay lumalawak nang walang hanggan nang hindi nagsusumikap. Kundi, ang relasyonal na modelo ang angkop para sa isang larangang tinutukoy ng mga relasyon, at sulit ang pagsisikap na inilaan sa pagpapalawak nito dahil mas magastos sana ang paglipat sa ibang modelo ng datos.

Twitter: ang masakit na migrasyon mula sa MySQL patungo sa isang halo-halong arkitektura

Nagsimula ang Twitter sa MySQL at hinarap ang isang kilalang krisis sa pag-scale nang lumampas ang paglago ng mga gumagamit sa kayang pagseserbisyo ng isang solong relational database. Ang pangunahing problema ay ang social graph — ang mga relasyon ng tagasunod/sinusundan sa pagitan ng daan-daang milyong mga gumagamit — at ang problema sa timeline fanout: kapag ang isang gumagamit na may 10 milyong tagasunod ay nag-tweet, kailangang lumabas ang tweet na iyon sa 10 milyong timeline nang halos agarang.

Ang relational model, ayon sa pagpapatupad ng Twitter, ay hindi makasabay sa write fanout na ito sa kinakailangang bilis. Inilipat ng Twitter ang social graph sa isang pasadyang in-memory store at kalaunan ay ginamit ang Manhattan (ang kanilang panloob na distributed key-value store) para sa timelines at ang Cassandra para sa iba pang high-write workloads.

Masalimuot ang aral dito. Ang pangunahing datos ng Twitter — mga tweet, mga user, mga relasyon — ay batay sa ugnayan. Hindi ang data model ang problema; kundi ang dami ng pagsusulat at ang pagpapalaganap nito sa saklaw na nangangailangan ng distribusyon. Magastos ang migrasyon, teknikal na kumplikado, at nangailangan ng maraming taon ng pamumuhunan sa engineering. Sa saklaw ng Twitter, tama ang naging desisyon. Sa saklaw ng halos anumang ibang aplikasyon, maaga pa iyon.

MongoDB: isang babala tungkol sa kakayahang umangkop ng schema

Noong unang bahagi ng 2010s, habang mabilis na tumanyag ang MongoDB, maraming koponan ang nag-ampon nito pangunahin dahil sa kakayahang umangkop ng schema nito — ang kakayahang magsimulang mag-imbak ng data nang hindi muna nagde-define ng schema. Para sa prototyping at maagang yugto ng pag-develop, tunay na pina-bilis nito ang iteration.

Lumitaw ang mga problema habang nagiging mas matatag ang mga sistema. Kung walang pagpapatupad ng schema, unti-unting naipon ang hindi pagkakatugma ng datos. Minsan ay wala ang mga field na dapat sana ay kinakailangan. Minsan, ang mga halaga na dapat sana ay integer ay string. Ang mga query na nagpapalagay ng pare-parehong istruktura ay nagbabalik ng hindi inaasahang resulta. Napilitan ang mga koponan na magsulat ng malawakang pagpapatunay sa antas ng aplikasyon na sana ay awtomatikong ipinatupad na ng database.

Hindi ito pagkabigo ng MongoDB bilang isang database — ito ay angkop na kasangkapan para sa maraming gamit. Ito ay pagkabigo ng palagay na ang kakayahang magbago ng schema ay mabuti nang walang kondisyon. Inantala ng kakayahang magbago ang gastos sa pag-iisip tungkol sa estruktura ng datos; hindi nito inalis ang gastusing iyon. Ang mga koponang gumamit ng MongoDB nang walang disiplina ay napilitan na magpatupad ng mahina na bersyon ng isang relational schema sa code ng aplikasyon, nang walang mga garantiyang ibibigay sana ng isang relational database.

Amazon DynamoDB: isang kuwento ng tagumpay para sa tamang use case

Ang shopping cart ng Amazon ay isa sa mga pangunahing halimbawa ng tamang paggamit ng NoSQL. Malinaw ang mga kinakailangan: kailangang palaging magamit ang shopping cart (dapat palaging makapagdagdag ng mga item ang isang customer, kahit sa panahon ng isang pangrehiyong pagkabigo), kailangan nitong kayanin ang napakalaking dami ng pagsusulat (daan-daang milyong mga gumagamit na nagdaragdag at nag-aalis ng mga item), at simple at alam nang pauna ang pattern ng pag-access (laging sa pamamagitan ng customer ID).

Ang engineering team ng Amazon, sa papel noong 2007 na nagbigay-inspirasyon sa DynamoDB, ay inilarawan ang sinadyang pagpili ng eventual consistency para sa cart: kung sabay na nagdagdag ng mga item ang dalawang device sa panahon ng network partition, pareho silang mapapanatili kapag naayos na ang partition, kahit na nangangahulugan itong pansamantalang magpapakita ng bahagyang hindi magkakatugmang estado. Ang isang shopping cart na palaging maaaring sulatanan — kahit na kapalit nito ay panandaliang hindi pagkakatugma — ay mas mahalaga kaysa sa isang cart na kung minsan ay hindi magagamit.

Ang disenyo ng DynamoDB para sa paggamit na ito — simpleng pag-access ng key-value, kilalang mga pattern ng query, availability kaysa consistency — ang dahilan kung bakit ito mahusay. Ang mga aplikasyon na sinusubukang gamitin ang DynamoDB bilang isang pangkalahatang-gamit na relational database, na nagpapatakbo ng mga kumplikadong query sa iba't ibang entidad, ay karaniwang nahihirapan.

Airbnb: Elasticsearch para sa paghahanap, PostgreSQL para sa katotohanan

Ang paghahanap ng Airbnb — pag-filter ng mga listahan ayon sa lokasyon, petsa, presyo, pasilidad, at availability — ay isang query na walang relasyonal na database na kayang paglingkuran nang mahusay sa malawakang sukat. Ang kombinasyon ng heograpikong paghahanap, full-text matching, at kumplikadong multi-atributong pagsasala sa milyun-milyong listahan ay eksaktong use case na idinisenyo ang Elasticsearch.

Ginagamit ng Airbnb ang Elasticsearch bilang search layer habang pinananatili ang PostgreSQL bilang system of record. Kapag na-update ang isang listing, isinusulat ang pagbabago sa PostgreSQL (ang pinagkukunan ng katotohanan, na may buong garantiyang ACID) at pagkatapos ay ipinapadala nang asynchronous sa Elasticsearch (ang search index, na na-optimize para sa mga partikular na pattern ng query ng karanasan sa paghahanap).

Ito ay isang hinog na arkitektural na pattern: gamitin ang tamang database para sa bawat usapin, panatilihin ang isang malinaw na pinagkukunan ng katotohanan, at tanggapin ang kompleksidad sa operasyon ng pagpapanatiling magkakatugma ang maraming imbakan. Gumagana ito dahil malinaw ang mga hangganan at nauunawaan ang mga kompromiso.

Kailan pipili ng isang relational database

Ang isang relational database ang angkop na default para sa karamihan ng mga aplikasyon. Ang mga kaso kung saan ito ay malinaw na tamang pagpipilian:

May makabuluhang ugnayan ang iyong datos. Kung ang mga entidad sa iyong sistema ay magkakaugnay sa paraang mahalaga — mga gumagamit at ang kanilang mga post, mga order at ang mga item nito, mga proyekto at ang kanilang mga gawain — direktang kinakatawan ng relasyonal na modelo ang mga ugnayang iyon at hinahayaan kang mag-query sa mga ito nang mahusay.

Kailangan mo ng matibay na konsistensya. Mga transaksyong pinansyal, pamamahala ng imbentaryo, mga sistema ng pag-book, mga talaan sa pangangalagang pangkalusugan — anumang larangan kung saan ang maling pagbasa ay may totoong kahihinatnan ay nangangailangan ng mga garantiyang ACID. Ibinibigay ito ng isang relational database sa antas ng engine.

Hindi mo pa lubos na alam ang iyong mga pattern ng query. Kung kakailanganin ng iyong aplikasyon na sagutin ang mga tanong tungkol sa iyong data na hindi mo lubos na mahuhulaan sa oras ng pagdidisenyo, mahalaga ang kakayahang umangkop ng SQL. Ang kakayahang magsulat ng ad-hoc na query laban sa isang well-normalised na schema ay isang makabuluhang operational asset.

Alam ng iyong koponan ang SQL. Mukhang walang kuwenta ito pero hindi. Ang SQL ay isa sa mga teknikal na kasanayan na pinakamalawak na nauunawaan sa software engineering. Bawat developer na iyong kukunin ay marunong nito sa isang antas. Ang kaalamang pang-operasyon — kung paano magdagdag ng index, kung paano basahin ang query plan, kung paano pamahalaan ang mga backup — ay malawakang magagamit. Ang ecosystem ng mga kasangkapan ay hinog na.

Hindi ka sigurado sa kailangan mo. Kapag nag-aalinlangan, magsimula sa PostgreSQL. Mas madaling magpakilala ng isang espesyal na imbakan (specialised store) mamaya, kapag naintindihan mo na ang iyong aktwal na pattern ng pag-access, kaysa lumipat mula sa isang document store pabalik sa isang relational model kapag lumabas na mas istruktura pala ang iyong data kaysa sa inaakala mo.

Kailan pipili ng NoSQL

Ang NoSQL ang tamang pagpipilian kapag ang isang partikular na pangangailangan ay hindi matutugunan ng relational model nang hindi gumagamit ng labis na pagsisikap:

Ang dami ng isusulat na data ay higit sa kayang hawakan ng isang node. Kung kailangan ng iyong aplikasyon na magpatuloy sa daan-daang libong pagsusulat bawat segundo sa isang sistemang nakakalat sa iba't ibang lugar, kinakailangan ang pahalang na pagpapalawak sa maraming node. Ang mga column-family store tulad ng Cassandra ay dinisenyo para dito; ang mga relational database ay maaaring ikalat ngunit hindi ito ang kanilang likas na paraan.

Ang iyong data ay tunay na walang iskema o lubhang nagbabago. Isang katalogo ng produkto kung saan ang iba't ibang uri ng produkto ay may ganap na magkaibang mga katangian, isang CMS kung saan mabilis na nagbabago ang mga uri ng nilalaman, isang sistema ng pag-log kung saan ang mga iskema ng kaganapan ay tinutukoy ng mga panlabas na sistema — nakikinabang ang mga kasong ito sa imbakan ng dokumento kung saan hindi ipinapataw ng database ang istruktura.

Ang pangunahing pattern ng iyong pag-access ay key-value lookup sa napakalaking sukat. Mga session store, cache, real-time leaderboard, feature flag — mga workload kung saan palagi mong ina-access ang data gamit ang isang susi at hindi mo kailangang mag-join o mag-aggregate ay nakikinabang sa pagiging simple at pagganap ng isang key-value store.

Naghahabi ka ng graph. Kung ang iyong pangunahing mga query ay tungkol sa pagdaan sa mga relasyon — hanapin ang lahat ng kaibigan ng kaibigan, tukuyin ang pinakamaikling daan sa pagitan ng dalawang node, tuklasin ang mga paikot na pagdepende — mas natural na mailalahad ng isang graph database ang mga query na iyon at mas mahusay na maisasagawa kaysa sa recursive SQL.

Kailangan mo ng optimisasyon para sa time-series. Ang milyun-milyong pagbasa ng sensor, paggalaw ng pananalapi, o sukatan ng aplikasyon kada segundo, na may mga query na pangunahing nakatuon sa mga saklaw ng oras, ay mas mahusay na pinaglilingkuran ng isang database na dinisenyo para sa time-series kaysa sa isang relational store na may kolum na timestamp.

Ang realidad ng multi-database

Ang pinakamahalagang bagay na dapat maunawaan tungkol sa tanong na relational vs NoSQL ay hindi ito, sa karamihan ng mga mature na sistema, isang pagpipiliang alinman sa isa o sa isa pa. Ang mga sistemang malawak ang saklaw ay karaniwang gumagamit ng maraming database, na ang bawat isa ay pinili para sa partikular na workload na pinaglilingkuran nito.

PostgreSQL para sa system of record. Redis para sa session caching at rate limiting. Elasticsearch para sa full-text search. InfluxDB para sa application metrics. Ginagawa ng bawat database sa stack na ito ang pinakamagaling nitong gawain, at pinamamahalaan ng application layer ang pagkakatugma sa pagitan nila.

Totoo ang gastos sa pagpapatakbo ng kompleksidad na ito. Bawat karagdagang database ay isa pang sistema na dapat subaybayan, i-back up, palawakin, at unawain. Hindi biro ang disiplina sa inhinyeriya na kailangan upang panatilihing magkakatugma ang maraming imbakan — tulad ng paghawak sa mga senaryo ng pagkabigo kung saan nagtatagumpay ang pagsusulat sa PostgreSQL ngunit nabibigo ang kasunod na pag-update sa Elasticsearch.

Ang panimulang punto para sa halos bawat aplikasyon ay dapat isang solong relational database. Magdagdag ng mga espesyal na imbakan kapag ang isang tiyak at lubos na nauunawaan na pangangailangan ay hindi matutugunan nang wala ito. Ang maagang pag-iiba-iba ng database ay isang uri ng maagang optimisasyon: nagdaragdag ito ng komplikasyon bago mo pa maunawaan kung kinakailangan nga ba ang komplikasyong iyon.

Ang paggawa ng desisyon

Ang mga tanong na tunay na mahalaga kapag pumipili ng database:

Ano ang iyong mga kinakailangan sa konsistensiya? Kung ang sagot sa "ano ang mangyayari kung babasahin ng isang gumagamit ang lipas na datos" ay "isang seryosong problema," kailangan mo ng ACID. Kung ang sagot ay "medyo nakakainis pero katanggap-tanggap," mayroon kang mga pagpipilian.

Ano ang mga pattern ng query mo? Kung alam mong eksakto kung paano maa-access ang data mo at ang pattern ng pag-access ay simple at mataas ang dami, maaari mo itong i-optimize. Kung kumplikado ang mga pattern ng pag-access mo o hindi pa lubos na alam, mahalaga ang kakayahang umangkop ng SQL.

Gaano karami ang iyong isinusulat na datos? Para sa karamihan ng mga aplikasyon, ang isang maayos na na-tune na PostgreSQL instance sa makatwirang hardware ay kayang hawakan ang libu-libong isulat bawat segundo nang walang kahirap-hirap. Ang mga kaso kung kailan ito ay tunay na hindi sapat ay mas bihira kaysa sa ipinahiwatig ng hype ng NoSQL noong dekada 2010.

Ano ang hugis ng iyong datos? Ang lubos na magkakapareho at mahigpit na magkakaugnay na datos ay akma sa relasyonal na modelo. Ang lubos na magkakaiba at maluwag na magkakaugnay na datos ay maaaring mas akma sa modelong dokumento.

Ano ang alam ng iyong koponan? Mahalaga ang pamilyaridad sa operasyon. Ang isang koponang may malalim na kaalaman sa PostgreSQL ay makakabuo ng mas maaasahang sistema gamit ang PostgreSQL kaysa sa isang NoSQL database na kanilang pinag-aaralan, kahit na teoretikal na mas angkop ang NoSQL database.

Nakaligtas ang relasyonal na database sa limampung taon ng pagbabagong teknolohikal hindi dahil ito palagi ang pinakamahusay na kasangkapan, kundi dahil ito ay isang pambihirang magandang default — madaling baguhin, maaasahan, madaling unawain, at sinusuportahan ng dekada ng kaalamang pang-operasyon. Lumihis dito nang may layunin, na may malinaw na pag-unawa sa kung ano ang iyong nakukuha at kung ano ang iyong isinusuko.