Přeskočit na hlavní obsah

NoSQL - Život nepodléhá třetí normální formě

BigData, NoSQL...

Asi každý se již setkal s těmito názvy, které jsou často spojovány se jmény jako je Google, Facebook či Amazon.

Co to vlastně znamená?

Díky rozmachu internetu na běžnou část populace, začalo docházet k exponenciálnímu nárůstu dat, které je třeba uchovávat a zároveň v nich "dolovat". Klasické relační databáze, které díky ACID udržují validní stav dat, se staly nevhodnou variantou. Ano, ani MS SQL a ani Oracle není vhodná databáze na Big Data.

Existuje mnoho důvodů, proč relační databáze není ideální variantou pro větší systémy. Zde je pár příkladů:

1. Vertikální škálování - tedy databázový stroj se nedá donekonečna výkonostně nafukovat
2. Pevná struktura - předem definovaná struktura dat, není pro vetší a rychle se měnící systémy, žádoucí
3. Migrace - Pro změnu struktury je často třeba sofistikovaná migrace přes SQL
4. SQL - dotazování pomocí tohoto jazyku je sice jednoduché, ale zároveň dost omezující

 Co tedy znamená NoSQL?

V první řadě by bylo vhodné říct, že označení NoSQL není zrovna vhodný název. Do této rodiny totiž dnes spadá několik typů databází. Pojďme si je v rychlosti projít:

Objektová databáze
První takzvanou NoSQL databází byla objektová. Šlo o to, že v době dominance objektově orientovaných jazyků (ještě stále to platí, nicméne funkcionální přístup ukazuje lepší koncept), se došlo do bodu, kdy mapování tabulek z relační databáze na objekty může být náročné. Vzniklo mnoho ORM knihoven, napříč všemi objektově orientovanými jazyky (C# - Entity Framework, Java - JPA, apod).  Proto vznikl koncept objektové databáze, která se snažila odbourat dané mapování a zvýšit tak výkon. Bohužel nikdy nedošlo k většímu rozmachu těchto databází a dnes se dá v podstatě říci, že se jedná o upadající koncept.

XML databáze
Označení není asi úplně správné, ale koresponduje přesně s tím, co takový typ databáze dělá. Jedná se o to, že data jsou ukládána v podobě XML dokumentů a jejich schématem je v podstatě XSD. Tento typ databází je vhodný zejména v případě složitých struktur jednotlivých dokumentů. Jistě bude stále existovat segment, kde tento druh databází bude využíván.

Key-Value databáze
Toto označení se vztahuje na databáze, které ukladají svá data do jakési hash mapy. Tedy klíč reprezentuje metadata a hodnota je reálná uložená hodnota. Tyto mapy jsou ukládány v blocích, které je unifikováno vlastním klíčem, který je použit pro přístup k daným datům.
První koncept přinesl Google, který dal světu Hadoop. Ten byl poté uvolněn pod Apache a stal se open source projektem. Pro dotazování se využívá přístup Map-Reduce.

Dokumentová databáze
Tento typ databáze vychází z principu key-value, kdy value reprezentuje dokument, což je struktura, nejčastěji reprezentovaná pomocí JSON formátu. Jednotlivé dokumenty mají svůj klíč v rámci celé kolekce a umožňují vazby na další dokumenty. Nejpopulárnější databází tohoto formátu je MongoDB.

Sloupcová databáze
Vychází z principu NoSQL databází s tím, že se nejvíce podobá relačním databázím. Data jsou reprezentována v tabulce se sloupci. Narozdíl od relační databáze je ovšem možné aby jednotlivé řádky obsahovaly jiné sloupce. Tedy nejedná se o pevnou strukturu v rámci celé tabulky.

Grafová databáze
Tento typ databáze je asi nesložitější a zároveň nejnovějším návrhem. Jedná se o to, že jednotlivá data mohou být propojována na další data pomocí vlastních vazeb. V té chvíli vznikají vazby jako: "uživatel vlastní", "role spadá do", apod. Grafová databáze umožňuje navrhnout strukturu tak, aby skutečně kopírovala reálný svět.

Správný výběr
V rámci projektu, na kterém v současné době pracuji, jsem hledal úložiště, které by mi splňovalo několik kritérií:


  1. Úložiště musí mít horizontální škálování. Tedy bude možné přidáváním dalších virtuálních strojů, zvyšovat výkon.
  2. Dostupnost je nejdůležitější vlastnost. Prominu úložišti dočasnou "zastaralost" dat, ale určitě ne výkyv v dostupnosti.
  3. Bude docházet k častým změnám v modelu aplikace. Rád bych tedy úložiště, ve kterém nebudu muset dělat složité migrace.
  4. Rád bych, aby databáze uměla zpracovávat JSON a to přirozenou formou. Nechci nic slyšet o formátech jako XML, apod. Nežijeme v pravěku.
  5. Jelikož server API je GraphQL, tak bych rád databázi, pro kterou bude tento způsob přirozený.
  6. Musí existovat možnost, jak se na databázi napojit přes Node.JS
Po sepsání základních požadavků, jsem se pustil do výběru hledání. Finále je vcelku jasné. MongoDB. I přes některá svá úskalí je to nejlepší varianta, která se dá zvolit. Splňuje základních 6 bodů, které jsem si dal.

Co MongoDB neumí?
Určitě se nedá říct, že tento typ databáze je spásou na vše. Tak například: "Těžko budete zařizovat bulk operace, jako hromadný insert. Dvoufázový commit sice MongoDB má, ale v tomto stavu se rapidně začně snižovat i výkon. Relace mezi daty si musíte hlídat v aplikaci."
Věcí, které při přechodu z klasických SQL databází člověk musí oželet, je více. Buď se s tím smíříte a nebo se vrátíte :)

