Otimizando a performance com in memory no sql 2016

SQL Server 2016: In-Memory OLTP
Otimizando a performance
usando In-Memory OLTP
no SQL Server 2016
Felipe de Assis
@felipespas | DataEX
Felipe.assis@outlook.com
Luiz Henrique Garetti
@luizhgaretti | Microsoft
luizh.rosario@gmail.com

PosConference – 09/10 – SP
Local:
Microsoft Brasil – SP
Inscrições:
http://tinyurl.com/SQLSat570

Felipe de Assis
 Consultor SQL Server na DataEX
 Graduado em Ciência da Computação
 MBA em Arquitetura e Gestão de TI
 Articulista na SQL Magazine
 MCTS, MCITP, MCSA, MCSE e MCT
 Blog: felipedba.wordpress.com
 Email: felipe.assis@outlook.com

Luiz Henrique Garetti
 vPFE SQL Server na Microsoft
 Graduado em Ciência da Computação
 Pós-graduado em Arquitetura de BDs
 Colunista no site iMasters e SQL Magazine
 MCT, MTA, MCTS, MCSA
 Blog: lhgaretti.wordpress.com
 Email: luizh.rosario@gmail.com

Agenda
BEGIN TRANSACTION
1- Introdução ao In-Memory OLTP
2- Principais conceitos
3- Índices
4- Procedures Nativamente Compiladas
5- Transaction Log
6- Migrando Disk Based para Memória
7- Cases Reais
COMMIT TRANSACTION

DEMONSTRAÇÃO
Afinal de contas, do que estamos falando?
Qual o potencial do In-Memory OLTP?
Referência: https://msdn.microsoft.com/en-us/library/dn133171.aspx

Introdução ao In-Memory OLTP
 Funcionalidade disponível a partir do SQL Server 2014
 Processamento transacional de altíssima performance
 Mecanismos de funcionamento totalmente repensados
 Novo conceito de armazenamento de dados
 Modelo otimista de concorrência
 Implantação praticamente transparente às aplicações
 Integrado com os principais recursos do SQL Server

Overview da arquitetura
DatafileLogfileIn-Memory FG
tabelas e índices in-memory query
interop
tabelas e índices disk-
based
execução de queries t-
sql
parser,
catalog,
optimizer
Compilador
in-memory
SPs nativamente
compiladas
tds handler
T1 IX1
T1 IX1T1 IX1
T2 IX2
T2 T2
• Disk-Based
• In-Memory
• Interop

