Rapid Cache

Nesta página, descrevemos o Rapid Cache, um recurso que fornece um cache de leitura zonal com SSD para buckets do Cloud Storage que pode aumentar a capacidade de processamento e reduzir a latência nos dados armazenados. O Rapid Cache oferece capacidade de armazenamento e largura de banda que são escalonadas automaticamente para cima ou para baixo de acordo com suas necessidades. O Rapid Cache é um serviço totalmente gerenciado e retorna dados consistentes.

O Rapid Cache é útil para melhorar o desempenho de cargas de trabalho com muita leitura e reduzir os custos de rede. Para mais informações, consulte Benefícios.

Consulte Criar e gerenciar caches para saber como criar e gerenciar caches usando o Rapid Cache.

Como o Rapid Cache funciona?

Com o Rapid Cache, é possível criar caches na mesma zona das cargas de trabalho. Quando você cria um cache em uma zona, as solicitações de leitura de dados originadas da zona são processadas pelo cache, e não pelo bucket. Cada cache atende a clientes na mesma zona que ele.

Os dados de um bucket são ingeridos em um cache quando são lidos por uma VM que reside na mesma zona que o cache. Se você configurar o comportamento de ingestão na gravação, os dados também serão ingeridos no cache quando forem gravados no bucket.

Os metadados não são armazenados em cache. As solicitações de metadados de objeto são sempre processadas pelo bucket, e não pelo cache.

Para mais informações sobre como os dados são ingeridos em um cache, consulte Ingestão de dados. É possível configurar o time to live (TTL) e o comportamento de ingestão na gravação de um cache ao criá-lo ou atualizá-lo.

Vantagens

Ao armazenar seus dados em cache com o Rapid Cache, você tem os seguintes benefícios:

• Acesso mais rápido aos dados: o Rapid Cache colocaliza seus dados na mesma zona que seus recursos de computação e tem suporte total de SSD. Isso permite que suas cargas de trabalho tenham até 2,5 TB/s de capacidade de processamento e reduz a latência para leituras mais rápidas.

• Reduza as taxas de transferência de dados multirregionais: os dados lidos do cache são cobrados com taxas de transferência de dados reduzidas em comparação com os dados lidos diretamente de um bucket multirregional.

• Reduzir as taxas de recuperação: as taxas de recuperação para buckets no Nearline Storage, Coldline Storage e Archive Storage não se aplicam a leituras de dados do cache.

• Reduzir os custos das operações de leitura: as operações de leitura veiculadas pelo Rapid Cache têm preços mais baixos do que as operações de classe B veiculadas por um bucket no Standard Storage.

• Escalonar automaticamente o tamanho do cache: o armazenamento em cache SSD dinâmico do Rapid Cache é escalonado automaticamente com base no uso, sem que você precise especificar um tamanho de cache.

• Usar caches de maneira eficiente: o Rapid Cache pode ser ativado em buckets existentes sem exigir mudanças nos aplicativos ou nas APIs atuais. Os dados armazenados no Rapid Cache têm consistência forte.

Para mais detalhes sobre preços, consulte Preços do Rapid Cache. Para informações sobre cotas, consulte Cotas do Rapid Cache.

Quando usar o Rapid Cache?

Use o Rapid Cache para dados que são lidos com frequência e alterados com pouca frequência para acelerar as leituras de dados em cargas de trabalho de análise e no treinamento e carregamento de modelos de IA/ML.

Digamos que você esteja treinando um modelo de IA em vários nós do Google Kubernetes Engine, todos lendo repetidamente dados armazenados nos buckets do Cloud Storage e em execução na mesma zona. Quando você cria um cache na zona em que sua carga de trabalho está em execução, ele fornece largura de banda extra e ajuda a reduzir as taxas de transferência de dados associadas à leitura de dados em buckets multirregionais, permitindo que você execute cargas de trabalho maiores e escalonadas com mais eficiência.

Escalonamento automático do tamanho do cache e do limite de largura de banda

O Rapid Cache oferece capacidade de armazenamento temporário e largura de banda que são escalonadas automaticamente para cima ou para baixo de acordo com a quantidade de dados armazenados em um cache.

