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

Estou configurando um sistema SaaS, no qual planejamos fornecer a cada cliente seu próprio banco de dados. O sistema já está configurado para que possamos escalar facilmente para servidores adicionais se a carga se tornar muito alta; esperamos ter milhares ou mesmo dezenas de milhares de clientes.

Questões

• Existe alguma limitação prática no número de micro-bancos de dados que você pode / deve ter em um SQL Server?
• Isso pode afetar o desempenho do servidor?
• É melhor ter 10.000 bancos de dados de 100 MB cada, ou um banco de dados de 1 TB?

Informação adicional

Quando digo "micro-bancos de dados", não quero dizer "micro"; Quero apenas dizer que estamos visando milhares de clientes, para que cada banco de dados individual represente apenas um milésimo ou menos do armazenamento total de dados. Na realidade, cada banco de dados ficaria em torno da marca de 100 MB, dependendo de quanto uso ele receber.

O principal motivo para usar 10.000 bancos de dados é a escalabilidade. O fato é que a V1 do sistema possui um banco de dados e tivemos alguns momentos desconfortáveis ​​em que o banco de dados estava sobrecarregado.

Estava sobrecarregando CPU, memória, E / S - todas as opções acima. Embora tenhamos resolvido esses problemas, eles nos fizeram perceber que, em algum momento, mesmo com a melhor indexação do mundo, se tivermos o sucesso que esperamos ter, simplesmente não podemos colocar todos os nossos dados em um grande espaço. ' base de dados. Portanto, para a V2, estamos compartilhando, para que possamos dividir a carga entre vários servidores de banco de dados.

Passei o último ano desenvolvendo essa solução fragmentada. É uma licença por servidor, mas de qualquer maneira isso é resolvido, pois estamos usando VMs no Azure. A razão pela qual a questão surge agora é porque anteriormente estávamos oferecendo apenas a grandes instituições e montando cada uma delas. Nossa próxima ordem de negócios é um modelo de autoatendimento em que qualquer pessoa com um navegador pode se inscrever e criar seu próprio banco de dados. Seus bancos de dados serão muito menores e muito mais numerosos que as grandes instituições.

Tentamos Pools elásticos do banco de dados SQL do Azure . O desempenho foi muito decepcionante, por isso voltamos às VMs regulares.

Trabalhei em servidores SQL com 8 a 10 mil bancos de dados em uma única instância. Não é bonito.

Reiniciar o servidor pode levar até 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 maneira confiável no Pesquisador de Objetos.

Os backups são um pesadelo, pois para que os backups valham a pena, é necessário ter uma solução viável de recuperação de desastres. Espero que sua equipe seja excelente em criar scripts para tudo .

Você começa a nomear bancos de dados com números, como M01022e T9945. Tentar garantir que você esteja trabalhando no banco de dados correto, por exemplo, em M001022vez de M01022, pode ser enlouquecedor.

Alocar memória para muitos bancos de dados pode ser torturante; O SQL Server acaba realizando muitas E / S, o que pode ser um empecilho real para o desempenho. Considere um sistema que registre detalhes do uso de carbono em quatro 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 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ê criar que será executada nessas tabelas exigirá pelo menos 10.000 planos no cache do plano se houver 10.000 bancos de dados em uso.

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

Você provavelmente encontrará coisas como o Serviço do SQL Server demorando muito tempo para iniciar, o que pode causar erros no Controlador de Serviço. Você pode aumentar o tempo de inicialização do serviço, criar a seguinte entrada do 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 do tempo limite do serviço, digite 600000.

Desde que escrevi minha resposta, percebi que a pergunta está falando do Azure. Talvez fazer isso no banco de dados SQL 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, existem prós e contras nos dois métodos. Sem saber mais sobre o seu aplicativo ou os serviços que você deseja fornecer, não poderei dar uma resposta definitiva, mas jogarei fora alguns dos meus pensamentos sobre o assunto.

Meu argumento é 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 executar sua tarefa de manutenção em um local e não em muitos. Imagine o pesadelo de lidar com 1000 bancos de dados diferentes para fazer backup. Que tal atualizar estatísticas em 1000 DBs ou reconstruir índices ou DBCC CHECKDB?

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

