Base de memória - Linux Magazine

ANÁLISE | Memória principal em sistemas de bancos de dados
Memória principal em sistemas de bancos de dados
ANÁLISE
Base de memória
Graças ao hardware poderoso, bancos de dados em memória introduzem
uma revolução no mercado, ao lidar com transações e avaliações em
alta velocidade sem acessar dispositivos de memória em massa.
por Alfons Kemper e Thomas Neumann
S
istemas de gerenciamento de
banco de dados em memória,
tais como o TimesTen da Oracle [1] e o solidDB da IBM [2], já
existem há algum tempo. Estes sistemas mantêm todo o conjunto de
dados na RAM, e desta forma removem a necessidade de fazer paginação
entre o buffer de memória principal
e o disco rígido, como é o caso dos
antigos SGBDs. Contudo, os sistemas
de banco de dados em memória – até
agora – tendem a ser produtos-nicho
para aplicativos especiais.
Massas de memória
O progresso do hardware mudou tudo
isso. Os servidores atuais têm acima
de 1TB de RAM e múltiplos núcleos, e novos algoritmos e estruturas de
dados para o eficiente processamento
de dados na RAM já estão em uso
juntamente com cache eficiente de
estruturas de dados de registro, como
PAX ou armazenamento de colunas,
compressão e cache eficiente de estruturas de índice. Os SGBDs em
memória provavelmente irão tornar-se
ainda mais importantes se considerarmos o seguinte: as empresas de hoje
podem comprar servidores relativamente baratos, com uma capacidade
RAM de mais de 1TB por menos de
50 mil dólares. Estes servidores contam com processadores de múltiplos
núcleos capazes de executar várias
tarefas em paralelo. A capacidade é
suficiente para armazenar os dados
transacionais da empresa, mesmo os
60
maiores – não estamos considerando
dados de multimidia aqui, mas dados
para operações de missão crítica.
Por exemplo, observe os dados de
encomendas de uma loja como a
Amazon. Em 2011, a Amazon gerou
um volume de negócios em torno de
48 bilhões de dólares [3]. A um preço médio do produto de 25 dólares, a
empresa armazena assim cerca de 2
bilhões de itens de pedidos, cada um
dos quais geralmente representado
por menos de 100 bytes de dados. Isso
gera um volume de armazenamento
de aproximadamente 200GB – que facilmente se encaixa em 1TB de RAM.
Este cálculo não leva outras operações
(clientes, produtos etc.) em consideração, mas também não considera as
opções de compressão. Alternativamente, uma grande empresa pode
criar um banco de dados distribuído
e particionado em um cluster.
Empresas iniciantes
neste ramo
Os avanços tecnológicos em hardware de servidor levaram à criação de
muitas empresas iniciantes na área de
SGBD em memória: VoltDB [4], Clustrix, Akiban, db-Shards, NimbusDB,
ScaleDB, Lightwolf e ElectronDB,
para citar apenas alguns dos melhores exemplos conhecidos. Também
as grandes corporações, tais como a
SAP (NewDB/Hana [5]) e a IBM
(ISAO/Blink [6]) estão investindo
pesadamente neste ramo de negócio.
Em muitos casos, estes novos desenvolvimentos dependem de sistemas
de banco de dados de código aberto,
como MySQL ou PostgreSQL como
base para suas otimizações de memória
principal. Além das edições comerciais
para empresas, os fornecedores geralmente oferecem também uma versão
gratuita que tem menos recursos. O
VoltDB, por exemplo, está disponível
sob a licença GPLv3. Os sistemas de
banco de dados em memória anteriores
foram concebidos para casos de uso
específico: ou para processamento de
transações online (OLTP), processamento eficiente de transações, ou
ainda processamento analítico online
(da sigla OLAP, de Online Analytical
Processing). Argumentos convincentes,
no entanto, como aqueles apresentados
pelo fundador da SAP, Hasso Plattner
[7], assumem a posição de que esta
distribuição não suporta suficientemente as necessidades do usuário em
termos de inteligência de negócios (da
sigla BI, de business intelligence) em
tempo real.
Velhos conceitos
caem por terra
Hoje, a arquitetura de um banco de dados típico prevê principalmente o gerenciamento de dados transacionais em um
sistema de banco de dados OLTP, que
sempre mantém o status mais recente.
A partir daí, um processo de extração,
transformação e carga (da sigla ETL,
de Extract Transform Load) transfere
www.linuxmagazine.com.br
Memória principal em sistemas de bancos de dados | ANÁLISE
o HyPer que combina os benefícios
de bancos de dados OLTP e OLAP.
O rendimento transacional do HyPer
é comparável a ou até melhor que sistemas OLTP dedicados (por exemplo,
o VoltDB) e, em termos de processamento de consultas OLAP, o HyPer
é comparável àqueles dedicados ao
armazenamento em coluna como o
MonetDB ou o Vectorwise [11]. ■
Mais informações
Figura 1 Visão geral de um SGBD em memória, otimizado para OLAP (esquerda) ou
OLTP (direita). Pouquíssimos oferecem o melhor de dois mundos (centro).
os dados para um sistema OLAP (de
depósito de dados, também chamado
de data warehouse). Esta operação pode
ocorrer apenas periodicamente – por
exemplo, à noite – por razões de carga.
Os sistemas anteriores não puderam,
por motivos de desempenho, executar
consultas OLAP diretamente nos dados
de sistemas OLTP.
Este processo está mudando por
conta da ascensão dos SGBDs em memória, conhecidos pela junção entre
bancos de dados OLTP e OLAP. Ambos
combinam as melhores propriedades
de ambos os mundos, como podemos
ver na figura 1. O seu processamento
de transação é tão rápido quanto o de
um banco de dados OLTP dedicado
(por exemplo, o VoltDB), e em termos de processamento de consulta,
eles são capazes de manter o controle
com engines de OLAPs dedicadas, tais
como o armazenamento em coluna
do MonetDB [8], Vertica, Vectorwise,
ou sistema IBM ISAO/Blink.
O HANA, desenvolvido pela SAP,
e o HyPer, da Universidade Técnica
de Munique [9], são provavelmente
os melhores representantes conhecidos de sistemas híbridos destinados à
inteligência de negócios operacional.
O Hyper é um SGBD em memória de
última geração que utiliza gerenciamento de memória virtual suportado
pelo hardware do sistema operacional
para gerenciamento de dados e sin-
Linux Magazine #94 | Setembro de 2012
cronização entre transações OLTP e
consultas OLAP.
O gerenciamento de dados “no núcleo” mapeia dados relacionais diretamente no espaço de endereço virtual do
processo OLTP, em qualquer direção,
através de um buffer controlado pelo
SGBD e sistema de gerenciamento de
paginação. Ele pode criar snapshots
(imagens do sistema) de transações
consistentes do banco de dados através
da ramificação de um novo processo
OLAP. O mecanismo de cópia e escrita
do sistema operacional e o processador
mantêm o snapshot consistente, replicando as páginas com a mudança de
objetos de dados.
Este método de snapshot é equivalente ao conceito de página-sombra
desenvolvido por Lorie em 1977 para
a IBM [10] – com a diferença de que
os snapshots de memória virtual não
sofrem de nenhum dos inconvenientes
do período: a fragmentação de memória não é um problema na RAM, e o
que costumava ser um caro aplicativo
de controle de gestão das cópias de
sombra é agora altamente eficiente na
abordagem de HyPer por ter o suporte
interno do processador.
Além disso, o gerenciamento de
memória virtual permite que seja mantido um número arbitrário de cópias
de sombra (tempo escalonado). Isto
torna possível a implementação de
um sistema de banco de dados com
[1] TimesTen: http://www.
oracle.com/timesten/
[2] solidDB: http://www-01.ibm.
com/software/data/soliddb/
[3] Relatório Anual de 2011 da
Amazon.com: http://phx.
corporate-ir.net/phoenix.
zhtml?c=97664&p=irolreportsannual
[4] VoltDB: http://voltdb.com/
[5] SAP HANA: http://www.sap.
com/solutions/technology/
in-memory-computingplatform/index.epx
[6] Blink: http://www.almaden.
ibm.com/cs/projects/blink/
[7] Plattner, Hasso e Alexander
Zeier. Gerenciamento de
Dados em Memória: um
ponto de inflexão para
aplicativos empresariais.
Springer-Verlag, 2011
[8] MonetDB: http://
www.monetdb.org/
[9] HyPer: http://www3.in.tum.
de/research/projects/HyPer/
[10] Lorie, R.A. Integridade
física em um grande banco
de dados segmentado.
TODS 1977;2(1):91-104
[11] Kemper, Alfons e Thomas
Neumann. HyPer - Sistema
Híbrido de Banco de Dados
OLTP e OLAP de Alto
Desempenho. Universidade
Técnica de Munique, relatório
técnico TUM-I1010, 2010,
http://www3.in.tum.de/
research/projects/HyPer/
HyperTechReport.pdf
Gostou do artigo?
o?
Queremos ouvir sua opinião.
ião.
Fale conosco em
[email protected]
ne.com.b
Este artigo no nosso
so site:
sit
http://lnm.com.br/article/7459
article 459
61