Arquivo da tag: hardware

O desenvolvimento ágil funciona em projetos de hardware?

Vários profissionais de TI tem trazido à tona recentemente a questão da aplicação das práticas ágeis no desenvolvimento de hardware. Nil Johnson escreveu um artigo na Electronic Engineering Times (EETimes): Desenvolvimento ágil de hardware – sem sentido ou necessidade?

Ele colocou a questão:

Deve haver um debate quando se trata de aplicar o Agile no desenvolvimento de hardware? Deveriam os valores e princípios que guiam as equipes ágeis de software também guiar os times que desenvolvem para sistema operacional (System on Chip teams) ; ou as diferenças entre estas duas disciplinas seria muito grande?

Ele continua com uma discussão sobre os valores do Manifesto Ágil e como estes valores formam a base da abordagem ágil no desenvolvimento de software. Ele coloca a questão – Poderia o mesmo funcionar para o desenvolvimento de hardware? – e comenta:

Para qualquer um que vê o desenvolvimento de hardware como um processo criativo, é difícil negar que os valores do manifesto são diretamente aplicados. Mas apenas considerar um conjunto de valores não é suficiente. De certo modo, valores abstratos precisam se traduzir na prática. Felizmente, times de software têm criado práticas que abordam os valores ágeis e muitas delas podem ser aplicadas diretamente também no desenvolvimento de hardware.

Ele reconhece as diferenças entre as abordagens do desenvolvimento de software e de hardware encorajando os times de hardware a abraçarem as práticas ágeis. Ele usa a prática do continuous delivery (entrega contínua) como um exemplo:

Uma prática de destaque é aquela de implantação rápida e contínua aos clientes. Para muitos times ágeis de software, implantação contínua é absolutamente crítico para o sucesso. Infelizmente, sua aplicabilidade no desenvolvimento de hardware – ou a falta dela – tende a ser usado para desacreditar o Agile totalmente. Para desenvolvimento ASIC em particular, implantação contínua não é realista; mas uma prática não ser realista não deve ser motivo de descrédito do conjunto de práticas. Nenhum time ágil de software realiza todas as práticas ao pé da letra; logo não se pode esperar o mesmo de um time de desenvolvimento de hardware.

Ele conclui com um pedido de mudança no foco das organizações de hardware:

Mudanças acontecem no desenvolvimento de hardware. Independentemente se são mudanças nas especificações, na rotatividade de funcionários, na dinânica do time ou novas tecnologias. Não há como evitar isso. As equipes que deixarem de lado os conceitos de Dilbert e as políticas internas para uma forma mais apurada e uma visão mais humana do desenvolvimento de hardware, retratada pelo manifesto, vai fazer desta mudança uma vantagem. Aos times que não se abrirem a esta mudança, irá restar o exercício fútil de tentar encaixar o “quadrado” dos tradicionais processos bem definidos no “buraco redondo” que é o desenvolvimento de hardware atual.

Larry Maccherone escreveu recentemente algo similar sobre as As 10 questões principais sobre quando usar Agile em projetos de hardware.

Ele elenca uma lista de questões e respostas a fim de auxiliar nas decisões sobre a aplicação de abordagens ágeis em projetos de hardware:

  1. As práticas e processos ágeis são efetivos na condução de projetos que não são de software (firmware, eletrônicos, mecânicos, etc.)?
  2. Quais ajustes são necessários no framework de processo Scrum para funcionar bem para estes projetos?
  3. Quais ajustes são necessários em nossas expectativas sobre funcionalidades comerciais mínimas, design emergente e definição de Scrum?
  4. Quais ajustes em nossas expectativas são necessárias acerca de histórias?
  5. Como fica a questão de priorizar histórias estritamente pelo valor gerado ao usuário final?
  6. Deveriam as histórias de usuário ser nossa única ferramenta de gerenciamento de requisitos?
  7. Se histórias de usuário não são nem requisitos oficiais do Scrum, então porque não devemos usar somente nossas práticas tradicionais de requisitos?
  8. O que fazer quando precisamos enviar um protótipo ao fornecedor e não é possível ser feito dentro de uma iteração?
  9. O que fazer com dependências e analise do caminho crítico?
  10. Talvez não precisemos da analise contínua do caminho crítico, mas ainda temos especialistas que não são dedicados permanentemente ao time. Como lidar com isso?

