Arquivos da Tag: best pratice

Qual sistema de arquivos devo utilizar no meu banco de dados?

Publicado em por
2

A pergunta clássica que todos sempre fazem em listas de discussão, fóruns e bate-papos no IRC é “Qual o melhor sistema de arquivos eu devo utilizar para o meu banco de dados”? Para variar, fizeram novamente esta pergunta na lista do PostgreSQL.org.br

E lá fui eu responder o que para muitos é óbvio, mas para muitos não. Em primeiro lugar, deixe-me dizer que estou falando, é  claro, de sistemas de arquivos em Linux. Para outros sistemas operacionais, a coisa funciona mais ou menos assim:

É claro que boa parte dos sistemas operacionais acima também tem suporte para outros sistemas de arquivos. Mas o uso de outro sistema de arquivo é algo mais raro e atende a necessidades específicas. Também não estou falando aqui de sistemas de arquivos com propósitos especiais, otimizados para clusters, servidores de arquivos, discos SSD, etc. De fato existe uma grande variedade de  sistemas de arquivos por aí. Mas é no Linux em que encontramos uma quantidade grande de sistemas de arquivos maduros e que funcionam muito bem, com poucas ou nenhuma limitação. E é aí que a confusão está armada.

Entre os mais comuns estão o EXT2, EXT3, JFS, XFS e ReiserFS. Todos eles são bons sistemas de arquivos e levam alguma vantagem uns sobre os outros em alguma coisa. O ReiserFS é muito bom em lidar com uma grande quantidade de arquivos pequenos. O XFS é bom em lidar com arquivos grandes, e por aí vai. Existem milhares de testes e brigas intermináveis apontando qual deles é o melhor.

O Fato é que tirando a distribuição SUSE, o EXT3 é o sistema de arquivo padrão das grandes distribuições Linux. É também o único sistema de arquivos que a Oracle homologa para a instalação dos seus bancos de dados, tirando é claro o OCFS2, mas que é um sistema de arquivos para cluster, que é outra história.

Antes de mais nada, é preciso entender que em geral todos são bons e apresentam boa velocidade e segurança (ok, tirando o EXT2 neste ponto). O fato é que para cada tipo de aplicação, existe uma forma peculiar de usar os discos. E digo mais, bancos de dados de fornecedores diferentes usam o disco de forma diferente. Mais ainda, um banco de dados do mesmo fornecedor pode utilizar o disco de forma completamente diferente dependendo do tipo de aplicação que o utiliza.

Como eu já demonstrei bem antes por aqui, um banco de dados não deve em situação ideal contar apenas com uma única partição e um único disco. O SO deve ficar num lugar, os logs de transação em outro, os dados em outro lugar e por aí vai. Assim, cada um destes discos são utilizados de forma completamente diferente. Vejamos alguns pontos notáveis:

  • O  Sistema Operacional tem um perfil de uso mais comum e não é crítico em termos de desempenho. Em termos de segurança, você irá ficar muito tempo indisponível se tiver que instalar tudo novamente, mas de fato não vai perder nenhuma informação crítica. É o caso de utilizar o sistema de arquivos padrão e não tentar nenhuma configuração especial;
  • Os logs de transação possuem um perfil bem específico,  gravação sequencial em arquivos de tamanho bem definido. É claro que a gravação só vai ser sequencial mesmo se o disco físico (não o volume lógico) for utilizado apenas para isso e não tiver nenhuma outra operação paralela. Já comentei antes que os logs de transação são um ponto crítico no desempenho e na segurança de um banco de dados com grande volume de atualizações, ou OLTP. Você poderia escolher um sistema de arquivos com uma configuração bem específica só para os logs de transação;
  • Uma partição contendo tablespaces com dados históricos sem atualizações, pode utilizar um sistema de arquivos com opções mais agressivas reforçando apenas a leitura e sem preocupações com segurança como a jornalização;
  • Uma partição com índices que podem ser recriados sem prejuízo para os negócios (a recriação dos índices pode levar várias horas ou até dias) pode dispensar também preocupações com a segurança, mas não com desempenho em gravação;

Tirando estes pontos notáveis, existem algumas considerações de ordem genérica que podemos citar:

  • Embora alguns digam que em bancos de dados você pode utilizar EXT2 ou outros sistema de arquivos sem jornalização, uma vez que você já tem a “jornalização” dos logs de transação do sistemas de arquivos, a afimação só é válida se:
    • Você realiza backup físico e não apenas lógico (dump) do banco de dados periodicamente;
    • Você realiza um backup dos logs de transação arquivados para outro disco e para outro servidor/fita, com período de retenção superior ao intervalo entre os backups físicos;
    • Você está disposto a perder os últimos dados contidos do log de transação ativo, que se for perdido não poderá ser recuperado, afinal não foi arquivado e você não tem cópia em outro disco dele;
    • Você não se importa de perder tempo recuperando backups, seu banco de dados tem suporte ao PITR e você sabe utiliza-lo bem.
  • Todo sistema de arquivos destinado a guardar dados deverá lidar em geral com arquivos grandes, beirando sempre a casa do Gigabyte. Isto geralmente exclui o ReiserFS como sistema de arquivos predileto para bancos de dados. Isto não significa que ele não seja ótimo em outras situações;
  • Se você estiver com um Data Mart ou um Data Warehouse onde o perfil de uso é de cargas em lotes agendadas e poucas consultas monstruosas, utilizar tamanhos de bloco maior do que o padrão pode ser vantajoso. Mas só é vantagem neste tipo de situação, fora destas condições o efeito é o inverso;
  • Os ganhos de desempenho ao escolher o sistema de arquivos mais rápido com as configurações mais agressivas são da ordem de 5 a 20%;
  • Os ganhos de desempenho no ajuste mais agressivo num sistema de arquivos onde ficam tablespaces de uso geral podem ser de cerca de 20% em determinadas operações, mas a perda em outras operações pode ser de mais de 60%;

