Caratteristiche del carico di lavoro

Storicamente, le piattaforme di elaborazione di database specializzate erano progettate per un particolare carico di lavoro, come l'elaborazione delle transazioni online (OLTP) o l'elaborazione analitica online (OLAP), e questi modelli di progettazione specifici le rendevano una scelta inadeguata per altri carichi di lavoro. Ad esempio, i database Oracle che ospitano sistemi di supporto decisionale utilizzano in genere blocchi di dimensioni maggiori per supportare la lettura di più dati dalla cache con un minor numero di operazioni di I/O. D'altra parte, i carichi di lavoro OLTP traggono vantaggio da una dimensione dei blocchi più piccola per favorire l'accesso casuale a righe di piccole dimensioni e ridurre il conflitto tra blocchi. Exadata è efficace nell'esecuzione di qualsiasi tipo di carico di lavoro del database Oracle o qualsiasi combinazione di carichi di lavoro grazie a funzionalità come la memoria persistente (PMEM) e Exadata Smart Flash Cache per aumentare le prestazioni delle transazioni OLTP e Hybrid Columnar Compression (HCC) e Smart Scan per favorire le query analitiche. Tuttavia, la migrazione di un carico di lavoro Exadata offre una buona opportunità per prendere in considerazione l'utilizzo di un motore di database appositamente progettato per il carico di lavoro anziché utilizzare il tipo o l'istanza di database esistente. AWS i database creati appositamente semplificano la selezione di un tipo specifico di servizio per un carico di lavoro specifico su un modello basato sul consumo anziché cercare di forzare più carichi di lavoro sulla stessa piattaforma. Come discusso in precedenza, AWS offre oltre 15 motori appositamente progettati per supportare diversi modelli di dati, tra cui database relazionali, chiave-valore, documentali, in memoria, grafici, di serie temporali, a colonna larga e di registro.

Tradizionalmente, i database ottimizzati per i sistemi di supporto decisionale seguono modelli di progettazione e caratteristiche del carico di lavoro specifici, come i seguenti:

• Blocchi di database di dimensioni maggiori (16K o 32K)

• Schemi a stella con tabelle dei fatti e delle dimensioni e parametri impostati star_transformation_enabled su TRUE

• Funzionalità di compressione come HCC, Advanced Compression o Basic Compression

• Funzionalità OLAP

• Presenza di viste materializzate nel database con impostazione query_rewrite_enabled TRUE

• Elaborazione parallela massiva

• Elevato ingombro I/O

D'altra parte, i database ottimizzati per OLTP hanno blocchi di database di dimensioni inferiori (8K o inferiori), letture a blocco singolo, forte concorrenza, elevato rapporto di successo della cache nel buffer ed esecuzione seriale delle transazioni. In Exadata, è tipico vedere anti-pattern in cui un database progettato per un carico di lavoro OLTP viene ampiamente utilizzato per le query analitiche o viceversa. È altamente improbabile che un database Oracle venga utilizzato per carichi di lavoro OLTP puri, poiché è pratica comune eseguire query di reporting sul database transazionale per comodità.

Diverse statistiche di sistema disponibili nelle viste dinamiche delle prestazioni di Oracle, nel report Automatic Workload Repository (AWR) e nel report Statspack possono rivelare quanto sia simile il carico di lavoro di un database a un sistema OLTP o OLAP. La statistica Physical read total multi block requests indica il numero totale di richieste di lettura che sono state lette in due o più blocchi di database per richiesta. La differenza tra Physical read total IO requests e Physical read total multi block requests indica il numero totale di richieste di lettura a blocco singolo emesse dal database. Un numero elevato di richieste multiblocco indica in genere un sistema OLAP, mentre un numero elevato di richieste di lettura a blocco singolo indica un sistema OLTP. Inoltre, le seguenti statistiche nel rapporto AWR possono anche rivelare se un carico di lavoro in esecuzione su un database Oracle è principalmente un carico di lavoro OLTP o OLAP:

• user commits— Riflette il numero di commit emessi al limite di una transazione. In genere, i sistemi OLTP hanno un numero elevato di transazioni di piccole dimensioni, che comportano un numero elevato di impegni da parte degli utenti. D'altra parte, i sistemi OLAP eseguono un numero inferiore di transazioni pesanti.

