O que é o Azure HorizonDB (Preview)?

O Azure HorizonDB é um serviço de base de dados nativo da cloud, totalmente gerido e pronto para IA, construído em PostgreSQL. Combina uma arquitetura de computação e armazenamento desagregada com um design de base de dados como registo para oferecer desempenho previsível, segurança de nível empresarial, alta disponibilidade e escalabilidade fluida para cargas de trabalho críticas.

O Azure HorizonDB capacita os programadores a construir aplicações inteligentes baseadas em IA através do suporte nativo para embeddings vetoriais e integração com o Azure AI Foundry Tools, mantendo a compatibilidade total com o PostgreSQL, permitindo que as aplicações existentes migrem facilmente para o Azure HorizonDB.

Azure HorizonDB casos de uso

O Azure HorizonDB é uma alternativa escalável nativa da cloud ao PostgreSQL autogerido e foi concebido para cargas de trabalho críticas para a missão, não limitadas a, mas incluindo:

  • Cargas de trabalho transacionais (OLTP) - Processamento de transações de alto débito e baixa latência com desempenho previsível para aplicações de linha de negócio, plataformas de comércio eletrónico e backends SaaS.
  • IA e aplicações inteligentes - O suporte nativo de pesquisa vetorial e embedding permite-lhe construir pipelines de geração aumentada por recuperação (RAG), motores de recomendação e pesquisa semântica diretamente na camada da base de dados. A gestão de modelos de IA e os pipelines de IA simplificam ainda mais a construção de aplicações inteligentes dentro da base de dados.
  • Escalonamento massivo da leitura - Aplicações que podem beneficiar da escalonabilidade da leitura com dados resilientes em zonas partilhadas.
  • Aplicações híbridas - Integração com o ecossistema Azure, espelhamento de dados transacionais para o Fabric OneLake, integrados com outros dados analíticos.

Arquitetura do Azure HorizonDB

O Azure HorizonDB baseia-se em dois princípios arquitetónicos fundamentais: separação entre computação e armazenamento, e um design de base de dados como log.

Diagrama mostrando a arquitetura Azure HorizonDB.

Computação e armazenamento desagregados

A arquitetura separa totalmente a camada de computação da camada de armazenamento:

  • Camada de computação - A computação no Azure HorizonDB é sem estado. Os recursos de computação (vCores e memória) podem ser escalados de forma independente sem afetar o armazenamento, e vice-versa. Pode escalar as leituras horizontalmente adicionando réplicas ao cluster do HorizonDB.
  • Camada de armazenamento - A camada de armazenamento utiliza duas infraestruturas de armazenamento concebidas especificamente para o efeito: uma dedicada ao WAL e outra dedicada a dados; ambas com durabilidade assegurada pelo armazenamento do Azure. Todo o armazenamento é resiliente entre zonas por defeito. O armazenamento escala automaticamente à medida que os dados crescem, independentemente do nível de computação provisionado.

A separação entre computação e armazenamento oferece vários benefícios:

  • Escalar computação e armazenamento de forma independente com base nas exigências de carga de trabalho.
  • Provisão rápida de réplicas de leitura, uma vez que partilham o mesmo armazenamento subjacente e não é necessária replicação de dados.
  • Failover mais rápido para alta disponibilidade, uma vez que o armazenamento WAL durável é partilhado e não é necessário retroceder os registos.

Arquitetura de base de dados como registo

O Azure HorizonDB adota a arquitetura database-as-a-log, onde apenas o WAL (Write ahead log) é escrito do compute para a camada de armazenamento. As páginas de dados não são escritas a partir das réplicas de computação para a camada de armazenamento. A WAL é a fonte fidedigna em todo o sistema.

  • Todas as operações de escrita (registo de escrita antecipada) são adicionadas a um serviço de log persistente antes de serem confirmadas ao cliente. O Serviço WAL está otimizado para a semântica de um registo de transações e para baixa latência.
  • O WAL filtrado é enviado apenas para os nós de armazenamento a que pertencem as alterações.
  • Os nós de armazenamento reconstituem o estado da página aplicando o WAL, eliminando os gargalos tradicionais de E/S associados ao checkpoint.
  • Esta abordagem reduz a amplificação da escrita e proporciona uma latência de escrita consistente e previsível, independentemente do tamanho da base de dados.

