Tipo de serviço de Hiperescala

  • Artigo

Aplica-se a: Banco de Dados SQL do Azure

Banco de dados SQL do Azure baseia-se na arquitetura de mecanismo de banco de dados do SQL Server que é ajustada para o ambiente de nuvem para garantir alta disponibilidade, até mesmo no caso 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:

  • Uso Geral
  • Comercialmente Crítico
  • Hiperescala

A camada de serviço Hiperescala é adequada para todos os tipos de carga de trabalho. A arquitetura nativa de nuvem fornece computação e armazenamento escalonáveis independentemente para dar suporte à maior variedade de aplicações tradicionais e modernas. Os recursos de computação e armazenamento na Hiperescala excedem substancialmente os recursos disponíveis nas camadas Uso Geral e Comercialmente Crítico.

Para obter detalhes sobre as camadas de serviço de Uso Geral e Comercialmente Crítica no modelo de compra baseado em vCore, confira Camadas de serviço de Uso Geral e Comercialmente Crítico. Para obter uma comparação do modelo de compra baseado em vCore com o modelo de compra baseado em DTU, confira Compare modelos de compra baseados em DTU e vCore de Banco de Dados SQL do Azure.

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

Quais são as funcionalidades de Hiperescala

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

  • Escala vertical rápida: você pode, de forma contínua, escalar verticalmente seus recursos de computação para acomodar cargas de trabalho pesadas conforme a necessidade e, depois, diminuir os recursos computacionais novamente quando não for mais necessário.
  • Escala horizontal rápida – você pode provisionar uma ou mais réplicas somente leitura para descarregar sua carga de trabalho de leitura e usar como esperas ativas.
  • Cobrança, escalonamento e redução vertical automáticos para computação com base no uso com computação sem servidor.
  • Preço/desempenho otimizado para um grupo de bancos de dados de Hiperescala com diferentes demandas de recursos com pools elásticos.
  • Armazenamento de dimensionamento automático com suporte para até 128 TB de banco de dados ou 100 TB de tamanho de pool elástico.
  • Maior desempenho geral devido à maior taxa de transferência de log e tempos mais rápidos de confirmação de transação, independentemente dos volumes de dados.
  • Backups de banco de dados rápidos (com base em instantâneos de arquivo), independente do tamanho e sem nenhum impacto de E/S sobre os recursos computacionais.
  • Cópias ou restaurações de banco de dados (com base em instantâneos de arquivo) rápidas em minutos, em vez de horas ou dias.

A camada de serviço da Hiperescala elimina muitos dos limites práticos vistos tradicionalmente em bancos de dados de nuvem. Onde mais outros bancos de dados são limitados pelos recursos disponíveis em um único nó, bancos de dados na camada de serviço da Hiperescala não têm esses limites. Com sua arquitetura de armazenamento flexível, o armazenamento aumenta conforme necessário. Na realidade, os bancos de dados de Hiperescala não são criados com um tamanho máximo definido. Um banco de dados de Hiperescala aumenta conforme necessário, e você será cobrado apenas pela capacidade de armazenamento alocada. Para cargas de trabalho que fazem uso intenso de leitura, a camada de serviço Hiperescala oferece uma rápida expansão por meio do provisionamento de leitura de réplicas adicionais conforme necessário para descarregar 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. Bancos de dados de Hiperescala são armazenados virtualmente instantaneamente. Você também pode aumentar ou reduzir um banco de dados em dezenas de terabytes em minutos na camada de computação provisionada ou usar serverless para escalar a computação automaticamente. Esse recurso libera você das preocupações sobre ser encaixotado pelas opções iniciais de configuração.

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

Quem deve considerar a camada de serviço da Hiperescala

A camada de serviço de Hiperescala destina-se a todos os clientes que exigem maior desempenho e disponibilidade, backup e restauração rápidos e/ou escalabilidade de computação e armazenamento rápidos. Isso inclui clientes que estão migrando para a nuvem para modernizar os 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 de Hiperescala dá suporte a uma ampla variedade de cargas de trabalho de banco de dados, desde OLTP puro até análise pura. Ela é otimizada para cargas de trabalho de OLTP e HTAP (transações híbridas e processamento analítico).

Modelo de preços de Hiperescala

Observação

Os preços simplificados de Hiperescala do Banco de Dados SQL do Azure chegaram! Acesse o anúncio do novo tipo de preços para Hiperescala Banco de Dados SQL do Azure e, para obter detalhes sobre alterações de preços, consulte Hiperescala do Banco de Dados SQL do Azure – preços mais baixos e simplificados!.

