O AlloyDB Omni é um pacote de software de banco de dados para download que permite implantar uma edição simplificada do AlloyDB para PostgreSQL no seu próprio ambiente de computação. A portabilidade do AlloyDB Omni permite que ele seja executado em uma ampla variação de ambientes, incluindo os seguintes:
- Data centers
- Laptops
- Instâncias de VM baseadas na nuvem
O AlloyDB Omni é adequado para os seguintes cenários:
- Você precisa de uma versão escalonável e com bom desempenho do PostgreSQL, mas não pode executar um banco de dados na nuvem devido a requisitos regulatórios ou de soberania de dados.
- Você precisa de um banco de dados que continue em execução mesmo quando estiver desconectado da Internet.
- Você quer localizar fisicamente o banco de dados o mais próximo possível dos usuários para minimizar a latência.
- Você quer uma maneira de migrar de um banco de dados legado, mas sem se comprometer com uma migração completa para a nuvem.
O AlloyDB Omni não inclui recursos do AlloyDB que dependem da operação em Google Cloud. Se você quiser fazer upgrade do seu projeto para os recursos de escalonamento, segurança e disponibilidade totalmente gerenciados do AlloyDB, migre os dados do AlloyDB Omni para um cluster do AlloyDB da mesma forma que qualquer outra importação inicial de dados.
Principais recursos
- Um servidor de banco de dados compatível com PostgreSQL.
- Suporte para AlloyDB AI, um conjunto integrado de recursos integrados ao AlloyDB, para ajudar você a criar aplicativos de IA generativa de nível empresarial usando seus dados operacionais.
- Integrações com o Google Cloud ecossistema de IA, incluindo o Model Garden da Vertex AI e ferramentas de IA generativa de código aberto.
- Um consultor de índice que analisa consultas executadas com frequência e recomenda novos índices para melhorar o desempenho da consulta.
- O mecanismo de colunas do AlloyDB, que mantém os dados consultados com frequência em um formato colunar na memória para melhor desempenho em Business Intelligence, geração de relatórios e cargas de trabalho híbridas de processamento analítico e transacional (HTAP).
- Outras otimizações e melhorias em relação a um servidor PostgreSQL padrão, como gerenciamento automático de memória e autovacuum adaptativo de dados desatualizados.
Como o AlloyDB Omni funciona
O AlloyDB Omni pode ser instalado como um servidor independente ou como parte de um ambiente do Kubernetes.
O AlloyDB Omni é executado em um contêiner do Docker que você instala no seu ambiente. Recomendamos executar o AlloyDB Omni em um sistema Linux com armazenamento SSD e pelo menos 8 GB de memória por CPU.
O operador AlloyDB Omni no Kubernetes é uma extensão da API Kubernetes que permite executar o AlloyDB Omni na maioria dos ambientes do Kubernetes em conformidade com CNCF. Para mais informações, consulte Instalar o AlloyDB Omni no Kubernetes.
Seus aplicativos se conectam e se comunicam com a instalação do AlloyDB Omni exatamente como fariam com um servidor de banco de dados PostgreSQL comum. O controle de acesso do usuário também depende dos padrões do PostgreSQL.
É possível configurar o comportamento do AlloyDB Omni usando as mesmas flags de banco de dados disponíveis para o AlloyDB.
Arquitetura do mecanismo de banco de dados do AlloyDB Omni em uma VM
Este documento descreve a arquitetura do banco de dados no AlloyDB Omni em um contêiner. Este documento pressupõe que você já conhece o PostgreSQL.
Um mecanismo de banco de dados realiza as seguintes tarefas:
- Converte uma consulta de um cliente em um plano executável
- Encontra os dados necessários para atender à consulta
- Executa qualquer filtragem, ordenação e agregação necessária
- Retorna os resultados para o cliente
Quando o aplicativo cliente envia uma consulta para o AlloyDB Omni, as seguintes ações ocorrem:
- A camada de processamento de consulta transforma a consulta em um plano de execução que vai para a camada de execução de consulta.
- A camada de execução de consulta realiza as operações necessárias para calcular a resposta à consulta.
- Durante a execução, os dados podem ser carregados do cache de buffer ou diretamente do armazenamento. Se os dados forem carregados do armazenamento, eles serão armazenados no cache para uso futuro.
Os recursos usados ao processar a consulta do cliente incluem CPU, memória, E/S, rede e primitivas de sincronização, como bloqueios de banco de dados. O objetivo do ajuste de desempenho é otimizar a utilização de recursos durante cada uma das etapas da execução da consulta.
O objetivo de um mecanismo de banco de dados com bom desempenho é responder a uma consulta usando o menor número possível de recursos. Essa meta começa com um bom modelo de dados e design de consulta.
- Como as consultas podem ser respondidas analisando a menor quantidade de dados?
- Quais índices são necessários para reduzir o espaço de pesquisa e a E/S?
- A classificação de dados requer CPU e, muitas vezes, acesso ao disco para grandes conjuntos de dados. Como evitar a classificação de dados?
Armazenamento de dados
O AlloyDB Omni armazena dados em páginas de tamanho fixo armazenadas no sistema de arquivos. Quando uma consulta precisa acessar dados, o AlloyDB Omni verifica primeiro o pool de buffer. Se as páginas que contêm os dados necessários não forem encontradas no pool de buffer, o AlloyDB Omni vai ler as páginas necessárias do sistema de arquivos. O acesso a dados do pool de buffer é muito mais rápido do que a leitura do sistema de arquivos. Portanto, maximizar o tamanho do pool de buffer para a quantidade de dados que serão acessados por um aplicativo é um fator importante.
Gerenciamento de recursos
O AlloyDB Omni usa o gerenciamento de memória dinâmico para permitir que o pool de buffer cresça e diminua dinamicamente dentro dos limites configurados, dependendo das demandas de memória do sistema. Portanto, não é necessário ajustar o tamanho do pool de buffer. Ao diagnosticar problemas de desempenho, as primeiras métricas a serem consideradas são a taxa de acerto do pool de buffer e a taxa de leitura para saber se o aplicativo está aproveitando o pool de buffer. Caso contrário, isso indica que o conjunto de dados do aplicativo não cabe no pool de buffer, e você pode considerar redimensionar para uma máquina maior com mais memória.
O processo de extração, filtragem, agregação, classificação e projeção de dados exige recursos de CPU no servidor do banco de dados. Para reduzir a quantidade de recursos de CPU necessários para esse processo, minimize a quantidade de dados que precisam ser manipulados. Monitore a utilização da CPU no servidor do banco de dados para garantir que a utilização no estado estável seja de cerca de 70%. Essa quantidade deixa espaço suficiente no servidor para picos de utilização ou mudanças nos padrões de acesso ao longo do tempo. A execução com uma utilização mais próxima de 100% gera sobrecarga devido à programação de processos e à alternância de contexto e pode criar gargalos em outras partes do sistema. A alta utilização da CPU é outra métrica importante a ser usada ao tomar decisões sobre as especificações da máquina.
As operações de entrada/saída por segundo (IOPS) são um fator importante no desempenho do aplicativo do banco de dados, ou seja, quantas operações de entrada ou saída por segundo o dispositivo de armazenamento pode fornecer ao banco de dados. Para evitar atingir os limites de IOPS do armazenamento do banco de dados, minimize as leituras e gravações no armazenamento maximizando a quantidade de dados que podem caber no pool de buffer.
Backup de dados e recuperação de desastres
O AlloyDB Omni tem um sistema de backup e recuperação contínuo que permite criar um novo cluster de banco de dados com base em qualquer ponto em um período de armazenamento ajustável. Isso permite que você se recupere rapidamente de acidentes de perda de dados.
Além disso, o AlloyDB Omni pode criar e armazenar backups completos dos dados do cluster do banco de dados, sob demanda ou em uma programação regular. A qualquer momento, é possível restaurar um backup para um cluster de banco de dados do AlloyDB Omni que contém todos os dados do cluster de banco de dados original no momento da criação do backup.
Para mais informações, consulte Fazer backup e restaurar o AlloyDB Omni.
Como outro método de recuperação de desastres, é possível realizar a replicação entre data centers criando clusters de banco de dados secundários em data centers separados. O AlloyDB Omni transmite dados de um cluster de banco de dados principal designado de forma assíncrona para cada um dos clusters secundários. Sempre que necessário, é possível promover um cluster de banco de dados secundário para um cluster de banco de dados principal do AlloyDB Omni.
Para mais informações, consulte Sobre a replicação entre data centers.
Documentação para a versão 15.5.2 e anteriores do AlloyDB Omni
Para saber mais sobre a versão anterior do AlloyDB Omni, consulte o conjunto de documentação do AlloyDB Omni para vários contêineres.