solidDB e os segredos da velocidade

Como o banco de dados em memória da IBM redefine alto desempenho

Veja os segredos técnicos dentro do IBM solidDB

Antoni Wolski, Chief Researcher for solidDB product family, IBM

Antoni Wolski é chief researcher da solidDB. Com mais de 20 anos de atividade em tecnologia de banco de dados, contribuiu com soluções, produtos, pesquisa, patentes e trabalho literário no campo.



Sally Hartnell, IBM solidDB Product Marketing Leader, IBM

Sally Hartnell juntou-se à IBM com a aquisição da Solid Information Techology, e continua responsável pelo marketing mundial do IBM solidDB.



05/Mar/2010

Leia este artigo em nosso formato de edição digital interativa!

Um banco de dados relacional na memória, o IBM solidDB é usado em todo o mundo pela sua capacidade de fornecer velocidade e disponibilidade extremas. Como o nome implica, um banco de dados na memória reside inteiramente na memória principal e não no disco, tornando o acesso aos dados uma ordem de magnitude mais rápida que com bancos de dados convencionais, baseados em disco. Parte desse salto é devido ao fato que a RAM simplesmente fornece um acesso aos dados mais rápido que unidades de disco rígido.

Mas o solidDB também tem estruturas de dados e métodos de acesso projetados especificamente para armazenar, pesquisar e processar dados na memória principal. Como resultado, seu desempenho é superior aos bancos de dados comuns baseados em disco, mesmo quando têm os dados completamente armazenados em cache na memória. Alguns bancos de dados entregam uma baixa latência, mas não podem tratar grandes números de transações ou sessões concorrentes. O IBM solidDB fornece rendimento medido na faixa de dezenas a centenas de milhares de transações por segundo, conseguindo tempos de resposta (ou latência) consistentemente medidos em microssegundos. Este artigo explora as diferenças estruturais entre bancos de dados em memória e baseados em disco, e como o solidDB trabalha para entregar velocidade extrema.

Um pouco de história de RDBMS

Quando os primeiros sistemas de gerenciamento de dados apareceram nos anos 60, as unidades de disco eram o único lugar para armazenar e acessar grandes quantidades de dados em um tempo razoável. Os projetistas de RDBMS se concentraram na otimização de E/S e tentaram alinhar os padrões de acesso aos dados com a estrutura de blocos imposta pelas unidades. A estratégia de projeto frequentemente se concentrava em um buffer pool compartilhado, onde os blocos de dados eram mantidos para reutilização, enquanto que avanços nos métodos de acesso produziam soluções como a famosa árvore B+, que era um índice otimizado para blocos.

Enquanto isso, as táticas de otimização de consultas se concentravam em minimizar os acessos a páginas sempre que possível. Na feroz luta por desempenho, a E/S de disco era muitas vezes o inimigo mais perigoso, e a eficiência de processamento foi sacrificada para evitar os acessos ao disco. Por exemplo, com tamanhos de página típicos de 8 KB ou 16 KB, o processamento interno na página é inerentemente sequencial e menos eficiente em termos de CPU que o acesso aos dados randômico. Mesmo assim, permanece sendo uma maneira popular de reduzir acessos a disco.

Quando chegou a era da memória abundante, muitos DBAs aumentaram seus buffer pools até que se tornassem grandes o suficiente para conter um banco de dados inteiro, criando, dessa forma, o conceito de um banco de dados completamente armazenado em cache. Mas, dentro dos buffer pools de RAM, os DBMSs ainda eram reféns de todas as ineficiências estruturais da estratégia de E/S orientada a blocos que tinha sido criada para tratar unidades de disco rígido.


Indo além dos blocos

Uma das diferenças mais notáveis de um banco de dados em memória é a ausência de grandes estruturas de blocos de dados. O IBM solidDB os elimina. Linhas de tabela e nós de índices são armazenados independentemente na memória, de modo que os dados podem ser adicionados sem reorganizar grandes estruturas de blocos. Bancos de dados em memória também renunciam ao uso de índices de blocos grandes, denominados às vezes bushy trees, e usam estruturas leves onde o número de níveis de índice é maior e o tamanho do nó de índice e mantido o menor possível para evitar o custoso processamento interno do nó. A estratégia mais comum de índice de banco de dados em memória é denominada T-tree. Em vez disso, o IBM solidDB usa um índice denominado trie (ou árvore de prefixo), que foi criada originalmente para pesquisa de texto, mas mostra-se perfeita para indexação na memória. Um tri (o nome vem da palavra retrieval (recuperação)) é composto de uma série de nós, onde os descendentes de um determinado nó têm o mesmo prefixo da cadeia de caracteres associada a esse nó. Por exemplo, se a palavra "dog" fosse armazenada em um trie como um nó, descenderia do nó contendo "do", que descenderia do nó contendo "d".

