Vues matérialisées continues
Ce document présente les vues matérialisées continues et leurs cas d'utilisation courants. Avant de lire cette page, vous devez avoir lu la présentation de Bigtable overview.
Dans Bigtable, une vue matérialisée continue est le résultat d'un processus d'arrière-plan continu et entièrement géré. Ce processus utilise une requête SQL que vous fournissez pour créer et gérer une table précalculée que Bigtable met à jour de manière incrémentielle lorsque les données sources changent. La requête SQL peut inclure des agrégations et des transformations sur la table Bigtable sous-jacente.
Les données d'une vue matérialisée continue incluent les éléments suivants :
- Valeurs agrégées ou transformées dérivées des données de la table source
- Valeurs non agrégées qui définissent la clé de regroupement
Les vues matérialisées continues vous permettent de pré-agréger vos données au fur et à mesure de leur ingestion. De plus, une vue matérialisée continue possède un schéma différent de celui de sa table source. Elle présente les données de la table source dans une structure optimisée pour les requêtes avec des modèles de recherche différents de ceux utilisés sur la table source.
Voici les principales caractéristiques des vues matérialisées continues dans Bigtable :
- Aucune maintenance : une vue matérialisée continue est précalculée en arrière-plan. Les modifications apportées aux données de la table source, y compris les mises à jour et les suppressions, sont automatiquement propagées en arrière-plan à la vue matérialisée continue, sans aucune action de l'utilisateur.
- Modèles de développement SQL : les vues matérialisées continues sont basées sur GoogleSQL pour les requêtes Bigtable, y compris les fonctions, les filtres et les agrégations SQL.
- Synchronisation avec la récupération de mémoire : une vue matérialisée continue reste synchronisée avec les stratégies de récupération de mémoire de sa table source, et se met automatiquement à jour lorsque les données de la table expirent ou sont supprimées.
- La latence en lecture et en écriture n'est pas affectée : une vue matérialisée continue a un impact minimal sur les performances de la table source lorsque les clusters de l'instance sont correctement provisionnés ou utilisent l'autoscaling.
- Cohérence à terme : les vues matérialisées continues sont calculées en arrière-plan. Les mises à jour d'une vue matérialisée continue peuvent être retardées, mais les résultats matérialisés continus sont toujours cohérents au fil du temps.
La clé de ligne, le qualificatif de colonne et les valeurs de colonne que vous utilisez pour définir une vue matérialisée continue sont traités comme des données de service. Pour cette raison, ne créez pas de vue matérialisée continue à l'aide d'une clé de ligne, d'un qualificatif de colonne ou de valeurs de colonne contenant des informations sensibles. Pour en savoir plus sur le traitement des données de service, consultez l'Google Cloud Avis de confidentialité.
Vous pouvez créer une vue matérialisée continue à l'aide de Google Cloud CLI, de l' éditeur de requêtes Bigtable Studio dans la Google Cloud console ou des bibliothèques clientes Bigtable pour Java et Go.
Vous pouvez lire à partir d'une vue matérialisée continue en procédant comme suit :
- Éditeur de requêtes Bigtable Studio
- Bibliothèques clientes Bigtable compatibles avec les requêtes SQL
- Appel d'API
ReadRowsà l'aide des bibliothèques clientes Bigtable pour Java et Go
Pour en savoir plus, consultez la section Lire à partir d'une vue matérialisée continue.
Quand utiliser des vues matérialisées continues ?
Les vues matérialisées continues vous permettent de définir une nouvelle représentation de vos données Bigtable à l'aide de SQL. Une fois créée, une vue matérialisée continue restructure en permanence et automatiquement les données de la table source au format défini par la requête SQL. Ensuite, au lieu d'interroger votre table et de transformer ou d'agréger les données après les avoir lues, vous pouvez interroger la vue matérialisée continue.
Les vues matérialisées continues peuvent améliorer les performances des requêtes dans les cas d'utilisation suivants :
- Pré-agrégation des données : vous pouvez utiliser une vue matérialisée continue pour agréger les données entrantes sur plusieurs lignes. Cela vous permet de récupérer rapidement des données récapitulatives et agrégées, telles que des métriques pour les tableaux de bord.
- Automatisation des architectures lambda et kappa : si votre application nécessite un mélange de données de pipeline de streaming en temps réel et de données de pipeline par lot contenant des données historiques, utilisez des vues matérialisées continues. Ces vues fournissent une vue de toutes les sources de données qui est mise à jour au fil du temps pour refléter les modifications apportées aux données sous-jacentes, sans avoir besoin d'outils de traitement par flux supplémentaires ni de tâches ETL personnalisées.
- Modèles d'accès secondaires : les vues matérialisées continues créent une représentation alternative de vos données. Cette représentation peut être optimisée pour les requêtes avec des modèles de recherche différents de ceux que vous utilisez dans les requêtes sur la table source. Cela fait des vues matérialisées continues un outil puissant pour créer ce qui est effectivement un index secondaire asynchrone sur vos données. Pour en savoir plus sur ces modèles, consultez la section Créer un index secondaire asynchrone.
Pour comparer les vues matérialisées continues à d'autres types de vues Bigtable, consultez la section Tables et vues.
Quand utiliser des compteurs ?
Une autre façon de pré-agréger vos données consiste à créer des compteurs distribués à l'aide de cellules agrégées.
Les écritures dans les cellules agrégées sont immédiatement lisibles à partir du cluster dans lequel elles sont écrites. Les vues matérialisées continues sont traitées après l'écriture des données et finissent par devenir cohérentes avec la table source.
Utilisez des compteurs au lieu de vues matérialisées continues pour les éléments suivants :
- Agrégations qui ne nécessitent pas de filtres et qui n'ont pas besoin d'être sur plusieurs lignes
- Si vous devez lire immédiatement vos écritures à partir du cluster dans lequel elles sont écrites
Utilisez des vues matérialisées continues lorsque vous souhaitez effectuer les opérations suivantes :
- Générer une clé différente pour les requêtes sur vos agrégations
- Afficher les modifications apportées à la table de base dans vos agrégations
- Combiner automatiquement des données sur plusieurs lignes
Utilisez une combinaison de compteurs et de vues matérialisées continues pour des cas d'utilisation tels que les suivants :
- Capturer des métriques récentes dans une cellule agrégée, mais conserver les cumuls historiques de ces métriques
- Combiner des métriques dans une vue matérialisée continue
Provisionnement des ressources et performances
Le traitement continu des vues matérialisées continues s'effectue en tant que tâche d'arrière-plan de faible priorité. Par conséquent, il a un impact minimal sur les performances de l'application, ainsi que sur la latence en lecture et en écriture sur la table source, à condition que vos clusters soient correctement dimensionnés.
Pour vous assurer que les données de la vue matérialisée continue restent à jour, activez l'autoscaling pour les clusters de l'instance contenant votre vue matérialisée continue. L'autoscaling ajoute automatiquement suffisamment de nœuds pour gérer la surcharge de traitement, puis les supprime lorsqu'ils ne sont plus nécessaires. Cela permet de s'assurer qu'une capacité de calcul suffisante est disponible lors de l'exécution de la requête SQL continue. L'autoscaling peut également vous assurer que vous disposez de suffisamment de nœuds pour répondre aux besoins de stockage de vos vues matérialisées continues.
Les vues matérialisées continues sont comptabilisées dans la limite de 1 000 tables par instance .
Créer des vues matérialisées continues sur des tables existantes
Lorsque vous créez une vue matérialisée continue pour une table existante, Bigtable démarre un processus unique qui remplit la vue avec les données de la table existante. Le temps nécessaire à ce remplissage initial dépend de la taille de la table et de la complexité de la requête. Pendant ce temps, la vue n'est pas disponible pour les requêtes. Ce remplissage initial des données s'exécute en tant que tâche d'arrière-plan de faible priorité afin de minimiser l'effet sur les performances de votre cluster. Pour les grandes tables, vous pouvez ajouter temporairement des nœuds à votre cluster afin d'accélérer la création de la vue.
Le schéma suivant illustre le processus de création de vues matérialisées continues :
Supposons, par exemple, que votre table source contienne des lignes avec des clés qui suivent le modèle advertiser_id#region#ad_id et une famille de colonnes, data, qui inclut un qualificatif de colonne spend_usd avec des données numériques représentant les dépenses publicitaires :
| Clé de ligne | data:spend_usd |
|---|---|
adv1#us-east#ad1 |
100 |
adv1#us-west#ad2 |
150 |
adv2#us-east#ad3 |
200 |
Si vous utilisez la requête suivante pour définir une vue matérialisée continue de cette table, le remplissage initial de 1 To de données s'effectue en environ trois heures sur un cluster de 175 nœuds.
SELECT
SPLIT(_key, "#")[SAFE_OFFSET(0)] AS advertiser_id,
count(*) AS count,
sum(cast(cast(data['spend_usd'] as string) as int64)) as sum_spend
FROM `$0`
GROUP BY advertiser_id
Étant donné que Bigtable effectue un scaling linéaire, un cluster de 175 nœuds traite 2 To de données en environ six heures et 10 To en environ 30 heures, en supposant que les données ont une forme similaire. Pour réduire le temps nécessaire au remplissage initial, vous pouvez temporairement ajouter temporairement des nœuds à votre cluster ou, si vous utilisez l'autoscaling, temporairement augmenter le nombre maximal de nœuds.
Stockage
Pour chaque vue matérialisée continue, Bigtable stocke les éléments suivants :
- Les données de la vue matérialisée continue
- Le stockage intermédiaire
Comme toute table Bigtable, une vue matérialisée continue existe sur tous les clusters de l'instance qui la contient. Les clusters de votre instance doivent disposer de suffisamment de nœuds pour stocker la table source et toutes les vues matérialisées continues basées sur la table. L'autoscaling permet à vos clusters de faire évoluer leur taille en fonction des besoins de stockage.
Une vue matérialisée continue doit être créée dans la même instance que la table source, même si le stockage de la vue matérialisée continue est distinct de celui de la table source.
Stockage des vues matérialisées continues
Une vue matérialisée continue contient des données résultant de la requête SQL sur laquelle elle est basée. Cela signifie qu'elle contient des valeurs agrégées définies par des clauses d'agrégation dans la requête SQL et des valeurs non agrégées qui définissent la clé de regroupement.
Stockage intermédiaire
Pour prendre en charge la synchronisation d'une vue matérialisée continue avec sa table source, Bigtable utilise le stockage intermédiaire pour stocker des copies des données dont il a besoin pour mettre à jour de manière incrémentielle la vue matérialisée continue.
La quantité de données dans le stockage intermédiaire est à peu près équivalente à la quantité de données analysées dans la table source pour générer le résultat de la requête SQL qui définit la vue matérialisée continue. Par exemple, si votre requête agrège des données sur l'ensemble de la table, Bigtable conserve l'équivalent de la table entière dans le stockage intermédiaire. Une vue matérialisée continue basée sur une requête de plages de clés de ligne ou de colonnes spécifiques ne conserve que ces lignes ou colonnes dans le stockage intermédiaire.
Le stockage intermédiaire persiste pendant la durée de vie de la vue matérialisée continue pour prendre en charge efficacement les mises à jour incrémentielles de la vue et propager les suppressions de la table source à la vue matérialisée continue. Vous ne pouvez pas lire les données dans le stockage intermédiaire. Pour obtenir des insights sur votre utilisation de l'espace de stockage intermédiaire, consultez la section Métriques des vues matérialisées continues.
Réplication
Dans les instances qui utilisent la réplication, les vues matérialisées continues ne sont pas répliquées de la même manière que les tables. Au lieu de cela, chaque cluster d'une instance traite la vue matérialisée continue indépendamment, à l'aide de sa propre copie de la table source. Cela signifie, par exemple, que les données écrites dans une table source sur le cluster A sont répliquées dans la table du cluster B, puis dans la vue matérialisée continue du cluster B.
Coûts
L'utilisation de vues matérialisées continues n'entraîne aucun coût par ressource. Toutefois, la création et la synchronisation de vues matérialisées continues nécessitent un traitement et un stockage, et vous êtes facturé aux tarifs standards. Vous pouvez vous attendre à une augmentation des éléments suivants lorsque vous créez une vue matérialisée continue :
- Stockage : vous êtes facturé pour le stockage des données dans la vue matérialisée continue et pour le stockage intermédiaire. Pour en savoir plus, consultez la section Stockage.
- Calcul : la synchronisation continue de la table source et de la vue matérialisée continue nécessite un traitement du processeur, et vos clusters peuvent avoir besoin de plus de nœuds pour gérer le travail d'arrière-plan supplémentaire.
En même temps, vous pouvez constater une diminution du traitement sur la table source, par exemple lorsque vous n'effectuez plus d'analyses de plage des données pour effectuer des calculs répétés et d'autres requêtes moins efficaces. Vous pouvez également éliminer la nécessité d'exécuter des tâches de pipeline, telles que Dataflow ou Spark, pour agréger les données sources et les réécrire dans Bigtable.
Pour en savoir plus sur les tarifs, consultez la page Tarifs de Bigtable. Pour obtenir des métriques qui peuvent vous aider à surveiller l'utilisation de votre vue matérialisée continue, consultez la section Métriques.
Métriques
Une vue matérialisée continue signale plusieurs métriques clés à Cloud Logging que vous pouvez utiliser pour surveiller vos vues matérialisées continues.
| Métrique | Description |
|---|---|
materialized_view/max_delay |
Limite supérieure du délai de traitement pour la vue matérialisée continue |
materialized_view/storage |
Quantité de données utilisées pour le stockage de la vue matérialisée continue en octets |
materialized_view/intermediate_storage |
Quantité de données utilisées par le traitement intermédiaire pour la vue matérialisée continue en octets |
table/materialized_view_intermediate_storage |
Quantité de données utilisées par le traitement intermédiaire pour les vues matérialisées continues définies dans cette table |
materialized_view/user_errors |
Nombre d'erreurs provenant des données utilisateur pour la vue matérialisée continue. Les erreurs utilisateur empêchent la propagation des données à la vue. |
materialized_view/system_errors |
Nombre d'erreurs provenant du système pour la vue matérialisée continue |
Vous pouvez également utiliser de nombreuses métriques de table Bigtable pour surveiller une vue matérialisée continue, en utilisant l'ID de la vue matérialisée continue à la place de l'ID de la table. En particulier, les vues matérialisées continues sont incluses dans
la répartition des métriques du processeur, ce qui
peut vous aider à comprendre leur impact. Les métriques Bigtable pour les requêtes par seconde, la latence et le débit sont générées lorsque vous lisez une vue matérialisée continue à l'aide de la méthode ReadRows de l'API Data. Pour en savoir plus, consultez l'article Métriques.
Pour commencer à utiliser Cloud Logging, consultez la présentation Interroger et afficher les journaux.
Limites
- Vous pouvez créer jusqu'à 50 vues matérialisées continues par instance.
- Vous pouvez créer jusqu'à cinq vues matérialisées continues par table. Si nécessaire, vous pouvez demander une augmentation de cette limite en contactant Cloud Customer Care.
- Lorsque vous créez une vue sans
_keyspécifiée, les colonnes sélectionnées dans la table source ne doivent pas êtreNULL. Pour en savoir plus, consultez la section Clés de ligne définies parGROUP BYclause. - Vous ne pouvez pas modifier la requête SQL qui définit une vue matérialisée continue. Vous devez supprimer la vue matérialisée continue et en créer une avec vos modifications.
- Vous ne pouvez pas créer de vue matérialisée continue d'une autre vue matérialisée continue ou d'une vue logique.
- Vous ne pouvez pas configurer de stratégies de récupération de mémoire pour une vue matérialisée continue. Toutes les règles de conservation des données sont régies par les stratégies de récupération de mémoire de la table source, et la récupération de mémoire de la source est automatiquement reflétée dans la vue matérialisée continue.
Étape suivante
- Requête de vue matérialisée continue
- Créer et gérer des vues matérialisées continues
- Créer un index secondaire asynchrone
- Bonnes pratiques relatives à la conception de schémas
- Comptage distribué dans Bigtable