PERF04-BP01 Comprensione delle caratteristiche dei dati - Framework AWS Well-Architected
Guida all'implementazioneRisorse

PERF04-BP01 Comprensione delle caratteristiche dei dati

Scegli le soluzioni di gestione dei dati perché coincidano in modo ottimale con le caratteristiche, gli schemi di accesso e i requisiti dei set di dati del carico di lavoro. Nel selezionare e implementare una soluzione di gestione dei dati, è necessario assicurarsi che le caratteristiche relative a query, dimensionamento e archiviazione siano adeguate ai requisiti dei dati del carico di lavoro. Scopriamo come si abbinano le diverse opzioni di database e i modelli di dati, nonché quali opzioni di configurazione sono più adatte al tuo caso d'uso. 

AWS offre diversi motori di database dedicati, tra cui database relazionali, a chiave-valore, di documento, in memoria, a grafo, di serie temporali e di libro mastro. Ogni soluzione di gestione dei dati offre soluzioni e configurazioni adatte a gestire i tuoi casi d'uso e modelli di dati. Per il tuo carico di lavoro può essere possibile utilizzare più soluzioni di database diverse in base alle caratteristiche dei dati. Selezionando le soluzioni di database più adatte a uno specifico problema, puoi allontanarti dall'idea di database monolitico, contraddistinta da tutte le limitazioni di approccio universale, e concentrarti sulla gestione dei dati per soddisfare le esigenze del cliente.

Risultato desiderato: le caratteristiche dei dati del carico di lavoro sono documentate in modo sufficientemente dettagliato da agevolare la selezione e la configurazione di soluzioni di database di supporto e offrono informazioni approfondite su possibili alternative.

Anti-pattern comuni:

  • Non considerare modi per segmentare grandi set di dati in raccolte più piccole con caratteristiche simili, mancando così di cogliere l'opportunità di utilizzare più spesso i database dedicati, che coincidono meglio con le caratteristiche dei dati e della crescita.

  • Non identificare in anticipo gli schemi di accesso ai dati, con conseguenti costose e complesse rilavorazioni in seguito.

  • Limitare la crescita adottando strategie di archiviazione dei dati il cui dimensionamento non è rapido quanto necessario

  • Scegliere un fornitore e un tipo di database per tutti i carichi di lavoro.

  • Continuare a utilizzare una soluzione di database per via dell'esperienza e delle competenze interne relative a quel particolare tipo di soluzione.

  • Continuare con una soluzione di database perché ha funzionato bene in un ambiente on-premise.

Vantaggi dell'adozione di questa best practice: È utile conoscere tutte le soluzioni di database AWS in modo da determinare la soluzione di database corretta per i vari carichi di lavoro. Dopo aver selezionato la soluzione di database appropriata per il tuo carico di lavoro, sperimenta rapidamente ciascuna di queste offerte di database per determinare se continuano a soddisfare le esigenze del tuo carico di lavoro.

Livello di rischio associato se questa best practice non fosse adottata: Alto

  • I potenziali risparmi sui costi possono non essere identificati.

  • Sicurezza dei dati non al livello richiesto.

  • Accesso ai dati e prestazioni di archiviazione non ottimali.

Guida all'implementazione

Definisci le caratteristiche dei dati e gli schemi di accesso del tuo carico di lavoro. Esamina tutte le soluzioni di database disponibili per identificare quella più adatta ai requisiti dei tuoi dati. Per un dato carico di lavoro possono essere selezionati più database. Considera ogni servizio o gruppo di servizi e valutali singolarmente. Se identifichi possibili alternative nelle soluzioni di gestione per tutti i dati (o parte di essi), sperimenta implementazioni alternative che potrebbero portare benefici in termini di costi, sicurezza, prestazioni e affidabilità. Se viene adottato un nuovo approccio alla gestione dei dati, aggiorna la documentazione esistente.

