SaaS Single-tenant vs Multi-tenant (devo criar um banco por empresa!)
ฝัง
- เผยแพร่เมื่อ 12 ก.ย. 2024
- Sempre que você desenvolver um SaaS (Software as a Service) vai precisar escolher a melhor arquitetura para compartilhamento de recursos e dados entre os usuários da aplicação.
Acontece que essa decisão não afeta apenas o banco de dados, como muita gente pensa.
Nesse vídeo vou te explicar um pouco mais sobre isso e apresentar as arquiteturas Single tenant e Multi-tenant, falando das especificações e detalhes de cada uma, usando um projeto meu como exemplo.
-----
Conecte-se a 500mil devs e avance para o próximo nível com a nossa plataforma: rocketseat.com...
Cadastre-se na nossa plataforma: app.rocketseat...
Junte-se a mais de 392mil devs em nossa comunidade no Discord: / discord
Acompanhe a Rocketseat nas redes sociais:
Twitter: @rocketseat
Facebook: @rocketseat
Instagram: @rocketseat
Eu trabalhei numa empresa que tinha o conceito de Multi-Tenant, mas era para a área de autenticação e user management. Basicamente nossa APP servia multiplas empresas e cada uma dessas empresas tinham seus clientes, então nós tinhamos multi-tenants e cada tenant tinham seus clientes. Quem logava na nossa aplicação eram os clientes dos clientes, mas cada um tinha as informações apenas do seu tenant relacionado. Era um banco para todos os nossos tenants e clientes deles, tudo baseado em tenant id e outras coisas similares.
Puta que pariu, que maluquice.
Curto demais seus vídeos Diego/Rocketseat, mas o mercado não está apenas com MicroSaaS, React e NextJS. Estão mais exigentes e pedindo AWS, GCP principalmente. Seria interessante trazer conteúdos com esse aspecto ou liberar dentro da plataforma para quem é membro.
Up. Um curso pra área de DevOps na plataforma seria sensacional. Criação de imagem docker para produção, desenvolvimento de aplicação voltada para escalabilidade horizontal com múltiplas instâncias, orquestração com swarm ou ferramentas AWS seriam sensacionais.
A vantagem do multi-bancos, alem do isolamento de dados ser trabalhado com mais facilidade, eu tenho a liberdade de escolher a infra por cliente, nao preciso ficar gastando uma infra de 32GB e 8 CPUS para minha instancia do banco de dados, para aquele cliente que nao tem muitas requisicoes, onde escolho algo mais real para o cliente, onde acabo tendo uma economia, a desvantagem é a complexidade de manutencao disso, trabalhar com varios bancos, atualizacoes é um saco, mas da para desenvolver ferramentas para esse tipo de coisa.
E como vc faz para atualizar as estruturss de tds os bancod ao mesmo tempo?
Muito boa a explicação Diego.
Trabalhei em uma empresa que o SaaS deles era Single-Tenant, tinha muita dificuldade para fazer atualizações.
Neste caso compensaria construir uma nova aplicação Multi-tenant pra sanar este problema? E qual seria o nível de dificuldade?
Ficou meio vago, sentir falta de soluções o que possivelmente essas empresas grandes usam. Pq assim.. sobre multi tenant eu só imagino 4 possibilidades: Separados por DOMINIOS, BANCOS, SCHEMA DE BANCO OU FK que identifica o cliente. Essa de FK é o melhor custo mas bem chata de implementar pq em toda consulta tem q por onde clienteId=clienteId.
Se possível fala mais sobre. Estou a frente de um projeto multi tenant e fiquei curioso sobre o que vcs tem a falar. Vlw!
Eu utilizo essa estratégia do FK, como utilizo jwt para autenticação, posso confiar no tenant_id e user_id que ele envia. Assim, todos os meus controllers passam para os use cases o tenant_id (e se preciso o user_id) e a primeira coisa que faço em casa use case é validar se o recurso solicitado pertence ao usuário. Realmente é meio chato e é uma consulta a mais no banco de dados, mas depois que acostuma já fica automático fazer a validação nas primeiras linhas do use case (e o copilot já aprendeu e sugere a validação certinha 😂😂😂😂).
Mas HOJE acho que se eu fosse fazer outro SAAS do zero, usaria um schema por tenant, que não precisaria dessas validações…
@@romulo886 psr. Por schema é bom pq utilizamos somente um banco. E os clientes ficam separados internamente no schema. Mas a manutenção em casa de update na estrutura vai precisar ser aplicada para cada schema logo deixa difícil na manutenção. É tal dos prós e contras.
E sobre a condição eu falei clienteId=clienteId só pra ilustrar. Eu uso ORM. Ele tem já as configs pra evitar esses ataques. Tmj
@@rafaelsantana588 exatamente kk fica meio complexo mesmo, essa tbm é minha dor kk, mas acostuma. Por isso queria ouvir mais sobre.
Sobre o schema é bom pq evita as condições mas a manutenção fica mais difícil se tiver necessidade de por exemplo: adicionar uma coluna nova. Vai ter q replicar para todos os tenants.
Antigamente não, aqui na empresa ainda é feito assim. Delphi, Firebird e por ai vai :)
Quando esse curso vai pra dentro da plataforma ?
Diego, quando este projeto entra no Ignate?
ansioso pra ver o codigo-fonte dessa maravilha
o pessoal cria problema onde n tem!
Existem várias abordagens de multi tenant para banco de dados, algumas delas são: bancos de dados separados; banco de dados compartilhado e esquema de dados separados; banco de dados e esquema de dados compartilhados.
Gostei da explicação. Então o ideal seria multi tenant de schema?
tem 3 abordagens. um schema por empresa, um schema para todas as empresas ou um banco para cada empresa.
Onde ele faz live?
Eu queria criar um crud multiusuários, tem curso?
esse projeto vai completo pro ignite?
Dúvida. Como fica a parte de backup para um banco apenas. Ex: cliente quer o backup dos dados dele?
Partindo do pressuposto que toda tabela sua contém um tenant_id, era só fazer backup de todos os dados que contém aquele tenant_id.
Eu fiz estágio numa empresa que era desse jeito em delphi(2:23) kkkkkkkkkkkkkkkkk