Condividi tramite

Informazioni sui modelli di archivio dati

  • Articolo

I sistemi aziendali moderni gestiscono volumi sempre più grandi di dati eterogenei. Questa eterogeneità significa che un unico archivio dati non è in genere l'approccio migliore. È invece spesso preferibile archiviare tipi diversi di dati in archivi dati diversi, ognuno incentrato su un carico di lavoro o un modello di utilizzo specifico. Il termine persistenza poliglotta viene usato per descrivere le soluzioni che usano una combinazione di tecnologie di archivi dati. È quindi importante comprendere i principali modelli di archiviazione e i relativi compromessi.

La selezione dell'archivio dati corretto per le proprie esigenze è una decisione di progettazione fondamentale. Esistono centinaia di implementazioni tra cui scegliere nei database SQL e NoSQL. Gli archivi dati vengono spesso classificati in base a come strutturano i dati e ai tipi di operazioni supportate. Questo articolo descrive molti dei modelli di archiviazione più comuni. Si noti che una particolare tecnologia di archivio dati può supportare più modelli di archiviazione. Ad esempio, un sistema di gestione di database relazionali (RDBMS) può anche supportare l'archiviazione chiave/valore o di grafi. In effetti, esiste una tendenza generale per il cosiddetto supporto multimodelle , in cui un singolo sistema di database supporta diversi modelli. Ma è comunque utile comprendere i diversi modelli a livello generale.

Non tutti gli archivi dati in una determinata categoria forniscono lo stesso set di funzionalità. La maggior parte degli archivi dati forniscono funzionalità sul lato server per query ed elaborazione di dati. A volte questa funzionalità è incorporata nel motore di archiviazione dati. In altri casi, le funzionalità di elaborazione e archiviazione dati sono separate e possono essere presenti diverse opzioni per l'elaborazione e l'analisi. Gli archivi dati supportano anche diverse interfacce di gestione e programmatiche.

In genere, è consigliabile iniziare stabilendo qual è il modello di archiviazione più adatto alle proprie esigenze. Si consideri quindi un archivio dati specifico all'interno di tale categoria, in base a fattori quali set di funzionalità, costo e facilità di gestione.

Nota

Altre informazioni sull'identificazione e l'analisi dei requisiti del servizio dati per l'adozione del cloud in Microsoft Cloud Adoption Framework per Azure. Analogamente, è anche possibile ottenere informazioni sulla selezione di strumenti e servizi di archiviazione.

Sistemi di gestione di database relazionali

I database relazionali organizzano i dati come una serie di tabelle bidimensionali con righe e colonne. La maggior parte dei fornitori fornisce un dialetto del linguaggio SQL (Structured Query Language) per il recupero e la gestione dei dati. Un sistema di gestione di database relazionali implementa in genere un meccanismo coerente a livello transazionale conforme al modello ACID (Atomic, Consistent, Isolated, Durable) per l'aggiornamento delle informazioni.

Un sistema di gestione di database relazionali supporta in genere un modello di schema in scrittura in cui la struttura dei dati viene definita anticipatamente e tutte le operazioni di lettura o scrittura devono usare lo schema.

Questo modello è molto utile quando le garanzie di coerenza assoluta sono importanti, in cui tutte le modifiche sono atomiche e le transazioni lasciano sempre i dati in uno stato coerente. Tuttavia, un rdbms in genere non può aumentare orizzontalmente senza partizionare i dati in qualche modo. Inoltre, i dati in un set di dati RDBMS devono essere normalizzati, che non sono appropriati per ogni set di dati.

Servizi di Azure

Carico di lavoro

  • I record vengono creati e aggiornati di frequente.
  • Occorre completare più operazioni in una singola transazione.
  • Le relazioni vengono applicate usando i vincoli del database.
  • Per ottimizzare le prestazioni delle query vengono usati gli indici.

Tipo di dati

  • I dati sono altamente normalizzati.
  • Sono necessari e vengono applicati schemi del database.
  • Relazioni molti-a-molti tra le entità di dati nel database.
  • Nello schema sono definiti vincoli imposti a tutti i dati nel database.
  • I dati richiedono integrità elevata. Gli indici e le relazioni devono essere gestiti in modo accurato.
  • I dati richiedono la coerenza assoluta. Le transazioni funzionano in modo da garantire che tutti i dati siano coerenti al 100% per tutti gli utenti e i processi.
  • Le dimensioni delle singole voci di dati sono di piccole e medie dimensioni.

Esempi

  • Gestione articoli
  • Gestione degli ordini
  • Database di report
  • Contabilità

Archivi chiave/valore