A combinação destes dois princípios permite que o Azure HorizonDB ofereça alto rendimento, baixa latência e utilização eficiente dos recursos, mantendo garantias completas de ACID.

Cluster

Um recurso Azure HorizonDB provisionado é um cluster. Um cluster do Azure HorizonDB tem:

  • Uma ou mais réplicas de computação, sendo uma delas uma réplica primária com escrita e as restantes réplicas em espera só de leitura.
  • Uma única cópia dos dados em armazenamento resiliente por zonas partilhada por todas as réplicas do cluster.
  • Um endpoint de leitura-escrita que aponta sempre para a réplica primária.
  • Um endpoint só de leitura que distribui a carga das ligações entre todas as réplicas legíveis.

Cálculo de réplicas

Uma réplica computada do Azure HorizonDB pode ser a principal (gravável) ou uma réplica de reserva que é legível, sendo também candidata a failover. Compute replica é onde reside o motor relacional PostgreSQL e onde ocorrem a linguagem, a consulta e o processamento de transações. Todas as interações com o cluster Azure HorizonDB acontecem através das réplicas de computação. Para ter resiliência zonal, é necessário pelo menos duas réplicas no cluster. Podes adicionar ou remover réplicas ao cluster do Azure HorizonDB conforme a tua carga de trabalho precisar.

As réplicas de computação vêm com 8 GB de memória por núcleo provisionado. As réplicas de computação também dispõem de uma cache SSD local. Esta cache é uma cache NVMe de baixa latência que armazena em cache páginas quentes e minimiza a necessidade de obter dados da camada remota de armazenamento. A memória cache está presente em todas as réplicas, na réplica primária e na réplica de espera.

As réplicas computacionais são usadas de forma eficiente, pois transferem tarefas relacionadas com durabilidade e alta disponibilidade para a camada de armazenamento. Esta transferência de carga liberta mais recursos de CPU, disco e rede para executar, na base de dados, a lógica de negócio das aplicações. As seguintes tarefas são transferidas das réplicas de Computação para a camada de armazenamento.

Tarefa Processo PostgreSQL Poupança de recursos
Envio de WAL a partir de réplicas walsender E/S de Disco, E/S de Rede
Arquivação de WAL em armazenamento de blobs Arquivador E/S de Disco, E/S de Rede
Escrita de Páginas Sujas Argumentista de fundo E/S de Disco
Pontos de verificação Ponto de controlo E/S de Disco
Backups pg_dump, pg_basebackup, pg_backup_start, pg_backup_stop E/S de Disco
Página inteira escreve Processos de backend a escrever no WAL E/S de Disco
Recuperação do WAL do PostgreSQL Startup em recuperação E/S de Disco
Refazer réplica de leitura do PostgreSQL Startup em recuperação E/S de Disco

Armazenamento

O Azure HorizonDB executa duas frotas de armazenamento suportadas por armazenamento blob do Azure. Todas as camadas da pilha de armazenamento são resistentes a zonas de falha por defeito.

Armazenamento WAL

O serviço WAL é um serviço concebido especificamente que aceita WAL da réplica de computação primária e está otimizado para baixa latência e para os padrões de escrita de WAL. Quando é feita uma alteração de dados (inserir/atualizar/eliminar) na réplica primária, o WAL é escrito no serviço WAL e a transação é confirmada. O WAL é então aplicado de forma assíncrona aos respetivos fragmentos de dados na frota de armazenamento de dados para aplicar as alterações mais recentes. Além disso, o WAL é enviado para réplicas de computação secundárias para refazer quaisquer alterações nas páginas que estejam na memória das réplicas. O WAL é então arquivado no armazenamento de blobs do Azure e mantido pelo período de retenção de curto prazo configurado.

