Partilhar via

Camada de serviço de hiperescala

  • Artigo

Aplica-se a: do Banco de Dados SQL do Azure

O Banco de Dados SQL do Azure é baseado na arquitetura do Mecanismo de Banco de Dados do SQL Server que é ajustada para o ambiente de nuvem para garantir alta disponibilidade mesmo em casos de falhas de infraestrutura. Há três opções de camada de serviço no modelo de compra vCore para o Banco de Dados SQL do Azure:

  • Finalidade Geral
  • Negócios Críticos
  • Hiperescala

A camada de serviço Hyperscale é adequada para todos os tipos de carga de trabalho. Sua arquitetura nativa da nuvem fornece computação e armazenamento escaláveis de forma independente para suportar a maior variedade de aplicativos tradicionais e modernos. Os recursos de computação e armazenamento em Hyperscale excedem substancialmente os recursos disponíveis nas camadas de uso geral e crítica para os negócios.

Para obter detalhes sobre as camadas de serviço "General Purpose" e "Business Critical" no modelo de compra baseado em vCore, consulte as camadas de serviço General Purpose e Business Critical. Para obter uma comparação do modelo de compra baseado em vCore com o modelo de compra baseado em DTU, consulte Comparar modelos de compra baseados em vCore e DTU do Banco de Dados SQL do Azure.

Atualmente, a camada de serviço Hyperscale está disponível apenas para o Banco de Dados SQL do Azure e não para a Instância Gerenciada SQL do Azure.

Quais são os recursos de hiperescala

A camada de serviço Hyperscale no Banco de Dados SQL do Azure fornece os seguintes recursos adicionais:

  • Escalonamento rápido - você pode, em tempo constante, escalar seus recursos de computação para acomodar cargas de trabalho pesadas quando necessário e, em seguida, dimensionar os recursos de computação novamente quando não for necessário.
  • Expansão rápida - pode provisionar uma ou mais réplicas somente leitura para aliviar a carga de trabalho de leitura e para uso como servidores de contingência.
  • Escalonamento, redução e cobrança automáticos para computação com base no uso com de computação sem servidor.
  • Preço/desempenho otimizado para um grupo de bancos de dados Hyperscale com demandas de recursos variáveis com pools elásticos .
  • Armazenamento de dimensionamento automático com suporte para até 128 TB de banco de dados ou pool elástico de 100 TB.
  • Maior desempenho geral devido à maior taxa de transferência do log de transações e tempos de confirmação de transações mais rápidos, independentemente dos volumes de dados.
  • Backups rápidos de banco de dados (com base em instantâneos de arquivos), independentemente do tamanho, sem impacto de E/S nos recursos de computação.
  • Restaurações ou cópias de bancos de dados rápidas (com base em instantâneos de arquivos) concluídas em minutos, em vez de horas ou dias.

A camada de serviço Hyperscale remove muitos dos limites práticos tradicionalmente vistos em bancos de dados em nuvem. Onde a maioria dos outros bancos de dados é limitada pelos recursos disponíveis em um único nó, os bancos de dados na camada de serviço Hyperscale não têm esses limites. Com sua arquitetura de armazenamento flexível, o armazenamento cresce conforme necessário. Na verdade, os bancos de dados Hyperscale não são criados com um tamanho máximo definido. Um banco de dados Hyperscale cresce conforme necessário - e você é cobrado apenas pela capacidade de armazenamento alocada. Para cargas de trabalho de leitura intensiva, a camada de serviço Hyperscale fornece escalabilidade horizontal rápida, provisionando réplicas adicionais, conforme necessário, para aliviar cargas de trabalho de leitura.

Além disso, o tempo necessário para criar backups de banco de dados ou para aumentar ou diminuir a escala não está mais vinculado ao volume de dados no banco de dados. O backup dos bancos de dados de hiperescala é praticamente instantâneo. Você também pode dimensionar um banco de dados em dezenas de terabytes para cima ou para baixo em poucos minutos na camada de computação provisionada ou usar sem servidor para dimensionar a computação automaticamente. Esta funcionalidade liberta-o de preocupações sobre ser limitado pelas suas escolhas iniciais de configuração.

