# PERF 4 In che modo selezioni la soluzione di database?
<a name="w2aac19c11b5c11"></a>

 La soluzione di database ottimale per un determinato sistema può variare in base ai requisiti di disponibilità, coerenza, tolleranza della partizione, latenza, durata, scalabilità e capacità di query. Molti sistemi utilizzano diverse soluzioni di database per vari sottosistemi e consentono funzionalità differenti per migliorare le prestazioni. Selezionare la soluzione e le funzionalità del database sbagliate per un sistema può ridurre l'efficienza delle prestazioni. 

**Topics**
+ [PERF04-BP01 Comprensione delle caratteristiche dei dati](perf_right_database_solution_understand_char.md)
+ [PERF04-BP02 Valutazione delle opzioni disponibili](perf_right_database_solution_evaluate_options.md)
+ [PERF04-BP03 Raccolta e registrazione dei parametri delle prestazioni del database](perf_right_database_solution_collect_metrics.md)
+ [PERF04-BP04 Scelta dello spazio di archiviazione dei dati in base ai modelli di accesso](perf_right_database_solution_access_patterns.md)
+ [PERF04-BP05 Ottimizzazione dello spazio di archiviazione dei dati in base ai modelli e ai parametri di accesso](perf_right_database_solution_optimize_metrics.md)

# PERF04-BP01 Comprensione delle caratteristiche dei dati
<a name="perf_right_database_solution_understand_char"></a>

 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
