Cette page a été traduite par l'API Cloud Translation.

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 l'application. 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 et n'est pas recommandé pour les lectures d'une seule ligne. Vous ne pouvez pas utiliser Data Boost pour les analyses inverses. 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 sur 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, soit en spécifiant un préfixe de clé de ligne, soit en spécifiant une plage de lignes. Le préfixe de la clé de ligne est utilisé comme point de départ de l'analyse pour lire à rebours. 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 rechercher 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 à l'aide d'un code temporel comme suffixe de clé de ligne.

Les analyses inversées sont moins efficaces que les analyses directes. En règle générale, concevez vos clés de ligne de sorte que la plupart des analyses soient en avant. Utilisez des analyses inversées pour les analyses courtes, par exemple 50 lignes ou moins, afin de maintenir un temps de réponse à faible latence.

Pour effectuer une analyse à l'envers, définissez la valeur du champ ReadRowsRequest reversed sur "true". La valeur par défaut est "false".

Les analyses inverses 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 obtenir des exemples de code montrant comment utiliser les analyses inversées, consultez Analyser à l'envers.

Exemples de cas d'utilisation

Les exemples suivants montrent comment les analyses inverses 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

Supposons que 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 rechercher les fluctuations de prix autour du prix du 14 février 2023, même si une clé de ligne pour cette date particulière n'existe pas dans le tableau, vous pouvez effectuer une analyse avant à partir de la clé de ligne productA#model2#1676376000 pour un nombre N de lignes, puis une analyse inverse 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'une des méthodes suivantes:

CLI gcloud
Client Bigtable pour Java

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

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

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 :

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.
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.
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 limite la taille d'une ligne à 256 Mo, mais il est possible de dépasser accidentellement cette limite maximale. 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.