Style Switcher

Layout options
  • Boxed Layout
  • Full Width Layout
Primary Color

Belo Horizonte

Porto Alegre

No eventos found

Pague em até 4x no Cartão de Crédito

Aceitamos cartões de crédito através do PayPal para pessoas físicas e depósito bancário ou boleto para pessoas jurídicas.
BotãoCheckout
Nos treinamentos que eu ministro gosto de dar exemplos reais para mostrar a aplicação prática de conceitos, nada melhor que uma experiência de trabalho real para mostrar como, quando e onde a teoria se aplica no mundo real.
Fui chamado em uma empresa de e-commerce para ajudá-los com um problema de “performance” do banco de dados que estava afetando o crescimento da empresa. Eles já tinham chamado consultores, DBAs e arquitetos de software, mas depois de ajustes em consultas, aumento da capacidade do hardware com memória e processadores, o problema de performance era resolvido por algumas semanas e depois voltava pior.

Quando sou chamado para um trabalho, sempre procuro entender o contexto do negócio. De forma bem resumida o cenário era o seguinte:
A empresa iniciou suas atividades em 2004 com a venda de produtos através de callcenter receptivo, o sistema em Java e Oracle nasceu nesta época. Por volta de 2007 os mesmos produtos eram vendidos tanto pelo callcenter quanto por um website, e no final de 2011 lançaram aplicativos mobile para iOS e Android. E foi neste momento em que os problemas de performance começaram, pois apesar dos 3 canais de vendas terem interfaces diferentes com o consumidor, por traz de tudo tem um único banco de dados.
A primeira conclusão que os gestores da empresa chegaram foi que o sistema desenvolvido ao longo de todo o período para suportar as vendas de callcenter, internet e mobile precisava de mais hardware ou pequenos ajustes em consultas, índices em tabelas. Mas por que isso não resolveu o problema de performance?

Bem nessa parte entra a segunda etapa da minha investigação. Solicitei o modelo de dados. Adivinhem, não tinha! Por que ninguém queria perder tempo com “documentação” do sistema. Fico muito p. quando alguém pensa assim, sempre falo para os meus alunos de cursos de modelagem: o modelo de dados não é uma documentação para ser feita depois do sistema pronto, modelo de dados é ferramenta de um analista de sistemas para entender, desenvolver e implementar um banco de dados. E quando é feito também serve como documentação do sistema.

Tudo bem, não tem modelo de dados, eu faço o meu. Fiz a engenharia reversa do banco de dados, peguei um programador que dava suporte a operação e fui perguntado o que tinha em cada tabela. Em pouco tempo tinha o modelo lógico e físico que eu precisava.
Agora sim, com os modelos de dados, o cenário do negócio e problema sintomático pude buscar a causa raiz. Existem várias formas de buscar a causa raiz de um problema, uma delas bem conhecida e fácil de aplicar é a dos 5 Porquês.
No caso o sintoma do problema ocorria quando em horários de pico de vendas os consumidores não conseguiam fechar pedidos pela web, os atendentes do callcenter perdiam muito tempo montando o pedido do cliente, ou ainda os usuários dos APP mobile simplesmente não conseguiam comprar e recebiam erros de timeout da aplicação. Feita a análise da causa raiz por qualquer sintoma, chegamos ao banco de dados, especificamente no conjunto de tabelas de pedidos, exatamente, pedidos, itens do pedido, situação do pedido, etc.
Mas como ainda poderiam ter problemas de performance, se o DBA fez o ajuste fino de todas as consultas envolvendo as tabelas de pedidos, reconstruiu os índices, aumentou SGA, a máquina passou de 4GB para 8GB, depois para 16GB e agora estava com 32GB. O servidor de aplicação JAVA foi melhorado, os webservices feitos e refeitos. O que mais poderia ser feito? Um cluster de máquinas, mais discos em RAID5. Quem garante que todo este investimento vai resolver o problema?
Nada disso. A solução proposta foi outra. A Gestão de dados alinhada com as necessidades do negócio. Ah! Você é maluco! O que esse papo teórico de Gestão de dados pode resolver um problema real de uma empresa de e-commerce e callcenter.

