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, décrit les implications en termes de performances et présente un 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 jobs de lecture par lot et des requêtes sans affecter le trafic quotidien des applications. Data Boost est de calcul sans serveur permettant de lire vos données Bigtable pendant que l'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 inverses. Pour en savoir plus et d'éligibilité, consultez le webinaire Data Boost présentation.

Lectures sur une seule ligne

Vous pouvez demander une seule ligne en fonction de la clé de ligne. Les lectures à ligne unique en tant que 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 :

Recherches inversées

Les analyses inversées vous permettent de lire une plage de lignes vers l'arrière en spécifiant une ligne un préfixe de clé ou une plage de lignes. Le préfixe de clé de ligne est utilisé comme pour lire vers l'arrière. Si vous spécifiez une plage de lignes, la clé de ligne de fin est utilisée comme le 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 de événements.
Vous souhaitez trouver la valeur la plus élevée avant une valeur donnée. Il peut s'agir utile lorsque vous stockez des données de séries temporelles en utilisant un code temporel comme clé de ligne suffix.

Les balayages inversés sont moins efficaces que les balayages avant. En général, Concevez vos clés de ligne de sorte que la plupart des analyses aient lieu vers l'avant. Effectuer des analyses inverses pour des analyses courtes, de 50 lignes ou moins par exemple, afin de maintenir un temps de réponse à faible latence.

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

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

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

Pour obtenir des exemples de code montrant comment utiliser les analyses inversées, consultez la section Scanner inverse.

Exemples de cas d'utilisation

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

Réinitialisation du mot de passe

Supposons que vos clés de ligne contiennent chacune un numéro client et un date, au format 123ABC#2022-05-02, et l'une des colonnes est 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 suivis. Notez que cette colonne n'existe pas pour les lignes (jours) lorsque le mot de passe n'a pas été réinitialisée.

`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 voulez savoir quand le client 123ABC a réinitialisé son mot de passe pour la dernière fois, vous pouvez effectuer l'analyse inversée sur une plage comprise entre 123ABC# et 123ABC#<DATE>, en utilisant la méthode du jour ou à une date future, pour toutes les lignes contenant cette colonne password_reset avec une limite de 1 lignes.

Changements de prix

Dans cet exemple, vos clés de ligne contiennent des valeurs pour le produit, le modèle et l'horodatage, L'une des colonnes contient le prix du produit et du modèle en temps réel.

`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 connaître les fluctuations de prix autour des prix à partir du 14 février, 2023, même si aucune clé de ligne pour cette date spécifique n'existe dans le vous pouvez effectuer une analyse directe à partir de la clé de ligne productA#model2#1676376000 pour le nombre N de lignes, puis effectuer une analyse inverse ; pour le même nombre de lignes à partir de la même ligne de départ. Les deux analyses vous permettent 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 des données à partir 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 les vues y accéder.

Toute méthode qui appelle la méthode ReadRows ou SampleRowKeys de la L'API Bigtable Data est compatible. Vous fournissez l'ID de la vue autorisée. 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 nécessitant des conditions, des entrelacements ou des expressions régulières la correspondance avec de grandes valeurs ont tendance à faire plus de mal que de bien si elles permettent les 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.