Persistência de dados em memória com o Hekaton

Há um bom tempo sabemos que o grande gargalo de desempenho em bancos de dados tem sido o local de armazenamento e recuperação das informações, os HDs. Quando os SGBDs foram projetados, não contávamos com o desenvolvimento tecnológico que possuímos atualmente, e considerávamos a disponibilidade de hardware escassa e de alto custo naquela época.

A arquitetura presente no SQL Server até a versão Denali (2012), assim como em outros SGBDs, foi projetada para persistir os dados somente nos HDs, mas devido à evolução em termos de hardware aliada à queda nos preços de memória física, a suposição de que o armazenamento de dados deveria sempre ocorrer nos HDs passou a ser modificada.

Os servidores de aplicações e bancos de dados passaram a trabalhar com cada vez mais memória, como também processadores de diversos núcleos de processamento.

A Microsoft, reconhecendo essa tendência, começou a aperfeiçoar o database engine do SQL Server para realizar um melhor aproveitamento da grande quantidade de memória e recursos de processamento que os servidores atuais dispõem.

É válido lembrar que os servidores receberam arquitetura de 64bit a partir de 2003, entretanto a capacidade de processamento que faz com que os servidores reconheçam grandes quantidades de memória vem desde 2012.

O projeto Hekaton foi idealizado com o objetivo de trabalhar com dados e tabelas completamente em memória (atuando de maneira completamente diferente de quando estes estão em disco) e a partir de uma arquitetura híbrida (ou seja, atuar com dados persistidos em memória e também em disco), alcançar muito mais eficiência no processamento das transações.

O que é o projeto Hekaton?

O projeto Hekaton teve seu início há cerca de quatro anos atrás, onde foi oficialmente apresentado como a feature In-Memory OLTP presente na versão 2014 do SQL Server. Seu início foi dado em um momento em que se notou a crescente necessidade de agilidade nos processos das organizações, como também a crescente queda nos preços de memória no decorrer dos últimos trinta anos, ao mesmo tempo em que servidores com uma grande capacidade de processamento se tornaram acessíveis para a grande maioria das organizações. Atualmente se pode comprar um servidor com 32 núcleos de processamento e 1TB de memória por menos de 50 mil reais.

Essa feature consiste em um novo database engine, entretanto esta nova engine não substitui a utilizada até então. Foi desenvolvida uma arquitetura para trabalhar em completa conformidade com tudo o que sempre existiu no SQL Server, não necessitando de uma nova interface gráfica, ou um novo aprendizado em termos de linguagem para sua utilização.

É possível notar essa conformidade na arquitetura do SQL Server 2014 que será demonstrada mais adiante. Notaremos alguns componentes que não existiam, e que atualmente se relacionam com alguns já existentes em versões anteriores do SGBD.

A In-Memory OLTP foi projetada com o foco principal em transações OLTP, onde ao acessar dados persistidos em memória será possível atingir significativas melhorias de desempenho devido ao tempo reduzido para efetuar as transações que se utilizam da feature.

As principais razões da redução do tempo de processamento é a falta de necessidade de recuperar dados contidos no disco, como também a maneira à qual as Stored Procedures podem ser compiladas (como uma DLL em código de máquina) o que também resulta em mais otimização. Segundo estudos e casos de sucesso já publicados é possível adquirir uma melhoria de cerca de 20 vezes ou mais em determinadas transações.

Devido à nova concepção de armazenamento de dados apresentada pela feature In-Memory OLTP, ela tem sido considerada a mais importante melhoria presente na versão do SQL Server 2014. Desde que a feature foi apresentada, muitas questões foram levantadas na comunidade de SQL e muitas das respostas apresentadas se tornaram mito que ainda confundem muitas pessoas. Por exemplo, In-Memory OLTP teria a mesma funcionalidade ou seria uma versão melhorada da descontinuada feature DBCC PINTABLE?

A In-Memory OLTP em nada se assemelha com a DBCC PINTABLE. Nas primeiras versões do SQL Server existiam situações nas quais era necessário mover páginas de dados de tabelas muito utilizadas para o buffer pool.

Para esse tipo de necessidade foi introduzido o comando DBCC PINTABLE na versão 6.5 que foi muito utilizado até a versão 2000, e descontinuado na versão 2005. DBCC PINTABLE não fazia com que as tabelas fossem lidas da memória, o comando fazia com que as páginas ficassem marcadas como pinned no buffer pool, e não liberava o espaço alocado para a leitura de uma nova página até que o comando DBCC UNPINTABLE fosse realizado.

Porém, nada disso impedia de o SQL Server realizar uma nova escrita nas páginas de dados, como ocorre em uma instrução de atualização por exemplo.

O In-Memory OLTP traz uma concepção completamente diferenciada. Ele foi projetado para que as transações não necessitem sofrer com latência derivada da escrita e leitura de dados em disco.

Ao utilizar essa feature, os dados envolvidos em uma determinada transação não sofrerão com bloqueios ocasionados por níveis de isolamento, latência devido à escrita de operações no arquivo de log de transações, "