Conhecendo o In-memory database na teoria para entender o SAP HANA

(1)

1

1 CI/OSR2-LA | 20/12/2013 | © Robert Bosch Ltda 2011. Todos os direitos reservados, incluindo–se qualquer traspasse, exploração, reprodução, edição, distribuição, assim como no caso de pedidos de direitos de propriedade industrial.

SAP FORUM 2014 – In-memory database / HANA

Conhecendo o

In-memory database na teoria para

entender o SAP HANA

Heitor Lourenço Jr

(2)

Motivação para um banco em memória

 Lei de Moore – duplicar capacidade CPU cada 2 anos

 Chegou-se ao limite da física – camadas em nível atômico

 Dispersão calor

 5 Ghz IBM refrigeração líquida – mercado entre 2 e 4 Ghz

 CPUS com vários cores

 Disco não evoluiu tanto quanto CPU

 Interface memória - disco

 Custo IO físico imensamente maior que memória

(3)

3

In-Memory – a que se propõe

 Não somente banco de dados na memória

 Eliminação IO físico

 Processador com características próprias para acesso à memória

 Maior desenvolvimento latência CPU – memória

 3 níveis de cache além de registradores

 Mínima movimentação de dados e/ou instruções

 Alinhamentos

(4)

SAP FORUM 2014 - In-memory database / HANA

Comparação de acessos a dados

 Acesso à memória principal – 100 ns

 Ler 1 Mbytes sequenciais da memória – 250.000 ns

 Seek do disco – 5.000.000 ns

 Ler 1 Mbytes sequenciais do disco 30.000.000 ns

Uma comparação com a vida atual seria, ao se querer um café, o acesso a memória iria até a cozinha. Por outro lado, o acesso ao disco seria pegar um avião e ir à Europa para pegar o café.

(5)

5

Breve história que levou ao HANA

 Trex

 BWA

 HANA

(6)

A que o HANA se propõe

 Toda base em memória - constrained

 Compressão aproximada de 4 vezes a atual

 Processadores próprios Intel X7 e memória Samsung

 Persistência dos dados

 Código direto na base – procedures SQLScript

 Revisão de códigos que usavam bypasses para performance

 Eliminação DW

 Eliminação de índices

(7)

7

A que o HANA se propõe (continuação)

 10, 100, 1.000 vezes mais rápido, depende de implementação

 Uso de tabelas row e column oriented

 Possibilidade de atualização de columnar tables devido ao processo de merge

 Migração total ou side-by-side

 Alguns processos críticos já contemplados no side-by-side (i.e. COPA)

 HANA Studio

 Big Data – text processing

(8)

Sizing aproximado de um banco HANA

 Base dividida por 4 vezes 2 – área de computação

 Conforme bases crescem deve crescer memória real (scale up– out)

 Venda em appliance fechado na base de T-shirt (S, M, L etc) SUSE Linux – Processador Xeon E7 – Memória Samsun (IBM, HP, Hitachi etc). Storage sem restrição

(9)

9

O que está contemplado no HANA ou por vir

 Suite (ERP, CRM) desde início 2013

 Interface com ferramentas de backup (TSM disponível agora)

 Sem proposta de High Availability concreta ou integração ferramentas BR

 Scale up limitado ao tamanho de appliance liberado (2 Tbytes com estudos de mais)

 Sem scale out para Suite

 Licenciamento com base de tamanho e não usuários

(10)

Futuro de banco de dados

 Desenvolvimentos mais e mais em HANA

 Primeiro passo, primeiro a estar “lá”

 Devido a limitações físicas, deve ser o futuro

 Alguns anos até estabelecer-se como padrão

O que o mercado oferece em termos de In-memory

 IBM DB2 10.5 BLU Acceleration

 Oracle 12c

 MS/SQL 2014 Hekaton

(11)

11

BIBLIOGRAFIA

 SAP HANA: an introduction

 SAP HANA: a starter

 SAP HANA Essentials

 SAP HANA Certified Technology

 In-memory computing with SAP HANA on IBM eX5 – IBM Redbook

 The SAP HANA Project Guide

 In-memory Data Management

 A Course in In-Memory Data Management: The Inner Mechanics of In-Memory Database

 Hasso-Plattner-Institute Potsdam – gravação de palestras

 Cursos e certificações oficiais SAP

[email protected]