Datawarehouse de performance de problème avec beaucoup d'index

Question

Notre produit fait des essais de 350 candidats en même temps. À la fin du test, les résultats de chaque candidat sont déplacés vers un datawarehouse rempli d'index. Pour chaque test, il y a quelque 400 enregistrements à entrer dans Datawarehouse. Donc, 400 x 350 est beaucoup d'enregistrements. S'il n'y a pas beaucoup d'enregistrements dans le datawarehouse, tout se passe bien. Mais s'il y a déjà beaucoup d'enregistrements dans le datawarehouse, alors beaucoup d'insertions échouent ...

Existe-t-il un moyen d'avoir des index qui sont seulement reconstruits à la fin de la journée ou n'est-ce pas le vrai problème? ? Ou comment voulez-vous résoudre cela?

Answer 1

J'ai travaillé avec des entrepôts de données standard et Kimball Star, mais cela ne vous semble pas être un problème. Je dirais 140000 lignes n'est pas beaucoup de lignes, même dans un petit entrepôt de données.

Pourquoi les insertions échouent-elles? Généralement, dans un entrepôt de style Kimball, aucune insertions n'échoue jamais - par exemple, dans une table de faits, les insertions ont toujours un ensemble unique de clés primaires liées aux dimensions et au grain (comme un instantané de date ou d'heure). Dans une table de dimmension, des modifications sont détectées, de nouvelles dimensions sont insérées, celles existantes sont réutilisées. Dans un entrepôt normalisé, vous disposez généralement d'un mécanisme de révision ou d'un processus d'archivage ou d'une date d'entrée en vigueur qui conserve les choses uniques.

Il me semble que quelque soit la philosophie ou l'architecture de votre logiciel DW, il devrait y avoir quelque chose qui garderait ces lignes uniques. Si (comme vous l'avez indiqué dans vos commentaires) vous avez un seul index contenant chaque colonne, ce n'est probablement pas un index très utile (dans n'importe quelle conception de base de données). Êtes-vous sûr que votre index est même utilisé pour des requêtes? Est-il également marqué comme étant unique et cette contrainte est-elle violée? En tout cas, c'est un très grand index multi-colonnes, et il va être relativement cher de comparer - cela pourrait entraîner un timeout - vous pouvez toujours corriger cela dans votre connexion pour attendre indéfiniment, mais je voudrais attaquer le problème de une perspective de conception.

Answer 2

Il est courant dans les entrepôts de données de supprimer les index et les contraintes avant le chargement et de les recréer après. Si vous supprimez des contraintes (FK), assurez-vous que votre processus de chargement s'en occupe. Supprimez toutes les contraintes de vérification et transférez les validations de contrôle dans le logiciel ETL.

Answer 3

140K est pas beaucoup de lignes. S'il vous plaît poster votre conception de table et l'erreur que vous obtenez lorsque les insertions échouent

Answer 4

Je suggère ce qui suit: Conservez toutes vos données, sauf d'aujourd'hui dans le tableau séparé (appelons-le Histoire), où indexés sont réglés pour vos rapports. Conservez les données du jour dans un autre tableau séparé (Appelons-le aujourd'hui) et exécutez un travail à minuit pour déplacer les données de la table Aujourd'hui vers la table Historique. Dans la table Aujourd'hui, vous devez avoir une indexation minimale pour améliorer les performances d'insertion. En implémentant cette conception, vous serez sûr que vos rapports ne sont pas encombrés avec des insertions. En outre - vous avez deux table à l'écoute pour leurs besoins. En général, il est difficile de régler la table pour des insertions rapides et des sélections rapides.