Relační databáze jsou páteří enterprise IT už desítky let. Ale co když vaše data nemají pevné schéma? Co když potřebujete horizontální škálovatelnost bez Oracle licence? MongoDB 2.6 právě vyšlo a my jsme ho nasadili do produkce. Tady je naše zkušenost.
Proč jsme sáhli po MongoDB¶
Klient — středně velký e-commerce player — řešil klasický problém: produktový katalog s tisíci atributů, které se lišily kategorie od kategorie. V MySQL to znamenalo buď EAV model (pomalý, složitý), nebo stovky sloupců s NULL hodnotami. Žádná z variant nebyla udržitelná.
MongoDB nabídlo dokumentový model, kde každý produkt mohl mít jiný set atributů. Žádné ALTER TABLE, žádné migrace. Přidáte nový atribut? Prostě ho zapíšete do dokumentu. Pro katalogové use-case to byl game changer.
Architektura nasazení¶
Nasadili jsme MongoDB 2.6 v replica set konfiguraci — tři nody, jeden primární a dva sekundární. Pro náš objem dat (přibližně 50 GB) nebyl sharding nutný, ale architektura byla připravená na budoucí růst.
# Replica Set konfigurace
mongod --replSet rs0 --port 27017 --dbpath /data/db1
mongod --replSet rs0 --port 27018 --dbpath /data/db2
mongod --replSet rs0 --port 27019 --dbpath /data/db3
# Inicializace
rs.initiate({
_id: "rs0",
members: [
{ _id: 0, host: "mongo1:27017" },
{ _id: 1, host: "mongo2:27018" },
{ _id: 2, host: "mongo3:27019" }
]
})
Aplikační vrstva běžela na Node.js s Mongoose ODM. Volba Node.js nebyla náhodná — JSON in, JSON out, žádná impedance mismatch mezi aplikací a databází. V roce 2014 je tato kombinace stále relativně čerstvá, ale funguje překvapivě dobře.
Datový model — dokumenty místo tabulek¶
Největší mentální posun pro tým zvyklý na relační databáze: denormalizace je OK. V MongoDB neděláme JOINy — místo toho vkládáme související data přímo do dokumentu.
Produktový dokument vypadal přibližně takto: název, popis, cena, kategorie, pole variant (každá s vlastní cenou a skladem), embedded recenze a metadata. Jeden dotaz vrátil vše, co frontend potřeboval. Žádné JOINy přes pět tabulek.
Samozřejmě to má svá úskalí. Když se změní jméno kategorie, musíte ho aktualizovat ve všech produktech. Ale pro read-heavy workload e-shopu to byl přijatelný trade-off.
Indexování — klíč k výkonu¶
MongoDB bez správných indexů je pomalé. Velmi pomalé. Toto jsme
se naučili tvrdě. Náš první deployment měl response time přes
500 ms na jednoduchých dotazech. Po analýze pomocí explain()
jsme zjistili, že MongoDB provádělo full collection scan.
- Compound indexy — kombinace polí, která se nejčastěji dotazují společně
- Text indexy — pro fulltextové vyhledávání v katalogu (nové v 2.6)
- TTL indexy — automatické mazání session dat po expiraci
- Sparse indexy — pro pole, která existují jen v části dokumentů
Po správném naindexování jsme se dostali na response time pod 10 ms. Rozdíl byl dramatický. Poučení: MongoDB vám neřekne, že vám chybí index. Musíte aktivně monitorovat a profilovat.
Co nás překvapilo pozitivně¶
Rychlost vývoje. Bez nutnosti definovat schéma předem jsme iterovali mnohem rychleji. Nový feature vyžadující nové pole? Prostě ho začneme zapisovat. Žádné ALTER TABLE, žádné migrace, žádné čekání na DBA.
Aggregation Framework. MongoDB 2.6 přineslo vylepšený aggregation pipeline, který pokryl většinu analytických dotazů, které jsme dříve řešili komplexními SQL dotazy. Pipeline stages jako $match, $group, $unwind a $project jsou intuitivní.
Replica Set failover. Simulovali jsme výpadek primárního nodu. Volba nového primárního proběhla za 12 sekund. Aplikace automaticky přesměrovala zápisy. Žádný manuální zásah.
Co bolí¶
Žádné transakce. MongoDB v roce 2014 nepodporuje multi-document transakce. Pro objednávkový proces — kde potřebujete atomicky odečíst sklad a vytvořit objednávku — jsme museli implementovat two-phase commit pattern ručně. Složité a křehké.
Write concern gotchas. Defaultní write concern v driveru byl „fire and forget”. Bez explicitního nastavení w:majority jste mohli ztratit data při failoveru. Dokumentace na to upozorňovala, ale ne dost hlasitě.
Memory-mapped storage engine. MongoDB používá mmap pro storage. Na serveru s 64 GB RAM a 50 GB daty to fungovalo skvěle. Ale jakmile working set přerostl RAM, výkon padl dramaticky. WiredTiger engine slibuje zlepšení, ale je zatím experimentální.
Kdy MongoDB ano, kdy ne¶
Po půl roce provozu máme jasný obrázek:
- Ano: produktové katalogy, CMS, real-time analytics, session storage, IoT data, prototypování
- Ne: finanční transakce, systémy vyžadující složité JOINy, reporting s komplexními relacemi
- Záleží: user management (jednoduché profily ano, komplexní role/permissions spíš relační DB)
MongoDB v enterprise — s rozvahou¶
MongoDB není náhrada za PostgreSQL nebo Oracle. Je to nástroj pro specifické use-case, kde dokumentový model dává smysl. Nasaďte ho tam, kde relační model škrípe — a nechte relační databáze tam, kde excelují. Polyglot persistence není buzzword. Je to pragmatismus.