Narcis Miclaus

10 min de citit

Arhitectura datelor și a sistemelor, de la zero Lecția 19 / 80

Document stores: MongoDB și ascensiunea/căderea/renașterea

Când datele imbricate sunt modelul, ce costă schema-on-read și lecțiile operaționale pe care MongoDB le-a dat industriei.

Lecțiile precedente au acoperit modelul relațional (lecția 17) și modelul key-value (lecția 18). Asta o acoperă pe a treia familie majoră: document stores, unde fiecare înregistrare e un arbore în formă JSON, iar schema e, cel puțin nominal, opțională. Produsul canonic e MongoDB. Istoria MongoDB e un arc util, pentru că acoperă, în timp real, ciclul de hype al unei tehnologii noi, realitatea operațională dureroasă, apoi maturizarea constantă într-o unealtă legitimă. Citirea arcului e cea mai rapidă cale de a înțelege atât pentru ce sunt bune document stores, cât și unde a luat-o razna discursul din jurul lor.

Modelul de date

Un document store tratează fiecare înregistrare ca un document de sine stătător, de obicei JSON sau o variantă binară a JSON-ului (BSON în cazul MongoDB). Un document e un arbore de câmpuri denumite ale căror valori pot fi primitive (string-uri, numere, boolean-i, null, date), array-uri sau documente imbricate. Documentele trăiesc în colecții, echivalentul tabelelor în lumea document store. Nu există o schemă fixă declarată la nivel de colecție; două documente din aceeași colecție pot avea câmpuri diferite, tipuri diferite pentru același nume de câmp sau forme arbitrar de diferite.

Un document tipic ar putea arăta așa, conceptual:

{
  "_id": "post_42",
  "title": "Hello world",
  "author": { "id": "user_7", "name": "Narcis" },
  "tags": ["intro", "meta"],
  "comments": [
    { "by": "user_3", "text": "nice", "at": "2026-04-12T10:30:00Z" },
    { "by": "user_5", "text": "+1",  "at": "2026-04-12T11:02:00Z" }
  ],
  "published_at": "2026-04-12T09:00:00Z"
}

Tot postul, cu comentarii și autor cu tot, trăiește într-un singur document. O citire aduce întreg lucrul dintr-o singură mișcare. O scriere actualizează câmpuri din interiorul lui, posibil atomic. Pitch-ul a fost: așa e mai aproape de cum gândește aplicația despre date, deci impedance mismatch-ul dintre baza de date și modelul de obiecte dispare.

Comparat cu echivalentul relațional, unde ai avea o tabelă posts, o tabelă users, o tabelă comments și o tabelă tags, modelul document colapsează ce ar fi fost trei sau patru join-uri într-un singur fetch de document. Pentru pattern-ul de acces „arată-mi un post cu tot ce ține de el”, ăla e un câștig real.

Pitch-ul, prin 2010

MongoDB a fost lansat în 2009. Discursul din 2010 până în 2013 a fost neîncetat de entuziast, iar marketingul a fost specific: „bazele de date schemaless sunt mai ușoare”; „JSON intră, JSON iese, nimic de migrat”; „echipele agile livrează mai repede fără frecarea definițiilor de schemă”. Pitch-ul a vândut milioane de deployment-uri MongoDB, în multe cazuri către echipe care n-aveau de fapt nevoie de modelul document.

Mișcarea intelectuală din spate era reală chiar dacă execuția a fost exagerată. Schemele SQL în lumea Rails-and-Django de la începutul anilor 2010 erau autentic dureroase: fiecare nouă funcționalitate însemna o migrare, fiecare migrare însemna o coregrafie de deploy, ORM-urile mascau impedance mismatch-ul și introduceau propriile bug-uri. „Stochează doar JSON-ul” se simțea eliberator. Pentru faza de prototip a unui startup, unde produsul se schimbă săptămânal și nimeni nu știe schema corectă, pitch-ul no-schema era atrăgător.

