Ler em inglês

Partilhar via

Otimizar o desempenho usando tecnologias na memória no Banco de Dados SQL do Azure

  • Artigo

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

As tecnologias na memória permitem melhorar o desempenho do aplicativo e, potencialmente, reduzir o custo do banco de dados.

Quando usar tecnologias em memória

Usando tecnologias in-memory, você pode obter melhorias de desempenho com várias cargas de trabalho:

  • transacional (processamento transacional online (OLTP)) onde a maioria das solicitações lê ou atualiza um conjunto menor de dados, por exemplo, operações create/read/update/delete (CRUD).
  • analítico (processamento analítico on-line (OLAP)) onde a maioria das consultas tem cálculos complexos para fins de relatório e também processos agendados regularmente que executam operações de carga (ou carga em massa) e/ou gravam alterações de dados em tabelas existentes. Muitas vezes, as cargas de trabalho OLAP são atualizadas periodicamente a partir de cargas de trabalho OLTP.
  • mista (transação híbrida/processamento analítico (HTAP)) em que as consultas OLTP e OLAP são executadas no mesmo conjunto de dados.

As tecnologias na memória podem melhorar o desempenho dessas cargas de trabalho mantendo os dados que devem ser processados na memória, usando compilação nativa das consultas ou processamento avançado, como processamento em lote e instruções SIMD disponíveis no hardware subjacente.

Visão geral

A Base de Dados SQL do Azure suporta as seguintes tecnologias na memória:

  • In-Memory OLTP aumenta o número de transações por segundo e reduz a latência para o processamento de transações. Os cenários que se beneficiam de In-Memory OLTP são: processamento de transações de alta taxa de transferência, como negociação e jogos, ingestão de dados de eventos ou dispositivos IoT, cache, carga de dados e cenários de tabelas temporárias e variáveis de tabela.
  • Os índices columnstore agrupados reduzem a pegada de armazenamento (até 10 vezes) e melhoram o desempenho para consultas de relatórios e de análise. Você pode usá-lo com tabelas de fatos nos seus data marts para acomodar mais dados na sua base de dados e melhorar o desempenho. Além disso, você pode usá-lo com dados históricos em seu banco de dados operacional para arquivar e ser capaz de consultar até 10 vezes mais dados.
  • índices columnstore não clusterizados para HTAP ajudam você a obter insights em tempo real sobre sua empresa consultando o banco de dados operacional diretamente, sem a necessidade de executar um processo caro de extração, transformação e carregamento (ETL) e esperar que o data warehouse seja preenchido. Os índices columnstore não clusterizados permitem a execução rápida de consultas analíticas no banco de dados OLTP, reduzindo o impacto na carga de trabalho operacional.
  • Índices columnstore clusterizados otimizados para memória para HTAP permite que você execute um processamento rápido de transações e simultaneamente execute consultas de análise muito rapidamente nos mesmos dados.

Os índices Columnstore e In-Memory OLTP foram introduzidos no SQL Server em 2012 e 2014, respectivamente. O Banco de Dados SQL do Azure, a Instância Gerenciada SQL do Azure e o SQL Server compartilham a mesma implementação de tecnologias na memória.

Nota

Para obter um tutorial passo a passo detalhado para demonstrar as vantagens de desempenho de In-Memory tecnologia OLTP, usando o banco de dados de exemplo AdventureWorksLT e ostress.exe, consulte Exemplo na memória no Banco de Dados SQL do Azure.

Benefícios da tecnologia in-memory

Devido ao processamento mais eficiente de consultas e transações, as tecnologias in-memory também ajudam a reduzir custos. Normalmente, não é necessário atualizar a camada de preços do banco de dados para obter ganhos de desempenho. Em alguns casos, pode-se até mesmo reduzir o nível de preço, enquanto ainda se observam melhorias de desempenho com tecnologias em memória.

Usando In-Memory OLTP, a Quorum Business Solutions conseguiu dobrar sua carga de trabalho enquanto melhorava as DTUs em 70%. Para obter mais informações, consulte In-Memory OLTP no Banco de Dados SQL do Azure.

