Construa uma arquitetura multilocatário
Nesta página
Você pode implementar a multilocação com o Atlas para que uma única instância de um aplicativo atenda a vários locatários. Suas decisões iniciais de design para uma arquitetura multilocatário podem ter efeitos não intencionais ao longo do tempo, à medida que os requisitos evoluem ou as expectativas de dimensionamento mudam.
A melhor abordagem pode depender dos seguintes fatores:
Requisitos de dimensionamento projetados (número de locatários e uso de dados)
Requisitos de segurança e isolamento
Uniformidade ou variabilidade dos requisitos de dados em todos os inquilinos
Considere esses fatores ao decidir sobre a melhor abordagem a ser usada em sua arquitetura multilocatária.
Ao projetar uma arquitetura de vários inquilinos, considere as seguintes abordagens:
Descrição | Se você tiver um número pequeno e estável (até algumas centenas) de locatários com requisitos de dados variados e requisitos rigorosos de controle de acesso, considere um banco de dados por locatário. | Se você espera um número indefinidamente crescente de locatários, e a estrutura de dados e requisitos de query é relativamente consistente entre os locatários, considere ter os dados dos locatários coexistindo em coleções compartilhadas dentro de um único banco de dados. Você pode usar um campo tenantId em cada documento para segmentar logicamente os dados entre os inquilinos. |
|---|---|---|
Benefícios |
|
|
Considerações | Você pode:
|
|
Evite todos os inquilinos com suas próprias coleções em um único banco de dados.
Importante
Considerações de segurança
Em todas as abordagens a seguir, você constrói uma arquitetura de vários inquilinos em um único cluster. Você compartilha o oplog de replicação e os dados do usuário entre todos os locatários, o que pode resultar em possíveis preocupações de segurança. Para proteger o particionamento de dados, você deve implantar um único conjunto de réplicas pequeno para cada locatário com autenticação exclusiva.
Dica
Veja também:
Cada inquilino em seu próprio banco de dados
Se você tiver um número pequeno e estável (até algumas centenas) de locatários com requisitos de dados variados e requisitos rígidos de controle de acesso, considere a criação de um banco de dados por locatário.
Essa abordagem tem os seguintes benefícios:
Para maior segurança, o usuário do banco de dados pode limitar o acesso aos dados do locatário. Como padrão, o Atlas impõe um limite de 100 usuários do banco de dados por projeto.
Para levar em conta padrões de acesso exclusivos para estruturas de dados variáveis entre locatários, você pode definir a indexação.
Para mover um único locatário para seus próprios recursos dedicados, você pode migrar ou dimensionar os dados isolados de um locatário inteiro para novos recursos (por exemplo, outro cluster).
Considere que você pode:
Adicione mais complexidade à camada de aplicativos.
Tenha collections e índices redundantes entre os inquilinos.
Resolver problemas em escala em um único cluster. Os arquivos de dados subjacentes exigidos para cada nova coleção e índice consomem recursos computacionais.
Cada locatário tem seu próprio banco de dados lógico no mesmo cluster. Essa abordagem permite fácil personalização e forte segurança. Permite backups e ações de manutenção para um inquilino sem afetar os outros.
No entanto, essa abordagem pode aumentar o esforço de configuração e os recursos computacionais necessários. As interações entre locatários exigem conexões com vários bancos de dados. Alguns comandos MongoDB funcionam apenas entre coleções no mesmo banco de dados.
Cada coleção e índice é armazenado no disco como um arquivo separado, o que pode levar a um número muito grande de arquivos abertos e alto uso de memória. Para mitigar isso, use menos de 1000 arquivos de dados (coleções e índices individuais) por nó. Para saber mais, consulte Limites de coleção e índice.
Todos os contratos em um único banco de dados com coleções compartilhadas
Se você espera um número indefinidamente crescente de locatários, a estrutura de dados e os requisitos de queries são relativamente consistentes entre os locatários e você tem requisitos de controle de acesso menos rigorosos, considere o uso de um único database com coleções compartilhadas para todos os tenants.
Essa abordagem tem os seguintes benefícios:
Altamente escalável (por exemplo, você pode fragmentar o cluster)
Simplifica a manutenção contínua (por exemplo, indexação para novos padrões de query)
Considere os seguintes possíveis problemas:
Um único utilizador de banco de dados poderia acessar esse grande conjunto de dados multi-tenant.
A segmentação de dados é puramente lógica e deve ser imposta na camada do aplicativo.
Todos os inquilinos podem ter documentos em todas as collections. A lógica de multilocação existe na camada do aplicativo. Cada documento deve ter um campo tenantId e cada query de banco de dados deve filtrar por esse campo. Você deve gerenciar a segurança no nível do aplicativo.
Você pode encontrar problemas de dimensionamento a longo prazo. Qualquer manutenção que você realizar afeta todos os locatários ao mesmo tempo. Embora essa abordagem funcione bem para muitos locatários pequenos do mesmo tamanho, ela não funciona bem se os tamanhos dos locatários variarem. Além disso, você pode achar difícil personalizar as configurações para cada locatário.
Todos os inquilinos com suas próprias coleções em um único banco de dados
Evite colocar todos os locatários com suas próprias coleções em um único banco de dados. Embora essa abordagem evite problemas de customização, ela complica o código do aplicativo e agrava os problemas de dimensionamento a longo prazo.