Para cada questão que ele lista uma resposta curta é dada seguida de uma discussão de abordagens práticas para resolver as potenciais incompatibilidades e como endereçá-las.

As práticas ágeis poderiam ser usadas no desenvolvimento de hardware? Quais mudanças seriam necessárias fazê-las funcionar neste contexto?

Os diferentes tipos de Web Hosting

A escolha do serviço de alojamento pode tornar-se uma dor de cabeça grande para os Webmasters, principalmente no que respeita ao operador escolhido. Em Portugal este é um mercado que, na minha opinião, está saturado – muito por culpa de operadores menos bons que desaparecem do mapa sem deixar contacto. Como é óbvio, uma atitude dessas pode causar muitos constrangimentos a muitos Webmasters, e até a empresas. Eu sou da opinião que mais vale gastar mais alguns escudos para não ter más surpresas. Mas deixo essa discussão para mais tarde.

Outra escolha pertinente é o tipo de alojamento que se deve escolher. Esta escolha pode depender dos mais variados factores, como por exemplo o retorno que tem o site, ou a utilização de recursos do site. Apenas para dar um exemplo, o Moodle é um sistema pesado, especialmente se tiver integrados alguns módulos, sendo aconselhável uma solução mais dedicada.

Alojamento gratuito

Era bom todos termos um serviço de alojamento fiável e gratuito. Mas podem esquecer… para evitar dissabores, não recomendo alojamentos gratuitos a quem deseja ter o mínimo de garantias. Normalmente quem oferece este tipo de serviço tem os servidores com centenas de sites, o que causa muita instabilidade no serviço. Também por norma não existe suporte técnico qualificado, pelo que qualquer problema que tenha pode demorar alguns dias para se resolver, isto se conseguir resolvê-lo.

Alojamento partilhado

Este é o serviço utilizado por cerca de 90% dos sites. Normalmente são dadas garantias básicas de funcionamento e de suporte técnico. Não obstante, não nos esqueçamos que estamos a falar de um serviço partilhado por vários clientes, e que infelizmente há clientes mal intencionados, ou então sem saber o que estão a fazer, e que em poucos minutos podem sobre-carregar o serviço, ao enviar uma simples newsletter. Em Portugal, já a maioria dos operadores proíbem o envio de newsletters em ambiente partilhado. No entanto, esse processo só é verificado quando o servidor já está com um load alto, o que gera incapacidade no servidor.

VPS – Virtual Private Servers

Os VPS são uma espécie de servidor dedicado, mas com dependência de uma máquina principal, que também pode ter anomalias que interfiram com a VM (virtual machine). A nível de software, normalmente é configurado pelo cliente, vindo com uma instalação base. Alguns operadores podem ajudar noutras configurações iniciais, mas depois o trabalho é, regra geral, feito pelo cliente. Para ter um VPS, é recomendado ter alguns conhecimentos de como funciona o sistema ou o painel de controlo, já que em caso de falha é pouco provável ter a ajuda da empresa de hosting, a menos que se chegue a algum acordo, que normalmente inclui pagamentos extra.

Servidor Dedicado

Ao contrário do VPS, em que os recursos de um servidor principal são divididos por várias VM’s, num servidor dedicado o normal é ter um servidor (máquina) exclusiva, em que os recursos de hardware são garantidos. É apenas aconselhável para quem já tem conhecimentos suficientes para administrar a máquina sem ajuda de terceiros. Infelizmente já encontrei por aí empresas que falam em servidor dedicado, mas na verdade depois somos confrontados com nada mais do que um servidor virtualizado, embora com hardware dedicado.

Cloud Hosting

Este é o futuro. O Cloud Hosting é aplicado quando temos uma garantia de 100% de uptime de hardware, uma vez que temos vários servidores a funcionar em conjunto, e uma máquina é automaticamente substituída quando tem problemas ou está mais carregada de pedidos. Mais uma vez, há empresas que confundem as coisas… fornecem um serviço de alojamento partilhado, e chamam-lhe Cloud Hosting. É necessário ter alguma atenção ao nome que damos aos produtos.

Resumo

Na prática, estamos perante vários tipo de Web Hosting que, embora o objectivo seja o mesmo em 95% dos casos (colocar um site online), diferem no que toca à capacidade de alteração de configurações, dependência e partilha de recursos e, claro, o preço.