A camada de serviço em Hiperescala só está disponível no modelo vCore. Para alinhar-se com a nova arquitetura, o modelo de preços é ligeiramente diferente de camadas de serviço de Uso Geral ou Comercialmente Críticas:

  • Computação provisionada:

    O preço de unidade de computação em Hiperescala é por réplica. Os usuários podem ajustar o número total de réplicas secundárias de alta disponibilidade de 0 para 4, dependendo dos requisitos de disponibilidade e escalabilidade, e criar até 30 réplicas nomeadas para dar suporte a diversas 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, confira Camada de computação sem servidor para Banco de Dados SQL do Azure.

  • Armazenamento:

    Você não precisa especificar o tamanho máximo de dados ao configurar um banco de dados da Hiperescala. Na camada de Hiperescala, você é cobrado pelo armazenamento do seu banco de dados de acordo com a 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 os preços da Hiperescala, confira Preços do Banco de Dados SQL do Azure.

Arquitetura de funções distribuídas

A Hiperescala separa o mecanismo de processamento de consulta dos componentes que fornecem armazenamento de longo prazo e durabilidade para os dados. Essa arquitetura permite que você dimensione suavemente a capacidade de armazenamento conforme necessário (até 128 TB) e dimensione recursos de computação rapidamente.

O diagrama a seguir ilustra a arquitetura funcional da Hiperescala:

Diagrama mostrando a arquitetura hiperescala.

Saiba mais sobre a Arquitetura de funções distribuídas de Hiperescala.

Vantagens de desempenho e escala

Com a capacidade de criar rapidamente nós de computação adicionais de somente leitura para cima/para baixo, a arquitetura permite significativa ler recursos de escala e Hiperescala também pode liberar o nó de computação principal para atender às solicitações de gravação mais. Além disso, os nós de computação podem ser dimensionados para cima/para baixo rapidamente devido à arquitetura de armazenamento compartilhado da arquitetura da Hiperescala. Nós de computação somente leitura na Hiperescala também estão disponíveis na camada de computação sem servidor, que escala automaticamente a computação com base na demanda de carga de trabalho.

Alta disponibilidade de banco de dados em Hiperescala

Como em todas as outras camadas de serviço, a Hiperescala garante a durabilidade dos dados para transações confirmadas, independentemente da disponibilidade da réplica de computação. A duração do tempo de inatividade causado pela não disponibilidade da réplica primária depende do tipo de failover (planejado ou não planejado), da configuração ou não da redundância de zona e da presença de pelo menos uma réplica de alta disponibilidade. Em um failover planejado (como um evento de manutenção), o sistema cria a nova réplica primária antes de iniciar um failover ou usa uma réplica de alta disponibilidade existente como meta de failover. 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 uma meta de failover (se houver) ou cria uma réplica primária com base no pool de capacidade de computação disponível. No último caso, a duração do tempo de inatividade é mais longa devido às etapas adicionais necessárias para criar a nova réplica primária.

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

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

Conjunto de buffer, extensão de conjunto de buffer resiliente e preparação contínua

