Columm Store x Row Store e o In-Memory

Big Data & NoSQL

IoT, Mobile, Big Data, Stream Analytics e por ai vai. Cada vez temos mais referências da necessidade dos chamados NoSQLs. A verdade é que o cenário de armazenamento de dados clássico tem se tornado inviável em alguns cenários. Para aqueles de nós que já estão vendo este futuro hoje, vale entender as bases deste novo mundo cheio de diferenças em relação ao nosso tradicional modelo relacional de armazenamento de dados.</p>

Com a crescente necessidade de análise de grandes volumes de dados no menor tempo possível, bancos de dados baseados em uso intensivo de memória RAM (In-Memory) estão cotados como sendo a solução mais viável. A principal diferença entre os bancos de dados** In-Memory** e os “tradicionais/clássicos” já conhecidos, está na forma de armazenamento dos dados, Column Store vs Row Store. Vamos considerar uma tabela organizada nos dois modelos:

Row Store

Column Store

Ao invés de cada registro da tabela ficar armazenado em uma linha, o registro passa a ser armazenado em colunas separadas. Essa forma de armazenamento tem algumas vantagens, como exemplo a capacidade de compressão dos dados, se formos analisar a compressão de um banco onde os registros são armazenados em linha, encontraremos em uma mesma linha diferentes tipos (domínios) o que torna o processo mais complicado, já no banco orientado a colunas, cada coluna irá conter o mesmo tipo (domínio) de dado. De acordo com algumas pesquisas o nível de compressão alcançado  em bancos orientados a colunas chega a ser de 60% a 70%  mais eficiente que nos bancos orientados a linhas.

Para o caso de armazenamento dos dados em colunas é necessário que haja um relacionamento entre as colunas para identificar que a mesma pertence a um registro específico, para resolver esse problema a estratégia de incluir um ID virtual é normalmente adotada, nesse caso a representação do armazenamento em colunas ficaria como a imagem abaixo:

Vamos a seguinte query:

    
  SELECT AVG(PESSOA_IDADE) FROM PESSOA
    

Em um banco de dados orientado a linhas, esta consulta irá recuperar todas as linhas, carregando todos os campos para executar a operação e retornar a média de idade, já no banco de dados orientado a colunas apenas a coluna PESSOA_IDADE será levada em consideração, o que neste caso vai consumir menos recursos.

Vale lembrar que um SELECT * FROM PESSOA, possivelmente não terá vantagem alguma já que todas as colunas precisarão ser lidas.

As principais técnicas aplicadas a banco de dados em coluna são particionamento, indexação, compressão e uma série de estratégias para realização dos JOINS.

A utilização de armazenamento em colunas torna-se viável com a utilização de arquiteturas de hardware modernas com grande número de processadores e grandes quantidades de memória. Os tipos de sistemas mais indicados para uso de armazenamento em colunas são os sistemas que precisam ler e realizar operações de consultas em grandes volumes de dados (OLAP), para sistemas do tipo OLTP as operações de escrita podem não ser tão vantajosas.

Alguns fornecedores permitem que uma tabela seja definida como Column Store ou Row Store dentro do mesmo banco de dados. Mesmo com as implicações desta abordagem, o grande desafio dos fabricantes hoje é desenvolver as melhores soluções que consigam extrair o máximo do hardware e abstrair as complexidades para os usuários.

Para quem se interessar pelo assunto, deixo alguns links com boas informações sobre Column Store.

Referências


Author's profile picture

Vitor is a computer scientist who is passionate about creating software that will positively change the world we live in.

MVP Azure - Cloud Architect - Data science enthusiast


3 minutes to read