• Buffer hit— Indica la frequenza con cui un blocco richiesto viene trovato nella buffer cache senza richiedere l'accesso al disco. I sistemi OLTP hanno in genere un buffer hit ratio superiore al 99 percento, mentre il buffer hit ratio per i sistemi OLAP è in genere basso.

La tabella seguente riassume le differenze comuni nelle caratteristiche del carico di lavoro tra i sistemi OLTP e OLAP.

Caratteristica	OLTP	OLAP
Dimensione del blocco	<= 8K	> 8 K
Tasso di impegno	Elevata	Bassa
Rapporto di successo della cache del buffer	> 99%	< 99%
Eventi di attesa I/O importanti	Lettura sequenziale di file DB, sincronizzazione dei file di registro	Lettura sparsa del file DB, lettura diretta del percorso
Dimensione media delle richieste di I/O (throughput I/O/ IOPS)	< 120 K	400K
Schema a stella	Does not exist	Potrebbe esistere
star_transformation_enabledparametro	FALSE	TRUE
parallelismo	Basso grado o disabilitato	Abilitato con grado elevato

Se il tuo database supporta principalmente un carico di lavoro OLAP, una soluzione di data warehouse appositamente progettata come Amazon Redshift potrebbe essere la soluzione migliore per la migrazione del carico di lavoro verso. AWSPuoi quindi creare una soluzione analitica AWS utilizzando servizi come Amazon S3, AmazonAthena e Amazon. QuickSight Per i carichi di lavoro OLTP, Amazon RDS offre una scelta di sei motori relazionali, incluso Amazon RDS for Oracle, se dipendi da un database Oracle. In caso contrario, puoi scegliere un motore open source come Amazon RDS for PostgreSQL o Aurora PostgreSQL compatibile. Amazon DynamoDB può anche ospitare sistemi transazionali altamente scalabili che non richiedono un modello relazionale e potrebbero essere serviti da un archivio chiave-valore.

Rapporto di lettura/scrittura

Un altro fattore importante è il rapporto di lettura/scrittura del carico di lavoro ospitato sul database di cui si desidera migrare. La maggior parte dei sistemi OLTP viene utilizzata anche per scopi di reporting e su database transazionali critici vengono eseguite query ad hoc che richiedono molte risorse. Ciò causa spesso problemi di prestazioni nei componenti critici delle applicazioni. Le query di reporting meno critiche e che richiedono molte risorse possono essere reindirizzate a una copia dell'istanza di produzione per evitare qualsiasi impatto sulle prestazioni dell'applicazione di produzione critica. La physical writes statistica AWR riflette il numero totale di blocchi di dati scritti su disco e specifica il numero totale di blocchi di dati physical reads letti dal disco. Utilizzando queste statistiche, è possibile determinare la percentuale di lettura del carico di lavoro nel modo seguente:

Read percentage = physical reads/(physical reads + physical writes)*100

A seconda del modo in cui una transazione emette le operazioni di lettura sul database, puoi implementare una soluzione di replica di lettura o una soluzione di caching esterna al database, ad esempio Amazon, nell'architettura di destinazione. ElastiCache Questo aiuta a ridurre le risorse necessarie all'istanza del database principale per servire il carico di lavoro di lettura. Amazon Aurora, che è un motore di database relazionale nativo per il cloud che fa parte della famiglia Amazon RDS, offre un'opzione di scalabilità automatica che supporta un carico di lavoro di sola lettura altamente scalabile con un massimo di 15 istanze di lettura. Puoi anche utilizzare i database globali Aurora per estendere più regioni AWS con operazioni di lettura locale veloci e bassa latenza in ogni regione.

Carichi di lavoro non relazionali

La versione 12.c di Oracle Database supporta l'archiviazione di dati JSON in modo nativo con funzionalità di database relazionali. In 21c, Oracle Database ha introdotto il tipo di dati JSON. Inoltre, la funzionalità Simple Oracle Document Access (SODA) consente di creare, archiviare e recuperare raccolte di documenti utilizzando le API NoSQL. Puoi anche utilizzare Oracle Graph Server per carichi di lavoro grafici. Tuttavia, puoi eseguire questi carichi di lavoro non relazionali in modo più efficiente utilizzando database AWS appositamente creati come Amazon DynamoDB, Amazon DocumentDB o Amazon Neptune. Questi servizi sono ottimizzati specificamente per modelli di accesso NoSQL e casi d'uso specializzati.