Você pode implementar a multilocação com o MongoDB Search para que uma única instância de um aplicativo sirva a vários locatários. Esta página descreve recomendações de design que se aplicam especificamente ao MongoDB Search para dados estruturados e aos índices do MongoDB Search para dimensionar com segurança enquanto mantém o isolamento do locatário.
Importante
Esta orientação pressupõe que você pode colocar locatários em uma única VPC. Se o isolamento rigoroso da rede for necessário, você deverá manter projetos separados para cada locatário.
Escolher uma estratégia
Selecione uma estratégia com base em suas necessidades de isolamento, metas de dimensionamento e requisitos de carga de gravação. As estratégias mais comuns são:
A single collection for all tenants - This strategy is recommended for most workloads.
One Database per tenant - This strategy offers high isolation but increases index count.
Uma coleção por locatário – essa estratégia não é recomendada para cargas de trabalho do MongoDB Search.
Uma única coleção para todos os inquilinos (recomendado)
Recomendamos aplicar a estratégia de uma coleção para todos os locatários. Nessa arquitetura, você armazena todos os dados de locatários em uma única coleção dentro de um único banco de dados. Você pode distinguir entre inquilinos incluindo um campo tenant_id dentro de cada documento. Este campo pode ser qualquer identificador exclusivo para o locatário, como UUID ou um nome de locatário.
Essa abordagem centralizada oferece os seguintes benefícios:
Reduz o número de índices
Como todos os dados do locatário são armazenados em uma coleção, você precisa de apenas um único índice que sirva documentos para todos os locatários. Você evita atingir os limites de recursos do cluster. Por exemplo, você pode incluir o
tenant_ide outros campos compartilhados ou específicos do inquilino em um único índice.Simplifica as operações de manutenção
Com apenas uma única coleção armazenando todos os dados, você não precisa manter várias coleções ou dimensionar recursos em vários bancos de dados. Você também simplifica as operações de backup, fragmentação e replicação, pois precisa direcionar apenas uma única coleção em um único banco de dados.
Processa query de forma eficiente
Você fornece o campo
tenant_idem suas queries como um filtro usando o operador igual na cláusula$search.compound.filter.Observação
Os resultados da query incluirão apenas documentos do locatário correspondente, evitando o vazamento de dados entre locatários.
Se os locatários que você coloca compartilharem padrões de acesso e tamanhos de recursos semelhantes, essa estratégia também manterá a contagem de campo de índice Lucene baixa.
Importante
Quando cada locatário tem uma alta carga de gravação, colocar todos os locatários em uma única coleção pode criar uma contenção de gravação. Nesse cenário, considere dividir os locatários com o maior número de gravações em coleções separadas para distribuir a carga de gravação por mais recursos subjacentes.
Se você tiver locatários grandes com requisitos exclusivos de recursos ou indexação, use uma Visualização:
Índice separadamente. Crie um índice de pesquisa MongoDB na visualização.
Isso permite que você personalize a definição de índice para o locatário grande sem afetar o índice compartilhado usado por outros. Todos os outros locatários podem usar um único índice.
Uma contagem alta de índices gera uma carga significativa no cluster base e pode interromper sua carga de trabalho. O número de índices que seu cluster pode suportar depende da camada do cluster e da carga de trabalho. Camadas do cluster menores, como
M10, podem sofrer degradação de desempenho ou erros de falta de memória à medida que a contagem de índices aumenta. Comece com um pequeno número de índices e monitore o uso de recursos do seu cluster à medida que você dimensiona.
If you currently apply the one collection per tenant strategy, we recommend scaling up the base tier to prevent increased replication lag or OOM errors due to resource contention from a high number of indexes. We also recommend migrating to the one collection for all tenants strategy.
Lidando com inquilinos de alta gravação
Se locatários específicos tiverem cargas de escrita massivas, eles poderão causar contenção em uma coleção compartilhada. Recomendamos que você mova somente os locatários de maior volume para coleções separadas para distribuir a carga de E/S.
Tratamento de requisitos únicos (visualizações)
If a tenant requires unique indexing or is significantly larger than others, use a MongoDB View:
Crie uma visualização usando
$matchpara filtrar apenas os documentos desse locatário.Crie um índice de pesquisa do MongoDB nessa visualização. Isso permite a personalização para locatários outliers sem interromper o índice compartilhado usado pela maioria.
Um banco de dados por locatário
Em um configurar de banco de dados por tenant, cada tenant contém seu próprio banco de dados. Esse configurar isola os dados do tenant, mas também multiplica o número de índices no cluster. À medida que o número de banco de dados de tenant aumenta, a contagem de índice pode exceder o que sua camada do cluster e carga de trabalho podem suportar.
Aviso
Uma contagem alta de índices gera uma carga significativa no cluster base e pode interromper sua carga de trabalho. O número de índices que seu cluster pode suportar depende da camada do cluster e da carga de trabalho. Camadas do cluster menores, como M10, podem sofrer degradação de desempenho ou erros de falta de memória à medida que a contagem de índices aumenta. Comece com um pequeno número de índices e monitore o uso de recursos do seu cluster à medida que você dimensiona.
Uma coleção por locatário (não recomendado)
A estratégia de coleção por inquilino mapeia cada inquilino para sua própria coleção em um banco de dados compartilhado. A sobrecarga de manter um índice por coleção pode causar:
Maior atraso de replicação
Erros de OOM devido à contenção de recursos
Instabilidade no nível base
We do not recommend this strategy for MongoDB Search unless tenants have very predictable, lightweight workloads. If you currently use this strategy, migrate toward the one collection for all tenants strategy.
Gerenciando campos indexados
Considere as seguintes recomendações para gerenciar campos indexados: