Coherencia de Cloud Storage

En esta página, se explica qué operaciones de Cloud Storage tienen coherencia sólida y cuáles tienen coherencia eventual. En el caso de objetos de lectura pública y almacenables en caché, puedes controlar el grado en el que las operaciones en los objetos son coherentes.

Operaciones con coherencia sólida

Cloud Storage proporciona coherencia sólida global para las siguientes operaciones:

  • Lista de buckets
  • Lectura del bucket después de su creación
  • Bucket read-after-metadata-update
  • Lectura de buckets después de la eliminación
  • Lectura después de la escritura de objetos
  • Operación de lectura de objetos después de la actualización de metadatos
  • Lectura de objetos después de la eliminación
  • Lista de objetos

Cuando escribes un objeto en Cloud Storage, por ejemplo, cuando subes, redactas o copias un objeto, este está disponible de inmediato para operaciones de lectura y metadatos en cuanto recibes una respuesta exitosa a tu escritura. Esto se aplica a todos los buckets y a todas las clases de almacenamiento, y esto se aplica a la creación de objetos nuevos y al reemplazo de los objetos existentes. Cloud Storage también ofrece operaciones de lectura después de la creación, lectura después de la actualización de metadatos, lectura después de la eliminación y coherencia de la lista para recursos como carpetas y carpetas administradas.

Debido a que las escrituras tienen coherencia sólida, nunca recibes una respuesta 404 Not Found o datos inactivos para una operación de lectura luego de escritura o lectura luego de actualización de metadatos de objetos, incluso para los buckets ubicados en regiones dobles o múltiples. En el caso poco frecuente de que tus datos aún no se hayan replicado en todas las regiones, pero la ubicación en la que se escribió por primera vez tu objeto deje de estar disponible, los intentos de acceder a él mostrarán una respuesta de error 500 reintentable.

La coherencia sólida global se extiende también a las operaciones de eliminación en objetos. Si la solicitud de una eliminación es exitosa, el intento inmediato de descarga de un objeto o sus metadatos será un código de estado 404 Not Found. El error 404 ocurre debido a que el objeto ya no existe después de que la operación de eliminación es exitosa.

Las enumeraciones de depósitos y de objetos tienen coherencia sólida: cuando creas un depósito o un objeto y realizas de inmediato la operación list relevante, el objeto o depósito recién creado aparece en la lista que se muestra.

En los depósitos, las actualizaciones de metadatos tienen coherencia sólida para las operaciones de lectura y, luego, actualización de metadatos, y los cambios resultantes de la configuración pueden tardar en propagarse. Por ejemplo, si habilitas el control de versiones de objetos en un depósito, debes esperar al menos 30 segundos antes de borrar o reemplazar objetos.

De manera similar, para las claves HMAC hay una demora de hasta 3 minutos entre el momento en que solicitas cambiar el estado de la clave y el momento en que el cambio de estado surte efecto. Por ejemplo, si inhabilitas una clave HMAC, debes esperar al menos 3 minutos antes de realizar una solicitud para borrar la clave, ya que los intentos en los primeros 3 minutos podrían fallar.

Operaciones con coherencia eventual

Las operaciones siguientes tienen coherencia eventual:

  • Otorgar o revocar el acceso a los recursos
  • Volver a crear buckets después de la eliminación

En general, estas operaciones tardan alrededor de un minuto en aplicarse. En algunos casos, puede llevar varios minutos más.

Como ejemplo de comportamiento que puede surgir en la coherencia eventual, si le quitas el acceso a un bucket a un usuario, este cambio se reflejará de inmediato en los metadatos del bucket ; sin embargo, el usuario aún puede tener acceso al bucket por un período corto.

Los buckets que se vuelven a crear después de la eliminación pueden tardar varios minutos en ser accesibles.

Coherencia y control de caché

Es posible que los objetos almacenados en caché que son de lectura pública no muestren coherencia sólida. Si permites que un objeto se almacene en caché y el objeto está en caché cuando se actualiza o se borra, ese objeto no se actualiza o se borra hasta que no caduca la vida útil de su caché.

La vida útil de la caché de un objeto se define por los metadatos Cache-Control asociados con el objeto. Los metadatos Cache-Control se pueden configurar con un encabezado de solicitud Cache-Control incluido en la carga inicial del objeto o en la actualización posterior de los metadatos del objeto. Debido a que controlas los metadatos Cache-Control, también controlas el grado de coherencia de los objetos almacenados en caché. Además, si las solicitudes para un objeto incluyen su propio encabezado Cache-Control, Cloud Storage ignora estos encabezados si están configurados para evitar el contenido en caché.

Operaciones atómicas

Cloud Storage proporciona garantías de atomicidad para la mayoría de las operaciones que implican objetos individuales, como subir un objeto, actualizar los metadatos de un objeto, reemplazar un objeto y borrarlo.

Las solicitudes por lotes, que agregan operaciones individuales en una sola solicitud, no son atómicas, ya que es posible que algunas de las operaciones contenidas en el lote fallen mientras que otras se completen correctamente.

La caché puede hacer que recibas versiones inactivas de un objeto y, si realizas operaciones de lectura de rango sin especificar un número de generación, es posible que tus datos se dañen si el objeto se reemplaza entre operaciones de lectura de rango sucesivas. Como práctica recomendada, usa condiciones previas para asegurarte de recuperar la versión correcta del objeto.

¿Qué sigue?