Tipus de bases de dades

Classificació per ús

Més enllà del model de dades, les bases de dades es classifiquen sovint per l'ús que se'n fa, ja que cada cas d'ús té requisits molt diferents en termes de rendiment, consistència i estructura de les consultes.

Bases de dades OLTP (Online Transaction Processing)

Les bases de dades OLTP estan optimitzades per a les operacions transaccionals del dia a dia: inserir una comanda, actualitzar l'estoc d'un producte, registrar un pagament, crear un nou usuari. Aquestes operacions són moltes, curtes i afecten poques files alhora.

Característiques:

Moltes transaccions concurrents (desenes o centenars per segon).
Operacions curtes que afecten poques files (1-100 files).
Esquema normalitzat per evitar redundàncies.
Optimitzades per a escriptura ràpida i lectura puntual.
Consistència ACID estricta.

Exemples de sistemes OLTP:

Sistema de reserves d'un hotel
Plataforma bancària (transferències, pagaments)
TPV (terminal punt de venda) d'un supermercat
Sistema de tickets de suport

Motors típics: PostgreSQL, MySQL/MariaDB, SQL Server, Oracle.

flowchart LR
    U1["App web"] --> OLTP["BD OLTP\nNormalitzada\nACID completes"]
    U2["App mobil"] --> OLTP
    U3["TPV"] --> OLTP
    OLTP --> D["Dades\noperacionals"]

Bases de dades OLAP (Online Analytical Processing)

Les bases de dades OLAP estan optimitzades per a consultes analítiques complexes que agreguen grans volums de dades històriques: quants productes s'han venut per regió, quines categories de clients són més rendibles, quina és la tendència de vendes dels últims 5 anys.

Característiques:

Poques transaccions d'escriptura, però consultes de lectura molt complexes.
Les consultes agrupen milions o bilions de files.
Esquema desnormalitzat (esquema en estrella o en floc de neu) per a rendiment de lectura.
Dades històriques, normalment carregades en lots (batch ETL).
Consistència eventual acceptable.

Esquema en estrella:

flowchart TD
    F["Taula de fets\n(vendes)"]
    F --> D1["Dimensió temps\n(any, mes, dia)"]
    F --> D2["Dimensió producte\n(categoria, marca)"]
    F --> D3["Dimensió client\n(regió, segment)"]
    F --> D4["Dimensió botiga\n(país, format)"]

Exemples de sistemes OLAP:

Data Warehouse corporatiu
Sistema de reporting mensual per a la direcció
Anàlisi de campanyes de marketing
Dashboard de KPIs empresarials

Motors típics: Snowflake, Amazon Redshift, Google BigQuery, ClickHouse, Microsoft Analysis Services, DuckDB.

ETL i la distinció OLTP/OLAP

