E o In-memory OLTP do SQL Server? Como funciona?


O SQL Server foi concebido numa época em que se podia presumir que a memória principal do hardware era muito cara. Por isso os dados precisavam residir no disco, exceto quando eram realmente necessários para processamento. Esta hipótese não é mais válida, já que os custos com memória caíram muito nos últimos 30 anos. Ao mesmo tempo, os servidores multi-core tornaram-se acessíveis, de modo que hoje se pode comprar um servidor com 32 núcleos e 1 TB de memória por menos de US $ 50 mil.

É sabido que os maiores sistemas de varejo e de companhias aéreas tem hoje entre 500GB e 5TB de storage. Assim, uma vez que muitos dos bancos de dados OLTP em produção, em média, cabem inteiramente em 1TB, precisamos reavaliar o benefício do armazenamento de dados em disco e quanto isso incorre no consumo de I / O, quando os dados precisam ser lidos na memória para serem processados. Além disso, os bancos de dados OLTP também consomem I / O quando esses dados são atualizados e precisam ser escritos de volta para o disco. Tabelas otimizadas em memória são armazenadas de forma completamente diferente das tabelas baseadas em disco e essas novas estruturas de dados permitem que os dados sejam acessados ??e processados ??de forma muito mais eficiente.

Devido a esta tendência da memória estar muito mais disponível e muitos mais núcleos surgindo em processadores cada vez mais potentes, a equipe de SQL Server da Microsoft começou a construir um motor de banco de dados otimizado para memória.

Como isso funciona?

O motor In-Memory OLTP é projetado para concorrência extremamente alta nas operações OLTP. Para isso, o SQL usa estrutura de dados latch-free com multi-versionamento no controle de concorrência. O resultado é previsível: eliminação da contenção, baixa latência, alto rendimento com escala linear e tudo isso com a garantia de durabilidade do dado. O ganho de desempenho real depende de muitos fatores, mas comumente vemos melhorias na ordem de 5 a 20 vezes.

A maioria dos sistemas especializados, incluindo os de CEP (Complex Event Processing), DW / BI e OLTP, otimizam as estruturas de dados e algoritmos concentrando-se em estruturas na memória! Assim é importante estarmos ligados nas tecnologias que temos à nossa disposição para cada um desses cenários.  

Voltando a traçar um paralelo com a parte de hardware, a partir de 2012, até mesmo um servidor de dois soquetes poderia prender 2 TB de DRAM usando DIMMs de 32GB (como IBM x3680 X5). Portanto, olhando para o futuro, certamente teremos sistemas de DRAM distribuídos com capacidade de 1-10 Petabytes a um custo inferior a US $ 5 / GB. É apenas uma questão de tempo antes do RAM não volátil torna-se viável.

Mudado o cenário dos dados bem como do hardware que o hospeda, as regras de custeio que o otimizador SQL Server tem usado desde a primeira versão ficam obsoletas.. Ter por exemplo todas as páginas de dados acessadas para ler apenas parte da informação, exige leitura física de disco desnecessária, ocupação de espaço, também desnecessário, de RAM, e ainda aumenta o tempo de processamento.Da mesma forma, a espera do término da escrita de log para então passarmos para a próxima instrução, causa um grande delay...  O In-Memory da Microsoft, tanto para OLTP quando para DW, aborda todas essas questões de acordo com a necessidade do cenário analisado.

Em síntese

O In-Memory OLTP (antigo projeto "Hekaton") é um novo e embutido componente do banco de dados SQL Server. Ele acessa dados residentes na memória e alcança melhorias significativas no desempenho e trazendo redução do tempo de processamento. Tabelas otimizadas em memória são totalmente transacionais e podem ser acessadas usando o Transact-SQL convencional. Alias, o Transact-SQL para store procedure pode ser compilado para o código de máquina culminando em mais ganhos de desempenho ! Este engine é projetado para alta concorrência e bloqueio é mínimo.

Quer saber mais?

Acesse aqui: In-Memory OLTP (In-Memory Optimization)


Comments (2)

  1. Sergio Tavares says:

    òtimo post, muito explicado.

Skip to main content