Introdução

A computação em nuvem está abrindo mercados que não eram contemplados pelas empresas no passado. Agora, algumas empresas de software estão pensando em entregar o software como serviço, em vez de adotar o método usual de desenvolver o software e vendê-lo aos clientes por meio dos métodos de distribuição tradicionais. Para serem fornecedoras de software como serviço (SaaS), as empresas precisam encontrar o equilíbrio correto, no qual os recursos são compartilhados entre os vários arrendatários para reduzir custos e garantir a privacidade das informações do cliente em relação aos outros clientes. Não há problema mais sério do que poder ver as informações privadas de um arrendatário a partir da conta de outro. Além da privacidade das informações dos arrendatários, os fornecedores de SaaS precisam fornecer algum nível de customização para os clientes.

Em um ambiente de multilocação, uma empresa de SaaS pode reduzir custos se compartilhar ou reutilizar mais os seus recursos. Entretanto, quanto mais a empresa compartilha, mais riscos ela enfrenta, porque a indisponibilidade de um recurso compartilhado pode afetar outros clientes. O compartilhamento de mais recursos também aumenta a complexidade da solução.

A Figura 1 foi usada em várias apresentações da IBM para mostrar a visão geral de um ambiente de aplicativos em multilocação.

Neste artigo, trataremos somente da camada de dados mostrada no lado direito da Figura 1 e usaremos o software DB2. As outras camadas podem ser manipuladas por outros softwares IBM, como o WebSphere® Portlet Factory, WebSphere Portal Server, Tivoli® Directory Server, Tivoli Directory Integrator, Tivoli Provisioning Manager, Tivoli Monitoring, Tivoli Usage e Accounting Manager, etc.

A multilocação na camada de dados por meio do DB2 pode ser usada em várias situações, como mostrado nos seis casos a seguir. Também tenha em mente que, se a empresa é pequena e quer reduzir os custos de licenciamento, é possível considerar a possibilidade de usar a versão grátis do DB2: DB2 Express-C. O DB2 Express-C não tem limites de tamanho do banco de dados.

Voltar para parte superior

Caso 1: compartilhando tabelas

Neste caso, os seguintes recursos são compartilhados:

• O servidor de banco de dados
• A instância do DB2
• O banco de dados
• Um espaço de tabela ou mais
• Uma tabela ou mais

A Figura 2 mostra uma visão geral dos recursos compartilhados neste caso. As tabelas inventory, customers e orders possuem informações dos clientes dos vários arrendatários.

Esse caso oferece vantagens de custo e armazenamento mais baixos, quantidade mínima de licenciamento do DB2 e número mínimo de instâncias de nuvem necessárias.

A principal desvantagem é que se, por exemplo, uma tabela é corrompida, todos os clientes são afetados. Além disso, é possível aumentar a complexidade dos aplicativos na tentativa de sempre determinar quais registros de um arrendatário devem ser recuperados nas consultas.

Voltar para parte superior

Caso 2: compartilhando um banco de dados

Neste caso, os seguintes recursos são compartilhados:

• O servidor de banco de dados
• A instância do DB2
• O banco de dados

A Figura 3 mostra a visão geral dos recursos compartilhados neste caso.

Neste caso, os benefícios do compartilhamento de um banco de dados ainda representam um custo relativamente baixo em relação ao uso de uma licença de DB2 e uma instância de nuvem. O isolamento de dados é bom porque é usado um conjunto diferente de tabelas. A customização do ponto de vista dos dados é mais fácil, porque cada arrendatário tem o seu próprio conjunto de tabelas.

A desvantagem é a necessidade de mais armazenamento, já que é necessário criar um conjunto das mesmas tabelas por arrendatário. Em comparação com o caso 1, seria usado x vezes mais de armazenamento, onde x é o número de arrendatários. A complexidade do aplicativo também aumenta e não tem a mesma flexibilidade, já que agora é necessário customizar o aplicativo para manipular nomes de tabela diferentes e uma estrutura de tabela possivelmente diferente caso algum arrendatário tenha uma customização específica.