Para obter mais informações sobre os tamanhos de computação para a camada de serviço Hyperscale, consulte Características da camada de serviço.

Quem deve considerar a camada de serviço Hyperscale

A camada de serviço Hyperscale destina-se a todos os clientes que precisam de maior desempenho e disponibilidade, backup e restauração rápidos e/ou escalabilidade rápida de armazenamento e computação. Isso inclui clientes que estão migrando para a nuvem para modernizar seus aplicativos e clientes que já estão usando outras camadas de serviço no Banco de Dados SQL do Azure. A camada de serviço Hyperscale suporta uma ampla gama de cargas de trabalho de banco de dados, de OLTP puro a análise pura. Ele é otimizado para OLTP e cargas de trabalho de transação híbrida e processamento analítico (HTAP).

Modelo de preços de hiperescala

Observação

Os preços simplificados para o Azure SQL Database Hyperscale chegaram! Reveja o novo escalão de preços para o anúncio de Hiperescala da Base de Dados SQL do Azuree, para obter detalhes sobre a alteração de preços, consulte Hiperescala da Base de Dados SQL do Azure – preços mais baixos e simplificados!.

A camada de serviço de hiperescala só está disponível no modelo de vCore . Para se alinhar com a nova arquitetura, o modelo de preços é ligeiramente diferente dos níveis de serviço de uso geral ou críticos para os negócios:

  • Computação provisionada:

    O preço da unidade de computação Hyperscale é por réplica. Os usuários podem ajustar o número total de réplicas secundárias de alta disponibilidade de 0 a 4, dependendo dos requisitos de disponibilidade e escalabilidade, e criar até 30 réplicas nomeadas para dar suporte a várias cargas de trabalho de expansão de leitura.

  • Computação sem servidor:

    A cobrança de computação sem servidor é baseada no uso. Para obter mais informações, consulte camada de computação sem servidor para o Banco de Dados SQL do Azure.

  • Armazenamento:

    Não é necessário especificar o tamanho máximo de dados ao configurar um banco de dados Hyperscale. Na camada Hyperscale, você é cobrado pelo armazenamento do banco de dados com base na alocação real. O armazenamento é alocado automaticamente entre 10 GB e 128 TB e cresce em incrementos de 10 GB conforme necessário.

Para obter mais informações sobre preços de hiperescala, consulte preços do Banco de Dados SQL do Azure.

Arquitetura de funções distribuídas

O Hyperscale separa o mecanismo de processamento de consultas dos componentes que fornecem armazenamento de longo prazo e durabilidade para os dados. Essa arquitetura permite dimensionar suavemente a capacidade de armazenamento até onde for necessário (até 128 TB) e a capacidade de dimensionar recursos de computação rapidamente.

O diagrama a seguir ilustra a arquitetura funcional de hiperescala:

Diagrama mostrando a arquitetura Hyperscale.

Saiba mais sobre a arquitetura de funções distribuídas Hyperscale.

Vantagens de escala e desempenho

Com a capacidade de aumentar/reduzir rapidamente nós de computação adicionais de leitura, a arquitetura Hyperscale permite capacidades significativas de escala de leitura e também pode disponibilizar o nó de computação primário para atender mais solicitações de gravação. Além disso, os nós de computação podem ser dimensionados para cima/para baixo rapidamente devido à arquitetura de armazenamento compartilhado da arquitetura Hyperscale. Os nós de computação somente leitura no Hyperscale também estão disponíveis na camada sem servidor de computação , que ajusta automaticamente a computação com base na demanda de carga de trabalho.

Alta disponibilidade do banco de dados em Hyperscale

