Oracle Analytics Cloud maintient un cache d'ensembles de résultats de requête dans le cache de requêtes.
Rubriques :
Le cache de requêtes permet à Oracle Analytics Cloud de répondre à plusieurs demandes de requête consécutives sans accéder aux sources de données back-end, ce qui améliore les performances de requête. Cependant, les entrées du cache de requêtes peuvent devenir obsolète au fil des mises à jour des sources de données back-end.
Le moyen le plus rapide de traiter une requête est d'éviter la majeure partie du traitement et d'utiliser une réponse précalculée.
Avec la mise en cache des requêtes, Oracle Analytics Cloud stocke les résultats précalculés des requêtes dans un cache local. Si une autre requête peut utiliser ces résultats, tout traitement de base de données pour cette requête est éliminé. Le temps de réponse moyen des requêtes peut s'en trouver grandement amélioré.
En plus d'améliorer les performances, la possibilité de répondre à une requête à partir d'un cache local préserve les ressources réseau et le temps de traitement sur le serveur de base de données. Les ressources réseau sont préservées car les résultats intermédiaires ne sont pas renvoyés à Oracle Analytics Cloud. La non-exécution de la requête sur la base de données libère le serveur de base de données pour d'autres tâches. Si la base de données applique un système de refacturation, l'exécution d'un plus faible nombre de requêtes peut réduire les coûts.
L'un des autres avantages de l'utilisation du cache pour répondre à une requête est le gain de temps de traitement sur Oracle Analytics Cloud, particulièrement si les résultats de la requête sont extraits de plusieurs bases de données. En fonction de la requête, le traitement de jointure et de tri peut être considérable sur le serveur. Si la requête est déjà calculée, ce traitement est évité, ce qui libère des ressources de serveur pour d'autres tâches.
En résumé, la mise en cache des requêtes améliore significativement les performances de requête et réduit le trafic réseau, le traitement de base de données et la surcharge de traitement.
La mise en cache des requêtes possède des avantages évidents, mais engendre des coûts.
Potentiel de résultats mis en cache obsolètes
Coûts d'administration de gestion du cache
Avec la gestion de cache, les avantages l'emportent haut la main sur les coûts.
Certaines tâches d'administration sont associées à la mise en cache. Vous devez définir une durée appropriée de persistance du cache pour chaque table physique, basée sur la fréquence de mise à jour de données de la table.
En cas de variation de la fréquence de mise à jour, suivez la survenue des modifications et purgez le cache manuellement si nécessaire.
Si les entrées de cache ne sont pas purgées lorsque les données des bases de données sous-jacentes changent, les requêtes peuvent potentiellement renvoyer des résultats obsolètes.
Vous devez déterminer si ce comportement est acceptable. Vous pouvez tolérer que le cache contienne des données obsolètes. Vous devez décider du niveau de données obsolètes acceptable, puis configurer (et suivre) un ensemble de règles en adéquation avec ce niveau.
Par exemple, supposons qu'une application analyse les données d'entreprise d'un grand conglomérat, et que vous générez des récapitulatifs annuels sur les différentes divisions de l'entreprise. Les nouvelles données n'ont pas d'impact net sur les requêtes car elles concernent uniquement les récapitulatifs de l'année suivante. Dans ce cas, au moment de déterminer si le cache doit être purgé, la balance peut pencher en faveur de la conservation des entrées dans le cache.
Imaginons, cependant, que les bases de données sont mises à jour trois fois par jour et que vous exécutez les requêtes sur les activités du jour. Dans ce cas, vous devez purger le cache plus fréquemment, voire envisager de ne pas utiliser le cache.
Dans un autre scénario, vous recréez l'ensemble de données intégralement à des intervalles réguliers (par exemple, une fois par semaine). Dans cet exemple, vous pouvez purger la totalité du cache dans le cadre du processus de recréation de l'ensemble de données, ce qui vous assure de l'absence de données obsolètes dans le cache.
Quelle que soit votre situation, vous devez déterminer ce qui est acceptable en matière d'informations non à jour renvoyées aux utilisateurs.
Si la connexion partagée est activée pour un pool de connexions spécifique, le cache peut être partagé entre les utilisateurs et ne doit pas être prédéfini pour chaque utilisateur.
Si la connexion partagée n'est pas activée et qu'une connexion de base de données propre à l'utilisateur est employée, chaque utilisateur génère sa propre entrée de cache.
Dans Oracle Analytics Cloud, le cache de requêtes est activé par défaut. Vous pouvez activer ou désactiver la mise en cache des requêtes sur la page Paramètres système.
Pour gérer les modifications apportées aux bases de données sous-jacentes et pour surveiller les entrées de cache, vous devez développer une stratégie de gestion de cache.
Vous avez besoin d'un processus permettant d'invalider les entrées de cache lorsque les données des tables sous-jacentes qui composent ces entrées changent, ainsi que d'un processus permettant de surveiller, d'identifier et d'enlever les entrées de cache indésirables.
Cette section comprend les rubriques suivantes :
Le choix d'une stratégie de gestion de cache dépend de la volatilité des données dans les bases de données sous-jacentes et de la prévisibilité des modifications à l'origine de cette volatilité.
Il dépend également du nombre de requêtes comprises dans le cache et de leurs types, ainsi que de l'utilisation qui est faite de ces requêtes. Cette section fournit une présentation des différentes approches de gestion de cache.
Vous pouvez désactiver la mise en cache pour l'intégralité du système afin de faire en sorte que toutes les nouvelles entrées de cache et les nouvelles requêtes n'utilisent pas le cache existant. Si vous désactivez la mise en cache, vous pouvez l'activer ultérieurement sans perdre les entrées stockées dans le cache.
La désactivation temporaire de la mise en cache est une stratégie efficace dans les cas où vous suspectez la présence d'entrées de cache obsolètes, mais où vous voulez vérifier si elles sont véritablement obsolètes avant de purger ces entrées ou l'ensemble du cache. S'il s'avère que les données stockées dans le cache sont toujours pertinentes, ou une fois que vous avez purgé en toute sécurité les entrées problématiques, vous pouvez activer le cache sans inquiétude. Si nécessaire, purgez l'intégralité du cache ou le cache associé à un modèle de gestion particulier avant de réactiver le cache.
Vous pouvez définir un attribut pouvant être mis en cache pour chaque table physique, ce qui vous permet d'indiquer si les requêtes pour cette table sont ajoutées au cache afin de répondre aux requêtes futures.
Si vous activez la mise en cache pour une table, toute requête impliquant la table est ajoutée au cache. Par défaut, toutes les tables peuvent être mises en cache, mais l'inclusion de certaines dans le cache peut ne pas être pertinente, sauf si vous configurez les paramètres appropriés de persistance du cache. Par exemple, supposons que vous disposez d'une table qui stocke des données boursières mises à jour toutes les minutes. Vous pouvez indiquer que vous voulez purger les entrées pour cette table toutes les 59 secondes.
Vous pouvez également utiliser les paramètres de persistance du cache afin d'indiquer la durée de stockage des entrées pour cette table dans le cache de requêtes. Cette opération est utile pour les sources de données mises à jour fréquemment.
Dans l'outil d'administration de modèle, dans la couche physique, cliquez deux fois sur la table physique.
Si vous utilisez le modeleur sémantique, reportez-vous à Quelles sont les propriétés générales d'une table physique ?.
Dans la boîte de dialogue des propriétés de la table physique, dans l'onglet Général, effectuez l'une des sélections suivantes :
Pour activer la mise en cache, sélectionnez Mise en mémoire cache possible.
Pour empêcher la mise en cache d'une table, désélectionnez Mise en mémoire cache possible.
Pour définir un délai d'expiration de cache, définissez la durée de persistance du cache et indiquez une unité de mesure (jours, heures, minutes ou secondes). Si vous ne voulez pas que les entrées de cache expirent automatiquement, sélectionnez Le cache n'expire jamais.
Cliquez sur OK.
Lorsque vous modifiez des modèles sémantiques à l'aide du modeleur sémantique ou de l'outil d'administration de modèle, les modifications peuvent avoir des conséquences sur les entrées stockées dans le cache. Par exemple, si vous modifiez la définition d'un objet physique ou d'une variable de modèle sémantique globale, les entrées de cache référençant cet objet ou cette variable peuvent ne plus être valides. Suite à ces modifications, vous devrez peut-être purger le cache. Vous devez connaître deux scénarios : la modification d'un modèle sémantique existant et la création (ou le téléchargement vers le serveur) d'un modèle sémantique.
Modifications apportées au modèle sémantique
Lorsque vous modifiez un modèle sémantique ou téléchargez un autre fichier .rpd, toute modification apportée ayant une incidence sur les entrées de cache entraîne automatiquement la purge de toutes les entrées de cache référençant les objets modifiés. La purge survient lorsque vous téléchargez les modifications. Par exemple, si vous supprimez une table physique d'un modèle sémantique, toutes les entrées de cache référençant cette table sont purgées au moment de la réinsertion. Les éventuelles modifications apportées à un modèle sémantique de la couche logique purgent toutes les entrées de cache correspondant à ce modèle sémantique.
Modifications apportées aux variables globales de modèle sémantique
Les valeurs des variables de modèle sémantique globales sont actualisées par les données renvoyées par les demandes. Lorsque vous définissez une variable de modèle sémantique globale, vous créez un bloc d'initialisation ou vous utilisez un bloc préexistant contenant une requête SQL. Vous configurez également une programmation d'exécution de la requête et actualisez régulièrement la valeur de la variable.
En cas de modification de la valeur d'une variable de modèle sémantique globale, toute entrée de cache utilisant cette variable dans une colonne devient obsolète, et une nouvelle entrée de cache est générée lorsque les données de cette entrée sont à nouveau demandées. L'ancienne entrée de cache n'est pas enlevée immédiatement, mais est conservée jusqu'à son nettoyage via le mécanisme de mise en cache habituel.
L'un des avantages principaux de la mise en cache des requêtes est l'amélioration des performances de requête apparentes.
La mise en cache des requêtes peut être utile pour prédéfinir le cache pendant les heures creuses en exécutant des requêtes et en mettant en cache leurs résultats. Pour une stratégie de prédéfinition efficace, vous devez savoir à quel moment ont lieu les accès réussis au cache.
Si vous voulez prédéfinir le cache pour tous les utilisateurs, vous devez appliquer la requête suivante :
SELECT User, SRs
Une fois le cache prédéfini à l'aide de SELECT User, SRs, les requêtes suivantes constituent des accès réussis au cache :
SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (and the user was USER1) SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (and the user was USER2) SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (and the user was USER3)
Cette section comprend les rubriques suivantes :
Lorsque la mise en cache est activée, chaque requête est évaluée pour déterminer si elle peut générer un accès réussi au cache.
Un accès réussi au cache signifie qu'Oracle Analytics Cloud a pu utiliser le cache pour répondre à la requête sans jamais passer par la base de données. Oracle Analytics Cloud peut utiliser le cache de requêtes pour répondre aux requêtes à un niveau d'agrégation identique ou supérieur.
De nombreux facteurs déterminent l'accès réussi au cache. Le tableau ci-dessous décrit ces facteurs.
| Facteur ou règle | Description |
|---|---|
|
Un sous-ensemble de colonne dans la liste |
Toutes les colonnes de la liste Cette règle décrit les exigences minimales d'accès au cache, mais le respect de cette règle ne garantit pas un accès réussi au cache. Les autres règles répertoriées dans ce tableau s'appliquent également. |
|
Les colonnes de la liste |
Oracle Analytics Cloud peut calculer les expressions des résultats mis en cache afin de répondre à la nouvelle requête, mais toutes les colonnes doivent figurer dans le résultat mis en cache. Par exemple, la requête : SELECT product, month, averageprice FROM sales WHERE year = 2000 entraîne un accès réussi au cache sur la requête : SELECT product, month, dollars, unitsales FROM sales WHERE year = 2000 car |
|
La clause |
Pour que la requête puisse générer un accès réussi au cache, les contraintes de la clause Une clause
Par ailleurs, les colonnes utilisées sur la clause SELECT employeename
FROM employee, geography
WHERE region in ('EAST', 'WEST')
ne génère pas un accès réussi au cache pour la requête de prédéfinition de la liste précédente car REGION ne figure pas dans la liste de projection. |
|
Les requêtes de dimension uniquement doivent constituer des correspondances exactes |
S'il s'agit d'une requête de dimension uniquement, c'est-à-dire qu'aucun fait ou indicateur n'est inclus dans la requête, seule une correspondance exacte des colonnes de projection de la requête mise en cache entraîne un accès réussi au cache. Ce comportement empêche les faux positifs en présence de plusieurs sources logiques pour une table de dimensions. |
|
Les requêtes avec des fonctions spéciales doivent constituer des correspondances exactes |
Les autres requêtes contenant des fonctions spéciales telles que les fonctions de séries temporelles ( |
|
L'ensemble de tables logiques doit concorder |
Pour pouvoir générer des accès réussis au cache, toutes les requêtes entrantes doivent posséder le même ensemble de tables logiques que l'entrée de cache. Cette règle permet d'éviter les faux accès réussis au cache. Par exemple, |
|
Les valeurs de variable de session doivent concorder, y compris les variables de session de sécurité |
Si l'instruction SQL physique ou logique fait référence à une variable de session, les valeurs de variable de session doivent concorder. Sinon, la requête n'accède pas au cache. Par ailleurs, les valeurs des variables de session en lien avec la sécurité doivent correspondre aux valeurs de variable de session de sécurité définies dans le modèle sémantique, même si l'instruction SQL logique en elle-même ne référence pas les variables de session. Reportez-vous à Résultats de cache corrects assurés lors de l'utilisation de la sécurité de base de données de niveau ligne. |
|
Conditions de jointure équivalentes |
La table logique jointe résultante d'une nouvelle demande de requête doit être identique aux résultats mis en cache (ou en représenter un sous-ensemble) pour pouvoir générer un accès réussi au cache. |
|
L'attribut |
Si une requête mise en cache élimine les enregistrements en double via le traitement |
|
Les requêtes doivent contenir des niveaux d'agrégation compatibles |
Les requêtes qui demandent un niveau d'informations agrégé peuvent utiliser les résultats mis en cache à un niveau inférieur d'agrégation. Par exemple, la requête suivante demande la quantité vendue au niveau du fournisseur, de la région et de la ville : SELECT supplier, region, city, qtysold FROM suppliercity La requête suivante demande la quantité vendue au niveau de la ville : SELECT city, qtysold FROM suppliercity La seconde requête génère un accès réussi au cache sur la première requête. |
|
Agrégation supplémentaire limitée |
Par exemple, si une requête avec la colonne |
|
La clause |
Les requêtes avec des colonnes ORDER BY qui n'apparaissent pas dans la liste SELECT génèrent des accès non réussis au cache. |
|
Diagnostic du comportement d'accès réussi au cache |
Pour mieux évaluer le comportement d'accès réussi au cache, définissez la variable de session ENABLE_CACHE_DIAGNOSTICS sur 4, comme indiqué dans l'exemple suivant : ENABLE_CACHE_DIAGNOSTICS=4 |
Lors de l'utilisation d'une stratégie de sécurité de base de données de niveau ligne, comme avec une base de données privée virtuelle, les résultats de données renvoyés dépendent des informations d'identification d'autorisation de l'utilisateur.
De ce fait, Oracle Analytics Cloud doit savoir si une source de données utilise la sécurité de base de données de niveau ligne et connaître les variables associées à la sécurité.
Pour vous assurer que les accès réussis au cache surviennent uniquement sur les entrées de cache qui incluent toutes les variables de sécurité et y correspondent, vous devez configurer correctement l'objet de base de données et les objets de variable de session dans l'outil d'administration de modèle, comme suit :
Objet de base de données. Dans la couche physique, dans l'onglet Général de la boîte de dialogue Base de données, sélectionnez Base de données privée virtuelle pour indiquer que la source de données utilise la sécurité de base de données de niveau ligne.
Si vous utilisez la sécurité de base de données de niveau ligne avec la mise en cache partagée, vous devez sélectionner cette option pour empêcher le partage des entrées de cache dont les variables de sécurité ne sont pas mises en correspondance.
Objet de variable de session. Pour les variables associées à la sécurité, dans la boîte de dialogue Variable de session, sélectionnez Prendre en compte la sécurité pour les identifier comme variables de sécurité en cas d'utilisation de la stratégie de sécurité de base de données de niveau ligne. Cette option fait en sorte que les entrées de cache soient marquées avec les variables de sécurité, ce qui permet la mise en correspondance des variables de sécurité sur toutes les requêtes entrantes.
Pour maximiser les accès réussis potentiels au cache, l'une des stratégies consiste à exécuter une suite de requêtes pour remplir le cache.
Vous trouverez ci-après des recommandations relatives aux types de requête à utiliser lors de la création d'une suite de requêtes servant à prédéfinir le cache.
Requêtes préconstruites courantes. Les requêtes couramment exécutées, en particulier celles dont le traitement est coûteux, sont d'excellentes requêtes de prédéfinition de cache. Les requêtes dont les résultats sont imbriqués dans des tableaux de bord sont des exemples pertinents de requêtes courantes.
Listes SELECT sans expression. L'élimination des expressions dans les colonnes de liste SELECT accroît la probabilité d'accès réussis au cache. Une colonne mise en cache avec une expression peut uniquement répondre à une nouvelle requête avec la même expression, tandis qu'une colonne mise en cache sans expression peut répondre à une demande pour cette colonne avec n'importe quelle expression. Par exemple, une demande mise en cache telle que :
SELECT QUANTITY, REVENUE...
peut répondre à une nouvelle requête telle que :
SELECT QUANTITY/REVENUE...
mais pas l'inverse.
Aucune clause WHERE. En l'absence de clause WHERE dans un résultat mis en cache, celui-ci peut être utilisé pour répondre aux requêtes conformes aux règles d'accès réussi au cache pour la liste SELECT avec n'importe quelle clause WHERE incluant des colonnes dans la liste de projection.
En général, les meilleures requêtes pour prédéfinir le cache sont celles qui consomment d'importantes ressources de traitement de base de données et sont susceptibles d'être émises à nouveau. Veillez à ne pas prédéfinir le cache avec des requêtes simples renvoyant de nombreuses lignes. Ces requêtes (par exemple, SELECT * FROM PRODUCTS, où PRODUCTS est mis en correspondance directement avec une seule table de base de données) impliquent très peu de ressources de traitement de base de données. Leur inconvénient est la surcharge du réseau et du disque, que la mise en cache ne réduit pas.
Lorsqu'Oracle Analytics Cloud actualise les variables de modèle sémantique, il examine les modèles de gestion pour déterminer s'ils référencent ces variables de modèle sémantique. Si tel est le cas, Oracle Analytics Cloud purge l'ensemble du cache pour ces modèles de gestion. Reportez-vous à Impact des modifications de modèle sémantique sur le cache de requêtes.
Vous pouvez configurer des agents pour prédéfinir le cache de requêtes Oracle Analytics Cloud.
La prédéfinition du cache peut améliorer les temps de réponse pour les utilisateurs lorsqu'ils exécutent des analyses et visualisent des analyses imbriquées sur leurs tableaux de bord. Pour ce faire, programmez l'exécution de demandes actualisant ces données par les agents.
La seule différence entre les agents de prédéfinition de cache et les autres agents réside dans le fait qu'ils effacent automatiquement le cache précédent et n'apparaissent pas sur le tableau de bord en tant qu'alertes.
Remarque :
Les agents de prédéfinition de cache purgeant uniquement les requêtes avec correspondance exacte, des données obsolètes peuvent subsister. Assurez-vous que la stratégie de mise en cache inclut toujours la purge du cache, car les requêtes d'agent ne gèrent pas les explorations ou les requêtes ad hoc.La purge du cache entraîne la suppression des entrées du cache de requêtes et maintient le contenu à jour. Vous pouvez purger automatiquement les entrées de cache pour des tables spécifiques en définissant le champ Durée de persistance du cache de chaque table dans l'outil d'administration de modèle.
Remarque :
Si vous utilisez le modeleur sémantique, reportez-vous à Quelles sont les propriétés générales d'une table physique ?.
Cette opération est utile pour les sources de données mises à jour fréquemment. Par exemple, si vous disposez d'une table qui stocke des données boursières mises à jour toutes les minutes, vous pouvez utiliser le paramètre Durée de persistance du cache pour purger les entrées de cette table toutes les 59 secondes. Reportez-vous à Mise en cache et durée de persistance du cache pour les tables physiques spécifiées.