En una empresa real, normalment coexisteixen un sistema OLTP (per a les operacions del dia a dia) i un sistema OLAP (per a l'anàlisi). Les dades flueixen del primer al segon mitjançant un procés ETL (Extract, Transform, Load):

flowchart LR
    OLTP1["BD OLTP\n(vendes)"] --> ETL["procés ETL\n(nightly batch)"]
    OLTP2["BD OLTP\n(CRM)"] --> ETL
    OLTP3["BD OLTP\n(ERP)"] --> ETL
    ETL --> DW["Data Warehouse\n(OLAP)"]
    DW --> BI["Eines BI\n(Power BI, Tableau)"]

AC0372/01/04 — Miniactivitat

RA1 · CA1.3

Classifiqueu cadascuna de les operacions seguents com a OLTP o OLAP:

Registrar la venda d'un producte en un TPV.
Calcular els ingressos totals per mes dels últims 3 anys agrupats per categoria de producte.
Actualitzar l'adreça d'enviament d'un client.
Identificar quins 10 productes han tingut més devolucions el trimestre passat.
Processar el pagament d'una factura.

Bases de dades NoSQL

Com ja hem vist en el capítol de models de dades, les bases de dades NoSQL (Not Only SQL) agrupen tots els sistemes que no segueixen el model relacional. Sorgiren a finals dels 2000 per respondre als desafiaments d'escala de les grans empreses d'internet (Google, Amazon, Facebook).

Quan NO usar NoSQL:

Les dades són clarament estructurades i les relacions importants.
Es necessita consistència ACID estricta.
L'equip té més experiència amb SQL.
Es fan moltes consultes ad-hoc imprevisibles.

Quan considerar NoSQL:

Les dades són semiestructurades o la seva estructura varia molt.
Cal escalar horitzontalment a centenars o milers de servidors.
Els patrons de consulta són molt predictibles i simples.
El rendiment en escriptura massiva és crític.

Tipus	Exemples	Quan usar
Document	MongoDB, CouchDB	Catàlegs, perfils d'usuari, CMS
Clau-valor	Redis, Memcached, DynamoDB	Cache, sessions, cues de missatges
Columnar	Cassandra, HBase	IoT, logs, sèries temporals a gran escala
Graf	Neo4j, Amazon Neptune	Xarxes socials, recomanadors, frau

Bases de dades NewSQL

Les bases de dades NewSQL són una generació de SGBD relacionals (SQL complet + propietats ACID) però dissenyades per a l'escalabilitat horitzontal dels sistemes NoSQL. Pretenen combinar el millor dels dos mons.

Exemples:

Google Spanner: BD global distribuïda de Google, usada internament i disponible a GCP. Suporta transaccions globals amb consistència externa.
CockroachDB: Compatible amb PostgreSQL, dissenyat per sobreviure a fallades de centres de dades sencers.
TiDB: BD híbrida MySQL-compatible amb escalabilitat horitzontal.
YugabyteDB: Compatible amb PostgreSQL, arquitectura distribuïda.

NewSQL té sentit en grans empreses que necessiten la consistència ACID d'un SGBD relacional però amb un volum de dades i transaccions que supera la capacitat d'un sol servidor.

Bases de dades en memòria (In-Memory)

Les bases de dades en memòria emmagatzemen les dades principalment en la RAM del servidor, en comptes del disc. Això les fa ordres de magnitud més ràpides per a operacions de lectura i escriptura, però amb la limitació que la capacitat està restringida per la quantitat de RAM disponible i que les dades són volàtils si no hi ha un mecanisme de persistència addicional.

Exemples:

Redis: El més popular. Clau-valor en memòria amb suport per a llistes, conjunts, hashes i més. S'usa com a cache, broker de missatges i BD en temps real. Suporta persistència opcional.
Memcached: Cache distribuit en memòria, més simple que Redis.
VoltDB: BD relacional en memòria amb SQL complet i ACID.
SAP HANA: BD en memòria empresarial d'SAP, usada per a aplicacions ERP d'alt rendiment.

Cas d'ús típic: Cache de sessions d'usuari en una aplicació web d'alta concurrència. Quan un usuari inicia sessió, el token es desa a Redis en comptes de la BD relacional, reduint dràsticament la latència de les peticions.

Redis a la pràctica

En gairebé tota arquitectura web moderna, Redis coexisteix amb un SGBD relacional: - La BD relacional (PostgreSQL, MySQL) emmagatzema les dades permanents. - Redis fa de cache per als resultats de consultes freqüents, sessions d'usuari i cues de tasques asincrones.

Resum comparatiu

---
config:
  theme: base
  themeVariables:
    background: "#FFFFFF"
    primaryTextColor: "#1F2937"
    secondaryTextColor: "#fafafa"
    lineColor: "#64748B"
    nodeBorder: "#CBD5E1"
    cScale0: "#2563EB"
    cScale1: "#16A34A"
    cScale2: "#7C3AED"
---
flowchart LR
    BD["Tipus de BD"]
    BD --> OLTP["OLTP\nTransaccions operacionals\nPostgreSQL, MySQL, SQL Server"]
    BD --> OLAP["OLAP\nAnàlisi i reporting\nSnowflake, Redshift, BigQuery"]
    BD --> NoSQL["NoSQL\nFlexibilitat i escala\nMongoDB, Redis, Cassandra, Neo4j"]
    BD --> NewSQL["NewSQL\nEscala + consistència\nSpanner, CockroachDB, TiDB"]
    BD --> InMem["En memòria\nUltra-baixa latència\nRedis, Memcached, VoltDB"]

    style OLTP fill:#2563EB,color:#fafafa
    style OLAP fill:#16A34A,color:#fafafa
    style NoSQL fill:#7C3AED,color:#fafafa
    style NewSQL fill:#64748B,color:#fafafa
    style InMem fill:#475569,color:#fafafa

AC0372/01/05 — Miniactivitat

RA1 · CA1.3, CA1.4

Una empresa de logística està dissenyant el seu sistema d'informació. Identifiqueu quin tipus de BD seria més adequat per a cada cas:

Registre de lliuraments i actualització d'estats de paquets en temps real.
Dashboard mensual per al director comercial amb mètriques de lliuraments per ruta i client.
Cache dels estats dels paquets per a l'app mòbil del repartidor (ha de ser ultraràpida).
Graf de les relacions entre orígens, destins i rutes per optimitzar el routing.
Historial complet de tots els lliuraments dels últims 10 anys per a auditoria.