Existe algum limite para o número de bancos de dados que você pode colocar em um servidor SQL?

Já trabalhei em SQL Servers com 8 a 10 mil bancos de dados em uma única instância. Não é bonito.

A reinicialização do servidor pode levar uma hora ou mais. Pense no processo de recuperação de 10.000 bancos de dados.

Você não pode usar o SQL Server Management Studio para localizar um banco de dados de forma confiável no Pesquisador de Objetos.

Os backups são um pesadelo, pois, para que os backups valham a pena, você precisa ter uma solução de recuperação de desastres viável. Espero que sua equipe seja ótima em scripts de tudo .

Você começa a fazer coisas como nomear bancos de dados com números, como M01022, e T9945. Tentar ter certeza de que você está trabalhando no banco de dados correto, por exemplo, M001022em vez de M01022, pode ser enlouquecedor.

Alocar memória para tantos bancos de dados pode ser excruciante; O SQL Server acaba fazendo muita E/S, o que pode prejudicar muito o desempenho. Considere um sistema que registra os detalhes do uso de carbono em 4 tabelas para 10.000 empresas. Se você fizer isso em um banco de dados, precisará apenas de 4 tabelas; se você fizer isso em 10.000 bancos de dados, de repente você precisará de 40.000 tabelas na memória. A sobrecarga de lidar com esse número de tabelas na memória é substancial. Qualquer consulta que você projetar que será executada nessas tabelas exigirá pelo menos 10.000 planos no cache de planos se houver 10.000 bancos de dados em uso.

A lista acima é apenas uma pequena amostra dos problemas que você precisará planejar ao operar nesse tipo de escala.

Você provavelmente encontrará coisas como o SQL Server Service demorando muito para inicializar, o que pode causar erros do Service Controller. Você mesmo pode aumentar o tempo de inicialização do serviço, crie a seguinte entrada de registro:

Subchave: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
Nome: ServicesPipeTimeout
Tipo: REG_DWORD
Dados: o número de milissegundos antes que o tempo limite ocorra durante a inicialização do serviço

Por exemplo, para aguardar 600 segundos (10 minutos) antes que o serviço expire, digite 600000.

Desde que escrevi minha resposta, percebi que a pergunta está falando sobre o Azure. Talvez fazer isso no Banco de Dados SQL do Azure não seja tão problemático; talvez seja mais problemático. Pessoalmente, eu provavelmente projetaria um sistema usando um único banco de dados, talvez fragmentado verticalmente em vários servidores, mas certamente não um banco de dados por cliente.

Portanto, há prós e contras para ambos os métodos. Sem saber mais sobre seu aplicativo ou os serviços que você deseja fornecer, não poderei dar uma resposta definitiva, mas vou expor alguns dos meus pensamentos sobre o assunto.

Meu caso de por que você deve usar 1 banco de dados para todos os clientes.

Prós

• Manutenção fácil. Ter um banco de dados significa que você só precisa fazer sua tarefa de manutenção em um local em vez de muitos. Imagine o pesadelo de lidar com 1.000 bancos de dados diferentes para fazer backup. Que tal atualizar estatísticas em 1000 DB's ou reconstruir índices ou DBCC CHECKDB?

• Código de implantação. Digamos que você tenha um problema com um procedimento armazenado em seu código de aplicativo ou relatório. Você precisa fazer uma alteração rápida... Agora você precisa implantar essa alteração em mais de 1000 DBs. Não, obrigado, prefiro não.

• Fácil Visibilidade. Apenas imagine o SSMS tentando abrir mais de 1000 DBs (estremecer) . Isso praticamente tornaria o problema inútil e levaria um tempo surpreendente para abrir e renderizar o SSMS. Lembre-se, isso se você conseguir criar uma convenção de nomenclatura decente.

Contras

• Segurança. Seria mais fácil evitar que as pessoas olhassem os dados de outros clientes se você os tivesse como bancos de dados separados. No entanto, existem algumas coisas muito simples que você pode fazer para evitar que isso aconteça.

• Atuação. Pode-se argumentar que limitar um banco de dados por cliente significa que o SQL Server terá que varrer menos dados para obter as informações que você está consultando. No entanto, com uma estrutura de dados adequada e uma boa indexação (e possível particionamento), você provavelmente pode eliminar isso como um problema se for feito com cuidado. Eu recomendaria dar a cada tabela que contém dados específicos do cliente algum tipo de guia CompanyIDpara reduzir essa sobrecarga.

Em última análise, acho que sua melhor aposta é ter um banco de dados para seu aplicativo e apenas dividir os dados do cliente dentro do próprio banco de dados. Os problemas que isso lhe dará não serão nada em comparação com o pesadelo de gerenciar mais de 1000 bancos de dados.

As especificações de capacidade máxima para SQL Server indicam que há um limite de 32.767.

Quanto ao fato de afetar o desempenho, a resposta é sim, mas as maneiras como afetará o desempenho, e se seria substancial, dependeria de uma infinidade de fatores.