O limite de largura de banda do cache começa em 100 Gbps e aumenta a uma taxa de 20 Gbps por 1 TiB de dados armazenados. É possível aumentar a largura de banda inicial ou o limite total de largura de banda aumentando a quantidade de dados armazenados no cache, criando mais caches em uma zona ou entrando em contato com o gerente técnico de contas ou o representante do Google.

Para saber mais sobre os limites de tamanho e largura de banda do Rapid Cache, consulte Cotas e limites do Cloud Storage.

Como armazenar dados em cache em zonas

Ao criar um cache para um bucket, ele precisa ser criado em uma zona dentro do local do bucket. Por exemplo, se o bucket estiver localizado na região us-east1, será possível criar um cache em us-east1-b, mas não em us-central1-c. Se o bucket estiver localizado na birregião ASIA, será possível criar um cache em qualquer zona que componha as regiões asia-east1 e asia-southeast1.

Para cada bucket, é possível criar no máximo um cache por zona. Por exemplo, se um bucket estiver localizado na região us-east1, será possível criar um cache em us-east1-b e outro em us-east1-c. Se um bucket estiver localizado em um local multirregional que abrange us-central1 e us-east1, será possível criar um cache em us-central1-a e outro em us-east1-b.

É possível criar caches em zonas, desde que haja capacidade disponível para elas. Se a capacidade para criar um cache não estiver disponível, o Rapid Cache continuará tentando criar um cache até que a capacidade fique disponível ou o processo de criação seja cancelado pelo usuário. A capacidade pode permanecer indisponível por um longo período.

É possível usar o Rapid Cache nas zonas a seguir. Essas zonas podem ser usadas dependendo do tipo de local do bucket.

Ásia

A tabela a seguir mostra as zonas e os tipos de local disponíveis para o Rapid Cache na área geográfica da Ásia.

Nome da zona	Região	Birregional	Multirregional	Birregião personalizada
asia-east1-a	check		check	check
asia-east1-b	check		check	check
asia-east1-c	check		check	check
asia-northeast1-a	check	check
asia-northeast1-b	check	check
asia-northeast1-c	check	check
asia-south1-a	check
asia-south1-b	check
asia-south1-c	check
asia-southeast1-a	check		check	check
asia-southeast1-b	check		check	check
asia-southeast1-c	check		check	check

Europa

A tabela a seguir mostra as zonas e os tipos de local disponíveis para o Rapid Cache na área geográfica da Europa.

Nome da zona	Região	Birregional	Multirregional	Birregião personalizada
europe-north1-a	check	check
europe-north1-b	check	check
europe-north1-c	check	check
europe-west1-b	check	check	check	check
europe-west1-c	check	check	check	check
europe-west1-d	check	check	check	check
europe-west3-a	check		check	check
europe-west3-b	check		check	check
europe-west3-c	check		check	check
europe-west4-a	check	check	check	check
europe-west4-b	check	check	check	check
europe-west4-c	check	check	check	check
europe-west4-ai1a (Zona de IA)	check
europe-west6-a	check	check
europe-west6-b	check	check

Estados Unidos

A tabela a seguir mostra as zonas e os tipos de local disponíveis para o Rapid Cache na área geográfica dos Estados Unidos.

Nome da zona	Região	Birregional	Multirregional	Birregião personalizada
us-central1-a	check	check	check	check
us-central1-b	check	check	check	check
us-central1-c	check	check	check	check
us-central1-f	check	check	check	check
us-central1-ai1a (Zona de IA)	check
us-east1-b	check	check	check	check
us-east1-c	check	check	check	check
us-east1-d	check	check	check	check
us-east4-a	check		check	check
us-east4-b	check		check	check
us-east4-c	check		check	check
us-east5-a	check		check	check
us-east5-b	check		check	check
us-east5-c	check		check	check
us-south1-a	check		check	check
us-south1-b	check		check	check
us-south1-c	check		check	check
us-south1-ai1b (Zona de IA)	check
us-west1-a	check		check	check
us-west1-b	check		check	check
us-west1-c	check		check	check
us-west2-a	check
us-west3-a	check
us-west3-b	check
us-west3-c	check
us-west4-a	check		check	check
us-west4-b	check		check	check
us-west4-c	check		check	check

