Vues indexées dans les OLTP ?

Question

Je connais les vues indexées SQL Server (ou vues matérialisées Oracle), nous les utilisons dans nos applications OLAP.Ils ont la fonctionnalité vraiment intéressante de pouvoir usurper un plan d'exécution et de le remapper vers la vue indexée sans avoir à modifier le code existant.

C'EST À DIRE.Disons que j'avais un SPROC qui coûtait très cher.

SÉLECTIONNEZ [CERTAINES COLONNES]
FROM Table1 INNER JOIN Table2 [DÉTAILS]
Tableau de jointure intérieure3 [Bunch plus de joints] ...

Si j'ai créé une vue indexée contenant un ensemble de résultats similaire, l'optimiseur de requêtes enverra très probablement le SPROC à ma vue indexée par opposition aux tables de base et j'obtiendrai une forte augmentation des performances.

Disons maintenant que je voulais utiliser des vues indexées dans un OLTP !? Je veux dire que la plupart des OLTP (comme ce site) sont relativement lourds en lecture, s'ils ont des jointures coûteuses, nous pourrions les accélérer considérablement ET potentiellement réduire les conflits de verrouillage (http://www.codinghorror.com/blog/archives/001166.html).Mieux encore, vous n’aurez pas besoin de modifier le code, il vous suffit de créer la vue indexée.

Mais cela signifie également que la base de données s'agrandit puisque nous devons conserver une copie de ces données dans la vue indexée...

Quelqu'un a-t-il déjà utilisé des vues indexées pour résoudre des problèmes de contention ou de vitesse dans un OLTP ?Comment se fait-il que je n'ai jamais vu ça en utilisation ?

Answer 1

Les vues matérialisées peuvent être utiles pour créer des rapports sur OLTP, en particulier si un grand nombre de lignes sont agrégées pour obtenir les résultats.Les besoins en espace dépendent entièrement de la quantité de données que vous enregistrez.Considérez-le comme une cache.

L’équilibre délicat se situe entre la date à laquelle les données doivent être récentes pour les rapports et l’impact que vous pouvez avoir sur les performances OLTP.Si des données quelque peu obsolètes sont correctes, vous pourrez peut-être planifier les mises à jour des vues à une période où l'activité du système est faible.

La seule fois où je n’ai pas pu et où j’avais besoin de données très récentes, j’ai fini par utiliser un développement personnalisé.Chaque mise à jour de la table de base déclenchait un déclencheur qui écrivait un enregistrement dans une table de transactions.La vue examinait un agrégat mis en cache, ainsi que le delta stocké dans la table des transactions.Dans la mesure où les ressources système le permettaient, les transactions ont été appliquées à la table agrégée en tant que transactions delta.Cela m'a permis d'accéder aux secondes données, de bonnes performances en matière de reporting (la seule agrégation effectuée était les transactions récentes) et assez peu de charge sur la base de données (ne doublant que la taille de chaque écriture, sans recalculer un agrégat énorme à chaque fois).

Malheureusement, il était complexe à maintenir et n’utilisait pas d’outils intégrés simples.Si vous pouvez attendre vos données de reporting, il est souvent préférable d'utiliser les vues matérialisées intégrées et de différer l'actualisation.

Answer 2

Nous utilisons des vues matérialisées pour accélérer les choses là où je travaille.Le plus souvent pour les rapports contre le système OLTP.Beaucoup de nos rapports sont exécutés à partir d'un entrepôt de données, mais comme nous actualisons l'entrepôt du jour au lendemain, jusqu'à présent, les données doivent provenir des tables OLTP.