Pitch-ul avea două puncte oarbe specifice. Întâi, absența unei scheme declarate nu înseamnă absența unei scheme. Schema e implicită, împrăștiată prin codul aplicației, neaplicată de nicio componentă singulară. Două servicii scriu aceeași colecție cu forme subtil diferite. Un câmp e redenumit într-un loc, dar nu și în altul. O citire dintr-un al treilea serviciu crapă pe un tip neașteptat. Schema există; doar că nu e unde poți s-o vezi.

Doi, „mai ușor de evoluat” era un semi-adevăr. Da, poți schimba forma fără o migrare. Dar documentele vechi, scrise sub forma veche, sunt în continuare în baza de date. Codul aplicației trebuie să gestioneze fiecare formă istorică pentru totdeauna, sau scrii oricum o migrare, dar acum fără ajutorul bazei de date.

Realitatea, prin 2015 până în 2020

Următoarea jumătate de deceniu a fost o educație brutală pentru lumea document store, iar MongoDB a încasat-o cel mai tare. Două categorii de durere.

Durerea de corectitudine a venit prima. Default-urile timpurii ale MongoDB erau, ca s-o spunem blând, nesigure: scrierile întorceau succes înainte de a fi persistate durabil, replicile puteau rămâne în urmă fără avertismente, garanțiile de izolare erau mai slabe decât presupuneau utilizatorii. Testele Jepsen ale lui Kyle Kingsbury între 2013 și 2020 au găsit o serie de probleme: update-uri pierdute sub partiție de rețea, citiri stale de pe replicile secundare, tranzacții care nu se comportau de fapt tranzacțional. MongoDB Inc. a răspuns, a reparat problemele și a livrat default-uri mai bune, dar pagubele de reputație au luat ani buni să fie reparate. „MongoDB is web scale” a circulat prin comunitatea de inginerie aproape tot deceniul 2010, livrat cu un rânjet.

Durerea operațională a venit alături. Sharding-ul a funcționat prost în practică ani de zile. Operațiunile pe cluster (rebalansare, backup, point-in-time recovery, schimbări de schemă) erau fie mai grele decât promis, fie absente de fapt. Echipele care au ales MongoDB pe baza pitch-ului developer-experience au descoperit, după șase luni, că operau un sistem distribuit fără maturitatea operațională pe care Postgres și-o construise în decenii.

Rezultatul a fost o retragere lentă, publică. Narațiunea „document store ca bază de date primară” s-a estompat și, prin 2018, consensul industriei era: folosește document stores doar pentru cazuri specifice unde forma e cu adevărat potrivită.

Renașterea, prin 2020 până azi

Dacă te-ai oprit din citit povestea MongoDB în 2018, ai fi ratat reculul. De-a lungul celei de-a doua jumătăți a deceniului, MongoDB Inc. a făcut munca neglamoroasă de a repara problemele reale și, până în 2026, produsul e semnificativ diferit de cel pe care l-a testat Jepsen în 2013.

Tranzacțiile multi-document au sosit în MongoDB 4.0 (2018) cu ACID propriu-zis în cadrul unui replica set, apoi extinse la cluster-uri shardate în 4.2. Apărarea „documentele sunt atomice deci nu ai nevoie de tranzacții” a fost retrasă. Write și read concerns au fost strânse: write concern-ul implicit e acum majority, deci o scriere e confirmată doar după ce o majoritate a replica set-ului o are. Validarea de schemă a fost adăugată: poți declara un validator JSON Schema pe o colecție, iar baza de date îl aplică. Pitch-ul „schemaless” a fost înlocuit discret de „schema-flexible”, care e versiunea cinstită. Pipeline-urile de agregare s-au maturizat într-un limbaj de query serios cu join-uri $lookup, funcții de fereastră și căutare facetată. Operațiunile de cluster s-au îmbunătățit pe toată linia.

Rapoartele Jepsen din anii 2020 spun o poveste diferită de cele din anii 2010. Produsul trece teste pe care obișnuia să le pice. Tranzacțiile multi-document funcționează cum sunt promise, cu avertismentul că tranzacțiile de lungă durată dintr-un cluster shardat au costuri reale de performanță. Produsul e acum o alegere legitimă pentru cazurile în care modelul document se potrivește, iar discursul e, în sfârșit, calibrat.

Când document stores se potrivesc cu adevărat