Ingestão de dados para caches

Por padrão, os dados são ingeridos em um cache depois de serem solicitados pela primeira vez.

Como o cache está vazio quando essa solicitação inicial chega, os dados ainda não podem ser encontrados nele. Isso resulta em uma ausência no cache inicial, em que o sistema recupera os dados do bucket do Cloud Storage de apoio. À medida que o sistema entrega esses dados recuperados ao usuário, ele os ingere simultaneamente no cache.

Depois que essa primeira solicitação é concluída, os dados residem no cache, permitindo que todas as leituras subsequentes sejam veiculadas diretamente do cache como ocorrências em cache de alta velocidade. Esse comportamento reduz significativamente a latência de leitura e acelera a recuperação de dados. Os dados ingeridos residem no cache até que o TTL expire. Depois disso, os dados são removidos do cache.

Para evitar totalmente a solicitação inicial lenta, configure o cache para ingerir dados na gravação, além de ingerir dados após a primeira leitura.

Como ingerir dados como blocos

Ao ingerir dados em um cache, o Rapid Cache divide os objetos em blocos menores de tamanho fixo. A divisão de objetos em partes permite um armazenamento em cache mais granular, especialmente para arquivos grandes em que apenas partes específicas são acessadas.

Um bloco é um conjunto de dados de 2 MB. Quando um objeto é solicitado, o Rapid Cache identifica quais blocos de 2 MB cobrem o intervalo de bytes solicitado e gerencia esses blocos de forma independente.

O comportamento da ingestão de dados varia de acordo com o tamanho do objeto que está sendo ingerido no cache:

• Para solicitações de leitura de objetos maiores que 2 MB, somente os blocos que contêm o intervalo de bytes solicitado são ingeridos. Por exemplo, a leitura do primeiro 1 MB de um arquivo de 100 MB ingere apenas o primeiro bloco de 2 MB.

• Para solicitações de leitura de objetos menores que 2 MB (por exemplo, uma imagem de 500 KB), todo o objeto é ingerido no cache.

Ingestão de dados na gravação

Quando você ativa um cache para ingerir dados na gravação, os dados são ingeridos no cache no momento em que são gravados no bucket. Esse comportamento pode ser ativado como complemento ao comportamento padrão de ingestão de dados após a leitura inicial.

O recurso de ingestão na gravação remove as ausências no cache iniciais e permite que sua carga de trabalho se beneficie de uma ocorrência em cache imediata na primeira leitura de dados. A ingestão de dados na gravação acelera as cargas de trabalho de leitura após gravação, como restaurar checkpoints do sistema ou preparar pipelines de dados para treinamento de modelo.

É possível ativar um cache para ingerir dados na gravação ao criar ou atualizar o cache. É possível configurar um cache para ingerir todos os objetos gravados em um bucket (também conhecido como "ingestão na gravação no nível do bucket") ou ingerir seletivamente objetos gravados no bucket em uma pasta gerenciada especificada (também conhecida como "ingestão na gravação no nível do prefixo").

Por exemplo, digamos que você ative um cache para realizar a ingestão na gravação no nível do prefixo para objetos no bucket my-bucket que têm o prefixo red/ no nome. Em seguida, você faz upload de três objetos para my-bucket: os objetos red/my-dog.png, blue/my-cat.png e red/my-goldfish.png. Como resultado, apenas os objetos red/my-dog.png e red/my-goldfish.png são ingeridos no cache após o upload para my-bucket.

Ao configurar a ingestão na gravação no nível do prefixo usando determinadas ferramentas (como o console doCloud de Confiance ), uma nova pasta gerenciada é criada automaticamente para você se você especificar um prefixo que não seja o nome de uma pasta gerenciada atual. No entanto, ao usar a API JSON, é necessário criar manualmente a pasta gerenciada e aplicar as configurações de ingestOnWrite para cada zona de cache. Confira as instruções para ativar ou desativar a ingestão na gravação usando cada ferramenta em Usar o Rapid Cache.