Como em todas as outras camadas de serviço, o Hyperscale garante a durabilidade dos dados para transações confirmadas, independentemente da disponibilidade da réplica de computação. A extensão do tempo de inatividade devido à indisponibilidade da réplica principal depende do tipo de failover (planejado versus não planejado), se a redundância de zona está configuradae da presença de pelo menos uma réplica de alta disponibilidade. Em uma transferência planejada (como um evento de manutenção), o sistema ou cria a nova réplica primária antes de iniciar a transferência, ou utiliza uma réplica de alta disponibilidade existente como alvo da transferência. Em um failover não planejado (como uma falha de hardware na réplica primária), o sistema usa uma réplica de alta disponibilidade como destino de failover, se existir, ou cria uma nova réplica primária a partir do pool de capacidade de computação disponível. Neste último caso, a duração do tempo de inatividade é maior devido às etapas adicionais necessárias para criar a nova réplica primária.

Você pode escolher uma janela de manutenção que permita tornar os eventos de manutenção impactantes previsíveis e menos perturbadores para sua carga de trabalho.

Para o SLA de Hiperescala, consulte o SLA para o Banco de Dados SQL do Azure.

Pool de buffers, extensão resiliente do buffer pool e preparação contínua

No Azure Database Hyperscale, há uma separação distinta entre computação e armazenamento. O armazenamento contém todas as páginas do banco de dados em um banco de dados e pode ser alocado em várias máquinas à medida que o banco de dados cresce. O nó de computação, no entanto, armazena em cache apenas o que está sendo usado recentemente. As páginas mais quentes na computação são mantidas na memória em uma estrutura chamada buffer pool (BP). Ele também é armazenado no SSD local, a extensão resiliente do pool de buffers (RBPEX), para que os dados possam ser recuperados mais rapidamente caso o processo de computação seja reiniciado.

Em um sistema de nuvem, a computação pode ser movida para máquinas diferentes, conforme necessário. A camada de computação pode ter várias réplicas. Um é primário e recebe todas as atualizações, enquanto outros são réplicas secundárias. No caso de uma falha primária, uma das réplicas secundárias de alta disponibilidade pode ser rapidamente promovida para primária em um processo chamado failover. A réplica secundária pode não ter um cache em seu BP e RBPEX otimizado para a carga de trabalho principal.

A inicialização contínua é um processo que coleta informações sobre quais páginas são as mais acessadas em todas as réplicas de computação. Essas informações são agregadas e as réplicas secundárias de alta disponibilidade utilizam a lista das páginas mais acessadas, que correspondem à carga de trabalho típica dos clientes. Isso preenche tanto a BP quanto a RBPEX com as páginas mais consultadas, continuamente, para acompanhar as mudanças na carga de trabalho dos clientes.

Sem preparação contínua, tanto o BP quanto o RBPEX não são herdados por novas réplicas de alta disponibilidade e só são reconstruídos durante a carga de trabalho do usuário. A preparação contínua economiza tempo e evita desempenhos inconsistentes, pois não há espera para que os caches sejam totalmente hidratados novamente. Com o priming contínuo, novas réplicas secundárias de alta disponibilidade começarão imediatamente a preparar seu BP e RBPEX. Isso ajudará a manter o desempenho de forma mais consistente à medida que os failovers acontecem.

A preparação contínua funciona nos dois sentidos: as réplicas secundárias de alta disponibilidade armazenarão em cache as páginas que estão sendo usadas na réplica primária e as primárias armazenarão em cache as páginas com a carga de trabalho das réplicas secundárias.

Observação

A preparação contínua está atualmente em uma visualização fechada e não está disponível para bancos de dados sem servidor. Para obter mais informações e optar pela preparação contínua, consulte Blog: Aprimoramentos de hiperescala de novembro de 2024.

Backup e restauração

As operações de backup e restauração para bancos de dados Hyperscale são baseadas em instantâneo de ficheiro. Isso permite que essas operações sejam quase instantâneas. Como a arquitetura Hyperscale utiliza a camada de armazenamento para backup e restauração, a carga de processamento e o impacto no desempenho das réplicas de computação são reduzidos. Saiba mais em backups em hiperescala e redundância de armazenamento.

