Lectures

Cette page décrit les types de requêtes de lecture que vous pouvez envoyer à Bigtable, traite des conséquences sur les performances et présente quelques recommandations pour des types de requêtes spécifiques. Avant de lire cette page, vous devez avoir lu la présentation de Bigtable.

Présentation

Les requêtes de lecture vers Bigtable renvoient le contenu des lignes demandées dans l'ordre des clés, ce qui signifie qu'elles sont renvoyées dans l'ordre dans lequel elles sont stockées. Vous pouvez lire toutes les écritures qui ont renvoyé une réponse.

Les requêtes compatibles avec votre table devraient vous aider à déterminer le type de lecture le mieux adapté à votre cas d'utilisation. Les requêtes de lecture de Bigtable appartiennent à deux catégories générales :

  • Lire une seule ligne
  • Analyses ou lecture de plusieurs lignes

Les lectures sont atomiques au niveau de la ligne. Cela signifie que lorsque vous envoyez une requête de lecture pour une ligne, Bigtable renvoie la ligne entière ou, en cas d'échec de la requête, aucune ligne. Une ligne partielle n'est jamais renvoyée, sauf si vous en faites la demande expresse.

Nous vous recommandons vivement d'utiliser nos bibliothèques clientes Cloud Bigtable pour lire les données d'une table au lieu d'appeler directement l'API. Des exemples de code montrant comment envoyer des requêtes de lecture sont disponibles dans plusieurs langues. Toutes les requêtes de lecture effectuent l'appel d'API ReadRows.

Lire des données avec le calcul sans serveur Data Boost

Bigtable Data Boost vous permet d'exécuter des requêtes et des jobs de lecture par lot sans affecter le trafic quotidien de vos applications. Data Boost est un service de calcul sans serveur que vous pouvez utiliser pour lire vos données Bigtable pendant que votre application principale utilise les nœuds de votre cluster pour le calcul.

Data Boost est idéal pour les analyses, mais n'est pas recommandé pour les lectures de lignes uniques. Vous ne pouvez pas utiliser Data Boost pour les analyses inversées. Pour en savoir plus et connaître les critères d'éligibilité, consultez la présentation de Data Boost.

Lectures sur une seule ligne

Vous pouvez demander une seule ligne en fonction de la clé de ligne. Les lectures d'une seule ligne, également appelées lectures ponctuelles, ne sont pas compatibles avec Data Boost. Des exemples de code sont disponibles pour les variantes suivantes :

Analyses

Les analyses constituent le moyen le plus courant de lire des données Bigtable. Vous pouvez lire une plage de lignes contiguës ou plusieurs plages de lignes de Bigtable, en spécifiant un préfixe de clé de ligne ou des clés de ligne de début et de fin. Des exemples de code sont disponibles pour les variantes suivantes :

Analyses inversées

Les analyses inversées vous permettent de lire une plage de lignes à l'envers en spécifiant un préfixe de clé de ligne ou une plage de lignes. Le préfixe de clé de ligne est utilisé comme point de départ de l'analyse pour la lecture à l'envers. Si vous spécifiez une plage de lignes, la clé de ligne de fin est utilisée comme point de départ de l'analyse.

L'analyse dans l'ordre inverse peut être utile dans les scénarios suivants :

  • Vous souhaitez trouver un événement (ligne), puis lire les N événements précédents.
  • Vous souhaitez trouver la valeur la plus élevée avant une valeur donnée. Cela peut être utile lorsque vous stockez des données de séries temporelles en utilisant un code temporel comme suffixe de clé de ligne.

Les analyses inversées sont moins efficaces que les analyses directes. En général, concevez vos clés de ligne de sorte que la plupart des analyses soient effectuées vers l'avant. Utilisez des analyses inversées pour les analyses courtes, telles que 50 lignes ou moins, afin de maintenir un temps de réponse à faible latence.

Pour effectuer une analyse inversée, définissez la valeur du champ ReadRowsRequest reversed sur "true". La valeur par défaut est "false".

Les analyses inversées sont disponibles lorsque vous utilisez les bibliothèques clientes suivantes :

  • Bibliothèque cliente Bigtable pour C++ version 2.18.0 ou ultérieure
  • Bibliothèque cliente Bigtable pour Go version 1.21.0 ou ultérieure
  • Bibliothèque cliente Bigtable pour Java version 2.24.1 ou ultérieure
  • Client Bigtable HBase pour Java version 2.10.0 ou ultérieure

Pour des exemples de code montrant comment utiliser les analyses inversées, consultez Analyse inversée.

Exemples de cas d'utilisation

Les exemples suivants montrent comment les analyses inversées peuvent être utilisées pour trouver la dernière fois qu'un client a modifié son mot de passe et les fluctuations de prix d'un produit autour d'un jour donné.

Réinitialisations du mot de passe

