Introdução
Quando lê dados no Spanner numa transação só de leitura ou numa chamada de leitura única, pode definir um limite de data/hora, que indica ao Spanner como escolher uma data/hora na qual ler os dados.
Por que motivo deve definir um limite de data/hora? Se a sua base de dados estiver distribuída geograficamente (ou seja, criou a sua instância do Spanner através de uma configuração de instância de várias regiões) e a sua aplicação puder tolerar alguma desatualização ao ler dados, pode obter vantagens de latência ao executar uma leitura desatualizada em vez de uma leitura forte. (Saiba mais sobre estes tipos de leituras em Leituras.)
Tipos de limites de tempo
Os tipos de limite de data/hora são:
- Forte (predefinição): lê os dados mais recentes.
- Obsolecência limitada: ler uma versão dos dados que não seja mais antiga do que um limite.
- Obsolecência exata: leia a versão dos dados numa indicação de tempo exata, por exemplo, um ponto no tempo no passado, embora possa especificar uma indicação de tempo para um momento que ainda não passou. (Se especificar uma data/hora no futuro, o Spanner aguarda essa data/hora antes de publicar a leitura.)
Notas:
Embora as leituras que usam estes modos com limite de tempo não façam parte de uma transação de leitura/escrita, podem bloquear a espera pela confirmação de transações de leitura/escrita simultâneas. As leituras de desatualização limitada tentam escolher uma data/hora para evitar o bloqueio, mas podem continuar a bloquear.
As leituras desatualizadas (ou seja, que usam os tipos de desatualização delimitada ou exata) têm o máximo benefício de desempenho nos intervalos de desatualização mais longos. Use uma antiguidade mínima de 10 segundos para obter uma vantagem.
O Spanner monitoriza o
earliest_version_timede uma base de dados, que especifica a hora mais antiga em que as versões anteriores dos dados podem ser lidas. Não pode ler numa data/hora anterior à data/hora da versão mais antiga.
Os tipos de limites de data/hora do Spanner são explicados mais detalhadamente abaixo.
Relevante
O Spanner fornece um tipo associado para leituras fortes. As leituras fortes têm a garantia de ver os efeitos de todas as transações que foram confirmadas antes do início da leitura. Além disso, todas as linhas geradas por uma única leitura são consistentes entre si. Se qualquer parte da leitura observar uma transação, todas as partes da leitura veem a transação.
As leituras fortes não são repetíveis: duas transações só de leitura fortes consecutivas podem devolver resultados inconsistentes se existirem escritas simultâneas. Se for necessária consistência nas leituras, as leituras devem ser executadas na mesma transação ou numa data/hora exata de leitura.
Obsolecência limitada
O Spanner fornece um tipo de limite para a obsolescência limitada. Os modos de desatualização limitada permitem que o Spanner escolha a data/hora de leitura, sujeita a um limite de desatualização fornecido pelo utilizador. O Spanner escolhe a data/hora mais recente dentro do limite de desatualização que permite a execução das leituras na réplica disponível mais próxima sem bloqueio.
Todas as linhas geradas são consistentes entre si. Se qualquer parte da leitura observar uma transação, todas as partes da leitura veem a transação. As leituras desatualizadas limitadas não são repetíveis: duas leituras desatualizadas, mesmo que usem o limite de desatualização, podem ser executadas em datas/horas diferentes e, por isso, devolvem resultados inconsistentes.
Normalmente, as leituras de desatualização limitada são um pouco mais lentas do que as leituras de desatualização exata comparáveis.
Obsolecência exata
O Spanner fornece um tipo associado para a desatualização exata. Estes limites de data/hora executam leituras numa data/hora especificada pelo utilizador. As leituras num carimbo de data/hora têm a garantia de ver um prefixo consistente do histórico de transações global: observam as modificações feitas por todas as transações com um carimbo de data/hora de confirmação inferior ou igual ao carimbo de data/hora de leitura e não observam nenhuma das modificações feitas por transações com um carimbo de data/hora de confirmação superior. São bloqueadas até que todas as transações em conflito que possam ter carimbos de data/hora de confirmação inferiores ou iguais ao carimbo de data/hora de leitura tenham terminado.
A data/hora pode ser expressa como uma data/hora de confirmação absoluta do Spanner ou uma desatualização relativa à hora atual.
Estes modos não requerem uma "fase de negociação" para escolher uma data/hora. Como resultado, são executados ligeiramente mais rapidamente do que os modos de concorrência obsoletos limitados equivalentes. Por outro lado, as leituras limitadas desatualizadas devolvem normalmente resultados mais recentes.
Obsolecência máxima da indicação de tempo
O Spanner recolhe continuamente lixo dos dados eliminados e substituídos em segundo plano para recuperar espaço de armazenamento. Este processo é conhecido como GC
de versões. A versão GC reclama versões após a respetiva validade expirar após o version_retention_period de uma base de dados, que é de 1 hora por predefinição, mas pode ser configurado até 1 semana.
Esta restrição também se aplica a leituras em curso e/ou consultas SQL cuja data/hora fica demasiado antiga durante a execução. As leituras e as consultas SQL com datas/horas de leitura demasiado antigas falham com o erro FAILED_PRECONDITION. A única exceção é a leitura/consulta de partições com tokens de partição, que impede a recolha de lixo de dados expirados enquanto a sessão permanecer ativa.