Există un set mic, bine definit, de workload-uri unde modelul document e unealta potrivită. Fiecare entitate e un arbore de sine stătător: un blog post cu comentarii și tag-uri încorporate, un produs cu variante și imagini imbricate, un document de configurare, o comandă completă cu line items și livrare. Pattern-ul de acces e „adu tot lucrul, modifică o parte, salvează-l înapoi”, iar descompunerea relațională ar împărți asta în patru sau cinci tabele fără un beneficiu clar la momentul citirii. Nu ai nevoie des de tranzacții cross-entity: granița de atomicitate într-un document store e, by default, documentul, deci tranzacțiile single-document sunt gratuite; dacă tranzacțiile tale traversează în mod obișnuit multe documente, modelul document nu te scutește de nimic. Evoluția schemei pe măsură ce un produs se maturizează: produsele aflate în stadii incipiente beneficiază de adăugarea de câmpuri sparse fără o migrare, deși Postgres cu JSONB poate gestiona și asta. Documente eterogene în aceeași colecție: produse diferite cu atribute diferite, evenimente diferite cu payload-uri diferite, unde coloanele fixe sunt incomode și câmpurile opționale sunt naturale.

Dacă workload-ul tău are una sau două dintre aceste trăsături, un document store e o alegere rezonabilă. Dacă n-are niciuna, plătești costul unei unelte nefamiliare pentru beneficii pe care nu le folosești.

Când SQL cu JSONB e o alegere mai bună

Postgres are un tip de coloană JSON din 2012, iar JSONB (binar, indexat, prietenos cu query-urile) din 2014. Până în 2026 setul de funcționalități e matur: indexuri GIN pentru lookup-uri arbitrare pe chei interioare, indexuri pe expresii pentru path-uri specifice, un set bogat de operatori, suport JSONPath, integrare bună cu query planner-ul. Combinația dintre o schemă relațională pentru partea structurată plus coloane JSONB pentru partea flexibilă acoperă majoritatea cazurilor de utilizare pentru care a fost vândut modelul document, fără să renunți la restul SQL-ului.

Pattern-ul Postgres-cu-JSONB câștigă atunci când uneori ai nevoie de query-uri relaționale și uneori de stil document (amestecul în MongoDB e incomod; în Postgres e un singur query), când vrei un singur motor în loc de două (backup-uri, monitorizare, failover și expertiză separate sunt un cost real) sau când majoritatea datelor tale sunt structurate, dar o mică parte e cu adevărat flexibilă.

Calea pure document-store câștigă atunci când întreaga formă a datelor e cu adevărat flexibilă, când pattern-urile de acces sunt cap-coadă în formă de document cu foarte puține operațiuni cross-document sau când ești greenfield cu expertiza operațională și o echipă confortabilă cu ecosistemul.

Diagnosticul cinstit pentru 2026: dacă nu ești sigur, mergi pe Postgres cu JSONB ca default. Portița de scăpare (mută părțile JSON într-un document store real mai târziu) rămâne deschisă. Migrarea inversă (MongoDB înapoi la Postgres) e mai grea, pentru că datele au fost scrise sub o presupunere de schemă-fixă-absentă care poate să fi produs inconsistențe pe care nu le știai acolo.

flowchart LR
    subgraph Document_Model
        D[blog_post document]
        D --> Dt[title]
        D --> Da[author embedded]
        D --> Dc[comments array embedded]
        D --> Dg[tags array embedded]
    end
    subgraph Relational_Model
        P[posts row]
        P -.fk.-> U[users row]
        P -.fk.-> C[comments rows]
        P -.fk.-> T[post_tags rows]
        T -.fk.-> Tg[tags rows]
    end

Aceeași entitate conceptuală, două modele diferite. Niciunul nu e universal corect. Modelul document e un fetch, o scriere, o graniță de consistență. Modelul relațional e mai multe rânduri, mai multe join-uri, mai multă flexibilitate pentru query-uri pe care designerul original nu le-a prevăzut.

Celelalte document stores