Para entender como ativar ou desativar a ingestão na gravação no nível do bucket ou do prefixo ao usar a API JSON, expanda a seção Noções básicas sobre como ativar a ingestão na gravação. As informações nesta seção se referem principalmente à API JSON. Outras ferramentas, como o console doCloud de Confiance , ocultam algumas das configurações para facilitar a ativação e o gerenciamento da ingestão na gravação.

Como ativar a ingestão na gravação

Esta seção ajuda você a entender quais configurações da API JSON usar para ativar a ingestão na gravação para todos os objetos gravados em um bucket ou apenas para objetos selecionados que são gravados no bucket em um prefixo de pasta gerenciada.

Há duas configurações que controlam se um cache ingere dados na gravação para todos os objetos em um bucket ou apenas para objetos seletivos em um prefixo:

• A ativação da ingestão na gravação no nível do bucket é feita usando o campo ingestOnWrite de um recurso de cache. O campo é assim:

  {
  "zone": "us-east1-a",
  "ttl": "24h",
  "ingestOnWrite": true
  }

  • Se definido como true, a ingestão na gravação será ativada para todos os objetos gravados no bucket. Isso substitui todas as configurações no nível da pasta gerenciada que ativam a ingestão na gravação para objetos seletivos por prefixo.
  • Se definido como false, a ingestão na gravação será desativada em objetos em todo o bucket. Essa configuração permite ativar a ingestão na gravação para objetos seletivos por prefixo usando as configurações de pastas gerenciadas.

• A ativação da ingestão na gravação no nível do prefixo é feita usando pastas gerenciadas, que representam caminhos de prefixo que terminam com uma barra (por exemplo: my-prefix/). Quando a ingestão na gravação no nível do prefixo está ativada, um cache ingere seletivamente objetos na gravação somente se o objeto tiver o prefixo no nome.

  A ingestão na gravação no nível do prefixo é controlada pelo campo ingestOnWrite do mapeamento rapidCacheConfig.policies em um recurso de pasta gerenciada. Uma instância de cache precisa existir para ser especificada no mapeamento rapidCacheConfig.policies.

  O mapeamento rapidCacheConfig.policies de uma pasta gerenciada é semelhante ao seguinte:

  "rapidCacheConfig": {
    "policies": {
      "us-east1-a": {
        "rapidCacheId": "us-east1-a",
        "ingestOnWrite": "unspecified"
      }
      "us-east1-b": {
        ...,
        ...
      }
    }
  }

  • As instâncias de cache especificadas no mapeamento policies precisam existir para que a ingestão na gravação no nível do prefixo funcione. Por exemplo, para especificar rapidCacheId: "us-east1-a" no mapeamento policies, primeiro é preciso ter um cache para a zona us-east1-a.
  • É possível atualizar várias instâncias de cache especificadas no mapeamento policies em uma única chamada de API.
  • Se ingestOnWrite for definido como enabled, a ingestão na gravação será ativada para todos os objetos gravados no bucket com esse prefixo de pasta gerenciada. A ingestão na gravação no nível do prefixo só pode ser ativada se o campo ingestOnWrite do recurso de cache for false.
  • Se definido como unspecified (padrão), a ativação da ingestão na gravação é herdada do recurso pai imediato, que pode ser uma pasta gerenciada pai ou o bucket que contém a própria pasta gerenciada.
  • Os caches não especificados no mapeamento de políticas são tratados como se a configuração ingestOnWrite estivesse definida como unspecified.

Veja a seguir um resumo de como configurar os recursos de cache e pasta gerenciada para ativar ou desativar a ingestão na gravação no nível do bucket ou do prefixo:

• Ativar a ingestão na gravação no nível do bucket (mas não no nível do prefixo)

  • Configuração: defina o campo ingestOnWrite do recurso de cache como true.

  • Comportamento: a ingestão na gravação está ativada para todos os objetos gravados no bucket. Essa configuração para todo o bucket substitui todas as configurações no nível da pasta gerenciada, ou seja, as configurações seletivas no nível do prefixo são ignoradas.

