Quando criar uma base de dados de relatórios separada?

Normalmente, eu tentaria informar-me da base de dados de transacções inicialmente.

Certifique-se de que todos os índices que adicionar para facilitar relatórios eficientes são frequentemente utilizados. Quanto mais índices você adicionar, o pior desempenho será em inserções e (se você alterar chaves) atualizações.

Quando for a uma base de dados de relatórios, lembre-se que existem apenas algumas razões para lá ir: Em última análise, a primeira coisa sobre relatórios de bases de dados é que você é a remover a contenção de bloqueio da base de dados OLTP. Então, se o seu banco de dados de relatórios é uma cópia direta do mesmo banco de dados, você está simplesmente usando instantâneos retardados que não interferem com as transações de produção.

A seguir, poderá ter uma estratégia de indexação separada para suportar os cenários de Utilização dos relatórios. Estes índices extras são OK para manter no banco de dados de relatórios, mas causaria sobrecarga desnecessária no banco de dados OLTP.

Agora ambas as coisas podem ser feitas no mesmo servidor (mesmo a mesma instância em um banco de dados separado ou mesmo apenas em um esquema separado) e ainda ver benefícios. Quando o CPU e o IO estão completamente indexados, nesse ponto, você definitivamente precisa tê-lo em uma caixa completamente separada (ou atualizar a sua caixa única).

Finalmente, para a derradeira flexibilidade de relatórios, você desnormaliza os dados (geralmente em um modelo dimensional ou esquemas de Estrelas) de modo que a base de dados de relatórios é os mesmos dados em um modelo diferente. Comunicação de grandes quantidades de dados (particularmente agregados) é extremamente rápido em modelos dimensionais porque os esquemas das estrelas são muito eficientes para isso. Ele também é eficiente para uma grande variedade de consultas sem um monte de re-indexação ou análise para mudar os índices, porque o modelo dimensional se presta melhor a padrões de uso imprevistos (o antigo "slice and dice every which way" pedido). Você pode ver que este é um tipo de mini-data warehouse onde você usa técnicas de armazenamento de dados, mas não estão necessariamente implementando um armazém de dados completo. Além disso, os esquemas de estrelas são particularmente fáceis de lidar com os usuários, e os dicionários de dados são muito mais simples e fáceis de construir para ferramentas BI ou ferramentas de relatórios de esquemas de estrelas. Você poderia fazer isso na mesma caixa ou caixa diferente etc, assim como discutido anteriormente.

@northpole:

Espero que tenhas encontrado a tua resposta depois de quase 2 anos. Esta questão requer experiência e não Ciência.

Como arquitecto BI, a abordagem que tenho em conceber cada solução BI para os meus clientes é muito diferente. Não passo por uma lista de verificação. Exige uma compreensão geral do seu sistema, dos seus requisitos de comunicação, do orçamento e do poder humano. Pessoalmente, prefiro manter os processos de comunicação o mais possível na banco de dados (Best practice in BI world). AS FERRAMENTAS DE RELATÓRIOS SÃO APENAS PARA MOSTRAR A FINALIDADE (MÁXIMO PARA PEQUENOS CÁLCULOS). Esta abordagem exige um grande número de pré-processamento de dados, o que exige diferentes tabelas de paragem, gatilhos e etc. Quando disseste:

Eu trabalho em projetos com centenas de milhões de linhas com relatórios em tempo real, juntamente com centenas de usuários acessando a aplicação/base de dados ao mesmo tempo sem problemas.

Há alguns as coisas estão erradas com o seu depoimento.

1. Centenas de milhões de filas são demais. mesmo hoje em ferramentas de memória Como Cognos TM1 ou Qlikview iria lutar para obter tais resultados. (veja SAP HANA da SAP para entender como os gigantes da indústria lidam com isso).

2. Se você tem centenas de milhões de linhas na base de dados, isso não significa necessariamente que o relatório precisa ver todos esses registros. talvez o relatório tenha funcionado em 1000s, não em milhões. provavelmente é ... o que viste.

3. Os relatórios de transacções são muito diferentes dos painéis. A maioria das ferramentas do painel de instrumentos pré-processamento e cache os dados.

Eu sei que estou respondendo 2 anos depois e meus pensamentos não estão bem organizados, mas meu ponto é que tudo vem à experiência para decidir quando: 1. desenhar um novo esquema 2. criar uma base de dados semântica 3. trabalhar na mesma base de dados de transacções 4. ou mesmo usar uma ferramenta de relatórios (por vezes, painéis manuscritos com Java/JSF/Ajax / jQuery ou JSP funcionaria bem para o cliente)

A principal razão pela qual precisaria de uma base de dados separada para a apresentação de relatórios é quando a geração dos relatórios interfere com as responsabilidades transaccionais da aplicação. Por exemplo, se um relatório levar 20 minutos para gerar e utilizar 100% da CPU/disco/etc... durante um período de alta atividade você pode pensar em usar um banco de dados separado para relatar. Quanto às perguntas, aqui estão algumas básicas:

1. posso fazer os relatórios de alta intensidade durante o não-Pico? horas?
Isso interfere com os utilizadores que usam o sistema?
2. Em caso afirmativo ao número 2, quais são os custos da interferência versus o custo de outro servidor de base de dados, código de refactoração, etc...?

Basicamente, quando a carga da base de dados da aplicação se torna incompatível com a carga da base de dados para comunicação. Isto pode ser devido a:

• Informar consumir uma quantidade excessiva de recursos do servidor de bases de dados com impacto no desempenho do DB da aplicação.

  Uma parte desta categoria seria o trabalho da App DB tendo que esperar por uma consulta de relatórios muito lenta devido ao bloqueio, embora pudesse ser possível resolver com métodos menos drásticos como o bloqueio ajuste.

• Consultas de Relatórios de ser muito incompatível com o app consultas na medida de ajuste (por exemplo, índices, mas não limitado a isso) - o mais idiota exemplo seria algo como um "hot spot" que afetam aplicativo insere devido a notificação-objetivo do índice.

• Problemas de tempo. Por exemplo, as únicas janelas pequenas para manutenção DB disponíveis (devido ao uso de aplicações) são os tempos de trabalho pesado de relatórios

• Volume absoluto dos dados comunicados (por exemplo, registo, auditoria) , estatísticas) é tão grande que sua arquitetura de servidor DB primária é uma má solução para tal relato (veja Sybase ASE vs. Sybase IQ). BTW, este é um cenário real-movemos nosso desempenho relatando para o QI por causa disso.

Além disso, acrescentaria que as bases de dados transacionais são destinadas a manter o estado actual e, muitas vezes, a manter-se a si próprias. Não queres que as bases de dados transacionais cresçam para além dos meios necessários. Quando um fluxo de trabalho ou transação está completo, em seguida, mover esses dados para fora e para um banco de dados de relatórios, que é muito melhor projetado para manter dados históricos.

Eu também adicionaria outra razão pela qual você poderia usar uma base de dados de relatórios, que é: padrão CQRS (separação de responsabilidade de Consulta de comando).

Se você tem um grande número de usuários acessando e escrevendo para um pequeno conjunto de dados, você faria bem em considerar este padrão. Basicamente, em sua forma mais simples, significa que todos os seus comandos (criar, Atualizar, Excluir) são empurrados para o banco de dados transacional. Todas as suas consultas (leia) são da sua base de dados de relatórios. Isto permite você copia livremente sua arquitetura e função de atualização.

Há muito mais sobre ele no padrão, Eu apenas mencionei o bit que era interessante devido à sua pergunta sobre a base de dados de relatórios.