MongoDB a NoSQL revoluce — konec relačních databází?

Poslední rok nelze v technologickém svete otevřít RSS ctecku, aniž by člověk nenarazil na článek o NoSQL databázích. MongoDB, CouchDB, Cassandra, Redis — každá slibuje něco jiného, ale vsechny sdílí jednu myslenku: relační model není jediná cesta. Jako tým, který poslední dekádu pracuje s Oracle a PostgreSQL, jsme se rozhodli prověřit, zda je NoSQL hype, nebo skutečná zmena paradigmatu.

Proc vznikly NoSQL databaze¶

Termín NoSQL se poprvé objevil v roce 2009 na konferenci v San Franciscu, ale myšlenka nerelacniho úložiště je mnohem starší. Hlavní hybatel byl jednoduchý — webové aplikace jako Facebook, Google a Amazon museli zpracovávat takové objemy dat a takový počet pozadavku, ze tradiční relační databaze proste nestacily. Oracle muze byt sebevykonnejsi, ale kdyz potřebujete horizontální škálování pres stovky serveru, relační model s jeho JOINy, transakcemi a normalizaci se stává brzdou.

Google publikoval paper o Bigtable v roce 2006, Amazon představil Dynamo v roce 2007 a tyto prace inspirovaly celou generaci open-source databazi. Cassandra vznikla ve Facebooku, HBase implementuje Bigtable model na Hadoopu, MongoDB přišla s dokumentovým modelem, který je intuitivní pro webove vyvojare. Každá z těchto databazi dělá kompromis — vymění něco z ACID vlastnosti za škálovatelnost, flexibilitu nebo vykon.

Dokumentový model MongoDB¶

MongoDB je dokumentova databaze, což znamená, ze data ukládá jako JSON-like dokumenty (interni format je BSON — Binary JSON). Kazdy dokument muze mit jinou strukturu, není potřeba předem definovat schema. To je fundamentální rozdíl oproti relačním databázím, kde musíte vytvořit tabulku s pevne danymi sloupci, nez do ni můžete vložit data.

Pro webove vyvojare je tento model přirozený. Kdyz vaše aplikace pracuje s JSON objekty (a v roce 2011 skoro každá webová aplikace pracuje s JSON), můžete je uložit primo do databaze bez nutnosti mapování na relační schema. Žádný ORM, zadne impedance mismatch. Dokument v MongoDB muze obsahovat vnořené objekty a pole, což umožňuje modelovat slozite datove struktury v jednom dokumentu misto více propojenych tabulek.

Kdy MongoDB dava smysl¶

MongoDB exceluje v situacích, kde schema není předem známé nebo se často meni. Typicky příklad jsou katalogové systemy — každá kategorie produktu muze mit jiné atributy. V relační databazi byste řešili EAV pattern (Entity-Attribute-Value) nebo měli desítky nullable sloupců. V MongoDB proste kazdy produkt má presne ty atributy, které potřebuje.

Další skvělý use case je logovani a analytika. Logy mají promenlivou strukturu a objem roste exponenciálně. MongoDB zvládá vysoký write throughput a s capped collections nabízí automatickou rotaci starých dat. Pro agregaci nad logy pouzivame MapReduce — což není tak pohodlné jako SQL GROUP BY, ale pro velke objemy dat je to efektivnější.

Content management systemy jsou další přirozený fit. Články, stránky, komentáře — kazdy typ obsahu muze mit jinou strukturu a vnořené komponenty. MongoDB umožňuje uložit celou stránku jako jeden dokument včetně metadat, tagu a komentářů. Čtení je pak jediný dotaz misto sloziteho JOINů pres pet tabulek.

Kdy MongoDB NEDÁVÁ smysl¶

A teď ta důležitá cast — kdy NoSQL používat nemáte. Pokud vaše data mají silne relační vazby a potřebujete konzistentní transakce pres více entit, relační databaze je stale lepsi volba. Bankovní system, kde převod peněz musí byt atomicky (odečíst z jednoho uctu a pricist na druhy v jedné transakci) — to s MongoDB neudelate spolehlive. MongoDB nemá multi-document transakce.

Reportovani a ad-hoc dotazy jsou další slabina. SQL je neuvěřitelně expresivní jazyk pro dotazování dat. MongoDB query language je omenenejsi — slozite agregace vyžadují MapReduce, který je pomalý a obtizne debugovatelny. Pokud vasi analyti potrebuji denně psát nove dotazy nad daty, Oracle s SQL Developer bude pořád produktivnější nez MongoDB shell.