Se preocupe com segurança de verdade

Todo DBA que já foi acordado de madrugada para ir recuperar um banco de dados corrompido já ouviu a mesma frase “mas em X anos que eu estou aqui na mesma empresa isso nunca aconteceu”. E não raro X chega a ser maior que 5 ou até 10 anos. A verdade é que o fato de você utilizar um bom hardware, um sistema operacional estável e um bom banco de dados não significa que não vai acontecer. E só quem é chamado para consertar os desastres que ocorrem por aí pode ter uma noção de que tipo de sistemas de arquivos é mais ou menos perigoso. Você não acha que porque está X anos numa mesma empresa usando o sistema de arquivos XPTO isto significa que ele é seguro, acha?

Tudo isso para dizer claramente e em bom tom:

NÃO TROQUE SEGURANÇA POR DESEMPENHO

Pode surgir o momento em que você terá de fazer alguns ajustes de desempenho. Eles existem sim. Mas não é qualquer um sabe utilizar isso de forma segura. De fato, conheço poucas pessoas com bom conhecimento técnico que se arriscam a utilizar este tipo de coisa em ambientes realmente críticos. Então, antes de partir para o tuning do seu sistema de arquivos, tenha em mente que você tem coisas muito mais importantes que podem melhorar o desempenho do seu banco de dados:

  1. Normalização e refatoração das tabelas (ganhos de 100% a 10.000%)
  2. Reescrever consultas mal escritas (ganhos de 10% a 10.000% na consulta alterada);
  3. Configurar adequadamente o sistema operacional e o banco de dados adequadamente (ganhos de 10% a 400%);
  4. Separar o log de transação em discos a parte (ganhos de 20% a 40%);
  5. Usar RAID 0+1 ao invés de RAID 5 (ganhos de 30% a 60%);
  6. Dobrar o número de discos do seu RAID (ganho de 60% a 80%)

Ok, não leve muuuito a sério as porcentagens utilizadas aqui. Não tenho nenhuma pesquisa científica para comprovar estes dados. Um DBA mais experiente poderia discordar um pouco dos números apresentados, mas a proporção entre os itens não iria mudar muito. E de qualquer forma ele iria provavelmente concordar com a ordem de importância apresentada aqui.

Se você procura uma forma de ganhar desempenho sem ter que mexer na aplicação, os parâmetros de configuração do seu sistema operacional (particularmente limites de memória e semáforos), e do seu banco de dados (memória, checkpoints e outros) podem ter um impácto enorme. Mas o problema é que são muitos parâmetros, particularmente no banco de dados e os testes não são tão simples. O ajuste ideal pode levar meses no ambiente de produção.

De qualquer forma, sempre haverá o momento em que para aumentar o desempenho você terá que abrir mão da segurança ou colocar a mão no bolso. Muitos parâmetros e configurações que aumentam o desempenho tem impacto muito negativo na segurança . Se você não está disposto a correr riscos então saiba que o preço dos discos não é mais tão assustador quanto antigamente. Mas se você está numa daquelas empresas que não investe nem em espaço extra para guardar os dados, esta não será uma opção viável. De qualquer forma, aumentar o desempenho do hardware, costuma mascarar os problemas na aplicação. Mas é claro, que apesar da aplicação ser o primeiro alvo de otimização, em geral ele é o último a ser atacado. Seja porquê a aplicação é um pacote escrito por terceiros, ou porquê os seus desenvolvedores estão ocupados com uma nova aplicação, o fato é que falar de remodelagem e normalização de uma aplicação em produção para um desenvolvedor é pior do que ofender a mãe. Bom… na verdade dá trabalho para todo mundo, e muitas vezes até o DBA acaba fazendo vista grossa.

O mito dos discos que não falham e da luz que não acaba

É fato que os discos de hoje em dia são muto bons. Muito longe dos discos que vinham com um software para fazer formatação física pois a mídia ia se deteriorando progressivamente. Mas um dia eles podem falhar, particularmente se já estiverem em uso 24/7 há mais de 3 ou 4 anos. Mesmos os melhores discos falham e tem mais, os discos com número de série iguais tem o hábito de falhar na mesma época… como lâmpadas num grande galpão que vão queimando todas juntas. Contra a queima do disco, o seu sistema de arquivo não tem muito o que fazer, a não ser que ele tenha embutido um mecanismo de espelhamento como o ZFS tem. Usando LVM, você também consegue este tipo de funcionalidade, que pode ser uma alternativa para aqueles que não dispõem de uma boa controladora que faça espelhamento por Hardware. Há quem até prefira o RAID por software embora isso esteja longe de ser um consenso. Em todo caso, um bom storage costuma ser a resposta ideal, com monitoramento remoto e tudo o mais.

