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. Eu acho que pode ser inviável ter um banco de dados por cliente nesta instância (para armazenar registros confidenciais e histórico de auditoria). No entanto, não sei se isso é perfeitamente normal ou não, ou se existe outra maneira de manter a segurança.
Alguma idéia sobre isso?
database-design
sql-server-2012
NibblyPig
fonte
fonte
Respostas:
O gerenciamento de 100 ou 500 bancos de dados não é tão diferente do gerenciamento de 5 ou 10 - você só precisa adotar a automação e ter um plano de escalabilidade em funcionamento (e não planeja usar recursos de alto custo por banco de dados, como o espelhamento em todos os clientes).
No meu trabalho anterior, usamos essa arquitetura e nunca pensei 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,bcompletos, etc.), a capacidade de restaurar em um ponto no tempo (ou remover completamente) um cliente sem atrapalhar os outros, a capacidade de mover perfeitamente um cliente com muitos recursos para seu próprio armazenamento ou para um servidor completamente diferente com muito pouco em termos de transparência (você atualiza um arquivo ou tabela de configuração que informa ao aplicativo onde encontrar esse cliente).Abordo várias das objeções e / ou como abordar os problemas nessas postagens:
Como lidar com um número crescente de inquilinos na arquitetura de banco de dados com vários inquilinos
Banco de dados multilocatário usando o SQL Server 2008?
Automação de backups de grande número de banco de dados
Isso tudo dito, eu não acho que qualquer um de nós pode dizer que você o ponto em que a gestão torna-se impraticável para você - só sei que o que quer específica desafia você se deparar, você pode perguntar sobre esses problemas individualmente.
fonte
Eu recomendo que você leia Arquitetura de dados com vários inquilinos , um white paper que discute as opções que você tem, e os prós e contras. Para resumir, ele fornece 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ê cresce em centenas de inquilinos, percebe que a logística de administração de centenas de bancos de dados está longe de ser trivial. Pense em backup-restauração (localização de arquivos de backup, trabalhos, agendas etc.). Pense em como você irá 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 qual será o seu cenário de alta disponibilidade / recuperação de desastres em um futuro próximo com 1000 inquilinos? 1000 DBs espelhados, 1000 sessões de envio de logs? Pense e se em 6 meses sua equipe de desenvolvimento chegar até você e disser "Eu sei como fornecer esse recurso incrível ao nosso produto, usaremos a 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 no PowerShell e parar de usar as ferramentas de gerenciamento da interface do usuário agora .
Além disso, é necessário considerar que vários (centenas) DBs têm um impacto mensurável no desempenho e no custo:
Os bancos de dados separados têm algumas vantagens devido ao isolamento, sendo a principal vantagem o backup / restauração independente.
Cenário como o seu, no entanto, é um candidato perfeito para os bancos de dados do SQL Azure . Sem administração de espaço em disco, sem necessidade de fornecer HA / DR, aumentar para centenas / milhares de bancos de dados, etc.
fonte
No meu trabalho anterior, hospedamos 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 web e de banco de dados independentes e completamente separados, mesmo em um data center totalmente separado) cada hospedagem 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 essa arquitetura é realmente viável. (Advertência: ao contrário dos ganhos aparentes no isolamento usando bancos de dados separados, todos os dados foram acessados através de um trio de aplicativos fortemente acoplados que usavam o mesmo usuário / passe do banco de dados! Suspeito que o desempenho possa ter sofrido um pouco se cada cliente tinha um usuário / passe separado - mas apenas um pouco.)
De minhas experiências trabalhando em estreita colaboração com os administradores do sistema (tecnicamente eu era um programador da empresa, mas, na realidade, eu era o melhor DBA que eles tinham e a única pessoa que tinha que sabia como configurar um firewall!), Relacionada ao desempenho as preocupações se resumiam a acessos simultâneos, complexidade / tempo da consulta, desempenho do índice etc. - todos os suspeitos do costume, em outras palavras, e o número de bancos de dados no servidor não desempenhou um papel discernível, uma conclusão afirmada pelo especialista altamente remunerado 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 existentes. Todos esses outros fatores serão mais que suficientes para mantê-lo ocupado na solução de problemas de desempenho e gargalos.
fonte