Storage Exadata: Protocolo iDB

Salve galera do mal! Eis que estou aqui de volta pra falar mais um assunto da série Storage Exadata. Irei abordar hoje o Intelligent Database Protocol, para os íntimos apenas iDB. Este protocolo é único e somente pode ser encontrado em servidores com storage Exadata e isso não é a toa. O protocolo está implementado no kernel do banco de dados Oracle e foi construído sobre o padrão de indústria RDS (Reliable Datagram Sockets versão 3) e executa sobre a Infiniband ZDP (Zero-Loss Zero-Copy Datagram Protocol) que é uma implementação cópia zero (Zero-Copy) do protocolo RDS, com isso é eliminada a desnecessária cópia de blocos, permitindo maior eficiência na rede.

É graças a este protocolo utilizado em comunicação entre os storage servers e os database nodes que é possível identificar o tipo de I/O que é enviado pelo servidor de banco de dados, por exemplo, seria impossível ter o benefício de cell offloading ou Smart Scan sem este protocolo. Dentro do servidor de storage, estão em execução três principais processos: CELLSRV; Management Server; e Restart Server. Em especial sobre o protocolo iDB, o processo CELLSRV é responsável pelas requisições de I/O efetuadas via iDB para poder efetuar as tratativas inteligentes como o cell offloading.

Foi aqui, no meu ponto de vista, que a Oracle acertou na construção de um hardware que entendesse o que o banco de dados está executando, sem isso nós teríamos apenas servidores ODA (Oracle Database Appliance) no mercado. E é por isso que o Exadata Storage Server é o futuro dos Engineered Systems e será muito difícil novos hardwares tomarem o seu lugar. Pois hardware e inteligência em infraestrutura todo mundo consegue copiar ou aprimorar muito rápido, porém software demora um pouco mais. Galera vou ficando por aqui, aquele abraaaaaaaa.

Exadata Storage: What is the Secret?

Hello guys!! Today I’ll post about some technologies from Exadata Storage. IMHO, Oracle has highly score when it launch this hardware for it database. The newest version of it is an X5-2 that can has it configuration using flash disks on the storage which it’s called Extreme Flash. Ok, let’s take a look on this machine and the most interesting features that are beside it.

This hardware is made of database servers which host the whole database and clusterware instances. The data is present on the storage nodes (cell nodes) and also the Exadata system software.The communication between this servers uses two infiniband switches which can handle data transfer up to 40 Gbps. Besides that there is a management switch and the PDUs. When we talk about High Availability, this machine is all about it.

OK, but what is the deal about this hardware because if it is all about hardware everyone can “copy and paste” it? It is all about avoiding or reducing I/O that the software can provide. And this can only be achieved because there is a communication from the databases and the storage servers using a protocol called iDB that allows intelligent I/O to be done. When the I/O is requested from the database nodes to the cell nodes, the cell node knows what kind of I/O is occurring and how to deal with it.

Most of the features that will be mentioned ahead are about the Smart Scan concept. This behaviour can only occur when Direct Path is performed on the database, so sequential reads will no have benefit from Smart Scan. Bellow are mentioned some of this features that minimize I/O on the Exadata:

  1. Column Filtering: As the name means, there is a filtering about the columns so when your query that retrieves only one column from a table that has 10 columns, only the selected column is returned to the database server. On a normal environment, the storage would retrieve all the columns and the SGBD would filter it;
  2. Predicate Filtering: Similar to the Column Filtering feature, but this one is happens on the row level. The Exadata Storage can retrieve only the rows that satisfy your query;
  3. Cell Offloading: Normally, the work can be offloaded to the cells. An example would be a query that count all the employees from a company (select count(*) from hr.employees), is work is done on the cell nodes and only the result goes back to the db node. There could be cases that when there is a high workload on the cells, it can’t offload the work and all the rows goes back to the database node as it would in a normal environment;
  4. Storage Indexes: The cell nodes have the ability to analyze the queries so they can build the Storage Indexes (SI). This structure resides on the memory of the cell nodes and they are lost on every restart from the cells. This feature can provide information about the minimum and maximum values from a column, so the Exadata knows exactly what are the blocks to hit. Each table can have a maximum of eight SI;
  5. Join Processing: The Exadata uses the Bloom Filtering technique which is a probabilist method when you join two tables to efficiently test result sets, this can only be used on database using version equal and above to 11.2.0.4;

