Em que momento um banco de dados por cliente se torna inviável?

31

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

Não conheço os prós e contras de ter vários bancos de dados por servidor (nunca tive nenhum problema com isso), mas o conceito de muitos esquemas technet.microsoft.com/en-us/library/dd207005.aspx no mesmo banco de dados oferece ambos isolamento e segurança. Então, você pode tentar essa arquitetura também.

— Alexandros

2

A separação de esquemas do @Alexandros oferece um pouco, mas não permite que você use modelos de recuperação separados, faça backup em agendamentos diferentes, restaure um cliente em um ponto específico no tempo, remova um cliente com facilidade, mova um cliente com facilidade etc.

— Aaron Bertrand

4

Já vi sistemas com mais de 3.000 bancos de dados (1 por cliente) em um único servidor. Não me preocuparia muito - apenas planeje os recursos cuidadosamente e monitore o uso à medida que a contagem de clientes aumenta.

— Max Vernon

Você pode ler isso, observe especificamente as datas e os comentários das operações: stackoverflow.com/questions/5596755/…

— NotMe

48

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:

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.

— Aaron Bertrand
fonte

6

Você também precisará de uma boa convenção de nomenclatura, aplicada de forma consistente.

— precisa

Obrigado, esses são alguns ótimos links. Não é realmente uma questão de gerenciamento (no momento), eu estava apenas preocupado que as coisas pudessem parar. Mas parece que não devo me preocupar com isso e apenas garantir que posso gerenciar tudo. Então obrigado!

— NibblyPig

@ Aaron, tenho um cenário semelhante no OMS, onde tenho várias oficinas que processam um pedido e são independentes. O workshop é selecionado com base no endereço do pedido (cliente). Assim, um cliente pode ter pedidos em vários locais de trabalho. Portanto, é difícil quando é necessário carregar o histórico de pedidos do Cliente conforme a necessidade de cada servidor de banco de dados.

— Navrattan Yadav

15

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:

DBs separados
esquemas separados
esquema compartilhado

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:

o espaço físico em disco é usado com menos eficiência (todo banco de dados deve ter algum espaço livre, você terá esse espaço multiplicado pelo número de bancos de dados)
Não há como criar um disco de log dedicado para tarefas intensivas de gravação; você precisará mover todos esses LDFs para um (ou mais) armazenamento SSD
as gravações de log serão menos eficientes nas confirmações frequentes, pois se espalharão por muitos registros individuais de blocos de log versus agregados em um (você obterá blocos de log subutilizados). Consulte O que é um LSN: Log Sequence Number para entender do que estou falando.

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.

— Remus Rusanu
fonte

Obrigado, este é um bom conselho, especialmente a possibilidade de mudar para um modelo de nuvem. Vou ter que pensar seriamente em como vou lidar com o backup das coisas.

— NibblyPig

E uma vez que sua automação esteja suficientemente bem desenvolvida para oferecer suporte a bancos de dados separados para cada cliente, não será um grande salto dali provisionar VMs separadas para cada cliente. Afinal, é isso que as empresas de hospedagem em "nuvem" fazem. Concordo que este é possivelmente um caso de bom uso para SQL Azure

— Gavin Campbell

2

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.

— Kromey
fonte