Mas há algo em que a maioria dos sistemas de arquivos são vulneráveis, a perda de energia. A jornalização foi criada exatamente para você que já viu uma falha de energia corromper todo o seu sistema de arquivos com o seu banco de dados junto.  A jonalização não é perfeita, mas melhora muito o nível de segurança. Vale citar que cada sistema de arquivos implementa a jornalização de uma forma diferente, e que o EXT2 simplesmente não o faz. Mais que isso, algumas opções de montagem dos sistemas de arquivos como o ‘writeback’ tem impacto positivo na performance, mas negativo na segurança da jornalização.  Outros parâmetros como o ‘noatime’ costumam ser mais seguros de se utilizar, e trazem algum ganho de desempenho.

Então chega uma das perguntas que produzem lembranças divertidas em muitos, mas que não foram tão divertidas na época em que ocorreram: “Se eu tenho nobreak, por que eu tenho que me preocupar com jornalização?”. Vejamos alguns bons motivos:

  • Nobreaks quebram;
  • Nobreaks que estão fora da garantia e não tem contrato de manutenção podem já estarem quebrados e você nem desconfia;
  • Nem todos testam os seus nobreaks da foram correta;
  • Nem todos habilitam o agente do nobreak para desligar gentilmente o servidor quando a bateria está no fim;
  • Um banco de dados pode demorar horas para ser desligado gentilmente quando tem muitos usuários conectados simultaneamente ou rodam longas transações;
  • As baterias do nobreak tem vida útil curta, em 2 ou 3 anos você tem
    que trocar. Tem gente que “esquece de trocar”;
  • Um nobreak com isolação total (onde a alimentação ocorre sempre
    diretamente das baterias) tem baterias com uma vida útil de pouco mais
    de 1 ano;
  • Em muitos lugares é comum haver falta de energia por mais de 3
    horas. Não tem nobreak que aguente isso. Nos final de semana a
    concessionária de energia adora fazer manutenção sem aviso prévio;
  • Você pode ter uma manutenção na rede elétrica interna do prédio e
    ficar sem energia. O pessoal da manutenção pode ter esquecido de lhe
    avisar;
  • Mesmo que você tenha um gerador, pode ocorrer de você não estar com a manutenção do gerador em dia, ou ele simplesmente estar sem
    combustível;
  • O número de equipamentos ligados ao nobreak e gerador pode ter aumentado nos últimos meses e o nobreak e/ou gerador podem não suportar a carga adicional;
  • Os servidores ou o sistema operacional  podem travar de repente. Se o servidor for um  Windows ele pode (e vai) pegar  um vírus;
  • Alguém pode desligar um servidor acidentalmente no CPD. Há não muito tempo atrás, os teclados vinham com uma infame tecla chamada “power”, que ficava ao lado da tecla delete. Você não precisava estar dentro do CPD para fazer uma besteira, bastava numa conexão remota apertar a tecla “power” sem querer….
  • Algumas vezes, mesmo quando o sistema operacional é desligado gentilmente, o banco de dados não está configurado para ser desligado gentilmente antes;
  • Agora para matar definitivamente: você sabia que todos os storages tem um nobreak adicional embutido?

O Que há de novo no mundo dos sistemas de arquivos?

Bom, a esta altura eu já poderia estar escrevendo assim:

- Espelho, espelho meu, existe sistema de arquivos melhor que o XPTO?
- Caro sysadmin, é carnaval, vai tomar uma cerveja e deixa o sistema de arquivos aí.

Mas é claro que no último e-mail da conversa na lista de discussão que deu origem ao texto que você esta lindo aqui, o Sr. Fernando Ike estragou a piada infame. Na verdade eu já estava esperando a posição dele que acabou fechando a conversa. Para quem não sabe, o Sr. Fernando Ike é um sysadmin que foi para o PGCon2008 no Canadá apresentar um trabalho de pesquisa feito junto com o Sr. Euler Taveira sobre testes de desempenho no PostgreSQL utilizando diferentes configurações de sistemas de arquivos. Vale a pena conferir aqui. E o que foi que mestre fike disse? Num futuro próximo teremos EXT4 e Btrfs.

Bom, por uma questão de sanidade mental, minha e dos meus leitores, vou deixar isso para o próximo post. Mas fiquem antenados, o mundo continua girando e as coisas estão mudando…

Um banco de dados ou um esquema por aplicação?

Publicado em por
Comentar

Há tempos atrás, escrevi um tutorial para mostrar como unificar vários bancos de dados em um único banco de dados com vários esquemas. Hoje na lista do PostgreSQL, houve uma dúvida sobre se valia a pena juntar tudo num banco de dados ou manter cada aplicação em um banco de dados diferente no mesmo servidor.

Realmente é difícil justificar o uso de bancos de dados separados. Em geral, utilizar esquemas é sempre mais indicado. Vale a pena lembrar que existem 3 níveis de compartilhamento num mesmo servidor PostgreSQL:

  • Cluster, que compartilham a mesma porta, os mesmos processos e a mesma configuração global (postgresql.conf e pg_hba.conf);
  • Bancos de Dados, que compartilham o mesmo cluster mas podem ter codificação de caracteres distintos e dependendo da configuração, podem ter usuários distintos (se ‘db_user_namespace’ for configurado como ON);
  • Esquemas, que compartilham o mesmo banco de dados;

