Tinkamos duomenų bazės pasirinkimas dažnai gali būti labai svarbus programos sėkmei. Užuot pasinaudojus pardavėjų patarimais ar naudojantis duomenų baze, nes jūs jau turite tai, naudinga atsižvelgti į pagrindinį duomenų saugyklos tikslą ir reikalavimus.
Šie yra svarbiausi klausimai, kuriuos reikia užduoti renkantis duomenų bazę:
- Kiek duomenų tikitės išsaugoti, kai programa bus subrendusi?
- Kiek vartotojų tikitės vienu metu dirbti didžiausią apkrovą?
- Kokio prieinamumo, mastelio, vėlavimo, pralaidumo ir duomenų nuoseklumo reikia jūsų programai?
- Kaip dažnai pasikeis jūsų duomenų bazės schemos?
- Koks yra jūsų naudotojų geografinis pasiskirstymas?
- Kokia yra natūrali jūsų duomenų „forma“?
- Ar jūsų programai reikalingas internetinis operacijų apdorojimas (OLTP), analitinės užklausos (OLAP), ar abu?
- Kokio skaitymo ir rašymo santykio tikitės gamyboje?
- Ar jums reikia geografinių ir (arba) viso teksto užklausų?
- Kokios yra jūsų pageidaujamos programavimo kalbos?
- Ar turite biudžetą? Jei taip, ar tai apims licencijas ir paramos sutartis?
- Ar yra teisinių apribojimų jūsų duomenų saugojimui?
Išplėskime tuos klausimus ir jų pasekmes.
Kiek duomenų kaupsite?
Jei jūsų įvertis yra gigabaitų ar mažiau, tada beveik bet kokia duomenų bazė tvarkys jūsų duomenis, o atmintyje esančios duomenų bazės yra visiškai įmanomos. Terabaitų (tūkstančių gigabaitų) diapazone duomenims tvarkyti vis dar yra daug duomenų bazės parinkčių.
Jei jūsų atsakymas yra petabaitai (milijonai gigabaitų) ar didesni, tada jums naudingos tik kelios duomenų bazės, ir jūs turite būti pasirengę didelėms duomenų saugojimo išlaidoms, arba kapitalinėms išlaidoms sandėliavimui vietoje, arba veiklos išlaidoms. debesies saugykla. Tokiu mastu jums gali prireikti pakopinės saugyklos, kad užklausos apie „gyvus“ duomenis būtų vykdomos atmintyje arba vietinių SSD greičio atžvilgiu, o visas duomenų rinkinys yra sukamuosiuose diskuose, kad būtų taupiau.
Kiek vartotojų vienu metu?
Įvertinant daugelio vienu metu esančių vartotojų apkrovą, dažnai traktuojama kaip serverio dydžio pratimas, atliekamas prieš pat įdiegiant gamybos duomenų bazę. Deja, daugelis duomenų bazių tiesiog negali apdoroti tūkstančių vartotojų užklausų terabaitais ar petabaitais duomenų dėl mastelio problemų.
Darbuotojų naudojamoje duomenų bazėje daug lengviau įvertinti vienu metu veikiančius vartotojus nei viešoje duomenų bazėje. Dėl pastarųjų gali reikėti išplėsti kelis serverius dėl netikėtų ar sezoninių apkrovų. Deja, ne visos duomenų bazės palaiko horizontalų mastelį be daug laiko reikalaujančio rankinio didelių lentelių skaldymo.
Kokie jūsų „sugebėjimo“ reikalavimai?
Šiai kategorijai priskiriu prieinamumą, mastelio keitimą, vėlavimą, pralaidumą ir duomenų nuoseklumą, nors ne visi terminai baigiasi „-ility“.
Prieinamumas dažnai yra pagrindinis sandorių duomenų bazių kriterijus. Nors ne kiekviena programa turi veikti 24 valandas per parą 7 valandas, kai jos prieinamumas yra 99,999%, kai kurios tai daro. Kelios debesų duomenų bazės siūlo „penkių devynių“ prieinamumą, jei jas vykdote keliose prieinamumo zonose. Vietos duomenų bazės paprastai gali būti sukonfigūruotos taip, kad jos būtų prieinamos ne suplanuotais techninės priežiūros laikotarpiais, ypač jei galite sau leisti nustatyti aktyvių ir aktyvių serverių porą.
„Scalability“, ypač horizontalusis mastelis, „NoSQL“ duomenų bazėms istoriškai buvo geresnis nei „SQL“ duomenų bazėms, tačiau kelios „SQL“ duomenų bazės pasivijo. Dinaminį mastelio keitimą daug lengviau pasiekti debesyje. Didelės mastelio duomenų bazės gali vienu metu valdyti daugelį vartotojų, keisdami mastelį, kol pralaidumas bus pakankamas apkrovai.
Delsos laikas nurodo tiek duomenų bazės atsako laiką, tiek programos atsakymo laiką. Idealiu atveju kiekvienas vartotojo veiksmas turės sekundės atsakymo laiką; tai dažnai reiškia, kad duomenų bazė turi atsakyti per mažiau nei 100 milisekundžių už kiekvieną paprastą operaciją. Analitinės užklausos dažnai gali trukti sekundes ar minutes. Programos gali išsaugoti atsakymo laiką, vykdydamos sudėtingas užklausas fone.
OLTP duomenų bazės pralaidumas paprastai matuojamas operacijomis per sekundę. Didelės pralaidumo duomenų bazės gali palaikyti daugelį vienu metu veikiančių vartotojų.
Duomenų nuoseklumas paprastai yra „stiprus“ SQL duomenų bazėms, o tai reiškia, kad visi skaitiniai pateikia naujausius duomenis. Duomenų nuoseklumas gali būti „NoSQL“ duomenų bazių „galutinis“ ir „stiprus“. Galutinis nuoseklumas suteikia mažesnį vėlavimą, rizikuojant skaityti pasenusius duomenis.
Nuoseklumas yra „C“ ACID savybėse, reikalingas galiojimui klaidų, tinklo skaidinių ir maitinimo sutrikimų atveju. Keturios rūgšties savybės yra atomiškumas, konsistencija, izoliacija ir patvarumas.
Ar jūsų duomenų bazės schemos yra stabilios?
Jei vargu ar jūsų duomenų bazės schemos laikui bėgant labai pasikeis ir norite, kad daugumoje laukų tipai būtų nuoseklūs nuo įrašo iki įrašo, tada SQL duomenų bazės būtų jums tinkamas pasirinkimas. Priešingu atveju „NoSQL“ duomenų bazės, kai kurios net nepalaiko schemų, gali būti geresnės jūsų programai. Tačiau yra išimčių. Pvz., „Rockset“ leidžia atlikti SQL užklausas netaikant fiksuotos schemos ar nuoseklių tipų importuojamiems duomenims.
Geografinis vartotojų pasiskirstymas
Kai jūsų duomenų bazės vartotojai yra visame pasaulyje, šviesos greitis nuotoliniams vartotojams nustato apatinę duomenų bazės vėlavimo ribą, nebent jūs pateikiate papildomų serverių jų regionuose. Kai kuriose duomenų bazėse galima paskirstytus skaitymo ir rašymo serverius; kiti siūlo paskirstytus tik skaitymo serverius, visi įrašai priversti pereiti per vieną pagrindinį serverį. Dėl geografinio pasiskirstymo dar sunkiau suderinti nuoseklumą ir vėlavimą.
Dauguma duomenų bazių, palaikančių visame pasaulyje paskirstytus mazgus ir tvirtą nuoseklumą, naudojasi sutarimo grupėmis, kad pagreitintų rašymą be rimtai žeminančio nuoseklumo, paprastai naudojant Paxos (Lamport, 1990) arba Raft (Ongaro ir Ousterhout, 2013) algoritmus. Paskirstytose „NoSQL“ duomenų bazėse, kurios galiausiai yra nuoseklios, paprastai naudojamas nesutarimas, „peer-to-peer“ replikacija, o tai gali sukelti konfliktus, kai dvi kopijos gauna vienu metu įrašus į tą patį įrašą, konfliktus, kurie paprastai sprendžiami euristiškai.
Duomenų forma
SQL duomenų bazėse griežtai surinkti duomenys klasikiškai saugomi stačiakampėse lentelėse su eilėmis ir stulpeliais. Jie remiasi apibrėžtais ryšiais tarp lentelių, naudoja indeksus, kad pagreitintų pasirinktas užklausas, ir naudodamiesi JOINS vienu metu pateikia užklausas kelioms lentelėms. Dokumentų duomenų bazėse paprastai saugoma silpnai surinkta JSON, kurioje gali būti masyvai ir įdėti dokumentai. Grafikų duomenų bazėse saugomos viršūnės ir kraštai, arba trigubos, arba keturvietės. Kitose „NoSQL“ duomenų bazių kategorijose yra raktų vertės ir stulpelių saugyklos.
Kartais duomenys generuojami tokia forma, kuri taip pat tiks analizei; kartais to nėra, ir reikės pertvarkyti. Kartais vienos rūšies duomenų bazė yra kuriama ant kitos. Pavyzdžiui, pagrindinės vertės saugyklos gali būti beveik bet kokios rūšies duomenų bazės pagrindas.
OLTP, OLAP ar HTAP?
Norint išsiaiškinti anksčiau pateiktus akronimus, kyla klausimas, ar jūsų programai reikalinga duomenų bazė operacijoms, analizei ar abiem. Jei reikia greitų operacijų, tai reiškia greitą rašymo greitį ir minimalius indeksus. Analizės reikalavimas reiškia greitą skaitymo greitį ir daugybę rodyklių. Hibridinės sistemos naudoja įvairias gudrybes, kad atitiktų abu reikalavimus, įskaitant pirminę sandorių saugyklą, kuri pakartotinai tiekia antrinę analizės atsargą.
Skaitymo / rašymo santykis
Kai kurios duomenų bazės yra greitesnės skaitant ir užduodant užklausas, o kitos - greičiau. Skaitymų ir rašymų derinys, kurio tikitės iš savo programos, yra naudingas skaičius, kurį reikia įtraukti į jūsų duomenų bazės pasirinkimo kriterijus ir kuris gali padėti atlikti etaloną. Optimalus indekso tipo pasirinkimas skiriasi sunkiai skaitomoms programoms (paprastai B medžiui) ir sunkiai rašomoms programoms (dažnai rąsto struktūros sujungimo medis, dar žinomas kaip LSM medis).
Geoerdvinės rodyklės ir užklausos
Jei turite geografinių ar geometrinių duomenų ir norite atlikti efektyvias užklausas, norėdami rasti objektus ribos viduje arba objektus, esančius tam tikru atstumu nuo vietos, jums reikia kitokių indeksų, nei norėtumėte tipiniams reliaciniams duomenims. R-medis dažnai yra pirmenybė teikiantis geoerdvinių indeksų pasirinkimui, tačiau yra daugiau nei dešimt kitų galimų geoerdvinių rodiklių duomenų struktūrų. Yra pora dešimčių duomenų bazių, palaikančių erdvinius duomenis; dauguma palaiko kai kuriuos arba visus „Open Geospatial Consortium“ standartus.
Viso teksto indeksai ir užklausos
Panašiai, norint efektyviai ieškoti viso teksto teksto laukų, reikia kitokių indeksų nei reliacinių ar geoerdvinių duomenų. Paprastai kuriate apverstą simbolizuotų žodžių sąrašo indeksą ir ieškote to, kad išvengtumėte brangaus lentelės nuskaitymo.
Pageidaujamos programavimo kalbos
Nors dauguma duomenų bazių palaiko daugelio programavimo kalbų API, pageidaujama programavimo kalba jūsų programoje kartais gali turėti įtakos jūsų duomenų bazės pasirinkimui. Pvz., JSON yra natūralus „JavaScript“ duomenų formatas, todėl galbūt norėsite pasirinkti duomenų bazę, palaikančią JSON duomenų tipą „JavaScript“ programai. Jei naudojate griežtai įvestą programavimo kalbą, galbūt norėsite pasirinkti griežtai surinktą duomenų bazę.
Biudžeto suvaržymai
Duomenų bazių kainos svyruoja nuo nemokamų iki labai brangių. Daugelyje duomenų bazių yra tiek nemokamų, tiek mokamų versijų, ir kartais jose yra daugiau nei vieno lygio mokamas pasiūlymas, pavyzdžiui, siūloma „Enterprise“ versija ir skirtingas paslaugų atsakymo laikas. Be to, kai kurios duomenų bazės yra prieinamos debesyje mokant einamuoju laikotarpiu.
Jei pasirinksite nemokamą atvirojo kodo duomenų bazę, gali tekti atsisakyti tiekėjo palaikymo. Tol, kol turite patirties namuose, tai gali būti gerai. Kita vertus, jūsų žmonėms gali būti produktyviau susikoncentruoti ties programa ir palikti duomenų bazių administravimą ir priežiūrą pardavėjams ar debesijos paslaugų teikėjams.
Teisiniai apribojimai
Yra daugybė įstatymų, susijusių su duomenų saugumu ir privatumu. ES GDPR turi platų padarinių privatumui, duomenų apsaugai ir duomenų vietai. JAV HIPAA reguliuoja medicininę informaciją, o GLBA - tai, kaip finansų įstaigos tvarko privačią klientų informaciją. Kalifornijoje naujoji CCPA sustiprina teises į privatumą ir vartotojų apsaugą.
Kai kurios duomenų bazės gali tvarkyti duomenis taip, kad atitiktų kai kuriuos arba visus šiuos reglamentus, jei laikysitės geriausios praktikos. Kitose duomenų bazėse yra trūkumų, dėl kurių labai sunku jas naudoti asmenį identifikuojančiai informacijai, kad ir koks atsargus esate.
Sąžiningai, tai buvo ilgas veiksnių, į kuriuos reikia atsižvelgti renkantis duomenų bazę, sąrašas, tikriausiai daugiau nei norėtumėte apsvarstyti. Nepaisant to, verta pabandyti atsakyti į visus klausimus kiek įmanoma geriau savo komandoje, prieš rizikuodami įsipareigoti savo projektui pasirodyti, kad duomenų bazė yra nepakankama arba per brangi.