Závěr
Většině databázistům jistě budou vadit dané nevýhody, které sebou tento princip přináší. Nicméně, kdo kdy navrhnul strukturu v relační databázi tak, aby mohl říci: "Jsem schopen obhospodařit jakýkoli požadavek na má data."? Odpověď je nikdo. A důvodem budiž třeba to, že život nepodléhá třetí normální formě.

Uvedu příklad, který jsem si vypůjčil z knihy "Big Data a NoSQL databáze":
Představte si situaci, že vlastníte stackoverflow.com, kde uživatelé pokládají otázky. V klasické relační databázi byste nejspíše měli tabulky jako otázka, uživatel. Uživatel by například obsahoval sloupec město, což by byla jeho aktuální adresa, kde bydlí. Samozřejmě by se uživatel mohl přestěhovat a tím by se změnilo i jeho bydliště. Vazba mezi uživatelem a otázkou by byla 1:N. Tady je zatím vše v pořádku, do doby, než dojde k požadavku, abyste zjistili, ze kterého města bylo pokládáno nejvíce otázek. V té chvíli by samotný návrh nebyl schopen obhospodařit tento požadavek. Sice jsme strukturu navrhli správně, nicménéně jsme si neuvědomili, že svět se nechová podle normálních forem. Asi by nám nezbylo nic jiného, než u změny bydliště si v čase uchovávat i změnu. Pak by nejspíše existovala tabulka bydliště, která by v podstatě musela udžovat změnu v čase.

Líbí se mi tento příklad. Ukazuje přesně to, že dopředu nikdy nemůžeme vědět, jaký bude požadavek na naše data. V dokumentové databázi se často data ukládají tak, že vazby jsou sice možné, ale nejsou hlavním stavebním kamenem. Jinak řečeno, v kolekci otázka by se uložila sice reference na uživatele, ale současně s tím i aktuální stav uživatele, tedy jeho jméno, adresa, apod. Ano porušili jsme sice normální formu, ale zároveň jsme umožnili vetší flexibilitu ohledně dolování dat. Navíc jsme se víc přiblížili realitě, tedy tomu, že v daném čase se uživatelka ještě nevdala a nezměnila příjmení a Franta ještě nebydlel v Praze, ale v Brně :)