Em geral, utilizar mais de um banco de dados num mesmo cluster pode ser válido se

  • Você precisa ter um ambiente onde o desenvolvedor precise ter poderes plenos num banco de dados de teste sem afetar outras aplicações. Isto é muito incomum, pois é normal você dar permissões para um usuário em um schema específico, mas existem ambientes de testes que podem ser um pouco extremos… Mas se você quiser soltar o desenvolvedor para brincar a vontade no seu servidor, esta pode ser uma opção. Mas jamais faça isso num servidor de produção! O ideal seria instalar o PostgreSQLlocalmente na máquina do usuário ou criar uma máquina virtual com XEN só para isso.
  • Em um provedor de serviços onde vários clientes tenham que compartilhar um mesmo servidor PostgreSQL e ao mesmo tempo ter isolação total das contas de usuários esta pode ser uma opção interessante. Vale a pena lembrar de configurar o parâmetro ‘db_user_namespace’ para OFF, opções de memória pequenas para cada banco de dados e de criar um TABLESPACE padrão para cada banco de dados procurando balancear eles entre os discos disponíveis. A partir daí cada cliente poderá colocar as suas várias aplicações em vários esquemas do mesmo banco de dados. É claro que um cliente grande vai querer ter um servidor de banco de dados dedicado, mas para clientes pequenos, isto pode ser uma opção viável.
  • Você precisa de ambientes de teste, homologação e/ou produção na mesma máquina. Em geral é melhor deixar seu ambiente de teste em outro servidor. Você vai descobrir que uma única consulta mal feita no ambiente de teste pode sentar todo o servidor… melhor evitar isso a todo o custo! Você também pode criar ambientes isolados em clusters separados e garantir mais recursos para o ambiente de testes ao ambiente de produção e ainda deixar os ambientes mais isolados utilizando portas distintas. Sempre utilize discos separados para o ambiente de produção, mesmo que esteja utilizando um cluster separado ou até mesmo uma máquina virtual XEN. Se você estiver num ambiente de produção mais exigente em termos de I/O, vai descobrir logo que mesmo com discos distintos, o limite de banda do próprio barramento interno do servidor pode se esgotar!
  • Você precisa de bancos de dados com codificações de caractere diferentes. Seria ideal você pensar em utilizar utf-8 para todas as bases se você está nesta situação. Mas isto é uma longa conversa, para lá de complicada. Em todo caso, você vai descobrir que terá problemas em manter bases com diferentes codificações de caractere. Há um certo consenso de que o futuro é o UTF-8, e há quem diga que até o Windows vai trabalhar direito com ele um dia.
  • Você precisa de configurações de desempenho diferentes para diferentes aplicações (OLTP x BI por exemplo). Bom, você pode fazer isso com esquema também, mas pode não ser tão simples se cada usuário da aplicação possuir uma conta de usuário no banco de dados. No entanto, se você quer levar isto realmente a sério, é melhor criar clusters distintos e melhor ainda, utilizar servidores distintos para cada aplicação. Afinal, você precisa de mais desempenho, não é mesmo?

Conclusão:
Se mais de uma aplicação podem conviver no mesmo servidor e no mesmo cluster, então elas podem estar no mesmo banco de dados. Existem raros casos em que isto não se aplique… mas são exceções e não a regra.

Homologar é preciso!

Publicado em por
2

Conheço muita gente que está acostumada a usar controle de versões, bug tracking e outras ferramentas importantes no desenvolviemnto de aplicações. Mas quando o assunto é banco de dados, poucos estão dispostos a investir em vários servidores de bancos de dados distintos. A situação ideal é ter

  • Um servidor em produção
  • Um servidor de homologação
  • Um servodor de testes

Mas a questão é… para que investir num servidor de banco de dados de homologação?

Bom… a realidade é que o processo de desenvolvimento só adquire um estatus suficiente para entrar em produção, após a homologação, e este não pode ser feito no ambiente de testes. Vejamos as diferenças:

No servidor de testes, você pode iniciar o desenvolvimento de uma aplicação, a partir do zero, com dados completamente fictícios e pequenos volumes. Em geral, o servidor de testes costuma ter menor capacidade de armazenamento e processamento. O DBA costuma dar um pouco mais de liberdade para o desenvolvedor neste servidor. A principal preocupação aqui é com o modelo de dados. O trabalho do AD aqui é fundamental, sendo modelo lógico o principal alvo de alterações. É na base de testes que os testes de componente ocorrem.

No servidor de homologação, os desenvolvedores perdem os seus direitos e entra em ação o trabalho do DBA. Os dados da base de produção devem ser carregados na sua totalidade (se a aplicação já estiver em produção). A conversão do modelo de dados deve ser testada. Quando a aplicação for completamente nova… um bom gerador de dados é importante. Deve-se realizar uma carga com volume compatível com o esperado após alguns anos de operação. O servidor de homologação, precisa ter uma capacidade de armazenamento semelhante a do servidor de produção, além da capacidade de processamento. Mais que isso, é importante que a arquitetura física e lógica seja o mais semelhante possível ao do servidor de produção.

É no servidor de homologação que os testes da aplicação ocorrem. Os testes de desempenho vão permitir que um bom DBA faça ajustes na estrutura física de armazenamento e sugerir ajustes no SQL da aplicação. Muitas pessoas desprezam estes testes e depois de um par de anos.. descobre que a aplicação foi mal projetada e começa apresentar graves problemas. Consertar isso depois de dois anos é realmente muito difícil. A chance de você perder o cliente ou gastar muito dinheiro para resolver o problema é grande.

Comprando Software Corporativo (parte 3)

Publicado em por
3

Requisitos para compra de software