Voltar para parte superior

Caso 3: compartilhando um banco de dados e usando um nome de esquema diferente

Neste caso, os seguintes recursos são compartilhados:

• O servidor de banco de dados
• A instância do DB2
• O banco de dados

A Figura 4 mostra a visão geral dos recursos compartilhados neste caso.

Neste caso, os benefícios são o custo ainda baixo, quase igual ao do caso 2. Também é necessário possuir uma licença do DB2 e uma instância de nuvem. O isolamento de dados é bom porque é usado um conjunto de tabelas separado. Compare com o caso 2: a complexidade do aplicativo é menor porque as instruções SQL usadas podem ser exatamente iguais. O redirecionamento de uma consulta para um determinado conjunto de tabelas é realizado ao mudar o nome do esquema usando o comando SET SCHEMA . As customizações de uma determinada tabela evidentemente aumentam a complexidade do seu aplicativo.

A desvantagem, como no caso 2, é que ainda é necessário usar mais armazenamento, porque seria criado um conjunto de tabelas por arrendatário.

Voltar para parte superior

Caso 4: compartilhando uma instância

Neste caso, os seguintes recursos são compartilhados:

• O servidor de banco de dados
• A instância do DB2

A Figura 5 mostra a visão geral dos recursos compartilhados neste caso.

Neste caso, os benefícios são o custo ainda baixo, quase igual ao do caso 2. Também é necessário possuir uma licença do DB2 e uma instância de nuvem. O isolamento de dados é muito bom porque cada arrendatário tem o seu próprio banco de dados, que no DB2 é uma unidade independente. Cada banco de dados pode ser configurado e mantido de forma independente, oferecendo mais flexibilidade. O aplicativo é menos complexo do que no caso 1. A estrutura da maioria das tabelas será igual em todos os bancos de dados. Se um arrendatário requer customização, é possível alterar a definição de tabela, mas isso aumenta a complexidade do aplicativo.

A desvantagem é que será necessário mais armazenamento. Cada banco de dados no DB2 cria o seu próprio catálogo, que em outros produtos de banco de dados é conhecido como dicionário, portanto, há necessidade de criar mais tabelas, visualizações e outros objetos de banco de dados do sistema. Além disso, no caso do DB2, há um limite de 256 bancos de dados ativos por instância, portanto, nesse cenário, somente 256 arrendatários poderiam trabalhar simultaneamente. Outra desvantagem é o aumento do consumo de memória, que pode ser problemático em duas frentes:

• É possível atingir o limite de memória da edição do DB2 em uso e seria necessário comprar uma edição mais cara do DB2.
• É possível atingir o limite de memória na instância de nuvem. Nesse caso, seria necessário escolher uma instância de nuvem mais cara.

Voltar para parte superior

Caso 5: compartilhando um servidor de banco de dados

Neste caso, somente o recurso do servidor de banco de dados é compartilhado. A Figura 6 mostra a visão geral dos recursos compartilhados neste caso.

Neste cenário, cada arrendatário tem a sua própria instância de DB2. O primeiro benefício é o bom controle de acesso. A complexidade do aplicativo é semelhante à do caso 4. Entretanto, talvez o administrador do sistema tenha que configurar os parâmetros de conectividade corretamente em todas as instâncias, o que pode dar mais trabalho. A estrutura da maioria das tabelas é igual e, como no caso 4, para um determinado arrendatário, é possível customizar algumas tabelas, mas há necessidade de mudanças no aplicativo. Outro benefício é o fato de que cada instância e banco de dados pode ser mantido de forma independente. Se você derruba uma instância, isso afeta somente um arrendatário.

