Programování

Jak vybrat správnou databázi pro vaši aplikaci

Výběr „správné“ databáze může být často zásadní pro úspěch aplikace. Spíše než radit se s prodejci nebo používat databázi, protože ji již máte, je užitečné vzít v úvahu základní účel a požadavky úložiště dat.

Při výběru databáze si musíte položit následující otázky:

  • Kolik dat očekáváte, že uložíte, až bude aplikace zralá?
  • Kolik uživatelů očekáváte, že zvládnete současně při špičkovém zatížení?
  • Jakou dostupnost, škálovatelnost, latenci, propustnost a konzistenci dat vaše aplikace potřebuje?
  • Jak často se vaše databázová schémata změní?
  • Jaké je geografické rozložení populace uživatelů?
  • Jaký je přirozený „tvar“ vašich dat?
  • Vyžaduje vaše aplikace online zpracování transakcí (OLTP), analytické dotazy (OLAP) nebo obojí?
  • Jaký poměr čtení a zápisu očekáváte ve výrobě?
  • Potřebujete geografické dotazy nebo fulltextové dotazy?
  • Jaké jsou vaše preferované programovací jazyky?
  • Máte rozpočet? Pokud ano, pokryje to licence a smlouvy o podpoře?
  • Existují právní omezení vašeho ukládání dat?

Pojďme se na tyto otázky a jejich důsledky zaměřit.

Kolik dat uložíte?

Pokud je váš odhad v gigabajtech nebo méně, bude s vašimi daty pracovat téměř libovolná databáze a databáze v paměti jsou zcela proveditelné. Stále existuje mnoho databázových možností pro zpracování dat v rozsahu terabajtů (tisíce gigabajtů).

Pokud je vaše odpověď v petabajtech (miliony gigabajtů) nebo více, pak vám dobře poslouží pouze několik databází a musíte být připraveni na značné náklady na ukládání dat, ať už v kapitálových výdajích za místní úložiště nebo v provozních výdajích pro cloudové úložiště. V tomto měřítku možná budete chtít víceúrovňové úložiště, aby dotazy na „živá“ data mohly běžet v paměti nebo proti místním jednotkám SSD kvůli rychlosti, zatímco celá datová sada je umístěna na rotujících discích za účelem úspory.

Kolik současných uživatelů?

Odhad zátěže od mnoha současných uživatelů se často považuje za cvičení dimenzování serveru, které je třeba provést těsně před instalací vaší produkční databáze. Mnoho databází bohužel kvůli problémům se škálováním nedokáže zpracovat tisíce uživatelů dotazujících se na terabajty nebo petabajty dat.

Odhad současných uživatelů je mnohem jednodušší pro databázi používanou zaměstnanci než pro veřejnou databázi. V případě druhého z nich budete možná muset mít možnost škálování na více serverů kvůli neočekávaným nebo sezónním načtením. Bohužel ne všechny databáze podporují horizontální škálování bez časově náročného ručního dělení velkých tabulek.

Jaké jsou vaše požadavky na „schopnost“?

Do této kategorie zahrnuji dostupnost, škálovatelnost, latenci, propustnost a konzistenci dat, i když ne všechny termíny končí „-ility“.

Dostupnost je často klíčovým kritériem pro transakční databáze. I když ne každá aplikace musí běžet 24/7 s dostupností 99,999%, některé ano. Několik cloudových databází nabízí dostupnost „pěti devíti“, pokud je provozujete ve více zónách dostupnosti. Místní databáze lze obvykle nakonfigurovat pro vysokou dostupnost mimo plánované období údržby, zvláště pokud si můžete dovolit nastavit pár aktivních aktivních serverů.

Škálovatelnost, zejména horizontální škálovatelnost, byla pro databáze NoSQL historicky lepší než databáze SQL, ale několik databází SQL to dohánělo. Dynamické škálovatelnosti je mnohem snazší dosáhnout v cloudu. Databáze s dobrou škálovatelností zvládnou mnoho současných uživatelů škálováním nahoru nebo ven, dokud nebude propustnost dostatečná pro zatížení.

