Limites d'horodatage

Introduction

Lorsque vous lisez des données dans Cloud Spanner via une transaction en lecture seule ou un appel de lecture unique, vous pouvez définir une limite d'horodatage indiquant à Cloud Spanner comment choisir un horodatage pour la lecture des données.

Pourquoi définir une limite d'horodatage ? Si votre base de données est géographiquement distribuée (ce qui est le cas si vous avez créé votre instance Cloud Spanner à l'aide d'une configuration multirégionale) et que votre application peut tolérer un certain degré d'obsolescence lors de la lecture de données, l'exécution d'une lecture non actualisée au lieu d'une lecture forte peut offrir des avantages en termes de latence. (Pour en savoir plus sur ces types de lecture, consultez la page Lectures.)

Types de limite d'horodatage

Les types de limite d'horodatage sont les suivants :

  • Lecture forte (valeur par défaut) : lire la version la plus récente des données.
  • Obsolescence limitée : lire une version des données dont l'obsolescence n'excède pas une certaine limite.
  • Obsolescence exacte : lire la version des données correspondant exactement à un certain horodatage, c'est-à-dire à un moment précis, qui peut être passé ou futur. (Si vous spécifiez un horodatage situé dans le futur, Cloud Spanner attendra ce moment pour diffuser la lecture.)

Remarques :

  • Bien que les lectures utilisant ces différents types de limite d'horodatage ne fassent pas partie d'une transaction en lecture-écriture, elles sont néanmoins susceptibles de se bloquer dans l'attente du commit de transactions en lecture/écriture simultanées. Les lectures à obsolescence limitée tentent d'éviter ce blocage en choisissant un horodatage, mais il arrive qu'elles se bloquent malgré tout.

  • Les lectures non actualisées (autrement dit, les lectures à obsolescence limitée ou exacte) assurent des gains de performances d'autant plus importants que l'intervalle d'obsolescence est plus long. Pour obtenir des avantages perceptibles, spécifiez un intervalle d'obsolescence d'au moins 10 secondes.

Les sections qui suivent présentent les types de limite d'horodatage de Cloud Spanner de manière plus détaillée.

Lecture forte

Cloud Spanner fournit un type de limite adapté aux lectures fortes. Les lectures fortes ont la garantie d'observer les effets de toutes les transactions dont le commit est antérieur au début de la lecture. De plus, toutes les lignes générées par une lecture unique sont cohérentes entre elles : si une partie de la lecture constate une transaction, toutes ses autres parties la voient également.

Les lectures fortes ne sont pas reproductibles : deux transactions en lecture seule fortes peuvent afficher des résultats incohérents en cas d'écritures simultanées. Si la cohérence entre les lectures est requise, celles-ci doivent être exécutées dans une même transaction ou selon un horodatage de lecture exact.

Obsolescence limitée

Cloud Spanner fournit un type de limite adapté à l'obsolescence limitée. Les modes d'obsolescence limitée permettent à Cloud Spanner de choisir l'horodatage de lecture en tenant compte d'une limite d'obsolescence fournie par l'utilisateur. Cloud Spanner choisit le dernier horodatage compris dans la limite d'obsolescence qui permette l'exécution sans blocage des lectures sur l'instance dupliquée disponible la plus proche.

Toutes les lignes générées sont cohérentes entre elles : si une partie de la lecture constate une transaction, toutes ses autres parties la voient également. Les lectures à obsolescence limitée ne sont pas reproductibles : même si leur limite d'obsolescence est la même, deux lectures non actualisées peuvent s'exécuter à des horodatages différents et afficher ainsi des résultats incohérents.

Une lecture à obsolescence limitée est généralement un peu plus lente qu'une lecture à obsolescence exacte d'importance comparable.

Obsolescence exacte

Cloud Spanner fournit un type de limite adapté à l'obsolescence exacte. Ces limites d'horodatage permettent d'exécuter des lectures à un horodatage spécifié par l'utilisateur. Les lectures calées sur un horodatage ont la garantie de voir un préfixe cohérent au sein de l'historique global des transactions : elles observent les modifications apportées par toutes les transactions dont l'horodatage de commit est inférieur ou égal à l'horodatage de lecture, et ne perçoivent aucune des modifications apportées par des transactions présentant un horodatage de commit supérieur. Le cas échéant, ces lectures restent bloquées jusqu'à la fin de toutes les transactions simultanées dont l'horodatage de commit est inférieur ou égal à leur horodatage de lecture.

L'horodatage peut être exprimé sous la forme d'un horodatage de commit Cloud Spanner absolu ou d'une obsolescence relative à l'heure actuelle.

Ces modes ne requièrent pas de "phase de négociation" pour le choix d'un horodatage. En conséquence, ils permettent une exécution légèrement plus rapide que les modes de simultanéité à obsolescence limitée équivalents. En revanche, les lectures à obsolescence limitée affichent généralement des résultats plus récents.

Obsolescence maximale de l'horodatage

Cloud Spanner collecte continuellement en arrière-plan les données supprimées ou écrasées afin de récupérer de l'espace de stockage. Ce processus, appelé version GC, récupère les versions présentant plus d'une heure d'ancienneté. De ce fait, Cloud Spanner ne peut pas effectuer de lectures dont l'horodatage de lecture remonterait à plus d'une heure. Cette restriction s'applique également aux lectures en cours et/ou aux requêtes SQL dont l'horodatage dépasserait ce seuil d'ancienneté pendant l'exécution. Les lectures et les requêtes SQL présentant un horodatage de lecture trop ancien échouent en générant l'erreur FAILED_PRECONDITION.

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Documentation Cloud Spanner