Prenons l'exemple d'une hypothèse selon laquelle vos clés de ligne contiennent chacune un ID client et une date au format 123ABC#2022-05-02, et que l'une des colonnes, password_reset, enregistre l'heure de réinitialisation du mot de passe. Bigtable stocke automatiquement les données de façon lexicographique, comme suit. Notez que la colonne n'existe pas pour les lignes (jours) où le mot de passe n'a pas été réinitialisé.

`123ABC#2022-02-12,password_reset:03`
`123ABC#2022-04-02,password_reset:11`
`123ABC#2022-04-14`
`123ABC#2022-05-02`
`223ABC#2022-05-22`

Si vous recherchez la dernière fois que le client 123ABC a réinitialisé son mot de passe, vous pouvez analyser à l'envers une plage de 123ABC# à 123ABC#<DATE>, en utilisant la date du jour ou une date ultérieure, pour toutes les lignes contenant la colonne password_reset avec une limite de ligne de 1.

Changements de prix

Dans cet exemple, vos clés de ligne contiennent des valeurs pour le produit, le modèle et le code temporel, et l'une des colonnes contient le prix du produit et du modèle à un moment donné.

`productA#model2#1675604471,price:82.63`
`productA#model2#1676219411,price:82.97`
`productA#model2#1677681011,price:83.15`
`productA#model2#1680786011,price:83.99`
`productA#model2#1682452238,price:83.12`

Si vous souhaitez trouver les fluctuations de prix autour du prix du 14 février 2023, même si une clé de ligne pour cette date spécifique n'existe pas dans la table, vous pouvez effectuer une analyse vers l'avant à partir de la clé de ligne productA#model2#1676376000 pour un nombre N de lignes, puis effectuer une analyse vers l'arrière pour le même nombre de lignes à partir de la même ligne de départ. Les deux analyses vous indiquent les prix avant et après l'heure donnée.

Lectures filtrées

Si vous avez uniquement besoin de lignes contenant des valeurs spécifiques ou partielles, vous pouvez utiliser un filtre dans votre requête de lecture. Les filtres vous permettent d'être très sélectif dans les données que vous souhaitez obtenir.

Les filtres vous permettent également de vous assurer que les lectures correspondent aux règles de récupération de mémoire utilisées par votre table. Cela est particulièrement utile si vous écrivez fréquemment de nouvelles cellules horodatées dans des colonnes existantes. La récupération de mémoire peut prendre jusqu'à une semaine pour supprimer les données arrivées à expiration. Par conséquent, l'utilisation d'un filtre de plage d'horodatages pour lire les données peut vous assurer de ne pas lire plus de données que nécessaire.

La présentation des filtres fournit des explications détaillées sur les types de filtres que vous pouvez utiliser. L'option Utiliser des filtres affiche des exemples dans plusieurs langues.

Lire les données d'une vue autorisée

Pour lire les données d'une vue autorisée, vous devez utiliser l'un des éléments suivants :

  • CLI gcloud
  • Client Bigtable pour Java

Les autres bibliothèques clientes Bigtable ne sont pas encore compatibles avec l'accès en lecture.

Toute méthode qui appelle la méthode ReadRows ou SampleRowKeys de l'API Bigtable Data est acceptée. Vous fournissez l'ID de la vue autorisée en plus de l'ID de la table lorsque vous créez votre client.

Lire les données d'une vue matérialisée continue

Vous pouvez lire les données d'une vue matérialisée continue à l'aide de SQL ou de l'appel d'API Data ReadRows. Les vues matérialisées continues sont en lecture seule. Les données d'une vue matérialisée sont typées en fonction de la requête qui la définit.

SQL

Pour lire des données à partir d'une vue matérialisée continue à l'aide de SQL, vous pouvez utiliser l'éditeur de requêtes Bigtable Studio ou l'une des bibliothèques clientes compatibles avec les requêtes SQL.

SQL expose automatiquement les résultats des requêtes sous forme de colonnes typées. Il n'est donc pas nécessaire de gérer l'encodage dans votre requête.

Lorsque vous créez une vue matérialisée continue, Bigtable crée automatiquement un schéma de clé de ligne pour la table qui définit les clés de ligne structurées pour la vue. Pour en savoir plus sur l'interrogation des clés de ligne structurées avec SQL, consultez Requêtes de clés de ligne structurées.

API Data

