Vues matérialisées dans Azure Cosmos DB for Apache Cassandra (préversion)

S’APPLIQUE À : Cassandra

Les vues matérialisées, quand elles sont définies, permettent d’interroger efficacement une table de base (ou un conteneur dans Azure Cosmos DB) avec des filtres qui ne sont pas des clés primaires. Quand les utilisateurs écrivent dans la table de base, la vue matérialisée est créée automatiquement en arrière-plan. Cette vue peut avoir une clé primaire distincte pour améliorer l’efficacité des recherches. La vue contient également uniquement les colonnes explicitement projetées à partir de la table de base. Cette vue est une table en lecture seule.

Vous pouvez interroger des données columnstore sans spécifier de clé de partition en utilisant des index secondaires. Toutefois, la requête ne sera pas efficace pour les colonnes ayant une cardinalité élevée ou faible. La requête peut analyser toutes les données à la recherche d’un petit jeu de résultats. De telles requêtes sont coûteuses, car elles finissent par s’exécuter en tant que requêtes interpartitions.

Avec une vue matérialisée, vous pouvez :

• Utiliser une table de recherche ou de mappage pour conserver les analyses interpartitions, qui sont des requêtes coûteuses.
• Fournir un prédicat conditionnel SQL pour remplir uniquement certaines colonnes et certaines données répondant à la condition préalable.
• Créer des vues en temps réel qui simplifient les scénarios basés sur les événements, généralement stockés sous forme de collections distinctes à l’aide de déclencheurs de flux de modification.

Avantages des vues matérialisées

Les vues matérialisées présentent de nombreux avantages (liste non exhaustive) :

• Vous pouvez implémenter la dénormalisation côté serveur à l’aide de vues matérialisées. Avec la dénormalisation côté serveur, vous pouvez éviter plusieurs tables indépendantes et une dénormalisation complexe sur le plan du calcul dans les applications clientes.
• Les vues matérialisées mettent à jour automatiquement les vues pour qu’elles restent cohérentes par rapport à la table de base. Cette mise à jour automatique extrait les responsabilités de vos applications clientes, et implémente généralement une logique personnalisée pour effectuer des écritures en double dans la table de base et la vue.
• Les vues matérialisées optimisent les performances de lecture en lisant à partir d’une seule vue.
• Vous pouvez spécifier le débit de la vue matérialisée de manière indépendante.
• Vous pouvez configurer une couche du générateur de vues matérialisées pour qu’elle corresponde à vos besoins au niveau de l’hydratation d’une vue.
• Les vues matérialisées améliorent les performances d’écriture, car les opérations d’écriture doivent uniquement être écrites dans la table de base.
• De plus, l’implémentation des vues matérialisées par Azure Cosmos DB est basée sur un modèle d’extraction. Cette implémentation n’affecte pas les performances d’écriture.

Bien démarrer avec les vues matérialisées

Créez des comptes d’API pour Cassandra à l’aide d’Azure CLI afin d’activer la fonctionnalité des vues matérialisées avec une commande native ou une opération d’API REST.

Sous le capot

L’API pour Cassandra utilise une couche de calcul du générateur de vues matérialisées afin de gérer les vues.

Vous pouvez configurer les instances de calcul du générateur de vues en fonction de vos impératifs de latence et de décalage pour hydrater les vues. D’un point de vue technique, cette couche de calcul permet de gérer les connexions entre les partitions de manière plus efficace, même quand la taille des données est importante et que le nombre de partitions est élevé.

Les conteneurs de calcul sont partagés entre toutes les vues matérialisées d’un compte Azure Cosmos DB. Chaque conteneur de calcul provisionné génère plusieurs tâches qui lisent le flux de modification des partitions de table de base, et écrit les données dans les vues matérialisées cibles. Le conteneur de calcul transforme les données en fonction de la définition de vue matérialisée de chaque vue matérialisée du compte.

Créer un générateur de vues matérialisées

Créez un générateur de vues matérialisées pour transformer automatiquement les données et écrire dans une vue matérialisée.

Créer une vue matérialisée

Une fois votre compte et le Générateur de vues matérialisés configurés, vous devez pouvoir créer des vues matérialisées en utilisant CQLSH.

Voici quelques exemples de commandes pour créer une vue matérialisée :

1. Commencez par créer le nom d’espace de clésuprofile.

   CREATE KEYSPACE IF NOT EXISTS uprofile WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'datacenter1' : 1 };
   

2. Créez ensuite une table nommée user dans l’espace de clés.

   CREATE TABLE IF NOT EXISTS uprofile.USER (user_id INT PRIMARY KEY, user_name text, user_bcity text);
   

