Modelagem de Banco de Dados para Nuvem

Não é o tamanho do banco de dados, 20mil de registros não é nada demais.

É que SGBD não escala tão bem para sistemas na nuvem. Esse é o problema.

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.

[]'s

Se eu entendi direito, pode ser interessante fazer sharding por cliente.

O que é sharding? rss

O que é sharding? rss

É uma das abordagens de multi-tenancy; significa ter uma instância de banco separada por cliente.

Você fez a busca que te falei?

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:

1. um banco por inquilino (tenant)
2. um esquema por inquilino num banco só.
3. 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.

O que é sharding? rss

É uma das abordagens de multi-tenancy; significa ter uma instância de banco separada por cliente.

Você fez a busca que te falei?

Ainda não pude pesquisar e ler o suficiente, mas com os termos citados pelos colegas já ajudou bastante na busca.

Segue dois artigos bem interessantes encontrados:

http://www.ibm.com/developerworks/cloud/library/cl-multitenantsaas/

Abraço

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.

Você quer criar uma plataforma tipo o salesforce? uma aplicação que roda no salesforce?

JoseIgnacio:

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.

Você quer criar uma plataforma tipo o salesforce? uma aplicação que roda no salesforce?

Não, nadad a ver, só quis citar um exemplo de sistema SaaS gigante.

Eu possuo um sistema parecido e trabalho com um esquema para cada cliente… Porém hoje possuo apenas 4 clientes e bancos pequenos…

gualtiere, como você fez essa modelagem?

Galera

Achei um fórum que a galera está discutindo 3 páginas sobre. Muito bom e bem fundamentado em todas as respostas.

Vale a pena.

http://www.tectura.com.br/topics/abordagens_de_multitenant

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.

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.