Si vous prévoyez de lire des données à partir d'une vue matérialisée continue avec un appel ReadRows depuis l'une des bibliothèques clientes pour Bigtable, vous devez examiner la requête SQL utilisée pour définir la vue. Notez si la vue comporte une colonne _key définie (recommandée pour les vues destinées à être lues à l'aide de ReadRows) et si elle comporte une colonne _timestamp.

Vous devez également connaître le type de chaque colonne et décoder les données de colonne dans le code de votre application.

Les valeurs agrégées d'une vue matérialisée continue sont stockées à l'aide de l'encodage décrit dans le tableau suivant, en fonction du type de sortie de la colonne de la définition de la vue.

Type Encodage
BOOL Valeur de 1 octet, 1 = vrai, 0 = faux
BYTES Aucun encodage
INT64 (ou INT, SMALLINT, INTEGER, BIGINT, TINYINT, BYTEINT) 64 bits big-endian
FLOAT64 IEEE 754 64 bits, à l'exclusion de NaN et de +/-inf
STRING UTF-8
TIME/TIMESTAMP Nombre entier de 64 bits représentant le nombre de microsecondes écoulées depuis l'époque Unix (compatible avec GoogleSQL)
Pour en savoir plus, consultez Encodage dans la documentation de référence de l'API Data.

En plus de connaître le type de chaque colonne de la vue, vous devez connaître la famille de colonnes et le qualificatif de colonne. La famille de colonnes par défaut est appelée default, et le qualificatif de colonne est l'alias spécifié dans la requête de définition. Prenons l'exemple d'une vue matérialisée continue définie avec cette requête :

SELECT
  _key,
  SUM(clicks) AS sum_clicks
FROM
  mytable
GROUP BY
  sum_clicks

Lorsque vous interrogez la vue avec ReadRows, vous fournissez la famille de colonnes default et le qualificatif de colonne sum_clicks.

Lectures et performances

Les lectures qui utilisent des filtres sont plus lentes que les lectures sans filtres et augmentent l'utilisation du processeur. En revanche, elles peuvent réduire considérablement la quantité de bande passante réseau que vous utilisez, en limitant la quantité de données renvoyées. En général, les filtres doivent être utilisés pour contrôler l'efficacité du débit, et non la latence.

Si vous souhaitez optimiser vos performances de lecture, envisagez les stratégies suivantes :

  1. Limitez autant que possible le nombre de lignes. Limiter le nombre de lignes que vos nœuds doivent analyser est la première mesure à prendre pour améliorer le délai de transmission du premier octet et la latence globale de la requête. Si vous ne limitez pas l'ensemble de lignes, Bigtable devra probablement analyser l'intégralité de la table. C'est pourquoi nous vous recommandons de concevoir votre schéma pour que vos requêtes les plus courantes fonctionnent de cette manière.

  2. Pour optimiser davantage les performances après avoir restreint le nombre de lignes, essayez d'ajouter un filtre de base. Le fait de limiter l'ensemble de colonnes ou le nombre de versions renvoyées n'augmente généralement pas la latence et peut parfois aider Bigtable à rechercher plus efficacement des données antérieures non pertinentes dans chaque ligne.

  3. Si vous souhaitez affiner encore plus vos performances de lecture après les deux premières stratégies, envisagez d'utiliser un filtre plus complexe. Vous pourriez tenter ceci pour plusieurs raisons :

    • Vous obtenez encore beaucoup de données dont vous n'avez pas besoin.
    • Vous souhaitez simplifier votre code d'application en poussant la requête dans Bigtable.

    Sachez toutefois que les filtres qui mettent en correspondance des conditions, des entrelacements ou des expressions régulières sur des valeurs volumineuses risquent de faire plus de mal que de bien s'ils laissent passer la plupart des données analysées. Ce problème se traduit par une utilisation accrue du processeur dans votre cluster sans grandes économies côté client.

Outre ces stratégies, évitez de lire un grand nombre de plages de lignes ou de plages de lignes non contiguës dans une seule requête de lecture. Lorsque vous demandez des centaines de clés de ligne ou de plages de lignes dans une seule requête, Bigtable analyse la table et lit les lignes demandées de manière séquentielle. Ce manque de parallélisme affecte la latence globale, et toutes les lectures qui atteignent un nœud à chaud peuvent augmenter la latence de queue. Plus le nombre de plages de lignes demandées est élevé, plus la lecture prend du temps. Si cette latence n'est pas acceptable, vous devez envoyer plusieurs requêtes simultanées qui récupèrent chacune moins de plages de lignes.

En général, la lecture d'un plus grand nombre de plages de lignes dans une seule requête optimise le débit, mais pas la latence. La lecture d'un nombre réduit de plages de lignes dans plusieurs requêtes simultanées optimise la latence, mais pas le débit. Pour trouver le bon équilibre entre la latence et le débit, il dépend des exigences de votre application et peut être obtenu en ajustant le nombre de requêtes de lecture simultanées et le nombre de plages de lignes dans une seule requête.

Lignes volumineuses

Bigtable applique les limites suivantes aux grandes lignes :

  • La taille maximale d'une ligne est de 256 Mo. Si vous devez lire une ligne qui dépasse la limite, vous pouvez paginer votre requête et utiliser un filtre cells per row limit et un filtre cells per row offset. Sachez que si une écriture arrive pour la ligne entre les demandes de lecture paginées, la lecture risque de ne pas être atomique.

  • La taille maximale d'un appel d'API ReadRows est de 512 Ko. Si vous dépassez la limite, Bigtable renvoie une erreur INVALID_ARGUMENT.

Étapes suivantes