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.
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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