Estrutura de arquivos In-Memory OLTP
CREATE DATABASE [Corporativo]
ON PRIMARY
(NAME = N‘Copor1',FILENAME = N'C:DataCoporrativo1.mdf'),
FILEGROUP [Hekaton_InMemory]
CONTAINS MEMORY_OPTIMIZED_DATA
(NAME = N‘Corp2', FILENAME = N'C:DataMemCorp2')
LOG ON (NAME = N‘Corp_log', FILENAME =
N'C:DataLogCorplog.ldf')
Filegroup Container
Create
Table
DDL
Code
Generated
and
Compiled
Table
DLL is
created
Table
DLL
loaded in
memory

DLLs geradas pelo In-Memory OLTP
Database ID
Module Loaded
sys.dm_os_loaded_modules
Object ID
Table

Tipos de Tabela In-Memory OLTP
 Dois novos tipos de tabelas:
 SCHEMA_ONLY
 Somente estrutura da tabela é persistida
 Índice requerido
 SCHEMA_AND_DATA
 Estrutura e dados da tabela são persistidos
 Dados são persistidos em arquivos chamados
Checkpoint Files (Filegroup In-Memory)
 Constraint Primary Key requerida

Criando tabelas otimizadas em memória
CREATE TABLE Example01_Data
(
Codigo INT NOT NULL IDENTITY,
Nome VARCHAR(100) COLLATE Latin1_General_100_BIN2 NOT NULL,
DataNasc DATETIME NOT NULL,
Endereco VARCHAR(100) NOT NULL,
Cidade VARCHAR(100) NOT NULL,
CONSTRAINT PK_Example01_Codigo
PRIMARY KEY NONCLUSTERED HASH (Codigo)
WITH (BUCKET_COUNT = 100),
INDEX IX_Nome NONCLUSTERED (Nome)
) WITH( MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA )
GO
Pré-requisito
para indexar
colunas do
tipo texto no
SQL Server
2014
Definição da Tabela como
Memory Optimized
Durabilidade:
SCHEMA_AND_DATA ou SCHEMA_ONLY
Índice na coluna Nome
Pré-Requisito:
Primary Key

Como funciona o armazenamento de dados
da maneira tradicional (Disk-Based)?
Buffer Cache
Data
Page
8KB
Data
Page
8KB
Index
Page
8KB
Buffer Buffer Buffer
Data
Page
8KB
Data
Page
8KB
Index
Page
8KB
Buffer Buffer Buffer
Data
Page
8KB
Data
Page
8KB
Data
Page
8KB
Buffer BufferBuffer
Data
Page
8KB
Data
Page
8KB
Index
Page
8KB
Buffer BufferBuffer
Datafile(s) mdf ou ndf
Data
Page
8KB
Data
Page
8KB
Data
Page
8KB
Index
Page
8KB
Data
Page
8KB
Data
Page
8KB
Data
Page
8KB
Index
Page
8KB

Como funciona o armazenamento de dados
no In-Memory OLTP?
 In-Memory OLTP
não utiliza páginas
e extents
 Registros são
armazenados
individualmente
 Índices são
utilizados para
conectar registros
da mesma tabela
Memória
Row 1
Row 2
Row 3
Row 4
Row 5
Row 6
Row 7
Row 8
Tabela A
Tabela B

Estrutura dos registros em memória
End Ts StmIdBegin Ts IdxLinkCount
{
8 bytes
{
{
4 bytes
{2 bytes
Padding
Index
Pointers
8 bytes
Row Header Payload
8 bytes
(por índice)
{
2 bytes
{
 Cada registro possui seu próprio cabeçalho

Persistência de dados no In-Memory OLTP
Codigo Nome Disciplina
1 Neymar Ed. Física
Memória
Checkpoint
Files
Disco
2 Gabriel Jesus Teologia
3 Gabigol Psicologia Checkpoint
Thread
Codigo Nome Disciplina
1 Neymar Ed. Física
2 Gabriel Jesus Teologia
3 Gabigol Psicologia
Inserts
Deletes
3
Data Files Delta Files
 Tá bom! Então tudo é armazenado em memória...
E se o servidor cair?

Novos tipos de índices In-Memory
 Hash Indexes
 Ideal para consultas que:
 Recuperam registros específicos (lookups)
 Procuram registros usando igualdade (=)
 Pesquisas em colunas com alta cardinalidade (poucos
valores repetidos)
 Funcionamento diferente em relação à queries com
filtros compostos (mais de um predicado)
 Memória alocada previamente, no momento da
criação da tabela/índice
 Necessário pré-definir a quantidade de Hash Buckets
que serão criados

Exemplo: Hash Indexes na coluna “nome”
1
0
3
2
5
4
7
6
Neymar Ed. Fisica60, ...
Index Pointer NameTimestamps Class
Gabigol Psicologia7, ...
Array de Ponteiros (Buckets)
Gabriel Jesus Teologia7, ...
RowChain
SELECT * FROM Clientes WHERE CPF = @CPF

 Range Indexes
 Ideal para consultas que:
 Pesquisam por intervalos de registros
 Utilizam predicados como >, <, >=, <=, BETWEEN, etc.
 Quantidade de registros é desconhecida
 Baseado em uma variação de árvore balanceada
conhecida como BW-Tree
 Único “elemento” do In-Memory Engine que usa
o conceito de páginas, mas ainda sim, funciona
diferente do tradicional (disk-based)

Exemplo: Range Index na primeira letra
1
3
4
5
6
Page Mapping TabIe
(Memory Addresses)
2
7
8
AE
ABCD EFG
HK
HIJ KLMNOP
GPZ
QV
QRSTU VWXYZ
PID2 PID1 PID3
Root
PID0
0 Novo Conceito:
BW-Tree
M
M
M
M
Data Rows
(Chain)
SELECT * FROM Pedidos WHERE DataPedido > @Data

 Columnstore Indexes
 Novidade no SQL Server 2016
 Utilizado apenas por consultas interop
 Procedures nativamente compiladas não fazem uso
 Queries interop podem fazer uso do paralelismo e do
modo de processamento batch de forma mais eficiente
 Podem ser considerados “nonclustered” porque
geram uma cópia adicional dos dados
 Podem consumir entre 10% e 100% da
quantidade de memória alocada para a tabela

Exemplo: Criando um Columnstore Index
CREATE TABLE dbo.OrderDetailsBig
(
PedidoID INT NOT NULL
,ProdutoID INT NOT NULL
,PrecoUnitario MONEY NOT NULL
,Quantidade SMALLINT NOT NULL
,Desconto MONEY NOT NULL
,CONSTRAINT PK_Order_Details
PRIMARY KEY NONCLUSTERED HASH (OrderID,ProductID)
WITH (BUCKET_COUNT = 1000000)
,INDEX clcsi_OrderDetailsBig CLUSTERED COLUMNSTORE WITH
(COMPRESSION_DELAY = 60)
)
WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA);
Criação do Índice Columnstore
Compression_Delay:
Periodicidade de compressão

DEMONSTRAÇÃO
Hash Indexes vs Range Indexes

Procedures Nativamente Compiladas
• T-SQL Compilado em DLLs (C++)
• Executado em baixo nível (Linguagem de Maquina)
• Somente para tabelas In-Memory – Oferece maior
performance e não permite interoperabilidade.
• T-SQL com limitações
In Memory
OLTP
Runtime
In Memory
OLTP
Compiler
DLL
Parser /
Algebrizer
Query
Optimizer
Query
Plan
Query
Tree
CREATE PROC
DDL
(T-SQL)

CREATE PROCEDURE [dbo].[InsertOrder]
(@id INT, @date DATETIME)
WITH
NATIVE_COMPILATION,
SCHEMABINDING,
AS
BEGIN ATOMIC
WITH
(TRANSACTION ISOLATION LEVEL = SNAPSHOT,
LANGUAGE = N'us_english')
-- Insert T-SQL…
END
Procedures Nativamente Compiladas
Identifica que a Procedure será
Nativamente Compilada em Memoria
Requerido
Transações >
Operações.
Isolation Level e Idioma
precisam ser definidos
no início da procedure

Uso do Transaction Log
T1 IX1 T2 IX2
UPDATE Example01
SET Descricao = 'Novo Valor'
WHERE Codigo = 1
Disk-Based In-Memory
In-Memory FG
Data Delta
In-Memory Checkpoint
- Transações In-Memory são
registradas no mesmo TLOG
- Apenas transações
confirmadas (commit) são
registradas
- Escrita mais eficiente obtida
através de compressão

DEMONSTRAÇÃO
Utilização do Transaction Log
em Tabelas In-Memory

Migrando tabelas Disk-Based para In-Memory

DEMONSTRAÇÃO
Table Usage Analysis
Migrando para In-Memory OLTP

Case – Shock Absorber
 Após mudar a arquitetura para utilizar in-memory (em
uma implementação conhecida como Shock Absorber)
o limite de throughput de envio de SMS passou de 1000
SMS/hora para 850 mil SMS/hora.
 Impacto positivo de 450%
na receita da empresa.

Case – Tabela Schema_Only
Procedure
de Insert
AVG Time
(2 Sessões paralelas)
Média CPU
(micro seg)
Disk-Based T-SQL 4025 ms 1.974.912
In-Memory T-SQL 708 ms 366.233
Onde:
Empresa de
processamento
de transações
de crédito.
Resultado:
Throughput de
processamento
otimizado em
mais de 400%.

OPCIONAL: DEMONSTRAÇÃO
Particionamento Lógico de Tabelas
usando In-Memory OLTP
https://msdn.microsoft.com/en-us/library/dn133171.aspx

Algumas referências...
White Paper: SQL Server 2016 CTP 3 In-Memory OLTP Internals
http://sqlblog.com/blogs/kalen_delaney/archive/2016/01/19/sql-server-2016-ctp3-in-
memory-oltp-internals-whitepaper.aspx
Book: SQL Server Internals: In-Memory OLTP
http://www.red-gate.com/library/sql-server-internals-in-memory-oltp
Shock Absorber
https://blogs.technet.microsoft.com/dataplatforminsider/2013/09/19/in-memory-oltp-
common-design-pattern-high-data-input-rateshock-absorber/
Calling Native Compiled Procedures Best Practices
http://sqlperformance.com/2015/06/t-sql-queries/how-not-to-call-hekaton-procedures
Felipe de Assis – Série sobre In Memory OLTP
https://felipedba.wordpress.com/category/in-memory-oltp

Não abordamos por limitações de tempo...
 Funções In-Memory (msdn): http://tinyurl.com/ztt33ho
 Isolation Levels (msdn): http://tinyurl.com/hh24e7u
 Checkpoint Files (msdn): http://tinyurl.com/gl47x56
 Constraints (Pinal Dave): http://tinyurl.com/jgxdalc
 Garbage Collector (msdn): http://tinyurl.com/hx6wbts
 Monitoração (Murilo Miranda): http://tinyurl.com/jfxmo38
 Resource Governor (msdn): http://tinyurl.com/zdhzvce
 Modelo otimista de concorrência (P. Dave): http://tinyurl.com/hn5oyqr

Otimizando a performance com in memory no sql 2016

Otimizando a performance com in memory no sql 2016

Mais conteúdo relacionado

Mais procurados (20)

Destaque (20)

Semelhante a Otimizando a performance com in memory no sql 2016 (20)

Mais de Luiz Henrique Garetti Rosário (14)

Otimizando a performance com in memory no sql 2016

Notas do Editor