Partilhar via

In-Memory visão geral do OLTP e cenários de uso

Aplica-se a:SQL ServerBanco de Dados SQL do AzureInstância Gerenciada SQL do Azure

In-Memory OLTP é a principal tecnologia disponível no SQL Server e no Banco de dados SQL para otimizar o desempenho do processamento de transações, ingestão de dados, carga de dados e cenários de dados transitórios. Este artigo inclui uma visão geral da tecnologia e descreve cenários de uso para In-Memory OLTP. Use essas informações para determinar se In-Memory OLTP é adequado para seu aplicativo. O artigo conclui com um exemplo que mostra In-Memory objetos OLTP, referência a uma demonstração perf e referências a recursos que você pode usar para as próximas etapas.

In-Memory visão geral do OLTP

In-Memory OLTP pode fornecer grandes ganhos de desempenho, para as cargas de trabalho certas. Embora os clientes tenham visto um ganho de desempenho de até 30 vezes em alguns casos, o ganho que você vê depende da carga de trabalho.

Agora, de onde vem esse ganho de desempenho? Em essência, In-Memory OLTP melhora o desempenho do processamento de transações, tornando o acesso aos dados e a execução de transações mais eficientes e removendo a contenção de bloqueio e trava entre transações executadas simultaneamente. In-Memory OLTP não é rápido porque está na memória; É rápido devido à otimização em torno dos dados na memória. Os algoritmos de armazenamento, acesso e processamento de dados foram redesenhados desde o início para aproveitar os aprimoramentos mais recentes em computação in-memory e de alta simultaneidade.

Agora, só porque os dados vivem na memória não significa que você os perde quando há uma falha. Por padrão, todas as transações são totalmente duráveis, o que significa que você tem as mesmas garantias de durabilidade obtidas para qualquer outra tabela no SQL Server: como parte da confirmação de transação, todas as alterações são gravadas no log de transações, no disco. Se houver uma falha a qualquer momento após a confirmação da transação, seus dados estarão lá quando o banco de dados voltar a ficar online. Além disso, In-Memory OLTP funciona com todos os recursos de alta disponibilidade e recuperação de desastres do SQL Server, como grupos de disponibilidade, instâncias de cluster de failover, backup/restauração e assim por diante.

Para usar In-Memory OLTP em seu banco de dados, use um ou mais dos seguintes tipos de objetos:

  • As tabelas com otimização de memória são usadas para armazenar dados do usuário. Você declara que uma tabela é otimizada para memória no momento da criação.
  • As tabelas não duráveis são usadas para dados transitórios, seja para armazenamento em cache ou para conjunto de resultados intermediário (substituindo tabelas temp tradicionais). Uma tabela não durável é uma tabela com otimização de memória que é declarada com DURABILITY=SCHEMA_ONLY, o que significa que as alterações nessas tabelas não incorrem em nenhuma E/S. Isso evita o consumo de recursos de E/S de log para casos em que a durabilidade não é uma preocupação.
  • Os tipos de tabela com otimização de memória são usados para parâmetros com valor de tabela (TVPs) e conjuntos de resultados intermediários em procedimentos armazenados. Tipos de tabela com otimização de memória podem ser usados em vez dos tipos de tabela tradicionais. As variáveis de tabela e TVPs declaradas usando um tipo de tabela com otimização de memória herdam os benefícios de tabelas não duráveis com otimização de memória: acesso eficiente a dados e sem E/S.
  • Os módulos T-SQL compilados nativamente são usados para reduzir ainda mais o tempo necessário para uma transação individual, reduzindo os ciclos de CPU necessários para processar as operações. Você declara um módulo Transact-SQL a ser compilado nativamente no momento da criação. Neste momento, os seguintes módulos T-SQL podem ser compilados nativamente: procedimentos armazenados, gatilhos e funções escalares definidas pelo usuário.

In-Memory OLTP é incorporado ao SQL Server e ao Banco de Dados SQL. Como esses objetos se comportam de maneira semelhante aos seus homólogos tradicionais, muitas vezes você pode obter benefícios de desempenho ao fazer apenas alterações mínimas no banco de dados e no aplicativo. Além disso, você pode ter tabelas baseadas em disco tradicionais e otimizadas para memória no mesmo banco de dados e executar consultas entre os dois. Consulte o exemplo de script Transact-SQL para cada um desses tipos de objetos mais adiante neste artigo.

Cenários de uso para In-Memory OLTP

In-Memory OLTP não é um botão mágico e não é adequado para todas as cargas de trabalho. Por exemplo, tabelas com otimização de memória não reduzem a utilização da CPU se a maioria das consultas estiver executando agregação em grandes intervalos de dados. Os índices Columnstore ajudam nesse cenário.

