O AlloyDB Omni é um pacote de software de banco de dados para download que permite implantar uma versão simplificada do AlloyDB para PostgreSQL no seu próprio ambiente de computação. O AlloyDB Omni e o serviço totalmente gerenciado do AlloyDB para PostgreSQL em Google Cloud compartilham os mesmos componentes principais. O AlloyDB para PostgreSQL usa uma camada de armazenamento nativa da nuvem que otimiza o desempenho do WAL, enquanto o AlloyDB Omni usa a mesma interface de sistema de arquivos padrão usada pelo PostgreSQL.
A portabilidade do AlloyDB Omni permite que ele seja executado 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 com bom desempenho do PostgreSQL, mas não pode executar um banco de dados na nuvem devido a requisitos de soberania de dados ou regulamentares.
- Você precisa de um banco de dados que continue em execução mesmo quando estiver desconectado da Internet.
- Para minimizar a latência, localize o banco de dados o mais próximo possível dos usuários.
- 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 para PostgreSQL que dependem da operação em Google Cloud. Se você quiser atualizar seu projeto para os recursos de escalonamento, segurança e disponibilidade totalmente gerenciados do AlloyDB para PostgreSQL, migre seus dados do AlloyDB Omni para um cluster do AlloyDB para PostgreSQL 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 a AlloyDB AI, 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 a recursos de Autopilot do AlloyDB para PostgreSQL em Google Cloud , que permite que o AlloyDB Omni se autogerencie e se ajuste automaticamente.
Por exemplo, o AlloyDB Omni oferece suporte ao gerenciamento automático de memória e ao autovacuum adaptável de dados desatualizados.
Um consultor de índice que analisa consultas executadas com frequência e recomenda novos índices para melhorar o desempenho 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 desempenho em Business Intelligence, geração de relatórios e cargas de trabalho híbridas, transacionais e analíticas (HTAP).
Em nossos testes de desempenho, 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 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 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, 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 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êineres, como o Docker e o Podman. Operacionalmente, os contêineres apresentam as seguintes vantagens:
- Gerenciamento transparente de dependências: 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: o AlloyDB Omni opera de forma consistente em todos os ambientes.
- Isolamento de segurança: você escolhe o 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 AlloyDB Omni use.
- Atualizações e patches perfeitos: para corrigir um contêiner, basta substituir a imagem atual por uma nova.
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 retenção 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.
Componentes da 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, em qual camada de infraestrutura 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 do banco de dados
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 ajuste de desempenho visa 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 de recursos necessários. Essa meta começa com um bom modelo de dados e um 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 é possível 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 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 requer 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 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% introduz 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 de banco de dados: 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.
Mecanismo colunar
O mecanismo colunar acelera o processamento de consultas SQL de verificações, mesclagens e agregações fornecendo os seguintes componentes:
Armazenamento 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 armazenamento de colunas consome 1 GB de memória disponível. Para mudar a quantidade de memória que pode ser usada pelo armazenamento 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 Mudar parâmetros de configuração.
Planificador de consultas colunares e mecanismo de execução: oferece suporte ao uso do armazenamento de colunas em consultas.
Gerenciamento automático de memória
O gerenciador de memória automático monitora e otimiza continuamente o consumo
de memória em uma instância inteira do AlloyDB Omni. Quando você executa
as 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 de memória automático define o limite máximo em 80%
da memória do sistema e aloca 10% da memória do sistema para o cache de buffer compartilhado.
Para mudar o limite máximo 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.
Autolimpeza adaptativa
O autovacuum adaptável analisa as operações com base na carga de trabalho do banco de dados e ajusta automaticamente a frequência da limpeza. Esse ajuste automático ajuda o banco de dados a executar no pico de desempenho, mesmo que a carga de trabalho mude, sem interferência do processo de vácuo.
O autovacuum adaptativo usa os seguintes fatores para determinar a frequência e a intensidade das operações de aspiração:
- Tamanho do banco de dados
- Número de tuplas inativas no banco de dados
- Idade dos dados no banco de dados
- Número de transações por segundo em relação à velocidade estimada do vácuo
O autovacuum adaptativo 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 aspiração e a utilização de recursos
associados são limitados. Se houver memória suficiente disponível,
mais memória será alocada para
maintenance_work_mempara reduzir o tempo de aspiração de ponta a ponta. - Restrição dinâmica de XID: monitora de forma automática e contínua o
progresso da aspiração e a velocidade do consumo de ID de 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 IDs. 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 de 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 segura (observáveis como
sessões aguardando
AdaptiveVacuumNewXidDelay). Quando a idade do ID de transação aumenta, os workers de aspiração são aumentados dinamicamente. - Aspiração eficiente para tabelas maiores: a lógica padrão do PostgreSQL
usada para decidir quando aspirar uma tabela é baseada em estatísticas específicas da tabela
armazenadas em
pg_stat_all_tables, que contém a proporção de tupla inválida. Essa lógica funciona para tabelas pequenas, mas pode não funcionar de maneira eficiente 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 partes de tabelas grandes e remove tuplas inativas 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 avisos são registrados nos registros do PostgreSQL para que você resolva os problemas em tempo hábil.
Trabalhador de IA/ML
No AlloyDB Omni, o worker em segundo plano de IA/ML oferece 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 o AlloyDB AI.