Resolvendo o problema em definitivo.
A última pergunta que eu fiz ao CEO da empresa: Qual a relação do pedido que está sendo feito hoje com os pedidos feitos no ano passado? Resposta: nenhuma relação. Isto quer dizer que o pedido de hoje não depende em nada do que aconteceu no passado, dos outros clientes e pedidos.

Mas na estrutura de banco de dados, como é um padrão, existiam 1 tabela de pedidos e 1 de itens de pedido, normal certo? Só que naquele momento da empresa a tabela já tinha cerca de 4 milhões de pedidos e 50 milhões de itens de pedidos. E com os novos clientes que começaram a acessar usando o aplicativo mobile o volume de pedidos e consultas aumentaram de forma exponencial.
Para este negócio existem 2 grandes grupos de pedidos, os pedidos que estão no processo de venda e os pedidos concluídos. No primeiro grupo temos um grande volume de acessos, consultas e inserções, mas uma quantidade pequena de algumas centenas de registros. No segundo grupo temos um volume de milhões de linhas, mas poucas consultas, somente quando um cliente deseja ver o seu histórico de pedidos, ou quando é necessário fazer um relatório de vendas semanal, mensal ou anual.
Para este negócio e nesta situação a modelagem das tabelas de pedidos deveria usar um recurso de desnormalização, o particionamento horizontal. Este recurso existe como funcionalidade de alguns bancos de dados, mas surgiu como um recurso que pode ser usado já na passagem do modelo de dados lógico para o físico. Separamos os dados em duas estruturas de pedidos, uma para os pedidos em processo de venda e outra estrutura para os pedidos concluídos.

A desnormalização usando o particionamento horizontal ou vertical é um recurso previsto como técnica de modelagem de dados quando passamos um modelo lógico para o modelo físico levando em conta os requisitos de performance, volume de registros, velocidade de crescimento e volume de acessos. Isso não é quebra-galho. Já escutei isso de pessoas que acham que conhecem de banco de dados, tanto não é que o Oracle, SQLServer e DB2 tem estes recursos nativos nas versões mais atuais. Mas mesmo não tendo este recurso no banco de dados é possível implementar o particionamento criando as tabelas e os programas que separam os dados de acordo com as regras de negócio.
Conclusão, feitas mudanças no banco de dados e programas os problemas de performance desapareceram e nunca mais voltaram. Na verdade, o hardware ficou sobrando mesmo com o negócio evoluindo rapidamente para milhares de pedidos e acessos por dia.
Para chegar a soluções mais abrangentes é preciso ter uma visão mais abrangente de como os dados, informações e conhecimento apoiam o negócio da empresa. Este é o objetivo da Gestão de Dados, que inclui o trabalhado do DBA, mas é muito mais do que isso. A Gestão de dados incluí as melhores práticas de arquitetura de dados, desenvolvimento de modelos de dados, dados alinhados com o negócio, gestão dos sistemas informacionais e transacionais, metadados e regras de negócios, qualidade dos dados, governança de dados, entre outros.

Treinamentos relacionados:
Processos de Administração de Dados com Método Ágil
Introdução à Arquitetura de Dados
Melhores práticas de Governança e Qualidade de Dados
Modelagem Multi dimensional de Dados para BI e DW
Método Ágil para Modelagem de Dados

Por: Caetano Andrade Silva
Consultor e Instrutor da CS Treina

Brasília

Curitiba

No eventos found

Newsletters

Assinar

Assine nossa newsletter e receba no sei e-mail o calendário de turmas abertas e novos treinamentos!

Onde estamos

Matriz:
Al dos Guatás, 468 sl.55
Saúde - São Paulo
CEP: 04053-041

Telefones:
(11) 4063-6450
(21) 4063-6250
(61) 4063-6350
(11) 3181-5166

Calendário

loader

Visitantes

0398378
Today
Yesterday
This Week
Last Week
This Month
Last Month
All days
82
435
1007
2930
11043
11959
398378

Forecast Today
96

21.06%
19.30%
8.10%
6.89%
0.03%
44.61%
Online (15 minutes ago):29
29 guests
no members

Your IP:54.156.92.46