Kako odabrati pravu bazu podataka za svoju aplikaciju

Odabir "prave" baze podataka često može biti presudan za uspjeh aplikacije. Umjesto da koristite savjete dobavljača ili koristite bazu podataka jer je već imate, korisno je razmotriti temeljnu svrhu i zahtjeve spremišta podataka.

Ovo su najvažnija pitanja koja trebate postaviti prilikom odabira baze podataka:

  • Koliko podataka očekujete da ćete pohraniti kada aplikacija bude sazrela?
  • S koliko korisnika očekujete istodobno rukovanje pri najvećem opterećenju?
  • Koja dostupnost, skalabilnost, latencija, protok i dosljednost podataka trebaju vašoj aplikaciji?
  • Koliko često će se mijenjati vaše sheme baze podataka?
  • Kakva je zemljopisna raspodjela vaše korisničke populacije?
  • Koji je prirodni "oblik" vaših podataka?
  • Treba li vašoj aplikaciji obrada mrežnih transakcija (OLTP), analitički upiti (OLAP) ili oboje?
  • Kakav omjer čitanja i pisanja očekujete u produkciji?
  • Trebate li zemljopisne upite i / ili upite u cijelom tekstu?
  • Koji su vaši preferirani programski jezici?
  • Imate li proračun? Ako da, hoće li obuhvaćati licence i ugovore o podršci?
  • Postoje li zakonska ograničenja za pohranu podataka?

Proširimo ta pitanja i njihove implikacije.

Koliko podataka ćete pohraniti?

Ako je vaša procjena u gigabajtima ili manje, tada će gotovo svaka baza podataka obrađivati ​​vaše podatke, a baze podataka u memoriji potpuno su izvedive. Još uvijek postoji mnogo opcija baze podataka za obradu podataka u rasponu od terabajta (tisuće gigabajta).

Ako je vaš odgovor u petabajtima (milijunima gigabajta) ili više, tada će vam poslužiti samo nekoliko baza podataka, a morate biti spremni na značajne troškove skladištenja podataka, bilo u kapitalnim izdacima za lokalno skladištenje ili u operativnim troškovima za pohrana u oblaku. Na toj ljestvici možda ćete htjeti složenu pohranu, tako da se upiti o "aktivnim" podacima mogu pokretati u memoriji ili prema lokalnim SSD-ima radi brzine, dok se cjeloviti skup podataka nalazi na prednjim diskovima radi štednje.

Koliko istovremeno korisnika?

Procjena opterećenja mnogih istodobnih korisnika često se tretira kao vježba određivanja veličine poslužitelja koju treba obaviti neposredno prije instaliranja vaše proizvodne baze podataka. Nažalost, mnoge baze podataka jednostavno ne mogu riješiti tisuće korisnika koji traže terabajte ili petabajte podataka zbog problema s skaliranjem.

Procjena istovremenih korisnika mnogo je lakša za bazu podataka koju koriste zaposlenici nego za javnu bazu podataka. Za potonje ćete možda morati imati mogućnost skaliranja na više poslužitelja zbog neočekivanih ili sezonskih opterećenja. Nažalost, ne podržavaju sve baze podataka vodoravno skaliranje bez dugotrajnog ručnog oštrenja velikih tablica.

Koji su vaši '-ility' zahtjevi?

U ovu kategoriju ubrajam dostupnost, skalabilnost, latenciju, propusnost i dosljednost podataka, iako svi pojmovi ne završavaju s "-ility".

Dostupnost je često ključni kriterij za transakcijske baze podataka. Iako ne treba svaka aplikacija raditi 24/7 s 99,999% dostupnosti, neki to rade. Nekoliko baza podataka u oblaku nudi dostupnost s „pet devetki“, sve dok ih pokrećete u više zona dostupnosti. Lokacijske baze podataka obično se mogu konfigurirati za visoku dostupnost izvan planiranih razdoblja održavanja, posebno ako si možete priuštiti postavljanje aktivnog i aktivnog para poslužitelja.

Skalabilnost, posebno horizontalna skalabilnost, u povijesti je bila bolja za NoSQL baze podataka od SQL baza podataka, ali nekoliko SQL baza podataka to sustiže. Dinamičku skalabilnost puno je lakše postići u oblaku. Baze podataka s dobrom skalabilnošću mogu upravljati mnogim istodobnim korisnicima povećavanjem ili smanjivanjem dok protok ne bude dovoljan za opterećenje.

