Estamos construindo uma aplicação onde cada cliente terá seu próprio banco de dados. Nenhum dos bancos de dados é particularmente grande (20MB a 400MB cada), mas haverá ~ 5.000 para iniciar e a qualquer momento 100 ou mais estarão ativos.
Nossa equipe vem debatendo a melhor forma de configurar o sistema. Os clientes só acessam o banco de dados uma vez a cada duas semanas (processamento 401k / finance) e usam-no somente por 10 a 30 minutos de cada vez. As operações são distribuídas uniformemente entre leituras / gravações.
Metade da nossa equipe acha que, como resultado, deveríamos distribuir os bancos de dados por vários servidores baratos e usar o SQL Express ... eles dizem que a memória / armazenamento em cache não seria tão útil, dado o curto período de tempo de cada banco de dados. usado (não temos orçamento para o padrão SQL completo em mais de um servidor).
É este o caso? Um limite de memória maior é realmente a única vantagem que vejo o MSSQL Standard nos trazendo (já temos scripts para fazer backups / restaurações, upgrades de esquema, migração de dados, etc).
Atualizar
Estou particularmente interessado em características de desempenho de vários bancos de dados em comparação a um banco de dados. A experiência do usuário final não estaria atingindo melhor um único banco de dados de 200 MB do que um banco de dados de 1 TB (mesmo se ambos estivessem bem indexados)? Isso também significa que podemos facilmente fazer backup / restaurar bancos de dados de cliente único muito rapidamente, certo? Será que precisamos ajustar o SQL Server para lidar melhor com o cenário 'milhares de bancos de dados'?
Eu jogaria tudo em um servidor. Manter os vários servidores SQL Express baratos será uma dor. Você pode espalhar bancos de dados, logs e o banco de dados temporário em diferentes arrays de disco RAID. Você deve considerar mover seu banco de dados temporário para sua própria matriz, pois ele pode estar em uso por todos os bancos de dados de uma só vez.
Confira o gerenciador de recursos de 2008 para garantir que nenhum usuário traga o servidor para um rastreamento. É apenas na versão corporativa.
Se você oferecer hospedagem para acesso de cliente com vários inquilinos, também terá a opção de licenciamento por volume como Provedor de serviços , que pode ser significativamente mais barato do que comprar uma licença padrão por CPU, e o custo pode ser efetivamente repassado para o preço mensal do serviço.
A implantação de várias instâncias do SQL Express para hospedagem é, na verdade, contra as recomendações .
Embora esteja um pouco desatualizado com relação ao SQL 2008 e R2, recomendo a leitura do white paper SQL Server 2005 Orientação de Implantação para Ambientes de Hospedagem na Web , a orientação se aplica a outros ambientes de hospedagem e multilocação, não apenas para hospedagem na Web.
Jess,
Sem saber mais sobre seu ambiente ou padrões de uso, direi que você pode ver um melhor desempenho com cada cliente tendo seu próprio banco de dados (portanto, milhares de bancos de dados menores versus um grande banco de dados). Você poderia reduzir potencialmente as chances de bloqueio de tabela e linha, já que os clientes só atingirão seu próprio conjunto exclusivo de tabelas, em vez de compartilhar um conjunto de tabelas. A E / S de disco ainda seria um fator limitante.
Além disso, a segurança seria mais clara, pois cada banco de dados teria seu próprio conjunto exclusivo de permissões para cada cliente. Como você afirmou, os backups e restaurações seriam muito mais rápidos com os bancos de dados menores, mas a configuração e a manutenção dessas tarefas de backup seriam extremamente complexas (mas parece que você já considerou isso).
Se você tiver o hardware, eu recomendo configurar arrays RAID diferentes para seus dados, logs e TempDB (como Sam sugeriu). Se você estiver usando algum tipo de armazenamento de conexão direta ou SAN e puder arrays extras, pode até considerar dividir os arquivos reais dos bancos de dados em matrizes diferentes.
HTH, Dan
Seu maior desafio provavelmente envolverá backups; Se você for SQL Express, você não tem nenhum agente para executá-los, você precisará confiar em tarefas agendadas do Windows e alguns scripts sofisticados.
Se você usar o SQL Std / Ent Edition e tentar usar os planos de manutenção internos para fazer backup de todos os bancos de dados, eles serão feitos um de cada vez e poderão demorar um pouco. O mesmo para backups de log.
Nem pense em usar o espelhamento com muitos bancos de dados em um servidor.
Eu me inclinaria para mais servidores, com uma estratégia de failover bem pensada.
Outra consideração que você deve ter em mente são os custos periféricos de manter milhares de bancos de dados SQL distribuídos em "vários servidores baratos". Com o aumento do número de servidores, seus requisitos de espaço em rack aumentam, assim como seus custos para alimentar e resfriar seu data center com todo o hardware adicional. Sem mencionar o aumento nos custos administrativos / tempo em ter que manter vários servidores versus um servidor.
Uma coisa a considerar aqui é adicionar vários arquivos ao tempdb e a arquivos db espalhados em vários discos. O SQL pode, então, espalhar ler & escreva nos fusos ... consulte link
Por favor, não tome isso errado. Você pode ter boas razões para fazer o que está fazendo. De onde estou, não vejo por que alguém gostaria de ter vários milhares de bancos de dados. Parece-me que há uma falha de design na sua aplicação e agora você está procurando maneiras de superá-lo sem consertá-lo. Eu recomendaria seriamente reconsiderar o design fundamental do banco de dados.
Dito isto: Se houver boas razões (possivelmente legais) para ter tantos bancos de dados, considere isto: Um MS SQL Server decente pode facilmente lidar com várias centenas de pequenos bancos de dados (500 x 400MB = 200GB de dados, o que não é um problema). Isso deve gerar renda mais do que suficiente para não precisar se preocupar com licenças adicionais do SQL Server. Você pode dividi-los simplesmente nomeando ou qualquer outro método que escolher.Ou, você pode considerar o uso do MySQL, onde o licenciamento não é um problema (embora eu saiba que isso não é uma opção se você usar muito os procedimentos armazenados).