Muito bem, chegou a hora da equipe de TI assumir o seu papel e definir quais são os requisitos técnicos que serão avaliados no processo de escolha do software. Esta é uma tarefa bastante espinhosa pois são muitas variáveis a serem consideradas. O serviço público tem novamente uma dificuldade extra, uma vez que se levantar exigências obrigatórias muito altas, corre o risco de não encontrar nenhuma empresa que atenda às suas expectativas e então toda a licitação é cancelada. Por outro lado, se pontuar poucas coisas, as empresas com sistemas de baixa qualidade ganharão a licitação por apresentarem o menor preço.

Para facilitar este trabalho, você pode fazer primeiro um brain storm e colocar no papel todos os ítens técnicos que você gostaria de encontrar no software. Depois você deve filtrar aqueles que são pouco relevantes e verificar se existem soluções que atendam aos seus critérios. Por fim você deve definir em que posição cada critério deve estar:

  • O – Requisito obrigatório: é aquele que quando não estiver presente desclassifica completamente uma proposta. Deve-se tomar um especial cuidado para não excluir de cara soluções que possam não atender um requisito específico e ainda sim ser uma opção viável.
  • Requisito desejável: é aquele que não desclassfica uma proposta mas servirá para compor uma nota técnica final. Você pode atribuir pesos diferentes para cada ítem como:
    • MD – Muito desejável (5 pontos),
    • D – Desjável (3 pontos),
    • PD – Pouco desejável (1 ponto).
  • C – Requisito contratual: é aquele que compõe uma exigência contratual obrigatória que influenciará no custo global de implantação e manutenção. Os ítens se referem em geral a forma como os serviços da empresa contratada deverão ser realizados.

Vejamos aqui alguns requisitos que você poderá querer utilizar como ponto de partida para a sua pontuação. Longe de querer apontar uma forma acabada, a intenção aqui é demonstrar um exemplo de como comparar soluções de software, sobre o ponto de vista de TI. A classificação e escolhas dos ítens variam muito em cada caso. Dependem da maturidade do mercado de software para a solução que você deseja adquirir. Os pesos atribuídos para cada ítem são mais para efeito de ilustração e devem variar com a cultura de TI existente.

Documentação Fornecida

Aqui está em jogo a capacidade do software em fornecer informação em diversos níveis em com diferentes qualidades. A qualidade da documentação está diretamente relacionada com a capacidade de manutenção do software comprado. Quanto melhor a documentação, menor o custo de manutenção e menor o tempo necessário para correções de erro e implantação de novas funcionalidades.

Ítem C O MD D PD
Dicionário de Dados contendo descrição de tabelas, chaves estrangeiras, índices, visões, sequências, gatilhos, funções, procedimentos e roles X
Diagrama Entidade Relacionamento X
Diagramas de caso de uso (UML 1.1 ou superior) X
Diagramas com regras de negócio em outro formato X
Diagramas de classes (UML 1.1 ou superior) X
Outros diagramas UML 1.1 ou superiores X
Manual do usuário impresso X
Ajuda on-line para o usuário com opção de busca X
Ajuda on-line sensível ao contexto X
Controle de versão de toda a documentação X
Atualização de toda a documentação a cada nova versão do software X

Vale aqui verificar qual é o formato em que as documentações técnicas estão disponíveis. É sempre interessante receber a documentação em formato impresso (alguns diagramas podem necessitar de papel de tamanho especial como A2 ou A1) e formato eletrônico. O formato eletrônico é mais adequado para receber quando houverem apenas pequenas alterações do software. No entanto, muitas empresas utilizam formatos que só abrem em programas específicos, dificultando a sua manipulação.

Tecnologia

Aqui a maioria das pessoas deve procurar se afastar dos modismos e procurar tecnologias já consagradas no mercado. Ferramentas proprietárias tem o azar de perderem o suporte depois de algum tempo, o que pode causar transtorno a longo prazo. Deve-se evitar ferramentas pouco robustas como geradores de código e RAD.

Um cuidado especial deve ser tomado com custos relacionados a tecnologias proprietárias. O custo das licenças deve ser contabilizado no custo total de implantação. O custo de manutenção destas ferramentas também deve ser contabilizado no custo total de manutenção. Particularmente, a maioria das linguagens de programação não exigem licenças de uso para executar a aplicação final, no entanto existem ferramentas que utilizam interpretadores que convertem o código da aplicação em código de máquina, necessitando de licenças por conexão ou por processador.

Ítem C O MD D PD
Uso de SGDB relacional multiplataforma compatível com a linguagem SQL X
Uso de protocolo de comunicação TCP/IP X
Uso de servidor de aplicação multiplataforma X
Interface com usuário multiplataforma X

Se possível dê preferência (colocando como ítem desejável) por tecnologias que sua equipe já tem experiência, principalmente se houver a intenção de adquirir o código fonte do software. Uma atenção especial neste sentido deve ser dada às tecnologias de comunicação e de banco de dados. Você pode ser obrigado a fazer investimentos significativos de precisar suportar tecnologias novas nesta área.

Arquitetura

A arquitetura do software é uma área importante no mundo corporativo. Softwares cliente-servidor estão sendo aposentados por apresentarem difícil manutenção e baixa escalabilidade.

Ítem C O MD D PD
Uso de 3 camadas X
Uso de MVC X
Uso de framework de software
 X

Desenvolvimento WEB

