Características da carga de trabalho

Historicamente, plataformas especializadas de computação de banco de dados foram projetadas para uma carga de trabalho específica, como processamento de transações on-line (OLTP) ou processamento analítico on-line (OLAP), e esses padrões de design específicos a tornaram uma escolha ruim para outras cargas de trabalho. Por exemplo, bancos de dados Oracle que hospedam sistemas de suporte à decisão normalmente usam um tamanho de bloco maior para suportar a leitura de mais dados do cache com menos operações de E/S. Por outro lado, as OLTP cargas de trabalho se beneficiam de um tamanho de bloco menor para favorecer o acesso aleatório a linhas pequenas e reduzir a contenção de blocos. O Exadata é eficaz na execução de qualquer tipo de carga de trabalho de banco de dados Oracle ou qualquer combinação de cargas de trabalho devido a recursos como memória persistente (PMEM) e Exadata Smart Flash Cache para aumentar o desempenho das OLTP transações, e Hybrid Columnar Compression (HCC) e Smart Scan para favorecer consultas analíticas. No entanto, migrar uma carga de trabalho do Exadata oferece uma boa oportunidade de considerar o uso de um mecanismo de banco de dados específico para a carga de trabalho, em vez de usar seu tipo ou instância de banco de dados existente. AWS bancos de dados criados especificamente facilitam a seleção de um tipo específico de serviço para uma carga de trabalho específica em um modelo baseado em consumo, em vez de tentar forçar várias cargas de trabalho na mesma plataforma. Conforme discutido anteriormente, AWS oferece mais de 15 mecanismos específicos para oferecer suporte a diversos modelos de dados, incluindo bancos de dados relacionais, de valores-chave, documentos, em memória, gráficos, séries temporais e de colunas largas.

Tradicionalmente, os bancos de dados otimizados para sistemas de apoio à decisão seguem padrões de design e características de carga de trabalho específicos, como os seguintes:

• Tamanho maior do bloco de banco de dados (16K ou 32K)

• Esquemas em estrela com tabelas de fatos e dimensões e o star_transformation_enabled parâmetro definido como TRUE

• Recursos de compactaçãoHCC, como compactação avançada ou compactação básica

• Recurso do OLAP

• Presença de visualizações materializadas no banco de dados com query_rewrite_enabled definido como TRUE

• Processamento paralelo massivo

• Área de I/O pesada

Por outro lado, os bancos de dados otimizados OLTP têm tamanhos menores de blocos de banco de dados (8K ou menores), leituras de bloco único, alta simultaneidade, alta taxa de acertos do cache de buffer e execução serial de transações. No Exadata, é comum ver antipadrões em que um banco de dados projetado para uma OLTP carga de trabalho é muito usado para consultas analíticas ou vice-versa. É altamente improvável que um banco de dados Oracle seja usado para OLTP cargas de trabalho puras, porque é uma prática comum executar consultas de relatórios no banco de dados transacional por conveniência.

Várias estatísticas do sistema disponíveis nas visualizações de desempenho dinâmico da Oracle, no relatório Automatic Workload Repository (AWR) e no relatório Statspack podem revelar a semelhança de uma carga de trabalho de banco de dados com um sistema o. OLTP OLAP A estatística Physical read total multi block requests indica o número total de solicitações de leitura que foram lidas em dois ou mais blocos de banco de dados por solicitação. A diferença entre Physical read total IO requests e Physical read total multi block requests indica o número total de solicitações de leitura de bloco único que foram emitidas pelo banco de dados. Um número alto de solicitações de vários blocos normalmente indica um OLAP sistema, e um grande número de solicitações de leitura de bloco único indica um OLTP sistema. Além disso, as estatísticas a seguir no AWR relatório também podem revelar se uma carga de trabalho executada em um banco de dados Oracle é basicamente uma carga de OLAP trabalho OLTP ou:

• user commits— Reflete o número de confirmações emitidas no limite de uma transação. Normalmente, OLTP os sistemas têm um grande número de pequenas transações, o que resulta em um grande número de confirmações de usuários. Por outro lado, os OLAP sistemas executam um número menor de transações pesadas.

