Izbor "prave" baze podatkov je pogosto lahko ključnega pomena za uspeh aplikacije. Namesto da bi upoštevali nasvete prodajalcev ali uporabili bazo podatkov, ker jo že imate, je koristno razmisliti o temeljnem namenu in zahtevah shrambe podatkov.
To so najpomembnejša vprašanja, ki si jih morate zastaviti, ko izbirate bazo podatkov:
- Koliko podatkov nameravate shraniti, ko bo aplikacija zrela?
- Koliko uporabnikov pričakujete, da bodo istočasno obravnavali pri največji obremenitvi?
- Kakšno razpoložljivost, razširljivost, zakasnitev, prepustnost in doslednost podatkov potrebuje vaša aplikacija?
- Kako pogosto se bodo spreminjale vaše sheme baz podatkov?
- Kakšna je geografska porazdelitev vaše uporabniške populacije?
- Kakšna je naravna »oblika« vaših podatkov?
- Ali vaša aplikacija potrebuje spletno obdelavo transakcij (OLTP), analitične poizvedbe (OLAP) ali oboje?
- Kakšno razmerje med branjem in zapisom pričakujete v produkciji?
- Ali potrebujete geografske poizvedbe in / ali poizvedbe po celotnem besedilu?
- Kateri so vaši najljubši programski jeziki?
- Imate proračun? Če je odgovor pritrdilen, bo zajemal licence in podporne pogodbe?
- Ali obstajajo zakonske omejitve za shranjevanje podatkov?
Razširimo ta vprašanja in njihove posledice.
Koliko podatkov boste shranili?
Če je vaša ocena v gigabajtih ali manj, bo skoraj vsaka baza podatkov obdelala vaše podatke, baze podatkov v pomnilniku pa so popolnoma izvedljive. Še vedno obstaja veliko možnosti zbirke podatkov za obdelavo podatkov v obsegu terabajtov (na tisoče gigabajtov).
Če je vaš odgovor v petabajtih (milijoni gigabajtov) ali več, vam bo le nekaj baz podatkov dobro služilo, zato morate biti pripravljeni na pomembne stroške shranjevanja podatkov, bodisi v kapitalskih izdatkih za lokalno shranjevanje bodisi v operativnih izdatkih za shranjevanje v oblaku. Na tej lestvici boste morda želeli večstopenjski pomnilnik, tako da se bodo lahko poizvedbe o "aktivnih" podatkih hitrosti izvajale v pomnilniku ali proti lokalnim SSD-jem, medtem ko je celoten nabor podatkov na vrtljivih diskih zaradi varčnosti.
Koliko hkratnih uporabnikov?
Ocenjevanje obremenitve številnih sočasnih uporabnikov se pogosto obravnava kot vaja za določanje velikosti strežnika, ki jo je treba opraviti tik pred namestitvijo vaše podatkovne baze. Na žalost številne zbirke podatkov zaradi težav s skaliranjem preprosto ne morejo obdelati na tisoče uporabnikov, ki poizvedujejo po terabajtih ali petabajtih podatkov.
Ocenjevanje hkratnih uporabnikov je za bazo podatkov, ki jo uporabljajo zaposleni, veliko lažje kot za javno bazo podatkov. Za slednje boste morda morali imeti možnost razširitve na več strežnikov zaradi nepričakovanih ali sezonskih obremenitev. Na žalost vse baze podatkov ne podpirajo vodoravnega skaliranja brez zamudnega ročnega ostrenja velikih tabel.
Kakšne so vaše zahteve za "-ility"?
V to kategorijo sem vključil razpoložljivost, razširljivost, zakasnitev, pretočnost in doslednost podatkov, čeprav se vsi izrazi ne končajo z »-ility«.
Razpoložljivost je pogosto ključno merilo za transakcijske baze podatkov. Čeprav ni treba, da vsaka aplikacija deluje neprekinjeno 24 ur na dan, z 99,999-odstotno razpoložljivostjo, nekateri to počnejo. Nekaj baz podatkov v oblaku ponuja razpoložljivost "pet devetk", če jih izvajate v več območjih razpoložljivosti. Lokalne zbirke podatkov je običajno mogoče konfigurirati za visoko razpoložljivost izven načrtovanih obdobij vzdrževanja, še posebej, če si lahko privoščite nastavitev aktivnega in aktivnega para strežnikov.
Prilagodljivost, zlasti horizontalna razširjenost, je bila v preteklosti boljša za zbirke podatkov NoSQL kot za zbirke podatkov SQL, vendar jih več baz podatkov dohiteva. Dinamično razširljivost je veliko lažje doseči v oblaku. Baze podatkov z dobro razširljivostjo lahko obvladujejo številne sočasne uporabnike s povečevanjem ali zmanjševanjem, dokler pretočnost ne zadošča za obremenitev.
Latenca se nanaša tako na odzivni čas baze podatkov kot na odzivni čas aplikacije od konca do konca. V idealnem primeru ima vsako uporabniško dejanje odzivni čas v sekundah; kar pogosto pomeni, da mora baza podatkov odgovoriti v manj kot 100 milisekundah za vsako preprosto transakcijo. Analitična poizvedbe lahko pogosto trajajo sekunde ali minute. Aplikacije lahko ohranijo odzivni čas tako, da v ozadju izvajajo zapletene poizvedbe.
Pretok za bazo podatkov OLTP se običajno meri v transakcijah na sekundo. Zbirke podatkov z visoko prepustnostjo lahko podpirajo številne sočasne uporabnike.
Doslednost podatkov je za baze podatkov SQL običajno "močna", kar pomeni, da vsa branja vrnejo najnovejše podatke. Skladnost podatkov je lahko od "morebitne" do "močne" za zbirke podatkov NoSQL. Morebitna doslednost ponuja nižjo zakasnitev, s tveganjem branja zastarelih podatkov.
Doslednost je »C« v lastnostih ACID, ki je potrebna za veljavnost v primeru napak, omrežnih particij in izpadov napajanja. Štiri lastnosti kisline so atomskost, doslednost, izolacija in trajnost.
Ali so vaše sheme zbirke podatkov stabilne?
Če se verjetno ne bodo vaše sheme baz podatkov sčasoma bistveno spremenile in želite, da ima večina polj skladne tipe od zapisa do zapisa, potem bi bile baze podatkov SQL dobra izbira za vas. V nasprotnem primeru bi bile za vašo aplikacijo morda boljše zbirke podatkov NoSQL, od katerih nekatere niti ne podpirajo shem. Vendar obstajajo izjeme. Na primer, Rockset omogoča poizvedbe SQL, ne da bi za podatke, ki jih uvaža, naložil fiksno shemo ali skladne tipe.
Geografska porazdelitev uporabnikov
Ko so uporabniki vaše baze podatkov po vsem svetu, svetlobna hitrost za oddaljene uporabnike nalaga spodnjo omejitev zakasnitve baze podatkov, razen če v njihovih regijah zagotovite dodatne strežnike. Nekatere zbirke podatkov omogočajo porazdeljene strežnike za branje in pisanje; drugi ponujajo porazdeljene strežnike, ki so samo za branje, pri čemer so vsi zapisi prisiljeni skozi en sam glavni strežnik. Geografska porazdelitev še bolj otežuje kompromis med skladnostjo in zakasnitvijo.
Večina baz podatkov, ki podpirajo globalno porazdeljena vozlišča in močno doslednost, uporablja skupine soglasja za pospešitev pisanja brez resne poslabšanja doslednosti, običajno z uporabo algoritmov Paxos (Lamport, 1990) ali Raft (Ongaro in Ousterhout, 2013). Porazdeljene baze podatkov NoSQL, ki so sčasoma dosledne, običajno uporabljajo nesoglasno replikacijo med enakovrednimi napravami, kar lahko privede do konfliktov, ko dve kopiji prejmeta sočasno zapisovanje v isti zapis, konflikte, ki se običajno rešijo hevristično.
Oblika podatkov
Podatkovne baze SQL klasično shranjujejo močno vtipkane podatke v pravokotne tabele z vrsticami in stolpci. Zanašajo se na definirane relacije med tabelami, uporabljajo indekse za pospešitev izbranih poizvedb in JOINS za poizvedovanje po več tabelah hkrati. Podatkovne baze dokumentov običajno shranjujejo šifrirani JSON, ki lahko vključuje nize in ugnezdene dokumente. Grafične podatkovne baze shranjujejo bodisi oglišča in robove bodisi trojke ali štirikolesnike. Druge kategorije baz podatkov NoSQL vključujejo shrambe ključ-vrednost in stolpce.
Podatki se včasih generirajo v obliki, ki bo delovala tudi za analizo; včasih ni in bo potrebna preobrazba. Včasih je ena vrsta baze podatkov zgrajena na drugi. Na primer shrambe ključ-vrednost so lahko osnova skoraj vseh vrst zbirk podatkov.
OLTP, OLAP ali HTAP?
Če želite razvozlati zgornje kratice, je vprašanje, ali vaša aplikacija potrebuje bazo podatkov za transakcije, analize ali oboje. Potreba po hitrih transakcijah pomeni hitro pisanje in minimalne indekse. Analiza potrebe pomeni hitro hitrost branja in veliko indeksov. Hibridni sistemi uporabljajo različne trike, da podpirajo obe zahtevi, vključno s primarnim skladiščem transakcij, ki prek kopiranja napaja sekundarno shrambo analiz.
Razmerje branja / pisanja
Nekatere zbirke podatkov hitreje berejo in poizvedujejo, druge pa hitreje pišejo. Kombinacija branja in pisanja, ki jo pričakujete od svoje aplikacije, je koristno število, ki jo lahko vključite v merila za izbiro baze podatkov, in vam lahko pomaga pri primerjalnih preizkusih. Optimalna izbira vrste indeksa se razlikuje med aplikacijami, ki so težke za branje (običajno B-drevo), in aplikacijami, težkimi za pisanje (pogosto drevo zlitja, strukturirano v dnevniku, imenovano LSM drevo).
Geoprostorski indeksi in poizvedbe
Če imate geografske ali geometrijske podatke in želite izvesti učinkovite poizvedbe za iskanje predmetov znotraj meje ali objektov na določeni razdalji lokacije, potrebujete drugačne indekse kot za običajne relacijske podatke. R-drevo je pogosto najprimernejša izbira za geoprostorske indekse, vendar obstaja več kot ducat drugih podatkovnih struktur geoprostorskega indeksa. Obstaja nekaj deset baz podatkov, ki podpirajo prostorske podatke; večina podpira nekatere ali vse standarde odprtega geoprostorskega konzorcija.
Indeksi in poizvedbe v celotnem besedilu
Podobno učinkovito iskanje besedilnih polj v celotnem besedilu zahteva drugačne indekse kot relacijski ali geoprostorski podatki. Značilno je, da zgradite indeks obrnjenega seznama tokeniziranih besed in iščete to, da se izognete dragemu pregledovanju tabel.
Prednostni programski jeziki
Medtem ko večina baz podatkov podpira API-je za številne programske jezike, lahko prednostni programski jezik v vaši aplikaciji včasih vpliva na izbiro baze podatkov. Na primer, JSON je naravna oblika podatkov za JavaScript, zato boste morda želeli izbrati bazo podatkov, ki podpira podatkovni tip JSON za aplikacijo JavaScript. Ko uporabljate močno tipiziran programski jezik, boste morda želeli izbrati močno tipizirano bazo podatkov.
Proračunske omejitve
Cene podatkovnih baz so od brezplačnih do zelo dragih. Številne zbirke podatkov imajo tako brezplačne kot plačljive različice in imajo včasih več kot eno raven plačljive ponudbe, na primer različica za podjetja in različni odzivni časi za storitve. Poleg tega so nekatere zbirke podatkov na voljo v oblaku pod pogoji, ko plačate.
Če izberete brezplačno odprtokodno bazo podatkov, se boste morda morali odreči podpori ponudnikov. Dokler imate lastno strokovno znanje, je to v redu. Po drugi strani pa je morda bolj produktivno, če se vaši ljudje osredotočijo na aplikacijo, upravljanje in vzdrževanje baze podatkov pa prepustijo prodajalcem ali ponudnikom v oblaku.
Zakonske omejitve
Obstaja veliko zakonov o varnosti podatkov in zasebnosti. V EU ima GDPR široke posledice za zasebnost, varstvo podatkov in lokacijo podatkov. V ZDA HIPAA ureja zdravstvene informacije, GLBA pa način, kako finančne institucije ravnajo z zasebnimi informacijami strank. V Kaliforniji novi CCPA izboljšuje pravice do zasebnosti in varstvo potrošnikov.
Nekatere zbirke podatkov lahko obdelujejo podatke na način, ki je v skladu z nekaterimi ali vsemi temi predpisi, če upoštevate najboljše prakse. Druge zbirke podatkov imajo pomanjkljivosti, zaradi katerih jih je zelo težko uporabiti za osebne podatke, ne glede na to, kako previdni ste.
Iskreno, to je bil dolg seznam dejavnikov, ki jih je treba upoštevati pri izbiri baze podatkov, verjetno več, kot bi raje upoštevali. Kljub temu je vredno poskusiti odgovoriti na vsa vprašanja po svojih najboljših močeh, preden tvegate, da boste svoj projekt posvetili nečemu, kar se izkaže za neustrezno ali predrago bazo podatkov.
