CASE: O PostgreSQL em BI: Milhares de operações diárias consolidadas em "near-real-time"

CASE: O POSTGRESQL EM BI
Milhares de operações diárias consolidadas "near-real-time"
PGDay Campinas 2014 www.object.com.br 1
Wagner Correa Ramos
Anderson Massaharu Shibata

CASE: O POSTGRESQL EM BI - Milhares de operações diárias consolidadas "near-real-time"
Roteiro
 Apresentação da empresa do “CASE”
 Requisitos do projeto de BI
 Origem dos dados
 Modelo de dados do BI
 Escolha do SGBD (PostgreSQL)
 Tecnologia para a integração dos dados
 Tecnologias usadas
 Resultados
 Futuro

Requisitos do projeto de BI
 Aumentar velocidade da informação
para a prevenção de problemas
 Disponibilidade destas informações
dentro e fora da empresa
 Foco em qualidade dos dados
 Usabilidade
 Dados para futuras pesquisas

Origem dos dados
 Cadastros (ERP)
 Vendas
 PDV (MySQL)
 ERP (PostgreSQL)
 Compras (ERP)
 Despesas (ERP)
 Metas (Excel)
 Vendas, Compras, Despesas
 RH (WS)

Modelo de dados do BI
 Primeira tentativa
 Compras e Vendas: Tabela única com totais
por loja, mercadoria, ano, mes, dia e hora
 Problema de desempenho nas consultas e
na qualidade dos dados

 Segunda tentativa
 Compras e Vendas, ainda juntos mas com 3
tabelas (hora/dia/mês)
 Melhor desempenho nas consultas
 Ainda problemas na qualidade dos dados

 Terceira tentativa
 Nas 2 tentativas iniciais faziamos a
totalização durante a replicação dos dados
dos PDVs para o BI
 Na terceira criamos no BI as tabelas de
cupons e itens de cupons de venda
 Simplificação das transformações
necessárias nos dados entre PDVs e BI
 Qualidade dos dados 100%

 Modelo desnormalizado x normalizado
 Desempenho de consultas
 Facilidade de consultas
 Manutenção do correto histórico dos dados
em consultas retroativas
 Problema do reaproveitamento de “IDs”

 Tabelas: 63 – Views: 4
 Volume atual de dados (6/set/14)
 mercadoria: 439.033
 cupom: 9.279.743 (jan/14)
 cupom_item: 33.713.982 (jan/14)
 mercadoria_hora: 153.891.136 (mai/12)
 mercadoria_dia: 58.523.056 (nov/12)
 mercadoria_mes: 9.338.419 (nov/12)
 mercadoria_estoque: 6.452.036 (mai/12)

Escolha do SGBD
 Fatores para decisão
 Ferramentas existentes para BI
 Custo
 Facilidade de uso
 Equipe existente
 Evolução
 Gerenciadores considerados
 Oracle
 MS SQLServer
 PostgreSQL
 MySQL

Escolha do SGBD
 2012 a 2013 – Oracle e PostgreSQL
 2014 – MySQL e PostgreSQL
 Atual - PostgreSQL

Escolha do SGBD
 Algum receio em usar um software open
source como o PostgreSQL ? NÃO
 A rede Shibata usa o PostgreSQL open source
desde 2004 sem NUNCA parar por algum
motivo de bug, etc, no software.
 Alguma motivação para uso de versão
comercial do PostgreSQL ? NÃO
 Para ficar novamente dependente de uma única
empresa ?
 Melhor opção contratar suporte de empresa
nacional especializada no PostgreSQL open
source.

PostgreSQL
 100% de satisfação
 Uso de recursos avançados
 Triggers e funções executando com
excelente desempenho complexas regras
de negócio
 Regras de negócio que se implementadas
em linguagem de programação ficariam
inviáveis devido ao baixo desempenho

PostgreSQL

Tecnologia Integração de dados
 O principal requisito para o projeto de BI
foi e continua sendo a alta velocidade
na obtenção de informações
consolidadas
 Escolhemos então uma ferramenta para
garantir a consolidação “near-real-time”
 Outro requisito importante é a
disponibilidade das informações dentro
e fora da empresa

 A rede Shibata utiliza o software
replicador OBJECTMMRS com objetivo
de descentralização
 No projeto BI o objetivo é praticamente
o contrário, queremos a consolidação
dos dados em um único servidor central

 Motivos que levaram à escolha
novamente do OBJECTMMRS
 Compatível com outros SGBDs (Oracle,
SQLServer, MySQL, etc)
 Flexibilidade. Pode-se desenvolver classes
java para realização de transformações de
dados
 Qualidade dos dados

Classe customizada
OBJECTMMRS

Tecnologias usadas
 Banco de dados: PostgreSQL 8.x e 9.x
 Replicação e integração:
OBJECTMMRS 6.x e 7.x
 Interface Web do BI: PHP 5.4, Apache
2.2, HTML5
 Webservices BI: Java, Jetty, Restlet
 Desenvolvimento Mobile: Phonegap 3.5

Resultados
 Totais de vendas acumulados e
disponíveis para consultas “near-real-
time”
 Informações sobre compras também
disponíveis “near-real-time”
 BI além de mostrar resultados ajuda na
prevenção de problemas (ruptura)
 Informação disponível dentro e fora da
empresa (online e/ou offline)

Resultados

Futuro
 O volume de dados sendo armazenado
no banco BI é gigantesco. A cada ano
mais de 100 milhões de novas linhas.
 Cluster de Pg x Big Data
 Data mining
 Ferramenta para consultas/gráficos “ad-
hoc”

PGDAY Campinas 2014
 Questões / Comentários
 Obrigado a todos pela presença
 Parabéns à Dextra pela organização do
evento
 Contato
 contato@object.com.br
 www.object.com.br
 Principais projetos de replicação com
OBJECTMMRS
 TJAM, PRODAM, Exército Brasileiro, Shibata

CASE: O PostgreSQL em BI: Milhares de operações diárias consolidadas em "near-real-time"

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à CASE: O PostgreSQL em BI: Milhares de operações diárias consolidadas em "near-real-time"

Similaire à CASE: O PostgreSQL em BI: Milhares de operações diárias consolidadas em "near-real-time" (20)

CASE: O PostgreSQL em BI: Milhares de operações diárias consolidadas em "near-real-time"