// data & ai · giornale tecnico MILANO ● LIVE 00:00:00

Database distribuiti: componenti, tipi e il trade-off del teorema CAP

Componenti, tipi e meccanismi dei database distribuiti, fino al trade-off del teorema CAP tra consistenza e disponibilità.

Scalare un database un tempo voleva dire comprare un server più grande. Oggi il volume dei dati rende quell’approccio impraticabile, e i sistemi vengono distribuiti su più macchine, region e persino provider cloud. Il guadagno è scala orizzontale e resilienza; il prezzo è che i dati diventano fisicamente frammentati.

Come funziona

Un database distribuito è un insieme di database interconnessi che all’applicazione appare come uno solo. Il software che mantiene questa illusione è il DDBMS: instrada le query al nodo giusto, sincronizza i dati e recupera dai guasti. In lettura un coordinator raccoglie i risultati dai nodi; in scrittura serve garantire che il dato non vada perso, e qui entrano gli algoritmi di consenso come Paxos o Raft, che richiedono l’accordo della maggioranza dei nodi prima di confermare la transazione.

Tipi e componenti

Le architetture si dividono in homogeneous (stesso software e schema su ogni nodo), heterogeneous (software o schemi diversi, con il DDBMS a fare da traduttore) e federated (database autonomi che partecipano a uno schema globale). I meccanismi chiave sono tre: il partitioning o sharding (orizzontale per righe, verticale per colonne), la replication con copie su più nodi per l’alta disponibilità, e le distributed transaction, tipicamente gestite con un two-phase commit.

Il trade-off del teorema CAP

Il teorema CAP dice che consistenza, disponibilità e tolleranza alle partizioni non possono coesistere tutte insieme. Quando la rete si partiziona bisogna scegliere: servire dati potenzialmente stantii (privilegiando la disponibilità) o rifiutare la richiesta finché i nodi non si risincronizzano (privilegiando la consistenza). Per carichi ACID relazionali gli esempi sono CockroachDB e Google Cloud Spanner; per la scala con priorità alla disponibilità, Apache Cassandra e Amazon DynamoDB.

In sintesi

  • Un database distribuito scambia semplicità con scala orizzontale e resilienza, al prezzo di latenza di rete e troubleshooting complesso.
  • Sharding, replication e distributed transaction sono i tre meccanismi che reggono l’architettura.
  • Il teorema CAP impone una scelta tra consistenza e disponibilità durante le partizioni di rete.

Fonte: What is a distributed database? Types, components, and use cases

Condividi X Facebook LinkedIn WhatsApp Email

// scritto da

Fernando

Hai qualcosa da aggiungere? Unisciti alla discussione.

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Altri dell'autore

dalla stessa firma