Em relação às desvantagens, há mais necessidade de armazenamento que nos outros casos e, além disso, pode haver problemas de memória. Embora o número de instâncias no DB2 seja limitado pelos limites do sistema operacional, e o início de uma instância não consuma muita memória, o fato de haver muitas instâncias iniciadas com vários bancos de dados ativos ao mesmo tempo pode causar problemas de memória. Consequentemente, talvez você seja obrigado a passar a usar uma edição mais cara do DB2 ou utilizar uma instância de nuvem maior e mais cara. Além dessas desvantagens, a complexidade da administração também aumenta, o que pode fazer com que a empresa contrate mais recursos, afetando os custos diretamente.

Voltar para parte superior

Caso 6: compartilhando um servidor de banco de dados com várias cópias do DB2

Neste caso, somente o recurso do servidor de banco de dados é compartilhado. A Figura 7 mostra a visão geral dos recursos compartilhados neste caso.

Para o propósito de um SaaS, o uso dessa abordagem não traz nenhum benefício. Em termos de desvantagens, existem várias:

• É necessário armazenar mais cópias do DB2 na sua instância de nuvem, ocupando espaço.
• É necessário instalar e configurar o DB2 para cada cópia instalada, portanto, o tempo de configuração da administração é maior.
• O aplicativo é mais complexo, e esse tipo de ambiente pode confundir os desenvolvedores, que ficam sem saber a qual banco de dados devem se conectar em cada instância da cópia do DB2.
• Há problemas semelhantes aos do caso 5 em termos de consumo de memória e armazenamento.

Em poucas palavras, esse caso não traz nenhum benefício real, mas foi acrescentado neste artigo para que ele ficasse completo.

Voltar para parte superior

Customização na camada de dados

Como já foi dito, a customização para um determinado arrendatário pode aumentar a complexidade do aplicativo e da administração. Essa seção mostra como se pode lidar com a customização usando o XML — , especificamente, a tecnologia pureXML do DB2® , que fornece mais flexibilidade. A Figura 8 mostra um exemplo.

A figura mostra que um arrendatário tem muitos clientes, e cada cliente tem um perfil diferente. A coluna do ID de arrendatário (TID) nas duas tabelas é usada para identificar o arrendatário. As linhas 1 e 3 da tabela à esquerda pertencem ao arrendatário que tem o TID 1. As linhas 2, 4 e 5 pertencem a outro arrendatário com o TID 2.

Suponha que o arrendatário No. 2 (TID = 2) possua uma regra de negócios que indica que os clientes não podem inserir informações de telefone, portanto, armazenar informações sobre números de telefone não seria aplicável a esse arrendatário. Entretanto, em um ambiente de multilocação no qual as tabelas são compartilhadas (caso 1), a empresa de SaaS precisa levar em conta que outros arrendatários querem incluir informações de telefone. Usando um banco de dados SQL tradicional (tabela à esquerda), o fornecedor de SaaS pode criar uma tabela de coluna fixa, que inclui colunas para todos os casos possíveis de números de telefone (telefone celular, telefone residencial). A coluna é incluída mesmo se o arrendatário No. 2 não permitir números de telefone nos perfis dos clientes. Portanto, haverá muitos "buracos" e dados dispersos, destacados pelos círculos na Figura 8.

Além disso, suponha que o arrendatário No. 1 (TID = 1) queira alterar os seus requisitos para armazenar não só números de celular e telefone residencial, mas também números de telefone profissional. Nessa situação, talvez seja necessário alterar a tabela. No entanto, se as regras de normalização para o design do banco de dados forem seguidas, na verdade, será necessário criar uma tabela PHONE separada. Em seguida, seria necessário mover os dados e alterar os aplicativos para que as consultas SQL apontem para a nova tabela PHONE e usem as operações de junção . Esse método não é flexível.

O lado direito da Figura 8 mostra o método sugerido para manipular as customizações. Nesse caso, a tabela só possui duas colunas. A segunda é definida com o tipo de dados XML. Com o XML, adquire-se muito mais flexibilidade para lidar com mudanças no esquema do banco de dados. Além disso, com a tecnologia pureXML do DB2, o desempenho melhora bastante. O DB2 9.7 também permite a evolução do esquema, portanto, as mudanças futuras em um determinado esquema XML podem ser aplicadas com facilidade. Além disso, o DB2 permite vários esquemas XML por coluna, assim, cada arrendatário pode usar esquemas XML diferentes.

