DevMedia
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
post favorito     comentários

SGBD relacionais orientados a coluna: uma nova roupagem ao Data Warehousing – Parte 01

Veja neste artigo SGBD relacionais orientados a coluna.

[fechar]

Você não gostou da qualidade deste conteúdo?

(opcional) Você poderia comentar o que não lhe agradou?

Confirmo meu voto negativo

SGBD relacionais orientados a coluna: uma nova roupagem ao Data Warehousing – Parte 01

 

por João Marcelo Borovina Josko

 

A necessidade por informações de qualidade e com baixa latência – Real-Time Business Intelligence – é condição cada vez mais premente na condução dos negócios dentro de organizações de vários segmentos. Responsável por atender a essa necessidade, os ambientes de suporte à decisão tornaram-se cada vez mais críticos concomitante ao desafio de TI retirar mais valor desses servindo-se de menos recursos.

 

A pressão para responder a esse cenário, no caso das tecnologias de Sistemas de Bancos de Dados – SGBD –, levou ao aparecimento de uma nova abordagem que oferece melhor eficiência de armazenamento atrelado a um melhor tempo de resposta nas consultas analíticas; os SGBD Orientado a Coluna – referenciados como Column Oriented ou Column Store.

SGBD e seu público no tempo

Na década de 70, os SGBD foram massivamente utilizados na automatização de processos operacionais crítico – Folha de Pagamento, Contabilidade, Conta Corrente, para citar alguns – que se caracterizam pela realização de transações com curta duração e pequeno volume de dados manipulados; as transações OLTP.

 

A partir da década de 90, as organizações perceberam o valor dos SGBD – e do grande volume de dados disponíveis – como instrumento de apoio a tomada de decisões, ao planejamento do seu negócio e ao entendimento de seus Clientes, culminando no fortalecimento dos segmentos de Data Warehousing e Customer Relationship Management – CRM.

 

Esses dois públicos – transacional e analítico –, porém, apresentam características e requisitos fundamentalmente diferentes quanto ao uso do SGBD – ver quadro a seguir –, levando os fornecedores e pesquisadores a buscarem propostas para atender aos públicos divergentes. Desta necessidade surge a abordagem Orientada a Coluna.

Quadro 1 – Contraposição das principais características do mundo transacional e analítico

sqlmagazine-18-12pic01.JPG


Distinções entre as abordagens

Muitas implantações de Data Warehouse/Data Marts foram – e estão sendo – concebidas com SGBD tradicionais – Oracle, Teradata, DB2, etc. – cujos núcleos focam no tratamento de linhas. Não obstante esta característica ser adequada a sistemas OLTP, muitos dos seus representantes receberam vultosos investimentos para incrementar sua capacidade de apoio as necessidades analíticas, como incorporação de índice Bit Map, visões Materializadas e capacidade de configuração.

 

Os SGBD com orientação a coluna – Vertica, Sybase IQ, BigTable, Exasol, ParAccel, entre outras opções comerciais e open-source –, por sua vez, apoiaram a construção do seu núcleo sobre a constatação cujo Data Warehouse/Data Mart apresenta uma freqüência de leitura muito superior a de operações de modificação – insert, update e delete. Tal fato determina seu desempenho ótimo para leituras seletivas – pequeno conjunto de colunas – sobre extenso volume de dados.

 

As principais diferenças entre as duas abordagens são:

 

Forma de Armazenamento

 

Na abordagem Orienta a Linha, cada coluna de uma linha é armazenada de forma contígua, ou seja, todas as informações sobre uma entidade são mantidas juntas, conforme figura abaixo. Na outra abordagem, os conteúdos de cada coluna de uma tabela é que são dispostos em seqüência.

 

 

sqlmagazine-18-12pic02.JPG 

Figura 1 – Visão geral de armazenamento na abordagem orientada a Linha e Coluna.

Evidentemente a questão não se resume a esse fato. Além desta segmentação das colunas, alguns SGBD Orientados a Coluna – como o Vertica – organizam cada tabela em um conjunto de projeções, cada qual com uma porção de suas colunas e com os respectivos dados com alguma ordenação (BURNS, 2007).

 


sqlmagazine-18-12pic03.JPG

Figura 2 – Visão esquemática da segmentação das colunas em Projeções.

Compressão dos dados

 

Apesar dos SGBD tradicionais disporem deste recurso, aqueles orientados a linha obtém uma taxa significativamente maior, pois os algoritmos deste atuam melhor sobre dados de mesmo tipo de dado – menor entropia. Além dos benefícios diretos na redução do espaço de armazenamento, verificam-se ainda vantagens de ordem  de desempenho das operações de consulta em razão do menor tráfego de dados entre o disco e a memória.

 

Operações de Leitura

 

A leitura direta das colunas desejadas – ver figura 3 –,  a compressão dos dados e as projeções – para os SBGD que apresentam mecanismo semelhante – fazem com que o tempo de resposta de operações de cálculo e/ou agregações massivos seja inferior àquele da abordagem tradicional. Esta última, respeitando suas características, recupera todas as linhas desejadas para, então, proceder com a seleção das colunas requeridas.

 

sqlmagazine-18-12pic04.JPG 

Figura 3 – Visão geral esquemática do plano de acesso aos dados no SGBD Orientado a Coluna

Operações de Manutenção

 

A abordagem Orientada a Coluna, ao satisfazer as operações de leitura, cria um ponto de tensão com relação ao desempenho das operações de atualizações. Para não provocarem a contenção do ambiente, são utilizados mecanismos de lock não convencionais, acarretando um desempenho inferior dessas operações em relação àquele verificado na abordagem Orientada a Linha.

 

 

sqlmagazine-18-12pic05.JPG 

Figura 4 – Modelo de armazenamento híbrido

O C-Store (STONABRAKER, 2005) e o Vertica (BURNS, 2007), por exemplo, adotaram um modelo híbrido de armazenamento composto por duas áreas ou segmentos; uma que suporta as operações de atualização dos dados – WS – e outra que suporta consultas de grandes quantidades de dados – RS –, como ilustrado na figura acima. A segunda área somente suporta operação de atualização via o mecanismo assíncrono – denominado Tuple Mover – que efetua o merge de seus dados com aqueles disponíveis na área WS.



João Marcelo Borovina Josko, Msc. em Computação pela UNICAMP. 16 anos atuando na condução e desenvolvimento de soluções para a gestão da informação. Especializado em Business Inteligence, Engenharia de Software e de Banco de Dados [...]

O que você achou deste post?
Conhece a assinatura MVP?
Publicidade
Serviços

Mais posts