Existují stovky technologicky náročných recenzí databází, které ale nemusí vždy poskytnout jasný návod k prvnímu kroku při výběru databáze: výběr nejlepšího obecného typu pro konkrétní aplikaci. Všechny databáze nejsou vytvořeny stejně. Každý z nich má specifické silné a slabé stránky. I když je pravda, že existují řešení, která umožní, aby oblíbená databáze fungovala pro většinu projektů, použití těchto triků přidává zbytečnou složitost.
Než začnete uvažovat o konkrétní databázi, věnujte nějaký čas přemýšlení o tom, jaký typ by nejlépe podpořil daný projekt. Otázka jde hlouběji než „SQL vs. NoSQL.“ Přečtěte si další informace o nejběžnějších typech databází, relativních výhodách každého z nich a o tom, jak zjistit, který je nejvhodnější.
Relační systémy pro správu databází (Oracle, MySQL, MS Server, PostgreSQL)
V 70. letech byly vyvinuty relační databáze, aby zvládly rostoucí záplavu vytvářených dat. Mají solidní základní teorii a ovlivnili téměř každý databázový systém, který se dnes používá.
Relační databáze ukládají datové sady jako „vztahy“: tabulky s řádky a sloupci, kde jsou všechny informace uloženy jako hodnota konkrétní buňky. Data v RDBMS jsou spravována pomocí SQL. I když existují různé implementace, SQL je standardizovaný a poskytuje úroveň předvídatelnosti a užitečnosti.
Poté, co se raná záplava prodejců pokusila využít popularitu systému u ne zcela relačních produktů, navrhl tvůrce E.F.Codd soubor pravidel, kterými se musí řídit všechny systémy správy relačních databází. Coddova 12 pravidel se točí kolem zavedení přísných protokolů vnitřní struktury, zajištění spolehlivého vyhledávání požadovaných dat a zabránění strukturálním změnám (alespoň uživateli). Rámec zajistil, aby relační databáze byly konzistentní a spolehlivé dodnes.
Silné stránky
Relační databáze vynikají při zpracování vysoce strukturovaných dat a poskytují podporu pro transakce ACID (Atomicity, Consistency, Isolation a Durability). Data se snadno ukládají a načítají pomocí dotazů SQL. Strukturu lze rychle zvětšit, protože přidávání dat bez úpravy stávajících dat je jednoduché.
Vytvoření omezení toho, k čemu mohou určité typy uživatelů přistupovat nebo je upravovat, je zabudováno do struktury RDBMS. Z tohoto důvodu jsou relační databáze vhodné pro aplikace, které vyžadují víceúrovňový přístup. Zákazníci si například mohli prohlížet své účty, zatímco agenti mohli prohlížet a provádět nezbytné změny.
Slabé stránky
Největší slabinou relačních databází je zrcadlo jejich největší síly. Jak dobře zvládají strukturovaná data, mají s nestrukturovanými daty potíže. Reprezentace entit reálného světa v kontextu je v mezích RDBMS obtížné. „Řezaná“ data musí být znovu sestavena z tabulek do něčeho čitelnějšího a rychlost může být negativně ovlivněna. Opravené schéma na změnu také nereaguje dobře.
S relačními databázemi je cena v úvahu. Mají tendenci být nákladnější na založení a růst. Horizontální škálování nebo škálování přidáním více serverů je obvykle rychlejší a ekonomičtější než vertikální škálování, což zahrnuje přidání více zdrojů na server. Struktura relačních databází však proces komplikuje. Sharding (kde jsou data horizontálně rozdělena a distribuována napříč kolekcí počítačů) je nezbytná pro škálování relační databáze. Shardování relačních databází při zachování souladu s ACID může být výzvou.
Použijte relační databázi pro:
- Situace, kdy je integrita dat naprosto zásadní (tj. Pro finanční aplikace, obranu a bezpečnost a soukromé zdravotní informace)
- Vysoce strukturovaná data
- Automatizace interních procesů
Úložiště dokumentů (MongoDB, Couchbase)
Úložiště dokumentů je nerelační databáze, která ukládá data v dokumentech JSON, BSON nebo XML. Mají flexibilní schéma. Na rozdíl od databází SQL, kde uživatelé musí před vložením dat deklarovat schéma tabulky, úložiště dokumentů nevynucují strukturu dokumentu. Dokumenty mohou obsahovat libovolná požadovaná data. Mají páry klíč – hodnota, ale také vkládají metadata atributů, což usnadňuje dotazování.
Silné stránky
Obchody s dokumenty jsou velmi flexibilní. S polostrukturovanými a nestrukturovanými daty zacházejí dobře. Uživatelé nemusí během nastavování vědět, jaké typy dat se budou ukládat, takže je to dobrá volba, když předem není jasné, jaký typ dat bude přicházet.
Uživatelé mohou vytvořit požadovanou strukturu v konkrétním dokumentu, aniž by to ovlivnilo všechny dokumenty. Schéma lze upravit bez způsobení prostojů, což vede k vysoké dostupnosti. Rychlost zápisu je také obecně rychlá.
Kromě flexibility mají vývojáři rádi obchody s dokumenty, protože je snadné je horizontálně škálovat. Sharding nezbytný pro horizontální škálování je mnohem intuitivnější než u relačních databází, takže úložiště dokumentů se rychle a efektivně rozšiřuje.
Slabé stránky
Databáze dokumentů obětují shodu s ACID kvůli flexibilitě. I když lze dotazovat v dokumentu, není to možné u všech dokumentů.
Databázi dokumentů použijte pro:
- Nestrukturovaná nebo polostrukturovaná data
- Správa obsahu
- Hloubková analýza dat
- Rychlé prototypování
Úložiště klíč – hodnota (Redis, Memcached)
Úložiště klíč-hodnota je typ nerelační databáze, kde je každá hodnota přidružena ke konkrétnímu klíči. Je také známé jako asociativní pole.
„Klíč“ je jedinečný identifikátor přidružený pouze k hodnotě. Klíče mohou být cokoli, co povoluje DBMS. Například v Redis může být key man libovolná binární sekvence až do 512 MB.
„Hodnoty“ jsou uloženy jako objekty BLOB a nepotřebují předdefinované schéma. Mohou mít téměř jakoukoli formu: čísla, řetězce, čítače, JSON, XML, HTML, PHP, binární soubory, obrázky, krátká videa, seznamy a dokonce i další pár klíč – hodnota zapouzdřený v objektu. Některé DBMS umožňují specifikovat datový typ, ale není to povinné.
Silné stránky
Tento styl databáze má mnoho pozitiv. Je neuvěřitelně flexibilní a dokáže snadno zpracovat velmi širokou škálu datových typů. Klávesy se používají k přechodu přímo na hodnotu bez vyhledávání indexů nebo připojení, takže výkon je vysoký. Další výhodou je přenositelnost: úložiště klíč – hodnota lze přesouvat z jednoho systému do druhého bez přepisování kódu. Nakonec jsou vysoce horizontálně škálovatelné a mají celkově nižší provozní náklady.
Slabé stránky
Flexibilita má svou cenu. Je nemožné dotazovat se na hodnoty, protože jsou uloženy jako blob a lze je vrátit pouze jako takové. To ztěžuje vytváření zpráv nebo úpravy částí hodnot. Ne všechny objekty lze snadno modelovat jako páry klíč – hodnota.
Úložiště klíč – hodnota použijte pro:
- Doporučení
- Uživatelské profily a nastavení
- Nestrukturovaná data, jako jsou recenze produktů nebo komentáře na blogu
- Správa relací v měřítku
- Data, ke kterým se bude přistupovat často, ale ne často se aktualizují
Širokoúhlý obchod (Cassandra, HBase)
Úložiště širokého sloupce, nazývaná také úložiště sloupců nebo rozšiřitelná úložiště záznamů, jsou dynamické sloupcově orientované nerelační databáze. Někdy jsou považovány za typ úložiště klíč-hodnota, ale mají také atributy tradičních relačních databází.
V obchodech se širokým sloupcem se místo schémat používá koncept klíčového prostoru. Klíčový prostor zahrnuje rodiny sloupců (podobné tabulkám, ale flexibilnější ve struktuře), z nichž každý obsahuje více řádků s odlišnými sloupci. Každý řádek nemusí mít stejný počet nebo typ sloupce. Časové razítko určuje nejnovější verzi dat.
Silné stránky
Tento typ databáze má některé výhody relačních i nerelačních databází. Zabývá se lépe strukturovanými i polostrukturovanými daty než jiné nerelační databáze a jeho aktualizace je snazší. Ve srovnání s relačními databázemi je horizontálně škálovatelnější a rychlejší v měřítku.
Sloupcové databáze se komprimují lépe než systémy založené na řádcích. Velké datové sady lze také snadno prozkoumat. Například obchody se širokými sloupci jsou zvláště dobré při agregačních dotazech.
Slabé stránky
Zápisy jsou v malém nákladné. Zatímco aktualizace je snadné provádět hromadně, nahrávání a aktualizace jednotlivých záznamů je těžké. Navíc obchody se širokými sloupci jsou při zpracování transakcí pomalejší než relační databáze.
Obchod se širokými sloupci použijte pro:
- Analýza velkých dat, kde je důležitá rychlost
- Skladování dat na velkých datech
- Velké projekty (tento styl databáze není dobrým nástrojem pro průměrné transakční aplikace)
Vyhledávač (Elasticsearch)
Může se zdát divné zahrnout vyhledávací stroje do článku o typech databází. Elasticsearch však zaznamenal v této sféře zvýšenou popularitu, protože vývojáři hledají inovativní způsoby, jak omezit zpoždění vyhledávání. Elastisearch je nerelační řešení pro ukládání a načítání dat založené na dokumentech, které je speciálně uspořádáno a optimalizováno pro ukládání a rychlé načítání dat.
Silné stránky
Elastisearch je velmi škálovatelný. Obsahuje flexibilní schéma a rychlé načítání záznamů s pokročilými možnostmi vyhledávání včetně fulltextového vyhledávání, návrhů a komplexních vyhledávacích výrazů.
Jedna z nejzajímavějších vyhledávacích funkcí vyplývá. Stemming analyzuje kořenovou formu slova a hledá relevantní záznamy, i když je použita jiná forma. Například uživatel, který hledá v databázi zaměstnání výraz „placená zaměstnání“, najde také pozice označené jako „placené“ a „placené“.
Slabé stránky
Elastisearch se používá spíše jako zprostředkující nebo doplňkové úložiště než primární databáze. Má nízkou odolnost a špatné zabezpečení. Neexistuje vrozené ověřování ani řízení přístupu. Elastisearch také nepodporuje transakce.
Použijte vyhledávač jako Elastisearch pro:
- Zlepšení uživatelského dojmu s rychlejšími výsledky vyhledávání
- Protokolování
Závěrečné úvahy
Některé aplikace úhledně zapadají do silných stránek jednoho konkrétního typu databáze, ale u většiny projektů se překrývají dvě nebo více. V těchto případech může být užitečné podívat se, které konkrétní databáze v napadených stylech jsou dobrými kandidáty. Prodejci nabízejí široké spektrum funkcí pro přizpůsobení své databáze individuálním standardům. Některé z nich mohou pomoci vyřešit nejistotu ohledně faktorů, jako je zabezpečení, škálovatelnost a cena.
