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 cargas de trabalho OLTP 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 transações OLTP, além de compressão colunar híbrida (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, colunas largas e bancos de dados contábeis.

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 compressão, como HCC, compressão avançada ou compressão básica

• Recurso 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 para OLTP têm tamanhos menores de blocos de banco de dados (8K ou menores), leituras de bloco único, alta simultaneidade, alta taxa de acerto 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 carga de trabalho OLTP é muito usado para consultas analíticas ou vice-versa. É altamente improvável que um banco de dados Oracle seja usado para cargas de trabalho OLTP 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 OLTP ou 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 sistema OLAP, e um número alto de solicitações de leitura de bloco único indica um sistema OLTP. Além disso, as estatísticas a seguir no relatório AWR também podem revelar se uma carga de trabalho que está sendo executada em um banco de dados Oracle é principalmente uma carga de trabalho OLTP ou OLAP:

• user commits— Reflete o número de confirmações emitidas no limite de uma transação. Normalmente, os sistemas OLTP 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 sistemas OLAP 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. Os sistemas OLTP normalmente têm uma taxa de acertos de buffer acima de 99%, enquanto a taxa de acertos de buffer para sistemas OLAP geralmente é baixa.

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

Característica	OLTP	OLAP
Tamanho do bloco	<= 8K	> 8K
Taxa de comprometimento	Alta	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	FALSE	VERDADEIRO
Paralelismo	Baixo grau ou deficiente	Habilitado com alto grau

Se seu banco de dados suporta principalmente uma carga de trabalho OLAP, uma solução de armazém 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 cargas de trabalho OLTP, o Amazon RDS vem com 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 PostgreSQL ou Aurora compatível com PostgreSQL. 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 sistemas OLTP 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 physical writes estatística AWR reflete o número total de blocos de dados gravados no disco, e a physical reads estatística especifica o 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 família Amazon RDS, 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 regiões da AWS 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 dados JSON com recursos de banco de dados relacional. Em 21c, o Oracle Database introduziu o tipo de dados JSON. Além disso, o recurso Simple Oracle Document Access (SODA) permite criar, armazenar e recuperar coleções de documentos usando APIs NoSQL. 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 acesso NoSQL e casos de uso especializados.