C-Store 7 years later

203 visualizações

Publicada em

Será apresentado um resumo do seguinte artigo:
The Vertica Analytic Database: C-Store 7 Years Later.
Andrew Lamb, Matt Fuller, Ramakrishna Varadarajan Nga Tran,
Ben Vandiver, Lyric Doshi, Chuck Bear Vertica Systems, An HP
Company, Cambridge, MA. Apresentado em VLDB 2012 Istambul.
Onde é mostrado um exemplo de RDBMS comercial usando os
conceitos de "Column Store", que já abriga um banco com 8PB.

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
203
No SlideShare
0
A partir de incorporações
0
Número de incorporações
1
Ações
Compartilhamentos
0
Downloads
4
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

C-Store 7 years later

  1. 1. COC762: 1o. Trabalho - The Vertica Analytic Database: C-Store 7 Years Later. Professores: Myrian Costa, Valeria Bastos, Nelson Ebecken Júlio César Chaves, COPPE/UFRJ October 19, 2013 Júlio César Chaves, COPPE/UFRJ COC762: 1o. Trabalho - The Vertica Analytic Database: C-Sto
  2. 2. Introdução Será apresentado um resumo do seguinte artigo: The Vertica Analytic Database: C-Store 7 Years Later. Andrew Lamb, Matt Fuller, Ramakrishna Varadarajan Nga Tran, Ben Vandiver, Lyric Doshi, Chuck Bear Vertica Systems, An HP Company, Cambridge, MA. Apresentado em VLDB 2012 Istambul. Onde é mostrado um exemplo de RDBMS comercial usando os conceitos de "Column Store", que já abriga um banco com 8PB. Júlio César Chaves, COPPE/UFRJ COC762: 1o. Trabalho - The Vertica Analytic Database: C-Sto
  3. 3. Column Store Tradicionalmente os bancos de dados trabalham sob o conceito de "row-store". Ou seja, fisicamente a manipulação se dá em nível de tuplas, mesmo que apenas uma coluna seja requisitada. Sob o conceito de column store (C-Store), os dados ficam particionados por padrão por colunas, permitindo abordagens até então não compatíveis com o modelo anterior. Apesar do interesse em bancos NoSQL, o C-Store antecipou a demanda por um DB "web-scale". Foi descoberto que o problema dos bancos tradicionais não era o fato de ser ou não SQL, mas sim as estruturas internas de armazenamento. Júlio César Chaves, COPPE/UFRJ COC762: 1o. Trabalho - The Vertica Analytic Database: C-Sto
  4. 4. Comportamento de trabalho transacional vs. analítica Transacional: Espera-se milhares de transações por segundo, cada transação lidando com poucas linhas. Ex.: Inserir novos dados de vendas, atualizar saldo bancário. Analítica: Espera-se por dezenas de transações por segundo, cada transação lidando com grande volume de linhas. Ex.: Agregar vendas por data e dimensões geográficas, analisar o comportamento de diferentes usuários num site web. Seguindo exemplo do GOOGLE, o Vertica foi desenhado para rodar hardware moderno de conveniência x86_64. O escalonamento é linear. Ou seja, se tenho 2 nós e adicionar 2, a capacidade operacional duplica de fato. O sistema foi desenhado para que as consultas anaílitas não sejam impactadas pelas cargas. Júlio César Chaves, COPPE/UFRJ COC762: 1o. Trabalho - The Vertica Analytic Database: C-Sto
  5. 5. Modelo de dados Assim como o padrão C-Store, o Vertica organiza os dados em projeções, que são nada menos do que segmentos físicos ordenados das colunas, que ficam ancoradas nas tabelas. Os dados são armazenados sob diferentes tipos de compressão possíveis. Por exemplo: Uma data que se repete 1 milhão de vezes é gravada somente uma vez. C-Store usa particionamento horizontal para aumentar o paralelismo num mesmo nó, ao passo que o motor de execução do Vertica faz de uma mesma divisão física, diversas sub-divisões lógicas e assim obtém o paralelismo com menos esforço operacional. Júlio César Chaves, COPPE/UFRJ COC762: 1o. Trabalho - The Vertica Analytic Database: C-Sto
  6. 6. Separação física: Particionamento e Segmentação Particionamento: Trata-se de uma divisão física que obedece cláusulas lógicas, num mesmo nó. PARTITION BY. Segmentação: Trata-se da divisão de blocos físicos de dados em diferentes nós, também obedecendo cláusulas lógicas via SEGMENTED BY na criação de projeções. Júlio César Chaves, COPPE/UFRJ COC762: 1o. Trabalho - The Vertica Analytic Database: C-Sto
  7. 7. ROS e WOS - "o kernel" ROS Read Optimized Store - Composição de áreas físicas de dados em disco que seguem os conceitos de C-Store. Não existem índices, pois uma área ROS nunca é modificada. WOS Write Optimized Store - Composi´ ão de áreas de memória c que podem ser column store ou row store e serve unicamente como buffer para pequenas operações DML. O dado não é comprimido, no entanto obedece as cláusulas de segmentação. Nenhum dado no Vertica é excluído no próprio local onde reside, mas sim, obedece a criação de um vetor de exclusão. Cada update ocorre via uma exclusão seguida por uma inserção. Júlio César Chaves, COPPE/UFRJ COC762: 1o. Trabalho - The Vertica Analytic Database: C-Sto
  8. 8. O mantenedor de tuplas - "tuple mover" O mantenedor de tuplas é um processo interno e automático do Vertica responsável por "digerir" e reajanjar fisicamente as estruturas de dados. As duas principais funções do mantenedor de tuplas são: Moveout: Movimenta de forma assíncrona os dados de WOS para ROS. Mergeout: Aglutina múltiplos arquivos ROS em arquivos ROS maiores. O desafio do mantenedor de tuplas é manter o equilíbrio e a tensão entre: gerar muitos pequenos arquivos de ROS ou causar estouro de cache do WOS devido a falta arquivos ROS. Júlio César Chaves, COPPE/UFRJ COC762: 1o. Trabalho - The Vertica Analytic Database: C-Sto
  9. 9. Atualizações (updates) e transações Cada tupla no Vertica leva consigo a data/hora (timestamp) da transação que a gerou, assim como cada tupla apagada leva a data/hora da transação que a apagou. Dessa forma, qualquer seleção de dados não irá gerar bloqueio algum, pois por padrão a seleção opera sob a forma READ COMMITED, o que no vertica equivale a dizer que lê sempre a última época válida de dados. Os nós do cluster trabalham em BROADCAST, assim, um nó que se torne inacessível, é automaticamente removido do grupo e essa informação é atualizada em todos os nós. Se um COMMIT falhar para determinado nó, ele automaticamente é removido do cluster sem segunda tentativa. O ROLLBACK implica simplesmente em descartar os blocos ROS e WOS referentes a transação que foi cancelada. Júlio César Chaves, COPPE/UFRJ COC762: 1o. Trabalho - The Vertica Analytic Database: C-Sto
  10. 10. Tolerância a falhas e log de transação Cada projeção possui obrigatoriamente uma buddy projection, uma espécie de "arquivo de controle" da projeção, que é capaz de recriar as linhas e colunas que foram perdidas num nó, em outro. Não são gerados os tradicionais "logs de transação", "transaction log" no SQL server, "archived logs" no oracle , pois a combinação (data+época) serve como histórico de transações passadas. Júlio César Chaves, COPPE/UFRJ COC762: 1o. Trabalho - The Vertica Analytic Database: C-Sto
  11. 11. Existe BACKUP Lembrando que o sistema de trabalho do vertica é baseado em arquivos "somente leitura", o backup apenas tira uma imagem dos arquivos de catálogo e cria "hard-links" para os arquivos de dados, para assegurar que eles não serão apagados durante o processo de cópia, que quando finalizada, apaga os "hard-links". É suportado backup FULL e incremental. O único impacto do backup é o consumo de recursos extra consumidos para levar as cópias para destinos externos. Júlio César Chaves, COPPE/UFRJ COC762: 1o. Trabalho - The Vertica Analytic Database: C-Sto
  12. 12. Integridade do Cluster Um cluster pode realizar um processo normal de SHUTDOWN/STARTUP com até N nós perdidos, onde N é o 2 número total de nós no cluster. Júlio César Chaves, COPPE/UFRJ COC762: 1o. Trabalho - The Vertica Analytic Database: C-Sto
  13. 13. Descoberta automática de projeções adequadas às consultas O vertica possui uma ferramenta nativa, chamada Database Designer, que recebe como parâmetro uma ou mais consultas num mesmo arquivo, e descobre a partir dos dados, quais a projeções, com suas respectivas ordenações e segmentações trariam o resultado desejado em menos tempo. Júlio César Chaves, COPPE/UFRJ COC762: 1o. Trabalho - The Vertica Analytic Database: C-Sto
  14. 14. Performance e Compressão Vide abaixo, a comparação entre tempos de consultas e taxas de compressão. Júlio César Chaves, COPPE/UFRJ COC762: 1o. Trabalho - The Vertica Analytic Database: C-Sto
  15. 15. Conclusão O projeto vertica só foi possível devido as inovações no sentido de "quebra de paradigma de banco de dados" juntamente com uma solução de continuidade que não exclui conceitos, regras e formas de trabalho já conhecidas, tanto na academia quanto no mercado. Não podemos continuar agindo, e tratando problemas de Petabytes da mesma forma com que estamos acostumados a tratar os de Gigabytes. A mudança aponta claramente para uma nova forma que não rompe com a anterior, simplesmente torna possível a continuidade. Júlio César Chaves, COPPE/UFRJ COC762: 1o. Trabalho - The Vertica Analytic Database: C-Sto

×