Nota

In-Memory OLTP está disponível nas camadas de serviço Premium (DTU) e Business Critical (vCore) do Banco de Dados SQL do Azure. A camada de serviço Hyperscale suporta um subconjunto de In-Memory objetos OLTP. Para obter mais informações, consulte Limitações de hiperescala.

Os índices Columnstore estão disponíveis em todas as camadas de serviço, exceto na camada Básica e na camada Standard quando o objetivo do serviço está abaixo do S3. Para obter mais informações, consulte Alterar camadas de serviço de bases de dados contendo índices columnstore.

Este artigo descreve aspetos de In-Memory índices OLTP e columnstore específicos do Banco de Dados SQL do Azure e também inclui exemplos que permitem ver:

  • O impacto dessas tecnologias nos limites de armazenamento e tamanho de dados.
  • Como gerenciar a movimentação de bancos de dados que usam essas tecnologias entre os diferentes níveis de preços.
  • Um exemplo ilustrativo de In-Memory OLTP, bem como índices de armazenamento em colunas.

Para obter mais informações sobre tecnologias na memória no SQL Server, consulte:

In-Memory OLTP

In-Memory tecnologia OLTP fornece operações de acesso a dados extremamente rápidas, mantendo todos os dados na memória. Ele também usa índices especializados, compilação nativa de consultas e acesso a dados sem trava para melhorar o desempenho da carga de trabalho OLTP. Há duas maneiras de organizar seus dados OLTP In-Memory:

  • Formato de armazenamento de linha otimizado para memória, onde cada linha é um objeto de memória separado. Este é um formato OLTP In-Memory clássico otimizado para cargas de trabalho OLTP de alto desempenho. Há dois tipos de tabelas com otimização de memória que podem ser usadas no formato de armazenamento de linha com otimização de memória:

    • Tabelas duráveis (SCHEMA_AND_DATA) onde as linhas colocadas na memória são preservadas após a reinicialização do servidor. Esse tipo de tabela se comporta como uma tabela de armazenamento de linhas tradicional com os benefícios adicionais das otimizações na memória.
    • Tabelas não duráveis (SCHEMA_ONLY) onde as linhas não são preservadas após a reinicialização. Esse tipo de tabela foi projetado para dados temporários (por exemplo, substituição de tabelas temporárias) ou tabelas em que você precisa carregar dados rapidamente antes de movê-los para alguma tabela persistente (as chamadas tabelas de preparo).

  • Formato columnstore otimizado para memória onde os dados são organizados em formato colunar. Essa estrutura foi projetada para cenários HTAP em que você precisa executar consultas analíticas na mesma estrutura de dados em que sua carga de trabalho OLTP está sendo executada.

Nota

In-Memory tecnologia OLTP é projetada para as estruturas de dados que podem residir totalmente na memória. Como os dados na memória não podem ser descarregados para o disco, verifique se você está usando um banco de dados com memória suficiente. Para obter mais informações, consulte Tamanho de dados e limite de armazenamento para In-Memory OLTP.

Tamanho dos dados e limite de armazenamento para In-Memory OLTP

In-Memory OLTP inclui tabelas com otimização de memória, que são usadas para armazenar dados do usuário. Essas tabelas são necessárias para caber na memória. Cada objetivo de serviço tem uma cota de memória ou limite para tabelas otimizadas para memória, conhecido como armazenamento OLTP In-Memory.

Cada objetivo de serviço de banco de dados único suportado e cada objetivo de serviço de pool elástico inclui uma certa quantidade de armazenamento OLTP In-Memory:

Os seguintes itens contam para o limite de armazenamento OLTP In-Memory:

  • Linhas de dados de utilizadores ativos em tabelas otimizadas para memória e variáveis de tabela. As versões antigas de linhas não contam para o limite.
  • Índices em tabelas com otimização de memória.
  • Sobrecarga operacional das operações ALTER TABLE.

Se atingir o limite, receberá um erro de exceder o limite da cota e não poderá inserir ou atualizar dados. Para atenuar esse erro, exclua dados ou aumente o objetivo de serviço do banco de dados ou pool elástico.

