Bancos de dados

Pontos-chave

• Motores: Db2, MariaDB, MySQL, Oracle, PostgreSQL e SQL Server. PostgreSQL para SQL avançado, extensões e consultas complexas, MySQL ou MariaDB para cargas web simples e amplamente suportadas, Oracle ou SQL Server quando licença ou recursos exigem.
• Classes de instância: uso geral (db.m*), otimizadas para memória (db.r*, db.x*, db.z1d), expansíveis (db.t*) e classes Optimized Reads com NVMe local. Escala vertical trocando a classe.
• Réplicas de leitura: cópias assíncronas que atendem leituras, até 15 por origem (Db2 até 3). Podem ficar em outra AZ ou outra Região e ser promovidas a instância independente para DR. O RDS não cria nem remove réplicas sozinho.
• Autoscaling de armazenamento: aumenta o disco quando o espaço livre fica em 10% ou menos por pelo menos 5 minutos, até o limite máximo definido. Nunca reduz.
• Armazenamento magnético foi descontinuado. Instâncias novas usam gp3 ou SSD com IOPS provisionadas.

Pontos-chave

• Armazenamento: 6 cópias dos dados em 3 AZs, num volume de cluster que cresce sozinho, até 256 TiB nas versões recentes do motor.
• Aurora Replicas: até 15 por cluster, com atraso normalmente bem abaixo de 100 ms. O reader endpoint distribui as conexões e o failover promove uma réplica por prioridade (tier 0 é a mais alta).
• Aurora Serverless v2: capacidade em ACUs (cerca de 2 GiB de memória cada) de 0 a 256, escalando em passos de até 0,5 ACU. Em 0 ACU a instância pausa nas versões suportadas.
• Global Database: até 10 Regiões secundárias, replicação normalmente abaixo de 1 segundo, RPO de 1 segundo e RTO abaixo de 1 minuto. Até 16 instâncias de leitura por secundária. Write forwarding encaminha escritas para a primária.
• I/O-Optimized: sem cobrança por I/O de leitura e escrita. Compensa quando o I/O passa de 25% da conta do Aurora (economia de até 40%). De Standard para I/O-Optimized uma vez a cada 30 dias.

Pontos-chave

• On-demand: paga por requisição, sem planejar capacidade, para tráfego desconhecido ou com picos. Provisionado: define RCUs e WCUs, com auto scaling, para tráfego previsível e mais barato. De provisionado para on-demand até 4 vezes em 24 horas, a volta a qualquer momento.
• RCU: 1 leitura fortemente consistente ou 2 eventualmente consistentes por segundo de um item de até 4 KB. WCU: 1 escrita por segundo de um item de até 1 KB. Transações custam o dobro.
• Chave de partição: use um atributo de alta cardinalidade (ID de usuário, ID de dispositivo) para espalhar as requisições. Chave de baixa cardinalidade gera partições quentes e throttling.
• Tamanho do item: até 400 KB. Objetos grandes vão para o S3 e o item guarda a chave.
• PITR: restaura para qualquer segundo dentro de um período configurável de 1 a 35 dias.

Pontos-chave

• GSI: chave de partição e de ordenação diferentes, criado a qualquer momento, só leituras eventualmente consistentes, capacidade própria. Cota padrão de 20 por tabela.
• LSI: mesma chave de partição, outra chave de ordenação, criado só junto com a tabela, aceita leitura fortemente consistente. Até 5 por tabela e 10 GB por valor de chave de partição.
• DAX: cache em memória na frente do DynamoDB, compatível com a API, leituras em microssegundos, até 10x mais rápido.
• Streams: alterações de itens em ordem, guardadas por 24 horas e consumidas pelo Lambda para processamento por eventos. TTL apaga itens expirados em poucos dias, sem consumir capacidade de escrita.
• Global tables: réplicas multiativas em várias Regiões. O padrão MREC replica normalmente em até 1 segundo. MRSC dá consistência forte entre Regiões e é escolhido na criação.

Pontos-chave

• Valkey ou Redis OSS: replicação, failover automático entre AZs, backup e restauração, pub/sub e sorted sets (rankings). O Global Datastore replica entre Regiões.
• Memcached: multithread e simples, sem replicação e sem failover. Serve para um cache de objetos que pode ser perdido.
• Lazy loading (cache-aside): lê do cache e, se faltar, lê do banco e preenche o cache. Só guarda o que é pedido, mas o dado pode ficar desatualizado e cada miss custa 3 idas.
• Write-through: atualiza o cache a cada escrita no banco. O dado nunca fica velho, mas toda escrita faz 2 idas e dados nunca lidos ocupam memória.
• TTL: some uma expiração a qualquer estratégia para limitar dados velhos e liberar memória.

Pontos-chave

• Amazon DocumentDB: documentos JSON, compatível com MongoDB.
• Amazon Keyspaces: banco wide-column serverless, compatível com Apache Cassandra.
• Amazon Neptune: banco de grafos para dados muito conectados, consultado com Gremlin, openCypher ou SPARQL.
• Amazon Redshift: data warehouse colunar para análises (OLAP) sobre grandes volumes, não para transações.

Pontos-chave

• Pool de conexões: muitos clientes de vida curta (funções Lambda) compartilham poucas conexões com o banco.
• Failover: reduz o tempo de failover em até 66% no Aurora e no RDS.
• Segurança: as credenciais ficam no AWS Secrets Manager e a autenticação IAM pode ser exigida. O proxy nunca é público e roda na VPC do banco.
• Motores: Aurora MySQL, Aurora PostgreSQL, RDS for MySQL, PostgreSQL, MariaDB e SQL Server.

Pontos-chave

• Homogênea: mesmo motor (MySQL para RDS for MySQL). O DMS ou as ferramentas nativas do motor movem os dados.
• Heterogênea: motores diferentes (Oracle para Aurora PostgreSQL). Converta esquema e código com o DMS Schema Conversion ou o AWS Schema Conversion Tool e depois mova os dados com o DMS.
• CDC: a captura de alterações replica as mudanças contínuas para um corte com downtime quase zero.
• Origem continua no ar: as aplicações seguem usando a origem durante a migração.