Stratégies de vues matérialisées

Cet article contient des informations sur les stratégies qui peuvent être définies sur les vues matérialisées.

Stratégie de rétention et de mise en cache

Une vue matérialisée a une stratégie de rétention et une stratégie de mise en cache. La vue matérialisée dérive les stratégies de rétention et de mise en cache de la base de données par défaut. Ces stratégies peuvent être modifiées à l’aide de commandes de gestion des stratégies de rétention ou de commandes de gestion des stratégies de mise en cache.

Les deux stratégies sont appliquées uniquement sur la partie matérialisée de la vue matérialisée. Pour une explication des différences entre la partie matérialisée et la partie delta, consultez le fonctionnement des vues matérialisées. Par exemple, si la stratégie de mise en cache d’une vue matérialisée est définie sur 7d, mais que la stratégie de mise en cache de sa table source est définie sur 0d, il peut toujours y avoir des absences de disque lors de l’interrogation de la vue matérialisée. Ce comportement se produit car la table source (partie delta) participe également à la requête.

La stratégie de rétention de la vue matérialisée n’est pas liée à la stratégie de rétention de la table source. La stratégie de rétention de la table source peut être plus courte que la stratégie de rétention de la vue matérialisée, si les enregistrements sources sont requis pendant une période plus courte. Nous recommandons une stratégie de rétention minimale d’au moins quelques jours et la possibilité de récupération définie sur true sur la table source. Ce paramètre permet une récupération rapide pour les erreurs et à des fins de diagnostic.

Notes

La stratégie de rétention zéro sur la table source n’est pas prise en charge.

Les stratégies de rétention et de mise en cache dépendent toutes deux de la durée de création de l’étendue. La dernière mise à jour d’un enregistrement détermine l’heure de création de l’étendue d’une vue matérialisée.

Notes

Le processus de matérialisation tente de réduire la quantité de mises à jour de la partie matérialisée de la vue. Dans les cas où un enregistrement n’a pas besoin d’être mis à jour dans la vue, il ne l’est pas. Par exemple, lorsque la vue matérialisée est une take_any(*) agrégation, les nouveaux enregistrements des mêmes clés de groupe par ne sont pas réingérés dans la vue et, par conséquent, la stratégie de rétention est ingérée par enregistrement le plus tôt.

Stratégie de partitionnement

Une stratégie de partitionnement peut être appliquée à une vue matérialisée. Nous vous recommandons de configurer une stratégie de partitionnement sur une vue matérialisée uniquement lorsque la plupart ou la totalité des requêtes d’affichage filtrent selon l’une des clés group-by de la vue matérialisée. Cette situation est courante dans les solutions multilocataires, où l’une des clés group-by de la vue matérialisée est l’identificateur du locataire (par exemple, tenantId, customerId). Pour plus d’informations, consultez le premier cas d’usage décrit dans la page scénarios pris en charge par la stratégie de partitionnement .

Pour que les commandes modifient la stratégie de partitionnement d’une vue matérialisée, consultez Commandes de stratégie de partitionnement.

L’ajout d’une stratégie de partitionnement sur une vue matérialisée augmente le nombre d’étendues dans la vue matérialisée et crée davantage de « travail » pour le processus de matérialisation. Pour plus d’informations sur la raison de ce comportement, consultez le processus de reconstruction des extensions mentionné dans le fonctionnement des vues matérialisées.

Stratégie de sécurité au niveau des lignes

Une sécurité au niveau des lignes peut être appliquée sur une vue matérialisée, avec plusieurs limitations :

• La stratégie peut être appliquée uniquement aux vues matérialisées avec des fonctions d’agrégation arg_max()/arg_min()/take_any(), ou lorsque la requête de sécurité au niveau des lignes référence le groupe par des clés de l’agrégation de vue matérialisée.
• La stratégie est appliquée uniquement à la partie matérialisée de la vue.
  • Si la même stratégie de sécurité au niveau des lignes n’est pas définie sur la table source de la vue matérialisée, l’interrogation de la vue matérialisée peut retourner des enregistrements qui doivent être masqués par la stratégie. Cela se produit parce que l’interrogation de la vue matérialisée interroge également la table source.
  • Nous vous recommandons de définir la même stratégie de sécurité au niveau des lignes à la fois sur la table source et sur la vue matérialisée si la vue est arg_max() ou arg_min()/take_any()).
• Lors de la définition d’une stratégie de sécurité au niveau des lignes sur la table source d’une vue matérialisée arg_max() ou arg_min()/take_any(), la commande échoue s’il n’existe aucune stratégie de sécurité au niveau des lignes définie sur la vue matérialisée elle-même. L’objectif de l’échec est d’avertir l’utilisateur d’une fuite de données potentielle, car la vue matérialisée peut exposer des informations. Pour atténuer cette erreur, effectuez l’une des actions suivantes :
  • Définissez la stratégie de sécurité au niveau des lignes sur la vue matérialisée.
  • Choisissez d’ignorer l’erreur en ajoutant allowMaterializedViewsWithoutRowLevelSecurity la propriété à la commande alter policy. Par exemple :

    .alter table SourceTable policy row_level_security enable with (allowMaterializedViewsWithoutRowLevelSecurity=true) "RLS_function"

Pour les commandes permettant de configurer une stratégie de sécurité au niveau des lignes sur une vue matérialisée, consultez commandes de stratégie row_level_security.