Latence označuje jak dobu odezvy databáze, tak dobu odezvy mezi aplikacemi. V ideálním případě bude mít každá akce uživatele dobu odezvy pod sekundu; což často znamená, že databáze musí reagovat na každou jednoduchou transakci za méně než 100 milisekund. Analytické dotazy mohou často trvat sekundy nebo minuty. Aplikace mohou zachovat dobu odezvy spuštěním komplikovaných dotazů na pozadí.

Propustnost pro databázi OLTP se obvykle měří v transakcích za sekundu. Databáze s vysokou propustností mohou podporovat mnoho současných uživatelů.

Konzistence dat je pro databáze SQL obvykle „silná“, což znamená, že všechna čtení vracejí nejnovější data. Konzistence dat může být pro databáze NoSQL cokoli od „eventuální“ po „silná“. Případná konzistence nabízí nižší latenci s rizikem čtení zastaralých dat.

Konzistence je „C“ ve vlastnostech ACID požadovaných pro platnost v případě chyb, síťových oddílů a výpadků napájení. Čtyři vlastnosti KYSELIN jsou Atomicita, Konzistence, Izolace a Trvanlivost.

Jsou vaše databázová schémata stabilní?

Pokud je nepravděpodobné, že se vaše databázová schémata v průběhu času významně změní, a chcete, aby většina polí měla konzistentní typy od záznamu k záznamu, pak by pro vás byla dobrá databáze SQL. Jinak by pro vaši aplikaci mohly být lepší databáze NoSQL, z nichž některé nepodporují ani schémata. Existují však výjimky. Například Rockset umožňuje dotazy SQL bez uložení pevného schématu nebo konzistentních typů na data, která importuje.

Geografické rozložení uživatelů

Když jsou uživatelé vaší databáze po celém světě, rychlost světla ukládá nižší limit latence databáze pro vzdálené uživatele, pokud neposkytnete další servery v jejich oblastech. Některé databáze umožňují distribuované servery pro čtení a zápis; jiné nabízejí distribuované servery jen pro čtení, přičemž všechny zápisy jsou nuceny projít jedním hlavním serverem. Geografická distribuce ještě více ztěžuje kompromis mezi konzistencí a latencí.

Většina databází, které podporují globálně distribuované uzly a silnou konzistenci, používají konsenzuální skupiny k urychlení zápisů bez vážného zhoršení konzistence, obvykle pomocí algoritmů Paxos (Lamport, 1990) nebo Raft (Ongaro a Ousterhout, 2013). Distribuované databáze NoSQL, které jsou nakonec konzistentní, obvykle používají nekonsenzovanou replikaci typu peer-to-peer, což může vést ke konfliktům, když dvě repliky obdrží souběžné zápisy do stejného záznamu, konflikty, které jsou obvykle vyřešeny heuristicky.

Tvar dat

Databáze SQL klasicky ukládají silně zadaná data do obdélníkových tabulek s řádky a sloupci. Spoléhají na definované vztahy mezi tabulkami, používají indexy k urychlení vybraných dotazů a pomocí JOINS dotazují více tabulek najednou. Databáze dokumentů obvykle ukládají JSON se slabým typem, který může obsahovat pole a vnořené dokumenty. Databáze grafů buď ukládají vrcholy a hrany, nebo trojice nebo čtyřkolky. Mezi další kategorie databází NoSQL patří páry klíč – hodnota a sloupcové úložiště.

Někdy se data generují ve tvaru, který bude fungovat i pro analýzu; někdy tomu tak není a bude nutná transformace. Někdy je jeden druh databáze postaven na jiném. Například obchody klíč – hodnota mohou být základem téměř jakéhokoli druhu databáze.

OLTP, OLAP nebo HTAP?

Chcete-li dešifrovat výše uvedená zkratka, je otázkou, zda vaše aplikace potřebuje databázi pro transakce, analýzu nebo obojí. Vyžadování rychlých transakcí znamená rychlou rychlost zápisu a minimální indexy. Analýza potřeb vyžaduje rychlou rychlost čtení a spoustu indexů. Hybridní systémy používají různé triky k podpoře obou požadavků, včetně toho, že primární transakční úložiště napájí sekundární analytické úložiště prostřednictvím replikace.