Tipo Servizi AWS Caratteristiche chiave Casi d'uso comuni
Relazionale Amazon RDS, Amazon Aurora Integrità referenziale, transazioni ACID, schema-on-write ERP, CRM, software COTS (Commercial off-the-shelf)
Chiave-valore Amazon DynamoDB Elevata velocità di trasmissione effettiva, bassa latenza, scalabilità praticamente infinita Carrelli (e-commerce), cataloghi di prodotti, applicazioni chat
Documento Amazon DocumentDB Archiviazione documenti JSON e query su qualsiasi attributo Gestione dei contenuti (CMS), profili clienti, applicazioni per dispositivi mobili
In memoria Amazon ElastiCache, Amazon MemoryDB Latenza in microsecondi Caching, classifiche di gioco
Grafo Amazon Neptune Dati altamente relazionali in cui le loro relazioni sono significative Social networks, motori di personalizzazione, rilevamento frodi
Serie temporali Amazon Timestream Dati in cui il tempo è la dimensione principale DevOps, IoT, monitoraggio
Colonna ampia Amazon Keyspaces Carichi di lavoro Cassandra Manutenzione di apparecchiature industriali, ottimizzazione dei percorsi
Di libri mastri Amazon QLDB Libro mastro delle modifiche immutabile e verificabile tramite crittografia Sistemi di registro, assistenza sanitaria, catene di fornitura, istituzioni finanziarie