Este ítem está destacado aqui por apresentar uma série de especificidades que merecem atenção especial. As aplicações web tem inúmeras vantagens que fogem do escopo deste texto, no entanto, uma boa aplicação deve atender a alguns critérios mínimos que se esquecidos podem trazer surpresas desagradáveis para os usuários. As interfaces WEB tem se tornado muito populares, mas não são adequadas ainda quando você precisa de entrada de grande volume de dados ou quando precisa de ferramentas gráficas de edição avançadas. Se você não pretende utilizar aplicações WEB, você pode pular esta parte.

Ítem C O MD D PD
Homologação nos navegadores IE 6.0, Firefox 1.0 e Safari 1.0 e todas versões superiores X
Possuir CSS 1.0 válido X
Possuir HTML ou XHTML válido X
Utiliza servidor web multiplataforma X
É plenamente funcional sem Java instalado no cliente X
É plenamente funcional sem JavaScript habilitado X
Possui suporte a https X

A parte mais importante aqui é garantir que a aplicação WEB seja escrita utilizando os padrões da W3C, garantindo que a aplicação funcione em diferentes situações.

Metodologia de desenvolvimento

A metodologia de desenvolvimento adotado está diretamente relacionada com o risco da empresa possuir métricas capazes de cumprir prazos e orçamentos. Uma metodologia formal bem documentada e aplicada deve trazer segurança o processo de desenvolvimento. Na área corporativa, a certificação CMM e CMMI são sinônimos de qualidade nesta área. No entanto, nem sempre se encontra fornecedores com este tipo de certificação para o tipo de software que se deseja adquirir. O processo de certificação CMMI custa atualmente cerca de U$ 400 mil, sendo assim, a SOFTEX criou uma iniciativa de certificação nacional chamada MPS.BR baseado no CMMI que está permitindo fábricas de software de menor porte alcançar uma certificação. O MPS.BR é ainda muito novo, mas estima-se que um número cada vez maior de pequenas e médias empresas adotem esta certificação no Brasil.

Deve-se ter em mente que quanto mais crítico e complexo for o software, mais importante será a contratação de uma empresa com certificação.

Ítem C O MD D PD
Certificação CMM ou CMMI nível 3 ou superior X
Certificação CMM ou CMMI nível 2 X
Certificação ISO 15504 nível 3 ou superior X
Certificação ISO 15504 nível 2 X
Certificação ISO 12207 X
Certificação MPS.BR níveis F e G X
Certificação MPS.BR níveis E ou superior X

Caso você não encontre empresas certificadas que forneçam o software desejado, você terá que pensar na seguinte tarefa: como verificar se um fornecedor possui um modelo de desenvolvimento confiável onde seja visível as etapas clássicas do desenvolvimento de software (análise, especificação, projeto, implementação, teste, documentação, treinamento, implementação e manutenção). Segue alguns indicadores que podem ser utilizados.

Ítem C O MD D PD
Organograma detalhado da equipe de desenvolvimento X
Descrição detalhada das funções da equipe de desenvolvimento X
Modelo de Processo de Desenvolvimento de Software formalizado X
Utiliza RUP X
Utiliza controle de versão do código fonte X
Possui equipes distintas para

  • Análise e projeto
  • Desenvolvimento
  • Testes
 X
Possui equipe distinta para gerência de projetos X
Realiza testes do tipo Caixa Branca X
Realiza testes do tipo Caixa Preta X
Realiza testes do tipo Caixa Cinza X
Realiza testes de unidade, integração e sistema X

Usabilidade

A usabilidade diz respeito a facilidade com que o usuário lida com a aplicação. Em geral, uma boa usabilidade garante maior produtividade e satisfação e menor ocorrencia de erros por parte do operador do software.

Ítem C O MD D PD
Interface e menssagens traduzidas para o Português do Brazil. X
Validação dos tipos dados inseridos X
Exibe falhas de validação após a digitação de cada campo X
Exibe apenas as funções ativas na tela X
Solicita confirmação do usuário para ações destrutivas ou não reversíveis X
Realiza paginação de listas X
Possibilita a inserção de texto com letras maiúsculas X
Possibilita plena navegação na aplicação sem uso do mouse X
Tabulação dos campos segue a órdem em que aparece na tela X
Possui busca fonética no Português do Brasil em campos de texto X
Exporta relatórios no formato CSV X
Exporta relatórios no formato PDF X
Exporta relatórios no formato MS Word 2000 ou superior X
Exporta relatórios no formato MS Excel 2000 ou superior X
Exporta relatórios no formato ODF X
Permite que o operador selecione um tema em alto contraste X
Permite que o operador aumente o tamanho da fonte padrão do texto X
Possui teclas de atalho para as principais funções e menus X
Sinalização gráfica informando o status de operações longas ou em várias etapas. X
Botões exibem dicas quando o ponteiro do mouse para sobre eles X

Interoperabilidade

Esta categoria diz respeito a capacidade do sistema de se integrar com os seus demais sitemas legados ou que possam vir a ser adquiridos futuramente. Suportar protocolos e padrões abertos são requisitos obrigatórios. A questão de interoperabilidade é tão importante que o Governo Federal criou o e-PING que é um documento trata com detalhes o assunto. A versão 1.0 do e-PING foi publicada em 2005 e continua sendo atualizada constantemente, se tornando uma referência obrigatória nesta área.

Segurança e Auditabilidade

Esta categoria de requisitos visa garantir a segurança e integridade das informações contidas no sistema bem como rastrear possíveis problemas ocorridos durante a operação do software.

