Criamos sites para empresas Realty. Os sites são usados apenas para exibir as informações e todos os sites compartilham um modelo comum. Temos cerca de 150 sites para diferentes clientes. Alguns provedores de dados de terceiros nos fornecem todas as atualizações sobre cada listagem no site de hora em hora. As atualizações para cada cliente acontecem em horários separados. Em média, temos 1000 listagens por site. E a cada atualização horária, 80% dos dados são alterados ou atualizados.
Neste momento, temos um único banco de dados no Sql Server 2008, para todos os clientes (projetado inicialmente para atender 10-20 sites). As tabelas no banco de dados são compartilhadas por todos. O problema é que sempre que uma atualização acontece, ela retarda outros sites de clientes também, que não estão relacionados à atualização. Também excluir os dados de um cliente, atrasa todos os sites.
Estou planejando remodelar o banco de dados criando um esquema separado para cada cliente, mas não tenho certeza se é a melhor maneira de lidar com o problema. Ter um banco de dados separado cria muitos problemas para manutenção (backups, espelhamento, etc.). Alguém pode me sugerir uma maneira melhor de lidar com esse problema. Não tenho certeza de como isso afeta o desempenho, se eu criar um esquema separado para cada cliente e isolar suas tabelas de outros. Ou existe alguma solução melhor?
A minha preferência pessoal seria para vários bancos de dados, pois permite ver quais bancos de dados usam o maior número de entradas e saídas, com uma variedade de DMVs - e permite que você migre facilmente os maiores bancos de dados para outros lugares. Além disso, há uma separação de segurança que é sempre reconfortante para os clientes.
Brent Ozar abordou esta questão em um post recente - definitivamente vale a pena ler como ele é muito bom: link
Embora eu provavelmente recomendaria ir a um banco de dados por cliente, se você quiser se ater a um banco de dados, parece que os esquemas serão adequados, de acordo com suas necessidades.
No entanto, além de um esquema por cliente, recomendo que você também crie um grupo de arquivos por cliente e, em seguida, coloque todos os objetos de banco de dados para cada cliente nesse grupo de arquivos. Existem várias vantagens para isso:
Acredito que o número máximo de grupos de arquivos que você pode ter é 32.000-ish, portanto, essa estratégia deve durar até que você realmente precise pensar em dividir em bancos de dados diferentes.
Para obter mais informações, eu recomendo o artigo on-line sobre livros ' Arquitetura de arquivos e grupos de arquivos ' e White paper do SQLCAT sobre disponibilidade parcial do banco de dados: link
Se todos os clientes compartilham o mesmo banco de dados, e todos os sites usam o mesmo modelo, isso é mais como um multi-inquilino cms e, como tal, ter um único banco de dados faz sentido aqui.
Eu não consideraria o problema como uma atualização de clientes afetando todas as outras, mas sim um nível mais baixo de atualizações e consultas simplesmente lentas em geral. Supondo que o hardware e a carga não mudem, 150 bancos de dados provavelmente funcionarão de maneira semelhante à solução de banco de dados único (possivelmente mais lenta sob certas circunstâncias)
Eu assumo que sua tabela principal é a tabela "listagens" que tem aproximadamente 150 * 1000 linhas vivas (presumivelmente + registros históricos).
Esta não é uma quantidade enorme de dados por um longo tiro, e uma máquina razoavelmente determinada não deve ter nenhum problema.
Eu estaria procurando garantir que registros históricos sejam movidos para suas próprias tabelas. Na consulta de leitura, eu adicionaria 'read uncommitted snapshot'
Nas atualizações, há algumas correções possíveis para isso 1. Use uma mesclagem em vez de várias instruções de atualização 2. Use um cursor para evitar a restrição de bloqueio 3. Adicione novos registros para as listagens atualizadas e apenas atualize um sinalizador de bit 'atual' nos antigos
Considerando que isso foi há dois anos, qual foi a solução final?
Parece que você está mais preocupado em manter tudo em um banco de dados, seja qual for o custo (embora você tenha mencionado isso), já que o ponto principal de Peter em bancos de dados separados estava relacionado ao desempenho e poder escalonar a longo prazo. corre. Se esse for o caso, convém ou dividir as tabelas em esquemas diferentes para clientes OU alternar para uma licença do Enterprise Edition para que você possa usar o particionamento de tabelas e particionar as tabelas compartilhadas com base no número do cliente.
Eu me fiz a mesma pergunta quando planejei reestruturar minha infra-estrutura de banco de dados. Este artigo me ajudou muito.
[ link