O AlloyDB Omni é um pacote de software de base de dados transferível que lhe permite implementar uma versão simplificada do AlloyDB para PostgreSQL em ambientes de computação que gere. O AlloyDB Omni e o serviço AlloyDB totalmente gerido no Google Cloud partilham os mesmos componentes essenciais. O AlloyDB usa uma camada de armazenamento desagregada nativa da nuvem, enquanto o AlloyDB Omni é implementado no armazenamento da sua escolha.
A portabilidade do AlloyDB Omni permite-lhe executá-lo em muitos ambientes, incluindo os seguintes:
- Os seus centros de dados privados
- Qualquer nuvem pública
- O seu portátil
- Instâncias de VM baseadas na nuvem
O AlloyDB Omni oferece várias melhorias, além do PostgreSQL padrão, que suportam escalabilidade, disponibilidade, fiabilidade, desempenho, IA e linguagem natural. Para mais informações, consulte o artigo Adições do AlloyDB Omni ao PostgreSQL padrão.
Exemplos de utilização do AlloyDB Omni
O AlloyDB Omni é adequado para os seguintes cenários:
- Precisa de uma versão escalável e de elevado desempenho do PostgreSQL que tem de executar no local devido a requisitos regulamentares ou de soberania dos dados.
- Precisa de uma base de dados que continue a ser executada mesmo quando está desligada da Internet.
- Quer migrar de uma base de dados antiga sem se comprometer com um serviço de nuvem totalmente gerido, como o AlloyDB para PostgreSQL.
Funcionalidades principais
- Um servidor de base de dados 100% compatível com o PostgreSQL.
- Suporte para o AlloyDB AI, que ajuda a criar aplicações de IA generativa de nível empresarial com os 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 para funcionalidades de condução autónoma do AlloyDB para PostgreSQL no Google Cloud que permite ao AlloyDB Omni autogerir-se e autoajustar-se.
Por exemplo, o AlloyDB Omni suporta a gestão automática de memória e o autovacuum adaptativo de dados desatualizados.
O motor de colunas do AlloyDB Omni, que mantém os dados relevantes num formato de colunas na memória para consultas analíticas, relatórios e cargas de trabalho de processamento analítico e transacional híbrido (HTAP) mais rápidos.
Nos testes de desempenho, as cargas de trabalho transacionais no AlloyDB Omni são mais de 2 vezes mais rápidas e as consultas analíticas são até 100 vezes mais rápidas do que o PostgreSQL padrão.
Como funciona o AlloyDB Omni
Pode instalar o AlloyDB Omni de uma das seguintes formas:
AlloyDB Omni para contentores: um contentor de base de dados autónomo. Execute o AlloyDB Omni num sistema Linux com armazenamento SSD e, pelo menos, 8 GB de memória por CPU.
AlloyDB Omni para Kubernetes: parte de um contentor num ambiente do Kubernetes. O operador do Kubernetes do AlloyDB Omni é uma extensão da API Kubernetes que lhe permite executar o AlloyDB Omni na maioria dos ambientes Kubernetes compatíveis com a CNCF.
O operador AlloyDB Omni simplifica as operações básicas da base de dados, o que lhe permite automatizar implementações únicas ou de alta disponibilidade (HA) e operações do dia 2, como cópia de segurança, restauro, comutação por falha e configuração da recuperação de desastres (DR) entre regiões.
AlloyDB Omni para Linux (pré-visualização): um Red Hat Package Manager (RPM) que é executado diretamente numa VM ou num sistema bare metal. O AlloyDB Omni para Linux é executado como um conjunto de componentes de software integrados diretamente no sistema operativo do anfitrião. Utiliza o sistema de ficheiros Linux padrão para armazenamento, o que lhe permite usar a sua infraestrutura de armazenamento e práticas de gestão existentes.
As suas aplicações ligam-se e comunicam com a base de dados do AlloyDB Omni, tal como as aplicações se ligam e comunicam com um servidor de base de dados PostgreSQL padrão. O controlo de acesso do utilizador também se baseia nas normas do PostgreSQL.
Desde o registo à limpeza, passando pelo motor colunar, pode configurar o comportamento da base de dados do AlloyDB Omni através de flags da base de dados.
Vantagens da execução do AlloyDB Omni como um contentor
A Google distribui o AlloyDB Omni como um contentor que pode executar com tempos de execução de contentores, como o Docker e o Podman. Também pode implementar contentores do AlloyDB Omni num ambiente do Kubernetes com muitas operações básicas automatizadas.
Do ponto de vista operacional, os contentores oferecem as seguintes vantagens:
- Gestão de dependências transparente: todas as dependências necessárias são incluídas no pacote do contentor e testadas pela Google para garantir que são totalmente compatíveis com o AlloyDB Omni.
- Portabilidade: pode esperar que o AlloyDB Omni funcione de forma consistente em todos os ambientes.
- Isolamento de segurança: escolhe a que o contentor do AlloyDB Omni tem acesso na máquina anfitriã.
- Gestão de recursos: pode definir a quantidade de recursos de computação que quer que o contentor do AlloyDB Omni use.
- Aplicação de patches e atualizações sem problemas: para aplicar um patch a um contentor, substitua a imagem existente por uma nova.
Vantagens da execução do AlloyDB Omni num ambiente RHEL
O AlloyDB Omni para Linux (pré-visualização) foi concebido para ambientes onde é preferível uma implementação de base de dados não contentorizada. Este modelo de implementação suporta servidores bare metal e máquinas virtuais.
Pode instalar o AlloyDB Omni para Linux diretamente num ambiente Red Hat Enterprise Linux (RHEL) ou compatível com o Red Hat através de gestores de pacotes do sistema operativo padrão.
O AlloyDB Omni para Linux suporta o RHEL 9 e o Rocky Linux 9.
Cópia de segurança de dados e recuperação de desastres
O AlloyDB Omni inclui um sistema de cópia de segurança e recuperação contínuo que lhe permite criar um novo cluster de base de dados com base em qualquer ponto no tempo dentro de um período de retenção ajustável. Isto permite-lhe recuperar de acidentes de perda de dados.
Além disso, o AlloyDB Omni pode criar e armazenar cópias de segurança completas dos dados do cluster da base de dados, a pedido ou de forma regular. Em qualquer altura, pode restaurar a partir de uma cópia de segurança para um cluster de base de dados do AlloyDB Omni que contenha todos os dados do cluster de base de dados original no momento em que a cópia de segurança foi criada.
Como método adicional de recuperação de desastres, pode conseguir a replicação entre centros de dados criando clusters de bases de dados secundários em centros de dados separados. O AlloyDB Omni transmite dados de forma assíncrona a partir de um cluster de base de dados principal designado para cada um dos respetivos clusters secundários. Sempre que necessário, pode promover um cluster de base de dados secundário num cluster de base de dados AlloyDB Omni principal.
Componentes do AlloyDB Omni
O AlloyDB Omni consiste em dois conjuntos de componentes de arquitetura: componentes do PostgreSQL com melhorias do AlloyDB e componentes específicos do AlloyDB.
O diagrama seguinte mostra ambos os conjuntos de componentes, incluindo a camada de infraestrutura em que os componentes residem e as funcionalidades de cada componente.
Figura 1. Arquitetura do AlloyDB Omni
Armazenamento de dados
O AlloyDB Omni armazena dados em páginas de tamanho fixo que são armazenadas no sistema de ficheiros subjacente. Quando uma consulta precisa de aceder a dados, o AlloyDB Omni verifica primeiro o conjunto de buffers. Se as páginas que contêm os dados necessários não forem encontradas no conjunto de memória intermédia, o AlloyDB Omni lê as páginas necessárias do sistema de ficheiros.
O acesso aos dados do conjunto de buffers é significativamente mais rápido do que a leitura do sistema de ficheiros. Maximizar o tamanho do conjunto de buffers para os dados aos quais uma aplicação acede é um fator importante. Opcionalmente, pode adicionar uma camada de cache ultrarrápida para melhorar ainda mais o desempenho das consultas.
Gestão de recursos
O AlloyDB Omni usa a gestão dinâmica automática de memória para permitir que o conjunto de buffers cresça e diminua dinamicamente dentro dos limites configurados, consoante as exigências de memória do sistema. Por conseguinte, não é necessário ajustar o tamanho do conjunto de buffers. Quando diagnosticar problemas de desempenho, considere primeiro métricas como a taxa de acertos do conjunto de buffers e a taxa de leitura para determinar se a sua aplicação está a beneficiar do conjunto de buffers. Caso contrário, isso indica que o conjunto de dados da aplicação não se ajusta ao conjunto de buffers e pode considerar redimensioná-lo para uma máquina maior com mais memória.
O processo de obtenção, filtragem, agregação, ordenação e projeção de dados requer recursos da CPU no servidor da base de dados. Para reduzir a quantidade de recursos de CPU necessários para este processo, minimize a quantidade de dados a manipular. Monitorize a utilização da CPU no servidor da base de dados para garantir que a utilização em estado estável é de cerca de 70%. Esta quantidade deixa espaço suficiente no servidor para picos de utilização ou alterações 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 à comutação de contexto, e pode criar gargalos noutras partes do sistema. A utilização elevada da CPU é outra métrica importante a usar quando toma 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 das aplicações de base de dados, medindo quantas operações de entrada ou saída por segundo o dispositivo de armazenamento subjacente pode fornecer à base de dados. Para evitar exceder os limites de IOPS do armazenamento da base de dados, minimize as leituras e as escritas no armazenamento maximizando a quantidade de dados que cabem no conjunto de buffers ou na camada de cache.
Motor colunar
O motor de colunas incorporado acelera o processamento de consultas analíticas que envolvem normalmente análises completas de tabelas, junções complexas e agregações.
Armazenamento de colunas na memória: contém dados de tabelas e vistas materializadas para colunas selecionadas num formato orientado para colunas. Por predefinição, o armazenamento de colunas consome 30% da memória disponível. Para alterar a quantidade de memória utilizável pelo armazenamento de colunas, defina o parâmetro
google_columnar_engine.memory_size_in_mbnopostgresql.confusado pela sua instância do AlloyDB Omni.Planeador de consultas e motor de execução colunar: suporta a utilização do armazenamento de colunas em consultas.
Gestão de memória automática
O gestor de memória automático monitoriza e otimiza continuamente o consumo de memória numa instância completa do AlloyDB Omni. Quando executa as suas cargas de trabalho, este módulo ajusta o tamanho da cache do buffer partilhado com base na pressão da memória.
Por predefinição, o gestor de memória automático define o limite máximo para 80% da memória do sistema e atribui 10% da memória do sistema à cache de buffer partilhada.
Para alterar o limite superior do tamanho da cache do buffer partilhado, defina o parâmetro shared_buffers no postgresql.conf usado pela sua instância do AlloyDB Omni.
Autovacuum adaptável
O autovacuum adaptável analisa as operações com base na carga de trabalho da base de dados e ajusta automaticamente a frequência de limpeza. Este ajuste automático ajuda a base de dados a manter um desempenho ideal, 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 limpeza:
- Tamanho da base de dados
- Número de tuplos mortos na base de dados
- Antiguidade dos dados na base de dados
- Número de transações por segundo em comparação com a velocidade de aspiração estimada
- Utilização de recursos
Trabalhador de IA/AA
No AlloyDB Omni, o trabalhador em segundo plano de IA/ML fornece as capacidades necessárias para chamar modelos da Vertex AI diretamente a partir da base de dados. O trabalhador de IA/ML é executado como um processo denominado omni ml worker.
O que se segue?
- Escolha um ambiente de implementação do AlloyDB Omni.
- Comece a usar o AlloyDB Omni para contentores.
- Comece a usar o AlloyDB Omni para Kubernetes.
- Comece a usar o AlloyDB Omni para Linux.