Ítem C O MD D PD
Utiliza integridade referencial no banco de dados X
Utiliza controle de transações para operações concorrentes X
Não registra usuários da aplicação como usuários do banco de dados X
Armazena senhas de usuários em formato criptografado X
Registra histórico de operações realizadas pelos usuários X
Registra erros de importação de dados externos
Registra erros da aplicação dentro do servidor X
Possui busca nos registros históricos por nome de usuário, data e tipo de operação X
Proteção contra injeção de SQL X
Criação de perfis de usuários X
Atribuição de usuários ou perfis de usuários a um perfil de usuário.
Atribuição de permissões para cada funcionalidade por usuário X
Atribuição de permissões para cada funcionalidade por perfil de usuário X
Atribuição de permissão para cada usuário a uma faixa de valores em funcionalidades específicas X
Possibilidade de inativar usuários por período determinado X
Possibilidade de inativar usuários por período indeterminado X
Possibilidade de inativar grupos de usuários por período determinado X
Possibilidade de inativar usuário em data prédeterminada X
Expira seção do usuário após determinado de inatividade X

Implantação e Manutenção

Este ítem descreve como deve ser o processo de implantação e manutenção. Os prazos aqui definidos tem impacto direto nos custos de implantação e manutenção do Software.

Ítem C O MD D PD
Importação, checagem de consistência e remodelagem de dados já existentes para o novo software X
Análise de requisitos, adequação do software e testes X
Implantação de funcionalidades principais em até 6 meses após início da vigência do contrato X
Implantação de funcionalidades secundárias em até 12 meses após início de operação das funcionalidades principais X
Treinamento dos usuários do software antes da implantação do Software X
Treinamento da equipe de TI demonstrando o modelo de dados do Software X
Treinamento ou reciclagem de usuários anualmente após implantação do Software X
Criação de interfaces com outros softwares já existentes ou que venham a ser implantados em até 20 dias úteis X
Implantação ou alteração de funcionalidades por força de alteração na legislação federal, estadual ou municipal X
Correção de erros críticos em até 4 horas X
Correção de erros graves em até 24 horas X
Correção de demais erros em até 5 dias úteis X

Aqui, é possível que alguns fornecedores lhe digam que não tem condições de cumprir alguns prazos exigidos. Não deve-se descartar imediatamente estas empresas. Se o fornecedor adquiriu uma boa avaliação nos requisitos de metodologia de desenvolvimento, e possui uma equipe de desenvolvimento com um porte mediano em comparação aos demais fornecedores, é possível que seus prazos sejam realmente impraticáveis. É recomendável discutir esta questão com outros fornecedores e avaliar se os prazos são viáveis e se for o caso altera-los.

Equipe de desenvolvimento

Este grupo de requisitos visam medir a qualidade da equipe de desenvolvimento, bem como o porte da mesma. Uma grande equipe garante que a simples saída de um funcionário do fornecedor não vá comprometer o projeto como um todo além de permitir a alocação de mais recursos em épocas de grandes demandas.

Ítem C O MD D PD
50 ou mais pessoas da equipe de desenvolvemento com jornada acima de 30 horas semanais em regime CLT X
10 ou mais membros da equipe de desenvolvimento com mestrado ou experiência comprovadas na área de desenvolvimento superior a 10 anos X
25 ou mais membros da equipe de desenvolvimento com nível superior ou experiência comprovadas na área de desenvolvimento superior a 5 anos X
5 ou mais membros da equipe de desenvolvimento com certificação PMP ou experiência comprovada na área de desenvolvimento superior a 5 anos X
5 ou mais membros da equipe de desenvolvimento com experiência comprovada como DBA superior a 5 anos X
5 ou mais membros da equipe de desenvolvimento com experiência comprovada em teste de software superior a 5 anos X

Inteligência em bancos de dados

Publicado em por
5

Todo desenvolvedor que tenha um conhecimento razoável sobre banco de dados já passou pela dúvida sobre como lidar com a possibilidade de concentrar boa parte das regras de negócio dentro do banco de dados.

Atualmente, com a disponibilidade de várias linguagens de programação, isto se torna cada vez mais tentador: a Oracle possui além do consagrado PL/SQL, suporte a Java, o PostgreSQL chegou num estado de arte suportando uma infinidade de linguagens de programação dentro de seu SGDB e agora já faz um ano que o MySQL também possui sua própria implementação de linguagem procedural.

Mas o uso desgovernado deste tipo de expediente pode trazer algumas desvantagens. Longe de querer ditar melhores práticas, gostaria aqui de discutir um pouco este tema que tem me intrigado por algum tempo.

Nos primórdios da informática, onde reinavam solenes apenas os computadores de grande porte, não havia a opção de distribuir a carga de processamento em várias máquinas separadas. Os SGDBs relacionais também começaram a nascer somente no final da década de 70 com o DB2, Oracle e Ingres. Sendo assim, toda a aplicação se concentrava em geral na mesma máquina.

Com o surgimento dos microcomputadores veio a revolução da arquitetura cliente-servidor no final da década de 80. A idéia era criar aplicações rodando em microcomputadores (clientes) e armazenar as informações em SGDBs que ficassem em máquinas mais confiáveis (servidores). Com isso foi possível adquirir servidores com um preço bem mais acessível que os computadores de grande porte, uma vez que a carga de processamento da aplicação ficou distribuída nos microcomputadores dos usuários.