Recuperação de desastres para bancos de dados Hyperscale

Caso precise restaurar um banco de dados Hyperscale no Banco de Dados SQL do Azure para uma região diferente daquela onde está atualmente hospedado, como parte de uma operação de recuperação de desastres, simulação, realocação ou qualquer outro motivo, o método principal é realizar uma restauração geográfica do banco de dados. A restauração geográfica só está disponível quando o armazenamento com redundância geográfica (RA-GRS) foi escolhido para redundância de armazenamento.

Saiba mais em como restaurar um banco de dados Hyperscale para uma região diferente.

Comparar limites de recursos

Os níveis de serviço baseados em vCore são diferenciados com base na disponibilidade do banco de dados, no tipo de armazenamento, no desempenho e no tamanho máximo do armazenamento. Essas diferenças são descritas na tabela a seguir:

ㅤ Uso Geral Essencial para os Negócios de hiperescala
Melhor para Oferece opções de computação e armazenamento equilibradas orientadas para o orçamento. Aplicações OLTP com alta taxa de transação e baixa latência de E/S. Oferece alta resiliência a falhas e failovers rápidos usando várias réplicas em espera ativa. A maior variedade de cargas de trabalho. Dimensionamento automático do tamanho de armazenamento de até 128 TB, rápido dimensionamento de computação vertical e horizontal, restauração rápida do banco de dados.
Tamanho de computação 2 a 128 vCores 2 a 128 vCores 2 a 128 vCores
Tipo de armazenamento Armazenamento remoto premium (por instância) Armazenamento SSD local muito rápido (por cada instância) Armazenamento desacoplado com cache de SSD local (para cada réplica de computação)
Tamanho de armazenamento 1 GB – 4 TB 1 GB – 4 TB 10 GB – 128 TB
IOPS 320 IOPS por vCore com 16.000 IOPS máximas 4.000 IOPS por vCore com 327.680 IOPS máximas 327.680 IOPS com SSD local máximo
A hiperescala é uma arquitetura multicamadas com cache em vários níveis. IOPS eficaz depende da carga de trabalho.
Memória/vCore 5,1 GB 5,1 GB 5,1 GB ou 10,2 GB
disponibilidade Uma réplica, sem expansão de leitura, HA com redundância de zona Três réplicas, uma expansão horizontal de leitura, alta disponibilidade com redundância de zona Várias réplicas, até quatro leituras escalonadas, HA com redundância de zona
Cópias de Segurança Uma opção de armazenamento com redundância local (LRS), com redundância de zona (ZRS) ou com redundância geográfica (GRS)
Retenção de 1 a 35 dias (sete dias por padrão), com até 10 anos de retenção de longo prazo disponíveis		 Uma opção de armazenamento com redundância local (LRS), com redundância de zona (ZRS) ou com redundância geográfica (GRS)
Retenção de 1 a 35 dias (sete dias por padrão), com até 10 anos de retenção de longo prazo disponíveis		 Uma opção de armazenamento com redundância local (LRS), com redundância de zona (ZRS) ou com redundância geográfica (GRS)
Retenção de 1 a 35 dias (sete dias por padrão), com até 10 anos de retenção de longo prazo disponíveis
Preços e faturação vCore, armazenamento reservado e armazenamento de backup são cobrados.
As IOPS não são cobradas.		 vCore, armazenamento reservado e armazenamento de backup são cobrados.
As IOPS não são cobradas.		 vCore para cada réplica, armazenamento de dados alocado e armazenamento de backup são cobrados.
As IOPS não são cobradas.
Modelos com desconto1 Instâncias reservadas
Benefício Híbrido do Azure2
Enterprise e oferta Pay-As-You-Go Dev/Test subscrições		 Instâncias reservadas
Benefício Híbrido do Azure2
Enterprise e oferta Pay-As-You-Go Dev/Test subscrições		 Instâncias reservadas
Benefício Híbrido do Azure2
Enterprise e oferta Pay-As-You-Go Dev/Test subscrições