Para obter detalhes sobre como monitorar In-Memory utilização do armazenamento OLTP e configurar alertas quando você quase atinge o limite, consulte Monitor In-Memory armazenamento OLTP.

Sobre piscinas elásticas

Com pools elásticos, o armazenamento OLTP In-Memory é compartilhado entre todos os bancos de dados no pool. Portanto, o uso em um banco de dados pode potencialmente afetar outros bancos de dados. Duas atenuações para isso são:

  • Configure um Max eDTU ou Max vCore para bancos de dados que seja menor do que a contagem de eDTU ou vCore para o pool como um todo. Esse máximo também limita a utilização do armazenamento OLTP In-Memory em qualquer banco de dados no pool proporcionalmente.
  • Configure um Min eDTU ou Min vCore maior que 0. Esse mínimo garante que cada banco de dados no pool tenha a quantidade de armazenamento OLTP In-Memory disponível que corresponde ao Min eDTU ou Min vCoreconfigurado.

Alterar camadas de serviço de bancos de dados que usam tecnologias OLTP In-Memory

In-Memory OLTP não tem suporte nas camadas de serviço de Propósito Geral, Standard e Básico do Banco de Dados SQL do Azure. Portanto, não é possível dimensionar um banco de dados que tenha objetos OLTP In-Memory para uma dessas camadas. Se você quiser dimensionar um banco de dados para uma dessas camadas de serviço, remova todas as tabelas e tipos de tabela com otimização de memória, bem como todos os módulos T-SQL compilados nativamente, ou converta-os em objetos baseados em disco e módulos T-SQL regulares.

Quando você reduz a escala de um banco de dados Business Critical ou Premium, os dados nas tabelas com otimização de memória devem caber no armazenamento OLTP In-Memory disponível no objetivo de serviço de destino do banco de dados ou pool elástico. Se tentar reduzir a escala do banco de dados ou do pool elástico, ou mover um banco de dados para um pool elástico, e o objetivo do serviço de destino não tiver armazenamento OLTP In-Memory suficiente disponível, a operação falhará.

Determinar se existem os objetos OLTP In-Memory

Há uma maneira programática de descobrir se um determinado banco de dados suporta In-Memory OLTP. Você pode executar a seguinte consulta Transact-SQL:

SQL 
SELECT DATABASEPROPERTYEX(DB_NAME(), 'IsXTPSupported');

Se a consulta retornar 1, In-Memory OLTP é suportado neste banco de dados.

As consultas a seguir identificam todos os objetos que precisam ser removidos antes que um banco de dados possa ser dimensionado para a camada de serviço Hyperscale, General Purpose, Standard ou Basic:

SQL 
SELECT * FROM sys.tables WHERE is_memory_optimized = 1;
SELECT * FROM sys.table_types WHERE is_memory_optimized = 1;
SELECT * FROM sys.sql_modules WHERE uses_native_compilation = 1;

Columnstore na memória

A tecnologia de columnstore em memória permite armazenar e consultar uma grande quantidade de dados nas tabelas. A tecnologia Columnstore usa o formato de armazenamento de dados baseado em colunas e o processamento de consultas em lote para obter um ganho de até 10 vezes o desempenho da consulta em cargas de trabalho OLAP em relação ao armazenamento tradicional orientado a linhas. Você também pode obter ganhos de até 10 vezes a compactação de dados em relação ao tamanho de dados não compactados.

Há dois tipos de índices columnstore que você pode usar para organizar seus dados:

  • Clustered columnstore onde todos os dados da tabela estão organizados em formato de coluna. Nesse tipo de índice, todas as linhas da tabela são colocadas em formato colunar que compacta altamente os dados e permite executar consultas analíticas e relatórios rápidos na tabela. Dependendo da natureza dos seus dados, o tamanho dos seus dados pode ser reduzido 10x-100x. Os índices columnstore agrupados também permitem a ingestão rápida de uma grande quantidade de dados (carga em massa), uma vez que grandes lotes de dados superiores a 100.000 linhas são compactados antes de serem armazenados no disco. Esse tipo de índice é uma boa opção para os cenários clássicos de data warehouse.
  • Armazenamento em coluna não agrupado onde os dados são armazenados na tabela de armazenamento em linha tradicional e há um índice adicional no formato de armazenamento em coluna que é usado para as consultas analíticas. Esse tipo de índice permite o Hybrid Transactional-Analytic Processing (HTAP): a capacidade de executar análises rápidas em tempo real em uma carga de trabalho transacional. As consultas OLTP são executadas na tabela rowstore otimizada para acessar um pequeno conjunto de linhas, enquanto as consultas OLAP são executadas no índice columnstore, que é a melhor opção para verificações e análises. O otimizador de consulta escolhe dinamicamente o formato rowstore ou columnstore com base na consulta. Os índices columnstore não clusterizados não diminuem o tamanho dos dados, uma vez que o conjunto de dados original é mantido na tabela de armazenamento de linhas original sem qualquer alteração. No entanto, o tamanho do índice columnstore adicional é ordens de magnitude menor do que o índice equivalente B-tree.

Nota

A tecnologia columnstore na memória mantém apenas os dados necessários para o processamento na memória, enquanto os dados que não cabem na memória são armazenados no disco. Portanto, a quantidade de dados em estruturas columnstore pode exceder a quantidade de memória disponível.

Tamanho e armazenamento de dados para índices de armazenamento por colunas

Os índices Columnstore não são necessários para caber totalmente na memória. Portanto, o único limite no tamanho dos índices é o tamanho máximo geral do banco de dados, que é documentado nos artigos do modelo de compra baseado em DTU e no modelo de compra baseado em vCore .

Quando você usa índices columnstore clusterizados, a compactação colunar é usada para o armazenamento da tabela base. Essa compactação pode reduzir significativamente o espaço necessário para armazenar os dados do utilizador, o que significa que pode inserir mais dados no banco de dados. A taxa de compressão pode ser ainda mais aumentada com a compressão arquivística colunar . A quantidade de compactação que você pode alcançar depende da natureza dos dados, mas 10 vezes a compactação não é incomum.

Por exemplo, se tiver um banco de dados com um tamanho máximo de 1 terabyte (TB) e conseguir 10 vezes a compressão usando índices do tipo columnstore, poderá armazenar um total de 10 TB de dados do utilizador no banco de dados.

Quando você usa índices columnstore não clusterizados, a tabela base ainda é armazenada no formato tradicional de armazenamento de linhas. Portanto, a economia de armazenamento não é tão significativa quanto com os índices columnstore clusterizados. No entanto, se você estiver substituindo muitos índices tradicionais não clusterizados por um único índice columnstore, ainda poderá ver uma economia geral no espaço de armazenamento da tabela. Pode também usar a compactação de dados rowstore para a tabela base.

Alterar camadas de serviço de bancos de dados que contêm índices columnstore

Se utilizar o modelo de compra DTU e o seu banco de dados contiver índices columnstore, o seu aplicativo poderá parar de funcionar se dimensionar o seu banco de dados abaixo do nível de serviço S3. Os índices Columnstore são suportados apenas nas camadas de serviço Hyperscale, Business Critical e Premium, bem como na camada de serviço Standard se usar o S3 e superior. Os índices Columnstore não são suportados na camada de serviço Basic. Quando você dimensiona seu banco de dados para uma camada de serviço ou objetivo de serviço sem suporte, seu índice columnstore fica indisponível. O sistema mantém o índice quando você executa instruções DML, mas nunca usa o índice. Se, posteriormente, você reduzir para uma camada de serviço ou objetivo de serviço suportado, seu índice columnstore estará imediatamente pronto para ser usado novamente.

Se tiveres um índice columnstore agrupado, a tabela inteira ficará indisponível se o banco de dados for escalado para uma camada de serviço ou objetivo de serviço sem suporte. Elimine todos os índices columnstore clusterizados , substituindo-os por índices clusterizados de armazenamento de linhas ou heaps, antes da operação de dimensionamento.

Conteúdo relacionado