In-Memory OLTP – “Hekaton” – Parte2

Posted on junho 20, 2013

1


Como dito no post anterior – https://luanmorenodba.wordpress.com/2013/06/05/in-memory-oltp-hekaton-parte1/ o “Hekaton” é um novo recurso otimizado em memória para se trabalhar em ambientes OLTP. Nesse post irei explicar sobre seus novos mecanismos e quebra de paradigmas. A grande diferença é que agora os dados não são mais colocados em CACHE para depois serem acessados, agora todos os dados já estão em memória todo o tempo e com isso a forma com que os índices são armazenados e como o SQL Server lida com as concorrências são tratados de uma forma totalmente diferente dentro do “Hekaton”.

Durante a criação de um banco de dados utilizando o “Hekaton”, o mesmo deve estar em um FILEGROUP diferente chamado de MEMORY_OPTIMIZED_DATA. Após a criação do banco de dados, a criação das tabelas dentro desse FILEGROUP se difere somente pela especificação MEMORY_OPTIMIZED = ON. Após isso temos duas especificações necessárias de DURABILIDADE (DURABILITY) – SCHEMA_AND_DATA ou SCHEMA_ONLY.

SCHEMA_ONLY – Com isso qualquer alteração que houver na tabela não será logada a os dados não serão persistidos em disco, porém o schema ou seja a estrutura sim é persistida , após um restart no SQL Server ou no servidor a tabela estara com a estrutura porém vazia.

SCHEMA_AND_DATA – Todas as informações são logadas e persistidas em disco.

Além disso os modos de isolamentos SNAPSHOT, REPEATABLE READ e SERIALIZABLE são suportados para as tabelas do “Hekaton”. O que é importante notar é que veremos que esse recurso quebra diversos paradigmas e com isso nos faz pensar em uma novo modo de lidar com os dados dentro dos nossos bancos de dados. Eu tive o prazer de ver Sunil Agarwal  inserir 5 milhões de registros em menos de 2 segundos, como isso realmente possível? Eu irei explicar mais detalhadamente o “Hekaton” nos proximos posts, com isso iremos entender que a forma com que os registros são armazenados, gravados e logados faz com que a velocidade seja altamente aplificada.

O que muitas pessoas não entendem é que podemos possuir uma tabela toda em memória que é, alocar toda ela no CACHE, porém dentro de um índice  B-TREE temos níveis e por mais que seja efetivo, buscar grandes quantidades de registros se torna uma operação custosa. O que o “Hekaton” faz é otimizar a tabela dentro da memória ou seja assim não possuímos mais uma B-TREE mais sim Hash Indexes que faz com que a busca do dado seja muito mais efetiva.

O que realmente devemos perceber é que, nesse próximo ano veremos mudanças significativas não somente no SQL Server 2014 mais sim em diversos conceitos que nos pareciam impossíveis de serem lidados serem totalmente eliminados com o “Hekaton”.