Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Azure HorizonDB é um serviço de banco de dados totalmente gerenciado e pronto para IA na nuvem criado no PostgreSQL. Ele combina uma arquitetura de computação e armazenamento desagregada com um design de banco de dados como um log para fornecer desempenho previsível, segurança de nível empresarial, alta disponibilidade e escalabilidade perfeita para cargas de trabalho críticas.
Azure HorizonDB capacita os desenvolvedores a criar aplicativos inteligentes e alimentados por IA por meio do suporte nativo para inserções vetoriais e integração com Fábrica de IA do Azure Tools, mantendo a compatibilidade completa do PostgreSQL para que os aplicativos existentes possam migrar facilmente para Azure HorizonDB.
casos de uso do Azure HorizonDB
Azure HorizonDB é uma alternativa escalonável nativa à nuvem para PostgreSQL autogerenciado e foi projetado para cargas de trabalho críticas não limitadas, mas incluindo:
- Cargas de trabalho transacionais (OLTP) – processamento de transações de alta taxa de transferência e baixa latência com desempenho previsível para aplicativos de linha de negócios, plataformas de comércio eletrônico e back-ends de SaaS.
- IA e aplicativos inteligentes - A busca vetorial nativa e o suporte a embeddings permitem criar pipelines de geração aumentada por recuperação (RAG), mecanismos de recomendação e busca semântica diretamente na camada do banco de dados. O gerenciamento de modelos de IA e os pipelines de IA simplificam ainda mais a criação de aplicativos inteligentes no banco de dados.
- Expansão de leitura massiva – Aplicativos que podem usufruir a expansão de leitura com dados resilientes entre zonas compartilhadas.
- Aplicativos híbridos - Integração com o ecossistema do Azure, espelhamento de dados transacionais para o OneLake do Fabric, integrando-os a outros dados analíticos.
Arquitetura do Azure HorizonDB
O Azure HorizonDB baseia-se em dois princípios arquitetônicos fundamentais: separação de processamento e armazenamento, e uma arquitetura de banco de dados baseada em log.
Computação e armazenamento desagregados
A arquitetura separa totalmente a camada de computação da camada de armazenamento:
- Compute layer - A computação no Azure HorizonDB é sem estado. Os recursos de computação (vCores e memória) podem ser dimensionados independentemente sem afetar o armazenamento e vice-versa. Você pode dimensionar horizontalmente as leituras adicionando réplicas ao cluster HorizonDB.
- Storage layer - A camada de armazenamento usa duas frotas de armazenamento criadas com finalidade: uma dedicada ao WAL, outra aos dados; ambos têm durabilidade apoiada pelo armazenamento Azure. Todo o armazenamento é resiliente à zona por padrão. O armazenamento é dimensionado automaticamente à medida que os dados aumentam, independentemente da camada de computação provisionada.
A separação de computação e armazenamento oferece vários benefícios:
- Dimensione a computação e o armazenamento de forma independente com base nas demandas de carga de trabalho.
- Provisionamento rápido de réplicas de leitura, pois elas compartilham o mesmo armazenamento subjacente e nenhuma replicação de dados é necessária.
- Failover mais rápido para alta disponibilidade, já que o armazenamento WAL durável compartilhado e elimina a necessidade de rebobinar logs.
Arquitetura do banco de dados como um log
O Azure HorizonDB adota uma arquitetura em que o banco de dados funciona como um log, na qual somente o WAL (log de escrita antecipada) é gravado da camada de computação para a camada de armazenamento. As páginas de dados não são gravadas a partir das réplicas de computação para a camada de armazenamento. WAL é a fonte única da verdade em todo o sistema.
- Todas as gravações (log write ahead) são anexadas a um serviço de log durável antes de serem confirmadas para o cliente. O serviço WAL é otimizado para semântica de um log de transações e otimizado para baixa latência.
- O WAL filtrado é enviado apenas para os nós de armazenamento aos quais as alterações pertencem.
- Os nós de armazenamento reconstroem o estado da página aplicando o WAL, eliminando gargalos de E/S do ponto de verificação tradicionais.
- Essa abordagem reduz a amplificação de gravação e fornece latência de gravação consistente e previsível, independentemente do tamanho do banco de dados.
A combinação desses dois princípios permite que o Azure HorizonDB ofereça alta taxa de transferência, baixa latência e utilização eficiente de recursos, mantendo garantias ACID completas.
Aglomerado
Um recurso Azure HorizonDB provisionado é um cluster. Um cluster Azure HorizonDB tem:
- Uma ou mais réplicas de computação, sendo uma delas uma primária gravável e as demais réplicas em espera legíveis.
- Uma única cópia dos dados em armazenamento com resiliência de zona compartilhada entre todas as réplicas do cluster.
- Um ponto de extremidade de leitura/gravação que sempre aponta para a réplica primária.
- Um ponto de extremidade somente leitura que faz o balanceamento de carga das conexões com todas as réplicas legíveis.
Réplicas computacionais
Uma réplica de computação do Azure HorizonDB pode ser a primária (gravável) ou uma réplica em espera que seja legível, além de ser uma candidata para failover. A réplica de computação é onde o mecanismo relacional PostgreSQL permanece e onde ocorre o processamento de idioma, consulta e transação. Todas as interações com o cluster Azure HorizonDB ocorrem por meio das réplicas de computação. Para ter resiliência zonal, você precisa de pelo menos duas réplicas no cluster. Você pode adicionar ou remover réplicas ao cluster Azure HorizonDB conforme sua carga de trabalho precisa.
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 têm um cache local em SSD. Esse cache é um cache NVMe de baixa latência que armazena em cache páginas quentes e minimiza a necessidade de buscar dados da camada de armazenamento remoto. O cache está presente em todas as réplicas, na primária e na réplica em espera.
As réplicas de computação são utilizadas de forma eficiente, pois transferem para a camada de armazenamento as tarefas de durabilidade e alta disponibilidade. Esse descarregamento fornece mais CPU, disco e rede para executar a lógica de negócios de aplicativos no banco de dados. As tarefas a seguir são transferidas das réplicas de computação para a camada de armazenamento.
| Tarefa | Processo postgreSQL | Economia de recursos |
|---|---|---|
| Envio de WAL a partir de réplicas | walsender | E/S de disco, E/S de rede |
| Arquivamento de WAL para armazenamento de blobs | Arquivador | E/S de disco, E/S de rede |
| Gravação em página suja | gravador em segundo plano | E/S de disco |
| Definindo o ponto de verificação | ponto de verificação | E/S de disco |
| Backups | pg_dump, pg_basebackup, pg_backup_start, pg_backup_stop | E/S de disco |
| Gravações em página completa | Back-ends gravando em WAL | E/S de disco |
| Recuperação do WAL do PostgreSQL | recuperação de inicialização | E/S de disco |
| Refazer réplica de leitura do PostgreSQL | recuperação de inicialização | E/S de disco |
Armazenamento
Azure HorizonDB executa duas frotas de armazenamento apoiadas pelo armazenamento de blobs Azure. Todas as camadas da pilha de armazenamento são resilientes à zona por padrão.
Armazenamento WAL
O serviço WAL é um serviço projetado especificamente para aceitar WAL da réplica de computação primária e é otimizado para baixa latência e para padrões de gravação WAL. Quando uma alteração de dados (inserir/atualizar/excluir) é feita na réplica primária, WAL é gravado no serviço WAL e a transação é confirmada. O WAL é aplicado de forma assíncrona aos respectivos fragmentos de dados na frota de armazenamento de dados para aplicar as alterações mais recentes. Além disso, WAL é enviado para réplicas de computação secundárias a fim de refazer alterações nas páginas que estejam em memória nas 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 funciona como um cache de todos os dados do banco de dados e fornece dados para todas as réplicas de computação no cluster Azure HorizonDB. O armazenamento é alocado dinamicamente à medida que o banco de dados cresce sem a necessidade de configurar o tamanho do armazenamento ou o IOPS. Os dados dos relacionamentos postgres são fragmentados entre vários nós de armazenamento do ambiente para proporcionar mais escalabilidade. Há várias cópias do mesmo fragmento de dados armazenados entre zonas para resiliência. À medida que o WAL é reaplicado na camada de armazenamento, as páginas sujas dessa camada acabam sendo gravadas no Armazenamento de Blobs do Azure.
Armazenamento de Blobs do Azure
O Armazenamento de Blobs do Azure oferece durabilidade para dados do banco de dados e também serve como o repositório de dados para arquivamento de WAL. Os dados são armazenados em contas de armazenamento com redundância de zona. Os backups de banco de dados são implementados como instantâneos dos blobs.
Preço
Azure HorizonDB atualmente cobra por:
- Computação provisionada em horas principais,
- Armazenamento de banco de dados usado (GB/mês) e
- Armazenamento de backup usado no período de retenção em curto prazo.
Para obter mais detalhes sobre preços, exiba a página de preços
Limitações
Azure HorizonDB está atualmente em preview. Os recursos a seguir ainda não estão disponíveis. Estamos trabalhando ativamente nesses recursos.
| Característica | Status | Observações |
|---|---|---|
| Retenção de backup configurável | Ainda não disponível | Atualmente, a retenção de backup é de sete dias. Estamos trabalhando para habilitar a retenção de backup de 1 a 35 dias |
| Réplicas de leitura entre regiões | Ainda não disponível | A replicação entre regiões para recuperação de desastre ainda não tem suporte. |
| CMK (chaves gerenciadas pelo cliente) para criptografia | Não disponível | A criptografia em repouso atualmente usa somente chaves gerenciadas pelo serviço. |
| Janelas de manutenção configuráveis | Ainda não disponível | Atualmente, as atualizações ocorrem em uma janela de manutenção gerenciada pelo sistema. A capacidade de configurar janelas de manutenção personalizada ainda não está disponível |
| Pool de conexões (PgBouncer) | Ainda não disponível | Um gerenciador externo de pool de conexões pode ser usado enquanto implementamos o pool de conexões no serviço. |
| LTR (retenção de longo prazo) | Não disponível | Atualmente, a retenção de backup é de sete dias. |
| Ajuste de índice | Ainda não disponível | O ajuste de índices estará disponível em breve. |
| Injeção da rede virtual | Não disponível | Atualmente, há suporte para link privado. A integração de rede virtual ainda não tem suporte |
Note
Essa lista reflete o estado atual do serviço e está sujeita a alterações à medida que novos recursos são lançados. Verifique as notas da versão para conferir as atualizações mais recentes.
Regiões do Azure
Azure HorizonDB está disponível atualmente nas seguintes regiões de Azure:
| Geography | Regions |
|---|---|
| Américas | Canadá Central, Eua Central, Leste dos EUA, Oeste dos EUA 2, Oeste dos EUA 3 |
| Europa | Centro-Oeste da Alemanha, Suécia Central |
| Pacífico Asiático | Leste da Austrália |
Note
A disponibilidade da região está sujeita a alterações e adicionaremos mais regiões em breve. Algumas regiões podem ter restrições em novas implantações. Para obter a disponibilidade da região mais recente, consulte o portal Azure ou entre em contato com Suporte do Azure.
Feedback e suporte
Se você tiver perguntas ou sugestões sobre Azure HorizonDB, poderá obter ajuda e suporte por meio dos seguintes canais:
- Para entrar em contato com o Suporte do Azure, abra um chamado no portal do Azure.
- Para corrigir um problema com sua conta, apresente uma solicitação de suporte no portal do Azure.
- Para fornecer comentários ou solicitar novos recursos, crie uma entrada por meio do UserVoice.