Kā izvēlēties datubāzi

Atruna – virsrakstā un arī tālāk tekstā minētais vārds “datubāze” šajā rakstā ir domāts kā Datu bāzu vadības sistēma (DBVS), ko piedāvā kāds no to izstrādātājiem.

Es centīšos būt pēc iespējas objektīvs, cik nu tas vispār iespējams ievērojot manu iepriekšējo pieredzi. Lai maksimāli izvairītos no noteiktiem mājieniem, es vismaz rakstā nevienu konkrētu datu bāzu vadības sistēmas vārdu labāk nenosaukšu 😉

Tātad jums ir jauns projekts un jūs varat vismaz daļēji iespaidot to kādu datu bāzi jūsu projektā izvēlēties. Kādi būtu galvenie kritēriji, lai izdarītu izvēli, kuru vēlāk nevajadzētu nožēlot, un kas šai gadījumā svarīgāk – ilgtermiņā samazināt $$, €€ vai Ls, kas tiks ņemti no jūsu pašu vai jūsu atbildībā esošās naudas? Aplūkosim manuprāt svarīgākos kritērijus šai procesā.

1. Visas datubāzes nav vienādas

Pirmais visā šajā izvēles procesā gan nav konkrēts kritērijs. Pats pirmais un pats svarīgākais šai procesā ir saprast uzstādījumu, ka datu bāzu vadības sistēmas gluži tāpat kā mašīnas ir ārkārtīgi dažādas sākot no mums labi zināmā Zaporožeca līdz pat Ferrari, Maybach un tādiem monstriem, kādi nesen Rīgā paralizēja kādu brīdi Salu tiltu, un Latvijā nemaz nav redzēti. Tieši tāpat ir ar datubāzēm. Jūs nevarat cerēt, ka ar zaporožecu jūs jutīsieties komfortabli vai varēsiet aizvest lielu kravu grants. Ja jūs mēģināsiet burtiski pielietot to pašu ātruma pārslēgšanas metodi mašīnai ar automātisko ātrumkārbu, kādu jūs iemācījāties mašīnai ar manuālo ātrumkārbu, galarezultātā jūs varat nolauzt ātrumkloķi vai sabeigt ātrumkārbu. Analoģiski ar datubāzēm – tās izstrādā dažādas kompānijas un to arhitektūra atšķiras – un jūs nevarat tieši tās pašas labās un pareizās metodes, kas derēja DBVS X, izmantot nemainīti arī visās citās DBVS.

2. Apzināties savas pašreizējās prasības, bet tomēr domāt arī par nākotni

Šis ir kritērijs, kam visnopietnāk būtu jāietekmē jūsu izvēli. Jums ir jānoskaidro jūsu funkcionālās un nefunkcionālās prasības pret potenciālo galaproduktu un jāizvēlas datubāze, kas atbildīs šīm jūsu prasībām. Prasības, kam noteikti būtu jāpievērš uzmanība ir vismaz šādas:
1) datu apjoms un datu veids (tekstuāli, bināri, ģeogrāfiski u.c. specifiski dati);
2) potenciālais vienlaicīgo lietotāju daudzums;
3) potenciālā pieejamība, t.i. cik daudz gadā jūs varat atļauties situācijas, kad datubāze nav pieejama;
4) mērogojamība – kas notiks, kad jūsu datu apjoms un lietotāju skaits augs;
5) drošība, cik svarīgas jums ir tādas lietas kā datu drošība, datu šifrēšana, lietotāju administrēšana, datu pieejamība atkarībā no tiesībām;
6) pārvaldība un administrēšana, cik viegli un “lietotājam draudzīgi” jūs gribat tikt galā ar datu bāzes uzraudzīšanu un pārvaldīšanu;
7) kādas gudras un modernas papildus lietas jūs gribētu sagaidīt no datu bāzes.
Kā jau parasti savas vēlmes vajadzētu sabalansēt ar iespējām un reālajām vajadzībām. Protams, ir nepieciešams skatīties mazliet nākotnē un izsacīt prasības, kas arī rīt un parīt nodrošinās jūsu datubāzes veiksmīgu darbību, bet tai pašā laikā nevajadzētu orientēties uz maksimāli iespējamo 0.01% ticamo scenāriju un visas prasības balstīt uz to. Daži piemēri, kas lielā mērā atspoguļo manu reālo dzīves pieredzi 🙂 Vajadzētu vienmēr pārliecināties, vai tiešām jums ir reāli nepieciešama 99,9% pieejamība (kas nozīmē nepieejamību 8.76 stundas gadā), ja tai pašā laikā naktīs ar jūsu sistēmu strādā pāris lietotāji, kuri mierīgi var paciesties kādu nakti līdz rītam vai mežonīga drošība, ja operatoram alga ir 200 Ls uz rokas un viņam ir pieejami visi dati. Jāatceras, ka, piemēram, pieejamība ir ļoti komplekss problēmu kopums un tas, ka datubāze strādās un būs pieejama lokāli, nenozīmē, ka tā būs pieejama jūsu klientiem tīkla atteices gadījumā. Otrs piemērs – ir vērts atcerēties arī par tādiem sīkumiem, kā rezerves kondicionieriem, jo, ja jūsu datu centrā karstā vasaras dienā pārstās strādāt esošais(-ie), tad nekāda dzelžu konfigurācija, datubāzes spoguļošana un klāsterēšana, atsevišķi dīzeļģeneratori un Dievs vien zina kas vēl nelīdzēs 🙂

