Muito bom o vídeo, mas será que não rola um outro vídeo com foco no código de como ficaria uma aplicação nessa arquitetura? Algo mais básico mas que fosse um ponto de partida...
Na empresa onde trabalho, independente do cliente, grande/medio/pequeno, separamos por ID, usamos um master e 2 slaves, as operações de escrita são no master e as de leitura o balancer direciona para os slaves. Isso ajuda bastante a aliviar o master
Eu tenho um SaaS para clinicas médicas e recentemente migrei pra multitenant. Antes, precisava criar uma aplicação diferente pra cada nova clínica. A maneira que faço é dentro de uma mesma instância do banco, crio 1 schema pra cada clinica nova. E, nas requisições, mando o tenant id sempre pra diferenciar.
@@gfrsolutions8042 Mesmo banco, mas diferentes schemas pra cada cliente. O conceito de schema no Postgres é como se fosse um namespace. Cada cliente tem suas tabelas, procedures, triggers etc... mas tudo dentro do mesmo banco.
@@ditimarfponto negativo, mesmo. provavelmente teria que rodar migrations. justamente por isso nós mudamos a estratégia: agora é um banco só e separamos por tenant_id na tabela. facilita bastante!
Passei a adotar o modelo de um banco para cada cliente. Tenho um banco onde salvo as informações de autenticação de cada cliente (meu) e identifico quem tá usando o sistema pelo subdomínio. Quando o cliente acessa o sistema eu verifico de quem se trata, carrego as informações dele para um redis (para evitar essa consulta o tempo todo) e a partir daí a conexão com o banco de dados é feito de forma dinâmica. Consigo assim permitir até que o cliente hospede o banco de dados em um servidor próprio se achar necessário.
Cara eu to estudando isso, mas não entendi muito bem fomo é feito essa distinção antes de logar na aplicação. Imagina que eu tenho um portal onde o usuario loga, eu teria um banco "Geral" pro cliente logar e eu saber qual seria a empresa dele? e ai como eu laço esse usuario no banco da empresa? esses detalhes que me pegaram xD.
@@montmor123 No caso vc teria um banco de dados "seu" com todos os seus inquilinos nele (email, senha,...etc, nome_do_banco, ip_do_banco), como se fosse um banco de dados so pra autenticacao, e um microserviço de autenticao que retornara o token e dai pra frente a aplicacao em si ira saber qual o inquilino e qual o banco dele, naum sei se fui claro
Já trabalhei em vários produtos Saas, e sem dúvida a melhor opção foi usando microservicos. Tínhamos um serviço exclusivo para administrar os tenants e gerênciar a autentiação e autorização deles. Cada microservicos tinha seu próprio database e separavamos os tenants por schema (Postgres)
Otimo conteudo, hoje temos os 2 cenarios multiplos databases e o tenant_id nas tabelas então temos opção de ter um banco para clientes de pequeno porte onde segregamos um numero x de clientes por banco de dados e também bancos totalmente separados para clientes de medio e grande porte
que legal, eu ja trabalhei com uma aplicacao multi-tenant e nem sabia! construimos um SaaS na empresa, o produto era comercializado para os clientes, pay-per-use era um gerador de assinaturas de email, o cliente criava uma assinatura, e aplicava no email corporativo para todos os usuarios o sistema nao era de grande porte, era uma API rest monolita em java/spring, o front era em vue.js, e ambos rodavam no PaaS do GCP (em maquinas diferentes) e o banco de dados era apenas 1, era cloud firestore, banco NoSQL do GCP, ate hoje me pergunto se escolhemos o banco certo... Sempre achei que tivesse sido um erro essa escolha, e que deveria ser SQL padrao, mas agora assistindo o video, talvez essa escolha de usar NoSQL faça sentido, se tratando de uma app multi-tenant
Na empresa implementamos com o multi database porque existem customizações inerentes ao negócio de cada cliente, uma base central que serve de template e filhos que herdam suas características, o que é inerente de cada negócio modificamos somente na base e implementamos na aplicação através de interfaces.
Não trabalhei com tabelas, penso que pra ter o trabalho de balanceamento e rastreio do tenant teria que marcar em muitos lugares, novos schemas ou data base acho mais apropriado pra esse tipo de arquitetura. Mas aquela velha nenhuma empresa nasce grande senão todos teriam microservice, docker, ambientes (dev/hom/prod), redundância e com monitoramento pesado pra tudo isso SLA 99,99%, mas quem iria pagar tudo isso se pode fazer um monolito que atende dentro de VPS e que custa 1/50 disso 🤷♂️ antes de pensar em todo essa arquiterura digna do coliseu, se o seu cliente só tá pedindo uma casa de 100m2
Top demais!! Achei essa abordagem de 1 db para pequenas e médias e outro para cada grande empresa muito top. Tenho uma duvida: no caso desse 1 db para pequenas e médias, pensando no isolamento dos dados, poderíamos usar schemas para cada empresa? Sei que pode parecer troca 6 por meia dúzia visto que terão que ser criadas as tabelas de novo, mas não há nenhum ganho ao utilizar esse recurso?
Outra dúvida, pensando nas particularidades que cada cliente possa ter.. a decisão de negócio mais sensata seria rejeitar novas funcionalidades que vão atender apenas poucos clientes. Mas em um caso diferente, como gerenciar essas mudanças tanto de banco, quanto de aplicação para alguns clientes?
@@joaobatista-rn6le a parte de autorização e autenticação fica no banco de dados do cliente, pois cada cliente configura os usuários e suas respectivas autorizações. Tenho um banco de dados mestre onde fica as configurações dos Tenants.
Atualmente eu trabalho no modelo de primary key, mas temos um problema muito grande pois as aplicacoes backend sao java 8 e muitos clientes juntos. Temos problemas constantes de vazamento de memoria mesmo sendo microservices. O backend consome quase 80gb de ram diariamente na AWS. Estamos buscando formas de conseguir desacoplar mais a aplicacao e buscando alternativas mais leves como nodejs, onde conseguimos consumor menor de ate 90% de memoria usando 20 replicas para aguentar a quantidade de requests feitas. Sao quase 100k US$ por mes so de infra
acho que golang seria mais adequado, go é bem mais eficiente em termos de memória que nodejs, usa metade. E é muito fácil de implementar concurrency. Go é mais rápido tmb, atende mais requests/second. Pelo tamanho do seu serviço, usar Go iria reduzir bem o custo de infraestrutura.
Pelo que eu entendi, no modelo de PK, o tenant_id sempre vai na PK de outras tabelas. Desta forma, Quando eu criar uma tabela que se relaciona com outra tabela (por exemplo itens do produto), eu referencio o tentant_id como chave estrangeira da tabela de tenant , ou da tabela de produto, já que eu também vou ter que referenciar ela?
Olá obrigado pela aula e conhecimento, uma duvida, alguns bancos permite o uso de schemas, sei que a finalidade não é essa, mais o uso é muita gambiarra ? abs ...
Muito bom o vídeo, mas será que não rola um outro vídeo com foco no código de como ficaria uma aplicação nessa arquitetura? Algo mais básico mas que fosse um ponto de partida...
Na empresa onde trabalho, independente do cliente, grande/medio/pequeno, separamos por ID, usamos um master e 2 slaves, as operações de escrita são no master e as de leitura o balancer direciona para os slaves. Isso ajuda bastante a aliviar o master
Pode me explicar melhor como funciona essa técnica? Estou pensando em criar um software, achei interessante essa abordagem
Eu tenho um SaaS para clinicas médicas e recentemente migrei pra multitenant. Antes, precisava criar uma aplicação diferente pra cada nova clínica. A maneira que faço é dentro de uma mesma instância do banco, crio 1 schema pra cada clinica nova. E, nas requisições, mando o tenant id sempre pra diferenciar.
Vc trabalha com o mesmo banco mas cria uma tabela para cada cliente ?
@@gfrsolutions8042 Mesmo banco, mas diferentes schemas pra cada cliente. O conceito de schema no Postgres é como se fosse um namespace. Cada cliente tem suas tabelas, procedures, triggers etc... mas tudo dentro do mesmo banco.
@@joaoluismoraes7215tu desenvolveu do zero mano? Ou foi low fode/no code? Se não, quais tech usou? Se puder falar, claro
O ponto negativo dessa arquitetura seria ter que alterar todos os schemas ao fazer uma alteração de BD, certo? Como voce faz para evitar isso?
@@ditimarfponto negativo, mesmo. provavelmente teria que rodar migrations. justamente por isso nós mudamos a estratégia: agora é um banco só e separamos por tenant_id na tabela. facilita bastante!
Passei a adotar o modelo de um banco para cada cliente. Tenho um banco onde salvo as informações de autenticação de cada cliente (meu) e identifico quem tá usando o sistema pelo subdomínio. Quando o cliente acessa o sistema eu verifico de quem se trata, carrego as informações dele para um redis (para evitar essa consulta o tempo todo) e a partir daí a conexão com o banco de dados é feito de forma dinâmica. Consigo assim permitir até que o cliente hospede o banco de dados em um servidor próprio se achar necessário.
Cara eu to estudando isso, mas não entendi muito bem fomo é feito essa distinção antes de logar na aplicação. Imagina que eu tenho um portal onde o usuario loga, eu teria um banco "Geral" pro cliente logar e eu saber qual seria a empresa dele? e ai como eu laço esse usuario no banco da empresa? esses detalhes que me pegaram xD.
@@montmor123 No caso vc teria um banco de dados "seu" com todos os seus inquilinos nele (email, senha,...etc, nome_do_banco, ip_do_banco), como se fosse um banco de dados so pra autenticacao, e um microserviço de autenticao que retornara o token e dai pra frente a aplicacao em si ira saber qual o inquilino e qual o banco dele, naum sei se fui claro
@@zoiaonline Obrigado amigo vc é um amigo!
Já trabalhei em vários produtos Saas, e sem dúvida a melhor opção foi usando microservicos. Tínhamos um serviço exclusivo para administrar os tenants e gerênciar a autentiação e autorização deles. Cada microservicos tinha seu próprio database e separavamos os tenants por schema (Postgres)
Pode me explicar melhor como funciona isso? E onde posso aprender mais, quero fazer algo assim para meu saas
Show demais mestre. Aqui na empresa usamos o Dynamo e separamos logicamente apenas utilizando a estratégia da PK.
Otimo conteudo, hoje temos os 2 cenarios multiplos databases e o tenant_id nas tabelas então temos opção de ter um banco para clientes de pequeno porte onde segregamos um numero x de clientes por banco de dados e também bancos totalmente separados para clientes de medio e grande porte
que legal, eu ja trabalhei com uma aplicacao multi-tenant e nem sabia!
construimos um SaaS na empresa, o produto era comercializado para os clientes, pay-per-use
era um gerador de assinaturas de email, o cliente criava uma assinatura, e aplicava no email corporativo para todos os usuarios
o sistema nao era de grande porte, era uma API rest monolita em java/spring, o front era em vue.js, e ambos rodavam no PaaS do GCP (em maquinas diferentes) e o banco de dados era apenas 1, era cloud firestore, banco NoSQL do GCP,
ate hoje me pergunto se escolhemos o banco certo... Sempre achei que tivesse sido um erro essa escolha, e que deveria ser SQL padrao, mas agora assistindo o video, talvez essa escolha de usar NoSQL faça sentido, se tratando de uma app multi-tenant
Muito bom. Não sabia de muitos pontos que apresentou.
Neste exato momento estou atuando em um SaaS pessoal onde implementei a metodologia Multi-Tenant.
Na empresa implementamos com o multi database porque existem customizações inerentes ao negócio de cada cliente, uma base central que serve de template e filhos que herdam suas características, o que é inerente de cada negócio modificamos somente na base e implementamos na aplicação através de interfaces.
Não trabalhei com tabelas, penso que pra ter o trabalho de balanceamento e rastreio do tenant teria que marcar em muitos lugares, novos schemas ou data base acho mais apropriado pra esse tipo de arquitetura. Mas aquela velha nenhuma empresa nasce grande senão todos teriam microservice, docker, ambientes (dev/hom/prod), redundância e com monitoramento pesado pra tudo isso SLA 99,99%, mas quem iria pagar tudo isso se pode fazer um monolito que atende dentro de VPS e que custa 1/50 disso 🤷♂️ antes de pensar em todo essa arquiterura digna do coliseu, se o seu cliente só tá pedindo uma casa de 100m2
Top demais!!
Achei essa abordagem de 1 db para pequenas e médias e outro para cada grande empresa muito top. Tenho uma duvida: no caso desse 1 db para pequenas e médias, pensando no isolamento dos dados, poderíamos usar schemas para cada empresa?
Sei que pode parecer troca 6 por meia dúzia visto que terão que ser criadas as tabelas de novo, mas não há nenhum ganho ao utilizar esse recurso?
Outra dúvida, pensando nas particularidades que cada cliente possa ter.. a decisão de negócio mais sensata seria rejeitar novas funcionalidades que vão atender apenas poucos clientes. Mas em um caso diferente, como gerenciar essas mudanças tanto de banco, quanto de aplicação para alguns clientes?
Uso um banco de dados para cada cliente, e separo o acesso por subdomínio
Legal, qual estratégia vc usa para isolar as autorizações dos clientes?
@@joaobatista-rn6le a parte de autorização e autenticação fica no banco de dados do cliente, pois cada cliente configura os usuários e suas respectivas autorizações. Tenho um banco de dados mestre onde fica as configurações dos Tenants.
@@joaobatista-rn6le Também tive essa mesma dúvida, comentei pra acompanhar a resposta do Bones! hahahaha
@@brunofontana7795 boa, aguardemos kkkk
@@joaobatista-rn6lemas já não é isolado pelo banco?
Atualmente eu trabalho no modelo de primary key, mas temos um problema muito grande pois as aplicacoes backend sao java 8 e muitos clientes juntos. Temos problemas constantes de vazamento de memoria mesmo sendo microservices. O backend consome quase 80gb de ram diariamente na AWS. Estamos buscando formas de conseguir desacoplar mais a aplicacao e buscando alternativas mais leves como nodejs, onde conseguimos consumor menor de ate 90% de memoria usando 20 replicas para aguentar a quantidade de requests feitas. Sao quase 100k US$ por mes so de infra
acho que golang seria mais adequado, go é bem mais eficiente em termos de memória que nodejs, usa metade. E é muito fácil de implementar concurrency. Go é mais rápido tmb, atende mais requests/second. Pelo tamanho do seu serviço, usar Go iria reduzir bem o custo de infraestrutura.
Pelo que eu entendi, no modelo de PK, o tenant_id sempre vai na PK de outras tabelas. Desta forma, Quando eu criar uma tabela que se relaciona com outra tabela (por exemplo itens do produto), eu referencio o tentant_id como chave estrangeira da tabela de tenant , ou da tabela de produto, já que eu também vou ter que referenciar ela?
Qual a diferença para uma aplicação white label?
quero entender mais, pois estou montando uma api que vai ser pra multi-tenant então, quero saber se é melhor separar por banco
Olá obrigado pela aula e conhecimento, uma duvida, alguns bancos permite o uso de schemas, sei que a finalidade não é essa, mais o uso é muita gambiarra ? abs ...
Na empresa que trabalho, separamos por esquemas do banco de dados
PK