Passaggi dell'implementazione

  1. Come sono strutturati i dati (ad esempio, sono non strutturati, a chiave-valore, semi-strutturati, relazionali)?

    1. Se i dati non sono strutturati, valuta un'archiviazione a oggetti come Amazon S3 o un database NoSQL come Amazon DocumentDB.

    2. Per i dati chiave-valore, valuta DynamoDB, ElastiCache per Redis oppure MemoryDB.

    3. Se i dati hanno una struttura relazionale, qual è il livello di integrità referenziale richiesto?

      1. Per i vincoli di chiave esterna, i database relazionali come Amazon RDS e Aurora possono fornire questo livello di integrità.

      2. In genere, in un modello di dati NoSQL, i dati vengono denormalizzati in un singolo documento o in una raccolta di documenti da recuperare in un'unica richiesta, anziché essere uniti tra diversi documenti o tabelle. 

  2. È richiesta la conformità ACID (atomicità, coerenza, isolamento, durabilità)?

    1. Se sono necessarie proprietà ACID associate ai database relazionali, valuta un database relazionale come Amazon RDS e Aurora.

  3. Qual è il modello di consistenza richiesto?

    1. Se la tua applicazione può tollerare la consistenza finale, valuta un'implementazione NoSQL. Esamina le altre caratteristiche per scegliere quale database NoSQL è il più appropriato.

    2. Se è necessaria un'elevata coerenza, puoi utilizzare le elevate coerenze di lettura con DynamoDB o un database relazionale come Amazon RDS.

  4. Quali formati di query e risultati devono essere supportati (ad esempio SQL, CSV, Parque, Avro, JSON, ecc.)?

  5. Quali sono i tipi di dati, le dimensioni dei campi e le quantità complessive presenti (ad esempio testo, numero, spaziale, serie temporali calcolate, binario o BLOB, documento)?

  6. Come cambierà nel tempo l'archiviazione? In che modo questo avrà effetto sulla scalabilità?

    1. I database serverless come DynamoDB e Amazon Quantum Ledger Database si dimensioneranno automaticamente fino a uno spazio di archiviazione pressoché illimitato.

    2. Per i database relazionali sono previsti limiti superiori per l'archiviazione assegnata, al raggiungimento dei quali si rende spesso necessario partizionare orizzontalmente tali database tramite meccanismi quali lo sharding.

  7. Qual è la proporzione di query in lettura rispetto alle quelle in scrittura? Il caching potrebbe probabilmente migliorare le prestazioni?

    1. I carichi di lavoro con molte operazioni di lettura traggono beneficio da un livello di caching, che può essere rappresentato da ElastiCache oppure DAX se il database è DynamoDB.

    2. È anche possibile passare le operazioni di lettura alle repliche di lettura con database relazionali come Amazon RDS.

  8. Hanno priorità più elevata le operazioni di archiviazione e modifica OLTP, Online Transaction Processing) o quelle di recupero e report (OLAP - Online Analytical Processing)?

    1. Per l'elaborazione transazionale ad alta velocità di trasmissione effettiva, valuta un database NoSQL come DynamoDB o Amazon DocumentDB.

    2. Per le query analitiche, valuta un database colonnare come Amazon Redshift o la possibilità di esportare i dati su Amazon S3 ed eseguire l'analisi tramite Athena oppure QuickSight.

  9. Quanto sono sensibili questi dati e quale livello di protezione e crittografia richiedono?

    1. Tutti i motori Amazon RDS e Aurora supportano la crittografia dei dati inattivi tramite AWS KMS. Microsoft SQL Server e Oracle supportano anche la tecnologia nativa Transparent Data Encryption (TDE) con l'uso di Amazon RDS.

    2. Per DynamoDB, puoi utilizzare il controllo granulare degli accessi con IAM per controllare chi ha accesso a quali dati a livello di chiave.

  10. Che livello di durabilità è necessario per i dati?

    1. Aurora replica automaticamente i dati su tre zone di disponibilità all'interno di una Regione, il che significa che i dati sono altamente durevoli con minori probabilità di perdite.

    2. DynamoDB viene automaticamente replicato in più zone di disponibilità per offrire livelli elevati di disponibilità e durabilità dei dati.

    3. Amazon S3 offre il 99,999999999% di durabilità. Molti servizi di database, come Amazon RDS e DynamoDB, supportano l'esportazione di dati su Amazon S3 per la conservazione e l'archiviazione a lungo termine.

  11. I requisiti in termini di Obiettivo del tempo di ripristino (RTO) e Obiettivo del punto di ripristino (RPO) influenzano la soluzione?

    1. Amazon RDS, Aurora, DynamoDB, Amazon DocumentDB e Neptune supportano tutti sia il ripristino point-in-time, sia il backup e il ripristino on-demand. 

    2. In caso di requisiti di elevata disponibilità, è possibile replicare le tabelle DynamoDB a livello globale tramite la funzionalità Tabelle globali, mentre i cluster Aurora possono essere replicati su più Regioni grazie alla funzionalità Database globale. Inoltre, è possibile replicare i bucket S3 tra Regioni AWS grazie alla replica fra Regioni. 

  12. È presente il desiderio di abbandonare i motori di database commerciali/i costi di licenza?

    1. Valuta motori open-source come PostgreSQL e MySQL su Amazon RDS o Aurora.

    2. Sfrutta AWS DMS e AWS SCT per eseguire le migrazioni dai motori di database commerciali a quelli open-source

  13. Quali sono le aspettative operative per il database? Il passaggio ai servizi gestiti è una priorità?

    1. Utilizzare Amazon RDS, invece di Amazon EC2, e scegliere DynamoDB o Amazon DocumentDB, invece di ospitare in autonomia un database NoSQL, riduce le spese operative.

  14. Come avviene attualmente l'accesso al database? È solo un accesso da applicazione o sono presenti utenti Business Intelligence (BI) e altre applicazioni pronte all'uso connesse?

    1. Se fossero presenti dipendenze verso altri strumenti esterni, potresti dover mantenere la compatibilità con i database che essi supportano. Amazon RDS è completamente compatibile con le diverse versioni dei motori che supporta, compresi Microsoft SQL Server, Oracle, MySQL e PostgreSQL.

  15. Di seguito è riportato un elenco di possibili servizi di gestione dei dati e i loro possibili migliori utilizzi:

    1. I database relazionali memorizzano i dati con relazioni e schemi predefiniti. Questi database sono progettati per supportare le transazioni ACID (atomicità, coerenza, isolamento, durabilità) e per mantenere l'integrità referenziale e una solida coerenza dei dati. Molte applicazioni tradizionali, Enterprise Resource Planning (ERP), Customer Relationship Management (CRM) ed e-commerce utilizzano database relazionali per archiviare i propri dati. Puoi eseguire molti di questi motori di database in Amazon EC2 oppure scegliere tra i servizi AWS di database gestiti: Amazon Aurora, Amazon RDSe Amazon Redshift.

    2. I database chiave-valore sono ottimizzati per schemi di accesso di uso comune, in genere per archiviare e recuperare grandi volumi di dati. Questi database offrono tempi di risposta rapidi, anche nel caso di volumi estremi di richieste simultanee. Le Web app dal traffico elevato, i sistemi di e-commerce e le applicazioni di gaming sono casi d'uso tipici dei database chiave-valore. In AWS, puoi utilizzare Amazon DynamoDB, un database completamente gestito, multi-regione, multi-master e durevole, con capacità integrate di sicurezza, backup e ripristino, oltre al caching in memoria per le applicazioni su scala Internet.

    3. I database in memoria vengono utilizzati per applicazioni che richiedono accesso in tempo reale ai dati, bassissima latenza ed elevatissima velocità di trasmissione effettiva. Archiviando i dati direttamente in memoria, questi database forniscono una latenza di microsecondi alle applicazioni per le quali la latenza di millisecondi non è sufficiente. Puoi utilizzare database in memoria per il caching delle applicazioni, la gestione delle sessioni, l'archiviazione delle sessioni di gioco e le applicazioni geospaziali. Amazon ElastiCache è un datastore in memoria completamente gestito, compatibile con Redis oppure Memcached. Se le applicazioni presentano anche requisiti più elevati in termini di durabilità, Amazon MemoryDB per Redis li offre ed è anche un servizio di database in memoria durevole e con prestazioni ad altissima velocità.

    4. Un database di documenti è progettato per archiviare dati semistrutturati come documenti di tipo JSON. Questi database aiutano gli sviluppatori a creare e aggiornare rapidamente applicazioni quali gestione di contenuti, cataloghi e profili utente. Amazon DocumentDB è un database di documenti veloce, scalabile, ad elevata disponibilità e completamente gestito, che supporta i carichi di lavoro MongoDB.

    5. Uno store colonnare è un tipo di database NoSQL. Utilizza tabelle, righe e colonne, ma a differenza di un database relazionale, i nomi e il formato delle colonne possono variare da riga a riga all'interno della stessa tabella. In genere, gli store colonnari sono utilizzati nelle applicazioni industriali su larga scala per la manutenzione delle apparecchiature, la gestione delle flotte e l'ottimizzazione dei percorsi. Amazon Keyspaces (per Apache Cassandra) è un servizio di database colonnare gestito compatibile con Apache Cassandra, scalabile e altamente disponibile.

    6. I database a grafo vengono implementati con le applicazioni che devono navigare ed eseguire query su milioni di relazioni tra set di dati a grafo altamente connessi, con una latenza misurata in millisecondi su larga scala. Molte aziende utilizzano database a grafo per il rilevamento di attività fraudolente, i social network e i motori di raccomandazione. Amazon Neptune è un servizio di database a grafo veloce, affidabile e completamente gestito che semplifica la creazione e l'esecuzione di applicazioni che funzionano con set di dati altamente connessi.

    7. I database di serie temporali sono efficienti per raccogliere, sintetizzare e derivare informazioni approfondite dai dati che cambiano nel tempo. I database di serie temporali sono spesso utilizzati dalle applicazioni IoT, DevOps e dalla telemetria industriale. Amazon Timestream è un servizio di database di serie temporali veloce, scalabile e completamente gestito per le applicazioni IoT ed operative che semplifica la memorizzazione e l'analisi di trilioni di eventi al giorno.

    8. I database di libri mastri forniscono un'autorità centralizzata e affidabile per mantenere un registro delle transazioni scalabile, immutabile e verificabile tramite crittografia per ogni applicazione. I database di libri mastri vengono utilizzati per sistemi di record, catena di fornitura, registrazioni e persino transazioni bancarie. Amazon Quantum Ledger Database (Amazon QLDB) è un database di libro mastro completamente gestito che fornisce un registro delle transazioni trasparente, immutabile e verificabile tramite crittografia, di proprietà di un'autorità centrale attendibile. Amazon QLDB tiene traccia di ogni modifica ai dati dell'applicazione e conserva una cronologia completa e verificabile delle modifiche nel corso del tempo.

Livello di impegno per il piano di implementazione: In caso di spostamento del carico di lavoro da una soluzione di database a un'altra, può essere richiesto un elevato livello di impegno per riprogettare i dati e l'applicazione.  

Risorse

Documenti correlati:

Video correlati:

Esempi correlati: