Nous avons un produit qui exécute Sql Server Express 2005 et utilise principalement ASP.NET. La base de données a environ 200 tables, avec quelques-unes (4 ou 5) qui peuvent passer de 300 à 5000 lignes par jour et conserver une histoire de 5 ans, de sorte qu'elles peuvent atteindre 10 millions de lignes.
Nous avons développé une plate-forme de reporting qui permet aux clients de créer des rapports basés sur des modèles, des champs et des filtres.
Nous faisons face à des problèmes de performance depuis le début, nous essayons de garder les rapports affichés sous 10 secondes, mais certains d'entre eux vont jusqu'à 25 secondes (spécialement sur les clients avec une longue histoire).
Nous continuons à vérifier les index et à essayer d'améliorer les requêtes, mais nous avons l'impression que nous ne pouvons pas faire grand-chose. Bien sûr, le fait que les requêtes soient générées dynamiquement n'aide pas à l'optimisation. Nous avons également ajouté quelques tables qui conservent des données redondantes, mais nous avons également le problème de maintenir ces données à jour, et Sql Express limite également la taille des bases de données.
Nous sommes maintenant confrontés à un point où nous devons décider si nous voulons abandonner les rapports en temps réel, ou peut-être couper l'histoire pour être en mesure d'avoir de meilleures performances.
Je voudrais demander quelle est l'approche recommandée pour ce genre de systèmes.
En outre, devrions-nous commencer à chercher des outils/plateformes tiers? Je sais que OLAP peut être une option, mais pouvons-nous la faire fonctionner sur Sql Server Express, ou au moins avec une licence qui est assez bon marché pour la distribuer à des milliers de déploiements?Architecture du système de reporting pour de meilleures performances
Merci
Oui, la demande d'accès est principalement accessible par une personne. Nous avons travaillé plusieurs fois sur l'amélioration des requêtes, l'analyse du plan d'exécution et l'ajout d'index. Nous avons amélioré de nombreuses requêtes, mais pour certains rapports, il semble impossible de passer à des requêtes d'une seconde. – pauloya
Pour pouvoir créer dynamiquement les requêtes, nous utilisons des vues qui regroupent les champs, qu'ils puissent provenir directement de tables ou de transformations de calculs de données ou de regroupements. J'imagine que cela empêche une flexibilité totale sur le bâtiment de la requête, mais même si nous essayons de construire manuellement une requête différente pour obtenir le même résultat, il ne semble pas que la performance soit meilleure. – pauloya
Cependant, nos tables étaient grandes depuis le début, parce que les données ont été migrées à partir d'un système précédent. – pauloya