Apesar de existirem ainda mais algumas formas de alojamento (Cluster por exemplo), não as vamos explicar agora, até porque são soluções normalmente utilizadas apenas por empresas já com uma dimensão razoavelmente grande, e com uma equipa informática.

Fonte: Bruno Miguel/phpportugal

Escolhendo a ferramenta certa para o banco de dados NoSQL

Meu Deus, existem tantas ferramentas para armazenamento do NoSQL por aí. É quase tão ruim quanto as marcas de bebidas esportivas, ou de água. Você notou que alguns supermercados imensos têm corredores inteiros dedicados ao que bebemos?

Como um administrador ou gerente de sistemas de TI, às vezes é muito difícil comparar várias ferramentas do NoSQL. Isso envolve a consideração das suas necessidades computacionais especiais, e o alinhamento das mesmas ao que é disponibilizado no mercado, combinando o que é certo para a sua empresa e então tomando a decisão certa!

É por isso que Monitis, um serviço tudo-em-um de monitoramento de performance de redes e sistemas para sysadmins, está publicando uma série de blogs que tinham o objetivo de oferecer um guia compreensivo para a tecnologia e para as marcas do NoSQL. O objetivo é te ajudar a fazer a escolha certa que atende à necessidade específica da sua empresa.

Por que deveríamos nos importar? – você pode se perguntar. Cada vez mais, nossos clientes, que dependem da nossa habilidade de monitorar servidores e redes e de várias outras métricas-chave dia e noite a partir da nuvem, também querem nosso conselho sobre qual tipo de tecnologia de banco de dados escalável e robusto usar. Portanto, estamos sendo prestativos!

Portanto, apresentaremos pesquisas em ferramentas populares existentes de armazenamento de dados NoSQL, que têm o intuito, geralmente, de armazenar quantidades imensas de dados sem precedentes, oferecer escalabilidade horizontal e flexível, e fornecer o processamento de consultas absurdamente rápido. Também chegaremos ao âmago da questão e iremos comparar vários bancos de dados NoSQL bastante conhecidos, como Cassandra, MongoDB, CouchDB, Redis, Riak, HBase e outros.

Neste primeiro artigo, vamos discutir sobre a razão pela qual a tecnologia NoSQL é importante.

Então, o que é NoSQL?

Geralmente, o NoSQL não é relacional e foi projetado para armazenamento distribuído de dados, para dados de grande escala (p.e. o Facebook ou o Twitter acumulam terabits de dados todos os dias para milhões de usuários), e não existem fixed schemas e joins. Enquanto isso, sistemas de gerenciamento de bancos de dados relacionais (RDBMS) geram escalonamento ao deixar seu hardware cada vez mais rápido e adicionando memória. O NoSQL, por outro lado, pode tirar vantagem de “escalar para baixo” – o que significa distribuir o carregamento entre muitos outros sistemas de conveniência.

O acrônimo NoSQL foi criado em 1998 e, enquanto muitos pensam que o NoSQL é um termo depreciativo criado para tirar sarro do SQL, na verdade ele significa “Não Somente SQL – Not Only SQL”. A ideia é que ambas tecnologias (NoSQL and RDBMSs) podem coexistir e cada uma delas tem o seu lugar. Empresas como Facebook, Twitter, Digg, Amazon, LinkedIn e Google usam o NoSQL de alguma maneira – então o termo tem estado nas notícias atuais nos últimos anos.

Qual o problema com RDBMSs?

Bom, nada, na verdade. Eles apenas têm suas limitações. Considere estes três problemas com RDBMSs:

RDBMSs usam uma abordagem de normalização com base em tabela de dados, e esse modelo é limitado. Certas estruturas de dados não podem ser representadas sem adulteração dos dados, programas, ou ambos…

Elas permitem versionamento ou atividades como: Criar, Ler, Atualizar e Deletar. Para banco de dados, atualizações nunca deveriam ser permitidas, porque elas destroem a informação. Em vez disso, quando os dados mudam, o banco de dados deveria apenas adicionar outro registro e anotar devidamente o valor para aquele registro.

A performance é perdida quando o RDBMSs normaliza os dados. O motivo: a normalização pede mais tabelas, joins de tabelas, chaves e índices e, dessa maneira, mais operações internas do banco de dados para implementar as consultas. Logo logo, o banco de dados começa a crescer para o tamanho de terabytes, e é aí que as coisas começam a ficar lentas.

As quatro categorias do NoSQL

1. Armazenamento Chave-Valor

A ideia principal aqui é usar uma tabela hash na qual há uma chave única e um indicador de um dado ou de um item em particular. O modelo chave-valor é o mais simples e fácil de implementar. Mas ele é ineficiente quando você somente está interessado em consultar ou em atualizar parte de um valor, entre outras desvantagens.

  • Exemplos: Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.
  • Aplicações típicas: Cache de conteúdo (Foco em escalar para imensas quantidades de dados, criado para lidar com carregamento massivos) logging etc.
  • Modelo de dados:Coleção de pares de chave-valor.
  • Pontos fortes: Pesquisas rápidas.
  • Fraquezas: Dados armazenados não têm schema.

2. Armazenamento Column Family

Foram criadas para armazenar e para processar grandes quantidades de dados distribuídos em muitas máquinas. Ainda existem chaves, mas elas apontam para colunas múltiplas. As colunas são organizadas por família da coluna.

  • Exemplos: Cassandra, HBase, Riak.
  • Aplicações típicas: Sistemas de arquivos distribuídos.
  • Modelo de dados: Colunas → famílias de colunas
  • Pontos fortes: Pesquisas rápidas, boa distribuição de armazenamento de dados.
  • Fraquezas: API de baixo nível.

3. Banco de Dados orientado a Documentos

Foram inspirados por Lotus Notes e são similares ao armazenamento chave-valor. O modelo é basicamente documentos versionados que são coleções de outras coleções de chave-valor. Os documentos semi-estruturados são armazenados em formatos como JSON. Bancos de dados de documentos são essencialmente o próximo nível do chave-valor, permitindo valores aninhados associados a cada chave. Bancos de dados de documentos suportam as consultas mais eficientemente.

  • Exemplos: CouchDB, MongoDb.
  • Aplicações típicas: Aplicações Web (Similar ao armazenamento chave-valor, mas o BD sabe qual é o valor).
  • Modelo de dados: Coleções de coleções de chave-valor.
  • Pontos fortes: Tolerante a dados incompletos.
  • Fraquezas: Query performance, sem sintaxe de query padrão.

4. Banco de Dados orientado a Grafos

Em vez de tabelas com linhas e colunas e a rígida estrutura do SQL, um modelo gráfico flexível é usado e que pode, mais uma vez, ser escalado através de varias máquinas. Bancos de dados NoSQL não fornecem uma linguagem query declarativa de alto nível como o SQL para evitar tempo extra em processamento. Em vez disso, executar o querying nesse banco de dados é um modelo de dados específico. Muitas das plataformas NoSQL permitem interfaces RESTful nos dados, enquanto outras oferecem query APIs.

  • Exemplos: Neo4J, InfoGrid, Infinite Graph.
  • Aplicações típicas: Redes Sociais, Recomendações (Foco em modelar a estrutura dos dados – interconectividade)
  • Modelo de dados: Grafo de Propriedades – Nós.
  • Pontos fortes: Algoritmos gráficos, p.e. caminho mais curto, conectividade, relacionamentos n degrees etc.
  • Fraquezas: Tem que atravessar todo o gráfico para obter uma resposta definitiva. Não é fácil de agrupar.

Geralmente, os melhores lugares para usar a tecnologia NoSQL é onde o modelo de dados é simples; onde flexibilidade é mais importante que controle rígido sobre estruturas definidas de dados; onde alta performance deve existir; consistência de dados rígida não é necessária; e onde é fácil mapear valores complexos para chaves conhecidas.

