A portabilidade do AlloyDB Omni permite que ele seja executado em vários 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 alto 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 funcionando mesmo quando está desconectado da Internet.
- Para minimizar a latência, localize seu banco de dados o mais próximo possível dos usuários.
- Você quer migrar de um banco de dados legado, mas sem fazer 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 fazer upgrade do seu projeto para os recursos totalmente gerenciados de escalonamento, segurança e disponibilidade do AlloyDB para PostgreSQL, migre seus dados do AlloyDB Omni para um cluster do AlloyDB para PostgreSQL da mesma forma que faria com qualquer outra importação inicial de dados.
Principais recursos
- Um servidor de banco de dados compatível com PostgreSQL.
- Suporte para a IA do AlloyDB, que ajuda 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 Vertex AI Model Garden e ferramentas de IA generativa de código aberto.
Suporte aos recursos do Autopilot do AlloyDB para PostgreSQL em Google Cloud que permitem 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 adaptativo de dados desatualizados.
Um consultor de índice que analisa consultas executadas com frequência e recomenda novos índices para melhorar a performance das consultas.
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 processamento híbrido e de transação híbrido. (HTAP).
Em nossos testes de desempenho, as cargas de trabalho transacionais no AlloyDB Omni são 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 a 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 se conectam e se comunicam com um servidor de banco de dados PostgreSQL padrão. O controle de acesso do usuário também depende dos padrões do PostgreSQL.
Do registro em registros à limpeza 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 Docker e 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 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.
- Patching e upgrades sem problemas: para fazer o patch de 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ínuos que permite criar um novo cluster de banco de dados com base em qualquer momento dentro de um período de retenção ajustável. Isso permite uma recuperação rápida 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, você pode restaurar de 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 fazer 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 da VM do AlloyDB Omni
O AlloyDB Omni em 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 um servidor e os recursos relacionados que você pode esperar de 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. Neste documento, presumimos que você já conhece 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 a filtragem, a ordenação e a agregação necessárias
- Retorna os resultados para o cliente
Quando o aplicativo cliente envia uma consulta ao AlloyDB Omni, as ações a seguir 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 usos futuros.
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 desempenho visa otimizar a utilização de recursos durante cada uma das etapas da execução de consultas.
O objetivo de um mecanismo de banco de dados eficiente é responder a uma consulta usando o mínimo de recursos necessário. Isso começa com um bom modelo de dados e um design de consulta.
- Como as consultas podem ser respondidas com a menor quantidade de dados possível?
- 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, muitas vezes, acesso a disco para grandes conjuntos de dados. Então, como evitar a classificação?
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. Acessar dados do pool de buffer é muito mais rápido do que ler 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 dinâmico de memória para permitir que o pool de buffer aumente 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 desempenho, as primeiras métricas a serem consideradas são a taxa de acertos do pool de buffer e a taxa de leitura para verificar 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 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 em estado estável seja de cerca de 70%. Esse valor deixa espaço suficiente no servidor para picos de utilização ou mudanças nos padrões de acesso ao longo do tempo. Executar com uma utilização mais próxima de 100% introduz sobrecarga devido ao agendamento de processos e à troca de contexto, além de 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 especificações de máquinas.
As operações de entrada/saída por segundo (IOPS) são um fator importante no desempenho de aplicativos de banco de dados. Elas indicam quantas operações de entrada ou saída por segundo o dispositivo de armazenamento subjacente pode fornecer ao banco de dados. Para evitar atingir os limites de IOPS do armazenamento de 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 consultas SQL de verificações, junções 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 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 sua instância do AlloyDB Omni.Para mais informações sobre como mudar o parâmetro, consulte Mudar parâmetros de configuração.
Planejador de consultas colunares e mecanismo de execução: 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 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 automático de memória define o limite máximo 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 máximo do tamanho do cache de buffer compartilhado, defina o parâmetro
shared_buffers no postgresql.conf usado pela sua
instância do AlloyDB Omni.
Para mais informações, consulte Gerenciamento automático de memória.
Autovacuum adaptável
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 funcionar com desempenho máximo, mesmo quando a carga de trabalho muda, sem interferência do processo de limpeza.
O vácuo automático 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 inativas no banco de dados
- Idade dos dados no banco de dados
- Número de transações por segundo x velocidade estimada de vácuo
O autovacuum adaptativo oferece os seguintes benefícios:
- Gerenciamento dinâmico de recursos de limpeza: em vez de usar um limite de custo fixo, o AlloyDB Omni usa estatísticas de recursos em tempo real para ajustar os trabalhadores de limpeza. Quando o sistema está ocupado, o processo de limpeza e o uso de recursos associados são limitados. Se houver memória suficiente, mais memória será alocada para
maintenance_work_meme reduzir o tempo de vácuo de ponta a ponta. - Limitação dinâmica de XID: monitora automaticamente e continuamente o
progresso da limpeza e a velocidade do consumo de ID de transação. Se for detectado um risco de encapsulamento do ID da transação, o AlloyDB Omni vai diminuir a velocidade das transações para limitar o consumo de IDs. Além disso, o AlloyDB Omni aloca mais recursos para os workers de vacuum a fim de processar as tabelas que bloqueiam o avanço e a liberação do espaço de ID de 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ável como sessões aguardando
AdaptiveVacuumNewXidDelay). Quando a idade do ID de transação aumenta, os workers de limpeza são aumentados dinamicamente. - Limpeza eficiente para tabelas maiores: a lógica padrão do PostgreSQL usada para decidir quando limpar uma tabela se baseia em estatísticas específicas da tabela armazenadas em
pg_stat_all_tables, que contém a proporção de tuplas mortas. Essa lógica funciona para tabelas pequenas, mas pode não ser 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 analisa partes de tabelas grandes e remove tuplas mortas com mais eficiência do que a lógica padrão do PostgreSQL. - Registrar mensagens de aviso: no AlloyDB Omni, os bloqueadores de vacuum, como transações de longa duração, 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 a tempo.
Profissional 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 a IA do AlloyDB.
A seguir
- Saiba mais sobre as opções de download e instalação do AlloyDB Omni.
- Faça um guia de início rápido para instalar o AlloyDB Omni em uma VM.
- Faça uma instalação de instância única do AlloyDB Omni em qualquer VM do Linux.
- Saiba como instalar o AlloyDB Omni no Kubernetes.