In-Memory a.k.a OLTP “Hekaton” – Deep Dives [3]

Posted on julho 29, 2013

0


Depois se ser mostrado como realizamos a criação das tabelas dentro do “Hekaton” – https://luanmorenodba.wordpress.com/2013/07/08/in-memory-a-k-a-oltp-hekaton-deep-dives-2/ agora iremos realizar uma pequena comparação entre “Disk-Based Tables” e “Memory-Optimized Tables”. Nesse exemplo possuímos a mesma tabela, a diferença é que uma está em disco e a outra em memória.

USE InMemoryDB

go

 

CREATE TABLE ExtratosPagamentos

(

       ID INT NOT NULL,

       Nome VARCHAR(300) NOT NULL,

       CPF CHAR(11) NOT NULL,

       Numr BIGINT,

       ValorBruto DECIMAL,

       ValorDesconto DECIMAL,

       ValorLiquido DECIMAL,

       DataPagamento DATETIME,

       DataRecebimento DATETIME,

       AgBanc VARCHAR(100),

       NomeBanco VARCHAR(300)

)

go

 

ALTER TABLE ExtratosPagamentos

ADD CONSTRAINT PK_ExtratosPagamentos_ID

PRIMARY KEY (ID)

 

go

 

CREATE TABLE InMemoryExtratosPagamentos

(

       ID INT NOT NULL PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = 1024),

       Nome VARCHAR(300) NOT NULL,

       CPF CHAR(11) NOT NULL,

       Numr BIGINT,

       ValorBruto DECIMAL,

       ValorDesconto DECIMAL,

       ValorLiquido DECIMAL,

       DataPagamento DATETIME,

       DataRecebimento DATETIME,

       AgBanc VARCHAR(100),

       NomeBanco VARCHAR(300)

) WITH (MEMORY_OPTIMIZED = ON , DURABILITY = SCHEMA_AND_DATA);

 

Verificando a quantidade de registros entre as tabelas….

SET STATISTICS TIME ON

SET STATISTICS IO ON

 

SELECT COUNT(*)

FROM ExtratosPagamentos

 

SELECT COUNT(*)

FROM InMemoryExtratosPagamentos

QuantidadeDB

(Figura 1 – Quantidade de registros nas duas tabelas.)

Ou seja, estamos falando da mesma estrutura e quantidade de registros, agora iremos realizar um SCAN para comparação entre as tabelas…

QuantidadeDB

(Figura 2 – Plano de Comparação SCAN.)

No primeiro plano de execução foi realizado um Clustered Index SCAN (Disk Based Table) e na segunda foi realizado um Nonclustered Hash SCAN (In Memory Table) ou seja 99% contra 1% aqui já vemos a grande eficiência da tabela “in-memory”.  Agora realizando um SEEK veremos que…

SELECT *

FROM DadosAtendimento

WHERE ID = 505

 

SELECT *

FROM InMemoryDadosAtendimento

WHERE ID = 505

QuantidadeDB

(Figura 3 – Plano de Comparação SEEK.)

Claramente vemos que são 95% da tabela em Disco contra 5% da tabela em memória, lembrando que é exatamente a mesma tabela com a mesma quantidade de registros ou seja o ganho de performance é extremamente alto.