MongoDB - závislost za 30 minut!

Byl bych rád, kdybyste se znovu ozval za pár let. Dost často pozoruju, že lidé, kteří použili mongodb po čase litovali nebo migrovali jinam. Dovedu si ale představit, že je perfektní např. na úlohu typu: Nahraju do toho složitá/nekon­zistentní/neod­povídajíci "moderním" požadavkům data, odladím si konverze/extrakce dat, a posléze CORE data uložím do relační databáze.

Tak my jsme v praci zacali pouzivat mongo asi pred dvema mozna trema rokama. A neda se rict ze bychom litovali. Ano dnes sice uvazujeme ze jej mozna v budoucnu nahradime za PostgreSQL (JSONB, vylepseni replikace) diky tomu ze se Postgres znacne za posledni dobu vylepsil a uz jej na par veci pouzivame, tudiz by se zjednodusila architektura. Ale to hodne zavisi jak dopadnou vykonnostni testy pro nase ucely. Osobne typuji ze pokud je mongo 3 o tolik rychlejsi jak slibuji tak u monga zustaneme.

Tak jako vždycky zázračně jednoduché řešení neexistují. U mongo postupně narazíte na:
Žádná podpora pro relace mezi záznamy, inner/left/rig­ht/outer join si děláte ručně.
Špatná podpora pro transakce.
Náhrada většího SQL dotazu je nepřehledná.
Global write lock, i když ve verzi 3 se to mírně zlepšilo.
Žádná pokročilá správa cache, používá se disková cache z OS.
Zabírá víc místa na HDD kvůli nutné duplicitě.
Konkurence umí JSON také.
Dokumenty bez pevného schématu lze uložit i do tradičního SQL, asi po dvou minutách přemýšlení, i když ne jako jeden záznam.
Od konce loňského roku je pomalejší než SQL konkurence.

Ve výsledku zjistíte, že motivace pro zahájení nového projektu s mongo je slabá.

S Mongo pracuje můj kolega - inspiroval jsem ho používáním CouchDB. Obě databáze, Mongo i CouchDB jsou trochu podobné. Kolega do MongoDB migruje systém webů s rozsáhlými sdílenými daty (MySql). Z aplikace vyhodil asi třetinu kódu - protokol pro předávání dat, o to se teď stará databáze. Prasečí kód (průměrný programátor MySql nezná join) přestěhoval do prasečí struktury dokumentů (každý dokument vypadá trochu jinak). Nevím, jak se to projevuje na rychlosti, ale na čitelnosti kódu prý ano.

Já používám pro některé projekty databázi CouchDB - ve firmě máme vytvořenou trochu větší distribuovanou databázi zhruba přes šest počítačů. Podobně používám CouchDB v jednom složitějším serveru pro ukládání konfigurace a vnitřního stavu X různých datových struktur. CouchDB je naprosto blbovzdorná a schopná přežít kdeco.

Dokumentové databáze se používají dobře a v mnoha případech mají své využití. Na druhou stranu si nedovedu představit, že bych do podobné databáze uložil některá jiná data, tady u mě vládne PostgreSQL, refereční integrita, joiny a spousta procesorových jader a disků.

Takže souhlasím. Jsou aplikace, kde dokumentové databáze miluju.

Moje zkusenosti s MongoDB - pekne, rychle, ale kdo to ma porad opravovat? Snad se za tech nekolik let zlepsili, ale naposled kdy jsem to zkoumal to bylo porad ve stavu, ze je nutne mit zdrojova data jeste ulozena bokem, a MongoDB se bere spis jako pracovni cache nez primarni uloziste. To same s replikaci - vetsinou to funguje, ale casem se data "rozjedou" a je nutne udelat resync (a pokud mate write-write repliku, tak si muzete vybrat, ktera data jsou ta "spravna").

CouchDB je trosinku jina hlavne v tom, jak se s daty pracuje - Mongo ma blize ke key-value databazi. U CouchDB neni problem, aby vyvojar pro 50MB dat vyrobil 50GB views na kterych zacne zaviset - v tu chvili se cele kouzlo ztraci, protoze je (na vetsine hardware) rychlejsi mit 50MB v RDBMS se silenou strukturou nez hledat neco v 50GB souboru.

Pouzivam Mongo jako doplnkovou databazi k MySQL (proste referencni integritu v tomto reseni potrebuji). Na nestrukturovana data je to flexibilnejsi nez relacni databaze, ale zase nema jine veci (treba tu referencni integritu).
Mam to zatim jako experiment. Uvidim jake budou poznatky z praxe.

Ja Mongo pouzival v praci.

Firma bezela na Jablku (MacOS) a v te dobe (cca 2 roky) k tomu nebyl pouzitelny client na obycejny UPDATE dat. Nejen ze pravidelne padal ale po zapsani do databaze s fontem UTF-8 doslo k naprostemu rozhozeni pridanych dat. A pak to lovit a opravovat byla sila.

Ad „Historické záznamy ale byly kombinace binárních a textových dat zachycených na sběrnici, přímo uložených bez dalších úprav. Dispečer měl pouze možnost přes starou ovládací aplikaci sledované parametry a stavy kontrolovat, tuto možnost musela vždy servisní firma zadrátovat přímo do kódu. V průběhu osmi let byl počet linek rozšiřován a i linky samotné byly upravovány. Tzn. co linka a období, to drobné nuance ve významu a struktuře zaznamenaných dat. Navíc s každou rekonfigurací linky docházelo ke změnám v přijímaných větách dat z řídících a monitorovacích jednotek (další bloky od nově instalovaných senzorů apod.).“

Tady je hezky vidět, že „schemaless“ je příčinou problému, nikoli řešením.

Ad „veškeré operace v databázi (místo SQL) provádíte jednoduše v JS.“

Jednoduše? SRSLY? Spíš mi to přijde jako pořádný krok zpátky.

Celkově vzato: jako vidle k přeházení hnoje z jedné hromady na druhou je to možná dobré, ale pro nově pořizovaná data bych nic „schemaless“ nedoporučoval a radil bych to udělat pořádně. Jinak za pár let přijde někdo, kdo bude ve stejné pozici jako ty teď a bude se v tom hnoji muset přehrabovat.

Na tento příspěvek jsem se rozhodnul reagovat. Především na výrok "Tady je hezky vidět, že schemaless je příčinou problému, nikoli řešením". Domnívám se, že zde došlo k neporozumění. Proč jsem na to právě Mongo použil? Právě proto, že je schemaless a že převod do takové databáze byl relativně rychlý a levný. Nedovedu si představit, že bych nejdříve musel projít celý dataset, připravit schéma, dlouze nahrávat (a normalizovat) a to do doby, než vyladím poslední chybu (která zapříčiní změnu schámatu). Takto se už v tom servisáci po rychlém zaškoleni (jednoduchý dotaz v JS) sami přehrabují a kontrolují si nastavení apod. Rozhodně bylo jednodušší v JSONu jim vysvětlit a pochopit pro ně dokument, ktery ma v sobě subdokumenty, než různé kartézské součiny, detektivní práci v čem se odlišují jednotlivé řádky nebo JOINy. Navíc to hnůj rozhodně není, už se to používá. Kdyby se to dělalo klasicky, nikdo to nezaplatí a ještě teď to není.

hyv: Jako jednorázová záležitost pro převod starých read-only dat do nového systému budiž. Ovšem začínat s Mongo nový projekt s potenciálem růstu není rozumné, je to návrat zpět asi tak o dvě desetiletí. Mongo není jediné s podporou nestrukturovaného datového skladu JSON dokumentů, konkurence to umí také.