Komentáře

Populární příspěvky z tohoto blogu

Jak si v IT vydělat hodně peněz?

Na začátek by bylo dobré, abych objasnil samotný titulek, který může na někoho působit jako červený hadr. Článek nebude o obecných pravidlech, ale bude vyprávět můj vlastní příběh, na kterém vám zkusím ukázat, jak se dá docílit úspěchu, či alespoň správně nastartovat svojí vlastní kariéru v IT.

I když se z názvu článku dá dedukovat, že se vše bude točit kolem peněz, není tomu tak. Alespoň ze dvou třetin určitě ne. Ale to už předbíhám, pojďme to raději vzít hezky popořadě...

Kdybychom měli mluvit o roce 2017 jako o přelomové době, nejspíše to nebude pravda. I když pro někoho to může být rok plný úspěchů a štěstí v podobě narození zdravých dětí, svatby či první velké lásky, tak z pohledu lidstva se jedná o rok, který jen kopíruje předešlé a v oblasti technologií nás posouvá stejným tempem jako rok předtím.

Jsem naprosto přesvědčen o tom, že i když se současná doba tak nenazývá, tak prožíváme dobu, která jednou bude označena za revoluční, a to zejména díky vynálezu internetu, který je st…

Jak by se firmy neměly chovat k programátorům?

Každý, kdo pracuje v IT oboru, se jistě již setkal s různými „geniálními nápady“, od kterých si firma slibovala zlepšení produktivity či snížení nákladů. Ať už je to zavedení agilních principů, striktní kontrola práce či zavedení nové a skvělé metodiky, o které si „šéf“ přečetl včera na internetu. Jsou z toho skutečně tak nadšení i samotní vývojáři? A bude nový nápad fungovat?
K napsání tohoto článku mě navedly různé programátorské diskuze, kde si lidé stěžovali na firmu, kde pracují. Příklady, které zde uvedu, jsou z reálné praxe. Ať už jsem je zažil jako řadový programátor, či jako šéf týmu.
I když je poptávka po programátorech tak vysoká, že Vás headhunteři nahánějí i ve chvílích, kdy o to opravdu nestojíte, tak i přes to je mnoho lidí, kteří se bojí opustit svoje současné zaměstnání.
Čeho se nejčastěji bojíme? Je to samozřejmě nejistota, kterou si často omlouváme větami jako: „Tady mám své pohodlí, co když to jinde mít nebudu?“ nebo „I když mě to v práci štve a nebaví, tak mě ale…

Jak jsem technologicky postavil startup

Tento příběh pojednává o technologiích, nástrojích a vůbec o všem, co jsem potřeboval k tomu, abych byl schopen, postavit startup na zelené louce.

Každý správný příběh začíná stejně: "Jednou jsem...."

Kapitola první: Nápad
Jednou jsem se setkal s člověkem, který měl nápad na produkt, který se v průmyslu zatím nevyskytuje. I přes prvotní skepsi, kdy jsem si říkal: "Tohle už přeci dávno v průmyslu existuje, ne?", jsem došel ke zjištění, že nikoli.

Tím jsem se dostal ke svému prvnímu poučení. Průmysl je technologicky dost zabržděný. Osobně se domnívám, že těch důvodů, proč tomu tak je, je několik. Za prvé je to fakt, že většina lidí, kteří se pohybují v tomto odvětví jsou často konzervativní a za správné považují pouze léty osvědčené věci. Druhým důvodem je to, že jakákoli změna znamená riziko. Ať už z pohledu finanční ztráty tak i z pohledu stability výroby. No a třetím a nejzásadnějším důvodem je to, že ač zde máme spousty technologických vymožeností, narážíme na to,…