1 A estrutura de preços simplificada para o SQL Database Hyperscale chegou em dezembro de 2023. Consulte o blog de preços do Hyperscale para obter detalhes.

2 A partir de dezembro de 2023, o Benefício Híbrido do Azure não estará disponível para novos bancos de dados Hyperscale ou em assinaturas de desenvolvimento/teste. Os bancos de dados únicos Hyperscale existentes com computação provisionada podem continuar a usar o Benefício Híbrido do Azure para economizar em custos de computação até dezembro de 2026. Para obter mais informações, consulte o blog de preços do Hyperscale.

Recursos computacionais

Configuração de hardware CPU Memória
Série padrão (Gen5) Computação provisionada
- Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)1, Intel® 8272CL (Cascade Lake) 2,5 GHz1, Intel® Xeon® Platinum 8370C (Ice Lake)1, processadores AMD EPYC 7763v (Milão)
- Provisão de até 80 vCores (hyper-threaded)

Computação sem servidor
- Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)1, Intel® 8272CL (Cascade Lake) 2,5 GHz1, Intel® Xeon® Platinum 8370C (Ice Lake)1, processadores AMD EPYC 7763v (Milão)
- Autoescala até 80 vCores (hiper-fios)
- A relação memória/vCore adapta-se dinamicamente à memória e ao uso da CPU com base na demanda de carga de trabalho e pode chegar a 24 GB por vCore. Por exemplo, em um determinado momento, uma carga de trabalho pode usar e ser cobrada por 240 GB de memória e apenas 10 vCores.		 [] Computação Provisionada []
- 5,1 GB por vCore
- Provisionamento de até 625 GB

Computação sem servidor
- Dimensionamento automático de até 24 GB por vCore
- Dimensionamento automático até 240 GB no máximo
Série Premium - Processadores Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC 7763v (Milão)
- Provisão de até 128 vCores (hyper-threaded)		 - 5,1 GB por vCore
Memória de série premium otimizada - Processadores Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC 7763v (Milão)
- Provisão de até 80 vCores (hyper-threaded)		 - 10,2 GB por vCore

1 Na visualização sys.dm_user_db_resource_governance gerenciamento dinâmico, a geração de hardware para bancos de dados usando processadores Intel® SP-8160 (Skylake) aparece como Gen6, a geração de hardware para bancos de dados usando Intel® 8272CL (Cascade Lake) aparece como Gen7 e a geração de hardware para bancos de dados usando Intel® Xeon® Platinum 8370C (Ice Lake) ou AMD® EPYC® 7763v (Milão) aparece como Gen8. Para um determinado tamanho de computação e configuração de hardware, os limites de recursos são os mesmos, independentemente do tipo de CPU. Para mais informações, consulte os limites de recursos para bancos de dados únicos e pools elásticos.

O Serverless só é suportado em hardware da série Standard (Gen5).

Criar e gerenciar bancos de dados Hyperscale

Você pode criar e gerenciar bancos de dados Hyperscale usando o portal do Azure, Transact-SQL, PowerShell e a CLI do Azure. Para obter mais informações, consulte Guia de início rápido : criar um banco de dados de hiperescala.

Operação Detalhes Saiba mais
Criar um banco de dados Hyperscale As bases de dados de hiperescala estão disponíveis somente usando o modelo de aquisição baseado em vCore . Encontre exemplos para criar um banco de dados Hyperscale em Guia de início rápido: criar um banco de dados Hyperscale no Banco de Dados SQL do Azure.
Atualizar um banco de dados existente para o Hyperscale A migração de um banco de dados existente no Azure SQL Database para a camada Hyperscale é uma operação relacionada ao tamanho dos dados. Saiba como migrar um banco de dados existente para o Hyperscale.
Reverter a migração de um banco de dados Hyperscale para a camada de serviço de uso geral Se você migrou anteriormente um Banco de Dados SQL do Azure existente para a camada de serviço Hyperscale, poderá reverter a migração do banco de dados para a camada de serviço de Propósito Geral dentro de 45 dias da migração original para Hyperscale.

Se desejar migrar o banco de dados para outra camada de serviço, como Business Critical, primeiro faça a migração reversa para a camada de serviço de uso geral e, em seguida, altere a camada de serviço.		 Saiba como reverter a migração do Hyperscale, incluindo as limitações de para migração reversa.

Limitações

Estas são as limitações atuais da camada de serviço Hyperscale. Estamos trabalhando ativamente para remover o maior número possível dessas limitações.

Questão Descrição
A redução é bloqueada quando a TDE está desativada Atualmente, as operações de redução de banco de dados e arquivo não são suportadas quando a Criptografia de Dados Transparente (TDE) está desabilitada no Hiperdimensionamento do Banco de Dados SQL do Azure.
Restaurar banco de dados de outras camadas de serviço Um banco de dados não Hyperscale não pode ser restaurado como um banco de dados Hyperscale e um banco de dados Hyperscale não pode ser restaurado como um banco de dados não-Hyperscale.

Para bancos de dados migrados para o Hyperscale de outras camadas de serviço do Banco de Dados SQL do Azure, os backups de pré-migração são mantidos durante período de retenção de backup do banco de dados de origem, incluindo políticas de retenção de longo prazo. A restauração de um backup de pré-migração dentro do período de retenção de backup do banco de dados é suportada por meio da linha de comando. Você pode restaurar esses backups para qualquer camada de serviço que não seja de hiperescala.
Migração de bases de dados contendo objetos OLTP In-Memory O Hyperscale suporta um subconjunto de In-Memory objetos OLTP, incluindo tipos de tabela com otimização de memória, variáveis de tabela e módulos compilados nativamente. No entanto, quando quaisquer objetos OLTP In-Memory estão presentes no banco de dados que está a ser migrado, a migração das camadas de serviço Premium e Business Critical para Hyperscale não é suportada. Para migrar esse banco de dados para o Hyperscale, todos os objetos OLTP In-Memory e suas dependências devem ser descartados. Depois que o banco de dados é migrado, esses objetos podem ser recriados. Tabelas com otimização de memória durável e não durável não são suportadas atualmente no Hyperscale e devem ser alteradas para tabelas de disco.
Verificação da integridade do banco de dados DBCC CHECKDB não é suportado atualmente para bancos de dados Hyperscale. DBCC CHECKTABLE ('TableName') WITH TABLOCK e DBCC CHECKFILEGROUP WITH TABLOCK podem ser usados como uma solução alternativa. Consulte Integridade de Dados no Banco de Dados SQL do Azure para obter detalhes sobre o gerenciamento de integridade de dados no Banco de Dados SQL do Azure.
Trabalhos elásticos Não há suporte para o uso de um banco de dados Hyperscale como o banco de dados Job. No entanto, os trabalhos elásticos podem direcionar bancos de dados Hyperscale da mesma maneira que qualquer outro banco de dados no Banco de Dados SQL do Azure.
Sincronização de dados Não há suporte para o uso de um banco de dados Hyperscale como um banco de dados de metadados de hub ou de sincronização. No entanto, um banco de dados Hyperscale pode ser um banco de dados membro em uma topologia de Sincronização de Dados.
Hardware da série premium da camada de serviço de hiperescala Atualmente, o hardware da série premium e otimizado para memória não suporta a camada de computação sem servidor.
Disponibilidade regional O hardware otimizado para memória da série premium e da camada de serviço de hiperescala está disponível em regiões limitadas do Azure. Para uma lista, consulte a disponibilidade da série premium Hyperscale em .

Conteúdo relacionado