Voltar para parte superior

Resumo

Neste artigo, abordamos as questões que os novos fornecedores de SaaS devem levar em conta ao desenvolver novos aplicativos ou modificar os aplicativos já existentes. O artigo trata das questões ou casos somente sob o ponto de vista do banco de dados, — especificamente, sob o ponto de vista do DB2. Foram descritos seis casos ou métodos. Como acontece em muitas situações na área de TI, é necessário encontrar o equilíbrio entre os custos e os requisitos ao escolher um determinado método. Os métodos nos quais você compartilha mais permitem um uso melhor dos recursos a um custo menor. Entretanto, se não for corretamente projetado, pode haver muitos problemas, já que a falha de um recurso pode afetar muitos arrendatários. Por outro lado, o uso dos métodos em que você compartilha menos recursos pode aumentar os custos, embora o risco para os outros arrendatários seja menor.

Como fornecedor de SaaS, é provável que você tenha que escolher os métodos nos quais os recursos são compartilhados. Se tomar os cuidados necessários, como usar o HADR e outros controles de alta disponibilidade e redundância do DB2, será possível reduzir ou evitar problemas em um ambiente de multilocação. Alguns desses controles de resiliência de dados estão integrados à nuvem.

Recursos

Aprender

• Saiba mais sobre a tecnologia pureXML do DB2.
  
  
• Revise o artigo "Introdução à analítica de dados com base em Hadoop no IBM SmartCloud Enterprise" para saber como configurar um cluster de Hadoop no IBM SmartCloud Enterprise.
  
  
• Faça o curso Hadoop and the IBM SmartCloud Enterprise para aprimorar a sua qualificação nessa área.
  
  
• Saiba mais sobre as ofertas de nuvem da IBM.
  
  
• Saiba mais sobre o DB2 HADR.
  
  
• Visite a página de recursos do developerWorks para o DB2 para Linux, UNIX e Windows para ler artigos e tutoriais e entrar em contato com outros recursos, ampliando assim suas qualificações em DB2.
  
  
• Saiba mais sobre Information Management na zona do Information Management no developerWorks. Encontre documentação técnica, artigos de instruções, treinamento, downloads, informações de produtos, e muito mais.
  
  
• Fique por dentro doseventos técnicos e webcasts do developerWorks .
  
  
• Siga o developerWorks no Twitter.
  
  

Obter produtos e tecnologias

• Crie seu próximo projeto de desenvolvimento com a Versão de teste do software IBM, disponível para download diretamente do developerWorks.
  
  
• Agora é possível usar o DB2 gratuitamente. Faça o download do DB2 Express-C, uma versão gratuita do DB2 Express Edition para a comunidade que oferece os mesmos recursos de dados centrais que o DB2 Express Edition e fornece uma base sólida para desenvolver e implementar aplicativos.
  
  

Discutir

• Participar do fórum de discussão.
  
  
• Para obter informações atualizadas sobre computação em nuvem, acesse o blog Thoughts on Cloud.
  
  
• Confira o blogs do developerWorks e participe da comunidade do developerWorks.
  
  

Sobre o autor

Raul F. Chong é gerente de programa senior e trabalha no Centro de Competência de Computação em Nuvem da Information Management. Trabalha na IBM há 14 anos como consultor de banco de dados, especialista de suporte, desenvolvedor de informações e divulgador técnico. As suas principais áreas de conhecimento são computação em nuvem, Big Data e bancos de dados.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução
• Caso 1: compartilhando tabelas
• Caso 2: compartilhando um banco de dados
• Caso 3: compartilhando um banco de dados e usando um nome de esquema diferente
• Caso 4: compartilhando uma instância
• Caso 5: compartilhando um servidor de banco de dados
• Caso 6: compartilhando um servidor de banco de dados com várias cópias do DB2
• Customização na camada de dados
• Resumo
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais