Amazon Redshift ne prendra plus en charge la création de nouveaux Python à UDFs partir du patch 198. UDFs Le Python existant continuera de fonctionner jusqu'au 30 juin 2026. Pour plus d’informations, consultez le [ billet de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Type de données SUPER avec des vues matérialisées Avec Amazon Redshift, vous pouvez utiliser des vues matérialisées pour améliorer les performances et la flexibilité des requêtes exécutées sur le type de données SUPER. Le type de données SUPER vous permet de stocker un sur-ensemble de colonnes provenant des tables de base dans une vue matérialisée, ce qui vous permet d’interroger directement la vue matérialisée sans joindre les tables de base. Les sections suivantes expliquent comment créer et utiliser des vues matérialisées avec le type de données SUPER dans Amazon Redshift. Amazon Redshift prend en charge les vues matérialisées qui incorporent des colonnes ayant le type de données SUPER et des requêtes PartiQL. Les vues matérialisées peuvent être actualisées de manière incrémentielle, tandis qu’Amazon Redshift met uniquement à jour les données modifiées dans les tables de base depuis la dernière opération d’actualisation. Cette approche de mise à jour sélective rend le processus d’actualisation plus efficace que les recalculs complets. Pour plus d’informations sur les vues matérialisées, consultez [Vues matérialisées dans Amazon Redshift](materialized-view-overview.md). ## Accélération des requêtes PartiQL Vous pouvez utiliser les vues matérialisées pour accélérer les requêtes PartiQL qui parcourent et/ou désimbriquent les données hiérarchiques dans les colonnes SUPER. En créant une ou plusieurs vues matérialisées pour fragmenter les valeurs SUPER en plusieurs colonnes et utiliser l’organisation en colonnes des requêtes analytiques Amazon Redshift, vous pouvez extraire et normaliser essentiellement les données imbriquées. Le niveau de normalisation dépend de l’effort que vous déployez pour transformer les données SUPER en données colonnaires conventionnelles. Les rubriques suivantes présentent des exemples de décomposition ou de fragmentation de données complexes en colonnes plus petites, ainsi que de création de colonnes scalaires à partir de données déchiquetées pour améliorer les performances. **Topics** + [Accélération des requêtes PartiQL](#r_accelerate_mv) + [Fragmentation de données semi-structurées en colonnes SUPER avec des vues matérialisées](r_shred_super.md) + [Création de colonnes scalaires Amazon Redshift à partir de données fragmentées](r_create_scalar.md) # Fragmentation de données semi-structurées en colonnes SUPER avec des vues matérialisées Avec Amazon Redshift, vous pouvez améliorer les performances des requêtes en fragmentant les données dans des colonnes SUPER à l’aide de vues matérialisées. La fragmentation fait référence au processus qui consiste à décomposer des types de données complexes tels que des données semi-structurées JSON ou XML en colonnes plus petites et plus plates. Les colonnes SUPER sont une forme spécialisée de stockage en colonnes optimisée pour analyser rapidement les données fragmentées. Les sections suivantes décrivent les étapes et les considérations relatives à la fragmentation de données dans des colonnes SUPER à l’aide de vues matérialisées dans Amazon Redshift. L’exemple suivant montre une définition de vue matérialisée qui fragmente les données imbriquées, les colonnes résultantes étant toujours du type de données SUPER. ``` SELECT c.c_name, o.o_orderstatus FROM customer_orders_lineitem c, c.c_orders o; ``` L’exemple suivant illustre une définition de vue matérialisée qui crée des colonnes scalaires Amazon Redshift conventionnelles à partir des données fragmentées. ``` SELECT c.c_name, c.c_orders[0].o_totalprice FROM customer_orders_lineitem c; ``` Vous pouvez créer une vue matérialisée unique super\$1mv pour accélérer les deux requêtes. Pour répondre à la première requête, vous devez matérialiser l’attribut o\$1orderstatus. Vous pouvez omettre l’attribut c\$1name car il n’implique pas la navigation imbriquée ni la désimbrication. Vous devez également inclure dans la vue matérialisée l’attribut c\$1custkey de customer\$1orders\$1lineitem pour pouvoir joindre la table de base à la vue matérialisée. Pour répondre à la deuxième requête, vous devez également matérialiser l’attribut o\$1totalprice et l’index de tableau o\$1idx de c\$1orders. Ainsi, vous pouvez accéder à l’index 0 de c\$1orders. ``` CREATE MATERIALIZED VIEW super_mv distkey(c_custkey) sortkey(c_custkey) AS ( SELECT c_custkey, o.o_orderstatus, o.o_totalprice, o_idx FROM customer_orders_lineitem c, c.c_orders o AT o_idx ); ``` Les attributs o\$1orderstatus et o\$1totalprice de la vue matérialisée super\$1mv sont SUPER. La vue matérialisée super\$1mv sera actualisée de manière incrémentielle lors des modifications apportées à la table de base customer\$1orders\$1lineitem. ``` REFRESH MATERIALIZED VIEW super_mv; INFO: Materialized view super_mv was incrementally updated successfully. ``` Pour réécrire la première requête PartiQL en tant que requête SQL standard, joignez customer\$1orders\$1lineitem avec super\$1mv comme suit. ``` SELECT c.c_name, v.o_orderstatus FROM customer_orders_lineitem c JOIN super_mv v ON c.c_custkey = v.c_custkey; ``` De la même manière, vous pouvez réécrire la deuxième requête PartiQL. L’exemple suivant utilise un filtre sur o\$1idx = 0. ``` SELECT c.c_name, v.o_totalprice FROM customer_orders_lineitem c JOIN super_mv v ON c.c_custkey = v.c_custkey WHERE v.o_idx = 0; ``` Dans l’instruction CREATE MATERIALISED VIEW, spécifiez c\$1custkey comme clé de distribution et clé de tri pour super\$1mv. Amazon Redshift effectue une fusion efficace, en supposant que c\$1custkey est également la clé de distribution et la clé de tri de customer\$1orders\$1lineitem. Si ce n’est pas le cas, vous pouvez spécifier c\$1custkey comme clé de tri et clé de distribution de customer\$1orders\$1lineitem comme suit. ``` ALTER TABLE customer_orders_lineitem ALTER DISTKEY c_custkey, ALTER SORTKEY (c_custkey); ``` Utilisez l’instruction EXPLAIN pour vérifier qu’Amazon Redshift effectue une fusion sur les requêtes réécrites. ``` EXPLAIN SELECT c.c_name, v.o_orderstatus FROM customer_orders_lineitem c JOIN super_mv v ON c.c_custkey = v.c_custkey; QUERY PLAN ------------------------------------------------------------------------------------------------------ XN Merge Join DS_DIST_NONE (cost=0.00..34701.82 rows=1470776 width=27) Merge Cond: ("outer".c_custkey = "inner".c_custkey) -> XN Seq Scan on mv_tbl__super_mv__0 derived_table2 (cost=0.00..14999.86 rows=1499986 width=13) -> XN Seq Scan on customer_orders_lineitem c (cost=0.00..999.96 rows=99996 width=30) (4 rows) ``` # Création de colonnes scalaires Amazon Redshift à partir de données fragmentées Les données sans schéma stockées dans SUPER peuvent affecter les performances d’Amazon Redshift. Par exemple, les prédicats de filtrage ou les conditions de jointure en tant qu’analyse à plage restreinte ne peuvent pas utiliser efficacement les cartes de zone. Les utilisateurs et les outils BI peuvent utiliser des vues matérialisées comme présentation conventionnelle des données et augmenter les performances des requêtes analytiques. La requête suivante analyse la vue matérialisée `super_mv` et les filtres sur `o_orderstatus`. ``` SELECT c.c_name, v.o_totalprice FROM customer_orders_lineitem c JOIN super_mv v ON c.c_custkey = v.c_custkey WHERE v.o_orderstatus = 'F'; ``` Inspectez `stl_scan` pour vérifier que Amazon Redshift ne peut effectivement pas utiliser les cartes de zone sur le scan à plage restreinte sur `o_orderstatus`. ``` SELECT slice, is_rrscan FROM stl_scan WHERE query = pg_last_query_id() AND perm_table_name LIKE '%super_mv%'; slice | is_rrscan -------+----------- 0 | f 1 | f 5 | f 4 | f 2 | f 3 | f (6 rows) ``` L’exemple suivant adapte la vue matérialisée `super_mv` pour créer des colonnes scalaires à partir des données fragmentées. Dans ce cas, Amazon Redshift convertit `o_orderstatus` de SUPER à VARCHAR. En outre, spécifiez `o_orderstatus` comme clé de tri pour `super_mv`. ``` CREATE MATERIALIZED VIEW super_mv distkey(c_custkey) sortkey(c_custkey, o_orderstatus) AS ( SELECT c_custkey, o.o_orderstatus::VARCHAR AS o_orderstatus, o.o_totalprice, o_idx FROM customer_orders_lineitem c, c.c_orders o AT o_idx ); ``` Après avoir réexécuté la requête, vérifiez qu’Amazon Redshift peut désormais utiliser des cartes de zones. ``` SELECT v.o_totalprice FROM super_mv v WHERE v.o_orderstatus = 'F'; ``` Vous pouvez vérifier que l’analyse à plage restreinte utilise désormais les cartes de zones comme suit. ``` SELECT slice, is_rrscan FROM stl_scan WHERE query = pg_last_query_id() AND perm_table_name LIKE '%super_mv%'; slice | is_rrscan -------+----------- 0 | t 1 | t 2 | t 3 | t 4 | t 5 | t (6 rows) ```