Versão

Podcast
Disciplina: Projeto em ciência de dados com soluções para
processamento paralelo e distribuído de dados
Título do tema: Monitoramento e depuração
de programas paralelos.
Autoria: Yuri Sá
Leitura crítica: Henrique Salustiano Silva

Abertura:

Olá! No Podcast de hoje vamos falar sobre um caso de uma implementação de

um banco de dados paralelo nativo que deu errado.

No início do Big Data, várias empresas disponibilizaram seus sistemas de

banco de dados distribuídos com altíssima disponibilidade e performance de
forma gratuita e código aberto.

Muitos desenvolvedores não resistiram a tentação e partiram para uma

migração sem a devida análise de custo/benefício e o resultado não podia ser
outro senão o fracasso.

O caso é que estes bancos de dados são apropriados para aplicações

monstruosas, geralmente rodando em clusters enormes com um fluxo de dados
bem grande.

Quando se tenta usar o mesmo software em aplicações pequenas, para o qual

não foi projetado, ele simplesmente não exibe a mesma performance.

O pior é que muita desta performance em grandes volumes vem ao custo de

algumas características que são importantes para pequenos sistemas como,
verificação de integridade e continuidade dos dados, metadados extensos,
relacionamentos etc.

Simplesmente utilizar uma aplicação que funciona em um grande servidor

único de BD e conectar ela à um sistema distribuído não vai fazer o sistema
desfrutar da performance automaticamente.

É preciso analisar e verificar se o banco de dados era o problema para início de

conversa. Uma possível lentidão pode vir de gargalos na conexão, consultas
pouco otimizadas e até mesmo hardware inadequado ou insuficiente.

Dependendo do nível de abstração do banco de dados na sua aplicação

realmente a troca é fácil, mas não é porque é fácil que precisamos fazer.

Mas a tempestade perfeita para afundar o projeto pode estar por vir...

Digamos que por acaso tenha sido feita a migração e em uma primeira visão
parece que tudo está fluindo bem, os dados estão entrando, estão
saindo...relatórios estão sendo feitos... De repente você começa a perder
relacionamentos importantes, as Chaves Primárias começam a duplicar ao
longo do banco e você tem que parar o sistema que já está em produção para
avaliar o que pode estar dando errado.

Pois é, várias rotinas presentes em SGBDs tradicionais muitas vezes não estão
presentes em sistemas distribuídos, até mesmo pela característica de
consenso entre os servidores, e podem ser muitos os casos, como Views que
não são consolidadas, segmentação de Chaves Primárias em tabelas
especiais... São muitos detalhes! Agora estamos com o banco de dados
inválido, houve operações novas e a situação ficou grave. Se voltarmos ao
banco antigo perderemos as operações que foram feitas no banco novo, se
tentarmos arrumar o banco novo manualmente é possível que mais dados
possam perder a integridade.

Lá se vão mais noites sem dormir.

Este exemplo pode parecer exagerado, mas aconteceu com um monte de

gente boa na primeira safra de Big Data que tivemos, com a revolução das
redes sociais e a desmobilização destas ferramentas.

Como tudo na vida, para qualquer coisa dar certo, precisamos de um bom
projeto.

Fechamento:

Este foi nosso podcast de hoje! Até a próxima!