O Exadata é a Resposta Definitiva? – Parte 1

Me lembro até hoje quando participei do Oracle Open World 2008 na qual foi feito o lançamento do Exadata Database Machine. Foi uma ação conjunta com a HP, que logo em seguida ficou a ver navios em função da aquisição da Sun Microsystems pela Oracle. A partir daí o equipamento passou pela evolução tecnológica (?) normal de esperada para qualquer produto, sendo que a estrutura básica se manteve até os dias de hoje.

De uma forma simplificada, o Exadata Database Machine é um equipamento baseado no que se chama de hardware commodity pelo fato de seus componentes serem facilmente encontrados nas “prateleiras”, ou seja, não há nenhum componente especial.

A sua composição física na sua configuração full rack é basicamente:

• Um rack com suas respectivas PDUs
• 8 servidores que são utilizados como servidores de banco de dados, possuindo discos somente para armazenamento do SO e binários do Oracle RDBMS
• 14 servidores que são utilizados como Exadata storage cells, possuindo discos e cartões de memória flash ou módulos de memória não-volátil nas versões mais recentes
• 2 ou mais switches Infiniband para conectividade entre os servidores
• 1 switch GigE para administração da infraestrutura

Como ele se diferencia então da infraestrutura “tradicional” onde você escolhe e monta a sua infraestrutura de banco de dados?

No banco de dados nada muda. O Oracle RDBMS que é executado no Exadata é exatamente o mesmo que está disponível para download no site da Oracle. Porém, algumas funcionalidades somente funcionam quando se detecta os Exadata storage cells ou um storage Pillar através de sinalização SNMP. Falaremos sobre a real necessidade e eficiência destas funcionalidades mais adiante.

No armazenamento e conectividade houveram sim algumas mudanças. Se olharmos para a primeira versão do Exadata, lançado em conjunto com a HP, notamos que o seu foco primário foi os ambientes de Data Warehouse. De forma bem simplista, estes ambientes são caracterizados em geral por um grande volume de dados, onde as consultas precisam ler grandes tabelas para a obtenção das respostas desejadas. Sob o aspecto técnico, o objetivo sempre foi simples: ler mais dados em tempos cada vez menores. Para isso o software foi evoluindo ao longo das diferentes versões com funcionalidades como paralelismo (conhecido no passado como Parallel Query), partititoning, sub-partitioning (falarei sobre isso em outra oportunidade), bitmap index, materialized views, query rewrite, e outras funcionalidades. No entanto, uma boa parte dos DBAs não entendeu que a performance está ligada não somente ao uso correto destas funcionalidades, mas também ao dimensionamento correto da infraestrutura utilizada. De forma geral, a infraestrutura quase sempre estava sub-dimensionada para as demandas específicas destes ambientes, seja pela falta de discos suficientes ou pela reduzida conectividade entre storage e servidores. Ao lançar um appliance (ou Engineered System como a Oracle gosta de chamar), padronizou-se este dimensionamento para satisfazer aos requerimentos destes ambientes que necessitam transferir grandes volumes de dados armazenados para os servidores de banco de dados.

Mas isso é tudo? Não. Quando se executam consultas sobre as grandes tabelas fato as seguintes operações acontecem, entre outras:

1. Os dados são lidos dos discos
2. Os dados são transferidos via fabric (rede) de dados para os servidores de bancos de dados
3. O servidor de banco de dados filtra os dados desejados (como por exemplo, do último mês)
4. O servidor de banco de dados faz os joins e cálculos necessários e retorna o resultado

As etapas 1 e 2 são melhorados com um dimensionamento correto da infraestrutura.

Algumas otimizações foram introduzidas no Exadata para tentar endereçar as etapas 2 e 3:

