Présentation
Lorsque vous lisez des données dans Spanner transaction en lecture seule ou appel de lecture unique, vous pouvez définir une limite du code temporel, indique à 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 répartie géographiquement (que vous avez créé votre instance Spanner à l'aide d'une instance multirégionale et votre application peut tolérer une certaine obsolescence lors de la lecture des données, vous pouvez bénéficier d'une latence accrue grâce à l'exécution d'une lecture non actualisée au lieu d'une lecture forte. (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 code temporel futur, Spanner attendra cet horodatage avant de 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.
Spanner conserve une trace du
earliest_version_timed'une base de données, qui spécifie le moment auquel les versions de données antérieures peuvent être lues. Vous ne pouvez pas lire un horodatage antérieur à la date de la première version.
Les types de limites d'horodatage Spanner sont expliqués plus en détail ci-dessous.
Forte
Spanner fournit un type de limite pour les 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
Spanner fournit un type de limite adapté à l'obsolescence limitée. Obsolescence limitée permettent à Spanner de choisir le code temporel de lecture, sous réserve d'une était d'assurer l'obsolescence. 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
Spanner fournit un type de limite pour une 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 Spanner absolu ou d'une obsolescence par rapport à 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
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 est appelé version GC. La version GC récupère les versions après leur expiration dans le champ version_retention_period d'une base de données. La valeur par défaut est d'une heure, mais elle peut être configurée jusqu'à une semaine.
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. La seule exception concerne la lecture/l'interrogation de la partition avec des jetons de partition, ce qui empêche la récupération de mémoire de données expirées lorsque la session reste active.