Analyse des profils de requête pour les tables hybrides¶
Les charges de travail Unistore posent des questions intéressantes sur l’exécution des requêtes que vous pouvez étudier à l’aide de la fonctionnalité de profil de requête de Snowsight ou des informations recueillies à partir de la sortie EXPLAIN. En plus de surveiller les performances et le débit globaux, vous souhaiterez peut-être savoir si une analyse de table est exécutée sur le magasin de lignes ou le stockage d’objets, ou si un index secondaire spécifique est utilisé.
Cette section identifie les opérateurs et attributs Query Profile qui se rapportent aux opérations de tables hybrides, et présente quelques exemples pour vous aider à comprendre comment lire les plans de requête qui accèdent aux tables hybrides. Voir aussi Surveillance de l’activité des requêtes avec l’historique des requêtes.
Analyses de tables hybrides et analyses d’index¶
Les opérateurs d’analyse de tables et d’index apparaissent dans les profils de requête pour afficher l’accès aux tables hybrides. Ces opérateurs apparaissent généralement au bas de l’arborescence, représentant la première étape de la lecture des données nécessaires à l’exécution d’une requête spécifique. Les requêtes sur les tables standard utilisent toujours des analyses de table ; elles n’utilisent pas d’analyses d’index.
Lorsqu’un index de clé primaire est utilisé pour analyser une table hybride, un opérateur TableScan apparaît dans le profil de requête, et non un opérateur IndexScan. Lorsqu’un autre index est utilisé pour analyser une table hybride, comme un index secondaire, vous voyez un opérateur IndexScan.
Sous Attributes pour l’opérateur IndexScan, vous pouvez voir le nom complet de l’index et Access predicates. Ce sont les prédicats qui sont appliqués à l’index pendant l’analyse. Vous pouvez également voir les prédicats des filtres appliqués lors des analyses de table.
Lorsqu’un prédicat est transféré vers un index, le prédicat contient un espace réservé, entre parenthèses, pour la constante qui a été utilisée dans la requête. Par exemple : SENSOR_DATA_DEVICE2.DEVICE_ID = (:SFAP_PRE_NR_1)
Mode d’analyse¶
Les données de tables hybrides sont conservées dans deux formats pour répondre aux charges de travail opérationnelles et analytiques. Une question fréquemment posée par les administrateurs est de savoir si une requête donnée accédera au magasin de lignes ou au magasin de colonnes (stockage d’objets). Une requête peut lire à partir d’un ou des deux types de stockage, en fonction des tables en question, les exigences spécifiques de la requête, la disponibilité des index et d’autres facteurs.
Le profil de requête pour les requêtes de tables hybrides comprend un attribut Scan Mode pour chaque opérateur d’analyse de table dans l’arborescence :
ROW-BASED : la requête lit les données de la table dans le magasin de lignes ou utilise des index pour calculer les résultats de la requête.
COLUMN-BASED : la requête lit une copie de stockage d’objets des mêmes données qui ont été chargées dans le magasin de lignes. Les analyses d’index peuvent également accéder au stockage d’objets, pour les requêtes Time Travel.
Le mode d’analyse est propre aux tables hybrides. Si une analyse de table est exécutée sur une table standard, aucun attribut Scan Mode ne s’affiche.
Données lues à partir du cache de l’entrepôt en colonnes¶
Dans la mesure du possible, les analyses des tables hybrides lisent les données depuis un cache entrepôt de données en format colonne. Ce cache est une extension du cache entrepôt standard. Voir Optimisation du cache de l’entrepôt. Le cache contient des données qui ont été lues à partir du fournisseur de stockage de table hybride et qui sont accessibles par des requêtes en lecture seule sur les tables hybrides.
Pour voir l’utilisation du cache dans un profil de requête donné, sélectionnez l’opérateur d’analyse de table et vérifiez le Percentage scanned from cache sous Statistics.
Les requêtes sélectionnées à partir de tables hybrides ne bénéficient pas du cache des résultats des requêtes.
Limitations des requêtes des tables hybrides¶
Dans l”Profile Overview, vous pouvez voir un pourcentage Hybrid Table Requests Throttling. Pour voir cet aperçu, ne sélectionnez pas d’opérateur dans l’arborescence ; l’aperçu s’applique à l’ensemble du plan de requête.
Par exemple, la requête suivante a enregistré que 87,5 % de son temps d’exécution était limité par le fournisseur de stockage de table hybride. Un pourcentage de limitation élevé indique que trop de demandes de lecture et d’écriture de tables hybrides sont envoyées au fournisseur de stockage, par rapport au quota de la base de données. Pour plus d’informations, voir Quotas et limitations.
Exemples¶
Les exemples de Snowsight suivants de profils de requête montrent des attributs propres aux opérations de tables hybrides. Pour comprendre ces exemples, vous n’avez pas besoin de créer et de charger les tables qui sont interrogées et modifiées. Cependant, voici l’instruction CREATE TABLE pour l’une des tables à titre de référence. Notez la définition de la contrainte PRIMARY KEY (sur la colonne timestamp) et un index secondaire (sur la colonne device_id) :
CREATE OR REPLACE HYBRID TABLE sensor_data_device1 (
device_id VARCHAR(10),
timestamp TIMESTAMP PRIMARY KEY,
temperature DECIMAL(6,4),
vibration DECIMAL(6,4),
motor_rpm INT,
INDEX device_idx(device_id));
Une autre table hybride similaire, sensor_data_device2, est également utilisée dans les exemples.
Plan de requête qui accède à la colonne de clé primaire¶
Lorsque votre requête filtre la clé primaire de la table (timestamp), qui est automatiquement indexée, le profil de requête utilise un opérateur TableScan. Notez également que le mode d’analyse ROW_BASED est utilisé pour cette requête.
SELECT * FROM sensor_data_device1 WHERE timestamp='2024-03-01 13:45:56.000';
Plan de requête qui accède à un index secondaire¶
La requête qui a généré ce profil ressemble à ceci :
SELECT COUNT(*) FROM sensor_data_device1 WHERE device_id='DEVICE2';
Seule une partie du profil est présentée ici. L’accent est mis sur l’opérateur IndexScan et ses attributs. Le mode d’analyse est ROW_BASED, et vous pouvez voir le prédicat complet en passant la souris sur :UI :Prédicats d'accès. Le nom de l’index entièrement qualifié est également affiché.
Plan de requête pour DML sur une table hybride¶
Les opérations DML sur les tables hybrides modifient généralement des lignes uniques. Par exemple :
UPDATE sensor_data_device2 SET device_id='DEVICE3' WHERE timestamp = '2024-04-02 00:00:05.000';
Le profil de requête pour l’opérateur TableScan montre que cette UPDATE accède au magasin de lignes pour la table hybride (le mode d’analyse est ROW_BASED) :
Requête récurrente qui bénéficie des données mises en cache¶
Dans ce cas, supposons que la requête suivante est exécutée deux fois de suite sur une table hybride.
SELECT device_id, AVG(temperature)
FROM sensor_data_device2
WHERE temperature>33
GROUP BY device_id;
La première requête lit toutes les données du stockage d’objets. La deuxième exécution de la requête lit 100 % des données du cache en colonnes. Notez également que le mode d’analyse pour cette requête est COLUMN_BASED.
Plan de requête pour une jointure (table hybride vers table standard)¶
Lorsque vous liez une table hybride à une table standard, vous voyez un attribut Scan Mode pour l’analyse sur la table hybride, mais pas sur la table standard. Par exemple, l’opérateur TableScan sur le côté gauche de ce plan de jointure a utilisé le mode d’analyse ROW_BASED. La table order_header est une table hybride avec order_id comme clé primaire (la colonne de jointure dans cet exemple). L’autre table, truck_history, est une table standard.
