Início / dba / Perguntas / 101700
Accepted
AMH
Asked: 2015-05-17 09:25:14 +0800 CST

Práticas recomendadas de balanceamento de carga e tráfego

  • 772

Estou prestes a projetar uma solução corporativa para um aplicativo de grande escala no qual um serviço do Windows, MVC e muitos outros projetos usarão um banco de dados, então estou pensando em balanceamento de carga e melhores práticas para organizar meu banco de dados.

Eu tenho duas opções:

  • use esquemas diferentes (eu sei que o esquema é muito parecido com uma pasta)
  • usar bancos de dados diferentes

Do ponto de vista do design do banco de dados, qual é o melhor e qual é a melhor prática?

database-design sql-server-2012

1 respostas

  1. Best Answer

    Se os bancos de dados residirem no mesmo servidor, então, de uma perspectiva direta de desempenho, usar um único banco de dados dividido por esquema versus vários bancos de dados separados não será diferente. Não há "custo" para chamar o banco de dados A versus o banco de dados B (a menos que ambos estejam configurados para fechamento automático, um "recurso" que você deve evitar como uma praga).

    Eu normalmente defendo bancos de dados separados, por vários motivos:

    • Você parece estar separando coisas que são funcionalmente diferentes - não há vantagem real em conter dados para aplicativos separados logicamente no mesmo banco de dados, independentemente de você usar separação de esquema ou não - a menos que eles realmente compartilhem a mesma cópia dos dados.
    • Mais fácil dividir um banco de dados em um servidor separado se ele escalar mais rapidamente ou superar o servidor em que está. Mesmo com esquemas separados, será tedioso mover apenas os dados de um aplicativo desse banco de dados; se eles iniciarem em seu próprio banco de dados, é tão simples quanto fazer backup, restaurar no outro servidor e alterar a string de conexão para esse aplicativo. Se você tem um banco de dados e supera o tamanho do servidor, precisa mover tudo. E então novamente na próxima vez.
    • Mais fácil de gerenciar a recuperação separadamente - você pode querer usar recuperação completa e backups de log frequentes para seu controle de origem, mas não precisa de tanto rigor para o banco de dados que contém os personagens favoritos dos funcionários do Power Ranger. Você também pode evitar ter que restaurar todos os aplicativos para o mesmo ponto no tempo se tiver que reverter um dos bancos de dados por algum motivo.
    • Parece mais trabalhoso gerenciar isso, mas, na verdade, você pode fazer com que gerenciar 2 bancos de dados não seja realmente diferente de gerenciar 2.000 bancos de dados.

    Em uma vida anterior gerenciei um sistema com muitos bancos de dados; eles eram um por cliente com (em grande parte) tabelas/visualizações/procedimentos idênticos. Respondi a várias perguntas aqui com base em minha experiência e conhecimento por meio dessa arquitetura (incluindo algumas desvantagens a serem observadas na primeira resposta):

    Ainda não ouvi ninguém argumentar com sucesso sobre o armazenamento de dados diferentes (aplicativos diferentes, clientes diferentes, etc.) no mesmo banco de dados. Acho que qualquer pessoa que optar por fazer isso está confiante de que seus dados nunca ultrapassarão esse servidor ou está se concentrando no objetivo de curto prazo de simplicidade e esforço mínimo (que pode ser bastante míope e mordê-lo a longo prazo) .

    • 2

relate perguntas