3. Ņemiet vērā savu iepriekšējo pieredzi darbā ar datu bāzēm

Noteikti ņemiet vērā savu iepriekšējo pieredzi un zināšanas darbā ar datu bāzēm. Kā jau minēju, tās ir atšķirīgas. Ja jūs izvēlēsieties jums nepazīstamu vai mazpazīstamu datu bāzi, noteikti būs nepieciešams laiks, lai to iepazītu, lai iepazītu tās atbalstītos rīkus, noskaidrotu, ko ar to var panākt un ko nevar, uzzinātu par tās vājajām vietām, ko parasti jau neviens tā vis neafišē. Iespējams jūsu darbiniekiem vajadzēs kursus (papildus jau esošajam normālajam kursu grafikam, kurš jūs organizācijā, protams, ir, vai ne?), kuri ne tikai paši maksās, bet arī tai laikā jūsu darbinieki nepildīs ikdienas darbu.

4. Esošā situācija (sadarbība ar esošajām sistēmām) – jauna pirmā dbvs vai citas jau priekšā

Ir liela atšķirība, vai šis jūsu projekts ir radīts tukšā vietā, kur nekā priekšā nav – tādā gadījumā jums ir daudz lielāka izvēles brīvība -, vai arī jums jau ir N citas datubāzes, ar ko jūsējai būs jāsadarbojas. Skaidrs, ka katrs datu bāzu izstrādātājs ir pacenties, lai ar šī paša izstrādātāja datu bāzēm “sarunāšanās” notiktu daudz vieglāk, nekā ar konkurentiem. Otrs iemesls, kāpēc nopietni pārdomāt jau esošās datubāzes izmantošanu, ir organizācijā esošā pieredze darbā ar datubāzi, pieredze darbā ar datubāzes izstrādātāja lietotāju atbalstu, ko kopsummā varētu nosaukt par esošās zināšanu bāzes izmantošanu. Jaunas lietas parasti ir riskantākas nekā vecās.

5. Novērtējiet pieejamo darba spēka tirgu Latvijā attiecībā uz potenciālo izvēlēto DBVS

Latvija nav liela. Latvijā pieejamais IT speciālistu loks ir vēl mazāks. Ja jūs nopirksiet kādu nevienam nezināma izstrādātāja mašīnas modeli, reti kāds serviss uzņemsies tādu labot vispār, savukārt, ja kāds būs gatavs to darīt, tad rodas jautājums, vai viņš to nedarīs tāpēc, ka nevienu parastu mašīnu šim servisam neuztic? Līdzīgi ir ar datubāzēm – pirms galīgās izvēles noskaidrojiet cik un vai vispār Latvijā ir kāds cilvēks, kas problēmu gadījumā ar šo datubāzi spēs tikt galā. Būs ļoti nepatīkami, ja jums nāksies maksāt pamatīgu naudu dienā kādam, kas savedīs jūsu unikālo datubāzi darba kārtībā, bet vēl daudz nepatīkamāk būs, ja jūs vienkārši nevienu nevarēsiet atrast, jo visi esošie būs pārāk aizņemti vai arī tādu vienkārši nebūs.

Tieši tas pats ir arī par normālu darba procesu izmantojot jūs izvēlēto datubāzi. Visu datu bāzu administratoriem un izstrādātājiem nemaksā vienādu algu. Katrā konkrētā laika posmā iespējams, ka tendences ir mainīgas, bet parasti ir tā, ka ir vieglāk dabūt izstrādātājus datubāzei X par zināmu algas apjomu, nekā datubāzei Y par to pašu algu. Darba spēka pieejamība tieši iespaido algas, tā tieši iespaido to, vai jums vispār izdosies un par kādu cenu vajadzības gadījumā iegādāties darbiniekus no kādas citas iestādes. Pieejamība nodrošina jūs ar lielākām vai mazākām manevra iespējām gadījumā, ja kāds darbinieks nerāda gluži to sniegumu, ko jūs no viņa esiet gaidījuši.

Nelielu ieskatu par potenciālu darba spēka pieejamību attiecībā uz darbaspēka pieejamību varat redzēt šeit – aptauja par popularākajām DBVS Latvijā.

6. Novērtējiet iespējamās tiešās izmaksas

6.1. Licences

Šī ir tā lieta, par ko visi uztraucas, smalki rēķina un salīdzina, ka lūk datubāze X ir lētāka nekā Y. Patiesībā šis faktors ir tikai viens no vairākiem, kas tieši ietekmē cenu, nemaz nerunājot par visiem tiem, kas cenu ietekmē netieši. Runājot par licenču cenām ir jāatceras, ka:

• datubāzēm mēdz būt dažādi licencēšanas modeļi, piemēram, pēc lietotāju skaita, pēc procesoru skaita, pēc operatīvās atmiņas lieluma;
• lai ko arī neteiktu oficiālā datubāzes izstrādātāja lapa, iespējams, ka ar pārdevēju jūs varat vienoties par zemāku cenu, jo sevišķi, ja tā nav jūsu ne pirmā, ne vienīgā šī izstrādātāja datubāze;
• lielākajām datubāzēm mēdz būt dažādas versijas, piemēram, enterprise un standard, kur ir ļoti būtiskas atšķirības to licenču cenā. Pārdomājiet, vai tiešām jums ir nepieciešama enterprise versija (kas parasti ir tā, uz ko visi pirmajā brīdī orientējas), jo enterprise versijas parasti ir domātas ASV tirgum un Latvijā vispār nav lielu uzņēmumu skatoties ASV mērogā, līdz ar to iespējams, ka jums pilnīgi pietiek ar standard versiju. Vēl ļoti nozīmīgs faktors – atcerieties pirmo punktu – datubāzes ir ļoti dažādas tāpēc, kas vienai varbūt ir enterprise versija, citai ir tikai standard. Līdz ar to nekļūstiet maldināti un nekad mehāniski nesalīdziniet versiju cenas, nepainteresējoties, kāda piedāvātā funkcionalitāte katrā ir iekšā.

6.2. Atbalsts

Noskaidrojiet, cik maksā atbalsts un kas tajā ietilpst. Parasti atbalsta līmeņi mēdz būt dažādi, ar attiecīgi dažādām cenām un piedāvātajām iespējām.

6.3. Papildus iespējas

Mēdz būt papildus iespējas, kas neietilpst nevienā no piedāvātajām versijām, arī enterprise. Tas nozīmē, ka jūs maksāsiet gan par enterprise/standard versiju, gan par papildus funkcionalitāti. Šis nu ir tas gadījums, kad ļoti skaidri un ļoti tieši ir jānovērtē vai attiecīgā papildus funkcionalitāte tik tiešām ir nepieciešama, kā arī šis var būt labs gadījums, kad pārdevējam tomēr prasīt kādu atlaidi 🙂

6.4. Operētājsistēmas prasības

Dažas datubāzes darbojas tikai uz noteiktām operētājsistēmām. Operētājsistēmas tāpat kā datubāzes mēdz būt dažādas. To izmaksu novērtēšanā var izmantot līdzīgus kritērijus kā šeit uzskaitītajām datubāzēm un ļoti var gadīties, ka tad, kad jums nāksies smalki konfigurēt nepazīstamu operētājsistēmu, jums vairs nemaz nebūs svarīga tās vai citas operētājsistēmas licences cena.

7. Datubāzes atteice

Cik liela ir varbūtība, ka izvēlētā datubāze kādā brīdī tādu vai citādu iemeslu dēļ atteiksies strādāt? Kurš jums to atjaunos? Kāds ir sagaidāmais laiks tās atjaunošanai? Cik daudz naudas jūs vai jūsu klients tai laikā zaudēs/neiegūs?

8. Specifiska industrija

Dažās specifiskās nozarēs ar specifiskām vajadzībām (piemēram, ģeogrāfiskās informācijas sistēmas) jau ir iepriekš noteiktas viena vai vairākas datubāzes, kas tajā parasti tiek izmantotas. Iespējams, ka jūs varat darboties kā celmlauzis un kļūt šai nozarē par pirmo visā pasaulē, kas tajā ievieš datubāzi X, bet tikpat droši vai pat drošāk var būt, ka jūs sastapsieties ar pārāk daudz problēmām šai procesā. Tātad, ja jums ir kaut kādi specifiski dati vai specifisks datu apstrādes veids, ir vērts nopietni interesēties par pieņemto praksi šādu datu apstrādē.

9. Specifisks produkts

Ja jūs izvēlaties kādu jau esošu produktu, kas spēj strādāt ar dažādām datubāzēm, tad vispirmām kārtām pārliecinieties, vai tam nav pārāk spilgti izteiktas šādu produktu negatīvās īpašības. Ja nu jums tomēr nav izvēles vai arī produkta izstrādātājs ir runājis pietiekami pārliecinoši, tad noteikti painteresējieties, vai produktam ir kāda vairāk ieteicamā datubāze salīdzinājumā ar citām. Ja nu jums arī tagad stāsta, ka uz visām datubāzēm produkts darbojas vienlīdz labi, tad tas visdrīzāk nozīmē to, ka vai nu jums nez kāpēc nestāsta taisnību, vai uz visām datubāzēm tas darbojas arī vienlīdz slikti 😉 Katrā ziņā tādā gadījumā mēģiniet noskaidrot, kura bija sākotnējā datubāze (visticamāk uz tās strādās vislabāk) vai arī pie esošajiem klientiem painteresējieties, kādas datubāzes šim produktam viņi izmanto un ar kādām problēmām ir sastapušies. Noteikti nenovēlu jums būt pirmajam produkta klientam uz izvēlētās datubāzes 😉

10. Esošā izstrādātāju kopiena, pieejamie info resursi  un popularitāte

Ja vien jums nav iedzimta vēlme būt celmlauzim, tad noteikti ir vērts painteresēties par esošās izstrādātāju kopienas (forumi, e-pasta listes, neformālas lietotāju apvienības, klātienes konferences un semināri) esamību un aktivitāti. Papildus tam painteresējieties, kādi ir pieejami rakstu krājumi, lietotāja/izstrādātāja rokasgrāmatas u.c. interneta resursi, kas grūtā brīdī noteikti noderēs un palīdzēs jums atrisināt radušās problēmas. Jūs visdrīzāk negribiet būt pirmais, kas risina daudzas radušās problēmas, pietiks jau arī ar dažām 😉

11. Nepieciešamā aparatūra

Ir vērts noskaidrot, kāda ir izvēlētās datubāzes rekomendējamā aparatūra un servera parametri (vismaz minimālie). Protams, tas ir ļoti atkarīgs no jūsu plānotā glabājamā datu daudzuma, vienlaicīgajiem lietotājiem un paredzamās noslodzes.

Kopsavilkums

Būsim jau nu godīgi, es neloloju ilūzijas, ka jūs ņemsiet vērā visus augšminētos kritērijus 😉 Vēl vairāk – vairumā gadījumu, kad jūs veidojat mazu sistēmiņu 5 lietotājiem, jūs īpaši neinteresē tādas lietas kā augsta pieejamība, mērogojamība utt. BET ar šo rakstu es gribēju uzsvērt pašu galveno lietu – datubāzes cena nav tikai tās licences cena. Nē, nē un vēlreiz nē. Jo lielāku sistēmu jūs būvējat, jo mazāk licences cena iespaido kopējās izmaksas. Ar katru nākošo dzīves mēnesi Latvijā arī šis iespaids mazinās, jo darba spēka izmaksas aizvien palielinās un tie daži simti vai pat tūkstoši dolāru, ko izmaksā licence reizi n gados maz izceļas uz datu bāzes administratora algas fona.

Augšminētie kritēriji lielā mērā var kalpot arī par pamatu TCO aprēķinam, ja vien kāds sadūšojas šo metodi pielietot savā projektā datubāzes izvēlei, vai konkrēta produkta izvēlei, kas darbojas uz kādas datubāzes.