<a name="implementation-guidance"></a>

 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](https://aws.amazon.com/products/storage/data-lake-storage/) o un database NoSQL come [Amazon DocumentDB.](https://aws.amazon.com/documentdb/) 

   1.  Per i dati chiave-valore, valuta [DynamoDB](https://aws.amazon.com/documentdb/), [ElastiCache per Redis](https://aws.amazon.com/elasticache/redis/) oppure [MemoryDB.](https://aws.amazon.com/memorydb/) 

   1.  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](https://aws.amazon.com/rds/) e [Aurora](https://aws.amazon.com/rds/aurora/) possono fornire questo livello di integrità. 

      1.  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.  

1.  È 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](https://aws.amazon.com/rds/) e [Aurora.](https://aws.amazon.com/rds/aurora/) 

1.  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](https://aws.amazon.com/nosql/) è il più appropriato. 

   1.  Se è necessaria un'elevata coerenza, puoi utilizzare le elevate coerenze di lettura con [DynamoDB](https://aws.amazon.com/documentdb/) o un database relazionale come [Amazon RDS](https://aws.amazon.com/rds/). 

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

1.  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)? 

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

   1.  I database serverless come [DynamoDB](https://aws.amazon.com/documentdb/) e [Amazon Quantum Ledger Database](https://aws.amazon.com/qldb/) si dimensioneranno automaticamente fino a uno spazio di archiviazione pressoché illimitato. 

   1.  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. 

1.  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](https://aws.amazon.com/elasticache/) oppure [DAX](https://aws.amazon.com/dynamodb/dax/) se il database è DynamoDB. 

   1.  È anche possibile passare le operazioni di lettura alle repliche di lettura con database relazionali come [Amazon RDS](https://aws.amazon.com/rds/). 

1.  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. 

   1.  Per le query analitiche, valuta un database colonnare come [Amazon Redshift](https://aws.amazon.com/redshift/) o la possibilità di esportare i dati su Amazon S3 ed eseguire l'analisi tramite [Athena](https://aws.amazon.com/athena/) oppure [QuickSight.](https://aws.amazon.com/quicksight/) 

1.  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. 

   1.  Per DynamoDB, puoi utilizzare il controllo granulare degli accessi con [IAM](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/access-control-overview.html) per controllare chi ha accesso a quali dati a livello di chiave. 

1.  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. 

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

   1.  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. 

1.  I requisiti in termini di [Obiettivo del tempo di ripristino (RTO) e Obiettivo del punto di ripristino (RPO)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html) 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.  

   1.  In caso di requisiti di elevata disponibilità, è possibile replicare le tabelle DynamoDB a livello globale tramite la funzionalità [Tabelle globali,](https://aws.amazon.com/dynamodb/global-tables/) 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.  

1.  È 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. 

   1.  Sfrutta [AWS DMS](https://aws.amazon.com/dms/) e [AWS SCT](https://aws.amazon.com/dms/schema-conversion-tool/) per eseguire le migrazioni dai motori di database commerciali a quelli open-source 

1.  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. 

1.  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. 

1.  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](https://aws.amazon.com/products/databases/): [Amazon Aurora](https://aws.amazon.com/rds/aurora), [Amazon RDS](https://aws.amazon.com/rds)e [Amazon Redshift](https://aws.amazon.com/redshift). 

   1.  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](https://aws.amazon.com/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. 

   1.  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](https://aws.amazon.com/elasticache/) è un datastore in memoria completamente gestito, compatibile con [Redis](https://aws.amazon.com/elasticache/redis/) oppure [Memcached](https://aws.amazon.com/elasticache/memcached). Se le applicazioni presentano anche requisiti più elevati in termini di durabilità, [Amazon MemoryDB per Redis](https://aws.amazon.com/memorydb/) li offre ed è anche un servizio di database in memoria durevole e con prestazioni ad altissima velocità. 

   1.  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](https://aws.amazon.com/documentdb/) è un database di documenti veloce, scalabile, ad elevata disponibilità e completamente gestito, che supporta i carichi di lavoro MongoDB. 

   1.  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)](https://aws.amazon.com/mcs/) è un servizio di database colonnare gestito compatibile con Apache Cassandra, scalabile e altamente disponibile. 

   1.  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](https://aws.amazon.com/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. 

   1.  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](https://aws.amazon.com/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. 

   1.  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)](https://aws.amazon.com/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
<a name="resources"></a>

 **Documenti correlati:** 
+  [Database su cloud AWS ](https://aws.amazon.com/products/databases/?ref=wellarchitected) 
+  [Memorizzazione nella cache di database AWS ](https://aws.amazon.com/caching/database-caching/?ref=wellarchitected) 
+  [Amazon DynamoDB Accelerator ](https://aws.amazon.com/dynamodb/dax/?ref=wellarchitected) 
+  [Best practice di Amazon Aurora ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.BestPractices.html?ref=wellarchitected) 
+  [Prestazioni di Amazon Redshift ](https://docs.aws.amazon.com/redshift/latest/dg/c_challenges_achieving_high_performance_queries.html?ref=wellarchitected) 
+  [10 suggerimenti prestazionali su Amazon Athena ](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/?ref=wellarchitected) 
+  [Best practice di Amazon Redshift Spectrum ](https://aws.amazon.com/blogs/big-data/10-best-practices-for-amazon-redshift-spectrum/?ref=wellarchitected) 
+  [Best practice di Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BestPractices.html?ref=wellarchitected) 
+  [Choose between EC2 and Amazon RDS (Scegliere tra EC2 e Amazon RDS)](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/comparison.html) 
+  [Best practice per l'implementazione di Amazon ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/BestPractices.html) 

 **Video correlati:** 
+ [Database dedicati di AWS (DAT209-L) ](https://www.youtube.com/watch?v=q81TVuV5u28) 
+ [Sfatiamo i miti sullo storage Amazon Aurora: come funziona realmente (DAT309-R) ](https://www.youtube.com/watch?v=uaQEGLKtw54) 
+ [Amazon DynamoDB deep dive: Advanced design patterns (DAT403-R1) ](https://www.youtube.com/watch?v=6yqfmXiZTlM) 

 **Esempi correlati:** 
+  [Optimize Data Pattern Using Amazon Redshift Data Sharing (Ottimizzare lo schema dei dati con la condivisione dei dati di Amazon Redshift)](https://wellarchitectedlabs.com/sustainability/300_labs/300_optimize_data_pattern_using_redshift_data_sharing/) 
+  [Migrazioni dei database](https://github.com/aws-samples/aws-database-migration-samples) 
+  [MS SQL Server - AWS Database Migration Service (DMS) Replication Demo (Demo di replica di AWS Database Migration Service, DMS)](https://github.com/aws-samples/aws-dms-sql-server) 
+  [Database Modernization Hands On Workshop (Workshop pratico sulla modernizzazione dei database)](https://github.com/aws-samples/amazon-rds-purpose-built-workshop) 
+  [Esempi di Amazon Neptune](https://github.com/aws-samples/amazon-neptune-samples) 

# PERF04-BP02 Valutazione delle opzioni disponibili
<a name="perf_right_database_solution_evaluate_options"></a>

 Prima di selezionare una soluzione di gestione dei dati, è importante capire come può migliorare le prestazioni e quali sono le opzioni disponibili per il database. Utilizza il test di carico per identificare i parametri del database più importanti per il tuo carico di lavoro. Nella valutazione delle opzioni per il database, tieni in considerazione diversi aspetti, come i gruppi di parametri, le opzioni di archiviazione, la memoria, il calcolo, la replica di lettura, l'eventuale coerenza, il pooling di connessioni e le opzioni di caching. Esegui prove con le diverse opzioni di configurazione per migliorare i parametri. 

 **Risultato desiderato:** un carico di lavoro può avere una o più soluzioni di database in base al tipo di dati. Le funzionalità e i vantaggi del database corrispondono in maniera ottimale alle caratteristiche dei dati, agli schemi di accesso e ai requisiti del carico di lavoro. Per ottimizzare le prestazioni e i costi del database, devi valutare gli schemi di accesso ai dati per determinare le opzioni di database appropriate. Valuta i tempi di query accettabili per accertarti che le opzioni di database selezionate possano rispettare i requisiti. 

 **Anti-pattern comuni:** 
+  Non identificare gli schemi di accesso. 
+  Non conoscere le opzioni di configurazione della soluzione di gestione dei dati scelta. 
+  Basarsi soltanto sull'aumento delle dimensioni dell'istanza, senza tenere conto di altre opzioni di configurazione disponibili. 
+  Non testare le caratteristiche di scalabilità della soluzione scelta. 

 

 **Vantaggi dell'adozione di questa best practice:** Esplorare le opzioni di database e sperimentare con esse può consentire di ridurre il costo dell'infrastruttura, migliorare le prestazioni e la scalabilità e ridurre l'impegno richiesto per mantenere i carichi di lavoro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alto 
+  L'ottimizzazione per un database *universale* comporta inutili compromessi. 
+  Costi più elevati dovuti alla mancata corrispondenza fra la configurazione della soluzione di database e gli schemi di traffico. 
+  Possibili problemi operativi come conseguenza dei problemi di dimensionamento. 
+  Sicurezza dei dati non al livello richiesto. 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Comprendi le caratteristiche dei dati del carico di lavoro per configurare al meglio le opzioni del database. Esegui test di carico per identificare i parametri prestazionali chiave e i colli di bottiglia. Utilizza queste caratteristiche e questi parametri per valutare le opzioni di database e sperimentare con diverse configurazioni. 


|  Servizi AWS  |  Amazon RDS, Amazon Aurora  |  Amazon DynamoDB  |  Amazon DocumentDB  |  Amazon ElastiCache  |  Amazon Neptune  |  Amazon Timestream  |  Amazon Keyspaces  |  Amazon QLDB  | 
| --- | --- | --- | --- | --- | --- | --- | --- | --- | 
|  Dimensionamento del calcolo  |  Aumento della dimensione dell'istanza, le istanze Aurora Serverless si dimensionano automaticamente in risposta ai cambiamenti di carico  |  Dimensionamento automatico in lettura/scrittura con la modalità capacità on demand o dimensionamento automatico della capacità assegnata in lettura/scrittura nella modalità capacità assegnata  |  Aumento della dimensione dell'istanza  |  Aumento della dimensione dell'istanza, aggiunta di nodi al cluster  |  Aumento della dimensione dell'istanza  |  Dimensionamento automatico per regolare la capacità  |  Dimensionamento automatico in lettura/scrittura con la modalità capacità on demand o dimensionamento automatico della capacità assegnata in lettura/scrittura nella modalità capacità assegnata  |  Dimensionamento automatico per regolare la capacità  | 
|  Dimensionamento orizzontale delle letture  |  Tutti i motori supportano le repliche di lettura. Aurora supporta il dimensionamento automatico delle istanze con replica di lettura  |  Aumento delle unità di capacità in lettura assegnate  |  Repliche di lettura  |  Repliche di lettura  |  Repliche di lettura. Supporta il dimensionamento automatico delle istanze con replica di lettura  |  Dimensionamento automatico  |  Aumento delle unità di capacità in lettura assegnate  |  Aumento del dimensionamento in risposta a limiti di simultaneità documentati  | 
|  Dimensionamento orizzontale delle scritture  |  Aumento della dimensione dell'istanza, raggruppamento in batch delle scritture nell'applicazione o aggiunta di una coda davanti al database. Dimensionamento orizzontale tramite partizione a livello dell'applicazione fra più istanze  |  Aumento delle unità di capacità in scrittura assegnate. Garanzia di una chiave di partizione ottimale per evitare limitazioni in scrittura a livello di partizione  |  Aumento delle dimensioni dell'istanza principale  |  Utilizzo di Redis in modalità cluster per distribuire le scritture tra le partizioni  |  Aumento della dimensione dell'istanza  |  Le richieste di scrittura potrebbero subire limitazioni durante il dimensionamento. Se riscontri eccezioni di limitazione, continua a inviare dati ad almeno la stessa velocità di trasmissione effettiva per attivare il dimensionamento automatico. Scritture in batch per ridurre le richieste di scrittura simultanee  |  Aumento delle unità di capacità in scrittura assegnate. Garanzia di una chiave di partizione ottimale per evitare limitazioni in scrittura a livello di partizione  |  Aumento del dimensionamento in risposta a limiti di simultaneità documentati  | 
|  Configurazione del motore  |  Gruppi di parametri  |  Non applicabile  |  Gruppi di parametri  |  Gruppi di parametri  |  Gruppi di parametri  |  Non applicabile  |  Non applicabile  |  Non applicabile  | 
|  Caching  |  Caching in memoria, configurabile tramite gruppi di parametri. Associazione a una cache dedicata come ElastiCache per Redis a cui assegnare le richieste per gli elementi con accesso più frequente  |  Cache DAX completamente gestita disponibile  |  Caching in memoria. Facoltativo: associazione a una cache dedicata come ElastiCache per Redis a cui assegnare le richieste per gli elementi con accesso più frequente  |  La funzione principale è il caching  |  Utilizzo della cache dei risultati delle query per memorizzare in cache il risultato delle query di sola lettura  |  Timestream dispone di due livelli di archiviazione, uno dei quali è in memoria e ad alte prestazioni  |  Implementazione di una cache dedicata separata come ElastiCache per Redis a cui assegnare le richieste per gli elementi con accesso più frequente  |  Non applicabile  | 
|  Alta disponibilità/ripristino di emergenza  |  Per i carichi di lavoro, la configurazione consigliata prevede l'esecuzione di un'istanza in stand-by in una seconda zona di disponibilità, al fine di garantire la resilienza all'interno di una Regione.  Per la resilienza tra Regioni è possibile utilizzare Aurora Global Database  |  Disponibilità elevata all'interno di una Regione. Possibilità di replicare le tabelle tra Regioni grazie alle tabelle globali di DynamoDB  |  Creazione di più istanze in diverse zone di disponibilità per una maggiore disponibilità.  Possibilità di condividere snapshot tra Regioni e cluster grazie a DMS, per garantire funzionalità di replica tra Regioni/ripristino di emergenza  |  La configurazione consigliata per i cluster di produzione prevede la creazione di almeno un nodo in una zona di disponibilità secondaria.  Per la replica di cluster tra Regioni è possibile utilizzare ElastiCache Global Datastore.  |  Le repliche di lettura in altre zone di disponibilità servono come destinazioni di failover.  È possibile condividere snapshot tra Regioni e replicare cluster tramite i flussi Neptune, che consentono di replicare dati tra due cluster in due diverse Regioni.  |  Disponibilità elevata all'interno di una Regione. La replica tra Regioni richiede lo sviluppo di un'applicazione personalizzata tramite SDK Timestream  |  Disponibilità elevata all'interno di una Regione.  La replica tra Regioni richiede una logica applicativa personalizzata o strumenti di terze parti  |  Disponibilità elevata all'interno di una Regione.  Per la replica tra Regioni, esporta i contenuti del registro Amazon QLDB in un bucket S3 e configura tale bucket per la replica tra Regioni.  | 

 

 **Passaggi dell'implementazione** 

1.  Quali opzioni di configurazione sono disponibili per i database selezionati? 

   1.  I gruppi di parametri per Amazon RDS e Aurora consentono di regolare le impostazioni comuni del database a livello di motore, ad esempio la memoria allocata per la cache o la regolazione del fuso orario del database 

   1.  Per i servizi di database assegnati, come Amazon RDS, Aurora, Neptune, Amazon DocumentDB e quelli implementati su Amazon EC2, è possibile modificare il tipo di istanza e l'archiviazione assegnata, nonché aggiungere repliche di lettura. 

   1.  DynamoDB consente di specificare due modalità di capacità: on-demand e assegnata. Per rispondere ai diversi carichi di lavoro, puoi passare da una modalità all'altra e aumentare in qualsiasi momento la capacità allocata nella modalità assegnata. 

1.  Il carico di lavoro comporta operazioni intensive in lettura o scrittura?  

   1.  Quali sono le soluzioni disponibili per eliminare il carico delle letture (repliche di lettura, caching, ecc.)?  

      1.  Per le tabelle DynamoDB, è possibile eliminare il carico delle letture grazie a DAX per il caching. 

      1.  Per i database relazionali è possibile creare un cluster ElastiCache per Redis e configurare l'applicazione perché legga prima dalla cache, passando poi al database se l'elemento richiesto non è presente. 

      1.  I database relazionali come Amazon RDS e Aurora, nonché i database assegnati NoSQL come Neptune e Amazon DocumentDB, supportano tutti l'aggiunta di repliche di lettura per eliminare il carico creato dalle parti di lettura nel carico di lavoro. 

      1.  I database serverless come DynamoDB si dimensionano automaticamente. Assicurati di avere abbastanza unità di capacità di lettura (RCU) assegnate per gestire il carico di lavoro. 

   1.  Quali soluzioni sono disponibili per il dimensionamento delle operazioni in scrittura (sharding della chiave di partizione, introduzione di una coda, ecc.)? 

      1.  Per i database relazionali, è possibile aumentare la dimensione dell'istanza per gestire un maggiore carico di lavoro o aumentare la capacità di IOPS allocata per gestire una maggiore velocità di trasmissione effettiva verso l'archiviazione sottostante. 
         +  È anche possibile introdurre una coda davanti al database, invece di eseguire direttamente la scrittura su di esso. Questo schema consente di disaccoppiare l'acquisizione dal database e controllare il flusso, in modo che il database sia in grado di gestirlo.  
         +  Raggruppare in batch le richieste di scrittura, anziché creare molte transazioni di breve durata, può aiutare a migliorare la velocità di trasmissione effettiva in database relazionali con un elevato volume in scrittura. 

      1.  I database serverless come DynamoDB possono dimensionare automaticamente la velocità di trasmissione effettiva in scrittura oppure è possibile regolare le unità di capacità in scrittura (WCU) assegnate, a seconda della modalità di capacità.  
         +  È comunque possibile che si verifichino problemi con partizioni *ad accesso frequente* quando si raggiungono i limiti di velocità di trasmissione effettiva per una data chiave di partizione. Questo problema può essere arginato scegliendo una chiave di partizione con una distribuzione più uniforme o eseguendo lo sharding in lettura della chiave di partizione.  

1.  Qual è il picco di transazioni per secondo (TPS) attuale o previsto? Esegui un test con questo volume di traffico da solo e con l'aggiunta di un X% per comprendere le caratteristiche di dimensionamento. 

   1.  È possibile utilizzare strumenti nativi come pg\$1bench for PostgreSQL per mettere sotto stress il database e comprendere dove si creano colli di bottiglia e quali sono le caratteristiche di dimensionamento. 

   1.  È utile acquisire il traffico in contesti simili alla produzione perché possa essere riprodotto per simulare condizioni reali in aggiunta ai carichi di lavoro sintetici. 

1.  Se utilizzi capacità di calcolo serverless o a dimensionamento elastico, testa l'impatto del suo dimensionamento sul database. Se necessario, prevedi una gestione o un pooling delle connessioni per ridurre l'impatto sul database.  

   1.  È possibile utilizzare RDS Proxy con Amazon RDS e Aurora per gestire le connessioni al database.  

   1.  I database serverless come DynamoDB non hanno connessioni associate, ma valuta la capacità assegnata e le policy di dimensionamento automatico per affrontare i picchi nel carico. 

1.  Se il carico è prevedibile, sono presenti picchi e periodi di inattività? 

   1.  In presenza di periodi di inattività, valuta la possibilità di ridurre la capacità assegnata o la dimensione dell'istanza durante questi momenti. Aurora Serverless V2 aumenterà o ridurrà automaticamente le dimensioni in base al carico. 

   1.  Valuta la possibilità di mettere in pausa o interrompere le istanze non di produzione al di fuori degli orari lavorativi. 

1.  Devi segmentare e suddividere i tuoi modelli di dati in base agli schemi di accesso e alle caratteristiche dei dati? 

   1.  Valuta la possibilità di utilizzare AWS DMS o AWS SCT per spostare i dati su altri servizi. 

## Livello di impegno per il piano di implementazione: 
<a name="level-of-effort-for-the-implementation-plan-to-establish-this-best-practice-you-must-be-aware-of-your-current-data-characteristics-and-metrics.-gathering-those-metrics-establishing-a-baseline-and-then-using-those-metrics-to-identify-the-ideal-database-configuration-options-is-a-low-to-moderate-level-of-effort.-this-is-best-validated-by-load-tests-and-experimentation."></a>

Per attuare questa best practice è necessario conoscere caratteristiche e parametri attuali dei dati. Raccogliere tali parametri, definire una linea di base e quindi utilizzare i parametri per identificare le opzioni ideali per la configurazione del database richiede un livello di impegno da *basso* a *moderato* livello di impegno La convalida migliore passa attraverso test di carico e sperimentazioni. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Database su cloud AWS ](https://aws.amazon.com/products/databases/?ref=wellarchitected) 
+  [AWS Database Caching (Memorizzazione nella cache del database AWS) ](https://aws.amazon.com/caching/database-caching/?ref=wellarchitected) 
+  [Amazon DynamoDB Accelerator ](https://aws.amazon.com/dynamodb/dax/?ref=wellarchitected) 
+  [Best practice di Amazon Aurora ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.BestPractices.html?ref=wellarchitected) 
+  [Prestazioni di Amazon Redshift ](https://docs.aws.amazon.com/redshift/latest/dg/c_challenges_achieving_high_performance_queries.html?ref=wellarchitected) 
+  [10 suggerimenti prestazionali su Amazon Athena ](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/?ref=wellarchitected) 
+  [Best practice di Amazon Redshift Spectrum ](https://aws.amazon.com/blogs/big-data/10-best-practices-for-amazon-redshift-spectrum/?ref=wellarchitected) 
+  [Best practice di Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BestPractices.html?ref=wellarchitected) 

 

 **Video correlati:** 
+  [AWS purpose-built databases (Database dedicati di AWS) (DAT209-L) ](https://www.youtube.com/watch?v=q81TVuV5u28)
+ [Amazon Aurora storage demystified: How it all works (Sfatiamo i miti sullo storage Amazon Aurora: come funziona realmente)(DAT309-R) ](https://www.youtube.com/watch?v=uaQEGLKtw54) 
+  [Amazon DynamoDB deep dive: Advanced design patterns (DAT403-R1) ](https://www.youtube.com/watch?v=6yqfmXiZTlM)

 **Esempi correlati:** 
+  [Esempi di Amazon DynamoDB](https://github.com/aws-samples/aws-dynamodb-examples) 
+  [Esempi di migrazione di database con AWS](https://github.com/aws-samples/aws-database-migration-samples) 
+  [Database Modernization Workshop (Workshop sulla modernizzazione dei database)](https://github.com/aws-samples/amazon-rds-purpose-built-workshop) 
+  [Utilizzo dei parametri sul database di Amazon RDS per PostgreSQL](https://github.com/awsdocs/amazon-rds-user-guide/blob/main/doc_source/Appendix.PostgreSQL.CommonDBATasks.Parameters.md) 

# PERF04-BP03 Raccolta e registrazione dei parametri delle prestazioni del database
<a name="perf_right_database_solution_collect_metrics"></a>

 Per capire come si comportano i sistemi di gestione dei dati, è importante monitorare i parametri pertinenti. Questi parametri ti aiuteranno a ottimizzare le risorse di gestione dei dati, a garantire che i requisiti del carico di lavoro siano soddisfatti e ad avere una chiara panoramica sulle prestazioni del carico di lavoro. Utilizza strumenti, librerie e sistemi che registrano misure delle prestazioni relative alle prestazioni del database. 

 

 Esistono parametri relativi al sistema su cui è ospitato il database (ad esempio, CPU, spazio di archiviazione, memoria, IOPS) e parametri di accesso ai dati stessi (ad esempio, transazioni al secondo, velocità di esecuzione delle query, tempi di risposta, errori). Questi parametri devono essere facilmente accessibili a tutto il personale di supporto o operativo e devono avere un registro cronologico sufficiente per poter identificare tendenze, anomalie e colli di bottiglia. 

 

 **Risultato desiderato:** per monitorare le prestazioni dei carichi di lavoro del database, è necessario registrare più parametri delle prestazioni in un dato periodo di tempo. Ciò consente di rilevare le anomalie e di misurare le prestazioni rispetto ai parametri aziendali, per garantire che le esigenze del carico di lavoro siano soddisfatte. 

 **Anti-pattern comuni:** 
+  Utilizzi solo i file di log manuali per la ricerca dei parametri. 
+  Pubblichi i parametri solo sugli strumenti interni utilizzati dal tuo team e non hai un quadro completo del carico di lavoro. 
+  Utilizzi solo i parametri predefiniti registrati dal software di monitoraggio selezionato. 
+  Rivedi i parametri solo quando c'è un problema. 
+  Monitori solo i parametri a livello di sistema, senza catturare l'accesso ai dati o i parametri di utilizzo. 

 **Vantaggi dell'adozione di questa best practice:** la definizione di una linea di base delle prestazioni aiuta a comprendere il comportamento normale e i requisiti dei carichi di lavoro. I modelli anomali possono essere identificati ed eliminati più rapidamente, per migliorare le prestazioni e l'affidabilità del database. La capacità del database può essere configurata per garantire costi ottimali senza compromettere le prestazioni. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alta 
+  L'incapacità di distinguere il livello di prestazioni fuori dalla norma da quello nella norma crea difficoltà nell'identificazione dei problemi e nel processo decisionale. 
+  I potenziali risparmi sui costi possono non essere identificati. 
+  Non verranno identificati modelli di crescita che possono comportare un degrado dell'affidabilità o delle prestazioni. 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Identificare, raccogliere, aggregare e correlare i parametri relativi al database. I parametri devono includere sia il sistema sottostante che supporta il database sia i parametri del database. I parametri del sistema sottostante possono includere utilizzo della CPU, memoria, spazio di archiviazione su disco disponibile, I/O su disco e parametri di rete in entrata e in uscita, mentre i parametri del database possono includere transazioni al secondo, query principali, velocità media delle query, tempi di risposta, utilizzo degli indici, blocco delle tabelle, timeout delle query e numero di connessioni aperte. Questi dati sono cruciali per capire come si comporta il carico di lavoro e come viene utilizzata la soluzione di database. Utilizza tali parametri come parte di un approccio basato sui dati per mettere a punto e ottimizzare le risorse del tuo carico di lavoro.  

 **Passaggi dell'implementazione:** 

1.  Quali parametri del database è importante monitorare? 

   1.  [Monitoraggio di parametri in un'istanza Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html) 

   1.  [Monitoraggio con Performance Insights](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html) 

   1.  [Monitoraggio avanzato](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.overview.html) 

   1.  [Parametri di DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html) 

   1.  [Monitoraggio di DynamoDB DAX](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.Monitoring.html) 

   1.  [Monitoring MemoryDB (Monitoraggio di MemoryDB)](https://docs.aws.amazon.com/memorydb/latest/devguide/monitoring-cloudwatch.html) 

   1.  [Monitoraggio di Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/metrics.html) 

   1.  [Timeseries metrics and dimensions (Parametri e dimensioni delle serie temporali)](https://docs.aws.amazon.com/timestream/latest/developerguide/metrics-dimensions.html) 

   1.  [Parametri a livello di cluster per Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMySQL.Monitoring.Metrics.html) 

   1.  [Monitoring Amazon Keyspaces (Monitoraggio di Amazon Keyspaces)](https://docs.aws.amazon.com/keyspaces/latest/devguide/monitoring.html) 

   1.  [Monitoring Amazon Neptune (Monitoraggio di Amazon Neptune)](https://docs.aws.amazon.com/neptune/latest/userguide/monitoring.html) 

1.  Il monitoraggio del database può trarre vantaggio da una soluzione di machine learning che rileva anomalie operative e problemi di prestazioni? 

   1.  [Amazon DevOps Guru per Amazon RDS](https://docs.aws.amazon.com/devops-guru/latest/userguide/working-with-rds.overview.how-it-works.html) offre visibilità sui problemi di prestazioni e fornisce suggerimenti per le azioni correttive. 

1.  Hai bisogno di dettagli a livello di applicazione sull'utilizzo di SQL? 

   1.  [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-api-segmentdocuments.html#api-segmentdocuments-sql) può essere inserito nell'applicazione per ottenere approfondimenti e incapsulare tutti i punti di dati per una singola query. 

1.  Disponi attualmente di una soluzione di registrazione e monitoraggio approvata? 

   1.  [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) può raccogliere i parametri per tutte le risorse dell'architettura. Puoi anche raccogliere e pubblicare parametri personalizzati per ottenere parametri aziendali o derivati. Utilizza CloudWatch o soluzioni di terze parti per impostare allarmi che indicano il superamento delle soglie. 

1.  Hai identificato e configurato le policy di conservazione dei dati in modo che corrispondano ai miei obiettivi operativi e di sicurezza? 

   1.  [Conservazione dei dati predefinita per i parametri CloudWatch](https://aws.amazon.com/cloudwatch/faqs/#AWS_resource_.26_custom_metrics_monitoring) 

   1.  [Conservazione dei dati predefinita per CloudWatch Logs](https://aws.amazon.com/cloudwatch/faqs/#Log_management) 

 **Livello di impegno per il piano di implementazione: **esiste un livello *medio* di impegno per identificare, monitorare, raccogliere, aggregare e correlare i parametri di tutte le risorse del database. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [AWS Database Caching (Memorizzazione nella cache del database AWS) ](https://aws.amazon.com/caching/database-caching/) 
+ [ 10 suggerimenti prestazionali su Amazon Athena ](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/)
+ [ Best practice con Amazon Aurora ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.BestPractices.html)
+  [Amazon DynamoDB Accelerator ](https://aws.amazon.com/dynamodb/dax/)
+ [Best practice di Amazon DynamoDB ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BestPractices.html) 
+ [Best practice di Amazon Redshift Spectrum (Best practice per Amazon Redshift Spectrum) ](https://aws.amazon.com/blogs/big-data/10-best-practices-for-amazon-redshift-spectrum/) 
+ [Prestazioni di Amazon Redshift ](https://docs.aws.amazon.com/redshift/latest/dg/c_challenges_achieving_high_performance_queries.html) 
+ [Database su cloud AWS](https://aws.amazon.com/products/databases/) 
+  [Amazon RDS Performance Insights](https://aws.amazon.com/rds/performance-insights/) 

 **Video correlati:** 
+ [AWS purpose-built databases (Database dedicati di AWS) (DAT209-L) ](https://www.youtube.com/watch?v=q81TVuV5u28) 
+  [Amazon Aurora storage demystified: How it all works (Sfatiamo i miti sullo storage Amazon Aurora: come funziona realmente)(DAT309-R) ](https://www.youtube.com/watch?v=uaQEGLKtw54)
+  [Amazon DynamoDB deep dive: Advanced design patterns (DAT403-R1) ](https://www.youtube.com/watch?v=6yqfmXiZTlM)

 **Esempi correlati:** 
+  [Level 100: Monitoring with CloudWatch Dashboards (Livello 100: Monitoraggio con i pannelli di controllo CloudWatch)](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_with_cloudwatch_dashboards/) 
+  [AWS Dataset Ingestion Metrics Collection Framework (Framework di raccolta dei parametri di ingestione del set di dati AWS)](https://github.com/awslabs/aws-dataset-ingestion-metrics-collection-framework) 
+  [Workshop di monitoraggio Amazon RDS](https://www.workshops.aws/?tag=Enhanced%20Monitoring) 

# PERF04-BP04 Scelta dello spazio di archiviazione dei dati in base ai modelli di accesso
<a name="perf_right_database_solution_access_patterns"></a>

 Utilizza gli schemi di accesso del carico di lavoro per decidere quali servizi e tecnologie utilizzare. Oltre ai requisiti non funzionali, come le prestazioni e il dimensionamento, i modelli di accesso influenzano pesantemente la scelta del database e delle soluzioni di archiviazione. La prima dimensione è data da necessità di transazioni, conformità ACID e letture coerenti. Non tutti i database supportano queste caratteristiche e la maggior parte dei database NoSQL fornisce un modello di consistenza eventuale. La seconda dimensione importante è la distribuzione delle scritture e delle letture nel tempo e nello spazio. Le applicazioni distribuite a livello globale devono considerare i modelli di traffico, la latenza e i requisiti di accesso per identificare la soluzione di archiviazione ottimale. Il terzo aspetto cruciale da scegliere è la flessibilità dei modelli di query, i modelli di accesso casuale e le query una tantum. Occorre inoltre tenere conto delle funzionalità di query altamente specializzate per l'elaborazione del testo e del linguaggio naturale, delle serie temporali e dei grafici. 

 **Risultato desiderato:** l'archiviazione di dati è stata selezionata in base a modelli di accesso ai dati identificati e documentati. Ciò potrebbe includere le query di lettura, scrittura e cancellazione più comuni, la necessità di calcoli e aggregazioni ad hoc, la complessità dei dati, l'interdipendenza dei dati e le esigenze di coerenza richieste. 

 **Anti-pattern comuni:** 
+  È sufficiente selezionare un solo fornitore di database per semplificare la gestione delle operazioni. 
+  Ritieni che gli schemi di accesso ai dati rimarranno coerenti nel tempo. 
+  Implementi transazioni complesse, rollback e logica di coerenza nell'applicazione. 
+  Il database è configurato per supportare un potenziale burst di traffico elevato, che fa sì che le risorse del database rimangano inattive per la maggior parte del tempo. 
+  Utilizzo di un database condiviso per usi transazionali e analitici. 

 **Vantaggi dell'adozione di questa best practice:** la selezione e l'ottimizzazione dell'archiviazione dei dati in base ai modelli di accesso contribuirà a ridurre la complessità dello sviluppo e a ottimizzare le opportunità di prestazione. Capire quando utilizzare le repliche di lettura, le tabelle globali, il partizionamento dei dati e la memorizzazione nella cache, ti aiuterà a ridurre i costi operativi e a effettuare il dimensionamento in base alle esigenze del carico di lavoro. 

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

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Identifica e valuta il modello di accesso ai dati per selezionare la configurazione di archiviazione corretta. Ogni soluzione di database dispone di opzioni per configurare e ottimizzare la soluzione di archiviazione. Utilizza i parametri e i registri raccolti e sperimenta le opzioni per trovare la configurazione ottimale. Utilizza la tabella seguente per esaminare le opzioni di archiviazione per ogni servizio di database. 


|  Servizi AWS  |  Amazon RDS, Amazon Aurora  |  Amazon DynamoDB  |  Amazon DocumentDB  |  Amazon ElastiCache  |  Amazon Neptune  |  Amazon Timestream  |  Amazon Keyspaces  |  Amazon QLDB  | 
| --- | --- | --- | --- | --- | --- | --- | --- | --- | 
|  Dimensionamento dello spazio di archiviazione  |  L'opzione di dimensionamento automatico dello spazio di archiviazione è disponibile per dimensionare automaticamente lo spazio di archiviazione allocato. La capacità di IOPS allocata può essere dimensionata anche indipendentemente dallo spazio di archiviazione allocato quando si sfruttano i tipi di spazio di archiviazione IOPS allocati.  |  Dimensionamento automatico. Le tabelle non hanno vincoli di dimensione.  |  Opzione di dimensionamento automatico dello spazio di archiviazione disponibile per dimensionare lo spazio di archiviazione allocato  |  Spazio di archiviazione in memoria, legato al tipo o al numero di istanze  |  Opzione di dimensionamento automatico dello spazio di archiviazione disponibile per dimensionare automaticamente lo spazio di archiviazione allocato  |  Configura il periodo di conservazione per i livelli in memoria e magnetici nei giorni  |  Aumenta e diminuisce automaticamente lo spazio di archiviazione della tabella  |  Dimensionamento automatico. Le tabelle non hanno vincoli di dimensione.  | 

 

 **Passaggi dell'implementazione:** 

1.  Identifica e documenta la crescita prevista dei dati e del traffico. 

   1.  Amazon RDS e Aurora supportano l'aumento automatico dello spazio di archiviazione fino ai limiti documentati. Oltre a questo, si può prendere in considerazione la transizione dei dati più vecchi verso Amazon S3 per l'archiviazione, l'aggregazione dei dati storici per l'analisi o la scalabilità orizzontale tramite partizioni. 

   1.  DynamoDB e Amazon S3 dimensioneranno automaticamente fino a raggiungere un volume di archiviazione quasi illimitato. 

   1.  I database e le istanze Amazon RDS in esecuzione su EC2 possono essere ridimensionati manualmente e le istanze EC2 possono avere nuovi volumi EBS aggiunti in un secondo momento per ottenere ulteriore spazio di archiviazione.  

   1.  I tipi di istanza possono essere modificati in base alle variazioni dell'attività. Ad esempio, puoi iniziare con un'istanza più piccola durante i test, per poi dimensionare l'istanza quando inizi a ricevere traffico di produzione verso il servizio. Aurora Serverless V2 si riduce orizzontalmente in modo automatico in risposta alle modifiche nel carico.  

1.  Documenta i requisiti relativi alle prestazioni normali e di picco (transazioni al secondo TPS e query al secondo QPS) e alla consistenza (ACID e consistenza eventuale). 

1.  Documenta gli aspetti di implementazione della soluzione e i requisiti di accesso al database (globale, Mult-AZ, replica in lettura, nodi di scrittura multipli) 

 **Livello di impegno per il piano di implementazione: **se non disponi di registri o parametri per la tua soluzione di gestione dei dati, devi completarli prima di identificare e documentare i modelli di accesso ai dati. Una volta compreso il modello di accesso ai dati, la selezione e la configurazione dello spazio di archiviazione dei dati è un *basso* livello di impegno 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [AWS Database Caching (Memorizzazione nella cache del database AWS) ](https://aws.amazon.com/caching/database-caching/)
+ [10 suggerimenti prestazionali su Amazon Athena ](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/) 
+ [Best practice di Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.BestPractices.html) 
+ [Amazon DynamoDB Accelerator ](https://aws.amazon.com/dynamodb/dax/) 
+ [Best practice di Amazon DynamoDB ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BestPractices.html) 
+ [Best practice di Amazon Redshift Spectrum ](https://aws.amazon.com/blogs/big-data/10-best-practices-for-amazon-redshift-spectrum/) 
+ [Prestazioni di Amazon Redshift ](https://docs.aws.amazon.com/redshift/latest/dg/c_challenges_achieving_high_performance_queries.html) 
+  [Database su cloud AWS](https://aws.amazon.com/products/databases/)
+  [Tipi di archiviazione Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html) 

 **Video correlati:** 
+ [AWS purpose-built databases (Database dedicati di AWS) (DAT209-L)](https://www.youtube.com/watch?v=q81TVuV5u28) 
+  [Amazon Aurora storage demystified: How it all works (Sfatiamo i miti sullo storage Amazon Aurora: come funziona realmente)(DAT309-R) ](https://www.youtube.com/watch?v=uaQEGLKtw54)
+ [ Amazon DynamoDB deep dive: Advanced design patterns (DAT403-R1) ](https://www.youtube.com/watch?v=6yqfmXiZTlM)

 **Esempi correlati:** 
+  [Experiment and test with Distributed Load Testing on AWS (Esperimenti e prove con i test di carico distribuiti su AWS)](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) 

# PERF04-BP05 Ottimizzazione dello spazio di archiviazione dei dati in base ai modelli e ai parametri di accesso
<a name="perf_right_database_solution_optimize_metrics"></a>

 Utilizza caratteristiche delle prestazioni e schemi di accesso che ottimizzano il modo in cui i dati vengono archiviati o interrogati al fine di ottenere le migliori prestazioni possibili. Misura il modo in cui le ottimizzazioni come l'indicizzazione, la distribuzione delle chiavi, la progettazione dei data warehouse o le strategie di memorizzazione nella cache influenzano le prestazioni del sistema o la sua efficienza nel complesso. 

 **Anti-pattern comuni:** 
+  Utilizzi solo i file di log manuali per la ricerca dei parametri. 
+  Pubblichi i parametri solo negli strumenti interni. 

 **Vantaggi dell'adozione di questa best practice:** Per assicurarti di soddisfare i parametri necessari per il carico di lavoro, devi monitorare i parametri delle prestazioni del database correlati alla lettura e alla scrittura. Puoi utilizzare questi dati per aggiungere nuove ottimizzazioni per le operazioni di lettura e scrittura al livello di storage dei dati. 

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

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Ottimizzazione dello spazio di archiviazione di dati in base a parametri e modelli: i parametri segnalati per identificare le aree con prestazioni inferiori nel carico di lavoro e ottimizzare i componenti del database. Ogni sistema del database ha caratteristiche diverse relative alle prestazioni che devono essere valutate, come il modo in cui i dati sono indicizzati, memorizzati nella cache o distribuiti in più sistemi. Misurazione dell'impatto delle ottimizzazioni. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Database Caching (Memorizzazione nella cache del database AWS)](https://aws.amazon.com/caching/database-caching/) 
+  [10 suggerimenti prestazionali su Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/) 
+  [Best practice con Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.BestPractices.html) 
+  [Amazon DynamoDB Accelerator](https://aws.amazon.com/dynamodb/dax/) 
+  [Best practice di Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BestPractices.html) 
+  [Best practice di Amazon Redshift Spectrum (Best practice per Amazon Redshift Spectrum)](https://aws.amazon.com/blogs/big-data/10-best-practices-for-amazon-redshift-spectrum/) 
+  [Prestazioni di Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/c_challenges_achieving_high_performance_queries.html) 
+  [Database su cloud AWS](https://aws.amazon.com/products/databases/) 
+  [Analisi delle anomalie delle prestazioni con DevOps Guru per RDS](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/devops-guru-for-rds.html) 
+  [Modalità di capacità in lettura/scrittura per DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html) 

 **Video correlati:** 
+  [AWS purpose-built databases (Database dedicati di AWS) (DAT209-L)](https://www.youtube.com/watch?v=q81TVuV5u28) 
+  [Amazon Aurora storage demystified: How it all works (Sfatiamo i miti sullo storage Amazon Aurora: come funziona realmente)(DAT309-R)](https://www.youtube.com/watch?v=uaQEGLKtw54) 
+  [Amazon DynamoDB deep dive: Advanced design patterns (DAT403-R1)](https://www.youtube.com/watch?v=6yqfmXiZTlM) 

 **Esempi correlati:** 
+  [Laboratori pratici per Amazon DynamoDB](https://amazon-dynamodb-labs.workshop.aws/hands-on-labs.html)