Un archivio chiave/valore associa ogni valore di dati a una chiave univoca. La maggior parte degli archivi chiave/valore supporta solo semplici operazioni di query, inserimento ed eliminazione. Per modificare parzialmente o completamente un valore, un'applicazione deve sovrascrivere i dati esistenti dell'intero valore. Nella maggior parte delle implementazioni la lettura o scrittura di un singolo valore è un'operazione atomica.

Un'applicazione può archiviare dati arbitrari come set di valori. Tutte le informazioni sullo schema devono essere fornite dall'applicazione. L'archivio chiave/valore recupera o archivia semplicemente il valore in base alla chiave.

Diagram of a key-value store

Gli archivi chiave/valore sono altamente ottimizzati per le applicazioni che eseguono ricerche semplici, ma sono meno adatti se è necessario eseguire query sui dati in archivi chiave/valore diversi. Anche gli archivi chiave/valore non sono ottimizzati per l'esecuzione di query in base al valore.

Un singolo archivio chiave/valore può essere estremamente scalabile in quanto l'archivio dati può distribuire facilmente i dati tra più nodi in computer separati.

Servizi di Azure

Carico di lavoro

  • L'accesso ai dati viene eseguito usando una singola chiave, ad esempio un dizionario.
  • Non sono necessari join, blocchi o unioni.
  • Non vengono usati meccanismi di aggregazione.
  • In genere non vengono usati indici secondari.

Tipo di dati

  • Ogni chiave è associata a un singolo valore.
  • Non viene applicata alcuna imposizione dello schema.
  • Non esistono relazioni tra le entità.

Esempi

  • Memorizzazione dei dati nella cache
  • Gestione della sessione
  • Gestione profilo e preferenze utente
  • Raccomandazione prodotti e visualizzazione annunci

Database di documenti

Un database di documenti archivia una raccolta di documenti, in cui ogni documento è costituito da campi e dati denominati. I dati possono essere semplici valori o elementi complessi, ad esempio elenchi e raccolte figlio. I documenti vengono recuperati da chiavi univoche.

In genere, un documento contiene i dati per una singola entità, ad esempio un cliente o un ordine. Un documento può contenere informazioni che verrebbero distribuite tra diverse tabelle relazionali in un rdbms. I documenti non devono avere la stessa struttura. Le applicazioni possono archiviare dati diversi nei documenti quando i requisiti aziendali cambiano.

Diagram of a document store

Servizio di Azure

Carico di lavoro

  • Le operazioni di inserimento e aggiornamento sono comuni.
  • Nessun mancata corrispondenza dell'impedenza tra modello a oggetti e relazionale. I documenti possono offrire una corrispondenza migliore con le strutture di oggetti usate nel codice dell'applicazione.
  • I singoli documenti vengono recuperati e scritti come un unico blocco.
  • I dati richiedono un indice in più campi.

Tipo di dati

  • I dati possono essere gestiti in modo denormalizzato.
  • Le dimensioni dei dati dei singoli documenti sono relativamente ridotte.
  • Ogni tipo di documento può usare uno schema proprio.
  • I documenti possono contenere campi facoltativi.
  • I dati dei documenti sono semistrutturati, vale a dire che i tipi di dati di ogni campo non sono definiti in modo rigido.

Esempi

  • Catalogo prodotti
  • Gestione dei contenuti
  • Gestione articoli

Database a grafo

Un database di grafi archivia due tipi di informazioni, nodi e bordi. Gli archi specificano le relazioni tra i nodi. I nodi e i bordi possono avere proprietà che forniscono informazioni sul nodo o sul bordo, in modo simile alle colonne di una tabella. I bordi possono avere anche una direzione che indica la natura della relazione.

I database a grafo possono eseguire query in modo efficiente attraverso la rete di nodi e archi e analizzare le relazioni tra entità. Il diagramma seguente illustra un database del personale di un'organizzazione strutturato come un grafo. Le entità sono dipendenti e reparti e gli archi indicano relazioni di report e i reparti in cui lavorano i dipendenti.

Diagram of a document database

Questa struttura semplifica l'esecuzione di query, ad esempio "Trovare tutti i dipendenti che segnalano direttamente o indirettamente a Sarah" o "Chi lavora nello stesso reparto di John?" Per grafici di grandi dimensioni con molte entità e relazioni, è possibile eseguire analisi molto complesse molto rapidamente. Molti database di grafi forniscono un linguaggio di query che è possibile usare per esaminare in modo efficiente una rete di relazioni.

Servizi di Azure

Carico di lavoro

  • Relazioni complesse tra elementi di dati che coinvolgono molti hop tra elementi di dati correlati.
  • Le relazioni tra gli elementi di dati sono dinamiche e cambiano nel tempo.
  • Le relazioni tra oggetti sono entità di prima classe e non richiedono chiavi esterne e join da attraversare.

Tipo di dati

  • Nodi e relazioni.
  • I nodi sono simili a righe di tabella o documenti JSON.
  • Le relazioni sono importanti quanto i nodi e sono esposte direttamente nel linguaggio di query.
  • Gli oggetti compositi, ad esempio una persona con più numeri di telefono, tendono a essere suddivisi in nodi separati di dimensioni inferiori, combinati con relazioni attraversabili

Esempi

  • Organigrammi
  • Grafi sociali
  • Rilevamento delle frodi
  • Motori di raccomandazione

Analisi dei dati

Gli archivi di analisi dei dati forniscono soluzioni parallele massive per l'inserimento, l'archiviazione e l'analisi dei dati. I dati vengono distribuiti tra più server per ottimizzare la scalabilità. I formati di file di dati di grandi dimensioni, ad esempio file delimitatori (CSV), parquet e ORC sono ampiamente usati nell'analisi dei dati. I dati cronologici vengono in genere archiviati in archivi dati, ad esempio l'archiviazione BLOB o Azure Data Lake Archiviazione Gen2, a cui viene quindi eseguito l'accesso da Azure Synapse, Databricks o HDInsight come tabelle esterne. Uno scenario tipico che usa i dati archiviati come file Parquet per le prestazioni, è descritto nell'articolo Usare tabelle esterne con Synapse SQL.

Servizi di Azure

Carico di lavoro

  • Analisi dei dati
  • Enterprise BI

Tipo di dati

  • Dati cronologici da più origini.
  • In genere denormalizzato in uno schema "star" o "snowflake", costituito da tabelle dei fatti e delle dimensioni.
  • In genere caricato con nuovi dati in base a una pianificazione.
  • Le tabelle delle dimensioni includono spesso più versioni cronologiche di un'entità, detta dimensione a modifica lenta.

Esempi

  • Data warehouse aziendale

Database a colonne

Un database a colonne consente di organizzare i dati in righe e colonne. Nella sua forma più semplice, un database a colonne può risultare molto simile a un database relazionale, almeno a livello concettuale. L'efficacia di un database a colonne sta nell'approccio denormalizzato per strutturare i dati di tipo sparse.

È possibile considerare un database a colonne come contenente dati tabulari con righe e colonne, ma le colonne sono suddivise in gruppi, noti come famiglie di colonne. Ogni famiglia di colonna contiene un set di colonne correlate tra loro in modo logico e che vengono in genere recuperate o modificate come un'unità. Altri dati di cui si accede separatamente possono essere archiviati in famiglie di colonne separate. All'interno di una famiglia di colonne, è possibile aggiungere nuove colonne in modo dinamico e le righe possono essere di tipo sparse, vale a dire una riga non deve necessariamente avere un valore per ogni colonna.

Nel diagramma seguente viene illustrato un esempio con due famiglie di colonne, Identity e Contact Info. I dati per una singola entità contengono la stessa chiave di riga in ogni famiglia di colonna. Questa struttura, in cui le righe per un determinato oggetto in una famiglia di colonne possono variare in modo dinamico, rappresenta un vantaggio importante dell'approccio della famiglia di colonne, rendendo questa forma di archivio di dati molto adatta all'archiviazione di dati strutturati e volatili.

Diagram of a column-family database

A differenza di un archivio chiave/valore o un di database di documenti, la maggior parte dei database a colonne archiviano i dati in ordine di chiave, anziché calcolare un hash. Molte implementazioni consentono di creare indici su colonne specifiche in una famiglia di colonne. Gli indici consentono di recuperare i dati in base al valore delle colonne, anziché della chiave di riga.

Le operazioni di lettura e scrittura per una riga sono in genere atomiche con una singola famiglia di colonne, anche se alcune implementazioni offrono l'atomicità sull'intera riga, con estensione su più famiglie di colonne.

Servizi di Azure

Carico di lavoro

  • La maggior parte dei database a colonne esegue le operazioni di scrittura molto rapidamente.
  • Le operazioni di aggiornamento ed eliminazione sono rare.
  • Progettato per offrire accesso a bassa latenza e velocità effettiva elevata.
  • Supporta l'accesso query semplice a un particolare set di campi all'interno di un record di dimensioni molto superiori.
  • Scalabilità elevata.

Tipo di dati

  • I dati vengono archiviati in tabelle composte da una colonna chiave e una o più famiglie di colonne.
  • Le specifiche colonne possono variare per singole righe.
  • Le singole celle sono accessibili tramite comandi Get e Put
  • Usando un comando di analisi vengono restituite più righe.

Esempi

  • Consigli
  • Personalizzazione
  • Dati di sensori
  • Telemetria
  • Messaggistica
  • Analisi dei social media
  • Web Analytics
  • Monitoraggio attività
  • Meteo e altri dati di serie temporali

Database di motori di ricerca

