Lecture

Cette page décrit les types de requêtes de lecture que vous pouvez envoyer à Cloud 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 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.

Lectures sur une seule ligne

Vous pouvez demander une seule ligne en fonction de la clé de ligne. 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 :

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.

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.

Lectures pour des situations spécifiques

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.

Simuler une analyse inverse

Bigtable ne permet pas d'effectuer d'analyse inverse, contrairement à HBase. Cependant, vous pouvez simuler une analyse inverse. Cette technique est utile si vous souhaitez rechercher la version la plus récente d'une valeur qui n'est pas stockée dans la même ligne et la même colonne.

Cette approche suppose que vous avez créé des clés de ligne contenant des valeurs pouvant être soustraites, telles que des nombres ou des dates. Commencez par une ligne, X, à partir de laquelle vous souhaitez effectuer une recherche. Commencez par rechercher un nombre de lignes Y avant X , à savoir de X-Y à X. Si la valeur est introuvable, recherchez l'ensemble de lignes suivant, par exemple de X-Y*2 à X-Y ou de X-Y*3 à X-Y. Si la valeur est introuvable, recherchez l'ensemble de lignes suivant, et ainsi de suite jusqu'à ce que la valeur soit trouvée.

Par exemple, supposons que vos clés de ligne comprennent un ID client et une date au format 123ABC#2020-05-02 et que l'une des colonnes, password_reset, enregistre l'heure de réinitialisation du mot de passe. Bigtable les stocke automatiquement 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#2020-02-12,password_reset:03`
`123ABC#2020-04-02,password_reset:11`
`123ABC#2020-04-14`
`123ABC#2020-05-02`
`223ABC#2020-05-22`

Si vous recherchez la dernière fois que le client 123ABC a réinitialisé son mot de passe, vous pouvez commencer par lire une plage de 2020-05-21 à 2020-05-22. Si la valeur est introuvable, recherchez de 2020-05-19 à 2020-05-20, etc. jusqu'à ce que vous obteniez une ligne contenant une valeur pour la colonne password_reset.

Étape suivante