Ce tipuri de baze de date există

Pe drumul spre inventar, QUERY încetinește lângă o secțiune întunecată a depozitului. În spatele sticlei se află registrul arhivelor vechiului Pământ care n-au supraviețuit Marii Rupturi: nodurile de cache s-au stins primele, depozitele documentare s-au sfărâmat în fragmente, iar clusterele analitice tac pe sectoare întregi. Copia relațională „Kotomarket” a rămas însă întreagă, cu toate legăturile ei.

Nu doar relaționale

Pentru „Kotomarket”, bazele de date relaționale sunt cele mai potrivite: cumpărătorii, comenzile și produsele se așază firesc în tabele legate între ele. Lor le este dedicat cursul. Dar în industrie, atât în 2024, cât și astăzi, întâlnești și alte abordări:

• cheie-valoare (Redis) — un format foarte rapid „cheie → valoare”, util când trebuie să citești instantaneu o înregistrare simplă;
• orientate pe documente (MongoDB) — păstrează documente JSON flexibile, în care structura poate diferi de la o înregistrare la alta;
• pe coloane (ClickHouse) — puternice în analiză, când trebuie să calculezi rapid indicatori peste volume uriașe de date.

Cele mai populare DBMS-uri pentru dezvoltarea de produs rămân, în mare parte, relaționale: PostgreSQL, MySQL, Oracle, MS SQL. Stăpânește SQL aici și vei putea citi datele cu încredere în companii foarte diferite.

QUERY: Fiecare arhivă are rostul ei: unele dau viteză, altele flexibilitate, altele putere de analiză. Noi doi am avut noroc: ne-a revenit cea în care totul e legat de tot.

Not only relational

For Kotomarket, relational databases suit us especially well: buyers, orders, and products fall naturally into tables with links between them. That’s what this course is about. But across the industry — in 2024 just as today — you’ll meet other approaches too:

• key-value (Redis) — a blazingly fast "key → value" format for when you need to grab a simple record instantly;
• document-oriented (MongoDB) — stores flexible JSON documents whose structure can differ from record to record;
• columnar (ClickHouse) — strong at analytics, when you need to crunch metrics over enormous volumes of data fast.

Most of the popular DBMSs for product development stay relational: PostgreSQL, MySQL, Oracle, MS SQL. Master SQL here and you’ll be able to read data confidently at very different companies.

QUERY: Each archive has its own job: one prizes speed, another flexibility, a third analytics. You and I got lucky: we inherited the one where everything is connected to everything.

Registrul familiilor: fiecare pe raftul ei

Registrul din spatele sticlei e un prilej bun să lămurim pe îndelete familiile de baze de date: „ce tipuri de BD există și când alegi fiecare variantă” este una dintre cele mai frecvente întrebări de interviu. Vom trece prin cinci familii, iar pentru fiecare folosim aceeași grilă: modul de stocare, punctele tari și slabe, produsele și cazurile în care merită aleasă.

BD relaționale: schemă strictă și legături

Modul de stocare: rânduri în tabele cu o schemă declarată din timp — fiecare coloană are un tip, între tabele există legături prin chei, iar DBMS-ul protejează integritatea: o comandă de la un cumpărător inexistent nu poate fi înregistrată. Modificările se execută ca tranzacții cu garanții ACID — „comanda + scăderea stocului” fie se scriu împreună, fie nu se scriu deloc.

• Puncte tari: SQL expresiv (filtre, îmbinări de tabele, agregate), integritate la nivelul bazei, tranzacții.
• Puncte slabe: schema trebuie gândită din timp și migrată la fiecare schimbare; scalarea orizontală pe multe servere e mai grea decât la familiile NoSQL.
• Produse: PostgreSQL, MySQL/MariaDB, Microsoft SQL Server, Oracle, SQLite.
• Când o alegi: utilizatori, comenzi, bani, stocuri — oriunde datele sunt legate între ele, iar o scriere greșită nu este acceptabilă. Pentru un produs nou, este alegerea implicită.

Bazele cheie-valoare: un dicționar la viteză maximă

Modul de stocare: un singur dicționar uriaș „cheie → valoare”, de obicei ținut în RAM. Fără tabele, fără legături: scrii după cheie, citești după cheie, în fracțiuni de milisecundă.

-- Asta nu e SQL, sunt comenzi Redis
SET session:8f3a '{"user_id": 42}'
GET session:8f3a