Latencija se odnosi i na vrijeme odziva baze podataka i na vrijeme odziva do kraja aplikacije. Idealno bi bilo da svaka korisnička radnja ima vrijeme odziva ispod sekunde; to često znači da baza podataka treba odgovoriti u manje od 100 milisekundi za svaku jednostavnu transakciju. Analitički upiti često mogu trajati sekunde ili minute. Aplikacije mogu sačuvati vrijeme odziva pokretanjem kompliciranih upita u pozadini.

Propusnost za OLTP bazu podataka obično se mjeri u transakcijama u sekundi. Baze podataka s velikom propusnošću mogu podržati mnoge istodobne korisnike.

Konzistentnost podataka obično je "jaka" za SQL baze podataka, što znači da sva očitavanja vraćaju najnovije podatke. Konzistentnost podataka može biti bilo koja, od "eventualne" do "jake" za baze podataka NoSQL. Eventualna dosljednost nudi manju latenciju, uz rizik čitanja zastarjelih podataka.

Konzistentnost je "C" u svojstvima ACID-a koja su potrebna za valjanost u slučaju pogrešaka, mrežnih particija i nestanka struje. Četiri svojstva kiseline su atomskost, dosljednost, izoliranost i trajnost.

Jesu li vaše sheme baze podataka stabilne?

Ako je malo vjerojatno da će se vaše sheme baza podataka s vremenom značajno promijeniti, a želite da većina polja ima dosljedne tipove od zapisa do zapisa, tada bi SQL baze podataka bio dobar izbor za vas. Inače, NoSQL baze podataka, od kojih neke čak ne podržavaju sheme, mogu biti bolje za vašu aplikaciju. Postoje, međutim, iznimke. Na primjer, Rockset omogućuje SQL upite bez nametanja fiksne sheme ili dosljednih tipova podataka koje uvozi.

Geografska raspodjela korisnika

Kada su korisnici vaše baze podataka širom svijeta, brzina svjetlosti nameće donju granicu kašnjenja baze podataka za udaljene korisnike, osim ako ne pružite dodatne poslužitelje u njihovim regijama. Neke baze podataka omogućuju distribuirane poslužitelje za čitanje i pisanje; drugi nude distribuirane poslužitelje samo za čitanje, a svi zapisi prisiljeni su proći kroz jedan glavni poslužitelj. Zemljopisna raspodjela čini kompromis između dosljednosti i latencije još težim.

Većina baza podataka koje podržavaju globalno distribuirane čvorove i snažnu dosljednost koriste skupine konsenzusa za ubrzanje pisanja bez ozbiljnog ponižavanja dosljednosti, obično koristeći algoritme Paxos (Lamport, 1990) ili Raft (Ongaro i Ousterhout, 2013). Distribuirane NoSQL baze podataka koje su na kraju dosljedne obično koriste nekonsenzusnu, peer-to-peer replikaciju, što može dovesti do sukoba kada dvije replike istovremeno dobivaju upise u isti zapis, sukobi koji se obično rješavaju heuristički.

Oblik podataka

SQL baze podataka klasično pohranjuju jako upisane podatke u pravokutne tablice s retcima i stupcima. Oslanjaju se na definirane relacije između tablica, koriste indekse za ubrzavanje odabranih upita i koriste JOINS za upit više tablica odjednom. Baze podataka dokumenata obično pohranjuju slabo otkucani JSON koji može sadržavati nizove i ugniježđene dokumente. Grafičke baze podataka ili pohranjuju vrhove i rubove, ili trojke ili četverokute. Ostale kategorije baze podataka NoSQL uključuju spremišta ključ / vrijednost i stupčaste trgovine.

Podaci se ponekad generiraju u obliku koji će također raditi za analizu; ponekad nije, i bit će potrebna transformacija. Ponekad se jedna vrsta baze podataka gradi na drugoj. Na primjer, pohrane ključa i vrijednosti mogu biti u osnovi gotovo bilo koje vrste baze podataka.

OLTP, OLAP ili HTAP?

