Written by Ukládání strukturovaných dat bylo po tři dekády doménou relačních databázových systémů (RDBMS). Proč je nahradit za NoSQL, které stojí na zcela jiných principech?
NoSQL vzniklo, protože relační DB neobstály v některých scénářích
Na stránkách cloudsvet.cz už jsem shrnoval CAP teorém a ACID vlastnosti databázových systémů. Relační DB přináší ACID, tedy transakční konzistenci, která vede na budování těchto systémů jako CA (tedy ať běží na jediném superserveru s hardwarovým řešením redundance všeho možného). Před asi deseti lety se začaly objevovat situace a požadavky, kdy to naráží na technické limity.
- Nechci hned na začátku rozhodnout, jakou strukturu mají moje data mít – chci schopnost přidat sloupec nebo dokonce vnořit objekt (to v relační DB vede na vytvoření nové tabulky s relačními ID z jiné tabulky) snadno a rychle a třeba jen pro jeden konkrétní řádek (tedy každý řádek může mít úplně jiné sloupce – nechci mít hodnoty NULL apod.)
- Například Google vyhledávač potřebuje pracovat s tabulkou, která má miliardy řádků na miliony sloupců a to s RDBMS prostě nefunguje
- Chtěl bych data rozprostřít přes vícero serverů, takže místo drahého velkého chci víc levných malých
- Rád bych řešil situace, kdy z důvodu latence nebo dostupnosti chci mít data k dispozici na různých lokalitách
- Nechci mít jen preferenci konzistence na úkor všeho ostatního, rád bych si sám zvolil svojí strategii ideálně v celé škále variant mezi dvěma póly
- Chci optimalizovat systém na práci s objekty, které odpovídají reálnému světu – například pro objednávku chci mít tuto uloženu jako celek, ne rozřezanou na záznamy v mnoha tabulkách jako jsou osoba, faktura, zboží, skladové zásoby apod.
- Požaduji schopnost extrémně rychle přistoupit ke konkrétnímu záznamu, když vím, co chci (znám ID) – bez ohledu na to, kolik záznamů v systému je
To jsou aspekty, ve kterých NoSQL excelují – a není jich málo. Existuje hned několik kategorií s odlišným přístupem k věci a něco přes sto známých systému (tedy obrovská míra inovací a volby v tomto prostoru). A to nejzajímavější? Naprostá většina je postavena na open source – nejste odkázáni na jediného dodavatele, nekupujete databázi samotnou, ale pokud něco, tak konzultace, zkušenosti, automatizaci či služby. Přestože možností je spousty, na stránkách cloudsvet.cz se zaměříme na ty nejpopulárnější jako jsou MongoDB, Cassandra, Redis, CouchDB nebo Neo4J.
Typy NoSQL a jejich využití
Key-Value store
Tyto systémy jsou extrémně jednoduché – data máte vždy uložena v páru, kdy první je klíč a druhý hodnota. Když se zeptáte co je uloženo pod nějakým klíčem, dostanete odpověď – například jakou velikost boty (to je value) má Tomáš (to je key). To je všechno. Nic víc. Nemůžete se ptát podle hodnoty (kdo má botu tři-a-čtyřicítítku?) ani shlukovat klíče podle nějaké příslušnosti ke skupině apod. Jako value může být nejen číslo nebo řetězec, ale také třeba BLOB (tedy bytová sekvence, třeba obrázek).
Perfektní využití najdete zejména v nasazení jako in-memoring KVS (key-value store), velmi typicky jako cache. Nejčastější implementace je asociativní pamětí na bázi hash – tedy z klíče se hash funkcí (pravděpodobně s modulo výsledku) získá adresa, ze které se už jen přečte hodnota – žádné hledání.. Mým nejoblíbenějším zástupcem v této kategorii je Redis a ještě o něm na cloudvet.cz uslyšíte. Ted nejen umožňuje implementaci in-memory, ale také může data odlévat na disk (není míněno jako náhrada jiných typů databází, probíhá co pár vteřin), ale hlavně podporuje distribuovaný clustering (Redis dokáže běžet na několika nodech a dohromady vytváří jeden adresní prostor). Mezi další patří například jednodušší memcache.
Document
Vezměte si znovu Key, které bude nějaké generované ID, ale hodnota bude ve skutečnosti složená struktura, dokument. Nepředstavujte si to jako nějaký text ve Wordu, spíše půjde o JSON/BSON (pokud neznáte jde v zásadě o něco podobného jako xml). Pakliže dokument bude představovat jednoho člověka, tak uvnitř najdete jeho atributy (jméno, adresu), pole obsahující výčet jeho zájmů, pole vnořených objektů jeho adres pro zasílání zboží (kde každá obsahuje adresu a PSČ) a pole vnořených objednávek, kde každá obsahuje nějaké položky zboží a tak podobně. Všechny relevantní informace o zákazníkovi máte v tomto dokumentu – krásně pohromadě a rychle k dispozici. Navíc nepotřebujete nic vymýšlet dopředu – u jednoho uživatele můžete mít informace o jeho oblíbené značce bot, u jiného ne – nemusíte definovat struktury tabulek a jejich vztahů. Přesto většinou můžete v záznamech vyhledávat, třeba vypsat si všechny zákazníky, kteří si od vás někdy koupili bačkory. Dokonce tyto NoSQL systémy občas nabízí možnost napsat si vlastní Map-Reduce “aplikaci” (často v Javascript) – tzn. zadáte si vlastní výpočet nad daty, který se distribuovaně provede přes všechny nody.
Klíčovým zástupcem je nejpopulárnější NoSQL současnosti – MongoDB, se kterou se velmi prakticky seznámíme hned v příštím článku. Kontrastem je CouchDB. Mají odlišné přístupy k namíchání CAP polévky. MongoDB je CP systém (zjednodušeně řečeno má mastera, který řídí zápisy – je volen a udržován, zajišťuje dobrou konzistenci), zatímco CouchDB je typicky AP (multi-master, zapisovat můžete kamkoli, ono se to dopíše a konflikty se řeší časovou značkou – takže můžete mít CouchDB třeba v mobilu, víte, že máte všechno lokálně, že tam klidně můžete i psát a ono se to dosynchronizuje v okamžiku, kdy se připojíte do sítě).
Column oriented
Sloupcově orientované tabulky vznikly především jako reakce na to, že není dost dobře možné pracovat s tabulkou a velikosti miliardy řádků na miliony sloupců. Google si pro svoje účely vytvořil proprietární BigTable, ale popsal principy fungování, takže později vznikla open source implementace jako je Apache Cassandra nebo HBase (ta využívá Hadoop jako vrstvy pod sebou). Běžná RDBMS ukládá data po řádcích, column databáze naopak po sloupcích. Pro určité typy úloh zejména netransakčního typu to má naprosto zásadní vliv na výkon (souvisí to s načítáním stránek a tak podobně – to dnes nechme stranou pro účely udržení čitelnosti článku) – Cassandra je skutečný závoďák mezi NoSQL systémy (a o relačních samozřejmě ani nemluvě) a dosahuje neuvěřitelné škálovatelnosti. Není tak flexibilní jako dokumentové NoSQL, ale přesto vás nenutí mít u každého řádku stejné sloupce – nepočítejte ale s vnořenými strukturami a tak podobně. Cassandra nabízí jazyk CQL, který je velmi podobný SQL (ale nemá relační vlastnosti typu JOIN). Chcete masivní výkon nebo enormní škálu – tedy jinak řečeno jde vám zejména o zpracování velkých dat? Sloupcové NoSQL jsou dobrá volba.
Graph
Relační, tedy “vztahová” databáze je nevhodná k ukládání informace o vztazích mezi objekty. Říkám nadneseně, ale je to tak. Ovšem ani předchozí NoSQL si v tomto nevedou dobře. Když si například položíme otázku, zda vy a já máme nějakého společného známého, vyžaduje to v klasickém systému opravdu hodně chroupání. A co teprve když budeme hledat, zda se někdo z mých známých nezná s někým z vašich známých. Podobné je to třeba s hledáním nejkratší cesty v logistice, propleteností vašich zájmů, návštěv obchodů nebo analýza jazyka. Tato speciální kategorie NoSQL systémů je nejčastěji spojována s populárním Neo4J.
