Quando se projeta um sistema para a nuvem, como é feita a modelagem do banco de dados? Existe alguma forma diferenciada de se trabalhar ou é feito da mesma maneira que se faria para um sistema web convencional?
Deixa eu tentar explicar melhor com um exemplo prático:
Vamos dizer que estamos criando um ERP Web que vai ser cloud. Ou seja, os clientes que usarem esse ERP não terão seu próprio servidor, estrutura, etc. Só vão fazer login em um link qualquer e usar.
Dentro deste ERP vamos ter um módulo de Vendas por exemplo. Esse módulo de Vendas vai ter uma tabela PEDIDOS.
Supondo que em média cada cliente que usar o ERP terá uns 100.000 pedidos, então essa tabela vai ter 100.000 registros. Supondo também que o nosso ERP tenha 200 clientes, então nossa tabela de pedidos chegará facilmente a 20.000.000 de registros.
Isso é um numero grande de registro, mesmo que tenhamos uma boa estrutura física (processadores, memória, etc.) e também um bom SGBD, além claro dos indices e chaves criadas corretamente para as tabelas. Ou seja, com o passar do tempo, o numero de pedidos de cada cliente e o numero de clientes que usam o ERP Web irá crescer e o numero de registros nesta tabela ficará cada vez maior, então a probabilidade de problemas de performance é muito alta.
Ai que pergunto. É assim mesmo que se modela o BD? Fica tudo em uma mesma base de dados e as informações são separadas pela chave primaria de cada tabela mesmo? Ou existe alguma outra solução para isto? Quais são as alternativas.
Não sei se fui claro expondo a problemática, mas qualquer coisa só questionar que respondo. E se puderem ajudar, será bem vindo. Já procurei bastante na net sobre isto, mas não encontrei nada. Até porque não sei bem que pergunta fazer ao Google para ele me dar a resposta certa.
O termo que você está procurando é multi-tenancy (não sei se a grafia correta é essa - com hífen ou não, junto ou não), deve te dar um bom norte. Ah, outra dica: não pense em coisas assim com a escalabilidade de RDBMS tradicionais. Pense em termos de NoSQL - mais especificamente, a altíssima escalabilidade que os acompanha.
Tbm tenho minhas dúvidas quanto a multi-tenancy.
Criar um banco para cada cliente? Controlar apenas pelo id do cliente (multi-tenancy) ou levantar uma instância do cloud para cada cliente conectado.
A princípio penso em fazer separado apenas por id do cliente. Mas uma aplicação como o SalesForce da vida, conseguiria ‘aguentar’ todos clientes usando essa abordagem?
Gostaria de relatos de quem já teve essa experiência.
De fato o ponto é [url=http://en.wikipedia.org/wiki/Multitenancy]multitenancy/url. O novo hibernate vem com 3 opções que são básicamente as opções que ha:
um banco por inquilino (tenant)
um esquema por inquilino num banco só.
um id em cada tabela identificado o inquilino.
Qual dos 3 escala melhor ? não sei dizer.
Eu acho que depende um pouco do PaaS de base ( o quão fácil é criar outro banco ou esquema) e da aplicação.
Se aplicação tem - por exemplo - funcionalidades estatisticas onde os dados de todos os inquilinos são usados a opção 3 poderá ser melhor.
Lembrar que irá ser necessário um banco master para coisas como controle de biling, acesso, etc… onde o id do inquilino será gerado e associados ao banco. Aqui ha a opção ( se o PaaS permitir) do sistema cria um novo banco ou novo esquema no banco padrão automáticamente baseado no id do inquilino que foi gerado em algum processo de cadastro.
[quote=j0nny]Tbm tenho minhas dúvidas quanto a multi-tenancy.
Criar um banco para cada cliente? Controlar apenas pelo id do cliente (multi-tenancy) ou levantar uma instância do cloud para cada cliente conectado.
A princípio penso em fazer separado apenas por id do cliente. Mas uma aplicação como o SalesForce da vida, conseguiria ‘aguentar’ todos clientes usando essa abordagem?
Gostaria de relatos de quem já teve essa experiência.[/quote]
Você quer criar uma plataforma tipo o salesforce? uma aplicação que roda no salesforce?
[quote=JoseIgnacio][quote=j0nny]Tbm tenho minhas dúvidas quanto a multi-tenancy.
Criar um banco para cada cliente? Controlar apenas pelo id do cliente (multi-tenancy) ou levantar uma instância do cloud para cada cliente conectado.
A princípio penso em fazer separado apenas por id do cliente. Mas uma aplicação como o SalesForce da vida, conseguiria ‘aguentar’ todos clientes usando essa abordagem?
Gostaria de relatos de quem já teve essa experiência.[/quote]
Você quer criar uma plataforma tipo o salesforce? uma aplicação que roda no salesforce?[/quote]
Não, nadad a ver, só quis citar um exemplo de sistema SaaS gigante.
Eu optei pela abordagem um schema por cliente. Acho mais escalável. Se uma instância de um banco ficar muito carregada, eu crio outra instância e divido os schemas dos meus clientes entre essas duas instâncias.
E qual a vantagem dessa solução em vez de um id do cliente em cada tabela?
A princípio vejo apenas as consultas talvez serem mais rápidas, também tenho minhas dúvidas quanto a isso, se talvez um índice na coluna ‘id’ em cada tabela resolveria esse possível problema.
E qual a vantagem dessa solução em vez de um id do cliente em cada tabela?
A princípio vejo apenas as consultas talvez serem mais rápidas, também tenho minhas dúvidas quanto a isso, se talvez um índice na coluna ‘id’ em cada tabela resolveria esse possível problema.[/quote]
Acredito que além da vantagem de performance, exista uma vantagem infraestrutural e de monitoramento. Separando os schemas fica mais fácil realizar manutenção em um cliente específico, além de facilitar o monitoramento, identificando clientes que demandam mais requisições e consumo do banco.
Quanto aos índices, já trabalhei em sistemas de OLAP onde tabelas com dezenas de milhões de registros ficam sofríveis mesmo com índices (mas claro que entra em pauta a necessidade de um bom servidor de BD, um bom DBA e bla bla bla), se refletirmos essa situação em uma tabela transacional, na nuvem, com n clientesl, deve piorar bastante.