Estou trabalhando com um colega que propôs dividir nosso banco de dados de 1 instância em cerca de 7 bancos de dados (divididos por domínio de dados) para desenvolvimento e 7 bancos de dados idênticos para produção. Eu recebo a lógica de dualidade de produção de teste, mas em que caso ou quais são as vantagens de dividir nosso 1 banco de dados relativamente simples em 7 bancos de dados? Nosso data warehouse é consumido/usado apenas por UMA aplicação de inteligência de negócios, ponto final.
Estou preocupado com essa direção, então espero que você possa discutir as razões gerais propostas para essa divisão, e eu posso lhe dar um resumo das propriedades atuais do banco de dados.
1 banco de dados Data Warehouse: total de 352 GB, 203 tabelas, 170 visualizações
Divisão proposta:
A: 280 GB
B: 43 GB
C: 28 GB
D: 1 GB
E,F,G: < 1 GB combined
Como você pode ver, isso já é um problema em termos de benefícios propostos, pois o armazenamento não será nem remotamente dividido uniformemente, com 80% restantes em 1 banco de dados. Aparentemente, particionar nosso banco de dados por esquema não é possível (de uma perspectiva de hardware) porque não temos o SQL Server de nível empresarial.
Motivos apresentados para a divisão:
- O banco de dados atual é pouco otimizado, pouca documentação, tipos de dados sub-ótimos, índices sub-ótimos.
Meus pensamentos de novato: esses problemas não são irrelevantes para dividir o banco de dados? Eles são simplesmente problemas que precisam ser resolvidos por conta própria de qualquer maneira.
- Existem 372 objetos no banco de dados atual, o que o torna lento.
Meus pensamentos: Isso dificilmente parece grande na minha opinião.
- Um banco de dados é mais difícil de documentar e desenhar diagramas de esquema para mais de 7 bancos de dados (teremos visualizações que abrangerão vários bancos de dados).
Meus pensamentos: .... Isso me parece completamente ridículo, mas talvez eu esteja errado. Já organizamos nosso data warehouse por 13 esquemas de 'sistema de origem'.
- Um banco de dados levará a mais deadlocks de banco de dados.
-- Este problema também não é completamente irrelevante para ter vários bancos de dados? É meu entendimento que os deadlocks ocorrem no nível da tabela (na verdade, geralmente até mesmo no nível da linha, mas eh). Mesmo assim, todas as nossas inserções de dados acontecem à meia-noite, todos os nossos selects downstream para o BI acontecem às 2 da manhã. Ter dois processos atualizando a mesma tabela é irrelevante para vários bancos de dados, não é (o impasse aconteceria de qualquer maneira)? Além disso, pessoalmente, não vi nenhuma evidência de deadlocks de tabela ocorrendo durante operações normais.
- Propriedade técnica/propriedade do banco de dados.
Somos apenas nós dois que trabalhamos no banco de dados. É possível que ele queira realmente segregar nossos 'feudos'. Realmente, não foi um problema, mas as permissões do usuário não podem ser determinadas no nível do esquema de qualquer maneira?
Quais são os motivos válidos para dividir um Data Warehouse em vários bancos de dados?
Adoraria aprofundar meu conhecimento aqui sobre bancos de dados em geral. Sim, acontece que estou fazendo muito trabalho em um com lacunas no meu conhecimento, mas bem, o trabalho é o que é, o que fui empurrado. As coisas têm funcionado muito bem até agora (bater na madeira).
Com certeza você está no caminho certo! 320 GB não é muito grande para um banco de dados, principalmente um DW.
Isso é um golpe no dinheiro. Dividir um grande banco de dados mal organizado, otimizado e documentado em 7 bancos de dados mal organizados, otimizados e documentados é uma perda de tempo! Você precisa atacar a raiz do problema!
Novamente, você está correto! 372 é positivamente pequeno em termos de número de objetos - muitos servidores grandes têm dezenas de milhares. Daqui _
Seu 370 dividido por ~ 2E9 ~= 1.7E-7 - então não se preocupe com essa pontuação! :-)
Novamente, você está correto. Se houver 372 entidades com inter-relações entre elas, você precisará documentá-las e diagrama-las. Vai ter um grau inerente de complexidade. O que você pode fazer é tentar dividir seu sistema geral em subsistemas e documentá-los e então tentar encaixá-los no quadro maior - grandes carvalhos de pequenas bolotas crescem!
O que você perderá no cenário de banco de dados múltiplo são transações ACID dentro do mesmo esquema - OK, você pode ter confirmação de 2 fases, mas não é tão robusto quanto as transações dentro do mesmo esquema (IMHO). Não tenho certeza de um motivo válido para separar as tabelas se elas forem necessárias para seus requisitos.
Você parece estar falando sobre leituras de bloqueio de gravação? Bem, você também parece ter um processo em lote à meia-noite seguido por um processo de consulta às 02:00? Se você puder fazer transações/tabelas somente leitura, isso aliviará um pouco a carga do mecanismo do servidor enquanto ele processa seus dados. Só você pode dizer se isso pode ser aplicado ao seu cenário!
Certamente, a propriedade está no nível da tabela e o acesso pode, dependendo do seu servidor/versão, ser concedido em uma coluna e/ou linha - então o negócio de propriedade é uma pista falsa! Se você for um DBA de servidor realizando uma reorganização (em vez de simplesmente agendar backups e outras tarefas mundanas), precisará "acessar todas as áreas"!
Você deve ter um comentário em cada tabela e campo em seu sistema - você pode colocar "propriedade" (no sentido organizacional em oposição ao banco de dados das coisas) lá - comentar tabelas e campos é um excelente primeiro passo para documentar um sistema - é torna-se auto-documentado!
Pode haver muitas razões - algumas estão associadas a multilocação (tanto em termos de recursos da máquina (CPU, RAM, HDD e rede) quanto de confidencialidade ou requisitos do cliente. Dê uma olhada aqui e também google "multilocação de banco de dados" ou similar .
Todo mundo fala, mas é uma luta - "documentação é muito importante"! Como primeiro passo, documente suas tabelas e campos nos comentários. Produza diagramas ERD para todos os seus subsistemas. Não deixe nada novo entrar no sistema sem que essas etapas sejam implementadas. Boa sorte em sua nova função!
Embora pareça uma tática clássica de espantalho sendo usada por seu colega, ele ou ela poderia estar se referindo à criação de data marts formais ao dizer "dividir o data warehouse"?
As duas principais abordagens de Data Warehousing são atribuídas a Ralph Kimball e Bill Inmon . Aqui estão algumas visões gerais de alto nível ( [1] , [2] ) sobre a diferença entre essas duas abordagens comuns se você tiver alguns minutos para queimar.
O que acredito pode ser aplicável à sua situação é que a abordagem de Bill Inmon exige a criação formal de Data Marts dos quais as ferramentas de relatório extraem dados. Esses Data Marts são projetados para serem acessados exclusivamente por departamentos ou unidades de negócios específicos, e acho que isso pode ser o que seu colega está tentando alcançar. A natureza idêntica das cópias é estranha, mas pode ser mais fácil criar uma cópia do data warehouse em sua forma atual e depois carregar apenas os dados de um departamento específico nessa cópia daqui para frente?
Pelo que você forneceu, parece que seu data warehouse atual está usando a abordagem de Kimball, onde os Data Marts são um subconjunto lógico de dados dentro do data warehouse dimensional que sua ferramenta de relatório acessa diretamente. Essas duas abordagens de design têm seus prós e contras, e esperamos que o cerne do problema do seu colega seja que ele esteja mais confortável com a abordagem de Inmon.
Espero que isso seja apenas um mal-entendido de termos e uma discussão aprofundada dessas duas abordagens diferentes com seu colega leve a alguns esclarecimentos sobre os obstáculos que ele ou ela está tentando superar.