C-Store 7 years later

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


COC762: 1o. Trabalho - The Vertica Analytic Database: C-Sto

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.



Column Store

Tradicionalmente os bancos de dados trabalham sob o conceito
de "row-store". Ou seja, ﬁsicamente 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 ﬁcam
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.



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áﬁcas, 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.



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



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.



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 é modiﬁcada.
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.



O mantenedor de tuplas - "tuple mover"

O mantenedor de tuplas é um processo interno e automático do
Vertica responsável por "digerir" e reajanjar ﬁsicamente 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 desaﬁo 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.



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.



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.



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 ﬁnalizada, 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.



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.



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.



Performance e Compressão

Vide abaixo, a comparação entre tempos de consultas e taxas de
compressão.



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.



C-Store 7 years later

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a C-Store 7 years later

C-Store 7 years later