• Puncte tari: viteză, simplitate, scalare ușoară.
• Puncte slabe: interogări doar după cheia exactă — întrebarea „găsește toate sesiunile cumpărătorilor din Moscova” nu poate fi pusă acestui format; interiorul valorii e opac pentru bază.
• Produse: Redis, Memcached, Amazon DynamoDB.
• Când o alegi: cache, sesiuni, contoare, cozi, clasamente — date fierbinți lângă baza principală, nu în locul ei.

BD documentare: JSON flexibil

Modul de stocare: înregistrările sunt documente JSON, grupate în colecții. Schema nu se declară din timp: un smartwatch are câmpul „autonomie a bateriei”, un hanorac are „grilă de mărimi”, iar ambele documente pot sta fără probleme în aceeași colecție. Structurile imbricate se păstrează chiar în interiorul documentului, fără tabele separate.

• Puncte tari: structură flexibilă, documentul se citește integral cu un singur acces, e comod pentru cataloage cu atribute eterogene și pentru prototipuri rapide.
• Puncte slabe: legăturile dintre documente cad în grija aplicației, JOIN-uri veritabile aproape că nu există; fără disciplină, colecția devine un amestec de formate incompatibile.
• Produse: MongoDB, Couchbase, Firestore.
• Când o alegi: conținut, cataloage cu câmpuri foarte diferite, profiluri și setări.

Apropo, granița dintre familii e neclară: PostgreSQL știe să păstreze documente într-o coloană de tip jsonb și să construiască indecși peste ele — adesea asta acoperă nevoia „documentară” fără a doua bază:

-- Un exemplu din afara instantaneului nostru: attrs — coloană de tip jsonb
SELECT name, attrs->>'color' AS color
FROM catalog
WHERE attrs @> '{"brand": "Kotomarket"}';

BD pe coloane: analiză peste miliarde de rânduri

Modul de stocare: valorile sunt păstrate pe coloane, nu rând cu rând: toate prețurile laolaltă, toate datele laolaltă. Interogarea „valoarea medie a comenzilor pe luni” citește de pe disc doar două coloane, nu tot tabelul, iar valorile de același fel se comprimă excelent. De aici vine viteza la agregate.

-- Genul preferat al bazei pe coloane (dialect ClickHouse: toYYYYMM e funcția lui)
SELECT toYYYYMM(created_at) AS month, avg(total_amount) AS avg_check
FROM orders
GROUP BY month;

• Puncte tari: agregate și scanări peste miliarde de rânduri, comprimare puternică.
• Puncte slabe: actualizările și ștergerile punctuale sunt costisitoare; citirea unui singur rând întreg e mai lentă decât într-o bază pe rânduri; nu sunt făcute pentru sarcini tranzacționale pure.
• Produse: ClickHouse, BigQuery, Snowflake, Amazon Redshift.
• Când o alegi: analiză, rapoarte, evenimente, log-uri, metrici — de obicei alături de baza relațională „de lucru”.

Tot aici intră două noțiuni foarte iubite la interviuri: OLTP (online transaction processing — multe operații scurte de scriere și citire, lumea PostgreSQL) și OLAP (online analytical processing — citiri analitice grele peste toată istoria, lumea ClickHouse). Produsul scrie în baza OLTP, analiza citește copia OLAP.

Ultima familie: BD graf

Când legăturile contează mai mult decât înregistrările în sine — „prietenii prietenilor”, rutele de livrare, lanțurile de recomandări — se aleg bazele graf (Neo4j, Memgraph). Datele din ele sunt noduri (adică înregistrările) și muchii (adică legăturile dintre înregistrări); parcurgerea legăturilor la orice adâncime este o operație nativă. Într-o bază relațională, o astfel de parcurgere devine o suită de îmbinări între tabele, tot mai grea pe măsură ce adâncimea crește.

Mini-ghid: cum alegi baza pentru un proiect

1. Pornește de la întrebări, nu de la date. Ce interogări va pune produsul: punctuale „după cheie”, legate „cine ce a cumpărat”, analitice „cât pe lună”?
2. Implicit, relațională. Date legate între ele plus cost mare al greșelii (comenzi, plăți, stocuri) înseamnă PostgreSQL. Este cel mai sigur început pentru aproape orice produs.
3. Bazele specializate sunt pentru o nevoie clară. Ai multe citiri fierbinți — adaugă un cache pe Redis. A crescut analiza — replică evenimentele în ClickHouse. Ai câmpuri foarte variabile — începe cu jsonb în PostgreSQL și abia când nu mai ajunge treci la o bază documentară.
4. Calculează prețul celei de-a doua baze. Fiecare DBMS nou înseamnă sincronizarea datelor, backupuri, monitorizare și încă o tehnologie pe care echipa trebuie să o întrețină.