• Buffer hit— Indica a frequência com que um bloco solicitado é encontrado no cache do buffer sem exigir acesso ao disco. OLTPos sistemas normalmente têm uma taxa de acertos de buffer acima de 99 por cento, enquanto a taxa de acertos de buffer para OLAP sistemas geralmente é baixa.

A tabela a seguir resume as diferenças comuns nas características da carga de trabalho entre OLTP os OLAP sistemas.

Característica	OLTP	OLAP
Tamanho do bloco	<= 8K	> 8K
Taxa de comprometimento	Alto	Baixo
Taxa de acertos do cache do buffer	> 99%	< 99%
Eventos de espera de I/O proeminentes	Leitura sequencial do arquivo DB, sincronização do arquivo de log	Leitura dispersa do arquivo DB, leitura direta do caminho
Tamanho médio da solicitação de E/S (taxa de transferência de E/S/) IOPS	< 120K	> 400 MIL
Esquema de estrelas	Não existe	Pode existir
star_transformation_enabledParâmetro do .	FALSE	TRUE
Paralelismo	Baixo grau ou deficiente	Habilitado com alto grau

Se seu banco de dados suportar principalmente uma OLAP carga de trabalho, uma solução de armazenamento de dados criada especificamente, como o Amazon Redshift, pode ser mais adequada quando você migra sua carga de trabalho para o. AWSEm seguida, você pode criar uma solução analítica AWS usando serviços como Amazon S3, Amazon Athena e Amazon. QuickSight Para OLTP cargas de trabalho, a Amazon RDS oferece uma opção de seis mecanismos relacionais, incluindo o Amazon RDS for Oracle, caso você dependa de um banco de dados Oracle. Caso contrário, você pode escolher um mecanismo de código aberto, como Amazon RDS for Postgre SQL ou Aurora SQL Postgre -Compatível. O Amazon DynamoDB também pode hospedar sistemas transacionais altamente escaláveis que não exigem um modelo relacional e podem ser atendidos por um repositório de valores-chave.

Relação de leitura/gravação

Outro fator importante é a taxa de leitura/gravação da carga de trabalho hospedada no banco de dados que você deseja migrar. A maioria dos OLTP sistemas também é usada para fins de geração de relatórios, e consultas ad hoc que consomem muitos recursos são executadas em bancos de dados transacionais essenciais. Isso geralmente causa problemas de desempenho em componentes críticos do aplicativo. Essas consultas de relatórios menos críticas e que consomem muitos recursos podem ser redirecionadas para uma cópia da instância de produção para evitar qualquer impacto no desempenho do aplicativo crítico de produção. A AWR physical writes estatística reflete o número total de blocos de dados gravados no disco e especifica o physical reads número total de blocos de dados lidos do disco. Usando essas estatísticas, você pode determinar a porcentagem de leitura da carga de trabalho da seguinte forma:

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

Dependendo de como uma transação emite operações de leitura no banco de dados, você pode implantar uma solução de réplica de leitura ou uma solução de armazenamento em cache externa ao banco de dados — por exemplo, ElastiCacheAmazon — na arquitetura de destino. Isso ajuda a reduzir os recursos que a instância primária do banco de dados exige para atender à carga de trabalho de leitura. O Amazon Aurora, que é um mecanismo de banco de dados relacional nativo da nuvem que faz parte da RDS família Amazon, fornece uma opção de escalabilidade automática que suporta uma carga de trabalho altamente escalável e somente para leitura com até 15 instâncias de leitura. Você também pode usar os bancos de dados globais do Aurora para abranger várias AWS regiões com operações de leitura local rápidas e baixa latência em cada região.

Cargas de trabalho não relacionais

O Oracle Database versão 12.c suporta o armazenamento nativo de JSON dados com recursos de banco de dados relacional. Em 21c, o Oracle Database introduziu o tipo JSON de dados. Além disso, o recurso Simple Oracle Document Access (SODA) permite criar, armazenar e recuperar coleções de documentos usando Não SQLAPIs. Você também pode usar o Oracle Graph Server para cargas de trabalho gráficas. No entanto, você pode executar essas cargas de trabalho não relacionais com mais eficiência ao usar bancos de dados AWS específicos, como Amazon DynamoDB, Amazon DocumentDB ou Amazon Neptune. Esses serviços são especificamente otimizados para padrões de ausência de SQL acesso e casos de uso especializados.