Vues indexées dans les tables OLTP?

Question

Je connais les vues indexées SQL Server (ou Oracle Materialized Views), nous les utilisons dans nos applications OLAP. Ils ont la caractéristique vraiment cool d'être capable d'usurper un plan d'exécution et de le remapper à la vue indexée sans avoir à changer le code existant.

IE. Disons que j'ai eu un SPROC qui était une jointure vraiment chère.

SELECT [QUELQUES COLONNES]
FROM Table1 INNER JOIN Table2 [Détails]
INNER JOIN Table3 [BUNCH PLUS REJOINT] ...

Si j'Authored une vue indexée qui a tenu une jeu de résultats similaire alors l'optimiseur de requête enverra très probablement le SPROC à ma vue indexée par opposition aux tables de base et j'obtiens une grande augmentation de la performance.

Dites 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 lourdes en lecture, s'ils ont des jointures coûteuses alors nous pourrions les accélérer d'une tonne ET potentiellement réduire les conflits de verrouillage (http://www.codinghorror.com/blog/archives/001166.html). Mieux encore, vous n'avez pas besoin de changer de code, mais créez simplement la vue indexée.

Mais cela signifie aussi la base de données devient de plus car nous avons besoin de conserver une copie de ces données dans la vue indexée ...

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

Answer 1

Les vues matérialisées peuvent être utiles pour générer des rapports sur OLTP, en particulier lorsqu'un grand nombre de lignes est agrégé pour obtenir les résultats. L'espace requis dépend entièrement de la quantité de données que vous enregistrez. Pensez-y comme un cache. L'équilibre délicat est entre la date à laquelle les données doivent être générées pour les rapports et la quantité de données que vous pouvez obtenir sur les performances OLTP. Si les données obsolètes sont correctes, vous pouvez planifier les mises à jour des vues pendant une période où l'activité du système est faible.

La fois où je ne pouvais pas, et besoin de données très actuelles, j'ai fini par utiliser un développement personnalisé. Chaque mise à jour de la table de base a déclenché un déclencheur qui a écrit un enregistrement dans une table de transaction. La vue a examiné un agrégat mis en cache, plus le delta stocké dans la table de transactions. Lorsque les ressources système sont autorisées, les transactions ont été appliquées à la table d'agrégats en tant que transactions delta. Cela m'a permis d'atteindre les deuxièmes données, de bonnes performances sur les rapports (la seule agrégation se produisant sur les transactions récentes) et une charge relativement faible sur la base de données (doubler la taille de chaque écriture, ne pas recalculer un agrégat à chaque fois).

Malheureusement, il était complexe à maintenir et n'utilisait pas d'outils intégrés simples. Si vous pouvez attendre sur vos données de rapport, 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 où je travaille. Le plus souvent pour les rapports contre le système OLTP. La plupart de nos rapports proviennent d'un entrepôt de données, mais puisque nous actualisons l'entrepôt pendant la nuit, les données doivent provenir des tables OLTP.