A História do Hekaton - Parte 1

Hekaton é uma funcionalidade que faz parte do “In-Memory Database” e está disponível a partir do SQL Server 2014.

Neste post quero mostrar um lado diferente do Hekaton. Vejo muita gente falando sobre a melhoria significativa de desempenho ao manter as tabelas em memória. Entretanto, o Hekaton não é exatamente isso! E, se fosse, deveria ser chamado de DBCC PINTABLE.

A funcionalidade denominada Hekaton nasceu a partir de uma constatação simples: as consultas T-SQL demoram milissegundos, enquanto que códigos nativos rodam em microssegundos. Veja o exemplo abaixo:

Esse código é centenas de vezes mais rápido do que o equivalente em T-SQL:

Qual o motivo dessa diferença de desempenho? Um grupo de pesquisadores da Microsoft Research junto com o time de desenvolvimento SQL Server trouxeram a possibilidade de empregar .NET como forma de codificação nativa no servidor. Afinal, por que não permitir que o SQL Server atinja esse desempenho de microssegundos? Além disso, por que não remover as sincronizações de thread entre CPUs, garantindo escalabilidade ao produto?

Assim nasceu a ideia do Hekaton…

Como fazer o SQL Server ter um desempenho semelhante ao código nativo?

1. Adoção de índices Hash – Como os índices clustered e non-clustered são baseados em estruturas B+ Trees, as operações de consulta (singleton lookup) percorrem os non-leaf nodes e se tornam operações bastante custosas. Uma forma de otimizar é adotar índices sem a hierarquia de árvore. Índices hash são mais rápidos. O principal parâmetro de ajuste em um índice Hash é o número de buckets: quanto maior o número de buckets, melhor o desempenho ao custo de maior espaço utilizado.
2. Compilação em código nativo – Enquanto os comandos T-SQL são interpretados e gerenciados por uma máquina de estado, o código .NET é compilado em código de máquina. O ganho de desempenho é direto.
3. Não há bloqueios ou locks – Isso é incrível! Assim como no exemplo do código .NET, não há necessidade de usar bloqueios explícitos.

Estou repetindo esse último item: não há locks envolvidos. Essa mudança é tão profunda que envolve mudanças significativas na forma como o Hekaton acessa as informações.

Por exemplo, no modelo atual os registros ficam armazenados em páginas de 8Kb. Portanto, múltiplos registros podem compartilhar uma mesma página e requerem o uso de Latches e Locks para sincronizar o acesso.

Hekaton, por outro lado, mantém uma lista ligada de registros. Essa lista é protegida por spinlocks, não sendo necessário realizar a operação de Latch/UnLatch. Essa é uma economia significativa de recursos, pois evita as transições para Kernel Mode e reduz o custo total de thread context switch.

Agora temos um código mais limpo:

A utilização de spinlock, no entanto, requer que os dados estejam previamente em memória. Não pode haver operações de leitura de disco enquanto as threads possuem spinlock. Em outras palavras, o Hekaton não utiliza PAGEIOLATCH ou PAGELATCH. Isso significa que todos os registros devem ficar em memória previamente.

Quem tem mais tempo de SQL Server (7.0, 2000, 2005) talvez se lembre do lendário e obsoleto comando DBCC PINTABLE. Esse comando garantia que a tabela ficasse em memória e o ganho de desempenho era decorrente da redução na quantidade de acesso ao disco. Na realidade, a eficácia do PINTABLE sempre foi muito questionável. A arquitetura do SQL Server garante que os dados mais acessados são mantidos em memória e, portanto, não há motivos que justificam seu uso. Esse foi um dos motivos pelo qual a Microsoft descontinuou esse comando.

Se alguém perguntar sobre qual a diferença entre Hekaton e DBCC PINTABLE, responda que eles são completamente diferentes.

O segredo do Hekaton é utilizar estruturas baseadas em registros e protegidas por spinlocks. Manter as tabelas em memória é um pré-requisito da arquitetura atual (e que pode ser melhorado no futuro).

Esqueça que isso tem alguma semelhança com DBCC PINTABLE, pois o Hekaton não utiliza o Buffer Pool. Ele possui uma estrutura à parte. A proposta do Hekaton era trazer o desempenho do código .NET para dentro do SQL Server.

Nesa primeira parte, apresentei os principais motivadores para o surgimento do Hekaton. Entretanto, houve uma série de evoluções na tecnologia até chegar à sua forma final. Se você conhece bem o Hekaton, sabe que não existe código .NET (e sim código em C) e que existem índices na forma de B-Tree para o Hekaton. Deixarei essa discussão para uma parte 2.

Você gostou do artigo? Deixe seu comentário com sugestões.

Fabricio Catae (@fcatae)

• Anonymous
  March 11, 2017
  Muito bom artigo... Conhecer o principio das coisas é sempre esclarecedor. Parabéns
  • Anonymous
    March 12, 2017
    Otimo! Obrigado!
• Anonymous
  March 29, 2017
  Ótimo artigo , parabéns !!!
  • Anonymous
    March 29, 2017
    Obrigado João!
• Anonymous
  July 12, 2017
  Estou um pouco atrasado na leitura, mas realmente, muito bom o primeiro artigo, partindo para o Segundo da serie... =)