Lectures

Cette page décrit les types de requêtes de lecture que vous pouvez envoyer à Bigtable, traite des implications 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 tâches et des requêtes de lecture par lot sans affecter le trafic quotidien des applications. Data Boost est un service de calcul sans serveur qui vous permet de 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 sur une seule ligne. 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 sur une seule ligne, également appelées lectures de points, 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 en sens inverse 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 lire en sens inverse. 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 cas suivants:

Vous souhaitez rechercher un événement (ligne), puis lire le nombre N précédent d'événements.
Vous devez déterminer 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 horodatage comme suffixe de clé de ligne.

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

Pour effectuer une analyse inversée, définissez la valeur reversed du champ ReadRowsRequest 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++ 2.18.0 ou version ultérieure
Bibliothèque cliente Bigtable pour Go 1.21.0 ou version ultérieure
Bibliothèque cliente Bigtable pour Java 2.24.1 ou version 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 la section Analyser en sens inverse.

Exemples de cas d'utilisation

Les exemples suivants montrent comment utiliser les analyses inversées pour connaître la dernière fois qu'un client a modifié son mot de passe et les fluctuations de prix d'un produit au cours d'une journée donnée.

Réinitialisation 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 soit password_reset, qui stocke l'heure à laquelle le mot de passe a été réinitialisé. Bigtable stocke automatiquement les données de manière lexicographique, comme suit : Notez que cette 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`

Pour savoir quand le client 123ABC a réinitialisé son mot de passe pour la dernière fois, vous pouvez effectuer une analyse inversée d'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 1.

Changements de prix

Dans cet exemple, vos clés de ligne contiennent des valeurs pour le produit, le modèle et l'horodatage, 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 identifier les fluctuations de prix autour du 14 février 2023, même s'il n'existe pas de clé de ligne pour cette date particulière dans la table, vous pouvez effectuer une analyse ascendante à partir de la clé de ligne productA#model2#1676376000 pour N nombre de lignes, puis effectuer une analyse inversée pour le même nombre de lignes à partir de la même ligne de départ. Les deux analyses vous donnent les prix avant et après l'heure indiqué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 des données à partir d'une vue autorisée

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

gcloud CLI
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 compatible. Vous devez fournir l'ID de la vue autorisée en plus de l'ID de la 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 nécessitant des conditions, des entrelacements ou des expressions régulières correspondant à des valeurs volumineuses ont tendance à 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.