Eu usaria um banco de dados, a menos que houvesse uma boa razão para dividi-lo em 10.000 bancos de dados. Um backup ou 10.000 backups? Uma verificação de integridade ou 10.000? Pode haver uma boa razão para usar 10.000 BDs pequenos, mas você não forneceu detalhes suficientes para determinar isso. A pergunta que você fez é bastante ampla e simplesmente não há informações suficientes para que alguém saiba qual é a melhor resposta.

O que você está falando aqui é arquitetura multi-tenant vs multi-instância . Estou apenas trazendo esses termos, pois você não os usa em sua pergunta, mas é assim que você está discutindo e se você apenas conectar "arquitetura multilocatário" ao Google, encontrará uma riqueza de recursos e discussões sobre isso, livros inteiros foram escritos sobre ele.

Alguns bons recursos sobre o SQL Server especificamente aqui:

https://msdn.microsoft.com/en-us/library/ff966499.aspx

https://learn.microsoft.com/en-us/azure/sql-database/sql-database-design-patterns-multi-tenancy-saas-applications

Eu estaria com outras respostas, na medida em que me inclinaria fortemente para o multi-tenant como padrão, a menos que você tenha razões convincentes para favorecer a multi-instância.

Você não precisa dividir em milhares de bancos de dados de clientes individuais para dimensionar, existem muitas outras maneiras de fazer isso, que provavelmente serão preferíveis. Como clustering, replicação, fragmentação, particionamento etc. Não reinvente a roda. Não há nada inerente que diga que você precisa dividir isso manualmente em um nível de cliente individual e, de fato, isso provavelmente aumentará significativamente os custos de adicionar cada novo cliente.

Você está falando de "milhões" de clientes, pense em qualquer software como serviço baseado em nuvem em grande escala, Gmail, qualquer que seja, você dificilmente acha que eles criam um banco de dados totalmente novo para cada nova inscrição, não é?

Pode haver razões em que você queira facilitar isso, por exemplo, se você estiver vendendo seu produto para um cliente que DEVE hospedá-lo internamente em sua própria infraestrutura. Mas, como regra geral do SAAS, use como padrão uma arquitetura multilocatário.

Uma das desvantagens que posso ver na sugestão de banco de dados único é a reversão de dados - se você tiver um banco de dados por configuração de locatário, poderá restaurar os dados de cada cliente independentemente (e em um determinado momento). Se eles estiverem todos em um banco de dados, isso se torna muito mais difícil (e muito mais propenso a erros, pois provavelmente precisaria ser feito por meio de instruções INSERT/UPDATE/DELETE).

Obrigado a todos que responderam - realmente aprecio os pontos que você me deu para pensar. A sensação geral que tive foi que um único banco de dados é preferível, mas gostaria de adicionar alguns pontos de compensação a favor da arquitetura fragmentada e abordar algumas das preocupações que outras pessoas mencionaram.

Motivação para sharding

Conforme mencionado na pergunta (atualizada), estamos buscando vendas massivas em todo o mundo, com literalmente milhões de usuários. Com o melhor hardware e indexação do mundo, um único servidor de banco de dados não suportará a carga, portanto, precisamos ser capazes de distribuir em vários servidores. E uma vez que você precisa procurar em qual servidor os dados de um determinado cliente estão, não dá muito mais trabalho fornecer a eles um banco de dados dedicado, o que torna as coisas mais simples em termos de manter os dados das pessoas perfeitamente segregados.

Resposta às Preocupações

• Reiniciar o servidor leva muito tempo: OK, mas em operação normal não pretendemos reiniciar nenhum servidor. Em última análise, o sistema precisa estar online 24 horas por dia, 7 dias por semana, portanto, se tivermos tempo de inatividade, ele terá que ser agendado de qualquer maneira.
• Backups/recuperação de desastres: Estamos usando o CloudBerry, que automatiza tudo. Não é um problema.
• Nomear bancos de dados/localizá-los no SSMS: A convenção de nomenclatura é fácil, apenas com base no nome do cliente. Adicione dígitos seriais se os nomes forem compartilhados.
• Manutenção: Se cada banco de dados for tão pequeno quanto eu imagino, não haverá necessidade de reconstruir os índices manualmente.
• Implantação de código: usamos o Entity Framework, portanto, todas as alterações de esquema serão implementadas automaticamente em cada banco de dados com novos lançamentos. É verdade, porém, que se descobrirmos um problema de desempenho na produção que pode ser corrigido com um simples ajuste de índice, não é tão fácil simplesmente colocá-lo lá fora. Por outro lado, com cada banco de dados sendo tão pequeno, é improvável que ocorram problemas de desempenho impressionantes nos fragmentos de produção. E o banco de dados comum continua sendo um único banco de dados, ao qual essas preocupações não se aplicam.

Ficarei feliz em ouvir de volta de você nos comentários se você acha que estou perdendo alguma coisa!