Alguns exemplos de quando usar NoSQL

  • Logging/Arquivamento. Ferramentas de Log-mining vêm a calhar porque elas conseguem acessar logs através de servidores, relacioná-los e analisá-los..
  • Insight em computação social. Muitas empresas hoje forneceram a seus usuários a habilidade de atuar na computação social através de fóruns de mensagens blogs etc.
  • Integração de feed de dados externos. Muitas empresas precisam integrar os dados oriundos de seus parceiros. Mesmo se as duas partes conduzirem várias discussões e negociações, as empresas têm pouco controle sobre o formato dos dados que chegam a elas. Além disso, existem muitas situações em que esses formatos mudam muito frequentemente – baseado na mudança das necessidades de negócios dos parceiros.
  • Sistemas de processamento de pedidos Front-end. Hoje, o volume de pedidos, aplicações e serviços flutuando através de diferentes canais para comerciantes, banqueiros e seguradoras, fornecedores de entretenimento, logística etc é enorme. Esses pedidos precisam ser capturados sem nenhum interrupção sempre que um usuário final faz uma transação de qualquer parte do mundo. Depois disso, um sistema de reconciliação tipicamente os atualiza para sistemas de back-end, ao mesmo tempo que atualiza o usuário final com o seu status.
  • Serviço de gerenciamento de conteúdo empresarial. O gerenciamento de conteúdo agora é utilizado através de diferentes grupos funcionais da empresa, como RH ou vendas. O desafio é congregar grupos diferentes utilizando estruturas diferentes de metadados em um serviço comum de gerenciamento de conteúdo.
  • Estatísticas/análises em tempo real. Às vezes, é necessário usar o banco de dados como uma maneira de rastrear métricas de performance em tempo real para websites (visualizações de páginas, visitas únicas etc). Ferramentas como o Google Analytics são ótimas, mas não são em tempo real – às vezes, é util construir um sistema secundário que fornece estatísticas em tempo real. Outras alterativas, como monitoramento de tráfego 24/7, são uma boa opção também.

Que tipo de armazenamento devo usar?

Aqui está um breve resumo que deve te ajudar a decidir:

NoSQL

  • O armazenamento deve ser capaz de lidar com carregamentos pesados.
  • Você executa muitas operações de escrita no armazenamento.
  • Você quer um armazenamento que seja escalável horizontalmente.
  • Simplicidade é bom, como em uma linguagem query bem simples (sem joins).

RDBMS

  • Armazenamento é esperado para apresentar carregamento pesado também, mas consiste principalmente na leitura de operações.
  • Você prefere performance a uma estrutura de dados sofisticada.
  • Você precisa de uma linguagem SQL query poderosa.

Em outros artigos, voltarei a falar do assunto, te guiando através de sete bancos de dados populares do NoSQL e discutindo seus méritos e seus problemas. Fique ligado!

Texto original disponível em http://blog.monitis.com/index.php/2011/05/22/picking-the-right-nosql-database-tool/

Fonte: Mikayel Vardanyan/IMaster

Google lança a sua própria linguagem de programação GO

O Gigante da pesquisa não para de surpreender na sua caminhada pela conquista do mundo tecnológico.

Desta vez a Google foi mais longe e criou a sua própria linguagem de programação denominada GO, que segundo ela é rápida e dinâmica como o Python, e segura como o C ou o C++.

A linguagem GO nasce como uma necessidade para a Google, esta linguagem havia sido criada pela empresa internamente para solucionar problemas de software e servidores, e passa agora a estar inteiramente disponível para quem quiser iniciar uma nova etapa em termos de programação.

A GO oferece uma simplicidade não só de compilação mas também porque a partir dela é possível tirar o máximo partido em termos de hardware de servidor sem ser necessário recorrer a software terceiro em algumas circunstâncias.

Fonte: Tecnologia.com

Desenvolvedores repensam banco de dados na nuvem

Fornecedores como NimbusDB, Xeround, ParAccels e Cloudant estão criando soluções para gerenciar grandes volumes de informações em cloud.

Diversas companhias estão desenvolvendo novas tecnologias de banco de dados para resolver a deficiência de seus sistemas para gerenciar informações no ambiente de cloud computing.

Quatro delas contaram como estão realizando esse trabalho durante um painel na conferência Estrutura GigaOm, realizada esta semana em São Francisco (EUA), para debater a infraestrutura para cloud computing. São elas: NimbusDB, Xeround, ParAccels e Cloudant.

O problema básico que essas empresas estão tentando resolver é a dificuldade de escalonamento dos bancos de banco de dados em sistemas em clusters com servidores x86. Executivos das quatro fornecedoras disseram que precisam fazer com que esse ambiente seja elástico para aumentar ou reduzir o processamento de acordo com a demanda por processamento.