3. À présent, créez une vue matérialisée nommée user_by_bcity dans le même espace de clés. Spécifiez, à l’aide d’une requête, la façon dont les données sont projetées dans la vue à partir de la table de base.

   CREATE MATERIALIZED VIEW uprofile.user_by_bcity AS 
   SELECT
       user_id,
       user_name,
       user_bcity 
   FROM
       uprofile.USER 
   WHERE
       user_id IS NOT NULL 
       AND user_bcity IS NOT NULL PRIMARY KEY (user_bcity, user_id);
   

4. Insérez des lignes dans la table de base.

   INSERT INTO
       uprofile.USER (user_id, user_name, user_bcity) 
   VALUES
       (
           101, 'johnjoe', 'New York' 
       );
   
   INSERT INTO
       uprofile.USER (user_id, user_name, user_bcity) 
   VALUES
       (
           102, 'james', 'New York' 
       );
   

5. Interrogez la vue matérialisée.

   SELECT * FROM user_by_bcity; 
   

6. Observez la sortie de la vue matérialisée.

    user_bcity | user_id | user_name 
   ------------+---------+----------- 
      New York |     101 |   johnjoe 
      New York |     102 |     james 
   
   (2 rows) 
   

Vous pouvez également utiliser le fournisseur de ressources pour créer ou mettre à jour une vue matérialisée.

• Créer ou mettre à jour une vue dans l’API pour Cassandra
• Obtenir une vue dans l’API pour Cassandra
• Lister les vues dans l’API pour Cassandra
• Supprimer une vue dans l’API pour Cassandra
• Mettre à jour le débit d’une vue dans l’API pour Cassandra

Limites actuelles

Il existe certaines limitations dans l’implémentation de la fonctionnalité en préversion des vues matérialisées de l’API pour Cassandra :

• Vous ne pouvez pas créer de vues matérialisées sur une table qui existait avant l’activation de la prise en charge des vues matérialisées pour le compte. Pour utiliser des vues matérialisées, créez une table après avoir activé la fonctionnalité.
• Pour la clause WHERE de la définition de vue matérialisée, seuls les filtres IS NOT NULL sont autorisés.
• Une fois qu’une vue matérialisée a été créée par rapport à une table de base, les opérations ALTER TABLE ADD ne sont plus autorisées sur le schéma de la table de base. ALTER TABLE APP est autorisé uniquement si aucune des vues matérialisées n’a sélectionné * dans sa définition.
• Il existe des limites relatives à la taille de la clé de partition (2 Ko) et à la taille totale de la clé de clustering (1 Ko). Si cette taille limite est dépassée, le message responsable se retrouve dans la file d’attente des messages incohérents.
• Si une table de base comporte des types définis par l’utilisateur (UDT), et si la définition de vue matérialisée contient SELECT * FROM ou le type défini par l’utilisateur dans l’une des colonnes projetées, les mises à jour du type défini par l’utilisateur ne sont pas autorisées sur le compte.
• Les vues matérialisées peuvent devenir incohérentes par rapport à la table de base pour certaines lignes après le basculement régional automatique. Pour éviter cette incohérence, recréez la vue matérialisée après le basculement.
• La création d’instances du générateur de vues matérialisées avec 32 cœurs n’est pas prise en charge. Si nécessaire, vous pouvez créer plusieurs instances du générateur avec un plus petit nombre de cœurs.

En plus des limitations ci-dessus, tenez compte des limitations supplémentaires suivantes :

• Zones de disponibilité
  • Vous ne pouvez pas utiliser de vues matérialisées sur un compte lié à des régions où la zone de disponibilité est activée.
  • L’ajout d’une nouvelle région avec une zone de disponibilité n’est pas pris en charge une fois que enableMaterializedViews a la valeur true pour le compte.
• Sauvegarde et restauration périodique
  • Les vues matérialisées ne sont pas restaurées automatiquement avec le processus de restauration. Vous devez recréer les vues matérialisées une fois le processus de restauration effectué. Vous devez ensuite configurer enableMaterializedViews sur le compte restauré avant de recréer les vues matérialisées et les générateurs.
• Apache cassandra
  • La définition d’une stratégie de résolution des conflits sur des vues matérialisées n’est pas autorisée.
  • Les opérations d’écriture ne sont pas autorisées sur les vues matérialisées.
  • Les requêtes interdocuments et l’utilisation de fonctions d’agrégation ne sont pas prises en charge sur les vues matérialisées.
  • Le schéma d’une vue matérialisée ne peut pas être modifié après sa création.
  • La suppression de la table de base n’est pas autorisée si au moins une vue matérialisée est définie sur celle-ci. Toutes les vues doivent d’abord être supprimées pour que la table de base puisse être supprimée.
  • La définition de vues matérialisées sur des conteneurs avec des colonnes statiques n’est pas autorisée.

Étapes suivantes