Pareizas datu bāzes izvēle bieži var būt kritiska, lai pieteikums gūtu panākumus. Tā vietā, lai izmantotu pārdevēju padomus vai izmantotu datu bāzi, jo jums tas jau ir noticis, ir lietderīgi apsvērt datu krātuves pamatmērķi un prasības.
Šie ir vissvarīgākie jautājumi, kas jāuzdod, izvēloties datu bāzi:
- Cik daudz datu jūs plānojat uzglabāt, kad lietojumprogramma ir nobriedusi?
- Paredzat, cik lietotāju vienlaikus strādās ar maksimālo slodzi?
- Kāda pieejamība, mērogojamība, latentums, caurlaidspēja un datu konsekvence ir nepieciešama jūsu lietojumprogrammai?
- Cik bieži mainīsies jūsu datu bāzes shēmas?
- Kāds ir jūsu lietotāju populācijas ģeogrāfiskais sadalījums?
- Kāda ir jūsu datu dabiskā “forma”?
- Vai jūsu lietojumprogrammai ir nepieciešama tiešsaistes darījumu apstrāde (OLTP), analītiskie vaicājumi (OLAP) vai abi?
- Kādu lasījumu un rakstu attiecību jūs sagaidāt ražošanā?
- Vai jums ir nepieciešami ģeogrāfiski vaicājumi un / vai pilna teksta vaicājumi?
- Kādas ir jūsu vēlamās programmēšanas valodas?
- Vai jums ir budžets? Ja jā, vai tā attieksies uz licencēm un atbalsta līgumiem?
- Vai jūsu datu glabāšanai ir juridiski ierobežojumi?
Pievērsīsimies šiem jautājumiem un to sekām.
Cik daudz datu glabāsiet?
Ja jūsu aprēķins ir gigabaitos vai mazāk, tad gandrīz jebkura datu bāze apstrādās jūsu datus, un atmiņā esošās datu bāzes ir pilnīgi iespējamas. Joprojām ir daudz datu bāzes iespēju apstrādāt datus terabaitu (tūkstošiem gigabaitu) diapazonā.
Ja jūsu atbilde ir petabaiti (miljoni gigabaitu) vai vairāk, tad tikai dažas datu bāzes jums noderēs, un jums jābūt gatavam būtiskām datu glabāšanas izmaksām vai nu kapitālajos izdevumos krātuvē uz vietas, vai arī darbības izdevumos. mākoņglabātuve. Šajā mērogā jūs varētu vēlēties daudzpakāpju krātuvi, lai vaicājumi par “dzīviem” datiem varētu darboties atmiņā vai pret vietējiem SSD, lai iegūtu ātrumu, savukārt pilna datu kopa atrodas vērpšanas diskos, lai taupītu.
Cik vienlaicīgi lietotāju?
Daudzu vienlaicīgu lietotāju slodzes novērtēšana bieži tiek uzskatīta par servera lieluma noteikšanas vingrinājumu, kas jāveic tieši pirms ražošanas datu bāzes instalēšanas. Diemžēl mērogošanas problēmu dēļ daudzas datu bāzes vienkārši nespēj apstrādāt tūkstošiem lietotāju, kas vaicā terabaitus vai petabaitus datu.
Novērtēt vienlaicīgus lietotājus ir daudz vieglāk datu bāzei, kuru izmanto darbinieki, nekā publiskai datu bāzei. Attiecībā uz pēdējo, iespējams, jums būs jābūt iespējai paplašināt vairākus serverus neparedzētu vai sezonālu slodžu gadījumā. Diemžēl ne visas datu bāzes atbalsta horizontālu mērogošanu bez laikietilpīgas manuālo lielo tabulu sadrupināšanas.
Kādas ir jūsu “prasmes” prasības?
Šajā kategorijā es iekļauju pieejamību, mērogojamību, latentumu, caurlaidspēju un datu konsekvenci, kaut arī ne visi vārdi beidzas ar “-ility”.
Pieejamība bieži ir galvenais darījumu datu bāzu kritērijs. Lai gan ne katrai lietojumprogrammai ir jādarbojas visu diennakti un ir pieejama ar 99,999%, dažas to dara. Dažas mākoņu datubāzes piedāvā “piecu deviņu” pieejamību, ja vien tās darbināt vairākās pieejamības zonās. Lokālās datubāzes parasti var konfigurēt lielai pieejamībai ārpus plānotajiem apkopes periodiem, it īpaši, ja varat atļauties izveidot aktīvo un aktīvo serveru pāri.
Mērogojamība, īpaši horizontālā mērogojamība, vēsturiski ir bijusi labāka NoSQL datu bāzēm nekā SQL datu bāzēm, taču vairākas SQL datu bāzes ir panākušas. Dinamisko mērogojamību ir daudz vieglāk sasniegt mākonī. Datu bāzes ar labu mērogojamību var apstrādāt daudzus vienlaikus lietotājus, palielinot vai samazinot, līdz slodze ir pietiekama slodzei.
Latentums attiecas gan uz datu bāzes atbildes laiku, gan uz lietojumprogrammas atbildes laiku no gala līdz beigām. Ideālā gadījumā katrai lietotāja darbībai būs sekundes atbildes laiks; tas bieži nozīmē to, ka datu bāzei ir jāatbild mazāk nekā 100 milisekundēs par katru vienkāršu darījumu. Analītiskie vaicājumi bieži var ilgt sekundes vai minūtes. Lietojumprogrammas var saglabāt atbildes laiku, fonā izpildot sarežģītus vaicājumus.
OLTP datubāzes caurlaidi parasti mēra darījumos sekundē. Datu bāzes ar lielu caurlaidspēju var atbalstīt daudzus vienlaicīgus lietotājus.
Datu konsekvence SQL datu bāzēm parasti ir “spēcīga”, tas nozīmē, ka visi lasījumi atgriež jaunākos datus. Datu konsekvence NoSQL datu bāzēm var būt jebkura, sākot no “iespējamās” līdz “spēcīgajai”. Galīgā konsekvence piedāvā zemāku latentumu, riskējot nolasīt datus.
Konsekvence ir “C” ACID rekvizītos, kas nepieciešams derīgumam kļūdu, tīkla nodalījumu un strāvas padeves traucējumu gadījumā. Četras skābes īpašības ir atomitāte, konsekvence, izolācija un izturība.
Vai jūsu datu bāzes shēmas ir stabilas?
Ja maz ticams, ka jūsu datubāzes shēmas laika gaitā būtiski mainīsies, un jūs vēlaties, lai lielākajai daļai lauku būtu ierakstu tipi no ieraksta līdz ierakstam, tad SQL datu bāzes būtu laba izvēle jums. Pretējā gadījumā NoSQL datu bāzes, no kurām dažas pat neatbalsta shēmas, varētu būt piemērotākas jūsu lietojumprogrammai. Ir arī izņēmumi. Piemēram, Rockset pieļauj SQL vaicājumus, neuzliekot fiksētu shēmu vai konsekventus veidus importētajiem datiem.
Lietotāju ģeogrāfiskais sadalījums
Kad jūsu datu bāzes lietotāji atrodas visā pasaulē, gaismas ātrums attālajiem lietotājiem nosaka datu bāzes latentuma zemāko ierobežojumu, ja vien viņu reģionos nenodrošināt papildu serverus. Dažas datu bāzes ļauj izplatīt lasīšanas un rakstīšanas serverus; citi piedāvā izplatītus tikai lasāmus serverus, un visi raksti ir spiesti iet caur vienu galveno serveri. Ģeogrāfiskais sadalījums vēl vairāk apgrūtina kompromisu starp konsekvenci un latentumu.
Lielākā daļa no datu bāzēm, kas atbalsta globāli izplatītus mezglus un spēcīgu konsekvenci, izmanto vienprātības grupas, lai paātrinātu rakstīšanu bez nopietni pazemojošas konsekvences, parasti izmantojot Paxos (Lamport, 1990) vai Raft (Ongaro un Ousterhout, 2013) algoritmus. Izplatītās NoSQL datubāzes, kas galu galā ir konsekventas, parasti izmanto nepiekrišanu, vienādranga replikāciju, kas var izraisīt konfliktus, kad divas kopijas saņem vienlaicīgi ierakstus vienā un tajā pašā ierakstā, konfliktus, kas parasti tiek atrisināti heiristiski.
Datu forma
SQL datu bāzes klasiski glabā stingri ierakstītus datus taisnstūrveida tabulās ar rindām un kolonnām. Viņi paļaujas uz noteiktām attiecībām starp tabulām, izmanto indeksus, lai paātrinātu atlasītos vaicājumus, un JOINS izmanto, lai vienlaikus vaicātu vairākām tabulām. Dokumentu datu bāzēs parasti tiek glabāts vāji ierakstīts JSON, kas var ietvert masīvus un ligzdotus dokumentus. Grafiku datu bāzēs glabājas virsotnes un malas, vai trīskārši vai četrinieki. Citas NoSQL datu bāzes kategorijas ietver atslēgas vērtību un kolonnu krājumus.
Dažreiz dati tiek ģenerēti formā, kas darbosies arī analīzei; dažreiz tā nav, un būs nepieciešama pārveidošana. Dažreiz viena veida datu bāze tiek veidota uz citas. Piemēram, atslēgas vērtību veikali var būt gandrīz jebkura veida datu bāzes pamatā.
OLTP, OLAP vai HTAP?
Lai atšifrētu iepriekš minētos akronīmus, jautājums ir par to, vai jūsu lietojumprogrammai ir nepieciešama datu bāze darījumiem, analīzei vai abiem. Nepieciešama ātra transakcija nozīmē ātru rakstīšanas ātrumu un minimālus indeksus. Nepieciešama analīze nozīmē ātru lasīšanas ātrumu un daudz indeksu. Hibrīdās sistēmās tiek izmantoti dažādi triki, lai atbalstītu abas prasības, tostarp primārais darījumu krājums ar sekundāro analīzes krātuvi tiek nodrošināts ar replikācijas palīdzību.
Lasīšanas / rakstīšanas attiecība
Dažas datu bāzes ir ātrākas lasījumos un vaicājumos, citas - ātrāk. Lasījumu un rakstu kopums, ko jūs sagaidāt no savas lietojumprogrammas, ir noderīgs skaitlis, kas jāiekļauj datu bāzes atlases kritērijos, un tas var palīdzēt jūsu salīdzinošās novērtēšanas centienos. Optimālā indeksa veida izvēle atšķiras ar lietojumprogrammām, kas paredzētas lasīšanai (parasti B-koks), un lietojumprogrammām, kas paredzētas rakstīšanai (bieži vien žurnālā strukturēts sapludināšanas koks, jeb LSM koks).
Ģeotelpiskie indeksi un vaicājumi
Ja jums ir ģeogrāfiski vai ģeometriski dati un vēlaties veikt efektīvus vaicājumus, lai atrastu objektus robežas iekšienē vai objektus noteiktā atrašanās vietas attālumā, jums ir nepieciešami atšķirīgi indeksi nekā tipiskiem relāciju datiem. R-koks bieži ir vēlamā ģeotelpisko indeksu izvēle, taču ir vairāk nekā ducis citu iespējamo ģeotelpisko indeksu datu struktūru. Ir pāris desmiti datu bāžu, kas atbalsta telpiskos datus; lielākā daļa atbalsta dažus vai visus Open Geospatial Consortium standartus.
Pilna teksta indeksi un vaicājumi
Tāpat efektīvai teksta lauku pilnteksta meklēšanai ir nepieciešami atšķirīgi indeksi nekā relāciju vai ģeotelpiskie dati. Parasti jūs izveidojat marķētu vārdu apgrieztu saraksta indeksu un meklējat to, lai izvairītos no dārgas tabulas skenēšanas.
Vēlamās programmēšanas valodas
Lai gan lielākā daļa datu bāzu atbalsta API daudzām programmēšanas valodām, vēlamā programmēšanas valoda jūsu lietojumprogrammā dažreiz var ietekmēt jūsu datu bāzes izvēli. Piemēram, JSON ir JavaScript dabiskais datu formāts, tāpēc, iespējams, vēlēsities izvēlēties datu bāzi, kas atbalsta JSON datu tipu JavaScript lietojumprogrammai. Ja izmantojat stingri ievadītu programmēšanas valodu, ieteicams izvēlēties stingri ierakstītu datu bāzi.
Budžeta ierobežojumi
Datu bāzes svārstās no bezmaksas līdz ļoti dārgai. Daudzās datubāzēs ir gan bezmaksas, gan apmaksāta versija, un dažreiz tām ir vairāk nekā viens apmaksāta piedāvājuma līmenis, piemēram, piedāvājot Enterprise versiju un atšķirīgus pakalpojumu reakcijas laikus. Turklāt dažas datubāzes ir pieejamas mākonī pēc maksas, kurā ejat.
Ja izvēlaties bezmaksas, atvērtā pirmkoda datu bāzi, jums, iespējams, būs jāatsakās no piegādātāja atbalsta. Kamēr jums ir pieredze uzņēmuma iekšienē, tas var būt labi. No otras puses, jūsu darbiniekiem var būt produktīvāk koncentrēties uz lietojumprogrammu un datu bāzes administrēšanu un uzturēšanu atstāt pārdevēju vai mākoņpakalpojumu sniedzēju ziņā.
Juridiskie ierobežojumi
Ir daudz likumu par datu drošību un privātumu. ES GDPR ir plaša mēroga ietekme uz privātumu, datu aizsardzību un datu atrašanās vietu. ASV HIPAA regulē medicīnisko informāciju, un GLBA regulē veidu, kā finanšu iestādes apstrādā klientu privāto informāciju. Kalifornijā jaunā CCPA uzlabo privātuma tiesības un patērētāju aizsardzību.
Dažas datubāzes spēj apstrādāt datus tādā veidā, kas atbilst dažiem vai visiem šiem noteikumiem, ja vien jūs ievērojat paraugpraksi. Citās datu bāzēs ir trūkumi, kuru dēļ ir ļoti grūti tos izmantot personu identificējošai informācijai neatkarīgi no tā, cik uzmanīgs jūs esat.
Godīgi sakot, tas bija garš faktoru saraksts, kas jāņem vērā, izvēloties datu bāzi, iespējams, vairāk nekā jūs vēlētos ņemt vērā. Neskatoties uz to, ir vērts mēģināt pēc iespējas labāk atbildēt uz visiem jautājumiem, pirms riskējat nodot savu projektu, kas izrādās nepietiekama vai pārāk dārga datu bāze.
