Quand créer une base de données de rapport distincte?
Nous construisons une application qui a une base de données (ouais, plutôt excitant hein :). La base de données est principalement transactionnelle (pour prendre en charge l'application) et effectue également un peu de "reporting" dans le cadre de l'application, mais rien de trop pénible.
Au-delà de cela, nous avons des exigences en matière de rapport - mais elles sont assez vagues et de haut niveau pour le moment. Nous utilisons un outil de reporting standard que nous utilisons en interne et que nous utiliserons pour le reporting "plus lourd" à mesure que les exigences se solidifient.
Ma question est la suivante: comment savoir quand une base de données distincte est requise pour les rapports?
Quel genre de questions faut-il poser? Quel genre de choses vous inciterait à décider qu'une base de données de rapport distincte était nécessaire?
En général, plus l'application transactionnelle est essentielle à la mission et plus les exigences en matière de rapports sont sophistiquées, plus le fractionnement est logique.
- Lorsque les performances des transactions sont critiques.
- Lorsqu'il est difficile d'obtenir une fenêtre de maintenance sur l'application transactionnelle.
- Si les rapports doivent corréler les résultats non seulement de cette application, mais également d'autres silos d'application.
- Si les rapports doivent prendre en charge les tendances ou d'autres types de rapports mieux adaptés à un environnement de schéma en étoile/Business Intelligence.
- Si les rapports sont longs.
- Si l'application transactionnelle se trouve sur une ressource matérielle coûteuse (cluster, ordinateur central, etc.)
- Si vous devez effectuer des opérations de nettoyage/d'extraction, de transformation et de chargement des données sur les données transactionnelles (par exemple, les noms d'état en abréviations d'état canoniques).
Cela ajoute une complexité non triviale, alors, imo, il doit y avoir une bonne raison de se séparer.
En règle générale, j'essayerais de créer un premier rapport sur la base de données transactionnelle.
Assurez-vous que tous les index que vous ajoutez pour faciliter la création de rapports efficaces sont tous fréquemment utilisés. Plus vous ajoutez d’index, moins les performances seront bonnes sur les insertions et les mises à jour (si vous modifiez des clés).
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 les conflits de verrouillage de la base de données OLTP. Ainsi, 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 différés qui n'interféreront pas avec les transactions de production.
Ensuite, vous pouvez avoir une stratégie d'indexation distincte pour prendre en charge les scénarios d'utilisation des rapports. Ces index supplémentaires sont corrects à conserver dans la base de données de rapports, mais entraîneraient une surcharge inutile dans la base de données OLTP.
Désormais, les deux opérations ci-dessus peuvent être effectuées sur le même serveur (même la même instance dans une base de données séparée ou même simplement dans un schéma séparé) tout en conservant les avantages. Lorsque CPU et IO sont complètement rattachés, vous devez absolument les disposer 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 constituée des mêmes données dans un modèle différent. La communication de grandes quantités de données (en particulier les agrégats) est extrêmement rapide dans les modèles dimensionnels, car les schémas en étoile 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, car le modèle dimensionnel se prête mieux à des modèles d’utilisation imprévus (l’ancienne requête "slice and dice"). Vous pouvez voir qu'il s'agit d'une sorte de mini entrepôt de données dans lequel vous utilisez des techniques d'entreposage de données, sans pour autant implémenter un entrepôt de données complet. De plus, les schémas en étoile sont particulièrement faciles à comprendre pour les utilisateurs, et les dictionnaires de données sont beaucoup plus simples et faciles à créer pour les outils de BI ou les outils de génération de rapports à partir des schémas en étoile. Vous pouvez le faire sur la même boîte ou sur une boîte différente, comme indiqué précédemment.
@pôle Nord:
J'espère que vous avez trouvé votre réponse après presque 2 ans. Cette question nécessite de l'expérience plutôt que de la science.
En tant qu'architecte de la BI, l'approche que j'adopte pour concevoir chaque solution de BI pour mes clients est très différente. Je ne passe pas par une liste de contrôle. Cela nécessite une compréhension générale de leur système, de leurs exigences en matière de rapports, de leur budget et de leurs ressources humaines.
Personnellement, je préfère garder les processus de reporting autant que possible du côté de la base de données (Meilleures pratiques dans le monde de la BI). LES OUTILS DE RAPPORT SONT UNIQUEMENT À DES FINS D'AFFICHAGE (MAXIMUM POUR LES PETITS CALCULS). Cette approche nécessite beaucoup de prétraitement des données, ce qui nécessite différentes tables de transfert, déclencheurs, etc.
quand tu as dit:
Je travaille sur des projets comportant des centaines de millions de lignes avec des rapports en temps réel et des centaines d'utilisateurs accédant à l'application/à la base de données en même temps, sans problème.
Il y a quelques erreurs dans votre déclaration.
Des centaines de millions de lignes sont BEAUCOUP. Même les outils en mémoire actuels tels que 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 traitent).
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 passer par tous ces enregistrements. Peut-être que le rapport a fonctionné sur des milliers et non des millions c'est probablement ce que vous avez vu.
Les rapports transactionnels sont très différents des tableaux de bord. La plupart des outils de tableau de bord prétraitent et cachent les données.
Je sais que je réponds 2 ans plus tard et que mes pensées ne sont pas bien organisées, mais ce que je veux dire, c’est une expérience qui permet d’expérimenter pour décider quand: 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 génération de rapports (des tableaux de bord manuscrits avec Java/JSF/Ajax/jQuery ou JSP peuvent fonctionner correctement pour le client)
La principale raison pour laquelle vous auriez besoin d'une base de données distincte pour signaler les problèmes 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 utiliser 100% de la CPU/du disque/etc ... pendant une période de forte activité, vous pourriez penser à utiliser une base de données distincte pour la génération de rapports.
En ce qui concerne les questions, en voici quelques unes:
- Puis-je faire les rapports de haute intensité en dehors des heures de pointe?
- Cela interfère-t-il avec les utilisateurs du système?
- 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, d'un code de refactoring, etc.
Fondamentalement, lorsque le chargement de la base de données à partir de l'application devient incompatible avec le chargement de la base de données pour la génération de rapports. Cela pourrait être dû à:
Signaler des quantités excessives de ressources du serveur de base de données qui ont une incidence sur les performances de la base de données de l'application.
Une partie de cette catégorie serait le travail de la base de données d'application devant attendre une requête de rapport extrêmement lente en raison du verrouillage, bien qu'il soit possible de résoudre le problème à l'aide de méthodes moins radicales telles que le verrouillage.
Les requêtes de rapport étant très incompatibles avec les requêtes d'applications en ce qui concerne le réglage (par exemple, les index mais sans s'y limiter), l'exemple le plus stupide serait quelque chose comme un point chaud affectant les insertions d'application en raison de l'index de rapport.
Problèmes de timing. Par exemple. les seules petites fenêtres disponibles pour la maintenance de la base de données (en raison de l'utilisation de l'application) sont les périodes de travail de génération de rapports intense
Le volume de données de rapport (par exemple, la journalisation, l'audit, les statistiques) est si important que l'architecture de votre serveur de base de données principal est une mauvaise solution pour ce type de rapport (voir Sybase ASE vs. Sybase IQ). BTW, c'est un scénario réel - nous avons déplacé nos rapports de performance vers IQ pour cette raison.
J'ajouterais également une autre raison pour laquelle vous pourriez utiliser une base de données de rapports, à savoir: Modèle CQRS (Séparation des responsabilités de la requête de commande).
Si vous avez un grand nombre d'utilisateurs accédant et écrivant dans un petit ensemble de données, vous feriez bien de prendre en compte ce modèle. En gros, dans sa forme la plus simple, cela signifie que toutes vos commandes (Créer, Mettre à jour, Supprimer) sont placées dans la base de données transactionnelle. Toutes vos requêtes (Lire) proviennent de votre base de données de rapports. Cela vous permet de copier librement votre architecture et la fonction de mise à niveau.
Il y a BEAUCOUP plus de choses 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.
J'ajouterais également que les bases de données transactionnelles sont censées conserver l'état actuel et le font souvent pour s'auto-entretenir. Vous ne voulez pas que les bases de données transactionnelles se développent au-delà de leurs moyens nécessaires. Lorsqu'un flux de travail ou une transaction est terminé, déplacez ces données vers une base de données de rapports, qui est bien mieux conçue pour contenir des données historiques.