Não é uma resposta fácil porque muito depende da arquitetura do seu aplicativo, uso e padrões de consulta, a distribuição entre os clientes (ou seja:os níveis de uso serão aproximadamente os mesmos entre os clientes, ou você poderia ter 10% dos clientes usando 90% do recursos), quanto você pode gastar em gerenciamento de código versus operações e uma série de outros problemas. Aqui estão algumas coisas a considerar:

1) ter um banco de dados tornará seu gerenciamento de operações mais fácil, exigirá menos recursos de computação e poderá permitir que você escale melhor, mas codificar a camada de acesso será mais difícil e você realmente precisará arquitetar bem sua camada de segurança por motivos óbvios. Você também consumirá menos recursos no cliente/servidor da Web, pois haverá muito menos conexões.

Existem duas opções de esquema populares ao abordar um banco de dados monolítico:

• Você pode colocar todos os dados semelhantes em uma coleção (ou seja:perfis de todas as contas vão para a mesma coleção) e dar a cada documento uma chave de ID de cliente para identificar quais dados pertencem a qual conta. Isso pode fornecer as melhores opções (dependendo da arquitetura do esquema) para dimensionar com o menor número de recursos de computação.
• Outra opção é separar os dados do cliente por coleções - cada cliente terá suas próprias coleções dentro do banco de dados identificadas com um prefixo clientid (ou seja:clientid_userprofiles).

2) a opção de banco de dados por cliente lhe dará mais dores de cabeça de gerenciamento de operações e custará mais, pois você precisará de mais recursos de computação. Por outro lado, seus custos de codificação devem ser menores, pois o código será mais fácil de escrever. Também permitirá que você distribua melhor seus recursos entre usuários pesados ​​e leves. Por exemplo, você pode mover clientes de uso intenso para máquinas mais poderosas e fornecer fragmentação por cliente.

3) você pode fornecer uma combinação das duas opções - bancos de dados dedicados para usuários finais (contas que pagam mais) e, em seguida, um banco de dados compartilhado com dados separados por coleção para clientes de baixo custo e contas de teste/freemium.

Observe que, se você seguir a rota de muitos bancos de dados, deverá procurar a opção de inicialização --smallfiles. Isso o ajudará em situações em que você tem muitas pessoas configurando "contas de teste", mas que não fazem muito com elas.

De qualquer forma, espero que o acima lhe dê o que pensar. Faça uma pesquisa em https://groups.google.com /forum/?fromgroups#!searchin/mongodb-user/multitenant já que tem havido uma série de discussões nos fóruns do Mongo sobre esta questão específica.

Quanto às implicações de auditoria, depende de qual nível de conformidade de auditoria você precisa aderir. Se você espera clientes da Fortune 1000, seus requisitos de conformidade serão muito maiores (e muito mais caros - pense em $ 10 a $ 100 de milhares de dólares), do que se seus clientes fossem startups que talvez nunca tenham ouvido falar do SAS70, etc. A resposta também depende do tipo de dados que você está armazenando - são dados financeiros do usuário ou são apenas fóruns de usuários? Basicamente, se houver alguma preocupação sobre a necessidade de passar por auditorias de segurança para grandes empresas no futuro, nem pense na abordagem de banco de dados compartilhado.