Atenção

Problema conhecido: para bancos de dados com tabelas com otimização de memória, executar um backup de log transacional sem recuperação e, posteriormente, executar uma restauração de log de transações com recuperação pode resultar em um processo de restauração de banco de dados sem resposta. Esse problema também pode afetar a funcionalidade de envio de logs. Para contornar esse problema, a instância do SQL Server pode ser reiniciada antes de iniciar o processo de restauração.

Aqui está uma lista de cenários e padrões de aplicativos em que vimos os clientes serem bem-sucedidos com In-Memory OLTP.

Processamento de transações de alta taxa de transferência e baixa latência

Este é o cenário central para o qual construímos In-Memory OLTP: suporte a grandes volumes de transações, com baixa latência consistente para transações individuais.

Os cenários de carga de trabalho comuns são: negociação de instrumentos financeiros, apostas esportivas, jogos móveis e veiculação de anúncios. Outro padrão comum é um "catálogo" que é frequentemente lido e/ou atualizado. Um exemplo é quando você tem arquivos grandes, cada um distribuído em vários nós de cluster, e cataloga o local de cada fragmento de cada arquivo em uma tabela com otimização de memória.

Considerações de implementação

Use tabelas com otimização de memória para suas principais tabelas de transações, ou seja, as tabelas com as transações mais críticas para o desempenho. Use procedimentos armazenados compilados nativamente para otimizar a execução da lógica associada à transação comercial. Quanto mais lógica você puder inserir em procedimentos armazenados no banco de dados, mais benefícios você verá In-Memory OLTP.

Para começar a usar um aplicativo existente:

  1. Use o relatório de análise de desempenho de transação para identificar os objetos que você deseja migrar.
  2. Use o Memory Optimization Advisor e o Native Compilation Advisor para ajudar na migração.

Ingestão de dados, incluindo IoT (Internet das Coisas)

In-Memory OLTP é bom em ingerir grandes volumes de dados de muitas fontes diferentes ao mesmo tempo. E muitas vezes é benéfico ingerir dados em um banco de dados do SQL Server em comparação com outros destinos, porque o SQL Server torna a execução de consultas nos dados rápida e permite que você obtenha informações em tempo real.

Os padrões de aplicação comuns são:

  • Ingerir leituras e eventos do sensor e permitir notificações, bem como análise histórica.
  • Gerenciar atualizações em lote, mesmo de várias fontes, enquanto minimiza o impacto na carga de trabalho de leitura simultânea.

Considerações de implementação

Use uma tabela com otimização de memória para a ingestão de dados. Se a ingestão consistir principalmente em inserções (em vez de atualizações) e In-Memory pegada de armazenamento OLTP dos dados for uma preocupação, ou

  • Use um trabalho para descarregar regularmente dados em lote para uma tabela baseada em disco com um índice columnstore clusterizado, usando um trabalho que faça INSERT INTO <disk-based table> SELECT FROM <memory-optimized table>;
  • Use uma tabela otimizada para memória temporal para gerenciar dados históricos - nesse modo, os dados históricos permanecem no disco e a movimentação de dados é gerenciada pelo sistema.

O repositório de exemplos do SQL Server contém um aplicativo de grade inteligente que usa uma tabela com otimização de memória temporal, um tipo de tabela com otimização de memória e um procedimento armazenado compilado nativamente para acelerar a ingestão de dados, enquanto gerencia a pegada de armazenamento OLTP In-Memory dos dados do sensor:

Cache e estado da sessão

A tecnologia OLTP In-Memory torna o mecanismo de banco de dados no SQL Server ou bancos de dados SQL do Azure uma plataforma atraente para manter o estado da sessão (por exemplo, para um aplicativo ASP.NET) e para armazenar em cache.

ASP.NET estado da sessão é um caso de uso bem-sucedido para In-Memory OLTP. Com o SQL Server, um cliente estava prestes a atingir 1,2 milhão de solicitações por segundo. Enquanto isso, eles começaram a usar In-Memory OLTP para as necessidades de cache de todos os aplicativos intermediários na empresa. Detalhes: Como a bwin está usando o SQL Server 2016 (13.x) In-Memory OLTP para obter desempenho e escala sem precedentes

Considerações de implementação

Você pode usar tabelas com otimização de memória não durável como um simples armazenamento de chave-valor armazenando um BLOB em uma coluna varbinary(max). Como alternativa, você pode implementar um cache semiestruturado com suporte a JSON no SQL Server e no Banco de dados SQL. Finalmente, você pode criar um cache relacional completo por meio de tabelas não duráveis com um esquema relacional completo, incluindo vários tipos de dados e restrições.