• Ativar a ingestão na gravação no nível do prefixo (mas não no nível do bucket)

  • Configuração:

    1. Defina o campo ingestOnWrite do recurso de cache como false.
    2. Configure um mapeamento policies válido (não nulo) no recurso de pasta gerenciada.
    3. Defina o campo ingestOnWrite da pasta gerenciada como enabled (ou defina como unspecified se for uma pasta filha que herda enabled de uma pasta gerenciada pai ativada).

  • Comportamento: a ingestão na gravação só ocorre para objetos gravados em prefixos de pastas gerenciadas correspondentes.

• Ativar a ingestão na gravação no nível do prefixo em pastas gerenciadas pai x filho

  Não é possível ativar a ingestão na gravação para pastas gerenciadas filhas sem também ativá-la na pasta gerenciada mãe.

• Como desativar a ingestão na gravação de buckets e prefixos

  • Configuração:

    1. Defina o campo ingestOnWrite do recurso de cache como false.

    2. Defina todos os campos ingestOnWrite das pastas gerenciadas como unspecified, garantindo que nenhum campo ingestOnWrite das pastas gerenciadas pai seja enabled.

       Como alternativa, não configure nenhuma política deixando o mapa policies null ou omitindo totalmente a configuração rapidCacheConfig.

  • Comportamento: a ingestão na gravação está desativada globalmente para o bucket e todos os prefixos.

Quando você ativa a ingestão na gravação no nível do prefixo em uma pasta gerenciada mãe, ela é ativada para todas as pastas gerenciadas filhas que estão aninhadas na pasta gerenciada mãe. Para saber mais sobre como os recursos herdam a ativação e a desativação da ingestão na gravação, abra a seção Como funciona a herança da ingestão na gravação.

Como funciona a herança de ingestão na gravação

Quando uma pasta gerenciada não ativa explicitamente a ingestão na gravação (em que o campo ingestOnWrite da pasta gerenciada é definido como unspecified), o comportamento de ingestão na gravação do cache é herdado do recurso pai da pasta gerenciada, seja do bucket ou de uma pasta gerenciada pai.

Ao usar a ingestão na gravação no nível do prefixo, a configuração de ingestão na gravação definida em uma pasta gerenciada pai é herdada por todas as pastas gerenciadas filhas.

Por exemplo, considere o seguinte cenário:

• Você tem uma pasta gerenciada a/ cujo recurso pai é o bucket my-bucket.
• Você tem uma pasta gerenciada a/b/ cujo recurso pai é a pasta gerenciada a/ em my-bucket.

Quando um objeto chamado a/b/info.txt é gravado, o Rapid Cache avalia a hierarquia de configuração de cima para baixo:

1. Verifique a pasta gerenciada imediata: se a/b/ estiver definido como enabled, a ingestão na gravação no nível do prefixo estará ativada para objetos gravados em a/b/. Se a/b/ estiver definido como unspecified, o Rapid Cache vai verificar o recurso pai imediato, que é a pasta gerenciada a/.
2. Verifique a pasta gerenciada pai: se a/ estiver definido como enabled, a ingestão na gravação no nível do prefixo estará ativada para a/ e a/b/. Se a/ estiver definido como unspecified, o Rapid Cache vai verificar o bucket pai.
3. Verifique a configuração de ingestOnWrite no nível do cache do bucket: se o campo ingestOnWrite do cache estiver definido como true, a ingestão na gravação no nível do bucket estará ativada e vai substituir qualquer pasta gerenciada que tenha a ingestão na gravação no nível do prefixo configurada. Se o campo ingestOnWrite do cache for false e o campo ingestOnWrite das pastas gerenciadas pai e filho forem unspecified, a ingestão na gravação será desativada para objetos no bucket que estão nas pastas gerenciadas pai e filho. Nesse cenário, se não houver outras pastas gerenciadas no bucket com a ingestão na gravação configurada, ela será desativada para todos os objetos no bucket.