Take pozor na duplikaci dat. V relačním modelu je adresa zákazníka na jednom místě a vsechny objednávky na ni referuji. V MongoDB byste adresu mohli embedovat do každé objednávky — což je rychle pro čtení, ale kdyz zákazník zmeni adresu, musíte aktualizovat vsechny dokumenty. Toto je zakladni tradeoff dokumentoveho modelu.

Škálování — sharding a replica sets¶

Jednou z hlavních výhod MongoDB je nativni podpora horizontálního škálování. Sharding rozdělí data pres více serveru podle shard key — například podle ID zákazníka. Kazdy shard obsahuje podmnožinu dat a MongoDB router (mongos) automaticky smeruje dotazy na správný shard. Přidání noveho shardů je relativně jednoduché a MongoDB automaticky rebalancuje data.

Replica sets zajišťují vysokou dostupnost. Kazdy shard má primární uzel a jeden nebo více sekundarnich uzlu, které replikují data asynchronně. Pokud primární uzel spadne, sekundární uzel je automaticky zvolen jako nový primární. Toto je vyrazne jednodušší nez nastavování Oracle RAC nebo PostgreSQL streaming replication.

Ale pozor — asynchronní replikace znamená, ze pri failoveru můžete ztratit data, která ještě nebyla replikovaná. MongoDB nabízí write concern nastaveni, kde můžete vyžadovat potvrzení zapisu od majority uzlu, ale to snižuje vykon. Je to vždy kompromis mezi konzistenci a výkonem.

Naše zkusenosti z pilotního projektu¶

Rozhodli jsme se vyzkoušet MongoDB na interním projektu — system pro správou konfigurace našich serveru. Kazdy server má jinou sadu služeb, ruzne parametry a historii zmen. V relačním modelu by to bylo pet tabulek s mnoha nullable sloupci. V MongoDB je kazdy server jeden dokument s presne těmi atributy, které potřebuje.

Prvni dojem byl skvělý — vyvoj šel rychle, nemuseli jsme resit migrace schématu a dotazy byly intuitivní. Problem přišel, kdyz jsme potřebovali hledat servery podle kombinace atributů — MongoDB vyzaduje indexy na každé pole, které chcete efektivně prohledávat, a compound indexy mají svá omezeni. Druhy problem byla absence JOINů — kdyz jsme chtěli zobrazit servery s informacemi o jejich datacentru, museli jsme dělat dva dotazy a spojovat data v aplikaci.

Na druhou stranu, přidání noveho atributů ke konfiguraci serveru bylo triviální — žádná ALTER TABLE, žádná migrace, proste jsme začali ukládat nový atribut. Pro system, který se rychle vyvíjí, je tato flexibilita k nezaplacení.

Srovnani NoSQL databazi¶

MongoDB není jediná NoSQL databaze a každá má svou niku. CouchDB je take dokumentova databaze, ale používá HTTP API a má vestavěný konflikt resolution pro offline-first aplikace. Cassandra je sloupcová databaze optimalizovaná pro extrémně vysoký write throughput — ideální pro logovani a IoT data. Redis je in-memory key-value store skvělý pro cache a session management. HBase běží na Hadoopu a je určen pro analytické workloady nad petabajty dat.

Vyber spravne databaze závisí na vašem use case. Neexistuje univerzální odpověď. Často je nejlepší řešení polyglot persistence — používat více databazi v jedné aplikaci, každou pro to, v čem je nejlepší. Relační databaze pro transakce, MongoDB pro flexibilni dokumenty, Redis pro cache, Elasticsearch pro fulltextové vyhledávání.

CAP teorem a realita¶

Kdyz mluvíme o NoSQL, musíme zminit CAP teorem. Eric Brewer formuloval hypotézu, ze distribuovaný system muze splňovat maximálně dvě ze tri vlastnosti: Consistency (konzistence), Availability (dostupnost) a Partition tolerance (odolnost proti rozdeleni site). V praxi to znamená, ze pri síťovém problemu si musíte vybrat — buď budete vracet stará data (AP system) nebo budete nedostupni, dokud se síť neobnoví (CP system).

MongoDB je CP system — pri nedostupnosti primary uzlu je cast dat docasne nedostupná, dokud proběhne election noveho primary. Cassandra je AP system — vždy odpoví, ale muze vrátit stará data. Tradiční relační databaze na jednom serveru proste ignorují partition tolerance, protože nemají distribuci.

Zaver¶

NoSQL databaze nejsou nahradou relacnich databazi — jsou doplnkem. MongoDB je skvělá volba pro flexibilni schema, vysoký write throughput a horizontální škálování. Ale pro transakce, slozite dotazy a silne relační data zůstáváme u PostgreSQL a Oracle. Budoucnost je v polyglot persistence — správná databaze pro správný problem.