Já há alguns anos eu quero testar um banco de dados colunar. Desde o Pentaho Day 2014 eu fiquei muito curioso para brincar com o HP Vertica, mas não tinha tido o tempo (nem um banco com volume) suficiente para todo o trabalho que isso implica.

No final de 2014 eu consegui instalar uma máquina virtual com o Vertica 7.1.1 (em um Ubuntu Server 14.04.1.) Construí uma dúzia de transformações que copiaram todos os cubos de um DW em Postgres para esse Vertica. Configurei um BI Server 5.1 com as duas fontes de dados, e um esquema Mondrian para cada uma dessas fontes. Ontem em consegui fazer e tabular um experimento simples: usando o jPivot, abri o maior dos cubos (14.095.514 de linhas) e fiz uma exploração simples: abri e fechei cada uma das seis dimensões principais. Todas elas tinham entre um e três membros no nível hierárquico superior, exceto por uma dimensão data, que tinha 11 membros no nível do ano.

O Experimento

Fiz essas navegações logo após o boot do servidor, com cache vazio, e com um esquema (=banco) de cada vez. Capturei o log MDX e SQL do Mondrian para cada caso. Elas foram tão idênticas que foi possível comparar até mesmo o SQL gerado entre os dois experimentos. Como o Vertica é um Postgres colunar, o SQL era idêntico até a última vírgula, e isso facilitou a comparação.

Veja, eu não estava fazendo um estudo milimetricamente planejado. Eu só queria obter um sentimento da relação de performance entre as duas tecnologias. Logo, o resultado vai refletir o preparo do experimento. A informação será mínima, binária: em plataformas de hardware parecidas, qual base é mais rápida?

Tempo total para fazer a mesma coisa.
Tempo total para fazer a mesma coisa.

É o Vertica, sem sombra de dúvida. A máquina virtual do Vertica tinha 2GB de RAM e uma CPU – um quarto do meu i7 2.4GHz. A máquina do Postgres é a minha máquina real, com 16GB de RAM além de toda a CPU disponível. A máquina virtual estava desligada, de modo que minha CPU não estava particionada no momento do teste do Postgres.

O gráfico anterior mostra o tempo total para repetir a mesma operação com o mesmo cubo, usando bases diferentes. Já o gráfico abaixo compara cada uma das operações – que por acaso são 15 – usando uma escala logarítmica no eixo Y.

Tempo por operação nas duas tecnologias.
Tempo por operação nas duas tecnologias.

Curiosamente, e talvez até previsivelmente, o Vertica teve um desempenho uniformemente melhor que o Postgres em todas as operações que levavam mais tempo, mas perdeu feio nas operações M e N, que duraram menos de 50 ms. Destas operações, a M é o pior resultado do Vertica: 42 ms a 0 ms para o Postgres. Ou seja, uma operação que durou mais de 40 ms no Vertica foi tão rápida no Postgres que o log do Mondrian não conseguiu medir.

Lendo a documentação do Vertica eu vi um tópico que discute exatamente isso: consultas menores tendem a ter um overhead proporcionalmente maior que bancos relacionais.

Legal.

Em compensação, o Vertica foi mais rápido em tudo que levou mais de 50 ms. Em alguns casos, como o O, ele chega a ter mais de uma ordem de grandeza de vantagem – 22 vezes mais rápido no caso da operação O.

A Conclusão…

… é óbvia: o Vertica parece ser muito interessante para exploração OLAP de fatos com milhões de linhas. Sendo um cientista, eu estou perfeitamente ciente do risco que seria generalizar essa conclusão para um “logo ele será bom para tudo”. Existe um caso de uso no qual eu estou particularmente interessado, um relatório (PRD) tabular construído sobre esse mesmo cubo. Meus próximos testes vão tentar determinar se é uma vantagem usar Vertica ou não.

E eu aposto que é.

Feliz Ano Novo!!

Anúncios