MongoDB e document store-ul canonic, dar nu singurul. Couchbase are un limbaj de query asemănător SQL-ului (N1QL) și e puternic la workload-uri single-document de mare throughput. RavenDB e un document store înclinat către .NET cu un focus puternic pe ACID. Firestore (Google Cloud) e un document store gestionat cu sincronizare în timp real, perfect pentru workload-uri mobile și web de tip „documente mici, mulți clienți, update-uri în timp real”. DocumentDB (AWS) vorbește protocolul wire al MongoDB, dar are propriul motor AWS dedesubt; compatibilitatea e parțială, citește cu atenție amănuntele. CouchDB e proiectul Apache mai vechi care a deschis drumul unora dintre pattern-uri, încă folosit cu PouchDB pentru aplicații web offline-first.

Compromisul e similar la toate: câștigi stocare naturală de documente, pierzi query-uri ad-hoc cross-entity facile.

Lecția operațională

Cea mai importantă lecție din arcul MongoDB nu e despre modelul document în sine. E despre greutatea relativă a modelului de date versus maturitatea operațională. Luptele MongoDB din anii 2010 n-au fost pentru că modelul document era greșit; au fost pentru că motorul nu construise încă poveștile de replicare, sharding, tranzacții și gestionare a defecțiunilor pe care lumea relațională a petrecut patruzeci de ani perfecționându-le. MongoDB-ul din 2026 e bun nu pentru că modelul document a devenit mai corect, ci pentru că povestea operațională a recuperat în sfârșit.

Corolarul se generalizează: când alegi o bază de date, modelul de date contează mai puțin decât crede lumea, iar maturitatea operațională contează mai mult. O potrivire perfectă a modelului de date pe un motor imatur produce o cădere. O potrivire mediocră pe un motor verificat în luptă produce frecare în codul aplicației. Frecarea e mai ieftină.

Unde aterizează lecția asta

Document stores sunt legitime, cu o potrivire mai îngustă decât a sugerat discursul anilor 2010. MongoDB e exemplul canonic, iar produsul e semnificativ mai bun decât reputația sa de acum un deceniu. Postgres cu JSONB acoperă majoritatea cazurilor de utilizare pentru care a fost vândut modelul document, păstrând în același timp SQL-ul la îndemână pentru query-urile la care modelul document e prost. Default-ul cinstit în 2026 e tot Postgres; document store-ul e atins când workload-ul e cu adevărat în formă de document cap-coadă.

Următorul model major de date e wide-column (Cassandra, ScyllaDB, HBase, Bigtable), pe care îl acoperim în lecția 20. După aceea, time-series (lecția 21), search (lecția 22), graph (lecția 23) și în sfârșit sinteza: lecția 24 despre persistență poliglotă, arhitectura realistă pentru sisteme de producție, care înseamnă să folosești store-ul specialist potrivit pentru fiecare formă de date, cu un set mic de granițe bine definite între ele.

Citate și lecturi suplimentare

  • Documentația MongoDB, https://www.mongodb.com/docs/ (consultat 2026-05-01). În special secțiunile „Transactions”, „Schema Validation” și „Replication”.
  • Kyle Kingsbury, rapoartele „Jepsen: MongoDB” de-a lungul anilor, https://jepsen.io/analyses (consultat 2026-05-01). Rapoartele din 2013, 2015, 2017 și 2020, citite în ordine, sunt o educație despre cum se maturizează o bază de date distribuită. Citește-l pe cel mai recent pentru starea curentă, dar cele mai vechi sunt povestea mai interesantă.
  • Werner Vogels, „Eventually Consistent”, Communications of the ACM, ianuarie 2009. Background util despre modelele de consistență care au modelat mișcarea NoSQL timpurie, MongoDB inclus.
  • Alex Petrov, „Database Internals” (O’Reilly, 2019). Capitolul despre motoare de stocare acoperă compromisurile de structuri de date din spatele document stores, key-value stores și bazelor de date relaționale într-un vocabular uniform.
  • Documentația PostgreSQL JSONB, https://www.postgresql.org/docs/current/datatype-json.html (consultat 2026-05-01). Referința pentru opțiunea SQL-cu-JSONB, inclusiv indexare, operatori și JSONPath.
Caută