Design de banco de dados SaaS – Vários bancos de dados?Dividir?
https://stackoverflow.com/questions/69128
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Já vi aplicativos SaaS hospedados de muitas maneiras diferentes.É uma boa ideia dividir recursos e módulos em vários bancos de dados?Por exemplo, colocar coisas como a tabela User em um banco de dados e tabelas específicas de recursos/aplicativos em outro banco de dados e talvez outras tabelas comumente compartilhadas em outro banco de dados?
Solução
Comece com um banco de dados.Divida dados/funcionalidades quando o projeto exigir.
Aqui está o que podemos aprender com o LinkedIn:
- Um único banco de dados não funciona
- A integridade referencial não será possível
- Qualquer perda de dados é um problema
- O cache é bom mesmo quando é modestamente eficaz
- Nunca subestime a trajetória de crescimento
Fonte:
Outras dicas
Alta escalabilidade é um bom blog para dimensionar aplicativos SaaS.Conforme mencionado, dividir tabelas em bancos de dados como você sugeriu geralmente é uma má ideia.Mas um conceito semelhante é o sharding, onde você mantém o mesmo esquema (ou semelhante), mas divide os dados em vários servidores.Por exemplo, os usuários 1-5000 estão no servidor1 e os usuários 5000-10000 no servidor2.Dependendo das consultas que seu aplicativo usa, pode ser uma forma eficiente de escalar.
Para aplicativos SaaS, você usa vários bancos de dados para vários locatários, mas geralmente não os divide em módulos.
Este é o modelo mais comum que vi no design de aplicativos SaaS.Seu esquema base é replicado para cada locatário adicionado ao seu aplicativo.
Ter um único banco de dados é melhor para a integridade dos dados porque você pode usar chaves estrangeiras.Você não pode ter essa integridade de dados integrada se dividir os dados em vários bancos de dados.Isso não é um problema se seus dados não estiverem relacionados, mas se estiverem relacionados, seria possível que seu banco de dados contivesse dados inconsistentes com outro banco de dados.Nesse caso, você precisaria escrever algum código que verifique regularmente seus bancos de dados em busca de dados inconsistentes, para que possa lidar com eles de maneira adequada.
No entanto, vários bancos de dados podem ser necessários se você precisar que seu site/aplicativo seja altamente escalável (por exemplo,escala de internet).Por exemplo, você poderia hospedar cada banco de dados em um servidor físico diferente.
Dividir o banco de dados por recursos pode não ser uma boa ideia, a menos que você veja fortes evidências sugerindo essa necessidade.Freqüentemente, você pode precisar atualizar dois bancos de dados como parte de uma única transação - e as transações distribuídas são muito mais difíceis de trabalhar.Além disso, se o banco de dados precisar ser dividido, você poderá empregar a fragmentação.
Há diversas maneiras de fazer isso, mas as questões da multilocação são mais profundas do que apenas o modelo de dados.Eu odeio estar conectando produtos, mas confira Grade SaaS pela minha empresa em que trabalho, Apprenda.Somos um sistema operacional em nuvem que permite escrever aplicativos SOA de locatário único (sinta-se à vontade para usar o NHibernate para acesso a dados) que injeta automaticamente multilocação em seu aplicativo.Ao publicar seu aplicativo, você pode fazer coisas como escolher um modelo de dados (banco de dados isolado ou compartilhado) e o SaaSGrid será implementado de acordo e seu aplicativo será executado sem nenhuma alteração de código - apenas escreva o código como se fosse para um único locatário!
Por que usar banco de dados?
Acho uma boa ideia usar sistemas de armazenamento distribuído como Hadoop, Voldemort (project-voldemort.com desenvolvido e usado pelo LinkedIn).
Acho que o banco de dados é bom para dados sensíveis, como operações financeiras, mas para todo o resto você pode usar armazenamentos distribuídos.
Pergunte a si mesmo:O que você ganha ao mover tudo para bancos de dados separados?
Muita dor em termos de gestão, seria meu palpite.Pessoalmente, eu estaria mais interessado em ter tudo em um único banco de dados e, se você encontrar problemas que não podem ser resolvidos por um único banco de dados posteriormente, migre os dados para vários bancos de dados.
Mantenha um design natural (desnormalize o quanto for necessário, normalize o menos que for necessário).Divida o modelo de banco de dados em seus módulos e mantenha em mente os princípios orientados a serviços, encaminhando os dados para um serviço (que possui os dados).