No Azure Database Hiperescala, há uma separação distinta entre computação e armazenamento. O armazenamento contém todas as páginas do banco de dados em um único banco de dados e pode ser alocado em várias máquinas conforme 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 populares 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 do pool de buffer resiliente (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. Uma é primária e recebe todas as atualizações, enquanto outras 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 a 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 primária.

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

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ó podem ser reconstruídos durante a carga de trabalho do usuário. A preparação contínua economiza tempo e evita desempenho inconsistente, pois não há espera até que os caches sejam totalmente hidratados novamente. Com a preparação contínua, 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 ocorrem failovers.

A preparação contínua funciona nos dois sentidos: 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 a primária armazenará 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 versão prévia restrita e não está disponível para bancos de dados sem servidor. Para obter mais informações e optar pela preparação contínua, veja Blog: Melhorias em hiperescala de novembro de 2024.

Fazer backup e restaurar

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

Recuperação de desastre para bancos de dados de Hiperescala

Se você precisar restaurar um banco de dados de Hiperescala no Banco de Dados SQL do Azure para uma região que não seja a que está hospedada no momento, como parte de uma operação de recuperação de desastres ou simulação, realocação ou qualquer outro motivo, o método principal é fazer uma restauração geográfica do banco de dados. A restauração geográfica só estará disponível quando o RA-GRS (armazenamento com redundância geográfica) tiver sido escolhido para redundância de armazenamento.

Saiba mais em Restauração de um banco de dados de Hiperescala para uma região diferente.

Comparar os limites de recursos

As camadas de serviço baseadas em vCore são diferenciadas de acordo com a disponibilidade do banco de dados e o tipo de armazenamento, o desempenho e o tamanho máximo do armazenamento. Essas diferenças são descritas na tabela a seguir:

ㅤ Uso Geral Comercialmente Crítico Hiperescala
Mais adequado para Oferece opções equilibradas de computação e armazenamento orientadas ao 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 de espera ativa. A maior variedade de cargas de trabalho. Escala automático do tamanho do armazenamento de até 128 TB, dimensionamento rápido de computação vertical e horizontal, restauração rápida de banco de dados.
Tamanho da computação Dois a 128 vCores Dois a 128 vCores Dois a 128 vCores
Tipo de armazenamento Armazenamento remoto Premium (por instância) Armazenamento SSD local super rápido (por instância) Armazenamento desacoplado com cache SSD local (por 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 no máximo 4.000 IOPS por vCore com máximo de 327.680 IOPS 327.680 IOPS com SSD local máximo
A Hiperescala é uma arquitetura de várias camadas com cache em vários níveis. A IOPS efetiva depende da carga de trabalho.
Memória/vCore 5,1 GB 5,1 GB 5.1 GB ou 10.2 GB
Disponibilidade Um réplica, sem expansão de leitura, HA com redundância de zona Três réplicas, uma expansão de leitura, HA com redundância de zona Várias réplicas, até quatro com expansão de leitura, HA com redundância de zona
Backups Uma opção de armazenamento LRS (com redundância local), ZRS (com redundância de zona) ou GRS (com redundância geográfica)
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 LRS (com redundância local), ZRS (com redundância de zona) ou GRS (com redundância geográfica)
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 LRS (com redundância local), ZRS (com redundância de zona) ou GRS (com redundância geográfica)
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ço/cobrança O vCore, o armazenamento reservado e o armazenamento de backup são cobrados.
IOPS não são cobrados.		 O vCore, o armazenamento reservado e o armazenamento de backup são cobrados.
IOPS não são cobrados.		 VCore para cada réplica, armazenamento de dados alocado e armazenamento de backup são cobrados.
IOPS não são cobrados.
Modelos de desconto1 Instâncias reservadas
Benefício Híbrido do Azure2
Assinaturas de ofertas de Desenvolvimento/Teste com Pagamento Conforme o Uso e Enterprise		 Instâncias reservadas
Benefício Híbrido do Azure2
Assinaturas de ofertas de Desenvolvimento/Teste com Pagamento Conforme o Uso e Enterprise		 Instâncias reservadas
Benefício Híbrido do Azure2
Assinaturas de ofertas de Desenvolvimento/Teste com Pagamento Conforme o Uso e Enterprise

1 Os preços simplificados da Hiperescala do Banco de Dados SQL começaram em dezembro de 2023. Consulte o blog de preços de Hiperescala para obter detalhes.

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

Recursos de computação

Configuração de hardware CPU Memória
Série Standard (Gen 5) Computação provisionada
– Processadores 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, AMD EPYC 7763v (Milan)
– Provisionar até 80 vCores (hyper-threaded)

Computação sem servidor
– Processadores 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, AMD EPYC 7763v (Milan)
– Dimensionamento automático para até 80 vCores (hyper-threaded)
– A taxa de memória para vCore se adapta dinamicamente à memória e ao uso da CPU com base na demanda de carga de trabalho e pode ser de até 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 para até 24 GB por vCore
– Dimensionamento automático para um máximo de 240 GB
Série Premium – Processadores Intel® Xeon Platinum 8370C (Ice Lake) e AMD EPYC 7763v (Milan)
– Provisionar até 128 vCores (hyper-threaded)		 – 5,1 GB por vCore
Série Premium otimizada para memória – Processadores Intel® Xeon Platinum 8370C (Ice Lake) e AMD EPYC 7763v (Milan)
– Provisionar até 80 vCores (hyper-threaded)		 – 10.2 GB por vCore

1 Na exibição de gerenciamento dinâmico sys.dm_user_db_resource_governance, a geração de hardware para bancos de dados que usam processadores Intel® SP-8160 (Skylake) aparece como Gen6, a geração de hardware para bancos de dados que usam Intel® 8272CL (Cascade Lake) aparece como Gen7 e a geração de hardware para bancos de dados que usam Intel Xeon® Platinum 8370C (Ice Lake) ou AMD® EPYC® 7763v (Milan) 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 saber mais, confira os limites de recurso para bancos de dados individuais e pools elásticos.

O serverless só tem suporte no hardware da série Standard (Gen5).

Criar gerenciar bancos de dados de Hiperescala

Você pode criar e gerenciar bancos de dados de Hiperescala usando o portal do Azure, o Transact-SQL, o PowerShell e a CLI do Azure. Para obter mais informações, confira Início Rápido: Criar um banco de dados de Hiperescala no Banco de Dados SQL do Azure.

Operação Detalhes Saiba mais
Criar um banco de dados de Hiperescala Os bancos de dados de Hiperescala estão disponíveis somente ao usar o Modelo de compra baseado em vCore. Encontre exemplos para criar um banco de dados de Hiperescala em Início Rápido: criar um banco de dados de Hiperescala no Banco de Dados SQL do Azure.
Atualizar um banco de dados existente para Hiperescala A migração de um banco de dados existente no Banco de Dados SQL do Microsoft Azure para a camada de Hiperescala é uma operação do tamanho dos dados. Saiba como migrar um banco de dados existente para Hiperescala.
Migração reversa de um banco de dados de Hiperescala para a camada de serviço de Uso Geral Se você já migrou um Banco de Dados SQL do Azure existente para a camada de serviço da Hiperescala, é possível migrar o banco de dados para a camada de serviço de Uso Geral em até 45 dias da migração original para a Hiperescala.

Se você quiser migrar o banco de dados para outra camada de serviço, como Comercialmente Crítico, 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 fazer a migração reversa da Hiperescala, incluindo as limitações para migração reversa.

Reduzir

As operações de redução de banco de dados e arquivos estão atualmente em preview do Banco de Dados SQL do Azure Hyperscale. Para obter mais informações sobre a visualização, consulte Reduzir para o banco de dados SQL do Azure em hiperescala.

Limitações conhecidas

Essas são as limitações atuais da camada de serviço de Hiperescala. Estamos trabalhando ativamente para excluir o máximo de limitações.

Problema Descrição
A redução é bloqueada quando a TDE está desativada Atualmente, não há suporte para operações de redução de banco de dados e arquivo quando a TDE (Transparent Data Encryption) está desabilitada na Hiperescala do Banco de Dados SQL do Azure.
Restaurar banco de dados de outras camadas de serviço Um banco de dados não Hiperescala não pode ser restaurado como um banco de dados de Hiperescala, e um banco de dados de Hiperescala não pode ser restaurado como um banco de dados que não seja de Hiperescala.

Para os bancos de dados migrados para a Hiperescala de outras camadas de serviço do Banco de Dados SQL do Azure, os backups da pré-migração são mantidos durante o período de retenção de backup do banco de dados de origem, incluindo as políticas de retenção de longo prazo. Há suporte para a restauração de um backup de pré-migração dentro do período de retenção de backup do banco de dados por meio da linha de comando. Você pode restaurar esses backups em qualquer camada de serviço que não seja a Hiperescala.
Migração de bancos de dados com objetos OLTP In-Memory O Hiperescala é compatível com subconjunto de objetos OLTP In-Memory, incluindo tipos de tabela com otimização de memória, variáveis de tabela e módulos compilados nativamente. No entanto, quando qualquer objeto OLTP in-memory está presente no banco de dados que está sendo migrado, a migração de camadas de serviço Premium e Comercialmente Crítico para Hiperescala não é compatível. Para migrar esse banco de dados para Hiperescala, 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. No momento, não há suporte para as tabelas com otimização de memória duráveis e não duráveis com hiperescala, devendo ser alteradas para tabelas em disco.
Verificação de integridade do banco de dados Atualmente, o DBCC CHECKDB não é compatível com os bancos de dados de Hiperescala. DBCC CHECKTABLE ('TableName') WITH TABLOCK e DBCC CHECKFILEGROUP WITH TABLOCK pode ser usado como uma solução alternativa. Confira Integridade de dados no Banco de Dados SQL do Azure para obter detalhes sobre o gerenciamento de integridade no Banco de Dados SQL do Azure.
Trabalhos elásticos Não há suporte para o uso de um banco de dados de Hiperescala como o banco de dados Trabalho. No entanto, os trabalhos elásticos podem direcionar os bancos de dados de Hiperescala da mesma forma 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 de Hiperescala como um banco de dados de Hub ou de Metadados de Sincronização. No entanto, um banco de dados de Hiperescala 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 O hardware da série Premium com e sem otimização de memória atualmente não oferece suporte para camada de computação sem servidor.
Disponibilidade regional O hardware otimizado para memória das séries Premium e Premium da camada de serviço de hiperescala está disponível em regiões limitadas do Azure. Para obter uma lista, consulte Disponibilidade da série Premium de Hiperescala.

Conteúdo relacionado