Da biste dešifrirali gornje kratice, pitanje je treba li vašoj aplikaciji baza podataka za transakcije, analizu ili oboje. Potrebne brze transakcije podrazumijevaju brzu brzinu upisa i minimalne indekse. Analiza potrebe podrazumijeva brzu brzinu čitanja i puno indeksa. Hibridni sustavi koriste se raznim trikovima kako bi podržali oba zahtjeva, uključujući primarno skladište transakcija koje sekundarnu analizu sprema kroz replikaciju.

Omjer čitanja / pisanja

Neke baze podataka brže čitaju i postavljaju upite, a druge brže pišu. Kombinacija čitanja i pisanja koju očekujete od svoje aplikacije koristan je broj koji ćete uključiti u kriterije za odabir baze podataka i može voditi vašim naporima uspoređivanja. Optimalni odabir vrste indeksa razlikuje se između aplikacija teških za čitanje (obično B-stablo) i teških programa za pisanje (često stablo stapanja strukturirano u dnevnik, zvano LSM stablo).

Geoprostorni indeksi i upiti

Ako imate geografske ili geometrijske podatke i želite izvršiti učinkovite upite za pronalaženje objekata unutar granice ili objekata unutar zadane udaljenosti od mjesta, trebaju vam drugačiji indeksi nego za tipične relacijske podatke. R-stablo je često preferirani izbor za geoprostorne indekse, ali postoji više od desetak drugih mogućih struktura podataka geoprostornog indeksa. Postoji nekoliko desetaka baza podataka koje podržavaju prostorne podatke; većina podržava neke ili sve standarde Otvorenog geoprostornog konzorcija.

Indeksi i upiti u cijelom tekstu

Slično tome, učinkovito cjelovito pretraživanje tekstualnih polja zahtijeva različite indekse od relacijskih ili geoprostornih podataka. Tipično gradite indeks obrnutog popisa tokeniziranih riječi i pretražujete to kako biste izbjegli skupo skeniranje tablice.

Preferirani programski jezici

Iako većina baza podataka podržava API-je za mnoge programske jezike, preferirani programski jezik u vašoj aplikaciji ponekad može utjecati na vaš izbor baze podataka. Na primjer, JSON je prirodni format podataka za JavaScript, pa ćete možda htjeti odabrati bazu podataka koja podržava tip podataka JSON za JavaScript aplikaciju. Kada koristite jako tipkani programski jezik, možda ćete htjeti odabrati jako tipkanu bazu podataka.

Proračunska ograničenja

Cijene baza podataka variraju od besplatnih do vrlo skupih. Mnoge baze podataka imaju i besplatnu i plaćenu verziju, a ponekad imaju više od jedne razine plaćene ponude, na primjer nude verziju za Enterprise i različita vremena odgovora na uslugu. Osim toga, neke baze podataka dostupne su u oblaku pod uvjetima plaćanja.

Ako odaberete besplatnu bazu podataka otvorenog koda, možda ćete se morati odreći podrške dobavljača. Sve dok imate internu stručnost, to može biti u redu. S druge strane, možda će biti produktivnije da se vaši ljudi koncentriraju na aplikaciju, a administraciju i održavanje baze podataka prepuštaju dobavljačima ili davateljima usluga u oblaku.

Zakonska ograničenja

Postoje mnogi zakoni o sigurnosti podataka i privatnosti. U EU-u GDPR ima široke implikacije na privatnost, zaštitu podataka i mjesto podataka. U SAD-u HIPAA regulira medicinske podatke, a GLBA način na koji financijske institucije postupaju s privatnim podacima kupaca. U Kaliforniji novi CCPA poboljšava prava na privatnost i zaštitu potrošača.

Neke baze podataka mogu obrađivati ​​podatke na način koji je u skladu s nekim ili svim ovim propisima, pod uvjetom da slijedite najbolje prakse. U drugim bazama podataka postoje nedostaci zbog kojih je vrlo teško koristiti ih za osobne podatke, bez obzira na to koliko ste pažljivi.

Iskreno, to je bio dugačak popis čimbenika koje je trebalo uzeti u obzir pri odabiru baze podataka, vjerojatno više nego što biste radije uzeli u obzir. Ipak, vrijedi pokušati odgovoriti na sva pitanja najbolje što možete u svom timu prije nego što riskirate predati svoj projekt nečemu što se ispostavilo kao neadekvatna ili preskupa baza podataka.