Yra šimtai daug technikos reikalaujančių duomenų bazių apžvalgų, tačiau jos ne visada pateikia aiškias rekomendacijas dėl pirmo žingsnio renkantis duomenų bazę: parenkant geriausią konkretios programos bendrą tipą. Visos duomenų bazės nėra vienodos. Kiekvienas iš jų turi specifinių stipriųjų ir silpnųjų pusių. Nors tiesa, kad egzistuoja problemos sprendimo būdai, kad mėgstama duomenų bazė veiktų daugumoje projektų, šių gudrybių naudojimas padidina nereikalingą sudėtingumą.
Prieš svarstydami konkrečią duomenų bazę, skirkite šiek tiek laiko pagalvoti, koks tipas geriausiai palaikytų esamą projektą. Klausimas yra gilesnis nei „SQL vs NoSQL“. Perskaitykite dažniausiai naudojamų duomenų bazių tipus, jų santykinius privalumus ir tai, kaip geriausiai tinka.
Reliacinės duomenų bazių valdymo sistemos („Oracle“, „MySQL“, „MS Server“, „PostgreSQL“)
Reliacinės duomenų bazės buvo sukurtos aštuntajame dešimtmetyje, siekiant įveikti didėjantį duomenų srautą. Jie turi tvirtą pamatinę teoriją ir padarė įtaką beveik visoms šiandien naudojamoms duomenų bazių sistemoms.
Reliacinėse duomenų bazėse duomenų rinkiniai saugomi kaip „santykiai“: lentelės su eilėmis ir stulpeliais, kuriose visa informacija saugoma kaip tam tikro langelio vertė. RDBVS duomenys tvarkomi naudojant SQL. Nors yra įvairių diegimų, SQL yra standartizuotas ir suteikia nuspėjamumo bei naudingumo lygį.
Ankstyvam pardavėjų potvyniui bandžius pasinaudoti sistemos populiarumu naudojant ne visai santykinius produktus, kūrėjas E.F.Coddas išdėstė taisyklių rinkinį, kurio turi laikytis visos reliacinių duomenų bazių valdymo sistemos. 12 „Codd“ taisyklių sukasi apie griežtų vidinės struktūros protokolų įvedimą, užtikrinant, kad paieškos patikimai grąžintų prašomus duomenis, ir užkirsti kelią struktūriniams pakeitimams (bent jau vartotojų). Ši sistema užtikrino, kad reliacinės duomenų bazės yra nuoseklios ir patikimos iki šiol.
Stiprybės
Reliacinės duomenų bazės puikiai tvarko labai struktūrizuotus duomenis ir teikia paramą ACID (atomiškumo, nuoseklumo, izoliacijos ir patvarumo) operacijoms. Duomenys lengvai saugomi ir gaunami naudojant SQL užklausas. Struktūrą galima greitai padidinti, nes pridėti duomenis nekeičiant esamų duomenų yra paprasta.
RDBVS struktūroje įmontuoti apribojimai, kuriuos tam tikri naudotojų tipai gali pasiekti ar keisti. Dėl to reliacinės duomenų bazės yra gerai pritaikytos programoms, kurioms reikalinga pakopinė prieiga. Pavyzdžiui, klientai galėjo peržiūrėti savo sąskaitas, o agentai - ir peržiūrėti, ir atlikti būtinus pakeitimus.
Trūkumai
Didžiausia reliacinių duomenų bazių silpnybė yra jų didžiausios stiprybės veidrodis. Kad ir kaip jie gerai tvarkytų struktūrizuotus duomenis, jiems sunku susidurti su nestruktūrizuotais duomenimis. Atstovauti realaus pasaulio subjektus kontekste yra sunku, atsižvelgiant į RDBMS. „Supjaustytus“ duomenis reikia iš lentelių surinkti į ką nors labiau įskaitomą, o greitis gali būti neigiamai paveiktas. Fiksuota schema taip pat blogai reaguoja į pokyčius.
Kaina yra atlygis naudojant reliacines duomenų bazes. Juos įrengti ir augti paprastai būna brangiau. Horizontalusis mastelis arba mastelis, pridedant daugiau serverių, paprastai yra greitesnis ir ekonomiškesnis nei vertikalusis mastelis, kai į serverį reikia įtraukti daugiau išteklių. Tačiau reliacinių duomenų bazių struktūra apsunkina procesą. Dalijimasis (kai duomenys horizontaliai skaidomi ir paskirstomi mašinų rinkiniui) yra būtini norint išplėsti reliacinę duomenų bazę. Reliacinių duomenų bazių dalijimasis išlaikant ACID atitiktį gali būti iššūkis.
Naudokite reliacinę duomenų bazę:
- Situacijos, kai duomenų vientisumas yra ypač svarbus (t. Y. Finansinių programų, gynybos ir saugumo bei privačios sveikatos informacijos srityje)
- Labai struktūrizuoti duomenys
- Vidinių procesų automatizavimas
Dokumentų parduotuvė („MongoDB“, „Couchbase“)
Dokumentų saugykla yra nesusijusi duomenų bazė, kurioje saugomi duomenys JSON, BSON arba XML dokumentuose. Jie turi lanksčią schemą. Skirtingai nuo SQL duomenų bazių, kur vartotojai, prieš įterpdami duomenis, turi deklaruoti lentelės schemą, dokumentų saugyklos nevykdo dokumentų struktūros. Dokumentuose gali būti visi norimi duomenys. Jie turi raktų ir verčių poras, bet taip pat įdeda atributų metaduomenis, kad būtų lengviau atlikti užklausas.
Stiprybės
Dokumentų parduotuvės yra labai lanksčios. Jie gerai tvarko pusiau struktūrizuotus ir nestruktūruotus duomenis. Vartotojams nereikia nustatyti, kokie duomenys bus saugomi, todėl tai yra geras pasirinkimas, kai iš anksto nėra aišku, kokie duomenys bus gaunami.
Vartotojai gali sukurti norimą struktūrą konkrečiame dokumente, nepaveikdami visų dokumentų. Schemą galima modifikuoti nesukeliant prastovų, o tai lemia didelį prieinamumą. Rašymo greitis taip pat yra greitas.
Be lankstumo, kūrėjai mėgsta dokumentų parduotuves, nes jas lengva keisti horizontaliai. Skaldymas, reikalingas horizontaliam masteliui, yra daug intuityvesnis nei naudojant reliacines duomenų bazes, todėl dokumentų saugyklos greitai ir efektyviai keičiasi.
Trūkumai
Dokumentų duomenų bazėse aukojama ACID atitiktis lankstumui. Be to, nors užklausą galima atlikti dokumente, tai neįmanoma visuose dokumentuose.
Naudokite dokumentų duomenų bazę:
- Nestruktūrizuoti arba pusiau struktūruoti duomenys
- Turinio vadyba
- Išsami duomenų analizė
- Greitas prototipų kūrimas
Pagrindinės vertės saugykla (Redis, Memcached)
Rakto vertės saugykla yra nesusijusios duomenų bazės tipas, kur kiekviena reikšmė yra susieta su konkrečiu raktu. Jis taip pat žinomas kaip asociacinis masyvas.
„Raktas“ yra unikalus identifikatorius, susietas tik su verte. Raktai gali būti bet kokie, kuriuos leidžia DBVS. Pavyzdžiui, „Redis“ klavišuose gali būti bet kokia dvejetainė seka iki 512 MB.
„Vertybės“ saugomos kaip dėmės ir nereikia iš anksto apibrėžtos schemos. Jie gali būti beveik bet kokios formos: skaičiai, eilutės, skaitikliai, JSON, XML, HTML, PHP, dvejetainiai failai, vaizdai, trumpi vaizdo įrašai, sąrašai ir netgi kita rakto ir vertės pora, įklijuota į objektą. Kai kurios DBVS leidžia nurodyti duomenų tipą, tačiau tai nėra privaloma.
Stiprybės
Šis duomenų bazės stilius turi daug teigiamų dalykų. Tai nepaprastai lanksti, lengvai valdanti labai platų duomenų tipą. Raktai naudojami norint pereiti tiesiai prie vertės be indekso paieškos ar prisijungimo, todėl našumas yra aukštas. Perkeliamumas yra dar viena nauda: pagrindinės vertės saugyklos gali būti perkeltos iš vienos sistemos į kitą, neperrašant kodo. Galiausiai, jie yra labai horizontaliai keičiami ir turi mažesnes eksploatacijos išlaidas.
Trūkumai
Lankstumas turi savo kainą. Neįmanoma pateikti užklausų dėl verčių, nes jos saugomos kaip dėmė ir jas galima grąžinti tik kaip tokias. Tai apsunkina ataskaitų teikimą ar verčių dalių redagavimą. Ne visus objektus taip pat lengva modeliuoti kaip raktų ir verčių poras.
Naudokite raktų vertės saugyklą:
- Rekomendacijos
- Vartotojo profiliai ir nustatymai
- Nestruktūrizuoti duomenys, pvz., Produktų apžvalgos ar tinklaraščio komentarai
- Sesijos valdymas masto
- Duomenys, prie kurių bus prieinama dažnai, bet jie nebus dažnai atnaujinami
Plataus stulpelio parduotuvė (Cassandra, HBase)
Plataus stulpelio parduotuvės, dar vadinamos stulpelių saugyklomis arba išplėstinėmis įrašų saugyklomis, yra dinamiškos, į kolonas orientuotos, nesusijusios su duomenų bazėmis. Jie kartais laikomi raktų vertės saugyklos tipu, tačiau turi ir tradicinių reliacinių duomenų bazių atributų.
Plataus stulpelio parduotuvėse vietoj schemų naudojama klavišų srities sąvoka. Raktų sritis apima stulpelių šeimas (panašias į lenteles, bet pagal struktūrą lankstesnę), kurių kiekvienoje yra kelios eilutės su atskirais stulpeliais. Kiekvienoje eilutėje nebūtinai turi būti tas pats stulpelio numeris ar tipas. Laiko antspaudas nustato naujausią duomenų versiją.
Stiprybės
Šio tipo duomenų bazės turi tam tikrų tiek santykinių, tiek ir nesusijusių duomenų bazių pranašumų. Jame geriau tvarkomi tiek struktūrizuoti, tiek pusiau struktūruoti duomenys nei kitose nesusijusiuose duomenų bazėse, ir juos lengviau atnaujinti. Palyginti su reliacinėmis duomenų bazėmis, ji yra horizontaliau keičiama ir greitesnė.
Stulpelių duomenų bazės glaudinamos geriau nei eilėmis pagrįstos sistemos. Be to, didelius duomenų rinkinius lengva ištirti. Plataus stulpelio parduotuvės ypač tinka vykdant užklausas, pavyzdžiui.
Trūkumai
Rašymai brangūs mažuose. Nors atnaujinti nesudėtinga masiškai, atskirus įrašus įkelti ir atnaujinti sunku. Be to, plačių stulpelių parduotuvės yra lėtesnės nei reliacinės duomenų bazės tvarkant operacijas.
Naudokite plataus stulpelio parduotuvę:
- Didžiųjų duomenų analizė ten, kur svarbu greitis
- Didelių duomenų saugojimas
- Didelio masto projektai (šis duomenų bazės stilius nėra geras įrankis vidutinėms operacijoms)
Paieškos variklis („Elasticsearch“)
Gali atrodyti keista įtraukti paieškos sistemas į straipsnį apie duomenų bazių tipus. Tačiau „Elasticsearch“ pastebėjo vis didesnį populiarumą šioje srityje, nes kūrėjai ieško novatoriškų būdų, kaip sumažinti paieškos vėlavimą. „Elastisearch“ yra nesusijęs dokumentais pagrįstas duomenų saugojimo ir paieškos sprendimas, specialiai sutvarkytas ir optimizuotas duomenims saugoti ir greitai gauti.
Stiprybės
Elastinis tyrimas yra labai keičiamas. Jame yra lanksčios schemos ir greitas įrašų gavimas su išplėstinėmis paieškos parinktimis, įskaitant viso teksto paiešką, pasiūlymus ir sudėtingas paieškos išraiškas.
Viena iš įdomiausių paieškos funkcijų yra. Stemming analizuoja žodžio šaknies formą, kad surastų atitinkamus įrašus, net jei naudojama kita forma. Pavyzdžiui, vartotojas, kuris ieško užimtumo duomenų bazėje ieškodamas „mokamų darbų“, taip pat ras pareigas, pažymėtas „mokama“ ir „mokama“.
Trūkumai
„Elastisearch“ naudojamas daugiau kaip tarpinė ar papildoma parduotuvė, o ne pagrindinė duomenų bazė. Jis pasižymi mažu patvarumu ir prastu saugumu. Nėra įgimto autentifikavimo ar prieigos kontrolės. Be to, „Elastisearch“ nepalaiko operacijų.
Naudokite paieškos variklį, pvz., „Elastisearch“:
- Vartotojo patirties gerinimas naudojant greitesnius paieškos rezultatus
- Prisijungimas
Paskutiniai svarstymai
Kai kurios programos puikiai tinka vieno konkretaus tipo duomenų bazės privalumams, tačiau daugumoje projektų sutampa dvi ar daugiau. Tais atvejais gali būti naudinga pažvelgti į tai, kurios konkrečios duomenų bazės pagal stilius yra geri kandidatai. Pardavėjai siūlo platų funkcijų spektrą pritaikydami savo duomenų bazę pagal individualius standartus. Kai kurie iš jų gali padėti išspręsti neapibrėžtumą dėl tokių veiksnių kaip saugumas, mastelis ir išlaidos.