• Visibilidade fácil. Imagine o SSMS tentando abrir mais de 1000 DBs (tremores) . Praticamente tornaria o problema inútil e levaria uma quantidade surpreendente de tempo para abrir e renderizar o SSMS. Lembre-se de que é possível criar uma convenção de nomenclatura decente.

Contras

• Segurança. Seria mais fácil impedir 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 impedir que isso aconteça.

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

Por fim, acho que sua melhor aposta é ter um banco de dados para sua aplicação e apenas dividir os dados do cliente dentro do próprio banco de dados. Os problemas que isso causará não serão nada em comparação com o pesadelo de gerenciar mais de 1000 bancos de dados.

Especificações de capacidade máxima para o SQL Server afirma que há um limite de 32.767.

Quanto a afetar o desempenho, a resposta é afirmativa, mas as maneiras pelas quais afetará o desempenho e se seria substancial dependeriam de uma infinidade de fatores.

Eu iria com o banco de dados único, a menos que haja 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 um bom motivo para usar 10.000 bancos de dados 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 é sobre arquitetura de vários locatários versus várias instâncias . Estou apenas trazendo esses termos para você não usá-los na sua pergunta, mas é assim que você está discutindo e se você apenas conectar a "arquitetura multi-inquilino" ao Google, encontrará muitos recursos e discussões. sobre isso, livros inteiros foram escritos nele.

Alguns bons recursos sobre o SQL Server especificamente aqui:

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

https://docs.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 em relação a vários inquilinos como padrão, a menos que você tenha razões convincentes para favorecer várias instâncias.

Você não precisa se dividir em milhares de bancos de dados de clientes individuais para escalar; existem muitas outras maneiras de fazer isso, que provavelmente são preferíveis. Como cluster, replicação, sharding, 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 da adição de cada novo cliente.

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

Pode haver razões pelas quais você deseja facilitar isso, por exemplo, se estiver vendendo seu produto para um cliente que DEVE tê-lo hospedado internamente em sua própria infraestrutura. Mas, como regra geral do SAAS, incline-se como padrão para uma arquitetura de vários locatários.

Uma das desvantagens que vejo na sugestão de banco de dados único é a reversão de dados - se você tiver um banco de dados por configuração de inquilino, poderá restaurar os dados de cada cliente de forma independente (e em um determinado momento). Se eles estiverem todos em um banco de dados, isso se tornará muito mais difícil (e muito mais propenso a erros, pois provavelmente seria necessário fazer isso através das instruções INSERT / UPDATE / DELETE).

Obrigado a todos que responderam - realmente aprecio os pontos que você me deu para pensar. O sentimento geral que tive foi que um único banco de dados é preferível, mas gostaria de acrescentar alguns pontos de compensação em 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 maciças 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 suporta a carga, por isso precisamos distribuir em vários servidores. E uma vez que você precisa procurar em qual servidor os dados de qualquer cliente estão, não é muito mais trabalhoso fornecer a eles um banco de dados dedicado, o que simplifica as coisas em termos de manter os dados das pessoas bem segregados.

Resposta a preocupações

• Reiniciar o servidor leva muito tempo: OK, mas em operação normal não pretendemos reiniciar nenhum servidor. O sistema precisa estar on-line 24 horas por dia, 7 dias por semana, portanto, se tivermos tempo de inatividade, ele deverá ser agendado.
• Backups / recuperação de desastre: estamos usando o CloudBerry, que automatiza tudo. Não é um problema.
• Nomeando bancos de dados / localizando-os no SSMS: A convenção de nomes é fácil, apenas com base no nome do cliente. Adicione dígitos de série 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 índices manualmente.
• Implantando código: usamos o Entity Framework, para que todas as alterações de esquema sejam 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 no índice, não é tão fácil apenas empurrá-lo para fora. Por outro lado, com cada banco de dados sendo tão pequeno, é improvável que ocorram problemas de desempenho nos fragmentos de produção. E o banco de dados comum permanece um único banco de dados, ao qual essas preocupações não se aplicam.

Ficarei feliz em receber uma resposta sua nos comentários, se você acha que estou perdendo alguma coisa!