Comece a otimizar a memória ASP.NET estado da sessão usando os scripts publicados no GitHub para substituir os objetos criados pelo provedor de estado de sessão interno do SQL Server: aspnet-session-state

Estudo de caso de cliente

substituição de objeto tempdb

Use tabelas não duráveis e tipos de tabela com otimização de memória para substituir suas estruturas baseadas tradicionais tempdb , como tabelas temporárias, variáveis de tabela e parâmetros com valor de tabela (TVPs).

Variáveis de tabela com otimização de memória e tabelas não duráveis normalmente reduzem a CPU e removem completamente a E/S de log, quando comparadas com variáveis de tabela tradicionais e #temp tabela.

Considerações de implementação

Para começar: Melhorar o desempenho da tabela temporária e da variável de tabela usando a otimização da memória.

Estudo de caso de cliente

ETL (carga de transformação de extração)

Os fluxos de trabalho de ETL geralmente incluem carga de dados em uma tabela de preparo, transformações dos dados e carga nas tabelas finais.

Use tabelas com otimização de memória não durável para o preparo de dados. Eles removem completamente todas as E/S e tornam o acesso aos dados mais eficiente.

Considerações de implementação

Se você executar transformações na tabela de preparo como parte do fluxo de trabalho, poderá usar procedimentos armazenados compilados nativamente para acelerar essas transformações. Se você puder fazer essas transformações em paralelo, obterá benefícios adicionais de dimensionamento da otimização de memória.

Exemplo de script

Antes de começar a usar In-Memory OLTP, você precisa criar um MEMORY_OPTIMIZED_DATA grupo de arquivos. Além disso, recomendamos usar o nível de compatibilidade de banco de dados 130 (ou superior) e definir a opção de banco de dados MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT como ON.

Você pode usar o script no seguinte local para criar o grupo de arquivos na pasta de dados padrão e definir as configurações recomendadas:

O script de exemplo a seguir ilustra In-Memory objetos OLTP que você pode criar em seu banco de dados.

Primeiro, comece configurando o banco de dados para In-Memory OLTP.

-- configure recommended DB option
ALTER DATABASE CURRENT SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT=ON;
GO

Você pode criar tabelas com durabilidade diferente:

-- memory-optimized table
CREATE TABLE dbo.table1
( c1 INT IDENTITY PRIMARY KEY NONCLUSTERED,
  c2 NVARCHAR(MAX))
WITH (MEMORY_OPTIMIZED=ON);
GO
-- non-durable table
CREATE TABLE dbo.temp_table1
( c1 INT IDENTITY PRIMARY KEY NONCLUSTERED,
  c2 NVARCHAR(MAX))
WITH (MEMORY_OPTIMIZED=ON,
      DURABILITY=SCHEMA_ONLY);
GO

Você pode criar um tipo de tabela como uma tabela na memória.

-- memory-optimized table type
CREATE TYPE dbo.tt_table1 AS TABLE
( c1 INT IDENTITY,
  c2 NVARCHAR(MAX),
  is_transient BIT NOT NULL DEFAULT (0),
  INDEX ix_c1 HASH (c1) WITH (BUCKET_COUNT=1024))
WITH (MEMORY_OPTIMIZED=ON);
GO

Você pode criar um procedimento armazenado compilado nativamente. Para obter mais informações, consulte Chamando procedimentos armazenados compilados nativamente de aplicativos de acesso a dados.

-- natively compiled stored procedure
CREATE PROCEDURE dbo.usp_ingest_table1
  @table1 dbo.tt_table1 READONLY
WITH NATIVE_COMPILATION, SCHEMABINDING
AS
BEGIN ATOMIC
    WITH (TRANSACTION ISOLATION LEVEL=SNAPSHOT,
          LANGUAGE=N'us_english')

  DECLARE @i INT = 1

  WHILE @i > 0
  BEGIN
    INSERT dbo.table1
    SELECT c2
    FROM @table1
    WHERE c1 = @i AND is_transient=0

    IF @@ROWCOUNT > 0
      SET @i += 1
    ELSE
    BEGIN
      INSERT dbo.temp_table1
      SELECT c2
      FROM @table1
      WHERE c1 = @i AND is_transient=1

      IF @@ROWCOUNT > 0
        SET @i += 1
      ELSE
        SET @i = 0
    END
  END

END
GO
-- sample execution of the proc
DECLARE @table1 dbo.tt_table1;
INSERT @table1 (c2, is_transient) VALUES (N'sample durable', 0);
INSERT @table1 (c2, is_transient) VALUES (N'sample non-durable', 1);
EXECUTE dbo.usp_ingest_table1 @table1=@table1;
SELECT c1, c2 from dbo.table1;
SELECT c1, c2 from dbo.temp_table1;
GO

Conteúdo relacionado