Este é um tema que me interessa e muito (vou ver se escrevo algo no meu blog a respeito).
O que tem de ser levado em consideração no caso de uma arquitetura multi tenant é, antes de mais nada, o custo. Na essência há duas alternativas:
* Um banco de dados por cliente: a principal vantagem é que fica muito mais fácil você isolar os dados de cada tenant, pois já estão físicamente separados.
A dificuldade neste caso é o fato de ser muito mais caro, pois para inquilino você terá o mesmo overhead. Além disto, a manutenção das tabelas/estruturas é cara, pois você precisará replicá-la em cada uma das instâncias de banco de dados.
Além disto, gerenciar os datasources pode se tornar algo bastante complexo.
* O mesmo banco de dados para múltiplos tenants: a vantagem é o custo reduzido que você tem no overhead, que passa a ser compartilhado pelo seu número de inquilinos.
Fica mais difícil você garantir o isolamento dos dados do usuário: seu código precisa ser mais esperto, mas a estratégia fundamental consiste em, basicamente, incluir uma coluna que identifique o seu inquilino e que será usada em toda consulta. O Hibernate mesmo já da suporte a isto para você.
Uma dúvida que poderia entrar aqui é: "minhas tabelas não ficariam gigantescas?". Sim, ficam bem maiores, mas você pode particioná-las, por exemplo, ou mesmo elaborar estratégias de gestão de dados que possam lhe ajudar a mitigar esta dificuldade.
Outro ponto que deve ser levado em consideração:
* Haverá customização de campos, isto é, o inquilino poderá definir novos campos na aplicação?
Se a resposta for sim, minha sugestão é adotar uma estratégia de persistência mista: algo como relacional/documental. Documental para onde os atributos variem, relacional para o resto. Outra alternativa é usar o próprio Postgres que agora oferece um suporte a este tipo de documento de uma forma bem interessante também.
Apesar do overhead, a opção de um banco de dados para cada cliente, será mesmo a opção a ser utilizada.
Seria possível você falar um pouco mais sobre a complexidade de gerenciar os datasources?
Agradeço a atenção
Oi Agnaldo,
neste caso a dificuldade vai ser realmente o overhead a mais que você irá pagar e o custo de manutenção das suas tabelas. Já passei por alguns projetos que tomaram esta decisão e até agora não vi um caso em que valesse à pena ou mesmo que pudesse ser considerado multi-tenant.
Um equívoco muito comum é ter diversas instâncias da aplicação, cada uma apontando para um datasource distinto, o que espero não ser o seu caso. Os problemas de versionamento costumam ser fatais a médio prazo.
Mas para criar datasources em tempo de execução, o que talvez seja seu caso, conheço este plugin: http://grails.org/plugin/runtime-datasources
Talvez lhe ajude. Tirando isto, o Grails oferece suporte a múltiplos datasources também, o que você pode verificar na documentação oficial: http://grails.org/doc/latest . Se não me engano, nativamente eles são definidos apenas no momento de boot da aplicação, o que não cairia bem para o seu caso.
Bom Dia Kico,
Não estou utilizando várias instâncias da aplicação.
No meu caso quando o cliente logar no sistema, e aplicação deverá identificar a configuração e conexão do banco dele, ou seja tudo estará acontecendo em bancos distintos (bd1, bd2 etc) para cada cliente.
Obrigado pela atenção, estarei verificando o plugin e também a documentação.
Grande resposta Agnaldo, agregou bastante! :)