O AlloyDB Omni é um pacote de software de banco de dados para download que permite implantar uma versão simplificada do AlloyDB para PostgreSQL em ambientes de computação gerenciados por você. O AlloyDB Omni e o serviço AlloyDB totalmente gerenciado no Google Cloud compartilham os mesmos componentes principais. O AlloyDB usa uma camada de armazenamento desagregada nativa da nuvem, enquanto o AlloyDB Omni é implantado no armazenamento de sua escolha.
A portabilidade do AlloyDB Omni permite que ele seja executado em vários ambientes, incluindo:
- Seus data centers particulares
- Qualquer nuvem pública
- Seu laptop
- Instâncias de VM baseadas na nuvem
O AlloyDB Omni oferece várias melhorias, além do PostgreSQL padrão, que oferecem suporte à escalonabilidade, disponibilidade, confiabilidade, desempenho, IA e linguagem natural. Para mais informações, consulte Adições do AlloyDB Omni para o PostgreSQL padrão.
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 que precisa ser executada no local 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.
- Você quer migrar de um banco de dados legado sem se comprometer com um serviço de nuvem totalmente gerenciado, como o AlloyDB para PostgreSQL.
Principais recursos
- Um servidor de banco de dados 100% 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 Vertex AI Model Garden e ferramentas de IA generativa de código aberto.
Suporte aos recursos de piloto automático do AlloyDB para PostgreSQL em Google Cloud que permite que o AlloyDB Omni seja autogerenciado e autoajustado.
Por exemplo, o AlloyDB Omni oferece suporte ao gerenciamento automático de memória e ao autovacuum adaptável de dados obsoletos.
O mecanismo colunar do AlloyDB Omni, que mantém os dados relevantes em um formato colunar na memória para consultas analíticas, relatórios e cargas de trabalho de processamento transacional e analítico híbrido (HTAP) mais rápidos.
Em 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.
Opções de implantação do AlloyDB Omni
É possível instalar o AlloyDB Omni usando uma das seguintes opções de implantação:
AlloyDB Omni usando contêineres: um contêiner de banco de dados independente. Execute o AlloyDB Omni em um sistema Linux com armazenamento SSD e pelo menos 8 GB de memória por CPU.
AlloyDB Omni usando o orquestrador de contêineres: parte de um contêiner em um ambiente do Kubernetes. 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 compliance com CNCF.
O operador AlloyDB Omni simplifica as operações básicas de banco de dados, o que permite automatizar implantações únicas ou de alta disponibilidade (HA) e operações do dia a dia, como backup, restauração, failover e configuração de recuperação de desastres (DR) entre regiões.
AlloyDB Omni usando RPM: um pacote independente que é executado diretamente em uma VM ou bare metal. O AlloyDB Omni usando RPM é executado como um conjunto de componentes de software integrados diretamente no sistema operacional host. Ele usa o sistema de arquivos Linux padrão para armazenamento, permitindo que você use sua infraestrutura de armazenamento e práticas de gerenciamento atuais.
AlloyDB Omni usando o orquestrador RPM (visualização): uma implantação do Red Hat Package Manager (RPM) para VMs ou servidores bare metal. Essa opção inclui uma plataforma de orquestração que automatiza a implantação e o gerenciamento em ambientes não Kubernetes. Ela estende a flexibilidade semelhante à nuvem para a infraestrutura escolhida, sem exigir camadas de contêinerização, como o Docker.
Seus aplicativos se conectam e se comunicam com o banco de dados do AlloyDB Omni, assim como os aplicativos 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.
É possível configurar o comportamento do banco de dados do AlloyDB Omni usando flags de banco de dados, incluindo registro, limpeza e o mecanismo colunar. Para mais informações, consulte Opções de download e instalação disponíveis do AlloyDB Omni.
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. Também é possível implantar contêineres do AlloyDB Omni em um ambiente do Kubernetes com muitas operações básicas automatizadas.
Operacionalmente, os contêineres oferecem 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: o AlloyDB Omni funciona 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.
- Patches e upgrades sem interrupções: para aplicar um patch a um contêiner, substitua a imagem atual por uma nova.
AlloyDB Omni em um ambiente RHEL
O AlloyDB Omni oferece duas opções de implantação para um ambiente RHEL, que dependem dos requisitos de automação e escalonamento.
AlloyDB Omni usando RPM
A opção de implantação do RPM é uma instalação independente do Red Hat Package Manager (RPM) projetada para ambientes em que você quer um banco de dados do AlloyDB Omni não contêinerizado. Essa opção oferece suporte ao RHEL 9 e ao Rocky Linux 9.
- Integração direta do SO: é executado como um conjunto de componentes de software integrados diretamente no sistema operacional (SO) host.
- Armazenamento atual: usa o sistema de arquivos Linux padrão (ext4 e xfs), que oferece suporte à infraestrutura de armazenamento e práticas de gerenciamento atuais.
- Simplicidade: adequado para configurações de instância única em que a integração profunda com o SO host é necessária, sem camadas de orquestração adicionais.
O orquestrador RPM
A opção de implantação do orquestrador RPM (visualização) usa os mesmos pacotes RPM que o AlloyDB Omni usando RPM, mas adiciona uma plataforma de orquestração para automatizar o gerenciamento em ambientes não Kubernetes
- Flexibilidade semelhante à nuvem: estende a automação para a infraestrutura local, processando o bootstrapping, o failover e o gerenciamento do ciclo de vida.
- Frameworks de Automation: integra-se a ferramentas conhecidas, como o Ansible, permitindo que as equipes usem conjuntos de habilidades atuais. Também é possível usar ferramentas de linha de comando criadas especificamente para essa finalidade.
- Recursos empresariais: projetados especificamente para oferecer suporte à alta disponibilidade (HA) e à recuperação de desastres (DR) por meio de um gerenciador de clusters centralizado.
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 ponto no tempo dentro de um período de armazenamento ajustável. Isso permite que você se recupere 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 em que o backup foi criado.
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.
Componentes do AlloyDB Omni
O AlloyDB Omni consiste em dois conjuntos de componentes de arquitetura: componentes do PostgreSQL com melhorias do AlloyDB Omni e componentes específicos do AlloyDB Omni.
O diagrama a seguir mostra os dois conjuntos de componentes, incluindo a camada de infraestrutura em que os componentes residem e os recursos de cada componente.
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. Maximizar o tamanho do pool de buffers para os dados acessados por um aplicativo é um fator importante. Opcionalmente, adicione uma camada de cache ultrarrápida para melhorar ainda mais a performance da consulta.
Gerenciamento de recursos
O AlloyDB Omni usa o gerenciamento automático de memória dinâmica 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, considere primeiro métricas como a taxa de acertos do pool de buffers e a taxa de leitura para determinar se o aplicativo está se beneficiando 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 a serem manipulados. Monitore a utilização da CPU no servidor de banco de dados para garantir que a utilização de 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 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) são um fator importante na performance do aplicativo de banco de dados, medindo quantas operações de entrada ou saída por segundo o dispositivo de armazenamento subjacente pode entregar ao banco de dados. Para evitar exceder os limites de IOPS do armazenamento de banco de dados, minimize as leituras e gravações no armazenamento. Maximize a quantidade de dados que cabem no pool de buffers ou na camada de cache.
Mecanismo colunar
O mecanismo colunar integrado acelera o processamento de consultas analíticas que normalmente envolve verificações de tabela completa, junções complexas e agregações.
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 30% da 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.Planejador de consultas e mecanismo de execução em colunas: oferece suporte ao uso do repositório de colunas em consultas.
Para mais informações, consulte Sobre o mecanismo colunar do AlloyDB para PostgreSQL.
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.
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 da limpeza. Esse ajuste automático ajuda o banco de dados a manter a performance ideal, mesmo quando a carga de trabalho muda, sem interferência do processo de limpeza.
O autovacuum adaptável usa os seguintes fatores para determinar a frequência e a intensidade das operações de limpeza:
- 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 de limpeza
- Uso dos recursos
Worker de IA/ML
No AlloyDB Omni, o worker de IA/ML em segundo plano fornece 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.
Plano de controle do orquestrador
A opção de implantação do orquestrador RPM usa um gerenciador de clusters centralizado para automatizar operações em todo o cluster, incluindo bootstrapping e failover.
Interfaces de gerenciamento
A opção de implantação do orquestrador RPM fornece um utilitário de linha de comando (alloydbctl) e papéis do Ansible para gerenciar um ou mais clusters em escala.
Otimização de desempenho
A opção de implantação do orquestrador RPM inclui suporte integrado para o PgBouncer para o pool de conexões e o HAProxy para o balanceamento de carga em endpoints de leitura/gravação e somente leitura.
A seguir
Comece a usar as seguintes opções de implantação do AlloyDB Omni: