Quand créer une base de données de rapports distincte?

Typiquement, j'essaierais de signaler la base de données transactionnelle initialement.

Assurez-vous que tous les index que vous ajoutez pour faciliter les rapports efficaces sont fréquemment utilisés. Plus vous ajoutez d'index, plus les performances seront faibles sur les insertions et (si vous modifiez les clés) les mises à jour.

Lorsque vous accédez à une base de données de rapports, n'oubliez pas qu'il n'y a que quelques raisons pour lesquelles vous y allez:

En fin de compte, la première chose à propos des bases de données de rapports est que vous supprimez verrouillage de la contention à partir de la base de données OLTP. Donc, si votre base de données de rapports est une copie directe de la même base de données, vous utilisez simplement des instantanés retardés qui n'interféreront pas avec les transactions de production.

Ensuite, vous pouvez disposer d'une stratégie d'indexation distincte pour prendre en charge les scénarios d'utilisation des rapports. Ces index supplémentaires peuvent être conservés dans la base de données de rapports, mais cela entraînerait une surcharge inutile dans la base de données OLTP.

Maintenant, ce qui précède peut être fait sur le même serveur (même la même instance dans une base de données séparée ou même juste dans un schéma séparé) et voir encore des avantages. Lorsque le processeur et les E / S sont complètement ancrés, à ce stade, vous devez absolument l'avoir sur une boîte complètement séparée (ou mettre à niveau votre boîte unique).

Enfin, pour une flexibilité de reporting Ultime, vous dénormalisez les données (généralement dans un modèle dimensionnel ou des schémas en étoile) de sorte que la base de données de reporting soit les mêmes données dans un modèle différent. Déclaration de grandes quantités de données (en particulier les agrégats) est extrêmement rapide dans les modèles dimensionnels parce que les schémas d'étoiles sont très efficaces pour cela. Il est également efficace pour une plus grande variété de requêtes sans beaucoup de réindexation ou d'analyse pour changer les index, car le modèle dimensionnel se prête mieux aux modèles d'utilisation imprévus (l'ancienne demande "slice and dice every way"). Vous pouvez voir ceci est une sorte de mini-entrepôt de données où vous utilisez des techniques d'entreposage de données, mais n'implémentez pas nécessairement un véritable entrepôt de données. En outre, les schémas en étoile sont particulièrement faciles à comprendre pour les utilisateurs, et les dictionnaires de données sont beaucoup plus simples et plus faciles à construire pour les outils de BI ou les outils de reporting à partir de schémas en étoile. Vous pouvez le faire sur la même boîte ou une boîte différente, tout comme discuté plus tôt.

@pôle nord:

Espérons que vous avez trouvé votre réponse après près de 2 ans. Cette question exige de l'expérience plutôt que de la science.

En tant qu'architecte BI, l'approche que j'adopte pour concevoir chaque solution BI pour mes clients est très différente. Je ne passe pas par une liste de contrôle. Il exige une compréhension générale de leur système, de leurs exigences en matière de rapports, de leur budget et de leur pouvoir de gestion.

Personnellement, je préfère garder les processus de reporting autant que possible sur la base de données côté (meilleure pratique dans le monde BI). LES OUTILS DE REPORTING SONT UNIQUEMENT DESTINÉS À L'AFFICHAGE (MAXIMUM POUR LES PETITS CALCULS). Cette approche nécessite beaucoup de prétraitement des données, ce qui nécessite différentes tables intermédiaires, déclencheurs, etc.

Quand vous avez dit:

Je travaille sur des projets avec des centaines de millions de lignes avec des rapports en temps réel ainsi que des centaines d'utilisateurs accédant à l'application/base de données en même temps sans problème.

Il y a quelques choses qui ne vont pas avec votre déclaration.

1. Des Centaines de millions de lignes sont BEAUCOUP. même les outils en mémoire d'aujourd'hui comme Cognos TM1 ou Qlikview auraient du mal à obtenir de tels résultats. (regardez SAP HANA de SAP pour comprendre comment les géants de L'industrie le gèrent).

2. Si vous avez des centaines de millions de lignes dans la base de données, cela ne signifie pas nécessairement que le rapport doit parcourir tous ces enregistrements. peut-être que le rapport a travaillé sur 1000s pas des millions. probablement c'est ce que vous scie.

3. Les rapports transactionnels sont très différents des tableaux de bord. La plupart des outils de tableau de bord pré-traitement et cache Les données.

Je sais que je réponds 2 ans plus tard et mes pensées ne sont pas bien organisées, mais mon point est que tout vient à l'expérience pour décider quand: 1. concevoir un nouveau schéma 2. créer une base de données sémantique 3. travailler sur la même base de données transactionnelle 4. ou même utiliser un outil de reporting (parfois des tableaux de bord manuscrits avec Java / JSF / Ajax / jQuery ou JSP fonctionnerait bien pour le client)

La principale raison pour laquelle vous auriez besoin d'une base de données séparée pour les problèmes de reporting est lorsque la génération des rapports interfère avec les responsabilités transactionnelles de l'application. Par exemple, si un rapport prend 20 minutes pour générer et utilise 100% du CPU / disque / etc... pendant une période de forte activité, vous pourriez penser à utiliser une base de données distincte pour les rapports.

En ce qui concerne les questions, en voici une de base:

1. Puis-je faire les rapports de haute intensité pendant non-pic heures d'ouverture?
2. cela interfère-t-il avec les utilisateurs utilisant le système?
3. Si oui à #2, Quels sont les coûts de l'interférence par rapport au coût d'un autre serveur de base de données, du code de refactoring, etc...?

Fondamentalement, lorsque la charge de base de données de l'application devient incompatible avec la charge de base de données pour les rapports. Cela pourrait être dû à:

• Rapports consommant une quantité excessive de ressources du serveur de base de données ayant un impact sur les performances de base de données de l'application.

  Une partie de cette catégorie serait le travail de base de données de l'application qui doit attendre une requête de rapport principalement lente en raison du verrouillage, bien qu'il puisse être possible de résoudre avec des méthodes moins drastiques comme le verrouillage tuning.

• Les requêtes de Reporting étant très incompatibles avec les requêtes d'application en ce qui concerne le réglage (par exemple, les indices mais sans s'y limiter)-l'exemple le plus stupide serait quelque chose comme un point chaud affectant les insertions d'applications en raison de l'index de reporting-purpose.

• Questions de calendrier. Par exemple, les seules petites fenêtres pour la maintenance DB disponibles (en raison de l'utilisation de l'application) sont les temps de travail de reporting lourd

• Rapport du volume des données (par exemple, journalisation, audit, statistiques) est si grand que votre architecture de serveur DB primaire est une mauvaise solution pour de tels rapports (Voir Sybase ASE vs Sybase IQ). BTW, c'est un vrai scénario - nous avons déplacé notre rapport de performance à IQ à cause de cela.

J'ajouterais également que les bases de données transactionnelles sont censées conserver l'état actuel et le font souvent pour être auto-entretenues. Vous ne voulez pas que les bases de données transactionnelles dépassent leurs moyens nécessaires. Lorsqu'un workflow ou une transaction est terminé, déplacez ces données dans une base de données de rapports, qui est beaucoup mieux conçue pour contenir des données historiques.

J'ajouterais également une autre raison pour laquelle vous pourriez utiliser une base de données de rapports, et c'est: Modèle CQRS (séparation des responsabilités de requête de commande).

Si vous avez un grand nombre d'utilisateurs accédant et écrivant à un petit ensemble de données, vous feriez bien de considérer ce modèle. Cela signifie fondamentalement, dans sa forme la plus simple, que toutes vos commandes (Create, Update, Delete) sont poussées vers la base de données transactionnelle. Toutes vos requêtes (lues) proviennent de votre base de données de rapports. Cela vous permet d' librement scopy votre architecture et mise à niveau fonction.

Il y a beaucoup plus dans le modèle, je viens de mentionner le bit qui était intéressant en raison de votre question concernant la base de données de rapports.