9 comentários sobre “Testando o Vertica

  1. Fábio, estou com uma fato no meu trabalho com cerca de 700 milhões de registros num banco postgres e acredito que utilizando o vertica a performance pode melhorar de acordo com a sua experência e mais alguns estudos de casos vistos da Internet. Você poderia me enviar algum material que você utilizou para realizar a carga de dados no kettle no banco Vertica? Outro ponto é em relação a arquitetura, acredito que não posso perder minha base relacional por ora, portanto a ideia seria utilizar o comando COPY do VERTICA para copiar os dados do postgres para banco de dados colunar, assim realizando um espelhamento rsrs. Outro ponto é de que é toda vez terei que realizar um truncate no vertica certo? acredito que fazer a carga incremental (lookup) dentro do vertica seja algo mais complexo, então todo dia vou ter que carregar o vertica novamente ;( ? caso tenha algum ganho de performance significativo não vejo problemas até dá uma estudada mais a fundo e vê como isso pode ser realizado.

    1. 700 milhões? Uau, que inveja!! Dá para comentar, por alto, sobre o que é a fato? Só curiosidade mesmo, nenhum motivo muito nobre. Fatos deste tamanho não aparecem todo dia, sabe como é. ;-)

      Por definição, parece mesmo ser feito sob medida para um banco colunar. Mas, como quase tudo em Informática, depende.

      Digamos, por exemplo, que essa fato acumula histórico, e a maioria das suas consultas é sobre o último dia ou a última semana. Um monte de linhas ficam quietinhas ali, sem serem tocadas, e uma parcela proporcionalmente pequena (e cada vez menor) é lida com frequência. Neste caso você até tem um ganho, mas ainda daria para espremer performance do Postgres só particionando essa fatona ou criando uma com o snapshot mais usado – enquanto o histórico vai sendo acumulado na fato principal.

      Se, por outro lado, a maioria das suas consultas lê mais da metade dessas linhas, grosso modo, então seu ganho ao mudar para um colunar seria sensível.

      Mesmo assim, nunca se esqueça que boas práticas de DW (como índices bem-pensados) e técnicas de pré-agregação (em especial para ferramentas OLAP, como Mondrian) podem ganhar algum suco extra do seu banco, ou mesmo do colunar.

      Com relação ao ETL: como você já sabe, todo banco colunar sofre horrores para fazer updates. Mas esses bancos também estão preparados para lidar com cargas incrementais. Traduzindo: se a sua fato cresce apenas por justaposição de novas linhas, você não precisa se preocupar (muito) com a carga – só grave as novas linhas e boas (adotando a técnica que der melhor resultado – Table Output, Bulk Load/Copy etc.)

      Agora, se sua fato sofre atualização, então não tem choro, nem vela: truncar e recarregar (muito provavelmente) vai ser mais rápido que um update. Na dúvida, teste. Como você está usando o PDI, o teste mais banal é trocar a conexão de todos os passos que lidam com o banco. Daí recrie no Vertica as tabelas, e rode o processo para ver como ele vai se comportar. Se a performance do refresh se monstrar inadequadamente lenta, vale a pena reescrever o ETL. Se não, se for comparável, vale a pena acompanhar assim por um tempo e ver como evolui – já que tudo depende de como você montou seu ETL, de como seus dados evoluem etc.

      Além de tudo isso, considere o seguinte fato: o Vertica divide o trabalho de consulta através de seus nós. Se você tiver um ganho de performance do Postgres para o Vertica com um único nó, muito provavelmente você ainda pode melhorar isso adicionando até dois outros nós, perfazendo um total de três. O limite da licença gratuita é, justamente, até 1TB distribuídos em até três nós.

      1. Fábio, desculpa o meu equivoco, foi um 0 a mais só rsrs, a tabela fato tem cerca de 70 milhoes de registro e é relacionado a um sistema de veículos de um orgão federal. Portanto, não posso entrar em mais detalhes rsrs. Entretanto, muito obrigado pelas suas respostas foram bem esclarecedoras!

        Vou fazer uma breve explanação do projeto: Existe um cubo legado que contém essa fato de 70mi de registro, porém os usuários vem reclamando do tempo de resposta. Então a ideia é refazer todo o ciclo:

        1.modelagem: vi que posso melhorar em alguns aspectos;
        2.etl e reconstrução dos cubos: isso ainda não é um grande problema,pois o mesmo carrega em cerca de 4 horas mensalmente, sendo que estão fazendo truncate na fato, portanto a idéia é fazer a carga incremental diariamente utilizando o postgres para o ETL e fazer um benchmarking depois entre os 2 processos antigos e novas nas seguintes métricas: tempo de carga e consultas . Portanto, através dos resultados do benchmarking tentarei otimizar a consultas do postgres através dos exemplos dados por você, porém caso o resultado ainda não seja satisfatório eu tentarei utilizar o vertica somente copiando os dados do banco de dados relacional para o colunar, pois é necessário manter o relacional devido alguns sistemas legados utilizarem as fatos para consultas.

        obs: mesmo que o postgresql tenha resultados satisfatórios com a nova modelagem, tunning, etc. Por natureza, nós que somos de TI, temos curiosidade, então com certeza irei implementar o vertica numa máquina virtual para testes rsrs. Afinal, como você mesmo disse, tudo depende de vários fatores, então temos que implementar e comparar haha!

      2. Tá perdoado. ;-) Mesmo assim, se sua fato sofre consultas frequentes contra todas as linhas, estamos falando de um cubo de 70 milhões de linhas, que o coloca como um tamanho médio. Nada, nada, é um tamanho de respeito, especialmente se o hardware não for topo de linha. Vale o esforço, com certeza!

        Alguns outros comentários:

        1. Neste volume vale a pena tentar um particionamento da tabela no Postgres. O truque é achar a chave de quebra, que pode ser cidade, estado, data de licenciamento etc. A melhor forma é sentar do lado do(s) usuário(s) e ver como o cubo é explorado;
        2. O cubo é servidor com o Pentaho? Se for, considere seriamente adotar tabelas pré-agregadas;
        3. Vertica e Virtualização: conversei com o pessoal que mostrou um case Vertica no PentahoDay de 2014 e eles desaconselharam o uso de máquina virtual. Mesmo assim eu fiz o teste mostrado aqui em uma máquina virtual e não ficou tão ruim;
        4. Sobre testar coisas novas: ah, meu caro, you’re in for a big smile! Existem bancos open source in memory, focados em performance. Olhe este aqui, para começar: https://www.voltdb.com/
        5. Depois de olhar o VoltDB, vá atrás do MemCache (https://memcached.org/) e do Hazelcast (https://hazelcast.com/). Eles trabalham com o Mondrian.

        Como você vê, tem novidade e coisas diferentes aí até umas horas. ;-) Um colega meu testou o HazelCast e conseguiu bons resultados. Boa idéia, sabe? Acho que vou dedicar alguns posts a esse assunto – caches e bancos em memória. Obrigado pelas idéias! ;-)

      3. Fábio,
        obrigado novamente pelo feedback, mas não entendi o seguinte trecho:

        “O cubo é servidor com o Pentaho? Se for, considere seriamente adotar tabelas pré-agregadas;”

        Já em relação aos bancos de dados in memory é uma ótima ideia, visto que reconheço o poder dos mesmos, pois já utilizei o qlikview e realmente funciona como mágica rsrs… Dou o maior apoio na criação dos posts de cache/bancos in memory visto que ainda são inexistentes em um tópico especifico do blog.

        Abraços e boas festas.

      4. Você sabe o que são tabelas pré-agregadas? São tabelas que estão no meio do caminho entre uma agregação completa (como por cidade, por mês, por produto) e a fato detalhada (que traz, seguindo o mesmo exemplo, pedido, por cliente, por produto, por dia, por loja, por hora.) Se o engine de consulta usa pré-agregadas, ele pode decidir entre agregar todas as linhas da fato inteira, ou uma tabela pré-agregada, cujo tamanho é uma fração da fato.

        Se você entendeu até aqui, sacou a vantagem: pré-agregadas aceleram a consulta sem custar hardware a mais. O preço é algum tempo a mais no final do ETL, onde as pré-agregadas são calculadas.

        O Pentaho, ou mais especificamente, o Mondrian, que é o componente do servidor que fornece os cubos OLAP, usa pré-agregadas. Portanto, se seu cliente está explorando esses dados em um Saiku ou outro cliente OLAP do Pentaho, você pode tentar conseguir alguma performance extra criando tabelas pré-agregadas. Você pode usar o PAD para isso: https://sourceforge.net/projects/mondrian/files/aggregation designer/

        Mais claro agora? ;-)

    2. Uma outra coisa que vale a pena trazer à baila é que a arquitetura de um DW não é padronizada, fixa e imutável. Você pode evolui-la conforme sua necessidade. Por exemplo, pode ser que o Postgres te ofereça uma boa velocidade de ETL. Ele pode continuar como armazém, como o componente que acumula histórico, e um Vertica pode ser montado apenas para as fatos mais pesadas, mais demandadas. Isso tem um custo inicial de um servidor extra, mas ao longo do tempo colabora para reduzir custos, já que previne uma migração de banco para uma estrutura não muito apta à tarefa de arquivar, enquanto aproveita o Vertica muito bem para a tarefa de consulta.

      Essa mistura de funções, arquivar vs. consultar, em um único banco, é uma das coisas que está na raiz dos problemas de muitos DWs, que começam a ser puxados em duas direções e acabam travando no meio – nem fazem bem uma coisa, nem outra. Meus artigos sobre Data Vault tocam nesta questão.

  2. Fábio, desculpa o meu equivoco, foi um 0 a mais só rsrs, a tabela fato tem cerca de 70 milhoes de registro e é relacionado a um sistema de veículos de um orgão federal. Portanto, não posso entrar em mais detalhes rsrs. Entretanto, muito obrigado pelas suas respostas foram bem esclarecedoras!

    Vou fazer uma breve explanação do projeto: Existe um cubo legado que contém essa fato de 70mi de registro, porém os usuários vem reclamando do tempo de resposta. Então a ideia é refazer todo o ciclo:

    1.modelagem: vi que posso melhorar em alguns aspectos;
    2.etl e reconstrução dos cubos: isso ainda não é um grande problema,pois o mesmo carrega em cerca de 4 horas mensalmente, sendo que estão fazendo truncate na fato, portanto a idéia é fazer a carga incremental diariamente utilizando o postgres para o ETL e fazer um benchmarking depois entre os 2 processos antigos e novas nas seguintes métricas: tempo de carga e consultas . Portanto, através dos resultados do benchmarking tentarei otimizar a consultas do postgres através dos exemplos dados por você, porém caso o resultado ainda não seja satisfatório eu tentarei utilizar o vertica somente copiando os dados do banco de dados relacional para o colunar, pois é necessário manter o relacional devido alguns sistemas legados utilizarem as fatos para consultas.

    obs: mesmo que o postgresql tenha resultados satisfatórios com a nova modelagem, tunning, etc. Por natureza, nós que somos de TI, temos curiosidade, então com certeza irei implementar o vertica numa máquina virtual para testes rsrs. Afinal, como você mesmo disse, tudo depende de vários fatores, então temos que implementar e comparar haha!

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s