• Smart Scan: é uma função de off loading, ou seja, o processamento é feito nos storage cells ao invés dos servidores de banco de dados. Para otimizar a transfêrencia de dados entre storage e servidores de banco de dados duas ações podem ser tomadas: aumentar o tamanho do “tubo” por onde passam os dados ou diminuir o volume de dados transferidos. O Smart Scan executa a segunda opção através do processamento prévio dos dados no storage cell mas de maneira restrita às operações mais simples relacionadas à leitura de grandes segmentos de dados em acessos sequenciais (full scans). Note que apesar do volume de dados trafegados ser menor, o Smart Scan não elimina a necessidade de leitura dos dados a partir dos discos.
• Storage Index: também é uma função de off loading e consiste na manutenção de “índices” na memória dos storage cells. O Storage Index é criado automaticamente para até 8 colunas por tabela. Por ser uma estrutura em memória, são criados a partir do acesso aos dados e são perdidos no caso de reboot dos storage cells. Diferente dos índices tradicionais, eles armazenam valores mínimos, máximos e a existência de valores nulos das colunas indexadas. Funcionam em conjunto com o Smart Scan, ou seja, para acessos sequenciais, o que significa que nem todas as operações conseguem tirar proveito deles. Resista portanto à idéia insana de eliminar todos os índices de suas tabelas.
• Uma terceira otimização presente no Exadata é o EHCC (Exadata Hybrid Columnar Compression), que é uma funcionalidade principalmente voltada à economia de espaço de armazenamento. Apesar de reduzir o volume de dados armazenado, ele aumenta o consumo de CPU dos servidores banco de dados e normalmente provoca um impacto na performance, sendo eventualmente utilizado para arquivamento de dados. Dados comprimidos ocupam menos espaço não somente para armazenamento, mas também para serem transferidos.

Como já mencionei anteriormente, o Exadata nasceu com um foco em ambientes de Data Warehouse buscando endereçar a transferência de grandes massas de dados, mas ele serve também para aplicações transacionais (OLTP)? Buscando endereçar este outro mercado, que por sinal é muito maior que o primeiro, foram incorporadas então à segunda versão do Exadata (X2) as placas de Flash Cache, que aumentam substancialmente a performance dos acessos randômicos à disco. Neste tipo de aplicação, as funcionalidades de off loading dos storage cells fazem pouca diferença devido à natureza randômica do acesso aos dados, assim como pouca vantagem tráz a infraestrutura Infiniband, sendo mais importante o tempo de resposta dos acessos aos blocos de pequeno tamanho resultante dos acessos indexados (viu o porquê de não se livrar dos índices confiando cegamente no storage index?). O cache é uma forma inteligente de se utilizar recursos caros de forma otimizada e tirar proveito da chamada localidade de referência, que diz respeito ao acesso mais frequente de determinadas áreas de dados. Diversos fabricantes de storage arrays usam cache com o mesmo objetivo há muitos anos.

Mas nem tudo é perfeito…

A eficiência de armazenamento do Exadata é baixa pois as formas de proteção de dados disponíveis contam com 2 ou 3 cópias dos dados, traduzindo-se em menos de 50% ou 33% de área útil respectivamente. A proteção NORMAL do ASM implica em duas cópias dos dados, que normalmente já significa um elevado nível de proteção de dados quando falamos de storages tradicionais. Porém, este nível de proteção é inadequado no Exadata quando pensamos em uma infraestrutura corporativa onde os requerimentos de disponibilidade são elevados. Pense no seguinte cenário: você vai aplicar um conjunto de patches nos storage cells. Você pode utilizar rolling upgrades e executar esta operação de forma online sem a necessidade de parada do ambiente, certo? Pense bem! Durante a aplicação de patches no storage cell, a mesma pode ficar indisponível e requerer reboots para completar a operação. Durante estes períodos de atualização os dados armazenados no storage cell podem ficar  indisponíveis de forma que parte dos dados ficam apenas com uma cópia. O que aconteceria se por um acaso (lembre-se de Murphy) esta única cópia fosse perdida? Por isto, a recomendação em ambientes críticos é a utilização do esquema de proteção tipo HIGH, que consiste em três (!) cópias dos dados, levando à uma área útil final inferior à 33% do total.

Ainda para deixar claro, ambos os tipos de aplicações podem ser endereçados fora do Exadata, através do uso adequado da infraestrutura e com um aproveitamento muito maior da área de armazenamento.

Em resumo: em termos de tecnologia o Exadata buscou endereçar os problemas de performance em ambientes de Data Warehouse através de um dimensionamento adequado da conectividade e da redução (limitada) da transferência dos dados. Para aplicações OLTP estas melhorias possuem pouco ou nenhum impacto, mas elas são beneficiadas pela disponibilidade de uma grande área de cache incluída posteriormente. Além disso, a eficiência de armazenamento do Exadata é muito baixa se considerarmos os demais players do mercado de armazenamento.