Multi tenancy com bancos de dados separados por cliente

Estou lidando com um projeto de Multi-Tenancy, onde adotamos a estratégia de cada cliente possuir seu próprio banco de dados, enquanto um banco central armazena informações gerais dos clientes, incluindo a referência para os respectivos bancos.

No contexto HTTP, através de um middleware, identifico qual é o cliente pelo hostname e realizo a conexão com o respectivo banco de dados.

Tenho dúvidas sobre como configurar as conexões com os bancos de dados dos clientes fora do contexto HTTP, como em tarefas agendadas (cron jobs) ou consumidores de filas. Alguém que já trabalhou nesse formato de multi tenancy com bancos de dados separados por cliente poderia compartilha como resolveram a questão de acessar os bancos fora do contexto de requisição?

noti0nShá 26 dias

Uma possibilidade seria criar uma tabela no banco de dados central que armazena informações da base de dados dos clientes. Com isso, você precisaria simplesmente fazer uma SELECT nessa tabela, recuperar as informações necessárias para montar a ConnectionString, conectar nas bases e fazer o que tem de ser feito.

Apesar deu nunca ter feito filas e nem cron jobs nesse cenário de multi tenancy, trabalhei em uma empresa que seguiu essa abordagem e seria assim que eu resolveria essa questão.

devpaulorcchá 26 dias
Como você abordaria esse cenário utilizando filas e cron jobs?
noti0nShá 26 dias
Então, depende muito do que se trata o procedimento em si. Alguns exemplos que consigo pensar: 1. Realizar o processamento de um pedido numa fila. Nesse caso, eu criaria uma tabela que representaria esse processamento em especifico na qual teria como uma de suas colunas o id dessa base de dados. Dai seria uma questão de recuperar esse registro, pegar o id da base e localizá-la na tabela do banco de dados central. 2. Criar um Cron Job que faz backup dos pedidos dos clientes 1x ao dia: quando ocorrer o trigger desse job, simplesmente faz um SELECT nessa tabela que contêm todas as bases de dados e faz o procedimento de backup na tabela de pedidos em cada base. É lógico que dependendo dos requerimentos não vai ser tão simples assim. Mas eu acho que ter uma tabela que me diz quais são as bases dos meus clientes é essencial para que eu consiga fazer algo, a não ser que os colegas da plataforma possam sugerir outras abordagens, claro.
welovetechhá 18 dias
Eu fico arrepiado vom algumas ideias que vejo de vez em quando.
noti0nShá 17 dias
Como você resolveria essa questão?
welovetechhá 11 dias
A melhor forma para resolver essa questão (hoje) é a mesma dos grandes sistemas de mercado, um banco de dados armazena os dados de todos os clientes e trabalhamos o balanceamento conforme necessário, mais jamais separando banco por cliente. Como seria a manutenção disso depois? Para alterar um campo, uma procedure, uma function? Altera em todos os bancos, automatiza? Vai dar problema, com certeza.
noti0nShá 11 dias
Sim, concordo 100% que para realizar manutenção e escalar verticalmente o sistema centralizar tudo num DB é a melhor abordagem. O ponto é que na pergunta do amigo ele diz que a empresa dele segue o caminho de dividir um banco para cada cliente. Nesse caso como eu imagino ser inviável mudar a arquitetura do sistema para seguir a abordagem que recomendados, a melhor forma de resolver o problema no contexto dele é centralizar as informações das bases num banco central. Não consigo enxergar outra forma de resolver esse caso.
chrysbohá 26 dias

tem um projeto muito bem estruturado para multi tenancy em dotnet c# + angular, caso for a stack que você usa pode te ajudar bastante, caso não for, pode te dar uma noção de como é feito, tem o fonte inteiro disponivel no github e vc pode baixar uma versão com seu nome direto do site deles: https://aspnetboilerplate.com/

sobre multi tenancy: https://aspnetboilerplate.com/Pages/Documents/Multi-Tenancy

valterpatrickhá 26 dias

Eu tinha pensado em desenvolver o meu sistema onde cada cliente teria seu banco de dados e cada banco ficaria em um container docker, onde cada servidor poderia ter tipo uns 100 bancos ou mais, faria algum balanceamento para que todos os servidores tivessem a MSM quantidade de bancos, mas no final após analisar melhor a situação e algumas questões técnicas, não fizemos assim, talvez funcione, mas na época minha equipe apresentou alguns argumentos bons e mudamos para um banco de dados onde todos os clientes conectam. Eu acho interessante esta ideia de separar os clientes por banco, mas assim teria uma complexidade a mais como ter senhas diferentes, portas diferentes para cada contêiner, recursos a mais de processamento para cada banco e etc. Ai tem de ver se é viável ou não. A necessidade e o retorno é maior nesta abordagem?

welovetechhá 18 dias
Mas qual a necessidade disso? Separe os tenants nas tabelas pelo id único de cada cliente, depois vincule isso ao domínio por exemplo, ou a alguma coisa no login e pronto. É a única forma de verticalizar as coisas sem ter que fazer uma via sacra para fazer manutenção. Tenho software financeirode nicho com mais de 10 mil clientes usando diariamente e usamos um banco só e conforme vai sendo necessário, balanceamos e fim.
FrancisFontourahá 26 dias

A questão gira em torno mais da maneira como você obtém uma conexão a partir de algum identificador único do tenant do que da origem dessa informação (no caso, a requisição HTTP) propriamente dita. Trabalho hoje com um sistema multi tenant e dado o acoplamento do código legado (objeto request sendo um god object), tive que escrever uma nova base de código para os jobs, usando clean arch e padrões de projeto, nenhum framework. A ideia é construir uma lib desacoplada na nova base e incorporá-la à base antiga de maneira progressiva, o que é possível por serem bases TypeScript, de modo a extinguir o god object aos poucos. Ainda que isso nunca aconteça, a nova base já atende os novos executáveis da aplicação. Então, já há o benefício. No meu caso, o alto acoplamento justifica a reescrita. Tens que avaliar se é o mesmo caso com você.

devpaulorcchá 25 dias
De que maneira abortaria essa situação de cron jobs fora do contexto http?
FrancisFontourahá 25 dias
No job, a resposta da pergunta "qual tenant?" entra como um argumento (de linha de comando, talvez, ou variável de ambiente, enfim). A questão é que para que isso funcione, a responsabilidade do seu middleware deve estar limitada a apenas responder a pergunta com base na requisição, não de fornecer acesso à infraestrutura correspondente. Uma vez que essa responsabilidade de acessar a infraestrutura (bancos de dados, armazenamento, etc.) esteja isolada, fora do middleware, pode ser utilizada tanto pelo contexto HTTP, quanto pelos jobs. Apenas a resposta de "qual tenant?" virá de fontes diferentes em cada caso, mas o acesso ao banco virá do mesmo código. O componente pode ser classe ou função (ou qualquer coisa) que execute "me forneça acesso ao banco do tenant X".
diegohenriquehá 17 dias

o https://tenancyforlaravel.com/ , tem uma implementação bacana disto para o laravel, ele tem um banco de dados central, que é o db geral, aonde fica uma tabela tenants, com todos os dados, não sei exatamente como ele manipula essa coisa do contexto no cron job, mais essa implementação depende doq exatamente você quer fazer.

welovetechhá 18 dias

Jamais separe as tabelas por clientes. A manutenção vai ser impossível com o crescimento do software. Isso foi até viável no passado, mas com as ideias de arquitetura mais modernas, isso nem é mais cogitado.

devpaulorcchá 16 dias
Que outra forma faria?