So the Exadata storage has a technology addressed to the highest data throughput per transaction and this is not recommended for an OLTP environment? No exactly, there are three features that I see as better designed to OLTP environments:

  1. Exadata Smart Flash Cache: This isn’t similar to the Database Smart Flash Cache feature. This feature has a method of write called write-back cache which the data can be first written on the ESFC and than can be write asynchronously on the cell disks presented on the storage nodes. Also, you can choose to com compress the data on the ESFC which gives you a better data usage capacity;
  2. Smart Flash Cache Log: There is a small area which is built on the flash cache from each cell nodes designed to redo logs writes. This is known as Smart Flash Cache Log, so when the cell nodes attempts to write a redo log request it tries to write on both cell disks and flasch cache. The first it gets, it acknowledge the request back to the db node speeding redo logs write which is excellent for OLTP environments;
  3. Join Processing: this feature is a good one for both DW and OLTP environments;

I understand that Smart Flash Cache with write-back enabled can be a good feature for DW environments too, but when we move to high workload environment with high load of data, the data could probably not fit into Smart Flash Cache. Besides that, the Exadata Database Machine has a special feature called HCC (Hybrid Columnar Compression) where the data could be compressed at high levels reducing I/O and enhance the performance for this machine. Well guys, that’s all for now! See you!

Storage Exadata: Qual o segredo?

Olá, galerinha! Hoje venho postar (bem por alto) sobre algumas das tecnologias do storage Exadata. Em minha humilde opinião, a Oracle acertou em cheio quando lançou no mercado este hardware projetado especificamente para o seu banco de dados. A versão mais recente deste hardware é a X5-2 (adquiridas nas versões de rack: eight; quarter; half; e full) que, diferentemente das versões anteriores, pode-se optar por discos de flash na opção de Extreme Flash. Aliás, nesta versão, o comprador pode também optar por adicionar apenas uma célula e/ou um database node não ficando amarrado nas configurações padrões.

Bom, vou passar brevemente pela arquitetura desta máquina apenas para ilustrar melhor o conceito do software. O hardware é composto por database nodes que hospedam os binários do Oracle Clusterware e as instâncias de banco de dados. E os dados residem nos storage nodes (cell nodes) que possuem os discos e o software. A comunicação entre estes servidores é efetuada através de infinibands switches que apresentam taxas de transmissão de até 40 Gbps. Além disso, temos um swtich de gerencia e as PDUs. Em termos de alta disponibilidade, a máquina apresenta uma solução completa.

Mas afinal, qual o grande lance desta tecnologia já que hardware qualquer fabricante consegue copiar? Em resumo (e na maioria das suas características), eu arrisco dizer que é a inteligência na redução de I/O proporcionado pelo software que está em suas células. E isso só acontece porque há uma comunicação, utilizando o protocolo iDB, entre o banco de dados e as células que informam o tipo de atividade executada. Sendo assim, as células funcionam provendo serviço de dados para o banco de dados nos db nodes.