Poměr čtení / zápisu

Některé databáze jsou rychlejší při čtení a dotazech a jiné jsou rychlejší při zápisech. Směs čtení a zápisů, kterou od své aplikace očekáváte, je užitečné číslo, které je třeba zahrnout do kritérií pro výběr databáze, a může vám posloužit jako vodítko pro snahy o srovnávání. Optimální volba typu indexu se liší mezi aplikacemi těžkými pro čtení (obvykle B-strom) a aplikacemi těžkými pro zápis (často logicky strukturovaný merge strom, aka LSM strom).

Geoprostorové indexy a dotazy

Pokud máte geografická nebo geometrická data a chcete provádět efektivní dotazy k vyhledání objektů uvnitř hranice nebo objektů v dané vzdálenosti od místa, potřebujete jiné indexy, než byste použili pro běžná relační data. R-strom je často preferovanou volbou pro geoprostorové indexy, ale existuje více než tucet dalších možných geoprostorových datových struktur indexu. Existuje několik desítek databází, které podporují prostorová data; většina podporuje některé nebo všechny standardy Open Geospatial Consortium.

Fulltextové indexy a dotazy

Efektivní fulltextové vyhledávání textových polí podobně vyžaduje jiné indexy než relační nebo geoprostorová data. Obvykle vytvoříte invertovaný seznam indexů tokenizovaných slov a prohledáte je, abyste se vyhnuli nákladnému prohledávání tabulky.

Preferované programovací jazyky

Zatímco většina databází podporuje API pro mnoho programovacích jazyků, preferovaný programovací jazyk ve vaší aplikaci může někdy ovlivnit váš výběr databáze. Například JSON je přirozený datový formát pro JavaScript, takže možná budete chtít vybrat databázi, která podporuje datový typ JSON pro aplikaci JavaScript. Pokud používáte programovací jazyk se silným typem, můžete zvolit databázi se silným typem.

Rozpočtová omezení

Ceny databází se pohybují od bezplatných po velmi drahé. Mnoho databází má bezplatnou i placenou verzi a někdy má více než jednu úroveň placené nabídky, například nabízí verzi Enterprise a různé doby odezvy služby. Některé databáze jsou navíc k dispozici v cloudu za podmínek pay-as-you-go.

Pokud si vyberete bezplatnou databázi s otevřeným zdrojovým kódem, možná se budete muset vzdát podpory dodavatele. Pokud máte interní odborné znalosti, může to být v pořádku. Na druhou stranu může být pro vaše lidi produktivnější soustředit se na aplikaci a správu a údržbu databáze nechat na prodejcích nebo poskytovatelích cloudu.

Zákonná omezení

Existuje mnoho zákonů o zabezpečení dat a soukromí. V EU má GDPR široké dopady na soukromí, ochranu dat a umístění dat. V USA reguluje HIPAA lékařské informace a GLBA reguluje způsob, jakým finanční instituce nakládají se soukromými informacemi zákazníků. V Kalifornii nová CCPA zvyšuje práva na soukromí a ochranu spotřebitele.

Některé databáze jsou schopné zpracovávat data způsobem, který je v souladu s některými nebo všemi těmito předpisy, pokud budete postupovat podle osvědčených postupů. Jiné databáze mají nedostatky, díky nimž je velmi obtížné je použít k osobním identifikačním informacím, bez ohledu na to, jak jste opatrní.

Upřímně řečeno, to byl dlouhý seznam faktorů, které je třeba vzít v úvahu při výběru databáze, pravděpodobně více, než byste raději zvážili. Přesto však stojí za to pokusit se odpovědět na všechny otázky nejlépe podle schopností vašeho týmu, než riskujete, že svůj projekt zadáte do databáze, která se ukáže jako neadekvátní nebo nadměrně drahá.

$config[zx-auto] not found$config[zx-overlay] not found