Výber „správnej“ databázy môže byť často rozhodujúci pre úspech aplikácie. Namiesto toho, aby ste sa riadili radami predajcov alebo využívali databázu, pretože už ju náhodou máte, je užitočné vziať do úvahy základný účel a požiadavky úložiska údajov.
Toto sú najdôležitejšie otázky, ktoré si musíte položiť pri výbere databázy:
- Koľko dát sa podľa očakávania uložíte, keď bude aplikácia vyspelá?
- Koľko používateľov očakávaš, že zvládnu súčasne pri špičkovej záťaži?
- Akú dostupnosť, škálovateľnosť, latenciu, priepustnosť a konzistenciu údajov potrebuje vaša aplikácia?
- Ako často sa budú meniť vaše databázové schémy?
- Aké je geografické rozdelenie vašej populácie používateľov?
- Aký je prirodzený „tvar“ vašich údajov?
- Potrebuje vaša aplikácia online spracovanie transakcií (OLTP), analytické dotazy (OLAP) alebo oboje?
- Aký pomer čítaní k zápisom očakávate vo výrobe?
- Potrebujete geografické alebo fulltextové dotazy?
- Aké sú vaše preferované programovacie jazyky?
- Máte rozpočet? Ak áno, bude sa to týkať licencií a zmlúv o podpore?
- Existujú právne obmedzenia týkajúce sa ukladania vašich údajov?
Rozoberme tieto otázky a ich dôsledky.
Koľko dát uložíte?
Ak je váš odhad v gigabajtoch alebo menej, bude s vašimi údajmi narábať takmer ľubovoľná databáza a databázy v pamäti sú úplne možné. Stále existuje veľa databázových možností na spracovanie údajov v rozsahu terabajtov (tisíce gigabajtov).
Ak je vaša odpoveď v petabajtoch (milióny gigabajtov) alebo viac, potom vám bude slúžiť iba niekoľko databáz a musíte byť pripravení na značné náklady na ukladanie údajov, či už v kapitálových výdavkoch na lokálne úložisko alebo v prevádzkových výdavkoch na. cloud-ové úložisko. V takom rozsahu možno budete chcieť viacúrovňové úložisko, aby dotazy na „živé“ dáta mohli bežať v pamäti alebo proti miestnym jednotkám SSD kvôli rýchlosti, zatiaľ čo celá množina dát je uložená na rotujúcich diskoch kvôli úspornosti.
Koľko súčasných používateľov?
Odhad záťaže od mnohých súčasných používateľov sa často považuje za cvičenie veľkosti servera, ktoré sa musí vykonať tesne pred inštaláciou vašej produkčnej databázy. Mnoho databáz bohužiaľ kvôli problémom s mierkou nedokáže spracovať tisíce používateľov dopytujúcich terabajty alebo petabajty dát.
Odhad súčasných používateľov je pre databázu používanú zamestnancami oveľa ľahší ako pre verejnú databázu. V prípade týchto serverov možno budete musieť mať možnosť škálovať na viac serverov kvôli neočakávaným alebo sezónnym zaťaženiam. Nie všetky databázy, bohužiaľ, podporujú horizontálne škálovanie bez časovo náročného manuálneho rozdelenia veľkých tabuliek.
Aké sú vaše požiadavky na „schopnosť“?
Do tejto kategórie zaraďujem dostupnosť, škálovateľnosť, latenciu, priepustnosť a konzistenciu údajov, aj keď nie všetky pojmy končia výrazom „-ility“.
Dostupnosť je často kľúčovým kritériom transakčných databáz. Aj keď nie každá aplikácia musí bežať nepretržite s dostupnosťou 99,999%, niektoré tak fungujú. Niekoľko cloudových databáz ponúka dostupnosť „päť deviatich“, pokiaľ ich prevádzkujete vo viacerých zónach dostupnosti. Miestne databázy možno zvyčajne nakonfigurovať na vysokú dostupnosť mimo plánovaných období údržby, najmä ak si môžete dovoliť nastaviť dvojicu aktívnych serverov.
Škálovateľnosť, najmä horizontálna škálovateľnosť, bola historicky pre databázy NoSQL lepšia ako pre databázy SQL, ale niekoľko databáz SQL ich doháňa. Dynamická škálovateľnosť je v cloude oveľa ľahšia. Databázy s dobrou škálovateľnosťou zvládnu mnoho súčasných používateľov zväčšením alebo zmenšením, kým nie je kapacita dostatočná na načítanie.
Latencia sa vzťahuje na čas odozvy databázy aj na čas úplnej odozvy aplikácie. V ideálnom prípade bude mať každá akcia používateľa čas odozvy menej ako jednu sekundu; čo často znamená potrebu databázy odpovedať za menej ako 100 milisekúnd pri každej jednoduchej transakcii. Analytické dotazy môžu často trvať sekundy alebo minúty. Aplikácie môžu udržiavať čas odozvy spúšťaním komplikovaných dotazov na pozadí.
Výkonnosť pre databázu OLTP sa zvyčajne meria v transakciách za sekundu. Databázy s vysokou priepustnosťou môžu podporovať mnoho súčasných používateľov.
Konzistencia údajov je pre databázy SQL zvyčajne „silná“, čo znamená, že všetky načítania vrátia najnovšie údaje. Konzistencia údajov môže byť pre databázy NoSQL čokoľvek od „prípadnej“ po „silná“. Prípadná konzistencia ponúka nižšiu latenciu pri riziku čítania zastaraných údajov.
Konzistencia je „C“ vo vlastnostiach ACID požadovaných na platnosť v prípade chýb, sieťových oddielov a výpadkov napájania. Štyri vlastnosti KYSELINY sú Atomicita, Konzistencia, Izolácia a Trvanlivosť.
Sú vaše databázové schémy stabilné?
Ak je nepravdepodobné, že sa vaše databázové schémy v priebehu času významne zmenia a chcete, aby väčšina polí mala konzistentné typy od záznamu k záznamu, potom by pre vás boli dobrou voľbou databázy SQL. V opačnom prípade môžu byť pre vašu aplikáciu lepšie databázy NoSQL, z ktorých niektoré nepodporujú ani schémy. Existujú však výnimky. Napríklad Rockset umožňuje dotazy SQL bez zavedenia pevnej schémy alebo konzistentných typov na dáta, ktoré importuje.
Geografické rozdelenie používateľov
Keď sú vaši používatelia databázy na celom svete, rýchlosť svetla ukladá nižší limit latencie databázy pre vzdialených používateľov, pokiaľ neposkytnete ďalšie servery v ich oblastiach. Niektoré databázy umožňujú distribuované servery na čítanie a zápis; iné ponúkajú distribuované servery iba na čítanie, pričom všetky zápisy sú nútené prechádzať cez jeden hlavný server. Geografická distribúcia ešte viac sťažuje kompromis medzi konzistenciou a latenciou.
Väčšina databáz, ktoré podporujú globálne distribuované uzly a silnú konzistenciu, používajú konsenzuálne skupiny na urýchlenie zápisov bez vážneho zhoršenia konzistencie, zvyčajne pomocou algoritmov Paxos (Lamport, 1990) alebo Raft (Ongaro a Ousterhout, 2013). Distribuované databázy NoSQL, ktoré sú nakoniec konzistentné, zvyčajne používajú nekonzenzovanú replikáciu typu peer-to-peer, čo môže viesť ku konfliktom, keď dve repliky prijímajú súbežné zápisy do rovnakého záznamu, konflikty sa zvyčajne riešia heuristicky.
Tvar údajov
Databázy SQL klasicky ukladajú silne zadané údaje do obdĺžnikových tabuliek s riadkami a stĺpcami. Spoliehajú sa na definované vzťahy medzi tabuľkami, na zrýchlenie vybraných dotazov používajú indexy a na spojenie viacerých tabuliek naraz používajú JOINS. V databázach dokumentov sa zvyčajne ukladajú súbory JSON slabého typu, ktoré môžu obsahovať polia a vnorené dokumenty. Databázy grafov ukladajú buď vrcholy a hrany, alebo trojice alebo štvorkolky. Medzi ďalšie kategórie databáz NoSQL patria páry kľúč - hodnota a stĺpcové obchody.
Niekedy sa údaje generujú v tvare, ktorý bude slúžiť aj na analýzu; niekedy to tak nie je a bude potrebná transformácia. Niekedy je jeden druh databázy postavený na inom. Napríklad obchody s kľúčom a hodnotou môžu byť základom pre takmer akýkoľvek druh databázy.
OLTP, OLAP alebo HTAP?
Ak chcete dešifrovať vyššie uvedené skratky, je potrebné si uvedomiť, či vaša aplikácia potrebuje databázu na transakcie, analýzu alebo oboje. Potrebné rýchle transakcie znamenajú vysokú rýchlosť zápisu a minimálne indexy. Analýza, ktorá vyžaduje, znamená vysokú rýchlosť čítania a veľa indexov. Hybridné systémy používajú rôzne triky na podporu oboch požiadaviek, vrátane primárneho transakčného úložiska, ktoré zásobuje sekundárne úložisko analýz prostredníctvom replikácie.
Pomer čítania a zápisu
Niektoré databázy sú rýchlejšie pri čítaní a dotazoch a iné pri zápisoch. Kombinácia čítaní a zápisov, ktorú od svojej aplikácie očakávate, je užitočné číslo, ktoré môžete zahrnúť do kritérií výberu databázy, a môže vám slúžiť ako pomôcka pri testovaní. Optimálna voľba typu indexu sa líši medzi aplikáciami náročnými na čítanie (zvyčajne B-strom) a aplikáciami náročnými na zápis (často logicky štruktúrovaný merge-strom, aka LSM strom).
Geopriestorové indexy a dotazy
Ak máte geografické alebo geometrické údaje a chcete vykonať efektívne dotazy na vyhľadanie objektov vo vnútri hranice alebo objektov v danej vzdialenosti od miesta, potrebujete iné indexy, ako by ste použili pre typické relačné údaje. Strom R je často preferovanou voľbou pre geopriestorové indexy, ale existuje viac ako tucet ďalších možných dátových štruktúr geopriestorového indexu. Existuje niekoľko desiatok databáz, ktoré podporujú priestorové údaje; väčšina podporuje niektoré alebo všetky štandardy Open Geospatial Consortium.
Fulltextové indexy a dotazy
Efektívne fulltextové vyhľadávanie textových polí vyžaduje iné indexy ako relačné alebo geopriestorové údaje. Spravidla vytvoríte inverzný zoznam indexov tokenizovaných slov a vyhľadáte ich tak, aby ste sa vyhli nákladnému skenovaniu tabuľky.
Preferované programovacie jazyky
Zatiaľ čo väčšina databáz podporuje API pre mnoho programovacích jazykov, preferovaný programovací jazyk vo vašej aplikácii môže niekedy ovplyvniť výber databázy. Napríklad JSON je prirodzený dátový formát pre JavaScript, takže možno budete chcieť zvoliť databázu, ktorá podporuje dátový typ JSON pre aplikáciu JavaScript. Ak používate programovací jazyk so silným typom písma, môžete si zvoliť databázu so silným typom písma.
Rozpočtové obmedzenia
Cena databáz sa pohybuje od bezplatných po veľmi drahé. Mnoho databáz má bezplatnú aj platenú verziu a niekedy má viac ako jednu úroveň platenej ponuky, napríklad ponúka verziu Enterprise a rôzne časy odozvy služby. Niektoré databázy sú navyše k dispozícii v cloude za priebežných podmienok.
Ak si vyberiete bezplatnú otvorenú databázu zdrojov, možno sa budete musieť vzdať podpory dodávateľov. Pokiaľ máte interné odborné znalosti, môže to byť v poriadku. Na druhej strane môže byť pre vašich zamestnancov produktívnejšie sústrediť sa na aplikáciu a správu a údržbu databáz prenechať predajcom alebo poskytovateľom cloudu.
Zákonné obmedzenia
Existuje veľa zákonov o bezpečnosti a ochrane osobných údajov. V EÚ má GDPR rozsiahle dôsledky na súkromie, ochranu údajov a umiestnenie údajov. V USA reguluje HIPAA lekárske informácie a GLBA reguluje spôsob, akým finančné inštitúcie narábajú so súkromnými informáciami zákazníkov. V Kalifornii nová CCPA zvyšuje práva na súkromie a ochranu spotrebiteľa.
Niektoré databázy sú schopné zaobchádzať s údajmi spôsobom, ktorý je v súlade s niektorými alebo so všetkými týmito predpismi, pokiaľ dodržiavate osvedčené postupy. Ostatné databázy majú chyby, ktoré veľmi sťažujú ich použitie na účely identifikácie osôb bez ohľadu na to, ako ste opatrní.
Úprimne povedané, pri výbere databázy to bol dlhý zoznam faktorov, ktoré by ste mali brať do úvahy, pravdepodobne viac, ako by ste radšej zvážili. Napriek tomu stojí za to pokúsiť sa odpovedať na všetky otázky podľa svojich najlepších schopností. Skôr ako riskujete, že svoj projekt zadáte do databázy, ktorá sa ukáže ako neprimeraná alebo nadmerne drahá.