Vale lembrar que as features abaixo mencionadas estão dentro do conceito de Smart Scan. Esta característica só pode ocorrer se houver (em básico porque existem várias regras) Direct Path no banco de dados, portanto todas as leituras ordenadas em índices (Index Range Scan / Index Unique Scan / Index Max/Min / Index Skip Scan / Index Full Scan), obtém em nada os recursos que somente este storage pode prover. A seguir serão mencionadas algumas destas tecnologias de redução de I/O:

  1. Column Filtering: No Exadata, e como o nome sugere, ocorre o filtro por coluna. Sendo assim, a query que buscar apenas uma coluna da tabela e esta possui dez colunas, somente será retornado os dados desta coluna. Em um servidor convencional, os blocos de toda a tabela seriam retornados do storage para o banco de dados, e este efetuaria o filtro da única coluna mencionada;
  2. Predicate Filtering: Similar a característica anterior, este filtro ocorre a nível de registro. Entenda que quando o banco de dados convencional solicita apenas um registro de uma tabela, e este registro está presente em um único bloco, o bloco por completo será retornado para o servidor de banco de dados, que descartará os demais registros. No Exadata, apenas o registro do bloco é retornado para o banco de dados;
  3. Cell Offloading: Sempre que possível, o trabalho será realizado pelas células. Exemplo, quando uma query pesquisar pela quantidade de funcionários em uma tabela (select count(*) from hr.employees), esta atividade será efetuada pela célula e somente será retornado o valor final para o db node. Em um servidor convencional, todos os dados da tabela seriam retornados para o banco de dados e este teria que efetuar a conta para retornar o resultado. Podem existir casos extremos que, com o grande consumo de atividades nas células, as atividades de offloading podem ser direcionadas para os database nodes executarem;
  4. Storage Indexes: As células tem a inteligência de analisar as pesquisas das queries em determinadas tabelas e viabilizam a construção dos SI (Storage Indexes). Esta estrutura reside na memória das células (sendo assim são perdidas todas as vezes que a célula for desligada) e informa os valores mínimos e máximos da coluna envolvida na query, sendo assim o storage consegue saber exatamente onde está o dado. Esta estrutura consegue montar até oito SIs para uma tabela;
  5. Join Processing: O Exadata utiliza da técnica de Bloom Filtering que é um método probabilístico utilizado quando se envolve uma tabela grande e uma pequena para se testar eficientemente um conjunto de resultados entre ambos. Esta técnica também pode ser analisada em banco de dados que estão acima da versão 11.2.0.4;

Então quer dizer que o storage do Exadata é uma tecnologia direcionada para ambientes com altíssimo volume de dados por transação (DW / DSS), não sendo recomendada para ambientes com alta quantidade transacional de baixo volume de dados (OLTPs com baixa escrita)? Não exatamente. Existem três características do Exadata que consigo avaliar sua utilização benéficas em ambientes OLTPs e estas são:

  1. Exadata Smart Flash Cache: Não confunda esta tecnologia com a Database Smart Flash Cache. A tecnologia que possui no Exadata utiliza os discos flash que constam na célula enquanto que a outra utiliza discos de alta velocidade (SSD). E no Exadata, esta área ainda pode ser configurada como write-back onde o dado será escrito primeiro na cache, liberando a transação e a cache se encarregará de escrevê-lo nos discos das células. Atualmente, pode-se também optar por comprimir os discos flash para aumentar a capacidade da flash cache;
  2. Smart Flash Cache Log: Esta tecnologia, que confunde um pouco as pessoas (inclusive eu estava confuso sobre esta há alguns meses atrás), mantém uma área de dentro de cada uma nas flash cache das células utilizadas exclusivamente para a escrita de redo logs. Sendo assim, quando a célula recebe uma requisição para escrever em seus discos dados de redo, automaticamente esta efetua escrita paralelizada tanto nos discos como na flash cache. Buscando otimizar a escrita do mesmo, pois em ambientes OLTPs, o gargalo pode ocorrer nestas áreas;
  3. Join Processing: mencionado anteriormente e que pode ter uma boa utilização em uniões de tabelas;

Entendo que a tecnologia do Smart Flash Cache com write-back habilitado pode ser um excelente benefício também para ambientes DWs porém quando estamos falando de alto volume de dados neste ambiente, pode ser que as áreas de cache não comportem a capacidade de dados transacionados.

Além destas tecnologias, o Exadata possui a característica de compressão de tabelas chamada HCC (Hybrid Columnar Compression) onde os dados são armazenados e comprimidos a nível de coluna, obtendo ótimos resultados de compressão. Mas por hoje é só e nos próximos posts, irei dar exemplo do funcionamento destas tecnologias de redução de I/O assim como de compressão. Aquele abraaaaaaaa.