Armazenamento de dados

A frota de armazenamento de dados é uma cache para todos os dados na base de dados que fornece dados a todas as réplicas computacionais no cluster Azure HorizonDB. O armazenamento é alocado dinamicamente à medida que a base de dados cresce, sem necessidade de configurar o tamanho do armazenamento ou IOPS. Os dados das relações postgres são fragmentados entre os múltiplos nós de armazenamento da frota para proporcionar melhor escalabilidade. Existem múltiplas cópias do mesmo fragmento de dados armazenadas entre zonas para maior resiliência. À medida que o WAL é reaplicado na infraestrutura de armazenamento, as páginas sujas são depois escritas no Azure Blob Storage.

Armazenamento em Blobs do Azure

O armazenamento Blob do Azure oferece durabilidade para dados de base de dados e também serve como armazenamento de dados para o arquivamento VAL. Os dados são armazenados em contas de armazenamento redundantes por zona. As cópias de segurança da base de dados são realizadas sob a forma de instantâneos dos blobs.

Preço

O Azure HorizonDB cobra atualmente por:

  • Capacidade de computação provisionada em horas de núcleo,
  • Armazenamento de base de dados usado (GB/mês), e
  • Usei armazenamento de backup durante o curto período de retenção.

Para mais detalhes sobre preços, consulte a página de preços

Limitações

Azure HorizonDB encontra-se atualmente em prévia. As seguintes funcionalidades ainda não estão disponíveis, estamos a trabalhar ativamente nelas.

Feature Status Notes
Retenção de cópias de segurança configurável Ainda não está disponível Atualmente, o período de retenção das cópias de segurança é de sete dias. Estamos a trabalhar para ativar a retenção de cópias de segurança de 1 a 35 dias
Réplicas de leitura entre regiões Ainda não está disponível A replicação entre regiões para recuperação de desastres ainda não é suportada.
Chaves geridas pelo cliente (CMK) para encriptação Não disponível A encriptação em repouso utiliza atualmente apenas chaves geridas pelo serviço.
Janelas de manutenção configuráveis Ainda não está disponível Atualmente, as atualizações ocorrem numa janela de manutenção gerida do sistema. Ainda não existe a possibilidade de configurar janelas de manutenção personalizadas
Agrupamento de Ligações (PgBouncer) Ainda não está disponível Pode ser utilizado um gestor externo de pools de ligações enquanto trabalhamos na gestão de pools de ligações no serviço.
Retenção a longo prazo (LTR) Não disponível Atualmente, o período de retenção das cópias de segurança é de sete dias.
Otimização de Índice Ainda não está disponível A otimização de índices estará disponível em breve.
Injeção de rede virtual Não disponível Atualmente, apoiamos o link privado. A integração com redes virtuais ainda não é suportada

Note

Esta lista reflete o estado atual do serviço e está sujeita a alterações à medida que forem lançadas novas capacidades. Consulte as notas de lançamento para as últimas atualizações.

Regiões do Azure

O Azure HorizonDB está atualmente disponível nas seguintes regiões do Azure:

Geography Regiões
Américas Canadá Central, Centro dos EUA, Leste dos EUA, Oeste dos EUA 2, Oeste dos EUA 3
Europa Alemanha Centro-Oeste, Suécia Central
Ásia-Pacífico Leste da Austrália

Note

A disponibilidade de regiões está sujeita a alterações e vamos adicionar mais regiões em breve. Algumas regiões podem ter restrições a novas implementações. Para a disponibilidade mais recente de regiões, consulte o portal Azure ou contacte o suporte do Azure.

Comentários e suporte

Se tiver dúvidas ou sugestões sobre o Azure HorizonDB, pode obter ajuda e apoio através dos seguintes canais:

Conteúdo relacionado

  • Last updated on