Oracle In-Memory: Introdução

Olá pessoal, aqui venho trazer uma breve introdução sobre o recurso Oracle In-Memory, disponível a partir da versão 12.1.0.2 do Oracle Database.

O objetivo é abordar brevemente este conteúdo para que possamos dar continuidade no conteúdo nos próximos artigos.

Contextualização

De alguns anos para cá vimos um tendência crescente na área de análise de dados em tempo real. Hoje o ambiente analítico não é mais como antigamente, muita coisa não é mais como antigamente…

Apesar de ainda hoje encontrarmos muitos ambientes de DataWarehouse sendo armazenados em HDDs, esta não é a tendência de futuro, nem os SSDs são, pois ainda são muito lentos para atingir o processamento Online ou Real Time que tanto se fala nos dias atuais. Então como podemos fazer para que estes ambientes tenham o desempenho desejado?

No contexto moderno da computação analítica falamos de processamento em massa diretamente na memória RAM/DRAM (Dynamic RAM). Para isso precisamos extrair o máximo de benefícios dela e é aí que entra o recurso In-Memory Column Store do Oracle Database.

Oracle In-Memory

O Oracle In-Memory Column Store exige alguns recursos de hardware para que possa ser eficientemente utilizado, são eles: Servidores com uma boa quantidade de cores para processamento paralelo, SIMD e é claro bastante RAM disponível.

Os dados são armazenados em forma de linha no Buffer Cache do Oracle Database e isso é chamado de Row-Major Format. Este tipo de armazenamento funciona muito bem para ambientes OLTP onde há uma grande quantidade de DMLs concorrentes e queries que consultam poucas linhas.

Row-Major Format

Row-Major Format

Tratando-se de ambientes analíticos, normalmente temos um grande volume de dados que serão consultados e também agregados por apenas algumas colunas e é nesse meio que o In-Memory Column Store tira vantagem, pois o armazenamento acontece de maneira colunar na In-Memory Area, a qual também faz parte da SGA.

Column-Store Format

Column-Store Format

Observe as duas maneiras de armazenamento e compare uma seleção onde você quer saber quantos pedidos do produto 32 estão com o status E. No modelo Row-Major você teria que ler todas as linhas da tabela que contém o produto 32 e o status E. Já no modelo Column-Store você precisa ler somente as “linhas” (colunas transpostas) referente ao produto e ao status ao invés de ler todas as demais colunas.

format

Vamos ver nos próximos artigos como isso se torna muito mais rápido para consultas analíticas.

Podemos armazenar tabelas e partições de tabelas na In-Memory Area usando IMCS. Estes objetos podem ser armazenados somente In-Memory ou em Dual Format, podemos ainda priorizar os objetos que queremos ter mais benefícios com o recurso IMCS e também comprimí-los para economizar recursos. É possível também que possamos nos desfazer de índices que não serão mais necessários nestas queries analíticas.

Veja abaixo como a In-Memory Area é populada quando um usuário efetua uma seleção:

  1. O usuário efetua um select em uma tabela propensa a usar o recurso IMCS;
  2. Se os dados ainda não estiverem no Buffer Cache, o Oracle irá ler o disco e colocá-los lá;
  3. Se houver espaço suficiente na In-Memory Area estes dados serão armazenados no formato colunar e então comprimidos;
  4. Quando o usuário solicitar novamente estes dados o Oracle irá descomprimí-los e devolvê-los a partir do IMCS;
  5. Caso estes dados ainda não estejam todos populados no IMCS, os dados serão retornados a partir do Buffer Cache.

Quando uma tabela já estiver no IMCS, então a ordem será consultar o dado de lá, senão do Buffer Cache, senão do disco.

Arquitetura do Oracle In-Memory

Alguns termos devem ser esclarecidos quando falamos sobre Oracle In-Memory:

  • IMCS: In-Memory Column Store é a área da In-Memory Area que armazena os IMCUs;
  • IMCU: In-Memory Compression Units ao invés de blocos, é uma área Read-Only;
  • IMEU: In-Memory Expression Unit é uma área de armazenamento para In-Memory Expressions e colunas virtuais;
  • SMU: Snapshot Metadata Unit é o Transaction Journal que mapeia quais IMCUs sofreram alteração no Buffer Cache e precisam ser atualizados no IMCS.
Oracle In-Memory

In-Memory Area

Ao efetuarmos um select na view v$inmemory_area veremos dois pools:

  • 1MB Pool: é o pool dos dados (Columnar Data Pool)
  • 64KB Pool: é o pool dos metadados (Metadata Pool)

Alguns processos são envolvidos na operação da In-Memory Area:

  • IMCO: In-Memory Coordinator é responsável por disparar a população dos dados no Columnar Data Pool;
  • SMCO: Space Management Coordinator: é responsável por coordenar os worker processes no que tange ao gerenciamento de espaço.
  • Wnnn: Space Management Worker: é responsável por popular e repopular dados no Columnar Data Pool e também cria os IMCUs, SMUs e IMEUs.

Vimos alguns componentes do Oracle In-Memory e é bom que fique claro que a In-Memory Area não é um cache de dados. Para auxiliar quem está começando o In-Memory Advisor verifica os melhores objetos para serem incluídos na In-Memory Area. O Oracle In-Memory é uma option paga a parte e disponível somente para o Oracle Database Enterprise Edition.

Por hoje é isso pessoal, espero que tenham gostado desta breve abordagem sobre o Oracle In-Memory.

Abraços,

Franky

Referências

https://docs.oracle.com/database/122/INMEM/intro-to-in-memory-column-store.htm#INMEM-GUID-BFA53515-7643-41E5-A296-654AB4A9F9E7

  • Bom dia Eli!
    Obrigado pelo comentário. Acredito que possa não ter tido o efeito esperado, nem todas as queries de ambientes OLTP vão se beneficiar do In-Memory. Ele realmente faz diferença num ambiente OLAP. Vou realizar alguns testes nesse sentido também e devo publicar aqui no blog em breve.

  • Eli Dias

    Bom dia.

    Ótimo artigo! Queria compartilhar que fiz um teste com uma aplicação OLTP e o in-memory não foi eficiente, o tempo de resposta caiu mas nada significativo, mesmo acabando com os índices das tabelas.