Un database del motore di ricerca consente alle applicazioni di cercare informazioni contenute in archivi dati esterni. Un database del motore di ricerca può indicizzare volumi elevati di dati e fornire l'accesso quasi in tempo reale a questi indici.

Gli indici possono essere multidimensionali e possono supportare le ricerche di testo libero su grandi volumi di dati di testo. L'indicizzazione può essere eseguita mediante un modello pull, generato dal database del motore di ricerca o tramite un modello push, avviato dal codice dell'applicazione esterna.

La ricerca può essere esatta o fuzzy. Una ricerca fuzzy individua documenti che corrispondono a un set di termini e calcola il grado di corrispondenza. Alcuni motori di ricerca supportano inoltre l'analisi linguistica che può restituire corrispondenze basate su sinonimi, le espansioni di genere (ad esempio, la corrispondenza di dogs a pets) e lo stemming, la ricerca di parole con la stessa radice.

Servizio di Azure

Carico di lavoro

  • Indici di dati da più origini e servizi.
  • Le query sono ad hoc e possono essere complesse.
  • È necessaria la ricerca full-text.
  • Sono necessarie query self-service ad hoc.

Tipo di dati

  • Testo semistrutturato o non strutturato
  • Testo con riferimento a dati strutturati

Esempi

  • Cataloghi prodotti
  • Ricerca nel sito
  • Registrazione

Database di serie temporali

I dati di serie temporali sono un set di valori organizzati in base a criteri temporali. I database time series raccolgono in genere grandi quantità di dati in tempo reale da un numero elevato di origini. Gli aggiornamenti sono rari e le eliminazioni vengono spesso eseguite come operazioni di massa. Anche se i record scritti in un database di serie temporali sono generalmente di dimensioni ridotte, sono spesso un numero elevato e le dimensioni totali dei dati possono aumentare rapidamente.

Servizio di Azure

Carico di lavoro

  • I record vengono in genere aggiunti in sequenza in ordine temporale.
  • Le stragrande maggioranza delle operazioni (95-99%) è di scrittura.
  • Gli aggiornamenti sono rari.
  • Le eliminazioni vengono eseguite in blocco e in blocchi o record contigui.
  • I dati sono letti in sequenza in ordine crescente o decrescente, spesso in parallelo.

Tipo di dati

  • Un timestamp viene usato come chiave primaria e meccanismo di ordinamento.
  • I tag possono definire informazioni aggiuntive sul tipo, l'origine e altre informazioni sulla voce.

Esempi

  • Monitoraggio e telemetria eventi.
  • Dati di sensori o altri dati IoT.

Archiviazione di oggetti

L'archiviazione di oggetti è ottimizzata per l'archiviazione e recupero di oggetti binari di grandi dimensioni come immagini, file, flussi audio e video, documenti e oggetti dati delle applicazioni di grandi dimensioni e immagini disco di macchine virtuali. I file di dati di grandi dimensioni vengono usati anche in questo modello, ad esempio file delimitatore (CSV), parquet e ORC. Gli archivi oggetti possono gestire grandi quantità di dati non strutturati.

Servizio di Azure

Carico di lavoro

  • Identificato dalla chiave.
  • Il contenuto è in genere un asset, ad esempio un delimitatore, un'immagine o un file video.
  • Il contenuto deve essere durevole ed esterno a qualsiasi livello applicazione.

Tipo di dati

  • I dati sono di grandi dimensioni.
  • Il valore è opaco.

Esempi

  • Immagini, video, documenti di Office, file PDF
  • HTML statico, JSON, CSS
  • File di log e di controllo
  • Backup del database

File condivisi

In alcuni casi, l'uso di semplici file flat può essere il mezzo più efficace per l'archiviazione e il recupero delle informazioni. L'uso della condivisione dei file consente di accedere ai file attraverso una rete. Predisponendo la sicurezza e i meccanismi di controllo di accesso simultaneo appropriati, la condivisione dei dati in questo modo consente ai servizi distribuiti di fornire un accesso ai dati estremamente scalabile per l'esecuzione di operazioni di base di basso livello come semplici richieste di lettura e scrittura.

Servizio di Azure

Carico di lavoro

  • Migrazione da app esistenti che interagiscono con il file system.
  • Richiede l'interfaccia SMB.

Tipo di dati

  • File in un set gerarchico di cartelle.
  • Accessibile con librerie di I/O standard.

Esempi

  • File legacy
  • Contenuto condiviso accessibile tra più macchine virtuali o istanze di app

Grazie a questa comprensione dei diversi modelli di archiviazione dei dati, il passaggio successivo consiste nel valutare il carico di lavoro e l'applicazione e decidere quale archivio dati soddisfa le esigenze specifiche. Usare l'albero delle decisioni di archiviazione dei dati per facilitare questo processo.

Passaggi successivi