Tur ir simtiem tehniski sarežģītu datu bāzu pārskatu, taču tie ne vienmēr sniedz skaidrus norādījumus par pirmo soli datu bāzes atlasē: izvēloties labāko vispārīgo veidu konkrētai lietojumprogrammai. Visas datu bāzes nav izveidotas vienādas. Katram no tiem ir specifiskas stiprās un vājās puses. Lai gan ir taisnība, ka pastāv risinājumi, lai iecienītā datu bāze darbotos lielākajai daļai projektu, šo triku izmantošana palielina nevajadzīgu sarežģītību.
Pirms apsverat konkrētu datu bāzi, veltiet laiku domāt par to, kāds veids vislabāk atbalstīs pašreizējo projektu. Jautājums ir dziļāks nekā “SQL vs NoSQL”. Lasiet tālāk, lai iepazītos ar visbiežāk sastopamajiem datu bāzes veidiem, katra relatīvajiem ieguvumiem un to, kā noteikt, kurš ir vispiemērotākais.
Relāciju datu bāzes pārvaldības sistēmas (Oracle, MySQL, MS Server, PostgreSQL)
1970. gados tika izveidotas relāciju datubāzes, lai apstrādātu pieaugošo datu plūsmu. Viņiem ir pamatota teorija, un tie ir ietekmējuši gandrīz katru mūsdienās izmantoto datu bāzu sistēmu.
Relāciju datu bāzēs datu kopas tiek glabātas kā “attiecības”: tabulas ar rindām un kolonnām, kur visa informācija tiek glabāta kā noteiktas šūnas vērtība. Dati RDBMS tiek pārvaldīti, izmantojot SQL. Lai gan ir dažādas ieviešanas iespējas, SQL ir standartizēts un nodrošina paredzamības un lietderības līmeni.
Pēc agrīna pārdevēju plūdiem mēģinājuši izmantot sistēmas popularitāti ar ne visai relatīviem produktiem, radītājs E.F. Codd izklāstīja noteikumu kopumu, kas jāievēro visām relāciju datu bāzu pārvaldības sistēmām. Codd 12 noteikumi ir saistīti ar stingru iekšējās struktūras protokolu ieviešanu, pārliecinoties, ka meklēšana droši atgriež pieprasītos datus, un novēršot strukturālas izmaiņas (vismaz lietotāju veiktās). Sistēma nodrošināja, ka relāciju datu bāzes ir konsekventas un uzticamas līdz šai dienai.
Stiprās puses
Relāciju datu bāzēs izcili tiek apstrādāti augsti strukturēti dati un tiek sniegts atbalsts ACID (atomitātes, konsekvences, izolācijas un izturības) darījumiem. Datus var viegli saglabāt un izgūt, izmantojot SQL vaicājumus. Struktūru var ātri palielināt, jo datu pievienošana, nemainot esošos datus, ir vienkārša.
RDBMS struktūrā ir iebūvēts ierobežojumu izveide tam, kādam noteiktam lietotāju tipam var piekļūt vai modificēt. Tāpēc relāciju datu bāzes ir labi piemērotas lietojumprogrammām, kurām nepieciešama daudzpakāpju piekļuve. Piemēram, klienti varēja apskatīt savus kontus, savukārt aģenti varēja gan skatīt, gan veikt nepieciešamās izmaiņas.
Vājās puses
Relāciju datu bāzu lielākais vājums ir to lielākās stiprības spogulis. Lai arī cik labi viņi strādā ar strukturētiem datiem, viņiem ir grūti ar nestrukturētiem datiem. RDBMS robežās ir grūti attēlot reālās pasaules vienības kontekstā. Dati “sagriezti” no tabulām ir jāpārveido lasāmākā veidā, un ātrumu var negatīvi ietekmēt. Fiksētā shēma arī nereaģē uz izmaiņām.
Izmaksas ir atlīdzība ar relāciju datu bāzēm. To uzstādīšana un augšana mēdz būt dārgāka. Horizontālā mērogošana vai mērogošana, pievienojot vairāk serveru, parasti ir gan ātrāka, gan ekonomiskāka nekā vertikālā mērogošana, kas ietver vairāk resursu pievienošanu serverim. Tomēr relāciju datu bāzu struktūra sarežģī procesu. Dalīšana (ja dati tiek horizontāli sadalīti un sadalīti mašīnu kolekcijā) ir nepieciešami, lai paplašinātu relāciju datu bāzi. Relāciju datu bāzu sadalīšana, vienlaikus saglabājot ACID atbilstību, var būt izaicinājums.
Izmantojiet relāciju datu bāzi:
- Situācijas, kurās datu integritāte ir absolūti vissvarīgākā (t.i., finanšu lietojumiem, aizsardzībai un drošībai, kā arī privātai informācijai par veselību)
- Ļoti strukturēti dati
- Iekšējo procesu automatizācija
Dokumentu veikals (MongoDB, Couchbase)
Dokumentu krājums ir nesaistīta datu bāze, kurā dati tiek glabāti JSON, BSON vai XML dokumentos. Tajos ir elastīga shēma. Atšķirībā no SQL datu bāzēm, kur lietotājiem pirms datu ievietošanas ir jādeklarē tabulas shēma, dokumentu krātuvēs netiek ieviesta dokumentu struktūra. Dokumentos var būt visi vēlamie dati. Viņiem ir atslēgu un vērtību pāri, bet arī iegulti atribūtu metadati, lai atvieglotu vaicājumu veikšanu.
Stiprās puses
Dokumentu veikali ir ļoti elastīgi. Viņi labi apstrādā pusstrukturētus un nestrukturētus datus. Lietotājiem iestatīšanas laikā nav jāzina, kādi dati tiks glabāti, tāpēc šī ir laba izvēle, ja iepriekš nav skaidrs, kāda veida dati tiks saņemti.
Lietotāji var izveidot vēlamo struktūru konkrētā dokumentā, neietekmējot visus dokumentus. Shēmu var modificēt, neradot dīkstāvi, kas noved pie augstas pieejamības. Arī rakstīšanas ātrums parasti ir ātrs.
Papildus elastībai izstrādātājiem patīk dokumentu veikali, jo tos ir viegli mērogot horizontāli. Horizontālajai mērogošanai nepieciešamā skaidošana ir daudz intuitīvāka nekā ar relāciju datu bāzēm, tāpēc dokumentu krātuves ātri un efektīvi tiek mērogotas.
Vājās puses
Dokumentu datu bāzēs upurē ACID atbilstību elastības dēļ. Lai arī vaicājumus var veikt dokumentā, tas nav iespējams visos dokumentos.
Izmantojiet dokumentu datu bāzi:
- Nestrukturēti vai pusstrukturēti dati
- Satura pārvaldība
- Padziļināta datu analīze
- Ātra prototipu veidošana
Atslēgu vērtību krājums (Redis, Memcached)
Atslēgu vērtību krātuve ir nederīgas datu bāzes veids, kur katra vērtība ir saistīta ar noteiktu atslēgu. Tas ir pazīstams arī kā asociatīvs masīvs.
“Atslēga” ir unikāls identifikators, kas saistīts tikai ar vērtību. Atslēgas var būt jebkas, ko atļauj DBVS. Redis, piemēram, atslēgas cilvēks var būt jebkura binārā secība līdz 512 MB.
“Vērtības” tiek glabātas kā plankumi, un tām nav nepieciešama iepriekš definēta shēma. Tie var būt gandrīz jebkurā formā: skaitļi, virknes, skaitītāji, JSON, XML, HTML, PHP, binārie faili, attēli, īsi videoklipi, saraksti un pat cits objektā iekapsulēts atslēgu un vērtību pāris. Dažas DBVS ļauj norādīt datu tipu, taču tas nav obligāti.
Stiprās puses
Šim datu bāzes stilam ir daudz pozitīva. Tas ir neticami elastīgs un viegli spēj apstrādāt ļoti plašu datu veidu klāstu. Taustiņi tiek izmantoti, lai pārietu tieši uz vērtību bez indeksu meklēšanas vai pievienošanās, tāpēc veiktspēja ir augsta. Pārnesamība ir vēl viens ieguvums: galveno vērtību krājumus var pārvietot no vienas sistēmas uz otru, nepārrakstot kodu. Visbeidzot, tie ir ļoti horizontāli mērogojami, un to darbības izmaksas kopumā ir zemākas.
Vājās puses
Elastībai ir sava cena. Vērtības nav iespējams vaicāt, jo tās tiek glabātas kā lāse un var tikt atdotas tikai kā tādas. Tas apgrūtina ziņojumu sagatavošanu vai vērtību daļu rediģēšanu. Arī visus objektus nav viegli modelēt kā atslēgu un vērtību pārus.
Izmantojiet atslēgas vērtību krātuvi:
- Ieteikumi
- Lietotāju profili un iestatījumi
- Nestrukturēti dati, piemēram, produktu atsauksmes vai emuāra komentāri
- Sesijas vadība mērogā
- Dati, kuriem piekļūs bieži, bet ne bieži atjauninās
Plašu kolonnu veikals (Cassandra, HBase)
Plašu kolonnu krātuves, sauktas arī par kolonnu krātuvēm vai paplašināmu ierakstu krātuvēm, ir dinamiskas uz kolonnām vērstas nerelacionālas datu bāzes. Dažreiz tie tiek uzskatīti par atslēgu vērtību glabāšanas veidu, taču tiem ir arī tradicionālo relāciju datu bāzu atribūti.
Plašu kolonnu veikalos shēmu vietā tiek izmantota atslēgu vietas koncepcija. Atslēgu laukums ietver kolonnu saimes (līdzīgas tabulām, bet strukturālākas), katrā no tām ir vairākas rindas ar atšķirīgām kolonnām. Katrai rindai nav jābūt vienādam kolonnu skaitam vai tipam. Laika zīmogs nosaka jaunāko datu versiju.
Stiprās puses
Šāda veida datu bāzēm ir dažas priekšrocības, ko sniedz gan relāciju, gan arī nesaistītās datu bāzes. Tas labāk apstrādā gan strukturētus, gan daļēji strukturētus datus nekā citas nesaistītas datu bāzes, un to ir vieglāk atjaunināt. Salīdzinot ar relāciju datu bāzēm, tā ir horizontāli mērogojama un ātrāka mērogā.
Kolonnu datubāzes saspiež labāk nekā uz rindām balstītas sistēmas. Arī lielas datu kopas ir viegli izpētīt. Plašu sleju veikali ir īpaši labi, piemēram, apkopošanas vaicājumos.
Vājās puses
Raksti ir dārgi mazajā. Lai gan atjaunināšanu ir viegli veikt vairumā, atsevišķu ierakstu augšupielāde un atjaunināšana ir sarežģīta. Turklāt plašu kolonnu veikali, apstrādājot darījumus, ir lēnāki nekā relāciju datu bāzes.
Izmantojiet plašu kolonnu krātuvi:
- Lielo datu analīze, kur ātrums ir svarīgs
- Datu uzglabāšana lielajiem datiem
- Liela mēroga projekti (šis datubāzes stils nav labs rīks vidējām darījumu lietojumprogrammām)
Meklētājprogramma (Elasticsearch)
Var šķist dīvaini meklētājprogrammu iekļaušana rakstā par datu bāzu tipiem. Tomēr Elasticsearch šajā jomā ir palielinājusi popularitāti, jo izstrādātāji meklē novatoriskus veidus, kā samazināt meklēšanas nobīdi. Elastisearch ir nesaistīts, uz dokumentiem balstīts datu glabāšanas un izguves risinājums, kas īpaši sakārtots un optimizēts datu glabāšanai un ātrai iegūšanai.
Stiprās puses
Elastisearch ir ļoti mērogojama. Tam ir elastīga shēma un ātra ierakstu atgūšana, izmantojot uzlabotas meklēšanas iespējas, tostarp pilna teksta meklēšanu, ieteikumus un sarežģītas meklēšanas izteiksmes.
Viena no interesantākajām meklēšanas funkcijām ir radusies. Stemming analizē vārda saknes formu, lai atrastu atbilstošus ierakstus, pat ja tiek izmantota cita forma. Piemēram, lietotājs, kurš nodarbinātības datu bāzē meklē “apmaksātu darbu”, atrastu arī amatus ar atzīmi “apmaksāts” un “atalgojums”.
Vājās puses
Elastisearch tiek izmantots vairāk kā starpnieks vai papildu veikals, nevis primārā datu bāze. Tam ir zema izturība un slikta drošība. Nav iedzimtas autentifikācijas vai piekļuves kontroles. Turklāt Elastisearch neatbalsta darījumus.
Izmantojiet tādu meklētājprogrammu kā Elastisearch:
- Lietotāju pieredzes uzlabošana, izmantojot ātrākus meklēšanas rezultātus
- Mežizstrāde
Nobeiguma apsvērumi
Dažas lietojumprogrammas glīti iekļaujas viena konkrēta datubāzes veida stiprajās pusēs, taču lielākajai daļai projektu pārklājas divi vai vairāki. Šādos gadījumos var būt noderīgi aplūkot, kuras konkrētās datu bāzes, par kurām tiek apgalvots, ir labi kandidāti. Pārdevēji piedāvā plašu funkciju spektru, lai pielāgotu savu datu bāzi individuāliem standartiem. Daži no tiem var palīdzēt novērst nenoteiktību tādos faktoros kā drošība, mērogojamība un izmaksas.