Time to live (TTL)

O TTL de um cache determina por quanto tempo os dados permanecem no cache antes de serem removidos. O TTL é o período em que os dados permanecem no cache desde a última leitura. Por exemplo, se o TTL estiver definido como 24 horas, um bloco de dados que foi lido pela última vez às 11h de segunda-feira sem leituras subsequentes será removido do cache às 11h de terça-feira.

É possível definir o TTL de um cache ao criá-lo ou atualizá-lo. É possível definir o TTL de um cache como um valor entre 24 horas e 7 dias, inclusive. Se não for especificado, o TTL padrão será de 24 horas.

Operações de cache

Nesta seção, descrevemos as operações que podem ser realizadas em caches do Rapid Cache. Algumas operações são assíncronas e retornam uma operação de longa duração, enquanto outras são síncronas, em que as operações são feitas imediatamente e retornam um recurso AnywhereCache.

Criar um cache

É possível definir o local, o TTL e o comportamento de ingestão de dados de um cache ao criá-lo. O cache entra em um estado CREATING enquanto está sendo criado e entra em um estado RUNNING quando se torna ativo. Uma operação de criação de cache pode levar até 48 horas. Depois disso, ela expira.

A API Create do AnywhereCaches é assíncrona. Uma operação de criação faz com que uma operação de longa duração seja retornada. A operação de longa duração fornece um status da operação de criação e permite que você a cancele antes que ela seja concluída.

Atualizar um cache

É possível definir o TTL ou o comportamento de ingestão de dados de um cache ao atualizar o cache. Só é possível atualizar caches que estejam no estado RUNNING. Não é possível atualizar um cache no estado CREATING ou DISABLED.

Quando um cache está sendo atualizado, o campo pending_update é avaliado como true. Enquanto o campo pending_update for avaliado como true, o cache não poderá ser atualizado novamente. Quando o TTL de um cache termina de ser atualizado, o novo TTL é aplicado imediatamente aos dados atuais e novos no cache.

A API AnywhereCaches Update é assíncrona e retorna uma operação de longa duração.

Acessar um cache

Quando você recebe um cache, o Rapid Cache retorna o estado e a configuração da instância de cache. A API Get do AnywhereCaches é síncrona e retorna um recurso AnywhereCache.

Listar caches

É possível retornar uma lista de caches associados a um determinado bucket. A API AnywhereCaches List é síncrona e oferece suporte à paginação.

Desativar um cache

É possível desativar um cache para removê-lo permanentemente da configuração do bucket. Quando você desativa um cache, ele entra no estado DESATIVADO. Durante esse estado, ainda é possível ler os dados atuais do cache, mas não é possível ingerir novos dados nele.

Depois de desativar um cache, há um período de carência de 1 hora em que é possível cancelar a desativação retomando o cache. Após esse período de carência de 1 hora, o cache é excluído. Quando o cache é excluído, todos os dados dentro dele são removidos, e o cache é removido do bucket.

Durante o período de uma hora antes da exclusão do cache, é possível reverter o estado DISABLED retomando o cache, que será retomado no estado RUNNING.

A API Disable do AnywhereCaches é síncrona e retorna um recurso AnywhereCache.

Retomar um cache

É possível retomar caches que estão no estado DISABLED, desde que o cache desativado esteja dentro do período de carência de 1 hora. Após o período de carência de uma hora, a operação de retomada é feita da melhor maneira possível, já que o cache pode ser excluído a qualquer momento após o período de carência. Depois que um cache é retomado, ele entra no estado RUNNING.

A API Resume do AnywhereCaches é síncrona e retorna um recurso AnywhereCache.

Recomendador do Rapid Cache

O recomendador do Rapid Cache fornece recomendações e insights para criar caches em pares de bucket e zona, analisando o uso e o armazenamento de dados. Para informações gerais e instruções sobre como usar o recomendador do Rapid Cache, consulte Recomendador do Rapid Cache.

Como usar o Rapid Cache para acelerar as leituras do BigQuery

