Para um de nossos sistemas, temos dados confidenciais do cliente e armazenamos os dados de cada cliente em um banco de dados separado. Temos cerca de 10 a 15 clientes para esse sistema.
No entanto, estamos desenvolvendo um novo sistema que terá de 50 a 100 clientes, talvez mais. Estou pensando que pode ser inviável ter um banco de dados por cliente nesta instância (para armazenar registros confidenciais e histórico de auditoria). Porém não sei se isso é perfeitamente normal ou não, ou se existe outra forma de manter a segurança.
Alguma opinião sobre isso?
Gerenciar 100 ou 500 bancos de dados não é tão diferente de gerenciar 5 ou 10 - você só precisa adotar a automação e ter um plano de escalabilidade implementado (e não planeja usar recursos de alto custo por banco de dados, como espelhamento em todos clientes).
Em meu trabalho anterior, usávamos essa arquitetura e eu nunca teria pensado em mesclar dois clientes em um único banco de dados, mesmo que alguns dos desafios possam ser "difíceis".
Os grandes benefícios são modelos de recuperação independentes (
apodem ser simples,bpodem ser completos, etc.), a capacidade de restaurar em um ponto no tempo (ou remover totalmente) um cliente sem interromper os outros, a capacidade de mover facilmente um cliente com muitos recursos para seu próprio armazenamento ou para um servidor completamente diferente com muito pouca transparência (você atualiza um arquivo de configuração ou tabela que informa ao aplicativo onde encontrar esse cliente).Abordo várias das objeções e/ou como abordar os problemas nestes posts:
Lidando com o número crescente de inquilinos na arquitetura de banco de dados multilocatário
Banco de dados multilocatário usando SQL Server 2008?
Automação de backups de grande número de banco de dados
Dito isso, acho que nenhum de nós pode dizer a você o ponto em que o gerenciamento se torna impraticável para você - apenas saiba que quaisquer que sejam os desafios específicos que você encontrar, você pode perguntar sobre esses problemas individualmente.
Recomendo que você leia Multi-Tenant Data Architecture , um white paper que discute as opções que você tem e os prós e contras. Para resumir, ele oferece três opções:
Agora você está no estágio de bancos de dados separados, que oferece a melhor separação (isolamento entre inquilinos), mas é o mais difícil de gerenciar. À medida que você crescer e se tornar centenas de inquilinos, perceberá que a logística de administrar centenas de bancos de dados está longe de ser trivial. Pense em backup-restauração (localização de arquivos de backup, tarefas, agendamentos, etc.). Pense em como você monitorará e gerenciará a alocação de arquivos, o espaço em disco usado e o crescimento do banco de dados em centenas de bancos de dados. Pense em qual será seu cenário de alta disponibilidade/recuperação de desastres em um futuro próximo com 1.000 inquilinos? 1.000 bancos de dados espelhados, 1.000 sessões de envio de log? Pense e se em 6 meses sua equipe de desenvolvimento chegar até você e disser "Eu sei como dar esse recurso incrível ao nosso produto, usaremos replicação transacional!", o que você dirá? "claro, deixe-me configurar 500 editores,"! Não é impossível gerenciar centenas de bancos de dados, mas se você planeja, é melhor aprimorar suas habilidades do PowerShell e parar de usar as ferramentas de gerenciamento de interface do usuário agora mesmo .
Além disso, você precisa considerar que vários (centenas) bancos de dados têm um impacto mensurável no desempenho e no custo:
Bancos de dados separados vêm com algumas vantagens devido ao isolamento, sendo a principal vantagem o backup/restauração independente.
Cenários como o seu são candidatos perfeitos para bancos de dados do SQL Azure . Sem administração de espaço em disco, sem necessidade de fornecer HA/DR, crescer para centenas/milhares de bancos de dados, etc.
No meu trabalho anterior, hospedávamos não apenas um banco de dados por cliente - na maioria dos casos, era mais do que isso! Quando saí, havia mais de 4.500 bancos de dados em execução em um cluster MariaDB, quase 7.000 em outro cluster (ironicamente menor) e 4 "shards" (servidores de banco de dados e web completamente separados e independentes, mesmo em um data center totalmente separado), cada um hospedando 200-500 bancos de dados em um único servidor MySQL. E essa empresa ainda está crescendo em um bom ritmo.
O longo e o curto é que o sucesso dessa empresa prova que tal arquitetura é realmente viável. (Advertência: ao contrário dos ganhos aparentes no isolamento usando bancos de dados separados, todos os dados foram acessados por meio de um trio de aplicativos fortemente acoplados que usaram o mesmo usuário/senha do banco de dados! Suspeito que o desempenho pode ter sofrido um pouco se cada cliente tinha um usuário/senha separado -- mas apenas um pouco.)
Pelas minhas experiências trabalhando de perto com os administradores de sistema (tecnicamente, eu era um programador da empresa, mas na realidade eu era o melhor DBA que eles tinham e a única pessoa que sabia como configurar um firewall!), relacionados ao desempenho as preocupações se resumiam a acessos simultâneos, complexidade/tempo de consulta, desempenho do índice, etc. - todos os suspeitos de sempre, em outras palavras, e o número de bancos de dados no servidor não desempenhou nenhum papel perceptível, uma conclusão afirmada pelo especialista altamente pago consultores que consultamos regularmente.
O ponto principal é que você deve concentrar suas preocupações em seu aplicativo, em sua infraestrutura e não no número de bancos de dados que você possui. Todos esses outros fatores serão mais do que suficientes para mantê-lo ocupado resolvendo problemas de desempenho e gargalos.