A portabilidade do AlloyDB Omni permite que você o execute em muitos ambientes, incluindo:
- Data centers
- Laptops
- Instâncias de VM baseadas na nuvem
Casos de uso do AlloyDB Omni
O AlloyDB Omni é adequado para os seguintes cenários:
- Você precisa de uma versão escalonável e de alta performance 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 funcionando mesmo quando estiver desconectado da Internet.
- Para minimizar a latência, você quer localizar seu banco de dados o mais próximo possível dos seus usuários.
- Você gostaria 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 totalmente gerenciados de escalonamento, segurança e disponibilidade do AlloyDB, migre os dados do AlloyDB Omni para um cluster do AlloyDB, assim como faria com qualquer outra importação inicial de dados.
Principais recursos
- Um servidor de banco de dados compatível com PostgreSQL.
- Suporte à IA do AlloyDB, que ajuda 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.
Suporte aos recursos de piloto automático do AlloyDB em Google Cloud que permite que o AlloyDB Omni se autogerencie e se ajuste.
Por exemplo, o AlloyDB Omni oferece suporte ao gerenciamento automático de memória e ao autovacuum adaptável de dados obsoletos.
Um consultor de índice que analisa consultas executadas com frequência e recomenda novos índices para melhorar a performance da consulta.
O mecanismo colunar do AlloyDB Omni , que mantém os dados consultados com frequência em um formato colunar na memória para melhor performance em Business Intelligence, geração de relatórios e cargas de trabalho de processamento híbrido e de transação híbrido (HTAP).
Em nossos testes de performance, as cargas de trabalho transacionais no AlloyDB Omni são mais de duas vezes mais rápidas, e as consultas analíticas são até 100 vezes mais rápidas do que o PostgreSQL padrão.
Como o AlloyDB Omni funciona
É possível instalar o AlloyDB Omni 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 próprio ambiente. Recomendamos que você execute o AlloyDB Omni em um sistema Linux com armazenamento SSD e pelo menos 8 GB de memória por CPU.
O operador do AlloyDB Omni no Kubernetes é uma extensão da API Kubernetes que permite executar o AlloyDB Omni na maioria dos ambientes do Kubernetes em compliance 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, assim como os aplicativos se conectam e se comunicam com um padrão com um servidor de banco de dados PostgreSQL. O controle de acesso do usuário também depende dos padrões do PostgreSQL.
Do registro em log ao vácuo e ao mecanismo colunar, é possível configurar o comportamento do banco de dados do AlloyDB Omni usando flags de banco de dados.
Vantagens de executar o AlloyDB Omni como um contêiner
O Google distribui o AlloyDB Omni como um contêiner que pode ser executado com ambientes de execução de contêiner, como Docker e Podman. Operacionalmente, os contêineres apresentam as seguintes vantagens:
- Gerenciamento de dependências transparente: todas as dependências necessárias são agrupadas no contêiner e testadas pelo Google para garantir que sejam totalmente compatíveis com o AlloyDB Omni.
- Portabilidade: você pode esperar que o AlloyDB Omni opere de maneira consistente em todos os ambientes.
- Isolamento de segurança: você escolhe a que o contêiner do AlloyDB Omni tem acesso na máquina host.
- Gerenciamento de recursos: é possível definir a quantidade de recursos de computação que você quer que o contêiner do AlloyDB Omni use.
- Aplicação de patches e upgrades sem problemas: para aplicar um patch a um contêiner, basta substituir a imagem atual por uma nova.
Backup de dados e recuperação de desastres
O AlloyDB Omni apresenta um sistema contínuo de backup e recuperação que permite criar um novo cluster de banco de dados com base em qualquer momento dentro de 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 de 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 contenha 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 forma assíncrona de um cluster de banco de dados primário designado 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 primário do AlloyDB Omni.
Para mais informações, consulte Sobre a replicação entre data centers
Componentes de VM do AlloyDB Omni
O AlloyDB Omni na VM consiste em dois conjuntos de componentes de arquitetura: componentes do PostgreSQL com melhorias do AlloyDB para PostgreSQL e componentes do AlloyDB para PostgreSQL. O diagrama a seguir descreve os dois conjuntos de componentes, a camada de infraestrutura em que eles residem em uma VM ou servidor e os recursos relacionados que você pode esperar para cada componente.
Figura 1. Arquitetura do AlloyDB Omni
Mecanismo de banco de dados
Este documento descreve a arquitetura do banco de dados no AlloyDB Omni em um contêiner. Ele pressupõe que você esteja familiarizado com o PostgreSQL.
Um mecanismo de banco de dados realiza as seguintes tarefas:
- Traduz uma consulta de um cliente em um plano executável
- Encontra os dados necessários para atender à consulta
- Realiza 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 consultas transforma a consulta em um plano de execução que vai para a camada de execução de consultas.
- A camada de execução de consultas 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 primitivos de sincronização, como bloqueios de banco de dados. O ajuste de performance tem como objetivo otimizar a utilização de recursos durante cada uma das etapas na execução da consulta.
O objetivo de um mecanismo de banco de dados de alta performance é responder a uma consulta usando o menor número de recursos necessários. Esse objetivo começa com um bom modelo de dados e design de consulta.
- Como as consultas podem ser respondidas ao analisar 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 exige CPU e, geralmente, acesso a disco para grandes conjuntos de dados. Como é possível evitar a classificação de dados?
Armazenamento de dados
O AlloyDB Omni armazena dados em páginas de tamanho fixo que são armazenadas no sistema de arquivos subjacente. Quando uma consulta precisa acessar dados, o AlloyDB Omni primeiro verifica o pool de buffers. Se as páginas que contêm os dados necessários não forem encontradas no pool de buffers, o AlloyDB Omni vai ler as páginas necessárias do sistema de arquivos. O acesso a dados do pool de buffers é significativamente mais rápido do que a leitura do sistema de arquivos. Portanto, maximizar o tamanho do pool de buffers para a quantidade de dados que serão acessados por um aplicativo é um fator importante.
Gerenciamento de recursos
O AlloyDB Omni usa o gerenciamento dinâmico de memória para permitir que o pool de buffers 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 buffers. Ao diagnosticar problemas de performance, as primeiras métricas a serem consideradas são a taxa de acertos do pool de buffers e a taxa de leitura para verificar se o aplicativo está recebendo o benefício do pool de buffers. Caso contrário, isso indica que o conjunto de dados do aplicativo não se ajusta ao pool de buffers, e você pode considerar redimensionar para uma máquina maior com mais memória.
O processo de recuperação, filtragem, agregação, classificação e projeção de dados exige recursos de CPU no servidor de 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 de banco de dados para garantir que a utilização do 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% introduz um overhead devido ao agendamento de processos e à troca 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, na sigla em inglês) são um fator importante na performance do aplicativo de banco de dados: quantas operações de entrada ou saída por segundo o dispositivo de armazenamento subjacente pode entregar 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 buffers.
Mecanismo colunar
O mecanismo colunar acelera o processamento de consulta SQL de verificações, mesclagens e agregações, fornecendo os seguintes componentes:
Repositório de colunas na memória: contém dados de tabela e de visualização materializada para colunas selecionadas em um formato orientado a colunas. Por padrão, o repositório de colunas consome 1 GB de memória disponível. Para mudar a quantidade de memória utilizável pelo repositório de colunas, defina o parâmetro
google_columnar_engine.memory_size_in_mbnopostgresql.confusado pela instância do AlloyDB Omni.Para mais informações sobre como mudar o parâmetro, consulte Alterar parâmetros de configuração.
Planejador de consultas e mecanismo de execução colunar: oferece suporte ao uso do repositório de colunas em consultas.
Gerenciamento automático de memória
O gerenciador automático de memória monitora e otimiza continuamente o consumo de memória em toda uma instância do AlloyDB Omni. Ao executar cargas de trabalho, esse módulo ajusta o tamanho do cache de buffer compartilhado com base na pressão da memória. Por padrão, o gerenciador automático de memória define o limite superior como 80% da memória do sistema e aloca 10% da memória do sistema para o cache de buffer compartilhado.
Para mudar o limite superior do tamanho do cache de buffer compartilhado, defina o parâmetro shared_buffers no postgresql.conf usado pela instância do AlloyDB Omni.
Para mais informações, consulte Gerenciamento automático de memória.
Autovacuum adaptável
O autovacuum adaptável analisa operações com base na carga de trabalho do banco de dados e ajusta automaticamente a frequência do vácuo. Esse ajuste automático ajuda o banco de dados a ser executado com performance máxima, mesmo quando a carga de trabalho muda, sem interferência do processo de vácuo.
O autovacuum adaptável usa os seguintes fatores para determinar a frequência e a intensidade das operações de vácuo:
- Tamanho do banco de dados
- Número de tuplas desativadas no banco de dados
- Idade dos dados no banco de dados
- Número de transações por segundo em comparação com a velocidade estimada do vácuo
O autovacuum adaptável oferece os seguintes benefícios:
- Gerenciamento dinâmico de recursos de vácuo: em vez de usar um limite de custo fixo,
o AlloyDB Omni usa estatísticas de recursos em tempo real para ajustar os
workers de vácuo. Quando o sistema está ocupado, o processo de vácuo e a utilização de recursos associada são limitados. Se houver memória suficiente disponível, mais memória será alocada para
maintenance_work_mempara reduzir o tempo de vácuo de ponta a ponta. - Limitação dinâmica de XID: monitora automaticamente e continuamente o
progresso do vácuo e a velocidade do consumo do ID da transação. Se um risco de encapsulamento do ID da transação for detectado, o AlloyDB Omni vai desacelerar as transações para limitar o consumo de ID. Além disso, o AlloyDB Omni aloca mais recursos para os workers de vácuo para processar as tabelas que bloqueiam o avanço e a liberação do espaço do ID da transação. Durante esse processo, as transações gerais por segundo são reduzidas até que os IDs de transação estejam em uma zona de segurança (observável como sessões aguardando
AdaptiveVacuumNewXidDelay). Quando a idade do ID da transação aumenta, os workers de vácuo são aumentados dinamicamente. - Vácuo eficiente para tabelas maiores: a lógica padrão do PostgreSQL
usada para decidir quando fazer o vácuo de uma tabela é baseada em estatísticas específicas da tabela
armazenadas em
pg_stat_all_tables, que contém a proporção de tuplas desativadas. Essa lógica funciona para tabelas pequenas, mas pode não funcionar com eficiência para tabelas maiores e atualizadas com frequência. O AlloyDB Omni oferece um mecanismo de verificação atualizado que ajuda a acionar o autovacuum com mais frequência. Esse mecanismo de verificação verifica blocos de tabelas grandes e remove tuplas desativadas com mais eficiência do que a lógica padrão do PostgreSQL. - Mensagens de aviso de registro: no AlloyDB Omni, os bloqueadores de vácuo, como transações de longa duração ou transações preparadas ou slots de replicação que perderam os destinos, são detectados e os avisos são registrados nos registros do PostgreSQL para que você resolva os problemas de maneira oportuna.
Worker de IA/ML
No AlloyDB Omni, o worker de IA/ML em segundo plano fornece todos os recursos necessários para chamar modelos da Vertex AI diretamente do banco de dados. O worker de IA/ML é executado como um processo chamado omni ml worker.
Para mais informações, consulte Criar aplicativos de IA generativa usando a IA do AlloyDB.