“O problema essencial, a meu ver, é que os atuais sistemas de gestão de banco de dados relacional não são escaláveis, disse Jim Starkey, arquiteto sênior do banco de dados de código aberto MySQL.

Starkey é fundador e CTO da NimbusDB, que está tentando resolver esse problema com o desenvolvimento de uma tecnologia que adota a linguagem de consulta padrão SQL.

O software da NimbusDB permite que um grande número de bancos de dados seja gerenciado automaticamente em um ambiente distribuído. Starkey diz que os desenvolvedores devem ser capazes de começar pequeno, desenvolvendo uma aplicação em uma máquina local, e depois transferir o seu banco de dados para uma nuvem pública, sem precisar colocá-lo offline.

A NimbusDB ainda está em estágio inicial desse trabalho e Starkey não informou data de entrega da solução. A empresa espera fornecer o software de graça.

Com o mesmo objetivo, a Xeround está tentando resolver o problemas com uma solução em MySQL. A versão beta conta com cerca de 2 mil clientes, segundo informou o CEO da companhia, Razi Sharir. O software quer oferecer a elasticidade da nuvem, com mesma a familiaridade da codificação do SQL.

“Somos um banco de dados distribuído que funciona na memória, que se divide em vários nós virtuais e vários centros de dados e serve muitos clientes ao mesmo tempo”, disse Sharir. Ele afirmou que a escala e a elasticidade são tratadas pelo serviço automaticamente.

O serviço da Xeround já está disponível na Europa e EUA, fornecido por provedores de cloud, incluindo Amazon e Rackspace.

Sharis oberva que que os clientes do banco de dados em nuvem, em geral, precisam executar suas aplicações no mesmo centro de dados, ou próximos uns dos outros, por razões de desempenho.

Grandes volumes de dados

Diferentemente da solução da Xeround, o software da ParAccel foi projetado para executar cargas de trabalho de análise em grandes bancos de dados distribuído, em torno 25 TB, infomou o CTO da companhia, Barry Zane.

“Somos o resumo dos grandes dados”, diz Zane. Clientes da ParAccel são empresas que dependem da análise de grande quantidade de dados, incluindo serviços financeiros, companhias de publicidade e de varejo online.

A Interclick recorreu à ParAccel para realizar análises demográficas de dados para permitir que empresas de publicidade online saibam quais anúncios devem mostrar aos usuários finais. A companhia roda um banco de dados de cerca de 2TB em um cluster de 32 nós. Outros clientes com conjuntos de dados maiores usam uma arquitetura baseada em disco.

A ParAccel também permite que desenvolvedores façam consultas no SQL, mas com extensões para que eles possam usar a estrutura MapReduce, software que faz a distribuição e a análise de uma enorme quantidade de dados.

“SQL é uma linguagem realmente poderosa, é muito fácil de usar para ações incrivelmente sofisticadas, mas claro que também há uma série de atividades que não pode realizar”, avalia Zane.

Já a Cloudant, que produz software para nuvens privadas e públicas, foi a única empresa que afirmou durante o painel estar desenvolvendo um banco de dados “não SQL”. A solução foi projetada para gerenciar tanto dados estruturados como não estruturados, e ainda para encurtar o “ciclo de vida de aplicativos”, disse o cofundador e cientista-chefe Mike Miller.

“Aplicativos não têm de passar por uma fase complexa de modelagem de dados”, afirma Miller. A interface de programação é HTTP. “Isso significa que você pode se inscrever e começar a conversar com o banco de dados de um navegador e construir aplicativos dessa maneira. Estamos tentando torná-lo mais fácil de implementar.”

Desafios do hardware

Enquanto bancos de dados em nuvem podem resolver problemas de escala, também apresentam novos desafios, reconhecem os palestrantes. A qualidade do servidor na nuvem pública é “muitas vezes um problema”, afirma Zane da ParAccels. Por isso, as empresas para quem a alta velocidade de análise é crítica, podem optar por comprar e gerenciar seu próprio hardware.

E enquanto muitos prestadores de serviços alegam não acreditar na nuvem, a realidade é muitas vezes diferente, diz Miller. Fornecedores de software em nuvem precisam realizar “uma engenharia reversa” para descobrir o que as arquiteturas de serviços como a Amazon EC2 possuem “por trás da cortina”, a fim de obter o máximo desempenho do software de banco de dados.

Fonte: Computerworld