Os índices trie aumentam o desempenho reduzindo a necessidade de comparações de valores de chaves e praticamente eliminando o processamento interno no nó. O índice contém um nó, que é uma pequena array de pointers para o nível mais baixo. Em vez de usar o valor de chave inteiro para percorrer a árvore efetuando comparações, o valor da chave é dividido em partes pequenas de alguns bits. Cada parte é um índice direto para a array de pointers do nível correspondente: a primeira parte à esquerda para os nós de primeiro nível, a segunda parte para os nós de segundo nível, e assim por diante. Dessa forma, a pesquisa completa pode ser executada com somente algumas recuperações de elementos de array. Além disso, cada nó de índice é um pequeno bloco de dados (aproximadamente 256 bytes no solidDB), o que é benéfico porque o bloco se encaixa precisamente em caches de processadores modernos, aumentando a eficiência de processamento ao promover o uso eficiente do cache. Pequenas matrizes de dados como essa são a estrutura de dados mais eficiente em processadores modernos, e o solidDB as usa com frequência para maximizar o desempenho.


Pontos de verificação e durabilidade: Caminhos para a velocidade

O IBM solidDB usa várias técnicas adicionais para acelerar o processamento de banco de dados, começando com um método de ponto de verificação patenteado que produz um ponto de verificação consistente em termos de captura instantânea sem bloquear o processamento normal das transações. Um ponto de verificação consistente em termos de captura instantânea permite que o banco de dados seja reinicializado somente a partir de um ponto de verificação. Outros produtos de bancos de dados não permitem isso - os arquivos de registro de transações devem ser usados para recalcular o estado consistente (o solidDB permite que o registro de transações seja desligado, se desejado). A solução solidDB é possibilitada pela capacidade de alocar imagens de linha e imagens-sombra de linha (diferentes versões da mesma linha) sem usar estruturas de bloco ineficientes. Somente as imagens que correspondam a uma captura instantânea consistente são gravadas no arquivo de ponto de verificação, e as sombras de linha permitem que as transações em execução no momento executem sem restrições durante o ponto de verificação.

Além disso, o otimizador de consultas do solidDB reconhece a natureza diferente de tabelas na memória, estimando os custos de execução de uma nova maneira. A otimização de consultas se concentra em caminhos de execução com uso intensivo de CPU, enquanto que um banco de dados completamente armazenado em cache ainda estará preocupado com a otimização de acessos a página para armazenamento de massa, que deixaram de ser um problema.

Outra técnica usada pelo IBM solidDB é o relaxamento da durabilidade da transação. No passado, os bancos de dados suportavam sempre a durabilidade completa, garantindo que os dados gravados fossem tornados persistentes no momento em que a transação fosse confirmada. O problema é que a durabilidade completa causa gravações síncronas de registro, e, portanto, consome recursos e reduz os tempos de resposta. Em muitas situações, aceitar a duração menor para algumas tarefas para obter tempos de resposta mais rápidos é um compromisso perfeitamente aceitável. Com o solidDB, a durabilidade das transações pode ser relaxada em tempo de execução para uma determinada sessão de banco de dados, ou até para uma única transação.

O IBM solidDB também aumenta o desempenho do banco de dados ajudando os desenvolvedores a evitar a alternância de contexto de processos em interações cliente/servidor. Ao usar um driver de acesso a banco de dados fornecido com o solidDB e que contém o código de execução completo, um desenvolvedor pode efetivamente vincular o aplicativo com o código do DBMS e usar memória compartilhada para compartilhar os dados entre os aplicativos.

Quanto todas essas medidas são aplicadas e a carga do aplicativo é de um tipo que geraria E/S considerável em um banco de dados tradicional, o rendimento aumentado com o uso do solidDB pode ser maior em uma ordem de magnitude. Além disso, as melhorias de tempo de resposta são ainda mais dramáticas: as latências para transações de consulta são usualmente de 10 a 20 microssegundos, e as latências para transações de atualização são geralmente menores que 100 microssegundos. Em um banco de dados tradicional baseado em disco, os tempos correspondentes são tipicamente medidos em milissegundos.


Velocidade e poder do solidDB

Além dessas vantagens de desempenho, o solidDB também fornece vários benefícios adicionais. Ele combina um banco de dados totalmente transacional na memória e um banco de dados poderoso baseado em disco em uma solução única e compacta, com a capacidade de hospedar transparentemente parte do mesmo banco de dados em memória e parte em disco. E o IBM solidDB é o único produto no mercado que pode ser implementado como um cache de alta velocidade na frente de praticamente qualquer outro banco de dados relacional e baseado em disco (consulte a Figura 1). Finalmente, o solidDB entrega uma disponibilidade extrema, indo além dos cinco noves típicos até 99,9999% de disponibilidade. Em outras palavras, se você está procurando velocidade extrema, a terá, mas isso é apenas o começo para o IBM solidDB.

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Information Management
ArticleID=472266
ArticleTitle=solidDB e os segredos da velocidade
publish-date=03052010