Nesta época, linguagens como o VB e o Delphi invadiram o mercado construindo aplicações cliente servidor com pães numa padaria. As aplicações cliente-servidor em boa parte foram muito bem sucedida, mas em ambientes corporativos elas começaram a apresentar uma performance muito insatisfatória. Conforme o tamanho do código cresce e as aplicações vão ficando mais pesadas várias coisas acontecem:

  • O código fica difícil de manter (bem, isto não é nenhuma novidade…)
  • Em transações longas, onde muito cálculo é utilizado, as máquinas utilizadas no cliente tem baixa capacidade de processamento, tornando a operação lenta.
  • Em transações longas com várias consultas ao banco de dados, o tráfego de rede é muito alto e gera um gargalo de desempenho.
  • Pequenas falhas na rede durante o processamento de transações longas podem no mínimo obrigar toda a operação a ser reiniciada.

É neste ponto em que entra em cena a linguagem procedural embutida no banco de dados. Com isso, é possível disparar gatilhos em circunstâncias determinadas e executar procedures e funções dentro do SGDB. O ganho de velocidade em aplicações cliente-servidor é realmente fantástico em transações longas.

Mas como tudo na vida , algumas pessoas se empolgaram! A idéia destas pessoas foi a de utilizar as aplicações no cliente apenas para exibir e receber informações, deixando todo o processamento das informações dentro do SGDB. Uma vantagem interessante desta técnica ocorre quando você possui mais de uma aplicação acessando o mesmo banco de dados. Um exemplo disto poderia ser uma aplicação cliente-servidor tradicional utilizada para alimentar e processar as informações, uma planilha extraindo informações complexas do banco de dados e uma aplicação web fazendo consultas de informações específicas. Neste ponto, centralizar toda a “inteligência” ou “regras de negócio” dentro do SGDB facilita a vida de quem tem que manter o código destas diferentes aplicações.

E qual a desvantagem disto? Bem, os ajustes de desempenho do SGDB tem que mudar drasticamente. Antes a coisa mais importante no desempenho de um banco de dados transacional era a velocidade dos seus discos. Com o acúmulo de tarefas de processamento da aplicação dentro do SGDB na mesma máquina o processador começa a assumir um papel cada vez mais importante. O resultado disto pode ser um SGDB muito lento.

Enquanto isto novas tendências de mercado começaram a ganhar força: Programação Orientada a Objeto e Aplicações Web. Na programação orientada a objeto, as linguagens procedurais perdem seu papel, pois estão muito mais próxima da lógica relacional dos SGDBs, embora o Sr. C. J. Date afirme que a maior parte dos fundamentos da P.O.O. estão na teoria relacional. Seja como for, outra tendência que ganhou força com a orientação a objetos é a programação em camadas. Com isso, o aplicativo começa a ser dividido em unidades funcionais, sendo que algumas delas certamente ficarão a cargo de servidores dedicados com maior capacidade de processamento, e conexão de rede dedicada com o SGDB. O mesmo acontece naturalmente em aplicações Web onde o processamento não é realizado em um computador cliente e sim no servidor web (ou em mais servidores se a aplicação for realizada em várias camadas).

Hoje se fala muito em camadas de abstração de bancos de dados e em frameworks MVC. Eles permitem que você desenvolva a aplicação sem se preocupar com qual banco de dados está utilizando. Desta forma, as linguagens procedurais nos SGDBs perderiam completamente sua função! A idéia é realmente tentadora.

No entanto, quando estudamos as boas opções no mercado, verifica-se a existência de brechas para enviar comandos específicos para cada SGDB. Isto ocorre porque se a abstração de SGDB fosse perfeita, certamente não precisaríamos de diferentes SGDBs no mercado. Há momentos em que é preciso acessar funcionalidades específicas de cada SGDB que as camadas de abstração não são capazes de lidar diretamente. Quando se precisa de funcionalidades avançadas e/ou alto desempenho em longas transações, as linguagem procedurais ainda são utilizadas mesmo em aplicações com várias camadas como no modelo MVC.

É claro que as camadas de abstração de dados tendem a evoluir, assim como o padrão SQL tem evoluído. No entanto estamos longe de uma padronização das linguagens procedurais dentro de bancos de dados, além de haverem novas funcionalidades sendo implementadas todos os dias nos SGDBs relacionais. Dito isto, é provável que aplicações continuem se beneficiando de camadas de abstração de dados, no entanto elas não cobrirão plenamente as necessidades de grandes aplicações corporativas, devendo haver sempre brechas para acessar diretamente as funcionalidades especificas de cada SGDB.

Enfim não existe uma regra clara para utilização de linguagens procedurais dem SGDBs. Existem funcionalidades como prover auditabilidade, gerar logs e realizar a carga de dados complexos onde estes são consagrados, além do processamento de longas transações com velocidade e confiabilidade ainda imbatíveis.

Em sistemas pequenos, a centralização da inteligência da aplicação dentro de SGDBs é aceitável, porém com o aumento de aplicações Web e frameworks como o Ruby On Rails, esta não parece ser uma tendência de longo prazo.

Por fim, este assunto é bastante polêmico e não existem regras formais para o uso de linguagens procedurais em SGDBs. A criatividade e o bom censo dos desenvolvedores e DBAs podem sempre apontar para novos rumos ou demonstrar equívocos.

Se você tem uma opinião diferente ou quer acrescentar alguma coisa, deixe seu comentário abaixo.