O Rapid Cache pode ser usado para disponibilizar dados para solicitações de leitura de objetos emitidas pelo BigQuery. Com o Rapid Cache, é possível acelerar as leituras de dados dos seus aplicativos e otimizar a eficiência de custos.

Embora o BigQuery seja um serviço regional, os recursos de computação subjacentes podem, ocasionalmente, mudar de zona para balanceamento de carga. Como prática recomendada, ative o Rapid Cache para uma carga de trabalho do BigQuery em todas as zonas de uma região para garantir que haja um cache disponível para uso caso os recursos de computação subjacentes mudem de zona. Se um cache em uma zona não for usado, ele não vai gerar custos extras, já que o Rapid Cache é pago por uso. Se os recursos de uma carga de trabalho mudarem de zona, o cache na nova zona precisará ingerir os dados novamente, o que pode gerar um aumento único nos custos de ingestão de dados.

Criptografia de dados em cache

Os dados são armazenados no cache no formato original criptografado do lado do servidor, fornecendo compatibilidade com as opções de criptografia compatíveis com o Cloud Storage.

Limitações e restrições

• Para excluir um bucket, primeiro é preciso excluir todos os caches associados a ele. A única exceção é ao excluir um bucket usando o console do Cloud de Confiance , que exclui todos os caches associados junto com o bucket.

• Ao realizar as operações de criação, desativação, retomada ou atualização de cache, limite a taxa de operações a no máximo uma operação por segundo. A execução de mais de uma operação por segundo pode resultar em falhas.

• O Rapid Cache não é um armazenamento durável, e os dados podem ser removidos do cache em vários cenários. Um cenário é quando o cache é redimensionado automaticamente para garantir que recursos suficientes estejam disponíveis para suas cargas de trabalho. Nesse cenário, alguns dados podem ser removidos de acordo com um algoritmo de uso mais recente (LRU, na sigla em inglês) até que o serviço de cache rápido termine de aumentar o tamanho do cache.

  Em qualquer caso, seus dados permanecem armazenados com segurança no bucket de origem. Quando os dados são removidos do cache por motivos que não sejam a expiração do TTL, o serviço Rapid Cache tenta reingerir os dados no cache de forma transparente e sem custo financeiro para você. Se os dados não puderem ser reingeridos de forma transparente ou forem descartados devido à expiração do TTL, o serviço Rapid Cache vai reingerir os dados na primeira leitura.

• As recomendações e os insights gerados pelo recomendador do Rapid Cache não podem ser lidos usando o BigQuery.

Considerações sobre desempenho

• Perdas de blocos: se uma solicitação abranger vários blocos e alguns deles estiverem no cache, mas outros não, o Rapid Cache vai recuperar de forma transparente os blocos ausentes do bucket de origem.

• TTL e remoção: as políticas de remoção de Time to Live (TTL) e Least Recently Used (LRU) também operam em blocos. As partes usadas com frequência de um arquivo grande podem permanecer no cache, enquanto as partes usadas com pouca frequência são removidas.

Preços

Para saber os preços de uso do Rapid Cache, consulte Preços do Rapid Cache.

Controle de custos

Expanda as dicas a seguir para saber como minimizar os custos de execução de caches:

Seleção de bucket

Crie caches apenas para buckets que contenham dados que você quer armazenar em cache.

Seleção de zona

Crie caches apenas em zonas em que a carga de trabalho se beneficie do armazenamento em cache.

Configuração de TTL

Especifique o TTL mínimo necessário para armazenar dados no cache. O TTL pode ser alterado sem interrupções. O padrão é 1 dia.

Como desativar o cache

É possível desativar um cache para removê-lo permanentemente do serviço e interromper o acúmulo de todas as taxas de cache associadas.

Solução de problemas de escassez temporária de recursos

As seções a seguir descrevem como resolver problemas quando ocorre uma escassez temporária de recursos, em que não há capacidade de SSD ou de exibição suficiente em uma zona especificada para criar um cache, aumentar o tamanho de um cache ou aumentar o limite de largura de banda de um cache.

A seguir

• Criar e gerenciar caches.